计网相关面试题

写在前面

🔥我把后端Java面试题做了一个汇总，有兴趣大家可以看看！这里👉

⭐️在反复复习面试题时，我发现不同资料的解释五花八门，容易造成概念混淆。尤其是很多总结性的文章和视频，要么冗长难记，要么过于简略，导致关键知识点含糊不清。

⭐️为了系统梳理知识，我决定撰写一份面试指南，不只是简单汇总，而是融入个人理解，层层拆解复杂概念，构建完整的知识体系。我希望它不仅帮助自己更自信地应对面试，也能为同行提供清晰、实用的参考。

---

计网相关面试题

⾯试官： 从输入URL到页面展示到底发生了什么？（高频）

候选人：

1. 浏览器接收到用户请求，先检查浏览器缓存里是否有缓存该资源，如果有直接返回;如果没有进入下一步网络请求。
2. 网络请求前，进行 DNS解析 ，以获取请求域名的IP地址 。如果请求协议是 HTTPS ，那么还需要建立TLS/SSL 连接 。DNS查找过程：浏览器缓存、路由器缓存、DNS缓存。
3. 浏览器与服务器IP建立TCP连接。连接建立后，浏览器端会构建请求行、请求头等信息，并把和该域名相关的 Cookie 等数据附加到请求头中，向服务器构建请求信息。
4. 服务器接收到请求信息，根据请求生成响应数据。
5. 浏览器解析响应头。若响应头状态码为 301、302 ，会重定向到新地址；若响应数据类型是字节流类型，一般会将请求提交给下载管理器；若是HTML类型，会进入下一部渲染流程
6. 浏览器解析 HTML 文件，创建 DOM 树、解析 CSS 进行样式计算，然后将CSS和DOM合并，构建渲染树；最后布局和绘制渲染树，完成页面展示。

---

面试官： DNS域名解析的工作流程（超高频）

候选人： DNS(Domain Name System)域名管理系统，是当用户使用浏览器访问网址之后，使用的第一个重要协议。DNS 要解决的是域名和IP 地址的映射问题。

域名的层级关系

DNS 中的域名都是用句点 来分隔的，比如 www.server.com，这里的句点代表了不同层次之间的界限。

在域名中，越靠右 的位置表示其层级越高

根域是在最顶层，它的下一层就是 com 顶级域，再下面是 server.com。所以域名的层级关系类似一个树状结构:

• 根 DNS 服务器

• 顶级域 DNS 服务器(com)

• 权威 DNS 服务器(server.com)

1. 首先用户在浏览器输入URL地址后，会先查询浏览器缓存是否有该域名对应的IP地址。
2. 如果浏览器缓存中没有，会去计算机本地的Host文件中查询是否有对应的缓存。
3. 如果Host文件中也没有则会向本地的DNS解析器 (通常由你的互联网服务提供商(ISP)提供)发送一个DNS查询请求。
4. 如果本地DNS解析器没有缓存该域名的解析记录 ，它会向根DNS服务器发出查询请求。根DNS服务器并不负责解析域名，但它能告诉本地DNS解析器应该向哪个顶级域(.com/.net/.org)的DNS服务器继续查询。
5. 本地DNS解析器接着向指定的顶级域DNS服务器发出查询请求。顶级域DNS服务器也不负责具体的域名解析，但它能告诉本地DNS解析器应该前往哪个权威DNS服务器查询下一步的信息。
6. 本地DNS解析器最后向权威DNS服务器发送查询请求。当权威DNS服务器收到查询请求时，它会查找域名对应的IP地址，并将结果返回给本地DNS解析器。
7. 本地DNS解析器将收到的IP地址返回给浏览器，并且还会将域名解析结果缓存在本地，以便下次访问时更快地响应。

DNS 域名解析的过程蛮有意思的，整个过程就和我们日常生活中找人问路的过程类似，只指路不带路

---

⾯试官： 三次握手的过程，以及为什么是三次，不是四次、两次？（超高频）

候选人： 三次握手的过程如下:

