小編是一個非典型面試官，對于HTTP協(xié)議的第一個問題，一般人會問常用的狀態(tài)碼有哪些。小編不這么問，小編的問題是HTTP的全稱是什么，把英語給我說出來!

[[222114]]

HTTP的全稱是什么?

超文本傳輸協(xié)議，HyperText Transfter Protocol，這幾個單詞可別發(fā)走音了。所謂的超文本就是帶標記的文本，剛開始的時候是指HTML。現(xiàn)在HTTP協(xié)議傳輸?shù)臇|西可不只是HTML了，什么表單啊JSON啊XML啊文件啊都可以傳輸。

HTTP常用的狀態(tài)碼有哪些?

大部分同學都知道200、404、500、302錯誤。如果連404都不知道，是要被小編鄙視的。500錯誤為什么這么常見呢，因為在開發(fā)的時候老是出bug，一個大異常拋出來，瀏覽器就500了。500表示InternalServerError，也就是內部服務器錯誤，如果不是bug，一般就是數(shù)據(jù)庫掛了。

再多問幾個狀態(tài)碼很多人就不知道了，因為大多數(shù)公司的軟件服務沒有走標準的HTTP狀態(tài)碼，很多狀態(tài)碼從來就不會出現(xiàn)，同學們自然也不會知道。

• 400 Bad Request 用于參數(shù)驗證，少了一個參數(shù)或者參數(shù)類型錯誤之類的。
• 502 Bad Gateway 后端服務掛掉或者壓力過大的時候， Nginx接到的請求無法及時傳遞給后端的服務進行處理，這個時候就會出現(xiàn)502錯誤。這個也非常常見，知乎豆瓣網(wǎng)站經(jīng)常開小差的時候發(fā)生的錯誤就是這個。
• 304 Not Modified 極少人知道這個錯誤，因為大部分后端開發(fā)者的前端Javascript開發(fā)經(jīng)驗都嚴重不足。當你用Chrome打開一個經(jīng)常訪問的網(wǎng)站，看看Network傳輸?shù)撵o態(tài)資源就可以看到很多304狀態(tài)碼。它表示該資源被瀏覽器緩存了不需要重新請求服務器。
• 401 Unauthorized 權限不足，這個很好理解，就是資源存在但是不讓你訪問。
• 403 Forbidden 資源禁止訪問，如果你的IP列為黑名單了，就會發(fā)生這種錯誤。

其實還有很多狀態(tài)碼，小編也沒去好好研究了，因為實在不會在工作中用到。感興趣的請繼續(xù)閱讀維基百科

HTTP有哪些Method?

• GET 不解釋，如果讀者不知道，建議別在IT圈混了。
• POST 一般用于創(chuàng)建或者修改資源，在RESTFUL規(guī)范里面POST只用來創(chuàng)建資源，并返回201 Created狀態(tài)碼表示創(chuàng)建成功。不過大多數(shù)網(wǎng)站都不遵循嚴格的RESTFUL規(guī)范，POST拿來做修改資源的事也是非常常見的。
• PUT 用于修改資源，比如修改資源的某個具體屬性。
• DELETE 用于刪除資源。
• HEAD 不常用，跟GET差不多，區(qū)別就是不返回Body內容，只返回HTTP頭信息。一般用于獲取資源的元信息，比如長度，修改時間等
• OPTIONS 小編沒用過。
• TRACE 小編沒用過。
• CONNECT 小編沒用過。

后面三個感興趣的去閱讀一下RPC規(guī)范。小編大概看了一下，表示沒怎么看懂，你行你上去挑戰(zhàn)一下。

HTTP協(xié)議格式是怎樣的?

• HTTP的請求和響應的消息協(xié)議是一樣的，分為三個部分，起始行、消息頭和消息體。這三個部分以CRLF作為分隔符。最后一個消息頭有兩個CRLF，用來表示消息頭部的結束。

• HTTP請求的起始行稱為請求行，形如GET /index.html HTTP/1.1
• HTTP響應的起始行稱為狀態(tài)行，形如200 ok

