밀리초 동안 싸우고 있습니다. 핑이 가장 낮은 서버를 선택하는 방법

많은 작업에서 클라이언트와 서버 간의 지연은 매우 중요합니다(예: 온라인 게임, 화상/음성 회의, IP 전화 통신, VPN 등). 서버가 IP 네트워크 수준에서 클라이언트와 너무 멀리 떨어져 있으면 지연(일반적으로 "핑", "지연"이라고 함)으로 인해 작업이 방해를 받습니다.

서버의 지리적 근접성이 항상 IP 라우팅 수준의 근접성과 같지는 않습니다. 예를 들어, 다른 국가의 서버는 귀하가 거주하는 도시의 서버보다 귀하에게 "가까울" 수 있습니다. 모두 라우팅 및 네트워크 구성의 특성 때문입니다.

모든 잠재 고객에게 최대한 가까운 서버를 선택하는 방법은 무엇입니까? IP 네트워크 연결이란 무엇입니까? 클라이언트를 가장 가까운 서버로 연결하는 방법은 무엇입니까? 기사를 통해 알아보겠습니다.

측정 지연

먼저 지연을 측정하는 방법을 알아보겠습니다. 프로토콜과 패킷 크기에 따라 지연이 달라질 수 있으므로 이 작업은 생각만큼 간단하지 않습니다. 또한 몇 밀리초 동안 지속되는 하락과 같은 단기 이벤트를 놓칠 수도 있습니다.

ICMP - 일반 핑

Unix ping 유틸리티를 사용하면 Windows용 ping 버전에서는 할 수 없는 패킷 전송 간격을 수동으로 설정할 수 있습니다. 패킷 사이에 긴 일시 중지가 있으면 패킷 사이에 무슨 일이 일어나고 있는지 전혀 알 수 없기 때문에 이는 중요합니다.

패키지 크기 (옵션 -s) - 기본적으로 ping 유틸리티는 64바이트 크기의 패킷을 보냅니다. 이렇게 작은 패킷의 경우 큰 패킷에서 발생하는 현상이 눈에 띄지 않을 수 있으므로 패킷 크기를 1300바이트로 설정하겠습니다.

패킷 사이의 간격 (옵션 -i) — 데이터 전송 사이의 시간입니다. 기본적으로 패킷은 0.1초에 한 번 전송되는데, 이는 매우 긴 시간이므로 실제 프로그램은 초당 수백, 수천 개의 패킷을 전송하므로 간격을 XNUMX초로 설정하겠습니다. 이 프로그램은 단순히 그 이하를 허용하지 않습니다.

결과적으로 명령은 다음과 같습니다.

ping -s 1300 -i 0.1 yandex.ru

이 디자인을 사용하면 지연에 대한 보다 현실적인 그림을 볼 수 있습니다.

UDP 및 TCP를 통한 핑

어떤 경우에는 TCP 연결이 ICMP 패킷과 다르게 처리되므로 프로토콜에 따라 측정값이 달라질 수 있습니다. 또한 호스트가 단순히 ICMP에 응답하지 않고 일반 핑이 작동하지 않는 경우도 종종 발생합니다. 예를 들어, 호스트가 평생 동안 하는 일이 바로 이것이다. microsoft.com.

공익 사업 핑 유명한 스캐너 nmap 개발자는 모든 패킷을 생성할 수 있습니다. 지연을 측정하는 데에도 사용할 수 있습니다.
UDP와 TCP는 특정 포트에서 작동하므로 특정 포트를 "ping"해야 합니다. TCP 80, 즉 웹 서버 포트를 ping해 보겠습니다.

$ sudo nping --tcp -p 80 --delay 0.1 -c 0 microsoft.com

