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

114 阅读11分钟

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

1 刷抖音是怎么交互的

1.1 网络接入

互联网

image.png

路由

同网段

image.png

路由分为同网段和跨网段,同网段通过交换机或者软件定义的虚拟连接

同网段如何发包/交互?

同网段发包,通过改目标ip的MAC地址

跨网段

image.png

IP 地址分成两种意义:

  • 一个是网络号,负责标识该 IP 地址是属于哪个「子网」的;
  • 一个是主机号,负责标识同一「子网」下的不同主机;

这需要配合子网掩码才能算出 IP 地址 的网络号和主机号。

举个例子,比如 10.100.122.0/24,后面的/24表示就是 255.255.255.0 子网掩码,255.255.255.0 二进制是「11111111-11111111-11111111-00000000」,大家数数一共多少个1?不用数了,是 24 个1,为了简化子网掩码的表示,用/24代替255.255.255.0。

怎么计算出网络地址和主机地址呢?

将 10.100.122.2 和 255.255.255.0 进行按位与运算,就可以得到网络号和主机号

在寻址的过程中,先匹配到相同的网络号(表示要找到同一个子网),才会去找对应的主机。

1、路由一定是对称的吗?

image.png

路由不一定是对称的,每次转发的路径不一定相同

2、路由是工作在哪一层协议?

RIP基于UDP,BGP基于TCP,OSPF和EIGRP基于IP。这些在TCP/IP协议栈中定义的路由协议用于发现和维护前往目的地的最短路径,可以认为它们不属于网络层协议,总体来说路由工作在网络层

3、路由是改ip地址吗?

路由是改MAC地址,发包过程中,源IP地址和目的IP地址是不会变得,源MAC和目标MAC会不断改变

ARP协议

image.png

在传输一个 IP 数据报的时候,确定了源 IP 地址和目标 IP 地址后,就会通过主机「路由表」确定 IP 数据包下一跳。然而,网络层的下一层是数据链路层,所以我们还要知道「下一跳」的 MAC 地址。由于主机的路由表中可以找到下一跳的 IP 地址,所以可以通过ARP 协议,求得下一跳的 MAC 地址。逻辑同网段才能发送ARP,ARP请求是广播,应答是单播

免费ARP的作用

  1. 该类型报文起到一个宣告作用。它以广播的形式将数据包发送出去,不需要得到回应,只为了告诉其他计算机自己的 IP 地址和 MAC 地址。
  2. 可用于检测 IP 地址冲突。当一台主机发送了免费 ARP 请求报文后,如果收到了 ARP 响应报文,则说明网络内已经存在使用该 IP 地址的主机。
  3. 可用于更新其他主机的 ARP 缓存表。如果该主机更换了网卡,而其他主机的 ARP 缓存表仍然保留着原来的 MAC 地址。这时,可以发送免费的 ARP 数据包。其他主机收到该数据包后,将更新 ARP 缓存表,将原来的 MAC 地址替换为新的 MAC 地址。

ARP代理

当出现跨网段的ARP请求时,路由器将自己的MAC返回给发送ARP广播请求发送者,实现MAC地址代理,最终使得主机能够通信。

IP协议

  • 唯一标识,互联网通用,抖音客户端一个,抖音服务器一个

  • Mac地址不能代替IP地址吗?

    MAC地址位于网络协议的数据链路层,数据链路层有很多协议,互联网终端有可能不支持Mac协议,为了向下兼容再封装一层IP层,解决地址的统一问题

  • Ipv4不够用,一般怎么解决?

    NAT转换

NAT

image.png

内部用户通过NAT设备,修改源地址,可以复用ip地址,只需要保证连接外网的ip唯一就行

多个内网客户端访问同一个目标地址+端口,源端口恰好一样,是否冲突?

NAT是改了IP地址和端口,不会出现冲突

1.2 网络传输

数据包

image.png

数据包发送

image.png

DNS解析

  • 客户端发www.douyin.com的解析请求

  • 递归解析器去问 "." ,com.去哪里解析

  • 递归解析器去问 "com." ,douyin.com去哪里解析

  • douyin.com告诉递归解(www.douyin.com解析到XXX)

