Christopher Rogers、Namil Kim「lineもspdyサポート（その１）」
NAVER Engineers' Blog 2013.1.11のエントリ
Adopting SPDY in Line – Part 1: An Overview « NAVER Engineers' Blog
lineがspdyサポートしたよ、というシリーズものエントリ第１弾
場合によっては非sslでもspdy使ってるよ、とか、tlsのNPNは使わないことにしたとか、概要的内容
以下斜め読んだ内容
- 自分らはux向上頑張ってる。現在進行形
- line＝コミュニケーションツールだとすると。。。
- メッセージ送受信時間を短縮できれば、ux改善、と言える
- これまでの送受信はずっとhttp
- httpは普及してる技術
- シンプルなrequest/responseモデル
- tcpコネクションの上で送受信するモデル
- httpの欠点
- リアルタイム通信向けに設計されてないhttp
- メッセージングサービスにhttpが不向きな理由あれこれ
- リクエスト多重化がない
- FIFO無視したレスポンス受信がない
- 新規メッセージ受信のために問合せを都度やる
- リクエスト増えればバッテリー使う
- これまでlong polling多用してきたline
- long pollingは専用にtcpコネクションが必要
- req/res頻度増えれば、httpヘッダの送受信のサイズは肥大化
- 冗長なhttpヘッダを同じコネクション使って何度も送ってる
- user-agentは変わらないのに
- 他にいいのないか調べた
- http/long-pollingの問題を解決するもの
- spdyは求めてたものに近かった
- spdy使うことにした
- 車輪の再発明はしなかった。これはメリット
- spdyが廃れなければ、spdyとspdy関連技術からもたくさんメリットを受け取り続けれる
- spdyおさらい
- 新しいブラウザのためのプロトコル
- googleが開発
- http2.0に取り込まれることが意図されてる
- lineが恩恵受けるspdyの機能
- リクエスト多重化
- fifo無視したレスポンス受け取り
- ヘッダ圧縮。辞書使って圧縮効率アップ
- ping使ってコネクションが生きてるか確認できる機能もあり
- lineでのspdyの使い方は色々
- 暗号化オフでspdy使う時もある
- tls+spdyで行くときもある
- NPNは使わないことにした。理由は２つ
- １つは、ブラウザなら得られるメリットがlineの場合なかった
- ブラウザからはホスト先がspdyサポートしてるからわからない
- NPM使うとコネクション確立で発生するラウンドトリップの総数を減らせるメリットあり
- lineの場合はクライアントはspdyサポートの有無をチェックする必要なし
- NPN使った利用できるプロトコルのチェックはlineには不要
- もう２はアプリのアップグレードが必要な点
-
- NPN使うならアプリのOpenSSLのアップグレードが必要
-
- ポートスキャンもspdyと一緒にサポートした
- 広く使われるポートでもブロックしてるネットワークがある
- 世界中のキャリアでどのポートが使えるかをサーベイした結果、使えるポートの候補はごくわずかだった
- 一応フォールバックとしてhttpでポート80番での接続もサポートしてる
- lineの自作のapiゲートウェイサーバ
- 自分らはLEGYと読んでる
- Line Event-delivery GatewaY
- legyはerlangで書いた
- LEGYがspdyをサポートしてる
- 2012.10.16からspdyをサポート開始
- 導入後に出た問題
- 一定時間超えるとLEGYのメモリ使用量が跳ね上がる現象
- ヘッダ圧縮に使う辞書のサイズと辞書の状態が原因だった
- コード最適化して解決済
- たまーに、クライアントへ送るデータが一部ロスする現象
- 特定ネットワークでのみ起こってて、間にあったプロキシが邪魔してたことが分かった
- このネットワークのポートは使わないことにした
- それ以外は問題出てない
- 一定時間超えるとLEGYのメモリ使用量が跳ね上がる現象
- lineでのspdyサポートはうまく行ってる
- 必要コネクション数を減らせた
- メッセージ送受信の高速化
- 変化し続けるネットワーク環境への適応をこれからも進める
- その２では、spdyサポートの詳細を書く
