?哈嘍，大家好，我是指北君。話不多說，先來個小能量。

有些路看起來很近走去卻很遠，缺少耐心永遠走不到頭。——沈從文

接下來就開始指北君的分享~

前言

對于從事互聯(lián)網(wǎng)開發(fā)的同學(xué)來說，永遠都無法繞過網(wǎng)絡(luò)連接，各種原理、各種協(xié)議...輕輕松松就被搞得暈頭轉(zhuǎn)向，不知所措，從而影響解決問題的效率，同時需要投入大量時間去查閱資料，搞不好還會搞丟自己的績效...想想后果就不禁一顫，那不如提前儲備，以備不時之需。

本篇內(nèi)容主要圍繞常見的HTTP內(nèi)容，同時對比TCP進行梳理，接下來就和小編一起去探索網(wǎng)絡(luò)連接那些事！

網(wǎng)絡(luò)小知識?

分析網(wǎng)絡(luò)連接前，需要給大家簡介下網(wǎng)絡(luò)知識，了解的同學(xué)可以直接跳過

• 網(wǎng)絡(luò)模型通常分為四層或七層，小編以七層為例，網(wǎng)絡(luò)自下而上分層為：物理層、數(shù)據(jù)鏈路層、網(wǎng)絡(luò)層、傳輸層、會話層、表示層、應(yīng)用層。每一層都依賴于其底層的協(xié)議，比如沒有網(wǎng)絡(luò)層，就不會有傳輸層。
• HTTP協(xié)議對應(yīng)網(wǎng)絡(luò)的應(yīng)用層，TCP協(xié)議對應(yīng)網(wǎng)絡(luò)的傳輸層。（多提一句，IP協(xié)議對應(yīng)網(wǎng)絡(luò)層，socket是基于TCP/IP協(xié)議封裝的應(yīng)用接口，便于開發(fā)人員使用）
• TCP協(xié)議主要作用是如何穩(wěn)定快速的傳輸數(shù)據(jù)，而HTTP協(xié)議負責(zé)定義數(shù)據(jù)，以便網(wǎng)絡(luò)兩端的計算機理解數(shù)據(jù)。

HTTP協(xié)議

• HTTP協(xié)議全名超文本傳送協(xié)議（Hypertext Transfer Protocol），是web聯(lián)網(wǎng)的基礎(chǔ)，也是移動端常用協(xié)議之一。
• HTTP協(xié)議屬于應(yīng)用層，主要作用于兩臺連接的計算機，并且在不同計算機中充當(dāng)著客戶端和服務(wù)器的角色。客戶端發(fā)起請求，服務(wù)器負責(zé)給予請求對應(yīng)的響應(yīng)，完成數(shù)據(jù)交互。
• HTTP屬于無狀態(tài)協(xié)議，每一次請求都是互相獨立的、沒有任何關(guān)聯(lián)的。在1.0版本中，客戶端每次請求都是建立一次單獨的連接，請求完成后自動釋放，1.1版本中單連接允許處理多個請求，并且多個請求可以并發(fā)執(zhí)行。（后續(xù)會單獨詳細介紹HTTP，敬請期待）
• 由于HTTP每次請求結(jié)束后會釋放連接，所以被稱為‘短鏈接’。為了保持客戶端的在線狀態(tài)，需要不斷向服務(wù)器發(fā)起連接請求，根據(jù)服務(wù)器的響應(yīng)結(jié)果判斷連接是否斷開。

TCP協(xié)議?

