【面试】全面掌握HTTP协议（持续更新中）

0. 写在前面

背景
博主近期打算换工作，面试时经常被问到HTTP协议，自认为对HTTP协议挺熟悉的，没想到面试过程中屡屡被面试官刁难，碰到稍微有点深度的知识点就答不上来，感觉被吊打了。

本文目的
由浅入深，全面总结HTTP常见面试题，吊打面试官！

声明
参考素材均来源于网络，如有侵权请联系本人删除。如需转载请注明出处，谢谢。

1. 基础知识

1.1 什么是HTTP？

HTTP是HyperText Transfer Protocol的缩写，翻译成中文即超文本传输协议。
HTTP是用于从万维网（WWW：World Wide Web ）服务器传输超文本到本地浏览器的传送协议。
HTTP是一个基于TCP/IP通信协议来传递数据（html文件，css/js，图片文件等）的应用层协议。

1.2 HTTP请求方法有哪些？

HTTP1.0定义了三种请求方法： GET、POST、HEAD
HTTP1.1新增了五种请求方法：OPTIONS、PUT、DELETE、TRACE、CONNECT

1.2.1 GET

用来请求已被URI识别的资源，指定的资源经服务器端解析后返回响应内容。如果请求的资源是文本，那就保持原样返回；如果是CGI（通用网关接口）那样的程序，则返回经过执行后的输出结果。
　常用于向服务器查询某些信息。必要时，可以将查询字符串参数追加到URL末尾，以便将信息发送给服务器。

1.2.2 POST

POST方法用于向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST 请求可能会导致新的资源的建立和/或已有资源的修改。

1.2.3 HEAD

类似于 GET 请求，只不过返回的响应中没有具体的内容，用于获取报文头部。用于确认URI的有效性及资源更新的日期时间等。
具体来说head方法的作用有：
1、判断类型；
2、查看响应中的状态码，看对象是否存在（响应：请求执行成功了，但无数据返回）；
3、测试资源是否被修改过。
HEAD方法和GET方法的区别： GET方法有实体，HEAD方法无实体。

1.2.4 OPTIONS

OPTIONS方法用来查询针对请求URI指定资源支持的方法（客户端询问服务器可以提交哪些请求方法）。若请求成功，则它会在HTTP头中包含一个名为“Allow”的key，value为所支持的方法。

1.2.5 PUT

PUT方法用来传输文件，就像FTP协议的文件上传一样，要求在请求报文的主体中包含文件内容，然后保存在请求URI指定的位置。如果指定路径的文件已经存在则覆盖，否则新建。但是HTTP/1.1的PUT方法自身不带验证机制，任何人都可以上传文件，存在安全问题，故一般不用。

1.2.6 DELETE

指明客户端想让服务器删除某个资源，与PUT方法相反，按URI删除指定资源。

1.2.7 TRACE

客户端可以对请求消息的传输路径进行追踪，TRACE方法是让Web服务器端将之前的请求通信还给客户端的方法。可用于回显服务器收到的请求，以便测试或诊断。

1.2.8 CONNECT

CONNECT方法要求在与代理服务器通信时建立隧道，实现用隧道协议进行TCP通信。主要使用SSL（安全套接层）和TLS（传输层安全）协议把通信内容加密后经网络隧道传输。

1.3 HTTP1.0、HTTP1.1、HTTP2.0、HTTPS的区别？

1.3.1 HTTP1.0

HTTP 1.0规定浏览器与服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器完成请求处理后立即断开TCP连接。
　当一个网页文件中包含了很多图像的地址的时候，那就需要很多次的http请求和响应，每次请求和响应都需要一个单独的连接，每次连接只是传输一个文档和图像，上一次和下一次请求完全分离。即使图像文件都很小，但是客户端和服务器端每次建立和关闭连接却是一个相对比较费时的过程，并且会严重影响客户机和服务器的性能。当一个网页文件中包含JavaScript文件，CSS文件等内容时，也会出现类似上述的情况。

1.3.2 HTTP1.1

