HTTP 기본 지식

Spring Boot로 웹 애플리케이션을 만들기 전에, 웹이 데이터를 주고받는 규칙인 HTTP를 이해해야 한다. 브라우저 주소창에 URL을 입력하면 어떤 일이 벌어지는지, 서버는 무엇을 받아 무엇을 돌려주는지를 알면 스프링이 처리하는 일이 훨씬 명확해진다.

브라우저에 https://example.com을 입력한 순간부터 화면이 그려지기까지, 전체 흐름은 다음과 같다.

sequenceDiagram
    participant B as 브라우저
    participant D as DNS 서버
    participant S as 웹 서버
    B->>D: ① 도메인 → IP 주소 조회 (example.com?)
    D-->>B: 93.184.216.34
    B->>S: ② TCP 연결 (3-way 핸드셰이크)
    B->>S: ③ HTTP 요청 (GET / HTTP/1.1)
    Note over S: ④ 요청 처리 (DB 조회 등)
    S-->>B: ⑤ HTTP 응답 (200 OK + HTML)
    Note over B: ⑥ HTML 렌더링 → 화면 표시

이 문서는 위 흐름을 아래에서 위로(네트워크 계층 → HTTP 메시지) 차근차근 뜯어본다. ②는 3절(TCP), ③·⑤의 메시지 구조는 5·6절에서 자세히 다룬다.

#1. IP (Internet Protocol)

인터넷 프로토콜(IP)은 네트워크에서 데이터를 전송하는 규칙과 방법을 정의하는 프로토콜이다. 데이터가 올바르게 전송되어 목적지에 도달하도록 하는 핵심 역할을 한다.

#IP의 주요 기능

• 데이터 패킷화: 데이터를 작은 패킷으로 나누어 전송한다. 각 패킷은 독립적으로 전송되며, 목적지에서 다시 조립된다.

• 주소 지정: 각 장치에 고유한 IP 주소를 할당하여 데이터를 정확히 전달한다.

• 라우팅: 패킷이 출발지에서 목적지까지 최적의 경로를 따라 이동하도록 한다. 라우터와 함께 동작한다.

• 오류 제어 및 데이터 무결성: 전송 중 오류를 검출하고, 오류가 발견되면 패킷을 다시 요청한다.

#IP 주소 체계

#IP 패킷의 구조

IP 패킷은 헤더와 데이터 두 부분으로 나뉜다.

• 헤더: 출발지·목적지 주소, 패킷 길이, 시간 제한(TTL), 프로토콜 타입 등 중요한 정보를 담는다.

• 데이터: 실제 전송되는 메시지나 정보로, 상위 계층에서 전달된 데이터이다.

#TCP/IP 모델의 4계층

IP는 TCP/IP 모델에서 핵심적인 역할을 한다. TCP/IP 모델은 네트워크 통신을 4개의 계층으로 나눈다.

#2. OSI 7계층

OSI(Open Systems Interconnection) 모델은 네트워크 통신을 7개의 계층으로 나눈 표준 모델이다. 편지를 보내는 과정에 비유하면 이해하기 쉽다.

#📤 보내는 과정 (클라이언트 → 서버)

#📥 받는 과정 (서버 → 클라이언트)

서버에서는 이 과정이 거꾸로 일어난다. 물리적 신호 수신 → 네트워크 카드 처리 → 주소 확인 → 패킷 재조립 → 세션 확인 → 압축 해제·복호화 → 웹 서버가 요청을 이해하고 응답을 준비한다. 그리고 서버는 똑같은 7단계를 거쳐 웹페이지 데이터를 다시 클라이언트에게 보낸다.

#캡슐화 — 계층을 내려갈수록 헤더가 붙는다

데이터는 위 계층에서 아래로 내려가며 각 계층의 정보(헤더)가 봉투처럼 차곡차곡 덧씌워진다. 이를 캡슐화(Encapsulation) 라고 한다. 받는 쪽에서는 반대로 한 겹씩 벗겨낸다(역캡슐화).

graph TB
    A["응용 데이터<br>(HTTP 메시지)"]
    B["TCP 헤더 + 데이터<br>= 세그먼트"]
    C["IP 헤더 + 세그먼트<br>= 패킷"]
    D["프레임 헤더 + 패킷 + 트레일러<br>= 프레임 → 전기/광/전파 신호"]
    A -->|전송 계층| B
    B -->|네트워크 계층| C
    C -->|데이터 링크·물리 계층| D

#OSI 7계층 ↔ TCP/IP 4계층

OSI는 통신을 설명·교육하기 위한 이론 모델이고, 실제 인터넷은 더 단순한 TCP/IP 4계층으로 동작한다. 둘은 다음과 같이 대응된다.

