一、《圖解HTTP》- WEB和網路基礎

tjhttp 一、《圖解HTTP》- WEB和網路基礎

知識點

1. 概覽HTTP誕生歷史。文中提供一箇中文翻譯網站可以對照閱讀。
2. 擴充套件：HTTP3.0 都已經出來了，為什麼2.0 推進還是隻有一半？題外話討論
3. TCP/IP 協議概覽，瞭解基本定義。
4. 區分URL和URI。

1.1 本章重點

開頭部分是關於WEB和網路歷史介紹，所以沒有多少需要理解和記憶的內容。網路基礎 TCP/IP的部分是整個網際網路的核心，建議多看幾遍理解和消化。

WEB的傳輸依賴HTTP（HyperText Transfer Protocol，超文字傳輸協議 1 ）的協議作為規範，HTTP的工作是完成從客戶端到伺服器端等一系列運作流程，為了保證兩臺不同的裝置能正常溝通，兩者需要遵守相同的規則。

目前HTTP已經發展到3.0了，但是這本書寫下來的時候2.0還在起草，所以可以認為是一本比較“老”的書，很多地方需要查閱當前的資料進行糾正。

1.2 HTTP誕生

1989 年 3 月HTTP在少數幾個人手中誕生。CERN（歐洲核子研究組織）的蒂姆 • 伯納斯 - 李（Tim BernersLee）提出網路通訊的設想。

1990 年 11 月，CERN 成功研發了世界上第一臺 Web 伺服器和 Web 瀏 覽器。

1990 年，大家針對 HTML 1.0 草案進行了討論，因 HTML 1.0 中存在 多處模糊不清的部分，草案被直接廢棄了。

1993 年 1 月，現代瀏覽器的祖先 NCSA（National Center for Supercomputer Applications，美國國家超級計算機應用中心）研發的 Mosaic 問世了。同年秋天釋出Windows 版和 Macintosh 版面世。

1994 年 的 12 月，時代的眼淚網景通訊公司釋出了 Netscape Navigator 1.0，1995 年微軟公司釋出臭名昭著的 Internet Explorer 1.0 和 2.0，隨後IE折磨開發人員數十年的歷史開始。

這裡有一個網際網路比較知名的歷史，那就是關於微軟和網景之間的瀏覽器爭奪，感興趣的同學可以查查這一段歷史，微軟最終憑藉Windows平臺的客戶粘性繫結以及免費贏得勝利，網景雖然贏了官司但是瀏覽器市場被Windows壟斷逐漸沒落，畢竟explore不收費誰奈何的了。

現在的FireFox瀏覽器前身就是網景，不過瀏覽器核心卻是谷歌一家獨大，Edge在chrome核心以及自身最佳化的加持下也可圈可點，但是微軟利用平臺強制繫結客戶的行為依舊可見一二，這都是現代的使用者可以感知的。

另外值得一提的是3W的構建包含三種技術：

• SGML（Standard Generalized Markup Language，標準通用標記語言），是最早的超文字格式的最高層次標準。可以定義標記語言的元語言，甚至可以定義不必採用< >的常規方式，因為太複雜因而難以普及。後續的HTTP和XML都可以看作這個協議的擴充套件和拆分和簡化。
• HTML（HyperText Markup Language，超文字標記語言）。
• URL（Uniform12 Resource Locator，統一資源定位符）。

1.3 HTTP歷史簡述

HTTP發展到現在也基本所有網站都是HTTP1.1版本作為標準，自 1999 年釋出的 RFC2616 之後釋出過一個版本RFC723。

這部分內容在第二章中會再次重點擴充套件和討論

**RFC7231 協議線上閱讀：

https://tools.ietf.org/html/rfc7231

歷史發展

感興趣可以點選協議號檢視原文。

• HTTP/0.9：HTTP 於 1990 年問世，這個版本可以看作是1.0之前的雛形，因為沒有作為標準正式版建立，所以被叫做為0.9。
• HTTP/1.0：HTTP 正式作為標準被公佈是在 1996 年的 5 月，標準號為RFC1945（點選連結檢視白皮書）。
• HTTP/1.1：1997 年 1 月公佈，直到現在依然還有大量的網站在使用，最初標準為RFC2068，之後釋出的修訂版 RFC2616 ，目前最新版本為rfc7231。

