HTTP(Hypertext Transfer Protocol)란?

HTTP(Hypertext Transfer Protocol)는 월드 와이드 웹(WWW)에서 사용되는 주요 통신 프로토콜이다. 클라이언트(주로 웹 브라우저)와 서버 간에 데이터를 주고받는 규칙을 정의한다.

➡ Protocol(프로토콜)이란?
프로토콜이란 컴퓨터 네트워크에서 데이터 통신을 위해 정해진 규칙이다. 이는 서로 다른 시스템 간에 데이터를 정확하고 효율적으로 주고받을 수 있도록 한다.
➡ 월드 와이드 웹이란?
월드 와이드 웹(WWW)이란 웹 페이지를 네트워크 상에서 이용하기 위한 구조를 말한다.

HTTP는 TCP/IP 프로토콜 위에서 작동한다. 따라서, 웹 서버와 웹 클라이언트는 IP 주소를 통해 서로 통신할 수 있게 된다. 즉, 우리가 웹을 이용하려면 웹 서버와 웹 클라이언트는 각각 고유한 IP 주소를 가져야 한다.

HTTP는 그 이름처럼 하이퍼텍스트만 전송할 수 있을 것 같지만, 실제로는 HTML이나 XML과 같은 하이퍼텍스트뿐 아니라 이미지, 오디오, 비디오, JavaScript, PDF 및 기타 다양한 문서 파일 등 컴퓨터에서 다룰 수 있는 모든 형태의 데이터를 전송할 수 있다.

---

1. HTTP의 특징

1) 클라이언트-서버 모델 (Client-Server Model)

HTTP는 클라이언트-서버 모델을 기반으로 작동한다. 예를 들어, 사용자가 웹 브라우저에서 https://www.example.com을 입력하면 브라우저(클라이언트)는 웹 서버에 요청(Request)을 보내고, 웹 서버는 해당 요청을 처리한 후 웹 페이지를 응답(Response)으로 보낸다.

2) 비연결성 (Connectionless)

HTTP는 비연결성 프로토콜이다. 예를 들어, 사용자가 웹 페이지에서 링크를 클릭하면 브라우저가 서버에 요청을 보내고, 응답을 받으면 연결이 끊어진다. 이후 사용자가 다른 링크를 클릭하면 새로운 요청이 생성되고, 또다시 서버와의 연결이 끊어진다.

왜 비연결성 모델인가?
비연결성 모델의 반대는 Connection Oriented(연결을 유지하는) 모델이다. TCP/IP는 기본적으로 연결을 유지하는 모델이다. 이 경우, 클라이언트가 요청을 보내지 않더라도 연결은 계속 유지되고, 연결을 유지하는 서버의 자원이 지속적으로 소모된다.

• Connection Oriented 모델
  

• Connectionless 모델
  

비연결성 모델을 사용할 경우 서버 자원을 매우 효율적으로 사용할 수 있다는 장점이 있지만, 그에 따른 한계가 있다. 아래의 내용을 살펴보자.

• HTTP/1.0 - 비지속 연결 (Non-Persistent Connection)
  
  HTTP/1.0에서는 비지속 연결을 사용하는데, 이는 하나의 요청-응답 사이클이 끝나면 서버와의 연결이 즉시 끊어지는 방식이다. 이러한 방식은 매 요청마다 새로운 연결(TCP handshake)을 설정해야 하므로, 네트워크 자원과 시간이 많이 소모되는 단점이 있다. 특히, 웹 페이지를 구성하는 여러 요소(이미지, CSS 파일 등)를 각각 요청할 때마다 새로운 연결을 설정해야 하므로 성능이 저하된다.

• HTTP/1.1 - 지속 연결 (Persistent Connection)
  
  HTTP/1.1에서는 지속 연결이 도입되었다. 이는 한 번 연결이 설정되면, 여러 요청과 응답을 그 연결을 통해 연속적으로 처리할 수 있는 방식이다. 연결을 유지함으로써, 여러 리소스를 요청할 때마다 새로운 연결을 설정할 필요가 없어 네트워크 자원을 절약하고 성능을 향상시킬 수 있다. HTTP/2(멀티플렉싱 사용)와 HTTP/3(QUIC 사용)는 HTTP/1.1의 지속 연결 방식을 한층 개선하여 성능을 더욱 향상시켰다.

지속 연결을 사용하더라도 HTTP의 기본적인 비연결성 특징이 사라지는 것은 아니다. 지속 연결은 하나의 TCP 연결을 통해 여러 개의 HTTP 요청과 응답을 처리할 수 있게 해주는 것으로, "어느 정도까지 기다린 후 연결을 끊는 것"으로 이해할 수 있다.

