数据传输方法和系统

摘要

一种数据传输方法，包括以下步骤：服务器接收发送端发送的数据包；所述服务器记录所述数据包并设置所述数据包对应的标志位，将处理后的数据包发送至接收端；所述服务器接收所述接收端发送的确认包，设置所述数据包对应的标志位为已回复状态；所述服务器根据所述标志位向所述发送端返回确认包。采用上述方法，能够减少数据重发次数，节省流量。此外，还提供了一种数据传输系统。

权利要求

1.一种基于UDP协议的数据传输方法，包括以下步骤：

服务器接收发送端发送的数据包；

所述服务器记录所述数据包并设置所述数据包对应的标志位，将处理后的数据包发送至接收端；

所述服务器接收所述接收端发送的确认包，设置所述数据包对应的标志位为已回复状态；

所述服务器根据所述标志位向所述发送端返回确认包，包括：接收发送端发送的数据包，判断所述数据包是否记录在哈希表中且数据包到达时间与上一次数据包到达时间的间隔是否超过设定的阈值，若是，则进一步判断所述数据包对应的标志位是否为已回复状态，若是，则向所述发送端返回确认包。

2.根据权利要求1所述的基于UDP协议的数据传输方法，其特征在于，所述服务器根据所述标志位向所述发送端返回确认包的步骤还包括：当所述数据包未记录在哈希表中时，则处理所述数据包，并将所述数据包的记录插入到哈希表中。

3.根据权利要求1所述的基于UDP协议的数据传输方法，其特征在于，所述服务器根据所述标志位向所述发送端返回确认包的步骤还包括：当数据包到达时间与上一次数据包到达时间的间隔没有超过设定的阈值时，则将所述数据包直接抛弃。

4.根据权利要求1所述的基于UDP协议的数据传输方法，其特征在于，所述服务器根据所述标志位向所述发送端返回确认包的步骤还包括：当所述数据包对应的标志位不为已回复状态时，则处理所述数据包并更新哈希表中的数据包到达时间。

5.一种基于UDP协议的数据传输系统，其特征在于，包括服务器及与所述服务器进行交互的发送端和接收端，所述服务器包括：收发模块，用于接收发送端发送的数据包；

处理模块，用于记录所述数据包并设置所述数据包对应的标志位；

所述收发模块还用于将处理后的数据包发送至所述接收端，并接收所述接收端发送的确认包；

设置模块，用于在所述收发模块接收到接收端发送的确认包后，设置所述数据包对应的标志位为已回复状态；

所述收发模块还用于根据所述标志位向所述发送端返回确认包；

判断模块，用于在所述收发模块接收到发送端发送的数据包时，判断所述数据包是否记录在哈希表中且数据包到达时间与上一次数据包到达时间的间隔是否超过设定的阈值，若是，则进一步判断所述数据包对应的标志位是否为已回复状态，若是，则通知所述收发模块；

所述收发模块还用于当所述数据包对应的标志位为已回复状态时向所述发送端返回确认包。

6.根据权利要求5所述的基于UDP协议的数据传输系统，其特征在于，所述处理模块还用于当所述数据包未记录在哈希表中时，处理所述数据包；

所述设置模块还用于当所述数据包未记录在哈希表中时，则将所述数据包的记录插入到哈希表中。

7.根据权利要求5所述的基于UDP协议的数据传输系统，其特征在于，所述设置模块还用于当数据包到达时间与上一次数据包到达时间的间隔没有超过设定的阈值时，则将所述数据包直接抛弃。

8.根据权利要求5所述的基于UDP协议的数据传输系统，其特征在于，所述处理模块还用于当所述数据包对应的标志位不为已回复状态时处理所述数据包；

所述设置模块还用于当所述数据包对应的标志位不为已回复状态时更新哈希表中的数据包到达时间。

说明书

数据传输方法和系统

【技术领域】

[0001] 本发明涉及网络技术，尤其涉及一种数据传输方法和系统。【背景技术】

[0002] UDP协议（User Datagram Protocol，用户数据包协议）在网络中是用于处理数据包的协议，其在OSI（Open System Interconnect，开放式系统互联）模型中位于传输层。UDP协议具有不提供数据包分组、组装和不能对数据包进行排序的特性，也就是说，当报文发送之后，是无法得知其是否安全完整到达的。由于UDP协议的这些特性，UDP协议具有资源消耗小、处理数据快的优点，因此通常用于音频、视频和普通数据的传输中，因为这些数据传输中即使偶尔丢失一两个数据包，也不会对接收结果产生太大影响。例如，即时聊天工具中的消息传输通常采用的是UDP协议。

