渋川の記事の補足というか、実装者目線からみた話を書きます。
立ち位置
仕様策定には関わっていません。あくまで出てきた仕様を実装する実装者（Implementor) です。
また HTTP/3 や QUIC がメインというよりかは WebRTC がメインです。WebRTC が利用しているプロトコルが QUIC に置き換わる流れがきているため、QUIC を実装しており、さらに QUIC を利用したプロトコルとして、まずは HTTP/3 が採用されていることから、HTTP/3 に手を付けている状況です。
現時点では Chrome Canary M74 で利用可能な RTCQuicTransport が自分の戦場です。
QUIC の使いみち
QUIC ですが現段階ではまだ仕様策定中です。ドラフトが上がる度に仕様が変わっています。追従するだけで一苦労でしょう。
また QUIC を実装したとしてもすぐに活用するのはとても難しいでしょう。QUIC 自体が HTTP/3 をターゲットとしているため、HTTP/3 に必要な仕様しか Version 1 では提供されません。
QUIC は UDP ベースで、暗号部分に TLS 1.3 の一部を利用するというかなり特殊な実装になっています。はっきり言って理解するためのコストが高すぎます。
HTTP/3 簡単な説明
HTTP/3 は QUIC を通信経路として利用します。ヘッダーは HTTP/2 の HPACK ではなく QPACK を利用します。QPACK はできるだけ HoL Blocking をへらすための仕組みです。
そもそも TCP で提供されていた HTTP/2 から HoL Blocking を徹底的にへらすというのが最大の目的なのが HTTP/3 です。
HTTP/1.1 や HTTP/2 が HTTP/3 の登場でなくなるわけではない
HTTP/3 の登場で将来的にすべて HTTP/3 へ行くというわけではありません。これが一番の誤解を生んでいるような気がします。
HTTP/1.1 や HTTP/2 はそれぞれ適材適所で使われていきますし、残ります。さらに HTTP/3 も適材適所です。そもそも HTTP/3 は UDP ポートが塞がれていたら使えないのを忘れないでください。
HTTP/3 は必要な分野があるから出てきただけです。使い道がわからないのであれば無理に追いかける必要はありません。これは QUIC も同様です。
ではどうすべきか
日本語で読めるこの詳解 HTTP/3 がとても優秀です。curl の作者が書かれたもので、とてもわかり易いです。
これを読んでふーんってなるのがおすすめです。HTTP/3 が重要になったら HTTP/3 を作ってる人たちが騒いでくれますのでその時からで大丈夫です。QUIC は普通の人が触れるプロトコルではないので、名前と特徴だけ覚えておけば十分です。
蛇足
そもそも QUIC や HTTP/3 って一部の特定事業者以外は稼げるプロトコルではないと思います。この技術をやったとしても旨味がすごくありません。
実際自分も WebRTC で採用されなかったらやっていませんでしたし、採用される気配がなかった間は関わりもしませんでした。
採用される気配が 2018 年の 9 月くらいから出てきたので関わるようにして、2019 年の 1 月に Chrome が RTCQuicTransport を実装してきて、あーきたかー、ってなってるレベルです。
