1부 1장 - HTTP 개관

1.1 HTTP: 인터넷의 멀티미디어 배달부

HTTP는 신뢰성 있는 데이터 전송 프로토콜을 사용하기 떄문에, 데이터가 전송 중 손상되거나 꼬이지 않음을 보장한다.

이 덕분에 사용자는 인터넷에서 얻은 정보가 손상된 게 아닌지 염려하지 않아도 된다.

개발자는 인터넷의 결함이나 약점에 대한 걱정 없이 애플리케이션 고유의 기능을 구현하는 데 집중할 수 있다.

1.2 웹 클라이언트와 서버

웹 콘텐츠는 웹 서버에 존재한다. 보통 HTTP 프로토콜로 의사소통하기 때문에 HTTP 서버라고 불린다.

웹 서버는 인터넷의 데이터를 저장하고, HTTP 클라이언트가 요청한 데이터를 제공한다.

클라이언트는 서버에게 HTTP 요청을 보내고 서버는 요청된 데이터를 HTTP 응답으로 돌려준다.

HTTP 클라이언트와 HTTP 서버는 월드 와이드 웹의 기본 요소다.

1.3 리소스

웹 서버는 웹 리소스를 관리 / 제공한다.

웹 리소스란 웹에 콘텐츠를 제공하는 모든 것이다.

어떤 종류의 콘텐츠 소스도 리소스가 될 수 있다.

1.3.1 미디어 타입

인터넷은 수천가지 데이터 타입을 다루기 때문에, HTTP는 웹에서 전송되는 객체 각각에 MIME 타입이라는 데이터 포맷 라벨을 붙인다.

웹 서버는 모든 HTTP 객체 데이터에 MIME 타입을 붙인다. 대부분의 웹 브라우저는 잘 알려진 객체 타입 수백 가지를 다룰 수 있다.

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

예)   HTML로 작성된 텍스트 문서 -> text/html

JPEG 이미지 파일 -> image/jpeg

애플 퀵타임 동영상 -> video/quicktime

1.3.2 URI

웹 서버 리소스는 각자 이름을 갖고 있기 때문에, 클라이언트는 관심 있는 리소스를 지목할 수 있다.

서버 리소스 이름은 통합 자원 식별자, URI라고 불린다. 이것은 정보 리소스를 고유하게 식별하고 위치를 지정할 수 있다.

URI는 URL과 URN이 있다.

1.3.3 URL

리소스 식별자의 가장 흔한 형태.

특정 서버의 한 리소스에 대한 구체적인 위치를 서술한다.

리소스가 정확히 어디에 있고 어떻게 접근할 수 있는지 분명히 알려준다.

대부분의 URL은 세 부분으로 이루어진 표준 포맷을 따른다.

1. URL의 첫번째 부분은 스킴(scheme) 이라고 불리는 데, 리소스에 접근하기 위해 사용되는 프로토콜을 서술한다. 보통 HTTP 프로토콜이다.

2. 두번째 부분은 서버의 인터넷 주소를 제공한다. (예: www.naver.com)

3. 마지막은 웹 서버의 리소스를 가리킨다. (예: /specials/saw-blade.gif)

1.3.4 URN

콘텐츠를 이루는 한 리소스에 대해, 그 리소스의 위치에 영향 받지 않는 유일무이한 이름.

리소스를 여기저기로 옮기더라도 문제 없이 작동함.

아직 널리 채택되지는 않았다.

1.4 트랜잭션

HTTP 트랜잭션은 요청 명령 (클라이언트 -> 서버)과 응답 명령 (서버 -> 클라이언트) 로 구성되어 있다.

이 상호작용은 HTTP 메시지라고 불리는 정형화 된 데이터 덩어리를 이용해 이루어 진다.

1.4.1 메서드

HTTP는 HTTP 메서드라고 불리는 여러가지 종류의 요청 명령을 지원한다.

모든 HTTP 요청 메시지는 한 개의 메서드를 갖는다.

메서드는 서버에게 어떤 동작이 취해져야 하는지 말해준다.

예)   GET: 서버에서 클라이언트로 지정한 리소스를 보내라

PUT: 클라이언트에서 서버로 보낸 데이터를 지정한 이름의 리소스로 저장하라.

DELETE: 지정한 리소스를 서버에서 삭제하라

POST: 클라이언트 데이터를 서버 게이트웨이 애플리케이션으로 보내라

HEAD: 지정한 리소스에 대한 응답에서, HTTP 헤더 부분만 보내라

1.4.2 상태 코드

모든 HTTP 응답 메시지는 상태 코드와 함께 반환된다.

상태 코드는 클라이언트에게 요청이 성공했는지 아니면 추가 조치가 필요한 지 알려주는 세 자리 숫자다.

