天下無難試之HTTP協議面試刁難大全（上）

小編是一個非典型面試官，對於HTTP協議的第一個問題，通常人會問經常使用的狀態碼有哪些。小編不這麼問，小編的問題是HTTP的全稱是什麼，把英語給我說出來！

HTTP的全稱是什麼？

超文本傳輸協議，HyperText Transfer Protocol，這幾個單詞可別發走音了。所謂的超文本就是帶標記的文本，剛開始的時候是指HTML。如今HTTP協議傳輸的東西可不僅是HTML了，什麼表單啊JSON啊XML啊文件啊均可以傳輸。

HTTP經常使用的狀態碼有哪些？

大部分同窗都知道200、40四、500、302狀態碼。若是連404都不知道，是要被小編鄙視的。500錯誤爲何這麼常見呢，由於在開發的時候總是出bug，一個大異常拋出來，瀏覽器就500了。500表示InternalServerError，也就是內部服務器錯誤，若是不是bug，通常就是數據庫掛了。

再多問幾個狀態碼不少人就不知道了，由於大多數公司的軟件服務沒有走標準的HTTP狀態碼，不少狀態碼歷來就不會出現，同窗們天然也不會知道。

400 Bad Request 用於參數驗證，少了一個參數或者參數類型錯誤之類的。

502 Bad Gateway 後端服務掛掉或者壓力過大的時候， Nginx接到的請求沒法及時傳遞給後端的服務進行處理，這個時候就會出現502錯誤。這個也很是常見，知乎豆瓣網站常常開小差的時候發生的錯誤就是這個。

304 Not Modified 極少人知道這個狀態碼，由於大部分後端開發者的前端Javascript開發經驗都嚴重不足。當你用Chrome打開一個常常訪問的網站，看看Network傳輸的靜態資源就能夠看到不少304狀態碼。它表示該資源被瀏覽器緩存了不須要從新請求服務器。

401 Unauthorized 權限不足，這個很好理解，就是資源存在可是不讓你訪問。

403 Forbidden 資源禁止訪問，若是你的IP列爲黑名單了，就會發生這種錯誤。

其實還有不少狀態碼，小編也沒去好好研究了，由於實在不會在工做中用到。感興趣的請繼續閱讀維基百科

HTTP有哪些Method？

GET 不解釋，若是讀者不知道，建議別在IT圈混了。

POST 通常用於建立或者修改資源，在RESTFUL規範裏面POST只用來建立資源，並返回201 Created狀態碼錶示建立成功。不過大多數網站都不遵循嚴格的RESTFUL規範，POST拿來作修改資源的事也是很是常見的。

PUT 對應於POST表示建立資源，PUT用於修改資源，PUT的參數必須是對象的所有屬性，修改是覆蓋式所有修改。

PATCH 對應於PUT的參數是對象的所有屬性，PATCH的參數是部分屬性，修改是局部字段修改。

DELETE 用於刪除資源。

HEAD 不經常使用，跟GET差很少，區別就是不返回Body內容，只返回HTTP頭信息。通常用於獲取資源的元信息，好比長度，修改時間等

OPTIONS 跨域相關，後面再講。

TRACE 小編沒用過。

CONNECT 小編沒用過。

後面三個感興趣的去閱讀一下RPC規範。小編大概看了一下，表示沒怎麼看懂，你行你上去挑戰一下。

HTTP協議格式是怎樣的？

HTTP的請求和響應的消息協議是同樣的，分爲三個部分，起始行、消息頭和消息體。這三個部分以CRLF做爲分隔符。最後一個消息頭有兩個CRLF，用來表示消息頭部的結束。

HTTP請求的起始行稱爲請求行，形如GET /index.html HTTP/1.1

HTTP響應的起始行稱爲狀態行，形如200 ok

消息頭部有不少鍵值對組成，多個鍵值對之間使用CRLF做爲分隔符，也能夠徹底沒有鍵值對。形如Content-Encoding: gzip

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

什麼是分塊傳送？

當瀏覽器向服務器請求一個資源時，這個資源是一個動態資源，服務器沒法提早預知資源的大小，這個時候就可使用分塊傳輸。

服務器先生成一個thunk，發送這個chunk，再生成一個chunk，再發送一個chunk，直到所有資源傳送完成。

分塊傳送須要在請求頭增長一個特殊的鍵值對transfer-encoding: thunked，那麼消息體的內容即是分塊傳送的。

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

持久鏈接的機制是怎樣的？

HTTP早期版本中每一個請求都會發起一個鏈接，一個網頁除了頁面的HTML以外還會有不少靜態資源以及諸多的API調用，若是每一個請求都一個鏈接，勢必網頁的一次加載就會和服務器建立屢次鏈接，這是很是浪費服務器資源的，同時也讓客戶端的訪問速度慢了很多。HTTP1.0以後引入了Keep-Alive持久鏈接，在HTTP1.1版本中成爲默認選項。它使得HTTP的一個鏈接能夠連續服務多個請求，有效節省了資源，增長了客戶端頁面的加載速度。

持久鏈接也不宜一直保持，畢竟每一個鏈接都會佔用服務器資源，若是打開網頁的人太多，那服務器資源也會緊張，因此通常服務器都會配置一個KeepAlive Timeout參數和KeepAlive Requests參數限制單個鏈接持續時長和最多服務的請求次數。

若是服務器設置的timeout時長爲0，就退化到非持久鏈接。非持久鏈接會在響應頭部增長一個頭信息Connection: Close通知客戶端在接受完當前響應後鏈接須要當即關閉。

一樣瀏覽器也不會由於服務器將KeepAlive Timeout配置了無限長就無論不問一直持續保持鏈接。每一個瀏覽器都有它本身的內置限制，具體限制瀏覽器廠商各有不一樣。

什麼叫Pipeline管線化？

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

從HTTP1.1開始要求服務器支持管線化，能夠同時將多個請求發送到服務器，而後逐個讀取響應。這個管線化和Redis的管線化原理是同樣的，響應的順序必須和請求的順序保持一致。

如何理解HTTP協議的無狀態性？

所謂HTTP協議的無狀態性是指服務器的協議層無需爲不一樣的請求之間創建任何相關關係，它特指的是協議層的無狀態性。可是這並不表明創建在HTTP協議之上的應用程序就沒法維持狀態。應用層能夠經過會話Session來跟蹤用戶請求之間的相關性，服務器會爲每一個會話對象綁定一個惟一的會話ID，瀏覽器能夠將會話ID記錄在本地緩存LocalStorage或者Cookie，在後續的請求都帶上這個會話ID，服務器就能夠爲每一個請求找到相應的會話狀態。

閱讀相關文章，關注公衆號【碼洞】