企业官网建设流程全解析

1. 先搞清楚 Kali 里那个nc到底是哪一个

很多人第一次在 Kali 里用nc都会经历同一个瞬间：照着某篇教程敲下nc -z 192.168.1.10 22，终端回你一句nc: invalid option -- 'z'，于是开始怀疑人生——是我打错了，还是 Kali 有问题？都不是。问题出在nc这个名字底下藏着至少四套完全不同的程序，它们的参数表互不兼容，而 Kali 又很"贴心"地把选择权交给了 alternatives 机制。

我自己的习惯是，接手任何一台新装的 Kali（或者任何 Debian 系发行版），第一个动作不是直接开敲，而是先问清楚"这台机器上的 nc 是谁"。

1.1 同名不同源的四个 netcat 分支

把家谱理一遍，后面所有的报错你都能自己解释：

这四个东西在功能上覆盖度大概是这样：Ncat ⊃ OpenBSD netcat ⊃ GNU netcat ≈ traditional。功能越往后越少，但"少"不等于"不好用"——traditional 版本因为没有多余选项，体积极小，很多精简镜像里只有它。

真正让人抓狂的点在于：它们都叫nc，-h帮助信息还都长得有点像，但选项列表完全不是一回事。你在 A 机器上跑通的命令，换到 B 机器可能直接报错，这不是玄学，是包管理器的选择。

1.2 用 update-alternatives 确认你机器上的 nc 指向谁

Kali 里nc通常是一个软链接，由 Debian alternatives 系统管理，所以一行命令就能看到真相：

# 看当前 nc 指向哪个实现，以及有哪些候选 update-alternatives --display nc # 交互式切换（装了多个实现时才有多个选项） sudo update-alternatives --config nc # 不想切来切去，直接看链接链路 ls -l /usr/bin/nc readlink -f /usr/bin/nc

如果你想要 OpenBSD 版本，装包之后 alternatives 会自动注册：

sudo apt update sudo apt install netcat-openbsd update-alternatives --config nc

我个人的建议是：如果你主要做日常调试，直接装ncat（sudo apt install ncat），然后把nc切到 OpenBSD 版。理由是日常用得最多的-z、-k、-N三个参数，traditional 版本一个都没有；而真需要 Ncat 独有能力（加密、多客户端）时，直接敲完整的ncat命令，意图更明确，也不会因为 alternatives 切换导致脚本行为漂移。

提示：写进脚本的命令，永远不要依赖nc这个名字的默认指向。要么在脚本开头做一次版本探测，要么直接用/usr/bin/nc.openbsd这类全路径。我踩过一次坑——同一份巡检脚本在三台机器上表现不一致，最后发现其中一台的 nc 被切换到 ncat，-w的超时语义变了，导致探测结果忽早忽晚。

1.3 那几个最容易翻车的参数差异

把差异落实到具体使用上，下面这几条几乎每天都会遇到：

• -p的含义不一样。traditional 版本里nc -l -p 1234是标准写法；OpenBSD 版本里-p是"指定源端口"，监听直接写nc -l 1234。
• -z只有 OpenBSD 和 Ncat 有。traditional 版本没有，遇到invalid option -- 'z'就知道该换实现或者换写法了。
• -N和-q的取舍。-N是"stdin 读到 EOF 后就关闭套接字"，OpenBSD 和 Ncat 支持；-q 秒数是 GNU 系的写法。功能相近，但不要混着用。
• -e的可用性。traditional 和部分 GNU 版本支持-e，OpenBSD 版本刻意移除了它（原因很直白，这个参数太容易被滥用）。Ncat 用--exec/--sh-exec替代。

2. 把"监听 / 连接"这一对动作练到形成肌肉记忆

netcat 的所有用法，本质都可以拆成两个角色：一端 listen，另一端 connect。剩下的一切——传文件、聊天、抓 banner、当临时服务——都是在这对动作之上叠输入输出重定向。理解了这一层，你就不需要背参数了。

2.1 最小可用的两条命令

开两个终端，或者两台机器，先跑一遍这个：

# 终端 A：监听 1234 端口 nc -lvnp 1234 # 终端 B：连过去 nc 127.0.0.1 1234

然后随便打字，两边回车，你会看到文字在对面出现。这就是 netcat 的全部魔法：它把 TCP 连接的两端直接接到了 stdin/stdout 上。没有协议，没有握手，没有分帧，你敲什么就发什么，收什么就显示什么。

