前五篇我们一直在追一份数据包它离开电脑经过路由器一跳一跳走向服务器。假设它终于到了。服务器上可能同时运行着网站、数据库和其他服务网站还可能正在接待成千上万名访客。服务器怎么知道这份数据该交给哪个程序、哪个访客的连接答案要从端口说起。弄懂端口再看 TCP 和 UDP就能明白它们为什么都属于“传输层”却提供了不同的服务。IP 地址只能找到机器把服务器的 IP 地址想成一栋楼的地址大体上是有用的数据可以靠它找到目标机器。但数据到了楼下还得知道交给谁。端口就是操作系统分配和识别网络通信的一种编号。比如一个网站服务可能在 TCP 的443端口等待连接。假设你的电脑向网站发起一次连接你的电脑 192.168.1.20:53142 ↓ 网站服务器 203.0.113.10:443冒号前是 IP 地址冒号后是端口号。这里203.0.113.10指向目标服务器443指向服务器上等待这类连接的服务53142是电脑为这次通信使用的本地端口便于接收返回的数据。服务器回复时方向反过来网站服务器 203.0.113.10:443 ↓ 你的电脑 192.168.1.20:53142如果你记得前一篇的 NAT数据经过家用路由器时来源 IP 和来源端口可能被改写。上图画的是电脑这一侧看到的通信信息不代表互联网上每一跳看到的来源地址都完全一样。端口也不是机器上真实存在的插孔。它是网络协议中的编号由操作系统用来把收到的数据交给相应的网络程序。同一个443怎么接待许多访客服务器上的网站可以一直在443端口等待连接并不需要为每个访客换一个服务端口。来看两位访客访客 A 192.168.1.20:53142 → 服务器 203.0.113.10:443 访客 B 192.168.1.21:53142 → 服务器 203.0.113.10:443两台设备甚至碰巧用了相同的本地端口。服务器仍然能区分因为来源 IP 不同。即使同一台电脑打开多个连接也可以使用不同的本地端口。对于 TCP 连接常用下面四项描述通信双方来源 IP 来源端口 目标 IP 目标端口再加上使用的是 TCP 还是 UDP就能区分不同协议中的通信。这比单说“连接了 443 端口”准确得多端口必须放在 IP 地址和传输协议的上下文里看。你可以把“服务器监听443”理解为它开着一个接待入口进入后的每条通信操作系统仍然能分清是谁和谁在说话。为什么还需要 TCP 或 UDPIP 负责寻址和转发但它并不承诺每个数据包都能到达也不承诺先发的包一定先到。应用程序对传输的要求却不一样。传一份文件时你希望内容完整、顺序正确进行实时通话时迟到几秒的旧声音可能已经没有用应用更关心及时处理当前声音。TCP 和 UDP 给应用提供了两种不同的基础。它们都使用端口但处理数据的方式不同。UDP按一份一份的消息发送UDP 提供的是数据报服务。应用交给它一份消息它把这份消息作为一个数据报发送。接收方如果收到了也能按一份数据报来处理。UDP 本身不先建立 TCP 那样的连接也不负责替应用保证送达、按序到达或丢失后重传。它做得少给上层留下了更多选择。这并不等于“使用 UDP 的应用不可靠”。应用可以自己决定怎样确认、重传或纠错。QUIC 就建立在 UDP 之上另外实现了连接管理、可靠传输等能力HTTP/3 使用的正是 QUIC。所以更准确的说法是UDP自身不提供可靠、有序的传输使用 UDP 的上层协议可以按需要补上这些能力。DNS 查询常使用 UDP但 DNS 也可以使用 TCP。实时音视频也常采用基于 UDP 的方案。不能看见“UDP”两个字就断定它一定是游戏或语音更不能断定它“一定比 TCP 快”。实际速度还取决于应用要实现什么、网络状况如何以及丢包后怎么处理。TCP建立连接交付有序的字节流TCP 提供的是另一种服务可靠、有序的字节流。通信双方先建立连接。传输过程中TCP 会处理编号、确认、重传等问题努力把发送方交出的字节按顺序交给接收方。下一篇会专门拆开讲建立和关闭连接第八篇再讲它怎样处理丢包与拥塞。这里有个很容易被忽略的词字节流。假设程序连续写入两次第一次写入“你好” 第二次写入“世界”接收方不能想当然地认为自己一定会收到两份恰好对应的“消息”。它可能一次读到“你好世界”也可能分几次读到。TCP 保证的是字节顺序不替应用规定“第一条消息在哪里结束第二条在哪里开始”。如果应用需要区分一条条消息就得自己设计边界例如先写明消息长度或者约定分隔方式。HTTP 等应用层协议要处理的正包含这类“这些字节是什么意思”的问题。TCP 的“可靠”也有边界。它能确认数据在连接中被另一端的 TCP 接收不等于网站已经把订单写入数据库更不等于用户重复点击付款时业务只会执行一次。传输成功和业务成功不是一回事。到底该用哪个把两者放在一起看区别就清楚了问题TCPUDP发送前是否建立传输连接是否是否由协议自身处理有序、可靠传输是否交给应用的是什么连续的字节流一份份数据报丢包后的处理TCP 有确认和重传机制由使用它的上层协议决定选用哪个不是按“TCP 稳、UDP 快”二选一。要看应用究竟需要什么以及它愿意自己承担多少传输工作。访问网页就是一个好例子。很多 HTTPS 连接运行在 TCP 之上HTTP/3 则使用建立在 UDP 之上的 QUIC。用户看到的都是网页但底层传输方案可以不同。443也不能脱离 TCP 或 UDP 单独理解TCP443和 UDP443是不同协议中的端口。在电脑上看见真实连接Windows 用户可以打开几个网页再在命令提示符中输入netstat -ano -p tcp在输出中找状态为ESTABLISHED的行。你可能看到类似内容协议 本地地址 外部地址 状态 PID TCP 192.168.1.20:53142 203.0.113.10:443 ESTABLISHED 1234这是示意不是你电脑应当出现的固定地址。试着辨认本地 IP、本地端口、远端 IP、远端端口。最后一列 PID 是进程编号。再运行netstat -ano -p udp你会发现 UDP 的显示方式与 TCP 连接列表不同UDP 没有ESTABLISHED这种 TCP 连接状态。如果你刚打开了网页却没找到对应的 TCP443先别急着判断命令失效。浏览器可能使用了 HTTP/3也可能复用了已有连接连接还可能很快结束。这个练习的重点是读懂一行连接信息而不是保证抓到某个指定网站。今天把从“机器”到“程序”的最后一步补上了IP 帮数据找到目标设备端口帮助设备区分通信TCP 和 UDP 决定应用拿到怎样的传输服务。下一篇我们顺着最常见的 TCP 连接继续问既然要先建立连接为什么大家总说“三次握手”关闭连接时又发生了什么参考资料TCP 规范 RFC 9293、UDP 规范 RFC 768、QUIC 规范 RFC 9000、微软netstat使用说明。