%EB%A5%BC%20%EC%82%AC%EC%9A%A9%ED%95%A0%20%EB%95%8C%20TCP%20%ED%9D%90%EB%A6%84%EC%9D%80%20UDP%EC%99%80%20%EA%B3%B5%EC%A1%B4%ED%95%A9%EB%8B%88%EB%8B%A4..png)
모든 인터페이스를 제한하고 수정하기 위해 TC(트래픽 제어)를 사용하여 네트워크를 시뮬레이션하고 있습니다. 내 인터페이스는 HTB --- SFQ 형식입니다(조금 복잡하지만 단순화하겠습니다).
인터페이스 속도는 10mbps로 제한됩니다. 7mbps 속도로 A에서 B로 UDP 스트림을 보낸다고 가정해 보겠습니다. 그 후 동일한 호스트(A)에서 B로 TCP 스트림을 보냅니다. 출력 인터페이스에 SFQ가 있고 두 개의 스트림이 있으므로 스케줄러는 스트림당 5mbps를 보냅니다. 따라서 처음에 UDP 스트림은 2mbps의 대역폭을 잃게 됩니다.
물론 이것은 공정한 대기열에서 기대할 수 있는 것입니다. 전송하는 각 스트림에서 적절한 수의 패킷을 전송하기를 원할 것입니다. 그러나 일부 ACK 시간 초과 후 UDP 스트림은 7mpbs를 사용하고 TCP는 3mpbs를 사용하게 될 것으로 예상됩니다. 그러나 나는 시간 초과를 본 적이 없습니다. SFQ 대기열을 제거하면 모든 것이 예상대로 작동하고 TCP 트래픽은 3mpbs에 도달하고 UDP 트래픽은 7mbps에 도달합니다.
이게 정상인가요? 이것이 내가 기대해야 하는 것입니까? 이것이 정상적인 동작이라면 이는 특정 경로에 대해 상당한 TCP 트래픽이 있는 경우 손실을 원하지 않으면 UDP 트래픽에 50%만 사용할 수 있음을 의미합니다.
SFQ 대기열을 유지하는 방법이 있습니까?
답변1
이것은 예상됩니다. SFQ는 제한된 대역폭을 놓고 경쟁할 때 공정성에 근접한 TCP/TCP 친화적인 프로토콜을 시행합니다. 일부 트래픽이 공평한 분배보다 더 많이 얻어야 하는 경우 이를 분류하고 경쟁 SFQ 인스턴스를 우회해야 합니다. 이것이 HTB의 목적입니다(클래스 없는 TBF와 반대).
이것은 일반적인 전략입니다. 거기에는 몇 가지 실제 예제가 있지만 필요할 때 얻지 못했습니다. 일반적으로 우선순위가 더 높은 범주에 대한 대역폭은 다음을 방지하기 위해 제한됩니다.완전히다른 트래픽을 굶주리게 만드세요.
https://wiki.archlinux.org/index.php/Advanced_traffic_control#Hierarchical_Token_Bucket_.28HTB.29
http://lartc.org/howto/lartc.qdisc.filters.html
일부 UDP 트래픽은 TCP 친화적으로 설계되었습니다.빠른. UDP 트래픽을 필터링하는 경우 Chrome nightlies에서 다운로드하면 우선순위가 높은 대역폭이 포화될 수 있습니다. 공정성 관점에서 볼 때 이것은 말이되지 않습니다.
또한 SFQ를 FQ_CODEL로 바꾸고 싶을 때가 거의 확실합니다. 테스트 부하로 인한 지연.http://dslreports.com/speedtest, 또는 ping포화 테스트 중 하나에서만 가능합니다. (흥미로운 주의 사항이 있습니다. uTP를 사용하는 "백그라운드" 트래픽은 유도된 대기 시간을 100ms 미만으로 유지함으로써 작동합니다. CODEL 또는 이와 유사한 것을 사용하여 이보다 낮은 대기 시간을 고정하면 uTP 흐름은 실제로 포그라운드 트래픽이 되며 동일한 것에 대해 TCP와 경쟁합니다. 대역폭 공유).