HTTP特点：
- 无连接
- 限制每次连接（tcp）只处理一个请求
- 服务器处理完客户的请求，并收到客户的应答后，即断开连接(tcp)（原避免服务器端口资源浪费，后面适应发展需要在一个页面下多个请求，因此后面改善 keep-live)
- 无状态
- 提高响应速度
- 协议对于事务处理没有记忆能力。当次事务如果要利用前面请求传递的信息，则需要重传。（后面通过 cookie、session 改善，当次请求如果信息量过大，则会导致请求量太大，请求时间长）
导航
文章目录
一、TCP/IP 协议族
HTTP协议是构建在 TPC/IP 协议之上的协议，是TCP/IP协议的子集
特征：
- 分层管理 （四层）
- 应用层
- 定义：一般为我们编写的应用程序，决定了向用户提供的应用服务。可以通过系统调用与传输层进行通信。
- 例子：FTP、DNS、HTTP、SMTP等协议
- 传输层
- 定义：通过系统调用向应用层提供处于网络连接中的两台计算机之间的数据传输功能
- 例子：TCP（面向连接，三次握手四次挥手，比较可靠，效率低）、UDP（无连接，可靠性低，效率高）等协议
- 网络层
- 定义：用来处理在网络上流动的数据包，
数据包是网络传输的最小数据单元。该层规定了通过怎样的路径（传输路线）到达对方计算机，并把数据包传输给对方。 - 例子：IP、ARP等协议
- 定义：用来处理在网络上流动的数据包，
- 数据链路层（网络接口层）
- 定义：用来处理连接网络的硬件部分，包括控制操作系统、硬件设备驱动、NIC(Network Interface Card，网络适配器）以及光纤等物理可见部分。硬件上的范畴均在链路层的作用范围之内。
- 应用层
二、数据包
1.数据包封装过程
2.HTTP数据传输过程
数据发送以及接收。会经过上层传输到下层，这过程经过数据包封装，打上每一层的头部信息。在到达对方计算机后由下层到达上层，都将逆向一级一级将头部信息进行解析删除。
三、一些重要的支持协议
DNS（应用层）
用于解决域名到IP地址之间的解析服务（IP地址不容理解记住）
DNS 解析过程
- 浏览器会检查本地缓存中有没有解析过该域名，如果缓存有则直接使用，没有则继续
- 解析本地 host 文件时有对应的域名ip映射，如果有则返回，没有继续
- 向本地解析服务器（LDNS Local DNS Server）发起域名解析请求。（本地配置中所配置的DNS服务器地址），如果服务器缓存中存在对应的解析结果则返回，否则继续。
- 向根域名解析器（RDNS Root DNS Server) 发起请求，根域名服务器返回通用顶级域名解析服务器（gTDL）地址
- 本地域名服务器（LDNS）向gTDL发起解析域名请求，gTLD服务器返回请求地址所注册的域名服务器（Name Server服务器）
- 本地域名服务器（LDNS）向 Name Server服务器发起域名解析请求，Name Server 服务器解析映射表，返回该域名对应的ip和TTL（LDNS进行缓存这个域名和ip的对应关系表，缓存时间由TTL决定）
- LDNS返回ip给浏览器，客户端进行缓存，缓存时间由TTL决定
DNS的记录类型
| 类型 | 说明 |
|---|---|
| A记录 | A代表的是Address，用来指定域名对应的IP地址，A记录允许将多个域名解析到一个IP地址，但不允许将一个域名解析到多个IP上。 |
| MX记录 | MX代表的是Mail Exchage，就是可以将某个域名下的邮箱服务器指向自己的Mail Server |
| CNAME记录 | CNAME指的是Canonical Name，也就是别名解析，可以将指定的域名解析到其他域名上，而其他域名就是指定域名的别名，整个解析过程称为别名解析。 |
| NS记录 | 就是为了某个域名指定了特定的DNS服务器去解析。 |
| TXT记录 | 为某个主机名或者域名设置特定的说明。 |
TCP (传输层)
TCP 三次握手（确保双方收发能力的最少步骤）
-
客户端发送SYN标记的连接请求报文段，进入SYN_SEND状态，等待服务器确认
- 服务器确认客户端发送能力和服务器接收能力
-
服务器接收SYN报文段，发送ACK信息对客户端SYN报文段确认，发送服务器SYN请求信息，将之前的ACK信息打包一起（SYN+ACK报文段），一起发送给客户端，服务器进入SYN_RECV状态。
- 客户端确认服务器接收能力、服务器发送能力、客户端发送能力和客户端接收能力
-
客户端接收到服务器的SYN+ACK报文段后，向服务器发送ACK确认报文段，客户端进入ESTABLISHED状态，服务器接收后进入ESTABLISHED状态，完成TCP三次握手过程。
- 服务器确认客户端接收能力和服务器发送能力
-
两端进入数据传送。
TCP的四次挥手
- 第一次挥手：TCP发送一个FIN(结束)，用来关闭客户端到服务器端的连接。
- 客户端发起关闭请求
- 第二次挥手：服务器端收到这个FIN后发回一个ACK确认标示，确认收到。
- 服务器回复收到
- 第三次挥手：服务器端发送一个FIN到客户端，服务器端关闭客户端的连接。
- 服务器关闭成功（关闭等待阶段）后发送要求客户关闭
- 第四次挥手：客户端发送ACK报文确认，这样关闭完成。
- 客户端回复收到，服务器最终关闭
挥手的四次是为了确保双方已经关闭连接
IP (网络层)
四、HTTP事务流程
- 客户端发起请求，通过DNS服务器查询域名对应的IP地址
- 浏览器发起HTTP请求，通过TCP/IP协议发送给服务器
- 服务器根据请求返回响应内容，通过TCP/IP协议返回给客户端
五、请求方法
GET
简单的通过URI进行资源访问，GET并不包含body体，对于所需要的现象都在URL里面体现。
- 注意长度，URI 长度可能会超限（各种浏览器限制不同）
POST
POST用于提交主体内容（表单）
- 相对于GET，POST主体内容在后面进行换行后天就主体内容
PUT
- 从客户端向服务器传送的数据取代指定的文档的内容
- 与POST的最大不同是，PUT是幂等（无论做多少次操作都是实现相同的结果），POST不是
- PUT更适合作为传输资源，更新操作（无验证机制）
HEAD
- 类似于GET，不过返回的响应中不存在内容，只获取头部
- 经常用于测速连接有效性
DELETE
- 与PUT相反，指定用于删除操作（无验证机制）
OPTIONS
通常用来查询针对请求URI指定的资源支持的方法。
比如执行
curl -X OPTIONS http://127.0.0.1:8080 -i
系统将返回
HTTP/1.1 200
Set-Cookie: JSESSIONID=F25AB057FAA74D590A67E014F9AC;path=/;HttpOnly
Allow: GET, HEAD, POST, PUT, DELETE, OPTIONS
Content-Length: 0
Date: Web, 07 Aug 2019 11:05:44 GMT
在头部Allow 中返回所支持的请求类型
TRACE
- 回显服务器收到的请求，主要用于测速或诊断（跨站追踪攻击）
CONNECT
- 开启一个客户端与请求资源之间的双向沟通的通道，可以用来创建隧道
- 例子：代理，通过与代理创建的隧道，代理只负责转发数据，但是不对数据进行读取
六、状态码
用来表示网页超文本传输协议响应状态的3位数字状态码
分类与含义
2XX
3XX
4XX
5XX
七、字符集与编码
关键字：编码规范、 编码方式、字符集、字库表
- 一个二进制数通过一种编码方式，转化成编码字符集中对应的地址，然后在字库表里面找到一个对应的字符显示给用户
- 一种编码规范可以存着多种编码方式，多种编码方式存着性能空间上的差异，比如Unicode规范可以有 UTF-8(变长) 和 UTF-16（固容） 不同的实现方式
- UTF-16 拥有两个字节，对应复杂字符，比如中文可以很方便的存着，如果为英文则只需要一个字节即可实现，但是对应UTF-16来说还是需要两个字符来存储，因此存着空间浪费。但是在解析上，对二级制数据只需要按照2个字节的读取拆分，既可快速解码。
- UTF-8 是根据情况进行一个字节、两个字节或三个字节的变长容量。存储上并不能将整个字段8位用于表示字符，还需要额外提供变长标记、大端小端标记等。一个字节只有2的7次方可表示的容量，两个字节则为2的11次方，三个则为2的16次方。
编码规范
- ASCII码
- GBK（主要面向中文）
- ISO-8859-1（主要面向西方文字）
- Unicode（面向全世界兼容）
URL的编码与解码
需要编码内容
- URL 所使用的是ASCII字符集编码，如果URL中存在非该编码字符，则需要对其进行编码
- URL 中的保留字符也需要进行编码，比如 &、？
编码规范
- "%编码"规范
- 对URL中属于ASCII字符集的非保留字不做编码；对URL中的保留字需要取其ASCII内码，然后加上 % 前缀将该字符进行编码；对于URL中的非ASCII字符需要取其Unicode内码，然后加上 % 前缀将该字符进行编码
八、Cookie 与 Session
Cookie
实际上为一段小文本信息。当客户端请求服务器时，如果服务器需要记录该用户状态，则向客户端浏览器颁发一个Cookie，客户端（浏览器）将把Cookie保存起来。当浏览器再请求该网站时，浏览器吧请求的网址连同Cookie一并发送给服务器，服务器检查该Cookie，以此来辨认用户状态。
- 不同浏览器对Cookie 保存实现不同，Cookie仅是规范
Session
是另外一种记录客户状态的机制，保存在服务器上。客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上。（服务器技术），客户端再次访问时，只需要从Session中找到该用户的状态即可。
保存Session ID的方式
- Cookie
- 一般保存形式通过 cookie 保存
- URL重写
- 可以通过URL主动传递
- 例子：http://…/xxx;Sessionid=dfjlsjfioewjjflXXsflkjdsfl(路径形式) 或 http://…/xxx?Sessionid=fioewjffjdsflkjdkfjasdlfjdl(参数形式)
- 隐藏表单
Session有效期
- Session 超时失效（有效时间）
- 程序主动注销 HttpSession.invalidate() 等
- 程序进程终止
Cookie 与 Session 不同
- 存放位置不同（客户端、服务端）
- 安全性不同（Cookie 较松、服务器较为严格）
- 有效期不同（Cookie 可以很长甚至永久、服务器较短）
- 对服务器压力不同（Cookie保存在客户端很少压力、Session保存服务器占用资源）
九、身份认证
认证方式
- BASIC认证（基本认证）
- DIGEST认证（摘要认证）
- SSL客户端认证
- FormBase认证（基于表单认证）
BASIC 认证（安全性差）
使用质询/响应的方式，并且直接发送明文密码
DIGEST认证
相对BASIC 来说，不在直接发送明文密码，解决防止密码被直接窃听，用户欺骗还是不行
SSL 客户端认证
借助HTTPS客户度证书完成认证，但是维护成本高。
基于表单认证
并不是在HTTP协议中定义而是在Web应用中实现，借助于Cookie 和 Session 来保持用户状态。
十、长连接和短连接
HTTP的长短连接本质是TCP的长短连接。HTTP 1.0 默认使用短连接，一次请求一次连接后就中断，从1.1开始默认使用长连接，保持连接性
- 使用 Connect:keep-live
十一、代理（拦截服务器）
代理服务器作为一种既是服务器又是客户机的中间程序，主要用于转发客户系统的网络访问请求。但是，代理服务器不只是简单地向真正的因特网服务器转发请求，它还可以控制用户的行为，对接收到的客户请求进行决策，并根据过滤规则对用户请求进行过滤。
主要作用：
- 抓包
- 翻墙
- 匿名访问
- 过滤器
通过代理服务器，网络管理员可以实现比用包过滤路由器更严格的安全策略。不同于使用通用的包过滤路由器来管理通过防火墙的因特网服务流向，代理服务器通过在网关上为每项需要的应用安装专用的代码（代理服务）来工作。如果网络管理员没有为某一特殊服务安装代理服务代码，该服务就不会被支持，也不会通过防火墙转发相应的客户请求。并且，这种代理服务器码能被配置成仅支持某项服务的网络管理员认为可以接受的那部分特征，而不支持其他的特征。
十二、网关
作为某种翻译器使用（协议转换器 的角色），它抽象出一种能够到达资源的方法。网关是资源和应用程序之间的粘合剂
Web 网关在一侧使用HTTP协议，在另一侧使用另一种协议。
<客户端协议>/<服务端协议>
常见的网关类型
- （HTTP/*）服务器Web网关 ： 客户端使用HTTP协议通过网关转换成服务要求的不同协议
- （HTTP/HTTPS）服务器安全网关：将客户端使用的HTTP转换为HTTPS协议
- （HTTPS/HTTP）客户端安全加速网关：将客户端HTTPS转换为HTTP协议
- 资源网关：使用不同协议转换为对应需要的资源，HTTP转RPC
十三、HTTP缓存
相关头字段
- Cache-Control
- no-store: 所有内容都不缓存
- no-cache: 缓存，但是浏览器使用缓存前，都会请求服务器判断资源是否是最新。
- max-age=x(秒)：请求缓存后的X秒不在发起请求（1.0 的EXPIRES 头部字段响应，但是优先该字段）
- s-maxage=x(秒)：代理服务器请求源站缓存后的X秒不在发起请求，只对CDN缓存有效
- public：客户端和代理服务器（CDN）都可缓存
- private：只有客户端可以缓存
- Expires (代表资源过期时间，由服务器返回提供，与max-age共存时，优先级低)
- Last-Modified (资源最新修改时间，由服务器告知客户端，用于刷新资源时间)
- if-Modified-Since (资源最新修改时间，由客户端告诉服务器，会与Last-Modified进行对比)
- Etag (资源标识，由服务器告诉客户端)
- if-None-Match (缓存资源标识，由客户端告诉服务器，与Etag为一对，会进行对比)
工作原理：
- 客户端向服务器发起请求，如果发现请求资源 Expires 过期，则会向服务器进行更新请求，如果发送修改则服务器返回新文件和新Expires时间，否则返回304（频繁请求、并且服务器的更新无法感知）
- 在Expires基础增加，Last-Modified(服务器响应带) 和 if-Modified-Since(客户端请求带)，当客户端向服务器发起请求时，发现文件过期，则带上 if-Modified-Since 最近文件更新时间向服务器请求新文件，服务器通过对比文件更新时间，如果发送修改则返回新的 Last-Modified 修改时间以及新文件，否则返回304（但是如果文件频繁修改，修改记录在1s以内则无法触发）
- 在之前的基础上增加 Etag与If-None-Match 以及 max-age 字段，Etag、If-None-Match 用来标记资源唯一标识，如果设置在发送时设置了该资源标识，则服务器仅对该资源标识进行匹配，忽略其他有效期（更新时间）等验证。（针对资源标识频繁变更，但是该方案仅在发生过期时，在服务器匹配方案上的调整）
缓存改进
- MD5缓存： 为了解决在未发生过期的情况下，更新缓存资源，将资源名进行MD5命名，保证在每次请求时资源名都和上次不一样，这将导致缓存策略失败，从而实现每次资源拉取时都拉取最新资源
- CDN缓存：构建在网络之上的内容分发网络，依靠部署在各地的边缘服务器，通过中心平台的负责均衡、内容分发、调度等功能模块，使用户就近获取需要的内容，降低网络拥塞，提高用户访问响应速度和命中率
十四、内容协商机制
客户端与服务器就响应的资源内容进行交涉，然后提供给客户端最为适合的资源，内容协商会以响应资源的语言，字符集，编码方式等作为判断的标准。
协商方式
- 客户端驱动，由客户端发起，服务器发送回可选项类别，客户端选择后发起第二次请求。（迟延、多次请求问题）
- 服务器驱动，服务器检查客户端请求头来决定提供的版本（）
- 透明协商，某个中间社保（通常是缓存代理）代表客户端进行协商
服务器驱动
相关头部信息
| 客户端请求头部名 | 说明 | 对应服务器返回头部名 |
|---|---|---|
| Accept | 告知服务器发送何种媒体类型 | Content-Type |
| Accept-Language | 告知服务器发送何种语言 | Content-Language |
| Accept-Charset | 告知服务器发送何种字符集 | Content-Type |
| Accept-Encoding | 告知服务器采用何种编码 | Content-Encoding |
近似匹配
Accept-Language:en;q=0.5,fr;q=0.0,nl;q=1.0,tr;q=0.0
该语言表示，如果有荷兰语（nl）则优先返回，如果没有则优先英语（en），不接受 法语（fr）和土耳其语（tr），q为权重值，如果没有则返回服务默认语言
十五、断点续传和多线程下载
相关头部名
Range
客户端发起时携带Range，用于请求头中，指定第一个字节的位置和最后一个字节的位置，一般格式为：
Range:(unit=first byte pos)-[last byte pos]
例如：
Range:bytes=0-499
Range:bytes=500-
Range:bytes=-500
Range:bytes=500-600,601-999
Content-Range
服务器根据Range返回的响应头，服务器会在Content-Range头部返回当前接受的范围和文件总大小，返回格式为：
Content-Range:bytes(unit first byte pos)-[last byte pos]/[entity length]
例如：
Content-Range:bytes 512000-/1024000
根据不同的下载方式会返回不同的响应状态
- 使用断点续传方式：
HTTP/1.1 206 Partial Content - 不适用断点续传方式：
HTTP/1.1 200 OK
十六、HTTPS
关键词： 证书颁发机构、服务器网址、机构私钥加密（服务端公钥）、机构私钥加密（证书签名）、操作系统证书列表、浏览器证书列表
HTTP+TLS(传输层加密协议，前身是SSL协议)
相对于HTTP提升
- 内容加密（非对称密钥交换、对称内容加密）（HTTP为明文传输）
- 身份认证（数字证书）（HTTP并不对发送方进行验证，直接信任）
- 数据完整性（HTTP不会对接收内容进行是否篡改的验证）
流程
- 服务器将公钥交给第三方证书机构，机构通过自身私钥对公钥进行加密产生证书给服务器。（签名证书）
- 客户端与服务器建立连接，服务器将证书发送给客户端。（服务器->证书->客户端）
- 客户端通过机构公钥解密证书获得服务器公钥。（使用合法第三方机构公钥解密证书，验证该证书是合法的服务器提供，非中间人伪造）
- 使用获得的公钥对客户端公钥进行加密，将加密后的客户端公钥发送给服务器，服务器通过自身的私钥解开加密后的客户端公钥，获得客户端公钥。（客户端->加密后的客户端公钥->服务器，两者都获得双方公钥后可以进行通信）
加密
在HTTPS中同时采用了对称加密和非对称加密，在交换密钥环节使用了非对称加密（以RSA为代表），在建立通信后交换报文采用对称加密方式（以DES为代表）。
认证环节使用非对称加密可以有效防止认证信息泄露
数字证书认证（CA）
在非对称加密中，最大的问题是对于密钥的生成、保管以及对于公钥的合法性（是否来源于合法机构）。
为了解决公钥真实性问题，HTTPS使用了数字证书认证机构以及它公开的密钥证书。
CA使用具体的流程如下：
- 服务器的运营人员向数字证书认证机构(CA)提出公开密钥的申请;
- CA通过线上、线下等多种手段验证申请者提供信息的真实性，如组织是否存在、企业是否合法，是否拥有域名的所有权等；
- 如果信息审核通过，CA会对已申请的公开密钥做数字签名，然后分配这个已签名的公开密钥，并将该公开密钥放入公钥证书后绑定在一起。
证书包含以下信息：申请者公钥、申请者的组织信息和个人信息、签发机构CA的信息、有效时间、证书序列号等信息的明文，同时包含一个签名；
签名的产生算法：首先，使用散列函数计算公开的明文信息的信息摘要，然后，采用CA的私钥对信息摘要进行加密，密文即签名；
- 客户端在HTTPS握手阶段向服务器发出请求，要求服务器返回证书文件；
- 客户端读取证书中的相关的明文信息，采用相同的散列函数计算得到信息摘要，然后，利用对应CA的公钥解密签名数据，对比证书的信息摘要，如果一致，则可以确认证书的合法性，即公钥合法；
客户端然后验证证书相关的域名信息、有效时间等信息； - 客户端会内置信任CA的证书信息(包含公钥)，如果CA不被信任，则找不到对应CA的证书，证书也会被判定非法。
成本
- 证书费用以及更新维护
- HTTPS降低用户访问速度
- CPU资源
性能影响
- 协议交互所增加的网络RTT
* HTTPS 如果在用户执行HTTP需要进行302重定向为HTTPS链接，并且由于发送了端口变更，需要重新进行握手，在进行 TLS握手，进行加密套件协商和证书验证
* Ocsp 在线证书状态协议，返回证书状态（过期、无效等）
- 加解密耗时
- 计算耗时
- 客户端耗时（计算证书，加解密）
- 服务器耗时（加解密等）
Android 中对TLS 版本的支持
Client Socket支持
| protocol | 支持API（需要配置） | 默认支持API |
|---|---|---|
| SSLv3 | 1-25 | 1-22 |
| TLSv1 | 1+ | 1+ |
| TLSv1.1 | 16+ | 20+ |
| TLSv1.2 | 16+ | 20+ |
| TLSv1.3 | 29+ | 29+ |
Server Socket 支持
| protocol | 支持API（需要配置） | 默认支持API |
|---|---|---|
| SSLv3 | 1-25 | 1-22 |
| TLSv1 | 1+ | 1+ |
| TLSv1.1 | 16+ | 16+ |
| TLSv1.2 | 16+ | 16+ |
| TLSv1.3 | 29+ | 29+ |
注意默认情况下，服务器和客户端通信需要
十七、HTTP的瓶颈
- 带宽
- 延迟
- 一条连接上只可能进行一个请求
- 请求只能从客户端发起，不可接受响应之外的指令
- 请求/响应投不经压缩就发送
- 每次互相发送相同的头部造成浪费
- 非强制压缩发送
十八、WebSocket
WebSocket 是HTTP一种解决不足上的新协议，遵守HTTP的握手规范，所谓的基于HTTP，是对HTTP的兼容，但是和HTTP协议基本没有关系
- 真正的全双工方式
- 减少通信量
头部信息
- Upgrade:WebSocket 固定字段，用于通知服务器需要WebSocket服务
- Connection:Upgrade 固定字段
- Sec-WebSocket-Key Base64 encode值，由浏览器自动生成用于验证是否为WebScoket服务器
- Sec-WebSocket-Protocol 用户自定义字段，用来区分同URL下，不同的服务需要的协议，通知服务器，客户端所需要的服务类型
- Sec-WebSocket-Version 通知服务器WebSocket Draft 协议版本
其他技术
- Ajax 采用不断请求返回Response的轮询 形式
- long poll 采用轮询，在没有结果前则一直阻塞，直到达成某个条件才返回Response
以上两种都需要客户端主动发起Request，并且ajax 需要比较好的响应速度，而 long poll 会产生比较高的并发
解决的问题
- 建立链接后，可以互相发送（推送），不需要由客户端发起才能返回Response，解决高并发，延迟问题
- 加快响应速度，减少重复的HTTP验证握手，WebSocket只需要一HTTP握手，在一次状态中。
- 整个通讯过程可以维持状态(HTTP是无状态，每次请求都需要携带)
- WebSocket 是新协议，必须客户端和服务器同时支持才能执行
十九、SPDY协议（会话层）
SPDY协议是用于加强HTTP协议，是作用于TLS之上的协议，它的出现是用于解决HTTP仍然存在的一些问题。
目前还有的HTTP 缺陷
- 单路链接 请求效率低
- 只允许客户端发起请求
- 头部冗余
SPAY 对缺陷的改进
- 允许多路复用，请求优化（建立一个TCP连接，可以多次发起请求，并且可以设置优先级，HTTPS先进先出）
- 支持服务器推送技术
- 压缩了HTTP头
- 强制使用SSL传输协议（HTTPS)
但是在之后HTTP2.0已解决以上问题（实际应该是采纳了Google的方案），google 已放弃维护，转而支持HTTP2.0
二十、HTTP2.0
二进制分帧
- 对于以前的 Header 部分信息被封装进2.0的HEADERS frame 帧
- 数据部分被封装到 DATA frame 帧
- 以上数据被进行二进制处理，这些帧在传输时可以乱序发送，在获取后再进行重新组装，用于提升传输效率（重试效率）
二十一、WebDAV协议
所增加的请求方法和状态码
为了方便对文件进行操作，WebDAV 增加了几种新的方法和状态码
| 方法 | 用途 |
|---|---|
| PROPFIND | 获取属性 |
| PROPPATCH | 修改属性 |
| MKCOL | 创建集合 |
| COPY | 复制资源及其属性 |
| MOVE | 移动资源 |
| LOCK | 资源加锁 |
| UNLOCK | 资源解锁 |
| 状态码 | 说明 |
|---|---|
| 102 Processing | 可以正常处理请求，但目前是处理中状态 |
| 207 Multi-Status | 存在多种状态 |
| 422 UnprocessibleEntity | 格式正确，内容有误 |
| 424 FailedDependency | 处理与某请求关联的请求失败，因此不再维持依赖关系 |
| 507 InsufficientStorage | 保存空间不足 |
请求：
响应：
二十二、HTTP3.0&QUIC
对之前的改进
- 使用UDP为底层协议
- 0 RTT
- 没有队头阻塞的多路复用（因为使用UDP协议，不会阻塞重传，从而避免后面数据的被应用层无法读取问题）
改进前：
改进后
- 前向纠错
对于发送的数据包，如果在一组数据里面发送某一个包（仅限于丢失一个包），则可以通过校验包（通过其他完整的数据包计算出的一个前置包）恢复丢失包的数据。
解决的问题
- 2.0 队头阻塞
- 建立连接的握手延迟大
二十三、各个版本的改进汇总
| 协议版本 | HTTP1.0 | HTTP1.1 | HTTP2.0 |
|---|---|---|---|
| HTTP1.0 | |||
| HTTP1.1 | 1. 缓存处理，HTTP1.0使用if-Modified-Since、Expires做缓存标准，HTTP1.1增加Entity Tag(eTag)、If-Unmodified-Since、If-Match、If-None-Match等更多缓存头部来控制。 2. 带宽、网络连接优化。HTTP1.0 不支持断点续传，当客户端需要服务器资源部分内容时，服务器只能返回整个资源内容。HTTP1.1加入range头，支持断点，增加返回码状态206（Partial Content）。 3. 增加新状态码。 4. 增加Host头域，并且在请求服务器时需要强制携带，否则返回400。 5. 增加长连接。支持长连接（PersistentConnection）和请求流水线（Pipelining）处理，支持一个TCP连接发起多个HTTP请求响应，HTTP1.1默认开启长连接 keep-alive | ||
| HTTP2.0 | 1. 数据压缩，使用二进制格式传输数据（Binary Format）。HTTP1.X是基于文本，需要适应不同的编码。 2. 多路复用（MultiPlexing），每个请求都有一个id，这样一个连接上存着多个请求，接收方根据id将请求归属于不同于不同的服务端。 3. HEADE 压缩，HTTP1.X 每次请求都重复发送Header，HTTP2.0使用encoder减少Header大小，通讯双方各自缓存一份header fields表，只对前一次所不同的地方进行增量传输，避免重复传输header。 4. 服务端推送，具备主动推送到客户端能力 |
二十四、关于其他的问题
-
提升访问速度
直接使用IP访问，不经过域名DNS -
双向通信方案
- 建立自身的TCP长连接，基于TCP Socket编程，定制自己的协议
- long-poling 长轮询方案，由客户端发起请求，等待服务器有新信息才返回给客户端，当完成请求后，客户端需要离开在发起请求，保持持续的连接中。
- http streaming, 通过Server Response头部增加“Transfer Encoding:chunked”童子客户端还有后续数据，保持不断开response
- websocket，但是需要双方都支持。
-
头部拥塞解决
- Pipelining 病不能完全解决该问题，Pipelining 是在上一个请求响应时，在同一个TCP连接中，发送下一个请求，但是客户端还是需要按照请求顺序来接收响应，如果前面一个还未响应，则还是会导致头部拥塞。
-
keep-alive 和 多路复用 效率
首先http1.1同域请求限制6个tcp连接建立，但是，每个http1.1的TCP都是线头阻塞的
而http2是基于流进行数据请求的，几百个请求都是可以基于一个tcp连接传递，然后通过流id进行拼接返回到每个请求上，不存在线头阻塞并且只会用到一个tcp，对于服务器的并发量提高了6倍
并且http2还有头压缩对状态行和头信息进行哈弗曼编码压缩，还有静态字典动态字典相关等技术处理节省头信息优化传输浪费流量
- HTTP 和 HTTPS 区别
- HTTP下加入SSL层，HTTPS的安全基础是SSL。
- 接收端口不一样