简述 TCP 连接的过程

TCP（Transmission Control Protocol）连接的过程可以概括为三个主要步骤：建立连接、数据传输和连接关闭。

1. 建立连接：

   • 客户端向服务器发起连接请求，发送一个带有 SYN（同步）标志的 TCP 报文段，其中包含客户端的初始序列号（ISN）。
   • 服务器接收到连接请求后，发送一个带有 SYN/ACK（同步/确认）标志的 TCP 报文段作为响应，其中包含确认号（ACK）和服务器的初始序列号。
   • 客户端接收到服务器的响应后，发送一个带有 ACK 标志的 TCP 报文段，确认服务器的确认号，完成连接建立。

2. 数据传输：

   • 在连接建立后，客户端和服务器可以通过 TCP 报文段进行数据的可靠传输。数据会被分割成适当的大小（根据 MSS，最大段大小），并封装在 TCP 报文段中发送。
   • 发送方将数据发送到接收方，并根据 TCP 的流量控制和拥塞控制机制来维护传输的可靠性和性能。

3. 连接关闭：

   • 当数据传输完成或任一一方决定关闭连接时，发送方发送一个带有 FIN（结束）标志的 TCP 报文段，表示数据传输结束。
   • 接收方收到 FIN 后，发送一个带有 ACK 标志的 TCP 报文段作为确认，并进入半关闭状态，即接收数据但不再发送数据。
   • 如果接收方也希望关闭连接，它可以发送一个带有 FIN 标志的 TCP 报文段，请求断开连接。
   • 发送方收到 FIN 后，发送一个带有 ACK 标志的 TCP 报文段作为确认，并进入时间等待状态（Time Wait）。在此状态下，发送方等待一段时间以确保接收方收到确认，并处理可能尚未到达的后续数据包。
   • 最终，发送方关闭连接，不再接收或发送数据，释放资源。

这是 TCP 连接的基本过程，它提供了可靠的、面向连接的数据传输。通过建立连接、传输数据和关闭连接的步骤，TCP 确保了数据的可靠性、完整性和顺序性，并提供了拥塞控制和流量控制等机制以优化网络性能。

介绍下 HTTPS 中间人攻击

HTTPS 中间人攻击（HTTPS Man-in-the-Middle Attack）是一种针对使用 HTTPS（HTTP Secure）协议进行通信的攻击方法。在正常的 HTTPS 通信中，通信双方之间建立了加密的隧道，确保数据的机密性和完整性。然而，中间人攻击利用了一个恶意的第三方介入通信过程，使其能够窃听、篡改或伪装通信内容。

下面是中间人攻击的基本过程：

1. 建立伪造的加密连接：攻击者在受害者与目标服务器之间插入自己的服务器或恶意设备。受害者的浏览器会与攻击者的服务器建立连接，而攻击者的服务器再与目标服务器建立另一个连接。

2. 伪装为目标服务器：攻击者的服务器伪装成目标服务器，向受害者发送伪造的数字证书。受害者的浏览器会相信这个伪造的证书，因为它看起来与目标服务器的证书一样。

3. 中间人窃听或篡改通信：一旦建立了伪造的加密连接，受害者的浏览器和目标服务器之间的通信将经过攻击者的服务器。攻击者可以窃听通信内容、篡改数据，甚至完全阻止通信。

中间人攻击对通信的影响包括但不限于以下几点：

• 窃听通信内容：攻击者可以获取受害者与目标服务器之间传输的敏感信息，如登录凭据、个人数据等。

• 篡改通信内容：攻击者可以修改通过通信传输的数据，如注入恶意代码、篡改网页内容等。

• 伪装身份：攻击者可以完全伪装成目标服务器，欺骗受害者输入敏感信息，如用户名、密码、信用卡信息等。

为了防止中间人攻击，可以采取以下措施：

• 使用受信任的证书：确保服务器使用由受信任的证书颁发机构（CA）签发的证书。浏览器会验证证书的合法性，如果检测到问题，会发出警告。

• 使用公钥固定（Public Key Pinning）：服务器可以发送公钥固定信息，要求浏览器只接受特定的公钥，防止中间人使用伪造的证书。

• 使用证书透明度（Certificate Transparency）：监控和记录所有发布的 SSL/TLS 证书，以便检测潜在的伪造证书。

• 安全的网络环境：确保网络环境的安全性，防止攻击者在受害者和目标服务器之间插入恶意设备或窃听网络流量。

• 注意警告和指示：用户应该注意浏览器发出的任何证书警告或安全指示，特别是在访问重要网站时，确保连接的安全性。

综上所述，中间人攻击是一种严重的安全威胁，可以破坏 HTTPS 通信的保密性和完整性。采取适当的安全措施和用户教育可以有助于减少中间人攻击的风险。

介绍下 http1.0、http1.1、http2.0 协议的区别？

HTTP（Hypertext Transfer Protocol）是一种用于在 Web 上进行通信的协议。HTTP 的不同版本有不同的特点和功能。下面是 HTTP 1.0、HTTP 1.1 和 HTTP 2.0 协议之间的主要区别：

1. HTTP 1.0：

   • 连接管理：每次请求/响应都需要建立和关闭一个单独的 TCP 连接，即短连接。这导致了较高的延迟和资源消耗。
   • 请求-响应模型：每个请求只能对应一个响应，请求和响应是一对一的关系。
   • 无状态协议：HTTP 1.0 协议本身不保持客户端和服务器之间的状态，每个请求都是独立的。
   • 缓存控制：缓存控制主要依赖于 HTTP 头中的Expires和Pragma字段，缺乏灵活性和精确性。

2. HTTP 1.1：

   • 持久连接：引入了持久连接（Keep-Alive），使得多个请求/响应可以通过同一个 TCP 连接传输，减少了连接建立和关闭的开销。
   • 请求管道化：允许客户端在收到之前的响应之前发送多个请求，减少了网络延迟。
   • 主机头（Host Header）：引入了Host头字段，使得一个服务器可以承载多个域名的网站。
   • 增强的缓存控制：引入了更多缓存控制机制，如ETag和Cache-Control，提供了更灵活和精确的缓存策略。

3. HTTP 2.0：

   • 二进制协议：HTTP 2.0 使用二进制格式传输数据，取代了 HTTP 1.x 中的文本格式，提供了更高效的解析和传输。
   • 多路复用：引入了多路复用技术，允许在同一个 TCP 连接上同时发送多个请求和响应，解决了 HTTP 1.x 中的队头阻塞问题，提高了并发性能。
   • 头部压缩：使用 HPACK 算法对 HTTP 头进行压缩，减少了头部的传输大小，节省了带宽。
   • 服务器推送：服务器可以主动将多个资源推送给客户端，减少了客户端请求的延迟。
   • 流量控制和优先级：引入了流量控制和优先级机制，可以对数据流进行优先级排序和控制，提高了性能和资源利用率。

总体而言，HTTP 1.1 相对于 HTTP 1.0 提供了更好的性能和功能，引入了持久连接和请求管道化等特性。而 HTTP 2.0 在 HTTP 1.1 的基础上进一步提升了性能，引入了二进制协议、多路复用和头部压缩等特性，以提供更高效的通信和更好的用户体验。

为什么 HTTP1.1 不能实现多路复用

HTTP 1.1 的设计并未考虑到多路复用（Multiplexing）的需求，主要原因如下：

1. 顺序传输：HTTP 1.1 使用顺序传输的方式，即在同一个 TCP 连接上，每个请求和响应按照顺序进行。每个请求必须等待前一个请求的响应返回后才能发送，这导致了队头阻塞（Head-of-Line Blocking）问题。一旦某个请求的响应出现延迟，后续的请求也会被阻塞，影响了并发性能。

2. 无法区分请求：在 HTTP 1.1 中，请求和响应之间没有明确的标识符或标签来区分它们。服务器只能依靠请求的顺序来确定相应的响应。这使得难以在同一连接上同时处理多个请求和响应。

3. 头部阻塞：HTTP 1.1 使用文本格式的头部信息（Header），每个请求和响应都需要发送完整的头部信息。由于头部信息相对较大，如果其中一个请求的头部很大，就会占用很多带宽，导致其他请求的传输被延迟。

综上所述，HTTP 1.1 的设计限制了多路复用的实现。为了解决这些问题，并提高性能，HTTP 2.0 引入了多路复用机制，使用二进制协议、帧和流的概念，允许在同一个 TCP 连接上同时传输多个请求和响应，解决了队头阻塞和头部阻塞问题，提高了并发性能和响应速度。

简单讲解一下 http2 的多路复用

HTTP/2 中的多路复用（Multiplexing）是指在单个 TCP 连接上同时发送多个 HTTP 请求和接收多个 HTTP 响应的能力。它解决了 HTTP/1.1 中的队头阻塞问题，并提高了性能和效率。

在 HTTP/2 中，通信的数据被分割成更小的二进制帧（Frames），每个帧都有一个唯一的标识符，称为 Stream ID。这些帧可以按照任意的顺序发送，然后在接收端重新组装成完整的请求和响应。

多路复用的工作原理如下：

1. 建立连接：客户端与服务器之间建立一个 TCP 连接。

2. 创建流：在这个 TCP 连接上，客户端和服务器可以同时创建多个流（Stream）。每个流都有唯一的 Stream ID。

3. 拆分帧：HTTP/2 将每个请求和响应拆分成更小的二进制帧。这些帧可以是请求头帧、请求体帧、响应头帧或响应体帧等。

4. 乱序发送：客户端可以按照任意顺序将这些帧发送到服务器端，而服务器也可以按照任意顺序将这些帧发送到客户端。

5. 重组帧：在接收端，帧根据各自的 Stream ID 被重新组装成完整的请求和响应。这意味着即使帧的顺序不同，它们仍然可以正确地重组成原始的 HTTP 消息。

通过使用多路复用，HTTP/2 带来了以下好处：

• 队头阻塞问题的解决：在 HTTP/1.1 中，如果一个请求被阻塞，后续的请求也会受到影响。而在 HTTP/2 中，多个请求可以并行地发送和处理，不会被单个请求的阻塞所影响，提高了并发性能。

• 减少连接数：HTTP/2 中的多路复用允许多个请求共享同一个 TCP 连接，减少了连接建立和关闭的开销，节省了网络资源。

• 更高的性能：多路复用允许服务器同时推送多个响应，客户端可以更快地获取所需的资源，提高了页面加载速度和用户体验。

总结而言，HTTP/2 的多路复用通过在单个 TCP 连接上同时发送多个请求和接收多个响应，解决了 HTTP/1.1 中的队头阻塞问题，提高了并发性能和网络效率。

谈谈你对 TCP 三次握手和四次挥手的理解

TCP（Transmission Control Protocol）是一种可靠的传输协议，用于在网络上建立可靠的连接并进行数据传输。TCP 的连接建立和断开过程涉及到三次握手（Three-Way Handshake）和四次挥手（Four-Way Handshake）。

三次握手（Three-Way Handshake）：

1. 第一次握手：客户端向服务器发送一个带有 SYN（同步）标志的 TCP 报文段，表示客户端请求建立连接。此时客户端进入 SYN_SENT 状态。

2. 第二次握手：服务器收到客户端的 SYN 报文段后，会发送一个带有 SYN/ACK（同步/确认）标志的 TCP 报文段作为响应。服务器同时为这个连接分配资源，并进入 SYN_RECEIVED 状态。

3. 第三次握手：客户端收到服务器的 SYN/ACK 报文段后，会发送一个带有 ACK（确认）标志的 TCP 报文段，表示客户端接受连接。服务器和客户端都进入已建立连接的 ESTABLISHED 状态，可以开始进行数据传输。

通过三次握手，客户端和服务器都确认了对方的能力和意愿，建立了双向的可靠连接。

四次挥手（Four-Way Handshake）：

1. 第一次挥手：当客户端要关闭连接时，发送一个带有 FIN（结束）标志的 TCP 报文段，表示客户端不再发送数据。客户端进入 FIN_WAIT_1 状态。

2. 第二次挥手：服务器收到客户端的 FIN 报文段后，发送一个带有 ACK 标志的报文段作为确认，表示已经收到客户端的关闭请求。服务器进入 CLOSE_WAIT 状态，客户端进入 FIN_WAIT_2 状态。

3. 第三次挥手：服务器确定自己已经完成所有数据的发送后，发送一个带有 FIN 标志的报文段，表示服务器也准备关闭连接。服务器进入 LAST_ACK 状态。

4. 第四次挥手：客户端收到服务器的 FIN 报文段后，发送一个带有 ACK 标志的报文段作为确认，表示客户端接受关闭请求。客户端进入 TIME_WAIT 状态，等待一段时间后彻底关闭连接，服务器也进入 CLOSED 状态。

通过四次挥手，客户端和服务器都确认了彼此的关闭意图，并完成了连接的断开。

关于挥手过程中的 TIME_WAIT 状态，它的作用是确保所有网络上的延迟报文都被接收和处理，以避免旧的连接请求在新的连接中被混淆。

总结而言，TCP 的三次握手和四次挥手确保了连接的可靠建立和断开，保证了数据的可靠传输。三次握手建立连接，四次挥手关闭连接，是 TCP 协议可靠性的基石。

详细说一下三次握手和四次挥手以及中间发送的信息

TCP 三次握手

TCP 三次握手就好比两个人在街上隔着 50 米看见了对方，但是因为雾霾等原因不能 100%确认，所以要通过招手的方式相互确定对方是否认识自己。

张三首先向李四招手(syn)，李四看到张三向自己招手后，向对方点了点头挤出了一个微笑(ack)。张三看到李四微笑后确认了李四成功辨认出了自己(进入estalished状态)。

但是李四还有点狐疑，向四周看了一看，有没有可能张三是在看别人呢，他也需要确认一下。所以李四也向张三招了招手(syn)，张三看到李四向自己招手后知道对方是在寻求自己的确认，于是也点了点头挤出了微笑(ack)，李四看到对方的微笑后确认了张三就是在向自己打招呼(进入established状态)。

于是两人加快步伐，走到了一起，相互拥抱。

我们看到这个过程中一共是四个动作，张三招手--李四点头微笑--李四招手--张三点头微笑。其中李四连续进行了 2 个动作，先是点头微笑(回复对方)，然后再次招手(寻求确认)，实际上可以将这两个动作合一，招手的同时点头和微笑(syn+ack)。于是四个动作就简化成了三个动作，张三招手--李四点头微笑并招手--张三点头微笑。这就是三次握手的本质，中间的一次动作是两个动作的合并。

我们看到有两个中间状态，syn_sent和syn_rcvd，这两个状态叫着「半打开」状态，就是向对方招手了，但是还没来得及看到对方的点头微笑。syn_sent是主动打开方的「半打开」状态，syn_rcvd是被动打开方的「半打开」状态。客户端是主动打开方，服务器是被动打开方。

• syn_sent: syn package has been sent
• syn_rcvd: syn package has been received

TCP 数据传输

TCP 数据传输就是两个人隔空对话，差了一点距离，所以需要对方反复确认听见了自己的话。

张三喊了一句话(data)，李四听见了之后要向张三回复自己听见了(ack)。

如果张三喊了一句，半天没听到李四回复，张三就认为自己的话被大风吹走了，李四没听见，所以需要重新喊话，这就是 tcp 重传。

也有可能是李四听到了张三的话，但是李四向张三的回复被大风吹走了，以至于张三没听见李四的回复。张三并不能判断究竟是自己的话被大风吹走了还是李四的回复被大风吹走了，张三也不用管，重传一下就是。

既然会重传，李四就有可能同一句话听见了两次，这就是「去重」。「重传」和「去重」工作操作系统的网络内核模块都已经帮我们处理好了，用户层是不用关心的。

张三可以向李四喊话，同样李四也可以向张三喊话，因为 tcp 链接是「双工的」，双方都可以主动发起数据传输。不过无论是哪方喊话，都需要收到对方的确认才能认为对方收到了自己的喊话。

张三可能是个高射炮，一说连说了八句话，这时候李四可以不用一句一句回复，而是连续听了这八句话之后，一起向对方回复说前面你说的八句话我都听见了，这就是批量 ack。但是张三也不能一次性说了太多话，李四的脑子短时间可能无法消化太多，两人之间需要有协商好的合适的发送和接受速率，这个就是「TCP 窗口大小」。

网络环境的数据交互同人类之间的对话还要复杂一些，它存在数据包乱序的现象。同一个来源发出来的不同数据包在「网际路由」上可能会走过不同的路径，最终达到同一个地方时，顺序就不一样了。操作系统的网络内核模块会负责对数据包进行排序，到用户层时顺序就已经完全一致了。

TCP 四次挥手

TCP 断开链接的过程和建立链接的过程比较类似，只不过中间的两部并不总是会合成一步走，所以它分成了 4 个动作，张三挥手(fin)——李四伤感地微笑(ack)——李四挥手(fin)——张三伤感地微笑(ack)。

之所以中间的两个动作没有合并，是因为 tcp 存在「半关闭」状态，也就是单向关闭。张三已经挥了手，可是人还没有走，只是不再说话，但是耳朵还是可以继续听，李四呢继续喊话。等待李四累了，也不再说话了，朝张三挥了挥手，张三伤感地微笑了一下，才彻底结束了。

上面有一个非常特殊的状态time_wait，它是主动关闭的一方在回复完对方的挥手后进入的一个长期状态，这个状态标准的持续时间是 4 分钟，4 分钟后才会进入到 closed 状态，释放套接字资源。不过在具体实现上这个时间是可以调整的。

它就好比主动分手方要承担的责任，是你提出的要分手，你得付出代价。这个后果就是持续 4 分钟的time_wait状态，不能释放套接字资源(端口)，就好比守寡期，这段时间内套接字资源(端口)不得回收利用。

它的作用是重传最后一个 ack 报文，确保对方可以收到。因为如果对方没有收到 ack 的话，会重传 fin 报文，处于 time_wait 状态的套接字会立即向对方重发 ack 报文。

同时在这段时间内，该链接在对话期间于网际路由上产生的残留报文(因为路径过于崎岖，数据报文走的时间太长，重传的报文都收到了，原始报文还在路上)传过来时，都会被立即丢弃掉。4 分钟的时间足以使得这些残留报文彻底消逝。不然当新的端口被重复利用时，这些残留报文可能会干扰新的链接。

4 分钟就是 2 个 MSL，每个 MSL 是 2 分钟。MSL 就是maximium segment lifetime——最长报文寿命。这个时间是由官方 RFC 协议规定的。至于为什么是 2 个 MSL 而不是 1 个 MSL，我还没有看到一个非常满意的解释。

四次挥手也并不总是四次挥手，中间的两个动作有时候是可以合并一起进行的，这个时候就成了三次挥手，主动关闭方就会从fin_wait_1状态直接进入到time_wait状态，跳过了fin_wait_2状态。

https://juejin.cn/post/6844903625513238541

介绍 HTTPS 握手过程

HTTPS（Hypertext Transfer Protocol Secure）是在 HTTP 的基础上加入了 SSL/TLS 协议进行加密和身份验证的安全通信协议。HTTPS 握手过程（Handshake Process）用于建立安全的 HTTPS 连接，确保通信的机密性和完整性。

以下是 HTTPS 握手过程的简要介绍：

1. 客户端发送协议支持列表：客户端向服务器发送一个加密连接请求，这个请求中包含了客户端支持的 SSL/TLS 协议版本和加密算法列表。

2. 服务器选择协议和证书：服务器从客户端提供的协议列表中选择一个最高版本的 SSL/TLS 协议，并从服务器配置的证书中选择一个合适的数字证书。

3. 服务器发送证书：服务器将选定的数字证书发送给客户端。这个证书包含了服务器的公钥以及其他相关信息。

4. 客户端验证证书：客户端接收到服务器发送的证书后，会验证证书的有效性。这包括检查数字签名、证书的有效期、证书颁发机构（CA）的信任等。如果验证失败，客户端会终止连接。

5. 客户端生成密钥：如果服务器的证书验证通过，客户端会生成一个用于后续通信的随机对称密钥，称为会话密钥（Session Key）。

6. 客户端加密密钥发送：客户端使用服务器的公钥对会话密钥进行加密，并将加密后的会话密钥发送给服务器。

7. 服务器解密密钥：服务器接收到客户端发送的加密会话密钥后，使用私钥对其进行解密，得到会话密钥。

8. 握手完成：客户端和服务器现在都拥有相同的会话密钥，用于后续的加密和解密通信。握手过程完成后，双方可以开始使用加密的 HTTPS 通信。

值得注意的是，上述握手过程是简化的描述，实际的握手过程可能还涉及到服务器的身份验证和客户端的安全策略协商等步骤。

通过 HTTPS 握手过程，客户端和服务器之间建立了安全的加密通道，保护了数据的机密性和完整性，防止信息被窃听或篡改。这使得 HTTPS 成为安全敏感数据传输的首选协议，如网上银行、电子商务等领域。

HTTPS 握手过程中，客户端如何验证证书的合法性

在 HTTPS 握手过程中，客户端通过以下步骤来验证服务器证书的合法性：

1. 证书链验证：客户端会检查服务器证书中的数字签名，并使用内置的根证书颁发机构（CA）证书列表或操作系统提供的信任锚点来验证证书的合法性。客户端会逐级验证证书链中的每个证书，确保每个证书都由下一个证书签名，并且最终被信任的根证书所签名。

2. 证书有效性检查：客户端会验证证书的有效期，确保证书在当前时间内是有效的。客户端还会检查证书中的主题和域名是否匹配，以确保证书是用于当前服务器的。

3. 证书吊销检查：客户端会检查证书是否被吊销（Revoked），即是否被证书颁发机构宣布为不可信任。客户端可以通过在线查询证书吊销列表（Certificate Revocation List，CRL）或使用在线证书状态协议（Online Certificate Status Protocol，OCSP）来获取最新的吊销状态。

4. 可信任根证书：客户端要验证服务器证书时，会使用本地存储的根证书或操作系统提供的信任锚点来验证证书的合法性。这些根证书是由受信任的证书颁发机构所签署的，并被广泛接受和信任。

如果在任何验证步骤中发现问题，比如证书链断裂、证书过期、证书主题与域名不匹配或证书被吊销等，客户端会中止握手过程，拒绝与服务器建立连接。

验证证书的合法性是为了确保客户端与服务器之间的通信是安全和可信的。通过验证证书，客户端可以确认服务器的身份和信任服务器发送的公钥，从而建立安全的通信通道。

Http 状态码 301 和 302 的应用场景分别是什么

HTTP 状态码 301 和 302 都属于重定向状态码，用于指示客户端需要采取进一步的操作来完成请求。

301 Moved Permanently（永久重定向）： 当服务器收到客户端的请求时，如果请求的资源已经永久地移动到了新的 URL 上，服务器会返回 301 状态码，并在响应头中包含一个 Location 字段，指向新的 URL。客户端在接收到 301 响应后，应该更新自己的 URL 引用，并使用新的 URL 发起新的请求。这意味着搜索引擎和浏览器会将旧的 URL 替换为新的 URL，之后的请求都将直接发送到新的 URL。

应用场景：

• 网站更换域名或 URL 结构：当网站需要更换域名或重构 URL 结构时，可以使用 301 重定向来告知搜索引擎和浏览器，之后的请求应该使用新的 URL。
• 重定向到首选域名：当网站有多个域名指向同一内容时，可以使用 301 重定向将所有流量引导到首选的域名上。

302 Found（临时重定向）： 当服务器收到客户端的请求时，如果请求的资源临时地移动到了新的 URL 上，服务器会返回 302 状态码，并在响应头中包含一个 Location 字段，指向新的 URL。客户端在接收到 302 响应后，应该继续使用原始的 URL 发起请求，并在请求中包含新的 URL。这意味着搜索引擎和浏览器会继续使用原始的 URL，并在之后的请求中包含新的 URL。

应用场景：

• 简单的 A/B 测试：在进行 A/B 测试时，可以使用 302 重定向将一部分用户随机分配到不同的页面版本上，以评估它们的效果。
• 临时性的网站维护：当网站需要进行临时性维护时，可以使用 302 重定向将用户引导到一个维护页面或其他临时页面。

需要注意的是，根据 HTTP 规范，客户端在接收到 301 和 302 响应后应该遵循重定向，并在之后的请求中使用新的 URL。但实际上，有些浏览器可能会对这两种状态码有不同的处理方式。因此，在使用 301 和 302 时，应该根据具体的需求和预期的效果来选择合适的状态码。

cookie 和 token 都存放在 header 中，为什么不会劫持 token？

虽然 Cookie 和 Token 都可以存放在 HTTP 请求的 Header 中，但它们在设计和用途上有一些区别，这导致了它们受到劫持的风险程度不同。

Cookie：

• Cookie 是服务器在 HTTP 响应中通过 Set-Cookie 头部字段发送给客户端的小型数据片段，存储在客户端的浏览器中。
• 浏览器会自动在每个符合条件的请求中通过 Cookie 头部字段将 Cookie 发送回服务器。
• Cookie 通常用于存储会话标识、用户首选项和其他与用户相关的信息。
• Cookie 在存储时可以设置为 HttpOnly 属性，这样浏览器会禁止 JavaScript 访问 Cookie，减少了被劫持的风险。

Token：

• Token 是一种用于认证和授权的令牌，通常由服务器颁发给客户端，并通过 Authorization 或其他自定义的头部字段发送回服务器。
• 客户端在每个请求中需要主动将 Token 包含在请求头中，以便服务器进行身份验证和授权。
• Token 通常用于无状态的身份验证和 API 访问控制。
• Token 的安全性取决于其生成和验证的机制，包括使用安全的算法进行签名和加密。

尽管 Token 也存储在请求头中，但相对于 Cookie，Token 的劫持风险较低的原因如下：

1. 不受同源策略限制：在浏览器中，Cookie 受到同源策略的限制，只能在与其所属域名相同的请求中自动发送。而 Token 不受同源策略限制，可以通过自定义的头部字段发送到任意目标服务器。

2. 不会自动发送：相比 Cookie，Token 不会被浏览器自动发送，需要显式地包含在请求头中。这意味着攻击者无法通过简单的跨站脚本（XSS）攻击获取到 Token。

3. 安全机制的支持：Token 的生成和验证过程通常采用安全的算法和机制，如使用密钥进行签名或加密，确保 Token 的完整性和安全性。

尽管 Token 具有一定的安全性，但仍然需要采取适当的安全措施来保护 Token 的安全性，如使用 HTTPS 协议传输，定期更新 Token，设置适当的过期时间，并实施其他安全控制措施来防止伪造和劫持攻击。

介绍下如何实现 token 加密

实现 Token 加密通常涉及以下步骤：

1. 选择加密算法：选择适合的加密算法和方案。常见的选择包括对称加密算法（如 AES）和非对称加密算法（如 RSA）。

2. 生成密钥：根据选择的加密算法，生成加密和解密所需的密钥。对称加密使用相同的密钥进行加密和解密，而非对称加密使用一对公钥和私钥。

3. 生成 Token：根据业务需求，生成包含必要信息的原始 Token。这些信息可以是用户 ID、角色、权限等。

4. 加密 Token：使用选择的加密算法和密钥，对生成的 Token 进行加密操作。具体实现方式取决于所选的加密算法和编程语言/框架。

5. 存储和传输：将加密后的 Token 存储在可信的位置，如服务器端的数据库或缓存中。在传输过程中，确保使用安全的通信协议（如 HTTPS）来保护加密后的 Token。

6. 解密 Token：在需要验证和解析 Token 的时候，通过相同的加密算法和密钥对加密的 Token 进行解密操作，还原为原始的 Token 数据。

7. 验证和使用 Token：对解密后的 Token 进行验证，确保其完整性和有效性。验证可以包括检查 Token 的签名、过期时间以及其他自定义的验证规则。一旦 Token 验证通过，可以使用其中包含的信息进行相应的身份验证、授权或其他业务逻辑。

需要注意的是，Token 加密只是保护 Token 在传输和存储过程中的安全性，但并不防止 Token 被伪造或盗用。为了增强 Token 的安全性，还可以采取以下措施：

• 签名和验证：使用数字签名机制对 Token 进行签名，确保 Token 的完整性和来源验证。验证过程可以防止伪造和篡改。

• 短期有效：设置 Token 的有效期，尽量保持较短的时间，减少被盗用的风险。可以定期刷新 Token，避免长期使用同一个 Token。

• 令牌刷新：为 Token 引入刷新机制，使得在一定时间内，客户端可以通过特定的请求来刷新 Token，延长其有效期。

• 使用 HTTPS：在传输 Token 的过程中，使用 HTTPS 协议加密通信，确保传输的安全性。

• 安全存储：在服务器端将 Token 存储在安全的位置，如加密的数据库或缓存中，防止未经授权的访问。

Token 加密是一个复杂的过程，具体实现方式会因所选的加密算法和编程语言/框架而有所不同。在实际应用中，建议借助可信的安全库或框架来实现 Token 的加密和解密操作，以确保安全性和可靠性。

说下单点登录

单点登录（Single Sign-On，简称 SSO）是一种身份验证和授权机制，允许用户只需一次登录即可访问多个关联的应用程序或系统，而无需再次提供凭据。

