HTTP 02 HTTP1.1 協議

發送請求:

返回時, content-type 與 HTTP 正文之間有一個空格

HTTP 是不保存狀態協議, 也就是說在 HTTP 這個級別, 協議對於發送過的請求或相應都不作持久化處理.

可是, 好比用戶登陸到一家購物網站, 即便他跳轉到該站的其餘頁面後, 也須要能繼續保持登陸狀態, 針對這個實例, 網站爲了可以掌握是誰送出的請求, 須要保存用戶的狀態. HTTP1.1 雖然是無狀態協議, 但爲了實現指望的保持狀態功能, 因而引入了 Cookie 技術.

告知服務器意圖的HTTP方法

GET: 獲取資源

POST: 傳輸實體到服務器

PUT : 傳輸文件到服務器

HEAD: 得到報文首部, head 方法和 GET 方法同樣, 只是不返回報文主體內容.

DELETE : 刪除文件, 於 PUT 相反

持久鏈接節省通訊量

HTTP 協議的初始版本, 每進行一次HTTP通訊就要斷開一次TCP鏈接.

爲解決上述 TCP 鏈接問題, HTTP/1.1 想出了持久鏈接, 持久鏈接的特色是, 只要任意一端沒有明確提出斷開鏈接, 則保持 TCP 鏈接狀態.

持久鏈接的好處在與減小了TCP鏈接的重複創建和斷開所形成的額外開銷, 減輕了服務器端的負載.

在 HTTP/1.1 中, 全部的鏈接默認都是持久鏈接.

管線化

持久鏈接使得多數請求以管線化的方式發送成爲可能. 從前發送請求後需等待並收到響應, 才能發送下一個請求, 管線化技術出現後, 不用等待響應亦可直接發送下一個請求. 這樣可以作到同時並行發送多個請求, 而不須要一個接一個的等待響應了.

使用 Cookie 的狀態管理

保留無狀態協議這個特徵的同時又要解決服務器的負擔太重(若是由服務器來管理全部的客戶端信息)的矛盾問題, 引入了 Cookie技術, Cookie技術經過在請求和響應報文中寫入 Cookie信息來控制客戶端狀態.

Cookie 會根據從服務器端發送的響應報文內的一個叫 Set-Cookie的首部字段信息, 通知客戶端保存Cookie, 當下次客戶端再往該服務器發送請求時, 客戶端會自動在請求的報文中加入Cookie值後發送出去.

服務器發現客戶端發送過來的 Cookie後, 會去檢查到底是哪一個客戶端發來的請求, 而後對比服務器上的記錄, 最後獲得以前的狀態信息. 

下邊序號, 對應上圖

注意下邊的 set-Cookie: sid

再次請求時, 就包含了 Cookie 信息