用一張表大概描述：
一寂诱、HTTP/0.9
HTTP 是基于 TCP/IP 協(xié)議的應用層協(xié)議。它不涉及數據包（packet）傳輸，主要規(guī)定了客戶端和服務器之間的通信格式，默認使用80端口瑰抵。
最早版本是1991年發(fā)布的0.9版乔煞。該版本極其簡單岭辣，只有一個命令GET搁廓。
GET /index.html
上面命令表示，TCP 連接（connection）建立后诵冒，客戶端向服務器請求（request）網頁index.html凯肋。
協(xié)議規(guī)定，服務器只能回應HTML格式的字符串汽馋，不能回應別的格式侮东。
服務器發(fā)送完畢，就關閉TCP連接豹芯。
二悄雅、HTTP/1.0
1996年5月，HTTP/1.0 版本發(fā)布铁蹈，內容大大增加宽闲。
首先，任何格式的內容都可以發(fā)送握牧。這使得互聯網不僅可以傳輸文字容诬，還能傳輸圖像、視頻沿腰、二進制文件览徒。這為互聯網的大發(fā)展奠定了基礎。
其次颂龙，除了GET命令习蓬，還引入了POST命令和HEAD命令纽什，豐富了瀏覽器與服務器的互動手段。
再次友雳，HTTP請求和回應的格式也變了稿湿。除了數據部分，每次通信都必須包括頭信息（HTTP header）押赊，用來描述一些元數據。
其他的新增功能還包括狀態(tài)碼（status code）包斑、多字符集支持流礁、多部分發(fā)送（multi-part type）、權限（authorization）罗丰、緩存（cache）神帅、內容編碼（content encoding）等。
2.2 請求格式
下面是一個1.0版的HTTP請求的例子萌抵。
GET/ HTTP/1.0
User-Agent: Mozilla/5.0(Macintosh;Intel Mac OSX10_10_5)
Accept: /
可以看到找御，這個格式與0.9版有很大變化。
第一行是請求命令绍填，必須在尾部添加協(xié)議版本（HTTP/1.0）霎桅。后面就是多行頭信息，描述客戶端的情況讨永。
2.3 回應格式
服務器的回應如下滔驶。
HTTP/1.0 200 OK
Content-Type: text/plain
Content-Length: 137582
Expires: Thu,05Dec199716:00:00GMT
Last-Modified: Wed,5August199615:55:28GMT
Server: Apache0.84
回應的格式是”頭信息 + 一個空行（\r\n） + 數據”。其中卿闹，第一行是”協(xié)議版本 + 狀態(tài)碼（status code） + 狀態(tài)描述”揭糕。
2.4 Content-Type 字段
關于字符的編碼，1.0版規(guī)定锻霎，頭信息必須是 ASCII 碼著角，后面的數據可以是任何格式。因此旋恼，服務器回應的時候吏口，必須告訴客戶端，數據是什么格式蚌铜，這就是Content-Type字段的作用锨侯。
下面是一些常見的Content-Type字段的值。
text/plain
text/html
text/css
image/jpeg
image/png
image/svg+xml
audio/mp4
video/mp4
application/java
application/pdf
application/zip
application/atom+xml
這些數據類型總稱為MIME type冬殃，每個值包括一級類型和二級類型囚痴，之間用斜杠分隔。
除了預定義的類型审葬，廠商也可以自定義類型深滚。
application/vnd.debian.binary-package
上面的類型表明奕谭，發(fā)送的是Debian系統(tǒng)的二進制數據包。
MIME type還可以在尾部使用分號痴荐，添加參數血柳。
Content-Type: text/html; charset=utf-8
上面的類型表明，發(fā)送的是網頁生兆，而且編碼是UTF-8难捌。
客戶端請求的時候，可以使用Accept字段聲明自己可以接受哪些數據格式鸦难。
Accept: /
上面代碼中根吁，客戶端聲明自己可以接受任何格式的數據。
MIME type不僅用在HTTP協(xié)議合蔽，還可以用在其他地方击敌，比如HTML網頁。
<meta http-equiv="Content-Type" content="text/html;charset= utf-8"
2.5 Content-Encoding 字段
由于發(fā)送的數據可以是任何格式拴事，因此可以把數據壓縮后再發(fā)送沃斤。Content-Encoding字段說明數據的壓縮方法。
Content-Encoding: gzip
Content-Encoding: compress
Content-Encoding: deflate
客戶端在請求時刃宵，用Accept-Encoding字段說明自己可以接受哪些壓縮方法衡瓶。
Accept-Encoding: gzip, deflate
2.6 缺點
HTTP/1.0 版的主要缺點是，每個TCP連接只能發(fā)送一個請求组去。發(fā)送數據完畢鞍陨，連接就關閉，如果還要請求其他資源从隆，就必須再新建一個連接诚撵。
TCP連接的新建成本很高，因為需要客戶端和服務器三次握手键闺，并且開始時發(fā)送速率較慢（slow start）寿烟。所以，HTTP 1.0版本的性能比較差辛燥。隨著網頁加載的外部資源越來越多筛武，這個問題就愈發(fā)突出了。
為了解決這個問題挎塌，有些瀏覽器在請求時徘六，用了一個非標準的Connection字段。
Connection: keep-alive
這個字段要求服務器不要關閉TCP連接榴都，以便其他請求復用待锈。服務器同樣回應這個字段。
Connection: keep-alive
一個可以復用的TCP連接就建立了嘴高，直到客戶端或服務器主動關閉連接竿音。但是和屎，這不是標準字段，不同實現的行為可能不一致春瞬，因此不是根本的解決辦法柴信。
三、HTTP/1.1
1997年1月宽气，HTTP/1.1 版本發(fā)布随常，只比 1.0 版本晚了半年。它進一步完善了 HTTP 協(xié)議抹竹，一直用到了20年后的今天线罕，直到現在還是最流行的版本。
3.1 持久連接
1.1 版的最大變化窃判，就是引入了持久連接（persistent connection），即TCP連接默認不關閉喇闸，可以被多個請求復用袄琳，不用聲明Connection: keep-alive。
客戶端和服務器發(fā)現對方一段時間沒有活動燃乍，就可以主動關閉連接唆樊。不過，規(guī)范的做法是刻蟹，客戶端在最后一個請求時逗旁，發(fā)送Connection: close，明確要求服務器關閉TCP連接舆瘪。
Connection: close
目前片效，對于同一個域名，大多數瀏覽器允許同時建立6個持久連接英古。
3.2 管道機制
1.1 版還引入了管道機制（pipelining）淀衣，即在同一個TCP連接里面，客戶端可以同時發(fā)送多個請求召调。這樣就進一步改進了HTTP協(xié)議的效率膨桥。
舉例來說，客戶端需要請求兩個資源唠叛。以前的做法是只嚣，在同一個TCP連接里面，先發(fā)送A請求艺沼，然后等待服務器做出回應册舞，收到后再發(fā)出B請求。管道機制則是允許瀏覽器同時發(fā)出A請求和B請求澳厢，但是服務器還是按照順序环础，先回應A請求囚似，完成后再回應B請求。
3.3 Content-Length 字段
一個TCP連接現在可以傳送多個回應线得，勢必就要有一種機制饶唤，區(qū)分數據包是屬于哪一個回應的。這就是Content-length字段的作用贯钩，聲明本次回應的數據長度募狂。
Content-Length: 3495
上面代碼告訴瀏覽器，本次回應的長度是3495個字節(jié)角雷，后面的字節(jié)就屬于下一個回應了祸穷。
在1.0版中，Content-Length字段不是必需的勺三，因為瀏覽器發(fā)現服務器關閉了TCP連接雷滚，就表明收到的數據包已經全了。
3.4 分塊傳輸編碼
使用Content-Length字段的前提條件是吗坚，服務器發(fā)送回應之前祈远，必須知道回應的數據長度。
對于一些很耗時的動態(tài)操作來說商源，這意味著车份，服務器要等到所有操作完成，才能發(fā)送數據牡彻，顯然這樣的效率不高扫沼。更好的處理方法是，產生一塊數據庄吼，就發(fā)送一塊缎除，采用”流模式”（stream）取代”緩存模式”（buffer）。
因此霸褒，1.1版規(guī)定可以不使用Content-Length字段伴找，而使用“分塊傳輸編碼”（chunked transfer encoding）。只要請求或回應的頭信息有Transfer-Encoding字段废菱，就表明回應將由數量未定的數據塊組成技矮。
Transfer-Encoding: chunked
每個非空的數據塊之前，會有一個16進制的數值殊轴，表示這個塊的長度衰倦。最后是一個大小為0的塊，就表示本次回應的數據發(fā)送完了旁理。下面是一個例子樊零。
HTTP/1.1200OK
Content-Type: text/plain
Transfer-Encoding: chunked
25
Thisisthe data inthe first chunk
1C
andthisisthe second one
3
con
8
sequence
0
3.5 其他功能
1.1版還新增了許多動詞方法：PUT、PATCH、HEAD驻襟、 OPTIONS夺艰、DELETE。另外沉衣，客戶端請求的頭信息新增了Host字段郁副，用來指定服務器的域名。Host: www.example.com有了Host字段豌习，就可以將請求發(fā)往同一臺服務器上的不同網站存谎，為虛擬主機的興起打下了基礎。
3.6 缺點 - 也可以說是優(yōu)化項
雖然1.1版允許復用TCP連接肥隆，但是同一個TCP連接里面既荚，所有的數據通信是按次序進行的。服務器只有處理完一個回應栋艳，才會進行下一個回應恰聘。要是前面的回應特別慢，后面就會有許多請求排隊等著吸占。這稱為“隊頭堵塞”（Head-of-line blocking）憨琳。
為了避免這個問題，只有兩種方法：一是減少請求數旬昭，二是同時多開持久連接。這導致了很多的網頁優(yōu)化技巧菌湃，比如合并腳本和樣式表问拘、將圖片嵌入CSS代碼、域名分片（domain sharding）等等惧所。如果HTTP協(xié)議設計得更好一些骤坐，這些額外的工作是可以避免的。
四下愈、SPDY 協(xié)議
2009年纽绍，谷歌公開了自行研發(fā)的 SPDY 協(xié)議，主要解決 HTTP/1.1 效率不高的問題势似。
這個協(xié)議在Chrome瀏覽器上證明可行以后拌夏，就被當作 HTTP/2 的基礎，主要特性都在 HTTP/2 之中得到繼承履因。
五障簿、HTTP/2
2015年，HTTP/2 發(fā)布栅迄。它不叫 HTTP/2.0站故，是因為標準委員會不打算再發(fā)布子版本了，下一個新版本將是 HTTP/3毅舆。
5.1 二進制協(xié)議
HTTP/1.1 版的頭信息肯定是文本（ASCII編碼）西篓，數據體可以是文本愈腾，也可以是二進制。HTTP/2 則是一個徹底的二進制協(xié)議岂津，頭信息和數據體都是二進制虱黄，并且統(tǒng)稱為”幀”（frame）：頭信息幀和數據幀。
二進制協(xié)議的一個好處是寸爆，可以定義額外的幀礁鲁。HTTP/2 定義了近十種幀，為將來的高級應用打好了基礎赁豆。如果使用文本實現這種功能仅醇，解析數據將會變得非常麻煩，二進制解析則方便得多魔种。
5.2 多工
HTTP/2 復用TCP連接析二，在一個連接里，客戶端和瀏覽器都可以同時發(fā)送多個請求或回應节预，而且不用按照順序一一對應叶摄，這樣就避免了”隊頭堵塞”。
舉例來說安拟，在一個TCP連接里面蛤吓，服務器同時收到了A請求和B請求，于是先回應A請求糠赦，結果發(fā)現處理過程非常耗時会傲，于是就發(fā)送A請求已經處理好的部分， 接著回應B請求拙泽，完成后淌山，再發(fā)送A請求剩下的部分。
這樣雙向的顾瞻、實時的通信泼疑，就叫做多工（Multiplexing）。
5.3 數據流
因為 HTTP/2 的數據包是不按順序發(fā)送的荷荤，同一個連接里面連續(xù)的數據包退渗，可能屬于不同的回應。因此梅猿，必須要對數據包做標記氓辣，指出它屬于哪個回應。
HTTP/2 將每個請求或回應的所有數據包袱蚓，稱為一個數據流（stream）钞啸。每個數據流都有一個獨一無二的編號。數據包發(fā)送的時候，都必須標記數據流ID体斩，用來區(qū)分它屬于哪個數據流梭稚。另外還規(guī)定，客戶端發(fā)出的數據流絮吵，ID一律為奇數弧烤，服務器發(fā)出的，ID為偶數蹬敲。
數據流發(fā)送到一半的時候暇昂，客戶端和服務器都可以發(fā)送信號（RST_STREAM幀），取消這個數據流伴嗡。1.1版取消數據流的唯一方法急波，就是關閉TCP連接。這就是說瘪校，HTTP/2 可以取消某一次請求澄暮，同時保證TCP連接還打開著，可以被其他請求使用阱扬。
客戶端還可以指定數據流的優(yōu)先級泣懊。優(yōu)先級越高，服務器就會越早回應麻惶。
5.4 頭信息壓縮
HTTP 協(xié)議不帶有狀態(tài)馍刮，每次請求都必須附上所有信息。所以窃蹋，請求的很多字段都是重復的渠退，比如Cookie和User Agent，一模一樣的內容脐彩，每次請求都必須附帶，這會浪費很多帶寬姊扔，也影響速度惠奸。
HTTP/2 對這一點做了優(yōu)化，引入了頭信息壓縮機制（header compression）恰梢。一方面佛南，頭信息使用gzip或compress壓縮后再發(fā)送；另一方面嵌言，客戶端和服務器同時維護一張頭信息表嗅回，所有字段都會存入這個表，生成一個索引號摧茴，以后就不發(fā)送同樣字段了绵载，只發(fā)送索引號，這樣就提高速度了。
5.5 服務器推送
HTTP/2 允許服務器未經請求娃豹，主動向客戶端發(fā)送資源焚虱，這叫做服務器推送（server push）。
常見場景是客戶端請求一個網頁懂版，這個網頁里面包含很多靜態(tài)資源鹃栽。正常情況下，客戶端必須收到網頁后躯畴，解析HTML源碼民鼓，發(fā)現有靜態(tài)資源，再發(fā)出靜態(tài)資源請求蓬抄。其實丰嘉，服務器可以預期到客戶端請求網頁后，很可能會再請求靜態(tài)資源倡鲸，所以就主動把這些靜態(tài)資源隨著網頁一起發(fā)給客戶端了供嚎。
