将我的服务开放给用户：HTTPS和全站加速 | 青训营笔记

SyntaxSugar
93 阅读13分钟

这是我在青训营的第七篇笔记，包含了HTTPS协议和全站加速

HTTPS

2.3 接入 HTTPS 协议

上一节 example 公司为了解决外部云厂商处托管 DNS 带来的一些问题，它们使用了自建DNS服务系统，并且也解决了内网解析和外网DNS不稳定的一些问题。接下来是 HTTPS 协议

HTTPS 协议主要是为了解决 HTTP 协议明文传输带来的各种不安全的问题。

随着 example 公司的不断壮大和发展，发现了各种奇奇怪怪的问题，每天都会收到用户投诉和反馈。

2.3.1 问题背景

  • 页面出现白页/出现某些奇怪的东西
  • 返回了403的页面
  • 搜索不了东西
  • 搜索问题带了小尾巴，页面总要闪几次
  • 页面弹窗广告
  • 搜索个汽车就有人给我打电话推销4s店和保险什么的。

经过运维人员的排查，发现问题的根本原因，是某些运营商对我们的请求做了抓取，并对我们的响应做了篡改，因为HTTP响应是明文的，使用HTTP的弊端越来越明显。

解决办法是使用 HTTPS 协议

https 协议看起来就是在 http 后面加了个 s，但真的是这么简单吗？

2.3.2 对称加密和非对称加密

常见的加密算法 对称加密：一份密钥

image.png

对称加密是指加密的数据在传输过程中是无规则的乱码，即使被第三方获取，它在没有密钥的情况下也无法解密数据，从而保证了数据到安全性。

图中的对称加密，客户端和服务器都拿密钥KEY进行数据的加密，从而保证数据的安全性，但这样有一个致命的问题。

双方都要使用相同的密钥，那么在传输数据之前，密钥必须从一方传递给另一方，在传输的过程中，密钥可能被截获，这样加密的数据可能就会被轻松的解密。

如何保证密钥在传输过程中的安全性？需要使用非对称加密。

非对称加密，加密和解密使用两个不同的密钥，也就是公钥和私钥。公钥和私钥是一对，如果使用公钥对数据进行加密，只有用私钥才能进行解密，如果用私钥对数据进行加密，只有用公钥才能进行解密。

公钥私钥就像一把钥匙和一个锁头，你可以把锁头给别人，这样的话别人可以用锁头把重要的东西锁起来，发给你，因为只有你一个人有这把钥匙，所以只有你能看到被这把所锁起来的东西。

常见的非对称加密算法是 RSA 算法

图中，客户端在拿到服务器的公钥后会生成一个用于对称加密的密钥key，客户端使用服务器的公钥把密钥加密后再发给服务器，服务器再使用私钥进行解密，双方有一个同样的对称加密的密钥key，加密的传输密钥key，传输过程中，即使第三方获取了公钥和加密后的密钥key，在没有私钥的情况下也无法获取用于对称加密的密钥key，而且私钥存储在服务器上，泄露的风险比较小，这样就保证了接下来对称加密传输数据的一个安全性。右边的图其实是HTTPS的雏形。HTTPS综合了对称加密和非对称加密的有带你，不仅保证了数据通讯安全，还保证了一定的数据传输效率

2.3.3 SSL 的通信过程

SSL握手的过程：

image.png

  • client random

  • server random

  • premaster secret

  • 加密算法协商

  • 对称密钥 session key

SSL 的加密套件有很多，拿最简单的 SA 套件来举例

首先 client 跟 server 端发了一个 client hello 消息，这个消息包含了客户端支持的TLS版本以及密码组合，让服务器进行选择，还有一个 client random 的随机字符串

server 端收到这条消息之后，又发送一个 server hello 给 client，这个消息包含了数字的证书链，以及服务器选择的密码组合，还有一个 server random 的随机字符串。

接下来客户端会对服务器发来的证书或者公钥进行验证来保证对方的一个合法身份。

接下来，客户端会生成一个域主密钥： premaster secret 这个 secret 会经过服务器的公钥进行加密，然后发送给服务器，服务器用私钥进行解密。

到这里，服务器和 client 都有了相同的四个属性，一个是 client random，随机字符串，一个是 server 端的 server random 随机字符串，一个是域主密钥：premaster secret，根据它们协商出来的加密算法，能够算出来一个对称加密的 session key，然后双方就用这个 session key来进行数据传输。

