반응형
    이 시리즈는 그림으로 배우는Http&Network Basic을 읽고 스터디 하면서 정리한 내용입니다.
    추가적으로 포함되어 있는 내용은 GPT 를 이용하여서 정리한 내용으로 참고해주시면 감사하겠습니다.

    3.1.HTTP 메시지

    1. HTTP 메시지의 구성 요소

    크게 리퀘스트 메시지(Request Message) 와 리스폰스 메시지(Response Message) 두 가지 유형이 있다.
    각 메시지는 메시지 헤더(Header)와 메시지 바디(Body) 로 나뉘며,
    헤더와 바디 사이에는 개행 문자 CRLF (\r\n) 로 구분한다.

    3.2. 리퀘스트 메세지와 리스폰스 메세지의 구조

    1️⃣ 리퀘스트 메시지 (Request Message)

    클라이언트가 서버에 요청을 보낼 때 사용되는 메시지

    GET /index.html HTTP/1.1\r\n
Host: www.example.com\r\n
User-Agent: Mozilla/5.0\r\n
\r\n
(요청 바디, 필요 없는 경우 생략)
     

    구성 요소

    • 요청 라인(Request Line)
      • GET /index.html HTTP/1.1
      • 요청 메서드 (GET, POST, PUT 등), URL 경로, HTTP 버전 포함
    • 헤더(Header)
      • Host: www.example.com → 요청하는 서버
      • User-Agent: Mozilla/5.0 → 클라이언트 정보
    • 공백 라인 (\r\n) → 헤더와 바디를 구분
    • 바디(Body)
      • GET, DELETE 요청에서는 보통 바디가 없음
      • POST, PUT 요청에서는 실제 전송할 데이터를 포함

     

    2️⃣ 리스폰스 메시지 (Response Message)

    서버가 클라이언트 요청에 응답할 때 사용되는 메시지

    HTTP/1.1 200 OK\r\n
Content-Type: text/html\r\n
Content-Length: 342\r\n
\r\n
<html>...</html>

    구성 요소

    • 상태 라인 (Status Line)
      • HTTP/1.1 200 OK
      • HTTP 버전, 상태 코드 (200, 404 등), 상태 메시지 포함
    • 헤더(Header)
      • Content-Type: text/html → 응답 데이터 타입
      • Content-Length: 342 → 바디 크기
    • 공백 라인 (\r\n) → 헤더와 바디를 구분
    • 바디(Body)
      • 요청한 데이터를 포함 (HTML, JSON, 이미지 등)

    🔹 HTTP/1.1 vs HTTP/2의 차이

    • HTTP/1.1은 텍스트 기반 프로토콜이라 줄바꿈(CRLF)이 필요했음.
    • HTTP/2와 HTTP/3는 이진(Binary) 프로토콜이라 데이터 구조가 정해져 있어 CRLF 없이도 헤더와 본문을 구분할 수 있음.

    즉, HTTP/2에서는 데이터를 프레임이라는 정해진 형식에 맞게 나눠서 전송하는데, 이것이 HTTP/1.1과의 가장 큰 차이점이다.

    +-----------------------------------------------+
