在debian Linux服务器的日志中，dmesg出现类似的信息：
TCP: Treason uncloaked! Peer 202.106.38.7:57824/80 shrinks window 3573023813:3573023814. Repaired.
TCP: Treason uncloaked! Peer 202.106.38.7:57824/80 shrinks window 3573023813:3573023814. Repaired.
TCP: Treason uncloaked! Peer 202.99.99.211:3760/80 shrinks window 1828242657:1828242673. Repaired.
TCP: Treason uncloaked! Peer 210.76.114.42:2544/80 shrinks window 504374393:504375853. Repaired.
..........
查了资料，求助了google：
That comes from the kernel tcp code below. Looks like the DLink has returned information yielding a transmit window smaller than it previously did; specifically it returned a window of zero plus an ack of up to byte 3957222360, thus indicating that it can accept nothing after that byte. Previously it had sent ome ack+wnd values indicating that it would accept up to byte 3957222379.
The Linux side is now supposed to send a packet every now and then forever until the returned window is nonzero. It does.
However, the dlink is apparently not responding in a timely manner. Any response would either open the window or update the rcv timestamp such that the thing will retransmit forever. It may be responding very slowly, or just not responding at all.
The kernel prints the message after it expected but did not see a response to the probe packet it sent to check for a nonzero window. The kernel implements exponential backoff retransmissions until it hasn't seen any response in 2m, then it will bail and close the connection. This is reasonable. It's unclear from your report if the connections are failing outright or just sometimes having to retransmit a probe against a peer that shrank the window.
结论：
TCP: Treason uncloaked! Peer 202.106.38.7:57824/80 shrinks window 3573023813:3573023814. Repaired.
TCP: Treason uncloaked! Peer 202.106.38.7:57824/80 shrinks window 3573023813:3573023814. Repaired.
TCP: Treason uncloaked! Peer 202.99.99.211:3760/80 shrinks window 1828242657:1828242673. Repaired.
TCP: Treason uncloaked! Peer 210.76.114.42:2544/80 shrinks window 504374393:504375853. Repaired.
..........
查了资料，求助了google：
That comes from the kernel tcp code below. Looks like the DLink has returned information yielding a transmit window smaller than it previously did; specifically it returned a window of zero plus an ack of up to byte 3957222360, thus indicating that it can accept nothing after that byte. Previously it had sent ome ack+wnd values indicating that it would accept up to byte 3957222379.
The Linux side is now supposed to send a packet every now and then forever until the returned window is nonzero. It does.
However, the dlink is apparently not responding in a timely manner. Any response would either open the window or update the rcv timestamp such that the thing will retransmit forever. It may be responding very slowly, or just not responding at all.
The kernel prints the message after it expected but did not see a response to the probe packet it sent to check for a nonzero window. The kernel implements exponential backoff retransmissions until it hasn't seen any response in 2m, then it will bail and close the connection. This is reasonable. It's unclear from your report if the connections are failing outright or just sometimes having to retransmit a probe against a peer that shrank the window.
结论：
The remote host decided to shrink the TCP window size without negotiating such with your Linux box. The message is of the informational level, meaning Linux doesn't like what it is seeing but will cope with it and carry on.
意思是：在远程client和服务器通信的过程中，由于client没有和服务器协商，就减少了 TCP window的长度，也就是包的大小变小了，因此有这类的提示信息，此时服务器依然处理该类请求，但是处理的速度会比之前较差。
出现这种情况的时候，最好看看你的服务器流量监控情况，看看是否有流量异常，如果带宽被占满，有可能被电信或者联通进行了带宽限制，最好的方法是花费银子买带宽，或者看看你的web服务器有没有可优化的地方，例如gzip是否开启，响应时间是合适等等，这些手段比被电信限制你的龟速访问的体验好一些，是没钱人的垂死挣扎的手段，不是最终的方法。
此类问题，增加带宽或许是最好的方式。
