저 지연 10GbE-> 1GbE 네트워크에 대한 TCP 혼잡 제어?

스위치에 10GbE로 연결된 서버와 동일한 스위치에 1GbE로 연결된 10 개의 클라이언트가 있습니다.

각 클라이언트에서 동시에 nuttcp를 실행하면 유선 속도에 가깝게 10 개의 TCP 스트림을 동시에 서버에 푸시 할 수 있습니다 (즉, 10 개의 클라이언트 모두에서 초당 100MB의 수줍음).

그러나 방향을 바꾸고 서버에서 클라이언트로 데이터를 보내면 (즉, 10 개의 TCP 스트림, 각 클라이언트로 하나씩 전송) TCP 재전송이 급증하고 성능이 초당 30, 20 또는 심지어 10MB로 떨어집니다. 클라이언트 당. 이 트래픽 패턴은 내가 관심있는 특정 응용 프로그램을 대표하기 때문에 이러한 숫자를 얻고 싶습니다.

내 서버가 비슷한 서버에 10GbE 연결을 통해 동일한 실험을 수행하여 10GbE 링크를 포화시킬 수 있음을 확인했습니다. 포트에 오류가없는 것을 확인했습니다.

마지막으로 수신기의 TCP 창 크기를 강제로 제한 (제한)하면 대역폭이 약간 더 높아질 수 있습니다 (30-40 메가 바이트 / 초). 매우 낮게 클램핑하면 재전송이 0이 될 수 있습니다 (대역폭이 매우 낮음).

따라서 스위치의 버퍼를 초과하여 정체로 인한 패킷 손실이 발생한다고 확신합니다. 그러나 TCP의 혼잡 제어 가이 문제를 잘 처리하고 결국 회선 속도의 50 % 이상으로 안정화되어야한다고 생각했습니다.

그래서 첫 번째 질문은 매우 간단합니다. 내 상황에 가장 적합한 TCP 혼잡 제어 알고리즘은 무엇입니까? 사용할 수있는 톤은 많지만 대부분 손실이있는 네트워크 나 고 대역폭의 높은 대기 시간 네트워크 또는 무선 네트워크를 대상으로하는 것 같습니다.

두 번째 질문 : 다른 방법이 있습니까?

1. 패킷 드롭이있을 때 창 크기가 크게 줄어들지 않는 알고리즘을 원할 것입니다. 창 크기가 급격히 감소하여 TCP 트래픽의 처리량이 급격히 감소합니다.

2. 스위치와 서버가 흐름 제어를 지원하는 경우 흐름 제어를 활성화하십시오. 이것이 얼마나 잘 작동하는지는 거의 전적으로 스위치의 실리콘과 펌웨어에 달려 있습니다. 기본적으로 스위치는 클라이언트에 연결된 포트에서 송신 정체를 감지하고 패킷이 어디에서 왔는지 확인하고 플로우 제어 프레임을 수신 포트로 (즉, 서버로) 보냅니다. 서버가 흐름 제어 프레임을 이해하면 전송 속도가 느려집니다. 모두 제대로 작동하면 스위치의 송신 버퍼에서 패킷 손실이 거의 발생하지 않는 최적의 처리량을 얻을 수 있습니다.