CN114500399A - 数据传输方法、设备、介质和产品 - Google Patents

数据传输方法、设备、介质和产品 Download PDF

Info

Publication number
CN114500399A
CN114500399A CN202111625151.2A CN202111625151A CN114500399A CN 114500399 A CN114500399 A CN 114500399A CN 202111625151 A CN202111625151 A CN 202111625151A CN 114500399 A CN114500399 A CN 114500399A
Authority
CN
China
Prior art keywords
data
data segment
segment
length
tcp
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.)
Pending
Application number
CN202111625151.2A
Other languages
English (en)
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.)
CERNET Corp
Original Assignee
CERNET Corp
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 CERNET Corp filed Critical CERNET Corp
Priority to CN202111625151.2A priority Critical patent/CN114500399A/zh
Publication of CN114500399A publication Critical patent/CN114500399A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/36—Flow control; Congestion control by determining packet size, e.g. maximum transfer unit [MTU]
    • H04L47/365—Dynamic adaptation of the packet size
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/12—Avoiding congestion; Recovering from congestion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/37—Slow start
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0435—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption

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)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本公开提供了一种数据传输方法，包括：S1，获取待封装的数据，对所述待封装的数据进行分段，依次形成至少一个第一数据段和至少一个第二数据段；其中，所述至少一个第一数据段的数据长度较所述至少一个第二数据段的数据长度小；S2，对所述至少一个第一数据段和至少一个第二数据段分别进行加密。其适配了传输控制协议(TCP)具有拥塞控制机制的特性，在TCP连接刚开始的慢启动阶段，拥塞窗口较小，数据长度较小的第一数据段可以通过，一旦连接运行起来，就可以增加分段的数据长度，通过数据长度较长的第二数据段。传输数据的长度与TCP能够发送的大小相匹配，能在保证数据传输前期时延的情况下，增加吞吐率。

Description