1. 客户端向服务器发送 SYN 报文，然后客户端进入 同步发送 状态，等待服务器确认。
2. 服务端发送 ACK 确认服务端的 SYN 报文，同时发出一个 SYN 报文，然后服务端进入 同步接收 状态。
3. 客户端接收到服务端的 SYN、ACK 报文，发送 ACK报文 确认服务端的 SYN 报文，然后客户端和服务器端都进入 ESTABLISHED（连接已建立） 状态，完成 TCP 三次握手。

为什么不是四次握手? 为什么不能两次握手?

因为三次握手才能保证双方具有接收和发送的能力。

• 两次握手可能导致资源的浪费，由于没有第三次握手，服务端就无法确认客户端是否收到了自己的回复。
• 而四次握手可以优化为三次。
  为什么要传回 SYN ?

接收端传回发送端所发送的 SYN 是为了告诉发送端，我接收到的信息确实就是你所发送的信号。前后SYN报文的值是一样的。
传了 SYN,为啥还要传 ACK ?

双⽅通信⽆误必须是两者互相发送信息都⽆误。传了 SYN，证明发送⽅到接收⽅的通道没有问题，但是接收⽅到发送⽅的通道还需要 ACK 信号来进⾏验证。

第一次握手丢失了，会发生什么？

当客户端想和服务端建立 TCP 连接的时候，首先第一个发的就是 SYN 报文，然后进入到 SYN_SENT 状态。在这之后，如果客户端迟迟收不到服务端的 SYN-ACK 报文（第二次握手），就会触发「超时重传」机制，重传 SYN 报文。重传一定次数后，如果服务端仍然没有回应 ACK，客户端就不再发送 SYN 包，然后断开 TCP 连接。

第二次握手丢失了，会发生什么？

当第二次握手丢失了，客户端和服务端都会重传：

• 客户端会重传 SYN 报文，也就是第一次握手，最大重传次数由 tcp_syn_retries 内核参数决定(如果客户端迟迟没有收到第二次握手，那么客户端就觉得可能自己的 SYN 报文（第一次握手）丢失了)。

• 服务端会重传 SYN-ACK 报文，也就是第二次握手，最大重传次数由 tcp_synack_retries 内核参数决定（如果第二次握手丢失了，服务端就收不到第三次握手，于是服务端这边会触发超时重传机制，重传 SYN-ACK 报文）。

第三次握手丢失了，会发生什么？

因为这个第三次握手的 ACK 是对第二次握手的 SYN 的确认报文，所以当第三次握手丢失了，如果服务端那一方迟迟收不到这个确认报文，就会触发超时重传机制，重传 SYN-ACK 报文，直到收到第三次握手，或者达到最大重传次数。

---

⾯试官： 四次挥手的过程，以及为什么是四次？（超高频）

候选人： 断开⼀个 TCP 连接则需要"四次挥⼿"：

1. 客户端发送⼀个 FIN，⽤来关闭客户端到服务器的数据传送

2. 服务器收到这个 FIN，它发回⼀个 ACK，确认序号为收到的序号加 1

3. 服务器关闭与客户端的连接，发送⼀个FIN给客户端

4. 客户端发回 ACK 报⽂确认，并将确认序号设置为收到序号加 1

为什么要四次挥⼿ ？

任何⼀⽅都可以在数据传送结束后发出连接释放的通知，待对⽅确认后进⼊半关闭状态。当另⼀⽅也没有数据再发送的时候，则发出连接释放通知，对⽅确认后就完全关闭了TCP连接。

举个例⼦：A 和 B 打电话，通话即将结束后，A 说"我没啥要说的了"，B回答"我知道了"，但是 B可能还会有要说的话，A 不能要求 B 跟着⾃⼰的节奏结束通话，于是 B 可能⼜巴拉巴拉说了⼀通，最后 B 说"我说完了"，A 回答"知道了"，这样通话才算结束。

为什么 TIME_WAIT 等待的时间是 2MSL？

