CN107995233A - 建立连接的方法及相应的设备 - Google Patents

Abstract

本申请的目的是提供一种快速建立TCP连接的方法及相应的设备，用以解决现有技术中请求建立连接的数据包容易被防火墙丢弃，造成建连失败的问题。与现有技术相比，本申请提供的方案中，客户机在发起建连请求时，同时发送握手包和请求数据包，其中，握手包即为建立普通TCP连接的握手包，请求数据包中包含了用于向服务器请求相关数据的数据请求；相应地，服务器在接收到来自客户机的请求数据包以及握手包，或者由于各类原因仅接收到请求数据包时，可以根据这些包所携带的相应内容确定请求数据包来自于匹配的客户机，进而与客户机建立连接，由于握手包和请求数据包分别单独发送，无须将数据请求塞入握手包中，因此不会被防火墙丢弃，而造成建连失败。

Description

建立连接的方法及相应的设备

技术领域

本申请涉及信息技术领域，尤其涉及一种快速建立TCP连接的方法及相应的设备。

背景技术

TCP(Transmission Control Protocol，传输控制协议)作为常用的传输协议，对现有的互联网应用影响巨大。所有基于TCP的应用，在传输速度方面，都不免受到TCP自身处理机制的限制。现有的移动端App(Application，应用)或PC(Personal Computer，个人计算机)端的Web(互联网)页面，需要尽快展现给用户，否则会造成糟糕的体验效果，并导致点击率下降。常见的应用请求，其所要求的数据传送规模并不大，有众多的请求仅仅要求服务器提供十几KB乃至几个KB的数据。

而现有的TCP处理机制，在这种应用场景中，很容易造成带宽浪费，传输效率低。由于TCP是可靠的传输协议，所以在数据传输开始之前，要求客户机(client)和服务器(server)确认建立连接，也就是三次握手，如图1所示。以客户机发起请求的情况为例，客户机首先发出一个握手包(SYN包)给服务器；如果服务器收到了这个握手包，则回应一个握手确认包(SYN+ACK包)给客户机；客户机接到握手确认包之后，会再向服务器回复一个确认包(ACK包)表示确认连接建立。而后客户机才开始发送数据请求，这样，在发送数据请求之前，已经浪费了一个往返延时(Round Trip Time，RTT)。这对于需要频繁建立连接的交互式应用而言，影响较大，拖慢了传输效率。

目前解决传输时，节省建连开销的办法主要有两种：一、连接保活。在应用层和TCP层都有一些保活机制，比如HTTP keepalive，其核心原理是在同一条连接上不断发送保活探测包，以维持连接的可用性。使用连接保活技术来节省建连开销，有以下几个问题：

1.仅适用于复用同一条连接的情况。无论是TCP还是应用的保活机制，都是在同一条连接上维持可用性。而复用同一条连接，需要应用程序的支持。

2.不能应对需要频繁建立新连接的动态路径切换场景。在动态路径切换的场景中，多个节点之间有多条通路，为了实时选择最近路线，往往需要频繁切换连接。

二、Google提出的TCP Fast Open机制，在发送SYN包建立连接时，携带数据请求，其具体交互流畅如图2所示，为了防止DDos(Distributed Denial of Service，分布式拒绝服务)等攻击，需要在支持Google TCP Fast Open的客户机和服务器之间建立信任关系。因此在初始化时，客户机需要向服务器发起TFO cookie请求(TFO cookie request)。在拿到cookie之后，客户机的后续发送数据请求(data)的过程可以节省建连开销。在每次发起建连请求时，携带TFO cookie和data(即发送的数据包为SYN+TFOcookie+data包)，服务器收到正确的cookie之后，可以快速建立连接，并将data交给上层处理。这样，在建连的同时，就可以触发服务端发送数据，比传统的TCP交互过程节省了一个往返延迟。由此可知，使用Google TCP Fast Open(GTFO)来节省建连开销时还存在如下问题：

1.GTFO必须将数据请求塞入SYN包才能起到节省建连开销，由于这种SYN+DATA的握手包与建立TCP连接的标准握手包存在差异，许多防火墙对会主动丢弃，而防火墙的主动丢弃行为会造成大量的建连失败，导致其在实际场景无法应用。

