TL; DR;

Golangのnet/http実装からHTTP1.1クライアント挙動の疑問を解消しました。
http.Transportにはmaxディレクティブのような利用回数上限はなく、idleConnTimeoutよりも前にコネクションを再利用し続けることでコネクションを維持できます。
HTTPリクエストをcontextでキャンセルすると、そのコネクションは再利用されず切断されます。
Response.BodyをEOFまで読まなかったりCloseを忘れると下の表のような挙動になります。

	Keep-Alive無効	Keep-Alive有効
EOFまで読まずCloseもしない	切断処理の途中でスタックしコネクションが残り続ける	コネクションが残り続けてkeep-aliveされない
EOFまで読むがCloseはしない	コネクションは切断される	keep-aliveされる
EOFまで読まずCloseはする	コネクションは切断される	コネクションが切断されてkeep-aliveされない
EOFまで読みCloseする	コネクションは切断される	keep-aliveされる

はじめに

先日、Golangを利用したアプリケーションによるHTTPリクエストで発生したNW起因エラーの調査をしていたのですが、細かいところまで深く考え始めると「こういうときってTCPコネクションって再利用されるんだっけ…」「なんでこうなるんだっけ…」と気になり始めました。

この記事は、これを機にGolangのnet/httpのコードリーディングを行い実装に基づいて様々な挙動を調べてみた結果を整理する目的で執筆しています。具体的には、

Transport.idleConnTimeoutよりも前にコネクションを再利用し続けるとどうなるのか？
- HTTPのkeep-aliveヘッダにはmaxディレクティブがあり利用回数の上限を設定できますが、golangのHTTPクライアントでは上限があるのか？
contextによってHTTPリクエストをキャンセルするとTCPコネクションは再利用されるのか？
Response.BodyはEOFまで読んだ上でCloseしなくてはいけないとよく言われるけどやらないとどうなるのか？

という疑問です。

この記事では、はじめにnet/httpでのHTTPクライアントがどのように実装されているのかを解説します。その後で、それを元に上記の疑問を実装ベース・実際の挙動ベースの両方から検証していきます。

実装の解説は細かめになるので、頭からじっくり読んでもいいですし、各疑問に飛んで読んでもいいです。

net/httpでのHTTPクライアントの実装

今回参考にした実装はGolang 1.24.1のものです。詳細な実装の説明に入る前に、net/httpでのHTTPクライアントの主要な型の関係を図にまとめておきます。

RequestやResponseは読んで字のごとくリクエストやレスポンスそのものを表す型ですが、Client/RoundTripper/Transport/net.Dialerなどは初見ではよくわからないと思います。 net/httpの主要型の関係

Clientは、HTTPクライアントそのものです。単純にリクエストを送る場合にhttp.Get()を使うことがあるかと思いますが、内部ではClient型のデフォルト実装として用意されているDefaultClientが使われています。

とはいってもClientが直接HTTPリクエストを送るわけではなく、RoundTripperインタフェースを実装したTransportフィールドが直接的なHTTPリクエストを送信しています。少しややこしいですが、Transportフィールドを特に指定しなかった場合、RoundTripperインタフェースを実装したTransport型のデフォルト実装であるDefaultTransportが使われています。 Transportというフィールド名にTransport型を入れていますが、あくまでもRoundTripperインタフェースを実装している型を指定しているだけです。

1
type RoundTripper interface {
2
  // ...
3
  RoundTrip(*Request) (*Response, error)
4
}

RoundTripperインタフェースは上記のように単独のHTTPリクエストを行うRoundTripメソッドを持つだけのインタフェースです。そのため、内部でコネクションプールを実装することも可能ですし、もしかすると鳩通信プロトコルを使ってリクエストを送る実装もあるかもしれません。

このように、HTTPクライアントで使われるTCPコネクションの挙動はRoundTripperとして具体的に何が使われるかに依存するため、全てのHTTPクライアントの挙動を説明することはできませんが、それだとこの記事の意味がなくなってしまうのでこれ以降では多くの場合に使われるTransport型を前提として説明します。 Transport型ではRoundTripメソッドはroundTripメソッドのラッパーとなっているため、Transport型のroundTripメソッドを見ればHTTPクライアントの挙動を理解できると言えます。

それではいよいよTransport.roundTripメソッドを起点にHTTPリクエスト時の挙動をみていきましょう。以下の図がTransport.roundTripメソッドの処理の流れです。

曼荼羅のようですが、大雑把に分けると以下のようにコネクションプール管理・TCPコネクション生成・TCPコネクションによるHTTP読み書きに分けられます。つまり、プールされたもしくは新たに生成されたTCPコネクションを取得し、そのコネクションに対してHTTPリクエスト発行を要求・その結果を受信することでリクエストが行われます。

実際のコードは下のようになっています。 Transport.getConn()でTCPコネクション（persistConn型）を取得し、persistConn.roundTrip()でHTTPリクエストを行ってResponseを受け取ります。

1
// roundTrip implements a RoundTripper over HTTP.
2
func (t *Transport) roundTrip(req *Request) (_ *Response, err error) {
3
    ...
4
    // forとなっているのはリトライのため
5
  for{
6
    ...
7
    pconn, err := t.getConn(treq, cm)
8
    ...
9

10
    var resp *Response
11
    if pconn.alt != nil {
12
      ...
13
    } else {
14
      resp, err = pconn.roundTrip(treq)
15
    }
16
        if err == nil {
17
      ...
18
      return resp, nil
19
    }
20
    ...
21
  }
22
}

