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

doris_dan
97 阅读5分钟

这是我参与「第三届青训营 -后端场」笔记创作活动的的第6篇笔记」

image.png

网络接入

问题引入

  • 浏览器输入网址域名到网页加载出来，都经历了哪些过程？
    • 域名解析DNS
    • tcp建连（三次握手）
    • SSL握手 （https加密通信）TLS
    • HTTP请求
  • 浏览器抓包（根源或本质？输入的url）其他加载出来的是渲染需要

字节接入框架

  • 一个报文的生命周期（10步）

image.png

具体分析

域名系统

  • Host管理 /etc/hosts，诸多问题：流量负载、主机名称冲突、名称修改时效性差
  • 使用域名系统替换hosts文件 （域名树-根-〉顶级域-〉二级域-〉三级域-〉四级域）
    • 域名购买与配置迁移，域名备案、修改配置
  • 开放外部用户访问（建设外部网站），租赁外网ip

自建DNS服务器

  • DNS记录类型
  • 权威DNS系统架构，企业角度需要的是哪种DNS服务器？
    • 权威DNS、LocalDNS（可选）
    • 常见开源DNS：bind，nsd， knot，coredns

截屏2022-05-21 下午9.47.21.png

截屏2022-05-21 下午9.48.46.png

HTTPS协议

  • 问题背景
    • 页面弹窗、广告
    • http 明文传输 不安全
  • 对称加密与非对成加密
    • 握手阶段非对称加密（ADS）传输对称加密的密钥
    • 数据传输阶段，对称加密数据
    • 客户端、服务器 都有相同的状态
      • client random
      • server random
      • premaster secret
      • 加密算法协商——》对称密钥 session key
    • 公钥确定是可信的吗？是否会被劫持？
      • 证书链
      • server端发送是带签名的证书链
      • client 收到仍会验证
      • 服务端：【证书摘要-〉私钥加密-》指纹（数字签名）+上级CA公钥】-》客户端接收，使用CA公钥解谜-》生成证书摘要-进行比对。

接入全站加速

  • 问题背景：外网用户访问站点 可能会出现的问题
    • 源站容量滴，并发访问少，容易垮
    • 网络传输：丢包、劫持、mtu
    • 自选网络联络长，时延高 响应慢、卡顿
  • 解决方案
    • 源站容量： 增加后端机器扩容，静态内容，使用静态加速缓存
    • 网络传输：动态加速DCDN
    • 全站加速：静态加速+动态加速
  • 静态加速 CDN
    • 针对静态文件传输（图片、视频、文件等），网络优化方式？
      • 缓存，缓存到CDN节点上，不用请求源站了
      • 解决服务器端的第一公里问题
      • 缓解甚至消除了不同运营商之间互联的瓶颈造成的影响
      • 减轻了各省的出口带宽压力
      • 优化了网上热点内容的分布，热点内容缓存在了靠近客户端的CDN节点上。
  • 动态加速DCDN
    • 针对POST等非静态请求等不能在用户边缘缓存的业务，基于智能选路技术，从众多回源路线中择优选择一条线路进行传输。
  • 全站加速

    • 截屏2022-05-21 下午11.11.47.png

    • 截屏2022-05-21 下午11.12.28.png

四层负载均衡

  • 工作在OSI的4层和7层？？
  • 一个物理机-》配一个ip，多个应用，多个server监听不同端口，容灾问题：一个server由于操作不当挂，全挂
  • 组多个公网IP-数量有限

是什么

避免了把物理机的ip暴露在公网上 截屏2022-05-21 下午11.18.00.png

常用的负载均衡调度算法

截屏2022-05-21 下午11.19.47.png

常见实现方式

  • FULLNAT

截屏2022-05-21 下午11.21.37.png

截屏2022-05-21 下午11.22.13.png

截屏2022-05-21 下午11.23.13.png

七层负载均衡

截屏2022-05-21 下午11.24.36.png

截屏2022-05-21 下午11.25.50.png

应用层网关 截屏2022-05-21 下午11.28.59.png

四层和七层负载均衡的对比

  • 四层即运输层，就是基于 IP + 端口的负载均衡；

  • 七层即应用层，就是基于 URL 等应用层信息的负载均衡； 还有基于 MAC 地址的二层负载均衡和基于 IP 地址的三层负载均衡。

  • 二层负载均衡会通过一个虚拟 MAC 地址接收请求，然后再分配到真实的 MAC 地址

  • 三层负载均衡会通过一个虚拟 IP 地址接收请求，然后再分配到真实的 IP 地址；

  • 四层通过虚拟 IP + 端口接收请求，然后再分配到真实的服务器

  • 七层通过虚拟的 URL 或主机名接收请求，然后再分配到真实的服务器。

所谓的四到七层负载均衡，就是在对后台的服务器进行负载均衡时，依据四层的信息或七层的信息来决定怎么样转发流量。

所谓的四到七层负载均衡，就是在对后台的服务器进行负载均衡时，依据四层的信息或七层的信息来决定怎么样转发流量。

根据不同的信息(不同层决定不同的划分粒度)决定选择哪台服务器处理

比如四层的负载均衡，就是通过发布三层的 IP 地址（VIP），然后加四层的端口号,如[ip:端口号]，来决定哪些流量需要做负载均衡， 对需要处理的流量进行 NAT 处理，转发至后台服务器，并记录下这个 TCP 或者 UDP 的流量是由哪台服务器处理的， 后续这个连接的所有流量都同样转发到同一台服务器处理。

七层的负载均衡，就是在四层的基础上（没有四层是绝对不可能有七层的），再考虑应用层的特征如[ip：端口号：URL等]， 比如同一个 Web 服务器的负载均衡，除了根据 VIP 加 80 端口辨别是否需要处理的流量， 还可根据七层的 URL、浏览器类别、语言来决定是否要进行负载均衡。

avatar
文章
阅读
粉丝