八股—8.计算机网络

网络模型

为什么要有网络模型?

对于同一台设备上的进程间通信，有很多种方式，比如有管道、消息队列、共享内存、信号等方式， 
而对于不同设备上的进程间通信，就需要网络通信，
而设备是多样性的，所以要兼容多种多样的设备，就协商出了一套通用的网络协议。
这个网络协议是分层的，每一层都有各自的作用和职责

OSI七层模型⭐️

为了使得多种设备能通过网络相互通信，和为了解决各种不同设备在网络互联中的兼容性问题，国际标准化组织制定了OSI 网络模型，该模型主要有 7 层，分别是应用层、表示层、会话层、传输层、网络层、数据链路层以及物理层。

每一层负责的职能都不同，如下，

应用层，负责给应用程序提供统一的接口；
表示层，负责把数据转换成兼容另一个系统能识别的格式；
会话层，负责建立、管理和终止表示层实体之间的通信会话；
传输层，负责端到端的数据传输；
网络层，负责数据的路由、转发、分片；
数据链路层，负责数据的封帧和差错检测，以及 MAC 寻址；
物理层，负责在物理网络中传输数据帧；

由于 OSI 模型实在太复杂，提出的也只是概念理论上的分层，并没有提供具体的实现方案。
事实上，我们比较常见，也比较实用的是四层模型，即 TCP/IP 网络模型。

TCP/IP模型有哪几层？⭐️⭐️⭐️

TCP/IP 网络通常是由上到下分成 4 层，分别是应用层，传输层，网络层和网络接口层。

应用层

这一层是最接近用户的，负责为用户提供应用服务，它包括我们常见的应用协议，如 HTTP（用于网页浏览）、FTP（用于文件传输）、SMTP（用于邮件传输）等。
处理应用数据并将其传递给下层，不关心数据的传输过程。
应用层工作在操作系统的用户态，而传输层及以下则工作在内核态。

传输层

传输层负责为应用层提供端到端的数据传输服务。常用的传输协议有 TCP 和 UDP。
TCP（传输控制协议）确保数据可靠传输，保持顺序和完整性；
UDP （用户数据报协议）提供更快但不可靠的数据传输。
当数据包超过最大报文段长度 （MSS） 时，传输层会对数据进行分块传输。即使某个分块丢失或损坏，只有该分块需要重传。
传输层通过 端口号 来区分不同应用。接收方可以通过端口号识别数据包对应的应用。

网络层

网络层负责将数据包从源主机传输到目标主机，主要通过 IP协议 来实现。
它通过 IP地址 确定数据包的目标子网和主机，使用路由选择来决定数据包的传输路径，确保数据包准确到达目标主机。

网络接口层

负责物理网络中的数据传输，常见协议是 Ethernet（以太网）。
确保数据在网络设备之间可靠传输。

HTTP、tcp、ip分别位于哪一层？⭐️

HTTP在应用层                TCP 在传输层                IP 在网络层

网络为什么要分层？

说到分层，我们先从我们平时使用框架开发一个后台程序来说，我们往往会按照每一层做不同的事情的原则将系统分为三层（复杂的系统分层会更多）:

Repository（数据库操作）
Service（业务操作）
Controller（前后端数据交互）

各层之间相互独立，提高了灵活性和可替换性，大问题化小。

DNS

DNS是什么？解决了什么问题？是哪一层的协议？

DNS（Domain Name System）域名管理系统，是当用户使用浏览器访问网址之后，使用的第一个重要协议。
DNS 要解决的是域名和 IP 地址的映射问题。
DNS 是应用层协议，它可以在 UDP 或 TCP 协议之上运行，端口为 53 。

DNS能解析端口吗？

DNS 是域名解析协议，只能将域名和IP 地址相互映射，不能指定端口。
如果想通过域名访问特定端口的服务 可以通过 Nginx 反向代理(或其他反向代理服务器)

HTTP

键入网址到网页显示，期间发生了什么？⭐️⭐️⭐️⭐️

从输入 URL 到页面展示，整体是从浏览器发起请求到最终页面呈现给用户，步骤如下：

用户输入URL并按回车：

浏览器解析输入的URL，将其分解为协议（如HTTP、HTTPS）、域名和路径等部分。

