CN111031065B - 一种文件传输方法、系统、客户端及防火墙 - Google Patents

一种文件传输方法、系统、客户端及防火墙 Download PDF

Info

Publication number
CN111031065B
CN111031065B CN201911359604.4A CN201911359604A CN111031065B CN 111031065 B CN111031065 B CN 111031065B CN 201911359604 A CN201911359604 A CN 201911359604A CN 111031065 B CN111031065 B CN 111031065B
Authority
CN
China
Prior art keywords
session
message
port number
plaintext
ciphertext
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.)
Active
Application number
CN201911359604.4A
Other languages
English (en)
Other versions
CN111031065A (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.)
Neusoft Corp
Original Assignee
Neusoft 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 Neusoft Corp filed Critical Neusoft Corp
Priority to CN201911359604.4A priority Critical patent/CN111031065B/zh
Publication of CN111031065A publication Critical patent/CN111031065A/zh
Application granted granted Critical
Publication of CN111031065B publication Critical patent/CN111031065B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • 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/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227—Filtering policies
    • H04L63/0236—Filtering by address, protocol, port number or service, e.g. IP-address or URL

Landscapes

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

Abstract

本申请公开一种文件传输方法、系统、客户端及防火墙。客户端对服务器的文件有传输需求时，首先获得保证明文会话和密文会话的左右方向报文均由同一处理器处理的源端口号，其一为明文会话的左方向报文的源端口号，其二为密文会话的左方向报文的源端口号。为传输文件，客户端利用密文会话的左方向报文的源端口号与防火墙之间基于文件传输需求建立密文会话，防火墙解密密文会话的左方向报文能够得到明文会话的左方向报文的源端口号，从而建立明文会话。防火墙能够采用同一处理器处理明文会话和密文会话的左右方向报文。本申请避免倒核操作，提升防火墙的文件传输性能。当参与大文件传输的客户端数量较大时，对防火墙文件传输性能的提升效果十分显著。

Description

