RFC1191

合集下载

关于 MTU

关于 MTU

关于MTU详细解释因特网协议允许IP分片,这样就可以将数据报分成足够小的片段以通过那些最大传输单元小于该数据报原始大小的链路了。

这一分片过程发生在IP层(OSI模型的第三层,即网络层),它使用的是将分组发送到链路上的网络接口的最大传输单元的值。

原始分组的分片都被加上了标记,这样目的主机的IP层就能将分组重组成原始的数据报了。

在因特网协议中,一条因特网传输路径的“路径最大传输单元”被定义为从源地址到目的地址所经过“路径”上的所有IP跳的最大传输单元的最小值。

或者从另外一个角度来看,就是无需进一步分片就能穿过这条“路径”的最大传输单元的最大值。

RFC 1191描述了“路径最大传输单元发现方法”,这是一种确定两个IP主机之间路径最大传输单元的技术,其目的是为了避免IP分片。

在这项技术中,源地址将数据报的DF(Don't Fragment,不要分片)位置位,再逐渐增大发送的数据报的大小——路径上任何需要将分组进行分片的设备都会将这种数据报丢弃并返回一个“数据报过大”的ICMP响应到源地址——这样,源主机就“学习”到了不用进行分片就能通过这条路径的最大的最大传输单元了。

不幸的是,越来越多的网络封杀了ICMP的传输(譬如说为了防范DDOS攻击)——这使得路径最大传输单元发现方法不能正常工作,其常见表现就是一个连接在低数据流量的情况下可以正常工作,但一旦有大量数据同时发送,就会立即挂起(例如在使用IRC的时候,客户会发现在发送了一个禁止IP欺骗的ping之后就得不到任何响应了,这是因为该连接被大量的欢迎消息堵塞了)。

而且,在一个使用因特网协议的网络中,从源地址到目的地址的“路径”常常会为了响应各种各样的事件(负载均衡、拥塞、断电等等)而被动态地修改——这可能导致路径最大传输单元在传输过程中发生改变——有时甚至是反复的改变。

其结果是,在主机寻找新的可以安全工作的最大传输单元的同时,更多的分组被丢失掉了。

深入理解IP包分片原理

深入理解IP包分片原理

深入理解IP‎包分片原理原理, 分片一、关键术语MTU MRU PMTU MSS包分片‎ip 分片和tcp‎分片差异1.IP分片产生‎的原因是网络‎层的MTU;TCP分段产‎生原因是MS‎S.2.IP分片由网‎络层完成,也在网络层进‎行重组;TCP分段是‎在传输层完成‎,并在传输层进‎行重组. //透明性3.对于以太网,MSS为14‎60字节,而MUT往往‎会大于MSS‎.故采用TCP‎协议进行数据‎传输,是不会造成I‎P分片的。

若数据过大,只会在传输层‎进行数据分段‎,到了IP层就‎不用分片。

而我们常提到‎的IP分片是‎由于UDP传‎输协议造成的‎,因为UDP传‎输协议并未限‎定传输数据报‎的大小。

为什么会有I‎P分片?直接原因是上‎层协议企图发‎送一段数据,其长度超过了‎M TU (Maxitu‎m Transm‎i ssion‎Unit)。

什么情况,或者说什么协‎议会尝试发送‎这么长的数据‎?常见的有UD‎P和ICMP‎,需要特别注意‎的是,TCP一般不‎会。

为什么TCP‎不会造成IP‎分片呢?原因是TCP‎自身支持分段‎:当TCP要传‎输长度超过M‎S S(Maxitu‎m Segmen‎t Size)的数据时,会先对数据进‎行分段,正常情况下,MSS小于M‎T U,因此,TCP一般不‎会造成IP分‎片。

而UDP和I‎C MP就不支‎持这种分段功‎能了,UDP和IC‎M P认为网络‎层可以传输无‎限长(实际上有65‎535的限制‎)的数据,当这两种协议‎发送数据时,它们不考虑数‎据长度,仅在其头部添‎加UDP或I‎C MP首部,然后直接交给‎网络层就万事‎大吉了。

接着网络层I‎P协议对这种‎“身长头短”的数据进行分‎片,不要指望IP‎能很“智能”地识别传给它‎的数据上层头‎部在哪里,载荷又在哪里‎,它会直接将整‎个的数据切成‎N个分片,这样做的结果‎是,只有第一个分‎片具有UDP‎或者ICMP‎首部,而其它分片则‎没有。

传输层学习之四TCP长肥管道

传输层学习之四TCP长肥管道

TCP也可以通过保护定时器来检测对端是否已经“死掉”。

这和其它协议的保护机制是类的,没什么神奇之处。

二、路径MTU发现路径MTU指的是当前在两个主机之间的路径上任何网络上的最小MTU。

IP中的路径MTU发现的实现:在IP首部中设置“不要分片(DF)”比特,来发现当前路径上的路由器是否需要对正在发送的IP数据报进行分片。

如果一个待转发的IP数据报被设置DF比特,而其长度又超过了MTU,那么路由器将返回ICMP不可达的差错。

然后就降低数据报长度,再尝试该过程,直到找到一个可以成功到达对端的MTU,它就是路径MTU。

TCP的路径MTU发现按如下方式进行:在连接建立时,TCP使用初始的MSS作为起始的报文段大小。

初始的MSS为对端声明的MSS,如果对端没有指定一个MSS,则默认为536。

一旦选定了起始的报文段大小,在该连接上的所有被TCP发送的IP数据报都将被设置DF比特。

如果某个中间路由器需要对一个设置了DF标志的数据报进行分片,它就丢弃这个数据报,并产生一个的ICMP的“不能分片”差错。

如果收到这个ICMP差错,TCP就减少段大小并进行重传。

当由这个ICMP差错引起的重传发生时,拥塞窗口不需要变化,但要启动慢启动。

由于路由可以动态变化,因此在最后一次减少路径MTU的一段时间以后,可以尝试使用一个较大的(直到等于对端声明的MSS或输出接口MTU的最小)。

RFC1191推荐这个时间间隔为10分钟。

三、长肥管道一个连接的时延带宽积可表示为:capacity(b)=bandwidth(b/s)×round-triptime(s)。

也可称它为两端的管道大小。

具有大的带宽时延乘积的网络被称为长肥网络(LongFatNetwork,即LFN),而一个运行在LFN上的TCP连接被称为长肥管道。

使用长肥管道会遇到多种问题。

TCP首部中窗口大小为16bit,因此窗口大小最大为65535字节,这就将发送方发送但未被确认的数据的总长度限制到了65536字节。

解决GRE和IPSEC中的IP分段MTUMSS和PMTUD问题-Cisco

解决GRE和IPSEC中的IP分段MTUMSS和PMTUD问题-Cisco

解决 GRE 和 IPsec 中的 IPv4 分段、MTU、MSS 和 PMTUD 问题ContentsIntroductionIPv4 分段和重组IPv4 分段相关问题避免 IPv4 分段:TCP MSS 用途及其工作原理场景 1场景 2PMTUD 是什么?场景 3场景 4PMTUD 相关问题需要 PMTUD 的常见网络拓扑隧道有关隧道接口的注意事项在隧道终端作为 PMTUD 参与者的路由器方案 5方案 6纯 IPsec 隧道模式方案 7方案 8GRE 与 IPv4sec 协同工作方案 9方案 10更多建议Related InformationIntroduction本文档介绍 IPv4 分段和路径最大传输单位发现 (PMTUD) 的工作原理,此外还会讨论在考虑不同的IPv4 隧道组合时会涉及 PMTUD 行为的一些场景。

目前互联网上广泛使用的 IPv4 隧道引起了人们对涉及 IPv4 分段和 PMTUD 问题的重视。

IPv4 分段和重组IPv4 协议设计用于各种传输链路。

尽管 IPv4 数据报的最大长度为 65535 字节,但大多数传输链路强制执行更小的最大数据包长度限制(即 MTU)。

MTU 的值取决于传输链路的类型。

设计 IPv4 时已考虑 MTU 的差异,因为它允许路由器根据需要将 IPv4 数据报分段。

接收站负责将这些分段重组回原始的全尺寸 IPv4 数据报。

IPv4 分段功能将数据报拆分为多个部分,随后可以对这些部分进行重组。

IPv4 报头中的 IPv4 源地址、目的地址、标识符、总长度和分段偏移量字段、“更多分段”以及“不分段”标志都被用于 IPv4 分段和重组。

有关 IPv4 分段和重组机制的更多信息,请参阅 RFC 791。

下图显示了 IPv4 报头的布局。

标识符是 IPv4 数据报发送端分配的 16 位值,用于帮助重组数据报的分段。

分段偏移量字段长 13 位,表示分段在原始 IPv4 数据报中所属的位置。

UDP数据协议报学习

UDP数据协议报学习

UDP封装:
IP包 IP头 UDP头 载荷数据
UDP数据报
源端口(Source Port) 长度(Length) 数据(Data) (1)源端口:用于标识数据报的源端进程,字段长度为16比特,最大支持64 k个端口号。源端进程不需要目的端 返回数据报,源端口字段可设为0 (2)目的端口:目的端进程所使用的端口,字段长度为16比特,最大支持64 k个端口号。 (3)长度:16位的长度字段,表明包括UDP头和数据在内的整个UDP数据报的长度。 (4)校验和:16位的错误检查字段,基于部分IP头信息,UDP头和载荷数据的内容计算得到,用于检测传输过程 中出现的错误。 目的端口(Destination Port) 校验和(Checksum) UDP头格式
UDP需要滑动窗口协议吗?
UDP是不可靠的,本身缺乏拥塞控制机制,如果想实现可靠文件传输,需要加 入额外的机制来确保可靠。
优点: 1、实现拥塞控制,避免丢包 2、实现可靠文件传输 缺点:
1、加大系统开销,提高CPU占用率
2、延迟大,由于需要等待确认和超时
面向连接和无连接协议:
面向连接的服务:就是通信双方在通信时,要事先建立一条通信线路,其过程有建立连接
UDP进行路径MTU发现:
本图给出了在目的主机(slip)上所收集到的tcpdump对于第一个到达数 据报的输出结果。 可以看出在slip主机上的收到的包是被bsdi又重新分了片的 第1行是272 第2行是272
第3行是8
第4行是106
滑动窗口协议:
滑动窗口是一种流量控制技术。早期的网络通信中,通信双方不会考虑网络的拥挤 情况直接发送数据。由于大家不知道网络拥塞状况,一起发送数据,导致中间结点阻
以及20字节IP首部,因此,总IP数据报长度是 572字节。

RFC文档阅读 1-100

RFC文档阅读 1-100
RFC974_邮件路由与域名系统
RFC975_自治联邦
RFC976 UUCP 邮件互换格式标准
RFC985 Internet 网关要求 - 起草
RFC988 主机扩展用于IP多点传送
RFC文档阅读 1001-1500
RFC1050_RPC远程步骤呼叫协议说明书
RFC1055_在串行线路上传输IP数据报的非标准协议
RFC1134_+PPP协议:关于在点到点链路上进行多协议包传送的建议
RFC1142 OSI IS-IS 域内路由协议
RFC1144_低速串行链路上的TCPIP头部压缩
RFC1145 SNMPv2的管理模型
RFC1155_基于TCPIP网络的管理结构和标记
RFC1166_Internet数字
RFC1288_Finger用户信息协议
RFC1298_基于IPX协议的SNMP
RFC1321_MD5 信息-摘要算
RFC1332_PPP Internet 协议控制协议 (IPCP)
RFC1333_PPP 链接质量监控
RFC1355_网络中心数据库的保密和准确性问题
RFC1365 一种IP地址扩展提议
RFC1690 Internet工程与计划组(IEPG)介绍
RFC1691 康奈尔大学数字图书馆文档体系结构
RFC1696 用SMIv2定义的调制解调器MIB
RFC1713_DNS调试工具
RFC1715_地址分配效率比率H
RFC1723_路由信息协议(版本2)
RFC1724_RIP 版本 2 管理系统库(MIB) 扩展
RFC1370_OSPF适用范围声明
RFC1387_RIP(版本2)协议分析

MTU参数对运营商网络的影响及配置建议

MTU参数对运营商网络的影响及配置建议

MTU参数对运营商网络的影响及配置建议MTU概念简介最大传输单元(Maximum Transmission Unit,MTU)是指一种通信协议承载上层数据报文的最大数据报大小(以字节为单位)。

最大传输单元这个参数通常与通信物理接口有关(以太接口、串口、ATM、E1/T1等)。

通常来说是指在IP层上能通过的最大报文长度。

IP协议允许IP分片,这样就可以将数据报分成足够小的片段以通过那些最大传输单元小于该数据报原始大小的链路了。

分片技术会降低通信效率,因此很多应用通过将IP报文头的DF“Don’t Fragment”标记位置位,来禁止对报文分片。

如常见的WEB应用。

此时就需要有一种机制来发现整个传输路径的所有接口的最小MTU值。

在IP协议中,一条传输路径的“路径的MTU”被定义为从源地址到目的地址所经过“路径”上的所有IP接口的MTU的最小值。

RFC 1191描述了“路径最大传输单元发现方法”。

在这项技术中,源地址将数据报文的DF“Don't Fragment”标记位置位,路径上任何需要将报文进行分片的设备接口都会将这种数据报丢弃并返回一个“数据报过大”的ICMP响应到源地址,并在这个响应中告知了该接口的MTU值。

这样,源主机就“学习”到了不用进行分片就能通过这条路径的最大传输单元了。

但在现实网络中,有很多种原因使得路径最大传输单元发现方法不能正常工作,常见的环境有:网络中存在NAT设备,导致路径上需要将报文分片的设备无法通知数据源;网络中安全设备基于状态的访问控制,或对ICMP报文抑制;网络中存在隧道,MPLS-VPN等技术,报文在传输过程中增加了额外的封装,超过了接口的MTU。

下面我们来看一看一些MTU带来的问题。

问题1:通过PPPoE over L2TP隧道访问总部WEB服务器部分网页打不开参考如下组网图:分部采用R1路由器和总部R2路由器租用运营商提供的Internet访问链路,通过L2TP建立隧道,分部需要访问总部服务器的客户端通过PPPoE连到R1,并通过L2TP隧道从R2处获得地址。

capwap学习笔记——初识capwap(四)(转)

capwap学习笔记——初识capwap(四)(转)

capwap学习笔记——初识capwap(四)(转)2.5.7 CAPWAP传输机制WTP和AC之间使⽤标准的UDP客户端/服务器模式来建⽴通讯。

CAPWAP协议⽀持UDP和UDP-Lite [RFC3828]。

¢ 在IPv4上,CAPWAP控制和数据通道使⽤UDP。

此时CAPWAP报⽂中的UDP校验和必须设置为0。

AC上的CAPWAP控制报⽂端⼝为UDP众所周知端⼝5246,数据报⽂端⼝为UDP众所周知端⼝5247 ,WTP可以随意选择CAPWAP控制和数据端⼝。

¢ 在IPv6上,CAPWAP控制通道⼀般使⽤UDP,⽽数据通道可以使⽤UDP或者UDP-Lite。

UDP-Lite为默认的数据通道传输协议。

当使⽤UDP-Lite协议的时候,校验和必须为8. UDP-Lite使⽤的端⼝与UDP⼀致。

2.5.8 分⽚、重组、MTU发现CAPWAP协议在应⽤层上提供IP报⽂的分配和重组服务,由于使⽤隧道机制,报⽂分⽚中间的传输媒介来说是透明的。

因此可以在任何⽹络架构(防⽕墙,NAT等)上使⽤CAPWAP协议。

CAPWAP实现的分⽚机制也有局限和不⾜,协议RFC4963中详细描述。

CAPWAP执⾏MTU发现来避免分⽚。

⼀旦WTP发现AC,且想要与这个AC建⽴⼀个CAPWAP会话,它必须执⾏⼀个Path MTU (PMTU)发现。

IPv4的PMTU发现过程在RFC1191中详细描述。

IPv6使⽤RFC4821。

2.5.9 报⽂格式CAPWAP协议可靠机制要求消息必须成对,由请求和响应组成。

所有的请求消息的消息类型值都为奇数,所有的响应消息类型值都为偶数。

如果WTP或者AC接收到了⼀个不认识的消息,消息类型是奇数,那么会将消息类型值加⼀,然后响应给发送者,并且在响应中带有“不认识的消息类型”元素。

如果不认识的消息类型为偶数,那么这个消息将会被忽略。

2.5.9.1 UDP-Lite协议的简单介绍UDP-Lite协议更加适应于⽹络的差错率⽐较⼤,但是应⽤对轻微差错不敏感的情况,例如实时视频的播放等。

RFC目录及对照表

RFC目录及对照表

RFC930_Telnet 终端类型选项 RFC932_子网地址分配方案 RFC937_邮局协议( 版本 2) RFC948_IP 数据包通过 IEEE 802.3 网络传输的两种方法 RFC949_FTP 未公开的独特命令 RFC951_引导协议(BOOTP) RFC955_朝向一个处理过程应用的传输服务 RFC962_TCP-4 的最初 RFC968 “这是开动前的黑暗” RFC974_邮件路由与域名系统 RFC975_自治联邦 RFC976 UUCP 邮件互换格式标准 RFC985 Internet 网关要求 - 起草 RFC988 主机扩展用于 IP 多点传送
中文 RFC 文档阅读 101-700
RFC102 主机-主机 协议故障清除委员会的说明 RFC103 中断键的执行 RFC104 连接 191 RFC105 通过 UCSB 进行远程登录和远程输出返回的网络说明书 RFC106 用户/服务器 站点协议的网络主机问卷 RFC107 主机-主机 协议故障清除委员会的说明 RFC108 1971 年 2 月 17-19 日在 Urbana 举行的 NWG 会议的人员列表 RFC124 在 RFC107 中有印刷错误 RFC132 RFC107 的排版错误 RFC148 RFC123 的注释 RFC149 最好的铺设计划 RFC154 风格显示 RFC156 伊利诺斯州站点的状态: 响应 RFC116 RFC179 连接的数字分配 RFC185 NIC 分发手册 RFC188 数据管理会议公告 RFC198 站点证明-林肯实验室 360/67 RFC204_利用报路 RFC218 改变 IMP 状态报告设备 RFC228 澄清 RFC232 网络图形会议延缓 RFC245 预定网络工作组会议 RFC246 网络图形会议 RFC256 IMPSYS 变更通知 RFC276 NIC 过程 RFC285 网络图形 RFC324 RJE 协议会议 RFC335 新界面 - IMP/360 RFC348_放弃过程 RFC404 文件迁移协议的注释 RFC405 给 TIP 用户的第二封信 RFC456 UCSB 的数据重置服务 RFC457_FTP 的服务器与服务器交互 RFC496 IMP/TIP 内存更新时间表(修订版 2) RFC516 丢失消息的检测 RFC591 在 NVT ASCII UCSB 和在线系统之间的实验输入映象 RFC621 “注意圣诞节的时候要把长袜挂在烟囱下面” RFC628 更深的数据语言的设计观念 RFC634 最近的网络图 RFC637 SU-DSL 网络地址的更改

学习网络常用的RFC文档的名称

学习网络常用的RFC文档的名称

学习网络常用的RFC文档的名称双语RFC --RFC中英文对照版rfc1050中文版-远程过程调用协议规范rfc1055中文版-在串行线路上传输IP数据报的非标准协议rfc1057中文版-RFC:远程过程调用协议说明第二版rfc1058中文版-路由信息协议(Routing Information Protocol)rfc1073中文版-RFC1073 Telnet窗口尺寸选项rfc1075中文版-远距离矢量多播选路协议rfc1088中文版-在NetBIOS网络上传输IP数据报的标准rfc1090中文版-SMTP在X.25上rfc1091中文版-TELNET终端类型选项rfc1094中文版-RFC1094 网络文件系统协议rfc1096中文版-Telnet X显示定位选项rfc1097中文版-Telnet潜意识-信息选项rfc1112中文版-主机扩展用于IP多点传送rfc1113中文版-Internet电子邮件保密增强:Part1-消息编码和鉴别过程rfc1132中文版-802.2分组在IPX网络上传输的标准rfc1144中文版-低速串行链路上的TCP/IP头部压缩rfc1155中文版-基于TCP/IP网络的管理结构和标记rfc1191中文版-RFC1191 路径MTU发现rfc1332中文版-RFC1332 端对端协议网间协议控制协议(IPCP)rfc1333中文版-PPP 链路质量监控rfc1334中文版-PPP 身份验证协议rfc1387中文版-RIP(版本2)协议分析rfc1388中文版-RIP协议版本2rfc1433中文版-直接ARPrfc1445中文版-SNMPv2的管理模型rfc1582中文版-扩展RIP以支持按需链路rfc1618中文版-ISDN上的PPP(点对点)协议rfc1661中文版-RFC1661 PPP协议rfc1723中文版-路由信息协议(版本2)rfc1738中文版-统一资源定位器(URL)rfc1769中文版-简单网络时间协议( SNTP)rfc1771中文版-边界网关协议版本4(BGP-4)rfc1827中文版-IP封装安全载荷(ESP)rfc1883中文版-Internet协议,版本6(IPv6)说明书rfc1939中文版-POP3协议rfc1945中文版-超文本传输协议 -- HTTP/1.0rfc1994中文版-PPP挑战握手认证协议(CHAP)rfc1997中文版-RFC1997 BGP团体属性rfc2002中文版-IP移动性支持rfc204中文版-利用报路rfc2105中文版-Cisco 系统的标签交换体系结构纵览rfc2281中文版-Cisco热备份路由协议()rfc2283中文版-BGP-4的多协议扩展rfc2326中文版-实时流协议(RTSP)rfc2328中文版-OSPF版本2rfc2516中文版-在以太网上传输PPP的方法(PPPoE)rfc2526中文版-IPv6保留的子网任意传送地址rfc2547中文版-BGP/MPLS VPNsrfc2616中文版-超文本传输协议——HTTP/1.1rfc2702中文版-基于MPLS的流量工程要求rfc2706中文版-RFC2706—电子商务域名标准rfc2756中文版-超文本缓存协议(HTCP/0.0)rfc2764中文版-IP VPN的框架体系rfc2773中文版-使用KEA和SKIPJACK加密rfc2774中文版-HTTP扩展框架rfc2781中文版-UTF-16, 一种ISO 10646的编码方式rfc2784中文版-通用路由封装rfc2793中文版-用于文本交谈的RTP负载rfc2796中文版-BGP路由反射rfc2917中文版-核心 MPLSIP VPN 体系结构rfc2918中文版-BGP-4(边界网关协议)的路由刷新功能rfc2923中文版-TCP的路径MTU发现问题rfc3003中文版-Audio/mpeg 媒体类型rfc3005中文版-IETF 讨论列表许可证rfc3007中文版-安全的域名系统动态更新rfc3018中文版-统一内存空间协议规范rfc3022中文版-传统IP网络地址转换(传统NAT)rfc3032中文版-RFC3032 MPLS标记栈编码rfc3033中文版-用于Internet协议的信息域和协议标识符在Q.2941类属标识符和Q.2957 User-to-user信令中的分配rfc3034中文版-标签转换在帧中继网络说明书中的使用rfc3037中文版-RFC3037 标记分配协议的适用范围(RFC3037 LDP Applicability)rfc3058中文版-IDEA加密算法在CMS上的使用rfc3059中文版-服务定位协议的属性列表扩展rfc3061中文版-对象标识符的一种URN姓名空间rfc3062中文版-LDAP口令修改扩展操作rfc3063中文版-MPLS(多协议标签交换)环路预防机制rfc3066中文版-语言鉴定标签rfc3067中文版-事件对象描述和转换格式要求rfc3069中文版-VLAN聚合实现IP地址有效分配rfc3070中文版-基于帧中继的第二层隧道协议rfc3072中文版-结构化数据交换格式rfc3074中文版-DHCP 负载平衡算法rfc3078中文版-RFC3078微软点到点加密(MPPE)协议rfc3081中文版-将区块扩展交换协议(BEEP)核心映射到传输控制协议(TCP)rfc3083中文版-遵循DOCSIS的Cable Modem和CMTS的PBI 的管理信息数据库rfc3085中文版-新闻型标记语言(NewsML)资源的URN名字空间rfc3090中文版-域名系统在区域状况下的安全扩展声明rfc3091中文版-Pi数字生成协议rfc3093中文版-防火墙增强协议rfc3550中文版-RTP:实时应用程序传输协议rfc457中文版-TIPUGrfc697中文版-FTP的CWD命令rfc698中文版-TELNET扩展ASCII选项rfc775中文版-面向目录的 FTP 命令rfc779中文版-TELNET的SEND-LOCATION选项rfc792中文版-RFC792- Internet控制信息协议(ICMP)rfc821中文版-RFC821 简单邮件传输协议(SMTP)rfc826中文版-以太网地址转换协议或转换网络协议地址为48比特以太网地址用于在以太网硬件上传输rfc854中文版-TELNET协议规范rfc855中文版-TELNET选项规范rfc856中文版-RFC856 TELNET二进制传输rfc857中文版-RFC 857 TELNET ECHO选项rfc858中文版-RFC 858 TELNET SUPPRESS GO AHEAD选项rfc859中文版-RFC 859 TELNET的STATUS选项rfc860中文版-RFC 860 TELNET TIMING MARK选项rfc861中文版-RFC 861 TELNET扩展选项-LISTrfc862中文版-RFC 862 Echo 协议rfc868中文版-RFC868 时间协议rfc894中文版-IP 数据包通过以太网网络传输标准rfc903中文版-反向地址转换协议rfc930中文版-Telnet终端类型选项(RFC930——T elnet Terminal Type Option)rfc932中文版-子网地址分配方案rfc937中文版-邮局协议 (版本2)rfc948中文版-IP数据报通过IEEE802.3网络传输的两种方法rfc949中文版-FTP 未公开的独特命令rfc951中文版-引导协议(BOOTP)rfc962中文版-TCP-4 的最初rfc974中文版-邮件路由与域名系统rfc975中文版-自治联邦。

MTU原理及相关问题分析

MTU原理及相关问题分析

MTU原理及相关问题分析一、MTU的定义及相关概念:Mtu即最大传输单元,全称为Maximum Transmission Unit,是指通信协议的某一层上面所能通过的最大数据包大小(以字节为单位)。

由于定义的模糊性,在此也介绍几个相关的名词,MRU、PMTU、MSS和JUMBO FRAME,供大家甄别。

MRU即最大接收单元,全称为Maximum Receive Unit,与MTU相对,称为最大接收单元,目前也没有权威的标准定义,但许多文章中有这个名词。

一台主机或路由器的MTU与MRU可以不一致。

PMTU,全称为 path maximum transmission unit,即路径MTU,把一条IP路径上MTU的最小值称为PMTU,PMTU是个理想化的概念,但目前业界没有有效的手段来实现PMTU的发现和更新。

`MSS是OSI参考模型中四层的一个概念,即最大分段长度,全称为TCP Maximum Segment Size,指TCP每次能够传输的最大数据分段长度(以字节为单位),MSS一般比MTU小40字节。

Jumbo Frame(有些称Giant Frame),网络上会遇到jumbo frame的概念,cisco路由器的接口中也有这个参数,超过以太网标准长度1518字节的帧称为jumbo frame。

二、MTU涉及主要原理:1、常见网络的MTU值:IP网络以包为单位进行信息传递,那么,一次传送多大的包合适、多大的包最高效就成为一个核心问题之一。

MTU就是决定在什么样的物理网络传送多大数据包大的事实标准,不同类型网络由于物理特性、发展阶段不同,其MTU的默认值也不尽相同,以下是摘录的各类网络及其默认MTU值:对于windows操作系统来讲,其以太网网卡MTU默认为1500,但可以通过修改工具或修改注册表进行修改,但只能改小,不能改大,即只能修改为小于或等于1500字节。

2、PMTU 发现过程:对于一个基于网络的应用来讲,如果应用穿过网络的MTU与PMTU相等,那么应用穿过网络的效率最高,或者说,应用通过主机网卡发出的最大数据包与PMTU越接近(指小于等于PMTU),应用穿过网络的效率越高,原因是有效的避免了分片和重组。

完整版MTU参数对运营商网络的影响及配置建议

完整版MTU参数对运营商网络的影响及配置建议

MTU参数对运营商网络的影响及配置建议MTU概念简介最大传输单元(MaximunTransmission Unit , MTU是指一种通信协议承载上层数据报文的最大数据报大小(以字节为单位)。

最大传输单元这个参数通常与通信物理接口有关(以太接口、串口、ATM E1/T1等)。

通常来说是指在IP层上能通过的最大报文长度。

IP协议允许IP分片,这样就可以将数据报分成足够小的片段以通过那些最大传输单元小于该数据报原始大小的链路了。

分片技术会降低通信效率,因此很多应用通过将IP报文头的DF “Don t Fragment”标记位置位,来禁止对报文分片。

如常见的WEB应用。

此时就需要有一种机制来发现整个传输路径的所有接口的最小MTU值。

在IP协议中,一条传输路径的“路径的MTU被定义为从源地址到目的地址所经过“路径”上的所有IP接口的MTU勺最小值。

RFC1191描述了“路径最大传输单元发现方法”。

在这项技术中,源地址将数据报文的DF “Don't Fragment”标记位置位,路径上任何需要将报文进行分片的设备接口都会将这种数据报丢弃并返回一个“数据报过大”的ICMP响应到源地址,并在这个响应中告知了该接口的MTU值。

这样,源主机就“学习”到了不用进行分片就能通过这条路径的最大传输单元了。

但在现实网络中,有很多种原因使得路径最大传输单元发现方法不能正常工作,常见的环境有:网络中存在NAT设备,导致路径上需要将报文分片的设备无法通知数据源;网络中安全设备基于状态的访问控制,或对ICMP报文抑制;网络中存在隧道,MPLS-VP等技术,报文在传输过程中增加了额外的封装,超过了接口的MTU 下面我们来看一看一些MTU带来的问题。

问题1 :通过PPPoE over L2TP 隧道访问总部WEB服务器部分网页打不开参考如下组网图:分部采用R1路由器和总部R2路由器租用运营商提供的In ternet访问链路,通过L2TP建立隧道,分部需要访问总部服务器的客户端通过PPPoE连到R1,并通过L2TP隧道从R2处获得地址。

PMTU发现的探讨

PMTU发现的探讨

PMTU发现的探讨作者:姚利增来源:《沿海企业与科技》2008年第07期[摘要]文章介绍PMTU以及在复杂网络环境面临的问题,并且探讨PMTU 自动探测和隧道MTU发现机制。

[关键词]MTU;隧道MTU;PMTU[作者简介]姚利增,唐山学院计算机科学与技术系,研究方向:计算机网络安全,河北唐山,063000[中图分类号] TP393 [文献标识码] A [文章编号] 1007-7723(2008)07-0036-0002一、PMTU以及复杂网络环境面临的问题在因特网上,两个主机之间的通信要经过多个网络,而每个不同的网络在IP 层可能有不同的MTU(最大传输单元)。

两台通信主机路径中的最小MTU 被称作路径MTU 即PMTU。

路径MTU 发现机制通过在IP 首部中继承并设置“不要分片(DF)”比特,来发现当前路径的路由器是否需要对正在发送的IP 数据报进行分片。

如果一个待转发的IP 数据报被设置DF 比特,而其长度又超过了MTU ,那么路由器就会丢弃这个报文,并返回一个ICMP 不可达的差错报文(类型为3 ,代码为4 :需要进行分片但设置了不分片比特),其中填有下一跳正确的MTU。

如果发送端主机接收到这个ICMP 差错控制报文,它就可以用正确的MTU 重新传送这个报文,并在以后的传输中沿用这个MTU 大小。

路径MTU 发现机制的出现大大减少了网路上IP 分片的可能性。

它在简单环境下是能够正常运行的,但在复杂网络环境下会有问题。

在实际复杂的网络环境中,一些网关设备(如防火墙、路由器等)会为了避免拒绝服务攻击或者其他原因而将这个ICMP 差错报文无条件地丢弃掉。

源主机会一直以原来的那个MTU 大小发送IP 数据报并设置DF 位,这些数据报就会像前面的数据报一样被路由器丢弃掉,不能到达目的地。

另外,在实际的网络环境中存在诸如VPN 一类的设备,它们由于加密的需要对报文进行了封装。

这样,报文的长度就增加了,报文有可能因为太大被下一站的路由器丢弃掉。

ping代码

ping代码

大部分人用ping命令只是作为查看另一个系统的网络连接是否正常的一种简单方法。

在这篇文章中,整理将介绍如何用C语言编写一个模拟ping命令功能的程序。

ping命令是用来查看网络上另一个主机系统的网络连接是否正常的一个工具。

ping命令的工作原理是:向网络上的另一个主机系统发送ICMP报文,如果指定系统得到了报文,它将把报文一模一样地传回给发送者,这有点象潜水艇声纳系统中使用的发声装置。

例如,在Linux终端上执行ping localhost命令将会看到以下结果:PING localhost.localdomain (127.0.0.1) from 127.0.0.1 : 56(84) bytes of data.64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=0 ttl=255 time=112 usec64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=255 time=79 usec64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=2 ttl=255 time=78 usec64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=3 ttl=255 time=82 usec--- localhost.localdomain ping statistics ---4 packets transmitted, 4 packets received, 0% packet lossround-trip min/avg/max/mdev = 0.078/0.087/0.112/0.018 ms由上面的执行结果可以看到,ping命令执行后显示出被测试系统主机名和相应IP位置、返回给当前主机的ICMP报文顺序号、ttl生存时间和往返时间rtt(单位是毫秒,即千分之一秒)。

路径最大传输单元 (PMTU) 黑洞路由器

路径最大传输单元 (PMTU) 黑洞路由器

在 TCP 三次握手期间交换的 TCP 数据段不会太大,因而不会被 PMTU 黑洞路由器丢弃。但是,一旦开始在连接上传输数据—假定基于协商的 MSS 确定的 PMTU 比实际 PMTU 大—TCP 数据段的大于实际 PMTU 的 IP 包就会被直接丢弃。
例如,您可以用 FTP 命令行工具成功地与 FTP 服务器建立连接并登录。但是,当您试图下载或者上载文件时,中间的 PMTU 黑洞路由器就会丢弃达到最大大小的 TCP 数据段,从而导致错误和文件传输失败。
? 直接丢弃包。
直接丢弃需分段但 DF 标记设置为 1 的包的路由器称为 PMTU 黑洞路由器。
返回页首
检测 PMTU 黑洞路由器
PMTU 黑洞路由器会给 TCP 连接带来问题。例如,Microsoft? Windows? XP 和 Windows Server?2003 中的 TCP/IP 协议默认情况下会使用 PMTU 发现。TCP 会发送 DF 标记设置为 1 的数据段,并且在需要时,会根据符合 RFC 1191 定义的“ICMP Destination Unreachable-Fragmentation Needed and DF Set”消息的回执(其中包含 IP MTU),更改 TCP MSS 值。
7.
右键单击树视图中的“GUID”键,指向“新建”,然后单击“双字节值”。
8.
在注册表编辑器工具的内容窗格(右窗格)中,为新注册表设置的值键入 MTU,然后按 ENTER。
9.
在内容窗格中,双击新的 MTU 设置,并在“编辑双字节值”对话框中选择“十进制”,然后在“数值数据”中键入有效 MTU 值。
要找出包含 PMTU 黑洞路由器的路径的有效 IP MTU,请使用 Ping 工具,同时不断增大 Echo 消息的有效负载的大小。因为典型子网的最小 IP MTU 是 576 字节,因此开始时可将 ICMP Echo 消息的有效负载设置为 548 字节,然后每次递增 100 字节,直到找到有效 PMTU。

MTU基本概念

MTU基本概念

源MAC 6字节
目的MAC 6字节
VLAN TAG 4字节 长度/类型 2字节
净荷 46~1500字节
CRC 4字节
HUAWEI TECHNOLOGIES CO., LTD.
Huawei Confidential
22
不过,早在千兆以太网时代,有些厂商提出了“巨 型帧”的概念,大胆地把以太帧最大长度扩到了 9K。这样做的好处是,减少了网络中以太帧个数, 帧数目的大量减少必将带来性能的提高,引起了各 个厂商的兴趣。
Huawei Confidential
2
但是,如果规划不当,它会引发网络问题,例如: 部分网站打不开 能打开网页但看不到图片
Email无法发送附件 网速慢 游戏卡 ……
HUAWEI TECHNOLOGIES CO., LTD.
Huawei Confidential
3
它是谁?
HUAWEI TECHNOLOGIES CO., LTD.
帧 头
IP头 20
1480
帧 尾
IP头 20
IP头 20
880
400 200
帧 尾 帧 尾
3
2
帧 头
IP头 20
帧 尾
HUAWEI TECHNOLOGIES CO., LTD.
Huawei Confidential
10
Q:分片会降低传输效率,能否不分片?
可以。如果源端发送的IP包不大于路径上最小的MTU, 整个过程不会被分片,这是最理想的。于是,这个最 小MTU引起人们的重视,并获得了一个学名——PMTU (Path MTU)。
关于PMTU发现详细信息,请参见 RFC1191。
HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential 14

MTU

MTU

MTU当信息在网络线路上传送时,往往会被自动分割成尺寸不同的数据封包,而MTU值参数就是用来指定数据封包大小的标准。

当MTU值跟ISP的设备参数不匹配时,有可能会出现连接失败的问题。

某些使用PPPoE方式拨号上网的设备的MTU值为1492,而通过局域网路由器获取IP地址的方式上网的MTU值通常为1500。

MTU设置MTU,即Maximum Transmission Unit(最大传输单元),此值设定TCP/IP协议传输数据报时的最大传输单元。

设置合适的MTU值可以解决“部分网站打不开”、“上网速度慢”等问题,并且可以适当提升上网速度。

设置多大的MTU值取决于你的上网方式,不同的上网方式支持不同的MTU,下面列出了一些上网方式的MTU值:EtherNet(一般上网方式,默认值):1500PPPoE/ADSL:1492Dial Up/Modem:576问题一:知道了我的上网方式,如何设置MTU值?1. 在『开始』>『运行』中,键入regedit,点确定;2. 选择『HKEY_Local_Machine』>『SYSTEM』>『CurrentControlSet』>『Services』>『Tcpip』>『Parameters』>『interface』;3. 在interface 底下可能有很多的选项,你一个一个的去看,会有一个选项与你的网卡的IP 相同,那个就是你要挑选的选项啦!然后同样的在该选项上选择『编辑』>『新建』>『DWORD值』之后,建立一个名为『MTU』的DWORD,然后双击修改,选择十进制,填入合适MTU 值,确定!大功告成!问题二:我不知道自己的上网方式,如何确定MTU值呢?ping -f -l 1500 127.0.0.1C:\WINDOWS>ping -f -l 1500 127.0.0.1Pinging 127.0.0.1 with 1500 bytes of data:Packet needs to be fragmented but DF set.Packet needs to be fragmented but DF set.Packet needs to be fragmented but DF set.Packet needs to be fragmented but DF set.Ping statistics for 127.0.0.1:Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), Approximate round trip times in milli-seconds:Minimum = 0ms, Maximum = 0ms, Average = 0ms上面的式子中,-l 是L 的小写(不是 1 喔),1500 是我们要测的MTU 值,结果出现了Packet needs to be fragmented but DF set. 这个东西,那表示MTU值太大了,你需要更小的MTU 值才行!好啦!那假设我们使用1464 来测试时:C:\WINDOWS>ping -f -l 1464 127.0.0.1Pinging 127.0.0.1 with 1464 bytes of data:Reply from 127.0.0.1: bytes=1464 time=10ms TTL=128Reply from 127.0.0.1: bytes=1464 time<10ms TTL=128Reply from 127.0.0.1: bytes=1464 time<10ms TTL=128Reply from 127.0.0.1: bytes=1464 time<10ms TTL=128Ping statistics for 127.0.0.1:Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds:Minimum = 0ms, Maximum = 10ms, Average = 2ms结果出现了回应了!这表示这一个MTU 值是可行的!不过,强烈建议找出可行的最大MTU 值!这样一来,在设定的时候,才可以达到最佳的网速!找出MTU 值:利用上面这个方法找到的数值还不是MTU 喔!由于一些封包上面的问题,上面这个值再加上28 才是我们所需要的MTU 值!所以,在上面的例子中,我们所需要的MTU 值是1464+28=1492!一般来讲,设计好本机的MTU值,可以解决部分网站打不开的情况,但是如果你的共享主机或路由器的MTU设置有问题,有时问题仍然存或,或者出现网速过慢的情况。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

实际上,很多TCP实现总是发送MSS选项, 但是,如果目的地不是本地的,把值设置为536。当因特网中充满了不遵守超过576字节的数据报不发给非本地的目的地址规则的主机的时候,这种行为是正确的。现在大多数主机遵守这个规则,所以对非本地的对等者来说也不必把TCP MSS选项的值限制为536。
7. 路径MTU的可能值 11
7.1 一种较好的检测PMTU增长的方法 12
8. 安全性的考虑 13
参考书目: 13
作者地址: 14
1. 简介
当一台IP主机有大量的数据要发送给另一台主机的时候,数据是作为一系列的IP数据报传输。数据报最好具有在从源点到目的点的路径上不需要分片的最大尺寸。(避免分片的情况,见[5]。)这种数据报的尺寸称作为路径MTU(PMTU),它等于路径上每一跳的MTU之中的最小值。当前因特网协议族的缺点就是对一台主机来说缺乏发现任意一条路径的PMTU的标准机制。
使用PMTU发现的主机一定要尽可能快地检测到路径MTU的减少。主机可以检测到路径MTU的增加,但是,因为这样做需要发送比当前估计的PMTU大的数据报, 而且PMTU很可能不增加,所以这种工作一定不要频繁地做。检测一个增加的尝试(通过发送一个比当前估计值大的数据报)一定不要在数据报太大报文收到后5分钟内做,或者在前一个成功的增加尝试之后1分钟内做。我们建议把计时器设置为它们最小值的两倍(分别为10分钟和2分钟)。
而且,这样做防止发现超过576的PMTU,所以,主机应该不再减少它们在MSS选项中发送的值。MSS选项应该比主机能够重组的最大数据报(MSS_R,在[1]中定义)的尺寸小40字节; 在许多情况下,这将有65495 (65535 - 40)字节结构上的限制。主机可能发送从它连接网络上的MTU(对一个多宿主主机来说,是在它所有连接网络中的最大MTU)得到的MSS值;这应该不会对PMTU发现造成问题,可以阻止一个损坏的对等者发送巨大的数据报。
期望未来的路由协议将能够在一个路径区域中提供准确的PMTU信息,尽管也许不能越过多级路由层次。还要多久这种未来的路由协议才能广泛应用现在还不清楚。所以在以后的几年中,因特网在所有主机和路由器被修改前为了不浪费资源需要一种简单的发现PMTU的机制。
2. 协议概览
在此备忘录中,我们描述了一种技术,在IP首部使用不分片(DF)比特位动态发现一条路径的PMTU。基本思想就是源主机开始假定一条路径的PMTU是它的(已知的)第一跳的MTU,在这条路径上发送的数据报都设置DF比特位。如果有的数据报太大,不被路径中的某些路由器分片就不能转发,那么路由器将丢弃这些数据报,然后返回一个意思为“需要分片,设置了DF位 [7]”的ICMP目的不可达报文。在收到这样一条报文后(以后称它为“数据报太大”报文),源主机减小它假定的这条路径的PMTU。
| 类型 = 3 | 代码 = 4 | 校验和 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
注意:这时,我们没有看到发送比连接的网络最大的MTU还要大的MSS的原因。我们建议主机不使用65495。因为一些IP实现可能有负比特位的错误,这种错误在在没有必要使用这么大的MSS的时候被触发。
4. 路由器规范
路由器不能转发数据报,是因为数据报超过了下一跳网络的MTU并且它的不分段比特位被设置, 路由器需要给数据报的源地址返回一个ICMP的目的不可达报文,此报文带有表示“需要分段,设置了DF位”的代码。为了支持在此备忘录中说明的路径MTU发现技术,路由器必须在ICMP首部字段中低序的16bit中包含下一跳网络的MTU,这个字段在ICMP规范[7]中被标记为“未使用”。高序的16bit保持未用,必须设置为0。因此,报文具有下面的格式:
2. 协议概览 2
3, 主机规范 3
3.1 TCP MSS选项 4
4. 路由器规范 5
5. 主机对老式报文的处理 5
6. 主机实现 6
6.1 分层 7
6.2 存储PMTU信息 7
6.3 清除过时的PMTU信息 8
6.4 TCP层的行为 9
6.5 其它传输协议的问题 10
6.6 管理接口 11
不幸的是,当前指定的数据报太大报文不报告拒绝太大数据报的那一跳的MTU。所以源主机不能准确地判定把它假设的PMTU减小多少。为了弥补这个缺点,我们建议使用当前在数据报太大报文中没有使用的一个报头字段来报告减小的那一跳的MTU。这是支持PMTU发现的路由器唯一被指定的改变。
路径的PMTU可能随着时间而改变,因为路由的拓扑结构可能改变。PMTU的减小通过数据报太大报文被检测到,除非主机停止设置沿此路径的数据报的DF比特位。为了检测路径的PMTU值的增加,主机周期地增加它假定的PMTU(如果它已经停止,再重新设置DF比特位)。这几乎总是导致数据报被丢弃,数据报太大报文产生,因为在大多数情况下,路径的PMTU不会改变,所以不应该频繁地做这种工作。
"Requirements for Internet Hosts -- Communication Layers" [1]的 4.2.2.6节中陈述了:
一些TCP实现只有当目的主机在一个非直接连接网络上才发送MSS选项。但是,通常TCP层不可能有适当地信息来作出这种决定,所有它更愿意把决定因特网路径合适的MTU的工作留给IP层来完成。
当主机对PMTU的估计值小到它的数据报不需要分片也能转发的时候,PMTU发现过程结束。或者,主机可以选择停止在数据报首部中设置DF比特位来结束发现过程;它可能会这样做,例如主机想在某些情况下让数据报分片。通常,主机继续在所有的数据报中设置DF,这是为了如果路由改变并且新的PMTU减小的时候,将会被发现。
注意:路径MTU在[1]中被称作为“用于发送的有效MTU" (EMTU_S).
PMTU与一条路径相关,路径是IP的源地址、目的地址,也许还有
服务类型(TOS)的特定组合。
当前实际[1]采用的是576和第一跳MTU中的较小者作为任何不与源地址网络或者子网直接相连的目的地址的PMTU。在许多情况下,这导致了使用比必须要求小的数据报,因为许多路径的PMTU比576大。一台主机发送比路径MTU小的多的数据报是浪费因特网的资源,达不到最优的吞吐量。而且,当前的实现在所有的情况下不防止分片,因为一些路径的MTU比576小。
主机一定不要使对路径MTU的估计值低于68字节。
主机一定不能增加它对路径MTU的估计值来响应数据报太大报文的内容。一个通告路径MTU增加的报文可能是一个在因特网中飘移的过时的数据报,一个作为服务拒绝攻击一部分的虚假的数据报,或者是由于到目的地址有多条路径造成的结果。
3.1 TCP MSS选项
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Obsoletes: RFC 1063 S. Deering
Stanford University
November 1990
RFC1191 路径MTU发现
(RFC1191 Path MTU Discovery)
本备忘录状态
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
组织:中国互动出版网(/)
RFC文档中文翻译计划(/compters/emook/aboutemook.htm)
E-mail:ouyang@
译者:马东辉(eaststone ma_donghui@)
作PMTU发现的主机一定要遵守不发送大于576字节的IP数据报的规则,除非它具有接收者的许可。对于TCP连接来说,这意味着主机一定不能发送大于40字节加上它的对等者发来的最大段尺寸(MSS)的数据报。
注意:TCP MSS 被定义为相关的IP数据报尺寸减40[9]。最大IP数据报尺寸的默认值576将导致TCP MSS的默认值是536字节。
因为这种机制本质上保证了主机接收不到来自另机进行互操作有帮助。
3, 主机规范
当主机收到一个数据报太大报文时,它必须基于此报文中的下一跳MTU字段中的值(见第四节),减少对相关路径的PMTU估计值。因为不同的应用程序有不同的需要,不同的实现体系倾向于不同的策略,所以我们不能在这种情况下指定确定的行为。
致谢
这个建议是IETF MTU发现工作组的产品。
这种被建议的机制首先由Geof Cooper [2]提出,他在两个简短的段落中陈述了所有基本的思想,IETF MTU发现工作组用了几个月的时间重新修订。
目录
1. 简介 2
memo is unlimited.
摘要
此备忘录描述了一种动态发现因特网上任意一条路径的最大传输单元(MTU)的技术。它对这条路径上的路由器产生的一种ICMP消息作了很小的修改。在路径上的路由器如果没有作出这样的改变,这种技术将不能发现正确的路径MTU,但是这种技术选择出来的路径MTU将和当前使用的其它方法选择出来的MTU同样准确,而且在许多情况下更加精确。
相关文档
最新文档