[컴퓨터 네트워크] 24. Transport Layer (10) : TCP 기능의 진화

TCP, UDP 프로토콜은 40년이 넘은 굉장히 오래된 프로토콜이다.

그래서 현대의 인터넷 사용환경과 맞지 않는 부분도 꽤 있다.

 

예를 들면, 과거에는 무선 인터넷이라는 것이 존재하지 않았지만, 지금은 무선 인터넷이 굉장히 흔하다.

이런 새로운 환경의 변화에 의해 새로운 도전과제가 생겼을 때, 어떻게 발전을 해야하는지에 대해 정리해보려고 한다.

 

1. 대역폭이 매우 큰 데이터 링크

매우 넓고 긴 대역폭을 가진 링크는 과거에 불가능했지만, 지금은 가능하다.

예로 백본에서 사용하는 급의 링크는 10Gbps 이상의 대역폭을 제공하기도 한다.

 

그런 상황에서의 문제는 굉장히 많은 패킷들이 in-flight 될 수 있다는 것이다.

미국 서부에서 동부 끝까지 데이터를 보내는 상황을 생각해보자.

만약 stop-and-wait 프로토콜이면 하나를 보내놓고 응답이 올 때까지 기다렸다가 다시 다음 데이터를 보낼 텐데, 거리가 멀면 성능에 큰 영향을 미칠 것이다.

이때 패킷 loss가 발생하면 굉장히 많은 in-flight 패킷을 파이프라인 방식으로 보내는게 막힐 수도 있다.

 

이런 문제는 어떻게 해결할 수 있을까?

지금 패킷을 연속해서 보내고 있는데, 기존보다 더 많은 패킷이 in-flight 되고 있는 상황이다.

그렇다면 과거에는 fast retransmit 을 3번째 중복 ACK를 받았을 때 다시 보냈는데, 이보다 이전에 fast retransmit을 할 수도 있다.

전송중인 패킷이 굉장히 많은 상황에서 뭔가 하나가 누락되었다는 것을 확인할 때까지 3번째 duplicated ACK를 기다리는 것은 너무 오래 걸린다고 판단할 수도 있다는 것

 

2. 무선 네트워크

무선 네트워크는 현대에서 굉장히 크게 변한 네트워크 환경이다.

백본 쪽은 여전히 유선을 많이 사용하긴 하지만, 엑세스 네트워크쪽은 무선을 사용하는 사례가 많다.

 

이 경우 발생할 수 있는 문제는 이제 host의 위치가 시시각각 변할 수 있는 것이 문제가 된다.

host와 host 사이에 TCP 연결이 있을 때 스마트폰을 들고 이동하면 (타고 있는 자동차가 빠르게 이동하는 등)

무선 엑세스 네트워크가 바뀔 수 있다. 그러면 순간적으로 TCP 연결이 끊어지게 된다.

 

이걸 만약 라우터에서 Loss라고 판정한다면 end system 에서는 굉장히 심각하게 받아들이게 된다.

그런데 사실은 이동하면서 곧바로 새로운 엑세스 네트워크에 접근할 것이기 때문에 네트워크 코어에서는 아무 문제가 없다. 다만 엑세스 네트워크의 변경에 의해 일시적으로 로스가 발생한 것이다. 그래서 이런 부분을 심각하게 받아들이지 않고 대처할 수 있도록 추가적인 조치가 필요하다.

 

3. Long-Dealy link

1번과도 이어지는 상황이다. 1번처럼 길고 두꺼운 링크를 지나게 되면 딜레이 시간이 증가할 수 있다.

즉, RTT가 증가할 수 있다.

 

이때는 ACK가 오기까지 시간이 오래 걸릴 것이기 때문에 congestion window 크기를 공격적으로 크게 잡아놓는 것을 생각할 수 있다.

 

4. 데이터 센터 네트워크

대규모의 IT 회사들은 자사의 데이터 센터 네트워크를 갖고 있다.

예를 들면, 우리나라에서는 네이버가 데이터 센터를 갖고 있다. (춘천에 있다고 한다.)

데이터센터는 큰 건물에 많은 서버들을 모아두고, 그 서버들끼리 서로 연결시켜놓은 네트워크를 말한다.

 

이때 중요한 것은, 데이터센터에 있는 서버 사이의 데이터 트래픽 레이턴시가 굉장히 짧아야 한다는 것이다.

그래서 데이터센터 네트워크에서는 보통 미리 TCP연결을 설정해두어 연결 설정에 필요한 오버헤드를 감소시킨다.

 

5. 백그라운드 트래픽

SNMP (Simple Network Management Protocol) 과 같은 네트워크 관리 프로토콜이 있다.

이 프로토콜은 네트워크와 그에 연결된 각 장치들이 현재 잘 동작하는지 모니터링해서 관리자에게 알리고, 문제가 있다면 즉각적으로 조치를 취하도록 하는 것이 목적이다.

 

이 프로토콜에 의한 트래픽은 정말 순수하게 네트워크를 관리하는 목적의 트래픽이기 때문에, 실 데이터를 주고받는 트래픽에 비해 우선순위가 낮다.

따라서 TCP에 우선순위가 높은 트래픽과 낮은 트래픽을 구분할 수 있는 기능을 추가할 필요가 있다.

(현재 TCP에는 이런 기능이 없지만, 우선순위를 부여하는 것도 고려해볼 수 있다는 것)

 

QUIC

QUIC은 http3 QUIC이라고 부르는 프로토콜로, UDP 기반의 http이다.

QUIC 의 약자는 Quick UDP Internet Connections 를 의미한다.

즉, UDP를 사용한 어플리케이션 레이어의 프로토콜이다.

 

이 프로토콜의 목표는 http 2.0 의 한계를 극복하는 것이다.

이 프로토콜은 구글이 최초로 제안을 했고, 다수의 구글 서버에 구현이 되어있다.

그래서 구글의 유튜브, 크롬과 크로미움 기반의 브라우저들은 이 프로토콜을 지원한다.

 

먼저 QUIC 이전의 http 2.0에 대해 다시 돌아가보자.

http 2.0은 웹에서 Loss가 있으면 안되니 전통적인 TCP를 사용하겠다는 아이디어에 기반한 프로토콜이다.

이를 그림으로 나타내면 아래와 같다.

 

 

IP 위에 TCP가 있고, TCP 위에 TLS (보안을 위한 레이어), HTTP/2 가 존재한다.

TLS 는 Transport Layer Security의 줄임말이다.

SSL의 표준 버전이라고 생각하면 된다. (SSL에서 약간의 보안 취약점이 발견되어서 TLS가 이를 해소한 버전이므로 TLS를 사용하는 것이 좋다. TLS의 최신버전은 1.3 이다.)

 

 

QUIC은 위 그림과 같이 구현되어있다.

IP 위에 UDP를 두고, 그 위에 QUIC을 둔 뒤에 HTTP/2 의 기능을 간소화시켜서 두었다.

이때 QUIC 과 HTTP/2 기능의 간소화된 버전을 합쳐서 HTTP/3 이라고 한다.

 

이를 통해 할 수 있는 추론은 기존 버전에서 TLS가 사라졌으므로, TCP가 하는 신뢰성 보장과 보안 기능을 QUIC이 대신 하겠다는 것을 생각할 수 있다. 따라서 QUIC은 그 자체로 매우 복잡한 프로토콜이다.

 

UDP는 IP가 하는 기능에서 포트에 의한 mux, demux 밖에 없기 때문에 그저 best effort로 동작한다.

QUIC은 이 위에서 TCP가 하던 연결 설정, 패킷 loss 감지, 혼잡 제어 등을 모두 구현하고 있다.

TCP에서 연결 설정을 함으로써 얻을 수 있었던 이점(신뢰성, 혼잡 제어, authentication, encryption 등)을 QUIC에서 사용하겠다는 것. (TCP, TLS가 제공하는 기능을 QUIC에서 모두 제공)

 

그리고 이걸 집어넣으면서 몇가지 개선사항이 들어가있다.

우선 이 모든 것을 1RTT에 할 수 있다!

1RTT 이후에 연결이 설정된다고 가정하는 것이다.

 

먼저 http 1.1 에서 데이터를 전송하는 과정을 다시 살펴보자.

http 1.1 에서는 TCP를 사용하며, 그 위에 TLS 를 기반으로 보안을 두는 형태를 하고 있다.

데이터를 전송할 때는 어플리케이션 메세지를 하나씩 TLS, TCP 순으로 하나씩 거쳐가며 데이터를 전송한다.

 

 

그런데 http 1.1 에서는 데이터를 전송하다가 문제가 발생하면, 이 에러가 rdt에의해 해소될 때까지 멈춰있을 수 밖에 없다.

에러가 해소된 이후에야 데이터를 전송할 수 있다.

그리고 이 에러가 해서되어서 두번째 패킷이 전송되지 못하고 막혀있는 동안, 세번째 패킷은 두번째 패킷 다음에 보내지기를 기다리므로 stall 이 발생한다.

 

 

QUIC을 이용해서 http2를 개선하면 위 그림과 같은 형태로 구성된다.

encryption, rdt가 각 패킷마다 독자적으로 존재한다.

만약 어떤 웹사이트에 동영상과 이미지가 들어 있어서 그 데이터도 추가로 가져와야 한다면, 그 각각의 오브젝트를 가져오는 스트림이 별개로 존재한다.

 

단, Congestion Control은 예외적으로 공통으로 존재한다.

각각의 스트림이 이기적으로 데이터를 보내는 것을 막고 혼잡 제어에는 따르도록 두기 위함이다.

 

 

QUIC을 사용하면 이렇게 그림과 같이 중간에 error가 발생해서 패킷이 멈춰있더라도, 세번째 패킷에 대한 스트림은 독립적으로 존재하기 때문에 아래와 같이 패킷을 전송할 수 있다.

 

 

그래서 이를 가리켜, multiple application-level streams 를 사용하고 이 스트림들이 multiplexed 되어 하나의 QUIC connection이 된다고 표현한다.

즉, 하나의 connection 위에서 여러개의 stream을 두고 데이터를 동시에 주고받을 수 있다는 것이다.

따라서 데이터를 주고받는 과정에서 문제가 생기면, 이 문제는 그 스트림 하나에만 영향을 주고, 나머지는 영향을 받지 않는다. 다만 네트워크 혼잡상황의 경우는 모두에게 영향이 가므로 함께 컨트롤한다.

 

마지막으로 QUIC에서 어떻게 하나의 RTT만에 연결설정을 할 수 있는지 살펴보려고 한다.

 

 

기존 TCP에서는 암호화를 사용하기 위해 연속적으로 2 RTT를 거쳐서 연결 설정을 해야했다.

첫번째 RTT에서는 기존 TCP를 사용하기 위해 필요한 연결 설정

두번째 RTT에서는 암호화를 위해 필요한 정보를 담아 보내면서 암호화를 설정한다.

(암호화 기법, 키에 대한 것 등등)

그래서 3번째 RTT부터 실제로 데이터를 보낼 수 있었다.

 

 

반면 QUIC을 사용하면 한번 연결 설정 요청을 보낼 때는, 기본적으로 UDP를 사용하기 때문에 한번에 기존 TCP 연결을 위해 필요했던 데이터와 암호화 관련 데이터까지 한번에 보내서 연결을 설정할 수 있다.

다만 이때 제한이 하나 있는데, 바로 서버가 받아들일 수 있는 제안을 하는 것이다.

 

예를 들어서 어떤 알고리즘을 통해서 데이터를 암호화하자 라고 클라이언트가 제안할 때, 서버는 그 알고리즘을 지원하는지 여부에 따라서 승인할 수도 거부할 수도 있다.

물론 보통은 대부분의 QUIC 서버가 사용하는 알고리즘을 제안해서 대부분 수락을 받는다.

만약 거절을 당한다면 수락할만한 내용으로 다시 제안을 보내는 과정을 반복할 수도 있다.

그래서 QUIC은 보통 안전하다고 알려진 알고리즘, 키의 길이 등을 디폴트 파라미터로 정해두고 그에 맞춰서 구현해서 통신하자는 규칙을 만들어서 1번의 핸드셰이크로 연결을 설정할 수 있도록 한다.