HTTP 概述

HTTP 是什麼？

先看一下 HTTP（Hypertext Transfer Protocol）的名字：「超文本傳輸協議」，它能夠拆成三個部分，分別是：「超文本」「傳輸」和「協議」。咱們從後往前來逐個解析，理解了這三個詞，咱們也就明白了什麼是 HTTP。

首先，HTTP 是一個協議。不過，協議又是什麼呢？

• 協議必需要有兩個或多個參與者，也就是「協」。

• 協議是對參與者的一種行爲約定和規範，也就是「議」。

協議意味着有多個參與者爲了達成某個共同的目的而站在了一塊兒，除了要無疑義地溝通交流以外，還必須明確地規定各方的「責、權、利」，約定該作什麼不應作什麼，先作什麼後作什麼，作錯了怎麼辦，有沒有補救措施等等。

HTTP 是一個用在計算機世界裏的協議。它使用計算機可以理解的語言確立了一種計算機之間交流通訊的規範，以及相關的各類控制和錯誤處理方式。

接下來咱們看 HTTP 字面裏的第二部分：「傳輸」。

HTTP 是一個「傳輸協議」，所謂的「傳輸」（Transfer）其實很好理解，就是把一堆東西從 A 點搬到 B 點，或者從 B 點搬到 A 點，即「A<===>B」。

• 第一點，HTTP 協議是一個「雙向協議」。有兩個最基本的參與者 A 和 B，從 A 開始到 B 結束，數據在 A 和 B 之間雙向而不是單向流動。一般咱們把先發起傳輸動做的 A 叫作請求方，把後接到傳輸的 B 叫作應答方或者響應方。

• 第二點，數據雖然是在 A 和 B 之間傳輸，但並無限制只有 A 和 B 這兩個角色，容許中間有「中轉」或者「接力」。只要不打擾基本的數據傳輸，就能夠添加任意的額外功能，例如安全認證、數據壓縮、編碼轉換等等，優化整個傳輸過程。

HTTP 是一個在計算機世界裏專門用來在兩點之間傳輸數據的約定和規範。

講完了「協議」和「傳輸」，如今，咱們終於到 HTTP 字面裏的第三部分：「超文本」。

在互聯網早期，「文本」只是簡單的字符文字，但發展到如今，「文本」的涵義已經被大大地擴展了，圖片、音頻、視頻、甚至是壓縮包，在 HTTP 眼裏均可以算作是「文本」。

所謂「超文本」，就是「超越了普通文本的文本」，它是文字、圖片、音頻和視頻等的混合體，最關鍵的是含有「超連接」，可以從一個「超文本」跳躍到另外一個「超文本」，造成複雜的非線性、網狀的結構關係。

對於「超文本」，咱們最熟悉的就應該是 HTML 了，它自己只是純文字文件，但內部用不少標籤訂義了對圖片、音頻、視頻等的連接，再通過瀏覽器的解釋，呈如今咱們面前的就是一個含有多種視聽信息的頁面。

OK，通過了對 HTTP 裏這三個名詞的詳細解釋，下次當你再面對面試官時，就能夠給出比「超文本傳輸協議」這七個字更準確更有技術含量的答案：「HTTP 是一個在計算機世界裏專門在兩點之間傳輸文字、圖片、音頻、視頻等超文本數據的約定和規範」。

• HTTP 是一個用在計算機世界裏的協議，它確立了一種計算機之間交流通訊的規範，以及相關的各類控制和錯誤處理方式。

• HTTP 專門用來在兩點之間傳輸數據，不能用於廣播、尋址或路由。

• HTTP 傳輸的是文字、圖片、音頻、視頻等超文本數據。

• HTTP 是構建互聯網的重要基礎技術，它沒有實體，依賴許多其餘的技術來實現，但同時許多技術也都依賴於它。

 

HTTP 發展史

創世紀

1989 年，任職於歐洲核子研究中心（CERN）的蒂姆·伯納斯 - 李（Tim Berners-Lee）發表了一篇論文，提出了在互聯網上構建超連接文檔系統的構想。這篇論文中他確立了三項關鍵技術。

