1. 接入问题引入

浏览器 输入网站域名到网页加载出来，都经历了哪些过程？
域名解析；TCP建连；SSL握手；
浏览器抓包：DNS解析；TCP 建连；TLS握手；HTTP请求；

1.2 字节接入框架

2. 企业接入升级打怪之路

2.1 域名系统

2.1.1 Host管理

内部站点
主机表
Host->ip映射
业务规模，host管理出现问题： 流量和负载，文件越来越大；
名称冲突：人工判断域名；
时效性差：刚修改，就又要修改；

2.1.2 使用域名系统

用域名系统替代hosts文件
域名空间： 域名空间被组织成树形结构； 通过划分zone的方式进行分层授权管理；
全球公共域名空间仅对应一棵树；
根域名服务器：查询起点；
域名组成格式：[a-zA-Z0_-],以点划分label；
根、顶级域、二级域、三级域、四级域……
顶级域gTLD（general top-level domains）：gov政府、edu教育、com商业、mil军事、org非盈利组织
如何拿到属于自己（自己能管控）的域名

2.1.3 域名购买与配置迁移

域名购买：云厂商购买，如阿里云
若现在购买二级域名：example.com，则域名树在对应的二级域名处就多加了一个节点example
但现在还不能为所欲为， 要进行域名备案：防止在网上从事非法的网站经营活动，打击不良互联网信息的传播，一般在云厂商处即可进行实名认证并备案。
修改配置： 清空/etc/hosts 文件；配置/etc/resolv.conf中nameservers为公共DNS；
迁移原配置，通过云厂商控制台添加解析记录即可。

2.1.4 如何开放外部用户访问

建设外部网站，提高公司影响力
方案：租赁一个外网ip，专用于外部用户访问门户网站，将www.example.com解析到外网IP 100.1.2.3,将该IP绑定到一台物理机上，并发布公网route，用于外部用户访问
用户在云厂商DNS获取解析地址，得到IP地址 100.1.2.3 ，然后访问100.1.2.3

2.2. 自建DNS服务器

2.2.1 问题背景

用云厂商的DNS的缺点： 内网域名的解析也要出公网去获取，效率低下（没有必要，本可以内网解决的）
公网可以看到内网的IP地址，容易被hacker攻击
云厂商权威DNS不稳定容易出故障

2.2.2 DNS查询过程

客户端想要访问一个网站，先问本地DNS服务器有没有对应的解析记录，若没有，问DNS根服务器，根没有，但是它给了对应顶级域服务器的地址，顶级域服务器也没有，但是给了二级域服务器地址，刚好，这个二级域服务器知道并且返回给本地DNS服务器这个域名的IP地址，然后本地DNS服务器把IP地址告诉客户端，并且自己存下了这个解析记录

2.2.3 DNS记录类型

A/AAAA
CNAME
TXT:
MX:邮件交换记录
NS:解析服务器
SOA：其实授权机构记录

2.2.4 权威DNS系统架构

思考：站在企业角度考虑，我们需要的是哪种DNS? 答：权威DNS，localDNS（可选）
常见的开源DNS:bind，nsd、knot、cordns
以最常见的bind为例看看架构：
DNS query：用户发起DNS请求，系统返回response
DNS update：系统管理员发现系统要更新，发出update的指令，并把更新的结果返回给下发端。
DNS notify：master更新后，通知slave，我更新了，你要不要同步
DNS XFR:slave要同步，发出XFR请求，把当前的变更（更新）拉取过来

2.2.5 权威DNS系统架构

用户要获取某域名的解析地址，先向local DNS发出请求，local DNS 向自建权威DNS发出请求，用户得到所需IP地址，然后访问该地址。

2.3 接入HTTPS协议

2.3.1 问题背景

出现问题：返回403；搜索问题带了小尾巴；页面弹窗广告；出现白页；搜索之后就有人打电话推销；
原因：某些中间运营商对请求做了抓取，并对响应做了篡改；HTTP明文传输的弊端越来越明显。
解决：用HTTPS协议

2.3.2 对称加密和非对称加密

常见的加密算法：
对称加密：一份密钥；
传输的信息通过密钥进行了加密；
双方持有同一份密钥，在传输数据之前，一方要先把密钥传给另一方，这样，在传输过程中，密钥就有可能被截获，不够安全。
解决方法：非对称加密保证密钥在传输过程中的安全性（公钥和私钥）
客户端发送请求； 服务器将公钥返回给客户端（这样，服务器有公钥和私钥，客户端有公钥）
客户端生成密钥KEY，并使用公钥对KEY进行加密；
客户端把加密后的KEY发给服务器；
服务器使用私钥解密获得密钥KEY; 双方使用密钥KEY进行对称加密传输；
这样，即使传输中的公钥和加密后的KEY被获取，没有私钥，也不能获取信息。
私钥在服务器上，泄露的风险较小
以上就是HTTPS的雏形

2.3.3 SSL的通信过程

用最简单的RSA举例
客户端发 client random 给 服务端 ，
服务端发 server random 给 客户端，还有 public key certifcate
客户端 生成密钥 经过 公钥加密 的premaster secret 发给服务端
服务端 私钥解密 得到 premaster secret
通过协商加密算法
最后双方都有session key用于对称加密

2.3.4 证书链

公钥确定是可信的吗？会不会被劫持
公钥在证书里面
client收到证书需要验证： 是否是可信机构颁布的；域名是否与实际访问一致；检查数字签名是否一致；检查证书的有效期；检查证书的撤回状态
证书链如何验签？
服务器在对摘要信息计算的时候会得到证书摘要信息（指纹）
用私钥对证书摘要加密，得到数字签名
服务器把数字证书和上级CA的数字签名发送给客户端
客户端用上级CA的公钥解密数字签名，得到摘要信息
若能正常解密则说明摘要信息没有错，保证数据安全性
同时，client会用相同的信息摘要算法重新计算证书的摘要信息，将两个摘要信息进行比对，若相同，则证书没有被篡改

2.3.5 使用https

2.4 接入全站加速

2.4.1 问题背景

外网用户访问站点，一定是一帆风顺的吗？可能出现的问题有？
源站容量低，可承载的并发请求数低，容易被打垮
报文经过的网络设备越多，出问题的概率越大，丢包、劫持、mtu大小匹配不一致问题
自主选路，网络链路不可控，可能时延很高。
以上问题在用户看来，就是响应慢、卡顿，用户就不喜欢；
极大的流失了大部分的用户群体，NPS留存率数据不乐观

2.4.2 解决方案

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

2.4.3 静态加速CDN

针对静态文件传输： 静态：大家看到的都一样的
优化方式：缓存加速。缓存到cdn节点上。 解决了服务器端的“第一公里”问题：将请求尽可能优化在靠近用户的那一端，缩短网络链路
不同运营商访问需要成本，这个缓解甚至消除了不同运营商之间互联的瓶颈造成的影响；
减轻了各省的出口带宽压力：静态文件到缓存到用户端附近，不出省就能响应请求
优化了网上热点内容分布：将热点内容放在靠近用户的cdn节点上。

2.4.4 动态加速 DCDN

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

2.4.5 DCDN原理

用户；
边缘节点：靠近用户，规模小，数量庞大；
汇聚节点：围绕核心机房搭建，数量居中，容量居中。
核心机房：一般在核心区，规模大，数量少。
西部地区网络质量差，地广人稀，建机房的投入产出比较小。
用户要获取某域名的解析地址，
先向local DNS发出请求，
local DNS 向 全站加速的厂商DNS发出请求，拿到全站加速DNS的IP地址； local DNS将全站加速DNS的IP地址交给用户；
用户访问全站加速IP地址，
然后厂商DNS向自建权威DNS用户得到所需IP地址，
然后全站加速DNS访问该地址得到response
全站加速DNS将response返回给用户。

2.5 四层负载均衡

2.5.1 问题背景

在运营商处租用的100.1.2.3的公网IP，如何在企业内部使用最合理？
现状：直接找一个物理机，ifconfig将网卡配上这个IP，起server监听端口即可
随着业务发展，应用多，要起多个server监听不同的端口。
服务混杂，每个部门容易误伤；所有服务都部署在一台物理机上，物理机不小心挂了，就完蛋了
处理：企业内部，分层次管理； 对外暴露的公网IP称为VIP，virtual IP

2.5.2 什么是4层负载均衡

基于IP+端口，利用某种算法将报文转发给某个后端服务器，实现负载均衡地落到后端服务器上。

2.6 七层负载均衡

2.6.1 问题背景

四层负载对100.1.2.3只能bind一个80端口，而有多个外部站点需要使用，该如何解决？
有一些7层相关的配置需求，该怎么做？ SSL卸载：业务侧是http服务，用户需要用https访问；
请求重定向：浏览器访问toutiao.com，自动跳转www.toutiao.com;
路由添加匹配策略：完全、前缀、正则
header编辑；
跨域支持（第三方页面）；
协议支持：websocket、grpc、quic；
要实现以上功能，四层负载均衡不行。

2.6.2 Nginx简介

最灵活的高性能web server，应用最广的7层反向代理；
模块化设计，有较好的扩展性和可靠性；
基于master（进程管理)/worker（数据面请求的处理，如报文处理）架构设计； 支持热部署；可在线升级；
不停机更新配置文件、日志文件、更新服务器二进制
较低的内存消耗：一万个keep-alive连接模式下的非活动连接仅消耗2.5M内存；
事件驱动：异步非阻塞模型、支持aio、mmap内存映射

2.6.3 nginx和apache性能对比

nginx优势很大

2.6.4 nginx反向代理示意

2.6.5 nginx内部架构

2.6.6 事件驱动模型

一个事件，用一个进程去循环检测（要很多进程，太浪费）
一个进程管一个事件队列，不同事件调用不同的处理函数（进程少，比较好）