一、HTTP簡介

Web 使用一種名為 HTTP （ HyperText Transfer Protocol ，超文本傳輸協(xié)議的協(xié)議作為規(guī)范，完成從客戶端到服務(wù)器端等一系列運(yùn)作流程。 HTTP處于計算機(jī)網(wǎng)絡(luò)中的應(yīng)用層，HTTP是建立在TCP協(xié)議之上，所以HTTP協(xié)議的瓶頸及其優(yōu)化技巧都是基于TCP協(xié)議本身的特性，例如tcp建立連接的3次握手和斷開連接的4次揮手以及每次建立連接帶來的RTT延遲時間。HTTP HTTP協(xié)議通常承載于TCP協(xié)議之上，有時也承載于TLS或SSL協(xié)議層之上，這個時候，就成了我們常說的HTTPS。默認(rèn)HTTP的端口號為80，HTTPS的端口號為443。
       

HTTP 是一個屬于應(yīng)用層的面向?qū)ο蟮膮f(xié)議，HTTP 協(xié)議一共有五大特點(diǎn)：1、支持客戶/服務(wù)器模式；2、簡單快速；3、靈活；4、無連接；5、無狀態(tài)。
無連接的含義是限制每次連接只處理一個請求。服務(wù)器處理完客戶的請求并收到客戶的應(yīng)答后即斷開連接。采用這種方式可以節(jié)省傳輸時間，可以盡快將資源釋放出來服務(wù)其他客戶端。HTTP1.1及以后出現(xiàn)了Keep-Alive，它可以使客戶端到服務(wù)器端的連接持續(xù)有效，當(dāng)出現(xiàn)對服務(wù)器的后繼請求時，Keep-Alive 功能避免了建立或者重新建立連接。

無狀態(tài)是指協(xié)議對于事務(wù)處理沒有記憶能力，服務(wù)器不知道客戶端是什么狀態(tài)。即我們給服務(wù)器發(fā)送HTTP請求之后，服務(wù)器根據(jù)請求會給我們發(fā)送數(shù)據(jù)過來，但是發(fā)送完不會記錄任何信息。HTTP協(xié)議這種特性有優(yōu)點(diǎn)也有缺點(diǎn)，優(yōu)點(diǎn)在于解放了服務(wù)器，每一次請求“點(diǎn)到為止”不會造成不必要連接占用，缺點(diǎn)在于每次請求會傳輸大量重復(fù)的內(nèi)容信息。于是兩種用于保持HTTP連接狀態(tài)的技術(shù)就應(yīng)運(yùn)而生了，一個是Cookie另一個是Session。Cookie可以保持登錄信息到用戶下次與服務(wù)器的會話，下次訪問同一網(wǎng)站時，用戶會發(fā)現(xiàn)不必輸入用戶名和密碼就已經(jīng)登錄了。

二、HTTP的報文結(jié)構(gòu)

用于 HTTP 協(xié)議交互的信息被稱為 HTTP 報文。請求端（客戶端）的HTTP 報文叫做請求報文，響應(yīng)端（服務(wù)器端）的叫做響應(yīng)報文。HTTP 報文本身是由多行（用 CR+LF 作換行符）數(shù)據(jù)構(gòu)成的字符串文本。HTTP 報文大致可分為報文首部和報文主體兩塊。兩者由最初出現(xiàn)的空行（ CR+LF ）來劃分。通常并不一定要有報文主體。

HTTP的 請求、響應(yīng) 報文結(jié)構(gòu)：

URI(統(tǒng)一資源標(biāo)識符)和URL(統(tǒng)一資源定位符)
URI：一個用于標(biāo)識某一互聯(lián)網(wǎng)資源名稱的字符串。組成：主機(jī)名(含端口號)+相對路徑+標(biāo)識符
URL：對可以從互聯(lián)網(wǎng)上得到的資源的位置和訪問方法的一種簡潔的表示，是互聯(lián)網(wǎng)上標(biāo)準(zhǔn)資源的地址。組成：協(xié)議+主機(jī)名(含端口號)+相對路徑
區(qū)別：URI表示請求資源在互聯(lián)網(wǎng)上存在的位置，URL在表示請求資源的位置同時還要說明如何訪問到這個資源，URL是URI的一個子集。

如http://www.baidu.com:80/login.jsp  其中https為協(xié)議，/login.jsp 為相對路徑

HTTP的報文頭部類型

1 通用首部字段（ General Header Fields ）請求報文和響應(yīng)報文兩方都會使用的首部。
| 首部字段名 | 說明
| ------------- |:-------------:
| Cache-Control|控制緩存的行為
| Connection|逐跳首部、連接的管理
| Date|創(chuàng)建報文的日期時間
| Pragma|報文指令
| Trailer|報文末端的首部一覽
| Transfer-Encoding|指定報文主體的傳輸編碼方式
| Upgrade|升級為其他協(xié)議
| Via|代理服務(wù)器的相關(guān)信息
| Warning|錯誤通知

2 請求首部字段（ Request Header Fields ）從客戶端向服務(wù)器端發(fā)送請求報文時使用的首部。補(bǔ)充了請求的附加內(nèi)容、客戶端信息、響應(yīng)內(nèi)容相關(guān)優(yōu)先級等信息。

形如 If-xxx 這種樣式的請求首部字段，都可稱為條件請求。服務(wù)器接收到附帶條件的請求后，只有判斷指定條件為真時，才會執(zhí)行請求。

3 響應(yīng)首部字段（ Response Header Fields ）從服務(wù)器端向客戶端返回響應(yīng)報文時使用的首部。補(bǔ)充了響應(yīng)的附加內(nèi)容，也會要求客戶端附加額外的內(nèi)容信息。

4 實(shí)體首部字段（ Entity Header Fields ）針對請求報文和響應(yīng)報文的實(shí)體部分使用的首部。補(bǔ)充了資源內(nèi)容更新時間等與實(shí)體有關(guān)的信息。
| 首部字段名 | 說明
| ------------- |:-------------:
| Allow| 資源可支持的 HTTP 方法
| Content-Encoding| 實(shí)體主體適用的編碼方式
| Content-Language| 實(shí)體主體的自然語言
| Content-Length| 實(shí)體主體的大小（單位：字節(jié)）
| Content-Location| 替代對應(yīng)資源的 URI
| Content-MD5| 實(shí)體主體的報文摘要
| Content-Range| 實(shí)體主體的位置范圍
| Content-Type| 實(shí)體主體的媒體類型
| Expires| 實(shí)體主體過期的日期時間
| Last-Modified| 資源的最后修改日期時間

