Tcp Dup ACK--又是数据库的问题
最近，值班的同学反映，有个程序定时会在凌晨4点的时候挂起，重启后恢复，让开发的同事
查了一下，有可能挂起的地方只有在查询数据库，后来gdb也证明了是挂在otl的fetch函数，
这个问题让我想起了，也是同个程序，也是在查询数据库，所以就叫同事捉了个
包，一打开，比较奇怪：
04:17:19 向数据库发起数据，然后回了个ACK，再发了个数据，再回个ACK。紧接着就不停地重发那个ACK了。
会发重复ACK（Dup ACK）理论上是收到数据了，再会回ACK，而回重复ACK应该是收到的是乱序的包，有些
数据丢了，或者是服务器不停地重发同一个包。由于捉包的同事只捉了dst端口，所以来的数据包看不到，今晚
再捉一次，希望能看到真相。 Dup ACK的间隔分别是： 3s, 6s, 12s, 24s, 48s, 64s, 64s,64s 64s,64s,64s
2014-10-30
发现这个超时时间竟然跟TCP/IP详解的说明完全对得上，今天才发现数据库主机是AIX，原来unix的实现还是
这样，Linux做了不少改动。
从这两天发的包已经可以确认，是应用向数据发起请求，数据库收到了，回了数据，应用回了ACK，这个回得
到，接着应用再请求数据，这时数据库发了一个大包，应用只收到第一个包，回了ACK，这个ACK丢了，数据
库不停地重发那个包，应用是收到了，但回了ACK数据库一直收不到了，重发12次后，发了RST，这个RST也
没有收到。这个现象非常奇怪，现在还不知道原因为何：
最近，值班的同学反映，有个程序定时会在凌晨4点的时候挂起，重启后恢复，让开发的同事 查了一下，有可能挂起的地方只有在查询数据库，后来gdb也证明了是挂在otl的fetch函数， 这个问题让我想起了，也是同个程序，也是在查询数据库，所以就叫同事捉了个 包，一打开，比较奇怪： 04:17:19 向数据库发起数据，然后回了个ACK，再发了个数据，再回个ACK。紧接着就不停地重发那个ACK了。 会发重复ACK（Dup ACK）理论上是收到数据了，再会回ACK，而回重复ACK应该是收到的是乱序的包，有些 数据丢了，或者是服务器不停地重发同一个包。由于捉包的同事只捉了dst端口，所以来的数据包看不到，今晚 再捉一次，希望能看到真相。 Dup ACK的间隔分别是： 3s, 6s, 12s, 24s, 48s, 64s, 64s,64s 64s,64s,64s 2014-10-30 发现这个超时时间竟然跟TCP/IP详解的说明完全对得上，今天才发现数据库主机是AIX，原来unix的实现还是 这样，Linux做了不少改动。 从这两天发的包已经可以确认，是应用向数据发起请求，数据库收到了，回了数据，应用回了ACK，这个回得 到，接着应用再请求数据，这时数据库发了一个大包，应用只收到第一个包，回了ACK，这个ACK丢了，数据 库不停地重发那个包，应用是收到了，但回了ACK数据库一直收不到了，重发12次后，发了RST，这个RST也 没有收到。这个现象非常奇怪，现在还不知道原因为何：
下一篇：
MySQL学习(17)︱存储过程及实战