打开抖音会发生什么
刷视频：域名解析DNS、视频下载/HTTP、图片下载/HTTP、评论API/HTTP
刷抖音网络是怎么交互的
1.1 网络接入 -互联网
终端（pad，pc）→ WiFi、5G、4G →运营商（联通、电信等运营商的服务器和抖音的机房打通）→ 也和美国网络通过光缆连接
1.2 网络接入-路由
同网段、跨网段
SDN 软件虚拟化
同网段可能是一个虚拟的同网段
跨网段：
中间有一个交换设备连接起来两个服务器
路由一定是对称的吗
不一定
路由是工作在哪一层协议
大多数在IP层，但有些是其他层的
路由是改的IP地址吗
目标IP不变，它是找中间的路，改mac，找到发包口
1.3 网络接入-ARP协议
找到下一跳
ARP查询过程：
服务器A广播：服务器B在哪？
各服务器收到了这个广播，并且B发现找的是自己，于是B作出相应。
逻辑同网段才能发送ARP，如果是跨网段也是一层一层同网段之间发送ARP（先找到下一跳），不断迭代
ARP请求是广播，应答是单播
免费ARP：不同请求就告诉你IP地址
比如，新加了一个IP，但是其他服务器没有缓存到这个地址，在要发送东西到这个IP的时候，效率就会低，这个时候发送一个免费ARP，告诉别人，你刷新一下地址，我这边新增了机器
防止IP冲突
ARP代理：劫持一个ARP请求，发往另一个地方，伪造一个东西
ARP本质上是查找下一跳的mac，不是请求目标地址
1.4 网络接入-IP协议
- IP地址是唯一标识，互联网通用。抖音客户端一个，抖音服务端一个。
- 如果mac地址也是抖音客户端一个，抖音服务端一个，可以用mac代替IP地址吗？
mac协议是二层的，有很多协议，互联网历史遗留问题。将不同的二层网络封装，协议统一起来。 - IPV4不够用怎么办？
IPV6 和 NAT
1.5 网络接入-NAT
家里的路由器
多个内网用户客户端通过一个NAT设备修改原地址，用同一个重复的IP地址
NAT 修改的是IP地址+端口，当多个内网用户访问同一个目标地址+端口时，不会有IP冲突，因为NAT不仅修改了IP，还修改了端口，当已经有一个IP+端口访问的时候，再来一个去访问的时候可以选择另一个端口。
1.6 网络传输-数据包
1.7 网络传输-请求DNS
IP不好记，就有DNS域名 递归迭代
1.8 网络传输-DNS的传输协议 UDP
UPD本身相对简单
端口+校验
想发什么包，就分配一个UDP的头，把payload里面塞数据发出去就好
UDP用好很难
怎么保证协议可靠？：
发包每次发多少
怎么避免分片（会降低效率）
怎么知道没丢包
怎么权衡传输效率和质量
1.9 网络传输-TCP
UDP不可靠，常用TCP
什么是TCP 连接？
拔了网线，连接会断吗？
拔了网线和TCP本身是没有强耦合的东西的
若TCP有探活，定期发包探测对方的状态，拔了网线，包发不出去，就会断开连接
TCP 很复杂
TIME_WAIT：recycle 、reuse
1.10 网络传输-HTTP/HTTP1.1
TCP 和 HTTP 之间就像 中文和军事专用语。
HTTP 是基于TCP的，它是针对于某一特定情境下使用，多了一层规矩，更清晰简洁。
1.11 网络传输-HTTPS
传输中被插入小网站怎么办？
HTTPS 解密出来仍然是HTTP
相当于加密防窃听
SSL/TLS 握手
对称加密和非对称加密
CA
公钥和私钥
网络架构怎么给抖音提质
2.1 网络提速-HTTP2.0
多路复用，并行下载
多路复用
TCP是串行的，一个包一个包地发 丢包，重传，后面的等待，阻塞（灾难性的），多路复用不能用。tcp option。
QUIC/HTTP3.0
解决队头阻塞、改TCP牵一发动全身、不可插拔，所以用UDP，方便推广
kernel or user space？若kernel，很多系统都要实现，推广复杂，所以在user space实现。
0 RTT：QUIC是有加密的，section共享
弱网传输优势：弱网环境下容易丢包，quic在弱网更强。
路径优化
2.4 网络提速-数据中心分布
数据中心：服务器集合的地方（机房）。
机房类别：核心机房：核心数据
pop接入：外网，小型机房
边缘机房：靠近用户，非核心的。很多。
2.5 网络提速-同运营商访问
中国特性：跨网质量差，丢包概率高。 通过解析去做，客户端解析
2.6 CDN
静态资源：图片视频。所有人看到的都一样，可以缓存。边缘机房缓存，若客户端要访问，现在边缘机房访问，看有无缓存，就不用访问汇聚机房，甚至核心机房了。
2.7 网络提速-动态API
如播放、评论接口，会随着客户、时间改变
路径优化：DSA
2.8 网络稳定-容灾
概念：
故障发生
故障感知：系统感知到故障，
自动切换：把故障节点从整个系统里面去掉，自动恢复
服务恢复：
2.8.1 案例1
专线：内部的机房，把两个机房做连接 ，比interne快 外网：在机房专线以外的，通过Internet的
案例2
调度容灾
案例3
云控 降级容灾 机房不可用，让你的端不访问那个机房。 web页面容灾不好做
案例4
前置兜底逻辑/cache文件
降级
没有容灾的故障怎么查
2.9 故障排查
故障明确： 沟通：什么业务，什么接口故障？如何体现？
故障止损：
先止损再排查
用户体验第一，对公司收入的影响
组件没有容灾，降级处理。
分段排查：
客户端排查：访问其他服务，其他客户端访问目标服务
服务端排查：服务端监控、指标正常吗？手动访问一下；分组件排查；
中间链路排查：服务端和客户端都没问题的话，中间网络设备？旁路的DNS?
网络故障排查常用命令
dig查询DNS问题；ping、telnet查询
连通性：
traceroute 排查中间链路；
iptabels：查客户端；fa防火墙之类的
TCP dump：抓包；客户端抓个包，服务端抓个包，对比
案例1
健康检查异常：中间设备的误判，导致摘掉了正常的节点
案例2
个别用户报故障，生产环境大多是客户端的问题。
案例3
电缆被挖断了，地区APP不可用
案例4
路由不对称，不要用快速抓包
预防
监控报警
故障演练/预案
故障降级/止损