一种文件传输方法、系统、客户端及防火墙
技术领域
本申请涉及文件传输技术领域，特别是涉及一种文件传输方法、系统、客户端及防火墙。
背景技术
为保证文件传输的安全性，通常在服务器的前端部署防火墙。对于防火墙而言，最主要的性能开销就是将服务器的大文件(例如视频文件)传输给客户端。在同时进行大文件传输的客户端数量庞大的场景下，防火墙的并发会话数可能达到百万级别。
防火墙通常是多核系统，即带有多个处理器。当同一个大文件的传输会话的右方向和左方向报文分别由两个处理器处理时，需要进行倒核。例如，同一会话的左方向数据包被处理器X收到，而右方向数据包被处理器Y收到，需要将右方向数据包从处理器Y转移到处理器X。倒核操作降低了防火墙的大文件传输性能，参与大文件传输的客户端越多，倒核对防火墙性能的影响越大。
发明内容
基于上述问题，本申请提供了一种文件传输方法、系统、客户端及防火墙，保证文件传输的明文会话的两个方向报文及密文会话的两个方向报文被防火墙的同一处理器处理，避免倒核操作，提升防火墙的大文件传输性能。
本申请实施例公开了如下技术方案：
第一方面，本申请提供一种文件传输方法，应用于客户端，基于所述客户端对于服务器的文件的传输需求，所述客户端与防火墙之间建立密文会话，所述防火墙与所述服务器之间建立明文会话；所述防火墙设置于所述服务器前端；所述方法包括：
所述客户端获得所述明文会话的左方向报文的源端口号，并获得所述密文会话的左方向报文的源端口号，以使所述明文会话的左方向报文和右方向报文以及所述密文会话的左方向报文和右方向报文由所述防火墙的同一处理器处理；
所述客户端利用所述密文会话的左方向报文的源端口号建立所述密文会话，并且以使所述防火墙通过解密所述密文会话的左方向报文获得所述明文会话的左方向报文的源端口号，利用所述明文会话的左方向报文的源端口号建立所述明文会话，传输所述文件。
可选地，客户端获得所述明文会话的左方向报文的源端口号，具体包括：
所述客户端获得所述防火墙的关键参数种子值和处理器个数；
所述客户端利用所述关键参数种子值和所述处理器个数，获得当所述明文会话的左方向报文和右方向报文由所述同一处理器处理时所述明文会话的左方向报文的源端口号。
可选地，客户端利用所述关键参数种子值和所述处理器个数，获得当所述明文会话的左方向报文和右方向报文由所述同一处理器处理时所述明文会话的左方向报文的源端口号，具体包括：
所述客户端利用随机函数生成所述明文会话的左方向报文的随机源端口号；
所述客户端利用所述关键参数种子值和所述明文会话的左方向报文的随机源端口号，通过接收端缩放RSS算法得到所述明文会话的左方向RSS值和右方向RSS值；
所述客户端利用所述明文会话的左方向RSS值和右方向RSS值，以及所述处理器个数，确定使所述同一处理器处理所述明文会话的左方向报文和右方向报文时所述明文会话的左方向报文的源端口号。
可选地，客户端利用所述明文会话的左方向RSS值和右方向RSS值，以及所述处理器个数，确定使所述同一处理器处理所述明文会话的左方向报文和右方向报文时所述明文会话的左方向报文的源端口号，具体包括：
所述客户端利用所述明文会话的左方向RSS值和右方向RSS值，以及所述处理器个数，分别得到处理所述明文会话的左方向报文和右方向报文的处理器对应的哈希值；
当所述处理所述明文会话的左方向报文和右方向报文的处理器对应的哈希值相同，且所述随机源端口号未被占用时，则所述客户端将所述处理所述明文会话的左方向报文和右方向报文的处理器作为所述同一处理器，并将所述随机源端口号作为所述明文会话的左方向报文的源端口号。
可选地，上述方法还包括：所述客户端获得所述同一处理器对应的哈希值；
所述客户端获得所述密文会话的左方向报文的源端口号，具体包括：
所述客户端利用所述关键参数种子值和所述同一处理器对应的哈希值，获得当所述密文会话的左方向报文和右方向报文由所述同一处理器处理时所述密文会话的左方向报文的源端口号。
可选地，客户端利用所述关键参数种子值和所述同一处理器对应的哈希值，获得当所述密文会话的左方向报文和右方向报文由所述同一处理器处理时所述密文会话的左方向报文的源端口号，具体包括：
所述客户端利用随机函数生成所述密文会话的左方向报文的随机源端口号；
所述客户端利用所述关键参数种子值和所述密文会话的左方向报文的随机源端口号，通过接收端缩放RSS算法得到所述密文会话的左方向RSS值和右方向RSS值；
所述客户端利用所述密文会话的左方向RSS值和右方向RSS值，以及所述处理器个数，确定使所述同一处理器处理所述密文会话的左方向报文和右方向报文时所述密文会话的左方向报文的源端口号。
可选地，客户端利用所述密文会话的左方向RSS值和右方向RSS值，以及所述处理器个数，确定使所述同一处理器处理所述密文会话的左方向报文和右方向报文时所述密文会话的左方向报文的源端口号，具体包括：
所述客户端利用所述密文会话的左方向RSS值和右方向RSS值，以及所述处理器个数，分别得到处理所述密文会话的左方向报文和右方向报文的处理器对应的哈希值；
当所述处理所述密文会话的左方向报文和右方向报文的处理器对应的哈希值都等于所述同一处理器对应的哈希值，且所述随机源端口号未被占用时，则所述客户端将所述随机源端口号作为所述密文会话的左方向报文的源端口号。
第二方面，本申请提供一种客户端，包括：
端口号获取模块，用于获得明文会话的左方向报文的源端口号，并获得密文会话的左方向报文的源端口号，以使所述明文会话的左方向报文和右方向报文以及所述密文会话的左方向报文和右方向报文由防火墙的同一处理器处理；所述明文会话为所述防火墙与服务器之间基于所述客户端对所述服务器的文件的传输需求建立；所述防火墙设置于所述服务器前端；
文件传输模块，用于利用所述密文会话的左方向报文的源端口号建立所述密文会话，并且以使所述防火墙通过解密所述密文会话的左方向报文获得所述明文会话的左方向报文的源端口号，利用所述明文会话的左方向报文的源端口号建立所述明文会话，传输所述文件。
第三方面，本申请提供一种文件传输方法，应用于防火墙，所述防火墙设置于服务器前端，基于客户端对于所述服务器的文件的传输需求，所述客户端与所述防火墙之间建立密文会话，所述防火墙与所述服务器之间建立明文会话；所述方法包括：
所述防火墙通过解密所述密文会话的左方向报文得到所述明文会话的左方向报文的源端口号；所述明文会话的左方向报文的源端口号，为使所述明文会话的左方向报文和右方向报文以及所述密文会话的左方向报文和右方向报文由所述防火墙的同一处理器处理的源端口号；
所述防火墙基于所述明文会话的左方向报文的源端口号与所述服务器建立连接，创建所述明文会话。
可选地，在所述防火墙通过解密所述密文会话的左方向报文得到所述明文会话的左方向报文的源端口号之前，所述方法还包括：
所述防火墙向所述客户端发送关键参数种子值和处理器个数，以使所述客户端利用所述关键参数种子值和所述处理器个数，获得当所述明文会话的左方向报文和右方向报文由所述同一处理器处理时所述明文会话的左方向报文的源端口号。
可选地，上述方法还包括：
所述防火墙通过解密所述密文会话的左方向报文得到所述同一处理器对应的哈希值；
所述防火墙利用所述哈希值构造密钥；
所述传输所述文件，具体包括：
所述防火墙利用所述密钥对所述服务器发送的所述文件进行加密，向所述客户端发送所述密文会话的右方向报文。
第四方面，本申请提供一种防火墙，其设置于服务器前端，该防火墙包括：
解密模块，用于通过解密所述密文会话的左方向报文得到明文会话的左方向报文的源端口号；所述明文会话的左方向报文的源端口号，为使所述明文会话的左方向报文和右方向报文以及密文会话的左方向报文和右方向报文由所述防火墙的同一处理器处理的源端口号；所述密文会话为客户端与所述防火墙之间基于所述客户端对所述服务器的文件的传输需求建立；
会话建立模块，用于基于所述明文会话的左方向报文的源端口号与所述服务器建立连接，创建所述明文会话。
第五方面，本申请提供一种文件传输系统，包括：客户端，服务器，和设置于服务器前端的防火墙；所述客户端对于服务器的文件具有传输需求；
所述客户端用于获得明文会话的左方向报文的源端口号，并获得密文会话的左方向报文的源端口号；利用所述密文会话的左方向报文的源端口号与所述防火墙建立所述密文会话；所述防火墙用于基于所述传输需求，通过解密所述密文会话的左方向报文获得所述明文会话的左方向报文的源端口号，利用所述明文会话的左方向报文的源端口号与所述服务器建立所述明文会话；
所述防火墙还用于采用同一处理器处理所述明文会话的左方向报文和右方向报文以及所述密文会话的左方向报文和右方向报文，传输所述文件。
相较于现有技术，本申请具有以下有益效果：
客户端对于服务器的文件具有传输需求时，首先获得能够保证明文会话和密文会话的左右方向报文均由同一处理器处理的源端口号，其一为明文会话的左方向报文的源端口号，其二为密文会话的左方向报文的源端口号。为进行文件传输，客户端利用密文会话的左方向报文的源端口号与防火墙之间基于文件传输需求建立密文会话，而防火墙通过解密密文会话的左方向报文能够得到明文会话的左方向报文的源端口号，从而建立明文会话。从而，防火墙能够采用同一处理器处理明文会话和密文会话的左右方向报文。该方法相比于现有技术，避免倒核操作，提升防火墙的文件传输性能。当参与大文件传输的客户端数量较大时，该方法对防火墙文件传输性能的提升效果十分显著。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1为本申请实施例提供的一种文件传输场景示意图；
图2为本申请实施例提供的一种文件传输方法的流程图；
图3a为本申请实施例提供的一种客户端对数据进行加密前后的数据形式的示意图；
图3b为本申请实施例提供的一种明密文会话交互示意图；
图4为本申请实施例提供的另一种文件传输方法的流程图；
图5为本申请实施例提供的一种获取明文会话的左方向报文的源端口号实现方式流程图；
图6为本申请实施例提供的一种获取密文会话的左方向报文的源端口号实现方式流程图；
图7为本申请实施例提供的一种客户端的结构示意图；
图8为本申请实施例提供的又一种文件传输方法的流程图；
图9为本申请实施例提供的一种防火墙的结构示意图。
具体实施方式
为保证文件的安全传输，防止文件泄露，需要在服务器前端部署防火墙，防火墙对服务器提供给客户端的文件进行保护和传递。参见图1，该图所示为本申请实施例提供的一种文件传输场景。防火墙101不但能够与服务器102建立通信连接，还可以与客户端103建立通信连接。对于服务器102的数量以及客户端103的数量均不加以限定。图1中以台式电脑作为客户端103的示例形式，当然，在实际应用中客户端103还可以是移动终端，例如平板电脑、手机等。本申请对客户端103的具体形式不进行限定。实际应用中，服务器102可以根据客户端103的请求，提供多样化的数据，例如可以向用户端103提供视频文件、音频文件、图片等。
对于防火墙而言，最主要的性能消耗在于大文件的传输，其中比较典型的例如视频文件。视频文件的数据量通常在几十MB到几十GB不等。防火墙是多核报文转发系统，如果同时进行大文件传输的用户数量庞多，为保证防火墙并发高性能，需要将会话表设计为独立核资源，将会话表建立在接收文件传输会话的首包的处理器中。为便于描述和理解，本申请中，左方向是指从客户端到服务器的方向；右方向是指从服务器到客户端的方向。由于防火墙设置在服务器前端，因此，从客户端到防火墙，以及从防火墙到服务器的方向均为左方向；从服务器到防火墙，以及从防火墙到客户端的方向均为右方向。对于文件传输会话的首包，其具体的传输方向为左方向。假设左方向的报文由处理器X处理，即处理器X接收到会话的首包，会话表也建立在处理器X中。
目前存在一种可能是，会话右方向的报文被处理器Y接收。由于会话表建立在处理器X中，因此，需要将处理器Y接收到的会话右方向的报文全部送到处理器X中。实际应用中，右方向数据包通常是服务器发送给客户端的大文件，流量非常大。通过研究，发明人发现，需要倒核时防火墙性能相对于无需倒核时防火墙性能下降至少40％。并且，并发的用户数越多，即同时向服务器请求文件传输的客户端数量越多，防火墙因倒核操作受到的性能影响越严重。
针对这一问题，发明人经过研究，提供一种文件传输方法、系统、客户端及防火墙。避免文件传输时防火墙的倒核操作，使防火墙参与大文件传输过程中保持高性能。
为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
在下面的实施例中，首先从客户端的角度，对本申请技术方案进行描述。
方法实施例一
参见图2，该图为本申请实施例提供的一种文件传输方法的流程图。
如图2所示，本实施例提供的文件传输方法，包括：
步骤201：客户端获得所述明文会话的左方向报文的源端口号，并获得所述密文会话的左方向报文的源端口号，以使所述明文会话的左方向报文和右方向报文以及所述密文会话的左方向报文和右方向报文由所述防火墙的同一处理器处理。
可参照图1所示的场景，本实施例中，客户端对服务器具有文件的传输需求。作为示例，该文件可以是某一视频文件、音频文件或图片等。需要说明的是，本实施例中，基于客户端对服务器的文件的传输需求，客户端与防火墙之间建立的会话具体为密文会话，而防火墙与服务器之间建立的会话具体为明文会话。
在左方向，当客户端向服务器请求文件传输(文件下载)时，由客户端的虚拟专用网络(Virtual Private Network,VPN)模块将明文数据进行加密处理，并以公网ip来封装密文。参见图3a，其为本申请实施例提供的一种客户端对数据进行加密前后的数据形式的示意图。根据图3a可以发现，加密前数据时明文数据，加密后数据是密文数据；加密前明文会话的左方向报文的源端口号sport1和目的端口号dport1均已准备就绪，加密后四层首部为密文会话的左方向报文的源端口号sport和目的端口号dport；加密前IP首部的IP地址分别是源地址sip1和目的地址dip1，加密后IP首部的IP地址分别是源地址sip和目的地址dip。可以理解的是，当防火墙对密文解密便可相应地获得加密前四层首部的sport1和dport1。
为描述方便，将左方向的密文报文称为密文会话的左方向报文，相应地，将右方向的密文报文称为密文会话的右方向报文。密文会话的左方向报文以公网ip从客户端发送至防火墙。当防火墙接收到密文会话的左方向报文后，将密文解密后以明文形式发送给服务器。为描述方便，将左方向的明文报文称为明文会话的左方向报文，相应地，将右方向的明文报文称为明文会话的右方向报文。也就是说，明文会话的左方向报文以内网ip从防火墙发送至服务器。
为便于理解本步骤，可参见图3b，该图为本申请实施例提供的一种明密文会话交互示意图。图3b中，客户端301经过防火墙302与服务器303建立传输。
密文五元组A表示从客户端301到防火墙302的五元组，利用密文五元组A从客户端301发往防火墙302的报文为密文会话的左方向报文；
明文五元组B表示从防火墙302到服务器303的五元组，利用明文五元组B从防火墙302发往服务器303的报文为明文会话的左方向报文；
明文五元组C表示从服务器303到防火墙302的五元组，利用明文五元组C从服务器303发往防火墙302的报文为明文会话的右方向报文；
密文五元组D表示从防火墙302到客户端301的五元组，利用密文五元组D从防火墙302发往客户端301的报文为密文会话的右方向报文。
其中，密文五元组A、明文五元组B、明文五元组C以及密文五元组D中的协议未在图中示出，仅在图中示出其他四元，即源ip、源端口号、目的ip和目的端口号。
客户端301的公网ip表示为sip，即密文五元组A的源ip，同时也是密文五元组D的目的ip；
防火墙302的内网ip表示为sip1，即明文五元组B的源ip，同时也是明文五元组C的目的ip；
防火墙302与客户端301通信的ip表示为dip，即密文五元组A的目的ip，同时也是密文五元组D的源ip；
服务器303的ip表示为dip1，即明文五元组B的目的ip，同时也是明文五元组C的源ip。
在本实施例中，以sport表示密文会话的左方向报文的源端口号，同时sport也是密文会话的右方向报文的目的端口号；以sport1表示明文会话的左方向报文的源端口号，同时sport1也是明文会话的右方向报文的目的端口号。
本步骤的执行目的是获得sport和sport1，要求sport和sport1能够使所述明文会话的左方向报文和右方向报文以及所述密文会话的左方向报文和右方向报文由所述防火墙302的同一处理器处理。需要说明的是，本步骤执行之前，客户端301与防火墙302之间的密文会话并未真实建立；防火墙302与服务器303之间的明文会话也未真实建立。也就是说，本步骤是在明密文会话真实建立之前，为保证明文会话的左方向报文和右方向报文以及所述密文会话的左方向报文和右方向报文由所述防火墙302的同一处理器处理，预先获得能够满足这一要求的sport和sport1。
现存的问题是防火墙在处理文件传输的报文时，右方向报文和左方向报文分别由防火墙的不同处理器处理，为此才导致倒核操作成为了必然操作。为了克服该问题，只需获得能够满足明文会话的左方向报文和右方向报文以及密文会话的左方向报文和右方向报文由防火墙302的同一处理器处理这一条件的sport和sport1，利用满足此条件的sport和sport1便可避免防火墙302执行倒核操作。
步骤202：客户端利用所述密文会话的左方向报文的源端口号建立所述密文会话，并且以使所述防火墙通过解密所述密文会话的左方向报文获得所述明文会话的左方向报文的源端口号，利用所述明文会话的左方向报文的源端口号建立所述明文会话，传输所述文件。
在上一步骤，客户端301已经获得明文会话的左方向报文的源端口号sport1，以及密文会话的左方向报文的源端口号sport。为使防火墙302建立明文会话，避免倒核操作的执行，客户端301还需通过与防火墙302构建密文会话，从而使防火墙302得以解密密文获得前一步获得的明文会话的左方向报文的源端口号，进而以便防火墙302与服务器303据其建立文件传输的明文会话。此处，文件即是客户端301向服务器303请求传输(请求下载)的文件。
通过建立明文会话和密文会话，实现文件传输。文件传输的具体过程是：客户端301以sport向防火墙302传递加密形式的报文(密文会话的左方向报文)，防火墙302对该报文进行解密获得sport1，并以sport1向服务器303发送解密获得报文(明文会话的左方向报文)。服务器303根据接收到的明文会话的左方向报文，通过权限认证确认发送请求的客户端301提供的用户身份是否具备下载文件的权限，权限认证通过的情况下，服务器303向防火墙发送明文会话的右方向报文以传输该文件。防火墙302为保证文件传输的安全性，执行加密处理，将文件通过密文会话的右方向报文以加密的形式发送给客户端301。
以上即为本申请实施例提供的一种文件传输方法。该方法中，客户端对于服务器的文件具有传输需求时，首先获得能够保证明文会话和密文会话的左右方向报文均由同一处理器处理的源端口号，其一为明文会话的左方向报文的源端口号，其二为密文会话的左方向报文的源端口号。为进行文件传输，客户端利用密文会话的左方向报文的源端口号与防火墙之间基于文件传输需求建立密文会话，而防火墙通过解密密文会话的左方向报文能够得到明文会话的左方向报文的源端口号，从而建立明文会话。从而，防火墙能够采用同一处理器处理明文会话和密文会话的左右方向报文。将防火墙的相关资源局部化，提升整体性能。该方法相比于现有技术，避免倒核操作，提升防火墙的文件传输性能。当参与大文件传输的客户端数量较大时，该方法对防火墙文件传输性能的提升效果十分显著。远超过对防火墙硬件配置进行更改所带来的性能提升效果。
实际应用中，防火墙302能够向客户端301提供辅助其设计满足要求的sport及sport1的有效参数。下面结合实施例和附图，仍从客户端的角度，就本申请提供的另一种文件传输方法进行说明。
方法实施例二
参见图4，该图为本申请实施例提供的另一种文件传输方法的流程图。
如图4所示，本实施例提供的文件传输方法，包括：
步骤401：客户端获得防火墙的关键参数种子值和处理器个数。
客户端301可以向防火墙302发出请求，以获取防火墙302的一些基本参数。本实施例中，主要应用接收端缩放(receive side scaling,RSS)算法来设计明文会话的左方向报文的源端口号sport1以及密文会话的左方向报文的源端口号sport。为此，客户端301向防火墙302请求的基本参数包括：关键参数种子值和处理器个数。
本实施例中，防火墙302的关键参数种子值表示为key_seed。key_seed是320位，即40个字节。作为一种可能的实现方式，防火墙302的key_seed可以是供应防火墙302的厂商设置的默认关键参数种子值，也可以是预先根据实际需求为防火墙302配置好的。当客户端301向防火墙302请求key_seed时，防火墙302即可将自身的key_seed发送给客户端301。对于本领域技术人员，如何利用客户端获取防火墙的关键参数种子值属于比较成熟的技术，在此不做详述。
实际应用中，防火墙302有多个转发核，即有多个处理器。假设本实施例中防火墙302的处理器个数为N，分别是CPU1、CPU2、CPU3、…、CPUN。客户端301通过向防火墙302发送对于其基本信息的请求，即可获得防火墙302的处理器个数N。
通常而言，具有N个处理器的防火墙302支持网卡多队列，使用RSS算法可以将不同报文分配给不同的处理器处理。假设共有M个网卡，每个网卡建立与防火墙302的处理器个数等同数目的接收队列和发送队列，即N个接收队列和N个发送队列。可以预先将处理器的CPU配置为与队列的标识相关，该标识可以是队列的序数。
例如，CPU1配置为处理网卡1、网卡2、…、网卡M的第1个队列；
CPU2配置为处理网卡1、网卡2、…、网卡M的第2个队列；
CPU3配置为处理网卡1、网卡2、…、网卡M的第3个队列；
…
CPUN配置为处理网卡1、网卡2、…、网卡M的第N个队列。
key_seed是应用RSS算法的一个基本参数，结合某一报文的源ip、源端口号、目的ip和目的端口号，能够得到该报文的RSS值。利用RSS值和防火墙的处理器个数，可以得到一个哈希值，该哈希值指示队列。例如，哈希值为1就将报文发送给队列1，基于上述配置，需该报文分配给CPU1处理；同理，哈希值为2就将报文发送给队列2，基于上述配置，需该报文分配给CPU2处理；哈希值为N就将报文发送给队列N，基于上述配置，需该报文分配给CPUN处理。
前面简单介绍了利用RSS算法将报文分配给CPU的实现方式。
实际应用中，明文会话的五元组是早于密文会话的五元组构建的。为使sport1和sport满足所述明文会话的左方向报文和右方向报文以及所述密文会话的左方向报文和右方向报文由所述防火墙的同一处理器处理这一要求，首先要求明文会话的左方向报文和右方向报文由同一处理器处理，得到sport1；再要求密文会话的左方向报文和右方向报文也由该同一处理器处理，得到sport。基于利用RSS算法将报文分配给CPU的实现方式，下面结合步骤402-404具体描述对于sport1以及sport的设计过程。
步骤402：客户端利用所述关键参数种子值和所述处理器个数，获得当所述明文会话的左方向报文和右方向报文由所述同一处理器处理时所述明文会话的左方向报文的源端口号。
本步骤描述对sport1的获取流程，具体可以通过以下步骤4021-4023实现。参见图5，该图为本申请实施例提供的一种获取明文会话的左方向报文的源端口号实现方式流程图。
步骤4021：客户端利用随机函数生成所述明文会话的左方向报文的随机源端口号。
结合上文对于利用RSS算法将报文分配给CPU的实现方式的介绍，可知为获得RSS值，需要以报文的源ip、源端口号、目的ip和目的端口号作为数据基础进行运算。结合图3b可知，本实施例中明文会话的左方向报文的源ip、源端口号、目的ip和目的端口号分别表示为sip1，sport1，dip1和dport1。步骤402的目的是获得sport1，在实现之前，采用了一个随机的源端口号。为方便描述和区分，本实施例将明文会话的左方向报文的随机源端口号记为：sport1_r。
作为一种实现方式，可以采用随机函数来生成sport1_r，已确定的sip1，dip1和dport1作为生成sport1_r的数据基础。
步骤4022：客户端利用所述关键参数种子值和所述明文会话的左方向报文的随机源端口号，通过接收端缩放RSS算法得到所述明文会话的左方向RSS值和右方向RSS值。
RSS函数的具体逻辑如下：
For hash-input input[]of length N bytes(8N bits)and a random secretkey
key_seed of 320bits
Result＝0；
For each bit b in input[]{
if(b＝＝1)then Result^＝(left-most 32bits of key_seed)；
shift key_seed left 1bit position；
}
return Result；
在上面的函数逻辑中，Result为RSS值。以ipv4报文为示例，上述函数逻辑中，函数的输入input[]为明文会话的左方向报文ip首部的第12-23字节(共12个字节)，即sip1，dip1，sport1_r和dport1：
input[12]＝@12-15,@16-19,@20-21,@22-23.
也就是说，第12-15字节为sip1，第16-19字节为dip1，第20-21字节为sport1_r，第22-23字节为dport1。
应用上述RSS函数逻辑，输入input[12]并以key_seed作为参数，得到RSS值为便于区分，称为明文会话的左方向RSS值。同理，基于明文五元组B和明文五元组C的相互对应关系，相应地，明文会话的右方向报文ip首部第12-23字节(共12个字节)分别是dip1，sip1，dport1和sport1_r。利用该12个字节作为输入，得到的RSS值称为明文会话的右方向RSS值。
步骤4023：客户端利用所述明文会话的左方向RSS值和右方向RSS值，以及所述处理器个数，确定使所述同一处理器处理所述明文会话的左方向报文和右方向报文时所述明文会话的左方向报文的源端口号。
客户端利用所述明文会话的左方向RSS值和右方向RSS值，以及所述处理器个数，分别得到处理所述明文会话的左方向报文和右方向报文的处理器对应的哈希值。
求取哈希值的函数由如下公式表示：
ComputeHash()＝Result mod N 公式(1)
在公式(1)中，Result是应用上述RSS函数逻辑得到的RSS值，N即防火墙302的处理器个数。
将明文会话的左方向RSS值和N代入公式(1)，即可得到明文会话的左方向报文的处理器对应的哈希值，该哈希值表示如下：
ComputeHash(sip1,sport1_r,dip1,dport1,key_seed)
将明文会话的右方向RSS值和N代入公式(1)，即可得到明文会话的右方向报文的处理器对应的哈希值，该哈希值表示如下：
ComputeHash(dip1,dport1,sip1,sport1_r,key_seed)
本实施例中，仅当ComputeHash(sip1,sport1_r,dip1,dport1,key_seed)与ComputeHash(dip1,dport1,sip1,sport1_r,key_seed)相同时，表示明文会话的左方向报文和明文会话的右方向报文由同一处理器处理，否则由不同处理器处理。
需要说明的是，如果ComputeHash(sip1,sport1_r,dip1,dport1,key_seed)与ComputeHash(dip1,dport1,sip1,sport1_r,key_seed)不同，则需要重新生成sport1_r，并重新进行RSS值及哈希值的计算。
实际应用中，有可能ComputeHash(sip1,sport1_r,dip1,dport1,key_seed)与ComputeHash(dip1,dport1,sip1,sport1_r,key_seed)相同，但是端口号sport1_r有可能已被占用。此时，需要更换明文会话的左方向报文的源端口号，即也需要重新生成sport1_r，并重新进行RSS值及哈希值的计算。
当所述处理所述明文会话的左方向报文和右方向报文的处理器对应的哈希值相同，且所述随机源端口号未被占用时，表明明文会话的左方向报文和明文会话的右方向报文由同一处理器处理，当前采用的sport1_r可以作为sport1用以后续使用。
为便于后续描述，将该同一处理器即为CPUS，该CPUS为防火墙302的N个处理器CPU1、CPU2、CPU3、…、CPUN中之一。CPUS可以由ComputeHash(sip1,sport1,dip1,dport1,key_seed)或者ComputeHash(dip1,dport1,sip1,sport1,key_seed)进行确定。这是因为，每个哈希值对应一个唯一的队列标识，而处理器配置为与队列标识相关，因此，根据哈希值相应可以确定处理报文的处理器。
步骤403：客户端获得所述同一处理器对应的哈希值。
CPUS对应的哈希值，即是ComputeHash(sip1,sport1,dip1,dport1,key_seed)或者ComputeHash(dip1,dport1,sip1,sport1,key_seed)。
本步骤可以在步骤402之后执行，也可以在步骤402的执行过程中执行。此处对步骤403和步骤402的先后执行顺序不加以限定。
步骤404：客户端利用所述关键参数种子值和所述同一处理器对应的哈希值，获得当所述密文会话的左方向报文和右方向报文由所述同一处理器处理时所述密文会话的左方向报文的源端口号。
本步骤描述对sport的获取流程，具体可以通过以下步骤4041-4043实现。参见图6，该图为本申请实施例提供的一种获取密文会话的左方向报文的源端口号实现方式流程图。
步骤4041：客户端利用随机函数生成所述密文会话的左方向报文的随机源端口号。
结合上文对于利用RSS算法将报文分配给CPU的实现方式的介绍，可知为获得RSS值，需要以报文的源ip、源端口号、目的ip和目的端口号作为数据基础进行运算。
结合图3b可知，本实施例中密文会话的左方向报文的源ip、源端口号、目的ip和目的端口号分别表示为sip，sport，dip和dport。步骤404的目的是获得sport，在实现之前，采用了一个随机的源端口号。为方便描述和区分，本实施例将密文会话的左方向报文的随机源端口号记为：sport_r。
作为一种实现方式，可以采用随机函数来生成sport_r，已确定的sip，dip和dport作为生成sport_r数据基础。
步骤4042：客户端利用所述关键参数种子值和所述密文会话的左方向报文的随机源端口号，通过接收端缩放RSS算法得到所述密文会话的左方向RSS值和右方向RSS值。
参照步骤4022部分描述过的RSS函数的具体逻辑。为获得密文会话的左方向报文的RSS值，函数的输入input[]为密文会话的左方向报文ip首部的第12-23字节(共12个字节)，即sip，dip，sport_r和dport。
应用前述RSS函数逻辑，输入input[12]并以key_seed作为参数，得到RSS值为便于区分，称为密文会话的左方向RSS值。同理，基于密文五元组A和密文五元组D的相互对应关系，相应地，密文会话的右方向报文ip首部第12-23字节(共12个字节)分别是dip，sip，dport和sport_r。利用该12个字节作为输入，得到的RSS值称为密文会话的右方向RSS值。
步骤4043：客户端利用所述密文会话的左方向RSS值和右方向RSS值，以及所述处理器个数，确定使所述同一处理器处理所述密文会话的左方向报文和右方向报文时所述密文会话的左方向报文的源端口号。
客户端利用所述密文会话的左方向RSS值和右方向RSS值，以及所述处理器个数，分别得到处理所述密文会话的左方向报文和右方向报文的处理器对应的哈希值。
具体地，将密文会话的左方向RSS值和N代入公式(1)，即可得到密文会话的左方向报文的处理器对应的哈希值，该哈希值表示如下：
ComputeHash(sip,sport_r,dip,dport,key_seed)
将密文会话的右方向RSS值和N代入公式(1)，即可得到密文会话的右方向报文的处理器对应的哈希值，该哈希值表示如下：
ComputeHash(dip,dport,sip,sport_r,key_seed)
在步骤403中，已经得到CPUS对应的哈希值，即ComputeHash(sip1,sport1,dip1,dport1,key_seed)或者ComputeHash(dip1,dport1,sip1,sport1,key_seed)。本步骤为获得满足要求的sport，需要保证密文会话的左方向报文和右方向报文的处理器对应的哈希值也要等同于ComputeHash(sip1,sport1,dip1,dport1,key_seed)或者ComputeHash(dip1,dport1,sip1,sport1,key_seed)。如此，保证处理密文会话两方向报文的处理器相同，并且明密文会话的两方向报文的处理器为同一处理器。
实际应用中，对于以下任意一种情况，均需要重新生成sport_r，并重新进行RSS值及哈希值的计算：
情况一：
ComputeHash(sip,sport_r,dip,dport,key_seed)与ComputeHash(dip,dport,sip,sport_r,key_seed)不相等；
情况二：
ComputeHash(sip,sport_r,dip,dport,key_seed)和/或ComputeHash(dip,dport,sip,sport_r,key_seed)与ComputeHash(sip1,sport1,dip1,dport1,key_seed)不相等；
情况三：
ComputeHash(sip,sport_r,dip,dport,key_seed)＝ComputeHash(dip,dport,sip,sport_r,key_seed)＝ComputeHash(sip1,sport1,dip1,dport1,key_seed)，但是sport_r已被占用。
也就是说，当所述处理所述密文会话的左方向报文和右方向报文的处理器对应的哈希值都等于所述同一处理器对应的哈希值，且随机源端口号sport_r未被占用时，客户端可以将所述随机源端口号sport_r作为所述密文会话的左方向报文的源端口号sport。
步骤405：客户端利用所述密文会话的左方向报文的源端口号建立所述密文会话，并且以使所述防火墙通过解密所述密文会话的左方向报文获得所述明文会话的左方向报文的源端口号，利用所述明文会话的左方向报文的源端口号建立所述明文会话，传输所述文件。
本实施例步骤405的实现方式与前述实施例步骤202的实现方式基本相同，因此步骤405的相关描述可参照前述实施例，此处不再赘述。
以上即为本申请实施例提供的文件传输方法。该方法中，客户端从防火墙获得防火墙的关键参数种子值和处理器个数，并利用关键参数种子值和处理器个数得到满足明文会话的左方向报文和右方向报文由同一处理器处理的sport1。接着，客户端利用该同一处理器对应的哈希值、关键参数种子值以及处理器个数，得到满足密文会话的左方向报文和右方向报文由该同一处理器处理的sport。最终，利用sport1使防火墙与服务器建立明文会话，并利用sport使客户端与防火墙建立密文会话，实现客户端所需求的文件的安全传输。
文件传输过程中，对文件进行加密是保障传输安全性的关键。为文件提升传输的安全性，本实施例中，将处理明文会话的右方向报文、明文会话的左方向报文、密文会话的右方向报文和密文会话的左方向报文的同一处理器对应的哈希值，作为构造加密密钥的参数之一。
本实施例中该哈希值可以表示为以下四种形式中任意一种，这是由于通过上面的描述，可以明确以下四者的值相等：
(1)ComputeHash(sip1,sport1,dip1,dport1,key_seed)；
(2)ComputeHash(dip1,dport1,sip1,sport1,key_seed)；
(3)ComputeHash(sip,sport,dip,dport,key_seed)；
(4)ComputeHash(dip,dport,sip,sport,key_seed)。
由于该哈希值没有在客户端301与服务器303之间进行传输，而是通过运算得到，因此将该哈希值作为加密密钥的构造参数之一，能够大大增加密钥被破译的难度，从而提升文件传输的安全性，防止数据被窃取，损害用户利益。
由于文件从服务器303传输到客户端301需要经过防火墙302加密数据，因此，在具体实现时，可以由客户端301向防火墙302发送密文会话的左方向报文时，防火墙302通过解密获得该同一处理器对应的哈希值，进而防火墙302可以根据该哈希值构造密钥并利用该密钥进行所述文件的传输，即防火墙302利用该密钥加密从服务器303向客户端301发送的文件。
基于前述实施例提供的文件传输方法，相应地，本申请还提供一种客户端。下面结合实施例和附图对该客户端的具体实现进行描述。
客户端实施例
参见图7，该图为本申请实施例提供的一种客户端的结构示意图。
如图7所示，本实施例提供的客户端，包括：端口号获取模块701，以及文件传输模块702。
其中，端口号获取模块701，用于获得明文会话的左方向报文的源端口号，并获得密文会话的左方向报文的源端口号，以使所述明文会话的左方向报文和右方向报文以及所述密文会话的左方向报文和右方向报文由防火墙的同一处理器处理；所述明文会话为所述防火墙与服务器之间基于所述客户端对所述服务器的文件的传输需求建立；所述防火墙设置于所述服务器前端；
文件传输模块702，用于利用所述密文会话的左方向报文的源端口号建立所述密文会话，并且以使所述防火墙通过解密所述密文会话的左方向报文获得所述明文会话的左方向报文的源端口号，利用所述明文会话的左方向报文的源端口号建立所述明文会话，传输所述文件。
客户端对于服务器的文件具有传输需求时，由端口号获取模块701首先获得能够保证明文会话和密文会话的左右方向报文均由同一处理器处理的源端口号，其一为明文会话的左方向报文的源端口号，其二为密文会话的左方向报文的源端口号。为进行文件传输，客户端利用密文会话的左方向报文的源端口号与防火墙之间基于文件传输需求建立密文会话，而防火墙通过解密密文会话的左方向报文能够得到明文会话的左方向报文的源端口号，从而建立明文会话。从而，防火墙能够采用同一处理器处理明文会话和密文会话的左右方向报文。该客户端避免了防火墙的倒核操作，提升防火墙的文件传输性能。当参与大文件传输的客户端数量较大时，该客户端对防火墙文件传输性能的提升效果十分显著。
防火墙能够向客户端提供有效参数，以辅助其设计满足要求的明文会话的左方向报文的源端口号sport1及密文会话的左方向报文的源端口号sport。因此可选地，端口号获取模块701，具体包括：
参数值获取子模块，用于获得所述防火墙的关键参数种子值和处理器个数；
端口号第一获取子模块，用于利用所述关键参数种子值和所述处理器个数，获得当所述明文会话的左方向报文和右方向报文由所述同一处理器处理时所述明文会话的左方向报文的源端口号。
可选地，端口号第一获取子模块，具体包括：
端口号第一生成单元，用于利用随机函数生成所述明文会话的左方向报文的随机源端口号；
RSS值第一获取单元，用于利用所述关键参数种子值和所述明文会话的左方向报文的随机源端口号，通过接收端缩放RSS算法得到所述明文会话的左方向RSS值和右方向RSS值；
端口号第一获取单元，用于利用所述明文会话的左方向RSS值和右方向RSS值，以及所述处理器个数，确定使所述同一处理器处理所述明文会话的左方向报文和右方向报文时所述明文会话的左方向报文的源端口号。
可选地，端口号第一获取单元，具体用于：
利用所述明文会话的左方向RSS值和右方向RSS值，以及所述处理器个数，分别得到处理所述明文会话的左方向报文和右方向报文的处理器对应的哈希值；
当所述处理所述明文会话的左方向报文和右方向报文的处理器对应的哈希值相同，且所述随机源端口号未被占用时，则将所述处理所述明文会话的左方向报文和右方向报文的处理器作为所述同一处理器，并将所述随机源端口号作为所述明文会话的左方向报文的源端口号。
可选地，客户端还包括：哈希值获取模块，用于获得所述同一处理器对应的哈希值。
端口号获取模块701，具体包括：
端口号第一获取子模块，用于利用所述关键参数种子值和所述同一处理器对应的哈希值，获得当所述密文会话的左方向报文和右方向报文由所述同一处理器处理时所述密文会话的左方向报文的源端口号。
可选地，端口号第一获取子模块，具体包括：
端口号第二生成单元，用于利用随机函数生成所述密文会话的左方向报文的随机源端口号；
RSS值第二获取单元，用于利用所述关键参数种子值和所述密文会话的左方向报文的随机源端口号，通过接收端缩放RSS算法得到所述密文会话的左方向RSS值和右方向RSS值；
端口号第二获取单元，用于利用所述密文会话的左方向RSS值和右方向RSS值，以及所述处理器个数，确定使所述同一处理器处理所述密文会话的左方向报文和右方向报文时所述密文会话的左方向报文的源端口号。
可选地，端口号第二获取单元，具体用于：
利用所述密文会话的左方向RSS值和右方向RSS值，以及所述处理器个数，分别得到处理所述密文会话的左方向报文和右方向报文的处理器对应的哈希值；
当所述处理所述密文会话的左方向报文和右方向报文的处理器对应的哈希值都等于所述同一处理器对应的哈希值，且所述随机源端口号未被占用时，则将所述随机源端口号作为所述密文会话的左方向报文的源端口号。
文件传输过程中，对文件进行加密是保障传输安全性的关键。为文件提升传输的安全性，本实施例中，将处理明文会话的右方向报文、明文会话的左方向报文、密文会话的右方向报文和密文会话的左方向报文的同一处理器对应的哈希值，作为构造加密密钥的参数之一。防火墙通过解密即可获得该同一处理器对应的哈希值，从而构造密钥。
由于该哈希值没有在客户端与服务器之间进行传输，而是通过运算得到，因此将该哈希值作为加密密钥的构造参数之一，能够大大增加密钥被破译的难度，从而提升文件传输的安全性，防止数据被窃取，损害用户利益。
下面从防火墙的角度，对本申请技术方案进行介绍。
方法实施例三
参见图8，该图为本申请实施例提供的又一种文件传输方法的流程图。
如图8所示，本实施例提供的文件传输方法，包括：
步骤801：防火墙通过解密所述密文会话的左方向报文得到所述明文会话的左方向报文的源端口号。
需要说明的是，本步骤防火墙接收到密文会话的左方向报文后对其解密获得明文会话的左方向报文的源端口号，该源端口号为使所述明文会话的左方向报文和右方向报文以及所述密文会话的左方向报文和右方向报文由所述防火墙的同一处理器处理的源端口号。
由于前述方法实施例中，对于明文会话的左方向报文的源端口号sport1的获取过程进行了详细描述，因此此处不再详述，可参照前述方法实施例。
步骤802：防火墙基于所述明文会话的左方向报文的源端口号与所述服务器建立连接，创建所述明文会话。
需要说明的是，明文会话的左方向报文的源端口号同样也是明文会话的右方向报文的目的端口号。当防火墙将客户端发送的报文转发给服务器时，以该端口号向服务器发送报文；当服务器向防火墙发送带有客户端所需文件的报文时，以该端口号作为目的端口号发送报文。
由于防火墙解密到的明文会话的左方向报文的源端口号，为使所述明文会话的左方向报文和右方向报文以及所述密文会话的左方向报文和右方向报文由所述防火墙的同一处理器处理的源端口号，因此当防火墙与服务器利用该端口号建立明文会话时，防火墙能够采用同一处理器处理明文会话和密文会话的左右方向报文。该方法相比于现有技术，避免倒核操作，提升防火墙的文件传输性能。当参与大文件传输的客户端数量较大时，该方法对防火墙文件传输性能的提升效果十分显著。
实际应用中，防火墙能够向客户端提供辅助其设计满足要求的sport及sport1的有效参数。因此，在步骤801执行之前，还可以进一步包括：
步骤800：防火墙向所述客户端发送关键参数种子值和处理器个数，以使所述客户端利用所述关键参数种子值和所述处理器个数，获得当所述明文会话的左方向报文和右方向报文由所述同一处理器处理时所述明文会话的左方向报文的源端口号。
文件传输过程中，对文件进行加密是保障传输安全性的关键。为文件提升传输的安全性，本实施例中，将处理明文会话的右方向报文、明文会话的左方向报文、密文会话的右方向报文和密文会话的左方向报文的同一处理器对应的哈希值，作为构造加密密钥的参数之一。
因此，在本实施例提供的方法中，还可在步骤802之前，进一步包括：
防火墙接收所述客户端发送的所述同一处理器对应的哈希值；
防火墙利用所述哈希值构造密钥。
步骤802中，防火墙在执行文件传输时利用该密钥对所述服务器发送的所述文件进行加密，向所述客户端发送所述密文会话的右方向报文。对于本领域技术人员，如何利用参数构造密钥属于比较成熟的技术，具体实现方式可能有很多种，因此在此不做详述和限定。
由于该哈希值没有在客户端与服务器之间进行传输，而是通过运算得到，因此将该哈希值作为加密密钥的构造参数之一，能够大大增加密钥被破译的难度，从而提升文件传输的安全性，防止数据被窃取，损害用户利益。
基于前述实施例提供的文件传输方法和客户端，相应地，本申请还提供一种防火墙。下面结合实施例和附图对该防火墙的具体实现进行描述和说明。
防火墙实施例
参见图9，该图为本申请实施例提供的一种防火墙的结构示意图。
如图9所示，本实施例提供的防火墙，包括：解密模块901，以及会话建立模块902。
其中，解密模块901，用于通过解密所述密文会话的左方向报文得到明文会话的左方向报文的源端口号；所述明文会话的左方向报文的源端口号，为使所述明文会话的左方向报文和右方向报文以及密文会话的左方向报文和右方向报文由所述防火墙的同一处理器处理的源端口号；所述密文会话为客户端与所述防火墙之间基于所述客户端对所述服务器的文件的传输需求建立；
会话建立模块902，用于基于所述明文会话的左方向报文的源端口号与所述服务器建立连接，创建所述明文会话。
由于防火墙的解密模块901解密得到的明文会话的左方向报文的源端口号，为使所述明文会话的左方向报文和右方向报文以及所述密文会话的左方向报文和右方向报文由所述防火墙的同一处理器处理的源端口号，因此当防火墙的会话建立模块902与服务器利用该端口号建立明文会话时，防火墙能够采用同一处理器处理明文会话和密文会话的左右方向报文。该防火墙相比于现有的防火墙，避免倒核操作，提升了防火墙的文件传输性能。当参与大文件传输的客户端数量较大时，防火墙文件传输性能的提升效果十分显著。
可选地，防火墙还包括：
参数发送模块，用于向所述客户端发送关键参数种子值和处理器个数，以使所述客户端利用所述关键参数种子值和所述处理器个数，获得当所述明文会话的左方向报文和右方向报文由所述同一处理器处理时所述明文会话的左方向报文的源端口号。
可选地，防火墙还包括：
哈希值接收模块，用于接收所述客户端发送的所述同一处理器对应的哈希值；
密钥构造模块，用于利用所述哈希值构造密钥；
由于该哈希值没有在客户端与服务器之间进行传输，而是通过运算得到，因此将该哈希值作为加密密钥的构造参数之一，能够大大增加密钥被破译的难度，从而提升文件传输的安全性，防止数据被窃取，损害用户利益。
所述会话建立模块902，具体包括：
加密子模块，用于利用所述密钥对所述服务器发送的所述文件进行加密，向所述客户端发送所述密文会话的右方向报文。
基于前述实施例提供的文件传输方法、客户端和防火墙，相应地，本申请还提供一种文件传输系统。下面结合实施例进行描述。
系统实施例
本实施例提供的文件传输系统，其结构可参见图3b。图3b中箭头所指方向为报文的传输方法。
如图3b所示，本实施例提供的文件传输系统，包括：客户端301，服务器303，和设置于服务器前端的防火墙302；其中，所述客户端301对于服务器303的文件具有传输需求。
本实施例提供的系统中，客户端301可以是客户端实施例中描述的客户端，具备执行前述方法实施例一和/或方法实施例二提供的文件传输方法的功能；防火墙302可以是防火墙实施例中描述的防火墙，具备执行前述方法实施例三提供的文件传输方法的功能。为行文简洁，此处不做赘述，可参照前述各实施例。
下面对系统中各组成部分的功能进行简要描述。
系统中，客户端301用于获得明文会话的左方向报文的源端口号，并获得密文会话的左方向报文的源端口号；利用所述密文会话的左方向报文的源端口号与所述防火墙302建立所述密文会话；防火墙302用于基于所述传输需求，通过解密所述密文会话的左方向报文获得所述明文会话的左方向报文的源端口号，基于所述明文会话的左方向报文的源端口号与所述服务器303建立连接，创建所述明文会话；
防火墙302还用于采用同一处理器处理所述明文会话的左方向报文和右方向报文以及所述密文会话的左方向报文和右方向报文，传输所述文件。
在该系统中，客户端301为用户对应的终端设备，用户可以通过操控客户端的按键或模块，触发客户端301执行相应的功能。实际应用中，客户端301为基于windows环境开发，功能包括用户认证、文件下载和存储等。防火墙302可以是基于x86系统实现，部署在服务器前端，功能包括：对服务器输出的数据(例如客户端请求的文件)进行保护和传递。
在本实施例提供的系统中，客户端对于服务器的文件具有传输需求时，首先获得能够保证明文会话和密文会话的左右方向报文均由同一处理器处理的源端口号，其一为明文会话的左方向报文的源端口号，其二为密文会话的左方向报文的源端口号。为进行文件传输，客户端利用密文会话的左方向报文的源端口号与防火墙之间基于文件传输需求建立密文会话，而防火墙通过解密密文会话的左方向报文能够得到明文会话的左方向报文的源端口号，从而建立明文会话。从而，防火墙能够采用同一处理器处理明文会话和密文会话的左右方向报文。该系统避免倒核操作，提升防火墙的文件传输性能。当参与大文件传输的客户端数量较大时，该系统中防火墙文件传输性能的提升效果十分显著。
需要说明的是，本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于设备及系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的设备及系统实施例仅仅是示意性的，其中作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元提示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
以上所述，仅为本申请的一种具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应该以权利要求的保护范围为准。

