别用TCP的紧急数据

公司分布式系统的通信组件实在有点看不下去了，有自己的想法，动动手吧，有个原型也好与人ＰＫ。

想当然地希望使用TCP紧急数据处理作为“消息”的异常中止标志，心想这个简单，加了EPOLLPRI后，一直表现正常的epoll_wait()突然陷入了看似万劫不复的等待当中。修改一下代码后，发现了另一个问题，明明是用send(MSG_OOB)发送的带外数据，却出现在正常的字节流中，可是没有设置SO_OOBINLINE啊，神秘事件。

费几个周折，最终确定我的代码是ＯＫ的，稍微修改一下UNP的例子也可以重现这个问题：让sender只发送MSG_OOB数据，而接收者不读归紧急数据，只读取正常的字节流。不一会儿，接收程序就从正常字节流中读出东西了。按预想的情况，接收者应该永远阻塞才是。

开始以为是TCP receiver side的内核代码出了问题，检查一下更新tcp_sock->urg_data/urg_seq的代码没有什么问题啊，并且2.6.32和2.6.38-rc7都有这个问题！抓包看看吧，有些数据包有16384字节长。看来发送消息时就有“问题”，看tcp_sendmsg()吧。果然这里是有可能出现情况的。心想，这是个bug吧！心中窃喜，让俺抓到TCP stack的小辫子了？

怎么fix呢？查查以前下载RFC全集，根本就没要求带外数据一定不能出现字节流中。想了想，改这个真是有些复杂的，发送端需要修改不说，连滑动窗口的行为恐怕都得动，不然，接收端可能还得缓冲一堆紧急指针。仔细想了想，这个劳什子的ＴＣＰ紧急数据其实就是个不中用的货色：

１、最直观的缺点：名为带外数据，其实不带外，这也就罢了。数据长度只有一个字节，作用实在有限。

２、带外数据在TCP头内的偏移只有16bit长，而现代TCP连接大量使用的window scaling选项，这样滑动窗口的容量大大超出了16 bits能表示的范围。因此很可能在接收端还没有知晓前一个带外数据的时候，后一个段已经把紧急指针写掉了。这样，前一个紧急数据就被丢掉了。接收端的应用程序可能根本就不知晓。

３、Linux的ＴＣＰ实现，如果两个紧急数据挨的太近，就引起上面的我提到的bug。

后来发邮件问了问netdev邮件列表上的达人，John回复说，参考一下RFC6093吧，一看，这个ＲＦＣ还挺新鲜，2011-01, TCP的紧急数据已经是废弃的功能了。不建议新的应用程序使用，只为旧程序兼容而存在。即使是使用，也建议使用打开SO_OOBINLINE。可是，我要说，打开这个选项也没有什么帮助，因为这个选项只对接收端有作用，tcp_sendmsg()还是可能出现上述（３）的问题。TCP的ＲＦＣ和实现代码都好复杂啊，对于它，很有些积重难返的感觉。也许在许多场合，ＳＣＴＰ是个更好的选择吧。

一句话，别用的ＴＣＰ的紧急数据。