Starting Nping 0.7.80 ( https://nmap.org/nping ) at 2020-04-30 13:07 MSK
SENT (0.0078s) TCP 10.0.0.1:63236 > 13.77.161.179:80 S ttl=64 id=49156 iplen=40  seq=3401731188 win=1480
SENT (0.1099s) TCP 10.0.0.1:63236 > 13.77.161.179:80 S ttl=64 id=49156 iplen=40  seq=3401731188 win=1480
RCVD (0.2068s) TCP 13.77.161.179:80 > 10.0.0.1:63236 SA ttl=43 id=0 iplen=44  seq=1480267007 win=64240 <mss 1440>
SENT (0.2107s) TCP 10.0.0.1:63236 > 13.77.161.179:80 S ttl=64 id=49156 iplen=40  seq=3401731188 win=1480
RCVD (0.3046s) TCP 13.77.161.179:80 > 10.0.0.1:63236 SA ttl=43 id=0 iplen=44  seq=1480267007 win=64240 <mss 1440>
SENT (0.3122s) TCP 10.0.0.1:63236 > 13.77.161.179:80 S ttl=64 id=49156 iplen=40  seq=3401731188 win=1480
RCVD (0.4247s) TCP 13.77.161.179:80 > 10.0.0.1:63236 SA ttl=42 id=0 iplen=44  seq=2876862274 win=64240 <mss 1398>

Max rtt: 112.572ms | Min rtt: 93.866ms | Avg rtt: 101.093ms
Raw packets sent: 4 (160B) | Rcvd: 3 (132B) | Lost: 1 (25.00%)
Nping done: 1 IP address pinged in 0.43 seconds

기본적으로 nping은 4개의 패킷을 보내고 중지합니다. 옵션 -c 0 패킷의 끝없는 전송을 활성화합니다. 프로그램을 중지하려면 Ctrl+C를 눌러야 합니다. 마지막에 통계가 표시됩니다. 평균 rtt(왕복 시간) 값이 101ms임을 알 수 있습니다.

MTR - 스테로이드에 대한 추적 경로

프로그램 MTR My Traceroute는 원격 호스트에 대한 경로를 추적하기 위한 고급 유틸리티입니다. 일반적인 시스템 유틸리티인 Traceroute(Windows에서는 Tracert 유틸리티임)와 달리 패킷 체인의 각 호스트에 대한 지연을 표시할 수 있습니다. ICMP뿐만 아니라 UDP 및 TCP를 통해서도 경로를 추적할 수 있습니다.

$ sudo mtr microsoft.com

(클릭 가능) MTR 프로그램 인터페이스. microsoft.com에 대한 경로 추적이 시작되었습니다.

MTR은 체인의 각 호스트에 대한 ping을 즉시 표시하며 프로그램이 실행되는 동안 데이터가 지속적으로 업데이트되고 단기적인 변경 사항을 볼 수 있습니다.
스크린샷은 노드 #6에 패킷 손실이 있음을 보여 주지만 실제로 이는 전적으로 사실이 아닙니다. 일부 라우터는 만료된 TTL이 포함된 패킷을 단순히 삭제하고 오류 응답을 반환하지 않을 수 있으므로 여기서 패킷 손실 데이터는 무시할 수 있습니다.

WiFi 대 케이블

이 주제는 기사와 전적으로 관련이 없지만 제 생각에는 지연이라는 맥락에서 매우 중요합니다. 저는 WiFi를 정말 좋아하지만, 케이블로 인터넷에 연결할 수 있는 기회가 조금이라도 생기면 그것을 사용하겠습니다. 나는 또한 사람들이 WiFi 카메라를 사용하지 못하도록 항상 권장합니다.
진지한 온라인 슈팅 게임을 플레이하거나, 비디오를 스트리밍하거나, 증권 거래소에서 거래하는 경우: 케이블을 통해 인터넷을 사용하십시오.

WiFi와 케이블 연결을 비교하는 시각적 테스트는 다음과 같습니다. 이것은 WiFi 라우터, 즉 아직 인터넷에도 연결되지 않은 핑입니다.

(클릭 가능) 케이블과 WiFi를 통한 WiFi 라우터에 대한 핑 비교

WiFi를 통해 지연이 1ms 더 길어지고 때로는 1배 더 긴 지연이 있는 패킷이 있는 것을 볼 수 있습니다! 그리고 이것은 단지 짧은 시간일 뿐입니다. 동시에 동일한 라우터는 <XNUMXms의 ​​안정적인 지연을 생성합니다.

위의 예에서는 802.11GHz의 WiFi 2.4n이 사용되며 노트북과 휴대폰만 WiFi 액세스 포인트에 연결됩니다. 액세스 포인트에 더 많은 클라이언트가 있으면 결과는 훨씬 더 나쁠 것입니다. 이것이 바로 제가 케이블을 통해 연결할 수 있는 모든 사무실 컴퓨터를 WiFi로 전환하는 것을 반대하는 이유입니다.

IP 연결

이제 우리는 서버에 대한 지연을 측정하는 방법을 배웠습니다. 우리에게 가장 가까운 서버를 찾아보겠습니다. 이를 위해 공급자의 라우팅이 어떻게 작동하는지 확인할 수 있습니다. 이를 위해 서비스를 이용하면 편리합니다. bgp.he.net

사이트에 접속하면 우리의 IP 주소가 자율 시스템에 속해 있음을 알 수 있습니다. AS42610.

자율 시스템의 연결 그래프를 보면 우리 공급자가 어떤 상위 공급자를 통해 전 세계와 연결되어 있는지 확인할 수 있습니다. 각 점을 클릭할 수 있으며, 들어가서 어떤 종류의 공급자인지 읽을 수 있습니다.

공급자의 자율 시스템의 연결 그래프

이 도구를 사용하면 호스팅을 포함한 모든 공급자의 채널이 어떻게 구성되어 있는지 연구할 수 있습니다. 어떤 제공업체에 직접 연결되어 있는지 확인하세요. 이렇게 하려면 bgp.he.net 검색에 서버의 IP 주소를 입력하고 자율 시스템의 그래프를 살펴봐야 합니다. 또한 하나의 데이터 센터 또는 호스팅 공급자가 다른 데이터 센터 또는 호스팅 공급자와 어떻게 연결되어 있는지 이해할 수 있습니다.

대부분의 트래픽 교환 지점은 교환 지점의 특정 라우터에서 핑 및 경로 추적을 수행할 수 있는 거울이라는 특수 도구를 제공합니다.

예를 들어, 거울 MGTS에서

따라서 서버를 선택할 때 다양한 트래픽 교환 지점에서 서버가 어떻게 보일지 미리 확인할 수 있습니다. 그리고 잠재 고객이 특정 지리적 영역에 있는 경우 서버에 대한 최적의 위치를 ​​찾을 수 있습니다.

가장 가까운 서버를 선택하세요

우리는 고객을 위한 최적의 서버를 찾는 절차를 단순화하기로 결정하고 근처 위치를 자동으로 테스트하는 페이지를 만들었습니다. RUVDS 데이터 센터.
페이지를 방문하면 스크립트는 브라우저에서 각 서버까지의 지연을 측정하여 대화형 지도에 표시합니다. 데이터센터를 클릭하면 테스트 결과와 함께 정보가 표시됩니다.

버튼을 누르면 모든 데이터 센터의 대기 시간 테스트 페이지로 이동됩니다. 테스트 결과를 보려면 지도에서 데이터 센터 지점을 클릭하세요.

출처 : habr.com