一、刷抖音网络是怎么交互的
1.网络接入（先让我的手机能够访问抖音服务器）
互联网： PC 通过WiFi和路由器进行交互，路由器再和中国运营商交互，中国运营商都有对应的服务器，中国运营商和美国网络通过光缆连接
2.路由：
- 往相同网段如何发包/交互？ 交换机可以连接多个pc，交换机与交换机之间可以靠物理端口连接，也可以靠SDN连接
- 路由一定是对称的吗？ 并不一定是对称的
- 路由是工作在哪一层协议？ 一般来说是IP层
- 那路由是改的ip地址吗？ 改的是mac，传输过程中只会改ma·c 路由是改Mac，找到发包口
3.ARP协议
- 逻辑同网段才能发送ARP
- ARP请求广播，ARP应答单播
- ARP本质上是查找下一跳的MAC，不是请求目标的地址
4.IP协议
唯一标识，互联网通用。抖音客户端一个，抖音服务端一个
- Mac地址不能代替IP地址吗 MAC协议是二层协议，在这一层不只是有MAC一个协议，还有其他协议，所以就用更高一层，IP统一了二层的协议
- ipv4不够用，一般咋解决，家里的路由器是怎样上网的 利用NAT，内部网络可以用重复的IP地址，外部网用全局唯一的一个IP地址去联网
- 多个内网客户端访问同一个目标地址+端口，源端口恰好一样，冲突了？ NAT可以改变IP和端口，端口会被修改，就不会被冲突
5.网络传输
应用的客户端通过socket到TCP和UDP传输数据，然后根据IP地址到数据链路层找到对应源机器网络设备，然后到目的机器网络设备，目标机器返回到自己的数据链路层通过IP再经过传输层，到达自己的服务器端
6.请求DNS
客户端发www.douyin.com 的解析请求 ->递归解析器去问 “.”,com 去哪里解析->递归解析器去问“com”，douyin.com去哪里解析->douyin.com告诉递归解 解析到xxx
DNS传输协议UDP,UDP本身相对简单,然后保证协议可靠
总结：想发什么包，就分配一个UDP的头，把payload里面塞数据发出去就好
7.HTTP
为啥不直接用TCP通信？为什么互联网上那么多的HTTP通信？
其实HTTP只是多加了一层规矩。HTTP依然是TCP，只是这个规矩让用户更加清晰/更简洁
8.HTTPS
传输中被插入小网站怎么办 HTTPS解密出来依然是HTTP
二、网络架构怎么给抖音提质
1.网络提速
HTTP2.0 实现了多图并发下载，重要的是多路复用
- 怎么理解多路复用/stream？ 单个TCP链接传输，http里面是串行的，里面相当于有多个流串行，但是都是同时向单个tcp连接传输
- 如果TCP丢包怎么办？ 队头会堵塞，TCP自己有所优化
2.QUIC/HTTP3.0
谷歌推出QUIC协议解决了TCP队头堵塞
- TCP or UDP 思路是改变TCP 但是TCP牵扯的协议太多，牵一发而动全身，所以就选择UDP，各个服务器都支持
- Kernel or Userspace 使用Kernel，就要考虑可以适配几个地方，不同的操作系统是否都要考虑内核态的实现，推广起来比较复杂
- 0 RTT 天然支持HTTPS，支持加密
- 弱网优势 在弱网情况下，TCO自身对队头堵塞的优化就没有用了，而在QUIC协议优化下解决了队头堵塞，弱网情况下得到了一次提升，推行HTTP3.0
3.网络路径优化
数据中心分布基本概念
- 数据中心：服务器集中的地方，机房
- 核心机房:存核心数据
- pop接入:跟运营商，跟internet作交互的小型的机房
- 边缘机房:小运营商
同运营商访问，移动访问移动服务器，电信访问电信服务器，跨网质量差，容易丢包，优化如下：
- 静态资源（图片视频）路径优化（CDN）：边缘机房有缓存，会缓存部分客户端访问的静态资源，当其他客户端要访问时，会先从这些缓存中寻找，找到了就直接下载，没有的话就汇聚机房找，如果没有就去核心机房找
- 动态API(播放/评论接口)路径优化 （DSA）
- 通过路径算法，找到最优路径
4.网路稳定
容灾概念：故障发生，故障感知，自动切换，服务恢复
-
网络容灾案例一 专线：两个机房不通过internet连接，而是通过一条物理连接，网路更快 外网：在机房专线外部连接的网络，就是Internet连接的网，专线不可以用时就要用到外网
-
网络容灾案例二： 容灾调度，bytedance.com 域名解析到A机房，B机房，A机房不可以用，将A记录替换，自动换成B记录，还要测B机房的容量
-
案例三： 当客户端安装了字节跳动的APP，里面会内置一个SDK，SDK能够连接到服务器，当服务器出现问题时，会更换为另外一个服务器，当然在更换前会先查看服务器的容量，但是SDK的运用受用户的授权限制，有些是需要通过法律允许
-
案例四： LB到app不通，或者出现bug，做一个cache，当下面不通，则响应上次缓存的东西
5.故障排查
- 故障明确
- 出现什么故障，沟通是前提
- 什么业务？什么接口故障？
- 故障体现在哪里？
- 访问其他目标是否正常？
- 是否是修改导致的异常？
- 故障止损
- 先止损再排查：优先保证用户体验第一，对公司收入的影响是按照分钟甚至秒来计算
- 如何止损：组件没有容灾，但是不知道系统有没有，采用降级的方法
- 分段排查
- 客户端排查 客户端访问其他服务没问题？ 其他客户端访问目标服务没问题吗？
- 服务端排查 服务端监控/指标都正常吗？ 手动访问一下正常吗？ 分组件排查
- 中间链路排查 服务端跟客户端确保没问题 中间网络设备有没有问题？（交换机/路由器/网关LB） 旁路的DNS有没有问题？
- 网络故障排查常用命令
- dig 查询DNS问题
- ping/telnet/nmap查询三层/四层连通性
- Traceroute排查中间链路
- 故障案例
- 案例一： 客户端异常->服务端自测正常->网关转发异常->健康检查异常
- 案例二： 个别用户报故障，生产环境大多是客户端的问题
- 案例三： 安徽电信报障某APP不能使用->检测后服务正常，安徽电信流量突降->安徽电信客户端ping不通目标服务->电缆被挖断
- 案例四： 某APP->后端服务器反馈服务正常->网络转发设备异常->抓包->路由不对称
- 故障预防
- 监控报警
- 故障演练/预案
- 故障降级/止损
三、总结及建议
总结
这里主要讲了抖音在互联网这方面是怎么实现的，以及如何提升网络质量，最后面对问题和故障是如何解决的，总的来说这里还是偏理论性的，大概讲述了一整个过程，具体的体现得在实际项目中
建议
我认为学习这部分知识，如果是没有学过计算机网络的，就先将计算机网络的一些基本概念搞清楚，再来学习，如果是已经学过了的，就可以结合一个实际的项目来实操一下，这样可以加深对这部分的理解