如果nc -lvnp 1234在你的机器上报错，先别急，换成你那个实现对应的写法：

• traditional：nc -l -p 1234 -v
• OpenBSD：nc -lv 1234
• Ncat：ncat -lv 1234

-v这个参数值得一提。它会把连接建立和关闭的信息打在标准错误上，方便你确认"对面到底连上来没有"。生产脚本里我一般保留-v，把 stderr 重定向到日志，这样出问题时有迹可循。

2.2 为什么你的-l加上-p会报错

这是新手最常见的困惑之一。原因很简单：-p在 OpenBSD 版本里不是"监听端口"的意思，它的定义是"指定本地源端口"，用于主动连接时绑定出口端口。所以当你写nc -l -p 1234的时候，OpenBSD 版本的解析逻辑会觉得你同时给了两个矛盾的指令，直接报错退出。

判断方法很土但是很好用：

# 直接问它自己 nc -h 2>&1 | head -30 ncat --help | head -30

看帮助里有没有-p和-l同时出现的用法示例。有，就是 traditional 或 GNU；没有，就老老实实nc -l 1234。

提示：我见过有人在脚本里写nc -l -p $PORT，然后在开发机上跑得好好的，一到 CI 容器里就挂。原因就是两个环境的 nc 实现不同。这类"环境相关"的报错，八成都能归到这一节。

2.3 会话什么时候结束：EOF、Ctrl+C、-N、-q的区别

这个问题看着小，实际影响巨大，尤其是批量传文件的时候。

默认行为是这样的：当一端的 stdin 关闭（EOF）时，netcat 会把剩余数据发完，然后关闭连接；另一端收到对端关闭，读取循环退出，程序结束。听起来很合理，但有两个容易翻车的细节：

第一个细节是-l模式下的退出时机。traditional 版本的nc -l -p 1234在连接关闭后就直接退出，只服务一个客户端；OpenBSD 版本需要-k才会持续监听。如果你写了个接收端脚本，以为它会一直等着，结果只收到第一份文件就退出了，多半就是这个原因。

第二个细节是半关闭。有些场景（比如管道对管道）需要"我发完了但我还要读"的状态。这时候：

# OpenBSD / Ncat：stdin EOF 后直接关闭套接字，不做半关闭等待 nc -N 127.0.0.1 1234 < file.bin # GNU 系：等待 1 秒让对端把数据吐完再关 nc -q 1 127.0.0.1 1234 < file.bin

Ctrl+C是强杀，会直接把连接掐掉，对端可能收到 RST。给对端发大文件时如果提前 Ctrl+C，对面拿到的是个残缺文件，而且不会报错——这是最恶心的一类"静默失败"。所以我的做法是：传输类操作一律不用 Ctrl+C 结束，而是让 stdin 自然 EOF。

2.4 UDP 模式的隐式规则

加个-u就走 UDP：

# 接收端 nc -u -l 1234 # 发送端 echo "hello udp" | nc -u 127.0.0.1 1234

UDP 下有三条不成文的规则要记住。第一，netcat 不做重传，丢包就是丢包，别指望它可靠；第二，接收端看到的是一个个独立数据报的边界，不会像 TCP 那样被粘在一起；第三，很多实现里-l -u只处理第一个来源，来自其他地址的包会被忽略，这在多客户端场景下会让人困惑。

我的实际经验是：UDP 用 netcat 只适合一次性验证"包能不能到"。比如排查 syslog 有没有发出来、SNMP trap 有没有上报、某个自研服务的 UDP 端口通不通。真要做持续的数据接收，老老实实写个十几行的 Python 脚本更省心。

3. 文件传输：不用 scp 也能把东西搬过去

netcat 传文件这件事，价值不在于"比 scp 快"（大多数情况下并不快），而在于它几乎是所有环境里都存在的那个最小公约数。当你面对一台没有 sshd、没装 curl、只有 busybox 的环境时，netcat 往往是你唯一的选择。

3.1 单向接收的标准姿势

记住一个口诀：接收端先监听，发送端后连接。顺序反了就连不上。

# 接收端（先执行） nc -l -p 9999 > received.tar.gz # 发送端（后执行） nc 192.168.1.20 9999 < source.tar.gz

