KEEP ALIVE PACKET

Tiny Web Server 이후 바로 현업에서 논할만한 기술인 Keep Alive에 대해 논해보겠습니다.

• 주의. Alive Packet, keep alive, heartbeat 다 혼용되도 그런가보다 해주길 부탁..

우리가 만들 Tiny Server의 개요

1. 간소함(Simplicity): Tiny 서버는 최소한의 기능만 구현합니다. 이로 인해 코드의 구조와 흐름을 쉽게 이해할 수 있도록 설계되어 있으며, 초보자에게 네트워크 서버의 내부 동작을 가르치기에 적합합니다.
2. 동기식(iterative) 서버: 서버는 단일 스레드(혹은 단일 프로세스)로 동작하면서, 하나의 연결을 처리한 후 다음 연결을 순차적으로 처리합니다. 이 방식은 병렬 처리가 아닌 순차적 처리를 통해 복잡성을 줄이고 기본 개념에 집중할 수 있게 합니다.

• Tiny에서 직접 해보기엔 어려울것.. 왜냐하면

우리의 이 코딱지만한 서버는 되게 작고 순차적 처리를 하기 때문에 직접 여기에 구현하기에는 의도에서 많이 벗어나는 상황이 일어날 수 있다. 그래서 구현에 대해서 논하진 않는다.

• 하나의 클라이언트가 연결을 유지하기 위한 패킷이 오고가는데 우리 코딱지서버는 단일 스레드이다. 서버는 할 일도 해야하는데, 그 와중에 Alive Packet도 해야하니 단일 스레드이면서 순차적 처리를 하는 상황으로썬 버거운 상황이 자주 나오겠죠?

다만, 요즘 많은 웹 서비스들이 기본값으로 Keep Alive를 적용하고 있기 때문에 Proxy 도전을 하지 않겠다고 하더라도 이 개념을 반드시 알아두는 것이 좋다.

 

• ALIVE PACKET 개념의 역사는 오래 되었다

완전 초기 인터넷이었던 ARPANET에도 Alive Packet 개념이 있었다. 그 때는 노드간 통신 유지를 위해 주기적으로 메시지를 교환하는 방식이 있었다. 그냥 지금이랑 다르지 않다.

 

• 웹 사이트는 ALIVE PACKET가 대대로 필요했던 컴퓨터 업계의 의외로 예외에 속하는 영역이(었)다

그니까, 웹 서비스는 오히려 웹 페이지 단위로 일정 주기로 넘어가는게 있으니 서비스 이용 자체가 Alive Packet 개념을 논하고 있어서 특별히 논할 필요가 없었지만, 모바일 웹을 포함한 서비스 제공이 최근들어 잦아지면서 기본적으로 Keep Alive을 다루는 서비스들이 즐비한 상황이다.

 

• ALIVE PACKET의 존재 의의

일반적으로 "alive packet" 또는 "heartbeat" 메시지는 클라이언트와 서버 간에 주기적으로 전송되어 양쪽이 아직 쓰고 있는지에 대한 여부를 보는데 쓰인다.

• 이러한 패킷을 통해 서버는 클라이언트가 오랫동안 응답이 없는 상태로 방치되지 않고 실제로 접속 중임을 확인할 수 있으며, 만약 일정 시간 동안 heartbeat를 받지 못하면 연결이 끊겼다고 판단하여 적절한 조치를 취할 수 있다.
• 이 개념은 TCP의 keepalive 옵션이나, 애플리케이션 레벨에서 구현되는 heartbeat 메시지 등 다양한 형태로 사용되며, 네트워크 환경에서 연결의 안정성을 유지하고 문제를 조기에 탐지하는 데 매우 유용하다.

 

Keep Alive 과정 없이 일단 뭐든 보내면 받지 않을까?

• 시도 자체가 리소스 낭비인 경우가 생김. 그래서 기본 값을 Keep Alive 우선으로 하기로 결정하는경우가 많다.
• 확실한 신호이면서 제일 오버헤드가 적은 방법이 Keep Alive인것

 

Keep Alive에 문제가 생기면 일어나는 일

• 내가 행위하는게 서버에 반영이 안됨. 남이 하는 행위를 서버를 통해 받아 올 수 없다.
• 총 게임에서 제자리 걸음하고, 내 캐릭터 안움직이고, 그런것들
• 일정시간 그 모양이면 튕김

 

