HTTP、HTTPS详解

介绍

超文本传输协议HTTP（HyperText Transfer Protocol）是一个应用层的协议，它使用TCP连接进行可靠的传送。是用于从万维网（WWW:World Wide Web ）服务器传输超文本到本地浏览器的传送协议。HTTP协议工作于客户端-服务端架构之上。浏览器作为HTTP客户端通过URL向HTTP服务端即WEB服务器发送所有请求。Web服务器根据接收到的请求后，向客户端发送响应信息。HTTP的URL一般形式是 http://<主机>:<端口>/<路径>，HTTP默认端口是80。

特点

• 支持客户端/服务器模式：客户端（浏览器）通过URL向服务器发送请求，服务器收到后处理请求，向客户端传送响应信息。
• 简单快速：浏览器只需要向服务器发送请求路径和请求方法即可
• 灵活：允许传输任意类型的数据，文本、图片、音频、视频等
• 无连接：每次连接只处理一个请求，服务器处理完请求，响应客户端并收到确认后就断开连接。从HTTP/1.1开始，默认使用长连接，即服务器处理完请求后还需等待一段时间才断开，该时间内可以继续接受请求。
• 无状态：协议对请求处理没有记忆，后续请求如需前面请求的信息，则需要重传。

版本

• HTTP/0.9：是第一个版本的HTTP协议，已过时。它的组成极其简单，只允许客户端发送GET这一种请求，且不支持请求头。由于没有协议头，造成了HTTP/0.9协议只支持一种内容，即纯文本。
• HTTP/1.0：这是第一个在通讯中指定版本号的HTTP协议版本，至今仍被广泛采用，特别是在代理服务器中。
• HTTP/1.1：长连接被默认采用，并能很好地配合代理服务器工作。还支持以管道方式同时发送多个请求，以便降低线路负载，提高传输速度。该版本是目前主流版本，也是本文讲解的版本。
  HTTP/1.1相较于HTTP/1.0协议的区别主要体现在：
  1. 缓存处理
  2. 带宽优化及网络连接的使用
  3. 错误通知的管理
  4. 消息在网络中的发送
  5. 互联网地址的维护
  6. 安全性及完整性
• HTTP/2.0：于2015年5月作为互联网标准正式发布。

报文结构

HTTP有两类报文：

• 请求报文，从浏览器向服务器发送的报文。
• 响应报文，从服务器到浏览器的回答。

请求报文一般格式如下：

GET / HTTP/1.1
Host: www.baidu.com
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.80 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, br
Accept-Language: zh-CN,zh;q=0.9,en-US;q=0.8,en;q=0.7

请求头	含义
请求方法	GET、PUT、POST、DELETE、OPTIONS、HEAD、TRACE
Host	接受请求的服务器地址，可以是ip:port，也可以是域名
Connection	连接类型，通常是close或keep-alive
User-Agent	用来让服务器来识别发起请求的用户代理软件的应用类型、操作系统、软件开发商以及版本号。
Accept	用来告知服务器，当前客户端可以处理的内容类型
Accept-Encoding	通知服务端可以发送的数据压缩格式
Accept-Language	通知服务端可以发送的语言

响应报文一般格式如下：

HTTP/1.1 200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html
Content-Length: 28

请求头	含义
状态码	200代表请求成功。状态码格式：1xx、2xx、3xx、4xx、5xx
Connection	连接类型，通常是close或keep-alive
Content-Encoding	响应正文使用的数据压缩格式
Content-Type	响应类型，常见的有：text/html、text/css、image/jpeg、image/png、application/json等
Content-Length	响应正文长度

执行过程

用户在浏览器地址栏输入正确的URL，并且敲击回车后。一次完整的HTTP请求包含如下过程：

1. DNS解析：浏览器查询DNS缓存（浏览器缓存->系统缓存->路由器缓存->IPS缓存->根域名服务器缓存->顶级域名服务器缓存），获取URL所对应的IP地址
2. 建立TCP连接：根据DNS返回的IP和端口建立TCP连接
3. 发送HTTP请求
4. 服务器处理请求并返回HTTP响应报文
5. 关闭TCP连接
6. 浏览器解析渲染页面

GET请求和POST请求的区别

• GET请求参数直接拼在URL后面，并显示在浏览器地址栏，URL长度会有限制，此限制来自Chrome、Firefox等浏览器，而非HTTP协议本身。POST请求参数在报文体中，所以POST请求安全性稍高一些

• GET请求具有幂等性和安全性，POST不具有。在HTTP/1.1规范中幂等性的定义是：

  Methods can also have the property of “idempotence” in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request.

  意思是一次和多次请求某一个资源应该具有同样的副作用，而安全性是指GET请求不会破坏数据库中的数据。

• GET请求可以被缓存（浏览器、CDN等），而POST请求不能。

响应状态码

HTTP响应状态码都是三位数字的，分为5类共33种：

• 1xx：表示通知信息，如请求收到了，或正在执行
• 2xx：表示成功
• 3xx：表示重定向，如要完成请求还必须采取进一步的行动
• 4xx：表示客户端的差错，如请求中有错误的语法或不能完成
• 5xx：表示服务器的差错，如服务器失效或者无法完成请求

无状态协议

