协议

什么是跨域

跨域本质是浏览器基于同源策略的一种安全手段 同源策略(Sameoriginpolicy)，是一种约定，它是浏览器最核心也最基本的安全功能 所谓同源(即指在同一个域)具有以下三个相同点

• 协议相同(protocol)
• 主机相同(host)
• 端口相同(port)

反之非同源请求，也就是协议、端口、主机其中一项不相同的时候，这时候就会产生跨域

一定要注意跨域是浏览器的限制，你用抓包工具抓取接口数据，是可以看到接口已经把数据返回回来了，只是浏览器的限制，你获取不到数据。用 postman 请求接口能够请求到数据。这些再次印证了跨域是浏览器的限制。

浏览器的地址栏输入 URL 并按下回车

• 浏览器查找当前 URL 是否存在缓存，并比较缓存是否过期。
• DNS 解析 URL 对应的 IP。
• 根据 IP 建立 TCP 连接（三次握手）。
• HTTP 发起请求。
• 服务器处理请求，浏览器接收 HTTP 响应。
• 渲染页面，构建 DOM 树。
• 关闭 TCP 连接（四次挥手）。

http https 区别

• 安全性：HTTP 是一种无加密的传输协议，数据在传输过程中可能被截获或被篡改。而 HTTPS 则通过 SSL/TLS 协议进行加密传输，确保数据在传输过程中的安全，防止数据被窃取或篡改。
• 连接方式：HTTP 使用的是明文传输，而 HTTPS 则通过 SSL/TLS 协议进行加密传输。这种加密方式可以保护数据在传输过程中的安全，防止数据被窃取或篡改。
• 证书管理：HTTPS 需要使用 CA（证书颁发机构）颁发的证书来进行加密和解密操作，而 HTTP 则不需要证书。因此，在使用 HTTPS 时，需要配置证书，而 HTTP 则不需要。
• 连接状态：HTTPS 连接在数据传输过程中始终保持加密状态，即使用户与服务器之间的连接在传输过程中被截断，也不会影响数据的加密状态。而 HTTP 的连接是明文的，一旦被截断，数据就可能被窃取或篡改。
• 端口号：HTTP 和 HTTPS 使用的端口号不同，HTTP 默认使用 80 端口，而 HTTPS 默认使用 443 端口。
• 资源消耗：由于 HTTPS 使用了加密和解密操作，因此在数据传输过程中需要消耗更多的计算资源。

总的来说，HTTPS 相较于 HTTP 提供了更高的安全性，但也会带来一定的性能开销。在实际应用中，应根据具体需求和安全要求来选择合适的协议。

http协议 websocket 区别

HTTP（超文本传输协议）和WebSocket在Web通信中扮演着不同的角色，它们之间存在多个显著的区别。以下是它们之间主要区别的详细解析：

一、协议定义与通信模式

• HTTP：
  • 是一种用于在Web上进行数据通信的协议。
  • 采用请求-响应模式，即客户端发送请求，服务器响应请求。
  • 通常运行在TCP协议之上，但本身是一个单向的通信协议。
• WebSocket：
  • 是一种在单个TCP连接上进行全双工通信的协议。
  • 允许服务器和客户端之间建立持久性的连接，并进行双向数据传输。
  • 一旦连接建立，双方都可以随时发送数据，无需像HTTP那样每次都需要客户端发起请求。

二、连接特性

• 连接方式：
  • HTTP连接是由客户端（如浏览器）发起的，服务器预先并不知道这个连接。
  • WebSocket连接则需要浏览器和服务器进行握手来建立，握手过程基于HTTP协议，但之后的数据传输则不再使用HTTP。
• 连接长度：
  • HTTP连接通常是短连接，即每次请求-响应完成后，连接就会关闭。虽然可以通过Ajax等技术实现长轮询来保持一段时间内的连接，但本质上还是短连接。
  • WebSocket则是持久连接，一旦建立，就会保持开放状态，直到被显式关闭。

三、连接状态与数据传输

• 连接状态：
  • HTTP是无状态的单向连接，即服务器不保存任何关于客户端的信息，每个请求都是独立的。
  • WebSocket是有状态的双向连接，服务器和客户端都可以随时发送数据，且数据传输具有连续性。
• 数据传输：
  • HTTP使用Request/Response模型进行数据传输，即客户端发送请求，服务器返回响应。
  • WebSocket在连接建立后，数据的传输使用帧来传递，不再需要Request消息。这使得WebSocket在实时性要求高的应用中具有优势。

