計(jì)算機(jī)網(wǎng)絡(luò)是一個(gè)很龐大的區(qū)域妒茬，從物理機(jī)器到路由器、基站到你的手機(jī)終端蔚晨，當(dāng)今我們和整個(gè)世界的連接都靠著這個(gè)無形的紐帶乍钻，它帶給我了無限的想象和豐富的資訊。探討一下計(jì)算機(jī)網(wǎng)絡(luò)中的HTTP和HTTPS是很有必要的铭腕！

HTTP協(xié)議

HTTP(Hyper Text Transfer Protocol）超文本傳輸協(xié)議银择，是處于網(wǎng)絡(luò)層次中的應(yīng)用層。HTTP協(xié)議是C/S架構(gòu)的累舷，客戶端與服務(wù)器之間的HTTP連接是一種一次性連接浩考，它限制每次連接只處理一個(gè)請求，當(dāng)服務(wù)器返回本次請求的應(yīng)答后便立即關(guān)閉連接被盈，下次請求再重新建立連接析孽。這種一次性連接主要考慮到服務(wù)器面向的是Internet中成干上萬個(gè)用戶，且只能提供有限個(gè)連接只怎，故服務(wù)器不會(huì)讓一個(gè)連接處于等待狀態(tài)袜瞬，及時(shí)地釋放連接可以大大提高服務(wù)器的執(zhí)行效率。

網(wǎng)絡(luò)層次

計(jì)算機(jī)中的網(wǎng)絡(luò)層次中包含了許多的協(xié)議身堡，有些協(xié)議是相互依賴的邓尤，HTTP協(xié)議是依賴于TCP/IP的協(xié)議，你當(dāng)然可以直接根據(jù)TCP/IP來進(jìn)行通信贴谎，但是那不是大眾認(rèn)可的汞扎，HTTP協(xié)議的本質(zhì)就是一種大家認(rèn)可的規(guī)范。同理網(wǎng)絡(luò)層次也是一種大家都認(rèn)可的規(guī)范擅这。
常用的網(wǎng)絡(luò)分層有OSI/RM七層和TCP/IP四層澈魄，以及TCP/IP五層。

image.png

可以看到OSI的協(xié)議是對TCP/IP的細(xì)分蕾哟，多分了表示層和會(huì)話層一忱。莲蜘、

• 物理層： 激活、維持帘营、關(guān)閉通信斷電之間的機(jī)械性票渠、電氣特性、功能特性以及過程特性芬迄；該層為上層協(xié)議提供了一個(gè)傳輸數(shù)據(jù)的可靠物理媒體问顷。物理層確保原始的數(shù)據(jù)可以在各種物理媒體上傳輸。物理層較為重要的兩個(gè)設(shè)備：中繼器（Repeater 也叫放大器）禀梳、集線器杜窄。
• 數(shù)據(jù)鏈路層： 數(shù)據(jù)鏈路層在物理層提供的服務(wù)基礎(chǔ)上想網(wǎng)絡(luò)層提供服務(wù)；其最基本的服務(wù)是將源自網(wǎng)絡(luò)層來的數(shù)據(jù)可靠地傳輸?shù)较噜徆?jié)點(diǎn)的網(wǎng)絡(luò)層算途。為達(dá)到這一目的塞耕，數(shù)據(jù)鏈路層具備一系列相應(yīng)的功能：如何將數(shù)據(jù)組成數(shù)據(jù)塊，在數(shù)據(jù)鏈路層中這種數(shù)據(jù)開稱為“幀”（frame）嘴瓤。幀是數(shù)據(jù)鏈路層的傳輸單位扫外；如何控制幀在物理信道上傳輸，包括如何處理傳輸差錯(cuò)廓脆，如何調(diào)節(jié)發(fā)送速率與接收方相匹配筛谚；以及在兩個(gè)實(shí)體之間提供數(shù)據(jù)鏈路的建立、維持和釋放的管理停忿。數(shù)據(jù)鏈路層在不可靠的物理介質(zhì)上提供可靠的傳輸驾讲。該層的作用包括：物理地址的尋址、數(shù)據(jù)的成幀席赂、流量的控制吮铭、數(shù)據(jù)的檢錯(cuò)、重發(fā)等氧枣。
  簡單來說：數(shù)據(jù)鏈路層為網(wǎng)絡(luò)提供可靠的數(shù)據(jù)傳輸沐兵； 基本數(shù)據(jù)單位——幀别垮；主要協(xié)議：以太網(wǎng)協(xié)議便监； 兩個(gè)重要的設(shè)備：網(wǎng)橋、交換機(jī)