HTTP协议是无状态的（stateless）。也就是说，同一个客户端第二次访问同一个服务器上的页面时，服务器响应与第一次被访问时相同（如果服务器尚未更新该页面），因为服务器并不知道这个客户端是否访问过自己，也不知道访问过几次。HTTP无状态特性简化了服务器的设计，使服务器更容易支持大量并发的HTTP请求。
这样做虽然简化了服务器的设计，但在实际工作中，一些站点却常常希望能够识别用户。例如网上购物，一个顾客要购买多种物品。当他把选好的物品加入购物车后，又要去浏览其他商品。因此网站需要识别该用户，使该用户后续选购的商品能够加入同一个“购物车”，这样便于集中结账。要做到这点，可以使用Cookie来跟踪用户。用于HTTP服务器和客户端之间传递状态信息。其工作原理如下：

• 客户端访问支持Cookie的网站，提交用户名，密码等能验证身份的信息
• 服务器在响应头中回复Set-Cookie字段，以文本文件的形式保存在客户端（浏览器）
• 客户端以后的请求都会在请求头中带上Cookie字段
• 服务器识别身份，作出响应

总之Cookie是服务器根据用户提交的身份信息，生成唯一的识别码，并且以文本文件的形式存储在客户端的。

服务器为了维护用户状态，还用到了另一种机制：Session（会话）。Session 对象存储特定用户会话所需的属性及配置信息。这样，当用户在应用程序的 Web 页之间跳转时，存储在 Session 对象中的变量将不会丢失，而是在整个用户会话中一直存在下去。当用户请求来自应用程序的 Web 页时，如果该用户还没有会话，则 Web 服务器将自动创建一个 Session 对象。当会话过期或被放弃后，服务器将终止该会话。Session的实现方式主要有两种：

• 使用Cookie来实现
  
  服务器根据用户提交的身份验证信息，生成一个session id，然后以Set-Cookie的形式返回给客户端，客户端每次请求都带上session id，服务器就可以识别用户身份，维护会话状态。
• 使用URL回写，是指浏览器发送给客户端的所有URL后面，加上JSESSIONID这个参数，如果不加则无法验证用户身份。

两种方式都离不开JSESSIONID（不同语境下这个参数名不同，Java叫JSESSIONID，PHP叫PHPSESSIONID…），一种是放在请求头中传递，一种是以参数形式传递。由于Cookie属于浏览器实现，Session由服务器维护，所以常说Cookie存在浏览器，Session存在服务端。

HTTPS

HTTPS（HyperText Transfer Protocol Secure）超文本传输安全协议，默认端口443。HTTPS经由HTTP进行通信，但利用SSL/TLS来加密数据包。HTTPS开发的主要目的，是提供对网站服务器的身份认证，保护交换数据的隐私与完整性。

SSL（Secure Sockets Layer）安全套接层，为网络通信提供安全以及数据完整性的一种安全协议，3.0后的版本改名为TLS（Transport Layer Security）传输层安全协议，主要采用身份认证和数据加密等手段来保证传输安全。其数据传输流程如下：

• 浏览器向服务器发送加密通信的请求（Client Hello），请求中包含如下内容：
  1. 支持的SSL/TLS版本
  2. 支持的加密算法
  3. 一个随机数(RNc=Random Number of Client）
  4. 支持的压缩算法
• 服务器收到请求后响应（Server Hello）如下信息：
  1. 确认使用的SSL/TLS版本，如果服务器和浏览器支持的版本不一致，服务器关闭加密通道
  2. 确认使用的加密算法
  3. 一个随机数(RNs=Random Number of Server)
  4. 服务器证书
• 浏览器收到证书
  1. 校验证书的合法性，证书是否受到信任会在浏览器地址栏标识出来。
  2. 生成一个随机数pre-master secret，并用证书中的服务器的公钥加密，发送给服务器。
• 服务器收到数据后，使用自己的私钥解密。此时浏览器和服务器都拥有了三个随机数RNc、RNs和pre-master secret，双方通过这三个随机数生成一致的对称加密使用的秘钥。

以上是TCP三次握手 + SSL/TLS四次握手过程。
下面结合Wireshark（win64下载地址：Wireshark-win64-2.6.6.exe）来具体看看握手过程：
看第一列序号，23、26、27分别是TCP三次握手过程。31是TLS第一次握手，33,34,35是TLS第二次握手，这次握手的数据分一次传输还是多次传输，不同的服务器有不同的实现。37、45分别TLS是第三、四次握手。接下来具体看看每次握手传输具体信息。

• 第一次握手（Client Hello）
  

• 第二次握手（Server Hello）
  

• 第三次握手
  
  Change Cipher Spec：表示自己已经生成了新的秘钥，并且告知对方，以后就用新的秘钥通信。
  Encrypted Handshake Message： 用新秘钥加密规定好的测试信息传输给对方，用于验证双方新的秘钥是否一致。

• 第四次握手
  
  Change Cipher Spec：表示自己已经生成了新的秘钥，并且告知对方，以后就用新的秘钥通信。
  Encrypted Handshake Message： 用新秘钥加密规定好的测试信息传输给对方，用于验证双方新的秘钥是否一致。
  New Session Ticket：用于刚刚建立的会话，在接下来的一段时间，双方都以刚刚交换的秘钥进行通信。

总结：运行在SSL/TLS上的HTTP就是HTTPS。