Hatena::ブログ(Diary)

mad-pの日記 Twitter

2013-01-19

CROSS 2013レポート(2)

CROSS 2013レポートパート2です。次世代Webセッションのメモ。

間違いや発言意図と違う表現だ、などということがあると思います。ご指摘いただければ幸いです。

次世代Webセッション前半〜プロトコル

HTTP2
  • 2012/11最初のドラフト。絶賛議論中
  • どんなところが問題?
  • kazubu: 前回のIETFの続きのトピック。crimeアタックに関して圧縮回り見直しとか
  • jovi: SPDYはSSLの上でやってるから気にしてくていいという話だった。crimeの衝撃。chromeは3ではdisableにした(クライアント側からの圧縮率を下げる)
    • kazubu: 対応: 圧縮のコンテキストを分ける。headerとbodyとか。最近は圧縮方式を変える。
      • crimeはhuffman木の再構成によって発生する。huffman木を変える方法が考えられている
      • googleは前回と同じ物が来たときにだけフラグをつける。クッキーだけわかればいいという発想
  • HTTP2が出てきたときにどうupgradeするか
    • DNSをよごすなと言いたい
    • SPDY: NPNを使う以上はTLSにならざるを得ない
    • HTTP2になったときにTLS前提でいいのか
      • koma: fallbackどうすんのという話と、それを仕様にするといつから使えるのかって
SPDY
  • jovi: LINEの特徴
    • SPDYなのにNPNを使っていない → 直接SPDY決めうち。TLSにはなっている
    • 443を使っていない → 9413 gitポートだった。いま見たら5000番だった。いくつかスキャンして決めてる?
    • SPDYをオレオレプロトコルでやるのはなかなかいいね
    • J: サービスとクライアントを両方手にしている人だけができる方法
  • koma: スマートフォンにはプライベートアドレスが払い出されてる
  • マルチプレクシング
    • SPDYでできちゃうのでWebsocktsでやらなくてもいいんじゃね的な
    • per frame compression
  • レスポンスを上げる → テキスト→バイナリ → 圧縮 → などとなっている
  • J: SPDY: bandwidthよりRTTが重要という流れだと思うんですけど
    • jovi: googleが必要で作ったもの。2011年の1月にはGoogleサービスの90%がSPDY
      • googleはa/bテストで実験をくり返している。かなりノウハウを持ってるんだろう
      • J: → それって本当にgoogleしか持っていないですよねー
      • jovi: 他にはtwitterwordpressくらいしかない。twitterも本当苦労していて、operaが出るたびに見れないなどということがある
  • J:デバッグ大変ですよね!? → jovi:大変です!!
    • HTTPのときはheaderのparseができればという話だったけど、SPDYのparserは個人でできる範囲をこえてしまった
  • J: prioritizationというのがある。HTMLの世界でやっていたドキュメント読み込み順をSPDYに持ってきたときにどうなるかを考える必要がある
  • 「ハイパフォーマンスWebサイト」は書き直さなきゃね!
  • SPDY4ってどんなカンジなの?
    • jovi: 8月くらいに最初のドラフトというかたたき台が出た。脆弱性のない圧縮方法を使おう。サーバーpush拡張しよう。
      • いまできてるのはサーバー証明書push, dns情報を送ってしまう, プロキシの情報(このプロキシ使ってほしい)など
      • コンテンツ入手に必要な情報をサーバーからあらかじめpush
    • koma: もはやhypertext transferのプロトコルじゃないよね
      • jo: たしかにサーバーとクライアントの間でやりたいことはできている。
      • J: これはHTTP2に持っていけるものではなくgoogleのオレオレプロトコルとなっているだろう
  • koma: layer violationがはげしくなってきて、階層どおりになっていない
