HTTP

1. HTTP란 무엇인가?

HTTP(HyperText Transfer Protocol)는 인터넷 상에서 클라이언트(주로 브라우저)와 서버 간의 데이터 교환을 위한 애플리케이션 계층 프로토콜입니다. 주로 웹 문서, 이미지, 동영상 등의 리소스를 요청하고 응답받는 데 사용됩니다.

HTTP는 무상태성(Stateless) 프로토콜로, 각각의 요청이 독립적으로 처리되며 이전 요청의 정보를 기억하지 않습니다.
클라이언트(사용자)는 서버에게 요청(Request)을 보내고, 서버는 응답(Response)을 반환합니다.

2. IP(Internet Protocol)란 무엇인가?

IP는 인터넷 상의 장치(클라이언트와 서버 포함) 간 데이터를 전송하기 위한 인터넷 계층 프로토콜입니다. IP는 데이터를 패킷(Packet) 단위로 나누어 전달합니다.

IP 패킷 구조

IP 패킷은 다음과 같은 정보를 포함합니다:

[ IP 패킷 구조 ]
+-------------------+
| 출발지 IP 주소    |
| 목적지 IP 주소    |
| 데이터 (Payload)  |
+-------------------+

출발지 IP: 데이터를 보낸 장치의 IP 주소.
목적지 IP: 데이터를 받을 장치의 IP 주소.
데이터 (Payload): 전송하려는 실제 데이터(예: HTTP 요청/응답 등).

3. IP 프로토콜의 한계

IP만으로 데이터를 전송할 수는 있지만, 다음과 같은 문제를 해결할 수 없습니다:

비연결성:
- IP는 수신자가 존재하는지 확인하지 않고 데이터를 전송합니다.
- 받는 쪽에서 데이터를 처리할 준비가 안 되어 있어도 전송합니다.
비신뢰성:
- 중간에 패킷이 손실되거나, 순서가 뒤바뀌어 도착할 수 있습니다.
- 순서가 중요한 데이터(예: 동영상, 파일) 전송 시 문제 발생.
프로그램 구분 불가:
- 같은 IP를 사용하는 서버에서 여러 애플리케이션이 동작 중이라면, 패킷이 어느 애플리케이션에 도달해야 하는지 알 수 없습니다.
대상 확인 불가:
- IP는 우편처럼 데이터 패킷을 "보내기만" 할 뿐, 대상 서버가 데이터 패킷을 받을 준비가 되었는지 확인하지 않습니다.
노드 손상 문제:
- 중간 노드(라우터 등)가 손상되면 데이터가 목적지에 도달하지 못할 수 있습니다.
순서 보장 문제:
- 패킷이 큰 경우 여러 조각으로 나뉘어 전송되는데, 전송 경로가 다르면 순서가 보장되지 않습니다.

4. TCP(Transmission Control Protocol)

TCP는 이러한 IP의 문제를 해결하기 위한 전송 계층 프로토콜입니다. TCP는 신뢰성 있는 데이터 전송을 보장하며, 다음과 같은 특징을 제공합니다:

연결 지향성:
- TCP는 데이터를 보내기 전에 클라이언트와 서버 간 연결을 설정합니다(3-way handshake).
- 수신자가 데이터 수신 준비가 되었는지 확인 후 전송합니다.
신뢰성:
- 전송된 데이터가 손실되거나 순서가 뒤바뀌어도, 재전송 및 정렬을 통해 올바른 데이터 전달을 보장합니다.
프로그램 구분:
- 포트 번호를 사용하여 서버 내의 특정 애플리케이션으로 데이터를 전달합니다.

5. TCP/IP 네트워크 모델

TCP/IP 모델은 인터넷에서 데이터를 전송하는 데 사용되는 네트워크 모델입니다. OSI 7계층 모델과는 다르게 4개의 계층으로 구성됩니다.

[ TCP/IP 네트워크 모델 ]
+-----------------------+
| 애플리케이션 계층      | HTTP, FTP 등
+-----------------------+
| 전송 계층             | TCP, UDP
+-----------------------+
| 인터넷 계층           | IP
+-----------------------+
| 네트워크 인터페이스 계층| LAN 드라이버, LAN 장비
+-----------------------+

TCP/IP 네트워크 모델의 각 계층 설명

애플리케이션 계층:
- 최종 사용자와의 상호작용이 이루어지는 계층.
- HTTP, FTP, SMTP 등이 여기에 포함됩니다.
전송 계층:
- 데이터의 신뢰성과 정확성을 보장하는 계층.
- TCP(신뢰성 제공), UDP(속도 우선)가 포함됩니다.
인터넷 계층:
- 데이터를 목적지로 전달하기 위해 IP 주소를 사용합니다.
- IP 프로토콜이 포함됩니다.
네트워크 인터페이스 계층:
- 데이터의 물리적인 전송을 담당합니다.
- 이더넷, Wi-Fi 등이 포함됩니다.

6. TCP/IP 데이터 흐름

다음은 TCP/IP 모델에서 데이터가 전송되는 과정

[ 클라이언트 → 서버 데이터 흐름 ]
+---------------------------+
| HTTP 요청 생성            |
| "GET / HTTP/1.1"         |
+---------------------------+
            ↓
+---------------------------+
| TCP 헤더 추가             |
| [포트번호: 80]            |
+---------------------------+
            ↓
+---------------------------+
| IP 헤더 추가              |
| [목적지: 192.168.0.1]    |
+---------------------------+
            ↓
+---------------------------+
| 데이터 링크 계층 처리     |
| [이더넷 프레임 추가]      |
+---------------------------+
            ↓
    [ 물리적 전송 (전선) ]

TCP와 IP의 협력

+-----------+         +-----------+
|  클라이언트  |         |    서버    |
|  (HTTP 요청) | -----> |  (HTTP 응답)|
+-----------+         +-----------+
       ↓                   ↑
  [ TCP ]                [ TCP ]
       ↓                   ↑
  [  IP ]                [  IP ]
       ↓                   ↑
[ 데이터 링크 ]         [ 데이터 링크 ]
       ↓                   ↑
[ 물리적 전송 ] <------> [ 물리적 전송 ]

8. TCP의 3-way Handshake 과정

TCP는 데이터를 전송하기 전, 연결을 설정하는 과정을 거칩니다. 이를 3-way handshake라 합니다.

1. 클라이언트 → 서버: SYN
2. 서버 → 클라이언트: SYN-ACK
3. 클라이언트 → 서버: ACK

이 과정을 통해 데이터 전송 전 연결이 성립되고, 수신자가 데이터 수신 준비가 되었음을 확인합니다.

TCP 메시지 전송 과정과 특징

1. 메시지 작성과 전송 흐름

애플리케이션 작성:
- 프로그램이 메시지를 작성합니다.
- 예를 들어, 클라이언트가 "Hello, Server!"라는 데이터를 전송한다고 가정합니다.
SOCKET 라이브러리 사용:
- 애플리케이션에서 SOCKET 라이브러리를 통해 메시지를 전달합니다.
- 메시지가 TCP 계층으로 내려갑니다.
TCP 계층 작업:
- TCP 계층은 메시지에 TCP 헤더 정보를 추가합니다.
- TCP 헤더에 포함되는 정보:
  - 출발지 포트: 클라이언트 애플리케이션의 포트 번호.
  - 목적지 포트: 서버 애플리케이션의 포트 번호.
  - 전송 제어 정보: 메시지의 순서를 확인하고 제어하기 위한 정보.
  - 순서 번호: 메시지 순서를 보장하기 위한 번호.
  - 검증 정보: 데이터 무결성을 확인하기 위한 체크섬.
IP 계층 작업:
- TCP 계층에서 생성된 데이터에 IP 헤더가 추가됩니다.
- IP 헤더에 포함되는 정보:
  - 출발지 IP: 클라이언트의 IP 주소.
  - 목적지 IP: 서버의 IP 주소.
데이터 링크 계층 작업:
- IP 계층에서 생성된 IP 패킷에 이더넷 프레임 헤더가 추가됩니다.
- 이더넷 프레임 헤더에 포함되는 정보:
  - 출발지 MAC 주소: 송신 장치의 물리적 주소.
  - 목적지 MAC 주소: 수신 장치의 물리적 주소.
물리적 전송:
- 데이터를 전기 신호(아날로그 신호)로 변환하여 전송 매체(전선 또는 무선)를 통해 서버로 전달합니다.

2. TCP 헤더 구성

TCP 헤더는 다음과 같은 정보를 포함합니다:

[ TCP 헤더 구조 ]
+----------------------------+
| 출발지 포트 (Source Port)  |
| 목적지 포트 (Destination Port) |
| 순서 번호 (Sequence Number) |
| 확인 응답 번호 (Acknowledgment Number) |
| 데이터 오프셋 (Data Offset) |
| 플래그 (Flags)             |
| 윈도 크기 (Window Size)    |
| 체크섬 (Checksum)          |
| 긴급 포인터 (Urgent Pointer)|
| 옵션 (Options, if any)     |
+----------------------------+

UDP의 특징 (하얀 도화지 비유)

UDP(User Datagram Protocol)는 간단하고 가벼운 전송 프로토콜입니다. 하얀 도화지에 비유하면, 연결 설정이나 데이터 보증 없이 기본적인 전송만을 제공합니다.

특징 요약:

연결지향이 아님: 데이터를 보내기 전에 연결 설정이 필요하지 않습니다.
데이터 전달 보증이 없음: 데이터가 제대로 도착했는지 확인하지 않습니다.
순서 보장이 없음: 패킷 순서가 바뀌거나 손실될 가능성이 있습니다.
IP 프로토콜과 거의 유사: IP 프로토콜에 포트와 체크섬 정도만 추가되었습니다.

구조 비교 코드블럭:

IP 구조:
[출발지 IP] [목적지 IP] [데이터]

UDP 구조:
[출발지 IP] [목적지 IP] [출발지 PORT] [목적지 PORT] [체크섬] [데이터]

체크섬: 데이터가 손상되지 않았는지 검증하는 간단한 도구.
포트: 같은 IP 안에서 여러 애플리케이션을 구분하는 역할.

애플리케이션에서 추가 작업이 필요함. 예를 들어 데이터 순서 보장이나 손실 보장을 직접 구현해야 합니다.

