websockets を proxy 環境でも利用する場合の注意点
ええとコメント頂いたのでまじめに書くことにします。
（ちょっとアングラな世界でドライバ作ってました）
現在のwebsocketsのクライアント側の実装でproxy越えをしようとする場合、サーバ側で特殊な考慮をしておかないと繋がらない環境が多いと思います。
ちょっとややこしいので順を追って説明します。
・クライアント側の実装でproxy越えする際にはProxyに対し CONNECT を発行する
・proxyでCONNECTできるのは接続先ポートがhttps(443)に制限されている場合が多い
（squidはデフォルト。443以外のSSLポートをSquidでプロキシするには辺り参考）
・一方、サーバ側はというとhttps使ってるならhttpsの場合が多い。
・websocketsで443に繋いだとしてもSSLのハンドシェークは行われない
以上から、proxy経由でのwebsocketsをなるべく利用可能にするならrawな（SSLでない）websocketsの口をポート443であけて置く必要があります。このblogに張ったwebsockets chatはこの対応をやってます。(httpsは潰してますｗ）
ま、現状の実装（websockets, proxy）での話しなのでこの先は分かりませんが…。
後、思い浮かぶことをつらつらと。
# 元記事の proxy のキャッシュっていうのは、元記事のネタ元Blogの記事でjpegという静的ファイルのダウンロードの高速化を取り上げててそれに反応しての記述です。もちろんキャッシュが効かないコンテンツに対してProxyのキャッシュ云々という話は、websocketsだろうがajaxだろうがhttpだろうが関係ありません。
新技術って何のために有るのかを考える必要が有ります。
既存技術を使って出来ること新技術で置き換える場合、そこには何らかのメリットが必要ですよね。
またデメリットが有るならそのメリットとデメリットどちらが大きいか計る必要も有ります。
単純にメリットデメリットと言っても、立場はそれぞれでサービサー・顧客・開発者色々です。
webの高速化に１台のクライアントからセッションがんがん張ってそのためにwebsockets利用って言うのは違う気がしたんですよね。クライアントからのセッション数がHTTP/1.0で4本、HTTP/1.1で2本に制限されてるのも訳有ってのことなのですよ。
pipelineに関してはもっと低レベルな話でGoogleのSPDYとかがまっとうなアプローチな気がします。サーバ、クライアント、Proxyその他色々インフラ面での対応が必要ですがコンテンツ側は意識する必要が無いという利点が有ります。
websocketsに関して言えばまだまだ出てきたばかり動くようになったところで、websocketsを使って何をするかって言うのもこれからだと思います。そんな中でwebcoskets + pipelineで高速データ転送！っていうのがスタンダードな使い方に成ってほしく無いなと。