웹소켓 프레임 크기 계산기
페이로드 크기에서 웹소켓 프레임의 헤더 크기와 오버헤드를 계산합니다. 길이 필드가 계단식으로 뛰는 지점과 묶어 보낼 때의 절감량도 함께 냅니다.
10 B입니다
데이터 프레임입니다. 길이 제한이 없습니다
프레임 하나의 크기
16 B
헤더 6바이트 + 페이로드 10바이트. 헤더가 37.5%를 차지합니다
페이로드에 따른 헤더 계단
| 페이로드 | 클라이언트 | 서버 | 오버헤드 (클라) |
|---|---|---|---|
| 0 B | 6 B | 2 B | 100% |
| 1 B | 6 B | 2 B | 85.7% |
| 10 B | 6 B | 2 B | 37.5% |
| 125 B | 6 B | 2 B | 4.6% |
| 126 B | 8 B | 4 B | 6% |
| 1,000 B | 8 B | 4 B | 0.8% |
| 65,535 B | 8 B | 4 B | 0% |
| 65,536 B | 14 B | 10 B | 0% |
| 1,000,000 B | 14 B | 10 B | 0% |
125 → 126과 65,535 → 65,536에서 헤더가 뜁니다. 같은 크기라도 클라이언트가 보내면 마스킹 키 4바이트가 더 붙습니다.
사용 방법
- 1페이로드 크기를 넣습니다.
- 2누가 보내는지 고릅니다. 클라이언트가 보내면 마스킹 키 4바이트가 더 붙습니다.
- 3메시지 수를 넣으면 전체 트래픽과 묶어 보낼 때의 절감량이 나옵니다.
자주 묻는 질문
2바이트에서 14바이트까지입니다. 기본 헤더 2바이트에 페이로드 길이에 따른 확장 필드 0·2·8바이트, 클라이언트가 보낼 때의 마스킹 키 4바이트가 더해집니다. 작은 메시지를 서버가 보내면 2바이트, 클라이언트가 보내면 6바이트가 됩니다.
7비트 길이 필드에서 126과 127이 길이가 아니라 "뒤에 더 있다"는 표시로 예약되어 있기 때문입니다. 125까지는 그대로 적고, 126이 적혀 있으면 뒤의 16비트를, 127이면 뒤의 64비트를 더 읽습니다. 그래서 페이로드가 125에서 126으로 한 바이트 늘 때 헤더가 2바이트, 65,535에서 65,536으로 넘을 때 6바이트 뜁니다.
중간의 프록시가 웹소켓 트래픽을 HTTP 요청으로 오인해 캐시를 오염시키는 공격을 막기 위해서입니다. 선택이 아니라 의무이고, 마스킹하지 않은 프레임을 받은 서버는 연결을 끊어야 합니다. 반대로 서버는 마스킹하면 안 되므로, 같은 크기의 메시지라도 보내는 쪽에 따라 헤더가 4바이트 차이 납니다.
10바이트 메시지를 클라이언트에서 보내면 헤더가 6바이트라 전체의 37.5%가 헤더입니다. 100개를 따로 보내면 1,600바이트지만 한 프레임으로 묶으면 1,008바이트로 37% 줄어듭니다. 좌표나 하트비트처럼 작은 메시지를 자주 보내는 구조에서는 묶어 보내는 효과가 큽니다.
close·ping·pong은 페이로드가 125바이트를 넘을 수 없고 조각내서 보낼 수도 없습니다. 확장 길이 필드를 쓸 수 없다는 뜻이라 헤더가 항상 2바이트(서버) 또는 6바이트(클라이언트)로 고정됩니다.
다릅니다. 여기서 세는 것은 웹소켓 프레임까지이고, 실제로는 TCP·IP 헤더가 패킷마다 더 붙고 TLS를 쓰면 레코드 헤더와 인증 태그도 붙습니다. 작은 메시지에서는 이쪽이 웹소켓 헤더보다 크므로 실제 트래픽을 따지실 때는 함께 보셔야 합니다.
전송되지 않습니다. 모든 계산은 브라우저 안에서만 이루어지고, 넣으신 값은 이 기기를 벗어나지 않습니다.
알아두면 좋은 점
- RFC 6455 §5.2를 기준으로 합니다.
- permessage-deflate 같은 확장을 쓰면 페이로드가 압축되어 실제 크기가 달라집니다. 이 계산기는 압축하지 않은 경우를 봅니다.
- TCP·IP·TLS 헤더는 들어 있지 않습니다. 작은 메시지에서는 그쪽이 더 클 수 있습니다.
함께 보면 좋은 도구
마지막 검증: 2026년 8월 31일 · 결과는 참고용 추정치입니다.