网络问题 - 凌冬的个人博客

tcp和udp的区别，他们的报头结构，tcp的三次握手和四次握手的中间状态有哪些

TCP（传输控制协议）和UDP（用户数据报协议）是两种不同的传输层协议，它们在数据传输的可靠性、连接性、流量控制和头部结构等方面有显著区别。

区别：

连接性：TCP是面向连接的协议，需要在数据传输前建立连接；UDP是无连接的协议，不需要建立连接。
可靠性：TCP提供可靠的数据传输，通过确认应答、重传机制保证数据完整性；UDP不保证数据的可靠性，数据包可能会丢失或乱序。
流量控制：TCP通过滑动窗口和流量控制机制来管理数据流量；UDP不提供流量控制。
速度：TCP由于其可靠性机制，速度相对较慢；UDP相对较快，适合实时应用。

报头结构：

TCP报头结构通常为20字节，主要字段包括：源端口、目标端口、序列号、确认号、数据偏移、标志位、窗口大小、校验和、紧急指针等。
UDP报头结构为8字节，主要字段包括：源端口、目标端口、长度、校验和。

TCP的三次握手和四次挥手：

三次握手：

客户端发送SYN包请求建立连接（状态：SYN_SEND）。
服务器收到SYN包后，发送SYN-ACK包确认（状态：SYN_RECEIVED）。
客户端收到SYN-ACK包后，发送ACK包确认连接建立（状态：ESTABLISHED）。

四次挥手：

主动关闭方发送FIN包请求关闭连接（状态：FIN_WAIT_1）。
被动关闭方收到FIN包后，发送ACK包确认（状态：CLOSE_WAIT）。
被动关闭方发送FIN包请求关闭连接（状态：LAST_ACK）。
主动关闭方收到FIN包后，发送ACK包确认（状态：TIME_WAIT），然后进入CLOSED状态。

伪代码示例： TCP三次握手的伪代码：

1
2
3
4
5
6
7
8
9


Client:
send(SYN)
wait for SYN-ACK
send(ACK)

Server:
wait for SYN
send(SYN-ACK)
wait for ACK

TCP四次挥手的伪代码：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


Client:
send(FIN)
wait for ACK
wait for FIN
send(ACK)

Server:
wait for FIN
send(ACK)
send(FIN)
wait for ACK

这样的伪代码帮助理解TCP连接建立和关闭的过程。

TCP与UDP的区别：

连接性： TCP是面向连接的协议，在数据传输前需要建立连接；UDP是无连接的协议，发送数据时不需要建立连接。
可靠性： TCP确保数据的可靠传输，使用序列号和确认应答机制来实现；UDP不保证数据传输的可靠性，数据包可能丢失、重复或乱序。
传输速度：因为TCP需要建立连接和进行流量控制，其传输速度相对较慢；UDP由于简单的传输机制，速度较快，适合实时应用。
适用场景： TCP适用于对数据完整性要求高的应用，如网页浏览、文件传输；UDP适用于对实时性要求高的应用，如视频会议、在线游戏。

SSL

HTTPS握手流程：

客户端发起连接请求，发送支持的TLS版本和加密算法列表。
服务器回应其支持的TLS版本和选定的加密算法，并发送其数字证书（包含公钥）。
客户端验证服务器证书的有效性，通过根证书和证书链进行验证。
验证通过后，客户端生成一个随机数 （称为Pre-Master Secret） ，使用服务器的公钥加密并发送给服务器。
服务器使用其私钥解密得到Pre-Master Secret，并与客户端生成会话密钥。
之后，客户端和服务器使用会话密钥进行加密通信。

伪代码示例：

客户端发送请求： client.send(“HELLO”)
服务器发送证书： server.send(certificate)
客户端验证证书： if verify(certificate): client.send(encrypt(pre_master_secret, server.public_key))
服务器解密： pre_master_secret = decrypt(client_message, server.private_key)

