文章

网络编程高频总结四

发表于 更新于
作者 匆匆那年 25 分钟阅读

粘包拆包是什么，发生在哪一层

粘包拆包是什么

粘包和拆包是网络编程中经常遇到的问题，主要发生在传输层，具体是基于 TCP 协议的网络通信中。

粘包

  • 定义: 粘包是指一次发送的多个数据包在接收方被粘在一起，接收方无法正确分辨每个数据包的边界。
  • 原因:
    1. TCP是流式协议: TCP 是面向流的协议，不像 UDP 那样是面向消息的。数据以字节流的形式传输，可能将多次发送的数据合并成一个数据块。
    2. 发送方原因: 应用程序发送数据的速度过快，导致多个数据包在底层协议栈中被合并。
    3. 接收方原因: 接收方的缓冲区一次读取了多个数据包，造成粘包。

拆包

  • 定义: 拆包是指一次发送的大数据包在接收方被分成多个小块，接收方需要将其重新组合以获得完整的数据。
  • 原因:
    1. TCP数据分片: 数据包太大，超过了 TCP 的 MSS（最大分段大小），需要分片传输。
    2. 网络条件: 网络拥塞或接收方缓冲区较小，导致数据被分成多次传输。

发生在哪一层

  1. 传输层（TCP 协议）:
    • 粘包和拆包问题的根本原因在于 TCP 是流式协议，没有边界概念。
    • 数据以流的形式传输时，TCP 协议栈负责将数据分段，但不保证应用层数据的分界。
  2. 应用层:
    • 粘包拆包的处理通常需要在应用层实现，因为 TCP 并不提供自动的消息边界处理机制。

解决粘包和拆包的方法

粘包问题的解决

  1. 固定长度协议:
    • 约定每个消息固定长度，接收方按照固定长度解析数据。
    • 优点: 简单高效。
    • 缺点: 不适合变长消息，会浪费带宽。
  2. 分隔符协议:
    • 在每个消息之间插入特殊的分隔符（如 \n 或 \r\n）。
    • 接收方根据分隔符分割消息。
    • 示例: 网络文本协议（如 HTTP 的 Chunked 传输、Redis 协议）。
  3. 消息头加长度协议:
    • 在每个数据包的头部增加一个定长字段，用于表示消息的长度。
    • 接收方先读取消息头，获取长度信息后再读取对应长度的数据。
    • 常见于二进制协议（如 TLV 格式）。

拆包问题的解决

  1. 缓存未完整数据:
    • 如果接收方读取的数据不完整，可以将不完整的部分缓存，等下一次读取时拼接完整。
  2. 基于消息长度读取:
    • 结合粘包问题的“消息头加长度”方法，确保每次按长度读取完整消息。

总结

粘包和拆包问题是由于 TCP 的流式特性 引起的，主要发生在 传输层，需要在 应用层 自行设计协议解决。这种问题常见于需要高性能、可靠传输的场景，如即时通信、文件传输等。

TCP在什么情况下会出现大量time_wait，哪个阶段出现

在 TCP 协议中，大量 TIME_WAIT 状态的出现通常是因为连接终止阶段的设计，尤其是在高并发情况下。这种状态出现的背景和原因需要从 TCP 四次挥手 和 TIME_WAIT 的作用 角度来分析。

TIME_WAIT 出现的阶段

TIME_WAIT 是 TCP 连接的 主动关闭方 在完成四次挥手后的临时状态，具体发生在 第四次握手 之后：

  1. 四次挥手的过程:
    • 第一步: 主动关闭方发送 FIN，表示不再发送数据。
    • 第二步: 被动关闭方回 ACK，确认接收。
    • 第三步: 被动关闭方发送 FIN，表示自己也要关闭连接。
    • 第四步: 主动关闭方回 ACK，确认接收后进入 TIME_WAIT 状态。
  2. TIME_WAIT 作用:
    • 确保被动关闭方的 FIN能被正确接收：
      • 如果最后的 ACK 丢失，被动关闭方会重发 FIN，此时主动关闭方仍然可以响应。
    • 确保旧连接的数据包不会影响新连接：
      • 等待时间（通常是 2倍的最大报文段寿命，即 2MSL）后，内核确保本次连接的所有数据包都已从网络中消失。

