CN117375857A - 一种报文处理方法、装置、系统及相关设备 - Google Patents

Abstract

一种报文处理方法、装置、系统及相关设备，该系统包括客户终端和应用服务器，该方法包括以下步骤：应用服务器接收客户终端发送的报文，该报文包括由客户终端为报文添加的流量标签，流量标签包括报文的传输链路的唯一的标识，应用服务器根据报文的流量标签确定报文的真实源地址信息，应用服务器根据真实源地址信息对报文实现网络访问控制，在报文传输过程中，传输链路中的任何设备不会对该流量标签进行修改，使得应用服务器接收到报文后，可根据报文的该流量标签确定报文的真实源地址信息，从而解决报文传输过程中由于源地址信息被修改导致应用服务器的网络方案实施困难的问题。

Description

一种报文处理方法、装置、系统及相关设备

技术领域

本申请涉及通信领域，尤其涉及一种报文处理方法、装置、系统及相关设备。

背景技术

随着通信技术的不断发展，云计算、大数据、移动互联网等技术的大规模应用，使得客户端(client)和服务端(server)不再是简单的直连，客户端和服务端之间存在越来越多的设备，比如路由设备和负载均衡器(比如弹性负载均衡(elastic load balance,ELB)、应用型负载均衡(application load balancer,ALB)等)，部分路由设备和负载均衡器会对流量服务的源地址信息中的部分信息进行修改或者丢弃，使得报文从客户端达到服务端时，服务端所接收到的报文上携带的源地址信息已经不是客户端处生成的真实源地址信息，服务端根据非真实的源地址信息进行网络访问控制，导致网络访问控制失败、错误率高等问题，降低用户的使用体验。

发明内容

本申请提供了一种报文处理方法、装置、系统及相关设备，用于解决应用服务器接收到的报文所携带的源地址信息在传输过程中被修改，导致应用服务器网络访问控制失败、错误率高的问题。

第一方面，提供了一种报文处理方法，该方法应用于报文处理系统，上述报文处理系统包括客户终端和应用服务器，该方法包括以下步骤：应用服务器接收客户终端发送的报文，报文的可选字段包括由客户终端为报文添加的流量标签，流量标签包括报文的传输链路的唯一的标识，应用服务器根据报文的流量标签确定报文的真实源地址信息，根据真实源地址信息对报文实现网络访问控制。

实施第一方面描述的方法，客户终端可以生成携带有流量标签的报文，该流量标签可包括报文传输链路的唯一标识，在报文传输过程中，传输链路中的任何设备不会对该流量标签进行修改，使得应用服务器接收到报文后，可根据报文的该流量标签确定报文的真实源地址信息，从而解决报文传输过程中由于源地址信息被修改导致应用服务器的网络方案实施困难的问题。

在一可能的实现方式中，标识包括路径身份信息trace id。

具体实现中，上述唯一标识可以是trace id，客户终端可以将生成的全局唯一的trace id与报文的传输链路进行关联，使得应用服务器接收到报文后，可根据全局唯一的trace id获知报文的真实源地址信息，这里的真实源地址信息至少包括客户终端的源IP地址、报文的传输链路中的主体和客体的信息，还可包括其他能够根据traceid确定的真实源地址信息，这里不一一举例说明。

可选地，上述traceid可以是使用雪花算法或者改进版雪花算法生成的ID，还可以是其他能够保证全局唯一、保证所生成的字符串不会出现重复的算法，比如根据时间戳生成ID、根据哈希算法生成ID等等，本申请不作具体限定。

实施上述实现方式，通过生成全局唯一的标识，并将其与报文的传输链路进行关联，可以使得应用服务器接收报文后，可根据报文的该流量标签确定报文的真实源地址信息，从而解决报文传输过程中由于源地址信息被修改导致应用服务器的网络方案实施困难的问题。

在一可能的实现方式中，流量标签还包括与报文相关的客户终端进程的进程信息，进程信息包括进程名称、客户终端名称、用户名称中的一种或者多种，真实源地址信息包括报文的传输链路中的主体和客体对应的进程信息。

具体实现中，客户终端可以在生成traceid并将traceid与报文的传输链路进行关联之后，获取报文的进程数据生成进程信息，从而获得流量标签。其中，该进程数据可以是与报文的发起进程相关的数据，进程数据包括但不限于进程名、进程路径、进程链、命令行、文件签名、进程来源、客户终端名、客户终端名、用户名等，具体可根据流量标签的内容确定获取的数据类型，本申请不作具体限定。

应理解，获取报文的进程数据之后，可以将进程数据的部分或者全部数据作为进程信息添加入流量标签，比如将进程数据中的进程名作为进程信息添加入流量标签；也可以对进程数据进行二次处理之后作为进程信息添加入流量标签，比如将进程信息编码压缩为二进制字符串之后作为进程信息添加入流量标签，本申请不作具体限定。

可选地，上述流量标签还可包括更多或者更少的内容，比如流量标签还可包括网络数据，其中，网络数据包括但不限于源IP地址和源端口、目标IP地址和目标端口、接口方式、接入区域等，具体可根据实际业务场景确定，比如应用服务器需要根据文件签名实现某种网络安全方案，那么上述流量标签还可包括文件签名的信息，这里不一一展开举例。

具体实现中，客户终端可以根据应用服务器对报文进行访问控制时所需的真实源地址信息，确定流量标签所需包括的内容，然后根据流量标签的内容确定协议栈生成流量标签时所需获取的进程数据和网络数据。这样，在后续报文处理过程中，客户终端为报文添加的流量标签可以应用服务器获取真实源地址信息，从而解决报文传输过程中由于源地址信息被修改导致应用服务器的网络方案实施困难的问题。

可选地，确定流量标签的内容之后，可以按照预设的格式生成流量标签，使得应用服务器可以根据预设格式对流量标签进行解析，获取标签中的进程信息和唯一标识，举例来说，标签格式可以为“traceid|进程名”，比如“00934df880e82cf2a6a1129965|outlook.exe”，其中，00934df880e82cf2a6a1129965为traceid，outlook.exe为进程名。上述举例用于说明，本申请不作具体限定。

实施上述实现方式，流量标签包括进行信息，使得应用服务器接收到报文后可以根据流量标签的进程信息，获得发送报文的客户终端的进程信息，还可以根据上述标识获得报文传输链路中全部主体和客体的进程信息，从而解决报文传输过程中由于源地址信息被修改导致应用服务器的网络方案实施困难的问题。

在一可能的实现方式中，报文包括TCP报文、ACK报文、PSH报文、SYN报文、FIN报文中的任一种。

应理解，客户终端可生成多个报文，比如UDP报文、TCP报文等等，而本申请中的客户终端为TCP报文添加流量标签，具体可包括TCP报文下的全部类型报文，比如ACK报文、PSH报文、SYN报文、FIN报文、RST报文、URG报文等等，其中，ACK报文用于确认报文序号，PSH报文用于提示接收方尽快将报文提交给应用层，SYN报文用于同步序号以发起连接，FIN报文用于结束连接，RST报文用于重建连接，URG报文用于传输紧急指针。简单来说，在TCP协议的建立和连接阶段所需传输的全部类型报文，都属于本申请的待处理报文。

具体实现中，客户终端可以先拦截Inbound/Outbound网络层报文，然后对拦截到的报文进行协议识别，过滤掉非TCP报文，对非TCP报文进行放行，不为其添加流量标签。具体实现中，客户终端可以基于WFP的NetWork Layer shim拦截Inbound/Outbound网络层报文，当然也可以使用其他技术手段对其进行拦截，本申请不作具体限定。

进一步地，客户终端过滤掉非TCP报文后，可以对保留的TCP报文进行进一步的过滤，过滤掉一些传输过程中源地址信息不会发生改变，或者应用服务器不需要进行处理的TCP报文，举例来说，客户终端可以对loopback、ipsec报文进行放行。应理解，ipsec报文用于为网络中传输的数据提高高质量的、可互操作的、基于密码学的安全保证，传输过程中的安全性很高，因此客户终端可以将其过滤放行，不对其进行处理。loopback报文是回环报文，换言之是自己发送自己接收的报文，该类报文不通过网络进行传输，因此该类报文可以放行，不需要对其添加流量标签。应理解，上述举例用于说明，本申请不作具体限定。

进一步地，用户也可以设置一些过滤放行的TCP报文，为其添加放行标志，比如FWPS_RIGHT_ACTION_WRITE标志，该标志指示了报文有权限进行过滤放行，如果没有这个标志则对报文进行捕获，如果有这个标志则对该报文进行过滤放行，从而满足各种应用场景下的用户需求，提高用户的使用体验。

进一步地，客户终端也可以确定TCP报文是否是应用层发送的报文，如果不是应用层发送的报文，而是协议栈增加(inject)的报文，那么对TCP报文中的inject报文进行放行，应理解，客户终端在协议栈中对待处理报文添加流量标签，生成新的报文之后，待处理报文将会被删除，协议栈会根据报文处理顺序，逐个将携带有流量标签的报文重新inject到系统协议栈，然后一一发送给应用服务器，因此inject的报文是携带有流量标签的报文，因此客户终端可以对其进行过滤放行，避免出现二次添加流量标签的情况。

需要说明的，报完处理装置过滤掉的报文，比如上述Inbound/Outbound网络层报文、非TCP报文、loopback报文、inject报文、拥有FWPS_RIGHT_ACTION_WRITE标志的报文等等，可以不对其添加流量标签，直接将其发送给应用服务器。过滤后保留的待处理报文可以为其添加流量标签。

可以理解的，对于在传输过程中源地址信息不会发生改变，或者应用服务器的应用服务器不需要进行处理的报文，客户终端都可以将其过滤，从而降低客户终端的处理压力，提高报文处理效率，减少对报文通信效率的影响。

