计算机网络八股文

计算机网络八股文

第一章 计算机网络基础

1.1 OSI 七层参考模型及各自功能

七层参考模式是一个抽象的模型体，不仅包括一系列抽象的术语或概念，也包括具体的协议。 （物、数、网、传、会、表、应）

• 物理层：主要定义物理设备标准，如网线的接口类型、光纤的接口类型、各种传输介质的传输速率等。它的主要作用是传输比特流（就是由1、0转化为电流强弱来进行传输，到达目的地后再转化为1、0，也就是我们常说的数模转换与模数转换）。
• 数据链路层：进行硬件地址寻址、差错校验等功能。将比特组合成字节进而组合成帧，用MAC地址访问介质。
• 网络层：进行逻辑地址寻址，在位于不同地理位置的两个主机系统之间提供连接和路径选择，主要用于IP寻址和路由选择
• 传输层：定义了一些传输数据的协议和端口号，如：TCP（传输控制协议，传输效率低，可靠性强，用于传输可靠性要求高，数据量大的数据），UDP（用户数据报协议，与TCP 特性恰恰相反，用于传输可靠性要求不高，数据量小的数据）。 主要是建立、管理、维护端到端的连接。常常把这一层数据叫做段。
• 会话层：建立、管理和维护会话，使用校验点可使会话在通信失效时从校验点继续恢复通信。这种能力对于传送大的文件极为重要。
• 表示层：数据的表示、安全、压缩。主要是进行对接收的数据进行解释、加密与解密、压缩与解压缩等（也就是把计算机能够识别的东西转换成人能够能识别的东西（如图片、声音等）。
• 应用层：网络服务与用户的一个接口。这一层为用户的应用程序（例如电子邮件、文件传输和终端仿真）提供网络服务

每一层传输的数据叫什么？

• 传输层数据被称作tcp报文段或udp用户数据报（Segments）；
• 网络层数据被称做包（Packages）；
• 数据链路层时数据被称为帧（Frames）；
• 物理层时数据被称为比特流（Bits）。

1.2 在浏览器中输入网址后发生了什么

1. 域名解析：首先是从浏览器缓存里面寻找域名和IP地址对照表，如果找不到，再从本机操作系统的缓存里面去找这个对照表，如果仍然没有，则请求本地域名服务器解析
2. 域名解析完成之后，客户端需要和服务端建立TCP连接来实现通信，这个过程需要三次握手。
3. TCP连接建立之后，客户端向服务端发出HTTP请求，请求获取资源。
4. 服务端在收到客户端发出的请求后，响应请求，向客户端发送资源。
5. 对于从服务端收到的资源，浏览器解析HTML
6. 浏览器对页面进行渲染呈现给用户
7. 客户端与服务端均可主动断开TCP连接，这个过程需要四次挥手。

1.3 什么是DNS，工作原理是什么，域名解析为什么使用UDP协议？

定义：DNS（Domain Name System，域名系统），是域名和IP地址相互映射的一个分布式数据库，能够使用户更方便的访问互联网，而不用去记住IP数串。属于应用层协议，使用UDP传输。

工作原理：

1. 当用户输入域名时，浏览器先检查自己的缓存中是否包含这个域名映射的ip地址，有解析结束。若无，则检查操作系统缓存中有没有，有解析结束。 若无，则请求本地域名服务器解析（LDNS），有解析结束，若无，则委托LDNS询问根域名服务器，根域名服务器返回给LDNS一个gTLD（ 通用顶级域）。 此时LDNS再发送请求给gTLD，gTLD查找并返回这个域名对应的Name Server的地址，LDNS再发送请求给Name Server，Name Server根据映射关系表找到目标ip，返回给LDNS
2. LDNS缓存这个域名和对应的ip， 把解析的结果返回给用户，用户根据缓存到本地系统缓存中，域名解析过程至此结束

使用UDP协议的原因：UDP传输速度快，只要一个请求一个应答即可，而基于TCP的DNS协议需要三次握手、发送数据及应答、四次挥手等内容。但UDP协议传输内容不超过512个字节，不过客户端向DNS服务器请求查询域名时，一般返回的内容不超过512个字节，使用UDP传输即可。

