这里是计算机网络的一些八股

计算机网路层次结构

OSI参考模型

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

TCP/IP模型

应用层 主要提供两个终端设备上的应用程序之间信息交换的服务，它定义了信息交换的格式，消息会交给下一层传输层来传输
- 协议：HTTP 、DNS 、SMTP 、FTP
传输层处理主机到主机的通信
- 协议：TCP、UDP
网络层寻址和路由数据包(IP 协议)——（转发与路由 ）
- 协议：IP、ARP、ICMP 、NAT、OSPF、RIP、BGP
链路层通过网络的物理电线、电缆或无线信道移动比特

一、HTTP

HTTP、HTTPS、DNS、FTP(文件传输协议 ) 都是应用层协议

http 是 80，https 默认是 443。

DNS默认端口号：53

1.HTTP常用的状态码

1xx 类状态码属于提示信息，是协议处理中的一种中间状态，实际用到的比较少。
2xx 类状态码表示服务器成功处理了客户端的请求，也是我们最愿意看到的状态。
3xx 类状态码表示客户端请求的资源发生了变动，需要客户端用新的 URL 重新发送请求获取资源，也就是重定向。
- 「301 Moved Permanently」表示永久重定向，说明请求的资源已经不存在了，需改用新的 URL再次访问。
- 「302 Found」表示临时重定向，说明请求的资源还在，但暂时需要用另一个 URL 来访问。
4xx 类状态码表示客户端发送的报文有误，服务器无法处理，也就是错误码的含义。
- 400 Bad Request：发送的 HTTP 请求存在问题。比如请求参数不合法、请求方法错误。
- 404 Not Found：你请求的资源未在服务端找到。比如你请求某个用户的信息，服务端并没有找到指定的用户。
5xx 类状态码表示客户端请求报文正确，但是服务器处理时内部发生了错误，属于服务器端的错误码。
- 500（Internal Server Error）表示服务器内部错误，通常由服务器端代码问题引起。
- [502 Bad Gateway」表示网关或代理服务器从上游服务器(服务端)收到了无效响应，通常与服务器之间的通信问题有关。
- 504 Gateway Time-out:表示网关或代理服务器在等待上游服务器的响应时超时，通常是由于上游服务器处理时间过长或无法访问。
  
  举一个例子，假设 nginx 是代理服务器，收到客户端的请求后，将请求转发到后端服务器(tomcat 等)。
  - 当nginx收到了无效的响应时，就返回502。
  - 当nginx超过自己配置的超时时间，还没有收到请求时，就返回504错误。

2.HTTP头部常见字段

HTTP报文组成如下：

请求报文	响应报文
请求行	状态行
请求头部	响应头部
空行	空行
请求体	响应体

其中头部字段主要有；

Host 字段：客户端发送请求时，用来指定服务器的域名。 Host: www.A.com。有了 Host 字段，就可以将请求发往「同一台」服务器上的不同网站。
Content-Length 字段 ：服务器在返回数据时，会有 Content-Length 字段，表明本次回应的数据长度。

HTTP 是基于 TCP 传输协议进行通信的，而使用了 TCP 传输协议，就会存在一个“粘包”的问题，HTTP 协议通过设置回车符、 换行符作为 HTTP header 的边界，通过 Content-Length 字段作为 HTTP body 的边界，这两个方式都是为了解决“粘包”的问题。
Connection 字段 ：Connection 字段最常用于客户端要求服务器使用「HTTP 长连接」机制，以便其他请求复用，Connection: Keep-Alive。 HTTP 长连接的特点是，只要任意一端没有明确提出断开连接，则保持 TCP 连接状态。
Content-Type 字段 ：Content-Type 字段用于服务器回应时，告诉客户端，本次数据是什么格式。客户端请求的时候，可以使用 Accept 字段声明自己可以接受哪些数据格式。
Content-Encoding 字段 ：Content-Encoding 字段说明数据的压缩方法。表示服务器返回的数据使用了什么压缩格式。客户端在请求时，用 Accept-Encoding 字段说明自己可以接受哪些压缩方法。

3.HTTP和HTTPS的区别⭐

区别主要有以下五点:

安全性和资源消耗： HTTP 是超文本传输协议，信息是明文传输，存在安全风险的问题。HTTPS 是运行在 SSL/TLS 之上的 HTTP 协议，SSL/TLS 运行在 TCP 之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。所以说，HTTP 安全性没有 HTTPS 高，但是 HTTPS 比 HTTP 耗费更多服务器资源。
连接过程：HTTP 连接建立相对简单， TCP 三次握手之后便可进行 HTTP 的报文传输。而 HTTPS 在 TCP 三次握手之后，还需进行 SSL/TLS 的握手过程，才可进入加密报文传输。
端口号，HTTP 默认端口号是 80，HTTPS 默认端口号是 443。
SEO（搜索引擎优化）：搜索引擎通常会更青睐使用 HTTPS 协议的网站，因为 HTTPS 能够提供更高的安全性和用户隐私保护。使用 HTTPS 协议的网站在搜索结果中可能会被优先显示，从而对 SEO 产生影响。

4. 1.0和1.1的区别

主要是前三个

连接方式 : HTTP/1.0 默认情况下为短连接，HTTP/1.1 支持长连接。HTTP 协议的长连接和短连接，实质上是 TCP 协议的长连接和短连接。
管道化（Pipelining）：
- HTTP/1.0：不支持管道化，客户端必须等待前一个请求的响应后才能发送下一个请求。
- HTTP/1.1：支持管道化，允许客户端发送多个请求而不必等待每个响应，这可以进一步提高性能。
1.1允许请求部分资源：HTTP/1.0 中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP/1.1 则在请求头引入了 range 头域，它允许只请求资源的某个部分，即返回码是 206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。
状态响应码 : HTTP/1.1 引入了更多的状态码和错误处理机制，提供了更详细的错误信息。
Host 头（Host Header）处理 :HTTP/1.1 引入了 Host 头字段，允许在同一 IP 地址上托管多个域名，从而支持虚拟主机的功能。而 HTTP/1.0 没有 Host 头字段，无法实现虚拟主机。

5. 1.1和2.0的区别

头部压缩（Header Compression）： HTTP/2 会压缩头（Header）如果你同时发出多个请求，他们的头是一样的或是相似的，那么，协议会帮你消除重复的部分。这就是所谓的 HPACK 算法：在客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不发送同样字段了，只发送索引号，这样就提高速度了。
多路复用（Multiplexing）：HTTP/1.1每个请求和响应需要独立的 TCP 连接，或者通过 Keep-Alive 在同一连接上串行处理请求。由于是串行传输，存在“队头阻塞”问题，即一个请求的延迟会阻塞后续请求。HTTP/2.0支持多路复用，允许在单个 TCP 连接上并行发送多个请求和响应。消息被分解为独立的帧，交错传输并在另一端重新组装，有效消除了队头阻塞。
二进制帧（Binary Frames）：HTTP/2.0 使用二进制帧进行数据传输，而 HTTP/1.1 则使用文本格式的报文。二进制帧更加紧凑和高效，减少了传输的数据量和带宽消耗。
服务器推送（Server Push）：HTTP/2.0 支持服务器推送，服务器可以主动向客户端推送资源，而不需要客户端明确请求。

6.2.0和3.0的区别

前面我们知道了 HTTP/1.1 和 HTTP/2 都有队头阻塞的问题：

HTTP/1.1 中的管道（ pipeline）虽然解决了请求的队头阻塞，但是没有解决响应的队头阻塞，因为服务端需要按顺序响应收到的请求，如果服务端处理某个请求消耗的时间比较长，那么只能等响应完这个请求后，才能处理下一个请求，这属于 HTTP 层队头阻塞。
HTTP/2 虽然通过多个请求复用一个 TCP 连接解决了 HTTP 的队头阻塞，但是一旦发生丢包，就会阻塞住所有的 HTTP 请求，这属于 TCP 层队头阻塞。

HTTP/2 队头阻塞的问题是因为 TCP，所以 HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP

传输协议：HTTP/2.0 是基于 TCP 协议实现的，HTTP/3.0 新增了 QUIC（Quick UDP Internet Connections）协议来实现可靠的传输，提供与 TLS/SSL 相当的安全性，具有较低的连接和传输延迟。你可以将 QUIC 看作是 UDP 的升级版本，在其基础上新增了很多功能比如加密、重传等等。
队头阻塞：虽然支持多路复用，但在 TCP 层面仍存在队头阻塞问题。TCP 要求数据包按序到达，若一个数据包丢失，整个连接的传输会暂停，等待重传。而基于QUIC协议的3.0一个连接建立多个不同的数据流，这些数据流之间独立互不影响，某个数据流发生丢包了，其数据流不受影响
更快的连接建立：HTTP/2.0 需要经过经典的 TCP 三次握手过程（由于安全的 HTTPS 连接建立还需要 TLS 握手，共需要大约 3 个 RTT）。由于 QUIC 协议的特性（TLS 1.3，TLS 1.3 除了支持 1 个 RTT 的握手，还支持 0 个 RTT 的握手）连接建立仅需 0-RTT 或者 1-RTT。这意味着 QUIC 在最佳情况下不需要任何的额外往返时间就可以建立新连接。
连接迁移：基于 TCP 传输协议的 HTTP 协议，由于是通过四元组（源 IP、源端口、目的 IP、目的端口）确定一条 TCP 连接。这个四元组中一旦有一项值发生改变，这个连接也就不能用了。而 QUIC 协议没有用四元组的方式来“绑定”连接，而是通过连接 ID 来标记通信的两个端点，只要 ID 不变就不会中断，网络环境改变时（如从 Wi-Fi 切换到移动数据）也能保持连接。

7.HTTP如何保存用户状态？

HTTP 是无状态的协议（对于事务处理没有记忆能力，每次客户端和服务端会话完成时，服务端不会保存任何会话信息）：每个请求都是完全独立的，服务端无法确认当前访问者的身份信息，无法分辨上一次的请求发送者和这一次的发送者是不是同一个人。所以服务器与浏览器为了进行会话跟踪（知道是谁在访问我），就必须主动的去维护一个状态，这个状态用于告知服务端前后两个请求是否来自同一浏览器。而这个状态需要通过 cookie 或者 session 去实现。

那么我们如何保存用户状态呢？Session 机制的存在就是为了解决这个问题，Session 的主要作用就是通过服务端记录用户的状态。

Session 存放在服务器端，那么我们如何实现 Session 跟踪呢？大部分情况下，我们都是通过在 Cookie 中附加一个 Session ID 来方式来跟踪。

Cookie 被禁用怎么办?

最常用的就是利用 URL 重写把 Session ID 直接附加在 URL 路径的后面。

8.URI和URL的区别

URI(Uniform Resource Identifier) 是统一资源标志符，可以唯一标识一个资源。
URL(Uniform Resource Locator) 是统一资源定位符，可以提供该资源的路径。

URI 的作用像身份证号一样，URL 的作用更像家庭住址一样。URL 是一种具体的 URI，它不仅唯一标识资源，而且还提供了定位该资源的信息

9.GET和POST的区别⭐

语义（主要区别）：GET 通常用于获取或查询资源，而 POST 通常用于创建或修改资源。
幂等：GET 请求是幂等的，即多次重复执行不会改变资源的状态，而 POST 请求是不幂等的，即每次执行可能会产生不同的结果或影响资源的状态。
格式：GET 请求的参数通常放在 URL 中，形成查询字符串（querystring），而 POST 请求的参数通常放在请求体（body）中，可以有多种编码格式，如 application/x-www-form-urlencoded、multipart/form-data、application/json 等。GET 请求的 URL 长度受到浏览器和服务器的限制，而 POST 请求的 body 大小则没有明确的限制。不过，实际上 GET 请求也可以用 body 传输数据，只是并不推荐这样做，因为这样可能会导致一些兼容性或者语义上的问题。
缓存：由于 GET 请求是幂等的，它可以被浏览器或其他中间节点（如代理、网关）缓存起来，以提高性能和效率。而 POST 请求则不适合被缓存，因为它可能有副作用，每次执行可能需要实时的响应。
安全性：GET 请求和 POST 请求如果使用 HTTP 协议的话，那都不安全，因为 HTTP 协议本身是明文传输的，必须使用 HTTPS 协议来加密传输数据。另外，GET 请求相比 POST 请求更容易泄露敏感数据，因为 GET 请求的参数通常放在 URL 中。

10、键入网址到浏览器显示期间发生了什么？⭐

在牛客看到一个简答：

首先根据dns协议解析url获取服务器的ip，然后对服务器进行三次握手tcp链接，然后客户端这边会发起http请求来获取资源，然后服务端会响应请求，会返回资源，客户端拿到资源后对前端进行渲染后，执行tcp四次挥手断开链接

DNS 解析：浏览器通过 DNS 协议，获取域名对应的 IP 地址。
TCP 连接：浏览器根据 IP 向目标服务器发起一个 TCP 连接请求。这一步涉及到 TCP 的三次握手
发送 HTTP 请求：浏览器在 TCP 连接上，向服务器发送一个 HTTP 请求报文，请求获取网页的内容。
服务器处理请求：服务器收到 HTTP 请求报文后，处理请求，并返回 HTTP 响应报文给浏览器。
浏览器接收 HTTP 响应：浏览器收到 HTTP 响应报文后，解析响应体中的 HTML 代码，渲染网页的结构和样式，同时根据 HTML 中的其他资源的 URL（如图片、CSS、JS 等），再次发起 HTTP 请求，获取这些资源的内容，直到网页完全加载显示。
断开连接：TCP 四次挥手，连接结束。

解析URL：确定要访问Web 服务器和文件名
DNS解析：查询服务器域名对应的 IP 地址（这里可以有个问题：域名解析的工作流程）
获取MAC地址：当浏览器得到 IP 地址后，数据传输还需要知道目的主机 MAC 地址，（传输层TCP）因为应用层下发数据给传输层，TCP 协议会指定源端口号和目的端口号，然后下发给网络层。（网络层IP）网络层会将本机地址作为源地址，获取的IP 地址作为目的地址。然后将下发给数据链路层，数据链路层的发送需要加入通信双方的 MAC 地址，本机的 MAC 地址作为源 MAC 地址，目的 MAC 地址需要分情况处理。通过将 IP 地址与本机的子网掩码相结合，可以判断是否与请求主机在同一个子网里，如果在同一个子网里，可以使用 APR 协议获取到目的主机的 MAC地址，如果不在一个子网里，那么请求应该转发给网关，由它代为转发，此时同样可以通过 ARP 协议来获取网关的 MAC 地址，此时目的主机的 MAC 地址应该为网关的地址。
建立TCP连接：主机将使用目标IP地址和目标MAC地址发送一个TCP SYN包，请求建立一个TCP连接然后交给路由器转发，等路由器转到目标服务器后，服务器回复一个SYN-ACK包，确认连接请求。然后，主机发送一个ACK包，确认已收到服务器的确认，然后TCP连接建立完成。
HTTPS 的 TLS 四次握手:如果使用的是 HTTPS 协议，在通信前还存在 TLS 的四次握手。
发送HTTP请求:连接建立后，浏览器会向服务器发送HTTP请求。请求中包含了用户需要获取的资源的信息，例如网页的URL、请求方法(GET、POST等)等。
服务器处理请求并返回响应:服务器收到请求后，会根据请求的内容进行相应的处理。例如，如果是请求网页，服务器会读取相应的网页文件，并生成HTTP响应。

11.Cookie和Session有什么区别

在 Web 开发中，Cookie、Session、Token、JWT 是用于身份验证和状态管理的核心概念

1.cookie

存储在客户端（浏览器）

登录成功后，服务器返回用户名给前端，前端把用户名保存到浏览器的cookie。这样后续浏览器再访问后端都会自动带上cookie，从而维持状态信息。

可能存在的问题：

用户可以自己修改cookie里面存储的用户名，不安全
cookie的大小有限制
还可能会被用户禁用cookie
安全性：容易被窃取（XSS 攻击）或伪造（CSRF 攻击），需设置 HttpOnly、Secure、SameSite 等属性增强安全性。

2.session

存储在服务端（通常配合cookie使用）

session 是基于 cookie 实现的，session 存储在服务器端，sessionId 会被存储到客户端的cookie 中

登录信息传到服务端之后，服务器会在session中存储当前登录信息，并在响应头中把这个唯一的sessionId返回给前端（用的set-cookie），前端收到set-cookie后就会把这个唯一的sessionId存到cookie中，以后的每次请求都会把这个cookie发给后端

可能存在的问题：

占用服务器资源
依然需要依赖cookie
服务器需维护 Session 存储，在分布式系统中需共享 Session 存储（如 Redis 集群）。（集群模式下，前端的每次请求通过负载均衡可能会发到不同的服务器上，比如第一次发到A服务器上登录成功后，第二次发到B服务器上会判定你未登录）

问：如果客户端禁用了cookie，session还能用吗？

默认情况下禁用 Cookie 后，Session 是无法正常使用的，因为大多数 Web 服务器都是依赖于 Cookie 来传递 Session 的会话 ID 的。

但是，可以通过将Session ID附加到URL中作为参数来继续使用，服务器端需要相应地解析 URL 来获取 Session ID，并维护用户的会话状态。如果用户通过电子邮件或其他方式分享了这样的链接，可能导致Session ID的意外泄露

12.Token和JWT

1. Token

每一次请求都需要携带 token，需要把 token 放到 HTTP 的 Header 里

基于 token 的用户认证是一种服务端无状态的认证方式，服务端不用存放 token 数据。用解析 token 的计算时间换取 session 的存储空间，从而减轻服务器的压力，减少频繁的查询数据库

Token 是一种授权凭证，通常由服务器生成，用于客户端在后续请求中标识身份和权限。

特点：
- 存储在客户端（如浏览器 LocalStorage 或移动端本地存储）。
- 用途：无状态身份验证（如 API 调用）。
- 安全性：需通过 HTTPS 传输防止窃听；若使用 JWT 格式，需签名防篡改。
- 无状态性：服务器不存储 Token，仅通过签名验证有效性。
工作流程：
1. 用户登录后，服务器生成 Token 并返回给客户端。
2. 客户端后续请求在 Authorization 头中携带 Token（如 Bearer <token>）。
3. 服务器验证 Token 有效性后处理请求。

Token的无状态是什么意思？

在网络通信和系统设计中，Token的“无状态”（Stateless）是指在使用Token进行身份验证和授权时，服务器不需要在本地存储或维护客户端的会话状态信息。简单来说，每个Token本身包含了所有必要的信息，服务器只需要验证Token的有效性，就能识别用户的身份和权限，而无需依赖额外的存储或之前的请求记录。

2.JWT（JSON Web Token）

是目前最流行的跨域认证解决方案。

JWT 本质上就是一组字符串，通过（.）切分成三个为 Base64 编码的部分

Header（头部） : 描述 JWT 的元数据，定义了生成签名的算法以及 Token 的类型

Payload（载荷） : 用来存放实际需要传递的数据

Signature（签名）：服务器通过 Payload、Header 和一个密钥(Secret)使用 Header 里面指定的签名算法（默认是 HMAC SHA256）生成。

Header 和 Payload 都是 JSON 格式的数据，Signature 由 Payload、Header 和 Secret(密钥)通过特定的计算公式和加密算法得到。

Signature 部分是对前两部分的签名，作用是防止 JWT（主要是 payload）被篡改

这个签名的生成需要用到：

Header + Payload。
存放在服务端的密钥(一定不要泄露出去)。
加密算法。

算出签名以后，把 Header、Payload、Signature 三个部分拼成一个字符串，每个部分之间用”点”（.）分隔，这个字符串就是 JWT

如何基于JWT进行身份验证？

在基于JWT 进行身份验证的的应用程序中，服务器通过 Payload、Header和 Secret(密钥)创建 JWT 并将JWT 发送给客户端。客户端接收到JWT之后，会将其保存在 Cookie 或者localStorage 里面，以后客户端发出的所有请求都会携带这个令牌。

建议将 JWT 存放在 localStorage 中，放在 Cookie 中会有 CSRF 风险。

如何防止JWT被篡改

有了签名之后，即使 JWT 被泄露或者截获，黑客也没办法同时篡改 Signature、Header、Payload。

这是为什么呢？因为服务端拿到 JWT 之后，会解析出其中包含的 Header、Payload 以及 Signature 。服务端会根据 Header、Payload、密钥再次生成一个 Signature。拿新生成的 Signature 和 JWT 中的 Signature 作对比，如果一样就说明 Header 和 Payload 没有被修改。

不过，如果服务端的秘钥也被泄露的话，黑客就可以同时篡改 Signature、Header、Payload 了。黑客直接修改了 Header 和 Payload 之后，再重新生成一个 Signature 就可以了。

密钥一定保管好，一定不要泄露出去。JWT 安全的核心在于签名，签名安全的核心在密钥。

13.HTTP为什么不安全

HTTP 由于是明文传输，所以安全上存在以下三个风险:

窃听风险，比如通信链路上可以获取通信内容，用户号容易没。
篡改风险，比如强制植入垃圾广告，视觉污染，用户眼容易瞎。
冒充风险，比如冒充淘宝网站，用户钱容易没。

HTTPS 在 HTTP 与 TCP 层之间加入了 SSL/TLS 协议，可以很好的解决了上述的风险:

信息加密:交互信息无法被窃取，但你的号会因为「自身忘记」账号而没。
校验机制:无法篡改通信内容，篡改了就不能正常显示，但百度「竞价排名」依然可以搜索垃圾广告。
身份证书:证明淘宝是真的淘宝网，但你的钱还是会因为「剁手」而没。

14.HTTPS建立连接的过程

前置知识

加密/解密

如果用的是同一套规则，就是对称加密，否则就是非对称加密

非对称的加密规则叫公钥，解密规则叫私钥

通过公钥加密后的数据，可以通过私钥进行解密，反之亦然

接下来看看HTTPS的连接过程（主要是TLS/SSL四次握手）

TCP连接
TLS/SLL四次握手连接
1. 第一次握手：客户端告诉服务端TLS版本以及加密算法和客户端随机数
2. 第二次握手：服务端确认使用的TLS版本以及加密算法，以及给客户端一个服务端随机数和服务器证书
3. 第三次握手：客户端首先会验证数字证书的真实性，如果没有问题，客户端从服务器证书中取出服务器公钥，生成一个随机数（pre-master key），用服务器公钥加密后发送给服务端，然后用此时这边的三个随机数（客户端随机数，服务端随机数，pre-master-key）生成一个会话密钥，然后把迄今为止的通信数据生成一个摘要，也叫finished报文，用会话密钥加密后发送给服务端，供服务端校验
4. 第四次握手：服务端对客户端发送过来的随机数pre-master-key解密（用的是服务器私钥），然后用这边的三个随机数生成一个会话密钥，同样生成一个finished报文，发送给客户端做校验
加密通信

接下来，客户端与服务器就会用这个生成的会话密钥做加密通信

HTTPS是对称加密还是非对称加密？

都用到了，四次握手本质是利用了非对称加密的特点来生成会话密钥，后面就是利用会话密钥来进行对称加密的加密通信

为什么不都用非对称加密呢？

非对称加密慢

第二次握手中的服务器证书是什么？怎么从里面取出公钥？

服务器证书是被CA(证书权威机构) 的私钥对服务器公钥加密后的东西，即CA私钥+服务器公钥——>服务器证书

所以可以用CA公钥对服务器证书解密——>服务器公钥

为什么不能直接传公钥？还要拿CA私钥加密后再传过去

直接传公钥的话如果被黑客替换成自己的公钥，那客户端拿着假公钥加密pre-master-key，黑客经过解密就可以得到这个pre-master-key，又因为另外两个随机数是明文，就可以计算出会话密钥，然后就可以破解通信内容了

15.HTTP和RPC的区别

16.HTTP建立连接的过程

服务器在 80 端口等待客户的请求。

浏览器发起到服务器的 TCP 连接（创建套接字 Socket）。

服务器接收来自浏览器的 TCP 连接。

浏览器（HTTP 客户端）与 Web 服务器（HTTP 服务器）交换 HTTP 消息。

关闭 TCP 连接。

17.HTTPS中间人攻击以及如何防范

攻击原理

在HTTPS通信中，客户端通过服务器提供的数字证书来验证服务器的身份。证书由受信任的证书颁发机构（CA）签发，客户端会检查证书的有效性以确保通信安全。然而，在中间人攻击中，攻击者会伪造证书，冒充服务器与客户端通信。具体步骤如下：

拦截通信：攻击者拦截客户端发往服务器的请求。
伪装身份：攻击者伪装成服务器与客户端建立连接，同时与真正的服务器建立连接，充当中间人的角色。
伪造证书：攻击者向客户端提供一个伪造的证书，使客户端误以为与真正的服务器建立了安全连接。
窃听或篡改：攻击者可以窃听客户端和服务器之间的通信内容，甚至篡改数据。

防范

加密：https 握手期间会通过非对称加密的方式来协商出对称加密密钥。
身份校验：客户端会验证证书的合法性，包括检查证书的有效期、颁发机构的信任等。

18.HTTP和RPC的区别

HTTP（HyperText Transfer Protocol）

是一种用于传输超文本的 应用层协议，最初设计目的是在 Web 浏览器和服务器之间传输 HTML 页面。
设计目标是提供一种通用的、标准化的请求-响应通信方式，广泛用于 Web 服务、API 和客户端-服务器通信。
强调通用性、跨平台性和易用性。

RPC（Remote Procedure Call）

是一种 进程间通信机制，用于让程序像调用本地函数一样调用远程服务。
设计目标是屏蔽底层网络通信的复杂性，提供透明的远程调用体验，强调性能和效率。
更专注于系统间的直接通信，常用于分布式系统和服务间调用。

二、DNS

1、作用

DNS（Domain Name System）域名管理系统，是当用户使用浏览器访问网址之后，使用的第一个重要协议。DNS 要解决的是域名和 IP 地址的映射问题。 DNS扮演着重要的角色，使得人们可以通过易记的域名访问互联网资源，而无需记住复杂的IP地址。

在一台电脑上，可能存在浏览器 DNS 缓存，操作系统 DNS 缓存，路由器 DNS 缓存。如果以上缓存都查询不到，那么 DNS 就闪亮登场了。

2、域名解析的流程

客户端先访问本地DNS服务器（假如网址是www.server.com
没找到就（由本地DNS服务器）访问根DNS服务器（.），根DNS返回给本地DNS服务器要找的网址的顶级域DNS服务器（com)
（本地DNS服务器）访问顶级域服务器（com），顶级域服务器返回给本地DNS服务器要找的网址的权威DNS服务器（server.com）
（本地DNS服务器）访问权威DNS服务器（server.com），权威DNS服务器返回给本地DNS服务器要找IP地址

