1. HTTP 的版本

1.1 HTTP/0.9（20 世紀(jì) 90 年代初）

1. 采用純文本格式
2. 由于最初設(shè)想的系統(tǒng)里的文檔都是只讀的亮蒋，所以只允許 GET 動作從服務(wù)器拉取 HTML 數(shù)據(jù)
3. 響應(yīng)請求后立即關(guān)閉連接

1.2 HTTP/1.0（1996 正式發(fā)布）

在 0.9 的基礎(chǔ)上舔涎，做了下面改動：

1. 增加了 HEAD托嚣、POST等新方法
2. 增加了響應(yīng)狀態(tài)碼纷铣，標(biāo)記可能的錯誤原因
3. 引入了協(xié)議版本號概念
4. 引入了 HTTP Header 概念设凹，讓 Http 處理請求和響應(yīng)更加容易
5. 傳輸協(xié)議不再僅限于文本

但 HTTP 并不是一個標(biāo)準(zhǔn)碱工，而只是一個參考文檔沼琉，不具有實際的約束力北苟，相當(dāng)于一個“備忘錄”。

1.3 HTTP/1.1（1999 發(fā)布 RFC 文檔）

在 1.0 的基礎(chǔ)上進(jìn)行了小幅的修正打瘪，主要區(qū)別是：1.1 是一個“正式的標(biāo)準(zhǔn)”友鼻。

HTTP/1.1 的主要改動有：

1. 增加了 PUT、DELETE 等新的方法
2. 增加了緩存管理和控制
3. 明確了連接管理闺骚，允許持久連接
4. 允許響應(yīng)數(shù)據(jù)分塊（chunked）彩扔，利用數(shù)據(jù)大文件
5. 強(qiáng)制要求 Host 頭，讓互聯(lián)網(wǎng)主機(jī)托管成為可能

1.4 HTTP/2.0（2015 年正式發(fā)布）

基于 GOOGLE 開發(fā)的 SPY 協(xié)議而來僻爽。主要特點(diǎn)為：

1. 二進(jìn)制協(xié)議虫碉，不再是純文本
2. 可發(fā)起多個請求，廢棄了 1.1 里的管道
3. 使用專用算法壓縮頭部胸梆，減少數(shù)據(jù)傳輸量
4. 允許服務(wù)器主動向客戶端推送數(shù)據(jù)
5. 增強(qiáng)了安全性敦捧，要求加密通信

1.5 HTTP/3.0（2018 年進(jìn)入標(biāo)準(zhǔn)化制定階段）

基于 GOOGLE 的 QUIC 協(xié)議而來须板。

2. 什么是 HTTP

2.1 HTTP 解釋

HTTP（Hyper Text Transfer Protocol）：超文本傳輸協(xié)議，從字面上來看兢卵，用來傳輸超文本的一個協(xié)議逼纸。

詳細(xì)說明

HTTP 是一個計算機(jī)世界里專門用來在兩點(diǎn)之間傳輸文字、圖片济蝉、音頻纱意、視頻等超文本數(shù)據(jù)的約定和規(guī)范缕碎。

協(xié)議的特點(diǎn)

1. 協(xié)議必須要有兩個或以上的參與者胰舆，也就是“協(xié)”
2. 協(xié)議是對參與者的一種行為約束和規(guī)范坡垫，也就是“議”

2.2 HTTP 的特點(diǎn)

1. HTTP 使用計算機(jī)能夠理解的語言確立了計算機(jī)之間交流通信規(guī)范琅拌，以及相關(guān)的各種控制和錯誤處理方式
2. HTTP 是一個計算機(jī)世界里專門用來在兩點(diǎn)之間傳輸數(shù)據(jù)的約定和規(guī)范
3. HTTP 可以傳輸各種類型的資源阔加，如：圖片姑荷、音頻街望、視頻等

3. HTTP 應(yīng)用之 CDN 加速

3.1 互聯(lián)網(wǎng)（Internet）和 HTTP 的關(guān)系

HTTP 所對應(yīng)的 WWW（萬維網(wǎng)）服務(wù)只是互聯(lián)網(wǎng)的一個“子集”糜俗。除了 WWW 服務(wù)之外踱稍，還是 SMTP/POP3 電子郵件、FTP 文件下載悠抹、SSH 安全登錄等多種服務(wù)珠月，共同構(gòu)成了今天的互聯(lián)網(wǎng)。

