■前提
FLBのキープアライブ、アイドルタイムについて実際のパケットを見ながら理解を深めたいと思ったのがきっかけです。
-
キープアライブ：（＝httpキープアライブ）TCPコネクション上で動くhttpがそのTCPを再利用するかどうか
httpのリクエストヘッダをよく見てみると、以下のようなConnectionフィールドをよく見かけます。
Connection: keep-alive（TCPコネクションを切らずにそのあともhttpでも使う）
Connection: close（httpの処理が終わるとTCPコネクションを切る） -
アイドルタイムアウト：一定時間何も送られていないと切る
これを踏まえて、FLBのキープアライブ、アイドルタイムアウトのドキュメントを見ると、
ロード・バランサ・サービスは、10,000トランザクションの接続を保持するか、65秒間アイドル状態が継続するように(いずれか早い方の制限による)キープ・アライブ値を設定します。
TCPまたはHTTPリスナーを作成または編集する場合、「アイドル・タイムアウト(秒)」オプションを使用して最大アイドル時間を秒単位で指定できます。
この秒数で接続がクローズになると思いますが、それをパケットキャプチャで実際に見てみます。
■構成
- OSはOL8
- リスナーとバックエンドへhttpポート80で接続する
- WebサーバはApache
- FLBのヘルスチェックはパケットキャプチャで邪魔だったので別の22番ポートにしたり、ヘルスチェック間隔を長くしたり、「フェイルオープン」でヘルスチェックに失敗してもそのバックエンドに通信させるなど行った
- クライアントとWebサーバでパケットキャプチャを行う
■キープアライブが65秒の検証
構成情報と結果
- リスナーはhttp
- ncコマンドでFLBに対し80番ポートを開けて、httpリクエストを投げる
- Connectionフィールドはkeep-alive
- すぐにレスポンスが返ってくる
- そのまま放置
- 65秒後、クライアントとFLBのTCPコネクションをFLB側から切断
→ドキュメント通り、httpヘッダのConnection:keep-aliveにしたまま65秒経つと切断した。
クライアント側のhttpリクエスト
[opc@aksaka0630-843203 ~]$ nc 10.1.20.5 80
GET / HTTP/1.1
Host: 10.1.20.5
Connection: keep-alive
★エンターを押すとhttpリクエスト送信
HTTP/1.1 200 OK
Date: Thu, 02 Oct 2025 07:51:48 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 25
Connection: keep-alive
Set-Cookie: X-Oracle-BMC-LBS-Route=1807ed18a3b6f68c3e9284f17ca7f108104d5e9f; Path=/
Last-Modified: Wed, 25 Jun 2025 09:00:31 GMT
ETag: "19-63861ad55555f"
Accept-Ranges: bytes
X-Request-Id: 9af1cd217fab31d8d60a9419f4780150
Web Server 2 (host:web2)
★レスポンスが返ってきてこのまま放置
クライアント側のパケットキャプチャ
クライアント：10.1.0.132
FLBリスナーのIPアドレス：10.1.20.5
07:51:42.020585 IP 10.1.0.132.49760 > 10.1.20.5.80: Flags [S], seq 2133055581, win 62720, options [mss 8960,sackOK,TS val 2610428904 ecr 0,nop,wscale 7], length 0
07:51:42.023154 IP 10.1.20.5.80 > 10.1.0.132.49760: Flags [S.], seq 3051355037, ack 2133055582, win 62636, options [mss 8960,sackOK,TS val 3837583360 ecr 2610428904,nop,wscale 10], length 0
07:51:42.023199 IP 10.1.0.132.49760 > 10.1.20.5.80: Flags [.], ack 1, win 490, options [nop,nop,TS val 2610428906 ecr 3837583360], length 0
07:51:47.562617 IP 10.1.0.132.49760 > 10.1.20.5.80: Flags [P.], seq 1:16, ack 1, win 490, options [nop,nop,TS val 2610434446 ecr 3837583360], length 15: HTTP: GET / HTTP/1.1
07:51:47.563454 IP 10.1.20.5.80 > 10.1.0.132.49760: Flags [.], ack 16, win 62, options [nop,nop,TS val 3837588901 ecr 2610434446], length 0
07:51:47.563472 IP 10.1.0.132.49760 > 10.1.20.5.80: Flags [P.], seq 16:32, ack 1, win 490, options [nop,nop,TS val 2610434447 ecr 3837588901], length 16: HTTP
07:51:47.563763 IP 10.1.20.5.80 > 10.1.0.132.49760: Flags [.], ack 32, win 62, options [nop,nop,TS val 3837588902 ecr 2610434447], length 0
07:51:48.184070 IP 10.1.0.132.49760 > 10.1.20.5.80: Flags [P.], seq 32:55, ack 1, win 490, options [nop,nop,TS val 2610435067 ecr 3837588902], length 23: HTTP
07:51:48.184353 IP 10.1.20.5.80 > 10.1.0.132.49760: Flags [.], ack 55, win 62, options [nop,nop,TS val 3837589522 ecr 2610435067], length 0
07:51:48.894077 IP 10.1.0.132.49760 > 10.1.20.5.80: Flags [P.], seq 55:56, ack 1, win 490, options [nop,nop,TS val 2610435777 ecr 3837589522], length 1: HTTP
07:51:48.894371 IP 10.1.20.5.80 > 10.1.0.132.49760: Flags [.], ack 56, win 62, options [nop,nop,TS val 3837590232 ecr 2610435777], length 0
07:51:48.897888 IP 10.1.20.5.80 > 10.1.0.132.49760: Flags [P.], seq 1:393, ack 56, win 62, options [nop,nop,TS val 3837590236 ecr 2610435777], length 392: HTTP: HTTP/1.1 200 OK
07:51:48.897902 IP 10.1.0.132.49760 > 10.1.20.5.80: Flags [.], ack 393, win 487, options [nop,nop,TS val 2610435781 ecr 3837590236], length 0
★レスポンス後、65秒で切断↓
07:52:53.899289 IP 10.1.20.5.80 > 10.1.0.132.49760: Flags [F.], seq 393, ack 56, win 62, options [nop,nop,TS val 3837655236 ecr 2610435781], length 0
07:52:53.939342 IP 10.1.0.132.49760 > 10.1.20.5.80: Flags [.], ack 394, win 487, options [nop,nop,TS val 2610500823 ecr 3837655236], length 0
(展開ください) Webサーバ側のパケットキャプチャ
FLBバックエンド通信用のIPアドレス：10.1.20.6
WebサーバのIPアドレス：10.1.1.80
07:51:48.895933 IP 10.1.20.6.35662 > 10.1.1.80.80: Flags [S], seq 136779706, win 62720, options [mss 8960,sackOK,TS val 2704906294 ecr 0,nop,wscale 10], length 0
07:51:48.896008 IP 10.1.1.80.80 > 10.1.20.6.35662: Flags [S.], seq 3558736390, ack 136779707, win 62636, options [mss 8960,sackOK,TS val 2427049104 ecr 2704906294,nop,wscale 7], length 0
07:51:48.896869 IP 10.1.20.6.35662 > 10.1.1.80.80: Flags [P.], seq 1:215, ack 1, win 62, options [nop,nop,TS val 2704906296 ecr 2427049104], length 214: HTTP: GET / HTTP/1.1
07:51:48.896897 IP 10.1.1.80.80 > 10.1.20.6.35662: Flags [.], ack 215, win 488, options [nop,nop,TS val 2427049105 ecr 2704906296], length 0
07:51:48.897373 IP 10.1.1.80.80 > 10.1.20.6.35662: Flags [P.], seq 1:281, ack 215, win 488, options [nop,nop,TS val 2427049105 ecr 2704906296], length 280: HTTP: HTTP/1.1 200 OK
07:51:48.897519 IP 10.1.20.6.35662 > 10.1.1.80.80: Flags [.], ack 1, win 62, options [nop,nop,TS val 2704906296 ecr 2427049104], length 0
07:51:48.897545 IP 10.1.1.80.80 > 10.1.20.6.35662: Flags [.], ack 215, win 488, options [nop,nop,TS val 2427049105 ecr 2704906296], length 0
07:51:48.897810 IP 10.1.20.6.35662 > 10.1.1.80.80: Flags [.], ack 281, win 62, options [nop,nop,TS val 2704906297 ecr 2427049105], length 0
★5秒後に切っている
07:51:53.901694 IP 10.1.1.80.80 > 10.1.20.6.35662: Flags [F.], seq 281, ack 215, win 488, options [nop,nop,TS val 2427054110 ecr 2704906297], length 0
07:51:53.904103 IP 10.1.20.6.35662 > 10.1.1.80.80: Flags [F.], seq 215, ack 282, win 62, options [nop,nop,TS val 2704911302 ecr 2427054110], length 0
07:51:53.904131 IP 10.1.1.80.80 > 10.1.20.6.35662: Flags [.], ack 216, win 488, options [nop,nop,TS val 2427054112 ecr 2704911302], length 0
■アイドルタイムアウトの検証の準備
アイドルタイムアウトを検証するためにどのような設定をすればいいのでしょうか。
リクエストを送ってレスポンスを遅くすればアイドルタイムアウトに引っかかるのではないかと考え、そのような構成を作ってみます。
Apacheの構成
私はWebサーバの設定に自信がないので作ってもらいました。
mod_luaモジュールというものを構成するとレスポンスを遅くできるようです。
10.1.1.80/slowに遅延秒数を書いたリクエストを投げると、その秒数だけ待つような構成です。
(展開ください) Apacheの構成メモ
ロード済みモジュールの確認でluaモジュールがあるか
[opc@web2 ~]$ sudo httpd -M | grep lua || ture
lua_module (shared)
遅延用のluaハンドラ作成（ハンドラ：ファイルが呼ばれたときに実行される動作のApacheにおける内部表現）
[opc@web2 ~]$ sudo tee /var/www/slow.lua >/dev/null <<'LUA'
function handle(r)
r.content_type = "text/plain"
local GET = r:parseargs()
local delay = tonumber(GET["delay"]) or 5
if delay < 0 then delay = 0 end
r:puts(("sleeping for %s seconds...\n"):format(delay))
r:flush()
-- μ秒スリープ
r.usleep(delay * 1000000)
r:puts("done\n")
return apache2.OK
end
LUA
エンドポイント /slowにマッピング
[opc@web2 ~]$ sudo tee /etc/httpd/conf.d/slow.conf >/dev/null <<'CONF'
# /slow に来たリクエストを /var/www/slow.lua の handle() で処理
LuaMapHandler "/slow" "/var/www/slow.lua" "handle"
CONF
リロード
sudo httpd -t && sudo systemctl reload httpd
FLBの構成
- HTTPリスナーのアイドルタイムアウトを120秒に設定します
80秒遅延の場合→成功
[opc@aksaka0630-843203 ~]$ time curl -s http://10.1.20.5/slow?delay=80
sleeping for 80 seconds...
done
real 1m20.088s
user 0m0.006s
sys 0m0.006s
(展開ください)クライアント側のパケットキャプチャ
TCPコネクションは切れずに80秒後にレスポンスが返ってくる
クライアント：10.1.0.132
FLBリスナーのIPアドレス：10.1.20.5
08:51:13.250126 IP 10.1.0.132.55576 > 10.1.20.5.80: Flags [S], seq 1808074894, win 62720, options [mss 8960,sackOK,TS val 2614000133 ecr 0,nop,wscale 7], length 0
08:51:13.254284 IP 10.1.20.5.80 > 10.1.0.132.55576: Flags [S.], seq 2877817807, ack 1808074895, win 62636, options [mss 8960,sackOK,TS val 3841154591 ecr 2614000133,nop,wscale 10], length 0
08:51:13.254325 IP 10.1.0.132.55576 > 10.1.20.5.80: Flags [.], ack 1, win 490, options [nop,nop,TS val 2614000137 ecr 3841154591], length 0
08:51:13.254426 IP 10.1.0.132.55576 > 10.1.20.5.80: Flags [P.], seq 1:87, ack 1, win 490, options [nop,nop,TS val 2614000138 ecr 3841154591], length 86: HTTP: GET /slow?delay=80 HTTP/1.1
08:51:13.254706 IP 10.1.20.5.80 > 10.1.0.132.55576: Flags [.], ack 87, win 62, options [nop,nop,TS val 3841154593 ecr 2614000138], length 0
08:51:13.255777 IP 10.1.20.5.80 > 10.1.0.132.55576: Flags [.], ack 87, win 62, options [nop,nop,TS val 3841154594 ecr 2614000138], length 0
08:51:13.261909 IP 10.1.20.5.80 > 10.1.0.132.55576: Flags [P.], seq 1:316, ack 87, win 62, options [nop,nop,TS val 3841154600 ecr 2614000138], length 315: HTTP: HTTP/1.1 200 OK
08:51:13.261923 IP 10.1.0.132.55576 > 10.1.20.5.80: Flags [.], ack 316, win 488, options [nop,nop,TS val 2614000145 ecr 3841154600], length 0
★63秒後に謎のackがある。→後述
08:52:16.629337 IP 10.1.0.132.55576 > 10.1.20.5.80: Flags [.], ack 316, win 488, options [nop,nop,TS val 2614063513 ecr 3841154600], length 0
08:52:16.629669 IP 10.1.20.5.80 > 10.1.0.132.55576: Flags [.], ack 87, win 62, options [nop,nop,TS val 3841217968 ecr 2614000145], length 0
★80秒後にレスポンスを返した
08:52:33.328354 IP 10.1.20.5.80 > 10.1.0.132.55576: Flags [P.], seq 316:326, ack 87, win 62, options [nop,nop,TS val 3841234666 ecr 2614000145], length 10: HTTP
08:52:33.328414 IP 10.1.0.132.55576 > 10.1.20.5.80: Flags [.], ack 326, win 488, options [nop,nop,TS val 2614080212 ecr 3841234666], length 0
08:52:33.328442 IP 10.1.20.5.80 > 10.1.0.132.55576: Flags [P.], seq 326:331, ack 87, win 62, options [nop,nop,TS val 3841234667 ecr 2614000145], length 5: HTTP
08:52:33.328455 IP 10.1.0.132.55576 > 10.1.20.5.80: Flags [.], ack 331, win 488, options [nop,nop,TS val 2614080212 ecr 3841234667], length 0
08:52:33.328537 IP 10.1.0.132.55576 > 10.1.20.5.80: Flags [F.], seq 87, ack 331, win 488, options [nop,nop,TS val 2614080212 ecr 3841234667], length 0
08:52:33.329935 IP 10.1.20.5.80 > 10.1.0.132.55576: Flags [F.], seq 331, ack 88, win 62, options [nop,nop,TS val 3841234668 ecr 2614080212], length 0
08:52:33.329960 IP 10.1.0.132.55576 > 10.1.20.5.80: Flags [.], ack 332, win 488, options [nop,nop,TS val 2614080213 ecr 3841234668], length 0
(展開ください) Webサーバ側のパケットキャプチャ
FLBとの間でTCPコネクションを保っている。
FLBバックエンド通信用のIPアドレス：10.1.20.6
WebサーバのIPアドレス：10.1.1.80
08:51:13.255887 IP 10.1.20.6.39730 > 10.1.1.80.80: Flags [S], seq 4283096920, win 62720, options [mss 8960,sackOK,TS val 2708470655 ecr 0,nop,wscale 10], length 0
08:51:13.255957 IP 10.1.1.80.80 > 10.1.20.6.39730: Flags [S.], seq 3545652609, ack 4283096921, win 62636, options [mss 8960,sackOK,TS val 2430613464 ecr 2708470655,nop,wscale 7], length 0
08:51:13.258630 IP 10.1.20.6.39730 > 10.1.1.80.80: Flags [.], ack 1, win 62, options [nop,nop,TS val 2708470657 ecr 2430613464], length 0
08:51:13.259509 IP 10.1.20.6.39730 > 10.1.1.80.80: Flags [P.], seq 1:266, ack 1, win 62, options [nop,nop,TS val 2708470657 ecr 2430613464], length 265: HTTP: GET /slow?delay=80 HTTP/1.1
08:51:13.259539 IP 10.1.1.80.80 > 10.1.20.6.39730: Flags [.], ack 266, win 488, options [nop,nop,TS val 2430613467 ecr 2708470657], length 0
08:51:13.260156 IP 10.1.1.80.80 > 10.1.20.6.39730: Flags [P.], seq 1:204, ack 266, win 488, options [nop,nop,TS val 2430613468 ecr 2708470657], length 203: HTTP: HTTP/1.1 200 OK
08:51:13.261699 IP 10.1.20.6.39730 > 10.1.1.80.80: Flags [.], ack 204, win 62, options [nop,nop,TS val 2708470661 ecr 2430613468], length 0
★80秒後にレスポンスが返る
08:52:33.327658 IP 10.1.1.80.80 > 10.1.20.6.39730: Flags [P.], seq 204:219, ack 266, win 488, options [nop,nop,TS val 2430693536 ecr 2708470661], length 15: HTTP
08:52:33.327882 IP 10.1.20.6.39730 > 10.1.1.80.80: Flags [.], ack 219, win 62, options [nop,nop,TS val 2708550727 ecr 2430693536], length 0
08:52:38.331954 IP 10.1.1.80.80 > 10.1.20.6.39730: Flags [F.], seq 219, ack 266, win 488, options [nop,nop,TS val 2430698540 ecr 2708550727], length 0
08:52:38.334866 IP 10.1.20.6.39730 > 10.1.1.80.80: Flags [F.], seq 266, ack 220, win 62, options [nop,nop,TS val 2708555733 ecr 2430698540], length 0
08:52:38.334894 IP 10.1.1.80.80 > 10.1.20.6.39730: Flags [.], ack 267, win 488, options [nop,nop,TS val 2430698543 ecr 2708555733], length 0
130秒の遅延にした場合→httpリスナーのアイドルタイムアウトで失敗
curl結果
120秒でエラーになった。
[opc@aksaka0630-843203 ~]$ time curl http://10.1.20.5/slow?delay=130 -v
* Trying 10.1.20.5...
* TCP_NODELAY set
* Connected to 10.1.20.5 (10.1.20.5) port 80 (#0)
> GET /slow?delay=130 HTTP/1.1
> Host: 10.1.20.5
> User-Agent: curl/7.61.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Thu, 02 Oct 2025 09:06:56 GMT
< Content-Type: text/plain; charset=UTF-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< Set-Cookie: X-Oracle-BMC-LBS-Route=1807ed18a3b6f68c3e9284f17ca7f108104d5e9f; Path=/
< X-Request-Id: 13346d1f825adc39ca1398a108efa101
<
sleeping for 130 seconds...
* Connection #0 to host 10.1.20.5 left intact
real 2m0.018s
user 0m0.006s
sys 0m0.007s
(展開ください)クライアント側のパケットキャプチャ
クライアント：10.1.0.132
FLBリスナーのIPアドレス：10.1.20.5
09:06:56.688476 IP 10.1.0.132.55184 > 10.1.20.5.80: Flags [S], seq 2700102208, win 62720, options [mss 8960,sackOK,TS val 2614943572 ecr 0,nop,wscale 7], length 0
09:06:56.691012 IP 10.1.20.5.80 > 10.1.0.132.55184: Flags [S.], seq 2266488126, ack 2700102209, win 62636, options [mss 8960,sackOK,TS val 3235039523 ecr 2614943572,nop,wscale 10], length 0
09:06:56.691052 IP 10.1.0.132.55184 > 10.1.20.5.80: Flags [.], ack 1, win 490, options [nop,nop,TS val 2614943574 ecr 3235039523], length 0
09:06:56.691141 IP 10.1.0.132.55184 > 10.1.20.5.80: Flags [P.], seq 1:88, ack 1, win 490, options [nop,nop,TS val 2614943574 ecr 3235039523], length 87: HTTP: GET /slow?delay=130 HTTP/1.1
09:06:56.693818 IP 10.1.20.5.80 > 10.1.0.132.55184: Flags [.], ack 88, win 62, options [nop,nop,TS val 3235039526 ecr 2614943574], length 0
09:06:56.698824 IP 10.1.20.5.80 > 10.1.0.132.55184: Flags [P.], seq 1:317, ack 88, win 62, options [nop,nop,TS val 3235039532 ecr 2614943574], length 316: HTTP: HTTP/1.1 200 OK
09:06:56.698837 IP 10.1.0.132.55184 > 10.1.20.5.80: Flags [.], ack 317, win 488, options [nop,nop,TS val 2614943582 ecr 3235039532], length 0
★62秒でなにかACKがある（※後述）
09:07:58.709374 IP 10.1.0.132.55184 > 10.1.20.5.80: Flags [.], ack 317, win 488, options [nop,nop,TS val 2615005593 ecr 3235039532], length 0
09:07:58.709977 IP 10.1.20.5.80 > 10.1.0.132.55184: Flags [.], ack 88, win 62, options [nop,nop,TS val 3235101543 ecr 2614943582], length 0
★リスナーアイドルタイムアウト120秒で接続をFLBから切っている
09:08:56.697967 IP 10.1.20.5.80 > 10.1.0.132.55184: Flags [P.], seq 317:322, ack 88, win 62, options [nop,nop,TS val 3235159531 ecr 2614943582], length 5: HTTP
09:08:56.698005 IP 10.1.0.132.55184 > 10.1.20.5.80: Flags [.], ack 322, win 488, options [nop,nop,TS val 2615063581 ecr 3235159531], length 0
09:08:56.698103 IP 10.1.0.132.55184 > 10.1.20.5.80: Flags [F.], seq 88, ack 322, win 488, options [nop,nop,TS val 2615063581 ecr 3235159531], length 0
09:08:56.698845 IP 10.1.20.5.80 > 10.1.0.132.55184: Flags [F.], seq 322, ack 88, win 62, options [nop,nop,TS val 3235159531 ecr 2614943582], length 0
09:08:56.698865 IP 10.1.0.132.55184 > 10.1.20.5.80: Flags [.], ack 323, win 488, options [nop,nop,TS val 2615063582 ecr 3235159531], length 0
09:08:56.702689 IP 10.1.20.5.80 > 10.1.0.132.55184: Flags [.], ack 89, win 62, options [nop,nop,TS val 3235159535 e
(展開ください) Webサーバ側のパケットキャプチャ
FLBバックエンド通信用のIPアドレス：10.1.20.6
WebサーバのIPアドレス：10.1.1.80
09:06:56.694181 IP 10.1.20.6.8548 > 10.1.1.80.80: Flags [S], seq 1109331847, win 62720, options [mss 8960,sackOK,TS val 2704454210 ecr 0,nop,wscale 10], length 0
09:06:56.694248 IP 10.1.1.80.80 > 10.1.20.6.8548: Flags [S.], seq 2492025443, ack 1109331848, win 62636, options [mss 8960,sackOK,TS val 2431556902 ecr 2704454210,nop,wscale 7], length 0
09:06:56.696961 IP 10.1.20.6.8548 > 10.1.1.80.80: Flags [.], ack 1, win 62, options [nop,nop,TS val 2704454213 ecr 2431556902], length 0
09:06:56.697778 IP 10.1.20.6.8548 > 10.1.1.80.80: Flags [P.], seq 1:267, ack 1, win 62, options [nop,nop,TS val 2704454213 ecr 2431556902], length 266: HTTP: GET /slow?delay=130 HTTP/1.1
09:06:56.697807 IP 10.1.1.80.80 > 10.1.20.6.8548: Flags [.], ack 267, win 488, options [nop,nop,TS val 2431556906 ecr 2704454213], length 0
09:06:56.698414 IP 10.1.1.80.80 > 10.1.20.6.8548: Flags [P.], seq 1:205, ack 267, win 488, options [nop,nop,TS val 2431556906 ecr 2704454213], length 204: HTTP: HTTP/1.1 200 OK
09:06:56.698604 IP 10.1.20.6.8548 > 10.1.1.80.80: Flags [.], ack 205, win 62, options [nop,nop,TS val 2704454216 ecr 2431556906], length 0
★リスナータイムアウト120秒で接続をFLBからWebサーバへ向けてコネクションを切っている
09:08:56.698837 IP 10.1.20.6.8548 > 10.1.1.80.80: Flags [F.], seq 267, ack 205, win 62, options [nop,nop,TS val 2704574215 ecr 2431556906], length 0
09:08:56.739593 IP 10.1.1.80.80 > 10.1.20.6.8548: Flags [.], ack 268, win 488, options [nop,nop,TS val 2431676948 ecr 2704574215], length 0
★130秒後にレスポンスを消してクローズしようとするがFLBに拒否されている。
09:09:06.784491 IP 10.1.1.80.80 > 10.1.20.6.8548: Flags [P.], seq 205:220, ack 268, win 488, options [nop,nop,TS val 2431686992 ecr 2704574215], length 15: HTTP
09:09:06.784798 IP 10.1.1.80.80 > 10.1.20.6.8548: Flags [F.], seq 220, ack 268, win 488, options [nop,nop,TS val 2431686993 ecr 2704574215], length 0
09:09:06.785684 IP 10.1.20.6.8548 > 10.1.1.80.80: Flags [R], seq 1109332115, win 0, length 0
09:09:06.786874 IP 10.1.20.6.8548 > 10.1.1.80.80: Flags [R], seq 1109332115, win 0, length 0
■（参考）クライアント側のパケットキャプチャでの途中のACKについて
レスポンスを待っている間、約60秒ごとにACKが見えたのでこれが何かを探してみました。
ssコマンド（ソケットの使用状況を調べる）を使って、80番ポート宛てのソケットを見てみると、keepaliveの値が約60sとなっており、これが0sになるとACKが出てきました。
おそらくクライアントOSの設定でTCP-keepaliveが約60秒になっていると考えられます。
クライアントでssコマンド
[opc@aksaka0630-843203 ~]$ sudo ss -o state established dst 10.1.20.5 dport = :80
Netid Recv-Q Send-Q Local Address:Port Peer Address:Port
tcp 0 0 10.1.0.132:42580 10.1.20.5:http ★timer:(keepalive,58sec,0)
また、webサーバ側ではTCP-keepaliveは120分となっていました。（この違いはなんだろう）
■おわりに
パケットキャプチャを使ってリアルタイムで流れているパケットを観察すると分かりやすいです。