摘要：后者仍處于試驗階段，未大范圍使用。事務(wù)時延的有以下幾種主要原因客戶端首先需要根據(jù)確定服務(wù)器的地址和端口號。這種調(diào)諧被稱為慢啟動，用于防止因特網(wǎng)的突然過載和擁塞。

WilsonLiu"s blog 首發(fā)地址

HTTP協(xié)議是因特網(wǎng)的多媒體信使。HTTP可以從遍布世界的Web服務(wù)器上將這些信息快迅速，便捷，可靠地搬移到人們桌面上的Web瀏覽器上去。

HTTP協(xié)議主要分Web客戶端和服務(wù)器。其中Web服務(wù)器是Web資源的宿主。Web資源可以包含任意媒體類型內(nèi)容，HTTP協(xié)議為了標識各種媒體類型，會給通過Web傳輸?shù)膶ο蠖即蛏螹IME類型的數(shù)據(jù)標簽格式。(MIME科普:最初設(shè)計MIME(Multipurpose Internet Mail Extension，多用途因特網(wǎng)郵件擴展)是為了解決在不同的電子郵件系統(tǒng)之間搬移報文時存在的問題。HTTP隨后也采用了它，用他來描述并標記多媒體內(nèi)容。)

同時，每個web服務(wù)器資源都有一個名字去標識，這被稱為統(tǒng)一資源標識符(Uniform Resource Identifier)。URI有兩種類型，一種是我們常見的統(tǒng)一資源定位符URL，另外一種被稱為統(tǒng)一資源名URN。后者仍處于試驗階段，未大范圍使用。

web頁面可以包含多個對象，如一個頁面會包括許多圖片，視頻，音頻等內(nèi)容?？蛻舳送ㄟ^向Web服務(wù)器發(fā)送請求命令來進行事務(wù)處理。服務(wù)器響應(yīng)客戶端請求，并傳送相應(yīng)數(shù)據(jù)。

請求和響應(yīng)報文都有固定的規(guī)范。報文由一行一行簡單字符串組成的。HTTP報文都是純文本，而不是二進制代碼，所以人們可以很方便的進行讀寫(但難以解析)。報文分為三部分

起始行 GET /index.html HTTP/1.0

首部字段 每個首部字段包含一個名字和一個值，為了便于解析，兩者之間用冒號來分割。首部以一個空行結(jié)束。

主體 起始行和首部都是文本形式且都是結(jié)構(gòu)化的，主體則可以包含任意的二進制數(shù)據(jù)，當(dāng)然也可以包含文本。

HTTP協(xié)議的報文是通過傳輸控制協(xié)議(Transmission Control Protocol,TCP)連接從一個地方搬移到另外一個地方去的。
TCP提供了

無差錯的數(shù)據(jù)傳輸

按序傳輸 (數(shù)據(jù)總是會按照發(fā)送的順序到達)

未分段的數(shù)據(jù)流 (可以在任意時刻以任意尺寸將數(shù)據(jù)發(fā)送出去)

在HTTP客戶端向服務(wù)器發(fā)送報文之前，需要用網(wǎng)際協(xié)議(Internet Protocol,IP)地址和端口號在客戶端和服務(wù)器之間建立一條TCP/IP連接。首先需要將URL進行DNS解析成IP地址，再用IP地址連接Web服務(wù)器，默認端口是80。

除了客戶端與服務(wù)器之外，還有許多比較重要的Web結(jié)構(gòu)組件

代理 位于客戶端和服務(wù)器之間的HTTP中間實體

緩存 HTTP的倉庫，使常用頁面的副本可以保存在離客戶端更近的地方

網(wǎng)關(guān) 連接其他應(yīng)用程序的特殊Web服務(wù)器

隧道 對HTTP通信報文進行盲轉(zhuǎn)發(fā)的特殊代理

Agent代理 發(fā)起自動HTTP請求的半智能Web客戶端

URL提供了一種統(tǒng)一的資源命名方式，大多數(shù)URL都有同樣的:"方案://服務(wù)器位置/路徑"結(jié)構(gòu)。

://:@:/;?#
幾乎沒有哪個URL包含了所有這些組件。
URL最重要的3個部分是方案(scheme)，主機(host)和路徑(path)。

