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

氧烷
261 阅读14分钟

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

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

写在前面

本手册在开讲前会提前发放给用户，意在让学员提前学习接入依赖的基本组件都有哪些以及相关的有名词；因为此次课程是偏实践性质的课程，故会让学员提前了解和熟悉组件工具的使用；

因为大部分的接入都需要有网络等底层基础设施的支持，而此次课程由于学员数量多，资源申请以及管理都比较麻烦，故会尽可能的让同学们使用本地网络去模拟实际的接入过程，有些组件例如全站加速由于缺乏实际的基础设施难以去模拟故会跳过。

一、专有名词

  • 权威DNS：保存了相应域名的权威信息。权威DNS即通俗上“这个域名我说了算”的服务器
  • LocalDNS：缓存+递归查询，运营商（集团网）部署的本地DNS服务器，直接接受网内客户端请求
  • 根DNS服务器：全球有13台，LocalDNS未命中缓存查询的起点服务器，其公网地址具体可参考www.iana.org/domains/roo…
  • DNS Update：DNS主服务器master接受外部的变更指令
  • DNS Notify：DNS主服务器master接受变更命令后，会自增自身的serial号，同时将变更的serial号告知从服务器slave
  • DNS IXFR：DNS从服务器slave以增量的形式向master要求获取本次变更的内容
  • DNS AXFR：DNS从服务器slave以全量的形式向master要求获取当前的全量数据
  • 对称加密：使用相同的秘钥来加密传输内容，一端加密后，对端收到数据会用相同的秘钥来解密
  • 非对称加密：如果用公钥对数据进行加密，只有用对应的私钥才能解密；如果用私钥对数据进行加密，那么只有用对应的公钥才能解密。
  • 静态加速：针对视频、图片等不变的内容，将其缓存在靠近用户的边缘节点，缓存预热后用户直接从边缘获取，从而加速访问速度；
  • 动态加速DCDN：针对API类返回值不同的请求，通过特殊的网络优化方式（路由优化、传输优化）等技术加速其达到源站的速度。
  • VIP：虚拟IP，一般作为四层反向代理的入口，client看起来一直在与VIP交互
  • RS：Real Server，VIP后实际承受client请求的服务，可能是物理机/虚拟机/容器POD
  • DPDK：Data Plane Development Kit，主要用户4层负载均衡，用于转发的网络加速领域比较多；以极大提高网卡报文的处理性能和吞吐量，提高数据平面应用程序的工作效率
  • SSL/TLS：(Secure Sockets Layer 安全套接字协议),及其继任者传输层安全（Transport Layer Security，TLS）是为网络通信提供安全及数据完整性的一种安全协议
  • DPDK：Data Plane Development Kit，一种从数据面去加速网络报文处理的工具，可以极大提高数据处理性能和吞吐量，提高数据平面应用程序的工作效率

二、企业接入升级打怪之路

2.1 域名系统

2.1.1 Host管理

example公司 主机表 Host - > ip 映射

随着example公司业务规模和员工数量的增长，使用该方式面临诸多问题:

  • 流量和负载:用户规模指数级增长，文件大小越来越大，统一分发引起较大的网络流量和cpu负载
  • 名称冲突:无法保证主机名称的唯一性，同名主机添加导致服务故障
  • 时效性，分发靠人工上传，时效性太差

2.1.2 使用域名系统

使用域名系统替换hosts文件

关于域名空间:

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

顶级域 gTLD: general Top-level Domains: gov政府.edu教育.com商业.mil军事.org非盈利组织

2.1.3 域名购买与配置

域名备案:防止在网上从事非法的网站经营活动，打击不良互联网信息的传播，一般在云厂商处即可进行实名认证并备案

修改配置:

  • 清空/etc/hosts
  • 配置/etc/resolv.conf中nameservers为公共DNS
  • 迁移原配置，通过控制台添加解析记录即可

2.1.4 如何开放外部用户访问

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

方案:租赁-个外网ip,专用于外部用户访问]户网站，将www.example.com解析到外网ip100.1.2.3,将该ip绑定到-台物理机上， 并发布公网route,用于外部用户访问。

2.2 自建DNS服务器

2.2.1 问题背景

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

2.2.2 DNS查询过程

image-20220521121246160

2.2.3 DNS记录类型

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

