面试中的网络协议（上：UDP/TCP）

平山
233 阅读13分钟

网络协议是什么？

网络协议是计算机网络中设备之间通信时遵循的规则和约定，定义了数据格式、传输方式、错误处理等，确保不同设备能正确交换信息。

网络协议的分层（OSI/TCP-IP模型）

网络协议通常按分层模型归类，常用的是 TCP/IP四层模型 或 OSI七层模型，对应关系如下：

1741802086510.jpg

网络协议分层的设计是为了实现职责分离、模块化协作，提升系统的灵活性、可维护性和扩展性。

常见网络协议及特点

传输层：传输层为应用程序提供端到端的数据传输服务，负责数据的分段、传输控制、错误恢复和流量控制。它主要使用 TCP（传输控制协议）和 UDP（用户数据报协议）来实现这些功能。

协议特点应用场景
TCP面向连接、可靠传输（确认重传）、流量控制、拥塞控制。Web（HTTP/HTTPS）、文件传输（FTP）、邮件（SMTP）。
UDP无连接、不可靠（不保证顺序和到达）、低延迟、轻量级。实时音视频（Zoom）、DNS查询、在线游戏。

典型场景举例

  • 当你在浏览器中访问网页时，传输层（TCP）负责将完整的HTML文件拆分成多个报文段，确保它们按顺序到达服务器，并处理丢包重传。
  • 玩在线游戏时，传输层（UDP）快速发送玩家的实时位置信息，允许偶尔丢包以降低延迟。

应用层：该层为用于通信的应用程序和用于消息传输的底层网络提供接口。 应用层协议为应用程序之间的通信提供规则（如HTTP/HTTPS用于网页浏览和API通信，HTTPS通过加密提升安全性为确保通信畅通），源主机和目的主机上所实现的应用层协议必须一致。

协议特点应用场景
HTTP明文传输静态网站浏览（不涉及敏感信息）、 内部系统通信（封闭网络环境）。
HTTPS通过SSL/TLS加密用户登录，支付等敏感操作、 所有现代网站（浏览器强制要求HTTPS）。

典型场景举例

  • 当你在浏览器输入网址时，应用层（HTTP）定义如何向服务器请求页面，而传输层（TCP）确保请求可靠到达。
  • 使用微信发送消息时，应用层协议定义消息格式（文本、图片等），传输层（可能用TCP或UDP）负责传输数据。

协作关系：以网页加载为例

  1. 应用层：浏览器生成HTTP请求（GET /index.html），定义请求头和内容。
  2. 传输层：TCP将HTTP请求拆分为报文段，添加源端口（如5000）和目标端口（80），确保可靠传输。
  3. 网络层：IP协议将报文段封装为IP包，路由到目标服务器。
  4. 服务器端：传输层（TCP）重组报文段，应用层（HTTP）解析请求并返回HTML文件。

UDP协议

用户数据报协议 (User Datagram Protocol, UDP)是一个简单的面向无连接的，不可靠的数据报的传输层(transport layer)协议。 在TCP/IP模型中，UDP为网络层(network layer)以上和应用层(application layer)以下提供了一个简单的接口。UDP只提供数据的不可靠交付，它一旦把应用程序发给网络层的数据发送出去，就不保留数据备份（所以UDP有时候也被认为是不可靠的数据报协议）。UDP在IP数据报的头部仅仅加入了复用和数据校验（字段）。由于缺乏可靠性，UDP应用一般必须允许一定量的丢包、出错和复制。

简单来说它无需建立连接即可直接发送数据，头部开销小，传输速度快，但不保证数据的可靠性、有序性或完整性，可能丢包或乱序。 就像寄明信片一样，写好地址就直接寄出去，不管对方收没收到。UDP支持单播、多播和广播，适合对实时性要求高的场景，比如视频直播、在线游戏或语音通话。

特点

它一种轻量级、高效的传输协议，牺牲了部分可靠性来换取速度和灵活性。

1. 面向无连接（知道了对面的 ip 后就直接传输数据）：UDP不需要像TCP那样通过“三次握手”建立连接，也不需要维护连接状态。

2. 只做数据报文的搬运工（不增加额外的报文头部）：UDP头部只有8字节，包含源端口、目标端口、长度和校验和，没有额外的控制字段（如序列号、确认号等）。

3. 不保证数据包的有序性：UDP没有序列号机制，数据包按照发送顺序传输，但可能因网络路径不同而乱序到达。

4. 不保证数据的可靠性（可能丢包）：UDP没有确认机制（ACK）和重传机制，发送方不知道数据是否成功到达。

5. 没有拥塞控制：UDP不检测网络拥塞情况，也不会主动降低发送速率。

  • 好处：在网络状况良好时，可以充分利用带宽，实现高吞吐量。
  • 代价：在网络拥塞时，可能加剧问题，导致更多丢包。

