TCPing测的不是下载速度？多节点拨测还原真实加载差异

我以为 TCPing 能测速度

看到「TCPing」这个名字，我一开始把它当成 TCP 版的测速，觉得数字越小越快。后来才明白，它只做一次握手，根本没传数据。

握手快，只能说明「门开得及时」，说明不了「屋里搬东西快不快」。只看这一个数字，你会以为整条链路都好，其实它只覆盖了最开始那一下。

它测的是这一下握手

客户端发 SYN，服务端回 SYN-ACK，握手完成。TCPing 记录的就是这一来一回的时间。

没有 HTTP 请求，没有响应体，也没有下载。它验证的是端口可达、握手是否成功、握手要多久。

这已经很有用：服务器禁 ICMP 时，TCPing 能绕过限制，证明端口是通的。

网站测速：多站点分段耗时与状态码

握手快，传输慢，怎么同时成立

握手只跑一个来回，传输要跑很多个来回，还受窗口大小、拥塞控制、丢包率影响。

带宽和延迟是两回事。链路又远又不丢包，握手时间固定；一旦有丢包，传输速率会掉得比握手时间明显得多。

大文件、图片、视频，这类传输对丢包尤其敏感，TCPing 完全反映不出来。

还有 MTU 和链路抖动：握手包很小，未必暴露问题，传大包时才开始丢。

什么时候该用 TCPing

确认端口通不通，尤其是 80、443 以外的端口。

对比不同地区到某个端口的握手耗时，判断线路质量。

目标禁 ICMP 时，用它替代 ping 做连通性检查。

这几种场景，它比页面测速更快、更直接。测的时候记得指定端口，不同端口可能被不同策略对待。

什么时候必须回到页面测速

要看真实交付，就得走完整条链路。用宝塔拨测的网站测速跑多地区多运营商节点，DNS、TCP、TLS、TTFB、下载五段分开看。

TCP 那段只占其中一部分。TTFB 反映后端，下载段反映带宽和资源，跳转也会额外增加往返。

只看握手，你会漏掉后面所有的等待。页面测速里 TCP 段通常很短，别因为它小就以为不重要——它一旦异常，后面全废。

两个结果怎么对上

我的顺序是：先用 TCPing 确认端口和握手正常，再用页面测速看完整耗时。

如果握手正常、页面慢，重点看 TTFB 和下载段；如果握手本身就慢，先解决线路和端口。

先握手、后页面，顺序别反。握手不通时去测页面，只会得到更多超时。

各自测各自的，别拿一个的数字去解释另一个的结论。两个工具各有用处，记录也最好分开存档。