前言

過年倒計時～

今天是網(wǎng)絡(luò)篇的最后一篇呜投，網(wǎng)絡(luò)知識也是面試常考內(nèi)容，所以必須要把基礎(chǔ)知識打牢宙彪。

網(wǎng)絡(luò)十二問矩动，送給大家。

這些問題释漆，你能答上來嗎

我總結(jié)了下網(wǎng)絡(luò)方面會涉及到的一些問題悲没，大家看看，如果都能答上來男图，那這篇文章就可以略過了示姿。

• 網(wǎng)絡(luò)通信的過程，以及中間用了什么協(xié)議逊笆？
• TCP連接過程栈戳，三次握手和四次揮手，為什么难裆？
• 常用的狀態(tài)碼子檀。
• 講一下TCP協(xié)議和UDP協(xié)議的區(qū)別和場景
• socket和WebSocket
• Https的鏈接建立過程
• 講解一下數(shù)字簽名，為什么真實可靠
• 證書鏈安全機制
• 建立過程耗時乃戈，那么怎么優(yōu)化呢褂痰？
• 講一下Http和Https的區(qū)別
• Http傳輸圖片有哪些方式
• 怎么實現(xiàn)分塊傳輸，斷點續(xù)傳症虑？

網(wǎng)絡(luò)通信的過程缩歪，以及中間用了什么協(xié)議

這個問題我之前專門做了一個動畫，大家可以翻到上一篇文章看看：

網(wǎng)絡(luò)數(shù)據(jù)原來是這么傳輸?shù)模ńY(jié)合動畫解析）

再簡單總結(jié)下：

客戶端：

• 1谍憔、在瀏覽器輸入網(wǎng)址
• 2匪蝙、瀏覽器解析網(wǎng)址，并生成http請求消息
• 3习贫、瀏覽器調(diào)用系統(tǒng)解析器逛球，發(fā)送消息到DNS服務(wù)器查詢域名對應(yīng)的ip
• 4、拿到ip后沈条，和請求消息一起交給操作系統(tǒng)協(xié)議棧的TCP模塊
• 5需忿、將數(shù)據(jù)分成一個個數(shù)據(jù)包，并加上TCP報頭形成TCP數(shù)據(jù)包
• 6蜡歹、TCP報頭包括發(fā)送方端口號屋厘、接收方端口號、數(shù)據(jù)包的序號月而、ACK號汗洒。
• 7、然后將TCP消息交給IP模塊父款。
• 8溢谤、IP模塊會添加IP頭部和MAC頭部瞻凤。
• 9、IP頭部包括IP地址世杀，為IP模塊使用阀参，MAC頭部包括MAC地址，為數(shù)據(jù)鏈路層使用瞻坝。
• 10蛛壳、IP模塊會把整個消息包交給網(wǎng)絡(luò)硬件，也就是數(shù)據(jù)鏈路層所刀，比如以太網(wǎng)衙荐，WIFI等
• 11、然后網(wǎng)卡會將這些包轉(zhuǎn)換成電信號或者在光信號浮创，通過網(wǎng)線或者光纖發(fā)送出去忧吟，再由路由器等轉(zhuǎn)發(fā)設(shè)備送達接收方。

服務(wù)器端：

• 1斩披、數(shù)據(jù)包到達服務(wù)器的數(shù)據(jù)鏈路層溜族，比如以太網(wǎng)，然后會將其轉(zhuǎn)換為數(shù)據(jù)包（數(shù)字信號）交給IP模塊雏掠。
• 2斩祭、IP模塊會將MAC頭部和IP頭部后面的內(nèi)容劣像，也就是TCP數(shù)據(jù)包發(fā)送給TCP模塊乡话。
• 3、TCP模塊會解析TCP頭信息耳奕，然后和客戶端溝通表示收到這個數(shù)據(jù)包了绑青。
• 4、TCP模塊在收到消息的所有數(shù)據(jù)包之后屋群，就會封裝好消息闸婴，生成相應(yīng)報文發(fā)給應(yīng)用層，也就是HTTP層芍躏。
• 5邪乍、HTTP層收到消息，比如是HTML數(shù)據(jù)对竣，就會解析這個HTML數(shù)據(jù)庇楞，最終繪制到瀏覽器頁面上。