轉(zhuǎn)義表示法包含一個百分號%，后面跟著兩個表示字符ASCII碼的十六進制數(shù)。
例子http://www.baidu.com/%7Ejoe ~ 126(0x7E)

HTTP報文是在HTTP應(yīng)用程序之間發(fā)生的數(shù)據(jù)塊。這些數(shù)據(jù)塊以一些文本形式的元信息(meta-information)開頭，這些信息描述了報文的內(nèi)容及含義，后面跟著可選的數(shù)據(jù)部分。這些報文在客戶端，服務(wù)器和代理之間流動。

所有的報文都可以分為兩類:請求報文(request message)和響應(yīng)報文(response message)。

請求報文

響應(yīng)報文

并不是所有服務(wù)器都實現(xiàn)了上述7種方法，而且，由于HTTP設(shè)計的易于擴展，所以其他服務(wù)器可能還會實現(xiàn)一些自己的請求方法。

當(dāng)前的HTTP版本只為每類狀態(tài)定義了幾個代碼，隨著協(xié)議的發(fā)展，HTTP規(guī)范中會正式的定義更多的狀態(tài)碼，如果收到了不認識的狀態(tài)碼，可能是有人將其作為當(dāng)前協(xié)議的擴展定義的?？梢愿鶕?jù)其所處范圍，將它作為那個類別中一個普通的成員來處理。

首部分類：

通用首部 既可以出現(xiàn)在請求報文中又可以出現(xiàn)在響應(yīng)報文中

請求首部 提供更多有關(guān)請求的信息

響應(yīng)首部 提供更多有關(guān)響應(yīng)的信息

實體首部 描述主體的長度和內(nèi)容，或者資源自身

擴展首部 規(guī)范中沒有定義的新首部

HTTP報文的第三部分是可選的實體主體部分。實體的主體是HTTP報文的負荷，就是HTTP要傳輸?shù)膬?nèi)容。

世界上幾乎所有的HTTP通信都是由TCP/IP承載的，TCP/IP是全球計算機及網(wǎng)絡(luò)設(shè)備都在使用的一種常用的分組交換網(wǎng)絡(luò)分層協(xié)議集?？蛻舳藨?yīng)用程序可以打開一條TCP/IP連接，連接到可能運行在世界任何地方的服務(wù)器應(yīng)用程序。

https://github.com:80/WilsonLiu95

瀏覽器利用解析出主機名 github.com

瀏覽器查詢這個主機名的IP地址 192.30.252.122

瀏覽器獲得端口號 80

瀏覽器發(fā)起到192.30.252.122端口80的連接

瀏覽器向服務(wù)器發(fā)送一條HTTP GET報文

瀏覽器從服務(wù)器讀取HTTP響應(yīng)報文

瀏覽器關(guān)閉TCP連接

與建立TCP連接，以及傳輸請求和響應(yīng)報文的時間相比，事務(wù)處理時間可能是很短的。除非客戶端或服務(wù)器超載，或正在處理復(fù)雜的動態(tài)資源，否則HTTP時延就是由TCP網(wǎng)絡(luò)時延構(gòu)成的。

HTTP事務(wù)時延的有以下幾種主要原因

客戶端首先需要根據(jù)URI確定Web服務(wù)器的IP地址和端口號。其中IP地址需要通過DNS解析URL中的主機名獲得，這可能花費數(shù)十秒的時間。

客戶端向服務(wù)器發(fā)送TCP連接請求，即著名的"三次握手"。這個值通常最多只有一兩秒鐘，但如果有數(shù)百個HTTP事務(wù)的話，這個值就會快速疊加上去。

因特網(wǎng)傳輸報文，以及服務(wù)器處理請求報文都需要花費時間。

web服務(wù)器回送HTTP響應(yīng)也需要時間。
這些TCP網(wǎng)絡(luò)時延取決于硬件速度，網(wǎng)絡(luò)和服務(wù)器的負載，請求和響應(yīng)報文的尺寸，以及客戶端和服務(wù)器之間的距離。TCP協(xié)議的技術(shù)復(fù)雜性也會對時延產(chǎn)生巨大的影響。

一下是其余一些會對HTTP產(chǎn)生影響，最常見的相關(guān)時延

TCP連接建立握手

TCP慢啟動擁塞控制

數(shù)據(jù)聚焦的Nagle算法

用于捎帶確認的TCP延遲確認算法

TIME_WAIT時延和端口耗盡

