这是一个创建于 1394 天前的主题，其中的信息可能已经有所发展或是发生改变。
如上这个 ip （ 39.156.66.14 ）是百度的 ip，我在浏览器键入这个 ip 后，关闭了这个网页。
- 为啥没有看到客户端先发 FIN 呢，反而是服务器先发[FIN,ACK]呢？
- 之后才看到客户端连发了 6 次[FIN,ACK]？
- 客户端从来没有发过 FIN 呢？
- 从上示意图来看，服务器发的 FIN 和 ACK 都是分开的呀？
看完这个挥手过程完全懵了，大佬们求解答？
 |
1
divilkcvf 2021-03-03 23:03:23 +08:00
图看不到，但是一般来说 http 请求不会保持长连接，即 html 以及相关的 js 下载完就由服务端关闭了，不用等到关闭页面
多次 FIN 是因为不只有一个 tcp 连接，每一张图片都是单独的 http 同时请求的。 |
 |
2
amiwrong123 OP @divilkcvf #1
等一下哈，大佬，我发现这个图床有问题。。路过图床又不好使了。你们都用的什么图床啊~ |
|
3
amiwrong123 OP |
 |
4
wakzz 2021-03-04 09:24:20 +08:00
楼主这个图是 6 个 tcp 的挥手过程，只看 7719 端口的话，实际上是 3 次挥手，符合标准协议没问题。
|
 |
5
diaryevil 2021-03-04 09:55:28 +08:00
1. 建议加个端口的过滤式，百度的 IP 对应了不止一个端口，说明不止一个连接
2. 服务端先发 FIN 也很常见，双方都可以关闭连接 |
 |
6
daimiaopeng 2021-03-04 10:10:32 +08:00
有的没有四次，只有三次，二三次和在一起发。
|
|
7
amiwrong123 OP |
|
8
amiwrong123 OP |
|
9
amiwrong123 OP @daimiaopeng #6
你的意思是，像握手过程一样，把二三次进行了合并（因为本质上来说，是四次握手，只不过进行了合并） |
|
10
amiwrong123 OP |
|
11
daimiaopeng 2021-03-05 09:05:18 +08:00
@amiwrong123 对，具体 google 上有，我之前抓的 linux nc 命令的包就这样
|
|
12
daimiaopeng 2021-03-05 09:07:05 +08:00
|
|
13
wakzz 2021-03-05 09:07:58 +08:00
@amiwrong123
建议对端口做个过滤，例如看 7719 端口，一共就三个包 443 -> 7719 [FIN, ACK] 7719 -> 443 [FIN, ACK] 443 -> 7719 [ACK] ------------------------ TCP 挥手标准情况为 4 次挥手，如下 A -> B [FIN] B-> A [ACK] B -> A [FIN] A -> B [ACK] 但是当服务端与客户端之间没有数据延迟(大多数发生在闲置 TCP 连接上)，为了更快地交互而把第二步和第三步合并，从而把 4 次挥手缩短成了 3 次挥手，也就是楼主图片这种情况。 |
|
14
daimiaopeng 2021-03-05 09:09:18 +08:00
@amiwrong123 还有一个忘记说了，https 和 http 连接不一样，https 步数更多
|
|
15
diaryevil 2021-03-05 10:17:00 +08:00
@amiwrong123 我测试了下，百度的 keepalive 客户端不发送数据的话保持 90s，90s 不发送任何实际数据的话百度会自动断开连接。我在访问后的 8s 关闭了浏览器，是由客户端主动发起的 FIN
|
Select Language