网络交互打开抖音互联网会发生什么
刷抖音时网络如何交互
网络接入
- 大致过程
- 互联网
- 全球有13个根服务器，其他网络厂商都需要与根服务器连接才能连接网络
- 网络厂商如中国移动、中国电信等，其他个人/组织向网络厂商购买网络连接服务即可接入网络
- 路由（网络层传输，通过IP地址）
- 同网段接入（通过mac地址转发，无需路由）
- 多个PC设备通过交换机/逻辑交换机连接
- 使用SDN（网络软件化）技术，把两个交换机连接的网络虚拟成同一个网络
- 不同网段接入（使用路由，查找对应IP地址，进行转发）
- 路由在实际网络中通常是对称的，但是在复杂的连接网中是不对称的，比如当主机A向主机B发包的途径有很多时，A->B和B->A的路由就不对称了。
- 路由通常情况下认为工作在IP层/网络层
- 路由表的内容：目标IP地址 | 下一跳IP地址
- 同网段接入（通过mac地址转发，无需路由）
- ARP协议——通过IP地址找到MAC地址（链路层寻址，通过MAC地址）
- 逻辑同网段才能发送ARP包
- 不同网段的查找需要通过中间路由，中间路由通过IP表不断查找最终找指定服务器IP地址，同网段中间路由发送ARP请求获取该服务器Mac，并将数据包发送给服务器
- ARP请求广播（目标MAC地址为255.255.255.255）；ARP应答单播（目标MACA地址为请求的MAC地址）
- 免费ARP，比如一个局域网内新增一个主机，不用请求会直接告知所有主机，防止新增主机的MAC地址与已有的主机MAC地址重复，所以会重新为新增主机重新分配一个MAC地址
- IP协议
- 产生原因：存在二层设备没有MAC地址的情况，为了统一，向上封装了一个IP地址，用于转发
- IP地址是连接互联网的设备的唯一标识
- IPv4已经不够了，解决方案：1）扩展IPv6；2）NAT
- NAT
- IP地址不够了，NAT的本质是通过修改IP地址和源端口达到IP地址复用的效果
- 流程如下
网络传输
- 数据包
- DNS域名解析
- 迭代查询
- 递归查询
- UDP
UDP协议很简单，UDP的数据包内容如下
缺点：不能保证可靠传输（是否丢包/出错）
- TCP
- 三次握手
- HTTP/HTTP1.1
- HTTP协议属于TCP通信的一种，只是细分出的一个更易懂（对于用户）的连接
- HTTP1.1相对于HTTP的优化：1）长连接；2）部分传输；3）HOST；4）缓存。。。。。。
- HTTPS
- HTTPS是HTTP的加密版本，HTTP传输容易被窃听，所以加了一层加密
- SSL/TSL握手
网络架构提质——刷抖音时又快又稳
网络提速
- HTTP2.0的优化：采用多路复用，提高传输效率，一次请求，并行传输（实际上有先后，但是无需等待前一个数据的响应）
- 多路复用：
- 一个TCP连接中，数据流串行发送（一个发完另一个立马接上），即为多路复用，相比于一个数据发送后，等到收到响应后才发第二个数据（1个RTT）更快
- 存在问题：TCP丢包——队头阻塞（如果其中一个包在传输过程中丢了，后面的包就会阻塞等待该包重传接收，此时多路复用也不管用，而且会造成资源浪费）
- QUIC/HTTP3.0
- QUIC/HTTP3.0 是对队头阻塞问题的解决
- QUIC/HTTP3.0 是在UDP协议进行了拓展，从而达到目的，原因是UDP协议比较简单，而且使用广泛，而TCP协议较为复杂，牵一发而动全身，而且一旦修改，所有使用该协议的设备很难简单的换掉协议
- QUIC/HTTP3.0 在Userspace态实现该功能，因为Kernel层实现意味着需要考虑到各个版本的操作系统的不同，较为复杂，加上现在有较多正在开发的OS系统，日后可能也需要实现，太过麻烦
- QUIC/HTTP3.0 天然实现了HTTPS的功能，0RTT传输
- QUIC/HTTP3.0 弱网优势，在弱网环境下容易丢包，而QUIC/HTTP3.0 主要就是解决了队头阻塞的问题（TCP丢包）
- 数据中心
- 分布图如下（核心机房是提供服务的核心服务器所在；边缘机房是转接核心机房/提供简单服务的服务器所在；POP接入连接了核心机房与外部网络）
- 同运营商访问
- 移动的访问移动的边缘机房；电信的访问电信的边缘机房。。。
- 原因：跨运营商网络很差
- 过程：通过解析访问的IP所属的运营商，转接入对应的边缘机房
- 静态资源（图片/视频）路径优化（CDN）
过程：如果有请求静态资源，则先在边缘机房的缓存中查找，没有就向上访问汇聚机房，再没有就请求核心机房，拿到数据后，边缘机房会将静态资源进行缓存，下一次访问，就直接从边缘机房的缓存中取相关的静态资源
- 动态API（播放/评论接口）路径优化（DSA）
过程：通过网络探测确定各机房的传输花销，构成一张表，然后通过算法确定最佳路径
网络稳定
- 容灾概念
- 故障发生
- 故障感知
- 自动切换
- 服务恢复
- 故障排查（没有容灾）
- 故障明确
- 故障止损
- 先止损再排查
- 降级止损/启动容灾系统
- 分段排查
- 客户端排查
- 服务端排查
- 中间链连排查
- 故障排查常用命令
- dig——查询DNS问题
- ping/talnet/nmap——查询三层/四层连通性
- Traceroute——排查中间链路
- iptables——IP表
- tcpdump——tcp抓包
- 故障预防
网络接入与企业级优化
网络接入
- 问题引入
- 经典面试问题：在浏览器中输入网站域名到网页加载出来，显示页面，都经历了哪些过程？
答：简略导入——域名解析、TCP建立连接、SSL握手等
- 探究其过程的方法
- 浏览器抓包（观察网络/network）
- wireshark抓包（DNS->TCP->TLS->HTTP包）
- 字节接入框架
企业级接入
以example公司为例，从企业的发展观察网络接入的不断优化
域名系统
- 域名系统的引入
初始公司小，使用Hosts主机表管理公司的主机，主机表中记录了公司内所有主机名（服务）与IP地址的映射
公司规模扩大，主机增多引发一系列问题
- 流量和负载：员工规模指数级增长，Host文件大小越来越大，所有的消息统一分发引起较大的网络流量和CPU负载（相当于部门的内部消息需要广播发出）
- 名称冲突：主机数量非常多，无法保证主机名称的唯一性，同名主机添加会导致服务故障
- 时效性：针对第一条我们可以知道，部门的内部消息需要广播发出显然是不合理的，但是如果要保证部门消息只发给本部门的员工，则需要靠人工上传，时效性极差
为了解决上述问题，引入了域名系统
- 域名系统介绍
- 域名系统是树状结构，每一级服务器都有各自的域名，每一级域名不能重名，不同级域名可重复，以 . 为分界，替代Host主机表存储
- 通常服务器主机名结构：（四级域名.）三级域名.二级域名权威域名.顶级域名，如
www.baidu.com、www.juejin.cn、www.hdu.edu.cn - 公共域名系统分级大致如下
- 根域名服务器全球有13台，是域名解析查询起点，存储了所有顶级域名服务器的IP地址与域名的映射表
- 顶级域名通常为特定组织对应特定域名，如com——商业；gov——政府；edu——教育。。。，顶级域名服务器存储了所有向它购买/申请的二级域名服务器IP地址与域名的映射表（每个域名服务器各有一张表）
- 域名购买与配置迁移
- 域名购买：example公司属于商业机构，应该向公有云厂商处购买二级域名example.com，如阿里、火山引擎等，也可以购买其他特定主机对应域名
- 域名备案：防止在网上从事非法的网站经营活动，打击不良互联网信息的传播，一般在云厂商处即可进行实名认证并备案
- 修改配置：
- 清空原有的/etc/hosts 主机表
- 配置/etc/resolv.conf中nameservers为公共DNS，内部主机自划分域名级
- 迁移原配置，通过控制台添加解析记录即可
- 开放外部用户访问
公司内网主机域名系统配置完成，公司面向外网建设外部网站，方案？
自建DNS服务器
- 问题引入——自定义域名系统：
- 域名系统非常好用，但是当公司内网的所有主机域名都向云厂商购买，那么每次解析也得去公网获取，效率低下
- 外部用户可以看到公司内网IP地址，容易被hacker攻击
- 云厂商权威DNS容易出故障，影响用户体验
- 不妨公司内部自定义DNS，其架设可以仿照上述域名系统设定，以公司域名example.com为自定义DNS系统的根域名服务器，以子公司/部门为域名分级命名
- 域名解析流程（迭代查询）——自定义域名查询流程
自定义的DNS系统可以仿照上述流程设计域名解析
- DNS记录类型及示例
- 企业选择自建DNS系统通常会选择 权威DNS
- 常见的开源DNS：bind、nsd、knot、coredns
- 常用DNS指令/请求
HTTPS协议
- 问题产生（HTTP明文传输 易篡改带来的问题）
- 页面出现百页/出现某些奇怪的东西
- 返回了403的页面
- 搜索不了东西
- 页面弹窗广告
- ······
- 常见加密
- 对称加密：同一个秘钥加解密
- 非对称加密：公钥加密，私钥解密，RSA
- SSL通信过程
- 证书链
针对Server端发送的证书链，Client端需要做以下验证
- 是否是可信机构颁布
- 域名是否与实际访问一致
- 检查数字签名是否一致
- 检查证书的有效期
- 检查证书的撤回状态
Server端获取证书链时，会将证书摘要（指纹）用私钥进行加密获得签名，然后把加密后的签名连同公钥一起发给Client，Client使用公钥解密签名，正常解密说明传输没有问题（证书主要作用就是确保传输的公钥可信），然后再使用公钥加密预主密钥
接入全站加速
- 问题引入
外网用户访问站点（网站）可能会出现以下问题
- 源站容量低，可承载的并发请求数低，容易被打垮
- 报文经过的网络设备越多，出问题的概率越大，丢包、劫持、MTU问题
- 自主选路网络链路长，时延高
- 全站加速=静态加速（CDN）+动态加速（DCDN）
- 源站容量问题——增加后端机器扩容；静态内容使用静态加速缓存
- 网络传输问题——动态加速
- 静态加速（CDN）
- 过程：Client通过DNS查询获得最近cdn节点IP地址，向其发起请求（静态资源），cdn节点若没有该缓存，则由cdn节点向源服务器发起请求，并将结果缓存，以便下一次使用；若有该缓存，则由cdn节点向Client发送数据
- 优点：
- 解决了服务器端的“第一公里”问题（请求的响应尽可能优化在靠近Client的节点上，缩短网络传输链路）
- 缓解甚至消除了不同运营商之间互联的瓶颈造成的影响（数据量较大时，在数据中心进行交换会很容易出问题？）
- 减轻了各省的出口带宽压力（cdn节点通常离Client端很近，可以不用每次同样的请求都出省访问）
- 优化了网上热点内容的分布
- 动态加速（DCDN）
- 内容：针对POST等非静态请求（不能再用户边缘缓存的业务），基于智能选路技术，从众多回源线路中择优选择一条线路进行传输
- 过程：
- Client发起动态请求
- 智能选择性能和稳定性最优路径（检测DCDN节点）
- 动态请求通过最优路径快速回源
- 使用效果
四层负载均衡
- 问题引入
公司越做越大，提供的服务越来越多，用户越来越多，因此内部需要更多的后端服务器一起响应。
但是有两个问题，首先，公网IP地址有限，不可能一个后端服务器一个公网IP；其次，各服务器的负载有限，如何控制各个服务器处理的请求在负载能力内。
简单了解负载均衡
- 四层负载均衡——原理
- 基于IP+端口，实现扩展多个后端服务器（NAT）
- 利用某种算法将报文转发给某个后端服务器，实现负载均衡地落在后端服务器上
- 四层负载均衡——功能
- 解耦vip（虚拟服务IP——公网IP）和rs（实际服务器）（NAT复用内部IP地址）
- 负载均衡
- 防攻击：使用syn proxy 可以防止部分攻击
- 常见的调度算法（负载均衡）
- RR（Round Robin）轮询：将所有的请求平均分配给每一个真实服务器RS
- 加权RR（Round Robin）轮询：给每一个真实服务器RS一个权值比例，将请求按比例分配
- 最小连接：把新的连接请求分配到当前连接数最小的服务器
- 五元组hash：根据sip、sport、proto、dip、dport（两源+协议+两目的）对静态分配做散列取模，散列取模后，所有结果保存在hash环上面。缺点：当后端某个服务器故障后，所有的连接都重新计算，影响整个hash环。
- 一致性hash：只影响故障服务器上的连接session，其余服务器上的连接不受影响
- 四层负载均衡——常见实现方式FULLNAT
- 如下所示，用户、负载均衡器、真实服务器处于三个网段中，流程如下
- 四层负载均衡特点
七层负载均衡
- 问题引入
涉及到7层网络架构的相关配置需求，需要使用七层负载均衡
- Nginx
- Nginx是最灵活的高性能Web Server，是应用最广泛的7层反向代理
- 并发连接场景下，Nginx的内存使用比Apache低很多，每秒请求数量是Apache的很多倍
- Nginx 采用模块化设计，有较好的扩展性和可靠性
- Nginx 基于master/worker架构设计
- Nginx 支持热部署，可在线升级
- Nginx 支持不停机更新配置文件、更换日志文件、更新服务器二进制
- Nginx 使用较低的内存：1万个keep-alive连接模式下的非活动连接仅消耗2.5M内存
- Nginx 事件驱动：异步非阻塞模型、支持aio、mmap（内存映射）
- Nginx 内部架构
- Nginx 反向代理示意
- 事件驱动模型
- 异步非阻塞
- 传统服务器：一个线程/进程处理一个请求/连接，属于阻塞模型，依赖OS实现并发
- Nginx：一个线程/进程处理多个请求/连接，是异步非阻塞模型，减少OS进程切换
- 简单调优