为了克服HTTP1.0的这个缺陷，HTTP1.1支持持久连接（HTTP/1.1的默认模式使用带流水线的持久连接），在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。一个包含有许多图像的网页文件的多个请求和应答可以在一个连接中传输，但每个单独的网页文件的请求和应答仍然需要使用各自的连接。
　HTTP1.1还允许客户端不用等待上一次请求结果返回，就可以发出下一次请求，但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果，以保证客户端能够区分出每次请求的响应内容，这样也显著地减少了整个下载过程所需要的时间。
　在HTTP1.1，request和reponse头中都有可能出现一个connection的头，此header的含义是当client和server通信时对于长链接如何进行处理。在HTTP1.1中，client和server都是默认对方支持长链接的， 如果client使用HTTP1.1协议，但又不希望使用长链接，则需要在header中指明connection的值为close；如果server方也不想支持长链接，则在response中也需要明确说明connection的值为close。不论request还是response的header中包含了值为close的connection，都表明当前正在使用的tcp链接在当次请求处理完毕后会被断掉。以后client再进行新的请求时就必须创建新的tcp链接了。

1.3.3 HTTP1.1和HTTP1.0的区别

HTTP1.1在继承了HTTP1.0优点的基础上，也克服了HTTP1.0的性能问题。HTTP1.1通过增加更多的请求头和响应头来改进和扩充HTTP 1.0的功能。如：

1. 新增Host请求头，HTTP 1.0不支持Host请求头字段，WEB浏览器无法使用主机头名来明确表示要访问服务器上的哪个WEB站点，这样就无法使用WEB服务器在同一个IP地址和端口号上配置多个虚拟WEB站点。在HTTP 1.1中增加Host请求头字段后，WEB浏览器可以使用主机头名来明确表示要访问服务器上的哪个WEB站点，这才实现了在一台WEB服务器上可以在同一个IP地址和端口号上使用不同的主机名来创建多个虚拟WEB站点。
2. 支持长连接。HTTP1.1的持续连接，也需要增加新的请求头来帮助实现，例如，Connection请求头的值为Keep-Alive时，客户端通知服务器返回本次请求结果后保持连接；Connection请求头的值为close时，客户端通知服务器返回本次请求结果后关闭连接。
3. HTTP1.1还提供了与身份认证、状态管理和Cache缓存等机制相关的请求头和响应头。
4. 支持断点续传。HTTP1.0不支持文件断点续传，RANGE:bytes是HTTP1.1新增内容，HTTP1.0每次传送文件都是从文件头开始，即0字节处开始。RANGE:bytes=XXXX表示要求服务器从文件XXXX字节处开始传送，这就是我们平时所说的断点续传！

简单的来说，HTTP1.1相较于 HTTP1.0 协议的区别主要体现在：

1. 缓存处理
2. 带宽优化及网络连接的使用
3. 错误通知的管理
4. 消息在网络中的发送
5. 互联网地址的维护
6. 安全性及完整性

1.3.4 HTTP2.0和HTTP1.x的区别

相比 HTTP/1.x，HTTP/2 在底层传输做了很大的改动和优化：

1. HTTP/2 采用二进制格式传输数据，而非 HTTP/1.x 的文本格式。二进制格式在协议的解析和优化扩展上带来更多的优势和可能。
2. HTTP/2 对消息头采用 HPACK 进行压缩传输，能够节省消息头占用的网络的流量。而 HTTP/1.x 每次请求，都会携带大量冗余头信息，浪费了很多带宽资源。头压缩能够很好的解决该问题。
3. 多路复用，直白的说就是所有的请求都是通过一个TCP 连接并发完成。HTTP/1.x 虽然通过 pipeline 也能并发请求，但是多个请求之间的响应会被阻塞的，所以 pipeline 至今也没有被普及应用，而 HTTP/2 做到了真正的并发请求。同时，流还支持优先级和流量控制。
4. Server Push：服务端能够更快的把资源推送给客户端。例如服务端可以主动把 JS 和 CSS 文件推送给客户端，而不需要客户端解析 HTML 再发送这些请求。当客户端需要的时候，它已经在客户端了。
5. HTTP/2 主要是 HTTP/1.x 在底层传输机制上的完全重构，HTTP/2 是基本兼容 HTTP/1.x 的语义的(详细兼容性说明请戳这里)。Content-Type 仍然是 Content-Type，只不过它不再是文本传输了。

1.3.5 HTTPS

HTTP本身不具备加密功能，报文使用明文（未经加密的报文）方式发送，通信内容在所有的通信线路上都有可能遭到窥视。
加密处理的两种方式：

1. 通信的加密：将HTTP和SSL（安全套接层）或者TLS（安全传输层协议）组合使用，与SSL组合使用的HTTP被称为HTTPS（超文本传输安全协议）。

