打开抖音互联网会发生什么｜ 青训营笔记

YanaHangabina
110 阅读7分钟

这是我参与「第三届青训营 -后端场」笔记创作活动的第5篇笔记

  • 底层：TCP/IP、UDP、ARP……
  • 应用层：域名解析 DNS、视频下载 /HTTP、图片下载 /HTTP、评论 /HTTP

刷抖音网络是怎么交互的？

网络接入：终端访问抖音服务器

互联网（物理）

  • 丢包、拥塞通常发生在 Last mile

路由

  • 同网段接入：中转设备（集线器、3 层交换机 / 逻辑交换机）

    • 有一定限制（数量等）→SDN

    • 同网段通过修改修改 MAC 发包 / 交互

  • 跨网段接入：路由

    • 路由不一定对称（尽管实际互联网一般都是通的）

    • 网络层（IP 层）查找下一跳时需要路由协议，但路由协议本身不一定工作在网络层，如动态路由协议 BGP / OSPF 可能基于 TCP / UDP、工作在传输层

    • 路由修改 MAC 地址，找到发包口

      例：路由找到下一跳 254，向其发送 ARP 请求，返回 254 的 MAC 地址，将目标 MAC 改为 254 的MAC，254 收到后寻找 1.1 服务器，发现在同一网段，再请求其 MAC 地址……

ARP 协议

  • 本质是查找下一跳的 MAC

  • 逻辑同网段才能发送 ARP（广播不能跨网段）

  • ARP 请求广播，ARP 应答单播

  • 免费 ARP：一种特殊的 ARP 请求，它并非期待得到 IP 对应的 MAC 地址，而是当主机启动的时候，发送一个 Gratuitous ARP（IPv6 中） 请求，即请求自己的 IP 地址的 MAC 地址

    • 新增服务器，告诉其他服务器进行刷新
    • 服务器新增 IP，防止 IP 冲突

  • ARP 代理：劫持 ARP 请求，进行 SDN

IP 协议

  • 唯一标识，互联网通用
  • MAC 地址代替 IP 地址？二层协议不仅仅是 MAC 协议、以太网链路（如电话线路）等，为了向下兼容、统一地址，在上层封装 IP 协议

NAT

  • NAT 修改 IP + 端口
网络传输

数据包

数据包发送

请求 DNS

  • 客户端发 www.douyin.com 的解析请求
  • 递归解析器去问 .，com. 去哪里解析
  • 递归解析器去问 com.，douyin.com 去哪里解析
  • douyin.com 告诉递归解
  • www.douyin.com 解析到 xxx

DNS 的传输协议 UDP

UDP 本身相对简单UDP 用好很难
·发包每次发多少？怎样避免分片？ ·怎么知道没丢包？ ·怎样权衡传输效率和质量？ ·……
发包时分配一个 UDP 头、payload 中放入数据发送即可如何保证协议可靠？

TCP 三次握手

Q：拔了网线，TCP 连接会断吗？

A：取决于是否有保活机制

Q：TCP 通过什么防止分片？

A：MSS（TCP Option：还包括时间戳等）

Tcpdump + Wireshark

TCP 传输

  • sequence number：表示的是我方（发送方）这边，这个 packet 的数据部分的第一位应该在整个 data stream 中所在的位置

  • acknowledge number：表示的是期望的对方（接收方）的下一次 sequence number 是多少

    • SYN / FIN 的传输虽然没有 data，但是会让下一次传输的 packet seq 增加一
    • ACK 的传输，不会让下一次的传输 packet 加一

Q：Timewait 解决什么问题？

A：Timewait 等待两倍的 MSL，确保连接正常关闭、防止前一次 ACK 丢失；Linux 中有 timewait_recycle、timewait_reuse 字段，可以设置不等待提高传输效率，但可能出现连接异常

Q：TCP 丢包怎么办？

A：根据 ACK 判断重传

  • 滑动窗口

    • 典型的 ACK 协议要求每一个数据段发送之后都要有一个 回复，然后才能发送下一个数据段——保证数据的可靠传输，但由于 TCP 是全双工通信，在等待一个数据段的 ACK 恢复之前网络将会闲置，效率将会受到极大影响

    • 协议提出了滑动窗口子协议，专门负责数据的传输，滑动窗口子协议分为：

      • 简单的停-等协议
      • 后退 N 协议
      • 选择重传协议

    • 三个子子协议，是一个例程的三个不同情况，如发送和接收窗口都为 1 时就是简单的停等协议

    • 复杂的机制换取了网络链路的高效利用

