硬直化の回避に必要なのは一致団結した行動
1990年代、「19」から始まらない西暦によって起こりうる混乱を前に、世界中のソフトウェアエンジニアが対応を急いでいました。Y2K 問題とも呼ばれたこの問題は、硬直化の最も有名な例の一つです。変化がない、もしくは長期間変化がなかったため今後も変化がないことを前提とすることで、硬直化が起こります。
Y2K 問題は、変化が簡単に予測可能だった点で特に嘆かわしい例ですが、こうしたリスクはインターネット・インフラストラクチャ・プロバイダーとして Fastly が提供するサービスにも潜在するものです。Fastly ではお客様にインターネットプロトコルへの低レベルのアクセスを提供しているため、意図せずにインターネットの未来に悪影響を及ぼさぬよう、団結して配慮しなければなりません。では硬直化を防ぐために私たち全員が担う役割について見ていきましょう。
進化性が築く柔軟なインターネット
インターネットは非常に頑丈なシステムです。1970年代から1990年代にかけて設計されたネットワークプロトコルが今でも利用可能な理由の一つは、これらが進化性を考慮して設計されたものであるためです。設計者らは先々の変化を予測し、インターネットに障害を及ぼすことなく新機能を追加したりプロトコルを変更したりするための手段を意図的にプロトコルに組み込みました。
インターネット全体を同時にアップグレードすることは不可能なため、一部の関係者のみが変更内容を把握しているのではなく、円滑なコミュニケーションと段階的な変更が可能であることが非常に重要なのです。このような設計は通常、拡張およびバージョニングを可能にした構成によって実現できます。IPv4 のアドレス枯渇問題へも、進化性を考慮した設計により、IPv6 を徐々に導入し対応することができました。また TLS の新バージョンの導入を可能にすることで、Web や他のアプリケーションでのセキュリティ向上を実現しています。HTTP/2 による Web パフォーマンスの改善や、ヘッダー、メソッド、ステータスコードを使った新機能の導入も進化性の賜物です。
インターネットの進化を妨げる硬直化
アプリケーション、ネットワークデバイス、その他の要素によってプロトコルのバージョニングや拡張仕様が阻害されてしまうと、プロトコルに柔軟性をもたらす部分が「錆びついて」しまい、硬直化が起こってしまいます。このような問題は、プロトコルへの変更を想定せずにプロトコルが実装・使用される場合に多く発生します。
たとえば、Web アプリケーションファイアウォール (WAF) が target=value のような文字列を含むヘッダーのリクエストを拒否してしまうと、ブラウザが新たなヘッダーを導入することが難しくなります。信じられないような話ですが、実は既に起こったことなのです。
TLS 1.3 も硬直化の被害を受けたプロトコルの一つです。一部のサーバーが、対応しているバージ ョン以降のバージョンを想定しなかったため、プロトコルヘッダーのバージョン文字列を TLS 1.2 の値に設定するように指定されています。このような「バージョン不耐性 (version intolerance)」は、新規プロトコルのデプロイにおいて複雑性やリスクを引き起こします。
硬直化が起こると、プロトコルへの新機能の導入が困難になります。そして最終的には、硬直化が進んでしまったプロトコルを置き換えざるを得なくなります。この硬直化の問題は、現在 TCP でも起こっています。多くのネットワークデバイスが、パフォーマンスを改善しようと TCP の仕組みを完全に理解せずに WAN アクセラレーターなどを導入してしまったため、全く新しいアプローチである QUIC が必要になったのです。善かれと思って設計されたこれらの装置は、接続の最適化や変更をエンドポイント側から加えようとしていた人達との対話なしに導入されてしまったため、実際はパフォーマンスや信頼性に悪影響を及ぼしていたのです。
Fastly と共に硬直化のリスクを管理
Fastly では、VCL や Compute@Edge のお客様のコードに対し、低レベルのプロトコル詳細を公開しています。これは、この情報を利用して Fastly 上により高性能なシステムを構築可能にするために、Fastly が意図して行っていることです。その代わり、私たち Fastly 社員も心がけているように、プロトコルの硬直化につながるような行動や決断を控えていただくようお客様に呼びかけています。
特に、クライアントの行動や正常なトラフィックに関する思い込みは、硬直化につながるリスクがあります。一時的に問題が改善したとしても、これらの解決法は先々の (ブラウザなどによる) 変更によって無効となり、アプリケーションにて予測せぬ問題を招くことがあります。
硬直化のリスクは、プロトコル仕様に基づいてサイトの仕組みを変更するクライアント分類子や WAF などを構築する際に多く発生します。Fastly の WAF や内蔵のデバイス検出メカニズム (VCL のclient.class.*、client.platform.*、client.display.* など) を使用することで、お客様に代わって Fastly が硬直化リスクの大部分に対応することができます。しかし、自分自身でこうした機能を構築してしまうと、意図せずインターネットの硬直化の一因となってしまう可能性があります。
特に HTTP バージョン、HTTP リクエストヘッダー、TLS、TCP、QUIC の接続情報といった低レベルのプロトコルメタデータに基づいたリクエストの拒否も、硬直化のリスクを高めてしまう恐れがあります。また、制限に直面した人が問題を報告できる実用的なフィードバックチャネルが存在しない場合、人々が編み出した回避策がインターネットの硬直化を進めてしまう可能性が高まります。
以下のポイントを考慮することで、責任を持って機能やプロダクトを構築することができます。
さまざまな早期公開ブラウザや HTTP クライアントで継続的にテストを行い、相互運用性の問題を早期に検出する
自分のプロダクトに関する言及がないか、ブラウザのバグキューを定期的に確認する
プロダクトの作成者がすぐに分かるよう、プロトコル内に明確に表示する
サポートチャネルやバグキュー、専用のメールアドレスなどを使用し、ブラウザやクライアント開発者が必要に応じて連絡を取れるようにする
プロダクトの仮定を破る可能性のある、関連するプロトコルにおける変更を追跡する。IETF HTTP ワーキンググループや IETF TLS ワーキンググループを確認すると良いでしょう。また、特定のプロトコルの硬直化に関するディスカッションや通知が行われる、専用の http-grease リストもあります
硬直化を防ぐには、インターネットに携わる人すべてが一同に取り組まなければなりません。プロトコル拡張ポイントを誤用するサイトやプログラムは存在し続けますが、これらを最 小限に抑えることで、インターネットのスムーズな進化と問題解決を実現することができます。
