혼자 공부하는 네트워크 5-2 HTTP

HTTP의 특징, 메시지 구조, 메서드, 상태 코드 및 발전 과정

HTTP 특징

1. 요청-응답 기반 동작
   • HTTP는 클라이언트가 서버에 요청을 보내면 서버가 이에 응답하는 방식으로 동작합니다. 요청 메시지와 응답 메시지는 각각 다른 형식을 가집니다.
2. 미디어 독립적 프로토콜
   • HTTP는 다양한 종류의 자원을 주고받을 수 있는 미디어 독립적인 프로토콜입니다. 전송되는 자원의 종류는 미디어 타입(MIME 타입)으로 구분되며, "타입/서브타입" 형식으로 표현됩니다. 예를 들어, text/html이나 image/png 등이 있습니다. 또한, 매개변수를 포함하여 type/subtype; charset=UTF-8과 같이 상세하게 지정할 수도 있습니다.
3. 스테이트리스 프로토콜
   • HTTP는 상태를 유지하지 않는 스테이트리스(stateless) 프로토콜입니다. 서버는 클라이언트의 이전 요청 상태를 기억하지 않으며, 각 요청은 독립적인 것으로 간주됩니다. 이는 확장성과 견고성을 높여 서버의 추가나 문제 발생 시 유연하게 대처할 수 있게 합니다.
4. 지속 연결 지원
   • HTTP는 기본적으로 TCP 위에서 동작하는 비연결형 프로토콜이지만, HTTP/1.1부터는 지속 연결(Persistent Connection) 기능을 지원합니다. 이를 통해 하나의 TCP 연결에서 여러 개의 요청-응답을 주고받을 수 있으며, 연결을 유지하는 동안 지속적으로 통신할 수 있습니다. 이는 "Keep-Alive"라고도 불리며, 네트워크 효율성을 높입니다.

HTTP 메시지 구조

1. 시작 라인
   • HTTP 메시지는 요청 메시지일 경우 요청 라인, 응답 메시지일 경우 상태 라인으로 시작됩니다.
   • 요청 라인
     • 메서드(Method): 클라이언트가 서버에 수행할 작업의 종류를 나타냅니다. 예: GET, POST, PUT, DELETE
     • 요청 대상(Request Target): 요청을 보낼 서버의 자원 URI를 명시합니다.
     • HTTP 버전: 사용 중인 HTTP 프로토콜의 버전을 표시합니다. 예: HTTP/1.1
   • 상태 라인
     • HTTP 버전: 사용 중인 HTTP 프로토콜의 버전을 표시합니다.
     • 상태 코드(Status Code): 요청에 대한 서버의 응답 상태를 나타내는 3자리 숫자입니다. 예: 200, 404
     • 이유 구문(Reason Phrase): 상태 코드에 대한 간단한 설명입니다.
2. 필드 라인 (헤더)
   • 0개 이상의 HTTP 헤더로 구성되며, 각 헤더는 이름: 값 형식으로 작성됩니다. 예: Content-Type: text/html
3. 메시지 본문
   • 요청 또는 응답 메시지에 포함될 수 있으며, 전송되는 데이터의 실제 내용을 담고 있습니다. 예: HTML 문서, JSON 데이터 등

반응형

HTTP 메서드

1. GET
   • 특정 자원을 조회할 때 사용합니다. 예를 들어, 웹 페이지나 API에서 데이터를 가져올 때 사용됩니다. 요청 라인에 요청 대상과 호스트 헤더가 포함되며, 본문 대신 쿼리 문자열을 사용하는 경우가 많습니다.
2. HEAD
   • GET과 유사하지만, 응답 메시지의 본문을 제외하고 헤더만 반환받습니다. 리소스의 메타데이터를 확인할 때 유용합니다.
3. POST
   • 서버에 데이터를 제출하거나 특정 작업을 요청할 때 사용합니다. 요청 메시지의 본문에 처리할 데이터를 포함합니다.
4. PUT
   • 요청 자원이 없을 경우 새로운 자원을 생성하거나, 이미 존재하는 자원을 대체할 때 사용합니다. 요청 메시지의 본문에 자원 데이터를 포함합니다.
5. PATCH
   • 자원의 일부를 수정할 때 사용합니다. PUT과 달리 전체 자원을 대체하지 않고, 일부만 변경할 수 있습니다.
6. DELETE
   • 특정 자원을 삭제할 때 사용합니다.

HTTP 상태 코드

