深流客栈
Avatar
⌂正在统计字数

一、HTTP 通信流程（基于 HTTP/1.1）

  1. DNS 解析
    浏览器把域名解析为服务器 IP。
  2. 建立连接（TCP / TLS）
    • HTTP → TCP 三次握手
    • HTTPS → TCP + TLS 握手（建立加密通道）
  3. 发送请求（Request）
    客户端发送：
    请求行（方法 + 路径 + 协议版本）
请求头
请求体（可选）
  4. 服务器处理请求
    应用程序处理业务逻辑。
  5. 返回响应（Response）
    状态行（状态码）
响应头
响应体
  6. 连接复用或关闭
    • HTTP/1.1 默认 keep-alive
    • HTTP/2 多路复用
    • HTTP/3 基于 QUIC

二、HTTP 基本原理

1️、 本质：应用层协议

HTTP 是运行在 TCP 之上的 请求-响应模型协议。

比喻：TCP 是“快递运输公司”， HTTP 是“包裹里的格式规范”。

2️、 无状态

服务器不保存客户端状态。
每个请求都是独立的。

比喻：每次去银行办业务，柜员都不记得你，除非你带“凭证”（Cookie / Token）。

3️、 基于文本协议（HTTP/1.x）

请求和响应是纯文本结构：

GET /index.html HTTP/1.1
Host: example.com

优点：可读
缺点：效率低（HTTP/2 变为二进制）

4️、 关键机制

  • 方法（GET / POST / PUT / DELETE）
  • 状态码（200 / 404 / 500）
  • Header 控制行为
  • Cookie / Session 维持状态
  • 缓存机制（Cache-Control / ETag）
  • 长连接（Keep-Alive）

三、核心理解

HTTP 通信本质就是： 建立连接 → 发送格式化请求 → 返回格式化响应 → 关闭或复用连接

如果压缩成一句话：HTTP 是一个基于 TCP 的、无状态的、请求-响应式应用层协议。

基于 OSI 七层模型：HTTPS 建立过程

本质：先用 TLS 建立安全通道，再在通道里跑 HTTP

一、L7 应用层（HTTP）

用户在浏览器输入：

https://example.com

浏览器构造 HTTP 请求，但此时还不能发送明文数据。 👉 必须先建立 TLS 加密通道。

二、L6 表示层（TLS/SSL 加密层）

TLS 工作在表示层（在 TCP 之上，HTTP 之下）。

1、 Client Hello

客户端发送：

  • 支持的 TLS 版本
  • 支持的加密套件
  • 随机数（Client Random）
  • 支持的加密算法列表

👉 相当于： “我会这些加密方式，你选一个。”

2、Server Hello

服务器返回：

  • 选择的 TLS 版本
  • 选定的加密套件
  • 随机数（Server Random）
  • 服务器证书（含公钥）

3、 证书验证

客户端验证：

  • 证书是否由受信任 CA 签发
  • 域名是否匹配
  • 是否过期

比喻：就像确认对方的身份证是不是公安机关盖章。

4、 密钥协商

根据加密套件：

  • 使用 RSA 或 ECDHE 等算法
  • 双方生成 对称会话密钥

核心原理：

  • 非对称加密 → 用来安全交换密钥
  • 对称加密 → 用来高效传输数据

比喻：先用保险箱交换钥匙 然后用这把钥匙锁同一把门

5、Finished

双方确认握手完成。
之后所有数据都使用对称密钥加密。

TLS 通道建立完成。

三、L4 传输层（TCP）

在 TLS 之前，必须先完成：

TCP 三次握手

  1. SYN
  2. SYN-ACK
  3. ACK

作用：

  • 建立可靠连接
  • 确认双方收发能力

四、L3 网络层（IP）

  • 封装为 IP 数据包
  • 确定源 IP 和目标 IP
  • 进行路由转发

五、L2 数据链路层

  • 封装为帧
  • 使用 MAC 地址
  • ARP 查询网关 MAC

六、L1 物理层

  • 电信号 / 光信号传输

七、TLS 建立完成后

回到应用层：

客户端发送：

GET / HTTP/1.1

但此时：

  • 内容已经被 TLS 加密
  • 抓包只能看到密文

服务器解密后返回加密响应。

总流程时间线

TCP 三次握手
        ↓
TLS 握手
        ↓
生成对称密钥
        ↓
HTTP 加密通信

核心理解

HTTPS =

HTTP
+
TLS（加密 + 身份认证 + 完整性校验）
+
TCP
+
IP