2.在防攻击和加密控制上付出较大开销，为了防止DDos攻击，做了复杂的防攻击和加密控制策略，例如在初始化时需要请求cookie，开销较大。

申请内容

本申请的一个目的是提供一种快速建立TCP连接的方法及相应的设备，用以解决现有技术中请求建立连接的数据包容易被防火墙丢弃，造成建连失败的问题。

为实现上述目的，本申请提供了一种在服务器端建立连接的方法，该方法包括：

在接收到来自客户机的请求数据包以及握手包时，根据所述握手包的序号以及请求数据包的确认号，确定所述请求数据包来自于匹配的客户机；

建立与所述客户机的连接。

进一步地，根据所述握手包的序号以及请求数据包的确认号，确定所述请求数据包来自于匹配的客户机，包括：

根据所述握手包的序号和所述服务器的标识信息设定握手确认包的序号；

若所述握手确认包的序号与所述请求数据包的确认号匹配，则确定所述请求数据包来自于匹配的客户机，其中，所述请求数据包的确认号根据所述握手包的序号和所述客户机的标识信息设定，且与确认包的确认号一致。

进一步地，根据所述握手包的序号和所述服务器的标识信息设定握手确认包的序号之后，还包括：

向所述客户机发送所述握手确认包，以及接收所述客户机基于所述握手确认包发送的确认包。

本申请还提供了另一种在服务器端处理数据请求的方法，该方法包括：

在接收到来自客户机的请求数据包时，根据所述请求数据包中包含的客户机的识别信息，确定所述请求数据包来自于匹配的客户机；

建立与所述客户机的连接。

进一步地，根据所述请求数据包中包含的客户机的识别信息，确定所述请求数据包来自于匹配的客户机，包括：

若所述请求数据包中包含的客户机的识别信息与服务器的识别信息一致，则确定所述请求数据包来自于匹配的客户机。

进一步地，在确定所述请求数据包来自于匹配的客户机之前，还包括：

由内容分发网络节点获取服务器的标识信息，其中，所述服务器的标识信息与匹配的客户机的标识信息一致。

本申请还提供了一种在客户机端建立连接的方法，该方法包括：

向服务器发送请求数据包以及握手包，以使所述服务器根据所述握手包的序号以及和请求数据包的确认号、或根据所述请求数据包中包含的客户机的识别信息，确定所述请求数据包来自于匹配的客户机，并建立连接。

进一步地，向服务器发送请求数据包以及握手包之后，还包括：

接收来自所述服务器的握手确认包，以及向所述服务器发送基于所述握手确认包生成的确认包。

进一步地，在向服务器发送请求数据包以及握手包之前，还包括：

由内容分发网络节点获取获取客户机的标识信息，其中，所述客户机的标识信息与匹配的服务器的标识信息一致。

基于本申请的另一方面，还提供了一种服务器，该服务器包括：

处理装置，用于在接收到来自客户机的请求数据包以及握手包时，根据所述握手包的序号以及请求数据包的确认号，确定所述请求数据包来自于匹配的客户机；

连接建立装置，用于建立与所述客户机的连接。

进一步地，所述处理装置用于根据所述握手包的序号和所述服务器的标识信息设定握手确认包的序号；以及在所述握手确认包的序号与所述请求数据包的确认号匹配时，确定所述请求数据包来自于匹配的客户机，其中，所述请求数据包的确认号根据所述握手包的序号和所述客户机的标识信息设定，且与确认包的确认号一致。

进一步地，该服务器还包括

收发装置，用于在根据所述握手包的序号和所述服务器的标识信息设定握手确认包的序号之后，向所述客户机发送所述握手确认包，以及接收所述客户机基于所述握手确认包发送的确认包。

此外，本申请提供的另一种服务器包括：

处理装置，用于在接收到来自客户机的请求数据包时，根据所述请求数据包中包含的客户机的识别信息，确定所述请求数据包来自于匹配的客户机；

连接建立装置，用于建立与所述客户机的连接。

进一步地，所述处理装置用于在所述请求数据包中包含的客户机的识别信息与服务器的识别信息一致时，确定所述请求数据包来自于匹配的客户机。

进一步地，所述收发装置，还用于在确定所述请求数据包来自于匹配的客户机之前，由内容分发网络节点获取服务器的标识信息，其中，所述服务器的标识信息与匹配的客户机的标识信息一致。

