Передача файлов по сети — это перенос содержимого файла с одного узла на другой по согласованному протоколу, который задает порядок команд, формат данных и, в защищенных вариантах, шифрование канала. Главная развилка темы — какой протокол выбрать и как не отдать файл (и пароль) в открытом виде. Ниже разбираю рабочие протоколы (FTP, FTPS, SFTP, SCP, HTTP/HTTPS, WebDAV), облачные хранилища и P2P, свожу их в таблицу и показываю, как передать файл с проверкой целостности.
Содержание
Сразу развожу три похожих сокращения, которые чаще всего путают:
- FTP — старый протокол передачи файлов, канал не шифруется.
- FTPS — тот же FTP, но обернутый в TLS (шифрование добавлено сверху).
- SFTP — отдельный протокол внутри SSH, к FTP отношения не имеет, кроме похожего названия.
FTPS и SFTP — это не «две версии одного». Это разные технологии с разным устройством, и дальше я показываю, чем именно.
FTP и почему он небезопасен
FTP (File Transfer Protocol) — один из старейших прикладных протоколов, базовая спецификация RFC 959 действует с 1985 года. Работает поверх TCP и использует два соединения: управляющее (порт 21) для команд и отдельное — для самих данных.
Ключевая проблема: FTP передает все открытым текстом. Логин, пароль и содержимое файлов идут по сети без шифрования, их видно при перехвате трафика. Поэтому для чувствительных данных чистый FTP не используют — только для публичной раздачи, где скрывать нечего (зеркала дистрибутивов, анонимный доступ).
Второй нюанс — режимы соединения для канала данных. В активном режиме сервер сам открывает соединение к клиенту, и клиентский файрвол часто блокирует такой входящий запрос. В пассивном режиме соединение для данных инициирует клиент; этот режим совместим с NAT и файрволами, поэтому на практике почти всегда используют его.
FTPS: FTP поверх TLS
FTPS — это FTP, к которому добавили шифрование через TLS (раньше SSL, сейчас это устаревшее название той же линейки). Структура команд FTP сохраняется, но канал шифруется, и логин с паролем больше не идут открыто.
Есть два варианта включения TLS, их тоже путают. В явном (explicit, AUTH TLS) клиент подключается к обычному порту 21 и командой AUTH TLS просит переключиться на шифрование — это современный, рекомендуемый вариант. В неявном (implicit) шифрование включено с первого байта на отдельном порту 990; вариант устаревший, оставлен для совместимости.
Минус FTPS остается «родовым»: два соединения (команды и данные) плюс TLS плохо дружат с NAT и файрволами, настройка диапазона пассивных портов бывает болезненной.
SFTP: передача файлов внутри SSH
SFTP (SSH File Transfer Protocol) — это не FTP с шифрованием, а самостоятельный протокол, работающий как подсистема SSH. Одно зашифрованное соединение по порту 22 несет и аутентификацию, и команды, и данные. Второго канала, как в FTP/FTPS, нет — поэтому SFTP заметно дружелюбнее к файрволам, использует уже открытый для SSH порт 22, поддерживает аутентификацию по ключам и полный набор операций (докачка, переименование, права, листинг). Именно SFTP — вариант по умолчанию для новых систем, когда нужен защищенный доступ к файлам сервера.
SCP: простое защищенное копирование
SCP (Secure Copy) — утилита копирования файлов тоже поверх SSH (порт 22). Она проще SFTP: умеет по сути только «скопировать отсюда туда», без листинга каталога и докачки.
Актуализация на 2026: классический протокол scp считается устаревшим из-за проблем безопасности, и в свежих версиях OpenSSH утилита scp по умолчанию переносит файлы поверх протокола SFTP. Команду scp использовать можно, но под капотом это чаще уже SFTP; для скриптов предпочтительнее прямой sftp или rsync поверх SSH.
HTTP/HTTPS и WebDAV
HTTP/HTTPS — это не только веб-страницы. Через них передают и файлы: скачивание по прямой ссылке, выгрузка формой на сайт, загрузка в REST API. HTTPS шифрует канал через TLS, поэтому для веб-раздачи и загрузок это безопасный и повсеместный вариант, проходящий через любые файрволы (порт 443).
WebDAV — расширение HTTP (спецификация RFC 4918), которое добавляет операции с файлами и каталогами поверх веб-протокола: создание, копирование, перемещение, блокировки. По WebDAV работают сетевые диски и корпоративные хранилища; поверх HTTPS канал шифруется как обычный веб-трафик.
Облако, файлообменники и P2P
Для повседневного обмена между людьми протокол напрямую обычно не трогают — берут сервис поверх HTTPS. Облачные хранилища (синхронизируемые папки) удобны для совместной работы и версий: файл кладут в папку, получателю дают ссылку. Файлообменники — это разовая загрузка и ссылка на скачивание, часто с ограничением срока и размера. Минус для чувствительных данных: файл лежит на чужом сервере, и публичная ссылка «видно всем, у кого она есть» приравнивается к открытой публикации.
P2P (peer-to-peer) и протокол BitTorrent решают другую задачу — раздачу одного большого файла множеству получателей без единого сервера. Файл делится на части, и каждый скачавший раздает их дальше; это эффективно для легального распространения объемных данных (образы дистрибутивов, датасеты). Целостность частей проверяется хешами внутри торрент-файла, но конфиденциальности P2P не дает: состав раздачи и участники видны.
Сводная таблица протоколов
| Протокол | Порт(ы) | Шифрование канала | Транспорт | Где применять |
|---|---|---|---|---|
| FTP | 21 (команды), 20 (данные) | нет | поверх TCP | публичная раздача, где нечего скрывать |
| FTPS | 21 или 990 + порты данных | TLS | FTP + TLS | legacy-интеграции, где нужен именно FTP-протокол |
| SFTP | 22 | да (SSH) | подсистема SSH | защищенный доступ к файлам сервера (по умолчанию) |
| SCP | 22 | да (SSH) | поверх SSH | быстрое копирование файла на сервер |
| HTTP | 80 | нет | поверх TCP | публичное скачивание без чувствительных данных |
| HTTPS | 443 | TLS | поверх TCP | веб-скачивание и загрузка, API |
| WebDAV | 80/443 | TLS (по HTTPS) | расширение HTTP | сетевые диски, корпоративные хранилища |
Как выбрать протокол
Выбор сводится к трем вопросам. Данные чувствительные? Если да — только шифрованный канал (SFTP, FTPS, HTTPS/WebDAV), чистый FTP и HTTP исключаются. Что уже есть в инфраструктуре? Есть доступ по SSH — берите SFTP; нужна раздача через браузер — HTTPS; требуется совместимость со старой FTP-системой — FTPS. Какой сценарий? Один большой файл многим получателям — P2P; разовый обмен между людьми — облако или файлообменник; автоматизация переноса между серверами — SFTP или rsync поверх SSH.
Практический вывод: для большинства новых задач с сервером ответ — SFTP; для веба — HTTPS.
Безопасность передачи
Защита складывается из двух независимых вещей, которые нельзя подменять одна другой.
Шифрование канала защищает от перехвата в пути: логин, пароль и содержимое не видно тому, кто слушает сеть. Это дают SFTP, FTPS, HTTPS/WebDAV; чистый FTP и HTTP такой защиты не имеют, поэтому чувствительные файлы через них не передают.
Проверка целостности — отдельная задача: убедиться, что файл дошел без искажений и подмены. Шифрование канала само по себе этого не гарантирует (файл мог измениться на источнике или прийти битым). Для проверки сравнивают контрольную сумму (хеш) файла с эталоном. Ниже — минимальный полный пример на SFTP.
Скачиваю файл по SFTP и сразу считаю его хеш SHA-256:
# копирую файл с сервера в текущий каталог
sftp user@example.com:/data/report.tar.gz .
# считаю контрольную сумму скачанного файла
sha256sum report.tar.gzВ консоли увижу строку вида (хеш и имя файла):
9f2c1a...e4b7 report.tar.gz
Дальше сравниваю этот хеш с эталоном, который публикует источник рядом с файлом (например, в report.tar.gz.sha256). Проверка одной командой:
# проверяю файл против опубликованного эталона
sha256sum -c report.tar.gz.sha256Ожидаемый результат при совпадении:
report.tar.gz: OK
Если сумма не сошлась, вывод будет другим, и файлу доверять нельзя:
report.tar.gz: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match
В этом случае передачу повторяют: FAILED означает, что файл битый или подменен.
Скопировать файл на сервер и обратно можно и через SCP — синтаксис короче, канал так же шифруется по SSH:
# загружаю локальный файл на сервер в каталог /data
scp report.tar.gz user@example.com:/data/Частая ошибка новичка — перепутать направление и указать источник и приемник наоборот. Тогда файл не туда «уедет» или команда вернет ошибку доступа:
scp: /data/report.tar.gz: Permission denied
Исправление — проверить порядок аргументов (scp ОТКУДА КУДА) и права на целевой каталог; при необходимости писать в доступный путь.
Отдельно про доступ: для SFTP/SCP надежнее аутентификация по SSH-ключу, а не по паролю — ключ не перехватить подбором. Пароль по SSH тоже идет в шифрованном канале, но остается уязвимым к подбору при слабой парольной политике.
Выводы
- Передача файла — это не «магия», а работа конкретного протокола; выбор протокола решает и удобство, и безопасность.
- FTP, FTPS и SFTP — три разные вещи: FTP без шифрования, FTPS — это FTP плюс TLS, SFTP — отдельный протокол внутри SSH.
- Для чувствительных данных нужен шифрованный канал (SFTP, FTPS, HTTPS/WebDAV); чистый FTP годится только для публичной раздачи.
- Шифрование канала и проверка целостности — разные задачи: канал защищает от перехвата, контрольная сумма (SHA-256) — от искажения и подмены.
- Для нового доступа к файлам сервера по умолчанию берут SFTP, для веба — HTTPS.
Где применяется / связь с практикой
Выбор протокола передачи файлов, настройка SFTP-доступа, диапазонов пассивных портов FTPS и правил файрвола — повседневные задачи сетевого инженера и системного администратора. Здесь важно понимать не только команды, но и как трафик проходит через NAT и межсетевые экраны, где шифруется канал и как проверять целостность данных.
Освойте тему на практике
Системно эти темы (модель TCP/IP, протоколы прикладного уровня, безопасность передачи) разбирают на курсе Сетевой инженер. Basic. Посмотреть формат и уровень занятий можно на открытых уроках Otus — это бесплатные вебинары с разбором практических тем.
FAQ
Чем SFTP отличается от FTPS, если оба «защищенные»?
Это разные протоколы. FTPS — это привычный FTP, к которому добавили TLS-шифрование, он сохраняет два соединения (команды и данные) и капризен к файрволам. SFTP — подсистема SSH: одно соединение на порту 22, к протоколу FTP отношения не имеет.
Достаточно ли HTTPS-ссылки, чтобы передать файл безопасно?
HTTPS шифрует канал, то есть защищает от перехвата в пути. Но если ссылка публичная и доступна «всем, у кого она есть», файл фактически открыт. Для приватности ограничивают доступ (пароль, срок жизни, список получателей) отдельно от шифрования.
Зачем считать контрольную сумму, если канал уже зашифрован?
Шифрование канала не гарантирует, что файл не побился при записи или не был подменен на источнике. Хеш (например, SHA-256), сверенный с эталоном автора, подтверждает, что получен именно тот файл и целиком.