장점: 속도가 빠르고, 간단하여 실시간 데이터 전송에 적합합니다.

활용 사례: 최근 HTTP/3 스펙에서 UDP 기반의 QUIC 프로토콜을 사용하려는 움직임이 있습니다.

PORT란?

PORT는 한 컴퓨터에서 여러 애플리케이션이 네트워크를 사용할 때, 각 애플리케이션을 구분하는 역할을 합니다.

IP: 컴퓨터를 식별.
PORT: 해당 컴퓨터 내 특정 애플리케이션을 식별.

PORT 예시 코드블럭:

IP: 192.168.1.10
PORT: 8080 (웹 서버)
PORT: 22 (SSH 서버)
PORT: 3306 (데이터베이스 서버)

DNS (Domain Name System)

DNS는 인터넷의 전화번호부 역할을 합니다. 컴퓨터는 IP 주소를 사용해 통신하지만, 사람은 기억하기 쉬운 도메인 이름을 선호합니다.

문제점:

IP는 숫자로 되어 있어 기억하기 어렵습니다.
IP는 시간이 지나면 변경될 수 있습니다.

해결책: DNS 서버는 도메인 이름과 IP 주소를 매핑하여 관리합니다.

작동 원리:

사용자가 브라우저에 도메인 이름(예: www.example.com)을 입력.
브라우저가 DNS 서버에 해당 도메인의 IP 주소를 요청.
DNS 서버가 IP 주소를 응답.
브라우저가 해당 IP 주소로 연결.

DNS 작동 과정 코드블럭:

사용자: www.example.com -> DNS 서버 요청
DNS 서버: www.example.com의 IP는 192.168.1.100
사용자: 192.168.1.100에 연결

도메인 이름 등록: 사용자는 원하는 도메인을 구매한 뒤, 해당 도메인에 IP를 등록할 수 있습니다. 등록된 IP는 DNS 서버에서 관리됩니다.

URI와 URL

URI (Uniform Resource Identifier)

URI는 인터넷에서 리소스를 식별하는 통일된 방식입니다. 다양한 리소스(HTML 파일, 이미지, API 등)를 다른 리소스와 구분하는 데 필요한 정보를 제공합니다.

구성 요소:

Uniform (통일된): 리소스를 식별하기 위해 표준화된 방식으로 사용됨.
Resource (리소스): 구분 가능한 모든 정보(HTML 파일, 이미지, 비디오 등)를 뜻함.
Identifier (식별자): 리소스를 다른 항목과 구분하는 데 필요한 정보.

URL과 URN의 차이

URL (Uniform Resource Locator): 리소스의 위치를 알려줌.
- 예: https://example.com/path/to/resource
- Locator라는 이름처럼, 리소스가 "어디에 있는지"를 알려줍니다.
- 위치는 변할 수 있습니다.
URN (Uniform Resource Name): 리소스의 이름을 알려줌.
- 예: urn:isbn:4829138921 (특정 책의 ISBN)
- 리소스의 "이름"을 나타내지만, 위치를 제공하지는 않습니다.

URL이 URI의 하위 개념인 이유

URL은 URI의 한 유형입니다.
URI는 리소스를 식별하는 모든 방법을 포함하지만, URL은 그중에서 리소스의 위치를 식별하는 것만 담당합니다.

URL의 구조

URL은 다음과 같은 형식으로 구성됩니다.

Scheme://Authority/Path?Query#Fragment

1. Scheme:

리소스를 요청하는 데 사용하는 프로토콜.
예: http, https, ftp, mailto.
http는 80번 포트를 사용하며, https는 보안이 추가된 443번 포트를 사용합니다.

2. Authority:

서버의 위치를 나타냅니다.
구성 요소:
- 호스트명: example.com과 같은 도메인 이름 또는 IP 주소.
- 포트: 서버가 사용하는 포트 번호(기본적으로 생략 가능).

3. Path:

요청하는 리소스가 서버 내에서 위치하는 경로.
일반적으로 계층적 구조를 가집니다.
- 예: /path/to/resource 또는 /users/123.

4. Query:

리소스에 추가 데이터를 전달하기 위한 쿼리 파라미터.
형식: ?key=value&key2=value2
모두 문자열로 처리됩니다.

5. Fragment:

HTML 문서의 특정 위치로 이동하기 위해 사용.
형식: #section1

예제 URL 분석: https://google.com/search?q=hi

Scheme: https
Authority: google.com
Path: /search
Query: ?q=hi
Fragment: (없음)

URL 구성 요소 그림

https://google.com:443/search?q=hi#section1

+--------+   +----------+ +---+   +-----------+ +-------+ +----------+
| Scheme |://| Authority | :Port |    Path    | Query  |  Fragment  |
+--------+   +----------+ +---+   +-----------+ +-------+ +----------+
| https  |   | google.com| 443 |  /search     | ?q=hi  |  #section1 |
+--------+   +----------+ +---+   +-----------+ +-------+ +----------+

웹 브라우저 요청 흐름

사용자가 브라우저에 URL을 입력하거나 검색어를 입력합니다.
브라우저는 DNS 서버를 조회하여 도메인 이름(google.com)에 해당하는 IP 주소를 찾습니다.
DNS 서버가 IP 주소를 반환합니다.
브라우저는 IP 주소와 포트를 통해 서버에 연결합니다.
- HTTP: 기본적으로 80번 포트.
- HTTPS: 기본적으로 443번 포트.
브라우저가 HTTP 요청 메시지를 생성하고 서버로 보냅니다.

HTTP 요청 메시지 예시

GET /search?q=hi HTTP/1.1
Host: google.com
User-Agent: Mozilla/5.0
Accept: text/html
Connection: keep-alive

메서드: GET은 데이터를 요청하는 방식.
경로: /search?q=hi는 요청하는 리소스.
HTTP 버전: HTTP/1.1.
헤더: 요청에 포함된 추가 정보(예: 호스트, 브라우저 종류).

요청 메시지의 바디: GET 요청은 보통 바디가 없지만, POST 요청에는 보낼 데이터가 바디에 포함됩니다.

HTTP의 특징

1. HTTP란?

HTTP(HyperText Transfer Protocol): HyperText 문서를 전달하기 위한 프로토콜.
다양한 데이터 전송 가능: HTML, 텍스트, 이미지, 음성, 동영상 파일, JSON, XML 등 거의 모든 데이터 전송 가능.

2. HTTP 버전

HTTP/1.1: 현재 가장 많이 사용되는 버전. 단순하고 이해하기 쉬운 구조.
HTTP/2: 성능 개선 및 멀티플렉싱 지원.
HTTP/3: UDP 기반의 새로운 프로토콜로 더 빠른 전송이 목표.

참고: HTTP/1.1만 잘 이해하면 HTTP/2와 HTTP/3을 이해하기 쉽습니다.

3. HTTP의 특징

클라이언트-서버 구조: 클라이언트가 요청을 보내고, 서버가 응답하는 구조.
무상태 프로토콜: 서버는 이전 요청에 대한 상태를 기억하지 않음. (필요시 쿠키, 세션 등을 사용하여 상태 관리 가능.)
비연결성: 요청과 응답이 끝나면 연결을 종료.
단순함과 확장 가능성: 메시지 구조가 단순하고 다양한 확장이 가능.

HTTP 메시지 구조

HTTP 요청 메시지 예시

GET /search?q=hello HTTP/1.1
Host: google.com
User-Agent: Mozilla/5.0
Accept: text/html, application/json
Connection: keep-alive

메서드: GET(데이터 요청), POST(데이터 전송), 등.
경로: /search?q=hello는 요청하는 리소스의 경로.
HTTP 버전: HTTP/1.1은 요청이 어떤 HTTP 버전을 사용하는지 명시.
헤더: 추가적인 요청 정보 포함(예: Host, User-Agent 등).

HTTP 응답 메시지 예시

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 78

{
  "status": "success",
  "data": {
    "message": "Hello, World!"
  }
}

HTTP 요청 흐름 그림

1. 웹브라우저에서 URL 입력
   ↓
2. DNS 서버에서 IP 주소 반환
   ↓
3. TCP/IP 연결 (3-way handshake)
   ↓
4. HTTP 요청 메시지 생성 및 전송
   ↓
5. 서버에서 요청 처리 후 HTTP 응답 메시지 생성
   ↓
6. HTTP 응답 메시지 전달 및 브라우저에서 렌더링

HTTP 특징 자세히 살펴보기

1. 클라이언트-서버 구조

HTTP는 클라이언트-서버 구조를 기반으로 동작합니다. Request-Response 구조에서 클라이언트가 요청(Request)을 보내고 서버가 응답(Response)을 반환합니다.

특징:

클라이언트와 서버는 개념적으로 분리됩니다.
- 서버는 비즈니스 로직과 데이터 처리에 집중.
- 클라이언트는 UI 렌더링과 사용자와의 상호작용에 집중.
각각의 역할이 분리되면 독립적으로 발전 가능.
- 서버는 트래픽이 증가하더라도 클라이언트를 수정할 필요가 없음.
- 서버 개발자는 백엔드에 집중할 수 있으며, 다른 언어와 프레임워크를 자유롭게 선택 가능.

2. 무상태 프로토콜 (Stateless Protocol)

HTTP는 무상태 프로토콜로, 서버가 클라이언트의 상태를 보존하지 않습니다.

장점:

서버 확장성이 높아짐.
서버 간에 상태를 공유할 필요가 없으므로, 새로운 서버를 추가해도 쉽게 트래픽 분산 가능.

단점:

클라이언트 상태를 보존하지 않기 때문에 매 요청마다 추가 데이터 전송 필요.

무상태와 상태유지의 비교:

상태 유지(Stateful) 예시:
- 고객이 책을 구매하는 과정:
  1. 책의 가격을 질문 → 서버에서 가격 반환.
  2. 수량을 입력 → 서버에서 총 가격 반환 및 결제 방법 질문.
  3. 결제 방법 입력 → 서버에서 처리 완료 응답.
