Microsoft MVP성태의 닷넷 이야기
.NET Framework: 849. C# - Socket의 TIME_WAIT 상태를 없애는 방법 [링크 복사], [링크+제목 복사]
조회: 430
글쓴 사람
홈페이지
첨부 파일

C# - Socket의 TIME_WAIT 상태를 없애는 방법

예전에 소켓의 상태를 재현하는 방법에 대해서 소개했는데요.

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

이 중에서 접속을 끊으려는 측, 즉 closesocket을 먼저 호출한 측에서 TIME_WAIT이 발생한다고 했습니다. TIME_WAIT의 특성상, 2MSL 시간이 지난 후 해제된다는 면도 그렇지만, 소켓 자원의 구분을 "로컬측:원격측"의 쌍으로 구분하기 때문에,

윈도우 서버 환경에서, 최대 생성 가능한 소켓(socket) 연결 수는 얼마일까?
; https://www.sysnet.pe.kr/2/0/964

TIME_WAIT의 누적으로 인한 문제가 발생하는 경우는 많지 않습니다. 그렇긴 해도, 기왕이면 서버 측에서 TIME_WAIT 상태의 소켓이 누적되는 것보다는 (부하에 대한) 부담이 없는 클라이언트 측에서 발생하는 것이 낫기 때문에 가능한 closesocket은 클라이언트에서 먼저 호출하도록 프로토콜을 협의하는 것이 좋습니다.




TIME_WAIT을 발생시키는 간단한 예제 코드를 한 번 볼까요? 우선 다음은 서버 측을 담당하는 코드이고,

using System;
using System.Net;
using System.Net.Sockets;
using System.Threading;

class Program
{
    static Socket _serverSocket;

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

        Console.ReadLine();
    }

    private static void serverSockFunc(object obj)
    {
        try
        {
            using (_serverSocket = CreateServerSocket())
            {
                _serverSocket.Listen(5);

                while (_serverSocket != null)
                {
                    Console.WriteLine("accept...");
                    using (Socket clntSocket = _serverSocket.Accept())
                    {
                        try
                        {
                            string inputText = clntSocket.ReadString();
                            Console.WriteLine(inputText);
                        }
                        catch (Exception e)
                        {
                            Console.WriteLine(e.ToString());
                        }
                        clntSocket.Close();
                    }
                }
            }
        }
        catch (Exception ex)
        {
            Console.WriteLine(ex.ToString());
        }
    }

    private static Socket CreateServerSocket()
    {
        Socket socket = null;

        socket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
        IPEndPoint ipEp = new IPEndPoint(IPAddress.Loopback, 57102);
        socket.Bind(ipEp);

        return socket;
    }
}

아래는 별도의 EXE에서 실행할 클라이언트 측의 소스 코드입니다.

using System;
using System.Net;
using System.Net.Sockets;
using System.Threading;

class Program
{
    static void Main(string[] args)
    {
        Thread t2 = new Thread(clntSockFunc);
        t2.Start();

        Console.ReadLine();
    }

    private static void clntSockFunc(object obj)
    {
        while (true)
        {
            Thread.Sleep(1000);

            try
            {
                using (var socket = CreateClientSocket())
                {
                    IPEndPoint ipEp = new IPEndPoint(IPAddress.Loopback, 57102);
                    socket.Connect(ipEp);

                    try
                    {
                        socket.WriteString("test");
                        socket.Close();
                    }
                    catch (Exception e)
                    {
                        Console.WriteLine(e.ToString());
                    }
                }
            }
            catch (Exception e)
            {
                Console.WriteLine(e.ToString());
            }
        }
    }

    private static Socket CreateClientSocket()
    {
        return new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
    }
}

위의 2개 EXE를 실행하고 netstat로 확인하면 금방 다음과 같이 TIME_WAIT 소켓들이 (프로세스 id == 0번으로) 남아 있는 것을 볼 수 있습니다.

C:\Windows\System32> netstat -ano | findstr 57102
  TCP    127.0.0.1:57102        0.0.0.0:0              LISTENING       20008
  TCP    127.0.0.1:57102        127.0.0.1:4061         TIME_WAIT       0
  TCP    127.0.0.1:57102        127.0.0.1:4062         TIME_WAIT       0
  TCP    127.0.0.1:57102        127.0.0.1:4064         TIME_WAIT       0
  TCP    127.0.0.1:57102        127.0.0.1:4065         TIME_WAIT       0
  TCP    127.0.0.1:57102        127.0.0.1:4066         TIME_WAIT       0
  TCP    127.0.0.1:57102        127.0.0.1:4067         TIME_WAIT       0
  TCP    127.0.0.1:57102        127.0.0.1:4068         TIME_WAIT       0
  TCP    127.0.0.1:57102        127.0.0.1:4069         TIME_WAIT       0
  TCP    127.0.0.1:57102        127.0.0.1:4070         TIME_WAIT       0
  TCP    127.0.0.1:57102        127.0.0.1:4071         TIME_WAIT       0

