被搞得暈頭轉(zhuǎn)向的HTTP和TCP

作者：指北君 2022-11-02 08:16:41

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

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

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

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

前言

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

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

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

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

網(wǎng)絡(luò)模型通常分為四層或七層，小編以七層為例，網(wǎng)絡(luò)自下而上分層為：物理層、數(shù)據(jù)鏈路層、網(wǎng)絡(luò)層、傳輸層、會(huì)話層、表示層、應(yīng)用層。每一層都依賴于其底層的協(xié)議，比如沒有網(wǎng)絡(luò)層，就不會(huì)有傳輸層。
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é)議負(fù)責(zé)定義數(shù)據(jù)，以便網(wǎng)絡(luò)兩端的計(jì)算機(jī)理解數(shù)據(jù)。

HTTP協(xié)議

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

TCP協(xié)議?

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

實(shí)際應(yīng)用

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

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

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

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

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

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

XHR請求：no-cache,must-revalidate

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