JA EN
shiichan

QUIC の RTT がルールで見えるようになったよ！接続品質でルーティングを出し分けよう

Cloudflare Changelog ★★★★ Markdown で見る
#cloudflare#infrastructure#devops

こんにちは、しぃちゃんだよ！今日はネットワークの中身がちょっと覗けるようになる、地味だけど便利なアップデートを見つけたよ。

Cloudflare Changelog developers.cloudflare.com

なにが発表されたの？

Cloudflare の Changelog で、ルール式で使える新しいフィールドが 2 つ追加されたって発表があったよ。クライアント接続の L4（トランスポート層）のテレメトリーが、ルールの中から直接見られるようになったの。

  • cf.timings.client_quic_rtt_msec(Integer): Cloudflare とクライアントの間の、平滑化された QUIC の RTT（往復時間）をミリ秒で返すよ。QUIC（HTTP/3）の接続だけで値が入って、TCP 接続では 0 になるの
  • cf.edge.l4.delivery_rate(Integer): クライアント接続の直近のデータ配信レートの推定値を、バイト毎秒で返すよ。L4 の統計が取れないリクエストでは 0 になるんだって

既存の cf.timings.client_tcp_rtt_msec と組み合わせると、TCP でも QUIC でも接続品質をまるっと把握できるようになるよ。

今までどうだったの？

今までも QUIC の RTT や配信レートのデータ自体は存在してたんだけど、Server-Timing: cfL4 というレスポンスヘッダー経由でしか手に入らなかったの。ルール式の中で直接条件分岐に使うことはできなかったんだよね。

これで何が変わるの？

同じデータがルール式のフィールドとして使えるようになったから、Transform Rules や WAF Custom Rules をはじめ、動的フィールドに対応してるフェーズで、接続品質に応じたルーティングやレスポンスの出し分けができるようになるよ。クライアント側の変更は一切いらないのがうれしいポイントだね。

深く潜ってみよう

Changelog では、さっそく実用的な例が 2 つ紹介されてるよ。

高レイテンシの接続を軽量なオリジンに振り分ける例

リクエストヘッダー変換ルールで、レイテンシの高い接続からのリクエストにタグを付けて、オリジン側で軽いページを返せるようにする使い方だよ。

ルール式:

cf.timings.client_tcp_rtt_msec > 200 or cf.timings.client_quic_rtt_msec > 200

ヘッダー変更: X-High-Latency ヘッダーに true をセット

低帯域の接続を判定する例

cf.edge.l4.delivery_rate > 0 and cf.edge.l4.delivery_rate < 100000

こんな感じで、配信レートのしきい値を使って低帯域の接続を見分けることもできるよ。

まとめ

  • ルール式で使える新フィールド cf.timings.client_quic_rtt_msec(QUIC の RTT)と cf.edge.l4.delivery_rate(配信レート)が追加されたよ
  • これまで Server-Timing: cfL4 ヘッダーでしか見られなかったデータが、Transform Rules・WAF Custom Rules などで直接使えるように
  • 高レイテンシ接続へのタグ付けや、低帯域接続の判定といった、接続品質に応じたルーティングがクライアント側の変更なしで組めるよ

エッジでのルーティングを接続品質できめ細かく制御したい人にぴったりのアップデートだよ！

関連記事