メインコンテンツへジャンプする

JPNICはインターネットの円滑な運営を支えるための組織です

ロゴ:JPNIC

WHOIS 検索 サイト内検索 WHOISとは? JPNIC WHOIS Gateway
WHOIS検索 サイト内検索
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
    __
    /P▲        ◆ JPNIC News & Views vol.1647【臨時号】2018.12.13 ◆
  _/NIC
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ News & Views vol.1647 です
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2018年11月上旬にタイ・バンコクで開催された第103回IETFミーティングのレ
ポートを、vol.1644より連載にてお届けしています。

連載第4弾となる本号では、従来の「HTTP over QUIC」から改称された
「HTTP/3」に関する議論の動向をご紹介します。

第5弾以降では、セキュリティ関連の動向と、DNS関連の動向をお届けする予
定です。これまでに発行した第103回IETFの報告については、下記のURLから
バックナンバーをご覧ください。

  □第103回IETF報告

    ○[第1弾] 全体会議報告 (vol.1644)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2018/vol1644.html

    ○[第2弾] SUITとIETF Hackathon ~IoT機器の安全なファームウェア更
              新から~全体会議報告 (vol.1645)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2018/vol1645.html

    ○[第3弾] セキュリティエリア関連報告 ~オペレーション関連技術の動向
              CACAO/SMART~ (vol.1646)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2018/vol1646.html

また明日12月14日(金)には、東京・神田のNATULUCK神田駅前 会議室にて本
IETF会合のオンサイトでの報告会を開催します。本号の執筆者である後藤氏
も登壇されますので、みなさまぜひご参加ください。

    IETF報告会(103rdバンコク)
    https://www.isoc.jp/wiki.cgi?page=IETF103Update

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ 第103回IETF報告 [第4弾]  トランスポートエリア関連報告
                             ~HTTP over QUICからHTTP/3への改称~
                                               グリー株式会社 後藤浩行
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2018年11月3日(土)から11月9日(金)にかけて、IETF 103が開催されました。
HTTPやQUIC関連の現在の標準化状況を振り返りながら、私が参加したWorking
Group (WG)で議論されたトピックについて紹介します。


■ QUICについて

そもそもQUICとは、現在IETFで標準化が進められている新しいトランスポー
トプロトコルです。UDPの上で、TCPのような信頼性があり、TLSのような暗号
化されたデータ通信を提供します。コアとなる仕様は、下記の四つの草案か
らなります(執筆時点では2018年10月24日に発行されたdraft番号16であり、
今回のIETF 103での議論結果に伴う変更は含まれていません)。

- QUIC: A UDP-Based Multiplexed and Secure Transport (*1)
- QUIC Loss Detection and Congestion Control (*2)
- Using Transport Layer Security (TLS) to Secure QUIC (*3)
- Hypertext Transfer Protocol (HTTP) over QUIC (*4)

これらの草案はお互いに歩調を合わせ、同じ草案バージョンを持つように作
業が進められています。

当初の予定からは遅れ気味になってはいますが、2019年7月にWGとしての作業
は大詰めを迎え、IESG (Internet Engineering Steering Group)に送られる
予定となっています。

(*1) https://tools.ietf.org/html/draft-ietf-quic-transport-16
(*2) https://tools.ietf.org/html/draft-ietf-quic-recovery-16
(*3) https://tools.ietf.org/html/draft-ietf-quic-tls-16
(*4) https://tools.ietf.org/html/draft-ietf-quic-http-16


■ HTTP over QUIC、そしてHTTP/3

今回のIETF 103では、現在標準化を進めているHTTP over QUICを、HTTP/3へ
と名称を変更するWGコンセンサスがなされました。その議論の背景と、当日
のWGコンセンサスまでの流れを紹介していきます。

○背景

この議論は、もともとメーリングリストでチェアのMark Nottingham氏が投稿
した「Identifying our deliverables (*5)」がもとになっています。そもそ
も、QUICというプロトコルはGoogle社が考案、実装、ディプロイをしていた
プロトコルであり、2016年にIETFでQUIC WGが結成され、正式にIETFで標準化
を進めることになりました。しかし、Google社の開発したQUICとIETFのQUIC
は、同じ技術をベースとしながらも現状では異なるものになってしまってお
り、それらを明示的に区別して前者をgQUIC、後者をiQUICと呼び分けていま
す。