• URI：即統一資源標識符，做爲互聯網上資源的惟一身份；

• HTML：即超文本標記語言，描述超文本文檔；

• HTTP：即超文本傳輸協議，用來傳輸超文本。

HTTP/0.9

20 世紀 90 年代初期的互聯網世界很是簡陋，計算機處理能力低，存儲容量小，網速很慢，仍是一片「信息荒漠」。

這一時期的 HTTP 被定義爲 0.9 版，結構比較簡單，爲了便於服務器和客戶端處理，它也採用了純文本格式，只容許用 「GET」 動做從服務器上獲取 HTML 文檔，而且在響應請求以後當即關閉鏈接，功能很是有限。

HTTP/1.0

隨着計算機技術的發展，新的軟件和技術的出現，好比JPEG 圖像格式，服務器軟件 Apache等，須要對 HTTP 進行更新。HTTP/1.0 版本在 1996 年正式發佈。它在多方面加強了 0.9 版，形式上已經和咱們如今的 HTTP 差異不大了，例如：

• 增長了 HEAD、POST 等新方法；

• 增長了響應狀態碼，標記可能的錯誤緣由；

• 引入了協議版本號概念；

• 引入了 HTTP Header（頭部）的概念，讓 HTTP 處理請求和響應更加靈活；

• 傳輸的數據再也不僅限於文本。

但 HTTP/1.0 並非一個「標準」，只是記錄已有實踐和模式的一份參考文檔，不具備實際的約束力，至關於一個「備忘錄」。

HTTP/1.1

1995 年，網景的 Netscape Navigator 和微軟的 Internet Explorer 開始了著名的「瀏覽器大戰」，都但願在互聯網上佔據主導地位。

這場戰爭最終微軟的 IE 取得了決定性的勝利，而網景則「敗走麥城」（但後來卻憑藉 Mozilla Firefox 又扳回一局）。

「瀏覽器大戰」再一次極大地推進了 Web 的發展，HTTP/1.0 也在這個過程當中經受了實踐檢驗。因而在「瀏覽器大戰」結束以後的 1999 年，HTTP/1.1 發佈了 RFC 文檔，編號爲 2616，正式確立了延續十餘年的傳奇。

從版本號咱們就能夠看到，HTTP/1.1 是對 HTTP/1.0 的小幅度修正。但一個重要的區別是：它是一個「正式的標準」，而不是一份無關緊要的「參考文檔」。這意味着從此互聯網上全部的瀏覽器、服務器、網關、代理等等，只要用到 HTTP 協議，就必須嚴格遵照這個標準，至關因而互聯網世界的一個「立法」。

HTTP/1.1 主要的變動點有：

• 增長了 PUT、DELETE 等新的方法；

• 增長了緩存管理和控制；

• 明確了鏈接管理，容許持久鏈接；

• 容許響應數據分塊（chunked），利於傳輸大文件；

• 強制要求 Host 頭，讓互聯網主機託管成爲可能。

HTTP/1.1 的推出可謂是「衆望所歸」，互聯網在它的「保駕護航」下邁開了大步，由此走上了「康莊大道」，開啓了後續的「Web 1.0」「Web 2.0」時代。

不過因爲 HTTP/1.1 太過龐大和複雜，因此在 2014 年又作了一次修訂，原來的一個大文檔被拆分紅了六份較小的文檔，編號爲 7230-7235，優化了一些細節，但此外沒有任何實質性的改動。

HTTP/2

HTTP/1.1 發佈以後，整個互聯網世界呈現出了爆發式的增加，度過了十多年的「快樂時光」。這期間也出現了一些對 HTTP 不滿的意見，主要就是鏈接慢，沒法跟上迅猛發展的互聯網，但 HTTP/1.1 標準一直「巋然不動」，無奈之下人們只好發明各式各樣的「小花招」來緩解這些問題，好比之前常見的切圖、JS 合併等網頁優化手段。