是不是每次解析域名都要经过那么多的步骤呢？（了解，反正就是知道会先看缓存有没有就行

浏览器会先看自身有没有对这个域名的缓存，如果有，就直接返回，如果没有，就去问操作系统，操作系统也会去看自己的缓存，如果有，就直接返回，如果没有，再去 hosts 文件看，也没有，才会去问「本地DNS 服务器」。

3.DNS劫持了解吗

DNS 劫持是一种网络攻击，它通过修改 DNS 服务器的解析结果，使用户访问的域名指向错误的 IP 地址，从而导致用户无法访问正常的网站，或者被引导到恶意的网站。DNS 劫持有时也被称为 DNS 重定向、DNS 欺骗或 DNS 污染。

三、WebSocket

1.什么是WebSocket

WebSocket 是一种基于 TCP 连接的全双工通信协议，即客户端和服务器可以同时发送和接收数据。

WebSocket 协议本质上是应用层的协议，用于弥补 HTTP 协议在持久通信能力上的不足。客户端和服务器仅需一次握手，两者之间就直接可以创建持久性的连接，并进行双向数据传输。

这意味着连接是持久的，它一直保持打开，直到有一方主动关闭连接。这使得WebSocket 非常适合用于实时应用程序，因为它不需要不断地建立和关闭连接。

