uTorrent khiến DNS thỉnh thoảng ngừng hoạt động

Trong khi sử dụng uTorrent, DNS định kỳ ngừng phản hồi.

Vấn đề dường như không liên quan đến việc sử dụng quá nhiều băng thông (như được thấy từ bộ định tuyến đến máy tính), nhưng có thể liên quan đến một số hình thức chống lũ do bộ định tuyến cung cấp (nhiều kết nối đến bộ định tuyến hơn Windows sẽ chấp nhận).

Làm cách nào để mạng hoạt động bình thường (trong khi vẫn có thể sử dụng uTorrent)?

các khách hàng không chuyên nghiệp kết nối mạnh mẽ với các đồng nghiệp ... và một số bộ định tuyến diễn giải điều này như một trận lụt.

Kết nối mở

Khi uTorrent được tải và tải lên / tải xuống bị tạm dừng (không dừng lại), nó sẽ duy trì các kết nối mở với các đồng nghiệp của bạn. Trong khi đó, các nhóm đồng nghiệp internet vẫn sẽ cố gắng kết nối với bạn để tìm hiểu xem bạn có bit nào họ muốn không.

Cuối cùng, bạn sẽ đạt đến giới hạn kết nối mở được áp dụng bởi HĐH của bạn (trong Windows 7, đây là 10 kết nối) và các kết nối từ các máy khách mới sẽ bắt đầu xếp hàng tại bộ định tuyến của bạn.

Khách hàng xếp hàng sẽ kiểm tra tích cực để xem kết nối có miễn phí không. Cuộc bỏ phiếu tích cực này có thể được hiểu là một cuộc tấn công đồng bộ bởi bộ định tuyến.

Các giải pháp

• hạ thấp giới hạn kết nối nửa mở của bạn trong phần mềm bittorent của bạn xuống dưới giới hạn kết nối do hệ điều hành của bạn áp đặt
• vô hiệu hóa bảo vệ lũ IP tại bộ định tuyến / modem của bạn.

Độ bão hòa băng thông

Ngoài ra, với kết nối uTorrent (hoặc bất kỳ lưu lượng truy cập lớn) nào không bị hạn chế, đường ống tải lên (và có thể tải xuống) đạt mức sử dụng đầy đủ, buộc một số lưu lượng "bảo trì" phải ngồi ở ghế sau, điều này làm giảm tính hữu dụng của mạng.

Đây là một ví dụ:

1. Tải xuống tốc độ cao (torrent hoặc cách khác) bão hòa liên kết xuôi dòng.
2. Người dùng cố gắng duyệt đến một trang web không được truy cập gần đây. Máy tính tạo một yêu cầu thông tin DNS cho trang web mong muốn. "Tải lên" yêu cầu lên máy chủ DNS thành công (không bị thách thức khi truy cập đường ống ngược dòng).
3. Máy chủ DNS phản hồi (hoặc cố gắng), nhưng phản hồi bị treo khi cố gắng truy cập vào máy của người dùng vì đường ống tải xuống đã bão hòa với nội dung tải xuống và vì phải bỏ thứ gì đó xuống và tải xuống rất tích cực về việc duy trì tốc độ, Phản hồi DNS bị hủy (tại một số điểm trước khi đến bộ định tuyến cục bộ).

Điều tương tự có thể xảy ra nếu tải lên không bị hạn chế. Khi tải lên bão hòa, các gói được gọi là TCP-ACK (được gửi dưới dạng phản hồi kiểu "Hey, tôi đã nhận được gói xyz thành công") bị treo, khiến quá trình tải xuống bị đình trệ, khiến trình duyệt web trở nên rất chắp vá.

Các giải pháp

