转自：
https://mp.weixin.qq.com/s/7kXcYh7dHhOFgWJ5uPAjiA
https://mp.weixin.qq.com/s/NMhNVDP47npMqx5ruVy43w
状态码
| 状态码 | 类别 | 原因短语 |
|---|---|---|
| 1XX | Informational（信息性状态码） | 接收的请求正在处理 |
| 2XX | Success（成功状态码） | 请求正常处理完毕 |
| 3XX | Redirection（重定向状态码） | 需要进行附加操作以完成请求 |
| 4XX | Client Error（客户端错误状态码） | 服务器无法处理请求 |
| 5XX | Server Error（服务器错误状态码） | 服务器处理请求出错 |
1XX——信息
- 100 Continue ：表明到目前为止都很正常，客户端可以继续发送请求或者忽略这个响应。
- 101 Switching Protocols 协议升级：请求者要求服务器切换协议，服务器确认并准备切换
2XX——成功
- 200 OK
- 204 No Content ：请求已经成功处理，但是返回的响应报文不包含实体的主体部分。一般在只需要从客户端往服务器发送信息，而不需要返回数据时使用。
- 206 Partial Content ：表示客户端进行了范围请求。响应报文包含由 Content-Range 指定范围的实体内容。
3xx——重定向
- 301 Moved Permanently ：永久性重定向
- 302 Found ：临时性重定向
- 303 See Other ：和 302 有着相同的功能，但是 303 明确要求客户端应该采用 GET 方法获取资源。
| 注：虽然 HTTP 协议规定 301、302 状态下重定向时不允许把 POST 方法改成 GET 方法，但是大多数浏览器都会在 301、302 和 303 状态下的重定向把 POST 方法改成 GET 方法。 |
- 304 Not Modified ：如果请求报文首部包含一些条件，例如：If-Match，If-Modified-Since，If-None-Match，If-Range，If-Unmodified-Since，如果不满足条件，则服务器会返回 304 状态码。
| 浏览器缓存分为强制缓存和协商缓存，优先读取强制缓存。 强制缓存分为expires和cache-control： 协商缓存包括etag和last-modified： 如果 Last-Modified 和 ETag 同时被使用，则要求它们的验证都必须通过才会返回304，若其中某个验证没通过，则服务器会按常规返回资源实体及200状态码。 协商缓存与强制缓存的区别在于强制缓存不需要访问服务器，返回结果是200，协商缓存需要访问服务器，命中协商缓存的话，返回结果是304。 步骤：客户端发送附带条件的请求时（if-matched,if-modified-since,if-none-match,if-range,if-unmodified-since任一个）服务器端允许请求访问资源，但因发生请求未满足条件的情况后，直接返回304Modified（服务器端资源未改变，可直接使用客户端未过期的缓存）。
|
- 307 Temporary Redirect ：临时重定向，与 302 的含义类似，但是 307 要求浏览器不允许把重定向请求的 POST 方法改成 GET 方法。
| 关于303和307：https://blog.csdn.net/liuxingen/article/details/51511034 |
4xx——客户端错误
- 400 Bad Request ：请求报文中存在语法错误。提交json时，如果json格式有问题，接收端接收json，也会出现400 bad request。比如常见的json串，数组不应该有",但是有"了。
- 401 Unauthorized ：该状态码表示发送的请求需要有认证信息（BASIC 认证、DIGEST 认证）。如果之前已进行过一次请求，则表示用户认证失败。
- 403 Forbidden ：请求被拒绝，服务器端没有必要给出拒绝的详细理由。
- 404 Not Found：资源不存在
- 405 method not allowed问题原因：请求的方式（get、post、delete）方法与后台规定的方式不符合。比如： 后台方法规定的请求方式只接受get，如果用post请求，就会出现 405 method not allowed的提示
- 408 请求超时
5xx——服务器错误
- 500： Internal Server Error ：服务器内部错误
- 502：Bad Gateway：网关错误
- 503 Service Unavilable ：服务器暂时处于超负载或正在进行停机维护，现在无法处理请求。（瞬时请求量过大）
- 504：Gateway Time-out：进程阻塞超过nginx的时间阈值返回504
- 505：不支持该http版本
http版本
http1.1和1.0
长连接和流水线（Pipelining）处理
- HTTP 1.1支持长连接（PersistentConnection）和管线化（Pipelining）处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。
- 如果要断开 TCP 连接，需要由客户端或者服务器端提出断开，使用 Connection : close
- 在HTTP1.1中默认开启Connection： keep-alive，一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。
Host头处理/虚拟主机
- 在http 1.1中不能缺失host字段,如果缺失, 服务器返回400 bad request，http1.1中不能缺失host字段，但host字段可以是空值。
- 在http 1.0中可以缺失host字段。
| 在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。 HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。（Host头域指定请求资源的Intenet主机和端口号，必须表示请求url的原始服务器或网关的位置。） |
支持分块传输编码
- HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能
- HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。
- 另一种解释：可以把数据分割成多块，让浏览器逐步显示页面。
错误通知的管理/新增状态码
在HTTP1.1中新增了24个错误状态响应码，如：
- 409（Conflict）表示请求的资源与资源的当前状态发生冲突；
- 410（Gone）表示服务器上的某个资源被永久性的删除。
缓存处理（协商缓存）
- 在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准。
- HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。
- 新增缓存处理指令 max-age
HTTP1.1支持同时打开多个 TCP 连接
新增状态码 100
2.0和1.1
HTTP/1.x 缺陷
HTTP/1.x 实现简单是以牺牲性能为代价的：
- 客户端需要使用多个连接才能实现并发和缩短延迟；
- 不会压缩请求和响应首部，从而导致不必要的网络流量；
- 不支持有效的资源优先级，致使底层 TCP 连接的利用率低下。
二进制分帧层
HTTP/2.0 将报文分成 HEADERS 帧和 DATA 帧，它们都是二进制格式的。
在通信过程中，只会有一个 TCP 连接存在，它承载了任意数量的双向数据流（Stream）。
- 一个数据流（Stream）都有一个唯一标识符和可选的优先级信息，用于承载双向信息。
- 消息（Message）是与逻辑请求或响应对应的完整的一系列帧。
- 帧（Frame）是最小的通信单位，来自不同数据流的帧可以交错发送，然后再根据每个帧头的数据流标识符重新组装。
和1.1区别在于：
- HTTP1.x的解析是基于文本。基于文本协议的格式解析存在天然缺陷，文本的表现形式有多样性，要做到健壮性考虑的场景必然很多
- 二进制则不同，只认0和1的组合。基于这种考虑HTTP2.0的协议解析决定采用二进制格式，实现方便且健壮。
多路复用（MultiPlexing）
多路复用允许单一的 HTTP/2 连接同时发起多重的请求-响应消息
一个request对应一个id，这样一个连接上可以有多个request，每个连接的request可以随机的混杂在一起，接收方可以根据request的 id将request再归属到各自不同的服务端请求里面。
- 单连接多资源的方式，减少服务端的链接压力,内存占用更少,连接吞吐量更大；
- 由于减少TCP 慢启动时间，提高传输的速度。
我们知道HTTP底层其实依赖的是TCP协议，那问题是在同一个连接里面同时发生两个请求响应着是怎么做到的？
首先你要知道，TCP连接相当于两根管道（一个用于服务器到客户端，一个用于客户端到服务器），管道里面数据传输是通过字节码传输，传输是有序的，每个字节都是一个一个来传输。
例如客户端要向服务器发送Hello、World两个单词，只能是先发送Hello再发送World，没办法同时发送这两个单词。不然服务器收到的可能就是HWeolrllod（注意是穿插着发过去了，但是顺序还是不会乱）。这样服务器就懵b了。
接上面的问题，能否同时发送Hello和World两个单词能，当然也是可以的，可以将数据拆成包，给每个包打上标签。发的时候是这样的①H ②W ①e ②o ①l ②r ①l ②l ①o ②d。这样到了服务器，服务器根据标签把两个单词区分开来。实际的发送效果如下图：
要实现上面的效果我们引入一个新的概念就是：二进制分帧。
二进制分帧
二进制分帧层 在 应用层(HTTP/2)和传输层(TCP or UDP)之间。HTTP/2并没有去修改TCP协议而是尽可能的利用TCP的特性。
在二进制分帧层中， HTTP/2 会将所有传输的信息分割为帧（frame）,并对它们采用二进制格式的编码 ，其中首部信息会被封装到 HEADER frame，而相应的 Request Body 则封装到 DATA frame 里面。
HTTP 性能优化的关键并不在于高带宽，而是低延迟。TCP 连接会随着时间进行自我「调谐」，起初会限制连接的最大速度，如果数据成功传输，会随着时间的推移提高传输的速度。这种调谐则被称为 TCP 慢启动。由于这种原因，让原本就具有突发性和短时性的 HTTP 连接变的十分低效。
HTTP/2 通过让所有数据流共用同一个连接，可以更有效地使用 TCP 连接，让高带宽也能真正的服务于 HTTP 的性能提升。
HTTP2.0的多路复用和HTTP1.X中的长连接复用有什么区别？
关键点：一个是串行，一个是并行，一个阻塞不影响其他request。
首部压缩
在 HTTP/1 中，HTTP 请求和响应都是由「状态行、请求 / 响应头部、消息主体」三部分组成。一般而言，消息主体都会经过 gzip 压缩，或者本身传输的就是压缩过后的二进制文件（例如图片、音频），但状态行和头部却没有经过任何压缩，直接以纯文本传输。
随着 Web 功能越来越复杂，每个页面产生的请求数也越来越多，导致消耗在头部的流量越来越多，尤其是每次都要传输 UserAgent、Cookie 这类不会频繁变动的内容，完全是一种浪费。
我们再用通俗的语言解释下，压缩的原理。头部压缩需要在支持 HTTP/2 的浏览器和服务端之间。
- 维护一份相同的静态字典（Static Table），包含常见的头部名称，以及特别常见的头部名称与值的组合；
- 维护一份相同的动态字典（Dynamic Table），可以动态的添加内容；
- 支持基于静态哈夫曼码表的哈夫曼编码（Huffman Coding）；
静态字典的作用有两个：
- 1）对于完全匹配的头部键值对，例如 “:method :GET”，可以直接使用一个字符表示；
- 2）对于头部名称可以匹配的键值对，例如 “cookie :xxxxxxx”，可以将名称使用一个字符表示。
同时，浏览器和服务端都可以向动态字典中添加键值对，之后这个键值对就可以使用一个字符表示了。需要注意的是，动态字典上下文有关，需要为每个 HTTP/2 连接维护不同的字典。在传输过程中使用，使用字符代替键值对大大减少传输的数据量。
服务端推送（server push）
服务端推送是一种在客户端请求之前发送数据的机制。当代网页使用了许多资源:HTML、样式表、脚本、图片等等。在HTTP/1.x中这些资源每一个都必须明确地请求。这可能是一个很慢的过程。浏览器从获取HTML开始，然后在它解析和评估页面的时候，增量地获取更多的资源。因为服务器必须等待浏览器做每一个请求，网络经常是空闲的和未充分使用的。
为了改善延迟，HTTP/2引入了server push，它允许服务端推送资源给浏览器，在浏览器明确地请求之前。一个服务器经常知道一个页面需要很多附加资源，在它响应浏览器第一个请求的时候，可以开始推送这些资源。这允许服务端去完全充分地利用一个可能空闲的网络，改善页面加载时间。
HTTPs
HTTPS和HTTP的区别主要如下：
1、https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。
2、http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。
3、用的端口也不一样，http是80，https是443。
4、http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证、完整性保护的网络协议，比http协议安全。
HTTP 有以下安全性问题：
- 内容可能会被窃听；
- 通信方的身份有可能遭遇伪装；
- 报文有可能遭篡改。
HTTPs 并不是新协议，而是让 HTTP 先和 SSL（Secure Sockets Layer）通信，再由 SSL 和 TCP 通信。也就是说 HTTPs 使用了隧道进行通信。
| 隧道：它是将原始IP包（其报头包含原始发送者和最终目的地）封装在另一个数据包（称为封装的IP包）的数据净荷中进行传输。使用隧道的原因是在不兼容的网络上传输数据，或在不安全网络上提供一个安全路径。 |
通过使用 SSL，HTTPs 具有了：
加密（防窃听）、认证（防伪装）和完整性保护（防篡改）
GET 和 POST 的区别
作用
GET 用于获取资源，而 POST 用于传输实体主体。
参数
- GET 的传参方式相比于 POST 安全性较差，因为 GET 传的参数在 URL 中是可见的，可能会泄露私密信息。
- GET以？分割，？后面是接口的数据，接口数据以=分割，=前面是参数，=后面是数据
- 并且 GET 只支持 ASCII 字符，因此 GET 的参数中如果存在中文等字符就需要先进行编码，例如中文会转换为%E4%B8%AD%E6%96%87，而空格会转换为%20。POST 支持标准字符集。
- 不能因为 POST 参数存储在实体主体中就认为它的安全性更高，因为照样可以通过一些抓包工具（Fiddler）查看。
| GET /test/demo_form.asp?name1=value1&name2=value2 HTTP/1.1 POST /test/demo_form.asp HTTP/1.1 Host: w3schools.com name1=value1&name2=value2 |
安全
安全的 HTTP 方法不会改变服务器状态，也就是说它只是可读的。GET 方法是安全的，而 POST 却不是
| 因为 POST 的目的是传送实体主体内容，这个内容可能是用户上传的表单数据，上传成功之后，服务器可能把这个数据存储到数据库中，因此状态也就发生了改变。
|
幂等性
幂等的 HTTP 方法，同样的请求被执行一次与连续执行多次的效果是一样的，服务器的状态也是一样的。
GET，HEAD，PUT 和 DELETE 等方法都是幂等的，
而POST 方法不是。所有的安全方法也都是幂等的。
可缓存
- 请求报文的 HTTP 方法本身是可缓存的，包括 GET 和 HEAD
- 但是 PUT 和 DELETE 不可缓存，POST 在多数情况下不可缓存的。
305
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
