《计算机网络自顶向下方法？《计算机网络自顶向下方法》

计算机网络自顶向下方法

IO 复用技术epoll select polling Reactor 和Proactor 模式的区别、阻塞非阻塞、同步和异步浏览器搜索过程计算机断线故障排除TCP/IP 5 层网络模型网络协议Http Https HTTP 状态码HTTP 常用字段GET 和POST HTTP1 . 1 HTTP 和HTTPS 对称和非对称加密TLS 握手过程HTTP 和RPCIP 协议DNS 域名解析协议ARP 协议NATDHCP 协议TCPTCP 和UDP 之间的差异，实现可靠的UDP 传输Cookie 和会话三路握手和四路挥手1.TCP 重传机制2、滑动窗口3、流量控制4、拥塞控制1、慢启动2、拥塞避免3、拥塞发生

IO多路复用技术

通信双方都有socket，这个fd也对应了内核内部的缓冲区空间。缓冲区在一侧写入，在另一侧读取。 IO 指的是对缓冲区的操作。多路复用允许程序同时侦听多个文件描述符。

epoll select poll的区别

select/poll/epoll都是内核向用户态提供的复用系统调用。

不同之处：

select 和poll 发现的文件描述符集是在用户模式下创建的，并且每次调用都必须从用户模式复制到内核。而epoll从创建的时候起就在内核空间中创建。为了判断一个文件描述符是否准备好，选择和轮询必须遍历整个文件描述符集合，遍历的时间复杂度为O(n)。 epoll使用内核的事件驱动机制，由于硬件支持，只有当文件描述符准备好时才返回。时间复杂度为O(1)。 select 和Paul 都只能工作在效率相对较低的LT 模式下，而epoll 同时支持LT 和ET 模式。

水平触发：当一个文件描述符准备好时，会持续通知应用程序，直到应用程序处理该事件。 边沿触发器：从文件描述符读取和写入数据（通常在循环中），仅通知应用程序一次。一次读取尽可能多的数据。一般来说，边缘触发比水平触发更高效，因为它们可以减少系统调用次数并减少开销。如果您要监控的FDS 数量较少，我们建议使用select 和Paul。如果你有大量的FDS需要监控，epoll可以显着提高性能。 epoll 在内核中使用“红黑树”来跟踪进程中发现的所有套接字。

epoll是同步还是异步？

epoll 通常被认为是一种介于传统同步I/O 和完全异步I/O 之间的机制。

同步：epoll通过epoll_wait()系统调用告诉应用程序哪些文件描述符已经准备好。应用程序收到通知后必须执行实际的I/O操作。这种模式接近于同步I/O。

异步：epoll 允许应用程序注册特定的I/O 事件，当这些事件发生时操作系统会自动通知应用程序。此机制消除了应用程序轮询I/O 状态的需要，这是异步I/O 的一个关键功能。

因此，它提供了一种总体上同步但更接近异步I/O的编程模型。

Reactor模式和Proactor模式，阻塞非阻塞，同步异步

从数据流的角度来看，Reactor和Proactor模式分别是串行连接、阻塞和非阻塞、同步和异步。

数据流大致可以分为两个阶段。 [1] 数据已通过网络发送，尚未到达内核缓冲区- [2] 数据已到达内核缓冲区，但尚未复制到进程

当客户端请求到达时，可能是来自新客户端的连接请求，也可能是来自已连接客户端的数据请求。

如果在它到达之前什么都不做，它就会被阻塞。您可以先运行一些其他代码，然后在一段时间后再次检查请求是否已到达，而不是等待。这是一个轮询的想法，并且是非阻塞的。阻塞和非阻塞都发生在数据准备阶段，但都需要线程主动参与数据准备过程，而且都是同步IO，虽然等待方式不同。

数据已到达内核缓冲区，需要复制到进程缓冲区。此时需要接受并阅读。我现在遇到了问题。读取和接受是否由工作线程完成？

Reactor模式：主线程只负责监听和分发事件。即主线程通知工作线程执行读取和接受。读取和接受都是IO过程，工作线程要等待IO时间。这种情况是同步IO

Reactor模式灵活多变。在多反应器模式下，一个主反应器监视新连接的到达，其他几个子反应器监视已建立的连接。 不需要。运行io 需要一个工作线程。 aio_read 和aio_accept 完成后，它们在线程池中启动一个工作线程并将其加载到进程空间中。无需浪费工作线程处理业务逻辑。这是异步IO

