Microsoft MVP성태의 닷넷 이야기
.NET Framework: 983. C# - TIME_WAIT과 ephemeral port 재사용 [링크 복사], [링크+제목 복사],
조회: 18524
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
(연관된 글이 2개 있습니다.)
(시리즈 글이 9개 있습니다.)
개발 환경 구성: 92. 윈도우 서버 환경에서, 최대 생성 가능한 소켓(socket) 연결 수는 얼마일까?
; https://www.sysnet.pe.kr/2/0/964

Windows: 175. 윈도우 환경에서 클라이언트 소켓의 최대 접속 수
; https://www.sysnet.pe.kr/2/0/12350

Windows: 178. 윈도우 환경에서 클라이언트 소켓의 최대 접속 수 (2) - SO_REUSEADDR
; https://www.sysnet.pe.kr/2/0/12432

Windows: 179. 윈도우 환경에서 클라이언트 소켓의 최대 접속 수 (3) - SO_PORT_SCALABILITY
; https://www.sysnet.pe.kr/2/0/12433

Windows: 181. 윈도우 환경에서 클라이언트 소켓의 최대 접속 수 (4) - ReuseUnicastPort를 이용한 포트 고갈 문제 해결
; https://www.sysnet.pe.kr/2/0/12435

.NET Framework: 981. C# - HttpWebRequest, WebClient와 ephemeral port 재사용
; https://www.sysnet.pe.kr/2/0/12448

.NET Framework: 982. C# - HttpClient에서의 ephemeral port 재사용
; https://www.sysnet.pe.kr/2/0/12449

.NET Framework: 983. C# - TIME_WAIT과 ephemeral port 재사용
; https://www.sysnet.pe.kr/2/0/12450

Linux: 35. C# - 리눅스 환경에서 클라이언트 소켓의 ephemeral port 재사용
; https://www.sysnet.pe.kr/2/0/12459




C# - TIME_WAIT과 ephemeral port 재사용

예전에 소켓 상태 테스트를 하면서,

코드로 재현하는 소켓 상태(FIN_WAIT1, FIN_WAIT2, TIME_WAIT, CLOSE_WAIT, LAST_WAIT)
; https://www.sysnet.pe.kr/2/0/1334

맨 처음 closesocket을 호출한 측(만약, 둘이 동시에 closesocket을 호출하면 양측 모두)에 TIME_WAIT 상태로 2MSL(maximum segment lifetime) 시간 동안 유지된다고 했는데요, 그때도 언급했지만 2MSL 시간이라는 게 참 애매합니다. 이에 대해 직접적으로 설명한 공식 문서는 찾을 수 없고, 연관된 것들에서 그 흔적을 볼 수 있는데요,

TcpTimedWaitDelay
LPFN_CONNECTEX callback function (mswsock.h)
; https://docs.microsoft.com/en-us/windows/win32/api/mswsock/nc-mswsock-lpfn_connectex

By default, the MSL is defined to be 120 seconds. The TcpTimedWaitDelay registry setting defaults to a value 240 seconds, which represents 2 times the maximum segment lifetime of 120 seconds or 4 minutes.


SystemConfig_Network class
; https://docs.microsoft.com/en-us/windows/win32/etw/systemconfig-network

RFC 793 published by the IETF requires that TCP maintains a closed connection for an interval at least equal to twice the maximum segment lifetime (2MSL) of the network. When a connection is released, its socket pair and TCP control block (TCB) can be used to support another connection. By default, the MSL is defined to be 120 seconds, and the value of this entry is equal to two MSLs, or 4 minutes. For more information, see RFC 793.


MSL의 시간이 120초, 따라서 2MSL로 TcpTimedWaitDelay가 정해졌으니 4분인데, 엉뚱하게도 biztalk 문서에 보면,

Settings that can be Modified to Improve Network Performance
; https://docs.microsoft.com/en-us/biztalk/technical-guides/settings-that-can-be-modified-to-improve-network-performance

120으로 기본값이 설정되었다고 하며 실제로 테스트해보면 Windows 10에서 2분(120)이 맞습니다.

자, 그럼 TIME_WAIT 상태로 머무는 동안 점유된 포트는 이후 어떻게 소켓 통신에 영향을 미치게 될까요? 기왕에 이번 테스트를 하면서 환경도 구축했으니,