在传统的身份验证系统中，用户需要为每个应用程序或系统提供独立的用户名和密码进行登录。而在 SSO 系统中，用户只需进行一次身份验证，然后就可以无缝地访问其他关联的应用程序或系统，而不需要再次输入凭据。

以下是 SSO 的基本工作原理：

1. 认证中心（Identity Provider，简称 IdP）：SSO 系统的核心组件是认证中心，它负责管理用户的身份认证和授权过程。用户在访问应用程序之前首先与认证中心进行身份验证。

2. 会话和令牌：一旦用户通过认证中心进行身份验证，认证中心会创建一个会话，表示用户的身份已经验证成功。认证中心还会生成一个令牌（Token），包含用户的身份信息和其他必要的授权信息。

3. 应用程序的信任关系：在 SSO 系统中，应用程序需要与认证中心建立信任关系。这意味着应用程序信任认证中心的身份验证，并允许认证中心颁发的令牌用于访问。

4. 访问其他应用程序：一旦用户通过认证中心进行身份验证并获得令牌，用户可以访问与认证中心建立信任关系的其他应用程序。用户在访问这些应用程序时，会将令牌随请求一起发送给应用程序，应用程序可以验证令牌的有效性，并使用其中的用户信息进行身份验证和授权。

SSO 的优势包括：

• 用户便利性：用户只需进行一次登录，即可访问多个应用程序，简化了登录流程，提高用户体验。

• 减少密码管理负担：由于用户只需记住一个凭据，即认证中心的凭据，减少了需要记住和管理的密码数量。

• 统一的身份管理和控制：通过 SSO 系统，身份管理和控制可以集中在认证中心进行，从而简化了管理流程和提高安全性。

• 提高安全性：SSO 系统可以实施更强大的身份验证和授权机制，如多因素身份验证、单点注销等，提高了整体系统的安全性。

需要注意的是，SSO 的实现需要合适的协议和技术支持，如 SAML（Security Assertion Markup Language）、OAuth（Open Authorization）和 OpenID Connect 等。此外，应用程序需要与认证中心进行集成，并建立信任关系，以实现 SSO 的功能。

http1.1 是如何复用 tcp 连接的？

在 HTTP/1.1 中，复用 TCP 连接是通过持久连接（Persistent Connection）来实现的。HTTP/1.1 引入了持久连接的概念，使得在单个 TCP 连接上可以发送多个 HTTP 请求和响应，而无需为每个请求都建立新的 TCP 连接。

下面是 HTTP/1.1 复用 TCP 连接的基本工作原理：

1. 建立 TCP 连接：客户端通过 TCP 三次握手与服务器建立连接。

2. 发送 HTTP 请求：客户端发送 HTTP 请求给服务器，并在请求头中包含Connection: keep-alive字段，表示希望保持持久连接。

3. 接收 HTTP 响应：服务器接收到请求后，处理请求并发送 HTTP 响应给客户端。

4. 保持连接：在 HTTP 响应头中，服务器会包含Connection: keep-alive字段，表示同意保持持久连接。

5. 复用连接：客户端可以在当前 TCP 连接上发送另一个 HTTP 请求，而无需重新建立 TCP 连接。客户端发送新的请求时，保持连接的特性会被服务器识别并处理。

6. 重复步骤 2-5：客户端可以重复发送多个 HTTP 请求和接收响应，持久连接保持打开状态。

7. 关闭连接：当客户端或服务器决定关闭连接时，会在 HTTP 头部中使用Connection: close字段来指示关闭连接。

通过持久连接，HTTP/1.1 可以减少建立和关闭 TCP 连接的开销，提高请求的处理效率。然而，HTTP/1.1 的复用连接仍然存在一些限制，如队头阻塞（Head-of-Line Blocking）问题，即如果前面的请求阻塞或耗时较长，后续的请求也会被阻塞。为了解决这个问题，引入了 HTTP/2 协议，其中使用了二进制分帧（Binary Framing）和多路复用（Multiplexing）等技术来更高效地复用 TCP 连接。

文件上传如何做断点续传

实现文件上传的断点续传功能涉及以下几个步骤：

1. 切分文件：将待上传的文件切分成较小的块（Chunk）。通常，每个块的大小可以根据实际需求进行设置，例如 1MB 或更大。

2. 记录上传状态：在服务器端，为每个文件创建一个相关的上传状态记录。这个记录可以包含文件的元数据（如文件名、大小等）以及已成功上传的块的信息。

3. 上传块：客户端将切分的文件块逐个上传到服务器。每个块都包含一些元数据，如块的索引、总块数、块大小等，以便服务器能够正确地组合块并还原文件。

4. 保存块：服务器接收到上传的块后，将其保存在特定的位置。这可以是服务器上的临时目录或专门用于存储上传块的位置。

5. 验证块完整性：在上传块到服务器后，服务器可以对块的完整性进行校验，例如通过校验块的哈希值或使用校验和等方法。

6. 更新上传状态：在服务器成功保存块后，更新文件的上传状态记录，标记已成功上传的块，以便后续的断点续传。

7. 续传处理：如果上传过程中断或中止，下次继续上传时，客户端可以根据服务器返回的上传状态，确定哪些块已成功上传，然后从断点处继续上传未完成的块。

8. 合并块：当所有块都上传完成后，服务器端根据上传状态记录将这些块合并成完整的文件。合并可以通过将块按顺序连接起来或使用特定的合并算法来实现。

9. 清理临时数据：在文件上传完成后，服务器可以清理掉之前用于存储上传块的临时数据。

通过以上步骤，可以实现文件上传的断点续传功能。在实际实现中，还需要考虑错误处理、并发上传的处理、上传进度的显示等细节。

介绍 SSL 和 TLS

SSL（Secure Sockets Layer）和 TLS（Transport Layer Security）是用于保护网络通信安全的加密协议。它们提供了加密、身份验证和数据完整性验证等功能，用于确保客户端和服务器之间的通信在互联网上是安全的。

SSL 是最早用于保护网络通信的加密协议，而 TLS 是 SSL 的后续版本，目前广泛使用的是 TLS 1.2 和 TLS 1.3。TLS 基于 SSL 的设计思想，并进行了一些改进和增强。

下面是 SSL/TLS 的基本工作原理：

1. 握手协议：客户端发起与服务器的连接请求，然后进行握手协议。在握手过程中，客户端和服务器交换加密算法支持、生成临时密钥、验证身份等信息。

2. 协商加密参数：客户端和服务器通过握手协议协商确定使用的加密算法、密钥长度、哈希算法等参数，以确保安全通信。

3. 身份验证：服务器可以提供数字证书作为身份验证的凭据，客户端可以验证服务器的证书是否有效和可信。证书通常由受信任的证书颁发机构（Certificate Authority，CA）签发。

4. 密钥交换：客户端和服务器使用公开密钥加密算法进行密钥交换。这些算法包括 RSA、Diffie-Hellman 等，用于生成共享密钥，以便加密和解密通信数据。

5. 加密通信：一旦握手过程完成，客户端和服务器使用协商好的加密算法和密钥来加密和解密通信数据。这样，即使被截获的数据也无法被恶意方轻易解读。

6. 数据完整性验证：TLS 使用消息认证码（Message Authentication Code，MAC）来验证通信数据的完整性，以防止数据在传输过程中被篡改。

SSL/TLS 的使用可以确保通信的机密性、完整性和身份验证。它们广泛应用于 Web 浏览器和服务器之间的 HTTPS 通信，电子邮件传输（如 SMTP、POP3 和 IMAP）、虚拟私有网络（VPN）等场景，以保护敏感数据的安全。

说说网络的五层模型

网络的五层模型是指 OSI（Open Systems Interconnection）参考模型，它是一个将计算机网络通信划分为不同功能层的概念框架。每个层都具有特定的功能和责任，并通过接口与相邻层进行通信。以下是五层模型的各个层及其功能：

1. 物理层（Physical Layer）： 物理层是网络五层模型的最底层，它负责在物理媒介上传输原始比特流。它定义了电气、光学和机械特性，以及传输速率、连接器类型和传输距离等细节。物理层的例子包括以太网、光纤和无线电频谱等。

2. 数据链路层（Data Link Layer）： 数据链路层建立在物理层之上，负责在直连的节点之间传输帧（Frame）数据。它提供了一些功能，如物理地址（MAC 地址）的寻址、帧同步、流量控制和差错检测等。以太网、Wi-Fi 和 PPP（Point-to-Point Protocol）等协议工作在数据链路层。

3. 网络层（Network Layer）： 网络层负责在网络中传输分组（Packet）数据，并为分组选择合适的路径。它使用路由选择算法和协议，将数据从源主机路由到目标主机。IP（Internet Protocol）是网络层的核心协议，它负责逻辑寻址和路由功能。

4. 传输层（Transport Layer）： 传输层提供端到端的可靠数据传输服务。它将数据分割为较小的报文（Segment）并管理端口号、流量控制、数据完整性和可靠性等功能。传输层主要有两个主要协议：TCP（Transmission Control Protocol）和 UDP（User Datagram Protocol）。

5. 应用层（Application Layer）： 应用层是最高层，为用户提供网络应用服务，例如电子邮件、文件传输、Web 浏览等。它定义了应用协议，如 HTTP（Hypertext Transfer Protocol）、SMTP（Simple Mail Transfer Protocol）和 FTP（File Transfer Protocol）等。应用层数据经过下层的封装和分段后，最终通过物理层的传输实现网络通信。

这些层级的划分使得网络通信的功能得以模块化和分层化，使不同的网络设备和协议能够互相配合和交互操作。这样的模型使得网络设计、开发和故障排除更加简化和可靠。

GET 和 POST 的区别

GET 和 POST 是 HTTP 协议中的两种常见请求方法，它们在使用上有以下区别：

1. 语义上的区别：

   • GET：用于从服务器获取资源。GET 请求是一种幂等操作，它不应该对服务器产生任何副作用，即不会改变服务器的状态。
   • POST：用于向服务器提交数据，通常用于创建、更新或修改资源。POST 请求可能对服务器产生副作用，即可能改变服务器的状态。

2. 数据传输方式：

   • GET：通过 URL 参数将数据附加在请求的 URL 上，以?分隔 URL 和参数列表，并使用&分隔多个参数。例如：http://example.com/path?param1=value1&param2=value2。
   • POST：将数据包含在请求的消息体中，作为请求的一部分进行传输，不会在 URL 中暴露数据。

3. 数据长度限制：

   • GET：由于数据附加在 URL 上，对 URL 的长度有限制，不同浏览器和服务器对 URL 长度的限制可能有所不同。较长的 URL 可能会被截断或被服务器拒绝处理。
   • POST：数据作为消息体传输，对数据长度没有明确限制。但是，服务器和应用程序可能会有自己的数据大小限制。

4. 数据安全性：

   • GET：由于数据附加在 URL 上，敏感信息可能会被保存在浏览器的历史记录、服务器的日志文件中，甚至在网络传输过程中被拦截。因此，GET 请求不适合传输敏感数据。
   • POST：由于数据包含在请求的消息体中，不会直接暴露在 URL 中，相对于 GET 请求，POST 请求的数据相对更安全。

5. 缓存处理：

   • GET：GET 请求可以被浏览器缓存，以提高性能和减少网络请求。浏览器可以缓存响应结果，并在下次请求相同 URL 时直接使用缓存的数据（如果缓存有效）。
   • POST：POST 请求不会被浏览器缓存，每次请求都会向服务器发送请求。

综上所述，GET 适合用于获取资源，数据附加在 URL 上，对数据长度有限制，不适合传输敏感数据，可以被缓存。而 POST 适合用于提交数据，数据包含在请求的消息体中，对数据长度没有明确限制，适合传输敏感数据，不会被缓存。选择使用哪种请求方法应根据具体的业务需求和安全考虑来决定。

http 劫持是什么？

HTTP 劫持（HTTP hijacking），也称为 Session 劫持或 HTTP 会话劫持，是一种网络攻击技术，攻击者通过某种方式窃取或篡改正在进行的 HTTP 通信会话。攻击者可以获得用户的身份认证信息、会话令牌或敏感数据，从而冒充合法用户或执行未经授权的操作。

HTTP 劫持的常见形式包括以下几种：

1. 会话劫持： 攻击者截获用户的会话标识符（session ID），通常是通过窃取用户的 Cookie 信息或通过网络监听等手段获取。一旦攻击者获取到有效的会话标识符，他们可以在未经授权的情况下冒充用户，访问用户的账户、执行操作或篡改用户的数据。

2. 中间人攻击： 攻击者在用户与服务器之间插入自己的恶意代理，成为通信的中间人。通过这种方式，攻击者可以窃听、修改或重放通信数据，从而获取敏感信息或执行欺骗性操作。

3. DNS 劫持： 攻击者通过篡改 DNS（Domain Name System）响应，将用户请求的域名解析到恶意的 IP 地址。用户在访问原本合法的网站时，实际上被重定向到攻击者控制的恶意网站上，从而进行钓鱼攻击或窃取用户信息。

4. 网页篡改： 攻击者在传输过程中修改网页内容，通常是通过注入恶意脚本或修改 HTML 代码。这种攻击方式可以用于分发恶意软件、进行钓鱼攻击或欺骗用户执行恶意操作。

为了防止 HTTP 劫持攻击，可以采取以下措施：

• 使用 HTTPS：通过使用加密的 HTTPS 协议，可以保护通信的机密性和完整性，防止数据在传输过程中被窃听或篡改。
• 安全的会话管理：使用安全的会话管理机制，如使用加密的会话标识符、限制会话的有效时间、定期更换会话标识符等。
• 输入验证和过滤：对用户输入进行严格的验证和过滤，以防止恶意脚本注入或其他攻击方式。
• DNS 安全：使用可靠的 DNS 服务提供商，并监测和检测 DNS 劫持行为。
• 定期更新和修补：及时更新和修补服务器、框架和应用程序的安全漏洞，以减少攻击面。

综上所述，HTTP 劫持是一种攻击技术，攻击者通过窃取或篡改 HTTP 通信会话来获取用户的信息或执行未经授权的操作。保护通信的机密性、完整性和身份验证是防止 HTTP 劫持的重要措施。

HTTP 劫持、DNS 劫持与 XSS

HTTP 劫持、DNS 劫持和 XSS（跨站脚本）是三种不同的网络安全威胁，它们具有不同的工作原理和攻击方式：

1. HTTP 劫持：

   • 工作原理：攻击者截获用户的 HTTP 通信会话，篡改或窃取通信数据。
   • 攻击方式：常见的 HTTP 劫持包括会话劫持和中间人攻击。
   • 影响和防范措施：攻击者可以获取用户的身份认证信息、执行未经授权的操作等。使用 HTTPS 加密通信、安全的会话管理和输入验证等措施可以减少 HTTP 劫持的风险。

2. DNS 劫持：

   • 工作原理：攻击者篡改 DNS 响应，将用户请求的域名解析到恶意的 IP 地址。
   • 攻击方式：攻击者可以将用户重定向到恶意网站，进行钓鱼攻击或窃取用户信息。
   • 影响和防范措施：用户可能被引导到恶意网站，导致数据泄露或受到欺骗。使用可靠的 DNS 服务提供商，并监测和检测 DNS 劫持行为，可以降低风险。

3. XSS（跨站脚本）：

   • 工作原理：攻击者将恶意脚本注入到合法网站的页面中，当用户访问页面时，恶意脚本在用户浏览器中执行。
   • 攻击方式：XSS 攻击可以分为存储型、反射型和 DOM 型。攻击者可以窃取用户的会话标识、篡改页面内容或进行其他恶意操作。
   • 影响和防范措施：XSS 攻击威胁用户的隐私和数据安全。开发者应对用户输入进行严格的验证和过滤，确保用户提交的数据不会被解释为恶意脚本。使用内容安全策略（CSP）和输入输出过滤等措施可以减少 XSS 攻击的风险。

虽然 HTTP 劫持、DNS 劫持和 XSS 都属于网络安全威胁，但它们的攻击方式和目标略有不同。了解这些威胁并采取相应的安全措施可以帮助减少风险，并保护用户和网站的安全。

https 验证身份也就是 TSL/SSL 身份验证的过程

HTTPS 使用 TLS（Transport Layer Security）或 SSL（Secure Sockets Layer）协议来加密通信，确保通信的机密性和完整性。在 HTTPS 中，TLS/SSL 身份验证过程涉及以下步骤：

1. 客户端发起连接请求： 客户端（通常是 Web 浏览器）向服务器发送连接请求，请求建立 HTTPS 连接。

2. 服务器发送证书： 服务器将自己的数字证书发送给客户端。证书通常由受信任的第三方证书颁发机构（CA）签发，用于证明服务器的身份。

3. 客户端验证证书： 客户端收到服务器的证书后，会进行以下验证步骤：

   • 验证证书的有效性：客户端会检查证书的签名是否有效、证书是否在有效期内以及是否与访问的域名匹配。
   • 验证证书颁发机构：客户端会检查证书颁发机构是否可信，即证书是否由受信任的 CA 签发。

4. 客户端生成密钥： 如果服务器的证书通过了验证，客户端会生成一个用于对称加密的随机密钥，该密钥用于加密通信过程中的数据。

5. 客户端加密密钥并发送： 客户端使用服务器的公钥对生成的密钥进行加密，并将加密后的密钥发送给服务器。

6. 服务器解密密钥： 服务器使用自己的私钥对收到的加密密钥进行解密，从而获取用于对称加密的密钥。

7. 建立加密通信： 客户端和服务器都拥有相同的对称加密密钥，它们使用该密钥对后续的通信进行加密和解密，确保通信的机密性和完整性。

通过 TLS/SSL 身份验证过程，客户端可以验证服务器的身份，确保与合法服务器建立安全的加密通信。这种验证过程可以防止中间人攻击和伪造服务器的风险，保护用户的隐私和数据安全。

需要注意的是，TLS/SSL 身份验证只能验证服务器的身份，而不能直接验证客户端的身份。如果需要对客户端进行身份验证，可以使用客户端证书来实现双向身份验证，其中客户端也需要拥有有效的数字证书，并在连接建立时进行验证。

为什么需要 CA 机构对证书签名

CA（Certificate Authority）机构对证书进行签名的主要目的是确保证书的可信性和完整性。以下是为什么需要 CA 机构对证书进行签名的几个重要原因：

1. 建立信任链： CA 机构作为可信的第三方，通过签发证书对服务器的身份进行认证。客户端可以信任 CA 机构的签名，从而建立与服务器的信任链。通过这种方式，即使客户端没有直接与服务器进行过通信，仍然可以相信服务器的身份。

2. 验证证书的真实性： CA 机构对证书进行签名后，可以验证证书的真实性。签名是使用 CA 机构的私钥进行加密，只有具有对应 CA 机构公钥的客户端才能解密和验证签名。这样可以确保证书是由 CA 机构签发的，减少了被伪造的风险。

3. 防止篡改和中间人攻击： 证书签名可以防止证书的篡改和中间人攻击。如果没有 CA 机构的签名，攻击者可以自行签发证书并冒充服务器，欺骗客户端进行通信。通过 CA 机构的签名，客户端可以验证证书的完整性，如果证书被篡改，签名验证将失败，从而防止中间人攻击和数据篡改。

4. 保护用户隐私： 通过使用由可信的 CA 机构签发的证书，客户端可以确保与服务器之间的通信是加密的。这有助于保护用户的隐私和数据安全，防止敏感信息在传输过程中被窃听或窃取。

总而言之，CA 机构对证书进行签名的目的是为了建立信任链、验证证书的真实性、防止篡改和中间人攻击，并保护用户的隐私和数据安全。通过使用由受信任的 CA 机构签发的证书，可以确保通信的安全性和可靠性。

身份验证过程中会涉及到密钥，对称加密，非对称加密，摘要的概念，请解释一下

在身份验证过程中，涉及到密钥、对称加密、非对称加密和摘要等概念。下面我将为您解释每个概念的含义和作用：

1. 密钥： 密钥是用于加密和解密数据的秘密值。在身份验证过程中，密钥用于确保通信的机密性和完整性。对称加密和非对称加密都使用密钥来加密和解密数据。

2. 对称加密： 对称加密使用相同的密钥进行加密和解密。发送方使用密钥将数据加密，接收方使用相同的密钥解密数据。对称加密算法速度快，但需要确保密钥的安全共享，因为任何拥有该密钥的人都可以加密和解密数据。

3. 非对称加密： 非对称加密使用一对密钥，包括公钥和私钥。公钥用于加密数据，私钥用于解密数据。发送方使用接收方的公钥加密数据，只有接收方拥有对应的私钥才能解密数据。非对称加密算法提供了更高的安全性和身份验证能力，但比对称加密算法更加耗费计算资源。

4. 摘要： 摘要是对数据进行单向哈希计算的过程，生成固定长度的唯一摘要值。摘要值通常用于验证数据的完整性，而无法通过摘要值反推出原始数据。在身份验证过程中，常用的摘要算法如 SHA（Secure Hash Algorithm）被用于生成数据的摘要值。发送方可以将摘要值与数据一起发送，接收方通过重新计算摘要值并比较两者是否一致，从而验证数据的完整性。

这些概念在身份验证过程中起到重要作用。对称加密用于加密通信数据，非对称加密用于安全地交换密钥，并确保数据只能由合法方解密。摘要用于验证数据的完整性，确保数据在传输过程中未被篡改。综合使用这些技术可以构建安全的身份验证和通信系统。

webSocket 协议是什么，能简述一下吗？

WebSocket 协议是一种用于在 Web 应用程序中实现双向通信的协议。传统的 HTTP 协议是一种单向的通信协议，客户端发送请求，服务器返回响应，通信结束。而 WebSocket 协议允许在客户端和服务器之间建立持久的、双向的通信连接，使得服务器可以主动向客户端推送数据，而不需要客户端发送请求。

以下是 WebSocket 协议的一些关键特点：

1. 双向通信： WebSocket 协议支持双向通信，客户端和服务器可以同时发送和接收数据。这意味着服务器可以主动向客户端推送数据，而不需要客户端发起请求。

2. 持久连接： WebSocket 连接是持久的，一旦建立连接后，客户端和服务器之间的连接将保持打开状态，而不需要为每个请求/响应创建新的连接。这减少了连接建立的开销，同时提供了实时性和低延迟的通信。

3. 低开销： 与传统的 HTTP 通信相比，WebSocket 协议的开销较低。在初始建立连接时，客户端和服务器会进行一次握手过程，之后的通信数据可以以较小的开销进行传输。

4. 跨域支持： WebSocket 协议支持跨域通信，允许在不同域名或端口的客户端和服务器之间建立连接。这对于实现跨域的实时通信非常有用。

5. 实时性： WebSocket 协议提供了实时性的通信机制，适用于需要快速传输数据、实时更新或即时通知的应用场景，如聊天应用、实时数据监控等。

WebSocket 协议的使用需要在客户端和服务器上实现相应的 WebSocket API。现代的 Web 浏览器和 Web 服务器都支持 WebSocket 协议，使得开发者可以轻松地构建实时、交互性强的 Web 应用程序。

需要注意的是，WebSocket 协议是建立在 HTTP 协议之上的，通过 HTTP 的握手过程进行协议升级，从而建立 WebSocket 连接。这使得 WebSocket 可以与现有的 Web 基础设施和安全机制无缝集成。

webSocket 与传统的 http 有什么优势

WebSocket 与传统的 HTTP 相比具有以下几个优势：

1. 实时性和低延迟： WebSocket 协议提供了实时的双向通信机制，使得服务器可以主动向客户端推送数据，而不需要客户端发起请求。这极大地提高了实时性和低延迟的通信能力，适用于需要及时更新和实时交互的应用场景，如聊天应用、实时数据监控等。

2. 减少通信开销： 传统的 HTTP 协议在每次请求和响应时都需要携带 HTTP 头信息，这会增加通信的开销。而 WebSocket 协议在初始建立连接后，只需要进行一次握手过程，之后的通信数据可以以较小的开销进行传输，减少了不必要的头信息传输。

3. 较少的网络流量和资源消耗： WebSocket 协议使用的是持久连接，与传统的 HTTP 请求/响应模式相比，减少了不必要的连接建立和断开过程，从而减少了网络流量和服务器资源的消耗。

4. 跨域支持： WebSocket 协议支持跨域通信，允许在不同域名或端口的客户端和服务器之间建立连接。这对于实现跨域的实时通信非常有用，而传统的 HTTP 通信需要通过跨域资源共享（CORS）等机制来实现。

5. 更好的服务器资源利用： 由于 WebSocket 连接是持久的，服务器可以同时与多个客户端保持连接，有效地利用服务器资源，而不必为每个请求/响应创建新的连接。

需要注意的是，在某些情况下，如需要缓存、搜索引擎索引等特定需求的场景下，传统的 HTTP 请求/响应模式仍然是合适的选择。WebSocket 协议更适用于需要实时性、双向通信和低延迟的应用场景。

如何劫持 https 的请求，提供思路

https 有防篡改的特点，只要浏览器证书验证过程是正确的，很难在用户不察觉的情况下进行攻击。但若能够更改浏览器的证书验证过程，便有机会实现 https 中间人攻击。 所以，要劫持 https，首先要伪造一个证书，并且要想办法让用户信任这个证书，可以有多种方式，比如病毒、恶意软件、诱导等。一旦证书被信任后，就可以利用普通中间人攻击的方式，使用伪造的证书进行攻击。

怎样解决跨域问题？

跨域问题指的是在 Web 应用程序中，当浏览器执行一个跨域请求时，由于安全策略的限制，该请求会被浏览器阻止。为了解决跨域问题，有几种常用的方法：

1. CORS（跨域资源共享）： CORS 是一种机制，允许服务器在响应中添加一些头部信息，指示浏览器该服务器允许来自其他源的请求。通过在服务器端进行配置，可以控制是否允许跨域请求，以及允许的请求源、方法和头部信息等。在支持 CORS 的现代浏览器中，可以通过设置服务器的响应头部来实现跨域请求的授权。

2. JSONP（JSON with Padding）： JSONP 是一种利用<script>标签的 src 属性不受同源策略限制的特性来实现跨域请求的方法。通过将请求参数传递给一个动态生成的<script>标签的 src 属性，服务器可以返回一个回调函数的调用，并将数据作为参数传递给回调函数，从而实现跨域数据获取。

3. 代理服务器： 使用代理服务器是另一种常见的解决跨域问题的方法。在同域下搭建一个代理服务器，将跨域请求发送给代理服务器，然后代理服务器再将请求发送给目标服务器，并将响应返回给浏览器。由于浏览器与代理服务器之间是同域的，因此不存在跨域问题。

4. WebSocket 协议： WebSocket 协议支持跨域通信，可以在不同域名或端口之间建立持久的双向通信连接。通过 WebSocket 协议，客户端和服务器可以直接进行跨域通信，而无需采取其他跨域解决方案。

需要根据具体的情况选择合适的跨域解决方案。在使用这些方法时，应注意安全性和合法性，并确保遵守相关的安全和法律要求。

前端如何实现即时通讯？

前端实现即时通讯可以使用以下几种常见的技术和方法：

1. WebSocket： 使用 WebSocket 协议是实现即时通讯的常见方式。WebSocket 提供了实时的双向通信机制，可以在客户端和服务器之间建立持久连接，实现实时数据的推送和接收。在前端，可以使用 WebSocket API 来创建 WebSocket 连接，并通过发送和接收消息来实现即时通讯功能。

2. Server-Sent Events (SSE)： Server-Sent Events 是一种基于 HTTP 的单向通信机制，允许服务器向客户端推送事件和数据。在前端，可以通过创建 EventSource 对象来订阅服务器的事件流，服务器可以定期向客户端发送事件，实现实时通讯。

3. Long Polling： 长轮询是一种模拟实时通讯的技术，它通过客户端发送一个请求到服务器，服务器在有新数据时立即返回响应，否则一直保持连接不返回响应，直到有新数据到达或超时。在前端，可以使用 AJAX 或 Fetch API 来进行长轮询请求，并根据服务器的响应来实现实时通讯。

4. WebRTC： WebRTC 是一种支持浏览器间实时音视频通讯的技术。它提供了一组 API，使得浏览器可以直接建立点对点的通信连接，实现实时音视频的传输和通讯。在前端，可以使用 WebRTC API 来创建对等连接，进行音视频通话和数据传输。

这些技术和方法可以根据具体的需求和场景选择和组合使用。需要注意的是，实时通讯涉及到网络连接、服务器端的支持和逻辑处理，因此在实现时需要综合考虑前后端的配合和相关的安全性、性能和可伸缩性等因素。

HTTP 常用状态码

以下是 HTTP 常用的状态码及其含义：

1. 1xx 信息性状态码：

   • 100 Continue：服务器已经接收到请求的一部分，客户端应该继续发送剩余的请求。
   • 101 Switching Protocols：服务器要求客户端切换协议，如 HTTP 升级为 WebSocket。

2. 2xx 成功状态码：

   • 200 OK：请求成功，服务器成功处理了请求并返回相应结果。
   • 201 Created：请求成功，服务器成功创建了新资源。
   • 204 No Content：请求成功，服务器已处理请求，但没有返回任何内容。

