HTTP

인터넷 네트워크 

 

IP (인터넷 프로토콜)

인터넷을 통해 데이터를 전송하는 데 사용되는 프로토콜입니다. 각 기기는 고유한 IP 주소를 가지며, 이 주소를 통해 데이터가 전송되고 라우팅됩니다. IPv4와 IPv6는 주로 사용되며, IPv4는 32비트 주소를, IPv6는 128비트 주소를 사용합니다.

 

TCP (전송 제어 프로토콜)

신뢰성 있는 데이터 전송을 제공하는 프로토콜입니다. 데이터를 분할하고 보내고, 수신측에서 재조립하여 손실이나 오류를 최소화합니다. 웹 브라우징, 이메일 전송 등과 같이 신뢰성이 중요한 애플리케이션에서 주로 사용됩니다.

 

UDP (사용자 데이터그램 프로토콜)
TCP와 달리 연결 지향적이지 않고, 데이터 전송을 빠르게 처리합니다. 그러나 손실이나 중복 데이터 처리를 제공하지 않기 때문에, 빠른 데이터 전송이 중요한 애플리케이션에서 사용됩니다. 예를 들면, 음성 통화 및 동영상 스트리밍이 여기에 해당합니다.

 

PORT
포트는 컴퓨터 내에서 프로세스나 서비스를 식별하는 데 사용되는 번호입니다. 포트는 IP 주소와 결합하여 데이터가 어떤 프로세스나 서비스로 전송되어야 하는지를 결정합니다. 예를 들어, 웹 브라우저는 HTTP 트래픽을 보내기 위해 일반적으로 포트 80을 사용하며, 보안 HTTP는 포트 443을 사용합니다.

 

DNS (도메인 이름 시스템)

인터넷에서 도메인 이름을 해당 IP 주소로 해석하는 역할을 합니다. 사용자가 웹 브라우저에서 도메인을 입력하면, DNS는 이를 해당 웹 서버의 IP 주소로 변환하여 사용자의 요청을 올바른 위치로 전달합니다. DNS는 인터넷의 "전화번호부"라고 생각할 수 있습니다.

 

URI (Uniform Resource Identifier)
URI는 인터넷에서 리소스(웹 페이지, 이미지, 동영상, 파일 등)를 식별하기 위한 문자열입니다. URI는 URL(Uniform Resource Locator)과 URN(Uniform Resource Name)의 두 가지 주요 하위 유형으로 나뉩니다.

URL (Uniform Resource Locator)
URL은 리소스의 위치를 지정합니다. 주로 웹 주소로 알려져 있으며, 프로토콜(예: HTTP 또는 HTTPS), 호스트(웹 서버의 주소), 포트(선택적), 경로 등으로 구성됩니다. 예를 들어, "https://www.example.com/about"는 URL의 한 예입니다.

URN (Uniform Resource Name)
URN은 리소스의 이름을 지정합니다. 리소스의 위치가 바뀌어도 URN은 유지됩니다. 예를 들어, ISBN(국제 표준 도서 번호)은 URN의 한 예입니다.

 

URL 호출 시 발생하는 일 

1. URL 입력: 사용자가 웹 브라우저의 주소 표시줄에 웹 페이지의 URL을 입력합니다. 예를 들어 www.example.com, 과 같은 URL을 입력합니다.
2. URL 파싱: 웹 브라우저는 입력된 URL을 해석하고, 프로토콜(여기서는 HTTPS), 호스트(www.example.com), 포트(기본적으로는 443), 경로 등을 추출합니다.
3. DNS 조회: 브라우저는 호스트를 DNS(Domain Name System)에 요청하여 IP 주소로 변환합니다. 이 단계에서 DNS 서버는 호스트 이름에 해당하는 IP 주소를 찾아 브라우저에 반환합니다.
4. TCP 연결 설정: 브라우저는 웹 서버의 IP 주소를 획득했으므로, 해당 IP 주소로 TCP/IP 연결을 설정합니다. 이 과정은 TCP handshake  과정을 포함하며, 웹 서버와 안전하게 통신하기 위한 암호화(TLS/SSL) 연결을 설정할 수도 있습니다. 
5. HTTP 요청 전송: TCP 연결이 설정되면 브라우저는 HTTP 요청을 웹 서버로 전송합니다. 이 요청은 HTTP 메서드(GET, POST 등)와 함께 URL의 나머지 부분(경로 및 쿼리 매개변수)를 포함하며, 웹 서버에 원하는 리소스를 요청합니다.
6. 서버 응답 수신: 웹 서버는 요청을 받고, 해당 리소스(HTML 파일, 이미지, 스크립트 등)를 찾아서 HTTP 응답으로 클라이언트(브라우저)에게 전송합니다. 응답은 상태 코드(200 OK, 404 Not Found 등)와 함께 리소스의 본문 데이터를 포함합니다.
7. 응답 처리: 브라우저는 서버로부터 받은 응답을 처리합니다. HTML 문서를 렌더링하고, 스타일시트(CSS)를 적용하며, JavaScript 코드를 실행합니다. 이 단계에서 웹 페이지가 시각적으로 표시됩니다.
8. 하이퍼링크 탐색: 웹 페이지에는 하이퍼링크(링크)가 포함되어 있을 수 있습니다. 사용자가 링크를 클릭하면, 브라우저는 해당 링크의 URL로 다시 이동하며 위의 단계를 반복합니다.
9. 캐시 사용: 브라우저는 이전에 방문한 웹 페이지의 데이터를 캐시에 저장하여 미래에 더 빠른 로딩을 지원합니다. 따라서 동일한 웹 페이지에 다시 방문하면 일부 데이터는 캐시에서 로드됩니다.
10. 사용자 상호작용: 사용자가 웹 페이지와 상호작용하면, 브라우저는 해당 상호작용에 따라 추가 요청을 생성하고 웹 페이지를 업데이트합니다.

 

