01. Http Overview

전세계의 웹브라우저, 서버, 웹 애플리케이션은 모두 Http를 통해 대화한다. Http는 현대 인터넷의 공용어이다.

1. Http: 인터넷의 멀티미디어 배달부

Http는 신뢰성 있는 데이터 전송 프로토콜을 사요아기 때문에, 데이터가 지구 반대편에서 오더라도 전송 중 손상되거나 (순서가) 꼬이지 않음을 보장한다. 개발자는 인터넷의 결합이나 약점에 대한 걱정 없이 애플리케이션 고유의 기능을 구현하는데 집중할 수 있다.

2. 웹 클라이언트와 서버

웹 클라이언트는 서버에게 Http 요청을 송신하고, 웹 서버는 요청된 데이터(콘텐츠)를 Http 응답으로 돌려준다.

가장 흔한 Http 클라이언트는 웹 브라우저이다. 웹 브라우저는 서버에 Http 객체를 요청하고 사용자의 화면에 보여준다.

3. 리소스

웹 서버는 웹 리소스를 관리하고 제공한다. 가장 단순한 웹 리소스는 웹 서버 파일 시스템의 정적 파일이다. 정적 파일은 텍스트 파일, Html 파일, 어도비 아크로뱃 파일, JPEG 이미지, AVI 동영상 파일 등 모든 종류의 파일을 포함한다.

그러나 리소스가 반드시 정적 파일일 필요는 없다. 리소스는 요청에 따라 콘텐츠를 생산하는 프로그램이 될 수도 있다. 이러한 동적 콘텐츠 리소스는 사용자, 사용자의 요청 사항, 시간 등 여러 요소에 따라 다른 콘텐츠를 생성한다.

모든 종류의 콘텐츠 소스가 리소스가 될 수 있다. 엑셀 파일, 웹 게이트웨이, 인터넷 검색 엔진 역시 리소스이다.

3.1 미디어 타입

인터넷은 수천 가지 데이터 타입을 다루므로, 웹에서 전송되는 객체 각각에 MIME 타입이라는 데이터 포맷 라벨을 붙인다. 대부분의 웹 브라우저는 잘 알려진 객체 타입 수백 가지를 다룰 수 있다. 이미지 파일을 보여주고, HTML 파일을 분석하거나 포맷팅하고 오디오 파일을 컴퓨터의 스피커를 통해서 재생하고, 특별한 포맷 파일을 다루기 위해 외부 플러그인 소프트웨어를 실행한다.

MIME 타입은 사선으로 구분된 주 타입(primary type)과 부 타입(specific subtype)으로 이루어진 문자열 라벨이다.

- text/html : 문자열로 이루어진 html
- text/plain : plain ASCII 텍스트 문서
- image/jpeg : JPEG 이미지
- image/gif : GIF 이미지
- video/quicktime : 애플 퀵타임 동영상
- application/vnd.ms-powerpoint : 마이크로소프트 PPT

3.2 URI

웹 서버 리소스는 각자 이름을 가지고 있기 때문에 클라이언트는 관심 있는 리소스를 지목할 수 있다. 서버 리소스의 이름은 통합 자원 식별자(URI, Uniform Resource Identifier)라고 불린다. URI로 정보 리소스를 고유하게 식별할 수 있다.

예시로 ‘죠의 컴퓨터 가게’의 웹 서버에 있는 이미지 리소스 URI를 확인해보자.

http://www.joes-hardware.com/specials/saw-blade.gif

위의 URI에서 아래와 같은 정보를 확인할 수 있다.

• http protocol을 사용하라
• www.joes-hardware.com로 이동하라
• /specials/saw-blade.gif라고 불리는 리소스를 가져와라

HTTP는 주어진 URI로 리소스를 찾아온다. 대표적인 URI로는 URL과 URN이 있다.

URL(Uniform Resource Locator)

통합 자원 지시자. 특정 서버의 한 리소스에 대한 구체적인 위치를 서술한다. URL은 리소스가 정확히 어디에 있고, 어떻게 접근해야 하는지를 분명하게 알려준다.

• http://www.yagoo.com/images/logo.gif
• ftp://joe:tools4u@ftp.joes-hardware.com/locking-pliers.gif

URL은 기본적으로는 세 부분으로 구분할 수 있다.

• 스킴 (Scheme) : 리소스에 접근하기 위해 사용되는 프로토콜을 서술한다. 위에서는 대표적으로 사용되는 http 프로토콜, 비밀번호로 보호되는 ftp 프로토콜을 확인할 수 있다.

• 호스트 (Host) : 리소스를 제공하는 호스트(웹 서버). 도메인이나 IP 주소를 사용할 수 있다.

• 패스 (Path) : 리소스의 위치 경로

URI는 URL과 URN을 포함하는 더 넓은 개념이다. 리소스를 고유하게 식별할 수 있는 문자열이라면 URI에 해당한다.

