如何在Golang中编写一个TCP端口扫描器 Go语言网络编程并发实践

net.dialtimeout 更适合端口扫描，因其可精确控制连接超时（如500ms），避免系统默认长超时阻塞并发；需合理设值防误判，配合waitgroup与令牌桶限流，并通过类型断言准确区分open/filtered/closed状态。

为什么 net.DialTimeout 比 net.Dial 更适合端口扫描

直接用 net.Dial 扫描大量端口时，超时不可控——它默认依赖系统 TCP 连接超时（linux 通常 2–3 分钟），扫一个死端口就卡住几十秒，根本没法并发。而 net.DialTimeout 允许你精确控制连接尝试时长，比如设成 500 * time.Millisecond，既避开防火墙的 SYN flood 检测，又不让 goroutine 僵死。

• 必须显式传入 time.Duration，不能写 500，否则是纳秒级，实际等于立刻失败
• 超时值太短（如 10ms）会导致局域网内正常端口误报为关闭；太长（如 2s）会拖慢整体扫描速度
• 注意：windows 下某些高并发场景中，DialTimeout 可能触发 WSAENOBUFS 错误，需配合 runtime.goMAXPROCS 限流

如何用 sync.WaitGroup 安全控制并发 goroutine 数量

不加限制地为每个端口启一个 goroutine，轻松创建上万协程，内存暴涨、调度开销大，还可能被目标主机或中间设备限速/拦截。用 sync.WaitGroup + channel 控制并发数，是最轻量且可靠的方式。

• 别把 WaitGroup.Add(1) 放在 goroutine 内部——容易漏调或重复调，应在启动前调用
• 务必在 goroutine 结束前调用 wg.Done()，哪怕遇到错误也要执行，否则 wg.Wait() 永远阻塞
• 推荐搭配带缓冲的 channel 做“令牌桶”：先从 sem := make(chan Struct{}, 100) 拿令牌，扫描完再放回，比单纯靠 WaitGroup 更易控峰

怎么判断 net.DialTimeout 返回的是“端口关闭”还是“网络不可达”

错误类型不是只看字符串是否含 "timeout" 或 "refused"——底层错误可能是 *net.OpError 套着 *os.SyscallError，直接 err.Error() 匹配极易漏判或误判。

• 用类型断言检查：if opErr, ok := err.(*net.OpError); ok && opErr.Err != nil
• 真正表示端口关闭的是 opErr.Err.Error() == "connection refused"（Linux/macos）或包含 "WSAECONNREFUSED"（Windows）
• 网络不可达、主机无响应、防火墙静默丢包等情况，通常表现为 opErr.Err 是 *os.SyscallError 且 Err == syscall.EHOSTUNREACH 或 syscall.ENETUNREACH
• 别忽略 opErr.Timeout() 方法，它比字符串匹配更准，能统一识别所有超时类错误

为什么扫描结果要区分 “open”、“filtered”、“closed”，而不是只标 “open/closed”

真实网络环境中，很多防火墙会静默丢弃 SYN 包（不回 RST），导致你收不到任何响应——这不是端口开着或关着的问题，而是路径被过滤了。只分两类会严重误导判断。

立即学习“go语言免费学习笔记（深入）”；

• open：收到 SYN-ACK → 确认服务监听
• closed：收到 RST → 确认端口无服务
• filtered：超时且无 RST → 无法确认，可能是防火墙、ACL、NAT 设备拦截
• 实践中，filtered 出现频率远高于预期，尤其在云环境或企业内网；忽略它，相当于把盲区当安全区

端口扫描真正的难点不在发包，而在对各种中间设备行为的容忍和归因——同一段代码，在本地 docker 网络里跑得飞快，在 AWS Security Group 后面可能全变成 filtered，这时候看日志里满屏 timeout 就该想到：不是你的代码慢，是网络在说话。