計算機網路——HTTP協議

一、HTTP協議簡介

超文本傳輸協議（英文：HyperText Transfer Protocol，縮寫：HTTP）是一種用于分布式、協作式和超媒體資訊系統的應用層協議，HTTP是萬維網的資料通信的基礎，
HTTP由兩個程式實作：一個客戶程式和一個服務程式，分別運行在不同的端系統中，通過交換HTTP報文進行會，HTTP定義了這些報文的結構以及客戶和服務器進行報文交換的方式，（在解釋HTTP前應回顧一下web的術語）
web頁面是由一個個物件構成的，一個物件只是一個檔案，諸如一個HTML檔案、一個JPEC圖形或者java小程式等等，多數Web頁面有一個HTML基本檔案和多個物件，例，一個Web頁面包含HTML文本和5個JPEC圖形，那么這個頁面由6個物件構成，在進行客戶與服務器之間的報文交換時，客戶需要請求的就是這些物件的報文形式，例如，URL地址 http://www,someSchool. edu/someDepartment/picture.gif，其中的 www.someSchool. edu就是主機名，/someDepartment/ picture. gif 就是路徑名，因為Web瀏覽器（Web browser)實作了HTTP的客戶端，所以在Web環境中我們經常交替使用“瀏覽器”-和“客戶”這兩個術語，Web服務器實作了HTTP 的服務器端，它用于存盤Web物件，每個物件由URL尋址，

二、HTTP協議特點

1.支持客戶/服務器模式，
2.簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑，請求方法常用的有GET、HEAD、POST，每種方法規定了客戶與服務器聯系的型別不同，由于HTTP協議簡單，使得HTTP服務器的程式規模小，因而通信速度很快，
3.靈活：HTTP允許傳輸任意型別的資料物件，正在傳輸的型別由Content-Type加以標記，
4.無連接：無連接的含義是限制每次連接只處理一個請求，服務器處理完客戶的請求，并收到客戶的應答后，即斷開連接，采用這種方式可以節省傳輸時間，
5.無狀態：HTTP協議是無狀態協議，無狀態是指協議對于事務處理沒有記憶能力（不存盤任何關于客戶的狀態資訊），缺少狀態意味著如果后續處理需要前面的資訊，則它必須重傳，這樣可能導致每次連接傳送的資料量增大（cookie的產生解決了這一問題），另一方面，在服務器不需要先前資訊時它的應答就較快，

三、URL

HTTP URL (URL是一種特殊型別的URI，包含了用于查找某個資源的足夠的資訊)的格式為： http://host{":"port}{path}
http表示要通過HTTP協議來定位網路資源；host表示合法的Internet主機域名或者IP地址；port指定一個埠號，為空則使用預設埠80；path指定請求資源的URI；如果URL中沒有給出path，那么當它作為請求URI時，必須以“/”的形式給出，通常這個作業瀏覽器自動幫我們完成，
ps.URI表示的是一個抽象的地址，URL表示的是一個詳細的地址，詳細見：https://blog.csdn.net/qq_32595453/article/details/80563142（URL和URI的比較與理解）

四、HTTP作業原理