一句话总结：HTTPS 是在 TCP 之上通过 TLS 建立加密隧道，然后在隧道中进行 HTTP 请求响应通信。

补充：

在网络速度参数中，cwnd（拥塞窗口）是TCP（传输控制协议）发送方维护的一个关键变量，用于限制在任何给定时间可以发送到网络中但尚未得到确认的数据量。它的主要目的是防止网络拥塞。 cwnd的大小会根据网络状况动态调整，从而影响发送方的传输速率。

cwnd与ACK（确认应答）之间的关系如下：

  • 增加 cwnd：
    • 慢启动 (Slow Start) 阶段： 在连接建立初期或从严重拥塞中恢复时，TCP进入慢启动阶段。在此阶段，每当发送方收到一个有效的ACK时，cwnd会呈指数级增长，通常每次增加1个最大报文段大小（MSS）。 这使得TCP能够快速探测网络的可用带宽。
    • 拥塞避免 (Congestion Avoidance) 阶段： 当cwnd达到某个阈值（ssthresh）后，TCP进入拥塞避免阶段。在此阶段，为了更谨慎地探测网络容量，cwnd的增长变为线性，通常每个往返时间（RTT）增加约1个MSS，或者每次收到ACK时增加一小部分MSS。
  • 减小 cwnd：
    • 报文段丢失（超时）: 如果发送方在重传超时（RTO）期限内未收到某个报文段的ACK，这通常被视为网络严重拥塞的信号。在这种情况下，cwnd通常会急剧减小，例如直接降至1个MSS，并重新进入慢启动阶段。
    • 重复ACK（快速重传/快速恢复）: 当发送方收到3个重复的ACK时，这表明某个报文段可能已丢失，但后续的报文段仍在成功传输。这被认为是比超时更轻微的拥塞迹象。在这种情况下，TCP会触发快速重传机制，并通常将cwnd减半（乘法减小），以较温和的方式降低发送速率，同时进入快速恢复阶段。

总而言之，ACKs是TCP拥塞控制机制（如AIMD：加法增大、乘法减小）中“时钟”新数据包传输的关键。 通过接收ACK，发送方可以判断网络是否能够处理更多的数据，并相应地调整其cwnd，从而适应不断变化的网络状况，避免拥塞崩溃。 实际的发送窗口大小是拥塞窗口（cwnd）和接收方通告窗口（rwnd）中的较小值。

在网络通信中，"BDP问题" 主要指的是与带宽时延积 (Bandwidth-Delay Product, BDP) 相关的性能挑战和优化问题。为了理解BDP问题，我们首先需要理解BDP本身。

什么是带宽时延积 (BDP)？

带宽时延积（BDP）是网络链路的 带宽（Bandwidth）与往返时延（Round-Trip Time, RTT）的乘积。

  • 带宽 (Bandwidth)：指网络链路在单位时间内可以传输的最大数据量，通常以比特每秒 (bps) 表示。
  • 往返时延 (RTT)：指一个数据包从发送端发出，经过网络到达接收端，再由接收端返回一个确认 (ACK) 到发送端所经历的总时间。

BDP的计算结果是一个以比特或字节为单位的数据量，它代表了在任何给定时间点，网络链路上已发送但尚未被确认的最大数据量。 你可以把它想象成一个水管的“体积”，带宽是水管的横截面积，而RTT是水管的长度。BDP就是这个水管在任何时刻能容纳的水量，即“在途数据量” (data in flight)。

“BDP问题” 是什么？

“BDP问题”主要是指在高性能网络，特别是高带宽、高延迟网络（通常被称为“长肥网络”或 LFNs，Long Fat Networks）中，如果TCP的发送窗口（或接收窗口）没有被正确配置以匹配或超过BDP，就会导致网络链路的利用率不足，从而无法达到理论上的最大吞吐量。

