HTTP(Hyper Text Transfer Protocol)

HTTP

출처

HTTP(Hyper Text Transfer Protocol)은 웹에서 데이터를 전송하기 위한 프로토콜 중 하나로 클라이언트와 서버 간의 통신을 위해 사용합니다. HTTP는 TCP/IP 프로토콜 위에서 동작하며 요청과 응답으로 구성됩니다(HTTP/3은 UDP 기반). 클라이언트가 웹 사이트의 URL에 액세스하거나 입력하면 브라우저는 웹에서 HTTP 요청을 생성하고 URL에 표시된 IP 주소로 보냅니다. 서버는 이 요청을 받고 관련 파일을 보냅니다. 또한 HTTP는 아래와 같은 거의 모든 형태의 데이터가 전송 가능합니다.

• HTML, TEXT
• IMAGE, 음성, 영상, 파일
• JSON, XML (API)

특징

Client-Server Architecture

출처

클라이언트-서버 아키택처는 컴퓨터 시스템이나 소프트웨어 애플리케이션의 설계 및 구조를 지칭하는 개념입니다. 네트워크 환경에서 컴퓨터 간의 역할 및 업무 분배를 명확하게 정의하여 시스템의 효율성과 확장성을 높이는데 중점을 두고 있습니다.

• 클라이언트(Client): 클라이언트는 사용자 또는 사용자가 사용하는 디바이스(컴퓨터, 스마트폰, 태블릿 등)가 되며 서버로부터 서비스나 리소스를 요청하고 응답을 받아서 사용자에게 제공합니다. 클라이언트는 사용자의 요구를 반영하여 서버에게 데이터 요청을 보내고 응답을 받아 표시하거나 처리합니다.
• 서버(Server): 서버는 클라이언트의 요청을 수신하고 해당하는 작업을 수행하여 클라이언트에게 필요한 데이터나 리소스를 제공합니다. 서버는 클라이언트의 요청에 따라 데이터 처리, 저장, 계산 등 다양한 역할을 수행합니다.
• 분리된 역활과 책임: 클라이언트와 서버는 역할과 책임을 명확하게 분리합니다. 클라이언트는 사용자와 상호작용하며 인터페이스를 제공하고 버는 데이터 관리와 처리를 담당합니다.
• 확장성과 유연성: 클라이언트와 서버는 각각이 분리되어 있기 때문에 상호간의 영향도가 적어 추가, 변경 작업이 일어나도 전체 시스템에 큰 영향을 미치지 않습니다.

Stateless

출처

무상태 프로토콜은 서버가 클라이언트의 상태(state)를 보존하지 않습니다. 각각의 요청과 응답이 서로 독립적이며 이전 요청과 응답과는 아무런 연관이 없다는 개념입니다. 즉 각각의 HTTP 요청은 그 자체로 하나의 독립적인 작업 단위이며 이전 요청과는 아무런 관련이 없이 해당 요청에 필요한 모든 정보를 함께 전송해야 합니다.

무상태 프로토콜은 서버가 클라이언트의 상태를 관리하지 않기 때문에 서버의 확장성이 높아집니다. 즉 여러 대의 서버로 분산 처리를 할 때 관리의 어려움이 줄어듭니다. 하지만 모든 요청에 필요한 정보를 함께 전송해야 하므로 데이터 양이 증가하기 때문에 요청 및 응답 시간을 증가시킬 수 있습니다.

Connectionless

HTTP는 클라이언트와 서버 간의 통신이 연결을 유지하지 않고 단일 요청과 응답으로 구성 되어 있습니다. 실제로 요청을 주고 받을 때만 연결을 유지하고 응답을 주고나면 맺은 연결을 끊음으로써 최소한의 자원으로 서버를 유지합니다.

하지만 HTTP의 비연결성은 다음과 같은 한계점을 가집니다.

• 모든 연결에 TCP/IP 연결을 새로 맺어야 합니다(3 way handshake).
• 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 JavaScript, CSS, 추가 이미지 등 수 많은 자원을 추가로 함께 요청해야 합니다.

위와 같은 이유로 HTTP는 버전 업 될 때마다 비연결성의 한계에 대한 최적화 작업을 진행했습니다. HTTP 지속 연결을 통해 최초 연결 시점에 연결 시간을 좀 더 유지함으로써 필요한 자원들을 모두 다운받을때까지 연결을 종료하지 않고 유지 후 종료합니다.

HTTP Status Code

