この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。RFC 9293とMicrosoft LearnのGet-NetTCPConnectionを確認し、WindowsでTCP状態を読み取り専用で観察する形に整理しています。検証ステータス：📘 RFC・Microsoft公式仕様確認済み・Windows実機未確認
TCP接続は、通信が終わった瞬間に必ず一覧から消えるわけではありません。PowerShellで現在の状態を数えると、ESTABLISHED や TIME_WAIT が「接続の状態機械」の一部だと目で確認できます。
まず試す
管理者権限を要求せず、現在見えるTCP接続を状態別に数えます。
Get-NetTCPConnection |
Group-Object State |
Sort-Object Count -Descending |
Select-Object Count, Name
環境によって状態と件数は異なります。TIME_WAIT が0件でも失敗ではありません。
ここを見る
たとえば次のような状態があります。
Listen: 接続を待っているEstablished: TCP接続が確立しているTimeWait: close後、一定時間状態を保持している
TIME-WAITはRFC 9293にある正規のTCP状態です。「TIME_WAITがある＝障害」とは限りません。
TIME_WAITだけを見る
Get-NetTCPConnection -State TimeWait -ErrorAction SilentlyContinue |
Select-Object -First 10 LocalAddress, LocalPort, RemoteAddress, RemotePort, State
0件なら「今この瞬間は観察できなかった」という結果です。状態は時間で変わるため、固定値を期待しません。
stateDiagram-v2
[*] --> ESTABLISHED: 接続成立
ESTABLISHED --> FIN_WAIT: active close側の例
FIN_WAIT --> TIME_WAIT: close処理が進む
TIME_WAIT --> [*]: 待機後に終了
図は状態全体を網羅するものではなく、今回観察する流れを簡略化したものです。
1か所変えてみる
ブラウザやcurlなどでHTTPS通信を数回行った後、同じ集計をもう一度実行します。
1..3 | ForEach-Object {
curl.exe -sS -o NUL https://example.com/
}
Get-NetTCPConnection |
Group-Object State |
Sort-Object Count -Descending |
Select-Object Count, Name
接続再利用やOSのタイミングによって必ず同じ増え方をするとは限りません。重要なのは、通信の前後で状態分布を観察することです。
なぜTIME_WAITが残るのか
TCPは信頼性のあるbyte streamを提供するため、closeにも状態遷移があります。TIME-WAITには、遅れて到着したsegmentなどを扱うための役割があります。
そのため「接続を閉じたのにTIME_WAITが残った。強制的に消そう」と考える前に、まず通常の状態遷移なのか、短時間接続が大量発生しているのかを分けて見ます。
失敗・境界条件
1回の観察だけでport exhaustionを断定しない
TIME_WAIT件数だけでアプリ異常と断定しない
NAT、proxy、load balancerの向こう側の状態まではこのコマンドで見えない
短い通信は観察の瞬間を逃すことがある
仕事で使うなら
「Webが時々つながらない」「大量処理の後だけ接続がおかしい」といった問い合わせで、いきなり設定を変更する前に状態を記録できます。
Get-NetTCPConnection |
Group-Object State |
Select-Object Name, Count |
Sort-Object Name
時刻と一緒に保存して正常時と障害時を比較すれば、問い合わせ一次切り分けの材料になります。事務担当が自分で直すためというより、情シスやベンダーへ「どの状態が増えていたか」を伝えるための観測手段として使えます。
