CN110830541A

CN110830541A - 一种消息处理方法、装置及系统

Info

Publication number: CN110830541A
Application number: CN201810924407.1A
Authority: CN
Inventors: 程镒平; 戚彩霞; 陈靖
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2018-08-14
Filing date: 2018-08-14
Publication date: 2020-02-21
Anticipated expiration: 2038-08-14
Also published as: CN110830541B; US11310323B2; EP3787259A1; WO2020034843A1; US20210099527A1; EP3787259A4; EP3787259B1

Abstract

本申请提供一种消息处理方法、装置及系统。该方法包括：第一网元与第二网元之间建立了第一HTTP交互流程，第一网元在第一HTTP交互流程中向第二网元发送第一请求消息，且在第一网元接收到第一HTTP交互流程中的针对上述第一请求消息的第一响应消息之前，第二网元发起建立了第一网元与第二网元之间的第二HTTP交互流程且第一网元接收到第二网元发送的第二请求消息。此时，若直接对第二请求消息进行处理则可能导致在错误的时间处理第二请求消息，因此第一网元根据第一HTTP交互流程与第二HTTP交互流程的关系执行对第二请求消息的操作，有助于避免在错误的时间处理第二请求消息，可实现第一网元与第二网元之间的消息的有序交互。

Description

一种消息处理方法、装置及系统

技术领域

本申请涉及移动通信技术领域，尤其涉及一种消息处理方法、装置及系统。

背景技术

第五代(the 5th generation，5G)通信的控制面采用服务化架构，服务化架构中包括多个网络功能(network funciton，NF)网元，NF网元之间通过服务化接口通信，一个NF网元可以在一个服务化接口中开放多个服务给其他NF网元。当NF网元作为NF服务的提供方时，该NF网元可以称为NF服务生产者，当NF网元作为NF服务的使用方时，该NF网元可以称为NF服务消费者。

服务化接口采用超文本传输协议(HyperText Transfer Protocol，HTTP)/2作为应用层的传输协议，传输控制协议(Transmission Control Protocol，TCP)作为链路层的传输协议，且HTTP连接建立在TCP连接之上。

由于各个NF网元可能同时处于不同的NF服务的生产者或消费者角色，同时NF网元之间的业务流程是通过多个服务化接口相互调用完成的，因此在进行业务流程时，两个NF网元相互向对方发送HTTP请求消息，形成两次独立的HTTP交互流程，这两次独立的HTTP交互流程是在不同的TCP连接上进行的，因此可能导致这两个NF网元之间的消息存在交互乱序的情形。

发明内容

本申请提供一种消息处理方法、装置及系统，用以实现两个NF网元之间的消息的有序交互。

第一方面，本申请提供一种消息处理方法。该方法包括：第一网元向第二网元发送第一请求消息，第一请求消息属于第一HTTP交互流程；第一网元在接收到针对第一请求消息的第一响应消息之前，接收来自第二网元的第二请求消息，第一响应消息属于第一HTTP交互流程，第二请求消息属于第二HTTP交互流程；第一网元根据第一HTTP交互流程与第二HTTP交互流程的关系，执行对第二请求消息的操作。基于该方案，第一网元与第二网元之间建立了第一HTTP交互流程，第一网元在第一HTTP交互流程中向第二网元发送第一请求消息，且在第一网元接收到第一HTTP交互流程中的针对上述第一请求消息的第一响应消息之前，第二网元发起建立了第一网元与第二网元之间的第二HTTP交互流程且第一网元接收到第二网元发送的第二请求消息。此时，若直接对第二请求消息进行处理则可能导致在错误的时间处理第二请求消息，因此第一网元根据第一HTTP交互流程与第二HTTP交互流程的关系执行对第二请求消息的操作，有助于避免在错误的时间处理第二请求消息，进而可实现第一网元与第二网元之间的消息的有序交互。

针对根据第一HTTP交互流程与第二HTTP交互流程的关系执行对第二请求消息的操作，下面给出不同的实现方法。

实现方法一，第一网元确定第一HTTP交互流程与第二HTTP交互流程相互独立，则处理第二请求消息。

该实现方法中，由于第一HTTP交互流程与第二HTTP交互流程相互独立，或者理解为，第一HTTP交互流程与第二HTTP交互流程之间没有相互依赖关系。因此，第一网元在接收到第二请求消息后，可以处理该第二请求消息，而无需等待接收并处理第一HTTP交互流程中的第一响应消息之后再处理该第二请求消息。

进一步的，在一种实现方式中，第一网元处理第二请求消息之后，还可以向第二网元发送针对第二请求消息的第二响应消息。进一步的，在发送第二响应消息之后若接收来自第二网元的第一响应消息，则处理该第一响应消息。其中，第二响应消息属于第二HTTP交互流程。

进一步的，在又一种实现方式中，第一网元处理第二请求消息之后，若接收到来自第二网元的第一响应消息则处理该第一响应消息。进一步的，在处理第一响应消息之后还可以向第二网元发送针对第二请求消息的第二响应消息。其中，第二响应消息属于第二HTTP交互流程。

实现方法二，第一网元确定第二HTTP交互流程依赖于第一HTTP交互流程，且不能拒绝第二请求消息，则缓存第二请求消息。第一网元在接收并处理第一响应消息之后，处理第二请求消息。

该实现方法中，由于第二HTTP交互流程依赖于第一HTTP交互流程，并且不能拒绝该第二请求消息，则第一网元可以先缓存该第二请求消息。在第一网元接收并处理第一响应消息之后，再获取缓存的第二请求消息，然后处理该第二请求消息。其中，第二HTTP交互流程依赖于第一HTTP交互流程，可以理解为第一网元在处理第二请求消息时，依赖于第一网元接收到的第一响应消息，因此需要先接收并处理第一响应消息。

进一步的，第一网元处理第二请求消息之后，还可以向第二网元发送针对第二请求消息的第二响应消息，该第二响应消息属于第二HTTP交互流程。

实现方法三，第一网元确定第二HTTP交互流程依赖于第一HTTP交互流程，且能够拒绝第二请求消息，则向第二网元发送拒绝消息。

该实现方法中，由于第二HTTP交互流程依赖于第一HTTP交互流程，并且可以拒绝该第二请求消息，则第一网元可以拒绝该第二请求消息，即向第二网元发送拒绝消息。后续第二网元再重新发起请求消息。

作为一种实现方式，第一网元向第二网元发送的拒绝消息可以包括设定时长，该设定时长用于指示第二网元在设定时长后重新发起请求消息。该设定时长也可以理解为一个定时器。进一步的，第一网元向第二网元发送拒绝消息之后，若接收到来自第二网元的第一响应消息，则处理第一响应消息。在处理第一响应消息之后，若接收到第二网元在设定时长到达时发送的第三请求消息，则处理该第三请求消息，该第三请求消息为针对第二请求消息重新发起的请求消息。进一步的，第一网元还可以向第二网元发送针对第三请求消息的第三响应消息，该第三响应消息属于第二HTTP交互流程。需要说明的是，若第一网元在接收到第三请求消息时，第一网元还未接收到第一响应消息或者还未处理第一响应消息，则第一网元可以再次向第二网元发送拒绝消息。

作为又一种实现方式，第一网元向第二网元发送拒绝消息之后，第一网元接收来自第二网元的第一响应消息并处理第一响应消息。第一网元在处理第一响应消息之后，可以向第二网元发送重发请求消息，该重发请求消息用于触发第二网元重新发起针对第二请求消息的请求消息。第二网元在接收到重发请求消息后可以向第一网元发送第三请求消息，该第三请求消息为针对第二请求消息重新发起的请求消息。接着，第一网元处理第三请求消息，并向第二网元发送针对第三请求消息的第三响应消息，该第三响应消息属于第二HTTP交互流程。

实现方法四，第一网元确定第二HTTP交互流程的优先级高于第一HTTP交互流程，则处理第二请求消息。

该实现方法中，第一网元若确定第二HTTP交互流程的优先级高于第一HTTP交互流程，则在接收到第二请求消息时，尽管还未接收到第一HTTP交互流程中的第一响应消息，第一网元仍然优先处理第二请求消息。

进一步的，第一网元处理第二请求消息之后，若接收到来自第二网元的第一响应消息，则丢弃该第一响应消息。

第二方面，本申请提供一种消息处理方法。该方法包括：第一网元向第二网元发送第一消息，第一消息包括重置标志信息和序列号。第一网元将第一消息的序列号作为第一网元的交互序列号，将第一网元的交互序列号增加设定步长后作为第一网元的等待序列号。第二网元接收来自第一网元的第一消息。若重置标志信息为第一重置标志信息且第一消息的序列号与第二网元的等待序列号相同，则第二网元处理第一消息，以及将第一消息的序列号作为第二网元的交互序列号，将第二网元的交互序列号增加设定步长后作为第二网元的等待序列号。其中，第一网元的交互序列号用于指示第一网元与第二网元当前交互的消息的序列号，第一网元的等待序列号用于指示第一网元当前等待的下一条消息的序列号，第二网元的交互序列号用于指示第二网元与第一网元当前交互的消息的序列号，第二网元的等待序列号用于指示第二网元当前等待的下一条消息的序列号。基于该方案，第一网元记录交互序列号和等待序列号，第二网元也记录交互序列号和等待序列号。当第一网元向第二网元发送第一消息时，第二网元若确定第一消息携带的重置标志信息为第一重置标志信息，则确定该第一消息是第一网元与第二网元之间交互的非首条消息，即可以理解为，第一重置标志信息用于指示第一消息为第一网元与第二网元之间交互的非首条消息。接着，第二网元若确定第二网元的等待序列号与第一消息的序列号相同，则确定该第一消息是当前等待处理的消息，因此可以处理该第一消息。进一步的，第一网元在发送第一消息后还需要更新本地记录的交互序列号和等待序列号，同样的，第二网元在处理第一消息后也需要更新本地记录的交互序列号和等待序列号。如此，可以实现第一网元和第二网元之间的消息的有序交互。

