HTTP協議簡介

關於HTTP協議的基本介紹。

HTTP協議是基於TCP/IP協議之上的應用層協議，主要用於規定互使用聯網中客戶端和服務器之間的通信格式，不關心具體傳輸細節，默認80端口。對於Web開發，不管是前端還是后端開發，了解HTTP協議是必備的一些基本知識。

發展歷程

HTTP/0.9

於1991年發布，只有一個GET命令，返回HTML格式內容。

HTTP/1.0

於1996年5月發布，增加POST、HEAD命令，傳輸內容可以說任意格式，不再僅限於HTML，並且報文規定了一些元數據字段，比如字符集、狀態碼、編碼、緩存等。

HTTP/1.1

於1997年1月發布，增加PUT\PATCH\DELETE等命令，並新增了一些功能機制:

• 持久連接(keep-alive可保持長連接，減少重復請求)。
• 管道機制(pipelining，一個TCP連接中客戶端可同時發送多個請求)。Content-Length字段（報文內容長度）。
• Host字段(用於指定服務器域名，可以將請求發往同一台服務器的不同站點)。1.1版本基本完善了HTTP協議，並且一直使用至今仍然是目前最流行的版本。

SPDY

於2009年由谷歌研發，使用多種新特性提高HTTP/1.1版本效率不高的問題。作為HTTP/2版本草案，在HTTP/2發布后已停止使用。

HTTP/2

於2015年發布，基於谷歌的SPDY協議之上進行了小部分修改。主要有以下特點：

• 二進制協議(HTTP/1.1版本頭信息使用文本格式，數據體可以是文本或二進制格式，而HTTP/2版本則全部使用二進制格式,方便將來擴展)。
• 多工傳輸(復用TCP連接，雙向實時通信，客戶端服務器可同時發送多個請求和響應，並且不需要按照請求順序回應，避免隊頭阻塞問題)。
• 頭信息壓縮(HTTP協議是無狀態的，因此很多請求都需要帶上Cookie、User Agent等重復字段，影響效率。HTTP/2使用gzip、compress等算法壓縮頭信息后，並且在客戶端和服務器都維護一張頭信息表，記錄這些字段，從而提高速度)。

SSL/TLS

由於HTTP通信是全明文傳輸的，很多敏感信息容易被竊取。網景公司(Netspace)，發明了SSL協議，用於對HTTP傳輸的內容進行安全加密。后來互聯網標准化組織IETF將SSL推廣並重新命名為TLS協議，所以SSL和TLS基本是一個東西。

HTTPS

HTTPS = HTTP + SSL/TLS，可進行加密傳輸、身份認證，默認443端口，需要使用CA證書，免費證書較少，需交費。HTTPS有以下幾個特點:
（1） 所有信息都是加密傳播，黑客無法竊聽。
（2） 具有校驗機制，一旦被篡改，通信雙方會立刻發現。
（3） 配備身份證書，防止身份被冒充。

QUIC

由谷歌制定的基於UDP的一種傳輸層協議，QUIC協議集成了TCP可靠傳輸機制、TLS安全加密、HTTP /2 多路並發流量復用技術。

協議特點

由於目前HTTP/2還沒有廣泛使用，HTTP/1.1仍舊是目前使用最廣泛的版本，所以后面主要介紹HTTP/1.1版本的基本知識。沒有特指的情況下HTTP即為HTTP/1.1版本。

HTTP的主要特點有以下幾點：

1. 基於TCP協議：HTTP協議目的是規定客戶端和服務端數據傳輸的格式和數據交互行為，並不負責數據傳輸的細節。底層是基於TCP實現的。
2. 無狀態連接：HTTP協議本身不對請求和響應之間的通信狀態進行保存。
3. 多次請求：由於管道機制可實現一次TCP連接同時多個HTTP請求。客戶端請求服務器時先響應HTML，再請求加載CSS,JS，圖片等資源。
4. 持久連接：當TCP連接建立后，只要任意一端沒有明確提出斷開連接，則保持TCP連接狀態。減少TCP重復建立和斷開的開銷及服務器端的負載。
5. 使用Cookie和Session機制管理狀態：為了實現保存通信狀態，引入了Cookie和Session技術。比如用戶登錄網站跳轉到其他頁面能夠保存用戶狀態，而不需要重新登錄。
6. 全明文傳輸: 報文數據不加密（這一方面從某種意義上也方便了開發人員調試bug），敏感信息易泄露。可通過在代碼上使用SSL/TLS協議改造系統，加密請求響應報文，需調試可將報文解密后保存到日志中進行問題排查。
7. 內容編碼: 由於某些報文的內容過大，因此在傳輸時，為了減少傳輸的時間，會采取一些壓縮的措施。
8. 范圍請求: 當客戶端請求的數據內容過大時，比如請求一張很大的圖片，會發現有時候圖片是一塊一塊加載的。這就是因為設置了http請求的長度，這樣就可以分塊的加載資源文件。在請求報文中使用Range屬性，在響應報文中使用Content-Type屬性都可以指定一定字節范圍的http請求。
9. 多部分對象集合: 報文傳輸的內容，不僅僅是一些字符串，還有可能是一些圖片，字符，音樂二進制等混雜的內容。這就需要使用多部分對象集合，multipart。默認的情況下form使用的編碼格式是：applicatin/x-www-form-urlencoded，這種編碼格式會把所有的內容進行編碼，不適合上傳文件這種情況。multipart/form-data 會以控件為基准，編碼form中的內容。application/x-www-form-urlencoded 會把form中的內容編碼成鍵值對的形式。