DNS解析：
浏览器通过DNS（域名系统）获取域名的IP地址。如果IP地址已缓存，直接使用缓存的IP；否则，向DNS服务器发送请求获取IP。

建立TCP连接：
浏览器根据获取的IP地址，向目标服务器发起一个TCP连接。

客户端发送HTTP请求：
在建立TCP连接后，浏览器发送HTTP请求到服务器。请求包括请求行、请求头和请求体
请求行包含请求方法（如 GET、POST）、请求的 URL 路径和 HTTP 版本。
请求头包括浏览器信息、语言类型、缓存控制等信息。
请求体则用于发送数据（如表单提交数据）。

服务器处理请求并发送HTTP响应：
服务器接收到请求后，处理请求，构建HTTP响应并返回给浏览器。
响应包含响应行、响应头和响应体。
响应行指示处理结果（如 200 OK、404 Not Found），
响应头包含缓存控制、内容类型、日期等信息，
响应体则是实际的页面内容（HTML、CSS、JavaScript、图片等）。

浏览器解析和渲染页面：
浏览器收到HTTP响应后，解析响应体中的 HTML 内容，渲染网页的结构和样式，同时根据HTML中的其他资源的URL（如图片、CSS、JS等），再次发起HTTP请求，获取这些资源的内容，知道网页完全加载显示。

关闭TCP连接：
当浏览器无需与服务器通信时，它会主动关闭TCP连接，或等待服务器发送关闭请求。

HTTP 状态码有哪些？⭐️⭐️

HTTP 状态码是 Web 服务器在响应 HTTP 请求时返回的数字代码，用于指示请求的处理结果。状态码由三位数字组成，按照功能分为五大类。下面描述了 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，代表服务器作为网关时，未能及时收到上游服务器的响应。

HTTP 和 HTTPS 有什么区别？⭐️⭐️⭐️⭐️

HTTP（HyperText Transfer Protocol） 和 HTTPS（HyperText Transfer Protocol Secure） 都是 Web 传输协议，用于在客户端（浏览器）和服务器之间通信。HTTPS 是 HTTP 的安全增强版本，在传输过程中提供加密和数据完整性保障。它们的区别在：

安全性和资源消耗
HTTP 协议运行在 TCP 之上，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份。
HTTPS 是运行在 SSL/TLS 之上的 HTTP 协议，SSL/TLS 运行在 TCP 之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。
所以说，HTTP 安全性没有 HTTPS 高，但是 HTTPS 比 HTTP 耗费更多服务器资源。
端口号和URL前缀
HTTP 使用默认端口 80，前缀是http：//；
HTTPS 使用默认端口 443，前缀是https：//。
区别在于 HTTPS 需要额外的 SSL/TLS 握手过程。
搜索引擎偏好SEO
搜索引擎通常偏好使用 HTTPS 协议的网站，因为 HTTPS 提供更高的安全性和用户隐私保护。采用 HTTPS 协议的网站在搜索结果中可能会获得优先排名，从而对 SEO 产生积极影响。

HTTPS怎样加密⭐️

内容加密采用对称加密
但对称加密的密钥用服务器方的证书进行了非对称加密

HTTPS加密过程

客户端向服务器发送 HTTPS 请求。
服务器将公钥证书发送给客户端。公钥证书包含公钥、域名、有效期等，证明身份合法
客户端验证服务器的证书。
如果验证通过，客户端生成一个用于会话的对称密钥。
客户端使用服务器的公钥对对称密钥进行加密，并将加密后的密钥发送给服务器。
服务器使用私钥对客户端发送的加密密钥进行解密，得到对称密钥。
服务器和客户端使用对称密钥进行加密和解密数据传输。

对称加密（同钥加解密）效率高但密钥难安全传输（明文传密钥易被截获）；
非对称加密（公钥加密、私钥解密）可安全传密钥但效率低（不适合大量数据）。
非对称加密规则是公钥加密→私钥解密、私钥加密→公钥解密，若用 “私钥加密 – 私钥解密”，逻辑退化为对称加密（失去非对称价值），且私钥加密内容用公钥可解，易致密钥泄露，故不采用。
HTTPS 用非对称加密安全传对称密钥，再用对称加密高效传数据，避开二者短板，实现安全与效率平衡。