WebSocket 的常见应用场景：

视频弹幕
实时消息推送
实时游戏对战
多用户协同编辑
社交聊天
。。。

2.为什么有了HTTP还需要WebSocket？

或者说：WebSocket和HTTP有什么区别？

HTTP是基于TCP协议的，同一时间里，客户端和服务器只能有一方主动发数据，是半双工通信。

通常，打开某个网页，我们每点击一次网页上的某个选项前端就会发送一次HTTP请求，网站返回一次HTTP响应。这种由客户端主动请求，服务器响应的方式满足大部分网页的功能场景。但这种情况下，服务器不会主动给客户端发消息。而类似网页游戏这样的场景，是需要客户端和服务器之间互相主动发大量数据的。因此，我们需要一个基于TCP的新协议，即新的应用层协议WebSocket.

3.WebSocket的工作过程

WebSocket 连接通常在客户端(例如浏览器)和服务器之间建立。客户端发送一个 HTTP 请求来建立连接，然后服务器返回一个确认消息，表示已建立连接。之后，客户端和服务器可以通过这个连接进行双向通信。客户端可以向服务器发送消息，服务器也可以向客户端发送消息。

客户端或服务器可以主动发送一个关闭帧，表示要断开连接。另一方收到后，也会回复一个关闭帧，然后双方关闭 TCP 连接。