HTTP報文

HTTP報文可以分為請求報文、響應報文。每個報文又包含三個部分首行、頭部和主體。報文主體可有可無。

GET www.baidu.com HTTP/1.1

請求報文的首行叫請求行，包括請求方法、URL和HTTP版本。

HTTP/1.1 200 OK

響應報文的首行叫狀態行，包括HTTP版本，狀態碼和簡短原因，其中原因可有可無。

頭部的各種協議字段通過鍵值對來保存，主體保存具體內容。首行、頭部和主體以及頭部的各項字段用回車換行(\r\n)分割，另外頭部和主體之間多一個空行，也就是有兩個連續的回車換行。

請求方法

請求方法是客戶端用來告知服務端其操作意圖的一個命令。常用的主要有GET、POST方法。其他方法不常用了解一下即可。下面是幾種方法的說明：

1. GET： 用於獲取資源。
2. POST： 用於傳輸實體主體。
3. PUT：用於傳輸文件。PUT方法用來傳輸文件。類似FTP協議，文件內容包含在請求報文的實體中，然后請求保存到URL指定的服務器位置。
4. HEAD：獲取報文首部。HEAD方法類似GET方法，但是不同的是HEAD方法不要求返回數據。用於確認URI的有效性及資源更新時間等。
5. DELETE：用於刪除文件。DELETE方法用來刪除文件，是與PUT相反的方法。DELETE是要求返回URL指定的資源。
6. OPTIONS： 用於詢問服務器支持的請求方法。OPTIONS 方法用來查詢針對請求 URI 指定的資源支持的方法。有些服務器為了安全考慮會將PUT、DELETE方法禁用，這時可以先用OPTIONS查詢支持的方法。
7. TRACE：追蹤路徑。TRACE方法是讓Web服務器將之前的請求通信環回給客戶端的方法。這個方法並不常用。
8. CONNECT：要求用隧道協議連接代理。CONNECT方法要求在與代理服務器通信時建立隧道，實現用隧道協議進行TCP通信。主要使用SSL/TLS協議對通信內容加密后傳輸。

響應狀態碼

狀態碼是服務器用來告知客戶端處理請求的結果。憑借狀態碼用戶可以知道服務器是請求處理成功、失敗或者是被轉發；這樣出現了錯誤也好定位。狀態碼是由3位數字加原因短語組成。3位數字中的第一位是用來指定狀態的類別。共有5種類型：

狀態碼一共有60多種，經常使用的大概就是16種，其中加粗為最常見的情況：

• 200: OK 表示請求處理成功。
• 204: No Content 表示請求處理成功，但沒有數據實體返回。
• 206: Partial Content 表示客戶端指定請求范圍，服務器成功執行了這部分的GET請求。響應報文中包含由請求頭Content-Range指定范圍的實體內容。
• 301: Moved Permanently 代表永久性定向。該狀態碼表示請求的資源已經被分配了新的URL，以后應該使用資源現在指定的URL。也就是說如果已經把資源對應的URL保存為書簽了，這是應該按照Location首部字段提示的URL重新保存。
• 302: Found 代表臨時重定向。該狀態碼表示請求的資源已經被分配了新的URL，但是和301的區別是302代表的不是永久性的移動，只是臨時的。就是說這個URL還可能會發生改變。如果保存成書簽了也不會更新。
• 303: See Other 和302的區別是303明確規定客戶端應當使用GET方法。當 301、302、303 響應狀態碼返回時，幾乎所有的瀏覽器都會把
  POST 改成 GET，並刪除請求報文內的主體，之后請求會自動再次
  發送。301、302 標准是禁止將 POST 方法改變成 GET 方法的，但實際使
  用時大家都會這么做。