此外，本申请实施例还提供了一种客户机，该客户机包括：

收发装置，用于向服务器发送请求数据包以及握手包，以使所述服务器根据所述握手包的序号以及和请求数据包的确认号、或根据所述请求数据包中包含的客户机的识别信息，确定所述请求数据包来自于匹配的客户机，并建立连接。

进一步地，所述收发装置，还用于在向服务器发送请求数据包以及握手包之后，接收来自所述服务器的握手确认包，以及向所述服务器发送基于所述握手确认包生成的确认包。

进一步地，所述收发装置，还用于在向服务器发送请求数据包以及握手包之前，由内容分发网络节点获取获取客户机的标识信息，其中，所述客户机的标识信息与匹配的服务器的标识信息一致。

本申请实施例提供的另一种服务器包括：

处理器；以及

被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器：在接收到来自客户机的请求数据包以及握手包时，根据所述握手包的序号以及请求数据包的确认号，确定所述请求数据包来自于匹配的客户机；以及建立与所述客户机的连接。

本申请实施例提供的另一种服务器包括：

处理器；以及

被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器：在接收到来自客户机的请求数据包时，根据所述请求数据包中包含的客户机的识别信息，确定所述请求数据包来自于匹配的客户机；以及建立与所述客户机的连接。

本申请实施例提供的另一种客户机包括：

处理器；以及

被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器：向服务器发送请求数据包以及握手包，以使所述服务器根据所述握手包的序号以及和请求数据包的确认号、或根据所述请求数据包中包含的客户机的识别信息，确定所述请求数据包来自于匹配的客户机，并建立连接。

与现有技术相比，本申请提供的方案中，客户机在发起建连请求时，同时发送握手包和请求数据包，其中，所述握手包即为建立普通TCP连接的握手包，所述请求数据包中包含了用于向服务器请求相关数据的数据请求；相应地，服务器在接收到来自客户机的请求数据包以及握手包，或者由于各类原因仅接收到请求数据包时，可以根据这些包所携带的相应内容确定请求数据包来自于匹配的客户机，进而与所述客户机建立连接，由于握手包和请求数据包分别单独发送，无须将数据请求塞入握手包中，因此不会被防火墙丢弃，而造成建连失败。

进一步地，服务器以及客户机的标识信息通过CDN(Content Delivery Network，内容分发网络)节点统一下发，由此来避免客户机需要在初始化时向服务器进行请求的开销，由此进一步节省了整个交互过程的开销。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本申请的其它特征、目的和优点将会变得更明显：

图1为现有技术中普通的TCP连接建立流程；

图2为现有技术中Google TCP Fast Open技术的具体交互流程；

图3为TCP包的结构示意图；

图4(a)为实现本申请实施例提供的方案客户机所进行的相应处理的流程图；

图4(b)为实现本申请实施例提供的方案服务器所进行的相应处理的流程图；

图5为在实际场景下使用本申请实施例提供方法时客户机与服务器之间的交互过程示意图；

附图中相同或相似的附图标记代表相同或相似的部件。

具体实施方式

下面结合附图对本申请作进一步详细描述。

在本申请一个典型的配置中，终端、服务网络的设备和可信方均包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

本申请实施例提供一种建立连接的方法，用于在客户机和服务器之间建立TCP连接。具体地，客户机在主动发起建连请求时，会向服务器发送请求数据包(opt+data包)以及握手包(SYN包)，其中，所述握手包即为建立普通TCP连接的握手包，所述请求数据包中包含了用于向服务器请求相关数据的数据请求。由于握手包和请求数据包分别单独发送，无须将数据请求塞入握手包中，因此不会被防火墙丢弃，而造成建连失败。

相应地，在正常情况下，服务器会接收到来自客户机的请求数据包以及握手包，此时服务器能够根据所述握手包的序号(seq)以及请求数据包的确认号(ackseq)，确定所述请求数据包来自于匹配的客户机，并建立与该客户机的连接。

其中，该opt+data包的TCP首部中加入了一个选项内容，该选项内容即为客户机的key，其填充位置一般在20个字节的固定首部之后。key能够在特定情况下用于客户机和服务器之间的验证，以确定服务器与发送该opt+data包的客户机相互匹配，而数据部分中则包含用于向服务器请求相关数据的数据请求，具体可参考如图3所示的TCP包结构。