2. 内容的加密：通信双方都要求有加密和解密的机制，仍有被篡改的风险。

HTTPS = HTTP + 加密 + 认证 + 完整性保护

1.3.6 HTTPS的加密算法

在介绍HTTPS的加密算法之前，首先了解两个概念：
对称秘钥：对称密钥加密又叫专用密钥加密，即发送和接收数据的双方必使用相同的密钥对明文进行加密和解密运算。通常有两种模式：流加密和分组加密。
非对称秘钥：非对称加密算法需要两个密钥，公开秘钥（publickey）和私有密钥（privatekey）。公开密钥与私有密钥是一对，如果用公开密钥对数据进行加密，只有用对应的私有密钥才能解密；如果用私有密钥对数据进行加密，那么只有用对应的公开密钥才能解密。因为加密和解密使用的是两个不同的密钥，所以这种算法叫作非对称加密算法。

在HTTP的概念中介绍了HTTP是非常不安全的，那么在服务器与客户端传递数据的过程中HTTPS是如何保证数据的安全呢？

1. 客户端向服务器端发起SSL连接请求；（在此过程中依然存在数据被中间方盗取的可能，下面将会说明如何保证此过程的安全）
2. 服务器把公钥发送给客户端，并且服务器端保存着唯一的私钥；
3. 客户端用公钥对双方通信的对称秘钥进行加密，并发送给服务器端；
4. 服务器利用自己唯一的私钥对客户端发来的对称秘钥进行解密，在此过程中，中间方无法对其解密（即使是客户端也无法解密，因为只有服务器端拥有唯一的私钥），这样保证了对称秘钥在收发过程中的安全，此时，服务器端和客户端拥有了一套完全相同的对称秘钥。
5. 进行数据传输，服务器和客户端双方用公有的相同的对称秘钥对数据进行加密解密，可以保证在数据收发过程中的安全，即是第三方获得数据包，也无法对其进行加密，解密和篡改。

CA（电子商务认证机构）认证作用
　　在上面提到的客户端向服务器端发起请求时存在数据被盗取的过程：假如服务器端经由中间方向客户端发送公钥的时候，中间方没有将公钥发送给客户端，而是伪造了医药公钥，并将伪造的公钥发送给客户端，此时客户端用中间方伪造的公钥对自己正确的对称秘钥加密并由中间方发送给服务器端，而中间方将用自己伪造的公钥的私钥对其进行解密，得到正确的对称秘钥，并将得到的正确的对称秘钥用服务器端发过来的公钥进行加密发给服务器端，服务器daunt再用正确的私钥进行解密，也得到正确的对称秘钥，此时客户端，服务器端，中间方三者都拥有一套正确的对称秘钥，可以对传送的数据进行加密，解密。
　　为了解决上述问题，一般情况下，服务器端会向CA申请认证书，此证书包含了CA及服务器端的一些信息（可以理解为类似公章），这样，服务器端将证书发给客户端的过程中，中间方是无法伪造的，保证了，发给客户端的公钥是服务器端发送的。

1.3.7 HTTPS与HTTP的区别

1. HTTP 的URL 以http:// 开头，而HTTPS 的URL 以https:// 开头
2. HTTP 是不安全的，而 HTTPS 是安全的
3. HTTP 标准端口是80 ，而 HTTPS 的标准端口是443
4. 在OSI 网络模型中，HTTP工作于应用层，而HTTPS 的安全传输机制工作在传输层
5. HTTP 无法加密，而HTTPS 对传输的数据进行加密
6. HTTP无需证书，而HTTPS 需要CA机构wosign的颁发的SSL证书

1.4 session和cookie的区别？

参考文章：https://www.cnblogs.com/l199616j/p/11195667.html
　　会话跟踪是Web程序中常用的技术，用来跟踪用户的整个会话。常用的会话跟踪技术是Cookie与Session。Cookie通过在客户端记录信息确定用户身份，Session通过在服务器端记录信息确定用户身份。
　　在程序中，会话跟踪是很重要的事情。理论上，一个用户的所有请求操作都应该属于同一个会话，而另一个用户的所有请求操作则应该属于另一个会话，二者不能混淆。例如，用户A在超市购买的任何商品都应该放在A的购物车内，不论是用户A什么时间购买的，这都是属于同一个会话的，不能放入用户B或用户C的购物车内，这不属于同一个会话。
　　而Web应用程序是使用HTTP协议传输数据的。HTTP协议是无状态的协议。一旦数据交换完毕，客户端与服务器端的连接就会关闭，再次交换数据需要建立新的连接。这就意味着服务器无法从连接上跟踪会话。即用户A购买了一件商品放入购物车内，当再次购买商品时服务器已经无法判断该购买行为是属于用户A的会话还是用户B的会话了。要跟踪该会话，必须引入一种机制。
　　Cookie就是这样的一种机制。它可以弥补HTTP协议无状态的不足。在Session出现之前，基本上所有的网站都采用Cookie来跟踪会话。