[0003] 为了保证数据能够正确被接收到，传统的基于UDP协议的数据传输方法在发送端和接收端会采取数据重发和回包确认机制，具体实现如下：

[0004] 在发送端维持一个发送队列，将已经发送的数据包保存在队列中，并按照一定的时间周期不断检查。如果在检查过程中，收到回复确认包，则根据确认包的索引，在队列中找到对应的包将其删除；如果在检查过程中，发现有数据包在该时间内没有收到回复确认包，则将该数据包进行重发，并更新其发送时间；如果在几个周期内，某些数据包仍没有收到回复确认包，则将该数据包转移到其他服务器中处理，并从此队列中删除该数据包。

[0005] 在接收端会维持一个接收队列，其中保存在一定时间内收到的数据包的索引。如果在此时间内又收到数据包，则会根据索引在接收队列中查询该数据包是否出现过，如果已经出现过，则表明该数据包是发送端重复发送的，只需对发送端回复一个确认包即可；如果在接收队列中没有出现过，则表明这是一个新的数据包，需对该数据包进行下一步的数据处理，并对发送端回复一个确认包，然后将该数据包的索引放在接收队列中。此外，接收队列会按照一定时间周期清除过老的数据索引。

[0006] 在即时通信系统中，服务器之间以及服务器与客户端之间通常采用UDP协议进行通信。也有服务器与客户端之间采用TCP（Transmission Control Protocol，传输控制协议）协议进行通信的，例如Web服务器与浏览器之间可采用TCP协议进行通信。TCP协议是一种面向连接（连接导向）的、可靠的、基于字节流的运输层通信协议，服务器与客户端之间可通过建立的链接传输数据。由于基于TCP协议的数据传输只要建立了链接就可传输数据，而基于UDP协议的数据传输方法又广泛采用了数据重发和回包确认的机制。因此，当不同终端之间采用不同协议时，例如，服务器与接收端之间采用TCP协议，服务器与发送端之间采用UDP协议，这样在接收端、服务器、发送端之间则会存在数据包和确认包大量重复发送的问题，从而增加了程序逻辑处理，造成流量浪费。【发明内容】

[0007] 基于此，有必要提供一种能减少数据重复发送、节省流量的数据传输方法。

[0008] 一种数据传输方法，包括以下步骤：

[0009] 服务器接收发送端发送的数据包；

[0010] 所述服务器记录所述数据包并设置所述数据包对应的标志位，将处理后的数据包发送至接收端；

[0011] 所述服务器接收所述接收端发送的确认包，设置所述数据包对应的标志位为已回复状态；

[0012] 所述服务器根据所述标志位向所述发送端返回确认包。

[0013] 优选的，所述服务器根据所述标志位向所述发送端返回确认包的步骤包括：

[0014] 在接收到发送端发送的数据包时判断所述数据包是否记录在哈希表中且数据包到达时间与上一次数据包到达时间的间隔是否超过设定的阈值，若是，则[0015] 进一步判断所述数据包对应的标志位是否为已回复状态，若是，则[0016] 向所述发送端返回确认包。

[0017] 优选的，所述服务器根据标志位向所述发送端返回确认包的步骤还包括：

[0018] 当所述数据包未记录在哈希表中时，则处理所述数据包，并将所述数据包的记录插入到哈希表中。

[0019] 优选的，所述服务器根据标志位向所述发送端返回确认包的步骤还包括：

[0020] 当数据包到达时间与上一次数据包到达时间的间隔没有超过设定的阈值时，则将所述数据包直接抛弃。

[0021] 优选的，所述服务器根据标志位向所述发送端返回确认包的步骤还包括：

[0022] 当所述数据包对应的标志位不为已回复状态时，则处理所述数据包并更新哈希表中的数据包到达时间。

[0023] 此外，还有必要提供一种能减少数据重复发送、节省流量的数据传输系统。

[0024] 一种数据传输系统，包括服务器，所述服务器包括：

[0025] 收发模块，用于接收发送端发送的数据包；

[0026] 处理模块，用于记录所述数据包并设置所述数据包对应的标志位，将处理后的数据包；

