HTTP 和 HTTPS 其实我一直很模糊

ゝ一世哀愁。 2021-10-09 09:38 287阅读 0赞

### **HTTP 和 HTTPS 其实我们一直很模糊** ###

1.如题，在这种信息数据量大爆炸的时代，我们每一个人在网络上冲浪，来回穿梭。

那如果有人告诉你：你相当于在裸奔？你会怎么对待这件事情呢？

一种做法，拒绝使用互联网，拒绝在网络上进行任何会使用到我们信息的场景（基本不可能，数据时代，有数据建模，人物画像...）；逃避任何的信息录入方式。

一种做法，继续使用，但是你必须得给我保证，我是安全独立的在使用，而不是公开透明。那么这就得说到我们的安全协议了。

2.笔者很苦恼，为什么，我自己搭建的网站，注册的域名，使用了正规的域名解析，并且域名信息备案通过了网络部的认证。在使用谷歌浏览器的时候，他硬生生的给我贴上了一个“不安全”的标签！！！![20210221151454537.png][]

你说这气人不气人？

对比一下其他网站，我们看看

百度的就没有。![20210221151509967.png][]

淘宝也没有。![2021022115151470.png][]

什么意思？google挑软柿子捏？这可不行。

我们点击不安全这个标签，会弹出如下的弹窗。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjIzNjg4_size_16_color_FFFFFF_t_70][]

他警示我们：我作为用户和这个网站建立的连接是不安全的；为啥不安全呢？我们看看详情；（他这还把我在这个网站平台使用的Cookie都显示出来了。）

他会跳转至这个地址：[https://support.google.com/chrome/?p=ui\_security\_indicator][https_support.google.com_chrome_p_ui_security_indicator]

一个外网地址，我们打开科学上网软件就可以访问了；

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjIzNjg4_size_16_color_FFFFFF_t_70 1][]

其中最为关键一句话：

>     当您访问使用 HTTPS（连接安全）的网站时，该网站的服务器会使用证书向浏览器（如 Chrome）证明该网站的身份。任何人都可以创建证书，随意声称对应的网站是任意网站。
>     
>     为了确保您安全上网，Chrome 会要求网站使用来自受信任组织发放的证书。

这么理解：也就是说，当我们访问的网站是通过Https协议建立连接的网站的时候，可以理解为这个连接是安全的，这个网站的服务器会使用证书向浏览器证明“我这个服务器就是官方指定的服务器”，你现在是和一个官方的人在通信。

那么对于chrome就启动了这个要求，当任何一个网站和我们浏览器的用户建立连接的时候，你必须提供一个“受信任组织”发放出来的证书，否则我将一直提醒浏览器，你这个网站不安全；那么不安全的网站使用的连接协议一般都是http协议。

（协议可以理解为一种约定规则，那么本质我们的服务器上也是计算机，我们所谓的浏览网页只不过是计算机之间的一种通信，数据交互，那么要想在安全有效的建立交互，那么就得有约定）

所以我们对比上方几个网站的连接地址，可以发现，我的网站是http://的，其他都是https://的。

### 3.http ###

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

超文本传输协议，属于七层ISO模型中的顶层“应用层”上的协议；用于服务器向浏览器传输html等数据的传送协议；

那么http传输协议的原理到底是什么嗯？

上面也说到了Http是基于Tcp/Ip通信协议的一种传输数据的协议，那主要的数据就是我们常见的web界面中的Html文件、图片文件、css、js等文件了，然后对于一些json数据也有。通常用于我们的web项目中，也就是我们常见的B/S架构模型。客户端一般都是浏览器，浏览器通过请求url地址，想服务器发送请求，然后返回对应的响应信息；

这里说不定有同学就问了：我现在正在学习http协议，怎么又冒出来TCP协议和IP协议了。

我们都知道，在七层ISO模型中，有其他层，对于HTTP协议，他的作用范围是顶层，也就是应用层，主要功能就是控制应用之间的协议约束。

对于其中的TCP协议，那么就是建立在传输层上的协议了，解决的问题就是，如果在IP层上如何可靠的传输我们的数据包文件，就是在端对端之间有效，顺序，传输这些一个个数据包，完成整个连接过程的数据传输。自然传输html等数据的http协议就得基于这个基础上进行实现了。