• TCP全名傳輸控制協(xié)議（Transmission Control Protocol），是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議，是移動端建立無線網(wǎng)絡(luò)連接的基礎(chǔ)，實現(xiàn)移動聯(lián)網(wǎng)
• TCP相對于HTTP發(fā)起請求、接收響應(yīng)、釋放連接來說，是更加復(fù)雜的。最常見且最重要的就是‘三次握手’：
• 第一次握手：client發(fā)送SYN包（syn=j）到server，并進入SYN_SEND狀態(tài)開始等待；
• 第二次握手：server接收并確認client的SYN包（ack=j+1），同時也額外發(fā)送SYN包（syn=k），即SYN包+ACK包，此時server進入SYN_RECV狀態(tài)；
• 第三次握手：client收到server的SYN+ACK包后，向server發(fā)送ACK包（ack=k+1），成功后client和server分別進入ESTABLISHED狀態(tài)，完成三次握手。
• TCP還有另外一層容易被忽略的就是斷開連接（四次揮手）
• 第一次揮手：client端接收完數(shù)據(jù)，會向server端發(fā)起釋放請求（fin=m）;
• 第二次揮手：server端接收并確認client的釋放請求（ack=m+1）,通知應(yīng)用層要釋放TCP連接，并進入CLOSE_WAIT狀態(tài)；
• 第三次揮手：server端如果還有沒有發(fā)送完的數(shù)據(jù)，會繼續(xù)發(fā)送，直到發(fā)送完畢后會向client端發(fā)送連接釋放請求（fin=n），然后進入到LAST_ACK狀態(tài)；（此處可以將第二次和第三次合并，延遲ACK包的發(fā)送，用來解決傳輸時間限制等問題）
• 第四次揮手：client端接受并確認server的釋放請求（ack=n+1）后，進入TIME_WAIT狀態(tài)，并持續(xù)2MSL時間，若該時間內(nèi)未收到server端的重發(fā)請求，就會進入CLOSE狀態(tài)，并向server發(fā)送fin+ack包，server端確認接收后，也進入CLOSE狀態(tài)。

實際應(yīng)用

小編最近遇到的一個十分緊急的問題，就是外網(wǎng)的頁面資源加載延遲高，特別是圖片、js等靜態(tài)資源。由此為出發(fā)點，優(yōu)先解決靜態(tài)資源加載，想到了HTTP緩存這一特性。

• HTTP緩存：當(dāng)瀏覽器訪問服務(wù)端時，會將請求資源緩存到本地，當(dāng)下次再發(fā)起相同請求，則直接加載本地緩存資源，不再請求服務(wù)端，節(jié)省網(wǎng)絡(luò)資源。
• HTTP緩存是由請求頭字段（Cache-Control）控制。具體根據(jù)資源更新頻率設(shè)置緩存時長。
• 參考微信使用HTTP緩存（僅供參考）：

html：public, max-age=500 （public為公共緩存，max-age為緩存時間500秒）

JS文件：max-age=31536000(1年)，文件命名帶版本號或指紋信息，方便及時更新。

CSS文件：max-age=31536000，文件命名帶版本號或指紋信息，方便及時更新。

圖片：max-age=31536000，文件命名帶版本號或指紋信息，方便及時更新。

XHR請求：no-cache,must-revalidate

最終小編利用HTTP緩存解決了頁面加載問題，主要是參考微信的請求參數(shù)設(shè)置，后續(xù)涉及其它web資源優(yōu)化本文不再作詳細介紹，如果有其它問題可以私信一起探討。

總結(jié)

TCP協(xié)議對應(yīng)傳輸層，HTTP協(xié)議對應(yīng)應(yīng)用層，二者在本質(zhì)上其實沒有可比性，但實際應(yīng)用中出現(xiàn)問題很容易混淆，并且不容易定位問題，在此按自身理解分享給大家。

HTTP協(xié)議是基于TCP協(xié)議的，HTTP在發(fā)起請求時通過TCP建立起連接服務(wù)器的通道，當(dāng)請求結(jié)束后，會立即斷開TCP連接。

最后借用比較形象的比喻：HTTP是轎車，是封裝或顯示數(shù)據(jù)的具體形式；將TCP封裝的API（即Socket編程接口），是發(fā)動機，提供了網(wǎng)絡(luò)通信能力。