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包告诉它“端口不可达”，结果会怎么样？值得试试 。
第2卷 第13章 HTTP协议
这一章对HTTP的请求与响应格式做了简单的介绍 。由于所有传送的内容基于ASCII，虽然也会传送其他二进制，如图片，MIME文件，但是其本是还是可以从请求或响应头中看出传送的类型，分析起来就没什么难度了 。这些可以用 telnet 或者 nc做一个真实的会话过程 。把后面一章（第2卷第14章 HTTP服务器的分组）看完，预备自已动手做一个小的Web服务器 。公司下一步的计划是把大部分的硬件都做成可直接由浏览器操作的 。而这些必须要由一个 web服务器来驱动 。我是作软件的，本来不需要我去关心这个 。不过自己动手作一下，实践一下总不是坏事，而且可以跟他们交流一下 。
推荐阅读
- 一 网络沟通的桥梁---协议X档案
- 二 网络沟通的桥梁---协议X档案
- 四 网络沟通的桥梁---协议X档案
- 三 网络沟通的桥梁---协议X档案
- 六 网络沟通的桥梁---协议X档案
- 五 网络沟通的桥梁---协议X档案
- 怀孕期间如何协议离婚
- 网络协议分析缩略语汇总
- 七 网络沟通的桥梁---协议X档案
- 基于 IPv6 协议的家庭网络新技术