tc 트래픽 형성에 HTB 및 CQB를 사용하면 일관성 없는 패킷 전송 간격이 발생합니다.

tc 트래픽 형성에 HTB 및 CQB를 사용하면 일관성 없는 패킷 전송 간격이 발생합니다.

중복이라면 죄송합니다https://serverfault.com/q/1076769/822163. 저는 먼저 그것을 만든 다음 Linux 및 Unix용 Stack Exchange가 올바른 장소라는 것을 깨달았습니다. 문제: 트래픽 조절을 위해 tc HTB 또는 CQB를 사용할 때 특정 간격 후에 전송된 처음 두 개의 패킷이 pcap 로그에 기록된 대로 연속적으로 전송됩니다. 네트워크 전달이 활성화된 우분투 18.4 중간 컴퓨터가 있습니다. 나는 송신 포트에서 일정한 비트 전송률 출력을 갖도록 트래픽을 형성하기 위해 HTB를 사용하여 tc를 실행하고 있습니다. 클라이언트는 서버에 가변 크기의 청크를 요청합니다. 서버는 각 청크 사이에 200ms 간격으로 전송 인코딩된 데이터 청크를 클라이언트에 보냅니다. 중간 컴퓨터를 사용한 설정의 경우 이러한 패킷은 중간 컴퓨터의 트래픽 셰이퍼를 통해 전달되어 500kbps의 고정 비트 전송률을 얻습니다. 오프로딩(TSO 및 GRO)을 비활성화하면 모든 n 바이트가 pcap에 의해 프레임화됩니다. 대부분의 1448B 패킷의 시간 간격은 24.224ms에 가깝고 이는 500kbps로 예상됩니다.

문제: 프레임이 순서대로 도착하더라도 시간 간격이 일관되지 않게 도착합니다. 200ms 간격 이후의 두 번째 큰 패킷(1448B)은 항상 첫 번째 패킷과 거의 연속됩니다. 늦게 도착하는 블록(654B)의 마지막 패킷의 스크린샷(첨부된 그림의 예에서 10.464ms 대신 24.224ms) 패킷 사이의 시간 간격입니다.

HTB를 사용한 TC 명령:

tc qdisc del dev eno1 root 2> /dev/null > /dev/null
tc qdisc add dev eno1 root handle 1:0 htb default 2
tc class add dev eno1 parent 1:1 classid 1:2 htb rate 500kbit ceil 500kbit burst 10 cburst 10 prio 2
tc filter add dev eno1 protocol ip parent 1:0 u32 match ip dst 192.168.2.103 flowid 1:2

계산에 실수가 없었다면 트래픽 쉐이핑에 사용하고 있는 TC의 토큰 처리로 인해 문제가 발생한 것일 수 있다고 생각합니다. 유휴 시간 동안 토큰이 쌓였다가 다음 패킷이 수신되면 연속으로 두 개의 패킷을 보내는 것 같습니다. 세 번째 패킷부터 토큰 소비율이 안정화됩니다. 이런 경우, 블록의 두 번째 패킷에 누적된 토큰을 사용하지 않도록 할 수 있는 방법이 있는지 알고 싶습니다.

tc 명령에서 다양한 옵션을 시도했으며 아래 CQB - 명령 참조도 사용해 보았습니다.https://lartc.org/lartc.html#AEN2233

관찰: 버스트 = 10을 줄이면 첫 번째 패킷과 두 번째 패킷 사이의 간격이 약간 증가합니다. TC 및 CQB:

tc qdisc del dev eno1 root 2> /dev/null > /dev/null
tc qdisc add dev eno1 root handle 1: cbq avpkt 5000 bandwidth 10mbit
tc class add dev eno1 parent 1: classid 1:1 cbq rate 500kbit allot 5000 prio 5 bounded isolated
tc class add dev eno1 parent 1:1 classid 1:10 cbq rate 500kbit allot 5000 prio 1 avpkt 5000 bounded
tc class add dev eno1 parent 1:1 classid 1:20 cbq rate 500kbit allot 5000 avpkt 5000 prio 2
tc filter add dev eno1 protocol ip parent 1:0 u32 match ip dst 192.168.2.103 flowid 1:10
tc filter add dev eno1 parent 1: protocol ip prio 13 u32 match ip dst 0.0.0.0/0 flowid 1:20

추가: 제안된 대로http://linux-ip.net/articles/hfsc.en/HFSC(참조)를 사용해 보았습니다. HFSC에 대한 도움이 필요합니다. 이것은 내가 사용하는 스크립트입니다.

tc qdisc del dev eno1 root 2> /dev/null > /dev/null
tc qdisc add dev eno1 root handle 1: hfsc
tc class add dev eno1 parent 1: classid 1:1 hfsc sc rate 1000kbit ul rate 1000kbit
tc class add dev eno1 parent 1:1 classid 1:10 hfsc sc rate 1000kbit ul rate 1000kbit
tc class add dev eno1 parent 1:1 classid 1:20 hfsc sc rate 10000kbit ul rate 10000kbit
tc class add dev eno1 parent 1:10 classid 1:11 hfsc sc umax 1480b dmax 53ms rate 400kbit ul rate 1000kbit
tc class add dev eno1 parent 1:10 classid 1:12 hfsc sc umax 1480b dmax 30ms rate 100kbit ul rate 1000kbit
tc filter add dev eno1 protocol ip parent 1:0 u32 match ip dst 192.168.2.103 flowid 1:11

내 결과물

tc class show eno1

산출:

class hfsc 1:11 parent 1:10 sc m1 0bit d 23.4ms m2 400Kbit ul m1 0bit d 0us m2 1Mbit 
class hfsc 1: root 
class hfsc 1:1 parent 1: sc m1 0bit d 0us m2 1Mbit ul m1 0bit d 0us m2 1Mbit 
class hfsc 1:10 parent 1:1 sc m1 0bit d 0us m2 1Mbit ul m1 0bit d 0us m2 1Mbit 
class hfsc 1:20 parent 1:1 sc m1 0bit d 0us m2 10Mbit ul m1 0bit d 0us m2 10Mbit 
class hfsc 1:12 parent 1:10 sc m1 394672bit d 30.0ms m2 100Kbit ul m1 0bit d 0us m2 1Mbit

이것이 무엇을 의미하는지 잘 모르겠습니다.

ul m1 0비트 d 0us

내 tc 명령에는

sc umax 1480b dmax 53ms

이 스크립트를 실행한 후 192.168.1.102로 ping을 시도합니다. 핑 응답이 거의 없고 ARP가 나타납니다.

192.168.2.100을 가진 사람은 누구입니까?

192.168.2.100은 내가 tc를 실행하는 IP 전달 포트의 IP 주소입니다.

이 명령은 주로http://linux-ip.net/articles/hfsc.en/ 방금 경로를 추가했습니다.

TC 필터 dev eno1 프로토콜 추가 ip parent 1:0 u32 match ip dst 192.168.2.103 flowid 1:11

누구든지 umax 및 dmax 문제에 도움을 줄 수 있다면 좋을 것입니다.

관련 정보