大家都知道 HTTP 的底層是 TCP，但是可能僅限于知道，并不是真正理解它們的關(guān)系。

平時(shí)我們用 chrome devtools 的 Network 工具也只是能分析 HTTP 請(qǐng)求：

TCP 層的東西看不見摸不著的，所以對(duì)它的理解也模模糊糊。

那怎么能看到 TCP 層的數(shù)據(jù)包來理清 TCP 和 HTTP 的關(guān)系呢?

這里推薦一個(gè)抓包工具 WireShark，它能抓取 TCP 層的包：

今天我們就用它來抓包分析下 TCP 和 HTTP 吧!

首先，我們準(zhǔn)備這樣一段服務(wù)端代碼：

const express = require('express')
const app = express()
app.get('/', function (req, res) {
  res.setHeader('Connection', 'close')
  res.end('hello world');
})
app.listen(4000)

用 express 起了一個(gè)服務(wù)，監(jiān)聽 4000 端口，處理路徑為 / 的 get 請(qǐng)求，返回 hello world 的響應(yīng)體，并設(shè)置 Connection: close 的 header。

瀏覽器訪問下：

header 和 body 都符合預(yù)期。

那 TCP 層都做了什么呢?

我們用 WireShark 抓包分析下：

打開 WireShark 后會(huì)看到有個(gè)設(shè)置按鈕：

因?yàn)槲覀冊(cè)L問的是 localhost: 4000，所以這里選擇本地回環(huán)地址那個(gè)虛擬網(wǎng)卡，并輸入抓包過濾條件為 port 4000：

點(diǎn)擊 start 開始錄制，然后刷新一下瀏覽器：

這樣就能看到抓到的 TCP 數(shù)據(jù)包：

我們一一分析下。

在分析之前需要了解一些 TCP 基礎(chǔ)知識(shí)：

TCP 的頭部是這樣的：

TCP 是從端口到端口的傳輸協(xié)議，所以開始是源端口和目的端口。

接下來是序列號(hào)(sequence number)，表示當(dāng)前包的序號(hào)，后面是確認(rèn)的序列號(hào)(acknowledgment number)，表示我收到了序號(hào)為 xxx 的包。

然后紅框標(biāo)出的部分是 flags 標(biāo)識(shí)位，通過 0、1 表示有沒有：

這里我們只會(huì)用到其中的 SYN、ACK、FIN：

• SYN：請(qǐng)求建立一個(gè)連接(說明這是鏈接的開始)。
• ACK：表示 ack number 是否是有效的。
• FIN：表示本端要斷開鏈接了(說明這是鏈接的結(jié)束)。

有了這些，我們就知道怎么區(qū)分 TCP 鏈接的開始和結(jié)束了。

再看一下抓到的包：

有 SYN 標(biāo)志位的是連接的開始，有 FIN 標(biāo)志位的是連接的結(jié)束，所以我們分為 3 段來看：

首先是連接開始的部分：

大家聽過 TCP 的三次握手么?說的就是這個(gè)。

其中有一個(gè)端口是 4000，這個(gè)是服務(wù)的端口，那另一個(gè)端口 57454 明顯就是瀏覽器的端口。

首先是瀏覽器向服務(wù)器發(fā)送了一個(gè) SYN 的 TCP 請(qǐng)求，表示希望建立連接，序列號(hào) Seq 是 0。

嚴(yán)格來說，序列號(hào)的相對(duì)值是 0，絕對(duì)值是 2454579144。

然后服務(wù)器向?yàn)g覽器發(fā)送了一個(gè) SYN 的 TCP 請(qǐng)求，表示希望建立連接，ACK 是 1，代表現(xiàn)在的 ack number 是有效的：

這里 ack number 的相對(duì)值是 1，絕對(duì)值是 2454579145，不就是上個(gè) TCP 數(shù)據(jù)包的 seq 加 1 么?

TCP 連接中就是通過返回 seq number + 1 作為 ack number 來確認(rèn)收到的。

然后又返回了一個(gè) seq number 給瀏覽器，相對(duì)值是 0， 絕對(duì)值是 2765691269。

瀏覽器收到后返回了一個(gè) TCP 數(shù)據(jù)包給服務(wù)器，ack number 自然是 2765691270，代表收到了連接請(qǐng)求。

這樣瀏覽器和服務(wù)器各自向?qū)Ψ桨l(fā)送了 SYN 的建立連接請(qǐng)求，并且都收到了對(duì)方的確認(rèn)，那么 TCP 連接就建立成功了。

這就是 TCP 三次握手的原理!

趁熱打鐵來看下四次揮手的部分：

瀏覽器向服務(wù)器發(fā)送了有 FIN 標(biāo)志位的數(shù)據(jù)包，表示要斷開連接，然后服務(wù)端返回了 ACK 的包表示確認(rèn)。

之后服務(wù)端發(fā)送了 FIN 標(biāo)志位的數(shù)據(jù)包給瀏覽器，表示要斷開連接，瀏覽器也返回了 ACK 的包表示確認(rèn)。

這樣就完成了四次揮手的過程。

當(dāng)然，具體確認(rèn)的還是靠 ack number = seq number + 1 來實(shí)現(xiàn)的，和上面的一樣，就不展開了：

我們通過抓包理清了 TCP 連接建立和連接的過程。

那么為什么握手是三次，揮手是四次呢?

因?yàn)閾]手是一個(gè) FIN，一個(gè) ACK，一個(gè) FIN + ACK，一個(gè) ACK：

