HTTP 기본과 특징 알아둬야 할 모든 것

HTTP란 무엇인가?

HTTP(Hypertext Transfer Protocol)는 인터넷에서 웹 브라우저와 웹 서버가 서로 통신하기 위해 사용하는 프로토콜입니다.

• Hypertext: HTML, XML, JSON 등 하이퍼텍스트(혹은 하이퍼미디어) 형식의 문서를 주고받을 수 있다는 의미입니다.
• Transfer: 클라이언트와 서버 간 데이터를 전송한다는 의미입니다.
• Protocol: 통신 규약으로, 클라이언트와 서버 간 어떤 규칙으로 메시지를 교환할지 정해놓은 것입니다.

현재 우리가 알고 있는 웹(Web)이 동작하는 가장 기본적인 요소가 HTTP이며, 브라우저가 서버에 ‘문서(페이지나 리소스)’를 요청하면 서버가 응답하는 구조를 형성합니다.

HTTP의 역사

1. 탄생 배경

• 1990년대 초반: 팀 버너스-리(Tim Berners-Lee)가 제안한 월드 와이드 웹(WWW)과 함께 최초로 제안된 프로토콜이 HTTP였습니다.
• HTTP 0.9(1991년 제안): 가장 간단한 형태로, GET 요청만 있었고, 응답은 HTML 문서 하나로 한정되었습니다.

2. 주요 버전 변천사

1. HTTP/0.9
   • 텍스트만 전송 가능, 헤더 개념이 부재하여 매우 간단했음.
2. HTTP/1.0(1996년)
   • 요청과 응답에 헤더가 추가되면서 확장성이 높아졌음.
   • 하지만 TCP 연결을 매번 새로 맺는 구조이므로 비효율성이 존재.
3. HTTP/1.1(1997년, RFC 2068 이후)
   • 현재도 널리 사용되는 표준 버전.
   • Persistent Connection(Keep-Alive) 지원으로 여러 개의 요청을 하나의 TCP 연결로 처리 가능.
   • Chunked Transfer Encoding 지원, 호스트 헤더 필드 도입 등 기능 확장.
4. HTTP/2(2015년, RFC 7540)
   • SPDY 프로토콜을 기반으로 만들어짐.
   • 멀티플렉싱 지원으로 하나의 연결에서 여러 메시지를 동시 전송 가능.
   • 헤더 압축, 서버 푸시 등 성능 개선.
5. HTTP/3(2022년, RFC 9114)
   • QUIC 프로토콜(UDP 기반)을 사용하는 차세대 HTTP.
   • 커넥션 핸드셰이크 지연을 줄이고, 패킷 손실에 덜 민감하도록 설계.

이렇듯 HTTP는 웹의 발전과 함께 점진적으로 개선되어, 속도와 보안, 그리고 확장성을 지속적으로 높여 왔습니다.

HTTP의 주요 특징

1. 클라이언트-서버 구조
   • 클라이언트(브라우저)와 서버(웹 서버) 간 통신을 주고받는 구조.
   • 클라이언트가 요청(Request)을 보내고 서버가 응답(Response)을 하는 형태.
2. Stateless(무상태)
   • 요청 간 상태 정보를 보존하지 않음. 즉, 이전 요청과 다음 요청은 서로 독립적.
   • 이로 인해 서버는 매 요청마다 클라이언트 정보를 다시 확인해야 함.
   • 상태 유지를 위해 쿠키(Cookie)나 세션(Session), 토큰(Token) 등을 별도로 활용.
3. HTTP는 애플리케이션 레벨 프로토콜
   • OSI 7계층 중 애플리케이션 계층에 해당.
   • TCP/IP(전송 계층)를 기반으로 하며, SSL/TLS와 결합하여 HTTPS로 보안을 강화할 수 있음.
4. 확장성
   • 헤더를 통해 다양한 정보를 주고받을 수 있어 확장성이 높음.
   • 메서드나 헤더, 상태코드 등이 비교적 간단하면서도 유연함.
5. URI(Uniform Resource Identifier)를 통한 리소스 식별
   • HTTP는 URL/URI를 이용해 웹 상에 존재하는 리소스(문서, 이미지, 동영상 등)를 식별하고 접근.

이 모든 특징은 초기부터 단순함을 유지하면서도 확장성을 고려한 HTTP의 디자인 철학을 잘 보여줍니다.