Google 首先開發了本身的瀏覽器 Chrome，而後推出了新的 SPDY 協議，並在 Chrome 裏應用於自家的服務器，如同十多年前的網景與微軟同樣，從實際的用戶方來「倒逼」HTTP 協議的變革，這也開啓了第二次的「瀏覽器大戰」。Chrome 目前的全球的佔有率超過了 60%。「挾用戶以號令天下」，Google 藉此順勢把 SPDY 推上了標準的寶座，互聯網標準化組織以 SPDY 爲基礎開始制定新版本的 HTTP 協議，最終在 2015 年發佈了 HTTP/2，RFC 編號 7540。

HTTP/2 的制定充分考慮了現今互聯網的現狀：寬帶、移動、不安全，在高度兼容 HTTP/1.1 的同時在性能改善方面作了很大努力，主要的特色有：

• 二進制協議，再也不是純文本；

• 可發起多個請求，廢棄了 1.1 裏的管道；

• 使用專用算法壓縮頭部，減小數據傳輸量；

• 容許服務器主動向客戶端推送數據；

• 加強了安全性，「事實上」要求加密通訊。

雖然 HTTP/2 到今天已經四歲，也衍生出了 gRPC 等新協議，但因爲 HTTP/1.1 實在是太過經典和強勢，目前它的普及率還比較低，大多數網站使用的仍然仍是 20 年前的 HTTP/1.1。

HTTP/3

在 HTTP/2 還處於草案之時，Google 又發明了一個新的協議，叫作 QUIC，並且仍是相同的「套路」，繼續在 Chrome 和自家服務器裏試驗着「玩」，依託它的龐大用戶量和數據量，持續地推進 QUIC 協議成爲互聯網上的「既成事實」。

2018 年，互聯網標準化組織 IETF 提議將「HTTP over QUIC」改名爲「HTTP/3」並得到批准，HTTP/3 正式進入了標準化制訂階段，也許兩三年後就會正式發佈，到時候咱們極可能會跳過 HTTP/2 直接進入 HTTP/3。

小結

在這裏簡單小結一下今天的內容：

1. HTTP 協議始於三十年前蒂姆·伯納斯 - 李的一篇論文；

2. HTTP/0.9 是個簡單的文本協議，只能獲取文本資源；

3. HTTP/1.0 確立了大部分如今使用的技術，但它不是正式標準；

4. HTTP/1.1 是目前互聯網上使用最普遍的協議，功能也很是完善；

5. HTTP/2 基於 Google 的 SPDY 協議，注重性能改善，但還未普及；

6. HTTP/3 基於 Google 的 QUIC 協議，是未來的發展方向。

 

與 HTTP 相關的各類概念和協議

瀏覽器

上網就要用到瀏覽器，常見的瀏覽器有 Google 的 Chrome、Mozilla 的 Firefox、Apple 的 Safari、Microsoft 的 IE 和 Edge，還有小衆的 Opera 以及國內的各類「換殼」的「極速」「安全」瀏覽器。

那麼你想過沒有，所謂的「瀏覽器」究竟是個什麼東西呢？

瀏覽器的正式名字叫「Web Browser」，顧名思義，就是檢索、查看互聯網上網頁資源的應用程序，名字裏的 Web，實際上指的就是「World Wide Web」，也就是萬維網。

瀏覽器本質上是一個 HTTP 協議中的請求方，使用 HTTP 協議獲取網絡上的各類資源。固然，爲了讓咱們更好地檢索查看網頁，它還集成了不少額外的功能。

例如，HTML 排版引擎用來展現頁面，JavaScript 引擎用來實現動態化效果，甚至還有開發者工具用來調試網頁，以及五花八門的各類插件和擴展。

在 HTTP 協議裏，瀏覽器的角色被稱爲「User Agent」即「用戶代理」，意思是做爲訪問者的「代理」來發起 HTTP 請求。不過在不引發混淆的狀況下，咱們一般都簡單地稱之爲「客戶端」。

Web 服務器

