WebSocket 온라인 테스트 도구
온라인 WebSocket 연결 테스트, 메시지 전송 및 수신 디버깅 도구
WebSocket이란?
WebSocket은 단일 TCP 연결상에서 전이중 통신을 위한 프로토콜입니다. HTTP와 달리 WebSocket 연결이 한번 설정되면 클라이언트와 서버는 언제든지 서로 데이터를 전송할 수 있고 반복적으로 연결을 설정할 필요가 없습니다. WebSocket은 실시간 채팅, 온라인 게임, 주식 시세, 협업 편집 등 실시간 데이터 교환이 필요한 시나리오에 자주 사용됩니다.
사용 방법
사용 방법
- URL 필드에 WebSocket 서버 주소를 입력하세요 (ws:// 또는 wss://)
- 선택 사항: 서브프로토콜을 입력하세요, 여러 개는 쉼표로 구분
- WebSocket 연결을 시작하려면 '연결'을 클릭하세요
- 입력란에 메시지 내용을 입력하세요
- 메시지 유형을 선택하세요(텍스트 또는 JSON). JSON 유형은 형식을 자동으로 검증합니다
- 메시지를 보내려면 '보내기'를 클릭하거나 Ctrl + Enter를 누르세요
- 메시지 목록에서 송수신 메시지를 확인하고 클릭하여 복사하세요
연결 팁
- HTTPS 페이지에서 테스트할 때는 wss://를 사용하세요. 브라우저는 보안 출처에서의 안전하지 않은 ws:// 연결을 차단하는 경우가 많습니다
- 디버깅 중 연결 해제, 새로 고침, 엔드포인트 전환 전에 중요한 메시지 로그를 내보내거나 복사해 두세요
활용 사례
기술 원리
WebSocket 프로토콜의 핵심은 HTTP 업그레이드입니다. 클라이언트는 먼저 일반 HTTP GET 요청을 보내지만, Upgrade: websocket 및 Connection: Upgrade 헤더와 무작위로 생성된 Sec-WebSocket-Key를 포함합니다. 서버는 이 헤더를 검증한 뒤, Key에 고정 GUID를 연결한 값의 SHA-1을 Base64로 인코딩한 Sec-WebSocket-Accept 값을 포함하여 101 Switching Protocols로 응답합니다. 101 응답 이후 TCP 연결은 HTTP에서 WebSocket으로 전환되며, 이후 데이터는 WebSocket 프레임으로 전송됩니다. WebSocket 프레임 헤더는 최소 2바이트이며, FIN 플래그, opcode(0x1 텍스트, 0x2 바이너리, 0x8 닫기, 0x9 핑, 0xA 퐁), 그리고 페이로드 길이를 포함합니다. ping/pong 프레임은 하트비트 감지에 사용되며, 브라우저 API는 자동으로 전송하지 않으므로 애플리케이션 계층에서 구현해야 합니다. wss://는 HTTPS+WebSocket에 해당하며, 먼저 TLS 핸드셰이크를 수행한 뒤 WebSocket 업그레이드를 진행합니다. ws://는 평문이며, 브라우저는 https 페이지에서 ws:// 엔드포인트를 거부하여 다운그레이드 공격을 방지합니다. 단일 프레임은 기본적으로 약 1MB로 제한되며, 더 긴 메시지는 여러 프레임으로 분할됩니다.
- 핸드셰이크: 클라이언트가 Upgrade: websocket 헤더가 포함된 HTTP GET을 보내면, 서버는 101 Switching Protocols를 반환하여 업그레이드 성공을 알림
- Sec-WebSocket-Key는 브라우저가 무작위로 생성하는 16바이트 Base64 문자열; 서버는 고정 GUID를 연결하고 SHA-1을 취한 뒤 Sec-WebSocket-Accept로 검증
- 프레이밍: 모든 프레임은 최소 2바이트의 헤더를 가지며, FIN, opcode(텍스트/바이너리/핑/퐁/닫기), 페이로드 길이를 포함
- ws://는 평문, wss://는 HTTPS 위의 WebSocket; 브라우저는 https 사이트에서 ws://를 거부하여 다운그레이드 공격을 방지
- 하트비트용 ping/pong 프레임: RFC 6455는 모든 ping에 대해 pong 응답을 요구; 브라우저는 하트비트를 자동 전송하지 않으므로 애플리케이션이 구현해야 함
- 닫기 시퀀스: 양쪽 중 한쪽이 상태 코드가 포함된 0x8 닫기 프레임을 보내면 상대방이 일치하는 닫기 프레임으로 응답하고, 그제서야 TCP 연결이 실제로 해제됨
예시
퍼블릭 Echo 서비스 연결
wss://echo.websocket.org — 101 Switching Protocols 핸드셰이크 성공, "hello" 전송 시 즉시 "hello"가 그대로 echo됨자체 WebSocket 서비스 디버깅
wss://api.example.com/ws — 서브프로토콜 graphql-ws, 연결 성공, 구독 메시지 정상 수신연결 끊김 재현
wss://api.example.com/ws — 연결 수립 30초 후 서버가 능동적으로 연결을 종료, close code 1006 (비정상 종료)자주 묻는 질문
WebSocket 테스터는 무엇을 하나요?
임의의 ws:// 또는 wss:// 엔드포인트에 연결하고, 메시지를 주고받으며 프로토콜 교환을 검사할 수 있게 해줍니다. 개발 중인 WebSocket API, MQTT-over-WS 브로커, 실시간 게임 서버, 채팅 시스템, 주식 시세 피드 테스트에 유용합니다.
메시지가 저희 서버를 통해 전송되나요?
아니요. 브라우저는 WebSocket 연결을 대상 호스트에 직접 엽니다. 중간 매개체도, 저희 측 로깅도 없습니다. 대상 호스트는 다른 클라이언트와 마찬가지로 사용자의 IP를 보게 됩니다.
왜 localhost 엔드포인트에 연결되지 않나요?
혼합 콘텐츠 규칙 때문입니다: 이 페이지가 HTTPS로 제공되면 브라우저는 ws://(비보안) 연결을 차단합니다. 대상에 wss://를 사용하거나, 로컬 테스트를 위해 이 페이지를 일반 HTTP로 실행하세요. 브라우저 콘솔에 정확한 거부 이유가 표시됩니다.
바이너리 데이터를 보낼 수 있나요?
네. 대부분의 빌드는 텍스트 프레임과 바이너리 프레임을 모두 지원합니다. 바이너리 입력은 보통 Base64나 16진수이며, 페이지가 전송 전에 디코딩합니다. 바이너리 응답 표시는 기본적으로 16진수나 Base64를 사용합니다.
커스텀 헤더는 어떻게 추가하나요?
브라우저 WebSocket API는 커스텀 헤더를 허용하지 않습니다 — 이는 웹 플랫폼의 제약입니다. 설정할 수 있는 헤더는 Sec-WebSocket-Protocol(서브프로토콜)뿐입니다. Bearer 토큰 인증의 경우 쿼리 매개변수나 첫 메시지 인증을 사용하세요. 일부 서버는 Cookie를 받기도 합니다.
압축과 확장도 테스트할 수 있나요?
브라우저는 per-message-deflate를 광고하는 서버와 자동으로 협상합니다. 페이지는 보통 협상된 확장을 표시합니다. 커스텀 확장은 테스트할 수 없습니다 — 브라우저가 그 수준의 제어를 노출하지 않기 때문입니다.
왜 연결이 자꾸 끊어지나요?
흔한 원인: 서버의 유휴 타임아웃(보통 30~120초), 프록시/로드밸런서 타임아웃, 네트워크 중단, 노트북 절전 모드 진입 등입니다. 최신 WebSocket은 ping/pong 하트비트가 필요합니다 — 서버가 ping을 보내고 있는지 확인하거나, 클라이언트가 주기적으로 메시지를 보내도록 하세요.