1、網(wǎng)頁開發(fā)基礎(chǔ)教程 HTTP 協(xié)議入門HTTP 協(xié)議是互聯(lián)網(wǎng)的基礎(chǔ)協(xié)議，也是網(wǎng)頁開發(fā)的必備知識，最新版本 HTTP/2 更是讓它成為技術(shù)熱點。本文介紹 HTTP 協(xié)議的歷史演變和設(shè)計思路。一、HTTP/0.9HTTP 是基于 TCP/IP 協(xié)議的應(yīng)用層協(xié)議。它不涉及數(shù)據(jù)包(packet)傳輸，主要規(guī)定了客戶端和服務(wù)器之間的通信格式，默認使用80端口。最早版本是1991年發(fā)布的0.9版。該版本極其簡單，只有一個命令GET。GET /index.html上面命令表示，TCP 連接(connection)建立后，客戶端向服務(wù)器請求(request)網(wǎng)頁index.html。協(xié)議規(guī)定，服務(wù)器只能回應(yīng)HT

2、ML格式的字符串，不能回應(yīng)別的格式。Hello World服務(wù)器發(fā)送完畢，就關(guān)閉TCP連接。二、HTTP/1.02.1 簡介1996年5月，HTTP/1.0 版本發(fā)布，內(nèi)容大大增加。首先，任何格式的內(nèi)容都可以發(fā)送。這使得互聯(lián)網(wǎng)不僅可以傳輸文字，還能傳輸圖像、視頻、二進制文件。這為互聯(lián)網(wǎng)的大發(fā)展奠定了基礎(chǔ)。其次，除了GET命令，還引入了POST命令和HEAD命令，豐富了瀏覽器與服務(wù)器的互動手段。再次，HTTP請求和回應(yīng)的格式也變了。除了數(shù)據(jù)部分，每次通信都必須包括頭信息(HTTP header)，用來描述一些元數(shù)據(jù)。其他的新增功能還包括狀態(tài)碼(status code)、多字符集支持、多部分發(fā)送(

3、multi-part type)、權(quán)限(authorization)、緩存(cache)、內(nèi)容編碼(content encoding)等。2.2 請求格式下面是一個1.0版的HTTP請求的例子。1 / 8GET / HTTP/1.0User-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-Typ

4、e： text/plainContent-Length： 137582Expires： Thu， 05 Dec 1997 16：00：00 GMTLast-Modified： Wed， 5 August 1996 15：55：28 GMTServer： Apache 0.84Hello World回應(yīng)的格式是頭信息 + 一個空行(rn) + 數(shù)據(jù)。其中，第一行是協(xié)議版本 + 狀態(tài)碼(status code) + 狀態(tài)描述。2.4 Content-Type 字段關(guān)于字符的編碼，1.0版規(guī)定，頭信息必須是 ASCII 碼，后面的數(shù)據(jù)可以是任何格式。因此，服務(wù)器回應(yīng)的時候，必須告訴客戶端，數(shù)據(jù)是什么

5、格式，這就是Content-Type字段的作用。下面是一些常見的Content-Type字段的值。text/plaintext/htmltext/cssimage/jpegimage/pngimage/svg+xmlaudio/mp4video/mp4application/javascriptapplication/pdfapplication/zipapplication/atom+xml這些數(shù)據(jù)類型總稱為MIME type，每個值包括一級類型和二級類型，之間用斜杠分隔。除了預(yù)定義的類型，廠商也可以自定義類型。application/vnd.debian.binary-package上面的

6、類型表明，發(fā)送的是Debian系統(tǒng)的二進制數(shù)據(jù)包。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)頁。2.5 Content-Encoding 字段由于發(fā)送的數(shù)據(jù)可以是任何格式，因此可以把數(shù)據(jù)壓縮后再發(fā)送。Content-Encoding字段說明數(shù)據(jù)的

