在这里插入图片描述

在前面的网络层系列中,我们讨论了 IP 地址、路由选择、ICMP 和 SDN。网络层能够把一个 IP 数据报从源主机送到目的主机,但数据到达主机以后,问题并没有结束:

同一台主机上可能同时运行浏览器、即时通信软件、网盘客户端和游戏,收到的数据究竟应该交给哪一个应用?

这正是传输层需要解决的问题。

在 TCP/IP 五层模型中,传输层位于应用层与网络层之间。它承接网络层提供的主机到主机通信能力,并把它进一步扩展为应用进程之间的逻辑通信。本篇先建立传输层的整体认识,重点解释端口号,以及传输层最基础的复用与分用机制。

一、网络层找到主机,传输层找到进程

网络层和传输层都在“传输数据”,但二者解决的问题并不相同。

层次 主要解决的问题 主要标识 数据单元举例
网络层 数据应该送到哪台主机 IP 地址 IP 数据报
传输层 数据应该交给主机中的哪个应用进程 端口号等信息 TCP 报文段、UDP 数据报

可以把跨网络通信类比为寄送包裹:

  • IP 地址类似小区地址,负责找到收件人所在的小区;
  • 端口号类似小区内部的房间号,负责进一步找到具体住户;
  • 应用进程就是最终接收或发送数据的住户。

假设一台服务器同时提供网页、邮件和文件传输服务。网络层根据目的 IP 地址把数据送到这台服务器,但仅凭 IP 地址无法判断数据属于哪项服务。传输层还要检查报文段中的端口号等信息,再把数据交给正确的应用。

因此,可以用一句话概括两层的分工:

网络层提供主机到主机的逻辑通信,传输层提供应用进程到应用进程的逻辑通信。

这里的“逻辑通信”并不是说两个进程之间存在一根专用线路,而是说从应用的角度看,数据仿佛直接从发送进程交给了接收进程。实际数据仍然要经过传输层、网络层、链路层和物理层,并穿过中间网络。

二、传输层只存在于通信端系统

传输层协议主要运行在通信的两个端系统中。例如,浏览器和 Web 服务器会处理 TCP 或 UDP 信息,而路径上的普通路由器通常只需要根据网络层信息转发 IP 数据报。

发送端的传输层主要完成以下工作:

  1. 从一个或多个应用进程接收数据;
  2. 添加传输层首部,形成 TCP 报文段或 UDP 数据报;
  3. 把封装后的数据交给网络层。

接收端执行相反过程:

  1. 从网络层接收传输层报文;
  2. 检查首部中的端口号等字段;
  3. 找到对应的套接字;
  4. 将有效载荷交给正确的应用进程。

中间路由器一般不会把 IP 数据报中的应用数据交给本机传输层处理。它的核心任务仍然是查询转发表、选择下一跳并转发数据报。

这种设计让不同层的职责彼此解耦:网络层专注跨网络寻址与转发,传输层专注端到端的进程交付以及所选协议提供的传输服务。

三、传输层主要提供哪些功能?

根据传输层的基本工作,可以将其主要功能归纳为四类。

1. 实现应用进程之间的逻辑通信

这是传输层最根本的作用。网络层只能把数据送到一台主机,传输层继续完成主机内部的最后一步投递,使发送进程能够与另一台主机上的接收进程通信。

2. 复用与分用

一台主机中的多个应用可以共同使用传输层和网络层发送数据,这叫复用;接收端再根据首部信息把数据交给对应应用,这叫分用。

端口号就是实现这种精准交付的核心信息之一。

3. 差错检测

TCP 和 UDP 的首部中都包含校验和字段,用于检测传输过程中报文是否出现比特差错。不过,检测出差错并不等于一定会自动恢复:UDP 通常只是丢弃有差错的数据报,而 TCP 还会结合确认、序号与重传等机制实现可靠传输。

4. 向应用提供不同的传输服务

互联网中最常见的两个传输层协议是 TCP 和 UDP:

  • TCP 面向连接,能够提供可靠、按序的字节流传输,并实现流量控制和拥塞控制;
  • UDP 无连接,只提供较精简的数据报传输服务,不负责确认、重传和按序交付。

TCP 和 UDP 并不是传输层理论上仅有的协议,也不能简单理解为“TCP 一定慢、UDP 一定快”。它们提供的是不同的服务模型,应用需要根据可靠性、时延、开销和控制方式等需求进行选择。

本篇先关注二者共有的基础能力——端口号、复用与分用。它们的具体报文格式和传输机制会在后续文章中逐步展开。

四、端口号是什么?

1. 端口是软件层面的逻辑标识

传输层中的端口不是交换机或路由器上的物理接口,而是操作系统用于区分网络通信端点的逻辑编号。

端口号长度为 16 位,因此取值范围是:

0 ~ 65535

端口号通常可分为三类:

范围 常见名称 典型用途
0~1023 熟知端口 分配给常见的系统级或标准服务
1024~49151 注册端口 可登记给特定应用或服务使用
49152~65535 动态或私有端口 常由客户端临时选择,也可供私有用途使用