TCP連接過程否纬，三次握手和四次揮手吕晌，為什么？

連接階段（三次握手）：

• 創(chuàng)建套接字Socket临燃，服務(wù)器會在啟動的時候就創(chuàng)建好睛驳，客戶端是在需要訪問服務(wù)器的時候創(chuàng)建套接字
• 然后發(fā)起連接操作烙心，其實就是Socket的connect方法
• 這時候客戶端會生成一個TCP數(shù)據(jù)包。這個數(shù)據(jù)包的TCP頭部有三個重要信息：SYN乏沸、SEQ淫茵、ACK。

SYN,同步序列編號蹬跃，是TCP/IP建立連接時使用的握手信號痘昌，如果這個值為1就代表是連接消息。
SEQ,數(shù)據(jù)包序號炬转，是發(fā)送數(shù)據(jù)的一個順序編號辆苔。
ACK，確認號扼劈，是接收數(shù)據(jù)的一個順序編號驻啤。

• 所以客戶端就生成了這樣一個數(shù)據(jù)包，其中頭部信息的SYN設(shè)置為1荐吵，代表連接骑冗。SEQ設(shè)置一個隨機數(shù)，代表初始序號先煎，比如100贼涩。ACK沒有設(shè)置，因為是第一次發(fā)送數(shù)據(jù)薯蝎，不需要ACK棠隐。
• 然后服務(wù)器端收到這個消息心铃，知道了客戶端是要來連接的（SYN=1），知道了傳輸數(shù)據(jù)的初始序號（SEQ=100）。
• 服務(wù)器端也要生成一個數(shù)據(jù)包發(fā)送給客戶端煞茫，這個數(shù)據(jù)包的TCP頭部會包含三個值：表示我也要連接你的SYN（SYN=1）会油，我已經(jīng)收到了你的上個數(shù)據(jù)包的確認號ACK（ACK=SEQ+1=101）虚缎，以及服務(wù)器端隨機生成的一個序號SEQ（比如SEQ=200）章钾。
• 最后客戶端收到這個消息后，表示客戶端到服務(wù)器的連接是無誤了艺演，然后再發(fā)送一個數(shù)據(jù)包表示也確認收到了服務(wù)器發(fā)來的數(shù)據(jù)包却紧，這個數(shù)據(jù)包的頭部就主要就是一個ACK值（ACK=SEQ+1=201）。
• 至此胎撤，連接成功晓殊，三次握手結(jié)束，后面數(shù)據(jù)就會正常傳輸哩照，并且每次都要帶上TCP頭部中的SEQ和ACK值挺物。

這里有個問題是關(guān)于為什么需要三次握手？

最主要的原因就是需要通信雙方都確認自己的消息被準確傳達過去了飘弧。

A發(fā)送消息給B识藤，B回一條消息表示我收到了砚著，這個過程就保證了A的通信能力。
B發(fā)送消息給A痴昧，A回一條消息表示我收到了稽穆，這個過程就保證了B的通信能力。

也就是四條消息能保證雙方的消息發(fā)送都是正常的赶撰，其中B回消息和B發(fā)消息舌镶，可以融合為一次消息，所以就有了三次握手豪娜。

02tcp1.png

數(shù)據(jù)傳輸階段：

數(shù)據(jù)傳輸階段有個改變就是ACK確認號不再是SEQ+1了餐胀，而是SEQ+數(shù)據(jù)長度。例如：

• A發(fā)送給B的數(shù)據(jù)包（SEQ=100瘤载，長度=1000字節(jié)）
• B回給A的數(shù)據(jù)包（ACK=100+1000=1100）

這就是一次數(shù)據(jù)傳輸?shù)念^部信息否灾，ACK代表下個數(shù)據(jù)包應(yīng)該從哪個字節(jié)開始所以等于上個數(shù)據(jù)包的SEQ+長度，SEQ就等于上個數(shù)據(jù)包的ACK鸣奔。

當然墨技，TCP通信是雙向的，所以實際數(shù)據(jù)每個消息都會有SEQ和ACK：