- 여기서 서버는 이전 요청의 상태(책의 가격, 수량 등)를 기억하고 추가 데이터만 처리.
- 문제점: 상태를 기억하기 때문에 중간에 서버가 바뀌면 데이터 소실 가능.
무상태(Stateless) 예시:
- 매 요청마다 필요한 모든 데이터를 함께 전송.
- 어떤 서버가 응답하더라도 상관없음.
- 장점: 서버가 마비되더라도 다른 서버로 요청을 쉽게 이어받을 수 있음.

상태 유지는 언제 필요한가?

로그인, 사용자 인증 등 상태를 유지해야 하는 경우.
쿠키와 세션을 사용하여 최소한의 상태만 유지.

3. 비연결성 (Connectionless)

HTTP는 기본적으로 **비연결성(Connectionless)**입니다.

특징:
- 요청과 응답이 끝나면 연결이 종료됩니다.
- 서버 자원을 지속적으로 연결 상태로 유지할 필요가 없으므로 효율적.
문제점:
- HTML 외에도 CSS, JavaScript, 이미지 등 추가 자원이 필요한 경우 매번 새로운 TCP/IP 연결을 맺어야 함.
- 3-way handshake로 인해 시간이 추가 소요.
해결책:
- HTTP 지속 연결(Persistent Connection):
  - 요청이 완료된 후에도 연결을 유지하여 여러 자원을 한 번에 다운로드.
- HTTP/2, HTTP/3:
  - 성능 최적화를 통해 비효율성을 해결.

4. HTTP 메시지 구조

HTTP는 단순하고 확장 가능한 메시지 구조를 가지고 있습니다. 모든 통신은 HTTP 요청 메시지와 응답 메시지를 통해 이루어집니다.

HTTP 메시지 구성

요청 메시지(Request Message):

GET /search?q=hello HTTP/1.1
Host: www.google.com
User-Agent: Mozilla/5.0
Accept: text/html
Connection: keep-alive

요소:
- 시작 라인(Start Line): 요청의 메서드와 경로.
  - 예: GET /search?q=hello HTTP/1.1
- 헤더(Header): 요청에 포함된 부가 정보.
  - 예: Host, User-Agent, Accept 등.
- 공백 라인: 헤더와 메시지 바디를 구분.
- 메시지 바디(Optional): POST 요청 등에서 데이터 포함.

응답 메시지(Response Message):

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 305

<html>
<head><title>Response</title></head>
<body>Hello, World!</body>
</html>

요소:
- 시작 라인(Start Line): HTTP 버전, 상태 코드, 상태 메시지.
  - 예: HTTP/1.1 200 OK
- 헤더(Header): 응답에 포함된 부가 정보.
  - 예: Content-Type, Content-Length 등.
- 공백 라인: 헤더와 메시지 바디를 구분.
- 메시지 바디: 클라이언트가 요청한 데이터.

HTTP 메서드

GET: 리소스 조회.
POST: 요청 데이터를 서버에 전송.
PUT: 리소스 수정.
DELETE: 리소스 삭제.

상태 코드

2xx (성공):
- 200 OK: 요청 성공.
4xx (클라이언트 오류):
- 400 Bad Request: 잘못된 요청.
- 404 Not Found: 리소스 없음.
5xx (서버 오류):
- 500 Internal Server Error: 서버 내부 오류.

HTTP의 단순성과 확장성

HTTP는 단순한 스펙 덕분에 다양한 기능을 추가할 수 있습니다.
헤더 확장 가능: 압축, 인증, 브라우저 정보, 서버 정보 등 다양한 부가 기능을 지원.

API URL 설계 및 HTTP 메서드 활용

URI 설계의 원칙

URI는 리소스를 식별하는 역할만 수행하고, 리소스에 대한 행위는 HTTP 메서드로 구분.
리소스는 데이터를 표현하는 개념입니다.
- 예를 들어, "유저 등록, 수정, 조회"는 행위이고, "유저(users)" 자체가 리소스입니다.

리소스 식별 및 행위 분리

리소스 식별 예시:

목록 조회: /users
개별 리소스 접근 (등록/수정/삭제): /users/{id}

행위 구분: 행위는 HTTP 메서드를 사용해 처리.

HTTP 메서드와 역할

GET
- 리소스 조회.
- 정적 데이터 조회: 추가적인 파라미터 없이 단순 조회.
  - 예: 이미지, 정적 HTML.
- 동적 데이터 조회: 쿼리 파라미터를 사용하여 결과를 동적으로 생성.
  - 예: 게시판 조회, 정렬, 필터.
- 서버에 전달하고 싶은 데이터는 쿼리 파라미터로 전달.
예시:
```
GET /users        # 모든 사용자 조회
GET /users/123    # 특정 사용자 조회
GET /users?age=20&sort=asc  # 나이 20 이상 정렬된 사용자 조회
```
POST
- 새로운 리소스 생성.
- 요청 데이터 처리:
  - 데이터 생성/변경뿐만 아니라 프로세스를 처리.
  - 새로운 리소스가 생성되지 않을 수도 있음.
- 다른 메서드로 처리하기 애매할 때 사용.
예시:
```
POST /users       # 새로운 사용자 등록
POST /orders      # 주문 생성
```
PUT
- 리소스 전체를 대체.
- 리소스가 없으면 생성.
- 클라이언트가 리소스 위치를 이미 알고 있어야 함.
예시:
```
PUT /users/123    # ID가 123인 사용자를 전체 대체
```

PATCH

리소스의 일부만 수정.

예시:

PATCH /users/123  # ID가 123인 사용자의 일부 데이터 수정

DELETE

리소스 삭제.

예시:

DELETE /users/123 # ID가 123인 사용자 삭제

동적 vs 정적 데이터 조회

정적 데이터 조회:
- 리소스 위치만 알면 됨.
- 쿼리 파라미터 없이 GET 요청 사용.
예시:
```
GET /images/logo.png  # 정적 이미지 조회
```
동적 데이터 조회:
- 서버가 쿼리 파라미터를 기준으로 데이터를 동적으로 생성.
- GET 요청에 쿼리 파라미터 포함.
예시:
```
GET /users?age=20&sort=asc  # 나이 20 이상의 사용자 목록 정렬 조회
```

데이터 저장 및 전송 방식

POST 데이터 저장:
- 주로 Form 데이터 전송.
- Content-Type: application/x-www-form-urlencoded.
- Body에 key=value&key=value 형식으로 전송.
예시:
```
POST /users
Content-Type: application/x-www-form-urlencoded

name=John&age=30
```

파일 업로드:

Content-Type: multipart/form-data.
바이너리 데이터를 포함해 파일 전송에 사용.

예시:

POST /upload
Content-Type: multipart/form-data

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

(binary data)

JSON 데이터 전송:
- API나 서버 간 데이터 전송에 사용.
- Content-Type: application/json.
예시:
```
POST /api/users
Content-Type: application/json

{
  "name": "John",
  "age": 30
}
```

HTML에서의 API 데이터 전송

서버 간 데이터 전송:
- Content-Type: application/json 활용.
- 서버-서버, 모바일 클라이언트(API), AJAX 기반의 웹 클라이언트에서 주로 사용.
AJAX와 SPA 활용:
- React, Vue 같은 프레임워크에서 POST, PUT, PATCH를 통해 JSON 데이터를 메시지 바디로 전송.
예시:
```
PATCH /users/123
Content-Type: application/json

{
  "age": 35
}
```

URI 설계 요약

리소스 목록 조회    GET /users
리소스 등록       POST /users
리소스 상세 조회    GET /users/{id}
리소스 수정       PUT /users/{id}
리소스 일부 수정    PATCH /users/{id}
리소스 삭제       DELETE /users/{id}

HTTP 상태 코드 (HTTP Status Codes)

HTTP 상태 코드는 클라이언트가 보낸 요청의 처리 상태를 응답 메시지를 통해 알려줍니다. 각 상태 코드는 1xx부터 5xx까지 구분되며, 특정 상황에 따라 사용됩니다.

1xx (Informational): 요청이 수신되어 처리 중

1xx 상태 코드는 일반적으로 사용되지 않음.

2xx (Successful): 요청 정상 처리

200 OK
- 요청이 성공적으로 처리됨.
201 Created
- 새로운 리소스가 성공적으로 생성됨.
- 응답 헤더의 Location 필드에 생성된 리소스의 URI를 포함.
  Location: /members/100
202 Accepted
- 요청이 접수되었으나 아직 처리되지 않음.
- 주로 비동기 작업 처리에 사용되지만, 잘 사용하지 않음.
204 No Content
- 요청이 성공적으로 처리되었으나, 응답 본문에 보낼 데이터가 없음.
- 사실상 200 OK와 동일한 의미.

3xx (Redirection): 추가 행동 필요

리다이렉션 응답: 클라이언트가 요청을 완료하려면 추가 작업이 필요함. 응답 헤더의 Location 필드에 새로운 URI를 포함.
300 Multiple Choices
- 리소스에 여러 선택지가 존재할 때 사용.
301 Moved Permanently
- 요청된 리소스의 URI가 영구적으로 변경됨.
- 리다이렉트 시 요청 메서드가 GET으로 변경되고, 본문은 제거될 수 있음.
302 Found
- 요청된 리소스가 일시적으로 다른 URI에 존재.
- 리다이렉트 시 요청 메서드가 GET으로 변경되고, 본문은 제거될 수 있음.
303 See Other
- 302 Found와 비슷하지만, 리다이렉트 시 요청 메서드가 반드시 GET으로 변경됨.
307 Temporary Redirect
- 302 Found와 동일하지만, 리다이렉트 시 요청 메서드와 본문을 유지.
308 Permanent Redirect
- 301 Moved Permanently와 동일하지만, 리다이렉트 시 요청 메서드와 본문을 유지.
304 Not Modified
- 캐시 목적으로 사용.
- 클라이언트가 로컬 캐시를 재사용할 수 있음을 나타냄.
- 응답 메시지에 본문 메시지가 포함되면 안 됨.

사용 팁: 대부분의 리다이렉션 상황에서 302 Found를 사용하는 것이 일반적.

4xx (Client Error): 클라이언트 요청 오류

