前言
本文已經(jīng)收錄到我的
Github個人博客，歡迎大佬們光臨寒舍：
學(xué)習(xí)清單：
一爱只、網(wǎng)絡(luò)基礎(chǔ) TCP/IP
通常使用的網(wǎng)絡(luò)（包括互聯(lián)網(wǎng)）是在 TCP/IP 協(xié)議族的基礎(chǔ)上運(yùn)作与纽，而 HTTP 屬于它內(nèi)部的一個子集
1.1 層次劃分
-
應(yīng)用層： 決定了向用戶提供應(yīng)用服務(wù)時通信的活動赦颇，比如
FTP砸琅、DNS、HTTP
易記：應(yīng)用層变过，顧名思義，是提供給應(yīng)用服務(wù)的活動涝涤，然后現(xiàn)在最火的應(yīng)用是微信（通信功能）媚狰，所以就是：向用戶提供應(yīng)用服務(wù)時通信
-
傳輸層： 對上層應(yīng)用層，提供處于網(wǎng)絡(luò)連接中的兩臺計算機(jī)之間的數(shù)據(jù)傳輸阔拳，比如
TCP崭孤、UDP
易記：傳輸層类嗤，顧名思義，提供計算機(jī)之間的數(shù)據(jù)傳輸
- 網(wǎng)絡(luò)層： 用來處理在網(wǎng)絡(luò)上流動的數(shù)據(jù)包辨宠，該層規(guī)定了通過怎樣的路徑到達(dá)對方計算機(jī)遗锣，并把數(shù)據(jù)包傳送給對方；與對方計算機(jī)之間通過多臺計算機(jī)或網(wǎng)絡(luò)設(shè)備進(jìn)行傳輸時嗤形，網(wǎng)絡(luò)層所起的作用就是在眾多的選項(xiàng)內(nèi)選擇一條傳輸路線
易記：網(wǎng)絡(luò)層精偿，顧名思義，處理在網(wǎng)絡(luò)上流動的數(shù)據(jù)包赋兵，規(guī)定通過什么路徑
- 數(shù)據(jù)鏈路層： 用來處理連接網(wǎng)絡(luò)的硬件部分
易記：數(shù)據(jù)鏈路層笔咽，顧名思義，鏈路偏硬件的東西霹期，而數(shù)據(jù)是偏軟件層面的東西叶组，自然可以想到是起到連接作用
1.2 通信的過程
- 首先作為發(fā)送端的客戶端在應(yīng)用層（
HTTP協(xié)議）發(fā)出獲取Web頁面的HTTP請求 - 接著，為了傳輸方便历造，在傳輸層（
TCP協(xié)議）把從應(yīng)用層處收到的數(shù)據(jù)（HTTP請求報文）進(jìn)行分割甩十，并在各個報文上打上標(biāo)記序號及端口號后轉(zhuǎn)發(fā)給網(wǎng)絡(luò)層 - 在網(wǎng)絡(luò)層（
IP協(xié)議），增加作為通信目的地的MAC地址后轉(zhuǎn)發(fā)給鏈路層吭产。這樣一來侣监，發(fā)往網(wǎng)絡(luò)的通信請求就準(zhǔn)備齊全了 - 接收端的服務(wù)器在鏈路層接收到數(shù)據(jù)，按序往上層發(fā)送垮刹，一直到應(yīng)用層达吞。當(dāng)傳輸?shù)綉?yīng)用層，才能算真正接收到由客戶端發(fā)送過來的
HTTP請求
1.3 三次握手
之前已經(jīng)筆者已經(jīng)寫了荒典，因此在這里就不再贅述酪劫，點(diǎn)擊鏈接即可跳轉(zhuǎn)：
TCP連接管理
1.4 各協(xié)議與 HTTP 協(xié)議的關(guān)系
1.5 URI 和 URL
Q1：URL 和 URI 的區(qū)別
-
URI用字符串標(biāo)識某一互聯(lián)網(wǎng)資源 -
URL表示資源的地點(diǎn)
由此可見，
URL是URI的子集
Q2：URI 的各部分結(jié)構(gòu)
二寺董、簡單的 HTTP 協(xié)議
2.1 HTTP 方法
-
GET獲取資源： 用來請求訪問已被URI識別的資源覆糟，指定的資源經(jīng)服務(wù)器端解析后返回響應(yīng)內(nèi)容 -
POST傳輸實(shí)體主體： 用來傳輸實(shí)體的主體 雖然用GET方法也可以傳輸實(shí)體的主體，但一般不用GET方法進(jìn)行傳輸遮咖，而是用POST方法 -
PUT傳輸文件： 在請求報文的主體中包含文件內(nèi)容滩字，然后保存到請求URI指定的位置 鑒于HTTP1.1的PUT方法自身不帶驗(yàn)證機(jī)制，任何人都可以上傳文件御吞，存在安全性問題麦箍，因此一般不使用該方法 -
HEAD獲得報文首部： 和GET方法一樣，只是不返回報文主體部分陶珠。 用于確認(rèn)URI的有效性及資源更新的日期時間等 -
DELETE刪除文件： 用來刪除文件挟裂，是與PUT相反的方法。DELETE方法按請求 URI 刪除指定的資源揍诽。 不帶驗(yàn)證機(jī)制诀蓉，所以一般不使用DELETE方法
和
put相對應(yīng)栗竖，兩者都不具備驗(yàn)證機(jī)制
-
OPTIONS詢問支持的方法： 用來查詢針對請求URI指定的資源支持的方法（了解即可） -
TRACE追蹤路徑： 讓Web服務(wù)器端將之前的請求通信返回給客戶端的方法。 但TRACE方法本來就不怎么常用渠啤，再加上它容易引發(fā)XST攻擊狐肢，通常就更不會用到了（了解即可） -
CONNECT要求用隧道協(xié)議連接代理： 要求在與代理服務(wù)器通信時建立隧道，實(shí)現(xiàn)用隧道協(xié)議進(jìn)行TCP通信沥曹。 主要使用SSL（Secure Sockets Layer份名，安全套接層）和TLS（Transport Layer Security，傳輸層安全）協(xié)議把通信內(nèi)容加密后經(jīng)網(wǎng)絡(luò)隧道傳輸架专。
2.2 持久連接節(jié)省通信量
2.2.1 持久鏈接
持久連接的特點(diǎn)是同窘，只要任意一端沒有明確提出斷開連接，則保持 TCP 連接狀態(tài)
持久連接的好處：
- 減少了
TCP連接的重復(fù)建立和斷開所造成的額外開銷部脚，減輕了服務(wù)器端的負(fù)載
感覺有點(diǎn)類似于連接池的作用
- 減少開銷的那部分時間想邦，使
HTTP請求和響應(yīng)能夠更早地結(jié)束，這樣Web頁面的顯示速度也就相應(yīng)提高了
2.2.2 管線化
管線化技術(shù)出現(xiàn)后委刘，不用等待響應(yīng)亦可直接發(fā)送下一個請求
這樣就能夠做到同時并行發(fā)送多個請求丧没，而不需要一個接一個地等待響應(yīng)了
用持久連接可以讓請求更快結(jié)束。而管線化技術(shù)則比持久連接還要快锡移。請求數(shù)越多呕童，時間差就越明顯。
2.4 使用 Cookie 的狀態(tài)管理
狀態(tài)管理其實(shí)還有很多種淆珊，比如
Session,token夺饲，這里僅介紹cookie
HTTP 是無狀態(tài)協(xié)議，它不對之前發(fā)生過的請求和響應(yīng)的狀態(tài)進(jìn)行管理施符。
Cookie 技術(shù)通過在請求和響應(yīng)報文中寫入 Cookie 信息來控制客戶端的狀態(tài)往声。Cookie 會根據(jù)從服務(wù)器端發(fā)送的響應(yīng)報文內(nèi)的一個叫做 Set-Cookie 的首部字段信息，通知客戶端保存 Cookie戳吝。當(dāng)下次客戶端再往該服務(wù)器發(fā)送請求時浩销，客戶端會自動在請求報文中加入 Cookie 值后發(fā)送出去
三、HTTP 報文內(nèi)的 HTTP 信息
3.1 壓縮傳輸?shù)膬?nèi)容編碼
內(nèi)容編碼指明應(yīng)用在實(shí)體內(nèi)容上的編碼格式听哭，并保持實(shí)體信息原樣壓縮
常用的內(nèi)容編碼有：
gzipcompressdeflateidentity
四慢洋、返回結(jié)果的 HTTP 狀態(tài)碼
4.1 狀態(tài)碼告知從服務(wù)器端返回的請求結(jié)果
數(shù)字中的第一位指定了響應(yīng)類別，后兩位無分類
| 類別 | 原因短語 | |
|---|---|---|
| 1XX | Informational | 接收的請求正在處理 |
| 2XX | Success | 請求正常處理完畢 |
| 3XX | Redirection | 需要進(jìn)行附加操作以完成請求 |
| 4XX | Client Error | 客戶端無法處理請求 |
| 5XX | Server Error | 服務(wù)器處理請求出錯 |
4.2 2xx 成功
4.3 3xx 重定向
4.4 4XX 客戶端錯誤
PS:注意區(qū)分 403 和 404陆盘，一個是被拒絕（一般是權(quán)限問題）普筹，另一個是無法找到
4.5 5XX 服務(wù)器錯誤
五、Web 服務(wù)器
5.1 用單臺虛擬主機(jī)實(shí)現(xiàn)多個域名
HTTP1.1 規(guī)范允許一個服務(wù)器搭建多個 Web 站點(diǎn)隘马，這是虛擬主機(jī)功能太防。
Q1：為啥 Host 首部內(nèi)完整指定主機(jī)名或域名的 URI？
因?yàn)樘摂M主機(jī)可以寄存多個不同主機(jī)名和域名的 Web 網(wǎng)站
5.2 通信數(shù)據(jù)轉(zhuǎn)發(fā)程序
這些應(yīng)用程序和服務(wù)器可以將請求轉(zhuǎn)發(fā)給通信線路上的下一站服務(wù)器祟霍，并且能接收從那臺服務(wù)器發(fā)送的響應(yīng)再轉(zhuǎn)發(fā)給客戶端杏头。
- 代理：接收客戶端發(fā)送的請求后轉(zhuǎn)發(fā)給其他服務(wù)器；代理不改變請求
URI沸呐，會直接發(fā)送給前方持有資源的目標(biāo)服務(wù)器醇王。
- 緩存代理：預(yù)先將資源緩存保存在代理服務(wù)器上，當(dāng)代理再次接收到對相同資源的請求時崭添，就可以直接將之前緩存的資源作為響應(yīng)返回
- 透明代理：轉(zhuǎn)發(fā)請求或響應(yīng)時寓娩，不對報文做任何加工被稱為透明代理，對報文內(nèi)容進(jìn)行加工的稱為非透明代理呼渣。
2.網(wǎng)關(guān):轉(zhuǎn)發(fā)其他服務(wù)器通信數(shù)據(jù)的服務(wù)器棘伴，接收從客戶端發(fā)送來的請求時，它就像自己擁有資源的源服務(wù)器一樣對請求進(jìn)行處理屁置。
3.隧道： 按要求建立起一條與其他服務(wù)器的通信線路焊夸，屆時使用 SSL 等加密手段進(jìn)行通信，在通信雙方斷開連接時結(jié)束蓝角。隧道的目的是確壁逅耄客戶端能與服務(wù)器進(jìn)行安全的通信。
5.3 保存資源的緩存
客戶端的緩存： 瀏覽器緩存如果有效使鹅，不必再向服務(wù)器請求揪阶，而直接從本地讀取。當(dāng)判定緩存過期后患朱，會向源服務(wù)器確認(rèn)資源的有效性鲁僚。若判斷瀏覽器緩存失效，瀏覽器會再次請求新資源裁厅。
六冰沙、HTTP 首部
HTTP 協(xié)議的請求和響應(yīng)報文中必定包含 HTTP 首部，請求報文和響應(yīng)報文結(jié)構(gòu)如下
6.1 HTTP 首部字段
HTTP 首部字段將定義成緩存代理和非緩存代理的行為姐直，分成 2 種類型倦淀。
- 端到端首部： 分在此類別中的首部會轉(zhuǎn)發(fā)給請求 / 響應(yīng)對應(yīng)的最終接收目標(biāo)，且必須保存在由緩存生成的響應(yīng)中声畏，另外規(guī)定它必須被轉(zhuǎn)發(fā)撞叽。
-
逐跳首部： 分在此類別中的首部只對單次轉(zhuǎn)發(fā)有效，會因通過緩存或代理而不再轉(zhuǎn)發(fā)插龄。
HTTP1.1和之后版本中愿棋，如果要使用hop-by-hop首部，需提供Connection首部字段均牢。
6.1.1 通用首部字段
請求報文和響應(yīng)報文兩方都會使用的首部糠雨。
| 首部字段名 | 說明 |
|---|---|
Cache-Control |
控制緩存的行為 |
Connection |
逐跳首部、連接的管理 |
Date |
創(chuàng)建報文的日期時間 |
Pragma |
報文指令 |
Trailer |
報文末端的首部一覽 |
Transfer-Encoding |
指定報文主體的傳輸編碼方式 |
Upgrade |
升級為其他協(xié)議 |
Via |
代理服務(wù)器的相關(guān)信息 |
Warning |
錯誤通知 |
6.1.2 請求首部字段
從客戶端向服務(wù)器端發(fā)送請求報文時使用的首部徘跪。補(bǔ)充了請求的附加內(nèi)容甘邀、客戶端信息隧膘、響應(yīng)內(nèi)容相關(guān)優(yōu)先級等信息闲礼。
| 首部字段名 | 說明 |
|---|---|
| Accept | 用戶代理可處理的媒體類型 |
| Accept-Charset | 優(yōu)先的字符集 |
| Accept-Encoding | 優(yōu)先的內(nèi)容編碼 |
| Accept-Language | 優(yōu)先的語言（自然語言） |
| Authorization | Web認(rèn)證信息 |
| Expect | 期待服務(wù)器的特定行為 |
| From | 用戶的電子郵箱地址 |
| Host | 請求資源所在服務(wù)器 |
| If-Match | 比較實(shí)體標(biāo)記（ETag） |
| If-Modified-Since | 比較資源的更新時間 |
| If-None-Match | 比較實(shí)體標(biāo)記（與 If-Match 相反） |
| If-Range | 資源未更新時發(fā)送實(shí)體 Byte 的范圍請求 |
| If-Unmodified-Since | 比較資源的更新時間（與If-Modified-Since相反） |
| Max-Forwards | 最大傳輸逐跳數(shù) |
| Proxy-Authorization | 代理服務(wù)器要求客戶端的認(rèn)證信息 |
| Range | 實(shí)體的字節(jié)范圍請求 |
| Referer | 對請求中 URI 的原始獲取方 |
| TE | 傳輸編碼的優(yōu)先級 |
| User-Agent | HTTP 客戶端程序的信息 |
6.1.3 響應(yīng)首部字段
從服務(wù)器端向客戶端返回響應(yīng)報文時使用的首部。補(bǔ)充了響應(yīng)的附加內(nèi)容，也會要求客戶端附加額外的內(nèi)容信息叁温。
| 首部字段名 | 說明 |
|---|---|
| Accept-Ranges | 是否接受字節(jié)范圍請求 |
| Age | 推算資源創(chuàng)建經(jīng)過時間 |
| ETag | 資源的匹配信息 |
| Location | 令客戶端重定向至指定URI |
| Proxy-Authenticate | 代理服務(wù)器對客戶端的認(rèn)證信息 |
| Retry-After | 對再次發(fā)起請求的時機(jī)要求 |
| Server | HTTP服務(wù)器的安裝信息 |
| Vary | 代理服務(wù)器緩存的管理信息 |
| WWW-Authenticate | 服務(wù)器對客戶端的認(rèn)證信息 |
6.1.4 實(shí)體首部字段
針對請求報文和響應(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 | 資源的最后修改日期時間 |
6.2 HTTP1.1 通用首部字段
通用首部字段是指請求報文和響應(yīng)報文都會使用的首部。
6.2.1 Cache-Control
-
no-cache： 防止從緩存中返回過期的資源邮府∮兀客戶端請求如果包含
no-cache，表示客戶端將不會接收緩存過的響應(yīng)褂傀，緩存服務(wù)器必須把客戶端請求轉(zhuǎn)發(fā)給源服務(wù)器忍啤。服務(wù)器響應(yīng)中包含no-cache，那么緩存服務(wù)器不能對資源進(jìn)行緩存仙辟，源服務(wù)器以后也將不再對緩存服務(wù)器請求中提出的資源有效性進(jìn)行確認(rèn)檀轨，且禁止其對響應(yīng)資源進(jìn)行緩存操作。 - no-store： 緩存不能在本地存儲請求或響應(yīng)的任一部分欺嗤。
從字面意思上很容易把 no-cache 誤解成為不緩存参萄，但 no-cache 代表不緩存過期的資源，緩存會向源服務(wù)器進(jìn)行有效期確認(rèn)后處理資源煎饼，no-store 才是真正地不進(jìn)行緩存讹挎。
6.2.2 Connection
1.控制不再轉(zhuǎn)發(fā)給代理的首部字段： 在客戶端發(fā)送請求和服務(wù)器返回響應(yīng)內(nèi)，使用 Connection 首部字段吆玖，可控制不再轉(zhuǎn)發(fā)給代理的首部字段（即 Hop-by-hop 逐跳首部）筒溃。
2.管理持久連接： HTTP1.1 默認(rèn)持久連接，客戶端會在持久連接上連續(xù)發(fā)送請求沾乘。服務(wù)器端想斷開連接時怜奖，則設(shè)置 Connection 首部字段為 Close。HTTP1.1 之前默認(rèn)都是非持久連接翅阵。為此歪玲，如果想在舊版本 HTTP 協(xié)議上持續(xù)連接，則需設(shè)置 Connection 首部字段為 Keep-Alive掷匠。
6.2.3 Date
表明創(chuàng)建 HTTP 報文的日期和時間滥崩。
6.2.4 Upgrade
用于檢測 HTTP 協(xié)議及其他協(xié)議是否可使用更高的版本進(jìn)行通信，其參數(shù)值可以用來指定一個完全不同的通信協(xié)議讹语。
6.3 請求首部字段
從客戶端往服務(wù)器端發(fā)送請求報文中所使用的字段钙皮，用于補(bǔ)充請求的附加信息、客戶端信息、對響應(yīng)內(nèi)容相關(guān)的優(yōu)先級等內(nèi)容短条。
6.3.1 Accept
通知服務(wù)器导匣，用戶代理能夠處理的媒體類型及媒體類型的相對優(yōu)先級∪资保可使用 type/subtype 這種形式逐抑，一次指定多種媒體類型。
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
6.3.2 Host
告知服務(wù)器屹蚊，請求的資源所處的互聯(lián)網(wǎng)主機(jī)名和端口號。Host 首部字段在 HTTP1.1 規(guī)范內(nèi)是唯一一個必須被包含在請求內(nèi)的首部字段进每。
6.3.3 If-Match
形如 If-xxx 這種汹粤，都可稱為條件請求。服務(wù)器接收到后田晚，只有判斷指定條件為真時嘱兼，才會執(zhí)行請求。
6.3.4 If-None-Match
和 If-Match 相反
6.3.5 If-Modified-Since
如果在 If-Modified-Since 字段指定的日期時間后資源發(fā)生了更新贤徒，服務(wù)器會接受請求芹壕。
6.3.6 If-Unmodified-Since
和 If-Modified-Since 的作用相反
6.3.7 If-Range
字段如果跟 ETag 值或更新的日期時間一致，那么就作為范圍請求處理接奈。反之踢涌，則返回全體資源。
6.4 響應(yīng)首部字段
由服務(wù)器端向客戶端返回響應(yīng)報文中所使用的字段序宦，用于補(bǔ)充響應(yīng)的附加信息睁壁、服務(wù)器信息，以及對客戶端的附加要求等信息互捌。
6.4.1 ETag
實(shí)體標(biāo)識潘明，將資源以字符串形式做唯一性標(biāo)識的方式。服務(wù)器會為每份資源分配對應(yīng)的 ETag 值秕噪。當(dāng)資源更新時钳降，ETag 值也需要更新。
若在下載過程中出現(xiàn)連接中斷腌巾、再連接的情況遂填，都會依照 ETag 值來指定資源。
6.5 實(shí)體首部字段
包含在請求報文和響應(yīng)報文中的實(shí)體部分所使用的首部澈蝙，用于補(bǔ)充內(nèi)容的更新時間等與實(shí)體相關(guān)的信息城菊。
6.5.1 Allow
通知客戶端能夠支持的所有 HTTP 方法。當(dāng)服務(wù)器接收到不支持的 HTTP 方法時碉克，會以狀態(tài)碼 405 Method Not Allowed 作為響應(yīng)返回凌唬。與此同時，還會把所有能支持的 HTTP 方法寫入首部字段 Allow 后返回。
6.5.2 Content-Encoding
告知客戶端服務(wù)器對實(shí)體的主體部分選用的內(nèi)容編碼方式客税。內(nèi)容編碼是指在不丟失實(shí)體信息的前提下所進(jìn)行的壓縮况褪。
主要有：gzip、compress更耻、deflate测垛、identity
6.5.3 Content-Type
說明了實(shí)體主體內(nèi)對象的媒體類型，用 type/subtype 形式賦值秧均。
6.5.4 Expires
Expires 會將資源失效的日期告知客戶端食侮。緩存服務(wù)器在收到有 Expires 的響應(yīng)后，會以緩存來應(yīng)答請求目胡，在 Expires 字段值指定的時間之前锯七，響應(yīng)的副本會一直被保存。當(dāng)超過指定的時間后誉己，緩存服務(wù)器在請求發(fā)送過來時眉尸，會轉(zhuǎn)向源服務(wù)器請求資源。
6.5.5 Last-Modified
包含源頭服務(wù)器認(rèn)定的資源做出修改的日期及時間巨双。
6.6 為 Cookie 服務(wù)的首部字段
| 首部字段名 | 說明 | 首部類型 |
|---|---|---|
| Set-Cookie | 開始狀態(tài)管理所使用的Cookie信息 | 響應(yīng)首部字段 |
| Cookie | 服務(wù)器接收到的Cookie信息 | 請求首部字段 |
6.7 其他首部字段
6.7.1 X-XSS-Protection
是針對跨站腳本攻擊（XSS）的一種對策噪猾，用于控制瀏覽器 XSS 防護(hù)機(jī)制的開關(guān)，可指定的字段值如下
- 0：將
XSS過濾設(shè)置成無效狀態(tài) - 1：將
XSS過濾設(shè)置成有效狀態(tài)
七筑累、 HTTPS
HTTP協(xié)議中有可能存在信息竊聽或身份偽裝等安全問題袱蜡，怎么解決呢？HTTPS了解一下
7.1 HTTP 的缺點(diǎn)是啥慢宗？
- 通信使用明文（不加密）戒劫，內(nèi)容可能會被竊聽
- 不驗(yàn)證通信方的身份，因此有可能遭遇偽裝
- 無法證明報文的完整性婆廊，所以有可能已遭篡改
7.2 HTTPS 是啥 迅细？
簡單來說，就是：HTTP+ 加密 + 認(rèn)證 + 完整性保護(hù)
把添加了加密及認(rèn)證機(jī)制的 HTTP 稱為 HTTPS
HTTPS 并非是應(yīng)用層的一種新協(xié)議淘邻，只是 HTTP 通信接口部分用 SSL（Secure Socket Layer）和 TLS（Transport Layer Security）協(xié)議代替而已茵典。
HTTPS 采用共享密鑰加密和公開密鑰加密兩者并用的混合加密機(jī)制。若密鑰能夠?qū)崿F(xiàn)安全交換宾舅，那么有可能會考慮僅使用公開密鑰加密來通信统阿。但是公開密鑰加密與共享密鑰加密相比，其處理速度要慢筹我。
所以取長補(bǔ)短扶平，在交換密鑰環(huán)節(jié)使用公開密鑰加密方式，之后的建立通信交換報文階段則使用共享密鑰加密方式蔬蕊。
數(shù)字證書認(rèn)證機(jī)構(gòu)（CA结澄，Certificate Authority）和其相關(guān)機(jī)關(guān)頒發(fā)的公開密鑰證書就是認(rèn)證的可以信賴的公開密鑰，服務(wù)器會將這份由數(shù)字證書認(rèn)證機(jī)構(gòu)頒發(fā)的公鑰證書發(fā)送給客戶端，以進(jìn)行公開密鑰加密方式通信麻献。公鑰證書也可叫做數(shù)字證書或直接稱為證書们妥。
7.2.1 SSL 速度慢嗎
當(dāng)使用 SSL 時，它的處理速度會變慢勉吻。它慢分兩種：
- 一種是指通信慢
還必須進(jìn)行
SSL通信,所以慢
- 另一種是指由于大量消耗
CPU及內(nèi)存等資源监婶，導(dǎo)致處理速度變慢。
服務(wù)器和客戶端都需要進(jìn)行加解密處理
針對速度變慢這一問題齿桃，并沒有根本性的解決方案惑惶，一般會使用 SSL 加速器這種（專用服務(wù)器）硬件。
7.2.2 為啥沒使用 HTTPS 短纵？
- 加密通信會消耗更多的
CPU及內(nèi)存資源 - 如果是非敏感信息則使用
HTTP通信带污，只有在包含個人信息等敏感數(shù)據(jù)時踩娘，才利用HTTPS加密通信养渴。可以僅在那些需要信息隱藏時才加密理卑，以節(jié)約資源蔽氨。 - 節(jié)約購買證書的開銷
八、確認(rèn)訪問用戶身份的認(rèn)證
一些頁面只想讓特定的人瀏覽鹉究，這就引入了認(rèn)證功能。
HTTP1.1 常用的認(rèn)證方式：
-
BASIC認(rèn)證（基本認(rèn)證） -
DIGEST認(rèn)證（摘要認(rèn)證） -
SSL客戶端認(rèn)證 -
FormBase認(rèn)證（基于表單認(rèn)證）
九自赔、基于 HTTP 的功能追加協(xié)議
9.1 WebSocket
連接的發(fā)起方仍是客戶端，一旦確立 WebSocket 通信連接润脸，服務(wù)器與客戶端任意一方都可向?qū)Ψ桨l(fā)送報文。
- 推送功能： 支持由服務(wù)器向客戶端推送數(shù)據(jù)的推送功能毙驯。這樣，服務(wù)器可直接發(fā)送數(shù)據(jù)爆价，而不必等待客戶端的請求。
-
減少通信量： 和
HTTP相比允坚，不但每次連接時的開銷減少魂那，且由于首部信息很小，通信量也減少了稠项。
通信的建立：
1.首先使用 HTTP 的 Upgrade 首部字段涯雅，告知服務(wù)器通信協(xié)議發(fā)生改變，進(jìn)行握手展运。
GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
Sec-WebSocket-Key 字段內(nèi)記錄著握手過程中必不可少的鍵值活逆。Sec-WebSocket-Protocol 字段內(nèi)記錄使用的子協(xié)議。
2.之前的請求將會被返回 101 Switching Protocols 響應(yīng)
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chat
成功握手建立 WebSocket 連接之后拗胜，通信時不再使用 HTTP 的數(shù)據(jù)幀蔗候，而采用 WebSocket 獨(dú)立的數(shù)據(jù)幀。
9.2 HTTP/2.0
HTTP/2.0 的目標(biāo)是改善用戶在使用 Web 時的速度體驗(yàn)埂软。特點(diǎn)：
- HTTP/2.0 采用二進(jìn)制格式而非文本格式
- HTTP/2.0 是完全多路復(fù)用的锈遥，而非有序并阻塞的——只需一個連接即可實(shí)現(xiàn)并行
- 使用報頭壓縮，HTTP/2.0 降低了開銷
- HTTP/2.0 讓服務(wù)器可以將響應(yīng)主動“推送”到客戶端緩存中
如果文章對您有一點(diǎn)幫助的話勘畔，希望您能點(diǎn)一下贊所灸，您的點(diǎn)贊，是我前進(jìn)的動力
本文參考鏈接：
- 『圖解 HTTP』
- 《圖解 HTTP》 閱讀摘要