3. 3xx 重定向状态码：

   • 301 Moved Permanently：请求的资源已被永久移动到新位置。
   • 302 Found：请求的资源临时移动到新位置。
   • 304 Not Modified：客户端可以使用缓存的版本，无需重新请求。

4. 4xx 客户端错误状态码：

   • 400 Bad Request：请求无效，服务器无法理解。
   • 401 Unauthorized：请求要求身份验证。
   • 403 Forbidden：服务器拒绝请求访问资源。
   • 404 Not Found：服务器找不到请求的资源。

5. 5xx 服务器错误状态码：

   • 500 Internal Server Error：服务器遇到了一个未知的错误。
   • 502 Bad Gateway：作为网关或代理服务器的服务器从上游服务器收到无效的响应。
   • 503 Service Unavailable：服务器暂时无法处理请求，通常由于过载或维护。

100 Continue 继续。客户端应继续其请求
101 Switching Protocols 切换协议。服务器根据客户端的请求切换协议。只能切换到更
高级的协议，例如，切换到HTTP 的新版本协议
200 OK 请求成功。一般用于GET 与POST 请求
201 Created 已创建。成功请求并创建了新的资源
202 Accepted 已接受。已经接受请求，但未处理完成
203 Non-Authoritative Information 非授权信息。请求成功。但返回的meta 信息不在原
始的服务器，而是一个副本
204 No Content 无内容。服务器成功处理，但未返回内容。在未更新网页的情况下，
可确保浏览器继续显示当前文档
205 Reset Content 重置内容。服务器处理成功，用户终端（例如：浏览器）应重置文
档视图。可通过此返回码清除浏览器的表单域
206 Partial Content 部分内容。服务器成功处理了部分GET 请求
300 Multiple Choices 多种选择。请求的资源可包括多个位置，相应可返回一个资源特
征与地址的列表用于用户终端（例如：浏览器）选择
301 Moved Permanently 永久移动。请求的资源已被永久的移动到新URI，返回信息会
包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI 代替
302 Found 临时移动。与301 类似。但资源只是临时被移动。客户端应继续使用原有
URI
303 See Other 查看其它地址。与301 类似。使用GET 和POST 请求查看
304 Not Modified 未修改。所请求的资源未修改，服务器返回此状态码时，不会返回
任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返
回在指定日期之后修改的资源
305 Use Proxy 使用代理。所请求的资源必须通过代理访问
306 Unused 已经被废弃的HTTP 状态码
307 Temporary Redirect 临时重定向。与302 类似。使用GET 请求重定向
400 Bad Request 客户端请求的语法错误，服务器无法理解
401 Unauthorized 请求要求用户的身份认证
402 Payment Required 保留，将来使用
403 Forbidden 服务器理解请求客户端的请求，但是拒绝执行此请求
404 Not Found 服务器无法根据客户端的请求找到资源（网页）。通过此代码，网站
设计人员可设置"您所请求的资源无法找到"的个性页面
405 Method Not Allowed 客户端请求中的方法被禁止
406 Not Acceptable 服务器无法根据客户端请求的内容特性完成请求
407 Proxy Authentication Required 请求要求代理的身份认证，与401 类似，但请求者
应当使用代理进行授权
408 Request Time-out 服务器等待客户端发送的请求时间过长，超时
409 Conflict 服务器完成客户端的PUT 请求是可能返回此代码，服务器处理请求时发
生了冲突
410 Gone 客户端请求的资源已经不存在。410 不同于404，如果资源以前有现在被永
久删除了可使用410 代码，网站设计人员可通过301 代码指定资源的新位置
411 Length Required 服务器无法处理客户端发送的不带Content-Length 的请求信息
412 Precondition Failed 客户端请求信息的先决条件错误
413 Request Entity Too Large 由于请求的实体过大，服务器无法处理，因此拒绝请求。
为防止客户端的连续请求，服务器可能会关闭连接。如果只是服务器暂时无法处理，则
会包含一个Retry-After 的响应信息
414 Request-URI Too Large 请求的URI 过长（URI 通常为网址），服务器无法处理
415 Unsupported Media Type 服务器无法处理请求附带的媒体格式
416 Requested range not satisfiable 客户端请求的范围无效
417 Expectation Failed 服务器无法满足Expect 的请求头信息
500 Internal Server Error 服务器内部错误，无法完成请求
501 Not Implemented 服务器不支持请求的功能，无法完成请求
502 Bad Gateway 作为网关或者代理工作的服务器尝试执行请求时，从远程服务器接
收到了一个无效的响应
503 Service Unavailable 由于超载或系统维护，服务器暂时的无法处理客户端的请求。
延时的长度可包含在服务器的Retry-After 头信息中
504 Gateway Time-out 充当网关或代理的服务器，未及时从远端服务器获取请求
505 HTTP Version not supported 服务器不支持请求的HTTP 协议的版本，无法完成处
理

以上只是 HTTP 状态码的一些常见示例，还有其他状态码可用于不同的情况。状态码提供了一种标准化的方式，用于表示请求和响应的处理结果，帮助开发者了解和处理 HTTP 通信中的问题。

http1.0、http2.0、http3.0 之间的区别

HTTP/1.0、HTTP/2.0 和 HTTP/3.0 是一系列的 HTTP 协议版本，它们在性能、功能和协议设计上存在一些重要的区别。

1. HTTP/1.0：

   • 连接管理：每个 HTTP 请求都会建立一个新的 TCP 连接，请求完成后关闭连接，无法复用连接。
   • 请求-响应模型：每个请求都需要等待响应返回，阻塞后续请求的发送。
   • 无法压缩头部：HTTP/1.0 无法对请求和响应的头部进行压缩，导致传输的额外开销。
   • 不支持多路复用：每个请求都需要独立的连接，无法同时发送多个请求或响应。

2. HTTP/1.1：

   • 持久连接：引入了持久连接，即多个请求可以复用同一个 TCP 连接，减少了连接的建立和关闭的开销。
   • 分块传输编码：支持将响应数据划分为多个块进行传输，可以在接收到部分响应时即开始处理，提高了传输效率。
   • 压缩：支持对请求和响应的头部进行压缩，减少了传输的开销。
   • 虚拟主机：支持通过 Host 头部字段来区分不同的虚拟主机。
   • 缓存控制：引入了更灵活的缓存控制机制。

3. HTTP/2.0：

   • 二进制协议：HTTP/2.0 使用二进制格式对请求和响应进行编码，提高了解析效率。
   • 多路复用：引入了多路复用技术，可以在同一个 TCP 连接上同时发送多个请求和响应，消除了串行阻塞。
   • 请求优先级和流控制：可以指定请求的优先级，确保关键资源的优先传输，并进行流的流量控制。
   • 头部压缩：引入了 HPACK 算法对请求和响应的头部进行压缩，减少了传输的开销。
   • 服务器推送：服务器可以主动推送相关资源给客户端，提前满足客户端的请求需求。

4. HTTP/3.0：

   • 基于 UDP：HTTP/3.0 使用基于 UDP 的传输协议（QUIC），而不是 TCP，提供更低的传输延迟和更好的拥塞控制。
   • 多路复用：类似于 HTTP/2.0，HTTP/3.0 也支持多路复用，但通过 QUIC 的连接实现。
   • 0-RTT 连接建立：HTTP/3.0 允许在建立连接时发送加密数据，减少了连接建立的延迟。
   • 重传和拥塞控制：QUIC 协议内置了重传和拥塞控制机制，可以更好地适应不可靠的网络环境。

总的来说，HTTP/2.0 和 HTTP/3.0 在性能和效率方面相对于 HTTP/1.0 有较大的改进，特别是引入了多路复用和头部压缩等机制，提高了并发性能和带宽利用率。HTTP/3.0 则通过基于 UDP 的传输协议（QUIC）进一步降低了延迟，并提供更好的连接建立和拥塞控制。

cookie/sessionStorage/localStorage 的区别

Cookie、sessionStorage 和 localStorage 都是在 Web 开发中用于在浏览器端存储数据的机制，它们之间有以下区别：

1. 存储容量：

   • Cookie：每个域名下的 Cookie 总存储容量通常限制在几 KB 到几十 KB 之间，不同浏览器有不同的限制。
   • sessionStorage：每个浏览器标签页(session)之间独立，存储容量通常为几 MB。
   • localStorage：每个域名下的 localStorage 总存储容量通常限制在几 MB 到几十 MB 之间。

2. 数据生命周期：

   • Cookie：可以设置过期时间，可以在浏览器关闭后仍然存在（持久性 Cookie），也可以在浏览器关闭后自动删除（会话性 Cookie）。
   • sessionStorage：仅在当前浏览器标签页(session)关闭之前有效，关闭后数据即被删除。
   • localStorage：除非主动清除，否则数据将一直存在于浏览器中。

3. 数据传输：

   • Cookie：每次请求都会自动携带相应域名下的 Cookie 信息，会增加请求头的大小，对网络传输有一定影响。
   • sessionStorage 和 localStorage：数据存储在浏览器端，不会自动携带到服务器，仅在客户端使用。

4. 访问权限：

   • Cookie：具有域名和路径的限制，只能在设置了 Cookie 的域名和路径下访问。
   • sessionStorage 和 localStorage：相同协议和域名下的网页均可访问。

5. 安全性：

   • Cookie：存储的数据会被包含在 HTTP 请求中，存在一定的安全风险，可以通过设置 HttpOnly 属性来限制客户端的访问。
   • sessionStorage 和 localStorage：存储在客户端，对于跨站脚本攻击（XSS）有一定的风险，但不会自动发送给服务器。

根据不同的需求和场景，可以选择适合的存储机制。一般来说，Cookie 适合存储较小且需要在服务器端访问的数据，sessionStorage 适合临时保存会话数据，localStorage 适合长期保存的数据。

cookie 的大小是有限制的，一般浏览器会限制同一个域下的 cookie 总量为 4M，而 sessionStorage 和 localStorage 则没有限制 cookie 会与 domain、path 关联，而 sessionStorage 和 localStorage 只与 domain 关联

post 请求什么时候用 form data 什么时候用 request payload

在 HTTP POST 请求中，使用"form data"或"request payload"取决于数据的格式和传输方式。

1. Form Data：

   • 使用"form data"时，数据以键值对的形式编码，并通过"Content-Type: application/x-www-form-urlencoded"头部字段进行传输。
   • 适用于模拟 HTML 表单提交的场景，常见于传统的表单提交和服务器端处理方式。
   • 通常用于提交简单的表单数据，如文本字段、复选框、单选按钮等。
   • 可以通过 HTML 表单元素的默认行为或 JavaScript 的 FormData 对象来构建和发送"form data"。

2. Request Payload：

   • 使用"request payload"时，数据以特定格式（如 JSON、XML 等）进行编码，并通过"Content-Type"头部字段指定传输格式。
   • 适用于传输结构化的、复杂的数据，如 JSON 对象、XML 文档等。
   • 常见于现代的前端框架（如 React、Angular、Vue.js）与后端 API 之间的数据传输方式。
   • 可以使用 JavaScript 的 fetch API、Axios 等库来构建和发送带有"request payload"的 POST 请求。

选择使用"form data"还是"request payload"通常取决于后端服务器的接收方式和数据格式要求。如果后端期望接收的数据是键值对形式，使用"form data"更为合适。如果后端期望接收的数据是结构化的数据，如 JSON 对象，使用"request payload"更为合适。

需要注意的是，"form data"和"request payload"并不是严格的规定，而是一种约定。在实际开发中，你可以根据具体需求和后端 API 的要求来选择合适的数据传输方式。

http 常见请求方法有哪些？

HTTP 协议定义了一些常见的请求方法（也称为 HTTP 动词或 HTTP 谓词）来指定对资源的不同操作。以下是 HTTP 常见的请求方法：

1. GET：用于获取指定资源的表示形式。GET 请求是幂等的，即多次发送相同的 GET 请求，不会对服务器产生副作用。GET 请求将参数附加在 URL 的查询字符串中。

2. POST：向指定的资源提交数据，用于创建新的资源或执行某种操作。POST 请求可能导致服务器状态的变化，不具备幂等性。请求数据通常包含在请求的主体中。

3. PUT：向指定的资源位置存储新的表示形式，用于更新指定资源的内容。PUT 请求是幂等的，即多次发送相同的 PUT 请求，会得到相同的结果。请求数据通常包含在请求的主体中。

4. DELETE：删除指定的资源。DELETE 请求是幂等的，即多次发送相同的 DELETE 请求，会得到相同的结果。

5. PATCH：对指定资源进行部分更新。PATCH 请求用于对资源进行局部修改，只更新请求中指定的字段或属性。

6. HEAD：类似于 GET 请求，但只返回与请求相关的响应头部，不返回响应体。HEAD 请求常用于检查资源的元数据，如判断资源是否存在或是否已修改。

7. OPTIONS：获取指定资源支持的请求方法、请求头部等信息。OPTIONS 请求用于查询服务器支持的功能和通信选项。

8. TRACE：用于追踪请求在代理服务器上的传输路径，主要用于诊断和调试。

除了上述常见的 HTTP 请求方法，HTTP/1.1 规范还定义了其他一些请求方法，如 CONNECT、PROPFIND、MKCOL 等，用于特定的功能和场景。不同的请求方法具有不同的语义和用途，开发者可以根据具体需求选择合适的请求方法来与服务器进行交互。

列举优化网络性能方法

优化网络性能是 Web 开发中的重要任务之一，以下列举了一些常见的方法来提升网络性能：

1. 使用 CDN（内容分发网络）：将静态资源（如图片、样式表、脚本文件）部署到 CDN 上，利用离用户地理位置较近的缓存服务器来加速资源的传输，减少延迟并提高响应速度。

2. 压缩资源：对静态资源进行压缩，如使用 Gzip 或 Brotli 对文本文件（如 HTML、CSS、JavaScript）进行压缩，减少文件大小，加快下载速度。

3. 使用缓存：通过设置适当的缓存策略，让浏览器缓存页面和资源，减少对服务器的请求。使用浏览器缓存可以通过设置响应头的 Cache-Control 和 Expires 字段来实现。

4. 减少 HTTP 请求：合并和压缩多个 CSS 和 JavaScript 文件，减少 HTTP 请求次数。使用 CSS Sprites 将多个小图标合并成一张大图，通过 CSS 背景定位来显示不同的图标。

5. 使用异步加载：将 JavaScript 脚本放在页面底部，或使用 async 和 defer 属性进行异步加载，避免阻塞页面渲染。

6. 优化图片：使用适当的图片格式（如 JPEG、PNG、WebP）和压缩级别，根据实际需要选择合适的图片尺寸和分辨率，使用懒加载或按需加载图片。

7. 减少重定向：避免多余的重定向，直接访问目标 URL，减少额外的网络请求和延迟。

8. 使用 HTTP/2 或 HTTP/3：升级到新的 HTTP 协议版本，如 HTTP/2 或 HTTP/3，以支持多路复用、服务器推送等特性，提高并行传输和性能。

9. 使用合适的数据传输格式：选择合适的数据传输格式，如 JSON、Protocol Buffers 或 MessagePack，减少数据大小和传输时间。

10. 优化 DNS 解析：减少 DNS 查找时间，使用 CDN、预解析（prefetching）或预连接（preconnecting）来优化 DNS 解析过程。

11. 使用 HTTP 缓存：合理利用 HTTP 缓存机制，设置适当的缓存策略，如使用 Etag 和 Last-Modified 来进行缓存验证，避免不必要的数据传输。

12. 减小 Cookie 大小：仅在必要时使用 Cookie，并减小 Cookie 的大小，避免不必要的带宽消耗。

这些方法都可以在不同层面上优化网络性能，提升网站的加载速度和用户体验。根据具体的应用场景和需求，可以选择适合的方法进行网络性能优化。

session 怎么消除

要消除会话（session），你可以采取以下方法：

1. 清除服务器端的会话数据：会话数据通常存储在服务器端，例如在内存、数据库或持久化存储中。你可以通过在服务器上删除或清除与会话相关的数据来消除会话。具体的操作方法取决于你所使用的服务器和会话管理方式。

2. 使会话失效/过期：会话通常具有过期时间，在超过一定时间段后自动失效。你可以通过调整会话的过期时间来缩短会话的生命周期，使其在较短时间内失效。

3. 删除客户端的会话标识符：会话标识符（通常是一个 cookie）存储在客户端，并用于识别会话。你可以通过在响应中删除会话标识符的方式，要求客户端不再发送该标识符，从而达到消除会话的效果。

4. 清除浏览器缓存：浏览器可能会缓存会话数据，包括 cookie 和其他相关信息。通过清除浏览器缓存，可以清除与会话相关的数据。

需要注意的是，会话是一种基于状态的机制，用于在多个请求之间保持用户的身份和状态。因此，消除会话可能会导致用户的身份和状态丢失，因此在决定消除会话时需要谨慎考虑，并确保不会对用户体验和功能造成不良影响。

什么是 DNS 域名解析？

DNS（Domain Name System）域名解析是将人类可读的域名（例如 example.com）转换为计算机可理解的 IP 地址（例如 192.0.2.1）的过程。DNS 解析是互联网中域名与 IP 地址之间的转换机制。

当你在浏览器中输入一个域名时，浏览器首先会发送一个 DNS 解析请求到本地计算机或网络中的 DNS 解析器（通常由 Internet 服务提供商（ISP）提供）。

DNS 解析的过程如下：

1. 本地缓存检查：首先，本地 DNS 解析器会检查自己的缓存，看看是否已经解析过该域名。如果有缓存记录，解析器会直接返回对应的 IP 地址，减少解析时间。

2. 递归解析：如果本地缓存没有找到对应的记录，解析器会向根域名服务器发送请求，询问顶级域名服务器（如.com、.org）的 IP 地址。

3. 顺序解析：一旦获得顶级域名服务器的 IP 地址，解析器会继续向其发送请求，询问次级域名服务器的 IP 地址。这个过程会一级一级地向下进行，直到找到负责解析目标域名的特定域名服务器。

4. 解析结果返回：一旦找到负责解析目标域名的特定域名服务器，它会返回对应的 IP 地址给本地 DNS 解析器。

5. 本地缓存更新：本地 DNS 解析器将解析结果存储在本地缓存中，以便将来的请求可以更快地获得结果。

6. IP 地址返回：最后，本地 DNS 解析器将 IP 地址返回给浏览器，让浏览器可以向该 IP 地址发送请求，与目标服务器建立连接。

DNS 域名解析是互联网中重要的系统，它使得我们可以使用友好的域名来访问网站，而无需记住复杂的 IP 地址。

网络分层模型有哪七层？

网络分层模型指的是 OSI（Open Systems Interconnection）参考模型，它将网络通信划分为七个不同的层级。以下是 OSI 模型中的七个层级：

1. 物理层（Physical Layer）：物理层是网络通信的最底层，负责传输比特流（0 和 1）通过物理介质，如电缆、光纤或无线信号。它定义了传输介质的电气、机械和功能特性。

2. 数据链路层（Data Link Layer）：数据链路层建立在物理层之上，负责在直接相连的节点之间可靠地传输数据。它将原始的比特流划分为帧（Frames），并提供错误检测和纠正、帧同步、流控制等功能。

3. 网络层（Network Layer）：网络层负责在不同的网络之间进行数据包的路由和转发。它使用 IP 地址来标识网络设备，并决定最佳的数据传输路径。常见的网络层协议包括 IP（Internet Protocol）。

4. 传输层（Transport Layer）：传输层提供端到端的可靠数据传输。它将数据分割成较小的数据段，并为每个数据段提供可靠性保证、流量控制、拥塞控制等功能。传输层主要使用 TCP（Transmission Control Protocol）和 UDP（User Datagram Protocol）协议。

5. 会话层（Session Layer）：会话层负责建立、管理和终止会话（Session）或连接。它处理会话的控制和同步，提供会话的建立、保持和恢复功能。

6. 表示层（Presentation Layer）：表示层处理数据的表示和转换，确保不同系统的数据格式可以互相理解。它负责数据的加密、压缩、解压缩、编码和解码等操作。

7. 应用层（Application Layer）：应用层是最高层也是最接近用户的层级，提供用户与网络服务的接口。它包括各种应用协议，如 HTTP（Hypertext Transfer Protocol）、FTP（File Transfer Protocol）、SMTP（Simple Mail Transfer Protocol）等。

这些七个层级构成了 OSI 参考模型，每个层级都负责不同的功能，通过在不同层级之间定义清晰的接口，实现了网络中的通信和协作。需要注意的是，现实中更常用的是 TCP/IP 协议栈，它是基于 OSI 模型的简化版本，将网络通信划分为四个层级：网络接口层、网络层、传输层和应用层。

OSI 7 层模型和 TCP/IP 四层模型

OSI（开放系统互联模型）和 TCP/IP（传输控制协议/网际协议）是两种不同的网络模型，用于描述计算机网络中不同层级的功能和协议。

OSI 7 层模型（OSI 7-Layer Model）是国际标准化组织（ISO）定义的一种网络参考模型，它将计算机网络通信划分为七个不同的层级，每个层级负责特定的功能。以下是每个层级的简要说明：

1. 物理层（Physical Layer）： 负责传输原始比特流，处理物理连接和电信号传输，例如电缆、光纤和物理接口。

2. 数据链路层（Data Link Layer）： 提供可靠的点对点数据传输，通过帧（Frame）将数据划分为较小的块，并处理物理寻址、流控和差错校验等功能。

3. 网络层（Network Layer）： 处理网络间的数据路由和转发，负责将数据包从源主机传输到目标主机，包括寻址、路由选择和分组转发等功能。IP（Internet Protocol）是一种常见的网络层协议。

4. 传输层（Transport Layer）： 提供端到端的数据传输服务，负责数据的分段、流量控制、差错恢复和可靠性保证。TCP（Transmission Control Protocol）和 UDP（User Datagram Protocol）是常见的传输层协议。

5. 会话层（Session Layer）： 管理不同计算机之间的会话和连接，并提供会话的建立、维护和终止功能。

6. 表示层（Presentation Layer）： 处理数据的表示方式，负责数据的加密、压缩、解压缩和格式转换等功能，以确保应用程序能够正确地解释数据。

7. 应用层（Application Layer）： 提供用户与网络之间的接口，支持不同应用程序之间的通信和数据交换。常见的应用层协议包括 HTTP、FTP、SMTP 等。

TCP/IP 四层模型（TCP/IP Four-Layer Model）是互联网工程任务组（IETF）定义的一种网络模型，它将网络通信划分为四个层级，相对于 OSI 模型，合并了表示层和会话层，并将网络层和数据链路层的部分功能整合到一起。以下是每个层级的简要说明：

1. 网络接口层（Network Interface Layer）： 包含物理层和数据链路层的功能，处理物理连接、数据帧的传输和物理寻址等。

2. 网络层（Internet Layer）： 类似于 OSI 模型的网络层，负责数据路由和转发，以及 IP 协议的功能。

3. 传输层（Transport Layer）： 与 OSI 模型的传输层相同，提供端到端的数据传输服务，包括 TCP 和 UDP 协议的功能。

4. 应用层（Application Layer）： 与 OSI 模型的应用层相同，提供应用程序与网络之间的接口，支持不同应用层协议的功能。

需要注意的是，TCP/IP 四层模型是一种更简化的模型，与实际的网络协议栈中的协议分布并不完全一致。实际上，TCP/IP 协议栈中包含了更多的协议和功能，例如 ARP（地址解析协议）、ICMP（Internet 控制消息协议）等，它们在 OSI 模型中没有对应的明确层级。

常见的请求方法

在网络通信中，常见的请求方法（也称为 HTTP 方法或 HTTP 动词）用于指定客户端对服务器资源的操作类型。以下是常见的请求方法：

1. GET： 用于从服务器获取资源，无副作用，仅获取数据。

2. POST： 用于向服务器提交数据，通常用于创建新资源或执行某些处理操作。

3. PUT： 用于向服务器更新或替换资源，通常用于完全替换指定资源的内容。

4. PATCH： 用于向服务器部分更新资源，通常用于对指定资源进行局部修改。

5. DELETE： 用于从服务器删除指定的资源。

6. HEAD： 类似于 GET 方法，但只返回响应头部信息，而不返回实际的资源内容。

7. OPTIONS： 用于获取服务器支持的请求方法和资源的通信选项。

8. TRACE： 用于追踪请求在服务器端的传输路径，通常用于调试和诊断。

除了以上常见的请求方法，HTTP/1.1 规范还定义了一些其他的方法，如 CONNECT、MOVE、COPY 等，但它们的使用相对较少。

值得注意的是，请求方法的语义是标准化的，服务器和客户端都应该按照规范来解释和处理不同的请求方法。在实际的应用中，正确选择和使用适当的请求方法对于设计合理的 RESTful API 和实现安全的网络通信都非常重要。

HTTP 报文的结构

HTTP（Hypertext Transfer Protocol）报文是在客户端和服务器之间进行通信时使用的数据格式。它由请求报文和响应报文两种类型组成，具有相似的结构。下面是 HTTP 报文的一般结构：

1. 起始行（Start Line）： 起始行指定了请求或响应的基本信息，包括请求方法、URI（统一资源标识符）和 HTTP 版本号。对于请求报文，起始行包括请求方法、目标 URI 和 HTTP 版本号；对于响应报文，起始行包括 HTTP 版本号、状态码和对应的状态短语。

2. 首部（Header）： 首部包含了一系列的名值对，用于描述请求或响应的各种属性和元数据。每个首部字段都由字段名和字段值组成，中间使用冒号分隔。常见的首部字段包括 Content-Type、Content-Length、Cache-Control、User-Agent 等。首部字段可以有多个，并且可以自定义扩展字段。

3. 空行（Blank Line）： 空行是起始行和消息体之间的空白行，用于分隔首部和消息体。

4. 消息体（Message Body）： 消息体是可选的，用于携带请求或响应的实际数据内容。在请求报文中，消息体通常包含了要发送给服务器的数据，如表单数据、JSON 数据等；在响应报文中，消息体通常包含了服务器返回的实际资源数据，如 HTML 页面、图片、JSON 数据等。

总体而言，HTTP 报文的结构可以简化为以下形式：

起始行
首部
空行
消息体

需要注意的是，起始行和首部字段都是以换行符（CRLF，即回车符和换行符组合）作为行结束符进行分隔的。而空行是一个单独的换行符，用于表示首部的结束。如果报文中没有消息体，那么空行后面就直接结束了。

报文首部的结构

HTTP 报文中的首部字段（Header Fields）提供了关于请求或响应的附加信息和元数据。每个首部字段都由一个字段名和一个对应的字段值组成，中间使用冒号进行分隔。多个首部字段由换行符（CRLF）分隔。

以下是一个报文首部的示例结构：

字段名1: 值1
字段名2: 值2
字段名3: 值3
...

报文首部的结构可以包含多个字段，每个字段提供不同的信息。常见的报文首部字段包括：

• Host： 指定目标服务器的主机名或 IP 地址。
• User-Agent： 标识发起请求的用户代理（浏览器、应用程序等）的信息。
• Content-Type： 指定请求或响应中的实体内容的 MIME 类型（例如：text/html、application/json）。
• Content-Length： 指定请求或响应中实体内容的长度（以字节为单位）。
• Cache-Control： 控制缓存行为的指令，如缓存的存储与获取策略。
• Authorization： 提供对请求的身份验证凭据，用于访问受限资源。
• Cookie： 用于在客户端和服务器之间传递会话信息的报头字段。
• Set-Cookie： 服务器通过响应报文设置在客户端保存会话信息的 Cookie。

此外，还有许多其他的首部字段，用于提供各种功能和控制选项，例如跨域资源共享 (CORS)、缓存机制、压缩、身份验证等。

需要注意的是，报文首部字段可以具有多个同名字段，这种情况下，它们被认为是同一个字段的多个值。某些首部字段还可以包含参数，参数使用分号进行分隔。例如，Content-Type 首部字段可以包含字符编码参数，如 Content-Type: text/html; charset=UTF-8。

报文首部提供了灵活的机制，允许客户端和服务器之间传递额外的元数据和配置信息，以便更好地控制和处理请求和响应。

讲讲缓存

我们前端说的本地缓存一般指的是浏览器的本地缓存（webStorage），而本地缓存是我们做性能优化时的一大关注点，接下来我就带大家一起学习下如何利用本地缓存来做性能优化！

缓存分类：

1.Memory Cache：再浏览器内存中的缓存，访问优先级最高，访问速度也是最快的（和渲染进程共存，进程关闭就清除缓存，所以有效期比较短）

2.service worker Cache：独立的 js 线程，可实现离线缓存、消息推送等功能

3.Disk Cache：磁盘中的缓存，容量较大，但是相对的访问速度较慢

4.push Cache：HTTP2的新特新，优先级最低（前面三种缓存无法命中后才会命中这个）

比如我们现在打开掘金首页的控制台，就可以看到哪些请求是用了缓存的

（红色框里的就是用了memory cache 或disk cache 的）

缓存策略：

浏览器的缓存策略可以分为强缓存 和协商缓存两种

