Trong thuật ngữ TCP / IP, bộ giới hạn tốc độ tải xuống trong văn phòng hoạt động như thế nào?


8

Giả sử một văn phòng của mọi người, họ muốn giới hạn tải xuống HTTP ở mức tối đa 40% băng thông tốc độ kết nối internet của họ để nó không chặn lưu lượng truy cập khác.

Chúng tôi nói "nó không được hỗ trợ trong tường lửa của bạn" và họ nói rằng dòng không thể tránh khỏi "chúng tôi đã từng có thể làm điều đó với Netgear / DLink / DrayTek của chúng tôi".

Suy nghĩ về nó, một tải xuống là như thế này:

HTTP GET request
Server sends file data as TCP packets
Client acknowledges receipt of TCP packets
Repeat until download finished.

Tốc độ được xác định bởi tốc độ máy chủ gửi dữ liệu cho bạn và tốc độ bạn nhận dữ liệu.

Vì vậy, để hạn chế tốc độ tải xuống, bạn có hai lựa chọn:

1) Hướng dẫn máy chủ gửi dữ liệu cho bạn chậm hơn - và tôi không nghĩ có bất kỳ tính năng giao thức nào để yêu cầu điều đó trong TCP hoặc HTTP.

2) Xác nhận các gói chậm hơn bằng cách giới hạn tốc độ tải lên của bạn và cũng làm hỏng tốc độ tải lên của bạn.

Làm thế nào để các thiết bị làm điều này hạn chế? Có một cách tiêu chuẩn?


Tỷ lệ giới hạn tốc độ các gói nhận được cho phép ra khỏi tường lửa vào mạng LAN nhanh chóng gây ra các xác nhận chậm hơn và việc xử lý tắc nghẽn trong ngăn xếp TCP của máy chủ gửi lại tốc độ gửi trở lại. Cảm ơn. Tôi có thể làm cho nó hoạt động như thế với tessting. Tôi đã đưa ra một số câu trả lời, nhưng tôi chỉ có thể đánh dấu một câu trả lời.
TessellatingHeckler

Câu trả lời:


11

TCP tự thực hiện kiểm soát tắc nghẽn.

Những bộ giới hạn tốc độ này sẽ chỉ đơn giản là ném các gói đi quá giới hạn. TCP xử lý việc này, đảm bảo rằng tất cả các gói đến và tất cả đều đến theo thứ tự; máy khách không ACK cho các gói bị bỏ và chúng bị máy chủ phẫn nộ.

Ngăn xếp TCP của máy chủ sẽ gửi lại các gói và nó cũng sẽ quay lại một chút về tốc độ gửi của nó bởi vì nó cho thấy có sự tắc nghẽn giữa nó và máy khách. Nó sẽ tăng tốc trở lại cho đến khi bộ giới hạn tốc độ giảm các gói một lần nữa, v.v.


Vì vậy, tôi nên áp dụng tỷ lệ chính sách QoS giới hạn tốc độ tường lửa tăng lưu lượng HTTP trên giao diện / LAN /? Và sau đó chỉ cần để TCP xử lý nó. "Nó cũng sẽ quay lại một chút về tốc độ gửi của nó" là một phần khác tôi đã bỏ lỡ.
TessellatingHeckler

2
Yup, đúng vậy. Máy chủ chỉ có thể tiếp tục ném dữ liệu vào liên kết của bạn, bão hòa nó trước khi QoS được áp dụng - nhưng, miễn là nó là một công dân TCP tốt, tốc độ gửi của nó sẽ thiết lập trạng thái cân bằng gần đúng với tốc độ mà dữ liệu của nó thực sự vượt qua tỷ lệ giới hạn.
Shane Madden

Đúng, TCP thực hiện kiểm soát tắc nghẽn của riêng nó, nhưng nó không nhất thiết phải hiệu quả. Bất cứ ai có kinh nghiệm với torrent đều biết điều này. Về cơ bản, hầu hết các cài đặt kiểm soát tắc nghẽn TCP đều bị hỏng khi có hàng trăm kết nối hoạt động trên mạng.
dùng606723

1
@ user606723 Nếu torrent là một vấn đề, bạn nên sử dụng một máy ép gói ở đầu ra để loại bỏ lưu lượng đó. Điều này sẽ cắt torrenter khỏi trình theo dõi và giữ cho những người khác tải xuống cùng một torrent không làm ngập đường vào của bạn với các kết nối. Vấn đề được giải quyết.
MDMarra