这里有个非常隐蔽的坑：shell 的重定向>会在 nc 启动之前就把目标文件创建出来。如果连接因为防火墙原因一直没建立，你会看到一个 0 字节的received.tar.gz，然后以为"传过去了但内容是空的"。所以在脚本里，我习惯在>之后加一个校验步骤，而不是看到命令返回就认为成功。

另一个坑是-w超时和文件大小的关系。-w 3在某些实现里的语义是"连接建立超时"，在另一些实现里是"空闲超时"。如果你要传一个 2GB 的镜像，中间有几分钟没有新数据流（比如磁盘写入慢导致背压），空闲超时可能会把连接掐断。测大文件时一定把超时放宽，或者干脆不加。

3.2 用 tar 管道一次搬走整个目录

单个文件用上面那套就行，但现实中更常见的是"把整个目录搬过去"，这时候直接上管道：

# 接收端 nc -l -p 9999 | tar xzv # 发送端 tar czf - ./myapp | nc 192.168.1.20 9999

这条命令的妙处在于没有中间文件：tar 一边打包一边写 stdout，netcat 一边读一边发，接收端一边收一边解。整个过程占用的临时空间几乎为零，对磁盘紧张的机器特别友好。

但要注意，这条管道是"边传边解"，一旦中途断了，你会得到一个解了一半的目录，而且很难判断断在哪。我的做法是分两步：先传压缩包，校验完再解。多花一点时间，但失败时状态是干净的。

如果确实要一步到位，至少把-v加上：

nc -l -p 9999 | tar xz # 静默解包，快但没反馈 nc -l -p 9999 | tar xzv # 每个文件打一行，方便事后比对

3.3 传输校验：不做这一步等于没传

netcat 本身没有任何完整性校验。TCP 的校验和只能保证"传输过程中没被破坏"，但保证不了"你发的和我收的是同一份东西"——比如发送端读文件读到一半被 kill，接收端会拿到一个看起来完整、实际被截断的文件。

所以校验这一步必须做，而且方法要选对：

# 发送端：先算，再传 sha256sum source.tar.gz nc 192.168.1.20 9999 < source.tar.gz # 接收端：收完再算，两个哈希对比 sha256sum received.tar.gz

对于大文件或者批量文件，一次性手工比对太累，可以这样做：

# 发送端：生成清单并一起传过去 find ./data -type f -exec sha256sum {} \; > manifest.sha256 tar czf - ./data manifest.sha256 | nc -l -p 9999

提示：如果传输通道不可靠（比如跨广域网的链路），别用 netcat 硬扛。它的设计目标从来不是可靠传输。这种场景要考虑带断点续传的工具，netcat 只适合"同机房、内网、一次成功"这类场景。

3.4 传不过去时，按这个顺序查

传输失败基本都逃不出这几个原因，按这个顺序排查效率最高：

4. 端口存活探测与"手动打招呼"

这一节说的都是对你自己的机器、自己的实验环境做自检。在没有明确授权的情况下扫别人的机器，不管工具多轻量，性质都是一样的——这条线必须画清楚。

4.1-z的适用边界

-z的意思是"只探测，不发送数据，也不等回应内容"，配合-v就能拿到一行干净的结果：

nc -zv 127.0.0.1 22 nc -zv 127.0.0.1 1-1024 nc -zv -w 2 127.0.0.1 80 443 8080

用它能干的事其实很有限：确认本机某个服务有没有起来、确认两台自管机器之间的某条链路通不通、确认容器映射的端口有没有生效。这些场景下它比nmap轻得多，启动快，输出干净，非常适合塞进脚本里。

但它不适合做的事也很明确：不要用它做大范围扫描。原因有两个层面。技术层面，netcat 的探测是串行的，扫 65535 个端口会非常慢，还有可能因为瞬时大量连接被对端的防护机制记录。使用层面，超出授权范围的扫描行为，无论用什么工具都是不应该做的。

4.2 手动打招呼：抓 banner 的正确写法

很多时候你需要的不是"端口开没开"，而是"这个端口上跑的是什么"。这时候直接连上去看它说什么就行：

# HTTP：注意 HTTP/1.1 必须带 Host 头，\r\n 一定要是回车换行 printf 'GET / HTTP/1.1\r\nHost: 127.0.0.1\r\nConnection: close\r\n\r\n' | nc -w 3 127.0.0.1 80 # SSH：连上就能看到协议版本行 nc -w 3 127.0.0.1 22 # SMTP：手工走一遍对话 nc -w 3 127.0.0.1 25

