HTTP 웹의 기초

본 포스팅은 'O'REILLY HTTP 완벽가이드' 도서의 내용을 정리한 내용입니다.

 

 

웹 클라이언트, 웹 서버 그리고 리소스 

- 클라이언트(웹브라우저)는 서버에게 HTTP 요청을 보내고, 서버는 요청된 데이터를 HTTP 응답으로 돌려준다. 

- 서버는 요청받은 객체를 찾고, 성공했다면 그것의 타입, 길이 등의 정보와 함께 HTTP 응답에 실어서 클라이언트에게 보낸다.

 

- 리소스 : 웹 서버 파일 시스템의 단순한 정적파일 & 동적파일

- 웹 서버는 모든 HTTP 데이터에 MIME(Multipurpose Internet Mail Extensions) 타입을 붙인다. 

- 웹 브라우저는 서버로부터 객체를 돌려받을 때, 다룰 수 있는 객체인지 MIME 타입(text/html, image,jpeg 등)을 통해 확인한다. 

- URI(Uniform Resource Identifier)  웹 서버 리소스의 식별자로 URL과 URN이 있다. 

- URL(Uniform Resource Locator) : 리소스 식별자의 가장 흔한 형태. 리소스가 어디에 있고, 어떻게 접근할 수 있는지 분명히 알려준다. 보통 세 부분으로 이루어진 표준 포맷을 따른다. 통상적인 관례는 URI와 URL을 같은 의미로 사용한다. 

- URN(Uniform Resource Name) : 리소스의 위치에 영향 받지 않는 유일무이한 이름. 리소스가 그 이름을 변하지 않게 유지하는 한, 여러 종류의 네트워크 접속 프로토콜로 접근해도 문제 없다. 

 

 

트랜잭션

- 트랜잭션 : 요청 명령 + 응답 결과

- HTTP 메서드 : HTTP는 여러 종류의 요청 명령(HTTP 메서드)을 지원하며 서버에게 어떤 동작이 취해져야 하는지 말해준다. 

- 모든 HTTP요청 메시지는 한 개의 메서드를 갖는다.(GET / PUT / DELETE / POST / HEAD) 

- 상태코드 : 클라이언트에게 요청이 성공했는지 등을 알려주는 세 자리 숫자. 모든 HTTP 응답 메시지는 상태 코드와 함께 반환된다. 

- HTTP는 각 숫자 상태 코드에 텍스트로된 사유구절(reason phrase)도 함께 보낸다. 

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

(ex. 포털 사이트의 광고 영역과 뉴스 영역 등 각각 별개의 HTTP 트랜잭션을 필요로 한다) 

 

 

웹의 구성요소

- 프락시 : 클라이언트와 서버 사이에 위치하여 클라이언트의 모든 HTTP요청을 받아 서버에 전달함. 주로 보안을 위해 사용됨

 

- 캐시 : 많이 찾는 웹페이지를 클라이언트가 가까이에 보관하는 HTTP 창고

 

- 게이트웨이 : 다른 애플리케이션과 연결된 특별한 웹 서버. HTTP 트래픽을 다른 프로토콜로 변환하기 위해 주로 사용됨. 언제나 스스로가 리소스를 갖고 있는 진짜 서버인 것 처럼 요청을 다루며 클라이언트는 자신이 게이트웨이와 통신하고 있음을 알아채지 못함. 

ex) HTTP/FTP 게이트웨이는 FTP URI에 대한 HTTP 요청을 받아들인 뒤, FTP 프로토콜을 이용해 문서를 가져오고, 받아온 문서를 HTTP 메시지에 담아 클라이언트에게 보낸다. 

 

- 터널 : 단순히 HTTP 통신을 전달하기만 하는 특별한 프락시. 두 커넥션 사이에서 raw 데이터를 그대로 전달해주는 HTTP애플리케이션으로, 주로 비HTTP데이터를 하나 이상의 HTTP연결을 통해 그대로 전송해주기 위해 사용된다. HTTP터널로 HTTP가 아닌 다른 데이터를 보낼 수 있다. 

 

- 에이전트 : 사용자를 위해 HTTP 요청을 만들어주는 클라이언트 프로그램. 사용자의 통제 없이 스스로 웹을 돌아다니며 HTTP 트랜잭션을 일으키고 콘텐츠를 받아오는 '스파이더'나 '웹로봇'등의 준지능적 웹클라이언트.

 

 

URL 구성요소

- URL 문법

: <스킴>://<사용자 이름>:<비밀번호>@<호스트>:<포트>/<경로>;<파라미터>?<질의>#<프레그먼트>

