밖에 장마가 시작되어 빗줄기가 엄청나게 굵은 것들이 막~ 떨어지고 있습니다. 무섭군요 ;;
HTTP란 카테고리를 처음부터 만들어 놓았지만 아직 포스트를 못하고 있었던건 요즘 제가 읽고 있는 HTTP의
원서를 번역해서 올리려고 하다보니 다른것도 포스트 해야하고 번역하면서 저또한 스터디를 하기때문에 좀 늦게
포스트 하게되었습니다.
하지만 저자가 전달하려 했던 것을 하나라도 놓치지 않기위해 노력했으며, 혹시 내용중에 오류나
잘못된 곳이 있으면 알려주세요.

Overview of HTTP
세계의 웹브라우져들과 서버들 그리고 관련된 모든 웹 어플리케이션들이 HTTP(the HyperText Transfer Protocol)를 통해 각각의 대화를 하고 있다.HTTP는 현대 글로벌 인터넷의 일반적인 언어이다. 이번 챕터는 HTTP에 대해서 간략하게 알아볼것이다. 당신은 웹 어플리케이션들이 HTTP를 사용해 통신하는 방법을 보게될 것이다. 그리고 어떻게 HTTP가 작동하는지에 대해서도 알게 될 것이다. 우리가 알아볼 파트는 다음과 같다.

 - 웹 클라이언트와 서버가 통신하는 방법
 - 리소스들(웹 컨텐츠) 이 어디로 부터 오는지
 - 웹 트랜잭션이 작동하는 방법
 - HTTP 통신을 위한 사용될 메세지 형식
 - TCP 계층의 이해
 - HTTP 프로토콜의 다양한 변화들

HTTP : The Internet's Multimedia Courier
10억개의 이미지들과 html페이지들, 텍스트 파일들, MPEG 파일들, 음악파일들, 자바 애플릿 등이 각각 매일 인터넷을 통해 전달된다. HTTP는 서버로부터 이러한 정보을 빠르고, 편리하고, 믿을수있게 사용자의 웹브라우져에게 전달한다. 왜냐하면 HTTP는 믿을수 있는 데이터 전송 프로토콜을 사용하기 때문이고, 당신의 데이터가 손상을 입지않는 것을  보장한다. 이것은 유저인 당신에게 좋은것이다. 왜냐하면 당신은 이것이 완전무결하게 걱정없이 정보를 엑세스 할 수 있기 때문이다.

믿을 수 있는 전송(Reliable transmission)은 인터넷 어플리케이션 개발자인 당신에게도 좋은것이다. 왜냐하면 당신은 HTTP통신에 대해서 데이터가 파괴되거나, 중복되거나, 전송중에 에러에 걱정하지 않아도 되기 때문이다. 당신은 그저 걱정없이 당신의 어플리케이션을 프로그래밍하면 된다.

Web Clients and Servers
웹 컨텐츠들은 웹서버들이 가지고 있다. 웹서버들은 HTTP 프로토콜로 대화를 한다. 그래서 웹서버들은 종종 HTTP서버라고 불려진다. HTTP서버는 인터넷의 데이터를 저장하고 있고 이를 HTTP클라이언트에 의해 요청될때 제공한다. 클라이언트가 서버에게 HTTP 요청을하고, 서버는 HTTP응답을 반환한다.

당신은 아마도 매일 HTTP클라이언트를 사용하고 있을 것이다. 가장 일반적인 클라이언트는 MS사의 인터넷익스플로어 또는 넷스케이프와 같은 웹브라우져이다.
웹브라우져는 서버로부터 HTTP오브젝트를 요청하고 당신이 보는 화면에 그 오브젝트를 보여준다. 당신이 어느 웹페이지를 볼때, http://www.oreilly.com/index.html과 같이, 브라우져는  www.orailly.com 서버에게 HTTP요청을 한다. 서버는 요청된 오브젝트를 서버에서 찾고(이경우 "/index.html"), 존재한다면, 클라이언트에게 HTTP응답을 오브젝트의 타입, 오브젝트의 길이, 기타 정보들을 담은 오브젝트로서 전달된다.

Resources
웹 리소스들(사진파일, 텍스트파일 등등)은 웹서버들이 가지고 있다. 이러한 웹 리소스들이 웹컨텐츠(html파일등)의 자료가 된다. 가장 간단한 웹리소스는 웹서버의 파일시스템들의 정적파일(static file)들이다. 이러한 파일들은 어떠한것들이 될 수 있다. 텍스트, HTML, 워드파일, 아크로뱃파일, JPEG파일, AVI파일 등등 당신이 생각하는 어떠한 포맷도 될수 있다.

