一种通信方法、客户端及通信系统与流程

本申请涉及但不限于通信技术，尤其涉及一种通信方法、客户端及通信系统。

背景技术：

图1为标准的传输控制协议(tcp，transmissioncontrolprotocol)规定的tcp连接建立过程的三次握手交互示意图。如图1所示，tcp的三次握手流程包括：

第一次握手：客户端(client)发送一个同步(syn，synchronous)包，该syn包中syn标志位置为1，且序号(sequencenumber，以下简称为seq)可以为m，客户端进入syn_send状态；其中，m值可以随机确定；

第二次握手：服务端(server)在收到客户端的syn包后，根据syn标志位为1可知客户端请求建立连接，服务端向客户端反馈synack(同步确认)包，表明客户端的请求被接受；服务端在synack包中，将syn标志位和ack标志位都置为1，序号seq设为n，确认序号(acknumber)设为m+1，即确认序号等于客户端发送的syn包的序号加1；服务端进入syn_recv状态；其中，n值也可以随机确定；

第三次握手：客户端收到服务端返回的synack包后，在检查到synack包中ack标志位为1，且确认序号为m+1时，则返回一个确认(ack)包给服务端，在该ack包中，将ack标志位设为1，确认序号设为n+1；服务端接收到该ack包之后，在检查到ack包中ack标志位为1，且确认序号为n+1时，则说明客户端与服务端之间的tcp连接建立成功，客户端和服务端进入established(连接建立)状态。

通过三次握手，客户端和服务端之间成功建立tcp连接后，客户端和服务端之间可以基于建立的tcp连接进行数据传输。

根据图1可知，在标准tcp中，三次握手会浪费一个rtt(往返时延，round-triptime)。

tfo(tcpfastopen)是由google发布的一种对tcp(transmissioncontrolprotocol，传输控制协议)的扩展。tfo允许在tcp三次握手期间进行数据交换，从而节约一次rtt时间。

图2为tfo的交互流程图。如图2所示，tfo的交互流程包括：

第一步、客户端发送一个带有业务数据的syn包(即，tfo的syn包)，而且可以在fastopen选项中携带之前通过正常连接获取的cookie(即，foc(fastopencookie))；

第二步、服务端接收syn包后，验证其中携带的cookie；如果该cookie有效，则服务端返回synack包，并将syn包携带的业务数据传递给应用层；如果该cookie无效，则服务端可以丢掉syn包中的业务数据，同时向客户端返回一个synack包来确认syn包中的序号；

第三步、当cookie有效时，在连接完成之前，服务端可以给客户端发送响应数据；

第四步、客户端收到synack包后，发送ack包来确认服务端的synack包和数据；若客户端在第一步中发送的syn包中的业务数据没有被服务器确认，则客户端可以在这个ack包中重传对应的业务数据。

tfo过程的其余连接处理类似标准的tcp连接过程。需要说明的是，客户端一旦获取到foc，可以重复tfo过程直到cookie过期。在使用tfo之前，客户端可以通过一个普通的三次握手连接获取foc。例如，客户端发送一个带有fastopen选项的syn包，同时携带一个空的cookie域来请求一个cookie；服务端产生一个cookie，然后通过一个synack包的fastopen选项来返回给客户端；客户端缓存这个cookie以备后续使用tfo时使用。

然而，在互联网环境下，由于互联网上路由设备和运营商网间设备的限制，导致tfo在部分网络环境下失效退化为标准tcp，具体而言，如果中间设备不支持tfo，就会导致tfo超时退化为标准的tcp连接，从而使得整体上的连接速度甚至低于标准的tcp连接速度。

技术实现要素：

以下是对本文详细描述的主题的概述。本概述并非是为了限制权利要求的保护范围。

本申请实施例提供一种通信方法、客户端及通信系统，能够保障在tfo不可用场景下的通信性能。

第一方面，本申请实施例提供一种通信方法，包括：

客户端在与服务端建立tcp连接时，发送tfo的syn包，并在发送所述tfo的syn包之后并且所述tfo的syn包超时之前发送标准syn包。

在示例性实施方式中，所述tfo的syn包的发送时刻与所述标准syn包的发送时刻之间的间隔时长可以大于或等于0且小于或等于20毫秒。

