这是我参与「第三届青训营 -后端场」笔记创作活动的第5篇笔记。
刷抖音中使用的网络协议（应用层）
-
DNS: 域名解析
-
泛HTTP: 图片下载、视频下载、评论API
网络接入
互联网
-
服务器/机房与中国电信等运营商建立连接，运营商再通过海底光缆同美国网络连接。
-
同网段发包/交互: 更改目标IP的MAC
-
跨网段发包/交互: 中间通过交换设备连接，配置一个路由
路由
-
路由不一定是对称的，往返某一节点的路径可能不一致，绝大多是都是对称型路由
-
路由工作在网络层(IP层)的说法并不准确，有的路由协议本身可能并不工作在网络层。比如OSPF协议，就不是一个简单的工作中网络层的协议，它属于传输层。很多协议可能需要做很多层的交互。从总体角度来看，说路由工作在网络层没有问题。
-
路由不是去改IP地址，改的是目标MAC地址，找到发包口。每过一个设备，就需要将源MAC改为之前那个设备的MAC，源IP地址和目标IP地址应该一直是不变的。
ARP协议
-
同逻辑网段才能发送ARP。跨网段不能直接发送ARP，需要不断找下一跳，一种到同逻辑网段。
-
广播是不能跨网段的。
-
ARP查询是发送一个请求广播，目标设备发送一个ARP应答单播。
IP协议
唯一标识，互联网通用。抖音客户端一个，抖音服务端一个。
NET
NET是IP+端口一起改变的，解决多个内网客户端访问同一个目标地址+端口，而源端口一样的问题。
网络传输
数据包发送
先请求DNS
客户端发送网址的解析请求，递归解析器解析
UDP
-
UDP功能太过简单，想发什么包就i分配一个UDP的头，把payload里面塞数据发出去就好。
-
UDP想要用好很难，不能确保协议可靠。
TCP
三次握手：
确认传输的序列号/MSS/Option字段，建立连接。
TCP连接
一个虚拟的概念，本质上是维持一段内存，记录连接状态，也就是session。
TCP传输
sequence number(Seq):表示发送方这个packet的数据部分的第一位应该在整个data stream中的位置
acknowledge number(Ack):表示期望接收方的下一次sequence number是多少
ps: SYN/FIN的传输虽然没有data，但是会让下一次传输的的packet seq增加1，但是ACK的传输不会让下一次的传输packet加1.
timewait需要等两个msl（每个分节最长生命期）,原因是为了确保连接正常关闭，防止前一次的ACK丢失。
丢包解决办法：利用ACK的机制
HTTP/HTTP1.1
TCP负责的内容太多了，如果用TCP开发效率太低。相比较TCP，HTTP是多加了一层规矩，HTTP依然还是TCP,只是这个规矩让用户更清晰更简洁。
HTTPS
HTTPS为了防止传输中被窃听和劫持使用了加密，解密出来后依然是HTTP。
SSL/TLS握手
先进行非对称加密，再进行对称加密
网络架构如何给抖音提质
网络提速
HTTP2.0
多路复用，并行访问
多路复用时，TCP如果发生丢包便会导致队头阻塞，全部重传。
QUIC/HTTP3.0
-
用UDP的原因是TCP的队头阻塞问题不好解决，推倒重来代价太大。
-
在用户态实现的原因是内核的更新迭代频率较低，不好推广
在弱网环境下有很大的优势
数据中心分布
有边缘机房/汇聚机房/中心机房
同运营商访问
电信解析电信服务器，移动解析移动服务器
跨网质量较差
路径优化（CDN）--静态资源
对于视频图片类资源，进行缓存。
按照边缘机房->汇聚机房->核心机房的顺序依次查找。
路径优化（DSA）--动态资源
对于动态API(播放/评论接口)，优化路径。
对网络延时进行探测，探测的数据做成一张表，通过特定算法求得最优路径。
网络稳定
容灾
思路上：故障发送—>故障感知->自动切换->服务恢复
-
环路容灾：内部机房使用专线和外网同时连接，外网容灾。
-
DNS容灾：摘除故障节点，并对即将使用的机房进行容量判断。
-
云控容灾：服务器/云上下发命令到终端。
-
cache容灾：源站不可用，降级到之前的缓存内容
故障排查
思路上：故障明确->故障止损->分段排除
网络故障排除常用命令
-
dig查询DNS问题
-
ping/telnet/nmap查询三层/四层连通性
-
Traceroute排查中间链路
-
iptabels查客户端
-
tcpdump抓包
