1、前言
本文是《HTTP 權(quán)威指南》的第一章節(jié) HTTP 概述的 讀書筆記，我會(huì)嘗試站在 HTTP 設(shè)計(jì)者 的角度上將知識(shí)點(diǎn)編輯成串，所以閱讀本文您將收獲 HTTP 宏觀層面上的架構(gòu)設(shè)計(jì)。
2、概述
HTTP（HyperText Transfer Protocol）：超文本傳輸協(xié)議，是互聯(lián)網(wǎng)上應(yīng)用最廣泛的網(wǎng)絡(luò)協(xié)議之一。設(shè)計(jì) HTTP 的最初目的是為了提供一種發(fā)布和接收 HTML 頁(yè)面的方法。通過(guò) HTTP 或者 HTTPS 協(xié)議請(qǐng)求的資源由統(tǒng)一資源標(biāo)識(shí)符（Uniform Resources Identifiers，URI）來(lái)標(biāo)識(shí)。
HTTP 發(fā)展歷程：
1、由1989年在歐洲核子研究組織（CERN）發(fā)起。
2、由 W3C 和 IETF 制定標(biāo)準(zhǔn)并發(fā)布一系列 RFC（最著名的是RFC 2616 -- HTTP/1.1）。
3、2014年12月，IETF 提交了 HTTP/2的標(biāo)準(zhǔn)。
4、2015年2月17日，HTTP/2標(biāo)準(zhǔn)被批準(zhǔn)。
5、2015年5月，HTTP/2標(biāo)準(zhǔn)以 RFC 7540正式發(fā)表。
3、HTTP 的構(gòu)成
3.1、服務(wù)端
因?yàn)?Web 服務(wù)器所使用的是 HTTP 協(xié)議，因此經(jīng)常會(huì)被稱為 HTTP 服務(wù)器。
市面上常見(jiàn)的 HTTP 服務(wù)器有：
- Apache HTTP Server
- IIS
- Google WebServer 基于 Apache HTTP Server 開(kāi)發(fā)的。
- Nginx
- Tengine 基于 Nginx 開(kāi)發(fā)的。
- Lighttpd
3.2、客戶端
最常見(jiàn)的客戶端就是瀏覽器，客戶端向服務(wù)器請(qǐng)求 HTTP 對(duì)象，并將這些對(duì)象顯示在你的屏幕上。
服務(wù)端與客戶端就好比
公司與家，現(xiàn)在我們已經(jīng)知道了兩個(gè)真實(shí)世界上的地理位置。但是由于沒(méi)有坐標(biāo)，也就無(wú)法在地圖上定位兩個(gè)位置。（記住公司與家這個(gè)比喻，會(huì)在下文中反復(fù)提及該比喻。）
3.3、資源
Web 服務(wù)器是 Web 資源的宿主，所有能夠提供 Web 內(nèi)容的東西都可以理解為 Web 的資源。比如：圖片、HTML、音頻、股票交易系統(tǒng)。
3.3.1、媒體類型
正因?yàn)橛辛硕喾N資源，所以也就衍生了對(duì)資源分類的需求。對(duì)資源的分類也有利于數(shù)據(jù)的傳輸（打包、傳輸、解包），制定媒體類型可以讓眾多服務(wù)器/客戶端遵守統(tǒng)一的標(biāo)準(zhǔn)。
HTTP 在設(shè)計(jì)媒體類型時(shí)參考了 MIME（多用于因特網(wǎng)郵件擴(kuò)展），因?yàn)?MIME 很好的解決了在不同的電子郵件系統(tǒng)之間搬移報(bào)文時(shí)存在的問(wèn)題，因此 HTTP 也采納了它，用它來(lái)描述并標(biāo)記多媒體內(nèi)容。
HTTP 服務(wù)器會(huì)為所有的 HTTP 對(duì)象數(shù)據(jù)附加一個(gè) MIME 的類型。 當(dāng) Web 瀏覽器從服務(wù)器取回?cái)?shù)據(jù)對(duì)象時(shí)，會(huì)去查看 MIME 類型，看看它是否知道如何處理這個(gè)對(duì)象。
MIME 類型是一種文本標(biāo)記，由主要的對(duì)象對(duì)象和特定的子類型組成。使用 Content-Type 首部來(lái)標(biāo)識(shí)。
| 名稱 | 擴(kuò)展名 | MIME類型 |
|---|---|---|
| 超文本標(biāo)記語(yǔ)言文本 | .htm, .html | text/html |
| 普通文本 | .txt | text/plain |
| RTF文本 | .rtf | application/rtf |
| GIF圖形 | .gif | image/gif |
| JPEG圖形 | .ipeg, .jpg | image/jpeg |
| au聲音文件 | .au | audio/basic |
| MIDI音樂(lè)文件 | .mid, .midi | audio/midi, audio/x-midi |
| RealAudio音樂(lè)文件 | .ra, .ram | audio/x-pn-realaudio |
| MPEG文件 | .mpg,.mpeg | video/mpeg |
| AVI文件 | .avi | video/x-msvideo |
| GZIP文件 | .gz | application/x-gzip |
| TAR文件 | .tar | application/x-tar |
| JSON文件 | .json | application/json |
| png圖形 | .png | image/png |
更多的 MIME 類型，請(qǐng)參考 HTTP Content-Type 常用對(duì)照表。
3.3.2、URI
到目前為止我們手上擁有的武器是：客戶端、服務(wù)端、資源類型。下一步我們需要作的事情就是把資源類型跟資源能對(duì)應(yīng)上，這才能方便的往客戶端或服務(wù)端直接發(fā)送資源。而 URI 恰恰就是做這樣的事情，你看它的名字就知道了 —— 統(tǒng)一資源標(biāo)識(shí)符（Uniform Resources Identifier，URI）。
URI 就像經(jīng)緯度坐標(biāo)一樣，在世界范圍內(nèi)唯一標(biāo)識(shí)并定位信息資源。
比如：http://www.lxweimin.com/u/c2dc43022058 這是我的簡(jiǎn)書首頁(yè)。給定 URI，HTTP就可以解析出對(duì)象。
URI 有兩種形式：
3.3.2.1、URL
URL 說(shuō)明了協(xié)議、服務(wù)器和本地資源。
比如：http://www.lxweimin.com/u/c2dc43022058，對(duì)應(yīng)的是下表的內(nèi)容。
| 協(xié)議 | 服務(wù)器 | （相對(duì)服務(wù)器的）本地資源 |
|---|---|---|
| http | www.lxweimin.com | /u/c2dc43022058 |
3.3.2.2、URN
URN 是作為特定內(nèi)容的唯一名稱使用的，與目前資源的所在地?zé)o關(guān)。使用與位置無(wú)關(guān)的 URN 的好處是可以將資源四處搬移。
但是 URN 仍處于試驗(yàn)階段，所以這部分了解下即可。
3.4、事務(wù)
直到目前為止，我們手上有的武器有：客戶端、服務(wù)端、統(tǒng)一資源標(biāo)識(shí)符、資源類型，但是還沒(méi)有涉及到如何交換資源這一重大議題。
** 事務(wù)：即是一次成對(duì)出現(xiàn)的請(qǐng)求及響應(yīng)的結(jié)果。**
HTTP 事務(wù)是通過(guò)名為HTTP 報(bào)文的格式化數(shù)據(jù)塊進(jìn)行的。
1、瀏覽器輸入地址http://baidu.com，這是不符合標(biāo)準(zhǔn)格式的地址。
2、瀏覽器代理攔截了該次請(qǐng)求，并遵循 HTTP 協(xié)議模擬服務(wù)器返回我 HTTP報(bào)文。
3、瀏覽器獲取報(bào)文中的Location首部，瀏覽器地址重新輸入地址http://www.baidu.com，并再次發(fā)起請(qǐng)求。
這個(gè)過(guò)程關(guān)聯(lián)知識(shí)點(diǎn)HTTP 的報(bào)文，即請(qǐng)求報(bào)文與響應(yīng)報(bào)文的具體構(gòu)成。
3.5、報(bào)文
HTTP 報(bào)文都是純文本，相比二進(jìn)制代碼它具備很強(qiáng)的可讀性。我們可以用 Charles 來(lái)查看具體的報(bào)文。
HTTP 報(bào)文分為三個(gè)部分：
1、起始行，報(bào)文的第一行就是起始行。比如上圖中的：POST /v3/pb HTTP/1.1 與 HTTP/1.1 200 OK
2、首部字段，起始行后面有0~N 個(gè)首部字段。它們是由鍵名與鍵值構(gòu)成。格式如：Content-Type : text/html。（Charles 會(huì)將數(shù)據(jù)格式化，所以看不到冒號(hào)分割。）首部之后會(huì)有一行空行，這個(gè)空行是不應(yīng)被省略的。
3、主體，空行之后就是報(bào)文主體了。報(bào)文主體可以為空，通常用于表示該條報(bào)文要傳輸?shù)臄?shù)據(jù)
我們可以通過(guò)HTTP 報(bào)文，構(gòu)建一個(gè)數(shù)據(jù)與意圖的包裹。但目前為止，仍然沒(méi)有恰當(dāng)?shù)奈淦髂軌蛑С挚蛻舳伺c服務(wù)端之間互相傳遞包裹。
3.6、連接
3.6.1、TCP
HTTP 是位于 TCP 層之上的應(yīng)用層協(xié)議，HTTP 無(wú)需操心網(wǎng)絡(luò)通訊的細(xì)節(jié)，它把聯(lián)網(wǎng)的細(xì)節(jié)都交給了通用、可靠的 TCP 協(xié)議。
在 HTTP 客戶端向服務(wù)端發(fā)送報(bào)文之前，需要先用 IP 地址和端口號(hào)在客戶端與服務(wù)端之間建立一條 TCP/IP 連接。
建立 TCP/IP 連接的過(guò)程與打電話很相似。
| 序號(hào) | 建立 TCP/IP 連接 | 打電話 |
|---|---|---|
| 1、 | 需要知道 IP 地址 | 需要知道電話號(hào)碼 |
| 2、 | 連接 IP 地址 | 撥打電話號(hào)碼 |
| 3、 | 輸入端口號(hào) | 輸入分機(jī)號(hào)碼 |
| 4、 | 連接成功 | 電話撥號(hào)成功 |
在 TCP 中你需要知道服務(wù)器的 IP 地址，以及與服務(wù)器上允許的特定軟件相關(guān)的 TCP 端口號(hào)。
前面提到過(guò) URL，通過(guò) URL 自然就能夠?yàn)槲覀兲峁┐鎯?chǔ)資源的機(jī)器的 IP 地址。
舉例：http:// [主機(jī)名 或 IP 地址][端口號(hào)（可選）][資源位置]
- 如果填寫的是主機(jī)名，則可以通過(guò)與域名服務(wù)（DNS）的機(jī)制方便的將主機(jī)名轉(zhuǎn)化為 IP 地址。
- 如果未填寫端口號(hào)，則默認(rèn)端口號(hào)是：80。
HTTP 提供給我們五件武器，使用這些武器我們順利完成了對(duì)數(shù)據(jù)包裹的交換。這是最小的交互模型，理解它有助我們正確理解之后將要穿插在中間的代理鏈。
本文用客戶端或服務(wù)端名詞定義其實(shí)是不嚴(yán)謹(jǐn)?shù)模鼈兌际菍?shí)現(xiàn)了 HTTP 協(xié)議規(guī)范的應(yīng)用程序，本質(zhì)上它們都是普通的應(yīng)用程序（包括代理也是如此）。它們都需要正確的處理發(fā)送與接收響應(yīng)報(bào)文，站在Web服務(wù)器的視角 響應(yīng)可以看做是向Web 瀏覽器發(fā)送報(bào)文。站在 Web 瀏覽器亦反之。
4、拓展閱讀
另外列出一些比較重要的應(yīng)用程序（它們均滿足 HTTP 協(xié)議規(guī)范只是在應(yīng)用場(chǎng)景上實(shí)現(xiàn)不同）：
- 代理，位于客戶端與服務(wù)端之間的 HTTP 中間實(shí)體。
- 緩存，HTTP 倉(cāng)庫(kù)，使常用頁(yè)面的副本可以保存在離客戶端更近的地方。
- 網(wǎng)管，連接其他應(yīng)用程序的特殊 Web 服務(wù)器。
- 隧道，對(duì) HTTP 通信報(bào)文進(jìn)行
盲轉(zhuǎn)發(fā)的特殊代理。 - Agent 代理，發(fā)起自動(dòng) HTTP 請(qǐng)求的半智能 Web 客戶端。
（了解即可，后面會(huì)依次詳細(xì)介紹）
