HTTP, TLS 버전별 구분

개요

• HTTP 버전별 차이점 확인을 통해 개선이 가능한 부분 확인하기
• TLS 버전별 차이점 확인을 통해 개선이 가능한 부분 확인하기
• 게임 서비스 네트워크 환경 개선을 위해 확인이 필요한 부분에 대해 조사

 

게임 서비스 네트워크 환경 개선을 위해서는 무엇을 해야할까?

 

글로벌 서비스를 제공함에 있어 게임 서비스의 네트워크 환경은 매우 큰 영향을 끼친다.

현재 AWS에서도 글로벌 네트워크 속도 개선을 위해 "Cloud Front" 와 "AWS Global Accelerator" 기능을 제공하고 있다. 

Global Accelerator는 L3,L4(TCP, UDP) Layer의 프로토콜에 대한 가속을 지원하며 Client로부터 요청 발생시 Edge-Location을 통해 가장 최적의 리전을 찾아 네트워크를 진행한다.

 

네트워크 환경을 개선하기 위해 혹은 GA를 좀 더 효과적으로 사용하기 위해서는 반복적으로 발생하는 불필요한 통신 비용에 대한 축소가 필요할 것으로 보인다.

현재 웹 서버를 사용하는 대부분의 게임 서비스에서는 http/1버전을 사용할 것으로 예상된다. 

http/1은 stateless한 상태를 유지하기 떄문에 매 connection 생성시 handshake 과정이 반복되며 이러한 반복적인 handshake 과정은 비싼 비용을 초래하며 네트워크 성능 저하를 일으킨다. 

 

이를 개선하기 위해 http 2.0, 3.0에서는 connection 생성을 위한 handshake 과정의 간소화가 이루어 졌다.

(물론 이 외에도 기존 버전에 대한 문제점 개선을 위한 많은 변화가 이루어 졌다.)

2018년 TLS 또한 새로운 버전(1.3)의 출시로 인해 handshake 과정이 간소화 되었으며 기존 1.2 버전에서 가지고 있던 보안적인 이슈사항 또한 개선이 진행되었다.

 

결과적으로 어떤 차이가 있는지 간단하게 확인해보자.

HTTP 버전에 따른 성능 차이는?

 

그렇다면 실제 http version에 따른 성능 차이는 어떨까?

아래 그림은 http/1, http/2, https 간 웹 페이지의 콘텐츠가 화면에 나타나기까지 RTT에 따른 Latency 그래프이다.

 

출처 : https://www.nginx.com/blog/7-tips-for-faster-http2-performance/

 

• 매우 낮은 RTT(0–20ms)
  • HTTP/1.x, HTTP/2 및 HTTPS 간에 거의 차이가 없음
    
    
• 일반적인 인터넷 RTT(30–250ms)
  • HTTP/2는 HTTP/1.x보다 빠르며 둘 다 HTTPS보다 빠름
  • 서로 가까운 미국 도시의 경우 RTT는 약 30ms이고 해안에서 해안까지(약 3000마일) 약 70ms이며 도쿄와 런던 사이의 최단 경로에서 RTT는 약 240ms
    
    
• 높은 RTT(300ms 이상)
  • HTTP/1.x가 HTTPS, HTTP/2보다 빠름

 

일반적인 인터넷 환경(RTT 30-250ms)에서는 HTTP/2가 가장 짧은 Latency를 나타냈으며, 높은 RTT를 가질수록 HTTP/1.x이 빠른 속도를 나타내었다. 

허나 일반적인 웹 콘텐츠는 다양한 미디어 및 파일들을 포함하고 있기에 실제 웹서버를 사용하는 게임 서비스에 적용시 위와는 상이한 결과를 나타낼 수 도 있을 것이라 생각된다.

(실제 게임 서버에 테스트 해보기까지 모르...지 않을까 싶다)

 

 

아래 이미지는 http/1, http/2, quic(http/3 기반 프로토콜)를 비교한 latency에 대한 누적분포함수이다.

출처 : https://www.slideshare.net/deview/quic-67614063 - 쿠키런 quic을 이용한 네트워크 성능 개선

 

Latency 50ms -200ms 구간에서 분포의 밀도가 가장 높으며 그 중에서도 quic 프로토콜에서 밀도가  가장 높음을 확인할 수 있다.

즉, quic을 이용했을 때 낮은 Latency의 누적분포가 가장 많다. http/1, http/2 비교시 약 200ms 구간까지는 http/2에서 낮은 Latency의 응답 분포가 더 많음을 확인할 수 있다.

 

TLS 버전에 따른 성능차이는 어떨까?

 

네트워크 성능 관점에서 볼떄 TLS1.2와 TLS1.3의 가장 큰 차이는 handshake 과정의 간소화 일 것 이다.

TLS1.2에서 handshake를 위해 3-RTT의 과정이 필요했지만 1.3 버전에서는 1-RTT로 과정이 개선되었다.