400 Bad Request
- 요청 구문, 메시지 등에서 오류가 있어 서버가 요청을 처리할 수 없음.
- 클라이언트는 요청 내용을 검토한 후 다시 요청해야 함.
- 예시: 잘못된 요청 파라미터, API 스펙 불일치.
401 Unauthorized
- 인증이 필요하지만, 클라이언트가 인증되지 않음.
- 주로 로그인 오류 등에서 사용.
403 Forbidden
- 클라이언트가 인증되었지만, 요청한 리소스에 대한 접근 권한이 없음.
404 Not Found
- 요청한 리소스가 서버에 존재하지 않음.
- 주로 리소스를 숨기고 싶을 때도 사용.

5xx (Server Error): 서버 요청 처리 실패

503 Service Unavailable
- 서버가 현재 요청을 처리할 수 없음.
- 서버 과부하, 점검 등으로 서비스가 불가능할 때 사용.

HTTP 상태 코드 요약표

1xx Informational
  - 100 Continue: 요청을 계속 진행해도 됨 (잘 사용하지 않음)
  - 101 Switching Protocols: 프로토콜 변경

2xx Successful
  - 200 OK: 요청 성공
  - 201 Created: 리소스 생성 성공 (Location 헤더 포함)
  - 202 Accepted: 요청 접수 완료, 처리 중
  - 204 No Content: 요청 성공, 응답 본문 없음

3xx Redirection
  - 301 Moved Permanently: URI가 영구적으로 변경됨
  - 302 Found: URI가 임시로 변경됨
  - 303 See Other: 리다이렉트, 메서드가 GET으로 변경
  - 304 Not Modified: 캐시된 데이터 재사용
  - 307 Temporary Redirect: 리다이렉트, 메서드와 본문 유지
  - 308 Permanent Redirect: URI가 영구적으로 변경, 메서드와 본문 유지

4xx Client Error
  - 400 Bad Request: 요청 오류
  - 401 Unauthorized: 인증 필요
  - 403 Forbidden: 인증되었지만 접근 권한 없음
  - 404 Not Found: 요청 리소스 없음

5xx Server Error
  - 500 Internal Server Error: 서버 내부 오류
  - 503 Service Unavailable: 서버 사용 불가능

HTTP 헤더 개요

HTTP 헤더는 HTTP 전송에 필요한 모든 부가 정보를 포함합니다. 헤더는 요청(Request) 및 응답(Response) 메시지의 메타데이터 역할을 합니다.

HTTP 헤더의 종류

일반 헤더 (General Headers):
- HTTP 메시지 전체에 적용되는 정보.
요청 헤더 (Request Headers):
- 요청에 필요한 클라이언트 정보를 포함.
- 예: User-Agent.
응답 헤더 (Response Headers):
- 응답에 대한 정보를 포함.
- 예: Server.
표현 헤더 (Representation Headers):
- 본문 데이터의 형식과 관련된 정보를 설명.
- 예: Content-Type.

표현 헤더 (Representation Headers)

Content-Type

표현 데이터의 형식을 설명.

예:

Content-Type: text/html
Content-Type: application/json
Content-Type: image/png

Content-Encoding
- 표현 데이터를 압축하기 위해 사용.
- 데이터는 서버에서 압축된 상태로 전달되고, 클라이언트는 이를 해제.
- 예:
  Content-Encoding: gzip Content-Encoding: deflate Content-Encoding: identity
Content-Language
- 본문 데이터가 사용하는 자연어를 명시.
- 예:
  Content-Language: ko Content-Language: en-US
Content-Length
- 본문의 길이를 바이트 단위로 명시.
- 예:
  Content-Length: 348

콘텐츠 협상 (Content Negotiation)

클라이언트가 원하는 데이터 형식을 서버에 전달합니다. 요청(Request) 메시지에만 사용.

Accept
- 클라이언트가 선호하는 미디어 타입.
- 예:
  Accept: text/html, application/json
Accept-Charset
- 클라이언트가 선호하는 문자 인코딩.
- 예:
  Accept-Charset: utf-8, iso-8859-1
Accept-Encoding
- 클라이언트가 선호하는 압축 방식.
- 예:
  Accept-Encoding: gzip, deflate
Accept-Language
- 클라이언트가 선호하는 자연어.
- 우선순위를 명시할 수 있음.
- 예:
  Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7

일반 헤더 (General Headers)

Referer
- 요청이 발생한 이전 웹페이지 주소.
- 예:
  Referer: https://example.com
User-Agent
- 클라이언트 애플리케이션 정보(브라우저, OS 등).
- 예:
  User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Server
- 요청을 처리한 서버의 정보.
- 예:
  pServer: nginx/1.18.0
Date
- 메시지가 발생한 날짜.
- 예:
  Date: Tue, 27 Nov 2024 12:34:56 GMT

특별한 헤더

Host
- 요청에 사용되며 필수 헤더.
- 하나의 서버가 여러 도메인을 처리할 때 사용.
- 예:
  Host: example.com
Location
- 3xx 상태 코드와 함께 리다이렉션 위치를 명시.
- 예:
  Location: https://new.example.com
Allow
- 지원하는 HTTP 메서드 목록을 제공.
- 주로 405 Method Not Allowed 응답에서 사용.
- 예:
  Allow: GET, POST, DELETE

인증 헤더

Authorization
- 클라이언트 인증 정보를 서버에 전달.
- 예:
  Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l

쿠키는 클라이언트와 서버 간의 상태 정보를 저장하고 관리하는 데 사용됩니다. Set-Cookie를 통해 서버에서 클라이언트로 쿠키를 전달하며, 클라이언트는 이후 요청 시 Cookie 헤더를 사용해 쿠키를 서버로 다시 보냅니다.

1. Set-Cookie

서버에서 클라이언트로 쿠키 전달.
브라우저는 이를 쿠키 저장소에 저장하고, 이후 요청 시 Cookie 헤더에 쿠키를 포함해 서버로 전송.

예제:

Set-Cookie: user=test

클라이언트 저장:
```
user=test
```
이후 요청 시:
```
Cookie: user=test
```

쿠키 사용 목적:

세션 관리: 로그인 상태, 사용자 인증.
트래픽 추적: 사용자 활동 및 광고 트래킹.
개발 용이성: 무상태 요청의 복잡성을 줄여 개발 간소화.

2. Set-Cookie 속성

쿠키의 동작을 제어하는 다양한 속성이 있습니다.

Expires & Max-Age: 쿠키 만료 시간 설정.
- Expires: 특정 날짜와 시간에 쿠키 만료.
  Set-Cookie: user=test; Expires=Mon, 26-Nov-2024 11:11:11 GMT
- Max-Age: 쿠키의 생존 시간을 초 단위로 지정.
  Set-Cookie: user=test; Max-Age=3600
- 삭제: Expires를 과거 시간으로 설정하거나 Max-Age=0으로 설정.
  Set-Cookie: user=test; Expires=Thu, 01 Jan 1970 00:00:00 GMT
세션 쿠키:
- 만료 날짜가 설정되지 않으면 브라우저가 종료될 때 쿠키 삭제.
영속 쿠키:
- 만료 날짜가 설정되면 지정된 날짜까지 유지.

3. 쿠키 도메인

쿠키가 적용될 도메인을 설정합니다.

Domain=설정: 해당 도메인 및 모든 하위 도메인에 쿠키 적용.
```
Set-Cookie: user=test; Domain=woongjin.com
```
- woongjin.com뿐만 아니라 sub.woongjin.com에서도 쿠키에 접근 가능.
Domain 생략:
- 도메인을 생략하면 쿠키를 생성한 도메인에만 접근 가능.

4. 쿠키 경로 (Path)

쿠키가 적용될 경로를 설정합니다.

Path=/test: /test 경로와 하위 경로에서만 쿠키 접근 가능.
```
Set-Cookie: user=test; Path=/test
```
루트 경로 설정:
- 기본적으로 /를 사용하여 모든 경로에서 쿠키를 제공.

5. Secure

쿠키가 HTTPS 연결에서만 전송되도록 설정.
보안이 필요한 쿠키에 사용.
```
Set-Cookie: user=test; Secure
```

6. HttpOnly

JavaScript에서 쿠키에 접근할 수 없도록 설정.
XSS(교차 사이트 스크립팅) 공격 방지.
쿠키는 HTTP 요청/응답에만 사용.
```
Set-Cookie: user=test; HttpOnly
```

7. SameSite

쿠키가 요청 도메인과 설정된 도메인 간 일치 여부를 기준으로 전송.

SameSite=None: 모든 요청에 대해 쿠키 전송(HTTPS 필요).
SameSite=Strict: 동일한 도메인 요청에서만 쿠키 전송.
SameSite=Lax: 기본값. GET 요청, POST 요청 등 일부 조건에서만 쿠키 전송.

예제:

Set-Cookie: user=test; SameSite=Strict

XSRF(교차 사이트 요청 위조) 공격 방지. - 스프링 시큐리티때 다시 설명

쿠키 동작 예제

1. 서버가 쿠키 전달:

HTTP/1.1 200 OK
Set-Cookie: sessionId=abc123; Expires=Mon, 26-Nov-2024 11:11:11 GMT; Secure; HttpOnly

2. 클라이언트가 저장 후 요청 시 쿠키 포함:

GET /dashboard HTTP/1.1
Cookie: sessionId=abc123

쿠키 사용 주의 사항

최소한의 데이터만 사용:
- 쿠키에 너무 많은 정보를 저장하면 트래픽 증가 및 성능 저하 유발.
보안:
- Secure 및 HttpOnly 옵션을 적절히 사용하여 데이터 탈취 방지.
- 민감한 정보는 쿠키에 저장하지 말고 서버에서 관리.
쿠키 대안:
- 클라이언트 측 저장은 localStorage나 sessionStorage를 고려.

쿠키 설정 요약표

속성

설명

Expires

쿠키 만료 날짜와 시간 설정.

Max-Age

쿠키 생존 시간 설정(초 단위).

Domain

쿠키를 적용할 도메인 설정.

Path

쿠키를 적용할 경로 설정.

Secure

HTTPS 연결에서만 쿠키 전송.

HttpOnly

JavaScript에서 접근 불가. XSS 방지.

SameSite

쿠키 전송 정책 설정(None, Lax, Strict).

HTTP 헤더 요약표

표현 헤더
  Content-Type: 데이터 형식 (ex. application/json)
  Content-Encoding: 데이터 압축 방식 (ex. gzip)
  Content-Language: 자연언어 (ex. ko, en-US)
  Content-Length: 데이터 길이 (ex. 348)