• 網(wǎng)絡(luò)層：網(wǎng)絡(luò)層的目的是實(shí)現(xiàn)兩個(gè)終端之間的數(shù)據(jù)透明傳送碳想，具體功能包含尋址和路由選擇烧董、連接的建立、保持和終止胧奔。它提供的服務(wù)是網(wǎng)絡(luò)層負(fù)責(zé)對子網(wǎng)間的數(shù)據(jù)包進(jìn)行路由選擇逊移。此外，網(wǎng)絡(luò)層還可以實(shí)現(xiàn)擁塞控制和龙填、網(wǎng)際互連等功能胳泉；基本數(shù)據(jù)單位為IP數(shù)據(jù)報(bào)拐叉；包含的主要協(xié)議：IP協(xié)議（Internet Protocol更啄，因特網(wǎng)互聯(lián)協(xié)議）箕昭、ICMP協(xié)議（Internet Control Message Protocol，因特網(wǎng)控制報(bào)文協(xié)議）拂封、ARP協(xié)議（Address Resolution Protocol案铺，地址解析協(xié)議）蔬芥、RARP協(xié)議（Reverse Address Resolution Protocol，逆地址解析協(xié)議）;重要設(shè)備：路由器控汉。
• 傳輸層： 傳輸層主要負(fù)責(zé)上層數(shù)據(jù)分段并提供端到端笔诵、可靠的或者不可靠的傳輸。此外姑子，傳輸層還要處理端到端的差錯(cuò)控制和流量控制的問題乎婿；傳輸層的任務(wù)是根據(jù)通信子網(wǎng)的特性，最佳的利用網(wǎng)絡(luò)資源街佑，為兩個(gè)系統(tǒng)的會(huì)話之間次酌，提供建立、維護(hù)和取消傳輸連接的功能舆乔，負(fù)責(zé)端到端的可靠數(shù)據(jù)傳輸岳服。在這一層，信息傳送的數(shù)據(jù)單元稱為段或者報(bào)文希俩。傳輸層負(fù)責(zé)將上層數(shù)據(jù)分段并提供端到端的吊宋，可靠或者不可靠的以及端到端的差錯(cuò)控制和流量控制問題；包含的協(xié)議：TCP協(xié)議（Transmission Control Protocol颜武，傳輸控制協(xié)議）璃搜、UDP協(xié)議（User Datagram Protocol，用戶數(shù)據(jù)報(bào)協(xié)議）重要設(shè)備：網(wǎng)關(guān)
• 表示層 會(huì)話層 應(yīng)用層
  會(huì)話層：管理主機(jī)之間的會(huì)話進(jìn)程鳞上，即負(fù)責(zé)建立这吻、管理、終止進(jìn)程之間的會(huì)篙议。會(huì)話層還利用在數(shù)據(jù)中插入校驗(yàn)點(diǎn)來實(shí)現(xiàn)數(shù)據(jù)的同步唾糯。
  表示層：對上層數(shù)據(jù)或信息盡心變化以保證一個(gè)主機(jī)應(yīng)用層信息可以被另一個(gè)主機(jī)的應(yīng)用程序理解。表示層的數(shù)據(jù)轉(zhuǎn)換包括數(shù)據(jù)的加密鬼贱、壓縮移怯、格式轉(zhuǎn)換等。
  應(yīng)用層：為操作系統(tǒng)或網(wǎng)絡(luò)應(yīng)用程序提供訪問網(wǎng)絡(luò)服務(wù)的接口这难。
  三層的重點(diǎn)：
  數(shù)據(jù)傳輸基本單位為報(bào)文舟误；
  包含的主要協(xié)議：FTP（文件傳送協(xié)議）、Telent（遠(yuǎn)程登陸協(xié)議）姻乓、DNS（域名解析協(xié)議）嵌溢、SMTP（郵件傳送協(xié)議）眯牧、POP3協(xié)議（郵局協(xié)議）、HTTP協(xié)議（Hyper Text Transfer Protocol）赖草、SNMP協(xié)議（簡單網(wǎng)絡(luò)協(xié)議炸站，是封裝UDP的一種協(xié)議）
  （基于TCP的應(yīng)用層協(xié)議有：SMTP、TELNET疚顷、HTTP旱易、FTP
  基于UDP的應(yīng)用層協(xié)議：DNS、TFTP（簡單文件傳輸協(xié)議）腿堤、RIP（路由選擇協(xié)議）阀坏、DHCP、BOOTP（是DHCP的前身）笆檀、IGMP（Internet組管理協(xié)議））
