搞定 HTTP 協議（一）：HTTP 與網絡基礎

不管是前端工程師、後端工程師、客戶端工程師仍是測試工程師，HTTP 協議都是咱們天天須要打交道的東西。可是對於大多數人來講，也包括我本身，對於 HTTP 協議的學習都是碎片化且不成體系的。然而 HTTP 協議又如此重要，性能優化中一個很是重要的部分就是網絡優化，全面理解 HTTP 協議就可讓咱們的頁面更快，體驗更好。

同時，網絡也是每個程序員都應該掌握的底層知識，它與數據結構與算法、操做系統、編譯原理等被稱爲程序員的內功，掌握了內功，咱們才能在職場上走的更遠。HTTP 協議屬於網絡協議中重要的一環，所以須要咱們全面而深刻的掌握它。

其實系統學習 HTTP 協議的材料很是少，像 《HTTP 權威指南》這樣的大部頭年代也很是久遠，因此我最近的學習套路，是在閱讀 HTTP/1.1 版本 RFC7230 文檔的同時，在極客時間上閱讀網絡相關的幾個專欄。

而在最近的深刻學習中我也發現， HTTP 協議的概念衆多，經常看了後面忘了前面。就像學習金字塔理論所指出的，經過聽講和閱讀能記憶的知識實際上是不多的，並且俗話說的好 —— 「不動筆墨不讀書」，我也但願經過一個系列的寫做，更快更好地掌握 HTTP 協議。

本文是系列文章的第一篇 —— 《HTTP 與網絡基礎》。

起源

1989 年，歐洲核子研究組織（CERN）的蒂姆·博納斯-李（Tim Berners-Lee）博士提出一個構想：藉助多文檔之間相互關聯造成的超文本（HyperText），連成可參閱的 WWW（World Wide Web，萬維網），以幫助遠隔兩地的研究者們共享知識。

在這個構想中，他提出了 3 項 WWW 構建的關鍵技術：

• HTML
• URI
• HTTP

1990 年 11 月，CERN 研發出世界上第一臺 Web 服務器和 Web 瀏覽器，遠隔兩地的人們終於能夠在網絡上共享信息了，但受限於當時網絡的速度與技術的限制，網絡上的絕大多數資源都是純文本，因此誕生之初的 HTTP 僅提供 GET 方法，從服務器上獲取 HTML 文檔，設計至關簡陋。此時的 HTTP 協議版本，後來被稱爲 HTTP/0.9 ，但它並無做爲正式的標準被創建，HTTP/0.9 也含有 HTTP/1.0 以前版本的意思。

1993 年 1 月，NCSA（National Center for Supercomputer Applications，美國國家超級計算機應用中心）研發出 Mosaic 瀏覽器，它之內聯等形式顯示 HTML 圖像，人們終於能夠看到圖文混排的 HTML 文檔了。

1995年，網景公司發佈了 Netscape Navigator 1.0，微軟發佈了 IE 1.0 和 2.0，隨後服務器軟件 Apache 以及 HTML 2.0 版本的出現，讓 Web 技術日新月異的增加。HTTP 也在 Web 技術飛速的發展中，不斷地迭代。1996 年 HTTP/1.0 版本正式發佈，記載於 RFC1945。雖然說是早期版本，可是與如今最經常使用的 HTTP/1.1 版本差距並非很大，因此該版本仍然在一些公司使用。

1995 年後，網景和微軟的瀏覽器大戰愈演愈烈，兩家公司對當時發展中的 Web 標準視而不見，致使寫 HTML 頁面時，必須考慮兼容性問題，讓不少人頭痛不已。但不能否認的是，瀏覽器大戰也推進了 Web 的發展。1999 年，HTTP/1.1 發佈 RFC2612，雖然相對於 HTTP/1.0 來講改變不大，但卻在往後的 20 多年裏所向披靡，時至今日，HTTP/1.1 依然是絕大多數公司仍在使用的 HTTP 版本。

HTTP 是什麼？

說了這麼多 HTTP 的發展歷史，那麼 HTTP 究竟是什麼？

在 HTTP/1.1 最新標準 RFC7230 中，是這麼定義 HTTP 的：

The Hypertext Transfer Protocol (HTTP) is a stateless application-level request/response protocol that uses extensible semantics and self-descriptive message payloads for flexible integration with network-based hypertext information systems.

HTTP 協議是一種無狀態的、處於應用層的、以請求/應答方式運行的協議，使用可擴展的語義和自描述的信息格式，與基於網絡的超文本信息系統靈活的相互做用。

在上面的定義中，有幾個關鍵詞是須要咱們特別留意的，理解了這幾個關鍵詞，就能夠掌握 HTTP 協議的本質。

