前言
傳輸層是面向通信部分的最頂層，是面向應用的最底層。面向通信部分，距離傳輸層最近的網絡層，因此本文會將傳輸層與網絡層在必要時候進行對比。
傳輸層作用：
網絡層提供的是主機之間的邏輯通信，而傳輸層提供的是通信雙方的進程之間的邏輯通信。傳輸層爲應用屏蔽了底層複雜的網絡通信邏輯，簡單易用。
如上圖所示，網絡層提供主機之間的通信，傳輸層提供進程間的通信，有端口標誌通信的目標進行。
差錯檢測：
網絡層的檢錯檢測只是對網絡層的首部進行檢驗是否出差錯，不檢驗數據部分。運輸層需要對報文進行差錯檢測。
傳輸層主要協議：
傳輸層主要的協議分別：1、UDP協議；2、TCP協議。兩個通信端之間傳輸數據的單位叫做：傳輸協議數據單元。在UDP中爲：UDP用戶數據包、在TCP中爲TCP報文段。
1：UDP是無連接的通信協議，因此沒有連接管理，在一些場景下非常高效，實時性要求高的場景下使用UDP協議，並且可以自行實現一些可靠傳輸邏輯實現可靠傳輸。UDP支持廣播與多播。UDP特點如下：面向無連接的，盡最大努力交付，面向報文的，UDP沒有擁塞控制，UDP支持一對一，一對多以及多多對的交互通信，UDP首部開銷很小。雖然UDP沒有擁塞控制，但是當很多主機向網絡發送高速率的視頻流時，網絡就可能發送擁塞，導致大家都無法正常接收，因此不適用擁塞控制的UDP可能會發生嚴重的擁塞問題。UDP首部結構圖：
2：TCP是面向連接的服務，在傳輸數據之前必須建立連接，通信完畢釋放連接，TCP不提供廣播與多播服務；由於TCP提供可靠的，面向連接的傳輸服務，因此需要增加許多開銷，例如：確認、流量控制、計時器以及連接管理等。使用確認與重傳機制就可以在不可靠的網絡通道實現可靠傳輸。
備註：
當運輸層採用的是TCP協議時候，儘管下面的網絡是不可靠的，但是會盡最大努力交付，這種邏輯通信信道就是一條全雙工的可靠信道。當傳輸層使用UDP時候，下面是一條不可靠的信道。
TCP可靠傳輸原理
TCP下面的網絡所提供的傳輸是不可靠的，因此爲了提供可靠傳輸就需要採取措施保證可靠傳輸。理想的傳輸條件兩個：
1、傳輸信道不會產生差錯；
2、不管發送方以多快的速度發送數據，接收方總是來得及接受並處理數據。
但是實際上，網絡無法滿足理想的傳輸條件，因此就需要使用可靠傳輸協議：當接收方遇見差錯數據時，讓發送方重新發送這些出錯的數據；同時當接收方無法及時處理髮送方發送數據時候，及時告訴發送方降低發送數據的速度。這樣不可靠的信道就可以實現可靠傳輸了。
停止等待協議：
停止等待協議就是每發送一個分組就停止發送，等待對方確認。在等待收到對方的確認之後再發下一個數據包。
TCP傳輸數據時，無差錯情況下存在如下兩種情況，分別是確認正常收到與確認丟失，如下所示：
當接收到端發出去的確認丟失時候，發送端的計時器會啓動超時重傳，再一次發送該數據包。
TCP傳輸數據時，發送數據包出差錯情況下存在如下兩種情況，分別是接收到收到一個損壞的數據包，另一種是數據包丟失。兩種處理情況分別如下：
當收到一個損壞的數據包時候，接收方會丟棄什麼也不做，等待發送端超時重傳。另一種情況就是數據包丟失，此時也是觸發超時重傳。
TCP傳輸數據時，確認數據包的遲到丟失，發送方的處理如下兩種。
如果接收方的確認數據包丟失的話，客戶端會觸發超時重傳機制，發送方再次發送該數據包，接收到重複接收到該數據包直接丟棄，並再次發送該數據包的確認。如果接收到接收到數據之後發送的確認遲到了，此時客戶端會觸發超時重傳，並且接收方再次發送報文，接收方發現重複丟失，直接丟失並且向發送方發送確認。當發送端接收到遲到的確認之後，會直接丟失什麼也不做。過程如上圖所示。
停止等待協議需要注意如下三點：
a：發送方發送一個分組之後必須保留已經發送的分組，在超時重傳時候使用，當收到確認時候可以丟失該數據包。
b：分組與確認分組進行編號，這樣才能明確發送的數據包與確認數據包的對應關係。
c：發送端超時重傳的時間設置，通常應該比分組傳輸的平均往返時間設置更長一些。設置的時間過長的話，通信的效率就會很低，但是如果設置的時間過短的話，就會導致大量的不必要的重傳。超時重傳的時間設置還需要結合當時網絡的擁塞程度設置。
但是停止等待協議也存在缺點：就是信道利用率太低，如下圖所示：
爲了提高信道利用率，發送方可以不適用低效率的停止等待協議，而是採用流水線傳輸。流水線傳輸就是發送方連續發送多個分組，不必沒法玩一個分組就停止等待確認。這樣就可以保證信道上一直有數據在傳送。顯然這種方式可以提高信道的利用率。
當使用流水線傳輸時，就需要使用下面的連續ARQ協議與滑動窗口協議。
連續ARQ（Automatic Repeat reQuest）協議：指發送方維持着一個一定大小的發送窗口，位於發送窗口內的所有分組都可連續發送出去，而中途不需要等待對方的確認。這樣信道的利用率就提高了。而發送方每收到一個確認就把發送窗口向前滑動一個分組的位置。
連續ARQ協議規定，發送方沒接受到一個確認，就會把發送窗口向前滑動一個分組的位置。接收方一般採用積累確認的方式，也就是說接收方不必對接收到的分組逐個發送確認，對於按序到達的最後一個分組發送確認即可（注意：按序到達的分組的最後一個）。這就表示之前的所有的分組都已經正確收到。這樣也存在問題：例如發送方報送的數據包序號分別是：1，2，3，4，5；但是接收到接收到了：1，2，4，5；此時接收端只能對1，2發送確認（實際是對2發送確認，表示2之前的數據包都已經正確接收到），這個就叫做：Go-Back-N問題。表示需要回退重發已經發過的N個分組，可見，當網絡環境比較差的時候，自動ARQ會帶來負面影響。
而滑動窗口協議比較複雜，是TCP協議精髓所在。
超時重傳時間的選擇
上面已經提過，當在指定的時間沒有收到數據包的確認時候就需要觸發超時重傳以達到可靠傳輸，但是超時重傳的時間選擇是一個複雜的問題。TCP採用一種自適應算法，它記錄一個報文段的發出時間，以及收到的確認時間，這兩個時間差則是報文段的往返時間RTT。TCP保留了RTT的一個加權平均往返時間RTTs（又叫做平滑的往返時間）。
TCP的流量控制
一般來說，我們都希望數據傳輸的快一些，但是如果發送方發送的過快，接收方就可能來不及接收，這就造成數據的丟失。所謂的流量控制就是讓發送方的發送速率不要太快，要讓接收方來得及接收。
當發送方向接收方發送數據時候，在建立連接時候接收方會告訴發送方：“接收方當前的接收窗口大小，即rwnd大小”，因此發送方的發送窗口就不能超過接收方的rwnd大小。此處注意：TCP的窗口單位是字節，不是報文段。在協商rwnd時候容易發送死鎖，因此需要考慮處理情況，具體如下：發送方項接收方發送報文一段時間之後，接受方回饋的rwnd大小爲0，此時發送方的發送窗口大小則需要調整爲0；隨着接收方數據的處理，有了接受的空間，接收方調整rwnd不爲0之後，此時接收方需要通知發送方調整發送窗口並且發送數據，但是由於通知rwnd不爲0的數據包丟失了，此時就會陷入死鎖，即：接收方等待發送方的rwnd不爲0的數據包，而接收方等待發送方發送數據。爲了解決這個問題需要如下方案：
爲了解決rwnd=0選入死鎖問題，TCP爲發送方設置一個持續計時器，只要發送方接收到rwnd=0時候，就啓動該計時器，每當計時器超時的時候便會發送一個探測報文段，而接收方接收到這個探測報文段時候就會將自己當前的rwnd發送給發送方，這樣就可以打破死鎖的僵局了。
如何提高TCP的傳輸效率
如何控制TCP發送報文段的時機決定了TCP的傳輸效率問題，其實就是TCP何時將緩存區的數據發送出去，TCP傳輸效率解決方案：
1、最大報文段長度；
2、應用進程指明發送，即TCP支持推送的方式，PUSH方式；
3、設置一個計時器，當計時器到期則發送出去。
在TCP實現中廣泛使用的算法是Nagle，算法過程如下：
發送方把應用進程發送的數據逐個字節地發送到TCP緩衝區，則發送方先將第一個字節發送出去，然後把後面到達的字節緩存起來。當發送方收到對一個數據包的確認之後，再將緩衝區中的所有數據組裝成一個報文段發送出去，同事繼續緩存進程傳來的數據。這種情況只有收到前一個報文段的確認才發送下一個報文段，這對於網絡比較慢時，明顯可以減少網絡帶寬的使用，因此Nagle算法還規定：當到達的數據到達發送窗口的一半或者達到報文段的最大長度時，就立即報送出去，這樣可以提高網絡的吞吐率。
TCP擁塞控制（注意與流量控制的區別：流量控制是接收方來不及處理髮送方的數據，流量控制是端與端的通信量控制；而擁塞控制是避免大量報文段涌入網絡中，導致網絡中的路由器或者鏈路過載）。
如何判斷出現了網絡擁塞：
隨着網絡負載的增大，網絡的吞吐率越來越低，這就是出現了網絡擁塞。
TCP擁塞控制的一般原理：
在計算機網絡中的鏈路容量（即帶寬）、交換節點中的緩存以及處理機等都是網絡的資源。在某段時間，若對網絡中某一資源的需要超過該資源所能提供的可用部分，網絡的性能就要變壞。這種情況就是擁塞；網絡擁塞的條件關係如下：
網絡中許多資源同時呈現不足的時候，網絡的性能會明顯變壞，整個網絡的性能會隨着輸入符合增大而下降。而所謂的網絡擁塞控制就是防止過多的數據注入到網絡中，這樣可以避免網絡中的路由器或者鏈路不至於過載。
TCP擁塞控制方法：1、慢開始；2、擁塞避免；3、快重傳；4、快恢復。
（1）慢開始
下面討論的擁塞控制也是基於窗口的擁塞控制，爲此，發送方位置一個叫做擁塞窗口cwnd（congestion window）。擁塞窗口的大小取決於網絡的擁塞程度，並且動態的變化，發送方讓自己的發送窗口等於擁塞窗口。
發送方控制擁塞窗口的原則是：只要網絡沒有出現擁塞，擁塞窗口就可以再增大一些，以便讓更多分組發送出去，這樣可以提高網絡的利用率。但是網絡出現擁塞的時候，就要將擁塞窗口減小一些，以減少數據注入網絡中，減緩網絡擁塞。
慢開始思路如下：
當主機發送數據時候，由於不知道網絡的擁塞情況，如果立即將大量數據注入網絡可能會引起網絡擁塞；經驗證明，最好的辦法是先探測一下網絡情況，即由小到到大逐漸增大發送窗口，也就是說由小到大逐漸增大擁塞窗口數值。
慢開始所謂的慢並不是增長速度慢，而是起步慢，最開始cwnd=1，然後逐漸增長。
擁塞避免算法思路：讓擁塞窗口cwnd緩慢增大，之前慢開始是2倍增長，此時是每一次進行+1，按照加法增大。
開重傳思路：讓發送方儘可能早的知道個別報文的丟失；快重傳思路主要是讓接收方不要等待自己發送數據時候進行捎帶確認，而是立即發送確認。例如對於報文段m2收到三次重複確認，則發送方可以確認接收方沒有收到m3,則立即重傳m3，這樣不用等待超時重傳了；這樣可以提高網絡吞吐率。
快恢復：當知道只是丟失個別報文，於是不啓動慢開始，而是執行快恢復方法，此時發送方調整門限值爲擁塞窗口值的一半。如下圖4的位置就是丟失個別報文（因爲受到3次確認）。
TCP的連接管理
TCP是面向連接的通信，因此通信之前需要進行連接的建立，通信完成之後釋放連接。
TCP建立連接：
爲什麼連接需要三次握手，而不是兩次呢？如果兩次的話可能存在服務器佔用大量連接資源無法得以釋放。具體如下：
例如稀有兩次連接的話，會發生如下情景：
A發起連接，B接收連接，向A發送一個確認，但是此時，確認丟失，A誤以爲連接失敗。但是實際上此時A與B已經成功建立連接。此時由於A沒有感知到連接建立成功，A會繼續發起連接建立的請求，直至連接建立成功。如上過程中，那些沒有收到建立連接的ACK的連接都無法得以釋放，一直佔用服務器資源。
連接的釋放：
Http權威指南中TCP學習筆記：
https://github.com/javartisan/javartisan-resources/blob/master/ht.pptx
參考：計算機網絡（第七版）謝希仁、 Http權威指南 David Gourley