简介基于Java的TCP/UDP端口扫描器是一项计算机网络课程设计作品面向网络编程入门者和需要完成课程设计、大作业或实训项目的学生。工具采用多线程并发实现支持在界面中设置目标IP、起始与结束端口范围0~65535以及线程数0~200扫描过程中将开放端口实时显示在主窗体结束后还可保存结果便于后续分析。压缩包共12个文件以Java源码、编译后的class字节码为主另含Eclipse工程文件、Markdown说明文档和运行界面截图整体仅96KB结构紧凑便于快速导入工程并查看设计说明。已有131人浏览学习说明该作品对同类课程项目具有参考价值。通过源码可学习多线程端口扫描的任务调度与Socket探活思路结合文档能理解TCP/UDP连接探测的判别逻辑Eclipse工程文件让项目可直接加载运行PNG截图则展示了实际界面效果适合作为网络课程设计的起步模板或进一步扩展的基础。1. 课程设计里的端口扫描器为什么网上现成的代码交上去容易翻车“基于 Java 实现的 TCP/UDP 端口扫描器”是计算机网络课程设计里出现率极高的题目。很多同学第一反应是去网上找一份现成代码改个类名就交结果答辩时老师问“TCP 扫描为什么能判断端口开没开”“UDP 扫不到回包怎么解释”直接卡壳。更常见的是代码跑起来到处是坑只能扫本机 127.0.0.1换到局域网就全部报超时UDP 部分扫什么都显示开放线程开大了直接报 too many open files。这些问题的根源不在代码量而在对 TCP 三次握手、UDP 无连接特性、超时语义这三件事的理解。这篇文章把 TCP/UDP 端口扫描器的最小实现、线程池提速、UDP 误判边界讲透并给出可直接复现的 Java 代码和参数方案适合计算机网络课程设计、Java 课程设计以及想补网络编程基础的人。核心目标是让你写完能讲清、讲完能扛住追问。2. 先搞清楚扫描器在看什么TCP 的握手信号与 UDP 的沉默2.1 端口扫描的三种思路全连接、半开扫描与 Java 的边界端口扫描的本质是向目标端口发起一次探测然后观察协议栈的反应。按探测方式划分最常见的三种思路是TCP 全连接扫描完整走完 TCP 三次握手。连接建立成功即端口开放收到 RST 即端口关闭超时即被过滤。TCP 半开扫描SYN 扫描只发送 SYN 包收到 SYN-ACK 判定开放收到 RST 判定关闭然后主动回 RST 而不是完成握手。这种方式不留下完整连接记录扫描速度快但需要构造原始数据包。UDP 扫描发送 UDP 探测报文等待响应或 ICMP Port Unreachable 回包。Java 课程设计里最常踩的第一个坑就是把“半开扫描”写进报告但代码里压根没有半开扫描。原因在于 Java 标准库的 Socket 抽象由操作系统内核完成三次握手你无法让内核发一个 SYN 后不完成连接而去等待 SYN-ACK。Java 没有 raw socket 能力所以纯 Java 实现的是 TCP connect 扫描即全连接扫描不是 SYN 扫描。答辩时如果老师问“你实现的是不是半开扫描”最稳的回答是“Java 的 Socket 由内核完成完整握手所以本设计用的是全连接扫描判断依据是连接建立成功、RST 和超时三种信号。”这个边界不是缺陷课程设计的要求通常是“掌握端口扫描原理并做工程实现”全连接扫描在原理层面完全够用。真正要注意的是报告里的措辞应当和代码行为一致不要写“本系统实现 SYN 半开扫描”然后代码里全是 new Socket()。2.2 TCP 探测的三种判定信号连接建立、RST 与超时TCP 端口扫描的判断基础是三次握手的状态机。扫描器向目标端口发送 SYN 包目标端口有三种响应端口有进程监听且防火墙允许入站目标回 SYN-ACK扫描器回 ACK连接建立。这时扫描器能确认端口开放。端口没有进程监听目标主机协议栈直接回 RST。扫描器收到 RST确认端口关闭。目标在网络上不可达或防火墙静默丢弃探测包扫描器既等不到 SYN-ACK 也等不到 RST只能在超时时间到达后标记为 filtered被过滤。用 Java 的 Socket 来观察这三种信号非常直接。new Socket() 之后调用 connect 并传入超时时间时connect 方法内部由内核发起完整的握手过程。如果连接成功connect 正常返回如果收到 RST抛 ConnectException如果超时未收到任何响应抛 SocketTimeoutException。这三个异常分支就是 TCP 扫描器的核心逻辑。关于超时时间的选型我一般遵循一个经验区间扫描 127.0.0.1 或同网段主机timeout 设 200~500 ms 足够扫描跨网段的局域网主机设 1000 ms扫描公网地址设 2000~3000 ms。超时太短会把响应慢的开放端口漏报成 filtered超时太长又会导致全端口扫描的时间不可接受。具体数字需要在课程设计报告中说明依据这是最容易加分的地方。2.3 UDP 扫描的“黑洞”现象为什么没消息不能直接判关闭UDP 没有握手也没有 ACK 机制。一个 UDP 端口开放着不代表它会回应你的任意报文。例如一台机器的 DNS 服务监听 53 端口你只发一个空数据或一个字节的 0x00DNS 服务可能直接忽略因为请求格式不正确。反过来UDP 端口没有监听时目标主机的协议栈通常回一个 ICMP Port Unreachable 报文但这个回包行为不是强制的目标主机可能禁用 ICMP也可能因为 ICMP 错误报文限速而不回。于是 UDP 扫描的实际判定逻辑只有三档收到响应数据端口开放。收到 PortUnreachable 异常即 ICMP 端口不可达端口关闭。超时没有任何响应无法区分“开放但不应答”和“被过滤”标准术语记为 open|filtered。这个 open|filtered 状态是 UDP 扫描不可消除的固有模糊性。课程设计报告中最不该犯的错误就是把超时直接写为“端口关闭”。一份严谨的报告应当写明UDP 扫描的结果分为 open、closed、open|filtered 三类其中第三类是待确认项。这也是后续第 5 章要引入多轮探测的原因。3. 可复现的 Java 实现TCP/UDP 扫描核心代码与线程池提速3.1 最小 TCP 扫描实现三个异常分支对应三种端口状态先写一个单端口 TCP 扫描方法这是整个扫描器的基础。代码结构很简单但有一个细节很容易翻车不要用 new Socket(host, port) 这种构造方式因为它默认使用系统底层的超时时间可能长达几分钟一旦目标主机丢弃 SYN这个调用会卡很久。正确做法是先创建无连接 Socket 对象再显式调用 connect 方法传入超时时间。public static String scanTcpPort(String host, int port, int timeoutMs) { try (Socket socket new Socket()) { // 主动发起 TCP 三次握手在 timeoutMs 内等待完成 socket.connect(new InetSocketAddress(host, port), timeoutMs); return open; } catch (SocketTimeoutException e) { // SYN 发出后既没收到 SYN-ACK 也没收到 RST // 通常是防火墙静默丢弃或目标主机不可达 return filtered; } catch (ConnectException e) { // 目标协议栈回了 RST说明端口没有进程监听 return closed; } catch (IOException e) { // 其他网络层错误路由不可达、地址异常等 return unknown; } }这个方法的逻辑就是第 2 章讲的三种信号映射。使用 try-with-resources 确保 socket 在任何情况下都被关闭否则每次探测都会泄漏一个文件描述符扫描端口多了之后程序必崩。timeoutMs 参数直接传给 connect它控制的是等待握手完成的期限不是 SO_TIMEOUT 的读超时两者语义不同不要混用。调用示例System.out.println(scanTcpPort(127.0.0.1, 8080, 500)); System.out.println(scanTcpPort(127.0.0.1, 9999, 500));3.2 线程池提速把全端口扫描从小时级压到分钟级单线程扫描 65535 个 TCP 端口按每个端口 200 ms 计算最坏情况下需要 3.6 小时。这个时间在课程设计演示时完全不可接受。解决办法是用线程池并发探测但线程数不是越大越好。import java.net.*; import java.util.*; import java.util.concurrent.*; public static ListMap.EntryInteger, String scanTcpRange( String host, int startPort, int endPort, int timeoutMs, int threads) throws InterruptedException { ExecutorService pool Executors.newFixedThreadPool(threads); ListCallableMap.EntryInteger, String tasks new ArrayList(); for (int port startPort; port endPort; port) { int p port; tasks.add(() - Map.entry(p, scanTcpPort(host, p, timeoutMs))); } // invokeAll 保持任务提交顺序后续结果与端口一一对应 ListFutureMap.EntryInteger, String futures pool.invokeAll(tasks); pool.shutdown(); ListMap.EntryInteger, String results new ArrayList(); for (FutureMap.EntryInteger, String future : futures) { try { results.add(future.get()); } catch (ExecutionException e) { // 单个任务异常不阻塞整体扫描 results.add(Map.entry(0, error)); } } return results; }线程数的选择依据是目标网络环境和本机资源。我一般这样设扫描本机回环地址用 64~128 线程扫描局域网用 32~64 线程扫描公网地址用 16~32 线程。原因是每次 connect 都会占用一个文件描述符Linux 默认的进程 fd 限制通常是 1024如果线程数设为 1024每个线程同时建 socket还没等扫描完就先报 too many open files。另外对同一目标发起过高并发会导致网络栈或目标防火墙触发连接限速反而降低成功率。时间账值得写进报告100 个线程并发扫描本机全端口每个端口超时 500 ms整体最坏耗时约为 65535 / 100 * 0.5 秒约 5.5 分钟实际由于开放端口响应快、连接拒绝响应快大部分任务远低于超时时间。这个估算公式能体现你对并发模型的理解。3.3 UDP 扫描实现探测包、ICMP 错误与超时三态判定UDP 扫描用 DatagramSocket 实现。课程设计里一个常见的错误写法是new DatagramSocket() 后直接 send 一个包然后 receive 等待收不到就判关闭。这样写出来的程序在真实环境下几乎全是误报。正确做法是先调用 DatagramSocket 的 connect 方法把 socket 与目标地址和端口绑定这样后续 receive 只接收来自该端口的数据报且内核能把 ICMP Port Unreachable 错误转成 Java 的 PortUnreachableException。public static String scanUdpPort(String host, int port, int timeoutMs) { try (DatagramSocket socket new DatagramSocket()) { // UDP 的 connect 不是三次握手而是限定收发地址 // 让 receive 只关注来自该端口的响应和 ICMP 错误 socket.connect(new InetSocketAddress(host, port)); socket.setSoTimeout(timeoutMs); byte[] probeData new byte[]{0x00}; DatagramPacket probe new DatagramPacket( probeData, probeData.length, new InetSocketAddress(host, port)); socket.send(probe); byte[] buf new byte[512]; DatagramPacket response new DatagramPacket(buf, buf.length); try { socket.receive(response); // 收到了任何数据说明端口有进程应答 return open; } catch (PortUnreachableException e) { // 内核收到 ICMP Port Unreachable端口关闭 return closed; } catch (SocketTimeoutException e) { // 既没数据也没 ICMP 错误状态不可判定 return open|filtered; } } catch (IOException e) { return unknown; } }这个判断逻辑对应第 2 章讲的 UDP 三态。探测包只发一个字节 0x00这是为了让代码可控很多 UDP 服务对畸形请求不回包所以我们不把“无响应”当关闭而是留给开放与过滤两个可能性。如果你选的课程设计题目要求识别具体服务类型比如 DNS、NTP、SNMP可以在探测包里放对应协议的查询报文但这属于进阶功能基础版先保证判定逻辑不误报就行。需要特别说明的是PortUnreachableException 依赖目标主机回 ICMP 错误报文。在 Linux 环境下当扫描速率过高内核的 ICMP 限速机制会丢弃多余的 Port Unreachable 报文导致后续端口全部进入超时分支。在 Windows 环境下Java 收到 ICMP 错误并转换为异常的可靠性也低于 Linux。所以 UDP 扫描的结果天然带有不确定性代码里输出 open|filtered 而不是强行归类正是对这种不确定性的诚实表达。3.4 合并 TCP/UDP 扫描主流程一次运行覆盖两种协议把上面两个方法整合到一个控制类里方便命令行调用。主流程设计为解析参数按协议类型分发到对应扫描方法收集结果后按端口排序输出。public static void main(String[] args) { String host 127.0.0.1; String protocol tcp; // tcp | udp | both int timeoutMs 500; int threads 64; if (protocol.equals(tcp) || protocol.equals(both)) { ListMap.EntryInteger, String tcpResults scanTcpRange( host, 1, 65535, timeoutMs, threads); tcpResults.stream() .filter(e - !e.getValue().equals(closed)) .forEach(e - System.out.println(tcp e.getKey() e.getValue())); } // udp 分支同理注意全端口扫描默认只扫常用端口区间详见下文 }这里有一个所有 UDP 扫描器都必须面对的工程问题UDP 全端口扫描在公网上不可行因为每个超时端口要等满 timeoutMs而 UDP 的 timeout 不能像 TCP 那样普遍共用数百毫秒。常见做法是默认只扫 1~1024 端口加常见服务端口列表你可以在参数里加一个 --udp-top-ports 选项默认加载 53、67、68、123、161、500、1900、5353 等端口。这个设计不是偷懒是对 UDP 扫描时间成本和 ICMP 限速问题的合理妥协课程设计报告中写明这一点会加分。4. 端口扫描器踩坑排查5 个常见翻车场景与解决路径4.1 现象扫描本机一切正常换到局域网 IP 就全部超时这是课程设计中最常见的翻车现场。本机 127.0.0.1 全端口秒出结果把 host 改成同一台机器的局域网 IP比如 192.168.1.100结果几乎全是 filtered 或 open|filtered。原因有两层一是回环地址的流量根本不经过网卡和外层防火墙本机防火墙通常默认放行二是换到局域网地址后数据包要经过本机防火墙的入站规则Windows 防火墙和 Linux iptables 默认都会丢弃未允许的入站 SYN 包尤其当目标端口不是常用服务端口时。解决办法先把被测机器的防火墙入站规则关掉或者加上临时放行规则再跑测试。Windows 上是控制面板的“Windows Defender 防火墙”临时关闭专用网络入站Linux 上是sudo ufw disable或iptables -F仅限课程设计环境测试完恢复。注意这只能解决“被本机防火墙过滤”的场景如果目标是其他主机还要检查目标机的防火墙。排查时先用 ping 确认主机在线再用telnet 目标IP 端口验证单端口连通性逐层定位。4.2 现象UDP 扫描结果像黑匣子要么全部 closed 要么全部 open|filteredUDP 扫描跑完后发现一个明明在监听 DNS 服务的 53 端口显示 open|filtered而一个没进程监听的端口也显示 same 状态或者反过来所有端口都显示 closed包括那些确实在收包的 UDP 服务。前一种情况多半是探测包无效你发一个 0x00 字节给 DNS 53 端口DNS 服务直接丢弃不会回包所以显示 open|filtered 是正确行为不是 bug。后一种全 closed 的情况通常是客户端收到了 ICMP Port Unreachable但这是来自目标主机的另一个端口或是因为目标主机整体不可达而由中间路由器回的错误如果用了未 connect 的 DatagramSocket错误范围控制不住。解决路径有两条一是确认每个 UDP 端口回包的特性课程设计阶段优先选择会回包的 UDP 服务做演示比如用 NTP 时间查询或自定义的 Java UDP 服务端二是把探测包改成目标服务能识别的格式比如对 DNS 53 端口发一个标准的 DNS 查询头这需要你了解应用层协议但很能体现水平。如果实在无法让服务回包就在报告里说明 open|filtered 的含义解释这是 UDP 协议的固有特性。4.3 现象线程数开大后系统资源耗尽扫描反而更慢有的同学为了追求速度把线程池线程数设成 1000 甚至 65535结果程序运行到一半抛出 too many open files或者系统卡死。原因是每个 Socket 在操作系统层面对应一个文件描述符fdLinux 普通用户的 ulimit -n 默认值通常是 1024。线程数 1000 时瞬间创建的 socket 数远超 fd 上限。另外线程本身有栈内存开销默认 1 MB 虚拟内存大量并发线程还会增加上下文切换成本扫描吞吐量不一定随线程数线性增长。解决线程数设置不超过 256最常见的选择是 64。另一个要点是确保所有 socket 用 try-with-resources 关闭否则线程池复用线程时 fd 泄漏会累计到不可收拾。排查时用lsof -p 进程号 | wc -l看运行中的 fd 数如果只增不减说明有资源没释放。全端口扫描建议按端口段分批执行每批 10000 个端口跑完一批再跑下一批。4.4 现象结果乱序报告里端口号前后跳动并发扫描后结果列表如果按完成时间打印输出顺序是乱序的8080 出现在 22 前面443 在 80 前面。课程设计演示时看起来很不专业。原因很好理解Future 任务的完成时间不同先完成的先打印但顺序不代表端口大小。解决办法有两个方向一是在提交任务时用一个带端口的队列保存结果最后统一按端口排序二是像 3.2 节代码那样使用 invokeAll它的返回 List 顺序与任务提交顺序一致天然按端口升序。如果用的是 CompletionService则必须自行按端口排序再输出。4.5 现象socket 连接成功后调 getInputStream().read() 卡住给 TCP 扫描加 banner 功能读取服务版本信息时连接建立后调用 socket.getInputStream().read()程序卡在那一行直到读超时。原因在于很多服务不会主动向客户端发送 banner。HTTP 服务要等客户端发送请求行才响应Redis 服务会打印欢迎信息但那是 Telnet 协议的行为MySQL 协议也是先发握手包。对于不会主动发数据的目标read() 收不到任何字节。如果只为判断端口开闭完全不需要读数据如果要实现 banner 识别必须预先知道目标服务的协议行为不能对所有端口统一读取。解决banner 识别作为独立可选功能只对已知协议的目标端口启用并且给读操作设置 SoTimeout例如 1000 ms。不要在基础扫描逻辑里包含 read 操作否则扫描时间会被无限拖长。5. 加分改造给扫描器加参数、多轮探测与结果导出5.1 命令行参数把写死的代码变成可配置工具课程设计评审老师通常不喜欢只能通过改代码来换参数的“扫码器”。一个带命令行参数的小型扫描器接收主机地址、协议类型、端口范围、超时时间、线程数既体现了工程意识又方便演示不同场景。常见的参数设计如下public static ScanConfig parseArgs(String[] args) { ScanConfig config new ScanConfig(); for (int i 0; i args.length; i) { switch (args[i]) { case -h: config.host args[i]; break; case -p: config.portRange args[i]; break; case -t: config.protocol args[i]; break; // tcp / udp / both case -timeout: config.timeoutMs Integer.parseInt(args[i]); break; case -threads: config.threads Integer.parseInt(args[i]); break; default: System.out.println(用法: java PortScanner -h 127.0.0.1 -p 1-1024 -t both); } } return config; }ScanConfig 是一个简单的 POJO 类字段包括 host、portRange、protocol、timeoutMs、threads。portRange 用 1-1024 这样的字符串表达解析时拆成 start 和 end。参数表里值得写的三个默认值timeoutMs 默认 500threads 默认 64protocol 默认 tcp。这三个默认值对齐的是本机/局域网环境如果想扫公网需要在答辩时说明调参逻辑。课程设计中最常见的提问是“为什么 timeout 不是固定值”。你要能答上来timeout 反映的是网络往返时间与丢包容忍度。局域网 RTT 通常小于 10 ms500 ms 足够公网跨运营商 RTT 可能 100 ms 以上且有丢包重传需要 3000 ms。5.2 多轮探测与超时分级降低 UDP 误判的正确做法UDP 扫描最大的痛点是 open|filtered 的模糊状态。一个实用的工程方案是分三轮扫描每轮作用不同第一轮快速扫描。TCP 用 300 ms 超时快速摸一遍全部端口UDP 只扫常用端口列表超时 800 ms。这一轮的产出是候选列表把所有非 closed 状态都收进来。第二轮重点复核。对第一轮结果为 open|filtered 的 UDP 端口逐个做 3 秒超时的重测且对同一端口最多发三次探测包。这样做能绕过 ICMP 限速窗口内核的 ICMP 错误限速通常是按秒计数的多轮间隔几秒再探测能显著提高收到 Port Unreachable 的概率。同一探测目标状态如下轮次覆盖范围超时设置判定目的第一轮全端口或常用端口列表300~800 ms快速筛出候选端口第二轮候选中的 UDP openfiltered 端口3000 ms最多 3 次第三轮第二轮仍为 openfiltered 的端口加载应用层探测报文第三轮的“应用层探测报文”可以只做一个可扩展接口。比如对 DNS 服务发一个构造好的 DNS 查询包对 NTP 发 NTP 版本请求收到任何字节就算 open。这个设计能写进报告作为“基于协议指纹的 UDP 服务识别”是课程设计里很扎实的扩展亮点。实际实现中我给第三轮的每个端口最多 5 秒因为有些服务对畸形包处理慢。多轮探测的代价是总耗时增加但换来的可信度提升非常明显。演示时选 5 个端口一轮就能出结果全端口扫描用三轮能在一个小时左右跑完一个常见端口集合这种时间预算要提前算好。5.3 结果输出控制台表格、CSV 导出与轻量 GUI扫描结果只打 System.out.println 的话端口多了看不清。我给课程设计版配了两种输出控制台对齐表格和 CSV 文件导出。CSV 是最稳妥的格式后续可以用 Excel 或 Pandas 做统计图表汇报时直接用数据说话。public static void writeCsv(String filePath, ListScanResult results) throws IOException { try (BufferedWriter writer Files.newBufferedWriter(Paths.get(filePath))) { writer.write(protocol,port,state,response_time_ms); writer.newLine(); for (ScanResult r : results) { writer.write(String.format(%s,%d,%s,%d, r.protocol, r.port, r.state, r.responseTimeMs)); writer.newLine(); } } }ScanResult 类的字段建议至少包含 protocol、port、state、responseTimeMs 四项。加了响应时间字段后你可以额外输出一个“高延迟端口”列表判断哪些目标可能存在流量过滤或网络拥塞这也是报告里的好素材。GUI 部分我不建议把逻辑写进 Swing 事件线程。如果你需要图形界面用一个 Controller 类持有扫描逻辑Swing 界面只负责调用 controller.start(config) 和监听进度事件。扫描放后台线程执行用 SwingWorker 或线程池回调更新 JTable 模型。核心网络逻辑与展示层解耦既是好习惯也能避免界面卡死被老师当场发现。图形界面不是必需项但一旦做至少要保证扫码过程中窗口能拖动、能取消任务。6. 验证你的扫描器用 netstat 与本机服务做对照实验课程设计验收时最有力的证据不是“我扫出了这些端口”而是“我的扫描结果和系统真实监听状态一致”。验证方法很简单先查本机真实监听的端口列表再拿你自己的扫描器去扫逐项对照。Windows 用netstat -ano | findstr LISTENINGLinux 用ss -utln或netstat -utln。从中挑 3 个 TCP 监听端口和 1 个不存在的端口比如 39999用你的 TCP 扫描器分别扫预期是前 3 个显示 open最后一个显示 closed。用防火墙规则拦截一个端口的入站连接再扫它预期显示 filtered这能验证超时分支被正确触发。UDP 验证稍微麻烦一点可以写一个 30 行的 Java UDP 服务端程序绑定 8888 端口收到任何数据就回一个固定字节。然后用你的 UDP 扫描器扫 8888预期返回 open再扫一个未监听的 UDP 端口预期要么 closed 要么 open|filtered但注意全 closed 时要去目标机确认 ICMP 没有被防火墙丢弃。重复扫描同一个端口 5 次看结果是否稳定如果一次 open 一次 open|filtered说明探测报文或网络栈有问题恰好暴露了 UDP 扫描的真实难度。我习惯在提交课程设计前做最后一次“三段式自检”扫本机、扫局域网里的第二台机器、用 Wireshark 抓一次包确认 SYN 和 SYN-ACK 真的在线上出现。抓包这一步如果时间允许一定要做它能直接证明代码行为符合三次握手理论比口头解释有说服力得多。整套验证跑下来你对自己交付的不是“网上抄的代码”这件事会非常有底气。希望这些经验和参考代码能帮你把端口扫描器这个题目做成一份能讲清楚、经得起追问的课程设计。本文还有配套的精品资源点击获取
