协议栈处理的全分布式实现方法和分布式系统

摘要

本发明公开了一种协议栈的全分布式实现方法和系统，所述方法根据TCP、UDP和RawIP协议的特点，通过同步少量的INPCB数据达到协议栈的全分布式目的。具体来说，对于TCP协议，仅同步母SOCKET的INPCB数据；对于UDP协议，仅同步服务器端连接的INPCB数据；对于RawIP协议，同步所有连接的INPCB数据。使用本发明能够在不需要同步所有INPCB数据的情况下，实现协议栈处理的全分布式。

说明书

技术领域

本发明涉及分布式系统的处理技术，具体涉及分布式系统中协议栈处理的全分布式实现方法和分布式系统。

背景技术

目前，为了提高处理能力，出现了分布式系统，分布式系统中包括多个子系统，每个子系统具有独立的CPU处理能力，能够独立运行协议栈，多个子系统配合完成一套系统功能。

在分布式系统中，需要支持协议栈处理的分布式。协议栈是指传输控制协议/因特网协议(TCP/IP)协议栈，包括传输控制协议(TCP)、用户数据报协议(UDP)、原始因特网协议(RawIP)三种INET协议族的协议。在INET协议族(包括INET4和INET6)中，每个套接字(SOCKET)连接对应一个协议控制块，INPCB(Internet Protocol Control Block)是INET协议族的协议控制块，INPCB记录SOCKET连接的本地地址(LIP)、本地端口(LP)、远端地址(DIP)、远端端口(DP)等连接信息。

分布式系统中的各子系统都有可能创建INPCB数据，且当各子系统上建立的SOCKET连接不同时，其所创建的INPCB数据也不同。各子系统在接收到IP数据报文后会用报文的连接信息匹配INPCB数据，在匹配成功时，将所接收IP数据报文交给INPCB对应的上层协议SOCKET应用程序。

图1描述了一种理想的协议栈处理的全分布式实现方式，该方式通过同步所有INPCB数据实现协议栈的全分布式，协议栈处理包括INPCB数据同步和报文处理操作。

如图1所示，分布式系统包括三个子系统，每个子系统创建一个SOCKET连接，INPCB数据同步后的情况是三个子系统中的INPCB数据相同，且知道INPCB数据与子系统的对应关系。当System1收到SOCKET2的报文packet2后，匹配本地的INPCB数据，匹配上INPCB2，此时确定packet2对应的连接在System2上，因此直接将packet2透传给System2；System2再次匹配本地INPCB数据，发现是本地应用的数据直接上送到上层协议处理，如果未匹配上则丢弃。当packet2从System3进入时，处理过程类似，System3将packet2透传给System2，由System2上送给本地的上层协议处理。

上述协议栈处理的全分布式实现方式为理想的实现方式，仅适用于数据源固定且数据量不大的情况。而现实中较多的情况是，数据源不固定、数据量比较大，采用同步所有INPCB数据的方式会对系统性能造成一定影响。具体来说：由于上层协议的SOCKET应用可以任意在各子系统上运行，这样各SOCKET对应的INPCB数据也就有可能在任何子系统上面产生。要做到协议栈处理的全分布式，势必需要将所有SOCKET对应的INPCB数据同步到各子系统，使得各子系统都可以查到这些INPCB数据，保证报文从任何子系统进入都可以得到正确处理，而不至于丢弃。因此这种协议栈处理的全分布式实现方式需要在子系统之间同步大量INPCB数据，这势必会加重系统负担，从而降低系统的业务处理能力。

为了解决上述问题，目前采用基于端口特征的部分分布式的实现方式间接实现协议栈处理的分布式，具体为：

1、设置主用子系统(System Master)，System Master做服务器端监听知名端口，在收到客户端连接请求时，建立连接。而除System Master之外的其他子系统不监听知名端口，只允许作为客户端建立非知名端口的连接。

2、对于非知名端口的连接，可以预先划分端口范围，不同子系统处理固定端口范围的连接，各子系统收到带有端口特性连接的报文后可以明确地知道交给哪个子系统处理。因此不需要对INPCB数据进行同步。