• A發(fā)送給B的數(shù)據(jù)包（ACK=200挎狸，SEQ=100扣汪，長度=1000字節(jié)）
• B回給A的數(shù)據(jù)包（ACK=100+1000=1100，SEQ=上一個數(shù)據(jù)包的ACK=200锨匆，長度=500字節(jié)）
• A發(fā)送給B數(shù)據(jù)包（SEQ=1100崭别，ACK=200+500=700）

02tcp2.png

斷開階段（四次揮手）：

和連接階段一樣，TCP頭部也有一個專門用作關(guān)閉連接的值叫做FIN统刮。

• 客戶端準備關(guān)閉連接紊遵，會發(fā)送一個TCP數(shù)據(jù)包，頭部信息中包括（FIN=1代表要斷開連接）侥蒙。

• 服務(wù)器端收到消息，回復一個數(shù)據(jù)包給客戶端匀奏，頭部信息中包括ACK確認號鞭衩。但是此時服務(wù)器端的正常業(yè)務(wù)可能沒有完成，還要處理下數(shù)據(jù)娃善，收個尾论衍。

• 客戶端收到消息。

• 服務(wù)器繼續(xù)處理數(shù)據(jù)聚磺。

• 服務(wù)器處理數(shù)據(jù)完畢坯台，準備關(guān)閉連接，會發(fā)送一個TCP數(shù)據(jù)包給客戶端瘫寝，頭部信息中包括（FIN=1代表要斷開連接）

• 客戶端端收到消息蜒蕾，回復一個數(shù)據(jù)包給服務(wù)器端稠炬，頭部信息中包括ACK確認號。

• 服務(wù)器收到消息咪啡，到此服務(wù)器端完成連接關(guān)閉工作首启。

• 客戶端經(jīng)過一段時間（2MSL），自動進入關(guān)閉狀態(tài)撤摸，到此客戶端完成連接關(guān)閉工作毅桃。

MSL 是 Maximum Segment Lifetime，報文最大生存時間准夷，它是任何報文在網(wǎng)絡(luò)上存在的最長時間钥飞，超過這個時間報文將被丟棄。

這里有個問題是關(guān)于為什么需要四次揮手衫嵌？

A發(fā)送斷開消息給B代承，B回一條消息表示我收到了，這個過程就保證了A斷開成功渐扮。
B發(fā)送斷開消息給A论悴，A回一條消息表示我收到了，這個過程就保證了B斷開成功墓律。

其實和連接階段的區(qū)別就在于膀估，這里的B的確認消息和斷開消息不能融合。因為A要斷開的時候耻讽，B可能還有數(shù)據(jù)要處理要發(fā)送察纯，所以要等正常業(yè)務(wù)處理完，在發(fā)送斷開消息针肥。

02tcp3.png

常用的狀態(tài)碼

• 1XX - 臨時消息饼记。服務(wù)器收到請求，需要請求者繼續(xù)操作慰枕。
• 2XX - 請求成功具则。請求成功收到，理解并處理具帮。
• 3XX - 重定向博肋。需要進一步的操作以完成請求。
• 4XX - 客戶端錯誤蜂厅。請求包含語法錯誤或無法完成請求匪凡。
• 5XX - 服務(wù)器錯誤。服務(wù)器在處理請求的過程中發(fā)生了錯誤掘猿。

常見狀態(tài)碼：

200 OK - 客戶端請求成功
301 - 資源(網(wǎng)頁等)被永久轉(zhuǎn)移到其它URL
302 - 臨時跳轉(zhuǎn)
400 Bad Request - 客戶端請求有語法錯誤病游，不能被服務(wù)器所理解
404 - 請求資源不存在，錯誤的URL稠通。
500 - 服務(wù)器內(nèi)部發(fā)生了不可預期的錯誤衬衬。
503 Server Unavailable - 服務(wù)器當前不能處理客戶端的請求买猖，一段時間后可能恢復正常。

講一下TCP協(xié)議和UDP協(xié)議的區(qū)別和場景

我先說兩個場景佣耐，大家可能就比較能理解了政勃。

1） 第一個場景，瀏覽網(wǎng)頁兼砖。（TCP場景）