剛纔說的瀏覽器是 HTTP 裏的請求方，那麼在協議另外一端的應答方（響應方）又是什麼呢？答案就是服務器，Web Server。

Web 服務器是一個很大也很重要的概念，它是 HTTP 協議裏響應請求的主體，一般也把控着絕大多數的網絡資源，在網絡世界裏處於強勢地位。

當咱們談到「Web 服務器」時有兩個層面的含義：硬件和軟件。

硬件含義就是物理形式或「雲」形式的機器，在大多數狀況下它可能不是一臺服務器，而是利用反向代理、負載均衡等技術組成的龐大集羣。但從外界看來，它仍然表現爲一臺機器，但這個形象是「虛擬的」。

軟件含義的 Web 服務器可能咱們更爲關心，它就是提供 Web 服務的應用程序，一般會運行在硬件含義的服務器上。它利用強大的硬件能力響應海量的客戶端 HTTP 請求，處理磁盤上的網頁、圖片等靜態文件，或者把請求轉發給後面的 Tomcat、Node.js 等業務應用，返回動態的信息。

比起層出不窮的各類 Web 瀏覽器，Web 服務器就要少不少了，一隻手的手指頭就能夠數得過來。

Apache 是老牌的服務器，到今天已經快 25 年了，功能至關完善，相關的資料不少，學習門檻低，是許多創業者建站的入門產品。

Nginx 是 Web 服務器裏的後起之秀，特色是高性能、高穩定，且易於擴展。自 2004 年推出後就不斷蠶食 Apache 的市場份額，在高流量的網站裏更是不二之選。

此外，還有 Windows 上的 IIS、Java 的 Jetty/Tomcat 等，由於性能不是很高，因此在互聯網上應用得較少。

TCP/IP

TCP/IP 協議其實是一系列網絡通訊協議的統稱，其中最核心的兩個協議是TCP和IP，其餘的還有 UDP、ICMP、ARP 等等，共同構成了一個複雜但有層次的協議棧。

這個協議棧有四層，最上層是「應用層」，最下層是「連接層」，TCP 和 IP 則在中間：TCP 屬於「傳輸層」，IP 屬於「網際層」。協議的層級關係模型很是重要，我會在下一講中再專門講解，這裏先暫時放一放。

IP 協議是「Internet Protocol」的縮寫，主要目的是解決尋址和路由問題，以及如何在兩點間傳送數據包。IP 協議使用「IP 地址」的概念來定位互聯網上的每一臺計算機。能夠對比一下現實中的電話系統，你拿着的手機至關於互聯網上的計算機，而要打電話就必須接入電話網，由通訊公司給你分配一個號碼，這個號碼就至關於 IP 地址。

如今咱們使用的 IP 協議大多數是 v4 版，地址是四個用「.」分隔的數字，例如「192.168.0.1」，總共有 2^32，大約 42 億個能夠分配的地址。看上去好像不少，但互聯網的快速發展讓地址的分配管理很快就「捉襟見肘」。因此，就又出現了 v6 版，使用 8 組「:」分隔的數字做爲地址，容量擴大了不少，有 2^128 個，在將來的幾十年裏應該是足夠用了。

TCP 協議是「Transmission Control Protocol」的縮寫，意思是「傳輸控制協議」，它位於 IP 協議之上，基於 IP 協議提供可靠的、字節流形式的通訊，是 HTTP 協議得以實現的基礎。

「可靠」是指保證數據不丟失，「字節流」是指保證數據完整，因此在 TCP 協議的兩端能夠如同操做文件同樣訪問傳輸的數據，就像是讀寫在一個密閉的管道里「流動」的字節。

HTTP 是一個"傳輸協議"，但它不關心尋址、路由、數據完整性等傳輸細節，而要求這些工做都由下層來處理。由於互聯網上最流行的是 TCP/IP 協議，而它恰好知足 HTTP 的要求，因此互聯網上的 HTTP 協議就運行在了 TCP/IP 上，HTTP 也就能夠更準確地稱爲「HTTP over TCP/IP」。

DNS