• 報(bào)文：報(bào)文(message)是網(wǎng)絡(luò)中交換與傳輸?shù)幕締卧商茫凑军c(diǎn)一次性要發(fā)送的數(shù)據(jù)塊，報(bào)文包含了將要發(fā)送的完整的數(shù)據(jù)信息酗洒，其長短很不一致士修，長度不限且可變。
  
  image.png

HTTP協(xié)議的構(gòu)成

HTTP協(xié)議自1991年發(fā)布了第一個(gè)版本HTTP0.9到現(xiàn)在的HTTP3.0(HTTP制作小組還在制作樱衷，據(jù)說是放棄TCP擁抱UPD協(xié)議了）棋嘲。HTTP URL的格式如下所示：
http://host[＂:＂port][abs_path]
http表示要通過HTTP協(xié)議來定位網(wǎng)絡(luò)資源；host表示合法的Internet主機(jī)域名或者IP地址矩桂；
port指定一個(gè)端口號(hào)沸移，為空則使用默認(rèn)端口80；
abs_path指定請求資源的URI（Web上任意的可用資源）侄榴。
HTTP有兩種報(bào)文雹锣，分別是請求報(bào)文和響應(yīng)報(bào)文，下面先來查看請求報(bào)文

請求報(bào)文

HTTP的報(bào)文都是面向文本的癞蚕，報(bào)文中的每一個(gè)字段都是一些ASCII碼串蕊爵，各個(gè)字段的長度是不確定，一般一個(gè)HTTP請求報(bào)文由請求行 桦山、請求頭攒射、 以及請求數(shù)據(jù)、空行四個(gè)部分組成

image.png

• 請求行：請求行由請求方法度苔、URL字段和HTTP協(xié)議版本組成匆篓，格式如下：
  Method Request-URI HTTP-Version CRLF
  其中 Method表示請求方法浑度；Request-URI是一個(gè)統(tǒng)一資源標(biāo)識(shí)符寇窑；HTTP-Version表示請求的HTTP協(xié)議
  版本；CRLF表示回車和換行（除了作為結(jié)尾的CRLF外箩张，不允許出現(xiàn)單獨(dú)的CR或LF字符）甩骏。
  HTTP請求方法有8種窗市，分別是GET、POST饮笛、HEAD咨察、PUT、DELETE福青、TRACE摄狱、CONNECT、
  OPTIONS无午。對于移動(dòng)開發(fā)最常用的就是GET和POST了媒役。
  ? GET：請求獲取Request-URI所標(biāo)識(shí)的資源。
  ? POST：在Request-URI所標(biāo)識(shí)的資源后附加新的數(shù)據(jù)宪迟。
  ? HEAD：請求獲取由Request-URI所標(biāo)識(shí)的資源的響應(yīng)消息報(bào)頭酣衷。
  ? PUT：請求服務(wù)器存儲(chǔ)一個(gè)資源，并用Request-URI作為其標(biāo)識(shí)次泽。
  ? DELETE：請求服務(wù)器刪除Request-URI所標(biāo)識(shí)的資源穿仪。
  ? TRACE：請求服務(wù)器回送收到的請求信息，主要用于測試或診斷意荤。
  ? CONNECT：HTTP 1.1協(xié)議中預(yù)留給能夠?qū)⑦B接改為管道方式的代理服務(wù)器啊片。
  ? OPTIONS：請求查詢服務(wù)器的性能，或者查詢與資源相關(guān)的選項(xiàng)和需求玖像。
  例如钠龙，訪問百度：
  GET http://ww.baidu.com HTTP/1.1