Reactor和Proactor都是基于“事件分发”的网络编程模型。不同之处在于，Reactor 模型基于“待完成”的I/O 事件，而Proactor 模型基于“已完成”的I/O。事件。

同步和异步的区别在于数据准备好之后接下来的读写操作谁来读写。

同步是指整个数据读取过程由请求者自己完成。

异步是指请求者通知操作系统处理读写，操作系统处理其他工作，等待操作系统完成这个事件，然后请求者进行自己的业务处理。

浏览器搜索过程

解析URL：例如，应请求哪些文件以及在何处请求。 DNS查询以获取IP地址

浏览器首先检查操作系统自己的缓存hosts文件。本地域名服务器：本地DNS服务器通常是网络运营商（移动、电信）或顶级域名的服务器地址。对于名称服务器，权威域名服务器生成以下请求消息： 在这里，该文件执行其操作。请求行、请求头、空行、请求体的三次握手建立TCP链接并发送HTTP请求。

发送数据包时，如果目标IP不是本地局域网，则MAC地址将是下一跳路由器，该路由器将转发到下一个路由器，直到转发到与目标主机相连的路由器。如果发现目标IP地址是自己局域网内的主机，则通过ARP（地址解析协议，IP-MAC地址）请求获取目标主机的MAC地址，并转发到这台服务器主机。在转发过程中，源IP地址和目的IP地址不会发生变化（假设：不使用NAT网络），但源MAC地址和目的MAC地址会发生变化。 远程服务器处理请求并返回响应。浏览器解析并呈现响应。

电脑断网排查

请先重新启动。

查看机器右下角的网络连接状态，预先判断是网络配置问题还是物理连接问题。

如果是物理连接问题，请确保所有网络硬件（例如网线、交换机和路由器）均已正确连接。

http状态码可以分为五类：

1xx状态码是临时响应，在实践中很少使用。

2xx 状态码表示服务器成功处理了客户端的请求。

例如，通用200 OK 表示一切正常。

3xx状态码表示客户端请求的资源发生了变化，客户端必须重新提交请求才能使用新的URL获取资源。实际上，这通常是重定向。

例如，“301”永久重定向意味着所请求的资源不存在，必须使用新的URL 再次访问。您的浏览器会自动将您重定向到新的URL。

“302”是临时重定向，表示所请求的资源仍然存在，但应使用不同的URL 临时访问。

“304”表示资源没有改变，客户端可以继续使用缓存的资源。

4xx状态码表示客户端发送的消息不正确，服务器无法处理。这是客户端错误代码。

最常见的是，“404 Not Found”表示请求的资源在服务器上不存在或无法找到，因此服务器无法提供该资源。

5xx 状态码表示客户端请求的消息正常，但服务器在处理该消息时遇到内部错误。这是服务器端错误代码。

“503服务不可用”表示服务器当前正忙，暂时无法响应客户端。这类似于“网络服务正忙，请稍后重试”。

TCP/IP五层网络模型

host字段指定客户端发送请求时服务器的域名。

Content-Type字段在服务器响应时使用，告诉客户端本次响应中数据的格式。

Content-Length字段在服务器响应时使用Content-Length来指示本次响应的数据长度。

网络协议

GET 和POST 都是HTTP 请求方法。

Get请求通常用于请求静态文本、页面、图像和视频等资源。 Post请求通常用于根据请求处理指定的资源，例如发送数据或创建数据。

get请求的参数会显示在地址栏中，但是这样安全性较差，而且浏览器也可能会限制参数的长度。在post请求中，传递的参数放在请求体中，不会显示在地址栏中。它安全性较低，获取请求速度较快，并且对参数长度没有限制。

get请求不会影响服务器刷新或回滚。如果post请求被回滚，数据请求将会重新提交。

Http Https

HTTP 最显着的优点是它的简单性和灵活性。

1 无状态，用cookie解决

2使用HTTPS解决明文发送内容容易被盗的问题

HTTP状态码

HTTP是一种超文本传输协议，意味着信息以明文形式发送，这会带来安全风险。 HTTPS解决了HTTP的安全缺陷，在TCP和HTTP网络层之间添加了TLS安全协议，允许消息加密发送。建立HTTP 连接相对简单，允许在TCP 三向握手后发送HTTP 消息。在TCP 的三向握手之后，HTTPS 必须执行TLS 握手过程才能开始发送加密消息。 HTTP 的默认端口号是80，HTTPS 的默认端口号是443。

问题描述：HTTP请求和响应均以明文形式发送，存在安全风险。