例如,常见的约定包括:

  • HTTP 通常使用 TCP 端口 80;
  • HTTPS 通常使用 TCP 端口 443;
  • DNS 通常使用端口 53,并可根据场景使用 UDP 或 TCP。

这些端口是协议或服务的常见约定,并不表示某个应用在任何情况下都只能使用该端口。只要通信双方约定一致并且系统允许,服务也可以监听其他端口。

2. 端口号不等于进程编号

为了便于理解,可以把端口号暂时看作应用的“门牌号”,但它并不是操作系统中的进程 ID,也不是永久绑定给某个应用的固定身份。

更准确地说:

  • 应用进程通过套接字使用网络;
  • 套接字可以绑定本地 IP 地址、传输层协议和本地端口;
  • 操作系统依据这些通信信息,把到达的数据交给对应套接字;
  • 应用进程再从套接字中读取数据。

一个进程可以创建多个套接字,因而可能使用多个端口;一个服务也可能由多个进程或线程协同处理。端口号的作用是帮助操作系统定位通信端点,而不是直接给进程编号。

3. TCP 与 UDP 拥有各自的端口空间

TCP 端口 53 和 UDP 端口 53 属于不同的传输层协议。二者数值相同,但操作系统能够先根据 IP 首部中的协议字段判断应该交给 TCP 还是 UDP,再在相应协议内部根据端口等信息分用。

因此,“某个端口被占用”通常还要结合协议、本地 IP 地址和套接字绑定方式来判断,不能只看一个孤立的端口数字。

五、什么是复用与分用?

复用和分用描述的是同一套机制在发送端与接收端的两个方向。

1. 复用:汇集多个应用的数据

复用发生在发送端。不同应用进程通过各自的套接字把数据交给传输层,传输层为数据添加首部,再统一交给网络层。

浏览器数据 ─┐
聊天软件数据 ├─> 传输层封装 ─> 网络层 ─> 网络
网盘数据   ─┘

这些应用不需要各自拥有一套独立的网络层和物理线路,而是可以复用同一主机的协议栈与网络接口。

发送端大致会经历以下过程:

  1. 应用通过套接字提交数据;
  2. 传输层记录源端口和目的端口等必要信息;
  3. TCP 或 UDP 按各自格式添加首部;
  4. 形成的报文被交给 IP 层发送。

2. 分用:把数据交给正确的应用

分用发生在接收端。接收主机可能从同一个网络接口收到大量数据,传输层必须判断每个报文属于哪个套接字。

网络 ─> 网络层 ─> 传输层检查首部 ─┬─> 浏览器套接字
                                  ├─> 聊天软件套接字
                                  └─> 网盘套接字

其基本过程是:

  1. IP 层根据协议字段,把有效载荷交给 TCP 或 UDP;
  2. TCP 或 UDP 读取报文中的端口号等字段;
  3. 操作系统查找匹配的套接字;
  4. 数据进入对应套接字的接收缓冲区,等待应用读取。

复用解决“多个应用如何共用网络”的问题,分用解决“收到的数据如何各归其主”的问题。二者共同把网络层的主机到主机通信延伸为应用进程到应用进程通信。

六、UDP 和 TCP 的分用方式有什么区别?

UDP 和 TCP 都在首部中携带源端口号与目的端口号,但它们的通信模型不同,操作系统分用数据时使用的信息也不同。

1. UDP:多个来源的数据可以进入同一个套接字

UDP 是无连接的。教材在介绍 UDP 分用时,通常强调接收方主要依据目的 IP 地址和目的端口号找到本地 UDP 套接字。

例如,一台 DNS 服务器在 UDP 端口 53 上接收查询。来自不同客户端 IP、不同客户端端口的 UDP 数据报,都可以被交给服务器上同一个监听该端口的套接字。应用仍然能够从收到的数据中获知发送方地址,以便把响应发回正确客户端。

因此,不能说 UDP 报文“没有源 IP 和源端口”。源 IP 位于 IP 首部,源端口位于 UDP 首部;只是接收端通常不会像 TCP 那样为每个通信对端维护一条独立连接。

2. TCP:用四元组区分具体连接

TCP 是面向连接的。一个已建立的 TCP 连接通常由下面的四元组唯一标识:

源 IP 地址、源端口号、目的 IP 地址、目的端口号

假设一台 Web 服务器监听 TCP 端口 443,两个客户端同时连接它:

客户端 A:203.0.113.10:51001 -> 198.51.100.20:443
客户端 B:203.0.113.11:51001 -> 198.51.100.20:443

两个客户端碰巧选择了相同的源端口 51001,但源 IP 不同,所以四元组仍然不同,服务器可以准确区分这两条连接。

即使连接来自同一台客户端,只要客户端使用不同源端口,也会形成不同的四元组:

203.0.113.10:51001 -> 198.51.100.20:443
203.0.113.10:51002 -> 198.51.100.20:443

