day7-打开抖音互联网会发生什么-计算机网络
1. 刷抖音网络是怎么交互的?
1.1 网络接入-互联网
1.2 网络接入-路由
- 路由一定是对称的吗? 不一定 发送与返回的路由路径不一定一样
- 路由是工作在哪一层协议? 网络层 IP在IP层
- 那路由是改的IP地址吗? 路由是改Mac,找到发包口 目标IP不变,找路,目标MAC; 发送的网口
1.3 网络接入-ARP协议
找MAC:在以太网环境下,通过3层的IP地址来找寻2层的MAC地址,得到一张ARP缓存表。转发数据的时候根据ARP缓存表来进行传输。
- 逻辑同网段才能发ARP:不是直接发ARP找目标服务器,而是一级一级找下一跳,发ARP
- 免费ARP(Gratuitous ARP):当主机启动的时候,请求的是自己 IP 地址的 MAC 地址. 宣告:不需要得到回应,只为了告诉其他计算机自己的 IP 地址和 MAC 地址。 可用于检测 IP 地址冲突:如果收到了 ARP 响应报文,则说明网络内已经存在使用该 IP 地址的主机。 更新其他主机上的 ARP 缓存表
- ARP 代理:使用一个主机(通常为router)对另一设备的ARP请求作出应答。劫持ARP请求,构建虚拟网络
1.3 网络接入-IP协议
- 唯一标识,互联网通用。一个抖音客户端,一个抖音服务端。
- Mac地址不能代替IP地址: IP地址是网络层使用的地址,它能唯一地确定一台主机在网络中的位置,并能区分不同的网络 MAC地址是数据链路层使用的地址,它也能唯一地确定一台主机在网络中的位置。但是它不能很好地区分不同的网络。MAC地址只能说明主机的适配器是哪个厂家生产的并不能标识出在哪里个网络中。 不同网络中进行传输时,其MAC帧首部中的源地址和摸底地址要发生改变
- IPv4不够用,一般怎么解决的
1.3 网络接入-NAT
网络地址转换:设备可以用同一个公网地址来转换多个私网用户发过来的报文,并通过端口号来区分不同的私网用户,从而达到地址复用的目的
解决IP地址不足的问题,而且还能够有效地避免来自网络外部的攻击,隐藏并保护网络内部的计算机。
➢多个内网客户端访问同一个目标地址+端口,源端口恰好一样, 冲突了? 更改了 IP + 端口,源端口也会改
网络打通了怎么视频怎么下载?
1.4 网络传输-数据包
1.5 网络传输-数据包发送
1.6 网络传输-先请求DNS
Domain Name System:域名和IP地址相互映射
- 客户端发www.douyin.com的解析请求(本地DNS服务器无缓存记录)
- 递归解析器去问“.”,com.去哪里解析
- 递归解析器去问".com"(顶级域),douyin.com去哪里解析
- douyin.com告诉递归解www.douyin.com解析到xxx
递归查询:如果主机所询问的本地域名服务器不知道被查询的域名的 IP 地址,那么本地域名服务器就以 DNS 客户的身份,向其它根域名服务器继续发出查询请求报文(即替主机继续查询),而不是让主机自己进行下一步查询。
1.7 网络传输-DNS的传输协议UDP
1.8 网络传输-TCP三次握手
连接的状态:拔了网线不代表不在TCp连接状态(ACK)
Tcpdump + Wireshark
三次握手过程:
- 客户端——发送带有
SYN标志的数据包——服务端 一次握手 客户端进入syn_sent状态 - 服务端——发送带有
SYN/ACK标志的数据包——客户端 二次握手 服务端进入syn_rcvd - 客户端——发送带有
ACK标志的数据包——服务端 三次握手 连接就进入Established状态
为什么三次: 主要是为了建立可靠的通信信道,保证客户端与服务端同时具备发送、接收数据的能力。
为什么两次不行?
- 防止已失效的请求报文又传送到了服务端,建立了多余的链接,浪费资源。
- 两次握手只能保证单向连接是畅通的。(为了实现可靠数据传输,
TCP协议的通信双方, 都必须维护一个序列号, 以标识发送出去的数据包中, 哪些是已经被对方收到的。三次握手的过程即是通信双方 相互告知序列号起始值, 并确认对方已经收到了序列号起始值的必经步骤;如果只是两次握手, 至多只有连接发起方的起始序列号能被确认, 另一方选择的序列号则得不到确认)。
1.8 网络传输-TCP传输
回复的ACk+1:期望的下次收到的ack(SYN/FIN会使下次seq+1,或者数据发送+1)
-
为什么老问你Timewait? 2MSL(最大报文段生存时间)等待期间,这个连接的插口(客户端IP地址和端口号,服务器IP地址和端口号的四元组)将不能再被使用. 1.允许老的重复报文分组在网络中消逝。 2.保证TCP全双工连接的正确关闭。 一个web服务器最大的端口数量是65535个,如果这个服务器作为客户端不停的和服务端不停的创建短连接,就会导致有大量的TCP进入TIME_WAIT状态。高并发的情况下大量连接无法建立的问题:
tw_recyceltw_reuse -
丢包怎么办? ACK机制判断,重传
-
滑动窗口
-
流量控制/拥塞控制
典型的tcp协议要求每一个数据段发送之后都要有一个ack回复, 然后才能发送下一个数据段,虽然这样能保证数据的可靠传输,但是效率呢?
由于tcp是全双工通信,在等待一个数据段的ack恢复之前网络将会闲置,因此效率将会受到极大影响,因此协议提出了滑动窗口子协议,专门负责数据的传输,滑动窗口子协议分为简单的停等协议,后退N协议,以及选择重传协议三个子协议,其实三个子协议可以由一个例程表示,只是一个例程的三个不同情况, 比如发送和接收窗口都为1时就是简单的停等协议。三个子协议都很复杂,只有靠这种复杂的机制才换取了网络链路的高效利用。
1.9 网络传输-HTTP/HTTP1.1
其实HTTP只是多加了一层规矩(专用语)。HTTP依然是TCP,只是这个规矩让用户更清晰/更简洁。
HTTP1.1哪些优化?:
- 长连接(主要):减少了建立和关闭连接的消耗和延迟。
- 缓存处理:1.1添加更多的缓存控制策略(如:
Entity tag,If-Match) - Host头处理:支持
Host头域,不在以IP为请求方标志 - 网络连接的优化:1.1支持断点续传
- 错误状态码的增多:1.1新增了24个错误状态响应码,丰富的错误码更加明确各个状态
1.9 网络传输-HTTPS
HTTPS解密出来依然是HTTP 加密
1.10 网络传输-SSL/TLS握手
非对称加密:第三方CA
2. 网络架构怎么给抖音提质
网络提速 | 网络稳定
2.1 网络提速-HTTP2.0
并行下载,提高效率(IO多路复用)
如果是一张图一张图这样下载的话,那我们看到的是一张图,其他的图片都在加载(转圈圈中)。这样对用户的体验是非常不友好的。
2.2 网络提速-怎么理解多路复用/stream?
- 单个TCP链接传输 宏观上并行
- 如果TCP丢包怎么办? 一个包等待重传,后面的阻塞:队头阻塞(option:ACK序列号,重传对应的)
2.3 网络提速-QUIC/HTTP3.0
- TCP or UDP?
TCP热插拔不方便,UDP更方便推广 - Kernel or Userspace 内核适配不易,用户态
- 0 RTT 双方通信的第一个数据包就可以携带有效的业务数据 对于TCP:三次握手,必然带来1个RTT 非对称TSL加密消耗2RTT:非首次连接时,QUIC 可以做到 0RTT
- 弱网优势 解决了队头阻塞,优势
Quic不是四层协议 不止传输层:多路复用(应用层)
除了协议优化,网络路径能不能优化?
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 网络稳定-故障止损
从程序员角度分析处理流程,再切入细节。有通用的流程/全景图。
先止损再排查:
- 用户体验第一
- 对公司收入的影响是按照分钟甚至秒来计算
如何止损:
- 组件没有容灾,但是系统有没有?
- 降级(上线后出现问题,回退版本)
2.12 网络稳定分段排查
客户端排查
- 客户端访问其他服务没问题吗?
- 其他客户端访问目标服务没问题吗?
服务端排查
- 服务端监控/指标都正常吗?
- 手动访问一下正常吗?
- 分组件排查
中间链路排查
- 服务端跟客户端确保都没问题
- 中间网络设备有没有问题? (交换机/路由器/网关LB)
- 旁路的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 网络稳定-故障预防很重要
➢监控报警 ➢故障演练/预案 ➢故障降级/止损