作为一种实现方式，上述实施例中，若重置标志信息为第一重置标志信息且第一消息的序列号与第二网元的等待序列号不同，表明该第一消息是乱序的消息，则第二网元缓存第一消息。即第二网元确定第一消息不是等待的消息，则先缓存该第一消息。进一步的，第二网元可以接收第一网元发送的其他消息，或者向第一网元发送其他消息，并更新本地存储的交互序列号和等待序列号。接着，可以判断第二网元的当前的等待序列号与第一消息的序列号是否相同，若相同则处理第一消息，然后将第一消息的序列号作为第二网元的交互序列号，将第二网元的交互序列号增加设定步长后作为第二网元的等待序列号。若不相同则仍然不处理该第一消息直到确定第二网元的当前的等待序列号与第一消息的序列号相同再处理该第一消息。如此可以实现对消息的有序处理。

作为又一种实现方式，上述实施例中，若重置标志信息为第二重置标志信息，则确定该第一消息是第一网元与第二网元之间交互的首条消息，即可以理解为，第二重置标志信息用于指示第一消息为第一网元与第二网元之间交互的首条消息，因而第二网元可以处理该第一消息。然后第二网元将第一消息的序列号作为第二网元的交互序列号，将第二网元的交互序列号增加设定步长后作为第二网元的等待序列号。

在第二网元接收到第一响应消息之后，进一步的，第二网元还可以向第一网元发送第二消息，第二消息包括第一重置标志信息和序列号，第二消息的序列号为第二网元当前的交互序列号与设定步长之和，第二网元将第二消息的序列号作为第二网元的交互序列号，将第二网元的交互序列号增加设定步长后作为第二网元的等待序列号。第一网元接收来自第二网元的第二消息，若第二消息的序列号与第一网元的等待序列号相同，则第一网元处理第二消息，以及将第二消息的序列号作为第一网元的交互序列号，将第一网元的交互序列号增加设定步长后作为第一网元的等待序列号；若第二消息的序列号与第一网元的等待序列号不同，则第一网元缓存第二消息。

第三方面，本申请还提供一种消息处理方法。该方法包括：第一网元向第二网元发送第一消息，第一消息包括序列号。第一网元将第一消息的序列号作为第一网元的交互序列号，将第一网元的交互序列号增加设定步长后作为第一网元的等待序列号。其中，第一网元的交互序列号用于指示第一网元与第二网元当前交互的消息的序列号，第一网元的等待序列号用于指示第一网元等待的下一条消息的序列号。

在一种可能的实现方式中，第一消息还包括第二重置标志信息，第二重置标志信息用于指示第一消息为第一网元与第二网元之间交互的首条消息。

在又一种可能的实现方式中，第一消息还包括第一重置标志信息，第一重置标志信息用于指示第一消息为第一网元与第二网元之间交互的非首条消息。

第四方面，本申请还提供一种消息处理方法。该方法包括：第二网元接收来自第一网元的第一消息，第一消息包括重置标志信息和序列号；若重置标志信息为第一重置标志信息且第一消息的序列号与第二网元的等待序列号相同，则第二网元处理第一消息，以及将第一消息的序列号作为第二网元的交互序列号，将第二网元的交互序列号增加设定步长后作为第二网元的等待序列号；其中，第二网元的交互序列号用于指示第二网元与第一网元当前交互的消息的序列号，第二网元的等待序列号用于指示第二网元当前等待的下一条消息的序列号。基于该方案，当第一网元向第二网元发送第一消息时，第二网元若确定第一消息携带的重置标志信息为第一重置标志信息，则确定该第一消息是第一网元与第二网元之间交互的非首条消息，即可以理解为，第一重置标志信息用于指示第一消息为第一网元与第二网元之间交互的非首条消息。接着，第二网元若确定第二网元的等待序列号与第一消息的序列号相同，则确定该第一消息是当前等待处理的消息，因此可以处理该第一消息。进一步的，第二网元在处理第一消息后也需要更新本地记录的交互序列号和等待序列号。如此，可以实现第一网元和第二网元之间的消息的有序交互。

作为又一种实现方式，上述实施例中，若重置标志信息为第二重置标志信息，则确定该第一消息是第一网元与第二网元之间交互的首条消息，即可以理解为，第一重置标志信息用于指示第一消息为第一网元与第二网元之间交互的首条消息，因而第二网元可以处理该第一消息。然后第二网元将第一消息的序列号作为第二网元的交互序列号，将第二网元的交互序列号增加设定步长后作为第二网元的等待序列号。

第五方面，本申请提供一种装置，该装置可以是第一网元、或第二网元，也可以是芯片。该装置具有实现上述第一方面、或者第二方面、或者第三方面中、或者第四方面任意一个方面的各实施例的功能。该功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。

第六方面，提供了一种装置，包括：处理器和存储器；该存储器用于存储计算机执行指令，当该装置运行时，该处理器执行该存储器存储的该计算机执行指令，以使该装置执行如上述第一方面或第一方面中任一所述的消息处理方法、或者以使该装置执行如上述第二方面或第二方面中任一所述的消息处理方法、或者以使该装置执行如上述第三方面或第三方面中任一所述的消息处理方法、或者以使该装置执行如上述第四方面或第四方面中任一所述的消息处理方法。

第七方面，本申请还提供一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述各方面所述的方法。

第八方面，本申请还提供一种包括指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述各方面所述的方法。

本申请的这些方面或其他方面在以下实施例的描述中会更加简明易懂。

附图说明

图1为本申请提供的一种可能的网络架构示意图；

图2为本申请提供的一种服务化接口协议栈示例图；

图3为本申请提供的HTTP协议交互示意图；

图4为本申请所适用的又一种可能的网络架构示意图；

图5为本申请提供的一种消息处理方法流程示意图；

图6为本申请提供的又一种消息处理方法流程示意图；

图7为本申请提供的又一种消息处理方法流程示意图；

图8为本申请提供的又一种消息处理方法流程示意图；

图9为PDU会话建立流程示意图；

图10为SMF策略修改流程示意图；

图11为PDU会话释放流程示意图；

图12为本申请提供的一种消息处理方法流程示意图；

图13为PDU会话建立流程示意图；

图14为本申请提供的一种装置示意图；

图15为本申请提供的又一种装置示意图。

具体实施方式

为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述。方法实施例中的具体操作方法也可以应用于装置实施例或系统实施例中。其中，在本申请的描述中，除非另有说明，“多个”的含义是两个或两个以上。

本申请实施例描述的网络架构以及业务场景是为了更加清楚的说明本申请实施例的技术方案，并不构成对于本申请实施例提供的技术方案的限定，本领域普通技术人员可知，随着网络架构的演变和新业务场景的出现，本申请实施例提供的技术方案对于类似的技术问题，同样适用。

如图1所示，为本申请适用的一种可能的网络架构示意图。该网络架构包括第一网元和第二网元。这里的第一网元、第二网元分别可以称为NF网元。作为一种实现方式，两个NF网元之间可以通过服务化接口，调用并使用对方的服务实例。当然，在实际应用中两个NF网元之间也还可以采用其他形式的接口进行通信。

图1所示的第一网元和第二网元可以通过两种不同的实现方式执行本申请的消息处理方法，下面分别说明。

在第一种实现方式中，第一网元和第二网元可以通过以下步骤A-步骤C执行消息处理方法。

步骤A，第一网元向第二网元发送第一请求消息。相应地，第二网元可以接收到该第一请求消息。

比如，第一网元与第二网元之间可以建立一个TCP连接，然后第一网元与第二网元在该TCP连接上建立HTTP连接，该HTTP连接可以称为第一HTTP连接。然后第一网元向第二网元发送第一请求消息，因此该第一请求消息属于第一HTTP交互流程。

如图2所示，为本申请提供的一种服务化接口协议栈示例图。第一网元和第二网元分别包括以下协议层：L1层、L2层、互联网协议(internet protocol，IP)层、TCP层、HTTP/2层和应用(application)层。如图3，为本申请提供的HTTP协议交互示意图。第一网元可以与第二网元之间建立TCP连接，然后第一网元向第二网元发起HTTP请求(如第一HTTP请求)，第二网元可以向第一网元发送HTTP响应(如第一HTTP响应)。在完成HTTP交互之后，可以关闭TCP连接。此时第一网元作为服务的使用方，也可以称为HTTP客户端(client)，第二网元作为服务的提供方，也可以称为HTTP server(服务器)。第一网元与第二网元之间的HTTP连接是建立在TCP连接之上的，TCP连接是可靠的、有序的传输连接。

第二网元接收到第一请求消息后可以处理该第一请求消息，并且在处理完该第一请求消息之后还需要向第一网元发送针对该第一请求消息的第一响应消息，该第一响应消息也属于该第一HTTP交互流程。

本申请中，第二网元在向第一网元发送第一响应消息之前，又与第一网元之间建立了一个TCP连接，且在该TCP连接上建立了一个HTTP连接，该HTTP连接可以称为第二HTTP连接。进一步地，第二网元在向第一网元发送第一响应消息之前，通过该第二HTTP连接向第一网元发送了第二请求消息。

步骤B，第二网元向第一网元发送第二请求消息。相应地，第一网元可以接收到该第二请求消息。

即，第一网元通过第一HTTP连接向第二网元发送了第一请求消息，然后第二网元通过第二HTTP连接向第一网元发送了第二请求消息。并且，第一网元在接收到第二请求消息时还未收到第二网元发送的针对第一请求消息的第一响应消息。

步骤C，第一网元根据第一HTTP交互流程与第二HTTP交互流程的关系，执行对第二请求消息的操作。

