计算机网络面试问题（汇总）

1、Http和Https的区别

• Http协议运行在TCP之上，明文传输，客户端与服务器端都无法验证对方的身份；
• Https是身披SSL(Secure Socket Layer)外壳的Http，运行于SSL上，SSL运行于TCP之上，是添加了加密和认证机制的HTTP。

二者之间存在如下不同：

不同	HTTP	HTTPS
端口不同	80	443
资源消耗	小	大 (由于加减密处理消耗更多的CPU和内存资源)
开销	小	大 (Https通信需要证书，而证书一般需要向认证机构购买)

• Https的加密机制是一种 共享密钥加密 和 公开密钥加密 并用 的混合加密机制。

2、对称加密与非对称加密

对称加密	非对称加密
加密和解密使用同一个密钥	使用一对非对称密钥，即公钥和私钥，公钥可以随意发布，但私钥只有自己知道。
算法公开、计算量小、加密速度快、加密效率高	安全

• 由于非对称加密的方式不需要发送用来解密的私钥，所以可以保证安全性；但是和对称加密比起来，它非常的慢，所以我们还是要用对称加密来传送消息，但对称加密所使用的密钥我们可以通过非对称加密的方式发送出去。

3、三次握手与四次挥手

三次握手与四次挥手详细解答

三次握手

• 客户端：我要对你讲话，你能听到吗；
• 服务端：我能听到；而且我也要对你讲话，你能听到吗；
• 客户端：我也能听到。
  …….
  互相开始通话
  ………

三次握手	操作
第一次握手	Client将标志位SYN置为1，随机产生一个值seq=J，并将该数据包发送给Server，Client进入SYN_SENT状态，等待Server确认。
第二次握手	Server收到数据包后由标志位SYN=1知道Client请求建立连接，Server将标志位SYN和ACK都置为1，ack=J+1，随机产生一个值seq=K，并将该数据包发送给Client以确认连接请求，Server进入SYN_RCVD状态。
第三次握手	Client收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，并将该数据包发送给Server，Server检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，Client和Server进入ESTABLISHED状态，完成三次握手，随后Client与Server之间可以开始传输数据了。

四次挥手

• 客户端：我说完了，我要闭嘴了；
• 服务端：我收到请求，我要闭耳朵了；
  （客户端收到这个确认，于是安心地闭嘴了。）
  …….
  服务端还没倾诉完自己的故事，于是继续唠唠叨叨向客户端说了半天，直到说完为止
  …….
• 服务端：我说完了，我也要闭嘴了；
• 客户端：我收到请求，我要闭耳朵了；（事实上，客户端为了保证这个确认包成功送达，等待了两个最大报文生命周期后，才闭上耳朵。）
  （服务端收到这个确认，于是安心地闭嘴了。）

四次挥手	操作
第一次挥手	Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。
第二次挥手	Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态。此时TCP链接处于半关闭状态，即客户端已经没有要发送的数据了，但服务端若发送数据，则客户端仍要接收。
第三次挥手	Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。
第四次挥手	Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。

4、为什么TCP链接需要三次握手，两次不可以么，为什么？

为了防止 已失效的链接请求报文突然又传送到了服务端，因而产生错误。

• 客户端发出的连接请求报文并未丢失，而是在某个网络节点长时间滞留了，以致延误到链接释放以后的某个时间才到达Server。这是，Server误以为这是Client发出的一个新的链接请求，于是就向客户端发送确认数据包，同意建立链接。
• 若不采用“三次握手”，那么只要Server发出确认数据包，新的链接就建立了。由于client此时并未发出建立链接的请求，所以其不会理睬Server的确认，也不与Server通信；而这时Server一直在等待Client的请求，这样Server就白白浪费了一定的资源。若采用“三次握手”，在这种情况下，由于Server端没有收到来自客户端的确认，则就会知道Client并没有要求建立请求，就不会建立链接。

5、TCP协议如何来保证传输的可靠性

TCP提供一种面向连接的、可靠的字节流服务。其中，面向连接意味着两个使用TCP的应用（通常是一个客户和一个服务器）在彼此交换数据之前必须先建立一个TCP连接。在一个TCP连接中，仅有两方进行彼此通信；而字节流服务意味着两个应用程序通过TCP链接交换8bit字节构成的字节流，TCP不在字节流中插入记录标识符。