모두 클라이언트 측에서 WriteString 후, Close를 바로 했기 때문에 남아 있는 것으로, 이 문제(?)를 해결하려면 클라이언트 측의 소켓에서 Linger 옵션을 설정하면 됩니다.

TCP 소켓 옵션 - SO_LINGER
; https://blog.naver.com/bringmelove1/119145244

C/C++의 l_onoff = 1, l_linger = 0 옵션 설정은 C#에서 다음과 같이 설정할 수 있습니다.

socket.LingerState = new LingerOption(true, 0); // Abortive Shutdown

이후 netstat로 보면 이렇게 ^^ 조용합니다.

C:\Windows\System32> netstat -ano | findstr 57102
  TCP    127.0.0.1:57102        0.0.0.0:0              LISTENING       24752

그런데 문제가 있습니다. SO_LINGER 옵션은 close 호출 시 RST 패킷 전송을 하므로 클라이언트 측에서 다음과 같이 Send 후 곧바로 Close를 호출하면,

using (var socket = CreateClientSocket())
{
    IPEndPoint ipEp = new IPEndPoint(IPAddress.Loopback, 57102);
    socket.LingerState = new LingerOption(true, 0);
    socket.Connect(ipEp);
    socket.WriteString("test");
    socket.Close();
}

서버 측에서 (높은 확률로) Read 시점에 오류가 발생할 수 있습니다.

accept...
install
accept...
System.Net.Sockets.SocketException (0x80004005): An existing connection was forcibly closed by the remote host
   at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)
   at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 size, SocketFlags socketFlags)
   at SocketExtension.ReadInt32(Socket socket) in c:\temp\ConsoleApp2\ConsoleApp1\SocketExtension.cs:line 34
   at SocketExtension.ReadString(Socket socket) in c:\temp\ConsoleApp2\ConsoleApp1\SocketExtension.cs:line 18
   at ConsoleApp1.Program.serverSockFunc(Object obj) in c:\temp\ConsoleApp2\ConsoleApp1\Program.cs:line 35
accept...
System.Net.Sockets.SocketException (0x80004005): An existing connection was forcibly closed by the remote host
   at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)
   at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 size, SocketFlags socketFlags)
   at SocketExtension.ReadInt32(Socket socket) in c:\temp\ConsoleApp2\ConsoleApp1\SocketExtension.cs:line 34
   at SocketExtension.ReadString(Socket socket) in c:\temp\ConsoleApp2\ConsoleApp1\SocketExtension.cs:line 18
   at ConsoleApp1.Program.serverSockFunc(Object obj) in c:\temp\ConsoleApp2\ConsoleApp1\Program.cs:line 35
accept...

이유인즉, Write 후 Close를 너무 빠르게 호출하기 때문에 상대 측에서 Read 완료 전에 연결이 끊어지는 것입니다. 따라서, 다소의 가정을 통해 다음과 같이 Thread.Sleep을 주면 그런 문제를 없앨 수 있습니다.

using (var socket = CreateClientSocket())
{
    IPEndPoint ipEp = new IPEndPoint(IPAddress.Loopback, 57102);
    socket.LingerState = new LingerOption(true, 0);
    socket.Connect(ipEp);

    socket.WriteString("test");

    Thread.Sleep(1); // 경우에 따라 1조차도 서버 측의 Read 과정에서 예외가 발생할 수 있음.
                     // 따라서, 매우 임의적인 값에 불과. (localhost 환경이라면 거의 문제가 없겠지만!)
    socket.Close();
}

Thread.Sleep이 마음에 들지 않지만, 일단은 TIME_WAIT을 없애는 방법 중의 하나입니다.




반면 linger timeout을 1(초)로 설정하면 어떻게 될까요?

socket.LingerState = new LingerOption(true, 1);

SO_LINGER 옵션에 시간 설정이 되면, FIN 패킷의 전송과 함께 그에 대한 ACK를 받을 때까지 Close를 호출한 스레드는 blocking된다고 합니다. 만약 마지막 FIN에 대한 ACK 신호를 지정 시간 내에 받게 되면 기존의 closesocket과 동일한 절차대로 진행(graceful shutdown)이 되지만, 그렇지 않은 경우(1초 후)에는 LingerOption(true, 0)인 상황과 동일하게 RST 패킷 전송과 함께 송수신 버퍼의 모든 내용을 폐기합니다.

