Microsoft MVP성태의 닷넷 이야기
.NET Framework: 1030. C# Socket의 Close/Shutdown 동작 (동기 모드) [링크 복사], [링크+제목 복사],
조회: 12343
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 

(시리즈 글이 2개 있습니다.)
.NET Framework: 603. socket - shutdown 호출이 필요한 사례
; https://www.sysnet.pe.kr/2/0/11037

.NET Framework: 1030. C# Socket의 Close/Shutdown 동작 (동기 모드)
; https://www.sysnet.pe.kr/2/0/12574




C# Socket의 Close/Shutdown 동작 (동기 모드)

지금까지 앞에서 shutdown과 closesocket 동작에 대해 설명했는데요,

socket - shutdown 호출이 필요한 사례
; https://www.sysnet.pe.kr/2/0/11037

Wireshark + C/C++로 확인하는 TCP 연결에서의 shutdown 동작
; https://www.sysnet.pe.kr/2/0/12533

Wireshark + C/C++로 확인하는 TCP 연결에서의 closesocket 동작
; https://www.sysnet.pe.kr/2/0/12534

내부적으로는 Win32 Socket API를 그대로 호출하는 C#의 Socket 클래스도 유사하게 동작할 수밖에 없습니다. 따라서 C# 개발자라고 해도 저 글들을 읽어두시길 권장합니다. 또한, C#의 경우 약간의 래핑이 있으므로 저 내용뿐만 아니라 부가적인 코드에 대한 의미를 살짝 살펴볼 필요가 있습니다.




비동기 모드까지 고려하면 좀 복잡하니, 동기 모드에 한해 Socket 타입으로부터 소스 코드를 발췌해 보면 대충 이렇습니다.

namespace System.Net
{
    [SuppressUnmanagedCodeSecurity]
    internal class SafeCloseSocket : SafeHandleMinusOneIsInvalid
    {
        // ...[생략]...
        
        internal class InnerSafeCloseSocket : SafeHandleMinusOneIsInvalid
        {
            protected override bool ReleaseHandle()
            {
                SocketError socketError;
                if (this.m_Blockable)
                {
                    socketError = UnsafeNclNativeMethods.SafeNetHandles.closesocket(this.handle);
                    // ...[생략]...
                }
                
                // ...[생략]...
            }
        }	
    }
}

namespace System.Net.Sockets
{
    public class Socket : IDisposable
    {
        // ...[생략]...
        
        public void Close()
        {
            // ...[생략]...
            ((IDisposable)this).Dispose();
            // ...[생략]...
        }
        
        public void Close(int timeout)
        {
            // ...[생략]...
            this.m_CloseTimeout = timeout;
            ((IDisposable)this).Dispose();
        }
        
        protected virtual void Dispose(bool disposing)
        {
            // ...[생략]...
            try
            {
                int closeTimeout = this.m_CloseTimeout; /* m_CloseTimeout 기본값 -1 */
                if (closeTimeout == 0)
                {
            	    this.m_Handle.Dispose();
                }
                else
                {
            	    // ...[생략]...
            	    if (closeTimeout < 0) /* Close 메서드의 인자로 값을 넘기지 않는 한 -1 */
            	    {
            	        this.m_Handle.CloseAsIs();
            	    }
            	    else
            	    {
            	        // shutdown(SD_SEND) 호출
            	        SocketError socketError = UnsafeNclNativeMethods.OSSOCK.shutdown(this.m_Handle, 1);
                           
            	        // Receive Timeout을 closeTimeout(ms)으로 지정
            	        socketError = UnsafeNclNativeMethods.OSSOCK.setsockopt(m_Handle, SocketOptionLevel.Socket, SocketOptionName.ReceiveTimeout, ref closeTimeout, 4);
            	        if (socketError != SocketError.Success)
            	        {
            	            this.m_Handle.Dispose();
            	        }
            	        else if (UnsafeNclNativeMethods.OSSOCK.recv(m_Handle.DangerousGetHandle(), null, 0, SocketFlags.None) != 0)
            	        {
            	            this.m_Handle.Dispose();
            	        }
            	        else
            	        {
            	            int num3 = 0;                   /* FIONREAD == 0x4004667f == 1074030207 */
            	            if (UnsafeNclNativeMethods.OSSOCK.ioctlsocket(this.m_Handle, 1074030207, ref num3) != SocketError.Success || num3 != 0)
            	            {
            	                this.m_Handle.Dispose();
            	            }
            	            else
            	            {
            	                this.m_Handle.CloseAsIs();
            	            }
            	        }
            	    }
                }
            }
            // ...[생략]...
        }
    }        
}

