uTorrent는 때때로 DNS 작동을 중지시킵니다

uTorrent를 사용하는 동안 DNS는 주기적으로 응답을 멈 춥니 다.

이 문제는 너무 많은 대역폭 사용과 관련이없는 것으로 보이지만 (라우터에서 컴퓨터로 보았을 때) 라우터가 제공하는 일종의 플러드 방지와 관련이있을 수 있습니다 (Windows보다 라우터에 더 많은 들어오는 연결이 허용 함).

네트워크가 제대로 작동하도록하려면 어떻게해야합니까 (물론 uTorrent를 계속 사용할 수 있습니까)?

bittorent 클라이언트는 적극적으로 피어에 연결합니다 ... 그리고 일부 라우터는 이것을 syn-flood로 해석합니다.

열린 연결

uTorrent가로드되고 업로드 / 다운로드가 일시 중지 (중지되지 않음)되면 피어와의 열린 연결을 유지합니다. 한편, 인터넷 동료 군단은 여전히 ​​당신이 원하는 비트가 있는지 알아 내기 위해 당신에게 연결을 시도합니다.

결국 OS에서 부과 한 열린 연결 제한 (Windows 7의 경우 10 개 연결)에 도달하고 새 클라이언트의 연결이 라우터에서 큐잉되기 시작합니다.

대기중인 클라이언트는 연결이 비어 있는지 적극적으로 확인합니다. 이 적극적인 폴링은 라우터에 의한 syn-flood 공격으로 해석 될 수 있습니다.

솔루션

• 비트 토런트 소프트웨어의 반 개방 연결 제한을 OS에서 부과 한 연결 제한보다 낮게 설정
• 라우터 / 모뎀에서 IP 플러드 보호를 비활성화합니다.

대역폭 채도

또한 uTorrent (또는 모든 대량 트래픽) 연결이 무제한으로 실행되면 업로드 (및 다운로드 가능) 파이프가 전체 사용량에 도달하여 일부 "유지"트래픽이 뒷좌석으로 이동하게되어 네트워크 유용성이 감소합니다.

예를 들면 다음과 같습니다.

1. 고속 다운로드 (토렌트 또는 기타)는 다운 스트림 링크를 포화시킵니다.
2. 사용자가 최근에 방문하지 않은 사이트를 탐색하려고합니다. 컴퓨터가 원하는 사이트에 대한 DNS 정보 요청을 생성합니다. DNS 서버에 대한 요청의 "업로드"에 성공했습니다 (업스트림 파이프 액세스에 도전하지 않음).
3. DNS 서버가 응답 (또는 시도)하지만 다운로드 파이프가 다운로드 컨텐츠로 가득 차고 무언가를 삭제해야하기 때문에 다운로드가 속도 유지에 적극적이므로 사용자의 머신에 접속하려고하면 응답이 끊어집니다. DNS 응답이 삭제됩니다 (로컬 라우터에 도달하기 전).

업로드가 제한되지 않은 경우에도 마찬가지입니다. 업로드가 포화되면 TCP-ACK ( "안녕하세요, 패킷 xyz를 얻었습니다"형식 응답으로 전송 됨)로 알려진 패킷이 끊어지면서 다운로드가 중단되어 웹 브라우징이 매우 고르지 않게됩니다.

솔루션

• 연결의 최대 기능 (개별적으로 위 아래로)이 무엇인지 파악하고 대량 전송 클라이언트의 최대 속도가 해당 속도의 약 80 %를 초과하지 않도록 설정하십시오. 이렇게하면 DNS 및 TCP-ACK 패킷과 같은 것들이 대량 트래픽을 우회하여 신속하게 처리 할 수있는 "헤드 룸"이 남습니다.
• 특정 형태의 트래픽 (DNS, IMCP Ping, TCP-ACK)이 다른 형태의 트래픽보다 우선 순위를 가질 수 있고 일부 형태의 트래픽 (특히 토렌트)이 우선 순위를 해제 할 수 있도록 트래픽 쉐이핑을 처리 할 수있는 라우터를 사용하십시오. 이것이 내가 선호하는 방법입니다. 이를 통해 우선 순위가 높은 트래픽이 문제가되지 않을 때 토렌트 트래픽에 풀 업 / 다운 파이프를 사용할 수 있다는 이점이 있습니다.
• 1과 2의 조합을 사용하여 "오작동"트래픽을 제한하십시오.

Linux / BSD 배포판을 구성하는 트래픽에 대한 자세한 정보가 필요하면 MonoWall 과 IPCop에 좋은 정보가 있습니다.

내가 그런 것을 가질 때, Wireshark 는 나의 가장 친한 친구입니다.

그러나 먼저 다음 세 가지를 이해하는 것이 좋습니다.

• Ping이 작동한다고해서 DNS (또는 다른 서비스)가 작동한다는 의미는 아니며 그 반대도 마찬가지입니다.

  핑은 완전히 다른 수준의 네트워크 모델에서 완전히 다른 프로토콜 (ICMP, DNS는 IP와 UDP와 TCP의 조합을 사용)을 사용하기 때문입니다. 개인 방화벽에서 라우터 수를 통해 서비스가 실행되는 실제 호스트에 이르기까지 어떤 것도 (관리자의 편집증 또는 실패 사례인지 여부에 관계없이) 이들 중 하나를 버리지 않도록 구성 할 수 있습니다. 일반적으로 ICMP에 발생합니다.