四、TCP与UDP

TCP 是面向连接的、可靠的、基于字节流的传输层通信协议。

1.TCP报文的头部字段

一个 TCP 报文段主要由报文段头部（Header）和数据两部分组成。

源/目的端口号：用于表示发送端和接收端
序列号：用于标识从 TCP 发送者发送的数据字节流中的第一个字节的顺序号。通过 SYN 包传给接收端
确认号：指下一次「期望」收到的数据的序列号，发送端收到这个确认应答以后可以认为在这个序号以前的数据都已经被正常接收。用来解决丢包的问题。**
校验和：用于检测报文段在传输过程中的变化。
窗口大小：用于流量控制
控制位：

常见的有
1. ACK：确认字段是否有效
2. SYN：同步序号，用于建立连接
3. FIN：结束发送数据

2.TCP和UDP的区别

连接：TCP 是面向连接的传输层协议，传输数据前先要建立连接；UDP 是不需要连接，即刻传输数据。
服务对象：TCP 是一对一的两点服务，即一条连接只有两个端点。 UDP 支持一对一、一对多、多对多的交互通信
可靠性：TCP 是可靠交付数据的，数据可以无差错、不丢失、不重复、按序到达。 UDP 是尽最大努力交付，不保证可靠交付数据。但是我们可以基于 UDP 传输协议实现一个可靠的传输协议，比如 QUIC 协议
首部开销：TCP 首部开销（20 ～ 60 字节）比 UDP 首部开销（8 字节）要大。
传输方式：TCP 面向字节流传输，没有边界，但保证顺序和可靠。 UDP 是一个包一个包的发送，是有边界的，但可能会丢包和乱序。

