淺談通訊網絡（五）——TCP層

需求：

通訊的本質是進行信息的傳遞，而咱們但願達到的效果總結起來就兩點：快而準。

背景：

基於TCP/IP協議，運行在IP層上的流量將變得不可靠，沒法僅僅靠IP層技術保障數據包的準確傳達。

TCP協議

由此誕生了TCP協議來保證數據流量儘快準確的到達。

咱們來看下TCP協議採用了什麼策略來保障的：

 

 

首先是引入了確認機制，也就是在發送到對方後，對方得告知咱們確實收到了。

採用這種機制有一個前提，若是你發送很長一段數據包，須要拆分爲多個數據包進行屢次發送，由此你須要對這些數據包進行標序號，由此告知對方哪一個數據包在前，哪一個數據包在後，再便於TCP/IP協議棧組合以後，再傳達給上層應用程序。另外對方也才能告訴你究竟是哪塊數據包傳送成功了。

好比，A發送了SYN（序列號）爲1~25的數據包給B，B會返回一個ACK（=最大序列號+1），這裏ACK=26。由此B告訴了A本身確實收到了。

疑問：那B如何告知A沒有收到該數據包勒？

採用這種機制，A只有在接收到了ACK以後，纔會發送下一個數據包。若是等待一段時間後，還未收到，將再次從新發送該數據包。

缺陷：雖然保證了無誤的發送，可是明顯這種機制沒法達到快速的發送。

           1.每次發送一個數據包，若是有丟失，須要等一個週期，才能知曉丟包，耗時過久；

           2.ACK實際上是額外的網絡開銷，反覆的發送加重了網絡負擔。

發送優化：

a:

選擇一次性發送多個數據包。

問題：一次性到底可以發送多少數據包呢？會不會發送太多形成對方沒法接收？

最大發送速率（當前窗口大小）取擁塞窗口和通告window窗口的最小值。

b：

由此引入通告window窗口機制，對方反饋本身可以一次性接收多大的數據包大小。（接收端流量控制窗口）

c:

發送方如何告訴對方本身已經將數據包發送完畢了，並清空本地發送緩存，採用將TCP的PUSH字段置一。（涉及伯克利算法）

d：

針對window大小的計算，須要知道發送多少個包，固然發送方得提早知道每一個數據包可以發送多大呢？可以發送的最大值是多少？

針對不一樣的二層網絡，會有不一樣的數據包大小。好比以太網是1500字節，所謂的MTU。由此除去IP和TCP頭部，就是1460字節。

因此TCP協議定義了一個標識位叫MSS，以太網就是1460。也就是以太網接口可以發送的最大數據包大小爲1460字節。

在TCP建聯的時候，不只僅會協商window的大小，同時也會協商MSS的大小。發送方和接收方分別告知對方本身的MSS大小，最後以最小者爲準，來指導發送方發送數據。

缺陷：只是根據雙方的MTU來計算的MSS，並沒有法知曉路徑中網絡設備的MTU大小，若是中間設備的MTU設備相對小些，將可能形成丟包。除非該數據包DF位爲0，而且較小MTU的接口是三層口子，作的是三層轉發。

 

既然咱們談到了中間網路設備，發送的時候，不只僅須要考慮收方的狀況，還要預測二者之間的網絡狀況。到底帶寬是多少，信號是否穩定，咱們並沒有法直接獲知，但能夠採用必定的算法來優化。

e:慢啓動算法

意思是慢慢提升發送數據包的速度，即發送單位時間內發送數據包的個數逐漸增長，指數級增加。

f:擁塞窗口（發送方流量控制）

 前提：

  1. 最大發送速率（當前窗口大小）取擁塞窗口和通告window窗口的最小值。

  2.通常分組丟失，表示有擁塞。通常分組丟失有兩種方式：

       I.發送超時（意思是發送了，可是超過一段時間未收到ACK）；

       II.收到重複ACK（詳情見後面解釋）

處理過程：

 擁塞窗口初始值是1個報文段，每收到一個ACK就增長一個報文段大小。

 因爲最大發送速率前期主要受限於擁塞窗口。所以很容易獲得擁塞窗口是以2爲底的指數級增加。

 但這個最大發送速率的增加，在慢啓動算法裏面，有一個閾值，叫慢啓動門限ssthresh,默認值是65535字節。

 當發送擁塞的時候，ssthresh會取值爲當前窗口的一半（前面已經說了，該值取擁塞窗口和window窗口的最小值），並考慮是否將擁塞窗口置1（具體請看如下快速恢復算法）

 當未有擁塞，速率大小（當前最大速率大小或者叫當前窗口）超過ssthresh時候，進入擁塞避免階段，擁塞窗口將從指數級增加，變爲RRT時間內遞增長1的線性增加。由此速率也會進入線性增加的過程，直到等於通告窗口。

g:快速恢復算法

  當收到重複ACK後，擁塞窗口並不置1，進入慢啓動。而是直接進入擁塞避免。這就是快速恢復算法。

 可是若是是超時的擁塞，擁塞窗口將置1，從新進入慢啓動。

接收端優化：

a：

ACK附帶數據包發送。

接收數據方,也每每須要發送數據包，在發送數據包的時候，將ACK附帶一塊兒發送出去。

b.

經受延遲的ACK。

接收方在接收到數據後，並不當即發送ACK給發送方。己方有數據發送除外。通常採用的是等待200ms再發送最後一個ACK。

 好處：

能夠減小ACK的數據包量；

可是重複ACK將不會被延遲，而是會當即發送。

c.

 重複ACK（快速重傳算法）

當接收方發如今當前收到數據包裏序列號前的數據包，並無收到。則會將上次發送的ACK反饋給對方。由此告知對方兩個信息：

1.上次成功收到序列號後的數據我沒有正確收到；2.你須要從新給我發送後續的數據包給我（通常就發送該ACK後的一個數據包，也就是丟失的數據包，不從新發送其餘後續的數據包）。

     按照伯裏克實現，其實發送方在收到三個重複ACK纔會從新發送數據。緣由是擔憂只是因爲亂序形成的。而不是真實的丟包。

 

其餘

 

naglle算法，

一個TCP鏈接上最多隻能有一個未被確認的未完成的小數據包，在該數據包被確認前，不容許再次發送其餘小分組。

本算法理論上能夠提升互聯網效率，可是卻減慢了本地的發送速率。特別是在電腦上的人機交互設備上是必須關閉的。

 

疑問：

同一個鏈接，若是接收方未及時將數據包上傳給上層應用程序，好比因爲性能瓶頸，上層應用程序還將來得及獲取數據包，而發送方又發來了數據。應該如何處理呢？ 

解答：

1.接收方正常反饋ACK的時候，帶上當前window=最大window-當前已佔用緩存大小（通常爲0，但也可能出現錯誤包等，形成的非0狀況）；

2.發送方收到後，將調整發送數據爲更新後的window

（若是爲0，則不會發送，直到收到接收方發過來新的window窗口大小）

 

 

三次握手，四次斷鏈（略)

 

 RRT關於時間戳(通常用於擔憂SYN反轉)等（略）

 

RST主動快速斷鏈或者拒絕建鏈

 

URG（略）

 

TCP的四個定時器

重傳定時器、堅持定時器、保活定時器、2MSL定時器

 

華爲、思科等公司優化算法（再續）

 

引讀：https://user.qzone.qq.com/656272330/blog/1438714718