차례:
비디오: [ì¤íì¸í°ë·°]'ê°ìí ì¤í 리ì§'(IP SAN)ì ê´í 5ê°ì§ ê¶ê¸ì¦ (십월 2024)
네트워크 속도는 일반적으로 처리량으로 정의됩니다. 즉, 네트워크가 1 초 동안 파이프를 통해 펌핑 할 수있는 메가 비트 또는 기가비트 수입니다. 그것은 확실히 중요하지만 고려해야 할 또 다른 요소가 있습니다. 요즘에는 종종 원시 속도보다 중요하거나 때로는 더 중요합니다. 그 요소는 대기 시간입니다. 지연 시간을 정의하는 가장 좋은 방법은 지연입니다. 패킷 또는 패킷 그룹이 소스에서 대상으로 전송 될 때까지 걸리는 시간 범위이며 일반적으로 밀리 초 (ms)로 측정됩니다. 사용자는 일상적인 응용 프로그램을 사용하는 과정에서 지연 시간의 큰 차이조차 눈에 띄지 않습니다. 즉, 대기 시간에 민감한 앱을 사용하지 않는 한. 지연 시간에 민감한 앱 목록이 최근에 늘어나고 있기 때문에 지연 시간이 중요한 이유입니다. 대부분의 앱은 대기 시간을 느리게 조정할 수 있지만, 일부는 (특히 비디오 스트리밍 또는 다른 종류의 일정한 데이터 피드에 의존하는) 일부 대기 시간이 최소로 충족되지 않으면 멈출 수 있습니다.
대기 시간이란 무엇입니까?
클라우드 서비스에 영향을주는 두 가지 유형의 대기 시간이 있습니다. 하나는 데이터가 한 지점에서 다른 지점으로 네트워크를 통과하는 데 걸리는 시간입니다. 이는 연결의 "와이어 속도"에 의해 제한됩니다. 이는 유리 광섬유 케이블을 통과 할 때 빛의 속도 또는 Cat X 구리 케이블을 따라 흐르는 데이터의 신호 속도를 의미합니다. 모든 경우에 관련된 거리와 직접 관련이 있습니다. 가장 중요한 것은 클라우드 제공 업체에 더 가까이 다가 가거나 사용중인 클라우드 서비스에 가장 가까운 서버 위치를 선택하는 것 외에는 전송에 걸리는 시간으로 인한 지연에 대해 할 수있는 일은 없습니다. 그 옵션을 제공하십시오.
두 번째 유형의 대기 시간은 지연 처리 또는 때때로 불량 라우팅에 의해 생성됩니다. 데이터 패킷이 장치를 통과 할 때마다 라우터 나 스위치가 다음에 보낼 위치를 결정하는 동안 약간의 지연이 있습니다. 방화벽 또는 기타 보안 장치의 패킷 검사와 서버가 데이터 요청을 수신하고 대용량 저장소에서 찾은 후 요청에 따라 조치를 취하고 응답을 보내면 추가 지연이 발생합니다. 이러한 지연은 각각 짧을 수 있지만 더해진다. 때로는 데이터 센터에서 클라우드의 데이터로의 경로가 혼잡 한 경우 지연 및 대기 시간이 실제로 더해질 수 있습니다.
Traceroute로 대기 시간 측정
다행히 데이터 대기 시간을 측정하는 것은 매우 쉽고 비용이 들지 않습니다. 찾으려면 선택한 운영 체제 (OS)에서 명령 행을 실행하고 Traceroute 명령을 수행하십시오. Microsoft Windows의 경우 명령 프롬프트에서 "tracert"명령을 입력 한 다음 "aws.amazon.com"또는 "cloud.google.com"과 같이 대상 이름을 입력하십시오. (아래 스크린 샷 참조)
Apple OS X 또는 Linux에서 터미널 창으로 이동하여 traceroute -I companydomain.com을 입력하십시오 . 또는 도메인 이름을 실제 IP 주소로 바꿀 수 있습니다. traceroute가 ICMP (Internet Control Message Protocol)를 사용하여 대기 시간을 정확하게 측정하는 데 필요한 -I 스위치를 원합니다.
OS에 관계없이 화면에 표시되는 내용은 확인중인 웹 사이트 경로를 따라 각 라우터의 응답과 시간 측정 (ms)입니다. 그것들을 합하면 대기 시간입니다. 명령을 여러 번 실행하면 동일한 라우터가 항상 표시되지는 않습니다. 명령을 실행할 때마다 데이터 패킷이 다른 인터넷 경로를 사용할 수 있기 때문입니다. 일부 경로는 다른 경로보다 길어 전체 대기 시간이 길어질 수 있습니다. 인터넷 대기 시간에 오신 것을 환영합니다.
네트워크 관리 도구를 사용하여 대기 시간 측정
회사 네트워크를 담당하는 IT 전문가에게는 전선을 통해 실행되는 내용과 트래픽이 수행되는 방식을 파악할 수있는 일종의 네트워크 모니터링 도구가 있습니다. 다른 방법으로도 네트워크 대기 시간을 확인할 수 있습니다. 잘 작동하는 도구라면 자체 대기 시간 측정 기능이 있습니다. 예를 들어 Spiceworks에는 앞에서 설명한 표준 추적 경로 기능에 사용 된 ICMP 프로토콜 대신 TCP (Transmission Control Protocol)를 사용하는 자체 Traceroute 소프트웨어가 있습니다. Ping 명령에서도 사용됩니다. 일부 라우터는 ICMP 패킷에 응답하지 않도록 구성되어 있기 때문에 TCP가 더 정확할 수 있습니다.
또 다른 좋은 예는 Paessler PRTG 네트워크 모니터를 판매하는 Paessler AG입니다. 이 도구는 다른 기능과 함께 네트워크 대기 시간을 제공합니다. Paessler AG는 무료 평가판뿐만 아니라 해당 소프트웨어의 프리웨어 버전을 보유하고 있습니다. 향후 PCMag 검토를위한 도구를 테스트 할 때 지연 시간 기능을 포함한 PRTG 네트워크 모니터를 살펴볼 것입니다.
Paessler AG의 선임 시스템 엔지니어 인 Greg Ross는 "Pingler 시간 외에 매번 측정하는 경우 기본 대기 시간 측정 기준"이라고 설명합니다. "경로를 분할하고 경로의 각 홉에 대해 평가할 수 있습니다. 추적 경로 홉 수로이를 수행 할 수 있습니다.
Ross는“다른 측면은 저와 엔드 포인트 사이의 지터 및 왕복 시간을 확인하는 서비스 품질 모니터링입니다. 그는 이러한 모니터링은 지연된 패킷이나 순서대로 수신 된 패킷과 같은 대기 시간의 다른 원인을 보여줄 수 있다고 말했다.
지연 시간의 영향 감소
대기 시간이 길어 앱에 문제가있는 경우 제거 할 수 없더라도 대기 시간의 영향을 완화하기 위해 수행 할 수있는 몇 가지 작업이 있습니다. 첫 번째는 자체 DNS 서버가없는 경우 사용중인 DNS (Domain Name System) 서비스를 조사하는 것입니다. 대기 시간의 숨겨진 원인 중 하나는 사용중인 DNS 서버가 도달하려는 웹 사이트의 인터넷 프로토콜 (IP) 주소를 조회하는 동안 발생하는 지연입니다.
원격 DNS 서버는 단순히 성능이 좋지 않은 대기 시간을 유발합니다. 자체 서버가 있으면 주소가 서버의 테이블에있는 경우 조회 시간이 줄어 듭니다. 그렇지 않으면 다음 DNS 서버에 주소를 묻는 메시지가 표시 될 때까지 기다려야합니다. 자주 방문하는 웹 사이트의 경우 대기 시간이 단축 될 수 있습니다.
전용 연결을 사용하면 실제로 전용 인 경우 대기 시간이 단축되므로 정의 된 회선을 사용하여 연결해야합니다. 충분히 가까이 있거나 캐리어에서 회선을 임대 한 경우 물리적 인 광섬유 연결 일 수 있습니다. 이렇게하면 관련된 라우터 수를 줄이고 대기 시간을 유발할 수있는 라우팅 오류 가능성을 줄입니다.
물론 거리를 줄일 수 있습니다. M2 Optics가 제공 한 표에 따르면 100KM의 광섬유는 거의 500 마이크로 초의 대기 시간을 발생시킵니다. 0.5 밀리 초이므로 거리가 대기 시간을 어떻게 증가시킬 수 있는지 알 수 있습니다.
그 홉 수를 작게 유지
대기 시간을 처리하기 위해 어떤 "치료"를 사용하든 네트워크의 다른 측면에 어떤 영향을 미치는지 고려해야합니다. 예를 들어 재해 복구 (DR)에 클라우드를 사용하는 경우 데이터 센터에 충돌했을 때 재해가 발생하면 DR 사이트에 충돌하지 않기 때문에 너무 가까이 이동하면 자체 문제가 발생할 수 있습니다.
일반적으로 경로의 홉 수를 줄여 대기 시간을 줄일 수 있으며이 문제에 접근하는 방법에는 여러 가지가 있습니다. 앞에서 언급 한 것 외에도 혼잡으로 인한 대기 시간을 줄이기 위해 대역폭을 보장하거나 중복 공급자를 통해 앱이 실시간으로 대기 시간이 가장 짧은 경로를 선택할 수 있습니다.
물리 법칙을 위반하지 않고 대기 시간을 제거 할 수는 없지만 무시할 수는 없습니다. 실시간 스트리밍 분석, 화상 회의, 심지어 회사의 VoIP (Voice-over-IP) 트래픽과 같은 널리 사용되는 앱은 모두 대기 시간에 민감 해져서 문제가 발생하기 전에 네트워크 대기 시간을 파고 들게됩니다. 배당금을 줄입니다.