URL은 URI의 한 형태로, 리소스의 위치와 접근 방법(예: 프로토콜)을 함께 표현한다.

www.somehost.com은 URI로 간주될 수 있다. 이는 도메인 이름이라는 리소스를 식별하지만, 프로토콜(예: http)이나 경로(/index.html)가 없으므로 URL은 아니다.

http://www.somehost.com/index.html는 URI이자 URL이다. 해당 index.html이라는 리소스를 고유하게 식별하고 있고, 프로토콜과 위치 정보까지 표현하고 있다.

URN(Uniform Resource Name)

URN은 리소스에 대해, 그 리소스의 위치에 영향 받지 않는 유일무이한 이름 역할을 한다. 즉, 리소스를 여기저기로 옮기더라도 문제 없이 동작한다. 리소스의 이름이 변하지 않는 한은, 어떠한 프로토콜로 접근하더라도 문제 없다.

예를 들어, 다음의 URN은 인터넷 표준 문서 RFC 2141이 어디에 있거나와 상관없이, (심지어 여러군데 복사되었더라도) 그것을 지칭하는데 사용될 수 있다.

URN은 널리 채택되지 못했다. 효율적인 동작을 위해서는 인프라 지원이 필요한데 그러한 인프라가 부재하므로 URN 채택이 더 늦춰지고 있다.

4 트랜잭션

HTTP 트랜잭션은 요청과 응답으로 이루어진다. 이 상호작용은 HTTP 메세지라고 불리는 정형화된 데이터 덩어리를 통해 이루어진다.

4.1 메서드

HTTP는 HTTP 메서드라고 불리는 여러 가지 종류의 요청 명령을 지원한다. 모든 HTTP 요청 메세지는 하나의 메서드를 갖는다. 메서드는 서버에게 어떤 동작을 수행해야 하는지 말해준다. 아래 다섯 가지는 자주 사용하는 HTTP 메서드들이다.

• GET : 서버에서 클라이언트에게 리소스를 보내라.
• PUT : 클라이언트가 보낸 데이터를 지정한 이름으로 저장하라.
• POST : 클라이언트 데이터를 서버 게이트웨이 어플리케이션으로 보내라.
• DELETE : 지정한 리소스를 삭제하라.
• HEAD : 지정한 리소스의 응답 중, 헤더 부분만 보내라.

메서드에 대해서는 3장에서 상세히 다룰 것이다.

4.2 상태 코드

모든 HTTP 응답 메세지는 상태 코드와 함께 반환된다. 상태 코드는 클라이언트에게 요청이 성공했는지, 아니면 추가 조치가 필요한지 알려주는 세 자리 숫자다. 자주 사용하는 상태 코드는 다음과 같다.

• 200 : 리소스가 바르게 반환되었다.
• 302 : 다시 보내라. 다른 곳에서 리소스를 가져가라.
• 404 : 리소스를 찾을 수 없다.

상태 코드에 대해서도 3장에서 상세히 다룰 것이다.

5. 메시지

HTTP 메시지는 단순한 줄 단위의 문자열이다. 일반 텍스트이므로 사람이 읽고 쓰기 쉽다. 클라이언트 -> 서버는 요청 메세지, 서버 -> 클라이언트는 응답 메세지이다. 둘의 형식은 굉장히 비슷하다. HTTP 메세지는 다음과 같은 세 가지 영역으로 구분된다.

• 시작줄 : 요청이라면 무엇을 해야하는지, 응답이라면 무엇을 했는지를 나타낸다.
• 헤더(Header) : 0개 이상의 헤더 필드가 존재한다. 각 헤더 필드는 Key와 Value로 구성된다.
• 바디(Body) : 요청이나 응답의 데이터가 담기는 부분이다. 임의의 이진 데이터를 포함할 수 있으므로 텍스트는 물론, 이미지, 비디오, 어플리케이션 파일등도 담을 수 있다.

6. TCP 커넥션

HTTP는 어플리케이션 계층의 프로토콜이다. HTTP는 네트워크 통신의 핵심적 세부사항에 대해서 신경쓰지 않는다. 대신 대중적이고 신뢰성 있는 TCP 프로토콜에 위임한다.

TCP는 다음과 같은 신뢰성을 제공한다.

• 오류 없는 데이터 전송
• 데이터의 순서 보장 (데이터는 보낸 순서대로 도착한다)
• 조각나지 않는 데이터 스트림 (어떤 크기든 연속적으로 처리)

TCP 커넥션이 맺어지면, 상호 간 주고 받는 메세지가 사라지거나, 손상되거나, 순서가 뒤바뀌는 일은 없다. HTTP는 TCP의 상위 계층의 프로토콜이므로 HTTP로 메세지를 주고 받기 전에 TCP 연결을 먼저 수행한다.

7. 프로토콜 버전

오늘날 쓰이는 HTTP 프로토콜은 버전이 여러 가지이다.