| Length (3 bytes) | Type (1 byte) | Flags (1 byte) |
+-----------------------------------------------+
| Stream Identifier (4 bytes)                   |
+-----------------------------------------------+
| Frame Payload (variable length)               |
+-----------------------------------------------+

     

     

    3.3. 인코딩으로 전송 효율을 높이다.

    1. 메시지 바디 (Message Body)
      • HTTP 메시지(요청 또는 응답)의 본문으로, 실제 데이터를 포함합니다.
      • 메시지 헤더와는 별개로 존재하며, Content-Length 또는 Transfer-Encoding을 통해 크기나 인코딩 방식을 지정할 수 있습니다.
    2. 엔티티 바디 (Entity Body)
      • 원본 리소스의 콘텐츠를 의미하며, 메시지 바디와 동일할 수 있습니다.
      • 하지만 Transfer-Encoding이 적용될 경우, 메시지 바디는 전송을 위해 인코딩된 상태이고, 이를 디코딩한 것이 엔티티 바디입니다.

    결론적으로, 메시지 바디는 전송을 위한 바디이고, 엔티티 바디는 실질적인 콘텐츠입니다. 전송 인코딩이 없는 경우에는 두 개념이 동일하지만, 전송 인코딩이 적용되면 차이가 발생합니다

     

    🔹 주요 콘텐츠 코딩(Content Coding) 방식

     

    콘텐츠 코딩(Content Coding)은 HTTP에서 데이터를 압축하는 방식이다. 쉽게 말해, 서버가 데이터를 줄여서 보내고, 클라이언트가 다시 압축을 풀어 원래 데이터로 복원하는 방식이다.

    다음은 HTTP에서 사용되는 주요 콘텐츠 코딩 방식이다

    콘텐츠 코딩 값 설명
    gzip GNU zip 방식으로 압축 (가장 많이 사용됨)
    deflate zlib 형식의 DEFLATE 압축
    br Brotli 압축 (HTTP/2에서 널리 사용)
    compress Lempel-Ziv-Welch (LZW) 방식 (거의 사용되지 않음)
    identity 콘텐츠 변형 없음 (기본값)

     

    🔹 청크 전송 코딩(Chunked Transfer Coding) 방식

    청크 전송 코딩(Chunked Transfer Encoding)은 HTTP에서 응답 데이터를 일정한 크기(청크)로 나누어 전송하는 방식이다.
    즉, 데이터를 한 번에 전송하는 것이 아니라 조각(chunk) 단위로 나누어 보내는 방식이다.

     

    • 데이터 크기를 미리 알 수 없는 경우
      • 일반적으로 Content-Length 헤더를 사용해 데이터 크기를 미리 알려줘야 하지만, 동적으로 생성되는 데이터(예: 실시간 스트리밍)는 크기를 미리 알 수 없음.
      • 청크 방식이면 크기를 몰라도 바로 전송 가능.
    • 빠른 응답 가능
      • 모든 데이터를 준비한 후 한 번에 보내는 대신, 일부 데이터를 먼저 보내고 나머지를 계속 전송할 수 있음.
    • 메모리 절약
      • 서버가 전체 데이터를 한꺼번에 보관하지 않고, 생성되는 대로 나눠서 전송 가능.

     

    콘텐츠 코딩 엔티티 바디를 압축하여 저장 및 전송 최적화  Content-Encoding: gzip
    전송 코딩 메시지 조각으로 나눠 전송 Transfer-Encoding: chunked

     

     

    3.4. 여러 데이터를 보내는 멀티파트

    멀티파트(Multipart)는 HTTP에서 여러 개의 데이터를 한 번의 요청이나 응답으로 전송할 때 사용하는 방식이다.
    주로 파일 업로드, 이메일 전송(MIME), API에서 여러 데이터 전송 등에 사용됩니다.

     

    • 여러 개의 파일, 텍스트 데이터를 동시에 전송 가능
      • 예: 텍스트 데이터 + 이미지 파일 전송
    • 각 파트(part)가 고유한 헤더를 가짐
      • 각 데이터마다 Content-Type 등을 설정 가능
    • 경계를 나타내는 boundary 사용
      • 데이터를 구분하기 위해 고유한 문자열(boundary)을 사용

    📌 주요 멀티파트 타입

    타입 설명 사용예시
    multipart/form-data 파일 업로드 등 폼 데이터를 포함하는 요청 HTML 폼 업로드, REST API 파일 전송
    multipart/mixed 여러 개의 데이터를 포함하는 응답 이메일 첨부 파일, JSON + 이미지 응답
    multipart/alternative 동일한 콘텐츠의 여러 포맷 제공 이메일(텍스트 & HTML 버전)
    multipart/related 서로 연결된 데이터를 한 번에 전송 HTML + 이미지 포함 이메일 
    POST /upload HTTP/1.1
Host: example.com
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW

------WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="username"

alice
------WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="file"; filename="example.jpg"
Content-Type: image/jpeg

