Cách nhanh nhất để truyền tệp qua mạng (FTP, HTTP, RSync, v.v.)

Question

Tôi đang cố gắng tìm ra cách tốt nhất để chuyển lượng lớn dữ liệu qua mạng giữa hai hệ thống. Tôi hiện đang xem xét một trong hai FTP, HTTP, hoặc RSync, và tôi tự hỏi cái nào là nhanh nhất. Tôi đã nhìn trực tuyến với một số câu trả lời và tìm thấy những địa điểm sau:

• http://daniel.haxx.se/docs/ftp-vs-http.html
• http://www.isi.edu/lsam/publications/http-perf/

Vấn đề là đây là cũ, và nói thêm về sự khác biệt giữa lý thuyết như thế nào các giao thức giao tiếp. Tôi quan tâm nhiều hơn đến điểm chuẩn thực tế, có thể nói rằng đối với một thiết lập cụ thể, khi chuyển các tệp có kích thước khác nhau, một giao thức nhanh hơn x% so với các giao thức khác.

Có ai kiểm tra những điều này và đăng kết quả ở đâu đó không?

Answer 1

Được rồi, vì vậy tôi thiết lập các thử nghiệm sau đây:

• Phần cứng: 2 máy tính để bàn Intel Core Duo CPU @ 2.33GHz, với 4G RAM.
• Hệ điều hành: Ubuntu 11.10 trên cả hai máy
• Mạng: 100Mb chuyển đổi chuyên dụng, cả hai máy đều được kết nối với máy.
• Phần mềm:
  • Máy chủ HTTP Python (inspired by this).
  • Máy chủ FTP Python (inspired by this).
  • Ứng dụng khách HTTP Python (inspired by this).
  • Ứng dụng khách FTP Python (inspired by this).

Tôi đã tải lên các nhóm sau các tập tin cho mỗi máy chủ:

1. 1 100M tập tin.
2. 10 tệp 10M.
3. 100 tệp 1M.
4. 1.000 tệp 100K.
5. 10.000 tệp 10K.

tôi có kết quả như sau trung bình trên nhiều chạy (số tính bằng giây):

|-----------+---------+----------| 
| File Size | FTP (s) | HTTP (s) | 
|-----------+---------+----------| 
|  100M |  8 |  9 | 
|  10M |  8 |  9 | 
|  1M |  8 |  9 | 
|  100K |  14 |  12 | 
|  10K |  46 |  41 | 
|-----------+---------+----------| 

Vì vậy, có vẻ như FTP là hơi nhanh hơn trong các tập tin lớn, và HTTP là một chút nhanh hơn trong nhiều nhỏ các tập tin. Tất cả trong tất cả, tôi nghĩ rằng họ có thể so sánh, và việc thực hiện máy chủ là quan trọng hơn nhiều sau đó giao thức.

Answer 2

rsync tùy chọn nén dữ liệu của nó. Điều đó thường làm cho việc chuyển đi nhanh hơn nhiều. Xem rsync -z.

Bạn không đề cập đến scp, nhưng scp -C cũng nén.

Lưu ý rằng quá trình nén có thể khiến quá trình chuyển đi nhanh hơn hoặc chậm hơn, tùy thuộc vào tốc độ của CPU và liên kết mạng của bạn. (Các liên kết chậm hơn và CPU nhanh hơn làm cho nén trở thành một ý tưởng hay; các liên kết nhanh hơn và CPU chậm hơn làm cho việc nén trở thành một ý tưởng tồi.) Như với bất kỳ tối ưu hóa nào, hãy đo lường kết quả trong môi trường của riêng bạn.

Answer 3

Nếu các máy ở mỗi đầu có sức mạnh hợp lý (nghĩa là không phải netbook, hộp NAS, máy nướng bánh mì, vv), thì tôi mong đợi tất cả các giao thức hoạt động trên TCP sẽ có cùng tốc độ truyền dữ liệu hàng loạt. Công việc của giao thức ứng dụng thực sự chỉ là để lấp đầy một bộ đệm cho TCP để truyền, miễn là chúng có thể giữ nó đầy đủ, TCP sẽ thiết lập tốc độ.