경로: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters
이름: MaxUserPort
타입: DWORD
값: 7d0 (2000)

DynamicPortRangeStartPort       : 1024
DynamicPortRangeNumberOfPorts   : 977
AutoReusePortRangeStartPort     : 15000
AutoReusePortRangeNumberOfPorts : 1000

^^ 마저 결과를 확인해 보겠습니다.




어차피 서버 측은 5-tuple 구분을 하므로, 여기서 궁금한 것은 클라이언트 측의 TIME_WAIT 상태에 따른 포트 재사용 문제입니다. 따라서, 다음과 같이 서버와 클라이언트 코드를 구성해,

// 서버 예제 코드

using System;
using System.Collections.Generic;
using System.Net;
using System.Net.Sockets;
using System.Threading;

namespace ConsoleApp1
{
    class Program
    {
        static List<TcpClient> _cla17000 = new List<TcpClient>();
        static List<TcpClient> _cla17001 = new List<TcpClient>();

        static void Main(string[] args)
        {
            Thread t = new Thread(CountFunc);
            t.IsBackground = true;
            t.Start();

            bool active1 = true;
            bool active2 = true;

            if (args.Length >= 1)
            {
                if (args[0] == "1")
                {
                    active2 = false;
                }
                else if (args[0] == "2")
                {
                    active1 = false;
                }
            }

            if (active1 == true)
            {
                Thread t17000 = new Thread(acceptFunc);
                t17000.IsBackground = true;
                t17000.Start(17000);
            }

            if (active2 == true)
            {
                Thread t17001 = new Thread(acceptFunc);
                t17001.IsBackground = true;
                t17001.Start(17001);
            }

            while (true)
            {
                string txt = Console.ReadLine();
                if (txt == "1")
                {
                    foreach (var cla in _cla17000)
                    {
                        try
                        {
                            cla.Close();
                        } catch { }
                    }

                    _cla17000.Clear();
                }

                Console.WriteLine(DateTime.Now);
            }
        }

        private static void acceptFunc(object objPort)
        {
            int port = (int)objPort;

            TcpListener svr = new TcpListener(IPAddress.Any, port);
            {
                svr.Start();

                while (true)
                {
                    TcpClient client = svr.AcceptTcpClient();

                    if (port == 17000)
                    {
                        _cla17000.Add(client);
                    }
                    else
                    {
                        _cla17001.Add(client);
                    }
                }
            }
        }

        private static void CountFunc()
        {
            while (true)
            {
                Console.WriteLine($"# of 17000: {_cla17000.Count}, 17001: {_cla17001.Count}");
                Thread.Sleep(5000);
            }
        }
    }
}

// 클라이언트 예제 코드

using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Net;
using System.Net.Sockets;

namespace ConsoleApp2
{
    class Program
    {
        static void Main(string[] args)
        {
            string ipAddr = args[0];
            int port = int.Parse(args[1]);
            int numberOf = int.Parse(args[2]);

            List<Socket> clients1 = new List<Socket>();

            try
            {
                for (int i = 0; i < numberOf; i++)
                {
                    try
                    {
                        Socket client = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
                        client.Bind(new IPEndPoint(IPAddress.Any, 0));
                        client.Connect(ipAddr, port);

                        Console.WriteLine($"{client.LocalEndPoint}-{client.RemoteEndPoint}");

                        clients1.Add(client);
                    }
                    catch { }
                }
            }
            catch (Exception e)
            {
                Console.WriteLine(e.ToString());
            }

            Console.WriteLine($"{clients1.Count}, {Process.GetCurrentProcess().Id}");

            while (true)
            {
                string txt = Console.ReadLine();
                if (txt == "1")
                {
                    foreach (var cla in clients1)
                    {
                        cla.Close();
                    }
                }
                Console.ReadLine();
            }
        }
    }
}

실행해 보면, 클라이언트 측의 Bind로 인해 DynamicPortRangeStartPort 영역의 포트를 사용하게 되고 Reuse를 하지 못해 지난번처럼 DynamicPortRangeNumberOfPorts 즈음에서 더 이상 접속이 안 됩니다.

C:\temp2> ConsoleApp1.exe
# of 17000: 0, 15001: 0
# of 17000: 966, 15001: 0

