#!/usr/bin/env python
# coding: utf-8

# # このスライドへのアクセス方法
# 
# 1. 「nbviewer.jupyter.org」というサイトへアクセス
# 2. 「mrsekut」で検索
# 3. 「slides > HTTP2.ipynb」
# 4. 右上のプレゼントマークでスライドっぽく表示
# 5. スペースキーで順番に移動
# 
# [リンク](http://nbviewer.jupyter.org/format/slides/github/mrsekut/slides/blob/master/HTTP2.ipynb#/)
# 

# # HTTP/2.0について
# 
# tryangle株式会社  
# 丸末皓太

# # 自己紹介
# 
# ### 丸末皓太
# - 大阪府立大学 数学課(いちおうたぶん2回生)
# - 休学中
# - 府大生向けの「Opulency」というアプリを作った
# - 現在はtryangle社でばりばりアプリ開発してる卍卍
#     - 主にフロントエンド
# - 最近興味あること
#     - Typescript: ReactNative
#     - Haskell: 関数型プログラミング
#     - Go: ネットワーク, プログラミング言語そのもの
#     - Rust: OSなどの低レイヤ
#     - テスト  
# 
# 

# - 大学に入ってから本格的にプログラミングを始めた
# - 1回生でprogateなどでhtml,cssとか、普通にvimとか触った
# - 2回生になって機械学習の勉強を始めたり、reactでopulencyというアプリを作り始めた
# - opulencyは今年の4月にリリースして2週間で500人くらいにいれてもらったが、リリースした瞬間にモチベが切れ、終わった

# ![mrsekut](https://github.com/mrsekut/myStorage/blob/master/img/mrsekut_circle.png?raw=true)
# 
# ### SNS
# - blog: [mrsekutの備忘録 (http://mrsekut.site/)](http://mrsekut.site/)
# - twitter: [@mrsekut](https://twitter.com/mrsekut)
# - github: [mrsekut](https://github.com/mrsekut)

# # 発表のながれ
# 
# 1. 発表の動機と目的  (0.2m)
# 1. 従来のHTTP  (3m)
# 1. HTTP/2の概要  (15m)
# 1. 比較のデモページ  (1m)
# 

# # なんでHTTP/2について調べてみたか
# 
# - ネットワーク全然しらないなーってなった
# - これまでの勉強会で「webを支える技術」などを参考に勉強
# - 「Real World HTTP」という本を買ってもらった

# # 発表の目的
# 
# - 浅く広く紹介します
# - キーワードを拾っていってもらえばと思います

# # 従来のHTTP
# 

# ## 概要
# 
# - 通信プロトコル
#     - ステートレス性
# - リクエストとレスポンス
# - RFCという提案書
#     - IETFという団体が管理
# - HTTP/0.9 (1991~)
#     - GETしかない
# - HTTP/1.0 (1995~)
# - HTTP/1.1 (1997~)
# 

# - 0.9, 1.0, 1.1とバージョンが上がり、今の最新は2.0
# - たとえばhttp/1.1はRFC2068として初版が発表

# ## HTTP1.1の課題
# 
# - リクエストの多重化
#     - ページが大きくなり必要なリソースが増えた
#     - 1RTTで1リクエスト/1レスポンスしかできない
# - パイプライン化
#     - 同時に複数のリクエストを送れるようになった
#     - しかし、同じ順序でレスポンスしないといけない
#     - HoL(Head of Line)ブロッキング問題
#     - ![wikiから引用](https://upload.wikimedia.org/wikipedia/commons/thumb/1/19/HTTP_pipelining2.svg/640px-HTTP_pipelining2.svg.png)
#     - 画像引用元: [HTTPパイプライン - Wikipedia](https://ja.wikipedia.org/wiki/HTTP%E3%83%91%E3%82%A4%E3%83%97%E3%83%A9%E3%82%A4%E3%83%B3)
# 
# 

# - パイプライン化
#     - らうんどとりっぷでぃれいたいむ
#     - 前回のリクエストの完了を待たずに次のリクエストを送れるようになった
#     - 
#     - 一つ処理に時間がかかるものがあると、後続のレスポンスは全てブロックされる
#     - これをHoLブロッキング問題と呼ぶ

# # HTTP/2の概要