• 我們訪問網(wǎng)頁奸远，網(wǎng)頁肯定要把所有數(shù)據(jù)都正確的顯示出來吧，如果這個過程中丟包了讽挟，那么肯定也會重新傳包懒叛，不可能只顯示一部分網(wǎng)頁（保證數(shù)據(jù)正確性）
• 同樣，網(wǎng)頁中的內(nèi)容肯定也需要是順序的耽梅。比如我一個抽獎薛窥，不可能還沒抽就把獎給你了。（保證數(shù)據(jù)的順序）
• 再來眼姐，在這個對數(shù)據(jù)要求嚴格的過程中诅迷，我們肯定需要兩方建立起一個可靠的連接，也就是我們上述說到的要經(jīng)過三次握手才開始傳輸數(shù)據(jù)众旗，并且每次發(fā)數(shù)據(jù)包都需要回執(zhí)（面向連接的）
• 而這種連接中傳輸數(shù)據(jù)就是用的字節(jié)流罢杉，也就是有根管道，你想怎么傳數(shù)據(jù)都行贡歧，想怎么接受數(shù)據(jù)也都可以滩租，只要在這一根管道里面。

所以這種需要數(shù)據(jù)準確利朵、順序不能錯律想、要求穩(wěn)定可靠的場景就需要用到TCP。

2）第二個場景绍弟，打游戲技即。（UDP場景）

打游戲最最重要的就是即時，不然我這個技能發(fā)出去了你那邊還沒被打中晌柬，這就玩不了了姥份。

• 所以UDP是需要保證數(shù)據(jù)的即時性，而不保證每個數(shù)據(jù)包都正確接收到年碘，即使丟包了，也不會去找丟的那個是什么包展鸡，因為要顯示當前時間的當前數(shù)據(jù)包屿衅。（不保證數(shù)據(jù)正確性和數(shù)據(jù)順序，可能會丟包）
• 同樣莹弊，為了數(shù)據(jù)的即時性涤久，UDP也就不會去建立連接了涡尘，不需要什么三次握手，每次你還要確認收沒收到响迂。管你收沒收到考抄，我只要快速把每個數(shù)據(jù)包丟給你就行了。（面向無連接的）
• 因為是無連接的蔗彤，所以就不需要用到字節(jié)流川梅，直接每次丟一個數(shù)據(jù)報給你，接收方也只能接受一個數(shù)據(jù)報（不能和其他發(fā)送方的數(shù)據(jù)報混淆）然遏。（基于數(shù)據(jù)報的）

如果你還是有點暈贫途，可以看看這篇文章（亞當和夏娃），很形象的比喻：
https://www.zhihu.com/question/51388497?sort=created

socket和WebSocket

雖然這兩個貨名字類似待侵，但其實不是一個層級的概念丢早。

• socket，套接字秧倾。上文說過了怨酝，在TCP建立連接的過程中，是調(diào)用了Socket的相關(guān)API那先，建立了這個連接通道农猬。所以它只是一個接口，一個類胃榕。

• WebSocket盛险，是和HTTP同等級，屬于應(yīng)用層協(xié)議勋又。它是為了解決長時間通信的問題苦掘，由HTML5規(guī)范引出，是一種建立在TCP協(xié)議基礎(chǔ)上的全雙工通信的協(xié)議楔壤，同樣下層也需要TCP建立連接,所以也需要socket鹤啡。

科普：WebSocket在TCP連接建立后，還要通過Http進行一次握手蹲嚣，也就是通過Http發(fā)送一條GET請求消息給服務(wù)器递瑰，告訴服務(wù)器我要建立WebSocket連接了，你準備好哦隙畜，具體做法就是在頭部信息中添加相關(guān)參數(shù)抖部。然后服務(wù)器響應(yīng)我知道了，并且將連接協(xié)議改成WebSocket议惰，開始建立長連接慎颗。

如果硬要說這兩者有關(guān)系，那就是WebSocket協(xié)議也用到了TCP連接，而TCP連接用到了Socket的API俯萎。

Https的連接建立過程

說完了HTTP和TCP/IP傲宜，再說說HTTPS。

上一篇文章說了HTTPS是怎么保證數(shù)據(jù)安全傳輸,鏈接??:https://mp.weixin.qq.com/s/dbmwBVxHkvQ0fzWaSdtPYg