2.2.4 权威DNS系统架构

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

答案:权威DNS、L ocalDNS (可选)

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

2.2.5 权威DNS系统架构

image-20220521122152916

2.3 HTTPS接入

2.3.1 问题背景

  • 页面出现白页/出现某些奇怪的东西
  • 返回了403的页面
  • 搜索不了东西
  • 搜索问题带了小尾巴，页面总要闪几次
  • 页面弹窗广告
  • 搜索个汽车就有人给我打电话推销4s店和保险什么的

HTTP明文传输,危险!

2.3.2 对称加密和非对称加密

常见加密算法

对称加密: 一份秘钥

非对称加密: 公钥和私钥

2.3.3 SSL通信过程

image-20220521122634862

2.3.4 证书链

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

Client收到会仍然需要验证:

  • 是否是可信机构颁布
  • 域名是否与实际访问一致
  • 检查数字签名是否一致
  • 检查证书的有效期
  • 检查证书的撤回状态

2.3.5 使用https

安全了

2.4 接入全站加速

2.4.1 问题背景

外网用户访问站点,一定是一帆风顺的嘛?

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

2.4.2 解决方案

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

2.4.3 静态加速 CDN

网络优化方式:

  • 缓存 – 智能调度DNS

优势:

  • 解决服务器端“第一公里”问题
  • 缓解甚至消除了不同运营商之间互联的瓶颈造成的影响
  • 减轻了各省的出口带宽压力
  • 优化了网上热点内容的分布

2.4.4 动态加速 DCDN

智能选路技术

2.4.5 DCDN原理

RTT示例:

  • 用户到核心: 35ms
  • 用户到边缘: 20ms
  • 边缘到汇聚: 10ms
  • 汇聚到核心: 10ms

image-20220521123619775

2.4.6 使用全站加速

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

image-20220521124057424

2.5 四层负载均衡

2.5.1问题背景

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

  • 现状:直接找-一个物理机，ifconfig将网卡配 上这个IP，起server监 听即可
  • 应用多，起多个server监听不同的端口即可
  • 租多个公网ip(数量有限)

2.5.2 什么是四层负载均衡

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

image-20220521124243797

三个主要功能:

  1. 解耦 vip和 rs
  2. NAT
  3. 防攻击: syn proxy

2.5.3 常见调度算法

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

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

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

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

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

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

2.5.4 常见的实现方式FULLNAT

image-20220521124706240

提问: RS怎么知道真实的CIP?

回答:通过TCP option字段传递然后通过特殊的内核模块反解

2.5.5 4层负载均衡特点

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

2.5.6 使用四层负载均衡

image-20220521124851424

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 Nignx简介

最灵活的高性能WEB SERVER ,应用最广的7层反向代理

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

2.6.3 Nginx和 Apache性能对比

image-20220521125213835

2.6.4 Nginx反向代理示意图

image-20220521125457471

代理服务器功能:

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

2.6.5 Nginx内部架构

image-20220521125516311

2.6.6 事件驱动模型

image-20220521125919879

2.6.7 异步非阻塞

传统服务器:

  • 一个进程/线程处理一个连接/请求
  • 阻塞模型、依赖OS实现并发

Nginx:

  • 一个进程/线程处理多个连接/请求异步非阻塞模型、减少OS进程切换

2.6.8 Nginx简单调优

image-20220521130033721

2.6.9 提升网络效率

  • 连接复用

    • 减少upstr eam建连

  • 使用Cache

    • 超时时间对业务的影响

  • gzip压缩

    • 会增加cpu开销，需平衡使用

  • 开启proxy_ buffer ing

    • 谨慎设置proxy_ buffer 大小，磁盘io读写

2.6.10 使用7层负载均衡

三、实操环节

实验工具准备

基础条件：使用Linux/MacOS操作系统，windows可以安装虚拟机，Ubuntu或者Centos都行

开源软件：bind9、nginx、ngrok(ngrok.com/download)

备注：bind9和nginx使用apt-get或者yum命令安装即可

3.1 后端准备

DNS服务器搭建

准备一个网站，这里html等内容的建设步骤不在本次分享范围内，我们就以最简单的helloworld为例；

http访问监听的IP端口就返回‘Hello, World!’

img

3.2 host劫持实验

