day7 | 打开抖音互联网会发生什么 | 第三届字节跳动青训营笔记

2022-11-11 16:40:11 浏览数 (1)

字节跳动青训营系列文章

  1. day1 | Go语言上手-基础语言 | 字节跳动青训营笔记
  2. day2 | Go语言上手-工程实践 | 字节跳动青训营笔记
  3. day3 | 高质量编程与性能调优实战 | 字节跳动青训营笔记
  4. day4 | 高性能 Go 语言发行版优化与落地实践 | 字节跳动青训营笔记
  5. day5 | 设计模式之Database/SQL与GORM实践 | 字节跳动青训营笔记
  6. day6 | 从需求到上线全流程 实操课 | 字节跳动青训营笔记
  • 「打开抖音互联网会发生什么」 第三届字节跳动青训营 - 后端专场
  • 这篇课程我可以学到什么？
  • 目录
  • 1.1 网络接入-互联网
  • 1.2 网络接入路由
  • 1.2 网络接入-路由
  • 1.3 网络接入-ARP协议
  • 1.3 网络接入-IP协议
  • 1.3 网络接入-NAT
  • 1.4 网络传输数据包
  • 1.5 网络传输-数据包发送
  • 1.6 网络传输-先请求DNS
  • 1.7 网络传输- DNS的传输协议UDP
  • 1.8 网络传输-TCP三次握手
  • 1.8 网络传输-TCP传输
  • 1.9 网络传输-HTTP/HTTP1.1
  • 1.9 网络传输-HTTPS
  • 1.10 网络传输-SSL/TLS握手
  • 2.1 网络提速-HTTP2.0
  • 2.2 网络提速-怎么理解多路复用/stream?
  • 2.3 网络提速-QUIC/HTTP3.0
  • 2.4 网络提速数据中心分布
  • 2.5 网络提速-同运营商访问
  • 2.6 网络提速静态资源(图片视频)路径优化(CDN)
  • 2.7 网络提速-动态API (播放/评论接口)路径优化(DSA)
  • 2.8 网络稳定容灾概念
    • 2.8.1 网络容灾的具体案例一
    • 2.8.2 网络容灾的具体案例二
    • 2.8.3 网络容灾的具体案例三
    • 2.8.4网络容灾的具体案例四
  • 2.9 网络稳定-故障排查
    • 2.10 网络稳定-故障明确
    • 2.11 网络稳定-故障止损
    • 2.12 网络稳定分段排查
  • 2.13网络稳定-网络故障排查常用命令
    • 2.13.1 网络故障排查案例一
    • 2.13.2 网络故障排查案倒二
    • 2.13.3 网络故障排查案例三
    • 2.13.4 网络故障排查案例四
    • 2.14 网络稳定-故障预防很重要
  • 课后作业1
  • 课后作业2

这是我参与「第三届青训营 -后端场」笔记创作活动的的第7篇笔记。计算机网络真的是太庞大了

「打开抖音互联网会发生什么」 第三届字节跳动青训营 - 后端专场

同时这也是课表的第7天课程《计算机网络基本概念与实际应用》

PC端阅读效果更佳，点击文末：阅读原文即可。

这篇课程我可以学到什么？

  • 从事其他方向研发 / 从事网络相关研发
  • 简历更新(熟悉TCP/IP、计算机网络)
  • 协议分析(自学) / 互联网应用泛解
  • 协议基础/为什么会产生这些协议

看一下刷抖音这里，这里客户端与服务端之间有哪些协议

目录

1. 刷抖音网络是怎么交互的?

网络接入 | 网络传输

1.1 网络接入-互联网

1.2 网络接入路由

1.2 网络接入-路由

  • 路由一定是对称的吗? 不一定
  • 路由是工作在哪一层协议? 网络层
  • 那路由是改的IP地址吗? 路由是改Mac，找到发包口

怎么找到下一跳的MAC ?

1.3 网络接入-ARP协议

1.3 网络接入-IP协议

  • 唯一标识，互联网通用。一个抖音客户端，一个抖音服务端。
  • Mac地址不能代替IP地址吗?
  • IPv4不够用，一般怎么解决的?

1.3 网络接入-NAT

“➢家里路由器是怎样上网的? ➢多个内网客户端访问同一个目标地址 端口，源端口恰好一样， 冲突了?

