devEvan
861
2019-10-08 08:57:17
15
2954

HTTP/3는 왜 UDP를 선택한 것일까?


18
7
  • 댓글 15

  • zepinos
    19k
    2019-10-08 09:55:42

    내용이 꽤나 충실하네요. 잘 봤습니다.

    0
  • 오징어먹물식빵
    30
    2019-10-08 11:14:13

    좋은글 잘 봤습니다

    0
  • 어쩌다
    5k
    2019-10-08 11:15:11

    오 흥미 롭네요..

    커넥션아이디만으로 해당 서버(아이피가 변경된)를  어떻게 찾아갈수 있는지가 궁금하네요..

    잘 봤습니다 

    0
  • 믿음
    4k
    2019-10-08 13:22:55

    저도 출근하면서 본 글인데, 먼저 공유해주셔서 감사해요~ㅎㅎㅎ

    0
  • mirr
    127
    2019-10-08 13:27:15 작성 2019-10-08 13:29:26 수정됨

    tcp의 연결제어와 혼잡제어를 QUIC 프로토콜에 넘긴거네요.

    스트리밍이 주 트래픽이 된 현 인터넷 환경에서는 TCP보다는 UDP기반이 좀더 장점이 있다고 판단했나봅니다.

    그리고 IP에 종속되지 않고 고유 ID를 가지면서 모바일 네트워크 변화에 대응이 된다는 점이 장점이 되고요.

    UDP기반이지 UDP는 아니고 오히려 TCP 유사 프로토콜인 QUIC를 사용하였다고 하는게 좀더 정확한 표현같습니다. 


    가장 큰 문제는 게이트웨이 같은 네트워크장비들이 QUIC 프로토콜에 대응이 되느냐하는건데 그건 어느정도 기술적으로 해결했나봅니다. 


    1
  • nathak
    516
    2019-10-08 13:28:11

    //어쩌다

    커넥션아이디만으로 연결(세션)유지를 한다는것이지

    아이피가 변경된 서버를 찾는다는 의미는 아닌듯 합니다.

    아이피가 바뀌더라도 커넥션아이디로 판단하기 때문에 핸드쉐이크 과정없이 통신이 가능 한게 아닐까 하네요...

    1
  • 어쩌다
    5k
    2019-10-08 13:42:01 작성 2019-10-08 13:45:00 수정됨

    //nathak


    넵 그부분은 이해가 가는대 핸드쉐이크 없이도 어떻게 바뀐아이피를 알고 패킷전송이 이루어지냐는거죠..

    커넥션 아이디야 핸드쉐이크 기능을 대체하여 반복 안하기 위한 랜덤키일 가능성이 크고

    커넥션 아이디와 함꼐 어느정보들을 가지고 핸드쉐이크 없이 핸들 가능한 추적방법이 궁금한~~

    1
  • mirr
    127
    2019-10-08 14:03:32

    //어쩌다

    QUIC에서 연결제어 ( 핸드쉐이크 등 )을 한다고 합니다. TCP에 비해서 핸드쉐이크 횟수가 적다고 되어 있네요. 최초 연결과 연결경로 변경시 핸드쉐이크는 어떤식으로 하는지 정확히는 모르겠습니다. TCP가 신뢰성을 상당히 강조한 무거운 프로토콜이라는 점을 생각해보면 신뢰성부분은 다른 계층(예를 들어 HTTP3 계층)으로 일부 넘기고 연결이라는 점을 좀더 신경쓴 프로토콜로 보입니다. 나중에 프로토콜 설계서는 찾아볼필요가 있겠네요.

    https://docs.google.com/document/d/1gY9-YNDNAB1eip-RTPbqphgySwSNSDHLq9D5Bty4FSU/edit

    1
  • mirheeoj
    8k
    2019-10-09 14:51:29

    IP가 바뀌어도 세션이 유지된다는 말은 IP가 바뀐 클라이언트가 여전히 기존 커넥션ID를 가지고 있어서 그쪽에서 보낸 데이터를 그대로 서버에서 원래의 클라이언트가 보낸 메시지로 간주할 수 있다는 의미이지, 중간에 아무 통신도 하지 않았는데 별안간 서버가 클라이언트쪽의 바뀐 IP를 알아낼 재간은 없는 게 맞지요. 

    UDP를 사용하므로 재빠른 연결설정과 유연한 환경설정, 순서가 바뀌어도 그대로 데이터를 취할 수 있는 등의 장점도 있겠지만, 저는 멀티캐스팅쪽이 많이 기대가 됩니다. 유튜브를 가지고 있는 구글이기에 이쪽 발전도 기대할 수 있을 것 같아요. 실제로 관련 표준문서를 보니 멀티캐스팅쪽도 정의가 되어 있네요. 

    기능적인 면에서야 기존 TCP역할을 얼마든지 구현할 수 있으니, 구글과 같은 영향력을 지닌 곳에서 추진한다면야 얼마든지 정착 가능하겠지요. 걱정되는건 일부 네트웍 장비들이 아예 UDP를 차단해버린다는 사실 정도. http3으로 당장 전면교체할 일도 없으니 이쪽도 큰 지장은 없겠습니다만. 

    0
  • 지붕뚫고높이차
    656
    2019-10-09 22:20:09 작성 2019-10-09 22:30:20 수정됨

    쉽게 생각하세요.


    연결지향 프로토콜인 TCP 의 연결수립비용, 오류/흐름제어의 불필요함으로

    비연결지향 프로토콜인 UDP 선택 TLS 수립한다고 생각하면 됩니다.


    송신자는 한번의 전송으로 TLS 관련 정보를 전송하고

    수신자는 한번의 응답으로 TLS 결과를 전송하기 때문에

    2번의 데이터그램 교환으로 TLS 수립이 가능한 프로토콜입니다.


    TCP 는 초기 연결 수립, TLS 관련 정보 송수신 확인등으로

    9번 이상의 세그먼트 교환이 필요하기 때문에 네트워크 성능면에서

    QUIC 가 월등합니다.


    UDP 상위 프로토콜이기 때문에

    L3, L4 기반의 네트워크인프라에서도 문제없이 동작을 하고

    크게 볼때 인터넷의 부하를 절감 시키는데 기여합니다.


    또한 UDP 를 통해 TLS 성립 후

    교환된 대칭키를 재 사용 할 수 있기 때문에

    QUIC 이후
    연결을 TCP 로 전환

    TCP 의 장점인 오류제어/흐름제어를 사용 가능합니다.


    개념이나 기술적으로 어려운 프로토콜은 아니지만

    크롬 같은 인프라를 소유하고 있지 않은 기업이 아니면

    만들 수 없는 프로토콜입니다.

    1
  • onizuka
    221
    2019-10-10 15:04:41

    흠 저리 되면 방화벽에서 클라이언트 IP나 맥어드레스로 차단을 했던걸 수정해야할 수도 있겠네요

    스타 로컬에서 할때 UDP로 연결을 해서 했었는데...

    0
  • Aramode
    89
    2019-10-11 19:07:30

    성능저하의 원인이 되던것들에 적절한 대응을 해서 성능향상을 이룬것같네요.

    문제해결에 신기술이나 혁신만이 답은 아니라는 것을 보여준 좋은 사례같습니다.

    역시 Google, 응원하고있습니다.

    0
  • kamy
    80
    2019-10-13 19:21:46

    좋은 글 잘 읽었습니다. 덧붙여서 블로그에 대한 고민을 다시 해보게 되네요. 할까말까 오랫동안 망설였는데 쓰신 글들 보니 용기가 생기는거같습니다

    0
  • 마르세유1
    860
    2019-10-14 11:16:59

    TCP/IP 등 커널단에 이루어지는 네트워크는 90년대에 개발되어 그 시절에 맞추진것이 많죠..

    네트워크/시스템 환경이나, 성능 같은것들요


    UDP로 APP단에서 네트워크 스택을 HTTP3 프로토콜에 맞추어 개발하려는 시도같습니다.


    이제 TCP,나 UDP 를 손볼 시점이 온듯하네요

    0
  • AGUGU
    2
    2019-10-14 14:31:11

    좋은 글 감사합니다.

    글 댓글들도 왜 QUIC가 나왔는지, TCP의 흐름제어를 어떻게 가져갔는지 좋은 정보 감사합니다

    0
  • 로그인을 하시면 댓글을 등록할 수 있습니다.