四、应用场景

• HTTP：
  • 适用于大多数Web应用中的页面请求、资源加载等场景。
  • 由于其简单性和广泛的支持性，HTTP仍然是Web通信的基础协议。
• WebSocket：
  • 适用于需要实时交互和数据推送的场景，如实时聊天、实时协作、实时数据推送、多人在线游戏、在线客服等。
  • WebSocket的持久连接和双向通信特性使得这些应用能够实现更高效、更实时的数据交换。

五、其他区别

• 协议标识：
  • HTTP的URL以http://或https://开头。
  • WebSocket的URL则以ws://（非加密）或wss://（加密）开头。
• 安全性：
  • HTTP的传输是明文的，容易被网络攻击者窃取或篡改数据。但HTTPS（HTTP Secure）提供了加密传输的安全机制。
  • WebSocket同样支持加密传输（通过wss://），以保证数据传输的安全性。

综上所述，HTTP和WebSocket在协议定义、通信模式、连接特性、连接状态与数据传输以及应用场景等方面都存在显著的区别。选择哪种协议取决于具体的应用需求和场景。

OSI 七层模型

• 物理层
• 数据链路层
• 网络层
• 传输层 TCP UDP就是在这一层
• 会话层
• 表示层
• 应用层 HTTP，HTTPS，FTP，POP3、SMTP、Websocket等在这一层。

TCP 三次握手

第一次握手：

• 客户端向服务器发送一个 SYN 报文段。这个 SYN 报文段中包含客户端的初始序列号（seq=x），并请求建立连接。同时，客户端进入 SYN_SENT 状态，等待服务器的确认。

  服务器端得到结论：客户端的发送能力、服务端的接收能力是正常的。

第二次握手：

• 服务器收到客户端的 SYN 报文段后，会向客户端回复一个 SYN+ACK 报文段。这个报文段中包含对客户端初始序列号的确认（ack=x+1），表示服务器已经收到了客户端的请求。同时，服务器也会发送自己的初始序列号（seq=y），表明自己也准备好了发送数据。此时，服务器进入 SYN_RECV 状态。

  客户端得到结论：服务器的接收、发送能力，客户端的接收、发送能力正常。但是此时服务器并不能确定客户端的接收能力是否正常。

第三次握手：

• 客户端收到服务器的 SYN+ACK 报文段后，会向服务器发送一个 ACK 报文段。这个报文段中包含对服务器初始序列号的确认（ack=y+1），表示客户端已经准备好接收服务器发送的数据。此时，客户端和服务器都进入 ESTABLISHED 状态，表示连接已经成功建立，双方可以开始传输数据了。

  服务器端得到结论：客户端接收、发送能力正常，服务器端接收、发送能力正常。

为什么是 三次握手不是两次或四次?

• 三次握手既保证了连接的可靠性，又避免了不必要的复杂性和开销，客户端和服务器能够确保双方的发送和接收能力都是正常的，并且可以开始安全、可靠地传输数据。

• 在两次握手中，客户端发送 SYN 包给服务器，服务器收到后回复 SYN+ACK 包，这样看似完成了连接的建立。然而，这种设计存在潜在的问题。如果客户端发送的 SYN 包在网络中由于某种原因（如网络拥塞或丢包）没有到达服务器，客户端在超时后会重发 SYN 包。但如果此时第一次发送的 SYN 包在延迟后到达了服务器，服务器会回复 SYN+ACK 包，而客户端实际上并没有收到这个回复（因为它在等待第二次发送的 SYN 包的回复），那么服务器就会认为连接已经建立并等待客户端发送数据，而客户端则会因为未收到回复而继续重发 SYN 包，这就导致了一个半开连接（half-open connection）的状态，即服务器认为连接已建立而客户端则认为连接未建立。

• 在三次握手之后，客户端和服务器已经相互确认了对方的发送和接收能力，并且已经交换了初始序列号，可以开始传输数据了。增加更多的握手次数并不会带来额外的可靠性或安全性提升，反而会增加通信的开销和延迟，TCP 协议的设计也力求简洁和高效，过多的握手次数会增加协议的复杂性，降低性能。

TCP 四次挥手

