【網絡知識】|?作者?/ Edison Zhou

這是EdisonTalk的第293篇原創內容

---

作為一個專業的IT技術人，一個Web應用開發者，不了解網絡基礎和協議，怎么能行？本文是我2016年閱讀《圖解HTTP》一書的讀書筆記，希望對你有所幫助！

1關于《圖解HTTP》

目前國內講解HTTP協議的書實在太少了，記憶中有兩本被譽為經典的書《HTTP權威指南》與《TCP/IP詳解，卷1》，但內容晦澀難懂，學習難度較大。其實，HTTP協議并不復雜，理解起來也不會花費太多學習成本，這本書的出現就及時緩解了該問題。對基礎及核心部分的深入學習是成為一名專業技術人員的前提，以不變應萬變才是立足之本。此外，這本書也是我在2016年度讀書計劃中的一本，它和《圖解TCP/IP》一起作為計算機網絡基礎部分為我溫故知新了一把，謝謝作者和譯者，畫了這么多圖解讓我們理解。

2HTTP協議初探

各種協議與HTTP協議的關系

請求處理相應模型

HTTP協議規定，請求從客戶端發出，最后服務端響應應該請求并返回。

請求報文：由請求方法、請求URI、協議版本、可選的請求首部字段和內容實體構成的。

響應報文：由協議版本、狀態碼、用以解釋狀態碼的原因短語、可選的響應首部字段以及實體主體構成。

HTTP協議是一種無狀態協議

HTTP協議對于發送過的請求或響應都不做持久化處理：協議本身并不保留之前一切的請求或響應報文的信息，這是為了更快地處理大量事務，確保協議的可伸縮性，而特意把HTTP協議設計成如此簡單的。HTTP/1.1雖然是無狀態協議，但為了實現期望的保持狀態功能，于是引入Cookie技術。有了Cookie再用HTTP協議通信，就可以管理狀態了。

Cookie根據服務器端發送的響應報文內的一個叫做Set-Cookie的首部字段信息，通知客戶端保存Cookie。當下次客戶端再往該服務器發送請求時，客戶端自動在請求報文中加入Cookie值后發送出去。服務端發現客戶端發送過來的Cookie后，會去檢查究竟是從哪一個客戶端發來的連接請求，然后對比服務器上的記錄，最后得到之前的狀態信息。

告知服務器意圖的HTTP方法

（1）GET：獲取資源

（2）POST：傳輸實體主體 → POST的主要目的并不是獲取響應的主體內容

（3）PUT：傳輸文件?→ 就像FTP協議的文件上傳一樣，要求在請求報文的主體中包含文件內容，然后保存到請求URI指定的位置

但是，鑒于HTTP/1.1的PUT方法自身不帶驗證機制，任何人都可以上傳文件，所以存在安全性問題，因此一般的Web網站不使用該方法。

（4）HEAD：獲得報文首部?→ HEAD與GET一樣，只是不返回報文主體部分，用于確認URI的有效性及資源更新的日期時間等等。

（5）DELETE：刪除文件?→ DELETE與PUT相反，DELETE按請求URI刪除指定資源。

但是，HTTP/1.1的DELETE方法本身與PUT方法一樣不帶驗證機制，所以一般的Web網站也不使用DELETE方法。

（6）OPTIONS：詢問支持的方法?→ 查詢針對請求URI指定的資源所支持的方法（例如該資源支持GET、POST、PUT等）。

（7）TRACE：追蹤路徑?→ 讓Web服務器端將之前的請求通信還回給客戶端的方法。（不常用，容易引發XST攻擊）

（8）CONNECT：要求用隧道協議連接代理?→ 要求在與代理服務器通信時建立隧道，實現用隧道協議進行TCP通信。主要使用SSL和TLS協議把通信內容加密后經過網絡隧道傳輸。

CONNECT方法的格式：CONNECT 代理服務器名：端口號 HTTP版本

持久連接

在HTTP協議的初始版本中，每進行一次HTTP通信就要斷開一次TCP連接。因此，每次的請求都會造成無謂的TCP連接建立與斷開，增加通信量的開銷。為了解決這個問題，HTTP/1.1想出了持久連接（也稱為HTTP keep-alive），其特點是：只要任意一端沒有明確提出斷開連接，則保持TCP連接狀態。

持久連接的好處在于減少了TCP連接的重復建立和斷開所造成的額外開銷，減輕了服務器的負載，也使得HTTP請求和響應能夠更早地結束，這樣Web頁面的顯示速度也就相應的提高了。在HTTP/1.1中，所有的連接默認都是持久連接。

3HTTP報文詳解

用于HTTP協議交互的信息就被稱為HTTP報文，請求段的叫做請求報文，響應端的叫做響應報文。HTTP報文本身是由多行（用CR+LF作換行符）數據構成的字符串文本。

HTTP報文結構

（1）HTTP報文大致可以分為報文首部和報文主體兩塊

　（2）請求報文和響應報文的結構實例

部分內容的范圍請求

通常下載一個大文件時如果遇到網絡中斷的情況，那就必須重頭開始，因此為了解決上述問題，就需要一種可恢復的機制。所謂恢復就是指從之前下載的中斷處恢復下載。要實現該功能需要制定下載的實體范圍，這就叫范圍請求（Range Request）。

對一份10000字節大小的資源，如果使用范圍請求，可以只請求5001~10000字節內的資源。執行范圍請求時，就會用到Range來指定資源的byte范圍。

內容協商機制

內容協商機制就是指在客戶端和服務端就響應的資源內容進行交涉，然后提供給客戶端最為合適的資源。內容協商會議響應資源的語言、字符集、編碼方式等作為判斷的基準。

So，有哪些判斷的基準呢？?

Accept Accept-Charset?

Accept-Encoding?

Accept-Language?

Content-Language

HTTP狀態碼

HTTP狀態碼負責表示客戶端HTTP請求的返回結果、標記服務器端的處理是否正常、通知出現的錯誤等工作。借助狀態碼，用戶可以知道服務器端是正常處理了請求，還是出現了錯誤。

（1）2XX 成功?→ 表明請求被正常處理了，如200 OK，204 No Content，206 Partial Content

（2）3XX 重定向?→ 表明瀏覽器需要執行某些特殊的處理以正確處理請求。如301 Moved Permanently（永久移動），302 Found（臨時移動），303 See Other（資源的URI已更新，是否能臨時按新的URI訪問）、304 Not Modified（資源已找到，但未符合條件請求）、307 Temporary Redirect（臨時重定向）

（3）4XX 客戶端錯誤?→ 表明客戶端是發生錯誤的原因所在。如400 Bad Request（請求報文中存在語法錯誤），401 Unauthorized（認證失敗或未認證）、403 Forbidden（不允許訪問這個資源）、404 Not Found（服務器上沒有請求的資源）。

（4）5XX 服務器錯誤?→ 表明服務器本身發生錯誤。如500 Internal Server Error（服務器端在執行請求時發生了錯誤，也可能是Web應用存在的Bug或某些臨時的故障），503 Service Unavailable（表明服務器暫時處于超負載或正在停機維護，無法處理請求）。

HTTP首部

　HTTP/1.1規范定義了如下47種首部字段：

（1）通用首部字段

（2）請求首部字段　

　（3）響應首部字段

　（4）實體首部字段

Ref參考資料

[日]上野宣，《圖解HTTP》

后臺回復：圖解HTTP，即可獲得pdf下載鏈接喲！

姊妹篇：《圖解TCP/IP》學習總結

????掃碼關注EdisonTalk

設為星標，不再失聯！

往期推文合集：2020年上半年推文合集

成都新鮮坑位：喜鵲生活招聘.NET開發

總結

以上是生活随笔為你收集整理的网络知识 | 《图解HTTP》读书笔记（上）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。