콘텐츠 협상
  Accept: 클라이언트가 선호하는 미디어 타입
  Accept-Charset: 클라이언트가 선호하는 문자 인코딩
  Accept-Encoding: 클라이언트가 선호하는 압축 방식
  Accept-Language: 클라이언트가 선호하는 자연 언어

일반 헤더
  Referer: 이전 웹페이지 주소
  User-Agent: 클라이언트 정보
  Server: 요청 처리 서버 정보
  Date: 메시지 발생 날짜

특별한 헤더
  Host: 요청 도메인 구분
  Location: 리다이렉션 위치
  Allow: 지원하는 HTTP 메서드

쿠키
  Set-Cookie: 서버에서 클라이언트로 쿠키 전달
  Cookie: 클라이언트에서 서버로 쿠키 전달

Previous네트워크 NextOSI 7계층

Last updated 5 months ago

HTTP

1. HTTP란 무엇인가?

HTTP는 무상태성(Stateless) 프로토콜로, 각각의 요청이 독립적으로 처리되며 이전 요청의 정보를 기억하지 않습니다.
클라이언트(사용자)는 서버에게 요청(Request)을 보내고, 서버는 응답(Response)을 반환합니다.

2. IP(Internet Protocol)란 무엇인가?

IP 패킷 구조

IP 패킷은 다음과 같은 정보를 포함합니다:

[ IP 패킷 구조 ]
+-------------------+
| 출발지 IP 주소    |
| 목적지 IP 주소    |
| 데이터 (Payload)  |
+-------------------+

출발지 IP: 데이터를 보낸 장치의 IP 주소.
목적지 IP: 데이터를 받을 장치의 IP 주소.
데이터 (Payload): 전송하려는 실제 데이터(예: HTTP 요청/응답 등).

3. IP 프로토콜의 한계

IP만으로 데이터를 전송할 수는 있지만, 다음과 같은 문제를 해결할 수 없습니다:

비연결성:
- IP는 수신자가 존재하는지 확인하지 않고 데이터를 전송합니다.
- 받는 쪽에서 데이터를 처리할 준비가 안 되어 있어도 전송합니다.
비신뢰성:
- 중간에 패킷이 손실되거나, 순서가 뒤바뀌어 도착할 수 있습니다.
- 순서가 중요한 데이터(예: 동영상, 파일) 전송 시 문제 발생.
프로그램 구분 불가:
- 같은 IP를 사용하는 서버에서 여러 애플리케이션이 동작 중이라면, 패킷이 어느 애플리케이션에 도달해야 하는지 알 수 없습니다.
대상 확인 불가:
- IP는 우편처럼 데이터 패킷을 "보내기만" 할 뿐, 대상 서버가 데이터 패킷을 받을 준비가 되었는지 확인하지 않습니다.
노드 손상 문제:
- 중간 노드(라우터 등)가 손상되면 데이터가 목적지에 도달하지 못할 수 있습니다.
순서 보장 문제:
- 패킷이 큰 경우 여러 조각으로 나뉘어 전송되는데, 전송 경로가 다르면 순서가 보장되지 않습니다.

4. TCP(Transmission Control Protocol)

TCP는 이러한 IP의 문제를 해결하기 위한 전송 계층 프로토콜입니다. TCP는 신뢰성 있는 데이터 전송을 보장하며, 다음과 같은 특징을 제공합니다:

연결 지향성:
- TCP는 데이터를 보내기 전에 클라이언트와 서버 간 연결을 설정합니다(3-way handshake).
- 수신자가 데이터 수신 준비가 되었는지 확인 후 전송합니다.
신뢰성:
- 전송된 데이터가 손실되거나 순서가 뒤바뀌어도, 재전송 및 정렬을 통해 올바른 데이터 전달을 보장합니다.
프로그램 구분:
- 포트 번호를 사용하여 서버 내의 특정 애플리케이션으로 데이터를 전달합니다.

5. TCP/IP 네트워크 모델

TCP/IP 모델은 인터넷에서 데이터를 전송하는 데 사용되는 네트워크 모델입니다. OSI 7계층 모델과는 다르게 4개의 계층으로 구성됩니다.

[ TCP/IP 네트워크 모델 ]
+-----------------------+
| 애플리케이션 계층      | HTTP, FTP 등
+-----------------------+
| 전송 계층             | TCP, UDP
+-----------------------+
| 인터넷 계층           | IP
+-----------------------+
| 네트워크 인터페이스 계층| LAN 드라이버, LAN 장비
+-----------------------+

TCP/IP 네트워크 모델의 각 계층 설명

애플리케이션 계층:
- 최종 사용자와의 상호작용이 이루어지는 계층.
- HTTP, FTP, SMTP 등이 여기에 포함됩니다.
전송 계층:
- 데이터의 신뢰성과 정확성을 보장하는 계층.
- TCP(신뢰성 제공), UDP(속도 우선)가 포함됩니다.
인터넷 계층:
- 데이터를 목적지로 전달하기 위해 IP 주소를 사용합니다.
- IP 프로토콜이 포함됩니다.
네트워크 인터페이스 계층:
- 데이터의 물리적인 전송을 담당합니다.
- 이더넷, Wi-Fi 등이 포함됩니다.

6. TCP/IP 데이터 흐름

다음은 TCP/IP 모델에서 데이터가 전송되는 과정

[ 클라이언트 → 서버 데이터 흐름 ]
+---------------------------+
| HTTP 요청 생성            |
| "GET / HTTP/1.1"         |
+---------------------------+
            ↓
+---------------------------+
| TCP 헤더 추가             |
| [포트번호: 80]            |
+---------------------------+
            ↓
+---------------------------+
| IP 헤더 추가              |
| [목적지: 192.168.0.1]    |
+---------------------------+
            ↓
+---------------------------+
| 데이터 링크 계층 처리     |
| [이더넷 프레임 추가]      |
+---------------------------+
            ↓
    [ 물리적 전송 (전선) ]

TCP와 IP의 협력

+-----------+         +-----------+
|  클라이언트  |         |    서버    |
|  (HTTP 요청) | -----> |  (HTTP 응답)|
+-----------+         +-----------+
       ↓                   ↑
  [ TCP ]                [ TCP ]
       ↓                   ↑
  [  IP ]                [  IP ]
       ↓                   ↑
[ 데이터 링크 ]         [ 데이터 링크 ]
       ↓                   ↑
[ 물리적 전송 ] <------> [ 물리적 전송 ]

8. TCP의 3-way Handshake 과정

TCP는 데이터를 전송하기 전, 연결을 설정하는 과정을 거칩니다. 이를 3-way handshake라 합니다.

1. 클라이언트 → 서버: SYN
2. 서버 → 클라이언트: SYN-ACK
3. 클라이언트 → 서버: ACK

이 과정을 통해 데이터 전송 전 연결이 성립되고, 수신자가 데이터 수신 준비가 되었음을 확인합니다.

TCP 메시지 전송 과정과 특징

1. 메시지 작성과 전송 흐름

애플리케이션 작성:
- 프로그램이 메시지를 작성합니다.
- 예를 들어, 클라이언트가 "Hello, Server!"라는 데이터를 전송한다고 가정합니다.
SOCKET 라이브러리 사용:
- 애플리케이션에서 SOCKET 라이브러리를 통해 메시지를 전달합니다.
- 메시지가 TCP 계층으로 내려갑니다.
TCP 계층 작업:
- TCP 계층은 메시지에 TCP 헤더 정보를 추가합니다.
- TCP 헤더에 포함되는 정보:
  - 출발지 포트: 클라이언트 애플리케이션의 포트 번호.
  - 목적지 포트: 서버 애플리케이션의 포트 번호.
  - 전송 제어 정보: 메시지의 순서를 확인하고 제어하기 위한 정보.
  - 순서 번호: 메시지 순서를 보장하기 위한 번호.
  - 검증 정보: 데이터 무결성을 확인하기 위한 체크섬.
IP 계층 작업:
- TCP 계층에서 생성된 데이터에 IP 헤더가 추가됩니다.
- IP 헤더에 포함되는 정보:
  - 출발지 IP: 클라이언트의 IP 주소.
  - 목적지 IP: 서버의 IP 주소.
데이터 링크 계층 작업:
- IP 계층에서 생성된 IP 패킷에 이더넷 프레임 헤더가 추가됩니다.
- 이더넷 프레임 헤더에 포함되는 정보:
  - 출발지 MAC 주소: 송신 장치의 물리적 주소.
  - 목적지 MAC 주소: 수신 장치의 물리적 주소.
물리적 전송:
- 데이터를 전기 신호(아날로그 신호)로 변환하여 전송 매체(전선 또는 무선)를 통해 서버로 전달합니다.

2. TCP 헤더 구성

TCP 헤더는 다음과 같은 정보를 포함합니다:

[ TCP 헤더 구조 ]
+----------------------------+
| 출발지 포트 (Source Port)  |
| 목적지 포트 (Destination Port) |
| 순서 번호 (Sequence Number) |
| 확인 응답 번호 (Acknowledgment Number) |
| 데이터 오프셋 (Data Offset) |
| 플래그 (Flags)             |
| 윈도 크기 (Window Size)    |
| 체크섬 (Checksum)          |
| 긴급 포인터 (Urgent Pointer)|
| 옵션 (Options, if any)     |
+----------------------------+

UDP의 특징 (하얀 도화지 비유)

특징 요약:

연결지향이 아님: 데이터를 보내기 전에 연결 설정이 필요하지 않습니다.
데이터 전달 보증이 없음: 데이터가 제대로 도착했는지 확인하지 않습니다.
순서 보장이 없음: 패킷 순서가 바뀌거나 손실될 가능성이 있습니다.
IP 프로토콜과 거의 유사: IP 프로토콜에 포트와 체크섬 정도만 추가되었습니다.

구조 비교 코드블럭:

IP 구조:
[출발지 IP] [목적지 IP] [데이터]

UDP 구조:
[출발지 IP] [목적지 IP] [출발지 PORT] [목적지 PORT] [체크섬] [데이터]

체크섬: 데이터가 손상되지 않았는지 검증하는 간단한 도구.
포트: 같은 IP 안에서 여러 애플리케이션을 구분하는 역할.