• 일반적으로 요청이 (DNS) 요청인지 또는 답글을 잃었는지 명확하게하는 것이 좋습니다.

  글쎄, 사용중인 특정 프로그램은 이것을 분명히해야하지만 일반적으로 Wireshark GUI에서 직접 볼 수 있습니다 :)

• 앞서 언급했듯이 DNS는 일반적으로 UDP를 사용하여 요청 및 응답 내용을 전달합니다.

  UDP와는 달리 UDP는 패킷 이 전혀 전달 될 것이라는 보장 이 없으며 라우터가 실패에 대해 알리기 위해 할 수도없고 할 수도 없는 방식으로 정의됩니다 . (이것은 UDP의 또 다른 기능에 대한 희생입니다. 엄청나게 빠릅니다. 라우터는 보낸 사람이나 패킷 순서에 대한 정보를 유지할 필요가 없으며 빠르게 전달하고 잊어 버릴 수 있습니다. TCP)

일반적으로 가장 먼저 할 일은 다음과 같습니다.

1. Wireshark 시작
2. 캡처 옵션을 클릭하십시오
3. 캡처 필터의 경우 host 1.2.3.4사용자와 1.2.3.4 간의 트래픽 만 캡처하도록 설정 하십시오.
4. 캡처 시작
5. 이 방법으로 모두 해고되면 명령을 시도하십시오.

그러나 마지막 업데이트를 기반으로 : 나는이 소프트웨어를 모르지만 uTorrent 클라이언트를 의심합니다. 응용 프로그램이 너무 많은 UDP를 보낼 수 있습니다. 예를 들어 홈 라우터에서 일부 제한에 도달하고 UDP 패킷을 버리기 시작합니다.

GRC 의 DNS 벤치 마크 도구를 사용해 볼 것 입니다. 사용하도록 구성된 DNS 서버와 다른 많은 DNS 서버를 테스트합니다. 속도뿐만 아니라 신뢰성도 테스트합니다. 무료이며 설치할 필요가 없습니다 (Windows 만 해당). 해당 페이지에도 DNS에 대한 많은 좋은 정보가 있습니다.

전 세계 어느 지역에 있는지 알고 싶습니다. google.com 및 8.8.8.8에 대한 tracert / traceroute 결과를 얻는 데 도움이됩니다.

라우터 나 Google 서버 연결로 인해 문제가 발생할 수 있습니다. 문제가 간헐적으로 발생하면 연결 상태가 좋지 않지만 인터넷 연결 문제를 분석 할 때 너무 많은 요소가있어 바로 대답 할 수 있습니다.

Google 네트워크에 과부하가 걸리는 경우가 있습니다. 매일 google.com에 대한 요청이 시간 초과되어 다시 시작해야하는 경우가 있으며 해당 국가의 로컬 서버를 사용합니다. 요청이 라우팅되는 Google 네트워크의 어느 세그먼트에 운이 좋으며 Google의 내부 요청 배포 알고리즘에 비효율적 일 수도 있습니다.

아마도 구글의 네임 서버와 같은 방식 일 것입니다. Google에 여러 가지가 있지만 요청이 일시적으로 과도하게로드 된 내부 서버 또는 네트워크 세그먼트로 라우팅 될 수 있습니다.

당신은 당신이 세계의 어느 부분에 있는지 언급하지 않았습니다. 미국에 있지 않은 경우 각 요청은 다른 경로를 사용하고 너무 많은 중간 서버에 의존하는 경우 가끔 문제 나 지연이 발생할 수 있습니다.

ISP의 "최적화"또는 가능한 결함, 또는 서버에서 전 세계적으로 부담을 분할하기 위해 Google이 수행 한 최적화는 말할 것도 없습니다.

원거리 DNS 서버를 사용하면 다른 방식으로 처벌을받을 수 있습니다. 보다 :

Google DNS / OpenDNS를 사용하는 것이 좋지 않은 이유
ISP의 DNS 또는 Google의 8.8.8.8을 사용해야합니까?

나는 그것을 완전히 이해하지 못했지만 해결책을 찾았습니다. 누군가가 그것을 올바르게 설명 할 수 있다면 답변으로 게시하십시오. 다른 답변이 도움이되지 않았기 때문에 그에게 현상금을 줄 것입니다.

질문의 부록에서 언급했듯이 uTorrent를 닫으면 문제가 해결 되었기 때문에 uTorrent는 문제와 관련이있었습니다. 나는 uTorrent를 닫을 필요없이 그것을 고치는 방법을 찾기로 결정했습니다. 에서 이 스레드 및 이 하나 (매우 관련 있었다 같은 ISP 및 라우터가이 사람 때문에) 내가 사용하지 않도록해야한다고 제안 발견 IP 홍수 보호를 내 라우터를하고 속임수를 썼는지! 문제는 Cisco EPC3925 라우터 나 특정 ISP (유럽에서 인기가 많기 때문에 영어로 영어를 검색하기가 어려운 이유)에 국한된 문제입니다.