HTTP方法及狀態(tài)碼

HTTP方法

GET：          請求資源，GET請求可以將參數(shù)放入uri中也可以放入body，但不推薦get將參數(shù)放入body。
POST：       提交資源，POST將數(shù)據(jù)放在在body中 。
PUT:             傳輸文件，替換資源
DELETE:      刪除資源
HEAD：       獲得報文首部
OPTUIONS:  詢問支持的方法
TRACK:        追蹤路徑，回顯服務(wù)器收到的請求，用于測試診斷
CONNECT：要求用隧道協(xié)議連接代理

GET方法和POST方法的區(qū)別：
1）安全性：GET請求的數(shù)據(jù)會附在URL之后，以?分割URL和傳輸數(shù)據(jù)，參數(shù)之間以&相連，參數(shù)將明文出現(xiàn)在URL上，URL信息也可能會被記錄到歷史紀(jì)錄中。POST請求是把提交的數(shù)據(jù)則放置在HTTP包的包體中。
2）數(shù)據(jù)長度：HTTP協(xié)議沒有對傳輸?shù)臄?shù)據(jù)和URL長度進(jìn)行限制， 但特定瀏覽器和服務(wù)器對URL長度有限制， 因此對于GET提交時，傳輸數(shù)據(jù)就會受到URL長度的限制（大部分最多只能有1024字節(jié)）；由于POST操作不是通過URL傳值，理論上數(shù)據(jù)長度不受限；
3）緩存：GET 用于獲取信息，是冪等的，GET請求能夠被緩存,以GET請求的URL能夠保存為瀏覽器書簽，POST 用于修改服務(wù)器上的數(shù)據(jù)，非冪等，POST請求則都不能
4）數(shù)據(jù)獲取：Get是向服務(wù)器發(fā)索取數(shù)據(jù)的一種請求；而Post是向服務(wù)器提交數(shù)據(jù)的一種請求，要提交的數(shù)據(jù)位于信息頭后面的實(shí)體中。

HTTP狀態(tài)碼

1XX informational(信息性狀態(tài)碼) 接收的請求正在處理
100——客戶必須繼續(xù)發(fā)出請求
101——客戶要求服務(wù)器根據(jù)請求轉(zhuǎn)換HTTP協(xié)議版本

2XX Success(成功狀態(tài)碼) 請求正常處理完畢
200——交易成功
201——提示知道新文件的URL
202——接受和處理、但處理未完成
203——返回信息不確定或不完整
204——請求收到，但返回信息為空
205——服務(wù)器完成了請求，用戶代理必須復(fù)位當(dāng)前已經(jīng)瀏覽過的文件
206——服務(wù)器已經(jīng)完成了部分用戶的GET請求

3XX Redirection(重定向狀態(tài)碼) 需要進(jìn)行附加操作已完成請求
300——請求的資源可在多處得到
301——刪除請求數(shù)據(jù)
302——在其他地址發(fā)現(xiàn)了請求數(shù)據(jù)
303——建議客戶訪問其他URL或訪問方式
304——客戶端已經(jīng)執(zhí)行了GET，但文件未變化
305——請求的資源必須從服務(wù)器指定的地址得到
306——前一版本HTTP中使用的代碼，現(xiàn)行版本中不再使用
307——申明請求的資源臨時性刪除

4XX Client Error(客戶端錯誤狀態(tài)碼) 服務(wù)器無法處理請求
400——錯誤請求，如語法錯誤
401——未授權(quán)
402——保留有效ChargeTo頭響應(yīng)
403——禁止訪問
404——沒有發(fā)現(xiàn)文件、查詢或URl
405——用戶在Request-Line字段定義的方法不允許
406——根據(jù)用戶發(fā)送的Accept拖，請求資源不可訪問
407——類似401，用戶必須首先在代理服務(wù)器上得到授權(quán)
408——客戶端沒有在用戶指定的餓時間內(nèi)完成請求
409——對當(dāng)前資源狀態(tài)，請求不能完成
410——服務(wù)器上不再有此資源且無進(jìn)一步的參考地址
411——服務(wù)器拒絕用戶定義的Content-Length屬性請求
412——一個或多個請求頭字段在當(dāng)前請求中錯誤
413——請求的資源大于服務(wù)器允許的大小
414——請求的資源URL長于服務(wù)器允許的長度
415——請求資源不支持請求項目格式
416——請求中包含Range請求頭字段，在當(dāng)前請求資源范圍內(nèi)沒有range指示值，請求也不包含If-Range請求頭字段
417——服務(wù)器不滿足請求Expect頭字段指定的期望值，如果是代理服務(wù)器，可能是下一級服務(wù)器不能滿足請求長。

5XX Server Error(服務(wù)器端錯誤狀態(tài)碼) 服務(wù)器處理請求出錯
HTTP 500 - 內(nèi)部服務(wù)器錯誤
Error 501 - 未實(shí)現(xiàn)
HTTP 502 - 網(wǎng)關(guān)錯誤

Cookies&Session&token

cookie
cookie是http規(guī)范，存儲在客戶端，當(dāng)客戶端第一次登錄服務(wù)端的時候，如果服務(wù)器需要記錄用戶狀態(tài)，服務(wù)器會在響應(yīng)信息中包含一個Set-Cookie的響應(yīng)頭，結(jié)構(gòu)是一個字典，鍵是根據(jù)用戶名和密碼創(chuàng)建隨機(jī)的字符串，值是客戶端的所有操作的記錄和狀態(tài)，客戶端會根據(jù)這個響應(yīng)頭存儲Cookie信息。再次請求服務(wù)器時，客戶端會在請求信息中包含一個Cookie請求頭，服務(wù)器對該憑據(jù)進(jìn)行用戶身份、狀態(tài)等驗(yàn)證，合法時使用戶不必輸入用戶名和密碼就可以直接登錄。Cookie可以提高用戶體驗(yàn)，但會加大網(wǎng)絡(luò)之間的數(shù)據(jù)傳輸量，應(yīng)盡量在Cookie中僅保存必要的數(shù)據(jù)。服務(wù)端生成cookie時若不設(shè)置過期時間，則表示這個cookie的生命期為瀏覽器會話期間，關(guān)閉瀏覽器窗口cookie就消失，稱為會話cookie。會話cookie一般不存儲在硬盤上而是保存在內(nèi)存里。若設(shè)置了過期時間，瀏覽器就會把cookie保存在硬盤上，關(guān)閉后再次打開瀏覽器，這些cookie仍然有效直到超過設(shè)定的過期時間。存儲在硬盤上的cookie可以在不同的瀏覽器進(jìn)程間共享，比如兩個IE窗口。cookie 是不可跨域的，每個cookie都會綁定單一的域名，無法在別的域名下獲取使用（foo.com域產(chǎn)生的cookie無法被bar.com域讀取），一級域名和二級域名之間是允許共享使用的。