第二章 HTTP协议（应用层）

HTTP 是超文本传输协议，是一个在两点之间传输文字、图片、音频、视频等超文本数据的约定和规范

状态码：

• 1xx：提示信息，不常用
• 2xx：成功，表示请求正常处理完毕（如200 OK）
• 3xx：重定向，客户端请求的资源发生了变动，需要客户端用新的URL重新发送请求获取资源
• 4xx：客户端发送的报文有误（400Bad Request请求语法错误，403Forbidden请求被拒绝，404Not Found请求不存在）
• 5xx：服务器处理时内部发生错误

常见字段：

• Host字段：客户端发送请求时用来指定服务器的域名
• Connection字段：用于客户端要求服务器使用HTTP长连接（Keep-Alive）机制，即只要任意一端没有明确提出断开连接，则保持 TCP 连接状态，在用户态实现。（与TCP的Keep-Alive不同，TCP的Keep-Alive本质上是**TCP的保活机制，在内核态实现。**如果对端程序是正常工作的，当TCP保活的探测报文发送给对端, 对端会正常响应，TCP保活时间会被重置，等待下一个TCP保活时间的到来；如果对端主机宕机（注意不是进程崩溃，进程崩溃后操作系统在回收进程资源的时候，会发送 FIN 报文，而主机宕机则是无法感知的，所以需要 TCP 保活机制来探测对方是不是发生了主机宕机），或对端由于其他原因导致报文不可达，当TCP保活的探测报文发送给对端后，石沉大海，没有响应，连续几次，达到保活探测次数后，TCP 会报告该 TCP 连接已经死亡。）
• Content-Length字段：服务器返回数据时表明回应数据的长度
• Content-Type字段：用于服务器回应时告诉客户端本次数据是什么格式
• Content-Encoding字段：表示服务器返回的数据用了什么压缩格式

2.2 HTTP请求方式中GET和POST的区别

1. GET 是从服务器获取指定的资源，可以是文本、图片、视频、音频等。GET 请求的参数位置一般是写在 URL 中，只能支持 ASCII，且长度有限。是安全（请求不会破坏服务器资源）和幂等（多次执行相同的操作，结果相同）的，可被浏览器缓存的。（为了在URL中支持非ASCII字符，需要进行一种编码操作，将这些字符转换为ASCII字符。最常见的方法是使用URL编码，其中非ASCII字符被转换成百分号（%）后跟两位十六进制表示的ASCII码。例如，中文字符 “你好” 在URL编码后可能会变成 “%E4%BD%A0%E5%A5%BD”。浏览器和服务器都会自动执行这种编码和解码操作，以确保在URL中传递非ASCII字符时不会引发问题。）
2. POST 是根据请求体对指定的资源做出处理，POST 请求携带数据的位置一般是写在报文 body 中，body 中的数据可以是任意格式的数据，且长度不限。是不安全、不幂等、不被缓存的。

2.3 HTTP缓存技术

HTTP有强制缓存和协商缓存两种缓存实现方式。

• 强制缓存是指只要浏览器缓存没有过期，则直接使用浏览器的本地缓存，决定是否使用缓存的主动性在于浏览器，通过Cache-Control（常用）和Expires响应头字段实现。

  • 当浏览器第一次请求访问服务器资源时，服务器会在返回这个资源的同时，在 Response 头部加上 Cache-Control，Cache-Control 中设置了过期时间大小；
  • 浏览器再次请求访问服务器中的该资源时，会先通过请求资源的时间与 Cache-Control 中设置的过期时间来判断该资源是否过期，如果没有，则使用该缓存，否则重新请求服务器；
  • 服务器再次收到请求后，会再次更新 Response 头部的 Cache-Control。

• 协商缓存是指通过服务器告知浏览器是否可以使用缓存的方式，需要配合强制缓存中 Cache-Control 字段来使用，只有在未能命中强制缓存的时候，才能发起带有协商缓存字段的请求。

