TCP Dup ACK/재전송, 구성이 잘못되었나요?

TCP Dup ACK/재전송, 구성이 잘못되었나요?

현재 친구 LAN의 네트워크 문제를 조사 중입니다(다시). 인터넷 연결은 매우 느리고 불안정하며 때로는 서비스가 작동하지 않는 경우도 있습니다.

저는 Wireshark를 사용하여 한동안 트래픽을 모니터링했습니다. 나는 마침내 재현 가능한 문제, git pullssh작동하지 않는 문제 를 생각해냈습니다 . Wireshark 로그는 다음과 같습니다 git pull.

와이어샤크 로그

키 교환이 시작되면 TCP 재전송이 항상 시작됩니다. 서버가 내 컴퓨터에서 패킷을 수신하지 않거나 내 컴퓨터가 응답을 받지 못하고 있습니다. 나는 이것이 LAN의 다른 모든 네트워킹 문제의 원인이기도하다는 느낌을 받았습니다.

내가 생각해낸 것 중 하나는 1514조각화하지 않음 비트를 설정한 상태에서 모든 잘못된 패킷의 패킷 길이가 이지만 LAN 라우터는 MTU로 구성되어 있다는 것입니다 1492. . 1500​패킷이 너무 커서 라우터에 걸릴 수 있습니까?

또한 대부분의 보안 연결(https, ssh)이 영향을 받는 것으로 보이지만 항상 더 큰 패킷 크기가 필요할 수도 있습니다.

아시다시피 저는 네트워킹에 대한 경험이 많지 않습니다. 따라서 더 많은 경험을 가진 여러분 중 일부가 이에 대해 더 잘 이해할 수 있기를 바랍니다.

편집하다: 지금은 git pull다시 정상적으로 작동하고 있습니다. MTU 구성이 문제의 원인이 될 수는 없습니다.

답변1

"조각화하지 않음"이 표시된 대형 패킷은 정상입니다. 이것이 OS가 MTU 검색을 수행하는 방법입니다. 네트워크가 조용히 패킷을 조각화하도록 하는 대신 ICMP "조각화 필요" 오류가 반환될 것으로 예상합니다(올바른 MTU가 있음).

큰 패킷이 재전송되는 것을 보면 중간의 일부 라우터가 잘못 구성되어 ICMP 오류 패킷을 차단하거나 필요할 때 전송하지 않는다는 의미입니다.

답변2

중복 ack가 발생한 것 같아요오직수신자가 시퀀스 번호에 공백이 있는 것을 발견하면 패킷이 해당 경로로 가는 도중에 삭제되었음을 의미합니다. 따라서 문제는 192.168.0.8에서 원격 서버 방향으로 시작됩니다. 여러 번의 재전송에도 불구하고 응답이 없다는 사실(중복된 응답도 아님)은 아마도 무언가가 그 방향으로 완전히 잘못되었음을 의미할 것입니다. (원격 측에서 보낼 수 없지만 이는 이전의 중복 ack나 이후의 fin-ack와 일치하지 않음을 의미할 수 있습니다. 이는 1개가 아닌 2개의 문제가 있음을 의미합니다.)

다음은 몇 가지 아이디어입니다.

  • 연결이 불량한 공용 Wi-Fi 또는 3G를 통해 이루어지면 잠시 동안 100% 패킷 손실이 발생할 수 있습니다. 다른 서비스를 동시에 이용하여 서비스 중단으로 인해 영향을 받는지 확인해보세요.
  • 특정 연결에서 패킷을 삭제하기로 결정하기 전에 수행 중인 작업을 확인하는 데 약간의 시간이 걸릴 수 있는 프로토콜 인식 방화벽이 있습니다. 당신의 친구가 끌 수 있는 이국적인 방화벽을 실행하고 있습니까? ISP에는 몇 가지 사용 규칙이 있습니까?
  • 드라이버를 업데이트하거나 Linux 라이브 CD에서 부팅하여 동일한 일이 발생하는지 확인하십시오. 다른 서비스를 사용하여 연결의 다른 측면을 변경하여 문제의 범위를 좁혀보세요.

관련 정보