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

操作系统篇

- 1. 什么是HTTP? HTTP 和 HTTPS 的区别?
- 2. 为什么说HTTPS比HTTP安全? HTTPS是如何保证安全的？
- 3. 如何理解UDP 和 TCP? 区别? 应用场景?
- - 3.1 TCP 和 UDP 的特点
  - 3.2 适用场景
- 4. 如何理解TCP/IP协议?
- 5. DNS协议是什么？说说DNS 完整的查询过程?
- - 5.1 什么是 DNS 协议？
  - 5.2 DNS 解析的完整查询过程
  - 5.3 DNS 查询的类型
  - 5.4 DNS 解析优化
- 6. 说说 HTTP1.0/1.1/2.0 的区别?
- - 6.1 HTTP 1.0
  - 6.2 HTTP 1.1
  - 6.3 HTTP 2.0
  - 6.4 HTTP 3.0（基于 QUIC）
  - 总结
- 7. 说说HTTP 常见的状态码有哪些，适用场景？
- 8. 说一下 GET 和 POST 的区别？
- 9. 说说 HTTP 常见的请求头有哪些? 作用？
- 10. 说说地址栏输入 URL 敲下回车后发生了什么?
- 11. 说说TCP为什么需要三次握手和四次挥手？
- - 三次握手（TCP 建立连接）
  - 四次挥手（TCP 断开连接）
- 12. 说说对WebSocket的理解？应用场景？

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。
一旦服务器收到该确认包，连接建立完成，数据传输可以开始。

为什么需要三次握手？

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

为什么不是两次握手?