1 홉 거리에있는 Wi-Fi 라우터에 불규칙하고 때로는 매우 긴 핑 시간이 표시됩니다. 핑은 192.168.1.1때때로 400-800ms의 지연 시간을 제공합니다.

시도해야 할 것이 많지만 (펌웨어, 라우터 배치, AP 채널 등)이 방법을 좀 더 체계적으로 공격하고 싶습니다.

• 먼저, 네트워크 성능을 어떻게 시각화 할 수 있습니까?
• 그런 다음 주어진 구성의 성능을 어떻게 벤치마킹 하여 조정 후 안정적으로 비교할 수 있습니까?

이 serverfault 답변 에는 수행 할 작업에 대한 높은 수준의 지침이 있습니다. 마지막 단계는 정말 두려운 일입니다.

아래는 로컬 Wi-Fi 네트워크 내의 연결 상태를 이해 한 다음 인터넷 엔드 포인트에 대한 유용한 도구입니다.

와이파이 도구

NetSpot (Mac 용)

로컬 WiFI AP를 추적하고 SNR, 채널, 신호 강도와 같은 기본 데이터를 제공합니다. 또한 강도와 간섭을 나타내는 물리적 공간에 대한 기본 현장 조사를 수행 할 수도 있습니다. AP 검색 모드에서는 시간에 따른 신호 강도를 차트로 표시하여 배치를 테스트하고 간섭 가능성을 조정할 수 있습니다.

Android 용 Wi-Fi 속도 테스트

매우 도움이됩니다. 컴퓨터에서 간단한 Python 서버를 실행하면 앱에서 몇 가지 시나리오를 테스트하여 실시간 속도 피드백을 제공 할 수 있습니다.

또 다른 훌륭한 안드로이드 앱인 Wifi Analyzer 는 AP wifi 채널이 활성화 된 것에 대한 몇 가지 귀중한 견해를 가지고 있습니다. 많은 작업을 수행하지 않고도 AP 채널을 선택할 수있는 최고의 무료 도구 일 수 있습니다.

아이 퍼프

로컬 네트워크 성능을 이해하는 데 도움이되는 도구입니다. 하나는 서버로, 하나는 클라이언트로 두 개의 상자가 필요합니다. 여러 매개 변수를 설정하고 테스트를 실행하며 대역폭 및 지터에 대한 결과를 볼 수 있습니다. 결과를 차트로 만들고 매개 변수를 조정하기 위해 jPerf GUI 와 함께 사용하는 것이 좋습니다 .

brew install iperf
iperf -s # on server, next one on client
iperf -c 192.168.1.XXX -P 1 -i 1 -p 5001 -f m -t 60

인터넷 연결 상태

mtr (핑 및 추적 경로 결합)

모든 경로 추적 핑을 핑합니다. 트렌드 데이터를 제공합니다. 대단해

brew install mtr
mtr 8.8.4.4

speedtest-cli

일반적인 ookla speedtest.net 사의 CLI 버전. 프로젝트 관리자는 일관성이 없다고 선언하지만 여전히 큰 차이를 측정하는 것이 편리합니다.

wget -O speedtest-cli https://raw.github.com/sivel/speedtest-cli/master/speedtest_cli.py
chmod +x speedtest-cli
speedtest-cli --list | head # and chose a top server (sorted by distance)
speedtest-cli --server 2761 # re-use the same server

NPAD : 네트워크 경로 및 응용 프로그램 진단

최종 시스템 및 최종 네트워크 문제 해결을위한 자동 진단 서버. 테스트 배터리를 실행 한 후 다음 과 같은 결과 요약 페이지가 표시 됩니다. 이 NPAD 서버 리디렉션 링크 를 사용하여 가장 가까운 NPAD 서버를 찾고 테스트에 해당 호스트 이름을 사용하는 것이 좋습니다.

  wget http://netspeed.usc.edu:8000/diag-client.c
  cc diag-client.c -o diag-client
# ./diag-client <server_name> <port> <target_RTT> <target_data_rate_in_MB/S>
  ./diag-client ps.psc.xsede.org 8001 30 5

내 개인적인 결과 :

나는 여러 가지 일을 시도하고 (DD-WRT에서 토마토 펌웨어로 전환) 읽고 읽는 데 몇 시간을 보냈습니다. 그것은 네트워크 계층이 아니며 대부분 블루투스에서 오래된 RF 간섭이었습니다. 라우터에서 5 피트 이내에 컴퓨터, 블루투스 마우스 및 키보드가 있습니다. (그리고 오래된 라우터는 여전히 2.4Ghz에 충돌합니다.)

이를 위해 Android 용 Wifi 속도 테스트를 최대한 활용 하여 아파트에서 물건을 옮기는 동안 정기적으로 실행했습니다. 200ms 정도마다 업데이트가보고되므로 간섭으로 인해 패킷이 삭제 될 때 명확하게 전달됩니다.

Metageek 의 Common Sources of Interference 안내서를 읽는 것이 좋습니다 . 또한 InSSIDer 및 기타 Wifi 분석 도구를 양호하게 만듭니다.