• 第一次挥手：客户端向服务器发送一个 FIN 数据包（FIN=1，seq=u），用来关闭客户端到服务器的数据传送，并告诉服务器：我要跟你断开连接了，不会再给你发数据了。此时客户端还是可以接收数据的，如果一直没有收到被动连接方的确认包，则可以重新发送这个包。客户端此时进入 FIN_WAIT1 状态。

• 第二次挥手：服务器收到 FIN 包后，发送一个 ACK 给客户端，确认序号为收到序号+1（ACK=1，ack=u+1），此时 TCP 连接处于半关闭状态，即客户端已经没有要发送的数据了，但服务器若发送数据，则客户端仍要接受。这个状态还要持续一段时间，即整个 CLOSE_WAIT 状态持续的时间。服务器端将最后一条信息发送完毕后，就进入 LAST_ACK 状态，准备关闭服务器端到客户端的数据传送。

• 第三次挥手：服务器发送一个 FIN，用来关闭服务器到客户端的数据传送，服务器进入 LAST_ACK 状态。

• 第四次挥手：客户端收到 FIN 后，客户端进入 TIME_WAIT 状态，接着发送一个 ACK 给服务器，确认序号为收到序号+1，服务器进入 CLOSED 状态，完成四次挥手。

TCP 与 UDP 协议的区别

• 可靠性，tcp 提供可靠的数据传输，保证数据的完整性和有序性，udp 是无连接的协议；
• 速度，tcp 相对 udp 更加复杂，在传输效率上稍低一些；
• 连接性，tcp 是面向连接的协议，它通过建立连接来进行数据传输，udp 是无连接的协议，可以直接发送数据；
• 数据包大小，tcp 在传输数据时，将数据分割成较小的数据块，udp 的数据包大小没有限制。
• TCP 应用场景： 效率要求相对低，但对准确性要求相对高的场景。因为传输中需要对数据确认、重发、排序等操作，相比之下效率没有 UDP 高。例如：文件传输（准确高要求高、但是速度可以相对慢）、接受邮件、远程登录。
• UDP 应用场景： 效率要求相对高，对准确性要求相对低的场景。例如：QQ 聊天、在线视频、网络语音电话（即时通讯，速度要求高，但是出现偶尔断续不是太大问题，并且此处完全不可以使用重发机制）、广播通信（广播、多播）。

常见的 HTTP 请求方法

• GET: 向服务器获取数据；

• POST：将实体提交到指定的资源，通常会造成服务器资源的修改；

• PUT：上传文件，更新数据；

• DELETE：删除服务器上的对象；

• HEAD：获取报文首部，与 GET 相比，不返回报文主体部分；

• OPTIONS：询问支持的请求方法，用来跨域请求；

• CONNECT：要求在与代理服务器通信时建立隧道，使用隧道进行 TCP 通信；

• TRACE: 回显服务器收到的请求，主要⽤于测试或诊断。

GET 和 POST 的请求的区别

Post 和 Get 是 HTTP 请求的两种方法，其区别如下：

• **应用场景：**GET 请求是一个幂等的请求，一般 Get 请求用于对服务器资源不会产生影响的场景，比如说请求一个网页的资源。而 Post 不是一个幂等的请求，一般用于对服务器资源会产生影响的情景，比如注册用户这一类的操作。

• **是否缓存：**因为两者应用场景不同，浏览器一般会对 Get 请求缓存，但很少对 Post 请求缓存。

• **发送的报文格式：**Get 请求的报文中实体部分为空，Post 请求的报文中实体部分一般为向服务器发送的数据。

• **安全性：**Get 请求可以将请求的参数放入 url 中向服务器发送，这样的做法相对于 Post 请求来说是不太安全的，因为请求的 url 会被保留在历史记录中。

• **请求长度：**浏览器由于对 url 长度的限制，所以会影响 get 请求发送数据时的长度。这个限制是浏览器规定的，并不是 RFC 规定的。

• **参数类型：**post 的参数传递支持更多的数据类型。

POST 和 PUT 请求的区别

• PUT 请求是向服务器端发送数据，从而修改数据的内容，但是不会增加数据的种类等，也就是说无论进行多少次 PUT 操作，其结果并没有不同。（可以理解为时更新数据）
• POST 请求是向服务器端发送数据，该请求会改变数据的种类等资源，它会创建新的内容。（可以理解为是创建数据）

#OPTIONS 请求方法及使用场景

OPTIONS 是除了 GET 和 POST 之外的其中一种 HTTP 请求方法。

