openwrt를 사용하여 모든 네트워크 패킷에 2000ms 지연을 도입했습니다.네템기준 치수.
# This is run on the terminal of the OpenWRT router
tc qdisc add dev wlan1 root netem delay 2000ms
네트워크의 장치에 핑을 보낼 때 이것이 미치는 영향을 명확하게 볼 수 있습니다.
# ping 192.168.10.164
PING 192.168.10.164 (192.168.10.164): 56 data bytes
64 bytes from 192.168.10.164: seq=0 ttl=64 time=2001.956 ms
64 bytes from 192.168.10.164: seq=1 ttl=64 time=2010.677 ms
64 bytes from 192.168.10.164: seq=2 ttl=64 time=2004.216 ms
64 bytes from 192.168.10.164: seq=3 ttl=64 time=2001.451 ms
64 bytes from 192.168.10.164: seq=4 ttl=64 time=2005.981 ms
그러나 교환을 통해 메시지를 전달할 때 이러한 지연을 알아차리려고 하면 nc
무시되는 것 같습니다.
|---------------------|--------------------------------|
| Terminal 1 | Terminal 2 |
| (192.168.10.164) | 192.168.10.186 |
|---------------------|--------------------------------|
| # nc -l 2389 | |
| | # nc 192.168.10.164 2389 |
| | Hello |
| # NO 2s DELAY | |
| # ALMOST INSTANT | |
| Hello | |
|---------------------|--------------------------------|
내 질문은 다음과 같습니다
- 이것이 모듈이 잘못 구성된 경우라면
netem
모든 IP 패킷에 지연을 적용하는 올바른 모듈은 무엇입니까?
고쳐 쓰다 이는 netem 모듈의 버그로 인해 발생한 것 같습니다. 라우터가 재부팅되고 명령에 응답한 후 예상되는 지연이 발생했습니다.
답변1
ICMP와 TCP는 서로 다른 프로토콜이며, 명령이 ICMP 패킷에 영향을 미치는 경우 TCP 패킷에는 영향을 미치지 않습니다.
답변2
netem에 대한 문서는 여기에서 확인할 수 있습니다(https://wiki.linuxfoundation.org/networking/netem) 반면에 인터페이스가 올바른지 확인하셨나요? 일반적으로 opewwrt는 네트워크 장치를 생성하고 WLAN을 netem에 참조하며 nc 프로세스는 다른 장치와 연결된 다른 네트워크에 있을 수 있습니다.
답변3
qdisc를 추가한 것으로 보이며 192.168.10.164
186에서 ping할 때 요청 시간 대신 응답 시간으로 인해 2초 지연이 발생합니다.
netcat의 경우 Hello
트래픽은 186 -> 164로 흐르며 netem qdisc(인터페이스에 대한 입력이기 때문에)를 통과하지 않습니다. 하지만 자세히 살펴보면 연결을 열 때 2초 정도 지연되는 것을 볼 수 있습니다.
반대로 입력하면 지연을 확인할 수 있습니다.
다시 시작하는 경우 다시 시작한 후 반대 방향으로 테스트할 수 있나요? 즉, 186 대신 164를 입력합니까?