: 이 모든 컴포넌트를 가지는 URL은 거의 없고, 보통 스킴,호스트,경로로 구분되어진다. 

http://www.joes-hardward.com/seasonal/index-fail.html 
http(스킴:어떻게)
www.joes-hardward.com(호스트:어디에)
seasonal/index-fail.html(경로:무엇을) 

- 스킴 : 리소스를 가져오기 위해 '어떤 프로토콜'을 사용하여 서버에 접근해야 하는지

- 호스트 : 리소스를 호스팅하는 서버의 호스트 명이나 IP 주소

- 포트 : 리소스를 호출하는 서버가 열어놓은 포트번호

- 경로 : 서버 내 리소스가 서버 어디에 있는지를 가리킴

- 파라미터 : 특정 스킴들에서 입력 파라미터를 기술하는 용도로 사용 key-value 쌍으로 이루어져 있으며 여러개를 가질 수 있음

- 질의 : 스킴에서 애플리케이션(DB 등)에 파라미터를 전달하는데 쓰임. URL의 끝에 "?"로 구분됨

- 프래그먼트 : 리소스의 일부분을 가리키는 이름. URL이 특정 객체를 가리킬 경우 프래그먼트 필드는 서버에 전달되지 않으며 클라이언트에서만 사용한다. URL의 끝에 "#"문자로 구분됨 

 

 

브라우저가 지원하는 URL의 확장 기능

: URL을 입력한 다음이나 입력하고 있는 동안에 자동으로 URL을 확장하여 사용자가 URL을 빠르게 입력하게 도와준다. 

- 호스트 명 확장 : 주소 입력창에 'google'을 입력하면 브라우저는 호스트 명에 자동으로 'www'와 '.com'을 붙여준다. 

- 히스토리 확장 : 과거에 사용자가 방문했던 URL의 기록을 저장하여, 사용자가 URL의 시작부분을 입력했을때 이전에 방문했던 URL의 시작부분과 일치할 경우 해당 URL을 보여준다. 

 

 

URL의 안전한 전송

: 안전한 전송이란 정보가 유실될 위험 없이 URL을 전송할수 있다는 것을 의미

: 사람들이 URL에 이진 데이터나 알파벳 외의 여러 문자도 포함할 수 있어 '이스케이프'라는 기능을 추가하여 안전하지 않은 문자를 안전한 문자로 인코딩 할 수 있게 함 

- 인코딩은 안전하지 않은 문자를 %기호로 시작해, 아스키코드로 표현되는 두 개의 16진수 숫자로 이루어진 '이스케이프'문자로 바꾼다.

- ex) 공백 -> %20, ~ -> %7E 

 

 

HTTP와 HTTPS 스킴

- http : 일반 URL 포맷을 지키는 HTTP스킴. 포트값이 생략되어 있으면 기본값은 80이다.

- https : HTTP의 커넥션의 양 끝단에서 암호화하기 위해 넷스케이프에서 개발한 보안 소켓 계층(Secure Sockets Layer, SSL)을 사용한다는 것을 제외하곤 http스킴과 거의 같다. 문법 또한 HTTP와 같고 기본 포트값은 443이다. 

 

 

HTTP메시지 구조와 문법

: HTTP 메시지는 단순한 줄 단위 텍스트 구조를 갖고 있다.(시작줄+헤더+본문)

- 시작줄 : 무엇을 해야하는지(요청), 무슨 일이 일어났는지(응답)

- 헤더 : key-value로 이루어진 필드. 헤더는 빈 줄로 끝난다. 

- 본문 : 웹 서버로 실어보낼 데이터(요청), 클라이언트가 요청한 데이터(응답). 문자열이며 구조적인 시작줄/헤더와 달리, 본문은 임의의 이진 데이터를 포함 할 수 있다(이미지, 파일 등)

 

: 모든 HTTP메시지는 요청메시지나 응답메시지로 분류된다.

- 요청메시지 : 웹 서버에 어떤 동작을 요구하는 클라이언트의 메시지

<메서드><요청URL><버전>
<헤더>

<엔터티 본문>