Keep-Alive도 성능을 해치는거 아닌가요

Keep-Alive 관리보다 Keep-Alive을 통해 연결을 끊고 다시 잇는거에 대한 오버헤드가 더 컸기 때문에 서비스 초기 개발 과정에서 이런 선택을 하는 것이다. 특정 서비스에서는 비슷하지만 약간 다른 Alive Indicator : 서버가 클라이언트에게 일방적으로 보내는 상태 확인도 있어서, 소형 IoT 장치들에게 적합 할 수 있다.

얼라이브 패킷 개념은 네트워크 연결의 안정성을 보장하기 위해 사용되며, 네트워크 프로토콜의 발전 과정에서 자연스럽게 등장한 개념이다. 처음부터 네트워크 프로토콜 설계에 포함된 요소는 아니었지만, 시간이 지나면서 TCP의 keepalive 옵션과 같은 기능을 통해 연결 유지 기술이 발전했다.

큰 틀에선 같아도 레벨단위의 차이가 있다

• TCP의 keepalive 옵션은 운영체제 딴에서 이뤄지니 좀 더 근본적으로 이 컴퓨터가 연결되어있는지에 대해 다룬다. : 웹 서버,
• App 레벨의 alive packet은 이 App이 켜져있냐 꺼져냐를 더 중점으로 본다. 여러 목적의 리소스 절약을 위해 이 내용의 비중이 강한 편이다.

 

Keep Alive 개념이 사용되는 서비스 유형

1. 메신저 및 채팅 서비스
   • WhatsApp, 카카오톡, Telegram 같은 메신저는 사용자와 서버 간의 연결을 유지하기 위해 heartbeat 메시지를 사용합니다. 특히 푸시 알림이나 새 메시지를 빠르게 전달하기 위해 중요하죠.
2. 실시간 스트리밍 및 VoIP 서비스
   • Zoom, Microsoft Teams, Skype 같은 화상 통화 및 VoIP 서비스는 통신 중 연결 유지가 필수적이므로 주기적으로 keep alive 메시지를 전송하여 네트워크 상태를 확인합니다.
3. 온라인 게임
   • 다중 사용자 온라인 게임(MMO)은 플레이어가 지속적으로 서버와 동기화된 상태를 유지해야 합니다. 연결이 끊겼는지 감지하고, 끊기지 않도록 지속적으로 heartbeat 메시지를 보내죠.
4. IoT 및 스마트 기기
   • 스마트 홈 기기, 센서 네트워크, 자동차 시스템 등은 클라우드 서버와 지속적인 연결을 유지하여 장치 상태를 모니터링하고 제어하기 위해 heartbeat 메시지를 사용합니다.
5. 분산 시스템 및 마이크로서비스
   • 여러 서버가 협력하여 동작하는 시스템에서는 각 구성 요소가 서로의 가용성을 확인하기 위해 keep alive 메시지를 사용합니다. 예를 들어 Kubernetes의 health check 기능이 이에 해당됩니다.
6. 네이버 지도에 가서 한창 보다가 와이파이를 꺼보자.

Keep Alive 개념은 Tiny Server 이후에 도전과제로 다룰 Proxy Server에서도 그 개념을 필요로 합니다. 나는 도전과제까지 싸악 끝내길 원하기 때문에 이걸 다루게 되었습니다.

 

HTTP Keep-Alive의 동작 방식

웹 브라우저에서 HTTP Keep-Alive 옵션이 활성화되면 클라이언트(브라우저)와 서버 간의 TCP 연결을 유지하면서 여러 개의 HTTP 요청을 동일한 연결에서 처리할 수 있습니다.

1. 일반적인 HTTP 요청-응답 흐름 (Keep-Alive 미사용)

• 클라이언트(브라우저)는 서버에 요청을 보냅니다. (예: 웹 페이지를 로드하기 위한 요청)
• 서버가 응답을 반환합니다. (예: HTML 파일)
• 요청이 완료되면 TCP 연결이 종료됩니다.
• 이후 새로운 요청(예: CSS, 이미지 등)이 필요하면 새로운 연결을 생성해야 합니다.

