趣味IT 趣味故事：TCP 出“大事”了！( 二 ) |大事|故事|

Robert也看了一看， “你这么一说，确实是，而且你看，他不是瞎猜，好像是用二分法在猜！序列号是个32位的整数，二分法猜测，只需要32次就能猜出来” 。

本文插图
“二分法？要用二分法的前提他得知道他是猜大了还是猜小了，得不到这个反馈，他就只能瞎猜了。他是如何得知猜大还是猜小的呢？”
两人思来想去，也想不通对方是如何用二分法猜出了最终的序列号，随后将此事报给了网络部传输层主管，主管又将这事报给了帝国安全部长。
揪出潜伏者
部长得知这个消息后，高度重视，要求全面排查网络部TCP小组相关的代码。
大家寻着TCP数据包处理的流程，在序列号检查处的位置发现了问题。

本文插图
如果序列号检查不通过，就会进入tcp_send_dupack ，大家都把注意力放到了这里：

本文插图
“这里这个 before 判断是什么意思？” ，主管问到。
Cerf上前回答说：“这是在判断收到的数据包的序列号是不是比期望的序列号小，如果小的话，说明网络有重传，就要关闭延迟回复 ACK 的机制，需要立即回复 ACK” 。
“延迟回复ACK？”

本文插图
“哦，主管，这是我们 TCP 小组的一个优化， TCP 传输需要确认，但是如果每一次交互数据都发送 ACK 就太浪费了，所以我们做了一个优化，等到多次或者有数据发送的时候，一并把回复的 ACK 带上，就不用了每次发送 ACK 报文，我们把这个叫 Delayed ACK ，也就是延迟确认。 ” ， Cerf继续解释到。
“那下面这个 tcp_enter_quickack_mode 是不是就是关闭这个机制，进入快速 ACK回复模式？” ，主管问到。
“没错没错！”
这时，安全部长指着一行问到， “这里看着有些古怪，是在干嘛？”
“这个我知道， Cerf昨天教过我，这个是在进行统计。把这一次延迟ACK的丢失计入对应的全局计数器中” ， Robert说到。
经验老道的安全部长此刻意识到了问题， “如此看来，收到的序列号比期望小的时候，这个计数器才会增加，如果大了就不会增加。各位试想一下，如果那个猜测的家伙能看到这个计数器有无增长，不就能知道是猜大了还是猜小了？”
Robert摇了摇头说到：“不会吧，这计数器在我们这里，网络上其他人怎么可能知道。再说了，这个计数器大家都在用，用这个判断，误差太大啦！”
主管也摇了摇头， “不对，虽说是大家都在用，不过这里这个计数器很特别，发生的概率很小，一般不会走到这里来，网络哪那么容易出问题嘛” 。

本文插图
安全部长说到：“根据目前掌握的信息，之前就有其他部门反映帝国有奸细混了进来，不过他们一直藏在暗处，至今还没有揪出来。如若他们和外界勾结，作为眼线，观察这个计数器的变化，外面就能知道他的猜测是大是小。对，一定是这样！”
随后，安全部长来到了文件系统部门，调用了/proc/net/netstat的访问记录，根据记录很快定位到了隐藏在Linux帝国的两个细作，下令将他们逮捕。
高矮两位奸细如实交代了一切······
未完待续······