1. 200번대: 성공 상태 코드
   • 200 OK: 요청이 성공적으로 완료되었습니다.
   • 201 Created: 새로운 자원이 성공적으로 생성되었습니다.
   • 202 Accepted: 요청이 수락되었으나, 처리가 완료되지 않았습니다.
   • 204 No Content: 요청은 성공했으나, 반환할 콘텐츠가 없습니다.
2. 300번대: 리다이렉션 상태 코드
   • 추가적인 조치가 필요함을 나타냅니다.
   • 영구적인 리다이렉션
     • 301 Moved Permanently: 자원이 영구적으로 새로운 위치로 이동되었습니다.
     • 308 Permanent Redirect: 메서드가 잘못된 경우에도 영구 리다이렉션을 유지합니다.
   • 일시적인 리다이렉션
     • 302 Found: 자원이 임시로 다른 위치에 있습니다.
     • 303 See Other: 클라이언트는 다른 URL로 요청을 보내야 합니다.
     • 307 Temporary Redirect: 메서드를 유지한 채 일시적으로 리다이렉션됩니다.
3. 400번대: 클라이언트 에러 상태 코드
   • 요청이 잘못되었음을 나타냅니다.
   • 401 Unauthorized: 인증이 필요합니다.
   • 403 Forbidden: 권한이 없어 자원에 접근할 수 없습니다.
   • 404 Not Found: 요청한 자원이 존재하지 않습니다.
   • 405 Method Not Allowed: 지원되지 않는 메서드가 사용되었습니다.
4. 500번대: 서버 에러 상태 코드
   • 서버 내부에서 오류가 발생했음을 나타냅니다.
   • 502 Bad Gateway: 중간 서버 간 통신 오류가 발생했습니다.
   • 503 Service Unavailable: 서버가 과부하 상태이거나 점검 중입니다.

HTTP 발전 과정

1. HTTP/0.9
   • 초기 버전으로, GET 메서드만 지원하며 헤더가 없습니다. 기능과 성능이 매우 제한적입니다.
2. HTTP/1.0
   • HEAD와 POST 메서드가 추가되고 헤더가 도입되었습니다. 그러나 지속 연결을 지원하지 않아 매 요청마다 새로운 TCP 연결을 생성합니다.
3. HTTP/1.1
   • 지속 연결을 지원하여 하나의 TCP 연결에서 여러 요청을 처리할 수 있습니다. 파이프라이닝과 다양한 헤더 기능이 추가되어 효율성이 향상되었습니다.
4. HTTP/2.0
   • HTTP/1.1의 단점을 보완하기 위해 개발되었으며, 헤더 압축과 바이너리 프레이밍을 도입하여 전송 효율성을 높였습니다. 서버 푸시 기능을 통해 클라이언트 요청 없이도 자원을 전송할 수 있으며, 멀티플렉싱을 통해 블로킹 문제를 완화하였습니다.
5. HTTP/3.0
   • UDP 기반의 QUIC 프로토콜을 사용하여 더 빠르고 안정적인 전송을 목표로 합니다. TCP의 한계를 극복하고, 연결 설정 시간을 단축하며, 패킷 손실에 대한 복원력을 강화했습니다.

 

추가

• HTTP/1.1의 파이프라이닝:
  • 클라이언트가 여러 요청을 순차적으로 보내고, 서버가 이를 순서대로 응답하는 방식입니다. 그러나 실제 구현에서는 Head-of-Line 블로킹 문제로 인해 효율성이 제한적이었습니다.
• HTTP/2의 멀티플렉싱:
  • 하나의 TCP 연결에서 여러 요청과 응답을 동시에 처리할 수 있어, 지연 시간을 줄이고 네트워크 자원을 효율적으로 사용합니다.
• HTTP/3의 주요 개선점:
  • QUIC 프로토콜을 기반으로 하여, TCP의 연결 설정과 패킷 재전송에 따른 지연을 줄였습니다. 또한, 보안 기능이 강화되어 TLS가 기본으로 통합되었습니다.
• 보안 측면:
  • HTTP는 보안 프로토콜인 HTTPS와 함께 사용되어 데이터 전송 시 암호화를 제공합니다. 이는 데이터의 무결성과 기밀성을 보장합니다.
• 콘텐츠 협상(Content Negotiation):
  • 클라이언트가 원하는 미디어 타입을 서버에 전달하여, 서버는 적절한 형식의 응답을 제공할 수 있습니다. 이는 다양한 디바이스와 클라이언트 환경에 맞춘 유연한 서비스 제공을 가능하게 합니다.