### 什么叫路由？

路由器的英文是 Router，也就是「找路的工具」。找什么路？寻找各个网络节点之间的路。

换句话说，路由器就像是快递中转站，包裹会经过一个个的中转站，从遥远的地方寄到你家附近，数据包也是一样。

![image-20220714091434352](http://pic.nexopera.tech/62cf6dfc35f17.png)

路由器是连接两个网络的硬件设备，承担寻路功能，是网络的大门，因此，路由器又叫做网关设备（Gateway）。

### 路由表

路由器和交换机一样，也有自己的小本本，这个路由表上记载了到各个网络节点之间的路，会记录数据来源、相应的路由条目以及下一跳。

![image-20220714091446207](http://pic.nexopera.tech/62cf6e06cb313.png)

路由表就相当于路由器的导航，路由器只需要按照路由表的指示走就可以了。当然前提是，路由表中存在匹配该数据包目的 IP 地址的路由条目。路由表会周期性更新，当网络拓扑发生变化时也会更新，不用担心走错路。

![image-20220714091454435](http://pic.nexopera.tech/62cf6e0ee405e.png)

路由器收发数据包的流程

路由器在收发数据包的时候会先查看路由表，如果路由表里有匹配项，就会把数据包交给下一跳。如果没有匹配项，就会直接丢弃数据包，然后告诉主机，这个目的地不可达。

### 直连、静态路由、动态路由

路由条目的获取来源有很多种，比如说直连、静态路由和动态路由。

直连，也就是路由器的直接邻居。路由器会自己去认识邻居，然后记录下来。



当然，也可以通过手动添加的方式告诉路由器目的网段的路径，也就是静态路由，适合网络规模比较小的场景。但是当网络拓扑发生变化，或是规模扩大的时候，配置和维护的成本就会很高。

这时候就需要结合动态路由，让路由器通过动态的方式来学习。在大型网络中，往往采用这种动、静路由相结合的方式进行部署。

### 三层寻址

上期讲解的「二层寻址」，大家还记得吗？二层寻址就是交换机根据 MAC 地址，在物理层进行寻址。

三层寻址就是指路由器根据 IP 地址，在网络层进行寻址。

![image-20220714091504596](http://pic.nexopera.tech/62cf6e192bd05.png)

路由器三层寻址流程

当主机想要发送数据的时候，首先会查看目的地是否和自己在同一个网段，如果在同一个网段就会让交换机进行二层转发。

如下图所示，PC1 要给 PC2 发送数据，就会通过交换机来完成。

![image-20220714091523153](http://pic.nexopera.tech/62cf6e2ba1936.png)

如果不在同一个网段，主机会把数据包交给自己的路由器，路由器再根据目的 IP 查询自己的路由表，如果有匹配的条目，则交给下一跳，没有就丢弃。

如下图所示，PC1 要给 PC3 发送数据，发现 PC3 和自己不在同一个网段，就会把数据包交给路由器 A，再根据路由表的条目转发给路由器 B -> C，最后通过交换机 C 送达 PC3。

![image-20220714091535034](http://pic.nexopera.tech/62cf6e377b070.png)

### 寻路原则

既然路由器是负责找路的，那条条大路通罗马，哪条大路最近呢？

![image-20220714091550693](http://pic.nexopera.tech/62cf6e47ee2d9.png)

默认情况下，路由的查询遵循最长匹配原则，也就是掩码越长、越精确，路由器就会优先选择那条路。

然后考虑路径开销，比如说带宽、管理距离、度量值等。也就是如果从这条路走，要花上多少时间和金钱。绝大部分数据通信行为是双向的，考虑流量的时候，还要关注流量的往返，从这条路去，也得从这条路回来，回来的时候没路了，这也不行。

![image-20220714091600945](http://pic.nexopera.tech/62cf6e533bf4a.png)

路由查询的行为是逐跳的，到目标网络沿途的每个路由器都必须有关于该目标网段的路由信息。简单来说，数据包每经过一个路由器，路由器就会告诉它下一跳是谁，该往哪个方向走。

### 如何选择路由器？

路由器选型可以考虑这几个因素：带宽需求/转发性能、端口数量、带机量。

比如说家里拉了千兆宽带，那么路由器一定得是千兆路由器，还要满足千兆 NAT 转发的性能。顺带一提，运营商配的光猫是自带路由功能的，如果没有特殊需求，普通家庭一般够用了。

一般家用场景，路由端口用的不太多，可以通过交换机补充。大部分商用场景，4-12 口也就够了，再多的话，相信大部分企业会选择三层交换机。

带机量是一个很重要的指标，我们一般会考虑并发用户，还有用户的业务类型。

以 UniFi 的网关设备为例：USG 可以到 100 并发，普通家庭或小微企业，都足够用了；USG-Pro-4 带机量可以到 1000 并发，中小企业需求基本可以满足；如果还有更高需求，可以使用 UDM-Pro。

![image-20220714091613868](http://pic.nexopera.tech/62cf6e5e6245c.png)

路由器的工作原理



telnet 命令通常用来远程登录。telnet 程序是基于 TELNET 协议的远程登录客户端程序。Telnet 协议是 TCP/IP 协议族中的一员，是 Internet 远程登陆服务的标准协议和主要方式。它为用户提供了在本地计算机上完成远程主机工作的 能力。在终端使用者的电脑上使用 telnet 程序，用它连接到服务器。终端使用者可以在 telnet 程序中输入命令，这些命令会在服务器上运行，就像直接在服务器的控制台上输入一样。

可以在本地就能控制服务器。要开始一个 telnet 会话，必须输入用户名和密码来登录服务器。Telnet 是常用的远程控制 Web 服务器的方法。但是，telnet 因为采用明文传送报文，安全性不好，很多 Linux 服务器都不开放 telnet 服务，而改用更安全的 ssh 方式了。但仍然有很多别的系统可能采用了 telnet 方式来提供远程登录，因此弄清楚 telnet 客户端的使用方式仍是很有必要的。telnet 命令还可做别的用途，比如确定远程服务的状态，比如确定远程服务器的某个端口是否能访问。

**1．命令格式：**

```
telnet [参数][主机]
```

**2 ．命令功能：**

执行 telnet 指令开启终端机阶段作业，并登入远端主机。

**3．命令参数：**

```
-8 允许使用 8 位字符资料，包括输入与输出。

-a 尝试自动登入远端系统。

-b<主机别名> 使用别名指定远端主机名称。

-c 不读取用户专属目录里的。telnetrc 文件。

-d 启动排错模式。

-e<脱离字符> 设置脱离字符。

-E 滤除脱离字符。

-f 此参数的效果和指定"-F"参数相同。

-F 使用 Kerberos V5 认证时，加上此参数可把本地主机的认证数据上传到远端主机。

-k<域名> 使用 Kerberos 认证时，加上此参数让远端主机采用指定的领域名，而非该主机的域名。

-K 不自动登入远端主机。

-l<用户名称> 指定要登入远端主机的用户名称。

-L 允许输出 8 位字符资料。

-n<记录文件> 指定文件记录相关信息。

-r 使用类似 rlogin 指令的用户界面。

-S<服务类型> 设置 telnet 连线所需的 IP TOS 信息。

-x 假设主机有支持数据加密的功能，就使用它。

-X<认证形态> 关闭指定的认证形态。
```

**4．使用实例：**

**实例 1：远程服务器无法访问**

命令：

```
telnet 192.168.120.206
```

输出：

```
[root@localhost ~]# telnet 192.168.120.209
Trying 192.168.120.209...
telnet: connect to address 192.168.120.209: No route to host
telnet: Unable to connect to remote host: No route to host
[root@localhost ~]# 
```

说明：

处理这种情况方法：

1）确认 ip 地址是否正确？

2）确认 ip 地址对应的主机是否已经开机？

3）如果主机已经启动，确认路由设置是否设置正确？（使用 route 命令查看）

4）如果主机已经启动，确认主机上是否开启了 telnet 服务？（使用 netstat 命令查看，TCP 的 23 端口是否有 LISTEN 状态的行）

5）如果主机已经启动 telnet 服务，确认防火墙是否放开了 23 端口的访问？（使用 iptables-save 查看）

**实例 2：域名无法解析**

命令：

```
telnet www.baidu.com
```

输出：

```
[root@localhost ~]# telnet www.baidu.com
www.baidu.com/telnet: Temporary failure in name resolution
[root@localhost ~]# 
```

说明：

处理这种情况方法：

```
（1）确认域名是否正确
（2）确认本机的域名解析有关的设置是否正确（/etc/resolv.conf 中 nameserver 的设置是否正确，如果没有，可以使用 nameserver 8.8.8.8）
（3）确认防火墙是否放开了 UDP53 端口的访问（DNS 使用 UDP 协议，端口 53，使用 iptables-save 查看）
```

**实例 3：启动 telnet 服务**

命令：

```
service xinetd restart
```

输出：

```
[root@localhost ~]# cd /etc/xinetd.d/
[root@localhost xinetd.d]# ll
总计 124
-rw-r--r-- 1 root root 1157 2011-05-31 chargen-dgram
-rw-r--r-- 1 root root 1159 2011-05-31 chargen-stream
-rw-r--r-- 1 root root 523 2009-09-04 cvs
-rw-r--r-- 1 root root 1157 2011-05-31 daytime-dgram
-rw-r--r-- 1 root root 1159 2011-05-31 daytime-stream
-rw-r--r-- 1 root root 1157 2011-05-31 discard-dgram
-rw-r--r-- 1 root root 1159 2011-05-31 discard-stream
-rw-r--r-- 1 root root 1148 2011-05-31 echo-dgram
-rw-r--r-- 1 root root 1150 2011-05-31 echo-stream
-rw-r--r-- 1 root root 323 2004-09-09 eklogin
-rw-r--r-- 1 root root 347 2005-09-06 ekrb5-telnet
-rw-r--r-- 1 root root 326 2004-09-09 gssftp
-rw-r--r-- 1 root root 310 2004-09-09 klogin
-rw-r--r-- 1 root root 323 2004-09-09 krb5-telnet
-rw-r--r-- 1 root root 308 2004-09-09 kshell
-rw-r--r-- 1 root root 317 2004-09-09 rsync
-rw-r--r-- 1 root root 1212 2011-05-31 tcpmux-server
-rw-r--r-- 1 root root 1149 2011-05-31 time-dgram
-rw-r--r-- 1 root root 1150 2011-05-31 time-stream

[root@localhost xinetd.d]# cat krb5-telnet 
\# default: off
\# description: The kerberized telnet server accepts normal telnet sessions, \
\#       but can also use Kerberos 5 authentication.
service telnet
{
    flags      = REUSE
    socket_type   = stream    
    wait      = no
    user      = root
    server     = /usr/kerberos/sbin/telnetd
    log_on_failure += USERID
    disable     = yes
}
[root@localhost xinetd.d]# 
```

说明：

配置参数，通常的配置如下：

```
service telnet 

{ 
    disable = no #启用 
    flags = REUSE #socket 可重用 

    socket_type = stream #连接方式为 TCP 
    wait = no #为每个请求启动一个进程 

    user = root #启动服务的用户为 root 
    server = /usr/sbin/in.telnetd #要激活的进程 

    log_on_failure += USERID #登录失败时记录登录用户名 
} 
```

如果要配置允许登录的客户端列表，加入

```
only_from = 192.168.0.2 #只允许 192.168.0.2 登录 
```

如果要配置禁止登录的客户端列表，加入

```
no_access = 192.168.0.{2,3,4} #禁止 192.168.0.2、192.168.0.3、192.168.0.4 登录 
```

如果要设置开放时段，加入

```
access_times = 9:00-12:00 13:00-17:00 # 每天只有这两个时段开放服务（我们的上班时间：P） 
```

如果你有两个 IP 地址，一个是私网的 IP 地址如 192.168.0.2，一个是公网的 IP 地址如 218.75.74.83，如果你希望用户只能从私网来登录 telnet 服务，那么加入 bind = 192.168.0.2

各配置项具体的含义和语法可参考 xined 配置文件属性说明（man xinetd.conf） 配置端口，修改 services 文件：

```
\# vi /etc/services 

找到以下两句 

telnet 23/tcp 

telnet 23/udp 
```

如果前面有#字符，就去掉它。telnet 的默认端口是 23，这个端口也是黑客端口扫描的主要对象，因此最好将这个端口修改掉，修改的方法很简单，就是将 23 这个数字修改掉，改成大一点的数字，比如 61123。注意，1024 以下的端口号是 internet 保留的端口号，因此最好不要用，还应该注意不要与其它服务的端口冲突。

启动服务：

```
service xinetd restart 
```

实例 5：正常 telnet

命令：

```
telnet 192.168.120.204
```

输出：

```
[root@andy ~]# telnet 192.168.120.204
Trying 192.168.120.204...
Connected to 192.168.120.204 (192.168.120.204).
Escape character is '^]'.

  localhost (Linux release 2.6.18-274.18.1.el5 #1 SMP Thu Feb 9 12:45:44 EST 2012) (1)

login: root
Password: 
Login incorrect
```

说明：

一般情况下不允许 root 从远程登录，可以先用普通账号登录，然后再用 su -切到 root 用户。

telnet 命令使用方法详解

TCP协议学习

## 一、HTTP 状态码概述

### 1. 概念

当我们在浏览器输入URL并按下Enter键时，浏览器就会向站点的服务器发送一个HTTP请求，服务器接收并处理请求，然后将相关资源和HTTP标头一起返回。可以在浏览器的Network中查看 HTTP 的请求状态码：

![image-20221017130854173](http://pic.nexopera.tech/634ce37c313d7.png)

维基百科中对**HTTP状态码**的解释：

> HTTP状态码（HTTP Status Code）是用以表示网页服务器超文本传输协议响应状态的3位数字代码。它由 RFC 2616 规范定义的，并得到 RFC 2518、RFC 2817、RFC 2295、RFC 2774 与 RFC 4918 等规范扩展。所有状态码被分为五类，状态码的第一个数字代表了响应的五种状态之一。所示的消息短语是典型的，但是可以提供任何可读取的替代方案。除非另有说明，状态码是HTTP/1.1标准（RFC 7231）的一部分。

HTTP 状态代码是从 Web 服务器发送的 3 位代码（如 200 OK 或 404 Not Found），用于让我们和搜索引擎知道请求中是否存在任何错误或服务器尝试处理请求时是否存在任何问题。

### 2. 分类

应用通常就是客户端向服务器发出请求，服务器做出响应。状态码就是让我们知道 HTTP 请求是成功、失败还是其他。HTTP状态码通常分为五类：

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

### 3. 重要性

HTTP 状态代码对于诊断应用问题很重要，例如网络服务器是否无法正常工作且无法提供页面等。快速发现这些问题对于开发人员和搜索引擎提供良好的体验非常重要。那为什么 HTTP 状态代码和错误对搜索引擎优化 (SEO) 很重要呢？

搜索引擎机器人在抓取网站时会看到 HTTP 状态码。在某些情况下，这些会影响网页是否以及如何被编入索引，以及搜索引擎如何看待网站的健康状况。

一般来说，1XX 和 2XX 状态码不会对 SEO 产生太大影响。因为它们表明网站上是正常运行的，并使搜索引擎机器人能够继续执行操作。但是，它们并不会提高网站的排名。在大多数情况下，对 SEO 重要的是更高级别的代码。4XX 和 5XX 响应会阻止机器人抓取和索引页面。错误太多也可能表明网站质量不高，可能会降低网站的排名。

3XX 状态码与 SEO 的关系就会复杂很多。要想了解它们的影响，就需要了解永久重定向和临时重定向之间的区别，这里先不解释，后面再详细介绍。总之，对已经迁移的页面使用永久重定向会有更好的SEO。

可以使用 Google Search Console，在覆盖率报告中查看 3XX、4XX 和 5XX 的状态代码：

![image-20221017130901537](http://pic.nexopera.tech/634ce37d087df.png)

这个报告中会显示网站中四种类型的页面：

- 返回错误的页面；
- 有警告但是有效的页面；
- 有效的页面；
- 从索引中排除的页面；

我们可以在除了有效页面之外的三类中找到3XX、4XX、5XX 的HTTO状态码的页面，具体的话取决于状态码类型，比如301重定向可能会出现在最后一种中。

![image-20221017130906564](http://pic.nexopera.tech/634ce37db0b19.png)

4XX 和 5XX 状态码可能会出现在Error下。

## 二、HTTP 状态码列表

### 1. 1xx Informational

1XX的状态码是在HTTP/1.1 中引入的，它们是信息性的状态码，是临时的，表示请求已被接受，需要继续处理。这些状态码并没有提供太多有用的信息，我们可能永远看不到1XX相关的状态码。

#### （1）100 Continue

服务器已收到浏览器的请求标头，并且现在已准备好发送请求正文。这使得请求过程更加高效，因为它可以防止浏览器发送正文请求，即使标头已被拒绝。

#### （2）101 Switching Protocols

服务器已经接受了客户端的请求，并将通过`Upgrade`消息头通知客户端采用不同的协议来完成这个请求。在发送完这个响应最后的空行后，服务器将会切换到在Upgrade消息头中定义的协议。

#### （3）102 Processing

服务器已经收到并正在处理请求，目前还没有响应。这样可以防止客户端超时，并假设请求丢失。

#### （4）103 Early hints

在服务器响应的HTTP消息之前返回一些响应头。该状态码用于允许用户代理预加载资源，同时服务器准备响应。

### 2. 2xx Success

2xx 状态码表示客户端的请求被成功接收、理解和接受。

#### （1）200 OK

表示客户端发来的请求被服务器端正常处理了。从 SEO 的角度来看，200 OK 状态码是功能页面的完美状态码，所有链接页面都在正常工作。200 表示搜索引擎爬虫可以成功爬取该页面并将其放入其搜索引擎中。

#### （2）201 Created

服务器完成了浏览器的请求，因此创建了一个或多个新资源。

#### （3）202 Accepted

服务器已接受浏览器的请求，但仍在处理中。该请求最终可能会也可能不会进行响应。

#### （4）203 Non-authoritative Information

使用代理时可能会出现此状态代码。这意味着代理服务器从源服务器收到了 200 状态代码，但在将响应传递给浏览器之前已对其进行了修改。

#### （5）204 No Content

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

#### （6）205 Reset Content

服务器端成功处理了请求，且没有返回任何内容。但是与204响应不同，返回此状态码的响应要求请求者重置文档视图。该响应主要是被用于接受用户输入后，立即重置表单，以便用户能够轻松地开始另一次输入。

#### （7）206 Partial Content

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

#### （8）226 IM Used

服务器已成功处理浏览器的 GET 方法，以检索已缓存资源的更新版本。通常，当请求的资源有一个或多个轻微修改时返回响应。

### 3. 3xx Redirection

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

#### （1）300 Multiple Choices

有时，服务器可能会响应多种可能的资源来满足浏览器的请求。300 状态码意味着浏览器现在需要在它们之间进行选择。当有多个可用的文件类型扩展名时，可能会发生这种情况。

#### （2）301 Moved Permanently

**永久重定向。**已为目标资源分配了一个新的永久 URI。新的 URI 会在 HTTP 响应头中的 Location 首部字段指定。若用户已经把原来的URI保存为书签，此时会按照 Location 中新的URI重新保存该书签。同时，搜索引擎在抓取新内容的同时也将旧的网址替换为重定向之后的网址。

#### （3）302 Found

**临时重定向。**请求的资源被分配到了新的 URI，希望用户（本次）能使用新的 URI 访问资源。和 301 Moved Permanently 状态码相似，但是 302 代表的资源不是被永久重定向，只是临时性质的。也就是说已移动的资源对应的 URI 将来还有可能发生改变。

若用户把 URI 保存成书签，但不会像 301 状态码出现时那样去更新书签，而是仍旧保留返回 302 状态码的页面对应的 URI。同时，搜索引擎会抓取新的内容而保留旧的网址。因为服务器返回302代码，搜索引擎认为新的网址只是暂时的。

**使用场景：**

- 未登陆的用户访问用户中心重定向到登录页面。
- 访问404页面重新定向到首页。

#### （4）303 See Other

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

303 状态码和 302 Found 状态码有着相似的功能，但是 303 状态码明确表示客户端应当采用 GET 方法获取资源。303 状态码通常作为 PUT 或 POST 操作的返回结果，它表示重定向链接指向的不是新上传的资源，而是另外一个页面，比如消息确认页面或上传进度页面。而请求重定向页面的方法要总是使用 GET。

注意：

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

#### （5）304 Not Modified

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

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

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

#### （6）305 Use Proxy

服务器需要代理才能返回请求的资源。此响应代码当前未使用，因为当前大多数浏览器由于安全问题不支持它。

#### （7）307 Temporary Redirect

**临时重定向**。该状态码与 302 Found 有着相同含义，尽管 302 标准禁止 POST 变成 GET，但是实际使用时还是用了。307 会遵守浏览器标准，**不会从 POST 变成 GET**。但是对于处理请求的行为时，不同浏览器还是会出现不同的情况。规范要求浏览器继续向 Location 的地址 POST 内容。规范要求浏览器继续向 Location 的地址 POST 内容。

#### （8）308 Permanent Redirect

永久重定向，当前及未来的请求重定向到了新的 URL。

### 4. 4xx Client errors

#### （1）400 Bad Request

请求报文中存在语法错误。当错误发生时，需修改请求的内容后再次发送请求。

#### （2）401 Unauthorized

发送的请求需要有通过 HTTP 认证(BASIC 认证、DIGEST 认证)的认证信息。若之前已进行过一次请求，则表示用户认证失败。返回含有 401 的响应必须包含一个适用于被请求资源的 WWW-Authenticate 首部用以质询(challenge)用户信息。当浏览器初次接收到 401 响应，会弹出认证用的对话窗口。

#### （3）402 Payment Required

为数字支付系统保留的。不过，它并没有被广泛使用。

#### （4）403 Forbidden

客户端请求已被拒绝，因为客户端无权访问内容。与 401 不同，服务器知道客户端的身份，但由于他们无权查看内容，因此服务器拒绝提供正确的响应。

#### （5）404 Not Found

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

#### （6）405 Method Not Allowed

服务器识别到浏览器使用的 HTTP 请求方法，但需要使用不同的方法才能提供所需的资源。服务器应该总是允许客户端使用 GET 和 HEAD 方法进行访问。

客户端可以通过 OPTIONS 方法（预检）来查看服务器允许的访问方法, 如下

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

#### （7）406 Not Acceptable

服务器通知客户端没有资源符合浏览器请求的标准。

#### （8）407 Proxy Authentication Required

客户端必须首先通过代理进行身份验证。

#### （9）408 Request Timeout

当服务器在等待来自浏览器的完整请求时超时时会生成此状态码。换句话说，服务器没有收到浏览器发送的完整请求。一种可能的原因就是网络拥塞导致浏览器和服务器之间的数据包丢失。

#### （10）409 Conflict

服务器无法处理浏览器的请求，因为与相关资源存在冲突。这有时是由于多个同时编辑而发生的。

#### （11）410 Gone

请求的资源将来将不再可用。

#### （12）411 Length Required

请求的资源需要客户端指定一定的长度，通过 Content-Length 来定义。

#### （13）412 Precondition Failed

服务器不满足请求头字段中指示的一个或多个先决条件。

#### （14）413 Payload Too Large

服务器拒绝处理请求，因为请求的负载大于服务器能够或愿意处理的。虽然服务器可能会关闭连接以阻止客户端继续请求，但它应该生成一个 Retry-After 头字段以及客户端可以在多长时间后重试。

#### （15）414 Request-URI Too Long

浏览器发出的请求无法被服务器处理，因为客户端将太多数据编码为查询字符串，然后作为 GET 方法发送。

#### （16）415 Unsupported Media Type

请求已被服务器拒绝，因为它不支持请求数据的媒体格式。

#### （17）416 Requested Range Not Satisfiable

请求的 Range 头中指定的范围无法满足。原因可能是给定范围超出了目标 URI 数据的大小。

#### （18）417 Expectation Failed

服务器无法满足请求的请求头的 Expect 字段中指定的要求。

#### （19）421 Misdirected Request

浏览器的请求已被重定向到其他服务器，该服务器无法产生响应。

#### （20）422 Unprocessable Entity

浏览器发出的请求中存在语义错误，服务器无法处理。

#### （21）423 Locked

对所需资源的访问被拒绝，因为它已被锁定。

#### （22）424 Failed Dependency

浏览器发出的请求失败，因为它依赖于另一个请求，而该请求失败了。

#### （23）426 Upgrade Required

当服务器拒绝使用当前协议执行给定的请求时，它可能愿意在客户端升级到不同的协议后这来执行请求。

#### （24）428 Precondition Required

服务器要求在处理请求之前指定条件。

#### （25）429 Too Many Requests

用户在给定的时间内发送了太多请求（速率限制）时，这是由服务器生成的。这有时可能是由于机器人或脚本试图访问站点而造成的。

#### （26）431 Request Header Fields Too Large

服务器无法处理请求，因为标头字段太大。这可能是单个标头字段或所有标头字段存在问题。

#### （27）451 Unavailable For Legal Reasons

服务器的运营商收到了禁止访问请求的资源的要求。

#### （28）499 Client closed request

当 nginx 正在处理请求时，客户端关闭了连接，nginx 就会返回此状态码。

### 5. 5xx Server Error

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

#### （1）500 Internal Server Error

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

#### （2）501 Not Implemented

请求无法处理，因为服务器不支持。

#### （3）502 Bad Gateway

该扮演网关或代理角色的服务器从上游服务器中接收到的响应是无效的。注意，502 错误通常不是客户端能够修复的，而是需要由途经的服务器或者代理服务器对其进行修复

#### （4）503 Service Unavailable

服务器暂时处于超负载或正在进行停机维护，现在无法处理请求。

**使用场景：**

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

#### （5）504 Gateway Timeout

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

**使用场景：**

- 代码执行时间超时；
- 代码发生了死循环。

#### （6）505 HTTP Version Not Supported

请求中使用的 HTTP 版本不受服务器支持。

#### （7）506 Variant Also Negotiates

服务器内部配置错误。

#### （8）507 Insufficient Storage

服务器无法存储完成请求所必须的内容。

#### （9）508 Loop Detected

服务器在处理请求时检测到无限循环。

#### （10）510 Not Extended

服务器需要进一步扩展才能满足请求。

#### （11）511 Network Authentication Required

客户端需要进行身份验证才能获得访问权限。


HTTP 状态码概述

网络层协议--IP协议

Nexopera是一个专注于Linux、网络和运维等领域的博客网站。将为读者提供广泛的相关文章，涵盖操作系统、服务器管理、网络配置、安全性等多个主题。如果你是初学者，希望这里有适合你的内容。