这里，第一HTTP交互流程与第二HTTP交互流程的关系包括：第一HTTP交互流程与第二HTTP交互流程相互独立、第一HTTP交互流程与第二HTTP交互流程相互依赖。其中，第一HTTP交互流程与第二HTTP交互流程相互依赖，例如包括第一网元在处理第二请求消息时需要参考接收到的第一响应消息的内容，即第二请求消息的处理方法依赖于第一响应消息的内容。再比如，第一网元处理第二请求消息的优先级高于第一响应消息等。

基于上述实施例，第一网元与第二网元之间建立了第一HTTP交互流程，第一网元在第一HTTP交互流程中向第二网元发送第一请求消息，且在第一网元接收到第一HTTP交互流程中的针对上述第一请求消息的第一响应消息之前，第二网元发起建立了第一网元与第二网元之间的第二HTTP交互流程且第一网元接收到第二网元发送的第二请求消息。此时，若直接对第二请求消息进行处理则可能导致在错误的时间处理第二请求消息，因此第一网元根据第一HTTP交互流程与第二HTTP交互流程的关系执行对第二请求消息的操作，有助于避免在错误的时间处理第二请求消息，进而可实现第一网元与第二网元之间的消息的有序交互。

在第二种实现方式中，第一网元和第二网元可以通过以下步骤A1-步骤C1、或者步骤A1-步骤F1执行本申请的消息处理方法。

步骤A1，第一网元向第二网元发送第一消息。相应地，第二网元可以接收到该第一消息。

第一消息包括重置标志信息和序列号。其中，序列号是作为该第一消息的发送编号或序号。

重置标志信息具体可以为第一重置标志信息或第二重置标志信息。这里的重置标志信息也可以称为复位标志(Reset Flag)信息。第一重置标志信息用于指示第一消息为第一网元与第二网元之间交互的非首条消息，第二重置标志信息用于指示第一消息为第一网元与第二网元之间交互的首条消息。例如，当使用一个比特位实现重置标志信息时，则第一重置标志信息可以为“1”，第二重置标志信息可以为“0”。或者，第一重置标志信息可以为“0”，第二重置标志信息可以为“1”。

步骤B1，第一网元将第一消息的序列号作为第一网元的交互序列号，将第一网元的交互序列号增加设定步长后作为第一网元的等待序列号。

第一网元在向第二网元发送了第一消息之后，记录第一网元的交互序列号和第一网元的等待序列号。第一网元的交互序列号用于指示第一网元与第二网元当前交互的消息的序列号，第一网元的等待序列号用于指示第一网元当前等待的下一条消息的序列号。

例如，若第一消息是第一网元与第二网元之间交互的首条消息，且消息从0开始编号，则第一消息携带的序列号为0，携带的重置标志信息为第二重置标志信息。第一网元在发送了第一消息之后，将0作为交互序列号，若设定步长为1，则将交互序列号加1(即0+1＝1)后作为第一网元的等待序列号。因此，第一网元发送了第一消息之后，第一网元的交互序列号为0，等待序列号为1。

再比如，若第一消息是第一网元与第二网元之间交互的非首条消息，且消息从0开始编号，假设设定步长为1，第一网元当前保存的交互序列号为4，等待序列号为5，则第一网元准备发送第一消息时，将交互序列号加1后作为第一消息的序列号，因此，第一消息携带的序列号为5，携带的重置标志信息为第一重置标志信息。第一网元在发送了第一消息之后，将5作为交互序列号，则将交互序列号加1(即5+1＝6)后作为第一网元的等待序列号。因此，第一网元发送了第一消息之后，第一网元的交互序列号更新为5，等待序列号更新为6。

步骤C1，若重置标志信息为第一重置标志信息且第一消息的序列号与第二网元的等待序列号相同，则第二网元处理第一消息，以及将第一消息的序列号作为第二网元的交互序列号，将第二网元的交互序列号增加设定步长后作为第二网元的等待序列号。

第二网元的交互序列号用于指示第二网元与第一网元当前交互的消息的序列号，第二网元的等待序列号用于指示第二网元当前等待的下一条消息的序列号。

第二网元在接收到第一消息后，获取其中的序列号和重置标志信息，其中：

情形一，第一消息的重置标志信息为第一重置标志信息，且第一消息的序列号与第二网元的等待序列号相同。

由于重置标志信息为第一重置标志信息，且第一消息的序列号与第二网元的等待序列号相同，因此该第一消息是非首条消息且第一消息的序列号是正确的，则第二网元处理该第一消息。

第二网元处理该第一消息之后，将第一消息的序列号作为第二网元的交互序列号，将第二网元的交互序列号增加设定步长后作为第二网元的等待序列号。

比如，第一消息的序列号为5，重置标志信息为第一重置标志信息，第二网元当前保存的交互序列号为4，等待序列号为5，则第二网元接收到第一消息后，确定重置标志信息为第一重置标志信息，且第一消息的序列号与第二网元的等待序列号相同，则处理该第一消息。进一步的，第二网元将第二网元的交互序列号更新为5，等待序列号更新为6。其中，以设定步长为1举例。

情形二，第一消息的重置标志信息为第一重置标志信息且第一消息的序列号与第二网元的等待序列号不同。

由于重置标志信息为第一重置标志信息，且第一消息的序列号与第二网元的等待序列号不同，因此该第一消息是非首条消息，但第一消息的序列号不正确，则第二网元暂时不处理该第一消息。具体的，第二网元可以缓存该第一消息。

第二网元缓存第一消息之后，进一步的，第二网元可以接收第一网元发送的其他消息，或者向第一网元发送其他消息，并更新本地存储的交互序列号和等待序列号。接着，可以判断第二网元的当前的等待序列号与第一消息的序列号是否相同，若相同则处理第一消息，然后将第一消息的序列号作为第二网元的交互序列号，将第二网元的交互序列号增加设定步长后作为第二网元的等待序列号。若不相同则仍然不处理该第一消息直到确定第二网元的当前的等待序列号与第一消息的序列号相同再处理该第一消息。如此可以实现对消息的有序处理。

比如，第一消息的序列号为6，重置标志信息为第一重置标志信息，第二网元当前保存的交互序列号为4，等待序列号为5，则第二网元接收到第一消息后，确定重置标志信息为第一重置标志信息，但第一消息的序列号与第二网元的等待序列号不同，则缓存该第一消息。后续，若第二网元又接收到第一网元发送的另一消息，该消息的序列号为5且重置标志信息为第一重置标志信息，则第二网元处理该另一消息，然后将本地存储的交互序列号更新为5，等待序列号更新为6。接着，第二网元获取缓存中的第一消息，确定第一消息的序列号与第二网元当前的等待序列号相同，则处理该第一消息，同时将第二网元的交互序列号更新为6，等待序列号更新为7。其中，以设定步长为1举例。

情形三，第一消息的重置标志信息为第二重置标志信息。

由于第一消息的重置标志信息为第二重置标志信息，表明该第一消息是第一网元与第二网元之间交互的第一条消息，因此第二网元处理该第一消息，以及将第一消息的序列号作为第二网元的交互序列号，将第二网元的交互序列号增加设定步长后作为第二网元的等待序列号。具体的，若消息从0开始编号，则第一消息携带的序列号为0，携带的重置标志信息为第二重置标志信息。第二网元在接收到第一消息之后，将0作为第二网元的交互序列号，则将交互序列号加1(即0+1＝1)作为第二网元的等待序列号。因此，第二网元的交互序列号为0，等待序列号为1。其中，以设定步长为1举例。

基于上述实施例，第一网元记录交互序列号和等待序列号，第二网元也记录交互序列号和等待序列号。当第一网元向第二网元发送第一消息时，第二网元若确定第一消息携带的重置标志信息为第一重置标志信息，则确定该第一消息是第一网元与第二网元之间交互的非首条消息。接着，第二网元若确定第二网元的等待序列号与第一消息的序列号相同，则确定该第一消息是当前等待处理的消息，因此可以处理该第一消息。进一步的，第一网元在发送第一消息后还需要更新本地记录的交互序列号和等待序列号，同样的，第二网元在处理第一消息后也需要更新本地记录的交互序列号和等待序列号。如此，可以实现第一网元和第二网元之间的消息的有序交互。

进一步的，在上述步骤C1之后，还可以包括以下步骤D1-步骤F1。

步骤D1，第二网元向第一网元发送第二消息。相应地，第一网元可以接收到该第二消息。

该第二消息包括第一重置标志信息和序列号，第二消息的序列号为第二网元当前的交互序列号与设定步长之和。

步骤E1，第二网元将第二消息的序列号作为第二网元的交互序列号，将第二网元的交互序列号增加设定步长后作为第二网元的等待序列号。

步骤F1，若第二消息的序列号与第一网元的等待序列号相同，则第一网元处理第二消息，以及将第二消息的序列号作为第一网元的交互序列号，将第一网元的交互序列号增加设定步长后作为第一网元的等待序列号。若第二消息的序列号与第一网元的等待序列号不同，则第一网元缓存第二消息。

上述步骤D1-步骤F1的处理逻辑与上述步骤A1-步骤C1的处理逻辑类似，可参看前述描述，这里不再赘述。

作为一种具体实现方式，可以在NF网元内增加保序层，例如在图2所示的协议栈的应用层之上增加保序层，该保序层用于实现对NF网元接收和发送的消息进行保序。基于该实现方式，以设定步长为1，消息的编号从0开始为例，该第二种实现方式的实施例的具体实现为：

上述步骤A1之前，第一网元的应用层产生一个消息，然后将该消息发送给第一网元的保序层。

若该消息是第一网元与第二网元之间交互的首条消息，则第一网元的保序层在该消息中携带序列号0及第二重置标志信息，得到第一消息，然后通过步骤A1发送给第二网元。进一步的，第一网元的保序层执行上述步骤B1。第二网元的保序层接收到第一消息后，确定重置标志信息为第二重置标志信息，因此将第二网元的交互序列号设为0，将第二网元的等待序列号设为1，接着将第一消息中除序列号和重置标志信息外的信息发送至第二网元的应用层进行处理。