那么还有IP协议，这个是网络层的协议。我们在网络中实现网络之间的通信，怎么保证A计算机能在网络中找到B计算机呢？这是一个很关键的节点，那么这个就需要IP协议来支撑了，由IP协议来维护网络之间的寻址，路由问题。

举个例子吧：以一个获取我们网页的页面的接口为例。

例如我现在想打开我的网站的登录首页

第一步：先在浏览器中输入网站的域名地址，在然后后面在加上对于的uri地址；点击回车，浏览器就会帮我们发送请求到服务器中； 浏览器访问的是域名，那么先会访问的域名解析的对应的IP及端口；这样就会访问到我们的对应的节点上了。（此处省略负载均衡等技术）

第二步：客户端会发起一个TCP请求，建立通信链接（此处称之为3次握手）

第三步：当建立通信连接成功后，再发送对应的HTTP请求

第四步：服务端返回对应的资源文件或者json字符。

这就是我们整个http请求的流程概要。我们可以通过一个图进行描述

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjIzNjg4_size_16_color_FFFFFF_t_70 2][]

那么http协议而言，有什么优势和特点呢？

（1）http是无状态的，也就是在事务处理方面没有记忆性的，前后无联系；

（2）http是无连接方式的，就好比同一个浏览器向同一个浏览器发起的两个请求。这两个请求是没有关系的，也就是说，当第一个请求建立的连接，在第一个请求执行完成后，那么就会释放连接。第二个请求需要重新建立起一个新的连接。这种问题就会对请求数据方式产生一定影响，那么如何解决这种影响，就有了浏览器本地数据记录，和服务器会话建立，也就是cookie和session；怎么举例呢？当我们在网页上登录了一个账号，那我们关闭了当前网页，那么是不是就登录信息失效了？又重新需要登录呢？这显然是不合理的。那么就有了本地缓存和服务器会话。

（3）传输类型修改灵活，当我们传输不同的数据类型的时候，只需要对应的content-type传输不同的数据格式。

（4）请求便捷，只需要定义对应的url地址，以及对应的请求方法，就可以完成服务器通信。

那么再给各位大佬抓个包，给大家看看，一个http请求，所发送的内容都是什么吧。

![2021022115160342.png][]

其中的请求方法，请求地址，以及对应的请求协议http/1.1

然后就是一些请求头信息了。例如主机、连接类型、客户端类型信息啊，很多。

我们可以将一个报文的请求信息大致分为三个部分：

请求行：

>     GET http://changemax.cn/admin/login/page HTTP/1.1

请求头：

>     Host: changemax.cn
>     Connection: keep-alive
>     Upgrade-Insecure-Requests: 1
>     User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.96 Safari/537.36
>     Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
>     Referer: http://changemax.cn/admin/page
>     Accept-Encoding: gzip, deflate
>     Accept-Language: zh-CN,zh;q=0.9
>     Cookie: UM_distinctid=1773299224f868-0faca6a16e0924-31346d-144000-177329922506f7; JSESSIONID=hOpOvzmLh-GEdZbSbvPt9iFcIpxeJxeoB4_H1zcJ; CNZZDATA1279397328=2062894055-1611461630-%7C1613884903

请求体：

（注意，我这个是GET请求方式，是没有body的）

那么响应报文的组成呢？截图先：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjIzNjg4_size_16_color_FFFFFF_t_70 3][]

也可以分为三部分：

状态行：通常标识当前请求的响应状态 http status code == 200 即为成功

>     HTTP/1.1 200 OK

响应头：同请求头原理，在于一些服务器信息、服务器时间、服务器语言、编码等等也会将其放在响应头中。

>     Server: nginx/1.17.1
>     Date: Sun, 21 Feb 2021 05:58:54 GMT
>     Content-Type: text/html;charset=UTF-8
>     Transfer-Encoding: chunked
>     Connection: keep-alive
>     Content-Language: zh-CN

响应体：这个就是响应内容的主体的，笔者这个请求就是一个html文本内容。