首先我們先來確定一組概念，非持續連接和持續鏈接：
在許多因特網應用程式中，客戶和服務器在一個相當長的時間范圍內通信，其中客戶發出一系列請求并且服務器對每個請求進行回應，這一系列請求可以以規則的間隔周期性地或者間斷性地一個接一個發出，當這種客戶-服務器的互動是經TCP進行的，應用程式的研制者就需要做一個重要決定，即每個請求/回應對是經一個單獨的TCP連接發送，還是所有的請求及其回應經相同的TCP連接發送呢?采用前一種方法，該應用程式被稱為使用非持續連接;采用后一種方法，該應用程式被稱為使用持續連接，HTTP既能夠使用非持續連接，也能夠使用持續連接，盡管HTTP1.1在其默認方式下使用持續連接（HTTP1.0是非持續連接），HTTP客戶和服務器也能配置成使用非持續連接，
以下是 HTTP 請求/回應的步驟：
1.客戶端連接到Web服務器
一個HTTP客戶端，通常是瀏覽器，與Web服務器的HTTP埠（默認為80）建立一個TCP套接字連接，例如，http://www.baidu.com，
2.發送HTTP請求
通過TCP套接字，客戶端向Web服務器發送一個文本的請求報文，一個請求報文（HTTP報文，由請求行、請求頭部、空行和請求資料4部分組成），
3.服務器接受請求并回傳HTTP回應
Web服務器決議請求，定位請求資源，服務器將資源復本寫到TCP套接字，由客戶端讀取，一個回應由狀態行、回應頭部、空行和回應資料4部分組成，
4.釋放連接TCP連接
若connection 模式為close，則服務器主動關閉TCP連接，客戶端被動關閉連接，釋放TCP連接(非持續連接);若connection 模式為keepalive，則該連接會保持一段時間，在該時間內可以繼續接收請求（持續連接）;
5.客戶端瀏覽器決議HTML內容
客戶端瀏覽器首先決議狀態行，查看表明請求是否成功的狀態代碼，然后決議每一個回應頭，回應頭告知以下為若干位元組的HTML檔案和檔案的字符集，客戶端瀏覽器讀取回應資料HTML，根據HTML的語法對其進行格式化，并在瀏覽器視窗中顯示，
ps.在非持續連接中，每個TCP只傳送一個請求報文和回應報文，在上例中，6個物件需要建立6個TCP連接，我們并未指明多個連接是串行還是并行，然而默認情況下，大部分瀏覽器會打開5~10個并行的TCP連接，

五、HTTP報文交換時間花銷

首先我們來看兩個概念;
RTT(Round Trip Time)
從客戶端發送一個很小的資料包到服務器并回傳所經歷的時間
回應時間(Response time)
1.發起、建立TCP連接:1個RTT
2.發送HTTP請求訊息到HTTP回應訊息的前幾個位元組到達:1個RTT
回應訊息中所含的檔案/物件傳輸時間

由上圖我們可以看到接受一個物件需要約為2RTT的時間，
非持續連接有一些缺點，第一，必須為每一個請求的物件建立和維護一個全新的連接，對于每個這樣的連接，在客戶和服務器中都要分配TCP 的緩沖區和保持TCP變數,這給Web服務器帶來了嚴重的負擔，因為一臺Web服務器可能同時服務于數以百計不同的客戶的請求，第二，就像我們剛描述的那樣，每一個物件經受兩倍RTT的交付時延，即一個RTT用于創建TCP，另一個RTT用于請求和接收一個物件，若物件數量龐大那么傳輸效率就會很低，有沒有什么方法可以改進呢？
接下來我們從持續連接的角度去思考問題，首先介紹無流水/流水的持久連接：
無流水(pipelining)的持久性連接
1.客戶端只有收到前一個回應后才發送新的請求
2.每個被參考的物件耗時1個RTT帶有流水機制的持久性連接.HTTP1.1的默認選項
3.客戶端只要遇到一個參考物件就盡快發出請求
4.理想情況下，收到所有的參考物件只需耗時約1個RTT
帶有流水機制的持久性連接（HTTP1.1的默認選項）
1.客戶端只要遇到一個參考物件就盡快發出請求
2.理想情況下，收到所有的參考物件只需耗時約1個RTT