若该消息是第一网元与第二网元之间交互的非首条消息，则第一网元的保序层在该消息中携带序列号N(N＝第一网元的当前的交互序列号+1)及第一重置标志信息，得到第一消息，然后通过步骤A1发送给第二网元。进一步的，第一网元的保序层执行上述步骤B1。第二网元的保序层接收到第一消息后，若确定重置标志信息为第一重置标志信息，且第一消息的序列号与第二网元的等待序列号相同，则将第二网元的交互序列号设为N，将第二网元的等待序列号设为N+1，然后将第一消息中除序列号和重置标志信息外的信息发送至第二网元的应用层进行处理。第二网元的保序层接收到第一消息后，若确定重置标志信息为第一重置标志信息，且第一消息的序列号与第二网元的等待序列号不同，则保序层缓存该第一消息。

如图4所示，为本申请所适用的又一种可能的网络架构示意图，该网络架构为5G网络架构。该网络架构包括核心网网元和(无线)接入网络((radio)access network，(R)AN)设备。核心网网元包括会话管理功能(session management function，SMF)网元、接入与移动性管理功能(access and mobility management function，AMF)网元、用户面功能(userplane function，UPF)网元、统一数据管理(Unified Data Management，UDM)网元、鉴权服务功能(authentication server function,AUSF)网元、策略控制功能(policy controlfunction，PCF)网元、网络开放功能(Network Exposure Function，NEF)网元、网络注册发现功能(Network Repository Function，NRF)网元、网络切片选择功能(Network SliceSelection Function，NSSF)网元、鉴权服务器功能(Authentication Server Function，AUSF)网元等。上述网络架构可以为数据网络(data network，DN)、用户设备(userequipment，UE)、应用功能(application funciton，AF)服务器提供服务。

SMF网元负责会话管理，如用户的会话建立等。AMF网元主要用于移动网络中的移动性管理，如用户位置更新、用户注册网络、用户切换等。UPF网元主要负责连接外部网络，其包括了长期演进(long term evolution，LTE)的服务网关(serving gateway，SGW)和公用数据网网关(public data network GateWay，PDN-GW)的相关功能。PCF网元包括用户签约数据管理功能、策略控制功能、计费策略控制功能、服务质量(quality of service，QoS)控制功能等。AUSF网元具有鉴权服务功能。UDM网元可存储用户的签约信息等。NSSF网元主要用于确定网络切片实例，选择AMF网元等。NEF网元负责将移动网络提供的服务和能力安全地提供给第三方，例如提供给垂直行业用户，应用服务器等。

其中，UE与AMF网元之间通过N1接口通信，(R)AN设备与AMF网元之间通过N2接口通信，(R)AN设备与UPF网元之间通过N3接口通信，UPF网元与SMF网元之间通过N4接口通信，UPF网元与DN之间通过N6接口通信。上述网络架构的控制面采用服务化架构，NF网元之间采用服务化接口进行通信和交互。控制面的NF网元主要有AMF网元、SMF网元、AUSF网元、NSSF网元、NEF网元、NRF网元、PCF网元和UDM网元。例如，作为一种实现方式，控制面的服务化接口可以包括Namf、Nsmf、Nausf、Nssf、Nnef、Nnrf、Npcf、Nudm等。

本申请中的第一网元和第二网元分别可以是上述AMF网元、SMF网元、AUSF网元、NSSF网元、NEF网元、NRF网元、PCF网元、或UDM网元，且第一网元与第二网元是不同的网元。

可以理解的是,上述功能既可以是硬件设备中的网络元件,也可以是在专用硬件上运行软件功能，或者是平台(例如,云平台)上实例化的虚拟化功能。

为方便说明，本申请后续将AMF网元、SMF网元、AUSF网元、NSSF网元、NEF网元、NRF网元、PCF网元和UDM网元分别简称为AMF、SMF、AUSF、NSSF、NEF、NRF、PCF和UDM。

需要说明的是，本申请各实施例中的消息的名称只是一个示例，名称对消息本身不构成限定。在5G通信以及未来其它的通信中，本申请各实施例中的消息也可以是其他的名字，本申请实施例对此不作具体限定。

下面结合图5-图11，对图1所示的系统架构中的第一种实现方式进行具体说明。其中，第一请求消息和第一响应消息属于第一HTTP交互流程，第二请求消息和第二响应消息属于第二HTTP交互流程。即第一网元和第二网元之间建立了两个HTTP连接。

如图5所示，为本申请提供的一种消息处理方法流程示意图。在该方法中，第一网元确定第一HTTP交互流程与第二HTTP交互流程相互独立，则处理第二请求消息。该实现方法中，由于第一HTTP交互流程与第二HTTP交互流程相互独立，或者理解为，第一HTTP交互流程与第二HTTP交互流程之间没有相互依赖关系。因此，第一网元在接收到第二请求消息后，可以处理该第二请求消息，而无需等待接收并处理第一HTTP交互流程中的第一响应消息之后再处理该第二请求消息。

该方法包括以下步骤：

步骤501，第一网元向第二网元发送第一请求消息。相应地，第二网元可以接收到该第一请求消息。

第二网元接收到第一请求消息后可以处理该第一请求消息。

步骤502，第一网元等待第一响应消息。

步骤503，第二网元向第一网元发送第二请求消息。相应地，第一网元可以接收到该第二请求消息。

步骤504，第一网元处理第二请求消息。

该步骤中，第一网元确定第一HTTP交互流程与第二HTTP交互流程之间相互独立，因此在接收到第二请求消息时，尽管没有接收到第一响应消息，仍然处理第二请求消息。

进一步的，还可以包括以下步骤505-步骤507。

步骤505，第一网元向第二网元发送第二响应消息。相应地，第二网元可以接收到该第二响应消息。

第二网元接收到第二响应消息之后，可以处理该第二响应消息。该第二响应消息属于第二HTTP交互流程。

步骤506，第二网元向第一网元发送第一响应消息。相应地，第一网元可以接收到该第一响应消息。

步骤507，第一网元处理第一响应消息。

通过上述步骤505-步骤507，第一网元处理第二请求消息之后，还可以向第二网元发送针对第二请求消息的第二响应消息。进一步的，在发送第二响应消息之后若接收来自第二网元的第一响应消息，则处理该第一响应消息。

作为一种可替换的实现方式，上述步骤505也可以是在步骤506之后步骤507之前执行，或者是在步骤507之后执行，对此本申请不做限定。

如图6所示，为本申请提供的又一种消息处理方法流程示意图。在该方法中，第一网元确定第二HTTP交互流程依赖于第一HTTP交互流程，且不能拒绝第二请求消息，则缓存第二请求消息。第一网元在接收并处理第一响应消息之后，处理第二请求消息。该实现方法中，由于第二HTTP交互流程依赖于第一HTTP交互流程，并且不能拒绝该第二请求消息，则第一网元可以先缓存该第二请求消息。在第一网元接收并处理第一响应消息之后，再获取缓存的第二请求消息，然后处理该第二请求消息。其中，第二HTTP交互流程依赖于第一HTTP交互流程，可以理解为第一网元在处理第二请求消息时，依赖于第一网元接收到的第一响应消息，因此需要先接收并处理第一响应消息。

该方法包括以下步骤：

步骤601，第一网元向第二网元发送第一请求消息。相应地，第二网元可以接收到该第一请求消息。

第二网元接收到第一请求消息后可以处理该第一请求消息。

步骤602，第一网元等待第一响应消息。

步骤603，第二网元向第一网元发送第二请求消息。相应地，第一网元可以接收到该第二请求消息。

步骤604，第一网元缓存该第二请求消息。

该步骤中，第一网元确定第二HTTP交互流程依赖于第一HTTP交互流程，且不能拒绝第二请求消息，因此在接收到第二请求消息时，缓存第二请求消息。

这里的不能拒绝第二请求消息指的是，一旦第一网元拒绝了该第二请求消息，则该第二请求消息将不能再重新发起，从而可能导致发生错误。比如，当第二请求消息是由第二网元在接收到第一请求消息时触发发送时，则该第二请求消息为不能被第一网元拒绝的消息，因为第一网元不会向第二网元重发第一请求消息，因此一旦第一网元拒绝了第二请求消息，则该第二请求消息将不会重新发送请求消息。

步骤605，第二网元向第一网元发送第一响应消息。相应地，第一网元可以接收到该第一响应消息。

步骤606，第一网元处理第一响应消息。

步骤607，第一网元处理第二请求消息。

由于第一网元已经处理完第一响应消息，即第二请求消息所依赖的第一响应消息已经处理完毕，因此第一网元可以从缓存中获取并处理第二请求消息。

进一步的，还可以包括以下步骤608。

步骤608，第一网元向第二网元发送第二响应消息。相应地，第二网元可以接收到该第二响应消息。

如图7所示，为本申请提供的又一种消息处理方法流程示意图。在该方法中，第一网元确定第二HTTP交互流程依赖于第一HTTP交互流程，且能够拒绝第二请求消息，则向第二网元发送拒绝消息。该实现方法中，由于第二HTTP交互流程依赖于第一HTTP交互流程，并且可以拒绝该第二请求消息，则第一网元可以向第二网元发送拒绝消息。后续第二网元可以再重新发起请求消息。

该方法包括以下步骤：

步骤701，第一网元向第二网元发送第一请求消息。相应地，第二网元可以接收到该第一请求消息。

第二网元接收到第一请求消息后可以处理该第一请求消息。

步骤702，第一网元等待第一响应消息。

步骤703，第二网元向第一网元发送第二请求消息。相应地，第一网元可以接收到该第二请求消息。

步骤704，第一网元向第二网元发送拒绝消息。相应地，第二网元可以接收到该拒绝消息。

该步骤中，第一网元确定第二HTTP交互流程依赖于第一HTTP交互流程，且可以拒绝第二请求消息，因此在接收到第二请求消息时，向第二网元发送拒绝消息。

