目錄
HTTP協(xié)議是很基礎(chǔ)但又很容易被忽略的知識(shí)瑞凑。本篇文章整理了HTTP協(xié)議相關(guān)的基礎(chǔ)知識(shí)點(diǎn),適合入門學(xué)習(xí)的同學(xué)末秃。
網(wǎng)絡(luò)基礎(chǔ)
計(jì)算機(jī)網(wǎng)絡(luò)協(xié)十分復(fù)雜，為了讓復(fù)雜的網(wǎng)絡(luò)簡(jiǎn)單化籽御，專家們對(duì)網(wǎng)絡(luò)協(xié)議進(jìn)行了分層练慕。
常見(jiàn)的兩種分層方式：
-
OSI模型 -
TCP/IP協(xié)議
OSI 模型
OSI模型（Open System Interconnection,OSI/RM,Open Systems Interconnection Reference Model）惰匙，即開(kāi)放式通信系統(tǒng)互聯(lián)參考模型，是國(guó)際標(biāo)準(zhǔn)化組織(ISO)提出的一個(gè)試圖使各種計(jì)算機(jī)在世界范圍內(nèi)互連為網(wǎng)絡(luò)的標(biāo)準(zhǔn)框架铃将。
OSI將[計(jì)算機(jī)網(wǎng)絡(luò)體系結(jié)構(gòu)(architecture）劃分為以下七層：
| 分層 | 每層的操作 |
|---|---|
| 應(yīng)用層 | 在數(shù)據(jù)前面加首部项鬼，首部包括數(shù)據(jù)內(nèi)容、源地址和目標(biāo)地址劲阎，同時(shí)也會(huì)處理異常的反饋信息绘盟。 |
| 表示層 | 將特有的數(shù)據(jù)格式轉(zhuǎn)換為通用的數(shù)據(jù)格式，同時(shí)也會(huì)加上表示層的首部信息以供解析悯仙。 |
| 會(huì)話層 | 對(duì)何時(shí)連接龄毡，以何種方式連接，連接多久锡垄，何時(shí)斷開(kāi)等做記錄沦零。同時(shí)也會(huì)加會(huì)話層的首部信息。 |
| 傳輸層 | 建立連接货岭，斷開(kāi)連接路操，確認(rèn)數(shù)據(jù)是否發(fā)送成功和執(zhí)行失敗重發(fā)任務(wù)。 |
| 網(wǎng)絡(luò)層 | 負(fù)責(zé)將數(shù)據(jù)發(fā)到目標(biāo)地址千贯，也包含首部信息屯仗。 |
| 數(shù)據(jù)鏈路層 | 通過(guò)物理的傳輸介質(zhì)實(shí)現(xiàn)數(shù)據(jù)的傳輸。 |
| 物理層 | 將0/1轉(zhuǎn)換成物理的傳輸介質(zhì)搔谴，通過(guò)MAC地址進(jìn)行傳輸魁袜。 |
TCP/IP 協(xié)議
TCP/IP協(xié)議（Transmission Control Protocol/Internet Protocol），即傳輸控制協(xié)議因特網(wǎng)互聯(lián)協(xié)議己沛，又名網(wǎng)絡(luò)通訊協(xié)議慌核，是Internet最基本的協(xié)議、Internet國(guó)際互聯(lián)網(wǎng)絡(luò)的基礎(chǔ)申尼，由網(wǎng)絡(luò)層的IP協(xié)議和傳輸層的TCP協(xié)議組成垮卓。TCP/IP 定義了電子設(shè)備如何連入因特網(wǎng)，以及數(shù)據(jù)如何在它們之間傳輸?shù)臉?biāo)準(zhǔn)师幕。
TCP/IP 四層結(jié)構(gòu)
| 分層 | 每層的操作 |
|---|---|
| 應(yīng)用層 | 提供應(yīng)用服務(wù)粟按。協(xié)議：HTTP，F(xiàn)TP霹粥，SSH |
| 傳輸層 | 讓?xiě)?yīng)用程序之間實(shí)現(xiàn)通信灭将。協(xié)議：TCP，UDP |
| 網(wǎng)絡(luò)層 | 該層核心是IP協(xié)議后控，基于IP地址轉(zhuǎn)發(fā)數(shù)據(jù)包庙曙。 |
| 鏈路層 | 負(fù)責(zé)接收IP數(shù)據(jù)包并通過(guò)網(wǎng)絡(luò)發(fā)送，或者從網(wǎng)絡(luò)上接收物理幀浩淘，抽出IP數(shù)據(jù)包捌朴，交給網(wǎng)絡(luò)層 |
OSI模型與TCP/IP協(xié)議關(guān)系
上圖列出了OSI與TCP/IP分層之間的大致關(guān)系吴攒。可以看出砂蔽，OSI與TCP/IP在分層模塊上稍有區(qū)別洼怔，OSI參考模型注重通信協(xié)議必要的功能是什么，而TCP/IP更強(qiáng)調(diào)在計(jì)算機(jī)上實(shí)現(xiàn)協(xié)議應(yīng)該開(kāi)發(fā)哪種程序左驾。
OSI參考模型并沒(méi)有得到普及镣隶。TCP/IP協(xié)議被廣泛應(yīng)用，今天主角HTTP屬于TCP/IP協(xié)議诡右。
HTTP介紹
HTTP（HyperText Transfer Protocol, 超文本傳輸協(xié)議）是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議安岂。HTTP 協(xié)議是 TCP/IP 協(xié)議模型的子集，屬于應(yīng)用層協(xié)議稻爬。
客戶端與服務(wù)端通信流程
HTTP協(xié)議和TCP/IP協(xié)議族內(nèi)的其他眾多協(xié)議相同嗜闻，用于客戶端與服務(wù)端之間通信。
請(qǐng)求訪問(wèn)文本或圖片資源的一端成為客戶端桅锄，提供資源響應(yīng)的一端為服務(wù)端。
上圖為客戶端與服務(wù)端交互的流程样眠∮蚜觯客戶端發(fā)送請(qǐng)求信息，服務(wù)端返回響應(yīng)信息檐束，一來(lái)一回完成了一次HTTP通信辫秧。
使用Cookie、Session管理狀態(tài)
HTTP協(xié)議是無(wú)狀態(tài)的被丧，它不會(huì)記錄之前請(qǐng)求的狀態(tài)盟戏。比如，第一次和服務(wù)器交互登錄成功后甥桂，第二次發(fā)送請(qǐng)求服務(wù)器仍然不知道這是哪個(gè)用戶柿究。Cookie和Session出現(xiàn)就是為了解決這個(gè)問(wèn)題。
Cookie
第一次和服務(wù)器交互登錄成功后黄选，服務(wù)器會(huì)把用戶的標(biāo)識(shí)存到Cookie中返回給瀏覽器蝇摸。第二次請(qǐng)求，客戶端帶上Cookie發(fā)送給服務(wù)端办陷，服務(wù)端收到Cookie就知道是哪個(gè)用戶請(qǐng)求了貌夕。
Cookie儲(chǔ)存在客戶端，不同瀏覽器對(duì)儲(chǔ)存大小有不同限制民镜，一般不超過(guò)4KB啡专。因此Cookie適合儲(chǔ)存少量數(shù)據(jù)。
Session
Session和Cookie的作用類似制圈，都可以做用戶的狀態(tài)管理们童。Session儲(chǔ)存在服務(wù)端辱揭，儲(chǔ)存的大小和數(shù)據(jù)形式不受限制。
Cookie和Session兩者的區(qū)別在本文常見(jiàn)問(wèn)題小節(jié)病附。
HTTP報(bào)文結(jié)構(gòu)
客戶端和服務(wù)端之間交互的信息被稱為HTTP報(bào)文问窃。客戶端的HTTP報(bào)文叫做請(qǐng)求報(bào)文完沪，服務(wù)端的叫做響應(yīng)報(bào)文域庇。
HTTP 報(bào)文本身是由多行（用 CR+LF 作換行符）數(shù)據(jù)構(gòu)成的字符串文本。
下面兩段代碼是真實(shí)的報(bào)文數(shù)據(jù)覆积，先看一下真實(shí)報(bào)文听皿，理解報(bào)文結(jié)構(gòu)會(huì)容易一些。
GET / HTTP/1.1
Host: www.lizhengyang.cn
Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.75 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Cookie: SESSION=t20l97i9pgi9kosj5t9cbil3nm
HTTP/1.1 200 OK
Server: nginx
Date: Mon, 10 Sep 2018 07:19:49 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
X-Powered-By: blade-2.0.6-BETA
Content-Encoding: gzip
<!DOCTYPE html>
<html>
//此處省略具體HTML數(shù)據(jù)
</html>
這里的報(bào)文數(shù)據(jù)是抓包拿來(lái)的宽档，具體怎樣抓取HTTP報(bào)文請(qǐng)看另一篇文章：【網(wǎng)絡(luò)學(xué)習(xí)筆記】使用Wireshark抓取HTTP報(bào)文
請(qǐng)求報(bào)文
請(qǐng)求行
請(qǐng)求行包括：請(qǐng)求方法诅迷、URI、HTTP協(xié)議版本
請(qǐng)求方法
| 名稱 | 描述 | 最低支持協(xié)議版本 |
|---|---|---|
| GET | 請(qǐng)求服務(wù)器上的某一資源芬迄。 | 1.0 |
| POST | 向指定資源提交數(shù)據(jù)進(jìn)行處理請(qǐng)求,數(shù)據(jù)包含在請(qǐng)求體中嘲碧。 | 1.0 |
| HEAD | 用于確認(rèn)URI的有效性及資源更新的日期時(shí)間，不返回報(bào)文主體椎瘟，只返回報(bào)文文首部覆致。 | 1.0 |
| PUT | 向用來(lái)傳輸文件，將文件內(nèi)容放進(jìn)報(bào)文主體中肺蔚，保存到URI指定位置上煌妈。 | 1.1 |
| DELETE | 與PUT相反，請(qǐng)求URI刪除指定資源宣羊。 | 1.1 |
| OPTIONS | 查詢針對(duì)請(qǐng)求URI指定的資源支持的方法璧诵。 | 1.1 |
| TRACE | 用于追蹤路徑。發(fā)送請(qǐng)求時(shí)仇冯，首部字段Max-Forwards會(huì)指定一個(gè)數(shù)值之宿，每經(jīng)過(guò)一個(gè)服務(wù)器之后，該數(shù)值減1赞枕。當(dāng)該數(shù)值為0時(shí)澈缺，停止傳輸，最后接收到的服務(wù)器響應(yīng)炕婶。 | 1.1 |
| CONNECT | 用于在與代理服務(wù)器通信時(shí)建立隧道姐赡，實(shí)現(xiàn)用隧道協(xié)議進(jìn)行TCP通信。 | 1.1 |
GET和POST方法在工作中比較常用柠掂。
GET：
- 常用來(lái)查詢數(shù)據(jù)
- 請(qǐng)求參數(shù)包含在URL里面
- 在瀏覽器中對(duì)請(qǐng)求參數(shù)有長(zhǎng)度限制
POST:
- 常用來(lái)提交數(shù)據(jù)
- 請(qǐng)求參數(shù)在請(qǐng)求體中
- 對(duì)參數(shù)大小沒(méi)有長(zhǎng)度限制
POST比GET更安全项滑？
- 在瀏覽器中訪問(wèn)網(wǎng)址發(fā)送GET請(qǐng)求，請(qǐng)求參數(shù)會(huì)附加在網(wǎng)址后面很容被別人看見(jiàn)涯贞。POST請(qǐng)求不會(huì)把明文參數(shù)顯示在地址中枪狂。從這方面來(lái)砍GET比POST安全危喉。
- 如果HTTP請(qǐng)求不配置HTTPS證書(shū)，不管是POST請(qǐng)求還是GET請(qǐng)求州疾，所有的參數(shù)都會(huì)明文在網(wǎng)絡(luò)上傳輸辜限，容易被別人查看甚至篡改。從整體來(lái)看严蓖，不配置安全證書(shū)薄嫡，POST和GET請(qǐng)求都是不安全的。
URI
URI（Uniform Resource Identifier）統(tǒng)一資源標(biāo)識(shí)符颗胡，用來(lái)標(biāo)識(shí)某一互聯(lián)網(wǎng)資源名稱毫深。URI和URL長(zhǎng)得很像，容易混淆毒姨，在本文最后常見(jiàn)問(wèn)題中有兩者的差別哑蔫。
HTTP協(xié)議版本
HTTP主要有三個(gè)大版本：HTTP/1.0、HTTP/1.1弧呐、HTTP/2.0 闸迷。在本文最后常見(jiàn)問(wèn)題中有版本差異的講解。
請(qǐng)求頭
請(qǐng)求頭由多個(gè)鍵值對(duì)組成泉懦，如：
Host: www.lizhengyang.cn
Connection: keep-alive
這些鍵值被稱為首部字段稿黍。具體首部字段內(nèi)容請(qǐng)查看本文HTTP首部字段詳解小節(jié)
空行
HTTP報(bào)文中把第一個(gè)出現(xiàn)的空行當(dāng)做分隔符，空行下面就是報(bào)文主體崩哩。
請(qǐng)求報(bào)文主體
使用POST方法提交的數(shù)據(jù)必須放在報(bào)文主體中，協(xié)議沒(méi)有規(guī)定提交的數(shù)據(jù)使用什么傳輸格式言沐，實(shí)際開(kāi)發(fā)中客戶端和服務(wù)端可以自己決定傳輸?shù)母袷健?/p>
常見(jiàn)的傳輸格式：
- application/x-www-form-urlencoded
這應(yīng)該是最常見(jiàn)的POST數(shù)據(jù)傳輸格式了邓嘹。數(shù)據(jù)格式為“KEY=VALUE”鍵值對(duì)，多組數(shù)據(jù)中間用“&”符號(hào)連接险胰。請(qǐng)求報(bào)文如下：
//刪減了無(wú)關(guān)信息
POST http://lizhengyang.cn HTTP/1.1
Content-Type: application/x-www-form-urlencoded;charset=utf-8
title=你好&code=008
注意請(qǐng)求頭字段Content-Type的值為application/x-www-form-urlencoded
-
application/json
傳輸JSON格式的數(shù)據(jù)汹押，請(qǐng)求報(bào)文如下：
//刪減了無(wú)關(guān)信息 POST http://lizhengyang.cn HTTP/1.1 Content-Type:application/json;charset=utf-8 {"title":"你好","code":80}
注意請(qǐng)求頭字段Content-Type的值為application/json
響應(yīng)報(bào)文
狀態(tài)行
狀態(tài)行包括：HTTP協(xié)議版本、狀態(tài)碼起便、狀態(tài)碼描述
狀態(tài)碼類型
| 類別 | 原因短語(yǔ) | |
|---|---|---|
| 1XX | Informational（信息性狀態(tài)碼） | 接收的請(qǐng)求正在處理 |
| 2XX | Success（成功狀態(tài)碼） | 請(qǐng)求正常處理完畢 |
| 3XX | Redirection（重定向狀態(tài)碼） | 需要進(jìn)行附加操作以完成請(qǐng)求 |
| 4XX | Client Error（客戶端錯(cuò)誤狀態(tài)碼） | 服務(wù)器無(wú)法處理請(qǐng)求 |
| 5XX | Server Error（服務(wù)器錯(cuò)誤狀態(tài)碼） | 服務(wù)器處理請(qǐng)求出錯(cuò) |
常見(jiàn)的狀態(tài)碼
| 狀態(tài)碼 | 描述 |
|---|---|
| 200 OK | 請(qǐng)求成功 |
| 304 Not Modified | 所請(qǐng)求的資源未修改棚贾，服務(wù)器不會(huì)返回任何資源∮茏郏客戶端通常會(huì)緩存訪問(wèn)過(guò)的資源妙痹，通過(guò)提供一個(gè)頭信息指出客戶端希望只返回在指定日期之后修改的資源 |
| 403 Forbidden | 服務(wù)器理解請(qǐng)求客戶端的請(qǐng)求，但是拒絕執(zhí)行此請(qǐng)求 |
| 404 Not Found | 服務(wù)器無(wú)法根據(jù)客戶端的請(qǐng)求找到資源 |
| 500 Internal Server Error | 服務(wù)器內(nèi)部錯(cuò)誤鼻疮，無(wú)法完成請(qǐng)求 |
響應(yīng)頭
格式同請(qǐng)求頭怯伊。
空行
作用同請(qǐng)求報(bào)文中空行。
響應(yīng)報(bào)文主體
常用的傳輸格式除了請(qǐng)求報(bào)文主體中的兩種格式外判沟，還有text/html耿芹，HTML網(wǎng)頁(yè)就是采用的這種格式
HTTP首部字段詳解
HTTP首部字段根據(jù)實(shí)際用途為三種類型：
- 通用首部字段崭篡。請(qǐng)求報(bào)文和響應(yīng)報(bào)文兩方都會(huì)使用的首部
- 請(qǐng)求首部字段。從客戶端向服務(wù)器端發(fā)送請(qǐng)求報(bào)文時(shí)使用的首部吧秕。
- 響應(yīng)首部字段琉闪。從服務(wù)器端向客戶端返回響應(yīng)報(bào)文時(shí)使用的首部。
- 實(shí)體首部字段砸彬。針對(duì)請(qǐng)求報(bào)文和響應(yīng)報(bào)文的實(shí)體部分使用的首部
另外還有一些拓展首部字段颠毙，沒(méi)有在HTTP/1.1中定義，但使用頻率很高拿霉。比如：Cookie吟秩、Set-Cookie等字段。
通用首部字段
請(qǐng)求首部字段
響應(yīng)首部字段
實(shí)體首部字段
拓展首部字段
Set-Cookie
用來(lái)由服務(wù)器端向客戶端發(fā)送cookie
Set-Cookie: name=zhengyang;Domain=lizhengyang.cn;Path=/;Expires=Mon, 10 Sep 2018 07:19:49 GMT; Secure; HttpOnly
Set-Cookie字段的屬性
| 字段 | 屬性 |
|---|---|
| NAME=VALUE | 賦予 Cookie 的名稱和其值（必須項(xiàng)） |
| expires=DATE | 指定瀏覽器可發(fā)送 Cookie 的有效期（若不指定則默認(rèn)為瀏覽器關(guān)閉為止） |
| path=PATH | 將服務(wù)器上的文件目錄作為 Cookie 的適用對(duì)象（若不指定則默認(rèn)為文檔所在的文件目錄） |
| domain=域名 | 作為 Cookie 適用對(duì)象的域名（若不指定則默認(rèn)為創(chuàng)建 Cookie 的服務(wù)器的域名） |
| Secure | 僅在 HTTPS 安全通信時(shí)才會(huì)發(fā)送 Cookie |
| HttpOnly | 加以限制绽淘，使 Cookie 不能被 JavaScript 腳本訪問(wèn)涵防。主要目的是為防止跨站腳本攻擊對(duì) Cookie 的信息竊取。 |
Cookie
客戶端向服務(wù)端發(fā)送緩存的Cookie
Cookie:code=0;id=888;
常見(jiàn)問(wèn)題
uri與url的區(qū)別沪铭？
URI和URL在視覺(jué)上兩者很相似壮池，在含義上兩者同樣很相似，經(jīng)常讓人傻傻分不清楚杀怠。
概念
- URI（Uniform Resource Identifier）統(tǒng)一資源標(biāo)識(shí)符椰憋，用來(lái)標(biāo)識(shí)某一互聯(lián)網(wǎng)資源名稱，強(qiáng)調(diào)資源的名稱赔退。
- URL（Uniform Resource Locator）統(tǒng)一資源定位符橙依，用來(lái)從互聯(lián)網(wǎng)上獲得某一個(gè)資源，強(qiáng)調(diào)資源訪問(wèn)硕旗。
理解
北京市 海淀區(qū) 中關(guān)村 XXX大廈 N層888室 張三 （這是一個(gè)虛擬的收件地址）
- URL對(duì)應(yīng)著整個(gè)收件地址窗骑。通過(guò)收件地址能聯(lián)系到一個(gè)人，通過(guò)URL能訪問(wèn)一個(gè)文件漆枚，是一個(gè)道理创译。
- URI對(duì)應(yīng)著收件人姓名張三。在
北京市 海淀區(qū) 中關(guān)村 XXX大廈 N層888室大喊張三就能找到張三本人墙基，但在河北喊破嗓子也找不到北京市的那個(gè)張三软族。
關(guān)系
URL是URI的子集，所有的URL都是URI残制，但不是所有的URI都是URL立砸。
cookie與session的區(qū)別
| 對(duì)比 | Cookie | Session |
|---|---|---|
| 儲(chǔ)存位置 | 儲(chǔ)存在客戶端 | 儲(chǔ)存在服務(wù)器 |
| 安全性 | 不安全 | 安全 |
| 有效期 | 長(zhǎng) | 短 |
| 對(duì)服務(wù)器壓力 | 小 | 大 |
HTTP/1.1、HTTP/2.0版本特性
在建立 HTTP 標(biāo)準(zhǔn)規(guī)范時(shí)痘拆，制訂者主要想把 HTTP 當(dāng)作傳輸 HTML文檔的協(xié)議仰禽。隨著互聯(lián)網(wǎng)的發(fā)展，web用途更具有多樣性，HTTP也廣泛應(yīng)用到移動(dòng)端吐葵，我們對(duì)HTTP性能的要求也越來(lái)越高规揪。為了適應(yīng)新時(shí)代的要求，HTTP協(xié)議逐漸從1.0版本迭代到了1.1温峭、2.0猛铅。
HTTP/1.1 特性
緩存處理
在HTTP1.0中主要使用header里的If-Modified-Since,Expires來(lái)做為緩存判斷的標(biāo)準(zhǔn)，HTTP1.1則引入了更多的緩存控制策略例如Entity tag凤藏，If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的緩存頭來(lái)控制緩存策略奸忽。
持久連接
HTTP 1.1支持長(zhǎng)連接（PersistentConnection）和請(qǐng)求的流水線（Pipelining）處理，在一個(gè)TCP連接上可以傳送多個(gè)HTTP請(qǐng)求和響應(yīng)揖庄，減少了建立和關(guān)閉連接的消耗和延遲栗菜，在HTTP1.1中默認(rèn)開(kāi)啟Connection： keep-alive，一定程度上彌補(bǔ)了HTTP1.0每次請(qǐng)求都要?jiǎng)?chuàng)建連接的缺點(diǎn)蹄梢。
區(qū)別用一張圖來(lái)體現(xiàn)：
增加Host頭部字段
在HTTP1.0中認(rèn)為每臺(tái)服務(wù)器都綁定一個(gè)唯一的IP地址疙筹，因此，請(qǐng)求消息中的URL并沒(méi)有傳遞主機(jī)名（hostname）禁炒。但隨著虛擬主機(jī)技術(shù)的發(fā)展而咆，在一臺(tái)物理服務(wù)器上可以存在多個(gè)虛擬主機(jī)（Multi-homed Web Servers），并且它們共享一個(gè)IP地址幕袱。HTTP1.1的請(qǐng)求消息和響應(yīng)消息都應(yīng)支持Host頭域暴备，且請(qǐng)求消息中如果沒(méi)有Host頭域會(huì)報(bào)告一個(gè)錯(cuò)誤（400 Bad Request）。
帶寬優(yōu)化及網(wǎng)絡(luò)連接的使用
HTTP1.0中们豌，存在一些浪費(fèi)帶寬的現(xiàn)象涯捻，例如客戶端只是需要某個(gè)對(duì)象的一部分，而服務(wù)器卻將整個(gè)對(duì)象送過(guò)來(lái)了望迎，并且不支持?jǐn)帱c(diǎn)續(xù)傳功能汰瘫，HTTP1.1則在請(qǐng)求頭引入了range頭域，它允許只請(qǐng)求資源的某個(gè)部分擂煞，即返回碼是206（Partial Content），這樣就方便了開(kāi)發(fā)者自由的選擇以便于充分利用帶寬和連接趴乡。
HTTP/2.0 特性
新的二進(jìn)制格式
HTTP1.x的解析是基于文本对省。基于文本協(xié)議的格式解析存在天然缺陷晾捏，文本的表現(xiàn)形式有多樣性蒿涎，要做到健壯性考慮的場(chǎng)景必然很多，二進(jìn)制則不同惦辛，只認(rèn)0和1的組合劳秋。基于這種考慮HTTP2.0的協(xié)議解析決定采用二進(jìn)制格式，實(shí)現(xiàn)方便且健壯玻淑。
多路復(fù)用
即連接共享嗽冒，即每一個(gè)request都是是用作連接共享機(jī)制的。一個(gè)request對(duì)應(yīng)一個(gè)id补履，這樣一個(gè)連接上可以有多個(gè)request添坊，每個(gè)連接的request可以隨機(jī)的混雜在一起，接收方可以根據(jù)request的 id將request再歸屬到各自不同的服務(wù)端請(qǐng)求里面箫锤。
HTTP/2.0與HTTP/1.1區(qū)別
頭部壓縮
HTTP1.x的header帶有大量信息贬蛙，而且每次都要重復(fù)發(fā)送，HTTP2.0使用encoder來(lái)減少需要傳輸?shù)膆eader大小谚攒，通訊雙方各自cache一份header fields表阳准，既避免了重復(fù)header的傳輸，又減小了需要傳輸?shù)拇笮 ?/p>
服務(wù)端推送
HTTP/2.0之前版本馏臭，服務(wù)端總是被動(dòng)的野蝇，客戶端主動(dòng)請(qǐng)求才能返回?cái)?shù)據(jù)。2.0協(xié)議位喂，服務(wù)端可以主動(dòng)向客戶端發(fā)送數(shù)據(jù)浪耘，例如：網(wǎng)頁(yè)有一個(gè)sytle.css的請(qǐng)求，在客戶端收到sytle.css數(shù)據(jù)的同時(shí)塑崖，服務(wù)端會(huì)將sytle.js的文件推送給客戶端七冲，當(dāng)客戶端再次嘗試獲取sytle.js時(shí)就可以直接從緩存中獲取到，不用再發(fā)請(qǐng)求了规婆。
