Microsoft MVP성태의 닷넷 이야기
닷넷: 2197. C# - ClientWebSocket의 Ping, Pong 처리 [링크 복사], [링크+제목 복사],
조회: 2504
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 1개 있습니다.)
(시리즈 글이 4개 있습니다.)
닷넷: 2188. C# - ASP.NET Core SignalR로 구현하는 채팅 서비스 예제
; https://www.sysnet.pe.kr/2/0/13504

닷넷: 2189. C# - WebSocket 클라이언트를 닷넷으로 구현하는 예제 (System.Net.WebSockets)
; https://www.sysnet.pe.kr/2/0/13505

닷넷: 2197. C# - ClientWebSocket의 Ping, Pong 처리
; https://www.sysnet.pe.kr/2/0/13518

닷넷: 2198. C# - Reflection을 이용한 ClientWebSocket의 Ping 호출
; https://www.sysnet.pe.kr/2/0/13519




C# - ClientWebSocket의 Ping, Pong 처리

지난 글에 WebSocket의 기본 구현을 다뤄봤는데요,

C# - WebSocket 클라이언트를 닷넷으로 구현하는 예제 (System.Net.WebSockets)
; https://www.sysnet.pe.kr/2/0/13505

이번에는 Ping/Pong이 어떻게 ClientWebSocket에 구현되었는지 살펴보겠습니다. 이를 위해 그에 앞서 우선 닷넷 WebSocket의 구조를 먼저 살펴볼 필요가 있습니다. 왜냐하면 WebSocket을 상속한 ClientWebSocket은,

System.Net.WebSockets.ClientWebSocket ws = new System.Net.WebSockets.ClientWebSocket();

최소한의 API만 노출하고 있는, 사실상 껍데기에 불과하기 때문입니다. 실질적인 작업은, 이후 ConnectAsync 시점에 불리는,

await ws.ConnectAsync(new Uri(url), connectTimeout.Token);

WebSocketHandle 인스턴스가 담당합니다.

// ClientWebSocket 타입

public Task ConnectAsync(Uri uri, HttpMessageInvoker? invoker, CancellationToken cancellationToken)
{
    // ...[생략]...
    return ConnectAsyncCore(uri, invoker, cancellationToken);
}

private async Task ConnectAsyncCore(Uri uri, HttpMessageInvoker? invoker, CancellationToken cancellationToken)
{
    _innerWebSocket = new WebSocketHandle();

    await _innerWebSocket.ConnectAsync(uri, invoker, cancellationToken, Options).ConfigureAwait(false);
   
    // ...[생략]...
}

또한 WebSocketHandle 타입은 내부적으로 WebSocket 필드를 하나 가지고 있는데요, 그곳에는 ConnectAsync 시점에 ManagedWebSocket 인스턴스를 생성해 담아두게 됩니다.

// WebSocketHandle 타입

public async Task ConnectAsync(Uri uri, HttpMessageInvoker? invoker, CancellationToken cancellationToken, ClientWebSocketOptions options)
{
    // ...[생략]...
    WebSocket = WebSocket.CreateFromStream(connectedStream, new WebSocketCreationOptions
    {
        IsServer = false,
        SubProtocol = subprotocol,
        KeepAliveInterval = options.KeepAliveInterval,
        DangerousDeflateOptions = negotiatedDeflateOptions
    });
    // ...[생략]...
}

// WebSocket 타입

public static WebSocket CreateFromStream(Stream stream, WebSocketCreationOptions options)
{
    // ...[생략]...
    return new ManagedWebSocket(stream, options);
}

그러니까, WebSocket 프로토콜과 관련된 기능들은 모두 ManagedWebSocket에서 구현하고 있는 것입니다.




닷넷 ClientWebSocket의 경우, Ping/Pong 처리를 Options.KeepAliveInterval 속성으로 지정할 수 있습니다.

System.Net.WebSockets.ClientWebSocket ws = new System.Net.WebSockets.ClientWebSocket();
ws.Options.KeepAliveInterval = TimeSpan.FromSeconds(10); // 10초마다 서버로 Pong 전송

이후, ManagedWebSocket 내부에서는 SendKeepAliveFrameAsync 메서드가 KeepAliveInterval마다 호출이 되는데요,

// ManagedWebSocket 타입

