참고 도서 : HTTP 완벽 가이드
학습 목표
- 얼마나 많은 클라이언트와 서버가 통신하는지
- 리소스(웹 콘텐츠가 어디서 오는지)
- 웹 트랜잭션이 어떻게 동작하는지
- HTTP 통신을 위해 사용하는 메시지 형식
- HTTP 기저의 TCP 네트워크 전송
- 여러 종류의 HTTP 프로토콜
- 인터넷 곳곳에 설치된 다양한 HTTP 구성요소
HTTP
웹 클라이언트와 서버
웹 콘텐츠는 웹 서버에 존재한다. 웹 서버는 HTTP 프로토콜로 의사소통하기 때문에 보통 HTTP 라고 불린다. 이 웹 서버는 인터넷의 데이터를 저장하고, HTTP 클라이언트가 요청한 데이터를 제공한다.
클라이언트는 서버에게 HTTP 요청을 보내고, 서버는 요청된 데이터를 HTTP 응답으로 돌려준다. HTTP 클라이언트와 HTTP 서버는 월드 와이드 웹의 기본 요소다.
리소스
웹 서버는 웹 리소스를 관리하고 제공한다. 웹 리소스는 웹 콘텐츠의 원천이다. 가장 단순한 웹 리소스는 웹 서버 파일 시스템의 정적 파일이다.
그러나 리소스는 요청에 따라 콘텐츠를 생산하는 프로그램이 될 수도 있다. 즉, 어떤 종류의 콘텐츠 소스도 리소스가 될 수 있다.
미디어 타입
인터넷은 수천 가지 데이터 타입을 다루기 때문에, HTTP 는 웹에서 전송되는 객체 각각에 신중하게 MIME 타입이라는 데이터 포맷 라벨을 붙인다.
MIME(Multipurpose Internet Mail Extensions)
MIME은 원래 각기 다른 전자메일 시스템 사이에서 메시지가 오갈 때 겪는 문제점을 해결하기 위해 설계되었다. 원래 이메일에서 잘 동작했기 때문에, HTTP에서도 멀티미디어 콘텐츠를 기술하고 라벨을 붙이기 위해 채택되었다.
- text/html
- text/plain
- image/jpeg
- image/gif
- video/quicktime
- application/vnd.ms-powerpoint
등과 같이 표시된다.
URI
웹 서버 리소스는 각자 이름을 갖고 있기 때문에, 클라이언트는 관심 있는 리소스를 지목할 수 있다. 서버 리소스 이름은 통합 자원 식별자(uniform resource identifier)
혹은 URI
로 불린다. URI
는 인터넷의 주소 같은 것으로, 정보 리소스를 고유하게 식별하고 위치를 지정할 수 있다.
http://www.joes-hardware.com/specials/saw-blade.gif
조의 컴퓨터 가게
의 웹 서버에 있는 이미지 리소스에 대한 URI
라면 이런 식이다.
HTTP
는 주어진 URI
로 객체를 찾아온다. URI
에는 두 가지가 있는데, URL
과 URN
이라는 것이다.
URL
통합 자원 지시자(uniform resource locator
, URL
)는 리소스 식별자의 가장 흔한 형태이다. URL
은 특정 서버의 한 리소스에 대한 구체적인 위치를 서술한다. URL
은 리소스가 정확히 어디에 있고 어떻게 접근할 수 있는지 분명히 알려준다.
대부분의 URL
은 세 부분으로 이루어진 표준 포맷을 따른다.
URL
의 첫 번째 부분은 스키마(Scheme)라고 불리는데, 리소스에 접근하기 위해 사용되는 프로토콜을 말한다. 보통 HTTP 프로토콜http://
- 두 번째 부분은 서버의 인터넷 주소를 제공한다.
www.joes-hardware.com
- 마지막은 웹 서버의 리소스를 가리킨다.
/specials/saw-blade.gif
오늘날 대부분의 URI는 URL이다.
URN
URI의 두 번째 종류는 유니폼 리소스 이름 (uniform resource name
, URN
)이다. URN은 콘텐츠를 이루는 한 리소스에 대해, 그 리소스의 위치에 영향 받지 않는 이름 역할을 한다. 위치 독립적인 URN
은 리소스를 여기저기로 옮기더라도 문제없이 동작한다. 리소스가 이름을 변하지 않게 유지하는 한, 여러 종류의 네트워크 접속 프로토콜로 접근해도 문제없다.
urn:ietf:rfc:2141
URN
은 효율적인 동작을 위해 리소스 위치를 분석하기 위한 인프라 지원이 필요하다. 그 인프라가 부재하기에 URN
채택이 늦어지고 있다.
트랜잭션
클라이언트가 웹 서버와 리소스를 주고받기 위해 HTTP를 어떻게 사용하는가? HTTP 트랜잭션은 요청 명령과 응답 결과로 구성되어 있다. 이 상호작용은 HTTP 메시지라고 불리는 정형화된 데이터 덩어리를 이용해 이루어진다.
메서드
모든 HTTP 요청 메시지는 한 개의 메서드를 갖는다. 메서드는 서버에게 어떤 동작이 취해져야 하는지 말해준다.
- GET : 서버에서 클라이언트로 지정한 리소스를 보내라
- PUT : 클라이언트에서 서버로 보낸 데이터를 지정한 이름의 리소스로 저장하여라
- DELETE : 지정한 리소스를 서버에서 삭제하라
- POST : 클라이언트 데이터를 서버 게이트웨이 애플리케이션으로 보내라
- HEAD : 지정한 리소스에 대한 응답에서, HTTP 헤더 부분만 보내라
웹 페이지는 여러 객체로 이루어질 수 있다
애플리케이션은 보통 하나의 작업을 수행하기 위해 여러 HTTP 트랜잭션을 수행한다. 처음엔 페이지 레이아웃을 서술하는 HTML 뼈대를 한 번의 트랜잭션으로 가져온 뒤, 나머지들을 가져오기 위해 추가로 HTTP 트랜잭션들을 수행한다. 즉, 웹페이지는 보통 하나의 리소스가 아닌 리소스의 모음이다.
메시지
HTTP 메시지는 단순한 줄 단위의 문자열이다. 요청 메시지, 응답 메시지 외의 HTTP 메시지는 없다.
요청 메시지
GET /test/hi-there.txt HTTP/1.0
Accept: text/*
Accept-Language: en, fr
응답 메시지
HTTP/1.0 200 OK
Content-type: text/plain
Content-length: 19
Hello Message
HTTP 메시지는 시작줄, 헤더, 본문으로 나뉘어진다.
TCP 커넥션
어떻게 HTTP 메시지가 TCP(Transmission Control Protocol
, 전송 제어 프로토콜) 커넥션을 통해 한 곳에서 다른 곳으로 옮겨가는가?
TCP/IP
HTTP
는 애플리케이션 계층 프로토콜이다. HTTP
는 네트워크 통신의 핵심적인 세부사항에 대해서 신경쓰지 않는다. 이를 TCP/IP
에게 맡긴다.
TCP
는 다음을 제공한다.
- 오류 없는 데이터 전송
- 순서에 맞는 전달
- 조각나지 않는 데이터 스트림
TCP/IP
는 TCP
와 IP
가 층을 이루는 패킷 교환 네트워크 프로토콜의 집합니다. TCP/IP
는 각 네트워크와 하드웨어의 특성을 숨기고, 어떤 종류의 컴퓨터나 네트워크든 서로 신뢰성있는 의사소통을 하게 해준다.
TCP
커넥션이 맺어지면, 클라이언트와 서버 컴퓨터 간에 교환되는 메시지가 없어지거나 손상되는 등의 일은 절대 없다.
HTTP 프로토콜은 TCP 위의 계층이다. HTTP는 자신의 메시지 데이터를 전송하기 위해 TCP를 사용한다. 이와 유사하게 TCP는 IP 위의 계층이다.
접속, IP 주소 그리고 포트번호
HTTP
클라이언트가 서버에 메시지를 전송할 수 있게 되기 전에, 인터넷 프로토콜 주소와 포트번호를 사용해 클라이언트와 서버 사이에 TCP/IP
커넥션을 맺어야한다.
HTTP
서버의 IP
주소와 포트번호를 알아내려면, URL
을 이용하면 된다. URL
은 그 리소스를 가지고 있는 장비에 대한 IP
주소를 알려줄 수 있다.
URL
엔 숫자로 된 IP
주소도 있지만, 글자로 된 도메인 이름 혹은 호스트 명을 갖고 있다. 호스트 명은 IP
주소에 대한 이해하기 쉬운 형태의 별명이다. URL
포트번호가 없는 경우엔 기본값 80
이라고 가정하면 된다.
즉, IP주소와 포트번호를 이용해 클라이언트는 TCP/IP로 쉽게 통신할 수 있다.
- 웹 브라우저는 서버의 URL에서 호스트 명을 추출한다.
- 서버의 호스트 명을 IP로 변환한다.
- URL에서 포트번호를 추출한다.
- 웹 서버와 TCP 커넥션을 맺는다.
- 서버에 HTTP 요청을 보낸다.
- 서버는 웹 브라우저에 HTTP 응답을 돌려준다.
- 커넥션이 닫히면, 웹 브라우저는 문서를 보여준다.
Telnet
텔넷 유틸리티는 클라이언트의 키보드를 목적지의 TCP 포트로 연결해주고 출력 TCP 포트를 당신의 화면으로 연결해준다.
텔넷은 원격 터미널 세션을 위해 흔히 사용되지만, HTTP 서버를 포함한 일반적인 TCP 서버에 연결하기 위해 사용될 수도 있다.
텔넷이 호스트 명과 포트번호를 찾아 대기중인 웹 서버에 연결하면, 커넥션이 수립되었음을 출력하고, 그러면 HTTP 요청 명령을 입력하여 보내면 된다.
프로토콜 버전
- HTTP/0.9
1991년의 HTTP 프로토타입이다. 오직 GET 메서드만 지원한다. 이는 원래 간단한 HTML 객체를 받아오기 위해 만들어진 것이다.
- HTTP/1.0
처음으로 널리 쓰이기 시작한 HTTP 버전이다. 버전 번호, HTTP 헤더, 추가 메서드, 멀티미디어 객체 처리를 추가했다. 월드 와이드 웹을 대세로 만들었다. 잘 만들어진 명세는 아니다.
- HTTP/1.0+
1990년대 중반, 오래 지속되는 keep-alive
커넥션, 가상 호스팅 지원, 프락시 연결 지원을 포함해 많은 기능이 HTTP
에 추가되었다.
- HTTP/1.1
HTTP 설게의 구조적 결함 교정, 두드러진 성능 최적화, 잘못된 기능 제거를 하고, 뿐만 아니라 더 복잡해진 웹 애플리케이션과 배포를 지원한다. 이는 현재 HTTP 버전이다.
- HTTP/2.0
HTTP/1.1 성능 문제를 개선하기 위해 구글의 SPDY 프로토콜을 기반으로 설계된 프로토콜이다. 부족한 설명은 나중에 채우겠움
웹의 구성요소
웹 애플리케이션(웹 브라우저와 웹 서버)이 기본적인 트랜잭션을 구현하기 위해 어떻게 메시지를 주고받는지에 중점을 둔다. 인터넷과 상호작용할 수 있는 웹 애플리케이션은 많다.
- 프락시
클라이언트와 서버 사이에 위치한 HTTP 중개자
- 캐시
많이 찾는 웹 페이지를 클라이언트 가까이에 보관하는 HTTP 창고
- 게이트웨이
다른 애플리케이션과 연결된 특별한 웹 서버
- 터널
단순히 HTTP 통신을 전달하기만 하는 특별한 프락시
- 에이전트
자동화된 HTTP 요청을 만드는 준지능적 웹 클라이언트
프락시
웹 보안, 애플리케이션 통합, 성능 최적화를 위한 중요한 구성요소이다.
프락시는 클라이언트와 서버 사이에 위치하여, 클라이언트의 모든 HTTP 요청을 받아 서버에 전달한다. 사용자를 위한 프락시로 동작하며 사용자를 대신해서 서버에 접근한다.
프락시는 주로 보안을 위해 사용된다. 모든 웹 트래픽 흐름 속에서 신뢰할 만한 중개자 역할을 한다. 또한 요청과 응답을 필터링한다. (목적이 다른 사이트 및 바이러스 차단)
캐시
웹 캐시와 캐시 프락시는 자신을 거쳐 가는 문서들 중 자주 찾는 것의 사본을 저장해 두는 다른 종류의 HTTP 프락시 서버이다. 그 다음 클라이언트가 같은 문서를 요청하면 그 캐시가 갖고 있는 사본을 받을 수 있다.
클라이언트는 웹 서버보다 캐시에서 문서를 더욱 빨리 받아볼 수 있다. HTTP는 캐시를 효율적으로 동작하게 하고 캐시된 콘텐츠를 최신 버전으로 유지하면서 프라이버시도 보호하기 위한 많은 기능을 정의한다……
게이트웨이
게이트웨이는 다른 서버들의 중개자로 동작하는 특별한 서버다. 주로 HTTP 트래픽을 다른 프로토콜로 변환하기 위해 사용된다. 리소스를 갖고 있는 진짜 서버인 것처럼 요청을 다룬다. 클라이언트는 그래서 게이트웨이와 통신하고 있음을 알아채지 못한다.
HTTP/FTP 게이트웨이는 FTP URI에 대한 HTTP 요청을 받아들인 뒤, FTP 프로토콜을 이용해 문서를 가져온다. 받아온 문서는 HTTP 메시지에 담겨 클라이언트에게 보낸다.
터널
터널은 두 커넥션 사이에서 raw 데이터를 열어보지 않고 그대로 전달해주는 HTTP 애플리케이션이다.
대표적인 예로, 암호화된 SSL 트래픽을 HTTP 커넥션으로 전송함으로써 웹 트래픽만 허용하는 사내 방화벽을 통과시키는 경우 터널을 쓴다.
HTTP/SSL 터널은 HTTP 요청을 받아들여 목적지의 주소와 포트번호로 커넥션을 맺는다. 이후부터 암호화된 SSL 트래픽을 HTTP 채널을 통해 목적지 서버로 전송할 수 있게 된다.
에이전트
에이전트는 사용자를 위해 HTTP 요청을 만들어주는 클라이언트 프로그램이다. 예를 들어, 사람의 통제 없이 스스로 웹을 돌아다니며 HTTP 트랜잭션을 일으키고 콘텐츠를 받아오는 자동화된 사용자 에이전트가 있다.
이는 검색엔진의 데이터베이스 또는 가격비교 로봇을 위한 제품 카탈로그와 같은 유용한 웹 콘텐츠 보관소를 만든다.