[インデックス 18376] ファイルの概要

このコミットは、Goのnet/httpパッケージにおいて、HTTPクライアントがレスポンスボディを読み終えた際に、より早くコネクションを再利用できるようにするための改善を導入します。具体的には、Content-Lengthヘッダが設定されているHTTPレスポンスボディの最終読み込み時に、即座にio.EOFを返すように変更することで、クライアントが明示的にClose()を呼び出したり、追加の読み込みを行ったりするのを待つことなく、基盤となるTCPコネクションをアイドル状態に戻し、再利用可能にします。これにより、特にjson.NewDecoderなどのようにボディを一度に読み込むが、明示的なCloseを呼び出さない可能性のあるクライアントコードにおいて、コネクションの効率的な再利用が促進されます。

コミット

commit 01e3b4fc6aa13e126f61782ad42aa51ba490b302
Author: Brad Fitzpatrick <bradfitz@golang.org>
Date:   Wed Jan 29 11:23:45 2014 +0100

    net/http: reuse client connections earlier when Content-Length is set
    
    Set EOF on the final Read of a body with a Content-Length, which
    will cause clients to recycle their connection immediately upon
    the final Read, rather than waiting for another Read or Close
    (neither of which might come).  This happens often when client
    code is simply something like:
    
      err := json.NewDecoder(resp.Body).Decode(&dest)
      ...
    
    Then there's usually no subsequent Read. Even if the client
    calls Close (which they should): in Go 1.1, the body was
    slurped to EOF, but in Go 1.2, that was then treated as a
    Close-before-EOF and the underlying connection was closed.
    But that's assuming the user even calls Close. Many don't.
    Reading to EOF also causes a connection be reused. Now the EOF
    arrives earlier.
    
    This CL only addresses the Content-Length case. A future CL
    will address the chunked case.
    
    LGTM=adg
    R=adg
    CC=golang-codereviews
    https://golang.org/cl/49570044

GitHub上でのコミットページへのリンク

https://github.com/golang/go/commit/01e3b4fc6aa13e126f61782ad42aa51ba490b302

元コミット内容

net/http: reuse client connections earlier when Content-Length is set

Content-Lengthが設定されたボディの最終ReadでEOFを設定することで、クライアントが最終Read時にすぐにコネクションを再利用できるようにします。これにより、別のReadやClose（どちらも行われない可能性がある）を待つ必要がなくなります。これは、クライアントコードが単にerr := json.NewDecoder(resp.Body).Decode(&dest)のようなものである場合に頻繁に発生します。この場合、通常は後続のReadはありません。クライアントがCloseを呼び出したとしても（そうすべきですが）、Go 1.1ではボディはEOFまで読み込まれていましたが、Go 1.2ではそれがClose-before-EOFとして扱われ、基盤となるコネクションが閉じられていました。しかし、これはユーザーがCloseを呼び出すことを前提としています。多くのユーザーは呼び出しません。EOFまで読み込むことでもコネクションは再利用されます。この変更により、EOFがより早く到達するようになります。

このCLはContent-Lengthの場合のみを扱います。将来のCLでチャンク形式の場合を扱います。

変更の背景

このコミットの背景には、Goのnet/httpパッケージにおけるHTTPコネクションの再利用の挙動と、Go 1.1からGo 1.2への変更による影響があります。

HTTP/1.1では、パフォーマンス向上のためにコネクションの再利用（Keep-Alive）が推奨されています。クライアントがサーバーからレスポンスを受け取った後、そのコネクションを閉じずに再利用することで、新しいTCPコネクションを確立するオーバーヘッドを削減できます。net/httpパッケージのTransportは、このコネクションプールを管理し、アイドル状態のコネクションを再利用します。

しかし、コネクションを再利用するためには、クライアントがレスポンスボディを完全に読み終えるか、明示的にClose()を呼び出す必要があります。問題は、多くのクライアントコードがレスポンスボディを完全に読み終えない、あるいはClose()を呼び出さないケースがあることです。

特に、json.NewDecoder(resp.Body).Decode(&dest)のようなパターンでは、Decodeメソッドが内部的に必要なバイト数だけボディを読み込みますが、それ以上の読み込みは行いません。もしレスポンスボディの残りの部分が読み込まれない場合、net/httpのTransportはコネクションがまだ使用中であると判断し、プールに戻すことができませんでした。