3.2 CDN

CDN（Content Delivery Network）中文名稱為“內(nèi)容分發(fā)網(wǎng)絡(luò)”楔敌，它應(yīng)用了 HTTP 協(xié)議里的緩存和代理技術(shù)啤挎，作用是：代替源站響應(yīng)客戶端的請求。

好處

1. 為源站分?jǐn)傉埱筇幚?/li>
2. 尋找離用戶最近節(jié)點(diǎn)卵凑，大幅縮短響應(yīng)時間

局限

CDN 無法緩存由 PHP庆聘、JAVA 等后臺服務(wù)生成的頁面，只能從目標(biāo)網(wǎng)絡(luò)獲取勺卢。

4. 常見協(xié)議與 HTTP 的關(guān)系

4.1 TCP/IP

TCP/IP 是一系列協(xié)議的統(tǒng)稱伙判，其中最核心有就是 TCP 和 IP 協(xié)議。除此之外黑忱，還有 UDP宴抚、ICMP、ARP 等等杨何，共同構(gòu)建了一個復(fù)雜蛤有層次的協(xié)議棧酱塔。

IP 協(xié)議

主要目的是解決尋址和路由問題，以及在兩點(diǎn)之間傳輸數(shù)據(jù)包危虱。V6 版本的地址協(xié)議使用 8 組“:”分隔的十六進(jìn)制數(shù)作為地址羊娃，其容量為 2^128 次方。

TCP 協(xié)議

TCP（Transfer Control Protocol）協(xié)議：傳輸控制協(xié)議埃跷，它位于 IP 協(xié)議之上蕊玷，基于 IP 協(xié)議提供可靠的邮利、字節(jié)流形式的通信，是 HTTP 協(xié)議實現(xiàn)的基礎(chǔ)垃帅。

4.2 DNS

有了 IP 地址延届，還要 DNS 做什么？

由于 IP 地址不方便人類的記憶贸诚，于是方庭，使用 DNS 技術(shù)，通過有意義的字母或數(shù)字來代替無意義的 IP 地址來方便人類記憶酱固。

在訪問過程中械念，先將域名解析成 IP 地址，然后再進(jìn)行數(shù)據(jù)的傳輸运悲。

4.3 URI/URL

URI（Uniform Resource Identifier）：中文名稱統(tǒng)一資源標(biāo)識符龄减，用它來唯一地標(biāo)記互聯(lián)網(wǎng)上的資源。

URL（Uniform Resource Locator）:中文名稱統(tǒng)一資源定位符班眯，其是 URI 的一個子集希停。

4.4 HTTPS

HTTPS：是一個負(fù)責(zé)加密通信的安全協(xié)議，建立在 TCP/IP 之上署隘，所以也是可靠的傳輸協(xié)議宠能。

SSL（Secure Socket Layer）：由網(wǎng)景公司開發(fā)。
TLS(Transfer Layer Security)：SSL 發(fā)展到標(biāo)準(zhǔn)化后改名為 TLS定踱。

4.5 代理

代理（Proxy）:是 HTTP 協(xié)議中請求方和響應(yīng)方中間的一個環(huán)節(jié)棍潘，作為“中轉(zhuǎn)站”，即可以轉(zhuǎn)發(fā)客戶端的請求崖媚，也可以轉(zhuǎn)發(fā)服務(wù)器的應(yīng)答亦歉。

代理的種類

1. 匿名代理：完全“隱匿”了被代理的機(jī)器，外界看到的只是代理服務(wù)器
2. 透明代理：它在傳輸過程中是“透明開放”的畅哑，外界既知道代理肴楷，也知道客戶端
3. 正向代理：代替客戶端向服務(wù)端發(fā)送請求
4. 反向代理：代替服務(wù)器響應(yīng)客戶端的請求

基于代理的服務(wù)

1. 負(fù)載均衡：把訪問請求均勻分散到多臺機(jī)器，實現(xiàn)訪問集群化
2. 內(nèi)容緩存：類似 CDN荠呐，緩存數(shù)據(jù)赛蔫，減輕服務(wù)器壓力
3. 安全防護(hù)：隱匿 IP，使用 WAF 等工具抵御網(wǎng)絡(luò)攻擊泥张，保護(hù)代理服務(wù)器
4. 數(shù)據(jù)處理：數(shù)據(jù)壓縮呵恢，加密等額外功能