在通常情况下，服务器在给出的握手确认包(SYN+ACK包)的序号是随机生成的。按照TCP连接的逻辑，服务器发出的SYN+ACK包的seq需要与客户端最后发送的ACK包的ackseq匹配，由于本申请提供的方案在建立连接时，客户机同时发出两个包，因此请求数据包需要考虑适配TCP连接的这种处理逻辑，以避免建立连接发生异常。

为适配TCP的处理逻辑，本申请实施例中服务端在确定请求数据包是否来自于匹配的客户机时，可以具体采用如下所述的具体处理逻辑，即：首先，根据所述握手包的序号和所述服务器的标识信息(key)设定握手确认包的序号；若所述握手确认包的序号与所述请求数据包的确认号匹配，则确定所述请求数据包来自于匹配的客户机，其中，所述请求数据包的确认号根据所述握手包的序号和所述客户机的标识信息设定，且与确认包的确认号一致。

其实质相当于让opt+data包携带ACK包需要携带的ackseq，提前将ACK包的ackseq告知服务器。由于服务器和客户机的key可以由CDN节点统一下发，使得互信的服务器和客户机的key均相同，从而来避免客户机需要在初始化时向服务器进行请求的开销，由此进一步节省了整个交互过程的开销。由此，服务器和客户机可以在进行建连之前，例如初始化时，由CDN获取到各自的key，对于相互匹配的服务器和客户机，它们的key也相同。

在上述处理过程中，服务器发送的SYN+ACK包的seq是根据ACK包的seq和所述服务器的key而设定，而非随机生成，而所述opt+data包的ackseq则根据所述ACK包的seq和所述客户机的key而设定，只要两者匹配，则可以保证上述TCP的逻辑能够正确，由此保证在客户机发送ACK包之前，就可以正确建立客户机和服务器之间的TCP连接。在顺利建立连接之后，opt+data包携带的数据请求则会被交给上层程序进行处理，并向客户机发送相应的应答数据。

由此，在建立连接的过程中，所述客户机和服务器处理流程分别如图4(a)和图4(b)所示。在客户机端，具体的处理流程包括：

S401a，按照常规的方式生成SYN包。

S402a，根据SYN包的seq和CDN下发的key计算出值x。

S403a，设定opt+data包的ackseq为x+1。

S404a，向服务器发送SYN包和opt+data包。

而在服务器端，具体的处理流程则包括：

S401b，根据CDN下发的key，以及收到的SYN包的seq计算出x。由于key值相同，服务器计算出的x也与客户机计算出的x相同。

S402b，设定向客户机回复的SYN+ACK包的seq为x。

S403b，将计算得到的x与收到的opt+data包的ackseq进行匹配；

S404b，若x+1＝ackseq，则表示两者是匹配的，从而完成握手，顺利建立连接。

在实际场景下，由于TCP连接机制要求对于对端发送的包，必须要有相应的应答，因此，服务器在根据所述握手包的序号和所述服务器的标识信息设定握手确认包的序号之后，还会向所述客户机发送所述握手确认包，以及接收所述客户机基于所述握手确认包发送的确认包。而相应地，所述客户机在向服务器发送请求数据包以及握手包之后，还会接收来自所述服务器的握手确认包，以及向所述服务器发送基于所述握手确认包生成的确认包。

由此，在实际场景下使用本申请实施例提供方法时，客户机与服务器之间的交互过程如图5所示。

首先，客户机发起建连请求，向服务器发送SYN包和opt+data包，其中，SYN包的seq＝n，ackseq＝0；opt+data包的seq＝n+1，ackseq＝x+1。

服务器在收到SYN包和opt+data包之后，进行上述S401b至S404b的处理，建立与客户机之间的连接。对于收到的SYN包，服务器需要返回SYN+ACK包作为应答，该SYN+ACK包的seq＝x，ackseq＝n+1+k，其中，k是指opt+data包的数据部分的长度。而对于opt+data包，会根据其中的数据请求返回相应的应答数据，该过程即为图中的send resp，其相应应答数据包的seq和ackseq均延续自然增长即可。

客户机在收到SYN+ACK包之后，会返回一个ACK包，作为确认。该ACK包的seq＝ackseq＝n+1+k，seq＝x+1。

