单socket发送多UDP包实现VLAN发现：选多线程还是循环发送？

优先选择单线程循环发送的方案，多线程发送不仅没有收益，还会带来额外的问题，二者差异非常明显：

二者核心差异 #

• 资源开销差异
  为每个VID开独立线程属于完全没必要的资源浪费：Linux默认每个线程栈大小为8M，4096个线程光栈内存就占用32G，再加上线程上下文切换的CPU开销，反而会拉低程序运行效率。同时多线程还要额外处理同步逻辑：比如找到正确VLAN后要终止所有还在运行的发包线程，编程复杂度高很多。
• 网络稳定性差异
  多线程同时发送会在短时间内产生数千个广播DHCPDISCOVER报文，很容易触发交换机的广播风暴抑制策略，导致合法报文被丢弃，反而可能漏过正确VLAN的响应。单线程循环发送可以很方便的控制发包间隔（比如每次发完等待100~200ms再发下一个），完全不会触发广播抑制，网络侧处理更稳定。
• 逻辑复杂度差异
  单线程方案只需要初始化一次SOCK_RAW套接字，循环过程中仅修改802.1Q头部的VID字段复用套接字发送即可，再单独开一个收包线程监听响应即可，逻辑非常简单。多线程方案需要处理多线程发包同步、响应去重、异常退出等逻辑，出问题排查难度大很多。

优化建议 #

• 不用每次循环都重新创建套接字，初始化阶段创建一次RAW套接字复用即可，能大幅提升发包效率
• 等待响应不用发一个等一个，可以让收包线程持续监听，一旦拿到正确VLAN的DHCP响应就给发包循环发终止信号，避免无意义的遍历
• 不用硬遍历全部4094个可用VID，可优先遍历企业常用的VLAN段（比如2~1000），再遍历剩余段，能大幅加快发现速度

内容的提问来源于stack exchange，提问作者Mark