将我的服务开放给用户｜ 青训营笔记

nuanyang26
141 阅读9分钟

将我的服务开放给用户

学到什么？

  • 系统的熟悉和学习到企业级网络接入核心组件及基本原理
  • 当面试时，别人问到你从输入网页到内容加载出来，可以泛泛而谈
  • 可以自己从零到一搭建属于自己的网站/博客（网络基础设施)
  • 当访问服务出现问题时,可以针对性地进行故障分析及解决

01. 接入问题引入

1.1 问题引入

在浏览器地址栏输入 www.sinna.com/ 后发生了什么？

通过浏览器开发者工具 抓包可以发现有很多的请求

通过wireshark 抓包可以发现 大体有四个过程

  1. DNS解析

  2. TCP建连

  3. TLS握手

  4. http请求

    image-20230610094810815

如果是我,该如何从零到一搭建这样的一些服务器?

1.2 字节接入框架

一个请求的生命周期

image-20230610094922945

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

2.1 使用域名系统

2.1.1 Host管理

网管统一管理并下发 host文件

image-20230610095101243

缺点

  • 流量和负载:用户规模指数级增长，文件大小越来越大，统一分发引起较大的网络流量和cpu负载

  • 名称冲突:无法保证主机名称的唯一性，同名主机添加导致服务故障

  • 时效性:分发靠人工上传，时效性太差

2.1.2 使用域名系统

关于域名空间:

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

image-20230610095201581

域名报文结构

image-20230610095255770

2.1.3 域名购买与配置迁移

去一些云服务商进行购买，并且进行实名认证并备案

2.1.4 如何开放外部用户访问

如何建设外部网站，提升公司外部影响力？

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

image-20230610095512361

2.2 自建DNS服务器

重点学习一下

2.2.1 问题背景

  • 内网域名的解析也得出公网去获取，效率低下
  • 外部用户看到内网ip 地址，容易被hacker攻击
  • 云厂商权威DNS容易出故障，影响用户体验
  • 持续扩大公司品牌技术影响力，使用自己的DNS系统

从公有云托管 -> 构建自己的DNS系统

2.2.2 DNS查询过程

image-20230610095753040

2.2.3 DNS记录类型

  • A/AAAA:IP指向记录，用于指向IP，前者为IPv4记录，后者为 IPv6记录
  • CNAME︰别名记录，配置值为别名或主机名，客户端根据别名继续解析以提取P地址
  • TXT:文本记录，购买证书时需要.验证控制权
  • MX:邮件交换记录，用于指向邮件交换服务器
  • NS:解析服务器记录，用于指定哪台服务器对于该域名解析
  • SOA记录:起始授权机构记录，每个zone有且仅有唯一的一条SOA记录，SOA是描述zone属性以及主要权威服务器的记录

image-20230610100041837

image-20230610100049132

2.2.4 权威DNS系统架构

思考： 站在企业角度思考，我们需要的是哪种DNS服务器？

权威DNS、LocalDNS（可选）

常见的开源DNS：bind、nsd、knot、coredns

DNS Query DNS Response DNS Update DNS Notify DNS XFR

image-20230610100255738

2.2.5 权威DNS系统架构 流程图

image-20230610100355326

2.3 接入HTTPS 协议

2.3.1 问题背景

页面出现白页/出现某些奇怪的东西

返回了403的页面

搜索不了东西

搜索问题带了小尾巴,页面总要闪几次页面弹窗广告

搜索个汽车就有人给我打电话推销4s店和保险什么的

==HTTP明文传输，弊端越来越明显==

升级https

image-20230610100603984

2.3.2 对称加密和非对称加密

常见的加密算法：

对称加密：一份秘钥

image-20230610100709587

但对称加密需要在传输前先传输秘钥

非对称加密：公钥和私钥

image-20230610100803738

即使在第三方获取了 公钥和加密后的内容，没有私钥他也无法的得知

2.3.3 SSL的通信过程

client random

server random

premaster secret

加密算法协商

----- > 对称秘钥session key

image-20230610101025851

2.3.4 证书链

公钥确定是可信的吗？ 会不会被劫持？

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

Client收到会仍然需要验签:

  • 是否是可信机构颁布

  • 域名是否与实际访问一致

  • 检查数字签名是否一致

  • 检查证书的有效期

  • 检查证书的撤回状态

image-20230610101224613

服务器在对证书的内容进行信息内容计算的时候会得到一个指纹，然后再用证书私钥对证书进行加密，

得到数字签名，会把数字证书连同上级CA公钥一统发往客户端

客户端收到后会用上级CA公钥解密。

image-20230610101432484

数字签名

image-20230610101441610

上级CA公钥

2.4 接入全站加速

2.4.1 问题背景

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

image-20230610101621315

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

响应慢。卡顿

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

2.4.2 解决方案

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

2.4.3 静态加速CDN

image-20230610101912144

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

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

  • 减轻了各省的出口带宽压力

  • 优化了网上热点内容的分布

2.4.4 动态加速DCDN

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

image

2.4.5 DCDN 原理

image-20230610102119279

2.4.6 使用全站加速

请区分下列场景使用的加速类型 1、用户首次登录抖音，注册用户名手机号等用户信息 --- 动态加速DCDN 2、抖音用户点开某个特定的短视频加载后观看 --- 静态加速CDN 3、用户打开头条官网进行网页浏览 --- 静态加速CDN+动态加速DCDN

2.5 4层负载均衡

2.5.1 问题背景

提问： 在运营商处租用的100.1.2.3的公网IP，如何在企业内部使用最合理?

现状:直接找一个物理机，ifconfig将网卡配上这个IP，起server监听即可

应用多，起多个server监听不同的端口即可 租多个公网ip(数量有限)

怎样尽可能充分的利用和管理有限的公网IP资源?

2.5.2 什么是4层负载均衡

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

三个主要功能

解耦vip和rs

NAT

防攻击:syn proxy

image

2.5.3 常见的调度算法原理

  • RR轮询: Round Robin，将所有的请求平均分配给每个真实服务器RS

  • 加权RR轮询:给每个后端服务器一个权值比例，将请求按照比例分配

  • 最小连接:把新的连接请求分配到当前连接数最小的服务器

  • 五元组hash:根据sip、sport、proto、dip、dport对静态分配的服务器做散列取模

    缺点:当后端某个服务器故障后，所有连接都重新计算，影响整个hash 环

  • 一致性hash:只影响故障服务器上的连接session，其余服务器上的连接不受影响

2.5.4 常见的实现方式 FULLNAT

提问:RS怎么知道真实的CIP? 回答:通过TCP option字段传递然后通过特殊的内核模块反解

image (1)

2.5.5 4层负载均衡特点

  • 大部分都是通过dpdk 技术实现，技术成熟，大厂都在用
  • 纯用户态协议栈， kernel bypass，消除协议栈瓶颈
  • 无缓存，零拷贝，大页内存（减少cache miss)
  • 仅针对4层数据包转发，小包转发可达到限速，可承受高cps

image (2)

2.6 7层负载均衡

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层反向代理。

image-20230610105619420

  • 模块化设计，较好的扩展性和可靠性
  • 基于master/worker 架构设计
  • 支持热部署;可在线升级
  • 不停机更新配置文件、更换日志文件、更新服务器二进制
  • 较低的内存消耗:1万个keep-alive连接模式下的非活动连接仅消耗2.5M内存
  • 事件驱动:异步非阻塞模型、支持aio,mmap (内存映射)

2.6.3 Nginx和Apache 性能对比

image (3)

image (4)

2.6.4 Nginx 反向代理示意图

代理服务器功能

  • Keepalive访问日志
  • url rewrite重写
  • 路径别名
  • 基于ip 的用户的访问控制
  • 限速及并发连接数控制

image

2.6.7 异步非阻塞

传统服务器: 一个进程/线程处理一个连接/请求阻塞模型、依赖OS 实现并发 Nginx: 一个进程/线程处理多个连接/请求异步非阻塞模型、减少OS进程切换

image (5)

2.6.8 Nginx 简单调优

image (6)

别让OS限制了Nginx的性能

优化内核网络参数

fs.filemax= 999999
Tony 8323
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_keepalive_time = 600net.ipv4.tcp_fin_timeout = 30
Tony 8323
net.ipv4.tcp_max_tw_buckets = 5000
net.ipv4.ip_local_port_range =1024 61000net.ipv4.tcp_max_syn.backlog=1024
net.ipv4.tcp_syncookies = 1

提升CPU使用效率

image (7)

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

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

减少CPU开销 multi_accept允许worker同时接受新连接accept_mutex解决惊群问题 reuseport 监听同端口,内核负载均衡

提升网络效率

image (8)

连接复用 减少upstream建连

使用Cache 超时时间对业务的影响 gzip压缩 会增加cpu开销,需平衡使用 开启proxy_buffering 谨慎设置proxy_buffer 大小,磁盘io读写

2.6.10 使用7层负载均衡

image (9)

总结

再看接入架构

image (9)

课程回顾

image (10)

image-20230610110806220

avatar
文章
阅读
粉丝