作者 | 神说要有光
来源 | 神光的编程秘籍
大家都知道 HTTP 的底层是 TCP,但是可能仅限于知道,并不是真正理解它们的关系。
平时我们用 chrome devtools 的 Network 工具也只是能分析 HTTP 请求:
![1acad8da2abb467e4869ca4165a13a00.jpeg](https://i-blog.csdnimg.cn/blog_migrate/a141d2f09bc3be07e18f369d4d076eb9.jpeg)
TCP 层的东西看不见摸不着的,所以对它的理解也模模糊糊。
那怎么能看到 TCP 层的数据包来理清 TCP 和 HTTP 的关系呢?
这里推荐一个抓包工具 WireShark,它能抓取 TCP 层的包。
今天我们就用它来抓包分析下 TCP 和 HTTP 吧!
首先,我们准备这样一段服务端代码:
const express = require('express')
const app = express()
app.get('/', function (req, res) {
res.setHeader('Connection', 'close')
res.end('hello world');
})
app.listen(4000)
用 express 起了一个服务,监听 4000 端口,处理路径为 / 的 get 请求,返回 hello world 的响应体,并设置 Connection: close 的 header。
浏览器访问下:
![87ffc47ce0fa47e9451a473e0f42b797.png](https://i-blog.csdnimg.cn/blog_migrate/e6bcc1d95e69df1f5b8661bc4f405cda.png)
header 和 body 都符合预期。
那 TCP 层都做了什么呢?
我们用 WireShark 抓包分析下:
打开 WireShark 后会看到有个设置按钮。
因为我们访问的是 localhost: 4000,所以这里选择本地回环地址那个虚拟网卡,并输入抓包过滤条件为 port 4000:
![4617f183206f20d6f98a31a568d2cf17.png](https://i-blog.csdnimg.cn/blog_migrate/bfcb62dbea45f63900ffc20a904d3abd.png)
点击 start 开始录制,然后刷新一下浏览器:
这样就能看到抓到的 TCP 数据包:
![c9f9f0c6c0b13685c1630ec636b2b9de.jpeg](https://i-blog.csdnimg.cn/blog_migrate/ae459a18ac37b8b9c1e23cbdd5d17388.jpeg)
我们一一分析下。
在分析之前需要了解一些 TCP 基础知识:
TCP 的头部是这样的:
![632db5e20a1cf460bcce8b3e9651e5ae.jpeg](https://i-blog.csdnimg.cn/blog_migrate/25ed2dce04e6cc77a1de0f535b13fd00.jpeg)
TCP 是从端口到端口的传输协议,所以开始是源端口和目的端口。
接下来是序列号(sequence number),表示当前包的序号,后面是确认的序列号(acknowledgment number),表示我收到了序号为 xxx 的包。
然后红框标出的部分是 flags 标识位,通过 0、1 表示有没有:
这里我们只会用到其中的 SYN、ACK、FIN:
SYN:请求建立一个连接(说明这是链接的开始)
ACK:表示 ack number 是否是有效的
FIN:表示本端要断开链接了(说明这是链接的结束)
有了这些,我们就知道怎么区分 TCP 链接的开始和结束了。
再看一下抓到的包:
![53324b1396bf78cafc494aed54408d29.jpeg](https://i-blog.csdnimg.cn/blog_migrate/88967e75ea88b3c499662585ba90c2fd.jpeg)
有 SYN 标志位的是连接的开始,有 FIN 标志位的是连接的结束,所以我们分为 3 段来看:
首先是连接开始的部分:
![2cf93fd9c7f1b6d3660b8c58d83b9b94.png](https://i-blog.csdnimg.cn/blog_migrate/7428c8d68c8daa54b2ed167428322753.png)
大家听过 TCP 的三次握手么?说的就是这个。
其中有一个端口是 4000,这个是服务的端口,那另一个端口 57454 明显就是浏览器的端口。
首先是浏览器向服务器发送了一个 SYN 的 TCP 请求,表示希望建立连接,序列号 Seq 是 0。
严格来说,序列号的相对值是 0,绝对值是 2454579144。
![16906c867bb1e6dc8040adf676a15c89.png](https://i-blog.csdnimg.cn/blog_migrate/afe37f1eac72f1cc0abfbd8111b2c313.png)
然后服务器向浏览器发送了一个 SYN 的 TCP 请求,表示希望建立连接,ACK 是 1,代表现在的 ack number 是有效的:
![ca786e34f468d11ff678a738570c73cf.png](https://i-blog.csdnimg.cn/blog_migrate/9953684831dd2ebc2388765c0078ef3b.png)
这里 ack number 的相对值是 1,绝对值是 2454579145,不就是上个 TCP 数据包的 seq 加 1 么?
TCP 连接中就是通过返回 seq number + 1 作为 ack number 来确认收到的。
然后又返回了一个 seq number 给浏览器,相对值是 0, 绝对值是 2765691269。
浏览器收到后返回了一个 TCP 数据包给服务器,ack number 自然是 2765691270,代表收到了连接请求。
这样浏览器和服务器各自向对方发送了 SYN 的建立连接请求,并且都收到了对方的确认,那么 TCP 连接就建立成功了。
这就是 TCP 三次握手的原理!
![eb6957c645cb029709598c326ebf4dce.png](https://i-blog.csdnimg.cn/blog_migrate/d4fae4e110edf36d081e62a2af215577.png)
趁热打铁来看下四次挥手的部分:
![e7dfbe91b29bd908291a0f6e8857dc23.png](https://i-blog.csdnimg.cn/blog_migrate/cfa1b2a3594167d742a900f05d24a0bb.png)
浏览器向服务器发送了有 FIN 标志位的数据包,表示要断开连接,然后服务端返回了 ACK 的包表示确认。
之后服务端发送了 FIN 标志位的数据包给浏览器,表示要断开连接,浏览器也返回了 ACK 的包表示确认。
这样就完成了四次挥手的过程。
当然,具体确认的还是靠 ack number = seq number + 1 来实现的,和上面的一样,就不展开了:
![53679f101b97aca5079addfe6d348a1f.png](https://i-blog.csdnimg.cn/blog_migrate/71260b7dbfedabcb7d452d0d8d89074e.png)
![60cb315e4530e7112a2c167064596f12.png](https://i-blog.csdnimg.cn/blog_migrate/09d54e830314703be8b039b114ffbe47.png)
我们通过抓包理清了 TCP 连接建立和连接的过程。
![4daf7ac4176f1b7375e1cbdc1b0c98fb.png](https://i-blog.csdnimg.cn/blog_migrate/8bd49844b64da4e3c14e93324603bc8a.png)
那么为什么握手是三次,挥手是四次呢?
因为挥手是一个 FIN,一个 ACK,一个 FIN + ACK,一个 ACK:
![3e2f7eed696bdffae638f44139d29c66.png](https://i-blog.csdnimg.cn/blog_migrate/a06210ec5945a5a9e8a5c2d7132d335a.png)
而握手是一个 SYN,一个 ACK + SYN,一个 ACK:
![9f6b8ecc83a81ab8a99503e1070ed2f6.png](https://i-blog.csdnimg.cn/blog_migrate/04b86f5851900173968341b12e9d6402.png)
不过是因为握手时把 ACK 和 SYN 合并到一个数据包了而已。
那挥手时能合并成三次么?
不能!因为有两个 ack number,怎么合并,冲突了,而握手时只有一个 ack number,自然可以合并。
![bdee5f4f8899f881a4041cbfcc03accd.png](https://i-blog.csdnimg.cn/blog_migrate/644dcdd416ba36092fc579e069bc716d.png)
接下来再来看下连接建立后的 http 请求和响应吧:
![3e92f034c981b89f4bcadd8a47432e81.png](https://i-blog.csdnimg.cn/blog_migrate/b1e1d3ee0ac663cf85bdcf1193b980dc.png)
其实一次 HTTP 请求响应会有四个 TCP 数据包,其中两个数据包与滑动窗口有关,这里先不展开了。
相对值是 ack number = seq number + 1 没错,但是绝对值不是:
绝对值 2454579855 = 2454579145 + 710,也就是 ack number = seq number + segment len。
这些细节暂时不用深究。
总之,我们知道了HTTP 的请求和响应是通过序列号关联在一起的。
就算同一个 TCP 链接并行发送多个 HTTP 的请求和响应,它们也能找到各自对应的那个。就是通过这个 seq number 和 ack number。
这里为啥链接建立了发送了一个请求就断掉了呢?
我刷新浏览器,请求了两次,发现经历了两次连接的建立、http 请求响应、连接断开:
![3788ebfbf816f08158de3a85b0b8be13.png](https://i-blog.csdnimg.cn/blog_migrate/2b51d6e4495a970bac37bea5afcf1a35.png)
这是因为我设置了 Connection:close 的 header,它的作用就是一次 http 请求响应结束就断开 TCP 链接。
![48b55447a4770e839e01eb61eb49c69f.png](https://i-blog.csdnimg.cn/blog_migrate/3fd34d712671574ba2e174010f37fc5e.png)
我们改成 HTTP 1.1 支持的 keep-alive 试试:
![f40e2306d518af6abf2f19bbe6e1ee64.png](https://i-blog.csdnimg.cn/blog_migrate/5157501ef68f443f9c1400f53c3084ec.png)
设置 Connection 为 keep-alive,然后设置 keep-alive 的细节为 timeout 10 ,也就是 10s 后断开。
重启服务器,再刷新下浏览器试试:
![0a27c4e7ff170a6d6871af79fc9a4951.png](https://i-blog.csdnimg.cn/blog_migrate/0d7462d08c9ee8a30fb78c2f524e96af.png)
可以看到在一个 TCP 连接内发送了多次 http 请求响应。(通过 SYN 开始,FIN 结束)
这就是 keep-alive 的作用。
细心的同学会发现只是浏览器向服务器发送了 FIN 数据包,服务器没有发给浏览器 FIN 数据包。
这是因为 keep-alive 的 header 只是控制的浏览器的断开连接的行为,服务器的断开连接逻辑是独立的。
这样,我们就理清了 HTTP 在 TCP 层面的流程,连接的建立、断开,请求响应,还有 keep-alive。
总结
我们平时都是分析 HTTP 请求响应,TCP 对我们来说看不见摸不着的,理解的模模糊糊。
所以今天我们用 WireShark 抓了下 TCP 的包,来理清了 TCP 和 HTTP 的关系。
TCP 是从一个端口到另一个端口的传输控制协议,TCP header 中有序列号 seq number、确认序列号 ack number,还有几个标志位:
SYN 标志位代表请求建立连接
ACK 标志位代表当前确认序列号是有效的。
FIN 标志位代表请求断开连接
然后我们抓了 localhost:4000 的包分析了下 HTTP 请求的 TCP 流程,理清了三次握手(SYN、SYN + ACK、ACK),四次挥手(FIN、ACK、FIN + ACK、ACK)的连接建立、断开的流程。知道了为什么不能三次挥手(因为两个 ACK 冲突了)
然后还理清了同一个 TCP 连接传输的多个 HTTP 请求响应是通过 seq number 和 ack number 来关联的。
之后我们分别测试了 Connection:close 和 Connection:keep-alive 的情况,发现确实 keep-alive 能减少频繁的连接建立和断开,能复用同一个 TCP 链接。
HTTP 是通过 TCP 完成端口到端口的数据传输的。一个 TCP 连接可以传输多个 HTTP 请求、响应。请求和响应的关联是通过 TCP 包的序列号 seq。
理清了 TCP 和 HTTP 的关系,你是否对 HTTP 的理解更深了呢?
往期推荐
点分享
点收藏
点点赞
点在看