5. TCP/IP 和 ISO 協(xié)議棧

5.1 TCP/IP 協(xié)議棧

image

鏈路層：負(fù)責(zé)在以太網(wǎng)、WIFI 這樣的底層網(wǎng)絡(luò)中傳輸原始數(shù)據(jù)包媚创，工作在網(wǎng)卡這個層次渗钉，使用 MAC 地址來標(biāo)記網(wǎng)絡(luò)上的設(shè)備。

網(wǎng)際層/網(wǎng)絡(luò)互聯(lián)層：用 IP 地址取代 MAC 地址，把許多局域網(wǎng)鳄橘、廣域網(wǎng)連接成一個虛擬的巨大網(wǎng)絡(luò)声离。

傳輸層：保證數(shù)據(jù)在由 IP 地址標(biāo)記的兩點(diǎn)之間“可靠”傳輸。在這一層工作的主要是 TCP 和 UDP瘫怜。TCP 是有狀態(tài)的協(xié)議术徊，需要通過三次握手與對方建立連接后，才能發(fā)送數(shù)據(jù)鲸湃，從而保證數(shù)據(jù)不丟失赠涮，不重復(fù)。而 UDP 是無狀態(tài)的暗挑，不用事先連接世囊，也不保證數(shù)據(jù)一定發(fā)送給對方。TCP 的數(shù)據(jù)是連續(xù)的“字節(jié)流”窿祥，有先后順序；而 UDP 則是分散的小數(shù)據(jù)包蝙寨，是順序發(fā)晒衩，亂序收。

應(yīng)用層：面向具體應(yīng)用的協(xié)議墙歪。如：Telnet听系、SSH、FTP虹菲、SMTP/POP 等

各層數(shù)據(jù)包的區(qū)分

1. MAC 層的傳輸單位是幀（frame）
2. IP 層傳輸單位是包（Package）
3. TCP 層傳輸單位是段（segment）
4. HTTP 層傳輸單位是消息或報文（message）

這幾種無本質(zhì)區(qū)別靠胜，都是數(shù)據(jù)包。

TCP毕源、UDP 數(shù)據(jù)包的區(qū)別

TCP 建立連接后浪漠，數(shù)據(jù)在該連接上流動，可以是雙向的霎褐，沒有邊界址愿。而 UDP 是以獨(dú)立的數(shù)據(jù)包來發(fā)送數(shù)據(jù)，每個包中都包含源 IP 地址和目標(biāo) IP 地址冻璃。

5.2 OSI（網(wǎng)絡(luò)分層模型）

image

全稱為：開放式系統(tǒng)互聯(lián)通信參考模型响谓。這個是 ISO 標(biāo)準(zhǔn)化組織為了統(tǒng)一各網(wǎng)絡(luò)協(xié)議而制定出來的。比 TCP/IP 要晚省艳，而且只是停留在理論層面上娘纷。事實上，互聯(lián)網(wǎng)上應(yīng)用的還是 TCP/IP 這一套協(xié)議棧跋炕。

物理層：網(wǎng)絡(luò)的物理形式赖晶，如：光纜、網(wǎng)卡等

數(shù)據(jù)鏈路層：相當(dāng)于 TCP/IP 的鏈接層

網(wǎng)絡(luò)層：相當(dāng)于 TCP/IP 的網(wǎng)際層

傳輸層：相當(dāng)于 TCP/IP 的傳輸層

會話層：維護(hù)網(wǎng)絡(luò)中的連接狀態(tài)枣购，保持會話和狀態(tài)

表示層：把數(shù)據(jù)轉(zhuǎn)換為合適嬉探，可以理解的語法和語義

應(yīng)用層：面向具體的應(yīng)用傳輸數(shù)據(jù)

5.3 OSI 和 TCP/IP 的映射關(guān)系

image

四層負(fù)載均衡

是指工作在傳輸層上擦耀，基于 TCP/IP 協(xié)議的特性，通過 IP涩堤、端口號等實現(xiàn)對后端服務(wù)器的負(fù)載均衡眷蜓。

七層負(fù)載均衡

是指工作在應(yīng)用層上，看到的是 HTTP 協(xié)議胎围，解析 HTTP 報文里的 URI吁系，再用適當(dāng)?shù)牟呗赞D(zhuǎn)發(fā)給后端服務(wù)器。

