这是我参与「第三届青训营 -后端场」笔记创作活动的第3篇笔记、
本文主要是对打开抖音互联网会发生什么及将我的服务开放给用户两节网络相关课程的内容整理
引言
思考:为了让抖音工作,网络需要哪些交互?
网络接入
- 互联网的接入:网络拓扑的整体认知
-
路由发包原理:
-
同网段:配置网段即可默认添加静态路由。获取对端MAC直接发包
-
同网段不一定是接入同一物理逻辑交换机,可能是一个SDN的虚拟同网段
-
-
跨网段:配置网关路由。获取网关MAC地址发包
-
路由改的是 MAC地址,目标IP地址始终不变,找到发包口
-
动态路由:BGP/OSPF等,路由表在动态变化
-
路由是网状的,不一定是对称的
-
-
-
ARP协议
- 逻辑同网段才能发送ARP,本质上是查找下一跳的MAC,不是请求目标地址的MAC
-
ARP请求广播/应答单播:协议原理
- 免费ARP:主动广播告知MAC地址(场景:1、新增了服务器,直接告诉其他服务器去做一次MAC的刷新;2、当服务器新增了一个IP之后,防止IP冲突, 两台服务器配置了同一个IP)
- ARP代理:虚拟网络/伪造MAC地址,当ARP的请求目标跨网段时,网关设备收到此ARP请求,会用自己的MAC地址返回给请求者,这便是代理ARP,代理ARP本质是一个"善意的欺骗",是一个"错位"的映射。
-
IP协议
- IPv4:互联网终端节点的唯一标识
- MAC地址不能代替IP地址吗?
- 二层不只有MAC一种协议,存在向下兼容的问题(IP地址起到封装统一的作用)
- IPv6:不仅仅是IP地址长度的增加
-
NAT
-
-
NAT上网:家用路由器
-
NAT出网:机房内网主机上外网
-
NAT原理:注意不仅仅是源地址变换,改的是IP+端口,源端口/校验和/SEQ等都会变化
-
网络传输
- 数据包:本质上是一段内存,里面存储的内存是有序的,一般是按照TCP/IP的多层协议去封装。拆包/封包都是按照协议去写内存/读内存
- DNS递归迭代
-
UDP
- 协议简单,总结:想发什么包,就分配一个UDP的头,把payload里面塞数据发出去就好
- 需要考虑可靠性的场景使用复杂,总结:怎么保证协议可靠?很多方面相当于自实现了TCP
-
TCP
-
拔了网线,连接会断吗?关键看TCP是否有保活(keep alive)机制
-
三次握手:确认传输的序列号/MSS/Option字段,建立连接
-
TCP连接:是一个虚拟的概念,本质上两倍维持一段内存,记录连接状态,就是session
-
TCP传输:理解sequence number/acknowledge number
-
sequence number:表示的是我方(发送方)这边,这个packet的数据部分的第一位应该在整个data stream中所在的位置
- acknowledge number:表示的是期望的对方(接收方)的下一次sequence number是多少。注意,SYN/FIN的传输虽然没有data,但是会让下一次传输的packet seq增加一,但是ACK的传输不会让下一次的传输packet加一
-
丢包重传:理解丢包怎么感知并重传,理解快速重传发生在什么时候
-
滑动窗口:课后自学
-
流量控制:课后自学
-
-
HTTP
- HTTP比TCP好在哪里:方便,TCP已经十分复杂了,HTTP在此之上多加了一层规矩,让用户更清晰简洁,关注于业务本身
- HTTP1.1的优化:长连接是重点
-
HTTPS
- HTTPS的产生背景:加密/可靠/防劫持
- SSL/TLS握手:非对称加密/对称加密
网络提速
协议优化
-
HTTP2.0
-
多路复用:依然有TCP队头阻塞(重点)
-
QUIC/HTTP3.0
-
QUIC的产生背景和背后思考:
- 为什么在用户态实现? 内核的更新迭代频率较低,不好推广
- 为什么用UDP? TCP的队头阻塞问题不好解决,推倒重来&复用所有操作系统基本都支持的底层协议
-
0 RTT(HTTPS加密)
-
弱网传输优势
-
网络路径优化
-
数据中心建设
-
-
多运营商接入:同运营商内部访问,避免跨运营商的流量
-
有边缘机房/汇聚机房/中心机房
-
-
CDN静态缓存系统:边缘机房的建设,优先访问边缘机房,缓存命中视频/图片等静态内容
-
DSA动态加速系统:分四层/七层动态加速。核心在于利用可控节点做路径探测和规划
网络稳定
-
对容灾的理解
-
网络容灾的具体案例
-
机房专线故障:环路容灾,避免某条专线故障导致机房孤岛问题(专线是连接各个机房的网络物理路径)
-
-
-
单机房接入节点故障:DNS容灾,摘除故障的节点-字节GTM系统
- 云控容灾:云端交互,服务器/云上下发命令到终端(场景局限性:例如用户不给授权,或者流量入口是个web页面,无法嵌入SDK)-字节TNC系统
- cache容灾:源站不可用,降级到之前的缓存内容-字节TLB/ByteCDN等系统的容灾建设
-
故障排查
-
加强故障沟通-明确故障
- 故障止损要在第一时间做(灾备预案的建设)
- 熟悉常用的故障排查命令
-
故障排查的具体案例
- 服务端配置异常(健康检查异常)
- 客户端某个例异常(客户端自己配置错误)
- 外部运营商故障
- 复杂故障的排查:需要抓包,具体问题具体分析
接入问题引入
问题引入
- 经典问题:浏览器输入网站域名 www.toutiao.com 到网页加载出来,都经历了哪些过程?
- 域名解析
- TCP建连
- SSL/TLS握手
- HTTP请求
字节接入框架
企业接入升级打怪之路
使用域名系统
-
使用域名系统替代 Host 管理(主机表:Host -> ip 映射)
-
Host管理存在的问题:
- 浏览和负载:用户规模指数级增长,文件大小越来越大,统一分发会引起较大的网络流量和cpu负载
- 名称冲突:无法保证主机名称的唯一性,同名主机添加导致服务故障
- 时效性:分发靠人工上传,时效性太差
自建 DNS 服务器
- 使用自建 DNS 服务器代替云厂商的 DNS 服务
- DNS查询过程
- 站在企业角度,需要的是权威DNS
接入 HTTPS 协议
-
HTTP明文传输,弊端越来越明显
-
SSL的通信过程
- client random
- server random
- premaster secret
- 加密算法协商 -> 对称密钥 session key
- 证书链(数字签名 -> 根CA)
- 使用HTTPS协议
接入全站加速
-
外网用户访问站点,可能出现的问题有哪些?
- 源站容量低,可承载的并发请求数低,容易被打垮
- 报文经过的网络设备越多,出问题的概率越大,丢包、劫持、MTU问题
- 自主选路网络链路长,时延高
-
在用户看来的现象就是响应慢、卡顿
-
解决方案:
- 源站容量问题:增加后端机器扩容;静态内容使用静态加速缓存(本质是构建缓存的CDN节点)
- 网络传输问题:动态加速DCDN(针对POST等非静态请求等不能在用户边缘缓存的业务,基于智能选路技术,从众多回源线路中择优选择一条线路进行传输)
- 全站加速:静态加速CDN + 动态加速DCDN
-
使用全站加速
-
区分下列场景使用的加速类型
- 用户首次登录抖音,注册用户名手机号等用户信息(动态加速)
- 抖音用户点开某个特定的短视频加载后观看(静态加速)
- 用户打开头条官网进行网页浏览(静态加速 + 动态加速)
-
四层负载均衡
-
什么是4层负载均衡:
- 基于IP+端口,利用某种算法将报文转发给某个后端服务器,实现负载均衡地落到后端服务器上
-
三个主要功能:
- 解耦 VIP 和 RS
- NAT
- 防攻击(避免将后端物理机的IP暴露在公网):syn proxy
-
常见的调度算法原理
-
RR轮询:Round Robin,将所有的请求平均分配给每个真实服务器RS
-
加权RR轮询:给每个后端服务器一个权值比例,将请求按照比例分配
-
最小连接:把新的连接请求分配到当前连接数最小的服务器
-
五元组hash:根据 sip, sport, proto, dip, dport(源IP,源PORT,协议,目的IP,目的PORT)对静态分配的服务器做散列取模
缺点: 当后端某个服务器故障后,所有连接都重新计算,影响整个hash环
-
一致性hash:只影响故障服务器上的连接session,其余服务器上的连接不受影响
-
七层负载均衡
- 基于URL等应用层信息的负载均衡
-
最灵活的高性能web server,应用最广的7层反向代理——Nginx
-
代理服务器功能
- keepalive
- 访问日志
- url rewrite
- 路径别名
- 基于 ip 的用户的访问控制
- 限速及并发连接数控制