중복 ACK 레코드의 원인은 무엇입니까?

여러 개의 중복 ACK 레코드를 표시하는 클라이언트 시스템에서 Wireshark 캡처를 검토하여 재전송 및 순서가 잘못된 패킷을 트리거합니다.

다음 스크린 샷에 나와 있습니다. .26은 클라이언트이고 .252는 서버입니다.

중복 ACK 레코드의 원인은 무엇입니까?

도움이된다면 더 많은 배경 :

하나의 특정 클라이언트 사이트에서 네트워크 처리량 문제를 조사하고 있습니다. 사용자 인터페이스 관점에서 인식되는 문제는 활용도가 낮은 1gbps WAN 연결에도 불구하고 데이터가 느리게 전송된다는 것입니다.

거의 모든 클라이언트 시스템에는 동일한 문제가 있으며 20 개 이상의 시스템에서 테스트되었습니다. 문제가없는 두 대의 기계를 찾았습니다. 우리는 그들의 구성에서 다른 것을 식별하는 과정에 있습니다. 우리는 문제가없는 두 머신에서, 오직 하나의 중복 된 ACK 레코드 만 보았습니다. 문제가있는 머신에는 일반적으로 3 개의 중복 ACK 레코드가 있습니다. 한 가지 주목할만한 차이점은 잘 작동하는 머신은 모두 네트워크 운영 팀의 구성원이며 다른 모든 머신은 "일반적인"직원을위한 것입니다. 기계는 표준으로되어 있지만 네트워크 관리자는 로컬 시스템을 변경했을 수 있습니다. 이는 우리가 연구하는 또 다른 측면입니다.

우리는 서버 에서 TcpMaxDupAcks 설정을 변경하려고 시도했지만 실제로 필요한 값은 5이고 유효한 범위는 1-3입니다.

서버는 Windows Server 2003입니다. 클라이언트는 모두 엔터프라이즈 관리 Windows XP입니다. 작동중인 두 클라이언트를 포함한 모든 클라이언트에는 시만텍 안티 바이러스가 설치되어 있습니다.

이 문제를 보여준 수백 개의 유일한 클라이언트 사이트입니다.

pathping 문제의 시스템에서도 56ms RTT 및 일관된 0/100 패킷 손실을 보여줍니다.

감사,

샘

참고 :이 캡처는 클라이언트 컴퓨터에서 수행되었다고 가정합니다.

TCP 시퀀싱에 대한 간략한 요약 : TCP는 두 응용 프로그램간에 바이트 스트림을 안정적으로 제공합니다. 이 경우 "신뢰할 수있는"이란 무엇보다도 TCP가 순서가 잘못된 데이터를 수신 응용 프로그램에 전달하지 않도록 보장합니다.

순서 번호를 사용하여 순서대로 신뢰할 수있는 전달이 구현됩니다. 각 스트림의 모든 패킷에는 32 비트 시퀀스 번호가 할당됩니다 (TCP는 사실상 두 개의 독립적 인 데이터 스트림 인 A-> B 및 B-> A 임). A가 ACK를 B로 보내는 경우 ACK 필드의 값은 A가 B에서 볼 것으로 예상되는 다음 시퀀스 번호입니다.

위에서 서버에서 클라이언트로 전송되는 TCP 세그먼트가 하나 이상 손실 된 것으로 보입니다. 순서대로 세 개의 중복 ACK는 클라이언트가 빠른 재전송 을 트리거하려는 시도 입니다. TCP 발신자가 동일한 데이터에 대해 3 개의 중복 수신 확인 (즉, 가장 최근에 전송 된 데이터가 아닌 동일한 세그먼트에 대한 4 개의 ACK)을 수신하면, ACK되는 세그먼트 직후의 세그먼트가 손실되었다고 합리적으로 가정 할 수 있습니다. 네트워크에 연결되어 즉시 재전송됩니다.

이 경우 재전송이 이루어지고 Wireshark에서 순서가 잘못된 것으로 식별됩니다.

joeqwerty 에서 언급했듯이 패킷 손실은 대부분 혼잡에 의해 발생합니다. 인터페이스 카드 불량, 케이블 연결 불량 등으로 인해 링크의 CRC 또는 기타 오류로 인한 것일 수도 있습니다. 경로를 따라 모든 링크의 통계를 살펴보고 경로가 많이 활용되고 있는지 및 / 또는 많은 오류가 발생했습니다.

