一般地，網(wǎng)絡性能指標涉及延遲、丟失和抖動?，F(xiàn)在，我們將探討這些問題(尤其是延遲和丟包)如何影響應用程序的性能。

實際上，所有的應用程序都使用TCP，即從A到B的數(shù)據(jù)傳輸控制協(xié)議。85%的因特網(wǎng)流量是TCP。

TCP的一個有趣之處是，它完全隱藏了應用程序中基于分組的網(wǎng)絡特性。不管是應用程序偶爾向TCP(如Telnet或SSH)傳遞單個字符，還是以最快速度(FTP)或介于這兩者之間的速度轉(zhuǎn)儲一個兆字節(jié)的文件，TCP都會把數(shù)據(jù)放入數(shù)據(jù)包中，然后通過網(wǎng)絡發(fā)送。

因特網(wǎng)對包的恐懼之處是：包會丟失，永遠不會傳播，而且到達的順序和傳送的順序不同也是很正常的。

..。

延誤。

以前的網(wǎng)絡協(xié)議一般都是為了運行在衛(wèi)星或園區(qū)網(wǎng)絡上，在那里數(shù)據(jù)包可以在幾毫秒內(nèi)從網(wǎng)絡的一端傳送到另一端。在因特網(wǎng)上，這些協(xié)議并不總能很好地工作，在這種情況下，數(shù)據(jù)包在到達目的地前可以輕易地繞著地球轉(zhuǎn)十分之一秒。當你以后還需要返回一個包時，這個數(shù)字會加倍到200毫秒。

隊列理論表明，鏈接越忙碌，所需等待的時間越長。

比如，10的運行速度是8Gbps(80%的利用率)。

平均而言，Gbps鏈路意味著，當一個包到達時，其他四個包正在等待。這個隊列的使用率達到99%，增加到99個包。如果連結(jié)速度很慢，這可能會增加很多額外的延遲，但是可以達到10。

Gbps傳輸99個平均500字節(jié)的包，只需0.248毫秒。

TCP具有多種機制，可以在高延遲條件下獲得較好的性能。

重要的是要確保有足夠的“正在運行”的數(shù)據(jù)包。簡單地發(fā)送一個信息包，然后等對方說“知道了，然后發(fā)下一個”，就不會被打斷。

所以，TCP試圖確保發(fā)送足夠的數(shù)據(jù)包來填充這些鏈接，但是數(shù)量不會太大，以致于它使鏈接或路徑飽和。這種方法對長期數(shù)據(jù)傳輸非常有效(比如大量下載量)。

但對較小的數(shù)據(jù)傳輸來說，這并不奏效，因為TCP采用了“慢啟動”機制，以確保不會使您的網(wǎng)絡連接變得沉重。

慢啟動部分只占長下載量的一小部分，但是當TCP加速時，短傳輸?shù)膫鬏攲⒔Y(jié)束。由于TCP必須等待接受者的確認，更多的延遲意味著更多的時間被浪費在啟動緩慢。以前，Web瀏覽器的性能受到了啟動速度的限制，但瀏覽器開始重用TCP會話，因為TCP會話開始下載其他圖像和其他元素，而不再打開新的TCP會話。

毫無疑問，幾乎每一個TCP連接都是在TCP查找之前的。假如在Securities服務器上等得太久，整個過程就會慢下來。所以試著使用附近一臺S-服務器。

連環(huán)。

丟了包。

理論上來說，網(wǎng)絡絕不會丟失一個單獨的包。在現(xiàn)實世界中，他們之所以這么做，當然有兩個原因。每一種傳輸媒介會偶爾“翻車”，從而丟失整個數(shù)據(jù)包。

一旦出現(xiàn)這樣的錯誤，丟失的數(shù)據(jù)包需要重新傳送。這能阻止轉(zhuǎn)移。

比如說200毫秒。

