計算機網絡自頂向下方法第3章-傳輸層 (Transport Layer).2

3.5 面向鏈接的運輸: TCP

　　3.5.1 TCP鏈接

• TCP是因特網運輸層的面向鏈接的可靠的運輸協議。
• TCP鏈接提供全雙工服務（full-duplex service）.
• TCP鏈接是點對點的鏈接.

　　1).最大報文段長度（Maximum Segment Size,MSS）:該術語很容易被混淆，它其實指的是報文段裏應用數據的最大長度，而不是包括TCP首部的TCP報文段的最大長度。

　　2).最大傳輸單元（Maximun Transmission Unit,MTU）:指的是最大鏈路層幀長度，即應用數據+TCP首部+IP首部.

　　3.5.2 TCP報文段結構

　　

　　1.序號和確認號。

　　

　　在TCP協議中，序號是對應用層所要發送的數據的字節流的編號，而不是對報文段的編號。舉例來講，進程A想要想進程B發送50000字節的數據，而其MSS爲1000字節。那麼，在TCP協議中，第一個報文段的序號是0，第二個報文段的序號是1000，第三個報文段的序號是2000......以此類推。序號表示的是：當前的報文段中應用層數據的首個字節在整個字節流中的位置。
　　

　　TCP鏈接是全雙工的，當主機A向主機B發送數據的同時，也有可能受到來自主機B的數據。舉例來講，A收到了B發送的0~535的報文，同時它打算髮送一個報文給B，那它的發送的這條報文的確認號將爲536，表示它但願下一個接收到的報文的第一個序號是536 （固然，這條報文的初始序號是主機A本身隨機選擇的，好比0）

　　2.Telnet : 序號與確認號的一個學習案例。

　　假設客戶端A的起始序號是42，服務器B的起始序號是79。在客戶端中中輸入一個字符‘c’，那麼從A發出的報文應該是一個序號=42，確認號=79，data='c' 的TCP報文（前面說過，確認號指的是期待收到的下一個字節序號。在雙方還沒開始互發數據以前，客戶端A等待的是79，而服務端B等待的是42）

　　

　　3.5.3 往返時間的估計與超時

　　1.估計往返時間

　　報文段的「樣本RTT」（SampleRTT）就是指某報文段被髮出到該報文段的確認被收到的時間間隔。TCP維護一個SampleRTT的均值EstimatedRTT，每次收到一個新的SampleRTT,就對這個EstimatedRTT進行更新，「RTT誤差」（DevRTT）用於估算SampleRTT偏離EstimateRTT的程度

　　2.設置和管理重傳超時間隔

　　3.5.4 可靠數據傳輸

　　因爲TCP是在IP不可靠的、盡力而爲的服務上創建的一種可靠數據傳輸協議，即確保接收端從其接受緩存中讀取到的數據是無損壞、無間隔、非冗餘和按序的。但TCP的報文是被IP數據報攜帶着在網絡中傳輸的，有可能會出現比特錯誤、丟包。失序到達等問題，TCP如何保證數據的可靠性呢？

　　1. 在TCP的接收端，維護一個nextrcvseqnum變量，保存接收端下一個要接收的最小有序的報文段的序號。