Session
Session是一種記錄服務(wù)器和客戶端會話狀態(tài)的機(jī)制，使服務(wù)端有狀態(tài)化，可以記錄會話信息。session是基于cookie實(shí)現(xiàn)的，存儲在服務(wù)器端。用戶第一次請求服務(wù)器的時候，服務(wù)器會根據(jù)用戶提交的相關(guān)信息創(chuàng)建對應(yīng)的Session，請求返回時會將此 Session 的唯一標(biāo)識信息 SessionID 返回給瀏覽器，瀏覽器接收到服務(wù)器返回的 SessionID 信息后會將此信息存入到 Cookie 中，同時也會此 SessionID 屬于哪個域名記錄到該 Cookie 中。當(dāng)用戶第二次訪問服務(wù)器的時候，請求會自動判斷此域名下是否存在 Cookie 信息，如果存在則自動將 Cookie 信息也發(fā)送給服務(wù)端，服務(wù)端會從 Cookie 中獲取 SessionID，再根據(jù) SessionID 查找對應(yīng)的 Session 信息，如果找到 Session 證明用戶已經(jīng)登錄可執(zhí)行后面操作。如果沒有找到說明用戶沒有登錄或者登錄失效。通常情況下，服務(wù)端會使用Set-Cookie標(biāo)頭來傳遞SessionID，這只是其中一種常見的方式，有些應(yīng)用程序可能會將SessionID作為URL參數(shù)傳遞，或者使用自定義的HTTP頭來傳遞。

token令牌
客戶端使用用戶名跟密碼請求登錄，服務(wù)端收到請求后去驗(yàn)證用戶名與密碼，驗(yàn)證成功后服務(wù)端通過加密算法簽發(fā)一個token給客戶端，客戶端收到token后會把它存儲起來，比如放在cookie里或者localStorage里，客戶端每次向服務(wù)端請求資源的時候需要帶著服務(wù)端簽發(fā)的token，服務(wù)端收到請求后去驗(yàn)證客戶端請求里面帶著的 token ，如果驗(yàn)證成功就向客戶端返回請求的數(shù)據(jù)。每一次請求都需要攜帶 token，需要把 token 放到 HTTP的 Header里。基于 token 的用戶認(rèn)證是一種服務(wù)端無狀態(tài)的認(rèn)證方式，服務(wù)端不用存放 token數(shù)據(jù)。用解析 token 的計算時間換取 session 的存儲空間，從而減輕服務(wù)器的壓力，減少頻繁的查詢數(shù)據(jù)庫。token完全由應(yīng)用管理，所以它可以避開同源策略。token默認(rèn)沒有跨域限制。使用token就沒有這樣的問題。這對于需要向多個服務(wù)獲取授權(quán)的單頁面應(yīng)用程序尤其有用，使用token使得用從myapp.com獲取的授權(quán)向myservice1.com和myservice2.com獲取服務(wù)成為可能。當(dāng)你的客戶端是一個原生平臺(iOS, Android，Windows 8等)時，Cookie是不被支持的(你需要通過Cookie容器進(jìn)行處理)，這時采用Token認(rèn)證機(jī)制就會簡單得多。token 傳參有兩種一種是放在請求頭里，本質(zhì)上是跟 cookie 是一樣的，只是換個單詞而已；另外一種是在 url 請求參數(shù)里，這種更直觀。通常情況下，服務(wù)端會使用Set-Cookie標(biāo)頭來傳遞包含token的cookie。但并不是唯一的方式，服務(wù)端也可以將token直接作為響應(yīng)體的一部分進(jìn)行傳遞，或者使用自定義的HTTP頭字段進(jìn)行傳遞。

Cookie，Session和Token 的區(qū)別

安全性： Token比Session安全，Session比Cookie安全。Session存儲在服務(wù)器端，Cookie存儲在客戶端，token存儲在客戶端。

存取值的類型不同：Cookie 只支持存字符串?dāng)?shù)據(jù)，Session 可以存任意數(shù)據(jù)類型。客戶端發(fā)送session和token都要借助cookie。

有效期不同： Cookie 可設(shè)置為長時間保持，比如我們經(jīng)常使用的默認(rèn)登錄功能，Session 一般失效時間較短，客戶端關(guān)閉或者 Session 超時都會失效。

存儲大小不同： 單個 Cookie 保存的數(shù)據(jù)不能超過 4K，Session 可存儲數(shù)據(jù)遠(yuǎn)高于Cookie，但是當(dāng)訪問量過多會占用過多的服務(wù)器資源。

cookie格式如下：

Set-Cookie: "name=value;domain=.domain.com;path=/;expires=Sat, 11 Jun 2016 11:29:42 GMT;HttpOnly;secure"其中name=value是必選項，其它都是可選項。Cookie的主要構(gòu)成如下：

name:一個唯一確定的cookie名稱。通常來講cookie的名稱是不區(qū)分大小寫的。
value:存儲在cookie中的字符串值。最好為cookie的name和value進(jìn)行url編碼
domain:cookie對于哪個域是有效的。所有向該域發(fā)送的請求中都會包含這個cookie信息。這個值可以包含子域(如：yq.aliyun.com)，也可以不包含它(如：.aliyun.com，則對于aliyun.com的所有子域都有效).
path: 表示這個cookie影響到的路徑，瀏覽器跟會根據(jù)這項配置，像指定域中匹配的路徑發(fā)送cookie。
expires:失效時間，表示cookie何時應(yīng)該被刪除的時間戳(也就是何時應(yīng)該停止向服務(wù)器發(fā)送這個cookie)。如果不設(shè)置這個時間戳，瀏覽器會在頁面關(guān)閉時即將刪除所有cookie；不過也可以自己設(shè)置刪除時間。
這個值是GMT時間格式，如果客戶端和服務(wù)器端時間不一致，使用expires就會存在偏差。
max-age: 與expires作用相同，用來告訴瀏覽器此cookie多久過期（單位是秒），而不是一個固定的時間點(diǎn)。正常情況下，max-age的優(yōu)先級高于expires。
HttpOnly: 告知瀏覽器不允許通過腳本document.cookie去更改這個值，同樣這個值在document.cookie中也不可見。但在http請求張仍然會攜帶這個cookie。注意這個值雖然在腳本中不可獲取，但仍然在瀏覽器
安裝目錄中以文件形式存在。這項設(shè)置通常在服務(wù)器端設(shè)置。
secure: 安全標(biāo)志，指定后，只有在使用SSL鏈接時候才能發(fā)送到服務(wù)器，如果是http鏈接則不會傳遞該信息。就算設(shè)置了secure 屬性也并不代表他人不能看到你機(jī)器本地保存的 cookie 信息，所以不要把重要信息
放cookie就對了服務(wù)器端設(shè)置