数据传输方法、设备、介质和产品
技术领域
本公开涉及数据传输技术领域，具体涉及一种数据传输方法、设备、介质和产品。
背景技术
TLS/SSL数据加解密是基于分段的，接收方收到一个完整的分段就可以解密，如果分段过大，那接收方必须要等到接收完整个分段的数据才能解密，当网络不好出现丢包、拥塞、重传等等情况下会严重影响时延，如果分段过小，头部负载比重就会较大，影响吞吐率。所以，怎么分段就比较关键，也就是TLS Record Size大小多少合适。这就涉及到两个重要的指标：时延和吞吐率。
也即，如果TLS Record Size设置的较大，单个Record会在TCP层拆成多个包发送，那么时延就会增大，而由于Record头部占比较小，吞吐率却会增加，而TLS Record Size如果设置的较小，单个的record在TCP层存在于一个包中，时延就会比较小，而由于record头部占比较大，吞吐率却会下降。
发明内容
针对现有技术存在的上述缺陷，本发明提供了一种数据传输方法、设备、介质和产品，其适配了传输控制协议(TCP)具有拥塞控制机制的特性，在TCP连接刚开始的慢启动阶段，拥塞窗口较小，数据长度较小的第一数据段可以通过，一旦连接运行起来，就可以增加分段的数据长度，通过数据长度较长的第二数据段。传输数据的长度与TCP能够发送的大小相匹配，能在保证数据传输前期时延的情况下，增加吞吐率。
本发明提供了一种数据传输方法，包括：S1，获取待封装的数据，对所述待封装的数据进行分段，依次形成至少一个第一数据段和至少一个第二数据段；其中，所述至少一个第一数据段的数据长度较所述至少一个第二数据段的数据长度小；S2，对所述至少一个第一数据段和至少一个第二数据段分别进行加密。
可选地，所述S1中，所述至少一个第一数据段的大小为MTU与Record头部和TCP头部的差值，所述至少一个第二数据段的大小为16KB。
可选地，所述S1还包括：所述至少一个第一数据段和至少一个第二数据段依次传输，当所述至少一个第二数据段无法传输，对所述第二数据段的内容以第一数据段的数据长度为分段长度重新进行分段。
可选地，所述S2还包括：当所述至少一个第一数据段和至少一个第二数据段满足第一条件的情况下，使用第一方法进行加密；当所述至少一个第一数据段和至少一个第二数据段满足第二条件的情况下，使用第二方法进行加密。
可选地，当所述至少一个第一数据段和至少一个第二数据段为请求报文时，则代表其满足第一条件；当所述至少一个第一数据段和至少一个第二数据段为响应报文时，则代表其满足第二条件。
可选地，所述第一方法较第二方法加密过程更复杂。
可选地，所述第一方法为非对称加密；所述第二方法为对称加密。
本发明还提供了一种电子设备，包括：一个或多个处理器；存储装置，用于存储一个或多个程序，其中，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器执行上述一种数据传输方法。
本发明还提供了一种计算机可读存储介质，其上存储有可执行指令，该指令被处理器执行时使处理器执行上述一种数据传输方法。
本发明还提供了一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现上述一种数据传输方法。
本发明中所公开的数据传输方法、设备、介质和产品，适配了传输控制协议(TCP)具有拥塞控制机制的特性，在TCP连接刚开始的慢启动阶段，拥塞窗口较小，数据长度较小的第一数据段可以通过，一旦连接运行起来，就可以增加分段的数据长度，通过数据长度较长的第二数据段。传输数据的长度与TCP能够发送的大小相匹配，能在保证数据传输前期时延的情况下，增加吞吐率。
本发明中所公开的数据传输方法、设备、介质和产品，对请求报文和响应报文分别加密，由于请求包通常以小文件为主，因此应当使用加密过程更为复杂的非对称加密对其进行加密。而响应包通常以大文件为主，为考虑响应时间，因此加密过程应以相对简单的对称加密来进行。这样有针对性地设置请求包和响应包的加密类型，使得加密过程更合理，在保证响应速度的情况下，还保证了传输的安全性。
附图说明
图1示意性示出了根据本公开实施例的TLS的结构示意图；
图2示意性示出了根据本公开实施例的TLS Record协议的消息封装流程图；
图3示意性示出了根据本公开实施例的数据传输方法的应用场景图；
图4示意性示出了根据本公开实施例的数据传输方法的流程图；
图5示意性示出了根据本公开实施例的适于实现数据传输方法的方框图；
图中，终端设备-101、102、103；网络-104；服务器-105；电子设备-200；处理器-201；只读存储器(ROM)-202；随机访问存储器(RAM)-203；总线-204；输入/输出(I/O)接口-205；输入部分-206、207；存储部分-208；通信部分-209；驱动器-210；可拆卸介质-211。
具体实施方式
为使本公开的目的、技术方案和优点更加清楚明白，以下结合具体实施例，并参照附图，对本公开作进一步的详细说明。
以下，将参照附图来描述本公开的实施例。但是应该理解，这些描述只是示例性的，而并非要限制本公开的范围。在下面的详细描述中，为便于解释，阐述了许多具体的细节以提供对本公开实施例的全面理解。然而，明显地，一个或多个实施例在没有这些具体细节的情况下也可以被实施。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本公开的概念。
在此使用的术语仅仅是为了描述具体实施例，而并非意在限制本公开。在此使用的术语“包括”、“包含”等表明了特征、步骤、操作和/或部件的存在，但是并不排除存在或添加一个或多个其他特征、步骤、操作或部件。
在此使用的所有术语(包括技术和科学术语)具有本领域技术人员通常所理解的含义，除非另外定义。应注意，这里使用的术语应解释为具有与本说明书的上下文相一致的含义，而不应以理想化或过于刻板的方式来解释。
在使用类似于“A、B和C等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有A、B和C中至少一个的系统”应包括但不限于单独具有A、单独具有B、单独具有C、具有A和B、具有A和C、具有B和C、和/或具有A、B、C的系统等)。在使用类似于“A、B或C等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有A、B或C中至少一个的系统”应包括但不限于单独具有A、单独具有B、单独具有C、具有A和B、具有A和C、具有B和C、和/或具有A、B、C的系统等)。
图1示意性示出了根据本公开实施例的TLS的结构示意图。
TRS(TLS Record Size)是TLS的重要组成部分，如图1所示，TLS协议是由记录层(TLS Record Layer)和握手层(TLS Handshake Layer)组成的。
记录层处于协议的最底层，为TLS协议提供安全可靠的连接，为高层协议提供数据封装、压缩、加密等基本功能的支持。
握手层协议处于记录层协议之上，握手层协议的作用在真正的应用数据传输之前，可以使客户端和服务器互相进行身份认证，协商加密算法以及生成加密密钥。一般来说，最大的TLS Record的大小为16KB，而每个TLS Record包含一个5Byte的头部。
记录协议负责在传输连接上交换的所有底层消息，并且可以配置加密。每一条TLS记录以一个短标头开始。标头包含记录内容的类型(或子协议)、协议版本和长度。原始消息经过分段(或者合并)、压缩、添加认证码、加密转为TLS记录的数据部分。
所有的TLS上层数据(包含TLS握手协议消息以及更上层的应用协议数据)都由TLSRecord来封装和传输。
图2示意性示出了根据本公开实施例的TLS Record协议的消息封装流程图。
如图2所示，一个消息会在TLS Record协议层被分段，然后对每个分段分别压缩和加密，最后加上TLS Record协议头再通过网络层发送出去。
TCP(Transmission Control Protocol传输控制协议)是一种面向连接(连接导向)的、可靠的、基于IP的传输层协议。TLS是建立在可靠的数据传输的基础之上，运行在TCP层之上，一个TLS Record Size由多个TCP包组成。
TLS/SSL数据加解密是基于分段的，接收方收到一个完整的分段才能够进行解密，如果分段过大，那接收方必须要等到接收完整个分段的数据才能解密，当网络不好出现丢包、拥塞、重传等等情况下会严重影响时延，如果分段过小，头部负载比重就会较大，影响吞吐率。所以，怎么分段就比较关键，也就是TLS Record Size大小多少合适。这就涉及到两个重要的指标：时延和吞吐率。也即，如果TLS Record Size设置的较大，单个Record会在TCP层拆成多个包发送，那么时延就会增大，而由于Record头部占比较小，吞吐率却会增加，而TLS Record Size如果设置的较小，单个的Record在TCP层存在于一个包中，时延就会比较小，而由于Record头部占比较大，吞吐率却会下降。
在连接的不同时机，对性能的要求也不一样。用户发起访问一个https网页，需要尽快看到网页，就会对时延比较敏感。在TCP连接刚开始时，会产生TCP慢启动(SlowStart)，这使得被划分为多个TCP段的TLS记录只能缓慢交付。在整个TCP连接中，组成TLS记录的任何一个TCP段的丢失，都会导致整个记录被延迟，直到丢失的段被重传。
因此，不要使用固定的TLS记录大小，而是根据TCP连接速度的提升(或者收到拥塞控制而下降)动态调整记录大小。在每个连接刚开始时，使用较小的记录大小，使之能与TCP能够发送的大小相匹配。一旦连接运行起来，就可以增加记录大小。
图3示意性示出了根据本公开实施例的数据传输方法的应用场景图。
如图3所示，根据该实施例的应用场景100可以包括一种用于业务系统的数据考核方法。网络104用以在终端设备101、102、103和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。
用户可以使用终端设备101、102、103通过网络104与服务器105交互，以接收或发送消息等。终端设备101、102、103上可以安装有各种通讯客户端应用，例如购物类应用、网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等(仅为示例)。
终端设备101、102、103可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。
服务器105可以是提供各种服务的服务器，例如对用户利用终端设备101、102、103所浏览的网站提供支持的后台管理服务器(仅为示例)。后台管理服务器可以对接收到的用户请求等数据进行分析等处理，并将处理结果(例如根据用户请求获取或生成的网页、信息、或数据等)反馈给终端设备。
需要说明的是，本公开实施例所提供的一种用于业务系统的数据考核方法一般可以由服务器105执行。本公开实施例所提供的一种用于业务系统的数据考核方法也可以由不同于服务器105且能够与终端设备101、102、103和/或服务器105通信的服务器或服务器集群执行。
应该理解，图3中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。
以下将基于图3描述的场景，通过图4～图5对公开实施例的用于业务系统的数据考核方法进行详细描述。
图4示意性示出了根据本公开实施例的数据传输方法的流程图。
有鉴于此，本公开的实施例提供一种数据传输方法，如图3所示，包括：S1，获取待封装的数据，对所述待封装的数据进行分段，依次形成至少一个第一数据段和至少一个第二数据段；其中，所述至少一个第一数据段的数据长度较所述至少一个第二数据段的数据长度小；S2，对所述至少一个第一数据段和至少一个第二数据段分别进行加密。
由于传输控制协议(TCP)具有拥塞控制机制，因此，在TCP连接刚开始的慢启动阶段，拥塞窗口较小，这时较大的TLS Record Size会导致TLS Record片段被TCP分成多个包来发送，从而导致时延较大，可能就会影响网页的首屏时间，因此需要我们将每一段的数据长度设置得比较小，这样就可以和能与TCP能够发送的大小相匹配。一旦连接运行起来，就可以增加分段的数据长度。这样能在保证数据传输前期时延的情况下，增加吞吐率。因此，本发明中所公开的数据传输方法，适配了传输控制协议(TCP)具有拥塞控制机制的特性，在TCP连接刚开始的慢启动阶段，待封装的数据分段成为数据长度较小的第一数据段，运行起来之后，待封装的数据分段成为数据长度较大的第二数据段。传输数据的长度与TCP能够发送的大小相匹配，能在保证数据传输前期时延的情况下，增加了吞吐率。
在一些实施例中，所述S1中，所述至少一个第一数据段的大小为MTU与Record头部和TCP头部的差值，所述至少一个第二数据段的大小为16KB。
如果关心时延，也并非TLS Record Size越小越好。同样一个TCP包，包的长度并不会影响传输时间，都是一个RTT。但是TLS Record Size越小，Record头部越大，会导致吞吐率下降。所以在时延敏感的情况下，Record size的大小建议是MTU-Record头部-IP/TCP头部。在吞吐率敏感的情况下，是TLS Record Size越大，Record头部的占比越小，吞吐率会越高。所以在吞吐率敏感的情况下，TLS Record Size的大小建议设置成最大值16kb。
因此，在动态调整TLS Record Size的大小的值的时候，所选用的最小数据内存为第一数据段的大小，也即MTU-Record头部-TCP头部，最大数据内存为最大值16kb。
在一些实施例中，所述S1还包括：所述至少一个第一数据段和至少一个第二数据段依次传输，当所述至少一个第二数据段无法传输，对所述第二数据段的内容以第一数据段的数据长度为分段长度重新进行分段。
在这些实施例中，在连接是idle状态且持续了一段时间，会重新开始发送第一数据段大小的数据包，然后再从S1开始循环。
同时，在一些实施例中，所述S1还包括：对所述待封装的数据依照输入顺序进行分段，依次形成至少一个第一数据段、至少一个第三数据段和至少一个第二数据段；其中，所述至少一个第三数据段的数据长度位于所述至少一个第一数据段的数据长度和所述至少一个第二数据段的数据长度之间。且第三数据段的个数与第一数据段的个数相同。
这样的方法包括以下配置过程：对于一个新连接，先通过配置ssl_rec_size_lo，采用一个较小的TLS Record Size，也即MTU-Record头部-TCP头部，发送ssl_dyn_rec_threshold个包的Record后，形成若干第一数据段；然后通过配置ssl_dyn_rec_size_hi，切换为采用更大的Record Size。再发送ssl_dyn_rec_threshold个包的Record后，形成若干第三数据段，最后，通过配置ssl_buffer_size，使得TLS Record Size转换为最大的16KB。
在上一段的基础上，如果应用层过了ssl_dyn_rec_timeout个时间内，没法送过数据，将record size设置为为ssl_dyn_rec_size_lo，重复上段步骤。
在整个TCP数据传输过程中，可能启动拥塞避免算法，也可能遇到数据丢失和重传的情况，然后又重新进入慢启动阶段。因此，ssl_dyn_rec_timeout是有必要的，TCP协议也有类似的操作，socket如果idle了一定时间，其cwnd也会被设置为初始值，设置也契合了TCP特性。这样在不同场景下根据TLS Record Size变化实现基于可变TRS的加密域名系统的性能优化。
在一些实施例中，所述S2还包括：当所述至少一个第一数据段和至少一个第二数据段满足第一条件的情况下，使用第一方法进行加密；当所述至少一个第一数据段和至少一个第二数据段满足第二条件的情况下，使用第二方法进行加密。
当所述至少一个第一数据段和至少一个第二数据段为请求报文时，则代表其满足第一条件；当所述至少一个第一数据段和至少一个第二数据段为响应报文时，则代表其满足第二条件。
其中，第一方法较第二方法加密过程更复杂，所述第一方法为非对称加密；所述第二方法为对称加密。
DoT是DNS-over-TLS协议的简称，DoT基于TLS来进行报文加密的DNS请求交互，TLS用于在两个通信应用程序之间提供保密性和数据完整性，最著名的用途即我们常见的HTTPS。DoH是DNS-over-HTTPS协议的简称，用于在进行DNS查询时通过加密方式发送数据保护用户隐私，通过HTTPS协议进行DNS解析。DoH增加对用户的隐私的保护，这种方法有助于避免访问的网站被运营商或中间人窃取，同时也可以避免被中间人劫持和篡改。
而在数据交互过程中，请求语句通常较短，转换的请求语句数据包内存较小，为小文件，而响应语句通常较长，转换的请求语句数据包内存较大，为大文件，因此，通过对请求和响应采用不同的策略可以达到性能的优化。
TLS通讯主要是交换秘钥和加密数据，TLS服务器在握手的时候，主要看它的椭圆加密算法和RSA非对称加密算法这样的性能，因此，当待加密的数据文件为小文件时，主要考虑的是TLS服务器的非对称加密的性能，比如RSA；当处理大文件时，主要考虑对称加密算法的性能，比如AES。
对称加密算法采用单钥密码系统的加密方法，同一个密钥可以同时用作信息的加密和解密，由于其速度快，对称性加密通常在消息发送方需要加密大量数据时使用。对称性加密也称为密钥加密。
与对称加密算法不同，非对称加密算法需要两个密钥：公开密钥(publickey)和私有密钥(privatekey)。公开密钥与私有密钥是一对，如果用公开密钥对数据进行加密，只有用对应的私有密钥才能解密；如果用私有密钥对数据进行加密，那么只有用对应的公开密钥才能解密。因为加密和解密使用的是两个不同的密钥，所以这种算法叫作非对称加密算法。
因此，对称加密算法速度快，适合大文件的加密，而非对称加密安全性高，适合小文件的加密。
由于请求包通常以小文件为主，因此应当使用加密过程更为复杂的非对称加密对其进行加密。而响应包通常以大文件为主，为考虑响应时间，因此加密过程应以相对简单的对称加密来进行。这样有针对性地设置请求包和响应包的加密类型，使得加密过程更合理，在保证响应速度的情况下，还保证了传输的安全性。
图5示意性示出了根据本公开实施例的适于实现数据传输方法的方框图。
本公开的实施例还提供一种电子设备，如图5所示，包括：一个或多个处理器；存储装置，用于存储一个或多个程序，其中，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器执行上述数据传输方法。
根据本公开实施例的电子设备200包括处理器201，其可以根据存储在只读存储器(ROM)202中的程序或者从存储部分208加载到随机访问存储器(RAM)203中的程序而执行各种适当的动作和处理。处理器201例如可以包括通用微处理器(例如CPU)、指令集处理器和/或相关芯片组和/或专用微处理器(例如，专用集成电路(ASIC))等等。处理器201还可以包括用于缓存用途的板载存储器。处理器201可以包括用于执行根据本公开实施例的方法流程的不同动作的单一处理单元或者是多个处理单元。
在RAM 203中，存储有电子设备200操作所需的各种程序和数据。处理器201、ROM202以及RAM 203通过总线204彼此相连。处理器201通过执行ROM 202和/或RAM 203中的程序来执行根据本公开实施例的方法流程的各种操作。需要注意，所述程序也可以存储在除ROM 202和RAM 203以外的一个或多个存储器中。处理器201也可以通过执行存储在所述一个或多个存储器中的程序来执行根据本公开实施例的方法流程的各种操作。
根据本公开的实施例，电子设备200还可以包括输入/输出(I/O)接口205，输入/输出(I/O)接口205也连接至总线204。电子设备200还可以包括连接至I/O接口205的以下部件中的一项或多项：包括键盘、鼠标等的输入部分206；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分207；包括硬盘等的存储部分208；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分209。通信部分209经由诸如因特网的网络执行通信处理。驱动器210也根据需要连接至I/O接口205。可拆卸介质211，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器210上，以便于从其上读出的计算机程序根据需要被安装入存储部分208。
本公开的实施例还提供一种计算机可读存储介质，其上存储有可执行指令，该指令被处理器执行时使处理器执行上述数据传输方法。
该计算机可读存储介质可以是上述实施例中描述的设备/装置/系统中所包含的；也可以是单独存在，而未装配入该设备/装置/系统中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或者多个程序被执行时，实现根据本公开实施例的方法。
根据本公开的实施例，计算机可读存储介质可以是非易失性的计算机可读存储介质，例如可以包括但不限于：便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。例如，根据本公开的实施例，计算机可读存储介质可以包括上文描述的ROM 202和/或RAM 203和/或ROM 202和RAM 203以外的一个或多个存储器。
本公开的实施例还提供一种计算机程序产品，其特征在于，包括计算机程序，所述计算机程序被处理器执行时实现上述数据传输方法。
在该计算机程序被处理器201执行时执行本公开实施例的系统/装置中限定的上述功能。根据本公开的实施例，上文描述的系统、装置、模块、单元等可以通过计算机程序模块来实现。
在一种实施例中，该计算机程序可以依托于光存储器件、磁存储器件等有形存储介质。在另一种实施例中，该计算机程序也可以在网络介质上以信号的形式进行传输、分发，并通过通信部分209被下载和安装，和/或从可拆卸介质211被安装。该计算机程序包含的程序代码可以用任何适当的网络介质传输，包括但不限于：无线、有线等等，或者上述的任意合适的组合。
在这样的实施例中，该计算机程序可以通过通信部分209从网络上被下载和安装，和/或从可拆卸介质211被安装。在该计算机程序被处理器201执行时，执行本公开实施例的系统中限定的上述功能。根据本公开的实施例，上文描述的系统、设备、装置、模块、单元等可以通过计算机程序模块来实现。
根据本公开的实施例，可以以一种或多种程序设计语言的任意组合来编写用于执行本公开实施例提供的计算机程序的程序代码，具体地，可以利用高级过程和/或面向对象的编程语言、和/或汇编/机器语言来实施这些计算程序。程序设计语言包括但不限于诸如Java，C++，python，“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。
附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。
以上所述的具体实施例，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施例而已，并不用于限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种数据传输方法，其特征在于，包括：
S1，获取待封装的数据，对所述待封装的数据进行分段，依次形成至少一个第一数据段和至少一个第二数据段；其中，所述至少一个第一数据段的数据长度较所述至少一个第二数据段的数据长度小；
S2，对所述至少一个第一数据段和至少一个第二数据段分别进行加密。
2.根据权利要求1所述的数据传输方法，其特征在于，所述S1中，所述至少一个第一数据段的大小为MTU与Record头部和TCP头部的差值，所述至少一个第二数据段的大小为16KB。
3.根据权利要求1所述的数据传输方法，其特征在于，所述S1还包括：所述至少一个第一数据段和至少一个第二数据段依次传输，当所述至少一个第二数据段无法传输，对所述第二数据段的内容以第一数据段的数据长度为分段长度重新进行分段。
4.根据权利要求1所述的数据封装方法，其特征在于，所述S2还包括：
当所述至少一个第一数据段和至少一个第二数据段满足第一条件的情况下，使用第一方法进行加密；
当所述至少一个第一数据段和至少一个第二数据段满足第二条件的情况下，使用第二方法进行加密。
5.根据权利要求4所述的数据封装方法，其特征在于，当所述至少一个第一数据段和至少一个第二数据段为请求报文时，则代表其满足第一条件；当所述至少一个第一数据段和至少一个第二数据段为响应报文时，则代表其满足第二条件。
6.根据权利要求5所述的数据封装方法，其特征在于，所述第一方法较第二方法加密过程更复杂。
7.根据权利要求6所述的数据封装方法，其特征在于，所述第一方法为非对称加密；所述第二方法为对称加密。
8.一种电子设备，其特征在于，包括：
一个或多个处理器；
存储装置，用于存储一个或多个程序，
其中，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器执行根据权利要求1～7中任一项所述的方法。
9.一种计算机可读存储介质，其特征在于，其上存储有可执行指令，该指令被处理器执行时使处理器执行根据权利要求1～7中任一项所述的方法。
10.一种计算机程序产品，其特征在于，包括计算机程序，所述计算机程序被处理器执行时实现根据权利要求1～7中任一项所述的方法。
CN202111625151.2A 2021-12-28 2021-12-28 数据传输方法、设备、介质和产品 Pending CN114500399A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202111625151.2A CN114500399A (zh) 2021-12-28 2021-12-28 数据传输方法、设备、介质和产品

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202111625151.2A CN114500399A (zh) 2021-12-28 2021-12-28 数据传输方法、设备、介质和产品