1.4.1 cookie

Cookie意为“甜饼”，是由W3C组织提出，最早由Netscape社区发展的一种机制。目前Cookie已经成为标准，所有的主流浏览器如IE、Netscape、Firefox、Opera等都支持Cookie。

由于HTTP是一种无状态的协议，服务器单从网络连接上无从知道客户身份。怎么办呢？就给客户端们颁发一个通行证吧，每人一个，无论谁访问都必须携带自己通行证。这样服务器就能从通行证上确认客户身份了。这就是Cookie的工作原理。

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

1.4.2 session

除了使用Cookie，Web应用程序中还经常使用Session来记录客户端状态。Session是服务器端使用的一种记录客户端状态的机制，使用上比Cookie简单一些，相应的也增加了服务器的存储压力。

Session是另一种记录客户状态的机制，不同的是Cookie保存在客户端浏览器中，而Session保存在服务器上。客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上。这就是Session。客户端浏览器再次访问时只需要从该Session中查找该客户的状态就可以了。

如果说Cookie机制是通过检查客户身上的“通行证”来确定客户身份的话，那么Session机制就是通过检查服务器上的“客户明细表”来确认客户身份。Session相当于程序在服务器上建立的一份客户档案，客户来访的时候只需要查询客户档案表就可以了。

1.4.3 cookie和session的区别

1. 存储位置不同
cookie的数据信息存放在客户端的浏览器上。
session的数据信息存放在服务端上。

2. 存储容量不同
单个cookie保存的数据<=4KB，一个站点最多保存20个Cookie。
对于session来说并没有上限，但出于对服务器端的性能考虑，session内不要存放过多的东西，并且设置session删除机制。

3. 存储方式不同
cookie中只能保管ASCII字符串，并需要通过编码方式存储为Unicode字符或者二进制数据。
session中能够存储任何类型的数据，包括且不限于string，integer，list，map等。

4. 隐私策略不同
cookie对客户端是可见的，别有用心的人可以分析存放在本地的cookie并进行cookie欺骗，所以它是不安全的。
session存储在服务器上，对客户端是透明的，不存在敏感信息泄漏的风险。

5. 有效期不同
开发可以通过设置cookie的属性，达到使cookie长期有效的效果。
session依赖于名为JSESSIONID的cookie，而cookie JSESSIONID的过期时间maxAge默认为-1，只需关闭窗口该session就会失效，因而session不能达到长期有效的效果。

6. 对服务器压力不同
cookie保管在客户端，不占用服务器资源。对于并发用户十分多的网站，cookie是很好的选择。
session是保管在服务器端的，每个用户都会产生一个session。假如并发访问的用户十分多，会产生十分多的session，耗费大量的内存。

7. 浏览器支持不同
假如客户端浏览器不支持cookie：
　　cookie是需要客户端浏览器支持的，假如客户端禁用了cookie，或者不支持cookie，则会话跟踪会失效。关于WAP上的应用，常规的cookie就派不上用场了。
　　运用session需要使用URL地址重写的方式。一切用到session程序的URL都要进行URL地址重写，否则session会话跟踪还会失效。
　　URL地址重写是对客户端不支持Cookie的解决方案。URL地址重写的原理是将该用户Session的id信息重写到URL地址中。服务器能够解析重写后的URL获取Session的id。这样即使客户端不支持Cookie，也可以使用Session来记录用户状态。

假如客户端支持cookie：
　　cookie既能够设为本浏览器窗口以及子窗口内有效，也能够设为一切窗口内有效。
　　session只能在本窗口以及子窗口内有效。

8. 跨域支持上不同
cookie支持跨域名访问。
session不支持跨域名访问。

1.5 URL和URI的区别？

