文章目錄

• 一.基本知識
• 二.非持續連接與持續鏈接
• • 1.采用持續連接的HTTP
  • 2.采用非持續連接的HTTP
• 三.HTTP報文格式
• • 1.請求報文
  • 2.應答報文
• 五.cookie
• 六.Web緩存
• • 1.基本概念
  • 2.緩存器的作用
  • 3.條件Get
  • 4.Web緩存器效率分析

---

查看優秀博客HTTPS協議的介紹及與HTTP協議的區別
聲明：本篇博客參考了書籍《計算機網絡自頂向下》和部分優秀博客

一.基本知識

（1）Web（World Wide Web的縮寫），意味全球廣域網，也稱為萬維網，是一種全球性的、動態交互的、跨平臺的分布式圖形信息系統。
（2）Web的應用層協議就是HTTP協議(超文本傳輸協議)，它是Web的核心，這可能也是為什么計算機網絡書籍都喜歡將Web和HTTP結合在一起敘述的原因。
（3）HTTP使用TCP作為它的支撐運輸協議。
（4）HTTP服務器不保存關于客戶的任何信息，是一個無狀態協議。（即數據包的發送、傳輸、和接收都是相互獨立的）

二.非持續連接與持續鏈接

1.采用持續連接的HTTP

所有的請求/響應經相同的TCP連接發送，這種方式我們稱之為持續鏈接。
當Web客戶端-服務器交互模式采用持續連接時，服務器在發送響應后保持該TCP連接打開，在相同的客戶端和服務器之間，后續的請求和響應報文能夠通過相同的連接進行傳送，特別是在同一個Web頁面上的資源。也有些可能位于同一個服務器的多個Web頁面在從該服務器發送給同一個客戶端時，可以在單個持續的TCP連接上進行。
一般來說，如果一個連接經過一定時間（可配置的超時時間間隔）仍未被使用，HTTP服務器就會關閉該連接。HTTP的默認模式是使用持續連接。

2.采用非持續連接的HTTP

每個請求/響應是經過一個單獨的TCP連接發送，這種方式我們稱之為非持續鏈接。
當Web客戶端-服務器交互模式采用非持續連接時，每個TCP連接只傳輸一個請求報文和一個響應報文。每個TCP連接在服務器發送一個對象（可能是客戶端想要查看的圖片，也可能是一個視頻片段等，我們統稱為對象）后關閉。如下圖：
注意：在這里TCP連接三次握手，TCP斷開連接四次揮手不是重點，所以隨便畫的兩個箭頭表示一下連接和斷開，不要被誤導。

如上圖，申請一個資源前會建立連接，然后申請資源，服務器發送資源，然后斷開連接（可能是客戶端完全接收到資源先發出斷開申請，也可能是服務器收到所有ACK后先發出的斷開申請，在這里不是重點）。如果客戶端再申請資源，那么就需要再次申請連接，然后發送資源申請，接受完資源后，客戶端和服務器再斷開連接。
很明顯，Web客戶端和服務器之間采用非持續連接有些缺點：
（1）必須為每一個請求的對象建立和維護一個全新的連接。對于每一個這樣的連接，在客戶端和服務器都要分配TCP的緩沖區和保持TCP變量（在TCP協議中會總結出），給Web服務器帶來很大負擔。
（2）每個對象傳輸前都需要建立連接，這對于效率來說，大打折扣，因為TCP的連接是要經過三次握手的。(非持續連接時，第三次握手時，客戶端就可以在報文段中捎帶請求資源信息)

但是一般情況下，Web客戶端-服務器之間采用的仍然是非持續連接。因為持續連接會使服務器為這次連接一直維護著緩沖區，對于Web服務器來說，需要處理很多的客戶端資源請求，如果都采取持續連接，那么會同時維護著很多個緩沖區，而大部分緩沖區在客戶端提出資源申請時才會用上，對于服務器來說會造成很大的資源浪費。所以一般默認情況下采取的都是非持續鏈接。客戶端有資源申請，就建立連接，發送完接受完資源，就斷開連接，客戶端后面還需要資源，就重新建立連接。