image.png

UDP

UDP本身实现先比较TCP实现相对简单,想发什么包,就分配一个头,把playload里面塞数据发出去就好

image.png

TCP 三次握手

什么是TCP连接?

唯一地被通信两端的两个端点所确定,建立起的状态就是TCP连接

拔了网线,连接会断吗?

TCP具有保活机制,定期会发送探测报文,如果没有收到ack,那么就可以判断网线已经断掉了,就会断开TCP连接,如果没有保护机制,连接会直接断开

MSS: 最大报文段长度,是TCP数据包每次能够传输的最大数据分段

image.png

一般情况下,通信双方在建立连接时,SYN Segment中会携带MSS Option,MSS指明本端可以接受的最大长度的TCP Segment,也就是说,对端发送数据的长度不应该大于MSS(单位Byte)。

MSS并非和对端协商的值,而是对对端发送数据长度的“限制”,表明在整个TCP连接期间,都不会接收长度大于MSS的TCP Segment。

如果收到的SYN中没有MSS,将使用默认值536。MSS Option的Value字段长度固定为16bit,所以MSS最大值为65535(单位Byte)。因此,网络中所有设备都被要求,必须能够处理大小小于576Byte的数据包(IP Header + TCP Header + Default MSS 最小值为 576 Byte)

TCP 传输

  • sequence number:表示的是我方(发送方)这边,这个packet的数据部分的第一位应该在整个data stream中所在的位置。
  • acknowlegde number:表示的是期望的对方的下一次sequence number是多少。注意,SYN/FIN的传输虽然没有data,但是会让下一次传输的packet seq增加一,但是,ACK的传输,不会让下一次的传输packet加一。

image.png

为什么需要TIME-WAIT状态?

需要 TIME-WAIT 状态,主要是两个原因:

  • 防止历史连接中的数据,被后面相同四元组的连接错误的接收;
  • 保证「被动关闭连接」的一方,能被正确的关闭;

丢包怎么办?

如果没有返回ack响应,重传包

HTTP/HTTP1.1

1、为什么不直接用TCP通信?

其实HTTP只是多加了一层规则。HTTP依然是TCP,只是这个规则让用户更清晰,更简介

2、HTTP1.1做了哪些优化?

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

HTTPS

使用非对称加密+对称加密的方式

确保没有胁持,也确保私钥不泄密

image.png

2 网络架构怎么给抖音提质

2.1 网络提速

HTTP2.0

HTTP/2 协议其实还有很多内容,比如流控制、流状态、依赖关系等等。

HTTP/2 是如何提示性能的几个方向,它相比 HTTP/1 大大提高了传输效率、吞吐能力。

第一点,对于常见的 HTTP 头部通过静态表和 Huffman 编码的方式,将体积压缩了近一半,而且针对后续的请求头部,还可以建立动态表,将体积压缩近 90%,大大提高了编码效率,同时节约了带宽资源。

第二点,HTTP/2 实现了 Stream 并发,多个 Stream 只需复用 1 个 TCP 连接,节约了 TCP 和 TLS 握手时间,以及减少了 TCP 慢启动阶段对流量的影响。不同的 Stream ID 才可以并发,即时乱序发送帧也没问题,但是同一个 Stream 里的帧必须严格有序。

另外,可以根据资源的渲染顺序来设置 Stream 的优先级,从而提高用户体验。

第三点,服务器支持主动推送资源,大大提升了消息的传输性能,服务器推送资源时,会先发送 PUSH_PROMISE 帧,告诉客户端接下来在哪个 Stream 发送资源,然后用偶数号 Stream 发送资源给客户端。

HTTP/2 通过 Stream 的并发能力,解决了 HTTP/1 队头阻塞的问题,看似很完美了,但是 HTTP/2 还是存在“队头阻塞”的问题,只不过问题不是在 HTTP 这一层面,而是在 TCP 这一层。

多路复用/stream

队头阻塞问题

