HTTP事務的延遲—TCP的影響

導讀:最近看完了大部頭著做《HTTP權威指南》,對於此類指南類、手冊類圖書,每每讓咱們聯想到的就是枯燥無味的使用講解、技術指標講解......令人頭大。可是這本書卻讓我以爲讀起來很「清新」,一方面做者用了淺顯易懂的語言和大量的圖示讓咱們很容易知因此然,另外一方面應該是我一直以來對網絡編程的興趣和此書的內容有很大的契合點,今天要講的內容也是與本身的興趣有關的HTTP協議中有關TCP的部分,是從書中第四章——」鏈接管理「的部份內容總結而來。
web


HTTP請求過程當中會有哪些網絡時延?

wKiom1UhMG2hoBaIAACFJLHKC_U641.jpg

  1. 域名解析:域名解析是進行網絡訪問的第一步,把域名識別爲TCP認識的IP地址。這步每每會由於域名解析服務的質量形成諸多問題,我在實際的工程實踐中遇到的最多見的問題就是選擇的域名服務商質量很差或者客戶端自己設置的域名解析服務地址錯誤致使域名解析慢或者失敗。不過如今對於大多數的HTTP客戶端都有一個小的DNS緩存,用來保存近期所訪問站點的IP地址,能夠有效的緩解此問題。算法

  2. 接下來,客戶端會向服務器發送一條TCP鏈接請求,並等待服務器回送一條響應。每條新的TCP鏈接都有鏈接創建時延(一般最多隻有一兩秒鐘),對於單線程瀏覽器而言,若是有數百個併發的HTTP事務的話,可想而知時間疊加值也會很大。編程

  3. 一旦鏈接創建起來,客戶端和服務器端就會經過這個創建的TCP管道來進行請求的收發了,這些TCP的網絡時延的大小取決於硬件速度、網絡和服務器的負載,請求和響應報文的尺寸,以及客戶端和服務器之間的距離。請參見個人文章《構建高性能服務的考量》瀏覽器

TCP相關時延
  • TCP鏈接創建握手緩存

    wKioL1UhMc3RLTTHAACWKdyGkGs865.jpg
    創建一條新的TCP鏈接時,TCP兩端之間會交換一系列的IP分組,若是鏈接只是用來傳送少許的數據,相比而這種創建鏈接的過程會大大影響HTTP的性能。
    服務器

    一般HTTP的事務都不會交換太多數據,SYN/SYN+ACK兩次握手會產生一個可測量的時延,但第三次握手——TCP鏈接ACK分組一般都足夠大,能夠承載整個HTTP的請求報文(現代的TCP協議棧都容許客戶端在這個確認分組中發送數據),並且不少HTTP服務器響應報文均可以放到一個IP分組中去。網絡

    能夠看出,小的HTTP事務可能會在TCP創建鏈接上花費50%的時間之多。因此咱們現實中經常會有重用HTTP鏈接的需求。併發

  • TCP的延遲確認機制
    咱們都知道因特網自身是沒法保證可靠的分組傳輸的,因此TCP實現了本身的確認機制來確保數據的傳輸成功。在這種確認機制中使用的就是確認報文,因爲確認報文很小,因而TCP將要返回的確認信息與輸出的數據分組結合在一塊兒發送能夠更有效的利用網絡。爲了增長確認報文找到同向傳輸數據分組的可能性,不少TCP協議棧都實現了一種「延遲確認」算法——在一個特定的窗口時間(一般是100-200毫秒)內將輸出確認放在緩衝區中,以尋找可以捎帶它的輸出數據分組,不然超出這個時段就將確認數據單獨發送。
    tcp

    可是HTTP具備雙峯特徵的請求——應答行爲下降了捎帶信息的可能。當但願有相反方向回傳分組的時候,恰恰沒有那麼多。一般,延遲確認算法會引入至關大的時延,因此咱們應該依據相應的操做系統的不一樣調整或者禁用延遲確認算法。ide

注:在對TCP協議棧的任何參數進行修改以前,必定要對本身作什麼有清醒的認識。TCP中引入這些算法的目的是防止設計欠佳的應用程序對網絡形成破壞。因此修改這些配置後都應該保證應用程序不會引起這些算法所要避免的問題。

  • TCP慢啓動(擁塞控制)
    爲了更好的保護網絡,TCP慢啓動限制了一個TCP端點在任意時刻能夠傳輸的分組數。TCP數據傳輸起初會限制傳輸速度(傳輸分組數),若是數據成功傳輸,會隨着時間的推移提升傳輸速度(傳輸分組數)。若是某個HTTP事務有大量數據要發送,是不能一次將全部分組都發送出去的。必須依賴慢啓動逐漸的打開擁塞窗口。

    因爲存在這種擁塞控制特性,因此新鏈接的傳輸速度會比已經交換過必定量數據的鏈接慢一些。這樣又須要咱們從重用HTTP鏈接(持久鏈接)的角度去考慮提升傳輸性能。

  • Nagle算法與TCP_NODELAY
    若是TCP鏈接老是發送大量包含少許數據的分組,網絡的性能就會嚴重降低。Nagle算法就是試圖在發送一個分組以前,將大量TCP數據綁定在一塊兒發送(鼓勵發送全尺寸的段,好比以太網上的段大小是1500字節,不然就進行緩存,要麼當全部其餘分組都被確認以後,Nagle算法才容許發送非全尺寸的分組),以提升網絡效率。

    Nagle算法會引起幾種HTTP的性能問題。好比小的HTTP報文可能沒法填滿一個分組,因此要緩存等待起來,要麼就等待確認分組的抵達(確認分組的時延大概在100-200毫秒)。

    因此HTTP應用程序經常會在本身的協議棧中設置參數TCP_NODELAY,禁用Nagle算法來提升性能。

  • TIME_WAIT累積與端口耗盡
    關於TIME_WAIT狀態的解釋請看個人這篇博文
    《網絡編程釋疑之:TCP的TIME_WAIT狀態在服務器開發中的影響?》,以前TIME_WAIT時間的設置爲2分種之可能是由於早期路由器的處理速度還比較慢,可是如今高速路由器的使用已經大大弱化了這個問題,因此對於web服務器來講能夠經過操做系統設置來減少TIME_WAIT狀態的持續時間,不然若是服務器存在大量的TIME_WAIT狀態會大大影響服務器的性能。至於端口耗盡的狀況則是針對少許客戶端主機對web服務器進行基準測試時可能出現的問題,與TCP鏈接四元組有關。

參考書籍:

《HTTP權威指南》

相關文章
相關標籤/搜索