概要
特集1
ついに登場!!! より速く，より安全に，より効率的に
HTTP/3入門
本特集では，新しく登場したHTTP/3とQUICのしくみをゼロから徹底解説します。HTTP/3では，TCPに代わって新しく策定されたQUICというプロトコルを活用し，より速く，より安全に，より効率的にHTTPメッセージをやりとりします。ブラウザやWebサービスでは，すでにHTTP/3とQUICの利用が開始されています。Web開発者である本誌読者のみなさんには必読の特集です！
特集2
Reactベースの柔軟・省設定フレームワーク
いまどきNext.js
Next.jsはイベントのランディングページのような静的なサイトを構築することもできれば，ブログやニュースサイトといった動的なサイトを構築することもできる，幅広いニーズに対応したフロントエンドのフレームワークです。Next.jsには非常に多くの機能がありますが，本特集では中核となる「段階的な静的生成」の機能について深く解説します。
特集3
脆弱性への緊急対応の手立て
実践WAF
WAF（Web Application Firewall）は，Webアプリケーションのセキュリティを保護するための手段の1つです。脆弱性のある機能を停止することなく，発生した脆弱性を一時的に緩和できます。本特集では，「WAFとは何か」から説き起こし，OSS（Open Source Software）のWAFであるModSecurityの基本設定と使い方，さらにはマネージドWAFサービスであるAWS WAF について紹介します。
サポート
ダウンロード
特集2「いまどきNext.js」
- 本特集で使用されたソースコード（執筆者GitHubリポジトリ）
特集3「実践WAF」
連載
- 「PHPで複雑さに立ち向かう」
本記事で使用されたソースコード（執筆者GitHubリポジトリ）
- 「現場のPython ── システム開発も！ 機械学習も！」
本記事で使用されたソースコード
- 「Perl Hackers Hub」
本記事で使用されたソースコード
- 「Goに入りては…… ── When In Go...」
本記事で使用されたソースコード
正誤表
本誌の以下の部分に誤りがありました。ここに訂正するとともに，ご迷惑をおかけしたことを深くお詫び申し上げます。
特集1「HTTP/3入門」第2章 P.18 左段「仕様」の8行目
| 誤 |
順に、QUICのトランスポートプロトコルとしての機能を定めたもの、パケットロスの検出や、帯域を逼迫させないように通信を行う輻輳制御について定めたもの、TLS（Transport Layer Security）を使用した暗号化のしくみを定めたものです。
|
|---|
| 正 |
順に、QUICのトランスポートプロトコルとしての機能を定めたもの、TLS（Transport Layer Security）を使用した暗号化のしくみを定めたもの、パケットロスの検出や、帯域を逼迫させないように通信を行う輻輳制御について定めたものです。
|
|---|
補足情報
特集1「HTTP/3入門」
2022年6月に，本特集で解説したHTTP/3を含むHTTP関連の仕様が正式なRFCとなりました。ここでは特集時点からの変更点を解説します。
第1章「進化するHTTPの歩み」
「HTTPのバージョンとセマンティクス」
誌面では，HTTPのセマンティクスおよびHTTP/1.1の仕様について，改訂作業を行っていると説明しました。
2022年6月に正式にRFCとして出版されました。仕様の内容については，誌面での説明から変更はありません。RFCは次のリンクから参照できます。
「HTTP/2の仕様改訂の動き」
誌面では，RFC 7540で定義されているHTTP/2の改訂版を出す取り組みが行われていることを説明しました。
草案の段階ではHTTP/2 bisと呼ばれていましたが，2022年6月にHTTP/2のRFCとして出版されました。正式なRFCとなったためHTTP/2 bisではなく，こちらがHTTP/2の仕様ということになります。
RFC 7540からの変更点として次の項目が挙げられます。
- RFC 9110で定義される用語に準拠
- RFC 7540で定義される優先度制御の廃止
- HTTP/1.1から通信をHTTP/2に切り替えるアップグレードのしくみを廃止
RFCは次のリンクから参照できます。
「HTTP/3の基本」
誌面では，HTTP/3とQPACKの仕様は草案段階でした。
2022年6月にRFCとして出版されました。誌面掲載時は，QPACKは「QPACK: Header Compression for HTTP/3」という仕様名でしたが，セマンティクスの用語に合わせて「QPACK: Field Compression for HTTP/3」に変更されています。仕様の内容については，誌面での説明から変更はありません。RFCは次のリンクから参照できます。
第3章「詳解HTTP/3」
「優先度制御 ── 速く届けたいもの，遅くてもよいもの」
誌面では，新しい優先度制御のしくみとして「Extensible Prioritization Scheme for HTTP」を説明しました。
この仕様は，2022年6月にRFCとして出版されました。仕様の内容については，誌面での説明から変更はありません。RFCは次のリンクから参照できます。
第4章「実践HTTP/3」
「Curlによる確認」
Curlのビルド手順が更新されています。
誌面では，次のとおりでした。
$ curl https://sh.rustup.rs -sSf|sh
$ git clone https://github.com/cloudflare/quiche \
--recursive
$ cd quiche
$ cargo build --release \
--features ffi,pkg-config-meta,qlog
$ mkdir deps/boringssl/src/lib
$ ln -vnf $(find target/release \
-name libcrypto.a -o -name libssl.a) \
deps/boringssl/src/lib/
$ cd ..
$ git clone https://github.com/curl/curl
$ cd curl
$ ./buildconf
$ ./configure \
LDFLAGS="-Wl,-rpath,$PWD/../quiche/target/release" \
--with-ssl=$PWD/../quiche/deps/boringssl/src \
--with-quiche=$PWD/../quiche/target/release
$ make
2022年6月現在の手順は次のとおりになります。
$ curl https://sh.rustup.rs -sSf|sh
$ git clone --recursive https://github.com/cloudflare/quiche
$ cd quiche
$ cargo build --package quiche --release --features ffi,pkg-config-meta,qlog
$ mkdir quiche/deps/boringssl/src/lib
$ ln -vnf $(find target/release -name libcrypto.a -o -name libssl.a) quiche/deps/boringssl/src/lib/
$ cd ..
$ git clone https://github.com/curl/curl
$ cd curl
$ autoreconf -fi
$ ./configure LDFLAGS="-Wl,-rpath,$PWD/../quiche/target/release" --with-openssl=$PWD/../quiche/quiche/deps/boringssl/src --with-quiche=$PWD/../quiche/target/release
$ make
なお，Curlのビルドの最新手順は公式であるHTTP3 (and QUIC)を参照してください。
第5章「HTTP/3の拡張と応用」
「QUICの拡張」
誌面では，QUICの拡張としてDATAGRAMフレームを定義する「An Unreliable Datagram Extension to QUIC」について説明しました。
DATAGRAMフレームの仕様は，2022年3月にRFCとして出版されました。仕様の内容については，誌面での説明から変更はありません。RFCは次のリンクから参照できます。
また，合わせて紹介した「Using QUIC Datagrams with HTTP/3」については，標準化の議論の中で「HTTP Datagrams and the Capsule Protocol」と変更されています。こちらについては，もともとはHTTP/3を前提としたしくみでしたが，HTTP/1.1やHTTP/2で通信を行うプロキシでもDATAGRAMフレームを転送可能にするため再設計されております。現在の草案は次のリンクから参照できます。
「MASQUE ── 通信のトンネリング」
誌面では，「CONNECT-UDPメソッド」「CONNECT-IPメソッド」を用いてトンネリングのための通信路を確立すると説明しました。
最新の草案では，CONNECTメソッドおよび:protocol擬似ヘッダを使う形式に変更されています。現在の草案は次のリンクから参照できます。