HTTP与HTTPS详解

一、HTTP的概念

HTTP是超文本传输协议，是一种应用层协议，是基于为浏览器/服务器间提供统一的信息交换格式而出现的，其发展历程为HTTP/1.0、HTTP/1.1、HTTP/2、HTTP/3。

HTTP版本区别

• HTTP/1.0：HTTP/1.0为短连接，即客户端单次请求后就关闭TCP连接。这样效率显然是很低的
• HTTP/1.1：HTTP/1.1默认为长连接，提升了连接的利用率，可用报文中Connecton字段控制的，取值Keep-Alive 为长连接（默认），取值Close 表示关闭长连接。并且引入了管道化技术，发送请求后不必等待响应就可以继续发送下一个请求，但是由于性能原因很少被支持。
• HTTP/2：HTTP/1为半双工，只能由客户端向服务端发送请求，服务端再响应请求。并且HTTP/1.1存在应用层队头阻塞和报文头部信息重复传输的问题。HTTP/2引入了全双工，服务端也可主动发送数据。并且HTTP/2通过将报文分帧传输的方式，实现了连接的多路复用，解决了应用层面的队头阻塞问题。此外，HTTP/2通过HPACK算法对HTTP报文头部进行了压缩，提升了传输效率
• HTTP/3：在HTTP/3之前，HTTP都是基于TCP传输的。HTTP/3基于UDP传输

二、HTTP报文格式 

1. 请求报文

请求报文为主动发送一个http请求的报文，格式说明：

• 请求行(request line)：包括请求方法，资源的URL，以及HTTP协议版本。
• 请求头(header)：包括请求服务器所需要的附加信息。
• 空行(CRLF)：请求头部后面必须是空行,即使请求数据为空,也要有空行。
• 请求数据(body)：也称为请求体，可以添加任意类型的数据，通过请求头中的Content-Length字段确定请求数据的长度。

（1）GET请求报文 

根据RFC规范，GET 的语义是从服务器获取指定的资源。GET请求一般不携带请求体，如果有请求参数则放在URL后面，一个GET请求报文的样例如下:

GET /video1?p=2 HTTP/1.1  # 请求行：GET请求方式 请求资源路径 HTTP协议版本
Host: www.bilibili.com  # 服务器的主机地址和端口号,默认是80
Connection: keep-alive # 和服务端保持长连接
Upgrade-Insecure-Requests: 1 # 让浏览器升级不安全请求，使用https请求
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36  # 用户代理，也就是客户端的名称
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8 # 可接受的数据类型
Accept-Encoding: gzip, deflate # 可接受的压缩格式
Accept-Language: zh-CN,zh;q=0.9 #可接受的语言
Cookie: pgv_pvi=1246921728; # 登录用户的身份标识
---- 空行 ----

 （2）POST请求报文

根据 RFC 规范，POST 的语义是根据请求体（报文body）对指定的资源请求做出处理。一般提交表单时就会使用POST请求，例如登录，一个POST请求报文的样例如下:

POST /login HTTP/1.1 # 请求行：POST请求方式 请求资源路径 HTTP协议版本
Host: www.bilibili.com # 服务器的主机地址和端口号,默认是80
Connection: keep-alive # 和服务端保持长连接
Content-Type: application/json;charset=utf-8  # 请求体的数据类型
Content-Length：32 # 请求体的数据长度
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36 # 客户端的名称
---- 空行 ----
{username:hello,pass:123456} # 请求体

2. 响应报文 

响应报文为响应一个http请求的报文，格式说明：

• 状态行(status line): 包括HTTP协议版本，状态码和状态消息
• 消息报头(header): 包括返回客户端的一些附加信息
• 空行(CRLF): 必须有空行
• 响应正文(body): 服务器返回给客户端的数据,可以是任意类型的数据

响应报文样例：

 

3.HTTP常见响应状态码 

三、HTTP 与 HTTPS的区别 

• HTTP是明文传输，HTTPS比HTTP多一层SSL/TLS 安全协议，在TCP的三次握手之后，还需进行TLS握手，握手成功后通过秘钥对整个HTTP报文通过对称加密进行密文传输通信。
• HTTP 默认端口号是 80，HTTPS 默认端口号是 443。

SSL/TLS 协议基本流程：

• 客户端向服务器索要并验证服务器的公钥。
• 双方协商生产「会话秘钥」。
• 双方采用「会话秘钥」进行加密通信。

基于RSA的TLS握手机制

（1）第一次握手：客户端首先会发一个「Client Hello」消息，其中包括客户端使用的 TLS 版本号、支持的密码套件列表、以及生成的第一个随机数（Client Random）。

（2）第二次握手：当服务端收到客户端的「Client Hello」消息后，会确认 TLS 版本号是否支持，和从密码套件列表中选择一个密码套件，以及生成第二个随机数（Server Random）。接着返回「Server Hello」消息，其中包括确认 的TLS 版本号、选择的密码套件、Server Random。然后，服务端为了证明自己的身份，会发送「Server Certificate」给客户端，这个消息里含有数字证书。随后，服务端发了「Server Hello Done」消息，目的是告诉客户端，我已经把该给你的东西都给你了，第二次握手完毕。

（3）第三次握手：客户端首先对证书进行验证，认为可信则继续往下走。接着客户端就会生成第三个随机数 (pre-master)，用服务器公钥加密后传给服务端。然后客户端用这三个随机数生成一个会话秘钥，用于后续通信的对称加密。生成完「会话密钥」后，然后客户端发一个「Change Cipher Spec」，告诉服务端开始使用加密方式发送消息。然后，客户端再发一个「Encrypted Handshake Message（Finished）」消息，把之前所有发送的数据做个摘要，再用会话密钥（master secret）加密一下，让服务器做个验证，验证加密通信「是否可用」和「之前握手信息是否有被中途篡改过」。

（4）第四次握手：服务端收到加密后的第三个随机数 (pre-master)后，用服务端私钥进行解密，然后进行与客户端同样的操作：用这三个随机数生成同样的会话秘钥、发送「Change Cipher Spec」、发送会话秘钥加密后的摘要信息「Encrypted Handshake Message（Finished）」。验证过摘要信息之后客户端和服务端就可以开始用会话秘钥加密通信了。