OPTIONS 方法是用于请求获得由Request-URI标识的资源在请求/响应的通信过程中可以使用的功能选项。通过这个方法，客户端可以在采取具体资源请求之前，决定对该资源采取何种必要措施，或者了解服务器的性能。该请求方法的响应不能缓存。

OPTIONS 请求方法的主要用途有两个：

• 获取服务器支持的所有 HTTP 请求方法；
• 用来检查访问权限。例如：在进行 CORS 跨域资源共享时，对于复杂请求，就是使用 OPTIONS 方法发送嗅探请求，以判断是否有对指定资源的访问权限。

对 WebSocket 的理解

WebSocket 是 HTML5 提供的一种浏览器与服务器进行全双工通讯的网络技术，属于应用层协议。它基于 TCP 传输协议，并复用 HTTP 的握手通道。浏览器和服务器只需要完成一次握手，两者之间就直接可以创建持久性的连接， 并进行双向数据传输。

WebSocket 的出现就解决了半双工通信的弊端。它最大的特点是：服务器可以向客户端主动推动消息，客户端也可以主动向服务器推送消息。

WebSocket 原理：客户端向 WebSocket 服务器通知（notify）一个带有所有接收者 ID（recipients IDs）的事件（event），服务器接收后立即通知所有活跃的（active）客户端，只有 ID 在接收者 ID 序列中的客户端才会处理这个事件。

WebSocket 特点的如下： ● 支持双向通信，实时性更强 ● 可以发送文本，也可以发送二进制数据‘’ ● 建立在 TCP 协议之上，服务端的实现比较容易 ● 数据格式比较轻量，性能开销小，通信高效 ● 没有同源限制，客户端可以与任意服务器通信 ● 协议标识符是 ws（如果加密，则为 wss），服务器网址就是 URL ● 与 HTTP 协议有着良好的兼容性。默认端口也是 80 和 443，并且握手阶段采用 HTTP 协议，因此握手时不容易屏蔽，能通过各种 HTTP 代理服务器。

Websocket 的使用方法如下：

在客户端中：

// 在index.html中直接写WebSocket，设置服务端的端口号为 9999
let ws = new WebSocket('ws://localhost:9999');
// 在客户端与服务端建立连接后触发
ws.onopen = function() {
    console.log("Connection open.");
    ws.send('hello');
};
// 在服务端给客户端发来消息的时候触发
ws.onmessage = function(res) {
    console.log(res);       // 打印的是MessageEvent对象
    console.log(res.data);  // 打印的是收到的消息
};
// 在客户端与服务端建立关闭后触发
ws.onclose = function(evt) {
  console.log("Connection closed.");
};

即时通讯的实现：短轮询、长轮询、SSE 和 WebSocket 间的区别？

短轮询和长轮询的目的都是用于实现客户端和服务器端的一个即时通讯。

**短轮询的基本思路：**浏览器每隔一段时间向服务器发送 http 请求，服务器端在收到请求后，不论是否有数据更新，都直接进行响应。这种方式实现的即时通信，本质上还是浏览器发送请求，服务器接受请求的一个过程，通过让客户端不断的进行请求，使得客户端能够模拟实时地收到服务器端的数据的变化。这种方式的优点是比较简单，易于理解。缺点是这种方式由于需要不断的建立 http 连接，严重浪费了服务器端和客户端的资源。当用户增加时，服务器端的压力就会变大，这是很不合理的。

**长轮询的基本思路：**首先由客户端向服务器发起请求，当服务器收到客户端发来的请求后，服务器端不会直接进行响应，而是先将这个请求挂起，然后判断服务器端数据是否有更新。如果有更新，则进行响应，如果一直没有数据，则到达一定的时间限制才返回。客户端 JavaScript 响应处理函数会在处理完服务器返回的信息后，再次发出请求，重新建立连接。长轮询和短轮询比起来，它的优点是明显减少了很多不必要的 http 请求次数，相比之下节约了资源。长轮询的缺点在于，连接挂起也会导致资源的浪费。

**SSE 的基本思想：**它基于 HTTP 协议，易于实现和部署，特别适合那些需要服务器主动推送信息、客户端只需接收数据的场景。严格地说，http 协议无法做到服务器主动推送信息。但是，有一种变通方法，就是服务器向客户端声明，接下来要发送的是流信息。也就是说，发送的不是一次性的数据包，而是一个数据流，会连续不断地发送过来。这时，客户端不会关闭连接，会一直等着服务器发过来的新的数据流，视频播放就是这样的例子。SSE 就是利用这种机制，使用流信息向浏览器推送信息。目前除了 IE/Edge，其他浏览器都支持。它相对于前面两种方式来说，不需要建立过多的 http 请求，相比之下节约了资源。