HTTP(Hypertext Transfer Protocol)

HTTP는 웹에서 클라이언트(일반적으로 웹 브라우저)와 서버 간의 통신을 관리하는 프로토콜입니다. 이것은 웹 페이지의 로드, 데이터의 전송, 웹 애플리케이션의 동작 등 웹의 핵심 기능을 제공합니다.

클라이언트와 서버 구조
HTTP 통신은 기본적으로 클라이언트-서버 모델을 따릅니다. 이 모델에서 클라이언트는 웹 브라우저와 같은 사용자 에이전트를 나타내며, 서버는 웹 페이지와 리소스를 호스팅하는 웹 서버를 나타냅니다. 클라이언트는 서버에 요청을 보내고, 서버는 요청을 처리하고 응답을 보냅니다.

상태 유지 관리
HTTP는 기본적으로 비상태 프로토콜입니다. 이것은 서버가 클라이언트의 상태를 유지하지 않는다는 것을 의미합니다. 각각의 요청은 서로 독립적이며, 서버는 이전 요청과 현재 요청 사이에 어떤 관련성도 파악하지 않습니다. 이러한 특성은 서버의 부하를 줄이고 확장성을 향상시키는 데 도움이 됩니다. 하지만 웹 애플리케이션은 종종 상태 유지를 필요로 합니다. 이를 위해 쿠키(cookie)와 세션(session)과 같은 기술을 사용하여 클라이언트와 서버 간의 상태를 관리합니다. 쿠키는 클라이언트 측에 데이터를 저장하고, 세션은 서버 측에 상태 정보를 유지하는 데 사용됩니다.

비연결성
HTTP는 기본적으로 비연결성을 가지고 있습니다. 이것은 클라이언트가 서버와 한 번의 요청-응답 사이클을 완료하면 연결이 종료된다는 것을 의미합니다. 즉, 각각의 HTTP 요청은 서로 독립적이며, 이전 연결과 관련이 없습니다. 하지만 웹 페이지는 여러 리소스(이미지, 스크립트, 스타일 시트 등)를 로드해야 하므로, 여러 개의 연결이 필요합니다. 이를 위해 브라우저는 도메인당 병렬 연결을 지원하며, 최신 HTTP/2와 HTTP/3 프로토콜은 요청 다중화와 스트림 기능을 통해 연결을 효율적으로 관리합니다.

HTTP 메시지
HTTP 통신은 클라이언트와 서버 간에 메시지를 교환하는 것으로 이루어집니다. 이 메시지는 요청(Request)와 응답(Response) 두 가지 형태로 나눌 수 있습니다.

HTTP 요청 메시지: 클라이언트가 서버에게 리소스를 요청할 때 사용됩니다. 요청 메시지는 HTTP 메서드(GET, POST, PUT, DELETE 등)와 요청 헤더(페이지에 대한 정보, 캐싱 지침 등) 및 요청 본문(POST 요청과 함께 전송되는 데이터)으로 구성됩니다.

HTTP 응답 메시지: 서버가 클라이언트에게 리소스를 제공할 때 사용됩니다. 응답 메시지는 상태 코드(요청의 결과를 나타내는 숫자), 응답 헤더(응답에 대한 정보, 캐싱 지침 등), 응답 본문(웹 페이지의 HTML 내용, 이미지 데이터 등)으로 구성됩니다.

HTTP 메시지는 텍스트 기반 형식으로 이루어져 있으며, 사람이 읽을 수 있고 디버깅이 가능합니다. 이것은 HTTP의 간단하고 투명한 특성을 나타냅니다.

 

HTTP Method