그러나, 리소스들은 정적파일이 되어서는 안된다. 리소스들은 요청으로 생성된 컨텐츠를 가지는 소프트웨어 프로그램이 될 수 있다. 이러한 다이나믹한 컨텐츠 리소스들은 당신의 생각을 기반으로 컨텐츠들을 생성할수 있고, 당신이 요청했던 정보를 가지고도 생성할 수 있다. 또한 카메라로부터 움직이는영상을 보여줄 수도 있고, 주식현황도 볼 수 있고, 온라인상점으로부터 선문을 살 수도 있다.
요약하면, 리소스는 컨텐츠를 구성하는 소스가 아니다. 당신회사의 예상판매액의 스프레드쉬트가 담긴 파일이 리소스이다. 인터넷 검색엔진이 리소스이다.

Media Types
인터넷 호스트들은  수천개의 서로다른 데이터 타입을 가지고있기 때문에, HTTP는 MIME타입이라 불리우는 데이타 포맷라벨을 가지고 웹을 통해 각각의 오브젝트들을 조심스럽게 전송한다. MIME(Multipurpose Internet Mail Extensions)은 원래 서로 다른 전자메일시스템 사이에서 메세지를 보낼때 발생하는 문제를 해결하기 위해 설계되었다. MIME는 HTTP가 자신의 멀티미디어 컨텐츠를 설명하고 명명하기위해 채택되었다. 웹서버는 모든 HTTP 오브젝트 데이터에 MIME타입을 붙였다.

웹브라우져가 서버로부터 돌아온 오브젝트를 받을때, 웹브라우져는 오브젝트를 핸들링할 방법을 알아보기 위해 MIME타입과 관련시켜 찾아보게 된다.대부분의 브라우져들이 수백의 알려진 오브젝트타입을 핸들링 할 수 있다.
이미지 파일을 보여주고, HTML파일들을 파싱하고 포맷팅하고, 오디오 파일을 재생하고,특별한 포맷을 핸들링하기 위해 외부 플러그인 소프트웨어를 설치한다.텍스트기반의 MIME타입은 중요한 오브젝트 타입이고 슬래시(/)로 구분되어지는  분명한 서브타입이다.
예를 들면

HTML형식의 텍스트문서는 text/html 라는 라벨이 붙는다.
아스키형식의 텍스트문서는 text/plain 라는 라벨이 붙는다.
JPEG버전의 이미지는 image/jpeg 라는 라벨이 붙는다.
GIF버전의 이미지는 image/gif 라는 라벨이 붙는다.
애플사의 퀵타임 동영상은 video/quicktime 라는 라벨이 붙는다.

URIs
각 웹서버 리소스들은 이름을 가지고 있다. 그래서 클라이언트들은 자신들이 필요로하는 리소스가 무엇인지를 집어낼 수 있다. uniform resource identifier 라고 불리는 (또는 URI라 불리는) 서버 리소스 이름이 있다. URI는 인터넷의 우편주소와도 같은 것이다. URI는 두개의 속성을 갖는다. URLs와 URNs가 그것이다.