애플리케이션에서 추가 작업이 필요함. 예를 들어 데이터 순서 보장이나 손실 보장을 직접 구현해야 합니다.

장점: 속도가 빠르고, 간단하여 실시간 데이터 전송에 적합합니다.

활용 사례: 최근 HTTP/3 스펙에서 UDP 기반의 QUIC 프로토콜을 사용하려는 움직임이 있습니다.

PORT란?

PORT는 한 컴퓨터에서 여러 애플리케이션이 네트워크를 사용할 때, 각 애플리케이션을 구분하는 역할을 합니다.

IP: 컴퓨터를 식별.
PORT: 해당 컴퓨터 내 특정 애플리케이션을 식별.

PORT 예시 코드블럭:

IP: 192.168.1.10
PORT: 8080 (웹 서버)
PORT: 22 (SSH 서버)
PORT: 3306 (데이터베이스 서버)

DNS (Domain Name System)

DNS는 인터넷의 전화번호부 역할을 합니다. 컴퓨터는 IP 주소를 사용해 통신하지만, 사람은 기억하기 쉬운 도메인 이름을 선호합니다.

문제점:

IP는 숫자로 되어 있어 기억하기 어렵습니다.
IP는 시간이 지나면 변경될 수 있습니다.

해결책: DNS 서버는 도메인 이름과 IP 주소를 매핑하여 관리합니다.

작동 원리:

사용자가 브라우저에 도메인 이름(예: www.example.com)을 입력.
브라우저가 DNS 서버에 해당 도메인의 IP 주소를 요청.
DNS 서버가 IP 주소를 응답.
브라우저가 해당 IP 주소로 연결.

DNS 작동 과정 코드블럭:

사용자: www.example.com -> DNS 서버 요청
DNS 서버: www.example.com의 IP는 192.168.1.100
사용자: 192.168.1.100에 연결

도메인 이름 등록: 사용자는 원하는 도메인을 구매한 뒤, 해당 도메인에 IP를 등록할 수 있습니다. 등록된 IP는 DNS 서버에서 관리됩니다.

URI와 URL

URI (Uniform Resource Identifier)

구성 요소:

Uniform (통일된): 리소스를 식별하기 위해 표준화된 방식으로 사용됨.
Resource (리소스): 구분 가능한 모든 정보(HTML 파일, 이미지, 비디오 등)를 뜻함.
Identifier (식별자): 리소스를 다른 항목과 구분하는 데 필요한 정보.

URL과 URN의 차이

URL (Uniform Resource Locator): 리소스의 위치를 알려줌.
- 예: https://example.com/path/to/resource
- Locator라는 이름처럼, 리소스가 "어디에 있는지"를 알려줍니다.
- 위치는 변할 수 있습니다.
URN (Uniform Resource Name): 리소스의 이름을 알려줌.
- 예: urn:isbn:4829138921 (특정 책의 ISBN)
- 리소스의 "이름"을 나타내지만, 위치를 제공하지는 않습니다.

URL이 URI의 하위 개념인 이유

URL은 URI의 한 유형입니다.
URI는 리소스를 식별하는 모든 방법을 포함하지만, URL은 그중에서 리소스의 위치를 식별하는 것만 담당합니다.

URL의 구조

URL은 다음과 같은 형식으로 구성됩니다.

Scheme://Authority/Path?Query#Fragment

1. Scheme:

리소스를 요청하는 데 사용하는 프로토콜.
예: http, https, ftp, mailto.
http는 80번 포트를 사용하며, https는 보안이 추가된 443번 포트를 사용합니다.

2. Authority:

서버의 위치를 나타냅니다.
구성 요소:
- 호스트명: example.com과 같은 도메인 이름 또는 IP 주소.
- 포트: 서버가 사용하는 포트 번호(기본적으로 생략 가능).

3. Path:

요청하는 리소스가 서버 내에서 위치하는 경로.
일반적으로 계층적 구조를 가집니다.
- 예: /path/to/resource 또는 /users/123.

4. Query:

리소스에 추가 데이터를 전달하기 위한 쿼리 파라미터.
형식: ?key=value&key2=value2
모두 문자열로 처리됩니다.

5. Fragment:

HTML 문서의 특정 위치로 이동하기 위해 사용.
형식: #section1

예제 URL 분석: https://google.com/search?q=hi

Scheme: https
Authority: google.com
Path: /search
Query: ?q=hi
Fragment: (없음)

URL 구성 요소 그림

https://google.com:443/search?q=hi#section1

+--------+   +----------+ +---+   +-----------+ +-------+ +----------+
| Scheme |://| Authority | :Port |    Path    | Query  |  Fragment  |
+--------+   +----------+ +---+   +-----------+ +-------+ +----------+
| https  |   | google.com| 443 |  /search     | ?q=hi  |  #section1 |
+--------+   +----------+ +---+   +-----------+ +-------+ +----------+

웹 브라우저 요청 흐름

사용자가 브라우저에 URL을 입력하거나 검색어를 입력합니다.
브라우저는 DNS 서버를 조회하여 도메인 이름(google.com)에 해당하는 IP 주소를 찾습니다.
DNS 서버가 IP 주소를 반환합니다.
브라우저는 IP 주소와 포트를 통해 서버에 연결합니다.
- HTTP: 기본적으로 80번 포트.
- HTTPS: 기본적으로 443번 포트.
브라우저가 HTTP 요청 메시지를 생성하고 서버로 보냅니다.

HTTP 요청 메시지 예시

GET /search?q=hi HTTP/1.1
Host: google.com
User-Agent: Mozilla/5.0
Accept: text/html
Connection: keep-alive

메서드: GET은 데이터를 요청하는 방식.
경로: /search?q=hi는 요청하는 리소스.
HTTP 버전: HTTP/1.1.
헤더: 요청에 포함된 추가 정보(예: 호스트, 브라우저 종류).

요청 메시지의 바디: GET 요청은 보통 바디가 없지만, POST 요청에는 보낼 데이터가 바디에 포함됩니다.

HTTP의 특징

1. HTTP란?

HTTP(HyperText Transfer Protocol): HyperText 문서를 전달하기 위한 프로토콜.
다양한 데이터 전송 가능: HTML, 텍스트, 이미지, 음성, 동영상 파일, JSON, XML 등 거의 모든 데이터 전송 가능.

2. HTTP 버전

HTTP/1.1: 현재 가장 많이 사용되는 버전. 단순하고 이해하기 쉬운 구조.
HTTP/2: 성능 개선 및 멀티플렉싱 지원.
HTTP/3: UDP 기반의 새로운 프로토콜로 더 빠른 전송이 목표.

참고: HTTP/1.1만 잘 이해하면 HTTP/2와 HTTP/3을 이해하기 쉽습니다.

3. HTTP의 특징

클라이언트-서버 구조: 클라이언트가 요청을 보내고, 서버가 응답하는 구조.
무상태 프로토콜: 서버는 이전 요청에 대한 상태를 기억하지 않음. (필요시 쿠키, 세션 등을 사용하여 상태 관리 가능.)
비연결성: 요청과 응답이 끝나면 연결을 종료.
단순함과 확장 가능성: 메시지 구조가 단순하고 다양한 확장이 가능.

HTTP 메시지 구조

HTTP 요청 메시지 예시

GET /search?q=hello HTTP/1.1
Host: google.com
User-Agent: Mozilla/5.0
Accept: text/html, application/json
Connection: keep-alive

메서드: GET(데이터 요청), POST(데이터 전송), 등.
경로: /search?q=hello는 요청하는 리소스의 경로.
HTTP 버전: HTTP/1.1은 요청이 어떤 HTTP 버전을 사용하는지 명시.
헤더: 추가적인 요청 정보 포함(예: Host, User-Agent 등).

HTTP 응답 메시지 예시

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 78

{
  "status": "success",
  "data": {
    "message": "Hello, World!"
  }
}

HTTP 요청 흐름 그림

1. 웹브라우저에서 URL 입력
   ↓
2. DNS 서버에서 IP 주소 반환
   ↓
3. TCP/IP 연결 (3-way handshake)
   ↓
4. HTTP 요청 메시지 생성 및 전송
   ↓
5. 서버에서 요청 처리 후 HTTP 응답 메시지 생성
   ↓
6. HTTP 응답 메시지 전달 및 브라우저에서 렌더링

HTTP 특징 자세히 살펴보기

1. 클라이언트-서버 구조

특징:

클라이언트와 서버는 개념적으로 분리됩니다.
- 서버는 비즈니스 로직과 데이터 처리에 집중.
- 클라이언트는 UI 렌더링과 사용자와의 상호작용에 집중.
각각의 역할이 분리되면 독립적으로 발전 가능.
- 서버는 트래픽이 증가하더라도 클라이언트를 수정할 필요가 없음.
- 서버 개발자는 백엔드에 집중할 수 있으며, 다른 언어와 프레임워크를 자유롭게 선택 가능.

2. 무상태 프로토콜 (Stateless Protocol)

HTTP는 무상태 프로토콜로, 서버가 클라이언트의 상태를 보존하지 않습니다.

장점:

서버 확장성이 높아짐.
서버 간에 상태를 공유할 필요가 없으므로, 새로운 서버를 추가해도 쉽게 트래픽 분산 가능.

단점:

클라이언트 상태를 보존하지 않기 때문에 매 요청마다 추가 데이터 전송 필요.

무상태와 상태유지의 비교:

상태 유지(Stateful) 예시:
- 고객이 책을 구매하는 과정:
  1. 책의 가격을 질문 → 서버에서 가격 반환.
  2. 수량을 입력 → 서버에서 총 가격 반환 및 결제 방법 질문.
  3. 결제 방법 입력 → 서버에서 처리 완료 응답.
- 여기서 서버는 이전 요청의 상태(책의 가격, 수량 등)를 기억하고 추가 데이터만 처리.
- 문제점: 상태를 기억하기 때문에 중간에 서버가 바뀌면 데이터 소실 가능.
무상태(Stateless) 예시:
- 매 요청마다 필요한 모든 데이터를 함께 전송.
- 어떤 서버가 응답하더라도 상관없음.
- 장점: 서버가 마비되더라도 다른 서버로 요청을 쉽게 이어받을 수 있음.

상태 유지는 언제 필요한가?

