이번 포스팅에서는 HTTP와 HTTPS, HTTP2의 개요와 특징, 차이점 등을
각 프로토콜의 출시 과정을 통해 알아보고자 한다.
HTTP 란?
*HyperText Transfer Protocol
● 하이퍼 텍스트를 전송하기 위한 프로토콜이다.
하이퍼 텍스트를 작성하기 위해 개발된 언어가 HTML이기 때문에,
HTML을 전송하기 위한 프로토콜이라고 볼 수도 있다.
● 요청(Request)과 응답(Response)으로 구성되어 있다.
요청과 응답이 오고 가는 것을 하나의 스트림(Stream)이라 표현한다.
● 텍스트 데이터만을 취급한다.
● 80번 포트를 사용하도록 정의되어 있다.
★ 확장 가능한 프로토콜이기에 계속 진화하고 있다.
HTTP는 현재까지도 새로운 버전이 출시되는 등 거듭 진화중이라고 볼 수 있다.
새로운 버전이 출시되었다는 것은 출시 배경이 존재한다는 것을 의미한다.
이전 버전의 불편한 점들이 있었기에 그것을 보완한 신기술이 탄생하는 것이다.
그렇기에 본문에서는 HTTP를 3가지 버전으로 나누어 짚고 넘어가고자 한다.
순서는 각 프로토콜의 출시연도를 기준으로 정했다.
HTTP/0.9
● 출시연도 : 1991년
'넷스케이프 커뮤니케이션즈' 기업에서 출시하였다.
● 정말 기초적인 데이터만을 다룰 수 있는 프로토콜이다.
'데이터를 전송한다' 와 '데이터를 읽는다' 라는 개념만이 존재했고,
데이터를 가공하는 등의 행위는 존재하지 않았다.
● HTTP Method로는 GET 방식만을 사용할 수 있다.
● 응답(Response) 또한 body로만 받을 수 있다.
● 버전이라는 개념이 존재하지 않았다.
추후에 HTTP/1.0 버전이 출시되고 나서, HTTP/0.9 버전으로 명시되었다.
● 통신 과정 요약
· 한 번의 스트림이 생길 때마다 Connection을 열고 닫아야 한다.
· 이전 스트림의 응답이 올 때까지 새로운 스트림을 시작할 수 없다.
HTTP/1.0
● 출시연도 : 1996년
'넷스케이프 커뮤니케이션즈' 기업에서 출시하였다.
● 상태 코드의 개념이 등장하였다.
성공 코드 : 200 / 에러 코드 : 400 404 등
통신 결과에 대한 상태를 받을 수 있게 되었다.
클라이언트가 상태 코드로 특정 상황에 대한 예외 처리를 할 수 있는 등
디테일한 개발이 가능해지는 시점이다.
● 헤더(Header)가 등장하였다.
헤더에 메타 데이터를 포함하여 데이터를 주고 받을 수 있게 되었다.
메타 데이터에는 HTTP버전 정보 & 클라이언트의 간단한 정보 등이 포함되었다.
● Content-type 기능이 추가되었다.
jpg(이미지)파일 등 HTML 외의 문서를 전송할 수 있게 되었다.
● 위의 HTTP/0.9 탭에서 언급하였듯이, 버전이 명시되기 시작했다.
● 통신 과정 요약 그림은 위의 HTTP/0.9 버전과 동일하기에 생략한다.
HTTP/1.1
● 출시연도 : 1997년
'넷스케이프 커뮤니케이션즈' 기업에서 출시하였다.
● 헤더에 더 많은 데이터를 담기 시작했다.
언어, 타입, 인코딩 방식 등
더 많은 종류의 메타 데이터를 담을 수 있게 되었다.
통신의 유연성 & 확장성이 향상되었다고 볼 수 있다.
● 파이프 라이닝 기능이 추가되었다.
앞선 HTTP/0.9&1.0 버전에서는 이전 스트림의 응답이 올 때까지
새로운 스트림을 시작할 수 없었다.
파이프 라이닝 방식을 적용하면서 요청과 응답을 분리시키고,
이전 스트림의 응답과 관계없이 새로운 요청을 보낼 수 있게 되었다.
이는 전체적인 통신 속도 향상에 큰 영향을 주었다.
● 커넥션을 재사용할 수 있게 되었다.
스트림이 생길 때마다 커넥션을 열고 닫아주는 행위가 반복되자,
커넥션을 재사용 가능케 하는 방식을 추가하였다.
이로 인해, RTT를 감소시킬 수 있게 되었다.
*RTT(Round Trip Time) : 스트림에 소요된 시간
● 통신 과정 요약
· 파이프 라이닝 :
이전 스트림의 응답이 도착하기 전에 새로운 요청을 전송할 수 있다.
· 커넥션 재사용 :
스트림이 생길 때마다 매번 커넥션을 열고 닫을 필요가 없어졌다.
> 전체적인 통신 속도가 단축된 것을 확인할 수 있다.
HTTP/1.1 단점
● HOL Block (Head Of Line Block)
파이프 라이닝 기능은 FIFO 방식으로 적용되었다.
*FIFO(First In First Out) : 먼저 들어간 것이 먼저 나온다.
이는 이전 요청에 대한 응답이 먼저 처리되어야 한다는 의미인데,
이전 응답의 처리 시간이 길어지면 이후의 응답 또한 지연될 수 밖에 없다.
● 커넥션의 재사용 기능을 사용 가능할 뿐,
일반적으로 하나의 커넥션이 적용되어 있는 것은 아니다.
위에서도 언급했지만,
커넥션 재사용을 하지 않는 경우 RTT가 증가하는 결과를 초래한다.
● 헤더에 점차 다양한 메타 데이터를 추가하고 보니,
헤더가 점점 무거워지게 되었다.
- 종종 바디보다 헤더가 큰 케이스도 생기곤 한다.
이는 배보다 배꼽이 더 큰 격이라고 생각한다.
- 헤더에는 거의 동일한 내용이 작성되고, 식별되는 데이터는 주로 바디에 작성되곤 한다.
이때, 다수의 클라이언트를 상대해야 하는 서버의 입장에서 보면
헤더에 담긴 중복적인 데이터를 계속 전송하는 것이 불필요하다고 느꼈다.
HTTP/1.1의 단점을 보완하여 SPDY와 HTTP/2.0이 출시되었지만,
그 전에 HTTPS를 짚고 넘어가겠다.
HTTPS (HyperText Transfer Protocol Secure)
● 출시연도 : 2000년
● HTTP + SSL/TLS = HTTPS
HTTP 스트림을 SSL/TLS에 결합한 프로토콜이다.
*SSL/TLS : 데이터를 암호화해서 송수신하는 프로토콜.
두 용어는 같은 의미를 가지고 있으며 SSL의 상위호환 버전이 TLS이다.
현재는 TLS만 사용한다고 보면 된다.
실제로, 보안인증서 발급기관에 SSL 인증서를 신청하면 TLS 인증서를 준다고 한다.
용어상, 그동안 대중적으로 사용해왔기에 SSL이라는 이름이 불리는 것 뿐이다.
보안 전문가들이 SSL/TLS로 붙여서 부르기 시작했다고 한다.
● 443번 포트를 사용하도록 정의되어 있다.
● 초기에는 적용 범위가 좁았지만, 구글이 적용 범위를 확대시켰다.
초기에는 전자상거래 등 보안이 필요한 웹사이트에서만 사용되었다.
HTTPS가 보안 유지 측면에서 좋은 성능을 보이니, 구글이 발 벗고 나서게 된다.
2014년 부터 구글은 모든 웹사이트를 대상으로 4년간의 유예기간을 부여한다.
HTTPS를 적용한 웹사이트는 구글 검색 시 상위 노출해주는 방식으로 보상을 해주었다.
그리고 2018년 부터는 모든 웹사이트를 대상으로 강한 압박을 시작한다.
HTTPS를 적용하지 않은 웹사이트에 '안전하지 않음'을 표시해버린다.
사실상 HTTPS가 모든 웹사이트에서 의무화된 시점이기도 하다.
> 그리하여 현재는 거의 모든 웹사이트가 HTTPS를 적용하고 있는 상태다.
● HTTPS 동작 방식
공개키 암호화 방식을 사용한다.
이해를 돕기 위해 순서대로 그림과 함께 설명하겠다.
① HTTP 통신의 보안 취약점
HTTP 통신의 경우 클라이언트와 서버가 요청과 응답을 할 때,
제3자(해커)가 중간에 데이터를 가로챌 수 있었다.
② HTTPS의 공개키 암호화 방식
HTTPS의 공개키 암호화 방식이 적용된 그림이다.
공개키와 개인키는 각각 암호화와 복호화 둘 중 한가지만 처리할 수 있다.
ex) 공개키로 암호화 했으면 개인키로는 복호화만 할 수 있다.
반대로 개인키로 암호화 했으면 공개키로 복호화만 할 수 있다.
우선 서버는 개인키를 가지고 있다.
그리고 공개키는 여러 클라이언트가 이용할 수 있는 공개키 저장소에 있다.
클라이언트가 요청을 하기 위해서는, 공개키로 요청 데이터를 암호화해서 전송한다.
서버는 받은 암호화된 데이터를 개인키로 복호화해서 읽는다.
그리고 서버가 다시 응답 데이터를 개인키로 암호화해서 전송한다.
클라이언트는 공개키로 받은 데이터를 복호화해서 읽는다.
이러한 공개키&개인키 암호화 방식을 사용하면, 제3자(해커)가
중간에 데이터를 가로채더라도 암호화 되어있기 때문에 데이터를 읽을 수 없다.
③ 비대칭 암호화 → 대칭 암호화
공개키&개인키 암호화 방식으로 보안 유지는 충분하지만,
요청과 응답을 할 때 각각 암호화를 진행하므로 암호가 비대칭일 수밖에 없다.
이를 비대칭 암호화라고 하는데,
비대칭 암호화는 메모리 과부하를 불러일으킬 수 있다.
그래서 비대칭 암호화를 대칭 암호화로 변경시켜줘야 하는데,
위의 ②에서 진행했던 공개키&개인키 암호화를 시도할 때 사실
세션키를 암호화된 데이터 사이에 껴서 주고 받는다.
사실상 ②에서 진행했던 암호화 방식은 연결 초기,
즉 처음 연결된 후 1회만 진행되는 것이다.
④ 세션키 암호화 방식
③에서 진행했던 것처럼, 초기 1회 연결 시에 세션키를 주고 받으면
그 이후의 통신은 세션키로만 진행된다.
SPDY
● 출시연도 : 2010년
구글에서 출시하였다.
● SPDY 라는 이름은 'Speedy' 단어를 기반으로 만든 조어다.
● 이름 그대로, 웹 페이지의 로딩 속도 개선이 주 목적이다.
- 기존 HTTP는 텍스트 데이터만을 취급하는 프로토콜이었지만,
SPDY는 바이너리 프로토콜을 적용하였다.
*바이너리 : '두 가지의' 라는 의미를 갖고 있다.
컴퓨터 용어로는 이진법인 0과 1을 의미한다.
- 무거워진 헤더를 압축하는 방식을 적용하였다.
● 멀티플렉싱
- 기본적으로 1개의 커넥션을 사용한다.
앞서 언급했던 RTT가 감소하게 된다.
- 스트림 인터리빙을 적용하였다.
요청 순서에 구애받지 않고 먼저 준비된 응답부터 전달 받을 수 있다.
이로 인해, 위의 HTTP/1.1의 단점에서 언급하엿던 HOL Block 현상을 해결하였다.
*인터리빙 : 간섭하다
- 이외에도 응답 우선순위를 지정해놓을 수 있는 기능이 추가되었다.
● 암호화되지 않은 연결을 지원하지 않는다.
SSL/TLS 결합을 적용해야만 이용 가능하다.
즉, HTTPS 프로토콜만 확장 지원을 해준다는 이야기다.
● SPDY는 HTTP를 대체하는 프로토콜이 될 수 없었다.
전송되는 방식만을 재정의한 프로토콜이었고,
방식을 제시했지만 표준화까지는 성공하지 못했기 때문이다.
2010년 출시 후, 표준화 작업을 진행중이었지만
2015년 HTTP/2.0이 출시되면서 표준화 작업을 중단했다고 한다.
구글은 HTTP/2.0이 SPDY를 대체할 것이라고 언급하며 쿨하게 포기한 모습이다.
● 통신 과정 요약
· 멀티플렉싱 - 스트림 인터리빙을 적용했기에,
응답이 지연되면 다른 응답이 먼저 처리된 것을 볼 수 있다.
HTTP/2.0
● 출시연도 : 2015년
IETF(국제 인터넷 표준화 기구)에서 발표하였다.
(= HTTP Working Group)
● SPDY의 기능을 전부 포함한다.
(바이너리 프로토콜, 멀티플렉싱, HTTPS 의무화 등)
애초에 SPDY를 초안으로 삼고 개발을 시작했다고 한다.
● HTTP/1.1과 호환성이 유지된다.
SPDY와 다르게 HTTP를 대체하는 프로토콜이다.
● 서버 푸시 기능이 추가되었다.
정확한 요청을 받지 않은 데이터까지 응답을 해준다.
즉, 서버가 예상되는 데이터를 준비하여 미리 전송해버리는 것이다.
클라이언트는 선택적으로 데이터를 관리할 수 있다.
(푸시 활성화/비활성화)
푸시로 받은 데이터를 캐시에 저장해서 사용하는 등
여러 활용 방식을 보여준다.
● 통신 과정 요약 그림은 위의 SPDY와 동일하기에 생략한다.
HTTP/2.0이 적용된 웹사이트를 확인해보자
가장 자주 사용하는 웹사이트인 네이버에 들어가보자.
홈페이지에 접속하여 개발자 도구를 열어서 네트워크를 확인해 보았다.
부분적으로 h2(HTTP/2.0)가 적용된 것을 확인할 수 있었다.
여기까지 HTTP/0.9 ~ 2.0 의 진화 과정을 알아보았다.
작년에(2022년) HTTP/3.0 이 출시되었지만,
지금도 대부분의 웹 사이트에서는 HTTP/2.0 까지를 주로 사용하고 있는 것 같다.
다음 기회가 되면 HTTP/3.0에 대해서도 알아봐야겠다.
