一次对接的timeout事故,元凶居然是tcp_tw_recycle和tcp_timestamps

Fri Jul 31 15:45:01 CST 2015 HTTP OK: HTTP/1.1 200 OK - 240 bytes in 0.087 second response time |time=0.087261s;;;0.000000 size=240B;;;0
Fri Jul 31 15:48:01 CST 2015 HTTP OK: HTTP/1.1 200 OK - 240 bytes in 0.078 second response time |time=0.077894s;;;0.000000 size=240B;;;0
Fri Jul 31 15:51:01 CST 2015 HTTP OK: HTTP/1.1 200 OK - 240 bytes in 0.084 second response time |time=0.084313s;;;0.000000 size=240B;;;0
Fri Jul 31 15:54:22 CST 2015 HTTP OK: HTTP/1.1 200 OK - 240 bytes in 21.086 second response time |time=21.085550s;;;0.000000 size=240B;;;0
Fri Jul 31 15:57:31 CST 2015 CRITICAL - Socket timeout after 30 seconds
Fri Jul 31 16:00:01 CST 2015 HTTP OK: HTTP/1.1 200 OK - 240 bytes in 0.080 second response time |time=0.080339s;;;0.000000 size=240B;;;0
Fri Jul 31 16:03:02 CST 2015 HTTP OK: HTTP/1.1 200 OK - 240 bytes in 0.080 second response time |time=0.079804s;;;0.000000 size=240B;;;0
Fri Jul 31 16:06:01 CST 2015 HTTP OK: HTTP/1.1 200 OK - 240 bytes in 0.087 second response time |time=0.086504s;;;0.000000 size=240B;;;0
Fri Jul 31 16:09:01 CST 2015 HTTP OK: HTTP/1.1 200 OK - 240 bytes in 0.084 second response time |time=0.083803s;;;0.000000 size=240B;;;0
Fri Jul 31 16:12:01 CST 2015 HTTP OK: HTTP/1.1 200 OK - 240 bytes in 0.079 second response time |time=0.079404s;;;0.000000 size=240B;;;0
Fri Jul 31 16:15:01 CST 2015 HTTP OK: HTTP/1.1 200 OK - 240 bytes in 0.086 second response time |time=0.086371s;;;0.000000 size=240B;;;0
Fri Jul 31 16:18:01 CST 2015 HTTP OK: HTTP/1.1 200 OK - 240 bytes in 0.080 second response time |time=0.079938s;;;0.000000 size=240B;;;0
Fri Jul 31 16:21:31 CST 2015 CRITICAL - Socket timeout after 30 seconds
Fri Jul 31 16:24:31 CST 2015 CRITICAL - Socket timeout after 30 seconds
Fri Jul 31 16:27:02 CST 2015 HTTP OK: HTTP/1.1 200 OK - 240 bytes in 0.080 second response time |time=0.079929s;;;0.000000 size=240B;;;0
Fri Jul 31 16:30:01 CST 2015 HTTP OK: HTTP/1.1 200 OK - 240 bytes in 0.083 second response time |time=0.082782s;;;0.000000 size=240B;;;0
Fri Jul 31 16:33:22 CST 2015 HTTP OK: HTTP/1.1 200 OK - 240 bytes in 21.081 second response time |time=21.080820s;;;0.000000 size=240B;;;0
Fri Jul 31 16:36:01 CST 2015 HTTP OK: HTTP/1.1 200 OK - 240 bytes in 0.085 second response time |time=0.084818s;;;0.000000 size=240B;;;0
Fri Jul 31 16:39:02 CST 2015 HTTP OK: HTTP/1.1 200 OK - 240 bytes in 0.079 second response time |time=0.078770s;;;0.000000 size=240B;;;0
Fri Jul 31 16:42:01 CST 2015 HTTP OK: HTTP/1.1 200 OK - 240 bytes in 0.084 second response time |time=0.083813s;;;0.000000 size=240B;;;0
Fri Jul 31 16:45:31 CST 2015 CRITICAL - Socket timeout after 30 seconds
Fri Jul 31 16:48:01 CST 2015 HTTP OK: HTTP/1.1 200 OK - 240 bytes in 0.084 second response time |time=0.083595s;;;0.000000 size=240B;;;0
Fri Jul 31 16:51:31 CST 2015 CRITICAL - Socket timeout after 30 seconds
Fri Jul 31 16:54:31 CST 2015 CRITICAL - Socket timeout after 30 seconds
Fri Jul 31 16:57:31 CST 2015 CRITICAL - Socket timeout after 30 seconds
Fri Jul 31 17:00:01 CST 2015 HTTP OK: HTTP/1.1 200 OK - 240 bytes in 0.082 second response time |time=0.082200s;;;0.000000 size=240B;;;0
Fri Jul 31 17:03:01 CST 2015 HTTP OK: HTTP/1.1 200 OK - 240 bytes in 0.082 second response time |time=0.081671s;;;0.000000 size=240B;;;0
Fri Jul 31 17:06:01 CST 2015 HTTP OK: HTTP/1.1 200 OK - 240 bytes in 0.079 second response time |time=0.079241s;;;0.000000 size=240B;;;0
Fri Jul 31 17:09:01 CST 2015 HTTP OK: HTTP/1.1 200 OK - 240 bytes in 0.081 second response time |time=0.081428s;;;0.000000 size=240B;;;0
Fri Jul 31 17:12:31 CST 2015 CRITICAL - Socket timeout after 30 seconds

这次事故主要是和对方做对接,然后我们模拟HTTP的请求的连接对方,发现日志居然是这样

询问对方是不是接口不稳定,对面回答一直都OK,然后左查右查

发现是