大量 TIME_WAIT 的常见场景

  1. 高并发短连接:
    • 场景: 客户端与服务器频繁创建和销毁短连接（如 HTTP/1.0 不支持长连接的模式）。
    • 结果: 主动关闭方（通常是客户端，但也可能是服务器）会产生大量 TIME_WAIT。
  2. 服务器作为主动关闭方:
    • 场景: 在某些应用中，服务器处理完客户端请求后主动关闭连接。
    • 结果: 每个关闭的连接都会进入 TIME_WAIT 状态，导致状态堆积。
  3. 大量突发流量:
    • 场景: 如负载测试、大规模爬虫等高流量场景。
    • 结果: 短时间内创建并关闭大量 TCP 连接。
  4. NAT 或代理设备:
    • 场景: 使用 NAT 或代理时，多个连接复用相同的源 IP 和端口。
    • 结果: 这些设备可能会处理大量 TIME_WAIT 状态。

解决大量 TIME_WAIT 的方法

  1. 调整服务器主动关闭策略:

    • 尽量让客户端作为主动关闭方：
      • 如果可以控制应用逻辑，设计为客户端发送 FIN 主动关闭连接，从而将 TIME_WAIT 转移到客户端。

  2. 启用长连接:

    • 使用 HTTP/1.1 或 HTTP/2 的长连接特性（通过 Connection: keep-alive），减少频繁创建和销毁连接的成本。

  3. 修改系统内核参数:

    • 减少 TIME_WAIT

      状态的保留时间：

      1

      sysctl -w net.ipv4.tcp_fin_timeout=30

    • 允许端口快速重用：

      1
2

      sysctl -w net.ipv4.tcp_tw_reuse=1
sysctl -w net.ipv4.tcp_tw_recycle=1  # 注：此参数在高 NAT 环境中可能有问题，已被废弃。

  4. 优化端口资源:

    • 增加可用端口范围：

      1

      sysctl -w net.ipv4.ip_local_port_range="1024 65535"

    • 降低端口耗尽风险。

  5. 负载均衡:

    • 使用负载均衡器（如 Nginx、HAProxy）分摊连接压力。

  6. 使用更高效的协议:

    • 考虑使用 UDP 或基于 UDP 的高性能协议（如 QUIC）替代 TCP，尤其是对连接频率要求极高的场景。

总结

  • TIME_WAIT 状态主要出现在 TCP 连接的主动关闭方，发生在四次挥手的 最后阶段。
  • 它的设计目的是确保连接的安全性和可靠性，但在高并发场景下可能导致资源耗尽。
  • 解决方法包括优化连接逻辑、调整系统参数以及使用长连接或更高效的协议。

TCP包头字段… 标志位 -> 建立连接过程，终止连接过程 -> TIME_WAIT，CLOSE_WAIT分析，属于哪一方？

TCP 包头字段中的标志位

TCP 包头中的标志位用来控制连接的状态和数据传输。常见的标志位及其作用如下：

  • SYN (Synchronize): 发起连接，用于建立连接的初始阶段。
  • ACK (Acknowledgment): 确认数据接收或某种操作。
  • FIN (Finish): 表示发送方完成数据发送，请求关闭连接。
  • RST (Reset): 重置连接，用于异常情况下的强制关闭。
  • PSH (Push): 表示需要立即将数据推送给应用层。
  • URG (Urgent): 表示数据有优先级，需要立即处理。

TCP 建立连接过程

TCP 的连接建立过程是 三次握手，涉及 SYN 和 ACK 标志位。

  1. 第一次握手:
    • 客户端发送 SYN 包（SYN=1, ACK=0），随机生成一个序列号（Seq=x）。
    • 意图: 客户端请求建立连接。
  2. 第二次握手:
    • 服务器收到 SYN，发送 SYN+ACK 包（SYN=1, ACK=1），确认客户端的序列号并生成自己的序列号（Seq=y，Ack=x+1）。
    • 意图: 服务器同意建立连接，并要求客户端确认。
  3. 第三次握手:
    • 客户端收到 SYN+ACK，发送 ACK 包（ACK=1，Seq=x+1, Ack=y+1）。
    • 意图: 客户端确认连接，双方进入 ESTABLISHED 状态。

TCP 终止连接过程

TCP 的连接终止过程是 四次挥手，涉及 FIN 和 ACK 标志位。

  1. 第一次挥手:
    • 主动关闭方发送 FIN 包（FIN=1, ACK=1，Seq=u），表示不再发送数据。
    • 状态: 主动关闭方进入 FIN_WAIT_1 状态。
  2. 第二次挥手:
    • 被动关闭方收到 FIN，发送 ACK 包（ACK=1，Seq=v, Ack=u+1），确认收到。
    • 状态: 被动关闭方进入 CLOSE_WAIT 状态，主动关闭方进入 FIN_WAIT_2 状态。
  3. 第三次挥手:
    • 被动关闭方发送 FIN 包（FIN=1, ACK=1，Seq=w），请求关闭连接。
    • 状态: 被动关闭方进入 LAST_ACK 状态。
  4. 第四次挥手:
    • 主动关闭方收到 FIN，发送 ACK 包（ACK=1，Seq=x, Ack=w+1），确认收到。
    • 状态: 主动关闭方进入 TIME_WAIT 状态，等待 2MSL 后关闭连接。

