建立一條新的tcp連線時，甚至是在傳送任意資料之前，tcp軟體之間都會交換一系列的ip分組，對連線的有關引數進行溝通。如果連線只用來傳送少量資料，這些交換過程就會嚴重降低http的效能。
通常http事務都不會交換太多資料，此時，syn/syn+ack握手會產生乙個可測量的時延。tcp連線的ack分組通常都足夠大，可以承載整個http請求報文，而且很多http伺服器響應報文都可以放入乙個ip分組中去。
最後的結果是，小的http事務可能會在tcp建立上花費50%，或更多的時間。所以，需要重用現有連線。
由於確認報文很小，所以tcp允許在發往相同方向的輸出資料分組中對其進行「捎帶」。可以更有效地利用網路。延遲確認演算法會在乙個特定的視窗時間（通常是100~200毫秒）內將輸出確認存放在緩衝區中，以尋找能夠捎帶它的輸出資料分組。但是http具有雙峰特徵（？）的請求-應答行為降低了捎帶資訊的可能。當希望有相反方向回傳分組的時候，偏偏沒有那麼多。通常，延遲確認演算法會引入相當大的時延。根據所使用作業系統的不同，可以調整或禁止延遲確認演算法。
tcp慢啟動限制了乙個tcp端點在任意時刻可以傳輸的分組數。簡單來說，沒成功接收乙個分組，傳送端就有了傳送另外兩個分組的許可權。以此類推，這種方式被稱為「開啟擁塞視窗「，用於防止網際網路的突然過載和擁塞。由於已調諧連線要更快一些，所以http中有一些可以重用現存連線的工具。如http」持久連線「。
nagle演算法鼓勵傳送全尺寸（lan上最大尺寸的分組大約是1500位元組，在網際網路上是幾百位元組）的段。只有當所有其他分組都被確認之後，nagle演算法才允許傳送非全尺寸的分組。如果其他分組仍然在傳輸過程中，就將那部分資料快取起來。只有當掛起分組被確認，或者快取中積累了足夠傳送乙個全尺寸分組的資料時，才會將快取的資料傳送出去。
nagle會引發幾種http效能問題。小的http報文可能無法填滿乙個分組，可能會因為等待那些永遠不會到來的額外資料而產生時延。其次，nagle演算法與延遲確認之間的互動存在問題——nagle演算法會阻止資料的傳送，直到有確認分組抵達為止，但確認分組自身會被延遲確認演算法延遲100~200毫秒。
http應用程式常常會在自己的棧中設定引數tcp_nodelay，禁用nagle演算法，提高效能。如果這樣做，一定要確保會向tcp寫入大塊的資料，這樣才不會產生一堆小分組。
當某個tcp端點關閉tcp連線時，會在記憶體中維護乙個小的控制塊，用來記錄最近所關閉連線的ip位址和埠號。這類資訊只會維持一小段時間，通常是所估計的最大分段使用期的兩倍（稱為2msl，通常為2分鐘）左右，以確保在這段時間內不會建立具有相同位址和埠號的新連線。
客戶端每次連線到伺服器上去時，都會獲得乙個新的源埠，以實現連線的唯一性。但由於可用源埠的數量有限，並且在2msl秒內連線是無法重用的，連線率就被限制在了65535/120=546次/秒。這樣有可能產生的問題就是埠耗盡問題。
HTTP事務的延遲 TCP的影響
最近看完了大部頭著作 http權威指南 對於此類指南類 手冊類圖書，往往讓我們聯想到的就是枯燥無味的使用講解 技術指標講解.使人頭大。但是這本書卻讓我覺得讀起來很 清新 一方面作者用了淺顯易懂的語言和大量的圖示讓我們很容易知所以然，另一方面應該是我一直以來對網路程式設計的興趣和此書的內容有很大的契合...
HTTP事務的延遲 TCP的影響
最近看完了大部頭著作 http權威指南 對於此類指南類 手冊類圖書，往往讓我們聯想到的就是枯燥無味的使用講解 技術指標講解.使人頭大。但是這本書卻讓我覺得讀起來很 清新 一方面作者用了淺顯易懂的語言和大量的圖示讓我們很容易知所以然，另一方面應該是我一直以來對網路程式設計的興趣和此書的內容有很大的契合...
http請求時 tcp 三次握手
local 192.168.0.1 server 192.168.0.120 server 上就乙個空index.php頁面 1 開啟抓包 root centos tcpdump tcp port 80 s tcpdump verbose output suppressed,use v or vv ...