CS/Server.md at main · sehynn/CS

핸드셰이크

두 개의 장치가 본격적인 데이터 통신을 시작하기 전, 연결 설정 및 데이터 교환 규칙(통신 속도, 보안 설정 등)을 협상하는 사전 동기화 과정

기존의 HTTP는 요청을 보내야 응답이 오는 connectionless와 stateless 방식 새로운 정보를 받아오려면 먼저 요청을 보내야만 합니다. 지속적으로 받아올 새로운 정보가 있는지 확인해야 하는 경우에는 계속 요청을 보내야 합니다.

날씨나 차트 같은 실시간 정보를 모니터링 하려면 주기적으로 요청을 보내서 데이터를 갱신해야 합니다.

이러한 단점을 보완하기 위해 웹소켓이 탄생합니다.

웹소켓은 Transport protocol의 일종으로 양방향 소통을 위한 규약입니다.

요청을 먼저 보내지 않으면 데이터를 받아올 수 없었던 기존의 방식에서 벗어나 실시간 양방향 소통이 가능하게 해줍니다.

채팅이나 게임, 증권거래 등 실시간 서비스에서 많이 사용됩니다.

HTTP로 시작해서 Upgrade: websocket 헤더로 한 번 핸드셰이크하고, 그 뒤로는 같은 TCP 커넥션을 계속 열어둔 채 **양방향(full-duplex)**으로 데이터를 주고받는 프로토콜입니다.
HTTP처럼 매번 요청-응답이 아니라, 서버가 먼저 클라이언트에 데이터를 밀어넣을 수 있어요(new_message가 그렇게 옵니다). 이게 채팅이 "polling 안 하고 실시간"인 이유입니다.
연결이 상태를 가진(stateful) 연결이라는 게 핵심 — HTTP 요청은 매번 독립적이지만, WebSocket 연결은 "이 소켓이 곧 이 유저"라는 매핑이 서버 메모리에 생깁니다. 이게 우리가 계속 얘기한 "노드가 여러 개면 이 매핑이 노드마다 따로 논다"는 문제의 근본 원인이에요.

자동 재연결: 연결 끊기면 지수 백오프로 알아서 재시도. 우리 설계의 "1초→2초→4초..." 재연결 로직이 이걸 그대로 씀.
Room: 소켓을 그룹으로 묶어서 io.to(roomName).emit()으로 한 번에 보낼 수 있는 기능. 근데 지난번에 확인했듯 우리 SRS는 이걸 메시지 배달엔 안 쓰고(사용자 기반), 타이핑/읽음처럼 "지금 보고 있는 사람들끼리"만 쓰는 용도로 좁혀놨죠 — 이것도 Room이 뭔지 알아야 그 설계 결정이 왜 그렇게 나뉘었는지 이해가 됩니다.
Adapter (우리는 Redis/Valkey adapter): Socket.IO 서버가 여러 개(멀티노드)일 때, 노드1이 가진 소켓 목록을 노드2는 모릅니다. Adapter가 Valkey pub/sub으로 "누가 어느 room에 있는지, emit 명령을 다른 노드에도 전파"해주는 역할. 이게 없으면 sticky session(같은 유저를 항상 같은 노드로) 강제해야 하는데, 그럼 로드밸런싱이 망가지고 노드 하나 죽으면 그 방 전체가 끊깁니다.
Heartbeat (ping/pong): TCP 연결이 죽었는지 서버가 주기적으로 확인하는 메커니즘. 우리 설계에서 "클라이언트가 따로 heartbeat 안 보내도 됨"이라고 한 게 이거 — Socket.IO가 기본으로 해줍니다.
네임스페이스: 우리는 안 썼지만, 하나의 연결 위에 여러 논리적 채널을 분리하는 기능도 있습니다 (참고로만).

room vs 사용자 기반 배달: Room이 "지금 join한 사람에게만 간다"는 걸 알아야, SRS의 "채팅방 입장 시에만 Room Join" + "메시지는 Room 기반 아닌 사용자 기반"이라는 문장이 왜 짝을 이루는지 이해됩니다. Room에 없는 Idle 유저도 메시지를 받아야 하니까, 메시지는 room으로 못 보내고 참여자 개개인의 소켓으로 직접 쏴야 하는 거죠.
멀티노드에서 상태를 어디 둘지: 소켓이 "이 노드의 메모리에만 존재"한다는 걸 알아야, 왜 연결 상태·제재 목록·rate limit을 전부 Valkey로 빼야 하는지가 자연스럽게 나옵니다.
재연결 시 유실 처리: WebSocket이 끊기면 그 사이 서버가 보낸 메시지는 그냥 사라진다는 걸 알아야, "재연결 갭 채우기"(lastMessageId 기반 동기화)가 왜 필수 요구사항인지 이해됩니다.