SPDYとHTTP2とTLS
  • J: SPDYは速くしようということでHTTP2はHTTPのアップグレードだから、本来違う目的のもの
  • J: 注目するとしたらspeed and mobility?
  • J: HTTP2はTLSを前提としない、と明記されているが現実的なのか
    • kazubu: TLSを前提としないべきだとは思う
    • J: upgradeするとなれば、いつまでもHTTP/1からは脱却できないのか
    • kazubu: well-known portを他にすればいいとかwww
      • J: → 新しいプロトコルを出すならスキームを変える、というのはあるべき姿じゃないの?
      • kazubu: だけどリンクがたどれなくなっちゃう
      • koma: migrationの難しさを考えるとスキームを変えるのは現実的じゃない
  • jovi: WebsocketsはIETFに出すんじゃなかったという反省がある。HTTP2も数年はかかるだろう。その間にSPDYは5678とどんどん進んでいくんじゃないか
    • 規格作ったんだけど使われなくなっちゃうなんてことがあり得るんじゃないかな
Websockets
  • J: WebsocketsはHTTP→HTTP2に横からささってきた感じですが、これからはどうですか?
    • koma: IE10でもWebsocketsがサポートされて、非常にいい実装になっている
      • WSがこのまま世の中に普及するかというのは難しい。明日世の中のIEが全部10になるとかであれば使われるんでしょうが。IE678がいつなくなるかという話で、じゃあやっぱりsocket.ioでHTTPポーリング、ってなるでしょ。ああ、socket.ioは使われますよきっと
  • J: ブラウザ以外のWSのカベは?
    • koma: nat, firewall, proxy, いわゆるintermediariesが問題。キャッシュは関係ないかな
      • ある程度以上のレベルのサイトではそのへんが対応できないと保たない
      • LBで対応しないからamazonでダメとかnginxでサポートないからherokuで使えないとか
  • J: WSが切られちゃう件ってどうなんでしょ
    • まあ、わけわかんない接続が残ってるの切るのは正しい対応なんでしょうけども
    • 2本つないでみて試し、wsが使えるならupgradeしようみたいなのが出ているんですが、そのへんが難しい
  • kazubu: IETFでも話題になっている。LBが作りにくい。SPDYでもpriorityをさばくのはLBなのにコンテンツはWebサーバーにあるというギャップがある
  • J: WSもSPDYも接続を保持しないといけないからバランスしにくいのでは?
    • koma: いままででもクッキーでセッションを考える必要はあった。data by data, frame by frameでLBしようとするとキツイという面はある
    • jovi: chromegoogle 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はどうしても必要だし
      • jovi: Androidで知らない間に3-wayじゃないの使ってたりという世の中にすでになっている
      • koma: GoogleAndroidというOSを押さえたのはそういう意味でも面白い。でもNAT配下で使えなかったりと制約はあるよね。ipv6を待たないといけないんじゃ
v6
  • J: v6はどうなの?
    • kazubu: 流行るといいですねーwww
      • FBもgoogleも対応しているけど、v6で生活するというのは難しいよね
Webのこれから、どこに向かっていくのか
  • kazubu: 効率化が進むけど、問題も引き起こすのでバランスが重要
  • komasshu: ホームネットワークのTV・家電とクラウドの関わりが気になる。クラウドはSPDY,WSなどが進んでいくと思うが、ホームネットはHTTP以外のプロトコルでもガンガン動いている。シームレスにdevice - browser - serviceというトータルで考えないといけないと思う
  • jovi: 過去から来ていたのはリアルタイム性、RTT。マルチプレクスがもうできた。本当の本当のリアルタイムはこれから先は劇的に伸びるものはもうない。これから先、どんな新しいパラダイムが出てくるかを見ていかないといけない。光はまだまだ遅いw
  • Jxck_: みんなこういう話をするとすぐHTTPをdisったりする。HTTPにdisを持っていれば、いままさしくそれを検討する段階なので、どんどん出していくべき。もっとIETFに持っていくなどしていく必要がある。日本人の貢献がもっとできるはず
感想

正直、話がディープでついていくのが大変でした。SPDYのデコードはWireshark用のプラグインとかありますね。ユーザー側のネットワーク機器なども関わるとなると、SPDYやWSをカンタンに導入というところまではまだ来ていないのかと思いました。

次世代Webセッション後半〜アーキテクチャ

