继续创造，加快生长！这是我参与「日新方案 6 月更文挑战」的第22天，点击查看活动详情

1.全链路上的组件

域名体系

host文档

如图，主机表存储ip对域名的映射

可是会有流量和负载、名称抵触、时效性问题

运用域名体系（常用做法）

关于域名空间:
域名空间被组织成树形结构
域名空间经过区分zone的方法进行分层授权办理全球公共域名空间仅对应一棵树
根域名服务器:查询起点
域名组成格式:[a-zA-Z0-9_-]，以点区分label

尖端域gTLD: general Top-level Domains

域名报文格式：

给外部用户拜访

方案:租赁一个外网ip，专用于外部用户拜访门户网站，将w ww.example.com解析到外网ip 100.1.2.3，将该ip 绑定到一台物理机上，并发布公网route，用于外部用户拜访。

自建DNS服务器（大企业）

DNS查询进程

Linux查询DNS解析进程的命令：
dig www.baidu.com +trace

DNS记载类型

A/AAAA︰IP指向记载，用于指向IP，前者为IPv4记载，后者为IPv6记载
CNAME:别号记载，装备值为别号或主机名，客户端依据别号继续解析以提取IP地址TXT:文本记载，购买证书时需求
MX:邮件交流记载，用于指向邮件交流服务器
NS:解析服务器记载，用于指定哪台服务器关于该域名解析
SOA记载︰起始授权机构记载，每个zone有且仅有仅有的一条SOA记载，SOA是描绘zone特点以及首要威望服务器的记载

TTL是缓存时刻，超过就会失效，从而要从头向威望服务器恳求

版别号，Master和Slave之间的版别操控 Slave与Master间版别核对的间隔时刻 Slave向Master核对时未获得响应的重试间隔时刻 在没有Master响应的情况下，Slave依然能供给威望DNS解析时刻的长短 没有DNS解析成果时，缓存该恳求的时刻

威望DNS体系架构

以bind架构为例子： Client建议DNS Query，Master返回DNS Response，假如发现有DNS体系需求更新，APP Server就发送Update恳求，Update的成果返回给下发端，Master收到Update之后会自动Notify Slave询问是否同步更新，若是则向Master建议XFR恳求，返回更新信息。

有了威望DNS体系后，当时

接入HTTPS协议

对称加密和非对称加密

对称加密和非对称加密 RSA算法

对称算法：一份密钥，两边相同

非对称：公钥和私钥
公钥加密需求私钥来解密

SSL

SSL握手进程，RSA套件为例：

①Client向server端发送client hello消息，包括客户端支持的TLS版别和暗码组合
②server收到后又发送client hello给client，包括数字增量、server random以及服务器所挑选的暗码组合
③client对server发来的公钥和证书进行验证，保证对方合法身份
④client对server发送预备主密钥premaster secret，经过公钥加密，要服务器的私钥解密
⑤最终算出对称的密钥session key，两边运用session key进行数据传输

证书链

需求验证的项目：

• 是否是可信机构公布
• 域名是否与实践拜访共同
• 查看数字签名是否共同
• 查看证书的有效期
• 查看证书的撤回状态

验证签名的进程： 服务器进行信息摘要核算得出指纹，用证书私钥给摘要信息加密得出数字签名，证书数字签名和上级CA的签名会被一同发给Client，Client用上级CA（最终为根证书签名，可信）发的公钥来解密数字签名得到摘要信息，此刻Client会运用相同加密算法核算摘要信息的签名，假如共同阐明没有篡改

全站加快

可能呈现的问题： 源站容量低，可承载的并发恳求数低，简单被打垮 报文经过的网络设备越多，出问题的概率越大，丢包、绑架、mtu问题 自主选路网络链路长，时延高

源站容量问题 增加后端机器扩容;静态内容，运用静态加快缓存 网络传输问题 动态加快DCDN 全站加快 静态加快+动态加快

CDN静态加快

CDN加快，减轻站点服务器压力，此刻DNS服务器返回的也是CDN节点的解析成果

效果：
处理服务器端的“榜首公里”问题
缓解不同运营商之间互联的瓶颈形成的影响
减轻带宽压力
优化内容分布

DCDN动态加快

针对 POST等非静态恳求等不能在用户边际缓存的事务，依据智能选路技能，从众多回源线路中择优挑选一条线路进行传输。

耗时核算 惯例恳求耗时核算:Via DCDN:100ms 20(TCP)+20*2(TLS握手)+20+10+10(routine穿透)

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

运用全站加快

四层负载均衡

处理问题：对有限ip地址的运用

依据IP+端口，运用某种算法将报文转发给某个后端服务器，完成负载均衡地落到后端服务器上。

三个首要功用:

1. 解耦vip和rs。应用服务不局限于某一台物理机，能够灵活指向后端，使后台容量能够灵活扩缩容。
2. NAT。把恳求转发给后端，作为流量署理（反向署理）
3. 防进犯:syn proxy。防止物理机ip直接暴露在公网，负载均衡进行拦截

常见调度算法

• RR轮询:Round Robin，将所有的恳求均匀分配给每个实在服务器RS
• 加权RR轮询:给每个后端服务器一个权值份额，将恳求依照份额分配
• 最小衔接:把新的衔接恳求分配到当时衔接数最小的服务器
• 五元组hash:依据sip、sport、proto、dip、dport对静态分配的服务器做散列取模——缺陷︰当后端某个服务器毛病后，所有衔接都从头核算，影响整个hash环
• 共同性hash:只影响毛病服务器上的衔接session，其余服务器上的衔接不受影响

常见完成方法FULLNAT

VIP：virtual ip LIP: local ip RS: physical system 物理机

RS怎么知道实在CIP？（场景：交际渠道显示ip属地） 答复:经过TCP option字段传递，然后经过特别的内核模块反解

4层负载均衡特点

• 大部分都是经过dpdk技能完成,技能老练，大厂都在用
• 纯用户态协议栈,kernel bypass，消除协议栈瓶颈
• 无缓存，零拷贝，大页内存(削减cache miss)
• 仅针对4层数据包转发，小包转发可达到限速，可承受高cps

运用4层负载均衡

7层负载均衡

提问:四层负载对100.1.2.3只能bind一个80端口而有多个外部站点需求运用，该怎么处理?

事务场景：

• SSL卸载:事务侧是http 服务，用户需求用https拜访
• 恳求重定向︰浏览器拜访toutiao.com自动跳转www.toutiao.com
• 路由添加匹配战略:彻底、前缀、正则
• Header编辑
• 跨域支持（第三方网站支持）
• 协议支持:websocket、grpc、quic

Nginx

模块化规划，较好的扩展性和可靠性 依据master/worker 架构规划(master首要用于进程办理，worker处理用户恳求，http报文等） 支持热部署，可在线升级 不停机更新装备文件、替换日志文件、更新服务器二进制 较低的内存耗费:1万个 keep-alive衔接模式下的非活动衔接仅耗费2.5M内存 事情驱动:异步非堵塞模型、支持aio,mmap(内存映射)

反向署理示意图

署理服务器功用 Keepalive 拜访日志 url rewrite 途径别号 依据ip 的用户的拜访操控限速及并发衔接数操控

Nginx内部架构 每个worker进程能够响应多个用户恳求，运用模块把模块编译 不同模块与不同后端通讯，core跟web，upstream跟server 下面还完成了办理cache的组件

事情驱动模型

是Nginx功率进步一个很关键的点

不需求一直监听，发生事情后将事情以及对应回调函数存入行列傍边，然后线程从行列傍边取出并履行对应模块

异步非堵塞

进步CPU运用率 传统服务器: 一个进程/线程处理一个衔接/恳求堵塞模型、依赖OS 完成并发 Nginx: 一个进程/线程处理多个衔接/恳求异步非堵塞模型、削减OS 进程切换

简单调优

优化内核网络参数

fs.filemax= 999999 //文件最大句柄（方针或实例的标识）数，设置数值较大可限制并发衔接数
net.ipv4.tcp_tw_reuse = 1 //答应timewait socket建立新的TCP衔接，防止- timewait衔接数许多
net.ipv4.tcp_keepalive_time = 600  //调小，清理无效的TCP衔接
net.ipv4.tcp_fin_timeout = 30  //TCP自动延时
net.ipv4.tcp_max_tw_buckets = 5000 //答应timewait socket的最大值，太多会下降功率
net.ipv4.ip_local_port_range = 1024 61000 //client端口取值范围，调大一点处理更多衔接
net.ipv4.tcp_max_syn.backlog=1024 //半衔接行列长度，并发衔接过多时不会丢包
net.ipv4.tcp_syncookies = 1 //衔接进犯问题

提高CPU运用功率

合适的worker进程数
Worker进程数= CPU 核数

CPU亲和
每个worker进程绑定一个CPU核,提高缓存命中率

削减CPU开支的参数

• multi_accept答应worker一起承受新衔接，为on时让worker一次承受监听行列所有恳求，然后再处理
• accept_mutex处理惊群问题（waiting时，一下子都被唤醒，然而只有一个worker被承受，其他又继续waiting）
• reuseport 监听同端口,内核负载均衡，运用reuseport后accept_mutex就无效（由于用不着了）

提高网络功率

• 衔接复用 削减upstream建连
• 运用Cache 超时时刻对事务的影响
• gzip压缩 会增加cpu开支,需平衡运用
• 开启proxy_buffering 慎重设置proxy_buffer大小，磁盘io读写

运用7层负载均衡

留意：威望DNS服务器首要依据UDP/TCP转发，不需求七层负载均衡

实践

DNS服务器建立

四层负载均衡试验

开源的处理方案:LVS+keepalived
LVS: linux virtual server，linux虚拟服务器，依据方针地址和方针端口完成用户恳求转发，本身不发生流量，只做用户恳求转发,详见www.linuxvirtualserver.org/
Keepalived: LVS集群高可用，处理某个节点毛病问题

Nginx stram模块:可进行四层协议tcp/udp报文进行转发、署理

七层负载均衡试验

本地服务开放外网拜访

提问:服务开发前期，怎么低成本的让他人拜访自己的服务?
答复: Ngrok，Expose your localhost to the web

运用条件:运用github账户授权登录，即可运用，详见dashboard.ngrok.comIget-started/setup

EXAMPLES:
ngrok http 80 #secure public URL for port 80 web server
ngrok http -subdomain=baz 8080 # port 8080 available at baz.ngrok.iongrok http foo.dev:80 #tunnel to host:port instead of localhost
ngrok http https:/localhost # expose a local https server
ngrok tcp 22 #tunnel arbitrary TCP traffic to port 22
ngrok tls -hostname=foo.com 443 # TLS traffic for foo.com to port 443ngrok start foo bar baz #start tunnels from the configuration file

QA

dns污染和绑架
DHCP（Dynamic Host Configuration Protocol）被禁止，由于需求监测，绑架是会被中心抓包和抢先答复

TTL时刻越短越好吗？
TTL时刻过短，威望DNS压力会比较大