01
한 방향으로 모으기
방향 옵션은 클라이언트의 마스크 누락 또는 서버의 마스크 사용을 경고합니다. 미지정은 이 검사만 생략합니다. 양방향 대화를 자동으로 나누지는 않으므로 같은 방향의 프레임을 순서대로 넣으세요.
프로토콜 / 바이너리 직렬화
WebSocket 프레임 분석바이트 경계를 확인하세요
프레임 헤더부터 시작하는 16진수를 넣으세요. 마스크, 분할, 잘린 입력 예제를 제공합니다.
WebSocket 프레임 분석
헤더부터 입력: 81 05 48 65 6c 6c 6f. 완전한 바이트를 공백, 쉼표, 콜론으로 나눌 수 있습니다. 0x는 한 바이트에만 붙입니다.
결과
바이트를 입력하거나 예제를 선택하세요.
현재 브라우저 탭에서 처리하며 입력을 전송하거나 저장하지 않습니다.
옵션
바이트를 입력하거나 예제를 선택하세요.
웹소켓 프레임은 애플리케이션 메시지와 항상 일대일로 대응하지 않습니다. WebSocket 프레임 분석은 각 시작 위치를 보존해 두 조각 사이의 ping을 데이터와 구별합니다. 다음 헤더 위치가 예상과 다르다면 선언 길이와 실제 캡처를 비교할 수 있습니다.
브라우저 메시지 이벤트는 대개 헤더를 제거한 데이터를 제공합니다. 원시 프레임을 조사하려면 HTTP 업그레이드 이후의 바이트가 필요합니다. 메시지 문자열이나 TCP 패킷 전체를 프레임으로 해석하면 처음부터 잘못된 필드를 읽게 됩니다.
WebSocket 프레임 분석이 필요한 순간
첫 프레임 이후도 확인
WebSocket 프레임 분석은 헤더와 페이로드 길이를 따라 다음 프레임으로 이동합니다. 뒤쪽 입력이 잘리면 앞서 완성된 프레임은 남기고 내보내기를 막습니다. 부분 캡처가 정상적인 전체 보고서처럼 복사되는 일을 줄입니다.
마스크 전후를 나란히 보기
WebSocket 마스킹은 네 바이트 키를 페이로드에 반복해서 XOR하는 과정입니다. 전송된 바이트와 복원된 바이트를 따로 보여 주며, 새 프레임에서는 그 프레임 키의 처음부터 다시 적용합니다. 길이는 달라지지 않습니다.
캡처를 읽기 전에 확인할 세 가지
02
미리보기와 누락 구별하기
페이로드는 256바이트까지 미리 보여 줍니다. 헤더가 선언한 길이에 입력이 못 미치는 것은 별개의 구조 오류입니다. 미리보기 제한은 전체 보고서에 영향을 주지 않지만 누락된 프레임은 내보내기를 막습니다.
03
갱신 시점 정하기
자동 모드는 수정 후 350ms 뒤 실행됩니다. 끄면 분석 버튼과 Ctrl/Cmd+Enter를 사용할 수 있습니다. 바이트나 방향을 바꾸면 기존 결과를 즉시 복사할 수 없게 됩니다. 예제와 지우기는 변경량을 확인한 뒤 적용하고 입력과 결과를 한 번 되돌릴 수 있습니다.
헤더와 페이로드를 함께 조사
확장 길이 읽기
7비트 길이 또는 네트워크 바이트 순서의 16·64비트 확장 길이를 읽습니다. 큰 선언 값은 정밀도를 유지한 정수로 제한과 비교한 뒤 처리합니다. 최소 형식을 쓰지 않은 길이도 지우지 않고 경고합니다.
제어 프레임 분리
close, ping, pong을 데이터 프레임과 구별합니다. 종료 페이로드의 앞 두 바이트는 코드, 나머지는 UTF-8 이유입니다. 제어 프레임 분할, 과도한 길이, 부적절한 종료 값을 표시하지만 정상 종료 여부를 증명하지는 않습니다.
문자열 해석 구분
완전한 단독 텍스트 프레임은 엄격한 UTF-8로 검사합니다. 바이너리 프레임의 읽을 수 있는 텍스트는 참고용입니다. 분할 조각과 확장 페이로드를 완전한 문자열처럼 표시하지 않으며 미리보기 경계의 반쪽 문자도 출력하지 않습니다.
오류 위치 유지
헤더, 확장 길이, 마스크 키, 페이로드 부족은 바이트 오프셋과 입력 행·열을 남기고 중단합니다. 앞의 완전한 프레임은 계속 볼 수 있습니다. RSV나 예약 opcode는 바이트 경계를 알 수 있으므로 경고와 함께 유지합니다.
처리 범위와 제외 사항
- 16진수 입력만 지원
- 연속된 짝수 자릿수 또는 공백·쉼표·콜론으로 구분한 완전한 바이트를 받습니다. 0x 접두사는 바이트 하나에만 붙습니다. Base64, 비트 문자열, 파일, 주소 열이 포함된 hexdump는 지원하지 않습니다.
- 분할 메시지는 합치지 않음
- 시작·계속·끝·첫 조각 누락·미완료를 표시하며 제어 프레임은 진행 중인 분할을 끝내지 않습니다. 여러 조각을 합치거나 조각 사이의 UTF-8를 검증하지 않습니다. 프레임 분석 성공과 메시지 전체의 유효성은 다릅니다.
- 확장과 상위 프로토콜 제외
- RSV를 보고 협상 내용을 추측하지 않습니다. permessage-deflate 압축 해제, TLS 복호화, JSON·Socket.IO·Protobuf 자동 해석은 하지 않습니다. 마스크 해제는 되돌릴 수 있는 XOR이며 암호 해독이 아닙니다.
- 입력과 표시 제한
- 디코딩한 입력은 1MiB, 입력 문자는 6MiB, 프레임은 1000개까지입니다. 개별 선언 페이로드도 1MiB로 제한합니다. 화면은 50개씩 펼치며 JSON 보고서에는 256바이트 미리보기를 넘어선 전체 페이로드와 가능한 텍스트가 담깁니다.
- 경고를 고치지 않고 보존
- 프로토콜 경고는 보고서로 내보낼 수 있고 구조 오류는 내보내기를 막습니다. 길이, 마스크, opcode를 임의로 수정하지 않습니다. 종료 코드 범위 검사는 앱 등록이나 양측의 종료 핸드셰이크를 확인하지 않습니다.
WebSocket 프레임 분석 질문
클라이언트 페이로드를 마스킹하는 이유는 무엇인가요?
클라이언트가 중간 장비를 혼동시키는 전송 바이트를 자유롭게 만들지 못하도록 네 바이트 키로 XOR합니다. 같은 연산으로 복원하며 키도 프레임에 들어 있으므로 비밀을 지켜 주지는 않습니다. 기본 규격에서 서버 프레임은 마스크를 쓰지 않습니다.
페이로드 길이의 126과 127은 무슨 뜻인가요?
126과 127은 실제 크기가 아니라 뒤의 두 바이트 또는 여덟 바이트를 길이로 읽으라는 표시입니다. 빅엔디언으로 읽고 64비트 형식의 최상위 비트는 0이어야 합니다. 길이에는 헤더와 마스크 키가 포함되지 않습니다.
여러 프레임을 한 번에 붙여 넣을 수 있나요?
가능합니다. 같은 방향의 연속 프레임을 전송 순서로 넣으세요. 빈 페이로드와 사이에 낀 제어 프레임도 별도로 표시합니다. 불완전한 프레임이 있으면 캡처를 보완해야 전체 보고서를 내보낼 수 있습니다.
종료 프레임은 어떻게 해석하나요?
빈 페이로드에는 종료 코드가 없습니다. 그 외에는 앞 두 바이트가 코드이고 나머지가 UTF-8 이유입니다. 한 바이트뿐이거나 전송 금지 코드, 잘못된 UTF-8가 있으면 경고합니다. 비어 있는 close를 정상 종료로 채우지 않습니다.
WebSocket의 HTTP 핸드셰이크도 디코딩하나요?
지원하지 않습니다. HTTP Upgrade 요청과 응답은 프레임 전 단계입니다. 이후의 원시 프레임 바이트를 먼저 추출하세요. TCP/IP나 TLS 외곽을 제거하거나 서버에 연결해 핸드셰이크를 검증하지 않습니다.
계산 또는 검증 오류를 발견했나요?