【Java 面试 八股文】计算机网络篇

1. 什么是HTTP? HTTP 和 HTTPS 的区别?

HTTP（HyperText Transfer Protocol，超文本传输协议）是一种用于客户端（浏览器）和服务器之间通信的协议，主要用于传输网页数据，如HTML、CSS、JavaScript以及API请求等。它是无状态的，即每个请求都是独立的，服务器不会记录之前的请求信息。

HTTP 和 HTTPS 的区别：

1. 安全性：

• HTTP：数据是明文传输的，容易被中间人攻击、窃听和篡改。
• HTTPS：使用 SSL/TLS（安全套接层/传输层安全协议） 加密数据，提高数据的机密性和完整性，防止信息被窃取或篡改。

2. 端口号：

• HTTP 默认使用 80 端口。
• HTTPS 默认使用 443 端口。

3. 证书：

• HTTP 不需要任何证书。
• HTTPS 需要由 CA（证书颁发机构） 签发的 SSL/TLS 证书 进行身份认证，确保通信方的真实性。

4. 性能：

• 由于 HTTPS 需要进行加密和解密，理论上比 HTTP 稍慢，但现代硬件优化（如 TLS 1.3）使 HTTPS 的性能影响可以忽略不计。

总结：
HTTPS 相比 HTTP 更安全，能够有效防止数据泄露，尤其适用于涉及用户隐私和敏感信息的场景，如登录页面、支付页面等。因此，现在大部分网站都推荐使用 HTTPS。

---

2. 为什么说HTTPS比HTTP安全? HTTPS是如何保证安全的？

HTTPS 比 HTTP 更安全，主要是因为它在 HTTP 的基础上加入了 SSL/TLS（安全套接层/传输层安全协议），通过加密、身份验证和数据完整性保护来防止数据被窃取、篡改或伪造。

HTTPS 主要通过以下三方面来提升安全性：

1. 数据加密（防窃听）

• HTTPS 采用 对称加密 和 非对称加密 结合的方式，确保数据在传输过程中是加密的，即使黑客截获数据包，也无法解密。
• 非对称加密（RSA、ECDSA）：用于安全地交换对称密钥。
• 对称加密（AES、ChaCha20）：用于数据的高速加密传输。

2. 认证机制（防中间人攻击）

• HTTPS 采用 SSL/TLS 证书 来验证服务器的身份，防止用户访问伪造网站。
• CA（证书颁发机构） 颁发的 数字证书 可以保证网站的真实性，避免钓鱼攻击和中间人攻击。

3. 数据完整性（防篡改）

• HTTPS 使用 消息摘要算法（如 SHA-256） 计算数据的哈希值，并通过 HMAC（哈希消息认证码） 进行完整性校验，确保数据在传输过程中不会被篡改。
• 若数据被篡改，接收方计算出的哈希值与发送方的不匹配，通信将被中断。

总结
HTTPS 通过 加密 确保数据不被窃听，通过 身份认证 防止钓鱼网站，通过 完整性校验 防止数据被篡改，因此比 HTTP 更安全。现在，大部分网站、银行系统、电商平台等都采用 HTTPS 来保障数据安全。

---

3. 如何理解UDP 和 TCP? 区别? 应用场景?

3.1 TCP 和 UDP 的特点

UDP（User Datagram Protocol，用户数据报协议）和 TCP（Transmission Control Protocol，传输控制协议）是两种常见的 传输层协议，它们在数据传输方式、可靠性、连接管理等方面存在明显区别。

UDP（User Datagram Protocol），用户数据包协议，是一个简单的 面向数据报的通信协议，即对应用层交下来的报文，不合并，不拆分，只是在其上面加上首部后就交给了下面的网络层。

特点如下：

• UDP 不提供复杂的控制机制，利用 IP 提供面向无连接的通信服务
• 传输途中出现丢包，UDP 也不负责重发
• 当包的到达顺序出现乱序时，UDP没有纠正的功能。
• 并且它是将应用程序发来的数据在收到的那一刻，立即按照原样发送到网络上的一种机制。即使是出现网络拥堵的情况，UDP 也无法进行流量控制等避免网络拥塞行为