HTTP 메서드, 또는 HTTP 요청 메서드,는 클라이언트가 웹 서버에게 수행하길 원하는 작업을 지정하는 방법입니다. HTTP/1.1 프로토콜에서는 다양한 메서드가 정의되어 있으며, 각 메서드는 특정한 역할과 의미를 가지고 있습니다.

 

주요 HTTP 메서드

1. GET
용도: 리소스 조회
특징: 서버에서 데이터를 가져오기 위해 사용됩니다. 주로 웹 페이지 로드에 사용되며, 요청 파라미터를 URL에 포함하여 전달합니다.

2. POST
용도: 데이터 제출 또는 생성
특징: 클라이언트에서 서버로 데이터를 전송할 때 사용됩니다. 주로 폼 데이터를 제출하거나 리소스를 생성하는 데 활용됩니다.

3. PUT
용도: 리소스 업데이트 또는 생성
특징: 클라이언트에서 서버로 데이터를 전송하여 리소스를 업데이트하거나 생성할 때 사용됩니다. 주로 식별자를 지정하여 특정 리소스를 대체합니다.

4. DELETE
용도: 리소스 삭제
특징: 지정된 리소스를 삭제하기 위해 사용됩니다. 서버에서 해당 리소스를 삭제하고 응답을 반환합니다.

5. PATCH
용도: 리소스 부분 업데이트
특징: 리소스의 일부만 업데이트할 때 사용됩니다. PUT과 달리 리소스를 완전히 대체하지 않고 일부만 변경합니다.

6. HEAD
용도: 헤더 정보 조회
특징: GET과 유사하지만 응답으로 헤더 정보만 받아옵니다. 실제 데이터를 받아오지 않으므로 대용량 데이터를 다운로드하지 않고도 리소스 상태를 확인할 수 있습니다.

 

기타 HTTP 메서드

위에 나열된 메서드 이외에도 HTTP/1.1에는 다른 메서드도 존재합니다. 이러한 메서드 중 일부는 다음과 같습니다.

OPTIONS: 서버가 지원하는 메서드를 확인하기 위해 사용됩니다.

TRACE: 클라이언트와 서버 간의 통신 경로를 디버깅하기 위해 사용됩니다.

CONNECT: 프록시와 함께 사용되며, 호스트와의 네트워크 연결을 설정할 때 사용됩니다.

 

RESTful API와 HTTP 메서드

HTTP 메서드는 RESTful API 디자인에서 중요한 역할을 합니다. 각 메서드는 리소스에 대한 CRUD(Create, Read, Update, Delete) 작업을 나타내며, RESTful 웹 서비스에서는 이러한 메서드를 적절하게 활용하여 API 엔드포인트를 설계합니다.

예를 들어, 다음과 같이 HTTP 메서드를 사용하여 RESTful API를 디자인할 수 있습니다:

GET /products: 제품 목록 조회
POST /products: 제품 생성
PUT /products/{id}: 특정 제품 업데이트
DELETE /products/{id}: 특정 제품 삭제

 

메서드 속성

안전 (Safe)

• 안전한 메서드는 해당 요청이 리소스의 상태를 변경하지 않음을 보장합니다. 즉, 리소스를 조회하는 용도로만 사용됩니다.
• 안전한 메서드는 주로 GET 메서드와 HEAD 메서드입니다.
• GET 메서드는 리소스를 조회하기 위해 사용되며, HEAD 메서드는 헤더 정보만을 조회하므로 리소스의 상태를 변경하지 않습니다.
• 안전한 메서드는 여러 번 호출해도 동일한 결과를 반환해야 합니다.

역등 (Idempotent)

• 역등한 메서드는 같은 요청을 여러 번 실행하더라도 동일한 결과를 보장합니다. 즉, 여러 번 요청해도 리소스의 상태가 동일하게 유지되어야 합니다
• 역등한 메서드는 GET, HEAD, PUT, DELETE와 같은 메서드입니다.
• GET 및 HEAD 메서드는 조회만 하는 메서드이므로 역등성을 가집니다.
• PUT 메서드는 리소스를 업데이트하거나 생성하는데 사용되며, 여러 번 호출해도 동일한 결과를 보장합니다.
• DELETE 메서드는 리소스를 삭제하는데 사용되며, 동일한 리소스를 여러 번 삭제하더라도 상태가 동일하게 유지됩니다.

캐시 가능 (Cacheable)

• 캐시 가능한 메서드는 응답 데이터를 캐싱할 수 있는 메서드입니다. 이는 웹 브라우저 또는 중간 프록시 서버에서 응답 데이터를 저장하고 동일한 요청에 대한 재사용을 가능하게 합니다.
• 주로 GET 메서드가 캐시 가능한 메서드입니다.
• GET 메서드는 리소스를 조회하는 용도로 사용되며, 같은 리소스에 대한 여러 요청 간에 캐시를 사용하여 응답 속도를 향상시키는 데 도움을 줍니다.

 