消息頭部有很多鍵值對組成，多個鍵值對之間使用CRLF作為分隔符，也可以完全沒有鍵值對。形如Content-Encoding: gzip

消息體是一個字符串，字符串的長度是由消息頭部的Content-Length鍵指定的。如果沒有Content-Length字段說明沒有消息體，譬如GET請求就是沒有消息體的，POST請求的消息體一般用來放置表單數(shù)據(jù)。GET請求的響應返回的頁面內容也是放在消息體里面的。我們平時調用API返回的JSON內容都是放在消息體里面的。

什么是分塊傳送?

當瀏覽器向服務器請求一個資源時，這個資源是一個動態(tài)資源，服務器無法提前預知資源的大小，這個時候就可以使用分塊傳輸。

服務器先生成一個chunk，發(fā)送這個chunk，再生成一個chunk，再發(fā)送一個chunk，直到全部資源傳送完成。

分塊傳送需要在請求頭增加一個特殊的鍵值對transfer-encoding: chunked，那么消息體的內容便是分塊傳送的。

chunked傳輸格式如圖所示，由一段一段的分塊組合而成，每個塊由一個長度行和一個分塊體組成，最后一個分塊長度為0表示結束。

持久連接的機制是怎樣的?

HTTP早期版本中每個請求都會發(fā)起一個連接，一個網(wǎng)頁除了頁面的HTML之外還會有很多靜態(tài)資源以及諸多的API調用，如果每個請求都一個連接，勢必網(wǎng)頁的一次加載就會和服務器創(chuàng)建多次連接，這是非常浪費服務器資源的，同時也讓客戶端的訪問速度慢了不少。HTTP1.0之后引入了Keep-Alive持久連接，在HTTP1.1版本中成為默認選項。它使得HTTP的一個連接可以連續(xù)服務多個請求，有效節(jié)省了資源，增加了客戶端頁面的加載速度。

持久連接也不宜一直保持，畢竟每個連接都會占用服務器資源，如果打開網(wǎng)頁的人太多，那服務器資源也會緊張，所以一般服務器都會配置一個KeepAlive Timeout參數(shù)和KeepAlive Requests參數(shù)限制單個連接持續(xù)時長和最多服務的請求次數(shù)。

如果服務器設置的timeout時長為0，就退化到非持久連接。非持久連接會在響應頭部增加一個頭信息Connection: Close通知客戶端在接受完當前響應后連接需要立即關閉。

同樣瀏覽器也不會因為服務器將KeepAlive Timeout配置了無限長就不管不問一直持續(xù)保持連接。每個瀏覽器都有它自己的內置限制，具體限制瀏覽器廠商各有不同。

什么叫Pipeline管線化?

HTTP1.0不支持管線化，同一個連接處理請求的順序是逐個應答模式，處理一個請求就需要耗費一個TTL，也就是客戶端到服務器的往返時間，處理N個請求就是N個TTL時長。當頁面的請求非常多時，頁面加載速度就會非常緩慢。

從HTTP1.1開始要求服務器支持管線化，可以同時將多個請求發(fā)送到服務器，然后逐個讀取響應。這個管線化和Redis的管線化原理是一樣的，響應的順序必須和請求的順序保持一致。

如何理解HTTP協(xié)議的無狀態(tài)性?

所謂HTTP協(xié)議的無狀態(tài)性是指服務器的協(xié)議層無需為不同的請求之間建立任何相關關系，它特指的是協(xié)議層的無狀態(tài)性。但是這并不代表建立在HTTP協(xié)議之上的應用程序就無法維持狀態(tài)。應用層可以通過會話Session來跟蹤用戶請求之間的相關性，服務器會為每個會話對象綁定一個唯一的會話ID，瀏覽器可以將會話ID記錄在本地緩存LocalStorage或者Cookie，在后續(xù)的請求都帶上這個會話ID，服務器就可以為每個請求找到相應的會話狀態(tài)。