로그인, 사용자 인증 등 상태를 유지해야 하는 경우.
쿠키와 세션을 사용하여 최소한의 상태만 유지.

3. 비연결성 (Connectionless)

HTTP는 기본적으로 **비연결성(Connectionless)**입니다.

특징:
- 요청과 응답이 끝나면 연결이 종료됩니다.
- 서버 자원을 지속적으로 연결 상태로 유지할 필요가 없으므로 효율적.
문제점:
- HTML 외에도 CSS, JavaScript, 이미지 등 추가 자원이 필요한 경우 매번 새로운 TCP/IP 연결을 맺어야 함.
- 3-way handshake로 인해 시간이 추가 소요.
해결책:
- HTTP 지속 연결(Persistent Connection):
  - 요청이 완료된 후에도 연결을 유지하여 여러 자원을 한 번에 다운로드.
- HTTP/2, HTTP/3:
  - 성능 최적화를 통해 비효율성을 해결.

4. HTTP 메시지 구조

HTTP는 단순하고 확장 가능한 메시지 구조를 가지고 있습니다. 모든 통신은 HTTP 요청 메시지와 응답 메시지를 통해 이루어집니다.

HTTP 메시지 구성

요청 메시지(Request Message):

GET /search?q=hello HTTP/1.1
Host: www.google.com
User-Agent: Mozilla/5.0
Accept: text/html
Connection: keep-alive

요소:
- 시작 라인(Start Line): 요청의 메서드와 경로.
  - 예: GET /search?q=hello HTTP/1.1
- 헤더(Header): 요청에 포함된 부가 정보.
  - 예: Host, User-Agent, Accept 등.
- 공백 라인: 헤더와 메시지 바디를 구분.
- 메시지 바디(Optional): POST 요청 등에서 데이터 포함.

응답 메시지(Response Message):

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 305

<html>
<head><title>Response</title></head>
<body>Hello, World!</body>
</html>

요소:
- 시작 라인(Start Line): HTTP 버전, 상태 코드, 상태 메시지.
  - 예: HTTP/1.1 200 OK
- 헤더(Header): 응답에 포함된 부가 정보.
  - 예: Content-Type, Content-Length 등.
- 공백 라인: 헤더와 메시지 바디를 구분.
- 메시지 바디: 클라이언트가 요청한 데이터.

HTTP 메서드

GET: 리소스 조회.
POST: 요청 데이터를 서버에 전송.
PUT: 리소스 수정.
DELETE: 리소스 삭제.

상태 코드

2xx (성공):
- 200 OK: 요청 성공.
4xx (클라이언트 오류):
- 400 Bad Request: 잘못된 요청.
- 404 Not Found: 리소스 없음.
5xx (서버 오류):
- 500 Internal Server Error: 서버 내부 오류.

HTTP의 단순성과 확장성

HTTP는 단순한 스펙 덕분에 다양한 기능을 추가할 수 있습니다.
헤더 확장 가능: 압축, 인증, 브라우저 정보, 서버 정보 등 다양한 부가 기능을 지원.

API URL 설계 및 HTTP 메서드 활용

URI 설계의 원칙

URI는 리소스를 식별하는 역할만 수행하고, 리소스에 대한 행위는 HTTP 메서드로 구분.
리소스는 데이터를 표현하는 개념입니다.
- 예를 들어, "유저 등록, 수정, 조회"는 행위이고, "유저(users)" 자체가 리소스입니다.

리소스 식별 및 행위 분리

리소스 식별 예시:

목록 조회: /users
개별 리소스 접근 (등록/수정/삭제): /users/{id}

행위 구분: 행위는 HTTP 메서드를 사용해 처리.

HTTP 메서드와 역할

GET
- 리소스 조회.
- 정적 데이터 조회: 추가적인 파라미터 없이 단순 조회.
  - 예: 이미지, 정적 HTML.
- 동적 데이터 조회: 쿼리 파라미터를 사용하여 결과를 동적으로 생성.
  - 예: 게시판 조회, 정렬, 필터.
- 서버에 전달하고 싶은 데이터는 쿼리 파라미터로 전달.
예시:
```
GET /users        # 모든 사용자 조회
GET /users/123    # 특정 사용자 조회
GET /users?age=20&sort=asc  # 나이 20 이상 정렬된 사용자 조회
```
POST
- 새로운 리소스 생성.
- 요청 데이터 처리:
  - 데이터 생성/변경뿐만 아니라 프로세스를 처리.
  - 새로운 리소스가 생성되지 않을 수도 있음.
- 다른 메서드로 처리하기 애매할 때 사용.
예시:
```
POST /users       # 새로운 사용자 등록
POST /orders      # 주문 생성
```
PUT
- 리소스 전체를 대체.
- 리소스가 없으면 생성.
- 클라이언트가 리소스 위치를 이미 알고 있어야 함.
예시:
```
PUT /users/123    # ID가 123인 사용자를 전체 대체
```

PATCH

리소스의 일부만 수정.

예시:

PATCH /users/123  # ID가 123인 사용자의 일부 데이터 수정

DELETE

리소스 삭제.

예시:

DELETE /users/123 # ID가 123인 사용자 삭제

동적 vs 정적 데이터 조회

정적 데이터 조회:
- 리소스 위치만 알면 됨.
- 쿼리 파라미터 없이 GET 요청 사용.
예시:
```
GET /images/logo.png  # 정적 이미지 조회
```
동적 데이터 조회:
- 서버가 쿼리 파라미터를 기준으로 데이터를 동적으로 생성.
- GET 요청에 쿼리 파라미터 포함.
예시:
```
GET /users?age=20&sort=asc  # 나이 20 이상의 사용자 목록 정렬 조회
```

데이터 저장 및 전송 방식

POST 데이터 저장:
- 주로 Form 데이터 전송.
- Content-Type: application/x-www-form-urlencoded.
- Body에 key=value&key=value 형식으로 전송.
예시:
```
POST /users
Content-Type: application/x-www-form-urlencoded

name=John&age=30
```

파일 업로드:

Content-Type: multipart/form-data.
바이너리 데이터를 포함해 파일 전송에 사용.

예시:

POST /upload
Content-Type: multipart/form-data

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

(binary data)

JSON 데이터 전송:
- API나 서버 간 데이터 전송에 사용.
- Content-Type: application/json.
예시:
```
POST /api/users
Content-Type: application/json

{
  "name": "John",
  "age": 30
}
```

HTML에서의 API 데이터 전송

서버 간 데이터 전송:
- Content-Type: application/json 활용.
- 서버-서버, 모바일 클라이언트(API), AJAX 기반의 웹 클라이언트에서 주로 사용.
AJAX와 SPA 활용:
- React, Vue 같은 프레임워크에서 POST, PUT, PATCH를 통해 JSON 데이터를 메시지 바디로 전송.
예시:
```
PATCH /users/123
Content-Type: application/json

{
  "age": 35
}
```

URI 설계 요약

리소스 목록 조회    GET /users
리소스 등록       POST /users
리소스 상세 조회    GET /users/{id}
리소스 수정       PUT /users/{id}
리소스 일부 수정    PATCH /users/{id}
리소스 삭제       DELETE /users/{id}

HTTP 상태 코드 (HTTP Status Codes)

1xx (Informational): 요청이 수신되어 처리 중

1xx 상태 코드는 일반적으로 사용되지 않음.

2xx (Successful): 요청 정상 처리

200 OK
- 요청이 성공적으로 처리됨.
201 Created
- 새로운 리소스가 성공적으로 생성됨.
- 응답 헤더의 Location 필드에 생성된 리소스의 URI를 포함.
  Location: /members/100
202 Accepted
- 요청이 접수되었으나 아직 처리되지 않음.
- 주로 비동기 작업 처리에 사용되지만, 잘 사용하지 않음.
204 No Content
- 요청이 성공적으로 처리되었으나, 응답 본문에 보낼 데이터가 없음.
- 사실상 200 OK와 동일한 의미.

3xx (Redirection): 추가 행동 필요

리다이렉션 응답: 클라이언트가 요청을 완료하려면 추가 작업이 필요함. 응답 헤더의 Location 필드에 새로운 URI를 포함.
300 Multiple Choices
- 리소스에 여러 선택지가 존재할 때 사용.
301 Moved Permanently
- 요청된 리소스의 URI가 영구적으로 변경됨.
- 리다이렉트 시 요청 메서드가 GET으로 변경되고, 본문은 제거될 수 있음.
302 Found
- 요청된 리소스가 일시적으로 다른 URI에 존재.
- 리다이렉트 시 요청 메서드가 GET으로 변경되고, 본문은 제거될 수 있음.
303 See Other
- 302 Found와 비슷하지만, 리다이렉트 시 요청 메서드가 반드시 GET으로 변경됨.
307 Temporary Redirect
- 302 Found와 동일하지만, 리다이렉트 시 요청 메서드와 본문을 유지.
308 Permanent Redirect
- 301 Moved Permanently와 동일하지만, 리다이렉트 시 요청 메서드와 본문을 유지.
304 Not Modified
- 캐시 목적으로 사용.
- 클라이언트가 로컬 캐시를 재사용할 수 있음을 나타냄.
- 응답 메시지에 본문 메시지가 포함되면 안 됨.

사용 팁: 대부분의 리다이렉션 상황에서 302 Found를 사용하는 것이 일반적.

4xx (Client Error): 클라이언트 요청 오류

400 Bad Request
- 요청 구문, 메시지 등에서 오류가 있어 서버가 요청을 처리할 수 없음.
- 클라이언트는 요청 내용을 검토한 후 다시 요청해야 함.
- 예시: 잘못된 요청 파라미터, API 스펙 불일치.
401 Unauthorized
- 인증이 필요하지만, 클라이언트가 인증되지 않음.
- 주로 로그인 오류 등에서 사용.
403 Forbidden
- 클라이언트가 인증되었지만, 요청한 리소스에 대한 접근 권한이 없음.
404 Not Found
- 요청한 리소스가 서버에 존재하지 않음.
- 주로 리소스를 숨기고 싶을 때도 사용.

5xx (Server Error): 서버 요청 처리 실패

503 Service Unavailable
- 서버가 현재 요청을 처리할 수 없음.
- 서버 과부하, 점검 등으로 서비스가 불가능할 때 사용.

