HTTP(Hypertext Transfer Protocol)는 인터넷상에서 데이터를 주고 받기 위한 서버/클라이언트 모델을 따르는 프로토콜이다.
HTTP는 어떤 종류의 데이터든지 전송할 수 있도록 설계되어 있고, HTML문서, 이미지, 동영상, 오디오, 텍스트 문서 등의 리소스를 가져올 수 있다.
하이퍼텍스트 기반으로(Hypertext) 데이터를 전송하겠다(Transfer) = 링크기반으로 데이터에 접속하겠다는 의미인데, 일반적으로 웹 브라우저에 의해 요청이 시작된다.
클라이언트와 서버는 데이터 스트림이 아닌 개별 메시지를 교환하여 통신한다.
클라이언트 (보통 웹 브라우저)가 보낸 메시지를 Request(요청) 이라고 하고 서버가 응답으로 보낸 메시지를 Response(응답) 이라고 한다.
1990년대 초에 설계된 HTTP는 시간이 지남에 따라 진화한 확장 가능한 프로토콜이다.
신뢰할 수 있는 전송 프로토콜로 TCP 또는 TLS 암호화된 TCP 연결을 통해 전송되는 응용 프로그램 계층 프로토콜이다.
확장성으로 인해 하이퍼텍스트 문서뿐만 아니라 이미지 및 비디오를 가져오거나 HTML 형식 결과와 같이 서버에 콘텐츠를 게시하는 데 사용된다.
또한 HTTP는 요청 시 웹 페이지를 업데이트하기 위해 문서의 일부를 가져오는 데 사용될 수 있다.
HTTP 기반 시스템의 구성 요소
HTTP는 클라이언트-서버 프로토콜이다.
요청은 하나의 Entity, User-Agent(또는 그것을 대신하는 Proxy)에 의해 전송된다.
각각의 개별 요청은 서버에 전송되는데, 이 요청을 처리하고 답하는 것을 Response 라고 부른다.
클라이언트와 서버 사이에는 서로 다른 작업을 수행하고 게이트웨이나 캐시의 역할을 하는, 총칭 프록시라고 불리는 수많은 Entity 들이 있다.
실제로 브라우저와 서버 사이에 요청을 처리하는 요소는 매우 많다.
예를 들면, 라우터, 모뎀 등이 있는데, 고맙게도 웹의 계층화된 설계덕분에 네트워크와 전송 계층에 숨겨져 있다.
HTTP는 애플리케이션 계층에서 최상위에 있으며, 네트워크 문제를 진단하는 데 중요하지만 기본 계층은 대부분 HTTP와 관련이 없다.
Client : the user-agent
사용자 에이전트는 사용자를 대신하여 역할을 하는 모든 도구이다.
이 역할은 주로 웹 브라우저에서 수행되며, 엔지니어와 웹 개발자가 응용 프로그램을 디버깅하는 데 사용하는 프로그램도 될 수 있다.
브라우저는 항상 요청을 시작하는 Entity 이다. (서버에서 시작되는 메세징 방법론에서 여러 해에 걸쳐 바뀌어져 옴)
▶ 먼저, 웹 페이지를 표시하기위해 브라우저는 페이지를 나타내는 HTML 문서를 페치하라는 원래 요청을 보낸다.
▶ 그런 다음이 파일을 구문 분석하여 페이지에 포함된 실행 스크립트, 레이아웃 정보 (CSS) 및 하위 리소스 (일반적으로 이미지 및 비디오)에 해당하는 추가 요청을 만든다.
▶ 웹 브라우저는 이러한 리소스를 혼합하여 사용자에게 완전한 문서인 웹 페이지를 제공하게 된다.
▶ 브라우저가 실행한 스크립트는 이후 단계에서 더 많은 리소스를 가져올 수 있으며 브라우저는 웹 페이지를 적절히 업데이트한다.
웹 페이지는 하이퍼 텍스트 문서이다.
이는 표시되는 텍스트의 일부가 링크(일반적으로 마우스 클릭으로 활성화)되어 새 웹 페이지를 가져와서 사용자 에이전트를 지시하고 웹을 탐색 할 수있는 링크임을 의미한다.
브라우저는 이러한 지시를 HTTP 요청으로 변환하고, HTTP 응답을 추가로 해석하여 사용자에게 명확한 응답을 제공하게 된다.
Web Server
통신 채널의 반대편에는 클라이언트가 요청한 문서를 제공하는 서버가 있다.
서버는 사실상 가상의 단일 시스템으로만 나타난다.
실제로 하나의 서버는 서버 하나가 아닌 서버 모음, Load를 공유 (Load Balancing) 또는 다른 컴퓨터(캐시, DB 서버 또는 전자 상거래와 같은)를 조사하는 복잡한 소프트웨어일 수 있기 때문이다.
서버는 반드시 단일 머신 일 필요는 없지만 여러 서버 소프트웨어 인스턴스를 동일한 머신에서 호스팅 할 수 있고,
HTTP/1.1 과 Host헤더를 사용하면 동일한 IP 주소를 공유할 수도 있다.
Proxies
프록시 서버(Proxy Server)는 클라이언트가 자신을 통해서 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해 주는 컴퓨터 시스템이나 응용 프로그램을 가리킨다.
서버와 클라이언트 사이에 중계기로서 대리로 통신을 수행하는 것을 가리켜 '프록시', 그 중계 기능을 하는 것을 프록시 서버라고 부른다.
즉, 웹 브라우저와 서버 사이에서 수많은 컴퓨터와 시스템이 HTTP 메시지를 릴레이하게 되는데,
웹 스택의 계층 구조로 인해 대부분은 Transport, Network 또는 Physical Level에서 작동하여 HTTP 계층에서 그 메시지들은 명확해지며 성능에 상당한 영향을 미치게 된다.
응용 계층에서 작동하는 것을 일반적으로 Proxies(프록시)라고 한다.
프록시 서버 중 일부는 프록시 서버에 요청된 내용들을 캐시를 이용하여 저장해 둔다.
이렇게 캐시를 해 두고 난 후에, 캐시 안에 있는 정보를 요구하는 요청에 대해서는 원격 서버에 접속하여 데이터를 가져올 필요가 없게 됨으로써 전송 시간을 절약할 수 있게 됨과 동시에 불필요하게 외부와의 연결을 하지 않아도 된다는 장점을 갖게 된다.
또한 외부와의 트래픽을 줄이게 됨으로써 네트워크 병목 현상을 방지하는 효과도 얻을 수 있게 된다.
프록시는 다음과 같은 수많은 기능을 수행할 수 있다.
▶ Caching (브라우저는 브라우저 캐시처럼 공개 또는 개인 캐시일 수 있음)
▶ Filtering (바이러스 백신 검사 또는 보호자 통제와 같은 역할을 수행)
▶ Load Balancing (부하 분산, 여러 서버가 서로 다른 요청을 처리 할 수 있도록 함)
▶ Authentication (다른 자원에 대한 액세스 제어)
▶ Logging (이력 정보 저장)
HTTP의 기본적인 측면
HTTP is Simple.
HTTP는 일반적으로 HTTP 메시지를 프레임으로 캡슐화하여 HTTP/2에 도입 된 복잡성이 증가하더라도 간단하고 사람이 읽을 수 있도록 설계되었다.
HTTP 메시지는 사람이 읽고 이해할 수 있으므로 개발자에게 더 쉬운 테스트를 제공하고 초보자에게는 복잡성을 줄일 수 있다.
HTTP is Extensible.
HTTP/1.0에 도입 된 HTTP 헤더를 사용하면 이 프로토콜을 쉽게 확장하고 실험할 수 있다.
새로운 헤더에 대해 클라이언트와 서버 간의 간단한 계약을 통해 새로운 기능을 도입 할 수도 있다.
HTTP is Stateless, but Not Sessionless.
HTTP는 상태를 저장하지 않는다: 동일한 연결에서 두 요청이 연속적으로 수행되는 링크는 없다.
이는 전자 상거래 쇼핑 바구니를 사용하는 것과 같이 특정 페이지와 일관되게 상호 작용을 시도하는 사용자에게 문제가 될 수 있다.
그러나 HTTP의 핵심은 Stateless 인 반면, HTTP 쿠키는 상태 저장 세션을 사용할 수 있도록 한다.
헤더 확장성을 사용하여 HTTP 쿠키가 워크 플로우에 추가되어 각 HTTP 요청에서 세션 작성이 동일한 컨텍스트 또는 동일한 상태를 공유할 수 있다.
HTTP and Connections
Connection은 전송 계층에서 제어되므로 기본적으로 HTTP 범위를 벗어난다.
HTTP는 기본 전송 프로토콜이 연결 기반일 필요는 없지만 보통은 인터넷에서 가장 일반적인 TCP와 UDP 두 가지 전송 프로토콜 중에 연결 기반의 TCP 표준에 의존한다.
클라이언트와 서버가 HTTP Request/Response 쌍을 교환하려면 몇 차례의 왕복이 필요한 TCP 연결을 설정해야 한다.
HTTP/1.0 의 기본 동작은 각 HTTP Request/Response 쌍에 대해 별도의 TCP 연결을 한다.
여러 요청이 연속해서 전송 될 때 단일 TCP 연결을 공유하는 것은 비효율적인데,
이 결함을 완화하기 위해 HTTP/1.1 은 구현하기 어려운 파이프 라이닝과 지속적인 연결을 도입했다.
기본 TCP 연결은 Connection 헤더를 사용하여 부분적으로 제어할 수 있다.
HTTP/2 는 단일 연결을 통해 메시지를 다중화하여 한 단계 더 발전하여 연결을 효율적으로 유지한다.
HTTP에 보다 적합한 전송 프로토콜을 설계하기 위한 실험은 진행 중인데,
예를 들어 Google에서는 보다 안정적이고 효율적인 전송 프로토콜을 제공하기 위해 UDP를 기반으로하는 QUIC 를 개발하고 있다.
HTTP 로 제어 할 수 있는 것
이러한 확장 가능한 HTTP 특성으로 인해 시간이 지남에 따라 웹의 제어 및 기능이 향상되었다.
다음은 HTTP로 제어 할 수있는 일반적인 기능 목록이다.
▶ Caching
문서를 캐시하는 방법은 HTTP로 제어할 수 있다.
서버는 프록시 및 클라이언트에 캐시 대상 및 기간을 지정할 수 있다.
클라이언트는 저장된 캐시 문서를 무시하도록 중간 캐시 프록시에 적용할 수 있다.
▶ Relaxing the origin constraint
웹 스누핑 및 기타 개인 정보 침해를 방지하기 위해 웹 브라우저는 웹 사이트를 엄격하게 분리한다.
동일한 출처의 페이지만 웹 페이지의 모든 정보에 액세스 할 수 있게 한다.
이러한 제약은 서버에 부담이되지만 HTTP 헤더는 서버 측에서 이러한 엄격한 분리를 완화하여 문서가 다른 도메인에서 제공되는 정보가 될 수 있고, 보안 관련 이유가 있을 수도 있다.
▶ Authentication
특정 페이지 만 액세스 할 수 있도록 일부 페이지가 보호될 수 있다.
HTTP WWW-Authenticate 및 유사 헤더를 사용하거나 HTTP 쿠키를 사용하여 특정 세션을 설정하고 기본 인증을 제공 할 수 있다.
▶ Proxy and tunneling
서버 또는 클라이언트는 종종 인트라넷에 있으며 다른 컴퓨터에서 실제 IP 주소를 숨긴다.
그런 다음 HTTP 요청은 프록시를 통해 네트워크 장벽을 통과한다.
모든 프록시가 HTTP 프록시는 아니다.
예를 들어 SOCKS 프로토콜은 낮은 수준에서 작동하며, ftp와 같은 다른 프로토콜은 이러한 프록시에 의해 처리 될 수 있다.
▶ Sessions
HTTP 쿠키를 사용하면 서버 상태와 요청을 연결할 수 있다.
기본 HTTP가 State-Less 프로토콜 임에도 불구하고 세션이 생성된다.
이는 전자 상거래 쇼핑 바구니뿐만 아니라 사용자가 출력을 구성할 수 있는 모든 사이트에도 유용하다.
HTTP 흐름
클라이언트가 서버, 최종 서버 또는 중간 프록시와 통신하려는 경우 다음 단계를 수행한다.
1. TCP 연결(Connection) 열기
TCP 연결은 하나 이상의 요청을 보내고 응답을 받는 데 사용된다.
클라이언트는 새 연결을 열거나 기존 연결을 재사용하거나 서버에 대한 여러 TCP 연결을 열 수 있다.
2. HTTP 메시지 보내기
HTTPHTTP 메시지(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/2 메시지를 HTTP/1.1 형식으로 이해하는 것이 낫다.
HTTP 메시지에는 요청과 응답의 두 가지 유형이 있으며 각각 고유한 형식을 갖고 있다.
Requests
요청은 다음 요소로 구성된다.
HTTP Method(방법), 일반적으로 GET, POST 같은 동사 또는 OPTIONS 또는 HEAD같은 명사로 클라이언트가 수행하고자하는 작업을 정의한다.
클라이언트가 리소스를 페치하길 원하면 클라이언트의 데이터를 URL뒤에 붙여서 GET 방식을 사용하고
POST 방식은 GET 방식과 달리, 데이터 전송을 기반으로 한 요청 메서드로,
GET 방식은 URL에 데이터를 붙여서 보내는 반면, POST방식은 URL에 붙여서 보내지 않고 BODY 에다가 데이터를 넣어서 보낸다.
▶ 가져올 리소스의 경로
▶ HTTP 프로토콜의 버전
▶ 서버에 대한 추가 정보를 전달하는 선택적 헤더
▶ 또는 POST 전송된 리소스를 포함하는 응답과 유사한 일부 메소드의 경우 Body
Responses
응답은 다음 요소로 구성된다.
▶ 해당하는 HTTP 프로토콜의 버전
▶ 상태 코드, 요청이 성공하면 나타내는 여부와 이유
▶ 상태 메시지, 상태 코드에 대한 권한이 없는 간단한 설명
▶ 요청 헤더와 같은 HTTP 헤더
▶ 선택적으로 페치된 자원을 포함하는 Body