三.HTTP報文格式

HTTP報文格式分為兩種，請求報文和響應報文。

1.請求報文

先看HTTP請求報文的通用格式：

請求報文示例：

請求方法介紹：

2.應答報文

應答報文的通用格式：

應答報文示例：

狀態碼分類：
1開頭（提示信息）——表示請求正在處理
2開頭（成功）——表示請求處理完畢
3開頭（重定向）——要完成請求必須進行更進一步的處理
4開頭（客戶端錯誤）——請求有語法錯誤或請求無法實現
5開頭（服務端錯誤）——服務器處理請求出錯

200：請求成功
204：服務端返回的僅有狀態行和響應頭，不含數據主體
301/302/303：網站地址改變，需要重定向
304：表示文檔被本地緩存了，可以繼續使用
400：客戶端請求的語法服務端不能理解
404：請求的資源沒找到（說明客戶端請求的資源根本不存在）
500：請求的資源找到了，但是服務器內部發生了錯誤
503：服務器當前無法處理客戶端請求，過一會可能回復正常

五.cookie

該部分完全參考于《計算機網絡自頂向下》

HTTP服務器是無狀態的，但是一個Web網站希望去識別一個用戶，就出現了cooki，可以對用戶進行跟蹤。
cooki有四個組件：
（1）在HTTP請求報文中有一個cooki首部行
（2）在HTTP的響應報文中有一個cooki首部行
（3）在用戶端系統中保留有一個cooki文件，由用戶的瀏覽器進行管理
（4）位于Web站點的一個后端數據庫

注意客戶端系統中保留一個cooki文件，由客戶端系統的瀏覽器進行管理，發現客戶主機的cooki文件中一開始有ebay表項，說明該客戶主機之前已經訪問過ebay網站。當第一次訪問amazon.com網站時，服務器為它創建一個Id，并攜帶在HTTP響應報文中，客戶端瀏覽器收到HTTP響應報文后，該瀏覽器會在它管理的cooki文件中添加一個新表項，用以記錄該id的訪問記錄。過了一段時間之后，再次使用該瀏覽器訪問amazon.com網站時，瀏覽器首先在cooki文件下找到了記錄訪問amazon.com的數據表項，將id攜帶在HTTP的請求報文中發送給服務器，服務器后端數據庫查找到這個id的記錄，假如這個id之前收藏了什么想要購買的物品（購物車），那么后端服務器都有記錄，當用戶想要查詢之前的收藏記錄時，服務端自然能把該id對應的收藏的物品信息發送過去。
cooki作用：
可以用于標識一個用戶，在無狀態的HTTP之上建立一個用戶會話層。

六.Web緩存

1.基本概念

（1）Web緩存器也叫做代理服務器。
（2）Web緩存器有自己的磁盤空間，并在存儲空間中保存最近請求過的對象副本。

（3）一旦某個瀏覽器被配置，則該瀏覽器對某對象的請求首先會去Web緩存器中找。經歷以下步驟：
a.瀏覽器和Web緩存器之間創建TCP連接，并且向Web緩存器發送對對象的請求。
b.Web緩存器進行檢查，看看本地是否有該對象的副本，如果有的話，會將緩存器中的副本傳給瀏覽器；如果沒有，緩存器會向初始服務器發送資源請求，初始服務器將資源發給緩存器，緩存器保存副本，并且發送給瀏覽器。（實際并沒有這么簡單，見下面Web緩存器的講解）

2.緩存器的作用

1.Web緩存器可以大大減少對客戶的請求報文的回復時間，特別是當客戶與緩存器之間有高速寬帶的時候。（客戶方面）
2.Web服務器能大大減少一個機構的接入鏈路到該機構的通信量。沒有緩存器的話，都向初始服務器發送請求，初始服務器和機構之間的通信量很大，需要增加寬帶，需要耗費錢財。（機構方面）
3.Web緩存器能大大減少因特網上的Web流量，從而改善因特網的流量。（因特網方面）

3.條件Get