其中主要就是用到了數(shù)字證書夫啊。

現(xiàn)在完整看看Https連接建立（也叫TLS握手流程）：

• 1函卒、客戶端發(fā)送 Client Hello 數(shù)據(jù)包消息。

這個消息內(nèi)容包括一個隨機數(shù)（randomC）,加密族（密鑰交換算法也就是非對稱加密算法撇眯、對稱加密算法报嵌、哈希算法）,Session ID(用作恢復回話)。

客戶端要建立通信叛本，在TCP握手之后沪蓬，會發(fā)送第一個消息，也叫Client Hello消息来候。這個消息主要發(fā)了以上的一些內(nèi)容跷叉，其中密文族就是把客戶端這邊支持的一些算法發(fā)給服務(wù)器，然后服務(wù)器拿來和服務(wù)器支持的算法一比較营搅，就能得出雙方都支持的最優(yōu)算法了云挟。

• 2、服務(wù)器回復三個數(shù)據(jù)包消息： Server Hello转质，Certificate园欣，Server Hello Done。

Server Hello消息內(nèi)容包括一個隨機數(shù)（randomS）休蟹，比較后得出的加密族沸枯，Session ID(用作恢復回話)。

到現(xiàn)在赂弓，雙方已經(jīng)有兩個隨機數(shù)了绑榴，待會再看看這兩個隨機數(shù)是干嘛的。然后加密算法剛才說過了盈魁，服務(wù)器協(xié)商出了三種算法并發(fā)回給客戶端翔怎。

Certificate消息就是發(fā)送數(shù)字證書了。這里就不細說了杨耙。

Server Hello Done消息就是個結(jié)束標志赤套，表示已經(jīng)把該發(fā)的消息都發(fā)給你了。

• 3珊膜、對稱密鑰生成過程

1）首先容握，客戶端會對發(fā)來的證書進行驗證，比如數(shù)字簽名车柠、證書鏈唯沮、證書有效期脖旱、證書狀態(tài)堪遂。
2）證書校驗完畢后介蛉，然后客戶端會用證書里的服務(wù)器公鑰加密發(fā)送一個隨機數(shù) pre—master secret ，服務(wù)器收到之后用自己的私鑰解密溶褪。
3）到此币旧，客戶端和服務(wù)器就都有三個隨機數(shù)了：randomC、randomS猿妈、pre—master secret吹菱。
4）然后客戶端和服務(wù)器端分別按照固定的算法，用三個隨機數(shù)生成對稱密鑰彭则。

• 4鳍刷、生成Session ID

這一步和開始兩個hello消息中的Session ID對應(yīng)起來了。

會生成會話的id俯抖，如果后續(xù)會話斷開了输瓜，那么通過這個Session ID就可以恢復對話，不需要重新進行發(fā)送證書芬萍、生成密鑰過程了尤揣。

• 5、用對稱密鑰傳輸數(shù)據(jù)

拿到對稱密鑰后柬祠，雙方就可以使用對稱密鑰加密解密數(shù)據(jù)北戏，進行正常通信了。

02https.png

擴展：為什么要使用非對稱加密算法協(xié)商出對稱加密這種方法漫蛔？

首先嗜愈，網(wǎng)絡(luò)傳輸數(shù)據(jù)對傳輸?shù)乃俣纫蟊容^高，在保證安全的前提下莽龟，所以采用了對稱加密的方法蠕嫁，而不用耗時較多的非對稱加密算法。
其次轧房，在確定對稱加密傳輸數(shù)據(jù)的前提下拌阴，如果傳輸對稱加密的密鑰是個涉及到安全的問題，所以就采用了安全性更高的非對稱加密算法奶镶，加上證書鏈機制迟赃，保證了傳輸對稱密鑰相關(guān)數(shù)據(jù)的安全性。

請給我講解一下數(shù)字簽名厂镇，為什么真實可靠

數(shù)字簽名纤壁，也就是上文中說的電子簽名，再簡單回顧下：

數(shù)字簽名捺信，其實也是一種非對稱加密的用法酌媒。

它的使用方法是：