TCP連接握手需要經(jīng)過一下幾個步驟

酷虎的向服務(wù)器發(fā)送一個小的TCP分組(通常是40-60字節(jié))。這個分組中設(shè)置了一個特殊的SYN標記，說明這是一個連接請求。

如果服務(wù)器接收了連接，就會對一些連接參數(shù)進行計算，并向客戶端回送一個TCP分組，這個分組中的SYN和ACK標記都被置位了，說明連接請求已經(jīng)被接收了。

最后，客戶端向服務(wù)器回送一條確認信息，通知它連接已成功建立。現(xiàn)代的TCP棧都允許客戶端在這個確認分組中發(fā)送數(shù)據(jù)。

如果連接只用來傳送少量的數(shù)據(jù)，這些交換過程就會嚴重降低HTTP的性能。小的HTTP事務(wù)可能會在TCP建立上花費50%或者更多的時間。

每個TCP段都有一個序列號和數(shù)據(jù)完整性校驗和。每個段的接收者收到完好的段時，都會向發(fā)送者回送小的確認分組。如果發(fā)送者沒有在指定的窗口時間內(nèi)收到確認信息，發(fā)送者就認為分為已被破壞或損毀，并重發(fā)數(shù)據(jù)。
為了增加確認報文找到同向傳輸數(shù)據(jù)分組的可能性，很多TCP棧都實現(xiàn)了一種"延遲確認"算法。延遲確認算法會在一個特定的窗口時間(通常是100~200毫秒)內(nèi)將輸出確認存放在緩沖區(qū)中，以尋找能夠捎帶它的輸出數(shù)據(jù)分組。如果在那個時間段內(nèi)沒有輸出數(shù)據(jù)分組，就講確認信息放在多帶帶的分組中傳送。
通常，延遲確認算法會引入相當(dāng)大的時延，所以可以調(diào)整或者禁止延遲確認算法。

TCP數(shù)據(jù)傳輸?shù)男阅苓€取決于TCP連接的使用期(age)。TCP連接會隨著時間進行自我“調(diào)諧”，起初會限制連接的最大速度，如果數(shù)據(jù)成功傳輸，會隨著時間的推移提高傳輸?shù)乃俣?。這種調(diào)諧被稱為TCP慢啟動(slow start)，用于防止因特網(wǎng)的突然過載和擁塞。

Nagle算法鼓勵發(fā)送全尺寸(LAN上最大尺寸的分組大約是1500字節(jié)，在因特網(wǎng)上是幾百字節(jié))的段。只有當(dāng)所有其他的分組都被確認之后，Nagle才允許發(fā)送非全尺寸的分組，如果其他分仍然在傳輸過程中，就將那部分數(shù)據(jù)緩存起來。只有當(dāng)掛起分組被確認，或者緩存中積累了足夠發(fā)送一個全尺寸分組的數(shù)據(jù)時，才會將緩存的數(shù)據(jù)發(fā)送出去。
Nagle算法會引發(fā)幾種HTTP性能問題。首先小的HTTP報文無法填滿一個分組，可能會因為等待那些永遠不會到來的額外數(shù)據(jù)而產(chǎn)生時延。其次，Nagle算法與延時確認之間的交互存在問題——Nagle會阻止數(shù)據(jù)的發(fā)送，直到有確認分組抵達為止，但確認分組自身會被延遲確認算法延遲100-200毫秒。
因此，HTTP應(yīng)用程序常常會在自己的棧中設(shè)置參數(shù)TCP_NODELAY,禁用Nagle算法，提高性能。

當(dāng)某個TCP端點關(guān)閉TCP連接時，會在內(nèi)存中維護一個小的控制塊，用來記錄最近所關(guān)閉連接的IP地址和端口號。這類信息會維持一小段時間，以確保在這段時間內(nèi)不會創(chuàng)建于相同地址和端口號的新連接。
客戶端每次連接到服務(wù)器上去時，都會獲得一個新的端口號，以實現(xiàn)連接的唯一性。但由于可用的源端口數(shù)量有限，因此會出現(xiàn)端口耗盡的情況。就會無法建立新的連接。
解決辦法：增加客戶端負載生成機器的數(shù)量，或者確?？蛻舳撕头?wù)器在循環(huán)使用幾個虛擬的IP地址以增加更多的連接組合。