# ## 誕生の背景
# 
# - アクセスの増加
# - 2015年2月17日発表
#     - HTTP/1.1から16年ぶりの改訂
# - GoogleのSPDYから生まれた
# - 当初のプロジェクトの目標はページ読み込み時間の50%減

# - LTEなどの普及によりエンドユーザーの通信速度は上昇したが、サーバー側のページロードの速度はそれに比例せず1.6Mbpsほどで頭打ちしていた
# - 2009年からgoogleが独自にweb高速化の取り組みの一環からSPDYというプロトコルを作っていた
#     - Twitter,Facebookでも使われるようになった
#     - HTTP/2はこのSPDYを改良したもの

# ## HTTP/2の特徴
# 
# - ヘッダの圧縮
# - リクエストの多重化
# - リクエストの優先度制御
# - サーバープッシュ
# - バイナリプロトコル
# - フロー制御

# ### ヘッダの圧縮

# #### 一言で言うと...  
# → いろんな方法でリクエストやレスポンスのヘッダを圧縮する

# ### ヘッダの圧縮
# 
# 
# - ヘッダー圧縮
#     - 従来の圧縮に加え、ヘッダ部分の圧縮ができる
#     - 静的テーブル、動的テーブル
#         - 使用頻度の高いヘッダ、一度送信したヘッダなどに番号を振り、次からそれを使う
#     - HPACK
#         - 動的に辞書を更新し、2回目移行はインデックスを用いる
#         - 文字列をHuffman Encodingによって圧縮
#             - 高頻度で用いられる文字を少ないビット数で表現する
#             - バイナリ形式
#             - [超わかりやすい解説記事](https://qiita.com/iwanaga/items/98f60003c0114e04095e)
#             - [超詳しい解説記事](http://syucream.github.io/hpack-spec-ja/rfc7541-ja.html)
#             - [アルゴリズムの解説記事](http://www.techiedelight.com/huffman-coding/)
#         - 差分のみを送信する
#     - [わかりやすいヘッダの解説記事](https://qiita.com/0xfffffff7/items/39b944e3845ab3776b63)

# #### こんなアルゴリズム

# 
# 
# ![](https://i0.wp.com/www.techiedelight.com/wp-content/uploads/2016/11/Huffman-Coding-1.png?zoom=2&resize=395%2C85&ssl=1)
# 
# 

# ![](https://i2.wp.com/www.techiedelight.com/wp-content/uploads/2016/11/Huffman-Coding-3.png?zoom=2&resize=412%2C189&ssl=1)
# 
# 

# ![](https://i1.wp.com/www.techiedelight.com/wp-content/uploads/2016/11/Huffman-Coding-4.png?zoom=2&resize=354%2C231&ssl=1)
# 
# 

# ![haffman encoding](https://i2.wp.com/www.techiedelight.com/wp-content/uploads/2016/11/Huffman-Coding-6.png?zoom=2&resize=404%2C392&ssl=1)
# 
# - 画像引用元: [Huffman Coding Compression Algorithm - Techie Delight](http://www.techiedelight.com/huffman-coding/)

# - HTTP/1.1のヘッダは大きい
#     - リクエストは最低でも300Byte程度
#     - Cookieなどで更に増える
#     
# - HTTP/1.1ではbodyをエンコードするのにgzipでサイズを圧縮する機構がある
#     - CRIMEという攻撃手法に備えるためヘッダの圧縮には使えない
# 
# - 膨大なHTTPリクエスト/レスポンスのログのヘッダの文字の出現頻度を集計し、ハフマンツリーを作成
# - 高頻度で使われる文字列とは母音とか
#     - たとえばaとかが普通にすると8bit必要だったけど、例えば01みたいな2bitで耐える
#     - 「\(バックスラッシュ)」とかあまり使われない文字は19bitとか必要になり、逆に増える
# 
# - この「ヘッダ圧縮」だけ取り上げて深めてみても面白そうなトピックだなと感じた
# 
# - ちなみに「hpack」で検索するとhaskellのツールがでてくるが　、コレは関係ない
#     - jsでいうpackage.json的なファイルからコンパイルしたりするファイルを作成するやつ
#     
#     
#     

# ### リクエストとレスポンスの多重化

# #### 一言で言うと...
# 
# → 1回でたくさんリクエストを送っても耐える
# 

