1.1 分組傳遞（分包）
瀏覽器會基于http協(xié)議產(chǎn)生一個http報文（消息），然后會把這個報文拆分成不同的分組（包）
發(fā)送到路由上。路由先進行緩存，然后在根據(jù)路由表轉(zhuǎn)發(fā)給下一個路由，直到到達服務(wù)器。
1.1.1 我們?yōu)槭裁床恢苯影严l(fā)送給服務(wù)器，為什么一定要分包呢？
首先，路由是先緩存再轉(zhuǎn)發(fā)，如果把整個報文直接發(fā)給服務(wù)器，那么對路由內(nèi)存要求會非常高。
另外還有一個重要的概念就是網(wǎng)絡(luò)的帶寬，也是在鏈路上的傳輸速率，它是由單位時間內(nèi)可以傳輸?shù)臄?shù)據(jù)總量決定的。而不是我們物理距離，
1.2傳輸延時
排隊延時：比如當(dāng)?shù)?個到包達時A時，如果它前面已經(jīng)有一些其他客戶端的包到達，那么它就許多排隊等待。排隊所用的時間就是排隊延時。
結(jié)點處理延遲：排隊到了以后，結(jié)點A會對包進行一些處理，這個處理時間叫結(jié)點處理延遲，通常是毫秒級的影響非常小。
傳播延遲： A出發(fā)后，從A到B在鏈路上傳播還要經(jīng)過一定物理距離，但傳輸?shù)乃俣确浅？欤ǔＪ?.7倍的光速，所用的時間叫傳播延遲。
丟包： 如果很多客戶端同時向A結(jié)點發(fā)送數(shù)據(jù)包，A的緩存滿了以后，對接下來的數(shù)據(jù)包，會丟棄。而這正是丟包的主要原因。
2.1網(wǎng)絡(luò)體系結(jié)構(gòu)
osi 模型
分層：我們根據(jù)不同的功能把網(wǎng)絡(luò)模型分層。
協(xié)議：不同層之間規(guī)定了不同協(xié)議，每個層遵循每個層的網(wǎng)絡(luò)協(xié)議完成完成功能。
接口：層與層之間會通過接口去進行交互。
所以這也符合我們函數(shù)的模塊化，低層函數(shù)定義好接口API，你按照函數(shù)的接口文檔去調(diào)用依賴的函數(shù)，然后就等著讓它去處理。在實際的開發(fā)中，我們就是這么去實現(xiàn)的
[圖片上傳失敗...(image-71b6e6-1530587407491)]
應(yīng)用層
瀏覽器根據(jù)http協(xié)議，產(chǎn)生報文頭和主體
對并報文進行編碼，加密，壓縮。
將數(shù)據(jù)封裝好后，交給下一層，我們將這一層的PUD叫 報文（message）
傳輸層
在瀏覽器端會將報文分組，在服務(wù)器端會將報文重組。
在每個分組的頭，會加上自己協(xié)議信息。
這些協(xié)議信息主要功能是SAP尋址，連接控制，流量控制，差錯控制
將數(shù)據(jù)封裝好后，交給下一層，我們將這一層的PUD叫 段（segment)
網(wǎng)絡(luò)層：
網(wǎng)絡(luò)層在拿個每個段后，會根據(jù)IP協(xié)議，加上自己協(xié)議信息
這些協(xié)議信息主要功能是：邏輯尋址（IP地址）路由轉(zhuǎn)發(fā)。
將數(shù)據(jù)封裝好后，交給下一層，我們將這一層的PUD叫 數(shù)據(jù)報（datagram)
鏈路層
網(wǎng)絡(luò)層在拿個每個段后，會根據(jù)IP協(xié)議，加上自己協(xié)議信息
這些協(xié)議信息主要功能是：物理尋址（MAC地址），流量控制，差錯控制，接入控制。
將數(shù)據(jù)封裝好后，交給下一層，我們將這一層的PUD叫 幀（frame)
物理層：
物理層在拿個幀后，會把它轉(zhuǎn)化成 比特（bit），就是位，二進制編碼（一堆100111）
然后將這些二進制，根據(jù)自己物理特性去表示，比如電信號啥的。
然后就把它交給物理介質(zhì)去傳輸啦
MAC協(xié)議 （鏈路層 =>物理層）
在鏈路層上，主機和路由器用他們的物理地址來標(biāo)志，即48位的物理地址，也是是我們通常所說的網(wǎng)卡地址（MAC地址）
總結(jié)：
信道劃分MAC協(xié)議：時間、頻帶、碼片劃分
TDMA、 FDMA、 CDMA
隨機訪問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é)點輪詢；令牌傳遞
2.藍牙、 FDDI、令牌環(huán)網(wǎng)
詳情：https://blog.csdn.net/qq_20233867/article/details/78451799
ARP協(xié)議 （網(wǎng)絡(luò)層=>鏈路層）
在網(wǎng)絡(luò)層上，主機和路由器用邏輯地址來標(biāo)志，邏輯地址在本地是唯一的，但在全局上不一定。在TCP/IP協(xié)議族中稱為IP地址，現(xiàn)在常用的版本是IPv4，長度是32位。
因此需要能夠?qū)⑦壿嫷刂泛拖鄳?yīng)的物理地址之間進行映射，完成這樣的映射可以使用靜態(tài)映射和動態(tài)映射。
靜態(tài)映射：創(chuàng)建一個表，存儲邏輯地址和物理地址之間的關(guān)聯(lián)關(guān)系。然后將網(wǎng)絡(luò)上的每個主機都存儲這張表。缺點是映射表必須周期的更新，增加了 網(wǎng)絡(luò)的開銷。
動態(tài)地址映射，地址解析協(xié)議ARP和逆地址解析協(xié)議RARP。
地址解析協(xié)議ARP（Address Resolution Protocol），負責(zé)完成邏輯地址向物理地址的動態(tài)映射，將32位邏輯地址（IP地址）轉(zhuǎn)換為48位的物理地址（MAC地址）。
具體過程：
1) 本地主機在局域網(wǎng)中廣播ARP請求，ARP請求數(shù)據(jù)幀中包含目的主機的IP地址。意思是“如果你是這個IP地址的擁有者，請回答你的硬件地址”。
2) 目的主機的ARP層解析這份廣播報文，識別出是詢問其硬件地址。于是發(fā)送ARP應(yīng)答包，里面包含IP地址及其對應(yīng)的硬件地址。
3) 本地主機收到ARP應(yīng)答后，知道了目的地址的硬件地址，之后的數(shù)據(jù)報就可以傳送了。
點對點鏈路不使用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（谷歌制定低時延的互聯(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的進行預(yù)處理
decode解碼成普通字符串
encode普通字符串編碼，編碼后的名字非常長叫（application/x-www-form-urlencoded MIME 字符串）
HTTP協(xié)議
1.HTTP是超文本傳輸協(xié)議，從www瀏覽器傳輸?shù)奖镜貫g覽器的 一種傳輸協(xié)議，
HTTP協(xié)議是由從客戶機到服務(wù)器的請求(Request)和從服務(wù)器 到客戶機的響應(yīng)(response)進行約束和規(guī)范。
2.http報文
HTTP報文：用于HTTP協(xié)議交互的信息被稱為HTTP報文。
1.請求(Request)端的報文叫請求報文
2.響應(yīng)(response)端的報文叫響應(yīng)報文
3.http 規(guī)則
1. 報文首部和報文主體中間要有空行（CR+LF:回車+換行）
2. 報文首部：處理請求和響應(yīng)提供的信息（上文中設(shè)
3. 置的各種信息）
報文主體：所需要的資源都在（比如返回的文本信息就是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!
`;
報文首部：根據(jù)實際用途會分為四種
1.通用首部字段（General）:請求報文和響應(yīng)報文都會使用的字段
2.請求首部字段（Requse Header）：請求報文使用的首部
3.響應(yīng)首部字段（Response Header）：響應(yīng)報文使用的首部
4.實體首部字段（Entity Header）：與實體有關(guān)信息的字段
所以在chrome的network中，header會顯示為：
General
Response Headers
Requse Headers
實體首部字段會寫進請求頭和響應(yīng)頭
對于get請求后邊的參數(shù)會顯示在Query String Parameters
- http 狀態(tài)碼
- 1XX : 信息性狀態(tài)碼（接收請求正在處理）
- 2XX : 成功狀態(tài)碼（請求正常處理完畢）
- 3XX : 重定向狀態(tài)碼（需要進行附加操作以完成請求）
- 4XX : 客戶端錯誤狀態(tài)碼（服務(wù)器無法處理請求）
- 5XX : 服務(wù)端錯誤狀態(tài)碼（服務(wù)器處理請求出錯）
所以狀態(tài)碼就是前后端通信時對于狀態(tài)的一種約定，原則上只要遵循狀態(tài)碼類別的定義，即使改變RFC2616定義的狀態(tài)碼，或自行創(chuàng)建都是沒問題的。
常用狀態(tài)碼：
- 200 OK ：請求被正常處理返回 200 OK，這也是我們最常見的啦
- 204 No Content :請求處理成功但是沒有資源返回，就是報文中沒有報文主體
- 206 Partial Content :客戶端進行范圍請求，就是請求資源一部分，服務(wù)器返回請求這部分（Content-Range）
- 301 Moved Permanently:永久重定向（資源的URL已經(jīng)更新）
- 302 Found :臨時重定向（資源的URI已經(jīng)臨時定位到其他位置了）
- 303 See Other: 對應(yīng)的資源存在另一URL，資源的URL已經(jīng)更新，是否按新的去訪問
- 304 Not Modified:客戶端發(fā)附帶條件的請求，服務(wù)端允許請求訪問資源，但沒有滿足條件
- 307 Temporary Redirect: 也是臨時重定向
- 400 Bad Request : 請求報文中存在語法錯誤
- 401 Unauthorized : 需要有HTTP認證
- 403 Forbidden : 請求訪問的資源被服務(wù)器拒絕了
- 404 Not Found : 服務(wù)器上沒有找到資源
- 500 Internal Server Error: 服務(wù)器執(zhí)行請求時出錯
- 503 Service Unavailable : 服務(wù)器處于超負載，正在進行停機維護
- 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é)議
強緩存：
Catche Contrl： :是通用首部字段，就是之前將的發(fā)送報文和響應(yīng)報文都會使用的?？梢詫ξ募镆觅Y源的緩存進行設(shè)置
eg:
瀏覽器發(fā)訪問http://localhost:10080/
- '請求報文沒帶 Cache-Control' 客戶端說我要訪問首頁
服務(wù)器返回數(shù)據(jù)
- '響應(yīng)報文帶:Cache-Control : max-age = 604800' 服務(wù)器說給你index.html和加載里面資源,并告訴你這些資源一周之內(nèi)不要不必確認了
瀏覽器刷新的網(wǎng)頁再次訪問http://localhost:10080/時
- 里面的資源就不會再發(fā)送請求了,直接從緩存中拿 你會在chrome,network中看到Time是0(from memory catch)
服務(wù)器返回數(shù)據(jù)
- 服務(wù)器只返回index.html文件
這時候你強制刷新瀏覽器(command+shift+R)
- '請求報文帶 Catche Contrl：no-cache '客戶端說我不要緩存過的數(shù)據(jù)，我要源服務(wù)器的數(shù)據(jù)
服務(wù)器返回數(shù)據(jù)
- 服務(wù)器返回index.html文件和依賴的資源
這就是強緩存，所謂強是在條件內(nèi)，你網(wǎng)頁依賴的資源都不會發(fā)送http請求了?？梢灾苯訌木W(wǎng)頁里面拿。
協(xié)商緩存:（兩種）
第一種. If-Modified-Since／Last-Modified
服務(wù)器會下發(fā)一個Last-Modified最后修改時間。然后瀏覽器會記住這個時間。當(dāng)瀏覽器第二次請求時會帶上if-modified-since的時間。服務(wù)器可以去比較這份文件在if-modified-since的時間后是否修改過。如果沒有修改過，那就返回304.
1. Last-Modified:標(biāo)示這個響應(yīng)資源的最后修改時間。web服務(wù)器在響應(yīng)請求時，告訴瀏覽器資源的最后修改時間。
2. If-Modified-Since:當(dāng)資源過期時(使用Cache-Control標(biāo)識的max-age)，發(fā)現(xiàn)資源具有Last-Modified聲明，則再次向web服務(wù)器請求時帶上頭 If- -Modified-Since，表示請求時間。web服務(wù)器收到請求后發(fā)現(xiàn)有頭If-Modified- Since 則與被請求資源的最后修改時間進行比對。若最后修改時間較新，說 明資源又被改動過，則響應(yīng)整片資源內(nèi)容(寫在響應(yīng)消息包體內(nèi))，HTTP 200;若最后修改時間較舊，說明資源無新修改，則響應(yīng)HTTP 304 (無需包 體，節(jié)省瀏覽)，告知瀏覽器繼續(xù)使用所保存的cache。
第二種：Etag/ If-None-Match
服務(wù)器Etag會下發(fā)一個字符串，然后瀏覽器在第二次請求時會在if-none-match中帶上這個字符串。這時候服務(wù)器可以比較兩個字符串，如果相同，就讓瀏覽器去緩存中去取。
1. Etag:web服務(wù)器響應(yīng)請求時，告訴瀏覽器當(dāng)前資源在服務(wù)器的唯一標(biāo)識(生成規(guī)則由服務(wù)器決定)
2. If-None-Match:當(dāng)資源過期時(使用Cache-Control標(biāo)識的max- age)，發(fā)現(xiàn)資源具有Etage聲明，則再次向web服務(wù)器請求時帶 上頭If-None-Match (Etag的值)。web服務(wù)器收到請求后發(fā)現(xiàn) 有頭If-None-Match 則與被請求資源的相應(yīng)校驗串進行比對，決 定返回200或304。
7.HTTP 瀏覽器緩存機制
所以可以看出，強緩存優(yōu)先于協(xié)商緩存。
- http 方法
GET：獲取資源
POST:傳輸實體主體
PUT:傳輸文件
HEAD:獲取報文首部
DELETE：刪除文件
OPTIONS：查詢支持方法
TRACK：追蹤路徑
CONNECT：要求用隧道協(xié)議連接代理
- GET 與 POST區(qū)別
瀏覽器：
GET是請求數(shù)據(jù)，使用URL或Cookie傳參。POST是傳輸實體主體所以會把參數(shù)放到報文體中
GET數(shù)據(jù)放到URL中，瀏覽器對URL大小有限制，所以數(shù)據(jù)大小進行限制。POST是傳輸實體主體，所以大小沒有限制
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請求不是。冪等性是指一次和多次請求某一個資源應(yīng)該具有同樣的副作用。簡單來說意味著對同一URL的多個請求應(yīng)該返回同樣的結(jié)果。
請求數(shù)據(jù)的時候用get，傳輸實體主體的時候用post。
瀏覽器與協(xié)議
1.XHR 與 AJAX
AJAX全稱是Asynchronous JavaScript and XML（異步j(luò)s和XML）。異步j(luò)s，我們比較容易理解。那么什么是XHR呢。
XHR全稱是XMLHttpRequest，就是XML的http的請求。其實這是一個瀏覽器層面的API。通俗點講就是瀏覽器給你封裝好了的http功能函數(shù)。
2.瀏覽器安全與跨域
XHR的會有很多限制，其中對我們影響很大的就是不允許發(fā)送不同協(xié)議，地址和端口號的請求。
那么我們常見的解決方案有三種：
1.jsonp ：是把請求偽裝成標(biāo)簽去請求。因為標(biāo)簽是瀏覽器自己發(fā)送請求，所以不受同源策略影響啊
2.代理服務(wù)器：這個也很好理解，我把所有請求都發(fā)送到不跨域的代理服務(wù)器上，服務(wù)器上可是我們說的算，只要經(jīng)過處理把數(shù)據(jù)返回給瀏覽器就好。
3.CORS：這是我們今天主要講。因為解鈴還須系鈴人，既然是你限制的，那么你總得給我一個解決辦法吧。瀏覽器給出的解決辦法就是（CORS）
cors的辦法也很簡單：
1.如果瀏覽器發(fā)現(xiàn)你已經(jīng)跨域了它會發(fā)送一個帶原IP的請求頭Origin: http://localhost:8088
2.問服務(wù)器，你讓不讓localhost:8088訪問你的文件啊，如果瀏覽器同意就回復(fù)一個Access-Control-Allow-Origin： http://localhost:8088 。表示，這個IP可以訪問的
3.然后服務(wù)器在發(fā)起正式請求
4.如果服務(wù)器沒有給瀏覽器返回Access-Control-Allow-Origin或不允許這個地址訪問，那么瀏覽器就報跨域請求錯誤
當(dāng)然，為了安全起見CORS的請求都會忽略掉cookie 和 HTTP認證等用戶憑證。如果你想用，同樣在請求頭帶Origin時在發(fā)送一些參數(shù)。服務(wù)器也是在第一次返回時告訴瀏覽器同意還是不同意。
http發(fā)展
1.HTTP1.0 到http1.1
HTTP1.0的時候，每次發(fā)送一個http請求就要建立一次TCP連接，然后再斷開
http1.1的時候，引入了Connection:keep-alive的機制，連接后不斷開可以繼續(xù)發(fā)送請求
但每次請求都是第一個回來，第二個再出發(fā)。后來瀏覽器又引入了 pipelining的管道化連接。
在一個TCP連接內(nèi)，多個HTTP請求可以并行，下一個HTTP請求在上一個HTTP請求的應(yīng)答完成之前就發(fā)起
這個不需要你去設(shè)置，引入了Connection:keep-alive，瀏覽器自動會這么處理。但這又有一個問題，由于HTTP1.1服務(wù)端返回響應(yīng)數(shù)據(jù)的順序必須跟客戶端請求時的順序一致，這樣也就是要求先進先出。所以很容易造成隊首阻塞。就是你第一個請求不返回，后面都得在那等著。
2.HTTPS
HTTPS是針對HTTP安全性不足，做的改進，我們先看看HTTP安全性都有哪些不足
通信就是明文
沒有驗證通信方身份
無法證明報文完整性
所以 HTTS = HTTP + 加密 + 認證 + 完整性保護 **
加密解密：
比如我有一份數(shù)據(jù)要給你，我只需要把它加密了，你在解密這樣不就安全了。
所以我有一個私鑰用來加密，給別人解密的是公鑰
但是這個時候，我們又不能保證別人拿到的公鑰就是我的公鑰。萬一數(shù)據(jù)沒有變，但是公鑰被劫持，解密出來的內(nèi)容就也不是我想發(fā)給對方的啦
所以我把公鑰交給第三方CA認證一下，第三方把公鑰變成了證書
這樣瀏覽器再拿到我發(fā)給它的證書的時候，他去和第三方CA問一下，這是不是他的證書啊。
第三方說是，這樣我們就安全了。
同樣瀏覽器也會以同樣的私鑰和證書的方式對傳給服務(wù)器的數(shù)據(jù)進行加密解密。在第三方認證的時候，我們會詳細登記自己的信息。這樣我們彼此也就完成了身份認證。
最后，這個加密算法還用摘要功能來保證數(shù)據(jù)的完整性
總結(jié)：
HTTPS協(xié)議只是HTTP通信接口部分用SSL協(xié)議代替而已。而剛才我們講的這個過程就是SSL協(xié)議的內(nèi)容。它是由網(wǎng)景公司發(fā)明，后來轉(zhuǎn)交給IETF,IETF在SSL基礎(chǔ)上制定的TLS
3.HTTP2.0
（1）多路復(fù)用，并不在遵循先進先出。
那么現(xiàn)在有一個問題，http2中，既然沒有先進先出，那么重要的文件加載的慢，那不就尷尬啦。
（2）http2定義了請求優(yōu)先級
我們可以讓一些重要的請求優(yōu)先加載。瀏覽器也智能的根據(jù)http2定義出的優(yōu)先級規(guī)則去顯示頁面。
（3）頭部壓縮
我們知道我們在用Gzip方式給報文體進行壓縮。http2給報文頭也進行了壓縮。你可別小看了報文頭，一般網(wǎng)頁的報文頭能占到報文的40%。 而壓縮后能減少60%左右。
（4）性能上新增了二進制分幀層。也得到了大大的提升。分針層對應(yīng)的就是http報文。所以http/1.1是一個文本協(xié)議，而 http2 是一個徹徹底底的二進制協(xié)議。