3、对于RawIP协议，由于没有端口特征，因此不能参与端口范围的划分，这样的连接被限制在主用子系统上建立，子系统接收到RawIP连接的报文后，发给System Master集中处理。

图2描述了部分分布式实现方式下的报文处理流程。如图2所示，同样是分布式系统包括三个子系统，每个子系统创建一个SOCKET连接。假设，整个系统约定System Master可以处理的端口包括：端口段1～4000(其中包括知名端口1～1024)、端口段5000～6000、10000～20000；System II子系统可以处理的端口为端口段4001～4999；System III子系统可以处理的端口为端口段6001～6999。各子系统都知道自身及其他子系统可以处理的端口段信息。各子系统维护自身端口段对应的INPCB数据，而不需要进行INPCB数据的同步。

当System II接收到Packet1后，System II检查到Packet1的目的端口3301为System Master的处理范围，则直接透传到System Master，System Master收到Packet1后检查到报文目的端口为本子系统处理范围，则继续匹配本子系统上面的INPCB数据，匹配成功则上送上层应用，匹配失败则直接丢弃Packet1。Pakcet2的处理类似，System III接收到Packet2后检查到Packet2的目的端口4100为System II的处理范围，则直接透传到System II由SystemII进行匹配和后续处理。

但是，这种基于端口特征的分布式处理方式也存在以下弊端：

1、只能实现部分分布式。

由于限制了只能由System Master做服务器端监听知名端口，且基于端口特征的分布式只能支持TCP/UDP这种需要通过端口号识别的协议，对于RawIP这样没有端口信息的协议只能在System Master上集中处理，因此实际上只能实现部分分布式。实现部分分布式的后果是增加了System Master的负担，从而降低System Master的性能。

2、容易受到报文攻击。

由于知名端口报文只能由System Master集中处理，子系统接收到知名端口的报文后，不识别对应的知名端口服务是否打开，而是一味地将报文透传给System Master。当用户构造大量知名端口的报文从各子系统打入，各子系统检查目的端口为知名端口则全部上送System Master处理，而SystemMaster上面可能并没有开启相应的服务，这样就加重了System Master的处理，影响正常业务处理。

3、系统可扩展性不高。

各子系统作为客户端的时候只能从预先约定的非知名端口范围内分配本地端口号，不能进行扩展，因此各子系统建立连接可以使用的本地动态端口资源有限，容易形成系统瓶颈。而且，端口资源不能被充分利用，比如某个子系统没有建立任何连接，那么约定给这个子系统上面的端口资源不能被其他子系统使用，浪费了端口资源。

发明内容

有鉴于此，本发明提供了一种协议栈处理的全分布式的实现方法，能够在不需要同步所有INPCB数据的情况下，实现协议栈处理的全分布式。

本发明所提供的一种协议栈处理的全分布式实现方法中，分布式系统中每个子系统执行如下同步操作和报文处理操作；

所述同步操作包括，

对于TCP协议：记录为所在分布式系统中各子系统分配的非知名端口段；在作为客户端建立客户端TCP连接时，从本地分配得到的非知名端口段中为客户端TCP连接分配端口，不同步客户端TCP连接的INPCB数据；在作为服务器时，创建母套接字SOCKET监听知名端口，仅将母SOCKET的INPCB数据及其与子系统的对应关系同步到所有子系统中；

对于UDP协议：记录为所在分布式系统中各子系统分配的非知名端口段；在作为客户端建立客户端UDP连接时，从本地分配得到的非知名端口段中为客户端UDP连接分配端口，不同步客户端UDP连接的INPCB数据；在作为服务器时，将所有服务器端UDP连接的INPCB数据及其与子系统的对应关系同步到所有子系统中；

对于RawIP协议：将所有RawIP连接的INPCB数据及其与子系统的对应关系同步到所有子系统中；

分布式系统中每个子系统在接收到报文后，执行如下报文处理操作：