URLs
URL(uniform resource locator)는 가장 일반적인 구분자 리소스의 형태이다. URL은 특정서버의 리소스의 정확한 위치를 알려준다. URL은 당신에게 고정된 위치로부터   리소스를 불러오는 방법을 확실하게 알려줄 것이다. URL은 세개의 주요한 파트를 가지고 있다.(ex, http://www.joes-hardware.com/specials/saw-blade.gif)
스키마라고 불리는 URL의 첫번째 부분이고, 리소스에 접근하기 위해 사용되는 프로토콜을 설명한다. 이것은 일반적으로 HTTP프로토콜이 담당한다. (http://)
두번째 부분은 서버의 인터넷 주소이다.(e.g., www.joes-hardware.com)
세번째 부분은  웹서버의 리소스이다.(e.g., /specials/saw-blade.gif)

URNs
URI의 두번째 부분은 URN이다. URN은 위치 독립성을 가진 자원인 컨텐츠의 일부를 위해 유일한 이름을 제공한다. 이러한 위치독립성을 가진 URN은 한곳에서 다른한곳으로 자원이 이동하는것을 허락한다. URN은 또한 같은 이름으로 멀티 네트워크 엑세스에 의해 자원이 재사용되는 것을 허락한다.URN은 아직까지는 폭넓게 적용되지 않았고 실험적 단계이다. 효과적으로 일하기 위해, URN은 resource locations를 해결하기 위해 단체의 지지가 필요하다. 이러한 단체의 부족은 URN의 적용이 느린것에 기인한다. 우리는 URN에 대해서 2장에서 좀더 심도있게 논의할 것이다.

Transactions
자 이제 웹서버와 웹서버의 자원들을 클라이언트가 HTTP를 사용해 어떻게 처리하는지 자세하게 알아보자. HTTP트랜잭션은 요청명령(request command)과 응답결과(response result)로 이루어져 있다. 이러한 통신은 HTTP메세지라 불리우는 정형화된 블럭데이터로이뤄진다.

Methods
HTTP는 HTTP메소드라 불리우는 여러개의 요청명령(request command)들을 지원한다. 모든 HTTP 요청메세지는 메소드를 가지고 있다. 이 메소드는 서버에게 어떤종류의 액션인지를 알려준다.
GET : 서버에서 클라이언트에게 명명된 자원을 보내라
PUT : 클라이언트로 부터 온 데이터를 명명된 서버의 자원속에 저장하라
DELETE : 서버로부터 명명된 자원을 삭제하라
POST : 클라이언트 데이터를 서버 게이트웨이 어플리케이션으로 보내라
HEAD : 명명된 자원을 위한 응답의 HTTP헤더를 보내라
우리는 3장에서 HTTP메소드들을 자세히 논의할 것이다.

Status Codes
모든 HTTP 응답메세지는 상태코드값을 가지고 돌아온다. 상태코드는 클라이언트에게 알려줄 세자리의 숫자이다. 몇개의 일반적인 상태코드는 아래와 같다.
200 : 정확하게 document가 리턴되었다.
302 : Redirect
404 : 자원을 찾을 수 없다.
HTTP는 또한 설명을 위한 "이유구문(reson phrase)"을 상태코드와 함께 보낸다. 이유구문은 오직 설명을 목적으로 포함되어있다.
HTTP 상태코드는 3장에서 자세히 다룰 것이다.

Web pages Can Consist of Multiple Objects
어플리케이션은 종종 일을 처리하기위한 다중 HTTP 트랜잭션에 대해서 이야기한다. 예를들어, 웹브라우져는 그래픽이 많이 포함된 웹페이지를 가져오고 보여주기 위한 HTTP 트랜잭션의 수행이 이슈화된다. 브라우져는 페이지 레이아웃을 설명하는 "스켈레톤 skeleton) HTML을 가져오기 위해 하나의 트랜잭션을 수행하고, 각각의 첨부된 이미지와 그래픽, 자바 애플릿 등을 위한 HTTP 트랜잭션을 추가적으로 수행한다. 이러한 첨부된 자원들은 심지어는 다른 서버에도 존재한다.그러므로 "웹페이지"는 자원의 집합이고 하나의 자원이 아니다.

Messages
자, HTTP 요청과 응답메세지의 구조를 간단하게 보자. 우리는 HTTP메세지를 3장에서 자세히 공부할 것이다. HTTP메세지는 줄단위의 문자 시퀀스로 이루어진 단순구조이다. 때문에 HTTP메세지는 쉬운 텍스트(바이너리가 아닌)이고, 사람들이 쉽게 읽고 쓸수 있다.웹클라이언트로부터 웹서버에게 보내진 HTTP메세지는 요청메세지라 불리운다. 서버로부터 클라이언트로 보내진 메세지는 응답메세지라 불리운다.다른 종류의 HTTP메세지는 없다. HTTP 요청,응답메세지는 매우 간단하다. HTTP메세지는 세개의 부분으로 되어있다.
Start line
메세지의 첫번째로 시작라인이고, 요청을 위해 무엇을 해야하는지를 알려주거나 응답을 위해 어떤일이 발생하는지 알려준다.
Header fields
시작라인의 다음인 0 또는 그 이상의 갯수를 가진 헤더필드이다. 각 헤더필드는 이름과 값을 가지고 콜론(:)으로 구분되어져 쉽게 파싱할 수 있다.헤더필드는 하나의 빈 라인을 줌으로써 끝낸다. 헤더필드를 추가할때는 쉽게 다른 라인을 추가하면 된다.
Body
빈라인뒤는 어떠한 종류의 데이터도 포함할 수 있는 body메세지부분이다. 요청body는 웹서버로엑 데이터를 보낸다. 응답body는 클라이언트에게 데이터를 되돌려 보낸다. 시작라인과 헤더와는 달리, body는 바이너리 데이터(e.g., 이미지, 비디오, 오디오 트랙, 소프트웨어 어플리케이션)를 포함할 수 있다. 물론 텍스트도 포함할 수 있다.

Connections
지금 우리는 HTTP의 메세지가 어떻게 생겼는지 봐왔다. 이제는 한곳에서 다른 한곳으로 메세지가 어떻게 TCP를 통해 이동하는지에 대해서 이야기 해보자.

posted by blankus