本文介紹HTTP協(xié)議的歷史演變和設(shè)計(jì)思路，而下一遍文章關(guān)于HTTPS
摘要
- HTTP/0.9
- HTTP/1.0
- HTTP/1.1
- SPDY 協(xié)議
- HTTP/2
HTTP是基于TCP/IP協(xié)議的應(yīng)用層協(xié)議。它不設(shè)計(jì)數(shù)據(jù)包（packet）傳輸，主要規(guī)定了客戶端和服務(wù)器之間的通信格式，默認(rèn)使用80端口
一、HTTP/0.9
最早版本是1991年發(fā)布的0.9版。該版本及其簡單，只有一個命令GET
GET /index.html
上面命令表示，TCP連接（connection）建立后,客戶端向服務(wù)器請求（request）網(wǎng)頁index.html
協(xié)議規(guī)定，服務(wù)器只能回應(yīng)HTML格式的字符串，不能回應(yīng)別的格式
<html>
<body>Hello World</body>
</html>
服務(wù)器發(fā)送完畢，就關(guān)閉TCP連接
二、HTTP/1.0
2. 1簡介
1996年，HTTP/1.0版本發(fā)布，內(nèi)容大大增加
首先任何格式的內(nèi)容都可以發(fā)送。這使得互聯(lián)網(wǎng)不僅可以傳輸文字，還能傳輸圖像、視頻、二進(jìn)制文件。這為互聯(lián)網(wǎng)的大發(fā)展奠定了基礎(chǔ)
其次，除了GET命令，還引入了POST命令和HEAD命令，豐富了瀏覽器和服務(wù)器的互動手段
再次，HTTP請求和回應(yīng)的格式也變了。除了數(shù)據(jù)部分，每次通信都必須頭信息（HTTP header）,用來描述一些元數(shù)據(jù)
其他的新增功能還包括狀態(tài)碼（status code）、多字符集支持、多部分發(fā)送（multi-part type）、權(quán)限（authorization）、緩存（cache）、內(nèi)容編碼（content ）等
2.2 請求格式
下面是一個1.0版的HTTP請求的例子
GET / HTTP/1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5)
Accept: */*
可以看到，這個格式與0.9版有很大變化
第一行是請求命令，必須在尾部添加協(xié)議版本（HTTP/1.0）。后面是多行頭信息，描述客戶端的情況
2.3 回應(yīng)格式
服務(wù)器的回應(yīng)如下
HTTP/1.0 200 OK
Content-Type: text/plain
Content-Length: 137582
Expires: Thu, 05 Dec 1997 16:00:00 GMT
Last-Modified: Wed, 5 August 1996 15:55:28 GMT
Server: Apache 0.84
<html>
<body>Hello World</body>
</html
回應(yīng)的格式是“頭信息 + 一個空行 + 數(shù)據(jù)”。其中，第一行是“協(xié)議版本 + 狀態(tài)碼（status code） + 狀態(tài)描述”
2.4 Content-Type字段
Content-Type服務(wù)器回應(yīng)的時候（response），必須告訴客戶端，數(shù)據(jù)是什么格式
下面是常見的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，每個值包括一級類型和二級類型，之間通斜杠分割。就像Win文件的后綴名一樣，MIME 讓人和瀏覽器知道這是什么文件，改作什么處理
MIME type還可以在尾部使用分號，添加參數(shù)。
Content-Type: text/html; charset=utf-8
上面的類型表明，發(fā)送的是網(wǎng)頁，而且編碼啊是UTF-8
客戶端請求的時候，可以使用Accept字段聲明自己可以接受那些數(shù)據(jù)格式
Accept:*/*
上面代碼中，客戶端聲明自己可以接受任何格式的數(shù)據(jù)
MIME type不僅用在HTTP協(xié)議，還可以同在其他地方，比如HTML網(wǎng)頁
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<!-- 等同于 -->
<meta charset="utf-8" />
2.5 Content-Encoding字段
Content-Encoding字段說明數(shù)據(jù)的壓縮方法.由于發(fā)送的數(shù)據(jù)可以是任何格式，因此可以把數(shù)據(jù)壓縮后在發(fā)送。
Content-Encoding: gzip
Content-Encoding: compress
Content-Encoding: deflate
客戶端在請求時，通Accept-Encoding字段說明自己可以接受那些壓縮方法
Accept-Encoding: gzip, deflate
2.6 缺點(diǎn)
HTTP/1.0 版的主要缺點(diǎn)是，每個TCP連接只能發(fā)送一個請求。發(fā)送數(shù)據(jù)完畢，連接就關(guān)閉，如果還要請求其他資源，就必須再新建一個連接
TCP連接的新建成本很高，因?yàn)樾枰蛻舳撕头?wù)器三次握手，并且開始時發(fā)送 速率較慢（slow start）。所以。HTTP/1.0版本的性能比較差。隨著網(wǎng)頁加載的外部資源越來越多，這個問題就愈發(fā)突出了
為了解決這個問題，有些瀏覽器在請求時，用了一個非標(biāo)準(zhǔn)的Connection字段
Connection: keep-alive
這個字段要求服務(wù)器就不要關(guān)閉TCP連接，以便其他請求復(fù)用。服務(wù)器同樣回應(yīng)這個字段
Connection: keep-alive
一個可以復(fù)用的TCP連接就建立了，知道客戶端或服務(wù)器主動關(guān)閉連接。但是，這不是標(biāo)準(zhǔn)字段，不同實(shí)現(xiàn)的行為可能不一致，因此不是根本的解決方法
三、HTTP/1.1
1997年1月，HTTP/1.1斑斑發(fā)布，只比1.0版晚了半年。它進(jìn)一步完善了HTTP協(xié)議，一直用到了21多年后的今天，知道現(xiàn)在還是最流行的版本
3.1持久連接（persistent connection）
最大的變化，就是引入了持久連接,即TCP連接默認(rèn)不關(guān)閉，可以被多個請求復(fù)用，不用聲明Connection: keep-alive
客戶端和服務(wù)器發(fā)現(xiàn)對方一段時間沒有活動，就可以主動關(guān)閉連接。不過，規(guī)范的做法是，客戶端最后一個請求時，發(fā)送Connection: close，明確要求服務(wù)器關(guān)閉TCP連接
Connection: close
目前，對于同一個域名，大多數(shù)瀏覽器允許同時建立6個持久連接
3.2 管道機(jī)制（pipelining）
1.1版還引入了管道機(jī)制，即在同一個TCP連接里面，客戶端可以同時發(fā)送多個請求。這樣就進(jìn)一步改進(jìn)了HTTP協(xié)議的效率
距離來說，客戶端需要請求兩個資源。以前的做法是，同一個TCP連接里面，先發(fā)送A請求，然后等待服務(wù)器做出回應(yīng)，收到后在發(fā)出B請求。管道機(jī)制允許瀏覽器同時發(fā)出A請求和B請求，但是服務(wù)器還是按照順序，先回應(yīng)A請求，完成后再回應(yīng)B請求。
3.3 Content-Length字段
Content-Length聲明本次回應(yīng)的數(shù)據(jù)長度?，F(xiàn)在一個TCP連接可以傳送多個回應(yīng)，勢必要有一種機(jī)制，區(qū)分?jǐn)?shù)據(jù)包是屬于哪一個回應(yīng)的。
Content-Length: 3495
上面的代碼告訴瀏覽器，本次回應(yīng)的長度是3495個字節(jié)，后面的字節(jié)就屬于下一個回應(yīng)了
在1.0版本中，Content-Length字段不是必須要的，因?yàn)闉g覽器發(fā)現(xiàn)服務(wù)器關(guān)閉了TCP連接，就表明收到的數(shù)據(jù)包已經(jīng)全的
3.4 分塊傳輸編碼
使用Content-Length字段的前提條件是，服務(wù)器發(fā)送回應(yīng)之前，必須知道回應(yīng)的數(shù)據(jù)長度
對于一些耗時的動態(tài)操作來說，這意味著，服務(wù)器要等到所有的操作完成，才能發(fā)送數(shù)據(jù)，顯然這樣的效率不高。
更好的處理方式是：產(chǎn)生一塊數(shù)據(jù)，就發(fā)送一塊，采用“流模式”(stream)取代“緩存模式”(buffer)
因此，1.1版本可以不使用Content-Length字段，而是用"分塊傳輸編碼"（chunked transfer encoding）。只要請求或回應(yīng)的頭信息有Transfer-Encoding字段，就表明回應(yīng)將由數(shù)量未定的數(shù)據(jù)塊組成
Transfer-Encoding: chunked
每個非空的數(shù)據(jù)塊之前，會有一個16進(jìn)制的數(shù)值，表示這個塊的長度。最后是一個大小為0的塊，就表示本次回應(yīng)的數(shù)據(jù)發(fā)送完了。下面就是一個例子
HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked
25
This is the data in the first chunk
1C
and this is the second one
3
con
8
sequence
0
3.5 其他功能
1.1版還新增了許多動詞方法：PUT、PATCH、HEAD、 OPTIONS、DELETE。
另外，客戶端請求的頭信息新增了HOST字段，同來制定服務(wù)器的域名
Host: www.example.com
有了Host字段，就可以將請求發(fā)往同一臺服務(wù)器上的不同網(wǎng)站，為虛擬主機(jī)的興起打下了基礎(chǔ)。
3.6 缺點(diǎn)
雖然1.1版本允許復(fù)用TCP連接，但是同一個TCP連接里面，所有的數(shù)據(jù)通信是按次序進(jìn)行。服務(wù)器只有處理完一個回應(yīng)，才會進(jìn)行下一個回應(yīng)。要是前面的回應(yīng)特別慢，后面就會有許多請求排隊(duì)等著。這稱為"隊(duì)頭堵塞"（Head-of-line blocking）。
為了避免這個問題，只有兩種方法：
一是減少HTTP請求數(shù)，二是同時多開TCP持久連接。這引出了很多的網(wǎng)頁優(yōu)化技巧，比如合并腳本和樣式表、將圖片嵌入CSS代碼
域名分片（domain sharding）等等。如果HTTP協(xié)議設(shè)計(jì)得更好一些，這些額外的工作是可以避免的。
四、SPDY協(xié)議
2009年，谷歌公開了自行研發(fā)的SPDY協(xié)議，主要解決HTTP/1.1效率不高的問題
這個協(xié)議在Chrome瀏覽器上證明可行以后，就被當(dāng)作 HTTP/2 的基礎(chǔ)，主要特性都在 HTTP/2 之中得到繼承。
五、HTTP/2
2015年，HTTP/2 發(fā)布。它不叫 HTTP/2.0，是因?yàn)闃?biāo)準(zhǔn)委員會不打算再發(fā)布子版本了，下一個新版本將是 HTTP/3。
5.1二進(jìn)制協(xié)議
HTTP/1.1 版的頭信息肯定是文本（ASCII編碼），數(shù)據(jù)體可以是文本，也可以是二進(jìn)制。HTTP/2 則是一個徹底的二進(jìn)制協(xié)議，頭信息和數(shù)據(jù)體都是二進(jìn)制，并且統(tǒng)稱為"幀"（frame）：頭信息幀和數(shù)據(jù)幀。
5.2多工
HTTP/2復(fù)用TCP連接，在一個連接里，客戶端和瀏覽器都可以同時發(fā)送多個請求和回應(yīng)，而且不同按順序意義都贏，這樣就避免了“隊(duì)頭堵塞”
舉例來說，在一個TCP連接里面，服務(wù)器同時接受了A請求和B請求，于是先回應(yīng)A請求，解結(jié)果返現(xiàn)處理過程非常耗時時，于是就發(fā)送A請求已經(jīng)處理好的部分，接著回應(yīng)Ｂ請求，完成后，在發(fā)送Ａ請求剩下的部分
這樣雙向的、實(shí)時的通信，就叫做多工
5.3數(shù)據(jù)流
因?yàn)镠TTP/2的數(shù)據(jù)包是不按順序發(fā)送的，同一個連接里面連續(xù)的數(shù)據(jù)包，可能屬于不同的回應(yīng)。因此，必須對數(shù)據(jù)包做標(biāo)記，指出它屬于那個回應(yīng)
HTTP/2將每個請求或回應(yīng)的所有數(shù)據(jù)包，稱為一個數(shù)據(jù)流(stream)。每個數(shù)據(jù)流都有一個第一無二的編號。數(shù)據(jù)發(fā)送的時候，都必須標(biāo)記數(shù)據(jù)流ID，用來區(qū)分它屬于那個數(shù)據(jù)流。另外還規(guī)定，客戶端發(fā)出的數(shù)據(jù)流，ID一律為奇數(shù)，服務(wù)器發(fā)出的，ID為偶數(shù)
數(shù)據(jù)流發(fā)送到一半的時候，客戶端和服務(wù)器都可以發(fā)送信號（RST_STREAM幀），取消這個數(shù)據(jù)流。1.1版取消數(shù)據(jù)流的唯一方法，就是關(guān)閉TCP連接。這就是說，HTTP/2 可以取消某一次請求，同時保證TCP連接還打開著，可以被其他請求使用。
客戶端還可以指定數(shù)據(jù)流的優(yōu)先級。優(yōu)先級越高，服務(wù)器就會越早回應(yīng)。
5.4頭信息壓縮
HTTP是無狀態(tài)協(xié)議，每次請求都必須附上所有信息。所以，請求的很多字段都是重復(fù)的，比如cookie和User Agent，一模一樣的美容，每次請求都必須附帶，這會浪費(fèi)很多貸款，也影響速度
HTTP/2對這一點(diǎn)做了優(yōu)化，引入了頭信息壓縮機(jī)制（header compression）。一方面，頭信息使用gzip或compress壓縮后再發(fā)送；另一方面，客戶端和服務(wù)端同時維護(hù)一張頭信息表，所有字段都會存入這個表，生成一個索引紅啊，以后就不發(fā)送同樣的字段了，只發(fā)送索引號，這樣就提高速度了
5.5服務(wù)器推送
HTTP/2允許服務(wù)器未經(jīng)請求，主動向客戶端發(fā)送資源，這叫做服務(wù)器推送（server push）
常見場景是客戶端請求一個網(wǎng)頁，這個網(wǎng)頁里面很多靜態(tài)資源。正常情況下，客戶端必須收到網(wǎng)頁后，解析HTML源碼，發(fā)現(xiàn)有靜態(tài)資源，再發(fā)出靜態(tài)資源請求。其實(shí)，服務(wù)器可以預(yù)期到客戶端請求網(wǎng)頁后，很可能會再請求靜態(tài)資源，所以就主動把這些靜態(tài)資源隨著網(wǎng)頁一起發(fā)給客戶端了
總結(jié)
- HTTP/0.9 客戶端只能發(fā)送get請求，服務(wù)端只能響應(yīng)HTML文件
- HTTP/1.0 多了POST和HEAD請求，頭信息多了
Content-type、Content-Encoding等有用的字段，明顯的缺點(diǎn)是一次TCP連接只能發(fā)送一次請求 - HTTP/1.1 持久連接、管道機(jī)制、 Content-Length字段、分塊傳輸編碼、HOST字段、多個請求方法，明顯的缺點(diǎn)是“隊(duì)頭阻塞”
- HTTP/2 二進(jìn)制協(xié)議、多工通信、數(shù)據(jù)流、頭信息壓縮、服務(wù)器推送