匹配端口资源，包括：采用报文目的端口号匹配本地记录的各非知名端口段，如果端口匹配成功，且匹配的非知名端口段属于本子系统，则继续匹配INPCB数据；如果端口匹配成功，但匹配的非知名端口段不属于本子系统，则将报文透传到匹配的非知名端口段对应的子系统；如果端口未匹配成功，则继续匹配INPCB数据；

所述匹配INPCB数据包括：根据报文的连接信息在本地记录的INPCB数据中进行最长匹配，如果匹配成功，且匹配到的INPCB数据属于本子系统，则将报文上送本子系统的应用层处理；如果匹配成功，但匹配到的INPCB数据不属于本子系统，则将报文透传到匹配的INPCB数据对应的子系统；如果未匹配成功，按照报文为分布式系统不可识别报文处理。

优选地，为分布式系统中各子系统分配的非知名端口段的获取方式为：分布式系统中负责端口资源管理的主用子系统管理非知名端口段的分配；分布式系统中的子系统向所述主用子系统申请一段非知名端口段，申请的非知名端口段用竭后，继续申请另一段非知名端口段；所述主用子系统将分配给子系统的非知名端口段与子系统之间的对应关系同步到各子系统。

优选地，所述对应母SOCKET创建子SOCKET连接时，将母SOCKET与子SOCKET的对应关系以及INPCB数据保存到母子关系表中；当母SOCKET没有对应的子SOCKET时，允许删除母SOCKET。

优选地，所述按照报文为分布式系统不可识别报文处理为：丢弃报文。

本发明进一步提供了一种分布式系统，能够在不需要同步所有INPCB数据的情况下，实现协议栈处理的全分布式。

本发明所提供的一种分布式系统中，包括多个子系统；

每个子系统包括端口号维护单元、端口号分配单元、INPCB数据同步单元、INPCB数据存储单元和报文处理单元；

所述端口号维护单元，用于记录为所在分布式系统中各子系统分配的非知名端口段；

所述端口号分配单元，用于所在子系统作为客户端建立客户端TCP连接或客户端UDP连接时，从所述端口号维护单元记录的本地分配得到的非知名端口段中为客户端TCP连接或客户端UDP连接分配端口；

所述INPCB数据同步单元，对于TCP协议，当所在子系统作为客户端建立客户端TCP连接时，不同步客户端TCP连接的INPCB数据，当作为服务器时，创建母SOCKET监听知名端口，仅将母SOCKET的INPCB数据及其与子系统的对应关系进行同步到所有子系统中；对于UDP协议，当所在子系统作为客户端建立客户端UDP连接时，不同步客户端UDP连接的INPCB数据，在作为服务器时，将所有服务器端UDP连接的INPCB数据及其与子系统的对应关系同步到所有子系统中；对于RawIP协议，将所有RawIP连接的INPCB数据及其与子系统的对应关系同步到所有子系统中；

所述INPCB数据存储单元，用于存储所在子系统创建的本地INPCB数据，接收并保存其他子系统同步来的INPCB数据及其与子系统的对应关系；

所述报文处理单元包括端口匹配模块和INPCB数据匹配模块；

所述端口匹配模块，用于在接收到来自所在子系统外部的报文后，采用报文目的端口号匹配所述端口号维护单元记录的各非知名端口段，如果端口匹配成功，且匹配的非知名端口段属于本子系统，则发送给所述INPCB数据匹配模块；如果端口匹配成功，但匹配的非知名端口段不属于本子系统，则将报文透传到匹配的非知名端口段对应的子系统；如果未匹配成功，则发送给所述INPCB数据匹配模块；

所述INPCB数据匹配模块，用于在接收到来自端口匹配模块的报文后，根据报文的连接信息在所述INPCB数据存储单元记录的INPCB数据中进行最长匹配，如果匹配成功，且匹配到的INPCB数据属于本子系统，则将报文上送本子系统的应用层处理；如果匹配成功，但匹配到的INPCB数据不属于本子系统，则将报文透传到匹配的INPCB数据对应的子系统；如果未匹配成功，按照报文为分布式系统不可识别报文处理。

优选地，端口号维护单元包括端口申请模块和端口记录模块；