3.什么时候选择TCP，什么时候选择UDP？

UDP 一般用于即时通信，比如：语音、视频、直播等等。这些场景对传输数据的准确性要求不是特别高，比如你看视频即使少个一两帧，实际给人的感觉区别也不大。
TCP 用于对传输准确性要求特别高的场景，比如文件传输、发送和接收邮件、远程登录等等

4.TCP三次握手

第一次握手（SYN）：客户端通知服务器它希望建立连接，并告知服务器自己的初始序列号。

客户端发送一个 SYN 报文（SYN=1），并携带客户端的初始序列号 seq=x，表示请求建立连接。然后客户端进入SYN_SEND状态
目的：客户端告知服务器“我想建立连接，我的初始序列号是 x”。
第二次握手（SYN-ACK）：服务器告诉客户端，它的连接请求被接受了，并通知客户端自己的初始序列号。

服务器收到 SYN 后，回复一个 SYN-ACK 报文（SYN=1, ACK=1），携带服务器的初始序列号 seq=y，以及对客户端 SYN 的确认号 ack=x+1。然后服务端进入SYN_RCVD状态
目的：服务器告知客户端“我收到了你的请求，同意建立连接，我的初始序列号是 y”。
第三次握手（ACK）：客户端进入 ESTABLISHED 状态，当服务器接收到这个包时，也进入 ESTABLISHED 状态

