老王这骚操作，是反射攻击吗？

如果发送一个网络请求后，客户端离线，并且同一个IP被分配给另一台客户端，那么服务器响应会怎么做？

如题，假设客户端IP是1.1.1.1 ,我向2.2.2.2的客户端发送了一个请求。

然后我这台客户端断网，另一台客户端设置IP地址为1.1.1.1。

那么服务端在响应请求的时候会将响应发送给新的客户端吗？(假设两个客户端都是监听同一个端口)，如果发送了，会有安全隐患吗？

这彷佛就是反射攻击（Reflective Attack）的一种。

老王（IP地址随意）看老张（1.1.1.1）不爽，想戏弄他一下，于是伪造成老张，向老李（2.2.2.2）发送DNS请求，老李蒙在鼓里，向老张家返回了DNS回复。问老张能收到DNS回复吗？

可以的。

可是老王这种恶作剧伤害系数（1：1）不大，即老王发一个伪造包，老张就收到一个回复攻击包。

老王可以放大攻击系数吗？

理论上是可以的，假设2.2.2.0/24是一个广播域，包含的200多台主机都提供DNS回复。老王只要将目的地址修改成 2.2.2.255即可。如果老王不知道广播域多大，可以采用盲猜的方式，多发几个伪造包，可以是2.2.2.255、2.2.2.127、2.2.2.63、2.2.2.31、2.2.2.15、2.2.2.7、2.2.2.3 等等，只要理论上是一个广播地址即可。

老王还可以朝全球著名DNS发送类似的伪造报文，可以进一步放大攻击系数。此外老王还可以修改源IP为1.1.1.255、1.1.1.127、1.1.163…等等来恶心不光老王，还包括老王的邻居。

但是，以上不是题主所关心的，题主关心的是安全防护的（守）而不是网络攻击的（攻）。到底新的客户端可以收到服务器的回复吗？

理论上是可以的，只要满足以下条件：

• 老、新客户端使用相同的IP =1.1.1.1
• 老、新客户端使用相同的MAC
• 服务器的回复到达时，老客户端离线（交换机端口down）

只要同时满足以上条件，新客户端就可以收到服务器的回复。

如果服务器的回复到达时，老客户端还没有离线（down），新客户端需要做哪些努力才能让交换机把服务器回复包发给自己而不是老的客户端？

只要新客户端持续发包，可以是任意包，用来刷新（update）交换机的MAC地址表，用以覆盖老客户端MAC地址与端口的映射。

如果新客户端使用的MAC地址与老客户端不一样，服务器的回复有可能流向新客户端吗？

理论上依然有可能，只要新客户端持续发送Gratuitous ARP报文，可以起到两个作用：

• 刷新（update）网关的ARP Table
• 刷新（update）交换机的MAC Table

如果两个客户端MAC地址不同，仅仅使用相同的IP地址，不做上文的种种主动（active）参与，而是被动（passive）等待，新客户端是无法收到服务器的回复的。

看到有同学的回答，新客户端能否收到取决于“客户端与服务器之间是否有心跳（keepalive）机制”，这显然是对心跳有一个误解。

TCP层面的心跳，通常配置在服务器侧，为什么要这么配置？

主要用于TCP服务器侧回收内存资源，因为很多客户端往往并不在线，但是却一直保持TCP连接，这样就耗费了N多服务器的资源（维持TCP连接）。

TCP服务器发出的心跳检测，经过三次检测就可以将客户端判定为离线状态并释放连接，从而回收内存。但是这个周期是2小时，即两小时尝试回收一次。

以上是一个古老的故事了，自从NAT大批量引入互联网，为了避免NAT表的老化删除，需要通信双方有一个心跳包，用来刷新NAT表。多久刷新一次才好呢？

肯定要小于NAT表的老化删除时间，但是也不能太频繁，太频繁对双方是一个负担，对网络也是一个负担，综合各大厂商TCP/UDP/ICMP的NAT超时时长统计，小于60秒的心跳可以应对所有场景。即使苛刻的网络场景，心跳一般在5秒、10秒应该绰绰有余。在这么漫长的时间内，新客户端收到报文也是没有问题的，当然能收到源于上文的假设。

如果新客户端能收到服务器的回复，由于listen的端口 = 老的端口，自然能回复服务器的心跳检测请求，从而发出自己的心跳回复，服务器无法检测老的客户端已经离线了！

文章基于一个个假设，其实新客户端无论收到还是收不到，不是很重要，重要的是报文有没有安全加密，有没有完整性保护。如果有这两项的保护，收到又如何，没有密钥一样解不出，何用？这就是网络安全发展到今天，普遍采用的对策。