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

[[222114]]

HTTP的全稱是什么?

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

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

大部分同學(xué)都知道200、404、500、302錯(cuò)誤。如果連404都不知道，是要被小編鄙視的。500錯(cuò)誤為什么這么常見呢，因?yàn)樵陂_發(fā)的時(shí)候老是出bug，一個(gè)大異常拋出來(lái)，瀏覽器就500了。500表示InternalServerError，也就是內(nèi)部服務(wù)器錯(cuò)誤，如果不是bug，一般就是數(shù)據(jù)庫(kù)掛了。

再多問(wèn)幾個(gè)狀態(tài)碼很多人就不知道了，因?yàn)榇蠖鄶?shù)公司的軟件服務(wù)沒(méi)有走標(biāo)準(zhǔn)的HTTP狀態(tài)碼，很多狀態(tài)碼從來(lái)就不會(huì)出現(xiàn)，同學(xué)們自然也不會(huì)知道。

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

其實(shí)還有很多狀態(tài)碼，小編也沒(méi)去好好研究了，因?yàn)閷?shí)在不會(huì)在工作中用到。感興趣的請(qǐng)繼續(xù)閱讀維基百科

HTTP有哪些Method?

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

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

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

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

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

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

消息體是一個(gè)字符串，字符串的長(zhǎng)度是由消息頭部的Content-Length鍵指定的。如果沒(méi)有Content-Length字段說(shuō)明沒(méi)有消息體，譬如GET請(qǐng)求就是沒(méi)有消息體的，POST請(qǐng)求的消息體一般用來(lái)放置表單數(shù)據(jù)。GET請(qǐng)求的響應(yīng)返回的頁(yè)面內(nèi)容也是放在消息體里面的。我們平時(shí)調(diào)用API返回的JSON內(nèi)容都是放在消息體里面的。

什么是分塊傳送?

當(dāng)瀏覽器向服務(wù)器請(qǐng)求一個(gè)資源時(shí)，這個(gè)資源是一個(gè)動(dòng)態(tài)資源，服務(wù)器無(wú)法提前預(yù)知資源的大小，這個(gè)時(shí)候就可以使用分塊傳輸。

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

分塊傳送需要在請(qǐng)求頭增加一個(gè)特殊的鍵值對(duì)transfer-encoding: chunked，那么消息體的內(nèi)容便是分塊傳送的。

chunked傳輸格式如圖所示，由一段一段的分塊組合而成，每個(gè)塊由一個(gè)長(zhǎng)度行和一個(gè)分塊體組成，最后一個(gè)分塊長(zhǎng)度為0表示結(jié)束。

持久連接的機(jī)制是怎樣的?

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

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

如果服務(wù)器設(shè)置的timeout時(shí)長(zhǎng)為0，就退化到非持久連接。非持久連接會(huì)在響應(yīng)頭部增加一個(gè)頭信息Connection: Close通知客戶端在接受完當(dāng)前響應(yīng)后連接需要立即關(guān)閉。

同樣瀏覽器也不會(huì)因?yàn)榉?wù)器將KeepAlive Timeout配置了無(wú)限長(zhǎng)就不管不問(wèn)一直持續(xù)保持連接。每個(gè)瀏覽器都有它自己的內(nèi)置限制，具體限制瀏覽器廠商各有不同。

什么叫Pipeline管線化?

HTTP1.0不支持管線化，同一個(gè)連接處理請(qǐng)求的順序是逐個(gè)應(yīng)答模式，處理一個(gè)請(qǐng)求就需要耗費(fèi)一個(gè)TTL，也就是客戶端到服務(wù)器的往返時(shí)間，處理N個(gè)請(qǐng)求就是N個(gè)TTL時(shí)長(zhǎng)。當(dāng)頁(yè)面的請(qǐng)求非常多時(shí)，頁(yè)面加載速度就會(huì)非常緩慢。

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

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

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