TIME_WAIT 和 CLOSE_WAIT 分析

TIME_WAIT

  • 含义:
    • 主动关闭方在发送 ACK 后进入 TIME_WAIT 状态。
    • 等待 2 倍的最大报文段寿命（2MSL），确保网络中的所有数据包已被正确传输或丢弃。
  • 作用:
    1. 确保被动关闭方未收到 ACK 时重发的 FIN 能够被正确处理。
    2. 防止旧连接的数据包干扰后续新连接。
  • 属于哪一方:
    • 主动关闭方。

CLOSE_WAIT

  • 含义:
    • 被动关闭方在接收到 FIN 并回复 ACK 后进入 CLOSE_WAIT 状态。
    • 此时连接尚未完全关闭，被动关闭方还需处理未完成的事务。
  • 作用:
    • 等待应用程序调用 close() 来完成连接关闭。
  • 属于哪一方:
    • 被动关闭方。

总结

状态触发条件属于哪一方备注
TIME_WAIT主动关闭方发送完 ACK主动关闭方用于确保连接的安全性和数据完整性。
CLOSE_WAIT被动关闭方收到 FIN 后被动关闭方等待应用程序调用 close() 完成关闭。
  • 主动关闭方 会经历 TIME_WAIT 状态。
  • 被动关闭方 会经历 CLOSE_WAIT 状态。

TCP 建立连接过程 -> SYN + ACK 包能不能拆开来发

TCP 建立连接过程中 SYN + ACK 包能否拆开发送

理论上

在 TCP 三次握手的过程中，第二步中服务器返回的 SYN + ACK 包理论上是可以拆开来发送的，但在实际实现中通常不会这么做。

  1. 正常的第二次握手流程:

    • 服务器在收到客户端的 SYN 包后，发送一个合并的 SYN + ACK 包，既表示对客户端的 SYN 进行确认 (ACK)，又发送自己的 SYN 来建立连接。

  2. 拆开发送的可能性:

    • 第一部分: 服务器先单独发送 ACK 确认客户端的 SYN。
    • 第二部分: 服务器随后再发送 SYN 发起自己的连接请求。

    从协议角度看，这仍然是合法的，因为 TCP 协议没有强制要求 SYN 和 ACK 必须同时发送。

实际情况

一般情况下不会拆开发送，因为：

  1. 效率问题:
    • 合并发送 SYN + ACK 包可以减少一次包发送的时间和开销。
    • 如果拆开发送，服务器需要发送两个包，增加了网络负载和时延。
  2. 实现问题:
    • 大多数 TCP 协议栈在实现中都严格遵循三次握手的标准流程，直接将 SYN 和 ACK 合并为一个包发送。
    • 拆开发送会导致额外的逻辑复杂性，且没有明显的优势。
  3. 潜在的兼容性问题:
    • 某些 TCP 实现可能假设第二次握手的 SYN 和 ACK 是合并的。如果拆开发送，可能会出现未预期的行为（尽管仍然符合规范）。

拆开发送可能出现的场景

  1. 异常情况:
    • 如果服务器在收到客户端 SYN 后，网络条件导致 ACK 和 SYN 包分开发送。
    • 这种情况通常不是故意设计，而是由网络分片或延迟引起的。
  2. 定制协议栈:
    • 某些特殊场景下，定制的 TCP 实现可能选择拆开发送，例如为了调试或满足某些实验性的需求。

总结

  • 理论上: SYN 和 ACK 可以拆开发送。
  • 实际上: 大多数 TCP 实现都合并为一个 SYN + ACK 包发送，因为这样更高效、更简单、更符合实际需求。
  • 拆开发送可能出现在异常网络条件或特殊定制场景中，但通常不是推荐的做法。

讲讲quic/听说过哪些快速重传算法/timewait状态干啥用的

1. QUIC 协议

简介

QUIC (Quick UDP Internet Connections) 是 Google 开发的基于 UDP 的传输层协议，旨在改善 TCP 的性能和灵活性，特别是针对延迟敏感的应用（如 HTTP/3）。相比传统的 TCP，QUIC 提供了更快的连接建立、内置加密、安全性和拥塞控制。