내가 가지고 있지 않은 도구 중 하나는 물리적 스펙트럼 분석 미터였습니다. 휴대 전화와 랩톱은 Wi-Fi AP 만 감지 할 수 있지만 Bluetooth 또는 기타 RF 기반 기술의 간섭을 피할 수는 없습니다. Metageek은이 공간에 Wi-Spy 및 inSSIDer Office 와 같은 훌륭한 솔루션을 제공 하고 있으며 더 많은 도구가 AirShark 처럼 등장 할 것으로 기대 합니다.

위의 의견에서 언급했듯이 Wi-Fi 문제를 진단하는 데 일반적으로 사용되는 도구는 실제로이 문제를 일으킬 수 있습니다. Wi-Fi 네트워크를 스캔 할 때 라디오는 채널에서 나가야합니다. 일반적으로 AP는 프레임을 버퍼링하도록 AP에 지시하여 '슬립'한 다음 스캔 할 채널을 전환합니다.

또한 AirDrop이 도입 된 이후 iOS 및 OS X는 Wi-Fi 라디오 오프 채널을 사용하여 다른 AirDrop 서비스를 찾게되며 Yosemite는 주기적으로 채널을 통해 핸드 오프를 지원합니다.

그래서 라우터에 대한 Wi-Fi 핑 변동도있었습니다.

PING 192.168.0.1 (192.168.0.1): 56 data bytes
64 bytes from 192.168.0.1: icmp_seq=0 ttl=63 time=2.334 ms
64 bytes from 192.168.0.1: icmp_seq=1 ttl=63 time=1.813 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=63 time=2749.664 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=63 time=1748.912 ms
64 bytes from 192.168.0.1: icmp_seq=4 ttl=63 time=748.162 ms
64 bytes from 192.168.0.1: icmp_seq=5 ttl=63 time=1.796 ms
64 bytes from 192.168.0.1: icmp_seq=6 ttl=63 time=1.806 ms
64 bytes from 192.168.0.1: icmp_seq=7 ttl=63 time=1.991 ms
64 bytes from 192.168.0.1: icmp_seq=8 ttl=63 time=1.797 ms
64 bytes from 192.168.0.1: icmp_seq=9 ttl=63 time=1.832 ms
64 bytes from 192.168.0.1: icmp_seq=10 ttl=63 time=1.713 ms
64 bytes from 192.168.0.1: icmp_seq=11 ttl=63 time=1.819 ms
64 bytes from 192.168.0.1: icmp_seq=12 ttl=63 time=1.616 ms
64 bytes from 192.168.0.1: icmp_seq=13 ttl=63 time=1.748 ms
64 bytes from 192.168.0.1: icmp_seq=14 ttl=63 time=1.677 ms
64 bytes from 192.168.0.1: icmp_seq=15 ttl=63 time=3427.213 ms
64 bytes from 192.168.0.1: icmp_seq=16 ttl=63 time=2426.371 ms
64 bytes from 192.168.0.1: icmp_seq=17 ttl=63 time=1425.634 ms
64 bytes from 192.168.0.1: icmp_seq=18 ttl=63 time=424.834 ms
64 bytes from 192.168.0.1: icmp_seq=19 ttl=63 time=1.829 ms
64 bytes from 192.168.0.1: icmp_seq=20 ttl=63 time=1.691 ms
64 bytes from 192.168.0.1: icmp_seq=21 ttl=63 time=2.038 ms
64 bytes from 192.168.0.1: icmp_seq=22 ttl=63 time=1.679 ms
^C--- 192.168.0.1 ping statistics ---
23 packets transmitted, 23 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.616/564.346/3427.213/1015.102 ms

라우터를 TL-WR743ND에서 DIR-815로 전환하고 여러 Wi-Fi USB 어댑터 (대부분 TP-LINK도 시도했지만 D-Link DWA-160에 문제가 있다고 생각합니다)는 2.5GHz에서 5GHz는 채널을 닦았습니다. 운이 없다, 문제는 지속되었다.

네트워크 속도 테스트를 수행하거나 비트 토렌트 클라이언트를 실행할 때 핑은 괜찮습니다. 네트워크가 유휴 상태 일 때만 변동합니다.

Windows 7 문제이거나 TP-LINK 어댑터의 문제 일 수 있지만 Wi-Fi에 약간의 부하를 주면 변동이 사라지고 네트워크가 제대로 작동합니다.

지금까지 Wi-Fi 네트워크를 유지하기 위해 약간의 Rust 프로그램을 만들었습니다.

// Need a constant wifi load in order not to have the ping drops.
fn wifi_load() {
  // This *might* be useful if the router suddenly supports Keep-Alive.
  // Not the case with DIR-815 though, we'll keep making new connections to it.
  let config = hyper::client::pool::Config {max_idle: 1};

  let client = hyper::client::Client::with_pool_config (config);
  loop {
    let url = "http://192.168.0.1/css/init.css";
    if let Err (err) = client.get (url) .send() {
      log! ("wifi_load] Error fetching {}: {}", url, err);
      sleep (Duration::from_secs (9));}
    sleep (Duration::from_millis (100));}}