• 304： Not Modified 表示客戶端發送附帶條件請求時，服務器端允許請求訪問資源，但是沒有滿足條件。304狀態碼返回時不包含任何數據實體。304雖然被划分在3XX中但是和重定向沒有關系。
• 307: Temporary Redirect 臨時重定向，與302 Found相同，但是302會把POST改成GET，而307就不會。
• 400: Bad Request 表示請求報文中存在語法錯誤。需要修改后再次發送。
• 401: Unauthorized 表示發生的請求需要有通過HTTP認證的認證信息。
• 403: Forbidden 表示請求訪問資源被拒絕了。沒有獲得服務器的訪問權限，IP被禁止等。
• 404: Not Found 表示請求的資源在服務器上找不到。當然也可以在服務器拒絕請求且不想說明理由時使用。
• 408: Request Timeout 表示客戶端請求超時。就是在客戶端和服務器建立連接后服務器在一定時間內沒有收到客戶端的請求。
• 500: Internal Server Error 表明服務器端在執行請求時發生了錯誤，很有可能是服務端程序的Bug或者臨時故障。
• 503: Service Unavaliable 表明服務器暫時處於超負載或正在進行停機維護，現在無法處理請求。如果事先得知解除以上狀況需要的時間，最好寫入Retry-After字段再返回給客戶端。
• 504: Gateway Timeout 表示網關超時，是代理服務器等待應用服務器響應時的超時，和408 Request Timeout的卻別就是504是服務器的原因而不是客戶端的原因。

不少返回的狀態碼響應都是錯誤的，但是用戶可能察覺不到這點。
比如 Web 應用程序內部發生錯誤，狀態碼依然返回 200 OK，這種
情況也經常遇到。這時可查看相近的幾次請求信息。

更多狀態碼的詳細介紹請參考: http://tool.oschina.net/commons?type=5

HTTP首部字段

HTTP首部字段是構成HTTP報文最重要的元素之一。在客戶端與服務端之前進行信息傳遞的時候請求和響應都會使用首部字段，會傳遞一些重要的元信息。首部字段是以鍵值對的形式存在的。包含報文的主體大小、語言、認證信息等。HTTP首部字段包含4種類型：

• 通用首部字段（General Header Fields） 代表請求報文和響應報文都會使用的字段。

• 請求首部字段（Request Header Fields） 是客戶端向服務端發送請求時使用的首部字段。包含請求的附加內容、客戶端信息、響應內容相關優先級等信息。

• 響應首部字段（Response Header Fields） 是服務端向客戶端返回響應時使用的首部字段，包含響應的附加內容，可能也會要求客戶端附加額外的內容信息。

• 實體首部字段（Entity Header Fields） 是針對請求報文和響應報文的實體部分使用的首部。包含資源內容更新時間等和實體有關的信息。

其他首部字段Cookie、Set-Cookie、Content-Disposition、Connection、Keep-Alive、Proxy-Authenticate、Proxy-Authorization、Trailer、TE、Transfer-Encoding、Upgrade etc...也很常用，關於首部字段的細節請參考《圖解HTTP》或者《HTTP權威指南》的首部字段部分。

常見頭部字段說明

• Accept: Accept請求報頭域用於指定客戶端接受哪些類型的信息。e.g. Accept：text/html，表明客戶端希望接受html文本。
• Accept-Charset: Accept-Charset請求報頭域用於指定客戶端接受的字符集。
• Accept-Encoding: 客戶端用於指定可接受的內容編碼。
• Authorization: Authorization請求報頭域主要用於證明客戶端有權查看某個資源。
• User-Agent: 請求報頭域允許客戶端將它的操作系統、瀏覽器和其它屬性告訴服務器。
• Location: 重定向地址。
• Server： 服務器用來處理請求的軟件信息。
• Content-Encoding: 響應報文采用何種編碼格式傳輸正文。主要的編碼方式有gzip,compress,deflate,identity。
• Content-Language: 實體報頭域描述了資源所用的自然語言。
• Content-Length: 實體正文的長度，以字節方式存儲的十進制數字來表示。
• Content-Type: 響應報文的實體正文的媒體類型

相關概念介紹

與HTTP協議關聯比較密切的一些概念簡介：

• IP協議： 位於網絡層，用於計算機之間的通信。主要實現兩個基本功能：尋址和分段。IP可以根據數據包包頭中包括的目的地址將數據包傳送到目的地址，在此過程中IP負責選擇傳送的道路，這種選擇道路稱為路由功能。

• TCP協議： 位於傳輸層，用於應用程序之間的通信。采用“三次握手”和“四次揮手”機制建立可靠性連接。比如快遞送貨，IP協議相當於填寫快遞單號的規則以及如何根據快遞單信息找到客戶。TCP協議相當於送貨的快遞員，先打電話確認信息，再將快遞送過去，最后由客戶簽收。