参考文章：
https://www.jianshu.com/p/db65de31fe1b
https://blog.csdn.net/koflance/article/details/79635240

URI包括URL和URN两个类别，URL是URI的子集，所以URL一定是URI，而URI不一定是URL。

URI = Uniform Resource Identifier 统一资源标志符，用来标识抽象或物理资源的一个紧凑字符串。

URL = Uniform Resource Locator 统一资源定位符，一种定位资源的主要访问机制的字符串，一个标准的URL格式(带方括号[]的为可选项)：
protocol : // hostname[:port] / path / [;parameters][?query]#fragment

URN = Uniform Resource Name 统一资源名称，通过特定命名空间中的唯一名称或ID来标识资源。

统一资源标志符URI就是在某一规则下能把一个资源独一无二地标识出来。拿人做例子，假设这个世界上所有人的名字都不能重复，那么名字就是URI的一个实例，通过名字这个字符串就可以标识出唯一的一个人。现实当中名字当然是会重复的，所以身份证号才是URI，通过身份证号能让我们能且仅能确定一个人。那统一资源定位符URL是什么呢。也拿人做例子然后跟HTTP的URL做类比，就可以有：

动物住址协议://地球/中国/浙江省/杭州市/西湖区/某大学/14号宿舍楼/525号寝/张三.人

可以看到，这个字符串同样标识出了唯一的一个人，起到了URI的作用，所以URL是URI的子集。URL是以描述人的位置来唯一确定一个人的。

在上文我们用身份证号也可以唯一确定一个人。对于这个在杭州的张三，我们也可以用身份证号：123456789，来标识他。

所以不论是用定位的方式还是用编号的方式，我们都可以唯一确定一个人，都是URl的一种实现，而URL就是用定位的方式实现的URI。

回到Web上，假设所有的Html文档都有唯一的编号，记作html:xxxxx，xxxxx是一串数字，即Html文档的身份证号码，这个能唯一标识一个Html文档，那么这个号码就是一个URI。

而URL则通过描述是哪个主机上哪个路径上的文件来唯一确定一个资源，也就是定位的方式来实现的URI。

对于现在网址我更倾向于叫它URL，毕竟它提供了资源的位置信息，如果有一天网址通过号码来标识变成了http://741236985.html，那感觉叫成URI更为合适，不过这样子的话还得想办法找到这个资源咯。

1.6 什么是TCP/IP协议？它有几层？HTTP属于哪一层？

参考：https://blog.csdn.net/weixin_43796814/article/details/88965429
TCP/IP协议簇是基于TCP和IP这两个最初的协议之上的不同的通信协议的大的集合。
TCP/IP通讯协议采用了4层的层级结构，每一层都呼叫它的下一层所提供的网络来完成自己的需求。这4层分别为：应用层、传输层、网络层、网络接口层。如果分的细一点，也可以分为五层结构，把网络接口层拆分为：数据链路层、物理层。

应用层
应用程序间沟通的层，该层常见的协议有超文本传输协议（HTTP）、简单电子邮件传输(SMTP)、文件传输协议(FTP)、网络远程访问协议(Telnet)等。

传输层
在此层中，它提供了节点间的数据传送，应用程序之间的通信服务，主要功能是数据格式化、数据确认和丢失重传等。如传输控制协议(TCP)、用户数据报协议(UDP)等，TCP和UDP给数据包加入传输数据并把它传输到下一层中，这一层负责传送数据，并且确定数据已被送达并接收。

网络层
负责提供基本的数据封包传送功能，让每一块数据包都能够到达目的主机(但不检查是否被正确接收)，如网际协议(IP)。

网络接口层
接收IP数据报并进行传输，从网络上接收物理帧，抽取IP数据报转交给下一层，对实际的网络媒体的管理，定义如何使用实际网络(如Ethernet、Serial Line等)来传送数据。

1.7 HTTP请求报文和响应报文结构是怎么样的？

参考：https://www.cnblogs.com/ldq2016/p/9055933.html

1.7.1 请求报文

请求报文中主要由三部分组成：请求行、请求头、请求体。其中请求头与请求体之间用空行隔开。
请求行
包含请求方法、请求URL、HTTP协议及版本三个信息。
请求头
包含了各种key-value形式的头部信息。
请求体
若方法字段是GET，则此项为空，没有数据。
若方法字段是POST,则通常来说此处放置的就是要提交的数据。
比如要使用POST方法提交一个表单，其中有user字段中数据为“admin”, password字段为123456，那么这里的请求数据就是 user=admin&password=123456，使用&来连接各个字段。