接下來引入一個計算實體：
假設你在瀏覽某網頁時點擊了一個超鏈接，URL為“https://www.kicker.com.cn/index.html”，且該URL對應的IP地址在你的計算機上沒有快取；檔案index.html參考了8個小影像，域名決議程序中，無等待的一次DNS決議請求與回應時間記為RTTd，HTTP請求傳輸Web物件程序的一次往返時間記為RTTh，請回答下列問題：
1）你的瀏覽器決議到URL對應的IP地址的最短時間是多少？最長時間是多少？
2）若瀏覽器沒有配置并行TCP連接，則基于HTTP1.0獲取URL鏈接Web頁完整內容（包括參考的影像，下同）需要多長時間（不包括域名決議時間，下同）？
3) 若瀏覽器配置5個并行TCP連接，則基于HTTP1.0獲取URL鏈接Web頁完整內容需要多長時間？
4) 若瀏覽器沒有配置并行TCP連接，則基于非流水模式的HTTP1.1獲取URL鏈接Web頁完整內容需要多長時間？基于流水模式的HTTP1.1獲取URL鏈接Web頁完整內容需要多長時間？
解答：
1)最短時間：
當本地域名決議服務器中包含要訪問的URL所對應的IP地址時，所需的時間時間最短，為RTTd，
最長時間：
當本地域名決議器中不包含并且需要從根域名服務器決議時所需的時間最長，決議路徑如下：客戶端-本地域名服務器、本地域名服務器-根域名服務器、本地域名服務器-com.cn、cn-com、本地域名服務器-權威域名服務器，因此所需的時間為5RTTd，
2)需要html檔案本身，外加8個小影像連接，時間包括發起建立TCP連接一個RTTh，HTTP請求傳輸Web物件程序的一次往返時間RTTh，一共29 = 18 RTTh
3)一開始建立TCP連接，獲得index.html檔案2個RTTh，然后由影像地址資訊，在2輪并行處理下完成8個影像的加載作業，22個RTTh，2 + 4 = 6 RTTh，
4)無流水情況下，客戶端只有收到前一個回應后才發送新的請求，每個被參考的物件耗時一個RTT，
有流水情況下，客戶端只要遇到一個參考就盡快發出請求，
無流水: 2 + 8 = 10 RTTh，有流水: 2 + 1 = 3 RTTh

六、HTTP報文格式

HTTP報文分為請求報文和回應報文：
請求報文如下：

我們可以看到該報文是由ASCII碼文本書寫的，可以進行閱讀，
1.請求行（第一行）由方法欄位、URL欄位和HTTP協議版本欄位，
方法欄位可以取不同的值，包括POST、GET、HEAD、PUT、DELETE等，
2.請求頭部：位于請求行的下面
請求報文中常見的標頭有：
Connetion標頭（連接管理）、Host標頭（指定請求資源的主機）、Range標頭（請求物體的位元組范圍）、User-Agent標頭（包含發出請求的用戶資訊）、Accept標頭（首選的媒體型別）、Accept-Language(首選的自然語言)
3.物體體
若采用方法GET則物體體為空，采用POST物體體包含的就是用戶在表單欄位中輸入的值，
接下來我們可以對照著以上例子觀察HTTP請求報文的通用格式：

回應報文如下：

HTTP回應報文同樣也分為三部分，有狀態行、首部行、物體
狀態行（HTTP回應報文的第一行）包括三個欄位：協議版本、狀態碼與原因短語，
1.狀態碼：
1xx：這一型別的狀態碼，代表請求已被接受，需要繼續處理，這類回應是臨時回應，只包含狀態行和某些可選的回應頭資訊，并以空行結束，
2xx:這一型別的狀態碼，代表請求已成功被服務器接收、理解、并接受，
3xx:這類狀態碼代表需要客戶端采取進一步的操作才能完成請求，通常，這些狀態碼用來重定向，后續的請求地址（重定向目標）在本次回應的Location域中指明，
4xx:這類的狀態碼代表客戶端類的錯誤
5xx:服務器類的錯誤、常遇到的狀態碼說明
2.回應首部（首部行）：位于回應報文狀態行之后
Date標頭：訊息產生的時間
Age標頭:（從最初創建開始）回應持續時間
Server標頭: 向客戶端標明服務器程式名稱和版本
ETage標頭：不透明驗證者
Location標頭：URL備用的位置
Content-Length標頭：物體的長度
Content-Tyep標頭：物體的媒體型別
3.物體體：報文的主要部分，包含了所請求的物件本身，
接下來我們看一看回應報文的通用格式：