2.4 HTTP的优缺点

优点：

• 简单：HTTP 基本的报文格式就是 header + body，header信息也是 key-value 简单文本的形式，易于理解，降低了学习和使用的门槛。
• 灵活和易于扩展：HTTP 协议里的各类请求方法、状态码等都没有被固定死，允许开发人员自定义和扩充。HTTP工作在应用层，下层也可以随意变化。
• 应用广泛和跨平台

缺点：

• 无状态：服务器不会去记忆HTTP的状态，可以减轻服务器的负担，但在完成有关联性的操作时会非常麻烦。
• 明文传输：传输过程中的信息是方便阅读的，通过浏览器的F12控制台用肉眼查看，为调试工作带来了便利性，但信息透明，容易被窃取。
• 不安全：一是通信使用明文，有可能被窃取；二是不验证通信方的身份，有可能遭遇伪装；三是无法证明报文的完整性，有可能已遭篡改。

可以用 HTTPS 的方式解决，也就是通过引入SSL/TLS 层，使得在安全上达到了极致。

2.5 HTTP与HTTPS有哪些区别？

• HTTP是超文本传输协议，信息是明文传输，不安。HTTPS则解决 HTTP 不安全的缺陷，在 TCP 层和 HTTP层之间加入了 SSL/TLS安全协议，使得报文能够加密传输。
• HTTP连接建立相对简单， TCP三次握手之后便可进行 HTTP 的报文传输。而 HTTPS 在 TCP三次握手之后，还需进行 SSL/TLS的握手过程，才可进入加密报文传输。
• 两者的默认端口不一样，HTTP默认端口号是 80，HTTPS默认端口号是 443。
• HTTPS协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的。

2.6 HTTPS的优缺点、加密方式、握手流程（高频）

优点：

• 在数据传输过程中，使用密钥加密，安全性更高
• 可认证用户和服务器，确保数据发送到正确的用户和服务器

缺点：

• 握手阶段延时较高，在会话前还需进行SSL/TLS握手
• 部署成本高，需要购买CA证书
• 需要加解密计算，占用CPU资源

加密方式：

• 对称加密：只使用一个密钥，运算速度快，密钥必须保密，无法做到安全的密钥交换
• 非对称加密：使用两个密钥，公钥可以任意分发而私钥保密，解决密钥交换问题，但速度慢。
• 混合加密：HTTPS使用的是对称加密和非对称加密的混合加密方式。在建立通信前采用非对称加密方式交换会话密钥，在通信过程中使用对称加密的会话密码加密明文数据。

SSL/TLS 握手流程：

1. 客户端发送一个SSL/TLS连接请求到服务器，发送的内容包括客户端生成的随机数（Client Random）和加密算法（如RSA加密算法）。
2. 服务器收到请求后向客户端发送一个响应，发送的内容包括数字证书、服务器的公钥、服务器生成的随机数（Server Random）和确认的加密算法等信息。
3. 客户端之后验证数字证书，以确保证书来自可信的证书颁发机构，没有被篡改。之后客户端又生成一个随机数（pre-master key）并使用服务器的公钥加密，发送给服务器。此时客户端有了Client Random、Server Random、pre-master key，利用加密算法生成了会话密码，客户端还通知服务器以后用会话密钥通信。
4. 服务器使用自己的私钥解密客户端发送的随机数（pre-master key）。此时服务端也有了Client Random、Server Random、pre-master key，利用加密算法生成了会话密钥，服务器也通知客户端以后使用会话密钥通信。
5. 之后双方使用对称的会话密钥加密通信。

2.7 HTTPS一定安全可靠吗

HTTPS 协议目前为止还是没有任何漏洞的，即使进行中间人攻击，本质上是利用了客户端的漏洞（用户点击继续访问或者被恶意导入伪造的根证书），并不是 HTTPS 不够安全。具体情况如下：

客户端通过浏览器向服务端发起 HTTPS 请求时，被假基站转发到了一个中间人服务器，于是客户端是和中间人服务器完成了SSL/TLS握手，然后这个中间人服务器再与真正的服务端完成SSL/TLS握手。

