原因有二:保證TCP協議的全雙工連線能夠可靠關閉保證這次連線的重複資料段從網路中消失第一點:如果主機1直接CLOSED了,那麼由於IP協議的不可靠性或者是其它網路原因,導致主機2沒有收到主機1最後回覆的ACK
從上面的例項可以看出tcp包的確認是按照最小序列號進行確認的,這種是預設情況,要是在丟包率比較高的場景,使用TCP可以開啟sack選項,這樣就會對每一個包進行確認,而不是確認包序列號的最小值,對每一個包確認後,只需要重傳沒有確認的包,在上面
網路擁塞產生的原因:在沒有任何協商和請求許可機制的共享網路中,幾個IP分組同時到達路由器,並期望經同一個輸出埠轉發,但事實不是所有分組可以同時接受處理,必須有一個服務順序,中間節點上的快取為等候服務的分組提供一定保護
2 TCP BBR演算法基本原理前面我們提到了一些Loss-Based演算法存在的問題,TCP BBR演算法是一種主動式機制,簡單來說BBR演算法不再基於丟包判斷並且也不再使用AIMD線性增乘性減策略來維護擁塞視窗,而是分別取樣估計極大頻寬
2點,方法:TimeoutInterval = EstimatedRTT + 4*DevRTT流水線可靠資料傳輸:提高傳輸速度6.擁塞控制的基本邏輯需要網路擁塞控制的原因:巨大的排隊延時,不必要的重傳,浪費鏈路傳輸容量獲取擁塞狀態的方式:端
TCP在進行流量控制時,以分組的丟失作為產生擁塞的標誌,當然也存在一些其他情況會引起分組丟失:IP資料報分片後,在終點組裝超時,丟棄
原因有二:保證TCP協議的全雙工連線能夠可靠關閉保證這次連線的重複資料段從網路中消失第一點:如果主機1直接CLOSED了,那麼由於IP協議的不可靠性或者是其它網路原因,導致主機2沒有收到主機1最後回覆的ACK
超時重傳在進行TCP傳輸時,由於確認應答與序列號機制,也就是說傳送方傳送一部分資料後,都會等待接收方傳送的ACK報文,並解析ACK報文,判斷資料是否傳輸成功
慢啟動為TCP的傳送方增加了一個擁塞視窗,當連線建立時,擁塞視窗被初始化為一個報文段大小,每收到一個ACK,擁塞視窗就會增加一個報文段,傳送方取擁塞視窗與透過視窗的最小值作為傳送的上限
1.5 滑動視窗、慢開始、擁塞避免、快重傳、快恢復、可靠性、順序傳輸、TCP BBR 擁塞演算法滑動視窗: 滑動視窗協議是用來改善吞吐量的一種技術,即容許傳送方在接收任何應答之前傳送附加的包
TCP傳送方以指數速度增加其傳送速率,直到發生一個丟包事件為止,此時CongWin將被降為一半,然後就會像上面所講的那樣線性地增長
在無損佇列中,我們希望在快取丟包前,能觸發PFC進行反壓,所以在任何情況下,都應該入口PG-Share先到達水線,出口Queue-Share永遠不能到達水線(PG-Share到達會發PFC,Queue-Share到達會丟包)
Acknowledgement of delay通常TCP在收到資料的時候不會立刻傳送一個ACK確認,它會延遲傳送,可以和對方需要的資料一起傳送(資料捎帶ACK)或者是等待第二個資料來了直接回復第二個ACK,通常的實現採用的延遲是200ms
5 弱視窗擁塞機制其實在很多場景是不用擁塞控制或者只要很弱的擁塞控制即可,例如:師生雙方書寫同步、實時遊戲,因為本身的傳輸的資料量不大,只要保證足夠小的延時和可靠性就行,一般會採用固定視窗大小來進行流控,我們在系統中一般採用一個 cwnd
4G+其實就是把兩個頻段的訊號聚合在一起給你用,理論上是可以提升下載速率的,不過現在由於容量不足基本上都是虛設,現在很多地方的4G+就是個圖示,頻寬和其他引數都和4G基本相同,所以基本上是差不多的,但是考慮的4G+的駐留優先順序應該是高於4
如果使用的是兩次握手建立連線,假設有這樣一種場景,客戶端傳送了第一個請求連線並且沒有丟失,只是因為在網路結點中滯留的時間太長了,由於TCP的客戶端遲遲沒有收到確認報文,以為伺服器沒有收到,此時重新向伺服器傳送這條報文,此後客戶端和伺服器經過