上述实现方式，通过对客户终端生成的报文进行过滤和拦截，并为其设置拦截条件，使得在传输过程中源地址信息被修改的报文能够被拦截，而源地址信息不会在传输过程中被修改的报文被放行，从而减少流量标签处理的数据量，提高流量标签处理效率，降低对报文通信效率的影响。

在一可能的实现方式中，流量标签位于报文的可选option字段，流量标签的长度和报文option字段的原有数据的长度之和不小于阈值。

具体实现中，流量标签在报文中的位置可以包括报文传输过程中不会被任何设备修改的字段，这里的任何设备包括但不限于负载均衡器、路由设备、主体和客体等等，option字段是一种可选的实现方式，本申请不对此进行具体限定。

通常情况下，TCP报文为option字段预留的长度为0～40KB，但是大部分TCP报文的option字段为空，也就是0KB，少部分TCP报文的option字段有option信息，但是option信息的长度也往往很小，比如3～5kb。因此，将流量标签添加至option字段，可以在不影响TCP报文原有内容的情况下实现流量标签的传输，使得报文通信效率不会受到影响。

可选地，该流量标签的长度和报文原有的option信息的长度之和不小于阈值，这里的阈值可以是40kb。举例来说，如果待传输的TCP报文原有的option信息长度为20KB，那么流量标签的长度不大于20KB，如果原有的option信息长度为1KB，那么流量标签的长度不大于39KB，本申请不作具体限定。

应理解，TCP报文包括报文头和荷载(payload)，荷载即为报文需要传输的数据，报文头包括多个字段，不同的字段可用于描述该报文的不同信息，比如源端口号和目的端口号字段、序号字段、首部长度字段、option字段等等。其中，option信息的长度通常为0～40kb，该字段是一个可变长的可选信息，一些报文可以有option字段，一些报文可以没有option字段(即option字段长度为0KB)，具体可根据实际的应用场景确定option字段的内容和占用的长度。在本申请实施例中，流量标签写入可变长的option字段，并且流量标签的长度与原有的option信息长度之和不超过可变长的option字段的最大长度(40KB)，使得流量标签嵌入待处理报文后，不会对待处理报文的payload产生影响，从而不影响报文的正常通信。

可选地，如果原有option字段与流量标签的长度之和超过阈值时，可以将流量标签的内容进行压缩，使得压缩后的流量标签长度与原有的option信息长度之和不超阈值。需要说明的，如果待处理报文原有的option信息已达到40KB，即报文的option字段在添加流量标签之间已被占满，那么客户终端可以不生成流量标签，直接放行该报文，避免报文的正常通信被影响。如果待处理报文原有的option信息和流量标签的长度之和超过阈值，对极端情况可以不进行流量标签的嵌入，以免出现通信失败的问题。

可选地，流量标签也可以写入报文的payload中，还可以写入其他报文传输过程中不会被任何设备修改的字段，这里不一一举例说明。

上述实现方式，将流量标签添加至报文传输过程中不会被任何设备修改的报文字段中，使得应用服务器接收到报文时，即使报文的源地址信息被修改，也可以根据流量标签获得真实源地址信息，避免应用服务器根据非真实的源地址信息实施网络访问控制，提高网络访问控制的成功率，提高用户的使用体验。

在一可能的实现方式中，应用服务器可以调用协议栈实现对流量标签的解析，获得报文的真实源地址信息。具体实现中，应用服务器可以对协议栈进行升级，比如在协议栈安装插件程序，在协议栈接收到报文后，该插件程序可根据报文中的流量标签确定报文的真实源地址信息，该真实源地址信息可包括但不限于客户终端的源IP地址和进程信息、报文传输链路中的主体和客体对应的进程服务信息等，本申请不作具体限定。

同理，客户终端也可以调用协议栈实现对报文的拦截，并对拦截到的TCP报文添加流量标签。具体实现中，客户终端可以对协议栈进行升级，比如在协议栈安装插件程序，该插件程序可以在启动时采集客户终端的相关信息，比如机器码、操作系统版本等等，协议栈驱动程序拦截到上层应用程序下发的待处理报文时，该插件程序可以采集当前的调用环境信息，包括进程信息、线程信息等等，结合开机启动时采集的信息以及运行时采集的信息，生成流量标签，具体可参考前述关于流量标签生成的描述，这里不重复赘述。

上述实现方式，通过对客户终端和应用服务器的协议栈进行升级，内核模式下的协议栈拥有对操作系统的较高权限，使得客户终端可以快速获取报文的相关信息，比如进程、线程、客户端信息、traceid等等，从而获得流量标签。而且为报文添加流量标签操作在系统协议栈进行，不需要使用代理，报文按照原有路径经过协议栈、网卡发送到应用服务，不影响原始报文的流动路径，对通信性能影响很小，提高用户的使用体验。

第二方面，提供了一种访问控制装置，访问控制装置部署于应用服务器，该装置包括：接收单元，用于接收客户终端发送的报文，报文包括流量标签，流量标签包括报文的传输链路的唯一的标识，标识在报文传输过程中不发生改变，确定单元，用于根据报文的流量标签确定报文的真实源地址信息，处理单元，用于根据真实源地址信息对报文实现网络访问控制。

实施第一方面描述的方法，客户终端可以生成携带有流量标签的报文，该流量标签可包括报文传输链路的唯一标识，在报文传输过程中，传输链路中的任何设备不会对该流量标签进行修改，使得访问控制装置接收到报文后，可根据报文的该流量标签确定报文的真实源地址信息，从而解决报文传输过程中由于源地址信息被修改导致应用服务器的网络方案实施困难的问题。

在一可能的实现方式中，流量标签还包括与报文相关的客户终端进程的进程信息，进程信息包括进程名称、客户终端名称、用户名称中的一种或者多种，真实源地址信息包括报文的传输链路中的主体和客体对应的进程信息。

在一可能的实现方式中，报文包括TCP报文、ACK报文、PSH报文、SYN报文、FIN报文中的任一种。

在一可能的实现方式中，标识包括路径身份信息trace id。

在一可能的实现方式中，流量标签位于报文的可选option字段,流量标签的长度和报文option字段的原有数据的长度之和不小于阈值。

上述实现方式，通过对客户终端生成的报文进行过滤和拦截，并为其设置拦截条件，使得在传输过程中源地址信息被修改的报文能够被拦截，而源地址信息不会在传输过程中被修改的报文被放行，从而减少流量标签处理的数据量，提高流量标签处理效率，降低对报文通信效率的影响。

第三方面，提供了一种报文处理装置，报文处理装置部署于客户终端，装置包括：发送单元，用于向应用服务器发送报文，报文包括流量标签，流量标签包括报文的传输链路的唯一的标识，标识在报文传输过程中不发生改变，流量标签用于供应用服务器确定报文的真实源地址信息，根据真实源地址信息对报文实现网络访问控制。

在一可能的实现方式中，流量标签还包括与报文相关的客户终端进程的进程信息，进程信息包括进程名称、客户终端名称、用户名称中的一种或者多种，真实源地址信息包括报文的传输链路中的主体和客体对应的进程信息。

在一可能的实现方式中，报文包括TCP报文、ACK报文、PSH报文、SYN报文、FIN报文中的任一种。

在一可能的实现方式中，标识包括路径身份信息trace id。

在一可能的实现方式中，流量标签位于报文的可选option字段，流量标签的长度和报文option字段的原有数据的长度之和不小于阈值。

上述实现方式，通过对客户终端生成的报文进行过滤和拦截，并为其设置拦截条件，使得在传输过程中源地址信息被修改的报文能够被拦截，而源地址信息不会在传输过程中被修改的报文被放行，从而减少流量标签处理的数据量，提高流量标签处理效率，降低对报文通信效率的影响。

第四方面，提供了一种计算设备，计算设备包括处理器和存储器，存储器用于存储指令，处理器用于运行指令实现如第一方面描述的方法。

第五方面，提供了一种报文处理系统，该报文处理系统包括报文处理装置和访问控制装置，其中，报文处理装置包括第三方面描述的功能模块，访问控制装置包括第二方面描述的功能模块。

本申请在上述各方面提供的实现方式的基础上，还可以进行进一步组合以提供更多实现方式。

附图说明

图1是本申请提供的一种报文处理系统的架构示意图；

图2是本申请提供的一种报文处理装置和访问控制装置的结构示意图；

图3是本申请提供的一种客户终端的结构示意图；

图4是本申请提供的一种应用服务器的结构示意图；

图5是本申请提供的一种报文处理方法的步骤流程示意图；

图6是本申请提供的一种报文格式的示例图；

图7是本申请提供的一种计算设备的结构示意图。

具体实施方式

下面将结合本发明实施例中的附图。

为了便于理解，首先对本申请涉及的部分术语进行解释说明。

主体和客体：向外提供各种网络服务的设备可以称为主体，比如服务端(server)，从服务器上获取网络服务的机器称为客体，比如客户端(client)。

传输控制协议(transmission control protocol,TCP)：TCP是一种面向连接的、可靠的、基于字节流的传输层通信协议。TCP旨在适应支持多网络应用的分层协议层次结构。连接到不同但是互连的计算机通信网络的计算机中的成对进程之间依靠TCP提供可靠的通信服务。

其次，对本申请的应用场景进行说明。

随着通信技术的不断发展，云计算、大数据、移动互联网等技术的大规模应用，用户终端可以随时随地向云端读取数据，使得网络中客户端和服务端)之间传输的报文数量大幅度增加，为数据的泄露和攻击带来了更多漏洞。