所述端口申请模块，用于向分布式系统中负责端口资源管理的主用子系统申请一段非知名端口段，申请的非知名端口段用竭后，继续申请另一段非知名端口段；接收所述主用子系统同步到本地的非知名端口段以及使用该非知名端口段的子系统之间的对应关系，并发送到端口记录模块；

所述端口记录模块，用于记录所接收的非知名端口段与子系统的对应关系。

优选地，当所在子系统为所述主用子系统时，所述端口号维护单元进一步包括申请响应模块，用于在接收到其他子系统对非知名端口段的申请时，从未分配出去的非知名端口资源中分配一段非知名端口段，将分配的非知名端口段与子系统的对应关系同步到端口记录模块和其他各子系统中。

优选地，所述INPCB数据匹配模块在未匹配成功时，丢弃未匹配成功的报文。

根据以上技术方案可见，应用本发明能够达到以下有益效果：

由以上所述可以看出，1、各子系统均可作为服务器端监听知名端口，且各子系统都可以处理RawIP连接，避免现有技术中只采用主用子系统集中处理知名端口连接和RawIP连接带来的主用子系统负担过重的问题，实现了知名端口连接和RawIP连接的分布式处理。

对于连接量较多的服务器端TCP连接，本发明利用TCP协议母SOCKET和子SOCKET具有关联关系的特点，仅同步母SOCKET的INPCB数据，那么只要报文匹配上母SOCKET的INPCB数据就可以将报文透传到报文所属子系统进行INPCB匹配及后续处理；而对于连接较少的RawIP连接和知名端口的UDP连接，同步所有的INPCB数据，那么只要报文匹配上INPCB数据，也可以将报文透传到报文所属子系统进行INPCB匹配及后续处理。这种根据协议特点区分INPCB数据同步方式的方法，在实现全分布式的情况下，避免了大量INPCB数据的同步。

2、知名端口报文可由各子系统分布式处理，当子系统接收到知名端口的报文后，经过INPCB数据的匹配过程能够排除掉未打开服务的知名端口的报文，对于这类报文，由于没有相应INPCB数据，因此接收这类报文的子系统会丢弃所接收报文，从而避免受到恶意构造的大量知名端口报文的攻击。

3、本发明的子系统在需要本地端口资源时，向System Master申请非知名端口段，永竭后再申请。这种方式增加了端口分配的灵活度，端口资源能够被充分利用，避免端口资源的浪费。

附图说明

图1为一种理想的协议栈处理的全分布式实现方式。

图2为现有技术中部分分布式实现方式下报文处理流程。

图3为本发明全分布式实现方式下端口段分配和INPCB数据同步后的示意图。

图4为本发明全分布式实现方式下报文转发流程图。

图5为基于图3所示端口段分配和INPCB数据同步结果的报文转发流程图。

图6为本发明分布式系统中子系统的结构示意图。

具体实施方式

下面结合附图并举实施例，对本发明进行详细描述。

本发明根据TCP协议、UDP协议和RawIP协议的特点，通过同步少量INPCB数据来实现协议栈处理的全分布式。

首先，对TCP协议、UDP协议和RawIP协议的特点进行分析：

TCP协议：对于TCP协议的连接，连接的主要信息包括本地地址、本地端口、对端地址和对端端口。本地端口范围1～65535。知名端口为1～1024，且知名端口的连接数量比较多。

UDP协议：对于UDP协议的连接，连接的主要信息包括本地地址、本地端口、对端地址和对端端口。本地端口范围1～65535。知名端口为1～1024，1024以上也有部分知名端口。总体连接数量不大。

RawIP协议：对于RawIP协议的连接，连接的主要信息包括本地地址和对端地址。没有端口信息。这类连接数量比较少。

其次，从分布式系统的角色角度分析：

对于TCP连接和UDP连接来说，连接的两端一端为服务器端，一端为客户端，各子系统可以做服务器端，也可以做客户端。当子系统做服务器段时，采用知名端口建立连接，所建立的连接称为服务器端连接，当子系统做客户端时，采用非知名端口建立连接，所建立的连接称为客户端连接。但是对于RawIP协议来说，没有角色的概念。因此，下面从角色角度的分析都是针对TCP连接和UDP连接来说的。

