1. HTTP 协议

在谈论 HTTPS 协议之前，先来回顾一下 HTTP 协议的概念。

1.1 HTTP 协议介绍

HTTP 协议是一种基于文本的传输协议，它位于 OSI 网络模型中的应用层。

HTTP 协议是通过客户端和服务器的请求应答来进行通讯，目前协议由之前的 RFC 2616 拆分成立六个单独的协议说明（RFC 7230、RFC 7231、RFC 7232、RFC 7233、RFC 7234、RFC 7235），通讯报文如下：

请求

POST http://www.baidu.com HTTP/1.1
Host: www.baidu.com
Connection: keep-alive
Content-Length: 7
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36

wd=HTTP

响应

HTTP/1.1 200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html;charset=utf-8
Date: Thu, 14 Feb 2019 07:23:49 GMT
Transfer-Encoding: chunked

<html>...</html>

1.2 HTTP 中间人攻击

HTTP 协议使用起来确实非常的方便，但是它存在一个致命的缺点：不安全。如果您正在学习Spring Boot，那么推荐一个连载多年还在继续更新的免费教程：http://blog.didispace.com/spring-boot-learning-2x/

我们知道 HTTP 协议中的报文都是以明文的方式进行传输，不做任何加密，这样会导致什么问题呢？下面来举个例子：

小明在 JAVA 贴吧发帖，内容为我爱JAVA：

被中间人进行攻击，内容修改为我爱PHP

小明被群嘲(手动狗头)

可以看到在 HTTP 传输过程中，中间人能看到并且修改 HTTP 通讯中所有的请和响应内容，所以使用 HTTP 是非常的不安全的。

1.3 防止中间人攻击

这个时候可能就有人想到了，既然内容是明文那我使用对称加密的方式将报文加密这样中间人不就看不到明文了吗，于是如下改造：

双方约定加密方式

使用 AES 加密报文

这样看似中间人获取不到明文信息了，但其实在通讯过程中还是会以明文的方式暴露加密方式和秘钥，如果第一次通信被拦截到了，那么秘钥就会泄露给中间人，中间人仍然可以解密后续的通信：

那么对于这种情况，我们肯定就会考虑能不能将秘钥进行加密不让中间人看到呢？答案是有的，采用非对称加密，我们可以通过 RSA 算法来实现。最近整理了一份最新的面试资料，里面收录了2021年各个大厂的面试题，打算跳槽的小伙伴不要错过，点击领取吧！

在约定加密方式的时候由服务器生成一对公私钥，服务器将公钥返回给客户端，客户端本地生成一串秘钥(AES_KEY)用于对称加密，并通过服务器发送的公钥进行加密得到(AES_KEY_SECRET)，之后返回给服务端，服务端通过私钥将客户端发送的AES_KEY_SECRET进行解密得到AEK_KEY,最后客户端和服务器通过AEK_KEY进行报文的加密通讯，改造如下：

可以看到这种情况下中间人是窃取不到用于AES加密的秘钥，所以对于后续的通讯是肯定无法进行解密了，那么这样做就是绝对安全了吗？

所谓道高一尺魔高一丈，中间人为了对应这种加密方法又想出了一个新的破解方案，既然拿不到AES_KEY，那我就把自己模拟成一个客户端和服务器端的结合体，在用户->中间人的过程中中间人模拟服务器的行为，这样可以拿到用户请求的明文，在中间人->服务器的过程中中间人模拟客户端行为，这样可以拿到服务器响应的明文，以此来进行中间人攻击：

这一次通信再次被中间人截获，中间人自己也伪造了一对公私钥，并将公钥发送给用户以此来窃取客户端生成的AES_KEY，在拿到AES_KEY之后就能轻松的进行解密了。

中间人这样为所欲为，就没有办法制裁下吗，当然有啊，接下来我们看看 HTTPS 是怎么解决通讯安全问题的。

2. HTTPS 协议

2.1 HTTPS 简介

HTTPS 其实是SSL+HTTP的简称,当然现在SSL基本已经被TLS取代了，不过接下来我们还是统一以SSL作为简称，SSL协议其实不止是应用在HTTP协议上，还在应用在各种应用层协议上，例如：FTP、WebSocket。

其实SSL协议大致就和上一节非对称加密的性质一样，握手的过程中主要也是为了交换秘钥，然后再通讯过程中使用对称加密进行通讯，大概流程如下：