확실한 후보를 볼 수없는 경우 경로를 따라 여러 지점에서 동시 패킷 캡처를 수행하여 손실이 발생하는 위치를 찾아 내십시오.

여기서 어떤 종류의 WAN 연결을 사용하고 있습니까? 전용선입니까? MPLS VPN 링크? 공용 인터넷을 통한 IPsec VPN? 다른 것?

문제가있는 곳을 격리하는 동안 패킷 덤프를 증상 중 하나라고 생각하십시오. 유 추적으로 누군가가 가슴 통증으로 의사의 진료실에 들어가면 의사는 3 시간 동안 의사의 성격을 조사하지 않습니다. 고통. 그는 약 2 분을 보낸 다음 원인의 95 %가 가슴 앓이 또는 협심증이라는 것을 알고 있습니다. 같은 방법으로 중복 ACK가 보이면 즉시 흔적의 잡초에 쥐 구멍을 뚫지 마십시오. .

연결이 설정된 후 전송 네트워크 문제로 인해 TCP 성능이 저하되는 것은 아닙니다. 때로는 서버 CPU 또는 디스크 제한으로 인해 발생하며 때로는 클라이언트 PC의 일부 문제로 인해 발생합니다. 몇 주 동안 wireshark 추적의 잡초에 파고 들어 mtr을 사용 하여 문제를 비교적 빨리 포기하고 찾기 위해 또는 CPU 및 디스크 I / O와 같은 다른 호스트 메트릭을 조사하여 꼬리를 쫓았습니다 .

첫 번째 작업은 이것이 네트워크 문제인지 또는 호스트 수준 문제인지를 증명하는 것입니다. 초점 네트워크를 통해 실시간 트래픽을 전송 및 증명에 대한 여부있는 거 대기 / 잃어버린 / 재 주문 ^{주 1} 이; 이는 항상 이와 같은 잠재적 인 네트워크 문제에 대한 최종 결론 입니다.

ping처리량 문제가 발생하는 동안 클라이언트와 서버간에 오랜 시간 (일반적으로 1 시간) 샘플링을 수행합니다 . 이를 위해 mtr 또는 ping 플로터 프리웨어 를 사용할 수 있습니다 . 일부 홉에서 지속적으로 패킷을 잃어버린 후 모든 홉이 많이 느슨하게 풀리면 네트워크가 의심 될 수 있습니다. 장치 ICMP 속도 제한으로 인해 일부 홉이 패킷을 잃어버린 것처럼 보일 수 있습니다. 그러므로 해당 홉에서 시작하는 트렌드와 그 이후의 트렌드를 찾고자합니다.

^{참고 1} 트래픽을 다시 주문 하는 경우 wireshark가 제공 하는 전문가 정보 필드 에 다소 빨리 나타납니다.

ACK없이 많은 [재 조립 된 PDU의 TCP 세그먼트] 를 많이 보아서 - 선택적인 승인 (일명 SACK) 행동 으로 인해 ACK가 [TCP Dup ACK ...] 로 표시 될 가능성이 높습니다 .

예:

• 클라이언트가 데이터 부분 (..., 0,1,2,3,4,5,6, ...)을 보냅니다.

• 서버가 acked (0), 수신 (2,4,3), (5), (6) 수신되지 않음 (1)

위 시나리오에서 서버는 (2-4) 범위, 먼저 (2-5) 범위, (2-6) 범위를 합법적으로 선택할 수 있습니다. "(AB) 범위 ack"패킷을 형성하는 동안 서버는 TCP 헤더에서 마지막으로 잠긴 부분 (0)을 지정해야합니다. Wireshark는 범위 헤더 (SACK)를 [TCP Dup ACK ...]로 표시 합니다. 모든 범위 범위는 TCP 헤더에서 마지막으로 확인 된 부품 값이 있기 때문입니다 (귀하의 경우 Ack = 872619).

네트워크 혼잡 문제와 같은 느린 네트워크 성능과 함께 ACK를 복제합니다. 네트워크의 브로드 캐스트 트래픽 양과 속도를 확인하십시오. 멀티 캐스트뿐만 아니라 물리 계층 및 네트워크 계층 브로드 캐스트도 확인하십시오.