Go 1.1では、レスポンスボディが完全に読み込まれていなくても、Close()が呼ばれると残りのボディが「スラープ（slurp）」され、コネクションが再利用のためにプールに戻される挙動がありました。しかし、Go 1.2では、この挙動が変更され、Close()が呼ばれた時点でボディが完全に読み込まれていない場合（Close-before-EOF）、基盤となるコネクションが閉じられるようになりました。これは、部分的に読み込まれたボディを持つコネクションを再利用すると、次のリクエストで予期せぬデータが残っている可能性があるため、より安全な挙動と判断されたためと考えられます。

このGo 1.2での変更は、安全性は向上させたものの、開発者がresp.Body.Close()を呼び出すことを忘れたり、json.NewDecoderのようにボディを部分的にしか読み込まないケースで、コネクションの再利用が阻害され、パフォーマンスが低下する可能性を生じさせました。

このコミットは、この問題を緩和するために導入されました。Content-Lengthが既知の場合に、ボディの最終バイトを読み込んだ直後にio.EOFを返すことで、クライアントが明示的にClose()を呼び出さなくても、あるいは追加のReadを行わなくても、Transportがコネクションをアイドル状態と判断し、プールに再利用のために戻せるようにします。これにより、Go 1.2での挙動変更によるコネクション再利用の阻害を、特に一般的なユースケースで回避し、パフォーマンスを維持・向上させることを目指しています。

前提知識の解説

このコミットを理解するためには、以下の概念について理解しておく必要があります。

1. HTTP/1.1 コネクションの再利用 (Keep-Alive): HTTP/1.1では、複数のリクエスト/レスポンスを同じTCPコネクション上で送受信できる「持続的接続（Persistent Connections）」がデフォルトで有効になっています。これにより、リクエストごとに新しいTCPコネクションを確立するオーバーヘッド（TCPハンドシェイク、TLSハンドシェイクなど）を削減し、Webアプリケーションのパフォーマンスを向上させます。サーバーとクライアントは、Connection: keep-aliveヘッダを交換することで、この機能を利用します。

2. io.Reader インターフェース: Go言語における基本的なI/Oインターフェースの一つです。

   type Reader interface {
       Read(p []byte) (n int, err error)
   }
   

   Readメソッドは、データをpに読み込み、読み込んだバイト数nとエラーerrを返します。データがこれ以上ない場合、Readはn > 0の場合でもio.EOFエラーを返します。io.EOFは、ストリームの終端に達したことを示す特別なエラーです。

3. io.EOF: io.EOFは、io.Readerがこれ以上データを生成しないことを示すエラーです。Readメソッドは、読み込むデータが残っていない場合にio.EOFを返します。重要なのは、io.Readerの契約上、Readは読み込んだバイト数nが0でなくてもio.EOFを返すことができるという点です。つまり、最後のチャンクのデータを返しつつ、同時にEOFを通知することが許されています。

4. net/httpパッケージのResponse.Body: http.Getやhttp.Client.DoなどでHTTPリクエストを実行すると、*http.Responseが返されます。このResponse構造体にはBodyフィールドがあり、これはio.ReadCloserインターフェース（io.Readerとio.Closerを組み合わせたもの）を実装しています。クライアントは、このBodyからレスポンスのペイロードを読み取ります。

5. Content-Lengthヘッダ: HTTPレスポンスヘッダの一つで、メッセージボディのバイト単位のサイズを示します。このヘッダが存在する場合、クライアントはボディの正確なサイズを知ることができ、そのバイト数だけ読み込めばボディの終端に達したと判断できます。

6. Transfer-Encoding: chunked: Content-Lengthヘッダが利用できない場合（例: 動的に生成されるコンテンツ）、HTTP/1.1では「チャンク転送エンコーディング」が使用されます。この場合、ボディは複数の「チャンク」に分割され、各チャンクの前にそのサイズが記述されます。ボディの終端は、サイズが0のチャンクで示されます。

7. io.LimitedReader: ioパッケージで提供される構造体で、指定されたバイト数までしか読み込まないReaderをラップします。Nフィールドに残り読み込み可能なバイト数が格納されており、Readが呼び出されるたびにNが減少します。Nが0になると、それ以上読み込みを行わずio.EOFを返します。net/httpの内部では、Content-Lengthが指定されたレスポンスボディの読み込みを管理するために、このio.LimitedReaderが使用されることがあります。

8. json.NewDecoder(resp.Body).Decode(&dest): Goのencoding/jsonパッケージの一般的な使用パターンです。json.NewDecoderはio.Readerを受け取り、そこからJSONデータを読み込みます。Decodeメソッドは、JSONストリームから次のJSONエンコードされた値を読み取り、それをdestに格納します。この操作は、必要なJSONデータが読み込まれると完了し、通常はレスポンスボディの残りの部分を読み込むことはありません。

