TCP 속도 테스터 알고리즘 질문 ​​

Question

저는 ISP 회사에서 일하고 있습니다. 우리는 고객을 위해 속도 테스트기를 개발하고 있지만 TCP 속도 테스트와 관련된 몇 가지 문제에 직면 해 있습니다.

한 클라이언트의 총 지속 시간은 10292 초이며 100MB를 전송하며 8192의 패킷 크기는 100.000.000/8192 = 12.202 패킷입니다. 클라이언트가 ACK를 전송하는 경우 많은 ACK가 전송되는 것처럼 보입니다. 클라이언트가 6000 개의 ACK를 보내고 RTT가 15ms 인 경우 - ACK의 경우 6000 * 7.5 = 45.000ms = 45 초입니까?

나는 메가 비트/s의이 계산을 사용하는 경우 : 나는 MBP/S에 결과를 얻을 것이다

(((sizeof_download_in_bytes/durationinseconds) /1000) /1000) * 8 = Mbp/s 

하지만 다음 TTL은 송신자와 클라이언트가 낮을 MBP/s의 사이에있는 이상 속도가 될 것입니다.

사용자가 서버에 더 가깝다는 것을 시뮬레이트하려면 Mbp/s의 최종 결과에서 ACK 응답 시간을 제거하는 것이 "합법적"입니까? 이것은 최종 사용자가 서버에 가깝게 시뮬레이션하는 것과 같을까요?

(((sizeof_download_in_bytes/(durationinseconds - 45sec)) /1000)/1000) * 8 = Mbp/s 

즉 유효합니다

그래서 나는 최종 사용자에게이 계산을 표시하는 것인가?

Answer 1

여기서 문제는 RTT가 너무 커서 전체 대역폭이 사용되지 않는다는 것입니다. 테스트 용도로 소켓 단위로 수행 할 수있는 TCP 창 크기를 늘리거나 system-wide을 늘릴 수 있습니다.

고객으로서 속도 테스트 프로그램이 차선의 시스템 설정을 알리고이를 해결할 수있는 옵션을 제공한다면 큰 도움이 될 것입니다.

TCP 윈도우 설정이 올바른 경우, 중요한 패킷 수를 잃지 않는 한 TCP 속도 테스트에서 RTT가 중요하지 않습니다 (하지만 결국이 값을 먼저 감지하려고합니다).

Answer 2

TCP는 윈도우 흐름 제어를 사용하며 일반적으로 다음 프레임을 보내기 전에 ACK를 기다리지 않습니다. ACK는 데이터 프레임과 동시에 진행되며 추가 벽시계 시간이 필요하지 않습니다. 최근의 모든 TCP 구현은 속도 손실없이 이러한 RTT 및 비트 전송률을 처리 할 수 ​​있습니다.

그래서 정확한 계산은 확실 정말 테스트 서버에 고객의 PC에서 8192 MTU를 네트워크를 가지고 있으며, 또한 번호 1

입니까? 1500 MTU의 이더넷 세그먼트가 존재하고 8192 바이트 송신 버퍼가 표준 1500 바이트 TCP 세그먼트로 TCP 스택으로 분할 될 가능성이 큽니다.

마지막으로 1024 바이트가 킬로바이트이고 1024 킬로바이트가 메가 바이트입니다.