• 無狀態

無狀態是指每個請求/響應是被隔離的，後一個請求沒法依賴前一個請求中的信息、字段等。也就是說 HTTP 協議不會對請求和響應之間的通訊狀態進行保存，不作持久化處理。好比，當用戶 A 登陸後，發起一個查詢本身購物車中商品的請求，服務器會給出相應的響應。然而當用戶 A 再次發起一個請求，想要查詢本身信息的時候，服務器沒法依據上一次請求判斷用戶 A 的身份，必須將用戶身份再次告知服務器才能夠。

• 應用層

應用層面向具體的應用提供數據。應用層的協議不少，好比 DNS 專門處理域名及 IP 的相互轉換；FTP 專門傳輸文件；SMTP 專門發送郵件等等。而 HTTP 也是衆多應用層協議中的一種，可是它卻幾乎能夠傳遞一切東西，因此歷經 20 餘年的發展，依舊經久不衰，覆蓋面及廣

• 請求/應答

HTTP 的工做方式是由請求方首先創建鏈接發起請求，應答方接收到請求後才能作出響應，必須遵循」發起 - 接收「的工做模式。

• 可擴展語義

高度可擴展的語義，也是 HTTP 協議經久不衰的一個重要緣由。從最先的只支持 GET 請求的 HTTP/0.9 版本到如今最經常使用的 HTTP/1.1，HTTP 協議逐漸增長了不少請求方法、版本號、狀態碼等等。並且只要服務端和客戶端就 HTTP headers 達成語義一致，新功能就能夠被輕鬆加入進來。

• 自描述消息格式

咱們能夠本身描述消息，從本身描述的消息中咱們能夠知道傳遞的是文本、圖片、音頻仍是視頻。

• 超文本

所謂超文本，就是 HTTP 協議不只能夠傳輸文本，還能夠傳輸圖片、音頻、視頻以及超連接等複雜的數據。

網絡分層究竟是什麼？

OSI 概念模型

OSI（Open System Interconnection Reference Model），開放式系統互聯通訊參考模型，也就是咱們常說的 7 層模型。從它的名稱就能夠看出來，OSI 只是一個供參考的概念模型，它從未被真正的實現。

OSI 的 7 層，從上至下分別是：

• L7 應用層：解決業務問題，面向具體的應用傳輸數據；

• L6 表示層：將消息轉換爲應用層能夠讀取的消息；

• L5 會話層：創建會話、握手、維持網絡的鏈接狀態；

• L4 傳輸層：包括咱們熟悉的 TCP 與 UDP 等，解決進程與進程之間的通信；

• L3 網絡層：主要包括 IP 協議，負責將報文從因特網上的一個主機發送到另外一個主機上；

• L2 數據鏈路層：工做在局域網中，使用 MAC 地址標記網絡上的設備，如路由器，而後將報文轉到主機上；

• L1 物理層：電纜、光纖等。

TCP/IP 模型

OSI 只是一個概念模型，而日常工做咱們最經常使用的仍是 TCP/IP 模型。TCP/IP 模型其實就是 OSI 模型的簡化版本，也就是咱們平時所說的 4 層模型。

TCP/IP 的 4 層，由上至下分別是：

經過上圖咱們能夠看出，其實 TCP/IP 模型與 OSI 模型十分類似，主要是省略了表示層、會話層與物理層的實現。這裏每一層的功能實際上與對應的 OSI 模型十分相似，因此就再也不羅列了。下面是一張 OSI 模型與 TCP/IP 模型的層級對照圖，你們能夠經過對照圖來總結 TCP/IP 模型中各層的職責。

網絡分層的好處是，每一次層都只負責本身的任務，其餘層的事情徹底不須要考慮，層次之間交互的時候，只須要調用接口就能夠了。當某一層須要修改的時候，也徹底不影響其餘的功能。固然，有優點就必定有劣勢，每一次進行網絡通訊的時候，都須要由上至下，一層一層的傳遞信息，反過來，又要一層一層的向上傳遞，對於性能的影響是比較大的。

與 HTTP 相關的協議

DNS

DNS（Domain Name System）協議與 HTTP 協議同樣，位於應用層，提供域名到 IP 地址之間的解析服務。主機與主機間的通訊是經過 IP 完成的。可是 IP 地址是一串數字，好比 192.168.1.100，人們很難去記憶，因此就有了域名。相比於 IP 地址來講，域名是有意義的單詞，更容易被人們記住，可是計算機卻沒法理解，而 DNS 就能夠提供將咱們在瀏覽器的地址欄輸入的域名解析爲對應 IP 地址的服務（逆向反查也能夠）。

