CN1716944A - 网络路径最大传输长度发现方法 - Google Patents
网络路径最大传输长度发现方法 Download PDFInfo
- Publication number
- CN1716944A CN1716944A CN 200410059487 CN200410059487A CN1716944A CN 1716944 A CN1716944 A CN 1716944A CN 200410059487 CN200410059487 CN 200410059487 CN 200410059487 A CN200410059487 A CN 200410059487A CN 1716944 A CN1716944 A CN 1716944A
- Authority
- CN
- China
- Prior art keywords
- message
- probe messages
- length
- maximum transmitted
- burst
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明公开了一种网络路径最大传输长度发现方法,所述方法包括:构造路径最大传输长度探测报文;由源节点向目的节点发送探测报文;目的节点根据收到的探测报文获取探测报文的分片信息并返回给源节点;源节点根据探测报文的分片信息获取路径最大传输长度。利用本发明,可以在复杂组网环境中高效、简便地获取路径最大传输长度,提高网络传输效率。
Description
技术领域
本发明涉及网络通信技术领域,具体涉及一种网络路径最大传输长度发现方法。
背景技术
IP(网际协议)网络包括不同节点及其互连链路,连接不同节点的链路可以有多种类型,不同类型链路的MTU(最大传输长度)缺省值不一样,以太网的标准值为1500字节,而多数ISP(因特网服务提供商)提供的拨号网络的标准值为576字节。MTU是网络连接中数据链路所允许传送报文的最大长度。两台主机通过互联网进行通信时,从源节点到目的节点之间可能需要跨越多重网络路径,报文需要经过多个路由器逐跳转发,主机与路由器之间,路由器与路由器之间都是直连的数据链路,各段链路的MTU值不一定相同,因此,为使跨越多重网络路径的两个主机通信,重要的不是两台主机所在网络的MTU的值,而是两台通信主机路径中的最小MTU,即PMTU(路径最大传输长度)。为了保证较大长度报文的传输,当报文长度超过底层链路MTU的限制时,需要对其进行分片传输,使每一片都小于MTU。分片的报文在到达目的主机后,由IP层重组为原报文。其分片与重组过程如图1所示。
分片重组技术的使用,虽然给使用者带来了方便,但也存在一些问题:如果一个报文中的一个分片没有正常到达目的主机,则整个报文就传输失败,这时IP的上层只能重新传输整个报文。因此,报文的分片可能会导致网络性能的降低。所以为了提高报文传输效率,发送IP报文的一方希望所传输的报文在到达目的主机的过程中不进行分片,也就是说希望通过传输长度不大于网络路径的最小MTU的数据包来避免分段,这就需要发送方一开始就知道整个路径上最小的链路MTU,即PMTU。
RFC1191协议描述了路径MTU的发现机制,通过发送分组在分组头部设置不分片标志字段并判断返回ICMP(互联网控制管理协议)错误消息来实现。发送的第一个分组的长度与出口MTU相等,每次收到ICMP不能分片错误时,就减少分组长度,以下一个较小的MTU值发送。具体过程如下:
(1)发送方构造一个充分大的IP探测报文(长度大于出口的MTU),对IP头中的DF(Don’t Frament)位置位,标识该报文不可分片,然后发送。
(2)沿途的路由器如果要对报文分片,在检查到DF位置位后,就会丢弃报文,并向源主机返回一个目的不可达类型的ICMP差错控制报文。
(3)发送方收到ICMP差错控制报文后,可以减小探测报文的长度,然后再发送出去。
减小探测报文的长度可以采用以下两种策略:
枚举法:由于已知的数据链路种类是有限的,所以发送方可以预先罗列出所有可能的链路MTU值,发送的探测报文由高到低依次采用这些长度进行探测。
反馈法:扩展ICMP的差错控制报文,在返回的目的不可达报文的保留字段中记录路由器出口的MTU值,接收方可根据此值对报文的长度进行调整。
(4)如此反复探测,直到发送方认为报文已不会再被分片为止,此时的报文长度就是PMTU。
在上述探测过程中,可以利用ICMP的echo/reply报文来实现该方案。
该方案虽然目前广为使用,但是效率不高。在最坏的情况下,报文有可能会在途经的每个路由器处进行报文分片。如果沿途有n个路由器,则该方法在最坏的情况下就需要探测n次。另外,在有隧道网关的情况下这种探测方式有可能会失效。
由于公共IP的短缺,在组建局域网时,通常使用保留地址作为内部IP,这些保留地址在Internet上是无法被路由的,所以在正常情况下无法直接通过Internet访问到在局域网内的主机。为了实现这一目的,需要使用VPN(虚拟专用网)隧道技术,其实现过程如图2所示。其中,新IP头的源地址是发送方的隧道网关,目的地址是接收方的隧道网关。报文发送到接收方隧道网关时,由该网关去掉新的IP头,恢复原来的IP报文再继续转发。现在互联网中有许多的隧道网关,如IPv4/IPv6网关、Ipsec(IP security)网关。
在互联网传输过程中,如果中途路由器要对超长报文分片,但由于探测报文标志为不可分片,则中途路由器会丢弃报文,并返回目的不可达类型的ICMP差错控制报文,该报文中会携带原IP报文的首部及其后续8个字节的内容。其过程如图3所示。
在有隧道网关的情况下,中途路由器能处理的只是隧道报文,不可能看到原来的IP头,所以IP头1的目的地址是发送方的隧道网关,源地址是中途路由器。而ICMP携带的原报文信息只是隧道报文的IP头及其后续的8个字节。
在上述情况中,发送方隧道网关收到ICMP差错控制报文后,应该转发给源主机,这样才能通知主机报文超长。但通常情况下,隧道网关仅通过报文内容是难以确定原IP报文的源IP地址的,因此,也就无法将ICMP报文返回给源主机。
发明内容
本发明的目的在于提供一种网络路径最大传输长度发现方法,以克服现有技术中获取路径MTU时效率低、不能适应复杂网络环境的问题。
本发明的目的是通过以下技术方案实现的:
一种网络路径最大传输长度发现方法,所述网络包括多个节点,所述方法包括:
A、构造路径最大传输长度探测报文;
B、由源节点向目的节点发送所述探测报文;
C、目的节点根据所述探测报文获取所述探测报文的分片信息并返回给所述源节点;
D、所述源节点根据所述探测报文的分片信息获取所述路径最大传输长度。
所述步骤A包括:
A1、获取源节点出口的最大传输长度;
A2、设定长度大于所述源节点出口的最大传输长度的预定格式IP报文作为所述探测报文。
所述预定格式IP报文为可分片报文。
所述步骤A还包括:
定义所述探测报文的处理协议报文;
将所述处理协议报文封装到所述探测报文中。
所述探测报文处理协议包括:扩展的互联网控制管理协议和私有协议。
所述扩展的互联网控制管理协议具体为:
回应请求报文中将代码定义为要求接收方不要对报文进行重组,直接将报文的分片返回给请求方;
回应应答报文中将代码定义为返回原报文的分片信息。
所述步骤B包括:
当所述源节点至目的节点沿途的中间节点出口的最大传输长度小于所述探测报文的长度时,对所述探测报文进行分片传输;
当所述源节点至目的节点沿途的中间节点出口的最大传输长度大于所述探测报文的长度时,对所述探测报文直接传输。
所述步骤C包括:
获取所述探测报文头域中的偏移量字段;
根据所述偏移量字段获取所述探测报文的第一个分片信息。
所述步骤D包括:
D1、所述目的节点根据所述探测报文处理协议向所述源节点返回所述探测报文的第一个分片信息;
D2、所述源节点根据接收的第一个分片信息获取所述路径最大传输长度。
所述D1包括:
所述目的节点根据所述探测报文处理协议构造包含所述探测报文的第一个分片信息的回应报文;
利用网络层的传输协议将所述回应报文传送给所述源节点。
由以上本发明提供的技术方案可以看出,本发明对PMTU的探测过程只需发送一个可分片的、充分长的IP探测报文,即可从应答消息中获取路径最大传输长度,提高了探测效率;由于探测过程中不需要与沿途的路由器进行消息交互,只需等待目的主机返回的应答消息,避免了受到各种不可预料的复杂组网环境的影响,可以适应各种不同的网络环境;如果通过扩展ICMP协议来控制探测报文的传送,则不需要增加任何新的协议即可完成探测过程,兼容性强;PMTU的有效发现,可以使IP报文在传输中不分片或减少分片,减少了分片与重组过程及传输中单个分片丢失造成的整个传输无效,进而能够提高网络的传输效率。
附图说明
图1是IP报文分片与重组过程示意图;
图2是隧道网关原理示意图;
图3是现有技术中在隧道网关环境中探测MTU的过程示意图;
图4是IP报文格式;
图5是ICMP的回应请求与应答报文格式;
图6是本发明方法的流程图;
图7是本发明方法中定义的封装扩展ICMP协议后的探测报文格式;
图8是本发明方法中探测报文分片传输示例;
图9是本发明方法中探测报文在隧道网关环境中的分片与传输示例。
具体实施方式
本发明的核心是基于IP报文的传输规律,沿途路径上的路由器根据各自出口的MTU(最大传输长度),对超过该长度的IP报文按照原报文的字节顺序,由前向后进行分段,这样,在每一个路由器的出口,如果IP报文被分片,则在分出的多个片段中,第一个报文的长度一定等于出口的MTU。因此,构造一个充分长的报文,从源节点到目的节点,不论经过几个中间节点,也不论经过的中间节点属于同一网络还是属于异构网络,当该报文到达目的节点后,众多分片的第一个分片的长度即为PMTU(路径最大传输长度)。再通过特定协议控制,由目的节点将该分片或其长度返回给发送方,使发送方通过一次探测就可发现PMTU。
为了使本技术领域的人员更好地理解本发明方案,下面结合附图和实施方式对本发明作进一步的详细说明。
参照图4所示IP报文格式:包括以下字段:
版本号:协议版本;
报头长度:指示报头的长度;
服务类型域:指示如何处理数据报以及所需服务类型;
数据报长度域:指示整个IP数据报长度(包括头和数据),当数据报超过此长度时,还要分片传输,每片中都有报头和数据片组成;
标识域:是数据包的ID号,用来控制分片重组,标识分片属于哪个数据包,发送端发送的数据包标识字段都是一个唯一值,该值在分片时被复制到每个片中;
标志域:包括3个比特,其中,第一个比特R保留未用;第二个比特DF(Don’tfragment)表示目标主机不能分片;第二个比特MF(More fragment):“1”表示本分片后还有分片,“0”表示本分片后没有分片了,除了最后一片外,其他每个组成数据报的片都要把该比特置“1”;
片偏移:分片在原数据包中的位置,该片偏移原始数据包开始处的位置;
生存时间:数据包在网络中存在的时间;
协议类型域:表示创建该数据包的高级协议类型。如“1”表示ICMP协议,“6”表示TCP(传输控制协议)协议,“17”表示UDP(用户数据报文协议)协议等;
源IP地址和目标IP地址;
选项:用于网络控制。
ICMP是网标协议的扩展,它处理差错和控制信息,特别是网关和主机使用该协议可把分组网络传输过程中的异常情况或发生的差错报告给该分组的始发方,ICMP需要封装在IP数据包里传送。由于ICMP协议的广泛应用,因此,本发明采用该协议实现探测报文的功能。
ICMP最常见的回应请求与应答报文格式如图5所示:类型0为回应应答报文,8为回应请求报文。
原报文类型和代码的定义如下表1所示:
表1:
报文类型 | 类型 | 代码 |
ICMP echo | 8 | 0 |
ICMP reply | 0 | 0 |
在现有标准协议中,对于代码字段并未作定义,因此,可以扩展ICMP的echo/reply,即利用该字段来标识本发明中所述的PMTU探测报文,扩展的ICMPecho/reply定义如下表2所示:
表2:
报文类型 | 类型 | 代码 |
ICMP echo | 8 | 1 |
ICMP reply | 0 | 1 |
扩展的ICMP echo/reply报文与原报文格式一样,类型也一样,只是扩展了代码的定义和返回的参数:
代码为1时,扩展的ICMP echo表示要求接收方将报文首个分片的长度返回。
代码为1时,扩展的ICMP reply表示返回原报文首个分片的长度。长度的值在选项数据中。
基于上面对本发明中所使用的IP协议报文和扩展的ICMP协议描述,下面参照图6所示流程对本发明作详细说明。
图6是本发明的详细流程图,包括以下步骤:
步骤601:获取源节点出口的最大传输长度。
本技术领域人员知道,TCP/IP是一组协议簇,是互联网的核心,其中最主要的是IP(网际协议)和TCP(传输控制协议)。TCP/IP协议实现了网络间的互联。通过路由器,可以将彼此独立的网络互联起来,因此,IP报文的传送就是从源节点(发送端)经过不同的路由器,然后传送到目的节点(接收端)。为了使IP报文在不同节点之间正确传输,需要对发送端口、路由器、接收端口进行一系列的参数配置,MTU和其他TCP/IP配置选项都保存在发送端主机的注册表中,通过注册表就可获知发送端出口的MTU值。
步骤602:设定长度大于源节点出口的最大传输长度的预定格式IP报文作为探测报文。
图4描述了IP报文的标准格式,其头部字节数是固定的,但其数据域的长度是可以任意设定的,并在IP报文的头部数据报长度域字段中给出。因此,可以构造一个总长度大于发送端出口MTU值的IP报文作为PMTU探测报文。设定该报文中的DF为“1”,即设定该探测报文可分片。
步骤603:定义探测报文的处理协议。
对于超过路径MTU的IP报文,在正常传输情况下会进行分片和重组,重组过程发生在接收端主机,由接收端主机根据收到的IP分片报文头部信息,将各分片重新组合成一个原始的IP报文。但发送探测报文的目的是要发现路径MTU,而不是要对其正确重组,因此还需要一种协议来对该探测报文提供某些不同的服务,也就是说定义探测报文的处理协议。
由于标准的ICMP协议用于在IP主机、路由器之间进行错误信息和控制信息的传递。这些控制信息包括网络通不通、主机是否可达、路由是否可用等网络本身的消息。这些控制信息虽然并不传输用户数据,但对用户数据的传递起着重要的作用。而且,标准ICMP协议中的代码字段并未定义,因此,本发明首选ICMP协议,通过定义其代码字段扩展该协议(参见前面表2的定义),控制错误信息的传输。当然,也可定义其他的私有协议来实现对探测报文的处理。只要发送方和接收方都要接受该协议即可。
步骤604:将定义的处理协议封装到探测报文中。
将扩展的ICMP echo报文封装在探测报文IP数据包中,封装后探测报文结构如图7所示。
在该探测报文由源节点到目的节点传输过程中,沿途可能会经过多个不同的中间节点,这些节点可能分属于不同的网络,比如,以太网、FDDI(基于光纤的分布数据接口)、ATM(异步传输模式)等,这些节点出口的MTU可能相同,也可能不同,每经过一个节点,都要检查该报文的长度,当该节点出口的最大传输长度小于该探测报文的长度时,要对探测报文进行分片传输,否则,会直接传输。
具体分片传输过程如下:
由于构造的探测报文长度大于发送端出口的MTU,所以首先会在发送端出口进行分片,第一个分片的长度为发送端出口的MTU,如果需要多个分片,则每个分片的长度都小于或等于发送端出口的MTU;
每一个IP分片各自路由;
经过沿途节点时,如果分片后的报文长度大于该路由器出口的MTU,则在该路由器出口继续分片,第一个分片的长度为该路由器出口的MTU,如果需要多个分片,则每个分片的长度都小于或等于该路由器出口的MTU;
每一个IP分片各自路由;
按上述方式传送,直到目的节点。
图8描述了探测报文分片传输示例:
假设局域网1中允许的最大数据域长度为1500字节,局域网2的为1000字节,广域网分组中允许的最大数据域长度为670字节,″X,Y,ID,Length,MF,FO″表示长度为Length、标识符为ID的数据报从节点X发往节点Y,MF和FO分别表示分片和片偏移量。
数据报中不存在任何选项,每个数据报中都含有20字节的IP头。主机1按照本机出口的MTU值构造长度为1500字节的IP数据报文作为探测报文,其中的有效数据为1480字节。
探测报文在局域网1中不分片,经过路由器1时,要转发到广域网,在路由器1的出接口处进行分片,1480字节的数据域被分为3段,每段中数据域的数据长度分别为650、650和180字节。分片报文进入局域网2后不需要再分片,于是主机2将收到这三个分片,主机2将对首片报文(偏移量为0)进行检查,看是否是PMTU的探测报文,如果是,就将向源主机返回首个分片的IP报文长度。
图9给出了在有隧道网关存在的环境中,报文的分片和传输过程。隧道网关可以是IPv4/IPv6网关,IPsec网关。网络参数的假设与图8相似,只是在隧道网关1处,对进入隧道的报文将增加20字节的外层IP头,在隧道网关2处将去掉这20字节的外层IP头。具体的传输过程如下:
主机1发出一个长度为1500字节的IP探测报文,在局域网1中不分片。探测报文到达隧道网关1后,在隧道网关1的出接口需要进行分片,由于每个分片还需要加上一个新的IP头,所以分片的最大长度比出口的MTU(670)还要少20个字节,应该是650。这样探测报文从隧道网关1出来后就被分成了三片,各片的总长度和数据长度分别是:670(630),670(630),260(220)。
这三片报文到达隧道网关2后,将被剥去外层的IP头,在局域网2上传输不需要分片,这样到达主机2的各分片长度及其有效数据的长度将是:650(630),650(630),240(220)。
步骤605:目的节点根据接收的探测报文获取探测报文的分片信息。
目的节点主机接收到上述分片报文后,根据各分片报文头部解析出ICMPecho报文,其中代码为1,即知不需对该分片报文重组,直接将报文的分片返回给请求方。
于是,目的节点主机根据分片报文的头部信息,由标识域中的ID号识别该分片属于哪个数据包,由偏移量字段得知该分片在原数据包中的位置。
这样,就可获得探测报文的第一个分片信息,这些信息包括:数据包ID号,协议类型,源IP地址,目的IP地址等。
由源节点主机发送的探测报文不论经过多少次分片,由于每次分片时都是根据节点出口的MTU来划分的,并且是按照原报文的字节顺序由前向后来划分,其最大长度等于节点出口的MTU,因此探测报文的第一个分片包含了路径MTU的信息,也就是报文头部的数据报长度域字段。因为IP报文每次被分片后,该字段的值要修改为分片后的IP报文长度,因此获取该值也就得知了PMTU。
IP报文的长度是由报文的发送方来控制的,因此,接收方还需要将获取的第一个分片报文的信息传送给源节点主机,所以,
进到步骤606:由目的节点根据探测报文处理协议构造包含探测报文的第一个分片信息的回应报文。
然后,进到步骤607:利用网络层的传输协议将所述回应报文传送给所述源节点。
同样,可以采用扩展的ICMP协议,回应ICMP reply报文,在该报文中通过代码定义为返回原报文的分片信息。
如果采用私有协议,则可根据需要定义协议报文的格式。
步骤608:源节点根据接收的第一个分片信息获取路径最大传输长度。
由此可见,与现有技术相比,本发明只需一次探测过程,即可有效获取PMTU,不需要反复探测,也不受复杂网络环境的影响。
虽然通过实施例描绘了本发明,本领域普通技术人员知道,本发明有许多变形和变化而不脱离本发明的精神,希望所附的权利要求包括这些变形和变化而不脱离本发明的精神。
Claims (10)
1、一种网络路径最大传输长度发现方法,所述网络包括多个节点,其特征在于,所述方法包括:
A、构造路径最大传输长度探测报文;
B、由源节点向目的节点发送所述探测报文;
C、目的节点根据所述探测报文获取所述探测报文的分片信息并返回给所述源节点;
D、所述源节点根据所述探测报文的分片信息获取所述路径最大传输长度。
2、根据权利要求1所述的网络路径最大传输长度发现方法,其特征在于,所述步骤A包括:
A1、获取源节点出口的最大传输长度;
A2、设定长度大于所述源节点出口的最大传输长度的预定格式IP报文作为所述探测报文。
3、根据权利要求2所述的网络路径最大传输长度发现方法,其特征在于,所述预定格式IP报文为可分片报文。
4、根据权利要求3所述的网络路径最大传输长度发现方法,其特征在于,所述步骤A还包括:
定义所述探测报文的处理协议报文;
将所述处理协议报文封装到所述探测报文中。
5、根据权利要求4所述的网络路径最大传输长度发现方法,其特征在于,所述探测报文处理协议包括:扩展的互联网控制管理协议和私有协议。
6、根据权利要求5所述的网络路径最大传输长度发现方法,其特征在于,所述扩展的互联网控制管理协议具体为:
回应请求报文中将代码定义为要求接收方不要对报文进行重组,直接将报文的分片返回给请求方;
回应应答报文中将代码定义为返回原报文的分片信息。
7、根据权利要求3或4所述的网络路径最大传输长度发现方法,其特征在于,所述步骤B包括:
当所述源节点至目的节点沿途的中间节点出口的最大传输长度小于所述探测报文的长度时,对所述探测报文进行分片传输;
当所述源节点至目的节点沿途的中间节点出口的最大传输长度大于所述探测报文的长度时,对所述探测报文直接传输。
8、根据权利要求3或4所述的网络路径最大传输长度发现方法,其特征在于,所述步骤C包括:
获取所述探测报文头域中的偏移量字段;
根据所述偏移量字段获取所述探测报文的第一个分片信息。
9、根据权利要求8所述的网络路径最大传输长度发现方法,其特征在于,所述步骤D包括:
D1、所述目的节点根据所述探测报文处理协议向所述源节点返回所述探测报文的第一个分片信息;
D2、所述源节点根据接收的第一个分片信息获取所述路径最大传输长度。
10、根据权利要求9所述的网络路径最大传输长度发现方法,其特征在于,所述D1包括:
所述目的节点根据所述探测报文处理协议构造包含所述探测报文的第一个分片信息的回应报文;
利用网络层的传输协议将所述回应报文传送给所述源节点。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN 200410059487 CN1716944A (zh) | 2004-06-28 | 2004-06-28 | 网络路径最大传输长度发现方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN 200410059487 CN1716944A (zh) | 2004-06-28 | 2004-06-28 | 网络路径最大传输长度发现方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN1716944A true CN1716944A (zh) | 2006-01-04 |
Family
ID=35822364
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN 200410059487 Pending CN1716944A (zh) | 2004-06-28 | 2004-06-28 | 网络路径最大传输长度发现方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN1716944A (zh) |
Cited By (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2009026824A1 (fr) * | 2007-08-22 | 2009-03-05 | Huawei Technologies Co., Ltd. | Procédé, dispositif et système pour transférer des messages multiplex |
CN101931630A (zh) * | 2010-09-01 | 2010-12-29 | 中兴通讯股份有限公司 | 一种传输sip消息的方法、用户设备及网元 |
CN101459582B (zh) * | 2007-12-13 | 2011-05-11 | 华为技术有限公司 | 一种快速重路由的方法及路由器 |
CN102469016A (zh) * | 2010-11-16 | 2012-05-23 | 杭州华三通信技术有限公司 | 反向确定路径最大传输单元的方法和装置 |
CN103297348A (zh) * | 2013-05-10 | 2013-09-11 | 汉柏科技有限公司 | 防止esp/ah报文分片的方法 |
CN105634977A (zh) * | 2014-10-29 | 2016-06-01 | 杭州华三通信技术有限公司 | 发现路径最大传输单元的方法和装置 |
CN106411677A (zh) * | 2016-09-06 | 2017-02-15 | 杭州迪普科技有限公司 | 一种确定vpn数据通道的最优mtu的方法和装置 |
CN107925629A (zh) * | 2015-08-31 | 2018-04-17 | 华为技术有限公司 | 一种IPv6网络中数据报文的发送方法及装置 |
CN109873763A (zh) * | 2017-12-05 | 2019-06-11 | 北京华为数字技术有限公司 | 一种通信方法及设备 |
CN111654354A (zh) * | 2020-05-28 | 2020-09-11 | 北京小米移动软件有限公司 | 最大传输单元mtu的探测方法、装置及存储介质 |
CN113890858A (zh) * | 2021-09-29 | 2022-01-04 | 杭州迪普科技股份有限公司 | Pmtu的探测方法及装置 |
CN114244782A (zh) * | 2021-08-27 | 2022-03-25 | 新华三信息安全技术有限公司 | 路径最大传输单元Path MTU值调整方法及装置 |
CN114363234A (zh) * | 2020-10-14 | 2022-04-15 | 阿里巴巴集团控股有限公司 | 数据处理方法及系统、电子设备、路由器 |
WO2023173876A1 (zh) * | 2022-03-15 | 2023-09-21 | 深圳市广和通无线股份有限公司 | 数据通信方法、装置、设备和介质 |
-
2004
- 2004-06-28 CN CN 200410059487 patent/CN1716944A/zh active Pending
Cited By (24)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2009026824A1 (fr) * | 2007-08-22 | 2009-03-05 | Huawei Technologies Co., Ltd. | Procédé, dispositif et système pour transférer des messages multiplex |
CN101459582B (zh) * | 2007-12-13 | 2011-05-11 | 华为技术有限公司 | 一种快速重路由的方法及路由器 |
CN101931630A (zh) * | 2010-09-01 | 2010-12-29 | 中兴通讯股份有限公司 | 一种传输sip消息的方法、用户设备及网元 |
CN101931630B (zh) * | 2010-09-01 | 2014-09-10 | 中兴通讯股份有限公司 | 一种传输sip消息的方法、用户设备及网元 |
CN102469016A (zh) * | 2010-11-16 | 2012-05-23 | 杭州华三通信技术有限公司 | 反向确定路径最大传输单元的方法和装置 |
CN102469016B (zh) * | 2010-11-16 | 2014-11-05 | 杭州华三通信技术有限公司 | 反向确定路径最大传输单元的方法和装置 |
CN103297348A (zh) * | 2013-05-10 | 2013-09-11 | 汉柏科技有限公司 | 防止esp/ah报文分片的方法 |
US10404611B2 (en) | 2014-10-29 | 2019-09-03 | Hewlett Packard Enterprise Development Lp | Discovering path maximum transmission unit |
CN105634977B (zh) * | 2014-10-29 | 2019-06-04 | 新华三技术有限公司 | 发现路径最大传输单元的方法和装置 |
CN105634977A (zh) * | 2014-10-29 | 2016-06-01 | 杭州华三通信技术有限公司 | 发现路径最大传输单元的方法和装置 |
US11477106B2 (en) | 2015-08-31 | 2022-10-18 | Huawei Technologies Co., Ltd. | Data packet sending method and apparatus in IPV6 network |
CN107925629B (zh) * | 2015-08-31 | 2021-05-18 | 华为技术有限公司 | 一种IPv6网络中数据报文的发送方法及装置 |
CN107925629A (zh) * | 2015-08-31 | 2018-04-17 | 华为技术有限公司 | 一种IPv6网络中数据报文的发送方法及装置 |
CN113411260A (zh) * | 2015-08-31 | 2021-09-17 | 华为技术有限公司 | 一种IPv6网络中数据报文的发送方法及装置 |
CN106411677A (zh) * | 2016-09-06 | 2017-02-15 | 杭州迪普科技有限公司 | 一种确定vpn数据通道的最优mtu的方法和装置 |
CN109873763B (zh) * | 2017-12-05 | 2021-12-03 | 北京华为数字技术有限公司 | 一种通信方法及设备 |
CN109873763A (zh) * | 2017-12-05 | 2019-06-11 | 北京华为数字技术有限公司 | 一种通信方法及设备 |
CN111654354A (zh) * | 2020-05-28 | 2020-09-11 | 北京小米移动软件有限公司 | 最大传输单元mtu的探测方法、装置及存储介质 |
CN111654354B (zh) * | 2020-05-28 | 2023-08-08 | 北京小米移动软件有限公司 | 最大传输单元mtu的探测方法、装置及存储介质 |
CN114363234A (zh) * | 2020-10-14 | 2022-04-15 | 阿里巴巴集团控股有限公司 | 数据处理方法及系统、电子设备、路由器 |
CN114244782A (zh) * | 2021-08-27 | 2022-03-25 | 新华三信息安全技术有限公司 | 路径最大传输单元Path MTU值调整方法及装置 |
CN113890858A (zh) * | 2021-09-29 | 2022-01-04 | 杭州迪普科技股份有限公司 | Pmtu的探测方法及装置 |
CN113890858B (zh) * | 2021-09-29 | 2023-10-20 | 杭州迪普科技股份有限公司 | Pmtu的探测方法及装置 |
WO2023173876A1 (zh) * | 2022-03-15 | 2023-09-21 | 深圳市广和通无线股份有限公司 | 数据通信方法、装置、设备和介质 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN1221153C (zh) | 数据包传输方法及通信系统 | |
Clausen et al. | Mobile ad hoc network (manet) neighborhood discovery protocol (nhdp) | |
Li et al. | IP/ICMP translation algorithm | |
CN1266913C (zh) | 通过接入网络的隧道传送 | |
Coltun et al. | OSPF for IPv6 | |
KR100997075B1 (ko) | 통신 네트워크에서 비상태 어드레스 구성을 지원하는 액세스 장치, 라우팅 장치 및 방법 | |
CN1716944A (zh) | 网络路径最大传输长度发现方法 | |
CN1716954A (zh) | 基于过渡机制的IPv6网和IPv4网间互通的方法 | |
CN1411239A (zh) | 无线通信系统以及无线局域网接入点 | |
US20190124185A1 (en) | Method for operating a software defined network and a software defined network | |
CN1750512A (zh) | 单播反向路径转发方法 | |
CN1722698A (zh) | 多协议标签交换虚拟专用网及其控制和转发方法 | |
CN1822573A (zh) | 用于在无线通信系统中控制数据通信的系统和方法 | |
CN1968184A (zh) | 区域网络的链路层通信方法及其应用的网络设备 | |
CN1503539A (zh) | 在IPv6中使用接口标识符的路由选择表管理方法 | |
WO2012106935A1 (zh) | 数据通信网络配置方法、网关网元及数据通信系统 | |
CN1838632A (zh) | 移动IPv6报文穿越防火墙的实现方法 | |
WO2008014723A1 (fr) | Procédé et dispositif permettant la mise en oeuvre d'un réseau privé virtuel (vpn) fondé sur une structure d'adresse ipv6 | |
CN1881935A (zh) | 移动互联网协议路由处理方法和系统及路由器 | |
CN1297105C (zh) | 基于虚拟专用网的实现多角色主机的方法 | |
Bao et al. | IP/ICMP translation algorithm | |
CN1848799A (zh) | 实现虚拟专用网的方法 | |
CN1181655C (zh) | 移动ip中一种数据包传输的方法 | |
CN101035087A (zh) | 报文转发方法、系统及设备 | |
CN1893392A (zh) | 防止用户获得运营商网络信息的方法和装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C12 | Rejection of a patent application after its publication | ||
RJ01 | Rejection of invention patent application after publication |
Open date: 20060104 |