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);
　　}
　　
　　ICMP协议，基本格式：
　　|——– IP 数据报 ————+
　　+–20 bytes –+—————-+
　　+　IP首部　　　+ ICMP 报文　　　+
　　+——————————+
　　
　　ICMP报文还是通过IP报文发送出去的。
　　
　　ICMP的格式：
　　
　　+—-8—+—-8—+——– ——–+
　　+ 8位类型 + 8位代码 +　　16位检验和　　+
　　+———————————–+
　　+ 不同类型有不同的内容和长度　　　　　　+
　　+———————————–+
　　
　　ICMP的报文类型有很多种，而每种类型里又有多种代码。
　　
　　报文分查询报文和差错报文。差错报文不会嵌套产生。差错报文中包含导致差错的IP首部和数据部分的前8个字节，并据此与具体的协议和进程联系起来。因为TCP和UDP的前8个字节中包含有源端口和目的端口，可以据此查找到与此联系的用户进程。大部分的实现中只返回8个字节，有系统返回的是前64个字节。如果是UDP报文产生差错，而又没有预先通过 connect与指定端口联系起来，用户进程将收不到这个差错报文。内核在处理后将丢弃。
　　
　　讨论了部分tftp实现中的的简单的差错重传机制，等待5秒重传，已被RFC禁用。我在串口通讯中用的还是这种简单的重传方式，看来要改了。
　　
　　详细讨论了时间截请求与回复的过程，以及地址掩码请求与回应数据包的格式。对端口不可达错误，差错报文为：
　　
　　+—————– 端口不可达的ICMP差错报文 ——————————-+
　　+ 以太网首部　+　　　 IP首部　　+ ICMP首部 +　产生差错的IP首部　+ IP报数据域　+
　　+- 14 bytes　+— 20 bytes —+ 8 bytes +—- 20 bytes —-+– 8 bytes -+
　　
　　根据标准，列出5种情况下，不会产生差错报文，基本上都是为了避免出现ICMP广播风暴的。
　　
　　这个协议因为类型与具体的细节太多，比较的费事，不过也比较简单。如果不做协议的分析，倒不需要对每个类型都搞得十分清楚。好像这个并没有多少利用的空间。不过如果在一个主机试图发起连接时，发送一个伪装的ICMP包告诉它“端口不可达”，结果会怎么样，值得试试。