Tỷ lệ lưu lượng đến hạn chế

Tôi chưa bao giờ hiểu được liệu có thể giới hạn lưu lượng đến hạn chế hay không. Tôi nhận thấy rằng không có phương pháp trực tiếp nào để kiểm soát tốc độ gửi gói của máy chủ từ xa (trừ khi bạn kiểm soát cả hai điểm cuối), nhưng tính đến giới hạn này, cách chính xác các trình quản lý tải xuống cho phép tôi đặt thành công giới hạn tốc độ tải xuống ?

Có liên kết nào giữa TCP khởi động chậm và lưu lượng đến hạn chế tốc độ không? Có thể sử dụng các phương thức được mô tả bằng cách khởi động chậm để hạn chế giả tạo tốc độ gửi gói của người gửi không?

Khi xem xét bổ sung, cần lưu ý rằng máy chủ mà tôi muốn triển khai định hình lưu lượng truy cập sẽ tự thiết lập kết nối PPPoE và hoạt động như một bộ định tuyến cho phần còn lại của mạng.

Cập nhật: Các câu trả lời cho đến nay đã đưa ra một cái nhìn tổng quan công bằng về các câu hỏi tôi đã hỏi, nhưng tôi vẫn không biết làm thế nào các nhà quản lý tải xuống có thể hạn chế lưu lượng truy cập đến, và cụ thể hơn, liệu có thể thực hiện chiến lược tương tự trên một Hộp cổng Linux.

Các trình quản lý tải xuống rất có thể hoạt động như được giải thích trong bài báo nhỏ giọt .

Một quy trình sử dụng các ổ cắm BSD có thể thực hiện giới hạn tốc độ của chính nó. Để giới hạn ngược dòng, ứng dụng có thể thực hiện việc này bằng cách đơn giản giới hạn tốc độ dữ liệu được ghi vào ổ cắm. Tương tự, đối với giới hạn xuôi dòng, một ứng dụng có thể giới hạn tốc độ dữ liệu mà nó đọc được từ một ổ cắm. Tuy nhiên, lý do tại sao điều này hoạt động không phải là rõ ràng ngay lập tức. Khi ứng dụng bỏ qua việc đọc một số dữ liệu từ một ổ cắm, ổ cắm của nó sẽ nhận được bộ đệm. Điều này đến lượt nó sẽ khiến TCP nhận quảng cáo một cửa sổ thu nhỏ hơn (rwnd), tạo áp lực ngược lên kết nối TCP bên dưới do đó hạn chế luồng dữ liệu của nó. Cuối cùng, hiệu ứng này của trò lừa bịp này đã đạt được giới hạn tỷ lệ từ đầu đến cuối. Tùy thuộc vào bộ đệm trong tất cả các lớp của ngăn xếp mạng, hiệu ứng này có thể mất một thời gian để lan truyền.

Nếu bạn thỉnh thoảng cần giới hạn tỷ lệ một chương trình trên một hệ thống UNIX, một giải pháp đơn giản là nhỏ giọt . Định hình lưu lượng truy cập thực, như bạn sẽ thực hiện trên một cổng, có thể được thực hiện với tc. Điều này được ghi lại trong Chương 9. Các nguyên tắc xếp hàng để quản lý băng thông của Linux và định tuyến kiểm soát lưu lượng nâng cao.

Trong trường hợp modem 56k so với dòng DSl 4 Mb / giây, (thường) không có sự định hình tạo ra sự khác biệt về tốc độ, đó chỉ là sự khác biệt về tốc độ của liên kết.

Lý do tại sao khó định hình lưu lượng truy cập đến là vì không có bộ đệm trong phương tiện truyền dẫn. Bạn chấp nhận các bit đến hoặc chúng bị mất. Đối với lưu lượng truy cập sắp rời khỏi một giao diện, bạn có thể đệm và sắp xếp lại các gói theo ý muốn (hoặc, ít nhất là đến bộ nhớ đệm có sẵn trong thiết bị).

Đối với các giao thức có lớp trên cùng của TCP (Tôi không biết đó có phải là trường hợp của torrent không), đó sẽ là một vấn đề đơn giản về yêu cầu tạo nhịp cho dữ liệu tiếp theo. Nếu không, ứng dụng sẽ cần giao tiếp với HĐH, để trì hoãn ACKing các gói. Hầu hết các giao thức dựa trên UDP sẽ, do sự cần thiết phải có logic ACK / gửi lại trong giao thức dành riêng cho ứng dụng, do đó, tại thời điểm đó, nó giáp với tầm thường để tăng tốc chúng.