1
@ user606723 Tại sao có, kiểm soát tắc nghẽn sẽ gặp khó khăn khi hàng ngàn kết nối được khởi tạo mọi lúc với TCP khởi động nhanh, vì các kết nối mới không biết gì về trạng thái của kết nối mà chúng đang xây dựng. Hàng trăm kết nối hoạt động, mặc dù? Có lẽ điều đó sẽ làm mất liên kết nhà chậm ..
Shane Madden

5

Mô tả tốt nhất mà tôi từng nghe có ý nghĩa về phương pháp điều chỉnh vốn có của TCP là tắt một podcast Security Now gần đây . Trích dẫn Steve Gibson:

Vì vậy, theo thỏa thuận phổ quát, TCP là giao thức rất thông minh này, nó thực hiện một thứ gọi là "khởi đầu chậm". Nó thường được cho phép gửi một số lượng gói mà không cần xác nhận. Vì vậy, ý tưởng là, hãy để mọi thứ di chuyển ở đây. Và thông thường con số đó là hai. Và khi TCP khởi động, nó có thể gửi hai gói đi, từng gói một. Nếu không có cái đầu tiên được thừa nhận, nó sẽ gửi cái thứ hai. Nhưng rồi nó chờ. Và sau đó, quy tắc cho điều chỉnh là chúng tôi cho phép số lượng gói chưa được xác nhận tăng thêm một cho mỗi xác nhận chúng tôi nhận được.

Vậy hãy nghĩ về điều đó. Chúng tôi cho phép số lượng gói tin chưa được xác nhận tăng thêm một cho mỗi xác nhận chúng tôi nhận được. Vì vậy, trước tiên chúng tôi gửi đi hai gói như đã bắt đầu theo thỏa thuận của chúng tôi. Họ được thừa nhận. Vì vậy, chúng tôi có sự thừa nhận đầu tiên của chúng tôi. Chúng tôi đã cho phép mình gửi hai. Bây giờ, với việc nhận được xác nhận đầu tiên này, chúng tôi tăng nó lên một đến ba. Vì vậy, bây giờ chúng tôi có thể gửi thêm ba gói nữa mà không cần xác nhận thêm. Khi một xác nhận trở lại cho bất cứ điều gì chúng tôi đã gửi trước đó, chúng tôi sẽ tăng lên bốn. Điều này được gọi là "cửa sổ tắc nghẽn." Đó không phải là một cửa sổ từng được gửi trên đường dây, nghĩa là nó không giống như cửa sổ nhận, đó là 16 bit của tiêu đề TCP cho chúng ta biết chúng ta có thể gửi bao nhiêu dữ liệu. Cái này là - nó là một cửa sổ. Nó '

Nếu chúng tôi tiếp tục tăng số lượng gói chưa được xác nhận, chúng tôi được phép gửi cho mỗi lần chúng tôi nhận được xác nhận, đến một lúc nào đó chúng tôi sẽ đạt đến giới hạn. Và cái hay của hệ thống này là nó sẽ, khi chúng ta bắt đầu gửi các gói nhanh hơn liên kết yếu nhất, theo nghĩa đen, giữa các bộ định tuyến, tại một số điểm chúng ta thấy điểm liên kết yếu nhất bị phá vỡ. Nó làm giảm các gói chúng tôi đang cố gửi vì chúng tôi đang cố gửi chúng quá nhanh. Vì vậy, các xác nhận từ đầu kia dừng lại vì dữ liệu không còn được thông qua.

Và những gì TCP làm là, nếu nó không nhận được - và điều này thay đổi trong các chiến lược. Theo thời gian, chiến lược, chiến lược tránh tắc nghẽn thực tế đã thay đổi rất nhiều. Có những cái tên như Tahoe và Reno, và một loạt những cái khác mà bạn sẽ thấy nếu bạn thực hiện một số Google và Wikipedia, trong đó cụ thể chính xác hành vi đó là gì. Nhưng ý tưởng là, khi người gửi nhận ra rằng dữ liệu của họ không còn được thông qua vì nó thiếu các xác nhận, nó sẽ cắt giảm tốc độ gửi nhanh chóng. Thông thường, nó chia nó một nửa. Vì vậy, nó quy mô đáng kể nó trở lại, và sau đó quay trở lại để tăng nó.