TCP/IP 數(shù)據(jù)包流轉(zhuǎn)圖

image

6. DNS

6.1 DNS 三層系統(tǒng)結(jié)構(gòu)

image

1. 根域名服務(wù)器（Root DNS Server）：管理頂級域名服務(wù)器白魂，返回 .com汽纤、.cn 等頂級域名服務(wù)器的 IP 地址
2. 頂級域名服務(wù)器（Top-level DNS Server）：管理各自域名下的權(quán)威域名服務(wù)器，比如：com 頂級域名服務(wù)器可以返回 baidu.com 域名服務(wù)器的 IP 地址
3. 權(quán)威域名服務(wù)器（Authoritative DNS Server）：管理自己域名下主機(jī)的 IP 地址福荸，比如：badu.com 權(quán)威域名服務(wù)器可以返回 www.baidu.com 的 IP 地址

6.2 如何保證 DNS 的服務(wù)穩(wěn)定運(yùn)行

1. 緩存

瀏覽器緩存 -> 操作系統(tǒng)緩存 -> 本地 hosts 文件 -> 非權(quán)威服務(wù)器緩存 -> 根域名服務(wù)器緩存 -> 頂級域名服務(wù)器緩存 -> 權(quán)威域名服務(wù)器緩存

6.3 基于 DNS 的負(fù)載均衡

1. 一個域名可以對應(yīng)多臺主機(jī)蕴坪，客戶端收到多個 IP 地址后，就可以自己使用輪詢算法依次向服務(wù)器發(fā)起請求敬锐，實現(xiàn)負(fù)載均衡背传。也就是通過客戶端來實現(xiàn)負(fù)載均衡
2. 域名解析可以配置內(nèi)部的策略，返回離客戶端最近的主機(jī)台夺，或者返回當(dāng)前服務(wù)質(zhì)量最好的主機(jī)径玖，這樣在 DNS 服務(wù)端把請求分發(fā)到不同的服務(wù)器，實現(xiàn)負(fù)載均衡

6.4 惡意 DNS 服務(wù)器

1. 域名屏蔽：對域名直接不解析颤介，返回錯誤梳星，讓你無法拿到 IP 地址
2. 域名劫持：也叫“域名污染”，你要訪問 A 網(wǎng)站滚朵，但 DNS 給了你 B 網(wǎng)站

7. 一次 HTTP 請求的全過程

image

1. 先進(jìn)行 TCP 三次握手冤灾，建立連接

瀏覽器使用 52085，服務(wù)器使用 80 端口辕近，經(jīng)過 SYN瞳购、SYN/ACK、ACK 的三個包之后亏推，瀏覽器與服務(wù)器的 TCP 連接就建立起來了学赛。

2. 瀏覽器發(fā)送 HTTP 請求報文

通過 TCP 連接發(fā)送了一個 GET / HTTP/1.1 請求報文。

3. 服務(wù)器收到請求后吞杭，立即回復(fù) TCP ACK 確認(rèn)已收到請求

上圖中的第 5 個包盏浇，通過 TCP 協(xié)議層確認(rèn)收到瀏覽器發(fā)過來的請求，這個 TCP 層的響應(yīng)是不會傳遞到上層的芽狗。

4. 服務(wù)器對請求進(jìn)行處理绢掰，通過 HTTP 報文格式進(jìn)行響應(yīng)

上圖中的第 6 個包。

5. 瀏覽器接收到服務(wù)器響應(yīng)后，立即回復(fù) TCP ACK 確認(rèn)滴劲，表示已經(jīng)收到這個響應(yīng)了

上圖中的第 7 個包攻晒。

6. 瀏覽器通過調(diào)用排版引擎，JS 引擎等對服務(wù)器的響應(yīng)進(jìn)行渲染

第 8 ~ 11 這 4 個包是瀏覽器在渲染 JS 的過程中班挖，發(fā)現(xiàn)當(dāng)前頁面需要加載 favicon.ico 這個資源鲁捏，所以，又發(fā)送 HTTP 請求到服務(wù)器獲取相應(yīng)資源萧芙，而服務(wù)器上沒有該資源给梅，所以，返回了 Not Found双揪。

7.1 通信交互圖

image

8. HTTP 報文

8.1 HTTP 報文結(jié)構(gòu)

image

HTTP 協(xié)議規(guī)定动羽，必須要有 Header，而且 Header 后跟必須有一個空行（CRLF）,但是實體部分不是必須的渔期。