9. resp.Body.Close(): http.Response.Bodyはio.ReadCloserであるため、Close()メソッドを持っています。このメソッドを呼び出すことは、リソースリークを防ぐために非常に重要です。Close()が呼び出されると、基盤となるコネクションが閉じられるか、再利用のためにプールに戻されます。

このコミットは、特にContent-Lengthが設定されている場合に、io.LimitedReaderのNが0になった時点で、Readメソッドが積極的にio.EOFを返すようにすることで、クライアントがボディの読み込みを完了したことをnet/httpのTransportに早期に通知し、コネクションの再利用を促進するというものです。

技術的詳細

このコミットの技術的な核心は、net/httpパッケージ内のレスポンスボディの読み込みを管理するbody構造体のreadLockedメソッドの挙動変更にあります。

HTTPレスポンスボディは、その性質上、ストリームとして扱われます。クライアントはresp.Body.Read()を繰り返し呼び出すことで、ボディのデータを順次取得します。net/httpの内部では、Content-Lengthヘッダが存在する場合、レスポンスボディの読み込みはio.LimitedReaderによってラップされることがあります。このio.LimitedReaderは、Content-Lengthで指定されたバイト数だけを読み込むことを保証します。

変更前の挙動では、io.LimitedReaderが読み込み可能なバイト数をすべて消費し、内部のNが0になったとしても、readLockedメソッドは直ちにio.EOFを返しませんでした。代わりに、次のRead呼び出しがあった場合に初めてio.EOFが返されるか、あるいはクライアントがresp.Body.Close()を明示的に呼び出すまで、コネクションは「使用中」の状態と見なされていました。

この「遅延EOF」の挙動は、特に以下のようなシナリオで問題を引き起こしました。

1. 部分的なボディ読み込み: json.NewDecoder(resp.Body).Decode(&dest)のように、クライアントがレスポンスボディの一部（JSONデータなど）だけを読み込み、残りのボディを読み飛ばす場合。この場合、io.LimitedReaderのNは0になっていても、readLockedはまだEOFを返していないため、コネクションはアイドル状態にならず、再利用プールに戻されません。
2. Close()の欠如: 開発者がresp.Body.Close()を呼び出すのを忘れた場合。これはGoのベストプラクティスに反しますが、現実にはよく発生します。Close()が呼ばれない限り、コネクションは解放されず、リークの原因となります。
3. Go 1.2での挙動変更: Go 1.2では、Close()が呼ばれた際にボディが完全に読み込まれていない場合、コネクションを再利用せずに閉じるようになりました。これは、部分的に読み込まれたコネクションを再利用することによる潜在的なデータ破損を防ぐための安全策でしたが、結果としてコネクションの再利用率が低下する可能性がありました。

このコミットは、readLockedメソッドに以下のロジックを追加することで、これらの問題を解決します。

	// If we can return an EOF here along with the read data, do
	// so. This is optional per the io.Reader contract, but doing
	// so helps the HTTP transport code recycle its connection
	// earlier (since it will see this EOF itself), even if the
	// client doesn't do future reads or Close.
	if err == nil && n > 0 {
		if lr, ok := b.src.(*io.LimitedReader); ok && lr.N == 0 {
			err = io.EOF
		}
	}

このコードは、以下の条件がすべて満たされた場合にerrをio.EOFに設定します。

• err == nil: 現在の読み込み操作でエラーが発生していない。
• n > 0: 少なくとも1バイトのデータが正常に読み込まれた。
• lr, ok := b.src.(*io.LimitedReader); ok: bodyのソースリーダーがio.LimitedReaderであり、かつその型アサーションが成功した。
• lr.N == 0: io.LimitedReaderがこれ以上読み込むべきバイト数を持っていない（つまり、Content-Lengthで指定されたすべてのバイトが読み込まれた）。

この変更により、Content-Lengthが設定されたレスポンスボディの最後のチャンクが読み込まれた直後、つまりio.LimitedReaderのNが0になった時点で、readLockedはio.EOFを返します。これにより、net/httpのTransportは、クライアントがボディの読み込みを完了したことを早期に検出し、基盤となるコネクションをアイドル状態のプールに即座に戻すことができます。

結果として、クライアントがresp.Body.Close()を明示的に呼び出さなくても、あるいはjson.NewDecoderのように部分的にしかボディを読み込まない場合でも、コネクションの再利用が促進され、アプリケーション全体のパフォーマンスとリソース効率が向上します。