• Chỉ ra khả năng tối đa của kết nối của bạn là gì (lên và xuống, riêng lẻ) và đặt tốc độ tối đa của các máy khách chuyển số lượng lớn của bạn để không sử dụng nhiều hơn khoảng 80% tốc độ đó. Điều này sẽ để lại "khoảng trống" cho những thứ như gói DNS và TCP-ACK để vượt qua lưu lượng lớn và được xử lý nhanh chóng.
• Sử dụng bộ định tuyến có thể xử lý việc định hình lưu lượng sao cho lưu lượng truy cập nhất định (DNS, IMCP Ping, TCP-ACK) có thể được ưu tiên trước các hình thức lưu lượng khác và một số hình thức lưu lượng truy cập (cụ thể là torrent) có thể được ưu tiên. Đây là phương pháp ưa thích của tôi. Điều này có thể mang lại lợi ích bổ sung khi cho phép đường ống lên xuống đầy đủ có thể sử dụng được cho lưu lượng torrent khi lưu lượng ưu tiên cao hơn không thách thức nó.
• Sử dụng một số kết hợp của 1 và 2 để hạn chế lưu lượng truy cập "sai".

Nếu muốn biết thêm thông tin về các bản phân phối lưu lượng truy cập Linux / BSD, cả MonoWall và IPCop đều có một số thông tin tốt.

Khi tôi có một cái gì đó như thế, Wireshark là người bạn tốt nhất của tôi.

Nhưng trước tiên, thật tốt khi nhận ra ba điều sau:

• Thực tế là ping đang hoạt động không có nghĩa là DNS (hoặc bất kỳ dịch vụ nào khác) đang hoạt động và ngược lại.

  Đó là bởi vì ping sử dụng giao thức hoàn toàn khác nhau (ICMP, trong khi DNS sử dụng IP và kết hợp UDP và TCP), trên một mô hình mạng hoàn toàn khác. Bất cứ điều gì trên đường đi, từ tường lửa cá nhân của bạn thông qua số lượng bộ định tuyến đến máy chủ thực tế nơi dịch vụ đang chạy đều có thể được cấu hình để loại bỏ một trong số này nhưng không phải cái khác (cho dù đó là hoang tưởng của quản trị viên hoặc một số trường hợp thất bại), mặc dù nó thường xảy ra với ICMP hơn những người khác

• Nói chung, cũng tốt để làm rõ liệu đó là yêu cầu (DNS) của bạn hoặc câu trả lời đang bị mất.

  Chà, chương trình cụ thể mà bạn đang sử dụng sẽ làm rõ điều này cho bạn nhưng theo nguyên tắc chung, bạn sẽ dễ dàng nhìn thấy nó hơn trong GUI của Wireshark :)

• Như tôi đã đề cập, DNS thường sử dụng UDP như một cách để phân phối nội dung yêu cầu và phản hồi.

  Trái ngược với anh em TCP, UDP được định nghĩa theo cách không có sự bảo đảm rằng gói tin sẽ được gửi đi và không có bộ định tuyến nào phải (cũng không thể) làm gì để cho bạn biết về sự thất bại. (Đây là sự hy sinh cho một tính năng khác của UDP: nó cực kỳ nhanh. Bộ định tuyến không phải giữ bất kỳ thông tin nào về người gửi cũng như thứ tự các gói, họ chỉ cần nhanh chóng chuyển qua và quên đi. Họ thậm chí có thể ưu tiên cao hơn cho họ TCP.)

Thông thường điều đầu tiên tôi sẽ làm là:

1. Bắt đầu Wireshark
2. Nhấp vào Tùy chọn chụp
3. Đối với bộ lọc Capture, được đặt host 1.2.3.4để đảm bảo bạn chỉ chụp lưu lượng giữa bạn và 1.2.3.4
4. Chụp
5. Một khi bạn đã khởi động theo cách này, hãy thử các lệnh của bạn

Tuy nhiên, dựa trên bản cập nhật mới nhất của bạn: Tôi không biết phần mềm này, nhưng tôi chắc chắn nghi ngờ ứng dụng khách uTorrent. Ứng dụng có thể gửi quá nhiều UDP, ví dụ như đã đạt đến giới hạn nào đó trên bộ định tuyến gia đình của bạn và nó bắt đầu ném các gói UDP đi.