• HTTP/2.0：HTTP/2是HTTP協議自1999年HTTP 1.1的改進版RFC2616，釋出後的首個更新，主要基於SPDY協議。（RFC 7231 時後面修訂的）

  它由網際網路工程任務組（IETF）的Hypertext Transfer Protocol Bis（httpbis）工作小組進行開發。該組織於2014年12月將HTTP/2標準提議遞交至IESG（英語：Internet_Engineering_Steering_Group）進行討論，於2015年2月17日被批准。

  HTTP2.0的標準號：RFC 7540

中英文對照閱讀

最後在網上找到一個關於HTTP協議的翻譯網站，專案作者貌似棄坑很多年沒有更新，但是對於英語基礎較薄弱的同學可以作為參考：

rfc7540-translation-zh_cn

1.3.1 HTTP/2.0 的特點

HTTP/2.0 的目標是改善使用者在使用 Web 時的速度體驗。

為了支撐這一實現，官方提出了三種技術：

• SPDY（SPDY HTTP Speed）：谷歌提出用於提高HTTP訪問效率以及解決HTTP1.X中管道化的缺陷，意圖是縮短整個請求時間。
• Mobility Network-Friendly：由微軟公司起草，是用於改善並提高移動端通訊時的通訊速度和效能的標準。見名知意它是被用來實現手機高速上網的一個協議。
• HTTP Upgrade （Network-Friendly HTTP Upgrade）：同樣是對於移動端的一些改進意見。

1.3.2 HTTP2.0題外話

這本書寫於13，14年左右，HTTP2.0到現在都推廣快接近十年了，但是推廣速度個人認為一般。

作為讀者肯定好奇現在到底普及多少了，這裡找到一個可供參考的網站。

從紙面資料來看截止，到目前國外的統計目前使用HTTP/2的還不到一半，也就意味著還有一大半的伺服器還在使用HTTP1.1。

這就引申了下一個話題，3.0都快要出來了為什麼2.0還沒全面普及？

這就要了解為什麼2.0的普及這麼難。

首先是HTTP1.0中請求非常純粹，一個請求就是一次HTTP連線，請求完成就斷開。

於是 HTTP1.X 升級了一下，可以透過Keep-alive最佳化TCP的建立和斷開，一次連線也可以對應多個請求。

然而谷歌是不會滿足這樣的效率的，谷歌推動了HTTP2.0的升級，針對HTTP1.X的請求響應必須要排隊的問題處理，使用多路複用完成整個請求。

這樣當然對於效果顯著提升，為什麼大家都不用呢？

為什麼協議在進步，看起來效率在顯著提升，為什麼HTTP的升級難以推進？

表層來看

真實的專案基本需要依賴框架完成，有一些舊系統舊版本的框架不是想升級就升級的，或者說壓根懶得升級，因為沒有顯著的帶來效益的好處。甚至有可能搞出問題得不償失。

更深層次的原因

HTTP2.0 自帶HTTPS，這樣實際上就導致一個衝突問題，實際的專案大多需要使用Nginx反向代理。

但是Ngnix也可以開啟Http2.0的支援呀，為什麼依然堅持要用Nginx 做反向代理而不是直接使用HTTP2.0呢？

這樣的原因可能來自TCP長連結，在Nginx部署的情況下，實際上請求不需要走一長串的路由而是直接和Nginx互動。

但是HTTP2.0 可以透過多點部署以及多個請求順序並行，透過叢集和負載均衡可以很好的滿足伺服器要求。

在框架當中如果把請求發給本地，侷限單臺機器的核數量，併發效率實際上和HTTP1.X差不多，因為任務多起來依然需要排隊。

如果開啟HTTP2.0並且交給Nginx 拆分模組並且簡化功能，不改變開發模式的情況下又可以利用叢集。

此外，最關鍵的一個原因，HTTP2.0雖然解決了HTTP多路複用併發請求的問題，但是TCP的問題並沒有被解決。

所以大體上是TCP的鍋，其次是Nginx夠強，以及框架升級的高成本問題，最後是期待HTTP3.0一步到胃。

當然不要認為50% 普及率很低，從另一個角度來看訪問量很大日常使用的網站基本都有HTT P2.0的加成。

1.4 TCP/IP

理解HTTP必然需要了解TCP/IP。

