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

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个字节，有系统返回的是前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服务器来驱动。

我是作软件的，本来不需要我去关心这个。

不过自己动手作一下，实践一下总不是坏事，而且可以跟他们交流一下。

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