C:\temp2> ConsoleApp2 localhost 17000 1000
...[생략]...
966

이 상태에서, 클라이언트 측 콘솔에 1+{ENTER}를 치면 소켓 접속을 모두 끊고, 이어 서버 측에서도 1+{ENTER}를 치면 대응 소켓을 모두 끊으므로 클라이언트 측 소켓에 대해 TIME_WAIT이 남는 것을 "netstat -ano | findstr TIME_WAIT"로 확인할 수 있습니다.

C:\WINDOWS\system32> netstat -ano | findstr TIME_WAIT
  TCP    127.0.0.1:1024         127.0.0.1:17000        TIME_WAIT       0
  TCP    127.0.0.1:1025         127.0.0.1:17000        TIME_WAIT       0
  TCP    127.0.0.1:1026         127.0.0.1:17000        TIME_WAIT       0
  TCP    127.0.0.1:1027         127.0.0.1:17000        TIME_WAIT       0
...[생략]...
  TCP    127.0.0.1:1997         127.0.0.1:17000        TIME_WAIT       0
  TCP    127.0.0.1:1998         127.0.0.1:17000        TIME_WAIT       0
  TCP    127.0.0.1:1999         127.0.0.1:17000        TIME_WAIT       0
  TCP    127.0.0.1:2000         127.0.0.1:17000        TIME_WAIT       0

이제 2분의 여유 시간이 있으니 이 사이에 포트 재사용 여부를 테스트할 수 있습니다. ^^

우선, cmd.exe 창을 띄워 같은 포트로 접속을 시도해 보면,

D:\temp> ConsoleApp2.exe localhost 17000 1001
0

TIME_WAIT으로 점유된 포트로 인해 더 이상 가용 포트가 없어 접속이 안되는 것을 확인할 수 있습니다. 반면, 다른 포트로 접속하면 어떻게 될까요?

D:\temp> ConsoleApp2.exe localhost 17001 1001
127.0.0.1:1116-127.0.0.1:17001
127.0.0.1:1117-127.0.0.1:17001
127.0.0.1:1118-127.0.0.1:17001
127.0.0.1:1119-127.0.0.1:17001
...[생략]...
127.0.0.1:1112-127.0.0.1:17001
127.0.0.1:1113-127.0.0.1:17001
127.0.0.1:1114-127.0.0.1:17001
127.0.0.1:1115-127.0.0.1:17001
965

이런 경우에는, 별다른 설정이 없었는데도 5-tuple 구분을 통해 정상적으로 동일한 포트 번호를 점유하는 것을 확인할 수 있습니다. 실제로 위에서 출력된 포트 하나를 기준으로 netstat 명령을 내려보면,

C:\WINDOWS\system32> netstat -ano | findstr 1115
  TCP    127.0.0.1:1115         127.0.0.1:17000        TIME_WAIT       0
  TCP    127.0.0.1:1115         127.0.0.1:17001        ESTABLISHED     17304

1115 포트가 TIME_WAIT, ESTABLISHED에 각각 사용된 것이 보입니다.

(첨부 파일은 이 글의 예제 코드를 포함합니다.)




따라서, 5-tuple 구분이 되는 서버 소켓으로의 접속이라면 클라이언트 측의 TIME_WAIT으로 인한 소켓 고갈을 염려할 필요는 없습니다. 단지, 주소 및 포트까지 동일한 서버 소켓으로 접속하는 경우라면, TIME_WAIT으로 인한 소켓 포트 점유는 문제가 됩니다.

닷넷 환경이라면 어떨까요?

만약 여러분이 소켓을 사용해 직접 구현한 경우라면 TIME_WAIT으로 인한 소켓 포트 점유를 주의 깊게 살펴야 합니다. 반면, HttpWebRequest, WebClient, HttpClient 등을 이용한 경우라면 그것들 자체 내에 풀링 기능이 있으므로,

You're using HttpClient wrong and it is destabilizing your software
; https://aspnetmonsters.com/2016/08/2016-08-27-httpclientwrong/

TIME_WAIT이 문제가 되는 경우는 거의 없습니다.




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]






[최초 등록일: ]
[최종 수정일: 12/14/2020]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




