CROSS 2013レポート(2)
CROSS 2013レポートパート2です。次世代Webセッションのメモ。
間違いや発言意図と違う表現だ、などということがあると思います。ご指摘いただければ幸いです。
次世代Webセッション前半〜プロトコル編
- http://www.cross-party.com/programs/?p=138
- http://www.ustream.tv/recorded/28598269
- 司会 Jackさん(@Jxck_) 以下J
- 大津さん(@jovi0608) SPDY関連 以下jovi
- 小松さん(@komasshu) Websockets 以下koma
- 清水さん(@kazubu) HTTP/2.0 以下kazubu
HTTP2
- 2012/11最初のドラフト。絶賛議論中
- どんなところが問題?
- kazubu: 前回のIETFの続きのトピック。crimeアタックに関して圧縮回り見直しとか
- jovi: SPDYはSSLの上でやってるから気にしてくていいという話だった。crimeの衝撃。chromeは3ではdisableにした(クライアント側からの圧縮率を下げる)
- kazubu: 対応: 圧縮のコンテキストを分ける。headerとbodyとか。最近は圧縮方式を変える。
- crimeはhuffman木の再構成によって発生する。huffman木を変える方法が考えられている
- googleは前回と同じ物が来たときにだけフラグをつける。クッキーだけわかればいいという発想
- kazubu: 対応: 圧縮のコンテキストを分ける。headerとbodyとか。最近は圧縮方式を変える。
- HTTP2が出てきたときにどうupgradeするか
SPDY
- jovi: LINEの特徴
- koma: スマートフォンにはプライベートアドレスが払い出されてる
- マルチプレクシング
- SPDYでできちゃうのでWebsocktsでやらなくてもいいんじゃね的な
- per frame compression
- レスポンスを上げる → テキスト→バイナリ → 圧縮 → などとなっている
- J: SPDY: bandwidthよりRTTが重要という流れだと思うんですけど
- J:デバッグ大変ですよね!? → jovi:大変です!!
- HTTPのときはheaderのparseができればという話だったけど、SPDYのparserは個人でできる範囲をこえてしまった
- J: prioritizationというのがある。HTMLの世界でやっていたドキュメント読み込み順をSPDYに持ってきたときにどうなるかを考える必要がある
- 「ハイパフォーマンスWebサイト」は書き直さなきゃね!
- SPDY4ってどんなカンジなの?
- koma: layer violationがはげしくなってきて、階層どおりになっていない
SPDYとHTTP2とTLS
Websockets
- J: WebsocketsはHTTP→HTTP2に横からささってきた感じですが、これからはどうですか?
- koma: IE10でもWebsocketsがサポートされて、非常にいい実装になっている
- WSがこのまま世の中に普及するかというのは難しい。明日世の中のIEが全部10になるとかであれば使われるんでしょうが。IE678がいつなくなるかという話で、じゃあやっぱりsocket.ioでHTTPポーリング、ってなるでしょ。ああ、socket.ioは使われますよきっと
- koma: IE10でもWebsocketsがサポートされて、非常にいい実装になっている
- J: ブラウザ以外のWSのカベは?
- J: WSが切られちゃう件ってどうなんでしょ
- まあ、わけわかんない接続が残ってるの切るのは正しい対応なんでしょうけども
- 2本つないでみて試し、wsが使えるならupgradeしようみたいなのが出ているんですが、そのへんが難しい
- kazubu: IETFでも話題になっている。LBが作りにくい。SPDYでもpriorityをさばくのはLBなのにコンテンツはWebサーバーにあるというギャップがある
- J: WSもSPDYも接続を保持しないといけないからバランスしにくいのでは?
- koma: いままででもクッキーでセッションを考える必要はあった。data by data, frame by frameでLBしようとするとキツイという面はある
- jovi: chromeのgoogle map見ると、ひとつのTCPセッションに複数のホストが入っている。ワイルドカード証明書使ってDNSが同じアドレスになっているから、同じTCPセッションに入る。これは外から見てたらぜったいにわからない
- koma: シングルTCPに入れるのがいいかっていうと、回線品質が悪いときに急に悪くなったりというのがある。パラレルも使っていく工夫が重要
- kazubu: TCPいっぱい使うと間のNATがきびしくなるんじゃない?
- koma: HTTP時代の発想で20本も30本も張ると大変。でも1本にする必要はないんじゃない
- jovi: SSLのslow startから最高速が出てきたところでなんで切らなきゃいけないのって話。googleはこのへんもすごくやってる。half-close使ったりwindowサイズを3→10にしたり、SSL false startしたり
- こういうのがlinuxにも入っていて、みんな知らずに使っている
- J: イニシャルを速くするのと、つないだ後を速くするって話があって、つながっちゃえばやりようはあるんだろうけど、initialはなかなか難しいということか。3-way handshakeはどうしても必要だし
v6
- J: v6はどうなの?
- kazubu: 流行るといいですねーwww
- FBもgoogleも対応しているけど、v6で生活するというのは難しいよね
- kazubu: 流行るといいですねーwww
Webのこれから、どこに向かっていくのか
- kazubu: 効率化が進むけど、問題も引き起こすのでバランスが重要
- komasshu: ホームネットワークのTV・家電とクラウドの関わりが気になる。クラウドはSPDY,WSなどが進んでいくと思うが、ホームネットはHTTP以外のプロトコルでもガンガン動いている。シームレスにdevice - browser - serviceというトータルで考えないといけないと思う
- jovi: 過去から来ていたのはリアルタイム性、RTT。マルチプレクスがもうできた。本当の本当のリアルタイムはこれから先は劇的に伸びるものはもうない。これから先、どんな新しいパラダイムが出てくるかを見ていかないといけない。光はまだまだ遅いw
- Jxck_: みんなこういう話をするとすぐHTTPをdisったりする。HTTPにdisを持っていれば、いままさしくそれを検討する段階なので、どんどん出していくべき。もっとIETFに持っていくなどしていく必要がある。日本人の貢献がもっとできるはず
次世代Webセッション後半〜アーキテクチャ編
- http://www.cross-party.com/programs/?p=138
- http://www.ustream.tv/recorded/28599028
- 司会 Jackさん(@Jxck_) 以下J
- 和田卓人さん(@t_wada) 以下wada
- 山本陽平(@yohei) 以下yohei
- 佐々木庸平(@yssk22) 以下yssk
- 江島健太郎(@kenn) 以下kenn
Websockets
- J: LingrはWSにはならないのか
- kenn: ぶっちゃけよくわからない。互換性が失われる分があるので、サービスとしては採用にふみ切れない。ancientなCOMETを使っている。メリットは永続的なconnection。チャットはアイドリングの時間が長くてTCP接続のコストは高くない。生きたconnectionを使いまくるようなアプリでWSが生きてくるのだろう
- J: 結局COMETでよかったんじゃね?という話
- yssk: メリットが見えない。インフラ屋としてはconnection使い回すというのと、違うアプリが同じLBに入っている場合にどうやってLBのキャパを確保するのかが難しい。アプリがセッションを持ったまま永続してしまうと、バックエンドでサーバー再起動できなくなって困る。バックエンドが同じサーバーで動いていることを前提とされるとつらい
- J: HTTPはステートレスであることが良さだが、それが失われるとどうなります?
- J: statelessだったHTTPの上で信じるに値するRESTだったと思うが、そうもいかなくなってきた今、何をよりどころにすればいいでしょう
- wada: これまでのWeb、実はこうなっていたという説明がようやくストンと落ちたところだと思う。Webがドキュメントをやり取りする世界から、ストックのwebとフローのwebに分断された。twitterは過去が見られなくなったとか
- J: 自由なwebが失われた、みたいなブログがあったけどどう思いました?
- yohei: そのとおりだと思った。テクノラティーあったねーどこ行ったとか。ストックとフローの問題だと、世の中はフローに行ってるから、ゆり戻しがそのうち来るんじゃないかと思っている。タイムラインで流れていく情報をストックで扱う技術とか出てくるんじゃないか
- J: 文書をどう取ってくるかという点をよりどころに技術が進んできたと思う。バイナリになったり、始まりはあるが終わりのないストリームになったりということじゃないかと思うのだが
- yohei: 「インターネットになったな」と思う。ちょっと前はwebをインターネットと呼ぶな、とえらい人が言ってたりしていた。いまやweb==インターネットで、いかにその上でインターネットやるかというのでストリームになっていったんだろう。TCPの上にHTTP乗せてその上でTCPやるのがWSだったりする
- yssk: ゲームのようなHTTPベースじゃなかったものがHTTPでできるんじゃね、というのが今の流れ。WSはTCPの再実装じゃね、とは思っていて、少し懐疑的に見ている
- J: TCPに回帰していくと?
- yssk: そうではない。プロキシないと仕事にならない。HTTPの上にSOAPって言ってたけど、あれ?ということがあったよね
- yohei: HTTPをtransfer protocolとして考えないでsemantics考えろってのがRESTだと思う。結局みんなRPCやりたいんですよね
- kenn: textかバイナリかというのがハテ、と思うところで、テキストの扱いやすさがいい。圧縮してバイナリというのはどうかあと思う
Realtime
- J: 人がボトルネックになるというとそんなにリアルタイム求められてるのかな、と思う
- J: おととしくらいにWSのはしりが話題になってきて、キラーアプリが出るかと思ったけど、結局出てきたのってゲームとチャットだけだった。メッセージングが必要なキラーアプリ感がない。アプリとなると必要とされてないのか
- kenn: いいカンジに次世代webをdisる回になってきましたねw。エンジニアはすぐに効果が得られないものは採用しないと思う。にわとりとたまごではぜったいにたまご(新技術)が先。そこは悲観的には考えていない。時間の問題で出てくると思う。
- J: WSという仕様自体が求められて実装が進んでいて、それを使って何をするかは置いてけぼりになっている
- kenn: low latencyでリアルタイムというのは長く言われている割にようやく今だ!となってきた。時間がかかりますね。
歴史はくり返す
- J: 長い間見ているとよせては返すみたいな話がよくあると思うけど、それをふまえて、今よせているものはどこへ返っていくのか興味がある
- yohei: 今まで死んだスペックってすごくたくさんある。xsltとかw。仕様作っている人達はスペック先行で行っちゃう、楽しいし。しかしそれでうまくいかない。HTTPとかHTML5はうまくいってる? バランス取りながら進められるのがいい。いまだとIETFに行って合議制になった瞬間に終わるんじゃないかみたいな。IETFで仕様が出るよりgoogleでSPDYが234といくようなのがいいんじゃないか
- wada: 技術の歴史が螺旋状になっているよって話をよくする。テキスト/バイナリとか。前の周期を見ると、シンプルなものが生き残ってるのがわかる。やんなきゃいけないルールが多いものが死ぬ。SOAPとか。大きなものは自重で死んでいく。分散・集中だけでなく、自分の言葉をしゃべれるものが使いたいのかどうか。RPCやりたいというのは自分の語彙で話したいということ。なんで動詞が4つしかないんですかってPATCHもあるけど。自分のサーバーなんだし。他人の語彙を話すとなると急にやりたくなくなる
- LISPはマクロで言語を作るための言語だった。その結果みんなオレオレLISPを作ってしまってLISPの人同士で話ができなくなった。
- J: SOAPからRESTに行ったのもできることも少なかったが、覚えるルールが少ない分、よかったってこと?
- wada: ルールが少なければ納得できる。リンクを張ると使えるというおそるべきシンプルさ
TLSは前提?
- J: webはTLSを前提にしていいのかという話がある。プロトコル視点からは都合がいいのだが、web的視点からはどう考えたらいい?
- yohei: ビジネスではTLS前提が大歓迎でそうなるべきと思うが、個人としては受け入れ難い。web=internetと言っているが、internetのあり方としてどっかの会社から証明書を買ってこないと使えないというのは許せない。ハッカーとして自由でオープンなinternetが残ってほしい。テキスト/バイナリはどっちでもいいかな
- kenn: HTTPは実のところバイナリプロトコル。性能とかレイテンシというとTLSは明らかに落ちる。光の速度は越えられないw。それがどこに効いてくるかというとRTT。ハンドシェイクで一往復増えるというのはdrawback。CPUも食うし。フロントエンドnginxの負荷ってスケールさせにくい。オレオレプロトコルならAESかなんかにしてバックエンドでほどくなどやりようがいろいろある。それをフロントのTLSに限定するのはどうなのか。あとSSLも完璧ではなくて、ゲームを作っているとクライアントが信用できない場合もある。ローカルのプロキシで点数を書き換えるチーターもいるので、SSLだからと言って役に立つわけではない。役に立たないものに払うコストとしては見合わない
- yssk: webというモノが何かを考える。SSLにしてレイテンシがありますとかね。CDNが効いていて、遠くてもstatelessなら誰かが取ったcacheが効く、ということをbreakしてまでRPC指向でやる必要があるかというのは疑問。RPCは使いようがあるとしても、web全体でどうかというと、それだけではない
break the web
- J: 検索できるのはドキュメントがテキストベースでURLが固定だからというのが前提になっている。いまあるcacheの仕組みが使えなくなるとどうなんだ。break the webと言われますが、そのwebってどうなんだと思いますか
- yohei: 合わないものはこわせばいいと思う。cacheに代わる技術を作ればいい
- J: こわすだけのメリットがbreakした後のwebにあるのか
- kenn: 例えばスマホはwebなのかどうか
- yohei: あれは、むしろネットですよね
- yssk: 従来のロボット型検索エンジンは、Y!の登録型がうまく回らないところから出てきた。今後pubsubが広まっていくと、webの検索に登録するためにpubする、そのためにリアルタイム使うってのはあるんじゃないかな
- J: 登録型に戻る! そこへ行きますか
- kenn: pushは一発。一方pullは空振りがある。pubsubモデルになるとムダがなくなるよね
- yssk: cloud foundryが使いにくい、herokuが使いやすいのはgithubにpushするという操作があるから
- J: 出していただかないとgoogleに入らないよ、publishしてね、なんかの流れになるんですかね。facebookみたいにデータを囲い込んでる人達が検索するような、そんな世界ですか?
RESTに代わるパラダイム
- J: リアルタイムなwebを作りたい、でも従来型のrailsのwebを共存させようとしたとき、クライアント側にはajaxなど変わる必要があった。サーバー側APIはあまり変わっていなかったと思うが、今後WSでpushします、URLベースでないAPIが出てくると、RESTだけわかっていれば困らなかった時代は終わったんではないでしょうか。何をよりどころに生きていったらいいでしょう?
- wada: 道自体は自然発生的にできると思ってる。リアルタイムwebでは、アーキテクチャでは上に乗ってるのはnodeが引っぱっている。herokuはthinでeventmachineが動いているから、リアルタイムはできる。たくさん出てきているライブラリの中からどれがのびてくるか、思考のバッファにおさまるものが勝つのではないか。覚えることが少ない方が勝つ。プログラマの頭に入る量は決まっていて、そこにおさまり切るかどうかで生産性が決まってくる。nodeのasyncを使わないと非同期プログラミングできない。callback hellを見ると、あれはframeworkではあるけど環境ではない。あれを減らすためにasyncが出てきた。そんな風に、上に次が出てきて、大多数が暮らす主戦場ができると思う
- J: パラダイムシフトなのか、エコシステムがまだできていないということか。DOMで言うjQueryのようなものの登録が必要?
- wada: jQueryって言語内言語。一段抽象度の高い言語クエリー言語なんですよ。そこへ来てはじめてやりたいことの記述量が十分小さくなった。覚えられたのがjQueryの良さ。多くの人が「ああこれなら行けるわ」と思ったところがキーになるだろう
- J: 去年流行ったmeteor, socket streamみたいなものの流れだと思うがキラーなものはまだない。WSでやろうとしていることはネイティブアプリでやってたことが近くなる、XMPPでやってたのと同じじゃんみたいな話がある。swing、xmppのノウハウをいまこっちに持ってくることはできないのか?
- kenn: これから勉強する人は難しいことに押しつぶされそうな世界なので、オレオレでいいから作ってみることが大事じゃないかと思う。古い世代の人ほど新しいものが昔のモノに見えるので、逆に若い人ほど新しく作ったつもりが昔の物に似ている、と思えるんじゃないか。やりたいこととしてぜったいゆずれない部分を守るためにオレオレやればいいんじゃないかな
- yssk: 標準にのっかってWSやるなどは動機としてあると思う。うまく乗っかれればうまくいく。自分は乗れると思ってないんだけど。WSうまくいかなかったときに「ほーらね」って言えるw
- J: ysskさんのやりたいことがいまのweb技術で足りてるということ?
- yssk: APIとの接続として、zeromq, rabbitmqでやるかWSでやるかという選択だとは思う。やってみる価値はある。firewallをbreakできるチャンス?
Layer7のさらに上
- J: generalな世界でやるには課題も多いし、まだWSというには早いんじゃという時期だと思う、でも進んでるからやってみたい、この先どう進んでいくんですかね
- kenn: computerって放っとくとインフラは進んでいく。変わらないのは人間。一日に集中できる時間も決まっている。その中で開発をするなら楽をしたい。ソフトウエアの進化。下を改善するより上を良くするほうがいいと思う。TCPを作り直そうという人はあまりいない。UDPの上でreliableやったりはしないではないけど、HTTPってgood enoughだと思う。その上に何かを乗せ込んでいく。HTTPの上にfacebook、その上にアプリのようにどんどん上に行くし、それが人間の抽象度に合っていると思う。人間が瞬時に判断できる帯域は7bitという説があるんですよ
- J: 収束できるレイヤは4とか7ではなくその上にあるという話?
- wada: 人間のspecだけが変わらない。そこを直視する。何かのフレームワークが一瞬で頭に入るかどうか、と考えると、直観に頼るというのはいい指標ではないか。railsって結局、やることを減らしたからプレイヤーが増えた。何が流行るか流行らないかは、一瞬で制約に気づけるかにかかっている。足り算は流行らない。何かと何かを足すのではなく、何かができないかわりに何かができますという風になる。その「できないこと」を瞬時に理解できるか、判断できるかということだろう。その判断ができればみんながやりたいことに近づいていける
- wada: やりたいことがある、でもやりたい人の脳は変わらない。じゃあ何かができなくなる。同じかより高い抽象でプレイヤーがそろうところにアンテナを張っておくべき
- J: 抽象化の行き先って単純なRPCを定義できるかというところになるんですかね? 抽象化の先ってどこに向かうと思います?
- J: 今本当に何が起こっているかを出そろわせて、じゃあ次の一歩で自分が何ができるかってことを話すのは難しいと思う。自分で考えられるような人間を呼んできて聞く、というこの場はよかったと思う
- J: 自分で考えたこれからのwebについてブログに書くまでがこのセッションということで
感想
考える材料をたくさんもらったセッションでした。自分のものにするには時間がかかりそうです。
Jackさんの話の振り方は本当に上手でしたね。名司会だったと思います。
追加
セッション終了後、@yoheiさんからこんな提言がありました