• 强缓存： 不用向服务器请求。可以通过设置 HTTP Header的expries和cache-control实现

  • expries： 服务器第一次响应时，会将过期的时间戳写在expries的请求头中返回，当我们再次请求时，如果本地时间小于expries的时间戳，就直接去缓存中读取资源

    • 缺点：如果跟改了本地时间，可能会导致缓存失效

  • cache-control： 通过 max-age控制本地资源的有效期，s-maxage控制代理服务器（CDN 缓存）的有效期（s-maxage仅在代理服务器中生效，max-age仅在客户端生效），设置成no-store 则表示拒绝一切形式的缓存

    • 缺点：如果更改了本地时间，同样会导致缓存失效，但是解决了 expires会因为客户端和服务器直接时差不一导致的缓存时间不一致的问题

cache-control优先级高于 expries

• 协商缓存：浏览器需要先向服务器发起请求，在判断是否从本地获取缓存资源。可以通过设置 HTTP Header的 Last-Modified和 ETag实现

  • Last-Modified：首次响应时会返回 Last-Modified字段，之后客户端每次请求都会带上 If-Modified-Since的字段（上一次response中的 Last-Modified的值），服务器根据该时间戳和资源在服务器上最后的修改时间是否一致来判断是否使用缓存（返回 304 表示使用本地缓存，返回新的 Last-Modified表示不使用缓存）

    • 缺点：如果服务器没有及时感知到文件的变化（比如在毫秒级时间内完成了改动，但是因为 Last-Modified是秒级导致无法感知）

  • ETag：既然上面的 Last-Modified存在着缺点，那 ETag就是他的解决方案（服务器根据文件内容编码生成唯一标识符，可以精确感知文件的变化），首次响应会返回 ETag标识，下一次请求就带上 If-None-Match与服务端进行比较来判断是否使用缓存 （ETag是由文件内容和最后修改时间共同作用生成的）

    • 缺点：服务端需要额外的开销来生成 ETag标识

Etag 在感知文件变化上比 Last-Modified 更加准确，优先级也更高。当 Etag 和 Last-Modified 同时存在时，以 Etag 为准。

HTTP 决策

关于 HTTP 请求的决策，这里我们通过Chrome给出的官方流程图来给大家讲解

接下来我给大家解释下上面的步骤

1. 考虑资源是否可复用
   1. 如果不可以复用，则直接设置 Cache-Control 成 no-store表示拒绝一切形式的缓存
   2. 如果可以复用，考虑是否设置成每次都需要向浏览器进行缓存的有效确认
      1. 如果需要，则设置 Cache-Control为 no-cache
      2. 如果不需要，则考虑是否可以被代理服务器缓存
         1. 如果可以，设置成 public
         2. 如果不行，设置成 private
   3. 考虑资源有效时长
      1. 设置对应的 max-age和 s-maxage等值
      2. 最后再设置协商缓存需要用到的 ETag和 Last-Modified

以上便是对于一个HTTP 请求是否要用缓存以及如何使用缓存的决策过程，我们在考虑是否使用缓存的时候也可以按着这个思路来考虑。

网页刷新对缓存的影响

接下来我们看看网页刷新对各类缓存的影响，帮助大家更好地使用缓存

• 强制刷新： 直接从服务器请求，跳过强缓存和协商缓存（比如 Ctrl + F5）
• 地址栏回车或正常刷新：跳出强缓存，检查协商缓存
• 新窗口的 URL 访问： 按照正常的缓存策略，即先检查强缓存

相信看到这里你对于如何使用缓存来优化性能应该有了更深入的了解，赶快动手试试吧！

来源（非 AI）：https://juejin.cn/post/7153057814615687175

讲讲 DNS

DNS（Domain Name System，域名系统）是互联网上用于将域名（例如www.example.com）转换为对应 IP 地址的分布式命名系统。它充当了互联网上的“电话簿”，将易于记忆的域名映射到计算机可理解的 IP 地址。

DNS 的主要功能是将域名解析为 IP 地址，以便网络上的计算机能够相互通信。当您在浏览器中输入一个域名时，浏览器会向本地 DNS 解析器发出查询请求。以下是 DNS 解析的基本过程：

1. 递归查询： 当本地 DNS 解析器接收到域名查询请求后，它首先检查本地缓存中是否存在该域名的 IP 地址。如果存在，则返回缓存的结果。如果不存在，则进行递归查询。

2. 迭代查询： 本地 DNS 解析器向根域名服务器发送查询请求，询问顶级域名的 authoritative name server（权威名称服务器）的地址。根域名服务器是 DNS 层级结构的最高级别，它存储了顶级域名（例如.com、.net）的 authoritative name server 的地址。

3. 顶级域名查询： 本地 DNS 解析器向顶级域名服务器发送查询请求，询问二级域名的 authoritative name server 的地址。例如，如果查询的域名是www.example.com，那么顶级域名服务器将返回负责.com 域的 authoritative name server 的地址。

4. 权威名称服务器查询： 本地 DNS 解析器向负责特定域的 authoritative name server 发送查询请求。该 authoritative name server 存储了与该域相关的 IP 地址信息。它将返回查询域名的 IP 地址给本地 DNS 解析器。

5. 结果返回： 本地 DNS 解析器接收到 authoritative name server 的响应后，将 IP 地址返回给浏览器，并将结果保存在本地缓存中，以便下次查询时使用。

整个 DNS 解析过程可能涉及多次查询和响应，但由于大多数 DNS 解析器会缓存查询结果，因此对于相同的域名，后续的查询通常会更快，不需要再次查询 authoritative name server。

DNS 的分布式特性是通过将域名系统划分为多个层级、多个服务器和多个域名解析器来实现的。这种分布式设计有助于提高系统的可靠性、可扩展性和性能。

总之，DNS 是互联网中关键的基础设施之一，它使得人们能够使用易于记忆的域名来访问互联网资源，而无需记住复杂的 IP 地址。

讲讲 http 的不同版本

HTTP（Hypertext Transfer Protocol，超文本传输协议）是用于在客户端和服务器之间传输数据的协议。它已经经历了多个版本的演进，包括 HTTP/0.9、HTTP/1.0、HTTP/1.1 和 HTTP/2，以及最新的 HTTP/3。以下是这些版本的简要介绍：

1. HTTP/0.9： 这是最早的 HTTP 版本，于 1991 年引入。它非常简单，只支持 GET 方法，并且请求和响应报文都不带首部。它仅用于传输纯文本的 HTML 页面。

2. HTTP/1.0： 在 1996 年发布，HTTP/1.0 引入了多个重要的新特性。它支持多种请求方法（GET、POST 等），引入了状态码和响应头部，以及多部分（multipart）和带附件的消息体。HTTP/1.0 是一个无状态的协议，每个请求和响应都是独立的，不保留任何上下文信息。使用 If-Modified-Since | Expries 控制缓存.

3. HTTP/1.1： 于 1999 年发布，HTTP/1.1 是当前最广泛使用的 HTTP 版本。它在 HTTP/1.0 的基础上引入了持久连接（keep-alive）和管道化（pipelining）等功能，以减少重复的连接建立和断开开销。HTTP/1.1 还引入了虚拟主机、缓存控制、分块传输编码（chunked transfer encoding）等特性。比起 HTTP/1.0 增加了 ETag| If-Unmodified-Since | If-Match 等更多缓存头部字段，支持协商缓存和强缓存.新增了 PUT | HEAD | OPTIONS 等请求方法.新增 Host 字段（一个服务器可以创建多个 web 站点）

4. HTTP/2： 在 2015 年发布，HTTP/2 是对 HTTP/1.1 的重大改进。它采用了二进制协议，使用了帧（frame）和流（stream）的概念，允许多个请求和响应在同一个连接上并行传输。HTTP/2 支持头部压缩、服务器推送、优先级和流控制等特性，以提高性能和效率。

5. HTTP/3： HTTP/3 是最新的 HTTP 版本，基于 QUIC（Quick UDP Internet Connections）协议。QUIC 是一个在传输层提供安全性和可靠性的协议，它使用了 UDP 协议而不是 TCP。HTTP/3 通过使用 QUIC 替代传统的 TCP+TLS 组合来提供更快的连接建立和数据传输速度，以及更好的适应性和可靠性。

HTTP/1.1 仍然是互联网上最常用的 HTTP 版本，但 HTTP/2 和 HTTP/3 正在逐渐得到广泛采用，并提供了更好的性能和用户体验。每个版本都在之前版本的基础上引入了新的功能和改进，以满足不断增长的互联网应用需求。

https 是对称加密还是非对称

HTTPS（Hypertext Transfer Protocol Secure）使用的加密机制包含对称加密和非对称加密的组合。

1. 对称加密： 在 HTTPS 通信的过程中，对称加密用于加密传输的数据。对称加密使用相同的密钥用于加密和解密数据。在建立 HTTPS 连接时，客户端和服务器之间协商一个对称密钥，该密钥用于加密传输的数据。对称加密算法的优势在于加密和解密速度较快，但需要确保密钥的安全传输，以防止中间人攻击。

2. 非对称加密： 非对称加密用于在 HTTPS 连接的建立过程中进行身份验证和密钥交换。非对称加密使用一对密钥，包括公钥和私钥。服务器拥有私钥，用于解密客户端发送的加密数据，而公钥在证书中公开发布给客户端。客户端使用服务器的公钥加密生成的密钥，然后将该密钥发送给服务器，服务器使用私钥解密该密钥。这样，客户端和服务器都拥有相同的对称密钥，用于后续的数据传输。

综上所述，HTTPS 使用对称加密和非对称加密的组合来提供加密和安全性。对称加密用于加密传输的数据，而非对称加密用于身份验证和密钥交换。这种结合在保证数据传输安全的同时，提供了高效的加密和解密过程。

介绍下 HTTPS 中间人攻击

HTTPS 中间人攻击（Man-in-the-Middle Attack，简称 MITM 攻击）是一种攻击手法，攻击者通过在通信双方之间插入自己的恶意代理，能够拦截、篡改和窃取双方之间的通信内容。

HTTPS（Hypertext Transfer Protocol Secure）是一种通过加密和认证保护通信安全的协议。在正常的 HTTPS 通信中，客户端和服务器之间的通信被加密，确保敏感数据在传输过程中不会被窃听、篡改或伪造。

然而，在中间人攻击中，攻击者成功地插入了自己的恶意代理服务器，使其置身于客户端和服务器之间。攻击者与客户端建立一个加密连接，同时与服务器建立另一个加密连接，从而伪装成客户端和服务器的中间人。攻击者能够解密和读取客户端发送给服务器的数据，并有机会对数据进行篡改。然后，攻击者再将篡改后的数据加密并转发给服务器，同时对从服务器返回的数据进行同样的操作，以保持双方间的通信看似正常。

中间人攻击通常通过以下方式实施：

1. SSL/TLS 剥离（SSL/TLS Stripping）：攻击者将 HTTPS 请求重定向到非加密的 HTTP 连接，使客户端与服务器之间的通信不再加密。这样，攻击者可以窃听和篡改通信内容。

2. 自签名证书攻击（Self-Signed Certificate Attack）：攻击者伪造一个自签名证书，欺骗客户端相信它是合法的服务器。当客户端与攻击者的代理服务器建立连接时，攻击者会使用这个伪造的证书进行握手，对客户端进行欺骗，使其相信通信是安全的。

3. 证书劫持（Certificate Hijacking）：攻击者能够获取到合法服务器的私钥，或者能够替换合法证书的公钥部分，从而能够解密和篡改通信内容。

中间人攻击对通信的安全性构成严重威胁，因为攻击者能够窃听和篡改敏感数据，例如用户名、密码、信用卡信息等。为了防止中间人攻击，应采取以下措施：

1. 使用受信任的证书：确保使用由受信任的证书颁发机构（Certificate Authority，CA）签发的证书，以验证服务器的身份。

2. 公钥固定（Public Key Pinning）：在客户端上固定服务器的公钥，以防止攻击者替换证书或使用伪造的证书。

3. 使用安全的连接：避免访问不受信任的、使用不安全协议的连接，例如通过非加密的公共 Wi-Fi 进行敏感操作。

4. 安全编码实践：在开发和部署应用程序时，应遵循安全编码实践，防止常见的安全漏洞和攻击。

总之，HTTPS 中间人攻击是一种危险的攻击手法，通过插入恶意代理服务器，攻击者能够窃听、篡改和窃取双方之间的通信内容。为了保护通信的安全性，应采取适当的安全措施和实践。

TCP UDP 区别

TCP（传输控制协议）和 UDP（用户数据报协议）是两种常见的传输层协议，用于在计算机网络中传输数据。它们在功能、特点和适用场景上有一些明显的区别。

TCP (传输控制协议):

1. 可靠性: TCP 提供可靠的数据传输，通过使用确认、重传和错误检测机制，确保数据在传输过程中不丢失、不重复、并按正确的顺序到达目标。如果数据包丢失或损坏，TCP 会自动重传。

2. 有连接: 在 TCP 通信中，通信双方需要先建立连接，然后才能进行数据传输。这个过程包括三次握手（establishing connection）和四次挥手（terminating connection）等步骤。

3. 面向字节流: TCP 将数据视为字节流，它在发送端将数据分割成适当大小的数据块，并在接收端重新组装。这意味着数据可能会被分割成多个 TCP 段，或者多个 TCP 段可能会合并成一个数据块。

4. 拥塞控制: TCP 具有拥塞控制机制，可以根据网络的拥塞程度自适应地调整数据传输的速率，以避免网络拥塞。

5. 适用场景: TCP 适用于对数据可靠性要求较高的应用场景，如文件传输、电子邮件、网页浏览等。

UDP (用户数据报协议):

1. 无连接: UDP 是一种无连接的协议，不需要在通信之前建立连接。每个 UDP 数据包都是独立的，相互之间没有关联。

2. 不可靠性: UDP 不提供可靠的数据传输保证。它不进行确认、重传或错误检测，发送的数据包可能会丢失、重复或乱序到达。

3. 面向数据报: UDP 将数据分割成数据报（数据包），每个数据报都是独立的信息单元。接收端根据数据报边界来处理数据。

4. 低延迟: 由于 UDP 不需要建立连接和保证可靠性，它的开销较小，传输延迟较低。

5. 适用场景: UDP 适用于实时应用场景，如音频、视频流传输、游戏等，其中实时性比可靠性更重要。

区别	UDP	TCP
是否连接	无连接	面向连接
是否可靠	不可靠传输，不使用流量控制和拥塞控制	可靠传输，使用流量控制和拥塞控制
连接对象个数	支持一对一，一对多，多对一和多对多交互通信	只能是一对一通信
传输方式	面向报文	面向字节流
首部开销	首部开销小，仅 8 字节	首部最小 20 字节，最大 60 字节
适用场景	适用于实时应用（IP 电话、视频会议、直播等）	适用于要求可靠传输的应用，例如文件传输

综上所述，TCP 提供可靠的、面向连接的字节流传输，适用于对数据完整性和顺序性要求较高的应用场景。而 UDP 是一种无连接的、面向数据报的传输协议，适用于实时性要求较高的应用场景，但对数据的完整性和顺序性要求较低。

Http 和 Https 区别

HTTP（超文本传输协议）和 HTTPS（安全超文本传输协议）是用于在网络上传输数据的两种协议，它们在安全性和数据传输方式上有明显的区别。

HTTP（超文本传输协议）:

1. 不安全性: HTTP 是一种明文协议，数据在传输过程中以纯文本形式传输，没有加密保护。这意味着攻击者可以截获和查看传输的数据内容，存在信息泄露和篡改的风险。

2. 默认端口: HTTP 使用默认的端口号 80 进行通信。

3. 无身份验证: HTTP 不提供身份验证机制，无法验证服务器和客户端之间的身份。

4. 速度较快: 由于不涉及加密和握手过程，HTTP 的传输速度相对较快。

HTTPS（安全超文本传输协议）:

1. 安全性: HTTPS 使用 SSL（安全套接层）或 TLS（传输层安全）协议对数据进行加密和身份验证。通过使用公钥加密和对称密钥加密等技术，HTTPS 能够保护数据的机密性和完整性，防止数据被窃听和篡改。

2. 默认端口: HTTPS 使用默认的端口号 443 进行通信。

3. 身份验证: HTTPS 使用数字证书对服务器进行身份验证，确保客户端与合法的服务器建立连接。这样可以防止中间人攻击和伪装。

4. 稍慢: 由于涉及加密和握手过程，HTTPS 的传输速度相对较慢。

5. 可信度: HTTPS 使用数字证书来验证服务器的真实性和可信度。证书由可信的第三方机构颁发，客户端可以验证证书的有效性和合法性。

综上所述，HTTP 是一种不安全的协议，适用于对数据安全性要求不高的场景，如一般的网页浏览。而 HTTPS 通过加密和身份验证机制，提供了更高的数据安全性，适用于需要保护敏感信息的场景，如在线支付、用户登录等。在使用 HTTPS 时，通信双方之间的数据传输是经过加密保护的，确保了数据的机密性、完整性和真实性。

理解 xss，csrf，ddos 攻击原理以及避免方式

以下是对 XSS（跨站脚本攻击），CSRF（跨站请求伪造）和 DDoS（分布式拒绝服务攻击）攻击的简要解释以及避免方式：

XSS（跨站脚本攻击）: XSS 攻击是一种利用网页应用漏洞的攻击方式，攻击者通过注入恶意脚本代码到网页中，使得用户在浏览该页面时执行这些恶意代码。这可以导致攻击者在用户浏览器中执行恶意操作，如窃取用户敏感信息、劫持会话等。

避免方式：

• 对用户输入进行严格的验证和过滤，不信任任何来自用户的输入数据。
• 对输出到网页的内容进行正确的编码，以防止恶意脚本的执行。
• 使用内容安全策略（Content Security Policy）来限制页面中可以执行的脚本内容。

CSRF（跨站请求伪造）: CSRF 攻击是一种利用受害者已经在某个网站进行身份验证的情况下，通过伪造请求来执行非授权操作的攻击方式。攻击者诱导受害者访问恶意网站，当受害者在另一个网站上进行操作时，攻击者可以发送伪造的请求来执行攻击。

避免方式：

• 使用 CSRF 令牌（CSRF Token）来验证请求的合法性，确保请求来源于合法的网站。
• 对于敏感操作，要求用户进行二次身份验证，如输入密码。
• 限制跨域请求的权限，使用同源策略或其他安全机制。

DDoS（分布式拒绝服务攻击）: DDoS 攻击旨在通过同时向目标服务器发送大量请求，占用其带宽、资源或服务能力，使其无法正常提供服务。攻击者通常使用大量的僵尸计算机或恶意软件来发起攻击，使得服务器过载或崩溃。

避免方式：

• 使用防火墙、入侵检测系统和负载均衡器等安全设备和技术，以过滤和抵御 DDoS 攻击。
• 在网络架构中使用流量限制、访问控制和过滤规则等措施，以减轻攻击的影响。
• 与云服务提供商合作，利用其分布式网络和防御机制来缓解 DDoS 攻击。

需要注意的是，上述的避免方式只是一些常见的防御措施，具体的安全防护策略应根据具体情况和应用程序的需求来制定，同时及时更新和修补系统漏洞也是非常重要的安全实践。

什么是同源策略

同源策略（Same-Origin Policy）是一种浏览器安全机制，用于限制来自不同源（origin）的网页之间的交互。同源指的是协议（protocol），域名（domain）和端口（port）完全相同。

同源策略的目的是保护用户的信息安全，防止恶意网站通过脚本等方式访问或操作其他网站的数据。通过同源策略，浏览器确保网页只能与同一源的资源进行交互，限制了来自不同源的跨域请求。

同源策略的限制包括以下几个方面：

1. DOM 限制: 不同源的网页不能访问彼此的 DOM（Document Object Model）结构，即无法通过 JavaScript 脚本获取或修改其他网页的 DOM 元素。
2. Cookie 限制: 浏览器在发送跨域请求时，不会自动携带其他域下的 Cookie 信息，保护用户的身份认证信息。
3. Ajax 限制: 使用 XMLHttpRequest 或 Fetch API 等技术发送的 Ajax 请求受到同源策略的限制，只能向同一源的服务器发送请求。
4. 跨窗口通信限制: 不同源的窗口之间无法直接通信，如通过 Window.postMessage()方法进行跨窗口消息传递。

为了实现跨域数据交互，可以使用一些特殊的技术手段，如跨域资源共享（CORS）、JSONP、代理服务器等，这些方法在遵循同源策略的同时提供了合理的跨域交互方式。

需要注意的是，同源策略是由浏览器实施的安全机制，不是由服务器控制的。服务器可以通过设置适当的响应头（如 Access-Control-Allow-Origin）来允许跨域请求，但浏览器会先检查同源策略，如果不满足同源要求，仍然会阻止跨域请求。

前后端如何通信

前端和后端之间可以通过不同的方式进行通信。以下是几种常见的前后端通信方式：

1. HTTP 请求: HTTP 是前后端通信最常用的方式之一。前端通过发送 HTTP 请求（如 GET、POST 等）到后端的 API 接口，后端根据请求进行处理，并返回相应的数据或状态码给前端。前端可以使用浏览器内置的XMLHttpRequest对象或现代框架提供的fetch函数来发送 HTTP 请求。

2. AJAX: AJAX（Asynchronous JavaScript and XML）是一种利用 JavaScript 进行异步通信的技术。通过 AJAX，前端可以在不刷新整个页面的情况下，向后端发送 HTTP 请求，并在收到响应后更新页面的部分内容。常见的 AJAX 库包括 jQuery 的$.ajax和 Axios 等。

3. WebSocket: WebSocket 是一种在浏览器和服务器之间建立持久化连接的通信协议。它允许双向通信，使得服务器可以主动向前端推送数据，而不需要前端不断发送请求。前端可以使用WebSocket对象进行 WebSocket 通信，后端需要实现 WebSocket 服务器来处理连接和消息。

4. GraphQL: GraphQL 是一种由 Facebook 开发的数据查询和操作语言。它提供了一种灵活的方式，前端可以通过定义自己所需的数据结构和查询来向后端请求数据，从而减少了不必要的数据传输和多次请求。后端需要实现 GraphQL 服务器来解析查询并返回相应的数据。

5. 消息队列: 消息队列是一种异步通信的方式，通过消息中间件来实现前后端之间的解耦和异步处理。前端可以将消息发送到消息队列中，后端通过订阅消息队列来接收并处理消息。常见的消息队列系统包括 RabbitMQ、Apache Kafka 等。

需要根据具体的应用场景和需求来选择合适的通信方式。通常情况下，前端通过 HTTP 请求与后端进行数据交互，而其他方式如 AJAX、WebSocket 和 GraphQL 等可以用于更复杂的交互和实时通信需求。

get/post 请求传参长度有什么特点

GET 和 POST 请求的传参长度都有一定的特点。

1. GET 请求传参长度特点： GET 请求将参数附加在 URL 的查询字符串中，形如http://example.com/path?param1=value1&param2=value2。传参长度在实践中受到浏览器和服务器的限制，常见的约束如下：

• 浏览器限制： 不同浏览器对 URL 长度的限制不同，通常在 2,048 个字符左右。超过限制长度的 URL 可能会被浏览器截断或拒绝发送。
• 服务器限制： 服务器也可能对 URL 长度进行限制，具体限制取决于服务器软件和配置。常见的限制如 4,096 个字符或更多。

2. POST 请求传参长度特点： POST 请求将参数放在请求的请求体中，不像 GET 请求的参数暴露在 URL 中。传参长度受到服务器的限制，但与 URL 长度无关。一般来说，POST 请求没有明确的规定传参长度的限制，但服务器可能会对请求体的大小进行限制，以确保性能和安全性。服务器软件、配置和后端框架都可能对请求体大小设置有限制。

需要注意的是，虽然 HTTP 协议本身没有对 GET 和 POST 请求的传参长度做出具体规定，但实际应用中，浏览器和服务器都可能对传参长度进行限制。超过限制长度可能导致数据丢失、截断或请求被拒绝。如果需要传递大量数据或超过限制长度，应该考虑使用其他方法，如 POST 请求中的 multipart/form-data 或使用 AJAX 进行数据传输。

综上所述，GET 和 POST 请求的传参长度受到浏览器和服务器的限制，GET 请求受到 URL 长度的限制，而 POST 请求受到请求体大小的限制。在实际开发中，应该注意传参长度的限制，并根据需求选择适当的传输方式和数据处理方式。

TCP/IP / 如何保证数据包传输的有序可靠？

TCP/IP（Transmission Control Protocol/Internet Protocol）是一组网络协议，其中 TCP（传输控制协议）是一种面向连接的可靠传输协议。TCP 通过以下机制来保证数据包传输的有序可靠性：

1. 序列号和确认应答： TCP 使用序列号对发送的数据包进行编号，接收方通过确认应答来确认收到的数据包。序列号和确认应答机制使发送方能够知道哪些数据包已经成功传输，哪些需要重传。

2. 流量控制： TCP 使用滑动窗口机制来控制发送方发送数据的速率，以适应接收方的处理能力。接收方通过通告窗口大小来告知发送方可以接收的数据量，从而避免发送方发送过多数据导致接收方溢出。

3. 拥塞控制： TCP 通过拥塞窗口来控制网络中的拥塞情况。发送方根据网络的拥塞程度动态调整发送速率，以避免网络拥塞和数据丢失。拥塞控制算法包括慢启动、拥塞避免和快速重传等，它们共同协作来维护网络的稳定性和可靠性。

4. 超时重传： TCP 设置了一个定时器，如果发送方在一定时间内没有收到确认应答，就认为数据包丢失，触发重传机制。超时重传确保了即使网络中的数据包丢失，发送方仍能重新发送丢失的数据包，保证数据的完整传输。

5. 连接管理： TCP 使用三次握手和四次挥手的机制来建立和终止连接。这些握手和挥手过程中的消息交互保证了双方的同步，确保数据的可靠传输。

通过上述机制，TCP 提供了可靠的数据传输，保证了数据包的有序性和完整性。它是基于这些机制的可靠性保证，使得 TCP 成为互联网上最常用的传输协议之一。

粘包问题分析与对策

粘包问题是在网络通信中常见的一个问题，它指的是发送方在发送数据时，多个数据包被接收方合并成一个大的数据包，或者一个数据包被拆分成多个小的数据包接收。这种情况下，接收方可能无法正确解析数据，导致数据处理错误。

粘包问题的原因：

1. TCP 协议的特性： TCP 是面向流的协议，它将应用层提供的数据流切割成适当大小的数据块，然后将这些数据块封装成 TCP 数据包进行传输。由于 TCP 的数据传输是基于字节流的，因此无法保证应用层的数据包边界与 TCP 数据包边界的对齐。
2. 发送方连续发送导致合并： 如果发送方连续发送多个小的数据包，接收方可能会将它们合并成一个大的数据包进行接收和处理。
3. 网络传输延迟导致拆分： 在网络传输中，由于网络延迟等因素，一个数据包可能会被拆分成多个小的数据包进行传输，接收方在接收时会将它们拼接成一个完整的数据包。

粘包问题的对策：

1. 消息边界标识： 在应用层协议中，可以在数据包中添加特定的标识符来表示消息的边界，接收方根据这个标识符来正确解析和处理数据。常用的标识符可以是特殊字符、长度字段等。
2. 固定长度消息： 在应用层协议中，可以规定每个数据包的固定长度，发送方按照固定长度切分数据，接收方按照固定长度进行接收和处理。
3. 消息头部包含长度信息： 在应用层协议中，可以在消息的头部添加表示消息长度的字段，接收方先读取长度信息，然后根据长度读取对应长度的数据，以确保数据的正确解析。
4. 使用分隔符： 在数据包中使用特定的分隔符来标识消息的边界，接收方根据分隔符将数据包拆分成独立的消息进行处理。
5. 使用应用层协议： 使用应用层协议（如 HTTP、WebSocket）来处理数据包，这些协议已经解决了粘包问题，并提供了消息的边界标识和解析机制。

选择适当的对策取决于具体的应用场景和需求。在设计通信协议时，需要考虑到粘包问题，并采取相应的对策来确保数据的正确解析和处理。

介绍下 304 过程

HTTP 304 Not Modified 是一种服务器响应状态码，用于告知客户端请求的资源自上次请求后并未发生变化，无需重新传输整个资源。

下面是 HTTP 304 的基本过程：

1. 客户端发送一个 GET 请求到服务器，请求获取某个资源。
2. 服务器接收到请求后，检查请求中的条件，包括请求头中的 If-Modified-Since 和 If-None-Match 字段。
   • If-Modified-Since 表示自从指定日期时间后资源是否有修改。
   • If-None-Match 是一个与资源相关的实体标签（ETag），用于比较资源的新旧版本。
3. 服务器根据请求中的条件进行判断：
   • 如果服务器上的资源自上次请求后没有修改，且满足 If-Modified-Since 和 If-None-Match 的条件，服务器将返回一个 HTTP 304 Not Modified 响应。
   • 如果服务器上的资源发生修改，或者不满足 If-Modified-Since 和 If-None-Match 的条件，服务器将返回资源的新版本，包括响应头中的 Last-Modified 和 ETag 字段。
4. 客户端接收到 HTTP 304 响应后，可以从本地缓存中获取之前请求的资源，无需重新下载整个资源。
   • 客户端会检查自己本地缓存的资源的 Last-Modified 和 ETag 值，与服务器响应中的对应字段进行比较。
   • 如果匹配，客户端可以使用本地缓存的资源。
   • 如果不匹配，客户端需要发送新的请求，获取服务器上的更新资源。

