干翻 nio ,王炸 io_uring 来了 ,史上最详细说明及最全图解!!

Image
大趋势:全链路异步化,性能提升10倍+ 随着业务的发展,微服务应用的流量越来越大,使用到的资源也越来越多。 在微服务架构下,大量的应用都是 SpringCloud 分布式架构,这种架构总体上是 全链路同步模式 。 全链路同步模式 不仅造成了资源的极大浪费,并且在流量发生激增波动的时候,受制于系统资源而无法快速的扩容。 全球后疫情时代,降本增效是大背景。如何降本增效?一条好的路径: 全链路同步模式  ,升级为  全链路异步模式 。 全链路异步模式 改造 具体的内容,请参考尼恩的深度文章: 全链路异步,让你的 SpringCloud 性能优化10倍+ 先回顾一下全链路同步模式架构图 全链路同步模式  ,如何升级为  全链路异步模式 , 就是一个一个 环节的异步化。 40岁老架构师尼恩,持续深化自己的3高架构知识宇宙,当然首先要去完成一次牛逼的 全链路异步模式 微服务实操,下面是尼恩的实操过程、效果、压测数据(性能足足提升10倍多)。 全链路异步模式 改造 具体的内容,请参考尼恩的深度文章: 全链路异步,让你的 SpringCloud 性能优化10倍+ 并且,上面的文章,作为尼恩 全链路异步的架构知识,收录在《 尼恩Java面试宝典 》V52版的架构专题中 注:本文以 PDF 持续更新,最新尼恩 架构笔记、面试题 的PDF文件,请从这里获取: 语雀 或者 码云 全链路异步化的最终目标 全链路异步化的最终目标,如下图所示: 应用层:编程模型的异步化 框架层:IO线程的异步化 OS层:IO模型的异步化 一:应用层:编程模型的异步化 这个请大家去看 尼恩的 《 响应式 圣经 PDF 》电子书 随着 云原生时代的到来, 底层的 组件编程 越来越 响应式、流化, 从命令式 编程转换到 响应式 编程,在非常多的场景 ,是大势所趋。 而响应式编程, 学习曲线很大, 大家需要多看,多实操。 二:框架层:IO线程的异步化 这个大家 都选择 具有异步 回调功能的 异步线程模型,如 Reactor 线程模型 这个是面试的绝对重点 IO的王者组件,Netty框架,整体就是一个 Reactor 线程模型 实现 也是非常核心的知识,这里不做展开,请大家去看尼恩的畅销书《Java 高并发核心编程卷 1 加强版》。 三:OS层:IO模型的异步化 目前的一个最大难题,是IO模型的异步化。 注意,Netty

TCP 协议中 MSS 的理解,如何确定MSS

在介绍 MSS 之前我们必须要理解下面的几个重要的概念。

MTU: Maxitum Transmission Unit 最大传输单元

MSS: Maxitum Segment Size 最大分段大小

PPPoE: PPP Over Ethernet(在以太网上承载 PPP 协议),就是因为这个协议的出现我们才有必要修改我们的 MSS 或者是 MTU 值。

MTU 最大传输单元,这个最大传输单元实际上和链路层协议有着密切的关系,EthernetII 帧的结构 DMAC+SMAC+Type+Data+CRC

由于以太网传输电气方面的限制,每个以太网帧都有最小的大小 64bytes 最大不能超过 1518bytes,对于小于或者大于这个限制的以太网帧我们都可以视之为错误的数据帧,一般的以太网转发设备会丢弃这些数据帧。

由 于以太网 EthernetII 最大的数据帧是 1518Bytes 这样,刨去以太网帧的帧头(DMAC 目的 MAC 地址 48bit=6Bytes+SMAC 源 MAC 地址 48bit=6Bytes+Type 域 2bytes)14Bytes 和帧尾 CRC 校验部分 4Bytes(这个部分有时候也把它叫做 FCS),那么剩下承载上层协议的地方也就是 Data 域最大就只能有 1500Bytes,这个值我们就把它称之为 MTU。这个就是网络层协议非常关心的地方,因为网络层协议比如 IP 协议会根据这个值来决定是否把上层传下来的数据进行分片。

当两台远程 PC 互联的时候,它们的数据需要穿过很多的路由器和各种各样的网络媒介才能到达对端,网络中不同媒介的 MTU 各不相同。我们可以看下面的简单的组网图。

PC1(192.168.0.1)―――Router――――Internet―――-www server(238.136.1.1)

建立 tcp 连接的两端在三次握手时会协商 tcp mss 大小,具体如下:

