HTTP/HTTPS

参考文章：HTTP（超文本传输协议）的通俗理解_Huang_JunJun的博客-CSDN博客

小林coding小林coding的博客_CSDN博客-图解计算机网络,图解操作系统,C/C++领域博主

目录

Http

Http的优点

Http的缺点

Http1.1的改进

Http1.1的缺点

如何优化HTTP1.1？

Http2的改进

Http2的缺点

Http3

Http和Https的区别

Https握手

Https如何优化？

---

Http

超文本传输协议（Hyper Text Transfer Protocol，HTTP）是一个简单的请求-响应协议，它通常运行在TCP之上。它指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应。请求和响应消息的头以ASCII形式给出；而消息内容则具有一个类似MIME的格式。这个简单模型是早期Web成功的有功之臣，因为它使开发和部署非常地直截了当。

• 「协议」

HTTP 是一个用在计算机世界里的协议。它使用计算机能够理解的语言确立了一种计算机之间交流通信的规范（两个以上的参与者），以及相关的各种控制和错误处理方式（行为约定和规范）。

• 「传输」

所谓的「传输」，很好理解，就是把一堆东西从 A 点搬到 B 点，或者从 B 点 搬到 A 点。别轻视了这个简单的动作，它至少包含两项重要的信息。 HTTP 协议是一个双向协议。

• 「超文本」

HTTP 传输的内容是「超文本」。我们先来理解「文本」，在互联网早期的时候只是简单的字符文字，但现在「文本」。的涵义已经可以扩展为图片、视频、压缩包等，在 HTTP 眼里这些都算做「文本」。 再来理解「超文本」，它就是超越了普通文本的文本，它是文字、图片、视频等的混合体最关键有超链接，能从一个超文本跳转到另外一个超文本。 HTML 就是最常见的超文本了，它本身只是纯文字文件，但内部用很多标签定义了图片、视频等的链接，在经过浏览器的解释，呈现给我们的就是一个文字、有画面的网页了。

Http的优点

• 格式简单，http基本报文格式就是hreader和body，而且头部数据是key-value的形式，便于理解

• 灵活、易于拓展，http协议的各类请求方法、url、头字段、状态码都没有固定死，便于开发人员自定义和扩充

• 应用广泛，大多数网页，app都使用http，拥有跨平台的优越性

Http的缺点

• 无状态，虽然无状态代表服务器不需要消耗额外的资源去保存客户端传递的信息，但是假如一个用户需要登录，添加购物车、结算、支付，那么每次都需要进行验证用户信息，对用户体验很差，可使用cookie解决

• 明文传输，明文传输代表着程序员可以随时按f12去检查代码，抓包，易于检查程序代码错误，但是也意味着不安全，容易被盗取信息，可采用https解决

Http1.1的改进

• HTTP1.1采用长连接，Http1.0采用的短链接（短链接：每发起一个请求就需要新建一次TCP连接，增加了资源开销），而长连接减少了TCP连接的重复简历和断开所造成的额外开销，减轻了服务端的负载。长连接的特点：只要有任意一端没有明确提出断开连接，则保持TCP连接状态

• 管道网络传输，长连接的方式使管道网络传输成为了可能，即发出一个TCP请求，不需要等到服务器回应即可再次发送TCP请求，增加了传输效率，减少整体响应时间，但是服务器还是得按照顺序回应请求

Http1.1的缺点

• 队头阻塞：客户端向服务端发送多个TCP连接请求，但是第一个连接因某种原因阻塞了，会导致客户端一直请求不到数据，因为服务端要按照顺序回应请求

• 请求只能从客户端开始，不能从服务端开始

• 头部冗余，字段冗长，每次发送相同的首部造成的浪费较多

• 没有请求优先级控制

如何优化HTTP1.1？

减少HTTP请求

• 压缩文件，将多个小资源合并成一个大资源，减少请求次数

• 缓存

• 将由客户端处理的重定向交给代理服务器，减少重定向次数

• 按照需求访问，只访问当前用户用得到的资源

