TCP抓包分析PCAP示例

ChatTCP为用户提供了一些非常实用的PCAP示例，例如TCP协议的三次握手和四次挥手等，用户无需自己抓包，非常适合新手用于学习掌握TCP协议。除了TCP协议，ChatTCP后续也会逐渐提供一些应用层协议的示例，例如WebSocket协议，方便用户用于学习或复习，无需自己模拟场景和抓包。

PS：您看到的所有图片都是英文版的截图，ChatTCP支持中文，当您的系统使用中文时，ChatTCP就会使用中文。

PCAP示例

当前提供的示例

此示例只包含TCP协议的三次握手和四次挥手数据包，非常适合新手学习理解TCP协议。

其中四次挥手的第二次挥手和第三次挥手是同一个数据包。

四次挥手不是对应四个TCP数据包吗？为什么这个示例中只有三个？

一般情况下是对应四个数据包，但也有三个数据包的情况。原因是第二次挥手是被动关闭连接的一方回复ACK，表示已收到关闭请求，而第三次挥手是被动关闭连接的一方发送FIN给主动关闭连接的一方，表示自己也准备关闭连接。所以第三次挥手FIN可以合并到第二次挥手ACK的数据包一起发送。

你知道Keep-Alive数据包长什么样吗？如果还不知道，那么这个示例可以帮助你理解Keep-Alive数据包。

此示例中，Keep-Alive的间隔时间是15秒，这是一个Go程序的抓包，Go语言底层的net.Dialer默认Keep-Alive超时时间为15秒。感兴趣可以查看这个issue，说是Go的默认15秒Keep-Alive太频繁导致耗电。

此示例即适合理解为什么TCP协议需要三次握手，也是个非常典型的故障排查示例。

此示例由于服务端未能接收到客户端发送的第三次握手的数据包，所以连接实际上未建立成功。从这个示例判断，应该是服务端丢包了。

服务端不断重传第二次握手数据包，客户端接收到了服务端重传的第二次握手数据包，并重传第三次握手数据包，然而服务端还是没有收到。

最后客户端主动发送了断开连接的挥手数据包，服务端收到了挥手数据包，然后回复挥手确认，但由于服务端实际上并未建连成功，所以服务端没有发送第三次挥手，而是回复了RST报文。

此示例包含三次握手、Keep-Alive和四次挥手。

其中Keep-Alive由于服务端是Go进程，默认超时15秒，15秒没有发送和接收到任何数据包，所以主动发起了一次Keep-Alive，客户端收到Keep-Alive后回复ACK。

四次挥手对应四个数据包，由服务端主动发起断开连接（第一次挥手）。客户端第二次挥手是回复服务端第一次挥手的ACK报文，第三次则是客户端向服务端发送FIN报文，表示自己也准备关闭连接。此示例客户端并没有将第二次和第三次合并一个数据包发。

客户端传的某个请求头的值加了个'\n'，导致服务端框架无法正常解析请求，因为HTTP协议解析请求时，这个'\n'之后的内容都被当成了请求Body，但是Content-Length和Body的长度又对不上，所以请求有问题，服务端框架就主动断开了连接。

HTTP Event Stream是用于实现类似GPT的打字机效果的。

此示例虽然是HTTP协议，但如果用Charles抓包的话，可能看不出来Event Stream确实是分多个数据包返回的，只能看到最终的完整的HTTP响应。

通过TCP抓包分析，发现每个Event单独一个TCP数据包响应了。但是从前端看，卡了好久才一次性显示，并没有达到打字的效果。

而从TCP数据包看，发现每个Event都是乱码，我们并没有加密，那就只有一种可能，就是开启了压缩。

如果开启了压缩，那么就只能等整个Body响应完成才能解码，所以一直卡到最后一个数据包响应才一次性响应。