수신 데이터를 형성 할 수있는 솔루션을 찾지 못한 이유 (그리고 머리 꼭대기를 모르는)를 찾지 못했지만 발신자가 수신자가 데이터를 얼마나 빨리받을 수 있는지 알 수 있습니다.

TCP / IP의 기본 설계는 소스가 대상으로 전송하는 모든 패킷에 대해 대상 ACK이 패킷을 수신했다는 응답을 패킷 과 함께 회신 할 때까지 기다려야 한다는 것입니다.

따라서 4Mbps 발신자와 56Kbps 수신자가있는 경우, 발신자는 수신자가 각 패킷에 응답하기 위해 패킷을 송신하는 사이에 대기해야합니다 (이 오버 헤드를 줄이기위한 기술적 세부 사항이 있지만 전제는 여전히 요약을 유지합니다) 수평).

발신자가 이미 56Kbps의 데이터를 전송 한 다음 조금 더 보내려고하면 어떻게됩니까?

패킷이 손실됩니다. (글쎄, 잠재적으로 스위치의 버퍼에 대기 중이지만 채워질 때 패킷이 손실됩니다). 패킷이 손실되었다 때문에, 수신기는 수신하지, 그리고 따라서 전송하지 ACK패킷. 보낸 사람은이 ACK패킷을받지 못하기 때문에 (전송되지 않았지만 손실되거나 네트워크 중단이 발생할 수 있기 때문에) 추가 패킷 을 다시 보내야합니다 . 패킷이 도착하고 ACK응답이 다시 돌아올 때까지 패킷을 다시 보내려고 시도 합니다.

요약하자면, 발신자가 수신자의 대역폭을 최대한 활용 한 후에는 통과 할 수있는 충분한 대역폭이 확보 될 때까지 다음 패킷을 계속 반복해서 다시 보내야합니다. 이렇게하면 클라이언트가받을 수있는 최대 속도로 전송 속도가 효과적으로 줄어 듭니다. (이 경우 패킷을 다시 보내야하는 횟수를 줄이는 최적화 방법이 있습니다. 기본적으로 발신자는 패킷을 다시 보내야 할 때마다 속도가 느려지지만이 간단한 설명의 범위를 벗어납니다.

답변

This is slightly trickier as we can't really influence how fast the internet
ships us data. We can however drop packets that are coming in too fast,
which causes TCP/IP to slow down to just the rate we want. Because we don't
want to drop traffic unnecessarily, we configure a 'burst' size we allow at
higher speed.

Now, once we have done this, we have eliminated the downstream queue totally
(except for short bursts), and gain the ability to manage the upstream queue
with all the power Linux offers.