HTTP 통합 포스팅

HTTP 통합 포스팅

이 포스팅에서는 HTTP와 관련된 여러 주제들을 통합하여 정리하고자 합니다. 각 주제별로 핵심 개념을 정리하고, 이해도를 높이기 위한 연습문제를 포함하고 있습니다. 자세한 내용은 각 주제의 개별 포스팅을 참고하시기 바랍니다.

---

인터넷 네트워크

포스팅에서는 인터넷에서의 통신이 어떻게 이루어지는지 알아보았습니다.

주요 개념

• IP (Internet Protocol): 인터넷 상에서 데이터를 전달하기 위한 프로토콜로, 각 장치에 고유한 IP 주소를 부여합니다.
• TCP (Transmission Control Protocol): 신뢰성 있는 데이터 전달을 담당하는 프로토콜로, 연결 지향적입니다.
• UDP (User Datagram Protocol): 빠른 데이터 전달을 담당하는 프로토콜로, 비연결성입니다.
• PORT: 하나의 IP 주소 내에서 여러 응용 프로그램을 구분하기 위한 번호입니다.
• DNS (Domain Name System): 도메인 이름을 IP 주소로 변환해주는 시스템입니다.

예시: 웹 브라우저에서 www.example.com을 입력하면, DNS를 통해 해당 도메인의 IP 주소를 알아내어 서버에 접속합니다.

확인 문제

1. IP 프로토콜의 한계점은 무엇인가요?

2. TCP의 주요 특징 세 가지는 무엇인가요?

3. UDP는 어떤 상황에서 사용되나요?

4. 포트 번호는 왜 필요하며, 어떤 역할을 하나요?

5. DNS를 사용하는 이유는 무엇인가요?

답안

1. IP 프로토콜은 비연결성이고 비신뢰성이며, 데이터의 전달 여부나 순서 보장을 하지 못합니다.

2. TCP의 주요 특징은 연결 지향성, 신뢰성 있는 데이터 전달 보증, 순서 제어입니다.

3. UDP는 실시간 서비스나 빠른 전송이 필요할 때 사용됩니다. 예를 들어 온라인 게임, 스트리밍 서비스 등.

4. 포트 번호는 하나의 IP 주소 내에서 여러 응용 프로그램(프로세스)을 구분하기 위해 필요합니다.

5. DNS를 사용하면 사람이 이해하기 쉬운 도메인 이름으로 웹 사이트에 접근할 수 있고, IP 주소 변경에도 지속적으로 접근이 가능합니다.

---

URI와 웹 브라우저 요청 흐름

포스팅에서는 URI의 개념과 웹 브라우저가 요청을 처리하는 흐름에 대해 알아보았습니다.

주요 개념

• URI (Uniform Resource Identifier): 리소스를 식별하는 통합된 방법으로, URL과 URN을 포함하는 개념입니다.
• URL (Uniform Resource Locator): 리소스의 위치를 나타내는 방법입니다.
• URN (Uniform Resource Name): 리소스의 이름을 나타내는 방법입니다.

참고: URL은 우리가 흔히 사용하는 웹 주소이며, URN은 ISBN 같은 리소스의 고유한 이름입니다.

• 웹 브라우저 요청 흐름: 사용자가 URL을 입력하면 DNS 조회, TCP 연결 설정, HTTP 요청 메시지 생성 및 전송, 서버의 응답 처리가 이루어집니다.

확인 문제

1. URL과 URN의 차이는 무엇인가요?

2. 웹 브라우저가 도메인 이름을 IP 주소로 변환하기 위해 사용하는 시스템은 무엇인가요?

3. TCP 연결을 설정하기 위한 과정을 무엇이라고 하나요?

답안

1. URL은 리소스의 위치를 나타내고, URN은 리소스의 이름을 나타냅니다.

2. DNS (Domain Name System)을 사용합니다.

3. TCP 연결 설정 과정은 3-way handshake라고 합니다.

---

HTTP 기본

포스팅에서는 HTTP의 기초 개념과 특성에 대해 알아보았습니다.

주요 개념

• HTTP: HyperText Transfer Protocol의 약자로, 웹에서 데이터를 주고받기 위한 프로토콜입니다.
• 클라이언트-서버 구조: 클라이언트는 요청을 보내고, 서버는 응답을 반환하는 구조입니다.

예시: 웹 브라우저가 클라이언트로서 서버에 페이지 요청을 보내고, 서버는 해당 페이지를 응답으로 반환합니다.

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

장점: 서버의 확장성이 높아지고 자원 소모가 적습니다.

• 비연결성: HTTP는 기본적으로 요청과 응답 후 연결을 끊는 비연결성을 특징으로 합니다.

HTTP/1.1부터는 지속 연결(Persistent Connection)이 기본 적용되어 한 번의 연결로 여러 요청과 응답이 가능합니다.

• HTTP 메시지: 요청 메시지와 응답 메시지로 구성되며, 각 메시지는 시작줄, 헤더, 공백 줄, 본문으로 구성됩니다.

확인 문제