HTTPS：HTTPS 在TCP 和HTTP 之间添加了SSL/TLS 安全协议，SSL 是当今最常用的TLS 的前身。

HTTP 常见字段

对称加密：发送者和接收者同意相同的规则，因此使用相同的密钥来加密和解密所发送的信息。

非对称加密：使用两个密钥进行加密和解密。公钥是任何人都可以获得的密钥，而私钥是只有所有者知道的密钥。通常，服务器有公钥和私钥，客户端使用该公钥来加密数据。此时只能解密服务器上的私钥。

GET 和 POST

TLS 同时使用对称和非对称加密。

首先，服务器必须向CA证书颁发机构申请证书，以证明它是经过验证的正版服务器，而不是假冒服务器。 TCP 3 次握手后，TLS 握手开始。客户端将其支持的TLS版本、其支持的加密算法以及随机数（第一个随机数）发送到服务器。服务器用其验证的TLS 版本、加密算法和它生成的随机数（第二个随机数）进行响应，并继续发送自己的证书和公钥。客户端验证服务器的证书后，会生成预主密钥（第三个随机数），使用收到的公钥对其进行加密，然后发送。服务器收到后，用自己的私钥解密，得到客户端的预主密钥。此时，只有客户端和服务器知道预主密钥，除非私钥被泄露。然后客户端和服务器都使用预主密钥+第一个随机数+第二个随机数计算会话密钥。也就是说，在这一步中，前面的加密是非对称加密，而后续的实际数据传输目的是使用这个会话密钥进行加密和解密，所以正常的数据传输部分是采用对称加密。

HTTPS连接过程的可靠性是否有保障？

当客户端通过浏览器向服务器发起HTTPS请求时，请求被“假基站”转发到“中间服务器”，客户端与“中间服务器”完成TLS握手。然后这个“中间服务器”运行并完成与真实服务器的TLS 握手。

从客户端的角度来看，客户端实际上并不知道网络内存在中间服务器角色。然后中间服务器可以解密浏览器发起的HTTPS请求中的数据，以及服务器响应浏览器的HTTPS响应数据。

然而，这是有先决条件的。这意味着用户单击接受中间服务器的证书。

在中间服务器与客户端之间的TLS握手过程中，中间服务器将自己伪造的证书发送给浏览器，而这个伪造的证书被浏览器识别为非法，从而使用户意识到中间服务器存在问题。您将会收到一些通知。证书。

HTTP1.1

HTTP 和RPC 都是从TCP 派生的协议。

TCP是20世纪70年代出现的协议

RPC出现于20世纪80年代

HTTP 直到20 世纪90 年代才开始流行。

RPC，也称为远程过程调用，本身并不是一种特定的协议，而是一种调用方法。这里强调的是，我们希望在调用远程方法时能够像调用本地方法时一样方便地保护细节。

目前，很多C/S模式的软件必须与自己的服务器建立连接，才能作为客户端发送和接收消息。在这种情况下，您可以使用自己的RPC协议，因为您只需要连接到自己的服务器。

然而，对于浏览器来说，它不仅需要能够访问自己的服务器，还需要能够访问其他公司网站的服务器，所以除非有统一的标准，否则大家将无法进行通信。因此，当时用来整合B/S的协议就是HTTP。

RPC更加定制化，可以使用更小的Protobuf或者其他序列化协议来存储结构数据。您不必考虑HTTP 等不同的浏览器行为，例如302 重定向跳转。

HTTP主要用于B/S架构，而RPC更多用于C/S架构。然而，目前这种区别并不那么明显。 HTTP协议一般用于外部，RPC协议用于集群内部微服务之间的通信。

HTTP 与 HTTPS

IP协议是网络层的核心协议之一，负责路由和转发数据包，保证数据包从源地址发送到目的地址。

P地址（IPv4地址）由一个32位正整数表示，分为四组，每组8位。

IP 地址是根据您的网卡设置的。 IP 地址将与网卡的数量相同。

IPv4地址为32位，IPv6地址为128位，即使在没有DHCP服务器的情况下也会自动分配IP地址，即插即用方便。

IP地址分类

IP地址分为五类：A类、B类、C类、D类、E类。 A、B、C类主要分为两部分：网络号+主机号。 D 类通常用于多播。 E类为保留类别，暂时不会使用。

第0 个：A 类。第2 位数字0：B 类。

划分

未分类地址CIDR：分类地址的概念消失了，IP地址被分成两部分，前面是网络号，后面是主机号。 10.100.122.2/24 子网掩码：屏蔽主机号，其余为网络号。网络号是通过对子网掩码和IP 地址进行按位与运算而获得的。