TCP（Transmission Control Protocol），传输控制协议，是一种可靠、面向字节流的通信协议，把上面应用层交下来的数据看成无结构的字节流来发送

特点如下：

• TCP充分地实现了数据传输时各种控制功能，可以进行丢包时的重发控制，还可以对次序乱掉的分包进行顺序控制。而这些在 UDP 中都没有。
• 此外，TCP 作为一种面向有连接的协议，只有在确认通信对端存在时才会发送数据，从而可以控制通信流量的浪费。
• 根据 TCP 的这些机制，在 IP 这种无连接的网络上也能够实现高可靠性的通信（ 主要通过检验和、序列号、确认应答、重发控制、连接管理以及窗口控制等机制实现）

特性	TCP（面向连接）	UDP（无连接）
连接方式	需要 三次握手 建立连接，通信前后需要维护连接	无需连接，直接发送数据
可靠性	可靠传输：有确认机制（ACK）、重传机制、流量控制和拥塞控制	不可靠传输：无确认机制，可能丢包
数据顺序	有序传输，接收方能按顺序组装数据	无序传输，可能乱序到达
传输效率	较低（因需保证可靠性）	较高（因无连接管理，减少开销）
数据单位	以 字节流 传输，无固定边界	以 数据报（Datagram） 传输，具有边界
应用场景	适用于数据可靠性高的场景，	如文件传输、Web请求 适用于实时性高、丢包可接受的场景，如视频通话、直播、DNS查询

3.2 适用场景

适用于 TCP 的场景（强调可靠性）

• HTTP/HTTPS（网页浏览）：网页加载需要完整的数据，不允许丢失
• FTP（文件传输）：传输文件时必须保证数据完整性
• SMTP/POP3/IMAP（电子邮件）：邮件内容不能丢失或错乱
• 数据库连接（MySQL、PostgreSQL）：数据交互需要高可靠性

适用于 UDP 的场景（强调实时性）

• 视频直播、在线会议（如 Zoom、直播推流）：即使丢失部分数据，也要保证流畅
• 在线游戏：丢包影响不大，低延迟比数据完整性更重要
• DNS（域名解析）：查询请求很短，丢失可重试，无需建立连接
• VoIP（网络语音通话）：轻微丢包不会影响通话体验，减少延迟更重要

---

4. 如何理解TCP/IP协议?

TCP/IP（Transmission Control Protocol/Internet Protocol）是一组用于 互联网通信 的协议，它定义了计算机如何通过网络进行数据传输。TCP/IP 是 分层协议，确保数据能够从一台计算机可靠地传输到另一台计算机。

TCP/IP 的分层模型

TCP/IP 层	对应 OSI 层	主要协议	作用
应用层	应用层、表示层、会话层	HTTP、HTTPS、FTP、SMTP、DNS	提供具体应用服务（如网页浏览、邮件等）
传输层	传输层	TCP、UDP	负责端到端通信，提供可靠或非可靠传输
网络层	网络层	IP、ICMP、ARP	负责寻址与路由，将数据包从源传输到目标
链路层	数据链路层、物理层	以太网、Wi-Fi、PPP	负责物理设备间的通信

TCP/IP 是互联网通信的核心协议，提供数据传输的基础。
TCP 负责可靠传输，IP 负责寻址和路由。
TCP 适用于可靠传输场景，UDP 适用于高实时性场景。

---

5. DNS协议 是什么？说说DNS 完整的查询过程?

5.1 什么是 DNS 协议？

DNS（Domain Name System，域名系统）是一种 将域名转换为 IP 地址 的协议。由于人们更容易记住 www.google.com 这样的域名，而计算机网络使用 IP 地址（如 142.250.190.14）来标识服务器，因此 DNS 充当了 域名解析服务，帮助用户找到目标服务器的 IP 地址。

DNS 是 应用层协议，通常使用 UDP 53 端口 进行查询，但某些情况下（如大数据包或安全需求）会使用 TCP 53 端口。

5.2 DNS 解析的完整查询过程

当用户在浏览器中输入 www.example.com 并回车后，DNS 解析过程如下：

📌 查询步骤：