服务器角色：

当子系统做服务器时，创建连接的时候通过静态指定，使用本地知名端口。对于TCP这种面向连接的应用，创建连接的时机是在接受客户端请求的时候，连接数量由客户端数量决定，通常数量会比较大(比如SSL VPN这样的应用)；通常，子系统会采用一个母SOCKET监听一个知名端口，当客户端发起到服务器端的连接时，服务器端接受连接后创建一个子SOCKET连接与客户端进行通信。而对于UDP这种非面向连接的应用，作为服务器角色创建的连接数量基本不大。

客户端角色：

当子系统做客户端时，创建连接的时候通过动态分配，使用本地非知名端口。使用分布式系统做客户端的情况不多，所以这类连接的数量不大。

从以上分析可见，首先知名端口的连接量大，即服务器端连接的数量大，且在服务器端连接中，TCP连接占了很大部分，UDP连接并不多。相应地，非知名端口的连接量小，即客户端连接的数量小。此外，RawIP协议的连接量也不大。据此，本发明尽量做到同步少量的数据达到全分布式的效果。每个子系统中各协议需要同步的数据如下：

●TCP协议

作为客户端时：记录为所在分布式系统中各子系统分配的非知名端口段，即记录各子系统允许使用的非知名端口号与子系统的对应关系；在子系统作为客户端建立客户端TCP连接时，从本地分配得到的非知名端口段中为客户端TCP连接分配端口，不同步客户端TCP连接的INPCB数据。

其中，非知名端口段与子系统的对应关系可以预先划分，但这种方式不够灵活，端口资源不能被充分利用。因此，较佳地，本发明由分布式系统中的System Master集中管理非知名端口段的分配；当某子系统需要建立客户端TCP连接的时候，向System Master申请一段非知名端口段，然后从申请的非知名端口段中为连接动态分配端口，而不是像现有技术那样使用从预先划分的本地端口段中动态分配端口，当申请的非知名端口段用竭后，可以继续申请另一段非知名端口段。System Master会将分配给子系统的非知名端口段与子系统之间的对应关系同步到各子系统，以使各子系统已申请的端口资源段能够被其他子系统获知。

作为服务器时：知名端口不再仅仅由System Master集中处理，各子系统都可以监听知名端口。具体说，各子系统创建母SOCKET监听知名端口，将母SOCKET的INPCB数据及其与子系统的对应关系同步到所有子系统中；监听到并接受客户端发起的TCP连接后，对应母SOCKET创建子SOCKET连接与客户端通信，但不同步子SOCKET的INPCB数据。可见，本本发明考虑到服务器端TCP连接数量较多的特点，仅同步母SOCKET的的INPCB数据，避免了同步量巨大的问题。

为了实现母SOCKET的同步，在对应母SOCKET建立子SOCKET连接时，将母SOCKET与子SOCKET的对应关系记载到母子关系表中，该母子关系表中不仅包括母子SOCKET之间的对应关系，还包括各母SOCKET和子SOCKET的INPCB数据。在同步INPCB数据时，可以根据母子关系表确定哪些是不需要同步的SOCKET。需要注意的是，当母子关系表中存在子SOCKET的情况下不允许删除对应的母SOCKET，当母SOCKET没有对应的子SOCKET时，才可以删除母SOCKET，并将同步到各子系统的母SOCKET的INPCB数据回收，从而避免由于无法匹配到母SOCKET的INPCB数据而无法找到子SOCKET的情况发生。由于母SOCKET与子SOCKET之间存在关联关系，因此通过同步母SOCKET的INPCB数据，相当于实现了子SOCKET的INPCB数据的同步。

●UDP协议

作为客户端时：处理与TCP协议相同。即记录为所在分布式系统中各子系统分配的非知名端口段；在作为客户端建立客户端UDP连接时，从本地分配得到的非知名端口段中为客户端UDP连接分配端口，不同步客户端UDP连接的INPCB数据。