cf. https://cs.opensource.google/go/go/+/refs/tags/go1.24.1:src/net/http/transport.go

Transport.getConn()では、TCPコネクションの獲得要求（wantConn型）をTransport.queueForIdleConn()でコネクションプールに対して行い、コネクションがプールされていればそのコネクションを利用し、プールされていなければTransport.queueForDial()で新たにTCPコネクションを生成する要求（wantConn型）を発行します。

プールされていなかった場合、新たに作成するTCPコネクションを待ってもいいですし他のリクエストで使われていたコネクションがidleになったらそれを使ってもよいようになっているため、チャネル（wantConn.result）を使ってTCPコネクションの取得結果を待ちます。

1
func (t *Transport) getConn(treq *transportRequest, cm connectMethod) (_ *persistConn, err error) {
2
  ...
3
  w := &wantConn{
4
    cm:         cm,
5
    key:        cm.key(),
6
    ctx:        dialCtx,
7
    cancelCtx:  dialCancel,
8
    result:     make(chan connOrError, 1),
9
    beforeDial: testHookPrePendingDial,
10
    afterDial:  testHookPostPendingDial,
11
  }
12

13
    // コネクションプールに対してコネクション取得要求を発行
14
  if delivered := t.queueForIdleConn(w); !delivered {
15
        // プールされていない場合新たにTCPコネクションを生成
16
    t.queueForDial(w)
17
  }
18

19
    // コネクション取得結果を待つ
20
  select {
21
  case r := <-w.result:
22
    ...
23
    return r.pc, r.err
24
  ...
25
  }
26
}

cf. https://cs.opensource.google/go/go/+/refs/tags/go1.24.1:src/net/http/transport.go

Transport.queueForIdleConn()では、コネクションプールからコネクションを取得するか、プールされていない場合はコネクション待ち行列に追加します。また、HTTP Keep-Aliveが無効な場合にはプールという概念がないため、常に「プールから取得できなかった」とみなします。

この際、idleコネクションの最も新しいものからチェック・取得されます。

1
func (t *Transport) queueForIdleConn(w *wantConn) (delivered bool) {
2
  // Keep-Alive無効時にはプールという概念がない
3
  if t.DisableKeepAlives {
4
    return false
5
  }
6

7
  ...
8

9
  if list, ok := t.idleConn[w.key]; ok {
10
    ...
11
      // Keep-Alive有効の時にはidleコネクションの最も新しいものからチェック
12
    for len(list) > 0 && !stop {
13
      pconn := list[len(list)-1]
14

15
      ...
16

17
      delivered = w.tryDeliver(pconn, nil, pconn.idleAt)
18
      if delivered {
19
        if pconn.alt != nil {
20
                    ...
21
        } else {
22
                    ...
23
          t.idleLRU.remove(pconn)
24
          list = list[:len(list)-1]
25
        }
26
      }
27
      stop = true
28
    }
29
    ...
30
        // プールからコネクションを取得できたので早期リターン
31
    if stop {
32
      return delivered
33
    }
34
  }
35
    ...
36
  // 利用可能なidleコネクションがない場合にはidleコネクション待ち行列に追加
37
  q := t.idleConnWait[w.key]
38
    ...
39
  q.pushBack(w)
40
    ...
41
  return false
42
}

cf. https://cs.opensource.google/go/go/+/refs/tags/go1.24.1:src/net/http/transport.go

wantConn.tryDeliver()では、コネクションをチャネルに流し、Transport.getConn()に処理を戻します。 Transport.queueForIdleConn()ではプールから取得できた場合に即座に呼ばれる他、後ほど説明するTCPコネクション生成時にも呼ばれます。

1
func (w *wantConn) tryDeliver(pc *persistConn, err error, idleAt time.Time) bool {
2
  ...
3
  w.result <- connOrError{pc: pc, err: err, idleAt: idleAt}
4
  close(w.result)
5

6
  return true
7
}

cf. https://cs.opensource.google/go/go/+/refs/tags/go1.24.1:src/net/http/transport.go

さて、Keep-Aliveが無効であったりプールからコネクションを取得できなかった場合には、新たにTCPコネクションを生成する必要があります。これを行うのがTransport.getConn()から呼ばれるTransport.queueForDial()です。

この関数では、Transport.MaxConnsPerHostに設定されたホストあたりの最大接続数に達していない場合には新たにTCPコネクションを生成し、達している場合には待ち行列に追加します。

1
func (t *Transport) queueForDial(w *wantConn) {
2
  // コネクションの最大接続数が設定されていない場合には接続を開始する
3
  if t.MaxConnsPerHost <= 0 {
4
    t.startDialConnForLocked(w)
5
    return
6
  }
7

8
    // コネクションの最大接続数に達していない場合には接続を開始する
9
  if n := t.connsPerHost[w.key]; n < t.MaxConnsPerHost {
10
    ...
11
    t.connsPerHost[w.key] = n + 1
12
    t.startDialConnForLocked(w)
13
    return
14
  }
15

16
  // コネクションの最大接続数に達している場合には待ち行列に入れる
17
  ...
18
  q := t.connsPerHostWait[w.key]
19
    ...
20
  q.pushBack(w)
21
    ...
22
}

