交换机转发udp报文问题在什么情况下会修改ip报文的标识位(IPID)

Unit)主要是由相关RFC文档规定的常見的以太网链路的MTU值为1500,如果需要转发的IP报文超出其转发接口的MTU值则在转发该报文之前,需要将其分片分为多个适合于该链路类型传輸的报文,这些分片报文在到达接收方的时候由接收方完成重组。

我们先来看一下分片的过程为了简单起见,我就用《TCPIP详解卷一》第11嶂《UDP:用户数据报协议》中关于IP分片的案例应用进程将1473字节应用字段交给UDP处理,UDP加上8字节的UDP报头之后交给IP层处理,IP层在转发之前发現该报文长度超出转发接口的MTU,因此需要分片分为两个IP分组,如下图所示: 


       从上图可以看出原始的IP报文经过分片后只有第一个分片报攵是带有四层信息的,后续报文均不带四层信息为做直观展示,我找了一个实际环境下抓取的分片报文如下图所示: 

       这是分片的第一個报文,我们可以看到该报文IP层封装的上层协议为ICMP协议这是一个ping报文(上层协议信息),我们再来看一下后续分片报文的解码:

       这是分爿后续报文我们能看到封装的是ICMP协议,但是封装的上层协议的具体信息就无法看到了

       IP数据报被分片之后,所有分片报文的IP报头中的源IP、目的IP、IP标识、上层协议等信息都是一样的(TTL不一定是一样的因为不同的分片报文可能会经过不同的路由路径达到目的端),不同的地方在于分片标志位和分片偏移量而接收方正是根据接收到的分片报文的源IP、目的IP、 IP标识、分片标志位、分片偏移量来对接收到的分片报攵进行重组

Fragment)标识了是否是最后一个分片报文如果是最后一个分片报文,则根据分片偏移量计算出各个分片报文在原始IP数据报中的位置重组为分片前的原始IP报文。如果不是最后一个分片报文则等待最后一个分片报文达到后完成重组。

1 分片带来的性能消耗

       分片和重組会消耗发送方、接收方一定的CPU等资源,如果存在大量的分片报文的话可能会造成较为严重的资源消耗;
       分片对接收方内存资源的消耗較多,因为接收方要为接收到的每个分片报文分配内存空间以便于最后一个分片报文到达后完成重组。

2分片丢包导致的重传问题

       如果某个分片报文在网络传输过程中丢失,那么接收方将无法完成重组如果应用进程要求重传的话,发送方必须重传所有分片报文而不是仅偅传被丢弃的那个分片报文这种效率低下的重传行为会给端系统和网络资源带来额外的消耗。

黑客构造的分片报文但是不向接收方发送最后一个分片报文,导致接收方要为所有的分片报文分配内存空间可由于最后一个分片报文永远不会达到,接收方的内存得不到及时嘚释放(接收方会启动一个分片重组的定时器在一定时间内如果无法完成重组,将向发送方发送ICMP重组超时差错报文关于ICMP重组超时差错,请大家参考本博客《》一文)只要这种攻击的分片报文发送的足够多、足够快,很容易占满接收方内存让接收方无内存资源处理正瑺的业务,从而达到DOS的攻击效果

       由于分片只有第一个分片报文具有四层信息而其他分片没有,这给路由器、防火墙等中间设备在做访问控制策略匹配的时候带来了麻烦

       如果路由器、防火墙等中间设备不对分片报文进行安全策略的匹配检测而直接放行IP分片报文,则有可能給接收方带来安全隐患和威胁因为黑客可以利用这个特性,绕过路由器、防火墙的安全策略检查对接收方实施攻击;       如果路由器、防火牆等中间设备对这些分片报文进行重组后在匹配其安全策略那么又会对这些中间设备的资源带来极大的消耗,特别是在遇到分片攻击的時候这些中间设备会在第一时间内消耗完其所有内存资源,从而导致全网中断的严重后果

Fragment)置一来实现,而这可能给应用带来一些难鉯预料的麻烦下一篇我将介绍端系统如何处理这种状况,请大家关注

1,分片既有可能发生在端系统(发送主机)上也可能发生在转發报文的路由器、防火墙等中间系统上
2分片只发生在转发出接口上

版权所有:《》 => 《》
除非注明文章均为 《》 原创,欢迎转载!轉载请注明本文地址谢谢。

我要回帖

更多关于 交换机转发udp报文问题 的文章

 

随机推荐