作为服务器时：由于UDP协议的总体连接数量不大，因而可将所有服务器端UDP连接的INPCB数据及其与子系统的对应关系同步到所有子系统中。

●RawIP协议：

RawIP协议没有服务器端和客户端的概念，且RawIP连接的数量不大，因此本发明将所有RawIP连接的INPCB数据及其与子系统的对应关系同步到所有子系统中。

下面举一个实例对非知名端口段分配和INPCB数据同步进行说明。以TCP协议应用为例，假设每个非知名端口段包括64个可用端口号，参见图3；

System II：

System II申请到非知名端口段1(2000～2063)，本地创建了INPCB22，INPCB22是非知名端口段1中某个端口的INPCB数据；

System II采用母SOCKET监听知名端口200，对应知名端口200创建了INPCB2，接受客户端发起的TCP连接后，创建了两个子SOCKET，两个子SOCKET分别对应INPCB222和INPCB2222，并维护了一张如表1所示的母子关系表。

表1

System III：

System III申请到非知名端口段2(3000～3063)，本地创建了INPCB33；INPCB33是非知名端口段2中某个端口例如端口3002的INPCB数据；

System III采用母SOCKET监听知名端口300，对应知名端口300创建了INPCB3，接受客户端发起的TCP连接后，创建了两个子SOCKET，两个子SOCKET分别对应INPCB333和INPCB333，并维护了一张如表2所示的母子关系表。

表2

根据前述非知名端口段的分配规则和INPCB数据的同步规则，各子系统执行如下操作：

System Master将非知名端口段1与System II之间的对应关系以及非知名端口段2与System III之间的对应关系全局同步，即同步到System II和System III，当然还包括System Master本身；

System II将本地母SOCKET的INPCB数据(INPCB2)与System II的对应关系进行全局同步，即同步到System Master和System III，当然还包括System II本身；

System III将本地母SOCKET的INPCB数据(INPCB3)与System III的对应关系进行全局同步，即同步到System Master和System II，当然还包括System III本身；

经过同步处理，稳定后各子系统的情况如图3所示。为了清楚，图3将INPCB同步数据和INPCB本地数据分开显示。

经过数据同步稳定后，数据报文在各子系统上的分布式处理流程如图4所示，参见图4，每个子系统在收到报文后，执行如下各步骤：

步骤401：当子系统接收到报文后，采用报文目的端口号匹配本地记录的各非知名端口段，如果端口匹配成功，且匹配的非知名端口段属于本子系统，则执行步骤402；如果端口匹配成功，但匹配的非知名端口段不属于本子系统，则执行步骤404；如果端口未匹配成功，则执行步骤402。

步骤402：匹配INPCB数据。

本步骤的匹配INPCB数据的步骤包括：根据报文的连接信息在本地记录的INPCB数据中进行最长匹配。该INPCB数据包括本地连接的INPCB数据，还包括其他子系统同步到本子系统的INPCB数据。如果匹配成功，且匹配到的INPCB数据属于本子系统，执行步骤403；如果匹配成功，但匹配到的INPCB数据不属于本子系统，执行步骤404；如果匹配不成功，则，执行步骤405；

其中，连接信息包括本地地址(LIP)、本地端口(LP)、对端地址(DIP)、对端端口(DP)。最长匹配是指取匹配度最高的INPCB数据作为匹配结果。这里的匹配不是用完全匹配的原因是：母SOCKET和子SOCKET对应的INPCB数据具有相同的LIP和LP(对于所接收报文来说是报文的DIP和DP)，母SOCKET和子SOCKET的DP和DIP通常不相同，母SOCKET一般不指定DIP和DP，且不指定记为0)；如果接收报文的子系统中没有保存相应子SOCKET的INPCB数据，则通过最长匹配可以匹配上母SOCKET的INCPB数据，从而实施透传操作，而如果接收报文的子系统中有匹配的子SOCKET，则将报文上送应用层处理，下面会举实例说明这一点。

步骤403：将所接收报文直接上送本子系统的应用层处理。本流程结束。