https是http加了什么，TLS，讲一下TLS协商密钥的过程。用户的协商用的key会被发到信道上吗，用的什么加密方式解题思路踩一下【答案】： https是在http的基础上加入了TLS（Transport Layer Security）协议，用于保护数据传输的安全性。TLS协商密钥的过程主要包括以下几个步骤：

客户端发送一个随机数ClientHello给服务器端，其中包括支持的TLS版本、加密算法等信息。
服务器端接收到ClientHello后，回复一个随机数ServerHello给客户端，同时发送服务器端的证书（包括公钥）给客户端。
客户端收到服务器端的证书后，验证其有效性，并生成一个pre-master secret，然后用服务器端的公钥加密这个pre-master secret，并发送给服务器端。
服务器端收到加密的pre-master secret后，使用自己的私钥解密得到pre-master secret。
客户端和服务器端根据双方的随机数和pre-master secret生成对话密钥，用于后续的数据传输加密。

在TLS协商密钥的过程中，密钥本身并不会被明文发到信道上，而是通过非对称加密的方式进行传输。客户端生成的pre-master secret会使用服务器端的公钥加密后传输，而服务器端收到后使用自己的私钥解密得到原始的pre-master secret。这样可以确保密钥在传输过程中不被窃取。

至于加密方式，TLS支持多种加密算法，包括对称加密算法（如AES、DES）、非对称加密算法（如RSA、ECC）以及哈希算法（如SHA）。在TLS协商密钥的过程中，双方会根据支持的加密算法协商出一个最终的加密方式，从而保证通信数据的机密性和完整性。TLS的加密算法不断更新和演进，以应对日益复杂的网络安全威胁。

缓存的几个问题

在分布式系统中，缓存雪崩、缓存穿透和缓存击穿是三种常见的缓存问题。这些问题可能导致系统性能下降，甚至崩溃。以下是它们的定义和对应的解决方法：

1. 缓存雪崩

定义

缓存雪崩指的是在某一时刻，大量缓存失效，导致大量请求直接打到后端数据库或其他存储系统，从而引发系统过载甚至崩溃。

解决方法

缓存过期时间分布化：
- 给缓存设置随机的过期时间，避免大批缓存同时过期。例如，将过期时间随机分布在 [T, T+delta] 之间。
热点数据提前重构：
- 定期更新热点数据的缓存，或者提前加载热门缓存数据。
限流与降级：
- 使用限流策略限制对后端的访问流量，例如通过令牌桶算法或漏桶算法。
- 缓存失效时，返回默认值（如默认页面、错误提示等）。
缓存预热：
- 在系统启动或流量高峰到来前，将必要的数据提前加载到缓存中。
多级缓存：
- 配置多层缓存结构，例如在本地使用内存缓存（如 Guava Cache）作为一级缓存，在分布式缓存（如 Redis）作为二级缓存。
异步更新：
- 对于失效的缓存，不直接将请求打到后端，而是先返回旧缓存，异步更新缓存内容。

2. 缓存穿透

定义

缓存穿透指的是用户请求的数据在缓存中不存在，且数据库中也不存在，导致每次请求都穿过缓存直接访问数据库，可能引发数据库过载。

解决方法

缓存空结果：
- 对查询数据库返回空的数据也进行缓存，例如设置一个短时间的缓存（如 1 分钟）。下次请求相同的键时可以命中缓存，减少对数据库的访问。
- 示例代码（以 Redis 为例）：
  1 2 3 4
  
  if redis.get(key) is None: value = db.query(key) if value is None: redis.set(key, 'NULL', ex=60) # 缓存空值，有效期 60 秒
布隆过滤器（Bloom Filter）：
- 在请求到达缓存之前，先通过布隆过滤器判断数据是否可能存在。布隆过滤器可以高效过滤掉不存在的请求。
- 示例：布隆过滤器存储所有可能的合法键，非法键直接拦截。
参数校验：
- 对用户输入的参数进行严格校验，过滤掉非法请求。
- 例如，如果请求的 ID 是负数或者超出某范围，直接返回错误。
限流：
- 对单一用户或同一请求进行访问频率限制，避免恶意攻击导致缓存穿透。