HTTP/2 是基于 TCP 协议来传输数据的,TCP 是字节流协议,TCP 层必须保证收到的字节数据是完整且连续的,这样内核才会将缓冲区里的数据返回给 HTTP 应用,那么当「前 1 个字节数据」没有到达时,后收到的字节数据只能存放在内核缓冲区里,只有等到这 1 个字节数据到达时,HTTP/2 应用层才能从内核中拿到数据,这就是 HTTP/2 队头阻塞问题。

QUIC/HTTP3.0

image.png

HTTP/2 虽然具有多个流并发传输的能力,但是传输层是 TCP 协议,于是存在以下缺陷:

  • 队头阻塞,HTTP/2 多个请求跑在一个 TCP 连接中,如果序列号较低的 TCP 段在网络传输中丢失了,即使序列号较高的 TCP 段已经被接收了,应用层也无法从内核中读取到这部分数据,从 HTTP 视角看,就是多个请求被阻塞了;
  • TCP 和 TLS 握手时延,TCL 三次握手和 TLS 四次握手,共有 3-RTT 的时延;
  • 连接迁移需要重新连接,移动设备从 4G 网络环境切换到 WIFI 时,由于 TCP 是基于四元组来确认一条 TCP 连接的,那么网络环境变化后,就会导致 IP 地址或端口变化,于是 TCP 只能断开连接,然后再重新建立连接,切换网络环境的成本高;

HTTP/3 就将传输层从 TCP 替换成了 UDP,并在 UDP 协议上开发了 QUIC 协议,来保证数据的可靠传输。

QUIC 协议的特点:

  • 无队头阻塞,QUIC 连接上的多个 Stream 之间并没有依赖,都是独立的,也不会有底层协议限制,某个流发生丢包了,只会影响该流,其他流不受影响;
  • 建立连接速度快,因为 QUIC 内部包含 TLS1.3,因此仅需 1 个 RTT 就可以「同时」完成建立连接与 TLS 密钥协商,甚至在第二次连接的时候,应用数据包可以和 QUIC 握手信息(连接信息 + TLS 信息)一起发送,达到 0-RTT 的效果。
  • 连接迁移,QUIC 协议没有用四元组的方式来“绑定”连接,而是通过「连接 ID 」来标记通信的两个端点,客户端和服务器可以各自选择一组 ID 来标记自己,因此即使移动设备的网络变化后,导致 IP 地址变化了,只要仍保有上下文信息(比如连接 ID、TLS 密钥等),就可以“无缝”地复用原连接,消除重连的成本;

另外 HTTP/3 的 QPACK 通过两个特殊的单向流来同步双方的动态表,解决了 HTTP/2 的 HPACK 队头阻塞问题。

数据中心发布

image.png

同运营访问

image.png

三大运营商跨网的质量比较差,容易丢包,通过域名智能解析实现同运营访问,提高网络提速

路径优化CDN

CDN,即内容分发网络,CDN是构建在现有网络基础之上的智能虚拟网络,依靠部署在各地的边缘服务器,通过中心平台的负载均衡、内容分发、调度等功能模块,使用户就近获取所需内容,降低网络拥塞,提高用户访问响应速度和命中率;CDN的关键技术主要有内容存储和分发技术。

通俗讲其主要功能就是让在各个不同地点的网络用户,都能够快速访问到网站提供的内容,不会经常出现等待或是卡顿的状况。

image.png

2.2 网络稳定

容灾概念

  • 故障发生
  • 故障感知
  • 自动切换
  • 服务恢复

故障排查

  • 故障明确

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

    • 先止损再排查

      • 用户体验第一
      • 对公司的收入影响是按照分钟甚至秒来计算
    • 如何止损

      • 组件没有容灾,但是系统没有?
      • 降级
  • 分段排查

    • 客户端排查

      • 客户端访问其他服务没问题?
      • 其他客户端访问目标服务没问题?
    • 服务端排查

      • 服务端监控/指标都正常吗?
      • 手动访问一下正常吗?
      • 分组件排查
    • 中间链路排查

      • 服务端跟客户端确保都没问题
      • 中间网络设备有没有问题
      • 旁路的DNS有没有问题

故障预防

  • 监控报警
  • 故障演练
  • 故障降级