步骤404：将所接收报文透传到其所属子系统处理。本流程结束。所接收报文所属子系统接收到该报文后，也按照图4示出的流程进行处理。

步骤405：按照所接收报文为分布式系统无法处理的报文处理，例如直接丢弃报文，或实施某种预设的策略。

至此，本流程结束。

结合图4的流程可以看出，当采用图4示出的流程对所接收报文进行处理时，如果所接收报文为TCP协议报文，且端口号为非知名端口，则可在端口匹配步骤中确定报文所在子系统，进而由相应子系统进行处理；

如果所接收报文为TCP报文，报文端口号为知名端口，但本地没有维护相应子SOCKET，则在INPCB数据匹配过程中，通过最长匹配会匹配上母SOCKET的INPCB数据，此时根据母SOCKET与子系统的对应关系可确定报文所在子系统，进而由相应子系统进行处理；

如果所接收报文为TCP报文，报文端口号为知名端口，且本地维护了相应子SOCKET，则在INPCB数据匹配过程中，通过最长匹配会直接匹配上相应子SOCKET的INPCB数据，进而由本子系统的应用层进行处理；

如果所接收报文为UDP报文，且UDP报文端口号为非知名端口，则处理方式与TCP报文相同；如果UDP报文端口号为知名端口，则由于该协议的INPCB数据全部同步，因此可以在INPCB数据匹配过程中找到报文所属子系统，进而由相应子系统进行处理；

如果所接收报文为RawIP报文，由于该协议的INPCB数据全部同步，则可以在INPCB数据匹配过程中找到报文所属子系统，进而由相应子系统进行处理。

可见，无论报文从哪个子系统进入分布式系统，无论所接收报文是什么协议类型的报文，都可以得到恰当处理，从而实现了协议栈处理的全分布式。而，如果所接收报文为未打开服务的知名端口的攻击报文，由于未打开服务的知名端口不会创建和同步相应的INPCB数据，因此接收报文的子系统在INPCB数据匹配过程中确定匹配失败，从而丢弃所接收攻击报文，以避免攻击发生。

下面以图3示出的子系统为例，对报文处理流程进行描述。报文处理流程参见图5，

当Packet1从System II子系统进入时，System II识别Packet1的目的端口3002对应端口资源Res2，查找到Res2对应子系统System III，则将报文透传到System III；System III识别出Packet1属于本子系统的端口范围，然后匹配INPCB数据，匹配到INPCB33后成功上送本子系统应用程序。

当Packet2从System III子系统进入时，System III识别Packet2的目的端口200不属于任何端口段资源；然后进行INPCB数据的最长匹配，匹配到INPCB2后透传到System II；System II通过最长匹配，会匹配到INPCB222(可参考表1中INPCB222的内容)，直接上送本地上层应用程序。

由以上所述可以看出，1、各子系统均可作为服务器端监听知名端口，且各子系统都可以处理RawIP连接，避免现有技术中只采用主用子系统集中处理知名端口连接和RawIP连接带来的主用子系统负担过重的问题，实现了知名端口连接和RawIP连接的分布式处理。对于连接量较多的服务器端TCP连接，本发明利用TCP协议母SOCKET和子SOCKET具有关联关系的特点，仅同步母SOCKET的INPCB数据，那么只要报文匹配上母SOCKET的INPCB数据就可以将报文透传到报文所属子系统进行INPCB匹配及后续处理；而对于连接较少的RawIP连接和知名端口的UDP连接，同步所有的INPCB数据，那么只要报文匹配上INPCB数据，也可以将报文透传到报文所属子系统进行INPCB匹配及后续处理。这种根据协议特点区分INPCB数据同步方式的方法，在实现全分布式的情况下，避免了大量INPCB数据的同步。

2、知名端口报文可由各子系统分布式处理，当子系统接收到知名端口的报文后，经过INPCB数据的匹配过程能够排除掉未打开服务的知名端口的报文，对应这类报文，由于没有相应INPCB数据，因此接收这类报文的子系统会丢弃所接收报文，从而避免受到恶意构造的大量知名端口报文的攻击。

