English Deutsch Español Français Italiano Nederlands Polski Українська
Encoders & Utilities

Download Time

Оцінює час завантаження на будь-якій швидкості зʼєднання.

Download time estimator Pick file size and connection speed — we will compute the transfer time. SI units (1 KB = 1000 B).
Try: 1 GB @ 100 Mbps 50 GB @ 1 Gbps 4 GB @ 10 Mbps 700 MB @ 56 Kbps
2m 23s
1 MB @ 56 Kbps
Raw time
142.86 s
Adjusted time
142.86 s
Total bytes
1 000 000
Bits per second
56 000

Про цей інструмент

Download Time оцінює, скільки часу займе завантаження файла заданого розміру при заданій швидкості з'єднання. Введіть розмір файла в будь-яких одиницях (KB, MB, GB, TB — binary або decimal), оберіть швидкість у Mbps/MBps/Gbps (з пресетами для типових тарифів: 56k dial-up, 4G LTE, fibre 100 / 1000 Mbps), і інструмент повертає тривалість у human-friendly формі (1 година 23 хвилини 12 секунд) плюс кілька порівняльних рядків для інших типових швидкостей.

Математика проста — duration = size / speed — але юніт-конверсії плутають усіх. Інтернет-провайдери продають швидкість у бітах за секунду (Mbps); розміри файлів — у байтах (MB); а сам «MB» неоднозначний між 1 000 000 байт (decimal, ISP і диски) і 1 048 576 байт (binary, Windows і RAM). Інструмент маркує кожну одиницю точно, тож можна перевірити, в якому світі ви рахуєте.

Коли використовувати цей інструмент

  • Оцінка вікон бекапу або міграції. 500 GB cloud-to-cloud transfer на 1 Gbps — це ~70 хвилин фактичного transfer; планування дає maintenance window.
  • Порівняння інтернет-планів. «100 Mbps» vs «Gigabit» звучить драматично; на 10 GB game-завантаженні це 14 хвилин vs 1.5 хвилини. Конкретні числа допомагають вирішити, чи варто оновлення.
  • Sizing CI/CD bandwidth. Pull 2 GB Docker-образу на кожен build при офісному shared 50 Mbps швидко набирається.
  • Виставлення реалістичних user-очікувань. «Цей експорт займе ~5 хвилин» краще за спіннер без прогрес-бара.

Чому реальні завантаження повільніші за калькуляцію

Число, що ви рахуєте — абсолютний мінімум. Реальні завантаження стикаються з TCP slow-start (перша секунда — partial speed), per-connection-bandwidth caps (одне HTTPS-завантаження до одного сервера рідко насичує fibre-лінію), TLS handshake overhead, disk I/O bottlenecks і shared-pipe contention. Правило: плануйте на 70–85% теоретичного для одного великого файла, менше — якщо завантажуєте багато малих файлів.

Часті запитання

Чому Mbps — не те саме, що MB/s?
Mbps — megabits per second; MB/s — megabytes per second. 1 байт = 8 біт, тож 100 Mbps ≈ 12.5 MB/s. ISP рекламують у бітах, бо число виглядає у 8× більшим; OS показують у байтах, бо так вимірюються файли. Фактор 8 — найбільше джерело плутанини «чому моє завантаження повільніше за speed test?».

Яка різниця між MB і MiB?
MB = megabyte = 1 000 000 байт (decimal, SI). MiB = mebibyte = 1 048 576 байт (binary, IEC). Маркетинг дисків і ISP використовує MB; Windows file-size dialogs і RAM-spec — MiB (часто маркують «MB», додаючи плутанини). Для 1 TB hard drive від виробника ви отримуєте ~931 GiB usable — та сама кількість байт, інша конвенційна назва.

Чому моє реальне завантаження повільніше за калькулятор?
Кілька причин накладаються: TCP slow-start (протокол ramp-up-ить поступово, тож перші кілька секунд — partial speed); TLS handshake і DNS overhead (менші файли заледве отримують вигоду від високих швидкостей); single-connection caps (один HTTPS stream до одного сервера рідко насичує fibre); локальна Wi-Fi contention; і outbound bandwidth самого сервера. Плануйте на 70–85% теоретичного — рідко будете здивовані.

Чи враховує інструмент overhead?
Він рахує protocol-free теоретичний мінімум. Реальні transfer додають ~3–5% за TCP/IP-заголовки (40 байт на 1500-байтовий пакет) плюс кілька відсотків за TLS-framing. Ми свідомо не закладаємо це в headline-число, бо overhead варіюється за протоколом — HTTP/3 чистіший за HTTP/2 over TLS over TCP. Для песимістичного планування додавайте 5% до тривалості, що повідомляє інструмент.