예)   200: 좋다. 문서가 바르게 반환되었다.

302: 다른 곳에 가서 리소스를 가져가라

404: 없음. 리소스를 찾을 수 없다.

1.4.3 웹 페이지는 여러 객체로 이루어질 수 있다.

애플리케이션은 보통 하나의 작업을 수행하기 위해 여러 HTTP 트랜잭션을 수행한다.

웹 페이지는 보통 하나의 리소스가 아닌, 리소스의 모음이다.

1.5 메시지

HTTP 메시지는 단순한 줄 단위의 문자열이다.

웹 클라이언트에서 웹 서버로 보낸 HTTP 메시지를 요청 메시지라고 부름.

서버에서 클라이언트로 가는 메시지를 응답 메시지라 부름.

다른 종류의 메시지는 없음.

ex) 메시지의 구조

	요청 메시지	응답 메시지
시작줄	GET /test/hi-there.txt HTTP/1.0	HTTP/1.0 200 OK
헤더	Accept: text/*  Accept-Language: en,fr	Content-Type: text/plain Content-length: 19
본문		Hi! I`m a message!

- 시작줄: 메시지의 첫 줄. 요청이라면 무엇을 해야 하는지, 응답이라면 무슨 일이 일어났는지 나타냄.

- 헤더: 각 헤더 필드는 쌍점(:) 으로 구분되어 있는 하나의 이름과 하나의 값으로 구성된다. 헤더는 빈 줄로 끝난다.

- 본문: 어떤 종류의 데이터든 들어갈 수 있다. 요청의 본문은 웹 서버로 데이터를 실어 보내며, 응답의 본문은 클라이언트로 데이터를 반환한다.

1.6 TCP 커넥션

어떻게 메시지는 TCP 커넥션을 통해 한 곳에서 다른 곳으로 옮겨가는가?

1.6.1 TCP/IP

HTTP는 애플리케이션 계층 프로토콜이다.

HTTP는 네트워크 통신의 핵심적인 세부사항에 신경 쓰는 대신, TCP/IP에게 맡긴다.

TCP는 다음을 제공한다.

- 오류 없는 데이터 전송

- 순서에 맞는 전달 (데이터는 언제나 보낸 순서대로 도착)

- 조각나지 않는 데이터 스트림 (언제든 어떤 크기로든 보낼 수 있다)

TCP/IP는 TCP와 IP가 층을 이루는 패킷 교환 네트워크 프로토콜의 집합이다.

각 네트워크와 하드웨어의 특성을 숨기고, 어떤 종류의 컴퓨터나 네트워크든 서로 신뢰성 있는 의사소통을 하게 해준다.

네트워크 개념 상, HTTP 프로토콜은 TCP 위의 계층이다.

HTTP는 자신의 메시지 데이터를 전송하기 위해 TCP를 사용한다.

1.6.2 접속, IP 주소 그리고 포트 번호

HTTP 클라이언트가 서버에 메시지를 전송할 수 있게 되기 전에, 인터넷 프로토콜 (IP) 주소와 포트번호를 사용해 클라이언트와 서버 사이에 TCP/IP 커넥션을 맺어야 한다.

URL은 그 리소스를 가지고 있는 장비에 대한 IP 주소를 알려줄 수 있다.

1.8 웹의 구성요소

1.8.1 프락시

클라이언트와 서버 사이에 위치함

클라이언트의 모든 HTTP 요청을 받아 서버에 전달

사용자를 대신해서 서버에 접근함

주로 보안을 위해 사용되고, 요청과 응답을 필터링 함.

1.8.2 캐시

웹 캐시와 캐시 프락시는 자신을 거쳐 가는 문서들 중 자주 찾는 것의 사본을 저장해 두는, 특별한 종류의 HTTP 프락시 서버다.

클라이언트는 멀리 떨어진 웹 서버보다 근처의 캐시에서 훨씬 더 빨리 문서를 다운 받을 수 있다.

1.8.3 게이트웨이

다른 서버들의 중개자로 동작하는 특별한 서버.

주로 HTTP 트래픽을 다른 프로토콜로 변환하기 위해 사용.

언제나 스스로 진짜 서버인 것 처럼 요청을 다룬다.

1.8.4 터널

두 커넥션 사이에서 날 (raw) 데이터를 열어보지 않고 그대로 전달해주는 HTTP 애플리케이션.

HTTP 터널은 주로 비 HTTP 데이터를 하나 이상의 HTTP 연결을 통해 그대로 전송해주기 위해 사용된다.

1.8.5 에이전트

사용자를 위해 HTTP 요청을 만들어주는 클라이언트 프로그램

웹 요청을 만드는 애플리케이션은 뭐든 HTTP 에이전트다.