우리가 CS:APP에서 보았던 전통적인 request의 개념을 여기서 논하고있다. 그리고 코치님의 강의 내용에도 request가 계속 되면? 이라는 언급을 했던 적이 있다.

이 방식은 요청마다 별도로 TCP 연결을 설정해야 하므로 오버헤드가 발생하고, 페이지 로딩 속도에도 영향을 줄 수 있습니다.

2. HTTP Keep-Alive 활성화 시의 요청-응답 흐름

• 클라이언트가 최초 요청을 보냅니다.
• 서버는 Keep-Alive 헤더를 포함하여 응답합니다. (Connection: keep-alive)
• 이후 클라이언트가 추가 요청을 보낼 때 같은 TCP 연결을 재사용하여 요청을 처리합니다.
• 일정 시간이 지나거나 최대 요청 횟수에 도달하면 서버가 연결을 종료합니다.

예제: 웹 페이지를 로드할 때의 차이점

1. Keep-Alive 미사용 시
   • HTML 요청 → 연결 종료
   • CSS 요청 → 새로운 연결 생성 → 응답 후 종료
   • 이미지 요청 → 새로운 연결 생성 → 응답 후 종료
2. Keep-Alive 활성화 시
   • HTML 요청 → 연결 유지
   • CSS 요청 → 같은 연결에서 처리
   • 이미지 요청 → 같은 연결에서 처리
   • 일정 시간이 지나면 서버가 연결을 종료

이처럼 Keep-Alive를 사용하면 TCP 연결을 반복해서 설정하는 부담이 줄어들고, 웹 페이지 로딩 속도와 서버 성능이 개선될 수 있습니다.

1.  

• 그래서 다루는데 있어 좋은 점이 뭐가 있어요?

1. 멀티스레딩 또는 비동기 서버에서의 연결 유지 Tiny 서버는 단일 스레드 방식으로 동작하지만, 실무에서는 다중 연결을 처리할 수 있도록 비동기 방식이나 멀티스레딩 서버를 구현해야 합니다. 이때, keepalive를 활용하면 클라이언트와의 지속적인 연결을 관리하며 불필요한 연결 종료를 줄일 수 있습니다.
2. 성능 최적화 및 네트워크 오버헤드 감소 요청-응답마다 TCP 연결을 새로 설정하면 불필요한 핸드셰이크 과정이 발생하고 네트워크 성능이 저하될 수 있습니다. keepalive를 적용하면 하나의 연결을 재사용하여 불필요한 연결 비용을 절감할 수 있습니다.
3. 실시간 애플리케이션에서의 활용 온라인 게임, 채팅 서비스, 금융 거래 시스템 등에서는 연결이 지속적으로 유지되어야 하며, 장애 발생 시 신속하게 감지하고 복구해야 합니다. 이때 keepalive와 heartbeat를 활용하면 사용자가 연결이 끊긴 상태인지 빠르게 확인할 수 있습니다.
4. 로드 밸런싱과 분산 시스템에서의 역할 대규모 웹 서비스에서는 여러 서버가 협력하여 요청을 처리하며, 각 서버의 상태를 주기적으로 확인해야 합니다. 이 과정에서 keepalive는 서버가 정상 동작 중인지 확인하는 데 중요한 역할을 합니다.
5. HTTP/2 및 WebSocket 기반의 지속적인 연결 관리 HTTP/2와 WebSocket은 기본적으로 지속적인 연결을 지원하므로, keepalive와 비슷한 개념이 적용됩니다. 이를 활용하면 더욱 효율적인 통신이 가능해집니다.

흥미로웠던 질문 : 웹 사이트 단위에서 자주 사용되는 페이지를 저장하는 캐싱은 http 요청 자체를 줄이기 때문에 Alive-Packet이 필요없지 않나?

• 캐싱이 http request 횟수를 줄이는것으로 인해 request 신규 연결 또는 Alive-Packet을 논할 연결점을 덜 논해도 되는건 사실이지만, 캐싱의 용량 자체가 사이트 전부를 담을 수 없고, 또 양쪽의 호스트가 캐싱된 데이터만 다룬다는 보장을 못해요. 그래서 request를 새롭게 하는 염두를 해야하고, Alive-Packet은 그 개념에서 제일 효율적인 방안으로 소개된 것 입니다.