HTTP 개요

HTTP는 HTML 문서와 같은 리소스들을 페치하도록 해주는 protocol입니다. 그것은 보통 브라우저인 수신자에 의해 요청이 초기화되는 것을 의미하는, 웹과 클라이언트-서버 모델 상에서 모든 데이터 교환의 기초입니다. 하나의 완전한 문서는 페치된 또 다른 하위 문서, 텍스트, 레이아웃 설명, 이미지, 비디오, 스크립트 등으로부터 재구성되게 됩니다.

클라이언트와 서버들은 (데이터 스트림과 대조적으로) 개별적인 메시지 교환에 의해 통신합니다. 보통 브라우저인 클라이언트에 의해 전송되는 메시지를 requests 라고 부르며, 서버에 의해 응답으로 전송되는 메시지를 responses라고 부릅니다.

1990년대 초에 고안된 HTTP는 거듭하여 진화해온 확장 가능한 프로토콜입니다. 그것은 애플리케이션 계층의 프로토콜로, 신뢰 가능한 전송 프로토콜이라면 이론상으로는 무엇이든 사용할 수 있으나 TCP 혹은 암호화된 TCP 연결인 TLS을 통해 전송합니다. 그것의 확장성 덕분에, 오늘날 하이퍼텍스트 문서를 페치하기 위해 사용될 뿐만 아니라, 이미지와 비디오 혹은 HTML 폼 결과와 같은 내용을 서버로 포스트하기 위해서도 사용됩니다. HTTP는 또한 온디멘드 방식으로 웹 페이지를 갱신하기 위해 문서의 일부를 페치하는데 사용될 수도 있습니다.

HTTP 기반 시스템의 컴포넌트

HTTP는 클라이언트-서버 프로토콜입니다: 요청은 하나의 개체, 사용자 에이전트(혹은 그것을 대신하는 프록시)에 의해 전송됩니다. 대부분의 경우, 사용자 에이전트는 브라우저지만, 무엇이든 될 수 있습니다. 예를 들어, 검색 엔진 인덱스를 채워넣고 유지하기 위해 웹을 돌아다니는 로봇이 그러한 경우입니다.

각각의 개별적인 요청은 요청을 처리하고 response라고 불리는 응답을 제공하는 서버로 보내집니다. 예를 들자면, 많은 개체들이 존재하는 가운데, 다른 동작을 수행하며 게이트웨이 혹은 caches로써 활동하는 proxies로써 총괄적으로 고안된 것도 있습니다.

실제로는 브라우저와 요청을 처리하는 서버 사이에는 좀 더 많은 컴퓨터들이 존재합니다: 라우터, 모뎀 등이 있죠. 웹의 계층적인 설계 덕분에, 이들은 네트워크와 전송 계층 내로 숨겨집니다. HTTP은 애플리케이션 계층의 최상위에 있습니다. 네트워크 문제를 분석하는 것도 중요하지만, 근본적인 계층들은 HTTP의  명세와는 거의 관련이 없습니다.

클라이언트: 사용자 에이전트

문자 그대로, 사용자 에이전트는 사용자를 대신하여 동작하는 모든 도구입니다. 실제적으로, 이 역할은 브라우저에 의해 수행됩니다; 엔지니어들과 자신들의 애플리케이션을 디버그하는 웹 개발자들이 사용하는 프로그램들은 예외입니다.

브라우저는 항상 요청을 초기화하는 개체입니다. 그것은 결코 서버가 될 수 없습니다(몇 가지 메커니즘이 수년에 걸쳐 서버 초기화된 메시지를 추가해왔지만).

웹 페이지를 표현하기 위해, 브라우저는 페이지의 HTML 문서를 페치하기 위한 원본 요청을 전송한 뒤, 그것을 분석하여 실행해야 할 스크립트 그리고 페이지 내 포함된 하위 리소스들(보통 이미지와 비디오)을 잘 디스플레이하기 위한 레이아웃 정보(CSS)에 대응하는 추가적인 요청들을 페치합니다. 그런 뒤에 브라우저는 완전 문서인 웹 페이지를 표현하기 위해 그런 리소스들을 합칩니다. 브라우저에 의해 실행된 스크립트는 이후 단계에서 좀 더 많은 리소스들을 페치할 수 있으며 브라우저는 그에 따라 웹 페이지를 갱신하게 됩니다.

웹 페이지는 하이퍼텍스트 문서로, 사용자가 사용자 에이전트를 제어하고 웹을 돌아다닐 수 있도록, 디스플레이된 텍스트의 일부가 새로운 웹 페이지를 페치하기 위해 활성화(보통 마우스 클릭에 의해)될 수 있는 링크임을 뜻합니다. 브라우저는 HTTP 요청 내에서 이런 순서들을 이해하며 이해 가능한 응답으로 사용자에게 보여주기 위해 HTTP 응답을 인터프리트합니다.

