大话TCP:TCP的协议头以及其固化问题

Mon 14 August 2017 / In categories Networking Protocols

TCP

这篇讨论TCP的协议头,以及网络对TCP协议头产生的固化效果。

TCP协议头

TCP的协议头在RFC793定义的,可以说非常之精简:

    0                   1                   2                   3   
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Source Port          |       Destination Port        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sequence Number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Acknowledgment Number                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Data |           |U|A|P|R|S|F|                               |
   | Offset| Reserved  |R|C|S|S|Y|I|            Window             |
   |       |           |G|K|H|T|N|N|                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Checksum            |         Urgent Pointer        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Options                    |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             data                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

下面简单介绍下TCP协议头各个字段的作用:

  • Source Port,Destination Port,Checksum这三个是和UDP的协议头类似,就不赘述了
  • Data Offset的单位是4字节。TCP头的固定长度是20个字节,如果不带Option,Data Offset的值就是20/4=5;如果带Option,那么Option的字节数的计算公式是Data Offset x 4 - 20。
  • Window是用来做流控的,接收端通过这个字段来告诉发送端接收窗口的大小。
  • Sequence Number和Acknowledge是用来做确保数据的可靠性。
  • URG/ACK/PSH/RST/SYN/FIN几个控制位是用来管理TCP连接的。
  • Urgent point是TCP设计的一个小败笔吧,RFC6093已经不推荐使用TCP的Urgent机制了,留着这个字段,只为保持向后兼容性。

除了以上的固定字段以外,TCP还有很多Options用来扩展协议头的功能,由于不是本文的重点,所以就不一一列举了。

从网络视角看TCP

从TCP连接的两端看,网络好像是一条双向的快车道。但实际上不是这样子的,网络是由一个一个节点(路由器和交换机)构成的,其中很多节点会对TCP的头进行检测和修改,如下图所示:

                 +--------+      +--------+                    
                 | Middle |      | Middle |                    
             />>>| Box 1  |>>>>>>| Box 2  |>>>>>>>\            
            /    +--------+      +--------+        \           
  +--------+                                        +--------+ 
  | Server |                                        | Client | 
  +--------+                                        +--------+ 
           \             +--------+                /           
            \<<<<<<<<<<<<| Middle |<<<<<<<<<<<<<<</            
                         | Box 3  |                            
                         +--------+                            

对上图的一些解释。首先网络具有上下行不对称性。对于双向的TCP连接来说,上行和下行在网络中走的路径可能完全不一致。在上图中位于上方的路径表示从Server到Client;位于下方的路径表示从Client到Server。不管是上行的路径还是下行的路径,都是Middlebox的存在,对TCP的协议头进行检测和修改。这些Middlebox有不同的目的,有的是为了增加TCP的性能,而其他的则可能是为了阻止和过滤某些TCP流量。Middlebox的种类非常多,RFC 3234 - Middleboxes: Taxonomy and Issues对各种Middlebox进行了专门的介绍。

固化问题

TCP的协议头是暴露给网络的,就算使用TLS加密,能被加密的也只是TCP搭载的数据,而不是TCP的协议头。现在问题来了,如果网络的Middlebox对TCP的协议头做了各种各样的动作,那么TCP的协议头就会被固化住,很难修改和增加其他功能。因为一旦TCP协议头进行了修改,必须得让这些Middlebox认识和学会如何处理修改后的TCP协议头才行。在现实情况下,这基本是不太可能的,因为Middlebox是归属于不同群体,想让大家统一行动,那得费多大的力气啊。

这就给TCP带来了一个大难题,但凡TCP要做任何的改进,它就要取得太多太多人的认可,极大地阻碍了TCP的演进。有一个英文术语专门用来描述这个问题,叫做ossifying ,指的就是TCP协议头固化的问题。

Is it still possible to extend TCP?这篇论文里面对Middlebox对TCP协议的影响进行探究,得出了一个结论:虽然很难,TCP依然可以扩展,但是必须要考虑非常非常多东西,感兴趣的可以去看一下这篇论文。

总结和展望

TCP暴露了太多信息在协议头,所以导致的现在的困境,这个问题已经被大家伙所认识。未来的传输协议,如Google的QUIC,就吸取了经验和教训,对协议头里面的大部分信息都进行了加密,使之无法被检测和篡改,保留了协议演进的可能性。

(完)

Load Disqus Comments