这里有两个我踩过很多次的经验点。

第一，\r\n不能写错。用echo拼接的话，很多 shell 只会给你一个\n，某些服务对着一行残缺的请求头就默默不回应，让你误以为是网络问题。用printf显式写\r\n才靠谱。

第二，记得加Connection: close。否则 HTTP/1.1 默认长连接，服务端回完响应不关连接，你的 netcat 就一直挂在那里等，看着像卡死了。加了这个头，服务端回完主动关闭，命令自然返回。

还有一个更省事的替代方案——如果这台机器上有 curl，就别折腾 netcat 了：

curl -v --max-time 3 http://127.0.0.1/

我现在的判断标准是：需要精确控制请求字节的时候用 netcat，只是看一眼服务回什么就用 curl。前者能让你看到原始响应（包括那些 curl 会帮你解析掉的分块编码），后者省事。

4.3 拿/dev/tcp和 netcat 做个对比

Bash 内置了一个很多人不知道的功能，可以在不依赖任何外部程序的情况下做 TCP 连接：

# 探测端口是否可连 timeout 2 bash -c '</dev/tcp/127.0.0.1/22' && echo "open" || echo "closed" # 发一个请求 exec 3<>/dev/tcp/127.0.0.1/80 printf 'GET / HTTP/1.0\r\n\r\n' >&3 cat <&3 exec 3<&-

/dev/tcp的最大优势是零依赖——只要 shell 是 bash，就能用。缺点也很明显：报错信息非常不友好，连接失败时只会给你一个模糊的失败退出码，不像 netcat 会告诉你Connection refused还是Connection timed out。

我的实际选择是：写正式脚本用 netcat，因为错误信息可读性好；做极简环境下的兜底探测用/dev/tcp。

4.4 把探活写进脚本的完整例子

这是我在实际运维里反复用过的一个模板，结构简单但足够健壮：

#!/usr/bin/env bash set -uo pipefail TARGETS=( "127.0.0.1 22 ssh" "127.0.0.1 80 http" "127.0.0.1 5432 postgres" ) fail=0 for item in "${TARGETS[@]}"; do read -r host port name <<<"$item" if nc -z -w 2 "$host" "$port" >/dev/null 2>&1; then echo "[OK] ${name} ${host}:${port}" else echo "[FAIL] ${name} ${host}:${port}" fail=$((fail + 1)) fi done exit "$fail"

这段脚本有几个刻意的设计。set -uo pipefail保证变量未定义和管道失败能被发现；-w 2给每次探测一个明确的超时上限，避免某个目标不响应导致整个脚本挂住；退出码等于失败数量，这样上层调度系统可以直接根据退出码决定要不要告警。

提示：如果这段脚本要跑在不确定 nc 实现的机器上，把nc -z -w 2换成timeout 2 bash -c "</dev/tcp/$host/$port"，兼容性会好很多。这是我在混合环境里的默认做法。

5. Ncat 那些 netcat 做不到的事

如果你装了 nmap，那ncat就已经在你机器上了。它比任何 netcat 分支都多了一整套能力，值得单独拿出来讲。

5.1 用--ssl给会话加一层加密

这是 Ncat 最有价值的特性。传统 netcat 发出去的东西是明文的，只要链路上有人抓包，内容一览无余。Ncat 可以直接把 TLS 套上去：

# 生成一张自签证书（仅用于内网临时测试） openssl req -x509 -newkey rsa:2048 -nodes \ -keyout key.pem -out cert.pem -days 30 \ -subj "/CN=temp-test" # 服务端 ncat -lv 1234 --ssl --ssl-cert cert.pem --ssl-key key.pem # 客户端 ncat --ssl 127.0.0.1 1234

生成的证书是自签的，客户端默认不会验证，所以不需要额外信任配置，这也正好符合"内网临时通道"的定位。

用这套东西要清楚它的边界：它加密的是传输这一层，不解决身份验证问题。也就是说，任何人只要能连上你的端口，就能参与会话。所以 Ncat 的 SSL 模式适合"我知道链路上有抓包风险，想让内容不被直接看到"的场景，不适合当正式的服务入口。

5.2--broker做临时多人群聊

默认的 netcat 是一对一的，第二个客户端连上来会被拒。Ncat 的--broker模式解决了这个限制：