HTTP 상태 코드 요약표

1xx Informational
  - 100 Continue: 요청을 계속 진행해도 됨 (잘 사용하지 않음)
  - 101 Switching Protocols: 프로토콜 변경

2xx Successful
  - 200 OK: 요청 성공
  - 201 Created: 리소스 생성 성공 (Location 헤더 포함)
  - 202 Accepted: 요청 접수 완료, 처리 중
  - 204 No Content: 요청 성공, 응답 본문 없음

3xx Redirection
  - 301 Moved Permanently: URI가 영구적으로 변경됨
  - 302 Found: URI가 임시로 변경됨
  - 303 See Other: 리다이렉트, 메서드가 GET으로 변경
  - 304 Not Modified: 캐시된 데이터 재사용
  - 307 Temporary Redirect: 리다이렉트, 메서드와 본문 유지
  - 308 Permanent Redirect: URI가 영구적으로 변경, 메서드와 본문 유지

4xx Client Error
  - 400 Bad Request: 요청 오류
  - 401 Unauthorized: 인증 필요
  - 403 Forbidden: 인증되었지만 접근 권한 없음
  - 404 Not Found: 요청 리소스 없음

5xx Server Error
  - 500 Internal Server Error: 서버 내부 오류
  - 503 Service Unavailable: 서버 사용 불가능

HTTP 헤더 개요

HTTP 헤더는 HTTP 전송에 필요한 모든 부가 정보를 포함합니다. 헤더는 요청(Request) 및 응답(Response) 메시지의 메타데이터 역할을 합니다.

HTTP 헤더의 종류

일반 헤더 (General Headers):
- HTTP 메시지 전체에 적용되는 정보.
요청 헤더 (Request Headers):
- 요청에 필요한 클라이언트 정보를 포함.
- 예: User-Agent.
응답 헤더 (Response Headers):
- 응답에 대한 정보를 포함.
- 예: Server.
표현 헤더 (Representation Headers):
- 본문 데이터의 형식과 관련된 정보를 설명.
- 예: Content-Type.

표현 헤더 (Representation Headers)

Content-Type

표현 데이터의 형식을 설명.

예:

Content-Type: text/html
Content-Type: application/json
Content-Type: image/png

Content-Encoding
- 표현 데이터를 압축하기 위해 사용.
- 데이터는 서버에서 압축된 상태로 전달되고, 클라이언트는 이를 해제.
- 예:
  Content-Encoding: gzip Content-Encoding: deflate Content-Encoding: identity
Content-Language
- 본문 데이터가 사용하는 자연어를 명시.
- 예:
  Content-Language: ko Content-Language: en-US
Content-Length
- 본문의 길이를 바이트 단위로 명시.
- 예:
  Content-Length: 348

콘텐츠 협상 (Content Negotiation)

클라이언트가 원하는 데이터 형식을 서버에 전달합니다. 요청(Request) 메시지에만 사용.

Accept
- 클라이언트가 선호하는 미디어 타입.
- 예:
  Accept: text/html, application/json
Accept-Charset
- 클라이언트가 선호하는 문자 인코딩.
- 예:
  Accept-Charset: utf-8, iso-8859-1
Accept-Encoding
- 클라이언트가 선호하는 압축 방식.
- 예:
  Accept-Encoding: gzip, deflate
Accept-Language
- 클라이언트가 선호하는 자연어.
- 우선순위를 명시할 수 있음.
- 예:
  Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7

일반 헤더 (General Headers)

Referer
- 요청이 발생한 이전 웹페이지 주소.
- 예:
  Referer: https://example.com
User-Agent
- 클라이언트 애플리케이션 정보(브라우저, OS 등).
- 예:
  User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Server
- 요청을 처리한 서버의 정보.
- 예:
  pServer: nginx/1.18.0
Date
- 메시지가 발생한 날짜.
- 예:
  Date: Tue, 27 Nov 2024 12:34:56 GMT

특별한 헤더

Host
- 요청에 사용되며 필수 헤더.
- 하나의 서버가 여러 도메인을 처리할 때 사용.
- 예:
  Host: example.com
Location
- 3xx 상태 코드와 함께 리다이렉션 위치를 명시.
- 예:
  Location: https://new.example.com
Allow
- 지원하는 HTTP 메서드 목록을 제공.
- 주로 405 Method Not Allowed 응답에서 사용.
- 예:
  Allow: GET, POST, DELETE

인증 헤더

Authorization
- 클라이언트 인증 정보를 서버에 전달.
- 예:
  Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l

1. Set-Cookie

서버에서 클라이언트로 쿠키 전달.
브라우저는 이를 쿠키 저장소에 저장하고, 이후 요청 시 Cookie 헤더에 쿠키를 포함해 서버로 전송.

예제:

Set-Cookie: user=test

클라이언트 저장:
```
user=test
```
이후 요청 시:
```
Cookie: user=test
```

쿠키 사용 목적:

세션 관리: 로그인 상태, 사용자 인증.
트래픽 추적: 사용자 활동 및 광고 트래킹.
개발 용이성: 무상태 요청의 복잡성을 줄여 개발 간소화.

2. Set-Cookie 속성

쿠키의 동작을 제어하는 다양한 속성이 있습니다.

Expires & Max-Age: 쿠키 만료 시간 설정.
- Expires: 특정 날짜와 시간에 쿠키 만료.
  Set-Cookie: user=test; Expires=Mon, 26-Nov-2024 11:11:11 GMT
- Max-Age: 쿠키의 생존 시간을 초 단위로 지정.
  Set-Cookie: user=test; Max-Age=3600
- 삭제: Expires를 과거 시간으로 설정하거나 Max-Age=0으로 설정.
  Set-Cookie: user=test; Expires=Thu, 01 Jan 1970 00:00:00 GMT
세션 쿠키:
- 만료 날짜가 설정되지 않으면 브라우저가 종료될 때 쿠키 삭제.
영속 쿠키:
- 만료 날짜가 설정되면 지정된 날짜까지 유지.

3. 쿠키 도메인

쿠키가 적용될 도메인을 설정합니다.

Domain=설정: 해당 도메인 및 모든 하위 도메인에 쿠키 적용.
```
Set-Cookie: user=test; Domain=woongjin.com
```
- woongjin.com뿐만 아니라 sub.woongjin.com에서도 쿠키에 접근 가능.
Domain 생략:
- 도메인을 생략하면 쿠키를 생성한 도메인에만 접근 가능.

4. 쿠키 경로 (Path)

쿠키가 적용될 경로를 설정합니다.

Path=/test: /test 경로와 하위 경로에서만 쿠키 접근 가능.
```
Set-Cookie: user=test; Path=/test
```
루트 경로 설정:
- 기본적으로 /를 사용하여 모든 경로에서 쿠키를 제공.

5. Secure

쿠키가 HTTPS 연결에서만 전송되도록 설정.
보안이 필요한 쿠키에 사용.
```
Set-Cookie: user=test; Secure
```

6. HttpOnly

JavaScript에서 쿠키에 접근할 수 없도록 설정.
XSS(교차 사이트 스크립팅) 공격 방지.
쿠키는 HTTP 요청/응답에만 사용.
```
Set-Cookie: user=test; HttpOnly
```

7. SameSite

쿠키가 요청 도메인과 설정된 도메인 간 일치 여부를 기준으로 전송.

SameSite=None: 모든 요청에 대해 쿠키 전송(HTTPS 필요).
SameSite=Strict: 동일한 도메인 요청에서만 쿠키 전송.
SameSite=Lax: 기본값. GET 요청, POST 요청 등 일부 조건에서만 쿠키 전송.

예제:

Set-Cookie: user=test; SameSite=Strict

XSRF(교차 사이트 요청 위조) 공격 방지. - 스프링 시큐리티때 다시 설명

쿠키 동작 예제

1. 서버가 쿠키 전달:

HTTP/1.1 200 OK
Set-Cookie: sessionId=abc123; Expires=Mon, 26-Nov-2024 11:11:11 GMT; Secure; HttpOnly

2. 클라이언트가 저장 후 요청 시 쿠키 포함:

GET /dashboard HTTP/1.1
Cookie: sessionId=abc123

쿠키 사용 주의 사항

최소한의 데이터만 사용:
- 쿠키에 너무 많은 정보를 저장하면 트래픽 증가 및 성능 저하 유발.
보안:
- Secure 및 HttpOnly 옵션을 적절히 사용하여 데이터 탈취 방지.
- 민감한 정보는 쿠키에 저장하지 말고 서버에서 관리.
쿠키 대안:
- 클라이언트 측 저장은 localStorage나 sessionStorage를 고려.

쿠키 설정 요약표

속성

설명

Expires

쿠키 만료 날짜와 시간 설정.

Max-Age

쿠키 생존 시간 설정(초 단위).

Domain

쿠키를 적용할 도메인 설정.

Path

쿠키를 적용할 경로 설정.

Secure

HTTPS 연결에서만 쿠키 전송.

HttpOnly

JavaScript에서 접근 불가. XSS 방지.

SameSite

쿠키 전송 정책 설정(None, Lax, Strict).

HTTP 헤더 요약표

표현 헤더
  Content-Type: 데이터 형식 (ex. application/json)
  Content-Encoding: 데이터 압축 방식 (ex. gzip)
  Content-Language: 자연언어 (ex. ko, en-US)
  Content-Length: 데이터 길이 (ex. 348)

콘텐츠 협상
  Accept: 클라이언트가 선호하는 미디어 타입
  Accept-Charset: 클라이언트가 선호하는 문자 인코딩
  Accept-Encoding: 클라이언트가 선호하는 압축 방식
  Accept-Language: 클라이언트가 선호하는 자연 언어

일반 헤더
  Referer: 이전 웹페이지 주소
  User-Agent: 클라이언트 정보
  Server: 요청 처리 서버 정보
  Date: 메시지 발생 날짜

특별한 헤더
  Host: 요청 도메인 구분
  Location: 리다이렉션 위치
  Allow: 지원하는 HTTP 메서드

쿠키
  Set-Cookie: 서버에서 클라이언트로 쿠키 전달
  Cookie: 클라이언트에서 서버로 쿠키 전달

Previous네트워크 NextOSI 7계층

Last updated 5 months ago