WebSocket 是 HTML5 定义的一个新协议议，与传统的 http 协议不同，该协议允许由服务器主动的向客户端推送信息。使用 WebSocket 协议的缺点是在服务器端的配置比较复杂。WebSocket 是一个全双工的协议，也就是通信双方是平等的，可以相互发送消息，而 SSE 的方式是单向通信的，只能由服务器端向客户端推送信息，如果客户端需要发送信息就是属于下一个 http 请求了。

上面的四个通信协议，前三个都是基于 HTTP 协议的。

对于这四种即使通信协议，从性能的角度来看：

WebSocket > 长连接（SEE） > 长轮询 > 短轮询

但是，我们如果考虑浏览器的兼容性问题，顺序就恰恰相反了：

短轮询 > 长轮询 > 长连接（SEE） > WebSocket

所以，还是要根据具体的使用场景来判断使用哪种方式。

websocket 心跳机制（保活机制）

• 使用 setInterval 定时发送心跳包。

• 在前端监听到 WebSocket 的 onclose()事件时，重新创建 WebSocket 连接。

  第一种方式会对服务器造成很大的压力，因为即使 WebSocket 连接正常，也要定时发送心跳包，从而消耗服务器资源。第二种方式虽然减轻了服务器的负担，但是在重连时可能会丢失一些数据。

参考：https://download.csdn.net/blog/column/11572470/133860215

https://blog.csdn.net/m0_74265396/article/details/134340520

HTTP 状态码

状态码的类别：

类别	原因	描述
1xx	Informational(信息性状态码)	接受的请求正在处理
2xx	Success(成功状态码)	请求正常处理完毕
3xx	Redirection(重定向状态码)	需要进行附加操作一完成请求
4xx	Client Error (客户端错误状态码)	服务器无法处理请求
5xx	Server Error(服务器错误状态码)	服务器处理请求出错

1. 2XX (Success 成功状态码)

状态码 2XX 表示请求被正常处理了。

（1）200 OK

200 OK 表示客户端发来的请求被服务器端正常处理了。

（2）204 No Content

该状态码表示客户端发送的请求已经在服务器端正常处理了，但是没有返回的内容，响应报文中不包含实体的主体部分。一般在只需要从客户端往服务器端发送信息，而服务器端不需要往客户端发送内容时使用。

（3）206 Partial Content

该状态码表示客户端进行了范围请求，而服务器端执行了这部分的 GET 请求。响应报文中包含由 Content-Range 指定范围的实体内容。

2. 3XX (Redirection 重定向状态码)

3XX 响应结果表明浏览器需要执行某些特殊的处理以正确处理请求。

（1）301 Moved Permanently

永久重定向。

该状态码表示请求的资源已经被分配了新的 URI，以后应使用资源指定的 URI。新的 URI 会在 HTTP 响应头中的 Location 首部字段指定。若用户已经把原来的 URI 保存为书签，此时会按照 Location 中新的 URI 重新保存该书签。同时，搜索引擎在抓取新内容的同时也将旧的网址替换为重定向之后的网址。

使用场景：

• 当我们想换个域名，旧的域名不再使用时，用户访问旧域名时用 301 就重定向到新的域名。其实也是告诉搜索引擎收录的域名需要对新的域名进行收录。
• 在搜索引擎的搜索结果中出现了不带 www 的域名，而带 www 的域名却没有收录，这个时候可以用 301 重定向来告诉搜索引擎我们目标的域名是哪一个。

（2）302 Found

临时重定向。

该状态码表示请求的资源被分配到了新的 URI，希望用户（本次）能使用新的 URI 访问资源。和 301 Moved Permanently 状态码相似，但是 302 代表的资源不是被永久重定向，只是临时性质的。也就是说已移动的资源对应的 URI 将来还有可能发生改变。若用户把 URI 保存成书签，但不会像 301 状态码出现时那样去更新书签，而是仍旧保留返回 302 状态码的页面对应的 URI。同时，搜索引擎会抓取新的内容而保留旧的网址。因为服务器返回 302 代码，搜索引擎认为新的网址只是暂时的。