[0027] 所述收发模块还用于将处理后的数据包发送至所述接收端，并接收所述接收端发送的确认包；

[0028] 设置模块，用于在所述收发模块接收到接收端发送的确认包后，设置所述数据包对应的标志位为已回复状态；

[0029] 所述收发模块还用于根据所述标志位向所述发送端返回确认包。

[0030] 优选的，所述服务器还包括：

[0031] 判断模块，用于在所述收发模块接收到发送端发送的数据包时，判断所述数据包是否记录在哈希表中且数据包到达时间与上一次数据包到达时间的间隔是否超过设定的阈值，若是，则进一步判断所述数据包对应的标志位是否为已回复状态，若是，则通知所述收发模块所述数据包对应的标志位为已回复状态；

[0032] 所述收发模块还用于当所述数据包对应的标志位为已回复状态时向所述发送端返回确认包。

[0033] 优选的，所述处理模块还用于当所述数据包未记录在哈希表中时，处理所述数据包；

[0034] 所述设置模块还用于当所述数据包未记录在哈希表中时，则将所述数据包的记录插入到哈希表中。

[0035] 优选的，所述设置模块还用于当数据包到达时间与上一次数据包到达时间的间隔没有超过设定的阈值时，则将所述数据包直接抛弃。

[0036] 优选的，所述处理模块还用于当所述数据包对应的标志位不为已回复状态时处理所述数据包；

[0037] 所述设置模块还用于当所述数据包对应的标志位不为已回复状态时更新哈希表中的数据包到达时间。

[0038] 上述数据传输方法和系统，通过服务器接收到接收端发送的确认包时，设置数据包对应的标志位为已回复状态，根据设置的标志位向发送端返回确认包。由于服务器可能重复接收到发送端发送的数据包，在服务器重复收到数据包时，根据数据包对应的标志位来确定是否返回确认包，能够减少数据重复发送，节省了流量。【附图说明】

[0039] 图1为一个实施例中数据传输方法的流程示意图；

[0040] 图2为另一个实施例中数据传输方法的流程示意图；

[0041] 图3为一个实施例中数据传输系统的结构示意图；

[0042] 图4为另一个实施例中服务器的结构示意图；

[0043] 图5为在即时通信应用场景下的数据传输系统的示意图。【具体实施方式】

[0044] 如图1所示，在一个实施例中，一种数据传输方法，包括以下步骤：

[0045] 步骤S102，服务器接收发送端发送的数据包。

[0046] 本实施例中，服务器与发送端之间的数据传输基于UDP协议，发送端在一定时间间隔内没有接收到确认包时，则会重复向服务器发送同一数据包。发送端向服务器发送数据包的方式采用传统的数据重复和回包确认机制，在此则不再赘述。

[0047] 步骤S104，服务器记录数据包并设置数据包对应的标志位，将处理后的数据包发送至接收端。

[0048] 数据包对应的标志位用于标识服务器是否接收到了接收端返回的该数据包对应的确认包。本实施例中，设置数据包对应的标志位默认为未回复状态。

[0049] 步骤S106，服务器接收接收端发送的确认包，设置数据包对应的标志位为已回复状态。

[0050] 步骤S108，服务器根据标志位向发送端返回确认包。

[0051] 本实施例中，服务器与发送端之间的数据传输基于UDP协议，由于服务器再次收到数据包时，根据数据包对应的标志位能够确定是否已经收到确认包，若收到确认包，则可以不再向接收端发送数据包，因此能够减少数据重复发送，节省了流量。

[0052] 如图2所示，在另一个实施例中，服务器再次收到数据包，执行以下步骤：

[0053] 步骤S202，接收发送端发送的数据包。

[0054] 本实施例中，服务器与发送端之间的数据传输基于UDP协议，因此，发送端向服务器发送的是UDP数据包。该数据包包括发送端标识号、接收端标识号和消息序列号，服务器在接收到数据包后，会提取其中的发送端标识号、接收端标识号和消息序列号。

[0055] 步骤S204，判断数据包是否记录在哈希表中，若是，则进入步骤S208，否则进入步骤S206。

[0056] 在服务器会维护一个用来记录数据包的哈希表，在哈希表中保存了收到的数据包的索引，哈希表中的每条记录包括发送端标识号、接收端标识号、消息序列号、数据包到达时间和数据包对应的标志位。