通过 HTTP 304 Not Modified 响应，服务器可以减少不必要的网络传输和服务器负载，提高性能和效率。客户端可以利用缓存机制，避免重复下载未发生变化的资源，加快页面加载速度和减少带宽消耗。

一个 tcp 连接能发几个 http 请求？

如果是 HTTP 1.0 版本协议，一般情况下，不支持长连接，因此在每次请求发送完毕之后，TCP 连接即会断开，因此一个 TCP 发送一个 HTTP 请求，但是有一种情况可以将一条 TCP 连接保持在活跃状态，那就是通过 Connection 和 Keep-Alive 首部，在请求头带上 Connection: Keep-Alive，并且可以通过 Keep-Alive 通用首部中指定的，用逗号分隔的选项调节 keep-alive 的行为，如果客户端和服务端都支持，那么其实也可以发送多条，不过此方式也有限制，可以关注《HTTP 权威指南》4.5.5 节对于 Keep-Alive 连接的限制和规则。 而如果是 HTTP 1.1 版本协议，支持了长连接，因此只要 TCP 连接不断开，便可以一直发送 HTTP 请求，持续不断，没有上限； 同样，如果是 HTTP 2.0 版本协议，支持多用复用，一个 TCP 连接是可以并发多个 HTTP 请求的，同样也是支持长连接，因此只要不断开 TCP 的连接，HTTP 请求数也是可以没有上限地持续发送

https://juejin.cn/post/6844904097556987917

CDN 服务如何实现网络加速？

内容分发网络（Content Delivery Network，简称 CDN）是一种网络技术，它通过在各地部署节点服务器，将网站的内容分发到最接近用户的节点，从而实现网络加速。以下是 CDN 如何实现网络加速的具体步骤：

1. 内容分发：当你首次请求一个 CDN 上的资源时，CDN 会从源服务器获取该资源，然后将其缓存到最接近你的边缘服务器。这样，当你再次请求该资源时，CDN 可以直接从边缘服务器提供该资源，而无需再次从源服务器获取。

2. 负载均衡：CDN 可以根据各个边缘服务器的负载情况，将请求路由到负载最低的服务器。这样，即使某个服务器出现故障或过载，也不会影响到用户的访问。

3. 路由优化：CDN 还可以优化数据的传输路径。它会选择最快的路径，避开网络拥堵和故障，从而减少数据传输的延迟。

4. 数据压缩：CDN 可以对传输的数据进行压缩，减少数据的大小，从而提高传输速度。

5. 持久连接：CDN 可以使用持久连接（HTTP keep-alive）来减少建立和关闭连接的开销，从而提高数据传输的效率。

通过以上的方式，CDN 能够显著提高网站的加载速度，提升用户的访问体验，同时也能够减轻源服务器的负载。希望这个解释对你有所帮助！

什么是单工、半双工和全双工通信？

在通信系统中，单工、半双工和全双工是描述数据传输方式的术语：

1. 单工通信：数据只能在一个方向上流动，就像收音机一样，你可以接收广播信号，但不能发送信号给广播站。这就是单向通信，也被称为单工通信。

2. 半双工通信：数据可以在两个方向上流动，但不能同时进行。例如，对讲机就是半双工设备，你必须在说话时按下按钮，此时你不能听到对方的声音。只有当你松开按钮，才能听到对方的声音。

3. 全双工通信：数据可以同时在两个方向上流动。例如，电话就是全双工设备，你可以在说话的同时听到对方的声音。

希望这个解释对你有所帮助！

简单描述 HTTP 协议发送一个带域名的 URL 请求的协议传输过程？（DNS、TCP、IP、链路）

当你在浏览器中输入一个 URL 并按下回车键时，会发生以下步骤：

1. 域名解析（DNS）：首先，浏览器需要知道服务器的 IP 地址。它通过 DNS（域名系统）查询来获取这个信息。DNS 服务器会返回与请求的域名对应的 IP 地址。

2. 建立连接（TCP）：一旦浏览器获得了服务器的 IP 地址，它会通过 TCP（传输控制协议）建立一个到服务器的连接。这个过程通常被称为 TCP 握手。

3. 发送 HTTP 请求：连接建立后，浏览器会通过这个连接发送一个 HTTP 请求到服务器。这个请求包含了请求的方法（如 GET 或 POST）、请求的路径（URL 中的部分）以及可能的其他信息（如请求头或请求体）。

4. 服务器处理请求并返回 HTTP 响应：服务器接收到请求后，会处理这个请求，然后返回一个 HTTP 响应。这个响应包含了响应的状态码（如 200 表示成功，404 表示未找到），响应头（包含了一些元信息），以及响应体（通常是请求的资源，如 HTML 页面）。

5. 断开连接（TCP）：一旦服务器发送完响应，它通常会关闭 TCP 连接。然而，如果在 HTTP 响应头中设置了 Connection: keep-alive，那么连接将会保持开启，以便于后续的请求。

6. 浏览器处理响应：最后，浏览器会接收并处理服务器返回的 HTTP 响应。如果响应是一个 HTML 页面，浏览器会解析并渲染这个页面。如果响应是一个重定向（如状态码为 301 或 302），浏览器会发送一个新的请求到重定向的 URL。

以上就是 HTTP 协议发送一个带域名的 URL 请求的协议传输过程。希望这个解释对你有所帮助！

什么是正向代理？什么是反向代理？

正向代理和反向代理都是代理服务器的使用方式，但它们的工作方式和用途有所不同：

1. 正向代理：正向代理位于客户端和原始服务器之间，为一个或多个客户端提供服务。客户端直接向代理服务器发送请求，代理服务器再将请求转发给原始服务器，并将原始服务器的响应返回给客户端。正向代理的一个常见用途是为在内部网络中的客户端提供对互联网的访问。

2. 反向代理：反向代理位于客户端和一组原始服务器之间，为一个或多个原始服务器提供服务。客户端将请求发送到反向代理，反向代理决定将请求转发到哪个原始服务器，并将原始服务器的响应返回给客户端。反向代理的常见用途包括负载均衡、SSL 终端和缓存。

简单来说，正向代理代表的是客户端，反向代理代表的是服务器。希望这个解释对你有所帮助！

Cookie 可以在服务端生成吗？Cookie 在服务端生成后的工作流程是什么样的？

是的，Cookie 可以在服务端生成。当服务端需要在客户端存储一些信息时，就会生成 Cookie。以下是服务端生成 Cookie 后的工作流程：

1. 生成 Cookie：当服务端处理一个请求时，它可以创建一个或多个 Cookie。每个 Cookie 都是一个键值对，可以包含任何服务端希望在客户端存储的信息。

2. 设置 HTTP 响应头：服务端将生成的 Cookie 添加到 HTTP 响应的 Set-Cookie 头部字段中，然后将响应发送给客户端。

3. 客户端存储 Cookie：当客户端收到带有 Set-Cookie 头部字段的 HTTP 响应时，它会将这些 Cookie 存储在本地。存储的方式取决于 Cookie 的属性，例如，如果 Cookie 的 Secure 属性被设置，那么这个 Cookie 只会在 HTTPS 连接中被发送。

4. 发送 Cookie：之后，每当客户端向同一个服务器发送请求时，它都会自动在 HTTP 请求的 Cookie 头部字段中包含所有的 Cookie。这样，服务端就可以读取这些 Cookie，获取到之前存储在客户端的信息。

5. 更新和删除 Cookie：服务端可以通过发送新的 Set-Cookie 头部字段来更新或删除已经存储在客户端的 Cookie。如果新的 Set-Cookie 头部字段中的 Cookie 与已经存储的 Cookie 具有相同的名称，那么已经存储的 Cookie 将会被更新或删除。

以上就是服务端生成 Cookie 后的工作流程。希望这个解释对你有所帮助！

服务端如何生成 Cookie

服务端生成 Cookie 的过程通常涉及以下步骤：

1. 创建 Cookie：服务端首先需要创建一个 Cookie。这通常是在处理用户请求时完成的，例如用户登录时。Cookie 是一个键值对，可以包含任何服务端希望在客户端存储的信息。

2. 设置 Cookie 属性：服务端可以设置 Cookie 的各种属性，如过期时间（Expires 或 Max-Age）、路径（Path）、域（Domain）、安全标志（Secure）和 HttpOnly 标志（HttpOnly）。

3. 发送 Cookie：服务端将创建的 Cookie 添加到 HTTP 响应的 Set-Cookie 头部字段中，然后将响应发送给客户端。客户端收到响应后，会根据 Set-Cookie 头部字段的指示在本地存储 Cookie。

以下是一个简单的示例，展示了在 Node.js 的 Express 框架中如何设置 Cookie：

const express = require("express");
const app = express();

app.get("/", (req, res) => {
    // 设置一个名为 'myCookie' 的 Cookie，值为 'Hello, World!'
    res.cookie("myCookie", "Hello, World!", { maxAge: 900000, httpOnly: true });
    res.send("Cookie has been set");
});

app.listen(3000, () => {
    console.log("Listening on port 3000");
});

在这个示例中，当用户访问应用的根路径（/）时，服务端会设置一个名为 myCookie 的 Cookie，其值为 Hello, World!，并将其发送给客户端。希望这个解释对你有所帮助！

Session、Cookie 的区别和关联？如何进行临时性和永久性的 Session 存储？

Session 和 Cookie 都是用于在客户端和服务端之间保持状态的技术，但它们的工作方式和用途有所不同：

1. Cookie：Cookie 是存储在客户端（通常是浏览器）的小段数据。服务端可以在 HTTP 响应中设置 Cookie，然后客户端会在后续的请求中将这些 Cookie 发送回服务端。Cookie 常用于实现记住我功能、跟踪用户行为等。

2. Session：Session 是存储在服务端的数据，用于跟踪用户的状态。每个用户都有一个唯一的 Session，通常通过一个 Session ID 来标识，这个 Session ID 可以存储在 Cookie 中，也可以通过 URL 参数传递。

关于它们的关联，通常 Session 依赖于 Cookie 来存储 Session ID，从而在多个请求之间跟踪用户。当用户访问应用时，服务端会创建一个 Session，并将 Session ID 存储在 Cookie 中发送给客户端。在后续的请求中，客户端会将这个 Cookie 发送回服务端，服务端通过 Session ID 找到对应的 Session。

关于如何进行临时性和永久性的 Session 存储：

• 临时性 Session 存储：默认情况下，Session 是临时的，也就是说，当用户关闭浏览器时，Session 就会被销毁。这是因为 Session ID 通常存储在会话 Cookie 中，这种 Cookie 不会被持久化到硬盘，而是存储在内存中，当浏览器关闭时，会话 Cookie 就会被删除。

• 永久性 Session 存储：如果你希望 Session 在用户关闭浏览器后仍然存在，你可以将 Session ID 存储在持久化 Cookie 中，这种 Cookie 会被写入到硬盘，直到达到指定的过期时间才会被删除。然后，你需要在服务端将 Session 数据存储在一个持久化的存储系统（如数据库）中，这样即使服务端重启，Session 数据也不会丢失。

希望这个解释对你有所帮助！

设置 Cookie 时候如何防止 XSS 攻击？

在设置 Cookie 时，有几种方法可以帮助防止跨站脚本（XSS）攻击：

1. HttpOnly 标志：在设置 Cookie 时，使用 HttpOnly 标志可以防止 JavaScript 访问 Cookie。这可以防止如果网站受到 XSS 攻击，攻击者通过 JavaScript 读取用户的 Cookie。

document.cookie = "username=John Doe; secure; HttpOnly";

2. Secure 标志：使用 Secure 标志可以确保 Cookie 只通过 HTTPS 连接发送，这可以防止 Cookie 在网络上被拦截。

document.cookie = "username=John Doe; secure";

3. SameSite 属性：SameSite 属性可以防止跨站请求伪造（CSRF）攻击，它允许服务器决定是否应该发送 Cookie。如果设置为 Strict，则只有在请求来自同一站点时才会发送 Cookie。

document.cookie = "username=John Doe; SameSite=Strict";

4. 内容安全策略（CSP）：CSP 是一种安全机制，它可以帮助防止某些类型的攻击，包括 XSS 和数据注入攻击。

Content-Security-Policy: default-src 'self'

请注意，尽管这些措施可以提高安全性，但没有任何一种方法可以完全防止所有的攻击，因此，始终需要保持警惕，定期更新和修补系统。希望这些信息对您有所帮助！

简单描述一下用户免登陆的实现过程？可能会出现哪些安全性问题？一般如何对用户登录的密码进行加密？

用户免登录的实现过程通常涉及到以下几个步骤：

1. 用户首次登录：用户首次登录时，服务器会验证用户的用户名和密码。如果验证成功，服务器会生成一个唯一的令牌（Token）。

2. 发送令牌：服务器将令牌发送给用户的浏览器，并将其存储在 Cookie 中。

3. 免登录：当用户再次访问网站时，浏览器会自动发送存储的令牌。服务器验证令牌，如果验证成功，用户就可以免登录直接访问网站。

然而，这种方法可能会出现以下安全性问题：

• 令牌被盗用：如果攻击者能够以某种方式获取令牌，他们就可以伪装成用户访问网站。
• 令牌过期：为了安全，令牌应该有一个过期时间。但是，这意味着用户可能需要定期登录，这可能不符合“免登录”的目标。

对于用户登录的密码加密，一般采用以下步骤：

1. 盐值：生成一个随机的字符串，称为盐值（Salt）。盐值是为了防止彩虹表攻击，即使两个用户的密码相同，由于盐值的存在，他们的哈希值也会不同。

2. 哈希：将用户的密码和盐值一起进行哈希处理，生成一个哈希值。

3. 存储：将哈希值和盐值一起存储在数据库中。当用户登录时，服务器会重新计算哈希值，并与存储的哈希值进行比较。

这种方法可以有效地保护用户密码，即使数据库被泄露，攻击者也无法直接获取用户的原始密码。但是，无论采用何种方法，都需要定期更新和修补系统，以防止新的安全威胁。希望这些信息对您有所帮助！

HTTP 中提升传输速率的方式有哪些？常用的内容编码方式有哪些？

在 HTTP 中，有几种常用的方法可以提升传输速率：

1. 启用压缩：通过使用如 GZIP 或 Brotli 等内容编码方式，可以显著减少传输的数据量，从而提高传输速率。

2. 使用 HTTP/2：HTTP/2 引入了多路复用，允许在单个 TCP 连接上并行交换多个请求和响应消息，从而提高传输速率。

3. 使用 CDN：内容分发网络（CDN）可以将内容缓存到离用户更近的服务器上，从而减少网络延迟。

4. 浏览器缓存：通过设置合适的 HTTP 缓存头，可以使浏览器缓存静态资源，从而减少不必要的网络请求。

5. 减少 HTTP 请求：通过合并文件、内联小资源等方式，可以减少 HTTP 请求的数量，从而提高传输速率。

常用的内容编码方式有：

• GZIP：GZIP 是一种广泛使用的压缩算法，可以显著减少传输的数据量。

• Brotli：Brotli 是一种比 GZIP 更高效的压缩算法，但并非所有浏览器都支持。

• Deflate：Deflate 是一种早期的压缩算法，现在已经很少使用，因为 GZIP 和 Brotli 的效果更好。

希望这些信息对您有所帮助！

传输图片的过程中如果突然中断，如何在恢复后从之前的中断中恢复传输？

在传输图片的过程中，如果突然中断，可以通过以下方式在恢复后从之前的中断点恢复传输：

1. 使用 Range 请求：HTTP/1.1 协议支持 Range 请求，这意味着你可以请求资源的一个特定部分，而不是整个资源。当连接恢复后，你可以发送一个新的请求，请求从上次中断的地方开始的资源部分。

GET /image.jpg HTTP/1.1
Host: example.com
Range: bytes=500-999

这个请求会请求 image.jpg 的第 500 到 999 字节。服务器会返回这部分内容，并在响应头中包含一个 Content-Range 头，指示返回的内容范围和整个资源的大小。

HTTP/1.1 206 Partial Content
Content-Range: bytes 500-999/1234

2. 使用断点续传：很多文件传输协议，如 FTP 和 BitTorrent，都支持断点续传。这意味着如果文件传输被中断，可以在恢复连接后从中断的地方继续传输，而不是重新开始。

3. 使用可恢复的传输协议：一些传输协议，如 TCP，设计为在连接中断后自动恢复。这意味着如果网络连接暂时中断，传输会在连接恢复后自动继续。

请注意，这些方法的可用性取决于服务器和客户端的支持。希望这些信息对您有所帮助！

什么是代理？什么是网关？代理和网关的作用是什么？

代理（Proxy）和网关（Gateway）都是网络中的重要组件，它们在数据传输和网络安全中起着关键的作用。

1. 代理：代理服务器是一个位于客户端和互联网之间的服务器，它的主要功能是接收客户端的请求，并将这些请求转发到互联网上的其他服务器。代理可以用于多种目的，包括：

   • 缓存：代理服务器可以缓存来自互联网的响应，以便在未来更快地提供这些响应。
   • 过滤：代理服务器可以过滤客户端的请求，例如，阻止对特定网站的访问或只允许对特定网站的访问。
   • 负载均衡：在大型系统中，代理服务器可以将请求分发到多个服务器，以平衡负载并提高性能。
   • 隐私和安全：代理服务器可以隐藏客户端的 IP 地址，从而保护客户端的隐私。此外，它还可以提供额外的安全措施，例如，通过使用 HTTPS 来加密数据。

2. 网关：网关是一个网络节点，它作为其他网络的接入点。网关在网络之间传输数据，它将接收到的路由信息翻译成另一种网络协议。网关的主要作用包括：

   • 协议转换：网关可以在不同的网络协议之间进行转换，使得不同的网络可以进行通信。
   • 路由：网关可以决定如何将数据包从源地址发送到目标地址。
   • 安全：网关可以提供防火墙和其他安全功能，以保护网络不受外部威胁。

总的来说，代理主要用于管理内部网络与互联网之间的交互，而网关则用于连接两个不同的网络。希望这些信息对您有所帮助！

HTTPS 相比 HTTP 为什么更加安全可靠？

HTTPS 比 HTTP 更安全，主要是因为 HTTPS 使用了 SSL/TLS 协议，可以提供三重保护：

1. 加密：在客户端和服务器之间传输的数据都会被加密，这样即使数据在传输过程中被拦截，也无法直接查看其内容。
2. 数据完整性：可以检测数据是否在传输过程中被修改。
3. 身份验证：通过证书来验证服务器的身份，并防止 DNS 劫持和网络钓鱼。

因此，HTTPS 能有效防止 "中间人攻击"，保护信息在 Internet 中传输的安全。这就是为什么越来越多的网站正在采用 HTTPS 协议。希望这个解释对你有所帮助！

什么是对称密钥（共享密钥）加密？什么是非对称密钥（公开密钥）加密？哪个更加安全？

对称密钥加密和非对称密钥加密是两种主要的加密方法，它们在安全性和效率上各有优势。

1. 对称密钥加密：在这种加密方法中，加密和解密使用的是同一个密钥，也被称为共享密钥。这种方法的优点是加密和解密的速度快，适合于大量数据的加密。然而，密钥的分发和管理可能会带来安全风险，因为如果密钥在传输过程中被拦截，那么加密的数据就可能被破解。常见的对称密钥加密算法包括 DES、AES 等。

2. 非对称密钥加密：这种加密方法使用一对密钥，一个用于加密，另一个用于解密。这两个密钥中的一个是公开的（公钥），另一个是私有的（私钥）。公钥用于加密数据，私钥用于解密数据。这种方法的优点是安全性更高，因为即使公钥被其他人获取，没有私钥也无法解密数据。然而，非对称加密的速度相比对称加密要慢，所以通常只用于加密小量数据或者加密对称密钥。常见的非对称密钥加密算法包括 RSA、ECC 等。

至于哪种方法更安全，这取决于具体的应用场景。在需要加密大量数据的情况下，通常会结合使用这两种方法，即使用非对称加密算法来加密对称加密的密钥，然后使用对称加密来加密数据，这样既能保证安全性，又能保证效率。希望这个解释对你有所帮助！

网站用的是 https 抓包是明文传输，为什么能看到 https 报文的明文？

测试或者开发调试的过程中，经常会进行抓包分析，并且装上抓包工具的证书就能抓取 HTTPS 的数据包并显示。由此就产生了一个疑问，为什么抓包工具装上证书后就能抓到 HTTPS 的包并显示呢？不是说 HTTPS 是加密传输的吗？

今天这篇文章就来探究下上面这个问题，要解释清楚这个问题，我会通过解答以下两个问题来讲述：

1. HTTPS 到底是什么？
2. 抓包工具抓包的原理？

HTTPS 到底是什么

HTTP 作为一种被广泛使用的传输协议，也存在一些的缺点：

1. 无状态（可以通过 Cookie 或 Session 解决）；
2. 明文传输；
3. 不安全；

为了解决 “明文” 和 “不安全” 两个问题，就产生了 HTTPS。HTTPS 不是一种单独的协议，它是由 HTTP + SSL/TLS 组成。

所以要理解 HTTPS 就只需在 HTTP 的基础上理解 SSL/TLS （TLS 是 SSL 的后续版本，现在一般使用 TLS），下面就来了解下 TLS 是什么。

TLS

❝

「传输层安全性协议」（英语：「T」ransport 「L」ayer 「S」ecurity，缩写：「TLS」）及其前身「安全套接层」（英语：「S」ecure 「S」ockets 「L」ayer，缩写：「SSL」）是一种「安全协议」，目的是为互联网通信提供安全及「数据完整性」保障。

❞

TLS 由记录协议、握手协议、警报协议、变更密码规范协议、扩展协议等几个子协议组成，综合使用了对称加密、非对称加密、身份认证等许多密码学前沿技术。

• 「记录协议」 规定 TLS 收发数据的基本单位为：记录。类似 TCP 里的 segment，所有其它子协议都需要通过记录协议发出。
• 「警报协议」 的职责是向对方发出警报信息，类似于 HTTP 里的状态码。
• 「握手协议」 是 TLS 里最复杂的子协议，浏览器和服务器在握手过程中会协商 TLS 版本号、随机数、密码套件等信息，然后交换证书和密钥参数，最终双方协商得到会话密钥，用于后续的混合加密系统。
• 「变更密码规范协议」 用于告知对方，后续的数据都将使用加密传输。

交换密钥的过程为：

1. 客户端发起一个请求给服务器；
2. 服务器生成一对非对称的公钥（pubkey）和私钥（privatekey），然后把公钥附加到一个 CA数字证书 上返回给客户端；
3. 客户端校验该证书是否合法（通过浏览器内置的厂商根证书等手段校验），然后从证书中提取出公钥（pubkey）；
4. 客户端生成一个随机数（key），然后使用公钥（pubkey）对这个随机数进行加密后发送给服务器；
5. 服务器利用私钥（privatekey）对收到的随机数密文进行解密得到 key ;
6. 后续客户端和服务器传输数据使用该 key 进行加密后再传输；

抓包工具抓包的原理

先来看看抓 HTTP 包的原理

1. 首先抓包工具会提供出代理服务，客户端需要连接该代理；
2. 客户端发出 HTTP 请求时，会经过抓包工具的代理，抓包工具将请求的原文进行展示；
3. 抓包工具使用该原文将请求发送给服务器；
4. 服务器返回结果给抓包工具，抓包工具将返回结果进行展示；
5. 抓包工具将服务器返回的结果原样返回给客户端；

抓包工具就相当于个透明的中间人，数据经过的时候它一只手接到数据，然后另一只手把数据传出去。

再来看看 HTTPS 的抓包

这个时候抓包工具对客户端来说相当于服务器，对服务器来说相当于客户端。在这个传输过程中，客户端会以为它就是目标服务器，服务器也会以为它就是请求发起的客户端。

1. 客户端连接抓包工具提供的代理服务；
2. 客户端需要安装抓包工具的根证书；
3. 客户端发出 HTTPS 请求，抓包工具模拟服务器与客户端进行 TLS 握手交换密钥等流程；
4. 抓包工具发送一个 HTTPS 请求给客户端请求的目标服务器，并与目标服务器进行 TLS 握手交换密钥等流程；
5. 客户端使用与抓包工具协定好的密钥加密数据后发送给抓包工具；
6. 抓包工具使用与客户端协定好的密钥解密数据，并将结果进行展示；
7. 抓包工具将解密后的客户端数据，使用与服务器协定好的密钥进行加密后发送给目标服务器；
8. 服务器解密数据后，做对应的逻辑处理，然后将返回结果使用与抓包工具协定好的密钥进行加密发送给抓包工具；
9. 抓包工具将服务器返回的结果，用与服务器协定好的密钥解密，并将结果进行展示；
10. 抓包工具将解密后的服务器返回数据，使用与客户端协定好的密钥进行加密后发送给客户端；
11. 客户端解密数据；

总结

• HTTPS 不是单独的一个协议，它是 HTTP + SSL/TLS 的组合；
• TLS 是传输层安全性协议，它会对传输的 HTTP 数据进行加密，使用非对称加密和对称加密的混合方式；
• 抓包工具的原理就是“伪装“，对客户端伪装成服务器，对服务器伪装成客户端；
• 使用抓包工具抓 HTTPS 包必须要将抓包工具的证书安装到客户端本地，并设置信任；
• HTTPS 数据只是在传输时进行了加密，而抓包工具是接收到数据后再重新加密转发，所以抓包工具抓到的 HTTPS 包可以直接看到明文；

https://www.cnblogs.com/tester-xt/p/13174279.html

你觉得 HTTP 协议目前存在哪些缺点？

HTTP 协议是互联网上广泛使用的协议，但它确实存在一些缺点：

1. 安全性问题：HTTP 本身不提供任何方式来保护数据。传输的数据都是未加密的，也就是说，数据在网络中传输的过程可以被任何人捕获并查看。这就可能导致敏感信息（如密码、信用卡号等）的泄露。

2. 完整性问题：HTTP 不能保证数据的完整性，也就是说，数据在传输过程中可能会被篡改。

3. 无状态性：HTTP 协议无状态性意味着协议对于事务处理没有记忆能力，服务器不知道客户端是什么状态。虽然这样可以减少服务器的 CPU 和内存使用率，但在需要连续处理的应用中，无状态性就显得非常麻烦。

4. 明文传输：HTTP 协议中的信息都是明文传输，客户端和服务器端的信息都是直接发送，没有进行任何形式的加密，这样可能会被恶意用户监听并获得重要信息。

5. 传输速度慢：HTTP 协议在传输数据时，由于其规定每次只能处理一个请求，所以在处理大量请求时，速度会变得非常慢。

以上就是 HTTP 协议的一些主要缺点，这也是为什么现在越来越多的网站选择使用 HTTPS 协议，因为 HTTPS 在 HTTP 的基础上增加了 SSL/TLS 协议，可以对数据进行加密，保证数据的完整性和安全性。希望这个解释对你有所帮助！

304 是什么意思 一般什么场景出现 ，命中强缓存返回什么状态码

HTTP 状态码304表示"Not Modified"。这个状态码通常在以下场景出现：

当客户端发送一个带有If-Modified-Since或If-None-Match头的请求时，服务器会检查这个资源是否在指定的时间之后被修改过。如果没有被修改过，服务器就会返回一个304 Not Modified的响应，告诉客户端可以继续使用缓存的版本。

至于你提到的"命中强缓存"，这通常指的是浏览器直接从自身的缓存中获取资源，而不是向服务器发送请求。当命中强缓存时，浏览器实际上并不会收到服务器的 HTTP 响应，因此也就没有 HTTP 状态码。但是，你可以在浏览器的开发者工具中看到这种情况，它通常被标记为"200 (from cache)"或类似的标记。希望这个解释对你有所帮助！

GET 和 POST 在安全性上有什么区别？

GET 和 POST 是 HTTP 协议中两种常见的请求方法，它们在安全性方面有以下区别：

1. 数据传输位置：GET 请求将参数和数据附加在 URL 的查询字符串中，而 POST 请求将参数和数据包含在请求的正文中。由于 URL 是明文传输的，GET 请求的参数会暴露在 URL 中，可能被网络抓包工具或日志记录器捕获。相比之下，POST 请求的数据在请求正文中传输，相对更安全一些。

2. 数据长度限制：GET 请求对 URL 长度有限制，不同浏览器和服务器都有各自的限制。超过限制可能导致截断或丢失数据。而 POST 请求对数据长度没有固定限制，可以通过设置服务器的配置来允许更大的数据传输。

3. 数据类型：GET 请求的数据类型限制较为简单，主要是通过 URL 参数传递的字符串类型数据。而 POST 请求的数据类型相对灵活，可以通过请求头中的 Content-Type 字段指定不同的数据类型，如 JSON、表单数据、文件上传等。

4. 缓存：根据 HTTP 规范，GET 请求可被缓存，因此在浏览器历史记录、代理服务器等地方可能会留下记录。相比之下，POST 请求默认不会被缓存，因为 POST 请求通常会对资源进行修改或产生副作用。