1. HTTP가 무상태(stateless) 프로토콜인 이유는 무엇인가요?

2. HTTP/1.1에서 도입된 연결 방식으로, 한 번의 연결로 여러 요청과 응답을 주고받을 수 있게 한 것은 무엇인가요?

3. HTTP 메시지는 어떤 구성 요소로 이루어져 있나요?

답안

1. 서버가 상태를 유지하지 않음으로써 확장성을 높이고, 서버 자원을 효율적으로 사용하여 대량의 요청을 효과적으로 처리할 수 있기 때문입니다.

2. 지속 연결(Persistent Connection)입니다.

3. 시작줄(Start Line), 헤더(Header), 공백 줄, 본문(Body)으로 구성됩니다.

---

HTTP 메서드

포스팅에서는 HTTP 메서드의 종류와 특징에 대해 알아보았습니다.

주요 개념

• GET: 리소스 조회에 사용됩니다.
• POST: 리소스 생성이나 데이터 처리에 사용됩니다.
• PUT: 리소스 전체를 대체하거나 없으면 생성합니다.
• PATCH: 리소스의 부분을 수정합니다.
• DELETE: 리소스를 삭제합니다.

주의: GET 요청은 멱등성과 안전성을 갖지만, POST 요청은 멱등하지 않습니다.

확인 문제

1. 리소스의 일부만 수정하려면 어떤 메서드를 사용해야 하나요?

2. 멱등하지 않은 메서드는 무엇이며, 그 이유는 무엇인가요?

3. GET과 POST의 주요 차이점은 무엇인가요?

답안

1. PATCH 메서드를 사용합니다.

2. POST 메서드는 멱등하지 않습니다. 동일한 POST 요청을 여러 번 보내면 중복 생성 등의 부작용이 발생할 수 있기 때문입니다.

3. GET은 리소스를 조회하기 위해 사용되며, 요청 데이터를 주로 URL의 쿼리 스트링으로 전달합니다. POST는 리소스를 생성하거나 데이터 처리를 위해 사용되며, 요청 데이터를 본문(body)에 포함하여 전송합니다.

---

HTTP 메서드 활용

포스팅에서는 실제 API 설계에서 HTTP 메서드를 어떻게 활용하는지 알아보았습니다.

주요 개념

• 리소스 중심의 URI 설계: URI는 리소스를 나타내며, 행위는 HTTP 메서드로 표현합니다.

예시: /members라는 URI에 대해 GET 메서드를 사용하면 회원 목록 조회가 되고, POST 메서드를 사용하면 회원 생성이 됩니다.

• 컬렉션(Collection) 패턴: 서버가 리소스의 URI를 생성하고 관리합니다.

• 스토어(Store) 패턴: 클라이언트가 리소스의 URI를 알고 지정합니다.

• 컨트롤 URI: HTTP 메서드만으로 표현하기 어려운 추가적인 동작을 URI에 동사로 포함합니다.

예시: /orders/{id}/cancel과 같이 주문을 취소하는 동작을 표현합니다.

확인 문제

1. 클라이언트가 리소스의 URI를 직접 지정하여 서버에 리소스를 저장하는 패턴은 무엇인가요?

2. 컨트롤 URI를 사용할 때 URI에 포함되는 것은 무엇인가요?

3. HTML Form에서 DELETE 메서드를 사용할 수 없을 때, 어떻게 요청을 설계하나요?

답안

1. 스토어(Store) 패턴입니다.

2. 동사(행위)가 포함됩니다.

3. POST 메서드를 사용하고, URI에 동사를 포함시켜 /members/{id}/delete로 요청합니다.

---

HTTP 상태코드

포스팅에서는 HTTP 상태코드의 의미와 종류에 대해 알아보았습니다.

주요 개념

• 1xx (정보): 요청이 처리 중임을 의미합니다.

• 2xx (성공): 요청이 성공적으로 처리되었음을 의미합니다.

  • 200 OK: 요청 성공
  • 201 Created: 리소스가 생성되었음

실무에서는 주로 200 OK, 201 Created, 204 No Content를 많이 사용합니다.

• 3xx (리다이렉션): 추가적인 조치가 필요함을 의미합니다.

  • 301 Moved Permanently: 리소스의 영구 이동
  • 302 Found: 리소스의 임시 이동

PRG(Post-Redirect-Get) 패턴에서 302 Found를 사용하여 POST 요청 후 결과 페이지로 리다이렉트합니다.

• 4xx (클라이언트 오류): 클라이언트의 잘못된 요청을 의미합니다.

  • 400 Bad Request: 잘못된 요청
  • 401 Unauthorized: 인증 필요
  • 403 Forbidden: 접근 권한 없음
  • 404 Not Found: 리소스를 찾을 수 없음

• 5xx (서버 오류): 서버의 문제로 요청을 처리할 수 없음을 의미합니다.

  • 500 Internal Server Error: 서버 내부 오류

주의: 5xx 오류는 서버 내부의 문제로 인한 것이므로, 비즈니스 로직 상의 에러는 4xx 상태코드를 사용하는 것이 적절합니다.

