気になったところ、追いついたところだけ記載します。（自分用）
間違い、認識違い等あると思いますが、メモなのでまさかり投げないでください...
「それ、AMPで作りませんか？」--- RichでResponsiveかつ**PWA**なAMPの作り方
- AMPコンポーネント増えてきた
- before afterの画像で amp-imageつかえるんじゃないかな
- ビルド直後、ペイント後みたいな
- コンポーネント集ある
- レスポンシブ
- 一休.comのサイト
- Serviceworker使えるしPWA化できるよ
- AMP用のボイラープレートもある
- デメリット
- url問題。google.com/amp/hogehoge.com
- singed exchange ドキュメントに署名＆署名元のドメイン表示で作り直します
- オリジントライアルから全てのサイトに拡大した模様
- https://www.suzukikenichi.com/blog/google-testing-demo-search-for-signed-http-exchanges/
HTTPの今と未来 HTTPの基礎から5G試験ネットワークの評価まで
5Gの話
HTTP and 5G fixed1
https://www.slideshare.net/dynamis/httpp-and-5g-fixed1
- HTTP over QUIC → HTTP/3
- 世界初の実装はLitespeedとFacebook
- HTTP/3が、2019/RFC/TBD
HTTP/1.1の問題
HTTPヘッドオブラインブロッキング（HOLブロッキング）
- 待ち行列の先頭が詰まると以後全部待たされる。
- TCP接続1本あたり1ファイルずつ順次送信
- 表示に関係ない大きなファイルが先にくるとページ描画が遅れる→いわゆるレンダリングが遅くなるいつもの話のやつ
- 同時に6接続行うことで緩和してきたが限度がある
- ハンドシェイクに必要なRTT数（TLS1.2の問題）
- 並列リクエスト数の制限、優先度制御がない など
HTTP/2でHOLブロッキング解消したがTCP接続が1本になり
TCPヘッドオブラインブロッキングの影響を受ける
とは言えサーバー側でのプライオリティ制御、サーバープッシュ等可能になった
TCP高速化のひとつとしての
輻輳（ふくそう）制御アルゴリズム→BBR（Bottleneck Bandwidth and Round-trip propagation time）
今まではパケロス検出で制御していたがネットワーク最適化ポイントではない → RTTの時間変動を観測し最適化する新しい輻輳制御
QUICとは
HTTP/TLS over TCPをUDP上で再実装することで既存の問題を解消するために作られたプロトコル
→HTTP/2でのTCP HOLブロッキングを解消
- HTTP/2ではTCPパケロスで全てのストリームがブロックされる（再送まで通信とまる）
- QUICではUDPパケロス時も該当ストリームだけブロック（他ストリームでは継続される）
HTTP/3 （HTTP over QUIC）
- HTTP/2 + TCPでの課題、制限を解消
- TCP HOLブロッキングがなくなる
- LTE、5G、Wifiの切り替えで通信中にIPアドレスが変わっても接続セッション維持可能 （通信状態の切り替わるときによくあるアレ）
等々
- 無線環境は普通にパケロスするので、BBRと相性が悪い。RTTがナチュラルで変動する。
- 有線LAN、無線LAN、5G、それぞれパケロス時の低レイヤーの挙動が全く違う。
- 5Gのエラーでパケロスと誤認識されることがある（TCP的にはRTTが伸びただけのように見えるのかも？）
- 無線レイヤでの再送がTCP/QUICの輻輳制御に干渉している問題
BBRよりCUBICの方が高速だった
なぜか？→輻輳の検出がうまくできてない、5Gとの相性が悪い？再送でHOLブロッキングが頻繁に起きる
無線域の再送でパケロスするとHOLブロッキングで速度低下する
5Gでの試験でHTTP/2のほうが遅いケースもある。
輻輳制御はCUBICよりBBRが遅い傾向
特にHTTP/2でTCP1セッション時のときに。
HTTP/1
無線では単一ファイルより複数ファイルアクセスのmovie、imgのほうが高速
HTTP/1、HTTP/2、5Gそれぞれのプロトコルや輻輳制御別で
有線、無線の平均速度で特徴が出てきた。
5Gの帯域が使い切れていない問題ありそう
まだ未解決部分もあるので5Gに関してはまだこれから
「ネットワーク技術の変化を知らないWeb開発者ヤバイ」
みたいですよ。
参考
https://www.school.ctc-g.co.jp/columns/nakai2/nakai222.html
https://asnokaze.hatenablog.com/entry/2018/10/31/020215
https://tech.nikkeibp.co.jp/it/atcl/idg/14/481542/082500407/?ST=cm-network&P=1