3) 무상태성 (Stateless)

HTTP는 무상태성 프로토콜로, 각 요청은 독립적이며, 이전 요청과의 관계를 유지하지 않는다. 따라서 서버는 각 요청을 별도로 처리하고, 상태 정보를 저장하지 않는다. 상태 유지를 위해 쿠키(Cookie)나 세션(Session)과 같은 방법을 사용해야 한다.

만약 콜센터에 문의를 할 경우, 현재 대기 중인 상담원(서버) 중 1명과 대화를 하게 된다. 전화를 종료한 후, 다시 콜센터에 전화를 걸 경우 보통 다른 상담원이 전화를 받고, 문의 내용을 처음부터 다시 설명해야 한다. 이것이 HTTP의 무상태성이다.

콜센터 직원은 비유일 뿐, 만약 정말 우연히 같은 서버로 요청을 보내더라도 상태를 기억하지 못하는 것은 같다. 왜? 각 요청은 서로 독립적이니까!

그러면 HTTP가 무상태성인 이유와, 그 장점은 무엇일까?

• 서버 부담 경감
  서버가 이전 요청의 상태를 기억하거나 관리할 필요가 없다. 이로 인해 서버는 메모리와 리소스를 절약할 수 있으며, 모든 요청을 간단한 방식으로 처리할 수 있다.

• 서버 장애 대처
  하나의 서버가 장애를 겪더라도 다른 서버로의 전환이 용이하다. 서버가 요청의 상태를 저장하지 않기 때문에, 클라이언트는 어떤 서버에 요청을 보내든 상관없이 동일한 응답을 받을 수 있다.

• 서버 확장성
  서버를 쉽게 추가하여 확장할 수 있다. 각 서버는 독립적으로 요청을 처리하기에 새로운 서버를 추가하는 것이 간단하다. 이를 통해 서버를 수평으로 확장(Scale out)하기 수월하고, 대규모 애플리케이션에서 유용하다.

수평 확장(Scale out) vs 수직 확장(Scale up)

수직 확장(Scale up)은 단일 서버의 스펙을 더 좋은 것으로 업그레이드 하는 것이고, 수평 확장(Scale out)은 서버의 수를 늘리는 것이다.

실제로 웹사이트를 이용할 때, 대부분 페이지를 이동하더라도 로그인 정보가 유지된다. 이는 쿠키(Cookie), 세션(Session), 토큰(Token) 등을 통해 상태를 유지하는 것이다.

---

2. HTTP 메시지

1) Request

📌 start line

HTTP Request Message의 시작 라인이며, 세 가지 주요 부분으로 구성된다.

• Method
  HTTP 동작을 정의하는 키워드이다. GET, POST, PUT, DELETE

• URL
  요청할 리소스의 주소이다. /test.html

• HTTP 버전
  사용하고 있는 HTTP 프로토콜의 버전이다. HTTP/1.1

📌 headers (주요 헤더)

HTTP Request에서 헤더(Header)는 요청에 대한 추가 정보(addtional information)를 포함하며, 서버에 요청의 상세 정보나 클라이언트의 환경을 전달하는 키-값 쌍의 정보를 제공한다. 다양한 헤더 중, 주로 사용되는 헤더를 정리하면 아래와 같다.

• Host
  설명: 요청하는 호스트의 도메인 이름과 포트를 지정한다.
  형식: Host: example.com
  용도: 서버가 여러 도메인을 호스팅하는 경우, 어떤 도메인으로 요청이 들어왔는지 식별한다.

• User-Agent
  설명: 요청을 보낸 클라이언트 애플리케이션의 이름과 버전을 포함한다.
  형식: User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36
  용도: 서버가 클라이언트의 브라우저 또는 애플리케이션을 식별하고, 이를 기반으로 응답을 최적화할 수 있다.

