TCP connection 과 Streaming + QUIC 에 대한 고찰

같이 스터디하는 분들끼리 TCP connection에 대해 의견이 분분해서 토론이 시작되었고, 추가로 느꼈던 의문과 고민, 그 답을 찾아가는 과정을 남겨놓았습니다.

 

토론의 시작 질문

핸드폰으로 유튜브를 보던 중에 핸드폰의 IP가 변하면 TCP 연결이 끊어지나요?

 

상황 설명

1. 와이파이에 연결되어 있다가 와이파이를 끊어서 Public IP가 바뀐다던가.
2. 핸드폰을 들고 이동해서 IP가 바뀐다던가.

 

내 시나리오

TCP 연결이 끊어진다

 

서버사이드(유튜브)랑 클라이언트(핸드폰) 사이드로 나눠서 보면

1. 둘이 TCP 연결되어있다가 클라이언트 IP가 변경되면 서버에서는 그걸 모른다.
2. 따라서 서버에서는 계속해서 클라이언트에게 응답 패킷을 보낸다
3. 근데 클라이언트는 그걸 못받는다. 왜? 기존 연결되어있던 IP가 바뀌었으므로
4. 클라이언트는 바뀐 새 source ip로 TCP 연결되어있듯이 계속 서버에게 요청을 보낸다
5. 서버는 TIME_OUT으로 기존 ip(라우터)와 연결이 끊긴다.
6. 클라이언트도 계속해서 요청을 보냈는데 서버의 응답을 못 받아서 TIME_OUT으로 연결이 끊긴다.
7. 연결이 끊겼으니 클라이언트가 TCP 연결을 다시 시도한다.
8. 새로운 TCP 연결이 생긴다.

 

다른 분 시나리오

TCP 연결이 끊어 지지 않는다.

1. 계층화의 개념으로 생각해보면 TCP 연결은 port만으로 연결이 되기 때문에 IP는 상관이 없다.
2. Transport(전송) 계층 패킷의 헤더를 생각해보면 Source Port, Destination Port 만 있지 않은가?
3. TCP는 전송계층 프로토콜 이므로, IP가 바뀌어도 TCP 연결이 끊기지는 않는다.

 

첫 번째 결론

일단 토론 끝에 내린 결론은

• TCP 연결하는 통신에서도 패킷의 <소스 IP, 소스 port, 타깃 IP, 타깃 port>를 TCP control block으로 사용하기 때문에, 소스 IP가 변경되면 재 연결된다.

입니다!

 

 

추가 문제

TCP 연결이 끊어지느냐에 대한 것은 YES로 결론이 났다. 하지만 여기서 문제가 하나 더 있었으니,

유튜브는 스트리밍이므로 TCP 통신이 맞는가 UDP 통신이 맞는가?

우선 이론적으로 배운것을 바탕으로 시나리오를 작성해보고, 다른 개발자분들과 이야기를 나눠보며 새로 생긴 이슈들이다.

 

1. TCP는 신뢰성을 보장하기 위한 연결 지향 프로토콜이다 보니 흐름 제어나 혼잡 제어 등을 해서 속도가 느린 반면, UDP는 비연결성 프로토콜로 속도가 빨라서 보통 실시간 스트리밍 같은 곳에 많이 쓰인다.

 

2. 따라서 실시간 스트리밍 서비스는 UDP일 것이다.

 

3. 그러나, 유튜브 컨텐츠를 보는 것이 리얼타임 통신은 아니지 않은가?

 

4. 그렇다면 굳이 UDP를 쓸 이유도 없어진다.

 

5. 그럼 TCP인가?? 

 

6. 또한 HTTP 는 TCP/IP 기반 응용 프로토콜이다.

 

7. 브라우저는 UDP를 지원하는가..?

 

등의 끊이지 않는 의문이 생겼다.

 

이 의문들을 당장 해결하기 위해서, 바로 유튜브를 켜고, 개발자 도구를 열어서, 당장 Response Header를 살펴보았다.

유튜브 컨텐츠의 HTTP 헤더

그랬더니 예상과는 전혀 다른 quic라는 프로토콜이 튀어나오는 것이었다....!!

 

여기서 멈출 수는 없었다.

 

그렇게 quic 에 대해 알아보았다.

 

 

QUIC (Quick UDP Internet Connections)

QUIC 프로토콜은 Google에서 개발된 프로토콜로 현재 표준 등록을 진행 중이라고 한다.

우선 UDP 위에 QUIC 프로토콜은 얹고 HTTP를 얹은 게 눈에 띈다.

거기에 TCP-like 혼잡 제어 + loss recovery 라니...

 

간단하게,

UDP로 3-way-handshake 없애서 속도 올리고, QUIC로 TCP-like 신뢰성을 추가한다 라는 소리로 들린다.

 

즉, UDP의 속도적 장점 + TCP의 신뢰성 장점을 합친 것이 이 프로토콜의 목표인 것 같다.

 

 

TCP vs QUIC

 

시간적 이점이 왜 나타나는지를 조금 더 자세히 살펴보자.

 

TCP + TLS에서 동작하는 HTTP/2 프로토콜에는 HOL(head-of-line) 문제가 있었다.

• HOL(head-of-line): HTTP/2에서 TCP 연결을 통해 패킷 전송이 일어날 때, 한 패킷에 문제가 생기면 다른 패킷 전송이 영향이 간다.

이에 QUIC는 독립 스트림을 여러 개 만들어 이 문제를 피하고자 하는 것이 핵심이다.

또한 hanshake 과정의 시간도 비교가 안된다.

 

 

 

결론

1. TCP 연결이 되어있다가 Client IP (Source IP)가 바뀌게되면 TCP control block으로 사용하는 패킷의 <소스 IP, 소스 port, 타깃 IP, 타깃 port>가 바뀌므로 TCP connection 이 끊기고 재연결된다.

 

2. 유튜브 스트리밍 서비스는 UDP 기반 QUIC 프로토콜을 이용한다.

 

여담

구글의 대부분의 제품에는 이미 quic 가 들어가 있지만, 아직 표준이 지정되지 않았고 UDP 기반의 프로토콜을 서버가 받아들이는 데 있어서 최적화나 검증되지 않은 부분이 많기 때문에 항상 속도가 더 빠르다고 장담할 수는 없다.

 

다만, 표준이 지정되고 시대가 HTTP/3로 넘어가게 되면 IE의 몰락처럼, TCP 기반이 아닌 UDP 기반의 QUIC를 당연히 사용하는 시대가 올 수 있지 않을까.

(기술은 늘 변하는 것이고, 문제를 해결하는 데 있어서 더 좋은 해결책이 나왔다면 자연스레 바뀌기 마련이라 생각한다..)

 

 

 

 

이 내용들은 제가 공부하며 느꼈던 의문과 고민, 그 답을 나름대로 찾아가는 내용입니다.

아직 많이 부족하니. 틀린 부분은 얼마든지 지적해주세요!

 

 

Reference

• https://d2.naver.com/helloworld/47667
• What happens to TCP socket when IP address changes?
• How is a TCP connection maintained over a changing IP address
• QUIC - general-purpose transport layer network protocol
• QUIC, HURRY UP!

 

언제나 즐거운 질문과 답변에서 이어지는 티키타카

1. 개발자 커뮤니티에 질문

2. 같은 동아리 출신 개발자 분들께 질문