TCP抓包分析经典案例

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

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

当前提供的案例

TCP协议的三次握手和四次挥手案例，四次挥手的第二次和第三次是同一个数据包

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

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

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

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

TCP协议Keep-Alive数据包学习案例，了解Keep-Alive数据包长什么样

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

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

三次握手第三次握手服务端未接收到会怎么样？

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

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

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

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

TCP协议四次挥手四个数据包的案例

此案例包含三次握手、keep-alive和四次挥手。

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

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

http协议客户端请求传参某个请求头的值多了个'\n'导致服务端无法正常处理请求

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

通过TCP抓包分析，解决http event stream一直卡到最后一个消息才一次性返回的问题

http event stream是用于实现类似GPT的打字机效果的。

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

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

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

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

WebSocket协议学习案例(用于体验ChatTCP提供的应用层WebSocket协议解码功能)

一个下载图片文件的HTTP请求响应案例，用于体验"提取导出HTTP协议传输的文件"功能。

HTTP图片下载案例(用于体验"提取导出HTTP协议传输的文件"功能)

一个WebSocket协议案例，用于学习掌握WebSocket协议，以及体验ChatTCP提供的应用层WebSocket协议解码功能。