1. 浏览器缓存（本地缓存）：

• 浏览器会先检查本地缓存（如之前访问过 www.example.com）。
• 如果有对应的 IP 地址，则直接使用，无需 DNS 查询。

2. 操作系统缓存（本机 DNS 缓存）：

• 如果浏览器没有找到，会向操作系统（ipconfig /displaydns）查询本机缓存。
• 如果缓存中有，则直接返回。

3. 本地 DNS 服务器（ISP 提供的解析服务器）

• 如果本机缓存中没有，操作系统会向 本地 DNS 服务器（通常由 ISP 提供，如电信、联通、移动）查询。
  本地 DNS 服务器如果有缓存，就直接返回 IP 地址（递归查询）。

4. 根 DNS 服务器（Root Servers）：

• 若本地 DNS 服务器没有缓存，它会向 根 DNS 服务器 发起请求（全球 13 个根服务器，如 .）。
• 根服务器不会直接返回 IP，而是告诉本地 DNS 去找 顶级域（TLD）DNS 服务器（如 .com）。

5. 顶级域（TLD）DNS 服务器（如 .com 服务器）：

• TLD 服务器负责管理 .com、.cn、.net 等顶级域。
• 它会告诉本地 DNS，去找 权威 DNS 服务器（如 example.com 的 DNS 服务器）。

6. 权威 DNS 服务器（Authoritative DNS）：

• 该服务器存储了 example.com 的真实 IP 地址，并返回给本地 DNS 服务器。

7. 本地 DNS 服务器缓存并返回：

• 本地 DNS 服务器缓存该结果，减少下次查询时间。
• 然后返回给客户端（用户设备）。

8.浏览器与服务器建立连接：

• 解析完 IP 地址后，浏览器使用 TCP/IP 与目标服务器建立 HTTP/HTTPS 连接。

5.3 DNS 查询的类型

• 递归查询（Recursive Query）：
  本地 DNS 服务器 负责查到底，直到找到 IP 地址（用户 → 本地 DNS → 找 IP）。
• 迭代查询（Iterative Query）：
  本地 DNS 服务器 逐步向上查询，直到找到 IP 地址（本地 DNS → 根 DNS → TLD DNS → 权威 DNS）。

5.4 DNS 解析优化

• 本地缓存（浏览器、系统、DNS 服务器缓存）加速解析。
• CDN（内容分发网络） 通过就近服务器提供解析，提高访问速度。
• 负载均衡 通过多个 IP 地址优化解析，减少服务器压力。

---

6. 说说 HTTP1.0/1.1/2.0 的区别?

HTTP（HyperText Transfer Protocol）是 超文本传输协议，主要用于 客户端（浏览器）和服务器之间的数据通信。随着 Web 需求的增长，HTTP 先后经历了 HTTP/1.0 → HTTP/1.1 → HTTP/2.0 的演进，提升了性能、并发能力和安全性。

6.1 HTTP 1.0

特点：

• 无连接（非持久连接）：每次请求都要建立 TCP 连接，完成后立刻关闭，导致 资源浪费。
• 串行请求：浏览器请求资源时，每个请求必须等上一个完成才能继续，低效。
• 无 Host 头：不支持虚拟主机，多个网站共用同一 IP 时，服务器无法识别请求属于哪个网站。
• 不支持压缩：数据传输量大，加载慢。

缺点：

• 每个请求都会创建新连接，增加服务器开销。
• 队头阻塞（Head-of-line Blocking）：必须等待前一个请求完成，才能发送下一个。

6.2 HTTP 1.1

相较 HTTP/1.0 的改进：

✅ 支持持久连接（Keep-Alive）：

• 默认 复用 TCP 连接，多个请求可复用一个 TCP 连接，减少 频繁建立/断开连接的开销。
• 通过 Connection: keep-alive 头部控制。

✅ 支持管道化（Pipelining）：

• 允许多个请求同时发送，不必等待前一个请求结束（但仍会受到队头阻塞影响）。

✅ 支持 Host 头：

• 允许在同一 IP 地址上托管多个网站（虚拟主机）。

✅ 支持分块传输（Chunked Transfer Encoding）：

