《圖解Http》 2-6章： 基礎，報文，狀態碼，首部。

HTTP協議和Cookie

是stateless協議，自身不對請求和響應之間的通訊狀態進行保存。但隨着技術發展，爲了實現保存狀態的功能，引入了Cookie技術。

Cookie在請求和響應報文中寫入信息來控制客戶端的狀態。

1. Cookie根據從服務器發送的響應報文內的Set-Cookie的首部字段信息，通知客戶端保存Cookie。
2. 下次客戶端發送請求時，會在報文中加入Cookie值。
3. 服務器收到報文後，檢查Cookie，確認是哪一個客戶端發過來的鏈接請求，而後再對比服務器上的記錄，獲得以前的狀態信息。

 

告知服務器意圖的HTTP 方法：

GET，POST

HEAD：得到報文首部，不返回主體部分。用於確認URL的有效性和資源更新的日期時間等。

PUT, DELETE： 不帶驗證機制，只當配合Web應用的驗證機制或遵照REST標準時使用。

OPTIONS: 詢問支持的方法

CONNECT：要求用隧道協議鏈接代理。

 

持久鏈接，HTTP1.1的特性：

不會每次HTTP通訊後都斷開，這樣減小重複創建鏈接和斷開的負擔。

管線化：在鏈接的時候，發送請求，和響應請求分開了。能夠並行發送多個請求，無需一個接一個等待響應。

---

---

 

 

第3章 HTTP報文內的信息

以前的博客（有圖）https://www.cnblogs.com/chentianwei/p/9485301.html

3.1報文 message

分爲：通用的首部，請求首部，響應首部，實體首部4種。常見的見以前的博客的表格。

 

3.4發送多種數據的多部分對象集合Multipart

HTTP協議發送的報文主體內可含有多類型實體，一般是在圖片或文本文件上傳時使用：

multipart/form-data: 表單上傳

multipart/byteranges：狀態碼206響應報文包含了多個範圍的內容時使用

使用Content-Type,並加上boundary=XXX

集合對象中的每一個對象使用--XXX進行區分，最後的結尾用--XXX--標誌來表明結束。

 

3.5獲取部份內容（圖片）的range request

超大的圖片下載過程，一旦中斷，無需重新下載，由於它使用了Range Request。相似把大圖切割成幾部分，就像包同樣。

Content-Range: bytes 5001-10000/10000

---

 

 

第4章 狀態碼

60多種，經常使用14種。

 

200: ok

204: No Content, 請求處理成功了，但返回的response message中沒有主體部分。

206: Partial Content, 表示客戶端進行了Range request，服務器成功執行了這部分GET請求。響應報文中包含了Content-Range指定的實體內容。

 

301: Move Permanently, 表示請求的資源已經被分配了新的URL, 之後應使用資源如今所指向的URL.

302:Found, 表示臨時重定向，表示請求的資源被分配了新的URL，但願本次使用這個URL訪問。

303: See Other，表示請求對應的資源存在另外一個URL,應該使用GET方法定向獲取請求的資源。其餘和302相似。

 

304: Not Modified， 表示客戶端發送帶條件的請求，服務器容許請求訪問資源，但未知足條件的狀況。304返回時，不帶響應的主體部分。

⚠️（if-Match, If-Modified-Since,If-None-Match, If-Range, If-Unmodified-Since)首部

 

307: Temporary Redirect等同302，業界習慣POST變成GET。

 

400: Bad Request, 表示請求報文中有語法錯誤❌。

401 Unauthorized, 表示須要經過HTTP認證

403 Forbidden，服務器對請求資源的訪問拒絕。實體的主體部分看對緣由的描述。

404 Not Found， 服務器上沒法找到請求的資源，除此以外也能夠在服務器端拒絕請求而且不想說明理由時使用。

 

500 Internal Server Error ,表示服務器在執行請求時出現❌，bug，臨時故障。

503 Service Unavailable， 表示服務器暫時不可用，超載，停機維護。

 

⚠️ 狀態碼有可能和真實情況不一致。

---

 

 

第5章，和HTTP協做的Web服務器。

5.1虛擬主機virtual Host技術

讓一臺服務器託管了N多個域名。 Web託管服務的供應商就是這麼作的。

所以，發送HTTP請求，必須使用完整的主機名或域名URL

 

5.2 通訊數據轉發程序

代理：使用代理服務器能夠減小網絡帶寬的流量（利用緩存技術）

 

緩存代理proxy：在代理服務器上儲存從源服務器上發過來的response message。

緩存有效期。客戶端也能夠緩存。

 

網關：和代理相似，但能夠提供非HTTP協議服務。提升了安全性，如：鏈接數據庫，鏈接信用卡結算系統

隧道： 使用SSL等加密手段進行通訊。確保安全通訊。

---

---

 

 

第6章HTTP首部

4種類型：

General Header Fields,

Request Header Fields,　補充了請求的附加內容， 客戶端信息， 響應內容相關優先級等信息。

Response Header Fields, 補充了響應的附加內容，也會要求客戶端附加額外的內容信息。

Entity Header Fields， 報文實體部分使用的首部，補充了資源內容更新時間等和實體有關的message.

詳細講解見本書85頁

Request header Fields

---

 

 

6.3 HTTP1.1通用首部字段

6.31Cache-Control （有20來個指令，見86頁）

博客相關知識：https://www.cnblogs.com/chentianwei/p/9374341.html

 

public/private: 是否其餘用戶也能夠利用緩存。

no-cache：實際意思是不緩存過時的資源

若是是響應指令，表明緩存前必須先確認其有效性。若是是請求指令，表明向源服務器取資源不要緩存。

目的：防止從緩存中返回過時的資源。

no-store: 不儲存緩存資源，真正的不緩存。

max-age: 表明資源保存爲緩存的最長時間。max-age比Expires優先級高。

max-stale: 最大過時時間。即便超過max-age,但沒超過max-stale 緩存仍然會被客戶端接收。

6.32 Connection

• 控制再也不轉發給代理的首部字段 Connection: 再也不轉發的首部字段名
• 管理持久鏈接。Connection: close/ keep-Alive

 

6.33 Date 建立報文的時間。

6.36 Transfer-Encoding: chunked

規定使用分快傳輸的編碼方式。

6.38 Via

用於追蹤傳輸路徑，報文通過代理和網關時會在via中附加該服務器的信息。

6.39 Warning （具體見98頁）

告知用戶一些和緩存相關的問題的警告。

Warning: [警告碼][主機: 端口號]"[警告內容]"([日期時間])

 

---

 

 

6.4 request header fields

6.41 accept

 

 

6.45 Authorization

 

6.47 host

 

6.48 If-Match

若是是星號*，If-Match:*, 則忽略ETag值。只要資源存在就處理。

If-Match和If-None-Match做用相反。

---

 

 

6.5 response header fields

6.51 accept-ranges

6.53ETag

---

 

 

6.6 Entity header fields

6.66 Content-MD5

---

 

 

6.7爲Cookie服務的header fields（130頁）

工做機制： 用戶識別，狀態管理。

Set-Cookie: 響應首部字段

Cookie： 請求首部字段

屬性：