3、本发明的子系统在需要本地端口资源时，向System Master申请非知名端口段，永竭后再申请。这种方式增加了端口分配的灵活度，可扩展性明显增强，端口资源能够被充分利用，避免端口资源的浪费。各子系统可以建立的客户端连接数量不受限制，理论上只要能够分配到动态端口就可以创建客户端连接。

为了实现上述全分布式实现方法和报文转发方法，本发明还提供了一种分布式系统。图6示出了该分布式系统中每个子系统的结构示意图。如图6所示，该子系统包括端口号维护单元61、端口号分配单元62、INPCB数据同步单元63和INPCB数据存储单元64。

其中，端口号维护单元61，用于记录为所在分布式系统中各子系统分配的非知名端口段。

较佳地，该端口号维护单元61包括端口申请模块611和端口记录模块612；其中，

端口申请模块611，用于向分布式系统中负责端口资源管理的主用子系统申请一段非知名端口段，申请的非知名端口段用竭后，继续申请另一段非知名端口段；接收所述主用子系统同步到本地的非知名端口段以及使用该非知名端口段的子系统之间的对应关系，并发送到端口记录模块612。

端口记录模块612，用于记录端口所接收的的非知名端口段与子系统的对应关系。

当该子系统为所述负责端口资源管理的主用子系统时，该端口号维护单元61进一步包括申请响应模块613，用于在接收到其他子系统对非知名端口段的申请时，从未分配出去的非知名端口资源中分配一段非知名端口段，将分配的非知名端口段与子系统的对应关系同步到端口记录模块612和其他各子系统中。

端口号分配单元62，用于所在子系统作为客户端建立客户端TCP连接或客户端UDP连接时，从所述端口号维护单元61记录的本地分配得到的非知名端口段中为客户端TCP连接或客户端UDP连接分配端口。

INPCB数据同步单元63，对于TCP协议，当所在子系统作为客户端建立客户端TCP连接时，不同步客户端TCP连接的INPCB数据，当作为服务器时，创建母SOCKET监听知名端口，将母SOCKET的INPCB数据及其与子系统的对应关系进行同步到所有子系统中；接受客户端发起的TCP连接并对应母SOCKET创建子SOCKET连接后，不同步子SOCKET的INPCB数据；对于UDP协议，当所在子系统作为客户端建立客户端UDP连接时，不同步客户端UDP连接的INPCB数据，在作为服务器时，将所有服务器端UDP连接的INPCB数据及其与子系统的对应关系同步到所有子系统中；对于RawIP协议，将所有RawIP连接的INPCB数据及其与子系统的对应关系同步到所有子系统中。

INPCB数据存储单元64，用于存储所在子系统创建的本地INPCB数据，接收并保存其他子系统同步来的INPCB数据及其与子系统的对应关系。

以上各个模块的配合即可实现协议栈处理的全分布式。为了实现报文转发，每个子系统还需要包括报文处理单元65。本发明中，该报文处理单元65包括端口匹配模块651和INPCB数据匹配模块652。

端口匹配模块651，用于在接收到来自所在子系统外部的报文(包括来自分布式系统外部的报文和来自其他子系统的报文)后，采用报文目的端口号匹配端口号维护单元61(中的端口记录模块612)记录的各非知名端口段，如果端口匹配成功，且匹配的非知名端口段属于本子系统，则发送给INPCB数据匹配模块652；如果端口匹配成功，但匹配的非知名端口段不属于本子系统，则将报文透传到匹配的非知名端口段对应的子系统；如果未匹配成功，则发送给INPCB数据匹配模块652。

INPCB数据匹配模块652，用于在接收到来自端口匹配模块651的报文后，根据报文的连接信息在INPCB数据存储单元64记录的INPCB数据中进行最长匹配，如果匹配成功，且匹配到的INPCB数据属于本子系统，则将报文上送本子系统的应用层处理；如果匹配成功，但匹配到的INPCB数据不属于本子系统，则将报文透传到匹配的INPCB数据对应的子系统；如果未匹配成功，按照报文为分布式系统不可识别报文处理，例如丢弃。

综上所述，以上仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。