这是我参与「第三届青训营 -后端场」笔记创作活动的的第4篇笔记
1 刷抖音是怎么交互的
1.1 网络接入
互联网
路由
同网段
路由分为同网段和跨网段,同网段通过交换机或者软件定义的虚拟连接
同网段如何发包/交互?
同网段发包,通过改目标ip的MAC地址
跨网段
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、路由一定是对称的吗?
路由不一定是对称的,每次转发的路径不一定相同
2、路由是工作在哪一层协议?
RIP基于UDP,BGP基于TCP,OSPF和EIGRP基于IP。这些在TCP/IP协议栈中定义的路由协议用于发现和维护前往目的地的最短路径,可以认为它们不属于网络层协议,总体来说路由工作在网络层
3、路由是改ip地址吗?
路由是改MAC地址,发包过程中,源IP地址和目的IP地址是不会变得,源MAC和目标MAC会不断改变
ARP协议
在传输一个 IP 数据报的时候,确定了源 IP 地址和目标 IP 地址后,就会通过主机「路由表」确定 IP 数据包下一跳。然而,网络层的下一层是数据链路层,所以我们还要知道「下一跳」的 MAC 地址。由于主机的路由表中可以找到下一跳的 IP 地址,所以可以通过ARP 协议,求得下一跳的 MAC 地址。逻辑同网段才能发送ARP,ARP请求是广播,应答是单播
免费ARP的作用
- 该类型报文起到一个宣告作用。它以广播的形式将数据包发送出去,不需要得到回应,只为了告诉其他计算机自己的 IP 地址和 MAC 地址。
- 可用于检测 IP 地址冲突。当一台主机发送了免费 ARP 请求报文后,如果收到了 ARP 响应报文,则说明网络内已经存在使用该 IP 地址的主机。
- 可用于更新其他主机的 ARP 缓存表。如果该主机更换了网卡,而其他主机的 ARP 缓存表仍然保留着原来的 MAC 地址。这时,可以发送免费的 ARP 数据包。其他主机收到该数据包后,将更新 ARP 缓存表,将原来的 MAC 地址替换为新的 MAC 地址。
ARP代理
当出现跨网段的ARP请求时,路由器将自己的MAC返回给发送ARP广播请求发送者,实现MAC地址代理,最终使得主机能够通信。
IP协议
-
唯一标识,互联网通用,抖音客户端一个,抖音服务器一个
-
Mac地址不能代替IP地址吗?
MAC地址位于网络协议的数据链路层,数据链路层有很多协议,互联网终端有可能不支持Mac协议,为了向下兼容再封装一层IP层,解决地址的统一问题
-
Ipv4不够用,一般怎么解决?
NAT转换
NAT
内部用户通过NAT设备,修改源地址,可以复用ip地址,只需要保证连接外网的ip唯一就行
多个内网客户端访问同一个目标地址+端口,源端口恰好一样,是否冲突?
NAT是改了IP地址和端口,不会出现冲突
1.2 网络传输
数据包
数据包发送
DNS解析
-
客户端发www.douyin.com的解析请求
-
递归解析器去问 "." ,com.去哪里解析
-
递归解析器去问 "com." ,douyin.com去哪里解析
-
douyin.com告诉递归解(www.douyin.com解析到XXX)
UDP
UDP本身实现先比较TCP实现相对简单,想发什么包,就分配一个头,把playload里面塞数据发出去就好
TCP 三次握手
什么是TCP连接?
唯一地被通信两端的两个端点所确定,建立起的状态就是TCP连接
拔了网线,连接会断吗?
TCP具有保活机制,定期会发送探测报文,如果没有收到ack,那么就可以判断网线已经断掉了,就会断开TCP连接,如果没有保护机制,连接会直接断开
MSS: 最大报文段长度,是TCP数据包每次能够传输的最大数据分段
一般情况下,通信双方在建立连接时,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加一。
为什么需要TIME-WAIT状态?
需要 TIME-WAIT 状态,主要是两个原因:
- 防止历史连接中的数据,被后面相同四元组的连接错误的接收;
- 保证「被动关闭连接」的一方,能被正确的关闭;
丢包怎么办?
如果没有返回ack响应,重传包
HTTP/HTTP1.1
1、为什么不直接用TCP通信?
其实HTTP只是多加了一层规则。HTTP依然是TCP,只是这个规则让用户更清晰,更简介
2、HTTP1.1做了哪些优化?
- 长连接
- 部分传输
- HOST
- 缓存
HTTPS
使用非对称加密+对称加密的方式
确保没有胁持,也确保私钥不泄密
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
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 队头阻塞问题。
数据中心发布
同运营访问
三大运营商跨网的质量比较差,容易丢包,通过域名智能解析实现同运营访问,提高网络提速
路径优化CDN
CDN,即内容分发网络,CDN是构建在现有网络基础之上的智能虚拟网络,依靠部署在各地的边缘服务器,通过中心平台的负载均衡、内容分发、调度等功能模块,使用户就近获取所需内容,降低网络拥塞,提高用户访问响应速度和命中率;CDN的关键技术主要有内容存储和分发技术。
通俗讲其主要功能就是让在各个不同地点的网络用户,都能够快速访问到网站提供的内容,不会经常出现等待或是卡顿的状况。
2.2 网络稳定
容灾概念
- 故障发生
- 故障感知
- 自动切换
- 服务恢复
故障排查
-
故障明确
- 什么业务?什么接口故障?
- 故障体现在哪里?
- 访问其他目标是否正常?
- 是否是修改导致的异常?
-
故障止损
-
先止损再排查
- 用户体验第一
- 对公司的收入影响是按照分钟甚至秒来计算
-
如何止损
- 组件没有容灾,但是系统没有?
- 降级
-
-
分段排查
-
客户端排查
- 客户端访问其他服务没问题?
- 其他客户端访问目标服务没问题?
-
服务端排查
- 服务端监控/指标都正常吗?
- 手动访问一下正常吗?
- 分组件排查
-
中间链路排查
- 服务端跟客户端确保都没问题
- 中间网络设备有没有问题
- 旁路的DNS有没有问题
-
故障预防
- 监控报警
- 故障演练
- 故障降级