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

课程资料

网络接入

往同网段如何发包/交互？

改目标ip的MAC为查到的MAC

路由一定是对称的吗？

路由是网状的，不一定是对称的

路由到底是工作在哪一层协议的呢？

大部分说IP/网络层，但其实路由协议本身不只是在IP层，例如BGP/OSPF在传输层，甚至可能需要四层交互

那路由是不是改的IP地址呢？

不是，路由是改MAC地址，找到发包口。
路由不能改IP，改IP目标服务器会收不到包。

为什么发包需要指定网卡？

因为在kernel里发包，以网卡为单位，这样才能知道发到哪里

怎么找到下一跳的MAC

通过ARP协议。
逻辑同网段才能发送ARP，跨网段不能直接向目标IP发送ARP，要通过下一跳一级一级迭代，最终到达服务器。
广播不能跨网段，所以ARP不能跨网段发送。
ARP请求广播，应答单播。
免费ARP：
- 加一台服务器，其他机器往新机器发包，发送免费ARP，告诉其他机器要刷新
- 新增一个IP，发送免费ARP，防止IP冲突
ARP代理：
- 中介作用，中间设备抢先应答（例：交换机劫持一个ARP请求，做一层伪装，发往另外一个地方）
ARP本质：查找下一跳的MAC，不是请求目标地址的MAC

MAC地址为什么不能代替IP地址？

MAC协议是二层的以太网协议，二层不止以太网一个协议，还有电话拨号协议等，但不能废弃。所以要向下兼容，用IP协议统一封装不同的二层网络
MAC地址难记

IPv4不够用怎么办？

用IPv6，很难用尽
不支持IPv6? 用NAT（家里路由器常用）
- 内部用户通过NAT设备改源地址
- NAT把多量的私有IP，换成少量的公有IPv4

多个内网客户端访问同一个目标地址+端口，源端口恰好一样，冲突了？

不会，NAT是同时改IP+端口的

网络传输

数据包发送

本质上是一段内存，里面存储的内存是有序的，一般是按照TCP/IP的多层协议顺序去一层一层封装。拆包/封包都是按照协议去写内存/读内存。

DNS协议

IP难记，所以记域名，DNS请求将域名映射到IP
递归迭代
基于UDP协议，实现简单，用好难，怎么可靠？
- 发包每次多少？怎么避免MTU分片（效率低）？
- 怎么知道没丢包？
- 怎么权衡传输效率和质量？

TCP协议

TCP连接：保持一个虚拟的连接状态
拔了网线，连接会不会断？
- 看有没有TCP保活
三次握手里的option字段
- MSS
- 时间戳
TCP传输
- sequence number
- acknowledge number：expected sequence number
  - SYN/FIN传输，虽然没有data，但会让下一次传输的packet seq+1
  - ACK传输不会让packet+1
- Timewait
  - 确保连接正常关闭
  - 防止前一次的ACK丢失
  - timewait太多会占用端口
    - timewait recycle, timewait reuse：不等timewait，默认网络可靠，直接recycle/reuse
    - 这样有风险，当确实端口冲突时，会连接异常
- 丢包怎么办
  - ack的机制

HTTP/HTTP1.1

本质：TCP+一层规矩（优化），更简洁，更加没有歧义，这样可以关注于代码本身，不用去关注TCP实现，效率更高
HTTP1.1优化：
- 长连接
- 部分传输
- HOST
- 缓存

HTTPS

传输中被插入小网站、被劫持怎么办？
- HTTPS，解密出来依然是HTTP
SSL/TLS握手
- 非对称加密：对于对称加密的算法再做一次加密封装
- 公钥，私钥，证书，可靠的第三方CA

网络提速

协议优化：HTTP2.0

本质：多路复用来提升效率
- 同一个tcp连接通道，多个stream串行（本质是一个一个包在发）
- 例：下载一个用户所有的视频，并行请求，一起响应，一次下载一群视频
- 丢包怎么办
  - 对头阻塞，多路复用不能用

协议优化：QUIC/HTTP3.0

基于TCP还是UDP？
- TCP不好改，所以基于UDP
Kernel还是Userspace实现？
- 对于不同OS的Kernel都要实现一遍吗？No，所以做在用户态里
上面两点导致QUIC成为：1. 可靠的传输协议，2. 解决了对头阻塞的问题
0 RTT
- 优化：原来TLS握手的非对称加密，会耗费RTT去传输
弱网优势
- 弱网容易丢包，QUIC刚好解决丢包问题
本质：对HTTP2.0的多路复用进行优化，解决了对头阻塞的问题

网络路径优化算法

数据中心的分布
- 数据中心：服务器集合的地方
  - 核心机房：核心数据，数据库，30-50
  - pop接入：运营商，增加与internet交互的出入口，100
  - 边缘机房：靠近用户，不是核心，例：省级电信、移动、联通
同运营商访问（中国）
- 跨网质量差，容易丢包
- 解析运营商IP
路径优化CDN
- 静态资源（图片视频）
- 缓存：每个边缘机房，查有没有别人访问过的该视频存在这，如果有，下载；没有再继续访问核心机房等
路径优化DSA
- 动态资源（播放/评论接口）
- 根据每个机房和隔壁机房延时的数据算出最优路径

网络稳定

容灾

故障发生
故障感知
自动切换
- 把有问题的系统从整个系统去掉
服务恢复
- 有问题的系统自动恢复

机房专线故障

环路容灾，避免某条专线故障导致机房孤岛问题（专线是连接各个机房的网络物理路径）

单机房接入节点故障

DNS容灾，摘除故障的节点-字节GTM系统
- 防止雪崩：故障感知，切到其他机房之前，先探测其他机房能不能容纳问题机房的所有容量

云控容灾

云端交互，服务器/云上下发命令到终端-字节TNC系统（基于SDK）
- 局限性
  - 云控本身宕机
  - 用户不让执行某些命令，不给授权
  - 云控控制不到：web页面无法嵌入SDK

cache容灾

源站不可用，降级到之前的缓存内容-字节TLB/ByteCDN等系统的容灾建设
- 返回上一次/上一级缓存的数据

故障排查

故障明确
- 沟通是前提
  - 什么业务？什么接口？
    - 例：业务A故障，接口A有无故障，看其它接口？
  - 体现在哪儿？
    - 例：超时
  - 访问其他目标有无？
    - 例：客户端还是服务端有问题
  - 是否是修改导致？
    - 例：上线后导致故障，回退一下能不能恢复？
故障止损
- 先止损！再排查
- 如何止损
  - 有容灾：容灾
  - 没有容灾：降级
分段排查
- 客户端排查：50%问题
  - 客户端访问其他服务
  - 其他服务访问目标客户端
- 服务端排查：
  - 服务端监控、指标都正常吗
  - 手动访问
  - 分组件排查
- 中间链路排查：
  - 排查服务端和客户端
  - 中间网络设备有问题吗（交换机、路由器、网关LB）
  - 旁路DNS有问题吗

小结

这篇笔记主要总结了“打开抖音互联网会发生什么”一课里的各种Q&A知识点。通过复习本笔记可深入地了解计算机网络知识。

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

课程资料

网络接入

网络传输

网络提速

网络稳定

小结