记一次请求无响应的抓包分析过程

最新推荐文章于 2023-12-01 10:37:19 发布

JB324

最新推荐文章于 2023-12-01 10:37:19 发布

阅读量1.7k

点赞数 1

分类专栏： TCP/IP 文章标签： tcpip

本文链接：https://blog.csdn.net/JB324/article/details/112754696

版权

TCP/IP 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

本文分析了一次网络请求中出现的invalidchunkedresponse错误。通过对两次请求的对比，发现首次请求因未遵循Transfer-Encoding:chunked规定的格式而失败。文章详细解释了分块传输编码的工作原理及常见问题。

摘要由CSDN通过智能技术生成

请求链路

在这里插入图片描述

问题现象

相同的请求参数，第一次请求没有返回，第二次请求可以正常返回，查看SLB日志有报错invalid chunked response，接着抓包开始分析

对比分析

一、先做一个两次请求的对比，第一次请求一共传输了10个包，第二次请求传输了13个包
第一次请求的包
在这里插入图片描述

二、对比两次请求的TCP流，总共有三个不同点
1.第一次请求有set-cookie，第二次请求没有，最初怀疑是cookie格式的问题，百度之后排除，cookie的value里边除了|也没有其他特殊的字符。
2.第一次请求是SLB先关闭的连接，第二次是ECSB先关闭的连接，第一次应该是由于ECSB发回的数据包有问题，SLB校验失败，就主动关闭连接了，同时写了个日志invalid chunked response，这里边有一个知识点，TCP通信是双通道的，client和server都可以先发起关闭连接，发起关闭连接的一方就不能再发送数据包了，但是可以继续接收数据包，直到另外一方也发送FIN包
3.第二次请求的response body前边有一个4b，最后边有个0，根据SLB的错误日志和response header里的Transfer-Encoding: chunked，查阅自恋后发现当Transfer-Encoding为chunked的时候，表示数据包要分组发送，每组数据包最开始都要表明本次数据包的长度，4b是十六进制，转换成10进制对应的是75字节，与数据包的大小是可以对应上的，最后一个0代表数据包传输完成了

通过上边三个不同点的对比分析可以得出结论，第一次请求失败是由于，ECS返回的响应体没有按照Transfer-Encoding: chunked要求的格式
第一次请求的TCP流
第二次请求的TCP流