子网掩码的另一个特点是子网分裂，它将主机地址分为两部分：子网地址和子网主机地址。即网络地址+子网地址+主机地址。

使用网络地址192.168.1.0 和子网掩码255.255.255.192 进行子网划分。

C类地址的前24位是网络号，后8位是主机号。根据子网掩码，从8位主机号中借用2位作为子网号。

子网网络地址分为两位数，因此有四种：00、01、10和11。

对称加密与非对称加密

域名——IP地址

TLS握手过程

IP地址–MAC地址

发送IP数据报时，确定源IP地址和目的IP地址后，通过主机的“路由表”确定IP数据包的下一跳。网络层之后的下一层是数据链路层，因此我们还需要知道“下一跳”的MAC地址。

ICMP

ICMP的主要功能是检查IP数据包是否成功传送到其目的地址，并报告IP数据包在传输过程中被丢弃的原因。

HTTP和RPC

IPv4 地址非常短缺。我们还提到，使用非保密地址可以减缓IPv4地址的耗尽，但互联网用户的增长速度如此惊人，以至于IPv4地址仍然面临着耗尽的风险。

网络地址转换NAT的提出是为了缓解IPv4地址耗尽的问题。

简单来说，NAT 就是同一企业、家庭或教室内的主机与外界通信时，将私有IP 地址转换为公共IP 地址。

例如，假设两个客户端192.168.1.10 和192.168.1.11 同时与服务器183.232.231.172 通信，并且两个客户端的本地端口都是1025。

此时，两个私网IP地址都已将其IP地址转换为公网地址120.229.175.121，但端口号不同。

IP协议

主要特点是在整个DHCP交互过程中使用UDP广播通信来动态获取IP地址。

DNS 域名解析协议

TCP是一种面向连接、可靠、基于字节流的传输层通信协议。

面向连接：与UDP协议允许消息同时从一台主机发送到多台主机不同，连接必须是“一对一”的。 真实性：有完善的安全机制保证真实性。数据传送；字节流：接收数据进行传输时，不考虑数据边界，而是将数据视为连续的字节流进行传输。

TCP格式头序列号：建立连接时计算机生成的随机数，作为SYN的初始值，每次发送数据时都变成++。发送方和接收方使用这些序列号来重新组装数据包。验证数据包顺序是否正确。确认号：您期望接收的下一个数据的ACK 序列号。当发送方收到这个ACK时，就可以认为这个序列号之前的数据已经被成功接收。用于解决丢包问题。

ARP协议

1. 连接

TCP 是面向连接的，需要建立连接才能发送数据。

UDP 不需要连接并立即发送数据。

2. 互动次数

TCP是一对一的通信。

UDP支持一对一、一对多、多对多通信

3、可靠性

TCP提供重传机制、滑动窗口机制、流量控制和拥塞控制来保证数据的可靠发送。

UDP 是尽力交付的，因此不能保证可靠的交付。

4.如何发送

TCP 是一种以字节流为中心的流式传输。

UDP 以数据包的形式发送，并且是面向消息的。

5、适用场景

TCP适合需要可靠传输的场景，例如文件传输。

UDP适合对可靠性要求不高的实时应用，例如视频会议、直播等。

NAT

在应用层实现：

数据包编号：每个传输的数据包都被分配一个唯一的序列号，以确保有序传输。确认机制：接收方收到数据报后，向发送方发送一条确认消息，其中包含收到的数据报的序列号。超时重传：发送方在发送数据报后启动一个定时器。如果在定时器超时之前没有收到确认，则重传数据报。滑动窗口：采用滑动窗口机制来控制数据传输速率和重传机制。窗口大小可以根据网络情况动态调整。流量控制：根据接收器的处理能力调整传输速率，防止接收器被大量数据淹没。拥塞控制：监控网络拥塞并相应调整数据传输速率，以减少数据包丢失和网络拥塞。数据完整性检查错误恢复

DHCP协议

曲奇饼

这是浏览器本地存储的一小段数据，通常不大于4KB。 Cookie 的出现是因为HTTP 是一种无状态机制，服务器无法记住客户端的信息。每次刷新网页时，您可能都需要重新输入帐户和密码才能登录。

会话会话

打开浏览器、访问链接、执行某些操作、然后关闭浏览器的整个过程称为会话。