cf. https://cs.opensource.google/go/go/+/refs/tags/go1.24.1:src/net/http/transport.go

実際のTCPコネクション生成は複数の関数が直列に呼ばれることでなされますが、重要なのは2点で、

Transport.DialContext()でTCPコネクションを生成
生成したTCPコネクションをpersistConn型にセットしreadLoop/writeLoopをgoroutineで起動

です。

特に、persistConn.readLoop()とpersistConn.writeLoop()はTCPコネクションの読み書きを実際に行うための関数となっており、persistConn.roundTrip()とチャネル経由でやり取りを行います。

1
func (t *Transport) startDialConnForLocked(w *wantConn) {
2
  ...
3
  go func() {
4
    t.dialConnFor(w)
5
    ...
6
  }()
7
}
8

9
func (t *Transport) dialConnFor(w *wantConn) {
10
  ...
11
  pc, err := t.dialConn(ctx, w.cm)
12
  delivered := w.tryDeliver(pc, err, time.Time{})
13
  ...
14
}
15

16
func (t *Transport) dialConn(ctx context.Context, cm connectMethod) (pconn *persistConn, err error) {
17
  pconn = &persistConn{
18
    ...
19
  }
20

21
  ...
22

23
  if cm.scheme() == "https" && t.hasCustomTLSDialer() {
24
    ...
25
  } else {
26
    conn, err := t.dial(ctx, "tcp", cm.addr())
27
        ...
28
    pconn.conn = conn
29
    ...
30
  }
31

32
  ...
33

34
  go pconn.readLoop()
35
  go pconn.writeLoop()
36
  return pconn, nil
37
}
38

39
func (t *Transport) dial(ctx context.Context, network, addr string) (net.Conn, error) {
40
  if t.DialContext != nil {
41
    c, err := t.DialContext(ctx, network, addr)
42
    ...
43
    return c, err
44
  }
45
  ...
46
  return zeroDialer.DialContext(ctx, network, addr)
47
}

cf. https://cs.opensource.google/go/go/+/refs/tags/go1.24.1:src/net/http/transport.go

実際のコードは下のようになっており、persistConn.writech/reqch経由でreadLoop/writeLoopに要求を送信し、チャネルからレスポンスを受け取ります。

1
func (pc *persistConn) roundTrip(req *transportRequest) (resp *Response, err error) {
2
  ...
3
    // persistConn.writeLoop()にリクエストを送信
4
  pc.writech <- writeRequest{req, writeErrCh, continueCh}
5

6
    // persistConn.readLoop()にレスポンス要求を送信
7
  resc := make(chan responseAndError)
8
  pc.reqch <- requestAndChan{
9
        ...
10
    ch:         resc,
11
    ...
12
  }
13

14
  handleResponse := func(re responseAndError) (*Response, error) {
15
    ...
16
    return re.res, nil
17
  }
18

19
  ...
20
  for {
21
    ...
22
    select {
23
        ...
24
        // persistConn.readLoop()からのレスポンスを受信
25
    case re := <-resc:
26
      return handleResponse(re)
27
        ...
28
    }
29
  }
30
}

cf. https://cs.opensource.google/go/go/+/refs/tags/go1.24.1:src/net/http/transport.go

persistConn.writeLoop()では、persistConn.writechに送られたリクエスト送信要求をひたすら送信し続けます。

1
func (pc *persistConn) writeLoop() {
2
  ...
3
  for {
4
    select {
5
    case wr := <-pc.writech:
6
      ...
7
      err := wr.req.Request.write(pc.bw, pc.isProxy, wr.req.extra, pc.waitForContinue(wr.continueCh))
8
      ...
9
      if err != nil {
10
        pc.close(err)
11
        return
12
      }
13
    case <-pc.closech:
14
      return
15
    }
16
  }
17
}

cf. https://cs.opensource.google/go/go/+/refs/tags/go1.24.1:src/net/http/transport.go

persistConn.readLoop()では、persistConn.reqchに送られたレスポンス要求を受信し、実際にコネクションからHTTPレスポンスを取得しレスポンス要求に応えます。また、適切なタイミング（後述）でTransport.tryPutIdleConn()を呼び出すことで、このコネクションをidleコネクションプールに戻します。

1
func (pc *persistConn) readLoop() {
2
  ...
3

4
    // idleコネクションプールへ戻すための一時関数
5
  tryPutIdleConn := func(treq *transportRequest) bool {
6
    ...
7
    if err := pc.t.tryPutIdleConn(pc); err != nil {
8
      ...
9
      return false
10
    }
11
    ...
12
    return true
13
  }
14

15
  ...
16

17
  for alive {
18
    ...
19
        // persistConn.roundTrip()からのレスポンス要求を受信
20
    rc := <-pc.reqch
21
        ...
22

23
    var resp *Response
24
    if err == nil {
25
            // 実際にコネクションからHTTPレスポンスを取得
26
      resp, err = pc.readResponse(rc, trace)
27
    } else {
28
      ...
29
    }
30

31
    ...
32

33
    select {
34
        // persistConn.roundTrip()にHTTPレスポンス要求への返答を送信
35
    case rc.ch <- responseAndError{res: resp}:
36
        ...
37
    }
38

39
        // 適宜tryPutIdleConn()が呼ばれる
40

41
    ...
42
  }
43
}