这里的可以拒绝第二请求消息指的是，第一网元拒绝了该第二请求消息之后，该第二请求消息后续可以再重新发起请求消息。

可选的，该拒绝消息可以携带原因值“reject”。进一步的，该拒绝消息还可以携带设定时长，该设定时长可以理解为一个定时器或延迟时长(DelayTime)，用于指示第二网元在设定时长后重新发起请求消息。

步骤705，第二网元向第一网元发送第一响应消息。相应地，第一网元可以接收到该第一响应消息。

步骤706，第一网元处理第一响应消息。

步骤707，第二网元向第一网元发送第三请求消息。相应地，第一网元可以接收到该第三请求消息。

第一网元处理第一响应消息在处理第一响应消息之后，若接收到第二网元在设定时长到达时发送的第三请求消息，则处理该第三请求消息，该第三请求消息为针对第二请求消息重新发起的请求消息。或者也可以理解为该第三请求消息与上述第二请求消息是作用相同的消息。该第三请求消息属于第二HTTP交互流程。

步骤708，第一网元处理第三请求消息。

由于第一网元已经处理完第一响应消息，即第三请求消息所依赖的第一响应消息已经处理完毕，因此第一网元可以处理第三请求消息。

进一步的，还可以包括以下步骤709。

步骤709，第一网元向第二网元发送第三响应消息。相应地，第二网元可以接收到该第三响应消息。

第二网元接收到第三响应消息之后，可以处理该第三响应消息。该第三响应消息属于第二HTTP交互流程。

需要说明的是，若第一网元在接收到第三请求消息时，第一网元还未接收到第一响应消息或者还未处理第一响应消息，则第一网元可以再次向第二网元发送拒绝消息。直到第一网元已经处理完毕第一响应消息时，第一网元才处理针对第二请求消息重新发起的第三请求消息。

上述实施例，第一网元在接收到第一响应消息之前接收到第二请求消息，则先拒绝该第二请求消息，后续第二网元再重新发起针对该第二请求消息的第三请求消息，第一网元在处理完毕第一响应消息后处理第三请求消息，实现了第一网元与第二网元之间的消息的正确交互。

作为又一种实现方式，若上述步骤704的拒绝消息中不携带设定时长，即第一网元仅指示拒绝了第二请求消息，但没有通知第二网元在何时重新发起请求，则在上述步骤706之后步骤707之前还可以包括以下步骤A2。

步骤A2，第一网元向第二网元发送重发请求消息。相应地，第二网元可以接收到该重发请求消息。

该重发请求消息用于触发第二网元重新发起针对第二请求消息的请求消息。

第二网元在接收到重发请求消息后可以向第一网元发送第三请求消息，即执行上述步骤707。即该实施例是在第一网元处理完第一响应消息之后，主动通知第二网元重新发起针对第二请求消息的请求消息，即第三请求消息。

可选的，在步骤A2之后还可以包括以下步骤B2。

步骤B2，第二网元向第一网元发送重发响应消息，第一网元接收来自第二网元的重发响应消息。

如图8所示，为本申请提供的又一种消息处理方法流程示意图。该方法中，第一网元若确定第二HTTP交互流程的优先级高于第一HTTP交互流程，则在接收到第二请求消息时，尽管还未接收到第一HTTP交互流程中的第一响应消息，第一网元仍然优先处理第二请求消息。

该方法包括以下步骤：

步骤801，第一网元向第二网元发送第一请求消息。相应地，第二网元可以接收到该第一请求消息。

第二网元接收到第一请求消息后可以处理该第一请求消息。

步骤802，第一网元等待第一响应消息。

步骤803，第二网元向第一网元发送第二请求消息。相应地，第一网元可以接收到该第二请求消息。

步骤804，第一网元处理第二请求消息。

该步骤中，第一网元确定第二HTTP交互流程的优先级高于第一HTTP交互流程，则在接收到第二请求消息时，尽管还未接收到第一HTTP交互流程中的第一响应消息，第一网元仍然优先处理第二请求消息。

步骤805，第一网元向第二网元发送第二响应消息。相应地，第二网元可以接收到该第二响应消息。

进一步的，还可以包括以下步骤806-步骤807。

步骤806，第二网元向第一网元发送第一响应消息。相应地，第一网元可以接收到该第一响应消息。

步骤807，第一网元丢弃第一响应消息。

由于第一HTTP交互流程与第二HTTP交互流程相互之间不独立，且第二HTTP交互流程的优先级高于第一HTTP交互流程，则第一网元在处理第二请求消息之后，可以不需要再处理第一响应消息，因此可以丢弃该第一响应消息。

下面结合图4所示的系统中的应用场景，对上述实现方法进行举例说明。

参考图9，为协议数据单元(protocol data unit，PDU)会话建立流程示意图。该实施例是针对图6所示的实施例的一种应用场景。其中第一网元具体为AMF，第二网元具体为SMF。图6所示的实施例中的第一请求消息具体为上下文请求消息，第一响应消息具体为上下文响应消息，第二请求消息具体为通知消息，第二响应消息具体为响应消息。其中，上下文请求消息和上下文响应消息在一个HTTP交互流程，通知消息和响应消息在另一个HTTP交互流程。

该流程包括以下步骤：

步骤901，UE向AMF发送PDU会话建立请求(PDU Session Establishment Request)消息。相应地，AMF可以接收到该PDU会话建立请求消息。

步骤902，AMF向SMF发送上下文请求消息。相应地，SMF可以接收到该上下文请求消息。

该上下文请求消息为创建会话管理上下文请求消息，例如具体可以是Nsmf_PDUSession_CreateSMContext Request消息。

步骤903，AMF等待上下文响应消息。

该上下文响应消息为创建会话管理上下文响应消息，例如具体可以是Nsmf_PDUSession_CreateSMContext Response消息。

步骤904，SMF向AMF发送通知消息。相应地，AMF可以接收到该通知消息。

该通知消息具体可以是Namf_Communication_N1N2MessageTransfer Request消息。

由于乱序问题，AMF在该步骤中接收到了本来应该在步骤908之后才会接收到的通知消息。

步骤905，AMF缓存该通知消息。

AMF在接收到该通知消息后，确定第二HTTP交互流程依赖于第一HTTP交互流程，例如具体可以是该通知消息的处理依赖于上下文响应消息的处理，因此AMF缓存该通知消息，暂时不处理。

步骤906，SMF向UPF发送会话建立/修改请求消息。相应地，UPF可以接收到该会话建立/修改请求消息。

步骤907，UPF向SMF发送会话建立/修改响应消息。相应地，SMF可以接收到该会话建立/修改响应消息。

通过上述步骤906-步骤907，SMF和UPF交互，建立N4会话。该可步骤906和步骤907为可选步骤。

步骤908，SMF向AMF发送上下文响应消息。相应地，AMF可以接收到上下文响应消息。

该上下文响应消息具体可以是Nsmf_PDUSession_CreateSMContext Response消息。

步骤909，AMF处理上下文响应消息。

步骤910，AMF从缓存中获取通知消息，并处理该通知消息。

步骤911，AMF给SMF发送响应消息。相应地，SMF可以接收到该响应消息。

该响应消息具体可以是Namf_Communication_N1N2MessageTransfer Response消息。该响应消息是针对步骤904的通知消息的响应消息。

步骤912，AMF向UE发送PDU会话建立接受(PDU Session Establishment Accept)消息。相应地，UE可以接收到该PDU会话建立接受消息。

上述实施例中，由于出现乱序，AMF在接收到上下文响应消息之前接收到通知消息，则AMF缓存该通知消息，直到处理完上下文响应消息之后，再处理该通知消息，实现了不同HTTP连接之间的消息的有序处理。

参考图10，为SMF策略修改流程示意图。该实施例是针对图7所示的实施例的一种应用场景。其中第一网元具体为SMF，第二网元具体为PCF。图7所示的实施例中的第一请求消息具体为策略创建消息，第一响应消息具体为策略创建响应消息，第二请求消息具体为策略更新通知消息，第二响应消息具体为策略更新通知响应消息。其中，策略创建消息和策略创建响应消息在一个HTTP交互流程，策略更新通知消息和策略更新通知响应消息在另一个HTTP交互流程。

该流程包括以下步骤：

步骤1001，SMF向PCF发送策略创建消息。相应地，PCF可以接收到该策略创建消息。

该策略创建消息具体可以是Npcf_SMPolicyControl_Create消息，用于从PCF获取最新的策略。

步骤1002，SMF等待策略创建响应消息。

步骤1003，PCF修改了策略。

需要说明的是，在正确的时序中，该步骤应该是在发送了策略创建响应消息之后执行的。但由于乱序问题，该步骤先执行了。

步骤1004，PCF向SMF发送策略更新通知消息。相应地，SMF可以接收到该策略更新通知消息。

该策略更新通知消息具体可以是Npcf_SMPolicyControl_UpdateNotify消息。

在正确的时序中，该策略更新通知消息应该是在PCF发送了策略创建响应消息之后再发送，但由于消息出现乱序，该策略更新通知消息在该步骤1004中就发送给了SMF。

SMF接收到该策略更新通知消息后，确定当前处于Npcf_SMFPolicyControl_Create请求流程中，因此决策需要拒绝PCF的这次策略的修改请求。

步骤1005，SMF向PCF发送拒绝消息。相应地，PCF可以接收到该拒绝消息。

该拒绝消息具体可以是Npcf_SMPolicyControl_UpdateNotify Response消息，该消息中携带原因值“reject”和TimeDelay。PCF收到这个消息后，启动定时器等待重发策略更新通知消息。

步骤1006，PCF向SMF发送策略创建响应消息。相应地，SMF可以接收到该策略创建响应消息。

该策略创建响应消息具体可以是Npcf_SMPolicyControl_Create Response消息。

步骤1007，SMF处理该策略创建响应消息。

步骤1008，PCF的等待定时器超时后，重发策略更新通知消息给SMF。

