traffic server访问异常分析

zhliji2

1.首先说明一下我测试的客户机跟traffic server网络状况很好，大概有30ms的延迟，而访问同一个url间歇性的访问有异常，有时候打开需要10多s的时间，有时候只要300多ms，这个很不正常，采用curl进行测试发现有时候在建立连接的时候，花费了大量的时间，到服务器端抓包发现客户端发的syn包，服务端没有确认，要客户端发出二个以上的syn包才能确认这个请求，发送syn包的间隔是3秒，linux系统默认是发送5个syn包，而建立连接的时候在代码当中是出现在accept这个函数，也就是说在accept的时候就花费了3秒及其以上的时间，这个是完全不可接受的，另外在服务器端返回第一个数据包的时间也是有点过长，我发现有时候也是需要3秒的一个时间，另外传输完一个100K的js文件，发现有时候也不稳定，有时候需要5秒，有时候又是700ms，而我测试的时候都是在同一个公网有2个ats服务器，另外一个正常，
2.gzip插件明明加载进去，但是不知道是我配置不对，还是怎么着，前端抓包看，死活就是没有看到开启gzip的的http头，导致文件大。


另外，这次测试的ats版本，试过3.0.3，3.0.4，3.1.13

aaaaaa

问题1，基于你2个机器中一个是正常的，怀疑你的这个机器硬件方面可能存在问题。

问题2：
gzip是为后台服务器不支持gzip压缩或其他原因而作的，如nginx如果检测到前面有proxy默认就不给你gzip的内容。你的需求是啥？

zhliji2

回复 2# aaaaaa

1.现在是两个机器都不正常，都是间歇性的不正常，应该肯定是没有啥问题，现在是遇到这个问题，不知道怎么排查问题在那
2.后端的nginx肯定是支持gzip，只是我看到ats访问过去的请求并没有看到带有这个gzip的头。


   

aaaaaa

1，我仍然怀疑硬件、物理链路方面的问题：你可以看看网卡有丢包啥的不，如netstat -s 或ifconfig看看error drop等统计。然后如果流量少，可以抓一下服务器的包，你说的syn重传，很像是syn包丢掉了。

2，我说的nginx默认配置如果看到proxy带过来的via头，就不会给你gzip的内容了。