?

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時，它認為有關(guān)的數(shù)據(jù)包不僅被延遲，而且實際上已經(jīng)丟失。結(jié)果，丟失的數(shù)據(jù)包被重新傳輸。如果發(fā)生這種情況，發(fā)件人會假定網(wǎng)絡中存在擁堵，并將擁堵窗口減少50%，以積極應對擁堵。慢速啟動機制會緩慢增加CWD值。

例如，如果一個服務器向客戶傳輸一個大文件，由于慢速啟動機制，發(fā)送節(jié)點的吞吐量提升得更慢。當擁塞窗口達到24時，數(shù)據(jù)包丟失會被一個三重復的ACK檢測到。隨后，服務器重傳丟失的數(shù)據(jù)，CWD值減少到12。慢速啟動機制將在這個時候重新啟用其擁塞避免模式。這種行為在現(xiàn)代網(wǎng)絡中經(jīng)常看到。

?

結(jié)論和糾正措施

顯而易見的是，防止因擁堵造成的數(shù)據(jù)包丟失將提高性能。然而，這只有通過減少其他流量的擁堵才能實現(xiàn)，可以通過以下方式實現(xiàn)：

用于排隊優(yōu)先的QoS政策

減少總流量或增加帶寬

如果數(shù)據(jù)包丟失是由于其他情況造成的，如網(wǎng)絡接口故障、隊列配置錯誤或電纜連接不良，則必須確保TCP連接不會被不必要地關(guān)閉，不被不必要地超時，人們還可以減少重傳超時的值。

擴展閱讀

虹科 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)絡需求

高速全流量捕獲分析，回溯分析

中文界面支持

?