不过再怎么优化Http1.1还是有很大局限的，所以有了HTTP2

Http2的改进

• 头部压缩：如果你同时发送多个请求，他们的头是一样的或是相似的，那么协议会帮你消除重复部分

• 二进制格式：头信息和数据体都是二进制，并且统称为帧，头信息帧和数据帧，虽然对人不友好但是对计算机友好，计算机无需将明文转化为二进制，增加了计算机数据传输的效率

• 数据流：Http/2的数据包不是按顺序发送，每个请求或回应的所有数据包称为一个数据流，规定客户端发出的数据流编号为奇数，服务器发送的数据流编号为偶数，客户端还可以指定数据流的优先级

• 多路复用：Http2不用再按照顺序一一对应TCP请求，可以并发多个请求或者回应，移除了Http1.1中的串行请求，不会再出现队头阻塞，大幅度提高了连接的利用率

• 服务器推送：服务不再是被动响应，也可以主动向客户端发送消息，例如：在浏览器刚刚请求Html的时候就提前把可能会用到的JS、CSS文件主动发送给客户端，减少延时等待

Http2的缺点

多个Http请求复用在一个TCP，下层TCP协议不知道有多少个HTTP请求，一旦丢包，触发TCP重传机制，这样在一个TCP连接中所有的HTTP请求都必须等待这个丢了的包被重传回来

Http3

队头阻塞，多路复用的问题都是基于TCP传输层的问题，所以HTTP/3把HTTP下层的TCP协议改成了UDP

• UDP发生不管顺序不管丢包

Http和Https的区别

• Http采用明文传输报文，Https加密传输（通过SSL）

• Http端口号是80，Https是443

• Https需要验证数字证书

• Https比Http多了一个SSL协议

Https握手

TLS第一次握手

客户端发送一个Client Hello消息，消息里有客户端使用的TLS版本号、支持的密码套件列表、以及生成的随机数（用于生成对称加密密钥）

TLS第二次握手

服务端收到Client Hello消息 确认TLS版本号是否支持，从密码套件列表中选择一个密码套件、生成一个随机数，返回Server Hello消息。消息里有服务器确认的TLS版本号，随机数，合适的密码套件。至此客户端和服务端就已确认了TLS版本和使用的密码套件，你会发现双方都有一个随机数并传递给了对方，随机数主要是为了后续生成会话密钥，然后服务端为了证明自己的身份会发送Server Certificate给客户端，这个消息里含有数字证书，随后服务端发了Server Hello Done 消息，表示本次打招呼完毕

TLS第三次握手

客户端验证完证书后，认为可信则继续往下走，接着客户端会生成一个新的随机数，用服务器的RSA公钥加密该随机数，通过Change Cipher Key Exchange消息传给服务端，服务端收到后用RSA私钥解密，得到客户端发来的随机数

至此，客户端和服务端双方都共享了三个随机数

于是双方根据已得到的随机数生成会话密钥，用于对称加密，用于对后续HTTP请求的数据加密，生成会话密钥后，客户端发送一个Change Cipher Spec，告诉服务端开始使用加密方式发送消息，然后客户端再发一个Encrypted Handshake Message消息，把之前发送的所有数据做个摘要，再用会话密钥加密一下让服务器做个验证，验证加密信息是否可用和之前握手信息是否被冲突篡改过。Change Cipher Spec 消息之前传输的都是明文，之后都是对称加密的密文

TLS第四次握手

服务器也是同样的操作，发Change Cipeher Spec 和 Encrypted Handshake Message 消息 如果双方都验证加密和解密没问题，那么握手正式完成，最后就用会话密钥加解密HTTP请求和响应了。

Https如何优化？

• 硬件优化，HTTPS协议是计算密集型，而不是I/O密集型，所以不能把钱花在网卡、硬盘上，而是CPU上

• 软件优化：软件升级、协议优化（用ECDHE密钥交换算法替换RSA）

• TLS升级（TLS1.2升级为1.3，大幅度简化了握手步骤）

• 证书优化、减少证书大小（选择ECDSA证书比RSA证书短）