graph LR
    subgraph OSI["OSI 7계층 (이론)"]
        direction TB
        O7[7. 응용]
        O6[6. 표현]
        O5[5. 세션]
        O4[4. 전송]
        O3[3. 네트워크]
        O2[2. 데이터 링크]
        O1[1. 물리]
    end
    subgraph TCPIP["TCP/IP 4계층 (실제)"]
        direction TB
        T4["응용<br>(HTTP·FTP·DNS)"]
        T3["전송<br>(TCP·UDP)"]
        T2["인터넷<br>(IP)"]
        T1["네트워크 인터페이스<br>(이더넷·Wi-Fi)"]
    end
    O7 -.-> T4
    O6 -.-> T4
    O5 -.-> T4
    O4 -.-> T3
    O3 -.-> T2
    O2 -.-> T1
    O1 -.-> T1

#3. TCP

TCP(Transmission Control Protocol)는 인터넷 프로토콜 스위트의 주요 프로토콜로, 신뢰성 있고 순차적인 데이터 전송을 보장한다.

• 연결 지향(Connection-oriented): 데이터 전송 전에 반드시 송신자와 수신자 간의 연결을 설정한다. 연결 설정은 세 개의 패킷을 교환하는 3-way 핸드셰이크로 이루어진다.

• 신뢰성(Reliability): 데이터가 손실·손상되면 재전송한다.

  • 오류 검출과 수정: 각 세그먼트에 체크섬을 포함하여 오류를 검출하고 재전송한다.

  • 데이터 확인(ACK): 수신자가 데이터를 성공적으로 받았음을 송신자에게 알린다.

• 흐름 제어(Flow Control): 윈도우 크기(Window Size)를 사용해 수신자가 처리할 수 있는 양만큼만 전송한다.

• 혼잡 제어(Congestion Control): 네트워크 상태에 따라 전송 속도를 조절한다. 슬로우 스타트로 작게 시작해 점진적으로 늘리고, 혼잡이 감지되면 윈도우 크기를 줄인다.

• 데이터 순서 보장: 전송된 순서대로 수신자에게 도달하도록 보장한다.

• 연결 종료: 데이터 전송이 끝나면 4-way 핸드셰이크로 연결을 정상 종료한다.

#연결 수립 — 3-way 핸드셰이크

데이터를 주고받기 전에, 서로 "통신할 준비가 됐는지" 를 세 번의 패킷 교환으로 확인한다.

sequenceDiagram
    participant C as 클라이언트
    participant S as 서버
    Note over C,S: 연결 수립 (3-way)
    C->>S: ① SYN (연결 요청, seq=x)
    S->>C: ② SYN + ACK (수락, seq=y / ack=x+1)
    C->>S: ③ ACK (확인, ack=y+1)
    Note over C,S: 연결 성립 → 데이터 전송 시작

• ① SYN: 클라이언트가 "연결하자"며 동기화(Synchronize) 요청을 보낸다.

• ② SYN+ACK: 서버가 "좋다(SYN)"는 응답과 "네 요청 받았다(ACK)"를 함께 보낸다.

• ③ ACK: 클라이언트가 "확인했다"고 응답하면 연결이 성립된다.

#연결 종료 — 4-way 핸드셰이크

연결을 끊을 때는 양쪽이 각자 따로 종료를 알려야 하므로 네 번 교환한다.

sequenceDiagram
    participant C as 클라이언트
    participant S as 서버
    Note over C,S: 연결 종료 (4-way)
    C->>S: ① FIN (종료 요청)
    S->>C: ② ACK (요청 확인)
    Note over S: 남은 데이터 마저 전송
    S->>C: ③ FIN (서버도 종료 준비 완료)
    C->>S: ④ ACK (확인 후 종료)

#4. URI (Uniform Resource Identifier)

URI는 인터넷에서 리소스를 식별하기 위한 문자열이다. 리소스의 위치를 가리키거나 이름을 지정하여 고유하게 식별한다.

#URI의 구성 요소

http://www.example.com/path/to/page?name=ferret&color=purple#section
└┬─┘   └──────┬──────┘└─────┬─────┘└────────┬────────────┘└──┬──┘
스킴        호스트         경로            쿼리            프래그먼트

#URI의 유형: URL과 URN

• URL(Uniform Resource Locator): 리소스의 위치를 지정한다.

  • 예: http://www.example.com/path/to/resource?key=value#section

• URN(Uniform Resource Name): 위치와 무관하게 리소스를 고유한 이름으로 식별한다. 위치가 바뀌어도 동일한 URN으로 식별할 수 있다.

  • 예: urn:isbn:0451450523

#5. HTTP 요청 메시지

HTTP 요청 메시지는 요청 라인 → 헤더 → 빈 줄 → 본문 순서로 구성된다.

POST /api/login HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 ...
Accept: application/json
Content-Type: application/json
Content-Length: 48

{ "username": "example", "password": "password123" }

#요청 라인 (Request Line)

세 가지 요소로 구성된다.

• 메서드(Method): 클라이언트가 요청하는 동작. 예: GET, POST, PUT, DELETE

• 요청 URL: 요청하는 리소스의 경로

