之前张自然对这个问题也是很费解，看样子真是协议层的问题。

按理说，两台主机因为接收了多余的报文后，都应该无法正常工作，盗用马上就会被察觉，盗用也就无法继续了；但是，在实验中地址被盗用之后，各台实验设备都可以互不干扰的正常工作。这又是什么原因呢?答案应该归结于上层使用的协议。

目前，网络中最常用的协议是TCP/IP协议，网络应用程序一般都是运行在TCP或者UDP之上。例如，实验中Web服务器采用的HTTP协议就是基于TCP的。在TCP或者UDP中，标志通信双方的不仅仅是IP地址，还包括端口号。在一般的应用中，用户端的端口号并不是预先设置的，而是协议根据一定的规则生成的，具有随机性。像上面利用IE来访问Web服务器就是这样。UDP或者TCP的端口号为16位二进制数，两个16位的随机数字相等的几率非常小，恰好相等又谈何容易?两台主机虽然MAC地址和IP地址相同，但是应用端口号不同，接收到的多余数据由于在TCP/UDP层找不到匹配的端口号，被当成无用的数据简单地丢弃了，而TCP/UDP层的处理对于用户层来说是透明的；所以用户可以“正确无误”地正常使用相应的服务，而不受地址盗用的干扰。

当然，某些应用程序的用户端口号可能是用户或者应用程序自己设置的，而不是交给协议来随机的生成。那么，结果又会如何呢?例如，在两台MAC地址和IP地址都相同的主机上，启动了两个端口相同的应用程序，这两个应用是不是就无法正常工作了呢?其实不尽然。

如果下层使用的是UDP协议，两个应用将互相干扰无法正常工作。如果使用的是TCP协议，结果就不一样了。因为TCP是面向连接的，为了实现重发机制，保证数据的正确传输，TCP引入了报文序列号和接收窗口的概念。在上述的端口号匹配的报文中，只有那些序列号的偏差属于接收窗口之内的报文才会被接收，否则，会被认为是过期报文而丢弃。TCP协议中的报文的序列号有32位，每个应用程序发送的第一个报文的序列号是严格按照随机的原则产生的，以后每个报文的序列号依次加1。

窗口的大小有16位，也就是说窗口最大可以是216，而序列号的范围是232，主机期望接收的TCP数据的序列号正好也处于对方的接收范围之内的概率为1/216，可谓小之又小。 TCP的序列号本来是为了实现报文的正确传输，现在却成了地址盗用的帮凶。