HTTP/1.0 ， HTTP/1.1 ，HTTP/2.0，HTTP/3.0有什么区别？☆

HTTP/1.0 (1996)

每次请求都要建立新的 TCP 连接，效率低（如加载网页时每个资源都会重新建立连接）

不支持管道化，每次请求必须等待前一个完成后才能发送。

HTTP/1.1 (1999)（面试重点）

持久连接：一个 TCP 连接可以处理多个请求，减少了重复的握手过程，提高效率。

管道化：允许多个请求顺序发送，但若一个请求阻塞（如文件下载慢），后续请求会被卡住（队头阻塞问题）。

缓存机制：增加了缓存策略，减少重复资源请求（如图片是否更新）。

HOST 字段：支持虚拟主机，多个网站可以共享同一 IP 地址。

HTTP/2.0 (2015)（面试高频考点）

二进制分帧：将请求和响应分解为二进制“帧”，以二进制格式传输（HTTP/1.x 是文本格式），计算机解析更快。

多路复用：多个请求/响应可以在同一个连接中并行传输，避免了队头阻塞（同时加载网页的不同资源）。

头部压缩：使用了 头部压缩（HPACK），只在首次请求时发送，之后只发送变化的部分，减少了重复数据的传输。
在 HTTP/1.x 中，每次请求都会重复发送这些信息，浪费带宽。

服务器推送：服务器可主动推送资源给客户端（例如访问网页时，服务器预判需要加载某张图片，直接随 HTML 响应一起发送）。

HTTP/3.0 (2022)（技术前沿）

基于 QUIC 协议：使用 UDP 代替 TCP，解决 TCP 在高延迟网络下的性能问题。

更低的握手延迟：TCP 三次握手需 1-RTT（往返时间），QUIC 通过加密握手（TLS 1.3）将握手时间缩短到 0.5-RTT，首次连接更快。

解决队头阻塞：QUIC 将每个数据流拆分为独立数据包，某一数据包丢失不影响其他数据流（而 TCP 中一个包丢失会阻塞整个连接）。

WebSocket

WebSocket是什么？与HTTP区别？

WebSocket 是一种在单个 TCP 连接上实现双向、全双工通信的网络协议，允许服务器主动向客户端推送数据（无需客户端频繁请求）。

实时交互场景（如在线聊天、弹幕、协作编辑）：传统 HTTP 需要客户端不断发送请求 “拉取” 数据（如轮询），而 WebSocket 可让服务器主动 “推送” 新消息，延迟更低。
实时数据监控（如股票行情、物联网设备状态）：服务器能实时将数据变化推送给客户端，无需客户端反复请求。

WebSocket双向，HTTP单向；WebSocket支持扩展；WebSocket通信数据较轻量。

WebSocket的工作过程是什么样的？

客户端通过 HTTP 向服务器发起请求，表示希望升级到 WebSocket 协议，服务器回应确认升级。

握手成功后，HTTP 连接会被升级为 WebSocket 连接，建立起持久的连接。

连接建立后，客户端和服务器可以互相发送数据，支持双向实时通信，消息传递无需频繁的请求和响应。

当通信完成，任何一方都可以发起关闭连接的请求，WebSocket 会正常断开连接。

SSE与WebSocket区别？

两者都可以建立服务端与浏览器之间的通信，实现服务端向客户端推送消息。
但 SSE 只能由服务端向客户端单向通信，这是主要区别。

PING

PING命令的作用？工作原理？

测试网络中主机之间的连通性和网络延迟。
如果 PING 对应的目标主机无法得到正确的响应，则表明这两个主机之间的连通性存在问题。如果往返时间（RTT）过高，则表明网络延迟过高。
PING 基于网络层的 ICMP（Internet Control Message Protocol，互联网控制报文协议），其主要原理就是通过在网络上发送和接收 ICMP 报文实现的。

PING 命令会向目标主机发送 ICMP Echo Request。
如果两个主机的连通性正常，目标主机会返回一个对应的 ICMP Echo Reply。

TCP与DUP

TCP的三次握手与四次挥手⭐️⭐️⭐️⭐️⭐️⭐️

TCP 的三次握手和四次挥手是建立和断开 TCP 连接的过程。

三次握手（建立连接）：