Tôi sẽ thử công cụ Điểm chuẩn DNS từ GRC . Nó kiểm tra các máy chủ DNS mà bạn định cấu hình để sử dụng, cũng như nhiều máy chủ DNS khác. Nó không chỉ kiểm tra tốc độ của họ, mà còn độ tin cậy của họ. Nó miễn phí và không cần phải cài đặt (mặc dù chỉ là Windows). Cũng có rất nhiều thông tin tốt về DNS trên các trang đó.

Tôi muốn biết bạn đang ở khu vực nào trên thế giới và sẽ có kết quả tracert / traceroute cho google.com và cho ngày 8.8.8.8.

Vấn đề có thể do bộ định tuyến của bạn hoặc do kết nối của bạn với máy chủ của Google. Bản chất không liên tục của vấn đề của bạn có mùi của kết nối kém, nhưng đơn giản là có quá nhiều yếu tố khi phân tích các vấn đề kết nối Internet để đưa ra câu trả lời thẳng thắn.

Mạng của Google đôi khi có thể trở nên quá tải. Tôi có các trường hợp hàng ngày yêu cầu google.com hết thời gian và cần được khởi động lại và tôi sử dụng máy chủ cục bộ cho quốc gia của mình. Đó là một phần của sự may mắn khi phân đoạn yêu cầu của mạng Google được chuyển đến và thậm chí có thể có sự thiếu hiệu quả trong các thuật toán phân phối yêu cầu nội bộ của Google.

Nó có thể giống với các máy chủ tên của Google. Mặc dù Google có một vài trong số đó, yêu cầu có thể được chuyển đến một máy chủ nội bộ hoặc phân khúc mạng quá tải trong giây lát.

Bạn đã không đề cập đến phần nào của thế giới bạn đang nằm. Nếu bạn không ở Mỹ, thì mỗi yêu cầu có thể có một lộ trình khác nhau và có thể gặp sự cố hoặc sự chậm trễ thường xuyên nếu phụ thuộc vào quá nhiều máy chủ trung gian.

Không đề cập đến bất kỳ "tối ưu hóa" hoặc thiếu sót nào có thể có của ISP của bạn hoặc bất kỳ tối ưu hóa nào mà Google có thể đã thực hiện để phân vùng gánh nặng trên toàn thế giới trên các máy chủ của mình.

Sử dụng máy chủ DNS ở xa có thể phạt bạn theo những cách khác. Xem :

Tại sao sử dụng Google DNS / OpenDNS là một ý tưởng tồi
Tôi nên sử dụng DNS của ISP hoặc 8.8.8.8 của Google?

Tôi đã tìm thấy giải pháp, mặc dù tôi không hiểu hết về nó, nếu ai đó có thể giải thích chính xác, xin vui lòng gửi nó dưới dạng câu trả lời và tôi sẽ trả tiền cho anh ta, bởi vì những câu trả lời khác không giúp ích được gì.

Như tôi đã đề cập trong phần phụ lục của câu hỏi, uTorrent có liên quan đến vấn đề, bởi vì việc đóng uTorrent đã giải quyết vấn đề. Tôi quyết định tìm ra cách khắc phục mà không cần đóng uTorrent. Trong chủ đề này và chủ đề này (nó rất phù hợp vì mọi người có cùng ISP và bộ định tuyến) Tôi đã tìm thấy các đề xuất rằng tôi nên vô hiệu hóa bảo vệ chống lũ IP trên bộ định tuyến của mình và nó đã thực hiện thủ thuật! Vấn đề và giải pháp rất kỳ lạ, có thể là cụ thể đối với bộ định tuyến Cisco EPC3925 hoặc thậm chí với ISP cụ thể (phổ biến ở châu Âu, đó là lý do tại sao thật khó để tìm kiếm thứ gì đó bằng tiếng Anh).