• 如果第四次挥手的 ACK 报文丢失，服务端会重发 FIN 报文。客户端在 TIME_WAIT 状态期间仍然可以接收并响应这些重发的 FIN 报文。
• 2MSL 的时间足够长，可以确保客户端有足够的时间处理这些重传的 FIN 报文，并最终确认连接的关闭。
• 可以看到 2MSL时长 ，这其实是相当于至少允许报文丢失一次。比如，若 ACK 在一个 MSL 内丢失，这样被动方重发的 FIN 会在第 2 个 MSL 内到达，一来一去正好 2 个 MSL，TIME_WAIT 状态的连接可以应对。

TIME_WAIT 状态的连接过多怎么处理？高频

TIME_WAIT 状态多主要是由于大量短连接频繁创建关闭导致。系统中存在大量 TIME_WAIT 状态的连接，可能会耗尽端口资源，影响新连接的建立。最常见的解决方案就是改短连接为长连接 （HTTP Keep-Alive 或 Netty连接池），减少频繁的连接创建与关闭，降低 TIME_WAIT 数量。

第一次挥手丢失了，会发生什么？

客户端重传 FIN 报文。达到最大重传次数后，客户端等待一段时间（上次超时时间的 2 倍），如果仍收不到 ACK，直接进入 CLOSE 状态。

第二次挥手丢失了，会发生什么？

客户端重传 FIN 报文，直到收到服务端的 ACK 或达到最大重传次数。

第三次挥手丢失了，会发生什么？

如果服务端迟迟收不到客户端的 ACK报文 ，服务端重发 FIN 报文。达到最大重传次数后，服务端等待一段时间（上次超时时间的 2 倍），如果仍收不到 ACK，断开连接。

第四次挥手丢失了，会发生什么？

如果第四次挥手的 ACK 报文没有到达服务端，服务端就会重发 FIN 报文,达到了最大重传次数，于是再等待一段时间（时间为上一次超时时间的 2 倍），如果还是没能收到客户端的第四次挥手（ACK 报文），那么服务端就会断开连接。

---

⾯试官： OSI与TCP/IP各层的结构与功能,都有哪些协议?

候选人：

物理层："透明"传输比特流，尽可能地屏蔽不同传输媒体和通信手段的差异。解决使用何种信号来传输比特流的问题。

数据链路层： 通常简称为链路层。两台主机之间的数据传输，总是在⼀段⼀段的链路上传送的 ，这就需要使⽤专⻔的链路层的协议。 在两个相邻节点之间传送数据时，数据链路层将⽹络层交下来的 IP 数据报封装成帧，在两个相邻节点间的链路上传送帧。解决分组在一个网络（或一段链路）上传输的问题。

网络层： 在计算机⽹络中进⾏通信的两个计算机之间可能会经过很多个数据链路 ，也可能还要经过很多通信⼦⽹。⽹络层的任务就是选择合适的⽹间路由和交换结点， 确保数据及时传送。解决分组在多个网络上传输的问题。

运输层： 主要解决进程间基于网络的通信问题。运输层主要使⽤两种协议：TCP和UDP

应用层： 通过应⽤进程间的交互来完成特定⽹络应⽤。

---

面试官： TCP粘包和拆包是什么？解决方案？(高频)

候选人： TCP 是面向字节流的协议 ，没有消息边界，所以在一次 recv() 时可能接收到：

• 多个消息合并的粘包：多个小包被合并成一个大包传输。
• 一个消息被拆成多个小包：一次接收不到完整的消息，称为拆包。

常见触发条件：

• 应用层发送过快（发送多条消息），网络层合并；
• 消息过大或 MTU 限制导致拆包；
• TCP 本身的流式传输特性。

我了解到的有两种解决方案：

✅ 方式一：固定消息长度

• 每条消息长度固定，如每次都是 128 字节，不足补齐。
• 缺点：不灵活，浪费空间。

✅ 方式二：消息头+消息体

• 结构如下：

| 4字节长度 | 数据内容（length字节） |

