http vs https vs http2

HTTP/1.1

HTTP(HyperText Tranfer Protocol)는 WWW 상에서 정보를 주고 받는 프로토콜이다. 클라이언트가 서버에 HTTP를 통해 웹 페이지나 이미지 정보를 요청하면 서버는 이 요청에 응답하여 요구하는 정보를 제공하게 된다. 결국, HTTP는 클라이언트와 서버가 자원을 주고 받을 때 쓰는 통신 규약이다. HTTP는 텍스트 교환이다. 바이너리 데이터로 되어있는 것도 아니고 단순 텍스트를 주고 받기 때문에 누군가 네트워크에서 신호를 가로채어 본다면 내용이 노출된다.

 

HTTPS

HTTPS는 인터넷 상에서 정보를 암호화하는 SSL(Secure Socket Layer)프로토콜을 이용하여 클라이언트와 서버가 데이터를 주고 받는 통신 규약이다. HTTP 메세지(text)를 암호화하는 것이다. HTTPS의 암호화의 핵심은 공개키 암호화 방식이다.

 

공개키 암호화 방식

두 개의 키가 존재하는데 한 키로 암호화하면 반드시 다른 키로만 복호화할 수 있다. 그 중에서 하나는 모두에게 공개하는 공개키로 만들어서 공개키 저장소에 등록해놓는다. 서버는 서버만 알 수 있는 개인키를 소유하고 있으면 된다. 그러면 공개키로 HTTPS 프로토콜을 사용한 요청이 온다면 서버는 개인키를 이용하여 공개키로 암호화된 문장을 해독하게 된다. 서버는 요청이 무엇인지 알게되고 요청에 맞는 응답을 다시 개인키로 암호화해서 요청한 클라이언트에게 보내주게 된다. 그리고 응답을 받은 클라이언트는 공개키를 이용해서 암호화된 HTTPS 응답을 해독하고 사용하는 시나리오다.

 

HTTPS 통신 과정

1. 먼저 애플리케이션 서버(A)는 HTTPS를 적용하기 위해서 공개키와 개인키를 만든다.

2. 신뢰할 수 있는 CA 기업(B)을 선택하고 A의 공개키를 관리해달라고 계약하고 돈을 지불한다.

3. B은 또 B만의 공개키와 개인키가 있다. B은 B의 이름과 A의 공개키, A 공개키의 암호화 방법 등의 정보를 담은 인증서를 만들고, 해당 인증서를 B의 개인키로 암호화해서 A에게 제공한다.

4. A는 암호화된 인증서를 갖게 된다. 이제 A는 요청(Request)이 오면 이 암호화된 인증서를 클라이언트(C)에게 준다.

5. C가 A에게 index.html 파일을 달라고 요청했다. 그러면 C는 B가 A의 정보를 B의 개인키로 암호화한 인증서를 받게된다.

6. B의 공개키는 브라우저가 이미 알고 있다. C가 CA 기업 리스트를 쭉 탐색하면서 인증서에 적혀있는 CA기업 이름이 같으면 해당 CA기업의 공개키를 이미 알고 있는 C는 해독해서 A의 공개키를 얻는다.

8. 그러면 A와 통신할 때는 A의 공개키로 암호화해서 Request를 날리게 된다.

 

HTTP/2

HTTP/1.1의 문제점

HTTP/1.1은 기본적으로 한 connection 당 하나의 요청을 처리하도록 되어있다. 그래서 다음과 같은 문제점들이 발생한다.

1. Head Of Line Blocking : 동시전송이 불가능하고, 순차적으로 이루어진다. 다수의 리소스(images, css, script)를 처리하려면 리소스 갯수에 비례해 Latency가 발생한다. 그래서 파이프라이닝 기법을 도입해 개선하려고 하지만 3개의 요청이 있다고 했을 때, 맨 첫 번째 요청이 오래 걸리면 그 다음 요청들은 어쩔 수 없이 기다릴 수 밖에 없는 것은 필연적이다.

2. Round Trip Time : 매 요청마다 connection을 만드는데, 이럴 경우 매번 TCP 3 way handshake가 반복적으로 일어나 불필요한 RTT가 증가한다.

3. 무거운 Header : 헤더에 많은 메타 정보가 들어있으며, 요청마다 중복된 헤더 값을 전송한다. 심지어 요청하려는 값보다 헤더가 더 큰 경우도 있다.

 

HTTP/2의 개선사항

1. multiplexd streams : 한 connection으로 동시에 여러 개의 메세지를 주고 받을 수 있으며, 응답은 순서에 상관없이 stream 으로 주고 받는다.

2. stream prioritization : 리소스간의 의존관계를 설정해 렌더링이 늦어지는 문제를 해결한다.

3. server push : 서버는 클라이언트의 요청에 대해 요청하지도 않은 리소스를 마음대로 보내줄 수 있다. 이 말은 클라이언트가 HTML 문서를 읽고 필요한 리소스들을 요청하기도 전에 서버가 미리 push 해준다는 것을 의미한다.

4. header compression : 헤더 정보들을 압축하기 위해 header table, huffman encoding 기법을 사용해 처리한다. 헤더에 중복된 값이 존재할 경우, static/dynamic header table 개념을 사용해 중복 헤더를 검충하고 중복된 값은 table의 index만 전송한다. 중복되지 않은 값은 huffman encoding으로 인코딩 처리한다.

 

 

출처

https://jeong-pro.tistory.com/89

Http와 Https 이해와 차이점 그리고 오해(?)