[0057] 在一个实施例中，服务器以提取的发送端标识号、接收端标识号和消息序列号为索引，在哈希表中进行查找，判断是否查找到相应的记录，若查找到，则说明该数据包是发送端重复发送的，进入步骤S208，若没有查找到，则说明该数据包是服务器首次接收到的，则进入步骤S206。由于哈希表是根据关键码值直接进行访问的，即它可通过将关键码值映射到表中一个位置来访问记录，因此采用哈希表查找能加快查找速度。

[0058] 在一个实施例中，当数据包没有记录在哈希表中时，则执行步骤S206：

[0059] 步骤S206，处理数据包，并将该数据包的记录插入到哈希表中。

[0060] 在一个实施例中，接收端和服务器之间的数据传输可基于TCP协议，服务器处理数据包，将其转换为符合TCP协议的数据包，在接收端与服务器建立了链接时，则直接将数据包下发到接收端，接收端接收数据包后返回确认包。

[0061] 步骤S208，判断数据包到达时间与上一次数据包到达时间的间隔是否超过设定的阈值，若是，则进入步骤S212，否则进入步骤S210。

[0062] 本实施例中，服务器每次接收到数据包时会记录数据包到达时间，而上一次数据包达到时间已记录在哈希表中。若此时判断得到数据包到达时间与上一次数据包到达时间的间隔超过了设定的阈值，则说明已超时，即有相同的数据包已到达过并处理过，但还未收到接收端返回的确认包（可能是服务器下发数据包时丢失的原因，也可能是接收端返回确认包丢失的原因）。

[0063] 在一个实施例中，当判断到数据包到达时间与上一次数据包的到达时间没有超过设定的阈值时，则执行步骤S210：

[0064] 步骤S210，将数据包直接抛弃。

[0065] 在一个实施例中，若在步骤S208中判断得到数据包到达时间与上一次数据包到达时间的间隔没有超过设定的阈值，则说明未超时，而由于在步骤S204中已判断得到数据包已记录在哈希表中，则说明相同的数据包已到达并处理过，则可将数据包直接抛弃，不做处理。

[0066] 步骤S212，判断数据包对应的标志位是否为已回复状态，若是，则进入步骤S216，否则进入步骤S214。

[0067] 在一个实施例中，哈希表中的每一条记录中都包含了数据包对应的标志位，根据该标志位即可得知服务器是否收到了接收端返回的确认包，若没有收到，则数据包对应的标志位为未回复状态，例如默认为0，若收到了，则将数据包对应的标志位设置为已回复状态，例如设置为1。

[0068] 在一个实施例中，当在步骤S212中判断到数据包对应的标志位不为已回复状态时，则执行步骤S214：

[0069] 步骤S214，处理数据包并更新哈希表中的该数据包的到达时间。

[0070] 当在步骤S212中判断得到数据包对应的标志位不为已回复状态时，则说明服务器还未收到接收端返回的确认包，则处理该数据包，将处理后的数据包重新下发到接收端，并更新哈希表中的该数据包的到达时间。所更新的数据包到达时间可以在下一次服务器接收到相同的数据包时，用于判断是否超时。

[0071] 步骤S216，向发送端返回确认包。

[0072] 当在步骤S212中判断得到数据包对应的标志位为已回复状态时，则说明服务器已经收到了接收端返回的确认包，但可能确认包还未到达发送端（由于发送端未收到确认包，因此重复发送了数据包），则将确认包返回至发送端，该确认包中包含了发送端标识号、接收端标识号、消息序列号。

[0073] 本实施例中，服务器在重复收到发送端发送的数据包时，根据数据包对应的标志位即可得到服务器是否已收到了接收端返回的确认包，若服务器已经收到了接收端返回的确认包，则不会再向接收端发送数据包，因此能够减少数据包的重发次数，节省了流量。

[0074] 如图3所示，在一个实施例中，一种数据传输系统，包括服务器100及与服务器100进行交互的发送端200和接收端300，其中，服务器100包括收发模块102、处理模块104和设置模块106，其中：

[0075] 收发模块102用于接收发送端200发送的数据包。

[0076] 处理模块104用于记录所述数据包并设置所述数据包对应的标志位，将处理后的数据包。

[0077] 本实施例中，收发模块102还用于将处理后的数据包发送至接收端300，并接收接收端300发送的确认包。

[0078] 设置模块106用于在收发模块102接收到接收端300发送的确认包后，设置数据包对应的标志位为已回复状态。