SYN：客户端发送一个带 SYN 标志的数据包，表示请求建立连接。

SYN-ACK：服务器收到请求后，回应一个带 SYN 和 ACK 标志的数据包，表示同意建立连接。

ACK：客户端再发送一个带 ACK 标志的数据包，确认连接建立完成。

四次挥手（断开连接）：

FIN：客户端发送一个带 FIN 标志的数据包，表示准备关闭连接。

ACK：服务器收到 FIN 后，发送一个 ACK 包，确认收到关闭请求。

FIN：服务器准备关闭时，发送一个带 FIN 标志的数据包，表示关闭连接。

ACK：客户端收到服务器的 FIN 后，再发送一个 ACK 包，确认连接断开。

简而言之，三次握手确保连接可靠地建立，四次挥手确保双方都能正确关闭连接。

 

为什么要三次握手？

三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。

第一次握手：客户端什么都不能确认；服务器确认了对方发送正常，自己接收正常
第二次握手：客户端确认了：自己发送、接收正常，对方发送、接收正常；服务器确认了：对方发送正常，自己接收正常
第三次握手：客户端确认了：自己发送、接收正常，对方发送、接收正常；服务器确认了：自己发送、接收正常，对方发送、接收正常

三次握手就能确认双方收发功能都正常，缺一不可。

为什么要四次挥手？

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

半连接队列和全连接队列？如何工作的？⭐️⭐️

在 TCP 三次握手过程中，Linux 内核会维护两个队列来管理连接请求：

半连接队列（SYN Queue）：当服务端收到客户端的 SYN 请求时，此时双方还没有完全建立连接，它会把半连接状态的连接放在半连接队列。
全连接队列（Accept Queue）：当服务端收到客户端对 ACK 响应时，意味着三次握手成功完成，服务端会将该连接从半连接队列移动到全连接队列。如果未收到客户端的 ACK 响应，会进行重传，重传的等待时间通常是指数增长的。如果重传次数超过系统规定的最大重传次数，系统将从半连接队列中删除该连接信息。

这两个队列的存在是为了处理并发连接请求，确保服务端能够有效地管理新的连接请求。

正常流程：

当服务端接收到客户端的 SYN 报文时，会创建一个半连接的对象，然后将其加入到内核的「 SYN 队列」；
接着发送 SYN + ACK 给客户端，等待客户端回应 ACK 报文；
服务端接收到 ACK 报文后，从「 SYN 队列」取出一个半连接对象，然后创建一个新的连接对象放入到「 Accept 队列」；
应用通过调用 accpet()接口，从「 Accept 队列」取出连接对象。

不管是半连接队列还是全连接队列，都有最大长度限制，超过限制时默认情况都会丢弃报文

TCP与DUP的区别和使用场景⭐️⭐️⭐️

可靠性：

TCP：提供可靠的、面向连接的服务，保证数据的顺序和完整性。它会进行三次握手来建立连接，并且有流量控制和重传机制，确保数据正确到达。

UDP：是不可靠的、无连接的协议，不保证数据的顺序和完整性。它发送数据时不进行连接建立，也没有重传机制，适用于对实时性要求高、容错性强的应用。

速度：

TCP：由于有更多的控制和错误处理，速度较慢。

UDP：没有连接建立、重传机制等，所以速度较快，适用于对延迟敏感的应用。

是否支持广播或多播：

TCP：只支持点对点通信。

UDP：支持一对一、一对多、多对一、多对多。

使用场景：

TCP 用于对传输准确性要求特别高场景，比如网页浏览（HTTP）、文件传输（FTP）、电子邮件（SMTP）等
UDP 一般用于即时通信，比如：语音、 视频、直播等等。这些场景对传输数据的准确性要求不是特别高，比如你看视频即使少个一两帧，实际给人的感觉区别也不大。

TCP是如何保证传输的可靠性？⭐️⭐️⭐️⭐️

TCP 保证传输可靠性的方法有以下几个关键机制：

三次握手：在数据传输之前，TCP 通过三次握手建立连接，确保双方准备好进行通信

数据确认（ACK）：每收到一个数据包，接收方会发送一个确认包（ACK）回发送方，告知数据已成功接收。

