uTorrent를 사용하는 동안 DNS가 주기적으로 응답을 중지합니다.
문제는 너무 많은 대역폭 사용(라우터에서 컴퓨터로 볼 때)과 관련이 없는 것으로 보이지만 라우터에서 제공하는 일종의 플러드 방지(Windows에서 허용하는 것보다 더 많은 라우터로 들어오는 연결)와 관련이 있을 수 있습니다.
네트워크가 제대로 작동하도록 하려면 어떻게 해야 합니까(물론 uTorrent를 계속 사용할 수 있으면서도)?
답변1
비트토렌트 클라이언트적극적으로 동료들과 연결... 그리고 일부 라우터는 이것을 syn-flood로 해석합니다.
열린 연결
uTorrent가 로드되고 업로드/다운로드가 일시 중지되면(중지되지 않음) 동료와의 열린 연결을 유지합니다. 그 사이에도 수많은 인터넷 동료들은 귀하가 원하는 비트를 가지고 있는지 알아보기 위해 여전히 귀하에게 연결을 시도할 것입니다.
결국에는 OS에서 부과한 개방형 연결 제한(Windows 7에서는 10개 연결)에 도달하고 새 클라이언트의 연결이 라우터에서 대기하기 시작합니다.
대기 중인 클라이언트는 연결이 사용 가능한지 적극적으로 확인합니다. 이러한 공격적인 폴링은 라우터에 의한 syn-flood 공격으로 해석될 수 있습니다.
솔루션
- 비트토렌트 소프트웨어의 반개방 연결 제한을 OS에서 부과한 연결 제한보다 낮추십시오.
- 라우터/모뎀에서 IP 플러드 보호를 비활성화합니다.
대역폭 포화도
또한 uTorrent(또는 대량 트래픽) 연결이 무제한으로 실행되면 업로드(및 다운로드) 파이프가 최대 사용량에 도달하여 일부 "유지" 트래픽이 뒷자리로 밀려나게 되어 결국 네트워크 유용성이 감소하게 됩니다.
예는 다음과 같습니다.
- 고속 다운로드(토렌트 또는 기타)는 다운스트림 링크를 포화시킵니다.
- 사용자가 최근에 방문하지 않은 사이트를 탐색하려고 합니다. 컴퓨터가 원하는 사이트에 대한 DNS 정보 요청을 생성합니다. DNS 서버에 대한 요청의 "업로드"가 성공했습니다(업스트림 파이프 액세스에 대한 인증이 요청되지 않음).
- DNS 서버가 응답(또는 시도)하지만 다운로드 파이프가 다운로드 콘텐츠로 포화되어 있고 무언가를 삭제해야 하며 다운로드가 속도 유지에 공격적이기 때문에 사용자의 컴퓨터에 도달하려고 하면 응답이 중단됩니다. DNS 응답이 삭제됩니다(로컬 라우터에 도달하기 전 어느 시점에서).
업로드가 제한되지 않은 경우에도 동일한 일이 발생할 수 있습니다. 업로드가 포화되면 TCP-ACK라는 패킷("Hey, I got packet xyz 성공적으로" 유형의 응답으로 전송됨)이 중단되고 다운로드가 중단되어 웹 검색이 매우 불안정해집니다.
솔루션
- 연결의 최대 기능이 무엇인지 파악하고(개별적으로 위아래로) 대량 전송 클라이언트의 최대 속도를 해당 속도의 약 80% 이상 사용하지 않도록 설정하십시오. 이렇게 하면 DNS 및 TCP-ACK 패킷과 같은 항목이 대량 트래픽을 우회하고 신속하게 처리할 수 있는 "헤드룸"이 남게 됩니다.
- 특정 트래픽(DNS, IMCP Ping, TCP-ACK)이 다른 형태의 트래픽보다 우선 순위가 지정되고 일부 트래픽 형태(특히 토렌트)의 우선 순위가 해제될 수 있도록 트래픽 조절을 처리할 수 있는 라우터를 사용합니다. 이것이 내가 선호하는 방법입니다. 이렇게 하면 우선 순위가 더 높은 트래픽이 문제를 일으키지 않을 때 토렌트 트래픽에 전체 위쪽 및 아래쪽 파이프를 사용할 수 있다는 추가 이점을 제공할 수 있습니다.
- "잘못된" 트래픽을 제한하려면 1과 2를 조합하여 사용하십시오.
Linux/BSD 배포판의 트래픽 형성에 대한 자세한 정보에 관심이 있다면,모노월그리고IP캅둘 다 좋은 정보를 갖고 있어요.
답변2
나한테 그런 일이 있을 때,와이어샤크내 가장 친한 친구입니다.
하지만 먼저 다음 세 가지를 알아두는 것이 좋습니다.
ping이 작동한다고 해서 DNS(또는 다른 서비스)가 작동한다는 의미는 아니며 그 반대도 마찬가지입니다.
이는 ping이 완전히 다른 수준의 네트워크 모델에서 완전히 다른 프로토콜(ICMP, DNS는 IP와 UDP 및 TCP 조합을 사용함)을 사용하기 때문입니다. 개인 방화벽부터 라우터 수, 서비스가 실행되는 실제 호스트까지 진행 중인 모든 것은 잠재적으로 이들 중 하나를 버리고 다른 하나는 버리도록 구성할 수 있습니다(관리자의 편집증이든 일부 실패 사례든). 일반적으로 다른 것보다 ICMP에 발생합니다.
일반적으로 귀하의 (DNS) 요청인지 아니면 응답이 손실되는지 명확히 하는 것도 좋습니다.
글쎄, 당신이 사용하고 있는 특정 프로그램이 이것을 명확하게 해야 하지만 일반적으로 Wireshark GUI에서 직접 보는 것이 더 쉽습니다 :)
앞서 언급했듯이 DNS는 일반적으로 요청 및 응답 내용을 전달하는 방법으로 UDP를 사용합니다.
형제 TCP와 달리 UDP는 다음과 같은 방식으로 정의됩니다.보증 없음 패킷이 전혀 전달되지 않으며 실패에 대해 알리기 위해 라우터가 해야 할 일이 없습니다(할 수도 없음). (이것은 UDP의 또 다른 기능에 대한 희생입니다. 엄청나게 빠릅니다. 라우터는 보낸 사람이나 패킷 순서에 대한 정보를 유지할 필요가 없으며 단지 빠르게 전달하고 잊어버립니다. 라우터는 매우 안전하게 UDP보다 더 높은 우선순위를 부여할 수도 있습니다. TCP.)
일반적으로 내가 가장 먼저 할 일은 다음과 같습니다.
- Wireshark 시작
- 캡처 옵션을 클릭하세요.
- 캡처 필터의 경우
host 1.2.3.4귀하와 1.2.3.4 사이의 트래픽만 캡처하도록 설정하십시오. - 캡처 시작
- 이 방법으로 모두 실행한 후에는 명령을 시도해 보세요.
그러나 귀하의 마지막 업데이트에 따르면 저는 이 소프트웨어를 모르지만 확실히 uTorrent 클라이언트를 의심합니다. 예를 들어 홈 라우터에서 일부 제한에 도달하여 UDP 패킷을 버리기 시작하는 등 애플리케이션이 너무 많은 UDP를 보내는 것이 가능합니다.
답변3
나는 시도 할 것이다GRC의 DNS 벤치마크 도구. 사용하도록 구성된 DNS 서버뿐만 아니라 다른 많은 DNS 서버도 테스트합니다. 속도뿐만 아니라 신뢰성도 테스트합니다. 무료이며 설치할 필요가 없습니다(단, Windows에만 해당됩니다). 해당 페이지에는 DNS에 관한 좋은 정보도 많이 있습니다.
답변4
해결책을 찾았습니다. 완전히 이해하지는 못하지만 제대로 설명할 수 있는 사람이 있으면 답변으로 게시해 주세요. 다른 답변은 도움이 되지 않았기 때문에 그에게 현상금을 주겠습니다.
질문의 부록에서 언급했듯이 uTorrent는 문제와 관련이 있습니다. uTorrent를 닫으면 문제가 해결되었기 때문입니다. 나는 uTorrent를 닫을 필요 없이 문제를 해결하는 방법을 알아보기로 결정했습니다. ~ 안에이 스레드그리고이 하나(거기 사람들이 동일한 ISP와 라우터를 가지고 있기 때문에 매우 관련성이 있었습니다.) 비활성화해야 한다는 제안을 찾았습니다.IP 홍수 방지내 라우터에서 트릭을 수행했습니다! 문제와 해결책은 이국적이었고 아마도 라우터 Cisco EPC3925 또는 특정 ISP에 국한되었을 수 있습니다(유럽에서 인기가 있기 때문에 영어로 검색하기가 어려웠습니다).