반응형

 

HTTP 상태 코드

HTTP 상태 코드는 5개의 클래스로 나뉩니다. 각 클래스는 서버의 응답 상태를 나타내며, 그 중 일부 주요 상태 코드에 대해 설명하겠습니다.

Informational (1xx): 이 클래스의 상태 코드는 요청이 받아들여졌거나 처리 중임을 나타냅니다. 예를 들어, 100 (Continue) 상태 코드는 클라이언트가 요청을 계속할 수 있음을 알리는 데 사용됩니다.

Successful (2xx): 이 클래스의 상태 코드는 요청이 성공적으로 처리되었음을 나타냅니다. 가장 흔한 것은 200 (OK) 상태 코드로, 요청이 성공적으로 완료되었음을 나타냅니다. 다른 예로는 201 (Created) 상태 코드는 새 리소스가 성공적으로 생성되었음을 나타냅니다.

 

• 200 OK (성공): 이 상태 코드는 클라이언트의 요청이 성공적으로 처리되었음을 나타냅니다. 서버가 요청을 올바르게 이해하고, 요청된 작업을 성공적으로 수행한 경우에 사용됩니다. 보통 웹 페이지나 리소스에 대한 정상적인 응답으로 사용됩니다.

 

• 201 Created (생성됨): 이 상태 코드는 클라이언트의 요청으로 새 리소스가 성공적으로 생성되었음을 나타냅니다. 주로 POST 요청으로 새로운 데이터나 리소스를 만들 때 사용됩니다.

 

• 202 Accepted (수락됨): 이 상태 코드는 클라이언트의 요청이 서버에게 수락되었지만 아직 처리되지 않았음을 나타냅니다. 이것은 비동기적인 작업 처리 시 사용될 수 있으며, 클라이언트는 나중에 상태를 확인해야 합니다.

 

• 204 No Content (내용 없음): 이 상태 코드는 요청이 성공적으로 처리되었지만 응답 본문에 어떠한 데이터도 포함되지 않음을 나타냅니다. 주로 업데이트나 삭제와 같은 작업을 수행한 후에 사용됩니다.

 

Redirection (3xx): 이 클래스의 상태 코드는 요청을 완료하기 위해 클라이언트에게 추가 조치를 요구할 때 사용됩니다. 예를 들어, 301 (Moved Permanently) 상태 코드는 요청한 리소스가 새로운 위치로 옮겨졌음을 나타냅니다.

 

• 301 Moved Permanently (영구적으로 이동함): 이 상태 코드는 요청한 리소스가 새로운 URL로 영구적으로 이동했음을 나타냅니다. 이것은 검색 엔진에게 이전 URL의 랭킹을 새 URL로 전달하도록 하는 데 주로 사용됩니다. 브라우저는 이후에 해당 리소스를 새 URL로 요청합니다.

 

• 302 Found (임시로 이동함): 이 상태 코드는 요청한 리소스가 임시로 다른 위치에 있음을 나타냅니다. 브라우저는 리소스를 새 위치로 요청하지만 이동은 일시적이며 나중에 원래 위치로 다시 돌아올 수 있습니다.

 

• 303 See Other (다른 곳을 참조하라): 이 상태 코드는 POST 요청을 받은 서버에서 클라이언트에게 다른 URL로 GET 요청을 보내도록 요청할 때 사용됩니다. 주로 웹 폼 처리 후 리다이렉션할 때 사용됩니다.

 

• 304 Not Modified : 클라이언트가 요청한 리소스가 변경되지 않았음을 나타내는 상태 코드입니다. 이 상태 코드는 웹 브라우저와 웹 서버 간의 효율적인 캐싱을 지원하고, 웹 페이지의 로딩 속도를 개선하는 데 사용됩니다.

 

• 307 Temporary Redirect (임시적으로 이동함): 302 Found와 비슷하지만, 307 Temporary Redirect는 클라이언트가 POST 요청을 그대로 유지하도록 요청합니다. 즉, 리다이렉션 후에도 클라이언트는 원래 요청을 그대로 다시 시도해야 합니다.

 

• 308 Permanent Redirect (영구적으로 이동함): 301 Moved Permanently와 유사하지만, 308 Permanent Redirect는 리다이렉션 후에도 클라이언트가 원래 요청을 그대로 유지해야 함을 나타냅니다.

 

Client Error (4xx): 이 클래스의 상태 코드는 클라이언트 오류를 나타냅니다. 가장 흔한 것은 404 (Not Found) 상태 코드로, 요청한 리소스를 찾을 수 없음을 나타냅니다. 다른 예로는 400 (Bad Request) 상태 코드는 서버가 요청을 이해하지 못하거나 유효하지 않다고 판단할 때 사용됩니다.

 