可靠性	操作
数据包校验	目的是检测数据在传输过程中的任何变化，若校验出包有错，则丢弃报文段并且不给出响应，这时TCP发送数据端超时后会重发数据；
对失序数据包重排序	既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能会失序，因此TCP报文段的到达也可能会失序。TCP将对失序数据进行重新排序，然后才交给应用层；
丢弃重复数据	对于重复数据，能够丢弃重复数据；
应答机制	当TCP收到发自TCP连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒；
超时重发	当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段；
流量控制	TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据，这可以防止较快主机致使较慢主机的缓冲区溢出，这就是流量控制。TCP使用的流量控制协议是可变大小的滑动窗口协议。

6、客户端不断进行请求链接会怎样？DDos(Distributed Denial of Service)攻击？

• 服务器端会为每个请求创建一个链接，并向其发送确认报文，然后等待客户端进行确认

1)、DDos 攻击

• 客户端向服务端发送请求链接数据包
• 服务端向客户端发送确认数据包
• 客户端不向服务端发送确认数据包，服务器一直等待来自客户端的确认

2)、DDos 预防 ( 没有彻底根治的办法，除非不使用TCP )

• 限制同时打开SYN半链接的数目
• 缩短SYN半链接的Time out 时间
• 关闭不必要的服务

7、Get与POST的区别

• GET与POST是我们常用的两种HTTP Method，二者之间的区别主要包括如下五个方面：

区别	GET	POST
功能上	一般用来从服务器上获取资源	一般用来更新服务器上的资源
REST服务角度上	幂等的,不改变服务器上的资源	不是幂等的,会对服务器资源进行改变
请求参数形式上	请求的数据会附在URL之后	提交的数据放置在HTTP请求报文的请求体中。
安全性	低 (请求提交的数据将明文出现在URL上)	相对更安全(请求参数则被包装到请求体中)
请求的大小	请求的长度受限于浏览器或服务器对URL长度的限制，允许发送的数据量比较小	请求没有大小限制的。

8、TCP与UDP的区别

• TCP (Transmission Control Protocol)和UDP(User Datagram Protocol)协议属于传输层协议

区别	TCP	UDP
1	面向连接	面向非连接
2	可靠	不可靠
3	只支持点对点通信	支持一对一、一对多、多对一、多对多的通信模式
4	面向字节流的	面向报文的
5	有拥塞控制机制	没有拥塞控制，适合媒体通信
6	首部开销(20个字节)	首部开销(8个字节)

9、TCP的拥塞处理

• 计算机网络中的带宽、交换结点中的缓存及处理机等都是网络的资源。在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就会变坏，这种情况就叫做拥塞。拥塞控制就是 防止过多的数据注入网络中，这样可以使网络中的路由器或链路不致过载。注意，拥塞控制和流量控制不同，前者是一个全局性的过程，而后者指点对点通信量的控制。

处理方式	操作
慢启动	由小到大逐渐增加拥塞窗口的大小;
拥塞避免	拥塞避免算法让拥塞窗口缓慢增长
快重传	发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。
快恢复	当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把ssthresh门限减半，将cwnd设置为ssthresh的大小，然后执行拥塞避免算法。

10、从输入网址到获得页面的过程

步骤	操作
1	浏览器查询 DNS，获取域名对应的IP地址
2	浏览器获得域名对应的IP地址以后，浏览器向服务器请求建立链接，发起三次握手
3	TCP/IP链接建立起来后，浏览器向服务器发送HTTP请求
4	服务器接收到这个请求，并根据路径参数映射到特定的请求处理器进行处理，并将处理结果及相应的视图返回给浏览器
5	浏览器解析并渲染视图，若遇到对js文件、css文件及图片等静态资源的引用，则重复上述步骤并向服务器请求这些资源
6	浏览器根据其请求到的资源、数据渲染页面，最终向用户呈现一个完整的页面。

11、Session、Cookie 与 Application

• Cookie和Session都是客户端与服务器之间保持状态的解决方案，具体来说，cookie机制采用的是在客户端保持状态的方案，而session机制采用的是在服务器端保持状态的方案。

(1). Cookie及其相关API

