HappyEyeballsは、IPv4とIPv6を試行し早く接続したほうを利用します。

一方で、HappyEyeballsを使うことで接続の問題に気づきづらいという主張もあります。IPv4もしくはIPv6のどちらかでネットワーク上のエラーがあったとしても、もう片方にフォールバックされるため、ユーザは問題が起こったことに気づきません。
そこで、アプリケーションがそのネットワークエラーをレポートとして提出する方法はないかということで、幾つかの提案が出ています。
- 『Slow Alternate Detection for Happy Eyeballs』は、ICMPベースで通知を行います。ICMPですのでネットワーク経路上の主体に対してのシグナルになります。
- 『Network Error Logging』はブラウザの機能であり、Webサイト閲覧中に発生したネットワークエラーをHTTPレスポンスヘッダで指定されたエンドポイントに報告します。現状は、HappyEyeballsに関する機能はありませんが、この仕様を拡張できます。
これらの議論は、古くは2017年(draft)から行われておりますが、現在HAPPY WGの創立とともに改めて議論が行われております。
Happy Eyeballs エラーレポーティング に関する考慮事項
ここまで話しただけでも、課題に対する方向性は複数あるわけです。
そこで、論点を整理する『Considerations for Happy Eyeballs Error Reporting』というdraftが出されています。
- 何をレポートするか: 送信元IPアドレス? 送信先IPアドレス? フォールバックの原因、タイムアウト値?
- いつレポートするか: エラーの度?集約して?
- どうやって(誰に)レポートするか: syslog? ICMP? NEL? あるいは新しいフォーマットで?
さらに、これらの議論にはユーザのプライバシーの観点もあり、そこについても慎重に進める必要がありそうです。
感想
インターネットのユーザ環境は様々であり、疎通性の問題は非常に複雑だという意見も出ています。どれくらいの情報があればデバッグに役に立つのか未知数なところはあります。
もちろん、ブラウザベンダーやアプリケーション開発者が独自にレポートの仕組みを実装しているケースもあるわけで、何かしら有用な仕組みに落ち着くと良いなあとおもいました