重传机制：如果发送方在一定时间内没有收到确认（ACK），它会重传数据，确保数据最终到达接收方。

数据顺序：TCP 会给每个数据包编号，接收方按照顺序重新组装数据，确保数据按顺序到达。

流量控制：通过滑动窗口机制，TCP 控制发送方的发送速度，避免接收方处理不过来导致数据丢失。

拥塞控制：TCP 会根据网络状况动态调整数据传输速率，避免网络拥塞，确保网络的稳定性。

简而言之，TCP 通过确认、重传、顺序控制、流量控制和拥塞控制等机制，确保数据可靠、无差错地传输。

使用TCP、UDP的协议有哪些？⭐️⭐️

运行于 TCP 协议之上的协议：HTTP/3.0之前、HTTPS、FTP、SMTP、DNS 等
运行于 UDP 协议之上的协议：HTTP/3.0、DHCP 协议、DNS等

TCP的缺点？⭐️

较低的传输效率：因为它需要进行连接建立、数据确认、重传和流量控制等机制，导致传输速度比 UDP 更慢。

较大的首部开销：TCP 首部开销较大（最小 20 字节），相较于 UDP 的 8 字节，增加了传输的负担。

连接管理开销：TCP 需要维护连接状态，并进行三次握手、四次挥手等过程，这增加了计算和内存的消耗。

适应性差：TCP 在高延迟和大流量的网络环境中表现不佳，因为它的重传和拥塞控制机制可能导致性能下降。

TCP的流量控制是由发送方和接收方哪一方来控制的，同问TCP的拥塞控制？⭐️

TCP的流量控制是由接收方来控制的。

接收方通过滑动窗口机制告诉发送方它能够接收的数据量。如果接收方的缓冲区满了，它会减少窗口大小，防止接收方缓存满了导致数据丢失。

TCP的拥塞控制是由发送方来控制的。

发送方根据网络的拥塞状况调整发送速度。如果网络发生拥塞，发送方会减慢发送速度，避免过多的数据导致网络崩溃。拥塞控制通过算法（如慢开始、拥塞避免等）来实现。

介绍下慢启动（拥塞控制）⭐️

慢启动是 TCP 拥塞控制中的一个重要机制，目的是防止网络拥塞并逐渐增加数据发送速率。

具体过程：

初始化窗口：刚建立连接时，发送方不知道网络拥堵情况，先设一个小的拥塞窗口cwnd（初始通常为 1-2 个 MSS）。

指数增长：每当收到一个 ACK 确认，拥塞窗口翻倍（指数增长）（1→2→4→8…）。TCP 发送方的发送速率逐渐增加。

达到阈值：当窗口大小达到慢启动阈值时，TCP 切换到拥塞避免阶段，（每次只增加 1 个数据块）（线性增长），防止网络被压垮。

目的：慢启动目的是为了快速利用可用带宽，同时避免一开始就发送大量数据导致网络拥塞

HTTP是基于TCP还是UDP？

HTTP 是基于 TCP 的协议。

HTTP 需要保证数据的可靠传输、顺序到达和完整性，因此它使用 TCP 作为传输层协议
TCP 提供了可靠的连接和数据传输机制，例如三次握手、数据确认和重传等，这些对 HTTP 传输至关重要，尤其是在传输网页、图像等数据时。

为什么DNS协议使用UDP？只使用了UDP吗？

DNS 协议使用 UDP 主要是因为：

查询响应快：DNS 查询通常非常简单，数据量小，使用 UDP 可以避免建立连接的开销，从而提高查询效率，减少延迟。

请求-响应模式：DNS 查询是一个简单的请求-响应过程，UDP 是无连接的协议，非常适合这种快速、短小的数据传输。

大部分时间使用 UDP，但在以下情况会使用 TCP：

响应数据较大：如果 DNS 响应数据超过 UDP 的限制（一般是 512 字节），会切换到 TCP。

区域传输：在 DNS 服务器之间同步大量数据时，会使用 TCP。

总结：DNS 使用 UDP 是为了提高效率，但在数据量大或特殊场景下，也会使用 TCP。

TCP的粘包与拆包⭐️⭐️⭐️⭐️

粘包：

定义：多个小的数据包被合并成一个大数据包一起发送，接收方无法区分这些包的边界

