Tag: argo

試用 Cloudflare 的 Argo Tunnel

Cloudflare 宣佈讓大家免費使用 Argo Tunnel 了，也順便改名為 Cloudflare Tunnel 了：「A Boring Announcement: Free Tunnels for Everyone」。

Starting today, we’re excited to announce that any organization can use the secure, outbound-only connection feature of the product at no cost. You can still add the paid Argo Smart Routing feature to accelerate traffic.

As part of that change (and to reduce confusion), we’re also renaming the product to Cloudflare Tunnel. To get started, sign up today.

Cloudflare Tunnel 的功能就像 ngrok，在用戶端的機器上跑一隻 agent 連到 Cloudflare 或是 ngrok 的伺服器，這樣外部連到 Cloudflare 或是 ngrok 的伺服器後就可以透過這組預先建好的連線連上本機的服務了，常見的應用當然就是 HTTP(S) server。

本來是付費功能，一般使用者應該也不會需要這個功能，這次把這個功能免費丟出來的用意不知道是什麼...

不過既然都免費了，還是花了點時間測了一下，可以發現 ngrok 的設定比較簡單，Cloudflare 的 cloudflared 設定起來複雜不少，不過文件還算清楚，照著設就好。

Anyway，有些事情有了 Cloudflare Tunnel 就更方便了，像是有些超小型的 VPS 是共用 IPv4 address 而且沒有 IPv6 address 的，可以透過 cloudflared 反向打進去提供服務，同樣的，在 NAT 後面的機器也可以透過這個方法很簡單的打通。

順便說一下，現在的 blog.gslin.org 就是跑在 cloudflared 上面了，官方提供的 ARM64 binary 跑在 EC2 的 t4g 上面目前看起來沒有什麼問題，而且比起本來 nginx 都是抓到 Cloudflare 本身的 IP，現在加上這兩行後反而就可以抓到真的使用者 IP address 了：

    set_real_ip_from 127.0.0.1;
    real_ip_header X-Forwarded-For;

跑一陣子看看效果如何...

Cloudflare 在 Argo 架構上推出 Tiered Cache Smart Topology

Cloudflare 在 Argo 架構上 (付費功能) 推出了 Tiered Cache Smart Topology：「Tiered Cache Smart Topology」、「Introducing: Smarter Tiered Cache Topology Generation」。

這邊提到的 Argo 是 Cloudflare 在 2017 年時提出來想要降低 Internet 的 routing (像是 BGP) 未必會走到最佳路徑上的問題，透過 Cloudflare 自家的骨幹網路，最佳化 latency & bandwidth & packet loss 產生的問題：「Introducing Argo — A faster, more reliable, more secure Internet for everyone」。

而 Tiered Cache 算是 CDN 行業裡面很常見的技術了，主要是要解決不同 data center 的 edge server 都去跟 origin server 要資料，而造成 origin server 的流量太大。

緩解的方式是在 edge server 與 origin server 中間疊一層 cache server，就可以大幅緩解 origin server 的流量。

origin server 流量問題在一般的應用來說還好：就算是 Windows Update 或是 iOS 更新這種基數超大的量，一開始也許會慢一點，但當 edge server 有 cache 後就不會再吃到 origin server 的頻寬。

另外也可以在公開上線前先 pre-warm，讓 edge server 都有 cache 後再上線，這樣 origin server 就不需要準備太多頻寬。

但在大型影音直播的時候就不一樣了，因為會一直產出新的內容 (之前玩的是走 HLS，所以會一直有新的 .ts 檔生出來)，沒辦法先 pre-warm，這時候 origin server 就會需要大量的頻寬才有辦法支撐整個服務，所以需要 CDN 系統在中間疊一層 cache server，這個功能在各家 CDN 業者都有，只是名稱不太一樣。

記得當時用 Akamai 預設的 CDN 走直播時只有 95% 左右的 hit rate，這代表對外服務 20Gbps 就會對 origin server 產生 1Gbps 的量 (20:1)，而打開 Tiered Distribution 後可以拉到 98% 甚至 99%+，相對於後端的壓力可以降到 50:1 到 100+:1。

在 AWS 的 CloudFront 也有類似的架構，叫做 Regional Edge Caches：

不過這兩種架構都有一些缺點，像 Akamai 需要自己指定 cache server 的節點，這樣就不容易動態調整，或是使用者沒有設好導致 latency 偏高。

而像 AWS 這種已經已經先分好群的，就會遇到像是 origin server 與 edge server 都在台灣，但在 Regional Edge Caches 架構下必須先繞到日本 (或是新加坡)，產生 latency 與 packet loss 偏高的問題。

這次 Cloudflare 在 Argo 架構推出的 Tiered Cache Smart Topology 的賣點 (Argo 本來就有提供 Tiered Cache)，看起來是希望由系統自動選擇最佳的一個 data center 來當作 cache tier，不需要使用者額外設定。

不過一般網站應該還好，主力應該在電商網站與互動性很高的娛樂產業 (i.e. 操作起來要很流暢)...

將本機開發網站展示給外部看的工具 inlets

要講 inlets 前要先講 ngrok 這個服務。這個服務可以在開發機上主動建立連線到外部伺服器，接著透過這個連線與本機的 web server 溝通，讓外部的客戶可以很方便的進行測試 (通常會開個 Zoom 之類的工具邊討論邊修改)，算是 reverse proxy as a service 的服務。

類似機制的服務還有 Cloudflare 的 Argo Tunnel，不過產品定位不太一樣。

而 inlets 就是 open source 版本的 ngrok，你只要在外部租一台主機就可以用了。左邊是自己的開發機 (像是 Macbook)，右邊則是外部的主機 (租用 VPS)：

不過這個跟開發模式也有關...

Cloudflare 推出 Argo Tunnel

Cloudflare 推出了 Argo Tunnel，可以將內部網路與 Cloudflare 之間打通：「Argo Tunnel: A Private Link to the Public Internet」。

Cloudflare 在去年推出了 Wrap (可以參考「Cloudflare 推出的 Wrap 讓你不用在本地端開對外的 Port 80/443」這篇)，這次其實只是改名：

During the beta period, Argo Tunnel went under a different name: Warp. While we liked Warp as a name, as soon as we realized that it made sense to bundle Warp with Argo, we wanted it to be under the Argo product name. Plus, a tunnel is what the product is so it's more descriptive.

看起來沒有什麼新的玩意... 純粹改名字 :o