具体来说，BDP问题表现在以下几个方面：

  1. 窗口大小限制导致链路利用率低下：
    • TCP使用滑动窗口机制进行流量控制和拥塞控制。发送方在收到ACK之前，只能发送窗口内的数据。如果TCP的发送窗口（包括拥塞窗口 cwnd 和接收方通告窗口 rwnd）小于BDP，那么发送方在收到所有在途数据对应的ACK之前就会耗尽发送窗口，被迫停止发送并等待ACK。
    • 即使网络链路本身拥有很高的带宽，由于发送方不能持续发送足够的数据来“填满”整个“管道”（即BDP），链路的大部分时间可能处于空闲状态，导致带宽利用率不足，实际吞吐量远低于理论值。
  2. 传统TCP窗口大小的局限性：
    • 最初的TCP协议将窗口大小限制在16位，最大只能表示65,535字节（64 KiB）。对于BDP很大的网络（例如高带宽、高延迟的网络，如卫星链路或超高速局域网），这个默认的窗口大小可能远小于BDP。
    • 例如，一个1 Gbps带宽和100 ms RTT的网络，其BDP约为12.5 MB（1 Gbit/s * 0.1 s = 100 Mbit = 12.5 MByte）。如果TCP窗口只有64KB，那么发送方发送完64KB数据后就需要等待100ms的ACK，这极大地限制了吞吐量。
  3. 对TCP性能优化的需求：
    • 为了解决这个问题，需要对TCP进行调优，其中最关键的一步就是确保TCP窗口大小（包括拥塞窗口和接收窗口）足够大，至少应等于或大于BDP。
    • 这通常通过TCP窗口扩大选项 (TCP Window Scale Option) 来实现，该选项允许TCP窗口大小扩展到64KB以上，甚至达到数GB，从而能够充分利用高BDP网络的带宽。
  4. 长肥网络 (LFN) 的挑战：
    • BDP显著大于10^5比特（约12.5 KB）的网络被认为是长肥网络（LFN）。在这些网络中，由于大量数据在传输过程中尚未被确认，报文丢失的影响会更大，恢复机制需要更加鲁棒。
    • TCP拥塞控制算法在LFN中的表现也面临挑战，因此出现了许多为高BDP网络定制的TCP变体，如HSTCP、FAST TCP、BIC TCP、CUBIC TCP等。

简而言之，BDP问题就是指由于网络链路的带宽和时延乘积（BDP）较大，但TCP发送窗口（无论是拥塞窗口还是接收窗口）设置不足以“填满”这个管道，导致网络资源未能充分利用，传输效率低下。解决BDP问题通常需要通过合理设置TCP窗口大小以及使用TCP窗口扩大选项来优化网络性能。

  1. 小窗口（例如64KB）的情况：
    • 如果TCP窗口只有64KB，发送方会立即发送这64KB的数据。
    • 发送完这64KB后，**发送方就停止了！**因为它已经达到了其窗口限制，不能再发送任何数据，直到收到针对这64KB数据的一部分或全部的ACK。
    • 在100ms的RTT（往返时延）过去后，发送方才能收到这64KB数据的ACK。
    • 收到ACK后，窗口“滑动”，发送方才能发送下一批数据。
    • 结果是，每发送64KB数据，发送方就必须等待100ms。这导致了非常低的吞吐量：
      • 吞吐量 = 窗口大小 / RTT = 64KB / 0.1s = 640 KB/s。
      • 这远低于1 Gbps的理论带宽。
  2. 大窗口（例如12.5MB，即BDP）的情况：
    • 如果TCP窗口被设置为12.5MB，发送方不会在发送完64KB后就停止。
    • 发送方会持续地向网络中注入数据，直到它发送的未确认数据量达到了12.5MB的窗口限制。
    • 在网络中，数据包会持续不断地向前流动。当第一个64KB的数据包到达目的地并被接收方处理后，接收方会立即发送一个ACK回来。这个ACK仍然需要100ms才能回到发送方。
    • **但是，在这100ms的等待时间内，发送方并没有闲着！**它正在持续不断地发送后续的数据包，直到整个12.5MB的窗口都被填满。
    • 当第一个ACK在100ms后回来时，发送方的窗口会“滑动”，允许它继续发送更多的数据，从而保持管道的持续填充。
    • 这意味着，发送方可以在一个RTT内发送高达12.5MB的数据量，而不是仅仅64KB。

核心区别在于：

  • 小窗口强制发送方以“走走停停”（stop-and-wait）的方式发送数据，导致管道大部分时间是空的。
  • 大窗口允许发送方以“管道化”（pipelining）的方式连续发送数据，使得网络链路能够被充分利用，保持数据持续在途中，从而实现高吞吐量。

所以，将TCP窗口调整到12.5MB是为了确保在100ms的RTT内，发送方能够发送足够多的数据来完全填充1 Gbps的链路，从而最大限度地提高吞吐量，而不是为了减少单个ACK的等待时间。100ms的RTT是物理限制，无法通过调整窗口大小来改变，但大窗口可以确保在这100ms内，传输的数据量最大化。