5. 幂等性：GET 请求是幂等的，即多次请求相同的 URL 和参数，结果应该是一致的，不会对服务器产生副作用。POST 请求通常用于对服务器资源进行修改或创建，因此不是幂等的，多次请求可能会对服务器状态产生影响。

需要注意的是，虽然 POST 请求在某些方面相对于 GET 请求更安全，但安全性的保障不仅仅取决于使用 GET 还是 POST，还涉及其他方面的安全实践，如使用 HTTPS 协议进行加密通信、对用户输入进行验证和过滤、使用防止跨站脚本攻击（XSS）和跨站请求伪造（CSRF）的安全措施等。因此，在实际应用中，综合考虑不同的安全需求和场景，选择合适的请求方法和相应的安全实践是很重要的。

GET 在哪些情况下会有安全性问题？

GET 请求在以下情况下可能存在安全性问题：

1. 参数暴露：GET 请求将参数附加在 URL 的查询字符串中，这意味着参数信息会明文出现在 URL 中。如果参数包含敏感信息（如密码、用户身份验证令牌等），那么它们可能被网络抓包工具、浏览器历史记录或服务器日志记录器记录下来，导致信息泄露的风险。

2. URL 日志记录：服务器通常会记录收到的请求日志，包括 GET 请求的 URL 和参数。如果服务器的访问日志被未经授权的人访问或泄露，那么其中的参数信息也可能被暴露出去。

3. 缓存：GET 请求默认可以被缓存，这意味着响应的内容可能会被浏览器或代理服务器缓存下来。如果缓存的内容包含敏感信息或用户私密数据，那么其他人可能可以通过访问缓存来获取这些信息，尤其是在共享计算机或公共网络环境下。

4. CSRF 攻击：GET 请求容易受到跨站请求伪造（CSRF）攻击。攻击者可以构造一个恶意网页，其中包含对目标网站的 GET 请求，然后诱使受害者访问该网页。如果受害者已经在目标网站进行了身份验证，那么恶意请求将携带受害者的身份验证信息，并可能执行未经授权的操作。

5. 数据长度限制：GET 请求对 URL 长度有限制，不同浏览器和服务器都有各自的限制。如果发送的参数过多或超过限制，可能导致数据被截断或丢失。

综上所述，虽然 GET 请求在某些情况下更容易受到安全性威胁，但这并不意味着 GET 请求本身是不安全的。合理的安全实践和防护措施可以减轻这些风险，例如使用 HTTPS 加密通信、对敏感信息进行加密、避免将敏感信息暴露在 URL 中、实施 CSRF 防护机制等。

随便聊聊 Ajax，聊聊 axios？

当谈到 Ajax 时，它是一种用于在 Web 应用程序中进行异步通信的技术。Ajax 代表"Asynchronous JavaScript and XML"（异步 JavaScript 和 XML），它允许在不刷新整个页面的情况下，通过与服务器进行异步交互，更新部分页面内容。

Ajax 的核心是通过 JavaScript 中的 XMLHttpRequest 对象（或更现代的 Fetch API）发送 HTTP 请求并处理响应。通过 Ajax，可以使用 JavaScript 动态加载数据、向服务器发送数据、响应用户交互等。

而 axios 是一个流行的基于 Promise 的 HTTP 客户端库，用于在浏览器和 Node.js 中进行 HTTP 请求。它是建立在 XMLHttpRequest 对象之上的封装，并提供了一种简洁而强大的方式来进行 HTTP 交互。

axios 具有以下特点和功能：

• 支持 Promise API：axios 基于 Promise 构建，可以使用 async/await 或.then/.catch 等处理异步操作。
• 跨浏览器支持：axios 可以在现代浏览器和 Node.js 环境中使用，提供一致的 API。
• 支持请求和响应拦截：可以在请求发送前和响应返回后拦截和处理请求和响应。
• 支持取消请求：可以取消正在进行的请求，以避免不必要的响应处理。
• 提供请求和响应转换：可以通过自定义转换函数对请求和响应数据进行处理和转换。
• 支持 CSRF 防护：可以轻松配置和使用 CSRF 令牌来防止跨站请求伪造攻击。

使用 axios，您可以轻松地发送各种类型的 HTTP 请求（GET、POST、PUT、DELETE 等），设置请求头、传递参数、处理响应等。它提供了一种简洁且易于使用的方式来处理异步请求，并且具有广泛的社区支持和文档资源。

总结起来，Ajax 是一种用于异步通信的技术，而 axios 是一个流行的基于 Promise 的 HTTP 客户端库，它简化了使用 Ajax 进行 HTTP 请求的过程，并提供了额外的功能和便利性。

axios 库有什么能力？axios 库发请求的之前能做拦截么？

axios 库具有以下能力：

1. 支持浏览器和 Node.js 环境：axios 可以在浏览器和 Node.js 环境中使用，使其具备跨平台的能力。

2. 发送 HTTP 请求：axios 可以发送各种类型的 HTTP 请求，包括 GET、POST、PUT、DELETE 等。

3. Promise 支持：axios 基于 Promise 实现，可以使用 async/await 或.then/.catch 等方式处理异步操作，使得请求和响应处理更加灵活和可读性更强。

4. 请求和响应拦截：axios 提供了请求和响应拦截器的机制，可以在请求发送前和响应返回后对请求和响应进行拦截并进行相关处理。通过拦截器，可以实现对请求头的添加、对请求参数的校验、对响应数据的预处理等操作。

5. 请求取消：axios 支持请求取消的功能，可以通过取消请求来中止正在进行的请求。这对于处理用户取消或避免不必要的请求响应很有用。

6. 请求配置：axios 允许设置请求的各种配置选项，如请求头、超时时间、认证信息、请求数据格式等。这使得请求可以根据具体需求进行自定义配置。

7. 请求和响应转换：axios 提供了请求和响应转换的功能，可以通过自定义转换函数对请求和响应的数据进行处理和转换。例如，可以将请求和响应数据从 JSON 格式转换为其他格式，或者对特定结构的数据进行解析和处理。

8. 错误处理：axios 具有良好的错误处理机制，可以捕获请求过程中的错误，并提供详细的错误信息，方便开发者进行错误处理和调试。

总结起来，axios 是一个功能强大的 HTTP 客户端库，具备发送各种类型的 HTTP 请求、Promise 支持、请求和响应拦截、请求取消、请求配置、请求和响应转换、错误处理等能力。它简化了进行 HTTP 请求的过程，并提供了丰富的功能和灵活性，使得与服务器进行通信变得更加便捷和可控。

关于拦截器的问题，是的，axios 库允许在发出请求之前做拦截。通过使用请求拦截器（axios.interceptors.request），您可以在请求发送之前对请求进行拦截和处理。请求拦截器可以用于添加请求头、修改请求参数、进行身份验证等操作。以下是一个示例：

axios.interceptors.request.use(
    (config) => {
        // 在发送请求之前做一些处理
        config.headers.Authorization = "Bearer token123"; // 添加请求头
        return config;
    },
    (error) => {
        // 处理请求错误
        return Promise.reject(error);
    }
);

在上述示例中，请求拦截器通过axios.interceptors.request.use方法注册，并传入一个处理函数。该处理函数接收一个config对象作为参数，可以对该对象进行修改和处理，然后返回修改后的config对象。如果请求拦截器中出现错误，可以通过返回Promise.reject(error)来处理。

通过请求拦截器，您可以在发出请求之前对请求进行全局的处理和拦截，从而实现对请求的定制和控制。

fetch 和 axios 有什么区别？

Fetch 和 Axios 都是用于进行 HTTP 请求的 JavaScript 库，但它们有一些区别：

1. API 设计和使用体验：Fetch 是浏览器原生提供的 API，而 Axios 是一个第三方库。Fetch 使用起来的 API 较为简洁，使用 Promise 进行异步操作，但它的一些特性需要额外处理（如请求取消、请求超时等）。Axios 则提供了更丰富和易用的 API，支持请求和响应拦截、请求取消、请求配置等功能，使用起来更加便捷和灵活。

2. 兼容性：Fetch 是浏览器原生提供的 API，因此在现代浏览器中具有良好的兼容性。但在一些旧版本浏览器中可能不被完全支持，需要使用 Polyfill 进行兼容处理。Axios 是一个独立的第三方库，它提供了对所有主流浏览器和 Node.js 环境的兼容性支持。

3. 功能和扩展性：Axios 提供了更多的功能和扩展性，例如请求和响应拦截器、请求取消、请求配置、请求和响应转换等。而 Fetch 的功能相对较少，需要通过额外的代码来实现类似的功能。

4. 请求和响应处理：Fetch 使用 Promise 来处理请求和响应，可以使用 async/await 或.then/.catch 等语法进行处理。Axios 也使用 Promise，并提供了更多的辅助方法和选项，使得请求和响应处理更加简洁和灵活。

5. 浏览器和 Node.js 环境：Fetch 是浏览器原生提供的 API，可以在浏览器环境中直接使用。而 Axios 是一个独立的库，可以同时在浏览器和 Node.js 环境中使用，具有更广泛的适用性。

综上所述，Fetch 是浏览器原生的 API，具有较好的兼容性，使用起来简洁，但功能相对较少。Axios 是一个第三方库，提供了更多的功能和扩展性，使用起来更加便捷和灵活，适用于浏览器和 Node.js 环境。选择使用哪个库取决于您的具体需求和项目要求。

fetch 和 axios 如何取消发送请求？

在 Fetch 和 Axios 中，可以通过不同的方式取消发送请求。

对于 Fetch API，您可以使用AbortController和AbortSignal来取消请求。以下是一个使用 Fetch 取消请求的示例：

const controller = new AbortController();
const signal = controller.signal;

fetch(url, { signal })
    .then((response) => {
        // 处理响应
    })
    .catch((error) => {
        if (error.name === "AbortError") {
            // 请求被取消
        } else {
            // 处理其他错误
        }
    });

// 取消请求
controller.abort();

在上述示例中，我们创建了一个AbortController对象，并通过其signal属性将其传递给 Fetch 请求的选项。然后，我们可以通过调用controller.abort()方法来取消请求。

对于 Axios，它提供了一个CancelToken和Cancel机制来取消请求。以下是一个使用 Axios 取消请求的示例：

import axios from "axios";

// 创建一个取消令牌
const source = axios.CancelToken.source();

axios
    .get(url, {
        cancelToken: source.token,
    })
    .then((response) => {
        // 处理响应
    })
    .catch((error) => {
        if (axios.isCancel(error)) {
            // 请求被取消
        } else {
            // 处理其他错误
        }
    });

// 取消请求
source.cancel();

在上述示例中，我们使用axios.CancelToken.source()创建了一个取消令牌对象，并将其作为cancelToken选项传递给 Axios 请求。然后，我们可以调用source.cancel()方法来取消请求。

无论是使用 Fetch 还是 Axios，取消请求的原理都是通过触发一个特定的信号或令牌来中止请求过程。请注意，在取消请求后，您仍然需要适当处理取消的响应或错误，以避免可能出现的问题。

请注意，取消请求是一个在网络请求中常见的需求，但它需要与服务器端配合使用，以确保在取消请求时服务器能够正确处理。当使用取消功能时，请确保服务器端能够正确响应取消请求的信号。

axios 库发请求的之前能做拦截么？

是的，axios 库允许在发送请求之前进行拦截。通过使用请求拦截器（axios.interceptors.request），您可以在请求发送之前对请求进行拦截和处理。

以下是一个使用 axios 请求拦截器的示例：

axios.interceptors.request.use(
    (config) => {
        // 在发送请求之前做一些处理
        config.headers.Authorization = "Bearer token123"; // 添加请求头
        return config;
    },
    (error) => {
        // 处理请求错误
        return Promise.reject(error);
    }
);

在上述示例中，我们使用axios.interceptors.request.use方法注册了一个请求拦截器，并传入一个处理函数。该处理函数接收一个config对象作为参数，可以对该对象进行修改和处理，然后返回修改后的config对象。如果请求拦截器中出现错误，可以通过返回Promise.reject(error)来处理。

通过请求拦截器，您可以在发出请求之前对请求进行全局的处理和拦截，从而实现对请求的定制和控制。您可以在拦截器中进行一系列操作，如添加请求头、修改请求参数、进行身份验证等。这对于在每个请求中应用通用的操作非常有用，同时也可以用于处理请求错误或进行统一的错误处理。

需要注意的是，axios 允许注册多个请求拦截器，它们会按照注册的顺序依次执行。这使得您可以灵活地对请求进行处理，并可以根据需要添加和移除拦截器。

总结起来，axios 库允许在发送请求之前进行拦截，并提供了请求拦截器的机制。通过请求拦截器，您可以对请求进行修改、添加请求头、进行身份验证等操作，从而实现对请求的定制和控制。

axios 库发请求的时候能取消请求么？

是的，axios 库提供了取消请求的机制，您可以使用CancelToken和Cancel来取消正在进行的请求。

以下是一个使用 axios 取消请求的示例：

import axios from "axios";

// 创建一个取消令牌
const source = axios.CancelToken.source();

axios
    .get(url, {
        cancelToken: source.token,
    })
    .then((response) => {
        // 处理响应
    })
    .catch((error) => {
        if (axios.isCancel(error)) {
            console.log("请求被取消:", error.message);
        } else {
            console.log("请求发生错误:", error.message);
        }
    });

// 取消请求
source.cancel("请求被取消");

在上述示例中，我们使用axios.CancelToken.source()创建了一个取消令牌对象，并将其作为cancelToken选项传递给 axios 请求。然后，我们可以调用source.cancel()方法来取消请求，并传递一个可选的取消消息作为参数。

如果请求被取消，Axios 会抛出一个错误，您可以通过axios.isCancel(error)方法来判断错误是否是由取消请求引起的。在捕获到取消错误后，您可以根据需要进行相应的处理。

需要注意的是，取消请求需要与服务器端配合使用。当使用取消功能时，请确保服务器端能够正确响应取消请求的信号，并在接收到取消请求时中止相应的处理。

总结起来，axios 库提供了取消请求的机制，通过使用CancelToken和Cancel，您可以创建取消令牌并在需要取消请求时调用cancel()方法。这使得您可以在需要时中止正在进行的请求，从而更好地控制和管理网络请求。

硬件层和前端是如何做通讯的？

硬件层和前端之间的通讯可以通过多种方式实现，具体取决于硬件设备的类型和前端应用的需求。以下是一些常见的硬件层和前端通讯的方式：

1. API 和驱动程序：某些硬件设备（如摄像头、麦克风等）可能具有特定的 API 和驱动程序，可以在前端应用中使用这些 API 和驱动程序来与硬件进行通讯。通常，硬件供应商会提供相应的文档和软件开发工具包（SDK）来帮助开发者在前端应用中集成和控制硬件设备。

2. WebSocket：WebSocket 是一种在客户端和服务器之间进行双向通讯的协议，可以用于实时传输数据。前端应用可以通过 WebSocket 与特定硬件设备建立连接，并通过发送和接收消息来进行通讯。这种方式适用于需要实时交互和数据传输的场景，例如传感器数据的监控和控制。

3. RESTful API：如果硬件设备提供了网络接口，前端应用可以通过发送 HTTP 请求来与硬件进行通讯。硬件设备暴露出一组 RESTful API，前端应用可以通过 GET、POST、PUT 等 HTTP 方法与设备进行交互，发送指令或获取数据。

4. WebUSB 和 WebBluetooth：WebUSB 和 WebBluetooth 是 Web 标准中的 API，用于在前端应用中访问 USB 和蓝牙设备。这些 API 使得前端应用能够直接与特定的 USB 设备或蓝牙设备进行通讯，发送命令、接收数据等。

5. WebRTC：WebRTC 是一种用于实时音视频通讯的 Web 标准，可以在前端应用中实现与硬件设备的音视频通讯。例如，通过摄像头和麦克风采集音视频数据，并通过 WebRTC 传输到前端应用进行处理或显示。

需要注意的是，不同的硬件设备可能具有不同的通讯方式和协议，因此在与硬件层进行通讯时，您需要了解特定硬件设备的接口和支持的通讯协议，以选择合适的方式进行通讯。此外，一些通讯方式可能需要特定的浏览器支持，您需要在选择通讯方式时考虑浏览器的兼容性和支持情况。

WebSocket 的浏览器兼容性如何处理？

WebSocket 在现代浏览器中得到了广泛的支持，但在处理 WebSocket 的浏览器兼容性时，仍然需要考虑一些因素。

大多数主流的现代浏览器（如 Chrome、Firefox、Safari、Edge）都支持 WebSocket，并且提供了对 WebSocket API 的良好支持。这些浏览器通常遵循最新的 WebSocket 标准，可以稳定地进行 WebSocket 通讯。

然而，对于旧版本的浏览器，特别是 Internet Explorer（IE），WebSocket 的支持可能有限或不完全。以下是一些处理 WebSocket 浏览器兼容性的建议：

1. 检测浏览器支持：在使用 WebSocket 之前，可以通过检测浏览器是否支持 WebSocket 来采取相应的措施。可以使用 JavaScript 代码来检测 WebSocket 对象是否可用，例如：

if ("WebSocket" in window) {
    // 支持WebSocket
} else {
    // 不支持WebSocket
}

2. 使用 Polyfill 库：如果需要在不支持 WebSocket 的浏览器上使用 WebSocket 功能，可以考虑使用 WebSocket Polyfill 库。这些库可以模拟 WebSocket 的行为，并提供与标准 WebSocket API 兼容的接口。一些常用的 WebSocket Polyfill 库包括websocket.js和SockJS等。

3. 考虑使用替代方案：如果使用 WebSocket 在特定浏览器上存在问题或限制，可以考虑使用其他替代方案来实现实时通讯，如长轮询（Long Polling）或 Server-Sent Events（SSE）。这些替代方案在旧版本浏览器上可能更可靠和兼容。

需要注意的是，浏览器兼容性是一个不断变化的领域，新的浏览器版本可能会对 WebSocket 进行改进和修复。因此，在开发过程中，应该密切关注 WebSocket 的最新标准和浏览器的更新，以便及时调整和处理兼容性问题。

最佳的做法是根据您的应用程序的需求和目标受众来决定是否需要考虑旧版本浏览器的兼容性，并选择合适的处理方式来确保在不同浏览器上的稳定运行。

谈谈你对缓存的理解，举一个和你最相关的缓存的使用案例。

缓存是一种用于存储和提供快速访问数据的技术。它通过将计算或获取开销较大的数据或资源保存在高速存储介质中，以便将来可以快速检索和使用，减少对原始数据源的频繁访问，从而提高系统的性能和响应速度。

缓存可以存在于多个层级，包括硬件层（如 CPU 缓存）和软件层（如应用程序级缓存、数据库查询缓存、浏览器缓存等）。不同层级的缓存可以用于不同的目的，例如减少计算时间、加速数据访问、降低网络延迟等。

一个与我最相关的缓存使用案例是 Web 应用程序中的浏览器缓存。浏览器缓存是一种在客户端浏览器中存储和管理静态资源的机制，例如 HTML 页面、CSS 文件、JavaScript 文件、图像等。浏览器缓存可以减少对服务器的请求，加快页面加载速度，提升用户体验。

下面是一个简单的浏览器缓存使用案例：假设有一个网站的首页，它包含大量的静态资源，包括 CSS 文件和图像。在第一次访问首页时，浏览器会下载这些资源并缓存到本地。当用户再次访问同一个页面时，浏览器会先检查缓存，并且如果资源没有过期或被修改，浏览器会直接从缓存中加载资源，而不需要再次向服务器发送请求。这样就可以节省带宽，减少网络延迟，提高页面加载速度。

在这个案例中，浏览器缓存起到了重要的作用，通过减少对服务器的请求，加快了页面加载速度，提供了更好的用户体验。同时，网站开发人员可以通过设置合适的缓存策略（例如设置缓存过期时间、使用版本号控制缓存更新等）来控制缓存的行为，确保在资源更新时能够及时获取最新的版本。

需要注意的是，缓存的使用需要考虑缓存一致性和缓存更新的策略，以确保缓存数据的有效性和及时性。不适当或不正确地使用缓存可能会导致数据不一致或过期的问题。因此，在使用缓存时，需要综合考虑缓存的优势和限制，并根据具体情况进行适当的设计和配置。

服务端推送主要用到什么技术？

服务端推送（Server Push）是一种在客户端和服务器之间实现实时通讯的技术，它允许服务器主动向客户端推送数据，而不需要客户端明确地发送请求。以下是几种常用的技术用于实现服务端推送：

1. WebSocket：WebSocket 是一种在客户端和服务器之间进行双向通讯的协议，它支持持久连接，可以实现实时数据推送。WebSocket 协议在客户端和服务器之间建立长连接，服务器可以随时向客户端发送消息，而不需要客户端发起请求。WebSocket 适用于需要实时性和双向通讯的应用，如聊天应用、实时数据监控等。

2. Server-Sent Events（SSE）：Server-Sent Events 是一种基于 HTTP 的服务端推送技术，它允许服务器通过 HTTP 连接向客户端推送数据。SSE 使用了一种被称为"EventStream"的格式，服务器可以发送一系列的事件消息给客户端，客户端通过监听事件来接收数据。SSE 适用于单向的实时通知场景，如实时新闻、实时股票行情等。

3. Long Polling：Long Polling（长轮询）是一种模拟实时通讯的技术，在客户端发起请求后，服务器会保持连接打开，并在有新数据时立即返回响应，否则等待一段时间后返回响应。客户端在收到响应后立即再次发起请求，以保持连接。通过不断发起轮询请求，可以实现实时数据推送的效果。Long Polling 适用于旧版浏览器或不支持 WebSocket 的环境。

4. Pusher：Pusher 是一个托管的实时消息服务提供商，它提供了简化实时通讯的 API 和基础设施。Pusher 使用 WebSocket 和其他技术来实现实时消息传输和推送，开发者可以通过 Pusher 的 API 在应用程序中实现实时通讯功能。

这些技术都可以用于服务端推送，每种技术都有自己的特点和适用场景。选择合适的技术取决于您的应用需求、客户端和服务器的支持情况以及您对实时性、可扩展性和兼容性的要求。

HTTP 2 相对于 HTTP 1 有什么区别？

HTTP/2（简称为 HTTP2）是 HTTP 协议的最新版本，与 HTTP/1（即 HTTP 1.1）相比，它引入了一些重要的改进和特性，以提升性能和效率。以下是 HTTP/2 相对于 HTTP/1 的主要区别：

1. 多路复用（Multiplexing）：HTTP/2 引入了多路复用的机制，允许在同一个 TCP 连接上同时发送多个请求和响应。在 HTTP/1 中，每个请求都需要建立独立的连接，导致了连接的开销和延迟。多路复用可以减少连接的数量，提高资源利用率和响应速度。

2. 二进制分帧（Binary Framing）：HTTP/2 将数据分解为二进制的帧，并对它们进行传输和解析。这种二进制分帧的方式更高效，可以更好地利用网络的带宽。此外，二进制格式还使得协议更容易扩展和优化。

3. 首部压缩（Header Compression）：HTTP/2 使用了一种称为 HPACK 的首部压缩算法，可以减少请求和响应的头部大小。在 HTTP/1 中，每个请求和响应都需要携带大量的头部信息，导致了额外的数据传输和延迟。通过首部压缩，HTTP/2 可以减少需要传输的数据量，提高性能。

4. 服务器推送（Server Push）：HTTP/2 支持服务器主动推送数据到客户端，而不需要客户端明确地请求。当服务器识别到客户端可能需要某些资源时，它可以主动将这些资源推送给客户端，减少了额外的请求延迟。

5. 流量控制（Flow Control）：HTTP/2 引入了流量控制机制，可以在不同的流（streams）之间进行优先级和资源分配的管理，以防止某些流占用过多的带宽导致其他流受到影响。

这些改进使得 HTTP/2 在性能和效率方面相较于 HTTP/1 有显著的提升。它可以减少延迟、提高吞吐量，并改善了网络上的资源利用率。需要注意的是，HTTP/2 主要在协议层面进行了改进，而应用程序和开发者通常无需做太多改动，现有的 HTTP 应用程序可以在 HTTP/2 上运行，而且通常会获得性能上的提升。

WebSokect 本质上是基于什么协议进行通信的（TCP / UDP）？

WebSocket 本质上是基于 TCP 协议进行通信的。

WebSocket 是一种在客户端和服务器之间实现双向通信的协议。它通过在客户端和服务器之间建立一条持久的、全双工的通信通道，允许双方实时地交换数据。WebSocket 协议使用的底层传输协议是 TCP。

TCP（传输控制协议）是一种可靠的、面向连接的协议，它提供了数据传输的可靠性和顺序性。TCP 建立了一个持久的双向通信通道，并确保数据的可靠传输，具有流量控制和拥塞控制等机制，在网络不稳定的情况下仍能保证数据的完整性和可靠性。

WebSocket 协议在建立连接时使用 HTTP/HTTPS 协议进行握手，之后通过协商转换为 WebSocket 连接。一旦 WebSocket 连接建立成功，双方就可以在该连接上进行双向通信，发送和接收数据，而无需重复的握手过程。这种持久的连接能够有效地减少通信的延迟和开销，使得实时通信更加高效和可靠。

总结起来，WebSocket 协议是一种基于 TCP 的双向通信协议，它利用 TCP 提供的可靠性和顺序性特性，实现了实时通信和数据交换。相比于传统的 HTTP 请求-响应模式，WebSocket 提供了更低的延迟和更高的性能，适用于需要实时通信和即时数据更新的应用场景。

了解跨域么，一般什么情况下会导致跨域？

是的，我了解跨域问题。跨域指的是在浏览器中运行的 JavaScript 代码试图访问不同源（Origin）的资源时所产生的限制。同源策略（Same-Origin Policy）是浏览器的一种安全机制，它限制了不同源之间的交互，以防止恶意的跨站点脚本攻击。

在默认情况下，以下情况会导致跨域问题：

1. 协议不同：当 JavaScript 代码从一个协议（如 http://）加载页面，然后尝试与另一个协议（如 https://）交互时会发生跨域。

2. 域名不同：当 JavaScript 代码从一个域名加载页面，然后尝试与另一个域名交互时会发生跨域。例如，从example.com加载的页面尝试访问api.example.com上的资源。

3. 端口不同：当 JavaScript 代码从一个端口加载页面，然后尝试与另一个端口交互时会发生跨域。例如，从example.com:8080加载的页面尝试访问example.com:3000上的资源。

4. 子域名不同：当 JavaScript 代码从一个子域名加载页面，然后尝试与另一个子域名交互时会发生跨域。例如，从app.example.com加载的页面尝试访问api.example.com上的资源。

为了克服跨域限制，可以采取以下方法：

1. JSONP：通过动态创建<script>标签来加载跨域的 JavaScript 文件。由于<script>标签不受同源策略限制，因此可以通过回调函数来获取跨域资源的数据。

2. CORS（跨域资源共享）：在服务器端设置响应头，允许特定的域名访问资源。使用 CORS，服务器可以在响应中添加Access-Control-Allow-Origin头来指定允许访问的域名。

3. 代理服务器：在服务器端设置一个代理，将前端请求转发到目标服务器。前端通过访问同源的代理服务器来获取跨域资源。

4. WebSocket：通过 WebSocket 协议进行双向通信，WebSocket 不受同源策略的限制，可以在不同源之间进行实时通信。

需要注意的是，跨域问题只存在于浏览器环境中，而在服务器端则没有跨域限制。

cookie 和 session 的区别？

Cookie 和 Session 是用于在 Web 应用中跟踪用户状态和实现用户认证的机制，它们有一些区别和不同的用途。

Cookie 是在客户端（浏览器）存储的小型文本文件，由服务器通过响应头的 Set-Cookie 字段发送给客户端，并由客户端在后续请求中通过 Cookie 头将该文件发送回服务器。Cookie 主要用于在客户端存储用户的状态信息，包括身份认证、会话标识、个性化设置等。它们可以设置过期时间，可以是会话级别的（浏览器关闭后即失效）或长期有效的（在指定的过期时间之前有效）。Cookie 存储在客户端，因此可以在不同的页面和浏览器会话中共享。

Session 是在服务器端存储的用户数据对象。当用户首次访问服务器时，服务器会为该用户创建一个唯一的会话标识符（Session ID），并将该标识符存储在 Cookie 中（通常被称为 Session Cookie）或通过 URL 重写传递给客户端。客户端在后续请求中使用该标识符来识别自己的会话，并且服务器使用该标识符来检索和存储与该用户相关的数据。Session 可以存储任意类型的数据，包括用户信息、购物车内容、访问权限等。Session 数据存储在服务器端，相对于 Cookie 更安全，用户无法直接修改或访问其中的数据。

主要区别如下：

1. 存储位置：Cookie 存储在客户端（浏览器），Session 存储在服务器端。

2. 数据安全性：由于 Cookie 存储在客户端，可能受到篡改和窃取的风险。而 Session 数据存储在服务器端，相对更安全。

3. 存储容量：Cookie 的存储容量较小，通常限制在几 KB，而 Session 可以存储更大的数据，不受容量限制。

4. 有效期：Cookie 可以设置过期时间，可以是会话级别的或长期有效的。Session 通常存在于用户活动期间，当用户关闭浏览器或超过超时时间时会话结束。