Publications (1)

Publication Number Publication Date
CN114500399A true CN114500399A (zh) 2022-05-13

Family

ID=81495253

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202111625151.2A Pending CN114500399A (zh) 2021-12-28 2021-12-28 数据传输方法、设备、介质和产品

Country Status (1)

Country Link
CN (1) CN114500399A (zh)

Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1957579A (zh) * 2004-03-22 2007-05-02 高通股份有限公司 网络链路上的http加速
CN101557607A (zh) * 2009-05-15 2009-10-14 东南大学 无线传感器网络中汇聚节点的传输控制方法
CN101616077A (zh) * 2009-07-29 2009-12-30 武汉大学 互联网大文件的快速传输方法
CN101854738A (zh) * 2010-05-21 2010-10-06 南京邮电大学 一种用于卫星网络的传输控制协议方法
CN103929370A (zh) * 2013-01-11 2014-07-16 中国科学院声学研究所 一种用于带宽预留网络的tcp拥塞控制方法
CN107645409A (zh) * 2017-08-18 2018-01-30 上海华为技术有限公司 一种确定数据的传输故障原因方法及装置
CN108574644A (zh) * 2017-09-15 2018-09-25 北京金山云网络技术有限公司 一种tcp连接恢复方法、装置、电子设备及存储介质
CN108833996A (zh) * 2018-07-03 2018-11-16 湖北大学 分布式dash系统中服务节点选择、更新和码率自适应方法
CN112019332A (zh) * 2020-08-26 2020-12-01 平安国际智慧城市科技股份有限公司 基于微服务的加解密方法、api网关系统及设备
CN112953850A (zh) * 2021-04-06 2021-06-11 腾讯科技（深圳）有限公司 数据传输方法、装置、计算机可读介质及电子设备