Claims (8)

1.一种文件传输方法，其特征在于，应用于客户端，基于所述客户端对于服务器的文件的传输需求，所述客户端与防火墙之间建立密文会话，所述防火墙与所述服务器之间建立明文会话；所述防火墙设置于所述服务器前端；所述方法包括：
所述客户端获得所述明文会话的左方向报文的源端口号，并获得所述密文会话的左方向报文的源端口号，以使所述明文会话的左方向报文和右方向报文以及所述密文会话的左方向报文和右方向报文由所述防火墙的同一处理器处理；
所述客户端获得所述同一处理器对应的哈希值；
所述客户端利用所述密文会话的左方向报文的源端口号建立所述密文会话，并且以使所述防火墙通过解密所述密文会话的左方向报文获得所述明文会话的左方向报文的源端口号，利用所述明文会话的左方向报文的源端口号建立所述明文会话，传输所述文件；
所述客户端获得所述明文会话的左方向报文的源端口号，具体包括：
所述客户端获得所述防火墙的关键参数种子值和处理器个数；
所述客户端利用随机函数生成所述明文会话的左方向报文的随机源端口号；
所述客户端利用所述关键参数种子值和所述明文会话的左方向报文的随机源端口号，通过接收端缩放RSS算法得到所述明文会话的左方向RSS值和右方向RSS值；
所述客户端利用所述明文会话的左方向RSS值和右方向RSS值，以及所述处理器个数，确定使所述同一处理器处理所述明文会话的左方向报文和右方向报文时所述明文会话的左方向报文的源端口号；
所述客户端获得所述密文会话的左方向报文的源端口号，具体包括：
所述客户端利用随机函数生成所述密文会话的左方向报文的随机源端口号；
所述客户端利用所述关键参数种子值和所述密文会话的左方向报文的随机源端口号，通过接收端缩放RSS算法得到所述密文会话的左方向RSS值和右方向RSS值；
所述客户端利用所述密文会话的左方向RSS值和右方向RSS值，以及所述处理器个数，确定使所述同一处理器处理所述密文会话的左方向报文和右方向报文时所述密文会话的左方向报文的源端口号。
2.根据权利要求1所述的方法，其特征在于，所述客户端利用所述明文会话的左方向RSS值和右方向RSS值，以及所述处理器个数，确定使所述同一处理器处理所述明文会话的左方向报文和右方向报文时所述明文会话的左方向报文的源端口号，具体包括：
所述客户端利用所述明文会话的左方向RSS值和右方向RSS值，以及所述处理器个数，分别得到处理所述明文会话的左方向报文和右方向报文的处理器对应的哈希值；
当所述处理所述明文会话的左方向报文和右方向报文的处理器对应的哈希值相同，且所述随机源端口号未被占用时，则所述客户端将所述处理所述明文会话的左方向报文和右方向报文的处理器作为所述同一处理器，并将所述随机源端口号作为所述明文会话的左方向报文的源端口号。
3.根据权利要求1所述的方法，其特征在于，所述客户端利用所述密文会话的左方向RSS值和右方向RSS值，以及所述处理器个数，确定使所述同一处理器处理所述密文会话的左方向报文和右方向报文时所述密文会话的左方向报文的源端口号，具体包括：
所述客户端利用所述密文会话的左方向RSS值和右方向RSS值，以及所述处理器个数，分别得到处理所述密文会话的左方向报文和右方向报文的处理器对应的哈希值；
当所述处理所述密文会话的左方向报文和右方向报文的处理器对应的哈希值都等于所述同一处理器对应的哈希值，且所述随机源端口号未被占用时，则所述客户端将所述随机源端口号作为所述密文会话的左方向报文的源端口号。
4.一种客户端，其特征在于，包括：
端口号获取模块，用于获得明文会话的左方向报文的源端口号，并获得密文会话的左方向报文的源端口号，以使所述明文会话的左方向报文和右方向报文以及所述密文会话的左方向报文和右方向报文由防火墙的同一处理器处理；所述明文会话为所述防火墙与服务器之间基于所述客户端对所述服务器的文件的传输需求建立；所述防火墙设置于所述服务器前端；
哈希值获取模块，用于获得所述同一处理器对应的哈希值；
文件传输模块，用于利用所述密文会话的左方向报文的源端口号建立所述密文会话，并且以使所述防火墙通过解密所述密文会话的左方向报文获得所述明文会话的左方向报文的源端口号，利用所述明文会话的左方向报文的源端口号建立所述明文会话，传输所述文件；
所述端口号获取模块，包括：
参数值获取子模块，用于获得所述防火墙的关键参数种子值和处理器个数；
端口号第一生成单元，用于利用随机函数生成所述明文会话的左方向报文的随机源端口号；
RSS值第一获取单元，用于利用所述关键参数种子值和所述明文会话的左方向报文的随机源端口号，通过接收端缩放RSS算法得到所述明文会话的左方向RSS值和右方向RSS值；
端口号第一获取单元，用于利用所述明文会话的左方向RSS值和右方向RSS值，以及所述处理器个数，确定使所述同一处理器处理所述明文会话的左方向报文和右方向报文时所述明文会话的左方向报文的源端口号；
端口号第二生成单元，用于利用随机函数生成所述密文会话的左方向报文的随机源端口号；
RSS值第二获取单元，用于利用所述关键参数种子值和所述密文会话的左方向报文的随机源端口号，通过接收端缩放RSS算法得到所述密文会话的左方向RSS值和右方向RSS值；
端口号第二获取单元，用于利用所述密文会话的左方向RSS值和右方向RSS值，以及所述处理器个数，确定使所述同一处理器处理所述密文会话的左方向报文和右方向报文时所述密文会话的左方向报文的源端口号。
5.一种文件传输方法，其特征在于，应用于防火墙，所述防火墙设置于服务器前端，基于客户端对于所述服务器的文件的传输需求，所述客户端与所述防火墙之间建立密文会话，所述防火墙与所述服务器之间建立明文会话；所述方法包括：
所述防火墙通过解密所述密文会话的左方向报文得到所述明文会话的左方向报文的源端口号；所述明文会话的左方向报文的源端口号，为使所述明文会话的左方向报文和右方向报文以及所述密文会话的左方向报文和右方向报文由所述防火墙的同一处理器处理的源端口号；
所述防火墙基于所述明文会话的左方向报文的源端口号与所述服务器建立连接，创建所述明文会话；
在所述防火墙通过解密所述密文会话的左方向报文得到所述明文会话的左方向报文的源端口号之前，所述方法还包括：
所述防火墙向所述客户端发送关键参数种子值和处理器个数，以使所述客户端利用随机函数生成所述明文会话的左方向报文的随机源端口号；使所述客户端利用所述关键参数种子值和所述明文会话的左方向报文的随机源端口号，通过接收端缩放RSS算法得到所述明文会话的左方向RSS值和右方向RSS值；使所述客户端利用所述明文会话的左方向RSS值和右方向RSS值，以及所述处理器个数，确定使所述同一处理器处理所述明文会话的左方向报文和右方向报文时所述明文会话的左方向报文的源端口号；使所述客户端利用随机函数生成所述密文会话的左方向报文的随机源端口号；使所述客户端利用所述关键参数种子值和所述密文会话的左方向报文的随机源端口号，通过接收端缩放RSS算法得到所述密文会话的左方向RSS值和右方向RSS值；使所述客户端利用所述密文会话的左方向RSS值和右方向RSS值，以及所述处理器个数，确定使所述同一处理器处理所述密文会话的左方向报文和右方向报文时所述密文会话的左方向报文的源端口号。
6.根据权利要求5所述的方法，其特征在于，还包括：
所述防火墙通过解密所述密文会话的左方向报文得到所述同一处理器对应的哈希值；
所述防火墙利用所述哈希值构造密钥；
所述传输所述文件，具体包括：
所述防火墙利用所述密钥对所述服务器发送的所述文件进行加密，向所述客户端发送所述密文会话的右方向报文。
7.一种防火墙，其特征在于，设置于服务器前端，包括：
解密模块，用于通过解密密文会话的左方向报文得到明文会话的左方向报文的源端口号；所述明文会话的左方向报文的源端口号，为使所述明文会话的左方向报文和右方向报文以及密文会话的左方向报文和右方向报文由所述防火墙的同一处理器处理的源端口号；所述密文会话为客户端与所述防火墙之间基于所述客户端对所述服务器的文件的传输需求建立；
会话建立模块，用于基于所述明文会话的左方向报文的源端口号与所述服务器建立连接，创建所述明文会话；
参数发送模块，用于向所述客户端发送关键参数种子值和处理器个数，以使所述客户端利用随机函数生成所述明文会话的左方向报文的随机源端口号；使所述客户端利用所述关键参数种子值和所述明文会话的左方向报文的随机源端口号，通过接收端缩放RSS算法得到所述明文会话的左方向RSS值和右方向RSS值；使所述客户端利用所述明文会话的左方向RSS值和右方向RSS值，以及所述处理器个数，确定使所述同一处理器处理所述明文会话的左方向报文和右方向报文时所述明文会话的左方向报文的源端口号；使所述客户端利用随机函数生成所述密文会话的左方向报文的随机源端口号；使所述客户端利用所述关键参数种子值和所述密文会话的左方向报文的随机源端口号，通过接收端缩放RSS算法得到所述密文会话的左方向RSS值和右方向RSS值；使所述客户端利用所述密文会话的左方向RSS值和右方向RSS值，以及所述处理器个数，确定使所述同一处理器处理所述密文会话的左方向报文和右方向报文时所述密文会话的左方向报文的源端口号。
8.一种文件传输系统，其特征在于，包括：客户端，服务器，和设置于服务器前端的防火墙；所述客户端对于服务器的文件具有传输需求；
所述客户端用于获得明文会话的左方向报文的源端口号，并获得密文会话的左方向报文的源端口号；利用所述密文会话的左方向报文的源端口号与所述防火墙建立所述密文会话；所述防火墙用于基于所述传输需求，通过解密所述密文会话的左方向报文获得所述明文会话的左方向报文的源端口号，利用所述明文会话的左方向报文的源端口号与所述服务器建立所述明文会话；
所述防火墙还用于采用同一处理器处理所述明文会话的左方向报文和右方向报文以及所述密文会话的左方向报文和右方向报文，传输所述文件；
所述客户端具体用于通过以下方式获得所述明文会话的左方向报文的源端口号：
获得所述防火墙的关键参数种子值和处理器个数；利用随机函数生成所述明文会话的左方向报文的随机源端口号；利用所述关键参数种子值和所述明文会话的左方向报文的随机源端口号，通过接收端缩放RSS算法得到所述明文会话的左方向RSS值和右方向RSS值；利用所述明文会话的左方向RSS值和右方向RSS值，以及所述处理器个数，确定使所述同一处理器处理所述明文会话的左方向报文和右方向报文时所述明文会话的左方向报文的源端口号；
所述客户端具体用于通过以下方式获得所述密文会话的左方向报文的源端口号：
利用随机函数生成所述密文会话的左方向报文的随机源端口号；利用所述关键参数种子值和所述密文会话的左方向报文的随机源端口号，通过接收端缩放RSS算法得到所述密文会话的左方向RSS值和右方向RSS值；利用所述密文会话的左方向RSS值和右方向RSS值，以及所述处理器个数，确定使所述同一处理器处理所述密文会话的左方向报文和右方向报文时所述密文会话的左方向报文的源端口号。
CN201911359604.4A 2019-12-25 2019-12-25 一种文件传输方法、系统、客户端及防火墙 Active CN111031065B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201911359604.4A CN111031065B (zh) 2019-12-25 2019-12-25 一种文件传输方法、系统、客户端及防火墙

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201911359604.4A CN111031065B (zh) 2019-12-25 2019-12-25 一种文件传输方法、系统、客户端及防火墙

