當面試時被問對http瞭解多少的時候（一）—— http 協議破冰篇

前言

曾經在面試的時候被問了一個問題，關於 http 你瞭解多少，聽到這個問題的時候有點懵，想到了 http 的緩存，想到了 http 的響應狀態碼，想到了 http 和 https 的區別等等。可是不能否認，這些知識都是點，沒有造成系統的知識框架，因此最近系統學了一下，在這裏記錄下來。下次被問到關於 http 你瞭解多少的時候思路就比較清晰了。

這是一個系列的記錄與學習，由於內容比較長，因此每篇記錄會有對應一個思惟導圖，看起來更加一目瞭然。

http 的創世紀誕生

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

1. URI：即統一資源標識符，做爲互聯網上資源的惟一身份；
2. HTML：即超文本標記語言，用來描述超文本文檔；
3. HTTP：即超文本傳輸協議，用來傳輸超文本；

這三項技術在現在的咱們看起來已是稀鬆日常，但在當時倒是了不起的大發明。基於它們，就能夠把超文本系統完美的運行在互聯網上，讓各地的人們可以自由的共享信息，蒂姆把這個系統稱爲「萬維網」（World Wide Web），也就是咱們如今熟知的 web。

因此在這一年，咱們的英雄 「HTTP」 誕生了，今後開始了它偉大的征途。

http 的發展歷史

1. HTTP/0.9

20 世紀 90 年代初期的互聯網世界很是簡陋，計算機的處理能力低，存儲容量小，網速慢。網上的資源大部分都是純文本，不少通訊協議也都使用純文本，因此 http 的設計也不可避免的受到了時代的限制。

這一階段的 http 是個簡單的文本協議，只有GET一個命令，只能獲取文本資源，服務器發送完內容以後就關閉鏈接。

2. HTTP/1.0

隨着互聯網的發展，支持圖文混排瀏覽器 Mosaic 的問世，服務器軟件 Apache 的上線，以及計算機多媒體技術JPEG、MP3等的發展，從用戶的需求的角度促進 http 的發展已經勢在必行。

HTTP/1.0 版本在 1996年 正式發佈，它在多方面加強了0.9版，形式上已經和咱們如今的 http 差異不大了。

1. 增長了 HEAD、POST 等新方法；
2. 增長了相應狀態碼，標記可能的錯誤緣由；
3. 引入了 http Header 的概念，讓 http 處理請求和響應更加靈活；
4. 傳輸的數據再也不僅限於文本；

HTTP/1.0 確立了大部分如今使用的技術，但它 不是正式標準，不具備實際的約束力。因此 HTTP/1.0 的發佈對於當時正在蓬勃發展的互聯網來講並無太大的實際意義，各方勢力仍然按照本身的意圖繼續在市場上奮力拼殺。

3. HTTP/1.1

「瀏覽器大戰」 極大的推進了 web 的發展，在「瀏覽器大戰」 結束後的 1999 年，HTTP/1.1 發佈了 RFC 文檔，標示着它是一個正式的標準，而不是一份無關緊要的參考文檔。這意味着從此互聯網上全部的瀏覽器、服務器、網關等只要用到了 http 協議，就必須嚴格遵照這個標準。

HTTP/1.1 主要的變動點有：

1. 增長了 PUT、DELETE 等新的方法；
2. 增長了緩存管理和控制；
3. 明確了鏈接管理，容許持久鏈接；
4. 容許相應數據分塊（chunked），有利於傳輸大文件；

HTTP/1.1 的推出可謂是「衆望所歸」，互聯網在它的「保駕護航」下邁開了大步，由此走上了「康莊大道」，開啓了後續的「Web 1.0」「Web 2.0」時代。如今許多的知名網站都是在這個時間點左右創立的，例如 Google、新浪、搜狐、網易、騰訊等。

4. HTTP/2

現有的 http 鏈接慢，沒法跟上迅猛發展的互聯網，無奈之下人們採用各類各樣的方式去作性能的優化，好比常見的雪碧圖、JS資源合併等。