pc1 发出 syn 报文,其中 option 选项填充的 mss 字段一般为 1460,同样 www server 收到 syn 报文后,会发送 syn+ack 报文应答,option 选项填充的 mss 字段也为 1460;协商双方会比较 syn 和 syn+ack 报 文中 mss 字段大小,选择较小的 mss 作为发送 tcp 分片的大小。通过比较,协商双方的 tcp mss 都是 1460。

对于网络层的上层协议而言(我们以 TCP/IP 协议族为例)网络层 IP 协议会检查每个从上层协议下来的数据包的大小,并根据本机 MTU 的大小决定是否作 “分片” 处理。分片最大的坏处就是降低了传输性能,本来一次可以搞定的事情,分成多次搞定,所以在网络层更高一层(就是传输层)的实现中往往会对此加以注 意!所以会在 IP 数据包包头里面加上一个标签:DF(Donot Fragment)。这样当这个 IP 数据包通过多个路由其进行网络传输的时候,如果遇到 MTU 小于 IP 数据包的情况,转发设备就会根据要求丢弃这个数据 包。然后返回一个错误信息给发送者。这样往往会造成某些通讯上的问题,不过幸运的是大部分网络链路都是 MTU1500 或者大于 1500。

对于 UDP 协议而言,这个协议本身是无连接的协议,对数据包的到达顺序以及是否正确到达不甚关心,所以一般 UDP 应用对分片没有特殊要求。

对于 TCP 协议而言就不一样了,这个协议是面向连接的协议,对于 TCP 协议而言它非常在意数据包的到达顺序以及是否传输中有错误发生。所以有些 TCP 应用 对分片有要求 --- 不能分片(DF)。PPPoE 所谓 PPPoE 就是在以太网上面跑 PPP 协议,就是在我们传输的链路层协议上添加一层 PPPOE 的报头。 这样相当于整个数据包的变大了。

为什么会产生这种奇怪的需求呢?这是因为随着宽带接入(这种宽带接入一般为 Cable Modem 或者 xDSL 或者以太网的接入)由于以太网缺乏认证计费机制而传统运营商是通过 PPP 协议来对拨号等接入服务进行认证计费的,PPPoE 带来了 好处,也带来了一些坏处,比如:二次封装耗费资源,降低了传输效能等等,最大的坏处就是 PPPoE 导致 MTU 变小了,以太网的 MTU 是 1500,再减去 PPP 的包头包尾的开销(8Bytes),就变成 1492。

如果两台主机之间的某段网络使用了 PPPoE 那么就会导致某些不能分片的应用无法通讯。

这个时候就需要我们调整一下主机的 MTU,通过降低主机的 MTU,这样我们就能够顺利地进行通讯了。当我们的 PC 链接服务器的时,只能 PING 通,却不能通过网页访问时,这时我们就需要考虑 MSS 值的大小是否正确了,一般情况下都是由 MSS 值不对造成的。

当然对于 TCP 应用而言还有另外的解决方案。就是在 TCP 中有一个 OPTIONS 这里有一个 MSS 的选项。MSS 就是 TCP 数据包每次能够传输的最大数据分段。为了达到最佳的传输效能 TCP 协议在建立连接的时候通常要协商双方的 MSS 值,这个值 TCP 协议在实现的时 候往往用 MTU 值代替(需要减去 IP 数据包包头的大小 20Bytes 和 TCP 数据段的包头 20Bytes)所以往往 MSS 为 1460。通讯双方会根据双方 提供的 MSS 值得最小值确定为这次连接的最大 MSS 值。这是在 IPV4 的协议中,而在 IPV6 协议中一般情况下 MSS 的值为 1440,这是因为,IPv6 中的 IP 头的大小是 40bytes,比 IPV4 的大 20 个 bytes.

我们试想一下,如果我们在中间路由器上把每次 TCP 连接的最大 MSS 进行调整这样使得通过 PPPoE 链路的最大 MSS 值加上数据包头包尾不会超过 PPPoE 的 MTU 大小 1492 这样就不会造成无法通讯的问题. 所以上面的问题可以通过 ip tcp adjust-mss 1452 来解决。很多的路由器配置上会有这个配置选项。如果对于 IPV6 的话可以调整为 1432. 当我们不改变中间路由器的情况下,也可以通过改变我们主 机的 MTC 来解决。当主机的 MTU 值从 1500 改变为 1492 时,就相当于去掉了 EthernetII 和 PPPOE 头部的长度。

Comments

Popular posts from this blog

V2rayN 电脑客户端如何在 win7/win10/win11上 实现全局代理

便宜好用又稳定的VPN-桔子云,性价比极高!

IOS小火箭/Shadowsocks无需AppleID即可在线安装!