hexo博客搭建的一些思考

为什么要给域名申请SSL证书

只有给域名申请了SSL证书，才能以https协议访问域名，才能确保客户端和服务端的会话是加密的，是安全的。

https

http是不安全的，在客户端与服务端使用http通信的时候，请求响应报文都是明文的，消息被截获后通信内容就泄漏了。

https在http的基础上，使用TLS/SSL加密，从而确保通信是安全的。

使用https协议访问某个域名/网站，除了基本的DNS解析，TCP三次握手建立连接，还要经过SSL握手，然后才能开始加密通信。

TLS/SSL

TLS/SSL加密过程中既使用了对称加密，也使用了非对称加密。使用非对称加密是为了得到一个会话密钥，这个会话密钥并没有进行传输，而是双方通过计算得出来的，握手成功后，再使用这个会话密钥进行对称加密。

对称加密

使用同一把密钥进行加密和解密。发送方和接收方必须共享相同的密钥。优点是解密速度快，适合大量数据的加密，缺点是密钥必须共享，这个过程密钥可能被窃取。

非对称加密

使用一对密钥：公钥（公开）和私钥（保密）。公钥用于加密，私钥用于解密。优点是只传输公钥，私钥不进行传输，泄漏风险很小，很安全，缺点是解密速度慢。

SSL证书

SSL证书其实就是保存在源服务器的数据文件，想要证书生效必须向CA申请，表明域名是属于谁的(可以理解为域名必须实名认证，有人需要为这个域名负责)，还包含了公钥和私钥。

TLS/SSL握手过程

在握手的过程中，服务端会把自己的SSL证书和公钥发送给客户端验证，浏览器会通过查询浏览器的证书信任列表来判断这个证书是否有效，证书无效则浏览器显示这个连接不安全，有效则继续进行后续操作，经过非对称加密得到一个会话密钥，握手结束。

在握手过程中第一随机数，第二随机数，和公钥都是明文传输的，就意味着有暴露的风险，但是第三随机数的传输是经过公钥加密的，只能用私钥解密,也就是只有服务端知道第三随机数是什么，这就是一次非对称加密，然后再用那3个随机数计算得到会话密钥，会话密钥没有进行传输所以是安全的，握手结束后，后续的通信都用这个会话密钥加密。

详细解释可参考：HTTPS是什么？加密原理和证书。SSL/TLS握手过程_哔哩哔哩_bilibili

为什么接入cdn加速后还要申请SSL证书

在我们不接入cdn加速服务之前，我们无论是访问用户名.github.io还是自定义域名，最终都是从GitHub pages服务器拿到数据，SSL握手的对象也是githubpages服务器, github为我们免费生成的SSL证书是存储在githubpages服务器的;但是我们接入cdn服务后，我们就不是从源服务器（githubpages服务器）取数据了，而是cdn服务器，握手的对象就是cdn服务器，所以我们还需要手动为我们的自定义域名（或者默认域名）申请一次SSL证书，存储在CDN服务器中，后续我们才能使用https协议访问cdn服务器。

gulp和webpack的区别

Gulp是基于nodejs流的前端构建工具，可以实现文件的转换，压缩，合并，监听，自动部署等功能。gulp拥有强大的插件库，基本上满足开发需求，而且开发人员也可以根据自己的需求开发自定义插件。难得是，gulp只有五个api，容易上手。配置文件是gulpfile.js

webpack的主要作用是解析模块之间的依赖关系，并把他们有条理的打包起来，顺便把模块化的代码转化成浏览器可以识别的代码。webpack从入口文件开始，递归找出所有依赖的模块，并使用配置的loader解析模块，使之变为可用的模块，而在webpack会在各个特定的时期广播对应事件，插件会监听这些事件，在某个事件中进行特定的操作。通俗一点来说，webpack本身来递归找到各个文件之间的依赖关系，在这个过程中，使用loaders对文件进行解析，最后，在各个不同的事件阶段，插件可以对文件进行一个统一的处理。

虽然Webpack与gulp都是前端工程化的管理工具，但是二者的侧重点不同——gulp更加关注的是自动化的构建工具，你把代码写好了，gulp会帮你编译、压缩、解析。而Webpack关注的是在模块化背景下的打包工作；它侧重的还是如何将依赖的文件合理的组织起来，并且实现按需加载。

详细参考文章：Javascript五十问——从源头细说Webpack与Gulp - Javascript 五十问 - SegmentFault 思否