따라서, 최솟값 1초이므로 (localhost 내의 통신이라면 거의 대부분 안전하게 1초 내에는 ACK를 받게 되므로) 거의 항상 기존의 4-way handshake 방식대로 종료 절차를 밟아 TIME_WAIT 현상이 동일하게 발생합니다.

재미있는 점이 하나 있다면, LingerOption(true, 1)의 경우 FIN에 대한 ACK 신호를 지정 시간 내에 받았다고 해도, 현재 송/수신 버퍼에 내용이 있다면 RST 처리한다는 점입니다. 따라서, 다음과 같이 의도적으로 서버 측에서 Write 과정을 한 번 더 하게 되면,

// 서버 측
using (Socket clntSocket = _serverSocket.Accept())
{
    string inputText = clntSocket.ReadString();
    clntSocket.WriteString("1"); // 의도적으로 1바이트 전송
    clntSocket.Close();
}

// 클라이언트 측
using (var socket = CreateClientSocket())
{
    IPEndPoint ipEp = new IPEndPoint(IPAddress.Loopback, 57102);
    socket.LingerState = new LingerOption(true, 1);
    socket.Connect(ipEp);

    socket.WriteString("test");
    socket.Close();
}

클라이언트 측의 Close 시점에 FIN을 보내고 ACK를 1초 이내에 받게 되지만, Receive 버퍼에 내용이 있으므로 RST 처리로 넘어가 TIME_WAIT이 이런 경우에도 남지 않게 됩니다.




다행히 Thread.Sleep(1) 코드 없이 TIME_WAIT을 제거하는 방법이 있습니다. 바로 Disconnect 메서드를 사용하는 것입니다.

// 클라이언트 측
using (var socket = CreateClientSocket())
{
    IPEndPoint ipEp = new IPEndPoint(IPAddress.Loopback, 57102);
    socket.LingerState = new LingerOption(true, 0);
    socket.Connect(ipEp);

    socket.WriteString("test");
    socket.Disconnect(false);
    socket.Close();
}

단지 Disconnect 메서드의 사용이 다소 꺼려지는 점이 있다면, 이에 대한 문서같은 것들에서 왜 저것이 TIME_WAIT 과정을 거치지 않도록 만들어 주는지에 대한 정확한 자료를 찾을 수 없다는 점입니다.

Socket.Disconnect(Boolean) Method
; https://docs.microsoft.com/en-us/dotnet/api/system.net.sockets.socket.disconnect

To ensure that all data is sent and received before the socket is closed, you should call Shutdown before calling the Disconnect method.

If you need to call Disconnect without first calling Shutdown, you can set the DontLingerSocket option to false and specify a nonzero time-out interval to ensure that data queued for outgoing transmission is sent. Disconnect then blocks until the data is sent or until the specified time-out expires. If you set DontLinger to false and specify a zero time-out interval, Close releases the connection and automatically discards outgoing queued data.


게다가 위의 내용에 따르면, disconnect가 송/수신 데이터에 대한 책임을 지지 않는다는 것으로 LingerOption(true, 0) 설정과 함께 WriteString 후 곧바로 Close를 호출한 상황에서와 동일하게 서버 측의 예외가 발생할 듯싶은데, 테스트 결과에 따르면 분명히 서버 측은 Disconnect 이전의 데이터를 정상적으로 모두 수신을 합니다. 암튼, Disconnect의 이런 면 때문에 저 코드를 신뢰하고 사용할 수는 없을 것 같습니다.

또 다른 대안이 하나 있다면! 굳이 Disconnect를 사용하지 않더라도 클라이언트와 서버의 통신 프로토콜을 클라이언트 측의 마지막 과정이 Read가 되도록 조정하면 그냥 자연스럽게 RST를 보내게 되므로 TIME_WAIT이 남지 않는 상태가 됩니다.

// 서버 측
using (Socket clntSocket = _serverSocket.Accept())
{
    string inputText = clntSocket.ReadString();
    clntSocket.WriteString("OK"); // 결과 반환
    clntSocket.Close();
}

// 클라이언트 측
using (var socket = CreateClientSocket())
{
    IPEndPoint ipEp = new IPEndPoint(IPAddress.Loopback, 57102);
    socket.LingerState = new LingerOption(true, 0);
    socket.Connect(ipEp);

    socket.WriteString("test");
    string result = socket.ReadString(); // 마지막 동작이 Read
    socket.Close();
}

아마도 현실적으로는, (서버와 클라이언트를 모두 자신이 통제할 수 있다는 조건 하에) 저런 식으로 처리하는 것이 TIME_WAIT을 없애는 가장 매끄러운 방식이 아닐까 생각합니다.

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




시간이 있다면 위의 코드들을 상황 별로 네트워크 패킷 캡처를 통해 확인하고 싶은 내용들이 있습니다.

