tcpdump如何判斷丟包 TCP如何保證可靠性?

2021-10-11 03:17:50 字數 2165 閱讀 1150

tcp協議傳輸的特點主要就是面向位元組流、傳輸可靠、面向連線。本篇文章,我們就重點討論一下tcp協議如何確保傳輸的可靠性的。

tcp協議保證資料傳輸可靠性的方式主要有:

1. 校驗和

2. 序列號

3. 確認應答

4. 超時重傳

5. 連線管理

6. 流量控制

7. 擁塞控制

序列號:tcp傳輸時將每個位元組的資料都進行了編號,這就是序列號。

確認應答:tcp傳輸的過程中,每次接收方收到資料後,都會對傳輸方進行確認應答。也就是傳送ack報文。這個ack報文當中帶有對應的確認序列號,告訴傳送方,接收到了哪些資料,下一次的資料從**發。

序列號的作用不僅僅是應答的作用,有了序列號能夠將接收到的資料根據序列號排序,並且去掉重複序列號的資料。這也是tcp傳輸可靠性的保證之一。

在進行tcp傳輸時,由於確認應答與序列號機制,也就是說傳送方傳送一部分資料後,都會等待接收方傳送的ack報文,並解析ack報文,判斷資料是否傳輸成功。如果傳送方傳送完資料後,遲遲沒有等到接收方的ack報文,這該怎麼辦呢?而沒有收到ack報文的原因可能是什麼呢?

傳送方沒有接收到ack響應的原因:其中一方出現了網路問題。

1. 資料傳送方:資料傳送過程中有由於網路問題全體丟包,接收方根本沒有收到資料。

2. 資料接收方:資料拿到了。但是傳送ack報文的時候由於網路問題,傳送失敗。

為了解決丟包問題導致的【確認應答、序列號】機制失效,tcp引入了超時重傳機制。簡單的理解就是在傳送方傳送資料後的一段時候內,如果沒有接收到接收方的ack響應,那麼剛剛傳送的資料需要重新傳送。對應上面說到的兩種原因,如果是資料發方的問題,資料重新傳送,資料接收方進行響應ack;如果是資料接收方的問題,資料傳送過來之後,接收方根據序列號判斷是否是重複資料,如果是直接丟棄,然後繼續返回ack響應。

那麼傳送方傳送完畢後等待的時間是多少呢?如果這個等待的時間過長,那麼會影響tcp傳輸的整體效率,如果等待時間過短,又會導致頻繁的傳送重複的包。如何權衡?

由於tcp傳輸時保證能夠在任何環境下都有乙個高效能的通訊,因此這個最大超時時間(也就是等待的時間)是動態計算的。

接收端在接收到資料後,對其進行處理。如果傳送端的傳送速度太快,導致接收端的結束緩衝區很快的填充滿了。此時如果傳送端仍舊傳送資料,那麼接下來傳送的資料都會丟包,繼而導致丟包的一系列連鎖反應,超時重傳呀什麼的。而tcp根據接收端對資料的處理能力,決定傳送端的傳送速度,這個機制就是流量控制。

在tcp協議的報頭資訊當中,有乙個16位字段的視窗大小。在介紹這個視窗大小時我們知道,視窗大小的內容實際上是接收端接收資料緩衝區的剩餘大小。這個數字越大,證明接收端接收緩衝區的剩餘空間越大,網路的吞吐量越大。接收端會在確認應答傳送ack報文時,將自己的即時視窗大小填入,並跟隨ack報文一起傳送過去。而傳送方根據ack報文裡的視窗大小的值的改變進而改變自己的傳送速度。如果接收到視窗大小的值為0,那麼傳送方將停止傳送資料。並定期的向接收端傳送視窗探測資料段,讓接收端把視窗大小告訴傳送端。

關於tcp流量控制以及在 flink 中是如何實現的,可以參考這篇培訓:

tcp傳輸的過程中,傳送端開始傳送資料的時候,如果剛開始就傳送大量的資料,那麼就可能造成一些問題。網路可能在開始的時候就很擁堵,如果給網路中在扔出大量資料,那麼這個擁堵就會加劇。擁堵的加劇就會產生大量的丟包,就對大量的超時重傳,嚴重影響傳輸。

所以tcp引入了慢啟動的機制,在開始傳送資料時,先傳送少量的資料探路。探清當前的網路狀態如何,再決定多大的速度進行傳輸。這時候就引入乙個叫做擁塞視窗的概念。傳送剛開始定義擁塞視窗為 1,每次收到ack應答,擁塞視窗加 1。在傳送資料之前,首先將擁塞視窗與接收端反饋的視窗大小比對,取較小的值作為實際傳送的視窗。

擁塞視窗的增長是指數級別的。慢啟動的機制只是說明在開始的時候傳送的少,傳送的慢,但是增長的速度是非常快的。為了控制擁塞視窗的增長,不能使擁塞視窗單純的加倍,設定乙個擁塞視窗的閾值,當擁塞視窗大小超過閾值時,不能再按照指數來增長,而是線性的增長。在慢啟動開始的時候,慢啟動的閾值等於視窗的最大值,一旦造成網路擁塞,發生超時重傳時,慢啟動的閾值會為原來的一半(這裡的原來指的是發生網路擁塞時擁塞視窗的大小),同時擁塞視窗重置為 1。

tcpdump丟包問題解決方法

近日用tcpdump抓包,發現有大量的丟包出現 packets dropped by kernel 如下 tcpdump i eth0 dst port 1234 and udp s 2048 x tt a.pack 264 packets captured 3043 packets receive...

WebRTC研究 audio 丟包判斷

當收到乙個包時,丟包判斷原理 sequence number 當前收到的包的序列號 timestamp 當前收到的包的時間戳 void nacktracker updatelastreceivedpacket uint16 t sequence number,uint32 t timestamp r...

解決網路丟包及故障判斷方法

我們首先來認識一下什麼是丟包,以及什麼樣的現象被成為是網路丟包 接下來我們來看如何確認 檢測以及解決丟包故障 常見的測試丟包的方法是通過使用ping命令進行測試,如圖所示,request timed out.表示此刻發生丟包故障。reply from 220.181.6.19 bytes 32 ti...