用于执行传输控制协议握手的设备和方法
技术领域
本公开一般涉及计算机系统,并且具体地涉及在这样的系统中执行TCP/IP握手。
背景技术
这部分旨在向读者介绍技术的各个方面,其可以与下面描述和/或请求保护的本公开的各个方面有关。相信此讨论有助于为读者提供背景信息,以促进对本公开的各个方面的更好理解。因此,应当理解,要从这个角度来阅读这些陈述,而并非作为对现有技术的承认。
在描述中,词语“客户端”可以用于指代TCP客户端,即发送SYN消息和ACK消息的设备,并且词语“服务器”可以用于指代TCP服务器,即接收SYN消息的设备。因而,应当认识到,这种“客户端”在术语的更一般使用中可以是服务器(诸如web服务器),并且以对应方式,“服务器”也可以是客户端,诸如web客户端。根据上下文来看,将要如何理解这些术语是清楚的。
TCP/IP是非常熟知的通信协议。为了在两个设备之间创建TCP/IP连接,这两个设备执行图1所示的TCP握手。第一设备(被称为客户端)将包括第一设备的IP地址和第一整数m的SYN(m)消息发送到第二设备(被称为服务器)。如果服务器接受请求,则该服务器使用SYN-ACK(m+1,n)消息向所接收的IP地址进行响应,该SYN-ACK(m+1,n)消息包括第二整数n和第一整数m加1,即m+1。在发送SYN消息之后,客户端对所发送的SYN消息保存记录,并且等待预定时间;如果在时间耗尽之前客户端尚未接收到对应SYN-ACK消息,则该客户端停止等待。当从服务器接收到SYN-ACK消息时,客户端检查该SYN-ACK消息包括m+1。如果是这种情况,则客户端通过向服务器发送ACK(n+1)消息来确认接收,所述ACK(n+1)消息包括第二整数n加1,即n+1。服务器最后验证ACK消息包括n+1。假设服务器验证是成功的,在此之后,已成功完成握手。
在某些情形下,例如当客户端试图与多个服务器并行执行握手时,握手期间设备不得不保持资源分配可能是个问题。对于每个发出或接收的SYN,TCP堆栈初始化一个传输控制块(TCB)记录,每个记录需要几百个字节。在三路握手期间,关于网络速度没有进行先验的假设。因此,TCB记录可能长时间幸存,消耗了资源。更糟的是,当将SYN发送到未连接或未响应的设备时,TCP堆栈将对应TCB维持一些时间(超时持续时间),从而浪费了资源。
将认识到,期望有一种至少部分克服与TCP握手有关的问题的解决方案。本公开提供了这种解决方案。
发明内容
在第一方面,本原理针对一种用于执行TCP握手的设备。该设备包括:接口,其被配置为在至少一个外部设备与该设备的处理器之间传输消息;和
处理器,其被配置为从接口接收SYN-ACK消息,所述设备对于所述SYN-ACK消息并未发送过对应SYN消息,所述SYN-ACK消息包括源地址;生成与SYN-ACK消息对应的ACK消息;以及向接口发送ACK消息以传输到源地址。
第一方面的各个实施例包括:
·处理器被配置为访问存储所传输的SYN消息的记录的TCP堆栈,以及通过好像设备已发送过对应SYN消息一样地修补TCP堆栈并且通过创建与对应SYN消息对应的记录,由此好像设备已发送过对应SYN消息一样地重建TCP握手。有利的是,每个记录包括SYN消息的序列号,处理器进一步被配置为通过从SYN-ACK消息中对应的整数中减去1来获得对应SYN消息的序列号。
·该设备还包括防火墙,所述防火墙被配置为截取SYN-ACK消息并且向处理器通知该截取,处理器进一步被配置为生成向源地址发送的对应SYN消息并且更新TCP堆栈,以及防火墙进一步被配置为截取处理器所生成的对应SYN消息,然后仅将SYN-ACK消息转发到处理器。
·处理器进一步被配置为将对于数据的请求发送到服务器,该请求包括第一整数,从服务器接收数据,以及使用第一整数以及随SYN-ACK消息一起接收的第二整数,验证该SYN-ACK消息与该请求相关。
在第二方面,本原理针对一种用于执行TCP握手的方法。设备的处理器接收设备尚未为其发送过对应SYN消息的SYN-ACK消息,该SYN-ACK消息包括源地址,以及生成并且发送对应于SYN-ACK消息的ACK消息到该源地址。
第二方面的各个实施例包括:
·该方法还包括:访问存储所传输的SYN消息的记录的TCP堆栈,以及通过好像设备已发送过对应SYN消息一样地修补TCP堆栈并且通过创建与对应SYN消息对应的记录,由此好像设备已发送过对应SYN消息一样地重建TCP握手。有利的是,每个记录包括SYN消息的序列号,处理器进一步被配置为通过从SYN-ACK消息中对应的整数中减去1来获得对应SYN消息的序列号。
·该设备还包括防火墙,所述防火墙被配置为截取SYN-ACK消息并且向处理器通知该截取,处理器进一步被配置为生成向源地址发送的对应SYN消息并且更新TCP堆栈,以及防火墙进一步被配置为截取处理器所生成的对应SYN消息,然后仅将SYN-ACK消息转发到处理器。
·处理器进一步被配置为将对于数据的请求发送到服务器,该请求包括第一整数,从服务器接收数据,以及使用第一整数以及随SYN-ACK消息一起接收的第二整数,验证该SYN-ACK消息与该请求相关。
在第三个方面,本原理针对一种包括处理器的服务器,所述处理器被配置为从客户端接收对于数据的请求,该数据包括第一部分和第二部分并且该请求包括客户端的地址,发送第一部分到客户端,发送TCP握手的SYN消息到被配置为将第二部分提供给客户端的另一设备,该SYN消息包括作为源地址的客户端的地址。
第三方面的实施例包括:该请求包括整数,该处理器还被配置为随SYN消息一起将该整数发送到另一设备。
在第四方面,本原理针对一种方法,包括在服务器的处理器处:从客户端接收对于数据的请求,该数据包括第一部分和第二部分并且该请求包括客户端的地址,将第一部分发送到客户端,以及将TCP握手的SYN消息发送到被配置为将第二部分提供给客户端的另一设备,该SYN消息包括作为源地址的客户端的地址。
第四方面的实施例包括:该请求包括整数,并且其中该处理器进一步随SYN消息一起将该整数发送到另一设备。
附图说明
现在将通过非限制性举例的方式参照附图来描述本原理的优选特征,附图中:
图1示出了根据现有技术的TCP握手;
图2示出了实施本原理的系统;以及
图3示出了根据本原理的在设备处执行TCP握手的方法。
具体实施方式
图2示出了实施本原理的系统200。该系统200包括发起者设备210、至少一个服务器设备220和至少一个终止者设备230。虽然仅对一些设备进行说明,但是这些设备210、220、230中的每个设备包括:至少一个硬件处理单元(“处理器”)211、231,存储器212、232,以及至少一个通信接口(I/O)213、233,所述至少一个通信接口(I/O)被配置为与其它设备传送消息至/自处理器。终止者设备230还可以包括防火墙234,所述防火墙可能在处理器231中或在单独的处理器(未示出)中实施。技术人员将认识到,为了清楚起见,所示出的设备非常简化,并且真实设备另外将包括诸如内部连接和电源之类的特征。正如所描述的,该处理器被配置为运行(可能至少部分地存储在存储器中的)指令,以便处置消息、执行计算等。非瞬时性存储介质(未示出)存储指令,当处理器运行该指令时,在下文描述的终止者设备处执行TCP握手方法。
为了执行TCP握手,发起者设备210开始于:将SYN(m)消息240发送到服务器220。SYN消息包括第一整数m以及不同于标准现有技术握手的终止者设备的IP地址。此后,发起者设备210可以忘记关于所发送的SYN消息240的全部内容;对于发起者设备210而言,存储TCB是没有意义的,因为发起者设备将不会接收任何对应SYN-ACK消息。在一个实施例中,具体适用于例如监测许多服务器设备,发起者设备210可以在终止者设备的网络地址之中选择源地址,以便在终止者设备之间提供负载平衡;然后,对于终止者设备而言有利的是,将其各自负载上的反馈提供给发起者设备。
服务器220像现有技术的服务器一样作出反应,即通过使用包括m+1和第二整数n的对应SYN-ACK(m+1,n)信息250进行响应。要注意的是,服务器220将该响应发送到SYN消息240的源IP地址,因为服务器220相信这是SYN消息240的发送方的IP地址。
接收SYN-ACK消息的终止者设备230未存储对应的TCB,这意味着该SYN-ACK消息首次接触TCP握手。终止者设备230因此需要重建TCP握手,就好像该终止者设备已发送原始SYN消息240一样。这可以通过各种方式来进行,以下将给出所述各种方式的两个例子。
第一种方式是通过将终止者设备的TCP状态机设置为ESTABLISHED以及通过使用对应于第一整数m的序列号重建TCB,由此来修补该终止者设备的TCP堆栈。通过从SYN-ACK消息250中接收的已增大的整数中减去1,即通过计算(m+1)-1,很容易计算出序列号。一般地,TCP堆栈还保留SYN消息240的时间戳;使用SYN-ACK消息250的接收时间之前的时间,可以重建该时间戳。这种方式的优势是轻量级,但另一方面,修补TCP代码是复杂的。
第二种方式是在终止者设备230上使用防火墙234,以截取SYN-ACK消息250并且通知终止者设备230中的功能(function)来接收。该功能生成向服务器220发送但也被防火墙截取的对应SYN(m)消息,该防火墙接着仅将SYN-ACK消息250转发到TCP堆栈。这种方式的优势是,未修改TCP堆栈,但其需要诸如防火墙和功能之类的另外资源。
可以将TCP堆栈存储在处理器(如果处理器具有足够的资源)中,或者存储器中,或者其组合中。在任一种情况下,处理器能够访问TCP堆栈。
终止者设备230接着将SYN(n+1)消息260发送到服务器220,握手随之终止。
图3示出了根据本原理的在终止者设备处执行TCP握手的方法。终止者设备230没有为即将到来的TCP握手存储任何TCB;换言之,终止者设备未发送初始SYN消息,并且甚至可以没有意识到这种消息已被发送。
在步骤S310中,终止者设备的通信接口从服务器接收SYN-ACK(m+1,n)消息。在步骤320中,终止者设备使用例如上述两种方式之一来重建TCP握手,就好像它已发送过原始SYN消息一样。在步骤S330中,终止者设备然后将SYN(n+1)消息发送到服务器,并且握手随之终止。
可以在远程监测诸如网关或移动电话之类的设备时使用本原理。用于这种监测的现有技术解决方案存在问题,这主要是因为:由于对于SYN消息要被发送到的每个设备,资源被分配在多个监测服务器中,因此要监测大量设备(成百上千或甚至数百万)。主要现有技术解决方案是水平缩放(horizontalscaling),即根据待监测的设备的数量来添加监测服务器。缩放的成本最多是线性的,但通常需要额外的基础设施。
将认识到,本原理可以至少部分克服该问题。发起者设备未保留任何状态并且未存储任何TCB,这意味着其不必为待检测的每个设备分配资源(除了发送SYN消息所需的资源之外)。被监测的设备按照现有技术的方式运作,正如已经解释过的。最终,终止者设备(在这种情况下,通常不止一个)仅需要在接收到SYN-ACK消息时将资源分配给被监测的设备。因而,出于一个或其它理由,不需要为未响应的设备分配资源。
还可以在诸如web浏览器之类的客户端请求包括由不同提供商提供的信息的web网页时使用本原理。这样的web网页的主要例子是在线报纸的头版,所述在线报纸的头版除了包括由报纸本身提供的新闻文章之外,还包括由不同广告提供商提供的广告。
将认识到,还可以在这种情况下使用本原理。当客户端从服务器请求web网页时,服务器可以充当发起者设备的角色,并且将SYN消息发送到第三方服务器,该第三方服务器为所请求的web网页提供追踪、广告、缓存、嵌入内容等。服务器欺骗(spoof)这些SYN消息的源地址,以便这些消息看起来像是源自客户端。第三方服务器根据正常TCP握手运作,即,他们使用被发送到客户端的SYN-ACK消息来进行“响应”。当接收到SYN-ACK消息时,客户端接着像终止者设备一样行动,即,客户端重建TCP连接并且将SYN消息发送到第三方服务器。
有利的是使用类似于SYN-cookies的特征:客户端的请求包括整数,所述整数由服务器转发到第三方服务器,以便被包含在发送到客户端的SYN-ACK消息中。这样,客户端可以验证所接收的SYN-ACK消息与对于web网页的请求有关。第三方服务器可以包含照原样的整数,但也可以在包含之前通过例如增大该整数来处理该整数(正如使用SYN消息中的整数来进行)——在任何情况下,所接收的整数允许验证该SYN-ACK消息与请求相关。
这样的优势在于可以加速该连接,因为客户端与第三方服务器之间的连接可以更快——服务器初始化TCP握手时,客户端不需要等待web网页中关于第三方服务器的信息。有利的是,客户端例如在其请求中通知服务器,该客户端能够处理修改的TCP握手,因为不能做这一点的设备将简单地拒绝来自于第三方服务器的SYN-ACK消息。
因而将认识到,本原理提供了一种至少在某些情况下能够改进现有技术TCP握手的TCP握手。
说明书和(适当地方的)权利要求书以及附图中公开的每个特征可以被单独或以任何适当组合来提供。被描述为以硬件实施的特征也可以以软件实施,反之亦然。权利要求中出现的附图标记仅是用于说明的方式,并且对权利要求的保护范围没有限制效果。