• 400 Bad Request (잘못된 요청): 이 상태 코드는 서버가 클라이언트의 요청을 이해하지 못하거나 유효하지 않다고 판단한 경우에 사용됩니다. 주로 클라이언트가 잘못된 데이터를 보낸 경우나 요청 형식이 잘못된 경우에 발생합니다.

 

• 401 Unauthorized (인증 실패): 이 상태 코드는 클라이언트가 인증되지 않았거나 인증 정보가 유효하지 않을 때 사용됩니다. 주로 보호된 리소스에 접근 시 인증이 필요한 경우에 발생합니다.

 

• 403 Forbidden (금지됨): 이 상태 코드는 클라이언트가 요청한 리소스에 접근 권한이 없을 때 사용됩니다. 클라이언트가 요청한 작업을 수행할 권한이 없는 경우에 발생합니다.

 

• 404 Not Found (찾을 수 없음): 이 상태 코드는 클라이언트가 요청한 리소스를 서버가 찾을 수 없을 때 사용됩니다. 주로 잘못된 URL이나 삭제된 리소스에 대한 요청에 발생합니다.

 

• 429 Too Many Requests (너무 많은 요청): 이 상태 코드는 클라이언트가 일정 시간 동안 너무 많은 요청을 보냈을 때 사용됩니다. 서버는 클라이언트의 요청을 제한하고 다시 시도할 때까지 기다리라고 알립니다.

Server Error (5xx): 이 클래스의 상태 코드는 서버 오류를 나타냅니다. 500 (Internal Server Error) 상태 코드는 서버에서 처리 중에 오류가 발생했음을 나타냅니다.

 

• 500 Internal Server Error (내부 서버 오류):이 상태 코드는 서버가 처리 중에 오류가 발생했거나 처리할 수 없는 예기치 않은 상황이 발생했음을 나타냅니다.주로 서버 측 스크립트나 애플리케이션에서 발생한 버그, 잘못된 설정, 또는 하드웨어 문제로 인해 발생할 수 있습니다.

 

• 501 Not Implemented (구현되지 않음):이 상태 코드는 클라이언트의 요청에 대한 처리가 서버에서 구현되지 않았음을 나타냅니다.예를 들어, 클라이언트가 지원되지 않는 HTTP 메서드를 사용한 경우에 발생할 수 있습니다.

 

• 502 Bad Gateway (불량 게이트웨이):이 상태 코드는 서버가 게이트웨이나 프록시 서버로부터 잘못된 응답을 받았나 게이트웨이 서버 자체에 문제가 있을 때 발생합니다.주로 서버 간 통신 문제로 인해 발생합니다.

 

• 503 Service Unavailable (서비스 이용 불가):이 상태 코드는 서버가 현재 서비스를 이용할 수 없는 상태임을 나타냅니다. 주로 서버 과부하, 유지 보수 작업, 임시적으로 다운된 상태 등으로 인해 발생합니다.일시적인 문제일 경우 나중에 다시 시도하라는 메시지와 함께 응답할 수 있습니다.

 

• 504 Gateway Timeout (게이트웨이 시간 초과):이 상태 코드는 게이트웨이나 프록시 서버가 백엔드 서버로부터 응답 을 기다리는 동안 시간 초과되었을 때 발생합니다.주로 백엔드 서버가 응답을 너무 늦게 제공하는 경우에 발생합니다.

 

• 505 HTTP Version Not Supported (HTTP 버전 지원하지 않음):이 상태 코드는 클라이언트의 HTTP 프로토콜 버전이 서버에서 지원되지 않을 때 사용됩니다.클라이언트나 서버에서 사용하는 HTTP 버전을 업그레이드하거나 수정해야 할 수 있습니다.

 

HTTP 헤더

HTTP(Hypertext Transfer Protocol)는 웹 통신의 기반이 되는 프로토콜로, 클라이언트와 서버 간의 데이터 교환에 필수적입니다. HTTP 헤더는 이 통신에서 메시지의 부가 정보를 전달하는 역할을 합니다. 이러한 정보는 요청과 응답 메시지의 메타데이터로 사용되며, 통신의 원활한 진행과 향상된 사용자 경험을 위해 중요합니다.

 

표현 (Representation)

Content-Type 헤더
Content-Type 헤더는 웹 리소스의 콘텐츠 유형을 정의합니다. 이 헤더는 클라이언트에게 리소스의 미디어 타입 (예: 텍스트, 이미지, JSON 등) 및 문자 인코딩 (UTF-8, ISO-8859-1 등) 정보를 제공합니다. 서버는 이 정보를 통해 클라이언트에게 올바른 데이터 형식으로 응답할 수 있도록 합니다.