网络打通了怎么视频怎么下载?

1.4 网络传输数据包

1.5 网络传输-数据包发送

1.6 网络传输-先请求DNS

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

1.7 网络传输- DNS的传输协议UDP

1.8 网络传输-TCP三次握手

三次握手过程：

  1. 客户端——发送带有SYN标志的数据包——服务端 一次握手 客户端进入syn_sent状态
  2. 服务端——发送带有SYN/ACK标志的数据包——客户端 二次握手 服务端进入syn_rcvd
  3. 客户端——发送带有ACK标志的数据包——服务端 三次握手 连接就进入Established状态

为什么三次： 主要是为了建立可靠的通信信道，保证客户端与服务端同时具备发送、接收数据的能力。

为什么两次不行？

  1. 防止已失效的请求报文又传送到了服务端，建立了多余的链接，浪费资源。
  2. 两次握手只能保证单向连接是畅通的。（为了实现可靠数据传输， TCP 协议的通信双方， 都必须维护一个序列号， 以标识发送出去的数据包中， 哪些是已经被对方收到的。三次握手的过程即是通信双方 相互告知序列号起始值， 并确认对方已经收到了序列号起始值的必经步骤；如果只是两次握手， 至多只有连接发起方的起始序列号能被确认， 另一方选择的序列号则得不到确认）。

1.8 网络传输-TCP传输

“➢为什么老问你Timewait? ➢丢包怎么办? ➢滑动窗口再结合基础概念去理解 ➢流量控制/拥塞控制结合基础概念去理解

典型的tcp协议要求每一个数据段发送之后都要有一个ack回复， 然后才能发送下一个数据段，虽然这样能保证数据的可靠传输，但是效率呢?

由于tcp是全双工通信，在等待一个数据段的ack恢复之前网络将会闲置，因此效率将会受到极大影响，因此协议提出了滑动窗口子协议，专门负责数据的传输，滑动窗口子协议分为简单的停等协议，后退N协议，以及选择重传协议三个子协议，其实三个子协议可以由一个例程表示，只是一个例程的三个不同情况， 比如发送和接收窗口都为1时就是简单的停等协议。三个子协议都很复杂，只有靠这种复杂的机制才换取了网络链路的高效利用。

1.9 网络传输-HTTP/HTTP1.1

“为什么不直接用TCP通信呢? 为什么互联网上那么多HTTP通信?

其实HTTP只是多加了一层规矩。HTTP依然是TCP，只是这个规矩让用户更清晰/更简洁。

HTTP1.1哪些优化?

  1. 长连接：减少了建立和关闭连接的消耗和延迟。
  2. 缓存处理：1.1添加更多的缓存控制策略（如：Entity tag，If-Match）
  3. Host头处理：支持Host头域，不在以IP为请求方标志
  4. 网络连接的优化：1.1支持断点续传
  5. 错误状态码的增多：1.1新增了24个错误状态响应码，丰富的错误码更加明确各个状态

1.9 网络传输-HTTPS

传输中被插入小网站怎么办?

HTTPS解密出来依然是HTTP

1.10 网络传输-SSL/TLS握手

对称加密和非对称加密

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

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

网络提速 | 网络稳定

2.1 网络提速-HTTP2.0

当我打开抖音这个小姐姐主页的时候，可以并行去下载这么多视频，提高我们的效率（IO多路复用）

如果是一张图一张图这样下载的话，那我们看到的是一张图，其他的图片都在加载（转圈圈中）。这样对用户的体验是非常不友好的。

2.2 网络提速-怎么理解多路复用/stream?

➢单个TCP链接传输 ➢如果TCP丢包怎么办?

2.3 网络提速-QUIC/HTTP3.0

“Quic不是四层协议!很多博客胡说八道

➢TCP or UDP? ➢Kernel or Userspace ➢0 RTT ➢弱网优势

除了协议优化，网络路径能不能优化？

2.4 网络提速数据中心分布

2.5 网络提速-同运营商访问

如果是中国移动的话就解析到中国移动，如果是电信就解析到电信

2.6 网络提速静态资源(图片视频)路径优化(CDN)

cdn针对的是静态资源优化，简单理解为一个缓存。

2.7 网络提速-动态API (播放/评论接口)路径优化(DSA)