• HTTP 버전: 사용된 프로토콜 버전. 예: HTTP/1.1

#헤더 (Header)

요청에 대한 추가 정보를 제공하는 키: 값 쌍의 집합이다.

#본문 (Body)

주로 POST, PUT, PATCH에서 사용되며 서버로 전송할 데이터를 담는다. GET 요청에서는 보통 본문을 사용하지 않는다. JSON, XML, 폼 데이터 등의 형식으로 전송한다.

{
    "username": "example",
    "password": "password123"
}

#6. HTTP 응답 메시지

HTTP 응답 메시지는 상태 줄 → 헤더 → 빈 줄(CRLF) → 본문 순서로 구성된다.

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 138
Server: Apache/2.4.1 (Unix)
Date: Sun, 26 May 2024 18:00:00 GMT

<!DOCTYPE html>
<html>
<head>
    <title>Sample Page</title>
</head>
<body>
    <h1>Hello, World!</h1>
</body>
</html>

#상태 줄 (Status Line)

• HTTP 버전: 예 HTTP/1.1

• 상태 코드: 처리 결과를 나타내는 3자리 숫자. 예 200

• 상태 텍스트: 상태 코드에 대한 설명. 예 OK

#빈 줄과 본문

헤더가 끝났음을 나타내기 위해 빈 줄(CRLF)이 하나 들어간다. 그 뒤의 본문에는 HTML 문서, JSON 데이터, 이미지 등 실제 데이터가 들어간다. 상태 코드가 204(No Content)나 304(Not Modified)일 때는 본문이 없을 수 있다.

#7. HTTP 메소드

GET /index.html HTTP/1.1
Host: www.example.com

POST /submit-form HTTP/1.1
Host: www.example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 27

name=John&age=30

#8. HTTP 상태 코드

상태 코드는 3자리 숫자로, 첫 자리에 따라 5가지 범주로 나뉜다.

#9. 직접 확인해 보기

지금까지 본 요청·응답 메시지는 글로만 보면 추상적이다. 실제 요청을 눈으로 관찰해 보면 메소드·상태 코드·헤더가 한눈에 들어온다.

#방법 1 — 브라우저 개발자 도구 (Network 탭)

1. 크롬/엣지에서 아무 사이트나 연 뒤 F12(또는 Ctrl+Shift+I)로 개발자 도구를 연다.

2. Network 탭을 누르고 페이지를 새로고침(F5)한다.

3. 목록에서 요청 하나를 클릭하면 Headers(요청/응답 헤더), Payload(요청 본문), Response(응답 본문)를 단계별로 볼 수 있다.

#방법 2 — curl로 raw 메시지 보기

curl -v(verbose)를 쓰면 실제로 오간 요청·응답 라인과 헤더가 그대로 출력된다. (>는 보낸 것, <는 받은 것)

curl -v https://httpbin.org/get

> GET /get HTTP/2 > Host: httpbin.org > user-agent: curl/8.4.0 > accept: */* < HTTP/2 200 < content-type: application/json < content-length: 256

POST로 JSON 본문을 보내며 메소드·헤더·본문이 함께 나가는 모습도 확인할 수 있다.

curl -v -X POST https://httpbin.org/post \
     -H "Content-Type: application/json" \
     -d '{"username":"kim","age":20}'

#10. HTTP 헤더

헤더는 적용 대상에 따라 네 가지로 분류된다.

#일반 헤더 (General Headers)

요청·응답 모두에 적용된다.

• Cache-Control: no-cache — 캐싱 동작 지정

• Connection: keep-alive — 연결 관리 옵션

• Date: Tue, 15 Nov 1994 08:12:31 GMT — 메시지 생성 시각

• Transfer-Encoding: chunked — 본문 전송 인코딩

#요청 헤더 (Request Headers)

• Accept: text/html — 처리 가능한 MIME 타입

• Accept-Encoding: gzip, deflate — 지원하는 콘텐츠 인코딩

• Accept-Language: en-US — 선호 언어

• Authorization: Basic ... — 인증 정보

• Cookie: UserID=JohnDoe — 서버에 전송하는 쿠키

• Host: www.example.com — 요청 대상 서버

• User-Agent: ... — 클라이언트 소프트웨어 정보

#응답 헤더 (Response Headers)

• ETag: "xyzzy" — 리소스의 고유 식별자

• Location: http://... — 리다이렉션 대상 위치

• Server: Apache/2.4.1 (Unix) — 서버 소프트웨어 정보

• Set-Cookie: UserID=JohnDoe — 클라이언트에 전송할 쿠키

• WWW-Authenticate: Basic — 인증 요청

#엔티티 헤더 (Entity Headers)

본문에 대한 메타데이터를 제공한다.

• Content-Type: text/html; charset=utf-8 — 본문의 MIME 타입

• Content-Length: 348 — 본문 길이(바이트)

• Content-Encoding: gzip — 본문 인코딩 방식

• Last-Modified: ... — 본문 최종 수정 시각