3. 缓存击穿

定义

缓存击穿是指某些热点数据在缓存中失效，而大量并发请求同时查询该数据，导致这些请求直接打到后端数据库。

解决方法

互斥锁（Mutex）：

当缓存失效时，只有第一个请求可以访问数据库并更新缓存，其他请求等待。

示例（伪代码）：

1
2
3
4
5
6
7
8
9


if redis.get(key) is None:
    if not lock.exists():
        lock.set('lock', timeout=5)  # 设置锁，防止并发
        value = db.query(key)
        redis.set(key, value, ex=3600)  # 更新缓存
        lock.delete()  # 删除锁
    else:
        # 等待缓存更新
        time.sleep(0.1)

缓存预热：
- 对于热点数据，定期主动刷新缓存，确保它不会过期。
永不过期：
- 对热点数据缓存设置为不过期，而是通过后台异步任务或定时任务去更新缓存数据。
- 示例：
  - 缓存中没有设置过期时间，而通过后台定时任务每隔 T 秒更新数据。
分布式锁：
- 在分布式系统中，使用 Redis 的分布式锁（如 Redisson）保证某一时刻只有一个线程能够更新缓存。

总结

问题	现象	解决方法
缓存雪崩	大量缓存同时失效，流量直接压向数据库，导致系统过载	缓存过期时间分散化、缓存预热、多级缓存、限流与降级
缓存穿透	请求的键既不在缓存中，也不在数据库中，导致请求直接穿过缓存	缓存空结果、布隆过滤器、参数校验、限流
缓存击穿	缓存中某个热点数据失效，大量并发请求同时访问后端数据库	互斥锁（Mutex）、缓存预热、永不过期（定时刷新）、分布式锁

针对这些问题，合理的缓存设计和多层防护策略可以有效提高系统的健壮性，避免关键时刻系统性能下降或服务不可用。

TCP（传输控制协议）的头部由多个字段组成，总长度为20字节（基础部分），如果有可选字段则会更长。以下是TCP头部的字段及其作用：

TCP头部结构

源端口（Source Port）
- 长度：16 位
- 描述：发送方的端口号，用于标识发送应用。
目标端口（Destination Port）
- 长度：16 位
- 描述：接收方的端口号，用于标识目标应用。
序列号（Sequence Number）
- 长度：32 位
- 描述：
  - 用于标识数据段的顺序。
  - 第一个字节的编号。
  - 如果有 SYN 标志，则表示初始序列号（ISN）。
确认号（Acknowledgment Number）
- 长度：32 位
- 描述：
  - 确认接收到的数据的序号。
  - 仅在 ACK 标志被设置时有效。
数据偏移（Data Offset）
- 长度：4 位
- 描述：
  - 指示 TCP 头部的长度（以 4 字节为单位）。
  - 最小值为 5（即 20 字节）。
保留位（Reserved）
- 长度：3 位
- 描述：
  - 保留供将来使用，必须为 0。
控制标志（Control Bits）
- 长度：9 位
- 描述：
  包含多个标志，用于控制连接状态。
  - URG： 紧急指针有效。
  - ACK： 确认号有效。
  - PSH： 推送功能。
  - RST： 复位连接。
  - SYN： 同步序列号，用于建立连接。
  - FIN： 发送方已完成数据发送。
窗口大小（Window Size）
- 长度：16 位
- 描述：
  - 接收方可以接收的最大数据量（以字节为单位）。
  - 用于流量控制。
校验和（Checksum）
- 长度：16 位
- 描述：
  - 检验 TCP 头部、数据及伪首部是否有错误。
紧急指针（Urgent Pointer）
- 长度：16 位
- 描述：
  - 指向紧急数据的最后一个字节。
  - 仅在 URG 标志被设置时有效。
选项（Options）
- 长度：可变（不定长度，4 字节对齐）。
- 描述：
  - 提供额外功能，如最大分段大小（MSS）、时间戳等。