tcp_timestamps   的问题,

我们使用tcpdump来捉包,发现带有时间戳的包全部没有完成3此握手,

echo 1  > /proc/sys/net/ipv4/tcp_timestamps;

sysctl -p

然后再检查日志 一切正常了

有更详细的资料请参考

http://dngood.blog.51cto.com/446195/988968/

时间: 2024-09-30 10:21:10

一次对接的timeout事故,元凶居然是tcp_tw_recycle和tcp_timestamps的相关文章

网络面经总结

TCP与UDP区别总结: 1.TCP面向连接(如打电话要先拨号建立连接);UDP是无连接的,即发送数据之前不需要建立连接 2.TCP提供可靠的服务.也就是说,通过TCP连接传送的数据,无差错,不丢失,不重复,且按序到达;UDP尽最大努力交付,即不保   证可靠交付 3.TCP面向字节流,实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的 UDP没有拥塞控制,因此网络出现拥塞不会使源主机的发送速率降低(对实时应用很有用,如IP电话,实时视频会议等) 4.每一条TCP连接只能是点到点的

tcp timestamp

Description Protocol suite: TCP/IP. Protocol type: Transport layer protocol. Option length: 10 bytes. The TCP Timestamp option obsoletes the TCP Echo request and Echo reply options. RFC 1323: The timestamps are used for two distinct mechanisms: RTTM

99% 的人都不知道的 Kubernetes 网络疑难杂症排查方法

原文链接:Kubernetes 网络疑难杂症排查分享 大家好,我是 roc,来自腾讯云容器服务 (TKE) 团队,经常帮助用户解决各种 K8S 的疑难杂症,积累了比较丰富的经验,本文分享几个比较复杂的网络方面的问题排查和解决思路,深入分析并展开相关知识,信息量巨大,相关经验不足的同学可能需要细细品味才能消化,我建议收藏本文反复研读,当完全看懂后我相信你的功底会更加扎实,解决问题的能力会大大提升. 本文发现的问题是在使用 TKE 时遇到的,不同厂商的网络环境可能不一样,文中会对不同的问题的网络环境

因我而起的生产事故

首先,祝大家新年快乐!应该陆陆续续开始踏上了回家的征程吧! 生产事故 产品上线一段时间之后,技术支持反馈客户现场一个进程总是挂掉或者不干活!最开始不紧不慢的查找问题,后来老大很生气说:生产事故很严重,你们居然不重视!成立了一个应急小组,专门解决此问题,其中包括我! 事故原因 经过2.3天没日没夜的艰苦奋斗,终于找到进程挂掉的原因,问题因我而起.大约去年8月,做一个项目,与大数据对接,把数据推给它,然在加上了推送部分的代码,最开始那个模块是没有日志的,然后给加上了日志打印,当时也没考虑那么多,多线

如何可靠的对接微信、支付宝条码支付

场景 餐厅提供了网络点餐服务,用户通过微信能很方便的进行点餐并支付,享受餐厅提供的各种餐饮服务.其中可靠的支付服务是其中的核心环节之一,如果支付出了问题,对餐厅或用户都是一个损失,甚至会引起纠纷.如何避免发生这样的问题或者是把发生这样问题的概率降到最低,那就需要结合业务特点和使用场景来仔细分析隐藏的问题. 下面以微信支付中的2种支付场景来解析一下对接过程中遇到的问题以及如何解决 条码支付 对于支付宝和微信的条码支付,都是没有支付成功回调的.这点必须注意,那么基于这个特点,服务器对接了条码支付,就

顺丰快递单号查询api对接(全代码)

接口支持的消息接收方式:HTTP POST 请求方法的编码格式(utf-8):"application/x-www-form-urlencoded;charset=utf-8" 请求.返回数据类型:只支持JSON格式 接口提供:快递鸟 系统级参数定义 参数名称 类型 说明 必须要求 RequestData String 请求内容需进行URL(utf-8)编码.请求内容JSON格式,须和DataType一致. 必填 EBusinessID String 商户ID,请在我的服务页面查看.

快递鸟物流查询API接口对接案例

下面是以快递鸟提供的开发者接口进行展开,如有错误,请指正并及时修改. 首先,申请一个快递鸟的账号: 然后进入http://www.kdniao.com/reg界面点击免费申请,免费申请的接口每天接口的请求次数都是没有限制的,超过3000次/每天需接入订阅推送接口. 按照申请流程一步步做完后,即可对接. 注册信息必须填写正确,如果有误可能导致接口无法正常使用.   使用 案例分为3个 使用的是Chrome的postman插件进行Api测试调用 使用JAVA环境进行快递查询 使用.net环境进行快递

C#客户端与Django服务器端对接——HTTP协议之POST&GET

这段时间一直在搞C#客户端与Django搭建的服务器端对接的工作. 从最开始的不知道怎么用Django写服务器端来处理POST请求,到现在能让服务器端接受POST或GET请求并打印出来.虽然客户端还没有登录成功(因为response还没有写好),不过已经取得了部分成果. 任务分析:C#客户端有一个登录界面和一个登录后的界面,用户需要在登录界面输入用户名和密码才能登录成功,而输入用户名和密码后,单击“登录”按钮,触发相应事件,客户端会向以本机作为服务器的某个地址POST用户名和密码,而在客户端单击

C# 对接腾讯企业邮接口----get/post请求

在无所知之的情况下.来了一个对接接口的任务,没办法,只能根据前端时候的经验硬着头皮上了,随后又整理了一下写的方法,主要包括了部门的创建.更新.删除.查找.然后他们的前提是token的获取 首先HTTPHelper类 using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading.Tasks; using System.IO; using Sys