HTTPS, DNS, SSH, FTP и API — это названия, которые часто встречаются рядом в документации, настройках сайта и разговорах о серверах. Из-за этого легко решить, что перед нами конкурирующие варианты одного и того же протокола. На самом деле они отвечают на разные вопросы: как открыть веб-страницу, как найти сервер по имени, как безопасно войти на удалённую машину, как передать файл или как одной программе обратиться к другой.
Главная мысль: HTTPS, DNS, SSH, FTP и API не являются прямыми аналогами. Часть из них — сетевые протоколы, а API — способ организовать взаимодействие между программами.
В этой статье разберём назначение каждой технологии, её место в сетевой архитектуре, способы защиты, типичные ошибки и реальные сценарии. В конце будет проще понять, почему браузер сначала обращается к DNS, затем устанавливает защищённое HTTPS-соединение, а администратор при этом может подключаться к тому же серверу по SSH и загружать файлы через SFTP.
- Иерархия знаний о HTTPS
- Что есть что: кратко о протоколах. Таблица
- HTTP
- HTTPS
- FTP
- SSH
- API
- DNS
- Сравнение HTTP, HTTPS, FTP, SSH, API и DNS. Таблица
- Для чего используется
- Какие данные передаются
- Есть ли шифрование
- Как связаны с TCP/IP
- Типичные сценарии применения
- Как технологии работают вместе в одном запросе
- Шаг 1. Имя преобразуется в адрес
- Шаг 2. Устанавливается транспортное соединение
- Шаг 3. TLS проверяет сервер и шифрует канал
- Шаг 4. HTTP или API обмениваются данными
- Интересные факты
- HTTPS не всегда работает поверх TCP
- API — не обязательно HTTP
- DNS нужен ещё до открытия HTTPS-соединения
- SSH и HTTPS оба защищают соединение, но решают разные задачи
- FTP, FTPS и SFTP — не одно и то же
- Практический выбор технологии
- Когда нужен HTTPS
- Когда нужен SSH
- Когда нужен API
- Когда нужен DNS
- Типичные ошибки и заблуждения
- Путаница в названиях и функциях
- Как не перепутать проблему протокола и проблему настройки
- Безопасность: что защищать в первую очередь. Чек-лист
- Итоги
Иерархия знаний о HTTPS
Эта статья находится в разделе, где HTTPS рассматривается не изолированно, а в связи с другими технологиями Интернета. Такое сравнение помогает увидеть полную цепочку: от ввода доменного имени до загрузки страницы, обмена данными с API и администрирования сервера. Полную структуру материалов об HTTPS можно открыть в иерархии знаний о HTTPS.
HTTPS ├── HTTPS: что это такое, как работает и зачем нужен протокол ├── Как работает HTTPS: принцип работы, устройство и порядок соединения ├── HTTPS, SSL и TLS: как работает шифрование и защита данных ├── Порт HTTPS — 443: какой порт использует протокол и зачем он нужен ├── HTTPS и TCP/IP: уровни, протоколы и взаимодействие ├── Как подключить HTTPS к сайту: установка, настройка и переход с HTTP ├── DNS over HTTPS (DoH): что это такое, как работает и как настроить ├── Проверка HTTPS: как протестировать протокол и исправить ошибки └── HTTPS, DNS, SSH, FTP и API: чем отличаются сетевые протоколы
Что есть что: кратко о протоколах. Таблица
Перед подробным сравнением полезно зафиксировать базовые определения. Иначе разговор быстро превращается в набор похожих сокращений, где HTTP путают с API, а SFTP — с FTP. Ниже показано, какую задачу решает каждая технология и в какой ситуации она появляется.
Один сетевой сценарий может включать сразу несколько технологий: DNS находит адрес, HTTPS передаёт веб-данные, API обменивается структурированной информацией, а SSH используется администратором для управления сервером.
| Технология | Что делает | Где применяется | Типичный порт или транспорт |
|---|---|---|---|
| HTTP | Передаёт запросы и ответы между клиентом и веб-сервером | Веб-страницы, ресурсы, простые веб-сервисы | TCP 80, а для HTTP/3 — QUIC поверх UDP |
| HTTPS | Передаёт HTTP через защищённое TLS-соединение | Сайты, интернет-магазины, личные кабинеты, веб-API | TCP 443 или QUIC/UDP 443 |
| FTP | Передаёт файлы и команды управления файлами | Обмен файлами, устаревшие серверные системы, внутренние сети | TCP 21 для управления, отдельный канал для данных |
| SSH | Создаёт защищённый удалённый сеанс и выполняет команды | Администрирование Linux-серверов, туннели, Git, копирование файлов | TCP 22 по умолчанию |
| API | Определяет правила, по которым программы обмениваются данными | Мобильные приложения, интеграции, микросервисы, автоматизация | Не имеет единственного порта; часто HTTP или HTTPS |
| DNS | Связывает доменные имена с IP-адресами и другими записями | Открытие сайтов, почта, проверка домена, обнаружение сервисов | UDP/TCP 53, DoT и DoH используют защищённые каналы |
HTTP
HTTP — протокол прикладного уровня, с помощью которого клиент и сервер обмениваются сообщениями. Клиентом может быть браузер, мобильное приложение, поисковый робот или другая программа. Сервер получает запрос и возвращает ответ: HTML-документ, изображение, таблицу стилей, JSON или сообщение об ошибке.
Классический HTTP сам по себе не шифрует содержимое. Если соединение не защищено другим механизмом, посторонний наблюдатель потенциально может увидеть адреса страниц, заголовки, отправленные данные и содержимое ответа. Поэтому для публичных сайтов обычно используется HTTPS.
GET /catalog/item-42 HTTP/1.1 Host: cio-navigator.ru Accept: text/html Ответ сервера: HTTP/1.1 200 OK Content-Type: text/html <html>...страница товара...</html>
HTTPS
HTTPS — это HTTP, работающий поверх TLS. TLS шифрует передаваемые данные, помогает обнаружить их изменение и позволяет браузеру проверить, что сертификат действительно относится к нужному домену.
HTTPS не означает, что сайт автоматически безопасен во всех смыслах. Он защищает канал между клиентом и сервером, но не исправляет уязвимости самого сайта, слабые пароли или вредоносный код на сервере. Однако без HTTPS нельзя надёжно защитить данные при передаче через Интернет.
Браузер: https://cio-navigator.ru/login
│
├── DNS находит IP-адрес
├── TLS проверяет сертификат
├── создаётся зашифрованный канал
└── HTTP передаёт логин и пароль внутри TLS
FTP
FTP, или File Transfer Protocol, предназначен для передачи файлов и операций с каталогами: загрузки, скачивания, переименования и удаления. В отличие от HTTP, он изначально создавался именно как инструмент обмена файлами, а не как механизм доставки веб-страниц.
Важная особенность FTP — использование отдельного соединения для команд и передачи данных. Кроме того, обычный FTP не шифрует логины, пароли и содержимое файлов. Для новых проектов чаще выбирают SFTP или FTPS, но это разные технологии, а не два названия одного протокола.
SSH
SSH, или Secure Shell, создаёт защищённый удалённый сеанс. Через него администратор может войти на сервер, выполнить команды, посмотреть журналы, перезапустить службу или настроить веб-сервер.
SSH также используется как основа для других операций. Например, команда scp копирует файлы через SSH, sftp передаёт файлы через подсистему SSH, а SSH-туннель перенаправляет сетевой трафик через защищённое соединение.
ssh admin@cio-navigator.ru Подключение: 1. Клиент находит сервер по имени. 2. Сервер предъявляет ключ хоста. 3. Пользователь проходит аутентификацию. 4. Открывается командная оболочка. $ systemctl status nginx
API
API — это интерфейс взаимодействия программ. Он описывает, какие операции доступны, какие параметры нужно передать и в каком формате придёт ответ. API может работать через HTTPS, но API и HTTPS нельзя считать синонимами.
Например, интернет-магазин может предоставить API для получения каталога, создания заказа и проверки статуса доставки. Транспортом будет HTTPS, форматом — JSON, а правилами обращения — конкретная документация API. Само API — это договор между программами, а не один обязательный сетевой протокол.
Запрос приложения:
POST https://api.cio-navigator.ru/orders
Content-Type: application/json
{
"product_id": 42,
"quantity": 2
}
Ответ:
{
"order_id": 7815,
"status": "created"
}
DNS
DNS, или Domain Name System, переводит удобные для человека имена вроде cio-navigator.ru в IP-адреса и хранит другие сведения о домене. Благодаря DNS пользователю не приходится запоминать числовой адрес каждого сайта.
DNS не загружает саму веб-страницу и не шифрует HTTP-трафик. Он отвечает на вопросы о доменах: какой IP связан с именем, где находятся почтовые серверы, какие серверы авторитетны за зону и какие дополнительные параметры опубликованы.
Запрос: cio-navigator.ru → A? Ответ: cio-navigator.ru → 203.0.113.10 После этого браузер обращается уже к серверу по IP, но в HTTPS-запросе сохраняет имя cio-navigator.ru.
Сравнение HTTP, HTTPS, FTP, SSH, API и DNS. Таблица
Теперь можно сопоставить технологии по ключевым критериям. Такое сравнение полезно не только для теории: оно помогает выбрать правильный инструмент, понять назначение порта и быстрее найти причину ошибки.
Сравнивать HTTPS и DNS напрямую — примерно как сравнивать почтовый адрес с защищённым автомобилем: оба участвуют в доставке, но выполняют совершенно разные функции.
| Критерий | HTTP | HTTPS | FTP | SSH | API | DNS |
|---|---|---|---|---|---|---|
| Назначение | Веб-обмен | Защищённый веб-обмен | Обмен файлами | Удалённое управление | Контракт между программами | Работа с именами |
| Что передаётся | Документы, ресурсы, данные | То же, но внутри TLS | Файлы и команды | Команды, вывод программ, файлы | Структурированные запросы и ответы | DNS-запросы и записи |
| Шифрование по умолчанию | Нет | Да, через TLS | Нет | Да | Зависит от транспорта | Обычный DNS — нет |
| Проверка сервера | Не предусмотрена | Сертификат TLS | Зависит от варианта | Ключ хоста | Зависит от реализации | Механизмы DNSSEC или доверие к резолверу |
| Типичный клиент | Браузер | Браузер или HTTP-клиент | FTP-клиент | Терминал или SSH-клиент | Приложение или сервис | Резолвер операционной системы |
| Основная угроза при ошибочной настройке | Перехват данных | Ошибки сертификата и слабая конфигурация TLS | Утечка логина и файлов | Компрометация учётной записи | Утечка ключей и несанкционированный доступ | Подмена или утечка DNS-ответов |
Для чего используется
Назначение технологии — самый надёжный первый ориентир. Если требуется показать страницу, нужен HTTP или HTTPS. Если нужно выполнить команду на сервере, выбирают SSH. Если программа должна получить список товаров, речь идёт об API, которое часто будет работать через HTTPS.
- HTTP/HTTPS — запросить ресурс у веб-сервера.
- FTP и его защищённые варианты — обмениваться файлами.
- SSH — безопасно управлять удалённой системой.
- DNS — найти адрес или другие сведения о домене.
- API — договориться о формате и правилах обмена между программами.
Какие данные передаются
Тип данных тоже различается. Браузер обычно получает HTML, CSS, JavaScript и изображения. FTP-клиент работает с файлами и каталогами. SSH передаёт команды и результаты их выполнения, хотя через него можно организовать и копирование файлов. API чаще возвращает JSON, XML, protobuf или другой машинно-ориентированный формат.
| Сценарий | Пример данных | Подходящая технология | Почему |
|---|---|---|---|
| Открытие статьи | HTML, CSS, изображения | HTTPS | Браузеру нужен веб-протокол и защита канала |
| Загрузка архива на сервер | ZIP, TAR, резервная копия | SFTP, SCP или HTTPS | Нужна контролируемая передача файла |
| Получение курса валют | JSON с числовыми значениями | HTTPS API | Приложение обращается к формальному интерфейсу |
| Поиск IP домена | A, AAAA, CNAME и другие записи | DNS | Нужно сопоставить имя и сетевые параметры |
| Перезапуск веб-сервера | Команда и её вывод | SSH | Требуется удалённая оболочка |
Есть ли шифрование
Наличие шифрования нельзя определять только по назначению. Например, API может быть защищённым или открытым — всё зависит от того, использует ли оно HTTPS, VPN, TLS поверх другого транспорта или вообще не имеет шифрования. Аналогично, FTP бывает обычным, FTPS или заменённым на SFTP.
HTTPS защищает HTTP с помощью TLS, SSH шифрует собственный сеанс, а классические HTTP, FTP и DNS передают данные без встроенной конфиденциальности. Для DNS существуют DNS over TLS и DNS over HTTPS, но они защищают канал между клиентом и DNS-резолвером, а не весь последующий обмен с сайтом.
| Технология | Защита по умолчанию | Что именно защищается | Важное ограничение |
|---|---|---|---|
| HTTP | Нет | Ничего на транспортном уровне | Данные могут быть прочитаны или изменены в пути |
| HTTPS | Да | HTTP-трафик между клиентом и TLS-сервером | Не защищает уязвимое приложение от взлома |
| FTP | Нет | — | Логины и файлы могут передаваться открыто |
| SSH | Да | Сеанс, команды, туннели, передаваемые файлы | Нужно защищать ключи и учётные записи |
| API | Зависит от реализации | Определяется транспортом и механизмами авторизации | HTTPS не заменяет проверку прав доступа |
| DNS | Обычный DNS — нет | В DoH/DoT — канал до резолвера | Защита DNS не шифрует весь интернет-трафик |
Как связаны с TCP/IP
Модель TCP/IP удобно представлять как набор уровней. Нижние уровни отвечают за доставку пакетов по сети, а верхние — за смысл передаваемых сообщений. HTTP, FTP, SSH и DNS обычно относят к прикладному уровню. TCP обеспечивает надёжную доставку для многих из них, но современные протоколы могут использовать и другие варианты.
| Уровень | Примеры | Роль |
|---|---|---|
| Прикладной | HTTP, HTTPS, FTP, SSH, DNS, API | Определяет смысл сообщений и правила обмена |
| Транспортный | TCP, UDP, QUIC | Передаёт данные между сетевыми приложениями |
| Межсетевой | IP, ICMP | Доставляет пакеты между сетями |
| Канальный | Ethernet, Wi-Fi | Передаёт кадры в конкретной физической или локальной сети |
Важно не смешивать API с уровнем TCP/IP. API может быть реализован поверх HTTPS, WebSocket, TCP, UDP, gRPC или даже локального механизма операционной системы. Это описание интерфейса и правил вызова, а не обязательная транспортная оболочка.
Типичные сценарии применения
Одна и та же инфраструктура часто использует все перечисленные технологии одновременно. Веб-сайт может обслуживать посетителей по HTTPS, получать настройки через DNS, отдавать данные мобильному приложению через API, а команда разработки — подключаться к серверу по SSH.
| Задача | Что происходит | Основная технология | Дополнительные технологии |
|---|---|---|---|
| Посетитель открывает сайт | Имя преобразуется в IP, затем загружается страница | HTTPS | DNS, TCP или QUIC |
| Мобильное приложение получает профиль | Приложение отправляет запрос и получает JSON | API | HTTPS, DNS, авторизация |
| Администратор исправляет конфигурацию | Открывает удалённую оболочку и выполняет команды | SSH | DNS или IP, ключи доступа |
| Резервная копия передаётся на хранилище | Файл загружается по защищённому каналу | SFTP или HTTPS | SSH либо API хранилища |
| Почтовый сервер ищется по домену | DNS возвращает MX-записи | DNS | SMTP, TLS |
Практический сценарий: открытие сайта 1. Пользователь вводит https://cio-navigator.ru. 2. DNS возвращает адрес сервера. 3. Браузер устанавливает TCP-соединение или QUIC-сеанс. 4. TLS проверяет сертификат cio-navigator.ru. 5. Браузер отправляет HTTP-запрос. 6. Сервер возвращает HTML и дополнительные ресурсы. Вывод: в одном действии участвуют DNS + HTTPS + транспортный протокол.
Как технологии работают вместе в одном запросе
Чтобы окончательно развести понятия, полезно проследить путь обычного запроса от браузера до сервера. Пользователь видит только адрес страницы и результат на экране, но внутри происходит несколько последовательных операций.
Веб-страница не «работает на DNS» и не «открывается по SSH»: каждая технология выполняет свой этап общей цепочки.
Шаг 1. Имя преобразуется в адрес
Браузер передаёт доменное имя системному DNS-резолверу. Резолвер проверяет локальный кэш, а при необходимости обращается к другим DNS-серверам. В результате клиент получает IP-адрес, по которому можно искать сервер.
DNS может вернуть IPv4-запись A, IPv6-запись AAAA, псевдоним CNAME или несколько адресов. Несколько адресов позволяют распределять нагрузку и повышать отказоустойчивость, хотя сам факт наличия нескольких записей не гарантирует идеальную балансировку.
Домен: www.cio-navigator.ru DNS-ответ: A 203.0.113.20 AAAA 2001:db8::20 Клиент выберет подходящий сетевой путь, после чего начнёт соединение с сервером.
Шаг 2. Устанавливается транспортное соединение
Для классического HTTPS обычно используется TCP-порт 443. TCP устанавливает соединение и обеспечивает доставку данных в правильном порядке. В HTTP/3 используется QUIC, который работает поверх UDP и самостоятельно реализует необходимые механизмы надёжности и управления соединением.
Порт — это не отдельная программа и не гарантия того, что сервис действительно работает. Это номер логической точки, на которой приложение ожидает соединения. Если сервер слушает HTTPS на нестандартном порте, адрес может выглядеть как https://cio-navigator.ru:8443.
| Сервис | Стандартный порт | Что важно знать |
|---|---|---|
| HTTP | 80/TCP | Незащищённый веб-трафик |
| HTTPS | 443/TCP или UDP | TCP используется HTTP/1.1 и HTTP/2, UDP — HTTP/3 через QUIC |
| FTP | 21/TCP | Порт управляющего соединения; канал данных зависит от режима |
| SSH и SFTP | 22/TCP | SFTP работает внутри SSH, а не поверх FTP |
| DNS | 53/UDP и TCP | TCP нужен, например, для крупных ответов и передачи зон |
Шаг 3. TLS проверяет сервер и шифрует канал
После установления TCP-соединения HTTPS-клиент и сервер проводят TLS-рукопожатие. Сервер отправляет сертификат, клиент проверяет цепочку доверия, имя домена и срок действия. Затем стороны согласуют криптографические параметры и создают сеансовые ключи.
После этого содержимое HTTP-запросов шифруется. Наблюдатель в сети может видеть факт соединения и некоторые метаданные, но не должен получать открытый пароль, текст формы или тело API-запроса.
Без TLS: Наблюдатель → видит POST /login и содержимое формы С TLS: Наблюдатель → видит факт соединения с сервером Клиент и сервер → обмениваются зашифрованными данными Важно: сертификат подтверждает сервер и помогает защитить канал, но не проверяет добросовестность владельца сайта.
Шаг 4. HTTP или API обмениваются данными
После TLS браузер отправляет HTTP-запрос. Если запрос адресован API, он может содержать JSON, токен авторизации и параметры фильтрации. Для сервера это всё равно HTTP-сообщение, но смысл запроса определяется правилами конкретного API.
Так становится понятна разница: HTTPS отвечает за защищённую доставку, а API — за содержание и правила взаимодействия. Один и тот же API теоретически может иметь несколько реализаций транспорта, хотя на практике HTTPS встречается чаще всего.
HTTP-транспорт:
POST /v1/users HTTP/1.1
API-контракт:
{
"email": "user@cio-navigator.ru",
"name": "Анна"
}
HTTPS:
защищает весь запрос от просмотра в пути.
Интересные факты
Некоторые особенности этих технологий особенно часто вызывают вопросы. Они важны потому, что привычные упрощения вроде «HTTPS всегда TCP» или «API — это JSON по HTTP» верны не во всех случаях.
Сетевые названия описывают разные свойства системы: протокол может определять транспорт, API — правила обмена, а DNS — способ обнаружения узла.
HTTPS не всегда работает поверх TCP
В классическом варианте HTTPS использует HTTP/1.1 или HTTP/2 поверх TCP и TLS. Но HTTP/3 работает через QUIC, а QUIC использует UDP. Это не делает HTTP/3 «незащищённым»: криптография встроена в QUIC и основана на TLS 1.3.
UDP сам по себе не означает отсутствие надёжности. Он предоставляет более простой механизм доставки датаграмм, а QUIC добавляет шифрование, контроль потока, повторную передачу потерянных данных и другие функции.
| Версия | Транспорт | Шифрование | Особенность |
|---|---|---|---|
| HTTP/1.1 | TCP | TLS при HTTPS | Текстовые запросы, последовательная модель обмена |
| HTTP/2 | TCP | Практически всегда TLS в браузерах | Мультиплексирование потоков в одном соединении |
| HTTP/3 | QUIC поверх UDP | TLS 1.3 встроен в QUIC | Быстрее восстанавливает работу при изменении сети |
API — не обязательно HTTP
REST API действительно обычно работает через HTTP или HTTPS, но это не единственный вариант. Внутренние сервисы могут использовать gRPC, WebSocket, очереди сообщений, Unix-сокеты, TCP-протоколы или библиотеки, вызываемые внутри одного процесса.
Выбор зависит от задачи. Для публичного веб-сервиса удобен HTTPS REST или GraphQL, для постоянного двустороннего соединения — WebSocket, для взаимодействия микросервисов — gRPC, а для фоновых операций — очередь сообщений.
Примеры API: REST API → HTTPS + JSON GraphQL → HTTPS + единая точка запроса gRPC → HTTP/2 + Protocol Buffers WebSocket API → постоянное двустороннее соединение Local API → Unix socket или библиотечный вызов API описывает доступные операции, но не обязан быть REST и не обязан возвращать JSON.
DNS нужен ещё до открытия HTTPS-соединения
Если пользователь вводит доменное имя, клиенту сначала нужно узнать, куда подключаться. Поэтому DNS часто оказывается одним из первых этапов. Исключение — ситуации, когда адрес уже есть в кэше, задан напрямую в файле hosts или приложение заранее знает IP.
При этом DNS-запрос не всегда происходит ровно перед каждым открытием страницы. Ответы кэшируются на время, которое задаёт значение TTL. Благодаря кэшу сокращается задержка и уменьшается нагрузка на DNS-инфраструктуру.
Обычная последовательность: Доменное имя ↓ DNS-кэш или DNS-резолвер ↓ IP-адрес ↓ TCP или QUIC ↓ TLS ↓ HTTP-запрос ↓ Ответ веб-сервера
SSH и HTTPS оба защищают соединение, но решают разные задачи
И SSH, и HTTPS используют криптографию, однако пользовательская модель у них разная. HTTPS обычно обслуживает запросы большого числа клиентов к веб-приложению. SSH предоставляет авторизованному пользователю удалённый доступ к командной оболочке или отдельной подсистеме.
Нельзя заменить SSH на HTTPS только потому, что оба протокола шифруют данные. Веб-панель управления может выполнять часть административных функций через HTTPS, но полноценная диагностика сервера, работа с файлами и системными службами обычно требуют SSH или другого административного канала.
| Свойство | HTTPS | SSH |
|---|---|---|
| Основной пользователь | Посетитель, приложение, браузер | Администратор, разработчик, автоматизированный скрипт |
| Главная задача | Получить веб-ресурс или вызвать API | Выполнить команды и управлять системой |
| Идентификация сервера | TLS-сертификат | Ключ хоста |
| Аутентификация клиента | Сессия, пароль, токен, сертификат | Пароль, SSH-ключ, сертификат и другие методы |
| Основной риск | Уязвимое приложение или украденный токен | Компрометация ключа или чрезмерные права пользователя |
FTP, FTPS и SFTP — не одно и то же
Одинаковое слово «FTP» в названиях часто создаёт путаницу. Обычный FTP — самостоятельный протокол передачи файлов без шифрования. FTPS — это FTP, дополненный TLS. SFTP расшифровывается как SSH File Transfer Protocol и работает внутри SSH, используя другой механизм обмена.
| Вариант | Основа | Типичный порт | Защита | Особенность |
|---|---|---|---|---|
| FTP | FTP | 21 и дополнительные порты | Нет встроенного шифрования | Сложнее настраивать через firewall из-за отдельных каналов |
| FTPS | FTP + TLS | 21 или 990, зависит от режима | TLS | Сохраняет модель FTP и его особенности |
| SFTP | SSH | 22 | Шифрование SSH | Не совместим с обычным FTP-сервером |
Примеры команд FTP: ftp cio-navigator.ru SFTP: sftp user@cio-navigator.ru put backup.tar.gz SCP: scp backup.tar.gz user@cio-navigator.ru:/srv/backups/ HTTPS-загрузка: curl -X POST -F "file=@backup.tar.gz" https://api.cio-navigator.ru/upload Команды выглядят похоже по цели, но используют разные протоколы.
Практический выбор технологии
В реальной работе вопрос обычно звучит не «какой протокол лучше вообще», а «что выбрать для конкретной задачи». Нужно учитывать тип данных, требования к безопасности, доступность портов, способ авторизации, удобство автоматизации и поддержку со стороны сервера.
Правильный выбор начинается не с названия протокола, а с формулировки задачи: показать, найти, передать, выполнить или интегрировать.
| Задача | Предпочтительный вариант | Когда подходит альтернатива | Чего избегать |
|---|---|---|---|
| Открыть сайт | HTTPS | HTTP только для перенаправления на HTTPS или локальной разработки | Передачи паролей через HTTP |
| Получить данные приложением | HTTPS API | gRPC, WebSocket или очередь при особых требованиях | Публикации API без авторизации и ограничений |
| Администрировать сервер | SSH с ключами | VPN или защищённая панель управления | Открытого SSH с простым паролем для всех адресов |
| Передать файл между серверами | SFTP, SCP или HTTPS | FTPS при необходимости совместимости с FTP-инфраструктурой | Обычного FTP через Интернет |
| Найти IP домена | DNS | hosts для локального теста | Жёсткой привязки к IP, если адрес может измениться |
Когда нужен HTTPS
HTTPS следует использовать для публичных сайтов, личных кабинетов, форм, интернет-магазинов, веб-хранилищ и API. Даже если страница не содержит паролей, шифрование снижает риск подмены содержимого и защищает историю взаимодействия от просмотра в пути.
Минимальная практическая настройка включает действующий сертификат, корректную цепочку сертификатов, перенаправление с HTTP на HTTPS, актуальные версии TLS и отсутствие смешанного контента, когда защищённая страница загружает ресурсы по обычному HTTP.
Проверка сайта: curl -I http://cio-navigator.ru # Ожидается перенаправление на HTTPS curl -I https://cio-navigator.ru # Ожидается корректный HTTP-ответ Проверка API: curl -sS https://api.cio-navigator.ru/health Не следует отключать проверку сертификата только ради того, чтобы «запрос начал работать».
Когда нужен SSH
SSH выбирают, если нужно управлять операционной системой, а не просто получить страницу. Через него устанавливают пакеты, редактируют конфигурацию, проверяют процессы, изучают журналы и выполняют автоматизированные сценарии.
Для production-серверов обычно применяют ключевую аутентификацию, ограничивают доступ по IP или через VPN, отключают ненужные способы входа и предоставляют пользователям минимально необходимые права. Перенос SSH с порта 22 может уменьшить поток автоматических сканирований, но сам по себе не заменяет аутентификацию и firewall.
Безопасный рабочий подход: ssh-keygen -t ed25519 ssh-copy-id admin@cio-navigator.ru ssh admin@cio-navigator.ru На сервере: - запретить вход root по паролю; - использовать отдельные учётные записи; - ограничить доступ firewall; - хранить закрытый ключ с правами 600; - регулярно проверять authorized_keys.
Когда нужен API
API нужен, когда одна программа должна получать данные или запускать операцию в другой системе без участия человека. Хороший API описывает адреса методов, параметры, форматы ответов, коды ошибок, авторизацию, ограничения частоты запросов и правила версионирования.
При проектировании API важно разделять транспортную защиту и права доступа. HTTPS скрывает содержимое запроса от наблюдателей, но не отвечает на вопрос, может ли конкретный пользователь удалить заказ или получить данные другого клиента.
| Компонент API | Что нужно определить | Пример |
|---|---|---|
| Ресурс | С чем работает метод | /users, /orders, /products |
| Операция | Что сделать | GET, POST, PATCH, DELETE |
| Формат | Как выглядят данные | JSON, XML, protobuf |
| Авторизация | Как подтвердить права | Bearer-токен, OAuth 2.0, mTLS |
| Ошибки | Как клиент поймёт причину отказа | HTTP-код и структурированное сообщение |
| Ограничения | Сколько запросов разрешено | 100 запросов в минуту на ключ |
Пример корректного API-ответа с ошибкой
HTTP/1.1 401 Unauthorized
Content-Type: application/json
{
"error": {
"code": "invalid_token",
"message": "Токен отсутствует или истёк",
"request_id": "req-8f31"
}
}
HTTPS защищает сообщение,
а API сообщает приложению, что именно пошло не так.
Когда нужен DNS
DNS нужен практически всякий раз, когда сервис доступен по доменному имени. Помимо адресов веб-серверов, DNS хранит MX-записи для почты, TXT-записи для проверок и политик, CNAME для псевдонимов и SRV-записи для обнаружения отдельных сервисов.
При настройке DNS важно учитывать TTL, время распространения изменений, наличие IPv6, корректность делегирования зоны и различие между авторитетным сервером и рекурсивным резолвером. Изменение записи не всегда становится видимым мгновенно: старые ответы могут оставаться в кэшах до окончания TTL.
| Тип записи | Назначение | Пример смысла |
|---|---|---|
| A | Связывает имя с IPv4 | cio-navigator.ru → 203.0.113.10 |
| AAAA | Связывает имя с IPv6 | cio-navigator.ru → 2001:db8::10 |
| CNAME | Создаёт псевдоним имени | www → cio-navigator.ru |
| MX | Указывает почтовые серверы | Почта домена обслуживается mail.cio-navigator.ru |
| TXT | Хранит текстовые параметры | SPF, подтверждение владения, политики |
| NS | Указывает авторитетные DNS-серверы | Какие серверы отвечают за DNS-зону |
Диагностика DNS: dig cio-navigator.ru A dig cio-navigator.ru AAAA dig cio-navigator.ru MX dig cio-navigator.ru TXT Если A-запись неверна, HTTPS-сертификат может быть исправным, но браузер попадёт не на тот сервер или вообще не установит соединение.
Типичные ошибки и заблуждения
Большинство проблем возникает не из-за сложности самих протоколов, а из-за неверного представления об их границах.
Путаница в названиях и функциях
Ниже собраны ошибки, которые особенно часто встречаются при настройке сайтов и интеграций.
Понимание роли технологии часто важнее запоминания её порта: порт подсказывает, куда подключаться, но не объясняет, что именно умеет сервис.
- «API — это отдельный протокол вроде HTTPS». Нет, API — интерфейс и набор правил, который может использовать HTTPS, gRPC, WebSocket и другие механизмы.
- «Если есть HTTPS, сервер полностью защищён». TLS защищает канал, но не устраняет уязвимости приложения, ошибки авторизации и вредоносные файлы.
- «SFTP — это FTP с буквой S». SFTP работает через SSH и технически отличается от FTPS.
- «DNS отвечает только за сайты». DNS используется также для почты, проверок домена, обнаружения сервисов и распределения нагрузки.
- «Нужно открыть все порты, чтобы всё работало». Наоборот, безопаснее открыть только необходимые службы и ограничить доступ к ним.
- «Нестандартный порт делает сервис защищённым». Смена порта может снизить количество случайного шума, но не заменяет шифрование и контроль доступа.
Ошибка диагностики Пользователь: «HTTPS не работает». Проверка: 1. DNS возвращает старый IP. 2. На новом сервере сертификат ещё не установлен. 3. Порт 443 закрыт firewall. Вывод: Проблема может быть не в HTTPS как протоколе, а в DNS, сертификате или сетевом доступе.
Как не перепутать проблему протокола и проблему настройки
Диагностику лучше проводить по этапам. Сначала проверяют разрешение имени, затем доступность порта, затем сертификат и только после этого — ответ приложения. Такой порядок экономит время: бессмысленно отлаживать JSON API, если домен указывает на неправильный сервер.
- Проверить, какой IP возвращает DNS.
- Проверить доступность нужного порта.
- Проверить сертификат и имя домена.
- Посмотреть HTTP-код ответа.
- Проверить авторизацию и формат запроса.
- Изучить журналы веб-сервера и приложения.
Пример последовательной проверки:
dig api.cio-navigator.ru
nc -vz api.cio-navigator.ru 443
curl -Iv https://api.cio-navigator.ru/health
curl -H "Authorization: Bearer TOKEN"
https://api.cio-navigator.ru/v1/profile
Каждая команда проверяет отдельный слой:
DNS → порт → TLS/HTTP → API и авторизация.
Безопасность: что защищать в первую очередь. Чек-лист
У каждой технологии свои основные риски. Для HTTPS критичны сертификаты и конфигурация TLS, для SSH — ключи и права пользователей, для API — авторизация и валидация входных данных, для DNS — корректность зоны и защита аккаунта регистратора.
Безопасность складывается из нескольких независимых уровней. Зашифрованный канал не спасёт, если сервер принимает слишком простые пароли, API не проверяет права, а закрытый SSH-ключ хранится в открытом виде на общем компьютере.
| Объект защиты | Основной риск | Практическая мера |
|---|---|---|
| TLS-сертификат | Истёк, выпущен не для того домена или неправильно установлен | Автоматическое продление и мониторинг срока действия |
| SSH-ключ | Кража закрытого ключа | Защита passphrase, права файлов, аппаратное хранилище |
| API-токен | Утечка в коде, логах или репозитории | Секрет-хранилище, ротация, минимальные права |
| DNS-аккаунт | Подмена записей домена | MFA, разграничение ролей, уведомления об изменениях |
| FTP-учётная запись | Перехват пароля и несанкционированная загрузка файла | Отказ от обычного FTP в пользу SFTP, FTPS или HTTPS |
Минимальный чек-лист перед публикацией сервиса [ ] Домен указывает на правильный IP. [ ] Сертификат действителен и соответствует домену. [ ] HTTP перенаправляется на HTTPS. [ ] API требует авторизацию там, где это необходимо. [ ] SSH доступен только нужным пользователям. [ ] Обычный FTP отключён или изолирован. [ ] DNS-аккаунт защищён MFA. [ ] Секреты не находятся в публичном репозитории.
Итоги
HTTP и HTTPS используются для веб-взаимодействия: первый передаёт данные без встроенного шифрования, второй делает это через TLS. FTP предназначен для передачи файлов, но классический вариант небезопасен для открытых сетей. SSH обеспечивает защищённый удалённый доступ к серверу и служит основой для SFTP. DNS сопоставляет доменные имена с IP-адресами и другими записями. API описывает, как программы обращаются друг к другу, и может работать поверх разных транспортов.
Главное — не считать эти технологии прямыми конкурентами. В одном сценарии они дополняют друг друга: DNS помогает найти сервер, HTTPS защищает веб-соединение, API задаёт правила обмена данными, SSH позволяет администратору управлять инфраструктурой, а SFTP переносит файлы через защищённый канал. Когда роли разделены, становится значительно проще выбирать инструменты, настраивать безопасность и искать неисправности.