在示例性实施方式中，所述发送tfo的syn包和标准syn包之后，上述方法还可以包括：

所述客户端接收ack包；根据所述ack包，判断tfo是否失败。

在示例性实施方式中，所述根据所述ack包，判断tfo是否失败，可以包括：

在所述ack包携带的确认序号等于tfo的syn包的序号和所述syn包携带的数据长度之和加1时，确认tfo成功；

在所述ack包携带的确认序号等于标准syn包的序号加1时，确认tfo失败。

第二方面，本申请实施例提供一种客户端，包括：

发送模块，适于在与服务端建立tcp连接时，发送tfo的syn包，并在发送所述tfo的syn包之后且所述tfo的syn包超时之前发送标准syn包。

在示例性实施方式中，所述tfo的syn包的发送时刻与所述标准syn包的发送时刻之间的间隔时长可以大于或等于0且小于或等于20毫秒。

在示例性实施方式中，所述客户端还可以包括：

接收模块，适于接收ack包；

处理模块，适于根据所述ack包，判断tfo是否失败。

在示例性实施方式中，所述处理模块可以适于通过以下方式判断tfo是否失败：

在所述ack包携带的确认序号等于tfo的syn包的序号和所述syn包携带的数据长度之和加1时，确认tfo成功；

在所述ack包携带的确认序号等于标准syn包的序号加1时，确认tfo失败。

第三方面，本申请实施例提供一种通信系统，包括：客户端、服务端以及中间设备；

所述客户端适于在通过所述中间设备与所述服务端建立tcp连接时，发送tfo的syn包，并在发送所述tfo的syn包之后且所述tfo的syn包超时之前发送标准syn包；

所述中间设备适于在自身支持tfo时，将所述tfo的syn包发送给所述服务端，并丢弃所述标准syn包；在自身不支持tfo时，将所述标准syn包发送给所述服务端，并丢弃所述tfo的syn包。

在示例性实施方式中，在所述中间设备支持tfo时，所述服务端接收到所述tfo的syn包后，返回的ack包携带的确认序号等于所述tfo的syn包的序号和所述syn包携带的数据长度之和加1；在所述中间设备不支持tfo时，所述服务端接收到所述标准syn包后，返回的ack包携带的确认序号等于所述标准syn包的序号加1。

第四方面，本申请实施例提供一种终端设备，包括：存储器以及处理器；其中，所述存储器用于存储通信程序，所述通信程序被所述处理器读取执行时，执行以下操作：在与服务端建立tcp连接时，发送tfo的syn包，并在发送所述tfo的syn包之后且所述tfo的syn包超时之前发送标准syn包。

此外，本申请实施例还提供一种计算机可读介质，存储有通信程序，所述通信程序被处理器执行时实现以下操作：在与服务端建立tcp连接时，发送tfo的syn包，并在发送所述tfo的syn包之后且所述tfo的syn包超时之前发送标准syn包。

在本申请实施例中，客户端在与服务端建立tcp连接时，发送tfo的syn包，并在发送tfo的syn包之后且tfo的syn包超时之前发送标准syn包；如此，通过多发送一个标准syn包来发现tfo是否失败，从而保证在tfo不可用场景下的通信性能。

附图说明

图1为标准tcp规定的tcp连接建立过程的三次握手交互流程图；

图2为tfo的交互流程图；

图3为本申请实施例提供的通信系统的一种交互流程图；

图4为本申请实施例提供的通信系统的另一种交互流程图；

图5为本申请实施例提供的通信方法的流程图；

图6为本申请实施例提供的客户端的示意图。

具体实施方式

以下结合附图对本申请实施例进行详细说明，应当理解，以下所说明的实施例仅用于说明和解释本申请，并不用于限定本申请。

需要说明的是，如果不冲突，本申请实施例以及实施例中的各个特征可以相互结合，均在本申请的保护范围之内。另外，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

一些实施方式中，执行通信方法的计算设备可包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存(memory)。

内存可能包括计算机可读介质中的非永久性存储器、随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。内存可能包括模块1，模块2，……，模块n(n为大于2的整数)。

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

