`

TCP/IP_UDP归纳

阅读更多
参考TCP/IP三卷
第11章  UDP:用户数据报协议
在这章中,提到了UDP,分片,和UDP服务器的特征。

文章第一句话就指出,IP数据报分片,并不是发送端主机连接第一个网络才这么做,而是在源端到目的端之间

每个网络都可能产生分片。
最显著一个特征,不提供可靠性。

UDP首部字段:
16位UDP长度:这个长度指的是全长减去IP首部的长度。即,UDP首部和UDP数据的字节长度

UDP检验和:
看看IP首部检验方法:只覆盖了IP首部,不涉及到数据。
UDP和TCP都有覆盖他们的首部和数据, 同时,UDP的检验和是可选的,TCP是必须的。RFC标准中,UDP检验默认

是开启的。要想知道UDP是否打开检验和,检查UDP首部的UDP检验和即可。
检验时是16bit进行相加,所以对可能出现奇字节的UDP,经常用一个全0的字段填充,这个全0的字段是否会被

发送,要靠具体情况而定。

UDP和TCP段都包含一个12字节长的伪首部,为了计算检验而设置,不做为包发送, 伪首部包含IP首部一些字段

,其目的让UDP进行两次检验。。  其实可以发现ARP中也包含了一些重复性的数据。我对这个看法认为,各层

之间是透明的,除了一些检验外,不涉及到其他数据交换等。所以有这种现象是正常的。


IP分片:
  为什么要IP分片。略
  在分片时,除了第一片有运输层的首部,其他都只有IP层的首部
  几个主要特征位:
  一个唯一的标志值
  是否允许分片()
  是否还有其他分片
  偏移量
 
ICMP不可达差别(需要分片)
  基本MTU都在1500字节左右
  当路由器收到一份需要分片的数据报,而在IP首部又设了不可分片标志.在该报文中设置了下一站网络的MTU

最大UDP数据报长度
  理论上,IP数据报最大长度为65535字节。去除20字节IP首部和8个字节的UDP首部,理论为65507,但是大多

数实现所提供的长度比这个最大值小

UDP路径MTU发现



UDP和ARP之间交互作用
   这里作者举了一个很有意思的例子:发送一个8192字节UDP,产生6个数据报片,ARP缓存似乎空的。
用tcpdump查看结果是,在第一个arp返回前,总共产生6个ARP请求。认为原因是,IP很快产生6个数据报片,而

每个数据报片都引发一个ARP请求。
   在接收到第一个ARP应答时,只发送最后一个数据报片,似乎将前5个数据报片全都丢弃了。那么可以得出,

ARP操作的规律,在等待一个ARP应答时,只将最后一个报文发给特定的目的主机(FIFO)。(RFC里规定,ARP应该

至少保留一个报文.)
   在这里就有个问题,如果IP分片越多,发送的ARP就越多。建议最高速率是每秒一次。
   在监视时大家会发现没产生ICMP错误,这里有两个原因:
   1.大多数从Berkeley派生的实现从不产生错误.这些实现会设置定时器.比如在以上例子中,在第一个数据报

片出现时,IP层必须启动一个定时器.正常值为30秒或60秒,如果超时,或所有数据报片未能全部到达,那么将丢弃
   2.并未接收到第一个数报片(包含传输层首部),ICMP就无法区分出是哪个进程所发送的数据报被丢弃.

  UDP输入队列
  一台服务器,先休眠30秒.2台客户机,同时向它各发送3个数据报,在12秒内完成.结果S只收到两台C的第一份数

据报.其他四份丢弃.从这里可以看出,不存在像ICMP的报错信息,UDP输出队列遵循FIFO的.而在ARP里却是LIFO.


限制本地IP地址

大多UDP服务器在创建UDP端点都使用直接监听方式.如 *.*  ports
就表明进入的UDP数据报如果其目的为服务器端口,那么(可能有多个地址)本接口均可接收到它.

可以手动指定IP地址
变成
XXX.XXX.XXX.XXX ports
0
1
分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics