하이퍼텍스트 트랜스퍼 프로토콜(HTTP)는 HTML과 같은, 하이퍼미디어 문서 전송을 위한 응용-계층 프로토콜입니다. HTTP는 웹 브라우저와 웹 서버 사이의 통신을 위해 설계되었지만 다른 목적을 위해서도 사용될 수 있습니다. 이 프로토콜은 연결을 열고, 요청을 보낸 뒤 응답을 받을 때까지 대기하는 클라이언트를 이용하는 고전적인 클라이언트-서버 모델을 따릅니다. 또한 상태없는 프로토콜로, 이는 두 개의 요청 사이에 어떤 데이터(상태)도 서버가 유지하지 않는다는 것을 의미합니다. 종종 TCP / IP 계층을 기반으로 하지만, 모든 안정적인 전송 계층에서 사용할 수 있습니다. UDP처럼 메시지를 묵시적으로 손실하지 않는 프로토콜입니다.
간단한 요청과 응답 예
요청
GET /restapi/v1.0 HTTP/1.1
Accept: application/json
Authorization: Bearer UExBMDFUMDRQV1MwMnzpdvtYYNWMSJ7CL8h0zM6q6a9ntw
응답
HTTP/1.1 200 OK Date: Mon, 23 May 2005 22:38:34 GMT Content-Type: text/html;
charset=UTF-8 Content-Encoding: UTF-8 Content-Length: 138 Last-Modified: Wed, 08
Jan 2003 23:11:55 GMT Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux) ETag:
"3f80f-1b6-3e1cb03b" Accept-Ranges: bytes Connection: close
<html>
<head>
<title>An Example Page</title>
</head>
<body>
Hello World, this is a very simple HTML document.
</body>
</html>
HTTP Messages
HTTP/1.1은 text형식으로 되어 있기 떄문에 읽을 수 있다. HTTP/2는 Binary형식으로 임베드되어, 헤더의 압축과 다중화같은 최적화를 가능케 한다. 본래의 HTTP 메시지의 일부분만이 HTTP의 이 버전 내에서 전송된다고 할지라도, 각 메시지의 시맨틱들은 변화하지 않으며 클라이언트는 본래의 HTTP/1.1 요청을 (가상으로) 재구성한다. 그러므로 HTTP/1.1 포맷 내에서 HTTP/2를 이해하는 것은 여전히 유용하다.
HTTP 메시지의 두 가지 타입 request와 response이 있다.
Request
Response
응답 코드
| 코드 | 메시지 | 설명 |
|---|---|---|
| 1XX | Informational(정보) | 정보 교환. |
| 2XX | Success(성공) | 데이터 전송이 성공적으로 이루어졌거나, 이해되었거나, 수락되었음. |
| 3XX | Redirection(방향 바꿈) | 자료의 위치가 바뀌었음. |
| 4XX | Client Error(클라이언트 오류) | 클라이언트 측의 오류. 주소를 잘못 입력하였거나 요청이 잘못 되었음. |
| 5XX | Server Error(서버 오류) | 서버 측의 오류로 올바른 요청을 처리할 수 없음. |
자세한 내용은 (https://ko.wikipedia.org/wiki/HTTP#%EC%9D%91%EB%8B%B5_%EC%BD%94%EB%93%9C) 참고.
요약표
| HTTP 메소드 | RFC | 요청에 Body가 있음 | 응답에 Body가 있음 | 안전 | 멱등(Idempotent) | 캐시 가능 |
|---|---|---|---|---|---|---|
| GET | RFC 7231 | 아니오 | 예 | 예 | 예 | 예 |
| HEAD | RFC 7231 | 아니오 | 아니오 | 예 | 예 | 예 |
| POST | RFC 7231 | 예 | 예 | 아니오 | 아니오 | 예 |
| PUT | RFC 7231 | 예 | 예 | 아니오 | 예 | 아니오 |
| DELETE | RFC 7231 | 아니오 | 예 | 아니오 | 예 | 아니오 |
| CONNECT | RFC 7231 | 예 | 예 | 아니오 | 아니오 | 아니오 |
| OPTIONS | RFC 7231 | 선택 사항 | 예 | 예 | 예 | 아니오 |
| TRACE | RFC 7231 | 아니오 | 예 | 예 | 예 | 아니오 |
| PATCH | RFC 5789 | 예 | 예 | 아니오 | 아니오 | 예 |
HTTP의 진화
이 섹션은 https://developer.mozilla.org/ko/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP에서 발취했습니다.
1989년 당시 제네바의 CERN에서 일하고 있던 Tim Berners-Lee는 인터넷 상의 하이퍼텍스트 시스템을 만들기 위한 제안을 작성했습니다. 초기에 Mesh라고 불리던 그것은 1990년에 구현 과정에서 월드 와이드 웹으로 이름을 바꿨습니다.
1991년 9월 6일, alt.hypertext 공개 뉴스 그룹의 Tim Berners-Lee의 포스트가 공개 프로젝트로써의 월드 와이드 웹의 공식적인 출발점으로 여겨집니다.
이렇게 초기 단계에 사용되던 HTTP 프로토콜은 매우 간단했으며 이후 HTTP/0.9 버전을 부여했으며 때로는 원-라인 프로토콜로 불리기도 했습니다.
HTTP/0.9
HTTP 초기 버전에는 버전 번호가 없었습니다; HTTP/0.9는 이후에 차후 버전과 구별하기 위해 0.9로 불리게 됐습니다. HTTP/0.9는 극히 단순합니다: 요청은 단일 라인으로 구성되며 리소스에 대한 (프로토콜, 서버 그리고 포트는 서버가 연결되고 나면 불필요로 하므로 URL은 아닌) 경로로 가능한 메서드는 GET이 유일했습니다.
요청
GET /mypage.html
응답
<html>
A very simple HTML page
</html>
HTTP/1.0
HTTP/0.9는 매우 제한적이었으며 브라우저와 서버 모두 좀 더 융통성을 가지도록 빠르게 확장되었습니다:
- 버전 정보가 각 요청 사이내로 전송되기 시작했습니다. (
HTTP/1.0이GET라인에 붙은 형태로) - 상태 코드 라인 또한 응답의 시작 부분에 붙어 전송되어, 브라우저가 요청에 대한 성공과 실패를 알 수 있고 그 결과에 대한 동작(특정 방법으로 그것의 로컬 캐시를 갱신하거나 사용하는 것과 같은)을 할 수 있게 되었습니다.
- HTTP 헤더 개념은 요청과 응답 모두를 위해 도입되어, 메타데이터 전송을 허용하고 프로토콜을 극도로 유연하고 확장 가능하도록 만들어주었습니다.
- 새로운 HTTP 헤더의 도움으로, 평이한 HTML 파일들 외에 다른 문서들을 전송하는 기능이 추가되었습니다(
Content-Type덕분에).
요청
GET /mypage.html HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)
응답
200 OK Date: Tue, 15 Nov 1994 08:12:31 GMT Server: CERN/3.0 libwww/2.17
Content-Type: text/html
<html>
A page with an image
<img src="/myimage.gif" />
</html>
두 번재 커넥션에 의한 이미지를 내려받기 위한 요청과 그에 대한 응답입니다:
GET /myimage.gif HTTP/1.0 User-Agent: NCSA_Mosaic/2.0 (Windows 3.1) 200 OK Date:
Tue, 15 Nov 1994 08:12:32 GMT Server: CERN/3.0 libwww/2.17 Content-Type:
text/gif (image content)
HTTP/1.1 - 표준 프로토콜
HTTP의 첫번째 표준 버전인 HTTP/1.1은 HTTP/1.0이 나온지 몇 달 안되서 1997년 1월에 RFC 2068에서 처음 공개되었습니다.
HTTP/1.1은 모호함을 명확하게 하고 많은 개선 사항들을 도입했습니다:
- 커넥션이 재사용될 수 있게 하여, 탐색된 단일 원본 문서 내로 임베드된 리소스들을 디스플레이하기 위해 사용된 커넥션을 다시 열어 시간을 절약하게 하였습니다.
- 파이프라이닝을 추가하여, 첫번째 요청에 대한 응답이 완전히 전송되기 이전에 두번째 요청 전송을 가능케 하여, 커뮤니케이션 레이턴시를 낮췄습니다.
- 청크된 응답 또한 지원됩니다.
- 추가적인 캐시 제어 메커니즘이 도입되었습니다.
- 언어, 인코딩 혹은 타입을 포함한 컨텐츠 협상이 도입되어, 클라이언트와 서버로 하여금 교환하려는 가장 적합한 컨텐츠에 대한 동의를 가능케 했습니다.
Host헤더 덕분에, 동일 IP 주소에 다른 도메인을 호스트하는 기능이 서버 코로케이션을 가능케 합니다.
다음은 하나의 단일 커넥션을 통한 요청의 전형적인 전체 흐름의 예시입니다:
GET /en-US/docs/Glossary/Simple_header HTTP/1.1 Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101
Firefox/50.0 Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language:
en-US,en;q=0.5 Accept-Encoding: gzip, deflate, br Referer:
https://developer.mozilla.org/en-US/docs/Glossary/Simple_header
200 OK Connection: Keep-Alive Content-Encoding: gzip Content-Type: text/html;
charset=utf-8 Date: Wed, 20 Jul 2016 10:55:30 GMT Etag:
"547fa7e369ef56031dd3bff2ace9fc0832eb251a" Keep-Alive: timeout=5, max=1000
Last-Modified: Tue, 19 Jul 2016 00:59:33 GMT Server: Apache Transfer-Encoding:
chunked Vary: Cookie, Accept-Encoding (content)
GET /static/img/header-background.png HTTP/1.1 Host: developer.cdn.mozilla.net
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101
Firefox/50.0 Accept: */* Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip,
deflate, br Referer:
https://developer.mozilla.org/en-US/docs/Glossary/Simple_header
200 OK Age: 9578461 Cache-Control: public, max-age=315360000 Connection:
keep-alive Content-Length: 3077 Content-Type: image/png Date: Thu, 31 Mar 2016
13:34:46 GMT Last-Modified: Wed, 21 Oct 2015 18:27:50 GMT Server: Apache (image
content of 3077 bytes)
HTTP/2
HTTP/2 프로토콜은 HTTP/1.1 버전과 다른 몇가지 근본적인 차이점을 가지고 있습니다:
- 텍스트 프로토콜이라기 보다는 이진 프로토콜입니다. 더 이상 읽을 수도 없고 수작업을 만들어낼 수 없습니다; 이런 결점에 대한 보상으로, 새로운 최적화 기술이 구현될 수 있습니다.
- 병렬 요청이 동일한 커넥션 상에서 다루어질 수 있는 다중화 프로토콜로, 순서를 제거해주고 HTTP/1.x 프로토콜의 제약사항을 막아줍니다.
- 전송된 데이터의 분명한 중복과 그런 데이터로부터 유발된 불필요한 오버헤드를 제거하면서, 연속된 요청 사이의 매우 유사한 내용으로 존재하는 헤더들을 압축시킵니다.
- 서버로 하여금 사전에 클라이언트 캐시를 서버 푸쉬라고 불리는 메커니즘에 의해, 필요하게 될 데이터로 채워넣도록 허용합니다.
2015년 5월에 공식적으로 표준화된, HTTP/2는 큰 성공을 거두었습니다: 2016년 6월, 모든 웹 사이트 중 8.7%[1]가 이미 사용 중에 있고, 이것은 모든 요청의 68%[2] 이상을 나타냅니다. 인터넷 상에서 전송 오버헤드 감소로 많은 돈을 절약하는 높은 트래픽의 웹 사이트들은 이 프로토콜을 급속히 받아들이고 있습니다.
이러한 급격한 채택은 HTTP/2가 웹 사이트와 애플리케이션의 채택이 필요하지 않았기에 가능했습니다: HTTP/1.1을 사용할지 HTTP/2를 사용할지 고민할 필요가 없어졌습니다. 최신 브라우저와 통신하는 최신의 서버를 갖는 것은 프로토콜 사용을 활성화하는 것만으로 충분합니다: 어느 정도의 제한된 액터 세트만이 HTTP/2 채택을 불러일으키는데 필요했으며 브라우저와 서버 버전이 교체됨에 따라, 웹 개발자의 투입없이도 HTTP/2의 사용은 자연스럽게 증가했습니다.
오늘날 HTTP가 사용되는 환경은 1990년 초에 상상하던 것과는 완전히 다릅니다. HTTP 본래의 설계가 걸작이 되었음을 지난 25년 넘게 호환되지 않는 진화의 요구없이 웹을 진화시킴으로 증명했습니다. 25년 넘게 HTTP의 성공을 만들어 온 유연함과 확장성을 유지하는 동시에, 수년 넘게 밝혀진 많은 결함들을 수정한 덕택에, HTTP/2의 등장은 프로토콜에 대한 밝은 미래를 암시하는 것처럼 보입니다.