Publications (2)

Publication Number Publication Date
CN111031065A CN111031065A (zh) 2020-04-17
CN111031065B true CN111031065B (zh) 2022-02-11

Family

ID=70214382

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201911359604.4A Active CN111031065B (zh) 2019-12-25 2019-12-25 一种文件传输方法、系统、客户端及防火墙

Country Status (1)

Country Link
CN (1) CN111031065B (zh)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010036656A2 (en) * 2008-09-29 2010-04-01 Intel Corporation Directing data units to a core supporting tasks
CN104468412A (zh) * 2014-12-04 2015-03-25 东软集团股份有限公司 基于rss的网络会话数据包分发方法及系统
CN105871741A (zh) * 2015-01-23 2016-08-17 阿里巴巴集团控股有限公司 一种报文分流方法及装置
CN105915462A (zh) * 2016-06-03 2016-08-31 中国航天科技集团公司第九研究院第七七研究所 一种面向tcp会话的对称性rss电路
US9712460B1 (en) * 2013-08-26 2017-07-18 F5 Networks, Inc. Matching port pick for RSS disaggregation hashing
CN107911349A (zh) * 2017-11-01 2018-04-13 西安微电子技术研究所 一种面向UDP传输的对称性Receive‑side Scaling电路

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8990431B2 (en) * 2009-05-05 2015-03-24 Citrix Systems, Inc. Systems and methods for identifying a processor from a plurality of processors to provide symmetrical request and response processing
JPWO2011096307A1 (ja) * 2010-02-03 2013-06-10 日本電気株式会社 プロキシ装置とその動作方法
US10200447B2 (en) * 2015-09-23 2019-02-05 Citirix Systems, Inc. FTP load balancing support for cluster

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010036656A2 (en) * 2008-09-29 2010-04-01 Intel Corporation Directing data units to a core supporting tasks
US9712460B1 (en) * 2013-08-26 2017-07-18 F5 Networks, Inc. Matching port pick for RSS disaggregation hashing
CN104468412A (zh) * 2014-12-04 2015-03-25 东软集团股份有限公司 基于rss的网络会话数据包分发方法及系统
CN105871741A (zh) * 2015-01-23 2016-08-17 阿里巴巴集团控股有限公司 一种报文分流方法及装置
CN105915462A (zh) * 2016-06-03 2016-08-31 中国航天科技集团公司第九研究院第七七研究所 一种面向tcp会话的对称性rss电路
CN107911349A (zh) * 2017-11-01 2018-04-13 西安微电子技术研究所 一种面向UDP传输的对称性Receive‑side Scaling电路

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
基于DPDK的流量动态负载均衡技术研究;李凯;《中国优秀硕士学位论文全文数据库信息科技辑》;20190228;全文 *
高性能数据包捕获系统的研究与实现;刘宝辰;《中国优秀硕士学位论文全文数据库信息科技辑》;20140430;全文 *