这里我只是画了个示意图，其实真正的 SSL 握手会比这个复杂的多，但是性质还是差不多，而且我们这里需要关注的重点在于 HTTPS 是如何防止中间人攻击的。

通过上图可以观察到，服务器是通过 SSL 证书来传递公钥，客户端会对 SSL 证书进行验证，其中证书认证体系就是确保SSL安全的关键，接下来我们就来讲解下CA 认证体系，看看它是如何防止中间人攻击的。

2.2 CA 认证体系

上一节我们看到客户端需要对服务器返回的 SSL 证书进行校验，那么客户端是如何校验服务器 SSL 证书的安全性呢。如果您正在学习Spring Boot，那么推荐一个连载多年还在继续更新的免费教程：http://blog.didispace.com/spring-boot-learning-2x/

权威认证机构

在 CA 认证体系中，所有的证书都是由权威机构来颁发，而权威机构的 CA 证书都是已经在操作系统中内置的，我们把这些证书称之为CA根证书：

签发证书

我们的应用服务器如果想要使用 SSL 的话，需要通过权威认证机构来签发CA证书，我们将服务器生成的公钥和站点相关信息发送给CA签发机构，再由CA签发机构通过服务器发送的相关信息用CA签发机构进行加签，由此得到我们应用服务器的证书，证书会对应的生成证书内容的签名，并将该签名使用CA签发机构的私钥进行加密得到证书指纹，并且与上级证书生成关系链。

这里我们把百度的证书下载下来看看：

可以看到百度是受信于GlobalSign G2，同样的GlobalSign G2是受信于GlobalSign R1，当客户端(浏览器)做证书校验时，会一级一级的向上做检查，直到最后的根证书，如果没有问题说明服务器证书是可以被信任的。

如何验证服务器证书

那么客户端(浏览器)又是如何对服务器证书做校验的呢，首先会通过层级关系找到上级证书，通过上级证书里的公钥来对服务器的证书指纹进行解密得到签名(sign1)，再通过签名算法算出服务器证书的签名(sign2)，通过对比sign1和sign2，如果相等就说明证书是没有被篡改也不是伪造的。

这里有趣的是，证书校验用的 RSA 是通过私钥加密证书签名，公钥解密来巧妙的验证证书有效性。

这样通过证书的认证体系，我们就可以避免了中间人窃取AES_KEY从而发起拦截和修改 HTTP 通讯的报文。

总结

首先先通过对 HTTP 中间人攻击的来了解到 HTTP 为什么是不安全的，然后再从安全攻防的技术演变一直到 HTTPS 的原理概括，希望能让大家对 HTTPS 有个更深刻的了解。

面试官：为什么数据库连接很消耗资源，资源都消耗在哪里？

2022-04-11 19:19·小程序建站

本文主要想探究一下连接数据库的细节，尤其是在Web应用中要使用数据库来连接池，以免每次发送一次请求就重新建立一次连接。对于这个问题，答案都是一致的，建立数据库连接很耗时，但是这个耗时是都多少呢，又是分别在哪些方面产生的耗时呢？

本文以连接MySQL数据库为例，因为MySQL数据库是开源的，其通信协议是公开的，所以我们能够详细分析建立连接的整个过程。

❝

在本文中，消耗资源的分析主要集中在网络上，当然，资源也包括内存、CPU等计算资源，使用的编程语言是Java，但是不排除编程语言也会有一定的影响。

❞

首先先看一下连接数据库的Java代码，如下：

Class.forName("com.mysql.jdbc.Driver");

String name = "xttblog2";
String password = "123456";
String url = "jdbc:mysql://172.16.100.131:3306/xttblog2";
Connection conn = DriverManager.getConnection(url, name, password);
// 之后程序终止，连接被强制关闭

然后通过「Wireshark」 分析整个连接的建立过程，如下：

Wireshark抓包

在上图中显示的连接过程中，可以看出MySQL的通信协议是基于TCP传输协议的，而且该协议是二进制协议，不是类似于HTTP的文本协议，其中建立连接的过程具体如下：

第1步：建立TCP连接，通过三次握手实现；
第2步：服务器发送给客户端「握手信息」 ，客户端响应该握手消息；
第3步：客户端「发送认证包」 ，用于用户验证，验证成功后，服务器返回OK响应，之后开始执行命令；

