サーバーが数億のクライアントに同時にサービスを提供するGoogleChatなどのWebアプリケーションについて考えてみます。このようなアプリケーションでは、サーバーはほぼリアルタイムでクライアントに通知をプッシュする必要があります（チャットの例では、着信メッセージ、プレゼンス通知など）。
彼らはそれをどのように実装しますか？クライアントの重要な部分はブラウザベースです。ポーリングはGoogleのサーバーでさえ過負荷になると思います。それで、彼らはコメットのようなものを使っていますか？もしそうなら-彼らは65536クライアントごとにサーバーを割り当てる必要がありますか（マシンあたりの最大TCP接続）？この制限を回避する方法があることは理解していますが、どのように実装されているのかわかりません。
チャットは単一のアプリケーション/ハードウェア/インスタンスでは処理されません。彼らは間違いなく、チャットシステムを水平方向に拡張できる負荷分散を備えた多くのインスタンスを使用しています。リージョン専用の場合もあれば、単一のクラスター化システム専用の場合もあります（リージョン内専用であると思いますが、リージョン内でクラスター化されています）。同様に、ハードウェアとネットワークが処理できるのと同じ数の接続を持つことができますが、64kはできません。64k（実際にはそれよりも少ない）はバインディングソケット（サーバーソケットですが、クライアントソケットではありません）に関するものだからです。
グーグルの場合、サポートされているブラウザに基づいて、彼らは間違いなく混合技術を使用して、ブラウザのサポートに基づいて最も強力なものを選択して通信します。これは、長いポーリング、ソケット、さらには最も古いもの、つまり単純なajaxである可能性があります。
同様に、例えば、Facebookチャットはerlangに基づいています。そしてerlangを使用すると、100万を超える接続を持つ多くの例があります。
グーグルがこれをどのように処理するかはわかりませんが、おそらく彼らは私たちに教えてくれません。しかし、今日では、httpストリーミング、WebSocket、または長いポーリングを処理して、そのようなアプリケーションを構築できます。Atmosphereフレームワークの例を示します
は、「リアルタイム」で効率的でスケーラブルなWebアプリケーションを構築するためのツールです。