Easy TCP Analysis
TCP协议的三次握手和四次挥手案例，四次挥手的第二次和第三次是同一个数据包
吴就业📖：119👍：2其中四次挥手的第二次挥手和第三次挥手是同一个数据包。
四次挥手不是对应四个TCP数据包吗？为什么这个案例中只有三个？
一般情况下是对应四个数据包，但也有三个数据包的情况。原因是第二次挥手是被动关闭连接的一方回复ACK，表示已收到关闭请求，而第三次挥手是被动关闭连接的一方发送FIN给主动关闭连接的一方，表示自己也准备关闭连接。所以第三次挥手FIN可以合并到第二次挥手ACK的数据包一起发送。
经典案例：三次握手第三次握手服务端未接收到会怎么样？
吴就业📖：53👍：0此案例由于服务端未能接收到客户端发送的第三次握手的数据包，所以连接实际上未建立成功。从这个案例判断，应该是服务端丢包了。
服务端不断重传第二次握手数据包，客户端接收到了服务端重传的第二次握手数据包，并重传第三次握手数据包，然而服务端还是没有收到。
最后客户端主动发送了断开连接的挥手数据包，服务端收到了挥手数据包，然后回复挥手确认，但由于服务端实际上并未建连成功，所以服务端没有发送第三次挥手，而是回复了RST报文。
http协议客户端请求传参某个请求头的值多了个'\n'导致服务端无法正常处理请求
吴就业📖：56👍：0这个事情本该到此就结束了，但是客户端一口咬定他那边代码也没问题。这个时候，我是怀疑客户端的请求有问题的，只是我没证据，只能让他帮忙复现，然后自己抓个包确认一下了。通过抓包发现，客户端传的某个请求头的值加了个'\n'，这会导致服务端框架无法正常解析请求，因为http协议解析请求时，这个'\n'之后的内容都被当成了请求body，但是Content-Length和body的长度又对不上，所以请求有问题，服务端框架就主动断开了连接。
这下有了证据，确定是哪里的问题后，也就避免了扯皮争吵。
TCP协议Keep-Alive数据包学习案例，了解Keep-Alive数据包长什么样
吴就业📖：78👍：3如果还不知道，那么这个案例可以帮助你理解Keep-Alive数据包。
如果不理解怎么判断是一个Keep-Alive数据包，可以开启解说模式，Easy TCP Analysis的解说模式会解析为什么这是一个Keep-Alive数据包。
此案例中，Keep-Alive的间隔时间是15秒，这是一个go程序的抓包，go语言底层的net.Dialer默认KeepAlive超时时间为15秒。感兴趣可以查看这个issue，说是go的默认15秒KeepAlive太频繁导致耗电。
TCP协议四次挥手四个数据包的案例
吴就业📖：50👍：0其中keep-alive由于服务端是go进程，默认超时15秒，15秒没有发送和接收到任何数据包，所以主动发起了一次keep-alive，客户端收到keep-alive后回复ACK。
四次挥手对应四个数据包，由服务端主动发起断开连接（第一次挥手）。客户端第二次挥手是回复服务端第一次挥手的ACK报文，第三次则是客户端向服务端发送FIN报文，表示自己也准备关闭连接。此案例客户端并没有将第二次和第三次合并一个数据包发。
通过TCP抓包分析，解决http event stream一直卡到最后一个消息才一次性返回的问题
吴就业📖：66👍：1此案例虽然是http协议，但如果用charles抓包的话，可能看不出来event stream确实是分多个数据包返回的，只能看到最终的完整的http响应。
通过TCP抓包分析，发现每个event单独一个TCP数据包响应了。但是从前端看，卡了好久才一次性显示，并没有达到打印机的效果。
而从TCP数据包看，发现每个event都是乱码，我们并没有加密，那就只有一种可能，就是开启了压缩。
如果开启了压缩，那么就只能等整个body响应完成才能解码，所以一直卡到最后一个数据包响应才一次性响应。
TCP协议的三次握手和四次挥手案例，四次挥手的第二次和第三次是同一个数据包
吴就业📖：119👍：2其中四次挥手的第二次挥手和第三次挥手是同一个数据包。
四次挥手不是对应四个TCP数据包吗？为什么这个案例中只有三个？
一般情况下是对应四个数据包，但也有三个数据包的情况。原因是第二次挥手是被动关闭连接的一方回复ACK，表示已收到关闭请求，而第三次挥手是被动关闭连接的一方发送FIN给主动关闭连接的一方，表示自己也准备关闭连接。所以第三次挥手FIN可以合并到第二次挥手ACK的数据包一起发送。
TCP协议Keep-Alive数据包学习案例，了解Keep-Alive数据包长什么样
吴就业📖：78👍：3如果还不知道，那么这个案例可以帮助你理解Keep-Alive数据包。
如果不理解怎么判断是一个Keep-Alive数据包，可以开启解说模式，Easy TCP Analysis的解说模式会解析为什么这是一个Keep-Alive数据包。
此案例中，Keep-Alive的间隔时间是15秒，这是一个go程序的抓包，go语言底层的net.Dialer默认KeepAlive超时时间为15秒。感兴趣可以查看这个issue，说是go的默认15秒KeepAlive太频繁导致耗电。
经典案例：三次握手第三次握手服务端未接收到会怎么样？
吴就业📖：53👍：0此案例由于服务端未能接收到客户端发送的第三次握手的数据包，所以连接实际上未建立成功。从这个案例判断，应该是服务端丢包了。
服务端不断重传第二次握手数据包，客户端接收到了服务端重传的第二次握手数据包，并重传第三次握手数据包，然而服务端还是没有收到。
最后客户端主动发送了断开连接的挥手数据包，服务端收到了挥手数据包，然后回复挥手确认，但由于服务端实际上并未建连成功，所以服务端没有发送第三次挥手，而是回复了RST报文。
TCP协议四次挥手四个数据包的案例
吴就业📖：50👍：0其中keep-alive由于服务端是go进程，默认超时15秒，15秒没有发送和接收到任何数据包，所以主动发起了一次keep-alive，客户端收到keep-alive后回复ACK。
四次挥手对应四个数据包，由服务端主动发起断开连接（第一次挥手）。客户端第二次挥手是回复服务端第一次挥手的ACK报文，第三次则是客户端向服务端发送FIN报文，表示自己也准备关闭连接。此案例客户端并没有将第二次和第三次合并一个数据包发。
http协议客户端请求传参某个请求头的值多了个'\n'导致服务端无法正常处理请求
吴就业📖：56👍：0这个事情本该到此就结束了，但是客户端一口咬定他那边代码也没问题。这个时候，我是怀疑客户端的请求有问题的，只是我没证据，只能让他帮忙复现，然后自己抓个包确认一下了。通过抓包发现，客户端传的某个请求头的值加了个'\n'，这会导致服务端框架无法正常解析请求，因为http协议解析请求时，这个'\n'之后的内容都被当成了请求body，但是Content-Length和body的长度又对不上，所以请求有问题，服务端框架就主动断开了连接。
这下有了证据，确定是哪里的问题后，也就避免了扯皮争吵。
通过TCP抓包分析，解决http event stream一直卡到最后一个消息才一次性返回的问题
吴就业📖：66👍：1此案例虽然是http协议，但如果用charles抓包的话，可能看不出来event stream确实是分多个数据包返回的，只能看到最终的完整的http响应。
通过TCP抓包分析，发现每个event单独一个TCP数据包响应了。但是从前端看，卡了好久才一次性显示，并没有达到打印机的效果。
而从TCP数据包看，发现每个event都是乱码，我们并没有加密，那就只有一种可能，就是开启了压缩。
如果开启了压缩，那么就只能等整个body响应完成才能解码，所以一直卡到最后一个数据包响应才一次性响应。