自己紹介
- 政倉 智 (まさくら とも)
- codeArts 株式会社
- 趣味: バイクとか、プログラミングとか
- html5j 鹿児島
- 運用屋さんではありません!
ちょっとだけ
本日 SSL! SSL と連呼しますが
厳密な意味での SSL ではなく、TLS を含んだ俗称として SSL と呼びます
アジェンダ
- SSL おさらい
- HTML5 から見た HTTPSの必要性
- HTTPS のオーバーヘッド
SSL おさらい
SSL の目的
以下の三つを防止する
- 盗聴
- 改ざん
- なりすまし
テストに出るよ!
盗聴
中身を盗み見る
改ざん
都合のいいように内容を書き換える
なりすまし
消防の方から来ましたー
SSL の機能
- 通信の暗号化
- データの完全性チェック
- 接続先の認証
- 三つそろってはじめて安全
HTML5 からみた HTTPS
- HTML5 でウェブはアプリのプラットフォームとして進化
- 年々、安全に対する重要度が増している
2016/04 Chrome 50 から Geolocation API が非 HTTPS では使えなくなった
https://dynamis.github.io/webapi.link/ をもとに HTTPS 必須をマーク (漏れはあるかも...)
HTML5 を生かしたければ HTTPS は必須
HTTPS のオーバーヘッド
結論から先に
- HTTP -> HTTPS でスループットが 1/100 まで落ちた (悪条件下)
- HTTPS のコネクションの開始処理が重たい
- サーバーの性能次第でレスポンスは悪化する
テスト環境
| サーバー | クライアント | |
|---|---|---|
| マシン | Raspberry PI 3B | HP ML115 G5 |
| CPU | ARMv8 2 Core (*) | Phenom II 4 Core |
| Mem | 1GB | 16GB |
| OS | Raspbian | Ubuntu 16.04 LTS |
- Raspberry PI 3B は CPU に負荷をかけると温度が上がりすぎて停止するので、起動オプションで 2 Core に制限しました
HTTP (サーバー)
- 60 秒間で 100,000 クライアントからアクセス
- CPU 負荷は 50% 以下なのでまだ余裕ある
- 帯域 100Base-TX で使い切っちゃみたい
- 途中でエラーが多発しているのはちょっとわかんない
HTTPS (サーバー)
- F5 アタックをする人を少しずつ増やしていく感じ
- CPU がさばけてる間は 500 リクエスト/秒以上は出る
- さばききれなくなると 10 リクエスト/秒まで落ちる
HTTPS (サーバー) その二
- 60 秒間で 600 クライアントからアクセス
- CPU を 100% 使い切っているのでちょうど限界
HTTPS (サーバー) その三
- 60 秒間で 600 クライアントから各 2 アクセス (SSL 接続はクライアントにつき一回だけ)
- さっきの倍処理できている
結論 (サーバー)
- HTTP -> HTTPS でも、CPU が十分に速ければスループットはさほど変わらない
- CPU が不足すると、最悪の条件では 1/100 くらいまで落ちる
- SSL の開始処理がとてつもなく重たい...
HTTP (ブラウザー)
ブラウザーの高速化の工夫
- サーバーへのアクセスは最大 6 本同時に行う
- Keep Alive で TCP 接続を使いまわす
- (橙) - TCP 接続の開始に 0.70ms
- (緑) - リクエスト
- (緑) - 待機 (コンテンツのダウンロードが開始されるまでの無通信)
- (青) - コンテンツのダウンロード
HTTPS (ブラウザー)
- HTTP の時とあまり変わらない
- TCP + SSL 接続の開始に 269.87ms
- SSL 部分だけは 269.31ms
- 体感で分かるレベルでレスポンスが悪化する
- 重たい接続を同時に 6 本も開始するなんて、サーバーに厳しすぎます
HTTP/2.0 + SSL
- 接続は一本だけ
- その一本を多重化して使う
- (HTML 以外は) 同時にリクエストして同時にダウンロードしてる
サーバーにやさしい! (たぶん)
読み込み時間 (ブラウザー側)
- HTTP/2.0 + SSL は HTTP に近い性能が出ている (三回目以降は)
- TTL が悪ければもっと差が開くと思う
参考資料など
- HTTP/2.0 は多重化だけじゃないよ!
- サーバープッシュ (コンテンツの押し付け)
- ヘッダー圧縮
- 詳しくはさくらのナレッジ を見てね!
おまけ
- HTTP/2.0 は Google の開発した SPDY が元
- Google さんくらいになると...
- 常時 SSL でものすごいコストがかかるんじゃないかな...
- プロトコルの改良で節約できたコストもすごそう...
- 私の仕事のレベルだと、HTTP -> HTTPS の負荷は問題にならないレベル
- SNS とか、サイトへの常駐率が高いところは負荷が問題になるはず
- Pixiv さんは常時 SSL のためにハードウェアを更新してます
- 常時 SSL 化の前に、CPU 使用率とロードアベレージは確認しておこう
- サーバー側のチューニングという方法もある (今回未検証)
- サーバーの増強よりクラウドの SSL 付 L7 ロードバランサーおすすめ
- さくらのクラウドも SSL 対応してほしいなあ...
移行の前に WEB+DB Press を読もう!
まとめ
- SSL は盗聴・改ざん・なりすましをふせぐ
- HTML5 API は HTTPS 必須が多いので、HTTPS 化は必然
- HTTPS 化の負荷はそこそこあるよ
- 可能であれば HTTP/2.0 化しよう!
- めんどくさい人はクラウドの L7 ロードバランサーがおすすめ
告知
かごもく #7 UE4/Cocos2d-x/Unity 勉強会
- 4/28 (土) 13:00 - 17:00 (予定)
- 最初に、各プラットフォームの紹介があります
- 残りの時間はもくもく (チュートリアルとかいろいろ)
- 途中参加、途中退出、OK! 予定が付く時間だけどうぞ!
- 未経験者が中心で開催します (Cocos2d-x だけすごい人が来る予定)
近いうちにイベント公開します!
https://kagoben.connpass.com/