내 프로젝트에 문제가 있습니다. 우리는 Unix 서버에서 호스팅되는 애플리케이션을 지원합니다.
파트너는 여러 지역에서 동일한 콘텐츠에 액세스하려고 합니다. 이제 특정 지역의 일부 사용자는 "R"이 느린 속도에 대해 불평하고 있다고 말하고 있으며, 이는 해당 터미널의 네트워크 문제 때문일 수 있다고 믿을 만한 근거가 있습니다.
이것이 터미널의 네트워크 문제라는 것을 증명하기 위해 사용할 수 있는 터미널 시스템에서 어떤 명령을 실행할 수 있습니까?
그리고 지난 몇 분 동안 다른 웹 애플리케이션도 시스템에서 많은 시간을 차지하고 있다는 것을 증명할 수 있는 명령이 있습니까?
저는 UNIX를 처음 접했습니다. 미리 감사드립니다.
답변1
본질적인 한계
문제는 다양할 수 있습니다(예: ISP에 대한 링크의 정체 또는 ISP 내의 정체). 또한 끔찍할 수도 있습니다(방화벽이나 바이러스 백신도 심층 패킷 검사를 수행함). 아래 도구에는 전혀 문제가 표시되지 않을 수도 있습니다. 가질만한 가치가 있지만 터미널에 명령을 입력하여 수행할 수 있는 작업에는 한계가 있습니다.
당신이 알아야 할 2가지 테스트
ping
ICMP/IP를 통해 서버에 대한 왕복 대기 시간을 측정하는 데 사용됩니다 . 또한 서버traceroute
로 이동하여tracepath
처음 몇 홉의 왕복 대기 시간을 확인할 수도 있습니다. 주로 버퍼 팽창 증상을 확인하려고 하므로 링크가 완전히 사용된 경우에만 발생한다는 점에 유의하세요! ("부하 시 대기 시간" 측정).wget
curl --remote-name
전용 또는 다운로드 파일(단일 스트림)을 사용하여 사용 가능한 네트워크 다운로드 대역폭을 확인할 수 있습니다 . 영감이 부족하다면 Linux를 다운로드하는 것이 좋습니다 :-). 다운로드 링크를 찾아 마우스 오른쪽 버튼 클릭 메뉴에서 "링크 위치 복사"를 사용하세요. 현재 다운로드 속도가 표시되므로 다운로드가 완료될 때까지 기다리지 않아도 됩니다. Ctrl+C를 사용하여 취소하세요. 당신은 테스트할 수 있습니다거울서버와 동일한 지역에 있어야 합니다(중요할 수 있음). 터미널 사용을 고려하고 있다면 터미널이wget
존재한다는 것을 아는 것이 좋을 것 같습니다. 나는 개인적으로 사용하는 것을 선호합니다http://testmy.net/mirror.
기본적으로 그게 다야그것, 귀하가 제공한 정보를 기반으로 합니다. 결과 중 하나에는 주의 사항이 있습니다 ping
. 아래에서 강조하겠습니다.
ping
초기 테스트에 적합합니다. traceroute
전문가 도구입니다. 나는 이것을 traceroute
버퍼 팽창을 설명하기 위한 방법으로 제안할 뿐입니다. 그것이 의미하는 것처럼 보인다면 ... 실제로는 에서 볼 수 있는 라우터에서 사용하는 ping
것이 더 나을 수도 있습니다 .ping
traceroute
낮은 다운로드 속도가 직접적인 원인으로 과대평가되기 쉽습니다. 웹앱 아니요필요캐시되지 않은 이미지가 없는 한 사용자 요청에 응답하여 대량의 데이터를 제공합니다. 예를 들어 unix.stackexchange.com은 75K이고 4Mb/s로 다운로드하는 데 0.2초가 걸립니다. 그러나 테스트를 실행하는 것은 쉽고 퍼즐을 풀기 위한 몇 가지 데이터 포인트를 제공합니다.
패킷 손실(ping)이 얼마나 많은가요?
상당한 패킷 손실이 발생하면 다운로드 속도가 제한됩니다.특히 대륙간 거리에 걸쳐.
불행하게도 손실이 단기 거래에 미치는 영향은 다음과 같습니다.그보다 조금 더 복잡해요. 약 20Kb 전송의 경우 한 번의 손실로 인해 100% 이상 증가하지 않을 가능성이 높습니다. 서버(또는 클라이언트)의 첫 번째 패킷이 삭제되지 않는 한 전체 "수신 시간 초과"가 될 때까지 복구되지 않습니다.3초.
손실을 측정할 때 패킷 크기에 영향을 받을 수 있으므로 문제/경고가 있습니다. 측정 손실을 사용할 때 ping
기본적으로 작은 패킷을 사용한다는 점에 유의해야 합니다.. 이는 클라이언트와 서버의 첫 번째 패킷(각각 SYN/SYN-ACK)과 유사합니다. 즉, ping $SERVER
옵션 없이 실행할 때 5% 페널티가 표시된다면 해당 웹 애플리케이션을 사용하는 완벽한 경험을 기대할 수 없습니다. (즉, 20개의 사용자 작업 중 1개는 어떤 일이 발생하기까지 3초가 걸릴 것으로 예상됩니다. 특정 지속적인 연결은 이를 완화하지 않습니다.일반적인 웹 서버 구성)
ping -s 1400
예를 들어 UNIX에서 전체 크기 패킷에 대한 통계를 확인할 수 있습니다 . 원칙적으로 더 많은 요소(QoS라고도 알려진 라우터의 "우선순위")가 있을 수 있습니다. 특히 원하는 것은 커널이나 특정 응용 프로그램의 TCP 재전송 세부 정보입니다.패킷 추적.
엔드포인트에서는 링크가 혼잡한지, 링크가 물리적으로 불안정한지 여부를 구별하기 어렵습니다. 패킷 손실은 라우터가 TCP에 속도를 늦추도록 지시하는 방식입니다. 링크가 혼잡할수록 패킷 손실률이 높아집니다. 가장 좋은 희망은 패킷 손실이 높은 링크를 식별("증명")하고 액세스 권한이 있는 사람에게 이를 조사하거나 모니터링하도록 요청하는 것입니다.