Пожалуйста, предложите мне САМЫЙ БЫСТРЫЙ способ передать 35 ГБ сжатых (с помощью 7zip) данных с моего ноутбука на удаленный сервер. Пожалуйста, опубликуйте также команду. Я использовал SCP, но он ужасно медленный, rsync лучше, но с его скоростью около 1 МБ/мин это может занять очень много времени. Есть ли лучший способ?
решение1
FTP и HTTP являются самыми быстрыми, FTP быстрее для небольшого количества больших файлов, а HTTP быстрее для большего количества маленьких файлов (что неудивительно, учитывая природу трафика HTTP).
Дополнительные контрольные показатели -https://www.disk91.com/2014/technology/networks/compare-performance-of-different-file-transfer-protocol-over-latency/
Примечание: Ваш интернет-провайдер может ограничивать скорость загрузки в зависимости от вашего провайдера. Если ваш провайдер устанавливает ограничение скорости или данных, это может не иметь значения.
Вы также можете использовать другие методы, см.http://moo.nac.uci.edu/~hjm/HOWTO_move_data.html
решение2
35GiB займут около 25 дней при 1MB/минуту (17kB/s). Поскольку это займет много времени, я бы сосредоточился на способе, который позволит вам легко возобновить. Это исключает scp, насколько мне известно, и я бы рассмотрел следующих кандидатов:
- http(с)
- rsync
- Sneakernet
Настройка веб-сервера для обслуживания одного файла довольно проста; стандартная установка Ubuntu может сделать это без какой-либо настройки, пока машина доступна из Интернета. Просто поместите файл /var/www/html/(или дайте на него ссылку).
Используйте wget -c http://example.com/file.tarдля возобновления загрузки, если она была прервана. Это работает довольно надежно. Поскольку это одноразовая вещь, не беспокойтесь о сертификатах ssl — шифруйте и подписывайте данные, если вы беспокоитесь о безопасности и целостности.
Rsync передается через SSH, поэтому он безопасен. Он поддерживает бесшовное продолжение. должен поддерживать возобновление и передачу файла без каких-либо проблем.rsync -P localfile [email protected]:remotefile
Но 25 дней — это долго. Вероятно, вы можете скопировать диск на USB-накопитель и отправить его по почте быстрее. USB-накопители на 64GiB можно купить примерно за 20 долларов США. Если вы отправите его DHL, он доберется почти куда угодно в течение 3-4 дней.
Короче говоря, при таком объеме данных и той скорости соединения, которую вы видите, самым быстрым вариантом, вероятно, будет просто записать данные на внешний диск и отправить по почте.
Или отправьтесь куда-нибудь с хорошим соединением — загрузка 35 ГиБ при скорости соединения 100 Мбит/с займет меньше часа.
Для шифрования и подписи файла можно использовать gpg. Настройте пару ключей, зашифруйте файл и подпишите его. На удаленном конце вы проверяете подпись и расшифровываете ее. Это обеспечивает безопасность и целостность при передаче по недоверенному каналу, такому как mail или http. Если вы используете rsync, ssh позаботится об этом за вас.
решение3
Как заявил Panther, незашифрованные варианты, такие как FTPили HTTPбудут самыми быстрыми. Однако, если вы предпочитаете не выкладывать что-то в открытый доступ в Интернете, я рекомендую вам использовать зашифрованный метод. Вы можете попробовать что-то вроде создания простой страницы входа в PHP (используя оператор if), установить и настроить nginxили apacheдля HTTPS и иметь ссылку для загрузки, доступ к которой есть только у вас. HTTPS должен быть быстрым, поскольку он использует сжатие, и вы можете использовать программу, например, axelдля установки этого файла с использованием нескольких подключений.
Самый простой ответ, если предположить, что узким местом является ваше интернет-соединение, а не процессор, будет использовать SFTPс -Cфлагом для включения сжатия, хотя, поскольку вы уже сжали его, объем, который можно сжать еще больше, довольно мал. Самое простое, что можно сделать, это снова сжать файлы более эффективным методом.