高延遲的明顯影響是處理網(wǎng)絡請求需要更長時間。

理論上，如果RTT是10毫秒，從客戶端系統(tǒng)到服務器的請求將需要5毫秒，然后返回請求的數(shù)據(jù)將需要5毫秒。事實上，它需要更長時間，因為大多數(shù)協(xié)議需要在數(shù)據(jù)開始流動之前來回發(fā)送多個數(shù)據(jù)包。

舉例來說，TCP使用三向握手：客戶端向服務器發(fā)送第一個數(shù)據(jù)包。從客戶端到服務器的第三個數(shù)據(jù)包是第一個數(shù)據(jù)包，它能夠以(例如)HTTP請求的形式攜帶數(shù)據(jù)。在交換過程中，第四個數(shù)據(jù)包是第一個能夠向客戶端傳輸請求的數(shù)據(jù)包。若RTT為10毫秒，則需要20毫秒，但若RTT為100毫秒，則需要200毫秒。

此外，在打開TCP對話之前，應用程序幾乎總是需要在域名系統(tǒng)(DNS)中找到目標服務器的IP地址。這至少是另一次往返(時間)。因此，避免使用RTT高的DNS服務器很重要。在接受連接或處理請求之前，一些服務器軟件首先會對客戶端的IP地址進行反向DNS搜索。這可能會給用戶(尤其是遠程用戶)帶來嚴重的延遲，而來自之前看到的IP地址的測試人員不會看到這種延遲。如果需要記錄日志，請確保這種反向搜索異步，不會阻止處理連接和請求。

應用延遲的另一個來源是協(xié)商安全參數(shù)。

設置TLS/

SSL需要更多的往返時間，因為需要協(xié)商加密和哈希算法，服務器的身份由客戶端驗證并確定會話加密密鑰。類似地，由于開發(fā)者和測試者通常都比較接近系統(tǒng)，所以額外的往返效果通常對他們來說并不明顯。但遠處的用戶會看到明顯的延遲，因為大約需要十幾個數(shù)據(jù)包來回傳輸實際數(shù)據(jù)。

但一旦第一個數(shù)據(jù)包開始流動，延遲就不會結(jié)束。

通過互聯(lián)網(wǎng)進行通信的一個非常簡單的方法是發(fā)送數(shù)據(jù)包，等待另一端確認接收到的數(shù)據(jù)包，然后發(fā)送下一個數(shù)據(jù)包。這在短距離上是有效的，但在長距離上是不可行的。假設RTT是50毫秒，因為發(fā)送者和接收者之間的距離大約是5000公里(3000英里)。發(fā)送數(shù)據(jù)包后，發(fā)送者將等待100英里。

ms，然后接收確認并發(fā)送下一個數(shù)據(jù)包。所以傳輸速度是每個RTT一個數(shù)據(jù)包。這樣，整個大陸或海洋每秒只需要20個數(shù)據(jù)包，而標準1500字節(jié)以太網(wǎng)數(shù)據(jù)包只需要30個。

KB/秒！

所以TCP的方法就是找出要傳輸多少個數(shù)據(jù)包來充分利用可用帶寬。假定可用帶寬為100。

Mbps。大約每秒8300個1500字節(jié)數(shù)據(jù)包，或者每50毫秒RTT。

415個數(shù)據(jù)包。因此，TCP發(fā)送415個數(shù)據(jù)包。然后，等待第一個數(shù)據(jù)包確認后再發(fā)送第416個數(shù)據(jù)包，等等，使415個數(shù)據(jù)包的窗口處于運行狀態(tài)。事實上，TCP會不斷探索可用帶寬，所以它會向網(wǎng)絡注入比可用帶寬能承受更多的數(shù)據(jù)包。然后，在某個時間點，一個或多個數(shù)據(jù)包丟失，TCP降低了其窗口大小，從而降低了其傳輸速度。

為了避免會話開始時大量網(wǎng)絡過載，TCP使用了一種叫做慢啟動的算法。選擇這個算法的名字并不是特別好，因為TCP加倍了它的窗口，每次來回都加倍了速度。所以可以快速提高它的傳輸速度。麻煩的是，它從只有幾個數(shù)據(jù)包的窗口大小開始。所以這個窗口需要來回五次左右才能達到50。

msRTT填充100。

連接Mbps所需的415個數(shù)據(jù)包。所以在TCP達到全速之前需要250毫秒。由于RTT的增加，這種情況變得越來越快：當RTT達到100毫秒時，現(xiàn)在需要進行6次往返，但每次往返的時間是原來的兩倍，所以在TCP全速運行之前需要600毫秒。

在處理任何類型的互動網(wǎng)絡應用程序時，將等待時間保持在盡可能低的水平總是有幫助的:這將使數(shù)據(jù)盡快開始流動，并使TCP更快地達到全速。此外，高等待時間往往會使數(shù)據(jù)包丟失引起的問題更加嚴重，反之亦然。

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