• 請求報(bào)頭
  ? Host：請求的主機(jī)名，允許多個(gè)域名同處一個(gè)IP地址御铃，即虛擬主機(jī)碴里。
  ? User-Agent：發(fā)送請求的瀏覽器類型、操作系統(tǒng)等信息上真。
  ? Accept：客戶端可識(shí)別的內(nèi)容類型列表咬腋，用于指定客戶端接收哪些類型的信息。
  ? Accept-Encoding：客戶端可識(shí)別的數(shù)據(jù)編碼睡互。
  ? Accept-Language：表示瀏覽器所支持的語言類型根竿。
  ? Connection：允許客戶端和服務(wù)器指定與請求/響應(yīng)連接有關(guān)的選項(xiàng)。例如就珠，這時(shí)為Keep-Alive則表示
  保持連接寇壳。
  ? Transfer-Encoding：告知接收端為了保證報(bào)文的可靠傳輸，對報(bào)文采用了什么編碼方式妻怎。
• 請求數(shù)據(jù)
  請求數(shù)據(jù)不在GET方法中使用壳炎，而在POST方法中使用，POST方法適用于需要客戶填寫表單的場合逼侦。

響應(yīng)報(bào)文

image.png

• 狀態(tài)行铲球，狀態(tài)行的格式一般為：
  HTTP-Version Status-Code Reason-Phrase CRLF
  其中HTTP-Version代表服務(wù)器的協(xié)議版本挺庞，status-code表示服務(wù)器回應(yīng)的狀態(tài)碼，Reason-Phrase表示狀態(tài)碼的文本秒描述稼病，狀態(tài)碼由三位數(shù)字組成选侨，第一個(gè)數(shù)字定義了響應(yīng)的類別。
  ? 100～199：指示信息然走，收到請求侵俗，需要請求者繼續(xù)執(zhí)行操作。
  ? 200～299：請求成功丰刊，請求已被成功接收并處理隘谣。
  ? 300～399：重定向，要完成請求必須進(jìn)行更進(jìn)一步的操作啄巧。
  ? 400～499：客戶端錯(cuò)誤寻歧，請求有語法錯(cuò)誤或請求無法實(shí)現(xiàn)。
  ? 500～599：服務(wù)器錯(cuò)誤秩仆，服務(wù)器不能實(shí)現(xiàn)合法的請求码泛。
  常見的狀態(tài)碼如下。
  ? 200 OK：客戶端請求成功澄耍。
  ? 400 Bad Request：客戶端請求有語法錯(cuò)誤噪珊，服務(wù)器無法理解。
  ? 401 Unauthorized：請求未經(jīng)授權(quán)齐莲，這個(gè)狀態(tài)碼必須和WWW-Authenticate報(bào)頭域一起使用痢站。
  ? 403 Forbidden：服務(wù)器收到請求，但是拒絕提供服務(wù)选酗。
  ? 500 Internal Server Error：服務(wù)器內(nèi)部錯(cuò)誤阵难，無法完成請求。
  ? 503 Server Unavailable：服務(wù)器當(dāng)前不能處理客戶端的請求芒填，一段時(shí)間后可能恢復(fù)正常。
  例如殿衰，狀態(tài)行：
  HTTP/1.1 200 OK

TCP的三次握手和四次揮手

image.png

三次握手

LISTEN: 這個(gè)也是非常容易理解的一個(gè)狀態(tài)闷祥，表示服務(wù)器端的某個(gè)SOCKET處于監(jiān)聽狀態(tài)娱颊，可以接受連接了。
SYN_SENT: 當(dāng)客戶端SOCKET執(zhí)行CONNECT連接時(shí)，它首先發(fā)送SYN報(bào)文掰吕，因此也隨即它會(huì)進(jìn)入到了SYN_SENT狀態(tài)颅痊，并等待服務(wù)端的發(fā)送三次握手中的第2個(gè)報(bào)文。SYN_SENT狀態(tài)表示客戶端已發(fā)送SYN報(bào)文局待。（發(fā)送端）
SYN_RCVD: 這個(gè)狀態(tài)與SYN_SENT遙想呼應(yīng)這個(gè)狀態(tài)表示接受到了SYN報(bào)文斑响，在正常情況下钳榨，這個(gè)狀態(tài)是服務(wù)器端的SOCKET在建立TCP連接時(shí)的三次握手會(huì)話過程中的一個(gè)中間狀態(tài)，很短暫薛耻，基本上用netstat你是很難看到這種狀態(tài)的饼齿，除非你特意寫了一個(gè)客戶端測試程序，故意將三次TCP握手過程中最后一個(gè)ACK報(bào)文不予發(fā)送缕溉。因此這種狀態(tài)時(shí)，當(dāng)收到客戶端的ACK報(bào)文后僚楞，它會(huì)進(jìn)入到ESTABLISHED狀態(tài)枉层。（服務(wù)器端）
ESTABLISHED: 這個(gè)容易理解了，表示連接已經(jīng)建立了兴枯。

