一、HTTP協(xié)議用于客戶端和服務端之間的通信

1、http協(xié)議規(guī)定，請求是從客戶端發(fā)出，最后服務器端相應該請求并返回

2、請求報文是由請求方法，請求URI，協(xié)議版本，可選的請求首部字段和內(nèi)容實體構成。

? ? ??

3、響應報文基本上由協(xié)議版本，狀態(tài)碼，解釋狀態(tài)碼的原因短語，可選的響應首部字段以及實體主體構成。

? ? ??

4、告知服務器意圖的HTTP方法

• GET：獲取資源，如果為資源則保持原樣返回，如果為程序則返回程序執(zhí)行后的結果。
• POST：傳輸實體主體
• PUT：用來傳輸文件，要求在請求報文的主體中包含文件內(nèi)容，然后保存到請求URI指定的位置。（自身不帶驗證機制，存在安全問題，一般不使用該方法）
• HEAD：與GET方法類似，只是不返回報文主體部分。用于確認URI的有效性及資源更新的日期時間等。
• DELETE：與put相反，表示刪除某資源，一般不適用。
• OPTIONS：詢問支持的方法。
• TRACE：追蹤路徑，將web服務器之前等請求通信環(huán)給客戶端的方法。在MAX-Forwards首部字段中填入數(shù)值，每經(jīng)過一個服務器段，該數(shù)字就-1，當數(shù)值剛好為0時，就停止繼續(xù)傳輸，最后收到請求的服務器則返回狀態(tài)碼200 OK的響應。客戶端通過TRACE方法可以查詢發(fā)送出去的請求是如何被加工的。（不常用）
• CONNECT：要求用隧道協(xié)議連接代理，實現(xiàn)用隧道協(xié)議進行TCP通信。（使用SSL和TLS）

5、持續(xù)連接節(jié)省通信量

傳統(tǒng)每請求一次就要三次握手連接tcp四次握手斷開，但是原來傳輸量特別小，所以影響不大，但是當下一個html可能包含n多圖片，會造成過多無謂大通信量。

• 持久連接：只要任意一段沒有明確提出斷開連接，則保持TCP連接。HTTP1.1默認所有連接都是持久連接。

? ? ? ?

• 管線化：曾經(jīng)是發(fā)送請求后需要等待并收到響應，才會發(fā)送下一個請求。管線化技術不用等待響應亦可直接發(fā)送下一個請求。可以讓更多請求更快結束。（速度快很多）

? ? ? ? ?
?

二、使用Cookie的狀態(tài)管理

http協(xié)議本身不保留之前一切的請求和響應報文的信息，這是為了更快地處理大量食物，確保協(xié)議的可伸縮性，而特意把HTTP協(xié)議設計成如此簡單。但是假如用戶登陸了某界面，需要保存用戶登陸過這個事實該怎么辦？于是引入了Cookie技術。于是乎就可以管理狀態(tài)了。

如果讓服務器管理全部客戶端狀態(tài)會成為負擔。故引入Cookie技術解決該矛盾：Cookie會根據(jù)從服務端發(fā)送的響應報文中一個叫做set-Cookie的首部字段信息，通知客戶端保存Cookie。當下次客戶端再往該服務器發(fā)送請求時，客戶端會自動在請求報文中加入Cookie的值發(fā)送出去。

服務器發(fā)現(xiàn)客戶端發(fā)送過來的Cookie后，會去檢查究竟是從哪一個客戶端發(fā)來的連接請求，然后對比服務器上的紀錄，得到最終狀態(tài)信息。

總結

以上是生活随笔為你收集整理的HTTP协议的工作原理的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。