HTTP 상태 코드(HTTP Status Code)는 서버가 클라이언트에게 전송하는 응답 메시지의 일부로 클라이언트에게 요청의 처리 상태를 전달하는데 사용됩니다. 상태 코드는 다음과 같은 범주로 나눌 수 있습니다:

• 1xx (Informational): 요청이 수신되었으며 처리가 진행 중인 상태를 나타냅니다.
• 2xx (Successful): 요청이 성공적으로 처리되었음을 나타냅니다.
• 3xx (Redirection): 요청을 완료하려면 추가 동작이 필요한 경우를 나타냅니다.
• 4xx (Client Error): 클라이언트의 요청이 잘못되었거나 처리할 수 없는 경우를 나타냅니다.
• 5xx (Server Error): 서버가 요청을 처리하는 동안 오류가 발생한 경우를 나타냅니다.

출처

HTTP Message

출처

HTTP Message는 클라이언트가 서버에 특정 동작을 기대하고 전송하는 메시지입니다. 프로토콜(protocol)은 컴퓨터 내부 또는 컴퓨터 사이에서 데이터의 교환 방식을 정의하는 규칙 체계로 HTTP 요청 및 응답에 다음과 같은 규약을 따릅니다.

HTTP Request

Start Line

시작 줄은 다음과 같이 세 가지 요소로 이루어져 있습니다.

1. HTTP Method: 서버가 수행해야 할 동작을 나타냅니다.
2. URL: 요청 대상의 경로를 표시합니다.
3. Version: 사용된 HTTP의 버전을 표시합니다.

Header

HTTP 헤더의 기본 구조를 따릅니다. 대소문자 구분없는 문자열 다음에 콜론(‘:’)이 붙으며 그 뒤에 오는 값은 헤더에 따라 달라집니다.

다양한 요청 헤더를 몇몇 그룹으로 다음과 같이 나눌 수 있습니다.

• General: Via와 같은 헤더는 메시지 전체에 적용됩니다.
• Request: User-Agent, Accept-Type과 같은 헤더는 요청의 내용을 좀 더 구체화 시키는 역활을 합니다.
• Entity: Content-Length와 같은 헤더는 요청 본문에 적용됩니다.

Main Text

본문은 모든 요청에 들어가지는 않지만 요청의 마지막 부분에 들어갑니다. GET, HEAD, DELETE , OPTIONS처럼 리소스를 가져오는 요청은 본문이 필요 없습니다.

본문은 두 가지 종류를 가집니다.

• 단일 리소스 본문(single-resource bodies): 헤더 두 개(Content-Type와 Content-Length)로 정의된 단일 파일로 구성됩니다.
• 다중 리소스 본문(multiple-resource bodies): 멀티파트 본문으로 구성되는 다중 리소스 본문에서는 파트마다 다른 정보를 지니게 됩니다. 보통 HTML 폼 (en-US)과 관련이 있습니다.

HTTP Response

Status Line

HTTP 응답의 시작 줄은 상태 줄(status line) 이라고 불리며 다음과 같은 정보를 가지고 있습니다.

1. Version: 사용된 HTTP의 버전을 표시합니다.
2. Status Code: 요청의 상태 코드를 표시합니다.
3. Status Text: 상태 코드에 대한 설명을 글로 표시합니다.

Header

HTTP 응답 헤더는 HTTP 요청 헤더와 동일한 구조를 따릅니다.

다양한 응답 헤더를 몇몇 그룹으로 다음과 같이 나눌 수 있습니다.

• General: Via와 같은 헤더는 메시지 전체에 적용됩니다.
• Response: Vary와 Accept-Ranges와 같은 헤더는 상태 줄에 미처 들어가지 못했던 서버에 대한 추가 정보를 제공합니다.
• Entity: Content-Length와 같은 헤더는 요청 본문에 적용됩니다.

Main Text

본문은 모든 응답 들어가지는 않지만 응답의 마지막 부분에 들어갑니다.

• 이미 길이가 알려진 단일 파일로 구성된 단일-리소스 본문: 헤더 두개(Content-Type와 Content-Length)로 정의 합니다.
• 길이를 모르는 단일 파일로 구성된 단일-리소스 본문: Transfer-Encoding가 chunked로 설정되어 있으며 파일은 청크로 나뉘어 인코딩 되어 있습니다.
• 서로 다른 정보를 담고 있는 멀티파트로 이루어진 다중 리소스 본문

HTTP Method

출처