三、HTTP1

HTTP協(xié)議永遠(yuǎn)都是客戶端發(fā)起請求，服務(wù)器回送響應(yīng)。這樣就限制了使用HTTP協(xié)議，無法實(shí)現(xiàn)在客戶端沒有發(fā)起請求的時候，服務(wù)器將消息推送給客戶端。HTTP協(xié)議是一個無狀態(tài)的協(xié)議，同一個客戶端的這次請求和上次請求是沒有對應(yīng)關(guān)系。HTTP/1.0于1996年5月公布。HTTP/1.1于1997年1月公布。

HTTP通信機(jī)制

HTTP通信機(jī)制是在一次完整的HTTP通信過程中，Web瀏覽器與Web服務(wù)器之間將完成下列7個步驟
1. 建立TCP連接 在HTTP工作開始之前，Web瀏覽器首先要通過網(wǎng)絡(luò)與Web服務(wù)器建立連接，該連接是通過TCP來完成的，HTTP是比TCP更高層次的應(yīng)用層協(xié)議，只有低層協(xié)議建立之后才能進(jìn)行更高層協(xié)議的連接，因此首先要建立TCP連接。
2. Web瀏覽器向Web服務(wù)器發(fā)送請求命令 一旦建立了TCP連接，Web瀏覽器就會向Web服務(wù)器發(fā)送請求命令。例如：GET/sample/hello.jsp HTTP/1.1。
3. Web瀏覽器發(fā)送請求頭信息 瀏覽器發(fā)送其請求命令之后，還要以頭信息的形式向Web服務(wù)器發(fā)送一些別的信息，之后瀏覽器發(fā)送了一空白行來通知服務(wù)器，它已經(jīng)結(jié)束了該頭信息的發(fā)送。
4. Web服務(wù)器應(yīng)答 客戶機(jī)向服務(wù)器發(fā)出請求后，服務(wù)器會客戶機(jī)回送應(yīng)答， HTTP/1.1 200 OK ，應(yīng)答的第一部分是協(xié)議的版本號和應(yīng)答狀態(tài)碼。
5. Web服務(wù)器發(fā)送應(yīng)答頭信息 正如客戶端會隨同請求發(fā)送關(guān)于自身的信息一樣，服務(wù)器也會隨同應(yīng)答向用戶發(fā)送關(guān)于它自己的數(shù)據(jù)及被請求的文檔。
6. Web服務(wù)器向?yàn)g覽器發(fā)送數(shù)據(jù) Web服務(wù)器向?yàn)g覽器發(fā)送頭信息后，緊接著會發(fā)送一個空白行來表示頭信息的發(fā)送到此為結(jié)束，接著，服務(wù)器就以Content-Type應(yīng)答頭信息所描述的格式發(fā)送用戶所請求的實(shí)際數(shù)據(jù)。
7. Web服務(wù)器關(guān)閉TCP連接 一般情況下，一旦Web服務(wù)器向?yàn)g覽器發(fā)送了請求數(shù)據(jù)，它就要關(guān)閉TCP連接，然后如果瀏覽器或者服務(wù)器在其頭信息加入了這行代碼：Connection:keep-alive
TCP連接在發(fā)送后將仍然保持打開狀態(tài)，于是，瀏覽器可以繼續(xù)通過相同的連接發(fā)送請求。保持連接節(jié)省了為每個請求建立新連接所需的時間，還節(jié)約了網(wǎng)絡(luò)帶寬。

在上圖中，可清晰的看到客戶端瀏覽器（ip為192.168.2.33）與服務(wù)器的交互過程：
1）No1：瀏覽器（192.168.2.33）向服務(wù)器（220.181.50.118）發(fā)出連接請求。此為TCP三次握手第一步，此時從圖中可以看出，為SYN，seq:X （x=0）
2）No2：服務(wù)器（220.181.50.118）回應(yīng)了瀏覽器（192.168.2.33）的請求，并要求確認(rèn)，此時為：SYN，ACK，此時seq：y（y為0），ACK：x+1（為1）。此為三次握手的第二步；
3）No3：瀏覽器（192.168.2.33）回應(yīng)了服務(wù)器（220.181.50.118）的確認(rèn)，連接成功。為：ACK，此時seq：x+1（為1），ACK：y+1（為1）。此為三次握手的第三步；
4）No4：瀏覽器（192.168.2.33）發(fā)出一個頁面HTTP請求；
5）No5：服務(wù)器（220.181.50.118）確認(rèn)；
6）No6：服務(wù)器（220.181.50.118）發(fā)送數(shù)據(jù)；
7）No7：客戶端瀏覽器（192.168.2.33）確認(rèn)；
8）No14：客戶端（192.168.2.33）發(fā)出一個圖片HTTP請求；
9）No15：服務(wù)器（220.181.50.118）發(fā)送狀態(tài)響應(yīng)碼200 OK
……

持久連接

HTTP1.0每進(jìn)行一次HTTP請求就會斷開一次TCP連接，連接不能復(fù)用。這情況在早期傳輸文本很小的時候倒也不覺得如何，但是隨著時代的進(jìn)步，所需傳輸?shù)膬?nèi)容種類越來越多和內(nèi)容越來越大了，每次連接后都會斷開請求就大幅度的增加了通信量的開銷了。