cf. https://cs.opensource.google/go/go/+/refs/tags/go1.24.1:src/net/http/transport.go

transport.tryPutIdleConn()では、コネクションをidleコネクションプールに戻します。

1
func (t *Transport) tryPutIdleConn(pconn *persistConn) error {
2
  ...
3

4
    // idleコネクション待ち行列にコネクションを渡す
5
  key := pconn.cacheKey
6
  if q, ok := t.idleConnWait[key]; ok {
7
    done := false
8
    if pconn.alt == nil {
9
      ...
10
      for q.len() > 0 {
11
        w := q.popFront()
12
        if w.tryDeliver(pconn, nil, time.Time{}) {
13
          done = true
14
          break
15
        }
16
      }
17
    } else {
18
      ...
19
    }
20
    ...
21
  }
22

23
  ...
24
    // idleコネクション数上限を超えていた場合には最古のコネクションを切断
25
  t.idleConn[key] = append(idles, pconn)
26
  t.idleLRU.add(pconn)
27
  if t.MaxIdleConns != 0 && t.idleLRU.len() > t.MaxIdleConns {
28
    oldest := t.idleLRU.removeOldest()
29
    oldest.close(errTooManyIdle)
30
    t.removeIdleConnLocked(oldest)
31
  }
32

33
  // idleTimeoutをリセットする
34
  if t.IdleConnTimeout > 0 && pconn.alt == nil {
35
    if pconn.idleTimer != nil {
36
      pconn.idleTimer.Reset(t.IdleConnTimeout)
37
    } else {
38
      pconn.idleTimer = time.AfterFunc(t.IdleConnTimeout, pconn.closeConnIfStillIdle)
39
    }
40
  }
41
  pconn.idleAt = time.Now()
42
  return nil
43
}

cf. https://cs.opensource.google/go/go/+/refs/tags/go1.24.1:src/net/http/transport.go

一通りnet/httpのHTTPクライアントの実装を見てきましたが、この実装を元に疑問を解消していきます。

疑問1: Transport.idleConnTimeoutよりも前に再利用し続けるとどうなるのか？

HTTP Keep-Alive関連の設定として、ClientのidleConnTimeoutフィールドのドキュメントには、以下のように継続してidleである時間がこの設定を超えるとコネクションが切断されると書かれています。

1
  // IdleConnTimeout is the maximum amount of time an idle
2
  // (keep-alive) connection will remain idle before closing
3
  // itself.
4
  // Zero means no limit.
5
    IdleConnTimeout time.Duration

しかし、Keep-Aliveヘッダのmaxディレクティブのようなコネクションの利用回数の上限や、idleであったかにかかわらずコネクションの生存期間で制限はないのでしょうか？ドキュメントを見る限りそのような制限の設定はないように見えますが、実際のところを確かめてみます。

実験用にHTTPサーバとHTTPクライアントを用意し、HTTPクライアントからHTTPサーバに定期的にリクエストを送信するようにします。クライアントではIdleConnTimeoutを90sに設定し、クライアントの自発的な挙動を確かめるためにサーバではHTTP Keep-Aliveタイムアウトを無限に設定します。

1
package main
2

3
...
4

5
func main() {
6
        client := &http.Client{
7
                Transport: &http.Transport{
8
                        DialContext: (&net.Dialer{
9
                                Timeout: 30 * time.Second,
10
                        }).DialContext,
11
                        ForceAttemptHTTP2:     true,
12
                        MaxIdleConns:          1,
13
                        IdleConnTimeout:       90 * time.Second,
14
                        TLSHandshakeTimeout:   10 * time.Second,
15
                        ExpectContinueTimeout: 1 * time.Second,
16
                },
17
        }
18

19
        req, err := http.NewRequest("GET", url, nil)
20
        if err != nil {
21
                fmt.Printf("Error creating request: %v\n", err)
22
                return
23
        }
24

25
        go func() {
26
                for {
27
                        doReq(client, req)
28
                        time.Sleep(5 * time.Second)
29
                }
30
        }()
31
        ...
32
}
33

34
func doReq(client *http.Client, req *http.Request) {
35
        resp, err := client.Do(req)
36
        if err != nil {
37
                fmt.Printf("Error making GET request: %v\n", err)
38
                return
39
        }
40
        defer resp.Body.Close()
41

42
        body, err := io.ReadAll(resp.Body)
43
        if err != nil {
44
                fmt.Printf("Error reading response body: %v\n", err)
45
                return
46
        }
47
        ...
48
}

1
package main
2

3
...
4

5
func main() {
6
        ...
7
        http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
8
                w.Header().Set("Content-Type", "text/plain")
9
                w.WriteHeader(http.StatusOK)
10
                w.Write([]byte("Hello, World!"))
11
        })
12

13
        server := &http.Server{
14
                Addr:        ":8080",
15
                Handler:     http.DefaultServeMux,
16
                IdleTimeout: 0 * time.Second,
17
        }
18

