概念与机制

TCP 连接由四元组区分，服务器能在一个监听端口接受大量不同来源，所以整机连接数不直接受 65535 限制。固定源 IP 反复连接同一目标时，客户端更易耗尽临时端口，TIME_WAIT 与共享 NAT 也会压缩空间。真实瓶颈还有文件描述符、内存、CPU、队列和网卡。

理解“一台主机上只能保持最多 65535 个 TCP 连接吗？”不能停在名词定义，还要找到状态保存位置、报文字段和交互顺序。发送端、接收端、中间设备和应用各自看到的现象并不相同；同一个超时可能来自解析、路由、队列、握手或业务处理。先画最小正常时序，再分别加入丢包、重复、乱序、对端重启等条件，才能理解协议为何需要缓存、确认、窗口或超时，而不是把这些机制当作孤立规则。

实践与误区

验证时先记录目标地址、协议、端口、开始时间和请求标识，再把客户端错误、系统连接状态、网关指标、服务日志和抓包放到同一时间线。单一工具只能证明它实际观察的层次：端口可达不等于应用成功，收到响应也不代表业务数据已持久化。遇到异常应提出可证伪假设，选择能区分不同原因的证据，不要凭一次 Ping、一个状态码或一张抓包截图直接下结论。

工程设计还应明确超时、重试、幂等、容量和可观测性。超时太短会制造误判，太长会拖慢恢复；无上限重试会放大拥塞，非幂等操作还可能重复执行。上线前应写清依赖层次、失败语义和降级边界，保留关键阶段耗时与关联标识，并用可重复实验验证配置。常见误区是把协议提供的传输保证扩大为安全或业务保证；真正可靠的系统需要应用与基础设施共同收尾。