Cookie实际上是一小段的文本信息。客户端请求服务器，如果服务器需要记录该用户状态，就使用response向客户端浏览器颁发一个Cookie，而客户端浏览器会把Cookie保存起来。当浏览器再请求该网站时，浏览器把请求的网址连同该Cookie一同提交给服务器，服务器检查该Cookie，以此来辨认用户状态。服务器还可以根据需要修改Cookie的内容。
　　
(2). Session及其相关API

同样地，会话状态也可以保存在服务器端。客户端请求服务器，如果服务器记录该用户状态，就获取Session来保存状态，这时，如果服务器已经为此客户端创建过session，服务器就按照sessionid把这个session检索出来使用；如果客户端请求不包含sessionid，则为此客户端创建一个session并且生成一个与此session相关联的sessionid，并将这个sessionid在本次响应中返回给客户端保存。保存这个sessionid的方式可以采用 cookie机制 ，这样在交互过程中浏览器可以自动的按照规则把这个标识发挥给服务器；若浏览器禁用Cookie的话，可以通过 URL重写机制 将sessionid传回服务器。

(3). Session 与 Cookie 的对比

对比	Session	Cookie
实现机制	Session的实现常常依赖于Cookie机制通过Cookie机制回传SessionID
大小限制	Session没有大小限制，理论上只与服务器的内存大小有关	Cookie有大小限制并且浏览器对每个站点也有cookie的个数限制
安全性	Session由于保存在服务器端，相对更加安全	Cookie存在安全隐患，通过拦截或本地文件找得到cookie后可以进行攻击
服务器资源消耗	Session是保存在服务器端上会存在一段时间才会消失如果session过多会增加服务器的压力。

(4)Application（ServletContext）与一个Web应用程序相对应，为应用程序提供了一个全局的状态所有客户都可以使用该状态。

12、SQL 注入

SQL注入就是通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。

1). SQL注入攻击的总体思路

(1). 寻找到SQL注入的位置
(2). 判断服务器类型和后台数据库类型
(3). 针对不通的服务器和数据库特点进行SQL注入攻击

2). 应对方法

(1). 参数绑定
　　使用预编译手段，绑定参数是最好的防SQL注入的方法。目前许多的ORM框架及JDBC等都实现了SQL预编译和参数绑定功能，攻击者的恶意SQL会被当做SQL的参数而不是SQL命令被执行。

(2). 使用正则表达式过滤传入的参数

13、 XSS 攻击

• XSS是一种经常出现在web应用中的计算机安全漏洞，与SQL注入一起成为web中最主流的攻击方式。
• XSS是指恶意攻击者利用网站没有对用户提交数据进行转义处理或者过滤不足的缺点，进而添加一些脚本代码嵌入到web页面中去，使别的用户访问都会执行相应的嵌入代码，从而盗取用户资料、利用用户身份进行某种动作或者对访问者进行病毒侵害的一种攻击方式。

1). XSS攻击的危害

• 盗取各类用户帐号，如机器登录帐号、用户网银帐号、各类管理员帐号
• 控制企业数据，包括读取、篡改、添加、删除企业敏感数据的能力
• 盗窃企业重要的具有商业价值的资料
• 非法转账
• 强制发送电子邮件
• 网站挂马
• 控制受害者机器向其它网站发起攻击

2). 原因解析

• 主要原因：过于信任客户端提交的数据！
• 解决办法：不信任任何客户端提交的数据，只要是客户端提交的数据就应该先进行相应的过滤处理然后方可进行下一步的操作。
• 进一步分析细节：客户端提交的数据本来就是应用所需要的，但是恶意攻击者利用网站对客户端提交数据的信任，在数据中插入一些符号以及javascript代码，那么这些数据将会成为应用代码中的一部分了，那么攻击者就可以肆无忌惮地展开攻击啦，因此我们绝不可以信任任何客户端提交的数据！

3). XSS 攻击分类

(1). 反射性XSS攻击 (非持久性XSS攻击)

• 漏洞产生的原因是攻击者注入的数据反映在响应中。一个典型的非持久性XSS攻击包含一个带XSS攻击向量的链接(即每次攻击需要用户的点击)，例如，正常发送消息：

http://www.test.com/message.php?send=Hello,World！

接收者将会接收信息并显示Hello,World；但是，非正常发送消息：

