这是我参与「第三届青训营 -后端场」笔记创作活动的的第3篇笔记。
1. 刷抖音网络是怎么交互的？
1.1 互联网与路由
- 我们可以通过wifi或者有线接入网络，网络之间可通过光缆相连。
- 同网段发包/交互直接通过 （逻辑）交换机进行交互，基于ARP协议找到对应的MAC地址。
- 对于跨网段的交互需要通过路由，路由改的是MAC地址，找到对应的发包口后再修改源MAC地址和目标MAC地址。
- 路由不一定是对称的。
1.2 ARP协议
- 只有逻辑同网段才能发送ARP请求。
- ARP请求广播，ARP应答单播。
- ARP协议：查找同网段的目标MAC地址，或是查找下一跳的MAC地址（跨网段），而不是请求的目标地址。
- 免费ARP：主机将ARP Request广播报文中的目的IP地址字段设置为自己的IP地址，且该网络中所有主机包括网关都会收到此报文，当目的IP地址已经被一个主机或网关使用时，该主机或网关就会回应ARP Reply报文，就能检测IP地址冲突。
- 代理ARP：目的IP和源IP位于不同网络，由于源主机未配置网关，所以将会广播ARP Request报文请求目的主机MAC地址。启动代理ARP后，路由器收到这样的请求会查找路由表中是否存在目的主机的路由表项，如果有则将使用自己的G0/0/0接口的MAC地址来回应该ARP Request。主机A收到ARP Reply后，将以路由器的G0/0/0接口MAC地址作为目的MAC地址进行数据转发。
1.3 IP协议
- IP是互联网通用的唯一标识。
- MAC地址不能代替IP地址：MAC协议是一个二层协议，二层协议不仅仅只有MAC协议（还比如电话等），如果用MAC地址代替IP地址，则会出现向下不兼容的问题。IP协议是为了统一封装所有二层协议。
- IPv4地址不够用如何解决：可以使用IPv6协议，或者使用NAT。
1.4 数据包发送
1.5 DNS解析
1.6 TCP拔了网线以后连接会断吗
拔了网线以后TCP连接逻辑上不会断，不会直接影响TCP连接状态。具体需要看拔掉网线后，是否有数据传输。
-
有数据传输：
- 在客户端拔掉网线后，如果服务端发送数据报文，在服务端重传次数没有达到最大值前，客户端插回网线，那么原本的TCP连接将正常恢复。
- 如果在插回网线前服务器重传次数达到最大值，服务器将断开TCP连接。
-
没有数据传输：
- 若开启了TCP的keepalive机制，拔掉网线后如果一段时间内没有插回网线，TCP心跳检测将会断开TCP连接。
- 若双方都没有开启TCP的keepalive机制，则TCP连接状态将会一直保持。
1.7 TCP有限状态机
- TIME_WAIT：需要等待两个MSL（Maximum Segment Lifetime）后正常关闭TCP连接，防止前一次ACK丢失。
1.8 HTTP 1.0/1.1
-
为什么不直接使用TCP通信呢：HTTP是对TCP协议的封装，让开发者能够更关注业务的实现，而不用过于关注TCP底层协议的细节。
-
HTTP 1.1 相比于 1.0的优化：
- 默认开启长连接：可以在一个TCP连接上传输多个HTTP请求
- 管道化技术：能在未收到响应时，顺次发送多个请求
- 范围请求：当客户端想要请求文件的一部分时，可以在请求中加入
Range头部，以请求数据的一部分。 - Host字段：在请求头中增加Host字段，用来表示当前的域名地址，服务器可以根据不同的Host值进行处理，提供多个虚拟主机的支持。
- 缓存机制：增加了更多细致的特性，比如
Cache-Control: max-age = N
1.9 HTTPS（SSL/TLS）
SSL/TLS采取的是对称加密与非对称加密的混合加密方式。
- 在通信建立前采用非对称加密（相对来说更安全，需要公钥、私钥共同解密，避免发送这个密钥时候被劫持）的方式交换会话密钥，后续利用这个会话密钥进行对称加密明文数据。
- 非对称加密使用公钥——私钥机制，公钥可以任意分发而私钥保密，更安全，但是相对来说速度慢。
- 对称加密仅使用一个密钥，这个密钥应当保密，速度快，但是不一定安全。
2. 网络架构怎么给抖音提质？
2.1 HTTP 2.0
2.1.1 二进制分帧
HTTP2.0在应用层和传输层之间增加了一个二进制分帧层。HTTP2.0中所有加强性能的核心是二进制传输。在HTTP1.1中，我们是通过文本的方式传输数据，相比于二进制传输来说更复杂。
2.1.2 首部压缩
HTTP1.1不支持首部压缩，大量的重复首部传输影响性能。在HTTP2.0中，我们使用了HPACK压缩格式对传输的header进行编码，减少了header的大小，并在两端维护了索引表，用于记录已出现哎难过的header，后面传输的过程中只需要传输对应的key即可。
2.1.3 多路复用
在HTTP2.0中，基于二进制分帧层，HTTP2.0可以在共享TCP连接的基础上同时发送请求和响应。HTTP消息被分解为独立的帧，可以不破坏消息本身的语义交错发出去，在另一端根据Stream标识符和Header将他们组装起来。提高HTTP传输的吞吐量，同时优化了队头阻塞的问题。
2.1.4 请求优先级
将HTTP消息分为多个独立帧后，可以通过优化这些帧的交错和传输顺序进一步优化性能。
2.2 QUIC/HTTP 3.0
QUIC（Quick UDP Internet Connection）是Google推出的基于UDP的传输协议，实现了TCP + HTTPS + HTTP2.0的功能。
2.2.1 连接迁移
TCP连接是由四元组标识（源IP、源端口号、目标IP、目标端口号） ，其中有一个发生变化则需要重新建立TCP连接。而客户端可能存在不可控且网络环境经常变化，这时候需要重新建立TCP连接，无法做到丝滑的连接迁移，这是TCP协议中无解的问题。
因此我们基于UDP来设计QUIC协议，QUIC基于连接唯一ID来识别连接，当源地址发生改变时，QUIC仍然能保证连接正常与数据正常收发。客户端随机产这个64位的随机数ID。
2.2.2 低连接延时
在传统的HTTP连接中，我们以一次简单的浏览器访问为例：
- DNS递归查询，根据地址解析到对应的IP地址
- TCP三次握手，需要一个RTT
- TLS握手，对于当前TLS1.2来说需要两个RTT，如果非首次连接也需要一个RTT
- HTTP业务数据交互：至少一个RTT
对于数据量小的请求来说，这一次访问就需要4RTT + DNS解析的时间，单次请求握手占用了大量的时间，影响用户体验。
而QUIC基于UDP，无需TCP连接，在最好情况下短连接QUIC可以做到0-RTT开启数据传输。对于RTT敏感的业务，QUIC可以有效的降低连接建立的时延。
QUIC握手过程：
2.2.3 解决队头阻塞
TCP的队头阻塞问题
虽然HTTP2.0 实现了多路复用，但是还是基于面向字节流的TCP，一旦出现丢包，就会影响多路复用下的所有请求流。
TCP队头阻塞的主要原因是数据包超时确认或丢失导致阻塞了当前窗口向右滑动。
QUIC的解决方案
QUIC使用Packet Number代替TCP的Sequence Number，并且每个Packer Number都严格递增，就算其丢失了，重传的Packet N已不再是N，而是一个比N大的值。
QUIC支持乱序确认，当数据包Packet N丢失后，只要有新的已接受数据包确认，当前窗口就会继续向右滑动。待发送方获知数据包Packet N丢失后，会将需要重传的数据包重新发送且重新编号。
QUIC基于Stream ID来标识当前数据流属于哪个资源请求，这也是数据包多路复用传输到接收端能正常组装的依据。
重传的数据包与丢失的数据包靠Stream ID和Stream Offset两个标识来表征是否一致。
2.3 网络路径优化
2.3.1 同运营商访问
同一运营商内网络访问相对来说丢包率低，可通过解析来实现，看看当前IP所属哪个运营商
2.3.2 静态资源优化（CDN）
将一些静态资源（图片、视频）缓存在边缘机房，客户端访问时只需访问边缘机房即可获取到数据，不用进一步的去访问核心机房。
2.3.3 动态API路径优化（DSA）
网络中的各个节点进行延时探测，根据算法选择出一条最优的路径。
2.4 网络容灾
容灾过程
故障发生——故障感知——自动切换——服务恢复
故障排查
-
先止损再排查：用户体验第一，系统容灾、降级
-
分段排查：客户端、服务端、中间链路
-
常用命令：
- dig查询DNS问题
- ping/telnet/nmap查询三层/四层连通性
- Traceroute排查中间链路
- iptabels
- tcpdump