Also Published As

Publication number Publication date
CN111031065A (zh) 2020-04-17

Similar Documents

Publication Publication Date Title
CN110870277B (zh) 将中间盒引入到客户端与服务器之间的安全通信中
US9398026B1 (en) Method for authenticated communications incorporating intermediary appliances
US8418242B2 (en) Method, system, and device for negotiating SA on IPv6 network
CA2905583C (en) Secure network communication
JP2020080530A (ja) データ処理方法、装置、端末及びアクセスポイントコンピュータ
JP2019528604A (ja) 仮想マルチパスデータトランスポートのためのシステム及び方法
CN111428225A (zh) 数据交互方法、装置、计算机设备及存储介质
US9350711B2 (en) Data transmission method, system, and apparatus
US20180176194A1 (en) Service processing method and apparatus
Liu et al. CCBKE—Session key negotiation for fast and secure scheduling of scientific applications in cloud computing
US20170149748A1 (en) Secure Group Messaging and Data Steaming
US20230118375A1 (en) Secure communication session resumption in a service function chain
CN114503507A (zh) 安全的发布-订阅通信方法和设备
US9979550B1 (en) Methods of facilitating packet-based connections
WO2018076013A1 (en) Systems and method for anonymous, low-latencey, tracking-resistant communications in a networked environment
WO2016068941A1 (en) Secure transactions in a memory fabric
US20230367853A1 (en) Digital rights management systems and methods using efficient messaging schemes
CN106209401B (zh) 一种传输方法及装置
US8793494B2 (en) Method and apparatus for recovering sessions
US10623382B2 (en) Creating and utilizing black keys for the transport layer security (TLS) handshake protocol and method therefor
CN112202882B (zh) 一种传输方法、客户端及传输系统
CN111031065B (zh) 一种文件传输方法、系统、客户端及防火墙
Burgstaller et al. Anonymous communication in the browser via onion-routing
CN110995730B (zh) 数据传输方法、装置、代理服务器和代理服务器集群
CN116980171A (zh) 一种基于旁路模式下的密码服务安全接入方法及系统

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
GR01 Patent grant
GR01 Patent grant