株式会社ユーザベースの技術チームブログです。OpenTweetはじめまして。(ryoqun)です。Open)」という最新技術についてTCP/IPのおさらいを踏まえながら紹介したいと思います。ちなみに、この技術はTCPを高速化するもので、Google、Facebook、Appleなどでも本番投入され初めているものの、まだ国内では浸透していなくだいぶ先取りな紹介となります。Openという技術は比較的枯れたTCPに対してプロトコルレベルで変更を加える比較的インパクトが大きいと勝手に思っている技術です。最新動向を掴むと共に、TCP/IPの良い復習ということで少しの間ですがお付き合い下さい。Openとは?一言でいうとTCPのレイテンシーを改善する新しい拡張技術です。Openという名前の由来となっています)。RTT分のレイテンシーを削減できます。Openに対応して初めて有効になります。注意点としては、僅かに接続確立時の信頼性が犠牲となることです。これについては後述します。各ホストへの初回接続時には使えません。理由は、セキュリティのため認証情報(Cookie)が必要になるためです。flooding攻撃に似た危険性を軽減する対策余地をプロトコル上に残すためです。handshakeが必要になります。接続確立時に実際の通信ができるまでに、まずクライアント側からSYNフラグが立ったペイロードが無い小さいパケットを送り、サーバー側からSYN+ACKフラグが立ったペイロードが無い小さいパケットを受け取らなければなりません。RTT分のレイテンシーに相当するわけです。Openが有効な場合、接続確立時にいきなりSYNフラグを立てた上で、ペイロードを乗せることができます。RTTでnginxなどのHTTPサーバーはリクエストの内容をアプリケーションプロセスに渡すことが実現可能です。現在だとHTTPというよりかはHTTPS(=TLS)が主流です。handshakeを即座に開始できるというわけです。1.3を組み合わせるとTLSを含めて0-RTTを実現できるようになるようです。デモ百聞は一見にしかずということで、まずは実際の動きを見てみましょう。Openが有効になっているブラウザでファイルをChromiumでダウンロードしてみました。toolsのNetworkのtimingとWiresharkで状態を確認してみました。Openの効果がわかりやすくなるようにWikimediaを選んでいます。Openが無効と有効になっている時の違いを比べてみました。Open有効時は必要なくなっていて、SSLのhandshakeが前倒しになって開始されているのがよくわかります。SSLのhandshakeにかかった時間や実際のデータの転送にかかった時間はそれほど変わっていません。connection分の時間(レイテンシー)だけが綺麗に全体のレスポンス時間から減っています。Openが無効と有効になっている時の違いを比べてみました。handshakeをちゃんとやっています。handshakeの最初のパケット)があるパケットを送っているのがわかります。結果、パケットのLengthが大きくなっています。このスクリーンショットからはわからないのですが、この最初のパケットにはSYNフラッグがきちんと立っています。その後のやり取りの流れは無効時と変わりありません。Openを有効にすることによって犠牲にされた信頼性となります。この懸念を考慮する必要はインターネットから到達可能なWebサービスにおいてはほとんどありません。Open抜きにしても必ず考慮する必要があるからです。Openを有効にする場合には懸念となります。Openを有効にした際の信頼性の問題というのは、1つのTCP上のアプリケーションリクエストがIP通信網の品質の問題により、2つになりえるという理論的な問題となります。そのためアプリケーション層において、リクエストが2つになっても問題無いという冪等性が必要になります。その問題の原因を説明する前にまずは、前提となる背景を説明します。TCPの役割というのは、信頼性が担保されないIP通信上に、信頼できる双方向通信路を実現するためのプロトコルです。handshakeはその信頼性の担保のために接続確立時に必要となります。handshakeを必要としています。重視し、ごく稀なパケットロスやパケット重複は許容しています。handshakeが省かれ、パケット重複が万が一発生した場合、サーバーにとってはあたかもTCP接続確立が2つ来たかのように見えるので、2回リクエスト処理をしてしまうということになるわけです。Openはクライアント側とサーバー側がどちらも対応して初めて使えるようになります。Openを実装し、それが有効になっている事と、ミドルウェアやアプリケーションが対応している事が必要になります。クライアント側とサーバー側に分けて、2017年9月時点での普及状況について説明します。Facebookで有効になっているようです。Openはどちらかというと一般的なWebサービスでは効果が出にくく、CDNや広告配信等の1ショットのHTTPリクエストのトラフィックが大量に発生する場合に効果的です。日本サイトは筆者が簡単に確認する範囲では見つけられませんでした。クライアントWebブラウザはそれぞれ対応が始まっています。16.04/LTSのChromiumで動作確認をしています。OS的にも、iOS、Android、Windowsでそれぞれ動きがあるようです。ツール/ミドルウェアちらほらとサポートが始まっています。網羅的に調べたわけではありませんが、netty、Ruby、curlなどで対応情報を見つけることができます。Openの理解を多角的に深めていきたいと思います。Openとの相性が良くない場合があります。handshakeが省かれれば十分に正しくトラッキングできなくなる場合はあります。keep-aliveも同じ立ち位置です。keep-aliveによってだいぶレイテンシーは改善されます。Openというのはそれほど如実に効果があるわけではありません。keep-aliveはモバイル回線網にてあまり機能していないという指摘もあります。APIのエンドポイントアプリがkeep-aliveしていないならば効果はあります。keep-aliveを対応したほうがいいのは言うまでもありません。ラストワンマイル回線網(FTTHと4G)宅地のラストワンマイル回線網というと今で言えば日本国内で言えば、FTTHが圧倒的なシェアになっています。Openの効果はほとんどありません。ADSLならば多少は効果はあります。ラストワンマイルが何にしろ、海外ホストへのアクセスの場合には効果が望めます。モバイルのラストワンマイル回線網というと今で言えば4G回線が全盛となっています。こちらの場合は国内ホスト、海外ホストに限らず一定のレイテンシー向上が望めます。Openの際に使われるCookieの転用例としては、Supercookieが挙げられます。セキュリティ上、DOS攻撃対策としてCookieが必要なわけですが、別のセキュリティ観点では、匿名性が犠牲となっています。E-tag、HSTS同様、passiveでドメインをまたいだ(=クロスドメイン)トラッキングが実現できてしまいます。Openがトラッキング手段として加わったわけですが、他の既存の代替手段も存在するのも含め、残念ながらトラッキングを現在において完全に抑制することは非常に困難となっています。Openは意味があります。QUICに対してはこちらはUDPベースなので関係なくなります。TLSと絡めながらの言及まとめレイテンシーが速くなります。handshake)が地味に変わるかもしれません。deploymentを実現するこんにちは、SPEEDAのSREチームの阿南です。Kubernetesのネットワーク...こんにちは。SPEEDA開発チームの鈴木です。これまでマルチホス...2014-12-26SPEEDAに導入して分かった、CDNの劇的な効果インフラチームの金屋です。»プロフィール『経済情報で、世界を変える』をミッションに、企業・業界情報プラットフォーム「SPEEDA」やソーシャル経済ニュース「NewsPicks」、ABMを強力にサポートする「FORCAS」、スタートアップの情報収集を圧倒的効率化「entrepedia」などを提供する株式会社ユーザベースの技術チームブログです。多国通貨」をハンズオンしたら快適で楽しかったGo言語でオブジェクト指向プログラミングの基本(型編)月別アーカイブ検索@Uzabase_Techさんのツイートスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。