請求行

image

請求方法：是一個動詞运吓，表示對資源的動作。
請求目標(biāo)：通常是一個 URI疯趟，標(biāo)記請求方法要操作的資源羽德。
版本號：表示報文使用的 HTTP 版本。

中間用“空格”隔開迅办，并通過“CRLF”換行表示結(jié)束。

狀態(tài)行

image

版本號：表示 HTTP 使用的協(xié)議版本章蚣。
狀態(tài)碼：一個三位數(shù)站欺，用代碼的形式表示處理的結(jié)果。
原因：狀態(tài)碼的文字描述纤垂。

頭部字段

請求行或狀態(tài)行再加上頭部字段集合就構(gòu)成了 HTTP 報文里完整的請求頭或響應(yīng)頭矾策。也就是：

請求頭或響應(yīng)頭 = 請求行或響應(yīng)行 + 頭部字段組成。

請求頭或響應(yīng)頭的結(jié)構(gòu)

image

HTTP 請求頭里唯一必須出現(xiàn)的字段

Host: www.baidu.com

Host 字段告訴服務(wù)器請求應(yīng)該由哪個服務(wù)器處理峭沦，當(dāng)一臺計算機(jī)中托管了多個虛擬主機(jī)時贾虽，服務(wù)器端就需要使用 Host 字段來選擇轉(zhuǎn)發(fā)給哪一個虛擬主機(jī)。

主要用于區(qū)分 IP 地址相同但域名不同的網(wǎng)站吼鱼。

Content-lengh 和 chunked

Content-lengh：用來表示實體 body 數(shù)據(jù)長度蓬豁。如果沒有這個字段的話，說明實體字段是不定長的菇肃，需要使用 chunked 方法分段傳輸地粪。

8.2 HTTP GET 請求報文

image

9. 使用 Telnet 測試 HTTP 通信過程的方法

image

1. 運(yùn)行 telnet 工具
2. 輸入 open + 域名 + 端口號

10. 請求方法

10.1 請求方法種類

1. GET：獲取資源，讀取或者下載數(shù)據(jù)
2. HEAD：獲取資源的元信息琐谤，也就是只有響應(yīng)頭蟆技，而沒有實體 body。比如：檢查文件是否存在；檢查文件是否有新版本等操作
3. POST：向資源提交信息质礼，相當(dāng)于寫入或上傳數(shù)據(jù)旺聚，數(shù)據(jù)放在報文的實體 body 里，相比于 PUT眶蕉，POST 常常有“新建”的含義
4. PUT：類似 POST砰粹，相比于 POST，PUT 常常有“修改”的含義
5. DELETE：刪除資源
6. CONNECT：建立特殊的連接隧道妻坝，要求服務(wù)器為客戶端和另一臺遠(yuǎn)程服務(wù)器建立一條特殊的連接隧道伸眶，此時，WEB 服務(wù)器充當(dāng)“代理”角色
7. OPTIONS：列出對資源實行的方法
8. TRACE：追蹤請求/響應(yīng)的傳輸路徑

10.2 安全和冪等

HTTP 中的安全

在 HTTP 協(xié)議里的安全指的是：請求方不會“破壞”服務(wù)器上的資源刽宪，即不會對服務(wù)器上的資源造成實質(zhì)的修改厘贼。所以，只有 GET 和 HHEAD 操作是安全的圣拄。

而 POST/PUT/DELETE 這幾個請求方法是不安全的嘴秸。

HTTP 中的冪等

所謂“冪等”就是多次執(zhí)行相同的操作，結(jié)果也都是相同的庇谆，即多次“冪”之后“相等”岳掐。

同樣的，GET 和 HEAD 請求方法即是安全的也是冪等的饭耳，DELETE 可以多次刪除同一個資源串述，效果都是“資源不存在”，所以也是冪等的寞肖。

POST 的定義是“新增或提交數(shù)據(jù)”纲酗，多次提交會創(chuàng)建多個資源，所以不是冪等的新蟆；而 PUT 的定義是“替換或更新數(shù)據(jù)”觅赊，多次更新一個資源，所以是冪等的琼稻。

說明

此文是根據(jù)羅劍鋒透視 HTTP 協(xié)議相關(guān)專欄內(nèi)容整理而來吮螺，非原創(chuàng)。