2.8 HTTP/1.1与HTTP/1.0相比，提高了哪些性能

• 默认使用长连接的方式改善了HTTP/1.0默认使用短连接造成的性能开销。
• 支持管道（pipeline）网络传输，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。

2.9 HTTP/2.0和HTTP/1.1的区别？

• 首部压缩：HTTP/1.1 不支持 header 数据的压缩，HTTP/2.0 使用 HPACK 算法对header 的数据进行压缩，这样数据体积小了，在网络上传输就会更快。
• 二进制格式：HTTP/2.0 不再像 HTTP/1.1 里的纯文本形式的报文，而是全面采用了二进制格式，头信息和数据体都是二进制，并且统称为帧（frame），实现低延迟和高吞吐量。
• 并发传输：允许同时通过单一的 HTTP/2.0 连接发起多重的请求-响应消息。
• 服务端推送：在 HTTP/2.0 中，服务器可以对客户端的一个请求发送多个响应，即服务器可以额外的向客户端推送资源，而无需客户端明确的请求。

第三章 TCP协议（运输层）

3.1 什么是TCP？为什么需要TCP协议？TCP的头格式是什么形式的？

定义：TCP是面向连接的、可靠的、基于字节流的传输层控制协议

• 面向连接：一定是一对一的连接
• 可靠的：无论网络链路中出现了怎样的链路变化，TCP都可以保证一个报文一定能够到达接收端
• 字节流：消息可能会被操作系统分组成多个TCP报文，并且TCP报文是有序的，当前一个TCP报文没有收到，即使收到了后面的TCP报文，也不会扔给应用层去处理，同时对于重复的TCP报文会自动丢弃

TCP存在的原因：由于IP层不可靠，不保证网络包的交付：既不保证网络包的按序交付，也不保证网络包中数据的完整性。而TCP是一个工作在运输层的可靠数据传输的服务，保证数据可以不重复、不丢弃和按序传输

头部格式：

• 源端口、目的端口：告诉TCP协议报文从哪个进程来，发送给哪个进程

• 序列号：在建立连接时由计算机生成的随机数作为初始值，通过SYN包传给接收端主机，每发送一次数据就累加一次该数据字计数的大小。用来解决网络包乱序问题。

• 确认应答号：指下一次期望收到的数据的序列号，发送端收到这个确认应答以后可以认为在这个序号以前的数据都已经被正常接收。用来解决丢包问题。

• 首部长度：因为TCP有可变长度的选项字段，需要记录首部开销

• 控制位：

  • ACK：该位为1时，确认应答号字段变为有效
  • RST：该位为1时，表示TCP连接中出现异常必须强制断开连接
  • SYN：该位为1时，表示希望建立连接，并在其序列号的字段进行序列号初始化
  • FIN：该位为1时，表示今后不会再有数据发送，希望断开连接。

• 窗口大小：

• 校验和：

• 紧急指针

• 选项：

3.2 什么是TCP连接？如何确定一个TCP连接

TCP连接是用于保证可靠性和流量控制维护的某些状态信息，这些信息的组合包括socket、序列号和窗口大小

• socket：由IP地址和端口号组成
• 序列号：用来解决乱序问题
• 窗口大小：用来做流量控制

TCP的四元组可以唯一的确定一个连接，四元组包包括源IP地址、源端口、目标IP地址、目标端口

3.3 UDP头部字段有哪些？TCP和UDP有哪些不同？

UDP头部只有8个字节

• 源端口和目标端口：告诉UDP将报文发送给哪个进程
• 包长度：保存了UDP首部分长度和数据长度之和
• 校验和：校验和是为了提供可靠的UDP首部和数据而设计的，防止收到在网络传输中受损的UDP包。

TCP和UDP区别：

1. 连接：

   • TCP是面向连接的传输层协议，传输数据前先要建立连接

   • UDP是不需要连接的即可传输

2. 服务对象：

   • TCP是一对一的两点服务，即一条连接只有两个端点

   • UDP支持一对一、一对多、多对多的交互通信