Content-Length 헤더
Content-Length 헤더는 응답 본문의 길이를 바이트 단위로 나타냅니다. 이 정보를 사용하면 클라이언트가 응답 데이터를 얼마나 받아야 하는지 정확하게 알 수 있습니다. 또한 데이터 전송 중에 응답의 끝을 정확하게 식별할 수 있도록 도와줍니다.

Content-Encoding 헤더
Content-Encoding 헤더는 콘텐츠의 압축 및 인코딩 메커니즘을 지정합니다. 이 헤더는 서버가 응답 데이터를 압축하여 전송하는 경우에 사용됩니다. 클라이언트는 이 정보를 사용하여 데이터를 해제하고 읽을 수 있습니다.

 

컨텐츠 협상 (Content Negotiation)

Accept 및 Accept-Language 헤더
Accept 헤더는 클라이언트가 서버로부터 받아들일 수 있는 미디어 타입 및 우선순위를 나타냅니다. Accept-Language 헤더는 클라이언트가 선호하는 언어를 지정합니다. 이 정보는 서버에게 콘텐츠 협상을 수행하고 적절한 리소스를 선택하는 데 도움을 줍니다.

서버의 컨텐츠 협상 메커니즘
서버는 클라이언트의 Accept 및 Accept-Language 헤더와 일치하는 콘텐츠를 선택하는 방법을 결정합니다. 이를 위해 서버는 각각의 요청에 대한 적절한 응답을 선택하고 제공합니다. 이로써 다국어 지원 및 다양한 미디어 형식을 처리할 수 있습니다.

Vary 헤더
Vary 헤더는 캐시와 관련이 있으며, 캐시된 응답을 반환하기 전에 Accept 및 Accept-Language과 같은 컨텐츠 협상 헤더를 고려해야 함을 나타냅니다. 이것은 캐시된 데이터가 클라이언트의 요청과 일치하는 경우에만 사용되도록 합니다.

 

 

전송 방식 (Transfer Encodings)

Transfer-Encoding 헤더
Transfer-Encoding 헤더는 HTTP 응답 메시지에서 전송 인코딩 메커니즘을 지정하는데 사용됩니다. 이 헤더는 클라이언트에게 메시지가 어떻게 인코딩되었는지 알려주며, 클라이언트는 이 정보를 사용하여 응답 메시지를 해석합니다. 가장 일반적인 전송 인코딩 메커니즘 중 하나는 "chunked"입니다. Chunked 전송은 메시지를 여러 조각으로 분할하고 각 조각을 개별적으로 전송하는 방식입니다. 이것은 메시지 길이를 미리 알 수 없는 경우에 유용하며, 실시간 스트리밍과 호환됩니다.

Content-Disposition 헤더
Content-Disposition 헤더는 서버가 응답하는 리소스의 표시 방법을 클라이언트에게 지정합니다. 이 헤더는 일반적으로 다운로드 가능한 파일의 이름을 제공하고, 브라우저가 리소스를 어떻게 처리해야 하는지 알려주는 데 사용됩니다. 예를 들어, "attachment" 값을 사용하면 리소스를 다운로드로 처리하고, "inline" 값을 사용하면 리소스를 브라우저에서 직접 열 수 있도록 합니다.

 

일반 정보 (General Information)

Date 헤더
Date 헤더는 서버가 응답을 생성한 날짜와 시간을 나타냅니다. 이 정보는 클라이언트와 서버 사이의 통신에서 시간 정보를 동기화하는 데 사용됩니다.

Connection 헤더
Connection 헤더는 현재 커넥션을 계속 유지할 것인지 또는 종료할 것인지를 나타냅니다. 이 헤더는 "keep-alive" 값을 가질 수 있으며, 이 경우 커넥션을 재사용하여 추가 요청과 응답을 처리하는 데 도움을 줍니다.

Via 헤더
Via 헤더는 메시지가 전달된 서버 또는 프록시 서버의 경로 정보를 전달합니다. 이 헤더는 메시지가 어떻게 전달되었는지 추적하는 데 사용됩니다.

Upgrade 헤더
Upgrade 헤더는 클라이언트가 현재 프로토콜을 다른 프로토콜로 업그레이드하기 위한 요청을 보낼 때 사용됩니다. 이것은 웹 소켓과 같은 더 효율적인 프로토콜로 전환하는 데 사용됩니다.

 

Server 헤더
Server 헤더는 서버 소프트웨어의 정보를 전달합니다. 이 헤더는 보안 및 취약성 분석에 사용될 수 있으므로 서버 관리자가 주의를 기울여야 합니다.

