这是我在青训营的第六篇笔记，是将我的服务开放给用户这节课的前半部分（避免篇幅过长拆分了），包含网络接入和域名系统。老师以讲故事的形式讲了example公司建设自己的权威DNS服务器的心路历程（不是
将我的服务开放给用户
- 企业级服务的基本接入原理
- 从输入URL到内容加载出来经历了什么
- 从零到一搭建术语自己的网站/博客
- 当访问服务出现问题时，可以针对性地进行故障分析和解决
1.1 接入问题的引入
输入 www.toutiao.com 到网页加载出来，经历了哪些过程？
- 域名解析
- TCP建连
- SSL 握手
...
浏览器抓包：
可以通过开发者工具的 Network 进行抓包
为什么只访问头条页面，浏览器抓包却抓出来这么多请求？
根源或本质：
www.toutiao.com ，是抓包的第一条请求。其它的请求是为了渲染出来最终的页面获取的。只需关注首次的访问请求即可。
可以通过 WireShark 抓包工具来看一下，在 Client 端可以分为四个过程：
- DNS 解析
- TCP 建连
- TLS 握手
- HTTP 请求的发送
但如果要自己搭建站点，如何从零到一搭建这样的服务器呢？
字节跳动作为业界大型互联网公司，内部有一套比较成熟的网络接入体系，来帮助内部用户进行接入。
1.2 字节接入框架
A life of a request
一个报文的生命周期大概可以分为一到十步
02 企业接入升级打怪之路
以 example 公司为例，它在建站的过程中会遇到哪些问题，以及它们的网络运维人员是如何一个个解决这些问题的。
- 域名系统
- 自建DNS服务器
- HTTPS协议
- 接入全站加速
- 四层负载均衡
- 七层负载均衡
2.1 使用域名系统
example 公司在建立之初建立了好几个内部站点，下图是 example 公司的主机表：
它们的网络运维人员使用后 hosts 主机表的方式来管理 host 到 IP 的映射。 网络的管理员维护一份主配置，员工通过 ftp 协议拉取 hosts 的主配置，从而达到访问不同系统的目的。
随着 example 公司业务规模和员工数量的增长，使用该方式面临许多问题：
- 流量和负载：用户规模指数级增长，文件大小越来越大，统一分发，引起较大的网络流量和 CPU 负载。（在example公司建立初期，机房带宽和机器的容量是非常有限的）
- 名称冲突：无法保证主机名称的唯一性，同名主机添加导致服务故障（需要人工去判断域名是否是唯一的）
- 时效性：分发靠人工上传，时效性太差.（随着公司规模不断扩大，内部的系统在时刻的增长，可能本次修改还没有生效，下一个修改就已经触发了）
这种方式大大降低了企业内部系统维护的效率，工业界常规的做法是使用域名系统替代hosts文件
2.1.2 使用域名系统
使用域名系统替换 hosts 文件 关于域名空间：
- 域名空间被组织成属性结构
- 域名空间通过划分zone的方式进行分层授权管理
- 全球公共域名空间仅对应一棵树
- 根域名服务器：查询起点
- 域名组成格式: [a-zA-Z0-9_-],以带你划分label
图片的最上层是根服务器，全球有13台根服务器 接下来是 gTLD顶级域：gerneral Top-level Domains: .gov 政府, .edu 教育, .com 商业，.mil 军事, .org 非营利组织
顶级域的概念类似于在根的基础上又做了一层分布式管理
域名报文格式：（一串串看似没有规律的二进制）
2.1.3 域名购买与配置迁移
域名购买可在常规的公有云厂商处购买，比如火山引擎，阿里云。
购买二级域名： 在购买域名之后，域名树上又多了一个二级域名：example.com，专门用于 example 公司的域名体系管理
example 公司申请了一个域名之后，它就可以随心所欲进行网站建设吗？不行，工信部对域名有一些要求，要求注册商在注册域名之后进行域名的备案，从而控制域名不能进行非法信息的传播。
域名备案：放置在网上从事非法的网站经营活动，打击不良网络信息的传播，一般在云厂商处即可进行实名认证并备案。
修改配置：
- 清空 /etc/hosts
- 配置 /etc/resolv.conf 中 nameservers 为公共 DNS
- 迁移原配置，通过（云厂商）控制台添加解析记录即可。
2.1.4 如何开放外部用户访问
如何建设外部网站，提升公司的外部影响力？ 随着业务规模的不断扩大，example 公司想搭建一个外部的门户网站，用于提高公司的影响力。
之前的内部系统，比如 OA 系统，都是局域网内可达的，现在想开放公网系统该如何做呢？
方案：租赁一个外网 ip，专用于外部用户访问门户网站，将 www.example.com 解析到外网 ip 100.1.2.3，将该 ip 绑定到一台物理机上，并发布公网 route，用于外部用户访问。
下图是 example 公司的网络基础设施的雏形：
左半部分相当于运营商的部分，这里有运营商 A，运营商 B，两个运营商。
以运营商 A 来举例，用户 A 是运营商 A 的一个用户，他想访问 www.example.com ，他就去云厂商处的 DNS 来获取这个域名的解析记录，也就是 100.1.2.3 然后用户 a 直接访问 100.1.2.3 就能拿到 example 公司的外网门户网站的结果。
2.2 自建 DNS 服务器
为了解决 hosts 访问 IP 带来的 负载大，名称冲突以及时效性等一些问题， example 公司使用域名系统组件来替代 hosts 的解决方案，最终会将 web 网站开放给了用户
自建DNS就是自己的DNS系统要取代云厂商处的DNS，有些常见是云厂商处不能满足的，掌握在自己手里的才是最稳定的。
2.2.1 问题背景
使用云厂商处的DNS的缺点：
- 内网域名的解析也得出公网去获取，效率低下
- 外部用户能看到内网 IP 地址，容易被 hacker 攻击
- 云厂商权威DNS容易出故障，影响用户体验
- 持续扩大公司品牌技术影响力，使用自己的DNS系统（外部用户发现该域名的DNS托管在别的云厂商处，觉得 example 公司的能力可能不太行）
2.2.2 DNS 查询过程
网络客户端想要访问 www.163.com 这个域名，它会优先访问本地的 DNS 服务器，也就是 local DNS 里面有没有 www.163.com 的一个解析记录，一般来说首次访问，local DNS 是不会有这个域名的解析结果的，它会以此向根 顶级域和权威DNS进行解析。
step2 local DNS本身没有解析记录，它就问DNS根服务器有没有这个域名的解析记录，根服务器说没有，但是可以给你一个 com 域的一个 IP 地址，你可以向com域问一下。step4，问com域，com域说没有，但可以给你一个 163.com 的一个权威 DNS 的一个 IP 地址。之后从权威dns拿到了IP地址。Local DNS 在返回IP客户端之后，会把解析记录同时缓存在本地，以备其它网络客户端下一次查询使用。
dig {$domain} +trace 可以模拟域名的解析过程
2.2.3 DNS 记录类型
- A/AAAA: IP指向记录，用于指向IP，前者为IPv4记录，后者为IPv6记录
- CNMAE：别名记录，配置值为别名或主机名，客户端根据别名继续解析以提取IP地址
- TXT：文本记录，购买证书时需要
- MX：邮件交换记录，用于指向邮件交换服务器
- NS：解析服务器记录，用于指定哪台服务器对于该域名解析
- SOA 记录：起始授权机构记录，每个zone有且仅有唯一的一条SOA记录，SOA是描述zone属性以及主要权威服务器的记录
TTL：解析记录在 local 缓存时间超过这个时间就会失效，重新向权威 DNS 发起请求获取最新的结果
SOA 记录：权威NS是 ns1.domain.com，管理员邮件地址是 admin.example.com 下面的数据代表了 master slave之间的数据管理项： 第一个序列号是 zone 文件当前的版本号，用在做master和slave之间数据同步的版本控制 refresh 是 slave 多长时间与 master 进行一次序列号的版本核对。 目前的 DNS 系统都支持 notify 参数，这里的参数主要用于 notify参数 notify 一般用于 master 主动向 slave 进行业务通知
retry 是 slave 向 master 获取序列号失败，多长时间重新检查，这里是30分钟
expiry 是在 master 没有响应的情况下，它能够提供权威 DNS 的解析时间的长短，这里是三周
negative TTL 是针对 ns.domain 的记录，比如请求一个域名 local DNS 没有解析结果，缓存这个没有解析结果的时间，是一个小时
2.2.4 权威 DNS 系统框架：
思考：粘在企业角度思考，我们需要的是那种 DNS 服务器？
- 权威DNS
- LocalDNS（可选）
常见的开源DNS： bind、nsd、knot、coredns
以 bind 为例，了解 bind 的dns架构
- DNS Query
- DNS Response
- DNS Update
- DNS Notify
- DNS XFR
用户会发起一个DNS请求，DNS系统会给他一个 Response
如果管理员发现有一条 DNS 记录需要更新，就跟DNS系统发出一条 Update 指令，系统更新之后会把update结果返回给控制器，也就是下发端。
因为DNS系统是 Master Slave 主从模式，Master 在收到一条更新后会主动的 notify，也就是通知 slave 版本号有更新，是否要同步更新。slave收到后要获取最新的解析记录结果，就发起一条 XFR请求，最终把变更的DNS记录的全量信息拉取过来。
2.2.5 权威 DNS 系统架构
example 公司的网络运营人员经历一些时间的开发和部署之后，终于将自己的自建DNS系统上线了。
现在访问 www.example.com 的流程： 首先要解析域名的IP地址 会先向 local DNS 发起请求，Local DNS 在想自建 DNS发起请求，最终会拿到我们 IP 的解析地址 100.1.2.3，用户再去访问 100.1.2.3，把请求发送到 example 公司的机房内部，从而获取HTTP请求的结果 内网也可以直接请求内部的权威DNS服务器。
从此 example 公司再也不用担心 DNS 服务经常宕机了，同时扩大了公司的技术影响力，吸引了更多的人才来进行建设。