HTTP 메시지 구조

HTTP는 크게 요청(Request)과 응답(Response) 두 가지 메시지로 구분됩니다.

1. 요청(Request) 메시지

1. 시작줄(Request Line)
   • 메서드(Method), 요청 대상(URI), 그리고 프로토콜 버전(예: HTTP/1.1)을 표시.
   • 예: GET /index.html HTTP/1.1
2. 헤더(Header)
   • 요청에 대한 부가 정보를 담는 영역.
   • 예: Host, User-Agent, Accept, Cookie 등.
3. 공백 줄(빈 줄)
   • 헤더와 바디를 구분하기 위한 줄.
4. 바디(Body)
   • 실제 전송할 데이터가 포함되는 영역(주로 POST, PUT 등에서 사용).

2. 응답(Response) 메시지

1. 시작줄(Status Line)
   • 프로토콜 버전, 상태 코드(Status Code), 그리고 상태 텍스트(Reason Phrase).
   • 예: HTTP/1.1 200 OK
2. 헤더(Header)
   • 서버와 응답에 대한 정보를 담음.
   • 예: Content-Type, Content-Length, Set-Cookie 등.
3. 공백 줄(빈 줄)
   • 헤더와 바디를 구분.
4. 바디(Body)
   • 실제 전송되는 응답 데이터. HTML, JSON, 파일, 이미지 등 다양한 형태 가능.

HTTP 메서드의 종류와 용도

HTTP는 여러 가지 메서드를 통해 서버에게 ‘어떤 작업’을 할지를 알립니다.

1. GET
   • 리소스를 요청하여 가져올 때 사용.
   • 대부분 웹 브라우저에서 페이지 접속 시 사용.
   • 보통 요청 바디가 없고, 요청 파라미터는 URL에 쿼리 문자열로 포함되기도 함.
2. POST
   • 서버에 데이터를 전송하여 새로운 리소스를 생성하거나 처리를 요청할 때 사용.
   • 예: 회원가입 폼 전송, 게시글 작성.
3. PUT
   • 서버에 해당 리소스를 생성하거나 완전히 대체할 때 사용.
   • 리소스가 존재하면 내용이 대체(갱신), 존재하지 않으면 새로 생성.
4. DELETE
   • 리소스를 삭제할 때 사용.
   • 예: 게시글 삭제, 파일 삭제.
5. HEAD
   • GET과 동일하지만, 메시지 바디 없이 헤더만 요청.
   • 리소스의 존재 여부 및 헤더 정보를 확인할 때 유용.
6. OPTIONS
   • 특정 리소스가 지원하는 메서드와 옵션을 확인할 때 사용.
   • CORS(Cross-Origin Resource Sharing) 처리 시 사전 요청(Preflight Request)으로 자주 활용.
7. PATCH
   • 리소스의 일부를 수정할 때 사용.
   • PUT과 달리 전체가 아니라 부분 수정에 활용.
8. TRACE
   • 클라이언트와 서버 간 통신 경로를 추적할 때 사용.
   • 디버깅 목적으로 사용되지만, 보안상 꺼두는 경우가 많음.

이 메서드들의 정확한 사용 목적을 구분해 사용하면 RESTful API 설계 시 명확성과 일관성을 높일 수 있습니다.

HTTP의 장점

1. 단순하고 직관적인 구조
   • 텍스트 기반 포맷이어서 사람이 이해하고 디버깅하기 쉽습니다.
   • 시작줄, 헤더, 바디라는 간단한 구조로 되어 있어 확장에도 유리합니다.
2. 프로토콜 확장 용이
   • HTTP 헤더를 통해 원하는 정보를 추가하거나 사용자 정의 헤더를 만들 수 있습니다.
   • 새로운 버전(HTTP/2, HTTP/3)에서는 하위 호환성을 어느 정도 유지하며 성능을 개선.
3. 폭넓은 호환성과 범용성
   • TCP 위에서 동작하기 때문에 기기나 플랫폼에 구애받지 않습니다.
   • 전 세계 모든 웹 시스템이 사용하는 표준 인터페이스입니다.
4. RESTful API 설계의 기반
   • GET/POST/PUT/DELETE 같은 메서드를 이용해 리소스를 조작하는 API를 설계할 수 있습니다.
   • 클라이언트-서버 모델에서 분산 시스템을 안정적으로 구성하기에 적합합니다.