ncat -l 1234 --broker --keep-open

之后多个客户端同时连上同一个端口，每个人发的消息会广播给其他所有人。我用它做过几次临时协作：几个人同时在一台跳板机上排查问题，把各自的输出贴进这个会话里，比来回复制粘贴高效得多。

不过要清楚它的局限：broker 模式不提供任何回放，后来的人看不到之前的消息；也不提供身份标识，看不出谁是谁。它的定位就是"临时、短时、在场的人都在看"的同步沟通。

5.3--exec/--sh-exec：能力强但也最危险

这两个参数让 Ncat 可以把一个连接直接接到某个进程的标准输入输出上：

# 连接建立后执行指定命令，把输出发给客户端 ncat -lv 1234 --exec "/usr/bin/uptime" # 通过 shell 执行（支持管道和重定向，但风险更高） ncat -lv 1234 --sh-exec "df -h | head -5"

--exec有一个非常明确的好用途：做一个几十秒钟的一次性微服务。比如临时给同事提供一个查询接口，又不想写代码、不想起 web 服务，--exec就够了。

但必须把话说重一点：这类参数是历史上最经典的远程控制原语之一。如果你把--sh-exec "/bin/bash"这种写法暴露在任何可达的地址上，等于把机器的控制权开放给所有能连上这个端口的人，而且连密码都不需要。所以我的规矩很死：

• 只在自己的隔离实验环境里用，绝不在任何共享网络或对外的机器上开
• 监听地址显式绑到127.0.0.1，不要用0.0.0.0
• 用完立刻 Ctrl+C 关掉，不要挂在后台过夜

# 安全些的写法：只绑本地回环，配合 --allow ncat -lv 127.0.0.1 1234 --allow 127.0.0.1 --exec "/usr/bin/uptime"

5.4--keep-open、--idle-timeout与--allow

这三个参数组合起来，能把一个临时端口变成"勉强够用的轻量服务"：

• --keep-open：处理完一个连接后继续监听，而不是退出。这是做数据接收端必备的。
• --idle-timeout：空闲多久自动断开，防止僵尸连接占着不释放。
• --allow：只允许来自指定地址的连接，做最简单的访问控制。

# 一个可持续接收数据的端口，只接受同网段来源，空闲 60 秒自动断开 ncat -l 9999 --keep-open --idle-timeout 60 --allow 192.168.1.0/24 >> received.log

这段命令我用过很多次，专门用来接收一些内部设备上报的轮询结果。它的好处是不用写代码、不用起服务、不用配权限，一条命令就能开始收数据；坏处是没有并发处理能力，多个客户端同时连上来会排队或被拒，日志格式也没有任何结构化保证。

6. 把 netcat 串进日常工作的几种组合

工具本身没什么特别，价值在于组合。下面这几个是我在实际工作中反复使用的模式。

6.1 临时调试 HTTP 接口的完整过程

当需要看清服务端到底回了哪些原始字节时，我固定用这套：

# 第一步：确认端口是活的 nc -zv 127.0.0.1 8080 # 第二步：手工发一个最小请求，观察原始响应 printf 'GET /health HTTP/1.0\r\n\r\n' | nc -w 5 127.0.0.1 8080 | head -40 # 第三步：需要看响应头里某个字段是否存在 printf 'GET /health HTTP/1.0\r\n\r\n' | nc -w 5 127.0.0.1 8080 | grep -i '^content-type'

为什么用HTTP/1.0而不是1.1？因为 1.0 默认短连接，服务端回完就关，netcat 自然退出，不需要额外加Connection: close。调试的时候少一个变量就少一个坑。

对比一下同一件事用 curl 和用 netcat 的差别：

我的经验是：功能验证用 curl，协议层排查用 netcat。遇到过几次响应体看起来正常、但抓包显示有额外字节的情况，都是靠手工发请求定位到的。

6.2 把 netcat 当接收端收日志或指标

有些设备只能往外发数据，配置项少得可怜，不能指定目标为标准的日志服务。这种情况用 ncat 起个接收端最省事：

# 持续接收，带时间戳落盘 ncat -l 9999 --keep-open --idle-timeout 120 \ | while IFS= read -r line; do printf '%s %s\n' "$(date -Is)" "$line" done >> /var/tmp/incoming.log

