コミケ告知

サークル活動の詳細は circle タグの記事へ。
2014年12月31日水曜日

C87 お疲れ様でした

サークル浜風もっこす の2014年は終了しました。
西館まで足を運んでくださった皆様、ありがとうございました。

既刊の1+2の方が13:40頃に在庫切れてしまいました。新刊と比べるとあまり出ないだろうという予測でしたが、意外と初めて来てくださる方がたくさんいて、思ったより数が出ました。ありがたいことですが、その後にゆっくり来てくださった方には申し訳ありませんでした。新刊はたくさん刷ったので、無事最後まで持ちました。

Network Maniacsというタイトルなのに、Vol.3は1や2に比べたらライトな感じにしました。どのくらいの本が受けるかよくわからなかったので試行錯誤の途中でありますが、ちょっとライトにしすぎたかなーというのが反省&何度かいただいたご意見でした。次以降の参考にさせていただきます。

また、ご意見ご感想は常にお待ちしております。奥付にあるメールアドレスか、あるいはTwitterの方へ。監視頻度の都合、Twitterに飛ばしていただけると助かります。

当初出そうとしていた艦これ本は、普通に攻略本っぽいものがコピー本で20p超えたところまで作った挙句に、どうもいまいちまとまらなくて没にしてしまいました。分量も増えるし、前回のオフセ本に書いたような確率論的なものと合わせて、オフセ本で形にしたいですね。どこか艦これオンリーを狙いたいところ。

Vol.3のURL

新刊(vol.3)内に記載したURLは以下のひとつだけでしたので、独立記事にせずここに書いてしまいます。
netem: http://www.linuxfoundation.org/collaborate/workgroups/networking/netem

余談

サークルスペースで話していて、BSDの黒悪魔本なるものをお勧めされました。業務でLinuxかつカーネルまでは手を入れない範囲で頑張る都合、Linux以外のネットワークスタックの知識はさっぱりでしたが、mbufのメモリ管理にはskbよりすごいところが色々あるとのこと。
興味を持ったものの、どうもぐぐるとすごい値段がついているようで困っています。どなたか貸していただけないでしょうか…。あるいは、勉強会(もくもく会等)の集まりで、その場で借りてその場で読んで帰りに返す感じでも。
2014年12月23日火曜日

Cygwin環境下でElixirを使うときのバッドノウハウ

Windows上でCygwinを使いつつ、Windows用にインストールされたコマンドラインアプリケーションを使うと、ヒストリーを辿る動作が上手く動作しないことがあります。↑を押したらカーソル位置が上に移動してしまうなど。各種言語のREPLやDBの管理ツールで起こります。そんなときにはrlwrapを使うと、安直にまともな挙動を得ることができます。
rlwrap -A iex.bat

ここで今rlwrapを紹介したいわけではなくて、rlwrapを使ったときのバッドノウハウ。
elixirはwindows用の実行ファイル(iex.bat)を用意してくれますが、こいつをrlwrapで包むと、なぜか上手くCtrl+Cが伝わらなくて、erl.exeがゾンビの如く残ってしまいます。

対処は、 :erlang.halt で終了すること。

若干面倒ではありますが、そう頻繁に終了起動を繰り返すようなものではないので、実用的に問題ない範囲内かなと。
2014年12月21日日曜日

C87予定

◎貴サークル「浜風もっこす」は、火曜日 西地区“く”ブロック-23a に配置されました。

新刊

今回の出版物、まずNetwork Maniacs vol.3が出ます。内容を振り返ると、今回ManiacsではなくてBasicsにした方が良かったかも…。
  • TCP受信プログラミング
  • 「ネットワーク向けコマンドラインツール紹介
  • 2014年のネットワーク時事ネタ少々
 といった内容でございます。これは入稿したので、確実に出ます。結構刷りましたといいつつ部数を読み違えて早く売り切れてしまったことが過去ありましたが、今回コミケ2回分でも余るくらい刷ったので、ゆっくり来ても余裕です。(次回抽選落ちるフラグではなかろうか)


艦これの攻略本は、コピー本で小冊子を予定しています。
「社会人提督による、最低限の攻略基本+これからのイベントに向けた攻略指針」といった感じです。

既刊

Network Maniacs vol.1+2 を少し増刷しました。

  • 【TCPの高速化手法】 基本的な話からLinux3系の新実装まで、TCPの高速化に使われている方法の解説。
  • 【ネットワークバッファとパケットロス】 パケットロスとは何で、ネットワークバッファとはなにか?
  • 【QUIC】 Googleの実験用プロトコルQUICの概要と試用方法。
  • 【FiddlerCore】 .NET用のHTTP層解析ライブラリの紹介、使用例。