HTTP 메소드(HTTP Methods)는 클라이언트가 서버에게 어떤 동작을 수행하길 원하는지를 나타내는 방식입니다. 각 메소드는 특정한 의미와 목적을 가지며 서버는 클라이언트의 요청 메소드에 따라 해당하는 동작을 수행합니다.

HTTP에서 제공하는 각 메소드들의 특징은 다음과 같습니다.

• GET: 서버로부터 리소스를 조회하기 위해 사용됩니다.
• POST: 서버로 데이터를 전송하여 리소스를 생성하거나 업데이트하기 위해 사용됩니다.
• PUT: 서버로 데이터를 전송하여 특정 리소스를 생성하거나 갱신하는데 사용됩니다.
• DELETE: 서버로 리소스 삭제를 요청할 때 사용됩니다.
• HEAD: GET 메소드와 유사하지만 버는 실제 리소스를 반환하지 않고 응답 헤더만을 반환합니다. 클라이언트는 리소스의 메타 정보를 확인하거나 존재 여부를 확인하는 용도로 사용합니다.
• OPTIONS: 서버가 지원하는 HTTP 메소드의 종류를 확인하기 위해 사용됩니다. 이 메소드에 대한 응답으로 Allow 헤더를 포함하여 지원하는 메소드를 클라이언트에게 알려줍니다. 또한 특정 도메인으로부터의 요청 허용 여부를 판단하는데 사용됩니다.
• TRACE: 클라이언트가 서버에게 자신의 요청을 다시 돌려받기 위해 사용됩니다. 서버는 TRACE 요청을 받으면 요청 헤더와 본문을 그대로 응답으로 돌려줍니다. 하지만 보안 이슈를 유발할 수 있으므로 실제 서버에서는 비활성화시키는 것이 일반적입니다.

멱등성(Idempotence)

출처

멱등성이란 동일한 요청을 여러 번 보내더라도 항상 같은 결과가 반환되는 성질을 의미합니다. 즉 멱등성을 가진 메서드는 여러 번의 동일한 요청이 서버의 상태나 리소스에 변화를 주지 않는 것을 보장합니다.
다음은 명등성을 가지는 HTTP 메소드들의 목록입니다.

1. GET: 서버의 상태나 데이터를 변경하지 않고 리소스 정보를 요청합니다.
2. PUT: 리소스를 생성하거나 갱신하는 역할을 합니다. 여러 번 청을 보내더라도 결과는 동일합니다.
3. DELETE: 리소스를 삭제하는 역할을 합니다. 여러 번 청을 보내더라도 결과는 동일합니다.
4. HEAD: 실제 데이터가 아닌 헤더만을 반환합니다. GET과 동일한 정보를 가져오므로 멱등성을 가집니다.

역사

출처

HTTP/0.9

HTTP의 첫 번째 버전으로 1991년에 출시되었으며 현재 버전의 기능에 비해 대단히 제한적입니다. 첫 번째 버전에는 이름조차 없었고 후에 HTTP/0.9로 불렸으며 가장 간단한 형태의 프로토콜입니다.

• 단선 포털(The one-line portal): 직접 리소스 호출만 가능합니다.
• 단일 메소드(Single Method): GET 메소드만 지원합니다.
• 오류 코드 및 헤더의 부재(Absence of Error Code and Header)

요청/응답 예

GET /index.html HTTP/0.9

<html> 
This is the content of the index.html document. 
</html> 

HTTP/1.0

HTTP/1.0은 1996년에 도입됐으며 인터넷의 사용 용도가 통계/문서 웹 사이트에서 동적/콘텐츠 기반 웹사이트로 확장됨에 따라 해당 요구 사항에 맞게 버전 업 됐습니다.

• 헤더(Header): Content-Type, 캐싱 및 인증, 파일 유형과 같은 다양한 내용을 담을 수 있는 헤더가 추가되었습니다. 또한 Content-Type 헤더를 통해 여러 유형의 데이터(미디어, 스크립트 등)을 전송할 수 있습니다.
• 상태 코드(Status Code): 요청에 대한 상태를 나타내는 상태 코드가 추가 됐습니다.
• 메소드(Method): GET 메소드 외 POST, DELETE, PUT, HEAD … 와 같은 새로운 메소드가 추가 됐습니다.

요청/응답 예

GET /image.jpg HTTP/1.0

Host: www.example.com 

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) 

HTTP/1.0 200 OK 

Date: Mon, 18 July 2023 12:00:00 GMT 

Server: Apache/2.4.6 (Ubuntu) 

Content-Type: image/jpeg 