3. 可靠性：

   • TCP是可靠交付数据的，保证数据可以不重复、不丢弃和按序传输

   • UDP是尽最大努力交付，不保证可靠交付数据（UDP的可靠性是由应用层协议提供）

4. 拥塞控制、流量控制

   • TCP有拥塞控制和流量控制机制，保证数据传输的安全性

   • UDP则没有，即使网络非常拥堵了，也不会影响UDP的发送速率

5. 首部开销

   • TCP首部长度较长，会有一定的开销，首部在没有使用选项字段时是20个字节，如果使用了选项字段，首部字段更长

   • UDP首部只有8个字节且固定不变，开销较小

6. 应用场景

   • 由于TCP是面向连接的可靠性传输，常用于FTP文件传输、HTTP/HTTPS协议

   • 由于UDP是面向无连接的简单高效传输常用于

     • 包总量较少的通信，如DNS

     • 视频、音频等多媒体通信

     • 广播通信

3.4 TCP三次握手

3.4.1 TCP三次握手流程

1. 一开始，客户端和服务端都处于CLOSE状态，先是服务端主动监听某个端口处于listen状态。客户端会随机初始化序列号client_isn，同时把SYN设为1，表示SYN报文，接着就把第一个SYN报文发送给服务端，表示向服务端发起连接，该报文不包含应用层数据，之后客户端处于SYN_SENT状态。
2. 服务端收到客户端的SYN报文后，首先服务端也随机初始化自己的序列号server_isn，其次将client_isn+1填入确认应答号，把SYN和ACK设为1，随后把该报文发送给客户端，该报文也不包含应用层数据，之后服务端处于SYN_RCVD状态。
3. 客户端收到服务端报文后，还要向服务端回应最后一个应答报文，首先将ACK设为1，其次将server_isn+1填入确认应答号，最后把报文发送给服务端，这次报文可以携带应用层数据，之后客户端进入ESTABLISHED状态。（第三次握手是可以携带数据的，前两次握手是不可以携带数据的）
4. 服务端收到客户端的应答后，也进入ESTALISHED状态

3.4.2 为什么是三次握手而不是两次握手、四次握手？

三次握手能够防止历史连接的建立（重点），减少双方不必要的资源开销，帮助双方同步初始化序列号，保证数据包不重复、不丢弃和按序传输。

• 两次握手无法防止历史连接的建立，会造成双方资源的浪费，也无法可靠的同步双方序列号。

  • 历史连接的定义：客户端先发送了SYN报文，然后客户端宕机了，而且这个 SYN 报文还被网络阻塞了，服务端并没有收到，接着客户端重启后，又重新向服务端建立连接（注意不是重传SYN，重传SYN的序列号是一样的），此时原来的SYN报文是历史连接。
  • 如果是两次握手，服务端收到 SYN 报文后，就进入 ESTABLISHED状态，如果这次是历史连接，就会造成历史连接的建立，并且建立后服务器就可以发送数据了，浪费了服务器的资源。
  • 而如果是三次握手，服务端收到 SYN 报文后，先进入SYN_RCVD状态，此时并没有建立连接，如果这次是历史连接，客户端收到的确认应答号不是自己期望收到的确认应答号，则客户端会发送RST报文，进而终止历史连接的建立。

• 四次握手没必要因为三次握手就已经建立了可靠连接，所以不需要更多的通信次数。

3.4.3 为什么建立TCP连接时，初始化的序列号都要求不一样呢？初始化的序列号如何随机产生呢

1. 主要原因是为了防止历史报文被下一个相同四元组的连接接收，避免数据错乱。

2. ISN 随机生成算法：ISN = M + F(localhost, localport, remotehost, remoteport)。

   • M 是一个计时器，这个计时器每隔 4 微秒加 1。

   • F 是一个 Hash 算法，根据源 IP、目的 IP、源端口、目的端口生成一个随机数值。要保证 Hash 算法不能被外部轻易推算得出，用 MD5 算法是一个比较好的选择。

