当Rust性能不如Go时，问题往往不在语言本身。通过深入分析一个实际案例，揭示了并发模型选择对性能的决定性影响，以及操作系统层面的限制如何影响程序表现。
智能速览
Go的worker pool与Rust的stream模型底层行为完全不同
poll大量future的开销远大于调度固定数量goroutine
Windows临时端口耗尽是并发连接的性能瓶颈
Semaphore可以控制Rust并发数量，实现与Go等价效果
超时设置对扫描性能有直接影响
精华内容
深入分析Rust与Go的性能差异，发现关键在于并发模型的选择而非语言本身，同时操作系统层面的限制也不容忽视。
并发模型差异
Go版本采用经典的worker pool模式：固定100个goroutine从channel拉取任务执行。而Rust版本使用stream + buffer_unordered：一次性创建25000个future，让tokio调度器管理。虽然表面上都是100并发，但底层行为截然不同。poll 25000个future的开销远大于调度100个goroutine，这才是性能差异的根源。
系统端口限制
当程序发起25000个并发连接时，会遇到操作系统层面的限制。Windows的动态端口范围默认是49152-65535，只有约16384个可用端口。Go版本因为同时只有100个连接，端口足够使用。而Rust版本试图建立大量连接，导致临时端口耗尽，这是语言无关的系统限制。
Rust优化方案
要在Rust中实现真正的worker pool，可以使用tokio::sync::Semaphore控制并发数。通过Semaphore限制同时只有100个连接进行，这与Go的worker pool逻辑完全等价。虽然tokio::sync::mpsc的Receiver不能clone，但配合Arc
超时设置影响
超时设置对扫描速度影响显著。Rust版本设置200ms超时，Go版本为1秒。对于大部分关闭的端口，连接拒绝(RST)通常几毫秒就返回，根本等不到超时。真正影响速度的是被防火墙DROP的不响应端口，这些才需要等待超时。过短的超时反而可能导致误判。
Rust具备极高的性能上限，但前提是正确选择并发模型。对于IO密集型批量任务，stream并非最优解。理解底层原理、选择合适的并发策略，才能充分发挥Rust的性能优势。
