Congestion Control
One aspect of performance/ is/ about how efficiently a transport protocol can use a network’s full (physical) bandwidth (i.e. roughly, how many packets per second can be sent or received).
성능의 한 측면은 전송 프로토콜이 네트워크의 전체(물리적) 대역폭을 얼마나 효율적으로 사용할 수 있는지에 관한 것입니다(즉, 대략 초당 몇 개의 패킷을 송수신할 수 있는지).
This in turn affects how fast a page’s resources can be downloaded.
이는 페이지의 리소스를 다운로드하는 속도에 영향을 미칩니다.
Some claim that QUIC somehow does this much better than TCP, but that’s not true.
QUIC가 TCP보다 어떻게든 훨씬 더 잘한다는 주장도 있지만, 그렇지 않습니다.
Did You Know?
A TCP connection, for example, doesn’t just start sending data at full bandwidth, because this could end up overloading (or congesting) the network.
예를 들어, TCP 연결은 데이터를 처음부터 전체 대역폭으로 보내지 않습니다. 왜냐하면 이렇게 하면 네트워크가 과부하가 걸릴 수 있기 때문이에요.
This is because, as we said, each network link/ has/ only a certain amount of data (it can (physically) process every second).
말씀드린 것처럼 각 네트워크 링크는 매초마다 (물리적으로) 처리할 수 있는 일정량의 데이터만 가지고 있기 때문입니다.
Give it any more and there is no option other than to drop the excessive packets, leading to packet loss.
더 많은 양을 주면 다른 선택이 없이 과도한 패킷을 삭제하게 되어 패킷 손실로 이어집니다.
As discussed in part 1, (for a reliable protocol like TCP), the only way/ to recover from packet loss is/ by retransmitting a new copy of the data, which takes one round trip.
Part 1에서 논의했듯이 TCP와 같은 신뢰할 수 있는 프로토콜의 경우, 패킷 손실로부터 복구하는 유일한 방법은 새로운 데이터 복사본을 다시 전송하는 것으로, 이는 한 번의 왕복 시간을 소요합니다.
(Especially on high-latency networks) (say, with an over 50-millisecond RTT), packet loss/ can/ seriously affect performance.
특히 지연이 높은 네트워크에서 (가령, 왕복 시간이 50밀리초 이상인 경우), 패킷 손실은 성능에 심각한 영향을 줄 수 있습니다.
Another problem is that we don’t know up front how much the maximum bandwidth will be.
또 다른 문제는 최대 대역폭이 얼마나 될지 미리 알 수 없다는 것입니다.
It often depends on a bottleneck somewhere in the end-to-end connection,/ but we cannot predict or know where this will be.
종종 엔드 투 엔드 연결 어딘가의 병목 현상에 의존하지만, 이것이 어디에 있을지 예측할 수도, 알 수도 없습니다.
The Internet also doesn’t have mechanisms (yet) to signal link capacities back to the endpoints.
인터넷에는 아직 엔드포인트에 연결 용량을 다시 표시하는 메커니즘도 아직 없습니다.
Additionally, even if we/ knew/ the available physical bandwidth, that wouldn’t mean we could use all of it ourselves.
게다가, 실제 사용 가능한 대역폭을 알았다 하더라도, 그것은 우리가 그것을 모두 사용할 수 있다는 것을 의미하지 않습니다.
Several users/ are (typically active on a network concurrently), (each of whom) need/ a fair share of the available bandwidth.
일반적으로 여러 사용자들이 네트워크에서 동시에 활동하는데, 각각의 사용자들은 사용 가능한 대역폭의 공정한 분배가 필요합니다.
As such, a connection/ doesn’t know/ how much bandwidth it can safely or fairly use up front,/ and this bandwidth can change as users join, leave, and use the network.
따라서, 연결은 처음에 안전하게 또는 공정하게 얼마나 많은 대역폭을 사용할 수 있는지 알지 못하며, 이 대역폭은 사용자들이 네트워크에 가입하고 나가고 네트워크를 사용함에 따라 변할 수 있습니다.
To solve this problem, TCP/ will (constantly) try to discover the available bandwidth over time (by using a mechanism called congestion control).
이 문제를 해결하기 위해 TCP는 혼잡 제어라는 메커니즘을 사용하여 시간이 지남에 따라 지속적으로 사용 가능한 대역폭을 발견하려고 합니다.
(At the start of the connection), it/ sends/ just a few packets (in practice, ranging between 10 and 100 packets, or about 14 and 140 KB of data) and/ waits one round trip (until the receiver sends back acknowledgements of these packets).
연결의 시작 부분에서 TCP는 단지 몇 개의 패킷을 보내며(실제로는, 약 10개에서 100개의 패킷, 또는 약 14KB에서 140KB의 데이터 범위를 가지며), 이 패킷들에 대한 확인 응답을 수신자가 되돌려 보낼 때까지 한 번의 왕복을 기다립니다.
(If they are all acknowledged), this/ means the network can handle that send rate,/ and we/ can try to repeat the process / but with more data (in practice, the send rate usually doubles with every iteration).
만약 모든 것들이 확인 응답을 받았다면, 이것은 네트워크가 그 송신률을 처리할 수 있다는 것을 의미하며, 우리는 그 과정을 더 많은 데이터와 함께 반복할 수 있지만 (실제로는, 송신률은 일반적으로 매 반복마다 두 배씩 증가합니다.)
This way, the send rate/ continues/ to grow until some packets are not acknowledged (which indicates packet loss and network congestion).
이 방법으로, 송신률은 계속 증가합니다. 일부 패킷이 확인 응답을 받지 않을 때까지, 이는 패킷 손실과 네트워크 혼잡을 나타냅니다.
This first phase is typically called a “slow start”.
첫번째 단계는 일반적으로 slow start라고 부릅니다.
(Upon detection of packet loss), TCP/ reduces/ the send rate,/ and (after a while) starts to increase the send rate again, albeit in (much) smaller increments.
패킷 손실이 감지되면, TCP는 송신률을 감소시키고, (일정 시간이 지난 후에) 송신률을 다시 증가시키기 시작합니다, 비록 (훨씬) 작은 증가량으로.
This reduce-then-grow logic is repeated for every packet loss afterwards.
이러한 축소-후-성장 로직은 이후 모든 패킷 손실에 대해 반복됩니다.
Eventually, this means that TCP will constantly try to reach its ideal, fair bandwidth share.
결국, 이는 TCP가 이상적이고 공정한 대역폭 공유에 도달하기 위해 지속적으로 노력한다는 것을 의미합니다.
This mechanism is illustrated in figure 1.
이 메커니즘은 그림 1에 나와 있습니다.
모르는 단어
bottleneck: 병목
concurrently: 동시에
discover: 발견하다
acknowledgements: 인정하다.