http://www.test.com/message.php?send=<script>alert(‘foolish!’)</script>！

接收者接收消息显示的时候将会弹出警告窗口！

(2). 持久性XSS攻击 (留言板场景)

• XSS攻击向量(一般指XSS攻击代码)存储在网站数据库，当一个页面被用户打开的时候执行。也就是说，每当用户使用浏览器打开指定页面时，脚本便执行。与非持久性XSS攻击相比，持久性XSS攻击危害性更大。从名字就可以了解到，持久性XSS攻击就是将攻击代码存入数据库中，然后客户端打开时就执行这些攻击代码。

例如，留言板表单中的表单域：

<input type=“text” name=“content” value=“这里是用户填写的数据”>

正常操作流程是：用户是提交相应留言信息 —— 将数据存储到数据库 —— 其他用户访问留言板，应用去数据并显示；而非正常操作流程是攻击者在value填写:

<script>alert(‘foolish!’)；</script> <!--或者html其他标签（破坏样式。。。）、一段攻击型代码-->

并将数据提交、存储到数据库中；当其他用户取出数据显示的时候，将会执行这些攻击性代码。

4). 修复漏洞方针

• 漏洞产生的根本原因是 太相信用户提交的数据，对用户所提交的数据过滤不足所导致的，因此解决方案也应该从这个方面入手，具体方案包括：

方针	操作
1	将重要的cookie标记为http only, 这样的话Javascript 中的document.cookie语句就不能获取到cookie了（如果在cookie中设置了HttpOnly属性，那么通过js脚本将无法读取到cookie信息，这样能有效的防止XSS攻击
2	表单数据规定值的类型，例如：年龄应为只能为int、name只能为字母数字组合
3	对数据进行Html Encode 处理
4	过滤或移除特殊的Html标签
5	过滤JavaScript 事件的标签

14、OSI网络体系结构与TCP/IP协议模型

• OSI分层 （7层）：物理层、数据链路层、网络层、传输层、会话层、表示层、应用层。
• TCP/IP分层（4层）：网络接口层、 网际层、运输层、 应用层。
• 五层协议 （5层）：物理层、数据链路层、网络层、运输层、 应用层。

OSI七层模型

层数	层次名称	功能作用
7	应用层（Application Layer）	为用户的应用进程提供网络通信服务。（如文件传输，电子邮件）
6	表示层（Presentation Layer）	主要负责数据的转换。（编码，压缩和解压缩，数据的加密和解密）它对来自应用层的命令和数据进行解释，以确保一个系统的应用层所发送的信息可以被另一个系统的应用层读取。
5	会话层（Session Layer）	通信管理。负责建立和断开通信连接 ，以及数据的分割等数据传输相关管理
4	传输层（Transport Layer）	管理两个节点间的数据传输。在网络层通信网络建立的基础上，完成端到端通信链路的建立，维护和管理。
3	网络层(Network Layer)	分组传送，路由选择和流量控制，主要用于实现端到端通信系统中中间结点的路由选择
2	数据链路层（Data Link Layer）	通过一些数据链路层协议和链路控制规程，在不太可靠的物理链路上实现可靠的数据传输。
1	物理层(Physical Layer)	实现了相邻计算机节点之间比特流的透明传送，并尽可能地屏蔽掉具体传输介质和物理设备的差异。

TCP/IP各层主要协议

层次名称	协议
应用层	HTTP、FTP、Telnet、DNS、DHCP、SMTP、POP/POP3
传输层	TCP、UDP
网际层	IP、ICMP、ARP、RARP
网际接口层	Ethernet、Token Ring、 FDDI 、PPP

ARP是地址解析协议，简单语言解释一下工作原理。

1、首先，每个主机都会在自己的ARP缓冲区中建立一个ARP列表，以表示IP地址和MAC地址之间的对应关系。

2、当源主机要发送数据时，首先检查ARP列表中是否有对应IP地址的目的主机的MAC地址，如果有，则直接发送数据，如果没有，就向本网段的所有主机发送ARP数据包，该数据包包括的内容有：源主机IP地址，源主机MAC地址，目的主机的IP地址。

