最新文章专题视频专题问答1问答10问答100问答1000问答2000关键字专题1关键字专题50关键字专题500关键字专题1500TAG最新视频文章推荐1 推荐3 推荐5 推荐7 推荐9 推荐11 推荐13 推荐15 推荐17 推荐19 推荐21 推荐23 推荐25 推荐27 推荐29 推荐31 推荐33 推荐35 推荐37视频文章20视频文章30视频文章40视频文章50视频文章60 视频文章70视频文章80视频文章90视频文章100视频文章120视频文章140 视频2关键字专题关键字专题tag2tag3文章专题文章专题2文章索引1文章索引2文章索引3文章索引4文章索引5123456789101112131415文章专题3
当前位置: 首页 - 正文

TCPIP协议详解卷1学习笔记-IP校验和与ICMP协议

来源:动视网 责编:小OO 时间:2025-09-29 02:33:30
文档

TCPIP协议详解卷1学习笔记-IP校验和与ICMP协议

TCP/IP协议详解卷1学习笔记-IP校验和与ICMP协议IP数据报的检验和:为了计算一份数据报的IP检验和,首先把检验和字段置为0。然后,对首部中每个16bit进行二进制反码求和(整个首部看成是由一串16bit的字组成),结果存在检验和字段中。当收到一份IP数据报后,同样对首部中每个16bit进行二进制反码的求和。由于接收方在计算过程中包含了发送方存在首部中的检验和,因此,如果首部在传输过程中没有发生任何差错,那么接收方计算的结果应该为全1。这个是原文。看一些网络程序的源码时,发现几乎都是用
推荐度:
导读TCP/IP协议详解卷1学习笔记-IP校验和与ICMP协议IP数据报的检验和:为了计算一份数据报的IP检验和,首先把检验和字段置为0。然后,对首部中每个16bit进行二进制反码求和(整个首部看成是由一串16bit的字组成),结果存在检验和字段中。当收到一份IP数据报后,同样对首部中每个16bit进行二进制反码的求和。由于接收方在计算过程中包含了发送方存在首部中的检验和,因此,如果首部在传输过程中没有发生任何差错,那么接收方计算的结果应该为全1。这个是原文。看一些网络程序的源码时,发现几乎都是用
TCP/IP协议详解卷1学习笔记-IP校验和与ICMP协议

IP数据报的检验和: 

  为了计算一份数据报的I P检验和,首先把检验和字段置为0。然后,对首部中每个16 bit

进行二进制反码求和(整个首部看成是由一串16 bit的字组成),结果存在检验和字段中。当

收到一份I P数据报后,同样对首部中每个16 bit进行二进制反码的求和。由于接收方在计算过

程中包含了发送方存在首部中的检验和,因此,如果首部在传输过程中没有发生任何差错,

那么接收方计算的结果应该为全1。

  这个是原文。看一些网络程序的源码时,发现几乎都是用同一种程序来计算检验和的: 

USHORT checksum(USHORT *buffer, int size) { 

unsigned long cksum=0; 

while(size >1) {

cksum+=*buffer++;

size -=sizeof(USHORT);

}

if(size ) {

cksum += *(UCHAR*)buffer;

cksum = (cksum >> 16) + (cksum & 0xffff);

cksum += (cksum >>16);

return (USHORT)(~cksum);

}

摘自 ping 源码。

  大家都用的东西看来是不会错的了,不过还是要按协议说的方法用笨办法试试看。

  今天看的是ICMP协议,基本格式:

|-------- IP 数据报 ------------+

+--20 bytes --+----------------+

+  IP首部      + ICMP 报文      +

+------------------------------+

  ICMP报文还是通过IP报文发送出去的。

  ICMP的格式:

+----8---+----8---+-------- --------+

+ 8位类型 + 8位代码 +    16位检验和    +

+-----------------------------------+

+ 不同类型有不同的内容和长度            +

+-----------------------------------+

  ICMP的报文类型有很多种,而每种类型里又有多种代码。

  报文分查询报文和差错报文。差错报文不会嵌套产生。差错报文中包含导致差错的IP首部和数据部分的前8个字节,并据此与具体的协议和进程联系起来。因为TCP和UDP的前8个字节中包含有源端口和目的端口,可以据此查找到与此联系的用户进程。大部分的实现中只返回8个字节,有系统返回的是前个字节。如果是UDP报文产生差错,而又没有预先通过 connect与指定端口联系起来,用户进程将收不到这个差错报文。内核在处理后将丢弃。

  讨论了部分tftp实现中的的简单的差错重传机制,等待5秒重传,已被RFC禁用。我在串口通讯中用的还是这种简单的重传方式,看来要改了。

  详细讨论了时间截请求与回复的过程,以及地址掩码请求与回应数据包的格式。对端口不可达错误,差错报文为:

+----------------- 端口不可达的ICMP差错报文 -------------------------------+

+ 以太网首部  +       IP首部    + ICMP首部 +  产生差错的IP首部  + IP报数据域  +

+- 14 bytes  +--- 20 bytes ---+ 8 bytes +---- 20 bytes ----+-- 8 bytes -+

  根据标准,列出5种情况下,不会产生差错报文,基本上都是为了避免出现ICMP广播风暴的。

  这个协议因为类型与具体的细节太多,比较的费事,不过也比较简单。如果不做协议的分析,倒不需要对每个类型都搞得十分清楚。好像这个并没有多少利用的空间。不过如果在一个主机试图发起连接时,发送一个伪装的ICMP包告诉它“端口不可达”,结果会怎么样?值得试试。

第2卷 第13章 HTTP协议

  这一章对HTTP的请求与响应格式做了简单的介绍。由于所有传送的内容基于ASCII,虽然也会传送其他二进制,如图片,MIME文件,但是其本是还是可以从请求或响应头中看出传送的类型,分析起来就没什么难度了。这些可以用 telnet 或者 nc做一个真实的会话过程。把后面一章(第2卷第14章 HTTP服务器的分组)看完,准备自已动手做一个小的Web服务器。公司下一步的计划是把大部分的硬件都做成可直接由浏览器操作的。而这些必须要由一个 web服务器来驱动。我是作软件的,本来不需要我去关心这个。不过自己动手作一下,实践一下总不是坏事,而且可以跟他们交流一下。

  看了许多有关web服务器的漏洞导致的严重后果,这个得从一开始就要注意。

文档

TCPIP协议详解卷1学习笔记-IP校验和与ICMP协议

TCP/IP协议详解卷1学习笔记-IP校验和与ICMP协议IP数据报的检验和:为了计算一份数据报的IP检验和,首先把检验和字段置为0。然后,对首部中每个16bit进行二进制反码求和(整个首部看成是由一串16bit的字组成),结果存在检验和字段中。当收到一份IP数据报后,同样对首部中每个16bit进行二进制反码的求和。由于接收方在计算过程中包含了发送方存在首部中的检验和,因此,如果首部在传输过程中没有发生任何差错,那么接收方计算的结果应该为全1。这个是原文。看一些网络程序的源码时,发现几乎都是用
推荐度:
  • 热门焦点

最新推荐

猜你喜欢

热门推荐

专题
Top