【網路知識】|作者/ 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開發