需要说明的是，如果PCF在等待过程中还有其他策略的修改，则该策略更新通知消息中也可以将新的需要修改的策略一起发送给SMF。

步骤1009，SMF处理该策略更新通知消息。

具体的，SMF可以根据策略更新通知消息，更新策略并通知给UE。

步骤1010，SMF向PCF发送策略更新通知响应消息。相应地，PCF可以接收到该策略更新通知响应消息。

该策略更新通知响应消息具体可以是Npcf_SMPolicyControl_UpdateNotifyResponse消息。

上述实施例中，由于出现乱序，SMF在接收到策略创建响应消息之前接收到策略更新通知消息，则SMF拒绝该策略更新通知消息，直到处理完策略创建响应消息之后，再处理重新接收到的策略更新通知消息，实现了不同HTTP连接之间的消息的有序处理。

参考图11，为PDU会话释放流程示意图。该实施例是针对图8所示的实施例的一种应用场景。其中第一网元具体为SMF，第二网元具体为PCF。图8所示的实施例中的第一请求消息具体为策略创建消息，第一响应消息具体为策略创建响应消息，第二请求消息具体为策略更新通知消息，第二响应消息具体为策略更新通知响应消息。其中，策略创建消息和策略创建响应消息在一个HTTP交互流程，策略更新通知消息和策略更新通知响应消息在另一个HTTP交互流程。

该流程包括以下步骤：

步骤1101，SMF向PCF发送策略创建消息。相应地，PCF可以接收到该策略创建消息。

该策略创建消息具体可以是Npcf_SMPolicyControl_Create消息，用于请求从PCF获取最新的策略。

步骤1102，SMF等待策略创建响应消息。

该策略创建响应消息具体可以是Npcf_SMFPolicyControl_Create Response消息。

步骤1103，PCF修改策略，要求释放PDU会话。

需要说明的是，在正确的时序中，该步骤应该是在PCF发送策略创建响应消息之后执行的。但由于乱序问题，该步骤先执行了。

步骤1104，PCF向SMF发送策略更新通知消息。相应地，SMF可以接收到该策略更新通知消息。

在正确的时序中，该策略更新通知消息应该是在PCF发送了策略创建响应消息之后再发送，但由于消息出现乱序，该策略更新通知消息在发送策略创建响应消息之前就发送给了SMF。

SMF接收到该策略更新通知消息后，确定当前处于策略更新创建消息的流程中，但是PCF发送的策略更新通知消息是要求删除PDU会话，即该策略更新通知消息的优先级高于策略创建响应消息的优先级，因此SMF需要先处理该策略更新通知消息。

步骤1105，SMF处理该策略更新通知消息。

具体的，SMF根据策略更新通知消息，删除会话的策略。

步骤1106，SMF向PCF发送策略更新通知响应消息。相应地，PCF可以接收到该策略更新通知响应消息。

该策略更新通知响应消息是针对策略更新通知消息的响应消息。

步骤1107，PCF向SMF发送策略创建响应消息。相应地，SMF可以接收到该策略创建响应消息。

该策略创建响应消息具体可以是Npcf_SMPolicyControl_Create Response消息。由于SMF处于PDU会话删除的处理流程中，因此SMF可以丢弃该策略创建响应消息。

步骤1108，SMF丢弃策略创建响应消息。

步骤1109，SMF删除会话策略后，向PCF发送策略删除消息。相应地，PCF可以接收到该策略删除消息。

该策略删除消息具体可以是Npcf_SMPolicyControl_Delete消息。

步骤1110，PCF向SMF发送策略删除响应消息。相应地，SMF可以接收到该策略删除响应消息。

上述实施例中，由于出现乱序，SMF在接收到策略创建响应消息之前接收到策略更新通知消息，由于策略更新通知消息的优先级更高，因此SMF先处理该策略更新通知消息，在接收到策略创建响应消息后则丢弃该策略创建响应消息，实现了不同HTTP连接之间的消息的有序处理。

下面结合图12-图13，对图1所示的系统架构中的第二种实现方式进行具体说明。其中，NF网元中增加了保序层。

如图12所示，为本申请提供的一种消息处理方法流程示意图。第一网元包括应用层和保序层，第二网元包括应用层和保序层。设定步长为1，消息的编号从0开始，第一重置标志信息为0，第二重置标志信息为1。

该方法包括以下步骤：

步骤1201，第一网元的应用层向保序层发送请求消息。相应地，保序层可以接收到该请求消息。

保序层确定该消息为第一网元与第二网元之间交互的首条消息，则在请求消息中携带resetFlag:1,SN:0。其中，resetFlag表示重置信息。

步骤1202，第一网元的保序层向第二网元的保序层发送请求消息，相应地，第二网元的保序层可以接收到该请求消息。

该请求消息包括：resetFlag:1,SN:0。

步骤1203，第一网元的保序层保存交互序列号为0，等待序列号为1。

步骤1204，第二网元的保序层保存交互序列号为0，等待序列号为1。

步骤1205，第二网元的保序层向应用层发送请求消息。相应地，应用层可以接收到该请求消息。

需要说明的是，第二网元的保序层向应用层发送的请求消息中可以不包括resetFlag:1,SN:0，当然，也可以是保序层将完整的请求消息发送至应用层。

第二网元的应用层接收到请求消息后，处理该请求消息，处理结束后生成响应消息。

步骤1206，第二网元的应用层向保序层发送响应消息。相应地，保序层可以接收到该响应消息。

保序层确定该消息为第一网元与第二网元之间交互的非首条消息，则在响应消息中携带resetFlag:0,SN:1。

步骤1207，第二网元的保序层向第一网元的保序层发送响应消息，相应地，第一网元的保序层可以接收到该响应消息。

步骤1208，第二网元的保序层保存交互序列号为1，等待序列号为2。

步骤1209，第一网元的保序层向应用层发送响应消息。相应地，应用层可以接收到该响应消息。

第一网元的应用层接收到响应消息后，处理该响应消息。需要说明的是，该响应消息中可以不包括resetFlag:0,SN:1，当然，也可以是保序层将完整的响应消息发送至应用层。

步骤1210，第一网元的保序层保存交互序列号为1，等待序列号为2。

上述实施例，通过在网元内增加保序层，实现了对应用层屏蔽消息乱序的问题，实现了消息的有序处理。

下面结合图4所示的系统中的应用场景，对图12所示的方法进行具体说明。参考图13，为PDU会话建立流程示意图。其中第一网元具体为AMF，AMF包括应用层和保序层，第二网元具体为SMF，SMF包括应用层和保序层。设定步长为1，消息的编号从0开始，第一重置标志信息为0，第二重置标志信息为1。

该方法包括以下步骤：

步骤1301，AMF的应用层向保序层发送上下文请求消息。相应地，保序层可以接收到该上下文请求消息。

保序层确定该上下文消息为AMF与SMF之间交互的首条消息，则在上下文请求消息中携带resetFlag:1,SN:0。该上下文请求消息为创建会话管理上下文请求消息，例如具体可以是Nsmf_PDUSession_CreateSMContext Request消息。

步骤1302，AMF的保序层向SMF的保序层发送上下文请求消息，相应地，SMF的保序层可以接收到该上下文请求消息。

该上下文请求消息包括：resetFlag:1,SN:0。

步骤1303，AMF的保序层保存交互序列号为0，等待序列号为1。

步骤1304，SMF的保序层保存交互序列号为0，等待序列号为1。

步骤1305，SMF的保序层向应用层发送上下文请求消息。相应地，应用层可以接收到该上下文请求消息。

SMF的应用层接收到上下文请求消息后，处理该上下文请求消息，处理结束后生成上下文响应消息。

步骤1306，SMF的应用层向保序层发送上下文响应消息。相应地，保序层可以接收到该上下文响应消息。

保序层确定该上下文响应消息为SMF与SMF之间交互的非首条消息，则在上下文响应消息中携带resetFlag:0,SN:1。

步骤1307，SMF的保序层向AMF的保序层发送上下文响应消息。

步骤1308，SMF的保序层保存交互序列号为1，等待序列号为2。

步骤1309，SMF的应用层生成通知消息，并向保序层发送该通知消息。

步骤1310，SMF的保序层向AMF的保序层发送该通知消息。

保序层确定该通知消息为SMF与SMF之间交互的非首条消息，则在通知消息中携带resetFlag:0,SN:2。

在正常情况下，AMF先接收到步骤1307的上下文响应消息，再接收到步骤1310的通知消息，但由于出现的乱序问题，导致实际AMF先接收到通知消息，再接收到上下文响应消息。

步骤1311，SMF的保序层保存交互序列号为2，等待序列号为3。

步骤1312，AMF缓存通知消息。

AMF接收到通知消息后，获取其中的序列号为2，而AMF当前的等待序列号为1，因此缓存该通知消息，继续等待下一条消息，直到接收到上下文响应消息。

步骤1313，AMF的保序层向应用层发送上下文响应消息。相应地，应用层可以接收到该上下文响应消息。

由于上下文响应消息中的序列号为1，与AMF当前的等待序列号相同，因此AMF的保序层可以将该上下文响应消息发生至应用层处理。

应用层接收到该上下文响应消息后，可以处理该上下文响应消息。

步骤1314，AMF的保序层保存交互序列号为1，等待序列号为2。

步骤1315，AMF的保序层从缓存获取通知消息，向应用层发送该通知消息。相应地，应用层可以接收到该通知消息。

AMF的保序层在处理完上下文响应消息后，将本地的交互序列号更新为1，等待序列号更新为2。由于缓存的通知消息的序列号为2，与AMF的等待序列号相同，因此AMF的保序层确定当前可以处理通知消息，则向应用层发送该通知消息。

应用层接收到通知消息后处理该通知消息，然后生成响应消息。该响应消息具体可以是Namf_Communication_N1N2MessageTransfer Response消息。

步骤1316，AMF的保序层保存交互序列号为2，等待序列号为3。