Vì vậy, về cơ bản điều này có nghĩa là việc mất các gói là chức năng báo hiệu cho "Chúng tôi không thể gửi dữ liệu nhanh hơn" và người gửi TCP ở mỗi đầu của một kết nối, trên Internet, luôn luôn là - chúng ' Đang cố gắng đi nhanh hơn tốc độ tối đa có sẵn giữa hai điểm cuối, nghĩa là liên kết yếu nhất, bất cứ nơi nào và họ luôn đẩy nó đến giới hạn. Vì vậy, có một điểm ở đâu đó yếu hơn khả năng gửi gói của họ, họ sẽ tìm thấy điểm đó vì họ sẽ bơm các gói ra. Miễn là có dữ liệu được gửi và họ có kết nối băng thông cao, người gửi sẽ tăng tốc độ gửi, nghĩa là, số lượng gói tin còn tồn tại, các gói được phép ở ngoài đó dưới dạng xác nhận quay lại tích cực tiếp tục di chuyển số đó lên trên cho đến khi nó đẩy nó đi quá xa. Sau đó, nó lùi lại rất nhiều, và một lần nữa di chuyển về phía trước.

Vì vậy, đây là những gì thực sự xảy ra giữa các kết nối TCP, có lẽ, tôi có thể không biết bao nhiêu phần trăm, nhưng phần trăm lưu lượng truy cập lớn nhất trên Internet là trên các kết nối TCP. Tất cả các hệ điều hành của chúng tôi trong kernel, trong ngăn xếp được gọi là TCP, đều có các bộ đếm này. Và khi chúng tôi gửi một tệp, khi chúng tôi tải lên một tệp lớn hoặc chúng tôi đang nhận một trang web, máy chủ ở đầu kia đang làm điều tương tự. Đó là việc đẩy, trên cơ sở kết nối riêng lẻ, vì nhiều gói chưa được thừa nhận hết mức có thể, làm tăng tốc độ gói cho đến khi nó chạm đến điểm bắt đầu bị lỗi hoặc bị giật. Sau đó, nó lùi lại, để cho phép mọi thứ phục hồi, và sau đó bắt đầu hoạt động trở lại.

Và do đó, cuối cùng trở thành một loại hệ thống tự điều tiết, với những hạn chế, ý tôi là, nó thực sự có vẻ hơi kỳ cục và thô thiển. "


3

Vì vậy, để hạn chế tốc độ tải xuống, bạn có hai lựa chọn:

1) Hướng dẫn máy chủ gửi dữ liệu cho bạn chậm hơn - và tôi không nghĩ có bất kỳ tính năng giao thức nào để yêu cầu điều đó trong TCP hoặc HTTP.

2) Xác nhận các gói chậm hơn bằng cách giới hạn tốc độ tải lên của bạn và cũng làm hỏng tốc độ tải lên của bạn.

3) Thiết bị định tuyến / tường lửa của bạn đặt dữ liệu đến vào nhóm QoS và chỉ làm trống thùng đó theo tốc độ bạn yêu cầu. Dữ liệu đến sẽ thích ứng với tốc độ đó vì các máy tính bên trong sẽ chỉ nhìn thấy xác nhận đã nhận ở tốc độ đó. Ngoài ra, gói bị rơi thỉnh thoảng (cố ý) hoạt động thực sự tốt để làm chậm kết nối.

Khi cố gắng tìm một thiết bị xử lý việc này, hãy tìm QoS (Chất lượng dịch vụ) trong cấu hình / tài liệu. Các hộp Linux (hoặc BSD) cũng tiện dụng cho việc này.


Điều đó gần như có ý nghĩa - vì vậy kỹ thuật là để hạn chế tốc độ xác nhận và làm như vậy bằng cách giả vờ với thiết bị LAN mà máy chủ đang gửi chậm hơn thực tế? Vì vậy, sẽ có một vụ nổ làm đầy kết nối lúc đầu, sau đó không phải là sau đó?
TessellatingHeckler

1
@TessellatingHeckler Vâng, đúng vậy. Ngoài ra, "vụ nổ" không nên là một vụ nổ rất lớn của en.wikipedia.org/wiki/Slow-start .
Jeff Ferland

2

Bạn sử dụng tường lửa hoặc thiết bị hỗ trợ giới hạn QoS (chất lượng dịch vụ).

Bạn có thể xây dựng một hệ thống Linux để hoạt động như một cổng văn phòng và để nó sử dụng định hình lưu lượng truy cập để đạt được điều này. Chỉ cần cài đặt nhiều NIC và sau đó mọi máy chỉ đến là một cổng.

Là một phần thưởng, bạn có thể định cấu hình máy chủ proxy trên đó để giúp giảm lưu lượng. Một cái gì đó giống như Mực. Có thể có các bản phân phối thiết bị định tuyến chìa khóa trao tay cũng có thể làm điều này.


QoS giúp như thế nào? Vào thời điểm thiết bị của bạn có thể áp dụng QoS cho tải xuống, lưu lượng đến đã đến qua kết nối internet và có khả năng bị chặn trong khi thực hiện. QoS có thể áp dụng cho lưu lượng truy cập đi, nhưng nó không thể làm bất cứ điều gì về lưu lượng truy cập đến bởi vì tại thời điểm nó nhìn thấy lưu lượng truy cập, đã quá muộn.
TessellatingHeckler

3
Nó có thể định hình lưu lượng nơi bạn có thể kiểm soát nó. Không có cách nào bạn có thể yêu cầu một máy chủ từ xa giới hạn tốc độ bạn lấy dữ liệu, nhưng bạn có thể hạ thấp nó tại điểm xâm nhập của bạn. Mặt khác, bạn phải nói chuyện với nhà cung cấp về việc định hình lưu lượng truy cập trong mạng của họ với nguồn cấp dữ liệu của bạn.
Bart Silverstrim

Ngoài ra, máy chủ proxy cũng có thể giúp giảm bớt một số tắc nghẽn. Nhưng nếu không, bạn sẽ phải định hình nó tại điểm vào.
Bart Silverstrim

Câu hỏi ban đầu của tôi là: có vẻ như bạn không thể định hình được tại điểm xâm nhập, bởi vì bất kỳ điều khiển nào bạn có thể áp dụng đều xảy ra sau khi lưu lượng truy cập đi qua nút cổ chai, làm thế nào để bất kỳ số lượng công nghệ nào xử lý vấn đề đó? "Áp dụng QoS, ví dụ như với Linux" và "sử dụng định hình lưu lượng truy cập" thực tế có thể phải làm gì, nhưng tôi đang tìm kiếm một lời giải thích về cách điều đó có thể giúp ích. (và bây giờ có một số trong trả lời khác).
TessellatingHeckler

@TessellatingHeckler: Phương pháp mà tôi cũng muốn cho phép sử dụng ECN mà thực sự làm cho các máy chủ gửi chậm lại mà không cần bỏ các gói tin. Phương pháp này là áp dụng bộ giới hạn tốc độ, chẳng hạn như RED cho các gói rời khỏi giao diện LAN, thay vì cố gắng sử dụng bộ lọc xâm nhập trên giao diện WAN.
Zan Lynx

2

Giao thức HTTP không cung cấp các phương tiện để giới hạn băng thông được sử dụng và thậm chí nếu có, đó sẽ là cài đặt phía máy khách, trong đó các quản trị viên mạng không thể có bất kỳ kiểm soát nào.

Giới hạn băng thông (còn được gọi là "Chất lượng dịch vụ") thường được quản lý trên các bộ định tuyến / tường lửa, xử lý tất cả lưu lượng đến và đi đến / từ một mạng; những chính sách hỗ trợ này thường cho phép bạn định cấu hình các chính sách như "cho phép bất kỳ máy khách nào sử dụng tối đa 10% băng thông khả dụng" hoặc "ưu tiên SMTP qua FTP để email có thể lưu chuyển ngay cả khi ai đó đang tải xuống nặng ".

Làm thế nào chính xác điều này được thực hiện tùy thuộc vào bộ định tuyến / tường lửa được sử dụng, nhưng cách cơ bản nhất là chỉ cần vứt bỏ các gói vượt quá giới hạn được cấu hình; TCP sẽ đảm bảo chúng được truyền lại và cuối cùng sẽ có thể vượt qua nút cổ chai.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.