如何獲得伺服器的任播？
我想為我的網路服務提供任播，但我找不到任何關於如何實現這一點或任何可以提供幫助的公司的資訊。
我發現有很多公司提供任播 DNS，但這不是我需要的。
我有一個無狀態的 Web 服務，我想在地理上分佈它，使用任播來負載平衡和增加正常執行時間。公司是否有任何技術原因不能只為我在多個數據中心宣傳 IP 地址？
我需要了解有關任播的哪些技術方面的知識，以評估現有產品並幫助我找到可以幫助我的公司？我需要注意哪些陷阱？
為了滿足您的特定要求，需要了解有關任播的兩個不同方面。第一部分是如何廣播和路由任播地址。第二個是 TCP 對任播地址的挑戰是什麼，以及如何解決這些挑戰。
宣布和路由
為了使 BGP 表保持在可接受的大小，如果前綴太長，大多數 AS 將過濾傳入的公告。對於 IPv4，門檻值往往是 /24 前綴，這意味著 256 個地址。這意味著為了在公共網際網路上進行任播，您至少需要 256 個地址。
如果您已經擁有自己的 /24 前綴，那麼沒有太多阻止託管服務提供商代表您宣布它。如果是這種情況，選播對您來說就像找到一堆願意以合適的價格提供此服務的不同託管服務提供商一樣簡單。然後，您只需讓他們所有人代表您宣布前綴即可。
您可以查看有關廣告路線的公開可用資訊，以查找已經代表其客戶宣布前綴的提供商，以便將您引導至可能提供此類服務的提供商。在路由表中查找它的一個工具是bgp.he.net。
如果您沒有自己的前綴並希望從提供商處獲得前綴，那麼了解上述限制對該提供商意味著什麼很重要。
提供商有足夠的 IP 地址，他們可以配置任播前綴。但是，一旦他們這樣做了，他們就會承諾將所有 256 個地址用作任播。並且所有 256 個地址必須託管在完全相同的一組位置中。
出於這個原因，您有時會看到分配了 256 個地址，以便僅將其中一個用於任播服務。這可能是您的第一次機會。一個已經任播前綴的提供者實際上可能有 250 個未使用的任播地址。如果您的服務對提供商來說足夠“有趣”，他們可能願意租用您在其中一個剩餘地址上託管。一個重要的警告是，您必須託管在與其主要任播服務完全相同的位置。並且可能需要他們在他們認為合適的情況下移動您的服務的安排，因為這是他們的主要任播服務決定需要託管的位置。
以上大部分內容都假設提供商託管服務的位置與他們宣布前綴的位置之間大致存在 1:1 的對應關係。
如果託管服務提供商擁有自己的冗餘骨幹網和自己的數據中心，那麼他們可以在與其託管位置不同的一組位置宣布前綴。此外，在內部，它們可以將更長的前綴路由為單播或任播。
例如，如果提供商在四個不同的 POP 中宣布 /22，並且它們之間有一個冗餘網路（例如四個連結的環），他們可以在內部將 /24 或 /25 路由到每個 POP，並且可能留出一個/28 被任播到所有 POP（這實際上意味著由數據包首先進入其網路的 POP 提供服務）。
如果您可以找到同時擁有冗餘骨幹網和數據中心的提供商，那麼這樣的提供商就更容易為您的服務選擇他們自己的 IP 地址之一。但是請記住，這樣做時，您的服務會在其每個骨幹路由器中使用一個 CAM 表條目。你必須為此付出代價。
TCP 和任播
正如一些評論指出的那樣，TCP 是一種有狀態的協議。因此，即使您認為您的 Web 服務是無狀態的，它仍然在 TCP 層具有狀態。這樣做的結果是天真地任播基於 TCP 的服務將是使用者將經歷非常頻繁的連接重置。
這個問題可以通過在實際 Web 伺服器前面放置另一層來解決。所需要的是一個節點層，可以將接收到的 TCP 數據包轉發到適當的 Web 伺服器，並通過連接始終如一地這樣做。到目前為止，這幾乎描述了基於標準 DSR 的負載均衡器。
但是，由於此負載均衡器有多個實例，它們需要共享狀態。分佈式雜湊表是可用於該層的資料結構。
此外，來自負載平衡層的數據包需要不加修改地轉發到後端。基於原始數據包的目標 IP 的 IP 路由無法解決該問題，因為該目標地址仍然是任播地址，因此數據包永遠不會到達後端，而是簡單地反彈回負載均衡器並循環，直到TTL 已過期。
典型的負載均衡器通過修改目標 MAC 地址並轉發它來解決這個問題，從而繞過 IP 路由。這僅在您的負載均衡器和後端都位於一個位置並且它們之間的網路完全交換且負載均衡器和後端之間沒有任何路由器的情況下才有效。
然而，有一種不同的方法來解決這個問題。從負載均衡器到後端的數據包可以通過 IP 隧道發送。外層IP頭攜帶一個目的地址，它是一個指向後端的單播地址。內部 IP 標頭未修改，並攜帶客戶端 IP 作為源和任播 IP 作為目標。
在此設置中，外部標頭的源 IP 大多未使用。原則上它應該是接收數據包的負載均衡器的單播地址。但是，某些服務（例如 facebook）將客戶端 IP 從內部標頭複製為外部標頭上的源 IP。facebook 的這個錯誤可以從外部檢測到，因為有時隧道數據包會觸發 ICMP 錯誤，該錯誤會直接發送回客戶端。
內部和外部報頭無需使用相同的 IP 版本。因此，負載均衡器和後端所需的單播地址都可以是 IPv6，這樣負載均衡器和後端的數量就不受 IPv4 地址可用性的限制。
使用上述設計具有額外的優勢，即負載均衡器在此設置中通常只需要一小部分硬體，並且只有負載均衡器需要通過任播地址到達。這意味著，如果您的任播地址需要重新定位並發出簡短的警告，因為搭載了主要為不同服務分配的任播前綴，這不是問題。
陷阱
顯然，上面的設置比簡單地部署一堆獨立的 Web 伺服器要復雜得多。複雜的設置往往是不可用的根源。因此，必須在這樣的方案中投入一些工作，以使其足夠健壯，比其他方案更可靠。這意味著這更有可能應該作為 CDN 服務的一部分部署，而不是為單個 Web 服務部署的東西。
如果您嘗試使用比上述設置更簡單的任何方式進行任播 TCP，您很可能會遇到路由更改中間連接的問題，結果使用者將遇到重置。
Anycast 可能對可用性、延遲和負載平衡有好處。然而，它不是靈丹妙藥。Anycast 確實平衡負載，您可以通過添加更多節點來擴展負載。但是不要指望任播所達到的節點之間的負載接近完美平衡。在上述帶有分佈式負載平衡層的設置中，負載平衡器本身可能無法獲得均勻的負載，但它們可以在後端之間均勻地分配負載。
不要依賴單個任播 IP 來確保可用性。如果您的某個節點出現故障，路由可能不會自動將其拾起。它不會影響所有客戶端，但一部分客戶端可能會將其數據包路由到已關閉的節點。因此，對於這些客戶端，您的任播 IP 地址已關閉。如果您想要冗餘，則需要多個任播 IP 地址。
只要路由在連接過程中不發生變化，延遲就會很好。但是一旦 TCP 握手完成，您就承諾在 TCP 連接期間使用特定的後端。數據包必須從客戶端到負載均衡器再到後端和客戶端。這種三角形路由會增加延遲。任播可以減少延遲，並且能夠選擇最近的後端，但是在往返中有三個腿而不是只有兩個腿會增加延遲。只有收集大量真實世界的測量數據才能告訴您這兩個因素中哪一個更重要。