客户端收到 SYN-ACK 后，回复一个 ACK 报文（ACK=1），确认号为 ack=y+1。
目的：客户端告知服务器“我收到了你的确认，连接已建立”。然后客户端进入ESTABLISHED状态

第三次握手是可以携带数据的（如果携带数据就消耗一个序号，不携带的话就不消耗），前两次握手是不可以携带数据的

5.TCP全连接和半连接

半连接队列（SYN队列），服务端收到第一次握手后，会将socket加入到这个队列中，队列内的socket都处于SYN_RECV 状态。
全连接队列（ACCEPT队列），在服务端收到第三次握手后，会将半连接队列的socket取出，放到全连接队列中。队列里的socket都处于 ESTABLISHED状态。这里面的连接，就等着服务端执行accept()后被取出了。

虽然都叫队列，但其实全连接队列（icsk_accept_queue）是个链表，而半连接队列（syn_table）是个哈希表。

为什么半连接要设置为哈希表呢？

先对比下全连接队列，他本质是个链表，因为也是线性结构，说它是个队列也没毛病。它里面放的都是已经建立完成的连接，这些连接正等待被取走。而服务端取走连接的过程中，并不关心具体是哪个连接只要是个连接就行，所以直接从队列头取就行了。这个过程算法复杂度为0(1)。
而半连接队列却不太一样，因为队列里的都是不完整的连接，嗷嗷等待着第三次握手的到来。那么现在有个第三次握手来了，则需要从队列里把相应IP端口的连接取出，如果半连接队列还是个链表，那我们就需要依次遍历，才能拿到我们想要的那个连接，算法复杂度就是O(n)。
而如果将半连接队列设计成哈希表，那么查找半连接的算法复杂度就回到 0(1)了。
因此出于效率考虑，全连接队列被设计成链表，而半连接队列被设计为哈希表。

6.TCP连接为什么三次握手，而不是两次或四次

TCP 采用三次握手建立连接的核心目的是确保通信双方都能可靠地确认彼此的发送和接收能力，并同步初始序列号，从而为后续的可靠数据传输奠定基础。

(1) 防止旧的重复连接初始化（核心原因）

假设网络中存在延迟的旧 SYN 报文（例如客户端多次重试后建立的连接）：

两次握手的缺陷：
如果只有两次握手（客户端发 SYN，服务器回复 SYN-ACK），服务器在收到 SYN 后直接建立连接。若旧的 SYN 报文延迟到达服务器，服务器会误认为这是一个新连接并分配资源，导致资源浪费。
三次握手的解决：
客户端在收到服务器的 SYN-ACK 后，会检查确认号 ack 是否匹配自己的初始序列号。若不匹配（例如旧连接的 SYN 被服务器响应），客户端会发送 RST 报文终止连接，避免无效连接占用资源。

(2) 确保双方收发能力正常

第一次握手：客户端发送 SYN → 验证客户端的发送能力。
第二次握手：服务器发送 SYN-ACK → 验证服务器的发送能力和客户端的接收能力。
第三次握手：客户端发送 ACK → 验证客户端的发送能力和服务器的接收能力。
只有三次握手能双向确认双方的收发能力。

(3) 同步初始序列号（ISN）

TCP 依赖序列号实现可靠传输。三次握手确保双方交换并确认了初始序列号：

客户端通过 SYN 发送 seq=x，服务器通过 ACK 确认 x+1。
服务器通过 SYN 发送 seq=y，客户端通过 ACK 确认 y+1。
若只有两次握手，服务器无法确认客户端是否已正确接收自己的序列号。

3. 两次或四次握手的问题

两次握手：
无法解决旧 SYN 报文的重复连接问题，且服务器无法确认客户端的接收能力。
四次握手：
在三次握手的基础上，若增加第四次确认（例如服务器再回复一个 ACK），会导致冗余，三次已足够可靠。

7.TCP四次挥手

假设客户端主动发起关闭连接：

第一次挥手（FIN）：
客户端发送 FIN 报文（FIN=1），序列号为 seq=u，表示客户端不再发送数据，但仍可接收数据。客户端进入FIN-WAIT-1状态
第二次挥手（ACK）：
服务器收到 FIN 后，回复 ACK 报文（ACK=1），确认号为 ack=u+1，表示已收到客户端的关闭请求。此时服务器可能还有未发送完的数据。服务端进入CLOSE-WAIT状态，客户端进入FIN-WAIT-2状态
第三次挥手（FIN）：
服务器完成数据发送后，发送自己的 FIN 报文（FIN=1），序列号为 seq=v，表示服务器也准备关闭连接。服务端进入LAST-ACK状态
第四次挥手（ACK）：
客户端收到服务器的 FIN 后，回复 ACK 报文（ACK=1），确认号为 ack=v+1。客户端进入TIME-WAIT状态，也就是还要再等2MSL才能进入关闭状态。而服务器收到此 ACK 后，连接正式关闭，进入关闭状态

8.为什么要四次挥手？

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

举个例子：A 和 B 打电话，通话即将结束后。

第一次挥手：A 说“我没啥要说的了”
第二次挥手：B 回答“我知道了”，但是 B 可能还会有要说的话，A 不能要求 B 跟着自己的节奏结束通话
第三次挥手：于是 B 可能又巴拉巴拉说了一通，最后 B 说“我说完了”
第四次挥手：A 回答“知道了”，这样通话才算结束。

确保数据完全传输

第二次挥手的 ACK：服务器收到客户端的 FIN 后，先确认收到请求，但可能仍有数据需要发送。
第三次挥手的 FIN：服务器发送完剩余数据后，才通知客户端自己也要关闭。
若合并第二次和第三次挥手（即服务器直接回复 FIN+ACK），可能因数据未发送完导致数据丢失。

为什么四次挥手之后要等2MSL?

若第四次挥手的ACK丢失，服务器没有收到断开连接的最后的 ACK 报文，就会触发超时重发 FIN 报文，而客户端进入了关闭状态，就会导致服务器无法进入关闭状态

另一个，在 TIME_WAIT 持续的 2MSL 时间后，确保旧数据包完全消失，避免它们干扰未来建立的新连接。

9.如果TIME_WAIT状态过多，会有什么问题？如何解决？

第⼀是内存资源占⽤；

每个TIME_WAIT连接会占用一个四元组（源IP、源端口、目标IP、目标端口），导致端口和内存资源被占用。

第⼆是对端⼝资源的占⽤，⼀个 TCP 连接⾄少消耗⼀个本地端⼝；