使用场景：

• 当我们在做活动时，登录到首页自动重定向，进入活动页面。
• 未登陆的用户访问用户中心重定向到登录页面。
• 访问 404 页面重新定向到首页。

（3）303 See Other

该状态码表示由于请求对应的资源存在着另一个 URI，应使用 GET 方法定向获取请求的资源。

303 状态码和 302 Found 状态码有着相似的功能，但是 303 状态码明确表示客户端应当采用 GET 方法获取资源。

303 状态码通常作为 PUT 或 POST 操作的返回结果，它表示重定向链接指向的不是新上传的资源，而是另外一个页面，比如消息确认页面或上传进度页面。而请求重定向页面的方法要总是使用 GET。

注意：

• 当 301、302、303 响应状态码返回时，几乎所有的浏览器都会把 POST 改成 GET，并删除请求报文内的主体，之后请求会再次自动发送。
• 301、302 标准是禁止将 POST 方法变成 GET 方法的，但实际大家都会这么做。

（4）304 Not Modified

浏览器缓存相关。

该状态码表示客户端发送附带条件的请求时，服务器端允许请求访问资源，但未满足条件的情况。304 状态码返回时，不包含任何响应的主体部分。304 虽然被划分在 3XX 类别中，但是和重定向没有关系。

带条件的请求（Http 条件请求）：使用 Get 方法 请求，请求报文中包含（if-match、if-none-match、if-modified-since、if-unmodified-since、if-range）中任意首部。

状态码 304 并不是一种错误，而是告诉客户端有缓存，直接使用缓存中的数据。返回页面的只有头部信息，是没有内容部分的，这样在一定程度上提高了网页的性能。

（5）307 Temporary Redirect

**307 表示临时重定向。**该状态码与 302 Found 有着相同含义，尽管 302 标准禁止 POST 变成 GET，但是实际使用时还是这样做了。

307 会遵守浏览器标准，不会从 POST 变成 GET。但是对于处理请求的行为时，不同浏览器还是会出现不同的情况。规范要求浏览器继续向 Location 的地址 POST 内容。规范要求浏览器继续向 Location 的地址 POST 内容。

3. 4XX (Client Error 客户端错误状态码)

4XX 的响应结果表明客户端是发生错误的原因所在。

（1）400 Bad Request

该状态码表示请求报文中存在语法错误。当错误发生时，需修改请求的内容后再次发送请求。另外，浏览器会像 200 OK 一样对待该状态码。

（2）401 Unauthorized

该状态码表示发送的请求需要有通过 HTTP 认证(BASIC 认证、DIGEST 认证)的认证信息。若之前已进行过一次请求，则表示用户认证失败

返回含有 401 的响应必须包含一个适用于被请求资源的 WWW-Authenticate 首部用以质询(challenge)用户信息。当浏览器初次接收到 401 响应，会弹出认证用的对话窗口。

以下情况会出现 401：

• 401.1 - 登录失败。
• 401.2 - 服务器配置导致登录失败。
• 401.3 - 由于 ACL 对资源的限制而未获得授权。
• 401.4 - 筛选器授权失败。
• 401.5 - ISAPI/CGI 应用程序授权失败。
• 401.7 - 访问被 Web 服务器上的 URL 授权策略拒绝。这个错误代码为 IIS 6.0 所专用。

（3）403 Forbidden

该状态码表明请求资源的访问被服务器拒绝了，服务器端没有必要给出详细理由，但是可以在响应报文实体的主体中进行说明。进入该状态后，不能再继续进行验证。该访问是永久禁止的，并且与应用逻辑密切相关。

IIS 定义了许多不同的 403 错误，它们指明更为具体的错误原因：

• 403.1 - 执行访问被禁止。
• 403.2 - 读访问被禁止。
• 403.3 - 写访问被禁止。
• 403.4 - 要求 SSL。
• 403.5 - 要求 SSL 128。
• 403.6 - IP 地址被拒绝。
• 403.7 - 要求客户端证书。
• 403.8 - 站点访问被拒绝。
• 403.9 - 用户数过多。
• 403.10 - 配置无效。
• 403.11 - 密码更改。
• 403.12 - 拒绝访问映射表。
• 403.13 - 客户端证书被吊销。
• 403.14 - 拒绝目录列表。
• 403.15 - 超出客户端访问许可。
• 403.16 - 客户端证书不受信任或无效。
• 403.17 - 客户端证书已过期或尚未生效
• 403.18 - 在当前的应用程序池中不能执行所请求的 URL。这个错误代码为 IIS 6.0 所专用。
• 403.19 - 不能为这个应用程序池中的客户端执行 CGI。这个错误代码为 IIS 6.0 所专用。
• 403.20 - Passport 登录失败。这个错误代码为 IIS 6.0 所专用。

