01_Http、Https、Http2.0 的基础知识总结(持续更新篇)

发布于 2022年 02月 25日 21:40

更新时间 更新记录
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

一个标准的网络请求包括:

://:@:/;?#

但在实际使用过程中,对于不同协议可以缺少某些信息,比如

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协议栈中的位置

HTTP是基于TCP/IP的应用,因此HTTP无须关心网络寻址、数据传输和拓扑结构

协议工作流程

在HTTP1.0/1.1中,HTTP采用请求响应模型来处理HTTP事务 HTTP事务有一条请求命令和一个响应结果组成,它们通过HTTP报文进行数据传输

注意:请求是从客户端发往服务端,而响应是从服务端发回客户端

HTTP的工作过程

  • (1)客户端连接到Web服务器
  • (2)发送HTTP请求
  • (3)服务器接受请求并返回HTTP响应
  • (4)释放连接TCP连接
  • (5)客户端浏览器解析HTML内容

HTTP报文

报文

HTTP1.0/1.1报文由三部分组成:起始行、首部以及可选、包含数据的主体

其中起始行和首部是由行分隔的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是最常用的方法,通常用于请求服务器发送某个资源

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来加密数据包。

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 传输面临的巨大的安全问题如下:

  1. 隐私泄露
  2. 页面劫持
  3. 劫持路径及分类

HTTP 向 HTTPS 演化的过程

第一步:为了防止上述现象的发生,人们想到一个办法:对传输的信息加密(即使黑客截获,也无法破解)


如上图所示,此种方式属于对称加密,双方拥有相同的密钥,信息得到安全传输,但此种方式的缺点是:

  1. 不同的客户端、服务器数量庞大,所以双方都需要维护大量的密钥,维护成本很高
  2. 因每个客户端、服务器的安全级别不同,密钥极易泄露 第二步:既然使用对称加密时,密钥维护这么繁琐,那我们就用非对称加密试试

如上图所示,客户端用公钥对请求内容加密,服务器使用私钥对内容解密,反之亦然,但上述过程也存在缺点:

  1. 公钥是公开的(也就是黑客也会有公钥),所以第 ④ 步私钥加密的信息,如果被黑客截获,其可以使用公钥进行解密,获取其中的内容 第三步:非对称加密既然也有缺陷,那我们就将对称加密,非对称加密两者结合起来,取其精华、去其糟粕,发挥两者的各自的优势

    如上图所示
  2. 第 ③ 步时,客户端说:(咱们后续回话采用对称加密吧,这是对称加密的算法和对称密钥)这段话用公钥进行加密,然后传给服务器
  3. 服务器收到信息后,用私钥解密,提取出对称加密算法和对称密钥后,服务器说:(好的)对称密钥加密
  4. 后续两者之间信息的传输就可以使用对称加密的方式了

遇到的问题:

  1. 客户端如何获得公钥 如何确认服务器是真实的而不是黑客

第四步:获取公钥与确认服务器身份

  1. 获取公钥 提供一个下载公钥的地址,回话前让客户端去下载。(缺点:下载地址有可能是假的;客户端每次在回话前都先去下载公钥也很麻烦) 回话开始时,服务器把公钥发给客户端(缺点:黑客冒充服务器,发送给客户端假的公钥)

  2. 那有木有一种方式既可以安全的获取公钥,又能防止黑客冒充呢? 那就需要用到终极武器了:SSL 证书(申购)


    如上图所示,在第 ② 步时服务器发送了一个SSL证书给客户端,SSL 证书中包含的具体内容有:

    证书的发布机构CA
    证书的有效期
    公钥
    证书所有者
    签名
    ………

  3. 客户端在接受到服务端发来的SSL证书时,会对证书的真伪进行校验,以浏览器为例说明如下:

    1. 首先浏览器读取证书中的证书所有者、有效期等信息进行一一校验
    2. 浏览器开始查找操作系统中已内置的受信任的证书发布机构CA,与服务器发来的证书中的颁发者CA比对,用于校验证书是否为合法机构颁发
    3. 如果找不到,浏览器就会报错,说明服务器发来的证书是不可信任的。
    4. 如果找到,那么浏览器就会从操作系统中取出 颁发者CA 的公钥,然后对服务器发来的证书里面的签名进行解密
    5. 浏览器使用相同的hash算法计算出服务器发来的证书的hash值,将这个计算的hash值与证书中签名做对比
    6. 对比结果一致,则证明服务器发来的证书合法,没有被冒充
    7. 此时浏览器就可以读取证书中的公钥,用于后续加密了
  4. 所以通过发送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 完全语义兼容的基础上,进一步减少了网络延迟

    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 协议中 「浏览器客户端在同一时间,针对同一域名下的请求有一定数量限制。超过限制数目的请求会被阻塞」。

    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 连接变的十分低效。


    总结

    • 单连接多资源的方式,减少服务端的链接压力,内存占用更少,连接吞吐量更大
    • 由于 TCP 连接的减少而使网络拥塞状况得以改善,同时慢启动时间的减少,使拥塞和丢包恢复速度更快
  • 首部压缩(Header Compression) HTTP/1.1并不支持 HTTP 首部压缩,为此 SPDY 和 HTTP/2 应运而生, SPDY 使用的是通用的DEFLATE 算法,而 HTTP/2 则使用了专门为首部压缩而设计的 HPACK 算法。

  • 服务端推送
    服务端推送是一种在客户端请求之前发送数据的机制。在 HTTP/2 中,服务器可以对客户端的一个请求发送多个响应。Server Push 让 HTTP1.x 时代使用内嵌资源的优化手段变得没有意义;如果一个请求是由你的主页发起的,服务器很可能会响应主页内容、logo 以及样式表,因为它知道客户端会用到这些东西。这相当于在一个 HTML 文档内集合了所有的资源,不过与之相比,服务器推送还有一个很大的优势:可以缓存!也让在遵循同源的情况下,不同页面之间可以共享缓存资源成为可能。

HTTPS、SPDY和HTTP/2的性能比较

文章到此,基本介绍个人同样推荐文章《HTTP,HTTP2.0,SPDY,HTTPS看这篇就够了》;并非推荐但是感觉总结也不错。个人的文章感觉搬砖感觉更多(加油!)


参考内容:

推荐文章