本周的论文来自2021年初的一次会议（SIGCOMM 2021）。我也在尝试一种新的论文评论格式，非常感谢您的想法。这些论文评论可以每周发送到你的收件箱，也可以订阅Atom订阅源。一如既往，请随时在Twitter上发表反馈或建议！
《解除绑定的纽带：将IP与web服务和套接字分离以实现CDN级别的强大寻址灵活性》中的研究描述了CloudFlare将网络概念（主机名和套接字）与IP地址分离的工作。
通过将主机名和套接字与地址分离，CloudFlare的基础设施可以快速更改为给定主机提供流量的机器，以及每个主机上运行的服务——作者称这种方法为寻址敏捷性。
本文指出，减少IP地址的使用是将IP地址与主机名分离的最初动机。作者认为，CDN不一定需要大量IP地址才能运行——这与“大型CDN已经获得了大量IP地址：在撰写本文时，Cloudflare拥有170万个IPv4地址，Akamai拥有1200万个，Amazon AWS拥有超过5100万个！”的事实形成了对比
传统上，许多CDN使用大量IP，因为它们的体系结构（如下图所示）将入口点和出口点放在公共互联网上——入口点接收来自客户端的请求，而出口点向缓存上的源服务器发出请求，但却错过了“什么是源服务器”上的这些文档有帮助。为了让这些机器可以访问，它们需要公共IP地址。
其他因素可能会增加CDN的IP地址使用率。CDN可以将特定IP绑定到主机名，从而在CDN服务的主机名数量和CDN需要的地址数量之间建立关系。此外，CDN服务器通常在网络套接字上有一个上限，网络连接有用于连接的读/写缓冲区，以及一个名为sk_buff的内核数据结构。更多信息请点击这里，因此，客户机使用量的增加也会转化为更多的机器（以及相关的IP地址）。
主机名到地址绑定控制主机名（如www.micahlerner.com）如何映射到可以服务请求的IP地址/计算机
地址到套接字绑定控制机器上运行的服务。作为网络套接字的参考，我非常喜欢Beej的网络编程服务客户端请求指南。
首先，本文描述了CloudFlare如何通过更改称为策略的配置来快速、动态地更新主机名到地址绑定——DNS服务器接收策略，并使用它们来决定为给定主机名返回哪些IP地址。
一个示例策略允许主机名映射到从一组候选主机（称为池）中随机选择的IP地址。使用策略而不是从主机名到IP地址的固定映射与其他部署形成对比，在其他部署中，更改主机名到IP地址的映射在操作上既复杂又容易出错。
通常一个服务在一组固定的端口上接收流量——这种方法有几个缺点，包括每个套接字都有开销（意味着在每台机器上可以运行固定数量的服务），并且不可能在同一台机器上运行两个端口重叠的服务而不造成复杂性。本文指出了一种方法，使用INADDR_ANY（此处为相关文档），允许一个套接字接收发送到机器上所有接口的数据包。这种方法并非没有缺点，比如可能会带来安全问题——如果内部流量与外部流量进入同一个套接字，内部服务可能会意外地响应外部请求。（因为它们不能重复使用同一个端口）。
为了应对这些挑战，CloudFlare的系统引入了可编程套接字查找。CloudFlare博客提供了更多背景信息，使用BPF eBPF/BPF在过去的论文评论中出现过几次，我非常喜欢Julia Evans关于这个主题的这篇文章。（作为实现的一部分，作者构建了sk_查找，这里还有一个greta教程。）。这种方法基于规则在内核内部路由流量。一个示例规则可以将客户端流量路由到并行运行的同一服务的不同实例，每个实例都有一个单独的套接字。
本文讨论了解决敏捷性问题所带来的许多性能和安全优势——重要的是，这些优势在其他重要系统指标没有明显变化的情况下可用！
首先，分离主机名到地址和地址到套接字绑定允许CloudFlare CDN。本文指出，这种方法也可以转移到外部部署，但需要注意几点。使用更少的IP进行操作。地址不再需要保留供特定主机名使用，机器现在可以有更多的套接字。更少的IP地址会影响成本并降低进入壁垒——论文指出，主要云提供商拥有的IP空间价值不超过5亿美元（如果不是更多的话）。
CloudFlare继续使用的IP地址也变得更易于管理。将IP地址动态分配给主机名将使机器（以及相关地址）脱机的操作任务变成了从提供给客户端的池中删除地址的问题。
此外，论文中描述的随机化方法（池中的IP地址响应DNS查询而返回）可以实现更好的负载平衡。
虽然本文讨论了寻址灵活性提供的可扩展性优势，但也讨论了限制地址使用之外的其他影响——例如，该方法可以帮助抵御拒绝服务攻击。
如果某个特定地址受到攻击，则该地址的流量可以是blackholed CloudFlare在Blackhole路由上的参考。如果某个主机名受到攻击，则该主机名的通信量将均匀分布在地址池中的计算机上。