步骤1317，AMF的应用层向保序层发送响应消息。相应地，保序层可以接收到该响应消息。

步骤1318，AMF的保序层向SMF的保序层发送响应消息，相应地，SMF的保序层可以接收到该响应消息。

该响应消息包括：resetFlag:0,SN:3。

步骤1319，AMF的保序层保存交互序列号为3，等待序列号为4。

步骤1320，SMF的保序层保存交互序列号为3，等待序列号为4。

步骤1321，SMF的保序层向应用层发送响应消息。相应地，应用层可以接收到该响应消息。

SMF的应用层接收到响应消息后，处理该响应消息。

该实施例，尽管步骤1310的通知消息先于步骤1307的上下文响应消息到达AMF，即出现消息的乱序问题，但AMF将通知消息缓存，在处理完上下文响应消息后再处理通知消息，实现了消息的有序处理。

上述主要从各个网元之间交互的角度对本申请提供的方案进行了介绍。可以理解的是，上述实现各网元为了实现上述功能，其包括了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本发明能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

基于相同的发明构思，如图14所示，为本申请提供的一种装置示意图，该装置可以NF网元(如上述实施例中的第一网元)、或芯片，可执行上述任一实施例中由第一网元执行的方法。

该装置1400包括至少一个处理器1401，通信线路1402，存储器1403以及至少一个通信接口1404。

处理器1401可以是一个通用中央处理器(central processing unit，CPU)，微处理器，特定应用集成电路(application specific integrated circuit，ASIC)，或一个或多个用于控制本申请方案程序执行的集成电路。

通信线路1402可包括一通路，在上述组件之间传送信息。

通信接口1404，使用任何收发器一类的装置，用于与其他设备或通信网络通信，如以太网，无线接入网(radio access network，RAN)，无线局域网(wireless local areanetworks，WLAN)，有线接入网等。

存储器1403可以是只读存储器(read-only memory，ROM)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(random access memory，RAM)或者可存储信息和指令的其他类型的动态存储设备，也可以是电可擦可编程只读存储器(electrically er服务器able programmable read-only memory，EEPROM)、只读光盘(compact discread-only memory，CD-ROM)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器可以是独立存在，通过通信线路1402与处理器相连接。存储器也可以和处理器集成在一起。

其中，存储器1403用于存储执行本申请方案的计算机执行指令，并由处理器1401来控制执行。处理器1401用于执行存储器1403中存储的计算机执行指令，从而实现本申请上述实施例提供的消息处理方法。

可选的，本申请实施例中的计算机执行指令也可以称之为应用程序代码，本申请实施例对此不作具体限定。

在具体实现中，作为一种实施例，处理器1401可以包括一个或多个CPU，例如图14中的CPU0和CPU1。

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

当图14所示的装置为芯片时，例如可以是NF网元的芯片，则该芯片包括处理器1401(还可以包括处理器1408)、通信线路1402、存储器1403和通信接口1404。具体地，通信接口1404可以是输入接口、管脚或电路等。存储器1403可以是寄存器、缓存等。处理器1401和处理器1408可以是一个通用的CPU，微处理器，ASIC，或一个或多个用于控制上述任一实施例的消息处理方法的程序执行的集成电路。

本申请可以根据上述方法示例对装置进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本申请中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。比如，在采用对应各个功能划分各个功能模块的情况下，图15示出了一种装置示意图，该装置1500可以是上述实施例中所涉及的第一网元、或者第一网元的芯片，该装置1500包括接收单元1501、发送单元1502和处理单元1503。

在一种实现方式中，该装置1500可实现以下操作：

发送单元，用于向第二网元发送第一请求消息，所述第一请求消息属于第一HTTP交互流程；接收单元，用于在接收到针对所述第一请求消息的第一响应消息之前，接收来自所述第二网元的第二请求消息，所述第一响应消息属于所述第一HTTP交互流程，所述第二请求消息属于第二HTTP交互流程；处理单元，根据所述第一HTTP交互流程与所述第二HTTP交互流程的关系，执行对所述第二请求消息的操作。

在一种可能的实现方式中，所述处理单元，具体用于确定所述第一HTTP交互流程与所述第二HTTP交互流程相互独立，则处理所述第二请求消息。

在一种可能的实现方式中，所述发送单元，还用于向所述第二网元发送针对所述第二请求消息的第二响应消息；在所述发送单元发送所述第二响应消息之后，所述接收单元，还用于接收来自所述第二网元的所述第一响应消息，所述处理单元，还用于处理所述第一响应消息；或者，

所述接收单元，还用于接收来自所述第二网元的所述第一响应消息；所述处理单元，还用于处理所述第一响应消息；在所述处理的处理单元处理所述第一响应消息之后，所述发送单元，还用于向所述第二网元发送针对所述第二请求消息的第二响应消息；

其中，所述第二响应消息属于所述第二HTTP交互流程。

在一种可能的实现方式中，所述处理单元，具体用于确定所述第二HTTP交互流程依赖于所述第一HTTP交互流程，且不能拒绝所述第二请求消息，则缓存所述第二请求消息；

所述接收单元，还用于接收所述第一响应消息；

所述处理单元，还用于处理所述第一响应消息，以及在处理所述第一响应消息之后处理所述第二请求消息。

在一种可能的实现方式中，在所述处理单元处理所述第二请求消息之后，所述发送单元，还用于向所述第二网元发送针对所述第二请求消息的第二响应消息，所述第二响应消息属于所述第二HTTP交互流程。

在一种可能的实现方式中，所述处理单元，具体用于确定所述第二HTTP交互流程依赖于所述第一HTTP交互流程，且能够拒绝所述第二请求消息，则通知所述发送单元向所述第二网元发送拒绝消息。

在一种可能的实现方式中，所述拒绝消息包括设定时长，所述设定时长用于指示所述第二网元在所述设定时长后重新发起请求消息，在所述发送单元向所述第二网元发送拒绝消息之后，所述接收单元，还用于接收来自所述第二网元的所述第一响应消息；

所述处理单元，还用于处理所述第一响应消息。

在一种可能的实现方式中，在所述发送单元向所述第二网元发送拒绝消息之后，所述接收单元，还用于接收来自所述第二网元的所述第一响应消息；

所述处理单元，还用于处理所述第一响应消息；

在所述处理单元处理所述第一响应消息之后，所述发送单元，还用于向所述第二网元发送重发请求消息，所述重发请求消息用于触发所述第二网元重新发起针对所述第二请求消息的请求消息。

在一种可能的实现方式中，所述处理单元，具体用于确定所述第二HTTP交互流程的优先级高于所述第一HTTP交互流程，则处理所述第二请求消息。

在一种可能的实现方式中，在所述处理单元处理所述第二请求消息之后，所述接收单元，还用于接收来自所述第二网元的所述第一响应消息；

所述处理单元，还用于丢弃所述第一响应消息。

应理解，该装置1500可以用于实现本发明实施例的方法中由第一网元执行的步骤，相关特征可以参照上文，此处不再赘述。

若该装置是第一网元，则第一网元以采用集成的方式划分各个功能模块的形式来呈现。这里的“模块”可以指特定ASIC，电路，执行一个或多个软件或固件程序的处理器和存储器，集成逻辑电路，和/或其他可以提供上述功能的器件。在一个简单的实施例中，本领域的技术人员可以想到该第一网元可以采用图15所示的形式。

比如，图14中的处理器1401可以通过调用存储器1403中存储的计算机执行指令，使得第一网元执行上述方法实施例中的方法。

具体的，图15中的接收单元1501、处理单元1503、以及发送单元1502的功能/实现过程可以通过图14中的处理器1401调用存储器1403中存储的计算机执行指令来实现。或者，图15中的处理单元603的功能/实现过程可以通过图14中的处理器1401调用存储器1403中存储的计算机执行指令来实现，图15中的接收单元1501和发送单元1502的功能/实现过程可以通过图14中的通信接口1404来实现。

可选的，当该装置1500是芯片或电路时，则接收单元1501和发送单元1502的功能/实现过程还可以通过管脚或电路等来实现。可选地，当该装置1500是芯片时，存储器1503可以为芯片内的存储单元，如寄存器、缓存等。

当然，当该装置1500是第一网元时，存储器1503可以是第一网元内的位于芯片外部的存储单元，本申请实施例对此不作具体限定。

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

本申请实施例中所描述的各种说明性的逻辑单元和电路可以通过通用处理器，数字信号处理器，专用集成电路(ASIC)，现场可编程门阵列(FPGA)或其它可编程逻辑装置，离散门或晶体管逻辑，离散硬件部件，或上述任何组合的设计来实现或操作所描述的功能。通用处理器可以为微处理器，可选地，该通用处理器也可以为任何传统的处理器、控制器、微控制器或状态机。处理器也可以通过计算装置的组合来实现，例如数字信号处理器和微处理器，多个微处理器，一个或多个微处理器联合一个数字信号处理器核，或任何其它类似的配置来实现。

本申请实施例中所描述的方法或算法的步骤可以直接嵌入硬件、处理器执行的软件单元、或者这两者的结合。软件单元可以存储于RAM存储器、闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、可移动磁盘、CD-ROM或本领域中其它任意形式的存储媒介中。示例性地，存储媒介可以与处理器连接，以使得处理器可以从存储媒介中读取信息，并可以向存储媒介存写信息。可选地，存储媒介还可以集成到处理器中。处理器和存储媒介可以设置于ASIC中，ASIC可以设置于终端设备中。可选地，处理器和存储媒介也可以设置于终端设备中的不同的部件中。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管结合具体特征及其实施例对本发明进行了描述，显而易见的，在不脱离本发明的精神和范围的情况下，可对其进行各种修改和组合。相应地，本说明书和附图仅仅是所附权利要求所界定的本发明的示例性说明，且视为已覆盖本发明范围内的任意和所有修改、变化、组合或等同物。显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims

1.一种消息处理方法，其特征在于，包括：

