圖解HTTP筆記

這段時間跟同事借了本圖解HTTP，邊看邊作筆記~

1、瞭解Web及網絡基礎

Web使用HTTP(HyperText Transfer Protocol 超文本傳輸協議)做爲規範，完成從客戶端到服務端等一系列運做流程。協議是指規則的約定

網絡基礎TCP/IP協議族。一般使用的網絡(包括互聯網)是在TCP/IP協議族的基礎上運做的，而HTTP屬於它內部的一個子集

計算機與網絡設備要互相通訊，雙方就必須基於相同的方法。好比如何探測到通訊目標、由哪一邊先發起通訊、使用哪一種語言進行通訊、怎麼樣結束通訊等規則都須要事先肯定，全部的一切都須要一種規則，而咱們就把這種規則成爲協議

TCP/IP協議族裏面重要的一點就是分層。TCP/IP協議族按層次分別分爲：

• 應用層 (決定了向用戶提供應用服務時通訊的活動，如FTP、DNS。HTTP也處於該層)
• 傳輸層 (提供處於網絡鏈接中的兩臺計算機之間的數據傳輸，TCP、UDP)
• 網絡層 (處理在網絡上流動的數據包，數據包是網絡傳輸的最小數據單位。該層規定了經過怎樣的路徑到達對方計算機並把數據包傳送給對方)
• 數據鏈路層 (處理鏈接網絡的硬件部分，包括操做系統、硬件的設備驅動、NIC、光纖等)

利用TCP/IP協議族進行網絡通訊時，會經過分層順序與對方進行通訊。發送端從應用層往下走，接收端則從鏈路層往上走

發送端在層與層之間傳輸數據時，每通過一層時一定會被打上一個該層所屬的首部信息。在接收端在層與層傳輸數據時，每通過一層 時會把對應的首部消去

---

與HTTP關係密切的協議：

• 負責傳輸的IP協議： IP網際協議位於網絡層，做用是把各類數據包傳送給對方並確保正確傳送

• 確保可靠性的TCP協議： TCP位於傳輸層，提供可靠的字節流服務(爲了方便傳輸，將大塊數據分割成以報文段爲單位的數據包進行管理)。可靠是指能將數據準確可靠地傳給對方。採用三次握手策略(使用SYN和ACK標誌)

  發送端首先發送一個帶SYN標誌的數據包給對方。接收端收到後，回傳一個帶有SYN/ACK標誌的數據包以示傳達確認信息。最後發送端回傳一個帶ACK標誌的數據包表明握手結束

• 負責域名解析的DNS服務： DNS位於運用層，提供域名到IP地址之間的解析服務

他們之間的協做關係：

2、簡單的HTTP協議

客戶端：請求訪問文本或圖像等資源的一端
服務器端：提供資源響應的一端

2.1 HTTP協議規定，請求從客戶端發出，最後服務器端響應該請求並返回

HTTP不對請求和響應之間的通訊狀態進行保存/持久化處理，是一種不保存狀態，即無狀態協議：爲了更快地處理大量事務，確保協議的可伸縮性(後面引入Cookie作狀態管理)，減小內存資源損耗

2.2 HTTP方法：

• GET：獲取資源(1.0/1.1)
• POST：傳輸實體主體(1.0/1.1)
• PUT：傳輸文件(自身不帶驗證機制，存在安全性問題，通常不會使用)(1.0/1.1)
• HEAD：獲取相應首部，做驗證URI使用(1.0/1.1)
• DELETE：刪除文件(自身不帶驗證機制，存在安全性問題，通常不會使用)(1.0/1.1)
• OPTIONS：詢問支持的方法(1.1)
• CONNECT：要求用隧道協議鏈接代理(1.1)
• TRACE: 追蹤路徑(1.1)

2.3 持久鏈接

在HTTP協議的初始版本中，每進行一次HTTP通訊就要斷開一次TCP鏈接，會形成無畏的TCP鏈接和斷開，增長通訊量的開銷(客戶端與服務器端進行一次請求會通過創建TCP鏈接、HTTP請求與相應、斷開TCP鏈接三個階段)

爲了解決上述問題，HTTP/1.1和一部分的HTTP/1.0想出了持久鏈接(HTTP keep-alive)：只要任意一端沒有明確提出斷開鏈接，則保持TCP鏈接狀態(客戶端與服務器端進行一次請求會通過創建TCP鏈接、第一個HTTP請求與相應、第二個HTTP請求與相應、第N個HTTP請求與相應、斷開TCP鏈接三個階段)

好處：減小了TCP鏈接的重複創建和斷開所形成的額外開銷，減輕了服務器端的負載

在HTTP/1.1中，全部的鏈接默認都是持久鏈接。而HTTP/1.0內未標準化，須要經過非標準手段實現，須要兩邊支持

2.4 管線化