5. 跨域支持：Cookie 可以设置为跨域共享，被多个域名访问。而 Session 通常与单个域名关联。

在实际应用中，Cookie 和 Session 通常是结合使用的。服务器使用 Session 来维护用户状态和存储敏感信息，而将 Session ID 存储在 Cookie 中，以便在每个请求中进行识别。这样可以同时享受 Cookie 的便利性和 Session 的安全性。

什么是 CDN

全称 Content Delivery Network, 即内容分发网络。

摘录一个形象的比喻, 来理解 CDN 是什么。

10 年前，还没有火车票代售点一说，12306.cn 更是无从说起。那时候火车票还只能在火车站的售票大厅购买，而我所在的小县城并不通火车，火车票都要去市里的火车站购买，而从我家到县城再到市里，来回就是 4 个小时车程，简直就是浪费生命。后来就好了，小县城里出现了火车票代售点，甚至乡镇上也有了代售点，可以直接在代售点购买火车票，方便了不少，全市人民再也不用在一个点苦逼的排队买票了。

简单的理解 CDN 就是这些代售点 (缓存服务器) 的承包商, 他为买票者提供了便利, 帮助他们在最近的地方 (最近的 CDN 节点) 用最短的时间 (最短的请求时间) 买到票(拿到资源), 这样去火车站售票大厅排队的人也就少了。也就减轻了售票大厅的压力(起到分流作用, 减轻服务器负载压力)。

用户在浏览网站的时候，CDN 会选择一个离用户最近的 CDN 边缘节点来响应用户的请求，这样海南移动用户的请求就不会千里迢迢跑到北京电信机房的服务器（假设源站部署在北京电信机房）上了。

CDN 缓存 关于 CDN 缓存, 在浏览器本地缓存失效后, 浏览器会向 CDN 边缘节点发起请求。类似浏览器缓存, CDN 边缘节点也存在着一套缓存机制。CDN 边缘节点缓存策略因服务商不同而不同，但一般都会遵循 http 标准协议，通过 http 响应头中的

Cache-control: max-age //后面会提到 的字段来设置 CDN 边缘节点数据缓存时间。

当浏览器向 CDN 节点请求数据时，CDN 节点会判断缓存数据是否过期，若缓存数据并没有过期，则直接将缓存数据返回给客户端；否则，CDN 节点就会向服务器发出回源请求，从服务器拉取最新数据，更新本地缓存，并将最新数据返回给客户端。 CDN 服务商一般会提供基于文件后缀、目录多个维度来指定 CDN 缓存时间，为用户提供更精细化的缓存管理。

CDN 优势 CDN 节点解决了跨运营商和跨地域访问的问题，访问延时大大降低。 大部分请求在 CDN 边缘节点完成，CDN 起到了分流作用，减轻了源服务器的负载。

HTTP 请求的方式，HEAD 方式

参考回答：

head：类似于 get 请求，只不过返回的响应中没有具体的内容，用户获取报头

options：允许客户端查看服务器的性能，比如说服务器支持的请求方式等等。

一个图片 url 访问后直接下载怎样实现？

请求的返回头里面，用于浏览器解析的重要参数就是 OSS 的 API 文档里面的返回 http 头，决定用户下载行为的参数。

下载的情况下：
1. x-oss-object-type:
Normal
2. x-oss-request-id:
598D5ED34F29D01FE2925F41
3. x-oss-storage-class:
Standard

http 常用请求头

协议头	说明
Accept	可接受的响应内容类型（Content-Types）。
Accept-Charset	可接受的字符集
Accept-Encoding	可接受的响应内容的编码方式。
Accept-Language	可接受的响应内容语言列表。
Accept-Datetime	可接受的按照时间来表示的响应内容版本
Authorization	用于表示 HTTP 协议中需要认证资源的认证信息
Cache-Control	用来指定当前的请求/回复中的，是否使用缓存机制。
Connection	客户端（浏览器）想要优先使用的连接类型
Cookie	由之前服务器通过 Set-Cookie（见下文）设置的一个 HTTP 协议 Cookie
Content-Length	以 8 进制表示的请求体的长度
Content-MD5	请求体的内容的二进制 MD5 散列值（数字签名），以 Base64 编码的结果
Content-Type	请求体的 MIME 类型（用于 POST 和 PUT 请求中）
Date	发送该消息的日期和时间（以 RFC 7231 中定义的"HTTP 日期"格式来发送）
Expect	表示客户端要求服务器做出特定的行为
From	发起此请求的用户的邮件地址
Host	表示服务器的域名以及服务器所监听的端口号。如果所请求的端口是对应的服务的标准端口（80），则端口号可以省略。
If-Match	仅当客户端提供的实体与服务器上对应的实体相匹配时，才进行对应的操作。主要用于像 PUT 这样的方法中，仅当从用户上次更新某个资源后，该资源未被修改的情况下，才更新该资源。
If-Modified-Since	允许在对应的资源未被修改的情况下返回 304 未修改
If-None-Match	允许在对应的内容未被修改的情况下返回 304 未修改（ 304 NotModified ），参考超文本传输协议的实体标记
If-Range	如果该实体未被修改过，则向返回所缺少的那一个或多个部分。否则，返回整个新的实体
If-Unmodified-Since	仅当该实体自某个特定时间以来未被修改的情况下，才发送回应。
Max-Forwards	限制该消息可被代理及网关转发的次数。
Origin	发起一个针对跨域资源共享的请求（该请求要求服务器在响应中加入一个 Access-Control-Allow-Origin 的消息头，表示访问控制所允许的来源）。
Pragma	与具体的实现相关，这些字段可能在请求/回应链中的任何时候产生。
Proxy-Authorization	用于向代理进行认证的认证信息。
Range	表示请求某个实体的一部分，字节偏移以 0 开始。
Referer	表示浏览器所访问的前一个页面，可以认为是之前访问页面的链接将浏览器带到了当前页面。Referer 其实是 Referrer 这个单词，但 RFC 制作标准时给拼错了，后来也就将错就错使用 Referer 了。
TE	浏览器预期接受的传输时的编码方式：可使用回应协议头
Transfer-Encoding	中的值（还可以使用"trailers"表示数据传输时的分块方式）用来表示浏览器希望在最后一个大小为 0 的块之后还接收到一些额外的字段。
User-Agent	浏览器的身份标识字符串
Upgrade	要求服务器升级到一个高版本协议。
Via	告诉服务器，这个请求是由哪些代理发出的。
Warning	一个一般性的警告，表示在实体内容体中可能存在错误。

强缓存、协商缓存什么时候用哪个

因为服务器上的资源不是一直固定不变的，大多数情况下它会更新，这个时候如果我们还访问本地缓存，那么对用户来说，那就相当于资源没有更新，用户看到的还是旧的资源；所以我们希望服务器上的资源更新了浏览器就请求新的资源，没有更新就使用本地的缓存，以最大程度的减少因网络请求而产生的资源浪费。

讲讲 304

304：如果客户端发送了一个带条件的 GET 请求且该请求已被允许，而文档的内容（自上次访问以来或者根据请求的条件）并没有改变，则服务器应当返回这个 304 状态码。

301 和 302 的区别

参考回答：

• 301 Moved Permanently 被请求的资源已永久移动到新位置，并且将来任何对此资源的引用都应该使用本响应返回的若干个 URI 之一。如果可能，拥有链接编辑功能的客户端应当自动把请求的地址修改为从服务器反馈回来的地址。除非额外指定，否则这个响应也是可缓存的。
• 302 Found 请求的资源现在临时从不同的 URI 响应请求。由于这样的重定向是临时的，客户端应当继续向原有地址发送以后的请求。只有在 Cache-Control 或 Expires 中进行了指定的情况下，这个响应才是可缓存的。字面上的区别就是 301 是永久重定向，而 302 是临时重定向。
• 301 比较常用的场景是使用域名跳转。302 用来做临时跳转比如未登陆的用户访问用户中心重定向到登录页面。

csrf 和 xss 的网络攻击及防范

参考回答：

• CSRF：跨站请求伪造，可以理解为攻击者盗用了用户的身份，以用户的名义发送了恶意请求，比如用户登录了一个网站后，立刻在另一个ｔａｂ页面访问量攻击者用来制造攻击的网站，这个网站要求访问刚刚登陆的网站，并发送了一个恶意请求，这时候 CSRF 就产生了，比如这个制造攻击的网站使用一张图片，但是这种图片的链接却是可以修改数据库的，这时候攻击者就可以以用户的名义操作这个数据库，防御方式的话：使用验证码，检查 https 头部的 refer，使用 token。
• XSS：跨站脚本攻击，是说攻击者通过注入恶意的脚本，在用户浏览网页的时候进行攻击，比如获取 cookie，或者其他用户身份信息，可以分为存储型和反型，存储型是攻击者输入一些数据并且存储到了数据库中，其他浏览者看到的时候进行攻击，反射型的话不存储在数据库中，往往表现为将攻击代码放在 url 地址的请求参数中，防御的话为 cookie 设置 httpOnly 属性，对用户的输入进行检查，进行特殊字符过滤。

简述 TCP 连接的过程（淘系）

参考答案：

TCP 协议通过三次握手建立可靠的点对点连接，具体过程是：

首先服务器进入监听状态，然后即可处理连接

第一次握手：建立连接时，客户端发送 syn 包到服务器，并进入 SYN_SENT 状态，等待服务器确认。在发送的包中还会包含一个初始序列号 seq。此次握手的含义是客户端希望与服务器建立连接。

第二次握手：服务器收到 syn 包，然后回应给客户端一个 SYN+ACK 包，此时服务器进入 SYN_RCVD 状态。此次握手的含义是服务端回应客户端，表示已收到并同意客户端的连接请求。

第三次握手：客户端收到服务器的 SYN 包后，向服务器再次发送 ACK 包，并进入 ESTAB_LISHED 状态。

最后，服务端收到客户端的 ACK 包，于是也进入 ESTAB_LISHED 状态，至此，连接建立完成

介绍下 HTTPS 中间人攻击

参考答案：

针对 HTTPS 攻击主要有 SSL 劫持攻击和 SSL 剥离攻击两种。

SSL 劫持攻击是指攻击者劫持了客户端和服务器之间的连接，将服务器的合法证书替换为伪造的证书，从而获取客户端和服务器之间传递的信息。这种方式一般容易被用户发现，浏览器会明确的提示证书错误，但某些用户安全意识不强，可能会点击继续浏览，从而达到攻击目的。

SSL 剥离攻击是指攻击者劫持了客户端和服务器之间的连接，攻击者保持自己和服务器之间的 HTTPS 连接，但发送给客户端普通的 HTTP 连接，由于 HTTP 连接是明文传输的，即可获取客户端传输的所有明文数据。

介绍下 http1.0、http1.1、http2.0 协议的区别？

参考答案：

首先说 http1.0

它的特点是每次请求和响应完毕后都会销毁 TCP 连接，同时规定前一个响应完成后才能发送下一个请求。这样做有两个问题：

1. 无法复用连接

   每次请求都要创建新的 TCP 连接，完成三次握手和四次挥手，网络利用率低

2. 队头阻塞

   如果前一个请求被某种原因阻塞了，会导致后续请求无法发送。

然后是 http1.1

http1.1 是 http1.0 的改进版，它做出了以下改进：

1. 长连接

   http1.1 允许在请求时增加请求头connection:keep-alive，这样便允许后续的客户端请求在一段时间内复用之前的 TCP 连接

2. 管道化

   基于长连接的基础，管道化可以不等第一个请求响应继续发送后面的请求，但响应的顺序还是按照请求的顺序返回。

3. 缓存处理

   新增响应头 cache-control，用于实现客户端缓存。

4. 断点传输

   在上传/下载资源时，如果资源过大，将其分割为多个部分，分别上传/下载，如果遇到网络故障，可以从已经上传/下载好的地方继续请求，不用从头开始，提高效率

最后是 http2.0

http2.0 进一步优化了传输效率，它主要有以下改进：

1. 二进制分帧

   将传输的消息分为更小的二进制帧，每帧有自己的标识序号，即便被随意打乱也能在另一端正确组装

2. 多路复用

   基于二进制分帧，在同一域名下所有访问都是从同一个 tcp 连接中走，并且不再有队头阻塞问题，也无须遵守响应顺序

3. 头部压缩

   http2.0 通过字典的形式，将头部中的常见信息替换为更少的字符，极大的减少了头部的数据量，从而实现更小的传输量

4. 服务器推

   http2.0 允许服务器直接推送消息给客户端，无须客户端明确的请求

为什么 HTTP1.1 不能实现多路复用（腾讯）

参考答案：

HTTP/1.1 不是二进制传输，而是通过文本进行传输。由于没有流的概念，在使用并行传输（多路复用）传递数据时，接收端在接收到响应后，并不能区分多个响应分别对应的请求，所以无法将多个响应的结果重新进行组装，也就实现不了多路复用。

简单讲解一下 http2 的多路复用（网易）

参考答案：

在 HTTP/2 中，有两个非常重要的概念，分别是帧（frame）和流（stream）。 帧代表着最小的数据单位，每个帧会标识出该帧属于哪个流，流也就是多个帧组成的数据流。 多路复用，就是在一个 TCP 连接中可以存在多条流。换句话说，也就是可以发送多个请求，对端可以通过帧中的标识知道属于哪个请求。通过这个技术，可以避免 HTTP 旧版本中的队头阻塞问题，极大的提高传输性能。

谈谈你对 TCP 三次握手和四次挥手的理解

TCP 协议通过三次握手建立可靠的点对点连接，具体过程是：

首先服务器进入监听状态，然后即可处理连接

第一次握手：建立连接时，客户端发送 syn 包到服务器，并进入 SYN_SENT 状态，等待服务器确认。在发送的包中还会包含一个初始序列号 seq。此次握手的含义是客户端希望与服务器建立连接。

第二次握手：服务器收到 syn 包，然后回应给客户端一个 SYN+ACK 包，此时服务器进入 SYN_RCVD 状态。此次握手的含义是服务端回应客户端，表示已收到并同意客户端的连接请求。

第三次握手：客户端收到服务器的 SYN 包后，向服务器再次发送 ACK 包，并进入 ESTAB_LISHED 状态。

最后，服务端收到客户端的 ACK 包，于是也进入 ESTAB_LISHED 状态，至此，连接建立完成

当需要关闭连接时，需要进行四次挥手才能关闭

1. Client 向 Server 发送 FIN 包，表示 Client 主动要关闭连接，然后进入 FIN_WAIT_1 状态，等待 Server 返回 ACK 包。此后 Client 不能再向 Server 发送数据，但能读取数据。
2. Server 收到 FIN 包后向 Client 发送 ACK 包，然后进入 CLOSE_WAIT 状态，此后 Server 不能再读取数据，但可以继续向 Client 发送数据。
3. Client 收到 Server 返回的 ACK 包后进入 FIN_WAIT_2 状态，等待 Server 发送 FIN 包。
4. Server 完成数据的发送后，将 FIN 包发送给 Client，然后进入 LAST_ACK 状态，等待 Client 返回 ACK 包，此后 Server 既不能读取数据，也不能发送数据。
5. Client 收到 FIN 包后向 Server 发送 ACK 包，然后进入 TIME_WAIT 状态，接着等待足够长的时间（2MSL）以确保 Server 接收到 ACK 包，最后回到 CLOSED 状态，释放网络资源。
6. Server 收到 Client 返回的 ACK 包后便回到 CLOSED 状态，释放网络资源。

介绍 HTTPS 握手过程

参考答案：

1. 客户端请求服务器，并告诉服务器自身支持的加密算法以及密钥长度等信息
2. 服务器响应公钥和服务器证书
3. 客户端验证证书是否合法，然后生成一个会话密钥，并用服务器的公钥加密密钥，把加密的结果通过请求发送给服务器
4. 服务器使用私钥解密被加密的会话密钥并保存起来，然后使用会话密钥加密消息响应给客户端，表示自己已经准备就绪
5. 客户端使用会话密钥解密消息，知道了服务器已经准备就绪。
6. 后续客户端和服务器使用会话密钥加密信息传递消息

HTTPS 握手过程中，客户端如何验证证书的合法性

参考答案：

1. 校验证书的颁发机构是否受客户端信任。
2. 通过 CRL 或 OCSP 的方式校验证书是否被吊销。
3. 对比系统时间，校验证书是否在有效期内。
4. 通过校验对方是否存在证书的私钥，判断证书的网站域名是否与证书颁发的域名一致。

Http 状态码 301 和 302 的应用场景分别是什么

参考答案：

301 表示永久重定向，302 表示临时重定向。

如果浏览器收到的是 301，则会缓存重定向的地址，之后不会再重新请求服务器，直接使用缓存的地址请求，这样可以减少请求次数。

但如果浏览器收到的是 302，则不会缓存重定向地址，浏览器将来会继续以原有地址请求。

因此，301 适合地址永久转移的场景，比如域名变更；而 302 适合临时转移的场景，比如首页临时跳转到活动页

cookie 和 token 都存放在 header 中，为什么不会劫持 token？

参考答案：

由于浏览器会自动发送 cookie 到服务器，因此攻击者可以利用这种特点进行 csrf 攻击。

而通常 token 是不放到 cookie 中的，需要浏览器端使用 JS 自行保存到 localstorage 中，在请求时也需要手动的加入到请求头中，因此不容易引发 csrf 攻击。

介绍下如何实现 token 加密

参考答案：

以最常见的 token 格式 jwt 为例

token 分为三段，分别是 header、payload、signature

其中，header 标识签名算法和令牌类型；payload 标识主体信息，包含令牌过期时间、发布时间、发行者、主体内容等；signature 是使用特定的算法对前面两部分进行加密，得到的加密结果。

token 有防篡改的特点，如果攻击者改动了前面两个部分，就会导致和第三部分对应不上，使得 token 失效。而攻击者不知道加密秘钥，因此又无法修改第三部分的值。

所以，在秘钥不被泄露的前提下，一个验证通过的 token 是值得被信任的。

说下单点登录（新东方）

参考答案：

SSO 一般都需要一个独立的认证中心（passport），子系统的登录均得通过 passport，子系统本身将不参与登录操作，当一个系统成功登录以后，passport 将会颁发一个令牌给各个子系统，子系统可以拿着令牌会获取各自的受保护资源，为了减少频繁认证，各个子系统在被 passport 授权以后，会建立一个局部会话，在一定时间内可以无需再次向 passport 发起认证。

具体流程是：

1. 用户访问系统 1 的受保护资源，系统 1 发现用户未登录，跳转至 sso 认证中心，并将自己的地址作为参数
2. sso 认证中心发现用户未登录，将用户引导至登录页面
3. 用户输入用户名密码提交登录申请
4. sso 认证中心校验用户信息，创建用户与 sso 认证中心之间的会话，称为全局会话，同时创建授权令牌
5. sso 认证中心带着令牌跳转会最初的请求地址（系统 1）
6. 系统 1 拿到令牌，去 sso 认证中心校验令牌是否有效
7. sso 认证中心校验令牌，返回有效，注册系统 1
8. 系统 1 使用该令牌创建与用户的会话，称为局部会话，返回受保护资源
9. 用户访问系统 2 的受保护资源
10. 系统 2 发现用户未登录，跳转至 sso 认证中心，并将自己的地址作为参数
11. sso 认证中心发现用户已登录，跳转回系统 2 的地址，并附上令牌
12. 系统 2 拿到令牌，去 sso 认证中心校验令牌是否有效
13. sso 认证中心校验令牌，返回有效，注册系统 2
14. 系统 2 使用该令牌创建与用户的局部会话，返回受保护资源

http1.1 是如何复用 tcp 连接的？（网易）

参考答案：

客户端请求服务器时，通过请求行告诉服务器使用的协议是 http1.1，同时在请求头中附带connection:keep-alive（为保持兼容），告诉服务器这是一个长连接，后续请求可以重复使用这一次的 TCP 连接。

这样做的好处是减少了三次握手和四次挥手的次数，一定程度上提升了网络利用率。但由于 http1.1 不支持多路复用，响应顺序必须按照请求顺序抵达客户端，不能真正实现并行传输，因此在 http2.0 出现之前，实际项目中往往把静态资源，比如图片，分发到不同域名下的资源服务器，以便实现真正的并行传输。

文件上传如何做断点续传（网易）

参考答案：

客户端将文件的二进制内容进行分片，每片数据按顺序进行序号标识，上传每片数据时同时附带其序号。服务器接收到每片数据时，将其保存成一个临时文件，并记录每个文件的 hash 和序号。

若上传中止，将来再次上传时，可以向服务器索要已上传的分片序号，客户端仅需上传剩余分片即可。

当全部分片上传完成后，服务器按照分片的顺序组装成完整的文件，并删除分片文件。

介绍 SSL 和 TLS（寺库）

参考答案：

它们都是用于保证传输安全的协议，介于传输层和应用层之间，TLS 是 SSL 的升级版。

它们的基本流程一致：

1. 客户端向服务器端索要公钥，并使用数字证书验证公钥。
2. 客户端使用公钥加密会话密钥，服务端用私钥解密会话密钥，于是得到一个双方都认可的会话密钥
3. 传输的数据使用会话密钥加密，然后再传输，接收消息方使用会话密钥解密得到原始数据

说说网络的五层模型（寺库）

参考答案：

从上到下分别为：应用层、传输层、网络层、数据链路层、物理层。在发送消息时，消息从上到下进行打包，每一层会在上一层基础上加包，而接受消息时，从下到上进行解包，最终得到原始信息。

其中：

应用层主要面向互联网中的应用场景，比如网页、邮件、文件中心等等，它的代表协议有 http、smtp、pop3、ftp、DNS 等等

传输层主要面向传输过程，比如 TCP 协议是为了保证可靠的传输，而 UDP 协议则是一种无连接的广播，它们提供了不同的传输方式

网络层主要解决如何定位目标的问题，比如 IP、ICMP、ARP 等等

数据链路层的作用是将数据可靠的传输到目标，比如常见的以太网协议、P2P 协议

物理层是要规范网络两端使用的物理设备，比如蓝牙、wifi、光纤、网线接头等等

GET 和 POST 的区别（流利说）

参考答案：

从 http 协议的角度来说，GET 和 POST 它们都只是请求行中的第一个单词，除了语义不同，其实没有本质的区别。

之所以在实际开发中会产生各种区别，主要是因为浏览器的默认行为造成的。

受浏览器的影响，在实际开发中，GET 和 POST 有以下区别：

1. 浏览器在发送 GET 请求时，不会附带请求体
2. GET 请求的传递信息量有限，适合传递少量数据；POST 请求的传递信息量是没有限制的，适合传输大量数据。
3. GET 请求只能传递 ASCII 数据，遇到非 ASCII 数据需要进行编码；POST 请求没有限制
4. 大部分 GET 请求传递的数据都附带在 path 参数中，能够通过分享地址完整的重现页面，但同时也暴露了数据，若有敏感数据传递，不应该使用 GET 请求，至少不应该放到 path 中
5. 刷新页面时，若当前的页面是通过 POST 请求得到的，则浏览器会提示用户是否重新提交。若是 GET 请求得到的页面则没有提示。
6. GET 请求的地址可以被保存为浏览器书签，POST 不可以

http 劫持是什么？

参考答案：

是指攻击者在客户端和服务器之间同时建立了连接通道，通过某种方式，让客户端请求发送到自己的服务器，然后自己就拥有了控制响应内容的能力，从而给客户端展示错误的信息。

HTTP 劫持、DNS 劫持与 XSS

参考答案：

http 劫持是指攻击者在客户端和服务器之间同时建立了连接通道，通过某种方式，让客户端请求发送到自己的服务器，然后自己就拥有了控制响应内容的能力，从而给客户端展示错误的信息，比如在页面中加入一些广告内容。

DNS 劫持是指攻击者劫持了 DNS 服务器，获得了修改 DNS 解析记录的权限，从而导致客户端请求的域名被解析到了错误的 IP 地址，攻击者通过这种方式窃取用户资料或破坏原有正常服务。

XSS 是指跨站脚本攻击。攻击者利用站点的漏洞，在表单提交时，在表单内容中加入一些恶意脚本，当其他正常用户浏览页面，而页面中刚好出现攻击者的恶意脚本时，脚本被执行，从而使得页面遭到破坏，或者用户信息被窃取。

要防范 XSS 攻击，需要在服务器端过滤脚本代码，将一些危险的元素和属性去掉或对元素进行 HTML 实体编码。

介绍 xss csrf 攻击

参考答案：

XSS：

XSS 是指跨站脚本攻击。攻击者利用站点的漏洞，在表单提交时，在表单内容中加入一些恶意脚本，当其他正常用户浏览页面，而页面中刚好出现攻击者的恶意脚本时，脚本被执行，从而使得页面遭到破坏，或者用户信息被窃取。

要防范 XSS 攻击，需要在服务器端过滤脚本代码，将一些危险的元素和属性去掉或对元素进行 HTML 实体编码。

CSRF：

CSRF 是跨站请求伪造，是一种挟制用户在当前已登录的 Web 应用上执行非本意的操作的攻击方法

它首先引导用户访问一个危险网站，当用户访问网站后，网站会发送请求到被攻击的站点，这次请求会携带用户的 cookie 发送，因此就利用了用户的身份信息完成攻击

防御 CSRF 攻击有多种手段：

1. 不使用 cookie
2. 为表单添加校验的 token 校验
3. cookie 中使用 sameSite 字段
4. 服务器检查 referer 字段

https 验证身份也就是 TSL/SSL 身份验证的过程

参考答案：

1. 客户端请求服务器，并告诉服务器自身支持的加密算法以及密钥长度等信息
2. 服务器响应公钥和服务器证书
3. 客户端验证证书是否合法，然后生成一个会话密钥，并用服务器的公钥加密密钥，把加密的结果通过请求发送给服务器
4. 服务器使用私钥解密被加密的会话密钥并保存起来，然后使用会话密钥加密消息响应给客户端，表示自己已经准备就绪
5. 客户端使用会话密钥解密消息，知道了服务器已经准备就绪。
6. 后续客户端和服务器使用会话密钥加密信息传递消息

为什么需要 CA 机构对证书签名

参考答案：

主要是为了解决证书的可信问题。如果没有权威机构对证书进行签名，客户端就无法知晓证书是否是伪造的，从而增加了中间人攻击的风险，https 就变得毫无意义。

身份验证过程中会涉及到密钥，对称加密，非对称加密，摘要的概念，请解释一下

参考答案：

密钥

密钥是一种参数，它是在明文转换为密文或将密文转换为明文的算法中输入的参数。密钥分为对称密钥与非对称密钥，分别应用在对称加密和非对称加密上。

对称加密

对称加密又叫做私钥加密，即信息的发送方和接收方使用同一个密钥去加密和解密数据。对称加密的特点是算法公开、加密和解密速度快，适合于对大数据量进行加密，常见的对称加密算法有 DES、3DES、TDEA、Blowfish、RC5 和 IDEA。

非对称加密

非对称加密也叫做公钥加密。非对称加密与对称加密相比，其安全性更好。对称加密的通信双方使用相同的密钥，如果一方的密钥遭泄露，那么整个通信就会被破解。而非对称加密使用一对密钥，即公钥和私钥，且二者成对出现。私钥被自己保存，不能对外泄露。公钥指的是公共的密钥，任何人都可以获得该密钥。用公钥或私钥中的任何一个进行加密，用另一个进行解密。

摘要

摘要算法又称哈希/散列算法。它通过一个函数，把任意长度的数据转换为一个长度固定的数据串（通常用 16 进制的字符串表示）。算法不可逆。

webSocket 协议是什么，能简述一下吗？

参考答案：

websocket 协议 HTML5 带来的新协议，相对于 http，它是一个持久连接的协议，它利用 http 协议完成握手，然后通过 TCP 连接通道发送消息，使用 websocket 协议可以实现服务器主动推送消息。

首先，客户端若要发起 websocket 连接，首先必须向服务器发送 http 请求以完成握手，请求行中的 path 需要使用ws:开头的地址，请求头中要分别加入upgrade、connection、Sec-WebSocket-Key、Sec-WebSocket-Version标记

然后，服务器收到请求后，发现这是一个 websocket 协议的握手请求，于是响应行中包含Switching Protocols，同时响应头中包含upgrade、connection、Sec-WebSocket-Accept标记

当客户端收到响应后即可完成握手，随后使用建立的 TCP 连接直接发送和接收消息。

webSocket 与传统的 http 有什么优势

参考答案：

当页面中需要观察实时数据的变化（比如聊天、k 线图）时，过去我们往往使用两种方式完成

第一种是短轮询，即客户端每隔一段时间就向服务器发送消息，询问有没有新的数据

第二种是长轮询，发起一次请求询问服务器，服务器可以将该请求挂起，等到有新消息时再进行响应。响应后，客户端立即又发起一次请求，重复整个流程。

无论是哪一种方式，都暴露了 http 协议的弱点，即响应必须在请求之后发生，服务器是被动的，无法主动推送消息。而让客户端不断的发起请求又白白的占用了资源。

websocket 的出现就是为了解决这个问题，它利用 http 协议完成握手之后，就可以与服务器建立持久的连接，服务器可以在任何需要的时候，主动推送消息给客户端，这样占用的资源最少，同时实时性也最高。