四次揮手：

FIN_WAIT_1: 這個(gè)狀態(tài)要好好解釋一下矩欠，其實(shí)FIN_WAIT_1和FIN_WAIT_2狀態(tài)的真正含義都是表示等待對方的FIN報(bào)文。而這兩種狀態(tài)的區(qū)別是：FIN_WAIT_1狀態(tài)實(shí)際上是當(dāng)SOCKET在ESTABLISHED狀態(tài)時(shí)躺坟，它想主動(dòng)關(guān)閉連接乳蓄，向?qū)Ψ桨l(fā)送了FIN報(bào)文，此時(shí)該SOCKET即進(jìn)入到FIN_WAIT_1狀態(tài)美侦。而當(dāng)對方回應(yīng)ACK報(bào)文后，則進(jìn)入到FIN_WAIT_2狀態(tài)易猫，當(dāng)然在實(shí)際的正常情況下具壮，無論對方何種情況下，都應(yīng)該馬上回應(yīng)ACK報(bào)文棺妓，所以FIN_WAIT_1狀態(tài)一般是比較難見到的攘已，而FIN_WAIT_2狀態(tài)還有時(shí)常沉埽可以用netstat看到性芬。（主動(dòng)方）
FIN_WAIT_2: 上面已經(jīng)詳細(xì)解釋了這種狀態(tài)，實(shí)際上FIN_WAIT_2狀態(tài)下的SOCKET批旺，表示半連接汽煮，也即有一方要求close連接，但另外還告訴對方心例，我暫時(shí)還有點(diǎn)數(shù)據(jù)需要傳送給你(ACK信息)鞋囊，稍后再關(guān)閉連接。（主動(dòng)方）
TIME_WAIT: 表示收到了對方的FIN報(bào)文译株，并發(fā)送出了ACK報(bào)文挺益，就等2MSL后即可回到CLOSED可用狀態(tài)了望众。如果FIN_WAIT_1狀態(tài)下伞辛，收到了對方同時(shí)帶FIN標(biāo)志和ACK標(biāo)志的報(bào)文時(shí)夯缺，可以直接進(jìn)入到TIME_WAIT狀態(tài)踊兜，而無須經(jīng)過FIN_WAIT_2狀態(tài)。（主動(dòng)方）
CLOSING: 這種狀態(tài)比較特殊（比較少見）姐呐，實(shí)際情況中應(yīng)該是很少見典蝌，屬于一種比較罕見的例外狀態(tài)头谜。正常情況下，當(dāng)你發(fā)送FIN報(bào)文后截驮，按理來說是應(yīng)該先收到（或同時(shí)收到）對方的ACK報(bào)文葵袭，再收到對方的FIN報(bào)文乖菱。但是CLOSING狀態(tài)表示你發(fā)送FIN報(bào)文后，并沒有收到對方的ACK報(bào)文鹉勒，反而卻也收到了對方的FIN報(bào)文吵取。什么情況下會(huì)出現(xiàn)此種情況呢？其實(shí)細(xì)想一下脯倒，也不難得出結(jié)論：那就是如果雙方幾乎在同時(shí)close一個(gè)SOCKET的話捺氢，那么就出現(xiàn)了雙方同時(shí)發(fā)送FIN報(bào)文的情況讯沈，也即會(huì)出現(xiàn)CLOSING狀態(tài)婿奔，表示雙方都正在關(guān)閉SOCKET連接萍摊。
CLOSE_WAIT: 這種狀態(tài)的含義其實(shí)是表示在等待關(guān)閉如叼。怎么理解呢？當(dāng)對方close一個(gè)SOCKET后發(fā)送FIN報(bào)文給自己踊沸，你系統(tǒng)毫無疑問地會(huì)回應(yīng)一個(gè)ACK報(bào)文給對方社证，此時(shí)則進(jìn)入到CLOSE_WAIT狀態(tài)追葡。接下來呢，實(shí)際上你真正需要考慮的事情是察看你是否還有數(shù)據(jù)發(fā)送給對方匀钧，如果沒有的話谬返，那么你也就可以close這個(gè)SOCKET，發(fā)送FIN報(bào)文給對方佑刷，也即關(guān)閉連接翰蠢。所以你在CLOSE_WAIT狀態(tài)下梁沧，需要完成的事情是等待你去關(guān)閉連接。（被動(dòng)方）
LAST_ACK: 這個(gè)狀態(tài)還是比較容易好理解的频鉴，它是被動(dòng)關(guān)閉一方在發(fā)送FIN報(bào)文后恋拍，最后等待對方的ACK報(bào)文施敢。當(dāng)收到ACK報(bào)文后狭莱，也即可以進(jìn)入到CLOSED可用狀態(tài)了概作。（被動(dòng)方）
CLOSED: 表示連接中斷讯榕。