• DNS協議： 用於域名解析，將域名轉換為IP地址。

• URI/URL：

  • URL(統一資源定位符)：表示資源的地點，具體指向（門牌號）。
  • URI(統一資源標識符)：用字符串標識某些互聯網資源（該門牌號的地方具體有什么資源）。
  • URL是URI的子集。

• 媒體類型: 互聯網上有數千種不同的數據類型，http給每種需要通過http傳輸的對象都打上了MIME類型（MIME type）的數據格式標簽。媒體類型自身實際上包含兩部分。第一部分(斜線前)是頂級媒體類型，這部分描述了通用的類型信息以及常用處理規則。常見的頂級類型有：application,image,text，video和multipart。第二部分是
  子類型，描述一個非常具體的數據格式。常見的媒體類型有：

  • text/html: HTML格式的文本文檔。
  • text/plain: 普通的ASCII文本文檔。
  • text/xml: XML格式。
  • image/png、image/jpeg、image/gif：圖片類型。
  • application/xml: XML數據格式
  • application/json: JSON數據格式
  • application/x-www-form-urlencoded: form表單數據被編碼為key/value格式發送到服務器（表單默認的提交數據的格式）。
  • multipart/form-data: 表單中進行文件上傳時，需要使用該格式。

  更多的文件格式及對應的媒體類型信息請參考:http://tool.oschina.net/commons

一次完整的瀏覽器請求響應流程

當我們在瀏覽器地址欄輸入www.baidu.com回車后。這一瞬間發生的請求過程是這樣的：

1. 使用DNS協議對www.baidu.com域名進行解析，得到對應的IP地址。
2. 然后通過IP協議根據IP地址找到目標服務器。
3. 通過TCP協議發起三次握手建立TCP連接。
4. 通過TCP連接通信，瀏覽器發起HTTP請求。
5. 服務器處理請求，瀏覽器得到響應報文包含HTML代碼。
6. 瀏覽器解析HTML代碼，再發起請求去獲取HTML中需要的CSS、JS、圖片等資源。
7. 瀏覽器對頁面進行渲染並呈現給用戶。

常見問題

GET和POST區別

1. GET方法只用來獲取資源，不會對資源狀態進行修改；而POST方法用來傳輸實體對象，可能會對資源進行修改。
2. GET請求參數會放在URL上，使用?符號進行分割，參數之間使用&符號連接，並且因為URL長度會根據不同瀏覽器有不同長度的限制；而POST請求參數會放到請求主體中，沒有長度限制。
3. GET請求參數在URL可直接查看，因此主要用於不敏感數據的快速查詢；而POST數據放在實體中相對私密一些，主要可用於資源的增刪改等操作。
4. GET請求會被瀏覽器主動緩存，而POST不會，除非手動設置。
5. 對參數的數據類型，GET只接受ASCII字符，而POST沒有限制編碼。

Cookie和Session區別

Cookie和Session都是為了保存客戶端和服務端之間的交互狀態，實現機制不同，各有優缺點。首先一個最大的區別就是Cookie是保存在客戶端而Session就保存在服務端的。Cookie是客戶端請求服務端時服務器會將一些信息以鍵值對的形式返回給客戶端，保存在瀏覽器中，交互的時候可以加上這些Cookie值。用Cookie就可以方便的做一些緩存。Cookie的缺點是大小和數量都有限制；Cookie是存在客戶端的可能被禁用、刪除、篡改，是不安全的；Cookie如果很大，每次要請求都要帶上，這樣就影響了傳輸效率。Session是基於Cookie來實現的，不同的是Session本身存在於服務端，但是每次傳輸的時候不會傳輸數據，只是把代表一個客戶端的唯一ID（通常是JSESSIONID）寫在客戶端的Cookie中，這樣每次傳輸這個ID就可以了。Session的優勢就是傳輸數據量小，比較安全。但是Session也有缺點，就是如果Session不做特殊的處理容易失效、過期、丟失或者Session過多導致服務器內存溢出，並且要實現一個穩定可用安全的分布式Session框架也是有一定復雜度的。在實際使用中就要結合Cookie和Session的優缺點針對不同的問題來設計解決方案。

參考資料

• 上野宣.《圖解HTTP》.人民郵電出版社.2013-1
• 韓路彪.《看透Spring MVC源代碼分析與實踐》.機械工業出版社.2015-11
• 阮一峰HTTP協議入門
• 理解HTTP協議
• HTTP各版本區別
• 百度百科-IP協議
• 一次完整的瀏覽器請求過程
• HTTP協議之媒體類型
• HTTP協議詳解