A使用私鑰對數(shù)據(jù)的哈希值進行加密欠痴，這個加密后的密文就叫做簽名，然后將這個密文和數(shù)據(jù)本身傳輸給B秒咨。

B拿到后喇辽，簽名用公鑰解密出來，然后和傳過來數(shù)據(jù)的哈希值做比較雨席，如果一樣菩咨，就說明這個簽名確實是A簽的，而且只有A才可以簽陡厘，因為只有A有私鑰抽米。

反應(yīng)實際情況就是：

服務(wù)器端將數(shù)據(jù)，也就是我們要傳的數(shù)據(jù)（公鑰）糙置，用另外的私鑰簽名數(shù)據(jù)的哈希值云茸，然后和數(shù)據(jù)（公鑰）一起傳過去。
然后客戶端用另外的公鑰對簽名解密谤饭，如果解密數(shù)據(jù)和數(shù)據(jù)（公鑰）的哈希值一致标捺，就能證明來源正確，不是被偽造的网持。

• 來源可靠宜岛。數(shù)字簽名只能擁有私鑰的一方才能簽名，所以它的存在就保證了這個數(shù)據(jù)的來源是正確的
• 數(shù)據(jù)可靠功舀。hash值是固定的萍倡，如果簽名解密的數(shù)據(jù)和本身的數(shù)據(jù)哈希值一致，說明數(shù)據(jù)是未被修改的辟汰。

證書鏈安全機制

證書頒發(fā)機構(gòu)（CA, Certificate Authority）即頒發(fā)數(shù)字證書的機構(gòu)列敲。是負責發(fā)放和管理數(shù)字證書的權(quán)威機構(gòu)，并作為電子商務(wù)交易中受信任的第三方帖汞，承擔公鑰體系中公鑰的合法性檢驗的責任戴而。

實際情況中，服務(wù)器會拿自己的公鑰以及服務(wù)器的一些信息傳給CA翩蘸，然后CA會返回給服務(wù)器一個數(shù)字證書所意，這個證書里面包括：

• 服務(wù)器的公鑰
• 簽名算法
• 服務(wù)器的信息，包括主機名等催首。
• CA自己的私鑰對這個證書的簽名

然后服務(wù)器將這個證書在連接階段傳給客戶端扶踊，客戶端怎么驗證呢？

細心的小伙伴肯定知道郎任，每個客戶端秧耗，不管是電腦、手機都有自帶的系統(tǒng)根證書舶治，其中就會包括服務(wù)器數(shù)字證書的簽發(fā)機構(gòu)分井。所以系統(tǒng)的根證書會用他們的公鑰幫我們對數(shù)字證書的簽名進行解密车猬，然后和證書里面的數(shù)據(jù)哈希值進行對比，如果一樣尺锚，則代表來源是正確的,數(shù)據(jù)是沒有被修改的珠闰。

當然中間人也是可以通過CA申請證書的，但是證書中會有服務(wù)器的主機名缩麸，這個主機名（域名铸磅、IP）就可以驗證你的來源是來源自哪個主機。

擴展一下：

其實在服務(wù)器證書和根證書中間還有一層結(jié)構(gòu)：叫中級證書杭朱，我們可以任意點開一個網(wǎng)頁，點擊左上角的??按鈕就可以看到證書詳情：

image

可以看到一般完整的SSL/TLS證書有三層結(jié)構(gòu)：

• 第一層：根證書吹散。也就是客戶端自帶的那些弧械，根證書都是自簽名拦耐，即用自己的公鑰和私鑰完成了簽名的制作和驗證雏吭。
• 第二層：中級證書。一般根證書是不會直接頒發(fā)服務(wù)器證書的减宣，因為這種行為比較危險界轩，如果發(fā)現(xiàn)錯誤頒發(fā)就很麻煩画饥，需要涉及到跟證書的修改。所以一般會引用中間證書浊猾，根證書對中間證書進行簽名抖甘，然后中間證書再對服務(wù)器證書進行簽名，一層套一層葫慎。
• 第三層：服務(wù)器證書衔彻。也就是跟我們服務(wù)器相關(guān)的這個證書了。

建立過程耗時偷办，那么怎么優(yōu)化呢艰额？

• 1、升級HTTP2.0

