CN114979172A - 数据传输方法、装置、设备以及存储介质 - Google Patents

数据传输方法、装置、设备以及存储介质 Download PDF

Info

Publication number
CN114979172A
CN114979172A CN202110204458.9A CN202110204458A CN114979172A CN 114979172 A CN114979172 A CN 114979172A CN 202110204458 A CN202110204458 A CN 202110204458A CN 114979172 A CN114979172 A CN 114979172A
Authority
CN
China
Prior art keywords
data transmission
window
scaling factor
message
response
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202110204458.9A
Other languages
English (en)
Other versions
CN114979172B (zh
Inventor
李弘博
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tencent Technology Shenzhen Co Ltd
Original Assignee
Tencent Technology Shenzhen Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tencent Technology Shenzhen Co Ltd filed Critical Tencent Technology Shenzhen Co Ltd
Priority to CN202110204458.9A priority Critical patent/CN114979172B/zh
Publication of CN114979172A publication Critical patent/CN114979172A/zh
Application granted granted Critical
Publication of CN114979172B publication Critical patent/CN114979172B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1095Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607Details of the supervisory signal
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/12Applying verification of the received information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/14Session management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/163In-band adaptation of TCP data exchange; In-band control procedures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22Parsing or analysis of headers

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本申请实施例公开了一种数据传输方法、装置、设备以及存储介质,可适用于计算机技术、大数据以及区块链等领域。该方法包括:响应于第一设备发送的连接请求报文,确定数据传输窗口的窗口缩放因子;基于连接请求报文和窗口缩放因子,向第一设备发送第一响应报文;响应于第一设备针对第一响应报文的第二响应报文,基于第二响应报文确定窗口缩放因子,基于窗口缩放因子确定数据传输窗口,并基于数据传输窗口与第一设备进行数据传输。采用本申请实施例,可提升数据传输效率,适用性高。

Description

数据传输方法、装置、设备以及存储介质
技术领域
本申请涉及计算机技术领域,尤其涉及一种数据传输方法、装置、设备以及存储介质。
背景技术
传输控制协议(Transmission Control Protocol,TCP)是为了在不可靠的互联网络上提供可靠的端到端字节流而专门设计的一个传输协议。TCP通信时需要先进行三次握手,建立TCP连接以后才可以发送数据包。TCP SYN Flood攻击是一种典型的拒绝服务(Denial of Service,DoS)攻击。TCP服务端会为每一个TCP同步(Synchronize,SYN)请求分配一定的内存资源,SYN Flood攻击在短时间内伪造大量的连接请求发给服务端,服务端将为这些伪造的连接请求分配大量资源,从而将服务端的资源耗尽,导致服务端系统运行缓慢或宕机。
为解决上述问题,通常会引入TCP syn-cookie(同步请求对应的cookie数据)来防范SYN Flood攻击。如图1所示,图1是现有技术中基于syn-cookie的三次握手机制的一示意图。服务端收到客户端的SYN连接请求后,通过计算同步请求对应的cookie数据(syn-cookie)并将其作为同步-确认(Synchronize-acknowledgment,SYN-ACK)应答的序列号(sequence)返回给客户端,客户端返回的三次握手最后一个ACK应答的确认序号(ack_sequence)是基于syn-cookie所确定的(ack_sequence=syn-cookie+1),进而服务端对客户端返回的syn-cookie做合法性校验,如果合法则认为这是一个正常的连接,从而建立TCP连接以进行数据传输。
但是在上述方法中,服务端在接收ACK应答之后会计算数据传输窗口的大小,而客户端则是基于SYN-ACK应答确定数据传输窗口的大小,从而会导致二者确定出的数据传输窗口不一致,进而降低客户端与服务端之间的数据传输效率,适用性差。
发明内容
本申请实施例提供一种数据传输方法、装置、设备以及存储介质,可提升数据传输效率,适用性高。
一方面,本申请实施例提供一种数据传输方法,该方法包括:
响应于第一设备发送的连接请求报文,确定数据传输窗口的窗口缩放因子;
基于上述连接请求报文和上述窗口缩放因子,向上述第一设备发送第一响应报文;
响应于上述第一设备针对上述第一响应报文的第二响应报文,基于上述第二响应报文确定上述窗口缩放因子;
基于上述窗口缩放因子确定上述数据传输窗口,并基于上述数据传输窗口与上述第一设备进行数据传输。
另一方面,本申请实施例提供一种数据传输方法,该方法包括:
向第二设备发送连接请求报文;
响应于上述第二设备针对上述连接请求报文的第一响应报文,基于上述第一响应报文确定数据传输窗口的窗口缩放因子,上述第一响应报文是上述第二设备基于上述连接请求报文和上述窗口缩放因子确定的;
向上述第二设备发送针对上述第一响应报文的第二响应报文,以使上述第二设备基于上述第二响应报文确定上述窗口缩放因子并基于上述窗口缩放因子确定上述数据传输窗口;
基于上述窗口缩放因子确定上述数据传输窗口,基于上述数据传输窗口与上述第二设备进行数据传输。
另一方面,本申请实施例提供了一种数据传输装置,该数据传输装置包括:
第一报文响应模块,用于响应于第一设备发送的连接请求报文,确定数据传输窗口的窗口缩放因子;
第一报文发送模块,用于基于上述连接请求报文和上述窗口缩放因子,向上述第一设备发送第一响应报文;
第二报文响应模块,用于响应于上述第一设备针对上述第一响应报文的第二响应报文,基于上述第二响应报文确定上述窗口缩放因子;
第一数据传输模块,用于基于上述窗口缩放因子确定上述数据传输窗口,并基于上述数据传输窗口与上述第一设备进行数据传输。
另一方面,本申请实施例提供了一种数据传输装置,该数据传输装置包括:
第二报文发送模块,用于向第二设备发送连接请求报文;
第三报文响应模块,用于响应于上述第二设备针对上述连接请求报文的第一响应报文,基于上述第一响应报文确定数据传输窗口的窗口缩放因子,上述第一响应报文是上述第二设备基于上述连接请求报文和上述窗口缩放因子确定的;
第三报文发送模块,用于向上述第二设备发送针对上述第一响应报文的第二响应报文,以使上述第二设备基于上述第二响应报文确定上述窗口缩放因子并基于上述窗口缩放因子确定上述数据传输窗口;
第二数据传输模块,用于基于上述窗口缩放因子确定上述数据传输窗口,基于上述数据传输窗口与上述第二设备进行数据传输。
另一方面,本申请实施例提供了一种电子设备,包括处理器和存储器,该处理器和存储器相互连接;
上述存储器用于存储计算机程序;
上述处理器被配置用于在调用上述计算机程序时,执行本申请实施例提供的任一种数据传输方法。
另一方面,本申请实施例提供了一种计算机可读存储介质,该计算机可读存储介质存储有计算机程序,该计算机程序被处理器执行以实现本申请实施例提供的任一种数据传输方法。
另一方面,本申请实施例提供了一种计算机程序产品或计算机程序,该计算机程序产品或计算机程序包括计算机指令,该计算机指令存储在计算机可读存储介质中。电子设备的处理器从计算机可读存储介质读取该计算机指令,处理器执行该计算机指令,使得该计算机设备执行本申请实施例提供的任一种数据传输方法。
在本申请实施例中,第二设备通过将第一窗口缩放因子和连接请求报文向第一设备发送第一响应报文,可使得第一设备确定的数据传输窗口和第二设备在接收到第二响应报文后确定的数据传输窗口相匹配,进而可提升数据传输的效率,维持数据传输的稳定性。
附图说明
为了更清楚地说明本申请实施例中的技术方案,下面将对实施例中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1是现有技术中基于syn-cookie的三次握手机制的一示意图;
图2是本申请实施例提供的网络结构示意图;
图3是本申请实施例提供的数据传输方法的时序示意图;
图4是本申请实施例提供的TCP报文头部的结构示意图;
图5是本申请实施例提供的发送第一响应报文的方法流程图;
图6是本申请实施例提供的确定syn-cookie的场景示意图;
图7是本申请实施例提供的窗口缩放因子的封装示意图;
图8是现有技术中基于syn-cookie的三次握手机制的另一示意图;
图9是本申请实施例提供的基于syn-cookie的三次握手机制的示意图;
图10是本申请实施例提供的数据传输装置的一结构示意图;
图11是本申请实施例提供的数据传输装置的另一结构示意图;
图12是本申请实施例提供的电子设备的结构示意图。
具体实施方式
下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
本申请实施例提供的数据传输方法可适用于syn-cookie下的TCP三次握手机制,如应用Linux操作系统的场景以及所有运行于Linux操作系统上的采用TCP协议的设备和/或营业程序等。为方便描述,本申请将TCP三次握手过程中的客户端称为第一设备,将三次握手过程中的服务端称为第二设备。
参见图2,图2是本申请实施例提供的网络结构示意图。在图2中,第一设备100和第二设备200为可以进行数据传输的设备,包括但不限于服务器或者终端设备等。作为一示例,本申请实施例中的第一设备100为终端设备,第二设备200为服务器。
其中,上述服务器可以是独立的物理服务器,也可以是多个物理服务器构成的服务器集群或者分布式系统,还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、Tcaplus、安全服务、内容分发网络(ContentDelivery Network,CDN)的云服务器或服务器集群,在此不做限制。上述终端设备可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、客户机以及智能手表等,但并不局限于此。
在本申请实施例中,第一设备100在需要向第二设备200建立连接以进行数据传输时,第一设备100可向第二设备200发送连接请求报文,第二设备200可接收第一设备100发送的连接请求报文,进而确定用于进行数据传输的数据传输窗口的窗口缩放因子windowsscale。
进一步的,第二设备200可基于接收到的连接请求报文和窗口缩放因子,向第一设备100发送第一响应报文,以对第一设备100的连接请求报文做出响应。第一设备100在接收到第一设备100发送的第一响应报文之后,可基于第一响应报文确定数据传输窗口的窗口缩放因子,进而基于窗口缩放因子确定用于进行数据传输的数据传输窗口。
同时,第一设备100可进一步向第二设备200发送针对第一响应报文的第二响应报文。对于第二设备200而言,第二设备200可响应于第一设备100发送的第二响应报文,进而基于第二响应报文确定出窗口缩放因子,进而基于窗口缩放因子确定数据传输窗口。基于此,第一设备100和第二设备200完成连接,并可基于确定出的数据传输窗口进行数据传输。
作为一示例,第一设备100为终端设备,第二设备200为服务器。终端设备向服务器发送同步请求(SYN报文),服务器可响应于上述SYN报文,并确定服务器数据传输窗口的窗口缩放因子,进而根据上述SYN报文和窗口缩放因子,向终端设备发送同步-确认应答(SYN-ACK报文)。
终端设备在接收到SYN-ACK报文之后,可基于SYN-ACK报文确定出服务器确定出的窗口缩放因子,进而基于窗口缩放因子确定出数据传输窗口。同时终端设备向服务器发送针对SYN-ACK报文的确认报文(ACK报文)。服务器在接收到ACK报文之后,可基于ACK报文确定出此前确定出的窗口缩放因子,进而基于窗口缩放因子确定出数据传输窗口,并在该时刻建立与终端设备的连接,从而终端设备和服务器可基于确定出的数据传输窗口进行数据传输。
参见图3,图3是本申请实施例提供的数据传输方法的时序示意图。如图3所示,本申请实施例提供的数据传输方法可包括如下步骤:
步骤S31、向第二设备发送连接请求报文。
在一些可行的实施方式中,第一设备在需要与第二设备建立通信连接以进行数据传输时,可向第一设备发起连接请求报文。
例如,第一设备在需要与第二设备建立TCP连接时,向第二设备发送同步请求(SYN报文)。
参见图4,图4是本申请实施例提供的TCP报文头部的结构示意图。在图4中,TCP报文头部的源端口(Source Port)和目的端口(Destination Port),同互联网协议地址(Internet Protocol Address,IP)数据包中源头IP和目的IP唯一确定一条TCP连接。
其中,序列号(Sequence Number)是该报文段发送的数据组的第一个字节的序号。在TCP传输的数据流中,每一个字节对应一个序号。确认序号(Acknowledgement Number)用于指明下一个期待接收到的字节序号,表明该序号之前的所有数据已经正确无误的收到。
其中,U、A、P、R、S、F为标志位(TCP Flags),U(URG)为紧急指针标志,为1时表示紧急指针有效,为0时则忽略紧急指针;A(ACK)为确认序号标志,为1时表示确认序号有效,为0表示报文中不含确认信息,忽略确认序号字段;P(PUSH)为push标志,为1表示是带有push标志的数据,指示接收方在接收到该报文段以后,应尽快将这个报文段交给应用程序,而不是在缓冲区排队;R(RST)为重置连接标志,用于重置由于主机崩溃或其他原因而出现错误的连接,或者用于拒绝非法的报文段和拒绝连接请求;S(SYN)为同步序列号标志,用于在连接请求中,SYN=1和ACK=0表示该数据段没有使用捎带的确认域,在连接应答中进行确认,即SYN=1和ACK=1;F(FIN)为finish标志,用于释放连接,为1时表示发送方已经没有数据发送了,即关闭本方数据流。
其中,窗口字段用于说明数据传输窗口的窗口大小,用来告知发送端接收端的缓存大小,以此控制发送端发送数据的速率,从而达到流量控制。
其中,最常见的可选字段是最大报文段长度(Maximum Segment Size,MSS),每个连接方通常都在通信的第一个报文段(为建立连接而设置SYN标志为1的报文段)中指明这个选项,表示所能接收的最大报文段的长度。
结合图4,第一设备向第二设备发送的连接请求报文中,SYN标志为1,ACK标志位为0,且该连接请求报文中不携带数据。上述连接请求报文的序列号为X,具体可基于实际应用场景确定,在此不做限制。第一设备在发送连接请求报文(SYN报文)后进入SYN-SENT状态,即同步已发送状态。
步骤S32、响应于第一设备发送的连接请求报文,确定数据传输窗口的窗口缩放因子。
在一些可行的实施方式中,TCP是一种面向连接的数据传输协议。为了保证数据可靠,TCP连接的两端(第一设备和第二设备)保持对所有传输数据的严格跟踪,以便在需要时候进行重传或重新排序。另外为了跟踪已经发送了的数据在发送端有TCP发送缓存,在接收端有接收缓存,数据传输窗口则是这个缓存的一部分,因此发送端发送的数据不能超过接收端的数据传输窗口的窗口大小。因此,第二设备在接收到第一设备发送的连接请求报文后,可基于系统资源确定窗口缩放因子windows scale,以基于窗口缩放因子确定对应的数据传输窗口。
步骤S33、基于连接请求报文和窗口缩放因子,向第一设备发送第一响应报文。
在一些可行的实施方式中,第二设备在接收到第一设备发送的连接请求报文,且同意建立连接后,可向第一设备发送第一响应报文。
例如,第二设备在接收到第一设备发送的同步请求(SYN报文),且同意与其建立连接时可向第一设备发送同步-确认应答(SYN-ACK报文)。
其中,第二设备向第一设备发送的第一响应报文中,SYN标志为1,ACK标志为1,且该第一响应报文中同样不携带数据。第二设备在发送第一响应报文后进入SYN-RCVD状态,即同步收到状态。
其中,第二设备向第一设备发送的第一响应报文中的确认序号(ack_sequence)为X+1,即连接请求报文的序列号(sequence)加1。
其中,第二设备向第一设备发送的第一响应报文可基于连接请求报文和窗口缩放因子发送。具体可参见图5,图5是本申请实施例提供的发送第一响应报文的方法流程图。如图5可知,本申请实施例提供的发送第一响应报文的方法流程图可包括以下步骤:
步骤S51、获取连接请求报文的序列号以及相对应的第一端口信息和第一互联网协议地址信息。
在一些可行的实施方式中,连接请求报文对应的第一端口信息为连接请求报文的报文头部中的源端口字段和目的端口字段。连接请求报文对应的第一互联网协议(IP)地址为连接请求报文对应的源IP地址和目的IP地址。连接请求报文的第一序列号为连接请求报文中的sequence字段。
步骤S52、确定第一系统时间以及第二设备对应的最大报文段长度的第一索引。
在一些可行的实施方式中,第一系统时间为当前时刻的系统时间。
在一些可行的实施方式中,第二设备对应的最大报文段长度(MSS为第二设备所接收的最大报文段的长度,其第一索引可用MSSIND表示。
步骤S53、基于连接请求报文的序列号、第一端口信息、第一互联网协议地址信息、第一系统时间、第一索引以及窗口缩放因子,向第一设备发送第一响应报文。
在一些可行的实施方式中,可基于上述确定出的连接请求报文的序列号、第一端口信息、第一IP地址信息、第一系统时间、第一索引以及窗口缩放因子,确定cookie数据,并将cookie数据作为第一响应报文中的序列号,进而将第一响应报文发送至第一设备。
作为一示例,上述cookie数据为第二设备在接收到第一设备发送的SYN建连请求后所确定出的syn-cookie。
在实际应用场景中,第二设备在接收到连接请求报文后,通常基于连接请求报文确定该连接请求报文的序列号、相对应的端口信息、IP地址信息、当前时刻的系统时间以及第二设备对应的最大报文段长度MSS的第一索引,通过安全散列算法(Secure HashAlgorithm,SHA)和哈希算法等计算操作以及位移操作等,确定出syn-cookie,并将确定出的syn-cookie作为第一响应报文的序列号以将第一响应报文发送至第一设备。
在本申请实施例中,第二设备在接收到连接请求报文后,通常基于连接请求报文确定该连接请求报文的序列号、相对应的端口信息、IP地址信息、当前时刻的系统时间、第二设备对应的最大报文段长度MSS的第一索引以及窗口缩放因子,通过安全散列算法(Secure Hash Algorithm,SHA)和哈希算法等计算操作以及位移操作等,确定出syn-cookie。
参见图6,图6是本申请实施例提供的确定syn-cookie的场景示意图。如图6所示,第二设备在确定syn-cookie的过程中,将窗口缩放因子和第二设备对应的最大报文段长度MSS的第一索引视为新的索引,进而基于连接请求报文的序列号、相对应的端口信息、IP地址信息、当前时刻的系统时间以及新的索引,通过SHA和哈希算法等计算操作以及位移操作等,确定出syn-cookie,并将确定出的syn-cookie作为第一响应报文的序列号以将第一响应报文发送至第一设备。
基于本申请实施例提供的确定syn-cookie的方式,可将第二设备确定出的窗口缩放因子编码进syn-cookie中。
在一些可行的实施方式中,在确定第一响应报文的序列号之前,可先将上述端口信息、IP地址信息、第一索引以及窗口缩放因子windowsscale等封装至第一响应报文的报文头部中,进而基于报文头部中的封装信息来确定第一响应报文的序列号。
其中,第一响应报文的确认号为连接请求报文的序列号加1。
具体的,对于第一索引和窗口缩放因子而言,可确定第一索引对应于第一响应报文的报文头部的指定位置,进而将第一索引封装与该指定位置中的第一比特位,将窗口缩放因子封装与该指定位置中的第二比特位。
可选的,可将第一索引所占用的低24比特位进行分割,一部分比特位存储第一索引,另一部分用于存储窗口缩放因子。
其中,上述第一比特位和第二比特位的位数以及分别相对于上述指定位置的具体位置可基于实际应用场景需求确定,在此不做限制。其中,上述指定位置可以为第一响应报文的报文头部的可选选项对应的位置。
作为一示例,参见图7,图7是本申请实施例提供的窗口缩放因子的封装示意图。在图7中,第一响应报文的序列号(syn-cookie)一共占据32比特位,第一索引位于syn-cookie对应的低24比特位(0-23)。由于第一索引往往不能完全占据上述低24比特位,因此可将窗口缩放因子和第一索引一起封装至上述低24比特位。如图7所示中将上述低24比特位中的低16比特位(0-15)用于存储第一索引,高8比特位(16-23)用于存储窗口缩放因子。
步骤S34、响应于第二设备针对连接请求报文的第一响应报文,基于第一响应报文确定数据传输窗口的窗口缩放因子。
在一些可行的实施方式中,第一设备在接收到第一响应报文之后,可基于第一响应报文确定数据传输窗口的窗口缩放因子。
具体的,第一设备可解析第一响应报文,确定第一响应报文的序列号,并对第一响应报文的序列号进行解析得到第二设备在接收到连接请求报文后确定的窗口缩放因子,并将窗口缩放因子进行存储,以在后续基于窗口缩放因子确定用于进行数据传输的数据传输窗口。
其中,上述窗口缩放因子的存储可基于大数据、区块链等技术实现。如将确定出的窗口缩放因子存储于数据库、数据库管理系统或者区块链中,或者基于大数据、云存储技术等,通过集群应用、网格技术以及分布存储文件系统等功能,将网络中大量各种不同类型的存储设备(存储设备也称之为存储节点)通过应用软件或应用接口集合起来协同工作,共同存储。
其中,区块链是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链本质上是一个去中心化的数据库,是一串使用密码学方法相关联产生的数据块,每一个数据块用于存储数据。区块链可以包括区块链底层平台、平台产品服务层以及应用服务层。
可选的,第一设备还可将窗口缩放因子存储于第一设备对应的存储空间中,包括但不限于设备缓存、云存储空间以及硬盘的,具体可基于实际应用场景需求确定,在此不做限制。
步骤S35、向第二设备发送针对第一响应报文的第二响应报文。
在一些可行的实施方式中,第一设备在接收到第二设备发送的针对连接请求报文的确认报文(第一响应报文)之后,需要向第二设备发送第二响应报文以表示对第一响应报文的确认。
具体的,第二响应报文的确认序号可基于第一响应报文的序列号(sequence)确定。
其中,上述第二响应报文的确认序号(ack_sequence)为第一响应报文的序列号(sequence)加1。即第一响应报文的序列号为第二设备确定出的cookie数据,则第二响应报文的确认序号为cookie加1。例如,第一响应报文的序列号为syn-cookie,则第二响应报文的确认序号为syn-cookie+1。
基于此,第一设备可向第二设备发送确认序号为syn-cookie+1的第二响应报文。
其中,第一设备向第二设备发送的第二响应报文中的SYN标志为0,ACK标志为1,表示对第一响应报文的确认。
其中,上述第二响应报文的序列号为连接请求报文的序列号加1,即连接请求报文的序列号为X,则第二响应报文的序列号为X+1。
进一步的,第一设备在向第二设备发送第二响应报文之后进入STABLISHED状态,同时第二设备在收到第二响应报文之后也会进入ESTABLISHED状态,从而第一设备和第二设备建立连接。
作为一示例,第一设备在接收到第二设备发送的同步-确认应答(SYN-ACK报文)之后,可向第二设备发送确认应答(ACK报文),以在第二设备接收到确认后与第二设备建立TCP连接。
步骤S36、响应于第一设备针对第一响应报文的第二响应报文,基于第二响应报文确定窗口缩放因子。
在一些可行的实施方式中,第二设备在接收到第一设备发送的第二响应报文之后,为减少再次确定窗口缩放因子的步骤,以及避免再次确定出的窗口缩放因子与接收到连接请求报文时确定出的窗口缩放因子不一致的情况,可基于第二响应报文确定出先前确定出的窗口缩放因子。
具体的,第二设备在基于第二响应报文确定窗口缩放因子时,可先解析第二响应报文得到第二响应报文的确认序号。
作为一示例,第一设备发送的确认应答(ACK报文)的确认序号为syn-cookie+1。
进一步的,第一设备可基于第二响应报文的确认序号,确定第二响应报文所包括的cookie数据(为方便描述,以下将第二设备发送第一响应报文时对应的cookie数据称为第一cookie数据,将第二响应报文所包括的cookie数据称为第二cookie数据)。
具体的,第二设备可将第二响应报文的确认序号减1得到第二cookie数据。
由于第二响应报文的确认序号是基于第二设备发送的第一响应报文的序列号确定的,且第一响应报文的序列号为第二设备基于窗口缩放因子等信息确定的第一cookie数据,因此第二响应报文所包括的第二cookie数据即为第二设备在接收到连接请求报文后所确定的第一cookie数据。
进一步的,由于第二设备在确定第一cookie数据时,将窗口缩放因子编码至第一cookie数据中,因此第二设备在基于第二响应报文的确认序号确定第二cookie数据之后,可对第二cookie数据进行解析得到第二cookie数据所包含的窗口缩放因子。
在一些可行的实施方式中,第二设备在接收到第二响应报文并解析出第二响应报文的确认序号包括的第二cookie数据之后,可对第二cookie数据进行验证,在验证通过后说明第二响应报文的确认序号是基于第一响应报文的序列号所确定的,且第二设备所接收到的第二响应报文不是伪造的报文。
进一步的,在第二响应报文的确认序号是基于第一响应报文的序列号所确定的情况下,可确定第二cookie数据和第一响应报文的序列号(第一cookie数据)相同,也可确定第二cookie数据包含的窗口缩放因子和第一cookie数据包含的窗口缩放因子为同一窗口缩放因子。
具体的,第二设备在对第二cookie数据进行验证时,确定第二cookie数据的指定比特位(高5位)所表征的第二系统时间。其中,第二系统时间为确定第二cookie数据时对应的系统时间。与此同时,可获取第二响应报文的序列号以及相对应的第二端口信息和第二IP地址信息,并根据第二响应报文的序列号确定连接请求报文的序列号(将第二响应报文的序列号减1)。进而可基于连接请求报文的序列号、上述第二端口信息、第二IP地址信息、第二系统时间以及在接收到连接请求报文时确定的窗口缩放因子,重新基于上述步骤S53所示的实现方式确定一个cookie数据(为方便描述,以下称为第三cookie数据,此时第三cookie数据和第一cookie数据为同一cookie数据)。
若第三cookie数据和第二cookie数据一致,则说明第二响应报文未被伪造,且第二响应报文的确认序号是基于第一响应报文的序列号所确定的,即说明第二cookie数据通过验证。
其中,在第二响应报文未被伪造的情况下,第二响应报文对应的第二端口信息和第二IP地址信息与连接请求报文对应的第一端口信息和第一IP地址信息相同。
可选的,第二设备在接收到连接请求报文,并确定第一cookie数据之后,可将其存储,在基于第二响应报文得到第二cookie数据之后,可将第一cookie数据与第二cookie数据进行比较,若二者一致,则第二cookie通过验证,第二响应报文不是伪造报文。
可选的,由于第二系统时间为确定第二cookie数据时对应的系统时间,因此在第三cookie数据和第二cookie数据一致的情况下,可确定第二系统时间和当前系统时间的时间间隔。若该时间间隔超过预设时间间隔,则说明数据传输时间较长,在此情况下可确定第二cookie数据验证不通过。
在第二cookie数据通过验证的情况下,第二设备基于第二响应报文的确认序号确定出的第二cookie数据即为第二设备发送的第一响应报文的序列号(第一cookie数据),进而确定第二cookie数据包含的窗口缩放因子和第一cookie数据包含的窗口缩放因子为同一窗口缩放因子。
其中,第二设备在收到第二响应报文,并在第二cookie数据通过验证之后,第二设备也会进入ESTABLISHED状态。
作为一示例,第二设备接收到确认应答(ACK应答,即第二响应报文)之后,确定确认应答的确认序号syn-cookie+1,将确认序号syn-cookie减1后得到syn-cookie。另一方面,第二设备基于确认应答所包括的相关信息以及在接收到连接请求报文时确定出的窗口缩放因子,计算新的syn-cookie。若新的syn-cookie和基于确认应答确定出的syn-cookie一致,说明确认应答不是伪造报文,且基于确认应答确定的syn-cookie有效。
进而第二设备可对基于确认应答确定出的syn-cookie进行解析,得到第二设备在接收到同步请求(SYN报文)后确定出的窗口缩放因子windowsscale,进而确定出最终的数据传输窗口。
在本申请实施例中,确定cookie数据以及确定数据传输窗口的过程可基于计算机技术以及云计算等方式进行。其中,云计算是网格计算(Grid Computing)、分布式计算(Distributed Computing)、并行计算(Parallel Computing)、效用计算(UtilityComputing)、网络存储(Network Storage Technologies)、虚拟化(Virtualization)、负载均衡(Load Balance)等传统计算机和网络技术发展融合的产物,基于云计算可提升本申请实施例中cookie数据以及确定数据传输窗口的计算效率。
步骤S37、基于窗口缩放因子确定数据传输窗口,基于数据传输窗口进行数据传输。
在一些可行的实施方式中,第一设备可确定数据传输窗口的初始窗口大小,进而基于初始窗口大小和在接收到第一响应报文后存储的窗口缩放因子确定用于进行数据传输的数据传输窗口。
可选的,初始窗口大小可从第一响应报文的报文头部中的窗口字段获取。
需要特别说明的是,第一设备基于窗口缩放因子确定出的数据传输窗口,为第二设备所能接收到的最大数据长度。即第一设备在后续向第二设备传输数据时,第二设备传输的数据的长度不能超过该数据传输窗口。
其中,数据传输窗口的具体计算过程可基于windowssize*2windowsscale确定。其中,windowssize为初始窗口大小,windowsscale为窗口缩放因子。
例如,windows size=15,windows scale=10,则用于进行数据传输的数据传输窗口的实际窗口大小为15360字节。
作为一示例,第一设备在接收到第二设备发送的SYN-ACK报文(第一响应报文)之后,可从SYN-ACK报文的报文头部的可选选项中获取窗口缩放因子,或者对SYN-ACK报文的序列号syn-cookie进行解析得到窗口缩放因子,进而基于初始窗口大小windowssize和窗口缩放因子确定最终的数据传输窗口。
在一些可行的实施方式中,第二设备可在对第二响应报文进行解析得到窗口缩放因子后,基于对第二响应报文进行解析得到的窗口缩放因子以及初始窗口大小,确定用于进行数据传输的数据传输窗口。其中,第二设备基于窗口缩放因子以及初始窗口大小确定数据传输窗口的具体方式,可参见上述第一设备确定数据传输窗口的具体实施方式,在此不再赘述。
需要特别说明的是,基于本申请实施例提供的方法,第一设备和第二设备确定出的数据传输窗口相同。
在一些可行的实施方式中,在第一设备和第二设备均进入ESTABLISHED状态之后,第一设备和第二设备可基于确定出的数据传输窗口进行数据传输。在该情况下,第一设备和第二设备所能接收或者发送的数据的最大长度不超过数据传输窗口对应的数据长度。
基于本申请实施例提供的数据传输方法,可在引入TCP syn-cookie来防范SYNFlood攻击的情况下,使得客户端和服务端采用的数据传输窗口一致,进而可提升数据传输的效率,维持数据传输的稳定性。
参见图8,图8是现有技术中基于syn-cookie的三次握手机制的另一示意图。Linux内核中服务端socket(套接字)根据系统分配的资源多少计算数据传输窗口(缓冲区)的大小,用windows size(初始窗口大小)和windows scale(窗口缩放因子)来表示,windowssize*2windowsscale为实际的数据传输窗口的大小。比如windows size=15,windowsscale=10,则服务端实际的数据传输窗口的大小为15360字节。
服务端在接收到同步请求(SYN报文)之后,会计算syn-cookie作为同步-确认应答(SYN-ACK报文)的序列号,计算服务端windows scale并封装到TCP头部,并向客户端返回同步-确认应答(SYN-ACK报文)。服务端会在同步-确认应答中将windows scale的值通告给客户端,后续的报文中将不再包含windows scale,而只有windows size。
服务端接收到用户端的同步请求后,会第一次计算窗口缩放因子。服务端收到客户端返回的最后一次握手确认应答(ACK报文)后,二次计算窗口缩放因子。在该机制下无法保证前后两次计算结果一致,基于此服务端在计算数据传输窗口时会采用第二次计算的窗口缩放因子,而客户端在计算数据传输窗口时则会采用其记录的服务端第一次计算的窗口缩放因子。
由图8可知,在SYN Flood场景下,服务端计算了两次窗口缩放因子,服务端在TCP三次握手后保存的是第二次计算的窗口缩放因子,而客户端保存的是第一次计算的窗口缩放因子。这将会造成服务端和客户端计算的数据传输窗口的窗口大小不匹配。例如,服务端第一次计算的windows scale=2,客户端保存的服务端第一次计算的windows scale=2,服务端第二次计算的windows scale=10。假设windows size=15,则服务端的数据传输窗口的实际窗口大小为15360字节(采用第二次计算的windows scale),客户端计算的数据传输窗口的实际窗口大小为60字节(采用第一次计算的windows scale)。基于此,服务端提供了15360字节大小的数据传输窗口,但客户端却认为服务端只有60字节的数据传输窗口,进而服务端每次发送数据都不超过60字节,导致数据传输效率降低。
参见图9,图9是本申请实施例提供的基于syn-cookie的三次握手机制的示意图。服务端在接收到同步请求(SYN报文)之后,会计算syn-cookie作为同步-确认应答(SYN-ACK报文)的序列号,计算服务端windows scale并封装到TCP头部,并向客户端返回同步-确认应答。
服务端接收到用户端的同步请求后,会第一次计算窗口缩放因子,并在同步-确认应答中将windows scale的值通告给客户端,后续的报文中将不再包含windows scale,而只有windows size。其中,服务端计算得到的syn-cookie中包含有第一次计算的windowsscale。
客户端在保存服务端第一次计算得到的windows scale之后,会返回确认应答(ACK报文),且该确认应答的确认序号是基于同步-确认应答的序列号确定的。即客户端返回的确认应答的确认序号中包括服务端第一次计算得到的windows scale。
服务端收到客户端返回的最后一次握手的确认应答后,从确认序号中解析出syn-cookie并做合法性检验,待验证通过后再从syn-cookie中解析出服务端第一次计算的windows scale。在该机制下服务端和客户端在计算数据传输窗口时会采用相同的windowsscale(服务端第一次计算的windows scale),进而在SYN Flood场景下实现服务端和客户端在TCP三次握手后确定出的数据传输窗口的窗口大小一致。
基于本申请实施例提供的数据传输方法,不仅不需要更改原有的syn-cookie机制,不影响对syn flood攻击的防范,又消除了服务端和客户端windows scale(或者数据传输窗口)不一致的风险,从而避免高连接、高并发的syn-cookie场景下数据传输窗口不同步导致传输速度下降的问题。
参见图10,图10是本申请实施例提供的数据传输装置的一结构示意图。本申请实施例提供的数据传输装置1包括:
第一报文响应模块11,用于响应于第一设备发送的连接请求报文,确定数据传输窗口的窗口缩放因子;
第一报文发送模块12,用于基于上述连接请求报文和上述窗口缩放因子,向上述第一设备发送第一响应报文;
第二报文响应模块13,用于响应于上述第一设备针对上述第一响应报文的第二响应报文,基于上述第二响应报文确定上述窗口缩放因子;
第一数据传输模块14,用于基于上述窗口缩放因子确定上述数据传输窗口,并基于上述数据传输窗口与上述第一设备进行数据传输。
在一些可行的实施方式中,上述第一报文发送模块12,用于:
获取上述连接请求报文的序列号以及相对应的第一端口信息和第一互联网协议地址信息;
确定第一系统时间以及第二设备对应的最大报文段长度的第一索引;
基于上述连接请求报文的序列号、上述第一端口信息、上述第一互联网协议地址信息、上述第一系统时间、上述第一索引以及上述窗口缩放因子,向上述第一设备发送第一响应报文。
在一些可行的实施方式中,上述第一报文发送模块12,用于:
基于上述连接请求报文的序列号、上述第一系统时间、上述第一端口信息、上述第一互联网协议地址信息、上述第一索引和上述窗口缩放因子,确定cookie数据;
基于上述cookie数据,向上述第一设备发送第一响应报文,其中,上述cookie数据为上述第一响应报文的序列号。
在一些可行的实施方式中,上述第一报文发送模块12,还用于:
确定上述第一索引对应于上述第一响应报文的报文头部的指定位置;
将上述第一索引封装于上述指定位置中的第一比特位,将上述窗口缩放因子封装于上述指定位置中的第二比特位。
在一些可行的实施方式中,上述第二报文响应模块13,用于:
解析上述第二响应报文,得到上述第二响应报文的确认序号;
基于上述第二响应报文的确认序号确定cookie数据;
解析上述cookie数据,得到上述窗口缩放因子。
在一些可行的实施方式中,上述第一数据传输模块14,用于:
确定上述数据传输窗口的初始窗口大小;
基于上述初始窗口大小和上述窗口缩放因子,确定上述数据传输窗口。
在一些可行的实施方式中,上述第二报文响应模块13,还用于:
确定上述第二响应报文的序列号以及相对应的第二端口信息和第二互联网协议地址信息;
基于上述cookie数据确定第二系统时间;
确定第二设备对应的最大报文段长度的第一索引;
基于上述第二响应报文的序列号、上述第二端口信息、上述第二互联网协议地址信息、上述第二系统时间以及上述第一索引,对上述cookie数据进行验证,若通过验证则执行解析上述cookie数据的步骤。
具体实现中,上述数据传输装置1可以是运行于计算机设备中的一个计算机程序(包括程序代码),例如该数据传输装置1为一个应用软件,该数据传输装置1可通过其内置的各个功能模块执行如上述图3中步骤S32、步骤S33、步骤S36以及步骤S37和/或图5中各个步骤所提供的实现方式,具体可参见上述各个步骤所提供的实现方式,在此不再赘述。
在一些可行实施例中,本申请实施例提供的数据传输装置1可以采用软硬件结合的方式实现,作为示例,本申请实施例提供的数据传输装置1可以是采用硬件译码处理器形式的处理器,其被编程以上述图3中步骤S32、步骤S33、步骤S36以及步骤S37和/或图5中各个步骤所示的实现方式,例如,硬件译码处理器形式的处理器可以采用一个或多个应用专用集成电路(ASIC,Application Specific Integrated Circuit)、数字信号处理器(digital signal processor,DSP)、可编程逻辑器件(PLD,Programmable Logic Device)、复杂可编程逻辑器件(CPLD,Complex Programmable Logic Device)、现场可编程门阵列(FPGA,Field-Programmable Gate Array)或其他电子元件。
在一些可行的实施例中,本申请实施例提供的数据传输装置1可以采用软件方式实现,图10中的数据传输装置1,其可以是程序和插件等形式的软件,并包括一系列的模块,包括第一报文响应模块11、第一报文发送模块12、第二报文响应模块13以及第一数据传输模块14;其中,第一报文响应模块11、第一报文发送模块12、第二报文响应模块13以及第一数据传输模块14用于实现上述图3中步骤S32、步骤S33、步骤S36以及步骤S37和/或图5中各个步骤。
参见图11,图11是本申请实施例提供的数据传输装置的另一结构示意图。本申请实施例提供的数据传输装置2包括:
第二报文发送模块21,用于向第二设备发送连接请求报文;
第三报文响应模块22,用于响应于上述第二设备针对上述连接请求报文的第一响应报文,基于上述第一响应报文确定数据传输窗口的窗口缩放因子,上述第一响应报文是上述第二设备基于上述连接请求报文和上述窗口缩放因子确定的;
第三报文发送模块23,用于向上述第二设备发送针对上述第一响应报文的第二响应报文,以使上述第二设备基于上述第二响应报文确定上述窗口缩放因子并基于上述窗口缩放因子确定上述数据传输窗口;
第二数据传输模块24,用于基于上述窗口缩放因子确定上述数据传输窗口,基于上述数据传输窗口与上述第二设备进行数据传输。
在一些可行的实施方式中,上述第三报文响应模块22,用于:
响应于上述第二设备针对上述连接请求报文的第一响应报文,确定上述第一响应报文的序列号;
解析上述第一响应报文的序列号,得到数据传输窗口的窗口缩放因子。
在一些可行的实施方式中,上述第三报文发送模块23,用于:
基于上述第一响应报文的序列号,确定针对上述第一响应报文的第二响应报文的确认序号;
基于上述第二响应报文的确认序号,向上述第二设备发送上述第二响应报文。
在一些可行的实施方式中,上述第二数据传输模块24,用于:
确定上述数据传输窗口的初始窗口大小;
基于上述初始窗口大小和上述窗口缩放因子,确定上述数据传输窗口。
具体实现中,上述数据传输装置2可以是运行于计算机设备中的一个计算机程序(包括程序代码),例如该数据传输装置2为一个应用软件,该数据传输装置2可通过其内置的各个功能模块执行如上述图3中步骤S31、步骤S34、步骤S35以及步骤S37所示的实现方式,具体可参见上述各个步骤所提供的实现方式,在此不再赘述。
在一些可行实施例中,本申请实施例提供的数据传输装置2可以采用软硬件结合的方式实现,作为示例,本申请实施例提供的数据传输装置2可以是采用硬件译码处理器形式的处理器,其被编程以执行上述图3中步骤S31、步骤S34、步骤S35以及步骤S37所示的实现方式,例如,硬件译码处理器形式的处理器可以采用一个或多个应用专用集成电路ASIC、DSP、PLD、CPLD、FPGA或其他电子元件。
在一些可行的实施例中,本申请实施例提供的数据传输装置2可以采用软件方式实现,图11中的数据传输装置2,其可以是程序和插件等形式的软件,并包括一系列的模块,包括第二报文发送模块21、第三报文响应模块22、第三报文发送模块23以及第二数据传输模块24;其中,第二报文发送模块21、第三报文响应模块22、第三报文发送模块23以及第二数据传输模块24用于实现上述图3中步骤S31、步骤S34、步骤S35以及步骤S37所示的实现方式。
在本申请实施例中,第二设备通过确定出的窗口缩放因子和连接请求报文向第一设备发送第一响应报文,可使得第一设备确定的数据传输窗口和第二设备在接收到第二响应报文后确定的数据传输窗口相匹配,进而可提升数据传输的效率,维持数据传输的稳定性。
参见图12,图12是本申请实施例提供的电子设备的结构示意图。如图12所示,本实施例中的电子设备1000可以包括:处理器1001,网络接口1004和存储器1005,此外,上述电子设备1000还可以包括:用户接口1003,和至少一个通信总线1002。其中,通信总线1002用于实现这些组件之间的连接通信。其中,用户接口1003可以包括显示屏(Display)、键盘(Keyboard),可选用户接口1003还可以包括标准的有线接口、无线接口。网络接口1004可选的可以包括标准的有线接口、无线接口(如WI-FI接口)。存储器1004可以是高速RAM存储器,也可以是非不稳定的存储器(non-volatile memory),例如至少一个磁盘存储器。存储器1005可选的还可以是至少一个位于远离前述处理器1001的存储装置。如图12所示,作为一种计算机可读存储介质的存储器1005中可以包括操作系统、网络通信模块、用户接口模块以及设备控制应用程序。
在图12所示的电子设备1000中,网络接口1004可提供网络通讯功能;而用户接口1003主要用于为用户提供输入的接口;而电子设备1000作为第二设备时,处理器1001可以用于调用存储器1005中存储的设备控制应用程序,以实现:
响应于第一设备发送的连接请求报文,确定数据传输窗口的窗口缩放因子;
基于上述连接请求报文和上述窗口缩放因子,向上述第一设备发送第一响应报文;
响应于上述第一设备针对上述第一响应报文的第二响应报文,基于上述第二响应报文确定上述窗口缩放因子;
基于上述窗口缩放因子确定上述数据传输窗口,并基于上述数据传输窗口与上述第一设备进行数据传输。
在一些可行的实施方式中,上述处理器1001用于:
获取上述连接请求报文的序列号以及相对应的第一端口信息和第一互联网协议地址信息;
确定第一系统时间以及第二设备对应的最大报文段长度的第一索引;
基于上述连接请求报文的序列号、上述第一端口信息、上述第一互联网协议地址信息、上述第一系统时间、上述第一索引以及上述窗口缩放因子,向上述第一设备发送第一响应报文。
在一些可行的实施方式中,上述处理器1001用于:
基于上述连接请求报文的序列号、上述第一系统时间、上述第一端口信息、上述第一互联网协议地址信息、上述第一索引和上述窗口缩放因子,确定cookie数据;
基于上述cookie数据,向上述第一设备发送第一响应报文,其中,上述cookie数据为上述第一响应报文的序列号。
在一些可行的实施方式中,上述处理器1001还用于:
确定上述第一索引对应于上述第一响应报文的报文头部的指定位置;
将上述第一索引封装于上述指定位置中的第一比特位,将上述窗口缩放因子封装于上述指定位置中的第二比特位。
在一些可行的实施方式中,上述处理器1001用于:
解析上述第二响应报文,得到上述第二响应报文的确认序号;
基于上述第二响应报文的确认序号确定cookie数据;
解析上述cookie数据,得到上述窗口缩放因子。
在一些可行的实施方式中,上述处理器1001用于:
确定上述数据传输窗口的初始窗口大小;
基于上述初始窗口大小和上述窗口缩放因子,确定上述数据传输窗口。
在一些可行的实施方式中,上述处理器1001还用于:
确定上述第二响应报文的序列号以及相对应的第二端口信息和第二互联网协议地址信息;
基于上述cookie数据确定第二系统时间;
确定第二设备对应的最大报文段长度的第一索引;
基于上述第二响应报文的序列号、上述第二端口信息、上述第二互联网协议地址信息、上述第二系统时间以及上述第一索引,对上述cookie数据进行验证,若通过验证则执行解析上述cookie数据的步骤。
可选的,电子设备1000作为第一设备时,处理器1001还可以用于调用存储器1005中存储的设备控制应用程序,以实现:
向第二设备发送连接请求报文;
响应于上述第二设备针对上述连接请求报文的第一响应报文,基于上述第一响应报文确定数据传输窗口的窗口缩放因子,上述第一响应报文是上述第二设备基于上述连接请求报文和上述窗口缩放因子确定的;
向上述第二设备发送针对上述第一响应报文的第二响应报文,以使上述第二设备基于上述第二响应报文确定上述窗口缩放因子并基于上述窗口缩放因子确定上述数据传输窗口;
基于上述窗口缩放因子确定上述数据传输窗口,基于上述数据传输窗口与上述第二设备进行数据传输。
在一些可行的实施方式中,上述处理器1001用于:
响应于上述第二设备针对上述连接请求报文的第一响应报文,确定上述第一响应报文的序列号;
解析上述第一响应报文的序列号,得到数据传输窗口的窗口缩放因子。
在一些可行的实施方式中,上述处理器1001用于:
基于上述第一响应报文的序列号,确定针对上述第一响应报文的第二响应报文的确认序号;
基于上述第二响应报文的确认序号,向上述第二设备发送上述第二响应报文。
在一些可行的实施方式中,上述处理器1001用于:
确定上述数据传输窗口的初始窗口大小;
基于上述初始窗口大小和上述窗口缩放因子,确定上述数据传输窗口。应当理解,在一些可行的实施方式中,上述处理器1001可以是中央处理单元(central processingunit,CPU),该处理器还可以是其他通用处理器、DSP、专用集成电路(applicationspecific integrated circuit,ASIC)、FPGA或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。该存储器可以包括只读存储器和随机存取存储器,并向处理器提供指令和数据。存储器的一部分还可以包括非易失性随机存取存储器。例如,存储器还可以存储设备类型的信息。
具体实现中,上述电子设备1000可通过其内置的各个功能模块执行如上述图3和/或图5中各个步骤所提供的实现方式,具体可参见上述各个步骤所提供的实现方式,在此不再赘述。
在本申请实施例中,第二设备通过确定出的窗口缩放因子和连接请求报文向第一设备发送第一响应报文,可使得第一设备确定的数据传输窗口和第二设备在接收到第二响应报文后确定的数据传输窗口相匹配,进而可提升数据传输的效率,维持数据传输的稳定性。
本申请实施例还提供一种计算机可读存储介质,该计算机可读存储介质存储有计算机程序,被处理器执行以实现图3和/或图5中各个步骤所提供的方法,具体可参见上述各个步骤所提供的实现方式,在此不再赘述。
上述计算机可读存储介质可以是前述任一实施例提供的数据传输装置或者电子设备的内部存储单元,例如电子设备的硬盘或内存。该计算机可读存储介质也可以是该电子设备的外部存储设备,例如该电子设备上配备的插接式硬盘,智能存储卡(smart mediacard,SMC),安全数字(secure digital,SD)卡,闪存卡(flash card)等。上述计算机可读存储介质还可以包括磁碟、光盘、只读存储记忆体(read-only memory,ROM)或随机存储记忆体(random access memory,RAM)等。进一步地,该计算机可读存储介质还可以既包括该电子设备的内部存储单元也包括外部存储设备。该计算机可读存储介质用于存储该计算机程序以及该电子设备所需的其他程序和数据。该计算机可读存储介质还可以用于暂时地存储已经输出或者将要输出的数据。
本申请实施例提供了一种计算机程序产品或计算机程序,该计算机程序产品或计算机程序包括计算机指令,该计算机指令存储在计算机可读存储介质中。电子设备的处理器从计算机可读存储介质读取该计算机指令,处理器执行该计算机指令,使得该计算机设备执行图3和/或图5中各个步骤所提供的方法。
本申请的权利要求书和说明书及附图中的术语“第一”、“第二”等是用于区别不同对象,而不是用于描述特定顺序。此外,术语“包括”和“具有”以及它们任何变形,意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或电子设备没有限定于已列出的步骤或单元,而是可选地还包括没有列出的步骤或单元,或可选地还包括对于这些过程、方法、产品或电子设备固有的其它步骤或单元。在本文中提及“实施例”意味着,结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置展示该短语并不一定均是指相同的实施例,也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是,本文所描述的实施例可以与其它实施例相结合。在本申请说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合,并且包括这些组合。
本领域普通技术人员可以意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,能够以电子硬件、计算机软件或者二者的结合来实现,为了清楚地说明硬件和软件的可互换性,在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本申请的范围。
以上所揭露的仅为本申请较佳实施例而已,不能以此来限定本申请之权利范围,因此依本申请权利要求所作的等同变化,仍属本申请所涵盖的范围。

Claims (15)

1.一种数据传输方法,其特征在于,所述方法包括:
响应于第一设备发送的连接请求报文,确定数据传输窗口的窗口缩放因子;
基于所述连接请求报文和所述窗口缩放因子,向所述第一设备发送第一响应报文;
响应于所述第一设备针对所述第一响应报文的第二响应报文,基于所述第二响应报文确定所述窗口缩放因子;
基于所述窗口缩放因子确定所述数据传输窗口,并基于所述数据传输窗口与所述第一设备进行数据传输。
2.根据权利要求1所述的方法,其特征在于,所述基于所述连接请求报文和所述窗口缩放因子,向所述第一设备发送第一响应报文,包括:
获取所述连接请求报文的序列号以及相对应的第一端口信息和第一互联网协议地址信息;
确定第一系统时间以及第二设备对应的最大报文段长度的第一索引;
基于所述连接请求报文的序列号、所述第一端口信息、所述第一互联网协议地址信息、所述第一系统时间、所述第一索引以及所述窗口缩放因子,向所述第一设备发送第一响应报文。
3.根据权利要求2所述的方法,其特征在于,所述基于所述连接请求报文的序列号、所述第一端口信息、所述第一互联网协议地址信息、所述第一系统时间、所述第一索引以及所述窗口缩放因子,向所述第一设备发送第一响应报文,包括:
基于所述连接请求报文的序列号、所述第一系统时间、所述第一端口信息、所述第一互联网协议地址信息、所述第一索引和所述窗口缩放因子,确定cookie数据;
基于所述cookie数据,向所述第一设备发送第一响应报文,其中,所述cookie数据为所述第一响应报文的序列号。
4.根据权利要求3所述的方法,其特征在于,所述方法还包括:
确定所述第一索引对应于所述第一响应报文的报文头部的指定位置;
将所述第一索引封装于所述指定位置中的第一比特位,将所述窗口缩放因子封装于所述指定位置中的第二比特位。
5.根据权利要求1所述的方法,其特征在于,所述基于所述第二响应报文确定所述窗口缩放因子,包括:
解析所述第二响应报文,得到所述第二响应报文的确认序号;
基于所述第二响应报文的确认序号确定cookie数据;
解析所述cookie数据,得到所述窗口缩放因子。
6.根据权利要求1所述的方法,其特征在于,所述基于所述窗口缩放因子确定所述数据传输窗口,包括:
确定所述数据传输窗口的初始窗口大小;
基于所述初始窗口大小和所述窗口缩放因子,确定所述数据传输窗口。
7.根据权利要求5所述的方法,其特征在于,所述方法还包括:
确定所述第二响应报文的序列号以及相对应的第二端口信息和第二互联网协议地址信息;
基于所述cookie数据确定第二系统时间;
确定第二设备对应的最大报文段长度的第一索引;
基于所述第二响应报文的序列号、所述第二端口信息、所述第二互联网协议地址信息、所述第二系统时间以及所述第一索引,对所述cookie数据进行验证,若通过验证则执行解析所述cookie数据的步骤。
8.一种数据传输方法,其特征在于,所述方法包括:
向第二设备发送连接请求报文;
响应于所述第二设备针对所述连接请求报文的第一响应报文,基于所述第一响应报文确定数据传输窗口的窗口缩放因子,所述第一响应报文是所述第二设备基于所述连接请求报文和所述窗口缩放因子确定的;
向所述第二设备发送针对所述第一响应报文的第二响应报文,以使所述第二设备基于所述第二响应报文确定所述窗口缩放因子并基于所述窗口缩放因子确定所述数据传输窗口;
基于所述窗口缩放因子确定所述数据传输窗口,基于所述数据传输窗口与所述第二设备进行数据传输。
9.根据权利要求8所述的方法,其特征在于,所述响应于所述第二设备针对所述连接请求报文的第一响应报文,基于所述第一响应报文确定数据传输窗口的窗口缩放因子,包括:
响应于所述第二设备针对所述连接请求报文的第一响应报文,确定所述第一响应报文的序列号;
解析所述第一响应报文的序列号,得到数据传输窗口的窗口缩放因子。
10.根据权利要求9所述的方法,其特征在于,所述向所述第二设备发送针对所述第一响应报文的第二响应报文,包括:
基于所述第一响应报文的序列号,确定针对所述第一响应报文的第二响应报文的确认序号;
基于所述第二响应报文的确认序号,向所述第二设备发送所述第二响应报文。
11.根据权利要求8所述的方法,其特征在于,所述基于所述窗口缩放因子确定所述数据传输窗口,包括:
确定所述数据传输窗口的初始窗口大小;
基于所述初始窗口大小和所述窗口缩放因子,确定所述数据传输窗口。
12.一种数据传输装置,其特征在于,所述数据传输装置包括:
第一报文响应模块,用于响应于第一设备发送的连接请求报文,确定数据传输窗口的窗口缩放因子;
第一报文发送模块,用于基于所述连接请求报文和所述窗口缩放因子,向所述第一设备发送第一响应报文;
第二报文响应模块,用于响应于所述第一设备针对所述第一响应报文的第二响应报文,基于所述第二响应报文确定所述窗口缩放因子;
第一数据传输模块,用于基于所述窗口缩放因子确定所述数据传输窗口,并基于所述数据传输窗口与所述第一设备进行数据传输。
13.一种数据传输装置,其特征在于,所述数据传输装置包括:
第二报文发送模块,用于向第二设备发送连接请求报文;
第三报文响应模块,用于响应于所述第二设备针对所述连接请求报文的第一响应报文,基于所述第一响应报文确定数据传输窗口的窗口缩放因子,所述第一响应报文是所述第二设备基于所述连接请求报文和所述窗口缩放因子确定的;
第三报文发送模块,用于向所述第二设备发送针对所述第一响应报文的第二响应报文,以使所述第二设备基于所述第二响应报文确定所述窗口缩放因子并基于所述窗口缩放因子确定所述数据传输窗口;
第二数据传输模块,用于基于所述窗口缩放因子确定所述数据传输窗口,基于所述数据传输窗口与所述第二设备进行数据传输。
14.一种电子设备,其特征在于,包括处理器和存储器,所述处理器和存储器相互连接;
所述存储器用于存储计算机程序;
所述处理器被配置用于在调用所述计算机程序时,执行如权利要求1至7任一项所述的方法或者权利要求8至11所述的方法。
15.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质存储有计算机程序,所述计算机程序被处理器执行以实现权利要求1至7任一项所述的方法或者实现权利要求8至11所述的方法。
CN202110204458.9A 2021-02-23 2021-02-23 数据传输方法、装置、设备以及存储介质 Active CN114979172B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110204458.9A CN114979172B (zh) 2021-02-23 2021-02-23 数据传输方法、装置、设备以及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110204458.9A CN114979172B (zh) 2021-02-23 2021-02-23 数据传输方法、装置、设备以及存储介质

Publications (2)

Publication Number Publication Date
CN114979172A true CN114979172A (zh) 2022-08-30
CN114979172B CN114979172B (zh) 2024-06-11

Family

ID=82972578

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110204458.9A Active CN114979172B (zh) 2021-02-23 2021-02-23 数据传输方法、装置、设备以及存储介质

Country Status (1)

Country Link
CN (1) CN114979172B (zh)

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101162971A (zh) * 2007-10-30 2008-04-16 华为技术有限公司 数据传输的方法、设备及系统
US20120137019A1 (en) * 2010-11-29 2012-05-31 Verizon Patent And Licensing, Inc. Tcp window size performance optimization in wireless networks
CN103227794A (zh) * 2013-04-28 2013-07-31 华为技术有限公司 数据传输控制方法、装置以及系统
WO2016033948A1 (zh) * 2014-09-02 2016-03-10 中兴通讯股份有限公司 一种发送窗口流量控制方法和终端
CN108023758A (zh) * 2016-11-04 2018-05-11 华为技术有限公司 一种混合接入网络中处理报文的方法及网络设备
CN108432287A (zh) * 2015-12-24 2018-08-21 华为技术有限公司 一种数据传输方法及网络侧设备
WO2020024775A1 (zh) * 2018-08-02 2020-02-06 Oppo广东移动通信有限公司 数据传输控制方法及相关装置

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101162971A (zh) * 2007-10-30 2008-04-16 华为技术有限公司 数据传输的方法、设备及系统
WO2009059545A1 (fr) * 2007-10-30 2009-05-14 Huawei Technologies Co., Ltd. Procédé, dispositif et système de transmission de données
US20120137019A1 (en) * 2010-11-29 2012-05-31 Verizon Patent And Licensing, Inc. Tcp window size performance optimization in wireless networks
CN103227794A (zh) * 2013-04-28 2013-07-31 华为技术有限公司 数据传输控制方法、装置以及系统
WO2016033948A1 (zh) * 2014-09-02 2016-03-10 中兴通讯股份有限公司 一种发送窗口流量控制方法和终端
CN108432287A (zh) * 2015-12-24 2018-08-21 华为技术有限公司 一种数据传输方法及网络侧设备
CN108023758A (zh) * 2016-11-04 2018-05-11 华为技术有限公司 一种混合接入网络中处理报文的方法及网络设备
WO2020024775A1 (zh) * 2018-08-02 2020-02-06 Oppo广东移动通信有限公司 数据传输控制方法及相关装置

Also Published As

Publication number Publication date
CN114979172B (zh) 2024-06-11

Similar Documents

Publication Publication Date Title
EP3338396B1 (en) Device and method for establishing connection in load-balancing system
US9906630B2 (en) Processing data packets in performance enhancing proxy (PEP) environment
CN110597839A (zh) 交易数据处理方法、装置、设备以及存储介质
US10230563B2 (en) Methods and first network node for managing a stream control transmission protocol association
US9332090B1 (en) Communication data padding
CN111064755B (zh) 一种数据保护方法、装置、计算机设备和存储介质
CN110120854B (zh) 传输数据的方法和装置
WO2021134418A1 (zh) 一种数据校验方法及装置
CN102325025B (zh) 提供源真实性的数据处理方法及系统
US9241048B2 (en) Mechanism for processing network event protocol messages
CN111182551B (zh) 网络安全防护方法和系统
CN115361455B (zh) 一种数据传输存储方法、装置以及计算机设备
CN114979172B (zh) 数据传输方法、装置、设备以及存储介质
Kulkarni et al. Analysis of tcp performance in data center networks
CN114513418B (zh) 一种数据处理方法及相关设备
US20190236331A1 (en) Method, apparatus, and storage medium for data verification
CN115499173A (zh) 一种基于udp协议的可信通讯方法和系统
CN113225348B (zh) 请求防重放校验方法和装置
WO2020103420A1 (zh) 一种数据传输方法、接收方法、装置及系统
CN116055582A (zh) 一种专用网络报文tcp分段方法及设备
CN113765851B (zh) 一种数据处理方法及其设备
CN114124489B (zh) 防止流量攻击的方法、清洗装置、设备和介质
CN116566914B (zh) 旁路tcp加速方法、装置、设备及介质
CN114338010A (zh) 一种不落盘的数据库局内加密密钥加密方法、装置及电子设备
CN117768190A (zh) 一种基于http格式报文的病毒拦截方法、装置及设备

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
REG Reference to a national code

Ref country code: HK

Ref legal event code: DE

Ref document number: 40073418

Country of ref document: HK

GR01 Patent grant
GR01 Patent grant