会话是记录客户端状态的另一种机制。不同之处在于cookie存储在客户端的浏览器上，而session存储在服务器上。当客户端的浏览器访问服务器时，服务器会在服务器上记录客户端的信息。这样，当客户端的浏览器再次联系服务器时，只需要从本次会话中查找浏览器的信息即可。

存储位置不同。 Cookie 存储在浏览器端，Session 存储在服务器端。

存储容量各不相同。 Cookie 最多可存储4kB，但没有会话限制。

存储内容各不相同。 Cookie只能存储字符串，但Session存储结构类似于哈希表结构，可以存储任何类型。

安全级别不同：Cookie通常用于存储非敏感数据，因为Cookie存储在客户端，其内容很容易被拦截或伪造，而Session信息存储在服务器端，因此安全级别较高。被储存了。

TCP

最初，客户端和服务器都处于CLOSE 状态。首先，服务器主动监听处于LISTEN状态的特定端口，客户端初始化一个序列号，将其放入TCP头的序列号字段中，并将SYN标志设置为1，表示这是一个SYN报文。通过向服务器发送SYN 消息来启动与服务器的连接。报文发送后，进入SYN-SENT状态。服务器收到客户端的SYN报文后，随机初始化自己的序列号，并将其填充到TCP头的序列号字段中。然后在TCP 标头中输入client_isn + 1 作为确认编号，并添加SYN 和ACK。

标志位置为 1。最后把该报文发给客户端，该报文也不包含应用层数据，之后服务端处于 SYN-RCVD 状态。客户端收到服务端报文后，初始化一个应答报文，TCP 首部 ACK 标志位置为 1 ，「确认应答号」字段填入 server_isn + 1 ，最后把报文发送给服务端，这次报文可以携带实际数据，之后客户端处于 ESTABLISHED 状态。服务端收到客户端的应答报文后，也进入 ESTABLISHED 状态。
为什么是三次握手？
主要来说，三次握手主要是为了保证通信双方具有接收和发送的能力，并且三次握手也是防止历史连接初始化造成混乱的主要措施。
如果是用两次握手，可能会出现历史连接问题：
比如客户端发出连接请求，但因为网络延迟原因服务器没有收到，所以客户端第二次发送连接请求，这次服务器收到了然后返回确认开始连接传输释放连接。如果后面第一个经过延迟的请求到达了服务器，那服务端就会误以为客户端又发出了一个新的连接请求，于是就向客户端发出确认报文段，同意建立连接。而采用三次握手就可以解决这个连接的问题，减少不必要的资源浪费。

四次挥手

客户端打算关闭连接，发送一个 TCP 首部 FIN 标志位被置为 1 的报文，也即 FIN 报文，之后客户端进入 FIN_WAIT_1 状态。服务端收到该报文后，就向客户端发送 ACK 应答报文，接着服务端进入 CLOSE_WAIT 状态。客户端收到服务端的 ACK 应答报文后，之后进入 FIN_WAIT_2 状态。等待服务端处理完数据后，也向客户端发送 FIN 报文，之后服务端进入 LAST_ACK 状态。客户端收到服务端的 FIN 报文后，回一个 ACK 应答报文，之后进入 TIME_WAIT 状态服务端收到了 ACK 应答报文后，就进入了 CLOSE 状态。客户端在经过 2MSL 一段时间后，自动进入 CLOSE 状态。
如果服务端的第X次挥手丢失了，客户端就会触发超时重传机制，重传 xxx 报文，直到收到服务端的响应，或者达到最大的重传次数。如果还是没能收到服务端的 ACK 报文，那么客户端就会断开连接。
为什么挥手需要四次？
服务端收到客户端的 FIN 报文时，先回一个 ACK 应答报文表示我收到了你的FIN报文，但服务端现在可能还有数据需要处理和发送。
等服务端数据处理完后，也会发送 FIN 报文给客户端来表示现在OK，我可以现在关闭连接了。
从上面过程可知，服务端通常需要等待完成数据的发送和处理，所以服务端的 ACK 和 FIN 一般都会分开发送，需要四次挥手。
为什么 TIME_WAIT 等待的时间是 2MSL？
首先MSL 是报文最大生存时间，超过这个时间报文将被丢弃。
如果服务器没有收到断开连接的最后 ACK 报文，就会触发超时重发 FIN 报文，客户端接收到 FIN 后，会重发 ACK 给被动关闭方， 一来一去正好 2 个 MSL。
服务器出现大量 TIME_WAIT 状态的原因
首先如果服务器出现大量的 TIME_WAIT 状态的 TCP 连接，就是说明服务器主动断开了很多 TCP 连接。这可能是因为HTTP 没有在请求header里使用Keep-Alive长连接或者HTTP 长连接的请求数量达到上限。如果没有使用长连接，那么每次传数据的时候都要三次握手建立连接，传数据，然后四次挥手断开连接。