> <!DOCTYPE html>  
> <html lang="en">  
>   
> <head>  
>     <meta content="width=device-width, initial-scale=1, maximum-scale=1" name="viewport"/>  
>     <meta charset="utf-8">  
>     <meta content="第二颗大白菜keywords" name="keywords">  
>     <meta content="第二颗大白菜desc" name="description">  
>     <meta content="Second chinese cabbage" name="author">  
>     <meta content="webkit" name="renderer">  
>     <meta content="IE=edge,chrome=1" http-equiv="X-UA-Compatible">  
>     <meta content="width=device-width, initial-scale=1.0, minimum-scale=1.0, maximum-scale=1.0, user-scalable=0"  
>           name="viewport">  
> .............

### 4.说了这么就的http，那得说说https吧 ###

这两者我们可以看到多了一个s，所以笔者把他定义为是增强版的http，也就是说他解决了一些http会出现的问题；

那么是什么问题呢？

可以看到，笔者为了给大家演示http请求中报文的组成，直接通过Fidder进行请求抓包就可以明文式的浏览用户的请求内容。假设用户涉及到一些敏感性的操作，那么这个时候就很不安全了。并且对于抓包这个角度，我们可以对浏览器发起的报文进行拦截，二次修改，然后再次发送，这种情况下，显然是极度不安全的做法。

那么在http的网络请求协议中；请求信息都是明文发送、数据完整性都不会校验，容易被修改、且对于服务器的身份也没进行认证。这些问题都会引起信息安全的问题；

那么这个时候就是HTTPS的出现了。

国际惯例，先贴百科

>     HTTPS （全称：Hyper Text Transfer Protocol over SecureSocket Layer），是以安全为目标的 HTTP 通道，在HTTP的基础上通过传输加密和身份认证保证了传输过程的安全性 [1]  。HTTPS 在HTTP 的基础下加入SSL，HTTPS 的安全基础是 SSL，因此加密的详细内容就需要 SSL。 HTTPS 存在不同于 HTTP 的默认端口及一个加密/身份验证层（在 HTTP与 TCP 之间）。这个系统提供了身份验证与加密通讯方法。它被广泛用于万维网上安全敏感的通讯，例如交易支付等方面

上文中很清晰的说到一个关键字SSL；

也就是说HTTPS在HTTP的基础上，增加了安全性的功能，主要体现是，通过信息加密，以及身份认证实现；那么我们细细分析；

>     SSL(Secure Sockets Layer 安全套接字协议),及其继任者传输层安全（Transport Layer Security，TLS）是为网络通信提供安全及数据完整性的一种安全协议。TLS与SSL在传输层与应用层之间对网络连接进行加密。

又是一种协议栈，我们先不深入；

那么上图中，我们画了一个http的请求流程，那么https的也要有一个；（此处我们采用时序图来表示浏览器与服务器间的交互先后）

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjIzNjg4_size_16_color_FFFFFF_t_70 4][]

网络上其实也有类似的执行流程图，大同小异。

我们一步一步分析一下上图所描述的整个流程：

**（1）浏览器发起https请求，请求到服务器。**

**（2）服务器此刻会存在一个私钥和密钥，可以理解为数字签名。我们都都知道，公钥一般都是对外公开的。产生的方式，通常都是向证书管理组织申请，这种申请过来的数字证书可以方便我们验证过程。私钥和密钥的关系，在很多加密算法中也有提到，就是两个字符串，可以通过字符串A加密的数据，可以通过字符串B进行解密。**

**（3）那么服务器就会将事先准备好的公钥发送给浏览器了。**

**（4）浏览器这个时候，收到了服务器公钥，那么就需要验证一下当前和他进行交互的服务器是不是合法的，是不是对应的。那么就进行解析数字签名：数字签名，顾名思义，是一种签名，你签的，就可以知道是你，但是也有高仿的，但是逃不过认证组织的鉴定，我们可以从中获取到当前签名的合法性，有效性。**

**（5）当上一步数字签名验证通过后，浏览器就会生成一个随机数（客户端私钥）。我们上面说到，公钥通常是传递，公开，但是私钥不公开。那么这个浏览器传递的私钥为什么就发出去了呢？被别人拦截了咋办？是的，那么我们就不能明文公开了，这个时候，我们需要使用到服务器的公钥了。使用服务器公钥对客户端私钥进行加密，那这个客户端私钥加密后的文本只能服务器通过对应的私钥进行解密了。**