在 TCP/IP 協議中使用 IP 地址來標識計算機，數字形式的地址對於計算機來講是方便了，但對於人類來講卻既難以記憶又難以輸入。

因而「域名系統」（Domain Name System, DNS）出現了，用有意義的名字來做爲 IP 地址的等價替代。設想一下，你是願意記「95.211.80.227」這樣枯燥的數字，仍是「nginx.org」這樣的詞組呢？

在 DNS 中，「域名」（Domain Name）又稱爲「主機名」（Host），爲了更好地標記不一樣國家或組織的主機，讓名字更好記，因此被設計成了一個有層次的結構。

域名用「.」分隔成多個單詞，級別從左到右逐級升高，最右邊的被稱爲「頂級域名」。對於頂級域名，可能你隨口就能說出幾個，例如表示商業公司的「com」、表示教育機構的「edu」，表示國家的「cn」「uk」等，買火車票時的域名還記得嗎？是「www.12306.cn」。

但想要使用 TCP/IP 協議來通訊仍然要使用 IP 地址，因此須要把域名作一個轉換，「映射」到它的真實 IP，這就是所謂的「域名解析」。

域名解析的實際操做要比剛纔的例子複雜不少，由於互聯網上的電腦實在是太多了。目前全世界有 13 組根 DNS 服務器，下面再有許多的頂級 DNS、權威 DNS 和更小的本地 DNS，逐層遞歸地實現域名查詢。

HTTP 協議中並無明確要求必須使用 DNS，但實際上爲了方便訪問互聯網上的 Web 服務器，一般都會使用 DNS 來定位或標記主機名，間接地把 DNS 與 HTTP 綁在了一塊兒。

URI/URL

URI（Uniform Resource Identifier），中文名稱是 統一資源標識符，使用它就可以惟一地標記互聯網上資源。

URI 另外一個更經常使用的表現形式是 URL（Uniform Resource Locator）， 統一資源定位符，也就是咱們俗稱的「網址」，它其實是 URI 的一個子集，不過由於這二者幾乎是相同的，差別不大，因此一般不會作嚴格的區分。

我就拿 Nginx 網站來舉例，看一下 URI 是什麼樣子的。

http://nginx.org/en/download.html

你能夠看到，URI 主要有三個基本的部分構成：

1. 協議名：即訪問該資源應當使用的協議，在這裏是「http」；

2. 主機名：即互聯網上主機的標記，能夠是域名或 IP 地址，在這裏是「nginx.org」；

3. 路徑：即資源在主機上的位置，使用「/」分隔多級目錄，在這裏是「/en/download.html」。

CDN

瀏覽器和服務器是 HTTP 協議的兩個端點，那麼，在這二者之間還有別的什麼東西嗎？

固然有了。瀏覽器一般不會直接連到服務器，中間會通過「重重關卡」，其中的一個重要角色就叫作 CDN。

CDN，全稱是「Content Delivery Network」，翻譯過來就是「內容分發網絡」。它應用了 HTTP 協議裏的緩存和代理技術，代替源站響應客戶端的請求。

CDN 有什麼好處呢？

簡單來講，它能夠緩存源站的數據，讓瀏覽器的請求不用「千里迢迢」地到達源站服務器，直接在「半路」就能夠獲取響應。若是 CDN 的調度算法很優秀，更能夠找到離用戶最近的節點，大幅度縮短響應時間。

CDN 也是如今互聯網中的一項重要基礎設施，除了基本的網絡加速外，還提供負載均衡、安全防禦、邊緣計算、跨運營商網絡等功能，可以成倍地「放大」源站服務器的服務能力，不少雲服務商都把 CDN 做爲產品的一部分。

HTTPS

HTTPS 的全稱是 「HTTP over SSL/TLS」，也就是運行在 SSL/TLS 協議上的 HTTP。

注意它的名字，這裏是 SSL/TLS，而不是 TCP/IP，它是一個負責加密通訊的安全協議，創建在 TCP/IP 之上，因此也是個可靠的傳輸協議，能夠被用做 HTTP 的下層。