填充（Padding）
- 长度：可变
- 描述：
  - 填充使头部长度对齐到 4 字节。

TCP头部的基础长度

固定部分：20 字节
- 包含源端口、目标端口、序列号、确认号、数据偏移、保留位、控制标志、窗口大小、校验和、紧急指针。
可变部分：选项字段 + 填充字段
- 如果有选项字段，头部长度会超过 20 字节。

TCP头部字段可视化

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


  0      4      8      12     16     20     24     28     32
+-----------------------------------------------------------+
|      Source Port       |    Destination Port             |
+-----------------------------------------------------------+
|                        Sequence Number                   |
+-----------------------------------------------------------+
|                    Acknowledgment Number                 |
+-----------------------------------------------------------+
| Data  | Res |  Control Flags |      Window Size          |
| Offset| 0   |                |                           |
+-----------------------------------------------------------+
|       Checksum          |    Urgent Pointer             |
+-----------------------------------------------------------+
|          Options (if any)         |       Padding        |
+-----------------------------------------------------------+

TCP头部的功能

可靠传输：
- 通过序列号、确认号保证数据顺序和可靠性。
流量控制：
- 使用窗口大小字段实现接收方控制发送速度。
错误检测：
- 校验和字段提供完整性检查。
连接管理：
- 使用 SYN、ACK、FIN 等标志控制连接的建立、维持和释放。

TCP头部与UDP头部的区别

特性	TCP头部	UDP头部
最小长度	20 字节	8 字节
数据可靠性	序列号+确认号，保证可靠性	无可靠性机制
流量控制	窗口大小实现	无
错误检测	校验和字段检测	校验和字段检测
连接状态管理	SYN/ACK/FIN 管理连接	无连接

网络模型通常分为以下两种主要模型，它们定义了网络通信的分层结构：

1. OSI 七层模型（开放系统互联参考模型）

OSI 模型是理论上的分层模型，帮助理解和设计网络协议。它分为七层：

层次	名称	功能描述	协议/设备示例
7. 应用层	Application Layer	面向用户，提供网络服务功能，比如文件传输、邮件、Web 浏览等。	HTTP、FTP、SMTP、DNS、Telnet
6. 表示层	Presentation Layer	数据格式转换、加密解密、压缩等功能。	JPEG、GIF、TLS
5. 会话层	Session Layer	建立、管理和终止会话，比如维持用户与服务器之间的通信会话。	NetBIOS、RPC
4. 传输层	Transport Layer	负责端到端通信、错误校验、数据流控制，提供可靠的传输。	TCP、UDP
3. 网络层	Network Layer	负责路由选择、寻址和数据包传输，确保数据能够跨网络传递。	IP、ICMP、ARP、OSPF
2. 数据链路层	Data Link Layer	将数据打包成帧，负责节点到节点之间的通信，包括差错检测和流量控制。	Ethernet、PPP、Wi-Fi、MAC 地址
1. 物理层	Physical Layer	负责数据的物理传输，定义硬件接口、电压标准、数据传输速率等。	网线、光纤、无线信号

2. TCP/IP 四层模型

TCP/IP 模型是实际网络中最常用的模型，与 OSI 模型类似，但层数更少，更注重实现。分为四层：

层次	名称	功能描述	协议/设备示例
4. 应用层	Application Layer	包括 OSI 的应用层、表示层和会话层，提供用户接口和数据服务。	HTTP、FTP、SMTP、DNS、Telnet
3. 传输层	Transport Layer	与 OSI 的传输层功能类似，负责端到端通信和数据完整性。	TCP、UDP
2. 网络层	Internet Layer	类似 OSI 的网络层，负责数据包的寻址和路由。	IP、ICMP、ARP
1. 网络接口层	Network Interface Layer	包括 OSI 的数据链路层和物理层，负责设备之间的数据帧传输。	Ethernet、Wi-Fi、MAC 地址

3. OSI 与 TCP/IP 模型对比