GET /test/hi-there.txt HTTP/1.1
Accept: text/*
Host : www.joes-hardward.com

- <메서드> (GET)

 : 클라이언트 측에서 서버가 리소스에 대해 수행해주길 바라는 동작. 'GET', 'POST' 등이 있다.

- <요청URL> (specials/saw-blade.gif)

 : 요청 대상이 되는 리소스를 지칭하는 완전한 URL 혹은 URL의 경로 구성요소

- <버전> (HTTP/1.1)

 : 이 메시지에서 사용 중인 HTTP 버전

- <헤더> (Accept : text/* Host : www.joes-hardward.com)

 : 이름, 콜론(:), 선택적인 공백, 값, CRLF가 순서대로 나타내는 0개 이상의 헤더. 헤더의 목록은 빈 줄(CRLF)로 끝나 헤더 목록의 끝과 엔터티 본문의 시작을 표시한다. HTTP/1.1과 같은 몇몇 버전의 HTTP는 요청이나 응답에 어떤 특정 헤더가 포함되어야만 유효한 것으로 간주한다. 

- <엔터티 본문>  : 위와 같은 GET 요청은 본문(body)이 없다. 

 

- 응답메시지 : 요청의 결과를 클라이언트에게 보여주는 메시지 

<버전><상태코드><사유 구절>
<헤더>

<엔터티 본문>


HTTP/1.1 200 OK
Content-Type : text/plain
Content-Length : 19

Hi! I'm a message!

- <버전> (HTTP/1.1) : 요청 메시지와 같다. 

- <상태코드> (200)

 : 요청 중에 무엇이 일어났는지 설명하는 세 자리 숫자. HTTP명세에 정의되어 있다. 

- <사유 구절> (OK)

 : 숫자로 된 상태 코드의 의미를 사람이 이해할 수 있게 설명해주는 짧은 문구

- <헤더> (Content-Type : image/gif Content-Length : 8572) : 요청 메시지와 같다. 

- <엔터티 본문> : 요청메시지의 본문은 웹 서버로 실어보낼 데이터를 의미하며, 응답 메시지의 본문은 클라이언트로 반환되는 데이터이다. 문자열이며 구조적인 시작줄(버전,상태코드,사유구절)과 헤더와 달리, 본문은 임의의 이진 데이터(이미지,파일 등)를 포함할 수 있다. 

 

HTTP 메서드

: 요청의 시작줄은 메서드로 시작하며, 서버에게 무엇을 해야 하는지 말해준다. HTTP 명세서에 공통 요청 메서드의 집합이 정의되어 있다. 

: 모든 서버가 모든 메서드를 구현한 것은 아니며, HTTP는 쉽게 확장할 수 있도록 설계되어 있기 때문에, 어떤 서버는 그들만의 메서드를 추가로 구현했을 수도 있다. 

메서드	설명	메시지 본문 여부
GET	서버에서 어떤 문서를 가져온다. 가장 흔히 쓰이는 메서드로 HTTP/1.1은 서버가 이 메서드를 구현할 것을 요구한다.	없음
POST	서버가 처리해야 할 데이터를 보낸다. 서버에 입력 데이터를 전송하기 위해 설계되었으며 실제로 HTML 폼을 지원하기 위해 흔히 사용된다. 채워진 폼에 담긴 데이터가 서버로 전송된다.	있음
HEAD	서버에서 어떤 문서에 대해 헤더만 가져온다. 리소스를 가져오지 않고도 그에 대해 타입 등의 정보를 알아낼 수 있고, 응답의 상태 코드를 통해 개체가 존재하는지 확인할 수 있으며, 헤더를 확인하여 리소스가 변경되었는지 검사할 수 있다.	없음
PUT	서버에 요청 메시지의 본문을 저장한다. 서버가 요청의 본문을 가지고 요청 URL의 이름대로 새 문서를 만들거나, 이미 URL이 존재한다면 본문을 사용해서 교체할 수 있게 해준다.	있음
TRACE	메시지가 프락시를 거쳐 서버에 도달하는 과정을 추적한다. 요청 전송의 마지막 단계에 있는 서버는 자신이 받은 요청 메시지를 본문에 넣어 TRACE응답을 되돌려주며, 클라이언트는 자신과 목적지 서버 사이에 있는 모든 HTTP 애플리케이션의 요청/응답 연쇄를 따라가면서 자신이 보낸 메시지가 망가졌거나 수정되었는지, 만약 그렇다면 어떻게 변경되었는지 확인할 수 있다.	없음
OPTIONS	서버가 어떤 메서드를 수행할 수 있는지 확인한다. 웹 서버에게 여러 가지 종류의 지원 범위에 대해 물어보는 도구로 활용된다. 여러 리소스에 대해 실제로 접근하지 않고도 그것들을 어떻게 접근하는 것이 최선인지 확인할 수 있는 수단을 제공한다.	없음
DELETE	서버에서 문서를 제거한다. 서버에게 요청 URL로 지정한 리소스를 삭제할 것을 요청하지만 그 삭제의 수행이 보장되지는 않는다. HTTP 명세는 서버가 클라이언트에게 알리지 않고 요청을 무시하는 것을 허용하기 때문이다.	없음

 

 

상태코드

: 메서드가 서버에게 무엇을 해야 하는지 말해주는 것 처럼, 상태 코드는 클라이언트에게 무슨일이 일어났는지 말해준다. 

: 세 자리 숫자로 된 그들의 코드값을 기준으로 묶이며 종류는 아래와 같다.

전체 범위	정의된 범위	분류
100-199	100-101	정보
200-299	200-206	성공
300-399	300-305	리다이렉션
400-499	400-415	클라이언트 에러
500-599	500-505	서버 에러

- 100-199 : 정보성 상태 코드 

 : HTTP/1.1에서 도입되었으며, 보통은 정보 전송 전 서버가 그 정보를 받아들일 것인지 확인하려고 할때 쓰인다. 그 확인 작업을 최적화하기 위한 의도로 도입된 것이다.

- 200-299 : 성공 상태 코드

 : 클라이언트가 요청을 보냈을때, 그 요청이 성공하면 서버는 대응하는 성공을 의미하는 상태 코드의 배열을 갖고 있으며, 각각 다른 종류의 요청에 대응한다.

 : ex. 200 : 요청한 모든 데이터는 응답 본문에 들어있다. 

         204 : 요청은 받아들여졌으나 서버는 아직 그에 대한 어떤 동작도 수행하지 않았다. 

- 300-399 : 리다이렉션 상태 코드 

 : 클라이언트가 관심있어 하는 리소스에 대해 다른 위치를 사용하라고 말해주거나, 그 리소스의 내용 대신 다른 대안 응답을 제공한다. 

- 400-499 : 클라이언트 에러 상태 코드

 : 클라이언트가 잘못 구성된 요청메시지나 존재하지 않는 URL에 대한 요청 등 서버가 다룰 수 없는 무엇인가를 보낼때 반환되는 상태코드. 404 Not Found 에러가 대표적이다.

- 500-599 : 서버 에러 상태 코드

 : 클라이언트가 올바른 요청을 보냈음에도 서버 자체에서 에러가 발생하는 경우. 클라이언트가 서버의 제한에 걸렸거나 혹은 게이트웨이 리소스와 같은 서버 보조 구성요소에서 발생한 에러 등이 있다. 

 

이 중 가장 흔한 상태 코드는 아래와 같다. 

상태 코드	사유 구절	의미
200	OK	성공. 요청한 모든 데이터는 응답 본문에 들어있다.
401	Unauthorized	사용자 이름과 비밀번호를 입력해야 한다.
404	Not Found	서버는 요청한 URL에 해당하는 리소스를 찾지 못했다.

 

 

어떻게 HTTP 메시지가 TCP(Transmission Control Protocol)커넥션을 통해 이동하는가? 

- HTTP는 애플리케이션 계층 프로토콜로 네크워크 통신의 핵심적인 세부사항에 대해 신경쓰지 않고 TCP/IP에게 그 역할을 맡긴다.

- TCP/IP : TCP와 IP가 층을 이루는 패킷 교환 네트워크 프로토콜의 집합으로, 각 네트워크와 하드웨어의 특성을 숨기고 어떤 종류의 컴퓨터나 네트워크든 서로 신뢰성 있는 의사소통을 하게 해준다. 

- HTTP프로토콜은 TCP 위의 계층, HTTP는 메시지 데이터 전송을 위해 TCP를 사용하고, TCP는 IP 위의 계층으로 IP(PC간의 주소)를 이용해 데이터를 잘라내고, 이어붙이며 데이터를 전송한다. 

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

- HTTP 서버의 IP 주소와 포트번호는URL을 이용해 알아낸다. 

- 웹브라우저가 HTTP를 이용해 서버의 리소스를 사용자에게 보여주기 까지의 순서 

(1) 웹브라우저가 서버의 URL에서 호스트명 추출

(2) 웹브라우저가 서버의 호스트 명을 IP로 변환

(3) 웹브라우저가 URL에서 포트번호 추출

(4) 웹브라우저가 웹 서버와 TCP 커넥션을 맺음

(5) 웹브라우저가 서버에 HTTP 요청을 보냄

(6) 서버가 웹브라우저에게 HTTP 응답을 돌려줌

(6) 커넥션이 닫히면, 웹브라우저가 문서를 보여줌