Did You Know?
The official QUIC Recovery RFC 9002 specifies the use of the NewReno congestion-control algorithm.
공식 QUIC 복구 RFC 9002은 NewReno 혼잡 제어 알고리즘의 사용을 명시합니다.
While this approach is robust, it’s also somewhat outdated and not used extensively in practice anymore.
이 방법은 견고하지만, 다소 구식이며, 실제로는 더 이상 광범위하게 사용되지 않습니다
So, why is it in the QUIC RFC?
그렇다면 QUIC RFC에 있는 이유는 무엇입니까?
The first reason is that when QUIC was started, NewReno was the most recent congestion-control algorithm that was itself standardized.
첫번째 이유눈 QUIC가 시작될 때 NewReno는 그 자체로 표준화된 가장 최근의 혼잡 제어 알고리즘이었습니다.
More advanced algorithms, such as BBR and CUBIC, either are still not standardized or only recently became RFCs.
BBR과 CUBIC과 같은 더 고급 알고리즘들은 아직 표준화되지 않았거나 최근에 RFC가 된 것입니다.The second reason is that NewReno is a relatively simple set-up.
두번째 이유는 NewReno는 상대적으로 간단한 세팅 입니다.
Because the algorithms need a few tweaks to deal with QUIC’s differences from TCP, it’s easier to explain those changes on a simpler algorithm.
알고리즘들은 몇 가지 조정이 필요합니다. 이는 QUIC이 TCP와 다른 점을 다루기 위해서입니다, 그 변화들을 설명하는 것은 더 단순한 알고리즘에서 더 쉽습니다.
As such, RFC 9002 should be read more as “how to adapt a congestion-control algorithm to QUIC”, rather than “this is the thing you should use for QUIC”.
RFC 9002는 '어떻게 혼잡 제어 알고리즘을 QUIC에 적용할지'로 읽어져야 하며, '이것이 QUIC에 사용해야 할 것'으로 읽어져서는 안 됩니다.
Indeed, most production-level QUIC implementations/ have made/ custom implementations of both Cubic and BBR.
대부분의 상업용 수준의 QUIC 구현은 Cubic 및 BBR의 사용자 정의 구현을 만들었습니다.
It bears repeating that congestion-control algorithms are not TCP- or QUIC-specific; they can be used by either protocol, and the hope is that advances in QUIC will eventually find their way to TCP stacks as well.
혼잡 제어 알고리즘은 TCP 또는 QUIC 고유의 알고리즘이 아니며, 두 프로토콜 모두에서 사용할 수 있으며, QUIC의 발전이 결국 TCP 스택으로 가는 길을 찾을 것이라는 희망을 가지고 있습니다.
Did You Know?
Note that, next to congestion control is a related concept called flow control.
혼잡 제어와 함께 흐름 제어라는 관련 개념이 있음을 참고하세요.
These two features are often confused in TCP, because they are both said to use the “TCP window”, although there are actually two windows: the congestion window and the TCP receive window.
TCP에서는 이 두 가지 특징이 종종 혼동되는데, 실제로는 혼잡 창과 TCP 수신 창이라는 두 개의 창이 있습니다.
Flow control, however, comes into play a lot less for the use case of web-page loading that we’re interested in, so we’ll skip it here. More in-depth information is available.
그러나 웹 페이지 로딩 사용 사례에 대해서는 플로우 컨트롤이 훨씬 덜 작용하기 때문에 여기서는 생략하겠습니다.
WHAT DOES IT ALL MEAN?
QUIC is still bound by the laws of physics and the need to be nice to other senders on the Internet.
QUIC는 여전히 물리 법칙에 구속되어 있고 인터넷의 다른 송신자들에게 친절해야 할 필요성이 있습니다.
This means that it will not magically download your website resources much more quickly than TCP.
이것은 TCP보더 훨씬 더 빠르게 너의 웹사이트의 자원을 마법같이 다운로드 할 수 없다는 것을 의미합니다.
However, QUIC’s flexibility means that experimenting with new congestion-control algorithms will become easier, which should improve things in the future for both TCP and QUIC.
그러나 QUIC의 유연성은 새로운 혼잡제어 알고리즘을 더 쉽게 실험할 수 있음을 의미하고 이는 TCP와 QUIC 모두에게 앞으로 상황을 개선시켜 줄 것입니다.
모르는 단어
specifies: 명시하다
robust: 튼튼한, 강력한
outdated: 구식의, 시대에 뒤진
tweaks: 비틀다, 꼬집다
원글: https://www.smashingmagazine.com/2021/08/http3-performance-improvements-part2/