# ### リクエストとレスポンスの多重化
# 
# - 1つの接続上にストリームという仮想的な双方向シーケンスを作り多重化
# - 同時に100以上のリクエストを送信可能
# - 並列に扱うことができる
#     - レスポンスの順序に制限なし
#     - HoLブロッキング問題を解決
# - データにはフレームという単位にわけられ、ストリーム上でやりとりされる
#     - 0-9の10種類がありIDが振られている
#     - クライアント側は奇数、サーバ側は偶数番号を割り当て、重複を防いでいる
#     - ストリームはサーバ側でもクライアント側でも開始可能
# 

# | Type | フレームの種類 |                          役割                          |
# |:----:|:--------------:|:------------------------------------------------------:|
# |   0  |      DATA      |        リクエスト／レスポンスのボディ部分に相当        |
# |   1  |     HEADERS    |        リクエスト／レスポンスのヘッダ部分に相当        |
# |   2  |    PRIORITY    | ストリームの優先順位を指定（クライアントのみ送信可能） |
# |   3  |   RST_STREAM   |   エラーなどの理由でストリームを終了するために用いる   |
# |   4  |     SETTING    |                   接続設定を変更する                   |
# |   5  |  PUSH_PROMISE  |    サーバプッシュを予告します（サーバのみ送信可能）    |
# |   6  |      PING      |                 接続の生存状態を調べる                 |
# |   7  |     GOAWAY     |      エラーなどの理由で接続を終了するために用いる      |
# |   8  |  WINDOW_UPDATE |               ウインドウサイズを変更する               |
# |   9  |  CONTINUATION  |    サイズの大きなHEADERS/PUSH_PROMISEフレームの断片    |

# - 「フレーム」というのはHTTP/2の通信の最小単位
#     - それぞれにフレームヘッダが含まれる

# ### リクエストの優先度制御

# #### 一言で言うと...
# 
# → リソースに優先順位を付けることでUXが向上

# ### リクエストの優先度制御
# 
# - クライアントがサーバーに優先順位ツリーを送信することで、レスポンス優先度を指定できる
# - 重み付け
#     - 割り当てるリソースの割合を比率でしている
#     - 1~256の整数の重みを割り当てる
#     - デフォルトは16
# - 依存関係
#     - 各ストリームは、別のストリームに対して明示的な依存関係を指定できる
#     - より依存されているものが優先的に送られる
# - 優先度を付けることでユーザ体感速度を大幅に向上させることができる
# - [わかりやすい参考記事](https://qiita.com/Jxck_/items/16a5a9e9983e9ea1129f)
# - [わかりやすい参考スライド](https://www.slideshare.net/kazuho/http-58452175)
# 
# 

# - ![重み付け](https://developers.google.com/web/fundamentals/performance/http2/images/stream_prioritization01.svg?hl=ja)
#  
#  - 画像引用元: [HTTP/2 の概要  |  Web  |  Google Developers](https://developers.google.com/web/fundamentals/performance/http2/?hl=ja)

# - 先ほど紹介した2番のPRIORITYフレームを用いる
# - 偶数であることからもわかるように、クライアント側で指定する
# - サーバー側はクライアントから来たこの優先度は別に無視することもできる
# 
# - 例えば、A,B,Cという画像かなにかがあって、これらに対して8,16,32のように重み付けをすると、
# - 1:2:3の割合でリソースが割り当てられることが期待される

# ## HTTP/2の特徴
# 
# - ヘッダの圧縮
# - リクエストの多重化
# - __リクエストの優先度制御__ ← マダココ
# - サーバープッシュ 
# - バイナリプロトコル
# - フロー制御

# ### サーバプッシュ
# 
# 

# #### 一言で言うと...
# 
# → サーバーが次にくるレスポンスを先読みしてリクエストを返す

# ### サーバープッシュ
# 
# - サーバーがクライアントの発行するリクエストを予測してレスポンスを返す
# - 0RTTにすることができる
# - [詳細でわかりやすい解説記事](http://labs.gree.jp/blog/2014/12/11987/)
# 
# 
# 
# 

# - 1RTT(ラウンドトリップディレイ・タイム)は1往復にかかる時間のこと
# - HTTP/2にしたところで1RTTかかっちゃうけど、どうにか0RTTにしたいよな的な発想
# - リソースの数が増えればそれで時間がかかる