今回の議論で特に大事な違いは、gQUICはアプリケーションプロトコルとして
HTTPを前提としており、アプリケーションも含めQUICと呼んでいましたが、
iQUICではQUICはトランスポートプロトコルであり、上位のアプリケーション
はHTTPに限定されません。また、HTTP over QUICのHTTP部分にもいくつかの
変更があり、HTTP/2 over QUICとは既に別のマッピングを持ちます。このよ
うに、QUICの名称に関する違いは、今後の利用者にとって混乱となるため、
HTTP over QUICに新しい名称を付けるという議論となりました。

HTTP/3と言うと、逆に混乱するという意見は実際に出ましたが、フォーマッ
トとセマンティクスについて整理が行われており、その点を踏まえると私は
理解しやすいのかなと思っています。

現在HTTPBis WGでは、HTTP/1.1のRFC群(RFC7230~RFC7235)の再改訂作業が行
われています。その草案では、もともとのHTTP/1.1の仕様から、HTTP/1.1の
フォーマット(*6)と、HTTPのセマンティクス(*7)が分離される予定となって
います。HTTP/1.1、HTTP/2、HTTP/3というプロトコルの進歩により、さまざ
まな変更がありますが、HTTPというセマンティクスを伝える形式が異なるだ
けであり、セマンティクスは維持されます。

(*5) Identifying our deliverables
     https://mailarchive.ietf.org/arch/msg/quic/RLRs4nB1lwFCZ_7k0iuz0ZBa35s

(*6) HTTP/1.1 Messaging
     https://tools.ietf.org/html/draft-ietf-httpbis-messaging

(*7) HTTP Semantics
     https://tools.ietf.org/html/draft-ietf-httpbis-semantics

○WGコンセンサス

まず11月6日(火)のQUIC WGで、HTTP/3への名称変更の議論が行われました。
HTTP over QUICの仕様は現在QUIC WGで管理されており、改称の影響範囲とし
て名称だけでなく、プロトコル内で使用される識別子もH3に変更されること
が確認されました。その後、ハミング(Hum)による採決によって、多くの賛成
をもってQUIC WG内でHTTP/3に名称を変更することと、最終的な決定はHTTPBis
WGに委ねられることに関するコンセンサスが得られました。

その後、11月8日(木)に行われたHTTPBis WGで、引き続き議論が行われまし
た。ここでは名称変更の他に、HTTP/3とそこで使用される新しいHTTPヘッダ
圧縮アルゴリズムであるQPACKについて、標準化後のメンテナンスをHTTPBis
WGで行うことについてのコンセンサスが得られました。その他にあった議論
としては、HTTP/3と番号を進めることで、HTTP/2より新しいことを明示的に
し、HTTP/3への移行を促すといった意見や、改善した点をHTTP/2の拡張とし
てバックポートすることもできるといった意見もありました。その議論のあ
と、HTTP/3へのHumが取られ、多くの賛成によってWGでのコンセンサスが得ら
れました。

こうして、IETF 103においてHTTP over QUICをHTTP/3と呼ぶことについて、
両WGでコンセンサスが得られました。その後、実際のHTTP over QUICおよび
それを参照する草案の修正はもちろんのこと、HTTPBis WGのチャーター変更
が現在進行系で進められています。


■ HTTP/3

それでは、HTTP/3というプロトコルがQUICを使用する他に、どのような変更
点があるのかも簡単に紹介します。

HTTP/3ではHTTP/2の設計をベースにし、トランスポートレイヤとしてQUICを
使うための変更が含まれています。HTTP/2では、一つのTCPコネクション上
でHTTPリクエスト・HTTPリクエストレスポンスを多重化して送受信します。
その多重化を実現するために、仮想的なコネクションの通信単位であるスト
リームという概念を導入していました。このストリームという単一コネクショ
ン内の仮想的な通信単位は、QUICレイヤで提供されるようになったため、
HTTP/3ではQUICレイヤのストリームを利用する形に変更されており、今まで
HTTP/2レイヤで行っていた各ストリームの制御に関する機能は、HTTP/3では
削除されている部分も多くあります。実際に、HTTP/2で使用するフレームタ
イプ(メッセージの種類)より、HTTP/3で使用するフレームタイプの種類は少
なくなっています。