19
        listener, err := net.Listen("tcp", server.Addr)
20
        if err != nil {
21
                fmt.Printf("Error creating listener: %v\n", err)
22
                return
23
        }
24

25
        if err := server.Serve(listener); err != nil {
26
                fmt.Printf("Server error: %v\n", err)
27
        }
28
        ...
29
}

実際に試してみると、しばらく（1h以上経過させてみた）経ってもHTTPリクエスト時に新たなTCPコネクションが生成されることはなく、同じコネクションが再利用され続けることが確認できました。パケットキャプチャ

実機での挙動を確認したので、次は実装上でも同じ結論となるかを見ていきます。

Transport.tryPutIdleConn()では利用していたコネクションをidleコネクションプールに戻す際に、IdleConnTimeoutだけ経った後にpersistConn.closeConnIfStillIdle()を呼び出すタイマーをセット/リセットしています。タイマーが発火する前にコネクションが使用され再びidleコネクションプールに戻されるとタイマーはリセットされます。また、コネクション使用中にタイマーが発火した場合でも、この関数がコネクションを切断するのはidleの場合のみなので切断はされません。

1
func (t *Transport) tryPutIdleConn(pconn *persistConn) error {
2
  ...
3
  if t.IdleConnTimeout > 0 && pconn.alt == nil {
4
    if pconn.idleTimer != nil {
5
      pconn.idleTimer.Reset(t.IdleConnTimeout)
6
    } else {
7
      pconn.idleTimer = time.AfterFunc(t.IdleConnTimeout, pconn.closeConnIfStillIdle)
8
    }
9
  }
10
  pconn.idleAt = time.Now()
11
  return nil
12
}
13

14
func (pc *persistConn) closeConnIfStillIdle() {
15
  ...
16
  if _, ok := t.idleLRU.m[pc]; !ok {
17
    // Not idle.
18
    return
19
  }
20
  ...
21
}

つまり、IdleConnTimeoutよりも前に再利用し続ければ、コネクションは切断されることはないということです。

疑問2: HTTPリクエストをcontextでキャンセルするとTCPコネクションは再利用されるのか？

本格的なアプリケーションを作る際には、タイムアウトなどによってHTTPリクエストをキャンセルすることがあります。その際にはcontextのキャンセルを使うことが多いかと思いますが、この場合にTCPコネクションは再利用されるのでしょうか？

まずは実際に試してみます。疑問1とほぼ同じコードにリクエストのキャンセルを行うためにcontextを追加し、1sでリクエストをキャンセルする処理を追加しました。

1
func doReq(client *http.Client, req *http.Request) {
2
        ctx, cancel := context.WithTimeout(context.Background(), 1*time.Second)
3
        defer cancel()
4

5
        req = req.WithContext(ctx)
6

7
        resp, err := client.Do(req)
8
        if err != nil {
9
                fmt.Printf("Error making GET request: %v\n", err)
10
                return
11
        }
12
        defer resp.Body.Close()
13

14
        body, err := io.ReadAll(resp.Body)
15
        if err != nil {
16
                fmt.Printf("Error reading response body: %v\n", err)
17
                return
18
        }
19
        ...
20
}

予想ではキャンセルされたらコネクションはidleコネクションプールに戻るだろうと思っていましたが、実際に試してみるとコネクションは切断されました。さらに、リクエストをキャンセルしたタイミングではサーバー側からのFINは送られず、レスポンスが送られた後でFINが送られていました。後者の挙動についてはサーバー側の実装に起因するので取り上げませんが、前者の挙動については実装を見ていきます。パケットキャプチャ

persistConn.roundTrip()においては、レスポンスを待つselect-caseにおいて、context.Done()を受け取ると、persistConn.cancelRequest()が呼ばれます。

1
func (pc *persistConn) roundTrip(req *transportRequest) (resp *Response, err error) {
2
  ...
3
  ctxDoneChan := req.ctx.Done()
4
  pcClosed := pc.closech
5
  for {
6
    ...
7
    select {
8
    ...
9
        case re := <-resc:
10
      return handleResponse(re)
11
    case <-ctxDoneChan:
12
      ...
13
      pc.cancelRequest(context.Cause(req.ctx))
14
    }
15
  }
16
}

persistConn.cancelRequest()では、persistConn.closeLocked()によってTCPコネクションが切断されています。

1
func (pc *persistConn) cancelRequest(err error) {
2
  ...
3
  pc.closeLocked(errRequestCanceled)
4
}
5

6
func (pc *persistConn) closeLocked(err error) {
7
  ...
8
  if pc.closed == nil {
9
    ...
10
    // Close HTTP/1 (pc.alt == nil) connection.
11
    // HTTP/2 closes its connection itself.
12
    if pc.alt == nil {
13
      if err != errCallerOwnsConn {
14
        pc.conn.Close()
15
      }
16
      close(pc.closech)
17
    }
18
  }
19
  ...
20
}

つまり、コネクションがidleコネクションプールに戻ることはなく、キャンセルされたリクエストに対してはコネクションが切断されることがわかりました。

疑問3: Response.BodyはEOFまで読んだ上でCloseする必要があるとされるがやらないとどうなるのか？