Các giao thức thực hiện nén hoặc mã hóa có thể tắc nghẽn tại CPU trên các máy ít mạnh hơn. Netbook của tôi thực hiện FTP nhanh hơn nhiều so với SCP.

rsync thực hiện những điều thông minh để truyền các thay đổi gia tăng nhanh chóng, nhưng đối với chuyển số lượng lớn, nó không có lợi thế hơn các giao thức dumber.

Answer 4

Tôi sợ nếu bạn muốn biết câu trả lời cho nhu cầu và thiết lập của mình, bạn phải cụ thể hơn hoặc thực hiện các bài kiểm tra hiệu suất (và độ tin cậy) của riêng bạn. Nó giúp bạn hiểu ít nhất về các giao thức được đề cập và thông tin liên lạc của họ, vì vậy tôi sẽ xem xét các bài viết bạn đã trích dẫn một tài nguyên hữu ích. Nó cũng giúp biết những hạn chế nào mà các nhà phát minh ban đầu của các giao thức này phải đối mặt - là mục tiêu của họ để giữ cho tác động mạng thấp, họ có bị mất trí nhớ hay họ phải tính chu kỳ CPU của họ? Dưới đây là một vài điều cần xem xét hoặc trả lời nếu bạn muốn nhận được một câu trả lời phù hợp với tình hình của bạn:

• OS/File System liên quan:
  • được bạn sao chép giữa các OS/FS kết hợp cùng hoặc làm bạn phải phải lo lắng về sự không tương thích, chẳng hạn như loại tệp mà không khớp nhau ở đầu nhận?
  • I.e. bạn có gì đặc biệt để vận chuyển không? Siêu dữ liệu, nhánh ressource, thuộc tính mở rộng, quyền truy cập tệp có thể không được chuyển bởi giao thức/công cụ bạn chọn hoặc vô nghĩa ở đầu nhận.
  • Điều tương tự cũng xảy ra đối với các tệp thưa thớt, điều này có thể kết thúc với kích thước đầy đủ ở đầu kia của bản sao, làm hỏng tất cả các gói bạn có thể có về định cỡ.
• trở ngại vật lý liên quan: ảnh hưởng
  • Mạng
  • tải cpu: ngày nay, nén là nhiều "rẻ hơn", vì các CPU hiện đại đều ít thách thức bởi sự nén hơn những người trở lại trong thời gian khi hầu hết các giao thức chuyển giao Đã được thiết kế.
  • khả năng chịu lỗi - bạn có cần phải nhận nơi chuyển giao bị gián đoạn trái bạn hay bạn muốn bắt đầu lại lần nữa?
  • chuyển khoản gia tăng hoặc chuyển khoản đầy đủ? Việc chuyển tiền gia tăng có gây ra bất kỳ khoản tiết kiệm lớn nào cho bạn hay bạn có chuyển hoàn toàn bằng cách thiết kế nhiệm vụ của mình không? Trong trường hợp thứ hai, độ trễ và tác động bộ nhớ được thêm vào để xây dựng danh sách chuyển đổi trước khi bắt đầu chuyển giao sẽ là một sự cân bằng ít hấp dẫn hơn.
  • Giao thức sử dụng MTU có sẵn bằng giao thức mạng cơ bản của bạn tốt như thế nào?
  • Bạn có cần duy trì một luồng dữ liệu ổn định, ví dụ để giữ cho một ổ băng phát trực tuyến ở đầu nhận không?

Rất nhiều điều cần xem xét và tôi chắc chắn rằng danh sách này thậm chí không đầy đủ.

Answer 5

Một tiện ích khác cần xem xét là bbcp: http://www.slac.stanford.edu/~abh/bbcp/.

Hướng dẫn tốt, nhưng ngày tháng để sử dụng nó ở đây: http://pcbunn.cithep.caltech.edu/bbcp/using_bbcp.htm. Tôi đã thấy rằng bbcp là cực kỳ tốt trong việc chuyển các tập tin lớn (nhiều GB). Theo kinh nghiệm của tôi, nó nhanh hơn rsync trung bình.