摘要：所以我十分建議大家去讀一下圖解和權(quán)威指南。圖解這本書對互聯(lián)網(wǎng)基盤協(xié)議進(jìn)行了全面系統(tǒng)的介紹。通過書中大量生動形象的通信圖例，我們能夠更全面地理解通信過程中客戶端與服務(wù)器之間的交互情況。返回結(jié)果的狀態(tài)在通訊中，通過轉(zhuǎn)態(tài)碼，告知客戶端的請求狀態(tài)。

作為一個前端，如果能夠深刻理解 HTTP 通信，能夠讓我們在日常開發(fā)工作中快速定位問題。所以我十分建議大家去讀一下《圖解HTTP》和《HTTP權(quán)威指南》。權(quán)威指南講解的十分詳細(xì)，內(nèi)容也十分的全面，但是這本書的厚度也讓很多同學(xué)望而卻步。推薦大家從 《圖解HTTP》 這本書開始學(xué)習(xí)，這本書雖然沒有權(quán)威指南詳細(xì)，但涵蓋了很多我們?nèi)粘ｉ_發(fā)需要的知識點(diǎn)，理解他，能讓我們的開發(fā)效率事半功倍。

《圖解HTTP》這本書對互聯(lián)網(wǎng)基盤—— HTTP 協(xié)議進(jìn)行了全面系統(tǒng)的介紹。作者從 HTTP 發(fā)展史開始，嚴(yán)謹(jǐn)?shù)仄饰隽?HTTP 協(xié)議的結(jié)構(gòu)，列舉很多常見通信場景及實(shí)戰(zhàn)案例，最后延伸到Web安全、最新技術(shù)動向等方面。通過書中大量生動形象的通信圖例，我們能夠更全面地理解 HTTP 通信過程中客戶端與服務(wù)器之間的交互情況。在讀這本書的過程中我收獲頗多，并用思維導(dǎo)圖的方式記錄下來，方便自己后期溫故。如果你剛好沒有讀過，可以當(dāng)做度這本書的預(yù)習(xí)閱讀，相信你也會有所收獲（思維導(dǎo)圖圖片可能有點(diǎn)小，記得點(diǎn)開看）

這一章介紹了 Web 及網(wǎng)絡(luò)協(xié)議的基礎(chǔ)，http 通訊被拆分成四層，應(yīng)用層，傳輸層，網(wǎng)絡(luò)層和鏈路層，每層只要考慮分派給自己的任務(wù)，不需要弄清整個協(xié)議鏈路的細(xì)節(jié)。應(yīng)用層使我們?nèi)庋勰芸匆姷模覀兂Ｓ玫?http 協(xié)議和 FTP 協(xié)議就處在這一層，往下就是傳輸層，TCP/IP 協(xié)議工作的地方（我們的IP是IP地址，和這里的IP 協(xié)議有做區(qū)分），再往下是網(wǎng)絡(luò)層，傳輸層建立連接之后，網(wǎng)絡(luò)層負(fù)責(zé)將數(shù)據(jù)包的傳輸（數(shù)據(jù)包是網(wǎng)絡(luò)傳輸?shù)淖钚挝唬?。最后是鏈路層，用來連接網(wǎng)絡(luò)配件的部分，舉個栗子就是我們常說的網(wǎng)卡啊，光纖啊。在一個完整的數(shù)據(jù)傳輸中，客戶端會按照應(yīng)用層，傳輸層，網(wǎng)絡(luò)層，鏈路層的順序進(jìn)行進(jìn)行處理，每一層都會加一個首部，服務(wù)器端在接收的時(shí)候按照鏈路層，網(wǎng)路層，傳輸層，應(yīng)用層的順序去移除首部。

我們常說的3次握手就是 TCP 協(xié)議采用的策略，為了傳輸方便，TCP 將大數(shù)據(jù)分割成以報(bào)文為單位的數(shù)據(jù)包，IP 協(xié)議負(fù)責(zé)把數(shù)據(jù)包發(fā)送出去。在發(fā)送的過程中常常需要經(jīng)過多個路由器的中轉(zhuǎn)，這個時(shí)候會運(yùn)用 ARP 協(xié)議來查找下一個路由器的地址。

通常用戶的習(xí)慣會去訪問域名而不是IP地址，將域名解析成對應(yīng)的 IP 就需要用到 DNS 協(xié)議域名解析的服務(wù)。

日常開發(fā)中我們感知不到 http 協(xié)議的底層實(shí)現(xiàn)，我們所了解的 HTTP 協(xié)議總是由客戶端發(fā)起，服務(wù)端接收。我們關(guān)注到的請求，常常是請求的URI，協(xié)議版本，頭部信息，及內(nèi)容實(shí)體，我們常使用的響應(yīng)信息則包括了響應(yīng)狀態(tài)，響應(yīng)內(nèi)容。

我們常常會使用不通的 http 方法來執(zhí)行不同的操作。我們常使用 GET 來獲取資源，使用 POST 傳輸實(shí)體主題，使用 PUT 傳輸文件，使用 DELETE 刪除文件，使用 OPTIONS 詢問支持的方法（常常在跨域的場景中使用），使用TRACE 獲取訪問路徑，使用 CONNECT 用隧道協(xié)議鏈接代理。

http 協(xié)議是一種無狀態(tài)協(xié)議，不會去記錄上一次訪問狀態(tài)，這使得當(dāng)我們要做類似于登錄這樣的公能的時(shí)候，需要通過 cookie 來進(jìn)行狀態(tài)的管理。

通常HTTP報(bào)文（用于HTTP協(xié)議交互的信息）的結(jié)構(gòu)包括，請求行，狀態(tài)行，首部字段等，從 HTTP 的報(bào)文中，我們可以獲得很多信息。在 MIME 擴(kuò)展中會使用一種稱為多部分對象集合的方法，來容納多份不同的數(shù)據(jù)類型， 在 HTTP 報(bào)文中使用多部分對象時(shí)，需要在首部字段上加上 Content-type 。

通過設(shè)置首部字段，來達(dá)到獲取部分內(nèi)容范圍請求（請求資源中斷后，不需要重新開始請求),將傳輸內(nèi)容編碼的目的，來提高加載效率。

有的時(shí)候不同的場景需要我們獲取不同的內(nèi)容，就比如頁面的中英文切換的功能，在HTTP請求中，我們通過設(shè)置 accept 類的請求頭字段實(shí)現(xiàn)，也就是內(nèi)容協(xié)商的方式，返回最合適的內(nèi)容。協(xié)商方式分為，服務(wù)器驅(qū)動協(xié)商，客戶端驅(qū)動協(xié)商，透明協(xié)商。

在HTTP通訊中，通過轉(zhuǎn)態(tài)碼，告知客戶端的請求狀態(tài)。狀態(tài)碼大致可以被分為 5 大類，1xx 表示接受的請求正在處理，2xx 表示請求正常處理完畢，3xx 表示需要進(jìn)行附加操作以完成請求，4xx 表示客戶端無法處理請求，5xx 表示服務(wù)器處理出錯。

在這5大類請求中，我們常用的十幾種狀態(tài)碼，需要我們重點(diǎn)去掌握，詳細(xì)介紹看