1、TCP重传机制

TCP 针对数据包丢失的情况，会用重传机制解决。
超时重传
就是在发送数据时，设定一个定时器，当超过指定的时间还没有收到对方的 ACK 确认应答报文，就会重发该数据。
RTT往返时延是数据包的往返时间，超时重传时间的值应该略大于报文往返 RTT 的值。
快速重传
不以时间为驱动，而是以数据驱动重传。
快速重传的工作方式是当收到三个相同的 ACK 报文时，会在定时器过期之前，重传丢失的报文段。
比如A给B发了1、2、3、4、5个报文，B收到1后应答2表示希望收到2，但是2丢失了，后面B收到3、4、5时都返回2，A收到了三个 Ack = 2 的确认，知道了 Seq2 还没有收到，就会在定时器过期之前，重传丢失的 Seq2。
【它依然面临着另外一个问题。发送方并不清楚这连续的 ACK2 是接收方收到哪个报文而回复的，是重传一个，还是重传所有的报文。】
选择性确认
在 TCP 头部「选项」字段里加一个 SACK数据，它可以将已收到的数据的信息发送给「发送方」，这样发送方就可以知道哪些数据收到了，哪些数据没收到，知道了这些信息，就可以只重传丢失的数据。

2、滑动窗口

我们都知道 TCP 是每发送一个数据，都要进行一次确认应答。当上一个数据包收到了应答了， 再发送下一个。这种方式的效率比较低。
所以TCP引入了窗口这个概念，窗口大小就是指无需等待确认应答，而可以继续发送数据的最大值。窗口实际上是操作系统开辟的一个缓存空间，发送方主机在等到确认应答返回之前，必须在缓冲区中保留已发送的数据。如果按期收到确认应答，此时数据就可以从缓存区清除。而且还会有累计应答，只要发送方收到了 ACK xx 确认应答，就意味着 xx 之前的所有数据「接收方」都收到了，这样即使之前有应答丢失了也没事。

3、流量控制

发送方不能无脑的发数据给接收方，要考虑接收方处理能力。如果一直无脑的发数据给对方，但对方处理不过来，导致网络流量的无端的浪费。TCP 提供一种机制可以让「发送方」根据「接收方」的实际接收能力控制发送的数据量。

TCP流量控制的主要机制是通过滑动窗口实现的。发送方根据接收方的窗口大小和网络情况动态调整自己的发送窗口大小。

4、拥塞控制

流量控制是避免「发送方」的数据填满「接收方」的缓存
拥塞控制是避免「发送方」的数据填满整个网络
拥塞窗口cwnd是发送方根据网络的拥塞程度而动态维护的一个的变量。
发送窗口的值 是拥塞窗口和接收窗口中的最小值。
拥塞控制三个阶段：慢启动-》拥塞避免-》拥塞发生

1、慢启动

有个ssthresh慢启动门限的变量
TCP 在刚建立连接完成后，首先是有个慢启动的过程，一点一点的提高发送数据包的数量，发包的个数是指数性的增长，也就是拥塞窗口1、2、4、8这样。
当 拥塞窗口cwnd 超过 ssthresh慢启动门限 时，开始「拥塞避免算法」。

2、拥塞避免

进入拥塞避免算法后,每当收到一个 ACK 时，拥塞窗口cwnd 增加 1，也就是变成了线性增长。所以还是增长阶段，只是增长速度缓慢了一些。

3、拥塞发生

一直增长后，网络就会慢慢进入拥塞的状况，于是就会出现丢包现象，需要对丢失的数据包进行重传。
我们知道，重传一般也就超时重传和快速重传。

当发生了「超时重传」，则就会使用拥塞发生算法。
ssthresh慢启动门限 设为 拥塞窗口的一半，拥塞窗口重置为 1(初始值)，然后重新进入慢启动阶段。
这种方式太激进，反应也很强烈，会造成网络卡顿。当发生了「快速重传」，使用快速恢复算法。
快速恢复算法是认为，你还能收到 3 个重复 ACK 说明网络也不那么糟糕。此时慢启动门限和拥塞窗口都设为原拥塞窗口的一半，然后重新进入拥塞避免阶段；

#以上关于《计算机网络自顶向下方法的相关内容来源网络仅供参考，相关信息请以官方公告为准！