HTTP允許在客戶端和最終的源端服務(wù)器之間存在一串HTTP中間實體(代理，高速緩存等)?？梢詮目蛻舳碎_始，逐跳地將HTTP報文經(jīng)過這些中間設(shè)備，轉(zhuǎn)發(fā)到源端服務(wù)器上去(或者進行反向傳輸)。

在某些情況下，兩個相鄰的HTTP應(yīng)用程序會為它們共享的連接應(yīng)用一組選項。HTTP的Connection首部字段中有一個由逗號分隔的連接標簽列表，這些標簽為此連接指定了一些不會傳播到其他連接中去的選項。
Connection首部可以承載3種不同類型的標簽

HTTP首部字段名，列出了只與此連接有關(guān)的首部

任意標簽值，用于描述此連接的非標準選項

值close，說明操作完成之后需關(guān)閉這條持久連接

如果支隊連接進行簡單的管理，TCP的性能時延可能會疊加起來。串行加載的另外一個缺點是，有些瀏覽器在對象加載完畢之前無法獲知對象的尺寸，而且它們可能需要尺寸信息來決定將對象放在屏幕的什么位置上，所以在加載了足夠多的對象之前，無法在屏幕上顯示任何內(nèi)容。

以下為4種提高HTTP連接性能的技術(shù)。

并行連接 通過多條TCP連接發(fā)起并發(fā)的HTTP請求

持久連接 重用TCP連接，以消除連接及關(guān)閉時延

管道化連接 通過共享的TCP連接發(fā)起并發(fā)的HTTP請求

復(fù)用的連接 交替?zhèn)魉驼埱蠛晚憫?yīng)報文 (實驗階段)

HTTP允許客戶端打開多條連接，并行地執(zhí)行多個HTTP事務(wù)。

并行連接可以提高符合頁面的傳輸速度，但并行連接也有一些缺點:

每個事務(wù)都會打開/關(guān)閉一條新的連接，好耗費時間和帶寬

由于TCP慢啟動特性的存在，每條新連接的性能會有所降低

可打開的并行連接數(shù)量實際上是有限的

Web客戶端經(jīng)常會打開到同一個站點的連接。因此，初始化了對某服務(wù)器的HTTP請求的應(yīng)用程序很可能會在不久的將來對那臺服務(wù)器發(fā)起更多的請求。這種性質(zhì)被稱為站點局部性。
因此，HTTP/1.1允許HTTP設(shè)備在事務(wù)處理結(jié)束之后將TCP連接保持在打開狀態(tài)，以便為將來的HTTP請求重用現(xiàn)存的連接。

在事務(wù)處理結(jié)束之后仍然保持在打開狀態(tài)的TCP連接被稱為持久連接。非持久連接會在每個事務(wù)結(jié)束之后關(guān)閉。持久連接會在不同事務(wù)之間保持打開狀態(tài)，直到客戶端或服務(wù)器決定將其關(guān)閉為止。
重用已對目標服務(wù)器打開的空閑持久連接，就可以避開緩慢的連接建立階段。而且，已經(jīng)打開的連接還可以避免慢啟動的擁塞適應(yīng)階段，以便更快速地進行數(shù)據(jù)的傳輸。

持久連接有一些比并行連接更好的地方。持久連接降低了時延和連接建立的開銷，將連接保持在已調(diào)諧狀態(tài)，而且減少了打開連接的潛在數(shù)量。(持久連接有兩種類型:比較老的HTTP/1.0+ "keep-alive"連接，以及現(xiàn)代的HTTP/1.1 "persistent"連接)

并行連接與持久連接配合使用可能是最高效的方式。

允許在持久連接上可選的使用請求管道，這是相對于keep-alive連接的又一性能優(yōu)化。
在響應(yīng)到達之前，可以將多條請求放入隊列。當(dāng)?shù)谝粭l請求通過網(wǎng)絡(luò)流向地球另一端的服務(wù)器時，第二條和第三條請求也可以開始發(fā)送了。在高時延網(wǎng)絡(luò)條件下，這樣做可以降低網(wǎng)絡(luò)的環(huán)回時間。

本文為《http權(quán)威指南》的第一部分，由第一到四章組成，介紹了HTTP的基礎(chǔ)構(gòu)件和HTTP的核心技術(shù)。希望大家能夠喜歡。