这个模式我已经用了很久，有两处细节值得说明。第一，--keep-open必须加，否则第一个连接断开后端口就没了，后面的数据全丢。第二，外层用while read加时间戳而不是直接>>追加，是因为上游设备很少在每行里带时间，事后排查时没有时间戳基本没法对齐。

要提醒的是，这个方案不适合高并发场景。日志接收端一旦有几十个来源同时上报，单进程的 ncat 会成为瓶颈，写入也可能出现行交错。真到那个规模，就该上正经的日志收集组件了。

6.3 一份我在动手前的自查清单

养成开工前过一遍清单的习惯，能省掉大量返工：

• 确认实现：update-alternatives --display nc，知道自己在跟哪个版本打交道
• 确认方向：接收端先起，发送端后连，别搞反
• 确认地址：监听绑0.0.0.0还是127.0.0.1，决定了谁能连进来
• 确认端口：ss -lntp | grep <port>先看一眼有没有被占
• 确认超时：探测类加-w，传输类不加或放宽
• 确认校验：二进制传输一定对比哈希，不看文件大小
• 确认收尾：临时端口用完就关，尤其是带执行能力的那些

7. netcat 不按预期工作时的排查路径

最后一节留给排错。netcat 的报错信息通常很少，所以有一套固定的排查顺序很重要。

7.1 监听起不来：先查端口占用和权限

# 端口是不是已经被占了 ss -lntp | grep ':1234' # 谁占着 sudo lsof -i :1234 # 低于 1024 的端口需要特权 sudo nc -l 80

Address already in use是最常见的报错，绝大多数情况是上一个 netcat 进程还在后台。这时候pkill -f 'nc -l'比一个个找 PID 快得多。另一个容易忽略的点是权限：1024 以下的端口需要 root，用普通用户去监听会直接失败，而且报错信息有时候含糊得让人摸不着头脑。

7.2 连不上但端口明明在监听

这种情况说明问题不在 netcat，而在网络层或访问控制。按这个顺序查：

# 从本机连本机，测试程序本身 nc -zv 127.0.0.1 1234 # 从本机连自己的对外地址，测试绑定是否是 0.0.0.0 nc -zv <本机对外IP> 1234 # 看防火墙规则 sudo iptables -L -n | head -30 sudo nft list ruleset 2>/dev/null | head -30 # 看链路是否可达 ping -c 2 <目标IP> traceroute -n <目标IP>

判断逻辑很清楚：本机连本机通、对外地址连不通，说明监听地址绑定错了（绑在127.0.0.1上了）；本机都能连、远端连不上，问题在链路或访问控制。这个二分法能快速把范围缩到一半。

7.3 数据卡住不动：多半是缓冲问题

有一类问题特别迷惑：连接建立了，命令没报错，但两边都不动，像死机一样。原因通常是标准输入输出被缓冲了，而不是网络问题。

典型的触发场景是通过管道喂数据给 netcat，比如：

# 可能卡住：somecmd 的输出被缓冲，netcat 收不到 somecmd | nc 127.0.0.1 1234 # 更贴着线的方式：先把数据落到文件，再一次性发 somecmd > /tmp/payload nc 127.0.0.1 1234 < /tmp/payload

当somecmd检测到输出不是终端时，很多程序会切换到全缓冲模式，攒够几 KB 才写一次。如果数据量小，看起来就是"发出去了但对面没收到"。解决办法有三个：给somecmd加一个强制行缓冲的选项（比如stdbuf -oL somecmd）、换成先落盘再发、或者把数据量凑够触发刷新。

我自己偏好第二种——多一次落盘，少一次玄学。中间文件还能拿来复现问题，值。

7.4 参数报错速查

最后整理一张表，遇到invalid option就对着查：

这张表覆盖了我过去几年遇到过的大部分参数类报错。如果遇到表里没有的，第一反应应该是nc -h 2>&1 | head -40，把帮助翻出来看——不同实现的帮助信息差异很大，但总比猜快。

我个人在实际操作中的体会是，netcat 这类工具的价值恰恰在于它"不聪明"：它不解析协议、不做重传、不猜你的意图，只负责把字节从一个地方搬到另一个地方。正因为如此，它才不会在关键时刻掉链子——它没有依赖，没有配置，没有版本升级带来的行为变更（前提是你不依赖nc这个名字）。把它的能力边界记清楚，把它当成一把螺丝刀而不是电钻来用，它就能一直在你的工具箱里待下去。