Referer 및 User-Agent 헤더
Referer 헤더는 현재 요청을 만들기 위해 이전 페이지에서 어떤 페이지로 링크를 따라왔는지 나타내며, User-Agent 헤더는 클라이언트 소프트웨어 (예: 웹 브라우저)에 대한 정보를 전달합니다. 이 정보는 웹 서버 및 웹 애플리케이션에서 사용자 행동을 추적하고 최적화하는 데 도움을 줍니다.

 

특별한 정보 (Special Information)

Host 헤더 (Host):
Host 헤더는 HTTP/1.1 이상에서 필수적인 헤더입니다.
이 헤더는 클라이언트가 요청하는 웹 서버의 호스트 이름과 포트 번호를 지정합니다. 하나의 웹 서버에서 여러 도메인을 호스팅하는 경우, Host 헤더를 사용하여 서버는 어떤 도메인에 대한 요청인지를 식별합니다.

Location 헤더 (Location):
Location 헤더는 주로 HTTP 리다이렉션 시나리오에서 사용됩니다.
이 헤더는 클라이언트에게 새로운 URL로 이동하라는 지시를 제공합니다. 클라이언트는 이 URL로 다시 요청을 보내거나 브라우저는 사용자를 해당 URL로 리다이렉션합니다.
주로 3xx 상태 코드와 함께 사용되며, 주요 사용 사례로는 301 Moved Permanently (영구적 리다이렉션) 및 302 Found (임시 리다이렉션)가 있습니다.

Allow 헤더 (Allow):
Allow 헤더는 HTTP 메서드 중 리소스에서 허용되는 메서드를 나타냅니다.
이 헤더는 클라이언트에게 어떤 HTTP 메서드를 사용하여 해당 리소스에 대한 요청을 할 수 있는지 알려줍니다. 주로 OPTIONS 메서드와 함께 사용됩니다.

 

Retry-After 헤더 (Retry-After):
Retry-After 헤더는 서버에서 클라이언트에게 다시 시도하도록 권장하는 시간을 나타냅니다.
주로 503 Service Unavailable 상태 코드와 함께 사용되며, 서버가 과부하 상태이거나 유지 보수 중인 경우 클라이언트에게 얼마나 기다려야 하는지 알려줍니다.
시간을 초(second) 또는 HTTP 날짜 형식 (RFC 1123)으로 지정할 수 있습니다.

 

인증 (Authentication)

Authorization 헤더
Authorization 헤더는 요청 시 사용자 인증 정보를 서버에 제공합니다. 이 정보는 보호된 리소스에 접근하려는 클라이언트의 신원을 확인하는 데 사용됩니다.

WWW-Authenticate 헤더
WWW-Authenticate 헤더는 서버가 인증을 요구할 때 클라이언트에게 어떤 인증 방법을 사용해야 하는지 알려줍니다. 클라이언트는 이 정보를 기반으로 적절한 인증 요청을 생성합니다

 

쿠키 (Cookies)

Cookie 및 Set-Cookie 헤더
Cookie 헤더는 클라이언트와 서버 간의 상태 정보를 유지하기 위해 사용되며, Set-Cookie 헤더는 쿠키를 클라이언트에게 설정하도록 지시합니다. 이를 통해 웹 애플리케이션은 클라이언트의 세션 상태를 유지하고 사용자 경험을 개선할 수 있습니다. 쿠키의 동작 원리와 보안 주의 사항도 중요합니다.

 

쿠키의 작동 방식:
웹 서버에서 클라이언트로 전송된 쿠키는 클라이언트의 웹 브라우저에 저장됩니다.
클라이언트가 동일한 웹 사이트를 방문할 때, 해당 웹 사이트로부터 요청된 쿠키를 함께 전송하여 서버는 클라이언트를 식별하고 추가 정보를 제공할 수 있습니다.
쿠키는 키-값 쌍으로 구성되어 있으며, 이름, 값, 유효 기간, 도메인, 경로 등의 속성을 가질 수 있습니다.

 

쿠키의 주요 속성:
이름(Name): 쿠키의 고유한 식별자.
값(Value): 쿠키에 저장되는 데이터 또는 정보.
도메인(Domain): 쿠키가 유효한 도메인을 지정합니다. 해당 도메인 또는 하위 도메인에서만 쿠키가 전송됩니다.
경로(Path): 쿠키가 유효한 URL 경로를 지정합니다. 특정 경로 하위에서만 쿠키가 전송됩니다.
유효 기간(Expiration): 쿠키의 유효 기간을 설정하며, 기간이 지나면 자동으로 삭제됩니다. 세션 쿠키(브라우저가 열려 있는 동안만 유효)와 영구 쿠키(특정 날짜까지 유효)로 구분됩니다.
보안(secure): HTTPS 연결에서만 쿠키를 전송하도록 지정하는 속성.

 

