定位 macOS 网络连接耗时需分 DNS 解析、TCP 连接、TLS 协商三阶段：用 time nslookup 测 DNS，time nc -zv 测 TCP，time openssl s_client 测 TLS；networkQuality 则提供端到端 RTT 与 TLS 时序综合视图。
要分析 macOS 中网络连接的建立耗时，关键不是测“网速”，而是定位从发起请求到完成 TCP 握手（或 TLS 连接）之间的时间开销。这个过程常被忽略，但却是网页白屏、App 启动卡顿、API 超时的根源之一。macOS 提供了多层原生工具，可分别捕获 DNS 解析、TCP 连接、TLS 协商三个阶段的耗时。
DNS 解析阶段：用 nslookup + time 看域名转 IP 多久
DNS 延迟高会导致所有后续连接延迟启动。nslookup 本身不直接显示毫秒级响应时间，需配合 time 命令获取真实墙钟时间：
- 在终端中运行：time nslookup github.com 8.8.8.8（指定 Google DNS 避免本地缓存干扰）
- 关注输出末尾的 real 时间（例如 real 0m0.214s），这就是完整解析耗时
- 重复执行 3 次，若 consistently > 300ms，说明 DNS 是瓶颈；可尝试换为 114.114.114.114 或 1.1.1.1 对比
- 加 -debug 参数（nslookup -debug github.com）可查看是否经历多级递归、有无超时重试
TCP 连接阶段：用 telnet 或 nc 测通目标端口要多久
DNS 完成后，系统需与服务器 IP 的指定端口（如 443）建立 TCP 连接。这个“三次握手”是否顺畅，直接影响连接建立速度：
- 运行：time nc -zv github.com 443（nc 即 netcat，-z 表示只扫描端口，-v 显示详情）
- 观察输出中的 Connection to github.com port 443 [tcp/https] succeeded! 及其前的时间戳
- 若出现 Operation timed out 或耗时 > 1000ms，说明路由路径、防火墙或远端服务响应异常
- 对比测试网关（如 time nc -zv 192.168.1.1 80）可判断问题是否出在局域网内
TLS 协商阶段：用 openssl s_client 看加密握手花了多少毫秒
对 HTTPS 网站，TCP 连通后还需完成 TLS 握手（密钥交换、证书验证等）。这一步常被忽视，却可能占总连接耗时 70% 以上：
- 运行：time openssl s_client -connect github.com:443 -servername github.com < /dev/null 2>&1 | grep "Protocol\|Cipher"
- 命令本身不直接输出耗时，但结合 time 可得整体 TLS 建立时间（real 值）
- 若耗时明显高于 TCP 阶段（比如 TCP 仅 40ms，TLS 却达 800ms），可能是证书链长、OCSP 检查慢、或服务器 TLS 配置老旧（如仍用 TLS 1.0）
- 加 -debug 参数可查看每轮交互细节，定位卡在 Certificate、KeyExchange 还是 Verify 步骤
端到端整合：networkQuality 提供带宽+RTT+连接稳定性综合视图
Apple 官方 networkQuality 工具虽主打测速，但它会自动执行完整 HTTP/HTTPS 连接流程，并在 JSON 输出中给出多个关键时序字段：
- 运行：networkQuality -v（详细模式）
- 关注日志中类似 Starting upload test、Measuring RTT、Completed TLS handshake 的时间标记行
- 最终 JSON 中的 observedMinRTTMs（最小往返时延）、uploadMbps 和 downloadMbps 可交叉验证：若 RTT 很低但吞吐量差，问题可能在服务器或中间链路拥塞；若 RTT 高且波动大，则是网络质量本身不佳
- 该工具默认连 Apple 服务器，也支持自定义目标：networkQuality -s api.example.com -p 443，适合诊断特定业务接口