公式ドキュメントの記述では、Response.Bodyは必ずEOFまで読んだ上でCloseする必要があるとされており、その理由としてコネクションの再利用が妨げられるからとしています。

1
  // ...
2
  // The http Client and Transport guarantee that Body is always
3
  // non-nil, even on responses without a body or responses with
4
  // a zero-length body. It is the caller's responsibility to
5
  // close Body. The default HTTP client's Transport may not
6
  // reuse HTTP/1.x "keep-alive" TCP connections if the Body is
7
  // not read to completion and closed.
8
  // ...
9
  Body io.ReadCloser

cf. http package - net/http - Go Packages

他の記事でもこの点については注意するべき点として挙げられている他、実装面から見ている記事もありました。そこでこの記事ではより詳細まで踏み込んで、ネットワークレイヤにまで踏み込んでこの挙動を確認してみます。またKeep-Aliveのオンオフ・EOFまで読むか・BodyをCloseするかという条件を網羅的に検証してみます。

そのために、EOFまで読むか、BodyをCloseするかという条件を変えた4つの関数を用意し、さらにClient側でKeep-Aliveを有効にするかどうかも変えて検証します。つまり条件としては合計8通りとなりますが、このうちEOFまで読んだ上でCloseをするものについてはいわば正常系であり特筆すべき点はないため省略し、最終的に6通りについて検証します

1
// EOFまで読んでCloseする
2
func doReq(client *http.Client, req *http.Request) {
3
        resp, err := client.Do(req)
4
        if err != nil {
5
                fmt.Printf("Error making GET request: %v\n", err)
6
                return
7
        }
8
        defer resp.Body.Close()
9

10
        body, err := io.ReadAll(resp.Body)
11
        if err != nil {
12
                fmt.Printf("Error reading response body: %v\n", err)
13
                return
14
        }
15
        ...
16
}
17

18
// EOFまで読まずCloseもしない
19
func doReqNotReadEOFWithoutClose(client *http.Client, req *http.Request) {
20
        _, err := client.Do(req)
21
        if err != nil {
22
                fmt.Printf("Error making GET request: %v\n", err)
23
                return
24
        }
25
}
26

27
// EOFまで読んでCloseしない
28
func doReqWithoutClose(client *http.Client, req *http.Request) {
29
        resp, err := client.Do(req)
30
        if err != nil {
31
                fmt.Printf("Error making GET request: %v\n", err)
32
                return
33
        }
34

35
        _, err = io.ReadAll(resp.Body)
36
        if err != nil {
37
                fmt.Printf("Error reading response body: %v\n", err)
38
                return
39
        }
40
}
41

42
// EOFまで読まずCloseはする
43
func doReqNotReadEOF(client *http.Client, req *http.Request) {
44
        resp, err := client.Do(req)
45
        if err != nil {
46
                fmt.Printf("Error making GET request: %v\n", err)
47
                return
48
        }
49
        defer resp.Body.Close()
50

51
}

3-1: Keep-Alive有効・EOFまで読まずCloseもしない

公式ドキュメントでも警告されている通り、この条件ではコネクションの再利用が妨げられています。さらに、パケットキャプチャやソケットの状態をみると、使いまわされなかったコネクションは接続されたまま残り続けていることがわかります。これはサーバー側・クライアント側ともにファイルディスクリプタややリソースを消費し続けることに繋がってしまいます。パケットキャプチャ

1
❯ netstat -an -p tcp -f inet | grep 8080
2
tcp4       0      0  10.18.53.59.8080       10.18.53.59.52239      ESTABLISHED
3
tcp4       0      0  10.18.53.59.52239      10.18.53.59.8080       ESTABLISHED
4
tcp4       0      0  10.18.53.59.8080       10.18.53.59.52238      ESTABLISHED
5
tcp4       0      0  10.18.53.59.52238      10.18.53.59.8080       ESTABLISHED
6
tcp4       0      0  10.18.53.59.8080       10.18.53.59.52237      ESTABLISHED
7
tcp4       0      0  10.18.53.59.52237      10.18.53.59.8080       ESTABLISHED
8
tcp4       0      0  10.18.53.59.8080       10.18.53.59.52236      ESTABLISHED
9
tcp4       0      0  10.18.53.59.52236      10.18.53.59.8080       ESTABLISHED
10
tcp4       0      0  10.18.53.59.8080       10.18.53.59.52235      ESTABLISHED
11
tcp4       0      0  10.18.53.59.52235      10.18.53.59.8080       ESTABLISHED
12
tcp4       0      0  10.18.53.59.8080       10.18.53.59.52234      ESTABLISHED
13
tcp4       0      0  10.18.53.59.52234      10.18.53.59.8080       ESTABLISHED
14
tcp46      0      0  *.8080                 *.*                    LISTEN

3-2: Keep-Alive有効・EOFまで読んでCloseはしない

それではCloseはしないもののEOFまではしっかりと読む場合はどうでしょうか？

実際に試してみると、どうもコネクションはしっかりと再利用されているようです。

1
❯ netstat -an -p tcp -f inet | grep 8080
2
tcp4       0      0  10.18.53.59.8080       10.18.53.59.52300      ESTABLISHED
3
tcp4       0      0  10.18.53.59.52300      10.18.53.59.8080       ESTABLISHED
4
tcp46      0      0  *.8080                 *.*                    LISTEN