在基本概念中說，如果Web緩存器中有瀏覽器請求的資源的副本，會將副本發送給客戶。如果初始瀏覽器中的原始資源內容已經被修改呢？此時Web緩存器中的副本是個舊的副本，將舊的副本發給客戶顯然是不正確的。所以緩存器需要對初始服務器發送一個請求HTTP，需要初始服務器驗證一下該副本是否被修改，Web緩存器肯定不是將副本發給服務器讓服務器比較，否則的話Web緩存器的設置就顯然不適合了。Web服務器是將副本最后的修改時間發送給初始服務器，與初始服務器中的資源的修改時間比較。舉例說明，
第一種情況是瀏覽器向Web緩存器請求資源，Web緩存器中沒有資源；第二種情況是瀏覽器向Web緩存器請求資源，Web緩存器中有資源。
（1）瀏覽器向Web緩存器申請一個資源，Web緩存器中沒有這個資源。
這時Web緩存器會向初始服務器發送一個請求報文（這里直接使用前面的請求報文舉例）

初始服務器給Web緩存器發送一個響應報文：

注意紅線部分，紅線部分是最后修改的時間，Web緩存器收到這個資源，會將資源副本保存，資源發送給瀏覽器。這個資源最后的修改時間會被Web緩存器記錄下來。
（2）瀏覽器向Web緩存器請求資源，Web緩存器中有資源。
Web緩存器中有資源，但是Web緩存器并沒有直接將副本發送給瀏覽器，而是Web緩存器向初始服務器發送一個條件GET報文，驗證一下該副本有沒有被修改。
Web緩存器給初始服務器發送的報文：

第三行就是在向服務器驗證該資源有沒有被修改。初始服務器會將Web緩存器傳過來的最后修改時間與初始服務器中的原資源的最后修改時間對比，如果修改了，服務器會直接將資源發給Web緩存器，如果沒有修改，初始服務器會發送一個空實體的報文給Web緩存器。Web緩存器就會知道沒有被修改，就會被磁盤中的副本發送給申請資源的瀏覽器。

4.Web緩存器效率分析

當瀏覽器申請的資源不在Web緩存器中時，該瀏覽器得到資源的速度并不會說比從瀏覽器直接向初始服務器請求資源要快。
但是資源如果在Web緩存器中的話，Web緩存器向初始服務器驗證，如果沒有修改，那么初始服務器發送一個空實體的報文就可以了，然后Web緩存器將資源發送給瀏覽器。將各種情況列舉比較：
（1）客戶端直接向初始服務器尋求資源和客戶端從Web緩存器尋求資源（而Web緩存器沒有該資源）比較

注意到，此時對于客戶端來說，這兩種情況沒什么區別。
（2）客戶端直接向初始服務器尋求資源和客戶端從Web緩存器尋求資源（而Web緩存器有該資源，但是初始服務器中原資源被修改了）比較

注意到，此時和第一種情形沒什么區別，所以對于客戶端的體驗來說，向Web緩存器請求資源和直接向初始服務器發送資源請求之間并不會更快。
（3）客戶端直接向初始服務器尋求資源和客戶端從Web緩存器尋求資源（而Web緩存器有該資源，并且初始服務器中原資源沒有被修改）比較

注意到，這個時候就開始體現出來區別了，客戶收到資源的時間會比直接向初始服務器申請資源要快。（因為初始服務器給Web緩存器發送的應答報文并不攜帶資源）

但是注意：對于第一種情況和第二種情況，客戶端向Web緩存器申請資源和直接向初始服務器申請資源，之間真的沒什么差別嗎？并非如此。有以下原因：
（1）很多時候，相當部分的客戶會直接是第三種情況，這使得英特網的Web流量大大減少，——>英特網的擁塞降低，傳輸效率會提高
（2）第三種情況會使得初始服務器的吞吐量大大減少——>初始服務器的報文處理效率會提升
真正的效率分析比這個要嚴謹的多，要考慮各種時延用數據分析。但是我們粗略分析就可以明白，Web緩存器的設置確實很大程度上提升了客戶獲取資源的效率。

總結

以上是生活随笔為你收集整理的计算机网络——HTTP协议和Web的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。