OSI 七层模型	TCP/IP 四层模型	功能示例
应用层、表示层、会话层	应用层	文件传输、邮件、Web 浏览等
传输层	传输层	端到端通信、可靠性保障
网络层	网络层	IP 地址寻址、路由选择
数据链路层、物理层	网络接口层	数据链路控制、电信号传输

总结

OSI 七层模型： 理论模型，详细且适合学习网络概念。
TCP/IP 四层模型： 实际应用中的主流模型，更简单，适用于工程实践。

流量控制是网络传输中为了防止发送方发送的数据过快，导致接收方无法及时处理而采取的机制。流量控制的目的是保证数据通信的稳定性和可靠性，通常在 传输层 通过协议（如 TCP）实现。以下是流量控制的详细过程：

1. 流量控制的概念

流量控制是指对发送方的数据发送速率进行管理，避免接收方因为处理能力不足而丢包。其本质是通过双方协作调整数据发送的节奏。

2. 流量控制的主要机制

(1) 基于窗口的流量控制（TCP 的滑动窗口）

TCP 使用滑动窗口机制动态调整发送方的发送速率，具体步骤如下：

窗口大小的概念：
- 发送窗口（Sender Window）： 发送方允许发送但未被确认的数据范围。
- 接收窗口（Receiver Window）： 接收方能接受的数据量，由接收方通告给发送方。
滑动窗口的工作过程：
- 初始状态：
  - 接收方在握手过程中通过 ACK 包通告自己的接收窗口大小。
  - 发送方根据接收窗口决定一次性发送的数据量。
- 动态调整：
  - 当接收方处理完数据并发送 ACK，窗口右边界滑动，发送方可以继续发送更多数据。
  - 如果接收方处理缓慢或缓存满了，会将接收窗口设置为较小值甚至 0，通知发送方减少或停止发送。
零窗口的处理：
- 如果接收窗口为 0，发送方会停止发送数据，并定期发送窗口探测包（Window Probe），等待接收窗口恢复。

(2) 基于速率的流量控制

此机制直接限制发送数据的速率，常见于应用层或协议层的特定实现中。发送方根据接收方反馈或者自身的速率限制算法控制发送速率。

3. TCP 流量控制的详细过程

以下是 TCP 流量控制的具体工作流程：

三次握手时协商窗口大小：
- 在握手阶段，接收方通告自己的初始接收窗口大小，发送方根据这个值决定发送速度。
数据传输中动态调整：
- 发送方将窗口分成多个分片进行传输，每个分片的大小不能超过接收窗口的大小。
- 接收方通过 ACK 报文反馈接收情况，并告知新的窗口大小。
处理丢包和网络拥塞：
- 如果发送的数据超出了接收方的处理能力，接收方可能丢弃部分数据，并通过窗口缩小信号通知发送方减速。
- TCP 的流量控制会与拥塞控制配合，避免网络阻塞。
数据传输结束：
- 当接收方收到所有数据并关闭连接，发送方停止数据发送。

4. 流量控制 vs 拥塞控制

流量控制：
- 侧重于端到端通信的发送方和接收方之间，避免接收方处理不过来。
- 针对接收方的处理能力。
拥塞控制：
- 侧重于网络中间节点，避免网络过载。
- 针对网络带宽和链路负载。

5. 实现流量控制的典型协议

TCP：
- 使用滑动窗口和动态调整机制实现流量控制。
- 面向连接，适用于需要高可靠传输的场景。
UDP（不自带流量控制）：
- 需要在应用层通过自定义逻辑（如限制发送速率、接收方反馈）来实现。

总结

流量控制的核心在于通过发送方和接收方协作动态调整发送速率，常见的滑动窗口机制在 TCP 中实现得尤为成熟。流量控制与拥塞控制相辅相成，共同保证网络通信的高效性和可靠性。

拥塞避免（Congestion Avoidance）是网络中防止因数据过载导致网络性能下降的一种机制，特别是在TCP协议中，它是网络流量控制的一部分。拥塞避免旨在通过合理控制数据的发送速率，避免网络中出现过多的数据包导致拥塞，从而影响数据传输的效率和稳定性。