그러니까, 동기 모드의 소켓을 Socket.Close 또는 Socket.Dispose로 정리하는 경우 단순히 closesocket Win32 API를 호출하는 것과 같습니다. 따라서, 기본 동작은 수신 버퍼에만 데이터가 없다면 송신 버퍼의 내용은 모두 전송하고 FIN을 날려 half-close 작업을 개시합니다. 반면, 수신 버퍼가 비어 있지 않으면 RST를 송신해 무조건 비정상abortive 종료를 합니다.

위의 소스 코드에도 나오지만, Socket.Close의 경우 timeout을 지정한다면 동작이 약간 복잡해집니다. 가령 Socket.Close(1000);으로 timeout 시간을 정하면 특별한 에러가 없는 한 다음의 코드를 수행하게 됩니다.

// shutdown(SD_SEND) 호출
SocketError socketError = UnsafeNclNativeMethods.OSSOCK.shutdown(this.m_Handle, 1);

// Receive Timeout을 closeTimeout(ms)으로 지정
socketError = UnsafeNclNativeMethods.OSSOCK.setsockopt(m_Handle, SocketOptionLevel.Socket, SocketOptionName.ReceiveTimeout, ref closeTimeout, 4);
if (socketError != SocketError.Success)
{
    this.m_Handle.Dispose();
}
else if (UnsafeNclNativeMethods.OSSOCK.recv(m_Handle.DangerousGetHandle(), null, 0, SocketFlags.None) != 0)
if (socketError != SocketError.Success)
{
    this.m_Handle.Dispose();
}
else
{
    int num3 = 0;                   /* FIONREAD == 0x4004667f == 1074030207 */
    if (UnsafeNclNativeMethods.OSSOCK.ioctlsocket(this.m_Handle, 1074030207, ref num3) != SocketError.Success || um3 != 0)
    {
        this.m_Handle.Dispose();
    }
    else
    {
        this.m_Handle.CloseAsIs();
    }
}

상황별로 정리하면,

1. shutdown(SD_SEND) // 현재 송신 버퍼의 내용은 모두 전송하고, FIN 전달
2. recv 함수 호출에 대한 timeout 지정
3. 수신 버퍼에 내용이 있는지 확인 (최대 timeout이 지정한 시간 동안 블록킹)
    recv(0 bytes) 함수
    반환값이 -1인 경우: 수신 버퍼에 내용이 없고 FIN 수신하지 않은 상태에서 timeout 시간 만료
                       상대가 RST 처리
    반환값이 0인 경우: FIN 수신을 한 경우 (대기시간 없음)
                      수신 버퍼에 내용이 있는 경우 (대기시간 없음)

    3.1 recv가 -1을 반환한 경우 m_Handle.Dispose();
    3.2 ioctlsocket(FIONREAD)을 호출해 recv로 읽어낼 수 있는 바이트 수 확인
        3.2.1 수신 버퍼에 내용이 있으면 (m_Handle.Dispose로) 종료
        3.2.2 상대 측이 연결을 종료(FIN)해 0을 반환했으면 CloseAsIs 종료

복잡한 듯하지만, 어쨌든 수신 버퍼에 아직 읽지 않은 내용이 있으면 RST 한다는 사실에는 변함이 없습니다. 그리고, 저런 작업을 왜 한 것인지 잘 이해가 안 됩니다. 예를 들어, 수신 버퍼에 내용이 없다면 어차피 shutdown + closesocket 호출이 되는 효과를 갖는데, 그런 경우라면 그냥 closesocket만 호출해도 무방합니다. 오히려 recv를 끼워 넣음으로 인해 timeout 시간 동안 블록킹이 되는 단점이 있습니다. (혹시 저런 상황에서 기대되는 다른 효과를 아시는 분은 덧글 부탁드립니다. ^^)

반면, 수신 버퍼에 내용이 있다면 timeout이 무색하게 그냥 closesocket으로 진행을 하기 때문에 RST 처리가 됩니다. 이것 역시 closesocket을 단독으로 하는 것과 다르지 않습니다. 물론 저 과정은 TCP + 동기 소켓을 가정하고 해석한 것이므로 다른 상황에서는 저 과정이 의미가 있을 수 있습니다.




그렇다면 Socket.Shutdown을 호출하면 어떻게 될까요?

namespace System.Net.Sockets
{
    public enum SocketShutdown
    {
        Receive,
        Send,
        Both
    }

    public class Socket : IDisposable
    {
        // ...[생략]...

        public void Shutdown(SocketShutdown how)
        {
            // ...[생략]...
            SocketError socketError = UnsafeNclNativeMethods.OSSOCK.shutdown(this.m_Handle, (int)how);
            // ...[생략]...
            this.InternalSetBlocking(this.willBlockInternal); // willBlockInternal == true, blocking mode
            // ...[생략]...
        }