Content-Length: 5000 

<Binary data representing the image> 

HTTP/1.1

HTTP 1.1은 1999년에 발표된 버전으로 HTTP/1.0 출시와 병행하여 개발 됐습니다. HTTP의 표준화를 목표로 HTTP/1.0의 모호함을 명확히 정의하며 제시한 현재 가장 널리 사용되는 버전 중 하나입니다.

• 지속 연결(Persistent Connection) : 지정한 Timeout동안 연결을 재사용하여 단일 TCP 연결 내에서 여러 요청을 실행할 수 있습니다.
• 호스트 헤더(Host Header): 서버가 동일한 IP 주소를 사용하여 여러 도메인 이름을 처리할 수 있도록 요청에 호스트 헤더를 포함합니다. 단일 서버에서 여러 웹 사이트를 쉽게 호스팅할 수 있습니다.
• 파이프라이닝(Pipelining): 하나의 커넥션에서 응답을 기다리지 않고 여러 요청을 연속적으로 보내 그 순서에 맞춰 응답을 받는 방식으로 지연 시간을 줄이는 방식입니다. Head of Line Blocking과 같은 문제로 사장됐습니다.
• Head Of Line Blocking: 첫 번째 패킷에 의해 대기열에서 패킷 라인이 보류될 때 발생하는 성능 제한 현상입니다.

요청/응답 예

HTTP/1.1 200 OK
Date: Mon, 09 Aug 2023 10:00:00 GMT
Server: Apache/2.4.18 (Ubuntu)
Content-Length: 1234
Content-Type: text/html; charset=UTF-8

<!DOCTYPE html>
<html>
<head>
    <title>Welcome to Example.com</title>
</head>
<body>
    <h1>Hello, World!</h1>
    <p>This is the main page of Example.com.</p>
</body>
</html>

HTTP/2.0

HTTP/2.0은 2015년에 발표된 버전으로 HTTP/1.1의 성능 문제와 함께 사용자 경험을 개선하기 위한 목적으로 개발되었습니다. HTTP/1.1의 성능 개선용으로 개발되었기 때문에 기본적으로 HTTP/1.1와 유사하나 몇 가지 기능이 추가 됐습니다.

• 다중화(Multiplexing): HTTP/2는 HOL(Headline Of Line) 이슈를 해결하고 여러 요청을 한 연결로 처리함으로써 네트워크 사용량을 줄이고 응답 시간을 개선했습니다.
• 헤더 압축(Header Compression): HTTP 요청을 보낼 때 중복된 헤더 필드를 압축하여 전송합니다.
• 바이너리 프레이밍(Binary Framing Layer): 텍스트 기반 프로토콜 대신 바이너리 프레임 형식을 사용하여 데이터를 전송합니다.
• 서버 푸시(Server Push): 서버가 클라이언트의 요청 없이도 필요한 리소스를 미리 보내는 기능을 제공합니다. 추가적으로 필요한 리소스를 미리 전송합니다.
• 스트림 우선 순위(Stream Prioritization): 각 요청에 우선 순위를 부여하여 중요한 리소스에 대한 처리를 더 높은 우선 순위로 처리합니다.

위와 같은 특징들로 인해 기존 HTTP/1.1보다 웹 페이지 로딩 속도를 향상시키고 동시에 더 많은 요청을 처리하며 불필요한 리소스 다운로드를 최소화하여 전반적인 웹 애플리케이션의 성능을 향상시켰습니다.

요청/응답 예

HTTP/2.0의 요청 & 응답은 여러 개의 프레임으로 구성되며 각 프레임에는 헤더와 데이터가 함께 포함됩니다. 헤더 프레임은 요청 & 응답의 메타 데이터가, 데이터 프레임은 요청 & 응답 본문 데이터가 들어갑니다. 실제로 바이너리로 구성된 프레임을 직접 작성하는 것은 복잡하기 때문에 Binary Framing Layer 이미지로 대체하겠습니다.

출처

HTTP/3

HTTP/3은 2020년에 발표된 버전으로 기존의 TCP를 대체하는 UDP 기반의 QUIC(Quick UDP Internet Connections) 프로토콜 위에서 동작합니다. UDP 기반의 전송으로 인해 기존 TCP 기반 통신의 고질적인 지연 시간 문제를 더 낮은 지연 시간과 더 나은 성능을 제공합니다.

오탈자 및 오류 내용을 댓글 또는 메일로 알려주시면, 검토 후 조치하겠습니다.