Tại sao đa luồng tải xuống nhanh hơn luồng đơn?


13

Có một tệp lớn trong máy chủ của tôi. Tôi thấy rằng tải xuống đa luồng có thể nhận được 20Mbs, nhưng một luồng có thể nhận được 10Mb / giây, có ai có thể giải thích điều này không?


Nhiều luồng phục vụ cùng một kết nối TCP hoặc nhiều luồng với mỗi kết nối TCP riêng biệt? Ngoài ra, bạn đang nói rằng máy chủ là đa luồng, hay máy khách là đa luồng, hoặc cả hai?
Spiff

Câu trả lời:


14

Thông thường, điều này là do ở đâu đó giữa bạn và máy chủ khác có tường lửa giới hạn mỗi luồng HTTP ở mức 10Mb / giây. Khi bạn sử dụng đa luồng, bạn nhận được 2x 10Mb (một cho mỗi luồng).


1
Tôi sử dụng FTP và không có giới hạn nào trên máy chủ của mình
tại sao

@why: có thể ISP của bạn đang giới hạn mỗi kết nối tới 10mbps? Bạn có thể nhận được nhiều hơn thế trong một thử nghiệm tốc độ?
André Paramés

4

Điều này là do ping của bạn giữa bạn và máy chủ và kích thước cửa sổ / kích thước cửa sổ tcpip được sử dụng bởi phần mềm tải xuống của bạn.

Về cơ bản, nếu bạn có 100ms ping đến máy chủ và yêu cầu các gói 100kb, bạn chỉ có thể nhận được 10 gói mỗi giây bằng 1 kết nối, ngay cả khi tốc độ internet của bạn là vô hạn.


Bạn không cần phải ACK mỗi gói, miễn là người nhận làm trống bộ đệm của nó ở mức hợp lý, người gửi sẽ có thể bơm chúng liên tục.
André Paramés

Đúng rồi. Nhưng ngay cả với bộ đệm 256kb, ping vẫn gây ra sự chậm chạp lớn
BarsMonster

3

TCP hoạt động tốt nhất khi bạn "giữ cho đường ống đầy" - khi ứng dụng gửi tiếp tục gửi bộ đệm đủ nhanh để giữ cho ngăn xếp TCP gửi liên tục được cung cấp dữ liệu để nó luôn có dữ liệu "trong chuyến bay" trên mạng và khi người nhận ứng dụng tiếp tục đọc từ ngăn xếp TCP của người nhận đủ nhanh để cửa sổ TCP của người nhận không bao giờ bị đầy (một lần nữa, do đó, ngăn xếp TCP gửi luôn có thể giữ dữ liệu "trong chuyến bay" trên mạng).

Tôi có thể tưởng tượng một ứng dụng người gửi một luồng được viết kém, chuyển một bộ đệm vào ngăn xếp TCP, chờ nghe rằng nó đã được Acked hoàn toàn, và sau đó chuyển qua một bộ đệm khác. Điều đó có nghĩa là một khi kết thúc bộ đệm đầu tiên "trong chuyến bay" trên mạng, ngăn xếp TCP gửi bị bỏ đói dữ liệu để gửi, có nghĩa là ống thoát nước và không được nạp lại cho đến khi Ack quay lại và ứng dụng gửi vượt qua nó một bộ đệm mới.

Tôi cũng có thể tưởng tượng một ứng dụng thu đơn luồng được viết kém mà không đọc được từ ngăn xếp TCP nhận đủ nhanh và do đó cho phép bộ đệm của ngăn xếp TCP lấp đầy, điều đó có nghĩa là cửa sổ TCP lấp đầy, khiến cho ngăn xếp TCP gửi đến dừng gửi cho đến khi cửa sổ mở ra một số. Tăng kích thước cửa sổ TCP của người nhận có thể giúp ích một chút, nhưng giải pháp thực sự ở đầu này là đọc dữ liệu nhanh hơn.


Vì vậy, nó có thể không có gì để làm với một luồng?
Ape-inago

@ Ape-inago Chắc chắn, một ứng dụng đơn luồng được viết tốt có thể giữ cho đường ống đầy, vâng.
Spiff

2

Chà, có lẽ vì bạn chỉ có thể truyền quá nhiều dữ liệu qua một kết nối. Tuy nhiên, trong một chương trình đa luồng, bạn có thể có hai kết nối nhận dữ liệu cùng một lúc và nhân đôi lượng thông tin bạn có thể nhận được. Có một số hạn chế về điều này, ví dụ như tốc độ của máy chủ mà bạn đang tải xuống từ ... Bỏ qua hai người đã viết trình tải xuống đa luồng, những điều đó không dễ viết.


1
Tại sao lại khó như vậy? Bạn chỉ cần phân bổ một phần riêng lẻ cho mỗi luồng và để nó viết vào phần thích hợp của tệp kết quả. Nguồn axel có vẻ khá đơn giản với tôi.
André Paramés
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.