3.4.4 每次握手失效会出现什么结果

1. 第一次握手失效会发生什么？

• 客户端会触发超时重传机制，重传 SYN 报文，而且重传的 SYN 报文的序列号都是一样的，且有最大重传次数的限制（Linux默认5次）**。**重传时间也是写死在操作系统内核中，通常，第一次超时重传是在 1 秒后，第二次超时重传是在 2 秒，第三次超时重传是在 4 秒后，第四次超时重传是在 8 秒后，第五次是在超时重传 16 秒后。每次超时的时间是上一次的 2 倍。

2. 第二次握手失效会发生什么？

• 客户端和服务端都会重传：客户端会重传 SYN 报文，也就是第一次握手，服务端会重传 SYN-ACK 报文，也就是第二次握手。

3. 第三次握手失效会发生什么？

• 服务端触发超时重传机制，重传 SYN-ACK 报文，也就是第二次握手。注意ACK 报文是不会有重传的，当 ACK 丢失了，就由对方重传对应的报文。

3.5 既然IP会分片，为什么TCP还需要MSS呢？

• MTU：一个网络包的最大长度，以太网中一般为1500个字节
• MSS：除去IP和TCP头部后，一个网络包所能容纳的TCP数据的最大长度

如果IP层有一个超过MTU大小的数据要发送则IP进行分片再发送，目标主机IP层进行组装，再上交给TCP层。由于IP层没有超时重传，若一个IP分片丢失，整个IP报文所有的分片都得重传，因此效率非常低。

为了达到最佳的传输效率TCP协议在建立连接的时候要写商双方的MSS值，当TCP层发现数据超过MSS后会先进行切片，当然由他形成的IP包的长度自然不会大于MTU，也就不用IP分片了。若一个TCP丢失，进行重发时也是以MSS为单位，而不用重传所有的分片，效率大大增加。

3.6 TCP四次挥手

3.6.1 挥手过程

1. 客户端打算关闭连接，此时会发送一个FIN为1的报文，即FIN报文，之后客户端进入FIN_WAIT_1状态。
2. 服务端收到该报文后就向客户端发送ACK应答报文，接着服务器进入CLOSE_WAIT状态。
3. 客户端收到服务端的ACK应答报文后，之后进入FIN_WAIT2状态。
4. 等待服务端处理完数据后，也向客户端发送FIN报文，之后服务端进入LAST_ACK状态。
5. 客户端收到服务端的FIN报文后，回复一个ACK应答报文，之后进入TIME_WAIT状态。
6. 服务端收到了ACK应答后，就进入了CLOSE状态，至此服务器完成连接的关闭。
7. 客户端在经过2MSL时间后，自动进入CLOSE状态，至此客户端完成连接的关闭。

3.6.2 为什么挥手需要四次

• 关闭连接时，客户端向服务端发送 FIN 时，仅表示客户端不再发送数据了但是还能接收数据。
• 服务端收到客户端的 FIN 报文时，先回一个 ACK 应答报文，而服务端可能还有数据需要处理和发送，等服务端不再发送数据时，才发送 FIN 报文给客户端来表示同意现在关闭连接。

从上面过程可知，服务端通常需要等待完成数据的发送和处理，所以服务端的 ACK 和 FIN 一般都会分开发送，因此是需要四次挥手。

3.6.3 为什么 TIME_WAIT 等待的时间是 2MSL？为什么需要 TIME_WAIT 状态？

MSL是报文最大生存时间，它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。2MSL 的时间是从客户端接收到 FIN 后发送 ACK 开始计时的，如果在 TIME-WAIT 时间内，因为客户端的 ACK没有传输到服务端，客户端又接收到了服务端重发的 FIN 报文，那么 2MSL 时间将重新计时。

主动发起关闭连接的一方，才会有 TIME-WAIT 状态。需要 TIME-WAIT 状态，主要是两个原因：

1. 防止具有相同四元组的旧数据包被收到
2. 保证被动关闭连接的一方能被正确的关闭，即保证最后的 ACK 能让被动关闭方接收，从而帮助其正常关闭

