[HTTP] HTTP 헤더에 따른 4가지 전송 방식

HTTP 헤더에 따른 전송 방식은 크게 단순, 압축, 분할, 범위 전송이 있다.

 

 

---

✅ 1. 단순 전송: Content-Length

 

서버가 본문 데이터의 전체 길이를 미리 계산해 Content-Length 헤더에 명시하고, 클라이언트가 해당 길이만큼 읽도록 전송하는 방식

 

📜 헤더 예시

Content-Length: 348

 

💡 동작 흐름

• 서버는 응답 본문을 모두 구성한 뒤, 전체 크기를 계산함
• Content-Length를 설정하고 응답을 전송
• 클라이언트는 정확히 해당 길이만큼 읽음

 

✅ 장점

• 가장 간단하고 보편적인 방식
• 중간 프록시, 로드 밸런서에서 쉽게 처리 가능

 

❌ 단점

• 스트리밍 불가 (콘텐츠 전체를 알고 있어야 함)
• 큰 파일일수록 메모리 부담이 생김

 

 

 

---

✅ 2. 압축 전송: Content-Encoding

 

본문 데이터를 압축하여 전송하고, 클라이언트가 해당 인코딩을 해제하여 원문을 복원하는 방식

 

📜 헤더 예시

Content-Encoding: gzip

 

💡 동작 흐름

• 서버는 원본 데이터를 gzip 등으로 압축
• 압축된 응답 본문 전송
• 클라이언트는 Content-Encoding을 보고 압축 해제(decode)

 

✅ 장점

• 트래픽 절감 (텍스트일수록 효과 큼)
• 빠른 전송 속도 (파일 크기가 작아지므로)

 

❌ 단점

• CPU 부담 증가 (압축/해제 연산)
• 클라이언트가 압축 해제 기능을 지원해야 함

 

 

 

---

✅ 3. 분할 전송: Transfer-Encoding: chunked

 

서버가 응답 본문을 미리 다 구성하지 않고, 여러 조각(chunk)으로 나누어 스트리밍처럼 전송하는 방식

서버는 전체 Content-Length를 모를 경우, 데이터를 여러 청크로 나누어 보낸다.

 

📜 헤더 예시

Transfer-Encoding: chunked

 

💡 청크 메시지 예시

7\r\n
Mozilla\r\n
9\r\n
Developer\r\n
7\r\n
Network\r\n
0\r\n
\r\n

• 각 청크는 [16진수 크기] + CRLF + 데이터 + CRLF
• 마지막 청크는 크기 0으로, 종료 표시

 

✅ 장점

• 서버가 콘텐츠 크기를 미리 알 필요 없음 → 실시간 스트리밍, 동적 응답 가능
• 서버가 처리 결과를 바로 전송할 수 있음 (지연 감소)
• 동적 콘텐츠에 적합

 

❌ 단점

• Content-Length와 동시에 사용 불가
• HTTP/1.1 이상에서만 지원
• 클라이언트가 청크 방식 처리 지원이 필요함
• 일부 프록시나 캐시 서버에서 호환되지 않을 수도 있음

 

 

 

---

✅ 4. 범위 전송: Range / Content-Range

 

클라이언트가 전체 리소스 중 일부 범위만 요청하고, 서버가 해당 범위만 응답하는 방식

 

📜 요청 헤더 예시

Range: bytes=1001-2000

• bytes=1001-2000 → 1001번째 바이트부터 2000바이트까지 요청
• bytes=500- → 500번째 바이트부터 끝까지 요청
• bytes=-500 → 마지막 500바이트 요청

 

📜 응답 헤더 예시

HTTP/1.1 206 Partial Content
Content-Range: bytes 1001-2000/4000
Content-Length: 1000

• 의미: 전체 리소스는 4000 바이트이고, 현재 1001~2000 바이트를 보냄

 

💡 동작 흐름

• 클라이언트가 특정 범위 지정 (Range)
• 서버가 수락 시 206 Partial Content 상태 코드와 함께 Content-Range 응답
• 응답 본문에는 해당 범위의 데이터만 포함됨

🔶 참고

• Range 단위는 기본적으로 바이트지만, 다른 단위도 확장 가능 (HTTP Range Units)
• 여러 범위를 요청할 수도 있다. (예: Range: bytes=0-499,1000-1499)
• 여러 범위 요청에 대한 응답은 multipart/byteranges 콘텐츠 타입 사용

 

✅ 장점

• 대용량 파일 전송 최적화 (중단된 다운로드 재개, 스트리밍 서비스)
• 특정 부분만 요청 가능 (예: PDF 5페이지만 보기)

 

❌ 단점

• 서버가 Range 지원 안 하면 무시됨
• 복수 범위 요청 시 처리가 복잡 (multipart/byteranges)

 

📘 206 Partial Content

• 클라이언트가 Range 요청을 보냈고, 서버가 이를 수락했을 경우 반환하는 상태 코드
• 응답에는 Content-Range 헤더가 필수로 포함됨

 

 

 

---

📊 비교 요약

전송 방식	헤더	용도	특징	사용 예시
단순 전송	Content-Length	기본 전송	본문 크기 명시	정적 콘텐츠 (HTML, JSON 등)
압축 전송	Content-Encoding	트래픽 절감	gzip, deflate 등	페이지 압축
분할 전송	Transfer-Encoding: chunked	스트리밍	본문을 실시간 조각 전송	실시간 SSE, 채팅
범위 전송	Range, Content-Range	부분 다운로드	원하는 범위만 전송	대용량 다운로드