QUIC
Googleで開発されたが、いまはIETFがメンテをしている うれしさ
はやい
https://gyazo.com/95f5c7e411d0b7f96d182abe284be551
IETF QUICはTLS1.3 + HTTPより早い
We've found that IETF QUIC significantly outperforms HTTP over TLS 1.3 over TCP. In particular, Google search latency decreases by over 2%. YouTube rebuffer time decreased by over 9%, while client throughput increased by over 3% on desktop and over 7% on mobile.
暗号化による硬直性の解消
しくみ
QUIC is a new transport which reduces latency compared to that of TCP. On the surface, QUIC is very similar to TCP+TLS+HTTP/2 implemented on UDP. Because TCP is implemented in operating system kernels, and middlebox firmware, making significant changes to TCP is next to impossible. However, since QUIC is built on top of UDP, it suffers from no such limitations.
https://gyazo.com/92834bb86804b4ea4530a1b261192996
Quick UDP Internet Connections
UDP上にサーバクライアント間で多重化したコネクションセットをサポート QUIC による通信で利用されるQUICパケットの設計を紐解くことで、IPアドレスとポート番号に依存しないコネクションの単位である「コネクションID」、転送するアプリケーションデータの順番とは独立した「パケット番号」、ヘッドラインブロッキングの影響軽減のための「ストリーム」、将来にわたる高い拡張性のための「バージョン」や「可変長フィールド」など、QUIC で導入された新しい概念の背景について西田氏に説明いただいた。
トランスポート層の新しいプロトコル
TCPに変わりうるもの
実績
ネット上のトラフィックの10%以上はすでにQUIC（Googleがやっているため）
インターネットのトラフィックの内7%がQUICだと推定される
2017年の論文
帯域が太くて距離があるものはあまり活用されない
昔のTCPは急激にあげないように速度は徐々にしか上がらない
パケロスがあると速度を下げる
ルータがTCPを解析していろいろやっているのがつらい
パケットが捨てられたりする
QUICはすべて暗号化して対策している
rui.icon 当初入っていたforward error correctionがdropしたのが残念
ロスがわかっていれば、予め余分なデータを送る冗長化をしていた
1個だけ増やすならXORすればいい
実際には遅くなってしまった
GoogleはIETF版に移行するらしい