第一网元向第二网元发送第一请求消息，所述第一请求消息属于第一超文本传输协议HTTP交互流程；

所述第一网元在接收到针对所述第一请求消息的第一响应消息之前，接收来自所述第二网元的第二请求消息，所述第一响应消息属于所述第一HTTP交互流程，所述第二请求消息属于第二HTTP交互流程；

所述第一网元根据所述第一HTTP交互流程与所述第二HTTP交互流程的关系，执行对所述第二请求消息的操作。

2.根据权利要求1所述的方法，其特征在于，所述第一网元根据所述第一HTTP交互流程与所述第二HTTP交互流程的关系，执行对所述第二请求消息的操作，包括：

所述第一网元确定所述第一HTTP交互流程与所述第二HTTP交互流程相互独立，则处理所述第二请求消息。

3.根据权利要求2所述的方法，其特征在于，所述第一网元处理所述第二请求消息之后，还包括：

所述第一网元向所述第二网元发送针对所述第二请求消息的第二响应消息，以及，在发送所述第二响应消息之后接收来自所述第二网元的所述第一响应消息并处理所述第一响应消息；或者，

所述第一网元接收来自所述第二网元的所述第一响应消息并处理所述第一响应消息；以及，在处理所述第一响应消息之后向所述第二网元发送针对所述第二请求消息的第二响应消息；

其中，所述第二响应消息属于所述第二HTTP交互流程。

4.根据权利要求1所述的方法，其特征在于，所述第一网元根据所述第一HTTP交互流程与所述第二HTTP交互流程的关系，执行对所述第二请求消息的操作，包括：

所述第一网元确定所述第二HTTP交互流程依赖于所述第一HTTP交互流程，且不能拒绝所述第二请求消息，则缓存所述第二请求消息；

所述第一网元在接收并处理所述第一响应消息之后，处理所述第二请求消息。

5.根据权利要求4所述的方法，其特征在于，所述第一网元处理所述第二请求消息之后，还包括：

所述第一网元向所述第二网元发送针对所述第二请求消息的第二响应消息，所述第二响应消息属于所述第二HTTP交互流程。

6.根据权利要求1所述的方法，其特征在于，所述第一网元根据所述第一HTTP交互流程与所述第二HTTP交互流程的关系，执行对所述第二请求消息的操作，包括：

所述第一网元确定所述第二HTTP交互流程依赖于所述第一HTTP交互流程，且能够拒绝所述第二请求消息，则向所述第二网元发送拒绝消息。

7.根据权利要求6所述的方法，其特征在于，所述拒绝消息包括设定时长，所述设定时长用于指示所述第二网元在所述设定时长后重新发起请求消息，所述第一网元向所述第二网元发送拒绝消息之后，还包括：

所述第一网元接收来自所述第二网元的所述第一响应消息，并处理所述第一响应消息。

8.根据权利要求6所述的方法，其特征在于，所述第一网元向所述第二网元发送拒绝消息之后，还包括：

所述第一网元接收来自所述第二网元的所述第一响应消息，并处理所述第一响应消息；

所述第一网元在处理所述第一响应消息之后，向所述第二网元发送重发请求消息，所述重发请求消息用于触发所述第二网元重新发起针对所述第二请求消息的请求消息。

9.根据权利要求1所述的方法，其特征在于，所述第一网元根据所述第一HTTP交互流程与所述第二HTTP交互流程的关系，执行对所述第二请求消息的操作，包括：

所述第一网元确定所述第二HTTP交互流程的优先级高于所述第一HTTP交互流程，则处理所述第二请求消息。

10.根据权利要求9所述的方法，其特征在于，所述第一网元处理所述第二请求消息之后，还包括：

所述第一网元接收来自所述第二网元的所述第一响应消息；

所述第一网元丢弃所述第一响应消息。

11.一种消息处理方法，其特征在于，包括：

第一网元向第二网元发送第一消息，所述第一消息包括重置标志信息和序列号；

所述第一网元将所述第一消息的序列号作为所述第一网元的交互序列号，将所述第一网元的交互序列号增加设定步长后作为所述第一网元的等待序列号；

所述第二网元接收来自所述第一网元的所述第一消息；

若所述重置标志信息为第一重置标志信息且所述第一消息的序列号与所述第二网元的等待序列号相同，则所述第二网元处理所述第一消息，以及将所述第一消息的序列号作为所述第二网元的交互序列号，将所述第二网元的交互序列号增加设定步长后作为所述第二网元的等待序列号；

其中，所述第一网元的交互序列号用于指示所述第一网元与所述第二网元当前交互的消息的序列号，所述第一网元的等待序列号用于指示所述第一网元当前等待的下一条消息的序列号，所述第二网元的交互序列号用于指示所述第二网元与所述第一网元当前交互的消息的序列号，所述第二网元的等待序列号用于指示所述第二网元当前等待的下一条消息的序列号。

12.根据权利要求11所述的方法，其特征在于，所述方法还包括：

若所述重置标志信息为第一重置标志信息且所述第一消息的序列号与所述第二网元的等待序列号不同，则所述第二网元缓存所述第一消息。

13.根据权利要求12所述的方法，其特征在于，所述第二网元缓存所述第一消息之后，还包括：

若所述第二网元当前的等待序列号与所述第一消息的序列号相同，则所述第二网元处理所述第一消息；

所述第二网元将所述第一消息的序列号作为所述第二网元的交互序列号，将所述第二网元的交互序列号增加设定步长后作为所述第二网元的等待序列号。

14.根据权利要求11所述的方法，其特征在于，所述方法还包括：

若所述重置标志信息为第二重置标志信息，则所述第二网元处理所述第一消息；

15.根据权利要求11-14任一所述的方法，其特征在于，所述方法还包括：

所述第二网元向所述第一网元发送第二消息，所述第二消息包括第一重置标志信息和序列号，所述第二消息的序列号为所述第二网元当前的交互序列号与设定步长之和；

所述第二网元将所述第二消息的序列号作为所述第二网元的交互序列号，将所述第二网元的交互序列号增加设定步长后作为所述第二网元的等待序列号；

所述第一网元接收来自所述第二网元的所述第二消息；

若所述第二消息的序列号与所述第一网元的等待序列号相同，则所述第一网元处理所述第二消息，以及将所述第二消息的序列号作为所述第一网元的交互序列号，将所述第一网元的交互序列号增加设定步长后作为所述第一网元的等待序列号；若所述第二消息的序列号与所述第一网元的等待序列号不同，则所述第一网元缓存所述第二消息。

16.一种装置，其特征在于，包括：

发送单元，用于向第二网元发送第一请求消息，所述第一请求消息属于第一超文本传输协议HTTP交互流程；

接收单元，用于在接收到针对所述第一请求消息的第一响应消息之前，接收来自所述第二网元的第二请求消息，所述第一响应消息属于所述第一HTTP交互流程，所述第二请求消息属于第二HTTP交互流程；

处理单元，根据所述第一HTTP交互流程与所述第二HTTP交互流程的关系，执行对所述第二请求消息的操作。

17.根据权利要求16所述的装置，其特征在于，所述处理单元，具体用于确定所述第一HTTP交互流程与所述第二HTTP交互流程相互独立，则处理所述第二请求消息。

18.根据权利要求17所述的装置，其特征在于，所述发送单元，还用于向所述第二网元发送针对所述第二请求消息的第二响应消息；在所述发送单元发送所述第二响应消息之后，所述接收单元，还用于接收来自所述第二网元的所述第一响应消息；所述处理单元，还用于处理所述第一响应消息；或者，

其中，所述第二响应消息属于所述第二HTTP交互流程。

19.根据权利要求16所述的装置，其特征在于，所述处理单元，具体用于确定所述第二HTTP交互流程依赖于所述第一HTTP交互流程，且不能拒绝所述第二请求消息，则缓存所述第二请求消息；

所述接收单元，还用于接收所述第一响应消息；

20.根据权利要求16所述的装置，其特征在于，所述处理单元，具体用于确定所述第二HTTP交互流程依赖于所述第一HTTP交互流程，且能够拒绝所述第二请求消息，则通知所述发送单元向所述第二网元发送拒绝消息。

21.根据权利要求20所述的装置，其特征在于，所述拒绝消息包括设定时长，所述设定时长用于指示所述第二网元在所述设定时长后重新发起请求消息，在所述发送单元向所述第二网元发送拒绝消息之后，所述接收单元，还用于接收来自所述第二网元的所述第一响应消息；

所述处理单元，还用于处理所述第一响应消息。

22.根据权利要求16所述的装置，其特征在于，所述处理单元，具体用于确定所述第二HTTP交互流程的优先级高于所述第一HTTP交互流程，则处理所述第二请求消息。

23.一种系统，其特征在于，包括第一网元和第二网元；

所述第一网元，用于向所述第二网元发送第一消息，所述第一消息包括重置标志信息和序列号；将所述第一消息的序列号作为所述第一网元的交互序列号，将所述第一网元的交互序列号增加设定步长后作为所述第一网元的等待序列号；

所述第二网元，用于接收来自所述第一网元的所述第一消息；若所述重置标志信息为第一重置标志信息且所述第一消息的序列号与所述第二网元的等待序列号相同，则处理所述第一消息，以及将所述第一消息的序列号作为所述第二网元的交互序列号，将所述第二网元的交互序列号增加设定步长后作为所述第二网元的等待序列号；

24.根据权利要求23所述的系统，其特征在于，若所述重置标志信息为第一重置标志信息且所述第一消息的序列号与所述第二网元的等待序列号不同，则所述第二网元，还用于缓存所述第一消息。

25.根据权利要求23所述的系统，其特征在于，若所述重置标志信息为第二重置标志信息，则所述第二网元，还用于处理所述第一消息，以及，将所述第一消息的序列号作为所述第二网元的交互序列号，将所述第二网元的交互序列号增加设定步长后作为所述第二网元的等待序列号。