**（6）我们对上一步准备好的“加密后的私钥”进行传递，将其发送给服务器。**

**（7）服务器收到了这个“加密后的私钥”，然后使用自己的私钥对其进行解密操作，然后就会获取到“浏览器产生的私钥”**

**（8）这个时候浏览器向服务器发送的任何请求，都是通过自己的私钥进行对称加密，然后再发送给服务器。**

**（9）然后服务器使用第7步骤中获取的“浏览器私钥”进行解密操作，就可以获取到真实的请求体内容了。**

**（10）然后服务器对浏览器响应的响应体中，再用“浏览器私钥”进行加密操作，然后将其响应给“浏览器”**

**（11）浏览器就可以对“加密后的响应体”进行解密了。就可以获取到真实的响应内容了。**

上述流程，在其中7/8部分，我将其分为两步，在某些描述中，可能会合并，但是这都不重要，我们目的是了解其中的加密方式。

所以总结下来，服务器的公钥私钥作用本质上不是用于报文的加密，而是为了让服务器知道当前浏览器的加密私钥是什么。而传输报文的时候，采用的加密解密，都是通过浏览器随机产生的字符串进行加密解密的。

我们看看抓包中，https协议的显示情况

直接乱码

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjIzNjg4_size_16_color_FFFFFF_t_70 5][]

分析了上述流程，我们可以清晰的看到https的整个建立连接通信的过程，是不断的通过加密，解密方式去通信的，且还存在签名认证的过程。这种无异于是很安全的通信协议。

但是我们通过上述的流程的描述对比HTTP的流程的描述，可以知道，https做了很多次握手，大大降低了数据传递的效率。并且对于数字签名认证也是存在商用消耗的。且在我们进行加密解密过程也是一种资源的消耗，其中涉及的SSL协议中的算法资源消耗。

所以在某些安全前提下，我们大可不考虑https，只需要考虑http了。（内网，分布式环境，节点通信就是http）

**5.对于两者通信协议，我们需要做一个总结：**

**其中还是我的一句话：HTTPS是HTTP协议的增强版。**

**在HTTP的基础上，HTTPS考虑了安全性方面的问题，解决了我们在网上冲浪过程中的信息截取，或者服务冒充等问题。HTTPS使用的是SSL/TLS等协议进行的加密处理。**

**两种协议的连接方式过程都不一样，相对而言，http简单高效，但是没有https的安全。对于其两种协议的端口也是不一样的，http：80；https：443；**

**在现在的互联网情况下，基本上的都是基于HTTPS协议作为通信，且IOS开发严格要求服务器协议是HTTPS的（apple用心良苦）**

[20210221151454537.png]: /images/20211009/708b2214bad8493ca2dc3dddb865940d.png
[20210221151509967.png]: /images/20211009/90fdce69dd0443c0b7736b356cd1b748.png
[2021022115151470.png]: /images/20211009/a1872757ba5e4862beec218dc3fb6c9f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjIzNjg4_size_16_color_FFFFFF_t_70]: /images/20211009/865e2b5c875c4757aeb987d388f6f361.png
[https_support.google.com_chrome_p_ui_security_indicator]: https://support.google.com/chrome/?p=ui_security_indicator
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjIzNjg4_size_16_color_FFFFFF_t_70 1]: /images/20211009/543bcbf483444b5e9e0df2af08c93b68.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjIzNjg4_size_16_color_FFFFFF_t_70 2]: /images/20211009/1fef8367bdb9432dad9407a23045320e.png
[2021022115160342.png]: /images/20211009/f38aafecf4454bb480d86fbc8789f978.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjIzNjg4_size_16_color_FFFFFF_t_70 3]: /images/20211009/9f3ada56fe7c4535a0d936b664b4110f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjIzNjg4_size_16_color_FFFFFF_t_70 4]: /images/20211009/e3ee8982aad94dc58edcf0adfcb5551c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjIzNjg4_size_16_color_FFFFFF_t_70 5]: /images/20211009/44f37350064a42829a9b9711e4c3d972.png