从路径算法优化，先从A到B进行探测，最终通过机房与机房之间的延迟可以找到最优化的路径

刷的快，但是三天两天挂掉，谁刷抖音?

2.8 网络稳定容灾概念

容灾大多是通过网络手段去控制的。补充容灾的背景发展，为什么要容灾。

容灾系统是指在相隔较远的异地，建立两套或多套功能相同的IT系统，互相之间可以进行健康状态监视和功能切换，当一处系统因意外（如火灾、地震等）停止工作时，整个应用系统可以切换到另一处，使得该系统功能可以继续正常工作。容灾技术是系统的高可用性技术的一个组成部分，容灾系统更加强调处理外界环境对系统的影响，特别是灾难性事件对整个IT节点的影响，提供节点级别的系统恢复功能。

2.8.1 网络容灾的具体案例一

专线：指定规划好路线，可直达。（跨机房调用）

外网容灾：如果专线不可用，就走外网容灾

2.8.2 网络容灾的具体案例二

调度容灾

容灾大多是通过网络手段去控制的。补充容灾的背景/发展，为什么要容灾。

2.8.3 网络容灾的具体案例三

2.8.4网络容灾的具体案例四

类似cdn缓存，降级

没有容灾的故障怎么查?

2.9 网络稳定-故障排查

在这里插入图片描述

2.10 网络稳定-故障明确

出现什么故障? -> 沟通是前提

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

2.11 网络稳定-故障止损

从程序员角度分析处理流程，再切入细节。有通用的流程/全景图。

先止损再排查

  1. 用户体验第一
  2. 对公司收入的影响是按照分钟甚至秒来计算

如何止损

  1. 组件没有容灾，但是系统有没有?
  2. 降级（上线后出现问题，回退版本）

2.12 网络稳定分段排查

客户端排查

  1. 客户端访问其他服务没问题吗?
  2. 其他客户端访问目标服务没问题吗?

服务端排查

  1. 服务端监控/指标都正常吗?
  2. 手动访问一下正常吗?
  3. 分组件排查

中间链路排查

  1. 服务端跟客户端确保都没问题
  2. 中间网络设备有没有问题? (交换机/路由器/网关LB)
  3. 旁路的DNS有没有问题?

2.13网络稳定-网络故障排查常用命令

  • dig查询DNS问题
  • ping/telnet/nmap查询三层/四层连通性
  • Traceroute排查中间链路 （丢包）
  • iptabels （防火墙有问题）
  • tcpdump （抓包调试）

2.13.1 网络故障排查案例一

客户端异常->服务端自测正常->网关转发异常->健康检查异常

2.13.2 网络故障排查案倒二

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

2.13.3 网络故障排查案例三

2.13.4 网络故障排查案例四

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

2.14 网络稳定-故障预防很重要

➢监控报警 ➢故障演练/预案 ➢故障降级/止损

总结

课后作业1

UDP socket实现ack, 感知丢包重传

提示:

  1. 学会UDP socket编程
  2. 先从简单的ack学习，客户端等待ack再发包
  3. 什么时候客户端认为是丢包?
  4. 重传怎么考虑效率?
  5. 能不能不阻塞只穿丢掉的中间的段?

课后作业2

三台同网段内的服务器，模拟实现一个路由器

方法一: Linux操作系统配置法提示:

  1. 了 解Linux的路由配置方式
  2. 确保是同网段直连可达的环境。在三台机器上另外配置IP网段和路由。
  3. 台机器做客户端，一台机器做路由器，一台机器做服务端。
  4. 客户端配置到达服务器的下一跳指向路由器，路由器上配置到达服务端的路由

方法二: 用户态socket编程实现简易route软件提示:

  1. 收到指定的包后，做转发
  2. 注意是修改报文的MAC。不是修改IP。
  3. 实现一个对称路由。这样可以实现TCP交互
  4. 可以通过ping来验证
  5. 可以支持traceroute吗?

参考文献

  1. https://zhuanlan.zhihu.com/p/379580156
  2. https://wwwjianshu.com/p/15754b4e9458/
  3. https://blog.csdn.net/achenwenping/article/details/80627599
  4. https://baijiahao.baidu.com/s?id=1727869144490491655&wfr=spider&xfor=pc
tcp/ip http https dns 网络安全

0 人点赞