Transfer-Encoding(トランスファーエンコーディング)とは | 意味や読み方など丁寧でわかりやすい用語解説

「Transfer-Encoding」は、HTTP（Hypertext Transfer Protocol）において、メッセージボディをクライアントとサーバー間で安全かつ効率的に転送するためのエンコーディング形式を指定するヘッダフィールドである。特に、メッセージボディのサイズが事前に確定しない場合や、永続的な接続（Persistent Connections）を効率的に利用する場合に重要な役割を果たす。このヘッダはHTTP/1.1から導入され、従来のHTTP/1.0が抱えていたいくつかの課題を解決した。

「Transfer-Encoding」の主要な目的は、送信側（サーバー）がメッセージボディの全体量を把握していなくても、データの送信を開始し、受信側（クライアント）がその終わりを正しく認識できるようにすることにある。また、転送中にデータに何らかの変換が施されたことを示し、受信側がそれらを元に戻す（デコードする）必要があることを伝える。

詳細に入る。「Transfer-Encoding」で最も広く利用される値は「chunked」である。「chunked」エンコーディングでは、メッセージボディは複数の「チャンク」（塊）に分割されて送信される。各チャンクは、そのチャンクのサイズを示す16進数と、それに続く実際のデータで構成される。チャンクのデータが全て送信された後、改行コード（CRLF）が挿入され、次のチャンクが続く。メッセージボディの終わりを示すためには、サイズが「0」のチャンクが送信され、その後に終端を示す改行コードが2回続く。この「0」サイズのチャンクの後には、オプションでフッタと呼ばれるヘッダフィールドが付加される場合もあるが、これは必須ではない。

「chunked」エンコーディングの最大の利点は、サーバーがレスポンスメッセージボディの全長を事前に知る必要がない点にある。これは、動的にコンテンツを生成するアプリケーション（データベースからのデータ取得、CGIスクリプトの実行結果など）にとって非常に有効である。サーバーはコンテンツが生成され次第、その一部をチャンクとして送信し始めることができるため、ユーザーへの応答速度が向上する。従来のHTTP/1.0では、メッセージボディのサイズを「Content-Length」ヘッダで事前に指定する必要があったため、動的なコンテンツでは、サーバーが全てのコンテンツを生成し終えてからでないと送信を開始できなかった。これにより、レスポンスが遅延したり、サーバーが一時的に大量のメモリを消費してコンテンツ全体をバッファリングする必要が生じたりする問題があった。

また、「chunked」エンコーディングは、HTTP/1.1の永続的接続（Keep-Alive）と非常に相性が良い。永続的接続では、一つのTCP接続を複数のリクエスト・レスポンスのやり取りに再利用する。もしメッセージボディの終端を「Content-Length」で厳密に指定しない場合、受信側はメッセージボディのどこまでが現在のレスポンスに属するのかを判断できず、次のレスポンスの開始位置を特定できない可能性がある。「chunked」エンコーディングは、「0」サイズの終端チャンクによって、メッセージボディの明確な終わりを示すため、永続的接続下でも次のHTTPレスポンスの開始を正確に区別できる。これにより、接続の再確立にかかるオーバーヘッドが削減され、通信効率が向上する。

「Transfer-Encoding」と混同されやすいヘッダに「Content-Encoding」がある。「Content-Encoding」はメッセージボディの内容自体がどのように圧縮されたり、変換されたりしているかを示すものであり、例えば「gzip」や「deflate」といった値が用いられる。これはデータの内容に対するエンコーディングであり、クライアントは受信後、まず「Content-Encoding」に従ってデータを解凍してから、本来のコンテンツとして利用する。一方、「Transfer-Encoding」はメッセージボディの「転送方法」に関するエンコーディングであり、ネットワーク上でのデータの流れ方に関わる。両者は異なる役割を持ち、併用されることもある。例えば、データが「gzip」で圧縮され、かつ「chunked」形式で転送される場合、ヘッダは「Transfer-Encoding: chunked」と「Content-Encoding: gzip」のように記述される。HTTP/1.1の仕様では、「Transfer-Encoding」ヘッダに複数のエンコーディングをカンマ区切りで指定する際は、最後のエンコーディングが「chunked」である必要があるとされているが、現代では通常「Transfer-Encoding: chunked」のみが使われ、他の転送エンコーディングはほとんど見られない。

プロキシサーバーは、「Transfer-Encoding」ヘッダの処理において重要な役割を果たすことがある。特に、ダウンストリームのクライアントが「Transfer-Encoding: chunked」を理解しないHTTP/1.0クライアントである場合、プロキシサーバーは受信したチャンクデータを全てデコードし、結合して完全なメッセージボディを再構築し、その全体のサイズを「Content-Length」ヘッダに記載してHTTP/1.0クライアントに転送する責任を負う。これは「透過的なプロキシ」の挙動の一つである。しかし、プロキシがHTTP/1.1以降を理解するクライアントに転送する場合は、多くの場合「Transfer-Encoding: chunked」をそのまま転送する。

このように、「Transfer-Encoding」はHTTP通信、特にHTTP/1.1以降におけるデータ転送の柔軟性と効率性を大幅に向上させるための重要なメカニズムである。メッセージボディのサイズが不確定な動的コンテンツの配信や、永続的接続の効率的な利用を可能にし、ウェブアプリケーションのパフォーマンスと応答性を支えている。