6. 高效：UDP的设计目标是简单和快速，去掉了许多复杂的控制机制。

7. 支持单播、多播和广播：UDP的设计允许数据包发送给单个目标（单播）、多个目标（多播）或整个网络段（广播）。

应用场景

在线游戏：玩游戏时，玩家的操作需要瞬间传到服务器，延迟高了会让人觉得“反应慢半拍”。UDP速度快，即使偶尔丢包（比如角色突然“瞬移”一下），也比延迟高、操作不跟手要好。

流媒体分发：电视台通过多播同时向大量用户发送视频流，UDP支持多播，效率高，即使偶尔丢包（比如画面卡一下），比如你看电视直播时，画面突然卡住，但很快又恢复正常。

补充

  • 应用层可靠性增强：某些基于UDP的协议（如QUIC/HTTP3、RTSP）在应用层实现了重传、校验等机制，弥补了UDP的不足。
  • 与TCP对比：TCP通过握手、确认、重传等机制保证可靠性，但牺牲了速度和灵活性；UDP则通过“轻量化”换取极致效率。

TCP协议

传输控制协议（TCP，TransmissionControl Protocol）是一种面向连接的、可靠的、基于字节流的传输层通信协议，TCP旨在适应支持多网络应用的分层协议层次结构，互连的计算机通信网络中成对的应用程序进程之间能够依靠TCP提供可靠的通信服务来传输字节流。TCP支持双向数据流，应用程序也可以仅单向发送数据。在主机之间，TCP使用端口号标识应用程序服务并且可以多路传输数据流。

特点

TCP是一种以可靠性为核心的传输协议，通过复杂机制保障数据质量，但牺牲了部分速度和灵活性。

1. 面向连接：通过三次握手建立连接（SYN、SYN-ACK、ACK），通过四次挥手（FIN、ACK）安全断开连接，确保双方通信状态同步。

2. 头部信息复杂：TCP头部至少20字节（可扩展至60字节），包含关键控制字段：

  • 序列号（Sequence Number） ：标识数据包顺序，解决乱序问题。

  • 确认号（Acknowledgment Number） ：告知发送方“已收到哪些数据”。

  • 窗口大小（Window Size） ：网络环境支持传输数据量多少字节的数据，动态调整发送速率，避免接收方缓冲区溢出。

  • 标识符：

    • URG=1：紧急报文。
    • ACK=1：确认报文。
    • PSH=1：要求接收方立即将数据推送给应用层。
    • RST=1：强制复位异常连接。
    • SYN=1：发起连接请求。
    • FIN=1：请求终止连接。

3. 数据有序可靠：

  • 通过序列号和确认号保证数据按顺序到达。
  • 自动重传丢失或损坏的数据包（超时重传 + 快速重传机制）。

超时重传：发送方在发送一个分片时启动超时定时器，如果在定时器超时之后没有收到相应的确认，重发该分片；

4. 流量控制与拥塞控制：

  • 流量控制：采用了滑动窗口协议，协议中规定，对于窗口内未经确认的分组需要重传。通过滑动窗口机制，根据接收方处理能力动态调整发送速率。

滑动窗口：TCP连接每一方的接收缓冲空间大小都是固定的，接收端只允许另一端发送接收端缓冲区所能接纳的数据，TCP通过滑动窗口机制提供流量控制，防止较快主机致使较慢主机的缓冲区溢出；

  • 拥塞控制：采用了广受好评的TCP拥塞控制算法（也称AIMD算法）。包含慢启动、拥塞避免、快速恢复等算法，感知网络拥堵并降低发送速率，避免加剧网络拥塞。

慢启动： 每当建立一个TCP连接时或一个TCP连接发生超时重传后，该连接便进入慢启动阶段。进入慢启动后，TCP实体将拥塞窗口的大小初始化为一个报文，即：cwnd=1。此后，每收到一个报文的确认（ACK），cwnd值加1，即拥塞窗口指数增加。当cwnd值超过慢启动阈值（ssthresh）或发生报文丢失重传时，慢启动阶段结束。前者进入拥塞避免阶段，后者重新进入慢启动阶段。

简单来说，TCP 协议是一种面向连接的、可靠的传输层协议，通过三次握手建立连接、确认应答、超时重传和流量控制等机制，确保数据有序、完整地从一端传输到另一端。

应用场景

网页浏览（HTTP/HTTPS） ：加载网页时，若图片或文本丢失会导致页面错乱。TCP确保所有数据完整到达，用户看到的内容始终一致。

文件传输 ：下载文件时，即便网络波动，TCP也能通过重传保证文件完整无误，避免压缩包损坏。

金融交易：在线支付或股票交易中，TCP保证交易指令的完整性和顺序，防止金额错乱或重复提交。

三次握手