下面先对本申请涉及的标准同步(sny，synchronous)包和tfo的syn包携带的信息进行说明。需要说明的是，此处仅对本申请涉及的信息进行说明。

相较于标准sny包，tfo的syn包还可以携带业务数据(data)和foc(fastopencookie)。标准sny包和tfo的syn包都包括sny标志位、确认(ack)标志位、序号(sequencenumber)字段以及确认序号(acknumber)字段。其中，syn标志位为1时表示发起一个新连接；序号字段占32位，其中携带序号，用来标识从tcp源端向目的端发送的字节流，发起方发送数据时对此进行标记；确认序号字段占32位，其中携带确认序号，只有ack标志位为1时，确认序号字段才有效。

图3和图4为本申请实施例提供的通信系统的交互流程图。本实施例提供的通信系统包括：客户端、中间设备以及服务端。

在互联网环境下，由于互联网上路由设备和运营商的网间设备(即客户端和服务端之间的中间设备)的限制，这些设备存在不支持tfo的情况，这会导致tfo的性能低于标准tcp的握手性能。

本实施例中，客户端在通过中间设备与服务端建立tcp连接时，发送tfo的syn包，并在发送tfo的syn包之后且tfo的syn包超时之前发送标准syn包。

其中，tfo的syn包超时表示发送tfo的syn包后的设定时长内没有收到针对syn包的回应。

其中，tfo的syn包和标准syn包可以同时发送；或者，优先发送tfo的syn包，且tfo的syn包的发送时刻与标准syn包的发送时刻之间的间隔时长小于上述设定时长。比如，tfo的syn包的发送时刻与标准syn包的发送时刻之间的间隔时长可以小于或等于100ms，示例性地，两者的发送时刻之间的间隔时长可以为大于或等于0且小于或等于20ms。然而，本申请对此并不限定。在实际应用中，可以根据客户端所处的网络环境确定两者的发送时刻之间的间隔时长。

其中，中间设备适于在自身支持tfo时，将tfo的syn包发送给服务端，并丢弃标准syn包；在自身不支持tfo时，将标准syn包发送给服务端，并丢弃tfo的syn包。

示例性地，在客户端同时发送tfo的syn包和标准syn包时，若中间设备支持tfo，则中间设备可以转发tfo的syn包给服务端，而丢弃标准syn包，若中间设备不支持tfo，则中间设备可以转发标准syn包给服务端，而丢弃tfo的syn包。

示例性地，在中间设备支持tfo时，服务端接收到tfo的syn包后，返回的ack包携带的确认序号等于tfo的syn包的序号和该syn包携带的数据长度之和加1；在中间设备不支持tfo时，服务端接收到标准syn包后，返回的ack包携带的确认序号等于标准syn包的序号加1。

如图3所示，在中间设备支持tfo时，中间设备接收到tfo的syn包后，会转发给服务端，服务端会优先收到tfo的syn包，从而完成tfo的tcp连接建立；中间设备会因为连接已经建立而丢弃后面收到的标准syn包。图3中服务端和客户端之间完成tfo的tcp连接建立过程的其他说明可以参照图2所示的描述，故于此不再赘述。

如图4所示，在中间设备不支持tfo时，中间设备会丢弃收到的tfo的syn包，则服务端只会收到标准syn包，从而完成正常的tcp连接建立。图4中服务端和客户端之间完成tcp连接建立过程的其他说明可以参照图1所示的描述，故于此不再赘述。

本实施例中，鉴于syn包只有40字节(20字节ip+20字节tcp)，即使在连接建立时多发送一个40字节的数据包对于网络的影响也非常少，因此，通过多发送一个标准syn包来发现tfo是否失败，从而保证tfo不可用场景下的通信性能。

图5为本申请实施例提供的通信方法的流程图。如图5所示，本实施例提供的通信方法，包括：

s501、客户端在与服务端建立tcp连接时，发送tfo的syn包；其中，tfo的syn包携带业务数据；

s502、客户端在发送tfo的syn包之后且tfo的syn包超时之前发送标准syn包。

