Evolving transport-layer functionality
▪TCP, UDP: principal transport protocols for 40 years▪
많은 세월동안 TCP, UDP 둘만 사용되어 왔다.
Manyversions of TCP have developed, for specific scenarios TCP의 많은 변형 버전들이 발전됐다.
•Long and fat networks
•Wireless networks 무선을 사용하면 에러가 난다. TCP는 congestion control이 implicit하기 때문에 loss나 error에 대해 wireless는 데이터가 안들어오니까 congestion이 아닌데도 congestion인 줄 알게 된다.
•Datacenter networks: short paths and latency sensitive
▪If the transport services needed by an application don’t quite fit either the UDP or TCP service models, Application designers can always “roll their own” protocol at the application layer.
QUIC : 구글에서 개발, IETF에서 표준화를 해서 공식 doc이 존재한다. 하지만 IETF의 퀵과 구글의 퀵은 다르다. 퀵은 UDP위에서 동작을 한다. application protocol이라고 생각할 수 있지만 기능을 관점으로 봐야 한다. IP 레이어 위니까 트랜스포트 레이어인것같지만 IP를 그려놓고 그 해당 레이어 안에서 위에 적어놓는다.
크게 보면 transport레이어라고 봐도 틀린 건 아니다. 나중에 보면 IP가 있는데 2개를 쓸 수도 있다. IP packet을 또 ip로 할 수도 있고..그래서 얘는
TSL(1.2 or 3)는 암호화가 필요할 때 optional하게 사용.
HTTP1.1,2는 TCP위에서
HTTP 3 는 UDP위에서. 그리고 TLS(1.3) 이걸 따로 사용하는 게 아니라 QUIC 프로토콜 안에 포함하고 있음. 왼쪽은 HTTP2를 할 때는 stream으로 나누는데 어떤건 암호화가 필요하고 어떤건 아닌데 필요없는 것까지 전부 암호화를 시킴. TCP채널 자체를 암호화를 하는 것.
그런데 QUIC에서는 어떤 stream만 암호화를 선별적으로 하는 것. 그리고HTTP3는 2를 향상시킨 게 아니라 훨씬 간략화시킨 것임. 본인이 하는 stream multiplexing을 quic에게 기능을 넘기고 본인은 줄인 것. 슬림다운. 프로토콜 자체에서는 특별한 기능이 추가되지 않고 header compression만 조금 방법이 달라짐.
QUIC은 connection oriented임. UDP는 reliable하지 않다. 에러 리커버리. UDP는 DCCP라는 congestion control mechanism이 표준화 되어 있지만 그냥 quic에 있는 걸 가져와서 따로 그냥 씀. 그걸 QUIC이 제공. 이것들을 TCP에서 제공해준다.
connection migration 새로 추가됨
TCP가 3 handshaking할때 최소 1RTT가 필요. TLS할때는 4개보다 훨씬 더 복잡한데 같이 전송되기에 적어도 2RTT는 필요하다는 것. 그 다음에 여기서 HTTP request, response해서 1RTT. 총 적어도 4RTT정도는 필요하다. 이게 일반적.
1.3에서는 TLS가 1RTT로 줄어듬.
HTTP3 : QUIC은 connection oriented protocol. TLS랑 같이 QUIC이 커넥션을 만든다.
0RTT : 각각 2,3번째 시나리오에서 출발. HTTP1.3에서 session resumption을 한다. TLS에서 암호화를 위해 negotiate를 하는데 이전에 해놓은 걸 사용하겠다는 것임. 키에 대한 네고시에이션 없이 더 빨리 하자. 그래서 TLS가 이미 사용됐으니 그 키를 갖고 하자라는 것. 여기는 아예 request를 같이 할 수 없다는 것. 그렇게까지도 가능하다.
quic은 reliable하고 자체 multiplexing stream.
stream마다 ID를 갖고 있어서 멀티플렉싱이 가능하다. 그리고 HTTP2d에서는 순서에 따라 했어야 했다. request response에 ID가 없었기에. 그러나 2에서는 stream으로 나눠서 stream의 ID를 가지면 순서에 따라 할 필요가 없었다. 그럼에도 불구하고 2에서는 header oder blocking이 나타난다. HTTP2는 TCP, 에러 리커버리는 TCP, TCP는 채널이 하나. reliable하고 inoder. 그런데 한쪽이 에러가 나면 에러 리커버리가 다 되고 난 다음에야 그다음 데이터가 출발.
QUIC에서는 reliable in-order을 stream단위로 바꿈. 프레임들은 stream으로 되어 있다.
왼쪽그림
3개의 request가 있다. 처음에는 에러리커버리에 TCP를 사용. 처음에 request가 하나 갔다고 하자. 그리고 두번째가 가다가 에러가 났다. 그리고 3번째를 보냈다. 그런데 받는 쪽에서 올려줄 때 순서에 맞게 올려줘야 한다. TCP는 릴라이어블, 인 오더니까 보낸 순서로 받아야 한다. 그래서 다시 response를 할 때 HoL이 없어보이지만 2번째가 에러리커버리가 될 때까지 리시버 트랜스포트쪽에서 어플리케이션에게 안 올려준다. 그전 데이터가 안 왔기에. 에러 리커버리가 다 되어야 올려준다.
오른쪽그림
그런데 에러는 stream별로 따로 채널이 존재한다. 그래서 오른쪽이 전달되고 가운데가 에러가 났다. 그러면 그냥 3번째가 관계없이 전달이 된다는 것. QUIC에서 stream별로 에러 리커버리를 하기 때문에 앞에서 보는 그런 문제가 사라진다는 것.
QUIC은 TCP에서 사용하는 CUBIC이나 BBR을 모듈처럼 끼워서 사용할 수 있다. TCP와 QUIC트래픽이 섞여도 서로 악영향을 주지 않는다.
congestion migration : 한동대 와이파이를 쓰다가 자체 데이터를 4G,5G를 변경해서 사용하게 되기도 한다. 한동대의 IP가 있다가 KT, SKT 데이터를 사용하면 IP가 바뀐다. TCP는 항상 source destination이 바인드가 되어있는데 이게 바뀌면 그게 끊어진다. 그래서 이걸 hand off가 발생했다고 한다. IP가 바뀌기에 TCP connection이 끊긴다. 다시 커넥션을 해서 서비스를 받아야 함. 그런데 QUIC에서는 header쪽에 connection identifier가 있기에 그걸로 유지를 한다. IP가 바뀌어도 다른 ID로 유지하기에 hand off가 발생해도 끊임없이 서비스가유지된다.
한쪽에서 ID를 사용하는데 똑같은 ID를 사용하게되면 안되기에 네트웍이 바뀌면 connection ID를 바꾼다. 처음에는 동일한 ID를 사용하다가 통신을 유지하면서 ID를 바꾼다. 그래서 처음에 C ID를 list로 갖고 있는다. 한 ID를 가지고 한 네트웍에서 사용하다가 네트웍이 바뀌면 커넥션을 끊지 않고 ID만 바꾼다.
퀵과 TCP?
TCP보다 quic이 오버헤드가 더 크다. 에러 리커버리를 stream별로 하기 때문에. TLS보다 조금 더 크다. 여러개의 stream으로 전송할 필요성이 있는 게 일반적 프로그램에서는 없다. 거의 하나로 하지 논리적으로 여러개를 하는 경우는 많이 없다.