HTTP 2.0在2013年8月進行首次合作共事性測試椒涯。在開放互聯(lián)網(wǎng)上HTTP 2.0將只用于https://網(wǎng)址柄沮，而 http://網(wǎng)址將繼續(xù)使用HTTP/1，目的是在開放互聯(lián)網(wǎng)上增加使用加密技術(shù)废岂，以提供強有力的保護去遏制主動攻擊

HTTP2主要有以下特性：

• 二進制分幀祖搓。數(shù)據(jù)使用二進制傳輸，相比于文本傳輸泪喊，更利于解析和優(yōu)化棕硫。

• 多路復用。同域名下所有通信都在單個連接上完成袒啼，單個連接也可以承載任意數(shù)量的雙向數(shù)據(jù)流哈扮。

• 頭部優(yōu)化纬纪。HTTP/2對消息頭采用HPACK（專為http/2頭部設(shè)計的壓縮格式）進行壓縮傳輸，能夠節(jié)省消息頭占用的網(wǎng)絡(luò)的流量滑肉。

• 2包各、利用SessionID

這一點剛才已經(jīng)說過了，為了在斷開重連后靶庙，重復連接過程问畅，所以使用SessionID記錄會話id，然后就可以重新復用定位到哪個會話了六荒。
從而減去了重復發(fā)送證書护姆、生成密鑰過程。

• 3掏击、TLS False Start

這是Google提出來的優(yōu)化方案卵皂，具體做法是：

在TLS握手協(xié)商的第二個階段，也就是客戶端在驗證證書砚亭，發(fā)送了pre—master secret之后灯变，就直接把應(yīng)用數(shù)據(jù)帶上，比如請求網(wǎng)頁數(shù)據(jù)捅膘。

然后服務(wù)器端收到pre—master secret后添祸，生成對稱密鑰，然后直接用對稱密鑰解密這個應(yīng)用數(shù)據(jù)寻仗，并響應(yīng)消息給客戶端刃泌。

其實就是把兩個步驟混合為一個步驟了，客戶端不需要等待服務(wù)器確認愧沟，再發(fā)送應(yīng)用數(shù)據(jù)蔬咬，而是直接在第二階段就和pre—master secret一起發(fā)送給服務(wù)器端，減少了握手過程沐寺，從而減少了耗時林艘。

• 4、OCSP Stapling

OCSP是一種驗證檢查證書吊銷狀態(tài)（合法性）的在線查詢服務(wù)混坞。

驗證證書的過程中有一步是驗證證書的合法性狐援，我們可以讓服務(wù)器先通過OCSP查詢證書是否合法，然后把這個結(jié)果和證書一起發(fā)送給客戶端究孕，客戶端就不需要單獨驗證證書的合法性了啥酱，從而提高了TLS握手效率。這個功能就叫做OCSP Stapling厨诸。

擴展：

如果不考慮建立過程镶殷，從整個Https傳輸過程考慮，又有哪些優(yōu)化的點呢微酬？

可以看看這篇文章介紹：https://www.cnblogs.com/evan-blog/p/9898046.html

講一下HTTP和HTTPS的區(qū)別

經(jīng)過上面大篇幅的講解绘趋，對于兩者的區(qū)別應(yīng)該很明了了：

• HTTP是超文本傳輸協(xié)議颤陶，信息是明文傳輸，HTTPS則是在HTTP層下加了一層具有安全性的SSL/TLS加密傳輸協(xié)議陷遮，要用到CA證書滓走。
• HTTP是沒有身份認證的，客戶端無法知道對方的真實身份帽馋。HTTPS加入了CA證書搅方，可以確認對方信息。
• HTTP默認端口為80绽族，HTTPS為443姨涡。
• HTTP因為明文傳輸，容易被攻擊或者流量劫持项秉。

怎么實現(xiàn)分塊傳輸绣溜，斷點續(xù)傳？

分塊傳輸

正常情況下娄蔼，一次數(shù)據(jù)發(fā)完之后，服務(wù)器就會斷開鏈接底哗。

所以一般要在請求頭中設(shè)置Connection字段的值為：keep-alive岁诉，表示維持連接不要斷開，一直到某個數(shù)據(jù)包的Connection字段的值為close跋选。