一般来说，操作系统会优先查看本地/etc/hosts目录去匹配相应的IP，而不是再去查询DNS系统，使用此类方式可以在本地将域名劫持到特定的ip上，以用来调试目的

在/etc/hosts文件追加一行：’{$劫持的ip} www.toutiao.com’ 此处以 www.toutiao.com 举例

img

3.3 权威DNS及LocalDNS搭建实验

这里拟采用著名的开源软件bind9作为DNS服务的server

3.3.1 权威侧zone文件准备

新建zone文件/etc/bind/example.com.zone，并编辑为以下内容

$TTL 10M
@   IN    SOA    ns1.example.com    admin.example.com. (
        0       ; serial
        1D      ; refresh
        1H      ; retry
        1W      ; expire
        3H )    ; minimum
​
@    IN    NS   ns1.example.com.
; 这里ns1主机的ip地址可以换成本机地址
ns1        A    10.227.89.58
; 这里www主机的ip地址可以换成本机地址
www        A    10.227.89.58
复制代码

3.3.2 bind9配置准备

直接编辑/etc/bind/named.conf即可，配置参考如下：

logging {
 channel default_log {
        #这里注意提前创建log目录
        file "/var/log/named/named.log" versions 10 size 200m;
        severity dynamic;
        print-category yes;
        print-severity yes;
        print-time yes;
    };
    channel query_log {
        file "/var/log/named/query.log" versions 10 size 200m;
        severity dynamic;
        print-category yes;
        print-severity yes;
        print-time yes;
    };
    channel resolver_log {
        file "/var/log/named/resolver.log" versions 10 size 200m;
        severity dynamic;
        print-category yes;
        print-severity yes;
        print-time yes;
    };
    category default {default_log;};
    category queries {query_log;};
    category query-errors {query_log;};
    category resolver {resolver_log;};
};
​
options {
    #这里的ip地址可以换成本机地址
    listen-on port 53 { 10.227.89.58; };
    directory "/etc/bind";
    dnssec-validation no;
    #支持递归查询
    recursion yes;
    #转发到公共DNS优先，而不是自己去迭代查询，节省网络IO资源消耗
    forward first;
    forwarders {
        223.5.5.5;
        223.6.6.6;
    };
    allow-query { any; };
};
​
zone "example.com" {
    type master;
    file "example.com.zone";
};
复制代码

3.3.3 使用dig命令验证

  • 验证权威DNS服务命令：dig @10.227.89.58 www.example.com （10.227.89.58可以换成上面监听的本机地址），命中本地托管的zone example.com，直接吐数据

img

DNS请求日志见query.log

img

  • 验证LocalDNS服务

dig @10.227.89.58 www.toutiao.com （10.227.89.58可以换成上面监听的本机地址），未命中本地托管的zone数据，直接向任一forwarders（公共DNS）请求，获取结果后缓存到本地

img

DNS 请求日志见 query.log

img

3.4 四层负载均衡实验

这里没有选择使用专业的LVS+keepalived作为4层转发的样例，这一层对于个人站点搭建来说是可有可无的，学员们需要有这一层概念即可，此次实验选择nginx的stream模块作为4层负载均衡实验的基础软件。

实验目的

  1. 将到达本机的53端口的udp报文转发到DNS服务器
  2. 将到达本机的80端口的tcp报文转发到自己准备的hello_world后端服务上。

3.4.1 修改DNS服务监听的端口

因为我们都是在同一台Linux机器上进行实验，不能监听相同的端口，故这里我们修改下DNS服务监听的端口，这里我们将53端口改成其他端口，从而腾出53端口给VIP（这里VIP等于本机IP）使用。

options {
    #这里的ip地址可以换成本机地址
    listen-on port 8053 { 10.227.89.58; };
    directory "/etc/bind";
    ......
};

3.4.2 nginx stream配置准备

编辑/etc/nginx/nginx.conf，新增stream模块

ps:若nginx未安装stream模块，则自行添加stream模块或者重新编译nginx即可。