这也解释了一个常见问题:Web 服务器只监听一个 443 端口,为什么可以同时服务成千上万个客户端?

服务器的监听套接字负责接收新的连接请求。连接建立后,操作系统可以根据不同的四元组维护不同的连接状态,并将到达的 TCP 报文段分发到相应的连接套接字。服务器端口相同,并不意味着所有连接无法区分。

3. 二者对比

对比项 UDP TCP
通信模型 无连接的数据报服务 面向连接的字节流服务
典型分用依据 目的 IP、目的端口等本地绑定信息 源 IP、源端口、目的 IP、目的端口组成的四元组
是否为每个对端维护连接状态 通常不维护 需要维护
不同来源的数据 可以交给同一个 UDP 套接字 按不同 TCP 连接分别管理

这里描述的是教材中的典型模型。实际操作系统还支持通配地址绑定、端口复用等机制,具体匹配规则会受到系统实现和套接字选项影响,但不改变上述基本原理。

七、结合一次网页访问理解完整过程

假设浏览器准备通过 HTTPS 访问一台 Web 服务器,可以把端口、复用和分用串联起来理解。

1. 客户端发送请求

  1. 浏览器创建套接字;
  2. 操作系统为客户端选择一个临时端口,例如 51001;
  3. 浏览器连接服务器的 TCP 端口 443;
  4. TCP 为数据添加源端口 51001 和目的端口 443 等首部信息;
  5. IP 层再添加源、目的 IP 地址,并把数据报送入网络。

浏览器之外的其他应用也可以同时提交数据。传输层分别封装后,把这些报文统一交给 IP 层,这就是发送端复用。

2. 服务器接收请求

  1. 网络层确认目的 IP 是本机,并把 TCP 报文段交给 TCP;
  2. TCP 根据四元组找到对应连接;
  3. 请求数据进入该连接套接字的接收缓冲区;
  4. Web 服务器读取并处理请求。

服务器上的其他服务可能监听不同端口。操作系统会根据协议、地址和端口等信息把数据分配给正确套接字,这就是接收端分用。

3. 响应返回客户端

服务器发送响应时,端口方向随通信方向交换:服务器以 443 为源端口,51001 为目的端口。响应到达客户端后,操作系统根据连接的四元组把它交回浏览器对应的套接字,而不会误交给其他应用。

由此可见,一次看似简单的网页访问,既依赖 IP 地址把数据送到正确主机,也依赖传输层把数据交给正确的通信端点。

八、几个常见误区

1. “IP 地址已经能找到设备,所以不需要端口号”

IP 地址只能标识网络中的接口或主机,不能单独说明数据属于主机上的哪项网络服务。多个应用同时联网时,传输层仍需要端口等信息完成分用。

2. “一个端口只能对应一个连接”

端口号不是连接的完整标识。TCP 服务器可以在同一个本地端口上维护大量连接,因为不同连接拥有不同四元组。

3. “目的端口号可以唯一标识所有 TCP 数据”

目的端口可以帮助找到服务器的监听服务,但已建立的 TCP 连接需要结合源、目的 IP 和源、目的端口共同区分。只看目的端口无法区分所有并发客户端。

4. “运输层会在每台路由器上处理端口号”

普通 IP 路由器的核心转发依据是网络层信息。传输层的复用、分用和连接管理主要发生在通信端系统。防火墙、NAT 等中间设备可能检查端口,但那属于额外功能,不能据此认为所有路由器都在执行完整的传输层处理。

5. “套接字就是一条实际存在的网络通道”

套接字是应用使用网络服务的编程接口和通信端点。TCP 连接也是由两端维护状态形成的逻辑连接,并不是在两台主机之间拉出了一条独占的物理线路。

九、总结

本篇从网络层与传输层的分工出发,梳理了传输层最基础的几个概念:

  1. 网络层解决主机到主机的通信,传输层把它扩展为应用进程之间的逻辑通信;
  2. 传输层主要运行在端系统中,中间路由器通常只负责网络层转发;
  3. 端口号是 16 位的逻辑标识,用于帮助操作系统定位通信端点;
  4. 复用是发送端汇集不同应用的数据,分用是接收端把数据交给正确套接字;
  5. UDP 的典型分用主要围绕本地目的地址和目的端口,TCP 则使用四元组区分不同连接;
  6. IP 地址负责找到主机,端口号和套接字机制继续完成主机内部的精准交付。

至此,我们已经知道数据为什么能在多个应用之间正确分流。但“送到正确应用”并不代表协议一定会保证数据可靠、按序到达。接下来可以从结构最简单的 UDP 入手,看看它只做少量工作的设计为何仍然具有不可替代的价值。


如果这篇文章对你有帮助,欢迎点赞、评论、关注、收藏。你们的支持是我前进的动力!

Logo

openEuler 是由开放原子开源基金会孵化的全场景开源操作系统项目,面向数字基础设施四大核心场景(服务器、云计算、边缘计算、嵌入式),全面支持 ARM、x86、RISC-V、loongArch、PowerPC、SW-64 等多样性计算架构

更多推荐