HTTP/1.1有了持久連接，新的請求可以在上次請求建立的TCP連接之上發(fā)送，連接可以復(fù)用。它規(guī)定了只要任何一方?jīng)]有明確的提出斷開連接，那么就保持TCP連接狀態(tài)。而在維持的TCP連接期間，可以多次進(jìn)行HTTP請求來傳輸需要的內(nèi)容。長連接情況下，多個HTTP請求可以復(fù)用同一個TCP連接，這就節(jié)省了很多TCP連接建立和斷開的消耗。

HTTP/1.1默認(rèn)保持持久連接，在HTTP的頭部信息中會有Connection: Keep-alive屬性，在響應(yīng)頭設(shè)置Connection屬性為close即可關(guān)閉持久連接。我們也可以通過瀏覽器開發(fā)工具的NetWork面板查看這個屬性的狀態(tài)及HTTP請求信息：

如果你是短連接的話，那你每打開一個網(wǎng)頁，基本要建立幾個甚至幾十個TCP連接，這很浪費(fèi)資源。但如果是長連接的話，那么這么多次HTTP請求，其實(shí)使用的都是一個TCP連接，很顯然是可以節(jié)省很多消耗的。長連接并不是永久連接的，如果一段時間內(nèi)（具體的時間長短，是可以在header當(dāng)中進(jìn)行設(shè)置的，也就是所謂的超時時間），這個連接沒有HTTP請求發(fā)出的話，那么這個長連接就會被斷掉。

長連接多用于操作頻繁，點(diǎn)對點(diǎn)的通訊，而且連接數(shù)不能太多情況，例如：數(shù)據(jù)庫的連接用長連接， 如果用短連接頻繁的通信會造成socket錯誤，而且頻繁的socket 創(chuàng)建也是對資源的浪費(fèi)。 而像WEB網(wǎng)站的http服務(wù)一般都用短鏈接，因?yàn)殚L連接對于服務(wù)端來說會耗費(fèi)一定的資源，而像WEB網(wǎng)站這么頻繁的成千上萬甚至上億客戶端的連接用短連接會更省一些資源，如果用長連接，如果每個用戶都占用一個連接的話，并發(fā)量會很大。

HTTP協(xié)議中的長輪詢和短輪詢　　

短輪詢不難理解，比如你現(xiàn)在要做一個電商中商品詳情的頁面，這個詳情界面中有一個字段是庫存量。而這個庫存量需要實(shí)時的變化，保持和服務(wù)器里實(shí)際的庫存一致。這個時候，最簡單的一種方式，就是寫個死循環(huán)，不停的去請求服務(wù)器中的庫存量是多少，然后刷新到這個頁面當(dāng)中，這其實(shí)就是所謂的短輪詢。長輪詢和短輪詢最大的區(qū)別是，短輪詢?nèi)シ?wù)端查詢的時候，不管庫存量有沒有變化，服務(wù)器就立即返回結(jié)果了。而長輪詢則不是，在長輪詢中，服務(wù)器如果檢測到庫存量沒有變化的話，將會把當(dāng)前請求掛起一段時間（這個時間也叫作超時時間，一般是幾十秒）。在這個時間里，服務(wù)器會去檢測庫存量有沒有變化，檢測到變化就立即返回，否則就一直等到超時為止。而對于客戶端來說，不管是長輪詢還是短輪詢，客戶端的動作都是一樣的，就是不停的去請求，不同的是服務(wù)端，短輪詢情況下服務(wù)端每次請求不管有沒有變化都會立即返回結(jié)果，而長輪詢情況下，如果有變化才會立即返回結(jié)果，而沒有變化的話，則不會再立即給客戶端返回結(jié)果，直到超時為止。　

長短輪詢和長短連接的區(qū)別
第一，一個TCP連接是否為長連接，是通過設(shè)置HTTP的Connection Header來決定的，而且是需要兩邊都設(shè)置才有效。而一種輪詢方式是否為長輪詢，是根據(jù)服務(wù)端的處理方式來決定的，與客戶端沒有關(guān)系。
第二個區(qū)別就是實(shí)現(xiàn)的方式，連接的長短是通過協(xié)議來規(guī)定和實(shí)現(xiàn)的。而輪詢的長短，是服務(wù)器通過編程的方式手動掛起請求來實(shí)現(xiàn)的。

HTTP/1.x的缺陷

• 連接無法復(fù)用：連接無法復(fù)用會導(dǎo)致每次請求都經(jīng)歷三次握手和慢啟動。三次握手在高延遲的場景下影響較明顯，慢啟動則對大量小文件請求影響較大（未達(dá)到最大窗口請求就被終止）。
  • • HTTP/1.0傳輸數(shù)據(jù)時，每次都需要重新建立連接，增加延遲。
    • HTTP/1.1雖然加入keep-alive可以復(fù)用一部分連接，但域名分片等情況下仍然需要建立多個connection，耗費(fèi)資源，給服務(wù)器帶來性能壓力。
• 隊頭阻塞（HOLB）：導(dǎo)致帶寬無法被充分利用，以及后續(xù)健康請求被阻塞。HOLB是指一系列包因?yàn)榈谝粋€包被阻塞；HOLB會導(dǎo)致在達(dá)到最大請求數(shù)量時，剩余的資源需要等待其他資源請求完成后才能發(fā)起請求。
• HTTP 1.0：下個請求必須在前一個請求返回后才能發(fā)出，request-response對按序發(fā)生。顯然，如果某個請求長時間沒有返回，那么接下來的請求就全部阻塞了。
• HTTP 1.1：嘗試使用 pipeling 來解決，即瀏覽器可以一次性發(fā)出多個請求（同個域名，同一條 TCP 鏈接）。但 pipeling 要求返回是按序的，那么前一個請求如果很耗時（比如處理大圖片），那么后面的請求即使服務(wù)器已經(jīng)處理完，仍會等待前面的請求處理完才開始按序返回。所以，pipeling 只部分解決了 HOLB。

• 協(xié)議開銷大： HTTP1.x在使用時，header里攜帶的內(nèi)容過大，在一定程度上增加了傳輸?shù)某杀荆⑶颐看握埱骽eader基本不怎么變化，尤其在移動端增加用戶流量。
• 安全因素：HTTP1.x在傳輸數(shù)據(jù)時，所有傳輸?shù)膬?nèi)容都是明文，客戶端和服務(wù)器端都無法驗(yàn)證對方的身份，這在一定程度上無法保證數(shù)據(jù)的安全性

