This is an extremely oversimplified explanation of congestion control.
이것은 혼잡 제어에 대한 매우 과도하게 단순화된 설명입니다.
In practice, many other factors are at play, such as bufferbloat/, the fluctuation of RTTs due to congestion/, and the fact that multiple concurrent senders need to get their fair share of the bandwidth.
실제로 다양한 요인들이 작용 중인데, 그 중에는 버퍼편향, 혼잡으로 인한 RTT 변동, 그리고 여러 동시 송신자가 공정한 대역폭을 확보해야 한다는 사실이 있습니다.
As such, many different congestion-control algorithms exist/, and plenty are still being invented today, with none performing optimally in all situations.
그 결과로 많은 다양한 혼잡 제어 알고리즘이 존재하며, 오늘날에도 여전히 많은 알고리즘이 개발되고 있지만, 어떤 것도 모든 상황에서 최적으로 작동하지 않는다는 것입니다
While TCP’s congestion control makes it robust,/ it also means it takes a while to reach optimal send rates,/ depending on the RTT and actual available bandwidth.
TCP의 혼잡 제어는 강건성을 제공하지만, 실제 사용 가능한 대역폭과 왕복 시간(RTT)에 따라 최적의 전송 속도에 도달하는 데 시간이 걸릴 수 있다는 것입니다.
For web-page loading, this slow-start approach/ can also affect (metrics such as the first contentful paint),/ because (only a small amount of data) (tens of to a few hundred KB) can be transferred in the first few round trips.
웹 페이지 로딩에서는 이러한 천천히 시작하는 방식이 첫 번째 콘텐츠 로딩과 같은 지표에도 영향을 줄 수 있습니다. 왜냐하면 처음 몇 번의 왕복 시간 동안에는 매우 적은 양의 데이터만 전송될 수 있기 때문입니다.
(You might have heard the recommendation to keep your critical data to smaller than 14 KB.)
당신은 중요한 데이터를 14KB보다 작게 유지하는 것을 권장했을 수도 있습니다.
Choosing a more aggressive approach could thus lead to better results on high-bandwidth and high-latency networks, especially if you don’t care about the occasional packet loss.
더 공격적인 접근을 선택하는 것은 고대역폭과 고 대기시간 네트워크에서 더 나은 결과로 이끌 수 있습니다, 특히 가끔씩의 패킷 손실에 상관하지 않는다면.
This is where I’ve again seen many misinterpretations about how QUIC works.
여기에서 다시 많은 사람들이 QUIC가 어떻게 작동하는지에 대해 잘못 해석한 것을 보았습니다.
As discussed in part 1, QUIC, in theory, suffers less from packet loss (and the related head-of-line (HOL) blocking)/ because it treats packet loss on each resource’s byte stream independently.
Part 1에서 논의한 바와 같이, QUIC는 (및 관련 H2D(Head-of-Line) 블록킹) 패킷 손실을 덜 겪습니다./ 각 리소스의 바이트 스트림에서 패킷 손실을 독립적으로 처리하기 때문입니다.
Additionally, QUIC runs over the User Datagram Protocol (UDP), which, unlike TCP, doesn’t have a congestion-control feature built in;/ it allows you to try sending at whatever rate you want and doesn’t retransmit lost data.
또한, QUIC는 TCP와는 달리 내장된 혼잡 제어 기능이 없는 사용자 데이터그램 프로토콜 (UDP) 위에서 실행됩니다. 이는 당신이 원하는 어떤 속도로든 보내는 것을 허용하고, 잃어버린 데이터를 다시 전송하지 않습니다.
This has led to many articles claiming that QUIC also doesn’t use congestion control,/ that QUIC can instead start sending data at a much higher rate over UDP (relying on the removal of HOL blocking to deal with packet loss), that this is why QUIC is much faster than TCP.
QUIC도 혼잡 제어를 사용하지 않고, 대신 QUIC는 UDP를 통해 훨씬 더 높은 속도로 데이터를 전송할 수 있으며, 이는 패킷 손실을 다루기 위해 HOL 차단을 제거하는 데 의존하기 때문에 QUIC가 TCP보다 훨씬 빠른 것이라고 많은 기사들이 주장하고 있습니다.
In reality, nothing/ could be (further from the truth): QUIC actually uses very similar bandwidth-management techniques as TCP.
실제로, 아무것도 진실과 더 멀지 않습니다: QUIC는 사실 TCP와 매우 유사한 대역폭 관리 기술을 사용합니다
It too starts with a lower send rate and grows it over time, using acknowledgements as a key mechanism to measure network capacity.
그것은 또한 낮은 송신률로 시작합니다 그리고 시간이 지남에 따라 성장합니다, 네트워크 용량을 측정하기 위한 주요 메커니즘으로 확인 응답을 사용합니다.
This is (among other reasons) because QUIC needs to be reliable in order to be useful for something such as HTTP,
다른 이유들 중 하나로, QUIC은 HTTP와 같은 것에 대해 유용하게 쓰이기 위해 신뢰할 수 있어야 합니다.
because it needs to be fair to other QUIC (and TCP!) connections, and because its HOL-blocking removal doesn’t actually help against packet loss all that well (as we’ll see below).
다른 QUIC (그리고 TCP!) 연결에 공정해야 하기 때문에, 그리고 HOL 차단 제거가 실제로는 패킷 손실에 대해 크게 도움이 되지 않기 때문에 (아래에서 볼 것입니다).
However, that doesn’t mean that QUIC can’t be (a bit) smarter about how it manages bandwidth than TCP.
그러나, 그것이 QUIC가 대역폭을 어떻게 관리하는지에 대해 TCP보다 조금 더 똑똑할 수 없다는 것은 아닙니다.
This is mainly because QUIC is more flexible and easier to evolve than TCP.
이것은 주로 QUIC가 TCP보다 더 유연하고 발전하기 쉽기 때문입니다.
(As we’ve said), congestion-control algorithms/ are/ still heavily evolving today/, and we will likely need to, for example, tweak things to get the most out of 5G.
우리가 이미 말한대로, 혼잡 제어 알고리즘들은 아직도 진화하고 있으며, 우리는 아마도 예를 들어 5G에서 최대한 많은 이점을 얻기 위해 사항들을 조정해야 할 것입니다.
However, TCP is typically implemented in the operating system’s (OS’) kernel, a secure and more restricted environment, which for most OSes isn’t even open source.
그러나 TCP는 일반적으로 운영 체제의 커널에 구현되는데, 이는 안전하고 더 제한적인 환경입니다, 대부분의 운영 체제에 대해서는 심지어 오픈 소스조차 아닙니다.
As such, tuning congestion logic is usually only done by a select few developers, and evolution is slow.
이에 따라서, 혼잡 로직 조정은 일반적으로 선택된 소수 개발자들에 의해서만 수행되며, 진화는 느립니다
(In contrast), most QUIC implementations/ are/ currently being done in “user space” (where we typically run native apps) and are made open source, explicitly to encourage experimentation by a much wider pool of developers (as already shown, for example, by Facebook).
대조적으로, 대부분의 QUIC 구현은 현재 사용자 공간에서 이루어지며, (일반적으로 네이티브 앱을 실행하는 곳에서 만들어지며), 명시적으로 훨씬 넓은 개발자들의 실험을 촉진하기 위해 오픈 소스로 만들어지고 있습니다. (이는 이미 Facebook 등에서 보여진 바 있습니다).
Another concrete example is the delayed acknowledgement frequency extension proposal for QUIC.
또 다른 구체적인 예로는 QUIC을 위한 지연 응답 주기 확장 제안이 있습니다.
While, by default, QUIC sends an acknowledgement for every 2 received packets,/ this extension allows endpoints to acknowledge, for example, every 10 packets instead.
기본적으로 QUIC은 각각의 2개의 수신된 패킷에 대한 응답을 보내지만, 이 확장은 엔드포인트가 예를 들어 각각의 10개의 패킷에 대해 응답을 할 수 있도록 허용합니다
This has been shown to give large speed benefits on satellite and very high-bandwidth networks, because the overhead of transmitting the acknowledgement packets is lowered.
이것은 위성 및 매우 높은 대역폭 네트워크에서 큰 속도 이점을 제공하는 것으로 나타났습니다. 응답 패킷을 전송하는 것의 오버헤드가 줄어들기 때문입니다.
Adding such an extension for TCP would take a long time to become adopted, while for QUIC it’s much easier to deploy.
이런 확장 기능 추가가 채택되기 위해서는 시간이 많이 소요될 것이지만, QUIC의 경우에는 훨씬 쉽게 배포됩니다.
As such, we can expect (that QUIC’s flexibility) will lead to more experimentation and better congestion-control algorithms over time, which could in turn also be backported to TCP to improve it as well.
따라서, 우리는 QUIC의 유연성이 시간이 지남에 따라 더 많은 실험과 더 나은 혼잡 제어 알고리즘으로 이끌 것을 기대할 수 있습니다. 이는 돌아가서 TCP로 역전파되어 그것을 더 좋게 만들 수도 있습니다.
모르는 단어
misinterpretations: 오역
원글: https://www.smashingmagazine.com/2021/08/http3-performance-improvements-part2/