由於 HTTPS 至關於「HTTP+SSL/TLS+TCP/IP」，其中的「HTTP」和「TCP/IP」咱們都已經明白了，只要再瞭解一下 SSL/TLS，HTTPS 也就可以輕鬆掌握。

SSL 的全稱是「Secure Socket Layer」，由網景公司發明，當發展到 3.0 時被標準化，更名爲 TLS，即「Transport Layer Security」，但因爲歷史的緣由仍是有不少人稱之爲 SSL/TLS，或者直接簡稱爲 SSL。

SSL 使用了許多密碼學最早進的研究成果，綜合了對稱加密、非對稱加密、摘要算法、數字簽名、數字證書等技術，可以在不安全的環境中爲通訊的雙方建立出一個祕密的、安全的傳輸通道，爲 HTTP 套上一副堅固的盔甲。

你能夠留心看一下瀏覽器地址欄，若是有一個小鎖頭標誌，那就代表網站啓用了安全的 HTTPS 協議，而 URI 裏的協議名，也從「http」變成了「https」。

代理

代理（Proxy）是 HTTP 協議中請求方和應答方中間的一個環節，做爲「中轉站」，既能夠轉發客戶端的請求，也能夠轉發服務器的應答。

代理有不少的種類，常見的有：

1. 匿名代理：徹底「隱匿」了被代理的機器，外界看到的只是代理服務器；

2. 透明代理：顧名思義，它在傳輸過程當中是「透明開放」的，外界既知道代理，也知道客戶端；

3. 正向代理：靠近客戶端，表明客戶端向服務器發送請求；

4. 反向代理：靠近服務器端，表明服務器響應客戶端的請求；

 CDN 實際上就是一種代理，它代替源站服務器響應客戶端的請求，一般扮演着透明代理和反向代理的角色。

因爲代理在傳輸過程當中插入了一個「中間層」，因此能夠在這個環節作不少有意思的事情，好比：

1. 負載均衡：把訪問請求均勻分散到多臺機器，實現訪問集羣化；

2. 內容緩存：暫存上下行的數據，減輕後端的壓力；

3. 安全防禦：隱匿 IP, 使用 WAF 等工具抵禦網絡攻擊，保護被代理的機器；

4. 數據處理：提供壓縮、加密等額外的功能。

關於 HTTP 的代理還有一個特殊的「代理協議」（proxy protocol），它由知名的代理軟件 HAProxy 制訂，但並非 RFC 標準，我也會在以後的課程裏專門講解。

小結

此次我介紹了與 HTTP 相關的各類協議，在這裏簡單小結一下今天的內容。

 

1. TCP/IP 是網絡世界最經常使用的協議，HTTP 一般運行在 TCP/IP 提供的可靠傳輸基礎上；

2. DNS 域名是 IP 地址的等價替代，須要用域名解析實現到 IP 地址的映射；

3. URI 是用來標記互聯網上資源的一個名字，由「協議名 + 主機名 + 路徑」構成，俗稱 URL；

4. HTTPS 至關於「HTTP+SSL/TLS+TCP/IP」，爲 HTTP 套了一個安全的外殼；

5. 代理是 HTTP 傳輸過程當中的「中轉站」，能夠實現緩存加速、負載均衡等功能。

6. 瀏覽器是 HTTP 協議裏的請求方，即 User Agent；

7. 服務器是 HTTP 協議裏的應答方，經常使用的有 Apache 和 Nginx；

總結

HTTP 是一種可以獲取如 HTML 這樣的網絡資源的 protocol(通信協議)。它是在 Web 上進行數據交換的基礎，是一種 client-server 協議，也就是說，請求一般是由像瀏覽器這樣的接受方發起的。一個完整的 Web 文檔一般是由不一樣的子文檔拼接而成的，像是文本、佈局描述、圖片、視頻、腳本等等。

客戶端和服務端經過交換各自的消息（與數據流正好相反）進行交互。由像瀏覽器這樣的客戶端發出的消息叫作 requests，被服務端響應的消息叫作 responses。