TCP使用三次握手协议建立连接。当主动方发出SYN连接请求后，等待对方回答SYN+ACK，并最终对对方发来的 SYN 执行 ACK 确认。这种建立连接方法可以防止产生错误的连接。

1741850680879.png

最开始的时候客户端和服务器都是处于CLOSED关闭状态。主动打开连接的为客户端，被动打开连接的是服务器。 TCP服务器进程先创建传输控制块TCB，时刻准备接受客户进程的连接请求，此时服务器就进入了 LISTEN 监听状态

  1. 客户端发送 SYN 报文，请求建立连接 （客户端进入 SYN-SEND 状态）
  2. 服务端收到 SYN 报文，回复 SYN+ACK 报文 （服务端进入 SYN-RECEIVED 状态）
  3. 客户端收到 SYN+ACK 报文，回复 ACK 报文 （客户端和服务端同时进入 ESTABLISHED 状态）

为什么需要三次握手？两次握手行不行？

  • 防止历史连接干扰

假设客户端向服务端发送一个连接请求 A，但是网络环境差，导致 A 报文丢失，TCP 的超时重传会让客户端重新再发一个链接请求 B，此时服务端顺利接收到 B 报文，然后服务端回复一个确认报文，如果此时连接就建立成功的话，客户端和服务端就开始通信，通信结束后断开连接。但 A 报文，有可能再次出现在网络环境中被服务端接收到，此时服务端会再次回复一个确认报文，并进入ESTABLISHED状态，而客户端已经下线，服务端会一直等待客户端的数据通讯，造成资源浪费。

  • 验证双向通信能力

第一次握手： 客户端向服务器端发送报文证明客户端的发送能力正常

第二次握手：服务器端接收到报文并向客户端发送报文证明服务器端的接收能力、发送能力正常

第三次握手：客户端向服务器发送报文证明客户端的接收能力正常

HTTP协议 数据传输

HTTP 协议的数据传输基于 TCP 连接，整体流程如下：

三次握手（TCP 连接建立） → HTTP 请求 → HTTP 响应 → 数据传输 → 四次挥手（TCP 连接关闭）

具体场景 HTTPS 加载网页的完整流程（分层 + 时序）：

  1. 建立 TCP 连接：三次握手。

  2. TLS 握手：协商加密参数（仅 HTTPS）。

  3. HTTP 请求-响应（分层处理）：

    • 应用层：浏览器生成 HTTP 请求（如 GET /index.html）。

    • 传输层：TCP 拆分请求为报文段，添加端口号，确保可靠传输。

    • 网络层：IP 协议封装为数据包，路由到目标服务器。

    • 服务器处理：

    传输层重组 TCP 报文段 → 应用层解析 HTTP 请求 → 返回响应（如 HTML 文件）。

  4. 复用连接：浏览器解析 HTML，发现需加载 CSS/JS，通过同一 TCP 连接发送新请求。

  5. 关闭连接：四次挥手（当连接超时或主动关闭时）。

HTTPS简单来说HTTP的加密版，TLS，复用连接没听过没关系，下一篇来讲

四次挥手

859e96985dd18f849dfea0cf30a2b20.jpg
  1. 客户端向服务端发送 FIN 报文，请求断开连接 （客户端进入 FIN-WAIT-1 状态）
  2. 服务端收到 FIN 报文，回复 ACK 报文 （服务端进入 CLOSE-WAIT 状态）
  3. 服务端将未传输完的数据传输完后，向客户端发送 FIN 报文，请求断开连接 （服务端进入 LAST-ACK 状态）
  4. 客户端收到 FIN 报文，回复 ACK 报文 （客户端进入 TIME-WAIT 状态，一段时间后CLOSEED） 此时服务端进入 CLOSEED 状态

面试1. 为什么 TCP 关闭连接需要四次挥手？

  • 原因：服务器在收到客户端的 FIN 报文段后，可能还有一些数据要传输，所以不能马上关闭连接，但是会做出应答，返回 ACK 报文段，接下来可能会继续发送数据，在数据发送完后，服务器会向客户单发送 FIN 报文，表示数据已经发送完毕，请求关闭连接，然后客户端再做出应答，因此一共需要四次挥手。

面试2. 为什么 TIME-WAIT 状态要等待 2MSL？

  • 原因：解决网络不可靠导致的最后一个 ACK 丢失问题，并防止旧连接数据干扰新连接。

  • 作用：

    1. 确保服务器收到 ACK：
      若客户端 ACK 丢失，服务器会重发 FIN，客户端在 TIME-WAIT 期间可重新回复 ACK。
    2. 清除旧连接残留报文：
      等待 2MSL（2MSL是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃）确保网络中旧连接的报文失效，避免与新连接冲突。

  • 简答：
    等待 2MSL 既保证连接可靠关闭，又避免旧数据干扰新连接，是 TCP 对网络不可靠性的容错设计。

avatar
文章
阅读
粉丝