http連接管理(http權威指南第四章)

連接管理

本章將介紹:
- http時如何使用TCP連接的
- TCP連接的時延,瓶頸以及存在的障礙
- http的優化,包括並行連接,keep-alive(持久連接)和管道化連接
- 管理連接時應該以及不應該做的事情
1. TCP連接
TCP爲http提供了一條可靠的比特傳輸管道,從TCP連接的一端填入的字節會從另一端以原有的順序,正確的傳送出來
http要傳送一條報文時,會以流的形式將報文數據的內容通過一條打開的TCP連接按序傳輸。TCP受到數據流之後,會講數據流砍成被稱作爲段的小數據塊,並將段封裝在IP分組中,通過因特網進行傳輸,所有這些工作都由TCP/IP軟件來處理,http程序員什麼都看不到
每個TCP段都是由IP分組承載,從一個IP地址發送到另一個IP地址。每個IP分組包括:
- 一個IP分組首部(通常20個字節)
- 一個TCP段首部(通常20個字節)
- 一個TCP數據塊(0個或多個字節)
IP首部:源和目的IP地址,長度和其它一些標記
TCP段首部:TCP端口號,TCP控制標記,數據排序和完整性檢查的一些數字值
在任意時刻計算機都可以有幾條TCP連接處於打開狀態,TCP是通過端口號來保持所有這些連接的正確運行。IP地址可以將我們連接到正確的計算機,端口號可以將我們連接到正確的應用程序上。TCP連接通過4個值來識別:

<源IP地址,源端口號,目的IP地址,目的端口號>

這四個值唯一的定義一條連接
操作系統提供了一些操縱其TCP連接的工具,套接字API向http程序員隱藏了TCP和IP的所有細節。套接字API允許用戶創建TCP的端點數據結構,將這些端點與遠程服務器的TCP端點進行連接,並對數據流進行讀寫
2. 對TCP性能的考慮
http緊挨TCP,位於其上層,所以http事務的性能在很大程度上取決於底層TCP通道的性能。
http事務的時延由以下原因:
- 客戶端首先根據URI確定web服務器的IP地址和端口號,如果最近沒有對URI中的主機進行訪問,通過DNS解析系統將URI中的主機名轉換
- 客戶端向服務器發送一條TCP連接請求,並等待服務器回送一個請求接受應答
- 一旦連接建立起來,客戶端就會通過新建立的TCP管道發送http請求,web服務器會從TCP連接中讀取請求報文,並對請求進行處理
- web服務器回送http響應,這也需要時間
常見TCP相關時延爲:
- TCP連接建立握手
TCP連接握手需要經過以下幾個步驟:
1. 請求新的TCP連接時,客戶端要向服務器發送一個小的TCP分組,這個分組中設置一個特殊的SYN標記,說明這是一個連接請求
2. 如果服務器接收了連接,就會對一些連接參數進行計算,並向客戶端回送一個TCP分組,這個分組中的SYN和ACK標記都被置位,說明連接請求已被接受
3. 最後客戶端向服務器回送一條確認信息,通知它連接已建立。現在的TCP都允許客戶端在這個確認分組中發送數據
- TCP慢啓動擁塞控制
TCP數據傳輸的性能還取決於TCP連接的使用期。TCP連接會隨着時間進行自我“調諧”,起初會限制連接的最大速度,如果數據成功傳輸,會隨着時間的推移提高傳輸的速度,這種調諧別稱爲TCP慢啓動,用於防止因特網的突然過載荷擁塞。所以新連接的傳輸速度會比已經交換過一定數據的“已調諧”連接慢一些
- 數據聚集的Nagle算法
Nagle算法試圖在發送一個分組之前,將大量TCP數據綁定在一起,以提高網絡效率。Nagle算法鼓勵發送全尺寸的段,只有當所有其它分組都被確認之後,Nagle算法才允許發送非全尺寸分組,如果其它分組還在傳輸過程中,就將那部分數據緩存起來。只有當掛起分組被確認,或者緩存中積累了足夠發送一個全尺寸分組的數據時,纔會將緩存的數據發送出去。
http應用程序常常在自己的棧中設置參數TCP_NODELAY,禁用Nagle算法,提高性能。
- 用於捎帶確認的TCP延遲確認算法
小的http事務可能會在TCP建立上花費很多時間。TCP將返回的確認信息與輸出的數據分組結合在一起,可以更有效的利用網絡。爲了增加確認報文找到通向傳輸數據分組的可能性,很多TCP棧都實現了一種“延遲確認”算法。延遲確認算法會在一個特定的窗口時間(通常100-200毫秒)內將輸出確認存放在緩衝區中,以尋找能夠捎帶它的輸出數據分組,如果在那段時間內沒有輸出數據分組,就將確認信息放在單獨的分組中傳送
- TIME_WAIT時延和端口耗盡
TIME_WAIT端口耗盡時很嚴重的性能問題,會影響到性能基準,現實中相對較少出現
當某個TCP端點關閉TCP連接時,會在內存中維護一個小的控制塊,用來記錄最近所關閉連接的IP地址和端口號,這類信息只會維持一小段時間,以確保在這段時間內不會創建具有相同地址和端口號的新連接。
3. http連接的處理
- 常被誤解的Connection首部
http允許在客戶端和最終的源端服務器之間存在一串中間實體(代理,高速緩存等)。可以從客戶端開始,逐條的講http報文經過這些中間設備,轉發到源端服務器上去
Connection首部可以承載3中不同類型的標籤:
- http首部字段名,列出了只與此連接有關的首部
- 任意標籤值,用於描述此連接的非標準選項
- 值close,說明操作完成後需要關閉這條持久連接
在將報文轉發出去之前,必須刪除Connection首部列出的所有首部字段,因此將逐跳首部名放入Connection首部被稱爲“對首部的保護“
- 串行事務處理時延
串行事務的時延可能會疊加起來,幾種現存和新興的方法可以提高http的連接性能:
1. 並行連接
- 並行連接可能會提高頁面的加載速度
因爲時延會重疊
- 並行連接不一定更快
因爲帶寬有限,而且大量連接消耗內存資源,引發性能下降
- 並行連接可能讓人“感覺”更快一些
因爲多個組件對象同時出現在屏幕上,用戶能夠看到加載的進展
2. 持久連接
初始化了對某服務器http請求的應用程序很可能會在不久的將來對那臺服務器發起更多的請求,這種性質被稱爲站點本地性。因此http/1.1允許http設備在事務處理結束之後將TCP連接保持在打開狀態,以便爲未來的http請求重用現存的連接,這稱爲持久連接。非持久連接會在每個事務結束之後關閉。
並行連接的一些缺點:
- 每個事務都會打開/關閉一條新的連接,會耗費時間和帶寬
- 由於TCP慢啓動特性的存在,每條新連接的性能都會有所下降
- 可打開的並行連接數量是有限的
持久連接和並行連接配合使用時最高效的方式,現在很多web應用程序都會打開少量的並行連接,其中每一個都是持久連接。持久連接有兩種類型:
- 比較老的http/1.0+ keep-alive連接
- 現代的http/1.1 persistent連接
3. 管道化連接
http/1.1允許在持久連接上可選地使用請求管道。在響應到達之前,可以將多條請求放入隊列,當第一條請求通過網絡流向服務器時,第二條河第三條請求也可以開始發送了,這樣做可以降低網絡的環回時間,提高性能
4. 複用的連接
交替傳送請求和響應報文(實驗階段)

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章