?
TCP協(xié)議的可靠性
數(shù)據(jù)包丟失是對網(wǎng)絡的破壞,因為它導致延遲。TCP協(xié)議建立了可靠的數(shù)據(jù)傳輸,但掩蓋了丟包的影響。TCP確保數(shù)據(jù)的傳輸是基于一個叫做 "滑動窗口 "的概念。這種機制控制著傳輸?shù)淖止?jié)序列和收到的確認。
在排序的幫助下,接收方可以通知發(fā)送方丟失的數(shù)據(jù)(如數(shù)據(jù)包丟失)。獨立地講,發(fā)送方可以通過重傳定時器的到期來檢測丟包。從性能分析的角度來看,必須了解丟包的重要性,以避免 "機器中的幽靈"。下面的文章探討了這些機制的行為和性能。
?
重傳計時器
每個傳輸?shù)臄?shù)據(jù)包都由發(fā)送方鏈接到重傳計時器。如果計時器在已傳輸?shù)臄?shù)據(jù)段被確認之前過期,則該數(shù)據(jù)段將被聲明為丟失并重新傳輸。在性能方面,重傳定時器有兩個重要特點:
初始重新傳輸超時 (RTO) 的默認值幾乎始終為 3000 毫秒。隨后,該值會根據(jù)實際路徑重傳時間動態(tài)調(diào)整為更真實的值。
對于數(shù)據(jù)包的后續(xù)重新傳輸,超時值始終加倍。
?
對于短數(shù)據(jù)流(例如網(wǎng)絡流量),重傳計時器用于檢測數(shù)據(jù)包丟失。只有 1000 字節(jié)的消息在單個數(shù)據(jù)包中傳輸。當然,如果數(shù)據(jù)包丟失,接收方無法發(fā)送接收確認,因為接收方不知道丟失的數(shù)據(jù)包曾經(jīng)發(fā)送過。如果數(shù)據(jù)包在 TCP 連接的早期丟失,例如在三次握手期間丟失 SYN 數(shù)據(jù)包,則數(shù)據(jù)包丟失在三秒鐘內(nèi)不會恢復。
三次重復的ACK
在較大的數(shù)據(jù)流中,可以在重傳定時器過期前檢測到丟失的數(shù)據(jù)包。這是借助于三個收到的ACK副本來完成的。這種機制通常比等待重傳定時器過期更有效。如果到達的節(jié)點收到的數(shù)據(jù)包不符合順序,它就會發(fā)出重復的ACKs。失序的數(shù)據(jù)包可以是在丟失的數(shù)據(jù)包數(shù)據(jù)之后發(fā)送的數(shù)據(jù)包。重復的ACK包包含接收方仍在等待的準確序列號。當發(fā)送節(jié)點收到第三個重復的ACK時,它認為有關的數(shù)據(jù)包不僅被延遲,而且實際上已經(jīng)丟失。結果,丟失的數(shù)據(jù)包被重新傳輸。如果發(fā)生這種情況,發(fā)件人會假定網(wǎng)絡中存在擁堵,并將擁堵窗口減少50%,以積極應對擁堵。慢速啟動機制會緩慢增加CWD值。
例如,如果一個服務器向客戶傳輸一個大文件,由于慢速啟動機制,發(fā)送節(jié)點的吞吐量提升得更慢。當擁塞窗口達到24時,數(shù)據(jù)包丟失會被一個三重復的ACK檢測到。隨后,服務器重傳丟失的數(shù)據(jù),CWD值減少到12。慢速啟動機制將在這個時候重新啟用其擁塞避免模式。這種行為在現(xiàn)代網(wǎng)絡中經(jīng)??吹?。
?
結論和糾正措施
顯而易見的是,防止因擁堵造成的數(shù)據(jù)包丟失將提高性能。然而,這只有通過減少其他流量的擁堵才能實現(xiàn),可以通過以下方式實現(xiàn):
用于排隊優(yōu)先的QoS政策
減少總流量或增加帶寬
如果數(shù)據(jù)包丟失是由于其他情況造成的,如網(wǎng)絡接口故障、隊列配置錯誤或電纜連接不良,則必須確保TCP連接不會被不必要地關閉,不被不必要地超時,人們還可以減少重傳超時的值。
擴展閱讀
虹科 Allegro 介紹
虹科Allegro網(wǎng)絡萬用表 - 網(wǎng)絡故障排除的一體化解決方案
虹科Allegro網(wǎng)絡萬用表是是先進的網(wǎng)絡診斷工具,通過瀏覽器中的Web界面訪問分析數(shù)據(jù)。簡單部署,無需配置,只需要點擊幾下就可檢測到網(wǎng)絡問題??梢葬槍栴}區(qū)域或錯誤,并可以從預算的流量中捕獲PCAP以進一步分析。
一體化分析設備
軟件永久許可(全功能可用)
L2-L7全面分析
即插即用,無需配置
多種型號可選,1-200Gbit/s,滿足不同規(guī)模網(wǎng)絡需求
高速全流量捕獲分析,回溯分析
中文界面支持
?
-
網(wǎng)絡
+關注
關注
14文章
7389瀏覽量
88211
發(fā)布評論請先 登錄
相關推薦
評論