1장
1. 클라이언트와 서버가 주고받는 HTTP 메세지
HTTP는 웹 클라이언트(이하 클라이언트)와 웹 서버(이하 서버) 간의 통신에 사용되는 프로토콜 프로그램이다. 여기서 통신이란, 클라이언트가 서버에 리소스를 요청하고 서버가 요청된 데이터를 응답하는 과정을 말한다. 요청과 응답은 HTTP 메세지(이하 메세지)로 전달되며 메세지는 줄 단위의 문자열 세 부분으로 구성된다.
GET /test/readme.txt HTTP/1.0
시작줄
HTTP/1.0 200 OK
Accept: text/* Accept-Language: en, fr
헤더
Content-type: text/plain Content-length: 11
본문
I am groot.
HTTP가 무엇인지 알았으니 메세지에 들어있는 요소를 구체적으로 알아보자. 먼저 클라이언트는 HTTP 메서드라는 요청 명령을 사용해서 리소스에 대한 행위를 결정한다. 만일 HTTP 메서드가 없다면 서버는 클라이언트가 리소스로 어떤 행위를 하고 싶은지 알 수 없어서 혼란에 빠질 것이다.
GET
웹 서버에서 클라이언트로 지정한 리소스 전송
PUT
클라이언트에서 서버로 보낸 데이터를 지정한 이름의 리소스로 저장
DELETE
지정한 리소스를 서버에서 삭제
POST
클라이언트 데이터를 서버 게이트웨이 애플리케이션으로 전송
HEAD
지정한 리소스에 대한 응답에서 HTTP 헤더 부분만 전송
HTTP 메서드가 결정되었다면 클라이언트는 URI를 사용해서 요청하고 싶은 리소스를 지목한다. 만일 메세지에 HTTP 메서드만 존재한다면 서버는 어떤 리소스를 반환해야할지 몰라서 다시 한 번 혼란에 빠질 것이다. URI에는 URL과 URN이 있는데 대중적으로 쓰이는 건 URL이다.
URL의 표준 포맷 http://www.google.com/news/weather.gif
프로토콜(scheme)
서버
리소스
리소스에 접근하기 위해 사용되는 프로토콜 e.g. http://
서버의 인터넷 주소 e.g. www.google.com
웹 서버의 리소스 e.g. /news/weather.gif
클라이언트가 HTTP 메서드와 URI를 사용해서 제대로 잘 작성된 HTTP 메세지를 보냈다고 가정해보자. 서버는 메세지를 해석하고 그에 맞는 응답을 반환해야 한다. 먼저 서버는 요청 결과를 HTTP 상태 코드와 사유 구절로 표현한다. 만일 요청 결과가 없다면 클라이언트는 요청이 실패했다고 판단하고 계속 똑같은 요청을 보내거나 잘못된 결과를 옳은 요청이라고 인식하고 사용자에게 보여줄 수 있다.
200
성공. 문서가 바르게 반환되었다.
302
다시 보내라. 다른 곳에 가서 리소스를 가져가라.
404
없음. 리소스를 찾을 수 없다.
또한 서버는 반환할 리소스(HTTP 객체)에 MIME 타입을 붙인다. 만일 MIME가 없다면 클라이언트는 서버가 반환한 리소스를 다룰 수 없어 에러를 일으킬 수 있다. 그림 파일과 같은 정적 콘텐츠부터 요청에 따라 콘텐츠를 생산하는 동적 콘텐츠도 리소스가 될 수 있다. 다시 말해서 어떤 종류의 콘텐츠 소스도 리소스가 될 수 있다.
MIME 타입
주 타입(primary object type) / 부 타입(specific subtype)
text/html
2. 클라이언트와 서버의 HTTP 트랜잭션
클라이언트와 서버가 주고받는 HTTP 메세지를 알아봤으니 데이터 전송 관점에서 HTTP 트랜잭션을 생각해보자. 일반적으로 애플리케이션은 대량의 HTTP 트랜잭션을 수행한다. 대량의 트랜잭션을 수행하면서도 문제없이 의사소통을 하는 비결은 무엇일까? HTTP는 신뢰성 있는 데이터 전송 프로토콜, TCP 커넥션을 통해 데이터를 전송한다. TCP/IP는 TCP와 IP가 층을 이루는 패킷 교환 네트워크 프로토콜의 집합이다. TCP/IP는 각 네트워크와 하드웨어의 특성을 숨기고 어떤 종류의 컴퓨터/네트워크든 서로 신뢰성 있는 의사소통을 보장한다. TCP가 제공하는 기능은 아래와 같다.
오류 없는 데이터 전송
순서에 맞는 전달(데이터는 언제나 보낸 순서대로 도착한다)
조각나지 않는 데이터 스트림(언제든 어떤 크기로든 보낼 수 있다)
TCP가 무엇인지 알았으니 아래 그림을 보고 클라이언트와 서버가 어떻게 HTTP 메세지를 전송하는지 생각해보자.
HTTP 메세지를 보내기 위해 클라이언트와 서버는 먼저 TCP/IP 커넥션을 맺어야 한다. 커넥션을 맺기 위해서는 서버 컴퓨터에 대한 인터넷 프로토콜(IP) 주소와 서버에서 실행 중인 프로그램이 사용 중인 포트 번호가 필요하다. 예를 들어 사용자가 웹 브라우저에서 GET 메서드로 https://jiunkoo.github.io/index.html이라는 URL을 요청하면 어떤 일이 벌어질까? 해당 URL에는 포트 번호가 빠져 있지만, 포트 번호는 보이지 않을 뿐 존재한다. 일반적으로 포트 번호가 기본값 80인 경우 생략하기 때문이다. 마찬가지로 사용자가 작성한 URL에는 숫자로 된 IP 주소 대신 jiunkoo.github.io이라는 글자로 된 호스트 명(도매인 이름)만 가지고 있다. 호스트 명은 IP 주소에 대한 이해하기 쉬운 형태의 별명이다. 호스트 명은 DNS라 불리는 장치를 통해 IP주소로 변환된다. 예시에서는 207.200.228.29라는 IP 주소와 80의 포트 번호를 추출했다. 성공적으로 IP주소와 포트 번호를 알아냈다면 클라이언트는 서버와 TCP 커넥션을 맺을 수 있다. 커넥션이 성공적으로 맺어졌다면 클라이언트는 서버에 HTTP 요청을 보내고 서버는 웹브라우저에 HTTP응답을 반환한다. 요청과 응답이 끝났으면 TCP 커넥션은 해제되고 클라이언트는 사용자에게 응답받은 결과를 보여준다.
3. HTTP 프로토콜 버전과 다양한 웹 애플리케이션
오늘날 HTTP 프로토콜은 다양한 버전이 쓰이고 있으며 종류는 다음과 같다.
HTTP/1.0
버전 번호, HTTP 헤더, 추가 메서드, 멀티미디어 객체 처리 지원
HTTP/1.0+
"keep-alive" 커넥션, 가상 호스팅, 프락시 연결 지원
HTTP/1.1
복잡해진 웹 애플리케이션과 배포 지원
HTTP/2.0
구글의 SPDY 프로토콜을 기반으로 설계가 진행 중인 프로토콜
수많은 버전의 HTTP 프로토콜이 쓰이고 있듯이, 인터넷과 상호작용 할 수 있는 웹 애플리케이션의 종류도 다양하다. 웹 애플리케이션에 관해서는 6장에서 9장까지 자세히 다룰 것이므로 간략하게 소개하고 넘어가겠다.
프록시
- 클라이언트와 서버 사이에 위치하여 클라이언트의 모든 HTTP 요청을 받아 서버에 전달 - 사용자를 대신해서 서버에 접근 - 주로 보안을 위해 사용 - 웹 트래픽 흐름 속에서 신뢰할만한 중개자 역할 - 요청과 응답 필터링
캐시
- 웹 캐시와 캐시 프락시는 자신을 거쳐 가는 문서들 중 자주 찾는 것의 사본을 저장하는 HTTP 프락시 서버
게이트웨이
- 다른 서버들의 중개자로 동작하는 특별한 서버 - HTTP 트래픽을 다른 프로토콜로 변환하기 위해 사용 - 언제나 스스로가 리소스를 갖고 있는 진짜 서버인 것처럼 요청을 다룸 - HTTP/FTP 게이트웨이는 FTP URI에 대한 HTTP 요청을 받아들인 뒤 FTP 프로토콜을 이용해 문서를 가져옴 (가져온 문서는 HTTP 메세지로 클라이언트에 전송)
터널
- 두 커넥션 사이에서 날(raw) 데이터를 열어보지 않고 그대로 전달해주는 HTTP 애플리케이션 - 주로 비 HTTP 데이터를 하나 이상의 HTTP 연결을 통해 그대로 전송해주기 위해 사용 - 암호화된 SSL 트래픽을 HTTP 커넥션으로 전송함으로써 웹 트래픽만 허용하는 사내 방화벽 통과
(사용자) 에이전트
- 사용자를 위해 HTTP 요청을 만들어주는 클라이언트 프로그램 - 웹 요청을 만드는 애플리케이션은 뭐든 HTTP 에이전트 - 자동화된 사용자 에이전트: 웹 브라우저, 스파이더, 웹로봇 등 (사람의 통제 없이 스스로 웹을 돌아다니며 HTTP 트랜잭션을 일으키고 콘텐츠를 받아옴)
참고 자료
HTTP 완벽 가이드 - 인사이트
Last updated