2.3.4 证书链：

公钥确定是可信的吗？会不会被劫持？ 我们来看一下证书，公钥是存在证书里面的。

image.png

Server 端发送的是带签名的证书链

Client 收到后仍然需要验签

  • 是否是可信机构颁布
  • 域名是否与实际访问一直
  • 检查数字签名是否一致
  • 检查证书的有效期
  • 检查证书的撤回状态

服务器在对证书的内容进行信息摘要计算的时候，会得到一个摘要信息，也就是指纹。然后再用中级证书私钥把摘要进行加密，得到数字签名。然后服务器会把数字证书连同上级CA的数字签名一起发送给客户端，这样，客户端就用上级CA的公钥来解密数字签名，从而得到摘要信息，如果能够正常解密，就说明摘要信息是没有错的，保证了数据的安全性。

同时 client 会使用相同的信息之啊要算法重新计算证书的摘要信息，然后把两个摘要信息进行比对，如果相同，说明证书没有被篡改，从另一方面保证了安全性。

image.png

那么，上级证书的公钥一定是可信的吗？上级证书最终是被根证书所签名的，它是同样的一个校验过程。根证书是自己签发自己的，一定是可信的，因为它存在于用户的机器或者操作系统里面，是不变的。

2.3.5 使用 https

example 公司的运维人员，购买证书，然后配置到自己的服务器上，就可以使用https进行访问了，图片上多了一个小锁头，表明访问是安全的，而且再也不用担心公网上的内容被监听或者窃取，从而解决了明文传输所带来的一些黑产或者一些安全性的问题。

image.png

2.4 接入全站加速

上一节 example 公司巍峨了解决 HTTP 协议构建外部网站带来的各种劫持的问题，购买了证书，并强制使用了 HTTPS 系统，从而保证了访问的可靠性和啊那权限。下面讲解全站加，以及它适用于哪些网络优化的场景。

2.4.1 问题背景

外网用户访问站点，一定是一帆风顺的吗？可能出现的问题有哪些？

  • 源站容量第，可承载的缤纷噶请求书低，容易被打垮
  • 报文经过的网络设备越多，出问题的概率越大，丢包，劫持，mtu问题
  • 自主选路网络链路长，时延高

这些问题在用户角度看就是响应慢，卡顿

根据不完全统计，如果请求一个网页的响应时间大于3秒，80%的用户会选择其它产品进行替代，内容做的再好，也没有用户群体。

极大的六十了大部分的用户群体，NPS 留存率数据不乐观

2.4.2 解决方案

  • 源站容量问题：增加后端机器扩容；静态内容，使用静态加速缓存
  • 网络传输问题：动态加速 DCDN
  • 全站加速：静态加速+动态加速

静态加速和动态加速这里统称为全站加速

2.4.3 静态加速 CDN

当前的访问过程： image.png

client 在获取 DNS 解析以后，直接向站点服务器发送请求，得到响应

针对静态文件传输，网络优化方式？

缓存

image.png

静态内容：正在请求的过程中，访问的数据其实都是相同的静态文件，比如一些图片，视频，还有网站中的文件，比如 html，css，js等，还有软件压缩包，安装包等一些文件。

在计算机系统中，加速访问的解决方案是什么？比如 CPU 访问内存，有寄存器，有123级cache，CPU访问硬盘，有内存。

本质上其实都是缓存，一样的道理，使用 CDN 可以将静态文件进行缓存加速，通过将服务器的静态内容缓存在 CDN 节点上，当访问这些静态内容是，无需再访问服务器的源站而是就近访问CDN节点，就可以获取相同的结果从而达到加速的效果，同时减轻了源站服务器的压力。

根据图片，静态加速时，服务器获取的就不是源站的 DNS 结果了，而是CDN节点的解析结果，CDN节点使用的是智能调度DNS，根据一定的算法策略，比如静态拓扑，容量等等，将一些比较合适的CDN节点，IP地址返回给 local 节点，最终返回 client，client再进行请求CDN节点，同时发送一次源站的请求，它会把这个结果进行缓存，已被下一次命中缓存后，直接返回，不用请求源站，从加速了静态文件的响应优势。

