某OA系统访问慢原因分析
1.1. 故障描述
OA系统通过80端口对内提供服务，B/S架构，客户端通过网络直接访问OA服务器，中间会经过二个交换机和一个路由器。
故障现象：部份客户端访问OA速度慢，打开OA附件（pdf\doc）的速度慢。
1.2. 分析过程
1. 客户端访问速度慢原因分析
（访问时间统计）
（流量统计）
?访问总共耗时24s左右，确实访问慢；
?流量640KB，流量较大，因为OA首页并没有太多的链接；
?数据包共1664个，小包887个（742+145），占数据包的53%左右，数据包分布较异常；
（网络延迟分析）
（客户端响应分析）
客户端到服务器的RTT值为0.3ms，属于正常值；
客户端发送确认数据包后，在20s后再发起另一个应用请求；
分析结论：客户端延迟
2. 打开附件慢原因分析
1M左右的数据，传输时间2分38秒，效率很差；
服务端在155ms的时间内对客户端的请求进行了响应，并在之后的80ms开始发送数据；服务器端响应比较正常；
但我们在此会话中发现很多连续的ACK数据包，如下图：
经分析，这是客户端对服务器端传输数据的确认，随机打开一个确认数据包（编号1276）：
通过序列号和确认号可以分析出该数据包相关联的数据包（编号1207）：
可以看到，编号1276的数据包是对编号为1207的数据包进行确认，两个包之间的时间相差700ms。
分析结论：客户端延迟
问题出在客户端，客户端与OA相关的就是浏览器，难道问题出在浏览器上，与客户沟通后了解，网络中的浏览器种类、版本较多，而访问慢的机器都是使用IE6，其他机器则正常，将一问题机器浏览器更新到IE7后，访问速度恢复正常。（后来询问应用开发，证实该OA完全是在IE7的基础上开发的）
3. 关于小包太多的原因分析
客户端对服务器发送的每一个数据包都进行确认(ACK)，会造成访问应用的数据包增加，同时也会极大的浪费网络带宽，建议对客户端确认机制进行修改。（采用Delayed ACK机制）
采用Delayed ACK机制后，通常是服务端发送2个数据包后，客户端再进行确认，这样将极大的减少不必要的ACK数据包，同时也能提高访问速度，减少带宽浪费。
修改方法：
?重新设计OA系统的通讯机制
?在注册表中添加键值进行修改；
?HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\Ad
apter GUID
?值名称：TcpDelAckTicks（不同的操作系统该值的名称不尽相同）
数据类型：REG_DWORD
值数据：将该值设置为0 到6 之间的值
?默认情况下，延迟ACK 计时器值为200 毫秒。如果将TcpDelAckTicks 值设置为0，则禁用延
迟确认。