private void SendKeepAliveFrameAsync()
{
    // This exists purely to keep the connection alive; don't wait for the result, and ignore any failures.
    // The call will handle releasing the lock.  We send a pong rather than ping, since it's allowed by
    // the RFC as a unidirectional heartbeat and we're not interested in waiting for a response.
    ValueTask t = SendFrameAsync(MessageOpcode.Pong, endOfMessage: true, disableCompression: true, ReadOnlyMemory<byte>.Empty, CancellationToken.None);

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

재미있는 건, 이때 Ping이 아닌 Pong을 보낸다는 점입니다. 그 이유는 위의 코드에 남겨진 주석에서 설명하고 있습니다. 어차피 WebSocket의 Ping을 송신해도 서버로부터 응답이 오는 것에 관심이 없으므로, 그냥 클라이언트가 살아 있다는 Pong을 주기적으로 전송하는 역할만 하는 것입니다.

저렇게 (KeepAliveInterval로 인해) 자동 송신되는 Pong을 nodejs에서는 다음과 같이 수신할 수 있습니다.

sockserver.on('connection', ws => {
    console.log('New client connected!')

    ws.send('connection established')

    ws.on('pong', () => console.log('pong received from client!'))

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

따라서, nodejs 서버/닷넷 클라이언트를 실행하면 10초마다 닷넷 클라이언트에서 Pong을 주기적으로 송신하고, nodejs는 ws.on('pong', ...) 코드로 인해 10초마다 "pong received..." 로그가 찍히게 됩니다.




자, 그럼 반대로 nodejs 측에서 ping 또는 pong을 전송하도록 해볼까요?

우선, ping부터 다음과 같은 코드로 전송해 보겠습니다.

sockserver.on('connection', ws => {
    interval_id = 0;

    console.log('New client connected!')

    ws.send('connection established')

    ws.on('pong', () => {
        console.log('pong received from client');
    });

    ws.on('close', () => {
        clearInterval(interval_id);
        console.log('Client has disconnected!');
    });

    ws.on('message', data => {
        sockserver.clients.forEach(client => {
            console.log(`distributing message: ${data}`)
            client.send(`echo ${data}`)
        })
    })

    ws.onerror = function () {
        console.log('websocket error')
    }

    interval_id = setInterval(() => {
        ws.ping();
    }, 1000 * 5);
})

보는 바와 같이, 5초 주기로 ws.ping을 호출하고 있고, ws.on('pong', ...)으로 (ping을 보낸 측에서 응답할) pong 수신을 처리하고 있습니다. 닷넷 클라이언트 측은, 이에 대해 KeepAliveInterval을 사용할 필요도 없이 오직 해야 할 일은 "ReceiveAsync" 메서드를 호출해 두는 것입니다.

static async Task Main(string[] args)
{
    string url = "ws://localhost:18000/";

    var connectTimeout = new CancellationTokenSource();
    connectTimeout.CancelAfter(2000);

    System.Net.WebSockets.ClientWebSocket ws = new System.Net.WebSockets.ClientWebSocket();

    await ws.ConnectAsync(new Uri(url), connectTimeout.Token);

    if (ws.State != System.Net.WebSockets.WebSocketState.Open)
    {
        Console.WriteLine($"Failed to connect: {url}");
        return;
    }

    Console.WriteLine($"Received: {await Read(ws)}");
    await ws.SendAsync(Encoding.UTF8.GetBytes("Hello"), WebSocketMessageType.Text, true, CancellationToken.None);
    Console.WriteLine($"Received: {await Read(ws)}");

    // 위의 코드까지는 Send/Receive 쌍을 맞춰 호출

    // 아래의 코드는 일방적으로 Receive를 하는 경우로 가정
    var result = await ws.ReceiveAsync(new ArraySegment<byte>(new byte[1024]), CancellationToken.None);
    if (result.MessageType == WebSocketMessageType.Close)
    {
        await ws.CloseAsync(WebSocketCloseStatus.NormalClosure, null, CancellationToken.None);
        Console.WriteLine("Received close message");
    }

    Console.WriteLine(result.MessageType);
}

이후 nodejs 서버와 닷넷 클라이언트를 실행하면, nodejs 측의 주기적인 ping 신호에 대해 닷넷 클라이언트는 위의 코드상으로는 딱히 반응은 없지만 nodejs 측의 ws.on('pong', ...) 코드가 실행되는 것을 확인할 수 있습니다.




자, 그럼 왜 저렇게 동작하는지 한번 파악해 볼까요? ^^ 위에서 마지막에 호출한 ReceiveAsync 내에서는 nodejs로부터 수신한 Ping 신호를 자동으로 처리하는 코드를 담고 있습니다. 우선, ReceiveAsyncPrivate에서는 다음과 같이 Ping/Pong 신호를 구분해 내고,

[AsyncMethodBuilder(typeof(PoolingAsyncValueTaskMethodBuilder<>))]
private async ValueTask<TResult> ReceiveAsyncPrivate<TResult>(Memory<byte> payloadBuffer, CancellationToken cancellationToken)
{
    // ...[생략]...

    while (true) // in case we get control frames that should be ignored from the user's perspective
    {
        // ...[생략]...
        await _stream.ReadAsync(Memory<byte>.Empty, cancellationToken).ConfigureAwait(false);

        // ...[생략]...
        string? headerErrorMessage = TryParseMessageHeaderFromReceiveBuffer(out header);

        // ...[생략]...
        if (header.Opcode == MessageOpcode.Ping || header.Opcode == MessageOpcode.Pong)
        {
            await HandleReceivedPingPongAsync(header, cancellationToken).ConfigureAwait(false);
            continue;
        }

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

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

private string? TryParseMessageHeaderFromReceiveBuffer(out MessageHeader resultHeader)
{
    // ...[생략]...
    Span<byte> receiveBufferSpan = _receiveBuffer.Span;

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

    header.Opcode = (MessageOpcode)(receiveBufferSpan[_receiveBufferOffset] & 0xF);

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

    // Do basic validation of the header
    switch (header.Opcode)
    {
        // ...[생략]...
        case MessageOpcode.Ping:
        case MessageOpcode.Pong:
            if (header.PayloadLength > MaxControlPayloadLength || !header.Fin)
            {
                // Invalid control messgae
                resultHeader = default;
                return SR.net_Websockets_InvalidControlMessage;
            }
            break;

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

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

Pong 신호인 경우에는 무시하지만, Ping 신호인 경우에는 응답으로 Pong을 송신하는 절차를 거칩니다.

private async ValueTask HandleReceivedPingPongAsync(MessageHeader header, CancellationToken cancellationToken)
{
    // ...[생략]...

    // If this was a ping, send back a pong response.
    if (header.Opcode == MessageOpcode.Ping)
    {
        // ...[생략]...
        await SendFrameAsync(
            MessageOpcode.Pong,)
            endOfMessage: true,
            disableCompression: true,
            _receiveBuffer.Slice(_receiveBufferOffset, (int)header.PayloadLength),
            cancellationToken).ConfigureAwait(false);
    }

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

비록 ManagedWebSocket 자신은 KeepAliveInterval에 대해 Pong 전송만 하는 형식이었지만, 서버의 ping 신호에 대해서는 약속에 따라 Pong으로 응답하고 있는 것입니다. 따라서 만약 nodejs 측의 ping을 pong으로 바꾸면,

sockserver.on('connection', ws => {
    // ..[생략]...
    ws.on('pong', () => {
        console.log('log after pong'); // 이 코드가 실행되지 않음
    });

    // ..[생략]...

    interval_id = setInterval(() => {
        ws.pong(); // pong을 송신하므로 닷넷 클라이언트는 무응답!
    }, 1000 * 5);
})

ManagedWebSocket의 ReceiveAsyncPrivate 메서드에서는 Pong 수신을 무시하므로 nodejs의 ws.on('pong', ...) 코드도 (ping을 보냈던 것과는 달리) 더 이상 실행되지 않게 됩니다.




위의 소스코드를 정리해 보면, C#의 ClientWebSocket 자체는 Timeout 기능이 없다는 점입니다. 즉, (ReceiveAsync 내부적으로) Ping/Pong을 수신했다고 해서 어떠한 시간을 늘리거나 하는 등의 코드는 전혀 없습니다. 또한 ClientWebSocket은 그 패킷을 받았다는 것을 인지하기 위한 이벤트 핸들러같은 것도 제공하지 않습니다. 게다가 KeepAliveInterval조차도 단지 서버에 내가 살아 있으니 끊지 말라는 식으로 Pong 응답을 주기적으로 보내는 것에 불과하고!

그렇다면 왜 이런 식으로 만든 것일까요?

제가 아직 WebSocket에 대해서는 자세하게 몰라서 확신할 수는 없지만, 어쩌면 이것은 Client의 자원 부담이 상대적으로 Server보다는 덜하다는 점에서 나온 특징인 듯합니다. 즉, Client는 굳이 (WebSocket 수준에서의) Timeout 기능이 없어도 문제 될 가능성이 크지 않지만, Server는 필요 없는 연결 자원에 대해 가능한 빠르게 끊는 것이 더 바람직하기 때문입니다.

물론 Socket 자체의 Timeout 기능도 있고 WebSocket 역시 Send/Receive에서의 연결 해제 감지가 되므로 Client 입장에서 Ping/Pong을 이용한 timeout 체크가 간절하지 않기도 합니다.

반면 서버는, 응용 프로그램 측에서의 프로토콜 결정에 따라 좀 더 공격적으로 연결 여부를 확인하기 위해 필요한 수단이지 않을까 싶습니다. ^^ (혹시 이에 대해 자세한 이력을 아시는 분은 덧글 부탁드립니다.)




다시 간단하게 정리해 보면, 2가지만 기억하면 됩니다.

  1. ClientWebSocket은 KeepAliveInterval을 설정한 경우 서버로 Pong만 전송
  2. 서버로부터 Ping을 수신하면 Pong 응답, 반면 Pong을 수신하면 응답 없음




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

[연관 글]






[최초 등록일: ]
[최종 수정일: 1/12/2024]

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

비밀번호

댓글 작성자
 




1  2  3  [4]  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13555정성태2/15/20242405닷넷: 2216. C# - SemaphoreSlim 사용 시 주의점
13554정성태2/15/20242097VS.NET IDE: 189. Visual Studio - 닷넷 소스코드 디컴파일 찾기가 안 될 때
13553정성태2/14/20242151닷넷: 2215. windbg - thin/fat lock 없이 동작하는 Monitor.Wait + Pulse
13552정성태2/13/20242058닷넷: 2214. windbg - Monitor.Enter의 thin lock과 fat lock
13551정성태2/12/20242380닷넷: 2213. ASP.NET/Core 웹 응용 프로그램 - 2차 스레드의 예외로 인한 비정상 종료
13550정성태2/11/20242577Windows: 256. C# - Server socket이 닫히면 Accept 시켰던 자식 소켓이 닫힐까요?
13549정성태2/3/20242974개발 환경 구성: 706. C# - 컨테이너에서 실행하기 위한 (소켓) 콘솔 프로젝트 구성
13548정성태2/1/20242735개발 환경 구성: 705. "Docker Desktop for Windows" - ASP.NET Core 응용 프로그램의 소켓 주소 바인딩(IPv4/IPv6 loopback, Any)
13547정성태1/31/20242472개발 환경 구성: 704. Visual Studio - .NET 8 프로젝트부터 dockerfile에 추가된 "USER app" 설정
13546정성태1/30/20242298Windows: 255. (디버거의 영향 등으로) 대상 프로세스가 멈추면 Socket KeepAlive로 연결이 끊길까요?
13545정성태1/30/20242192닷넷: 2212. ASP.NET Core - 우선순위에 따른 HTTP/HTTPS 호스트:포트 바인딩 방법
13544정성태1/30/20242220오류 유형: 894. Microsoft.Data.SqlClient - Could not load file or assembly 'System.Security.Permissions, ...'
13543정성태1/30/20242266Windows: 254. Windows - 기본 사용 중인 5357 포트 비활성화는 방법
13542정성태1/30/20242260오류 유형: 893. Visual Studio - Web Application을 실행하지 못하는 IISExpress - 두 번째 이야기
13541정성태1/29/20242395VS.NET IDE: 188. launchSettings.json의 useSSL 옵션
13540정성태1/29/20242512Linux: 69. 리눅스 - "Docker Desktop for Windows" Container 환경에서 IPv6 Loopback Address 바인딩 오류
13539정성태1/26/20242485개발 환경 구성: 703. Visual Studio - launchSettings.json을 이용한 HTTP/HTTPS 포트 바인딩
13538정성태1/25/20242709닷넷: 2211. C# - NonGC(FOH) 영역에 .NET 개체를 생성파일 다운로드1
13537정성태1/24/20242767닷넷: 2210. C# - Native 메모리에 .NET 개체를 생성파일 다운로드1
13536정성태1/23/20242773닷넷: 2209. .NET 8 - NonGC Heap / FOH (Frozen Object Heap) [1]
13535정성태1/22/20242711닷넷: 2208. C# - GCHandle 구조체의 메모리 분석
13534정성태1/21/20242470닷넷: 2207. C# - SQL Server DB를 bacpac으로 Export/Import파일 다운로드1
13533정성태1/18/20242621닷넷: 2206. C# - TCP KeepAlive의 서버 측 구현파일 다운로드1
13532정성태1/17/20242577닷넷: 2205. C# - SuperSimpleTcp 사용 시 주의할 점파일 다운로드1
13531정성태1/16/20242610닷넷: 2204. C# - TCP KeepAlive에 새로 추가된 Retry 옵션파일 다운로드1
13530정성태1/15/20242351닷넷: 2203. C# - Python과의 AES 암호화 연동파일 다운로드1
1  2  3  [4]  5  6  7  8  9  10  11  12  13  14  15  ...