また、先述の通りHTTP/3で利用するQUICは、UDPプロトコル上で動作します。
QUICでは信頼性のある通信を提供しますが、TCPとは異なりストリームという
通信単位ごとにのみ信頼性があります。パケットロスがあったとしても、異
なるストリームの通信をブロックすることはなく、届いたパケットが処理可
能であれば、パケットロスの回復を待たずに処理を続行できます。HTTP/3で
は処理順番を柔軟にできるように、HTTP/2では配送順番に依存していた部分
について改善を多く行っています。

このように、HTTP/3ではよりHTTPのメッセージを効率よく転送できるように、
多くの変更が加えられています。


■おわりに

HTTP/3という新名称は印象の強いキーワードであり、驚いた方も多くいらっ
しゃるでしょう。だいぶ駆け足でのHTTP/3の紹介となりましたが、理解の一
助となれば幸いです。また、興味のある方はぜひHTTP/3について一緒に追い
かけていければと思います。2018年12月14日(金)に行われますIETF報告会(*8)
でもHTTP/3の話をいたしますので、お気軽にお声がけいただければと思いま
す。

(*8) IETF報告会(103rdバンコク)
     https://www.isoc.jp/wiki.cgi?page=IETF103Update


     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
          まわりの方にもぜひNews & Viewsをオススメください!
      転送にあたっての注意や新規登録については文末をご覧ください。
                  ◇              ◇              ◇
       わからない用語については、【JPNIC用語集】をご参照ください。
             https://www.nic.ad.jp/ja/tech/glossary.html
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃     ◆◇◆◇◆   本号のご感想をお聞かせください   ◆◇◆◇◆     ┃
┃良かった                                                          ┃
┃  http://feedback.nic.ad.jp/1647/fa97464246318b72a4cbf4edc9581501 ┃
┃                                                                  ┃
┃悪かった                                                          ┃
┃  http://feedback.nic.ad.jp/1647/cc5a04317d57fbf52d4ab423e920dd8f ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
___________________________________
■■■■■  JPNICの活動はJPNIC会員によって支えられています  ■■■■■
  :::::  会員リスト  ::::: https://www.nic.ad.jp/ja/member/list/
  :::: 会員専用サイト :::: https://www.nic.ad.jp/member/ (PASSWORD有)
□┓ ━━━  N e w s & V i e w s への会員広告無料掲載実施中 ━━━┏□
┗┛          お問い合わせは  jpnic-news@nic.ad.jp  まで          ┗┛
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 JPNIC News & Views vol.1647 【臨時号】

 @ 発行  一般社団法人 日本ネットワークインフォメーションセンター
          101-0047 東京都千代田区内神田3-6-2 アーバンネット神田ビル4F
 @ 問い合わせ先  jpnic-news@nic.ad.jp
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
___________________________________
            本メールを転載・複製・再配布・引用される際には
        https://www.nic.ad.jp/ja/copyright.html をご確認ください
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
   ◇ JPNIC Webにも掲載していますので、情報共有にご活用ください ◇
登録・削除・変更   https://www.nic.ad.jp/ja/mailmagazine/
バックナンバー     https://www.nic.ad.jp/ja/mailmagazine/backnumber/
___________________________________
■■■■■     News & ViewsはRSS経由でも配信しています!    ■■■■■
::::: https://www.nic.ad.jp/ja/mailmagazine/backnumber/index.xml :::::
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄

■■◆                          @ Japan Network Information Center
■■◆                                     @  https://www.nic.ad.jp/
■■

Copyright(C), 2018 Japan Network Information Center
            

このページを評価してください

このWebページは役に立ちましたか?
よろしければ回答の理由をご記入ください

それ以外にも、ページの改良点等がございましたら自由にご記入ください。

回答が必要な場合は、お問い合わせ先をご利用ください。

ロゴ:JPNIC

Copyright© 1996-2025 Japan Network Information Center. All Rights Reserved.

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy