[ 네트워크 이야기 #2 ] HTTP, HTTPS , SSL, TLS

안녕하세요. 이번 포스팅에서는 저번 포스팅에 이어 HTTP, HTTPS에 대해 자세하게 살펴보겠습니다.

 

https://chanho0912.tistory.com/86

[ 네트워크 이야기 #1 ] OSI 7 Layers(4-7), HTTP, TCP, UDP

 

저번 포스팅을 아직 보지 않으신 분이라면, 전체적인 맥락의 이해를 위해 한번 보시는 것을 추천드립니다!

 

HTTP의 정의에 대해서 저번 포스팅에서 살펴보았습니다. 다시 한번 요약하자면,

 

HTTP란? 

HTTP는 HyperText Transfer Protocol의 약자입니다. 쉽게 생각하면 일종의 Text를 전달하는 프로토콜인데, (HyperText는 링크를 활용한 Text라고 보시면 됩니다) 인터넷에서 데이터를 주고받을 수 있게 설계된 규약이라고 할 수 있습니다. 

 

즉, 웹에서 Client와 Server 간 데이터를 주고받기 위한 규약이 HTTP입니다.

 

HTTP의 발전 과정

크게 HTTP 1.1/2을 중점적으로 살펴보겠습니다.

 

HTTP 1.X

1. HTTP 헤더 + 바디로 구성되어 있습니다. 사실 모든 Network Protocol은 기본적으로 패킷의 정보를 담아야 하는 헤더가 필요합니다.

2. 평문형태의 전송 (별도의 인코딩이나 암호화 과정을 거치지 않고 사람이 읽을 수 있는 형태로 제공합니다)

3. TCP 커넥션을 사용합니다. (모든 HTTP 버전은 TCP 통신을 활용합니다)

 

HTTP 1.X 문제점

1. HTTP 연결당 하나의 요청과 응답을 처리하기 때문에 동시 전송 문제와 다수의 리소스를 처리하기에 속도, 성능의 이슈가 존재합니다.

2. HOL(Head Of Line) Blocking(특정 응답 지연) : HTTP 1.1 버전에서는 파이프라이닝이라는 기술을 활용하였습니다. 예를 들어 Client가 Transaction1 ~ 4까지 전송을 보내면, Server의 Queue에 순서대로 적재되고, 응답도 순서대로 보내주게 됩니다. 문제는 2번 Transaction에 대한 요청이 먼저 끝날 수 있는데, 1번 Transaction이 끝나기 전까지 2~4의 응답은 전송되지 않고 항상 Server의 Queue에 대기해야 합니다. 이러한 문제를 HOL Blocking 문제라고 합니다.

3. RTT 증가 (양방향 지연)

4. 헤더의 크기 : HTTP 1.1버전의 헤더에는 많은 메타 정보들이 저장되어 있습니다. 따라서 매 요청마다 큰 크기의 쿠키를 포함한 헤더를 전송하게 되며, 이로 인한 오버헤드가 높습니다.

 

HTTP 2.0

위의 HTTP 1.X 버전의 문제를 해결하기 위해 HTTP 2.0 버전이 도입되었습니다.

 

HTTP 2.0의 개선점

1. Multiplexed Streams : 우선 HTTP 1.X 버전의 가장 큰 문제점은 하나의 요청에 대해 하나의 응답만 처리할 수 있다는 점이었습니다. 따라서 Multiplexed Streams를 지원함에 따라 한 커넥션에 여러 개의 메시지를 동시에 주고받을 수 있습니다.

2. Stream Prioritization 요청 

3. Header Compression : HTTP 1.X 버전의 큰 문제점 중 하나인 Header가 비대함이라는 문제를 해결하였습니다. Header 정보를 HPACK 압축 방식을 이용하여 압축 전송을 진행합니다.

4. HTTP 1.X버전과 호환성이 좋습니다.

5. 페이지 로딩 속도가 향상됩니다. 

 

HTTP 2.0의 문제점

하지만 HTTP 2.0에서도 tcp의 근본적인 HOL Blocking의 문제를 해결하지는 못했습니다. 아무리 Stream으로 병렬적으로 처리가 가능하게 만들었어도, 결국 tcp는 순서를 보장하는 통신 프로토콜이기 때문에 packet loss로 인한 앞선 데이터의 부재가 HOL Blocking 문제로 다가오게 되는 것이죠. 

 

QUIC

결국 구글은 TCP기반으로 한 HTTP 프로토콜은 더 이상 개선점이 미비하다고 판단하여 UDP를 기반으로 한 HTTP 프로토콜을 고안하였습니다. UDP의 단점으로 부각되었던 신뢰성 부분의 문제를 애플리케이션 계층에서 처리하며 신뢰성을 확보하였습니다.

 

우선 HTTP 2버전 까지 가장 큰 문제가 TCP 통신 프로토콜의 HOL Blocking 문제였습니다. 따라서 이를 어떻게 해결했는지 역시 QUIC의 주요 관점입니다.

 

QUIC은 독립 스트림이라는 개념을 만들어냅니다. 

 

TCP Chain은 하나의 chain에서 stream을 전달합니다. 따라서 일부분에 병목현상이 발생하게 되면 그 뒤의 데이터 전송에 latency가 발생하게 됩니다.

하지만 QUIC는 독립적인 chain을 구상하여 문제가 된 stream만을 재전송하면 되기 때문에 HOL Blocking의 문제가 발생하지 않습니다.

(구글의 위대함...)

 

이번에는 HTTPS와 SSL에 대해 자세하게 살펴보겠습니다.

 

SSL

SSL(Secure Socket Layer)은 웹 표준 암호화 통신으로서 사용자와 웹 브라우저 간 통신을 암호화하는 데 사용하는 프로토콜입니다. TLS(Transport Layer Security)라는 개념도 같이 등장하는데, 이는 SSL의 업그레이드 버전 정도로 생각하면 되고, 통상적으로 SSL이라 불립니다. 

 

SSL의 동작

1. 인터넷 사이트는 자신의 정보와 공개키를 인증 기관에 제출합니다.

2. 인증 기관은 인증 기관의 개인키로 사이트의 정보와 공개키를 암호화합니다.

3. 인증 기관은 웹 브라우저에게 인증 기관의 공개키를 제공하고, 웹 서버에는 암호화된 인증서를 제공합니다.

4. Client가 웹 브라우저를 사용하여 웹 서버와 통신을 시도하면, 웹 서버는 자신의 인증서를 웹 브라우저에게 보내줍니다.

5. 웹 브라우저는 인증 기관의 공개키로 서버 인증서를 해독하여 검증합니다.

6. 5번 과정에서 얻은 웹 서버의 공개키로 대칭키를 암호화해서 전송합니다.

7. 웹 서버는 자신의 개인키로 암호문을 해독하여 대칭키를 얻습니다. 이제 대칭키로 암호문을 주고받을 수 있습니다.

 

이렇게 작성하면 조금 어렵게 다가올 수 있을 것이라 생각합니다. 따라서 현재 TLS에서 사용하는 암호화 방식을 쉽게 말로 풀어서 설명해보겠습니다.

 

우선 두 가지 주요한 개념이 있습니다. 바로 대칭키 암호화와 비대칭키 암호화입니다.

 

대칭키 암호화

대칭키 암호화는 말 그대로, 클라이언트와 서버가 같은 키를 공유하며 이를 통해 암호화, 복호화하는 것을 말합니다. 

대칭키 암호화는 서버의 CPU 리소스를 적게 소모합니다. 하지만 공개키가 탈취당했을 때 위험이 큽니다.

 

비대칭키 암호화

비대칭키 암호화는 서버와 클라이언트 각각 공개키와 개인키를 두 개 가지고 있는 방식을 말합니다. 클라이언트와 서버는 각각 자신의 공개키를 서로에게 알려줍니다. 그러면 서로의 공개키로 암호화한 데이터를 각자 받은 뒤, 각자 개인키로 복호화해서 해독하는 것을 말합니다. 따라서 공개키가 탈취당하더라도 암호를 해독하려면 개인키가 필요하기 때문에 데이터가 안전하게 전송됩니다.

 

* 이렇게 한쌍의 개인키, 공개키로 암호화 복호화를 하는 방식을 RSA 알고리즘이라 합니다.

 

현대에는 비대칭키 암호화가 CPU 리소스를 많이 사용하기 때문에 첫 키 공유에서만 비대칭키 암호화를 사용하고, 각자 키가 안전하게 공유된 상태에서 대칭키 암호화를 사용합니다.

 

HTTPS

이제 HTTPS에 대해 완벽하게 이해하실 수 있으리라 생각합니다. HTTP는 웹 통신에서 HyperText를 교환하기 위한 프로토콜, 여기에 보안/인증(SSL) 프로토콜을 더한 것이 HTTPS입니다.

 

*저의 글에 대한 피드백이나 지적은 언제나 환영합니다.