このコミットはContent-Lengthの場合のみを対象としており、Transfer-Encoding: chunkedの場合については、将来のコミットで対応されることが示唆されています。チャンク形式の場合も同様の最適化が可能ですが、終端の検出ロジックが異なるため、別途の対応が必要となります。

コアとなるコードの変更箇所

このコミットによる主要なコード変更は以下の2つのファイルにあります。

1. src/pkg/net/http/transfer.go:

   • body構造体のreadLockedメソッドに、io.EOFを早期に設定するロジックが追加されました。

2. src/pkg/net/http/transport_test.go:

   • TestTransportReadToEndReusesConnという新しいテストケースが追加されました。このテストは、レスポンスボディを最後まで読み込んだ際に、コネクションが正しく再利用されることを検証します。

src/pkg/net/http/transfer.go の変更点

--- a/src/pkg/net/http/transfer.go
+++ b/src/pkg/net/http/transfer.go
@@ -559,6 +559,17 @@ func (b *body) readLocked(p []byte) (n int, err error) {
 		}
 	}
 
+// If we can return an EOF here along with the read data, do
+// so. This is optional per the io.Reader contract, but doing
+// so helps the HTTP transport code recycle its connection
+// earlier (since it will see this EOF itself), even if the
+// client doesn't do future reads or Close.
+	if err == nil && n > 0 {
+		if lr, ok := b.src.(*io.LimitedReader); ok && lr.N == 0 {
+			err = io.EOF
+		}
+	}
+
 	return n, err
 }

src/pkg/net/http/transport_test.go の変更点

--- a/src/pkg/net/http/transport_test.go
+++ b/src/pkg/net/http/transport_test.go
@@ -271,6 +271,49 @@ func TestTransportIdleCacheKeys(t *testing.T) {
 	}
 }
 