原因：TCP 是面向字节流的协议，数据是连续流动的，发送端发送多个小包时，网络会将它们合并成一个包。接收方无法判断哪些是一个完整的消息，哪些是后续的消息。

拆包：

定义：一个大的数据包被拆成多个小包发送，接收方收到的数据不是完整的一条消息，需要将多个小包重新组合成完整的消息。

解决方式：

粘包和拆包问题通常通过以下方法来解决：

固定长度：每个数据包的长度固定，接收方知道如何拆分数据。

分隔符：在每个数据包的末尾加上特殊的分隔符（如
），接收方根据分隔符来区分不同的数据包。

长度字段：包头加字段标识包长，按长度读取数据。

TCP和UDP可以使用同一个端口吗?⭐️⭐️

TCP和UDP可以使用同一个端口号，因为它们是两种不同的协议，操作在不同的网络层。

在网络中，一个端口号的唯一性是由IP地址、端口号和协议三者共同决定的。这意味着TCP和UDP各自可以绑定相同的端口号，而不会产生冲突，因为协议类型(TCP或UDP)作为区分。这种机制允许应用程序同时或分别监听相同的端口号上的TCP和UDP流量。
举例来说，DNS服务就是一个典型的例子，它通常同时在UDP和TCP的53端口上监听。对于大多数查询，DNS使用UDP协议，因为它更快，且DNS请求和响应通常都很小，适合UDP。然而，当DNS响应数据较大时，超过了UDP的限制，就会改用TCP协议，以确保数据的完整性和可靠性。

什么是MAC地址？IP地址到MAC地址是如何转换的？

MAC 地址（媒体访问控制地址）是网卡在数据链路层的唯一标识符。它是一个硬件地址，通常由 6 字节（48 位）16进制数组成，每个设备在制造时都会分配一个唯一的 MAC 地址。

IP 地址到 MAC 地址的转换是通过 ARP（地址解析协议） 来完成的。具体步骤如下：

ARP 请求：当设备需要将数据发送到某个 IP 地址时，它首先检查自己的 ARP 缓存，如果没有找到对应的 MAC 地址，就会广播一个 ARP 请求，询问局域网中谁拥有该IP地址

ARP 响应：拥有该 IP 地址的设备会回复一个 ARP 响应，包含它的 MAC 地址。

更新缓存：请求设备收到 ARP 响应后，会将 IP 地址和对应的 MAC 地址存入 ARP 缓存，以便下次使用。

简而言之，ARP 协议通过广播请求和响应来将 IP 地址 转换成 MAC 地址，以便设备在局域网内可以根据 MAC 地址进行通信。

GET 和 POST

GET 和 POST的区别⭐️⭐️⭐️

特性	GET	POST
用途	请求资源或查询数据	提交数据或创建/更新资源
参数位置	URL 查询字符串（?key=value&key=value）	请求体（body）
数据可见性	明文显示在 URL 中	参数在请求体中，不显示在 URL 中
长度限制	限制较大（一般为 2048 字符）	无限制，可以传输大量数据
缓存	可以缓存（浏览器可以缓存 GET 请求）	通常不缓存
幂等性	幂等（多次相同请求产生相同结果）	非幂等（每次请求可能产生不同结果）
安全性	不适合传递敏感数据（明文传输）	比较安全，但仍需使用 HTTPS 加密通信
重复执行	支持重复执行（不会产生副作用）	不支持重复执行（可能导致重复操作）
使用场景	获取资源、查询操作、导航等	提交表单、上传文件、创建/修改数据等

GET 和 POST 方法都是安全和幂等的吗？

GET：幂等且不安全

GET 方法用于请求数据，不会改变服务器的状态。
数据暴露在 URL 中。

POST：非幂等且相对更安全

POST 方法通常用于提交数据，可能会导致服务器上的资源发生变化
数据包含在请求体中。

Cookie、Session、Token 之间有什么区别？

维度	Cookie	Session	Token
存储位置	客户端（浏览器）	服务器端	客户端（LocalStorage 等）
安全性	较低（易被篡改、XSS 攻击）	较高（数据在服务器）	较高（加密签名，无状态）
服务器负担	无（仅读取 Cookie）	有（需存储会话数据）	无（不存储状态）
跨域支持	较差（受同源策略限制）	较差（依赖特定服务器）	较好（可通过 Token 传递）
典型应用	记住登录状态、网站偏好	购物车、表单会话管理	API 认证、跨平台身份验证