웹 서버

통신 채널의 반대편에는 클라이언트에 의한 요청에 대한 문서를 서브하는 서버가 존재합니다. 하나의 서버는 실질적으로 단일 머신입니다: 그것은 로드(로드 밸런싱) 혹은 그때 그때 다른 컴퓨터(캐시, DB 서버, e-커머스 서버 등과 같은)들의 정보를 얻고 완전하게 혹은 부분적으로 문서를 생성해내는 소프트웨어의 복잡한 부분을 공유하는 서버들의 컬렉션일 수도 있습니다.

하나의 서버는 단일 서버일 필요는 없으며 여러 개의 서버들이 동일한 머신 위에 호스트될 수도 있습니다. HTTP/1.1과 Host 헤더를 이용하여, 동일한 IP 주소도 공유할 수 있습니다.

프록시

브라우저와 서버 사이에는, 많은 컴퓨터들과 머신들이 HTTP 메시지를 릴레이합니다. 웹 스택의 계층 구조 덕분에, 그들 중 대부분은 전송, 네트워크 혹은 물리적 수준에서 동작하며, (그들이 성능 상 상당한 영향을 가지고 있음에도) HTTP 계층에서는 눈에 보이지 않습니다. 애플리케이션 계층에서 동작하는 것을 일반적으로 프록시라고 부릅니다. 그들은 눈에 보이거나 그렇지 않을 수도 있으며(프록시는 그들을 통해 요청이 지나가도록 하거나 그렇게 하지 않을 수도 있습니다) 많은 기능들을 수행할 수 있습니다:

• 캐싱 (캐시는 브라우저 캐시처럼 공개되거나 비공개될 수 있습니다)
• 필터링 (안티바이러스 스캔, 시청 규제 등과 같은)
• 여러 서버들이 서로 다른 요청을 서브하도록 해주는 로드 밸런싱
• 다른 리소스에 접근하도록 제어해주는 인증
• 히스토리성의 정보를 저장해주는 로깅

HTTP의 기초적인 부분

HTTP은 간단합니다

HTTP 메시지를 프레임 내로 캡슐화하여 HTTP/2에서 공개된 몇 가지 복잡한 내용에도 불구하고, HTTP는 일반적으로 사람이 읽을 수 있으며 간단하게 고안되었습니다. HTTP 메시지들은 사람이 읽을 수 있고 이해하기 가능하도록 하여, 테스트하기 쉽고 초심자의 진입장벽을 낮췄습니다.

HTTP은 확장 가능합니다

HTTP/1.0에서 소개된, HTTP 헤더는 프로토콜을 확장하고 실험하기 극도로 쉽게 만들어주었습니다. 새로운 기능은 새로운 헤더의 시맨틱에 관한 클라이언트와 서버 간의 동의에 의해 간단히 도입될 수 있습니다.

HTTP은 상태가 없지만, 세션은 있습니다

HTTP는 상태가 없습니다: 동일한 커넥션이든 아닌든 그 위에서 성공적으로 완료된 두 개의 요청 사이에는 연결고리가 없습니다. 이것은, 예를 들자면, e-커머스 쇼핑 바구니처럼, 일관된 방법 내에서 사용자가 페이지와 상호작용하긴 원하자마자 문제가 많다는 것이 증명되었습니다. 헤더 확장성을 사용하여, 동일한 컨텍스트, 동일한 상태를 공유하기 위해 각각의 요청들에 세션을 만들도록 HTTP 쿠키가 추가되었습니다.

HTTP의 핵심은 상태가 없는 것이지만 쿠키의 사용은 상태가 있는 세션을 만들도록 해줍니다.

HTTP와 커넥션

커넥션은 전송 계층에서 제어되며 기본적으로는 HTTP 영역 밖입니다. 그럼에도 불구하고, HTTP는 커넥션에 기반하게 되도록 근본적인 전송 계층을 요구하지 않습니다; 메시지 손실이 없는(적어도 오류 메시지가 없지 않은), 신뢰도를 요구할 뿐입니다. 인터텟 상의 두 개의 가장 일반적인 전송 프로토콜 중에서 TCP는 신뢰성이 있으며 UDP는 그렇지 않습니다. 그러므로 HTTP는 필수는 아니지만 커넥션 기반이 될 수도 있는 TCP에 의존합니다.

