樰篱
2018-07-04
4961浏览量
本文作者:白金
上篇回顾:《CDN 之我见》系列二:原理篇(缓存、安全)https://yq.aliyun.com/articles/599253
《CDN 之我见》是一个系列文章,共由三个篇章组成,分为“原理篇”、“详解篇”和“陨坑篇”。本篇章属于“详解篇”的第一部分:网络优化。详解篇适合那些接触过 CDN,对 CDN 多少有些了解,但很多知识点知其然而不知其所以然,想深入了解学习的同学。
众所周知,当前是互联网时代,无论大大小小的公司,无论是互联网企业还是传统企业,统统离不开一个“网”字,而相比之下,硬件服务器、操作系统、应用组件等,在没有特殊必要需求的话(如果硬件不坏、软件或系统无急需修复的 BUG、无急需实现的客户需求),这些都是不用去主动改变。
相比之下网络则不同,最频繁变化的,最不想变化而又最无奈被动跟随变化的,就是网络质量,而 CDN 的缩写也是 Content Delivery Network,因此在详解篇我会把重点放在网络上。其它的部分相对都好把控,但网络问题存在一定的随机性和不可预测性。如果我们可以驾驭网络,相信在这个互联互通的互联网时代,我们将变得如虎添翼、叱咤风云!
为此,这里提出我对 CDN 的另一个解读:CDN - Can Do sth. on Network(我们可以在网络层面搞些事情)
提到优化,其实从 OSI 七层模型来讲(准确说是 TCP/IP 模型,二者是不同的,具体可以 google 一下),从物理层到应用层其实都是可以优化的,优化手段各异。
L1 物理层:硬件优化(升级硬件设备,承载更多业务)
L2 链路层:资源好坏(寻找更快的网络节点、确保 Lastmile 尽量短)
L3 路由层:路径优化(寻找 A 到 B 的最短路径)
L4 传输层:协议栈优化(TCP Optimization)
L7 应用层:能做的事情太多了(主要面向 HTTP 面向业务)
针对 CDN 而言,常用的是 L4 和 L7 的优化,例如上图所述。
总之,优化策略非常多,下面将抽取其中最具通用性的网络部分进行详细阐述。
如前文所述,所谓路径优化就是找到两点间的最优路径。
对于网络而言,A 到 B 最快 ≠ A 距离 B 最近,从广东联通访问福建联通,可能不如广东联通经北京联通再到福建联通更快,因此要对节点做实时探测,计算最优路径。
计算最优路径时,还要考虑带宽饱和度、成本、客户敏感度问题综合计算,因此不是看上去那么简单的。
带宽饱和度:作为中转节点(例如上例所说的北京),如果带宽本身已经没有多少剩余,那么穿越北京的路径优化可能会作为压死大象的最后一根稻草,使原本还 OK 的北京节点变得不堪重负。
成本:还以北京为例,北京资源的带宽成本肯定远高于其它省市,例如比河北联通、天津联通可能要贵很多,但可能只比河北天津慢几个毫秒(运动员起跑时最快的反应时间是 150 毫秒),那么为了这几毫秒要多支付很多带宽费用显然是不值当的,那么利用北京进行中转显然就是不值得的(当然,有的时候就是为了和对手 PK,那也没办法)。
客户敏感度:有了中转路径,提速效果当然是好的,但如前文所述也是有代价的,那么是所有业务流量都走最优路径呢?还是只让个别业务走最优路径呢?这个就要看客户敏感度了。例如重点大客户,例如对质量要求较高的高价优质客户,这些客户可能就是首选。
如前文所述,所谓传输层优化主要是指 TCP 优化,这是所有互联网行业的通用技术,是重中之重的领域,TCP 优化如果做的好,可弥补节点质量低下而造成的响应时间过大的损失。
赛马比赛时,有好马当然跑的快。如果马一般(不是太差),骑手的骑术精湛,或许同样也可以得第一,就是这个道理!
另外一点 TCP 优化重要的原因在于,TCP 是互联网尤其是 CDN 的基础协议,基本上所有业务都是 over TCP 来进行传输的,如果将 TCP 优化做好,受益面非常广,可以说全局收益(不仅是提升客户体验感,也能提升内部支撑系统的使用体验感,例如日志传输、配置下发等)。
谈到 TCP 优化,需要先将 TCP 协议基础知识。需要首先明确一些名词属于的概念。
了解了 TCP 的一些名词属于,其实大致也就了解了 TCP 的运作机制,但是有几点要注意。
1.不同的操作系统、内核版本,initcwnd(初始 CWND)不同
以 Linux 为例,kernel-2.6.18 的 initcwnd 是 2,而 kernel-2.6.32 变成了 10,通过 iproute 软件包中的 ip 命令可以修改 Linux 的 CWND 和 RWND。
具体可以参考一篇 Google 写的 Paper,是他们提出了原始 initcwnd = 2 太小了,需要扩大的理念。
原文请参考:
https://developers.google.com/speed/protocols/tcp_initcwnd_techreport.pdf
2.单位时间内(一个 RTT)发送量不是 CWND,而是 min(CWND, RWND)
除了数据发送端有个 CWND 以外,数据接收端还有个 RWND(Receive Window,接收窗口),决定还能接收多少数据,并通过接收确认报文显性告知数据发送端,发送端要参考 CWND 和 RWND 信息决定最终发送的数据量(packet 个数)。管道中究竟能放多少数据,取决于 CWND 和 RWND。
另一个问题:TCP 怎么了?TCP 有什么问题吗?
如果能问出这个问题,证明同学们的关注点是正确的。
TCP 是在上个世纪六七十年代设计的,当时面向的是短距离传输、窄带(可能还是半双工通信)的链路环境。链路本身不太可能丢包,丢包基本都是因为链路拥塞造成的。根据早起的 TCP 拥塞控制算法,丢包 -> 降速,再丢 -> 再降,算法本身的目的是希望通过降速来规避拥塞,进而规避丢包情况。
这个算法本身的理念是正确的,但是随着时代的发展,有了 4G,有了 WiFi,有了长距传输,有了策略性丢包逻辑,导致 TCP 传输过程中,丢包不一定就是拥塞造成的,如果按照传统的“丢包就降速”策略来考虑问题,可能不但不能缓解问题,甚至可能会导致问题更加恶化。
举个例子来说,在一个平均随机丢包 50% 的链路上(平均发出去的包,每 2 个就必然丢 1 个),在这种环境下,发现丢包了,降速发送有用吗?答案毋庸置疑,降速只会让对端收到的有效数据更少。这种环境如何优化呢?很简单,每个包发 2 遍不就可以了?这样对端就会 100% 收到数据了,但代价就是发送端的出口流量是之前的 2 倍。
当然,真正在做 TCP 优化时不是这么简单的,要考虑很多细节,例如如何区分丢包原因,例如该如何控制 CWND,例如如何更早的发现接收端没收到数据,例如当对端无响应时如何快速感知等等等等……
除此之外还有一个优化点,就是 TCP Pacing。
前文我们已经讲过,TCP 是通过 CWND/RTT 来控制传输速率的,在一个 RTT 中,最多只能发 min(CWND, RWND) 这么多数据。但是 TCP 协议栈在发送数据时,是在 RTT 周期之初一股脑将数据发送出去的,这样宏观看没有任何问题,但如果微观看,数据发送波形就像上图那样,一个又一个的凸起。虽然在 RTT 单位时间内发送量恒定,但某微观时间线上的发送速率确实超级猛烈的,这样有可能造成瞬间链路拥塞(尤其是窄带线路)。
原文请参考:https://homes.cs.washington.edu/~tom/pubs/pacing.pdf
通过 TCP 三次握手建连可以测得 RTT,在已知 CWND 的情况下,通过控制发包的时间间隔可以实现 Pacing 效果,使数据包在围观看是均衡发送充满整个 RTT 空间的效果,这样可以避免瞬时拥塞,对窄带链路后需要匀速恒定传输的业务非常有效。
除了 Pacing 以外,还有很多不同的优化算法或策略:
之前讲的 TCP 优化都是需要去修改代码的,这里有一个不用修改代码的方法,仅修改参数就可以。
内核协议栈参数 net.ipv4.tcp_slow_start_after_idle 默认是开启的,这个参数的用途,是为了规避 CWND 无休止增长,因此在连接不断开,但一段时间不传输数据的话,就将 CWND 收敛到 initcwnd,kernel-2.6.32 是 10,kernel-2.6.18 是 2。因此在 HTTP Connection: keep-alive 的环境下,若连续两个 GET 请求之间存在一定时间间隔,则此时服务器端会降低 CWND 到初始值,当 Client 再次发起 GET 后,服务器会重新进入慢启动流程。
这种友善的保护机制,对于 CDN 来说是帮倒忙,因此我们可以通过命令将此功能关闭,以提高 HTTP Connection: keep-alive 环境下的用户体验感。
# sysctl net.ipv4.tcp_slow_start_after_idle=0
下一期将为大家分享《CDN 之我见》的 “详解篇” 中的 “架构优化” 与 “Cache 选型” 话题。
敬请期待,欢迎拍砖!
【TechDay】阿里云CDN Tengine开源技术沙龙-上海站,将在8月29日下午阿里虹桥中心展开,多位专家现场探讨CDN QUIC、TLSv1.3、直播、Tengine实践等话题,参与活动即可赢取阿里云定制礼品,点击了解活动详情与报名:https://yq.aliyun.com/event/359
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。
分享边缘计算行业知识与阿里云边缘计算的行业应用,关注官网账号阿里云Edge Plus