7、壓縮方法。Content-Encoding： gzipContent-Encoding： compressContent-Encoding： deflate客戶端在請求時，用Accept-Encoding字段說明自己可以接受哪些壓縮方法。Accept-Encoding： gzip， deflate2.6 缺點HTTP/1.0 版的主要缺點是，每個TCP連接只能發(fā)送一個請求。發(fā)送數(shù)據(jù)完畢，連接就關(guān)閉，如果還要請求其他資源，就必須再新建一個連接。TCP連接的新建成本很高，因為需要客戶端和服務(wù)器三次握手，并且開始時發(fā)送速率較慢(slow start)。所以，HTTP 1.0版本的性能比較差。隨著網(wǎng)頁

8、加載的外部資源越來越多，這個問題就愈發(fā)突出了。為了解決這個問題，有些瀏覽器在請求時，用了一個非標準的Connection字段。Connection： keep-alive這個字段要求服務(wù)器不要關(guān)閉TCP連接，以便其他請求復(fù)用。服務(wù)器同樣回應(yīng)這個字段。Connection： keep-alive一個可以復(fù)用的TCP連接就建立了，直到客戶端或服務(wù)器主動關(guān)閉連接。但是，這不是標準字段，不同實現(xiàn)的行為可能不一致，因此不是根本的解決辦法。三、HTTP/1.11997年1月，HTTP/1.1 版本發(fā)布，只比 1.0 版本晚了半年。它進一步完善了 HTTP 協(xié)議，一直用到了20年后的今天，直到現(xiàn)在還是最流行

9、的版本。3.1 持久連接1.1 版的最大變化，就是引入了持久連接(persistent connection)，即TCP連接默認不關(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 管道機制1.1 版還引入了管道機制(pipelining)，即在同一個TCP連接里面，客戶端可以同時發(fā)送多個請求。

10、這樣就進一步改進了HTTP協(xié)議的效率。舉例來說，客戶端需要請求兩個資源。以前的做法是，在同一個TCP連接里面，先發(fā)送A請求，然后等待服務(wù)器做出回應(yīng)，收到后再發(fā)出B請求。管道機制則是允許瀏覽器同時發(fā)出A請求和B請求，但是服務(wù)器還是按照順序，先回應(yīng)A請求，完成后再回應(yīng)B請求。3.3 Content-Length 字段一個TCP連接現(xiàn)在可以傳送多個回應(yīng)，勢必就要有一種機制，區(qū)分數(shù)據(jù)包是屬于哪一個回應(yīng)的。這就是Content-length字段的作用，聲明本次回應(yīng)的數(shù)據(jù)長度。Content-Length： 3495上面代碼告訴瀏覽器，本次回應(yīng)的長度是3495個字節(jié)，后面的字節(jié)就屬于下一個回應(yīng)了。在1.0

11、版中，Content-Length字段不是必需的，因為瀏覽器發(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版規(guī)定可以不使用Content-Length字段，而使用分塊傳輸編碼(chunked transfer encoding)。只要請求或回應(yīng)的頭信息有Trans

12、fer-Encoding字段，就表明回應(yīng)將由數(shù)量未定的數(shù)據(jù)塊組成。Transfer-Encoding： chunked每個非空的數(shù)據(jù)塊之前，會有一個16進制的數(shù)值，表示這個塊的長度。最后是一個大小為0的塊，就表示本次回應(yīng)的數(shù)據(jù)發(fā)送完了。下面是一個例子。HTTP/1.1 200 OKContent-Type： text/plainTransfer-Encoding： chunked25This is the data in the first chunk1Cand this is the second one3con8sequence03.5 其他功能1.1版還新增了許多動詞方法：PUT、PATCH、HEAD、 OPTIONS、DELETE。另外，客戶端請求的頭信息新增了Host字段，用來指定服務(wù)器的域名。Host： 有了Host字段，就可以將請求發(fā)往同一臺服務(wù)器上的不同網(wǎng)站，為虛擬主機的興起打下了基礎(chǔ)。3.6 缺點雖然1.1版允許復(fù)用TCP連接，但是同一個TCP連接里面，所有的數(shù)據(jù)通信是按次序進行的。服務(wù)器只有處理完一個回應(yīng)，才會進行下一個回應(yīng)。要是前面的回應(yīng)特別慢，后面就會有許