最近在系统的dmesg信息中,经常看到这样的信息:

TCP: Treason uncloaked! Peer 116.236.228.19:24200/80 shrinks window 2847949362:2847961782. Repaired.
TCP: Treason uncloaked! Peer 116.236.228.19:24200/80 shrinks window 2848001802:2848007322. Repaired.
TCP: Treason uncloaked! Peer 218.242.131.162:2842/80 shrinks window 4278428847:4278429327. Repaired.
TCP: Treason uncloaked! Peer 116.236.228.4:13499/80 shrinks window 2375505816:2375509956. Repaired

一段引用了源代码的解释似乎直指了问题的本质

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 some 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.