[0079] 本实施例中，收发模块102还用于根据标志位向发送端200返回确认包。

[0080] 本实施例中，服务器100与发送端200之间的数据传输基于UDP协议，发送端200在一定时间间隔内没有接收到确认包时，则会重复向服务器100发送同一数据包。发送端200向服务器100发送数据包的方式采用传统的数据重复和回包确认机制，在此则不再赘述。

[0081] 由于服务器100再次收到数据包时，根据数据包对应的标志位能够确定是否已经收到确认包，若收到确认包，则可以不再向接收端300发送数据包，因此能够减少数据重复发送，节省了流量。

[0082] 在另一个实施例中，如图5所示，服务器100除了包括上述收发模块102、处理模块104和设置模块106外，还包括判断模块108。其中：

[0083] 判断模块108用于在收发模块102接收到发送端200发送的数据包时，判断数据包是否记录在哈希表中且数据包到达时间与上一次数据包到达时间的间隔是否超过设定的阈值，若是，则进一步判断数据包对应的标志位是否为已回复状态，若是，则通知收发模块102数据包对应的标志位为已回复状态。

[0084] 在一个实施例中，收发模块102还用于当数据包对应的标志位为已回复状态时向发送端200返回确认包。

[0085] 当判读模块108判断得到数据包对应的标志位为已回复状态时，则说明服务器100已经收到了接收端300返回的确认包，但可能确认包还未到达发送端200（由于发送端200未收到确认包，因此重复发送了数据包），则将确认包返回至发送端200，该确认包中包含了发送端标识号、接收端标识号、消息序列号。

[0086] 在一个实施例中，服务器100与发送端200之间的数据传输基于UDP协议，因此，发送端200向服务器100发送的是UDP数据包。该数据包包括发送端标识号、接收端标识号和消息序列号，服务器100在接收到数据包后，会提取其中的发送端标识号、接收端标识号和消息序列号。

[0087] 在服务器100会维护一个哈希表，在哈希表中保存了收到的数据包的索引，哈希表中的每条记录包括发送端标识号、接收端标识号、消息序列号、数据包到达时间和数据包对应的标志位。判断模块108用于以提取的发送端标识号、接收端标识号和消息序列号为索引，在哈希表中进行查找，判断是否查找到相应的记录，若查找到，则说明该数据包是发送端200重复发送的，若没有查找到，则说明该数据包是服务器100第一次接收到的。

[0088] 由于哈希表是根据关键码值直接进行访问的，即它可通过将关键码值映射到表中一个位置来访问记录，因此采用哈希表查找能加快查找速度。

[0089] 在一个实施例中，处理模块104还用于当判断模块108判断得到当数据包未记录在哈希表中时，则处理数据包。设置模块106还用于当判断模块108判断得到当数据包未记录在哈希表中时，则将数据表的记录插入到哈希表中。

[0090] 在一个实施例中，接收端300和服务器100之间的数据传输可基于TCP协议，处理模块104用于处理数据包，将其转换为符合TCP协议的数据包，在接收端300与服务器100建立了连接时，则由收发模块102直接将数据包下发到接收端300，接收端300接收数据包后返回确认包。

[0091] 在一个实施例中，设置模块106还用于当判断模块108判断得到数据包到达时间与上一次数据包到达时间的间隔没有超过设定的阈值时，则将数据包直接抛弃。

[0092] 在一个实施例中，服务器100每次接收到数据包时会记录数据包到达时间，而上一次数据包达到时间已记录在哈希表中。若判断模块108判断得到数据包到达时间与上一次数据包到达时间的间隔超过了设定的阈值，则说明已超时，即有相同的数据包已到达过并处理过，但还未收到接收端300返回的确认包（可能是服务器100下发数据包时丢失的原因，也可能是接收端300返回确认包丢失的原因）。若判断模块108判断得到数据包到达时间与上一次数据包到达时间的间隔没有超过设定的阈值，则说明未超时，即相同的数据包已到达并处理过，则可由设置模块108将数据包直接抛弃，不做处理。

[0093] 在一个实施例中，处理模块104还用于当判断模块108判断得到数据包对应的标志位不为已回复状态时处理数据包。设置模块106还用于当判断模块108判断得到数据包对应的标志位不为已回复状态时更新哈希表中的数据包到达时间。

