TCP協議(上）中. 他講述了其保證算法
包順序發送(TCP頭的第二行序號)緩存
包丟失會重傳(第三行有確認序號.響應超時會重發)網絡
擁塞控制
擁塞控制.對客戶端：它要保證發送的頻率,若是太快會撐死，太慢卻沒有物盡其用！對服務端：她得告訴對方本身的效率是多少(一次能處理多少個請求分別多少時間.若是超出本身的範疇直接不接收這就致使丟包)spa
咱們怎麼知道服務端的極限呢，咱們能夠看到TCP頭的第四行-16位窗口大小.叫Advertised window。超過這個窗口大小服務端就作不來這時客戶端就別再發送了.blog
客戶端四種狀態
1.已發送並已確認class
2.已發送但未確認效率
3.未發送待發送(可發送）sed
4.未發送不發送(不可發送)請求
這裏窗口大小爲二、3狀態的合(即上圖紫色部分的總和)程序
服務端三種狀態
1.已確認.等待應用程序處理
2.已收到.但未確認
3.還沒有收到
理想狀況下,上述就能在網絡中完整的傳輸.但現實每每是很骨感的。
好比客戶端是連續發送的包.有的包丟了(壓根沒到服務端).
有的包服務端收到了並進行ACK但途中丟了(這時服務端又得重發).
再者網絡狀態不穩定的狀況.也要適當的調整窗口大小
客戶端發送的包若是沒有回覆就會超時重試.那超時時間如何取值呢.這時間必須大於往返時間RTT的值.不然會引發沒必要要的重傳.也不宜過長，這樣訪問就變慢了.
這時就要用到自適應重傳算法：採樣RTT的波動範圍，計算並估計一個超時的時間。
流量控制問題
咱們在對於包的確認中，同時會攜帶一個窗口的大小.好比窗口大小爲9.即確保二、3狀態(已發送未確認、待發送)總和爲9便可
當有一些極端狀況，好比服務端發送一個確認包.卻不讀取緩存的包，這時窗口應設置爲8.若是這樣下去.窗口最後變爲0了.客戶端直接啥都不用作。這時客戶端會定時發送探測數據包.看服務端是否調整了窗口的大小以便繼續發包出去
擁塞控制問題
最後的擁塞控制，也是經過窗口的大小來控制的，
前面的滑動窗口rwnd是怕發送方把接收方緩存塞滿，用擁塞窗口cwnd，是怕把網絡塞滿