확인 문제

1. 클라이언트가 인증되지 않았을 때 반환되는 상태코드는 무엇인가요?

2. 요청한 리소스를 찾을 수 없을 때 반환되는 상태코드는 무엇인가요?

3. 서버 내부에 오류가 발생했을 때 반환되는 상태코드는 무엇인가요?

답안

1. 401 Unauthorized 상태코드가 반환됩니다.

2. 404 Not Found 상태코드가 반환됩니다.

3. 500 Internal Server Error 상태코드가 반환됩니다.

---

HTTP 일반 헤더

포스팅에서는 HTTP 헤더의 개요와 종류에 대해 알아보았습니다.

주요 개념

• 표현 헤더:

  • Content-Type: 표현 데이터의 MIME 타입을 지정합니다.
  • Content-Encoding: 표현 데이터를 압축하거나 인코딩한 방식을 명시합니다.
  • Content-Language: 표현 데이터의 언어를 명시합니다.
  • Content-Length: 표현 데이터의 길이를 명시합니다.

• 콘텐츠 협상: 클라이언트가 원하는 표현 형태를 서버에 알리는 것으로, 다음 헤더들을 사용합니다.

  • Accept
  • Accept-Charset
  • Accept-Encoding
  • Accept-Language

• 전송 방식:

  • Transfer-Encoding
  • Content-Encoding

Transfer-Encoding: chunked를 사용하여 데이터를 분할 전송할 수 있습니다.

• 일반 정보 헤더:

  • From
  • Referer
  • User-Agent
  • Server
  • Date

• 특별한 정보 헤더:

  • Host
  • Location
  • Allow
  • Retry-After

• 인증 헤더:

  • Authorization
  • WWW-Authenticate

Authorization 헤더를 통해 클라이언트의 인증 정보를 서버에 전달합니다.

• 쿠키:

  • Set-Cookie
  • Cookie

쿠키를 통해 HTTP의 무상태성(stateless)을 보완하여 상태를 유지할 수 있습니다.

확인 문제

1. 클라이언트가 서버에 원하는 콘텐츠의 언어를 지정하기 위해 사용하는 헤더는 무엇인가요?

2. 서버가 클라이언트에게 리소스의 최종 위치를 알려주기 위해 사용하는 헤더는 무엇인가요?

3. 쿠키를 설정할 때 보안 강화를 위해 설정할 수 있는 속성 두 가지는 무엇인가요?

답안

1. Accept-Language 헤더를 사용합니다.

2. Location 헤더를 사용합니다.

3. Secure와 HttpOnly 속성을 설정할 수 있습니다.

---

HTTP 캐시와 조건부 요청

포스팅에서는 웹 캐시의 동작 원리와 조건부 요청에 대해 알아보았습니다.

주요 개념

• 캐시(Cache): 클라이언트 또는 프록시 서버에서 리소스를 저장하여 재사용함으로써 네트워크 대역폭 절약과 응답 시간 단축을 가능하게 합니다.

예시: 브라우저 캐시는 자주 사용하는 리소스를 저장하여 페이지 로딩 속도를 향상시킵니다.

• 검증 헤더와 조건부 요청:

  • Last-Modified와 If-Modified-Since: 리소스의 최종 수정 시간을 기반으로 변경 여부를 판단합니다.
  • ETag와 If-None-Match: 리소스의 고유 식별자를 기반으로 변경 여부를 판단합니다.

304 Not Modified 상태코드는 리소스가 변경되지 않았음을 알려주며, 클라이언트는 캐시된 데이터를 재사용합니다.

• Cache-Control: 캐시 지시어를 통해 캐시 동작을 제어합니다.

  • max-age
  • no-cache
  • no-store

• 프록시 캐시: 여러 클라이언트가 공용으로 사용하는 캐시로, 네트워크 대역폭 절약과 응답 시간 단축에 기여합니다.

• 캐시 무효화: 민감한 정보를 포함하거나 항상 최신 데이터가 필요한 경우 캐시를 사용하지 않도록 설정합니다.

캐시 무효화를 위해 Cache-Control: no-cache, no-store, must-revalidate 지시어를 설정합니다.

확인 문제

1. 리소스가 변경되지 않았을 때 서버가 반환하는 상태코드는 무엇인가요?

2. 클라이언트가 리소스의 변경 여부를 확인하기 위해 사용하는 헤더는 무엇인가요?

3. 캐시를 확실히 사용하지 않도록 하기 위해 설정해야 하는 Cache-Control 지시어는 무엇인가요?

답안

1. 304 Not Modified 상태코드를 반환합니다.

2. If-Modified-Since 또는 If-None-Match 헤더를 사용합니다.

3. Cache-Control: no-cache, no-store, must-revalidate 지시어를 설정합니다.

---

이상으로 HTTP와 관련된 주요 개념들을 정리하였습니다. 각 주제에 대한 자세한 내용은 개별 포스팅을 참고하시기 바랍니다.

---

참고 포스팅

---