HTTP란 무엇인가?

1. HTTP란?

  Hyper Text Transfer Protocol의 약자로, TCP/IP를 기반으로 하여 Application 계층에서 네트워크로 연결된 기기간(클라이언트와 서버) 정보(HTML과 같은 리소스)를 주고 받기 위한 프로토콜로 WWW(World Wide Web)의 기반이 됩니다. TCP/IP 기반이기 때문에 보통 TCP 80포트를 쓰지만 다른 포트도 사용 가능하며, HTTPS에서는 443포트가 기본입니다.

 

  HTTP의 전반적인 흐름은 TCP 연결을 설정한 후, 클라이언트가 서버에게 요청을 보내고, 서버가 클라이언트에게 해당 요청에 대한 응답을 하는 것입니다. 클라이언트(보통 웹브라우저)가 보내는 메시지는 Request(요청), 서버가 그에 대한 답으로 보내는 메시지를 Response(응답)이라고 합니다. 예를 들어 브라우저가 한 웹 페이지를 사용자에게 보여준다고 할 때, 브라우저는 요청을 통해 HTML 문서를 받아오고, 이를 분석해서 실행해야할 스크립트나 페이지에 포함된 하위 리소스들(레이아웃정보(CSS), 이미지, 비디오 등)을 받아오기 위해 HTTP 요청을 추가적으로 생성, 이를 통해 받은 데이터를 재구성해서 웹페이지를 보여주거나 갱신하게 됩니다. 클라이언트와 서버 사이에도 사실 개체가 존재하는데, 게이트웨이나 캐시역할을 하는 프록시* 등이 존재합니다. 또한 라우터나 모뎀도 클라이언트와 서버 사이에 있지만 이는 Network 계층이나 Transport 계층에서 존재합니다.

 

  1991년에 처음 등장하게 된 HTTP(HTTP/0.9)는 GET 메소드만 존재하고 헤더가 없었으며 서버의 응답은 무조건 HTML의 형태만 가능했지만, 확장성이 좋아 시간이 흐르면서 단순 하이퍼텍스트 문서(document)뿐만이 아니라 이미지, 비디오나 서버로 post하는 콘텐츠(HTML의 form 결과 등) 등을 모두 아우를 수 있게 되었습니다.

 

 

2. HTTP의 특징

2-1.  간단합니다.

  HTTP는 간단하고 사람이 읽고 이해하기 쉽게 디자인됐습니다. 그렇기에 테스트하기 쉽고 초심자도 이해하기 쉽습니다. HTTP/2가 HTTP/1.x에 비해 복잡해졌음에도 불구하고 HTTP 메시지는 프레임별로 캡슐화를 함으로서 간단함을 유지했습니다. HTTP/2 이전에는 HTTP 메시지를 사람이 읽을 수 있었으나, 이후부터는 메시지들이 바이너리 구조의 프레임 안으로 캡슐화되어 사람이 읽을 수 없습니다. 하지만 덕분에 헤더의 압축이나 다중화(multiplexing) 같은 최적화가 가능하게 되었습니다. 또한 기본적인 메시지의 시맨틱은 같기 때문에 각 메시지를 상호해석도 가능합니다.

 

2-2. 확장성이 뛰어납니다.

  HTTP/1.0에서부터 HTTP헤더는 HTTP를 확장하고 실험하기 쉽도록 만들어졌습니다. 클라이언트와 서버가 새로운 헤더의 시맨틱에 대해 합의만 된다면, 언제든지 새로운 기능을 추가할 수 있습니다.

 

2-3. 상태는 없지만(Stateless) 세션은 존재합니다.

  HTTP는 상태를 저장하지 않습니다. 동일한 연결 상에서 연속적으로 전송된 두 개 이상의 요청 사이에는 연관 관계가 없습니다. 이는 e커머스 사이트에서 장바구니 기능처럼, 일관된 방식으로 사용자가 웹페이지와 상호작용하기를 원할 때 문제가 됩니다.  하지만 HTTP의 쿠키는 ‘상태가 있는(Stateful)’ 세션을 만들 수 있도록 해줍니다. HTTP 쿠키는 헤더의 확장성을 이용해서, 동일한 컨텍스트나 동일한 상태를 공유하기 위해 각각의 다른 요청들 사이에서도 세션을 만들 수 있도록 해줍니다.

 