HTTP/1.0에서는 요청/응답 교환에 대한 각각의 TCP 커넥션을 열었고, TCP는 두 개의 주요 흐름을 가지고 있습니다: 커넥션을 여는 것은 메시지 각자의 라운드-트립을 필요로 하며 그래서 느립니다. 그러나 그런 각가의 메시지들이 전송되고 규칙적으로 전송되는 경우에 좀 더 효과적으로 변합니다: 활기찬 커넥션이 한가한 커넥션보다 좀 더 효율적입니다.

이러한 흐름을 개선하기 위해, HTTP/1.1은 (구현하기 어렵다고 입증된)파이프라이닝 개념과 영속 커넥션의 개념을 도입했습니다: 기본적인 TCP 커넥션을 Connection 헤더를 사용해 부분적으로 제어할 수 있습니다. HTTP/2는 커넥션을 좀 더 활기차게 유지하는데 도움이 되도록, 단일 커넥션 상으로 메시지를 다중 전송(multiplex)하여 한 걸음 더 나아갔습니다.

HTTP에 더 들어맞도록 좀 더 나은 전송 프로토콜을 설계하는 실험이 진행 중에 있습니다. 예를 들어, 구글은 좀 더 신뢰성있고 효과적인 전송 프로토콜을 제공하기 위해 UDP를 잘 처리하여 빌드한 QUIC을 가지고 실험 중에 있습니다.

HTTP로 제어할 수 있는 것

HTTP의 확장 가능한 특성은 수년 간에 걸쳐 웹의 점점 더 많은 기능들을 제어하도록 허용해 왔습니다. 캐시 혹은 인증 메서드는 HTTP에 초기부터 제어해왔던 기능이며, 반면에 origin 제약사항을 완화시키는 조치는 2010년에 들어서 추가되었습니다.

다음은 HTTP 사용하여 제어 가능한 일반적인 기능 목록입니다.

• 캐시
  HTTP로 문서가 캐시되는 방식을 제어할 수 있습니다. 서버는 무엇을 캐시할 지 그리고 얼마나 오랫동안 할지를 프록시와 클라이언트에 지시할 수 있고 클라이언트는 저장된 문서를 무시하라고 중간 캐시 프록시에게 지시할 수 있습니다.
• origin 제약사항을 완화하기
  스누핑과 다른 프라이버시 침해를 막기 위해, 브라우저는 웹 사이트 간의 엄격한 분리를 강제합니다. 동일한 origin으로부터 온 페이지만이 웹 페이지의 전체 정보에 접근할 수 있죠. 그런 제약 사항은 부담이며, 서버는 HTTP 헤더를 통해 그것을 완화시킬 수 있습니다. 그런 덕분에 문서는 다른 도메인으로부터 전달된 정보를 패치워크할 수 있습니다(그렇게 하려면 몇몇 경우에 보안과 관련된 일이 있을 수도 있습니다).
• 인증
  어떤 페이지들은 보호될 수 있어서 오로지 특정 사용자만이 그것에 접근할 수도 있을 겁니다. 기본 인증은 Authenticate와 그와 유사한 헤더들을 사용해 HTTP에 의해 직접 제공될 수 있으며 혹은 HTTP 쿠키를 사용해 특정 세션을 설정하여 이루어질 수도 있습니다.
• 프록시와 터널링
  서버 혹은 클라이언트 혹은 그 둘 모두는 종종 인트라넷에 위치하며 다른 개체들에게 그들의 실제 주소를 숨기기도 합니다. HTTP 요청은 네트워크 장벅을 가로지르기 위해 프록시를 통해 나가게 되죠. 모든 프록시가 HTTP 프록시는 아니며, SOCKS 프로토콜을 사용하는 어떤 프록시들 같은 경우 저수준에서 동작합니다(프록시에 의해 처리될 수 있는 ftp와 같은 다른 프로토콜도 마찬가지입니다).
• 세션
  쿠키 사용은 서버 상에 상태를 가진 요청을 연결하도록 해줍니다. 이것은 HTTP가 기본적으로 상태없는 프로토콜임에도 세션을 만들어주는 계기가 됩니다. 이것은 e-커머스 쇼핑 바구니를 위해서 유용할 뿐만 아니라 출력 구성을 허용하는 모든 사이트에 대해서 유용합니다.

HTTP 흐름

클라이언트가 서버와 통신하고자 할 때, 최종 서버가 됐든 중간 프록시가 됐든, 다음 단계의 과정을 수행합니다:

1. TCP 커넥션을 엽니다(혹은 이전 것을 재활용합니다): TCP 커넥션은 응답을 얻는 것만큼 한 개 혹은 몇 개의 요청을 전송하는데 사용될 것입니다. 클라이언트는 이미 존재하고 있는 커넥션을 재사용하거나 서버로의 TCP 커넥션을 열 것입니다.
2. HTTP 메시지를 전송합니다: HTTP 메시지(HTTP/2 이전의)는 인간이 읽을 수 있습니다. HTTP/2에서는 이런 간단한 메시지가 프레임 속으로 캡슐화되어, 직접 읽는게 불가능하지만 원칙은 그대로 남겨둡니다.

   GET / HTTP/1.1
   Host: developer.mozilla.org
   Accept-Language: fr