（4）404 Not Found

该状态码表明服务器上无法找到请求的资源。除此之外，也可以在服务器端拒绝请求且不想说明理由时使用。

以下情况会出现 404：

• 404.0 -（无） – 没有找到文件或目录。
• 404.1 - 无法在所请求的端口上访问 Web 站点。
• 404.2 - Web 服务扩展锁定策略阻止本请求。
• 404.3 - MIME 映射策略阻止本请求。

（5）405 Method Not Allowed

该状态码表示客户端请求的方法虽然能被服务器识别，但是服务器禁止使用该方法。GET 和 HEAD 方法，服务器应该总是允许客户端进行访问。客户端可以通过 OPTIONS 方法（预检）来查看服务器允许的访问方法, 如下

Access-Control-Allow-Methods: GET,HEAD,PUT,PATCH,POST,DELETE

4. 5XX (Server Error 服务器错误状态码)

5XX 的响应结果表明服务器本身发生错误.

（1）500 Internal Server Error

该状态码表明服务器端在执行请求时发生了错误。也有可能是 Web 应用存在的 bug 或某些临时的故障。

（2）502 Bad Gateway

该状态码表明扮演网关或代理角色的服务器，从上游服务器中接收到的响应是无效的。注意，502 错误通常不是客户端能够修复的，而是需要由途经的 Web 服务器或者代理服务器对其进行修复。以下情况会出现 502：

• 502.1 - CGI （通用网关接口）应用程序超时。
• 502.2 - CGI （通用网关接口）应用程序出错。

（3）503 Service Unavailable

该状态码表明服务器暂时处于超负载或正在进行停机维护，现在无法处理请求。如果事先得知解除以上状况需要的时间，最好写入 RetryAfter 首部字段再返回给客户端。

使用场景：

• 服务器停机维护时，主动用 503 响应请求；
• nginx 设置限速，超过限速，会返回 503。

（4）504 Gateway Timeout

该状态码表示网关或者代理的服务器无法在规定的时间内获得想要的响应。他是 HTTP 1.1 中新加入的。

使用场景：代码执行时间超时，或者发生了死循环。

5. 总结

（1）2XX 成功

• 200 OK，表示从客户端发来的请求在服务器端被正确处理
• 204 No content，表示请求成功，但响应报文不含实体的主体部分
• 205 Reset Content，表示请求成功，但响应报文不含实体的主体部分，但是与 204 响应不同在于要求请求方重置内容
• 206 Partial Content，进行范围请求

（2）3XX 重定向

• 301 moved permanently，永久性重定向，表示资源已被分配了新的 URL
• 302 found，临时性重定向，表示资源临时被分配了新的 URL
• 303 see other，表示资源存在着另一个 URL，应使用 GET 方法获取资源
• 304 not modified，表示服务器允许访问资源，但因发生请求未满足条件的情况
• 307 temporary redirect，临时重定向，和 302 含义类似，但是期望客户端保持请求方法不变向新的地址发出请求

（3）4XX 客户端错误

• 400 bad request，请求报文存在语法错误
• 401 unauthorized，表示发送的请求需要有通过 HTTP 认证的认证信息
• 403 forbidden，表示对请求资源的访问被服务器拒绝
• 404 not found，表示在服务器上没有找到请求的资源

（4）5XX 服务器错误

• 500 internal sever error，表示服务器端在执行请求时发生了错误
• 501 Not Implemented，表示服务器不支持当前请求所需要的某个功能
• 503 service unavailable，表明服务器暂时处于超负载或正在停机维护，无法处理请求

6. 同样是重定向，307，303，302的区别？

302 是 http1.0 的协议状态码，在 http1.1 版本的时候为了细化 302 状态码⼜出来了两个 303 和 307。 303 明确表示客户端应当采⽤ get ⽅法获取资源，他会把 POST 请求变为 GET 请求进⾏重定向。 307 会遵照浏览器标准，不会从 post 变为 get。