가령, 위의 마지막 예제는 시간 상으로 보면 서버 측에서 먼저 Close를 하게 되어 있지만 실제로 테스트해 보면 TIME_WAIT이 서버 측에 남지 않습니다. 아마도 예상으로는, 서버는 Close 시점에 FIN을 보내고 클라이언트 측으로부터 ACK를 받아 FIN_WAIT2 상태에 빠지겠지만 클라이언트 측의 마지막 Close에서 FIN이 아닌 RST를 전송하는 것으로 인해 FIN_WAIT2에서 TIME_WAIT으로 넘어가지 못하고 곧바로 제거되는 것 같습니다.




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





[최초 등록일: ]
[최종 수정일: 7/26/2019 ]

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

비밀번호

댓글 쓴 사람
 




[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
12037정성태10/15/201985.NET Framework: 867. C# - Encoding.Default 값을 바꿀 수 있을까요?파일 다운로드1
12036정성태10/14/201936예약
12035정성태10/13/201968개발 환경 구성: 461. C# 8.0의 #nulable 관련 특성을 .NET Framework 프로젝트에서 사용하는 방법파일 다운로드1
12034정성태10/12/201987개발 환경 구성: 460. .NET Core 환경에서 (프로젝트가 아닌) C# 코드 파일을 입력으로 컴파일하는 방법 [1]
12033정성태10/11/201978개발 환경 구성: 459. .NET Framework 프로젝트에서 C# 8.0 컴파일러를 사용하는 방법
12032정성태10/8/201968.NET Framework: 865. .NET Core 2.2/3.0 웹 프로젝트를 IIS에서 호스팅(Inproc, out-of-proc)하는 방법 - AspNetCoreModuleV2 소개
12031정성태10/7/201927오류 유형: 569. Azure Site Extension 업그레이드 시 "System.IO.IOException: There is not enough space on the disk" 예외 발생
12030정성태10/13/2019800.NET Framework: 864. .NET Conf 2019 Korea - "닷넷 17년의 변화 정리 및 닷넷 코어 3.0" 발표 자료 [1]파일 다운로드1
12029정성태9/27/201996제니퍼 .NET: 29. Jennifersoft provides a trial promotion on its APM solution such as JENNIFER, PHP, and .NET in 2019 and shares the examples of their application.
12028정성태9/26/2019120.NET Framework: 863. C# - Thread.Suspend 호출 시 응용 프로그램 hang 현상을 해결하기 위한 시도파일 다운로드1
12027정성태9/26/201942오류 유형: 568. Consider app.config remapping of assembly "..." from Version "..." [...] to Version "..." [...] to solve conflict and get rid of warning.
12026정성태9/26/201947.NET Framework: 862. C# - Active Directory의 LDAP 경로 및 정보 조회
12025정성태9/25/2019138제니퍼 .NET: 28. APM 솔루션 제니퍼, PHP, .NET 무료 사용 프로모션 2019 및 적용 사례 (8)
12024정성태9/20/2019127.NET Framework: 861. HttpClient와 HttpClientHandler의 관계
12023정성태9/19/2019174.NET Framework: 860. ServicePointManager.DefaultConnectionLimit와 HttpClient의 관계파일 다운로드1
12022정성태9/12/2019338개발 환경 구성: 458. C# 8.0 (Preview) 신규 문법을 위한 개발 환경 구성 [3]
12021정성태9/12/2019155[예약]
12020정성태9/11/2019121VC++: 134. SYSTEMTIME 값 기준으로 특정 시간이 지났는지를 판단하는 함수
12019정성태9/11/2019120Linux: 23. .NET Core + 리눅스 환경에서 Environment.CurrentDirectory 접근 시 주의 사항
12018정성태9/25/201974오류 유형: 567. IIS - Unrecognized attribute 'targetFramework'. Note that attribute names are case-sensitive. (D:\lowSite4\web.config line 11)
12017정성태9/11/2019257오류 유형: 566. 비주얼 스튜디오 - Failed to register URL "http://localhost:6879/" for site "..." application "/". Error description: Access is denied. (0x80070005)
12016정성태9/5/2019281오류 유형: 565. git fetch - warning: 'C:\ProgramData/Git/config' has a dubious owner: '(unknown)'.
12015정성태9/3/2019268개발 환경 구성: 457. 윈도우 응용 프로그램의 Socket 연결 시 time-out 시간 제어
12014정성태9/3/2019347개발 환경 구성: 456. 명령행에서 AWS, Azure 등의 원격 저장소에 파일 관리하는 방법 - cyberduck/duck 소개
12013정성태8/28/2019278개발 환경 구성: 455. 윈도우에서 (테스트) 인증서 파일 만드는 방법
[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...