这段时间提交的勘误
三次握手相关
今天在阅读韩立刚《计算机网络原理》和林沛满《wireshark网络分析就是这么简单》这两本书时发现对tcp握手为什么是三次而不是两次有不同的解释。
林沛满《wireshark网络分析就是这么简单》在第62页对tcp握手为什么是三次而不是两次的解释是这样的:
为什么要用三个包来建立连接呢,用两个不可以吗?其实也是可以的,但两 个不够可靠。我们可以设想一个情况来说明这个问题:某个网络有多条路径,客 户端请求建立连接的第一个包跑到一条延迟严重的路径上了,所以迟迟没有到达 服务器。因此,客户端只能当作这个请求丢失了,不得不再请求一次。由于第二 个请求走了正确的路径,所以很快完成工作并关闭了连接。对于客户端来说,事 情似乎已经结束了。没想到它的第一个请求经过跋山涉水,还是到达了服务器。 服务器并不知道这是一个旧的无效请求,所以按照惯例回复了。假 如TCP只要求两次握手,服务器上就这样建立了一个无效的连接。而在三次握手 的机制下,客户端收到服务器的回复时,知道这个连接不是它想要的,所以就发一个拒绝包,服务器收到这个包之后,就放弃这个连接。
韩立刚《计算机网络原理》在第375页对tcp握手为什么是三次而不是两次的解释是这样的:
考虑一种正常情况。客户端发出连接请求, 但因连接请求报文丢失而未收到确认。于是客户端再重传一次连接请求。后来收到了确认,建立了连接。数据传输完毕后,就释放了连接。客户端共发送了两个连接请求报文段,其中第一个丢失, 第二个到达了服务器。没有“已失效的连接请求报文段"。
现假定出现一种异常情况,即客户端发出的第一个连接请求报文段并没有丢失,而是在某些网 络结点长时间滞留了,以致延误到连接释放以后的某个时间才到达服务器。本来这是一个早已失效 的报文段。但服务器收到此失效的连接请求报文段后,就误认为是A又发出一次新的连接请求。 于是就向客户端发出确认报文段,同意建立连接。假定不采用三次握手,那么只要服务器发出确认, 新的连接就建立了。 由于现在客户端并没有发出建立连接的请求,因此不会理睬服务器的确认,也不会向服务器发送数据。但服务器却以为新的传输连接已经建立了,并一直等待客户端发来数据。服务器的资源就这样白白浪费了。采用三次握手的办法可以防止上述现象的发生,例如在刚才的情况下,客户端不会向服务器的确认发出确认,服务器由于收不到确认,就知道客户端并没有要求建立连接。
RFC793当中的解释是这样的,https://www.ietf.org/rfc/rfc793.txt 并没有明确的结论:client 发出的第一个连接请求报文段并没有丢失,而是在某个网络结点长时间的滞留了,以致延误到连接释放以后的某个时间才到达 server。本来这是一个早已失效的报文段。但 server 收到此失效的连接请求报文段后,就误认为是 client 再次发出的一个新的连接请求。于是就向 client 发出确认报文段,同意建立连接。假设不采用 “三次握手”,那么只要 server 发出确认,新的连接就建立了。由于现在 client 并没有发出建立连接的请求,因此不会理睬 server 的确认,也不会向 server 发送数据。但 server 却以为新的运输连接已经建立,并一直等待 client 发来数据。这样,server 的很多资源就白白浪费掉了。采用 “三次握手” 的办法可以防止上述现象发生。例如刚才那种情况,client 不会向 server 的确认发出确认。server 由于收不到确认,就知道 client 并没有要求建立连接。”
![](https://img2020.cnblogs.com/blog/1703421/202004/1703421-20200419203532151-889132485.png)
DHCP相关
韩立刚《计算机网络原理》dhcp那一章(406页)有个地方错了,dhcp的offer包的ack包是单播,discover和request是广播,书里面全写成广播了;