对于客户机收到的SYN+ACK包，除了是为了符合TCP的交互机制之外，还可以在特定的情况下，完成对异常情况的验证。例如，在实际应用场景中，可能存在以下几种异常情况。

1、服务器端不支持本申请实施例中的方案。即服务器仅支持普通的TCP建连过程，此时服务器基于SYN包所回复的SYN+ACK包的seq是随机的，当客户机接收到SYN+ACK包时，发现其seq不符合预期，就可以确定无法采用本申请的方案来建立连接，此时，退回到普通方式来建立连接，以及发送数据请求。

2、服务器端支持本申请实施例中的方案，但是仅收到了opt+data包。此时由于未收到SYN包，服务器将直接判断opt+data包中的选项内容(即key)，若key符合预期(例如与服务器自身的key相同)，则直接建立连接。

基于此种情况，本申请实施例还提供了另一种建立连接的方法，在服务器端，在接收到来自客户机的请求数据包时，根据所述请求数据包中包含的客户机的识别信息，确定所述请求数据包来自于匹配的客户机。

其中，确定所述请求数据包来自于匹配的客户机的具体过程为：若所述请求数据包中包含的客户机的识别信息与服务器的识别信息一致，则确定所述请求数据包来自于匹配的客户机。

3、服务器端支持本申请实施例中的方案，但是仅收到了SYN包，而未收到opt+data包。此时，无需让客户机重新发送opt+data包，只需要直接退回到普通的TCP建连流程，再次发送数据请求即可。

4、服务器端支持本申请实施例中的方案，未收到SYN包和opt+data包。由于SYN包和opt+data包均丢失，这种情况说明网络状况不佳，直接启动SYN包重传即可。

基于同一发明构思，本申请实施例中还提供了相应的服务器和客户机，所述服务器和客户机对应的方法是前述实施例中的建立连接的方法，并且其解决问题的原理与所述方法相似。

具体地，所述客户机至少包括一收发装置，在发起建连请求时，该收发装置用于向服务器发送请求数据包(opt+data包)以及握手包(SYN包)，其中，所述握手包即为建立普通TCP连接的握手包，所述请求数据包中包含了用于向服务器请求相关数据的数据请求。由于握手包和请求数据包分别单独发送，无须将数据请求塞入握手包中，因此不会被防火墙丢弃，而造成建连失败。

相应地，所述服务器至少包括处理装置和连接建立装置。在正常情况下，服务器会接收到来自客户机的请求数据包以及握手包，此时处理装置能够根据所述握手包的序号(seq)以及请求数据包的确认号(ackseq)，确定所述请求数据包来自于匹配的客户机，而所述连接建立装置会建立与该客户机的连接。

其中，该opt+data包的TCP首部中加入了一个选项内容，该选项内容即为客户机的key，其填充位置一般在20个字节的固定首部之后。key能够在特定情况下用于客户机和服务器之间的验证，以确定服务器与发送该opt+data包的客户机相互匹配，而数据部分中则包含用于向服务器请求相关数据的数据请求，具体可参考如图3所示的TCP包结构。

在通常情况下，服务器在给出的握手确认包(SYN+ACK包)的序号是随机生成的。按照TCP连接的逻辑，服务器发出的SYN+ACK包的seq需要与客户端最后发送的ACK包的ackseq匹配，由于本申请提供的方案在建立连接时，客户机同时发出两个包，因此请求数据包需要考虑适配TCP连接的这种处理逻辑，以避免建立连接发生异常。

为适配TCP的处理逻辑，本申请实施例中服务端在确定请求数据包是否来自于匹配的客户机时，所述处理装置可以具体采用如下所述的处理逻辑，即：首先，根据所述握手包的序号和所述服务器的标识信息(key)设定握手确认包的序号；若所述握手确认包的序号与所述请求数据包的确认号匹配，则确定所述请求数据包来自于匹配的客户机，其中，所述请求数据包的确认号根据所述握手包的序号和所述客户机的标识信息设定，且与确认包的确认号一致。

其实质相当于让opt+data包携带ACK包需要携带的ackseq，提前将ACK包的ackseq告知服务器。由于服务器和客户机的key可以由CDN节点统一下发，使得互信的服务器和客户机的key均相同，从而来避免客户机需要在初始化时向服务器进行请求的开销，由此进一步节省了整个交互过程的开销。由此，服务器和客户机的收发装置可以在进行建连之前，例如初始化时，由CDN获取到各自的key，对于相互匹配的服务器和客户机，它们的key也相同。