如果客户端使用固定端口（如HTTP短连接频繁启闭），可能导致端口耗尽（Cannot assign requested address错误）。

解决方案：长连接替代短连接

使用HTTP/1.1的Keep-Alive或数据库连接池，减少连接频繁创建/销毁。

9.TCP为什么可靠传输？

连接管理：即三次握手和四次挥手。连接管理机制能够建立起可靠的连接，这是保证传输可靠性的前提。
序列号/确认应答：TCP 将数据分成多个小段，每段数据都有唯一的序列号。既能防止数据丢失，又能避免数据重复。同时，接收方接收到发送方的数据，会回复一个ACK来确认收到了
校验和：TCP 报文段包括一个校验和字段，用于检测报文段在传输过程中的变化。如果接收方检测到校验和错误，就会丢弃这个报文段。
重传机制 :发生超时或者收到重复ACK会触发重新传送。
流量控制：接收端处理数据的速度是有限的，如果发送方发送数据的速度过快，就会导致接收端的缓冲区溢出，进而导致丢包。为了避免上述情况的发生，TCP支持根据接收端的处理能力，来决定发送端的发送速度。这就是流量控制。流量控制是通过在TCP报文段首部维护一个滑动窗口来实现的。
拥塞控制：TCP 会采用慢启动的策略，一开始发的少，然后逐步增加，当检测到网络拥塞时，会降低发送速率。在网络拥塞缓解后，传输速率也会自动恢复。

这里补充一下超时重传

当发送端发送一个数据包后，如果在一定时间内没有收到接收端的确认（ACK），发送端会认为这个数据包可能丢失了，于是会重新发送这个数据包。这就是“超时重传”。

每次发送一个数据段，发送端都会启动一个定时器，叫做 RTO（Retransmission Timeout，重传超时时间）。如果在 RTO 时间内没有收到 ACK，发送端就认为数据包可能丢失了，会触发重传。

RTT：从发送数据包到收到 ACK 的时间。

10.滑动窗口

本来TCP是只能等到上次请求得到确认，才能继续发下次请求的，但这样通信效率低呀！

所以引入了窗口的概念，啥意思呢，就是这个窗口内可以连续发多条请求，而不必等一个请求得到应答了再发下一条，这样就极大提高了效率。而且有一个好处，那就是累计确认

比如图中ACK600这条确认丢失了，没事呀，我ACK700都接收到了，就代表之前的我都收到了！

窗口大小由哪一方决定？

当然是接收方啦

发送方的滑动窗口示意图

分成四个部分：

已发送并收到ACK确认
已发送但未收到ACK确认
未发送但总大小在接收方处理范围内，也就是还可用的窗口
未发送但总大小超过接收方处理范围内

程序可以通过三个指针来表示各个部分

SND.WND：表示发送窗口的大小
SND.UNA ：是一个绝对指针，它指向的是已发送但未收到确认的第一个字节的序列号
SND.NXT：也是一个绝对指针，它指向未发送但可发送范围的第一个字节的序列号

可用窗口大小 = SND.WND -（SND.NXT - SND.UNA） 也就是总窗口 - 已用窗口

接收方的窗口示意

分成三个部分：

已接收并确认的数据
未收到但可以接收的数据
未收到并且不可以接收的数据

11.流量控制

TCP 利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率，保证接收方来得及接收。 接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为 0，则发送方不能发送数据。

为什么需要流量控制? 这是因为双方在通信的时候，发送方的速率与接收方的速率是不一定相等，如果发送方的发送速率太快，会导致接收方处理不过来。如果接收方处理不过来的话，就只能把处理不过来的数据存在 接收缓冲区(Receiving Buffers) 里（失序的数据包也会被存放在缓存区里）。如果缓存区满了发送方还在狂发数据的话，接收方只能把收到的数据包丢掉。出现丢包问题的同时又疯狂浪费着珍贵的网络资源。因此，我们需要控制发送方的发送速率，让接收方与发送方处于一种动态平衡才好。

这里需要注意的是（常见误区）：

发送端不等同于客户端
接收端不等同于服务端

TCP 为全双工(Full-Duplex, FDX)通信，双方可以进行双向通信，客户端和服务端既可能是发送端又可能是服务端。因此，两端各有一个发送缓冲区与接收缓冲区，两端都各自维护一个发送窗口和一个接收窗口。接收窗口大小取决于应用、系统、硬件的限制（TCP 传输速率不能大于应用的数据处理速率）。通信双方的发送窗口和接收窗口的要求相同

12.拥塞控制

TCP拥塞控制是为了防止网络中的拥塞，确保数据在网络中可靠传输。它的目标是动态地调整数据发送速度，以适应网络的状况。

为了进行拥塞控制，TCP 发送方要维持一个 拥塞窗口(cwnd) 的状态变量。拥塞控制窗口的大小取决于网络的拥塞程度，并且动态变化。发送方让自己的发送窗口取为拥塞窗口和接收方的接受窗口中较小的一个。

TCP 的拥塞控制采用了四种算法，即 慢开始、 拥塞避免、快重传 和 快恢复。

慢开始：慢开始算法的思路是当主机开始发送数据时，如果立即把大量数据字节注入到网络，那么可能会引起网络阻塞，因为现在还不知道网络的符合情况。经验表明，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是由小到大逐渐增大拥塞窗口数值。cwnd 初始值为 1，每经过一个传播轮次，cwnd加倍（指数增长）。
拥塞避免：当cwnd达到阈值（ssthresh）后，进入拥塞避免阶段。拥塞避免算法的思路是让拥塞窗口 cwnd 缓慢增大，即每经过一个往返时间 RTT 就把发送方的 cwnd 加 1.（线性增长）
拥塞发生：

当网络拥塞发生丢包时，会有两种情况：
- 超时重传
  
  阈值设置为cwnd的一半，cwnd重置为1，然后启动慢开始
- 快速重传
  
  如果发送方在连续收到3个相同的ACK时，认为发生了丢包，立即重传丢失的数据包，而不等待超时重传。此时进入快恢复
- 快恢复（Fast Recovery）：
  - 在丢包发生后，进入快恢复阶段，阈值不变，cwnd被调整为原来的一半，并进入拥塞避免阶段，而不是回到慢启动。

13.TCP粘包⭐

TCP粘包是指在TCP协议中，由于数据的发送和接收没有明确的边界，多个数据包在传输过程中可能会被合并成一个数据包。这种情况会导致接收端无法准确区分每个独立的消息，从而无法正确解析数据。

解决方法：