(binary image data)
------WebKitFormBoundary7MA4YWxkTrZu0gW--

     

    1️⃣ Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW**boundary(경계 문자열)**을 사용하여 각 데이터를 구분
    2️⃣ 각 ------WebKitFormBoundary7MA4YWxkTrZu0gW 사이에 데이터 블록이 존재
    3️⃣ Content-Disposition 헤더
      . name="username" → 해당 필드는 "username" 입력값
      . name="file"; filename="example.jpg" → 파일 업로드 (이름: example.jpg)
    4️⃣ 마지막에는 --을 붙여 종료 표시 (------WebKitFormBoundary7MA4YWxkTrZu0gW--)

     

     

     

    3.5. 일부분만 받는 레인지 리퀘스트

     

    레인지 리퀘스트(Range Request)는 HTTP에서 파일의 일부(특정 바이트 범위)만 요청하는 기능
    대용량 파일을 한 번에 다운로드하지 않고 부분적으로 다운로드 가능하게 하다.

    • 대용량 파일 다운로드 최적화
      • 전체 파일을 받지 않고 일부만 요청 가능
      • 예: 동영상 스트리밍, 대용량 소프트웨어 다운로드
    • 다운로드 중단 후 이어받기 지원
      • 예: 인터넷 연결이 끊어졌을 때 중단된 부분부터 다시 다운로드 가능
    • 병렬 다운로드 가능
      • 여러 개의 레인지 요청을 보내서 파일을 여러 조각으로 나누어 빠르게 다운로드 가능

    1️⃣ 클라이언트가 파일의 일부만 요청하는 경우

     
    GET /largefile.zip HTTP/1.1
Host: example.com
Range: bytes=0-999,2000-2999

    2️⃣ 서버 응답

    HTTP/1.1 206 Partial Content
Content-Type: multipart/byteranges; boundary=BOUNDARY

--BOUNDARY
Content-Range: bytes 0-999/500000
Content-Type: application/zip

(binary data)

--BOUNDARY
Content-Range: bytes 2000-2999/500000
Content-Type: application/zip

(binary data)
--BOUNDARY--

    ➡️ multipart/byteranges 형식으로 여러 개의 범위를 따로 응답

     

     

     

    3.6. 최적의 콘텐츠를 돌려주는 콘텐츠 네고시에이션

    콘텐츠 네고시에이션(Content Negotiation)은 클라이언트가 원하는 콘텐츠 형식(언어, 인코딩, 미디어 타입 등)을 서버와 협상하여 최적의 응답을 받는 과정이다.

    즉, 클라이언트가 요청할 때 자신이 원하는 형식을 명시하면, 서버가 가장 적절한 응답을 선택해서 보내는 방식입니다.

     

     

    • 서버 주도(Server-driven) 네고시에이션
      • 클라이언트가 요청 헤더에 원하는 포맷을 포함하면, 서버가 최적의 응답을 결정해서 반환.
      • 예: 브라우저가 Accept-Language: ko-KR을 보내면, 서버가 한국어 페이지 제공.
    • 에이전트 주도(User Agent-driven, Client-driven) 네고시에이션
      • 서버가 여러 옵션을 제공하면, 클라이언트가 직접 원하는 것을 선택.
      • 예: 웹사이트에서 사용자가 언어(한국어/영어)를 선택하는 방식.
    • 투명(Transparent) 네고시에이션
      • 서버와 클라이언트가 협력하여 최적의 응답을 찾는 방식.
      • 거의 사용되지 않음.

     

    반응형

    'Study Platform📚 > 그림으로 배우는 Http&Network Basic' 카테고리의 다른 글

    그림으로 배우는 Http&Network Basic 정리 - 5장. HTTP와 연계하는 웹 서버  (0) 2025.02.18
    그림으로 배우는 Http&Network Basic 정리 - 4장. 결과를 전달하는 HTTP 상태 코드  (0) 2025.02.16
    그림으로 배우는 Http&Network Basic 정리 - 2장. 간단한 프로토콜 HTTP  (0) 2025.02.11
    JWT(Json Web Tool) 작동원리와 Refresh Token  (0) 2025.02.11
    그림으로 배우는 Http&Network Basic 정리 - 1장. 웹과 네트워크 기본에 대해 알아보자  (0) 2025.02.06

    티스토리툴바