我发现这个解释 CDN是如何工作的。 但有一件事我不是很明白。 假设我在我的位置设置了多个DNS服务器，并使用名称服务器域dns1.example.com ， dns2.example.com和dns3.example.com 。 这个DNS服务器能够根据访问者的位置（ping，地理数据库，浏览器语言或其他）提供服务器IP。 现在我在registry中更新这个域名www.example.org域名服务器设置。
现在， www.example.org上第一个过期的TTL请求会尝试parsing该域。 它问：
dns1.example.com 但是如果我理解正确，那么新的IP将被添加到所有这些名称服务器caching中，直到TTL再次到期。 那么如何根据他的位置向访问者发送其他IP呢？
在这个答案中， theand表示请求被“转发”，但我不认为这是一个CDN的工作原理，因为“转发”意味着延长传输方式，导致更长的加载时间。 还是一个CDN需要零TTL的域？
UPDATE1
通过这个问题，我发现Google的文档描述了他们如何优化CDN性能。 它没有解释CDN是如何工作的，但有如下有趣的解释：
之后，无论客户何时试图获取托pipe在CDN上的内容，客户端都被redirect到被确定为具有最less等待时间的节点。 然而，该redirect基于DNS名称服务器的IP地址所对应的前缀，该DNS名称服务器的IP地址代表客户端的内容的URL，通常与客户端位于同一位置。
这意味着Google首先检查所有IP前缀的延迟，并为所有可用的前缀定义DNSparsing表（？）。 如果访问者拥有IP 198.51.100.231 ，则使用Google服务器IP，前缀为198.51.100.0 。 但是，Google的DNS如何知道访问者正在使用哪个IP？ 大多数访问者通过他们的互联网提供商来parsingGoogle的域名，通过这些外部的DNS服务器来解决问题呢？
作为一个附加的例子：如果我使用不同的在线工具（托pipe在不同的国家/地区）为域名facebook.com启动一个DNSparsing，它将parsing为具有不同域名的不同IP：
之后，我认为这可能取决于访问者使用的DNS服务器的位置，但我尝试了自己的（德国电信，德国电信），谷歌（8.8.8.8）和法国（橙色）的主要一个，他们都返回了facebook.com IP 31.13.92.36 。
好吧，现在我可以粗略地回答我自己的问题。 Anurag Bhatia说CDN的工作方式有两种：
DNS
有DNS做魔术，即当networkingISP A的用户查找cdn.website.com时，他们应该得到一个单播的Cache A的IP地址，同样对于来自ISP Bnetworking的用户，Cache B的单播IP应该返回。
比方说，我们有一个位于美国的IP 1.2.3.4的服务器和位于德国的IP 2.3.4.5的caching服务器。 现在，访问者尝试parsing域example.org 。 如果他没有改变他的networking设置，他使用他的互联网服务提供商（ISP）的DNS服务器。 这个ISP现在要求dns1.example.com （域的名称服务器）。 现在取决于ISP的位置。 如果位于德国，则dns1.example.com返回2.3.4.5 ，如果位于美国，则返回1.2.3.4 。
但是这种方法可能有一个缺点：每次用户改变他的networking设置并使用一个不兼容的DNS提供商（例如一个公司的中央DNS服务器）的dns1.example.com （见IETF草案 ）时， dns1.example.com将会离这些DNS位置最近的IP，但是这次访问者很可能在不同的位置导致更高的延迟。
兼容EDNS0的DNS提供商将有关用户的信息传递给权威DNS服务器。 所以权威的DNS服务器可以用用户的位置旁边的IP来响应：
今天，如果您正在使用OpenDNS或Google公共DNS，访问网站或使用全球互联网加速中的某个参与networking或CDN提供的服务，则会在您的DNS请求中添加截断的IP地址版本。 互联网服务或CDN将使用这个截断的IP地址作出更明智的决定，以便它能够响应，以便您可以连接到最优化的服务器。
…
; EDNS: version: 0, flags:; udp: 512 ; CLIENT-SUBNET: 130.89.89.0/24/21
任播
根据“任播路由”的概念，路由到最近的caching节点。 这里，高速cachingA，高速cachingB和高速cachingC将使用相同的相同IP地址，并且路由将负责到达最近的一个。
由于BGP等原因，我不太了解Anycast，但我认为Anurag Bhatia的进一步解释给出了一个想法：
- 优化基于BGP路由和通告，而DNS的作用很小。
- 这种设置非常难以build立和扩展，因为任播在全球范围内完美地工作，每个地点都需要很多的对等和一致的过境提供商。 如果任何一个对等体泄漏到上游或其他对等体的路由，则由于任播被中断，在给定的群集上可能会有大量的意外stream量。
- 这个设置不依赖于DNS recursor，因此Google DNS或OpenDNS工作得很好。
- 这节省了大量的IP地址，因为在多个地点使用相同的池。
任播也有一个缺点：路由是灵活的。 而在TCP会话开始时，目标节点可能位于networkingA中，它可能会变成networkingB.因此Anycast将仅用于UDP。 UDP是无会话协议。
大多数CDN使用DNS进行HTTP / HTTPS通信，Anycast进行DNS请求。