而握手是一個(gè) SYN，一個(gè) ACK + SYN，一個(gè) ACK：

不過是因?yàn)槲帐謺r(shí)把 ACK 和 SYN 合并到一個(gè)數(shù)據(jù)包了而已。

那揮手時(shí)能合并成三次么?

不能!因?yàn)橛袃蓚€(gè) ack number，怎么合并，沖突了，而握手時(shí)只有一個(gè) ack number，自然可以合并。

接下來再來看下連接建立后的 http 請(qǐng)求和響應(yīng)吧：

其實(shí)一次 HTTP 請(qǐng)求響應(yīng)會(huì)有四個(gè) TCP 數(shù)據(jù)包，其中兩個(gè)數(shù)據(jù)包與滑動(dòng)窗口有關(guān)，這里先不展開了。

我們就看下 HTTP 的那兩個(gè)包吧：

請(qǐng)求的 seq 是這樣的：

而響應(yīng)的 ack 是這樣的：

相對(duì)值是 ack number = seq number + 1 沒錯(cuò)，但是絕對(duì)值不是：

絕對(duì)值 2454579855 = 2454579145 + 710，也就是 ack number = seq number + segment len。

這些細(xì)節(jié)暫時(shí)不用深究。

總之，我們知道了HTTP 的請(qǐng)求和響應(yīng)是通過序列號(hào)關(guān)聯(lián)在一起的。

就算同一個(gè) TCP 鏈接并行發(fā)送多個(gè) HTTP 的請(qǐng)求和響應(yīng)，它們也能找到各自對(duì)應(yīng)的那個(gè)。就是通過這個(gè) seq number 和 ack number。

這里為啥鏈接建立了發(fā)送了一個(gè)請(qǐng)求就斷掉了呢?

我刷新瀏覽器，請(qǐng)求了兩次，發(fā)現(xiàn)經(jīng)歷了兩次連接的建立、http 請(qǐng)求響應(yīng)、連接斷開：

這是因?yàn)槲以O(shè)置了 Connection:close 的 header，它的作用就是一次 http 請(qǐng)求響應(yīng)結(jié)束就斷開 TCP 鏈接。

我們改成 HTTP 1.1 支持的 keep-alive 試試：

設(shè)置 Connection 為 keep-alive，然后設(shè)置 keep-alive 的細(xì)節(jié)為 timeout 10 ，也就是 10s 后斷開。

重啟服務(wù)器，再刷新下瀏覽器試試：

可以看到在一個(gè) TCP 連接內(nèi)發(fā)送了多次 http 請(qǐng)求響應(yīng)。(通過 SYN 開始，F(xiàn)IN 結(jié)束)

這就是 keep-alive 的作用。

細(xì)心的同學(xué)會(huì)發(fā)現(xiàn)只是瀏覽器向服務(wù)器發(fā)送了 FIN 數(shù)據(jù)包，服務(wù)器沒有發(fā)給瀏覽器 FIN 數(shù)據(jù)包。

這是因?yàn)?keep-alive 的 header 只是控制的瀏覽器的斷開連接的行為，服務(wù)器的斷開連接邏輯是獨(dú)立的。

這樣，我們就理清了 HTTP 在 TCP 層面的流程，連接的建立、斷開，請(qǐng)求響應(yīng)，還有 keep-alive。

總結(jié)

我們平時(shí)都是分析 HTTP 請(qǐng)求響應(yīng)，TCP 對(duì)我們來說看不見摸不著的，理解的模模糊糊。

所以今天我們用 WireShark 抓了下 TCP 的包，來理清了 TCP 和 HTTP 的關(guān)系。

TCP 是從一個(gè)端口到另一個(gè)端口的傳輸控制協(xié)議，TCP header 中有序列號(hào) seq number、確認(rèn)序列號(hào) ack number，還有幾個(gè)標(biāo)志位：

• SYN 標(biāo)志位代表請(qǐng)求建立連接
• ACK 標(biāo)志位代表當(dāng)前確認(rèn)序列號(hào)是有效的。
• FIN 標(biāo)志位代表請(qǐng)求斷開連接

然后我們抓了 localhost:4000 的包分析了下 HTTP 請(qǐng)求的 TCP 流程，理清了三次握手(SYN、SYN + ACK、ACK)，四次揮手(FIN、ACK、FIN + ACK、ACK)的連接建立、斷開的流程。知道了為什么不能三次揮手(因?yàn)閮蓚€(gè) ACK 沖突了)

然后還理清了同一個(gè) TCP 連接傳輸?shù)亩鄠€(gè) HTTP 請(qǐng)求響應(yīng)式通過 seq number 和 ack number 來關(guān)聯(lián)的。

之后我們分別測試了 Connection：close 和 Connection：keep-alive 的情況，發(fā)現(xiàn)確實(shí) keep-alive 能減少頻繁的連接建立和斷開，能復(fù)用同一個(gè) TCP 鏈接。

HTTP 是通過 TCP 完成端口到端口的數(shù)據(jù)傳輸?shù)?。一個(gè) TCP 連接可以傳輸多個(gè) HTTP 請(qǐng)求、響應(yīng)。請(qǐng)求和響應(yīng)的關(guān)聯(lián)是通過 TCP 包的序列號(hào) seq。

理清了 TCP 和 HTTP 的關(guān)系，你是否對(duì) HTTP 的理解更深了呢?