Một lộ trình có thể là định hình lưu lượng truy cập từ Internet ở phía mạng LAN của bộ định tuyến DSL của bạn, vì tại thời điểm đó, bạn sẽ định hình trên một cổng ra.

Tôi không thể trả lời lý do tại sao bạn không tìm thấy bất kỳ giải pháp nào cho phép định hình dữ liệu đến (và không biết bất kỳ giải pháp nào ngoài đầu tôi), nhưng về cách người gửi biết người nhận có thể nhận dữ liệu nhanh như thế nào:

Thiết kế cơ bản của TCP / IP là với mỗi gói mà nguồn gửi đến đích, nó phải đợi đích trả lời lại (với một ACKgói) nói rằng nó đã nhận được gói.

Vì vậy, nếu Bạn có người gửi 4Mbps và máy thu 56Kbps, thì người gửi phải ngồi và chờ giữa việc gửi các gói để người nhận trả lời từng gói (Có một số chi tiết kỹ thuật để giảm chi phí này, nhưng tiền đề vẫn giữ một bản tóm tắt cấp độ).

Vậy chuyện gì xảy ra nếu người gửi đã gửi 56Kbps dữ liệu và sau đó cố gắng gửi thêm một chút?

Các gói bị mất. (Chà, có khả năng xếp hàng trong bộ đệm của công tắc, nhưng khi nó đầy, gói bị mất). Vì gói bị mất, người nhận không bao giờ nhận được nó, và do đó không bao giờ gửi ACKgói. Vì người gửi không bao giờ nhận được ACKgói này (vì nó không bao giờ được gửi, nhưng cũng có thể bị mất hoặc có thể bị gián đoạn mạng), nên người gửi được yêu cầu gửi lại gói bổ sung. Nó ngồi và cố gắng gửi lại gói cho đến khi nó được thông qua và ACKtrả lời trở lại với nó.

Vì vậy, để tóm tắt lại, một khi người gửi đã tối đa hóa băng thông của người nhận, nó phải dừng và gửi lại gói tiếp theo nhiều lần cho đến khi có đủ băng thông có sẵn để nó đi qua. Điều này có hiệu quả làm giảm tốc độ gửi đến mức tối đa mà khách hàng có thể nhận được tại. (Và có các phương pháp tối ưu hóa để giảm số lần phải gửi lại gói trong trường hợp này, trong đó về cơ bản người gửi chậm lại mỗi lần gửi lại gói, nhưng vượt quá phạm vi mô tả đơn giản này.

Bạn có thể làm điều đó với giao diện ifb.

Với giao diện ifb, bạn có thể định tuyến luồng vào của eth0 (hoặc bất cứ thứ gì) đến đầu ra trong ifb0 (ví dụ) và áp dụng các quy tắc giới hạn ở đó.

Kiểm tra url này của Linux Foundation: http://www.linuxfoundation.org/collabISE/workgroups/networking/ifb

Và tập lệnh này giới hạn băng thông không liên quan và vượt trội: https://github.com/rfrail3/misc/blob/master/tc/traffic-control.sh

Kiểm tra wonderershaper: http://lartc.org/wondershaper/

Về lưu lượng đến:

This is slightly trickier as we can't really influence how fast the internet
ships us data. We can however drop packets that are coming in too fast,
which causes TCP/IP to slow down to just the rate we want. Because we don't
want to drop traffic unnecessarily, we configure a 'burst' size we allow at
higher speed.

Now, once we have done this, we have eliminated the downstream queue totally
(except for short bursts), and gain the ability to manage the upstream queue
with all the power Linux offers.

sử dụng UFW (Tường lửa không biến chứng) http://ubuntuforums.org/showthread.php?t=1260812

Chuỗi này hiển thị một ví dụ đơn giản rằng mặc định cho IP có 6 lần truy cập trong vòng 30 giây bị từ chối:

sudo ufw limit ssh/tcp

Ngoài ra, một lệnh 'nâng cao' hơn với các giá trị được chỉ định cho thời gian và số lần nhấn

sudo iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH

sudo iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 8 --rttl --name SSH -j DROP