• 服务器可以 逐块 发送数据，不必等全部内容生成后再返回，提升性能。

✅ 增加缓存控制（Cache-Control）：

• 增加 Cache-Control 头，支持 缓存管理，减少重复请求。

✅ 断点续传（Range 请求）：

• 允许客户端请求某个资源的一部分（如视频流），提升下载体验。

缺点：

• 仍然存在队头阻塞（HOL Blocking），同一 TCP 连接仍需等待上一个请求完成。
• 不支持多路复用，并发请求仍需多个 TCP 连接。

6.3 HTTP 2.0

HTTP/2 主要优化了性能，解决了 HTTP/1.1 并发低的问题。

✅ 二进制帧传输（Binary Framing）：

• HTTP/1.x 使用 纯文本，HTTP/2 使用 二进制（更高效）。
• 结构化数据传输，减少解析成本。

✅ 多路复用（Multiplexing）——最大改进点：

• 允许 多个请求同时在一个 TCP 连接上传输，而不会互相阻塞，消除队头阻塞。
• 之前 HTTP/1.1 一个 TCP 连接一次只能传输一个请求，HTTP/2 一个连接可并行处理多个请求。

✅ Header 压缩（HPACK）：

• HTTP/1.x 的请求头较大，每次请求都要携带，浪费带宽。
• HTTP/2 采用 HPACK 压缩算法，减少 重复头部，提升传输效率。

✅ 服务器推送（Server Push）：

• 服务器可主动推送资源（如 CSS、JS），减少客户端请求，提高加载速度。

缺点：

• 仍然基于 TCP，虽然解决了 HTTP/1.1 的队头阻塞问题，但 TCP 层仍可能有 队头阻塞。
• 服务器需额外支持 HTTP/2，如 Nginx 需开启 HTTP/2 配置。
• 浏览器和服务器都需支持 HTTP/2（现代浏览器基本支持）。

6.4 HTTP 3.0（基于 QUIC）

HTTP/2 仍然基于 TCP，而 TCP 本身有队头阻塞问题。HTTP/3 采用 QUIC（基于 UDP），解决了 TCP 的缺陷。

• 使用 QUIC 协议（基于 UDP），减少握手延迟
• 连接迁移能力更强（适用于移动网络）
• 完全消除 TCP 层队头阻塞
• 更安全（默认 TLS 1.3）

总结

版本对比总结

特性	HTTP/1.0	HTTP/1.1	HTTP/2.0	HTTP/3.0
连接复用	❌ 每次请求建立新 TCP 连接	✅ Keep-Alive	✅ 多路复用	✅ QUIC 连接复用
管道化	❌	✅ 支持	✅ 完全支持	✅
队头阻塞	✅ 串行请求	✅ 仍存在	❌ 解决（应用层）	❌（TCP 层也解决）
数据传输格式	文本	文本	二进制	二进制
Header 压缩	❌	❌	✅ HPACK	✅ QPACK
服务器推送	❌	❌	✅ 支持	✅
使用协议	TCP	TCP	TCP	QUIC（基于 UDP）

候选人回答：

HTTP1.0、HTTP1.1 和 HTTP2.0 主要在连接管理、并发性能和数据传输方式上有所不同。HTTP1.0 每次请求都要建立新的 TCP 连接，开销大，性能低下。HTTP1.1 通过 Keep-Alive 复用 TCP 连接，支持管道化请求，但仍然存在队头阻塞。HTTP2.0 采用二进制帧传输，并引入多路复用机制，使得多个请求可以共享同一个 TCP 连接并行传输，从而提高了并发能力。同时，HTTP2.0 还支持头部压缩（HPACK）和服务器推送，进一步减少了数据传输的冗余和延迟。总体来说，HTTP2.0 相较于 HTTP1.1 提升了网络效率，减少了延迟。

---

7. 说说HTTP 常见的状态码有哪些，适用场景？

HTTP 状态码用于表示服务器对客户端请求的响应情况，常见的状态码包括以下几类：

• 1xx（信息响应）：表示请求已接收，需进一步操作。
  • 100 Continue：表示服务器已接收到请求的部分数据，客户端可继续发送剩余部分。