HTTP協議是應用層的協議，如果是金字塔結構它處於模型的頂層，但是實際上金字塔的核心是TCP/IP。

HTTP是在此基礎上做支撐的，現代的網路架構是基於TCP/IP模型建立的，HTTP也只是其中的一部分。

TCP/IP 是網際網路相關的各類協議族的總稱，這是一種說法，表示單單是字面意思的TCP協議和IP協議。但是另一種說法是隻是代表了TCP 和 IP 這兩種協議。

TCP/IP 協議族按層次分別分 為以下5 層：應用層、傳輸層、網路層和資料鏈路層，以及和硬體密切相關的物理層。

對於TCP/IP感興趣，可以閱讀《圖解TCP/IP》和《TCP/IP 詳解》

層次化的設計意味著便於修改，也就是常說的高內聚低耦合在TCP/IP協議得到充分體現。

但是實際上這種設計不是完全沒有缺點的，那就是每一層雖然可以升級但是無法突破原有的框架，TCP協議本身限制也是導致HTTP協議難以推動升級的一個重要原因。

那麼《TCP/IP 詳解，卷 1》中開頭介紹了OSI 模型又是啥？

實際上是早期網際網路協議構建者的美好願景，企圖透過這一個模型實現一個極強擴充套件性的網際網路架構，說難聽點就是把標準給完全壟斷掉，讓以後的架構無牌可打你們都得聽我的。

當然理想和美好現實很骨感，由於OSI模型結構的層級過多並且難以推動和維護，後續被更為精簡好理解的TCP/IP 快速取代。

所以OSI模型是歷史鬥爭的產物，但是卻是實際上網路模型協議制定標杆， TCP/IP 模型藉助UNIX最終存活下來。

根據模型介紹各層都做了什麼？

1. 應用層：決定為使用者提供服務的應用程式相關活動。
2. 傳輸層：傳輸層主要是協議之間的資料傳輸，包含各種豐富多樣的協議，包括但是不限於TCP協議，比如TCP（Transmission Control Protocol，傳輸控制協議）和 UDP（User Data Protocol，使用者資料包協議）。
3. 網路層：網路層用來處理在網路上流動的資料包，最終轉化為網路包的最小單位進行傳輸。
4. 資料鏈路層：也可以認為是看的見的硬體部分，比如網路卡，硬體上的範疇均在鏈路層的作用範圍之內。
5. 物理層：也就是網線和集線器等網路傳輸支援裝置，從粗略角度來看可以直接看作網線。

下面是整個網路資料包的封裝過程，如果想要了解整個過程可以檢視 《網路是怎麼樣連線的》這本書的第二章部分。

1.4.1 IP、TCP 和DNS

按照協議層次劃分：IP（Internet Protocol）網際協議位於網路層，TCP位於傳輸層，所以TCP/IP 協議除了代表一個協議族群之外，TCP協議和IP協議本身其實就不在一個層級，所以不能混為一談。

IP協議（Internet Protocol）

IP（Internet Protocol）網際協議位於網路層。

IP協議的主要工作是確保資訊能準確傳輸，為了保證資料能正確的送達，IP協議需要確保MAC地址和IP地址的正確，IP 地址指明瞭節點被分配到的地址，MAC 地址是指網路卡所屬的固定地址。

IP地址由於內外網通訊的緣故有可能會存在地址轉化，地址轉化依賴的是地址轉化裝置，但是MAC地址是從網路卡生產之後就固定了世界上唯一的網路卡MAC地址。

ARP 協議憑藉 MAC 地址進行通訊，接著便是透過類似快遞導航尋找站點的方式進行通訊傳輸，整個核心是透過“查表”方式進行。

ARP 協議（Address Resolution Protocol）：ARP 是一種用以解析地址的協議，根據通訊方的 IP 地址就可以反查出對應的 MAC 地址。

TCP協議

TCP協議位於傳輸層，提供位元組流服務，所謂位元組流服務是指大塊資料拆分為報文段， 而可靠服務指的是把資料傳輸給對方，同時TCP為了保證大段資料的傳輸會進行資料切割。

為了確保資料準確傳輸，整個TCP還需要依賴三次握手，關於三次握手的過程這裡也不做過多討論，可以看《網路是怎麼樣連線的》讀書筆記內容。

DNS 服務

使用者通常使用主機名或域名來訪問對方的計算機，而不是直接透過 IP地址訪問。

