What Is QUIC?
You might be wondering why this matters?
너는 왜 이 문제가 중요한지 궁금해할 수 있을 것이다.
Who cares if these features are in HTTP/3 or QUIC?
이러한 기능들이 HTTP/3 또는 QUIC에 있다면 누가 신경쓰겠어요?
I feel this is important, because QUIC is a generic transport protocol (which, much like TCP), can and will be used for many use cases in addition to HTTP and web page loading.
나는 이것이 중요하다고 느끼는데, QUIC는 TCP와 매우 유사한 일반적인 전송 프로토콜이며, HTTP 및 웹페이지 로딩 외에도 다양한 사용사례에 사용될 수 있을 것이기 때문입니다.
For example, DNS, SSH, SMB, RTP, and so on can all run over QUIC.
예를 들어, DNS, SSH, SMB, RTP 등은 모두 QUIC을 통해 실행될 수 있습니다.
As such, let’s look at QUIC a bit more in depth, because it’s here where most of the misconceptions about HTTP/3 that I’ve read come from.
따라서 QUIC에 대해 좀 더 자세히 살펴보겠습니다. 지금까지 읽은 HTTP/3에 대한 대부분의 오해가 여기에서 비롯되었기 때문입니다.
One thing you might have heard is that QUIC runs on top of yet another protocol, called the User Datagram Protocol (UDP).
들었을지도 모르는 것 하나는, QUIC가 또 다른 프로토콜, User Datagram Protocol(UDP)이라 불리는 것 위에 실행된다는 것입니다.
This is true, but not for the (performance) reasons many people claim.
이것은 사실입니다. 하지만 많은 사람들이 주장하는 (성능) 이유는 아닙니다.
Ideally, QUIC would have been a fully independent new transport protocol, running directly on top of IP in the protocol stack shown in the image I shared above.
이상적으로, QUIC는 완전히 독립적인 새로운 전송 프로토콜입니다, 위에 공유한 이미지에 표시된 프로토콜 스택의 IP 위에서 직접 실행됩니다.
However, doing that would have led to the same issue we encountered (when trying to evolve TCP): All devices on the Internet would first have to be updated in order to recognize and allow QUIC.
그러나 이렇게 하면 TCP를 발전시키려 할 때 우리가 마주했던 동일한 문제가 발생했을 것입니다. 먼저 QUIC를 인식하고 허용하려면 인터넷의 모든 장치를 업데이트해야 합니다.
(Luckily), we can build QUIC on top of the one other (broadly) supported transport-layer protocol (on the Internet): UDP.
다행히도, 우리는 인터넷 상에서 널리 지원되는 다른 하나의 전송 계층 프로토콜 위에 QUIC를 만들 수 있습니다: UDP.
Did You Know?
UDP is the most bare-bones transport protocol possible.
UDP는 가능한 가장 단순한 전송 프로토콜입니다.
It really doesn’t provide any features, besides so-called port numbers (for example, HTTP uses port 80, HTTPS is on 443, and DNS employs port 53).
포트번호 이외에는 실제로 어떠한 기능도 제공하지 않습니다. 예를 들어, HTTP 사용은 포트 80,HTTPS는 443 그리고 DNS는 53을 고용합니다.
It does not set up a connection with a handshake, nor is it reliable:
그것은 핸드셰이크로 연결을 설정하지 않으며 신뢰성이 없습니다.
If a UDP packet is lost, it is not automatically retransmitted.
만약 UDP 패킷이 손실되면 그것은 자동적으로 재전송되지 않습니다.
UDP’s “best effort” approach thus means that it’s about as performant as you can get:
UDP의 '최선의 노력' 방식은 그것이 당신이 얻을 수 있는 것과 같이 성능이 우수하다는 것을 의미합니다
There’s no need to wait for the handshake and there’s no HoL blocking.
핸드셰이크를 기다릴 필요가 없으며 HoL 차단도 없습니다.
In practice, UDP / is (mostly) used for live traffic (that updates at a high rate) / and thus suffers little from packet loss because missing data is quickly outdated anyway (examples include live video conferencing and gaming).
실제로 UDP는 대부분 고속으로 업데이트되는 라이브 트래픽에 사용되며, 따라서 누락된 데이터는 어쨌든 빠르게 구식이기 때문에 패킷 손실의 어려움을 거의 겪지 않습니다(예를 들어 라이브 화상 회의 및 게임).
It’s also useful for cases (that need low up-front delay); for example, DNS domain name lookups really should only take a single round trip to complete.
그것은 또한 낮은 전방 지연이 필요한 경우에 예를 들어, DNS 도메인 이름 검색은 한 번의 왕복만으로 완료해야하는 경우에 유용합니다.
Many sources / claim that HTTP/3 is built on top of UDP (because of performance).
많은 소스들이 HTTP/3이 성능 때문에 UDP 위에 구축되었다고 주장합니다.
They say that HTTP/3 is faster because, just like UDP, it doesn’t set up a connection and doesn’t wait for packet retransmissions.
그들은 HTTP/3이 UDP와 마찬가지로 연결을 설정하지 않고 패킷 재전송을 기다리지 않기 때문에 더 빠르다고 말합니다.
These claims are wrong.
그들의 주장은 틀렸습니다.
As we’ve said above, UDP is used by QUIC and, thus, HTTP/3 mainly because the hope is (that it will make them easier to deploy), because it is already known to and implemented by (almost) all devices onthe Internet.
위에서 언급한 바와 같이, UDP는 QUIC에 의해 사용되며, 따라서 HTTP/3는 인터넷 상의 (거의) 모든 장치에 의해 이미 알려져 있고 구현되어 있기 때문에 그들을 더 쉽게 배포할 수 있기를 희망하기 때문에 주로 사용됩니다.
On top of UDP, then, QUIC essentially reimplements almost all features that make TCP such a powerful and popular (yet somewhat slower) protocol.
UDP 위에 QUIC는 TCP를 강력하고 인기 있는 (하지만 다소 느린) 프로토콜로 만드는 거의 모든 기능을 재구현합니다.
QUIC is absolutely reliable, using acknowledgements for received packets / and retransmissions to make sure lost ones still arrive.
QUIC는 수신된 패킷에 대한 승인 및 재전송을 사용하여 손실된 패킷이 여전히 도착하는지 확인하는 등 절대적으로 신뢰할 수 있습니다.
QUIC also still sets up a connection and has a highly complex handshake.
또한 QUIC은 여전히 연결을 설정하고 매우 복잡한 핸드셰이크를 갖고 있습니다.
Finally, QUIC (also) uses so-called flow-control / and congestion-control mechanisms / that prevent a sender (from overloading) the network or the receiver,
QUIC은 일종의 플로우 제어 및 혼잡 제어 메커니즘을 사용합니다. 이 메커니즘들은 발신자가 네트워크나 수신자를 과부하시키는 것을 방지합니다.
but that also make TCP slower than what you could do with raw UDP.
그것은 TCP를 원시 UDP보다 느리게 만들어냅니다.
The key thing is that QUIC / implements these features in a smarter, more performant way than TCP.
중요한 것은 QUIC는 이러한 기능을 TCP보다 더 똑똑하고 성능이 우수한 방식으로 구현합니다.
It combines (decades of deployment experience / and best practices) of TCP (with some core new features).
그것은 TCP의 수십 년간의 배포 경험과 최고의 실천 방법을 몇가지 새로운 핵심 기능과 결합합니다.
We will discuss these features (in more depth) later in this article.
우리는 나중에 이러한 기능들을 더 깊게 논의할 것입니다.
TAKEAWAY
The key takeaway here is that there is no such thing as a free lunch.
여기서 중요한 점은 무료 점심 같은 것은 없다는 것입니다.
HTTP/3 isn’t magically faster than HTTP/2 just because we swapped TCP for UDP.
TCP를 UDP로 교환했다는 이유만으로 HTTP/3는 마법처럼 HTTP/2보다 빠르지 않습니다.
Instead, we’ve reimagined and implemented a much more advanced version of TCP / and called it QUIC.
대신 훨씬 더 발전된 버전의 TCP를 재구상하고 구현하여 QUIC라고 불렀습니다.
And because we want to make QUIC easier to deploy, we run it over UDP.
그리고 우리는 QUIC를 더 쉽게 배포하기를 원하기 때문에 UDP를 통해 실행합니다.
모르는 단어
thus: 따라서
suffers: (고통을)겪다, 경험하다
outdated: 구식의
acknowledgements: 인정
swapped: 교환하다.
원글: https://www.smashingmagazine.com/2021/08/http3-core-concepts-part1/