在RTT連接上以每秒1000包的速度發(fā)送數(shù)據(jù)。這就是說，當發(fā)送端發(fā)送數(shù)據(jù)包500時，數(shù)據(jù)包401–

499仍然在運行，而接收者只是對400的數(shù)據(jù)包發(fā)出了確認。然而，確認301–

由于399的運行方向不同，所以發(fā)送方所看到的最近的確認值為300。所以如果500包丟失了，發(fā)送者在看到499確認后才會注意到501?，F(xiàn)在它正在發(fā)送一個數(shù)據(jù)包700。這樣，接收者就可以看到包499,501。

-700、500，然后是701及以后的版本。這就是說，接收者必須緩沖501-700等待500時的包。

若網(wǎng)絡延遲或丟包過大，TCP將耗盡緩沖區(qū)空間，傳輸必須停止，直到接收到重新傳輸?shù)膩G失包。換言之：高延遲或高丟失的情況并不好，但仍可使用，但同時高延遲和高丟失會讓TCP爬網(wǎng)變慢。

丟包的第二個原因是TCP被發(fā)送得太快了，以至于路由器/交換機緩沖區(qū)被填塞得比包的傳輸快。在緩沖區(qū)滿的情況下，另一個數(shù)據(jù)包也會進入，路由器或交換機只能做一件事情：“丟棄”包。因為TCP不能識別因網(wǎng)絡中的位翻轉(zhuǎn)或緩沖區(qū)溢出而丟失的包之間的差異，所以會假設后者，并降低速度。上例中，此速度降低并不太嚴重，因為隨后的包會一直被確認。這樣就可以使用TCP“快速轉(zhuǎn)發(fā)”。

然而，如果傳輸中的最后三個包中的一個丟失了，快速重傳就會失效。這種情況下，TCP不能區(qū)分單獨丟失的包和網(wǎng)絡超載過大而不能通過的情況?，F(xiàn)在，TCP會讓它的超時計時器計數(shù)減少到0，通常需要1秒鐘，然后再試著讓所有的東西以慢速開始。Web會話通常會出現(xiàn)這種問題，而且Web會話通常很短，盡管頁面的大部分很快就會出現(xiàn)，但是頁面要花幾秒鐘才能完全完成加載。

TCP超時終止的另一個原因是短時間內(nèi)是否有過多的數(shù)據(jù)包。此時，TCP確定網(wǎng)絡只能承受非常保守的數(shù)據(jù)傳輸速度，慢速啟動確實可以說是對的。一般來說，在這種情況下，停止下載并重新開始下載要比等待TCP恢復快。

連環(huán)。

搖晃。

抖抖是指數(shù)據(jù)包之間的延遲。很明顯，光速是不變的，光纖的長度通常是一樣的。

所以，延時通常是由節(jié)點上的封包緩沖和交換機上的封包終止高利用率的鏈路造成的。尤其是在低帶寬鏈路上，如寬帶或3G鏈路。

/

四G連接方式)

有時候，信息包是幸運的，有時候，排隊的時間比平時長。

對TCP來說，這個問題不大，雖然這意味著TCP必須對RTT的估計使用保守值，而且超時時間會更長。然而，抖動對于(非TCP)實時音頻和視頻流量來說是一個問題，因為音頻/視頻播放速率必須是穩(wěn)定的。這就是說，應用程序必須緩存“快速”包，并等待慢速的包。

總之，在使用多個Internet連接的網(wǎng)絡中，這樣做確實可以避免這樣的情況：避免路徑過長，導致比到達同一目的地的替代路徑和阻塞路徑(高丟包率)更長的延遲。

我們實現(xiàn)了Vecloud微云主干網(wǎng)絡環(huán)境下的自動路徑選擇過程。確定您的智能路由，以及它如何評估多個提供商之間的包丟失和延遲，以選擇最優(yōu)路徑。

了解更多網(wǎng)絡知識關注：http://www.vecloud.com/