Я хотел бы передавать файлы между двумя местами через Интернет. Прямо сейчас у меня есть VPN, и я могу просматривать, загружать и передавать файлы. Поэтому мой вопрос не совсем в том, как передать файлы; Вместо этого я хотел бы использовать наиболее эффективный подход, потому что эти два места постоянно обмениваются большим количеством данных.

Причина, по которой я хочу избавиться от VPN, заключается в том, что он медленный. Высокая скорость загрузки очень дорога / невозможна в жилых помещениях, поэтому я хотел бы использовать другой подход.

Я думал об использовании таких программ, как http://www.dropbox.com . Проблема с Dropbox заключается в том, что бесплатная версия имеет только 2 ГБ дискового пространства. Я думаю, что предложения, которые они предлагают, в порядке, и я мог бы быть готов заплатить, чтобы получить это увеличение скорости. Но меня беспокоит скорость передачи данных. Dropbox загрузит файл на свой сервер, а затем отправит его с сервера в другое место. Я хотел бы, чтобы это было еще быстрее.


Во всяком случае, я думал, почему бы не создать программу самостоятельно. Это алгоритм, о котором я думал. Дайте мне знать, если это звучит слишком сумасшедшим.

(Помните, моя цель - максимально быстро передавать файлы)

Вещи, которые я буду использовать в этом алгоритме:

  • Сервер в интернете называется S (Имеет быструю скорость загрузки и выгрузки. Я плачу, чтобы разместить веб-сайт и некоторые услуги там. Я хочу воспользоваться этим.)
  • Клиент А в местоположении 1
  • Клиент Б по адресу 2

Допустим, в месте 1 создано 20 больших файлов, которые необходимо перенести в место 2.

  • Клиент A сжимает файлы с максимально возможной степенью сжатия.
  • Клиент A начинает отправку данных через UDP клиенту B.
  • Поскольку я использую UDP, я включу порядковый номер в каждый пакет.
  • Пусть сервер S поможет ускорить процесс. Например, каждый раз, когда пакет теряется, мы можем использовать сервер S, чтобы сообщить клиенту A, что ему нужно повторно отправить пакет.

В любом случае, я думаю, что такой подход увеличит скорость передачи. Я не знаю, возможно ли начать отправку данных, пока они сжимаются. Или, если есть возможность начать распаковку данных, даже если мы не закончили получать весь файл. Возможно, будет быстрее начать отправку файлов без сжатия. Если бы я знал, что я всегда буду отправлять большие текстовые файлы, то я, очевидно, буду использовать сжатие. Мне нужно это как общий алгоритм.

Поэтому я думаю, что мой вопрос заключается в том, могу ли я повысить производительность, используя UDP вместо TCP и используя дополнительный сервер для отслеживания потерянных пакетов? А как мне сжать файлы перед отправкой? Сжатие файла объемом 1 ГБ с самой высокой степенью сжатия занимает около 1 часа! Я хотел бы воспользоваться этим временем, отправив его по мере сжатия.

1 ответ1

3

Просто используйте rsync. Он очень эффективен в использовании TCP, он передает только файлы, которые изменились, и вы можете использовать сжатие, если хотите.

Вы не найдете способа победить приложение, которое эффективно использует TCP. TCP был определен и усовершенствован за последние ~ 40 лет многими действительно умными людьми, поэтому его очень трудно победить.

Современные стеки TCP, которые поддерживают SACK , очень эффективны при обнаружении и сообщении потерянных пакетов друг другу, поэтому только потерянные пакеты передаются повторно. Помещение сервера в середину ничего не ускорит, просто добавит задержку.

Единственный способ по-настоящему победить TCP при скорости передачи данных - это усилить перегрузку сети. TCP работает настолько быстро, насколько это возможно, но на мгновение отступает, когда появляются признаки перегрузки. Если вы создали протокол на основе UDP, который не заботился о том, сколько он добавил к перегрузке любых каналов, которые он пересекает, то вы могли бы взорвать пакеты, которые вызывают много проблем с перегрузкой, но в среднем могли бы получить немного большую пропускную способность, чем TCP.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .