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

夹心没有饼干
77 阅读11分钟

1. 接入问题

经典问题：浏览器输入网站域名www.toutiao.com到网页加载出来，都经历了哪些过程？

  1. DNS域名解析
  2. TCP建连
  3. SSL/TLS握手
  4. 等等

浏览器抓包的根源或者本质是什么？为什么我只是想访问这个主页，确出现了那么多请求？

  1. 我们只需要关注首次请求即可，其他请求是为了渲染最终的页面。
  2. DNS->TCP->TLS->HTTP请求的发送

字节接入框架：

image-20230802200911014.png

2. 使用域名系统

Host管理：example公司建立之初有很多站点，办公、文档、员工认证、人事等。通过Host主机表管理Host到ip的映射，网络运维人员使用主机表管理Host到ip的映射，网络的管理人员维护主配置，员工通过FTP协议拉取主配置，达到访问各个系统的目的。但因为员工越来越多，公司规模越来越大，导致流量和负载不支持，无法保证主机名称的唯一性，同名主机添加导致服务故障。分发时靠人工上传，时效性太差。

image-20230802201126658.png

通过使用域名系统来替换Hosts文件。

关于域名空间：

  • 域名空间被组织成树型结构
  • 域名空间通过划分zone的方式进行分层授权管理
  • 全球公共域名空间仅对应一棵树
  • 根域名服务器：查询起点
  • 域名组成格式：[a-zA-Z0-9_-]，以点划分label。
  • 顶级域名gTLD：general Top-level Domains：gov政府、.edu教育、.com商业、.mil军事、.org非盈利组织

域名报文格式：一串二进制数字。

3. 自建DNS服务器

问题：

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

DNS查询过程：先从网络客户端进入本地DNS服务器查找是否有改域名的缓存记录。如果没有，进入到DNS根服务器(13台根服务器)查找，然后返回本地DNS服务器。如果找不到，再进入.com域服务器(顶级域名服务器)进行查找，然后返回结果到本地DNS服务器。如果找不到，再进入163.com域服务器(权威域名服务器)查询该域名对应的IP地址，返回本地DNS服务器，再返回到网络客户端。

  • LocalDNS：缓存+递归查询，运营商（集团网）部署的本地DNS服务器，直接接受网内客户端请求。
  • 根DNS：全球有13台，LocalDNS未命中缓存查询的起点服务器。
  • 顶级DNS：
  • 权威DNS：保存了相应域名的权威信息。权威DNS即通俗上“这个域名我说了算”的服务器。

DNS记录类型：

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

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

答案：权威 DNS、LocalDNS (可选)

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

4. HTTPS协议

问题背景：

  1. 页面出现白页
  2. 返回了403
  3. 搜索不了东西
  4. 页面弹窗等

问题原因是某些厂商对明文的HTTP进行了一些响应抓取，所以HTTP明文传输，弊端越来越明显，然后就诞生了HTTPS，进行加密。

对称加密和非对称加密：

  • 对称加密：使用相同的秘钥来加密传输内容，一端加密后，对端收到数据会用相同的秘钥来解密。
  • 非对称加密：如果用公钥对数据进行加密，只有用对应的私钥才能解密；如果用私钥对数据进行加密，那么只有用对应的公钥才能解密。客户端向服务器发起请求，服务器将公钥返回给客户端，客户端生成Key，通过拿到的公钥对Key进行加密并返还给服务端，服务端再用私钥进行解密。随后，双方使用Key进行对称加密传输。

image-20230802212020677.png

SSL/TLS：SSL（Secure Sockets Layer，安全套接字协议），及其继任者TLS（Transport Layer Security，传输层安全协议）是为网络通信提供安全及数据完整性的一种安全协议。

SSL通信使用非对称加密：

  1. Client向server端发送client hello消息，包含客户端支持的SSL版本、加密算法、client random
  2. server收到后又发送client hello给client，包含数字证书、server random以及服务器所选择的加密算法
  3. client对server发来的公钥或者证书进行验证，保证对方合法身份
  4. client对server发送预备主密钥premaster secret，通过公钥加密，要服务器的私钥解密
  5. 用对称加密算法，算出对称密钥session key，双方使用session key进行数据传输

image-20230802212053622.png

数字证书：数字证书确定是可信的吗？会不会被劫持？

  1. 服务端发送的是带签名的数字证书
  2. 客户端收到后会进行验证：是否是可信机构颁布？域名是否与实际访问的一致？检查数字签名是否一致？检查证书的有效期？检查证书的撤回状态？

验证签名的过程：服务端根据证书计算摘要信息（指纹），用证书私钥给摘要信息（指纹）加密得出数字签名，服务端将数字签名和上级CA的公钥一起发给客户端，客户端用上级CA的公钥来解密数字签名得到摘要信息（指纹），此时客户端会使用相同加密算法计算摘要信息的签名，如果一致说明没有篡改。

上级CA的公钥是可信的吗？上级CA的公钥用根CA验证，根CA自己验证自己。？？？？？

公钥和证书是怎么生成的？一个HTTPS服务器首先创建他自己的密钥对（key pair），包含公钥和私钥。通过网络把公钥送到CA中心，公钥中包含了个人鉴别信息（他的名字、地址、所用设备的序列号等等）。CA中心创建并签署一个包含公钥及个人信息的证书，从而保证密钥的确实性。使用该证书的人可以通过检验CA中心的签名（检验CA签名需要CA的公钥）来验证证书的确实性。

5. 全站加速

问题背景：

  1. 外网用户访问站点，一定是一帆风顺的吗？可能出现的问题有哪些？
  2. 比如说源站(网站)的容量低，可承载的并发请求数低，容易被打垮。(有点类似于DDos)
  3. 报文经过的网络设备越多，出问题的概率越大，丢包、劫持、mtu问题。
  4. 自主选路网络链路长，时延比较高。
  5. 总结就是响应慢、卡顿。

解决方案：

  1. 如果是源站容量问题，可以增加后端机器扩容；如果是静态内容，可以使用静态加速缓存
  2. 网络传输问题就，使用动态加速DCDN
  3. 全站加速 = 静态加速 + 动态加速

静态加速CDN：

  • 针对视频、图片等不变的内容，将其缓存在靠近用户的边缘节点，缓存预热后用户直接从边缘获取，从而加速访问速度。

  • 原理：从源点获取的就不是DNS解析的结果，而是cdn节点解析的结果。cdn节点使用的是自动调取DNS，它是根据一些算法和策略将一些比较合适的cdn节点或IP地址返回给LocalDNS，最终返回客户端。同时cdn会发起一次请求，并且将此作为缓存。

  • 缩短了网络的链路吗，缓解了不同运营商互相访问的成本，减轻了各省的出口带宽压力，优化网络热点内容的分布。

动态加速 DCDN：针对API类返回值不同的请求，通过特殊的网络优化方式（路由优化、传输优化）等技术加速其达到源站的速度。

image-20230802212907308.png

6. 四层负载均衡

如果在运营商处租用了一个100.1.2.3的公网IP，如何在企业内部使用最合理？

现状：直接找一个物理机，Ifconfig将网卡配上这个IP，起server监听即可。应用越多，就要起多个server监听不同的端口。操作复杂，容易误伤。

问题：对有限ip地址的使用。

  • VIP：虚拟IP，一般作为四层反向代理的入口，client看起来一直在与VIP交互。
  • RS：Real Server，VIP后实际承受client请求的服务，可能是物理机/虚拟机/容器POD。

什么是四层负载均衡？基于IP+端口，利用某种算法将报文转发给某个后端服务器，实现负载均衡地落到后端服务器上。基于OSI七层模型进行划分的。

  • 解耦vip和rs，应用服务不局限于某一台物理机，可以灵活指向后端，使后台容量可以灵活扩缩容。
  • NAT，把请求转发给后端，作为流量代理（反向代理）。
  • 防攻击：syn proxy，避免直接将公网IP暴露出来，负载均衡进行拦截。

常见的调度算法原理：

  1. RR轮询：将所有请求平均分配给每个真实服务器RS
  2. 加权RR轮询：给每个后端服务器一个权值比例，将请求按照比例分配
  3. 最小连接：将新的连接请求分配到当前连接数最小的服务器
  4. 五元组hash：根据sip、sport、proto、dip、dport对静态分配的服务器做散列取模。缺点是当某个服务器故障后，所有连接都重新计算，影响整个hash环。
  5. 一致性hash：只影响故障服务器上的连接session，其余服务器上的连接不受影响。

最常见的实现方式FULLNAT：

image-20230802220407347.png

RS如何知道真实CIP？（场景：社交平台显示ip属地） 通过TCP option字段传递，然后通过特殊的内核模块反解。

4层负载均衡特点：

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

DPDK：Data Plane Development Kit，主要用户4层负载均衡，用于转发的网络加速领域比较多；以极大提高网卡报文的处理性能和吞吐量，提高数据平面应用程序的工作效率。

image-20230802220602226.png

7. 七层负载均衡

四层负载对100.1.2.3只能bind一个80端口，而有多个外部站点需要使用，该如何解决？换个问法，有一些7层的需求，该怎么做？

  1. SSL卸载，业务侧重是http服务，用户需要https访问
  2. 请求重定向：浏览器访问toutiao.com自动跳转www.toutiao.com
  3. 路由添加匹配策略：完全、前缀、正则
  4. Header编辑
  5. 跨域支持
  6. 协议支持：websocket、grpc、quic

Nginx简介：应用最广的7层反向代理

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

反向代理：

image-20230802221122507.png

Nginx内部架构：

image-20230802221306927.png

事件驱动模型：是Nginx效率提高的关键点，不需要一直监听，发生事件后将事件以及对应回调函数存入队列当中，然后线程从队列当中取出并执行对应模块。

image-20230802221606956.png

异步非阻塞，提高CPU使用率：

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

image-20230802221701511.png

8. 总结

image-20230802222754432.png

打到4层以后，再打到7层。

avatar
文章
阅读
粉丝