F5：从四个维度看TCP协议优化

　　在经过二十多年的发展后，TCP/IP协议（诞生于1983年）早已不适应现在的网络环境和复杂应用。实际上，业界对TCP/IP协议的各种修补和优化时间也不算短了，还诞生了不少专门做这件事情的公司。而对于专注在应用交付网络领域的F5来说，如何看待TCP协议优化方面的问题呢？对此，F5中国区技术总监吴静涛从以下几个维度上进行了阐述。

　　维度一：TCP协议的广域网优化

　　TCP在最初设计时没考虑到高带宽情况下远程传输的延迟问题，主要问题在于传输数据包的同时还有TCP的校验包。在延迟很小的网络TCP校验包可以忽略不计，但几千公里出去，很可能就是几百毫秒的延迟（中国的网络压力比较大，这种情况很常见），光等校验包的累计时间就要用分钟来计算。这种延迟在广域网上是致命的，而这本身恰恰又是TCP/IP的容错传输机制造成的。

F5中国区技术总监 吴静涛

　　WAN优化里面的TCP优化，是目前很多厂商都采用的优化技术， 实现方法是做成一个TCP代理的方式，多发一些数据包再统一校验，这是很常用的一种方法。在两端放上代理设备，构建与服务器的局域网连接环境，在广域网方面就改变TCP协议的校验方式，通过减少TCP校验的次数，来减少延迟的累计时间，会取得非常大的效果（一般在广域网优化时实现，端到端文件传输的情况）。

　　F5的WAN优化分为几个内容，其中一个就是TCP优化，另外还包括Cache的技术，文件缓存和字典技术等，综合解决协议初期主要考虑了容错而没有考虑到高带宽的延迟问题的优化方法。

　　维度二：TCP连接优化

　　另外，最初设计TCP/IP的时候没有也考虑到网络上那么多应用产生的那么多TCP连接。大量TCP连接对服务器资源的占用，对应用存在很大压力。通过One Connect和TCP Express等连接优化可以释放服务器压力。比如服务器性能最怕的是TCP连接，在一个网络里同时有高带宽和低带宽用户，后者的TCP连接结束就会相对较慢，服务器就要有资源去维护这个连接，当连接很多数据流量不大的情况下，服务器不忙（CPU很低）但资源被耗尽了，支撑不了更多用户，甚至简单的Web服务器都存在这个问题。

　　其实这些连接也是可以优化的，首先，可以直接做TCP连接优化，例如外部用户发起的1万个连接，经过设备以后合并成100个甚至更少的长连接到服务器，因为在线连接数量的下降，服务器性能发挥就会大很多，免费的节省30%左右的服务器压力；第二个方法，当客户端很慢的时候，可以先将服务器的回应包缓存在设备内，尽快结束和服务器的连接，再由优化设备慢慢将服务器回应传输给客户端，这样也可以降低服务器的在线连接，更好的发挥服务器能力（一般在服务器端实现，与客户端无关，大型应用上比较多）。连接耗的资源更多的是内存，在线连接被优化后，内存消耗的情况会好很多。连接优化、服务器回应优化释放资源，等一系列技术采用后，因为TCP在线连接对服务器造成的压力会很大缓解，更有利于服务器性能提升。

　　维度三：TCP的安全问题

　　在互联网上最常见的攻击就是DoS/DDoS，用的最多的就是Syn攻击，其实就是利用TCP的Syn来进行攻击，很多网络攻击都以TCP为依据。Syn Cookie和Delay Binding（延迟绑定）技术可以用来解决这个问题。在F5的TMOS中，采用的是双TCP堆栈技术，客户端和F5设备先建立TCP连接，在F5设备收到真正的请求包后，才会代理客户端发起访问，这样的处理方法保证攻击根本无法到达服务器，来保证应用的正常服务，很多的银行网银系统和互联网站都是采用这种处理方法。

　　维度四：对复杂应用的支持

　　复杂应用的用户会话一般由多个TCP（甚至是UDP）连接组成，在多个连接间存在相互关联关系。在大的服务集群中，如果不能通过辅助处理将这些关联的连接标识，并交由一个集群节点服务，就会出现访问故障。例如用户的注册和访问必须在同一集群节点，如果将注册和访问的两个不同的TCP连接分配到不同的集群节点，访问失败是必然的。如何判断这些不同的TCP联机是否关联，或是否由一个用户发起是和应用相关的，比如HTTP协议可以用Cookie或会话ID，而移动用户可以用Calling ID或手机号码，而这些处理方法都是TCP协议没有涵盖的，需要高层协议或其他设备的支持。

　　综述

　　很多用户都在采用针对广域网延迟的TCP优化，而TCP连接优化也是很多用户都要面对的问题，安全和复杂应用的支持就更是不需要更多讨论的问题。实际上，用户开发一个网上应用的目的，当然是给更多的人用的更好，而如果再规划应用的前期没有考虑到包括TCP优化的一系列应用交付问题。例如应用构建好了，可是交付不到用户，或交付品质不高，包括停机，页面慢，出现安全问题等。因此大部分高端网上应用在规划前期一定要考虑应用交付的问题，避免在出现问题的时候再修修补补。