　　①當接受到的報文的是正確的而且序號爲nextrcvseqnum時，更新接收端的nextrcvseqnum，使nextrcvseqnum = nextrcvseqnum+sizeof(接收到的數據），回送確認號爲nextrcvseqnum的ACK

　　②當接收到的報文是正確的，當序號>nextrcvseqnum時，先將這個報文緩存起來，而後繼續回覆確認號爲nextrcvseqnum的ACK告訴發送方本身如今最想要的是序號爲nextrcvseqnum的報文。 

　　③當接收到的報文是正確的，但序號<nextrcvseqnum時，接收端丟棄這個報文，並回復確認號爲nextrcvseqnum的ACK

　　④當接受到的報文是錯誤的，則無論序號是什麼，接收端丟棄這個報文，並回復確認號爲nextrcvseqnum的ACK

　　2. 在TCP的發送端，須要爲最先發送、未被確認的報文段維護一個baseSend變量來保存其序號和一個定時器來記錄其等待時間是否超時。

　　①當發送端接收到一個確認序號num>baseSend的ACK報文，那麼，因爲TCP採用的是累積確認機制，因此發送方知道序號<=num的報文都已經正確到達接收端了。因此發送端更新最先發送、未被確認的序號baseSend=num。若是當前還有未被確認的報文段，TCP還要從新啓動定時器。

　　②當發送端接收到一個確認序號=baseSend的ACK報文（當確認序號=baseSend時，說明接收方是爲baseSend的上一個報文回送的ACK）時，它的定時器會繼續運行，並統計接收到的冗餘ACK的數量。當接收到對相同數據的3個冗餘ACK時，發送方不等定時器的超時時間，直接快速重傳序號爲baseSend的ACK報文（能夠減小等待超時的時間，提高性能），並從新啓動定時器。

　　③當發送端接收到一個序號<baseSend的ACK報文，直接忽視（這個報文可能在網絡中延遲了，比較晚到達，而比它晚的累計確認報文已經到了，因此它沒有意義了）

　　④當發送端的定時器過時時，尚未收到序號>baseSend的ACK，則發送端重傳序號爲baseSend的報文，並將定時器的值增長一倍。

　　TCP的可靠數據傳輸協議是在GBN的基礎上，進行了改造。首先，GBN的接收端不會存儲任何失序報文，因此GBN遇到超時事件會直接重傳全部未被確認的報文，而TCP中只需重傳最小未被確認的報文便可；其次，在TCP中加入了冗餘ACK機制，能夠實現快速重傳，沒必要每次都等待漫長的超時事件的發生。兩者大大提升了傳輸協議的總體性能。　　

　　3.5.5 流量控制

　　TCP爲它的應用程序提供了流量控制服務（flow-control service）以消除發送方使接收方緩存溢出的可能性（TCP的發送端也有可能由於IP網絡的擁塞而被遏制，這種形式的控制成爲擁塞控制（congestion control)）

　　3.5.6 TCP 鏈接管理

　　1. TCP鏈接的創建：客戶端發起

　　TCP鏈接的創建也成爲三次握手協議，經過如下三個步驟：

　　（1）首先，客戶端想服務端發送一個特殊的「SYN報文」，這個報文不包含應用數據，但其首部的一個標誌位SYN被置爲1。另外，客戶端會隨機選擇一個初始序號client_isn,並將此編號放入報文的序號字段中；

　　（2）一旦服務器接收到SYN報文，服務器爲TCP鏈接分配TCP緩存和變量，並向客戶TCP發送容許鏈接的SYNACK報文。在SYNACK報文中，SYN比特被置爲1，首部的確認字段被置爲client_isn+1,最後，服務器選擇本身的隨機起始序號server_isn，放入序號段中。

　　（3）在收到SYNACK後，客戶端也要爲本身的TCP鏈接分配TCP緩存和變量，而且向服務器發送一個報文，這個報文是對服務器的容許鏈接的一個確認。這個報文段的確認字段爲server_isn+1；而因爲此時鏈接已經創建，因此SYN比特被置爲0。而且，在這個報文段裏，能夠攜帶應用層數據。
　　 

　　

　　2. TCP鏈接的拆除，四次揮手

　　參與TCP鏈接的兩個進程中的任意一個都能終止該鏈接。假設客戶端打算終止鏈接：

　　（1）客戶TCP向服務器進程發送一個特殊的報文，這個報文首部的FIN標誌位被置爲1；

　　（2）當服務器接收到這個報文時，他發送一個回送ACK報文

　　（3）服務器發送它的終止報文，其FIN標誌位被置爲1

　　（4）最後，該客戶對服務器的終止報文進行確認。此時，這兩臺主機上用於該鏈接的全部資源都被釋放了。
　　

3.6 擁塞控制原理

　　3.6.1 擁塞緣由與代價

•  網絡傳輸中某些數據的丟失是由於網絡的擁塞而致使的路由器的緩衝區的溢出而形成的。
•  當分組到達的速率接近鏈路容量的時候，會產生很大的隊列等待延遲。
•  發送方爲了對路由器緩衝區溢出所產生的分組丟失作出補償，就必須執行數據的重發操做。
•  當發生超長時間延遲時，發送方所進行的重傳操做可能會致使路由器浪費其帶寬去傳送一些沒必要要的分組副本。
•  當一個分組在傳送路徑中丟失，那麼前面全部發送過該分組的、一直到丟失該分組的路由器所作的傳輸工做就都浪費了。