• 2xx（成功响应）：表示请求成功。
  • 200 OK：请求成功，服务器返回正常数据（常见于 GET 请求）。
  • 201 Created：请求成功，并且资源已被创建（常见于 POST 请求）。
  • 204 No Content：请求成功，但无返回内容（常见于 DELETE 请求）。
• 3xx（重定向）：客户端需执行额外操作才能完成请求。
  • 301 Moved Permanently：资源已永久移动，客户端应使用新的 URL 访问。
  • 302 Found（临时重定向）：资源临时移动，客户端仍可使用原 URL。
  • 304 Not Modified：资源未修改，客户端可使用本地缓存版本。
• 4xx（客户端错误）：请求错误，需客户端修正。
  • 400 Bad Request：请求格式错误，服务器无法解析。
  • 401 Unauthorized：请求未认证，需提供身份凭证（如 JWT、OAuth）。
  • 403 Forbidden：服务器拒绝请求（权限不足）。
  • 404 Not Found：资源不存在（URL 错误或资源被删除）。
• 5xx（服务器错误）：服务器处理请求时发生错误。
  • 500 Internal Server Error：服务器内部错误，无法完成请求。
  • 502 Bad Gateway：服务器作为网关或代理，收到无效响应。
  • 503 Service Unavailable：服务器暂时无法处理请求（可能是过载或维护中）。

---

8. 说一下 GET 和 POST 的区别？

GET 和 POST，两者是 HTTP 协议中发送请求的方法。
GET 方法 从服务器获取指定的资源
POST 方法根据请求负荷（报文body）对指定的资源做出处理

主要区别：

1. 请求参数传递方式：

• GET：参数通过 URL 传递，拼接在 URL 后面，参数可见，格式为 ?key=value&key2=value2。
• POST：参数放在 请求体（body） 中，数据不可见，适合传输敏感信息或大数据量。

2. 安全性：

• GET：由于参数暴露在 URL 中，容易被篡改、缓存，不适合传输敏感数据（如密码）。
• POST：数据放在请求体中，相对安全，但仍需要 HTTPS 加密来增强安全性。

3. 请求长度限制：

• GET：由于 URL 长度限制（不同浏览器和服务器有所不同，一般为 2048 字符），不适合大数据提交。
• POST：理论上无大小限制（但服务器可以自行设定最大请求体大小）。

4. 幂等性：

• GET：幂等，即多次请求相同资源不会改变服务器状态，适用于查询操作。
• POST：非幂等，每次请求可能导致数据变化（如新增用户、提交订单）。

5. 浏览器缓存：

• GET：浏览器可缓存 GET 请求的结果，提高性能。
• POST：默认不会被缓存，需要手动设置。

总结来说，GET 适用于查询数据，速度快但不适合传输敏感信息或大数据，而 POST 适用于提交数据，安全性更高，适合修改服务器资源。

---

9. 说说 HTTP 常见的请求头有哪些? 作用？

HTTP 请求头（Headers）用于在客户端和服务器之间传递额外的信息，常见的请求头包括以下几类：

1. 通用请求头（General Headers）

• Host：指定服务器的域名和端口，如 Host: example.com:8080，用于虚拟主机识别。
• Connection：控制连接状态，如 Connection: keep-alive（保持连接）或 Connection: close（请求完成后关闭连接）。
• User-Agent：标识客户端信息，如浏览器或爬虫。
• Accept：客户端可接受的数据类型，如 Accept: text/html, application/json，用于服务器返回合适的内容。
• Accept-Encoding：指定支持的编码方式，如 gzip, deflate, br，服务器可返回压缩内容以减少流量。
• Accept-Language：指定客户端可接受的语言，如 Accept-Language: zh-CN, en-US。

2. 资源请求相关头

• Referer：表明请求的来源页面，如 Referer: https://example.com/page1，用于防止 CSRF 攻击。
• Origin：类似 Referer，但只包含协议和域名，如 Origin: https://example.com，用于 CORS 认证。

3. 认证与安全相关头

• Authorization：用于身份验证，如 Authorization: Bearer <token>（OAuth 令牌认证）。
• Cookie：用于在请求中携带会话信息，如 Cookie: sessionId=abc123，服务器可基于 Cookie 识别用户状态。