Websockets
  • J: LingrはWSにはならないのか
  • kenn: ぶっちゃけよくわからない。互換性が失われる分があるので、サービスとしては採用にふみ切れない。ancientなCOMETを使っている。メリットは永続的なconnection。チャットはアイドリングの時間が長くてTCP接続のコストは高くない。生きたconnectionを使いまくるようなアプリでWSが生きてくるのだろう
    • J: 置きかえコストは?
    • kenn: RubyのEventMachineは対応しているので、内部的なAPIのはりかえだけで動くだろう
  • J: 結局COMETでよかったんじゃね?という話
    • yssk: メリットが見えない。インフラ屋としてはconnection使い回すというのと、違うアプリが同じLBに入っている場合にどうやってLBのキャパを確保するのかが難しい。アプリがセッションを持ったまま永続してしまうと、バックエンドでサーバー再起動できなくなって困る。バックエンドが同じサーバーで動いていることを前提とされるとつらい
  • J: HTTPはステートレスであることが良さだが、それが失われるとどうなります?
    • yohei: RESTのマーケティングが成功しすぎたと思ってて、やりすぎ感がある。REST追求しすぎると大変だし、googleみたいに違う世界を作っちゃうみたいな方向に行きがち。もう少し頭を冷やしましょう。この先は端末ハード〜クラウドまで全部押さえているメーカーが一番強い時代が来る。そういうところが面白いはず
  • 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かバイナリかというのがハテ、と思うところで、テキストの扱いやすさがいい。圧縮してバイナリというのはどうかあと思う
JSON
    • J: JSONに対してmessagepack, protocolbufferと比べるとJSONがいい?
    • kenn: JSONはコンパクトで可変長。msgpkはprefixされたヘッダがある分、JSONの方が小さかったり速かったりする。JSON→yajil→ojなどライブラリも速くなってる。使われるから速くなるというのがあるだろうが
  • J: JSONでデータをたくわえる夢のデータベースcouchdbというのがあったと思うけど、どう?
    • yssk: なかなか難しい。ドキュメントベースのworkflowにはよかったと思う。しかしnosqlの流行と混同された結果mongoの方が速いよと言われたりしたのが残念。メインの開発者がいなくなったり
    • J: 分散したときにHTTPでやりとりするからレプリケーションが楽とかあったと思うが、そのセンでポーリングをWSにするとかはないんですかね
    • yssk: long pollingによるnotificationの仕組みもあった。しかし競合があったとき直せるのは人間しかいないので、人がボトルネックになってしまう
Realtime
  • J: 人がボトルネックになるというとそんなにリアルタイム求められてるのかな、と思う
    • wada: 示唆的な話。WSレベルのRTTって人間は求めていないのではと思う。lingrにしてもcometで十分とか。人はWSレベルのリアルタイム性があるってわかってしまうと息苦しくなってしまうと思う。ツイッターが流行ったのはゆるい同期、非同期だから。プログラマが電話が苦手wなのはリアルタイムだから。人間は苦手だけど、機械がリアルタイムに話をするという場面では有用だと思う。本当の本当のリアルタイムは人間以外のモノが使うのではないか
  • 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を定義できるかというところになるんですかね? 抽象化の先ってどこに向かうと思います?
    • yohei: 覚えるだけではダメ。教科書的なものは覚えるとしても、いくら覚えても新しいもの、作りたいものは生み出せないわけです。覚えるよりは自分の頭で考える方をやろうよ、と思います。それが一番楽しい。仕様を覚えるよりは何か作る方が楽しい
    • yssk: 個人的にはwebが今後どうなるかで言うと、google, facebookなどplatformerと呼ばれる人を中心に回るだろう。全部はムリなのでどこに乗るかということだろう
  • J: 今本当に何が起こっているかを出そろわせて、じゃあ次の一歩で自分が何ができるかってことを話すのは難しいと思う。自分で考えられるような人間を呼んできて聞く、というこの場はよかったと思う
  • J: 自分で考えたこれからのwebについてブログに書くまでがこのセッションということで
感想

考える材料をたくさんもらったセッションでした。自分のものにするには時間がかかりそうです。

Jackさんの話の振り方は本当に上手でしたね。名司会だったと思います。

追加

セッション終了後、@yoheiさんからこんな提言がありました

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証

Connection: close