HTTP結構

HTTP結構

轉載請註明出處：HTTP結構簡介

HTTP通訊過程包括從客戶端發往服務器的請求和服務器返回客戶端的響應，這篇文章就簡單的瞭解一下HTTP請求和響應的結構與協議自己的狀態管理。

用戶HTTP協議交互的信息被稱爲HTTP報文，HTTP報文可分爲請求報文和響應報文。請求報文包括請求行、首部字段(請求、通用、實體)和報文主體。響應報文包括狀態行、首部字段(響應、通用、實體)和報文主體。

常見的請求頭和響應頭以下

關於圖中涉及的請求與響應首部字段在以後的文章會涉及到。

1.HTTP是不保存狀態的協議

HTTP是一種不保存狀態，即無狀態協議。HTTP協議自己不對請求和響應的通訊狀態進行保存。也就是說，HTTP協議對於發送過的請求和響應都不作持久化處理。

這樣作的好處是爲了更快的處理大量事務，確保協議的可伸縮性。可是隨着web的不斷髮展，由於無狀態協議而致使業務處理變得棘手。如用戶登陸到一個電商網站，即便他跳轉到該網站的其餘頁面，也須要能保持登陸狀態。若是仍然保持無狀態協議的話，那每次進行頁面跳轉都須要從新登陸一次。

雖然HTTP/1.1是無狀態協議，可是爲了實現保持狀態功能而引入了Cookie。有了Cookie進行狀態管理以後，就能夠實現登陸、購物車等功能了。

2.Cookie

因爲HTTP是無狀態協議，所以引入了Cookie技術進行狀態管理。

好比咱們要實現的功能是：在登陸以後的5天內，訪問同一個網站時都不用再次登陸。

要實現這個持久登陸的功能，就可使用Cookie對用戶身份進行狀態管理。過程大體以下：

1. 第一次登陸時，服務端在響應頭部設置Set-Cookie字段(包括name, value, path, expires, httpOnly, domain等)。
2. 瀏覽器接收到響應以後，會對Cookie信息進行存儲。
3. 在下次訪問該頁面時，瀏覽器在發送請求時會將Cookie自動帶上，一同發向服務器。
4. 服務器在收到瀏覽器發過來的請求時，對傳過來的Cookie信息和服務器的Cookie信息進行匹配校驗，若是匹配成功，則獲得以前的狀態信息。

對Cookie不熟悉的同窗能夠看看這篇文章。傳送門: 前端存儲

給一個生動的圖片說明Cookie狀態管理。

針對登陸態還應該防範XSS攻擊和CSRF攻擊。不熟悉的同窗能夠看看這篇文章。前端安全之XSS 前端安全之XSS

3. 持久鏈接節省通訊

HTTP協議的初始版本中，每進行一次HTTP通訊就要斷開一個TCP鏈接。這種非持久鏈接的缺點在於每次請求都會形成無謂的TCP鏈接創建和斷開，增長TCP協議自己的開銷。

例如，在訪問某東電商網站時，若是是非持久的通訊，那麼會出現以下狀況。

加載DOM節點(三次握手 + HTTP通訊 + 四次分手)
加載各類商品圖片([三次握手 + HTTP通訊 + 四次分手] x N次)
...其餘前端資源([三次握手 + HTTP通訊 + 四次分手] x (N + 1)次)

訪問一次頁面時就要創建和斷開TCP鏈接無數次，這無疑會致使前端頁面渲染的性能問題。

3.1 持久鏈接

爲了解決不斷創建和斷開TCP鏈接的問題，HTTP/1.1實現了持久鏈接，即在請求頭和響應頭都有相應的Connection: Keep-Alive字段。持久鏈接的特色是，只要任意一端沒有明確提出斷開TCP鏈接，則保持TCP鏈接狀態。

持久鏈接(keep-alive)的好處在於減小了TCP鏈接的重複創建和斷開所形成的額外開銷，減輕了服務器端的負載，加快了網頁渲染的速度。

3.1 管線化

之前發送請求後須要收到響應，才能發送下一個請求。持久鏈接意味着能夠在一次TCP鏈接以後發送多個請求，而管線化技術的出現使得每一個請求能夠異步發送，而不用等待響應了。也就是說，管線化可以作到同時並行發送多個請求，而不須要一個接一個的等待響應了。

好比說，當請求一個包含10張圖片的網頁，與挨個鏈接相比，採用持久鏈接能夠減小TCP鏈接創建與斷開的時間，而採用管線化技術則比持久鏈接更快，由於能夠異步發送請求。請求數量越多，時間差就越明顯。通常狀況下，會同時使用持久鏈接和管線化。

4 HTTP狀態碼

響應報文中包含的狀態行中，包含HTTP響應狀態碼。狀態碼的職責是當客戶端向服務器端發送請求時，描述返回的請求結果。

狀態行的格式以下：

[協議版本號] [狀態碼] [狀態碼對應信息]

HTTP狀態碼沒有什麼學習上的難度，只須要記住狀態碼對應的意思便可。如下是狀態碼的類別。

如下會對常見的狀態碼進行簡單的說明。

2XX 成功

200 OK: 服務器端正確處理請求。

201 Created: 請求已經被實現，並且有一個新的資源已經依據請求的須要而創建，且其URI已經隨Location頭信息返回。假如須要的資源沒法及時創建的話，應當返回'202 Accepted'。

202 Accepted: 服務器已接受請求，但還沒有處理。最終該請求可能會也可能不會被執行，而且可能在處理髮生時被禁止。

204 No Content: 服務器接收的請求已經成功處理，但在返回的響應報文中不包含實體的主體內容。也不容許返回任何實體的主體。通常在只須要從客戶端往服務器發送消息，而對客戶端不須要發送新信息內容的狀況下使用。

206 Partial Content: 客戶端進行範圍請求，而服務器成功執行了GET請求，會在響應報文中添加Content-Range指定範圍的實體內容。

3XX 重定向

301 Moved Permanently: 永久重定向。該狀態碼錶示請求的資源已經被分配到了新的URI，之後應使用資源如今所指的URI。

302 Found: 臨時重定向。該狀態碼錶示請求的資源被分配到了新的URI，但願用戶能使用(本次)新的URI進行訪問。

303 See Other: 表示因爲請求對應的資源存在着另外一個URI，應該使用GET方法定向獲取請求的資源。這個狀態碼我在實際業務中基本沒有見過...

304 Not Modified: 表示請求的資源在瀏覽器存在緩存，則服務器端會返回304，直接從瀏覽器讀取緩存，而不是從服務器獲取資源。雖然304狀態碼被劃分在3XX中，可是其和重定向沒有關係。

4XX 客戶端錯誤

400 Bad Request: 表示請求報文中存在錯誤。

401 Unauthorized: 表示發送的請求須要有經過HTTP認證的認證信息。當瀏覽器初次接收到401響應時，會彈出認證用的對話窗口。

403 Forbidden: 沒有權限訪問請求的資源。未得到文件系統的訪問權限，訪問權限出現某些問題(從未受權的IP地址試圖訪問)等狀況均可能會返回403。

404 Not Found: 服務器上沒法找到對應的請求資源。

5XX 服務器錯誤

500 Internal Server Error: 表示服務器端在執行請求時發生了錯誤。也有多是應用存在的bug獲某些臨時的故障。

503 Service Unavailable: 表示服務器暫時處於超負荷獲正在停機維護，如今沒法處理請求。