4. 内容传输相关头

• Content-Type：声明请求体的数据格式，如：
  • Content-Type: application/json（JSON 格式）
  • Content-Type: application/x-www-form-urlencoded（表单提交）
  • Content-Type: multipart/form-data（文件上传）
• Content-Length：表示请求体的字节大小，如 Content-Length: 348，用于服务器解析请求数据。

5. 缓存控制相关头

• Cache-Control：控制缓存策略，如：
  • Cache-Control: no-cache（不使用缓存）
  • Cache-Control: max-age=3600（缓存 1 小时）
• If-Modified-Since：携带资源的上次修改时间，配合 304 Not Modified，避免重复下载数据。
• If-None-Match：携带资源的 ETag（唯一标识符），服务器可比较是否更新，减少不必要的传输。

这些请求头在 HTTP 请求中起到了控制缓存、身份验证、数据格式等关键作用。例如，Authorization 头用于携带 JWT 令牌，Accept 头用于指定响应格式，而 Content-Type 头则决定了 POST 请求传输的数据格式。

---

10. 说说地址栏输入 URL 敲下回车后发生了什么?

当我们在浏览器地址栏输入 URL 并按下回车后，浏览器会经历一系列步骤来加载网页，主要过程如下：

1. URL 解析
浏览器首先解析用户输入的 URL，如果省略了 http:// 或 https://，会默认添加协议（通常是 HTTPS）。

2. DNS 解析（域名解析）
浏览器需要将域名（如 example.com）解析为 IP 地址，解析过程包括：

• 浏览器缓存（检查是否已解析过该域名）
• 本地 DNS 缓存（操作系统维护的解析记录）
• 本地 DNS 服务器（ISP 提供的解析服务器）
• 递归查询根 DNS 服务器 → 顶级域名（TLD）服务器 → 权威 DNS 服务器，获取最终 IP

3. 建立 TCP 连接
浏览器使用解析出的 IP 地址，与服务器建立 TCP 三次握手 连接（如果是 HTTPS，则额外进行 TLS/SSL 握手）。

• 第一次握手：客户端发送 SYN（请求建立连接）
• 第二次握手：服务器返回 SYN-ACK（同意建立连接）
• 第三次握手：客户端发送 ACK，连接建立

4. 发送 HTTP 请求
浏览器向服务器发送 HTTP 请求，常见内容包括：

• 请求方法（如 GET /index.html HTTP/1.1）
• 请求头（如 User-Agent、Accept、Cookie）
• 请求体（仅 POST/PUT 等请求携带数据）

5. 服务器处理请求
服务器收到请求后，处理请求并返回 HTTP 响应，流程包括：

• 检查路由（确定请求的资源，如静态文件或 API）
• 查询数据库（如果请求涉及动态数据）
• 执行业务逻辑
• 生成 HTML、JSON 等数据

6. 服务器返回 HTTP 响应
服务器返回 HTTP 响应，包括：

• 状态码（如 200 OK、404 Not Found）
• 响应头（如 Content-Type: text/html、Set-Cookie）
• 响应体（HTML 页面或 JSON 数据）

7. 浏览器解析与渲染页面

• 解析 HTML，构建 DOM 树
• 解析 CSS，构建 CSSOM 树
• 执行 JavaScript（如动态渲染、Ajax 请求）
• 合成渲染树并绘制页面

11. 说说TCP为什么需要三次握手和四次挥手？

三次握手（TCP 建立连接）

三次握手用于确保客户端和服务器之间的连接是可靠的，并且双方都准备好发送和接收数据。

1. 第一次握手（客户端 → 服务器）：

• 客户端向服务器发送 SYN（同步）标志位为 1 的数据包，表示请求建立连接。
• 这个数据包中还包含客户端的初始序列号（Sequence Number），用来同步数据流的编号。

2. 第二次握手（服务器 → 客户端）：

• 服务器接收到客户端的 SYN 包后，返回一个 SYN-ACK（同步-确认）包，表示同意建立连接并同步服务器的初始序列号。
• 该包中的确认号为客户端发送的序列号 + 1，表示已接收到客户端的请求。

