IT技术博客大学习 共学习 共进步
全部 移动开发 后端 数据库 AI 算法 安全 DevOps 前端 设计 开发者

标签:Sliding Window

共 2 篇相关文章

IT 累计浏览 2,104

TCP 滑动窗口 与窗口缩放因子(Window Scaling)

这篇讲的是TCP滑动窗口协议中一个常被忽略但影响重大的参数:窗口缩放因子(Window Scaling)。文章指出,TCP窗口字段本身只有16位,最大值为65535字节。在“高带宽-长延迟”的网络中,这个上限会成为性能瓶颈——比如在10Mbps、单向延迟80ms的链路上,理想窗口需要约100KB,但65KB的窗口迫使发送方必须等待确认,白白浪费了带宽。 为了解决这个问题,窗口缩放选项被引入。它通过在TCP握手中协商一个“缩放因子”,将接收到的窗口值左移该因子位,从而将最大窗口理论上扩展至约1GB(缩放因子最大为14)。文章通过计算示例说明,原先65KB的窗口经过缩放后,能够匹配高带宽网络的实际吞吐需求。 作者在实战中也验证了其效果:对一个上传服务进行调优,增大TCP缓冲区并启用窗口缩放后,上传一个8MB视频文件的时间从1分30秒显著缩短至20秒,体现了在特定网络环境下对此参数进行调优的实际价值。

IT 累计浏览 2,820

关于两种限流模式

这篇讲的是高并发系统中两种主流的限流模式:滑窗模式与响应模式。滑窗模式是“事后统计”,通过检查过去多个单位时间窗口内的请求总量是否超标来决定是否放行。它的实现像一个环形计数器数组,逻辑直观,但阈值设定依赖经验或压测,且可能因单位时间请求分布不均导致“先松后紧”。文章指出,它更适合作为对单一资源(如数据库、特定API)的刚性保护承诺。 而响应模式则是一种“实时反馈”策略,它只关心当前正在处理的请求数。文章巧妙地指出了限流的根本目的——是保护系统资源不被拖垮。由于系统容量会受GC、依赖抖动等动态因素影响,响应模式通过公式(QPS/1000*RT)动态计算最大并发数,让限流阈值能随系统实际承载能力自动调整,展现了更强的适应性。 文章最后对比了二者的实现思路:滑窗模式基于数组和环形队列记录历史计数;响应模式则仅需一个原子计数器跟踪活跃请求数。这为在确定性资源保护和自适应系统保护两种场景下的选型提供了清晰的技术参考。