在示例性实施方式中，tfo的syn包和标准syn包可以同时发送；或者，优先发送tfo的syn包，且tfo的syn包的发送时刻与标准syn包的发送时刻之间的间隔时长小于tfo的syn包超时的设定时长。示例性地，间隔时长可以大于或等于0且小于或等于100ms，比如间隔时长的范围为0至20ms。

在本实施例中，在s502之后，本实施例的通信方法还可以包括：

s503、客户端接收服务端返回的ack包，并判断tfo是否失败；

其中，在该ack包携带的确认序号等于tfo的syn包的序号和该syn包携带的数据长度之和加1时，确认tfo成功；

在该ack包携带的确认序号等于标准syn包的序号加1时，确认tfo失败。

本实施例中，根据ack包携带的确认序号，识别服务端返回的ack包是针对哪个syn包的响应，通过确定服务端是否处理了tfo的syn包携带的业务数据，来判断tfo是否成功。在服务端处理了tfo的syn包携带的业务数据时，则表明tfo成功，反之，则表明tfo失败。

在本实施例中，在客户端确认tfo成功之后，客户端采用常规tcp数据传输流程进行数据传输；在客户端确认tfo失败而标准tcp成功之后，也可以采用常规tcp数据传输流程进行数据传输。相较于tfo成功的情况，客户端在tfo失败时，还需要重传tfo的syn包携带的业务数据。

图6为本申请实施例提供的客户端的示意图。如图6所示，本实施例提供的客户端，包括：

发送模块601，适于在与服务端建立tcp连接时，发送tfo的syn包，并在发送tfo的syn包之后且tfo的syn包超时之前发送标准syn包。

示例性地，tfo的syn包的发送时刻与标准syn包的发送时刻之间的间隔时长可以小于或等于100ms，比如间隔时长的范围为0至20ms。

其中，本实施例的客户端还可以包括：

接收模块602，适于接收ack包；

处理模块603，适于根据ack包，判断tfo是否失败。

其中，处理模块603可以适于通过以下方式判断tfo是否失败：

在ack包携带的确认序号等于tfo的syn包的序号和该syn包携带的数据长度之和加1时，确认tfo成功；在ack包携带的确认序号等于标准syn包的序号加1时，确认tfo失败。

关于本实施例提供的客户端的相关处理说明可以参照上述通信系统和通信方法的描述，故于此不再赘述。

本申请实施例还提供一种终端设备，包括：存储器以及处理器，存储器上用于存储通信程序；该通信程序在被处理器读取执行时，执行本实施例提供的通信方法的步骤。

其中，处理器可以包括但不限于微处理器(mcu，microcontrollerunit)或可编程逻辑器件(fpga，field-programmablegatearray)等的处理装置。存储器可用于存储应用软件的软件程序以及模块，如本实施例中的通信方法对应的程序指令或模块，处理器通过运行存储在存储器内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的通信方法。存储器可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器可进一步包括相对于处理器远程设置的存储器，这些远程存储器可以通过网络连接至上述终端设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

其中，上述终端设备还可以包括：通信单元，可以经由一个网络接收或者发送数据。在一个实例中，通信单元可以为射频(radiofrequency，简称为rf)模块，其用于通过无线方式与互联网进行通信。

此外，本申请实施例还提供一种计算机可读介质，存储有通信程序，该通信程序被处理器执行时实现上述通信方法的步骤。

本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统、装置中的功能模块/单元可以被实施为软件、固件、硬件及其适当的组合。在硬件实施方式中，在以上描述中提及的功能模块/单元之间的划分不一定对应于物理组件的划分；例如，一个物理组件可以具有多个功能，或者一个功能或步骤可以由若干物理组件合作执行。某些组件或所有组件可以被实施为由处理器，如数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在机器可读介质(比如，计算机可读介质)上，计算机可读介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于ram、rom、eeprom、闪存或其他存储器技术、cd-rom、数字多功能盘(dvd)或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外，本领域普通技术人员公知的是，通信介质通常包含计算机可读指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据，并且可包括任何信息递送介质。

以上显示和描述了本申请的基本原理和主要特征和本申请的优点。本申请不受上述实施例的限制，上述实施例和说明书中描述的只是说明本申请的原理，在不脱离本申请精神和范围的前提下，本申请还会有各种变化和改进，这些变化和改进都落入要求保护的本申请范围内。