1. 拥塞控制的概述

在TCP协议中，拥塞控制包括四个主要阶段：

慢启动（Slow Start）
拥塞避免（Congestion Avoidance）
快速重传（Fast Retransmit）
快速恢复（Fast Recovery）

在这些阶段中，拥塞避免阶段主要负责在避免拥塞的同时保持较高的网络利用率。

2. 拥塞避免的过程

拥塞避免阶段主要依赖于慢启动阶段完成初步的探测后，开始稳定地增加发送速率。其过程通常包括以下几个关键步骤：

(1) 拥塞窗口（cwnd）

拥塞窗口（Congestion Window，简称 cwnd）是TCP拥塞控制中用来控制发送数据量的一个重要变量。它表示TCP发送方可以发送的数据量。
在拥塞避免阶段，cwnd的增加方式与慢启动阶段不同，它更为缓慢。

(2) 慢启动结束，进入拥塞避免

慢启动阶段快速增长的拥塞窗口会在达到一个阈值时，转为拥塞避免阶段。
这个阈值称为慢启动阈值（ssthresh）。当拥塞窗口 cwnd 达到该值时，慢启动阶段结束，进入拥塞避免阶段。

(3) 线性增长

在拥塞避免阶段，cwnd 的增长速度变得更慢，采用的是线性增长。
每收到一个确认应答包（ACK），cwnd 会增加 1 个最大报文段（MSS）。具体来说，每经过一次 RTT（往返时延），cwnd 增加 1 MSS，这意味着窗口增长较为平缓，不会像慢启动阶段那样快速增大。
这种方式可以防止发送过多的数据包导致网络拥塞。

(4) 拥塞发生时的处理

如果发生丢包（通常是通过超时或三重重复ACK来判断），表明发生了网络拥塞。此时，TCP会采取拥塞控制措施：
- 将 cwnd 降到初始值（通常是 1 MSS）。
- 将慢启动阈值 ssthresh 设置为当前 cwnd 值的一半。
- 重新进入慢启动阶段，以较慢的速度进行探测，逐步增加 cwnd。

(5) 平衡网络带宽

拥塞避免的目标是使得传输速率稳定在一个合理的值，尽量使得网络利用率最大化，但又不会导致过度的拥塞。
当网络负载较低时，TCP 会逐步增大 cwnd 以提高数据传输速率；当网络拥塞发生时，TCP 会通过减小 cwnd 来避免过度拥塞。

3. 拥塞避免与慢启动的关系

慢启动： 在连接开始时，cwnd 从 1 MSS 开始，每经过一个RTT就指数性增长，直到达到阈值 ssthresh。
拥塞避免： 一旦 cwnd 达到 ssthresh，TCP 进入拥塞避免阶段，cwnd 按照线性增长的方式增加，每经过一个 RTT 增加 1 MSS。这个阶段的目的是为了避免在网络中迅速产生过多的数据包，防止拥塞。

4. 拥塞避免算法 - 增加和减少策略

增加： 在拥塞避免阶段，cwnd 每经过一次 RTT 会增加 1 个 MSS。通过这种平缓的增长方式，TCP 尝试维持较为稳定的发送速率，避免过度拥塞。
减少： 当网络发生拥塞时（通常通过丢包或重复 ACK 检测到），TCP 会将 cwnd 降低到 1 MSS，并进入慢启动阶段。ssthresh 会被设置为 cwnd 的一半，保证在下一次慢启动时不会过快地增加窗口。

5. 拥塞避免的关键点

线性增长： 在拥塞避免阶段，cwnd 的增长是线性的，确保网络不会因为快速增长的发送窗口而过载。
拥塞检测： 通过丢包或重复的 ACK 信号，TCP 能够检测到网络中出现的拥塞，及时进行调整。
慢启动阈值（ssthresh）： 该阈值决定了何时从慢启动进入拥塞避免阶段。

