1.1 分組傳遞（分包）
瀏覽器會基于http協(xié)議產(chǎn)生一個(gè)http報(bào)文（消息）磁椒，然后會把這個(gè)報(bào)文拆分成不同的分組（包）
發(fā)送到路由上。路由先進(jìn)行緩存涎劈，然后在根據(jù)路由表轉(zhuǎn)發(fā)給下一個(gè)路由荔睹，直到到達(dá)服務(wù)器揖盘。
1.1.1 我們?yōu)槭裁床恢苯影严l(fā)送給服務(wù)器楷力，為什么一定要分包呢喊式？
首先，路由是先緩存再轉(zhuǎn)發(fā)萧朝，如果把整個(gè)報(bào)文直接發(fā)給服務(wù)器岔留，那么對路由內(nèi)存要求會非常高。
另外還有一個(gè)重要的概念就是網(wǎng)絡(luò)的帶寬检柬，也是在鏈路上的傳輸速率献联，它是由單位時(shí)間內(nèi)可以傳輸?shù)臄?shù)據(jù)總量決定的。而不是我們物理距離何址，
1.2傳輸延時(shí)
排隊(duì)延時(shí)：比如當(dāng)?shù)?個(gè)到包達(dá)時(shí)A時(shí)里逆，如果它前面已經(jīng)有一些其他客戶端的包到達(dá)，那么它就許多排隊(duì)等待用爪。排隊(duì)所用的時(shí)間就是排隊(duì)延時(shí)原押。
結(jié)點(diǎn)處理延遲：排隊(duì)到了以后，結(jié)點(diǎn)A會對包進(jìn)行一些處理偎血，這個(gè)處理時(shí)間叫結(jié)點(diǎn)處理延遲诸衔，通常是毫秒級的影響非常小。
傳播延遲： A出發(fā)后颇玷，從A到B在鏈路上傳播還要經(jīng)過一定物理距離笨农，但傳輸?shù)乃俣确浅？焯ǔＪ?.7倍的光速谒亦，所用的時(shí)間叫傳播延遲。
丟包： 如果很多客戶端同時(shí)向A結(jié)點(diǎn)發(fā)送數(shù)據(jù)包空郊，A的緩存滿了以后份招，對接下來的數(shù)據(jù)包，會丟棄渣淳。而這正是丟包的主要原因脾还。
2.1網(wǎng)絡(luò)體系結(jié)構(gòu)
osi 模型
分層：我們根據(jù)不同的功能把網(wǎng)絡(luò)模型分層。
協(xié)議：不同層之間規(guī)定了不同協(xié)議入愧，每個(gè)層遵循每個(gè)層的網(wǎng)絡(luò)協(xié)議完成完成功能鄙漏。
接口：層與層之間會通過接口去進(jìn)行交互。
所以這也符合我們函數(shù)的模塊化棺蛛，低層函數(shù)定義好接口API怔蚌，你按照函數(shù)的接口文檔去調(diào)用依賴的函數(shù)，然后就等著讓它去處理旁赊。在實(shí)際的開發(fā)中桦踊，我們就是這么去實(shí)現(xiàn)的
[圖片上傳失敗...(image-71b6e6-1530587407491)]
應(yīng)用層
瀏覽器根據(jù)http協(xié)議，產(chǎn)生報(bào)文頭和主體
對并報(bào)文進(jìn)行編碼终畅，加密籍胯，壓縮竟闪。
將數(shù)據(jù)封裝好后，交給下一層杖狼，我們將這一層的PUD叫 報(bào)文（message）
傳輸層
在瀏覽器端會將報(bào)文分組炼蛤，在服務(wù)器端會將報(bào)文重組。
在每個(gè)分組的頭蝶涩，會加上自己協(xié)議信息理朋。
這些協(xié)議信息主要功能是SAP尋址，連接控制绿聘，流量控制嗽上，差錯(cuò)控制
將數(shù)據(jù)封裝好后，交給下一層熄攘，我們將這一層的PUD叫 段（segment)
網(wǎng)絡(luò)層：
網(wǎng)絡(luò)層在拿個(gè)每個(gè)段后兽愤，會根據(jù)IP協(xié)議，加上自己協(xié)議信息
這些協(xié)議信息主要功能是：邏輯尋址（IP地址）路由轉(zhuǎn)發(fā)挪圾。
將數(shù)據(jù)封裝好后烹看，交給下一層，我們將這一層的PUD叫 數(shù)據(jù)報(bào)（datagram)
鏈路層
網(wǎng)絡(luò)層在拿個(gè)每個(gè)段后洛史，會根據(jù)IP協(xié)議惯殊，加上自己協(xié)議信息
這些協(xié)議信息主要功能是：物理尋址（MAC地址），流量控制也殖，差錯(cuò)控制土思，接入控制。
將數(shù)據(jù)封裝好后忆嗜，交給下一層己儒，我們將這一層的PUD叫 幀（frame)
物理層：
物理層在拿個(gè)幀后，會把它轉(zhuǎn)化成 比特（bit）捆毫，就是位闪湾，二進(jìn)制編碼（一堆100111）
然后將這些二進(jìn)制，根據(jù)自己物理特性去表示绩卤，比如電信號啥的途样。
然后就把它交給物理介質(zhì)去傳輸啦
MAC協(xié)議 （鏈路層 =>物理層）
在鏈路層上，主機(jī)和路由器用他們的物理地址來標(biāo)志濒憋，即48位的物理地址何暇，也是是我們通常所說的網(wǎng)卡地址（MAC地址）
總結(jié)：
信道劃分MAC協(xié)議：時(shí)間、頻帶凛驮、碼片劃分
TDMA裆站、 FDMA、 CDMA
隨機(jī)訪問MAC協(xié)議：
1. ALOHA, S-ALOHA, CSMA, CSMA/CD
2.CSMA/CD應(yīng)用于以太網(wǎng)
3.CSMA/CA應(yīng)用802.11無線局域網(wǎng)
輪轉(zhuǎn)訪問MAC協(xié)議：
1.主結(jié)點(diǎn)輪詢；令牌傳遞
2.藍(lán)牙宏胯、 FDDI羽嫡、令牌環(huán)網(wǎng)
詳情：https://blog.csdn.net/qq_20233867/article/details/78451799
ARP協(xié)議 （網(wǎng)絡(luò)層=>鏈路層）
在網(wǎng)絡(luò)層上，主機(jī)和路由器用邏輯地址來標(biāo)志肩袍，邏輯地址在本地是唯一的厂僧，但在全局上不一定。在TCP/IP協(xié)議族中稱為IP地址了牛，現(xiàn)在常用的版本是IPv4，長度是32位辰妙。
因此需要能夠?qū)⑦壿嫷刂泛拖鄳?yīng)的物理地址之間進(jìn)行映射鹰祸，完成這樣的映射可以使用靜態(tài)映射和動態(tài)映射。
靜態(tài)映射：創(chuàng)建一個(gè)表密浑，存儲邏輯地址和物理地址之間的關(guān)聯(lián)關(guān)系蛙婴。然后將網(wǎng)絡(luò)上的每個(gè)主機(jī)都存儲這張表。缺點(diǎn)是映射表必須周期的更新尔破，增加了 網(wǎng)絡(luò)的開銷街图。
動態(tài)地址映射，地址解析協(xié)議ARP和逆地址解析協(xié)議RARP懒构。
地址解析協(xié)議ARP（Address Resolution Protocol）餐济，負(fù)責(zé)完成邏輯地址向物理地址的動態(tài)映射，將32位邏輯地址（IP地址）轉(zhuǎn)換為48位的物理地址（MAC地址）胆剧。
具體過程：
1) 本地主機(jī)在局域網(wǎng)中廣播ARP請求絮姆，ARP請求數(shù)據(jù)幀中包含目的主機(jī)的IP地址。意思是“如果你是這個(gè)IP地址的擁有者秩霍，請回答你的硬件地址”篙悯。
2) 目的主機(jī)的ARP層解析這份廣播報(bào)文，識別出是詢問其硬件地址铃绒。于是發(fā)送ARP應(yīng)答包鸽照，里面包含IP地址及其對應(yīng)的硬件地址。
3) 本地主機(jī)收到ARP應(yīng)答后颠悬，知道了目的地址的硬件地址矮燎，之后的數(shù)據(jù)報(bào)就可以傳送了。
點(diǎn)對點(diǎn)鏈路不使用ARP協(xié)議赔癌。
APR請求包是廣播的漏峰，但是ARP應(yīng)答幀是單播的。
ARP請求 ：0x0001
ARP應(yīng)答 ：0x0002
RARP請求：0x0003
RARP應(yīng)答：0x0004
詳情：https://blog.csdn.net/woshifennu1234/article/details/78256395
應(yīng)用層協(xié)議
基于TCP：HTTP（超文本傳輸協(xié)議）,FTP（文件傳輸協(xié)議）,SMTP(郵件傳輸協(xié)議)
基于UDP：DNS（域名系統(tǒng)）和最近興起的QUIC（谷歌制定低時(shí)延的互聯(lián)網(wǎng)傳輸層協(xié)議）
傳輸層協(xié)議
常見的傳輸層協(xié)議有TCP届榄，UDP浅乔。
URL:統(tǒng)一資源定位
語法為：
協(xié)議://用戶名:密碼@子域名.域名.頂級域名:端口號/目錄/文件名.文件后綴?參數(shù)=值#標(biāo)志
http://username:password@host:80/directory/file.html? query#ref
ftp://username:password@host:21/directory/file.html
news://news.newsgroup.com.hk
注意：
如果參數(shù)里邊有!,%,&,/,?,=，等非西歐字符 需要encode 方法對url的進(jìn)行預(yù)處理
decode解碼成普通字符串
encode普通字符串編碼，編碼后的名字非常長叫（application/x-www-form-urlencoded MIME 字符串）
HTTP協(xié)議
1.HTTP是超文本傳輸協(xié)議靖苇，從www瀏覽器傳輸?shù)奖镜貫g覽器的 一種傳輸協(xié)議席噩，
HTTP協(xié)議是由從客戶機(jī)到服務(wù)器的請求(Request)和從服務(wù)器 到客戶機(jī)的響應(yīng)(response)進(jìn)行約束和規(guī)范。
2.http報(bào)文
HTTP報(bào)文：用于HTTP協(xié)議交互的信息被稱為HTTP報(bào)文贤壁。
1.請求(Request)端的報(bào)文叫請求報(bào)文
2.響應(yīng)(response)端的報(bào)文叫響應(yīng)報(bào)文
3.http 規(guī)則
1. 報(bào)文首部和報(bào)文主體中間要有空行（CR+LF:回車+換行）
2. 報(bào)文首部：處理請求和響應(yīng)提供的信息（上文中設(shè)
3. 置的各種信息）
報(bào)文主體：所需要的資源都在（比如返回的文本信息就是Hello world）
eg:
let responseDataTpl = `HTTP/1.1 200 OK
Connection:keep-alive
Date: ${new Date()}
Content-Length: 12
Content-Type: text/plain
Hello world!
`;
報(bào)文首部：根據(jù)實(shí)際用途會分為四種
1.通用首部字段（General）:請求報(bào)文和響應(yīng)報(bào)文都會使用的字段
2.請求首部字段（Requse Header）：請求報(bào)文使用的首部
3.響應(yīng)首部字段（Response Header）：響應(yīng)報(bào)文使用的首部
4.實(shí)體首部字段（Entity Header）：與實(shí)體有關(guān)信息的字段
所以在chrome的network中悼枢，header會顯示為：
General
Response Headers
Requse Headers
實(shí)體首部字段會寫進(jìn)請求頭和響應(yīng)頭
對于get請求后邊的參數(shù)會顯示在Query String Parameters
- http 狀態(tài)碼
- 1XX : 信息性狀態(tài)碼（接收請求正在處理）
- 2XX : 成功狀態(tài)碼（請求正常處理完畢）
- 3XX : 重定向狀態(tài)碼（需要進(jìn)行附加操作以完成請求）
- 4XX : 客戶端錯(cuò)誤狀態(tài)碼（服務(wù)器無法處理請求）
- 5XX : 服務(wù)端錯(cuò)誤狀態(tài)碼（服務(wù)器處理請求出錯(cuò)）
所以狀態(tài)碼就是前后端通信時(shí)對于狀態(tài)的一種約定，原則上只要遵循狀態(tài)碼類別的定義脾拆，即使改變RFC2616定義的狀態(tài)碼馒索，或自行創(chuàng)建都是沒問題的。
常用狀態(tài)碼：
- 200 OK ：請求被正常處理返回 200 OK名船，這也是我們最常見的啦
- 204 No Content :請求處理成功但是沒有資源返回绰上，就是報(bào)文中沒有報(bào)文主體
- 206 Partial Content :客戶端進(jìn)行范圍請求，就是請求資源一部分渠驼，服務(wù)器返回請求這部分（Content-Range）
- 301 Moved Permanently:永久重定向（資源的URL已經(jīng)更新）
- 302 Found :臨時(shí)重定向（資源的URI已經(jīng)臨時(shí)定位到其他位置了）
- 303 See Other: 對應(yīng)的資源存在另一URL蜈块，資源的URL已經(jīng)更新，是否按新的去訪問
- 304 Not Modified:客戶端發(fā)附帶條件的請求迷扇，服務(wù)端允許請求訪問資源百揭，但沒有滿足條件
- 307 Temporary Redirect: 也是臨時(shí)重定向
- 400 Bad Request : 請求報(bào)文中存在語法錯(cuò)誤
- 401 Unauthorized : 需要有HTTP認(rèn)證
- 403 Forbidden : 請求訪問的資源被服務(wù)器拒絕了
- 404 Not Found : 服務(wù)器上沒有找到資源
- 500 Internal Server Error: 服務(wù)器執(zhí)行請求時(shí)出錯(cuò)
- 503 Service Unavailable : 服務(wù)器處于超負(fù)載，正在進(jìn)行停機(jī)維護(hù)
- http 壓縮協(xié)議
1. http請求頭帶：Accept-Encoding: gzip, deflate, br
這是瀏覽器告訴服務(wù)器我支持什么樣的壓縮格式蜓席，優(yōu)先級是什么樣的器一。
2. http響應(yīng)頭帶：Content-Encoding: gzip
這是服務(wù)器告訴瀏覽器我已經(jīng)按什么樣子的格式壓縮了，解壓工作你拜托你了
所以在瀏覽器上我們就需要根據(jù)請求頭中的Accept-Encoding去判斷厨内，瀏覽器支持什么壓縮啊盹舞。然后壓縮之后再告訴瀏覽器，我已經(jīng)給你壓縮成什么樣子啦隘庄。
- http 緩存協(xié)議
強(qiáng)緩存：
Catche Contrl： :是通用首部字段踢步，就是之前將的發(fā)送報(bào)文和響應(yīng)報(bào)文都會使用的〕蟛簦可以對文件里引用資源的緩存進(jìn)行設(shè)置
eg:
瀏覽器發(fā)訪問http://localhost:10080/
- '請求報(bào)文沒帶 Cache-Control' 客戶端說我要訪問首頁
服務(wù)器返回?cái)?shù)據(jù)
- '響應(yīng)報(bào)文帶:Cache-Control : max-age = 604800' 服務(wù)器說給你index.html和加載里面資源,并告訴你這些資源一周之內(nèi)不要不必確認(rèn)了
瀏覽器刷新的網(wǎng)頁再次訪問http://localhost:10080/時(shí)
- 里面的資源就不會再發(fā)送請求了,直接從緩存中拿 你會在chrome,network中看到Time是0(from memory catch)
服務(wù)器返回?cái)?shù)據(jù)
- 服務(wù)器只返回index.html文件
這時(shí)候你強(qiáng)制刷新瀏覽器(command+shift+R)
- '請求報(bào)文帶 Catche Contrl：no-cache '客戶端說我不要緩存過的數(shù)據(jù)获印，我要源服務(wù)器的數(shù)據(jù)
服務(wù)器返回?cái)?shù)據(jù)
- 服務(wù)器返回index.html文件和依賴的資源
這就是強(qiáng)緩存，所謂強(qiáng)是在條件內(nèi)街州，你網(wǎng)頁依賴的資源都不會發(fā)送http請求了兼丰。可以直接從網(wǎng)頁里面拿唆缴。
協(xié)商緩存:（兩種）
第一種. If-Modified-Since／Last-Modified
服務(wù)器會下發(fā)一個(gè)Last-Modified最后修改時(shí)間鳍征。然后瀏覽器會記住這個(gè)時(shí)間。當(dāng)瀏覽器第二次請求時(shí)會帶上if-modified-since的時(shí)間。服務(wù)器可以去比較這份文件在if-modified-since的時(shí)間后是否修改過。如果沒有修改過诈嘿，那就返回304.
1. Last-Modified:標(biāo)示這個(gè)響應(yīng)資源的最后修改時(shí)間帘睦。web服務(wù)器在響應(yīng)請求時(shí)，告訴瀏覽器資源的最后修改時(shí)間慕蔚。
2. If-Modified-Since:當(dāng)資源過期時(shí)(使用Cache-Control標(biāo)識的max-age)梧乘，發(fā)現(xiàn)資源具有Last-Modified聲明趟济，則再次向web服務(wù)器請求時(shí)帶上頭 If- -Modified-Since戴差，表示請求時(shí)間送爸。web服務(wù)器收到請求后發(fā)現(xiàn)有頭If-Modified- Since 則與被請求資源的最后修改時(shí)間進(jìn)行比對。若最后修改時(shí)間較新暖释，說 明資源又被改動過袭厂，則響應(yīng)整片資源內(nèi)容(寫在響應(yīng)消息包體內(nèi))，HTTP 200;若最后修改時(shí)間較舊球匕，說明資源無新修改纹磺，則響應(yīng)HTTP 304 (無需包 體，節(jié)省瀏覽)谐丢，告知瀏覽器繼續(xù)使用所保存的cache。
第二種：Etag/ If-None-Match
服務(wù)器Etag會下發(fā)一個(gè)字符串蚓让，然后瀏覽器在第二次請求時(shí)會在if-none-match中帶上這個(gè)字符串乾忱。這時(shí)候服務(wù)器可以比較兩個(gè)字符串，如果相同历极，就讓瀏覽器去緩存中去取窄瘟。
1. Etag:web服務(wù)器響應(yīng)請求時(shí)，告訴瀏覽器當(dāng)前資源在服務(wù)器的唯一標(biāo)識(生成規(guī)則由服務(wù)器決定)
2. If-None-Match:當(dāng)資源過期時(shí)(使用Cache-Control標(biāo)識的max- age)趟卸，發(fā)現(xiàn)資源具有Etage聲明蹄葱，則再次向web服務(wù)器請求時(shí)帶 上頭If-None-Match (Etag的值)。web服務(wù)器收到請求后發(fā)現(xiàn) 有頭If-None-Match 則與被請求資源的相應(yīng)校驗(yàn)串進(jìn)行比對锄列，決 定返回200或304图云。
7.HTTP 瀏覽器緩存機(jī)制
所以可以看出，強(qiáng)緩存優(yōu)先于協(xié)商緩存邻邮。
- http 方法
GET：獲取資源
POST:傳輸實(shí)體主體
PUT:傳輸文件
HEAD:獲取報(bào)文首部
DELETE：刪除文件
OPTIONS：查詢支持方法
TRACK：追蹤路徑
CONNECT：要求用隧道協(xié)議連接代理
- GET 與 POST區(qū)別
瀏覽器：
GET是請求數(shù)據(jù)竣况，使用URL或Cookie傳參。POST是傳輸實(shí)體主體所以會把參數(shù)放到報(bào)文體中
GET數(shù)據(jù)放到URL中筒严，瀏覽器對URL大小有限制丹泉，所以數(shù)據(jù)大小進(jìn)行限制。POST是傳輸實(shí)體主體鸭蛙，所以大小沒有限制
GET數(shù)據(jù)放到URL中摹恨，所以安全性肯定不高啊，所以不能用來傳遞敏感信息娶视。POST相對安全
GET是請求數(shù)據(jù)所以URL地址可以后退晒哄，而POST發(fā)送數(shù)據(jù)不會（chrome中post就會后退）。
GET是請求所以會被瀏覽器主動cache，而POST是發(fā)送數(shù)據(jù)揩晴，所以不會除非手動設(shè)置勋陪。
服務(wù)器：
get是把參數(shù)放到URL中去處理
而post是觸發(fā)了服務(wù)器中監(jiān)聽的請求事件，服務(wù)器可能會做出處理硫兰，影響返回結(jié)果
總結(jié)：
“GET和POST最大的區(qū)別主要是GET請求是冪等性的诅愚，POST請求不是。冪等性是指一次和多次請求某一個(gè)資源應(yīng)該具有同樣的副作用劫映。簡單來說意味著對同一URL的多個(gè)請求應(yīng)該返回同樣的結(jié)果违孝。
請求數(shù)據(jù)的時(shí)候用get，傳輸實(shí)體主體的時(shí)候用post泳赋。
瀏覽器與協(xié)議
1.XHR 與 AJAX
AJAX全稱是Asynchronous JavaScript and XML（異步j(luò)s和XML）雌桑。異步j(luò)s，我們比較容易理解祖今。那么什么是XHR呢校坑。
XHR全稱是XMLHttpRequest，就是XML的http的請求千诬。其實(shí)這是一個(gè)瀏覽器層面的API耍目。通俗點(diǎn)講就是瀏覽器給你封裝好了的http功能函數(shù)。
2.瀏覽器安全與跨域
XHR的會有很多限制徐绑，其中對我們影響很大的就是不允許發(fā)送不同協(xié)議邪驮，地址和端口號的請求。
那么我們常見的解決方案有三種：
1.jsonp ：是把請求偽裝成標(biāo)簽去請求傲茄。因?yàn)闃?biāo)簽是瀏覽器自己發(fā)送請求毅访，所以不受同源策略影響啊
2.代理服務(wù)器：這個(gè)也很好理解，我把所有請求都發(fā)送到不跨域的代理服務(wù)器上盘榨，服務(wù)器上可是我們說的算喻粹，只要經(jīng)過處理把數(shù)據(jù)返回給瀏覽器就好。
3.CORS：這是我們今天主要講草巡。因?yàn)榻忖忂€須系鈴人磷斧，既然是你限制的，那么你總得給我一個(gè)解決辦法吧捷犹。瀏覽器給出的解決辦法就是（CORS）
cors的辦法也很簡單：
1.如果瀏覽器發(fā)現(xiàn)你已經(jīng)跨域了它會發(fā)送一個(gè)帶原IP的請求頭Origin: http://localhost:8088
2.問服務(wù)器弛饭，你讓不讓localhost:8088訪問你的文件啊，如果瀏覽器同意就回復(fù)一個(gè)Access-Control-Allow-Origin： http://localhost:8088 萍歉。表示侣颂，這個(gè)IP可以訪問的
3.然后服務(wù)器在發(fā)起正式請求
4.如果服務(wù)器沒有給瀏覽器返回Access-Control-Allow-Origin或不允許這個(gè)地址訪問，那么瀏覽器就報(bào)跨域請求錯(cuò)誤
當(dāng)然枪孩，為了安全起見CORS的請求都會忽略掉cookie 和 HTTP認(rèn)證等用戶憑證憔晒。如果你想用藻肄，同樣在請求頭帶Origin時(shí)在發(fā)送一些參數(shù)。服務(wù)器也是在第一次返回時(shí)告訴瀏覽器同意還是不同意拒担。
http發(fā)展
1.HTTP1.0 到http1.1
HTTP1.0的時(shí)候嘹屯，每次發(fā)送一個(gè)http請求就要建立一次TCP連接，然后再斷開
http1.1的時(shí)候从撼，引入了Connection:keep-alive的機(jī)制州弟，連接后不斷開可以繼續(xù)發(fā)送請求
但每次請求都是第一個(gè)回來，第二個(gè)再出發(fā)低零。后來瀏覽器又引入了 pipelining的管道化連接婆翔。
在一個(gè)TCP連接內(nèi)，多個(gè)HTTP請求可以并行掏婶，下一個(gè)HTTP請求在上一個(gè)HTTP請求的應(yīng)答完成之前就發(fā)起
這個(gè)不需要你去設(shè)置啃奴，引入了Connection:keep-alive，瀏覽器自動會這么處理雄妥。但這又有一個(gè)問題最蕾，由于HTTP1.1服務(wù)端返回響應(yīng)數(shù)據(jù)的順序必須跟客戶端請求時(shí)的順序一致，這樣也就是要求先進(jìn)先出老厌。所以很容易造成隊(duì)首阻塞瘟则。就是你第一個(gè)請求不返回，后面都得在那等著梅桩。
2.HTTPS
HTTPS是針對HTTP安全性不足壹粟，做的改進(jìn)拜隧，我們先看看HTTP安全性都有哪些不足
通信就是明文
沒有驗(yàn)證通信方身份
無法證明報(bào)文完整性
所以 HTTS = HTTP + 加密 + 認(rèn)證 + 完整性保護(hù) **
加密解密：
比如我有一份數(shù)據(jù)要給你宿百，我只需要把它加密了，你在解密這樣不就安全了洪添。
所以我有一個(gè)私鑰用來加密垦页，給別人解密的是公鑰
但是這個(gè)時(shí)候，我們又不能保證別人拿到的公鑰就是我的公鑰干奢。萬一數(shù)據(jù)沒有變痊焊，但是公鑰被劫持，解密出來的內(nèi)容就也不是我想發(fā)給對方的啦
所以我把公鑰交給第三方CA認(rèn)證一下忿峻，第三方把公鑰變成了證書
這樣瀏覽器再拿到我發(fā)給它的證書的時(shí)候薄啥，他去和第三方CA問一下，這是不是他的證書啊逛尚。
第三方說是垄惧，這樣我們就安全了。
同樣瀏覽器也會以同樣的私鑰和證書的方式對傳給服務(wù)器的數(shù)據(jù)進(jìn)行加密解密绰寞。在第三方認(rèn)證的時(shí)候到逊，我們會詳細(xì)登記自己的信息铣口。這樣我們彼此也就完成了身份認(rèn)證。
最后觉壶，這個(gè)加密算法還用摘要功能來保證數(shù)據(jù)的完整性
總結(jié)：
HTTPS協(xié)議只是HTTP通信接口部分用SSL協(xié)議代替而已脑题。而剛才我們講的這個(gè)過程就是SSL協(xié)議的內(nèi)容。它是由網(wǎng)景公司發(fā)明铜靶，后來轉(zhuǎn)交給IETF,IETF在SSL基礎(chǔ)上制定的TLS
3.HTTP2.0
（1）多路復(fù)用叔遂，并不在遵循先進(jìn)先出。
那么現(xiàn)在有一個(gè)問題旷坦，http2中掏熬，既然沒有先進(jìn)先出，那么重要的文件加載的慢秒梅，那不就尷尬啦旗芬。
（2）http2定義了請求優(yōu)先級
我們可以讓一些重要的請求優(yōu)先加載。瀏覽器也智能的根據(jù)http2定義出的優(yōu)先級規(guī)則去顯示頁面捆蜀。
（3）頭部壓縮
我們知道我們在用Gzip方式給報(bào)文體進(jìn)行壓縮疮丛。http2給報(bào)文頭也進(jìn)行了壓縮。你可別小看了報(bào)文頭辆它，一般網(wǎng)頁的報(bào)文頭能占到報(bào)文的40%誊薄。 而壓縮后能減少60%左右。
（4）性能上新增了二進(jìn)制分幀層锰茉。也得到了大大的提升呢蔫。分針層對應(yīng)的就是http報(bào)文。所以http/1.1是一個(gè)文本協(xié)議飒筑，而 http2 是一個(gè)徹徹底底的二進(jìn)制協(xié)議片吊。
