更新中……
轉載請說明出處：http://blog.csdn.net/guwuchangtian/article/details/77481224
概述
運輸層：爲運行在不同主機上的進程之間提供邏輯通信功能。
與網絡層的關係：運輸層是爲進程提供通信，網絡層是爲主機提供邏輯通信。所以運輸層運行於主機上爲應用程序進程提供服務，而網絡層則運行於整個網絡，爲所有主機（也可以說是傳輸層）提供服務。
IP協議：即網際協議（internet protocol），是網絡層協議，IP服務模型是提供盡力而爲的交付服務，即不提供任何保證服務的委婉說法，因爲它不做任何的確保，只“盡最大努力”爲傳輸層提供報文段，因此IP被稱爲不可靠服務。
當網絡層數據報交付給運輸層時，運輸層如何區別是那個進程的報文？
套接字綁定，多路複用和多路分解。
套接字綁定：應用層的每個進程，都會與一個或多個套接字綁定，用套接字標識來將進程和套接字綁定。（如高性能web服務器通常只使用一個進程，而爲每個新的連接創建新線程創建一個新的綁定新端口的套接字）
多路複用：從主機收集應用層的進程產生的報文，添加適當的首部（包含用於多路分解的內容）生成報文段，將報文段傳遞給網絡層的過程，稱爲多路複用。
多路分解：將運輸層報文段報文首部解析，匹配套接字標識，將相應的報文交付到正確的套接字稱爲多路分解。
如何實現多路複用和多路分解：
標識：
① 套接字有唯一標識
② 每個報文段有特殊字段來指示該報文段所要交付到的套接字。
特殊字段包括源端口號字段、目的端口號字段、以及一些TCP和UDP特有的字段。
端口號：（source port number field），是一個16比特的數，大小爲0~65535，其中0~1023稱爲周知端口號，是受限的，它爲一些著名的程序或協議保留，如HTTP默認端口爲80，FTP爲21。
如何多路分解：主機上的每個套接字與一個端口號綁定，當報文段到達主機時，應用層檢查報文段中的目的端口號，將它定向到對應的套接字，報文中的數據通過套接字進入對應進程中。（UDP是這樣的，TCP比這個複雜得多）
UDP套接字標識：由一個二元組標識，即（目的IP地址，目的端口號）。運輸層報文段通過解析首部來找到對應二元式的UDP套接字。
TCP套接字標識：由一個四元組標識，即（源IP地址，源端口號，目的IP地址，目的端口號），運輸層通過解析首部來找到對應四元式的TCP套接字，與UDP不同的是，當一個源IP地址或源端口號不同時，將被定向到不同的套接字。
端口掃描：攻擊者通過掃描攻擊對象主機的端口，來找到存在漏洞的端口程序。
UDP
UDP做的工作：除了運輸層必須支持的多路複用和多路分解之外，只提供了簡單的基於16bit校驗和的差錯檢測功能，使用UDP差不多相當於和IP打交道。
UDP工作流程：當應用進程使用UDP進行通信是，UDP接收進程報文，附加上目的IP和目的端口號，以及其他兩個小字段，形成報文段交給網絡層，網絡層將報文段封裝成一個IP數據包，並盡力而爲地將它交付到目的主機。
沒有握手： UDP在傳輸數據之前沒有握手，因此被稱爲無連接的。DNS 是一個使用UDP運輸層協議的典型例子。
UDP的優勢：既然UDP“幾乎不”提供服務，那麼爲什麼還要選擇UDP來進行傳輸呢？
① 發送時間控制精確：UDP只要報文準備好就立即發送，而TCP爲保證可靠性，有時需要重複發送相同報文，直到接收方確認。
② 無需建立連接：TCP傳輸前需要三次握手。
③ 無連接狀態：TCP需要在端系統中維護連接狀態。
④ 首部開銷小。
UDP缺點：無連接，不可靠，無狀態，不能進行擁塞控制（對整個網絡來說，這是一個很致命的缺點）。
UDP報文段結構：首部包括四個字段，（源端口號，目的端口號，長度，校驗和）每個字段2字節。結構如下圖：
UDP校驗和：發送方將報文段中的所有16比特字的和進行反碼運算，求和時遇到的所有溢出都被回捲，得到的結果放到校驗和部分。接收方將接收到的報文段進行16比特相加，再加上校驗和，如果結果爲全1，則正確，有一個0則出現差錯。
UDP無恢復能力：雖然UDP可以進行差錯檢測，但沒有恢復能力，有的實現是將報文段直接丟棄，有的實現是將報文段交給應用程序，由應用程序來處理，如發出警告之類的。
TCP
可靠數據傳輸原理
可靠數據傳輸協議也是不斷完善了，從一開始的rdt1.0到rdt3.0，每個版本都比上一版本提供更可靠的數據傳輸，最後得到一個無錯的、可靠地協議。
\\\\\\\\\\\\\\\\\\ 經完全可靠信道傳輸的傳輸層協議 rdt1.0
該協議將可靠傳輸任務完全交由下層的可靠信道來處理，而如何構建這樣的可靠信道並不是現在討論的重點，我們先假設有這麼一條可靠信道，分組以發送的順序進行交付，分組和比特都不丟失。
一旦傳輸信道可靠，那麼運輸層需要做的就只有發送和接收工作了。
FSM：（finite-state machine）有限狀態機
rdt_send(data)：上層（應用層）數據傳輸接口，傳輸的數據爲data。rdt的意思是可靠數據傳輸，send的意思是發送。
udt_send(packet)：下層（網絡層及下層）提供的數據傳輸接口，不可靠數據傳輸。
deliver_data(data)：向叫高層交付數據。
rdt 1.0的FSM如下圖：
\\\\\\\\\\\\\\\\\\ 經有比特差錯信道的傳輸協議 rdt2.0
該版本協議由“肯定確認”和“否定確認”機制來進行支持，當接受方接收到正確數據，需要回復“肯定確認”，當檢測到有差錯時，需要回復“否定確認”，並提供自動重傳機制。
rdt2.0需要以下三種功能的支持：
差錯檢測：通過冗餘比特來檢測併力求糾正差錯，將在後續（物理層）講到。
接收方反饋：接收方需要反饋接收到的數據是否正確，正確則回覆“ACK”（用1表示），錯誤則回覆“NAK”（用0表示）。
重傳：接收方收到有差錯的分組是，發送方將重傳。
rdt 2.0的FSM如下圖：
發送方：
接收方：
rdt2.0有一個致命的缺點，就是如果ACK/NAK分組出錯，則發送方將不知道接收方是否正確接收到了數據，一種解決辦法是在ACK/NAK含糊不清時，直接重傳分組。這樣又引進一個問題，接收方如果正確接收到了分組，但是反饋的ACK出錯，發送方又重傳了分組，那麼接收方將不知道接收到的是一個新的分組還是重傳的分組。
rdt2.1中，在ACK/NAK含糊不清時重傳，並使用1bit爲來區分接收到的是新的分組和還是重傳的分組。
rdt2.2中，與rdt 2.1的區別是，沒有NAK反饋，如果發送方接收到了兩個同一分組的ACK之後，就說明接收方爲接收到正確的數據，則會重傳。
\\\\\\\\\\\\\\\\\\ 經有比特差錯和丟包信道的傳輸協議 rdt3.0
rdt 3.0解決的主要問題是：如果發送過程中發生了丟包，接收方將收不到包，也就不可能發送ACK/NAK進行確認，這種情況下，發送方是否需要重傳？
rdt 3.0引入了計時器，在發送方發送一個包時，啓動一個倒計時，如果在倒計時結束還未收到ACK，則重傳該分組。若收到ACK/NAK則中斷計時器。rdt 3.0是可靠數據傳輸協議。
rdt 3.0的FSM如下圖：
發送方：
接收方：
可靠數據傳輸總結：
以下四項爲可靠數據傳輸的四要素。
校驗和：（UDP中就有的）發送方求發送數據的16bit字之和的反碼得到校驗和，將校驗和與數據一同發送到接收方，接收方將受到的數據進行16bit字求和，再加上校驗和，若爲0說明接收到了正確的數據，若不爲0，則說明傳輸過程有bit差錯。
ACK/NAK：（rdt 2.0 加入）肯定確認和否定確認，接收方收到數據之後，用校驗和進行校驗，如果數據正確則回覆ACK，錯誤則回覆NAK。
序號：（rdt 2.1加入）將發送的分組以0和1編號（用發送序號+1 mod 2得到，如第3個發送的包其序號爲4 mod 2=0），該序號只是爲了區分相鄰兩個分組，以及是正常發送還是重傳。
如接收方接收到了序號爲0的分組，反饋一個ACK，但ACK中途丟包，發送方因爲超時而重傳，接收方再次接收到序號爲0的分組，由於此時接收方在等待序號爲1的分組，所有接收方就不會將這個冗餘的分組交付到上層，但仍會回覆該分組的ACK。
定時器：（rdt 3.0加入）傳輸過程中可能存在分組丟失的情況（如路由器緩存滿時，將丟掉後來的包），發送方需要等待接收方確認分組是否丟失，來判斷是否重傳，這段等待時間不是一個定值（因爲網絡時延不確定），有可能等待很久才能收到，甚至超過再重傳一次的時間，所以rdt 3.0加入了定時器，在發送每個分組時啓動一個倒計時，如果在倒計時爲0時還未收到反饋，則重傳給分組。
\\\\\\\\\\\\\\\\\\流水線可靠數據傳輸
rdt 3.0已經實現了可靠數據傳輸，但是它是一個停等協議，即在傳輸過程中需要停下來等待接收方反饋丟包信息。
假設一個分組的傳輸時延（將數據從節點推送到鏈路的時間）爲0.008ms，而往返傳播時延RTT爲30ms，那麼傳輸一個分組，主機需要等待至少30ms的時間，而將分組推送到鏈路只需要0.008ms，這樣主機的利用其實很低。
爲了解決這個性能問題，出現了流水線可靠數據傳輸協議，它不是停等協議，允許發送方發送多個分組而不需要等待確認（儘管最後還是要確認，但不需要等待）。
爲了實現流水線，必須：
增加序號範圍
發送方和接收方緩存多個分組
實現差錯恢復（分組丟失，損壞，延時過大）——回退N步和選擇重傳。
回退N步：
選擇重傳：