主要特点

  1. 基于 UDP:
    • 使用 UDP 数据报传输，绕过了 TCP 固有的限制，例如连接建立和拥塞控制的僵化机制。
    • 通过在应用层实现流控和重传等功能，实现了对网络资源的灵活利用。
  2. 0-RTT 连接建立:
    • 支持首次握手后的后续连接实现 0-RTT（零往返时间），显著降低延迟。
    • 避免了传统 TCP+TLS 所需的三次握手和加密握手的额外延迟。
  3. 多路复用:
    • 单个 QUIC 连接内支持多个流，避免 TCP 中的 “队头阻塞” 问题。
  4. 内置加密:
    • QUIC 默认启用 TLS 1.3，所有数据均加密传输，提高了安全性。
  5. 快速重传和纠错机制:
    • 使用自定义的 ACK 和丢包检测机制，比传统 TCP 更高效。
  6. 面向未来的协议:
    • 易于扩展，可以根据需求增加新功能（如更灵活的拥塞控制算法）。

应用场景

  • HTTP/3 标准化使用 QUIC。
  • 视频流媒体、实时通信、游戏等对低延迟有高要求的应用。

2. 常见的快速重传算法

快速重传算法是 TCP 拥塞控制的一个重要组成部分，用于在未收到超时事件之前，通过检测数据包的重复 ACK 判断丢包并进行快速重传。

常见算法

  1. TCP Tahoe:
    • 机制:
      • 触发条件: 接收到 3 次重复的 ACK。
      • 响应:
        • 快速重传丢失的包。
        • 将拥塞窗口设置为 1（进入慢启动阶段）。
    • 缺点:
      • 恢复慢，容易导致带宽利用率下降。
  2. TCP Reno:
    • 机制:
      • 同样触发快速重传。
      • 响应:
        • 将拥塞窗口减半（进入拥塞避免阶段），而不是直接降为 1。
    • 改进点:
      • 比 Tahoe 更高效，但仍可能在高丢包率下性能不佳。
  3. NewReno:
    • 机制:
      • 改进了重传机制，在一个 RTT 内可以处理多个丢包。
      • 进入 快速恢复阶段，维持较高的带宽利用率。
    • 特点:
      • 在中度丢包环境下表现更优。
  4. SACK（Selective Acknowledgment）:
    • 机制:
      • 接收方可以选择性确认哪些数据包已接收，发送给发送方。
      • 发送方仅重传未确认的丢失数据包。
    • 优势:
      • 高效利用带宽，特别是在多丢包场景下。
  5. BBR（Bottleneck Bandwidth and RTT）:
    • 机制:
      • Google 开发的现代拥塞控制算法。
      • 不依赖丢包检测，而是实时估算瓶颈带宽和最小 RTT 来动态调整发送速率。
    • 特点:
      • 适用于现代网络，更适合高带宽、高延迟链路。

3. TIME_WAIT 状态的作用

什么是 TIME_WAIT

TIME_WAIT 是主动关闭方在完成 TCP 四次挥手后进入的临时状态，持续时间为 2倍的 MSL（Maximum Segment Lifetime，报文段的最大生存时间）。

作用

  1. 确保最后一个 ACK 的可靠性:
    • 在四次挥手中，如果主动关闭方发送的最后一个 ACK 丢失，被动关闭方会重发 FIN。
    • TIME_WAIT 确保主动关闭方仍能接收并响应此 FIN。
  2. 防止旧连接的数据干扰新连接:
    • TCP 连接是通过四元组（源 IP、源端口、目标 IP、目标端口）标识的。
    • TIME_WAIT 的存在可以保证旧连接的残余数据（如延迟到达的包）在网络中被丢弃，不会影响新连接。

TIME_WAIT 的问题

  • 资源消耗:
    • 在高并发短连接的场景（如 HTTP/1.0 短连接），会产生大量的 TIME_WAIT 状态，占用系统资源（如端口和内存）。

TIME_WAIT 的优化方法

  1. 调整系统参数:

    • 缩短 TIME_WAIT的持续时间:

      1

      sysctl -w net.ipv4.tcp_fin_timeout=30

    • 启用端口复用:

      1

      sysctl -w net.ipv4.tcp_tw_reuse=1

  2. 使用长连接:

    • 在应用层启用长连接（如 HTTP/1.1 keep-alive），减少连接创建和销毁的频率。

  3. 负载分摊:

    • 通过负载均衡器（如 Nginx）分摊连接压力。

总结

  1. QUIC 是一种高性能协议，基于 UDP，专注于低延迟和高吞吐。
  2. 快速重传算法 是 TCP 拥塞控制的重要部分，NewReno、SACK 和 BBR 是常用的改进方案。
  3. TIME_WAIT 状态保障了连接关闭的可靠性和安全性，尽管在高并发场景中可能引发资源问题，可以通过系统参数优化和长连接策略缓解。
网络编程, 网络编程面经
网络编程 面经
本文由作者按照 CC BY 4.0 进行授权