3. 서버에 의해 전송된 응답을 읽어들입니다:

   HTTP/1.1 200 OK
   Date: Sat, 09 Oct 2010 14:28:02 GMT
   Server: Apache
   Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
   ETag: "51142bc1-7449-479b075b2891b"
   Accept-Ranges: bytes
   Content-Length: 29769
   Content-Type: text/html
   
   <!DOCTYPE html... (here comes the 29769 bytes of the requested web page)

4. 다른 요청들을 위해 커넥션을 닫거나 재사용합니다.

HTTP 파이프라이닝이 활성화되어 있다면, 첫번째 응답을 다 받기도 전에 몇가지 요청은 성공적으로 전송될 수 있습니다. HTTP 파이프라이닝이 활성화되면, 첫번째 응답이 완전히 받아질 때까지 기다리지 않고 몇 개의 요청을 성공적으로 전송할 수 있습니다. HTTP 파이프라이닝은 오래된 소프트웨어와 현재 버전이 공존하고 있는, 기존의 네트워크 상에서 구현하기 어렵다는게 입증되었으며, HTTP/2의 프레임 속 다중 요청의 좀 더 견고한 메커니즘으로 교체되고 있습니다.

HTTP 메시지

HTTP/1.1와 초기 HTTP 메시지는 사람이 읽을 수 있습니다. HTTP/2에서, 이 메시지들은 새로운 이진 구조인 프레임 안으로 임베드되어, 헤더의 압축과 다중화와 같은 최적화를 가능케 합니다. 본래의 HTTP 메시지의 일부분만이 HTTP의 이 버전 내에서 전송된다고 할지라도, 각 메시지의 시맨틱들은 변화하지 않으며 클라이언트는 본래의 HTTP/1.1 요청을 (가상으로) 재구성할하게 됩니다; 그러므로 HTTP/1.1 포맷 내에서 HTTP/2를 바라보는 것은 여전히 유용합니다.

HTTP 메시지의 두 가지 타입인 요청과 응답은 각자의 특성있는 형식을 가지고 있습니다.

요청

HTTP 요청의 예제:

요청은 다음의 요소들로 구성됩니다:

• 보통 GET, POST 같은 동사 혹은 OPTIONS나 HEAD와 같은 명사의 HTTP 메서드는 클라이언트가 실행하고자 하는 동작을 정의합니다. 일반적으로, 클라이언트는 리소스를 가져오거나(GET을 사용하여) HTML 폼form의 데이터를 전송(POST를 사용하여)하길 원하며, 다른 경우에는 다른 동작이 요구될 수도 있습니다.
• 가져오려는 리소스의 경로로, protocol (https://), domain (여기서는 developer.mozilla.org), 혹은 TCP port (여기서는 80)인 요소들을 제거한 리소스의 URL입니다.
• HTTP 프로토콜의 버전.
• 서버로 기타 정보를 실어나르는 부가적인 헤더들.
• POST와 같은 몇 가지 메서드를 위한, 응답의 body와 유사한, 전송된 리소스를 포함하는 body.

응답

응답의 예시:

응답은 다음의 요소들로 구성됩니다:

• 그들이 따르는 HTTP 프로토콜의 버전.
• 요청이 성공적으로 이루어졌는지 그렇지 않은지, 그렇지 않다면 왜 그런지를 가리키는 상태 코드.
• 아무런 영향력이 없는, 상태 코드의 짧은 설명을 나타내는 상태 메시지.
• 요청과 비슷한, HTTP 헤더들.
• 부가적이지만, 요청의 경우보다는 좀 더 일반적인, 불러온 리로스를 포함하는 body.

결론

HTTP는 확장 가능한 프로토콜로 사용하기 쉽습니다. 헤더를 쉽게 추가하는 능력을 지닌 클라이언트-서버 구조는 HTTP가 웹의 확장된 수용력과 함께 자라게 해줍니다.

HTTP/2가 성능 향상을 위해 HTTP 메시지를 프레임 내로 임베드하여 약간의 복잡함을 더했을지라도, 애플리케이션의 뷰 관점에서 볼 때, 메시지의 기본적인 구조는 HTTP/1.0이 릴리즈된 이후와 동일합니다. 세션의 흐름은 여전히 단순하여, 간단한 HTTP 메시지 모니터를 이용한 조사와 디버그를 가능하게 해줍니다.