Https的校驗(yàn)過程

image.png

image.png

TCP和UDP的區(qū)別

TCP是可靠的傳輸協(xié)議：最主要和最重要的就是TCP采用了重發(fā)的技術(shù)愚屁，具體來說，TCP在傳輸?shù)倪^程中送浊，發(fā)送方啟動(dòng)了一個(gè)定時(shí)器栽燕，然后將數(shù)據(jù)包發(fā)出改淑，當(dāng)接收方收到了這個(gè)信息時(shí)就給發(fā)發(fā)送方一個(gè)ACK字段朵夏，如果發(fā)送發(fā)在定時(shí)器到點(diǎn)之前沒有收到這個(gè)確認(rèn)信息，就重新發(fā)送這個(gè)數(shù)據(jù)包捏肢。
對于UDP協(xié)議來說（用戶數(shù)據(jù)報(bào)協(xié)議）是一種不可靠饥侵，無連接的協(xié)議躏升，可以保證應(yīng)用程序進(jìn)程間通信。UDP的錯(cuò)誤檢測功能弱的多一睁，UDP協(xié)議的主要作用是將UDP消息展示給應(yīng)用層佃却，它并不負(fù)責(zé)重新發(fā)送丟失的或出錯(cuò)的數(shù)據(jù)消息饲帅，不對接受到的無序IP數(shù)據(jù)重新排序瘤泪，不消除重復(fù)的IP數(shù)據(jù)報(bào)育八，不對接受到的數(shù)據(jù)報(bào)進(jìn)行確認(rèn)单鹿，也不負(fù)責(zé)建立或終止連接。

Https的驗(yàn)證分為雙向認(rèn)證和單向認(rèn)證劲妙。

HTTPS協(xié)議是在HTTP協(xié)議的基礎(chǔ)上添加了SSL/TLS（TLS1.0和SSL3.0幾乎沒有區(qū)別就稱為TLS協(xié)議）儒喊，是對傳輸?shù)臄?shù)據(jù)進(jìn)行了一次加密的過程怀愧，保證了通信安全，但是也會(huì)出現(xiàn)一些時(shí)間和性能的耗時(shí)哈垢。在進(jìn)行驗(yàn)證之后扛拨，會(huì)進(jìn)行TCP的握手過程。
單向認(rèn)證：是指在服務(wù)端傳遞證書回來的時(shí)候求泰，不進(jìn)行校驗(yàn)渴频，信任這個(gè)證書
雙向認(rèn)證：是指在客戶端對服務(wù)器傳遞的證書進(jìn)行校驗(yàn)北启，判斷這個(gè)證書是否在客戶端信任的列表中，否則就不進(jìn)行通信聊替。

HTTP2.0

HTTP1.x是基于文件解析協(xié)議的惹悄，基于文本協(xié)議的意思是每次讀取數(shù)據(jù)的時(shí)候都需要按行讀取肩钠，這樣會(huì)給接受數(shù)據(jù)的一方帶來復(fù)雜的計(jì)算暂殖。
HTTP2.0 ：將消息分割為更小的幀和消息呛每，并對它們采用二進(jìn)制編碼坡氯。

image.png

將HTTP1 的文本協(xié)議轉(zhuǎn)換為了二進(jìn)制的幀箫柳。

二進(jìn)制幀

二進(jìn)制幀是2.0通信的最小單位悯恍，包括幀首部，流標(biāo)識(shí)符瞬欧，優(yōu)先值罢防，幀凈荷等。

image.png

幀的類型：

• DATA：用于傳輸HTTP消息體
• HEADERS:用于傳輸首部字段
• SETTINGS：用于約定客戶端和服務(wù)端的配置數(shù)據(jù)，比如設(shè)置初識(shí)的雙向流量控制窗口的大小渤滞。

• WIN

  
  
  image.png
  
  
  image.png