1.7.2 响应报文

响应报文也是由三部分组成：响应行、响应头、响应体
响应行
响应行包含报文协议及版本、响应状态码、状态描述
响应头
各种key-value形式的信息
响应体
响应体就是响应的消息体，如果是纯数据就是返回纯数据，如果请求的是HTML页面，那么返回的就是HTML代码，如果是JS就是JS代码，如此之类。

1.8 一次完整的HTTP请求经历了哪些步骤？

这个问题的另外一种问法就是：我在浏览器输入一个URL，然后按回车键，直到整个页面展示完成，中间经历了哪些步骤。

1. 解析URL。在浏览器地址栏中输入url，先解析url，检测url地址是否合法。
2. 检测所请求的资源是否存在缓存，如有则直接渲染。
3. 对域名进行DNS得到IP地址。DNS过程：查询浏览器缓存>>查询本机系统缓存>>查询host文件>>查询路由器缓存>>查询本地域名服务器>>查询根域名服务器。
4. 通过IP寻址找到服务器，并发起TCP三次握手建立TCP连接。
5. 握手成功后，浏览器向服务器发送http请求报文。
6. 服务器处理收到的HTTP请求报文，并返回响应报文。
7. 浏览器解析响应报文，得到html代码，并请求html代码中的静态资源（如js、css、image等）。
8. 浏览器对页面进行渲染呈现给用户。

1.9 常见的HTTP状态码

参考文章：https://www.cnblogs.com/xflonga/p/9368993.html

1xx
指定客户端应相应的某些动作，代表请求已被接受，需要继续处理。由于 HTTP/1.0 协议中没有定义任何 1xx 状态码，所以除非在某些试验条件下，服务器禁止向此类客户端发送 1xx 响应。

2xx
代表请求已成功被服务器接收、理解、并接受。常见的有以下三个状态码：
200 OK：表示请求已成功，请求所希望的响应头或数据体将随此响应返回。
201 Created：表示请求成功并且服务器创建了新的资源，且其 URI 已经随Location 头信息返回。
202 Accepted：服务器已接受请求，但尚未处理。

3xx
代表需要客户端采取进一步的操作才能完成请求，这些状态码用来重定向，后续的请求地址（重定向目标）在本次响应的 Location 域中指明。最常见的有以下几个：
301 Moved Permanently：被请求的资源已永久移动到新位置。服务器返回此响应（对 GET 或 HEAD 请求的响应）时，会自动将请求者转到新位置。
302 Moved Temporarily：请求的资源临时从不同的URI响应请求，但请求者应继续使用原有位置来进行以后的请求
304 Not Modified：自从上次请求后，请求的网页未修改过。服务器返回此响应时，不会返回网页内容。 如果网页自请求者上次请求后再也没有更改过，您应将服务器配置为返回此响应(称为 If-Modified-Since HTTP 标头)。

4xx
表示请求错误。代表了客户端看起来可能发生了错误，妨碍了服务器的处理。常见有：
400 Bad Request：
401Unauthorized：请求要求身份验证。 对于需要登录的网页，服务器可能返回此响应。
403 Forbidden：服务器已经理解请求，但是拒绝执行它。与401响应不同的是，身份验证并不能提供任何帮助，而且这个请求也不应该被重复提交。
404 Not Found：请求失败，请求所希望得到的资源未被在服务器上发现。没有信息能够告诉用户这个状况到底是暂时的还是永久的。假如服务器知道情况的话，应当使用。

5xx
代表了服务器在处理请求的过程中有错误或者异常状态发生，也有可能是服务器意识到以当前的软硬件资源无法完成对请求的处理。常见有：
500 Internal Server Error：这是一个通用的服务器错误响应。对于大多数web框架，如果在执行请求处理代码时遇到了异常，它们就发送此响应代码。
502 Bad Gateway：只有HTTP代理会发送这个响应代码。它表明代理方面出现问题，或者代理与上行服务器之间出现问题，而不是上行服务器本身有问题。若代理根本无法访问上行服务器，响应代码将是504 Gateway Timeout。
503 Service Unavailable：由于临时的服务器维护或者过载，服务器当前无法处理请求。通常，这个是暂时状态，一段时间会恢复