Cookie：客户端存储的状态标识

定义：Cookie 是服务器发送到客户端浏览器并存储在本地的一小段文本数据，用于追踪用户状态，本质是 “客户端存储 + 浏览器自动携带”。

工作流程：

服务器响应请求时，通过Set-Cookie响应头向浏览器发送 Cookie；
浏览器后续向同一域名发送请求时，会自动在请求头中携带 Cookie；
服务器通过解析 Cookie 识别用户身份。

特点：

优点：浏览器原生支持，自动携带，无需额外开发；可跨域名共享。
缺点：存储容量小；明文存储，安全性低(XSS 攻击)；每次请求都携带，增加流量开销

// 创建与设置：
// 在Servlet中操作Cookie
Cookie cookie = new Cookie("username", "user123");
cookie.setMaxAge(3600); // 有效期1小时
cookie.setPath("/");    // 生效路径
response.addCookie(cookie);

// 读取：
Cookie[] cookies = request.getCookies();
if (cookies != null) {
    for (Cookie cookie : cookies) {
        if ("username".equals(cookie.getName())) {
            String value = cookie.getValue(); // 处理用户身份
        }
    }
}

Session：服务器端的会话状态管理

定义：Session 是服务器为用户创建的会话状态存储，通过Session ID（通常通过 Cookie 传递）关联用户请求，本质是 “服务器存储 + 客户端标识”。

工作流程：

首次请求时，服务器创建 Session 并生成唯一 ID；
通过 Cookie 将 Session ID 返回给浏览器；
后续请求携带 Session ID，服务器根据 ID 查询会话状态。
java中实现

单机 Session 无法跨服务器共享，需通过 Redis、Memcached 等分布式缓存实现 Session 共享。

特点：

优点：数据存储在服务器，安全性高；容量无严格限制，可存储复杂对象。
缺点：服务器存储压力大，需考虑集群环境下的共享问题；依赖 Cookie（若禁用 Cookie，需通过 URL 重写传递 Session ID）。

// 创建或获取Session
HttpSession session = request.getSession(); // 自动创建新Session或获取已有
session.setAttribute("userId", 123); // 存储用户信息

// 读取Session
Integer userId = (Integer) session.getAttribute("userId");

// 设置过期时间（默认30分钟）
session.setMaxInactiveInterval(30 * 60); // 单位：秒

Token：无状态的身份验证机制

定义：Token 是服务器生成的加密字符串，客户端携带 Token 访问资源，服务器无需存储状态，本质是 “自包含信息 + 无状态验证”。

典型实现：JWT（JSON Web Token）

结构：Header（头部）+ Payload（负载）+ Signature（签名），通过.分隔，例如：xxx.yyy.zzz。
工作流程：

用户登录成功后，服务器生成 JWT 并返回；
客户端后续请求在 Header 中携带Bearer Token；
服务器通过密钥验证 Token 合法性，解析 Payload 获取用户信息。

特点：

无状态：服务器不存储 Token，支持高并发和微服务架构；
自包含：Payload 可存储用户信息，减少数据库查询；
跨平台：客户端只需携带 Token，不依赖 Cookie，适合移动端、小程序等场景；
安全性：通过签名防止篡改，需配合 HTTPS 传输。

// 生成JWT:
// 使用JJWT库生成JWT
String token = Jwts.builder()
    .setSubject("user123") // 主题，存储用户标识
    .claim("roles", Arrays.asList("user", "admin")) // 自定义声明
    .setExpiration(new Date(System.currentTimeMillis() + 24 * 60 * 60 * 1000)) // 过期时间
    .signWith(SignatureAlgorithm.HS256, "secretKey") // 签名算法与密钥
    .compact();

// 验证JWT
try {
    Claims claims = Jwts.parser()
        .setSigningKey("secretKey")
        .parseClaimsJws(token)
        .getBody();
    String userId = claims.getSubject();
    List<String> roles = (List<String>) claims.get("roles");
    // 验证通过，处理业务逻辑
} catch (Exception e) {
    // Token无效或过期
}