6. 拥塞避免的其他算法

TCP 拥塞避免不仅限于基本的线性增长机制，还可以采用其他算法来优化拥塞控制。例如：

TCP Reno： 使用基本的慢启动、拥塞避免、快速重传和快速恢复等机制，采用加法增大、乘法减小的方式。
TCP NewReno： 是 TCP Reno 的改进版本，优化了快速重传的算法。
TCP Vegas： 在传统的 TCP Reno 上进行了优化，通过延迟估计来避免拥塞。

总结

拥塞避免 是防止网络发生拥塞并优化数据传输的关键机制，它通过逐渐线性增加发送窗口（cwnd）来控制数据发送速率。
拥塞控制不仅包括拥塞避免，还有其他机制如慢启动、快速重传和快速恢复，所有这些共同协作，确保了网络通信的稳定和高效。

cwnd（拥塞窗口）和 Sender Window（发送窗口）是两个相关但不同的概念，虽然它们都影响 TCP 连接中发送方的传输速率，但它们的作用和定义有所不同。

1. cwnd（拥塞窗口）

定义： cwnd 是 TCP 协议中的一个控制变量，它表示发送方在网络中可以发送的数据量（以字节为单位）。cwnd 主要由 TCP 协议根据网络的拥塞情况动态调整，目的是控制发送速率，避免过多的数据包在网络中导致拥塞。
功能： cwnd 的大小会根据网络状况（如丢包、延迟等）变化。在拥塞避免阶段，cwnd 是通过线性增加来控制发送数据的速率；在发生丢包时，cwnd 会被减小，并进入慢启动或快速恢复阶段。

2. Sender Window（发送窗口）

定义： Sender Window 是由接收方通告的窗口大小，表示接收方可以接收的数据量。它由接收方通过 TCP 报文的窗口字段（window size）来通知发送方。这个窗口大小表明发送方可以在不等待确认的情况下发送的最大数据量。
功能： 发送窗口大小通常受到接收方的缓冲区大小和处理能力的限制。接收方通过在每个 TCP 数据包中告知窗口大小来控制发送方的数据发送速率。

3. cwnd 与 Sender Window 的关系与区别

关系：
- cwnd 和 Sender Window 共同决定了发送方在某一时刻可以发送的数据量。发送方不能发送超过 cwnd 或 Sender Window 中较小的一个值的数据。
- 当 TCP 发送方发送数据时，它必须确保发送的数据量不超过 cwnd 和 Sender Window 的最小值。即，min(cwnd, Receiver Window) 决定了发送方可以发送的最大字节数。
区别：
- cwnd 是由发送方根据网络的拥塞情况动态调整的，它表示网络的可用带宽和网络拥塞状况。cwnd 主要与网络状况相关。
- Sender Window 是接收方通过 TCP 报文头部的 window size 字段通知发送方的，它反映了接收方的接收能力，具体受接收方的缓冲区大小和处理能力限制。

总结

cwnd 控制发送方的发送速率，反映了网络的拥塞状况。
Sender Window 反映了接收方的接收能力，控制着发送方可以发送的数据量。
在实际数据传输中，发送方只能发送 min(cwnd, Receiver Window) 大小的数据量。

这两者相互配合，共同调节数据传输速率，确保数据能够高效且稳定地在网络中传输。

TCP的拥塞控制是为了解决网络拥塞问题，避免过多的数据在网络中发送而导致网络性能下降，甚至崩溃。TCP协议通过使用多个机制来控制网络中的数据流，包括 拥塞窗口（Congestion Window, cwnd） 和 接收窗口（Receiver Window, rwnd）。它们都涉及数据流的控制，但有不同的侧重点和功能。

1. 接收窗口 (Receiver Window, rwnd)

接收窗口是由接收方（Receiver）维护的，用来表示接收方缓冲区的剩余空间。它的作用是告知发送方自己能够接收的数据量，防止接收方的缓冲区被溢出。