3. 第三次握手（客户端 → 服务器）：

• 客户端收到服务器的 SYN-ACK 包后，发送一个 ACK（确认）包，表示连接建立完成，确认号为服务器的序列号 + 1。
• 一旦服务器收到该确认包，连接建立完成，数据传输可以开始。

为什么需要三次握手？

• 第一次握手：客户端发送网络包，服务端收到了 这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的
• 第二次握手：服务端发包，客户端收到了 这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常
• 第三次握手：客户端发包，服务端收到了。 这样服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常
• 通过三次握手，就能确定双方的接收和发送能力是正常的。

为什么不是两次握手?

• 如果是两次握手，发送端可以确定自己发送的信息能对方能收到，也能确定对方发的包自己能收到，但接收端只能确定对方发的包自己能收到 无法确定自己发的包对方能收到
• 并且两次握手的话, 客户端有可能因为网络阻塞等原因会发送多个请求报文，延时到达的请求又会与服务器建立连接，浪费掉许多服务器的资源

四次挥手（TCP 断开连接）

四次挥手用于可靠地断开连接，确保双方都完全关闭连接，防止数据丢失。

1. 第一次挥手（客户端 → 服务器）：

• 客户端发送 FIN（终止）包，表示客户端没有数据发送完毕，要求关闭连接。
• 这个包的序列号是客户端的最后一个数据包的序列号，客户端告知服务器它的数据已经发送完。

2. 第二次挥手（服务器 → 客户端）：

• 服务器收到 FIN 包后，返回 ACK 包，确认客户端的连接关闭请求。
• 服务器表示已经收到了客户端的关闭连接请求，但可能还有数据要发送，所以并不立即关闭连接。

3. 第三次挥手（服务器 → 客户端）：

• 服务器准备好关闭连接后，发送 FIN 包，表示服务器的数据也已发送完毕，要求关闭连接。

4. 第四次挥手（客户端 → 服务器）：

• 客户端收到服务器的 FIN 包后，发送 ACK 包确认，表示客户端也准备好关闭连接。
• 至此，连接双方都已关闭连接，TCP 连接完全断开。

四次挥手的原因

• 服务端在收到客户端断开连接 Fin 报文后，并不会立即关闭连接，而是先发送一个 ACK 包先告诉客户端收到关闭连接的请求，只有当服务器的所有报文发送完毕之后，才发送 FIN 报文断开连接，因此需要四次挥手。

---

12. 说说对WebSocket的理解？应用场景？

WebSocket 是一种用于在客户端和服务器之间建立 全双工通信 的协议。与传统的 HTTP 协议不同，WebSocket 允许客户端和服务器之间的 持续连接，可以在双方之间实时双向传输数据。

WebSocket 的特点：

• 全双工通信：WebSocket 在客户端和服务器之间建立了一个持久的连接，双方可以在同一连接上相互发送数据，而不需要每次都建立新的连接。
• 实时性：一旦建立连接，服务器可以随时向客户端推送数据，客户端也可以随时向服务器发送数据，避免了传统 HTTP 请求-响应模式的延迟。
• 较低的开销：由于 WebSocket 使用的是单一的连接，避免了 HTTP 每次请求都需要建立连接的高开销。协议的握手阶段仅发生一次，数据传输更高效。
• 支持二进制数据：WebSocket 不仅支持文本数据的传输，还支持二进制数据（如图片、音频等）的传输，这使得它能够应用于更多的场景。

WebSocket 与 HTTP 的区别：

• HTTP 是无状态的，每次请求都需要建立新的连接，而 WebSocket 通过一次握手建立连接后，保持长时间连接，可以多次交换数据。
• HTTP 是请求-响应模型，每次客户端发起请求，服务器返回响应，而 WebSocket 是双向的，客户端和服务器可以随时互相发送消息。
• HTTP 不支持实时通信，而 WebSocket 支持实时双向通信，适合需要低延迟和实时更新的应用。

WebSocket 的应用场景：

• 弹幕
• 媒体聊天
• 协同编辑
• 基于位置的应用
• 体育实况更新
• 股票基金报价实时更新