쿠키의 사용 사례:
사용자 인증: 사용자 로그인 정보를 쿠키에 저장하여 웹 사이트가 사용자를 인증하고 로그인 상태를 유지할 수 있습니다.
장바구니 관리: 온라인 쇼핑 웹 사이트에서 사용자의 장바구니 내용을 저장하고 유지합니다.
사용자 추적: 웹 사이트 방문자의 행동과 관련된 정보를 수집하여 분석 및 통계를 생성합니다.
언어 및 선호 설정 저장: 사용자의 언어 및 선호 설정을 저장하여 웹 사이트를 맞춤화합니다.
세션 관리: 웹 애플리케이션 세션을 유지하고 상태 정보를 저장합니다.

 

보안 및 개인 정보 보호:
쿠키는 클라이언트 측에서 저장되기 때문에 보안과 개인 정보 보호에 주의를 기울여야 합니다.
민감한 정보(예: 비밀번호)를 저장하거나 공개해서는 안 됩니다.
영구 쿠키의 경우, 사용자에게 동의를 받는 것이 중요합니다.
HttpOnly 및 Secure 속성을 사용하여 보안을 강화할 수 있습니다.

 

캐시 기본 동작 (Caching Basics)

Cache-Control 헤더
Cache-Control 헤더는 캐싱 동작을 제어하는 지시사항을 포함합니다. 이 헤더를 사용하여 클라이언트 및 중간 캐시 서버가 리소스를 어떻게 캐시하고 재사용할지를 정의할 수 있습니다. 예를 들어, max-age 지시자를 사용하여 리소스의 캐시 유효 기간을 설정할 수 있으며, no-cache 지시자를 사용하여 항상 서버로부터 새로운 리소스를 요청하도록 할 수 있습니다.

Expires 및 Last-Modified 헤더
Expires 헤더는 리소스의 캐시 유효 기간을 날짜와 시간으로 정의합니다. 클라이언트 및 중간 캐시 서버는 이 정보를 사용하여 리소스의 유효성을 판단하고 새로운 요청을 서버로 보낼지 여부를 결정합니다. Last-Modified 헤더는 리소스의 마지막 수정 날짜를 제공하며, 조건부 요청에서 리소스의 변경 여부를 확인하는 데 사용됩니다.

 

검증 헤더와 조건부 요청 (Validation Headers and Conditional Requests)

ETag 및 If-None-Match 헤더
ETag 헤더는 엔터티 태그로서 리소스의 고유한 식별자를 나타냅니다. 클라이언트는 이 식별자를 사용하여 리소스의 캐시 유효성을 검사하고 If-None-Match 헤더를 통해 서버에게 리소스가 변경되었는지를 확인하는데 사용됩니다.

If-Modified-Since 및 If-Unmodified-Since 헤더
If-Modified-Since 헤더는 리소스의 마지막 수정 날짜와 비교하여 리소스가 변경되었는지를 확인합니다. 반면, If-Unmodified-Since 헤더는 리소스의 마지막 수정 날짜와 비교하여 리소스가 변경되지 않았는지를 확인합니다. 이러한 조건부 요청은 서버가 리소스를 다시 보내지 않아도 되는 경우에 사용됩니다.

 

캐시와 조건부 요청 헤더 (Cache and Conditional Request Headers)

If-Match 및 If-Range 헤더
If-Match 헤더는 엔터티 태그와 비교하여 리소스가 일치하는지를 확인합니다. If-Range 헤더는 엔터티 태그 또는 날짜와 범위 요청을 처리하는 데 사용됩니다. 이러한 조건부 요청 헤더를 사용하면 서버가 리소스를 전송하지 않아도 되는 경우에 대한 제어를 할 수 있습니다.

 

프록시 캐시 (Proxy Caches)

Proxy-Authenticate 및 Proxy-Authorization 헤더
Proxy-Authenticate 헤더는 프록시 서버가 요청한 리소스에 대한 인증을 요구할 때 클라이언트에게 어떤 인증 방법을 사용해야 하는지 알려줍니다. Proxy-Authorization 헤더는 클라이언트가 프록시 서버에게 자격 증명을 제공하는 데 사용됩니다.

Max-Forwards 헤더
Max-Forwards 헤더는 요청 메시지를 프록시 서버를 통해 전달할 때 전달 횟수를 제한합니다. 이 헤더는 무한 루프를 방지하고 요청의 전달을 제어하는 데 사용됩니다.

 

캐시 무효화 (Cache Invalidation)

캐시 무효화 관련 헤더 (예: Cache-Control의 no-cache, no-store, must-revalidate 등)는 캐시된 리소스를 무효화하고 새로운 데이터를 가져오도록 지시합니다. Pragma 헤더는 HTTP/1.0에서 사용되던 캐시 관련 헤더 중 하나로, 캐시 무효화에 관한 정보를 제공합니다.