• HTTP/0.9 : 1991년의 HTTP 프로토콜 타입. 심각한 디자인 결함으로 인해 빠르게 HTTP 1.0으로 대체되었다. MIME 타입이나 헤더, 버전 정보는 지원하지 않는다.

• HTTP/1.0 : 처음으로 널리 쓰인 HTTP 버전이다. 버전 번호, HTTP 헤더, 추가 메서드, 멀티미디어 객체 처리를 추가했다.

• HTTP/1.0+ : 90년대 중반, WWW이 급격히 팽창하고 성공하면서 이에 맞춘 여러 기능이 추가되었다. keep-alive 커넥션, 가상 호스팅, 프록시 연결 지원을 포함해 많은 기능이 사실상의 표준으로서 추가되었다.

• HTTP/1.1 : HTTP 설계의 구조적 결함 교정, 두드러진 성능 최적화, 잘못된 기능 제거에 집중했다. 더 복잡한 웹 어플리케이션과 배포를 지원한다. 현재의 HTTP 버전이다.

• HTTP/2.0 : HTTP/1.1의 성능 문제를 개선하기 위해 구글의 SPDY 프로토콜을 기반으로 설계한 프로토콜이다. 10장 참조.

8. 웹의 구성요소

인터넷에서 상호작용할 수 있는 웹 어플리케이션은 많다.

용어	정의
프록시 (Proxy)	클라이언트와 서버 사이에서 요청/응답을 중계하는 중간 서버 (보안, 캐싱, 필터링 등의 역할 수행)
캐시 (Cache)	자주 요청되는 리소스를 클라이언트 가까이에 임시 저장해 빠르게 응답하는 구조
게이트웨이 (Gateway)	다른 네트워크나 어플리케이션과 연결해주는 중계 서버 (종종 프로토콜 변환 포함)
터널 (Tunnel)	암호화된 트래픽(예: HTTPS)을 중계할 때, 데이터 내용은 보지 않고 연결만 유지하는 특수한 프록시
에이전트 (Agent)	HTTP 요청을 전송하는 클라이언트 프로그램 또는 라이브러리

8.1 프록시

프록시는 클라이언트와 서버 사이에 위치해서 클라이언트의 모든 요청을 받아 (대개 요청을 수정한 뒤에) 서버로 전달한다. 프록시는 일반적으로 보안을 위해 사용된다. 또한, 프록시는 모든 요청과 응답을 필터링한다. 회사에서 인바운드 데이터의 바이러스를 탐지하거나, 초등학교 학생들에게서 성인 컨텐츠를 차단한다. 6장에서 자세히 다룰 것이다.

8.2 캐시

웹 캐시와 캐시 프록시는 자신을 거쳐가는 문서 중 자주 찾는 것의 사본을 저장해둔다. 만약 클라이언트가 동일한 리소스를 요청하면 캐시의 사본을 받을 수 있다. 캐시는 웹 서버보다 클라이언트에게 가까우므로, 클라이언트는 더 빠르게 리소르를 받을 수 있다. 7장에서 캐싱 기술에 대해서 다룰 것이다.

8.3 게이트웨이

게이트웨이는 다른 서버들의 중개자로 동작하는 특별한 서버이다. 게이트웨이는 주로 HTTP 트래픽을 다른 프로토콜로 변환하기 위해서 사용된다. 게이트웨이는 마치 자신이 리소스를 갖고 있는 서버인 것처럼 요청을 다룬다. 클라이언트는 게이트웨이와 통신하고 있음을 알아채지 못할 것이다.

예를 들어, HTTP/FTP 게이트웨이는 FTP URI에 대한 HTTP 요청을 받아들인 뒤, FTP 프로토콜을 이용해 문서를 가져온다. 받아온 문서는 HTTP 메세지에 담겨 클라이언트에게 전달된다. 8장에서 게이트웨이에 대해 다룰 것이다.

8.4 터널

터널은 두 커넥션 사이에서 로우(raw) 데이터를 열어보지 않고 전달해주는 HTTP 어플리케이션이다. HTTP 터널은 주로 비 HTTP 데이터를 HTTP 연결을 통해 그대로 전송해주기 위해 사용된다.

HTTP 터널을 활용하는 대표적인 예로, 암호화된 SSL 트래픽을 HTTP 커넥션으로 전송함으로써 웹 트래픽만 허용하는 사내 방화벽을 통과시키는 것이 있다. HTTP/SSL 터널은 HTTP 요청을 받아들여 목적지의 주소와 포트 번호로 커넥션을 맞는다. 이후부터는 암호화된 SSL 트래픽을 HTTP 채널을 통해 목적지로 전송할 수 있다.

8.5 에이전트

에이전트는 사용자를 위해 HTTP 요청을 만들어주는 클라이언트 프로그램이다. 웹 요청을 만드는 어플리케이션은 모두 HTTP 에이전트이다.