1. 为什么“1G带宽跑不满”是个值得动手实测的问题很多人第一次看到监控面板上那条吞吐曲线时都会犯嘀咕明明买的是千兆链路交换机端口协商显示1000Mbps可实际文件传输速度死活卡在六七百兆甚至更低。于是开始怀疑运营商、怀疑网线、怀疑设备唯独没怀疑过“吞吐量”这个指标本身到底是怎么算出来的。我当年也是这样抱着“带宽就是水管粗细”的朴素认知结果被现实按在地上摩擦了好几轮。这篇内容想干的事情很直接抛开那些背了又忘的公式直接打开抓包工具用真实数据把TCP吞吐量算一遍看看千兆链路里那消失的三四百兆到底去哪了。核心关键词就三个——抓包实测、TCP吞吐量、带宽跑不满。它解决的不是“怎么配网络”的问题而是“怎么用数据说话”的问题当你面对一条跑不满的链路时能自己抓包、自己算、自己定位瓶颈而不是靠猜。适合谁来读网络运维、后端开发、测试工程师以及任何被“带宽够但速度不够”困扰过的技术人。不需要你精通TCP协议栈但得愿意动手敲几条命令、看一眼抓包结果。下面所有实操都基于通用工具和虚拟环境你可以直接照着复现。2. 先把“吞吐量”这件事想明白设计思路与方案选型2.1 为什么不用公式而用抓包教科书上的吞吐量公式大概是这样的吞吐量 ≈ 窗口大小 / RTT。看着简洁但它是个理想模型默认链路无丢包、无拥塞、接收窗口恒定。真实网络里这些假设一个都不成立。你按公式算出来理论值能跑满千兆实际却差一大截问题就出在“公式没告诉你的事”上。抓包的价值在于它记录的是链路上真实发生的每一个字节。你可以从抓包文件里直接读出实际传输了多少数据、花了多长时间、有没有重传、窗口有没有缩小、有没有零窗口通告。这些信息拼起来才是吞吐量跑不满的真实原因。公式给你一个上限抓包告诉你为什么没到上限。我选择用抓包而不是只看监控面板还有一个很实际的原因监控面板的采样粒度通常是秒级甚至分钟级短时间的突发、重传、窗口抖动全被平均掉了。而抓包是微秒级的任何一次异常都能被揪出来。这就像看病体检报告是平均值抓包是切片病理。2.2 实验环境怎么搭才可控要实测环境必须可控。我用的是一套完全虚拟化的方案避免真实硬件带来的干扰变量两台虚拟机分别作为发送端和接收端操作系统用常见的Linux发行版。中间用虚拟网络连接链路速率人为限制在1Gbps模拟千兆环境。抓包点在接收端网卡上用抓包工具的命令行版本避免图形界面带来的额外开销。传输工具用文件传输和自带的流量生成工具两种交叉验证。为什么要在接收端抓包而不是发送端因为接收端看到的是“实际到达”的数据重传、乱序、丢包的影响都体现在这里更接近用户感知到的吞吐量。发送端抓包看到的是“发出去”的容易高估。提示虚拟环境里限制链路速率建议用流量控制工具做整形而不是靠虚拟机软件自带的限速后者粒度粗、抖动大会让实测数据失真。2.3 关键指标先定义清楚别算错动手之前得统一口径否则算出来的数字没法对比。我关注四个量指标含义抓包里的来源传输字节数应用层有效载荷总量TCP段长度累加剔除头部传输耗时从第一个数据段到最后一个ACK的时间首末包时间戳之差重传率重传段数占总段数比例抓包工具的重传标记平均窗口接收窗口的平均值TCP头部窗口字段吞吐量 传输字节数 × 8 / 传输耗时单位换算成Mbps。注意这里用的是应用层有效载荷不是链路层帧长。很多人算出来偏大就是把以太网头、IP头、TCP头都算进去了那些是开销不是有效数据。这个细节后面还会展开。3. 抓包实操从零跑出一组可信数据3.1 抓包前的准备工作第一步是把抓包工具装好。命令行版本在主流Linux发行版里基本都能直接装装完确认版本老版本对新协议字段的解析可能不全。接着确认网卡名称用系统自带的网络信息命令看一眼别抓错网卡——虚拟环境里经常有好几块网卡抓错了等于白忙。第二步是设置抓包过滤器。这一步极其关键不加过滤会把整条链路的杂包全抓进来文件巨大还干扰分析。我的过滤条件是只抓目标端口上的TCP流量tcpdump -i eth0 -s 0 -w tcp_test.pcap tcp port 5201参数逐个说清楚-i eth0指定网卡-s 0表示抓完整包不截断默认只抓前几十字节头部信息会丢-w写入文件最后的过滤表达式限定端口。端口5201是流量生成工具的默认端口换成你自己的传输端口即可。注意-s 0一定要加。我踩过的坑就是忘了加结果抓下来的包每个只有几十字节TCP选项字段全被截断窗口缩放因子读不出来后面算窗口全是错的。3.2 发起传输并同步记录时间抓包启动后立刻在发送端发起传输。我建议同时记录一个“应用层开始时间”和“应用层结束时间”作为交叉验证。抓包算出来的是网络层视角的耗时应用层视角会多出一些系统调用和磁盘IO的时间两者对比能判断瓶颈是不是在主机侧。传输持续30秒左右比较合适。太短了抓不到稳态太长了文件大、分析慢。30秒在千兆链路上能传好几个GB足够看出趋势。传输过程中不要动其他网络配置保持环境干净。传输结束后先停抓包再停传输工具顺序别反。反了的话抓包文件里会缺最后一段算出来的耗时偏短、吞吐量偏大。这个细节很小但直接影响结果可信度。3.3 用抓包工具读出原始数字抓包文件拿到手先用抓包工具的统计功能看个大概。命令行版本可以用读取模式配合统计参数图形界面版本直接看“统计”菜单里的“对话”视图。重点看三个数总字节数、总包数、起止时间。我实测的一组原始数据是这样的30秒传输抓到的TCP段总数约26万个累计有效载荷约2.4GB首包到末包的时间跨度29.6秒。粗算一下2.4GB × 8 / 29.6s ≈ 649Mbps。千兆链路只跑到649Mbps缺口超过三分之一。这就是标题里说的“跑不满”接下来就是找原因。这里要强调一个易错点抓包工具统计的“字节数”默认可能包含链路层头部。一定要在统计设置里选择“只统计TCP有效载荷”或者手动用过滤条件剔除。我见过有人直接拿工具默认数字算结果算出来比链路速率还高闹了笑话。3.4 把数字代进公式但要知道公式的边界用抓包数据算吞吐量公式本身很简单吞吐量(Mbps) 有效载荷字节数 × 8 / 传输耗时(秒) / 1,000,000代入上面的数据2.4 × 1024 × 1024 × 1024 × 8 / 29.6 / 1,000,000 ≈ 649Mbps。和粗算一致。但这个公式只回答“实际跑了多少”不回答“为什么没跑满”。要回答后者得往下钻看重传、看窗口、看往返时延。公式是入口不是终点。很多人算完吞吐量就停了觉得“哦就是跑不满”这等于只做了体检没看报告。4. 逐层拆解那消失的350Mbps到底去哪了4.1 第一层协议开销先扣掉固定成本千兆指的是链路层速率也就是每秒能传多少以太网帧。但用户数据要经过层层封装以太网头14字节、IP头20字节、TCP头20字节不含选项加起来54字节。一个满载的以太网帧有效载荷是1500字节所以有效数据占比是1500 / (1500 54) ≈ 96.5%。这一层就吃掉了3.5%左右千兆变成约965Mbps。这是固定成本躲不掉。如果TCP头部带了时间戳等选项头部还会更长占比进一步下降。抓包里可以直接看到每个段的头部长度统计一下平均值就知道实际开销。提示别小看这3.5%。在万兆链路上协议开销的绝对值更大做容量规划时必须把它算进去否则永远对不上账。4.2 第二层往返时延与窗口吞吐量的真正天花板扣掉协议开销还有965Mbps实测只有649Mbps缺口还有300多。这时候要看窗口和往返时延。抓包里读接收窗口字段取稳态阶段的平均值我这次读到约64KB受窗口缩放因子影响实际值要乘上缩放倍数抓包工具一般会自动算好显示。往返时延从抓包里量找一个数据段和它对应的ACK时间戳相减。我这次环境里约2ms。代入带宽时延积64KB × 8 / 0.002s 256Mbps。等等这比实测的649Mbps还低说明窗口不是恒定64KB而是动态变化的峰值更高。抓包里看窗口随时间的变化曲线峰值能到200KB以上对应约800Mbps的理论上限。这就解释了为什么跑不到965Mbps窗口不够大填不满管道。带宽时延积决定了“管道里能装多少数据”窗口小于这个值发送端就得停下来等ACK链路出现空闲。这是吞吐量跑不满最常见的原因没有之一。4.3 第三层重传与拥塞控制看不见的刹车再看重传。抓包工具能标出重传段我这次统计重传率约0.8%。看着不高但TCP拥塞控制对丢包极其敏感一次丢包就可能把拥塞窗口砍半然后慢慢爬升。0.8%的重传率足以让平均窗口比峰值低一大截。抓包里还能看到拥塞窗口的变化部分工具支持解析呈现典型的锯齿状爬升、丢包、砍半、再爬升。每一次砍半链路就空闲一段时间。这些空闲时间累加起来就是那消失的几百兆。重传的原因这次是虚拟环境里的队列溢出不是链路误码。真实环境里还要考虑双工不匹配、网线质量、中间设备缓冲不足等。抓包能告诉你“有重传”但“为什么重传”还得结合环境判断。这就是为什么我一直强调环境要可控——变量太多根本没法归因。4.4 第四层主机侧瓶颈别忽略CPU和内存还有一类原因藏在主机里抓包不一定直接体现但能从时间戳的规律性看出来。如果数据段的发送间隔呈现明显的周期性抖动或者ACK的返回时间忽快忽慢可能是发送端CPU跑满了、内存拷贝成了瓶颈、或者中断处理跟不上。我这次特意在传输时看了发送端的CPU使用率单核跑到接近饱和。流量生成工具本身要消耗CPU做加密和拷贝千兆线速下这个开销不小。换成普通文件传输CPU压力小一些吞吐量反而略高。这说明主机侧的处理能力也是吞吐量的一部分链路再宽主机喂不满也白搭。5. 常见问题与排查速查表实操过程中遇到的问题不少挑几个典型的整理成表方便对照排查。现象可能原因排查手段处理方向抓包文件巨大分析卡死未加过滤器抓了全链路流量检查抓包命令的过滤表达式加端口或主机过滤只抓目标流量算出的吞吐量比链路速率还高统计时把协议头部算进了有效载荷核对统计口径只统计TCP有效载荷窗口字段读出来是0或异常小抓包时截断了包选项字段丢失检查是否加了-s 0重新抓完整包重传率很高但链路质量看着正常中间设备队列溢出或双工不匹配看重传的时间分布是否集中检查交换机端口配置和缓冲吞吐量忽高忽低无规律主机侧CPU或IO瓶颈传输时监控主机资源换更轻量的传输工具或加核首末包时间对不上应用层耗时抓包启停顺序反了核对操作顺序先启抓包后停传输除了表里的再补两个独家避坑点。第一虚拟环境的时钟可能不同步抓包时间戳和主机时间有偏差算耗时一定要用抓包文件内部的时间戳别混用。第二抓包工具本身在高流量下会丢包如果发现抓到的段数明显少于发送端统计说明抓包点扛不住了得换更靠前的抓包位置或者降低速率。6. 把结论落到可复现的操作上整套流程走下来其实就四步搭可控环境、抓完整包、算有效吞吐、逐层归因。每一步都有坑但坑都是可预见的。我个人在实际操作中的体会是抓包最大的价值不是算出那个数字而是让你对“带宽”这个词祛魅。千兆不是每秒传1000兆用户数据它是一个链路层速率上面叠着协议开销、窗口限制、拥塞控制、主机处理能力四道关卡每道关卡都要交过路费。如果你也想复现建议从最小的环境开始两台机器、一条限速链路、一个固定端口的传输。先把649Mbps这个数跑出来再逐项调整窗口大小、往返时延、重传率看吞吐量怎么变。调参的过程比看结论有意思得多也更能建立直觉。等你能凭抓包曲线一眼看出瓶颈在窗口还是在重传这套方法就算真正学到手了。后续还可以往深了做比如对比不同拥塞控制算法在同一链路下的表现或者把抓包数据导出来做时序分析那又是另一个话题了。
1. 为什么“1G带宽跑不满”是个值得动手实测的问题很多人第一次看到监控面板上那条吞吐曲线时都会犯嘀咕明明买的是千兆链路交换机端口协商显示1000Mbps可实际文件传输速度死活卡在六七百兆甚至更低。于是开始怀疑运营商、怀疑网线、怀疑设备唯独没怀疑过“吞吐量”这个指标本身到底是怎么算出来的。我当年也是这样抱着“带宽就是水管粗细”的朴素认知结果被现实按在地上摩擦了好几轮。这篇内容想干的事情很直接抛开那些背了又忘的公式直接打开抓包工具用真实数据把TCP吞吐量算一遍看看千兆链路里那消失的三四百兆到底去哪了。核心关键词就三个——抓包实测、TCP吞吐量、带宽跑不满。它解决的不是“怎么配网络”的问题而是“怎么用数据说话”的问题当你面对一条跑不满的链路时能自己抓包、自己算、自己定位瓶颈而不是靠猜。适合谁来读网络运维、后端开发、测试工程师以及任何被“带宽够但速度不够”困扰过的技术人。不需要你精通TCP协议栈但得愿意动手敲几条命令、看一眼抓包结果。下面所有实操都基于通用工具和虚拟环境你可以直接照着复现。2. 先把“吞吐量”这件事想明白设计思路与方案选型2.1 为什么不用公式而用抓包教科书上的吞吐量公式大概是这样的吞吐量 ≈ 窗口大小 / RTT。看着简洁但它是个理想模型默认链路无丢包、无拥塞、接收窗口恒定。真实网络里这些假设一个都不成立。你按公式算出来理论值能跑满千兆实际却差一大截问题就出在“公式没告诉你的事”上。抓包的价值在于它记录的是链路上真实发生的每一个字节。你可以从抓包文件里直接读出实际传输了多少数据、花了多长时间、有没有重传、窗口有没有缩小、有没有零窗口通告。这些信息拼起来才是吞吐量跑不满的真实原因。公式给你一个上限抓包告诉你为什么没到上限。我选择用抓包而不是只看监控面板还有一个很实际的原因监控面板的采样粒度通常是秒级甚至分钟级短时间的突发、重传、窗口抖动全被平均掉了。而抓包是微秒级的任何一次异常都能被揪出来。这就像看病体检报告是平均值抓包是切片病理。2.2 实验环境怎么搭才可控要实测环境必须可控。我用的是一套完全虚拟化的方案避免真实硬件带来的干扰变量两台虚拟机分别作为发送端和接收端操作系统用常见的Linux发行版。中间用虚拟网络连接链路速率人为限制在1Gbps模拟千兆环境。抓包点在接收端网卡上用抓包工具的命令行版本避免图形界面带来的额外开销。传输工具用文件传输和自带的流量生成工具两种交叉验证。为什么要在接收端抓包而不是发送端因为接收端看到的是“实际到达”的数据重传、乱序、丢包的影响都体现在这里更接近用户感知到的吞吐量。发送端抓包看到的是“发出去”的容易高估。提示虚拟环境里限制链路速率建议用流量控制工具做整形而不是靠虚拟机软件自带的限速后者粒度粗、抖动大会让实测数据失真。2.3 关键指标先定义清楚别算错动手之前得统一口径否则算出来的数字没法对比。我关注四个量指标含义抓包里的来源传输字节数应用层有效载荷总量TCP段长度累加剔除头部传输耗时从第一个数据段到最后一个ACK的时间首末包时间戳之差重传率重传段数占总段数比例抓包工具的重传标记平均窗口接收窗口的平均值TCP头部窗口字段吞吐量 传输字节数 × 8 / 传输耗时单位换算成Mbps。注意这里用的是应用层有效载荷不是链路层帧长。很多人算出来偏大就是把以太网头、IP头、TCP头都算进去了那些是开销不是有效数据。这个细节后面还会展开。3. 抓包实操从零跑出一组可信数据3.1 抓包前的准备工作第一步是把抓包工具装好。命令行版本在主流Linux发行版里基本都能直接装装完确认版本老版本对新协议字段的解析可能不全。接着确认网卡名称用系统自带的网络信息命令看一眼别抓错网卡——虚拟环境里经常有好几块网卡抓错了等于白忙。第二步是设置抓包过滤器。这一步极其关键不加过滤会把整条链路的杂包全抓进来文件巨大还干扰分析。我的过滤条件是只抓目标端口上的TCP流量tcpdump -i eth0 -s 0 -w tcp_test.pcap tcp port 5201参数逐个说清楚-i eth0指定网卡-s 0表示抓完整包不截断默认只抓前几十字节头部信息会丢-w写入文件最后的过滤表达式限定端口。端口5201是流量生成工具的默认端口换成你自己的传输端口即可。注意-s 0一定要加。我踩过的坑就是忘了加结果抓下来的包每个只有几十字节TCP选项字段全被截断窗口缩放因子读不出来后面算窗口全是错的。3.2 发起传输并同步记录时间抓包启动后立刻在发送端发起传输。我建议同时记录一个“应用层开始时间”和“应用层结束时间”作为交叉验证。抓包算出来的是网络层视角的耗时应用层视角会多出一些系统调用和磁盘IO的时间两者对比能判断瓶颈是不是在主机侧。传输持续30秒左右比较合适。太短了抓不到稳态太长了文件大、分析慢。30秒在千兆链路上能传好几个GB足够看出趋势。传输过程中不要动其他网络配置保持环境干净。传输结束后先停抓包再停传输工具顺序别反。反了的话抓包文件里会缺最后一段算出来的耗时偏短、吞吐量偏大。这个细节很小但直接影响结果可信度。3.3 用抓包工具读出原始数字抓包文件拿到手先用抓包工具的统计功能看个大概。命令行版本可以用读取模式配合统计参数图形界面版本直接看“统计”菜单里的“对话”视图。重点看三个数总字节数、总包数、起止时间。我实测的一组原始数据是这样的30秒传输抓到的TCP段总数约26万个累计有效载荷约2.4GB首包到末包的时间跨度29.6秒。粗算一下2.4GB × 8 / 29.6s ≈ 649Mbps。千兆链路只跑到649Mbps缺口超过三分之一。这就是标题里说的“跑不满”接下来就是找原因。这里要强调一个易错点抓包工具统计的“字节数”默认可能包含链路层头部。一定要在统计设置里选择“只统计TCP有效载荷”或者手动用过滤条件剔除。我见过有人直接拿工具默认数字算结果算出来比链路速率还高闹了笑话。3.4 把数字代进公式但要知道公式的边界用抓包数据算吞吐量公式本身很简单吞吐量(Mbps) 有效载荷字节数 × 8 / 传输耗时(秒) / 1,000,000代入上面的数据2.4 × 1024 × 1024 × 1024 × 8 / 29.6 / 1,000,000 ≈ 649Mbps。和粗算一致。但这个公式只回答“实际跑了多少”不回答“为什么没跑满”。要回答后者得往下钻看重传、看窗口、看往返时延。公式是入口不是终点。很多人算完吞吐量就停了觉得“哦就是跑不满”这等于只做了体检没看报告。4. 逐层拆解那消失的350Mbps到底去哪了4.1 第一层协议开销先扣掉固定成本千兆指的是链路层速率也就是每秒能传多少以太网帧。但用户数据要经过层层封装以太网头14字节、IP头20字节、TCP头20字节不含选项加起来54字节。一个满载的以太网帧有效载荷是1500字节所以有效数据占比是1500 / (1500 54) ≈ 96.5%。这一层就吃掉了3.5%左右千兆变成约965Mbps。这是固定成本躲不掉。如果TCP头部带了时间戳等选项头部还会更长占比进一步下降。抓包里可以直接看到每个段的头部长度统计一下平均值就知道实际开销。提示别小看这3.5%。在万兆链路上协议开销的绝对值更大做容量规划时必须把它算进去否则永远对不上账。4.2 第二层往返时延与窗口吞吐量的真正天花板扣掉协议开销还有965Mbps实测只有649Mbps缺口还有300多。这时候要看窗口和往返时延。抓包里读接收窗口字段取稳态阶段的平均值我这次读到约64KB受窗口缩放因子影响实际值要乘上缩放倍数抓包工具一般会自动算好显示。往返时延从抓包里量找一个数据段和它对应的ACK时间戳相减。我这次环境里约2ms。代入带宽时延积64KB × 8 / 0.002s 256Mbps。等等这比实测的649Mbps还低说明窗口不是恒定64KB而是动态变化的峰值更高。抓包里看窗口随时间的变化曲线峰值能到200KB以上对应约800Mbps的理论上限。这就解释了为什么跑不到965Mbps窗口不够大填不满管道。带宽时延积决定了“管道里能装多少数据”窗口小于这个值发送端就得停下来等ACK链路出现空闲。这是吞吐量跑不满最常见的原因没有之一。4.3 第三层重传与拥塞控制看不见的刹车再看重传。抓包工具能标出重传段我这次统计重传率约0.8%。看着不高但TCP拥塞控制对丢包极其敏感一次丢包就可能把拥塞窗口砍半然后慢慢爬升。0.8%的重传率足以让平均窗口比峰值低一大截。抓包里还能看到拥塞窗口的变化部分工具支持解析呈现典型的锯齿状爬升、丢包、砍半、再爬升。每一次砍半链路就空闲一段时间。这些空闲时间累加起来就是那消失的几百兆。重传的原因这次是虚拟环境里的队列溢出不是链路误码。真实环境里还要考虑双工不匹配、网线质量、中间设备缓冲不足等。抓包能告诉你“有重传”但“为什么重传”还得结合环境判断。这就是为什么我一直强调环境要可控——变量太多根本没法归因。4.4 第四层主机侧瓶颈别忽略CPU和内存还有一类原因藏在主机里抓包不一定直接体现但能从时间戳的规律性看出来。如果数据段的发送间隔呈现明显的周期性抖动或者ACK的返回时间忽快忽慢可能是发送端CPU跑满了、内存拷贝成了瓶颈、或者中断处理跟不上。我这次特意在传输时看了发送端的CPU使用率单核跑到接近饱和。流量生成工具本身要消耗CPU做加密和拷贝千兆线速下这个开销不小。换成普通文件传输CPU压力小一些吞吐量反而略高。这说明主机侧的处理能力也是吞吐量的一部分链路再宽主机喂不满也白搭。5. 常见问题与排查速查表实操过程中遇到的问题不少挑几个典型的整理成表方便对照排查。现象可能原因排查手段处理方向抓包文件巨大分析卡死未加过滤器抓了全链路流量检查抓包命令的过滤表达式加端口或主机过滤只抓目标流量算出的吞吐量比链路速率还高统计时把协议头部算进了有效载荷核对统计口径只统计TCP有效载荷窗口字段读出来是0或异常小抓包时截断了包选项字段丢失检查是否加了-s 0重新抓完整包重传率很高但链路质量看着正常中间设备队列溢出或双工不匹配看重传的时间分布是否集中检查交换机端口配置和缓冲吞吐量忽高忽低无规律主机侧CPU或IO瓶颈传输时监控主机资源换更轻量的传输工具或加核首末包时间对不上应用层耗时抓包启停顺序反了核对操作顺序先启抓包后停传输除了表里的再补两个独家避坑点。第一虚拟环境的时钟可能不同步抓包时间戳和主机时间有偏差算耗时一定要用抓包文件内部的时间戳别混用。第二抓包工具本身在高流量下会丢包如果发现抓到的段数明显少于发送端统计说明抓包点扛不住了得换更靠前的抓包位置或者降低速率。6. 把结论落到可复现的操作上整套流程走下来其实就四步搭可控环境、抓完整包、算有效吞吐、逐层归因。每一步都有坑但坑都是可预见的。我个人在实际操作中的体会是抓包最大的价值不是算出那个数字而是让你对“带宽”这个词祛魅。千兆不是每秒传1000兆用户数据它是一个链路层速率上面叠着协议开销、窗口限制、拥塞控制、主机处理能力四道关卡每道关卡都要交过路费。如果你也想复现建议从最小的环境开始两台机器、一条限速链路、一个固定端口的传输。先把649Mbps这个数跑出来再逐项调整窗口大小、往返时延、重传率看吞吐量怎么变。调参的过程比看结论有意思得多也更能建立直觉。等你能凭抓包曲线一眼看出瓶颈在窗口还是在重传这套方法就算真正学到手了。后续还可以往深了做比如对比不同拥塞控制算法在同一链路下的表现或者把抓包数据导出来做时序分析那又是另一个话题了。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