현재의 HTTP

1. HTTP/1.1 여전히 주요 표준

• 인터넷 상 많은 웹서버와 클라이언트에서 기본적으로 동작.
• Keep-Alive 덕분에 HTTP/1.0의 비효율성을 크게 줄임.

2. HTTP/2와 점차 늘어나는 사용

• 주요 클라우드 서비스, CDN 등에서 HTTP/2를 적극 채택.
• 멀티플렉싱, 서버 푸시로 성능 개선.

3. HTTPS 보편화

• 보안에 대한 요구가 커지면서, 대부분의 웹사이트가 SSL/TLS를 적용해 HTTPS로 전환.
• HTTPS는 사실 HTTP 프로토콜을 SSL/TLS로 감싸 암호화·무결성을 제공하는 것.

4. 모바일 환경, IoT에서의 사용 확대

• HTTP는 단순함과 범용성 덕분에 모바일 앱·IoT 기기에서도 주고받기 편리.
• 실시간·대용량 데이터 송수신이 필요한 경우 웹소켓이나 HTTP/2, HTTP/3 등을 결합.

HTTP의 미래

1. HTTP/3 (QUIC 기반)
   • TCP가 아닌 UDP 위에서 동작하는 QUIC 프로토콜을 사용.
   • TCP의 연결 설정 과정(핸드셰이크)에 따른 지연과 패킷 손실 문제를 개선.
   • 이미 여러 브라우저(Chrome, Firefox 등)와 서버(NGINX, Cloudflare 등)에서 지원이 확산 중.
2. 진화 방향
   • 더 빠른 연결: 지연 시간을 단축하고 멀티플렉싱을 안정적으로 처리.
   • 보안 강화: TLS는 기본, 식별 가능한 정보 최소화.
   • 지속적 확장성: 헤더 압축, 세분화된 흐름 제어 등으로 성능 개선.
   • 범용성 유지: 기존 HTTP 리소스를 그대로 사용할 수 있도록 하위 호환.
3. WebTransport, WebSocket 등 다른 프로토콜과의 조합도 가능
   • 웹 애플리케이션 성능을 높이는 여러 프로토콜이 제안되고 있으며, HTTP 기반 환경과 상호 보완.

앞으로 HTTP/3가 점차 확대됨에 따라 빠른 연결, 안정된 전송, 향상된 보안이 보편화될 것으로 전망합니다.

결론

• HTTP: 웹 클라이언트(브라우저)와 서버 간 통신을 위한 핵심 프로토콜로, 현재 웹 동작의 근간입니다.
• 역사: 1990년대 초반 단순 텍스트 전송용 HTTP/0.9에서 시작해, HTTP/1.1이 오랜 기간 웹 표준 역할을 해왔으며, HTTP/2를 거쳐 HTTP/3(QUIC 기반)로 진화 중입니다.
• 특징: 무상태(Stateless) 프로토콜, 요청과 응답의 구조, 텍스트 기반 확장성, 보안(HTTPS) 적용 가능 등.
• 메시지 구조: 요청(Request)와 응답(Response)은 시작줄, 헤더, 공백 줄, 바디로 구분되며 간단하고 직관적입니다.
• 메서드 종류: GET, POST, PUT, DELETE, PATCH 등 다양한 메서드를 통해 RESTful API를 구축하고 명확한 통신 로직을 확립할 수 있습니다.
• 장점: 단순함, 확장성, 범용성, RESTful 기반 지원 등.
• 현재: HTTP/1.1이 주요 표준이지만 HTTP/2 adoption이 늘어나고, HTTPS가 보편화되었으며 모바일·IoT에서도 활발히 사용됩니다.
• 미래: HTTP/3를 통해 더 빠른 연결, 보안 강화, 패킷 손실 방지 등 추가적인 성능 개선을 기대합니다.

HTTP는 인터넷이 존재하는 한 끊임없이 개선되고 발전하며, 다양한 서비스 및 기술과 결합하여 계속해서 웹의 표준 프로토콜 자리를 지킬 것입니다. 이렇게 발전해온 HTTP의 여정과 특징을 이해한다면, 웹 개발을 할 때 더욱 효율적이고 안전한 서비스를 설계하고 구현할 수 있을 것입니다.