持久鏈接使得多數請求以管線化方式發送成爲可能，在以前發送請求後須要等待並接收響應，才能發送下一個請求(如2.3中所提)。管線化技術出現後，不用等待響應亦可直接發送下一個請求，即同時並行發送多個請求(客戶端與服務器端進行一次請求會通過創建TCP鏈接、第一個HTTP請求、第二個HTTP請求、第N個HTTP請求、第一個HTTP響應、第二個HTTP響應、第N個HTTP響應、斷開TCP鏈接三個階段)

3、HTTP報文內的HTTP信息

HTTP報文大體可分爲報文首部和報文主體，由空行(CR+LF)劃分。不必定要有報文主體

請求報文：請求行+請求首部字段+通用首部字段+實體首部字段+其餘
響應報文：狀態行+響應首部字段+通用首部字段+實體首部字段+其餘

4、返回結果的HTTP狀態碼

4.1 狀態碼的類別

• 1xx：信息性狀態碼 接收的請求正在處理
• 2xx：成功狀態碼 請求正常處理完畢
• 3xx：重定向狀態碼 須要進行附加操做以完成請求
• 4xx：客戶端錯誤狀態碼 服務器沒法處理請求
• 4xx：服務器錯誤狀態嗎 服務器處理請求出錯

4.2 常見狀態碼

記錄的HTTP狀態碼有不少，在平時中經常使用的有如下：

• 200 OK (表示從客戶端發來的請求在服務器端被正常處理了)
• 204 No Content (表示服務器接收的請求已成功處理，但返回的響應報文中不含實體的主體部分)
• 206 Partial Content (表示客戶端進行了範圍請求，服務器成功執行)
• 301 Moved Permanently (永久性重定向，表示請求的資源已被分配了新的URI，之後應使用新的)
• 302 Found (臨時性重定向，表示請求的資源已被分配了新的URI，但願用戶使用新的)
• 304 Not Modified (表示客戶端發送附帶條件的請求時，服務器端容許訪問資源，但因未知足條件。協商緩存標誌)
• 400 Bad Request (表示請求報文中存在語法錯誤)
• 401 Unauthorized (表示發送的請求須要有經過HTTP認證)
• 403 Forbidden (表示請求資源的訪問被服務器拒絕)
• 404 Not Found (表示在服務器上沒法找到請求的資源)
• 500 Internal Server Error (表示服務器端在執行請求時發生錯誤)
• 503 Service Unavailable (表示服務器暫時處於超負荷或正在進行停機中，沒法處理請求)

5、HTTP首部

5.1 首部類型

HTTP首部字段起到傳遞額外重要信息的做用，會根據實際用途分爲四種類型：

• 通用首部字段(請求報文和響應報文兩方都會使用的首部)
• 請求首部字段
• 響應首部字段
• 實體首部字段(針對請求報文和響應報文的實體部分使用的首部)

5.2 首部定義

HTTP/1.1規範定義了以下47種首部字段：

5.2.1 通用首部字段

1. Cache-Control 控制緩存的行爲
2. Connection 逐跳首部、鏈接的管理
3. Date 建立報文的日期時間
4. Pragma 報文指令
5. Trailer 報文末端的首部一覽
6. Transfer-Encoding 制定報文主體的傳輸編碼方式
7. Upgrade 省級文其餘協議
8. Via 代理服務器的相關信息
9. Warning 錯誤通知

5.2.2 請求首部字段

1. Accept 用戶代理可處理的媒體類型
2. Accept-Charset 優先的字符集
3. Accept-Encoding 優先的內容編碼
4. Accept-Language 優先的語言
5. Authorization web認證信息
6. Expect 期待服務器的特定行爲
7. From 用戶的電子郵箱地址
8. Host 請求資源所在服務器
9. if-Match 比較實體標記
10. if-Modified-Since 比較資源更新時間
11. if-None-Match 比較實體標記
12. If-Range 資源未更新時發送實體Byte的範圍請求
13. If-Unmodified-Since 比較資源的更新時間
14. Max-Forwards 最大傳輸逐跳數
15. Proxy-Authorization 代理服務器要求客戶端的認證信息
16. Range 實體的字節範圍請求
17. Referer 對請求中URI的原始獲取方
18. TE 傳輸編碼的優先級
19. User-Agent HTTP客戶端程序的信息

5.2.3 響應首部字段

1. Accept-Ranges 是否接受字節範圍請求
2. Age 推算資源建立通過時間
3. ETag 資源的匹配信息
4. Location 令客戶端重定向至指定URI
5. Proxy-Authenticate 代理服務器對客戶端的認證信息
6. Retry-After 對在此發起請求的時機要求
7. Server HTTP服務器的安裝信息
8. Vary 代理服務器緩存的管理信息
9. WWW-Authenticate 服務器對客戶端的認證信息

5.2.4 實體首部字段