用户验证成功之后，会进行一些连接变量的设置，比如字符集、是否自动提交事务等，其间会有多次数据的交互。完成了这些步骤后，才会执行真正的数据查询和更新等操作。

在本文的测试中，只用了5行代码来建立连接，但是并没有通过该连接去执行任何操作，所以在程序执行完毕之后，连接不是通过Connection.close()关闭的，而是由于程序执行完毕，导致进程终止，造成与数据库的连接异常关闭，所以最后会出现TCP的RST报文。在这个最简单的代码中，没有设置任何额外的连接属性，所以在设置属性上占用的时间可以认为是最少的（其实，虽然我们没有设置任何属性，但是驱动仍然设置了字符集、事务自动提交等，这取决于具体的驱动实现），所以整个连接所使用的时间可以认为是最少的。但从统计信息中可以看出，在不包括最后TCP的RST 报文时（因为该报文不需要服务器返回任何响应），但是其中仍需在客户端和服务器之间进行往返「7」 次，「也就是说完成一次连接，可以认为，数据在客户端和服务器之间需要至少往返7次」 ，从时间上来看，从开始TCP的三次握手，到最终连接强制断开为止（不包括最后的RST报文），总共花费了：

10.416042 - 10.190799 = 0.225243s = **225.243ms**！！！

这意味着，建立一次数据库连接需要225ms，而这还是还可以认为是最少的，当然「花费的时间可能受到网络状况、数据库服务器性能以及应用代码是否高效的影响」 ，但是这里只是一个最简单的例子，已经足够说明问题了！

由于上面是程序异常终止了，但是在正常的应用程序中，连接的关闭一般都是通过Connection.close()完成的，代码如下：

Class.forName("com.mysql.jdbc.Driver");

String name = "shine_user";
String password = "123";
String url = "jdbc:mysql://172.16.100.131:3306/clever_mg_test";
Connection conn = DriverManager.getConnection(url, name, password);
conn.close();

这样的话，情况发生了变化，主要体现在与数据库连接的断开，如下图：

网络抓包

第1步：此时处于MySQL通信协议阶段，客户端发送关闭连接请求，而且不用等待服务端的响应；
第2步：TCP断开连接，4次挥手完成连接断开；

这里是完整地完成了从数据库连接的建立到关闭，整个过程花费了：

747.284311 - 747.100954 = 0.183357s = 183.357ms

这里可能也有网络状况的影响，比上述的225ms少了，但是也几乎达到了200ms的级别。

那么问题来了，想象一下这个场景，对于一个日活2万的网站来说，假设每个用户只会发送5个请求，那么一天就是10万个请求，对于建立数据库连接，我们保守一点计算为150ms好了，那么一天当中花费在建立数据库连接的时间有（还不包括执行查询和更新操作）：

100000 * 150ms = 15000000ms = 15000s = 250min = 4.17h

也就说每天花费在建立数据库连接上的时间已经达到「4个小时」 ，所以说数据库连接池是必须的嘛，而且当日活增加时，单单使用数据库连接池也不能完全保证你的服务能够正常运行，还需要考虑其他的解决方案：

缓存
SQL的预编译
负载均衡
……

当然这不是本文的主要内容，「本文想要阐述的核心思想只有一个，数据库连接真的很耗时，所以不要频繁的建立连接」 。

HTTPS是什么意思（HTTPS如何保障传输安全）

1. HTTP 协议

1.1 HTTP 协议介绍

1.2 HTTP 中间人攻击

1.3 防止中间人攻击

2. HTTPS 协议

2.1 HTTPS 简介

2.2 CA 认证体系

总结

面试官：为什么数据库连接很消耗资源，资源都消耗在哪里？

发表评论

HTTPS是什么意思（HTTPS如何保障传输安全）

1. HTTP 协议

1.1 HTTP 协议介绍

1.2 HTTP 中间人攻击

1.3 防止中间人攻击

2. HTTPS 协议

2.1 HTTPS 简介

2.2 CA 认证体系

总结

面试官：为什么数据库连接很消耗资源，资源都消耗在哪里？

相关推荐

fiddler手机抓包使用教程（怎样用fiddler抓手机包）

小米8刷Win11（小米8刷11系统）

b站自动升级脚本（b站刷等级脚本代码分享）

mac比较好用的软件（mac好用的软件推荐）

视频格式转换mp4格式免费软件（视频转mp4格式转换器免费版）

找电子书资源的网站（有没有好的电子书下载网站）

发表评论