小林 (koichik) さん、 森(mori_dev) です。 HTTPだと、途中のProxyなどによってはUpgrade: が通らない可能性があるため、 HTTPを推奨しているのかもしれない。だから、xhr-polling で使う場合、WebSocket への Upgrade: 処理は行わないのだし、HTTP でよさそうだとのこと。
わかりました。ありがとうございました。 私の方でさらに調べたところ、 RFC6455 WebSocket ( http://tools.ietf.org/html/rfc6455 ) に、ハンドシェイク時の仕様で、以下のような関係がありそうな記述をみつけたのですが、 4.2.2. Sending the Server's Opening Handshake When a client establishes a WebSocket connection to a server, the server MUST complete the following steps to accept the connection and send the server's opening handshake. 1. If the connection is happening on an HTTPS (HTTP-over-TLS) port, perform a TLS handshake over the connection. If this fails (e.g., the client indicated a host name in the extended client hello "server_name" extension that the server does not host), then close the connection; otherwise, all further communication for the connection (including the server's handshake) MUST run through the encrypted tunnel [RFC5246]. "otherwise, all further communicatio for the connection (including the server's handshake) MUST run through the encrypted tunnel [RFC5246]." だと何か困るのか？だから HTTPS 推奨なのか、 といったところまではたどり着きませんでした。 socket-spec を書いた人が HTTPS を推奨する理由を説明している資料を見つけたら、 この ML で報告しようと思います。 ありがとうございました。 2013年12月8日 1:00 Koichi Kobayashi <koic...@improvement.jp>: > 小林 (koichik) です。 > > トランスポートの一つであるWebSocketは、最初HTTP(S)で > 接続してからUpgrade:によってプロトコルを変更します。 > しかしHTTPだと、途中のProxyなどによってはUpgrade: が > 通らなかったりするかもしれません。 > > HTTPSにすれば、途中のProxyなどでは通信の中身が > 見えないため、トラブルが少なくなると期待して > 推奨しているのかなと推測してみました。 > > もっとも、AWSのELBのようにSSLターミネータな > ところで弾かれるケースもあるわけですが。。。 > > この理由はトランスポートにXHR等を使う場合は > 関係なさげですね。 > > Socket.IOの中の人の意図はわかりませんが、 > 可能性の一つということで。 > > > On Sat, 7 Dec 2013 23:48:44 +0900, mori dev <mori.dev.a...@gmail.com> > wrote: > > > はじめまして。 > > ハンドルネーム mori-dev と申します。Node 歴は 3週間ほどです。 > > > > Socket.IO の HTTP リクエストで、URI スキーマとして HTTPS が socket.io-spec > > で推奨されている理由はなんでしょうか。 > > > > socket.io-spec ( https://github.com/LearnBoost/socket.io-spec#uri-scheme) > > というページで、Socket.IO の HTTP リクエストで、URI スキーマとして HTTPS が socket.io-spec > > で推奨されています。 > > > > URI scheme > > The URI scheme is decided based on whether the client requires a > > secure > > connection or not. Defaults to http, but https is the recommended > > one. > > > > この根拠は何でしょうか。とくにふかよみするようなところではなく、本文から読み取れるとおり、通信が暗号化されていて HTTP > > よりセキュアだから、ということでしょうか。 > > publich key の 「SPDYやQUIC登場の背景。Webの進化がプロトコルを変えつつある。HTML5 Conference 2013 ( > > > http://www.publickey1.jp/blog/13/spdyquicwebtcphtml5_conference_2013.html) > 」という記事には「HTTPSではTCPコネクションを複数張っているので、1つが欠損してもほかのTCPコネクションは関係なくデータを送れます。」とあります。これも推奨する根拠と関係があるのでしょうか。 > > > > Socket.IO の v0.9.16 を、xhr-polling, jsonp-polling > > で利用する予定で、調査していて、疑問に思い、質問しました。 > > たとえば、以下のような http リクエストではなく > > > > > > > http://localhost:8081/socket.io/1/xhr-polling/sIp1vNChR6RLWu74equ1?t=1386426845697 > > > > https モジュールを使った結果に対し、socket モジュールを使い、 > > > > > > > https://localhost:8081/socket.io/1/xhr-polling/sIp1vNChR6RLWu74equ1?t=1386426845697 > > > > といったふうにするのが推奨されているようだ、という認識です。 > > > > > > 関連リンク > > > > * https://github.com/LearnBoost/socket.io-spec#uri-scheme > > * > > > https://github.com/Jxck/socket.io-spec#uri-%E3%82%B9%E3%82%AD%E3%83%BC%E3%83%9E > > > > -- > > > > --- > > このメールは Google グループのグループ「Node.js 日本ユーザグループ」の登録者に送られています。 > > このグループから退会し、メールの受信を停止するには、nodejs_jp+unsubscr...@googlegroups.comにメールを送信します。 > > その他のオプションについては、https://groups.google.com/groups/opt_out にアクセスしてください。 > > > -- > { > name: "Koichi Kobayashi", > mail: "koic...@improvement.jp", > blog: "http://d.hatena.ne.jp/koichik/";, > twitter: "@koichik" > } > > -- > > --- > このメールは Google グループのグループ「Node.js 日本ユーザグループ」の登録者に送られています。 > このグループから退会し、メールの受信を停止するには、nodejs_jp+unsubscr...@googlegroups.comにメールを送信します。 > その他のオプションについては、https://groups.google.com/groups/opt_out にアクセスしてください。 > -- --- このメールは Google グループのグループ「Node.js 日本ユーザグループ」の登録者に送られています。 このグループから退会し、メールの受信を停止するには、nodejs_jp+unsubscr...@googlegroups.com にメールを送信します。 その他のオプションについては、https://groups.google.com/groups/opt_out にアクセスしてください。
