趣談網絡協議(十二):TCP協議(下)

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,是怕把網絡塞滿

相關文章
相關標籤/搜索