또한, 클라이언트가 이전에 서버에 연결된 기록이 있는 경우 0-RTT Resumption이 가능해졌다.

 

실제로 TLS 버전에 따라 어느정도의 성능차이가 나타나는지 확인해보자.

 

위의 실험 그래프를 보면 TLS1.3은 shandshake 과정을 진행함에 있어 평균 44ms 정도의 속도를 보이며 1.3버전에서 전반적으로 빠른 속도를 나타낸다.

 

 

결론은?

종합해보면 특정 RTT 구간에서는 http 상위버전으로 갈수록 Latency가 낮게 나타났으며,  TLS 버전에 따른 handshake 또한 상위 버전에서 더 좋은 성능이 나타났다.

위의 실험 환경 중 일부는 실제 게임 서비스 환경과는 조금 다른 웹 서비스 기반의 실험 결과이다.

서비스의 종류(게임 혹은 웹서비스 등) 따라 서빙하는 데이터의 크기, 개수 및 종류가 다를 수 있고 이에 따른 결과 차이가 발생할 수 있음을 염두해두어야 한다.

다만, 프로토콜 버전 개선사항을 미루어 보았을 때 connection establish의 빈도가 잦은 환경에서 개선된 부분에 대한 높은 효율을 취할 수 있을 것으로 추측된다.

  

 

HTTP difference between version 

1.1 버전

• HOLB(Head of Line Blocking) 문제로 인해 여러가지 문제점이 발생
  • 앞선 요청의 처리가 늦어질 경우 병목이 발생할 수 있음
• multi connection establish의 resource 비용이 큼
  • 무선 네트워크의 경우 유선 네트워크 보다 대역폭이 작으므로 성능저하 발생의 가능성이 있음
  • 반복적인 handshake로 인해 RTT 증가 및 네트워크 지연 초래
• 헤더를 압축 하지 않음으로 반복 요청시 매번 헤더를 보내야하는 문제가 발생
  
  • 전송 데이터의 크기 증가

1.2 버전

• 헤더 정보에 대한 압축 지원(Header Compression)
  • 같은 클라이언트로 부터 반복되는 요청이 발생하는 경우 중복되는 헤더를 검출하여 table을 구성하고  index 값만 전송
• 하나의 커넥션을 통해 여러개의 요청 가능(multiflexing)
  • 기존 다중 요청에 대한 처리가 multi-connection으로 처리되었으나, 이를 개선하기 위해 단일 conneciton을 통한 multi-plexing 방식으로 변경
• 우선 순위 지정(Stream Prioritization)
  • 메시지 전송 단위가 Frame으로 변경되어 데이터 재조합을 위해 순서고려가 필요하게 되었다.
  • 각 스트림 데이터에 가중치 부여를 통해 리소스 할당이 가능해지며 응답 순서가 정해진다.
• 서버 푸시(Server Push)
  • 클라이언트의 요청 없이도 서버는 클라이언트에 푸시가 가능하다.

1.3 버전 

• 기존 TCP → UDP로 프로토콜 변경
• 프로토콜 변경으로 인해 TCP에서 사용하던 connection 생성을 위한 3-way-handshake 과정이 간소화 됨
• 패킷 손실 방지를 위한 대책이 필요함
  • 기존 TCP(http 1, 2)에서 패킷 손실 방지를 위해 ARQ 방식을 사용하여 패킷 손실에 대한 검증을 진행하였으나
  • QUIC 에서는 ARQ와 유사하나 일부 개선된 방식으로 패킷 손실에 대한 검증 진행
• http 2.0과 동일하게 multi-plexing 지원
• TCP에서 클라이언트 식별을 위해 Source의 IP주소와 Port Number,  Destination의 IP주소와 Port Number를 사용하였으나 QUIC에서는 Connection ID를 발급하여 서버와의 connection을 생성하여 클라이언트를 식별한다.

 

QUIC 패킷 손실 감지 및 혼잡 제어에 대한 IETF 문서 : https://datatracker.ietf.org/doc/rfc9002/

 

HTTP 1.123

프로토콜	TCP	TCP(SPDY 기반)	UDP(QUIC)
body	txt(데이터 단위 : http message)	Binary(데이터 단위 : 프레임 단위)	Datagram
특징	헤더 압축 불가 req -> res multi-connection 기반	헤더 압축 서버 푸시 multiplexing 지원(단일 커넥션) stream prioritization	UDP의 사용으로 TCP handshake 과정 제거 c/s간 커넥션 생성이 가볍다(1RTT) UDP에 대한 패킷 손실에 대한 대책 패킷 번호를 관리 multi-plexing 지원 클라이언트 IP에 자유로움 Connection ID를 통한 connection 유지(클라이언트 IP와는 무관함)

 

TLS 1.2 vs 1.3

 

TLS 1.2 vs 1.3 참고 자료: https://unused-css.com/blog/making-the-internet-safer-and-faster-with-tls-13/

 

 

http/3의 근간이 되는 quic            

https://musclebear.tistory.com/51