2022. 10. 26. 22:01ㆍTIL💡/Network
HTTP/0.9 - 원-라인 프로토콜
요청은 단일 라인으로 구성되며 리소스에 대한 경로로 가능한 메서드는 GET이 유일했다.
응답 또한 극도로 단순하다. 오로지 파일 내용 자체로 구성된다.
상태, 오류 코드도 없었다.
문제가 발생한 경우, 특정 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)15년 넘게 진행된 확장
새로운 헤더 혹은 메서드를 생성하기 쉬운 확장성 덕분에, 그리고 1999년 6월에 공개된 RFC 2616과 HTTP/2 릴리즈의 예견 속에서 2014년 6월에 공개된 RFC 7230-RFC 7235 시리즈, 그런 두번에 걸친 리비전을 통해 정재되었에도, 이 프로토콜은 15년 넘도록 극도로 안정성을 유지해왔습니다.
💛 보안 전송을 위한 HTTP 사용
HTTP에 일어났던 가장 큰 변화는 1994년 말에 이미 완료되었습니다. 기본적인 TCP/IP 스택을 통해 HTTP를 전송하는 대신에, 넷스케이프 커뮤니케이션은 그것의 토대 위에 추가적인 암호화된 전송 계층인 SSL을 만들어냈습니다. SSL 1.0은 회사 외부로 릴리즈된 적이 없으며, SSL 2.0과 그것의 후계자인 SSL 3.0과 SSL 3.1은 서버와 클라이언트 간에 교환된 메시지 인증을 암호화하고 보장하여 e-커머스 웹 사이트를 만들어내도록 했습니다. SSL은 표준 트랙 상에 놓여져 있었고 마침내 TLS가 되어, 성공적으로 취약성을 종식시키는 1.0, 1.1 그리고 1.2 버전이 나와있습니다. TLS 1.3은 현재 진행 중에 있습니다.
같은 시간 동안, 암호화된 전송 계층에 대한 필요성이 대두되었습니다. 웹은 광고주, 불특정 개인, 혹은 범죄자가 다른 사람인척 가장하거나 전송된 데이터를 수정된 데이터로 대치시키고자, 개인 정보를 빼내려고 경쟁하는 정글 속에, 거의 학문적인 네트워크의 상대적인 신뢰를 남겨두었습니다. HTTP 상에서 만들어진 애플리케이션들이 주소록, 이메일 혹은 사용자의 지리적 위치와 같은 수 많은 개인 정보에 접근하는 등 점점 더 강력해짐에 따라, TLS의 필요성은 e-커머스 사용 케이스 외에 여기 저기서 나타나게 되었습니다.
💛 복잡한 애플리케이션을 위한 HTTP 사용
웹에 대한 Tim Berners-Lee의 본래 비전은 읽기 전용의 매체는 아니었습니다. 그는 사람들이 문서를 원격으로 추가하거나 이동시킬 수 있는, 분산된 파일 시스템의 한 종류로 웹을 상상했었습니다. 1996 쯤, HTTP는 저작을 허용하도록 확장되었으며 WebDAV라고 불리는 표준이 만들어졌습니다. 그것은 주소록 개체들을 다루기 위한 CardDAV 그리고 달력을 다루기 위한 CalDav와 같은 특정 애플리케이션들로 더 확장되었습니다. 그러나 이런 모든 *DAV 확장들은 한 가지 결점을 갖고 있었습니다. 꽤 복잡한, 사용하고 있는 서버에 의해 구현되어야만 한다는 것이었죠. 웹 영역에서 그것들을 사용하는 것은 극비로 남겨져 있었습니다.
2000년에, HTTP 사용에 대한 새로운 패턴이 고안되었습니다. representational state transfer (혹은 REST). API에 의해 유도되는 액션들은 새로운 HTTP 메서드 뿐만 아니라, 기초적인 HTTP/1.1 메서드를 이용한 특정 URI 접근에 의해서도 더 이상 전달되지 않았습니다. 이것은 모든 웹 애플리케이션으로 하여금 브라우저나 서버의 갱신없이 데이터 탐색과 수정을 허용하는 API 제공을 가능케했습니다. 필요로 하는 모든 것은 표준 HTTP/1.1을 통해 웹 사이트에 의해 서브되는 파일 내로 임베드되는 것이었습니다. REST 모델의 단점은 각각의 웹사이트가 자신의 비표준 RESTful API를 정의하고 그에 대한 전권을 가진다는 사실에 있습니다; *DAV 확장과는 다르게 클라이언트와 서버들은 상호작용이 가능합니다. RESTful API들은 2010년에 들어 매우 일반적인 게 되었습니다.
💡 REST
효율적, 안정적이며 확장 가능한 분산 시스템을 가져올 수 있는 소프트웨어 아키텍처 디자인 제약의 모음
그리고 그 제약들을 준수했을 때 그 시스템은 RESTful하다고 일컬어진다.
REST의 기본 개념은 리소스이다. 리소스의 예로는 잘 정의된 상태와 관계, 표준화된 작동방식과 형식을 가지고 전송되는 문서를 들 수 있다.
종종 타입이나 문서를 수정해야할 때, API 혹은 그 서비스는 어디에선가 액션을 불러일으키지 않고 스스로 RESTful을 호출한다.
Web 뒤의 기준 프로토콜인 HTTP은 문서와 하이퍼텍스트 링크 또한 전달하기 때문에, 간단한 HTTP APIs는 꼭 REST 제약을 지킬 필요가 없어도 통상적으로 RESTful APIs, RESTful services, 혹은 simply REST services라고 불립니다. 초보자는 REST API는 표준 웹 라이브러리 및 도구가 사용되는 HTTP서비스라고 가정해도 좋습니다.
2005년부터, 웹 페이지에서 사용 가능한 API 집합들이 급격히 늘어나게 되었고 이들 API 중 몇몇은, 거의 새로운 특성화된 HTTP 헤더로, 특정한 목적을 위해 HTTP 프로토콜에 확장을 만들어내었다.
- 서버 전송 이벤트, 서버가 브라우저로 이따금씩 보내는 메시지를 푸쉬할 수 있는 곳.
- 전통적으로 웹페이지는 새로운 데이터를 받기 위해 서버로 요청을 보내야만 한다. 서버로 데이터를 요청하는 방식이다. 하지만 Server-sent Events 방식으로 웹페이지의 요청 없이도 언제든지 서버가 새로운 데이터를 보내는 것이 가능하다. 이렇게 보내진 메시지는 웹페이지 안에서 Events + 데이터로 다룰 수 있다.
- 웹소켓, 기존 HTTP 커넥션을 업그레이드하여 만들 수 있는 새로운 프로토콜
- 웹 소켓은 사용자의 브라우저와 서버 사이의 인터액티브 통신 세션을 설정할 수 있게 하는 고급 기술이다. 개발자는 웹 소켓 API를 통해 서버로 메시지를 보내고, 서버의 응답을 위해 서버를 폴링하지 않고도 이벤트 중심 응답을 받는 것이 가능하다.
💛 웹의 보안 모델 완화
HTTP는 웹의 보안 모델인 same-origin 정책에서 독립되어 있다. 사실 현재의 웹 보안 모델은 HTTP이 만들어진 이후에 개발되어 왔습니다! 몇 년에 걸쳐, 이 정책의 몇 가지 정책을 고무시키기 위해 확실한 제약사항 아래 허용함으로써, 좀 더 관대해지도록 하는 것이 유용하다는 것을 증명해왔다.
제약사항이 얼마나 그리고 언제 리프트될지는 HTTP 헤더의 새로운 묶음들을 사용하는 서버부터 클라이언트에 의해 전도된다.
이러한 내용들은 Cross-Origin 리소스 공유(CORS) 혹은 컨텐츠 보안 정책(CSP)과 같은 스펙 내에 정의되어 있다.
이런 커다란 확장에 덧붙여, 다른 많은 헤더들이, 때로는 실험적으로만, 추가되어 오고 있다.
🌱 동일 출처 정책(Same Origin Policy)
동일 출처 정책은 어떤 출처에서 불러온 문서나 스크립트가 다른 출처에서 가져온 리소스와 상호작용하는 것을 제한하는 중요한 보안 방식이다. 동일 출처 정책은 잠재적으로 해로울 수 있는 문서를 분리함으로써 공격받을 수 있는 경로로 줄여준다.
[출처의 정의]
두 URL의 프로토콜, 포트, 호스트가 모두 같아야 동일한 출처라고 말한다.
🌱 CORS(Cross Origin Resource Sharing)
다른 도메인에서의 자원을 호출하는 행위에 제한이 없을 경우 안전하지 않다. CORS는 이렇게 시스템 수준에서 타 도메인 간 자원 호출을 승인하거나 차단하는 것을 결정하는 것이다.
HTTP/2 - 더 나은 성능을 위한 프로토콜
몇 년에 걸쳐, 웹페이지는 매우 복잡해지면서, 종종 진정한 애플리케이션이 된다.
디스플레이되는 시간적 미디어에 양에 덧붙여 상호작용을 추가하기 위한 스크립트의 양과 크기는 점점 더 많이 증가하고 있다.
더 많은 데이터들이 더 많은 요청 너머로 전송되고 있다.
HTTP/1.1 커넥션은 올바른 순서로 전송되는 요청을 필요로 한다. 또한 병렬 커넥션이 이론적으로 사용 가능한 경우(일반적으로 5와 8 사이에서), 여전히 많은 양의 오버헤드와 복잡도가 남아 있다. 예를 들어, HTTP 파이프라이닝은 디플로이 악몽임이 확실해졌다.
2010년 전반기에, Google은 실험적인 SPDY 프로토콜을 구현하여, 클라이언트와 서버 간의 데이터 교환을 대체할 수단을 실증하였다.
그것은 브라우저와 서버 측 모두에 있어 많은 관심을 불러일으켰다. 응답성 증가 능력을 입증하고 전송된 데이터 중복에 관한 문제를 해결하면서, SPDY는 HTTP/2 프로토콜의 기초로써 기여했다.
HTTP/2 프로노콜은 HTTP/1.1 버전과 다른 몇 가지 근본적인 차이점을 가지고 있다.:
- 그것은 텍스트 프로토콜이라기보다는, 이진 프로토콜이다. 더 이상 읽을 수도 없고 수작업을 만들어낼 수 없다.
이런 결점에 대한 보상으로, 새로운 최적화 기술이 구현될 수 있었다. - 병렬 요청이 동일한 커넥션 상에서 다루어질 수 있는 다중화 프로토콜로, 순서를 제거해주고 HTTP/1.X 프로노콜의 제약사항을 막아준다.
- 전송된 데이터의 분명한 중복과 그런 데이터로부터 유발된 불필요한 오버헤드를 제거하면서, 연속된 요청 사이의 매우 유사한 내용으로 존재하는 헤더들을 압축시킨다.
- 서버로 하여금 사전에 클라이언트 캐시를 서버 푸쉬라고 불리는 매커니즘에 의해, 필요하게 될 데이터로 채워넣도록 허용한다.
2015년 5월에 공식적으로 표준화된, HTTP/2는 큰 성공을 거두었습니다. 2016년 6월, 모든 웹 사이트 중 8.7%[1]가 이미 사용 중에 있고, 이것은 모든 요청의 68% 이상을 나타냅니다. 인터넷 상에서 전송 오버헤드 감소로 많은 돈을 절약하는 높은 트래픽의 웹 사이트들은 이 프로토콜을 급속히 받아들이고 있습니다.
이러한 급격한 채택은 HTTP/2가 웹 사이트와 애플리케이션의 채택이 필요하지 않았기에 가능했습니다. HTTP/1.1을 사용할지 HTTP/2를 사용할지 고민할 필요가 없어졌습니다. 최신 브라우저와 통신하는 최신의 서버를 갖는 것은 프로토콜 사용을 활성화하는 것만으로 충분합니다.어느 정도의 제한된 액터 세트만이 HTTP/2 채택을 불러일으키는데 필요했으며 브라우저와 서버 버전이 교체됨에 따라, 웹 개발자의 투입없이도 HTTP/2의 사용은 자연스럽게 증가했습니다.
HTTP의 진화는 그것의 확장성과 단순함이 예측 불가능한 애플리케이션과 프로토콜 채택을 만들어내고 있다는 것을 보여줍니다. 오늘날 HTTP가 사용되는 환경은 1990년 초에 상상하던 것과는 완전히 다릅니다. HTTP 본래의 설계가 걸작이 되었음을 지난 25년 넘게 호환되지 않는 진화의 요구없이 웹을 진화시킴으로 증명했습니다. 25년 넘게 HTTP의 성공을 만들어 온 유연함과 확장성을 유지하는 동시에, 수년 넘게 밝혀진 많은 결함들을 수정한 덕택에, HTTP/2의 등장은 프로토콜에 대한 밝은 미래를 암시하는 것처럼 보입니다.
HTTP/3 - HTTP over QUIC
Experimental
HTTP의 다음 메이저 버전인 HTTP/3에서는 전송 계층 부분에 TCP/TLS 대신 QUIC가 사용된다.
https://developer.mozilla.org/ko/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP
HTTP의 진화 - HTTP | MDN
HTTP는 월드 와이드 웹에 내재된 프로토콜입니다. Tim Berners-Lee에 의해 1989년부터 1991년에 발명된 HTTP는, 본래의 단순함의 대부분을 지키면서 확장성 위에서 만들어지도록, 많은 수정을 거쳐왔습니
developer.mozilla.org
'TIL💡 > Network' 카테고리의 다른 글
| [HTTP] 전형적인 HTTP 세션 (0) | 2022.10.26 |
|---|---|
| [HTTP] HTTP/2.0 프레임 (0) | 2022.10.26 |
| [HTTP] HTTP 개념 정리 💡 (0) | 2022.10.26 |
| [Network] JWT란 (0) | 2022.09.30 |
| [암호화] TLS(Transport Layer Security) (0) | 2022.09.30 |