終於有一天 Google 忍不住了，決定 「揭竿而起」。Google 首先開發了本身的瀏覽器 Chrome，而後推出了新的 SPDY 協議，並在 Chrome 裏應用於自家服務器，從實際的用戶方來「倒逼」 http協議的變革。

Google 目前的全球佔有率超過了60%，順勢把 SPDY 推上了標準的寶座，互聯網標準化組織以 SPDY 爲基礎開始定製新版本的 http 協議，最終在 2015 年發佈了 HTTP/2。

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

1. 全部數據以二進制傳輸；
2. 能夠發起多個請求，同一個鏈接裏面發送多個請求再也不須要按照順序來；
3. 使用專用算法壓縮頭部，減小數據傳輸量；
4. 容許服務器主動向客戶端推送數據；
5. 加強了安全性，要求加密通訊；

5. HTTP/3

在 HTTP/2 還處於草案之時，Google 又發明了一個新的協議，叫作 QUIC，繼續依託它的龐大的用戶量和數據量，持續地推進 QUIC 協議稱爲互聯網上的「既成事實」。

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

HTTP 是什麼

詳細瞭解了 http 的發展歷史以後，再來看 http 是什麼可能會更好的理解。簡單的來講以下：

HTTP 就是超文本傳輸協議，也就是 HyperText Transfer Protocol。

可是這個回答太過簡單了，咱們再來深刻看一下。中國有一個成語叫 「人如其名」，意思是一我的的性格和特色是與他的名字相符的。先來看一下 http 的名字：「超文本傳輸協議」，它能夠拆成三個部分，分別是：「超文本」、「傳輸」 和 「協議」。咱們理解了這三個詞，也就明白了什麼是 http。

1. 所謂 「協議」

http 是一個協議，協議是對參與者的一種行爲約定和規範。

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

2. 所謂 「傳輸」

所謂的「傳輸」其實很好理解，就是把一堆東西從 A 點搬到 B 點，或者從 B 點搬到 A 點， 即 「A<===>B」，這裏麪包含了兩個重要的信息：

1. http 協議是一個 「雙向協議」
2. 數據雖然是在A 和 B 之間傳輸，但並無限制只有 A 和 B 這兩個角色，容許中間有 「中轉」 或者 「接力」。

這樣，傳輸方式就從「A<===>B」，變成了「A<=>X<=>Y<=>Z<=>B」，A 到 B 的傳輸過程當中能夠存在任意多個「中間人」，而這些中間人也都聽從 HTTP 協議，只要不打擾基本的數據傳輸，就能夠添加任意的額外功能，例如安全認證、數據壓縮、編碼轉換等等，優化整個傳輸過程。總結一下的話：

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

3. 所謂 「超文本」

所謂「文本」，就表示 http 傳輸的不是 TCP/UDP 這些較爲底層協議裏被切分的雜亂無章的二進制包（datagram），而是完整的、有異議的數據，能夠被瀏覽器、服務器這樣的上層應用程序處理。

在互聯網早期，「文本」只是簡單的字符文字，可是發展到如今，「文本」的含義已經被大大拓展了，圖片、音頻、視頻等，在 http 的眼裏均可以算做是「文本」。

所謂「超文本」，就是「超越了普普統統的文本」，它是文字、圖片、音頻、視頻等的混合體，還能夠含有「超連接」，可以從一個「超文本」跳轉到另外一個「超文本」。

最後總結一下http是什麼：

HTTP 是一個在計算機世界裏專門在兩點之間傳輸文字、圖片、音頻、視頻等超文本數據的約定和規範。

與 http 相關的一些概念

現在的互聯網是一個強大而又複雜的網絡，咱們有必要了解與 http 相關的一些概念。

1. CDN

客戶端和服務器是 http 協議的兩個端點，客戶端一般不會直接鏈接到服務器，中間會通過「重重關卡」，其中一個重要的角色就叫作 CDN。

CDN 的全稱是 「Content Delivery Network」，翻譯過來即爲 內容分發網絡，它應用了 http 協議裏的緩存和代理技術，代替源站相應客戶端的請求。那麼，CDN 有什麼好處呢？

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

2. 爬蟲