在上述处理过程中，服务器发送的SYN+ACK包的seq是根据ACK包的seq和所述服务器的key而设定，而非随机生成，而所述opt+data包的ackseq则根据所述ACK包的seq和所述客户机的key而设定，只要两者匹配，则可以保证上述TCP的逻辑能够正确，由此保证在客户机发送ACK包之前，就可以正确建立客户机和服务器之间的TCP连接。在顺利建立连接之后，opt+data包携带的数据请求则会被交给上层程序进行处理，并向客户机发送相应的应答数据。

在实际场景下，由于TCP连接机制要求对于对端发送的包，必须要有相应的应答，因此，服务器的收发装置在根据所述握手包的序号和所述服务器的标识信息设定握手确认包的序号之后，还会向所述客户机发送所述握手确认包，以及接收所述客户机基于所述握手确认包发送的确认包。而相应地，所述客户机的收发装置在向服务器发送请求数据包以及握手包之后，还会接收来自所述服务器的握手确认包，以及向所述服务器发送基于所述握手确认包生成的确认包。

由此，在实际场景下使用本申请实施例提供方法时，客户机与服务器之间的交互过程如图5所示。

首先，客户机发起建连请求，向服务器发送SYN包和opt+data包，其中，SYN包的seq＝n，ackseq＝0；opt+data包的seq＝n+1，ackseq＝x+1。

服务器在收到SYN包和opt+data包之后，进行上述S401b至S403b的处理，建立与客户机之间的连接。对于收到的SYN包，服务器需要返回SYN+ACK包作为应答，该SYN+ACK包的seq＝x，ackseq＝n+1+k，其中，k是指opt+data包的数据部分的长度。而对于opt+data包，会根据其中的数据请求返回相应的应答数据，该过程即为图中的send resp，其相应应答数据包的seq和ackseq均延续自然增长即可。

客户机在收到SYN+ACK包之后，会返回一个ACK包，作为确认。该ACK包的seq＝ackseq＝n+1+k，seq＝x+1。

对于客户机收到的SYN+ACK包，除了是为了符合TCP的交互机制之外，还可以在特定的情况下，完成对异常情况的验证。例如，在实际应用场景中，可能存在以下几种异常情况。

1、服务器端不支持本申请实施例中的方案。即服务器仅支持普通的TCP建连过程，此时服务器基于SYN包所回复的SYN+ACK包的seq是随机的，当客户机接收到SYN+ACK包时，发现其seq不符合预期，就可以确定无法采用本申请的方案来建立连接，此时，退回到普通方式来建立连接，以及发送数据请求。

2、服务器端支持本申请实施例中的方案，但是仅收到了opt+data包。此时由于未收到SYN包，服务器将直接判断opt+data包中的选项内容(即key)，若key符合预期(例如与服务器自身的key相同)，则直接建立连接。

基于此种情况，本申请实施例提供的服务器的处理装置，还可以用于在接收到来自客户机的请求数据包时，根据所述请求数据包中包含的客户机的识别信息，确定所述请求数据包来自于匹配的客户机。

其中，处理装置确定所述请求数据包来自于匹配的客户机的具体过程为：若所述请求数据包中包含的客户机的识别信息与服务器的识别信息一致，则确定所述请求数据包来自于匹配的客户机。

3、服务器端支持本申请实施例中的方案，但是仅收到了SYN包，而未收到opt+data包。此时，无需让客户机重新发送opt+data包，只需要直接退回到普通的TCP建连流程，再次发送数据请求即可。

4、服务器端支持本申请实施例中的方案，未收到SYN包和opt+data包。由于SYN包和opt+data包均丢失，这种情况说明网络状况不佳，直接启动SYN包重传即可。

作为另一种可行的实施方式，本申请实施例还提供了一种服务器，其中，该服务器包括：

处理器；以及

被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器：在接收到来自客户机的请求数据包以及握手包时，根据所述握手包的序号以及请求数据包的确认号，确定所述请求数据包来自于匹配的客户机；以及建立与所述客户机的连接。

此外，本申请提供的另一种服务器包括：

处理器；以及

