Чому Dropbox може бути дуже швидким порівняно з FTP?

Мені хотілося б знати, чому технічно Dropbox набагато швидший, ніж FTP? Яку технологію вона використовує?

Я не говорю про різні файли, я кажу про передачу нових файлів в обох випадках, Dropbox набагато швидше.

Я маю на увазі це, дуже набагато швидше, можливо, в 10 разів швидше, ніж FTP для завантажених файлів. Пізніше буду експериментувати для великих файлів.

Для цього може бути ціла низка причин.
Протокол FTP далеко не ефективний.

1. Для передачі FTP потрібно щонайменше два з'єднання (одне для керування та одне для даних), де DropBox може використовувати лише одне з'єднання HTTP. Також з'єднання даних для сеансу FTP може бути відкрито з сервера до вашого клієнта, і якщо ви NATED, це може вийти з ладу, тому ваш FTP-клієнт може намагатися з'єднатися таким чином, не вдавшись до спроби навпаки.

2. На FTP-з’єднанні існує велика кількість проблем. Щоб надіслати файл, клієнту необхідно надіслати як мінімум дві команди (одна для відкриття з'єднання для передачі даних та одна для запуску надсилання), і кожен раз, коли потрібно чекати, коли сервер відповість, додаючи додаткову затримку. Окрім цих двох зворотних посилань на файл, є декілька зворотних зворотів команди-відповіді для початкового з'єднання - один для надсилання імені користувача, один для пароля і хоча б один для встановлення параметрів передачі (щоб переконатися, що сервер є очікуючи, що двійкові, а не ASCII, дані). Клієнт також може видавати пару додаткових команд для повернення інформації про сервер про себе. Dropbox, ймовірно, використовує лише той HTTP-запит, або щонайбільше два (один для автентифікації, один для надсилання даних).

3. На додаток до цього, залежно від того, якого клієнта ви використовуєте для передачі FTP (який ви не вказуєте, було б корисно відредагувати своє запитання, щоб включити цю інформацію), можливо, буде перервано з'єднання після кожної операції надсилання та відновлення наступного час. Немажливо, що DropBox підтримує зв’язок, відкритий на деякий час для цілей тривалого опитування, щоб якнайшвидше реагувати на доступні нові дані, які цей клієнт повинен завантажувати, тому він у той час як йому потрібно буде створити новий HTTP-з'єднання, щоб надіслати файл, на який не потрібно буде повторно підтверджувати автентифікацію.

4. Навряд чи клієнт DropBox стискає дані перед тим, як надсилати їх (щоб покращити швидкість і зберегти пропускну здатність) там, де вашого FTP-клієнта не буде. Так що навіть для великих файлів (якщо вони не попередньо стиснуті або зашифровані) DropBox та утиліти, як це, можуть бути швидшими, ніж основна передача FTP за деяким запасом.

Для великих файлів перші три пункти вище будуть бліді до незначного порівняно з часом, необхідним для фактичної передачі даних, але точка 4 все ще може бути досить важливою. Для невеликих файлів весь додатковий час налаштування, доданий протоколом FTP, потенційно може бути в пару разів більшим за час, необхідний для фактичного надсилання даних.

Як уже згадували інші, Dropbox може пропускати частини файлів, які не були змінені . Але також Dropbox пропустить завантаження файлів, якщо у нього вже є копія на стороні сервера (ту, яку ви або хто-небудь ще завантажив).

Отже, якщо ви намагаєтеся завантажити файл, ідентичний файлу, який вже є Dropbox, завантаження пропускається (і інші пов'язані машини можуть почати завантажувати його з серверів Dropbox). Якщо ви завантажуєте файл, який майже ідентичний іншому, вже завантаженому файлу (незрозуміло, чи вже завантажений файл повинен бути "вашим" чи міг походити від будь-якого користувача), він просто надішле достатньо частин файл, щоб відтворити його на сервері в поєднанні з уже завантаженим файлом.

FTP не може зробити нічого з цього (це простий протокол для надсилання та отримання потоків даних без посилання на будь-які інші дані, доступні на віддаленому кінці). Такі інструменти, як rsync та Unison, можуть "пропустити фрагменти, які вже має інша сторона", але, як правило, обмежуються порівнянням фрагментів файлів у однаковій траєкторії синхронізованої ієрархії. Здається, що Dropbox розширив цю ідею до колекцій файлів (тому, якщо ви "завантажуєте" два майже однакових файли, імовірно, він може влаштувати лише один плюс, достатній для "diff", щоб відновити інший).

Я припускаю, що ви маєте на увазі швидше щодо передачі файлів. Коли ви зберігаєте файл у своїй папці Dropbox, Dropbox надсилає лише дельту (або відмінності) даних на віддалений сервер зберігання даних. FTP (швидше за все) відправляє файловий байт у байт (а не просто надсилання змін), що потенційно може зайняти набагато більше часу для передачі по мережі. Так само при синхронізації з віддаленого сервера місцеві клієнти завантажуватимуть лише зміни.

Функція синхронізації локальної мережі також може потенційно прискорити синхронізацію та зменшити необхідний мережевий трафік.

Dropbox може бути швидшим, коли ви надсилаєте більшу кількість файлів. FTP такий швидкий, як ви можете отримати, коли ми говоримо швидкість, але це займає занадто багато "розмов" між сервером і клієнтським комп'ютером для кожного файлу, тому FTP здається повільнішим. Якщо ви завантажуєте якусь програму з відкритим кодом з тисячами файлів, зручніше стискати всі файли, завантажувати її через FTP та розпаковувати на сервері.

Я думаю, вони використовують прості методи хешування, схожі на md5 / sha

Кожного разу, коли ви запускаєте файл у локальний "dropbox", dropbox-client обчислює хеш цього файлу і повинен надсилати додаткові дані, наприклад, розмір файлів, ім'я файлу на сервер dropbox.

Якщо сервер dropbox знайде подібні файли (вони повинні підтримувати індекс хешей та файлових даних на своєму сервері), він просто повідомить клієнта про те, що файл був успішно "завантажений". ;-)

Таким чином ви "завантажуєте" файл лише логічно. Оскільки немає реальної передачі вмісту файлів, це повинно бути швидше, ніж будь-що інше.

Я не впевнений, який алгоритм хешування використовує dropbox, але я на 100% впевнений, що їх принцип роботи схожий на той, який я окреслив вище.

Хоча Dropbox використовує інші сервіси, вони історично використовували Amazon AWS (Amazon Web Services). Це здається, що ваш трансфер від джерела до місця призначення має дуже велику трубу передачі. На мій досвід, Dropbox використовує призначення, яке може приймати велику кількість даних одночасно. Dropbox також розподіляє завантаження за різними IP-адресами. Веб-сайт, на якому ви FTPing, ймовірно, має набагато менший канал передачі і не має можливості розподіляти завантаження настільки ефективно.

Якщо ви запустите Монітор ресурсів (резонанс) та перейдете на вкладку Мережа, ви помітите різні процеси, використовуючи пропускну здатність мережі.

• У розділі Процеси з мережевою активністю виберіть стовпчик для Total (B/sec)
• У розділі Підключення TCP виберіть стовпчик для Total (B/sec)

Для мене, коли я завантажую файл у Dropbox, він використовує 4 з'єднання для надсилання 4 різних IP-адрес.