一條連接上只可發(fā)送一個請求。
請求只能從客戶端開始。客戶端不可以接收除響應(yīng)以外的指令。
請求 / 響應(yīng)首部未經(jīng)壓縮就發(fā)送。首部信息越多延遲越大。
發(fā)送冗長的首部。每次互相發(fā)送相同的首部造成的浪費(fèi)較多。

HTTP/1.1版的頭信息肯定是文本（ASCII編碼），數(shù)據(jù)體可以是文本，也可以是二進(jìn)制。
HTTP/2.0版的頭信息，數(shù)據(jù)體都是二進(jìn)制。

四、HTTP/2

隨著 web 技術(shù)的飛速發(fā)展。 HTTP 1.1 已經(jīng)無法滿足用戶對性能的要求， HTTP/2主要基于 SPDY 協(xié)議。HTTP/2標(biāo)準(zhǔn)于2015年5月發(fā)表。

HTTP/2 采用二進(jìn)制格式傳輸數(shù)據(jù)，而非 HTTP 1.x 的文本格式，二進(jìn)制協(xié)議解析起來更高效。 HTTP / 1 的請求和響應(yīng)報文，都是由起始行，首部和實(shí)體正文（可選）組成，各部分之間以文本換行符分隔。HTTP/2 將請求和響應(yīng)數(shù)據(jù)分割為更小的幀，并且它們采用二進(jìn)制編碼。

二進(jìn)制分幀

• 幀（幀）：HTTP/2數(shù)據(jù)通信的最小單位。
• 消息（Message）：指 HTTP/2 中邏輯上的 HTTP 消息。例如請求和響應(yīng)等，消息由一個或多個幀組成。
• 流（流）：存在于連接中的一個虛擬通道。流可以承載雙向消息，每個流都有一個唯一的整數(shù)ID。

HTTP/2 中，同域名下所有通信都在單個連接上完成，該連接可以承載任意數(shù)量的雙向數(shù)據(jù)流。每個數(shù)據(jù)流都以消息的形式發(fā)送，而消息又由一個或多個幀組成。多個幀之間可以亂序發(fā)送，根據(jù)幀首部的流標(biāo)識可以重新組裝。

多路復(fù)用

多路復(fù)用代替原來的序列和阻塞機(jī)制。所有就是請求的都是通過一個 TCP連接并發(fā)完成。HTTP 1.x 中，如果想并發(fā)多個請求，必須使用多個 TCP 鏈接，且瀏覽器為了控制資源，還會對單個域名有 6-8 的個數(shù)限制，如下圖，紅色圈出來的請求就因域名鏈接數(shù)已超過限制，而被掛起等待了一段時間：

在 HTTP/2 中，有了二進(jìn)制分幀之后，HTTP/2 不再依賴 TCP 鏈接去實(shí)現(xiàn)多流并行了，在 HTTP/2中：
●同域名下所有通信都在單個連接上完成。
●單個連接可以承載任意數(shù)量的雙向數(shù)據(jù)流。
●數(shù)據(jù)流以消息的形式發(fā)送，而消息又由一個或多個幀組成，多個幀之間可以亂序發(fā)送，因?yàn)楦鶕?jù)幀首部的流標(biāo)識可以重新組裝。
這一特性，性能會有極大的提升，因?yàn)椋?br>●同個域名只需要占用一個 TCP 連接，消除了因多個 TCP 連接而帶來的延時和內(nèi)存消耗。
●單個連接上可以并行交錯的請求和響應(yīng)，之間互不干擾。
●在HTTP/2中，每個請求都可以帶一個31bit的優(yōu)先值，0表示最高優(yōu)先級， 數(shù)值越大優(yōu)先級越低。有了這個優(yōu)先值，客戶端和服務(wù)器就可以在處理不同的流時采取不同的策略，以最優(yōu)的方式發(fā)送流、消息和幀。

服務(wù)器推送

服務(wù)端可以在發(fā)送頁面HTML時主動推送其它資源，而不用等到瀏覽器解析到相應(yīng)位置，發(fā)起請求再響應(yīng)。例如服務(wù)端可以主動把JS和CSS文件推送給客戶端，而不需要客戶端解析HTML再發(fā)送這些請求。服務(wù)端可以主動推送，客戶端也有權(quán)利選擇接收與否。如果服務(wù)端推送的資源已經(jīng)被瀏覽器緩存過，瀏覽器可以通過發(fā)送RST_STREAM幀來拒收。主動推送也遵守同源策略，服務(wù)器不會隨便推送第三方資源給客戶端。

頭部壓縮

HTTP 1.1請求的大小變得越來越大，有時甚至?xí)笥赥CP窗口的初始大小，因?yàn)樗鼈冃枰却龓е鳤CK的響應(yīng)回來以后才能繼續(xù)被發(fā)送。HTTP/2對消息頭采用HPACK（專為http2頭部設(shè)計的壓縮格式）進(jìn)行壓縮傳輸，能夠節(jié)省消息頭占用的網(wǎng)絡(luò)的流量。而HTTP/1.x每次請求，都會攜帶大量冗余頭信息，浪費(fèi)了很多帶寬資源。
HTTP 每一次通信都會攜帶一組頭部，用于描述這次通信的的資源、瀏覽器屬性、cookie 等，例如

為了減少這塊的開銷并提升性能， HTTP/2會壓縮這些首部：
●HTTP/2在客戶端和服務(wù)器端使用“首部表”來跟蹤和存儲之前發(fā)送的鍵－值對，對于相同的數(shù)據(jù)，不再通過每次請求和響應(yīng)發(fā)送；
●首部表在HTTP/2的連接存續(xù)期內(nèi)始終存在，由客戶端和服務(wù)器共同漸進(jìn)地更新;
●每個新的首部鍵－值對要么被追加到當(dāng)前表的末尾，要么替換表中之前的值。
例如：下圖中的兩個請求， 請求一發(fā)送了所有的頭部字段，第二個請求則只需要發(fā)送差異數(shù)據(jù)，這樣可以減少冗余數(shù)據(jù)，降低開銷。

我們來看一個實(shí)際的例子，下面是用WireShark抓取的訪問google首頁的包：

上圖是是訪問https://www.google.com/抓到的第一個請求的頭部，可以看到頭部的內(nèi)容，總共占用了437 bytes，我們選中頭部的cookie，可以看到cookie總共占用了118 bytes。接下來我們看看第二個請求的頭部：

從上圖可以看到，得益于頭部壓縮，第二個請求中cookie只占用了1個字節(jié)，我們來看看變化了的Accept字段：