被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器：在接收到来自客户机的请求数据包时，根据所述请求数据包中包含的客户机的识别信息，确定所述请求数据包来自于匹配的客户机；以及建立与所述客户机的连接。

本申请实施例提供的另一种客户机，处理器；以及

被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器：向服务器发送请求数据包以及握手包，以使所述服务器根据所述握手包的序号以及和请求数据包的确认号、或根据所述请求数据包中包含的客户机的识别信息，确定所述请求数据包来自于匹配的客户机，并建立连接。

综上所述，本申请提供的方案中，客户机在发起建连请求时，同时发送握手包和请求数据包，其中，所述握手包即为建立普通TCP连接的握手包，所述请求数据包中包含了用于向服务器请求相关数据的数据请求；相应地，服务器在接收到来自客户机的请求数据包以及握手包，或者由于各类原因仅接收到请求数据包时，可以根据这些包所携带的相应内容确定请求数据包来自于匹配的客户机，进而与所述客户机建立连接，由于握手包和请求数据包分别单独发送，无须将数据请求塞入握手包中，因此不会被防火墙丢弃，而造成建连失败。

需要注意的是，本申请可在软件和/或软件与硬件的组合体中被实施，例如，可采用专用集成电路(ASIC)、通用目的计算机或任何其他类似硬件设备来实现。在一个实施例中，本申请的软件程序可以通过处理器执行以实现上文所述步骤或功能。同样地，本申请的软件程序(包括相关的数据结构)可以被存储到计算机可读记录介质中，例如，RAM存储器，磁或光驱动器或软磁盘及类似设备。另外，本申请的一些步骤或功能可采用硬件来实现，例如，作为与处理器配合从而执行各个步骤或功能的电路。

另外，本申请的一部分可被应用为计算机程序产品，例如计算机程序指令，当其被计算机执行时，通过该计算机的操作，可以调用或提供根据本申请的方法和/或技术方案。而调用本申请的方法的程序指令，可能被存储在固定的或可移动的记录介质中，和/或通过广播或其他信号承载媒体中的数据流而被传输，和/或被存储在根据所述程序指令运行的计算机设备的工作存储器中。在此，根据本申请的一个实施例包括一个装置，该装置包括用于存储计算机程序指令的存储器和用于执行程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发该装置运行基于前述根据本申请的多个实施例的方法和/或技术方案。

对于本领域技术人员而言，显然本申请不限于上述示范性实施例的细节，而且在不背离本申请的精神或基本特征的情况下，能够以其他的具体形式实现本申请。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本申请的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本申请内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外，显然“包括”一词不排除其他单元或步骤，单数不排除复数。装置权利要求中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。

Claims (21)

1.一种在服务器端建立连接的方法，其中，该方法包括：

在接收到来自客户机的请求数据包以及握手包时，根据所述握手包的序号以及请求数据包的确认号，确定所述请求数据包来自于匹配的客户机；

建立与所述客户机的连接。

2.根据权利要求1所述的方法，其中，根据所述握手包的序号以及请求数据包的确认号，确定所述请求数据包来自于匹配的客户机，包括：

根据所述握手包的序号和所述服务器的标识信息设定握手确认包的序号；

若所述握手确认包的序号与所述请求数据包的确认号匹配，则确定所述请求数据包来自于匹配的客户机，其中，所述请求数据包的确认号根据所述握手包的序号和所述客户机的标识信息设定，且与确认包的确认号一致。

3.根据权利要求2所述的方法，其中，根据所述握手包的序号和所述服务器的标识信息设定握手确认包的序号之后，还包括：

向所述客户机发送所述握手确认包，以及接收所述客户机基于所述握手确认包发送的确认包。

4.一种在服务器端处理数据请求的方法，其中，该方法包括：

在接收到来自客户机的请求数据包时，根据所述请求数据包中包含的客户机的识别信息，确定所述请求数据包来自于匹配的客户机；

建立与所述客户机的连接。

5.根据权利要求4所述的方法，其中，根据所述请求数据包中包含的客户机的识别信息，确定所述请求数据包来自于匹配的客户机，包括：

若所述请求数据包中包含的客户机的识别信息与服务器的识别信息一致，则确定所述请求数据包来自于匹配的客户机。

6.根据权利要求2至5中任一项所述的方法，其中，在确定所述请求数据包来自于匹配的客户机之前，还包括：