HTTP / HTTP1.1

  • 无需关心 TCP 的实现细节（ACK、流量控制……）

  • HTTP 依然是 TCP，只是针对特定的场景进行了针对性的优化：使用 Socket TCP stream 流发包时，会做一些自定义协议约束 stream 流——HTTP 本质就是一种在 TCP 之上的自定义协议

  • HTTP1.1 的优化

    • 长连接
    • 部分传输
    • HOST
    • 缓存
    • ……

HTTPS

对称加密和非对称加密确保没有劫持，也确保私钥不泄密

网络架构给抖音提质

网络提速
协议优化

HTTP2.0

  • SPDY 强制 SSL

  • 多路复用 / stream

    • stream 实际上串行传输（TCP 一次发一个包）

      • 速度快是 HTTP 看起来是并行访问
      • 如果 TCP 丢包，则需要全部重传，可能产生 TCP 队头阻塞（反复重传丢失的包，后面的包全部在等待）→ TCP Option sack 可以指定 ACK 序列号，只重传丢失的包

QUIC / HTTP3.0

  • 基于 UDP 而非 TCP
  • 运行在 Userspace 而非 Kernal：QUIC 不是四层协议
  • 0 RTT：Google QUIC和0-RTT密钥交换
  • 弱网传输：解决了队头阻塞的问题
网络路径优化

例：CDN、P2P、Anycast、DSA、遗传 / 蚁群 / 强化学习算法

数据中心分布

  • 核心机房：存储核心数据
  • POP 点接入：小型机房，增加核心机房与互联网交互的出入口
  • 边缘机房：更接近用户

同运营商访问

静态资源（图片视频）路径优化：CDN 静态缓存

动态 API（播放 / 评论接口）路径优化：DSA

网络稳定

容灾：故障发生→故障感知→自动切换→服务恢复

例一：专线-外网容灾

例二：调度容灾

bytedance.com A 1.1.1.1 bytedance.com A 2.2.2.2→bytedance.com A 1.1.1.1→自动化（故障感知、确保 B 机房能够承载切换的流量）

例三：云控容灾

  • 云到端→主动降级 / 容灾
  • 场景局限性：没有 SDK 的 Web 页面

例四：可降级的页面 → 类似 CDN 缓存

Bug 导致全 crash → 前置兜底逻辑 / cache 文件

故障排查：故障明确→故障止损→分段排查

  • 故障明确：出现什么故障？→沟通是前提

    • 什么业务？什么接口故障？
    • 故障体现在哪里？
    • 访问其他目标是否正常？
    • 是否是修改导致的异常？

  • 故障止损

    • 先止损再排查：用户体验第一，减少公司收入损失

    • 如何止损

      • 组件没有容灾，寻求系统容灾
      • 降级

  • 分段排查

    • 客户端排查

      • 客户端访问其他服务没问题吗？
      • 其他客户端访问目标服务没问题吗？

    • 服务端排查

      • 服务端监控 / 指标都正常吗？
      • 手动访问正常吗？
      • 分组件排查

    • 中间链路排查

      • 服务端跟客户端确保都没问题
      • 中间网络设备有没有问题？（交换机 / 路由器 / 网关 LB）
      • 旁路的 DNS 有没有问题？

  • 故障排查常用命令

    • dig 查询 DNS 问题
    • ping / telnet / nmap查询三层 / 四层连通性
    • Traceroute 排查中间链路
    • iptabels
    • tcpdump

例一：客户端异常→服务端自测正常→网关转发异常→健康检查异常

健康检查误判，把正常的节点摘掉了

例二：个别用户报障，生产环境大多是客户端的问题

例三：安徽电信报障某 APP 无法使用→检测后端服务正常，安徽电信流量突降→安徽电信客户端 ping 不通目标服务→电缆被挖断

例四：某 APP 故障→后端服务器反馈服务正常→网络转发设备异常→抓包→路由不对称

  • 快速发包 fast xmit 默认路由对称（源 MAC \Leftrightarrow 目标 MAC），导致目标 MAC 有问题

故障预防

  • 监控报警
  • 故障演练 / 预案
  • 故障降级 / 止损
avatar
文章
阅读
粉丝