發送請求:
傳回時, content-type 與 HTTP 正文之間有一個空格
HTTP 是不儲存狀态協定, 也就是說在 HTTP 這個級别, 協定對于發送過的請求或相應都不做持久化處理.
但是, 比如使用者登入到一家購物網站, 即使他跳轉到該站的其他頁面後, 也需要能繼續保持登入狀态, 針對這個執行個體, 網站為了能夠掌握是誰送出的請求, 需要儲存使用者的狀态. HTTP1.1 雖然是無狀态協定, 但為了實作期望的保持狀态功能, 于是引入了 Cookie 技術.
GET: 擷取資源
POST: 傳輸實體到伺服器
PUT : 傳輸檔案到伺服器
HEAD: 獲得封包首部, head 方法和 GET 方法一樣, 隻是不傳回封包主體内容.
DELETE : 删除檔案, 于 PUT 相反
HTTP 協定的初始版本, 每進行一次HTTP通信就要斷開一次TCP連接配接.
為解決上述 TCP 連接配接問題, HTTP/1.1 想出了持久連接配接, 持久連接配接的特點是, 隻要任意一端沒有明确提出斷開連接配接, 則保持 TCP 連接配接狀态.
持久連接配接的好處在與減少了TCP連接配接的重複建立和斷開所造成的額外開銷, 減輕了伺服器端的負載.
在 HTTP/1.1 中, 所有的連接配接預設都是持久連接配接.
持久連接配接使得多數請求以管線化的方式發送成為可能. 從前發送請求後需等待并收到響應, 才能發送下一個請求, 管線化技術出現後, 不用等待響應亦可直接發送下一個請求. 這樣能夠做到同時并行發送多個請求, 而不需要一個接一個的等待響應了.
保留無狀态協定這個特征的同時又要解決伺服器的負擔過重(如果由伺服器來管理所有的用戶端資訊)的沖突問題, 引入了 Cookie技術, Cookie技術通過在請求和響應封包中寫入 Cookie資訊來控制用戶端狀态.
Cookie 會根據從伺服器端發送的響應封包内的一個叫 Set-Cookie的首部字段資訊, 通知用戶端儲存Cookie, 當下次用戶端再往該伺服器發送請求時, 用戶端會自動在請求的封包中加入Cookie值後發送出去.
伺服器發現用戶端發送過來的 Cookie後, 會去檢查究竟是哪個用戶端發來的請求, 然後對比伺服器上的記錄, 最後得到之前的狀态資訊.
下邊序号, 對應上圖
注意下邊的 set-Cookie: sid
再次請求時, 就包含了 Cookie 資訊