# #### 例 "index.html"
# ```
# <!DOCTYPE html>
# <html lang="ja">
# <head>
#   <meta charset="UTF-8">
#   <title>マジ卍</title>
# </head>
# <body>
#   <h1>おはようございます!!!!!!!!</h1>
#   <img alt="超おもしろい画像" src="omosiro.png">
# </body>
# </html>
# ```

# #### 従来
# 
# 1. index.htmlくれとリクエストを送る
# 2. サーバーがindex.htmlを返す
# 3. クライアントが上からindex.htmlをパース
# 4. imgタグを見つけたら、再びomosiro.pngくれとリクエストを送る
# 5. サーバーがomosiro.pngを返す
# 
# 

# #### サーバプッシュ
# 1. index.htmlくれとリクエストを送る
# 2. サーバーがindex.htmlとomosiro.pngを返す
# 3. <font color="Red">クライアントはomosiro.pngをキャッシュにセット</font>
# 4. クライアントが上からindex.htmlをパース
# 5. <font color="Red">imgが必要なことを発見しキャッシュを見に行く</font>
# 6. キャッシュにあるのでリクエストせずに表示

# ### バイナリベース

# #### 一言で言うと...
# 
# → 機械語で通信

# ### バイナリベース
# 
# - テキストベースからバイナリベースへ
# - サーバがパースを簡単に行える
# -  転送データ量の低減
# - エラーや間違いを減らす
# - セキュリティ向上
#     - HTTP Response Splitting Attack
#     - レスポンス分割攻撃

# - 0と1
# - 間違い
#     - 空白、大文字小文字の区別、改行コードなど

# ### フロー制御

# #### 一言で言うと...
# 
# → 通信路の渋滞をなくす！

# ### フロー制御
# 
# - 巨大なリソースがストリームを専有して他のストリームがブロックしてしまうことを防ぐ
# - TCPでも実装されている
#     - HTTP/2ではストリーム毎にフロー制御
# - 仕組みの概要
#     - １回で送れる容量の上限を決めてそれ以上のものが来たら止める
#     - 必要になったら残りを送る
#     - [わかりやすい記事](https://qiita.com/Jxck_/items/622162ad8bcb69fa043d)

# - 低レイヤでも頑張っているが、アプリケーション層でも頑張る！

# # 比較のデモページ
# 
# - http://www.http2demo.io/
# - https://http2.akamai.com/demo
# - http://www.httpvshttps.com/
# 

# # 調べてみた感想
# 
# - HTTP/2新たに追加された機能がいっぱいあった
# - 一つ一つが勉強会の題材にできるくらい深めたら面白そうだった
# - もうちょい詳細にしてブログにまとめます

# # 参考文献
# 
# これまでのスライド中に書いていない参考にした書籍やリンク先
# 
# - [Real World HTTP]()
# - [HTTP/2 - Wikipedia](https://ja.wikipedia.org/wiki/HTTP/2)
# - [HTTP/2の特徴 HTTP/1.1との違いについて | REDBOX Labo](https://blog.redbox.ne.jp/http2-cdn.html)
# - [なぜ、我々はHTTP/2に対応する必要があるのか？ | SEO Japan – アイオイクスによる海外最新SEO情報ブログ](http://www.seojapan.com/blog/everyone-moving-http2)
# - [HTTPとサーバ技術の最新動向](https://www.slideshare.net/kazuho/http-58452175)
# - [HTTP/2 の概要  |  Web  |  Google Developers](https://developers.google.com/web/fundamentals/performance/http2/?hl=ja)

# # おまけ

# ## 普及率
#  
# - 日本では70%弱
# - [Mozillaのデータ](https://letsencrypt.org/stats/#percent-pageloads)
# - [Googleのデータ](https://transparencyreport.google.com/https/overview)
# - [広まった理由とか解説されているサイト](https://medium.com/anderswodenkender/%E6%97%A5%E6%9C%AC%E3%81%AEhttps%E5%B0%8E%E5%85%A5-%E6%99%AE%E5%8F%8A%E3%81%97%E3%81%A4%E3%81%A4%E3%82%82%E3%81%BE%E3%81%A0%E4%B8%8D%E5%8D%81%E5%88%86-380dd64d9603)

# ## 導入方法
# 
# - クライアント側は対応してるブラウザ使うだけ
# - サーバー側は必要なモジュールを入れる
#     - TLS1.2以上が必要なので証明書つくる
# - [導入する方法](http://dskst9.hatenablog.com/entry/2016/01/30/235019)