2.4.3 静态加速 CDN

  • 解决服务器端“第一公里”问题

什么叫第一公里？我们要将请求经可能的优化在靠近用户的节点上进行响应，从而缩短网络的链路，最好控制在较短的一个网络链路里面。

  • 缓解甚至消除了不同运营商之间互联的瓶颈造成的影响。

不同的运营商再相互访问的时候是具有成本的，本质上是在互联网交换中心进行交换的，而这个交换时存在成本和瓶颈的，如果在数据量较大的时候，可能会出现一些问题

  • 减轻了各省出口的压力 将一些静态内容的请求尽量控制在靠近client端附近，也就是能够做到足不出省就呢个完成本次请求。
  1. 优化了网上热点内容的分布 热点分布在靠近用户的CDN节点上

说完了静态内容加速的一些适用场景，原理和优势，接下来看一下对于非静态内容应该怎么进行加速。

2.4.4 动态加速 DCDN

针对 POST 等非静态请求等不能在用户边缘缓存的业务，基于智能选路技术，从中断会员线路中择优选择一条线路进行传输。

image.png

动态内容其实可以通过特定的路由优化传输优化等动态加速的优化手段，来优化访问源站。

2.4.5 DCDN 原理

图片从最外层到最内层依次是用户，边缘节点，护具节点以及核心机房（也就是核心节点）

边缘节点靠近用户，规模小，容量小，但是数量庞大

汇聚节点，围绕核心机房搭建，数量次之，容量居中

核心机房是企业内部，比如 example 公司自建的机房，规模容量都比较大，但是缺点是数量少。

越往中心，节点越少，容量和算例越大，越往边缘，节点越多，容量和算力越少。

image.png

为什么呢？

假如去卖水果，是选择人多的中心闹市区，比如北上广，还是地广人稀的西部地区呢？

答案肯定是选择中心区域，一般来说西部地区网络环境比较差，同时地广人少，建机房的投入产出比非常小。

动态加速的核心思想： 打个比方，要实现北京交通，要从昌平走到国家图书馆。在十几年前的时候没有地铁，我们智能靠步行然后挨个问路，怎么从昌平到达海淀，怎么在海淀内部找各个标志性建筑物，这就类似于网络上路由的自主选路。

现在有了地铁，可以在导航上进行搜索，先步行到昌平线，然后在昌平线再转3号线，转4号线这样走快截图就的方式来加速访问速度。

接下来看一下 RTT

RTT是访问时间

RTT示例：

  • 用户到核心 35ms （直连）
  • 用户到边缘 20ms
  • 边缘到汇聚 10ms
  • 汇聚到核心 10ms

常规请求耗时计算

Via DCDN:100ms

20(TCP) + 20*2(TLS) +20 + 10 + 10(routine)

Direct 140ms 35(TCP) + 35*2(TLS) + 35(routine)

使用动态加速，一个 TCP连接是一个RTT，也就是20ms，TLS握手是 2个 RTT，也就是40ms，再加上一次路由穿透的过程，大概花了 100ms

直接请求源站是35*4 也就是140ms

使用动态加速节省了 40ms 的时间

从边缘节点到汇聚节点，以及从汇聚节点到核心节点不需要建连吗？

其实是需要建连的，只不过建联的动作在首次的时候已经被预热掉了，后续的一些请求就无需关注建连的时间成本。

2.4.6 使用全站加速

请区分下列场景使用的加速类型： 1.用户首次登录抖音，注册用户名手机号等用户信息：动态加速DCDN

  1. 抖音用户点开某个特定的短视频加载后观看：静态加速CDN
  2. 用户打开头条官网进行浏览：静态加速CDN+动态加速DCDN

使用全站加速后，example的网络链路以及网络架构模型：

image.png

多了一个全站加速的节点，全站加速节点里面主要包含全站加速 DNS和全站加速的数据面

用户在请求这个域名的时候 local DNS 会优先将请求达到全站加速的权威 DNS 上，从而拿到权威DNS的IP地址，拿到之后相当于用户会访问全站加速的节点，这个时候它其实是没有请求的 response的，它要解析源站的IP地址，也就是请求5，从而从 example 公司内部拿到权威DNS的一个解析结果，然后发起6这个请求，拿到请求的response之后通过7返回给用户

avatar
文章
阅读
粉丝