固定长度的消息：发送方将每个消息填充到固定的长度（例如，每个消息固定为100字节，不足的部分用特定字符填充）。接收方每次读取固定长度的数据即可分割消息。
特殊字符作为边界：在每个消息的末尾添加一个特殊的分隔符（例如，换行符\n或自定义字符）。接收方通过检测分隔符来分割消息。
消息头包含长度：在每个消息的头部添加一个字段（例如，4字节），用来指示该消息的长度。接收方先读取消息头的长度字段，然后根据这个长度读取后续的完整消息。

五、IP

1.IP协议的定义和作用

IP 协议（Internet Protocol）用于在计算机网络之间传输数据包，它定义了数据包的格式和处理规则，确保数据能够从一个设备传输到另一个设备，可能跨越多个中间网络设备（如路由器）。

①、寻址：每个连接到网络的设备都有一个唯一的 IP 地址。IP 协议使用这些地址来标识数据包的源地址和目的地址，确保数据包能够准确地传输到目标设备。

②、路由：IP 协议负责决定数据包在网络传输中的路径。比如说路由器使用路由表和 IP 地址信息来确定数据包的最佳传输路径。

③、分片和重组：当数据包过大无法在某个网络上传输时，IP 协议会将数据包分成更小的片段进行传输。接收端会根据头部信息将这些片段重新组装成完整的数据包。

2.域名和IP的关系？一个IP可以对应多个域名吗？

IP 地址在同一个网络中是惟一的，用来标识每一个网络上的设备，其相当于一个人的身份证号
域名在同一个网络中也是惟一的，就像是一个人的名字、绰号

假如你有多个不用的绰号，你的朋友可以用其中任何一个绰号叫你，但你的身份证号码却是惟一的。但同时你的绰号也可能和别人重复，假如你不在，有人叫你的绰号，其它人可能就答应了。

一个域名可以对应多个 IP，但这种情况 DNS 做负载均衡的，在用户访问过程中，一个域名只能对应一个 IP。

而一个 IP 却可以对应多个域名，是一对多的关系。

一个域名只能实际对应一个IP，一个IP可以对应多个域名

3.为什么既有IP地址又有MAC地址

MAC 地址和 IP 地址都有什么作用？

MAC 地址是数据链路层和物理层使用的地址，是写在网卡上的物理地址，用来定义网络设备的位置，不可变更。
IP 地址是网络层和以上各层使用的地址，是一种逻辑地址。IP 地址用来区别网络上的计算机。

类似物理地址（MAC）和逻辑地址（IP）的关系

为什么有了 MAC 地址还需要 IP 地址？

如果我们只使用 MAC 地址进行寻址的话，我们需要路由器记住每个 MAC 地址属于哪个子网，不然一次路由器收到数据包都要满世界寻找目的 MAC 地址。而我们知道 MAC 地址的长度为 48 位，也就是最多共有 2 的 48 次方个 MAC 地址，这就意味着每个路由器需要 256T 的内存，显然是不现实的。

和 MAC 地址不同，IP 地址是和地域相关的，在一个子网中的设备，我们给其分配的 IP 地址前缀都是一样的，这样路由器就能根据 IP 地址的前缀知道这个设备属于哪个子网，剩下的寻址就交给子网内部实现，从而大大减少了路由器所需要的内存。

简单说，就是MAC地址太长了，路由器存储起来占用内存；另一方面，一个子网内的IP地址具有相同的前缀，因此寻址起来只需要知道该IP地址在哪个子网，剩下的寻址就交给子网内部实现，可大大减少路由器所需内存

4.ARP协议

ARP（Address Resolution Protocol，地址解析协议）是网络通信中的一种协议，主要目的是将网络层的 IP 地址解析为链路层的 MAC 地址。

ARP 工作原理： 记住几个关键词：ARP 表、广播问询、单播响应。

ARP 协议工作时有一个大前提，那就是 ARP 表。

在一个局域网内，每个网络设备都自己维护了一个 ARP 表，ARP 表记录了某些其他网络设备的 IP 地址-MAC 地址映射关系，该映射关系以 <IP, MAC, TTL> 三元组的形式存储。其中，TTL 为该映射关系的生存周期，典型值为 20 分钟，超过该时间，该条目将被丢弃。

工作流程

①、ARP 请求

当主机 A 要发送数据给主机 B 时，首先会在自己的 ARP 表中查找主机 B 的 MAC 地址。

如果没有找到，主机 A 会向网络中广播一个 ARP 请求数据包，请求网络中的所有主机告诉它们的 MAC 地址；这个请求包含了请求设备和目标设备的 IP 和 MAC 地址。

②、ARP 应答

网络中的所有主机都会收到这个 ARP 请求，但只有主机 B 会回复 ARP 应答，告诉主机 A 自己的 MAC 地址。

并且主机 B 会将主机 A 的 IP 和 MAC 地址映射关系缓存到自己的 ARP 缓存中，以便下次通信时直接使用。

③、更新 ARP 缓存

主机 A 收到主机 B 的 ARP 应答后，也会将主机 B 的 IP 和 MAC 地址映射关系缓存到自己的 ARP 缓存中。

六、网络攻击

1.什么是DDOS攻击？怎么防范？

分布式拒绝服务（DDoS）攻击是通过大规模互联网流量淹没目标服务器或其周边基础设施，以破坏目标服务器、服务或网络正常流量的恶意行为。

DDoS 攻击是通过连接互联网的计算机网络进行的。这些网络由计算机和其他设备例如 IoT 设备）组成，它们感染了恶意软件，从而被攻击者远程控制。这些个体设备称为机器人（或僵尸），一组机器人则称为僵尸网络。

一旦建立了僵尸网络，攻击者就可通过向每个机器人发送远程指令来发动攻击。当僵尸网络将受害者的服务器或网络作为目标时，每个机器人会将请求发送到目标的 IP 地址，这可能导致服务器或网络不堪重负，从而造成对正常流量的拒绝服务。由于每个机器人都是合法的互联网设备，因而可能很难区分攻击流量与正常流量。

2.CSRF攻击

CSRF（跨站请求伪造）是一种攻击手段，攻击者通过诱导用户执行恶意操作，从而获取用户数据或执行恶意代码。CSRF攻击通常通过伪造一个合法的HTTP请求来实现，这个请求看起来是合法的，但实际上是为了执行一个攻击者控制的操作。

3.XSS攻击

XSS是跨站脚本攻击，攻击者通过在Web页面中插入恶意脚本代码，然后诱使用户访问该页面，从而使得恶意脚本在用户浏览器中执行，从而盗取用户信息、会话信息等敏感数据，甚至控制用户账户。