3.7 TCP重传机制

1. 超时重传：设定一个定时器，当超过指定的时间后，没有收到对方的 ACK 确认应答报文，就会重发该数据。超时重传时间 RTO 的值应该略大于报文往返 RTT 的值。
2. 快速重传：它不以时间为驱动，而是以数据驱动重传。工作方式是当收到三个相同的 ACK 报文时，会在定时器过期之前，重传丢失的报文段。快速重传虽然解决了超时时间的问题，但存在重传的时候，是重传一个，还是重传所有的问题。
3. SACK 方法：在 TCP 头部选项字段里加一个 SACK ，它可以将已收到的数据的信息发送给发送方，这样发送方就可以知道哪些数据收到了，哪些数据没收到，知道了这些信息，就可以只重传丢失的数据。
4. D-SACK：使用了 SACK 来告诉发送方哪些数据被重复接收了，使用该算法的好处：
   1. 可以让发送方知道，是发出去的包丢了，还是接收方回应的 ACK 包丢了;
   2. 可以知道是不是发送方的数据包被网络延迟了;
   3. 可以知道网络中是不是把发送方的数据包给复制了;

3.8 TCP滑动窗口

TCP 头里有一个字段叫 Window，也就是窗口大小：这个字段是接收端告诉发送端自己还有多少缓冲区可以接收数据。于是发送端就可以根据这个接收端的处理能力来发送数据，而不会导致接收端处理不过来。

3.9 TCP拥塞阻塞

作用：拥塞控制通过拥塞窗口来防止过多的数据注入网络，使得网络中的路由器或者链路过载

拥塞控制算法主要有四种：慢启动，拥塞避免，快速重传，快速恢复。

1. 慢启动：在连接刚开始时，发送方会逐渐增加发送窗口大小，从而以指数增长的速度增加发送的数据量。

2. 拥塞避免：一旦慢启动阶段过去，发送方进入拥塞避免阶段。在这个阶段，发送方逐渐增加发送窗口的大小，但增加速率较慢，避免过快增加导致网络拥塞。

3. 超时重传：如果发送方在超时时间内未收到确认，它会认为数据包丢失，并重传这些数据包。这是拥塞控制的最后手段，用于检测和处理网络中的丢包或拥塞情况。当网络出现拥塞，也就是会发生数据包重传

4. 快速重传（Fast Retransmit）和快速恢复（Fast Recovery）：当发送方发送的数据包丢失或网络出现拥塞时，接收方会发送重复确认（duplicate ACK）通知发送方有数据包丢失。当发送方收到一定数量的重复确认时，它会立即重传丢失的数据包，而不是等待超时。这样可以减少网络的拥塞程度。

5. 拥塞窗口调整：发送方根据网络的拥塞程度动态调整发送窗口的大小，通过监测网络延迟和丢包情况来确定合适的发送速率，以避免网络拥塞。

3.10 TCP流量控制

如果发送者发送数据过快，接收者来不及接收，那么就会有分组丢失。为了避免分组丢失，控制发送者的发送速度，使得接收者来得及接收，这就是流量控制。流量控制根本目的是防止分组丢失。
理网络中的丢包或拥塞情况。当网络出现拥塞，也就是会发生数据包重传

快速重传（Fast Retransmit）和快速恢复（Fast Recovery）：当发送方发送的数据包丢失或网络出现拥塞时，接收方会发送重复确认（duplicate ACK）通知发送方有数据包丢失。当发送方收到一定数量的重复确认时，它会立即重传丢失的数据包，而不是等待超时。这样可以减少网络的拥塞程度。

拥塞窗口调整：发送方根据网络的拥塞程度动态调整发送窗口的大小，通过监测网络延迟和丢包情况来确定合适的发送速率，以避免网络拥塞。

3.10 TCP流量控制

如果发送者发送数据过快，接收者来不及接收，那么就会有分组丢失。为了避免分组丢失，控制发送者的发送速度，使得接收者来得及接收，这就是流量控制。流量控制根本目的是防止分组丢失。