        private SocketError InternalSetBlocking(bool desired, out bool current)
        {
            // ...[생략]...
            int num = desired ? 0 : -1; /* num == 0, blocking mode */
            SocketError socketError;
            try
            {                                              /* FIONBIO == 0x8004667E == -2147195266 */
                socketError = UnsafeNclNativeMethods.OSSOCK.ioctlsocket(this.m_Handle, -2147195266, ref num);
                if (socketError == SocketError.SocketError)
                {
                    socketError = (SocketError)Marshal.GetLastWin32Error();
                }
            }
            // ...[생략]...
            current = this.willBlockInternal;
            return socketError;
        }

        // ...[생략]...
    }
}

Win32 API의 shutdown과 비교하면 ioctlsocket(FIONBIO)를 호출해 blocking 모드로 바꾸는 작업을 더했다는 것 외에 차이점은 없습니다. (하지만, 이번 글은 blocking 모드의 소켓만을 가정하므로 있으나 마나 한 코드입니다.)

마찬가지로 "Wireshark + C/C++로 확인하는 TCP 연결에서의 shutdown 동작" 글에서 설명했지만, 딱히 shutdown(SocketShutdown.Send)를 제외하고는 사용처가 마땅치 않습니다. (대부분은 SD_SEND 옵션으로 호출을 하게 될 것입니다.)

그리고 만약 다음과 같이 코딩을 한다면,

Socket.Shutdown(SocketShutdown.Send);
Socket.Close();

결과적으로 shutdown 2번, closesocket 한 번 호출한 것과 같습니다.




송신과 수신이 얼마나 남았든 아무런 관심 없고 지금 당장 연결을 강제 종료하고 싶어 Linger 옵션을 조정하는 코드는 C#에서 다음과 같이 LingerState 속성을 이용할 수 있습니다.

Socket client = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
client.Connect("..server_ip...", 15000);

client.LingerState = new LingerOption(true, 0);

client.Close();

Wireshark로 확인하면 곧바로 RST 처리로 나옵니다.

// 연결 3-way handshake
1 0.000000 ..client_ip... ..server_ip... TCP 66 7615 → 15000 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM=1
2 0.003599 ..server_ip... ..client_ip... TCP 66 15000 → 7615 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=256 SACK_PERM=1
3 0.003685 ..client_ip... ..server_ip... TCP 54 7615 → 15000 [ACK] Seq=1 Ack=1 Win=262656 Len=0

// RST 처리
4 0.004233 ..client_ip... ..server_ip... TCP 54 7615 → 15000 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0

반면, 서버 측과 (물리적인 연결 끊김이 없는 한) 송/수신이 어떤 경우든 정상graceful 종료하도록 만들고 싶다면 Shutdown 호출 후 receive 동작을 추가하면 됩니다. 이런 절차는 여러 가지 상황(예1, 예2)이 있지만 표준적으로 다음과 같은 식으로 코딩할 수 있습니다.

Socket client = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
client.Connect("..server_ip...", 15000);

// ...[소켓 작업]...

client.Shutdown(SocketShutdown.Send);

while (true)
{
    byte[] buffer = new byte[4096];
    if (client.Receive(buffer) <= 0)
    {
        // ...수신 데이터의 성격에 따라 처리 추가...
        break; 
    }
}

client.Close();

서버와 클라이언트를 모두 저렇게 구현해 두면 언제나 소켓 해제가 정상 종료4-way handshake를 합니다. 하지만, 이렇게 정상 종료하는 것이 항상 옳을 수는 없습니다. 예를 들어, 1GB 파일을 전송하는데 수신 측에서 중간에 사용자가 취소를 하고 싶다면 저렇게 정상 종료를 하기 보다 LingerState를 이용해 곧바로 RST 처리를 하는 것이 더 바람직합니다.




마지막으로 데이터를 one-way로 전송만 하는 식의 경우,

Socket client = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);

client.Connect("..server_ip...", 15000);

// .. 송신 처리...

client.Close();

using (Socket client = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp))
{
    client.Connect("..server_ip...", 15000);

    // .. 송신 처리...
}

이전 글에서도 설명했듯이, 저 코드가 완전히 수행된 경우조차도 Send 데이터가 커널 측의 TCP 버퍼에만 있는 상태일 수 있습니다. 즉, Close까지 수행되었어도 (컴퓨터의 전원이 나가거나, 네트워크 선이 끊기거나 하는 등의 사고로) 데이터가 실제로 상대방에 전송된 것은 아닐 수 있는데, 만약 그 확인이 꼭 필요한 상황이라면 Send 후 반드시 Receive로 확인 결과를 받는 프로토콜을 상호 정의해야 합니다. 그리고 그에 대한 가장 일반적인 사례가 바로 HTTP 프로토콜의 Request 후 Response를 받는 절차입니다.




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