另外還有一種辦法可以維持TCP連接涕癣，就是將請求數(shù)據(jù)進行分塊傳輸。

分塊傳輸指的是服務(wù)器發(fā)給客戶端的數(shù)據(jù)可以分成多個部分傳輸前标。

使用方法：

• 消息頭部設(shè)置Transfer-Encoding: chunked
• 每一塊會表明長度
• 由一個標明長度為0的chunk標示結(jié)束

目的：

讓客戶端快速響應(yīng)坠韩，減少等待時間。維持長連接炼列。

但是只搁、但是、這個分塊傳輸只在HTTP1.1才有俭尖。HTTP2.0支持了多路復用氢惋，單個連接可以承載任意數(shù)量的雙向數(shù)據(jù)流，也就是可以任意在一個連接在進行雙向傳輸稽犁，不需要分塊傳輸這個功能了焰望。

斷點續(xù)傳

指的是客戶端想從文件上次中斷的地方開始下載或者上傳,這樣就算遇到網(wǎng)絡(luò)問題導致下載或上傳中斷也沒事了，保證好的用戶體驗已亥。

使用方法：

• 客戶端請求報文頭部信息中加上Range字段熊赖，表示要從哪個字節(jié)開始下載，到哪個字節(jié)結(jié)束（Range: bytes=0-499）
• 服務(wù)器端響應(yīng)報文頭部信息中加上Content-Range虑椎，表示當前發(fā)送的數(shù)據(jù)的范圍震鹉，以及文件總大芯愕选（Content-Range: bytes 0-499/22400）。
• ETag字段表示文件的唯一性足陨。

實際使用流程：

• 第一次客戶端請求下載嫂粟，服務(wù)器端會返回文件內(nèi)容，和Etag標示墨缘，狀態(tài)碼為200星虹。
• 第二次客戶端請求斷點續(xù)傳，會發(fā)送兩個頭部信息（Range:bytes=200-499镊讼，If-Range：Etag）宽涌。
• 然后服務(wù)器會判斷Etag是否匹配，如果匹配則返回這一部分數(shù)據(jù)（Content-Range: bytes 200-499/22400）蝶棋，狀態(tài)碼為206卸亮，表示這是你請求的部分數(shù)據(jù)。否則會返回文件全部數(shù)據(jù)玩裙，狀態(tài)碼為200兼贸。

Http傳輸圖片有哪些方式

其實這種問題問的是對于Content-Type的認識，一共三種方法：

• multipart/form-data

表單類型傳輸文件請求吃溅。通過設(shè)置content-type為multipart/form-data溶诞，來發(fā)送二進制格式文件。
支持多個文件上傳决侈，還可以帶上文本參數(shù)螺垢。

這種是最常見的做法。

• image/png赖歌，image/jpeg

這種方法就是直接將圖片轉(zhuǎn)為二進制流傳輸枉圃，服務(wù)器端也是直接讀取流中的數(shù)據(jù)轉(zhuǎn)成圖片即可。

但是這種方法有個缺點就是一次只能傳一張圖片庐冯。

• application/x-www-form-urlencoded孽亲，text/plain

還有個辦法就是將圖片轉(zhuǎn)成Base64格式字符串，然后進行傳輸肄扎，和普通的文本參數(shù)一樣墨林，設(shè)置application/x-www-form-urlencoded或者text/plain等Content-Type即可。

參考

https://wetest.qq.com/lab/view/110.html
https://www.zhihu.com/question/271701044
https://www.cnblogs.com/wqhwe/p/5407468.html
http://www.ruanyifeng.com/blog/2017/06/tcp-protocol.html
https://network.51cto.com/art/201909/602938.htm
https://www.dazhuanlan.com/2019/11/21/5dd5aeeff1d0b/
https://zhuanlan.zhihu.com/p/26559480
《網(wǎng)絡(luò)是怎樣連接的》

拜拜

感謝大家的閱讀犯祠，有一起學習的小伙伴可以關(guān)注下我的公眾號——碼上積木????
每日一個知識點旭等，積少成多，建立知識體系架構(gòu)衡载。
這里有一群很好的Android小伙伴搔耕，歡迎大家加入～