同时，通信技术的不断发展也使得客户端和服务端不再是简单的直连，客户端和服务端之间存在越来越多的路由设备和负载均衡器(比如弹性负载均衡(elastic loadbalance,ELB)、应用型负载均衡(application load balancer,ALB)等，在报文由客户端发送至服务端的过程当中，路由设备和负载均衡器可能会对报文中的部分信息进行修改或者丢弃，使得报文达到服务端时，服务端在报文中获取到的源地址信息已经不是客户端处生成的真实源地址信息，服务端根据非真实的源地址信息进行网络访问控制，导致网络访问控制失败、错误率高等问题，降低用户的使用体验。

为了解决服务端无法根据真实源地址信息实现网络访问控制的问题，本申请提供了一种报文处理系统，该系统可包括客户终端和应用服务器，客户终端可以生成携带有流量标签的报文，该流量标签可包括报文传输链路的唯一标识，在报文传输过程中，传输链路中任何设备不会对该流量标签进行修改，使得应用服务器接收到报文后，可根据报文的该流量标签确定报文的真实源地址信息，从而解决报文传输过程中由于源地址信息被修改导致服务端的网络访问控制失败、错误率高等问题。

图1是本申请提供的一种报文处理系统的架构示意图，如图1所示，该报文处理系统可包括客户终端100、应用服务器200以及网络方案策略中心300，其中，客户终端100和应用服务器200之间可通过网络400建立通信连接。应理解，图1用于举例说明，本申请提供的报文处理系统不对客户终端100、应用服务器200以及网络方案策略中心300的数量进行具体限定。

客户终端100可以是用户持有的终端设备或者计算设备，其中，该终端设备可以是计算机、智能手机、掌上处理设备、平板电脑、移动笔记本、增强现实(augmented reality,AR)设备、虚拟现实(virtual reality,VR)设备、一体化掌机、穿戴设备、车载设备、智能会议设备、智能广告设备、智能家电等等，此处不作具体限定。该计算设备可以是裸金属服务器(Bare Metal Server,BMS)、虚拟机、容器或边缘计算设备。其中，BMS指的是通用的物理服务器，例如，ARM服务器或者X86服务器；虚拟机指的是网络功能虚拟化(NetworkFunctions Virtualization,NFV)技术实现的、通过软件模拟的具有完整硬件系统功能的、运行在一个完全隔离环境中的完整计算机系统，容器指的是一组受到资源限制，彼此间相互隔离的进程。

在本申请实施例中，客户终端100可以生成携带有流量标签的报文，该流量标签可包括报文传输链路的唯一标识，该流量标签可以供应用服务器确定报文的传输链路中的主体和客体的信息，获得该报文的真实源地址信息，从而解决报文传输过程中由于源地址信息被修改导致服务端的网络方案实施困难的问题。

应理解，该流量标签在报文从客户终端100传输至应用服务器200的整条访问链路中不会发生改变，使得服务端接收到报文后，可根据流量标签实施基于真实源地址信息实现的各种网络方案，从而解决由于传输过程中真实源地址信息发生变化导致一些网络方案实施困难的问题。

具体实现中，上述客户端110可以是客户终端100上任何可以生成待处理报文的客户端，比如邮箱客户端、网页客户端、游戏客户端、即时通讯软件客户端等等，本申请不作具体限定。

应用服务器200和/或网络方案策略中心300可以是计算设备，该计算设备可以是BMS、虚拟机或容器。其中，BMS指的是通用的物理服务器，例如，ARM服务器或者X86服务器；虚拟机和容器的描述可参考前述内容，这里不重复赘述；应用服务器200和网络方案策略中心300也可以是计算设备集群中的计算设备，比如公有云数据中心内的计算设备，本申请不作具体限定。具体实现中，应用服务器200和网络方案策略中心300可以是同一个计算设备，或者，应用服务器200和网络方案策略中心300是不同的计算设备，本申请不作具体限定。

进一步地，应用服务器200可包括服务端210和访问控制装置220，其中，访问控制装置220用于接收客户终端100发送的报文，然后根据报文中携带的流量标签实现访问控制，比如通过报文或者拒绝报文，通过的报文可以交由服务端210进行处理，比如接收邮件，对邮件内容进行处理；接收网页访问请求，返回该请求对应的网页信息；接收游戏中的控制请求，返回该控制请求对应的游戏画面等等，本申请不作具体限定。

网络方案策略中心300可以用于辅助访问控制装置220对报文进行认证，判断是否通过报文，比如访问控制装置220接收到报文后，远程请求根据网络方案策略中心300根据流量标签进行认证，实现相应的访问控制策略，当然，网络方案策略中心300也可部署于应用服务器200内部，即应用服务器200的访问控制装置220在本地根据报文的流量标签进行认证，判断是否通过报文。

需要说明的，上述网络方案可以是网络安全防护方案，比如防火墙、入侵检测、入侵防御等等，也可以是流量计费、流量控制、异常报文溯源等其他需要使用源地址信息实现其功能的网络方案，本申请不作具体限定。

网络400可以是有线网络或者无线网络，本申请不作具体限定，其中，网络400可包括多个路由设备410和负载均衡器420，其中，路由设备410可以是路由器、交换机等等，负载均衡器420可以是弹性负载均衡(elastic load balance,ELB)、应用型负载均衡(application load balancer,ALB)等，本申请不作具体限定。

需要说明的，网络400还可包括其他客户终端和其他应用服务器，也就是说，客户端110和服务端210传输的报文的通信链路可包括图1所示的多个路由设备410以及负载均衡器420，还可包括多个主体和客体，这里的主体可以是也通过该传输链路获取网络服务的其他客户终端，这里的客体可以是也通过该传输链路提供其他网络服务的应用服务器。其中，不仅路由设备410和负载均衡器420可以对报文中的部分内容进行修改或删除，恶意攻击网络400的主体和客体(比如恶意攻击网络400的客户终端A)也可以对网络400中的报文进行修改、删除或增添操作，本申请不作具体限定。

应理解，报文处理装置120为客户端110生成的报文添加流量标签之后，该报文在网络400中传输过程中，将会经过多个路由设备410和多个负载均衡器420，也可能会经过多个主体和客体，使得报文在达到应用服务器200时，报文上携带的源地址信息已不是客户端110生成的真实源地址信息，但是报文处理装置120为报文添加的流量标签在传输过程中不会发生修改，因此应用服务器200的访问控制装置220可根据流量标签实施基于真实源地址信息实现的各种网络方案，从而解决由于传输过程中真实源地址信息发生变化导致一些网络方案实施困难的问题。

可选地，上述报文处理装置120可以基于客户终端100的协议栈130实现，上述访问控制装置220可以基于应用服务器200的协议栈230实现，简单来说，对客户终端100和应用服务器200的协议栈进行升级，使得客户终端100可实现上述报文处理装置120所描述的功能，使得应用服务器200可实现上述访问控制装置220所描述的功能。具体实现中，可通过过滤器钩子(filter hook)等方式过滤网络数据包，拦截待处理报文，并为其添加流量标签，无需额外使用代理，且不会影响原始报文的传输，对客户端110和服务端210之间通信性能和交互产生的影响很小。

具体实现中，报文处理装置120可以以一种插件程序的方式安装于客户终端100的操作系统上的协议栈中，该插件程序与协议栈驱动程序一同运行在内核模式下，该插件程序可以在启动时采集客户终端100的相关信息，比如机器码、操作系统版本等等，协议栈驱动程序拦截到上层应用程序下发的待处理报文时，该插件程序可以采集当前的调用环境信息，包括进程信息、线程信息等等，结合启动时采集的客户终端信息，生成上述流量标签。

同理，访问控制装置220也可以以一种插件程序的方式安装于应用服务器200的操作系统上的协议栈中，该插件程序与协议栈驱动程序也一同运行在内核模式下，与上述报文处理装置120内的插件程序类似功能，这里不重复赘述。

进一步地，图1中的报文处理装置120和访问控制装置220可以划分为多个单元模块，示例性地，图2是本申请提供的一种报文处理装置和访问控制装置的结构示意图，其中，报文处理装置120可包括捕获单元121、标签生成单元122以及发送单元123，访问控制装置220可包括处理单元221、确定单元222以及接收单元223，应理解，图2是一种示例性划分方式，报文处理装置120和访问控制装置220还可包括更多或者更少的单元模块，本申请不作具体限定。

其中，捕获单元121用于获取待处理报文，其中，该待处理报文是向服务端210发送的报文，该待处理报文是TCP报文，包括ACK报文、PSH报文、SYN报文、FIN报文、RST报文、URG报文等待处理的TCP报文中的至少一种，其中，ACK报文用于确认报文序号，PSH报文用于提示接收方尽快将报文提交给应用层，SYN报文用于同步序号以发起连接，FIN报文用于结束连接，RST报文用于重建连接，URG报文用于传输紧急指针。简单来说，在TCP协议的建立和连接阶段所需传输的全部类型报文，都属于本申请的待处理报文。

应理解，TCP协议通常包括连接的建立阶段和连接的通信阶段，本申请在TCP协议的全部阶段下捕获单元121都可以进行待处理报文的识别的获取，换句话说，本申请的方案在TCP协议的全部阶段都可实现对TCP报文的拦截和处理，为TCP报文添加流量标签，从而解决由于传输过程中真实源地址信息发生变化导致一些网络方案实施困难的问题。

具体实现中，客户终端100所生成的报文包括TCP报文和非TCP报文，捕获单元121可基于客户终端100的系统协议栈识别和捕获客户终端100产的TCP报文。可选地，捕获单元121可以基于WFP的NetWork Layer shim拦截客户终端100上所有Inbound/Outbound网络层报文，对拦截到的所有报文进行协议识别，将非TCP报文放行，拦截TCP报文并将其交由标签生成单元122进行处理。

具体实现中，上述放行的非TCP报文可包括但不限于loopback报文、ipsec报文、协议栈增加(inject)发送的报文等等，还可包括没有FWPS_RIGHT_ACTION_WRITE权限的报文，当然还可包括其他非TCP报文，这里不一一举例说明。应理解，loopback报文是回环报文，换言之是自己发送自己接收的报文，该类报文不通过网络400进行传输，因此该类报文可以放行，不需要对其添加流量标签。ipsec报文用于为网络中传输的数据提高高质量的、可互操作的、基于密码学的安全保证，传输过程中的安全性很高，因此报文处理装置可以将其过滤放行，不对其进行处理。协议栈inject的报文指的是，协议栈对待处理报文添加流量标签，生成新的报文之后，待处理报文将会被删除，协议栈会根据报文处理顺序，逐个将携带有流量标签的报文重新inject到系统协议栈，然后一一发送给应用服务器200，因此inject的报文是携带有流量标签的报文，报文处理装置120可以对其进行过滤放行，避免出现二次添加流量标签的情况。携带有FWPS_RIGHT_ACTION_WRITE标志的报文指的是有权限进行过滤放行的报文，用户可以根据业务需求为部分TCP报文添加该标志，协议栈获取到的报文如果没有这个标志则对报文进行捕获，如果有这个标志则对该报文进行过滤放行，从而满足各种应用场景下的用户需求，提高用户的使用体验。

标签生成单元122用于根据捕获单元121获取的待处理报文，生成该待处理报文的流量标签，并将流量标签添加至待处理报文生成报文，上述流量标签包括该报文的传输链路的唯一标识，该流量标签在报文传输过程中不会发生改变。

参考前述内容可知，报文在从客户端110传输至服务端210的过程中，报文在网络400中会经过多个路由设备410、负载均衡器420、主体和客体，报文的报文头虽然记载有该报文的源地址信息，但是路由设备410和负载均衡器420可能会对报文头的一部分字段进行修改，恶意的主体和客体可能也会对报文进行修改，导致一部分源地址信息被修改，但是另一部分字段不会被修改，因此将流量标签添加至上述不会被修改的字段，使得报文传输过程中，报文头的源地址信息被修改，但是流量标签由于使用可选option字段进行传输，不是协议中预先约定的网络400需处理的字段，所以，流量标签不会被网络400中的任何设备进行修改，这里的任何设备包括但不限于负载均衡器、路由设备、主体和客体等等，使得服务端210接收到报文后，可以根据固定不变的流量标签追溯报文的传输链路，获知报文的真实源地址信息，从而解决由于传输过程中真实源地址信息发生变化导致一些网络方案实施困难的问题。

具体实现中，上述唯一标识可以是追踪身份证明(trace id)，标签生成单元122可以将trace id与报文的传输链路进行关联，作为一次网络请求的唯一标识，使得服务端210接收到报文后，可根据全局唯一的traceid获知报文的传输链路上的主体和客体。举例来说，如果服务端210所在的应用服务器200上的访问控制装置220基于应用安全保护技术(runtime application self-protection,RASP)实现对应用服务器200的网络安全防护，那么在RASP上报数据A时，标签生成单元122可以将用于传输数据A的报文的流量标签与数据A关联，这样服务端210所在的应用服务器200上的访问控制装置220可以根据报文的标签来确定关联的传输链路，获取整条传输链路上的主体和客体，从而解决由于传输过程中真实源地址信息发生变化导致一些网络方案实施困难的问题。

需要说明的，访问控制装置220根据报文的流量标签中的唯一标识(比如上述traceid)所确定的真实源地址信息至少包括客户终端的源IP地址、报文的传输链路中的主体和客体的信息，还可包括其他能够根据traceid确定的真实源地址信息，这里不一一举例说明。

可选地，上述traceid可以是使用雪花算法或者改进版雪花算法生成的ID，还可以是其他能够保证全局唯一、保证所生成的字符串不会出现重复的算法，比如根据时间戳生成ID、根据哈希算法生成ID等等，本申请不作具体限定。

在一实施例中，上述流量标签还可包括与报文相关的客户端110的进程信息，这里与报文相关的客户端110的进程可以是指参与生成报文的相关进程，进程信息包括但不限于进程名称、客户终端100名称、客户终端100名称、用户名称等，还可包括其他与报文相关的客户端110的进程信息，这里不一一举例说明。

参考前述内容可知，报文处理装置120可以以一种插件程序的形态安装于客户终端100的协议栈中，该插件程序可以在启动时采集客户终端100的相关信息，比如机器码、操作系统版本等等，协议栈驱动程序拦截到上层应用程序下发的待处理报文时，该插件程序可以采集当前的调用环境信息，包括进程信息、线程信息等等，标签生成单元122可以根据上述客户终端100、进程、线程等相关信息生成上述流量标签。

同理，访问控制装置220也可以以一种插件程序的形态安装于应用服务器200的协议栈中，这里不重复赘述。需要说明的，访问控制装置220接收到报文后，可根据报文中的流量标签中的进程信息，确定真实源地址信息，该真实源地址信息可包括报文传输链路中的主体和客体对应的进程服务信息，还可包括客户端110的进程信息，本申请不作具体限定。

具体实现中，标签生成单元122可以按照预设的格式生成流量标签，使得访问控制装置220可以根据预设格式对流量标签进行解析，获取标签中的进程信息和唯一标识，举例来说，标签格式可以为“traceid|进程名”，比如“00934df880e82cf2a6a1129965|outlook.exe”，其中，00934df880e82cf2a6a1129965为traceid，outlook.exe为进程名。上述举例用于说明，本申请不作具体限定。

在一实施例中，流量标签在报文中的位置可以包括报文传输过程中不会被传输链路中的任何设备修改的字段，这的任何设备包括但不限于路由设备、负载均衡器、主体和客体等等，可选地，标签生成单元122可以将流量标签嵌入待处理报文的可选(option)字段。

通常情况下，TCP报文为option字段预留的长度为0～40KB，但是大部分TCP报文的option字段为空，也就是0KB，少部分TCP报文的option字段存在option信息，但是option信息的长度也往往很小，比如3～5kb。因此，将流量标签添加至option字段，可以在不影响TCP报文原有内容的情况下实现流量标签的传输，使得报文通信效率不会受到影响。

可选地，该流量标签的长度和报文原有的option信息的长度之和不小于阈值，这里的阈值可以是40kb。举例来说，如果待传输的TCP报文原有的option信息长度为20KB，那么流量标签的长度不大于20KB，如果原有的option信息长度为1KB，那么流量标签的长度不大于39KB，本申请不作具体限定。

应理解，TCP报文包括报文头和荷载(payload)，荷载即为报文需要传输的数据，报文头包括多个字段，不同的字段可用于描述该报文的不同信息，比如源端口号和目的端口号字段、序号字段、首部长度字段、option字段等等。其中，option信息的长度通常为0～40kb，该字段是一个可变长的可选信息，一些报文可以有option字段，一些报文可以没有option字段(即option字段长度为0KB)，具体可根据实际的应用场景确定option字段的内容和占用的长度。在本申请实施例中，流量标签写入可变长的option字段，并且流量标签的长度与原有的option信息长度之和不超过可变长的option字段的最大长度(40KB)，使得流量标签嵌入待处理报文后，不会对待处理报文的payload产生影响，从而不影响报文的正常通信。

可选地，如果原有option字段与流量标签的长度之和超过阈值时，可以将流量标签的内容进行压缩，使得压缩后的流量标签长度与原有的option信息长度之和不超阈值。需要说明的，如果待处理报文原有的option信息已达到40KB，即报文的option字段在添加流量标签之间已被占满，那么标签生成单元122可以不生成流量标签，直接放行该报文，避免报文的正常通信被影响。如果待处理报文原有的option信息和流量标签的长度之和超过阈值，对极端情况可以不进行流量标签的嵌入，以免出现通信失败的问题。

可选地，流量标签也可以写入报文的payload中，还可以写入其他报文传输过程中不会被传输链路中的任何设备修改的字段，这的任何设备包括但不限于路由设备、负载均衡器、主体和客体等等，这里不一一举例说明。

可选地，上述流量标签还可包括其他客户端的信息，比如源IP地址和源端口、接口方式、接入区域、进程路径、进程链、命令行、文件签名、进程来源等，具体可根据实际业务场景确定，比如访问控制装置220需要根据文件签名实现某种网络安全方案，那么上述流量标签还可包括文件签名的信息，这里不一一展开举例。

具体实现中，由于待处理报文原有的option信息的长度和流量标签的长度不超过阈值，比如不超过40KB，标签生成单元122可以先确定待处理报文原有的option信息的长度，根据上述原有的option信息的长度和阈值确定流量标签的可用长度，然后根据上述流量标签的可用长度，结合具体的应用场景确定流量标签的内容。

举例来说，比如访问控制装置220需要根据文件签名、客户端110的进程名以及报文的传输链路中的主客体信息来实现某种网络安全方案，那么报文的流量标签至少应包括文件签名、进程信息和traceid，但是文件签名、进程信息和traceid的总长度为28KB，待处理报文的原有option字段长度为25KB，二者的总长度超过了预设的40KB，该场景下流量标签的长度不超过15KB，此时可以将文件签名从流量标签中删除，或者对标签内容进行压缩，使得流量标签长度小于15KB，或者本次报文传输不添加流量标签，避免由于option字段超过TCP报文头所规定的长度对报文payload产生影响，影响通信效率。应理解，上述举例用于说明，本申请不作具体限定。

发送单元123用于将标签生成单元122生成的携带有流量标签的报文，发送给访问控制装置220。

接收单元223用于接收报文处理装置120的发送单元123发送的报文，并将其交由确定单元222进行处理。

确定单元222用于根据报文的流量标签(比如traceid)确定报文的真实源地址信息，该真实源地址信息可包括源IP地址、报文传输链路中的主体和客体的信息。

应理解，在流量标签包括进程信息时，真实源地址信息还可包括报文传输链路中的主体和客体对应的进程服务信息。

需要说明的，真实源地址信息还可包括更多信息，比如传输链路中主体和客体的全部信息，客户端110的全部信息等等，具体可根据处理单元221对报文进行访问控制时所需的信息决定，本申请不作具体限定。

处理单元221用于根据真实源地址信息，对报文进行访问控制。

具体实现中，处理单元221可将真实源地址信息发送给网络方案策略中心300，网络方案策略中心300可以根据真实源地址信息确定访问是否合法，并向处理单元221发送反馈结果。根据网络方案策略中心300的反馈结果对报文进行访问控制，比如将报文进行放行或者阻止操作。

可选地，处理单元221也可在本地根据真实源地址信息确定访问是否合法，举例来说，确定单元222可根据traceid和进程信息查询客户端110的全部信息、报文传输链路中主体和客体的全部信息等等，基于客户端110的权限特征以及客户端110的进程特征，建立安全基线，生成安全策略，以此对报文进行访问控制，本申请不对此进行具体限定。

具体实现中，上述访问控制可以是网络安全访问控制，比如防火墙、入侵检测、入侵防御等等，也可以是流量计费、流量控制、异常报文溯源等，本申请不作具体限定。

举例来说，以流量计费为例，网络方案策略中心300可以基于流量标签中的源地址信息，查询发送报文的客户终端100的相关信息，比如客户终端100的地址信息、客户端信息、用户信息等等，结合用户的历史流量记录和购买的套餐来确定是否放行本次报文，如果用户的流量使用量超过其购买的套餐余额，那么网络方案策略中心300可以向访问控制装置220返回拒绝访问的信息，若没有超过其购买的套餐余额，可以向访问控制装置220返回同意访问的信息。应理解，上述举例用于说明，本申请不作具体限定。

再举例来说，报文的传输链路可包括图1所示的多个路由设备和负载均衡器，还可包括多个主体和客体，这里的主体可以是也通过该传输链路获取网络服务的其他客户终端，这里的客体可以是也通过该传输链路提供其他网络服务的应用服务器。以入侵检测的场景为例，网络方案策略中心300可以基于流量标签中的源地址信息，查询报文传输链路中的主体和客体以及发送报文的客户终端100的相关信息，比如报文传输链路中的上述各种设备的设备号、地址信息、进程信息等等，从而获知报文传输链路中的全部主体和客户终端100的访问权限，以及客体的访问进程特征，以此建立安安全基线，生成安全策略，确定本次传输链路中是否存在异常访问的主体或者异常的客体，如果存在异常可以向访问控制装置220返回拒绝访问的信息，若没有存在异常，可以向访问控制装置220返回同意访问的信息。应理解，上述举例用于说明，本申请不作具体限定。

图3是本申请提供的一种客户终端100的结构示意图，如图3所示，该客户终端可包括用户模式310、内核模式320以及网卡330，其中，用户模式310下，客户终端100运行的代码以对硬件的直接控制权限，也不能直接访问内存，程序是通过调用系统接口来达到访问硬件和内存的目的，该种模式下程序发生崩溃也可以恢复。内核模式320下，客户终端100运行的代码具有对硬件的所有控制权限，可以执行所有CPU指令，也可以访问任意地址的内存。内核模式为操作系统最底层、最可信的函数进行服务。

在本申请实施例中，用户模式310可包括客户端110和过滤规则140，其中，客户端110可参考图1和图2实施例中的描述，这里不重复赘述，过滤规则140可以是用户设定的，具体用于实现对客户端110生成的多个报文进行过滤，捕获其中的待处理报文，也就是TCP报文。

内核模式320可包括协议栈130和捕获单元121，其中，协议栈可包括标签生成单元122和发送单元123，其中，捕获单元121、标签生成单元122和发送单元123可参考图2实施例中的描述，这里不重复展开赘述。

需要说明的是，捕获单元121中的过滤引擎321可以根据过滤规则140，对协议栈130接收到的客户端110生成的多个报文进行过滤，获取多个报文中的TCP报文(比如图3所示的，拦截多个报文中的UDP报文1，捕获多个报文中的TCP报文1和TCP报文2)，并将其作为待处理报文发送给协议栈130，标签生成单元122可以为待处理报文添加流量标签获得报文，比如将TCP报文1添加流量标签获得TCP报文1’，为TCP报文2添加流量标签获得TCP报文2’。然后由发送单元123将携带有流量标签的TCP报文1’和TCP报文2’，以及被捕获单元121放行的报文UDP报文1，发送给应用服务器200。

网卡330可以是物理网卡或者虚拟网卡，本申请不作具体限定，发送单元123可通过网卡330向应用服务器200发送上述携带有流量标签的报文。

同理，应用服务器200也可包括用户模式、内核模式以及网卡，图4是本申请提供的一种应用服务器200的结构示意图，如图4所示，该应用服务器200可包括用户模式440、内核模式450以及网卡430，其中，用户模式440下，应用服务器200运行的代码以对硬件的直接控制权限，也不能直接访问内存，程序是通过调用系统接口来达到访问硬件和内存的目的，该种模式下程序发生崩溃也可以恢复。内核模式450下，应用服务器200运行的代码具有对硬件的所有控制权限，可以执行所有CPU指令，也可以访问任意地址的内存。内核模式为操作系统最底层、最可信的函数进行服务。

用户模式440可包括服务端210、确定规则240以及网络方案250，其中，服务端210可参考图1和图2实施例中的描述，这里不重复赘述。确定规则240可以是用户设定的，用于根据报文中的流量标签确定报文的源地址信息。网络方案250可以是用于实现访问控制时所需的方案策略，比如前述内容中的防火墙、入侵检测、入侵防御、流量计费、流量控制、异常报文溯源等，本申请不作具体限定。可选地，上述网络方案250可以是从网络方案策略中心300远程获取后存储至本地的方案。

具体实现中，用户可以根据网络方案250所需的源地址信息设置确定规则240，使得接收单元223获取到携带流量标签的报文之后，确定单元222可以根据确定规则240对流量标签进行解析，比如根据流量标签中的traceid确定报文传输链路中的全部主体和客体的信息，或者根据流量标签中的进程信息确定客户端110的进程的相关信息，本申请不作具体限定。

内核模式450可包括协议栈230、处理单元221以及确定单元222，其中，协议栈可包括接收单元223，需要说明的，处理单元221、确定单元222以及接收单元223的描述可参考图2实施例中的描述，这里不重复展开赘述。

网卡430可以是物理网卡或者虚拟网卡，本申请不作具体限定，发送单元接收单元223可通过网卡330接收由客户终端100发送的报文。该报文包括携带有流量标签的报文，也包括未携带流量标签的报文，以图3所示的应用场景为例，接收单元223通过网卡可接收UDP报文1、TCP报文1’以及TCP报文2’。

具体实现中，接收单元223接收UDP报文1、TCP报文1’以及TCP报文2’之后，将携带有流量标签的TCP报文1’以及TCP报文2’交由确定单元222，确定单元222中的确定引擎421可以根据确定规则240对TCP报文1’的流量标签进行分析，获得源地址信息1，对TCP报文2’的流量标签进行分析，获得源地址信息2。处理单元221的处理引擎422根据网络方案250结合源地址信息1确定是否对TCP报文1’进行放行，结合源地址信息2确定是否对TCP报文2’进行放行。放行的报文将会交由服务端210进行处理。

应理解，通过对客户终端100和应用服务器200的协议栈进行升级，内核模式下的协议栈拥有对操作系统的较高权限，使得客户终端100可以快速获取报文的相关信息，比如进程、线程、客户端信息、traceid等等，从而获得流量标签。而且为报文添加流量标签操作在系统协议栈进行，不需要使用代理，报文按照原有路径经过协议栈、网卡发送到应用服务，不影响原始报文的流动路径，对通信性能影响很小，提高用户的使用体验。

综上可知，本申请提供了一种报文处理系统，该系统可包括客户终端和应用服务器，客户终端可以生成携带有流量标签的报文，该流量标签可包括报文传输链路的唯一标识，在报文传输过程中，传输链路中的任何设备不会对该流量标签进行修改，使得应用服务器接收到报文后，可根据报文的该流量标签确定报文的传输链路中的主体和客体的信息，获得该报文的真实源地址信息，从而解决报文传输过程中由于源地址信息被修改导致网络访问控制失败、错误率高等问题。

图5是本申请提供的一种报文处理方法的步骤流程示意图，该方法可应用于图1所示的报文处理系统中，也可应用于如图2和图3所示的报文处理装置和访问控制装置中。如图5所示，该方法可包括以下步骤：

S301：报文处理装置120拦截客户端110生成的待处理报文，该步骤可以由图2和图3实施例中的捕获单元121实现。

具体实现中，客户端110可生成多个报文，比如UDP报文、TCP报文等等，本申请的待处理报文包括TCP报文，具体可包括TCP报文下的全部类型报文，比如ACK报文、PSH报文、SYN报文、FIN报文、RST报文、URG报文等等，其中，ACK报文用于确认报文序号，PSH报文用于提示接收方尽快将报文提交给应用层，SYN报文用于同步序号以发起连接，FIN报文用于结束连接，RST报文用于重建连接，URG报文用于传输紧急指针。简单来说，在TCP协议的建立和连接阶段所需传输的全部类型报文，都属于本申请的待处理报文。

在一实施例中，报文处理装置可以先拦截客户终端100上的Inbound/Outbound网络层报文，然后对拦截到的报文进行协议识别，过滤掉非TCP报文。具体实现中，报文处理装置120可以基于WFP的NetWork Layer shim拦截客户终端100上的Inbound/Outbound网络层报文，当然也可以使用其他技术手段对其进行拦截，本申请不作具体限定。

在一实施例中，报文处理装置过滤掉非TCP报文后，可以对保留的TCP报文进行进一步的过滤，过滤掉一些传输过程中源地址信息不会发生改变，或者应用服务器200的访问控制装置220不需要进行处理的TCP报文，举例来说，报文处理装置可以对loopback、ipsec报文进行放行。应理解，ipsec报文用于为网络中传输的数据提高高质量的、可互操作的、基于密码学的安全保证，传输过程中的安全性很高，因此报文处理装置可以将其过滤放行，不对其进行处理，应理解，上述举例用于说明，报文处理装置还可以对其他传输过程中源地址信息不会发生改变，或者应用服务器200的访问控制装置220不需要进行处理的TCP报文进行过滤放行，不为其添加流量标签，本申请不作具体限定。

在一实施例中，用户也可以设置一些过滤放行的TCP报文，为其添加放行标志，比如FWPS_RIGHT_ACTION_WRITE标志，该标志指示了报文有权限进行过滤放行，如果没有这个标志则对报文进行捕获，如果有这个标志则对该报文进行过滤放行，从而满足各种应用场景下的用户需求，提高用户的使用体验。

在一实施例中，报文处理装置也可以确定TCP报文是否是应用层发送的报文，如果不是应用层发送的报文，而是协议栈增加(inject)的报文，那么对TCP报文中的inject报文进行放行，应理解，报文处理装置在协议栈中对待处理报文添加流量标签，生成新的报文之后，待处理报文将会被删除，协议栈会根据报文处理顺序，逐个将携带有流量标签的报文重新inject到系统协议栈，然后一一发送给应用服务器200，因此inject的报文是携带有流量标签的报文，因此报文处理装置可以对其进行过滤放行，避免出现二次添加流量标签的情况。

需要说明的，报完处理装置过滤掉的报文，比如上述Inbound/Outbound网络层报文、非TCP报文、loopback报文、inject报文、拥有FWPS_RIGHT_ACTION_WRITE标志的报文等等，可以不对其添加流量标签，直接将其发送给应用服务器200。过滤后保留的待处理报文可以为其添加流量标签。

可以理解的，对于在传输过程中源地址信息不会发生改变，或者应用服务器200的访问控制装置220不需要进行处理的报文，报文处理装置120都可以将其过滤，从而降低客户终端100的处理压力，提高报文处理效率，减少对报文通信效率的影响。

S302：报文处理装置120生成待处理报文的流量标签。该步骤可以由图2和图3实施例中的标签生成单元122实现。

在一实施例中，上述流量标签可包括报文的传输链路的唯一标识，该标识在报文传输过程中不发生改变。具体实现中，上述唯一标识可以是trace id，报文处理装置120可以将生成的全局唯一的trace id与报文的传输链路进行关联，使得服务端210接收到报文后，可根据全局唯一的trace id获知报文的传输链路上的主体和客体。

可选地，上述traceid可以是使用雪花算法或者改进版雪花算法生成的ID，还可以是其他能够保证全局唯一、保证所生成的字符串不会出现重复的算法，比如根据时间戳生成ID、根据哈希算法生成ID等等，本申请不作具体限定。

在一实施例中，上述流量标签可包括报文的进程信息，其中，该进程信息可以是指参与生成报文的相关进程，进程信息包括但不限于进程名称、客户终端100名称、客户终端100名称、用户名称等，还可包括其他与报文相关的客户端110的进程信息，这里不一一举例说明。

具体实现中，报文处理装置120可以在生成traceid并将traceid与报文的传输链路进行关联之后，可以获取报文的进程数据生成进程信息，从而获得流量标签。其中，该进程数据可以是与报文的发起进程相关的数据，进程数据包括但不限于进程名、进程路径、进程链、命令行、文件签名、进程来源、客户端名、客户终端名、用户名等，具体可根据流量标签的内容确定获取的数据类型，本申请不作具体限定。

应理解，获取报文的进程数据之后，可以将进程数据的部分或者全部数据作为进程信息添加入流量标签，比如将进程数据中的进程名作为进程信息添加入流量标签；也可以对进程数据进行二次处理之后作为进程信息添加入流量标签，比如将进程信息编码压缩为二进制字符串之后作为进程信息添加入流量标签，本申请不作具体限定。

在一实施例中，上述流量标签还可包括更多或者更少的内容，比如流量标签还可包括网络数据，其中，网络数据包括但不限于源IP地址和源端口、目标IP地址和目标端口、接口方式、接入区域等，具体可根据实际业务场景确定，比如访问控制装置220需要根据文件签名实现某种网络安全方案，那么上述流量标签还可包括文件签名的信息，这里不一一展开举例。

具体实现中，报文处理装置120可以根据访问控制装置220对报文进行访问控制时所需的真实源地址信息，确定流量标签所需包括的内容，然后根据流量标签的内容确定协议栈生成流量标签时所需获取的进程数据和网络数据。这样，在后续报文处理过程中，协议栈为报文添加的流量标签可以供访问控制装置220获取真实源地址信息，从而解决报文传输过程中由于源地址信息被修改导致服务端的网络方案实施困难的问题。

在一实施例中，确定流量标签的内容之后，可以按照预设的格式生成流量标签，使得访问控制装置220可以根据预设格式对流量标签进行解析，获取标签中的进程信息和唯一标识，举例来说，标签格式可以为“traceid|进程名”，假设00934df880e82cf2a6a1129965为traceid，outlook.exe为进程名，那么流量标签可以为：“00934df880e82cf2a6a1129965|outlook.exe”，其中，上述举例用于说明，本申请不作具体限定。

参考前述内容可知，报文处理装置120可以以一种插件程序的形态安装于客户终端100的协议栈中，该插件程序可以在启动时采集客户终端100的相关信息，比如机器码、操作系统版本等等，协议栈驱动程序拦截到上层应用程序下发的待处理报文时，该插件程序可以采集当前的调用环境信息，包括进程信息、线程信息等等，标签生成单元122可以根据上述客户终端100、进程、线程等相关信息生成上述流量标签。

S303：报文处理装置120判断流量标签的长度是否合法。该步骤可由图2和图3实施例中的标签生成单元122实现。在长度合法的情况下执行步骤S304，在长度不合法的情况下执行步骤S310。

在一实施例中，报文处理装置120可以根据待处理报文的原有的option字段长度以及流量标签的长度判定流量标签是否合法。具体实现中，原有的option字段长度以及流量标签的长度之和小于阈值时，流量标签的长度合法，否则，流量标签的长度不合法。

举例来说，如果待传输的TCP报文原有的option字段长度为20KB，那么流量标签的长度不大于20KB，如果原有的option字段长度为1KB，那么流量标签的长度不大于39KB，本申请不作具体限定。

应理解，TCP报文包括报文头和荷载(payload)，荷载即为报文需要传输的数据，报文头包括多个字段，不同的字段可用于描述该报文的不同信息，比如源端口号和目的端口号字段、序号字段、首部长度字段、option字段等等。其中，option信息的长度通常为0～40kb，该字段是一个可变长的可选信息，一些报文可以有option字段，一些报文可以没有option字段(即option字段长度为0KB)，具体可根据实际的应用场景确定option字段的内容和占用的长度。在本申请实施例中，流量标签写入可变长的option字段之后，payload之前，并且所占用的空间大小与原有的option字段长度之和不超过option字段的最大长度(40KB)，使得流量标签嵌入待处理报文后，不会对待处理报文的内容进行修改，从而不影响报文的正常通信。

可选地，如果原有option字段与流量标签的长度之和超过阈值时，即步骤S303判断流量标签的长度不合法，可以先将流量标签的内容进行压缩，若压缩后的流量标签的长度与原有的option字段长度之和仍然超过阈值，则不执行步骤S304，执行步骤S310将其发送给应用服务器。

需要说明的，在步骤S302生成流量标签时，可以尽量缩短流量标签的长度，对于在传输过程中不会发生变化的源地址信息，或者，报文处理装置120不需要获取的源地址信息，不将其加入流量标签，避免出现流量标签过长导致其无法添加至待处理报文的情况。

S304：报文处理装置120将流量标签嵌入待处理报文，获得报文。该步骤可以由图2和图3实施例中的标签生成单元122实现。

参考前述内容可知，报文在从客户端110传输至服务端210的过程中，报文在网络400中会经过多个路由设备410、负载均衡器420、主体和客体，报文的报文头虽然记载有该报文的源地址信息，但是路由设备410和负载均衡器420可能会对报文头的一部分字段进行修改，存在恶意攻击的主体和客体也可能会对报文进行修改，导致一部分源地址信息被修改，但是另一部分字段不会被修改，因此将流量标签添加至上述不会被修改的字段，使得报文传输过程中，即使报文头的源地址信息被修改，但是流量标签不会被网络400中任何设备进行修改，这的任何设备包括但不限于路由设备、负载均衡器、主体和客体等等，使得服务端210接收到报文后，可根据固定不变的流量标签追溯报文的传输链路，获知报文的真实源地址信息，从而解决由于传输过程中真实源地址信息发生变化导致一些网络方案实施困难的问题。

具体实现中，流量标签在报文中的位置可以包括报文传输过程中不会被任何设备修改的字段。可选地，报文处理装置120可以将流量标签嵌入待处理报文的option字段。

通常情况下，TCP报文为option字段预留的长度为0～40KB，但是大部分TCP报文的option字段为空，也就是0KB，少部分TCP报文的option字段有option信息，但是option信息的长度也往往很小，比如3～5kb。因此，将流量标签添加至option字段，可以在不影响TCP报文原有内容的情况下实现流量标签的传输，使得报文通信效率不会受到影响。

可选地，该流量标签的长度和报文原有的option信息的长度之和不小于阈值，这里的阈值可以是40kb。举例来说，如果待传输的TCP报文原有的option信息长度为20KB，那么流量标签的长度不大于20KB，如果原有的option信息长度为1KB，那么流量标签的长度不大于39KB，本申请不作具体限定。

举例来说，图6是本申请提供的一种报文格式的示例图，如图6所示，该报文包括报文头和payload，其中，报文头包括源端口字段、目的端口字段、序号字段、确认号字段、数据偏移字段、保留字段、代码字段、窗口大小字段、校验和字段、紧急指针字段、可选(option)字段、流量标签。

需要说明的，流量标签位于待处理报文原有的option字段，例如图6所示的，流量标签被嵌入至报文原有的option信息之后。参考前述内容可知，流量标签的长度报文原有的option信息的长度之和小于阈值，具体可以是40kb，而TCP协议中定义的option信息的长度为0～40KB，这样，携带有流量标签的报文与待处理报文相比，payload和报文头的其他字段都不会产生影响，使得访问控制装置220接收到到报文时，只需要对流量标签进行解析，payload还可以按照原有的流程进行处理，使得本申请的方案可行性高，对现有的系统架构影响小，对报文的通信效率影响降到最小。

可选地，流量标签也可以写入报文的payload中，还可以写入其他报文传输过程中不会被传输链路中的任何设备修改的字段，这的任何设备包括但不限于路由设备、负载均衡器、主体和客体等等，这里不一一举例说明。

在一实施例中，报文处理装置120将流量标签写入报文传输过程中不会被任何设备修改的字段之后，果报文的部分字段发生了改变，那么报文处理装置120可以对报文进行修正，包括但不限于对TCP报文头中的数据偏移字段进行修正、对校验和字段进行修正等，应理解，上述举例用于说明，如果流量标签写入待处理报文之后，待处理报文的其他字段发生了改变，那么报文处理装置120也可以对其进行修正，这里不一一举例说明，本申请不作具体限定。

需要说明的是，待处理报文是传输层的TCP报文，对应的网络层报文是IP报文，该TCP报文在传输时会在TCP报文外侧添加IP报文头，IP报文的报文头包括报文总长度字段和校验和字段，由于流量标签嵌入了TCP报文的option字段导致TCP报文的总长度发生了改变，因此报文处理装置120可以对该TCP报文对应的IP报文头的报文总长度字段和校验和字段进行修正，同理，如果TCP报文外部添加有其他报文头，也可以根据实际情况对其进行修正，避免报文通信被影响。

具体实现中，报文处理装置120对报文的TCP报文头以及外部的其他报文头(比如IP报文头)进行修正之后，生成上述携带有流量标签的报文，然后可以将原始的待处理报文进行丢弃，并按照原始的待处理报文的发送顺序，逐个将新生成的报文inject到协议栈中。

S305：报文处理装置120向应用服务器200发送报文。该步骤可以由图2和图3中的发送单元123实现。

具体实现中，报文处理装置120可以根据协议栈中的待发送队列，按照发送顺序将协议栈新生成的携带有流量标签的报文发送至应用服务器200。具体可通过图3中的网卡330实现报文的发送。

S306：访问控制装置220根据流量标签确定真实源地址信息。该步骤可以由图2和图4中的接收单元223和确定单元222实现。

具体实现中，访问控制装置220可以根据流量标签中的唯一标识，比如trace id确定报文的真实源地址信息，该真实源地址信息科包括报文传输链路中的主体和客体的信息，以及源IP地址的信息。可选地，在流量标签包括进程信息时，真实源地址信息还可包括报文传输链路中的主体和客体对应的进程服务信息。

需要说明的，真实源地址信息还可包括更多信息，比如传输链路中主体和客体的全部信息，客户端110的全部信息等等，具体可根据流量标签的内容决定，本申请不作具体限定。参考步骤S302～步骤S304可知，流量标签的内容是根据报文原有的option信息的长度，以及访问控制装置220实现访问控制时所需的源地址信息决定的。

需要说明的，访问控制装置220也可以根据流量标签，结合报文头中的其他信息确定上述真实源地址信息，本申请不作具体限定。当然，如果报文头中的部分信息可以直接被访问控制装置220使用，该部分信息可以不被写入流量标签，从而尽可能缩短流量标签的长度。

S307：访问控制装置220对报文进行访问控制。该步骤可以由图2和图4中的处理单元221实现。具体地，在访问通过的情况下执行步骤S308，在访问拒绝的情况下执行步骤S309。

具体实现中，访问控制装置220可将真实源地址信息发送给网络方案策略中心300，网络方案策略中心300可以根据真实源地址信息确定访问是否合法，并向处理单元221发送反馈结果。根据网络方案策略中心300的反馈结果对报文进行访问控制，比如将报文进行放行或者阻止操作。

可选地，访问控制装置220也可在本地根据真实源地址信息确定访问是否合法，举例来说，可根据traceid和进程信息查询客户端110的全部信息、报文传输链路中主体和客体的全部信息等等，基于客户端110的权限特征以及客户端110的进程特征，建立安全基线，生成安全策略，以此对报文进行访问控制，本申请不对此进行具体限定。

具体实现中，上述访问控制可以是网络安全访问控制，比如防火墙、入侵检测、入侵防御等等，也可以是流量计费、流量控制、异常报文溯源等，本申请不作具体限定。

举例来说，以流量计费为例，访问控制装置220可以基于流量标签中的源地址信息，查询发送报文的客户终端100的相关信息，比如客户终端100的地址信息、客户端信息、用户信息等等，结合用户的历史流量记录和购买的套餐来确定拒绝或通过本次报文的访问，如果用户的流量使用量超过其购买的套餐余额，那么访问控制装置220可以拒绝访问，若没有超过其购买的套餐余额，访问控制装置220可以通过本次访问。应理解，上述举例用于说明，本申请不作具体限定。

再举例来说，报文的传输链路可包括图1所示的多个路由设备和负载均衡器，还可包括多个主体和客体，这里的主体可以是也通过该传输链路获取网络服务的其他客户终端，这里的客体可以是也通过该传输链路提供其他网络服务的应用服务器。以入侵检测的场景为例，访问控制装置220可以基于流量标签中的源地址信息，查询报文传输链路中的主体和客体以及发送报文的客户终端100的相关信息，比如报文传输链路中的上述各种设备的设备号、地址信息、进程信息等等，从而获知报文传输链路中的全部主体和客户终端100的访问权限，以及客体的访问进程特征，以此建立安安全基线，生成安全策略，确定本次传输链路中是否存在异常访问的主体或者异常的客体，如果存在异常可以向访问控制装置220拒绝本次报文的访问，若没有存在异常，可以向访问控制装置220通过本次报文的访问。应理解，上述举例用于说明，本申请不作具体限定。

S308：服务端210对报文进行处理。应理解，访问控制装置220对报文进行放行后，服务端210可以对报文进行处理。具体可参考图1实施例中关于服务端210的描述，这里不重复赘述。

S309：访问控制装置220向客户端110返回访问拒绝的消息。该步骤可以由图2和图4实施例中的处理单元221实现。

简单来说，访问控制装置220判断报文异常，拒绝接收该报文，以实现网络安全防护、流量控制、流量计费等功能，本申请不作具体限定。

S310：报文处理装置120向应用服务器200发送待处理报文。该步骤可以由图2和图4实施例中的处理单元221实现。

简单来说，如果报文原有option字段与流量标签的长度之和超过阈值时，可以不将流量标签嵌入待处理报文，从而避免报文的正常通信。值得注意的是，TCP报文原有的option字段多数为空，即使原有的option字段被占用，占用长度通常也很小，有足量的空间可以用来嵌入流量标签，因此对极端情况可以不进行流量标签的嵌入，以免出现通信失败的问题。

在一实施例中，报文处理装置120可以以一种插件程序的形态安装于客户终端100的协议栈中，该插件程序可以在启动时采集客户终端100的相关信息，比如机器码、操作系统版本等等，如果访问控制装置220的进行访问控制时需要客户终端100的相关信息，该插件程序可以将其保存，以便后续参与流量标签的生成。当协议栈驱动程序拦截到上层应用程序下发的待处理报文时，该插件程序可以采集当前的调用环境信息，包括进程信息、线程信息等等，根据访问控制装置220在进行访问控制时所需的真实源地址信息、结合待处理报文的原有option字段占用长度，生成流量标签，并将其添加至option字段。具体可参考图3实施例中关于协议栈实现报文处理装置120各种功能的描述，这里不重复赘述。

同理，访问控制装置220也可以以一种插件程序的形态安装于应用服务器200的协议栈中，这里不重复赘述。

应理解，通过协议栈来实现上述报文处理装置120和访问控制装置220的各种功能，使得方案实施简单，只需要对客户终端100和应用服务器200的协议栈进行升级，比如安装有能够实现步骤S301～步骤S310功能的插件程序，协议栈处于内核模式下，其获取的进程信息更加准确和快捷，而且无需安装各种代理，不会影响原始待处理报文的传输，对客户端110和服务端210之间通信性能和交互产生的影响很小。

综上可知，本申请提供了一种报文处理方法，应用于报文处理系统中，该系统可包括客户终端和应用服务器，客户终端可以生成携带有流量标签的报文，该流量标签可包括报文传输链路的唯一标识，在报文传输过程中，传输链路中的任何设备不会对该流量标签进行修改，使得应用服务器接收到报文后，可根据报文的该流量标签确定报文的传输链路中的主体和客体的信息，获得该报文的真实源地址信息，从而解决报文传输过程中由于源地址信息被修改导致网络访问控制失败、错误率高等问题。

作为一种可能的实现方式，流量标签除了通过上述TCP报文头的可选Option字段传输外，还可以通过其他未被使用字段传输，例如，静荷中可选字段或TCP报文中其他未被使用的字段进行传输。

图7是本申请提供的一种计算设备的结构示意图，该计算设备600是图1至图6实施例中的客户终端100或者应用服务器200。

进一步地，计算设备600包括处理器601、存储单元602、存储介质603和通信接口604，其中，处理器601、存储单元602、存储介质603和通信接口604通过总线605进行通信，也通过无线传输等其他手段实现通信。

处理器601由至少一个通用处理器构成，例如CPU、NPU或者CPU和硬件芯片的组合。上述硬件芯片是专用集成电路(Application-Specific Integrated Circuit，ASIC)、编程逻辑器件(Programmable Logic Device，PLD)或其组合。上述PLD是复杂编程逻辑器件(Complex Programmable Logic Device，CPLD)、现场编程逻辑门阵列(Field-Programmable Gate Array，FPGA)、通用阵列逻辑(Generic Array Logic，GAL)或其任意组合。处理器601执行各种类型的数字存储指令，例如存储在存储单元602中的软件或者固件程序，它能使计算设备600提供较宽的多种服务。

具体实现中，作为一种实施例，处理器601包括一个或多个CPU，例如图7中所示的CPU0和CPU1。

在具体实现中，作为一种实施例，计算设备600也包括多个处理器，例如图7中所示的处理器601和处理器606。这些处理器中的每一个可以是一个单核处理器(single-CPU)，也可以是一个多核处理器(multi-CPU)。这里的处理器指一个或多个设备、电路、和/或用于处理数据(例如计算机程序指令)的处理核。

存储单元602用于存储程序代码，并由处理器601来控制执行，以执行上述图1-图6中任一实施例中计算节点的处理步骤。程序代码中包括一个或多个软件单元。

在计算设备600为前述内容中的客户终端100时，上述一个或多个软件单元是图2和图3实施例中的捕获单元、标签生成单元以及发送单元，其中，捕获单元用于获取客户端生成的多个报文中的待处理报文，这里的待处理报文可以是TCP报文，标签生成单元用于生成流量标签并将其嵌入待处理报文，生成报文，发送单元用于将上述携带有流量标签的报文发送至应用服务器。其中，捕获单元用于执行图5实施例中的步骤S301及其可选步骤，标签生成单元用于执行步骤S302～步骤S304及其可选步骤，发送单元用于执行图5实施例中的步骤S305、步骤S310及其可选步骤，此处不再赘述。

在计算设备600为前述内容中的应用服务器200时，上述一个或多个软件单元是图2实施例中的接收单元、确定单元和处理单元，其中，接收单元用于接收客户终端发送的报文，确定单元用于根据报文中的流量标签确定报文的源地址信息，处理单元用于根据源地址信息实现访问控制。其中，接收单元用于执行图5实施例中的步骤S305及其可选步骤，确定单元用于执行图5实施例中的步骤S306及其可选步骤，处理单元用于执行图5中的步骤S307、步骤S309及其可选步骤，此处不再赘述。

存储单元602包括只读存储器和随机存取存储器，并向处理器601提供指令和数据。存储单元602还包括非易失性随机存取存储器。存储单元602是易失性存储器或非易失性存储器，或包括易失性和非易失性存储器两者。其中，非易失性存储器是只读存储器(read-only memory，ROM)、编程只读存储器(programmable ROM，PROM)、擦除编程只读存储器(erasable PROM，EPROM)、电擦除编程只读存储器(electrically EPROM，EEPROM)或闪存。易失性存储器是随机存取存储器(random access memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM用，例如静态随机存取存储器(static RAM，SRAM)、动态随机存取存储器(DRAM)、同步动态随机存取存储器(synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(double data date SDRAM，DDR SDRAM)、增强型同步动态随机存取存储器(enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(synchlink DRAM，SLDRAM)和直接内存总线随机存取存储器(direct rambus RAM，DRRAM)。还是硬盘(hard disk)、U盘(universal serial bus，USB)、闪存(flash)、SD卡(secure digital memory Card,SD card)、记忆棒等等，硬盘是硬盘驱动器(hard diskdrive,HDD)、固态硬盘(solid state disk,SSD)、机械硬盘(mechanical hard disk,HDD)等，本申请不作具体限定。

存储介质603是存储数据的载体，比如硬盘(hard disk)、U盘(universal serialbus，USB)、闪存(flash)、SD卡(secure digital memory Card,SD card)、记忆棒等等，硬盘可以是硬盘驱动器(hard disk drive,HDD)、固态硬盘(solid state disk,SSD)、机械硬盘(mechanical hard disk,HDD)等，本申请不作具体限定。

通信接口604为有线接口(例如以太网接口)，为内部接口(例如高速串行计算机扩展总线(Peripheral Component Interconnect express,PCIe)总线接口)、有线接口(例如以太网接口)或无线接口(例如蜂窝网络接口或使用无线局域网接口)，用于与其他服务器或单元进行通信。

总线605是快捷外围部件互联标准(Peripheral Component InterconnectExpress，PCIe)总线，或扩展工业标准结构(extended industry standard architecture，EISA)总线、统一总线(unified bus，Ubus或UB)、计算机快速链接(compute express link，CXL)、缓存一致互联协议(cache coherent interconnect for accelerators，CCIX)等。总线605分为地址总线、数据总线、控制总线等。

总线605除包括数据总线之外，还包括电源总线、控制总线和状态信号总线等。但是为了清楚说明起见，在图中将各种总线都标为总线605。

需要说明的，图7仅仅是本申请实施例的一种能的实现方式，实际应用中，计算设备600还包括更多或更少的部件，这里不作限制。关于本申请实施例中未示出或未描述的内容，参见前述图1-图6实施例中的相关阐述，这里不再赘述。

本申请实施例提供一种计算机存储介质，包括：该计算机存储介质中存储有指令；当该指令在计算设备上运行时，使得该计算设备执行上述图1至图6描述的作业运行方法。

上述实施例，全部或部分地通过软件、硬件、固件或其他任意组合来实现。当使用软件实现时，上述实施例全部或部分地以计算机程序产品的形式实现。计算机程序产品包括至少一个计算机指令。在计算机上加载或执行计算机程序指令时，全部或部分地产生按照本发明实施例的流程或功能。计算机为通用计算机、专用计算机、计算机网络、或者其他编程装置。计算机指令存储在计算机读存储介质中，或者从一个计算机读存储介质向另一个计算机读存储介质传输，例如，计算机指令从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line,DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。计算机读存储介质是计算机能够存取的任何用介质或者是包含至少一个用介质集合的服务器、数据中心等数据存储节点。用介质是磁性介质(例如，软盘、硬盘、磁带)、光介质(例如，高密度数字视频光盘(digital video disc,DVD)、或者半导体介质。半导体介质是SSD。

以上，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，轻易想到各种等效的修复或替换，这些修复或替换都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。

Claims (14)

1.一种报文处理方法，其特征在于，所述方法应用于报文处理系统，所述报文处理系统包括客户终端和应用服务器，所述方法包括：

所述应用服务器接收客户终端发送的报文，所述报文的可选字段包括由所述客户终端为所述报文添加的流量标签，所述流量标签包括所述报文的传输链路的唯一的标识；

所述应用服务器根据所述报文的流量标签确定所述报文的真实源地址信息；

所述应用服务器根据所述真实源地址信息对所述报文实现网络访问控制。

2.根据权利要求1所述的方法，其特征在于，所述流量标签还包括与所述报文相关的客户终端进程的进程信息，所述进程信息包括进程名称、客户终端名称、用户名称中的一种或者多种，所述真实源地址信息包括所述报文的传输链路中的主体和客体对应的进程信息。

3.根据权利要求1或2所述的方法，其特征在于，所述报文包括TCP报文、ACK报文、PSH报文、SYN报文、FIN报文中的任一种。

4.根据权利要求1至3任一权利要求所述的方法，其特征在于，所述流量标签位于所述报文的可选option字段，所述流量标签的长度和所述报文option字段的原有数据的长度之和不小于阈值。

5.一种访问控制装置，其特征在于，所述访问控制装置部署于应用服务器，所述装置包括：

接收单元，用于接收客户终端发送的报文，所述报文的可选字段包括流量标签，所述流量标签包括所述报文的传输链路的唯一的标识，所述标识在所述报文传输过程中不发生改变；

确定单元，用于根据所述报文的流量标签确定所述报文的真实源地址信息；

处理单元，用于根据所述真实源地址信息对所述报文实现网络访问控制。

6.根据权利要求5所述的装置，其特征在于，所述流量标签还包括与所述报文相关的客户终端进程的进程信息，所述进程信息包括进程名称、客户终端名称、用户名称中的一种或者多种，所述真实源地址信息包括所述报文的传输链路中的主体和客体对应的进程信息。

7.根据权利要求5或6所述的装置，其特征在于，所述报文包括TCP报文、ACK报文、PSH报文、SYN报文、FIN报文中的任一种。

8.根据权利要求5至7任一权利要求所述的装置，其特征在于，所述流量标签位于所述报文的可选option字段,所述流量标签的长度和所述报文option字段的原有数据的长度之和不小于阈值。

9.一种报文处理装置，其特征在于，所述报文处理装置部署于客户终端，所述装置包括：

发送单元，用于向应用服务器发送报文，所述报文的可选字段包括流量标签，所述流量标签包括所述报文的传输链路的唯一的标识，所述标识在所述报文传输过程中不发生改变，所述流量标签用于供所述应用服务器确定所述报文的真实源地址信息，根据所述真实源地址信息对所述报文实现网络访问控制。

10.根据权利要求9所述的装置，其特征在于，所述流量标签还包括与所述报文相关的客户终端进程的进程信息，所述进程信息包括进程名称、客户终端名称、用户名称中的一种或者多种，所述真实源地址信息包括所述报文的传输链路中的主体和客体对应的进程信息。

11.根据权利要求9或10所述的装置，其特征在于，所述报文包括TCP报文、ACK报文、PSH报文、SYN报文、FIN报文中的任一种。

12.根据权利要求9至11任一权利要求所述的装置，其特征在于，所述流量标签位于所述报文的可选option字段，所述流量标签的长度和所述报文option字段的原有数据的长度之和不小于阈值。

13.一种报文处理系统，其特征在于，所述系统包括报文处理装置和访问控制装置，所述报文处理装置用于实现如权利要求9至12中任一权利要求所述的功能模块，所述访问控制装置用于实现如权利要求5至8中任一权利要求所述的功能模块。

14.一种计算设备，其特征在于，所述计算设备包括处理器和存储器，所述存储器用于存储指令，所述处理器用于运行所述指令实现如权利要求1至4任一权利要求所述客户终端所执行操作步骤的功能。