[[379905]]

前言

過年倒計時～

今天是網(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ù)?結(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，確認(rèn)號，是接收數(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ù)包的確認(rèn)號ACK(ACK=SEQ+1=101)，以及服務(wù)器端隨機生成的一個序號SEQ(比如SEQ=200)。
• 最后客戶端收到這個消息后，表示客戶端到服務(wù)器的連接是無誤了，然后再發(fā)送一個數(shù)據(jù)包表示也確認(rèn)收到了服務(wù)器發(fā)來的數(shù)據(jù)包，這個數(shù)據(jù)包的頭部就主要就是一個ACK值(ACK=SEQ+1=201)。
• 至此，連接成功，三次握手結(jié)束，后面數(shù)據(jù)就會正常傳輸，并且每次都要帶上TCP頭部中的SEQ和ACK值。

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

最主要的原因就是需要通信雙方都確認(rèn)自己的消息被準(zhǔn)確傳達過去了。

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

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

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

數(shù)據(jù)傳輸階段有個改變就是ACK確認(rèn)號不再是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。

當(dāng)然，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)

斷開階段(四次揮手)：

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

• 客戶端準(zhǔn)備關(guān)閉連接，會發(fā)送一個TCP數(shù)據(jù)包，頭部信息中包括(FIN=1代表要斷開連接)。
• 服務(wù)器端收到消息，回復(fù)一個數(shù)據(jù)包給客戶端，頭部信息中包括ACK確認(rèn)號。但是此時服務(wù)器端的正常業(yè)務(wù)可能沒有完成，還要處理下數(shù)據(jù)，收個尾。
• 客戶端收到消息。
• 服務(wù)器繼續(xù)處理數(shù)據(jù)。
• 服務(wù)器處理數(shù)據(jù)完畢，準(zhǔn)備關(guān)閉連接，會發(fā)送一個TCP數(shù)據(jù)包給客戶端，頭部信息中包括(FIN=1代表要斷開連接)
• 客戶端端收到消息，回復(fù)一個數(shù)據(jù)包給服務(wù)器端，頭部信息中包括ACK確認(rèn)號。
• 服務(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的確認(rèn)消息和斷開消息不能融合。因為A要斷開的時候，B可能還有數(shù)據(jù)要處理要發(fā)送，所以要等正常業(yè)務(wù)處理完，在發(fā)送斷開消息。

常用的狀態(tài)碼

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

常見狀態(tài)碼：

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

講一下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ù)要求嚴(yán)格的過程中，我們肯定需要兩方建立起一個可靠的連接，也就是我們上述說到的要經(jīng)過三次握手才開始傳輸數(shù)據(jù)，并且每次發(fā)數(shù)據(jù)包都需要回執(zhí)(面向連接的)

而這種連接中傳輸數(shù)據(jù)就是用的字節(jié)流，也就是有根管道，你想怎么傳數(shù)據(jù)都行，想怎么接受數(shù)據(jù)也都可以，只要在這一根管道里面。

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

2)第二個場景，打游戲。(UDP場景)

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

• 所以UDP是需要保證數(shù)據(jù)的即時性，而不保證每個數(shù)據(jù)包都正確接收到，即使丟包了，也不會去找丟的那個是什么包，因為要顯示當(dāng)前時間的當(dāng)前數(shù)據(jù)包。(不保證數(shù)據(jù)正確性和數(shù)據(jù)順序，可能會丟包)
• 同樣，為了數(shù)據(jù)的即時性，UDP也就不會去建立連接了，不需要什么三次握手，每次你還要確認(rèn)收沒收到。管你收沒收到，我只要快速把每個數(shù)據(jù)包丟給你就行了。(面向無連接的)
• 因為是無連接的，所以就不需要用到字節(jié)流，直接每次丟一個數(shù)據(jù)報給你，接收方也只能接受一個數(shù)據(jù)報(不能和其他發(fā)送方的數(shù)據(jù)報混淆)。(基于數(shù)據(jù)報的)

如果你還是有點暈，可以看看這篇文章(亞當(dāng)和夏娃)，很形象的比喻：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連接了，你準(zhǔn)備好哦，具體做法就是在頭部信息中添加相關(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(用作恢復(fù)回話)。

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

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

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

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

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

Server Hello Done消息就是個結(jié)束標(biāo)志，表示已經(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ù)對話，不需要重新進行發(fā)送證書、生成密鑰過程了。

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

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

擴展：為什么要使用非對稱加密算法協(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ù)責(zé)發(fā)放和管理數(shù)字證書的權(quán)威機構(gòu)，并作為電子商務(wù)交易中受信任的第三方，承擔(dān)公鑰體系中公鑰的合法性檢驗的責(zé)任。

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

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

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

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

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

擴展一下：

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

可以看到一般完整的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)化。

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

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

• 2、利用SessionID

這一點剛才已經(jīng)說過了，為了在斷開重連后，重復(fù)連接過程，所以使用SessionID記錄會話id，然后就可以重新復(fù)用定位到哪個會話了。從而減去了重復(fù)發(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ù)器確認(rèn)，再發(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是沒有身份認(rèn)證的，客戶端無法知道對方的真實身份。HTTPS加入了CA證書，可以確認(rèn)對方信息。
• HTTP默認(rèn)端口為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
• 每一塊會表明長度
• 由一個標(biāo)明長度為0的chunk標(biāo)示結(jié)束

目的：

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

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

斷點續(xù)傳

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

使用方法：

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

實際使用流程：

• 第一次客戶端請求下載，服務(wù)器端會返回文件內(nèi)容，和Etag標(biāo)示，狀態(tài)碼為200。
• 第二次客戶端請求斷點續(xù)傳，會發(fā)送兩個頭部信息(Range:bytes=200-499，If-Range：Etag)。
• 然后服務(wù)器會判斷Etag是否匹配，如果匹配則返回這一部分?jǐn)?shù)據(jù)(Content-Range: bytes 200-499/22400)，狀態(tài)碼為206，表示這是你請求的部分?jǐn)?shù)據(jù)。否則會返回文件全部數(shù)據(jù)，狀態(tài)碼為200。

Http傳輸圖片有哪些方式

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

• 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ò)是怎樣連接的》

本文轉(zhuǎn)載自微信公眾號「碼上積木」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系碼上積木公眾號。