APP
HTTP/0.9
????????HTTP協(xié)議的最初版本，功能簡陋，僅支持請求方式GET，并且僅能請求訪問HTML格式的資源。
HTTP/1.0????
請求行必須在尾部添加協(xié)議版本字段（http/1.0）；必須包含頭消息? ? ? ??
在0.9版本上做了進(jìn)步，增加了請求方式POST和HEAD；不再局限于0.9版本的HTML格式，根據(jù)Content-Type可以支持多種數(shù)據(jù)格式，即MIME多用途互聯(lián)網(wǎng)郵件擴(kuò)展，例如text/html、image/jpeg等；同時(shí)也開始支持cache，就是當(dāng)客戶端在規(guī)定時(shí)間內(nèi)訪問統(tǒng)一網(wǎng)站，直接訪問cache即可。
再次，HTTP請求和回應(yīng)的格式也變了。除了數(shù)據(jù)部分，每次通信都必須包括頭信息（HTTP header），用來描述一些元數(shù)據(jù)。
其他的新增功能還包括狀態(tài)碼（status code）、多字符集支持、多部分發(fā)送（multi-part type）、權(quán)限（authorization）、緩存（cache）、內(nèi)容編碼（content encoding）等。
????????但是1.0版本的工作方式是每次TCP連接只能發(fā)送一個(gè)請求，當(dāng)服務(wù)器響應(yīng)后就會(huì)關(guān)閉這次連接，下一個(gè)請求需要再次建立TCP連接，就是不支持keepalive。
? ? ? ? TCP連接的新建成本很高，因?yàn)樾枰蛻舳撕头?wù)器三次握手，并且開始時(shí)發(fā)送速率較慢（slow start）。所以，HTTP 1.0版本的性能比較差。隨著網(wǎng)頁加載的外部資源越來越多，這個(gè)問題就愈發(fā)突出了。
為了解決這個(gè)問題，有些瀏覽器在請求時(shí)，用了一個(gè)非標(biāo)準(zhǔn)的Connection字段。
這個(gè)字段要求服務(wù)器不要關(guān)閉TCP連接，以便其他請求復(fù)用。服務(wù)器同樣回應(yīng)這個(gè)字段。
一個(gè)可以復(fù)用的TCP連接就建立了，直到客戶端或服務(wù)器主動(dòng)關(guān)閉連接。但是，這不是標(biāo)準(zhǔn)字段，不同實(shí)現(xiàn)的行為可能不一致，因此不是根本的解決辦法。
Content-Type 字段
關(guān)于字符的編碼，1.0版規(guī)定，頭信息必須是 ASCII 碼，后面的數(shù)據(jù)可以是任何格式。因此，服務(wù)器回應(yīng)的時(shí)候，必須告訴客戶端，數(shù)據(jù)是什么格式，這就是Content-Type字段的作用。
下面是一些常見的Content-Type字段的值。
- text/plain
- text/html
- text/css
- image/jpeg
- image/png
- image/svg+xml
- audio/mp4
- video/mp4
- application/javascript
- application/pdf
- application/zip
- application/atom+xml
這些數(shù)據(jù)類型總稱為MIME type，每個(gè)值包括一級(jí)類型和二級(jí)類型，之間用斜杠分隔。
除了預(yù)定義的類型，廠商也可以自定義類型。
上面的類型表明，發(fā)送的是Debian系統(tǒng)的二進(jìn)制數(shù)據(jù)包。
MIME type還可以在尾部使用分號(hào)，添加參數(shù)。
上面的類型表明，發(fā)送的是網(wǎng)頁，而且編碼是UTF-8。
客戶端請求的時(shí)候，可以使用Accept字段聲明自己可以接受哪些數(shù)據(jù)格式。
上面代碼中，客戶端聲明自己可以接受任何格式的數(shù)據(jù)。
MIME type不僅用在HTTP協(xié)議，還可以用在其他地方，比如HTML網(wǎng)頁。
Content-Encoding 字段
由于發(fā)送的數(shù)據(jù)可以是任何格式，因此可以把數(shù)據(jù)壓縮后再發(fā)送。Content-Encoding字段說明數(shù)據(jù)的壓縮方法。
客戶端在請求時(shí)，用Accept-Encoding字段說明自己可以接受哪些壓縮方法。
HTTP/1.1 ???
1.1 版的最大變化，就是引入了持久連接（persistent connection），即TCP連接默認(rèn)不關(guān)閉，可以被多個(gè)請求復(fù)用，不用聲明Connection: keep-alive。解決了1.0版本的keepalive問題，1.1版本加入了持久連接，一個(gè)TCP連接可以允許多個(gè)HTTP請求；
客戶端和服務(wù)器發(fā)現(xiàn)對方一段時(shí)間沒有活動(dòng)，就可以主動(dòng)關(guān)閉連接。不過，規(guī)范的做法是，客戶端在最后一個(gè)請求時(shí)，發(fā)送Connection: close，明確要求服務(wù)器關(guān)閉TCP連接。
目前，對于同一個(gè)域名，大多數(shù)瀏覽器允許同時(shí)建立6個(gè)持久連接。降低了延遲同時(shí)提高了帶寬的利用率。
? ??
加入了管道機(jī)制，在同一個(gè)TCP連接里，允許多個(gè)請求同時(shí)發(fā)送，增加了并發(fā)性，進(jìn)一步改善了HTTP協(xié)議的效率；舉例來說，客戶端需要請求兩個(gè)資源。以前的做法是，在同一個(gè)TCP連接里面，先發(fā)送A請求，然后等待服務(wù)器做出回應(yīng)，收到后再發(fā)出B請求。管道機(jī)制則是允許瀏覽器同時(shí)發(fā)出A請求和B請求，但是服務(wù)器還是按照順序，先回應(yīng)A請求，完成后再回應(yīng)B請求。
Content-Length 字段
一個(gè)TCP連接現(xiàn)在可以傳送多個(gè)回應(yīng)，勢必就要有一種機(jī)制，區(qū)分?jǐn)?shù)據(jù)包是屬于哪一個(gè)回應(yīng)的。這就是Content-length字段的作用，聲明本次回應(yīng)的數(shù)據(jù)長度。
上面代碼告訴瀏覽器，本次回應(yīng)的長度是3495個(gè)字節(jié)，后面的字節(jié)就屬于下一個(gè)回應(yīng)了。
在1.0版中，Content-Length字段不是必需的，因?yàn)闉g覽器發(fā)現(xiàn)服務(wù)器關(guān)閉了TCP連接，就表明收到的數(shù)據(jù)包已經(jīng)全了。
分塊傳輸編碼
使用Content-Length字段的前提條件是，服務(wù)器發(fā)送回應(yīng)之前，必須知道回應(yīng)的數(shù)據(jù)長度。
對于一些很耗時(shí)的動(dòng)態(tài)操作來說，這意味著，服務(wù)器要等到所有操作完成，才能發(fā)送數(shù)據(jù)，顯然這樣的效率不高。更好的處理方法是，產(chǎn)生一塊數(shù)據(jù)，就發(fā)送一塊，采用"流模式"（stream）取代"緩存模式"（buffer）。
因此，1.1版規(guī)定可以不使用Content-Length字段，而使用"分塊傳輸編碼"（chunked transfer encoding）。只要請求或回應(yīng)的頭信息有Transfer-Encoding字段，就表明回應(yīng)將由數(shù)量未定的數(shù)據(jù)塊組成。
每個(gè)非空的數(shù)據(jù)塊之前，會(huì)有一個(gè)16進(jìn)制的數(shù)值，表示這個(gè)塊的長度。最后是一個(gè)大小為0的塊，就表示本次回應(yīng)的數(shù)據(jù)發(fā)送完了。下面是一個(gè)例子。
新增了請求方式PUT、PATCH、OPTIONS、DELETE等。
另外，客戶端請求的頭信息新增了Host字段，用來指定服務(wù)器的域名。在HTTP1.0中認(rèn)為每臺(tái)服務(wù)器都綁定一個(gè)唯一的IP地址，因此，請求消息中的URL并沒有傳遞主機(jī)名（hostname）。但隨著虛擬主機(jī)技術(shù)的發(fā)展，在一臺(tái)物理服務(wù)器上可以存在多個(gè)虛擬主機(jī)（Multi-homed Web Servers），并且它們共享一個(gè)IP地址。
有了Host字段，就可以將請求發(fā)往同一臺(tái)服務(wù)器上的不同網(wǎng)站，為虛擬主機(jī)的興起打下了基礎(chǔ)。（實(shí)現(xiàn)了在一臺(tái)WEB服務(wù)器上可以在同一個(gè)IP地址和端口號(hào)上使用不同的主機(jī)名來創(chuàng)建多個(gè)虛擬WEB站點(diǎn)。也即是說，web server上的多個(gè)虛擬站點(diǎn)可以共享同一個(gè)ip和端口。）且請求消息中如果沒有Host頭域會(huì)報(bào)告一個(gè)錯(cuò)誤（400 Bad Request）。
????????雖然1.1版允許復(fù)用TCP連接，但是同一個(gè)TCP連接里面，所有的數(shù)據(jù)通信是按次序進(jìn)行的。服務(wù)端是按隊(duì)列順序處理請求的，服務(wù)器只有處理完一個(gè)回應(yīng)，才會(huì)進(jìn)行下一個(gè)回應(yīng)。假如前面的請求處理時(shí)間很長，后面就會(huì)有許多請求排隊(duì)等著，這樣就造成了“隊(duì)頭阻塞”的問題；同時(shí)HTTP是無狀態(tài)的連接，因此每次請求都需要添加重復(fù)的字段，降低了帶寬的利用率。
多路復(fù)用帶來一個(gè)新的問題是，在連接共享的基礎(chǔ)之上有可能會(huì)導(dǎo)致關(guān)鍵請求被阻塞。SPDY允許給每個(gè)request設(shè)置優(yōu)先級(jí)，這樣重要的請求就會(huì)優(yōu)先得到響應(yīng)。比如瀏覽器加載首頁，首頁的html內(nèi)容應(yīng)該優(yōu)先展示，之后才是各種靜態(tài)資源文件，腳本文件等加載，這樣可以保證用戶能第一時(shí)間看到網(wǎng)頁內(nèi)容。
為了避免這個(gè)問題，只有兩種方法：一是減少請求數(shù)，二是同時(shí)多開持久連接。這導(dǎo)致了很多的網(wǎng)頁優(yōu)化技巧，比如合并腳本和樣式表、將圖片嵌入CSS代碼、域名分片（domain sharding）等等。如果HTTP協(xié)議設(shè)計(jì)得更好一些，這些額外的工作是可以避免的。
100(Continue) Status(節(jié)約帶寬)
HTTP/1.1加入了一個(gè)新的狀態(tài)碼100（Continue）?？蛻舳耸孪劝l(fā)送一個(gè)只帶頭域的請求，如果服務(wù)器因?yàn)闄?quán)限拒絕了請求，就回送響應(yīng)碼401（Unauthorized）；如果服務(wù)器接收此請求就回送響應(yīng)碼100，客戶端就可以繼續(xù)發(fā)送帶實(shí)體的完整請求了。100 (Continue) 狀態(tài)代碼的使用，允許客戶端在發(fā)request消息body之前先用request header試探一下server，看server要不要接收request body，再?zèng)Q定要不要發(fā)request body。
HTTP/1.1在1.0的基礎(chǔ)上加入了一些cache的新特性，當(dāng)緩存對象的Age超過Expire時(shí)變?yōu)閟tale對象，cache不需要直接拋棄stale對象，而是與源服務(wù)器進(jìn)行重新激活（revalidation）。
HTTP 1.1支持只發(fā)送header信息(不帶任何body信息)，如果服務(wù)器認(rèn)為客戶端有權(quán)限請求服務(wù)器，則返回100，否則返回401?？蛻舳巳绻邮艿?00，才開始把請求body發(fā)送到服務(wù)器。這樣當(dāng)服務(wù)器返回401的時(shí)候，客戶端就可以不用發(fā)送請求body了，節(jié)約了帶寬。
HTTP1.1還有身份認(rèn)證機(jī)制，許多web站點(diǎn)要求用戶提供一個(gè)用戶名—口令對才能訪問存放在其服務(wù)器中的文檔，這種要求稱為身份認(rèn)證(authentication)。HTTP提供特殊的狀態(tài)碼和頭部來幫助Web站點(diǎn)執(zhí)行身份認(rèn)證。
HTTP支持傳送內(nèi)容的一部分。這樣當(dāng)客戶端已經(jīng)有一部分的資源后，只需要跟服務(wù)器請求另外的部分資源即可。這是支持文件斷點(diǎn)續(xù)傳的基礎(chǔ)。
HTTP/1.1支持文件斷點(diǎn)續(xù)傳，RANGE:bytes，HTTP/1.0每次傳送文件都是從文件頭開始，即0字節(jié)處開始。RANGE:bytes=XXXX表示要求服務(wù)器從文件XXXX字節(jié)處開始傳送，斷點(diǎn)續(xù)傳。即返回碼是206（Partial Content）
在HTTP1.1中新增了24個(gè)錯(cuò)誤狀態(tài)響應(yīng)碼，如409（Conflict）表示請求的資源與資源的當(dāng)前狀態(tài)發(fā)生沖突；410（Gone）表示服務(wù)器上的某個(gè)資源被永久性的刪除。
HTTP/2.0
????????為了解決1.1版本利用率不高的問題，提出了HTTP/2.0版本。增加雙工模式，即不僅客戶端能夠同時(shí)發(fā)送多個(gè)請求，服務(wù)端也能同時(shí)處理多個(gè)請求，解決了隊(duì)頭堵塞的問題（HTTP2.0使用了多路復(fù)用的技術(shù)，做到同一個(gè)連接并發(fā)處理多個(gè)請求，而且并發(fā)請求的數(shù)量比HTTP1.1大了好幾個(gè)數(shù)量級(jí)）；HTTP請求和響應(yīng)中，狀態(tài)行和請求/響應(yīng)頭都是些信息字段，并沒有真正的數(shù)據(jù)，因此在2.0版本中將所有的信息字段建立一張表，為表中的每個(gè)字段建立索引，客戶端和服務(wù)端共同使用這個(gè)表，他們之間就以索引號(hào)來表示信息字段，這樣就避免了1.0舊版本的重復(fù)繁瑣的字段，并以壓縮的方式傳輸，提高利用率。
????????另外也增加服務(wù)器推送的功能，即不經(jīng)請求服務(wù)端主動(dòng)向客戶端發(fā)送數(shù)據(jù)。
當(dāng)前主流的協(xié)議版本還是HTTP/1.1版本。
二進(jìn)制協(xié)議
HTTP/1.1 版的頭信息肯定是文本（ASCII編碼），數(shù)據(jù)體可以是文本，也可以是二進(jìn)制。HTTP/2 則是一個(gè)徹底的二進(jìn)制協(xié)議，頭信息和數(shù)據(jù)體都是二進(jìn)制，并且統(tǒng)稱為"幀"（frame）：頭信息幀和數(shù)據(jù)幀。
二進(jìn)制協(xié)議的一個(gè)好處是，可以定義額外的幀。HTTP/2 定義了近十種幀，為將來的高級(jí)應(yīng)用打好了基礎(chǔ)。如果使用文本實(shí)現(xiàn)這種功能，解析數(shù)據(jù)將會(huì)變得非常麻煩，二進(jìn)制解析則方便得多。
多工
HTTP/2 復(fù)用TCP連接，在一個(gè)連接里，客戶端和瀏覽器都可以同時(shí)發(fā)送多個(gè)請求或回應(yīng)，而且不用按照順序一一對應(yīng)，這樣就避免了"隊(duì)頭堵塞"。
舉例來說，在一個(gè)TCP連接里面，服務(wù)器同時(shí)收到了A請求和B請求，于是先回應(yīng)A請求，結(jié)果發(fā)現(xiàn)處理過程非常耗時(shí)，于是就發(fā)送A請求已經(jīng)處理好的部分， 接著回應(yīng)B請求，完成后，再發(fā)送A請求剩下的部分。
這樣雙向的、實(shí)時(shí)的通信，就叫做多工（Multiplexing）。
數(shù)據(jù)流
因?yàn)?HTTP/2 的數(shù)據(jù)包是不按順序發(fā)送的，同一個(gè)連接里面連續(xù)的數(shù)據(jù)包，可能屬于不同的回應(yīng)。因此，必須要對數(shù)據(jù)包做標(biāo)記，指出它屬于哪個(gè)回應(yīng)。
HTTP/2 將每個(gè)請求或回應(yīng)的所有數(shù)據(jù)包，稱為一個(gè)數(shù)據(jù)流（stream）。每個(gè)數(shù)據(jù)流都有一個(gè)獨(dú)一無二的編號(hào)。數(shù)據(jù)包發(fā)送的時(shí)候，都必須標(biāo)記數(shù)據(jù)流ID，用來區(qū)分它屬于哪個(gè)數(shù)據(jù)流。另外還規(guī)定，客戶端發(fā)出的數(shù)據(jù)流，ID一律為奇數(shù)，服務(wù)器發(fā)出的，ID為偶數(shù)。
數(shù)據(jù)流發(fā)送到一半的時(shí)候，客戶端和服務(wù)器都可以發(fā)送信號(hào)（RST_STREAM幀），取消這個(gè)數(shù)據(jù)流。1.1版取消數(shù)據(jù)流的唯一方法，就是關(guān)閉TCP連接。這就是說，HTTP/2 可以取消某一次請求，同時(shí)保證TCP連接還打開著，可以被其他請求使用。
客戶端還可以指定數(shù)據(jù)流的優(yōu)先級(jí)。優(yōu)先級(jí)越高，服務(wù)器就會(huì)越早回應(yīng)。
頭信息壓縮
HTTP 協(xié)議不帶有狀態(tài)，每次請求都必須附上所有信息。所以，請求的很多字段都是重復(fù)的，比如Cookie和User Agent，一模一樣的內(nèi)容，每次請求都必須附帶，這會(huì)浪費(fèi)很多帶寬，也影響速度。
HTTP/2 對這一點(diǎn)做了優(yōu)化，引入了頭信息壓縮機(jī)制（header compression）。一方面，頭信息使用gzip或compress壓縮后再發(fā)送；另一方面，客戶端和服務(wù)器同時(shí)維護(hù)一張頭信息表，所有字段都會(huì)存入這個(gè)表，生成一個(gè)索引號(hào)，以后就不發(fā)送同樣字段了，只發(fā)送索引號(hào)，這樣就提高速度了。
服務(wù)器推送
HTTP/2 允許服務(wù)器未經(jīng)請求，主動(dòng)向客戶端發(fā)送資源，這叫做服務(wù)器推送（server push）。
意思是說，當(dāng)我們對支持HTTP2.0的web server請求數(shù)據(jù)的時(shí)候，服務(wù)器會(huì)順便把一些客戶端需要的資源一起推送到客戶端，免得客戶端再次創(chuàng)建連接發(fā)送請求到服務(wù)器端獲取。這種方式非常合適加載靜態(tài)資源。
服務(wù)器端推送的這些資源其實(shí)存在客戶端的某處地方，客戶端直接從本地加載這些資源就可以了，不用走網(wǎng)絡(luò)，速度自然是快很多的。
常見場景是客戶端請求一個(gè)網(wǎng)頁，這個(gè)網(wǎng)頁里面包含很多靜態(tài)資源。正常情況下，客戶端必須收到網(wǎng)頁后，解析HTML源碼，發(fā)現(xiàn)有靜態(tài)資源，再發(fā)出靜態(tài)資源請求。其實(shí)，服務(wù)器可以預(yù)期到客戶端請求網(wǎng)頁后，很可能會(huì)再請求靜態(tài)資源，所以就主動(dòng)把這些靜態(tài)資源隨著網(wǎng)頁一起發(fā)給客戶端了。
服務(wù)端推送能把客戶端所需要的資源伴隨著index.html一起發(fā)送到客戶端，省去了客戶端重復(fù)請求的步驟。正因?yàn)闆]有發(fā)起請求，建立連接等操作，所以靜態(tài)資源通過服務(wù)端推送的方式可以極大地提升速度。
普通的客戶端請求過程：
服務(wù)端推送的過程：
HTTP 性能優(yōu)化的關(guān)鍵并不在于高帶寬，而是低延遲。TCP 連接會(huì)隨著時(shí)間進(jìn)行自我「調(diào)諧」，起初會(huì)限制連接的最大速度，如果數(shù)據(jù)成功傳輸，會(huì)隨著時(shí)間的推移提高傳輸?shù)乃俣?。這種調(diào)諧則被稱為 TCP 慢啟動(dòng)(擁塞控制)。由于這種原因，讓原本就具有突發(fā)性和短時(shí)性的 HTTP 連接變的十分低效。
HTTP/2 通過讓所有數(shù)據(jù)流共用同一個(gè)連接，可以更有效地使用 TCP 連接，讓高帶寬也能真正的服務(wù)于 HTTP 的性能提升。
二、HTTP響應(yīng)模型
????????服務(wù)器收到HTTP請求之后，會(huì)有多種方法響應(yīng)這個(gè)請求，下面是HTTP響應(yīng)的四種模型：
????????單進(jìn)程I/O模型
服務(wù)端開啟一個(gè)進(jìn)程，一個(gè)進(jìn)程僅能處理一個(gè)請求，并且對請求順序處理；
????????多進(jìn)程I/O模型
服務(wù)端并行開啟多個(gè)進(jìn)程，同樣的一個(gè)進(jìn)程只能處理一個(gè)請求，這樣服務(wù)端就可以同時(shí)處理多個(gè)請求；
????????復(fù)用I/O模型
服務(wù)端開啟一個(gè)進(jìn)程，但是呢，同時(shí)開啟多個(gè)線程，一個(gè)線程響應(yīng)一個(gè)請求，同樣可以達(dá)到同時(shí)處理多個(gè)請求，線程間并發(fā)執(zhí)行；
????????復(fù)用多線程I/O模型
服務(wù)端并行開啟多個(gè)進(jìn)程，同時(shí)每個(gè)進(jìn)程開啟多個(gè)線程，這樣服務(wù)端可以同時(shí)處理進(jìn)程數(shù)M*每個(gè)進(jìn)程的線程數(shù)N個(gè)請求。
本文摘自 ：https://www.cnblogs.com/