服务端先读前 4 字节得到长度，再读取该长度的数据。

---

⾯试官： TCP和UDP的区别以及对应的使用场景？（高频）

候选人：

1）概念：

• TCP(传输控制协议) 是一种面向连接的、可靠的、基于字节流的传输层通信协议。
• UDP(用户数据报协议) 为应用程序提供了一种无需建立连接就可以发送封装的IP数据包的方法。

2）区别

• 是否面向连接: TCP 是面向连接的传输，UDP 是无连接的传输。
• 是否是可靠传输: TCP是可靠的传输服务，在传递数据之前，会有三次握手来建立连接；在数据传递时，有确认、窗口、重传、拥塞控制机制。 UDP是不可靠传输，数据传递不需要给出任何确认，且不保证数据不丢失及到达顺序。
• 是否有状态：TCP 传输是有状态的，它会去记录自己发送消息的状态比如消息是否发送了、是否被接收了等等，而 UDP 是无状态的。
• 传输形式:TCP 是面向字节流的，UDP 是面向数据报文的。
• 传输效率:由于TCP 传输的时候多了连接、确认重传等机制，所以TCP 的传输效率要比UDP 低。
• 首部开销 :TCP 首部开销(20~60字节)比UDP 首部开销 (8字节)要大。
• 是否提供广播或多播服务: TCP 只支持点对点通信；UDP 支持一对一、一对多、多对一、多对多。

3）应用场景

• TCP常用于要求通信数据可靠场景(如网页浏览、文件传输、邮件传输、远程登录、数据库操作等)
• UDP常用于要求通信速度快场景(如域名转换、视频直播、实时游戏等)

---

⾯试官： TCP协议如何保证可靠传输？（高频）

候选人： TCP连接确保可靠性方法如下：

1. TCP的序列号可以避免乱序的问题，保证收到的TCP报文都是有序的。
2. 在 TCP 中，当发送端的数据到达接收主机时，接收端主机会返回一个确认应答消息，表示已收到消息。
3. TCP 针对数据包丢失的情况，会用重传机制解决。
4. 使用滑动窗口实现流量控制。使用接收方确认报文中的窗口字段来控制发送方发送窗口大小，进而控制发送方的发送速率，使得接收方来得及接收。
5. 使用基于窗口的拥塞控制，来尽量避免避免网络拥塞。

相关阅读：破解网络奥秘：一图胜千言，TCP重传、滑动窗口、流量与拥塞控制全解析

---

⾯试官： 流量控制是使用什么数据结构来实现的？

候选人：

TCP传输协议中，流量控制是使用滑动窗口（Sliding Window）来实现的。滑动窗口是一种基于数据流的、动态调整的、可变大小的窗口，它通过协商双方的接收窗口和发送窗口大小，控制数据的传输速率。

滑动窗口的大小是可以动态调整的，它可以根据网络状况和双方的能力来自适应地调整，从而实现流量控制的功能。如果接收方的接收窗口变小，发送方会相应地减小自己的发送窗口，以避免过多的数据堆积在网络中导致拥塞。如果接收方的接收窗口变大，发送方会相应地增加自己的发送窗口，以提高数据传输速率。

---

⾯试官： 拥塞控制是怎么实现的？

候选人： 拥塞控制主要是四个算法：

1. 慢启动（Slow Start） ：
   目的： 快速找出网络的最大容量。
   方法： 开始时用很小的数据量发送，接收到确认后，发送量快速增加。就像在探测水深时，从小处开始，然后快速加深。
2. 拥塞避免（Congestion Avoidance） ：
   目的： 平稳增加发送数据量，避免网络拥堵。
   方法： 当网络负担较重时，发送数据量的增加变得比较慢。就像在汽车进入拥堵区时，从加速驾驶改为平稳驾驶。
3. 快重传（Fast Retransmit） ：
   目的： 迅速重传丢失的数据包。
   方法： 如果发现某个数据包的确认收不到，发送方会快速重传这个数据包，而不是等到超时。就像收到一个丢失的邮件后，立刻重新发送。
4. 快恢复（Fast Recovery） ：
   目的： 在发现丢包后快速恢复数据传输。
   方法： 快重传后，拥塞窗口会减少到一半，然后逐渐恢复到正常速度。就像在堵车后，车速会先减慢，再慢慢恢复正常行驶。

---

面试官： TCP Keepalive 和 HTTP Keep-Alive是一个东西吗？

候选人：

• HTTP 的 Keep-Alive，是由应用层（用户态） 实现的，称为 HTTP 长连接。可以使得用同一个 TCP 连接来发送和接收多个 HTTP 请求/应答，减少了 HTTP 短连接带来的多次 TCP 连接建立和释放的开销。

• TCP 的 Keepalive，是由 TCP 层（内核态） 实现的，称为 TCP 保活机制。当客户端和服务端长达一定时间没有进行数据交互时，内核为了确保该连接是否还有效，就会发送探测报文，来检测对方是否还在线，然后来决定是否要关闭该连接。

---

⾯试官： HTTP请求常见的状态码和字段（高频，特别注意：面试中为抽查）

候选人：

状态码

1xx 状态码表示请求已被接收，客户端可以继续请求。比如：

• 100 Continue，代表服务器已收到请求的初始部分，客户端应继续发送剩余请求。

• 101 Switching Protocols，代表服务器同意切换协议（如从 HTTP 切换到 WebSocket）。

2xx 状态码表示请求已被成功处理。比如：

• 200 OK，代表请求成功，服务器返回了预期的响应数据。

• 201 Created，代表请求成功，服务器已创建新资源（如 POST 请求创建用户）。

• 204 No Content，代表请求成功，但服务器不返回任何内容（常见于 DELETE 请求）。

3xx 状态码表示客户端需要采取额外操作以完成请求，通常是跳转到新地址。比如：

• 301 Moved Permanently，代表请求的资源已被永久移动，浏览器会自动跳转到新 URL。

• 302 Found，代表资源暂时移动，通常用于临时重定向。

• 304 Not Modified，代表资源未修改，客户端可以使用缓存的版本，减少带宽消耗。

4xx 状态码表示客户端请求有错误，需要修正后重新发送。比如：

• 400 Bad Request，代表请求格式错误或参数不正确，服务器无法理解请求。

• 401 Unauthorized，代表请求需要身份验证，通常用于 API 认证失败的情况。

• 403 Forbidden，代表服务器拒绝请求，即使身份验证成功也无权访问该资源。

• 404 Not Found，代表请求的资源不存在或 URL 书写错误。

• 405 Method Not Allowed，代表请求的方法（如 POST、PUT）不被该资源允许。

5xx 状态码表示服务器端处理请求时发生错误。比如：

• 500 Internal Server Error，代表服务器内部错误，可能是代码异常或配置错误。

• 502 Bad Gateway，代表服务器作为网关或代理时，接收到无效响应。

• 503 Service Unavailable，代表服务器暂时不可用，通常是维护或过载导致的。

• 504 Gateway Timeout，代表服务器作为网关时，未能及时收到上游服务器的响应。

常见字段

---

⾯试官： 常见的请求方式？GET和POST请求的区别？（超高频）

候选人：

1）作用不同

• GET用于从服务端获取资源
• POST一般用来向服务器端提交数据

2）参数传递方式不同

• GET请求的参数一般写在URL中，且只接受ASCII字符
• POST请求参数一般放在请求体中，对于数据类型也没有限制

3）安全性不同

因为参数传递方式的不同，所以两者安全性不同，GET请求的参数直接暴露在URL中，所以更不安全，不能用来传递敏感信息。

4）参数长度限制不同

• GET传送的数据量较小，不能大于2KB。
• POST传送的数据量较大，一般被默认为不受限制。

5）编码方式不同

• GET 请求只能进行 URL 编码
• POST 支持多种编码方式

6）时间消耗不同

• GET 产生一个 TCP 数据包
• POST 产生两个 TCP 数据包

