关于抓包出现TCP DUP ACK问题
来源:互联网 发布:mysql alter user 编辑:程序博客网 时间:2024/06/05 00:24
对比对接其他地方的CDN的抓包,发现却是1次数据过来,回复一次ack,但是为什么对接这个CDN确实2次回复一个ACK呢?通过详细的对比报文,发现了问题所在。
TCP头部有一个标志位字段:
URG:紧急指针(urgent pointer)有效。
ACK:确认序号有效。
PSH:接收方应该尽快将这个报文段交给应用层。
RST:重建连接。
SYN:发起一个连接。
FIN:释放一个连接。
然而正常HTTP给数据的时候,这个标志位是ACK+PSH,但是这个CDN给数据的时候,却还是ACK,并没有带PSH。
TCP在处理交互数据流(即Interactive Data Flow,区别于Bulk Data Flow,即成块数据流,典型的交互数据流如telnet、rlogin等)时,采用了Delayed Ack机制以及Nagle算法来减少小分组数目。
对于非交互应用应该禁止NAGLE算法,设置 TCP_NODELAY,
const char chOpt = 1;
int nErr = setsockopt(pContext->m_Socket, IPPROTO_TCP, TCP_NODELAY, &chOpt, sizeof(char));
TCP延时确认时间通常为40毫秒(#define TCP_DELACK_MIN ((unsigned)(HZ/25)) ),如果在延迟时间内有报文段要发送的话,ack附加到数据报文段一起发送;如果没有,那么当延迟时间到时,就单独发送ACK。
所以,当对方只带ACK而不带PSH的时候,系统认为这个是交互信令,从而延时回复。在第二次数据到来的时候一次性回复了。这个时候如果对方CDN对数据传输回复要求很严格,就会存在对方及时得不到ACK回复的问题。所以就会发送TCP DUP ACK过来了。
解决办法:
通过查阅资料,可以在每次recv到数据后,调用一次setsockopt函数,设置TCP_QUICKACK
setsockopt(fd, IPPROTO_TCP, TCP_QUICKACK, (int*)(1), sizeof(int));
TCP_QUICKACK为值为12。
通过这个设置之后,每一个报文都及时回复了ACK。解决了这个TCP DUP ACK问题。
- 关于抓包出现TCP DUP ACK问题
- Wireshark抓包中的TCP DUP ACK问题
- TCP DUP ACK
- TCP报文之-tcp dup ack 、tcp Out-of-Order
- 关于Tcp包出现CheckSum incorrect的问题
- 网络基本功(二十五):Wireshark抓包实例分析TCP重复ACK与乱序
- tcpdump使用时tcp三次握手抓包,ack置1的一些说明
- Wireshark抓包实例分析TCP重复ACK与乱序
- 关于Iris网络流量分析监测工具对本地TCP无法抓包的问题
- TCP抓包经验
- TCP 抓包命令
- TCP抓包
- TCP抓包总结
- 手机抓tcp包
- tcpdump 抓 tcp 包
- 关于APP接口防止抓包问题
- 关于Charles无法抓包问题
- 关于TCP黏包问题
- linux基础入门之userdel命令
- ffmpeg_Cropping video(剪裁视频)命令行
- 前端开发,你知道cookie的弊端吗
- JavaScript格式化日期
- JS中的call()和apply()方法(项目总结)
- 关于抓包出现TCP DUP ACK问题
- testbench——文件读入输出
- final
- Linux学习第十四篇--文件系统和目录树的关系
- 浏览器的标准模式和怪异模式以及他们的区别
- Your ApplicationContext is unlikely to start due to a @ComponentScan of the default package.
- ETL总结
- unity读写XML的相关操作
- 创建表空间和创建表过程分析