开篇先说明一件事：我这里说的 NC，是指 Netcat，Linux/Windows 圈子里公认的“网络瑞士军刀”，不是硬件设计里那个 NC（Not Connected，未连接引脚），也不是三菱数控系统那套 NC Explorer。搜索资料的时候这两个名字特别容易撞车，我一开始就吃过这个亏，后面会专门展开讲。如果你刚好需要在一台机器和另一台机器之间快速传个文件、探测一下端口通不通、或者临时搭一个最简 TCP/UDP 服务做联调，Netcat 是最直接的工具，没有之一。这篇文章是我把整个跨机通信实验过程完整复盘后整理的笔记，包含环境规划、命令细节、截图内容说明和使用手册，希望能帮你少走一点弯路。
这次实验的初衷很朴素：有两台服务器不在同一个机房，中间只开了最基本的网络策略，我想验证它们之间的 TCP 连通性，并且临时传一个不大的安装包过去。当时手头没有 scp、没有 rsync，SSH 服务也没装，唯一确定可用的是系统自带的 nc。于是我把整个验证过程拆成了几个阶段，从最小化连通验证一路做到文件传输和简易服务搭建，踩了不少坑，也把每个坑的排查思路记了下来。文章适合刚接触网络调试工具的同学，也适合已经在用 NC 但想系统整理用法的人，直接对照命令抄作业就行。
1. 实验背景：为什么我要折腾 NC 跨机通信
1.1 这个实验到底解决什么问题
跨机通信听起来很玄乎，实际上就是两台计算机通过网络互相发数据。最常见的场景无非三种：验证端口是否可达、传输文件或文本、临时搭一个收数据的服务端。大多数时候我们第一反应是 SSH、SCP、或者写个 Python 脚本用 socket 发数据，但这些方案都有前提条件：SSH 需要装服务端、开端口、配密钥；SCP 依赖 SSH；Python 脚本虽然灵活，但目标机器上不一定有 Python 环境，或者版本不一致导致脚本跑不起来。
Netcat 不一样。它就是个单一可执行文件，依赖极低，几乎所有 Linux 发行版都内置了，Windows 上也可以用一个几百 KB 的 exe 解决问题。我这次实验的核心目标就是：在两台“裸得不能再裸”的机器之间，用最少的依赖完成连通性验证和文件传输。整个过程不涉及任何第三方服务，只要 IP 和端口是通的，Netcat 就能干活。
1.2 为什么选择 Netcat 而不是 SSH 和 Python
有人会问：SSH 不香吗？SCP 不香吗？说实话，在条件允许的情况下，SSH 和 SCP 当然更香，它们有加密、有认证、有断点续传，甚至还能跑 rsync。但真实环境往往没有这么理想。我这次遇到的情况是：目标机器是 CentOS 6.5，还是一个最小化安装，连 SSH 服务端都没装，手头也没有系统镜像光盘，只有一台能联网的跳板机可以下载少量依赖包。这种情况下，装一个 SSH 服务端要处理 RPM 依赖链，可能要拉十几个包进来，而 Netcat 只需要一个 RPM 就能搞定。
还有一种方案是 Python one-liner，比如python -m SimpleHTTPServer起一个 HTTP 服务来传文件。这个思路本身没问题，我也经常这么干。但问题在于：如果目标机器的 Python 版本太老、缺少模块，或者出于安全策略禁止了 Python 执行，这条路就走不通了。Netcat 没有任何脚本引擎依赖，它就是一个编译好的二进制文件，扔到机器上就能跑。
1.3 实验环境规划
这次实验我用了两台机器：
- 机器 A（服务端/监听端）：IP 192.168.1.10，CentOS 6.5，最小化安装，已有 nc 命令
- 机器 B（客户端/连接端）：IP 192.168.1.20，Ubuntu 20.04，自带 netcat-openbsd
网络环境是同一个局域网段，中间没有额外的防火墙设备，但两台机器自身的 iptables 都是开着的。这个细节很重要，因为后面的坑基本都出在防火墙和端口绑定上。
我把实验分成了五个阶段：
- 最基础的 TCP 端口连通性验证；
- 文本消息的实时发送和接收；
- 单个文件的传输；
- 整个目录的传输（用 tar 配合管道）；
- 端口探测与批量连通检查。
每个阶段都有明确的成功标准和失败时的大致原因，下面逐一复盘。
2. Netcat 基础认知与安装部署手册
2.1 Netcat 到底是什么？免费吗？
Netcat 最早由 Hobbit 在 1995 年发布，设计目标就是一个“通过网络读写数据的全能工具”。它的工作模式极其简单：从一个端读数据，发送到另一个端，反向也一样。也就是说，你可以把 Netcat 看作一根“网络管道”，把本地文件、标准输入、标准输出和网络端口串在一起。
关于“Netcat 收费吗”这个问题，网上问的人很多。答案是：Netcat 本身完全开源免费，无论是 GNU 版、OpenBSD 版还是 Nmap 项目维护的 Ncat，都是免费软件。那些让你付费的所谓“Netcat 收费版”，基本是商业网络工具套了层壳，或者是一些 Windows 图形化包装程序，和真正的 Netcat 不是一回事。你直接在 Linux 发行版仓库里装的nc命令，就是免费的。
2.2 三套主流版本怎么选
Netcat 的版本有点混乱，不同发行版默认装的实现不一样，参数也不完全兼容。我建议你优先搞清楚自己用的是哪一套：
| 实现 | 常见包名 | 特点 | 常见系统 |
|---|---|---|---|
| GNU Netcat | nc / netcat-traditional | 最经典，参数中规中矩，支持-e（部分编译时禁用） | CentOS 6、Debian 老版本 |
| OpenBSD Netcat | netcat-openbsd | 支持-k持续监听、-N发送完关闭连接、-6IPv6 | Ubuntu 默认、macOS 自带 |
| Ncat | nmap 附带 | 功能最丰富，支持 SSL、代理、--send-only、--recv-only | Nmap 安装包内附带 |
这里最容易踩的坑是：同一条命令行在 Ubuntu 上跑得通，在 CentOS 6 上就跑不通。比如nc -l 8888，OpenBSD 版可以直接用，但传统 GNU 版必须写成nc -l -p 8888，否则会报参数错误。所以使用前先跑一下nc -h看帮助信息，确认你的版本支持哪些参数，这能省掉很多排查时间。
2.3 各系统安装实操（含 CentOS 6.5 离线安装）
联网环境安装 Netcat 非常简单：
# Debian/Ubuntu apt-get install -y netcat-openbsd # CentOS/RHEL 7+ yum install -y nc # CentOS/RHEL 8+/Fedora dnf install -y nc # macOS（自带但可以升级） brew install netcat但我这次实验中的 CentOS 6.5 是内网环境，没法直接 yum。离线安装的思路是：在一台能联网的同版本机器上把 RPM 包下载下来，再拷贝进去。
# 在能联网的 CentOS 6.5 机器上执行（仅下载不安装） yum install --downloadonly --downloaddir=/tmp/nc_pkg nc # 生成依赖列表，确认是否还有依赖包 rpm -qpR /tmp/nc_pkg/nc-*.rpm如果机器是 x86_64 架构，通常只需要一个nc-1.84-24.el6.x86_64.rpm这种命名的包，依赖比较少，直接安装即可：
rpm -ivh nc-*.rpm # 验证安装结果 nc -h如果rpm -ivh提示缺少 glibc 依赖，那说明系统基础库本身就不完整，这种属于极端情况，一般最小化安装不会遇到。另一个可行的替代方案是拷贝一个静态编译的 Netcat 二进制文件过去，比如 Nmap 官方的 ncat 静态版本，解压就能用，连 RPM 都不用装。
3. 跨机通信实验全流程复盘
3.1 第一步：TCP 连通性验证
实验的第一步不是急着传文件，而是先验证两台机器之间 TCP 能不能通。我在机器 A 上开启监听：
# 机器 A nc -l -p 8888这个命令的意思是：监听本机 8888 端口，默认使用 TCP 协议。注意，-l是监听模式，传统 GNU 版必须配-p指定端口；如果是在 Ubuntu 的 OpenBSD 版上，可以直接nc -l 8888。
然后在机器 B 上发起连接：
# 机器 B nc -v -w 3 192.168.1.10 8888如果连接成功，机器 B 的终端会输出类似Connection to 192.168.1.10 8888 port [tcp/*] succeeded!的信息，并且两边都会进入交互状态——你在任意一边输入文字，回车后另一边就能看到。如果连接失败，会出现connection refused或timed out两种典型报错，前者说明端口没监听或防火墙直接拒绝，后者说明包根本没到达对端，大概率是网段不通或安全组策略拦截。
这一步成功以后，我做的第一件事就是在两边各截一张图：机器 A 显示监听态，机器 B 显示连接成功。这两张图是整个实验的基础证据，后续所有操作的前提都是这一步通过。
3.2 第二步：文本消息互发
TCP 连接建立后，最简单的验证是直接传文本。机器 A 保持监听状态，机器 B 连接后输入一句话，比如hello from B，机器 A 的终端会立刻显示出来。反过来也一样，机器 A 输入的文字会显示在机器 B 的终端上。
这里要解释一下原理：Netcat 把标准输入和标准输出直接映射到了网络 socket 上。你在键盘上敲的每个字符，经过系统标准输入进入 Netcat，Netcat 把它打包成 TCP 数据段发出去；对端 Netcat 收到后写到自己的标准输出，也就是终端屏幕。这就是“网络管道”的含义。
这个阶段有一个容易被忽略的点：默认情况下，Netcat 传输数据是没有加密的，局域网内测试问题不大，但在不可信网络上传输敏感内容属于裸奔。可以用 Wireshark 抓包看一下，数据段里直接就是明文。所以我在笔记里专门标注：Netcat 只适合做调试和临时传输，不能替代 SSH 这类加密通道。
3.3 第三步：文件传输实验
文本互通没问题后，我开始尝试传文件。这是 Netcat 用得最多的场景之一。接收端将网络数据导入文件，发送端把文件内容导向网络连接。
先启动接收端（机器 A）：
# 机器 A nc -l -p 8888 > received_file.tar.gz然后启动发送端（机器 B）：
# 机器 B nc -w 3 192.168.1.10 8888 < local_file.tar.gz注意发送端这里我加了-w 3，意思是当标准输入读取到 EOF 后最多等待 3 秒就关闭连接。这个参数很关键，不加的话，接收端的 Netcat 会一直等连接关闭，可能卡在那里不退出。
传输完成后，接收端需要校验文件的完整性：
# 分别核对两端文件哈希 md5sum original_file.tar.gz received_file.tar.gz sha1sum original_file.tar.gz received_file.tar.gz我实测传输几十 MB 的文件，在局域网内速度非常快，基本是磁盘读写速度的上限。哈希一致说明文件没有损坏。这里要特别提醒：如果传的是二进制文件（安装包、压缩包、图片），不要在中间环节做任何换行符转换；Netcat 本身不转换，但如果你用的是某些文本传输工具（比如老的 FTP 的 ASCII 模式），二进制文件就可能损坏。Netcat 没有这个坑，传进去什么就是什么。
3.4 第四步：目录实时传输（tar 管道组合）
单个文件传输成功以后，我想验证更进一步的需求：传整个目录，并保持文件权限和目录结构。Netcat 本身不具备打包能力，但它可以和 tar 配合：tar 把目录打包成字节流，Netcat 把字节流通过网络发出去，接收端再用 tar 解包。
接收端（机器 A）先跑：
# 机器 A nc -l -p 8888 | tar xzvf -发送端（机器 B）执行：
# 机器 B tar czvf - /path/to/dir | nc -w 3 192.168.1.10 8888注意管道方向：tar czvf -的最后一个-表示输出到标准输出（而不是文件），管道把它交给nc，nc发到网络；接收端nc从网络收到数据后，管道传给tar xzvf -，-表示从标准输入读取并解压。
这个组合非常实用，相当于在没有 rsync 的情况下快速同步一个目录。我在实测中传了一个包含几百个文件的网站目录，解压后文件权限基本保留，只有属主和属组因为两边用户体系不一致而不同（比如发送端是 root，接收端当前用户是普通用户）。如果需要严格保持属主属组，接收端必须用 root 身份来解压，并且发送端 tar 要加--same-owner参数。
3.5 第五步：端口扫描与批量探测
除了监听和传输，Netcat 还可以做端口探测。这个功能用来验证某台机器开了哪些端口，或者某一批端口是否可达。命令格式是：
# 扫描 192.168.1.10 的 20-80 端口 nc -zv -w 1 192.168.1.10 20-80这里-z是 zero-I/O 模式，只发送连接请求，不传输实际数据；-v是详细输出，会打印每个端口的结果；-w 1是每个端口等待 1 秒超时。扫出来的结果会显示哪些端口是 open 的，哪些是 closed 的。
批量扫描多个主机也可以，直接列 IP 地址：
nc -zv -w 1 192.168.1.10 192.168.1.20 192.168.1.30这个功能在排查网络策略时很高效。比如我怀疑某个端口被防火墙拦了，用nc -zv一测就知道结果，比 telnet 好用（telnet 在部分系统上还没安装）。但要注意，频繁扫描大量端口可能触发安全设备的告警，生产环境慎用，建议只在自己可控的测试网段操作。
4. 使用手册：常用场景直达区与截图区说明
4.1 高频命令速查表
为了方便复盘和后续查阅，我把这次实验中验证过的命令整理成了速查表。每条命令都标注了适用版本，避免换台机器就踩参数坑。
| 场景 | 命令（监听端 A） | 命令（连接端 B） | 说明 |
|---|---|---|---|
| 验证 TCP 端口 | nc -l -p 8888 | nc -v -w 3 192.168.1.10 8888 | 连接成功后可直接输入文本 |
| 验证 UDP 端口 | nc -u -l -p 8888 | nc -u -v -w 3 192.168.1.10 8888 | UDP 无连接，需要两边配合 |
| 传文件 | nc -l -p 8888 > file | nc -w 3 192.168.1.10 8888 < file | 适合单文件，接收端后启动 |
| 传目录 | nc -l -p 8888 | tar xzvf - | tar czvf - dir | nc -w 3 192.168.1.10 8888 | 目录会打包成字节流 |
| 简易聊天 | nc -l -p 8888 | nc 192.168.1.10 8888 | 双向实时文本，仅限调试 |
| 端口扫描 | nc -zv -w 1 192.168.1.20 20-80 | 无需监听端 | 批量探测端口状态 |
| 收 HTTP 响应 | printf 'GET / HTTP/1.1\r\nHost: a.com\r\n\r\n' | nc -w 5 a.com 80 | 无需监听端 | 手动构造 HTTP 请求 |
提醒一下：表里的 IP 和端口只是示例，实际使用时换成你自己的地址。UDP 测试比 TCP 麻烦一点，因为 UDP 本身不保证送达，两边接收输出可能不直观，建议用-v辅助确认。
4.2 截图区应该记录什么
原笔记里的“截图区”对应的是实验过程中的关键界面记录。虽然这里没法直接放图，但我把每张截图应该拍什么、为什么拍这张列出来，你实际操作时可以对照着留档，方便以后回溯问题。
第一张：监听端开启成功时的终端界面。记录点包括：完整的nc命令、监听端口、没有任何报错输出。这张图能证明监听动作已经生效。
第二张：连接端发起连接成功后的界面。记录点包括：Connection to ... succeeded字样、连接耗时、命令执行前的状态。这张图是验证 TCP 连通性的核心证据。
第三张：双向文本互发的场景。左边窗口显示从客户端收到的消息，右边窗口显示从服务端收到的回复。这张图直观说明数据传输是双向的。
第四张：文件传输前后的文件列表和哈希校验结果。左边是原始文件的ls -l和md5sum，右边是接收文件的同样信息，两张并列才能证明文件内容一致。
第五张：端口扫描结果。记录点包括：探针命令、每个端口的 open/closed 状态、命令执行总时长。这张图能帮你快速发现问题端口。
截图区不是摆设。我后面排查问题时，最常翻的就是这些截图，尤其是文件哈希对比那张，一眼就能定位是不是传输损坏。建议你也养成为每个实验保存截图的习惯。
4.3 NC 与系统工具的搭配技巧
Netcat 单独用已经很方便了，但和系统工具组合起来才是完全体。我在这次实验里还验证了几个组合，分享出来供参考：
nc+pv实现传输进度显示。Netcat 传大文件时没有进度条，看起来很着急。用pv管道包一层就能看到速度和进度：
# 接收端 nc -l -p 8888 | pv -b > received_file.iso # 发送端 pv local_file.iso | nc -w 3 192.168.1.10 8888pv没有的话，CentOS 可以通过yum install -y pv安装，Ubuntu 是apt-get install -y pv。
nc+dd实现裸盘镜像传输。如果要做磁盘备份或恢复，Netcat 可以把分区数据直接导到另一台机器：
# 接收端（目标机） nc -l -p 8888 | dd of=/dev/sdb bs=4M status=progress # 发送端（源机） dd if=/dev/sda bs=4M | nc -w 3 192.168.1.20 8888这个操作非常猛，相当于整个磁盘对拷，一定要确认接收端的设备名写对了，不然会把别人的盘覆盖掉。我在笔记里用红色标注：这个命令建议只在测试环境跑，生产环境除非明确知道后果，否则别碰。
nc+sleep实现简单的延迟探测。用sleep 1模拟慢速连接，可以测试对端在慢速场景下的行为：
# 监听端 nc -l -p 8888 | while read line; do echo "[$(date +%s)] $line"; done # 连接端 for i in $(seq 1 5); do echo "message $i"; sleep 1; done | nc 192.168.1.10 8888这组合的作用是验证对端服务是否能处理慢速到达的数据，排查数据积压和缓冲问题。
5. 踩坑记录与排查思路
5.1 连接超时：先查防火墙再查网段
实验过程中最典型的问题是连接端报timed out，不是connection refused。这两个报错有本质区别：refused说明数据包到达了目标机器，但目标端口没人监听或直接被内核拒绝；timed out说明数据包根本没到达目标，或者到达后没有响应。
我遇到的情况是：在机器 A 上启动了nc -l -p 8888，机器 B 执行nc -v -w 3 192.168.1.10 8888，等了 3 秒报timed out。排查步骤：
# 1. 在机器 A 上确认端口是否在监听 netstat -tlnp | grep 8888 ss -tlnp | grep 8888 # 2. 确认防火墙是否放行了端口 iptables -L -n | grep 8888结果发现机器 A 的 iptables 有一条策略，默认 INPUT 链 DROP，只放行了 22 端口，8888 端口被挡了。解法是加入放行规则：
iptables -I INPUT -p tcp --dport 8888 -j ACCEPT这个坑的教训是：先确认监听状态，再确认防火墙，最后确认网段路由。顺序不要反，否则容易被表象带偏。如果目标机器有自己的安全组策略，还需要在云控制台或机房防火墙同步放行。
5.2 监听端口被占用：netstat 和 ss 双确认
有一个坑也和端口有关：我启动接收端时，提示端口被占用。原因是一个之前实验的 Netcat 进程没有正常退出，还占着 8888 端口。排查命令：
# 查找占用端口的进程 netstat -tlnp | grep 8888 ss -tlnp | grep 8888 lsof -i :8888然后 kill 掉老进程：
kill -9 <PID>这里建议用ss而不是netstat，因为 CentOS 6 上 netstat 依赖 net-tools 包，某些最小化系统里根本没装。ss是 iproute2 自带的，基本都有。还有一点，lsof也不是默认安装的，确认有再使用。
5.3 传完文件卡死不退出：加-w超时
文件传输完成后，接收端 Netcat 经常卡在那里不退出。原因是：接收端在等待连接关闭，而发送端没有主动关闭连接。
解法是发送端加-w参数：
# 发送端，文件发完后最多等 3 秒关闭连接 nc -w 3 192.168.1.10 8888 < local_file.tar.gz需要注意-w的时机：它不是在连接建立后立刻超时，而是当标准输入 EOF 后，等待接收端最后一次回包的最长时间。对于 OpenBSD 版本，还可以用-N参数，表示读取到 EOF 后立刻关闭连接，语义更清晰：
# Ubuntu / netcat-openbsd nc -N 192.168.1.10 8888 < local_file.tar.gz如果用的是 GNU 版，没有-N，老老实实用-w就好。
5.4 传的文件损坏：文本模式与二进制模式要分清
有次我用 Netcat 传一个压缩包，接收端解压提示 CRC 错误。一开始以为是网络丢包，后来检查发现是命令里用了重定向方式不当：接收端用nc -l -p 8888 > received.txt没问题，但我当时是在 Windows 环境下用某种终端工具接收，它自动做了换行符转换，导致二进制文件的字节被篡改。
虽然 Netcat 本身不会转换换行符，但如果你的终端、或者中间经过的传输工具（比如某些 Windows 下的 nc.exe 包装器）做了文本处理，就会损坏文件。解决方法是：在接收端严格使用>重定向到文件，不要经过任何文本处理管道；发送端用<从文件读入，不要在中间加 cat 或 echo 之类的文本命令（除非你知道自己在做什么）。
另外，传完文件一定要校验哈希值。图片、压缩包、可执行文件、数据库备份这些内容，只要有一个字节变了，整个文件可能就废了。所以我把 md5sum/sha1sum 校验写进了实验流程的固定步骤，每次传完文件必须做。
5.5 “名字撞车”的坑：NC、ncat、nc.exe 别认错
这个坑不是网络层面的，而是工具命名层面的，但杀伤力极大。搜索 “nc 下载” 时，很容易搜到一堆同名但完全不同的软件：
ncat：Nmap 项目维护的 Netcat 增强版，功能更强但参数和传统 nc 不同；nc.exe：Windows 上常见的 Netcat 移植版，来源庞杂，有些是流氓软件改的，下载需要谨慎；NC Explorer：三菱 CNC 数控系统的文件远程浏览工具，和 Netcat 没有一毛钱关系；- 硬件设计领域的
NC引脚：指的是 Not Connected，比如 AD 原理图设计里用 Variant 区分正常器件和 NC 器件，这里的 NC 是指不焊接/不连接的元件，属于电子设计自动化的概念。
如果对“nc”这个词不敏感，很容易搜到一堆不相干的内容，或者用一个来路不明的 nc.exe 导致安全问题。我的建议是：Linux 下直接用发行版仓库的nc或netcat-openbsd包，Windows 下优先用 Nmap 安装包自带的ncat.exe，或者使用 WSL 里的 Linux 版 Netcat，尽量别从陌生网站单独下载 exe。
5.6 监听在错误的 IP 上：默认只监听所有接口
还有一次，我在机器 A 上执行nc -l -p 8888之后，从机器 B 连接不通，但在机器 A 本机执行nc -v 127.0.0.1 8888又能通。排查半天发现，Netcat 监听时默认绑定的地址是 0.0.0.0，也就是所有接口，按理说应该没问题；但某些版本在指定了-p后行为略有差异，或者系统有 ipv6 禁用策略导致监听绑定在::而不是 IPv4 地址。
解法是显式指定监听地址：
# 监听在 IPv4 所有地址 nc -4 -l -p 8888 # 监听在指定 IP nc -l -p 8888 -s 192.168.1.10-s参数指定源地址，-4强制 IPv4。如果你的网络环境同时有 IPv4 和 IPv6，建议都加上-4，避免监听在 IPv6 地址上导致客户端用 IPv4 连不上。
6. 常见问题速查表
把这次实验里遇到的典型问题、产生原因和解决方式整理成一个表，方便后续排查时快速定位。
| 现象 | 可能原因 | 解决方式 |
|---|---|---|
timed out | 防火墙拦截、网段不通、安全组未放行 | 先检查iptables -L -n、ss -tlnp，再确认网段路由 |
connection refused | 端口没监听，或监听地址不对 | 确认监听进程是否还活着，用ss -tlnp查监听 IP |
命令报错unknown option -- p | 用的是 OpenBSD 版，不需要-p | 改为nc -l 8888，或先看nc -h |
| 传完文件卡住 | 发送端未关闭连接 | 发送端加-w 3（GNU）或-N（OpenBSD） |
| 文件损坏 | 中间环节做了文本转换 | 直接用重定向<和>，传完做哈希校验 |
| 端口被占用 | 之前有残留进程 | ss -tlnp找到 PID，kill -9 |
| 客户端连不上但本机能连 | 监听了 IPv6 地址 | 加-4参数强制 IPv4 |
| UDP 测试没反应 | UDP 无连接特性 | 用-u加-v，两边同时启动才容易成功 |
| 某些 Linux 没装 nc | 最小化安装未包含 | 用发行版包管理器安装，或拷贝静态编译的 ncat |
排查顺序我总结成一句话：先看端口有没有监听，再看防火墙有没有放行，再看地址有没有绑定错，最后看参数有没有因版本不同而失效。按照这个顺序走，90% 的问题都能定位。
最后再分享一点我个人的体会。整个实验做下来，最大的收获不是学会了多少条 nc 命令，而是理解了“网络调试工具的本质是数据管道”这件事。Netcat 的所有用法，无论是传文件、传目录、扫端口还是搭临时服务，本质上都是把 stdin/stdout 和网络 socket 做映射，明白了这个核心概念，遇到没见过的参数组合也能自己推理出来。另外，工具版本差异带来的坑比想象中多，以后再在任何机器上使用 nc，我都会先瞄一眼nc -h，确认是 GNU、OpenBSD 还是 Ncat，避免凭记忆硬怼命令。这份笔记和速查表就是为这个目的沉淀的，希望对你也有用。