1. Allow 資源科支持的HTTP方法
2. Content-Encoding 實體主體適用的編碼方式
3. Content-Language 實體主體的天然語言
4. Content-Length 實體主體的大小
5. Content-Location 代替對應資源的URI
6. Content-MD5 實體主體的報文摘要
7. Content-Range 實體主體的位置範圍
8. Content-Type 實體主體的媒體類型
9. Expires 實體主體過時的日期時間
10. Last-Modified 資源的最後修改日期時間

做爲了解就好，通常也記不住這麼多配置字段。在須要用到的時候再對應查閱就好

5.3 非HTTP/1.1首部字段

在HTTP協議通訊交互中使用到的首部字段，不限於RFC2616中定義的47種首部字段，還有Cookie、Set-Cookie和Content-Disposition等在其餘RFC中定義的首部字段，它們的使用頻率也很高

5.4 部分首部字段的使用

5.4.1 Cache-Control (通用首部字段)

操做緩存的工做機制的重要字段，按請求和響應分類爲： 緩存請求指令：

• no-cache 強制想源服務器再次驗證
• no-store 不緩存請求或響應的任何內容
• max-age 響應的最大Age
• max-stale 接受已過時的響應
• min-flesh 指望在指定時間內的響應仍有效
• no-transform 代理不可更改媒體類型
• only-if-cached 從緩存獲取資源
• cache-extension 新指令標記

緩存響應指令：

• public 可向任意方提供相應的緩存
• private 僅向特定用戶返回響應
• no-cache 緩存錢必須先確認其有效性
• no-store 不緩存請求或響應的任何內容
• no-transform 代理不可更改媒體類型
• must-revalidate 可緩存但必須再向源服務器進行確認
• proxy-revalidate 要求中間緩存服務器對緩存的響應有效性再進行確認
• max-age 響應的最大Age
• s-maxage 公共緩存服務器響應的最大Age值
• cache-extension 新指令標記

相關配置內容較多，緩存配置使用，具體再查

5.4.2 Connection (通用首部字段)

字段具有以下兩個做用：

• 控制再也不轉發給代理的首部字段
• 管理持久鏈接

Connection： 再也不轉發的首部字段名 Connection： Close/Keep-Alive

HTTP/1.1 默認鏈接都是持久鏈接，當服務器端想明確斷開鏈接時，會指定Connection的值爲Close。在HTTP/1.1以前的HTTP版本的默認鏈接都是非持久鏈接，若是須要連續，須要指定Connection的值爲Keep-Alive

5.4.3 Pragma (通用首部字段)

Pragma是HTTP/1.1以前版本的遺留字段，僅做爲與HTTP/1.0的向後兼容而定義，做用和Cache-Control同樣

5.4.4 Accept (請求首部字段)

Accept: text/html,application/xhtml+xml,application/xml,image/jpeg,image/png,video/mpeg,application/zip

5.4.5 Accept-Encoding (請求首部字段)

告知服務器用戶代理支持的內容編碼以及內容編碼的優先級順序 Accept-Encoding: gzip,deflate

5.4.6 If-Match (請求首部字段)

形如If-xxx這樣的請求首部字段，均可以稱爲條件請求。服務器接收到附帶條件的請求後，只有判斷指定條件爲真時，纔會執行 只有當If-Match的字段值和ETag值匹配一致時，服務器纔會接受請求

5.4.7 If-Modified-Since (請求首部字段)

操做緩存的工做機制的重要字段，它會告知服務器若If-Modified-Since字段值早於資源的更新時間，則處理請求，返回更新後的資源+Last-Modified。若在指定時間以後，若是請求的資源沒有更新過，則返回304Not Modified的響應

5.4.8 Range (請求首部字段)

請求獲取指定範圍的資源數據 Range： bytes=5001-10000

5.4.9 Accept-Ranges (響應首部字段)

告知客戶端服務器是否能處理範圍請求 Accept-Ranges：bytes/none

5.4.10 Etag (響應首部字段)

告訴客戶端實體標識。它是一種可將資源以字符串形式作惟一性標識的方式，當資源更新時，ETag也會更新

5.4.11 Content-Encoding (實體首部字段)

告知客戶端服務器對實體的主體部分選用的內容編碼方法 Content-Encoding：gzip/compress/deflate/identity

5.4.12 Expires (實體首部字段)

告知接收方資源的失效日期。緩存服務器在接收到含有Expires的響應後，會以緩存來應答請求，在指定的時間以前，響應的副本會一直被保存。當超過指定的時間後，緩存服務器在請求發送過來時，會轉向源服務器請求資源

5.4.13 Last-Modified (實體首部字段)

指明資源最終修改的時間

5.4.14 爲Cookie服務的首部字段

• Set-Cookie：服務器設置客戶端
• Cookie：客戶端攜帶發送給服務端

後面章節開始衍生知識點，如HTTPS、安全設置等。上面篇幅已經有點多，留到下一篇~