#四层转发，tcp/udp协议转发
stream {
    log_format proxy '$remote_addr [$time_local] '
                 '$protocol $status $bytes_sent $bytes_received '
                 '$session_time "$upstream_addr" '
                 '"$upstream_bytes_sent" "$upstream_bytes_received" "$upstream_connect_time"';
​
    access_log  /var/log/nginx/access.log  proxy;
    open_log_file_cache off;
​
    upstream dns_proxy {
        server 10.227.89.58:8053;
    }
    upstream hello_proxy {
        server 10.227.89.58:8080;
    }
    server {
        listen 53 udp reuseport;
        proxy_pass dns_proxy;
    }
    server {
        listen 80;
        proxy_connect_timeout 1s;
        proxy_timeout 300s;
        proxy_pass hello_proxy;
    }
}

3.4.3 流量转发验证

  1. UDP流量

此处dig的验证效果和4.3.3表面上看似无异，但是4层流量是经过nginx stream模块转发的，这里我们可以查询转发日志查询UDP流量转发详情。

img

  1. TCP流量

访问效果和直接访问后端无异

img

转发日志如下：

img

3.5 七层负载均衡实验

这里需要使用nginx的http module在四层负载均衡和后端服务之间添加七层负载均衡服务，这里以880端口为例，修改如下： 将四层负载均衡的后端设置为7层监控的端口880

upstream hello_proxy {
        server 10.227.89.58:880;
    }

http模块配置如下：

http {
    include       mime.types;
    default_type  application/octet-stream;
​
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';
    access_log  /var/log/nginx/access.log  main;
    sendfile        on;
    keepalive_timeout  65;
    upstream backend {
       server 10.227.89.58:8080;
    }
    server {
        listen       880;
        server_name  www.example.com;
        location / {
            proxy_pass http://backend;
             proxy_set_header HOST $host;
             proxy_connect_timeout 60;
             proxy_send_timeout 60;
             proxy_read_timeout 60;
        }
    }
}

访问本地服务80端口现象与上相同，nginx四七层转发日志如下：

img

img

3.6 SSL自签证书实验

下面我们来支持使用https协议访问我们的后端，SSL卸载的任务一般落在七层负载均衡这一层。

下载自签证书生成工具

3.6.1 使用工具签发自定义证书链

  • 签发根证书 命令：./certmaker -gen root -cn “Test Root Ca” 结果：生成文件为根证书私钥rootCA.key和证书文件rootCA.pem
  • 签发中间CA证书 命令：./certmaker -gen intermediate -cn “TestIntermediateCA” -issuer rootCA.pem -issuerkey rootCA.key 结果：生成中间CA证书私钥TestIntermediateCA.key和证书文件TestIntermediateCA.pem
  • 签发域名证书 命令：./certmaker -gen cert -cn “*.example.com” -issuer TestIntermediateCA.pem -issuerkey TestIntermediateCA.key 结果：生成域名证书私钥 .example.com.key和证书文件.example.com.pem

3.6.2 nginx配置准备

  • 增加443端口转发四层配置
upstream hello_proxy_ssl {
    server 10.227.89.58:8443;
}
server {
    listen 443;
    proxy_connect_timeout 1s;
    proxy_timeout 300s;
    proxy_pass hello_proxy_ssl;
}
  • server块增加ssl配置
server {
    listen  880;
    listen  8443 ssl;
    server_name  www.example.com;
    # 引用中间CA证书
    ssl_certificate      /etc/nginx/ssl/TestIntermediateCA.pem;
    ssl_certificate_key  /etc/nginx/ssl/TestIntermediateCA.key;
    # 引用域名证书
    ssl_certificate      /etc/nginx/ssl/_.example.com.pem;
    ssl_certificate_key  /etc/nginx/ssl/_.example.com.key;
    # 自动跳转到HTTPS
    if ($server_port = 880) {
        rewrite ^(.*)$ https://$host$1 permanent;
    }
    ...
}

3.6.3 访问https

  • 443端口四七层转发日志：

img

img

  • 浏览器使用https协议访问：

img

3.7 将本地服务开放外网访问

有的同学可能觉得部署这一套可能太复杂，在项目前期有没有什么比较简单有效的方法将我本机的服务开放在公网供别人访问。这里简单介绍一种成熟的的解决方案。

项目地址：ngrok.com/

命令：./ngrok http 8080(将本地8080端口开放到公网)

服务状态：

img

访问工具提供的域名：

img

GitHub仓库 （必须）

github.com/chanyean/yo…

\

avatar
文章
阅读
粉丝