Patent Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1957579A (zh) * 2004-03-22 2007-05-02 高通股份有限公司 网络链路上的http加速
CN101557607A (zh) * 2009-05-15 2009-10-14 东南大学 无线传感器网络中汇聚节点的传输控制方法
CN101616077A (zh) * 2009-07-29 2009-12-30 武汉大学 互联网大文件的快速传输方法
CN101854738A (zh) * 2010-05-21 2010-10-06 南京邮电大学 一种用于卫星网络的传输控制协议方法
CN103929370A (zh) * 2013-01-11 2014-07-16 中国科学院声学研究所 一种用于带宽预留网络的tcp拥塞控制方法
CN107645409A (zh) * 2017-08-18 2018-01-30 上海华为技术有限公司 一种确定数据的传输故障原因方法及装置
CN108574644A (zh) * 2017-09-15 2018-09-25 北京金山云网络技术有限公司 一种tcp连接恢复方法、装置、电子设备及存储介质
CN108833996A (zh) * 2018-07-03 2018-11-16 湖北大学 分布式dash系统中服务节点选择、更新和码率自适应方法
CN112019332A (zh) * 2020-08-26 2020-12-01 平安国际智慧城市科技股份有限公司 基于微服务的加解密方法、api网关系统及设备
CN112953850A (zh) * 2021-04-06 2021-06-11 腾讯科技（深圳）有限公司 数据传输方法、装置、计算机可读介质及电子设备