こちらも引き続きよろしくお願いします。
2014年12月18日木曜日

QUICの技術要素分解

この投稿はHTTP2 Advent Calendar 2014の18日目の記事です。
前日は HTTP2におけるProxyに関する議論 でした。


(あらすじ・前略)
もっこすにはHTTPがわからぬ。もっこすは、ただのゲーマーである。ヴァナディールで市場価格操作に命を懸け、艦娘と遊んで暮らしてきた。けれどもトランスポート層のプロトコルについては、人一倍に敏感であった。

QUIC

HTTP2とは直接関係ないので、念のため概要を説明してから進みます。HTTP2勉強会 #http2studyシリーズに参加されている方だと、もうご存知の方が多そうな気はしますが、とりあえず。

QUICとは、Googleが開発しChromiumに実装中のトランスポート層、すなわちTCPと同じ層のプロトコルです。Internet上で運用される独自実装トランスポートの常として、UDPで包んだ中に独自実装が入っています。

QUICの主目的は、1にも2にも接続開始時の遅延削減です。Design Documentをはじめ各所には、QUICによるメリットがいくつも箇条書きされていますが、最初の遅延削減だけは飛びぬけてプライオリティが高いです。せっかくの新プロトコルなので、改良できそうな点はたくさんありますが、Webを扱うGoogleとしてのプライオリティは明確に「ページを早く表示する」ことに置かれているのです。IETFでの発表資料(PDF注意)でも、太字になっていますよね?

最低限の概要説明はここまで。以後、QUICで使われている技術要素から、面白そうなものを紹介していきます。

マルチストリーミング

QUICでは、ひとつの接続(Connection)の上に、複数の論理的接続(Stream)が走ります。


  • Streamに優先度をつけたり
  • Stream毎に違う挙動にしたり
  • 再送制御をStream毎に独立して行ったり
と色々な柔軟性が生まれます。一番インパクトが大きいのは最後のもので、例えばStream #1でパケットが落ちても、他のStreamに悪影響を及ぼしません。TCPだと仕様上そういうことは出来なくて、パケットが1個落ちたら、同じ接続上の後続パケットは全部影響を受けます。いわゆるHoLブロッキングというもの。その一個が再送されるまで、後ろのデータは一切アプリケーションに渡されません。つらぽよ。

このマルチストリーミングは、SCTPというプロトコルでかなり前から用いられています。SCTPについての説明は、古いですがIBM Developer worksのものをどうぞ。"2000年10月にRFCになった比較的新しいプロトコルです"なんて書いてありますね…。

既にあるならば、それを使えば良いではないですか! 実際WebRTCのデータ転送では、DTLS(UDP+セキュリティ)の上にSCTPが走っています。このレイヤーを弄っているギークなら、QUICを見て最初に思う事は「なんでDTLS+SCTPじゃダメなの?」であって、Design DocumentにもQUIC FAQ for Geeksにも理由の説明があります。本件の説明はこの後で少しずつ。


0-RTT connection

古き良きTCPで接続すると3-way ハンドシェイクによる接続が始まり、上にセキュリティレイヤーがあればそのレイヤーでも情報が行ったり来たりして、ようやく通信が始まります。これはたまらん。特に、RTTの長い場合に、ページが表示され始めるまでの時間がやたら長くなってしまいます。

TCPには、既にTCP Fast Openという技があります。乱暴に説明するならば、一番最初のパケットにリクエスト内容も載せてしまえるもの。Linuxカーネルには年単位で昔に入っていますが、クライアント側での普及率はまだかなり低いのではないかと思われます。BSDソケットAPIのconnect()にはデータを載せられないので、TCPなのにconnect()ではなくてsendto()で接続しに行くんですけど、どれくらいの方が使用経験ありますかね?


(左が普通のTCP、右がTFOが上手くいったときの図)

TFOのI-D見ると、しっかりGoogleの名前が入っています。Googleの資料に "Deploy in today's internet"と書いてある部分は、TCPにコントリビュートしても、浸透に何年かかるんだよ!という怒りが込められているのかもしれません。もちろん、QUICでは同様の技が実装されます。


QUICで遅延関係でもう一つ進んだところは、トランスポート層と、その上のセキュリティ関係の層(のハンドシェイク)をまとめて済ませようとしているところです。仮想化・レイヤー構造ってものは、柔軟に差し替えられるように存在するものであって、TLSを他に差し替える必要がないのであれば必要ない…という判断は理解できます。これが、DTLSでハンドシェイクして、SCTPでハンドシェイクして、と何度も往復しなければならない DTLS+SCTPとの違いになります。(他にTLS層でいくつかメリットがあるけども割愛)

