TIL

HTTP 206 Partial Content의 비밀

하얀잔디 2026. 6. 25. 17:02

 

 

사내 동영상 파일 서버에서 다운로드가 왜 이렇게 기어가냐는 제보가 들어옴.

인프라팀에 확인해 보니까 QoS가 200Mbps로 잡혀 있었음..

초당 25MB 정도는 빠지는 대역폭이라 회선 자체가 대단히 쪼달리는 상황은 아닌 것 같았음.

 

대체 뭐가 문제인가 싶어 엑세스 로그(Access Log)부터 까봤는데, 좀 이상한 현상이 보임. 유저가 동영상 파일 하나를 요청했는데 로그가 달랑 한 줄 찍히는 게 아니라, 짧은 시간 동안 수십 번씩 연속으로 호출되는 묘한 상황이었음. 게다가 응답 코드는 익숙한 200 OK가 아니라 죄다 206 Partial Content로 찍히고 있었음.

 

 

HTTP 206...이 아니라 원래 그런 거였다 (HTTP 206 Status와 다중 호출의 원인)

 

HTTP 206 Partial Content가 뭐길래? 이건 브라우저나 플레이어 같은 클라이언트가 "나 이 파일 처음부터 끝까지 다 필요 없고, 딱 요만큼만(Range) 먼저 줘"라고 요청했을 때, 서버가 "ㅇㅋ, 요청한 조각(Chunk)만 잘라서 보낸다" 하고 응답하는 코드임.

 

그럼 왜 이렇게 로그가 여러 번 쪼개져서 찍혔을까? 동영상 스트리밍이나 대용량 파일을 받을 때, 요즘 브라우저들은 한방에 다운로드하지 않음. 효율적으로 버퍼링을 하려고 Range: bytes=0-1023 같은 헤더를 날리면서 야금야금 이어 받기를 시도함.

 

게다가 유저가 영상을 보다가 중간에 싱크를 뒤로 돌리거나(Seeking), 브라우저가 플레이어 버퍼를 채우려고 미리 뒷부분을 땡겨올 때마다 서버에 새로운 206 요청을 계속 때리게 됨.

 

결론적으로 로그에 호출이 무더기로 찍혔던 건 서버가 터지거나 에러가 난 게 아니라, 동영상 스트리밍 환경에서 아주 지극히 정상적인 동작이었음. 속도가 느린 진짜 원인은 206 코드가 아니라, 이 조각 요청들이 들어올 때 대역폭 제한(Throttling)이나 커넥션 쪽에 병목이 걸린 게 아닌가 싶음. 타임라인 따라서 조금 더 파봐야 할 듯.

'TIL' 카테고리의 다른 글

Google Calendar WebHook 연동 방법  (0) 2026.06.26
DB) AutoVaccumm이란  (0) 2026.06.19
온프레미스 Overlay vs AWS EKS VPC CNI 차이점 정리  (0) 2026.06.17
Kube)NodePort vs LoadBalancer  (0) 2026.06.17
Redis 모니터링 해보자  (0) 2026.06.12