3-3: Keep-Alive有効・EOFまで読まずCloseはする

逆にEOFまでは読まないもののCloseはする場合をみてみましょう。

EOFまで読まずCloseしない場合と似たように、コネクションの再利用は妨げられているようですが、コネクションが残り続けるということはないようです。

1
❯ netstat -an -p tcp -f inet | grep 8080
2
tcp4       0      0  10.18.53.59.8080       10.18.53.59.52268      ESTABLISHED
3
tcp4       0      0  10.18.53.59.52268      10.18.53.59.8080       ESTABLISHED
4
tcp46      0      0  *.8080                 *.*                    LISTEN
5
tcp4       0      0  10.18.53.59.52265      10.18.53.59.8080       TIME_WAIT
6
tcp4       0      0  10.18.53.59.52266      10.18.53.59.8080       TIME_WAIT
7
tcp4       0      0  10.18.53.59.52267      10.18.53.59.8080       TIME_WAIT

ここまでの結果をみる限りでは、Keep-Aliveが有効である場合にはEOFまで読むことでコネクションが適切に再利用されるようです。

3-4: Keep-Alive無効・EOFまで読まずCloseもしない

ここからは、Keep-Aliveを無効にした場合について検証していきます。 EOFまで読まずCloseもしない場合については、コネクションが残り続けることがわかります。ただし残り続けるといってもESTABLISHED状態ではなく、サーバー側ではFIN_WAIT_2状態・クライアント側ではCLOSE_WAIT状態となっていることがわかります。

これはつまり、クライアント側がコネクションの切断をしないままになっていることを示しています。

1
❯ netstat -an -p tcp -f inet | grep 8080
2
tcp4       0      0  10.18.53.59.8080       10.18.53.59.52356      FIN_WAIT_2
3
tcp4       0      0  10.18.53.59.52356      10.18.53.59.8080       CLOSE_WAIT
4
tcp4       0      0  10.18.53.59.8080       10.18.53.59.52355      FIN_WAIT_2
5
tcp4       0      0  10.18.53.59.52355      10.18.53.59.8080       CLOSE_WAIT
6
tcp4       0      0  10.18.53.59.8080       10.18.53.59.52354      FIN_WAIT_2
7
tcp4       0      0  10.18.53.59.52354      10.18.53.59.8080       CLOSE_WAIT
8
tcp4       0      0  10.18.53.59.8080       10.18.53.59.52353      FIN_WAIT_2
9
tcp4       0      0  10.18.53.59.52353      10.18.53.59.8080       CLOSE_WAIT
10
tcp4       0      0  10.18.53.59.8080       10.18.53.59.52352      FIN_WAIT_2
11
tcp4       0      0  10.18.53.59.52352      10.18.53.59.8080       CLOSE_WAIT
12
tcp46      0      0  *.8080                 *.*                    LISTEN

3-5: Keep-Alive無効・EOFまで読んでCloseはしない

CloseをしないもののEOFまで読む場合については、サーバー側・クライアント側ともに切断に至っており、コネクションがそのままになることはないようです。

1
❯ netstat -an -p tcp -f inet | grep 8080
2
tcp4       0      0  10.18.53.59.8080       10.18.53.59.52399      ESTABLISHED
3
tcp4       0      0  10.18.53.59.52399      10.18.53.59.8080       ESTABLISHED
4
tcp46      0      0  *.8080                 *.*                    LISTEN
5
tcp4       0      0  10.18.53.59.8080       10.18.53.59.52395      TIME_WAIT
6
tcp4       0      0  10.18.53.59.8080       10.18.53.59.52396      TIME_WAIT
7
tcp4       0      0  10.18.53.59.8080       10.18.53.59.52398      TIME_WAIT

3-6: Keep-Alive無効・EOFまで読まずCloseはする

逆の場合を試してみます。

コネクションの再利用が妨げられていたKeep-Alive有効の場合とは異なり、正しい挙動をしているようです。

1
❯ netstat -an -p tcp -f inet | grep 8080
2
tcp4       0      0  10.18.53.59.8080       10.18.53.59.52419      ESTABLISHED
3
tcp4       0      0  10.18.53.59.52419      10.18.53.59.8080       ESTABLISHED
4
tcp46      0      0  *.8080                 *.*                    LISTEN
5
tcp4       0      0  10.18.53.59.8080       10.18.53.59.52416      TIME_WAIT
6
tcp4       0      0  10.18.53.59.8080       10.18.53.59.52417      TIME_WAIT
7
tcp4       0      0  10.18.53.59.8080       10.18.53.59.52418      TIME_WAIT

Keep-Aliveが無告である場合には、EOFまで読むかCloseをするかのどちらかをすることでコネクションは適切に切断されるようです。

3-まとめ

まとめると以下のような挙動となりました。とりあえずはEOFまで読んでおけば所望の挙動が達成されるようで、CloseするのはEOFまで読まなかった場合のコネクションリークを防ぐ効果があるようです。

	Keep-Alive無効	Keep-Alive有効
EOFまで読まずCloseもしない	切断処理の途中でスタックしコネクションが残り続ける	コネクションが残り続けてkeep-aliveされない
EOFまで読むがCloseはしない	コネクションは切断される	keep-aliveされる
EOFまで読まずCloseはする	コネクションは切断される	コネクションが切断されてkeep-aliveされない
EOFまで読みCloseする	コネクションは切断される	keep-aliveされる