以 www.baidu.com 爲例，從左到右層級逐漸升高，最右側的 com 稱爲頂級 DNS 服務器，中間的 baidu.com 稱爲權威域名服務器，最左側的 www 就是對應的主機。由於全世界互聯網上的電腦實在太多了，因此 DNS 服務器必需要進行分佈式管理，而且要承受高併發。所以，DNS 服務器被設計成了一種樹狀的層次結構，解析域名時逐層遞歸查詢，而最頂端是 13 組根 DNS 服務器。

除此以外，還須要衆多的緩存來處理域名與 IP 地址間的映射關係，以提升訪問速度。如瀏覽器緩存、本地 hosts 緩存、系統緩存。

當咱們在瀏覽器的地址欄中輸入一個域名時，一般查找域名與 IP 地址的映射關係的順序是：

1. 瀏覽器緩存

2. 本地 hosts

3. 系統緩存

4. 根 DNS 服務器（看到是 com 結尾的，就告訴 com 頂級 DNS 服務的 IP 地址）

5. 頂級 DNS 服務器（看到是 baidu.com，告訴 baidu.com 的權威 DNS 服務器的 IP 地址）

6. 權威 DNS 服務器（查找對應主機，告訴 www.baidu.com 的真正 IP 地址）

TCP

TCP 協議位於傳輸層，提供可靠的字節流服務，保證了數據的完整性以及不丟失。

爲了確保數據完整的到達目標處，TCP 協議採用了三次握手的策略：

發送端首先發送一個帶 SYN 標誌的數據包給接收端；

接收端收到後，回傳一個帶有 SYN/ACK 標誌的數據包，表示確認；

發送端再次回傳一個帶有 ACK 標誌的數據包，表示「握手」結束。

若是傳輸過程出現異常，TCP 協議會啓動重發機制。

IP

IP 協議位於網絡層，主要完成尋址和路由選擇（routing）的任務。IP 協議利用 IP 地址來定位互聯網上的計算機，再利用 ARP 協議獲取中轉設備的 MAC 地址，完成路由選擇的任務，直到找到目標 IP 地址。

HTTP 究竟是如何訪問 Web 的？

咱們以訪問 xxx 爲例，當咱們想去一個陌生的地方時，咱們可能只知道它的名字，好比 yy 大廈，可是咱們並不知道該如何到達，這時候咱們就須要導航的協助，幫助咱們找到 yy 大廈的具體地址，咱們就能夠順利前往了。當咱們在瀏覽器訪問一個網站時，狀況也相似。咱們在瀏覽器地址欄輸入 www.xxx.com 後，瀏覽器只知道名字是 www.xxx.com，並不知道如何訪問。因而，瀏覽器但願 DNS 能幫助他找到名字爲 www.xxx.com 的具體地址，也就是 IP 地址。DNS 通過一番查詢後，告訴瀏覽器你要去的地方的具體地址是 192.168.0.100，因而瀏覽器打包請求，使用 HTTP 協議，寫明請求信息。

以上的 HTTP、DNS 都屬於應用層協議，數據通過封裝後，瀏覽器將應用層的包交給下一層傳輸層處理。

傳輸層一般包含兩種經常使用的協議，面向鏈接的TCP 協議和無鏈接的 UDP 協議。這裏以最經常使用的 TCP 協議爲例。TCP 協議一般處理進程與進程間的通訊，因此 TCP 一般帶有兩個端口，一個是瀏覽器的端口號，另外一個是目標服務器的端口號。這樣，操做系統就能夠給指定的端口發送包了。

接着，包會被交給網絡層，IP 協議就在這一層中。網絡層一般處理主機與主機間的通訊，因此 IP 協議包含瀏覽器所在主機的 IP 地址以及目標服務器所在主機的 IP 地址。隨後操做系統將 IP 包發給鏈路層（MAC 層）。

在鏈路層會添加上 MAC 頭部，而後包就能夠漂洋過海了。

當服務端的鏈路層拿到數據後，會逐層向上發送，每到一層拿掉相應的頭部，直到傳輸到應用層，纔算真正接收到了瀏覽器發送過來的 HTTP 請求。

小結

本文是《搞定 HTTP 協議》的第一篇，主要介紹了 HTTP 協議的相關歷史、概念、與 HTTP 相關的協議、網絡分層模型等，以幫助你們對 HTTP 造成一個整體上的直觀概念。下一篇，我會介紹 HTTP 協議的整體結構，敬請期待。

最後，文章會首先發布在個人 Github ，以及公衆號上，歡迎關注。

參考資料

[1] RFC7230

[2] 《圖解 HTTP》

[3] 極客時間 - 《透視 HTTP 協議》

[4] 極客時間 - 《趣談網絡協議》

[5] 極客時間 - 《Web 協議詳解與抓包實戰》