• Accept
  설명: 클라이언트가 수용할 수 있는 콘텐츠의 MIME 타입을 지정한다.
  형식: Accept: text/html, application/xhtml+xml, application/xml;q=0.9, */*;q=0.8
  용도: 서버가 클라이언트가 요청한 콘텐츠 형식을 지원하는지 여부를 확인하는 데 사용된다.

• Accept-Encoding
  설명: 클라이언트가 지원하는 콘텐츠 인코딩 방식(압축 방법)을 지정한다.
  형식: Accept-Encoding: gzip, deflate, br
  용도: 서버가 클라이언트의 요구에 맞는 콘텐츠 압축 방식으로 응답을 제공할 수 있다.

• Accept-Language
  설명: 클라이언트가 선호하는 언어를 지정한다.
  형식: Accept-Language: en-US,en;q=0.9,fr;q=0.8
  용도: 서버가 클라이언트의 언어 선호에 맞춰 콘텐츠를 제공할 수 있다.

• Authorization
  설명: 인증 정보를 서버에 제공한다.
  형식:Authorization: Bearer <token>
  용도: 서버가 클라이언트의 인증을 확인하여 보호된 리소스에 접근할 수 있게 한다.

• Content-Type
  설명: 요청 본문의 콘텐츠 유형을 지정한다.
  형식: Content-Type: application/json
  용도: 서버가 요청 본문을 올바르게 해석할 수 있도록 도와준다. 예를 들어, JSON 데이터의 경우 application/json을 사용한다.

• Content-Length
  설명: 요청 본문의 길이를 바이트 단위로 표현한다.
  형식: Content-Length: 348
  용도: 서버가 요청 본문의 크기를 알고, 이를 올바르게 처리할 수 있도록 한다.

• Connection
  설명: 현재 요청/응답 후 연결을 유지할지 종료할지를 지정합니다.
  형식: Connection: keep-alive 또는 Connection: close
  용도: keep-alive를 사용하면 연결을 유지하고, close를 사용하면 요청/응답 후 연결을 종료한다. (앞서 설명한 지속 연결이 keep-alive를 사용한다.)

• Referer
  설명: 현재 요청이 유입된(바로 직전에 머물렀던) 페이지의 URL을 제공한다.
  형식: Referer: https://www.example.com/page.html
  용도: 서버가 요청의 출처를 추적하거나 분석할 수 있다.

• Cookie
  설명: 클라이언트의 쿠키 값을 전달한다.
  형식: Cookie: sessionId=abc123; theme=light
  용도: 서버가 클라이언트의 세션 상태나 사용자 설정을 추적하는 데 사용된다.

• Origin
  설명: 요청이 발생한 출처(Origin)를 나타낸다.
  형식: Origin: <scheme>://<host>:<port>
  용도: CORS(Cross-Origin Resource Sharing) 요청 시, 클라이언트가 요청을 보낸 출처를 서버에 전달한다. (출처가 다를 경우, CORS 에러 발생 가능)
  

📌 body

HTTP 요청에서 본문(Body)은 클라이언트가 서버에 전달하고자 하는 실제 데이터로, 주로 POST, PUT 요청에서 사용되며, 요청의 목적에 따라 폼 데이터, JSON, XML, 파일 등 다양한 형태일 수 있다.

예를 들면, 로그인 요청에서 HTTP 본문(Body)은 클라이언트가 서버에 사용자 인증 정보를 전달하는 데이터 부분으로, 보통 POST 메서드를 사용한다. 본문에 username=example&password=123456와 같은 폼 데이터가 포함되어 서버가 이를 기반으로 사용자를 인증하고 로그인 처리를 진행한다.

2) Response

📌 status line

HTTP 응답 메시지의 Status Line은 응답의 상태를 간략하게 나타내며, 세 가지 주요 부분으로 구성된다.

• HTTP version
  사용된 HTTP 프로토콜의 버전을 명시한다. HTTP/1.1
• Status Code
  요청 처리 결과를 나타내는 3자리 숫자 코드이다. 200
• Status Tex
  상태 코드를 이해할 수 있도록 설명하는 짧은 메시지이다. OK

📌 headers

Request 헤더와 동일한 구조를 가지되, 특정 부분에서 구분되는 header 값들이 있다.

예를 들어, Request 헤더는 User-Agent 헤더를 통해 클라이언트 애플리케이션(웹 브라우저, 모바일 앱 등)의 정보를 포함하고, Response 헤더는 Server 헤더를 통해 아래와 같은 형식으로 서버 소프트웨어에 대한 정보를 포함한다.

Server: Apache/2.4.41 (Ubuntu)

📌 body

서버가 클라이언트에게 전달하는 실제 데이터로, 요청의 결과를 포함한다. 응답 본문은 HTML, JSON, XML, 이미지 파일 등 다양한 형태일 수 있다. Request와 마찬가지로 모든 Response가 body가 있지는 않으며, 응답 데이터가 필요한 경우에만 body가 존재한다.

예를 들어, 요청이 성공적으로 처리되었으나 서버가 추가적인 데이터 제공이 필요 없는 경우 body가 비어 있고, 아래와 같이 상태 코드만 전달될 수 있다.

HTTP/1.1 200 OK

---

마치며

다음 글에서는 HTTP 상태 코드에 대한 정리를 해볼 예정이다.