3、当本网络的所有主机收到该ARP数据包时，首先检查数据包中的IP地址是否是自己的IP地址，如果不是，则忽略该数据包，如果是，则首先从数据包中取出源主机的IP和MAC地址写入到ARP列表中，如果已经存在，则覆盖，然后将自己的MAC地址写入ARP响应包中，告诉源主机自己是它想要找的MAC地址。

4、源主机收到ARP响应包后。将目的主机的IP和MAC地址写入ARP列表，并利用此信息发送数据。如果源主机一直没有收到ARP响应数据包，表示ARP查询失败。

• 广播发送ARP请求，单播发送ARP响应。

15、TCP对应的协议和UDP对应的协议

TCP对应的协议：

协议	描述
FTP	定义了文件传输协议，使用21端口。
Telnet	一种用于远程登陆的端口，使用23端口，用户可以以自己的身份远程连接到计算机上，可提供基于DOS模式下的通信服务。
SMTP	邮件传送协议，用于发送邮件。服务器开放的是25号端口。
POP3	它是和SMTP对应，POP3用于接收邮件。POP3协议所用的是110端口。
HTTP	是从Web服务器传输超文本到本地浏览器的传送协议。

UDP对应的协议：

协议	描述
DNS	用于域名解析服务，将域名地址转换为IP地址。DNS用的是53号端口。
SNMP	简单网络管理协议，使用161号端口，是用来管理网络设备的。由于网络设备很多，无连接的服务就体现出其优势。
TFTP(Trival File Transfer Protocal)	简单文件传输协议，该协议在熟知端口69上使用UDP服务。

16、IP地址的分类

• IP地址是指互联网协议地址，是IP协议提供的一种统一的地址格式，它为互联网上的每一个网络和每一台主机分配一个逻辑地址，以此来屏蔽物理地址的差异。IP地址编址方案将IP地址空间划分为A、B、C、D、E五类，其中A、B、C是基本类，D、E类作为多播和保留使用，为特殊地址。

• 每个IP地址包括两个标识码（ID），即网络ID和主机ID。同一个物理网络上的所有主机都使用同一个网络ID，网络上的一个主机（包括网络上工作站，服务器和路由器等）有一个主机ID与其对应。A~E类地址的特点如下：

地址类	说明
A类地址	以0开头，第一个字节范围：0~127
B类地址	以10开头，第一个字节范围：128~191
C类地址	以110开头，第一个字节范围：192~223
D类地址	以1110开头，第一个字节范围：224~239
E类地址	以1111开头，保留地址

17、 常见状态码及原因短语

• HTTP请求结构： 请求方式 + 请求URI + 协议及其版本

• HTTP响应结构： 状态码 + 原因短语 + 协议及其版本

• HTTP状态码由三个十进制数字组成，第一个十进制数字定义了状态码的类型，后两个数字没有分类的作用。HTTP状态码共分为5种类型：

HTTP状态码分类

状态码	类别	含义
1XX	Informational（信息性状态码）	接收的请求正在处理
2XX	Success（成功状态码）	请求正常处理完毕
3XX	Redirection（重定向状态码）	需要进行附加操作以完成请求
4XX	Client Error（客户端错误状态码）	服务器无法处理请求
5XX	Server Error（服务器错误状态码）	服务器处理请求出错

HTTP状态码列表

1xx	状态码英文名称	描述
100	Continue	继续。客户端应继续其请求
101	Switching Protocols	切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议，例如，切换到HTTP的新版本协议

2xx	状态码英文名称	描述
200	OK	请求成功。一般用于GET与POST请求
201	Created	已创建。成功请求并创建了新的资源
202	Accepted	已接受。已经接受请求，但未处理完成
203	Non-Authoritative Information	非授权信息。请求成功。但返回的meta信息不在原始的服务器，而是一个副本
204	No Content	无内容。服务器成功处理，但未返回内容。在未更新网页的情况下，可确保浏览器继续显示当前文档
205	Reset Content	重置内容。服务器处理成功，用户终端（例如：浏览器）应重置文档视图。可通过此返回码清除浏览器的表单域
206	Partial Content	部分内容。服务器成功处理了部分GET请求

3xx	状态码英文名称	描述
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请求重定向

4xx	状态码英文名称	描述
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的请求头信息

5xx	状态码英文名称	描述
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协议的版本，无法完成处理