由于Accept字段與請求一中的內(nèi)容不同，需要發(fā)送給服務(wù)器，所以占用了29 bytes。

HTTP/2.0核心優(yōu)勢/特性

多路復(fù)用：多個請求都是通過一個 TCP 連接并發(fā)完成(HTTP/1.1管線化在多個請求之間的響應(yīng)會被阻塞，HTTP/2.0解決了這問題，并且支持優(yōu)先級和流量控制)
頭部壓縮：報文頭部壓縮處理，數(shù)通信量更小
服務(wù)端推送：服務(wù)端能夠更快的把資源推送給客戶端
語義改進(jìn)：采用二進(jìn)制格式傳輸數(shù)據(jù)

五、HTTPS

HTTP是明文傳輸?shù)模簿鸵馕吨橛诎l(fā)送端和接收端中間的任意節(jié)點(diǎn)都可以知道你們傳輸?shù)膬?nèi)容是什么。這些節(jié)點(diǎn)可能是路由器、代理等。HTTPS全稱Hyper Text Transfer Protocol over Secure Socket Layer，直譯過來就是通過SSL實(shí)現(xiàn)的超文本傳輸協(xié)議，簡單來講就是加密版的HTTP協(xié)議，也就是HTTP+SSL/TLS。HTTPS是HTTP運(yùn)行在SSL/TLS之上，HTTPS使用對稱加密和非對稱加密相結(jié)合的方式來實(shí)現(xiàn)內(nèi)容加密。

SSL/TLS
為了解決HTTP明文傳輸?shù)娘L(fēng)險性，網(wǎng)景公司設(shè)計了SSL。SSL目前的版本是3.0，之后IETF對SSL 3.0進(jìn)行了升級，于是出現(xiàn)了TLS 1.0。簡單而言就是TLS是SSL的升級版，現(xiàn)在瀏覽器一般用的都是TLS。

SSL（Secure Socket Layer，安全套接字層）：1994年為 Netscape 所研發(fā)，SSL 協(xié)議位于 TCP/IP 協(xié)議與各種應(yīng)用層協(xié)議之間，為數(shù)據(jù)通訊提供安全支持。他的版本有：SSL 1.0、SSL 2.0、SSL 3.0

TLS（Transport Layer Security，傳輸層安全）：其前身是 SSL，1999年從 3.1 開始被 IETF 標(biāo)準(zhǔn)化并改名為TLS，發(fā)展至今已經(jīng)有 TLS 1.0、TLS 1.1、TLS 1.2 三個版本。
SSL3.0和TLS1.0由于存在安全漏洞，已經(jīng)很少被使用到。目前使用最廣泛的是TLS 1.1、TLS 1.2。

兩種基本的加解密算法類型：
1）對稱加密：密鑰只有一個，加密解密為同一個密碼，且加解密速度快，典型的對稱加密算法有DES、AES等；
2）非對稱加密：密鑰成對出現(xiàn)，加密解密使用不同密鑰（公鑰加密需要私鑰解密，私鑰加密需要公鑰解密），相對對稱加密速度較慢，典型的非對稱加密算法有RSA、DSA等。

HTTPS加密方式介紹
瀏覽器-->SSL Client Hello(我支持這些加密方式)-->服務(wù)器
瀏覽器<-SLL Server Hello(就用這種加密,然后下面是我的證書)-<--服務(wù)器
瀏覽器-->證書驗(yàn)證ok,拿證書里的公鑰加密key,告訴服務(wù)器-->服務(wù)器
瀏覽器<--私鑰解密，得到key<--服務(wù)器
開始以對稱密鑰的方式，加密通信，密鑰即key

HTTPS的優(yōu)點(diǎn)
從實(shí)際出發(fā)來看，HTTPS主要有以下優(yōu)點(diǎn)：
1防止私密信息泄露，防止信息被篡改；
2有助于SEO，百度、谷歌均明確表示會優(yōu)先收錄、展示HTTPS站點(diǎn)的內(nèi)容；
3完全杜絕運(yùn)營商HTTP劫持問題；
4有效解決運(yùn)營商DNS劫持問題，降低網(wǎng)站被劫持的風(fēng)險;
5HTTPS的小綠鎖表示可以提升用戶對網(wǎng)站信任程度（當(dāng)然不是說有小綠鎖的都是安全的）;
6可以有效防止山寨、鏡像網(wǎng)站等；
7為未來升級HTTP/2做準(zhǔn)備，HTTP/2必須基于HTTPS部署；

HTTPS的缺點(diǎn)
1服務(wù)器性能下降，開啟HTTPS會增加內(nèi)存、CPU、網(wǎng)絡(luò)帶寬的開銷，特別是非對稱加密這一塊；
2訪問速度下降，HTTP連接的建立需要3次握手，HTTPS還需要加上ssl的幾次握手，當(dāng)然下降主要是在第一次建立連接的時候，后面正常通信速度一般沒啥變化；
3除了握手部分外，所有信息傳輸之后瀏覽器和服務(wù)器都要進(jìn)行加密解密，又是一筆額外的開銷；
4申請證書需要一筆花費(fèi)，當(dāng)然現(xiàn)在免費(fèi)證書也很容易申請到，這個不算明顯缺點(diǎn)；

HTTPS原理

HTTPS主要分為單向認(rèn)證和雙向認(rèn)證，99%的場景都只需要單向認(rèn)證。

單向認(rèn)證