... 121  122  123  124  [125]  126  127  128  129  130  131  132  133  134  135  ...
NoWriterDateCnt.TitleFile(s)
10798정성태5/26/201522093기타: 53. 2015년 6월 10일 밤 10시 온라인 세미나 - 새로운 Windows 10 App을 개발하는 방법
10797정성태5/23/201521731VC++: 91. 자식 스레드에 자동 상속되는 TEB의 SubProcessTag 필드파일 다운로드1
10796정성태5/23/201532555오류 유형: 293. SQL Server Management Studio 실행 시 "Cannot find one or more components" 오류
10795정성태5/23/201530650오류 유형: 292. InstallUtil로 .NET 서비스 등록 시 오류 - Operation is not supported. (Exception from HRESULT: 0x80131515). [3]
10794정성태5/22/201525591개발 환경 구성: 267. (무료) 마이크로소프트 온라인 강좌 소개 - 네트워킹 기초 [1]
2925정성태5/14/201525132디버깅 기술: 73. PDB 기호 파일의 경로 구성 방식파일 다운로드1
2924정성태5/14/201528457VS.NET IDE: 100. 비주얼 스튜디오 원격 디버깅 시 'Unknown function' 콜스택이 나온다면?
2923정성태5/12/201587822기타: 52. 도서: 시작하세요! C# 6.0 프로그래밍: 기본 문법부터 실전 예제까지 [17]
2922정성태5/12/201524673오류 유형: 291. ssindex.cmd 실행 시 '...[tfs_collection_url]...' not found in srcsrv.ini 오류 발생
2921정성태5/9/201531054개발 환경 구성: 266. 인텔에서 구현한 최대 절전 모드 기능 - Intel® Rapid Start Technology
2920정성태5/9/201522137오류 유형: 290. 디스크 관리자의 파티션 축소 시, There is not enough space available on the disk(s) to complete this operation.
2919정성태5/9/201522058오류 유형: 289. Error: this template attempted to load component assembly 'NuGet.VisualStudio.Interop, ...'
2918정성태5/9/201540553Windows: 111. 복구(Recovery) 파티션 삭제하는 방법 [3]
2917정성태5/9/201530979오류 유형: 288. .NET Framework 4.6이 설치된 경우 "Intel® Rapid Storage Technology (Intel® RST) RAID Driver"가 설치 안 되는 문제 [5]
2916정성태5/9/201532073오류 유형: 287. 레지스트리 권한 오류 - Cannot edit [Registry key name]: Error writing the value's new contents.
2915정성태5/9/201531194개발 환경 구성: 265. TrustedInstaller 권한으로 프로그램 실행시키는 방법 [11]
2914정성태5/9/201528507DDK: 7. 정식 인증서가 있는 경우 Device Driver 서명하는 방법 [2]
2913정성태4/30/201526268.NET Framework: 511. Build 2015 행사에서 소개된 (맥/리눅스/윈도우 용 무료) Visual Studio Code 개발 도구 [8]
2912정성태4/29/201521998오류 유형: 286. VirtualBox에 Windows 8/2012 설치 시 "Error Code: 0x000000C4" 오류 발생
2911정성태4/29/201520658오류 유형: 285. Visual Studio 2015를 제거한 경우 Microsoft.VisualStudio.Web.PageInspector.Loader 어셈블리를 못 찾는 문제 [2]
2910정성태4/29/201524560오류 유형: 284. System.TypeLoadException: Could not load type 'System.Reflection.AssemblySignatureKeyAttribute' from assembly [1]
2909정성태4/29/201520703오류 유형: 283. WCF 연결 오류 - Expected record type 'PreambleAck'
2908정성태4/29/201528975오류 유형: 282. 원격에서 SQL 서버는 연결되지만, SQL Express는 연결되지 않는 경우
2907정성태4/29/201519074.NET Framework: 510. 제네릭(Generic) 인자에 대한 메타데이터 등록 확인
2906정성태4/28/201521626오류 유형: 281. DebugView로 인한 System.Diagnostics.Trace.WriteLine 멈춤(Hang) 현상
2905정성태4/27/201521998오류 유형: 280. HttpResponse.Headers.Add에서 "System.PlatformNotSupportedException: This operation requires IIS integrated pipeline mode." 예외 발생
... 121  122  123  124  [125]  126  127  128  129  130  131  132  133  134  135  ...