3-実装

実機の挙動を確認したので、次は実装上でも同じ結論となるかを見ていきます。 Response.BodyのCloseやEOFまでの読み込みについては、persistConn.readLoop()内をみるのが良いです。

どうもResponse.Bodyとしてセットされているのは、bodyEOFSignalという構造体のようです。

1
func (pc *persistConn) readLoop() {
2
  ...
3

4
  alive := true
5
  for alive {
6
    ...
7

8
    waitForBodyRead := make(chan bool, 2)
9
    body := &bodyEOFSignal{
10
      ...
11
    }
12

13
    resp.Body = body
14
    ...
15
  }
16
}

この構造体はio.ReadCloserを実装しており、Read()でEOF含むエラーが発生した場合・Close()された場合にfnフィールドの関数が最大1回呼ばれます。また、EOFエラーが発生する前にClose()された場合には代わりにearlyCloseFnフィールドの関数が呼ばれます。

1
type bodyEOFSignal struct {
2
  body         io.ReadCloser
3
  mu           sync.Mutex        // guards following 4 fields
4
  closed       bool              // whether Close has been called
5
  rerr         error             // sticky Read error
6
  fn           func(error) error // err will be nil on Read io.EOF
7
  earlyCloseFn func() error      // optional alt Close func used if io.EOF not seen
8
}
9

10
...
11

12
func (es *bodyEOFSignal) Read(p []byte) (n int, err error) {
13
  ...
14
  n, err = es.body.Read(p)
15
  if err != nil {
16
    ...
17
    err = es.condfn(err)
18
  }
19
  return
20
}
21

22
func (es *bodyEOFSignal) Close() error {
23
  ...
24
  if es.earlyCloseFn != nil && es.rerr != io.EOF {
25
    return es.earlyCloseFn()
26
  }
27
  err := es.body.Close()
28
  return es.condfn(err)
29
}
30

31
func (es *bodyEOFSignal) condfn(err error) error {
32
  ...
33
  err = es.fn(err)
34
  es.fn = nil
35
  return err
36
}

この挙動を踏まえてもう一度persistConn.readLoop()をみてみると、

EOFまで読まずCloseもしない場合：earlyCloseFnもfnも呼ばれず、waitForBodyReadチャネルはブロックし続ける
- Keep-Alive有効であればtryPutIdleConn()が呼ばれずコネクションは再利用されず、Keep-Alive無効であればdeferなclose()が呼ばれず自発的にFINを送らない
EOFまで読むがCloseはしない場合：fnが呼ばれwaitForBodyReadチャネルにはtrueが返るためブロックされずtryPutIdleConn()が呼ばれる
EOFまで読まずCloseはする場合：earlyCloseFnが呼ばれwaitForBodyReadチャネルにはfalseが返るためtryPutIdleConn()が呼ばれない
- ブロックされないためKeep-Alive無効な場合はコネクションが切断されるが、Keep-Alive有効な場合にはコネクションの再利用が妨げられる
EOFまで読みCloseする場合：fnが呼ばれwaitForBodyReadチャネルにはtrueが返るためブロックされずtryPutIdleConn()が呼ばれる

という挙動をとることがわかり、実機で確かめた挙動と一致しています。

1
func (pc *persistConn) readLoop() {
2
  closeErr := errReadLoopExiting // default value, if not changed below
3
  defer func() {
4
    pc.close(closeErr)
5
    pc.t.removeIdleConn(pc)
6
  }()
7

8
  ...
9
  eofc := make(chan struct{})
10
  defer close(eofc) // unblock reader on errors
11

12
  ...
13
  for alive {
14
    ...
15

16
    waitForBodyRead := make(chan bool, 2)
17
    body := &bodyEOFSignal{
18
      body: resp.Body,
19
      earlyCloseFn: func() error {
20
        waitForBodyRead <- false
21
        <-eofc // will be closed by deferred call at the end of the function
22
        return nil
23

24
      },
25
      fn: func(err error) error {
26
        isEOF := err == io.EOF
27
        waitForBodyRead <- isEOF
28
        if isEOF {
29
          <-eofc // see comment above eofc declaration
30
        } else if err != nil {
31
          if cerr := pc.canceled(); cerr != nil {
32
            return cerr
33
          }
34
        }
35
        return err
36
      },
37
    }
38

39
    resp.Body = body
40
    ...
41
    select {
42
    case bodyEOF := <-waitForBodyRead:
43
            // bodyEOFがfalseだと短絡評価されtryPutIdleConn()が呼ばれない
44
      alive = alive &&
45
        bodyEOF &&
46
        !pc.sawEOF &&
47
        pc.wroteRequest() &&
48
        tryPutIdleConn(rc.treq)
49
      if bodyEOF {
50
        eofc <- struct{}{}
51
      }
52
    ...
53
    }
54
        ...
55
  }
56
}

まとめ

非常に長くなってしまいましたが、この記事ではnet/httpのHTTPクライアントの実装を追うことで、「こういう時ってどうなるんだっけ？」という挙動を確認することができました。やはり実装を追うのは大事ですね。