詳解 HTTP 協議（一）

1、計算機網絡體系結構分層

2、TCP/IP 通信傳輸流

利用 TCP/IP 協議族進行網絡通信時，會通過分層順序與對方進行通信。發送端從應用層往下走，接收端則從鏈路層往上走。如下：

（1）首先作為發送端的客戶端在應用層（HTTP 協議）發出一個想看某個 Web 頁面的 HTTP 請求。

（2）接著，為了傳輸方便，在傳輸層（TCP 協議）把從應用層處收到的數據（HTTP 請求報文）進行分割，并在各個報文上打上標記序號及端口號后轉發給網絡層。

（3）在網絡層（IP 協議），增加作為通信目的地的 MAC 地址后轉發給鏈路層。這樣一來，發往網絡的通信請求就準備齊全了。

（4）接收端的服務器在鏈路層接收到數據，按序往上層發送，一直到應用層。當傳輸到應用層，才能算真正接收到由客戶端發送過來的 HTTP請求。

如下圖所示：

在網絡體系結構中，包含了眾多的網絡協議，這篇文章主要圍繞 HTTP 協議（HTTP/1.1版本）展開。

HTTP協議（HyperText Transfer Protocol，超文本傳輸協議）是用于從WWW服務器傳輸超文本到本地瀏覽器的傳輸協議。它可以使瀏覽器更加高效，使網絡傳輸減少。它不僅保證計算機正確快速地傳輸超文本文檔，還確定傳輸文檔中的哪一部分，以及哪部分內容首先顯示(如文本先于圖形)等。

HTTP是客戶端瀏覽器或其他程序與Web服務器之間的應用層通信協議。在Internet上的Web服務器上存放的都是超文本信息，客戶機需要通過HTTP協議傳輸所要訪問的超文本信息。HTTP包含命令和傳輸信息，不僅可用于Web訪問，也可以用于其他因特網/內聯網應用系統之間的通信，從而實現各類應用資源超媒體訪問的集成。

我們在瀏覽器的地址欄里輸入的網站地址叫做URL (Uniform Resource Locator，統一資源定位符)。 就像每家每戶都有一個門牌地址一樣，每個網頁也都有一個Internet地址。當你在瀏覽器的地址框中輸入一個URL或是單擊一個超級鏈接時，URL就確定了要瀏覽的地址。瀏覽器通過超文本傳輸協議(HTTP)，將Web服務器上站點的網頁代碼提取出來，并翻譯成漂亮的網頁。

3、HTTP 工作過程

（1）建立 TCP 連接

在HTTP工作開始之前，客戶端首先要通過網絡與服務器建立連接，該連接是通過 TCP 來完成的，該協議與 IP 協議共同構建 Internet，即著名的 TCP/IP 協議族，

因此 Internet 又被稱作是 TCP/IP 網絡。HTTP 是比 TCP 更高層次的應用層協議，根據規則，只有低層協議建立之后，才能進行高層協議的連接，

因此，首先要建立 TCP 連接，一般 TCP 連接的端口號是80；

（2）客戶端向服務器發送請求命令

一旦建立了TCP連接，客戶端就會向服務器發送請求命令；

例如：GET/sample/hello.jsp HTTP/1.1

（3）客戶端發送請求頭信息

客戶端發送其請求命令之后，還要以頭信息的形式向服務器發送一些別的信息，之后客戶端發送了一空白行來通知服務器，它已經結束了該頭信息的發送；

（4）服務器應答

客戶端向服務器發出請求后，服務器會客戶端返回響應；

例如： HTTP/1.1 200 OK

響應的第一部分是協議的版本號和響應狀態碼

（5）服務器返回響應頭信息

正如客戶端會隨同請求發送關于自身的信息一樣，服務器也會隨同響應向用戶發送關于它自己的數據及被請求的文檔；

（6）服務器向客戶端發送數據

服務器向客戶端發送頭信息后，它會發送一個空白行來表示頭信息的發送到此為結束，接著，它就以 Content-Type 響應頭信息所描述的格式發送用戶所請求的實際數據；

（7）服務器關閉 TCP 連接

一般情況下，一旦服務器向客戶端返回了請求數據，它就要關閉 TCP 連接，然后如果客戶端或者服務器在其頭信息加入了這行代碼 Connection:keep-alive ，

TCP 連接在發送后將仍然保持打開狀態，于是，客戶端可以繼續通過相同的連接發送請求。保持連接節省了為每個請求建立新連接所需的時間，還節約了網絡帶寬。

4、HTTP 協議基礎

（1）通過請求和響應的交換達成通信

應用 HTTP 協議時，必定是一端擔任客戶端角色，另一端擔任服務器端角色。僅從一條通信線路來說，服務器端和客服端的角色是確定的。HTTP 協議規定，請求從客戶端發出，最后服務器端響應該請求并返回。換句話說，肯定是先從客戶端開始建立通信的，服務器端在沒有接收到請求之前不會發送響應。