rwnd 由接收方的应用程序的接收缓冲区大小决定。
rwnd 的大小会随接收方的缓冲区空间变化而动态调整。如果接收方的缓冲区空间不足，它会向发送方报告一个较小的接收窗口，告知发送方不能再发送过多的数据。

2. 拥塞窗口 (Congestion Window, cwnd)

拥塞窗口是由发送方维护的，它用于控制发送方的发送速率。拥塞窗口的大小决定了发送方在网络中可以发送的最大数据量，避免由于过多的数据注入网络造成拥塞。

cwnd 由发送方基于网络的当前状态进行动态调整。TCP协议会根据网络的拥塞情况来增加或减少这个窗口的大小。具体来说，TCP会根据网络的反馈（如丢包、RTT等）来调整cwnd：
- 慢启动：开始时cwnd会快速增长。
- 拥塞避免：当网络出现拥塞时，cwnd会增加的速度减慢。
- 快重传与快恢复：如果丢包发生，cwnd会迅速减小，避免继续导致拥塞。

3. 二者的区别

接收窗口（rwnd） 关注的是接收方的能力，表示接收方的缓冲区大小；它的大小由接收方决定，并且在接收方的通知中发送给发送方。
拥塞窗口（cwnd） 关注的是网络的状态，表示发送方为了避免拥塞而控制发送速率的窗口。它由发送方根据网络的反馈信息（如RTT、丢包等）动态调整。

4. 协同工作

当发送方准备发送数据时，它会根据 rwnd 和 cwnd 中的较小值来决定可以发送的数据量。因此，TCP的数据流控制不仅受到接收方的接收能力限制（rwnd），还受到网络的拥塞状态限制（cwnd）。

如果 rwnd > cwnd，则发送方主要受到拥塞控制的限制。
如果 cwnd > rwnd，则发送方主要受到接收方的缓冲限制，避免接收方数据溢出。

5. 实际数据流控制

每次发送方发送数据时，它会根据当前 min(cwnd, rwnd) 的值来决定可以发送多少数据。
cwnd 是网络控制的核心，决定了发送方的数据发送速率；rwnd 则是接收方的能力限制。

总结

Receiver Window (rwnd): 接收方的缓冲区空间，告诉发送方可以接收的数据量。
Congestion Window (cwnd): 发送方根据网络的状态（如拥塞情况）调整的数据发送量的限制。

这两个窗口配合工作，共同保证数据的流量控制和拥塞管理，确保TCP连接的可靠性和稳定性。

文章目录

SSL

缓存的几个问题

1. 缓存雪崩

定义

解决方法

2. 缓存穿透

定义

解决方法

3. 缓存击穿

定义

解决方法

总结

TCP头部结构

TCP头部的基础长度

TCP头部字段可视化

TCP头部的功能

TCP头部与UDP头部的区别

1. OSI 七层模型（开放系统互联参考模型）

2. TCP/IP 四层模型

3. OSI 与 TCP/IP 模型对比

总结

1. 流量控制的概念

2. 流量控制的主要机制

(1) 基于窗口的流量控制（TCP 的滑动窗口）

(2) 基于速率的流量控制

3. TCP 流量控制的详细过程

4. 流量控制 vs 拥塞控制

5. 实现流量控制的典型协议

总结

1. 拥塞控制的概述

2. 拥塞避免的过程

(1) 拥塞窗口（cwnd）

(2) 慢启动结束，进入拥塞避免

(3) 线性增长

(4) 拥塞发生时的处理

(5) 平衡网络带宽

3. 拥塞避免与慢启动的关系

4. 拥塞避免算法 - 增加和减少策略

5. 拥塞避免的关键点

6. 拥塞避免的其他算法

总结

1. cwnd（拥塞窗口）

2. Sender Window（发送窗口）

3. cwnd 与 Sender Window 的关系与区别

总结

1. 接收窗口 (Receiver Window, rwnd)

2. 拥塞窗口 (Congestion Window, cwnd)

3. 二者的区别

4. 协同工作

5. 实际数据流控制

总结