| 更新时间 | 更新记录 |
|---|---|
| 2018.05.01 | 更新Http的基础知识部分 |
| 2018.05.03 | 更新Https的相关内容整理 |
| 2018.05.05 | 更新Http2.0的相关内容整理 |
前言
不得不说现在无论在前端和后端领域的技术迭代十分迅速，比如前段时间SpringBoot2.0的更新采用了Http2.0技术；这些基础协议的更新往往带来了实质的更新。一些名词:"HTTP 管线化"、"会话跟踪"、"跨站攻击"等等，那些你耳熟能详，但是无法细究的东西决定了这个总结诞生，或许文章会很长，但是也请静下心来阅读，而这个文章自己打算一段时间来持续更新。
基础知识
HTTP介绍
基础概念
HTTP协议（HyperText Transfer Protocol，超文本传输协议）是用于从WWW服务器传输超文本到本地浏览器的传送协议。
它的发展是万维网协会（World Wide Web Consortium）和Internet工作小组IETF（Internet Engineering Task Force）合作的结果。
它可以使浏览器更加高效，使网络传输减少。它不仅保证计算机正确快速地传输超文本文档，还确定传输文档中的哪一部分，以及哪部分内容首先显示(如文本先于图形)等。
版本
最常用的是HTTP1.0/1.1
最新版本是HTTP2.0，与1.0/1.1相比，有了更高的性能、安全性和灵活性
以前的版本0.9等
HTTP协议
URL与资源
在TCP/IP模型中，所有的网络连接都要使用方案，方案定义使用什么协议，比如http、ftp、telnet
一个标准的网络请求包括:
<scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>
但在实际使用过程中，对于不同协议可以缺少某些信息，比如
ftp://192.168.169.121
http://www.baidu.com/index.html
URI、URL和URN
URI:统一资源标识符，包括URL和URN
URL:统一资源标识符，比如http://www.baidu.com/index.html就是一个URL
URN:统一资源名，它是无关物理位置的资源名定义，例子urn:ieft:rfc:2141
目前URN处于试验阶段，实际应用还很困难，在没有特别说明时，一般我们说的URI就代表URL
媒体类型
在HTTP中，不管是word文件、js文件或者图片都是资源，通可以通过URL进行请求，但每种不同的文件都要进行区分，以便服务端和客户端进行正确处理，比如播放声音、显示文字。
因此，HTTP仔细地给每种要通过http请求响应传输的对象都打上名为MIME类型的数据格式标签。
MIME: Multipurpose Internet Mail Extension 多用途因特网邮件扩展
最开始是为了解决电子邮件系统之间的问题，后来用于定义更多类型的多谋体内容。常见的MIME：
html：text/html
Ascii: text/plain
Json:text/json
Jpg:image/jpeg
Gif:image/gif
Ppt: application/vnd.ms-powerpoint
Quicktime:video/quicktime
协议介绍
协议栈
HTTP在TCP/IP协议栈中的位置
image
HTTP是基于TCP/IP的应用，因此HTTP无须关心网络寻址、数据传输和拓扑结构
协议工作流程
协议图
在HTTP1.0/1.1中，HTTP采用请求响应模型来处理HTTP事务 HTTP事务有一条请求命令和一个响应结果组成，它们通过HTTP报文进行数据传输
注意：请求是从客户端发往服务端，而响应是从服务端发回客户端
HTTP的工作过程
HTTP的工作过程
- （1）客户端连接到Web服务器
- （2）发送HTTP请求
- （3）服务器接受请求并返回HTTP响应
- （4）释放连接TCP连接
- （5）客户端浏览器解析HTML内容
HTTP报文
报文
HTTP1.0/1.1报文由三部分组成：起始行、首部以及可选、包含数据的主体
image
其中起始行和首部是由行分隔的ASCII文本
主体是一个可选的数据块，主体中可以包含文本也可以包含二进制数据，也可以为空，与首部通过空一行进行区分
请求报文的格式：
<method> <request-url> <version>
<headers>
<entity-body>
响应报文的格式：
<version> <status> <reason-phrase>
<headers>
<entity-body>
具体例子：
浏览器报文
注：部分文章也将HTTP请求报文分为两部分请求头和请求体，请求头的第一行为请求行。
首部字段
HTTP首部字段向请求和响应报文中添加了一些附加信息，是一系列 key-value的列表,比如Content-Type:image/jpeg 表示类型是jpeg图片
首部的分类包括
通用首部：在请求和响应中都出现的信息
请求首部：只在请求报文中出现的信息
响应首部：只在响应报文中出现的信息
实体首部：描述主题的长度、内容等的信息
扩展首部：在HTTP规范中没有定义的其他信息
实体
HTTP实体是HTTP报文的负荷，是HTTP要传输的数据内容。
方法
HTTP基本的方法包括：GET/POST/HEAD/PUT/TRACE/OPTIONS，用来告诉服务端要做什么操作
GET
GET是最常用的方法，通常用于请求服务器发送某个资源
GET
POST
POST是常用的方法之一，用于向服务端提交数据，有主体
POST
HEAD
与GET类似，但在响应中只有首部，不返回具体数据，可以用来查看资源是否存在
PUT/TRACE/OPTIONS/DELETE
PUT:用于向服务端写入文档
TRACE:用于跟踪某个请求
OPTIONS:用于查询服务端支持的方法
DELETE:用于删除服务端某个资源
其他扩展方法
HTTP在设计之初就被设计成可扩展的，这样就可以适应新的特性。
扩展方法是在HTTP规范中没有定义的方法，它们有特别的用处，但需要服务端进行实现：
LOCK：锁定某个资源
COPY：拷贝某个资源
MOVE：移动某个资源
状态码
状态码是响应报文中对请求所做事情的处理结果，以方便客户端处理响应数据
状态码分为五大类：
信息性状态码：100~199
成功状态码：200~299
重定向状态码：300~399
客户端错误状态码：400~499
服务端错误状态码：500~599
常见的状态码有如下几种
- 200 OK 客户端请求成功
- 301 Moved Permanently 请求永久重定向
- 302 Moved Temporarily 请求临时重定向
- 304 Not Modified 文件未修改，可以直接使用缓存的文件。
- 400 Bad Request 由于客户端请求有语法错误，不能被服务器所理解。
- 401 Unauthorized 请求未经授权。这个状态代码必须和WWW-Authenticate报头域一起使用
- 403 Forbidden 服务器收到请求，但是拒绝提供服务。服务器通常会在响应正文中给出不提供服务的原因
- 404 Not Found 请求的资源不存在，例如，输入了错误的URL
- 500 Internal Server Error 服务器发生不可预期的错误，导致无法完成客户端的请求。
- 503 Service Unavailable 服务器当前不能够处理客户端的请求，在一段时间之后，服务器可能会恢复正常。
Https的基础知识
超文本传输安全协议（英语：Hypertext Transfer Protocol Secure，缩写：HTTPS，常称为HTTP over TLS，HTTP over SSL或HTTP Secure）是一种通过计算机网络进行安全通信的传输协议。HTTPS经由HTTP进行通信，但利用SSL/TLS来加密数据包。
Http与Https
SSL（Secure Socket Layer，安全套接字层）：1994年为 Netscape 所研发，SSL 协议位于 TCP/IP 协议与各种应用层协议之间，为数据通讯提供安全支持。
TLS（Transport Layer Security，传输层安全）：其前身是 SSL，它最初的几个版本（SSL 1.0、SSL 2.0、SSL 3.0）由网景公司开发，1999年从 3.1 开始被 IETF 标准化并改名，发展至今已经有 TLS 1.0、TLS 1.1、TLS 1.2 三个版本。SSL3.0和TLS1.0由于存在安全漏洞，已经很少被使用到。TLS 1.3 改动会比较大，目前还在草案阶段，目前使用最广泛的是TLS 1.1、TLS 1.2。
Https
HTTP 传输面临的巨大的安全问题如下：
- 隐私泄露
- 页面劫持
- 劫持路径及分类
HTTP 向 HTTPS 演化的过程
第一步：为了防止上述现象的发生，人们想到一个办法：对传输的信息加密（即使黑客截获，也无法破解）
image
如上图所示，此种方式属于对称加密，双方拥有相同的密钥，信息得到安全传输，但此种方式的缺点是：
- 不同的客户端、服务器数量庞大，所以双方都需要维护大量的密钥，维护成本很高
- 因每个客户端、服务器的安全级别不同，密钥极易泄露
第二步：既然使用对称加密时，密钥维护这么繁琐，那我们就用非对称加密试试
image
如上图所示，客户端用公钥对请求内容加密，服务器使用私钥对内容解密，反之亦然，但上述过程也存在缺点：
- 公钥是公开的（也就是黑客也会有公钥），所以第 ④ 步私钥加密的信息，如果被黑客截获，其可以使用公钥进行解密，获取其中的内容
第三步：非对称加密既然也有缺陷，那我们就将对称加密，非对称加密两者结合起来，取其精华、去其糟粕，发挥两者的各自的优势
image
如上图所示 - 第 ③ 步时，客户端说：（咱们后续回话采用对称加密吧，这是对称加密的算法和对称密钥）这段话用公钥进行加密，然后传给服务器
- 服务器收到信息后，用私钥解密，提取出对称加密算法和对称密钥后，服务器说：（好的）对称密钥加密
- 后续两者之间信息的传输就可以使用对称加密的方式了
遇到的问题：
- 客户端如何获得公钥
如何确认服务器是真实的而不是黑客
第四步：获取公钥与确认服务器身份
image
-
获取公钥
提供一个下载公钥的地址，回话前让客户端去下载。（缺点：下载地址有可能是假的；客户端每次在回话前都先去下载公钥也很麻烦）
回话开始时，服务器把公钥发给客户端（缺点：黑客冒充服务器，发送给客户端假的公钥） -
那有木有一种方式既可以安全的获取公钥，又能防止黑客冒充呢？ 那就需要用到终极武器了：SSL 证书（申购)
image
如上图所示，在第 ② 步时服务器发送了一个SSL证书给客户端，SSL 证书中包含的具体内容有：证书的发布机构CA
证书的有效期
公钥
证书所有者
签名
……… -
客户端在接受到服务端发来的SSL证书时，会对证书的真伪进行校验，以浏览器为例说明如下：
- 首先浏览器读取证书中的证书所有者、有效期等信息进行一一校验
- 浏览器开始查找操作系统中已内置的受信任的证书发布机构CA，与服务器发来的证书中的颁发者CA比对，用于校验证书是否为合法机构颁发
- 如果找不到，浏览器就会报错，说明服务器发来的证书是不可信任的。
- 如果找到，那么浏览器就会从操作系统中取出 颁发者CA 的公钥，然后对服务器发来的证书里面的签名进行解密
- 浏览器使用相同的hash算法计算出服务器发来的证书的hash值，将这个计算的hash值与证书中签名做对比
- 对比结果一致，则证明服务器发来的证书合法，没有被冒充
- 此时浏览器就可以读取证书中的公钥，用于后续加密了
-
所以通过发送SSL证书的形式，既解决了公钥获取问题，又解决了黑客冒充问题，一箭双雕，HTTPS加密过程也就此形成
Htttp2.0
HTTP/2 （原名HTTP/2.0）即超文本传输协议 2.0，是下一代HTTP协议。是由互联网工程任务组（IETF）的Hypertext Transfer Protocol Bis (httpbis)工作小组进行开发。是自1999年http1.1发布后的首个更新。HTTP 2.0在2013年8月进行首次合作共事性测试。在开放互联网上HTTP 2.0将只用于 https:// 网址，而 http:// 网址将继续使用HTTP/1，目的是在开放互联网上增加使用加密技术，以提供强有力的保护去遏制主动攻击。DANE RFC6698允许域名管理员不通过第三方CA自行发行证书。
Http2.0的优势；
-
提升web的性能，在与 HTTP/1.1 完全语义兼容的基础上，进一步减少了网络延迟
web性能对比
HTTP/2: the Future of the Internet 这是 Akamai 公司建立的一个官方的演示，用以说明 HTTP/2 相比于之前的 HTTP/1.1 在性能上的大幅度提升。 同时请求 379 张图片，从Load time 的对比可以看出 HTTP/2 在速度上的优势。
延时问题
使用chrome的开发工具的操作时，可以明显发现Http1.0的延时问题比较。 -
多路复用 (Multiplexing)
多路复用允许同时通过单一的 HTTP/2 连接发起多重的请求-响应消息。
众所周知 ，在 HTTP/1.1 协议中 「浏览器客户端在同一时间，针对同一域名下的请求有一定数量限制。超过限制数目的请求会被阻塞」。
image
HTTP/2 的多路复用(Multiplexing) 则允许同时通过单一的 HTTP/2 连接发起多重的请求-响应;因此 HTTP/2 可以很容易的去实现多流并行而不用依赖建立多个 TCP 连接，HTTP/2 把 HTTP 协议通信的基本单位缩小为一个一个的帧，这些帧对应着逻辑流中的消息。并行地在同一个 TCP 连接上;往往有效的解决了统一域名请求限制阻塞问题。 -
**二进制分帧 **
在二进制分帧层中， HTTP/2 会将所有传输的信息分割为更小的消息和帧（frame）,并对它们采用二进制格式的编码 ，其中 HTTP1.x 的首部信息会被封装到 HEADER frame，而相应的 Request Body 则封装到 DATA frame 里面。
++HTTP/2 通信都在一个连接上完成，这个连接可以承载任意数量的双向数据流++。
在过去， HTTP 性能优化的关键并不在于高带宽，而是低延迟。TCP 连接会随着时间进行自我「调谐」，起初会限制连接的最大速度，如果数据成功传输，会随着时间的推移提高传输的速度。这种调谐则被称为 TCP 慢启动。由于这种原因，让原本就具有突发性和短时性的 HTTP 连接变的十分低效。
image
总结：- 单连接多资源的方式，减少服务端的链接压力,内存占用更少,连接吞吐量更大
- 由于 TCP 连接的减少而使网络拥塞状况得以改善，同时慢启动时间的减少,使拥塞和丢包恢复速度更快
-
首部压缩（Header Compression）
HTTP/1.1并不支持 HTTP 首部压缩，为此 SPDY 和 HTTP/2 应运而生， SPDY 使用的是通用的DEFLATE 算法，而 HTTP/2 则使用了专门为首部压缩而设计的 HPACK 算法。
image
-
服务端推送
服务端推送是一种在客户端请求之前发送数据的机制。在 HTTP/2 中，服务器可以对客户端的一个请求发送多个响应。Server Push 让 HTTP1.x 时代使用内嵌资源的优化手段变得没有意义；如果一个请求是由你的主页发起的，服务器很可能会响应主页内容、logo 以及样式表，因为它知道客户端会用到这些东西。这相当于在一个 HTML 文档内集合了所有的资源，不过与之相比，服务器推送还有一个很大的优势：可以缓存！也让在遵循同源的情况下，不同页面之间可以共享缓存资源成为可能。
image
HTTPS、SPDY和HTTP/2的性能比较
文章到此，基本介绍个人同样推荐文章《HTTP,HTTP2.0,SPDY,HTTPS看这篇就够了》；并非推荐但是感觉总结也不错。个人的文章感觉搬砖感觉更多（加油！）
参考内容：
网友评论