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

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

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

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

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

web頁(yè)面可以包含多個(gè)對(duì)象，如一個(gè)頁(yè)面會(huì)包括許多圖片，視頻，音頻等內(nèi)容。客戶端通過(guò)向Web服務(wù)器發(fā)送請(qǐng)求命令來(lái)進(jìn)行事務(wù)處理。服務(wù)器響應(yīng)客戶端請(qǐng)求，并傳送相應(yīng)數(shù)據(jù)。

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

起始行 GET /index.html HTTP/1.0

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

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

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

無(wú)差錯(cuò)的數(shù)據(jù)傳輸

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

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

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

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

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

緩存 HTTP的倉(cāng)庫(kù)，使常用頁(yè)面的副本可以保存在離客戶端更近的地方

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

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

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

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

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

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

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

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

請(qǐng)求報(bào)文

響應(yīng)報(bào)文

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

當(dāng)前的HTTP版本只為每類狀態(tài)定義了幾個(gè)代碼，隨著協(xié)議的發(fā)展，HTTP規(guī)范中會(huì)正式的定義更多的狀態(tài)碼，如果收到了不認(rèn)識(shí)的狀態(tài)碼，可能是有人將其作為當(dāng)前協(xié)議的擴(kuò)展定義的。可以根據(jù)其所處范圍，將它作為那個(gè)類別中一個(gè)普通的成員來(lái)處理。

首部分類：

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

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

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

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

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

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

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

https://github.com:80/WilsonLiu95

瀏覽器利用解析出主機(jī)名 github.com

瀏覽器查詢這個(gè)主機(jī)名的IP地址 192.30.252.122

瀏覽器獲得端口號(hào) 80

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

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

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

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

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

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

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

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

因特網(wǎng)傳輸報(bào)文，以及服務(wù)器處理請(qǐng)求報(bào)文都需要花費(fèi)時(shí)間。

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

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

TCP連接建立握手

TCP慢啟動(dòng)擁塞控制

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

用于捎帶確認(rèn)的TCP延遲確認(rèn)算法

TIME_WAIT時(shí)延和端口耗盡

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

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

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

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

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

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

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

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

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

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

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

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

任意標(biāo)簽值，用于描述此連接的非標(biāo)準(zhǔn)選項(xiàng)

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

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

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

并行連接 通過(guò)多條TCP連接發(fā)起并發(fā)的HTTP請(qǐng)求

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

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

復(fù)用的連接 交替?zhèn)魉驼?qǐng)求和響應(yīng)報(bào)文 (實(shí)驗(yàn)階段)

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

并行連接可以提高符合頁(yè)面的傳輸速度，但并行連接也有一些缺點(diǎn):

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

由于TCP慢啟動(dòng)特性的存在，每條新連接的性能會(huì)有所降低

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

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

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

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

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

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

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