WebRTCの選択が悪いわけではありません。あれはコネクション張りっぱなしで色々するものなので、Googleのシナリオとは接続遅延の重要性が全く違います。そこの性能向上が要らないわけではないので、いずれQUICが成熟したら、置き換えの可能性はあるでしょうが…

ペーシング

ペーシングは、パケット送信間隔を均してバースト転送を避けることで、経路上のバッファ溢れによるパケットロスを減らす仕組みです。これを他人に説明するときには、いつも産総研のPSPacerのページに丸投げしています。良い説明です。新しい技術ではありませんが、QUICの送信制御に入るようです。

FEC (エラー訂正)

QUICには、パケットレベルのエラー訂正の仕組みが実装されています。仕組みは単純で、パケットN個のグループあたり1個のエラー訂正パケット(他のパケットのXOR)を追加で送ることにより、そのグループ内でパケットロスが1個ならば訂正し、再送を抑えることが出来る、というもの。(RAID5を思い浮かべましょう)
追加で余計な情報を送るので、再送遅延の節約と、余計な帯域消費とのトレードオフです。


ハンドオーバー

QUICはコネクションに対して64bitのユニークな値を付与し、これをIDとします。既存のInternetトランスポート層では基本的に、IDとなるのは {アドレス, ポート番号} でした。もちろん、アプリケーションレイヤーまで行けばちゃんとユーザーIDなどがありますが…。

IDがアドレスから切り離されることにより、仮にIPアドレスやポート番号が変化したとしても、それをトランスポート層で吸収して隠蔽することができます。接続が切れたからとハンドシェイクをやり直す必要がなくなり、すなわち次にWebページ等を表示したときの遅延が解消されます。モバイル環境で端末が大きく移動したとき、回線を3GからWiFiアクセスポイントに繋ぎかえたときに利点が得られるであろうことは、想像が付きますね。既存技術では、機能の観点からはmobile IPに相当するでしょうか?

QUICの場合、このID仕様が生きる場面はもう一つあり、それはNAT(NAPT)のポートマッピング変更です。UDPはコネクションの概念がないので、既存のmiddleboxはタイムアウトとかLRUとかを用いて、NAPTのマッピングを消したり変えたりします。同じように通信しているつもりが、いつのまにかさっきとユーザー側のポート番号が違う、という恐ろしいことが起こります。そこでこのID仕様が役に立つ…というより無いと困ってしまうわけです。

ついでにNAPTの話をもう少し


NAPT問題は、QUICの実用に向けて、一番難しい課題かもしれません。NAPTエントリが消滅したら、装置の内側から一発飛ばさないと穴が開きません。サーバーからの通信は、タイミングが悪いと落ちてしまいます。定期的に穴あけをしたいですが、keepaliveであまり帯域を食うのも微妙だし、モバイル端末ならバッテリーの問題もあります。つまらない話ですが、TCPへのフォールバックは必ず用意する必要がある、のかもしれません。

keepaliveの間隔はGoogle側で話題になっているし、NAPTのタイムアウト時間設定はISP側で悩ましい問題になりそうです。IPv6ならば、NAPTかまさず出てこられるかもしれないので、ここでv6への機運がなぜか高まる、というシナリオに進んだら面白いと思います。(あまりなさそうと思いつつ書いている)

近況

QUICはその実験的性格から、公開まで時間がかかるのではないかと心配していましたが、意外と早い時期に手の届くところに来るかもしれません。つい最近のQUIC Prototype Protocol Discussion groupの投稿によると…
we're hoping to engage other developers and get real server implementations (apache, nginx etc.) in 2015. 
nginxやapacheに載ってしまえば、あとは設定を変えれば動いてしまうわけで、2015年は良い意味でHTTP激動の年になってくれるかもしれません。HTTP/2のみならず、です。楽しみにしましょう!

この記事では、QUICで実装されている高速化技術を、できるだけ既存の対応する技術と関連させつつ紹介しました。セキュリティ関係は、若干地味な上に背景を説明するのに分量が必要なので、かなり割愛しています。興味のある方は、Design Documentに説明があったはずなので、そちらをどうぞ。


…ああ、思いつき3秒で書いたあらすじの伏線が投げっぱなしで回収されていない。どうしよう。困った。

万歳!Google様万歳!


---
この投稿はHTTP2 Advent Calendar 2014の18日目の記事でした。
後日、ここに翌日へのリンクが入ります。