（2）HTTP 是不保存狀態的協議

HTTP 是一種無狀態協議。協議自身不對請求和響應之間的通信狀態進行保存。也就是說在 HTTP 這個級別，協議對于發送過的請求或響應都不做持久化處理。這是為了更快地處理大量事務，確保協議的可伸縮性，而特意把 HTTP 協議設計成如此簡單的。

可是隨著 Web 的不斷發展，我們的很多業務都需要對通信狀態進行保存。于是我們引入了 Cookie 技術。有了 Cookie 再用 HTTP 協議通信，就可以管理狀態了。

（3）使用 Cookie 的狀態管理

Cookie 技術通過在請求和響應報文中寫入 Cookie 信息來控制客戶端的狀態。Cookie 會根據從服務器端發送的響應報文內的一個叫做 Set-Cookie 的首部字段信息，通知客戶端保存Cookie。當下次客戶端再往該服務器發送請求時，客戶端會自動在請求報文中加入 Cookie 值后發送出去。服務器端發現客戶端發送過來的 Cookie 后，會去檢查究竟是從哪一個客戶端發來的連接請求，然后對 比服務器上的記錄，最后得到之前的狀態信息。

（4）請求 URI 定位資源

HTTP 協議使用 URI 定位互聯網上的資源。正是因為 URI 的特定功能，在互聯網上任意位置的資源都能訪問到。

（5）告知服務器意圖的 HTTP 方法（HTTP/1.1）

（6）持久連接

HTTP 協議的初始版本中，每進行一個 HTTP 通信都要斷開一次 TCP 連接。比如使用瀏覽器瀏覽一個包含多張圖片的 HTML 頁面時，在發送請求訪問 HTML 頁面資源的同時，也會請求該 HTML 頁面里包含的其他資源。因此，每次的請求都會造成無畏的 TCP 連接建立和斷開，增加通信量的開銷。

為了解決上述 TCP 連接的問題，HTTP/1.1 和部分 HTTP/1.0 想出了持久連接的方法。其特點是，只要任意一端沒有明確提出斷開連接，則保持 TCP 連接狀態。旨在建立一次 TCP 連接后進行多次請求和響應的交互。在 HTTP/1.1 中，所有的連接默認都是持久連接。

（7）管線化

持久連接使得多數請求以管線化方式發送成為可能。以前發送請求后需等待并接收到響應，才能發送下一個請求。管線化技術出現后，不用等待亦可發送下一個請求。這樣就能做到同時并行發送多個請求，而不需要一個接一個地等待響應了。

比如，當請求一個包含多張圖片的 HTML 頁面時，與挨個連接相比，用持久連接可以讓請求更快結束。而管線化技術要比持久連接速度更快。請求數越多，時間差就越明顯。

5、HTTP 協議報文結構

（1）HTTP 報文

用于 HTTP 協議交互的信息被稱為 HTTP 報文。請求端（客戶端）的 HTTP 報文叫做請求報文；響應端（服務器端）的叫做響應報文。HTTP 報文本身是由多行（用 CR+LF 作換行符）數據構成的字符串文本。

（2）HTTP 報文結構

HTTP 報文大致可分為報文首部和報文主體兩部分。兩者由最初出現的空行（CR+LF）來劃分。通常，并不一定有報文主體。如下： 請求報文結構

請求報文的首部內容由以下數據組成：

（1）請求行? —— 包含用于請求的方法、請求 URI 和 HTTP 版本。

（2）首部字段 ?—— 包含表示請求的各種條件和屬性的各類首部。（通用首部、請求首部、實體首部以及RFC里未定義的首部如 Cookie 等）

請求報文的示例，如下：

響應報文結構

響應報文的首部內容由以下數據組成：

（1）狀態行 ?—— 包含表明響應結果的狀態碼、原因短語和 HTTP 版本。

（2）首部字段? —— 包含表示請求的各種條件和屬性的各類首部。（通用首部、響應首部、實體首部以及RFC里未定義的首部如 Cookie 等）

響應報文的示例，如下：

6、HTTP 報文首部之請求行、狀態行

（1）請求行

舉個栗子，下面是一個 HTTP 請求的報文：

其中，下面的這行就是請求行，

開頭的 GET 表示請求訪問服務器的類型，稱為方法；

隨后的字符串 /index.htm 指明了請求訪問的資源對象，也叫做請求 URI；

最后的 HTTP/1.1，即 HTTP 的版本號，用來提示客戶端使用的 HTTP 協議功能。

綜合來看，大意是請求訪問某臺 HTTP 服務器上的 /index.htm 頁面資源。

（2）狀態行

同樣舉個栗子，下面是一個 HTTP 響應的報文：

其中，下面的這行就是狀態行，

開頭的?HTTP/1.1?表示服務器對應的 HTTP 版本；

緊挨著的?200 OK?表示請求的處理結果的狀態碼和原因短語。

HTTP TCP/IP

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。