웹과 HTTP
07 Mar 2019목차
1. 하이퍼텍스트와 웹
- 1.1 하이퍼텍스트와 웹의 역사
- 1.2 웹의 주요 기능적 구성 요소
- 1.3 웹 서버와 웹 브라우저
2. HTTP와 클라이언트
- 2.1 HTTP 버전
- 2.2 HTTP URL
- 2.3 HTTP 메세지
- 2.4 HTTP 메소드
- 2.5 HTTP 상태 코드와 이유 구문
- 2.6 HTTP 헤더
참고문헌
1. 하이퍼텍스트와 웹
1.1 하이퍼텍스트와 웹의 역사
웹은 1989년 제네바에서 열린 CERN에서 시작한다. CERN은 방대하고 복잡하며, 오랜 시간이 걸리는 프로젝트들을 진행했는데, 연구자 중 한 명인 팀 버너스 리(Tim Berners-Lee)가 전자적으로 연결된 문서의 웹을 구성하여 소통을 하고자 했다. 팀 버너스 리와 다수의 개발진들에 의해 TCP/IP 기반의 HTTP가 탄생하고 HTML과 URL 등의 개념과 요소가 개발되었다.
이후 HTTP와 웹은 지속적으로 발전하여 넷스케이프 등의 브라우저의 등장으로 GUI 기반으로 웹을 이용하게 되었고, 단순 텍스트 뿐 아니라 미디어도 활용가능하게 되었다.
1.2 웹의 주요 기능적 구성 요소
- HTML
HTML(HyperText Markup Language)은 웹 페이지를 구조화하는 마크업 언어이다. 웹 페이지의 설계도 역할을 한다. HTML은 한 문서에서 다른 문서로 연결을 가능하게 하고, 미디어 타입과 특별한 데이터를 일정한 형식을 갖춰 문서에 추가하기 위해 일반적인 텍스트 문서에 태그라고 불리는 간단한 구조물을 더한다. - HTTP
HTTP(HyperText Transfer Protocol)는 웹에서 상호간 통신을 하기 위한 약속들의 모음이다. 내가 연인에게 편지를 보내기 위해서는 편지봉투에 주소를 쓰고, 우편번호를 쓰고, 우표를 붙이고, 우체통에 편지를 넣어야 한다. 만약 주소가 잘못되었거나 우표 가격이 적절하지 않으면 편지는 보내지지 않는다. HTTP는 이와 유사하게 클라이언트와 서버가 통신할 수 있도록 통신 방법 등에 대해 약속한 것이다. HTTP는 클라이언트와 서버 간 하이퍼텍스트 문서와 다른 파일 전송을 가능하게 함으로써 웹을 구현하는 TCP/IP 어플리케이션 계층의 프로토콜이다. - URI
URI(Uniform Resource Identifier)는 편지봉투에 적는 주소의 역할을 한다. URI는 인터넷상의 자원을 식별하는 표시로, 하이퍼텍스트 문서를 찾아서 읽기 위한 수단으로 개발되었다.
1.3 웹 서버와 웹 브라우저
웹 서버는 클라이언트가 하이퍼텍스트 문서 및 기타 파일을 요청하면 해당 파일들을 클라이언트에게 자동으로 제공하는 소프트웨어 또는, 그것이 구동되는 컴퓨터다. 웹 서버는 도서관 사서와 같다. 사서에게 책을 요청하면 사서는 책을 찾아서 준다. 웹 서버는 클라이언트가 요청하는 정보를 제공하는 역할을 한다.
웹 브라우저는 웹 서버를 통해 웹 문서 및 기타 파일에 접근하기 위해서 TCP/IP 클라이언트 컴퓨터에서 사용하는 HTTP 클라이언트 소프트웨어 프로그램이다. 브라우저는 하이퍼텍스트 문서에 접근해 해당 문서를 출력한다. 캐시 등의 고급 기능들을 지원한다. 이미지 파일을 표시하거나 영상을 재생하고, 대화형 프로그램을 구현하기도 한다.
2. HTTP
HTTP 프로토콜은 앞서 설명한 바와 같이 클라이언트와 서버가 주고 받는 메세지의 내용이나 순서를 정하는 약속이다. HTTP 프로토콜은 아래 그림과 같이 작동하도록 약속한 것이다.
2.1 HTTP 버전
HTTP의 버전은 0.9에서부터 1.0, 1.1 순서로 발전해 왔다.
- HTTP/0.9
HTTP/0.9는 최초의 버전으로, 공식 버전은 아니다. 하이퍼텍스트만 송신 가능하며 클라이언트가 가져올 자원의 정보를 GET 요청할 수 있도록 작성 되었다. 기능이 극히 제한적이어서 클라이언트와 서버 간 지능적인 정보 교환은 거의 불가능했다. - HTTP/1.0
HTTP의 첫 표준으로 HTTP에 대한 완전한 메세지 형태를 기술하고 어떻게 클라이언트의 요청과 서버의 응답을 사용하는지 설명했다. 하이퍼텍스트 문서 뿐 아니라 다양한 미디어를 취급할 수 있게 되었다. MIME으로부터 헤더 구조를 차용했다. 사이트 하나 당 하나의 서버가 필요하다는 점, 하나의 HTTP 세션이 하나의 클라이언트 요청만 처리할 수 있다는 점, 캐싱(Caching), 프록싱(Proxing), Partial Resource Retrieval 등이 불가능하다는 점 등은 단점으로 꼽힌다. - HTTP/1.1
앞선 1.0 버전의 단점으로 지목되었던 부분들을 해결하였다. 다중 호스트네임을 지원하여 하나의 서버에서 수십 수천개의 가상 호스트에 대한 요청을 다룰 수 있게 되었다. 캐싱, 프록싱, Partial Resource Retrieval 등이 가능해졌다. 기존 HTTP에 비해 보안이 향상되었다. 지속적 연결을 지원하여 클라이언트가 하나의 TCP 세션에서 다수의 요청을 보낼 수 있게 되었다.2.2 HTTP URL
HTTP URL은 아래와 같이 구성된다.
일반적으로 user와 password는 잘 쓰이지 않는다. port는 80번이 기본이며, 8080은 자주 사용되는 대체 포트다. DNS명은 대소문자 구분이 없지만 url-path는 대소문자를 구분한다. params와 query는 웹 서버에 추가적인 질의나 정보를 넘기기 위해 사용되는데, HTTP POST로 대체 가능하다.2.3 HTTP 메세지
2.4 HTTP 메소드
- GET
GET 메소드는 서버가 HTTP 요청(Request) 라인에 포함된 URL이 지정하는 자원을 찾아 클라이언트에게 전송하게 한다. If-Modified-Since, If-Match 등의 헤더가 포함된 GET 요청을 조건부(Conditional) GET이라고 한다. 또, Range 헤더를 포함하는 요청을 부분적인(Partial) GET이라고 한다. - HEAD
HEAD 메소드는 GET 메소드와 유사하지만 실제 메세지 본문은 제외하고 헤더만을 요청하는 메소드이다. - POST
POST 메소드는 클라이언트가 서버에게 데이터를 전송하기 위해 사용하는 메소드이다. 주로 대화형 HTML 폼(Form)과 같은 정보를 서버 내 프로그램으로 보내는 데 사용된다. - OPTIONS
OPTIONS 메소드는 클라이언트가 이용 가능한 통신 옵션에 대한 정보를 서버에 요청하는 경우에 사용된다. 이 메소드에 대한 응답은 서버에 어떻게 접속할 수 있는지를 알려주는 헤더를 포함한다. - PUT
PUT 메소드는 서버로 하여금 클라이언트가 요청 줄에 지정한 URL에 요청의 본문 내에 있는 실체를 저장하도록 하는 요청이다. PUT에서의 URI는 요청의 실체를 나타내지만, POST에서의 URI는 요청에 포함된 실체를 처리하는 프로그램을 나타낸다는 점에서 차이가 있다. 주로 URI로 지정한 서버의 파일을 실체 내의 파일로 치환한다. URI로 지정한 파일이 서버 내에 없는 경우엔 새로 파일을 작성한다. 주로 웹 어플리케이션 내에서 정보를 업데이트 할 때 사용한다. - DELETE
DELETE 메소드는 서버가 특정한 자원을 지우도록 하는 요청이다. - TRACE
TRACE 메소드는 클라이언트가 서버에 보낸 요청의 복사본을 돌려받도록 한다. 주로 테스트 용도로 사용된다.2.5 HTTP 상태 코드와 이유 구문
상태 코드와 이유 구문은 매우 다양하지만 여기서는 일반적인 몇 가지만 짚어 보고 넘어가도록 한다.
| 상태 코드 형식 | 의미 | 설명 |
|---|---|---|
| 1XX | 정보 제공 메세지 | 일반적인 정보를 제공하며 성공/실패는 표시하지 않는다 |
| 2XX | 성공 | 서버가 메소드를 수신했고 정상적으로 수행했다 |
| 3XX | 리다이렉션 | 요청이 완전히 실패한 것은 아니나, 성공을 위해서는 추가적인 행동이 필요하다 |
| 4XX | 클라이언트 에러 | 요청이 잘못되었거나, 구문 오류가 있거나 클라이언트 오류로 요청 수행을 완료할 수 없다 |
| 5XX | 서버 에러 | 요청은 유효하지만 서버 자체의 문제로 처리할 수 없다 |
먼저 “200 OK”는 요청 성공을 의미한다. 다음으로 “401 Unauthorized”는 클라이언트에 해당 자원에 접근할 권한이 없음을 의미한다. 가장 흔한 “404 Not Found”는 서버가 자원을 찾을 수 없다는 의미다.
2.6 HTTP 헤더
- 일반 헤더
일반 헤더는 담고 있는 내용에 대한 것이 아니라 메세지 자체에 대한 정보를 전달하는 데 주로 쓰인다. 대표적인 것으로는 Cache-Control 헤더가 있는데 HTTP 요청이나 응답에 대한 캐싱을 수행하는 방법을 관리하는 지시어를 지정한다. 그 외에도 Warning, Connection 등의 헤더가 존재한다. - 요청 헤더
요청 헤더는 HTTP 요청 메세지 내에서만 사용된다. Accept는 클라이언트가 응답으로 어떤 매체 유형을 받아들일지 서버에 알릴 수 있게 하는데, 이 헤더를 지정하지 않으면 서버는 클라이언트가 모든 매체 유형을 수용할 수 있다고 가정한다. Accept-Charset은 어떤 문자 집합을 받기 원하는지 지정한다. Accept-Incoding은 어떤 컨텐츠 인코딩을 수행하는지 나타내며, Accept-Language는 서버가 응답에서 사용하길 기대하는 언어가 어떤 언어인지를 지시하는 언어 태그 목록을 제공한다. Authorization은 클라이언트가 인증 정보를 서버에 제출하기 위해 사용하며 Host는 DNS의 도메인을 이용해 인터넷 호스트를 지정할 때 사용된다. User-Agent는 클라이언트 소프트웨어에 대한 정보를 제공하며, 서버 접속 통계를 기록하고, 서버가 각각의 클라이언트 요구에 맞는 응답을 하는 데 쓰이기도 한다. 그 밖에도 Expect, From, If-Match, Range 등이 존재한다. - 응답 헤더
서버나 중간 장비가 보내는 HTTP 응답에서만 나타난다. Accept-Range는 서버가 Range 요청 헤더를 사용한 부분적인 컨텐츠 요청을 받아들였는지, 어떤 유형을 받아들였는지에 대한 정보를 클라이언트에 전달한다. Location은 클라이언트가 처음 요청한 URL 대신 사용할 새로운 URL을 표시한다. 301, 302, 307 응답으로 서버가 클라이언트의 요청을 새로운 위치로 이동시킬 때 사용한다. 그 밖에도 Age, ETag, Proxy-Authenticate, Server 등이 존재한다. - 실체 헤더
HTTP 메세지 내 본문에 실린 자원에 대한 정보를 제공한다. 실체 헤더는 메세지의 수신자에게 실체를 적절히 처리하고 표시하기 위해 필요한 정보를 전달한다. 실체를 가지고 있는 HTTP 메세지는 최소 1개 이상의 실체 헤더를 가지고 있어야 한다. Allow는 특정한 자원이 지원하는 모든 메소드를 나열하고, Content-Encoding은 실체를 인코딩하는 데 쓰였던 방법을 설명한다. Last-Modified는 자원이 마지막으로 변경된 시간을 표시하며, 그 밖에도 Content-Language, Content-Length, Content-Location, Content-MD5, Content-Type 등이 있다.