瀏覽器是一種用戶代理，代替咱們訪問互聯網。但 http 協議並無規定用戶代理後面必須是 「真正的人類」 ，它徹底可使 「機器人」 ，這些 「機器人」 的正式名稱就叫作 「爬蟲」，實際上一種能夠自動訪問 web 資源的應用程序。

「爬蟲」 這個名字很是形象，他們就像是一隻只不知疲倦的螞蟻，在一望無際的網絡世界裏爬來爬去，不停地在網站間奔走，蒐集抓取各類信息。據估計，互聯網上至少有 50% 的流量都是由爬蟲產生的。

爬蟲 是怎麼來的呢？

絕大多數是由各大搜索引擎放出來的，抓取網頁存入龐大的數據庫，再創建關鍵字索引，這樣咱們纔可以在各大搜索引擎中快速的搜索到互聯網各個行業的內容。

爬蟲也有很差的一面，它會過分消耗網絡資源，佔用服務器和帶寬，影響網站對真實數據的分析，甚至致使敏感信息泄露。因此又會出現「反爬蟲」技術，經過各類手段來限制爬蟲。其中一項就是「君子協定」，約定哪些該爬，哪些不應爬。

3. DNS

DNS 的全稱是 Domain Name System，翻譯爲 域名系統。

在 TCP/IP 協議中使用 IP 地址來標識計算機，數字形式的地址對於計算機來說很方便，可是對於人類來說卻難以記憶和使用。因而 域名系統 出現了，核心是用有意義的名字來做爲 IP 地址的等價替代。

在 DNS 中，域名 又被稱爲 主機名，爲了更好地標記不一樣國家和組織的主機，而且讓名字更好的記憶，因此被設計成了一個 有層次的結構。

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

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

用打電話的例子來作個比喻，你想要打電話給小明，但不知道電話號碼，就得在手機裏的號碼簿裏一項一項地找，直到找到小明那一條記錄，而後才能查到號碼。這裏的「小明」就至關於域名，而「電話號碼」就至關於 IP 地址，這個查找的過程就是域名解析。

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

4. URL

有了 TCP/IP 和 DNS，仍是不是咱們就能夠任意訪問網絡上的資源了呢？

還不行，DNS 和 IP地址只是爲了標記互聯網上的主機，可是主機上有那麼多的文本、圖片和頁面等資源，到底要找哪個呢？

因此出現了 URL（Uniform Resource Locator），翻譯爲 統一資源定位符，也就是咱們俗稱的 網址。

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

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

複製代碼

能夠看到，URL 主要有三個基本的部分組成：

1. 協議名：即訪問該資源應該使用的協議，這裏是 http。
2. 主機名：即互聯網主機的標記，可使域名或 IP 地址，在這裏是 「nginx.org」。代理（Proxy）是 HTTP 協議中請求方和應答方中間的一個環節，做爲「中轉站」，既能夠轉發客戶端的請求，也能夠轉發服務器的應答。
3. 路徑：即資源在主機上的位置，使用 「/」 分割多級目錄，在這裏是 「/en/download.html」。

仍是用打電話來作比喻，你經過電話簿找到了小明，讓他把昨天作好的宣傳文案快遞過來。那麼這個過程當中你就完成了一次 URI 資源訪問，「小明」就是「主機名」，「昨天作好的宣傳文案」就是「路徑」，而「快遞」，就是你要訪問這個資源的「協議名」。

5. 代理（ Proxy ）

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

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

1. 匿名代理：徹底「隱匿」了被代理的機器，外界看到的只是代理服務器；
2. 透明代理：顧名思義，它在傳輸過程當中是「透明開放」的，外界既知道代理，也知道客戶端；
3. 正向代理：靠近客戶端，表明客戶端向服務器發送請求；
4. 反向代理：靠近服務器端，表明服務器響應客戶端的請求；

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

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

1. 負載均衡：把訪問請求均勻分散到多臺機器，實現訪問集羣化；
2. 內容緩存：暫存上下行的數據，減輕後端的壓力；
3. 安全防禦：隱匿 IP, 使用 WAF 等工具抵禦網絡攻擊，保護被代理的機器；
4. 數據處理：提供壓縮、加密等額外的功能。