[최초 등록일: ]
[최종 수정일: 3/28/2021]

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

비밀번호

댓글 작성자
 




... 46  47  48  49  50  51  52  53  54  55  56  57  58  [59]  60  ...
NoWriterDateCnt.TitleFile(s)
12170정성태3/6/20209900오류 유형: 599. "Docker Desktop is switching..." 메시지와 DockerDesktopVM CPU 소비 현상
12169정성태3/5/202011913개발 환경 구성: 473. Windows nanoserver에 대한 docker pull의 태그 사용 [1]
12168정성태3/5/202012633개발 환경 구성: 472. 윈도우 환경에서의 dockerd.exe("Docker Engine" 서비스)가 Linux의 것과 다른 점
12167정성태3/5/202011855개발 환경 구성: 471. C# - 닷넷 응용 프로그램에서 DB2 Express-C 데이터베이스 사용 (3) - ibmcom/db2express-c 컨테이너 사용
12166정성태3/4/202011465개발 환경 구성: 470. Windows Server 컨테이너 - DockerMsftProvider 모듈을 이용한 docker 설치
12165정성태3/2/202011091.NET Framework: 900. 실행 시에 메서드 가로채기 - CLR Injection: Runtime Method Replacer 개선 - 네 번째 이야기(Monitor.Enter 후킹)파일 다운로드1
12164정성태2/29/202011962오류 유형: 598. Surface Pro 6 - Windows Hello Face Software Device가 인식이 안 되는 문제
12163정성태2/27/202010424.NET Framework: 899. 익명 함수를 가리키는 delegate 필드에 대한 직렬화 문제
12162정성태2/26/202013270디버깅 기술: 166. C#에서 만든 COM 객체를 C/C++로 P/Invoke Interop 시 메모리 누수(Memory Leak) 발생 [6]파일 다운로드2
12161정성태2/26/20209875오류 유형: 597. manifest - The value "x64" of attribute "processorArchitecture" in element "assemblyIdentity" is invalid.
12160정성태2/26/202010596개발 환경 구성: 469. Reg-free COM 개체 사용을 위한 manifest 파일 생성 도구 - COMRegFreeManifest
12159정성태2/26/20208699오류 유형: 596. Visual Studio - The project needs to include ATL support
12158정성태2/25/202010612디버깅 기술: 165. C# - Marshal.GetIUnknownForObject/GetIDispatchForObject 사용 시 메모리 누수(Memory Leak) 발생파일 다운로드1
12157정성태2/25/202010585디버깅 기술: 164. C# - Marshal.GetNativeVariantForObject 사용 시 메모리 누수(Memory Leak) 발생 및 해결 방법파일 다운로드1
12156정성태2/25/20209872오류 유형: 595. LINK : warning LNK4098: defaultlib 'nafxcw.lib' conflicts with use of other libs; use /NODEFAULTLIB:library
12155정성태2/25/20209094오류 유형: 594. Warning NU1701 - This package may not be fully compatible with your project
12154정성태2/25/20208890오류 유형: 593. warning LNK4070: /OUT:... directive in .EXP differs from output filename
12153정성태2/23/202011666.NET Framework: 898. Trampoline을 이용한 후킹의 한계파일 다운로드1
12152정성태2/23/202011391.NET Framework: 897. 실행 시에 메서드 가로채기 - CLR Injection: Runtime Method Replacer 개선 - 세 번째 이야기(Trampoline 후킹)파일 다운로드1
12151정성태2/22/202011860.NET Framework: 896. C# - Win32 API를 Trampoline 기법을 이용해 C# 메서드로 가로채는 방법 - 두 번째 이야기 (원본 함수 호출)파일 다운로드1
12150정성태2/21/202011738.NET Framework: 895. C# - Win32 API를 Trampoline 기법을 이용해 C# 메서드로 가로채는 방법 [1]파일 다운로드1
12149정성태2/20/202011513.NET Framework: 894. eBEST C# XingAPI 래퍼 - 연속 조회 처리 방법 [1]
12148정성태2/19/202012783디버깅 기술: 163. x64 환경에서 구현하는 다양한 Trampoline 기법 [1]
12147정성태2/19/202011416디버깅 기술: 162. x86/x64의 기계어 코드 최대 길이
12146정성태2/18/202011614.NET Framework: 893. eBEST C# XingAPI 래퍼 - 로그인 처리파일 다운로드1
12145정성태2/18/202010840.NET Framework: 892. eBEST C# XingAPI 래퍼 - Sqlite 지원 추가파일 다운로드1
... 46  47  48  49  50  51  52  53  54  55  56  57  58  [59]  60  ...