DNS是負責域名和IP轉化的服務，在請求目標伺服器之前，通常需要根據DNS服務獲取域名對應的IP地址。

各協議和HTTP關係

注意在書中省略有關MAC頭部的內容。

整個圖畫算是最為入門級的角度，實際上稍微深入就會發現沒有那麼簡單，這幅圖也是畫的過於籠統，簡單看看角色的基本職責即可。

1.4.2 URL和URI

區別和對比

首先得區分概念本身：

URL：表示統一資源定位，也就是我們訪問WEB 伺服器在瀏覽器頂部的那一串字串。

URI： 其實這裡包含三個元件，URI全稱 是 Uniform Resource Identifier，RFC2396在規範的1.1分別對於這三個單詞進行下面的定義，整體來看URI 就是由某個協議方案表示的資源的定位識別符號。

• Uniform：規定統一的格式可方便處理多種不同型別的資源，也就是常說的“習慣優於配置”，具體案例是比如ftp是ftp開頭請求走協議，http開頭請求走http協議。
• Resource：抽象定義資源是“任何可以訪問的東西”，比如文件，圖片，網路檔案等等全都可以看做資源。
• Identifier：表示可以標識的物件，也叫做識別符號。

最快速的區分可以直接認為 URI 是協議和標準，URL是對於URI協議標準的“直接實現”和“表示”。

URI屬於網際網路頂級規範的行列，只有符合URI規範的請求才能被識別，由隸屬於國際網際網路資源管理的非營利社團 ICANN（Internet Corporation forAssigned Names and Numbers，網際網路名稱與數字地址分配機構）的IANA（Internet Assigned Numbers Authority，網際網路號碼分配局）管理頒佈。

最後是有關URL定義的兩個直觀例子：

                    hierarchical part
        ┌───────────────────┴─────────────────────┐
                    authority               path
        ┌───────────────┴───────────────┐┌───┴────┐
  abc://username:password@example.com:123/path/data?key=value&key2=value2#fragid1
  └┬┘   └───────┬───────┘ └────┬────┘ └┬┘           └─────────┬─────────┘ └──┬──┘
scheme  user information     host     port                  query         fragment

  urn:example:mammal:monotreme:echidna
  └┬┘ └──────────────┬───────────────┘
scheme              path

當然官方在白皮書也給了一些案例：

   The following examples illustrate URI that are in common use.

   ftp://ftp.is.co.za/rfc/rfc1808.txt
      -- ftp scheme for File Transfer Protocol services

   gopher://spinaltap.micro.umn.edu/00/Weather/California/Los%20Angeles
      -- gopher scheme for Gopher and Gopher+ Protocol services

   http://www.math.uio.no/faq/compression-faq/part1.html
      -- http scheme for Hypertext Transfer Protocol services

   mailto:mduerst@ifi.unizh.ch
      -- mailto scheme for electronic mail addresses

   news:comp.infosystems.www.servers.unix
      -- news scheme for USENET news groups and articles

   telnet://melvyl.ucop.edu/
      -- telnet scheme for interactive services via the TELNET Protocol

最後我們簡單來對比URL和URI，可以看到URI劃定了URL的“分類”，所以URL可以看做是URI的子集。

URL 格式

這裡主要介紹用的比較少的片段識別符號，片段識別符號表示已獲取資源中的子資源。

注意網際網路中並不是所有的請求都會符合RFC協議的，RFC指的是HTTP協議的意見修正書，這些內容多數情況下應用程式都會遵守，但是凡事總有特例。

如果不參考RFC協議進行通訊那麼就需要自己的協議完成客戶端之間的通訊，比較典型的例子比如RPC協議就是經典的非HTTP協議通訊實現，當然這種方案存在不少的問題和爭議。

1.5 總結

和多數技術書類似，第一章算是概覽的一個章節，大致介紹了HTTP的基礎背景。

當然這本書確實很老，很多協議和標準到現在其實早就不在使用了，但是從另一個角度來看IP、TCP、DNS這些東西基本都是萬年不變的，所以不需要擔心會過時。

關於HTTP2.0的討論是筆記中的擴充套件部分，在這一部分大致討論了一下為什麼HTTP2.0難以推進。

實際上HTTP2.0在各大主流網站都有普及，國內的一些大廠商基本也是第一時間跟進的。