这是我参与「第三届青训营 -后端场」笔记创作活动的的第7篇笔记
本文主要介绍了网络接入和网络传输过程中涉及的网络协议等网络基础知识,并介绍了网络提速和网络稳定的技术手段
网络基础
网络接入
路由
-
路由一定是对称的吗?
并不是,路由之间的转发其实是可以通过"绕远路"来实现的,并不一定是对称的
-
路由时工作在哪一层协议
可以说是网络层(ip层),但其实这是个复杂的问题,因为像OSPF等一些动态路由协议其实是需要借助tcp/udp等传输层协议的
-
路由在转发过程中改的是ip地址吗?
并不是,改的是mac地址,,从而找到发包口。只有源mac和目标mac会一直变化,目标ip是不会变的
-
路由发包伪代码
ARP协议
ARP协议,基于IP地址找目标地址的MAC地址,本质上是查找下一跳的MAC,不是请求目标地址的MAC。
- 逻辑同网段才能发送ARP
- ARP请求广播,ARP应答单播
- 免费ARP:免费ARP详解,免费 ARP 报文与普通 ARP 请求报文的区别在于报文中的目标 IP 地址。普通 ARP 报文中的目标 IP 地址是其他主机的 IP 地址;而免费 ARP 的请求报文中,目标 IP 地址是自己的 IP 地址。具有宣告自身IP和Mac地址的作用,也可以用来检测IP地址冲突。
- ARP代理:ARP代理
IP协议
- 唯一标识,互联网通用
- Mac地址为啥不能代替IP地址
- mac不方便记忆和记录,难以维护路径表等
- 历史遗留问题,mac协议是二层协议,协议类型多种多样(以太网等),引入IP协议目的是为了统一地址标识,向下兼容,统一不同的二层协议。
- IPV4不够用,如何解决
- IPV6
- NAT
NAT协议
当在专用网内部的一些主机本来已经分配到了本地IP地址(即仅在本专用网内使用的专用地址),但现在又想和因特网上的主机通信(并不需要加密)时,可使用NAT方法。这种方法需要在专用网连接到因特网的路由器上安装NAT软件。装有NAT软件的路由器叫做NAT路由器,它至少有一个有效的外部全球IP地址。这样,所有使用本地地址的主机在和外界通信时,都要在NAT路由器上将其本地地址转换成全球IP地址,才能和因特网连接。
- 将内网不同的ip地址映射到一个统一的公网ip进行外网通信
- NAT不仅仅只改变了IP地址,实际上是同时改变了IP+端口
- 优点:NAT不仅能解决了lP地址不足的问题,而且还能够有效地避免来自网络外部的攻击,隐藏并保护网络内部的计算机。把内网的私有地址,转化成外网的公有地址。使得内部网络上的(被设置为私有IP地址的)主机可以访问Internet。
网络传输
数据包与数据包发送
数据包
发送时按层封装
数据包发送
发送与接收一一对应
DNS解析
递归迭代地询问DNS服务器,过程如下,参考:一张图看懂DNS域名解析全过程
DNS的传输协议UDP
DNS是基于UDP进行传输的,UDP本身相对简单,报文格式如下:
想发什么包,就分配一个UDP的头,往payload里面塞数据发出去就好
用好UDP需要考虑的问题--怎么保证协议可靠?
- 发包每次发多少?怎么避免分片?
- 怎么知道没丢包?
- 怎么权衡传输效率和质量?
TCP三次握手
TCP三次握手目的
- 确保通信双方有接收和发送的能力
- 协商后续沟通的序列号
- 确保建立连接,避免重复的历史连接
- 协商分片所需的MSS大小(存放于报文Options字段中,tcp通信过程中的许多属性,比如时间戳,都是在三次握手的时候通过option协商)
- 等等...
TCP传输序列号
- sequence number:表示的是我方(发送方)这边,这个 packet的数据部分的第一位应该在整个data stream中所在的位置。
- acknowledge number:表示的是期望的对方(接收方)的下一次sequence number是多少。注意,SYN/FIN的传输虽然没有data,但是会让下一次传输的packet seq增加一,但是,ACK的传输,不会让下一次的传输packet加一。
TCP传输状态变化
参考:《图解TCP/IP》
- TimeWait作用
- 确保连接正常关闭
- 预防前一次的Ack丢失
- 典型的tcp协议要求每一个数据段发送之后都要有一个ack回复,然后才能发送下一个数据段,虽然这样能保证数据的可靠传输,但是效率呢?由于tcp是全双工通信,在等待一个数据段的ack恢复之前网络将会闲置,因此效率将会受到极大影响,因此协议提出了滑动窗口子协议,专门负责数据的传输,滑动窗口子协议分为简单的停-等协议,后退N协议,以及选择重传协议三个子子协议,其实三个子子协议可以由一个例程表示,只是一个例程的三个不同情况,比如发送和接收窗口都为1时就是简单的停等协议。三个子子协议都很复杂,只有靠这种复杂的机制才换取了网络链路的高效利用。
HTTP/HTTP1.1
HTTP本质上只是多加了一层规矩,HTTP依然是TCP,只是这个规矩让用户更清晰,更简洁,更关注业务本身
HTTP1.1有哪些优化
- 长连接
- 部分传输
- HOST字段
- 缓存
HTTPS
相关知识可以参考学习:
SSL/TLS握手
网络架构提质
网络提速
HTTP2.0
基于多路复用实现网络提速 HTTP2 详解
-
HTTP2 多路复用 具体参考:http2 简介
- 在 http/1.x 情况中,每个 http 请求都会建立一个 TCP 连接,这就意味着每个请求都需要进行三次握手。这样子就会浪费比较多的时间和资源,这点在 http/1.x 的情况下是没有办法避免的。并且浏览器会限制同一个域名下并发请求的个数。所以,在 http/1.x 的情况下,一个常见的优化手段是把静态资源分布到不同域名下,以此来突破浏览器并发数的限制。
- 在 http2 的情况下,所有的请求都会共用一个 TCP 连接,这个可以说是 http2 杀手级的特性了。同时,所有的请求都共用一个 TCP 连接,那么客户端/服务端怎么知道某一帧(http2 是的基本单位是帧),每一帧上的Stream Identifier 就是用来标识该帧属于哪个请求的。
- 当客户端同时向服务端发起多个请求,那么这些请求会被分解成一个个的帧,每个帧都会在一个 TCP 链路中无序的传输,同一个请求的帧的 Stream Identifier 都是一样的。当帧到达服务端之后,就可以根据 Stream Identifier 来重新组合得到完整的请求。
-
HTTP2缺陷--队头阻塞没有彻底解决 参考:解读 HTTP1/HTTP2/HTTP3
- 在HTTP/2中,多个请求是跑在一个TCP管道中的。但当出现了丢包时,HTTP/2 的表现反倒不如 HTTP/1 了。因为TCP为了保证可靠传输,有个特别的“
丢包重传”机制,丢失的包必须要等待重新传输确认,HTTP/2出现丢包时,整个 TCP 都要开始等待重传,那么就会阻塞该TCP连接中的所有请求(如下图)。而对于 HTTP/1.1 来说,可以开启多个 TCP 连接,出现这种情况反到只会影响其中一个连接,剩余的 TCP 连接还可以正常传输数据。
- 在HTTP/2中,多个请求是跑在一个TCP管道中的。但当出现了丢包时,HTTP/2 的表现反倒不如 HTTP/1 了。因为TCP为了保证可靠传输,有个特别的“
QUIC/HTTP3.0
HTTP3即HTTP over QUIC,QUIC协议是基于UDP协议的,而UDP是“无连接”的,根本就不需要“握手”和“挥手”,所以就比TCP来得快。此外QUIC也实现了可靠传输,保证数据一定能够抵达目的地。它还引入了类似HTTP/2的“流”和“多路复用”,单个“流"是有序的,可能会因为丢包而阻塞,但其他“流”不会受到影响。QUIC具有如下优势:
- 实现了类似TCP的流量控制、传输可靠性的功能
- 实现了快速握手功能
- 集成了TLS加密功能
- 多路复用,彻底解决TCP中队头阻塞的问题
静态资源/图片资源路径优化CDN
动态API(播放/评论接口)路径优化(DSA)
网络稳定
容灾
- 故障发生
- 故障感知
- 自动切换
- 服务恢复
故障排查
- 故障明确
- 出现什么故障
- 什么业务?什么接口故障?
- 故障体现在哪里?
- 访问其他目标是否正常?
- 是否是修改导致的异常?
- 故障止损
- 先止损再排查:用户体验第一;对企业收入的影响是按照分钟甚至秒来计算
- 如何止损:组件/系统容灾;降级
- 分段排查
- 客户端排查
- 客户端访问其他服务有没有问题
- 其他客户端访问目标服务有没有问题
- 服务端排查
- 服务端监控/指标是否正常
- 手动访问是否正常
- 分组件排查
- 中间链路排查
- 服务端和客户端确保没有问题
- 中间网络设备有没有问题(交换机/路由器/网关LB)
- 旁路的DNS有没有问题
- 客户端排查
网络故障排查常用命令
- dig查询DNS问题
- ping/telnet/nmap查询三层/四层连通性
- Tracerroute排查中间链路
- iptables
- tcpdump