由内容分发网络节点获取服务器的标识信息，其中，所述服务器的标识信息与匹配的客户机的标识信息一致。

7.一种在客户机端建立连接的方法，其中，该方法包括：

向服务器发送请求数据包以及握手包，以使所述服务器根据所述握手包的序号以及和请求数据包的确认号、或根据所述请求数据包中包含的客户机的识别信息，确定所述请求数据包来自于匹配的客户机，并建立连接。

8.根据权利要求7所述的方法，其中，向服务器发送请求数据包以及握手包之后，还包括：

接收来自所述服务器的握手确认包，以及向所述服务器发送基于所述握手确认包生成的确认包。

9.根据权利要求7或8所述的方法，其中，在向服务器发送请求数据包以及握手包之前，还包括：

由内容分发网络节点获取获取客户机的标识信息，其中，所述客户机的标识信息与匹配的服务器的标识信息一致。

10.一种服务器，其中，该服务器包括：

处理装置，用于在接收到来自客户机的请求数据包以及握手包时，根据所述握手包的序号以及请求数据包的确认号，确定所述请求数据包来自于匹配的客户机；

连接建立装置，用于建立与所述客户机的连接。

11.根据权利要求10所述的服务器，其中，所述处理装置用于根据所述握手包的序号和所述服务器的标识信息设定握手确认包的序号；以及在所述握手确认包的序号与所述请求数据包的确认号匹配时，确定所述请求数据包来自于匹配的客户机，其中，所述请求数据包的确认号根据所述握手包的序号和所述客户机的标识信息设定，且与确认包的确认号一致。

12.根据权利要求11所述的服务器，其中，该服务器还包括

收发装置，用于在根据所述握手包的序号和所述服务器的标识信息设定握手确认包的序号之后，向所述客户机发送所述握手确认包，以及接收所述客户机基于所述握手确认包发送的确认包。

13.一种服务器，其中，该服务器包括：

处理装置，用于在接收到来自客户机的请求数据包时，根据所述请求数据包中包含的客户机的识别信息，确定所述请求数据包来自于匹配的客户机；

连接建立装置，用于建立与所述客户机的连接。

14.根据权利要求13所述的服务器，其中，所述处理装置用于在所述请求数据包中包含的客户机的识别信息与服务器的识别信息一致时，确定所述请求数据包来自于匹配的客户机。

15.根据权利要求11至14中任一项所述的服务器，其中，所述收发装置，还用于在确定所述请求数据包来自于匹配的客户机之前，由内容分发网络节点获取服务器的标识信息，其中，所述服务器的标识信息与匹配的客户机的标识信息一致。

16.一种客户机，其中，该客户机包括：

收发装置，用于向服务器发送请求数据包以及握手包，以使所述服务器根据所述握手包的序号以及和请求数据包的确认号、或根据所述请求数据包中包含的客户机的识别信息，确定所述请求数据包来自于匹配的客户机，并建立连接。

17.根据权利要求16所述的客户机，其中，所述收发装置，还用于在向服务器发送请求数据包以及握手包之后，接收来自所述服务器的握手确认包，以及向所述服务器发送基于所述握手确认包生成的确认包。

18.根据权利要求16或17所述的客户机，其中，所述收发装置，还用于在向服务器发送请求数据包以及握手包之前，由内容分发网络节点获取获取客户机的标识信息，其中，所述客户机的标识信息与匹配的服务器的标识信息一致。

19.一种服务器，其中，该服务器包括：

处理器；以及

被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器：在接收到来自客户机的请求数据包以及握手包时，根据所述握手包的序号以及请求数据包的确认号，确定所述请求数据包来自于匹配的客户机；以及建立与所述客户机的连接。

20.一种服务器，其中，该服务器包括：

处理器；以及

被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器：在接收到来自客户机的请求数据包时，根据所述请求数据包中包含的客户机的识别信息，确定所述请求数据包来自于匹配的客户机；以及建立与所述客户机的连接。

21.一种客户机，其中，该客户机包括：

处理器；以及

被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器：向服务器发送请求数据包以及握手包，以使所述服务器根据所述握手包的序号以及和请求数据包的确认号、或根据所述请求数据包中包含的客户机的识别信息，确定所述请求数据包来自于匹配的客户机，并建立连接。