这是我参与「第三届青训营 -后端场」笔记创作活动的的第3篇笔记
思维导图
笔记
-
引言
- 为了让抖音工作,网络需要哪些交互?
- 为了让抖音工作,网络需要哪些交互?
-
网络接入
-
SDN
(28 封私信 / 81 条消息) SDN 是什么? - 知乎 (zhihu.com) 什么是SDN?SDN和NFV有什么区别? - 华为 (huawei.com)
-
定义
- SDN是一种新兴的控制与转发分离并直接可编程的网络架构
- 在传统网络中,网络设备可以分为管理面、控制面和转发面。管理面负责业务的编排和策略的制定,控制面负责操作系统的运行以及各种算法的运算,转发面负责数据包的转发和接收。SDN的理念是将网络设备的控制和转发功能解耦,使网络设备的控制面可直接编程,将网络服务从底层硬件设备中抽象出来。
-
传统网络问题
-
传统网络要求每台设备必须使用相同的网络协议,保证各厂商的设备可以实现相互通信,一旦原有的基础网络无法满足新需求,就需要上升到协议制定与修改的层面
- 在二层网络中,设备通过广播的方式传递设备间的可达信息
- 在三层网络中,设备间通过标准路由协议传递拓扑信息
- 传统网络部署一个传统网络往往需要使用到很多协议,由于标准协议中往往存在一些未明确的地方,导致各厂商的实现有差异。
- 传统网络以单台设备为单位,以命令行的方式进行管理。网络管理和业务调度时效率低下,运维成本高。
- 比如:传统网络一个村子里的每家有一个男人和女人,男人负责搬砖,女人负责告知男人搬砖的路径,每家每户有自己的方言,由居委会控制整个村的搬砖方法,而SDN介于网络运营商和网络设备之间,取缔了各家各户的女人
-
-
SDN架构
- SDN架构可分为基础设施层、控制层和应用层。
- 基础设施层:主要为转发设备,实现转发功能,例如数据中心交换机。
- 控制层:由SDN控制软件组成,可通过标准化协议与转发设备进行通信,实现对基础设施层的控制。
- 应用层:常见的有基于OpenStack架构的云平台。另外,也可以基于OpenStack构建用户自己的云管理平台。
- SDN使用北向和南向应用程序接口(API)来进行层与层之间的通信,分为北向API和南向API。北向API负责应用层和控制层之间的通信,南向API负责基础设施层和控制层之间的通信。
-
-
路由
- 路由是网状的,路由不一定是对称的——有多条路径供包的发送和返回
-
同网段:
(28 封私信 / 81 条消息) 静态路由和动态路由有什么异同点? - 知乎 (zhihu.com)
- 配置网段即可默认添加静态路由。获取对端MAC直接发包
-
直连路由
- 路由器等网络设备能够自动地学习到达该接口所在网络的直连路由,并将这条直连路由在路由表中生成
- 说简单点,因为这是我“家门口”的网络嘛,无需人为干预,自动学习
-
静态路由
- 对于到达非直连网络的路由可就无法自动学习了,一种最简单的方式就是通过手工配置的方式为路由器创建静态的路由表项,这叫静态路由
- 静态路由,没错,就是在R1上面加一条去往PC2的静态路由;同理,R2上也需要加一条去往PC1的静态路由;
-
默认路由
- 静态路由的一种,一般用于末梢/末节网络。
- 出现默认路由的原因:路由得查看路由表而决定怎么转发数据包,用静态路由一个个的配置,繁琐易错。如果路由器有个邻居知道怎么前往所有的目的地,可以把路由表匹配的任务交给它
-
浮动路由
- 配置两条静态路由,默认选取链路质量优(带宽大)的作为主路径,当主路径出现故障时,由带宽较小的备份路由顶替
-
跨网段:
什么是网关,网关的作用是什么? - 知乎 (zhihu.com)
- 配置网关路由。获取网关MAC地址发包
- 网关在传输层上以实现网络互连,是最复杂的网络互连设备,仅用于两个高层协议不同的网络互连。
- 如果网络A中的主机发现数据包的目的主机不在本地网络中,就把数据包转发给它自己的网关,再由网关转发给网络B的网关
-
动态路由:
- BGP/OSPF等,路由表在动态变化
- 路由是网状的,路由不一定是对称的——有多条路径供包的发送和返回
-
ARP协议
- 逻辑同网段才能发送ARP
-
免费ARP
- 主动广播告知MAC地址
- 判断IP是否冲突
-
ARP代理
-
虚拟网络/伪造MAC地址
- 用于虚拟网络等待
-
-
IP协议
- 使用IP地址而不仅仅使用MAC地址主要原因是为了向下兼容,链路层有多种设备和协议 当然,还包括设备间寻址,MC地址长度,网段划分等等原因
- IPv4:互联网终端节点的唯一标识
- IPv6:不仅仅是IP地址长度的增加
-
NAT-解决IPV4地址不足
-
多个内网客户端同时访问一个目标地址+端口,不会发生冲突
- NAT不仅仅是源地址变换,源端口/校验和/SEQ等都会变化
- NAT上网:家用路由器
- NAT出网:机房内网主机上外网
- NAT原理
-
-
-
网络传输
-
数据包
- 本质上是一段内存,里面存储的内存是有序的,一般是按照TCP/IP的多层协议去封装。拆包/封包都是按照协议去写内存/读内存。
- 本质上是一段内存,里面存储的内存是有序的,一般是按照TCP/IP的多层协议去封装。拆包/封包都是按照协议去写内存/读内存。
- 各层协议
-
TCP
- TCP连接:是一个虚拟的概念,本质上两边维持一段内存,记录连接状态,就是session
-
拔了网线,连接会断吗
-
MSS是在什么场景下确认的
- 时间:三次握手时确认
-
方法:
- 通过TCP Option(选项)字段,双方Option字段中MSS最小值
- 时间戳也是在TCP三次握手时,通过Option字段中的时间戳确认的
- TCP传输:理解sequence number/acknowledge number
- 丢包重传:理解丢包怎么感知并重传,理解快速重传发生在什么时候
- 三次握手:确认传输的序列号/MSS/Option字段,建立连接
-
HTTP
- HTTP比TCP好在哪里:方便
-
HTTP1.1的优化
- 长连接是重点
-
HTTPS
- HTTPS的产生背景:加密/可靠/防劫持
-
SSL/TLS握手:
(26条消息) TLS/SSL 工作原理及握手过程详解Tyler_Zx的博客-CSDN博客tls原理图解
- 非对称加密/对称加密
- CA
- 待补充
-
-
网络提速-协议优化/网络路径优化
-
HTTP2.0
-
多路复用:依然有队头阻塞
-
单个TCP连接通道,串行的stream
-
如果TCP丢包呢——队头阻塞
- TCP中Options字段会包含序列号,指定只重传丢失的包,而不是一直阻塞在丢失的包位置
-
-
-
-
QUIC
-
QUIC的产生背景和背后思考
QUIC网络协议简介 - 云+社区 - 腾讯云 (tencent.com) 科普:QUIC协议原理分析 - 知乎 (zhihu.com)
- QUIC不是四层协议
-
为什么在用户态实现?
- 内核的更新迭代频率较低,不好推广
-
为什么用UDP?
- TCP在Unix上是不可插拔的,TCP拥塞控制可插拔
- TCP的队头阻塞问题不好解决,推倒重来&复用所有操作系统基本都支持的底层协议
- 0 RTT
- 弱网优势
- 待补充
-
-
数据中心建设
-
边缘机房/汇聚机房/中心机房
- POP
- 待补充
-
多运营商接入
- 根据访问者的运营商,接入相应运营商服务器,同运营商内部访问,避免跨运营商的流量
- 根据访问者的运营商,接入相应运营商服务器,同运营商内部访问,避免跨运营商的流量
-
CDN静态缓存系统:
-
一部分数据是静态的,所有人访问结果应该相同
- 比如静态资源(图片视频)用户上传完的一张图片,每个人看到的应该是同一张图片 不同人访问的 数据一样,可以利用边缘机房中其他人访问过的缓存
- 边缘机房的建设,优先访问边缘机房,缓存命中视频/图片等静态内容
-
-
DSA动态加速系统:
-
一部分数据是动态的,不同的时间或者不同的人访问应该有不同的结果
- 比如动态API(播放/评论接口) 不同人应该有不同的访问数据,比如每个人偏爱的视频不同
-
分四层/七层动态加速。核心在于利用可控节点做路径探测和规划。
- 待补充
-
-
-
-
网络稳定
- 对容灾的理解
-
网络容灾的具体案例
-
机房专线故障
- 环路容灾,避免某条专线故障导致机房孤岛问题
-
专线是连接各个机房的网络物理路径
- 比如字节为抖音搭建的专线,不同于外部的运营商网络(外网)
-
单机房接入节点故障
bytedance.com对应两条DNS路径,但其中一条瘫痪
-
DNS容灾,摘除故障的节点-字节GTM系统
- 需要做到故障感知(探测)
- 故障切换(应该保证切换后,1.1.1.1的流量不会导致2.2.2.2瘫痪——防止雪崩)
- 故障恢复
-
-
云控容灾
-
云端交互,服务器/云上下发命令到终端-字节TNC系统
- 比如安装抖音后,会包含一个SDK,和服务端交互,对有问题的机房主动降级/容灾
-
场景局限
-
无法嵌入SDK的场景
- 比如通过浏览器访问,无法在其他厂商浏览器中做SDK嵌入
-
-
-
cache容灾
- 多级系统,源站不可用,降级到之前的缓存内容-字节TLB/ByteCDN等系统的容灾建设
-
LB
- 待补充
-
-
故障排查
-
加强故障沟通-明确故障
- 什么业务?什么接口故障?
- 故障体现在哪里?
- 访问其他目标是否正常?是否是修改导致的异常?
-
故障止损要在第一时间做(灾备预案的建设)
-
先止损后排查
- 容灾
-
降级
- 比如没有容灾的情况下推荐接口出现故障,可以先暂停推荐服务,但保证视频能正常观看
- 如何排查——分段排查
-
-
熟悉常用的故障排查命令
- dig查询DNS问题
- ping/telnet/nmap查询三层/四层连通性
- Traceroute排查中间链路
- iptabels查客户端 防火墙等
- tcpdump抓包
- ipvs
- 待补充各命令细节
-
-
故障排查的具体案例
-
服务端配置异常(健康检查异常)
-
客户端异常->服务端自测正常->网关转发异常->健康检查异常
- 健康检查误判摘掉了正常的节点
-
-
客户端某个例异常(客户端自己配置错误)
- 个别用户报故障,生产环境大多是客户端的问题
-
外部运营商故障
- 安徽电信报障某APP无法使用->检测后端服务正常,安徽电信流量突降->安徽电信客户端ping不通目标服务->电缆被挖断
-
复杂故障的排查:需要抓包,具体问题具体分析
-
某APP故障->后端服务器反馈服务正常->网络转发设备异常->抓包->路由不对称
- 路由器设置了快速发包(对称路径返回)
-
-
- 对容灾的理解