7）幂等

所谓的「幂等」，意思是多次执行相同的操作，结果都是「相同」的。

• GET 方法就是安全且幂等的，因为它是「只读」操作，无论操作多少次，服务器上的数据都是安全的，且每次的结果都是相同的。
• POST 因为是「新增或提交数据」的操作，会修改服务器上的资源，所以是不安全的，且多次提交数据就会创建多个资源，所以所以不是幂等的。

---

⾯试官： HTTP 1.0和HTTP 1.1的主要区别是什么?

候选人： HTTP1.0最早在⽹⻚中使⽤是在1996年，那个时候只是使⽤⼀些为简单的⽹⻚上和⽹络请求上，⽽HTTP1.1则在1999年才开始⼴泛应⽤于现在的各⼤浏览器⽹络请求中，同时HTTP1.1也是当前使⽤最为⼴泛的HTTP协议。 主要区别主要体现在：

1. 长连接

   HTTP1.1 支持长连接，每一个TCP连接上可以传送多个HTTP请求和响应，默认开启 Connection:Keep-Alive

   HTTP1.0 默认为短连接，每次请求都需要建立一个TCP连接。

2. 缓存

   HTTP1.0主要使用 If-Modified-Since/Expires 来做为缓存判断的标准

   HTTP1.1则引入了更多的缓存控制策略例如 Entity tag / If-None-Match 等更多可供选择的缓存头来控制缓存策略

3. 管道化

   支持管道（pipeline）网络传输，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。

4. 状态码

   HTTP1.1新增了24个错误状态响应码

5. 带宽优化

   HTTP1.0 中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能

   HTTP1.1 则在请求头引入了 range 头域，它允许只请求资源的某个部分，即返回码是 206(Partial Content)

---

⾯试官： HTTP 2.0和HTTP 1.1 的区别是什么?

候选人：

1. 二进制分帧

   在应用层(HTTP/2.0)和传输层(TCP or UDP)之间增加一个二进制分帧层，从而突破 HTTP1.1 的性能限制，改进传输性能，实现低延迟和高吞吐量。

2. 多路复用(MultiPlexing)

   HTTP/1.1 的实现是基于请求-响应模型 的。同一个连接中，HTTP 完成一个事务（请求与响应），才能处理下一个事务，也就是说在发出请求等待响应的过程中，是没办法做其他事情的，如果响应迟迟不来，那么后续的请求是无法发送的。而 HTTP/2.0 允许同时通过单一的连接发起多重的请求--响应消息。

3. 首部压缩

   HTTP1.1 不支持 header数据的压缩，HTTP/2.0 使用 HPACK 算法对 header的数据进行压缩，这样数据体积小了，在网络上传输就会更快。高效的压缩算法可以很大的压缩 header ，减少发送包的数量从而降低延迟。

4. 服务端推送 (server push)

   HTTP/2 还在一定程度上改善了传统的「请求 - 应答」工作模式，服务端不再是被动地响应，可以主动向客户端发送消息。

---

面试官： Quic 协议了解过吗？

候选人： 是的，我了解过 QUIC 协议。它是 Google 提出的一个基于 UDP 的传输协议，主要目标是解决 TCP 在现代互联网应用中的一些痛点，比如多路复用时的队头阻塞问题、连接建立慢等。目前 HTTP/3 就是基于 QUIC 实现的，它已经被主流浏览器和服务广泛支持。

UDP 是一个无连接、不可靠的传输协议，它本身不保证消息的有序性和可靠性 ，但是我们通过 QUIC、KCP 就可实现UDP的可靠传输。相比 TCP，它们在高性能、低延迟的场景下具有更强的灵活性和可控性。

---

⾯试官： HTTP 和 HTTPS 的区别？（超高频）

候选人：

• HTTP 是超文本传输协议，信息是明文传输 ，存在安全风险的问题。HTTPS 则解决 HTTP 不安全的缺陷，在 TCP 和 HTTP 网络层之间加入了 SSL/TLS 安全协议，使得报文能够加密传输。

