QUIC IS FLEXIBLE AND EVOLVABLE
A final aspect of QUIC is that it’s specifically made to be easy to evolve.
QUIC의 마지막 측면은 진화하기 쉽도록 특별히 제작되었다는 것입니다.
This is accomplished in several different ways.
이것은 여러 가지 다른 방식으로 달성됩니다.
First, as discussed, the fact that QUIC is almost fully encrypted/ means/ that we only need to update the endpoints (clients and servers), and not all middleboxes, if we want to deploy a newer version of QUIC.
QUIC가 거의 완전히 암호화되어 있기 때문에, 우리가 새로운 버전의 QUIC를 배포하고자 할 때 중간 상자 모두를 업데이트할 필요 없이 엔드포인트(클라이언트와 서버)만 업데이트하면 됩니다.
That still takes time, but typically in the order of months, not years.
이 작업에는 아직 시간이 걸리지만 일반적으로 몇 년이 아닌 몇 달이 소요됩니다.
Secondly, unlike TCP, QUIC/ does not use/ a single fixed packet header to send all protocol meta data.
둘째, TCP와 달리 QUIC는 모든 프로토콜 메타 데이터를 전송하기 위해 단일 고정 패킷 헤더를 사용하지 않습니다.
Instead, QUIC/ has/ short packet headers /and uses a variety of “frames” (kind of like miniature specialized packets) inside the packet payload to communicate extra information.
대신, QUIC는 짧은 패킷 헤더를 가지고 있으며, 패킷 페이로드 내부에 여러 종류의 "프레임"을 사용하여 추가 정보를 통신합니다.
There is, for example,
예를 들면 다음과 같은 것이 있습니다.
an ACK frame (for acknowledgements), a NEW_CONNECTION_ID frame (to help set up connection migration), and a STREAM frame (to carry data), as shown in the image below.
ACK 프레임(인정용), a NEW_CONNECTION_ID frame(연결 마이그레이션을 설정하는 데 도움이 됨) 및 a STREAM 아래 이미지와 같이 프레임(데이터를 운반합니다).
This/ is mainly done as an optimization, because not every packet carries all possible meta data/ (and so the TCP packet header/ (usually) wastes/ quite some bytes — see also the image above).
이것은 주로 최적화를 위해 수행됩니다. 왜냐하면 모든 패킷이 모든 가능한 메타 데이터를 가지고 있지 않기 때문에 TCP 패킷 헤더는 보통 꽤 많은 바이트를 낭비합니다
A very useful side effect/ of using frames, however, is/ that defining new frame types as extensions to QUIC will be very easy in the future.
그러나 프레임 사용의 매우 유용한 부작용은 앞으로 QUIC에 대한 새로운 프레임 유형을 정의하는 것이 매우 쉬워질 것이라는 것입니다.
A very important one, for example, is the DATAGRAM frame, (which allows unreliable data to be sent over an encrypted QUIC connection).
매우 중요한 것 중 하나는, 예를 들어, DATAGRAM 프레임입니다. DATAGRAM 프레임은 암호화된 QUIC 연결을 통해 신뢰할 수 없는 데이터를 전송할 수 있도록 합니다
QUIC uses individual frames to send meta data, instead of a large fixed packet header.
Thirdly, QUIC/ uses/ a custom TLS extension/ to carry (what are called transport parameters).
세 번째로, QUIC은 전송 매개변수라고 불리는 것을 운반하기 위해 사용자 정의 TLS 확장을 사용합니다.
These allow the client and server to choose a configuration for a QUIC connection.
이것들은 클라이언트와 서버가 QUIC 연결을 위한 구성을 선택할 수 있게 합니다.
This means they can negotiate which features are enabled (for example, whether to allow connection migration, which extensions are supported, etc.)/ and communicate sensible defaults for some mechanisms (for example, maximum supported packet size, flow control limits).
따라서 사용 가능한 기능(예: 연결 마이그레이션 허용 여부, 지원되는 확장 기능 등)을 협상하고 일부 메커니즘(예: 지원되는 최대 패킷 크기, 흐름 제어 제한)에 대해 합리적인 기본값을 전달할 수 있습니다.
While the QUIC standard/ defines/ a long list of these, it/ also allows/ extensions to define new ones, again making the protocol more flexible.
QUIC 표준은 이러한 긴 목록을 정의하지만 이는 확장 기능들이 새로운 것들을 정의할 수 있게 허용하며, 이로써 프로토콜이 더 유연해집니다.
Lastly, while not a real requirement of QUIC by itself, most implementations are currently done in “user space” (as opposed to TCP, which is usually done in “kernel space”).
마지막으로, QUIC 자체의 실제 요구 사항은 아니지만, 대부분의 구현은 현재 "사용자 공간"에서 수행됩니다(일반적으로 "커널 공간"에서 수행되는 TCP와는 반대입니다).
The details are discussed in part 2, but this mainly means that it’s much easier to experiment with and deploy QUIC implementation variations and extensions than it is for TCP.
자세한 내용은 파트 2에서 설명하지만, 이는 주로 QUIC 구현 변형 및 확장을 TCP에 비해 훨씬 쉽게 실험하고 구현할 수 있음을 의미합니다.
Takeaway
While QUIC has now been standardized, it should really be regarded as QUIC version 1 (which is also clearly stated in the Request For Comments (RFC)), and there is a clear intent to create version 2 and more fairly quickly.
QUIC는 이제 표준화되었지만 실제로는 QUIC 버전 1로 간주되어야 하며(이는 Request For Comments(RFC)에도 분명히 명시되어 있음), 버전 2를 보다 신속하게 생성하려는 분명한 의도가 있습니다.
On top of that, QUIC allows for the easy definition of extensions, so even more use cases can be implemented.
여기에 QUIC을 사용하면 확장을 쉽게 정의할 수 있으므로 더 많은 사용 사례를 구현할 수 있습니다.
Conclusion
Let’s summarize what we’ve learned in this part.
이 부분에서 배운 내용을 정리해 보겠습니다.
We/ have (mainly) talked about the omnipresent TCP protocol /and how it was designed in a time when many of today’s challenges were unknown.
우리는 주로 오늘날 많은 과제가 알려지지 않은 시기에 보편적인 TCP 프로토콜과 그것이 어떻게 설계되었는지에 대해 이야기했습니다.
As we tried to evolve TCP to keep up, it became clear this would be difficult (in practice), because almost every device has its own TCP implementation on board that would need to be updated.
TCP를 지속적으로 발전시키기 위해 노력하면서, 거의 모든 기기에 업데이트가 필요한 자체 TCP 구현이 탑재되어 있기 때문에 실제로는 어려울 것이 분명해졌습니다.
To bypass this issue while still improving TCP, we created the new QUIC protocol (which is really TCP 2.0 under the hood).
TCP를 개선하면서 이 문제를 우회하기 위해 새로운 QUIC 프로토콜을 만들었습니다(이것은 실제로는 후드 아래에 있는 TCP 2.0입니다).
To make QUIC easier to deploy, it is run on top of the UDP protocol (which most network devices also support),/ and to make sure it can evolve in the future, it is almost entirely encrypted (by default) and makes use of a flexible framing mechanism.
QUIC를 쉽게 배포하기 위해 대부분의 네트워크 장치가 지원하는 UDP 프로토콜 위에서 실행되며, 미래에 진화할 수 있도록 기본적으로 거의 완전히 암호화되어 있으며 유연한 프레이밍 메커니즘을 사용합니다.
Other than this, QUIC mostly mirrors known TCP features, such as the handshake, reliability, and congestion control.
이 외에도 QUIC는 핸드셰이크, 신뢰성 및 혼잡 제어와 같은 알려진 TCP 기능을 대부분 미러링합니다.
The two main changes besides encryption and framing are the awareness of multiple byte streams and the introduction of the connection ID.
암호화와 프레이밍 외에 두 가지 주요 변경 사항은 여러 바이트 스트림에 대한 인식과 연결 ID의 도입입니다.
These changes were, however, enough to prevent us from running HTTP/2 on top of QUIC directly, necessitating the creation of HTTP/3 (which is really HTTP/2-over-QUIC under the hood).
그러나 이러한 변경 사항은 QUIC 위에서 HTTP/2를 직접 실행할 수 없도록 하기에 충분했으며, HTTP/3(정말 HTTP/2-over-Q)을 생성해야 했습니다.후드 아래 UIC).
QUIC’s new approach gives way to a number of performance improvements, but their potential gains are more nuanced than typically communicated in articles on QUIC and HTTP/3.
QUIC의 새로운 접근 방식은 여러 가지 성능 향상을 제공하지만, 잠재적인 이점은 QUIC 및 HTTP/3에 대한 기사에서 일반적으로 전달되는 것보다 훨씬 미묘합니다.
Now that we know the basics, we can discuss these nuances in more depth in the next part of this series.
이제 기본을 알았으니 이 시리즈의 다음 부분에서 이러한 뉘앙스에 대해 더 깊이 논의할 수 있습니다.
모르는 단어
configuration: 구성, 배열
omnipresent: 편재하는, 어디에나 있는
awareness: 의식, 인식, 자각
원글: https://www.smashingmagazine.com/2021/08/http3-core-concepts-part1/
