如上这个 ip 抗投诉服务器（ 39.156.66.14 ）是百度的 ip，我在浏览器键入这个 ip 后，关闭了这个网页。

1. 为啥没有看到客户端先发 FIN 呢，反而是服务器先发[FIN,ACK]呢？
2. 之后才看到客户端连发了 6 次[FIN,ACK]？
3. 客户端从来没有发过 FIN 呢？
4. 从上示意图来看，服务器发的 FIN 和 ACK 都是分开的呀？

看完这个挥手过程完全懵了，大佬们求解答？

图看不到，但是一般来说 http 请求不会保持长连接，即 html 以及相关的 js 下载完就由服务端关闭了，不用等到关闭页面
多次 FIN 是因为不只有一个 tcp 连接，每一张图片都是单独的 http 同时请求的。


等一下哈，大佬，我发现这个图床有问题。。路过图床又不好使了。你们都用的什么图床啊~

这是抓包截图
#1

楼主这个图是 6 个 tcp 的挥手过程，只看 7719 端口的话，实际上是 3 次挥手，符合标准协议没问题。

1. 建议加个端口的过滤式，百度的 IP 对应了不止一个端口，说明不止一个连接
2. 服务端先发 FIN 也很常见，双方都可以关闭连接

有的没有四次，只有三次，二三次和在一起发。


我看是 4 次啊：
先是服务器先发 FIN，对方回复 ACK
然后客户端再发 FIN，对方回复 ACK


加个端口过滤是个好主意哈。
但是是我主动关闭了网页，才发现挥手过程的呀。这不应该客户端先发 FIN 嘛，我懵了


你的意思是，像握手过程一样，把二三次进行了合并（因为本质上来说，是四次握手，只不过进行了合并）

手动 at 大佬 @qakito


对，具体 google 上有，我之前抓的 linux nc 命令的包就这样

https://blog.csdn.net/qq_17271589/article/details/104898604 我之前写的，你可以参考一下


建议对端口做个过滤，例如看 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 次挥手，也就是楼主图片这种情况。

还有一个忘记说了，https 和 http 连接不一样，https 步数更多

我测试了下，百度的 keepalive 客户端不发送数据的话保持 90s，90s 不发送任何实际数据的话百度会自动断开连接。我在访问后的 8s 关闭了浏览器，是由客户端主动发起的 FIN

#8