Как эффективно передавать данные между двумя сетями
Я хотел бы передавать файлы между двумя местами через Интернет. Прямо сейчас у меня есть 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 ответ
Просто используйте rsync
, Он очень эффективен в использовании TCP, он передает только файлы, которые изменились, и вы можете использовать сжатие, если хотите.
Вы не найдете способа победить приложение, которое эффективно использует TCP. TCP был определен и усовершенствован за последние ~40 лет многими действительно умными людьми, поэтому его очень трудно победить.
Современные стеки TCP, которые поддерживают SACK, очень эффективны при обнаружении и сообщении потерянных пакетов друг другу, поэтому только потерянные пакеты передаются повторно. Помещение сервера в середину ничего не ускорит, просто добавит задержку.
Единственный способ по-настоящему выиграть у TCP при скорости передачи данных - это усилить перегрузку сети. TCP работает как можно быстрее, но на мгновение отступает, когда появляются признаки перегрузки. Если вы создали протокол на основе UDP, который не заботился о том, сколько он добавил к перегрузке любых каналов, которые он пересекает, то вы могли бы взорвать пакеты, которые вызывают много проблем с перегрузкой, но в среднем могли бы получить чуть более высокую пропускную способность, чем TCP.