2-4. HTTP와 연결(Connection)

  연결은 Transport 계층에서 제어하고 있기 때문에 Application 계층의 HTTP 영역 밖의 일입니다. HTTP는 연결기반(connection-based)이 되기 위해 Transport Protocol을 요구하지는 않지만, 신뢰성이 있고(reliable) 메시지를 잃지 않는 것(최소한의 오류 표시)을 요구합니다. 인터넷 상에서 가장 일반적인 두 개의 Transport 프로토콜(TCP, UDP)중에서 TCP는 신뢰할 수 있고(reliable), UDP는 그렇지 않습니다. 그렇기때문에 HTTP는 연결이 필수는 아니지만 연결 기반인 TCP에 의존합니다.

 

  클라이언트와 서버가 요청과 응답을 교환하기 전에 TCP 연결설정이 필요합니다. HTTP/1.0은 기본적으로 각 요청과 응답에 대해 별도의 TCP 연결을 설정합니다. 하지만 이는 여러 요청을 연속해서 보낼 경우에는 하나의 TCP 연결을 공유하는 것보다 효율적이지 않습니다.

 

  이를 개선하기 위해 HTTP/1.1에선 파이프라이닝과 지속적인 연결(persistent connections)의 개념을 도입했습니다. Connection헤더를 사용해 TCP연결을 부분적으로 제어할 수 있습니다. 또한 파이프라이닝을 사용하면 클라이언트가 서버로부터 특정 요청을 완전히 수신하기 전에 서버로 다른 여러 요청을 보낼 수 있습니다.

 

  HTTP/2에서는 TCP연결을 유지하고 효율을 증대하기 위해 하나의 TCP연결 상에서 메시지들을 다중 전송(multiplexing)하는 개념을 도입했습니다. (HTTP 버전별 역사와 발전에 대해서 더 자세히 알고 싶은 분들은 https://kamranahmed.info/blog/2016/08/13/http-in-depth 이 글을 읽어보시는 것을 추천합니다. 어렵지 않은 영어로 알기 쉽게 설명되어 있습니다.)

 

3. HTTP로 제어할 수 있는 부수적인 정보들

3-1. 캐시

  문서(document)가 캐싱되는 방식을 제어할 수 있습니다. 클라이언트는 저장된 문서를 무시하라고 중간 캐시 프록시에게 지시할 수 있으며, 서버는 캐싱 대상과 기간을 프록시와 클라이언트에게 지시할 수 있습니다.

 

3-2. 브라우저의 origin 관련 제약사항에 대한 완화

  브라우저는 보안 상의 공격이나 프라이버시 침해를 막기 위해 웹 사이트간 엄격한 분리를 강제합니다. 동일한 origin(데이터 소스)으로부터 온 페이지만 웹 페이지의 전체 정보에 접근할 수 있게 합니다. 이런 제약사항은 서버에 부담이 되기도 하기 때문에, HTTP헤더를 통해 다른 도메인에서 온 데이터들을 패치워크(patchwork)할 수 있게 하면서 그러한 제약사항을 완화시킬 수 있습니다.

 

3-3. 인증

  특정 유저에게만 웹 페이지에 접근이 가능하도록 만들 수 있습니다. 기본적인 인증을 HTTP에서 제공하며, WWW-인증이나 그와 비슷한 헤더를 사용하거나, HTTP 쿠키를 사용한 특정 세션을 설정할 수도 있습니다.

 

3-4. 프록시와 터널링

  서버나 클라이언트는 종종 인트라넷에 위치한 상태로 다른 개체(entity)들에게 그들의 실제 주소를 숨기기도 합니다. 이런 경우 HTTP 요청은 이러한 네트워크 장벽을 가로지르기 위해 프록시를 통과합니다. FTP와 같은 또 다른 프로토콜들 또한 이런 프록시를 통해 처리될 수 있습니다.

 

3-5. 세션

  HTTP 쿠키를 사용해서 서버의 상태(state)와 요청(Request)을 연결할 수 있습니다. 이는 사용자 구성을 원하는 사이트들에서 유용합니다.

 

* 프록시(Proxy)

  클라이언트와 서버 사이에서 HTTP 메시지를 이어 받고 전달하는 컴퓨터 및 기계들 중 Application 계층에서 동작하는 것들을 말합니다. 대부분 캐싱, 필터링(바이러스 스캔, 유해 콘텐츠 차단), 로드 밸런싱, 인증(접근 제어), 로깅(이력 저장) 등의 역할을 합니다.

4. HTTP 요청(Request)

  HTTP 요청은 웹브라우저같은 인터넷 통신 플랫폼이 웹페이지를 로드하기 위해 필요한 정보를 요청하는 방식입니다. HTTP 요청에 포함되는 데이터는 다음과 같습니다.

 

4-1. HTTP 버전 정보

4-2. URL

4-3. HTTP 메소드

  ‘HTTP 동사(verb)’라고도 불리는 HTTP 메소드는 쿼리를 받은 서버로부터의 예상되는 HTTP 요청의 동작을 나타냅니다. 대표적으로 GET과 POST가 있는데, GET의 경우 요청의 결과로 정보를 받기를 예상하는 것이고, POST의 경우는 보통 클라이언트가 서버측에 정보를 전달하는 것을 나타냅니다.

 

4-4. HTTP 요청 헤더

  키-밸류 쌍으로 저장된 텍스트 정보를 포함하며, 모든 HTTP 요청에 항상 존재합니다. 이러한 헤더는 클라이언트가 어떤 브라우저를 사용하고 어떤 데이터가 요청되고 있는지와 같은 핵심 정보를 전달합니다.

요청 헤더 예시

 

4-5. HTTP 요청 바디(Optional)

  HTTP 요청이 전송하는 정보의 본문에 해당됩니다. 사용자 이름이나 패스워드 등 어떠한 데이터든, 웹서버로 보내지는 데이터를 포함합니다.

 

5. HTTP 응답(Response)

  HTTP 응답은 웹 클라이언트(보통 브라우저)가 보낸 HTTP 요청의 결과로 인터넷 서버로부터 받게 되는 데이터입니다. 이러한 응답은 HTTP 요청에서 요청된 내용을 기반으로 중요한 정보를 전달합니다. 일반적으로 HTTP 응답에 포함되는 데이터에는 다음과 같습니다.

5-1. HTTP 상태(status) 코드

  HTTP 요청이 성공적으로 처리되었는지를 알려주는 3자리 숫자의 코드입니다. 예를들어 클라이언트가 웹페이지를 요청하고 그 요청이 적절히 처리되었다면 HTTP 응답에 200 OK라는 HTTP 상태 코드가 포함되어 옵니다. HTTP 상태 코드는 크게 맨 앞 숫자에 따라 5가지 그룹으로 나뉩니다.

1xx : Informational
2xx : Success
3xx : Redirection
4xx : Client Error
5xx : Server Error

 

5-2. HTTP 응답 헤더

  HTTP 요청 헤더와 비슷하게, 언어나 데이터의 포맷 등의 중요 정보들을 포함합니다.

응답 헤더 예시

5-3. HTTP 응답 바디

  GET 요청에 대해 성공적으로 처리된 HTTP 응답의 바디엔 보통 요청된 데이터가 들어있습니다. 대부분의 웹 요청에서 이는 웹 브라우저가 웹페이지로 보여주게 될 HTML데이터입니다.

 

6. HTTP 기반 API

6-1. XHLHttpRequest API

  가장 흔히 사용되는 HTTP 기반 API는 XHLHttpRequest API입니다. ( https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest )

6-2. Fetch API

  최신인 Fetch API는 XHLHttpRequest와 기본적으로는 같은 기능을 제공하지만, 더 강력하고 유연한 기능을 제공합니다. ( https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API )