　　3.6.2 擁塞控制方法

• 端到端的擁塞控制
• 網絡層發生做用的擁塞控制

3.7 TCP 擁塞控制

　　TCP 的擁塞控制主要來避免兩種現象，包丟失和超時重傳。一旦出現了這些現象就說明，發送速度太快了，要慢一點。TCP的擁塞控制主要原理依賴於一個擁塞窗口(cwnd)來控制　　

　　1.慢啓動

　　最初的TCP在鏈接創建成功後會向網絡中發送大量的數據包，這樣很容易致使網絡中路由器緩存空間耗盡，從而發生擁塞。所以新創建的鏈接不可以一開始就大量發送數據包，而只能根據網絡狀況逐步增長每次發送的數據量，以免上述現象的發生。具體來講，當新建鏈接時，cwnd初始化爲1個最大報文段(MSS)大小，發送端開始按照擁塞窗口大小發送數據，每當有一個報文段被確認，cwnd就增長1個MSS大小。這樣cwnd的值就隨着網絡往返時間(Round Trip Time,RTT)呈指數級增加，事實上，慢啓動的速度一點也不慢，只是它的起點比較低一點而已。

　　一條 TCP 鏈接開始，cwnd 設置爲一個報文段，一次只能發送一個；當收到這一個確認的時候，cwnd 加一，因而一次可以發送兩個；當這兩個的確認到來的時候，每一個確認 cwnd 加一，兩個確認 cwnd 加二，因而一次可以發送四個；當這四個的確認到來的時候，每一個確認 cwnd 加一，四個確認 cwnd 加四，因而一次可以發送八個。能夠看出這是指數性的增加。

　　2.擁塞避免

　　從慢啓動能夠看到，cwnd能夠很快的增加上來，從而最大程度利用網絡帶寬資源，可是cwnd不能一直這樣無限增加下去，必定須要某個限制。TCP使用了一個叫慢啓動門限(ssthresh)的變量，當cwnd超過該值後，慢啓動過程結束，進入擁塞避免階段。對於大多數TCP實現來講，ssthresh的值是65536(一樣以字節計算)。擁塞避免的主要思想是加法增大，也就是cwnd的值再也不指數級往上升，開始加法增長。此時當窗口中全部的報文段都被確認時，cwnd的大小加1，cwnd的值就隨着RTT開始線性增長，這樣就能夠避免增加過快致使網絡擁塞，慢慢的增長調整到網絡的最佳值。

　　漲到何時是個頭呢？有一個值 ssthresh 爲 65535 個字節，當超過這個值的時候，就要當心一點了，不能倒這麼快了，可能快滿了，再慢下來。 每收到一個確認後，cwnd 增長 1/cwnd，咱們接着上面的過程來，一次發送八個，當八個確認到來的時候，每一個確認增長 1/8，八個確認一共 cwnd 增長 1，因而一次可以發送九個，變成了線性增加。

　　3.快速重傳與快速恢復

　　擁塞的一種表現形式是丟包，須要超時重傳，這個時候，將 sshresh 設爲 cwnd/2，將 cwnd 設爲 1，從新開始慢啓動。這真是一旦超時重傳，立刻回到解放前。可是這種方式太激進了，將一個高速的傳輸速度一會兒停了下來，會形成網絡卡頓。快速重傳算法：當接收端發現丟了一箇中間包的時候，發送三次前一個包的 ACK，因而發送端就會快速的重傳，沒必要等待超時再重傳。TCP 認爲這種狀況不嚴重，由於大部分沒丟，只丟了一小部分，cwnd 減半爲 cwnd/2，而後 sshthresh = cwnd，當三個包返回的時候，cwnd = sshthresh + 3，也就是沒有一晚上回到解放前，而是還在比較高的值，呈線性增加。

參考

　　https://blog.csdn.net/qq_36464448/article/details/80409476 

　　https://blog.csdn.net/peijian1998/article/details/25684937 

　　https://blog.csdn.net/itmacar/article/details/12278769