[0094] 当判断模块108判断得到数据包对应的标志位不为已回复状态时，则说明服务器100还未收到接收端300返回的确认包，则由处理模块104处理该数据包，并通过收发模块
102将处理后的数据包重新下发到接收端300，并更新哈希表中的该数据包的到达时间。所更新的数据包到达时间可以在下一次服务器100接收到相同的数据包时，用于判断是否超时。

[0095] 服务器100在重复收到发送端200发送的数据包时，根据数据包对应的标志位即可得到服务器100是否已收到了接收端300返回的确认包，若服务器100已经收到了接收端300返回的确认包，则不会再向接收端300发送数据包，因此能够减少数据包的重发次数，节省了流量。

[0096] 下面以即时通信为应用场景对上述数据传输方法和系统进行详细阐述。如图5所示，在该应用场景下，用户端A与Web服务器之间通过TCP协议进行数据交互，用户端B与Web服务器之间通过UDP协议进行数据交互。用户端A的用户A通过浏览器登录Web即时通信工具，由浏览器通过TCP协议之上的HTTP协议，向Web服务器发起的登陆请求，Web服务器接收到登录请求后，向服务器群（具体的说，是某一个中转服务器）发起登录请求，如果收到成功的回应，则用户A登录上Web即时通信工具。用户端A的浏览器需不断维持与Web服务器之间的链接，如果有消息下发，会通过该链接将消息传递到用户端A。当一次消息接收成功后，Web服务器会关闭此链接，此时，用户端A的浏览器将发起下一次链接，以保证有通道可以提供数据下发。

[0097] 用户端B的用户B向用户端A的用户A发起即时通信消息时，该消息会组成一个数据包（即UDP消息包），由用户端B发送到其登录的中转服务器1，在由中转服务器1转发到用户端A登录的中转服务器2，由中转服务器2转发到Web服务器，Web服务器对接收到的UDP消息包进行处理。应当说明的是，在其他的应用场景下，也可以由用户端B直接发送即时通信消息至Web服务器，而不通过服务器群中的中转服务器1和中转服务器2，本发明不应以此为限制。

[0098] Web服务器收到UDP消息包时，提取其中的uin、fuin和seq，其中，uin为用户A的即时通信号码，fuin为用户B的即时通信号码，seq为该即时通信消息的序列号。Web服务器接收到UDP消息包后，会检查是否存在与uin对应的用户，如果不存在，说明用户A不在线，则将此UDP消息包丢弃（中转服务器2在若干次重发后，会将此消息放入离线消息服务器中，等待用户A登录后再发送）。如果存在，则用户A在线，Web服务器会以uin+fuin+seq为索引，在哈希表中进行查询。Web服务器维护的哈希表中每条记录的结构为uin+fuin+seq+time+flag，其中，time表示包含uin+fuin+seq的UDP消息包到达Web服务器的时间，flag为UDP消息包对应的标志位，flag默认为0，表示还未收到用户端A返回的确认包，如果Web服务器收到了用户端A返回的确认包，则将flag置为1。

[0099] Web服务器首先在哈希表中查询是否有uin+fuin+seq的记录，如果没有，说明该UDP消息包还未处理过，则处理该UDP消息包并该消息包的记录插入到哈希表中；如果有，则说明该UDP消息包已处理，则进一步判断UDP消息包是否超时，具体的，是将UDP消息包的此次到达时间与哈希表中记录的上一次UDP消息包到达时间进行对比，若这两者之间的时间间隔超过了设定的阈值，则超时。如果没有超时，则将该UDP消息包直接丢弃；如果超时，则进一步获取哈希表中的该UDP消息包对应的标志位（即flag），判断flag是否为1，如果flag=0，说明消息已处理但还未收到用户端A返回的确认包（可能是Web服务器下发消息后丢失，也可能是下发成功了，但是用户端A的回复丢失了），则Web服务器处理该UDP消息包并更新哈希表中的time为此次消息包的到达时间，处理后的消息包发送到用户端A；如果flag=1，则说明消息已处理，并得到了用户端A的回复（但可能还未将确认包回复到用户端B，导致用户端B因为未收到确认包而重复发送了UDP消息包），此时应将fuin+uin+sep组成数据包（即确认包）返回至中转服务器2，由中转服务器2转发给中转服务器1，再由中转服务器1转发到用户端B。

[0100] 以上所述实施例仅表达了本发明的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。因此，本发明专利的保护范围应以所附权利要求为准。