1瀏覽器訪問一個https地址，同時向服務(wù)端發(fā)送支持的SSL協(xié)議版本、支持的加密算法、一個客戶端生成的隨機(jī)數(shù)（用于稍后生成"對話密鑰"）等。
2服務(wù)端給客戶端返回要使用的SSL協(xié)議版本號、加密算法、一個服務(wù)器生成的隨機(jī)數(shù)（也同樣用于稍后生成"對話密鑰"），另外還有一個最重要的，返回服務(wù)器端的證書，即公鑰證書；
3客戶端收到服務(wù)器回應(yīng)以后，首先驗(yàn)證證書是否合法，如果證書不是可信機(jī)構(gòu)頒布、或者證書中的域名與實(shí)際域名不一致、或者證書已經(jīng)過期、或者返回的公鑰不能正確解開返回證書中的數(shù)字簽名，就會向訪問者顯示一個警告，由其選擇是否還要繼續(xù)通信。如果證書沒有問題，客戶端就會從證書中取出服務(wù)器的公鑰繼續(xù)；
客4戶端向服務(wù)端發(fā)送自己所能支持的對稱加密方案（注意是對稱加密），供服務(wù)器端進(jìn)行選擇；
5服務(wù)器端在客戶端提供的加密方案中選擇加密程度最高的加密方式；
6服務(wù)器將選擇好的加密方案通過明文方式返回給客戶端；
7客戶端接收到服務(wù)端返回的加密方式后，使用該加密方式生成產(chǎn)生一個隨機(jī)密鑰（后續(xù)用作通信過程中對稱加密的密鑰），然后將該隨機(jī)數(shù)用用證書中的公鑰加密發(fā)給服務(wù)端；
8服務(wù)器收到客戶端返回的加密信息后，使用自己的私鑰進(jìn)行解密，獲得最終的對稱加密密鑰。至此，客戶端和服務(wù)端都得到一個隨機(jī)密鑰，并且這個密鑰別人沒法知道；
9在接下來的會話中，服務(wù)器和客戶端將會使用該密碼進(jìn)行對稱加密解密，保證通信過程中信息的安全。

雙向認(rèn)證
雙向認(rèn)證和單向認(rèn)證原理基本差不多，主要區(qū)別是除了客戶端需要認(rèn)證服務(wù)端以外，服務(wù)端對客戶端也需要認(rèn)證。什么場景下需要驗(yàn)證客戶端呢？比如一些銀行業(yè)務(wù)，銀行會要求客戶必須在電腦上插入它們簽發(fā)的U盾之類的東西，或者安裝什么控件，這里就類似客戶端證書的概念，沒有這個證書的人無法使用銀行提供的業(yè)務(wù)。

一次完整的HTTPS請求

1.客戶端發(fā)送Client Hello報文開始SSL通信，報文中包含客戶端支持的SSL的指定版本、加密組件列表等
2.服務(wù)端可進(jìn)行SSL通信時，會以Serve rHello報文作為應(yīng)答
3.服務(wù)端發(fā)送Certificate報文，報文包含公開密鑰證書
4.服務(wù)端發(fā)送Server Hello Done報文通知客戶端，最初階段的SSL握手協(xié)商部分結(jié)束
5.SSL第一次握手結(jié)束后，客戶端以Client Key Exchange報文作為回應(yīng)，其中包含通信加密中使用的隨機(jī)密碼串
6.客戶端發(fā)送Change Cipher Spec報文，提示服務(wù)端此報文之后的通信采用符合上一步的隨機(jī)密碼串的密鑰加密
7.客戶端發(fā)送Finished報文，其中包含連接至今全部報文的整體校驗(yàn)值
8.服務(wù)端發(fā)送Change Cipher Spec報文
9.服務(wù)端發(fā)送Finished報文
10.Finished報文交換完畢后，SSL連接建立完成
11.應(yīng)用層協(xié)議通信，HTTP
12.客戶端斷開連接，發(fā)送close notify

TLS握手過程
在建立TCP連接后，開始建立TLS連接。TSL握手協(xié)議如下圖所示

(1) client端發(fā)起握手請求，會向服務(wù)器發(fā)送一個ClientHello消息，該消息包括其所支持的SSL/TLS版本、Cipher Suite加密算法列表（告知服務(wù)器自己支持哪些加密算法）、sessionID、隨機(jī)數(shù)等內(nèi)容。

(2) 服務(wù)器收到請求后會向client端發(fā)送ServerHello消息，其中包括：
SSL/TLS版本；
session ID，因?yàn)槭鞘状芜B接會新生成一個session id發(fā)給client；
Cipher Suite，sever端從Client Hello消息中的Cipher Suite加密算法列表中選擇使用的加密算法；
Radmon 隨機(jī)數(shù)。

(3) 經(jīng)過ServerHello消息確定TLS協(xié)議版本和選擇加密算法之后，就可以開始發(fā)送證書給client端了。證書中包含公鑰、簽名、證書機(jī)構(gòu)等信息。

(4) 服務(wù)器向client發(fā)送ServerKeyExchange消息，消息中包含了服務(wù)器這邊的EC Diffie-Hellman算法相關(guān)參數(shù)。此消息一般只在選擇使用DHE 和DH_anon等加密算法組合時才會由服務(wù)器發(fā)出。

(5) server端發(fā)送ServerHelloDone消息，表明服務(wù)器端握手消息已經(jīng)發(fā)送完成了。

(6) client端收到server發(fā)來的證書，會去驗(yàn)證證書，當(dāng)認(rèn)為證書可信之后，會向server發(fā)送ClientKeyExchange消息，消息中包含客戶端這邊的EC Diffie-Hellman算法相關(guān)參數(shù)，然后服務(wù)器和客戶端都可根據(jù)接收到的對方參數(shù)和自身參數(shù)運(yùn)算出Premaster secret，為生成會話密鑰做準(zhǔn)備。

(7) 此時client端和server端都可以根據(jù)之前通信內(nèi)容計算出Master Secret（加密傳輸所使用的對稱加密秘鑰），client端通過發(fā)送此消息告知server端開始使用加密方式發(fā)送消息。

(8) 客戶端使用之前握手過程中獲得的服務(wù)器隨機(jī)數(shù)、客戶端隨機(jī)數(shù)、Premaster secret計算生成會話密鑰master secret，然后使用該會話密鑰加密之前所有收發(fā)握手消息的Hash和MAC值，發(fā)送給服務(wù)器，以驗(yàn)證加密通信是否可用。服務(wù)器將使用相同的方法生成相同的會話密鑰以解密此消息，校驗(yàn)其中的Hash和MAC值。

(9) 服務(wù)器發(fā)送ChangeCipherSpec消息，通知客戶端此消息以后服務(wù)器會以加密方式發(fā)送數(shù)據(jù)。

(10) sever端使用會話密鑰加密（生成方式與客戶端相同，使用握手過程中獲得的服務(wù)器隨機(jī)數(shù)、客戶端隨機(jī)數(shù)、Premaster secret計算生成）之前所有收發(fā)握手消息的Hash和MAC值，發(fā)送給客戶端去校驗(yàn)。若客戶端服務(wù)器都校驗(yàn)成功，握手階段完成，雙方將按照SSL記錄協(xié)議的規(guī)范使用協(xié)商生成的會話密鑰加密發(fā)送數(shù)據(jù)。