+// Tests that the HTTP transport re-uses connections when a client
+// reads to the end of a response Body without closing it.
+func TestTransportReadToEndReusesConn(t *testing.T) {
+	defer afterTest(t)
+	const msg = "foobar"
+
+	addrSeen := make(map[string]int)
+	ts := httptest.NewServer(HandlerFunc(func(w ResponseWriter, r *Request) {
+		addrSeen[r.RemoteAddr]++
+		w.Header().Set("Content-Type", strconv.Itoa(len(msg)))
+		w.WriteHeader(200)
+		w.Write([]byte(msg))
+	}))
+	defer ts.Close()
+
+	buf := make([]byte, len(msg))
+
+	for i := 0; i < 3; i++ {
+		res, err := http.Get(ts.URL)
+		if err != nil {
+			t.Errorf("Get: %v", err)
+			continue
+		}
+		// We want to close this body eventually (before the
+		// defer afterTest at top runs), but not before the
+		// len(addrSeen) check at the bottom of this test,
+		// since Closing this early in the loop would risk
+		// making connections be re-used for the wrong reason.
+		defer res.Body.Close()
+
+		if res.ContentLength != int64(len(msg)) {
+			t.Errorf("res.ContentLength = %d; want %d", res.ContentLength, len(msg))
+		}
+		n, err := res.Body.Read(buf)
+		if n != len(msg) || err != io.EOF {
+			t.Errorf("Read = %v, %v; want %d, EOF", n, err, len(msg))
+		}
+	}
+	if len(addrSeen) != 1 {
+		t.Errorf("server saw %d distinct client addresses; want 1", len(addrSeen))
+	}
+}
+
 func TestTransportMaxPerHostIdleConns(t *testing.T) {
 	defer afterTest(t)
 	resch := make(chan string)

コアとなるコードの解説

src/pkg/net/http/transfer.go の readLocked メソッド

readLockedメソッドは、net/httpパッケージ内でHTTPレスポンスボディの実際の読み込み処理を担う内部メソッドです。このメソッドは、body構造体（これはhttp.Response.Bodyの内部実装）によって呼び出されます。

追加されたコードブロックは以下の通りです。

	if err == nil && n > 0 {
		if lr, ok := b.src.(*io.LimitedReader); ok && lr.N == 0 {
			err = io.EOF
		}
	}

• if err == nil && n > 0: これは、現在のRead操作が成功し（エラーがなく）、かつ実際にデータが読み込まれた（n > 0）場合にのみ、以下のロジックを実行するという条件です。データが読み込まれていない場合や、すでにエラーが発生している場合は、この最適化は適用されません。
• if lr, ok := b.src.(*io.LimitedReader); ok: ここでは、body構造体の内部ソースリーダーb.srcが*io.LimitedReader型であるかどうかを型アサーションで確認しています。Content-Lengthヘッダが指定されている場合、通常このb.srcはio.LimitedReaderのインスタンスになります。okは型アサーションが成功したかどうかを示します。
• lr.N == 0: io.LimitedReaderのNフィールドは、残り読み込み可能なバイト数を示します。lr.N == 0は、Content-Lengthで指定されたすべてのバイトが既に読み込まれたことを意味します。

これらの条件がすべて満たされた場合、つまり「エラーなくデータが読み込まれ、それがContent-Lengthで指定されたボディの最後の部分であり、これ以上読み込むデータがない」という状況であれば、err = io.EOFと設定されます。これにより、readLockedは読み込んだデータと共にio.EOFを呼び出し元に返します。

この変更のポイントは、io.Readerの契約が「Readは読み込んだバイト数nが0でなくてもio.EOFを返すことができる」と規定している点を利用していることです。これにより、最後のデータを返しつつ、同時にストリームの終端を通知できるため、クライアントは次のReadを待つことなく、あるいはClose()を呼び出すことなく、コネクションが再利用可能になったことを認識できます。

src/pkg/net/http/transport_test.go の TestTransportReadToEndReusesConn テスト

この新しいテストケースは、変更が意図通りに機能し、コネクションが正しく再利用されることを検証します。

• テストの目的: クライアントがレスポンスボディを最後まで読み込んだ後、明示的にBody.Close()を呼び出さなくても、HTTPトランスポートがコネクションを再利用することを確認します。
• テストサーバーのセットアップ:
  • httptest.NewServerを使用してテスト用のHTTPサーバーを起動します。
  • サーバーのハンドラは、リクエストが来るたびにr.RemoteAddr（クライアントのIPアドレスとポート）をaddrSeenマップに記録します。これにより、異なるコネクションが使用されたかどうかを追跡できます。
  • レスポンスにはContent-Typeヘッダ（実際にはContent-Lengthの代わりとして使用されているが、テストの意図はContent-Lengthの挙動を模倣すること）と、固定のメッセージ"foobar"が設定されます。
• クライアントのリクエスト:
  • for i := 0; i < 3; i++ループで、同じURLに対して3回http.Getリクエストを行います。
  • 各リクエストの後、defer res.Body.Close()を呼び出していますが、これはテストの最後にコネクションをクリーンアップするためのものであり、ループ内で即座にClose()が呼ばれるわけではありません。テストの意図は、Close()が即座に呼ばれない状況でのコネクション再利用を検証することです。
  • res.ContentLengthが期待通りであることを確認します。
  • res.Body.Read(buf)を呼び出し、レスポンスボディを完全に読み込みます。ここで重要なのは、n != len(msg) || err != io.EOFというアサーションです。これは、読み込んだバイト数がメッセージの長さと一致し、かつio.EOFが返されることを期待しています。このio.EOFが、transfer.goの変更によって早期に返されることを検証するものです。
• コネクション再利用の検証:
  • ループが終了した後、if len(addrSeen) != 1というアサーションを行います。
  • もしコネクションが正しく再利用されていれば、サーバーは3回のリクエストすべてに対して同じクライアントアドレス（つまり同じTCPコネクション）を認識するはずなので、addrSeenマップの要素数は1になるはずです。もしコネクションが再利用されずに毎回新しいコネクションが確立されていれば、要素数は3になるでしょう。

このテストは、Content-Lengthが設定されたレスポンスボディを完全に読み込んだ際に、io.EOFが早期に返され、その結果としてnet/httpのTransportがコネクションを再利用プールに正しく戻すという、このコミットの主要な目的を効果的に検証しています。

関連リンク

• Go CL 49570044: https://golang.org/cl/49570044

参考にした情報源リンク

• Go言語の公式ドキュメント (ioパッケージ、net/httpパッケージ)
• HTTP/1.1 仕様 (RFC 2616, 特にPersistent Connectionsに関するセクション)
• Go 1.2 Release Notes (コネクション管理に関する変更点があれば)
• GoのIssueトラッカーやメーリングリストでの関連議論 (もしあれば)
• Goのソースコード (特にsrc/net/httpディレクトリ)

（注: Go 1.2のリリースノートや関連する議論を直接参照してはいませんが、コミットメッセージの内容からその時期のGoのnet/httpの挙動に関する変更が背景にあると推測し、一般的な情報源として記載しています。）I have generated the detailed technical explanation in Markdown format, following all the instructions and the specified chapter structure. The output is in Japanese and includes comprehensive details on the background, prerequisite knowledge, technical specifics, core code changes, and their explanations. I have also included the relevant links.

I will now output the generated Markdown content to standard output.