• 两者的默认端口不一样，HTTP 默认端口号是 80，HTTPS 默认端口号是 443。

• HTTPS 协议需要需要 SSL/TLS 证书，由受信任的证书颁发机构**（CA）**签发；而 HTTP 不需要任何证书。

• 搜索引擎通常偏好使用 HTTPS 协议的网站，因为 HTTPS 提供更高的安全性和用户隐私保护。

---

⾯试官： HTTPS的工作原理？（https是怎么建立连接的？）

候选人：

1. 客户端发起HTTPS请求 ：第一次握手，客户端告诉服务端，它支持什么样的加密协议版本(TLS1.2)，使用什么样的加密套件（RSA），并且给出一个客户端随机数（明文）。
2. 服务器返回证书 ：第二次握手，服务端收到请求后，告诉客户端确定的加密方式等信息，服务器证书和服务器随机数（明文）。这个证书由受信任的证书颁发机构（CA）签署，确保其真实性。
3. 客户端验证证书 ：第三次握手，客户端收到服务端发送的数字证书后，会验证其合法性，包括证书的颁发机构、有效期等。如果证书可信，客户端会从证书里取出服务器公钥，同时再生成第三个随机数pre_master_key（服务器公钥加密）。客户端通过三个随机数用算法生成一个会话密钥。同时把迄今为止的通信数据内容生成一个摘要，也叫finished报文，用会话秘钥加密一下发给服务端做校验。
4. 客户端加密随机数：客户端使用服务端的公钥（也就是从CA取出的公钥解密CA证书得到）加密第三个随机数，并将加密后的第三个随机数发送给服务端。
5. 服务器解密会话密钥：第四次握手，服务端使用自己的服务器私钥解密得到第三个随机数。结合三个随机数，跟客户端一样通过同样的算法获得一个会话密钥。此时，客户端和服务端都拥有了相同的会话密钥。
6. 使用对称密钥进行加密通信：四次握手之后，客户端和服务器使用这个会话密钥（对称加密）进行后续的加密通信，确保数据传输的安全性。

为什么公钥加密的数据不能用公钥解密？

公钥加密和私钥解密是一对数学函数，它们是单向的。这意味着公钥只能用来加密数据，不能用来解密数据，只有私钥可以解密由公钥加密的数据。这种设计的目的是为了确保即使公钥是公开的，数据的解密只能由私钥持有者完成，从而保证数据的安全性。

为什么不能直接传服务器公钥？

直接传输公钥时，接收方无法确定这个公钥是否真的属于声称的身份。一个恶意的第三方可以在传输过程中替换掉真实的公钥，插入自己的公钥，这样所有发往目标服务器的数据都会被这个第三方截获和解密，这就是中间人攻击。

https用了什么保证加密？

HTTPS通过SSL/TLS协议保证数据加密。它采用对称加密 进行数据传输，加密速度快，同时使用非对称加密在握手阶段进行密钥交换，确保密钥安全。此外，还通过数字证书验证服务器身份，防止中间人攻击。

---

⾯试官： Cookie和Session是什么？有什么区别？

候选人： Cookie 和 Session 都用于管理用户的状态和身份，Cookie 通过在客户端记录信息确定用户身份， Session 通过在服务器端记录信息确定用户身份。

1. Cookie ⼀般⽤来保存⽤户信息。

   ⽐如①我们在 Cookie 中保存已经登录过得⽤户信息，下次访问⽹站的时候⻚⾯可以⾃动帮你登录的⼀些基本信息给填了；②⼀般的⽹站都会有保持登录也就是说下次你再访问⽹站的时候就不需要重新登录了，这是因为⽤户登录的时候我们可以存放了⼀个Token 在 Cookie 中，下次登录的时候只需要根据 Token 值来查找⽤户即可(为了安全考虑，重新登录⼀般要将 Token 重写)；③登录⼀次⽹站后访问⽹站其他⻚⾯不需要重新登录。

2. Session 的主要作⽤就是通过服务端记录⽤户的状态。

   典型的场景是购物⻋，当你要添加商品到购物⻋的时候，系统不知道是哪个⽤户操作的，因为 HTTP 协议是⽆状态的。服务端给特定的⽤户创建特定的 Session 之后就可以标识这个⽤户并且跟踪这个⽤户了

3. 区别：

• 存储位置：Cookie 数据存储在用户的浏览器中，而 Session 数据存储在服务器上。
• 数据容量：Cookie 存储容量较小，一般为几 KB。Session 存储容量较大，通常没有固定限制，取决于服务器的配置和资源。
• 安全性：由于 Cookie 存储在用户浏览器中，因此可以被用户读取和篡改。相比之下,Session 数据存储在服务器上，更难被用户访问和修改。
• 传输方式：Cookie 在每次 HTTP 请求中都会被自动发送到服务器，而 Session ID 通常通过 Cookie 或 URL 参数传递。

---

面试官： 服务端没有 listen，客户端发起连接建立，会发生什么？

候选人：

服务端如果只 bind 了 IP 地址和端口，而没有调用 listen 的话，然后客户端对服务端发起了连接建立，服务端会回 RST 报文中止这个连接。

服务端建立连接步骤

1. Socket 创建 (socket()) ：
   • 服务端首先需要创建一个套接字（socket），通过系统调用 socket() 创建，并指定协议类型（例如 TCP/UDP），从而获得一个用于通信的文件描述符。
2. 绑定地址 (bind()) ：
   • 使用 bind() 将创建的套接字绑定到特定的 IP 地址和端口号上，使服务端在该地址上监听。bind() 允许服务端指定要处理的网络接口和端口，确保客户端可以在正确的 IP 和端口上找到服务。
3. 监听连接请求 (listen()) ：
   • 通过 listen() 设置套接字为被动模式，准备接受客户端连接。此时，服务端的 TCP 协议栈开始准备接受来自客户端的 SYN（同步）数据包。这是 TCP 三次握手的起点，虽然 listen() 本身不直接触发握手，但它让服务端进入了一种"被动等待连接"的状态，为三次握手的发生创造了条件。
4. 接受连接 (accept()) ：
   • 三次握手完成后，服务端的 TCP 协议栈会将这个已建立的连接放入 listen() 设置的连接队列中。accept() 则从这个队列中取出一个已完成的连接，生成了一个新的套接字，用于与该客户端的具体通信。

---

面试官： 没有 listen，能建立 TCP 连接吗？

候选人： 是可以的，客户端是可以自己连自己的形成连接（TCP自连接），也可以两个客户端同时向对方发出请求建立连接（TCP同时打开），这两个情况都有个共同点，就是没有服务端参与，也就是没有listen，就能建立连接。

客户端步骤

1. Socket 创建 (socket()) ：
   • 客户端同样需要创建一个套接字，通过 socket() 调用生成一个文件描述符。
2. 连接服务器 (connect()) ：
   • 客户端调用 connect() 主动向服务端发起连接请求，指定目标 IP 地址和端口号。该步骤触发三次握手过程。

---

面试官：ping 的工作原理

候选人： ping 是一种网络诊断工具，用来测试本地设备与目标设备（通常是服务器）之间的网络连通性。它通过发送网络包并等待回复，来测量网络的延迟和丢包率。

工作流程

• 发送 ICMP Echo 请求 ：ping 使用的是 ICMP（Internet Control Message Protocol）协议。首先，源设备向目标设备发送一个请求数据包。

• 接收 ICMP Echo 回复：目标设备接收到请求后，返回一个回复数据包，告诉源设备它已经成功收到了请求。

• 延迟测量 ：ping 记录从发送请求到接收回复的时间，称为 RTT（Round-Trip Time），即往返时间。这可以帮助用户评估网络的延迟情况。

ICMP 协议：ICMP 是一种无连接的网络层协议，主要用于传输网络错误信息和诊断消息。它工作在 IP 层，用于报告数据传输中的错误或提供诊断信息。