如何劫持 https 的请求，提供思路

参考答案：

https 有防篡改的特点，只要浏览器证书验证过程是正确的，很难在用户不察觉的情况下进行攻击。但若能够更改浏览器的证书验证过程，便有机会实现 https 中间人攻击。

所以，要劫持 https，首先要伪造一个证书，并且要想办法让用户信任这个证书，可以有多种方式，比如病毒、恶意软件、诱导等。一旦证书被信任后，就可以利用普通中间人攻击的方式，使用伪造的证书进行攻击。

怎样解决跨域问题？

参考答案：

1. 使用 JSONP

   这是一种古老的解决跨域问题的思路。

   在需要跨域请求时，事先准备好一个处理服务器数据的函数，然后生成一个<script>元素，src指向跨域站点，同时把准备好的函数名通过地址参数传递到服务器。

   跨域站点返回一段调用该函数的脚本，当客户端接收到脚本后就会运行事先准备的函数，从而实现跨域获取数据。

   JSONP 实现简单、兼容性好，但缺点也很明显，它只支持 get 请求，同时也有安全性问题，并且对服务器端代码侵入性比较强。

2. 使用 cors

   在请求时，客户端使用一些特殊的请求头向服务器申请跨域访问，并通过这些请求头告诉服务器自己的行为。服务器根据自身的规则决定是否允许跨域，如果允许，则通过响应头告诉客户端可以发送跨域请求。

   cors 协议已被各种主流浏览器支持，它安全性高，同时也不会侵入服务器代码，是目前最主流的跨域方式

除此之外，远古时期的跨域处理还包括 iframe、form 等，由于它们缺陷非常明显，故很少使用了。

前端如何实现即时通讯？

参考答案：

1. 短轮询。即客户端每隔一段时间就向服务器发送消息，询问有没有新的数据
2. 长轮询，发起一次请求询问服务器，服务器可以将该请求挂起，等到有新消息时再进行响应。响应后，客户端立即又发起一次请求，重复整个流程。
3. websocket，握手完毕后会建立持久性的连接通道，随后服务器可以在任何时候推送新消息给客户端

HTTP 常用状态码 301 302 304 403

参考答案：

301 永久重定向，浏览器会把重定向后的地址缓存起来，将来用户再次访问原始地址时，直接引导用户访问新地址

302 临时重定向，浏览器会引导用户进入新地址，但不会缓存原始地址，下一次用户访问源地址时，浏览器仍然要请求原地址的服务器

304 资源未修改，服务器通过该状态码告诉客户端，请求的资源和过去一样，并没有任何变化，建议自行使用过去的缓存。通常，304 状态码的响应中，服务器不会附带任何的响应体。

403 不允许访问。服务器通过该状态码告诉客户端，这个资源目前不允许访问。这种状态码通常出现在权限不足的情况下。

在浏览器地址栏输入地址，并按下回车键后，发生了哪些事情？

1. 参考答案：
   1. 浏览器自动补全协议、端口
   2. 浏览器自动完成 url 编码
   3. 浏览器根据 url 地址查找本地缓存，根据缓存规则看是否命中缓存，若命中缓存则直接使用缓存，不再发出请求
   4. 通过 DNS 解析找到服务器的 IP 地址
   5. 浏览器向服务器发出建立 TCP 连接的申请，完成三次握手后，连接通道建立
   6. 若使用了 HTTPS 协议，则还会进行 SSL 握手，建立加密信道。使用 SSL 握手时，会确定是否使用 HTTP2
   7. 浏览器决定要附带哪些 cookie 到请求头中
   8. 浏览器自动设置好请求头、协议版本、cookie，发出 GET 请求
   9. 服务器处理请求，进入后端处理流程。完成处理后，服务器响应一个 HTTP 报文给浏览器。
   10. 浏览器根据使用的协议版本，以及 Connection 字段的约定，决定是否要保留 TCP 连接。
   11. 浏览器根据响应状态码决定如何处理这一次响应
   12. 浏览器根据响应头中的 Content-Type 字段识别响应类型，如果是 text/html，则对响应体的内容进行 HTML 解析，否则做其他处理
   13. 浏览器根据响应头的其他内容完成缓存、cookie 的设置
   14. 浏览器开始从上到下解析 HTML，若遇到外部资源链接，则进一步请求资源
   15. 解析过程中生成 DOM 树、CSSOM 树，然后一边生成，一边把二者合并为渲染树（rendering tree），随后对渲染树中的每个节点计算位置和大小（reflow），最后把每个节点利用 GPU 绘制到屏幕（repaint）
   16. 在解析过程中还会触发一系列的事件，当 DOM 树完成后会触发 DOMContentLoaded 事件，当所有资源加载完毕后会触发 load 事件

HTTPS 握手

参考答案：

1. 客户端请求服务器，并告诉服务器自身支持的加密算法以及密钥长度等信息
2. 服务器响应公钥和服务器证书
3. 客户端验证证书是否合法，然后生成一个会话密钥，并用服务器的公钥加密密钥，把加密的结果通过请求发送给服务器
4. 服务器使用私钥解密被加密的会话密钥并保存起来，然后使用会话密钥加密消息响应给客户端，表示自己已经准备就绪
5. 客户端使用会话密钥解密消息，知道了服务器已经准备就绪。
6. 后续客户端和服务器使用会话密钥加密信息传递消息

网页验证码是干嘛的，是为了解决什么安全问题？

参考答案：

验证码主要用于让服务器区分请求是人还是机器发送的。这样做是为了避免某些程序恶意的提交大量信息到服务器，进而导致服务器产生大量的垃圾数据。有时，验证码也可以防止机器暴力破解用户密码，它通过在短时间内不断提交登录信息，尝试各种密码组合来达到破解的目的。

http1.0、http2.0、http3.0 之间的区别

参考答案：

http1.0

每次请求和响应完毕后都会销毁 TCP 连接，同时规定前一个响应完成后才能发送下一个请求。这样做有两个问题：

1. 无法复用连接

   每次请求都要创建新的 TCP 连接，完成三次握手和四次挥手，网络利用率低

2. 队头阻塞

   如果前一个请求被某种原因阻塞了，会导致后续请求无法发送。

http2.0

http2.0 优化了传输效率，它主要有以下改进：

1. 二进制分帧

   将传输的消息分为更小的二进制帧，每帧有自己的标识序号，即便被随意打乱也能在另一端正确组装

2. 多路复用

   基于二进制分帧，在同一域名下所有访问都是从同一个 tcp 连接中走，并且不再有队头阻塞问题，也无须遵守响应顺序

3. 头部压缩

   http2.0 通过字典的形式，将头部中的常见信息替换为更少的字符，极大的减少了头部的数据量，从而实现更小的传输量

4. 服务器推

   http2.0 允许服务器直接推送消息给客户端，无须客户端明确的请求

http3.0

http3.0 目前还在草案阶段，它完全抛弃了 TCP 协议，转而使用 UDP 协议，是为了进一步提升性能。

虽然 http2.0 进行了大量的优化，但它无法摆脱 TCP 协议本身的问题，比如建立连接时间长、对头阻塞问题等等。

为了保证传输的可靠性，http3.0 使用了 QUIC 协议。

cookie/sessionStorage/localStorage 的区别

参考答案：

cookie、sessionStorage、localStorage 都是保存本地数据的方式

其中，cookie 兼容性较好，所有浏览器均支持。浏览器针对 cookie 会有一些默认行为，比如当响应头中出现set-cookie字段时，浏览器会自动保存 cookie 的值；再比如，浏览器发送请求时，会附带匹配的 cookie 到请求头中。这些默认行为，使得 cookie 长期以来担任着维持登录状态的责任。与此同时，也正是因为浏览器的默认行为，给了恶意攻击者可乘之机，CSRF 攻击就是一个典型的利用 cookie 的攻击方式。虽然 cookie 不断的改进，但前端仍然需要另一种更加安全的保存数据的方式

HTML5 新增了 sessionStorage 和 localStorage，前者用于保存会话级别的数据，后者用于更持久的保存数据。浏览器针对它们没有任何默认行为，这样一来，就把保存数据、读取数据的工作交给了前端开发者，这就让恶意攻击者难以针对登录状态进行攻击。 cookie 的大小是有限制的，一般浏览器会限制同一个域下的 cookie 总量为 4M，而 sessionStorage 和 localStorage 则没有限制 cookie 会与 domain、path 关联，而 sessionStorage 和 localStorage 只与 domain 关联

post 请求什么时候用 form data 什么时候用 request payload

参考答案：

form data 适合传递简单的键值对信息，由于传递的信息比较扁平，难以传递深层次嵌套的数据

request payload 适合传递任意格式的数据，包括单个数字、布尔、深层次嵌套的对象、数组等，但 request payload 不适合传递文件数据

在前后端分离的项目中，对于非文件数据的传递，都推荐使用 request payload 的形式，以传递最明确的数据类型和数据结构，而对于文件上传，则推荐使用传统的 form data

http 常见请求方法有哪些？

参考答案：

• GET，表示向服务器获取资源
• POST，表示向服务器提交信息，通常用于产生新的数据，比如注册
• PUT，表示希望修改服务器的数据，通常用于修改
• DELETE，表示希望删除服务器的数据
• OPTIONS，发生在跨域的预检请求中，表示客户端向服务器申请跨域提交
• TRACE，回显服务器收到的请求，主要用于测试和诊断
• CONNECT，用于建立连接管道，通常在代理场景中使用，网页中很少用到

列举优化网络性能方法

参考答案：

• 优化打包体积

  利用一些工具压缩、混淆最终打包代码，减少包体积

• 多目标打包

  利用一些打包插件，针对不同的浏览器打包出不同的兼容性版本，这样一来，每个版本中的兼容性代码就会大大减少，从而减少包体积

• 压缩

  现代浏览器普遍支持压缩格式，因此服务端的各种文件可以压缩后再响应给客户端，只要解压时间小于优化的传输时间，压缩就是可行的

• CDN

  利用 CDN 可以大幅缩减静态资源的访问时间，特别是对于公共库的访问，可以使用知名的 CDN 资源，这样可以实现跨越站点的缓存

• 缓存

  对于除 HTML 外的所有静态资源均可以开启协商缓存，利用构建工具打包产生的文件 hash 值来置换缓存

• http2

  开启 http2 后，利用其多路复用、头部压缩等特点，充分利用带宽传递大量的文件数据

• 雪碧图

  对于不使用 HTTP2 的场景，可以将多个图片合并为雪碧图，以达到减少文件的目的

• defer、async

  通过 defer 和 async 属性，可以让页面尽早加载 js 文件

• prefetch、preload

  通过 prefetch 属性，可以让页面在空闲时预先下载其他页面可能要用到的资源

  通过 preload 属性，可以让页面预先下载本页面可能要用到的资源

• 多个静态资源域

  对于不使用 HTTP2 的场景，将相对独立的静态资源分到多个域中保存，可以让浏览器同时开启多个 TCP 连接，并行下载

session 怎么消除

参考答案：

1. 过期时间

   当客户端长时间没有传递 sessionid 过来时，服务器可以在过期时间之后自动清除 session

2. 客户端主动通知

   可以使用 JS 监听客户端页面关闭或其他退出操作，然后通知服务器清除 session

什么是 DNS 域名解析？

参考答案：

DNS 域名解析是指把域名解析成 IP 地址的过程。

在具体的实现上，域名解析是由多个层级的服务器共同完成的。在查询域名时，客户端会先检查自身的 DNS 映射表，若找不到解析记录，则使用用户配置的 DNS 服务器，若目标 DNS 服务器中找不到记录，则继续往上一个层级寻找，直到到达根域名服务器，根域名服务器会根据域名的类型，将解析任务分发到对应的子域名服务器依次查找，直到找到解析记录为止。

HTTP 有哪些方法？

• HTTP1.0 定义了三种请求方法： GET, POST 和 HEAD 方法
• HTTP1.1 新增了五种请求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT

这些方法的具体作用是什么？

• GET: 通常用于请求服务器发送某些资源
• HEAD: 请求资源的头部信息, 并且这些头部与 HTTP GET 方法请求时返回的一致. 该请求方法的一个使用场景是在下载一个大文件前先获取其大小再决定是否要下载, 以此可以节约带宽资源
• OPTIONS: 用于获取目的资源所支持的通信选项
• POST: 发送数据给服务器
• PUT: 用于新增资源或者使用请求中的有效负载替换目标资源的表现形式
• DELETE: 用于删除指定的资源
• PATCH: 用于对资源进行部分修改
• CONNECT: HTTP/1.1 协议中预留给能够将连接改为管道方式的代理服务器
• TRACE: 回显服务器收到的请求，主要用于测试或诊断

GET 和 POST 有什么区别？

• 数据传输方式不同：GET 请求通过 URL 传输数据，而 POST 的数据通过请求体传输。
• 安全性不同：POST 的数据因为在请求主体内，所以有一定的安全性保证，而 GET 的数据在 URL 中，通过历史记录，缓存很容易查到数据信息。
• 数据类型不同：GET 只允许 ASCII 字符，而 POST 无限制
• GET 无害： 刷新、后退等浏览器操作 GET 请求是无害的，POST 可能重复提交表单
• 特性不同：GET 是安全（这里的安全是指只读特性，就是使用这个方法不会引起服务器状态变化）且幂等（幂等的概念是指同一个请求方法执行多次和仅执行一次的效果完全相同），而 POST 是非安全非幂等

PUT 和 POST 都是给服务器发送新增资源，有什么区别？

PUT 和 POST 方法的区别是,PUT 方法是幂等的：连续调用一次或者多次的效果相同（无副作用），而 POST 方法是非幂等的。

除此之外还有一个区别，通常情况下，PUT 的 URI 指向是具体单一资源，而 POST 可以指向资源集合。

举个例子，我们在开发一个博客系统，当我们要创建一篇文章的时候往往用POST https://www.jianshu.com/articles，这个请求的语义是，在 articles 的资源集合下创建一篇新的文章，如果我们多次提交这个请求会创建多个文章，这是非幂等的。

而PUT https://www.jianshu.com/articles/820357430的语义是更新对应文章下的资源（比如修改作者名称等），这个 URI 指向的就是单一资源，而且是幂等的，比如你把『刘德华』修改成『蔡徐坤』，提交多少次都是修改成『蔡徐坤』

ps: 『POST 表示创建资源，PUT 表示更新资源』这种说法是错误的，两个都能创建资源，根本区别就在于幂等性

PUT 和 PATCH 都是给服务器发送修改资源，有什么区别？

PUT 和 PATCH 都是更新资源，而 PATCH 用来对已知资源进行局部更新。

比如我们有一篇文章的地址https://www.jianshu.com/articles/820357430,这篇文章的可以表示为:

article = {
    author: 'dxy',
    creationDate: '2019-6-12',
    content: '我写文章像蔡徐坤',
    id: 820357430
}

当我们要修改文章的作者时，我们可以直接发送PUT https://www.jianshu.com/articles/820357430，这个时候的数据应该是:

{
    author:'蔡徐坤',
    creationDate: '2019-6-12',
    content: '我写文章像蔡徐坤',
    id: 820357430
}

这种直接覆盖资源的修改方式应该用 put，但是你觉得每次都带有这么多无用的信息，那么可以发送PATCH https://www.jianshu.com/articles/820357430，这个时候只需要:

 {
    author: "蔡徐坤";
}

http 的请求报文是什么样的？

请求报文有 4 部分组成:

• 请求行
• 请求头部
• 空行
• 请求体

• 请求行包括：请求方法字段、URL 字段、HTTP 协议版本字段。它们用空格分隔。例如，GET /index.html HTTP/1.1。
• 请求头部:请求头部由关键字/值对组成，每行一对，关键字和值用英文冒号“:”分隔

1. User-Agent：产生请求的浏览器类型。
2. Accept：客户端可识别的内容类型列表。
3. Host：请求的主机名，允许多个域名同处一个 IP 地址，即虚拟主机。

• 请求体: post put 等请求携带的数据

http 的响应报文是什么样的？

请求报文有 4 部分组成:

• 响应行
• 响应头
• 空行
• 响应体

• 响应行： 由协议版本，状态码和状态码的原因短语组成，例如HTTP/1.1 200 OK。
• 响应头：响应部首组成
• 响应体：服务器响应的数据

聊一聊 HTTP 的部首有哪些？

内容很多，重点看标『✨』内容

通用首部字段（General Header Fields）：请求报文和响应报文两方都会使用的首部

• Cache-Control 控制缓存 ✨
• Connection 连接管理、逐条首部 ✨
• Upgrade 升级为其他协议
• via 代理服务器的相关信息
• Wraning 错误和警告通知
• Transfor-Encoding 报文主体的传输编码格式 ✨
• Trailer 报文末端的首部一览
• Pragma 报文指令
• Date 创建报文的日期

请求首部字段（Reauest Header Fields）:客户端向服务器发送请求的报文时使用的首部

• Accept 客户端或者代理能够处理的媒体类型 ✨
• Accept-Encoding 优先可处理的编码格式
• Accept-Language 优先可处理的自然语言
• Accept-Charset 优先可以处理的字符集
• If-Match 比较实体标记（ETage） ✨
• If-None-Match 比较实体标记（ETage）与 If-Match 相反 ✨
• If-Modified-Since 比较资源更新时间（Last-Modified）✨
• If-Unmodified-Since 比较资源更新时间（Last-Modified），与 If-Modified-Since 相反 ✨
• If-Rnages 资源未更新时发送实体 byte 的范围请求
• Range 实体的字节范围请求 ✨
• Authorization web 的认证信息 ✨
• Proxy-Authorization 代理服务器要求 web 认证信息
• Host 请求资源所在服务器 ✨
• From 用户的邮箱地址
• User-Agent 客户端程序信息 ✨
• Max-Forwrads 最大的逐跳次数
• TE 传输编码的优先级
• Referer 请求原始放的 url
• Expect 期待服务器的特定行为

响应首部字段（Response Header Fields）:从服务器向客户端响应时使用的字段

• Accept-Ranges 能接受的字节范围
• Age 推算资源创建经过时间
• Location 令客户端重定向的 URI ✨
• vary 代理服务器的缓存信息
• ETag 能够表示资源唯一资源的字符串 ✨
• WWW-Authenticate 服务器要求客户端的验证信息
• Proxy-Authenticate 代理服务器要求客户端的验证信息
• Server 服务器的信息 ✨
• Retry-After 和状态码 503 一起使用的首部字段，表示下次请求服务器的时间

实体首部字段（Entiy Header Fields）:针对请求报文和响应报文的实体部分使用首部

• Allow 资源可支持 http 请求的方法 ✨
• Content-Language 实体的资源语言
• Content-Encoding 实体的编码格式
• Content-Length 实体的大小（字节）
• Content-Type 实体媒体类型
• Content-MD5 实体报文的摘要
• Content-Location 代替资源的 yri
• Content-Rnages 实体主体的位置返回
• Last-Modified 资源最后的修改资源 ✨
• Expires 实体主体的过期资源 ✨

聊一聊 HTTP 的状态码有哪些？

2XX 成功

• 200 OK，表示从客户端发来的请求在服务器端被正确处理 ✨
• 201 Created 请求已经被实现，而且有一个新的资源已经依据请求的需要而建立
• 202 Accepted 请求已接受，但是还没执行，不保证完成请求
• 204 No content，表示请求成功，但响应报文不含实体的主体部分
• 206 Partial Content，进行范围请求 ✨

3XX 重定向

• 301 moved permanently，永久性重定向，表示资源已被分配了新的 URL
• 302 found，临时性重定向，表示资源临时被分配了新的 URL ✨
• 303 see other，表示资源存在着另一个 URL，应使用 GET 方法丁香获取资源
• 304 not modified，表示服务器允许访问资源，但因发生请求未满足条件的情况
• 307 temporary redirect，临时重定向，和 302 含义相同

4XX 客户端错误

• 400 bad request，请求报文存在语法错误 ✨
• 401 unauthorized，表示发送的请求需要有通过 HTTP 认证的认证信息 ✨
• 403 forbidden，表示对请求资源的访问被服务器拒绝 ✨
• 404 not found，表示在服务器上没有找到请求的资源 ✨
• 408 Request timeout, 客户端请求超时
• 409 Confict, 请求的资源可能引起冲突

5XX 服务器错误

• 500 internal sever error，表示服务器端在执行请求时发生了错误 ✨
• 501 Not Implemented 请求超出服务器能力范围，例如服务器不支持当前请求所需要的某个功能，或者请求是服务器不支持的某个方法
• 503 service unavailable，表明服务器暂时处于超负载或正在停机维护，无法处理请求
• 505 http version not supported 服务器不支持，或者拒绝支持在请求中使用的 HTTP 版本

同样是重定向 307，303，302 的区别？

302 是 http1.0 的协议状态码，在 http1.1 版本的时候为了细化 302 状态码又出来了两个 303 和 307。

303 明确表示客户端应当采用 get 方法获取资源，他会把 POST 请求变为 GET 请求进行重定向。 307 会遵照浏览器标准，不会从 post 变为 get。

HTTP 的 keep-alive 是干什么的？

在早期的 HTTP/1.0 中，每次 http 请求都要创建一个连接，而创建连接的过程需要消耗资源和时间，为了减少资源消耗，缩短响应时间，就需要重用连接。在后来的 HTTP/1.0 中以及 HTTP/1.1 中，引入了重用连接的机制，就是在 http 请求头中加入 Connection: keep-alive 来告诉对方这个请求响应完成后不要关闭，下一次咱们还用这个请求继续交流。协议规定 HTTP/1.0 如果想要保持长连接，需要在请求头中加上 Connection: keep-alive。

keep-alive 的优点：

• 较少的 CPU 和内存的使用（由于同时打开的连接的减少了）
• 允许请求和应答的 HTTP 管线化
• 降低拥塞控制 （TCP 连接减少了）
• 减少了后续请求的延迟（无需再进行握手）
• 报告错误无需关闭 TCP 连

为什么有了 HTTP 为什么还要 HTTPS？

https 是安全版的 http，因为 http 协议的数据都是明文进行传输的，所以对于一些敏感信息的传输就很不安全，HTTPS 就是为了解决 HTTP 的不安全而生的。

HTTPS 是如何保证安全的？

过程比较复杂，我们得先理解两个概念

对称加密：即通信的双方都使用同一个秘钥进行加解密，比如特务接头的暗号，就属于对称加密

对称加密虽然很简单性能也好，但是无法解决首次把秘钥发给对方的问题，很容易被 hacker 拦截秘钥。

非对称加密：

1. 私钥 + 公钥= 密钥对
2. 即用私钥加密的数据,只有对应的公钥才能解密,用公钥加密的数据,只有对应的私钥才能解密
3. 因为通信双方的手里都有一套自己的密钥对,通信之前双方会先把自己的公钥都先发给对方
4. 然后对方再拿着这个公钥来加密数据响应给对方,等到到了对方那里,对方再用自己的私钥进行解密

非对称加密虽然安全性更高，但是带来的问题就是速度很慢，影响性能。

解决方案：

那么结合两种加密方式，将对称加密的密钥使用非对称加密的公钥进行加密，然后发送出去，接收方使用私钥进行解密得到对称加密的密钥，然后双方可以使用对称加密来进行沟通。

此时又带来一个问题，中间人问题：

如果此时在客户端和服务器之间存在一个中间人,这个中间人只需要把原本双方通信互发的公钥,换成自己的公钥,这样中间人就可以轻松解密通信双方所发送的所有数据。

所以这个时候需要一个安全的第三方颁发证书（CA），证明身份的身份，防止被中间人攻击。

证书中包括：签发者、证书用途、使用者公钥、使用者私钥、使用者的 HASH 算法、证书到期时间等

但是问题来了，如果中间人篡改了证书，那么身份证明是不是就无效了？这个证明就白买了，这个时候需要一个新的技术，数字签名。

数字签名就是用 CA 自带的 HASH 算法对证书的内容进行 HASH 得到一个摘要，再用 CA 的私钥加密，最终组成数字签名。

当别人把他的证书发过来的时候,我再用同样的 Hash 算法,再次生成消息摘要，然后用 CA 的公钥对数字签名解密,得到 CA 创建的消息摘要,两者一比,就知道中间有没有被人篡改了。

这个时候就能最大程度保证通信的安全了。

HTTP2 相对于 HTTP1.x 有什么优势和特点？

二进制分帧

帧：HTTP/2 数据通信的最小单位消息：指 HTTP/2 中逻辑上的 HTTP 消息。例如请求和响应等，消息由一个或多个帧组成。

流：存在于连接中的一个虚拟通道。流可以承载双向消息，每个流都有一个唯一的整数 ID

HTTP/2 采用二进制格式传输数据，而非 HTTP 1.x 的文本格式，二进制协议解析起来更高效。

服务器推送

服务端可以在发送页面 HTML 时主动推送其它资源，而不用等到浏览器解析到相应位置，发起请求再响应。例如服务端可以主动把 JS 和 CSS 文件推送给客户端，而不需要客户端解析 HTML 时再发送这些请求。

服务端可以主动推送，客户端也有权利选择是否接收。如果服务端推送的资源已经被浏览器缓存过，浏览器可以通过发送 RST_STREAM 帧来拒收。主动推送也遵守同源策略，服务器不会随便推送第三方资源给客户端。

头部压缩

HTTP/1.x 会在请求和响应中中重复地携带不常改变的、冗长的头部数据，给网络带来额外的负担。

• HTTP/2 在客户端和服务器端使用“首部表”来跟踪和存储之前发送的键－值对，对于相同的数据，不再通过每次请求和响应发送
• 首部表在 HTTP/2 的连接存续期内始终存在，由客户端和服务器共同渐进地更新;
• 每个新的首部键－值对要么被追加到当前表的末尾，要么替换表中之前的值。

你可以理解为只发送差异数据，而不是全部发送，从而减少头部的信息量

多路复用

HTTP 1.x 中，如果想并发多个请求，必须使用多个 TCP 链接，且浏览器为了控制资源，还会对单个域名有 6-8 个的 TCP 链接请求限制。

HTTP2 中：

• 同域名下所有通信都在单个连接上完成。
• 单个连接可以承载任意数量的双向数据流。
• 数据流以消息的形式发送，而消息又由一个或多个帧组成，多个帧之间可以乱序发送，因为根据帧首部的流标识可以重新组装

即时通讯的实现方式？

主要有四种方式，它们分别是轮询、长轮询(comet)、长连接(SSE)、WebSocket。它们大体可以分为两类，一种是在 HTTP 基础上实现的，包括短轮询、comet 和 SSE；另一种不是在 HTTP 基础上实现是，即 WebSocket。

1. 轮询 短轮询的基本思路就是浏览器每隔一段时间向浏览器发送 http 请求，服务器在收到请求后，不论是否有数据更新，都直接进行响应。这种方式实现的即时通信，本质上还是浏览器发送请求，服务器接受请求的一个过程，通过让客户端不断的进行请求，使得客户端能够模拟实时地收到服务器端的数据的变化。 优点：比较简单，易于理解，实现起来没有什么技术难点。 缺点：由于需要不断的建立 http 连接，严重浪费了服务器端和客户端的资源。
2. 长轮询 当服务器收到客户端发来的请求后，服务器端不会直接进行响应，而是先将这个请求挂起，然后判断服务器端数据是否有更新。如果有更新，则进行响应；如果一直没有数据，则到达一定的时间限制(服务器端设置)才返回。 优点：长轮询和短轮询比起来，明显减少了很多不必要的 http 请求次数，相比之下节约了资源。 缺点：连接挂起也会导致资源的浪费。
3. 长连接SSE是 HTML 5 新增的功能，全称为Server-Sent Events。它可以允许服务推送数据到客户端。SSE 在本质上就与之前的长轮询、短轮询不同，虽然都是基于 http 协议的，但是轮询需要客户端先发送请求。而 SSE 最大的特点就是不需要客户端发送请求，可以实现只要服务器端数据有更新，就可以马上发送到客户端。 优点：不需要建立或保持大量的客户端发往服务器端的请求，节约了很多资源，提升应用性能；实现非常简单，并且不需要依赖其他插件。
4. WebSocket WebSocket 是 HTML 5 定义的一个新协议，与传统的 http 协议不同，该协议可以实现服务器与客户端之间全双工通信。简单来说，首先需要在客户端和服务器端建立起一个连接，这部分需要 http。连接一旦建立，客户端和服务器端就处于平等的地位，可以相互发送数据，不存在请求和响应的区别。 优点：实现了双向通信。 缺点：服务器端的逻辑非常复杂

问题参考链接

2023 高频前端面试题合集之网络篇

谈谈前端需要学习的计网知识和热门面试题

【1 月最新】前端 100 问：能搞懂 80% 的请把简历给我

2021 年我的前端面试准备

12 道腾讯前端面试真题及答案整理

🔥 连八股文都不懂还指望在前端混下去么

阿里前端攻城狮们写了一份前端面试题答案，请查收

手撕钉钉前端考试卷，offer，拿来吧你~

在阿里我是如何当面试官的

前端万字面经——基础篇

前端面试必会网络系列面试题汇总

面试官（9）：可能是全网最全的 http 面试答案

2023 前端面试系列--网络篇