Similar Documents

Publication Publication Date Title
CN106713320B (zh) 终端数据传输的方法和装置
CN111628976B (zh) 一种报文处理方法、装置、设备及介质
CA2598227C (en) Mapping an encrypted https network packet to a specific url name and other data without decryption outside of a secure web server
US20210168088A1 (en) Discovery and Adjustment of Path Maximum Transmission Unit
CN111756751B (zh) 报文传输方法、装置及电子设备
US20120023158A1 (en) Method for secure transfer of multiple small messages
US20180375648A1 (en) Systems and methods for data encryption for cloud services
US20040088539A1 (en) System and method for securing digital messages
US11575662B2 (en) Transmitting and storing different types of encrypted information using TCP urgent mechanism
US11070533B2 (en) Encrypted server name indication inspection
CN116418590A (zh) 用于安全套接字层代理的自适应控制的方法、网络设备以及非瞬态计算机可读介质
CN111586072A (zh) 一种数据传输方法、装置、电子设备及存储介质
US20210281608A1 (en) Separation of handshake and record protocol
CN111163102B (zh) 数据处理方法及装置、网络设备、可读存储介质
US8281123B2 (en) Apparatus and method for managing and protecting information during use of semi-trusted interfaces
CN107343001B (zh) 数据处理方法及装置
US10231004B2 (en) Network recording service
CN114500399A (zh) 数据传输方法、设备、介质和产品
US20210281607A1 (en) Zero round trip time transmission for anticipatory request messages
CN110808993A (zh) 数据传输控制方法、装置、计算机系统和介质
CN111970281B (zh) 基于验证服务器的路由设备远程控制方法、系统及电子设备
CN114726564B (zh) 安全检测方法、安全检测装置、电子设备及介质
US20240007448A1 (en) Inflight network data encryption
CN111526128B (zh) 一种加密管理的方法和装置
WO2024032313A1 (en) Distribution of private session key and offloading protocol stack to network communication device for secured communications

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