HTTP의 진화
HTTP/0.9 – 원-라인 프로토콜
HTTP 초기 버전에는 버전 번호가 없었습니다. HTTP/0.9는 이후 버전과 구별하기 위해 0.9로 불리게 되었습니다.
리소스에 대한 경로는 GET이 유일 했으며 HTML 파일 전송만 가능했고 다른 유형의 파일들은 전송할 수 없었습니다. 문제가 발생했을 경우 문제에 대한 내용이 포함된 HTML 파일을 생성 했었습니다.
GET /mypage.html<html>
A very simple HTML page
</html>
HTTP/1.0 – 확장성 만들기
HTTP 요구사항을 충족하고 표준화 하기 위한 HTTP WG 조직이 탄생했고 1996년 HTTP WG는 HTTP에 관련된 사양들을 종합해서 발표 했는데 이를 HTTP/1.0 으로 불렀습니다. 이 때 최초 HTML 버전을 HTTP/0.9 로 명명 했습니다. (RFC 1945)
https://datatracker.ietf.org/doc/html/rfc1945
RFC 1945: Hypertext Transfer Protocol -- HTTP/1.0
The Hypertext Transfer Protocol (HTTP) is an application-level protocol with the lightness and speed necessary for distributed, collaborative, hypermedia information systems. This memo provides information for the Internet community. This memo does not spe
datatracker.ietf.org
- 요청 안에 버전 정보가 포함되어 전송되었습니다, HTTP/1.0 이 GET 라인에 붙은 형태.
- 요청 메서드가 GET, POST, HEAD 세가지로 확장 되었습니다.
- 상태 코드가 추가 되어 응답에 붙어 전송되었습니다.
따라서, 클라이언트는 요청에 대한 성공과 실패를 알 수 있게 되었고 결과에 대한 특정 동작을 할 수 있게 되었습니다.
(예, 특정 방법으로 로컬 캐시를 갱신하거나 사용)을 할 수 있게 되었습니다. - HTTP 헤더 개념은 요청과 응답 둘 다 도입되어, 메타데이터 전송이 가능해졌고, 프로토콜이 극도로 유연하고 확장성이 높아졌습니다.
- Content-Type 덕분에, 일반 HTML 파일들 외에 다른 문서들을 전송할 수 있었습니다.
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/1.1 버전은 1.0 발표 몇달 뒤 1997년 초 발표 되었습니다. 주로 1.0 버전의 모호함을 명확하게 하고 고려하지 못한 부분에 대한 개선에 대한 내용 이였습니다. (RFC 2068)
https://datatracker.ietf.org/doc/html/rfc2068
RFC 2068: Hypertext Transfer Protocol -- HTTP/1.1
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. [STANDARDS-TRACK]
datatracker.ietf.org
연결 상태 유지(영속적 연결, Persisted connection)
HTTP/1.0 에서는 다수의 HTTP 요청이 발생하는 경우 각 요청마다 TCP Handshake 과정을 거치다보니 속도와 성능에 대한 문제가 있었습니다. (이미지 1번째)
HTTP/1.1 에서는 한번 수립한 연결을 재사용하게 설정되어 있습니다. (이미지 2번째) 연결을 끊고 맺는 과정이 없어지어 연결에 대한 부분을 개선할 수 있었습니다. TCP 연결에 대해서는 Connection과 Keep-Alive로 제한하도록 했습니다.
HTTP/2에서는 비표준입니다.
파이프라이닝(pipelining)
파이프라이닝은 클라이언트에서 여러 요청을 보낼때 응답을 기다리지 않고 각 요청들을 먼저 전송하는 방식입니다. (연결 지연 회피). 이론적으로 두개의 HTTP 요청을 하나의 TCP 메시지 안에 포함하여 성능을 향상 시킬수 있었다.
파이프라인으로는 실패한 경우 다시 반복하기 위해서 멱등한 메소드만 가능하다 (GET, HEAD, PUT, DELETE)
이외에도 아래 기능들이 추가되었습니다.
- 청크 전송 인코딩
https://developer.mozilla.org/ko/docs/Web/HTTP/Headers/Transfer-Encoding - 캐시 제어
https://developer.mozilla.org/ko/docs/Web/HTTP/Headers/Cache-Control - 언어, 인코딩 컨텐츠
- 동일 IP 주소에 다른 도메인을 호스트
https://developer.mozilla.org/ko/docs/Web/HTTP/Headers/Host
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.mozilla.org
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의 확장성 덕분에 새로운 헤더와 메서드를 쉽게 만들 수 있었습니다. HTTP/1.1 프로토콜은 HTTP/2가 나오기 전인 1999년 6월에 공개된 RFC 2616과 2014년 6월에 공개된 RFC 7230, RFC 7235 두 번에 걸친 개정을 통해 개선되었고, 이 프로토콜은 15년 넘도록 매우 안정적이었습니다.
https://datatracker.ietf.org/doc/html/rfc2616
https://datatracker.ietf.org/doc/html/rfc7230
https://datatracker.ietf.org/doc/html/rfc7235
HTTPS
1994년 말 Netscape Communications는 기본 TCP/IP 스택을 통해 HTTP를 전송하는 대신에, TCP/IP 스택 위에 추가적인 암호화된 전송 계층인 SSL을 만들었고 SSL 1.0은 대중에게 비공개였지만 SSL 2.0과 후속 버전인 SSL 3.0을 통해 전자 상거래 웹사이트를 만들 수 있었습니다. 이를 위해서 서버와 클라이언트 간에 교환되는 메시지의 신뢰성을 암호화하고 보장했습니다. SSL은 결국 표준화되어 TLS가 되었습니다.
HTTP/2 – 더 나은 성능을 위한 프로토콜
웹이 점점더 복잡성을 가지기 시작하자 HTTP/1.1 으로는 힘든 복잡성과 오버헤드가 발생하기 시작했다.
2010년 구글에서 실험적인 SPDY 프로토콜 구현 하였고 이를 통해 응답성을 증가시키고 중복 데이터 전송 문제 해결하여 HTTP/2 프로토콜의 기반이 되었다.
HTTP/2 는 이진 프로토콜 입니다. HTTP/1.1 텍스트 기반의 아스키 코드와는 다르게 이진으로 읽을수도 수동으로 생성할 수도 없습니다.
다중화 프로토콜로 하나의 TCP 연결에서 여러 요청을 동시에 처리할 수 있습니다. TCP 연결을 Stream, Message, Frame 이라는 단위로 나누어서 처리하도록 했다.
- Stream: 요청과 응답 양방향으로 오가는 논리적 연결 단위. 동시에 여러개 존재 가능
- Message: 하나의 요청과 응답을 구성하는 단위
- Frame: 메시지를 구성하는 최소 단위, 쪼개어 전송하기 떄문에 수신측에서 조립하여 사용
또한, 헤도 필드 압축을 지원하면서 헤더를 압축하여 전송 데이터 중복과 오버헤드를 제거 했다. 달라지지 않은 부분은 전송하지 않기 때문에 불필요한 오버헤드를 최소화할 수 있다.
서버는 클라이언트가 요청하지 않은 리소스를 미리 클라이언트에 보낼수 있는 서버 푸시 매커니즘으로 클라이언트 캐시에 데이터 저장 기능 등이 포함되었다.
Ref
https://developer.mozilla.org/ko/docs/Web/HTTP
HTTP | MDN
하이퍼텍스트 전송 프로토콜 (HTTP) 은 HTML과 같은 하이퍼미디어 문서를 전송하기 위한 애플리케이션 계층 프로토콜입니다. 웹 브라우저와 웹 서버간의 통신을 위해 설계되었지만 다른 목적으로
developer.mozilla.org
https://yozm.wishket.com/magazine/detail/1686/
웹 개발자라면 알고 있어야 할 HTTP의 진화 과정 | 요즘IT
하나의 웹 사이트에서 왜 이렇게 다른 버전의 HTTP가 사용되고 있는 걸까요? 각 버전에는 무슨 차이가 있는 걸까요? 왜 HTTP의 버전은 1, 2, 3으로 딱 나누어 떨어지지 않을까요? 그래서 오늘은 HTTP의
yozm.wishket.com
'IT > Web' 카테고리의 다른 글
| HTTP의 진화, HTTP/2 (0) | 2024.12.25 |
|---|---|
| [Web Hacking] Challange 54 풀이 (0) | 2023.05.18 |
| [Web Hacking] Challange 24 풀이 (0) | 2023.05.05 |
| [Web Hacking] Challange 16 풀이 (0) | 2023.05.01 |
| [보안] Cookie bomb attack (0) | 2023.05.01 |
