Как curl вырос из httpget в сетевую инфраструктуру

Команду curl часто встречают в документации к API: её можно вставить в терминал, быстро проверить запрос, а затем перенести его в код приложения. За привычной командой скрывается более длинная история. Проект начинался как маленькая программа для загрузки данных из интернета, несколько раз менял имя вслед за своими возможностями, а затем получил библиотеку libcurl, благодаря которой тот же сетевой движок оказался внутри множества других программ.

Задача для IRC-бота и чужой исходный код

В конце 1996 года шведский разработчик Даниэль Стенберг писал IRC-бота для канала об Amiga в сети EFnet. Он хотел добавить пересчёт валют, а нужные курсы уже публиковались в интернете, поэтому оставалось автоматически загрузить страницу и извлечь данные. Вместо разработки HTTP-клиента с нуля Стенберг взял открытую программу HttpGet, версию 0.1 которой бразильский разработчик Рафаэл Сагула выпустил 11 ноября 1996 года.

Стенберг внёс необходимые изменения, а 17 декабря вышла версия 0.2 с его доработками. Вскоре он стал сопровождающим проекта, однако первоначальная практическая задача продолжила определять его развитие: программе требовалось получать данные из разных источников, а не демонстрировать один конкретный протокол. Эта последовательность подробно зафиксирована в официальной истории curl.

Почему httpget сначала стал urlget, а затем curl

Название httpget точно описывало раннюю версию, пока программа работала главным образом с HTTP-загрузками. Затем к ней добавились Gopher и FTP, поэтому в августе 1997 года проект получил более общее имя urlget: теперь он обращался к ресурсу по URL, а не только загружал страницу по HTTP. Поддержка FTP upload и HTTP POST вскоре сделала тесным и это название, поскольку программа уже не ограничивалась получением данных.

20 марта 1998 года Стенберг выпустил curl 4, сохранив нумерацию предыдущих версий. Новое имя связывали с выражением «client for URLs», а слово curl одновременно напоминало о том, что программа работает с URL. Важнее самого переименования была логика развития: каждый новый протокол, способ аутентификации или режим передачи превращал небольшой загрузчик в универсальный клиент, пригодный не только для исходного IRC-бота.

Во второй половине 1990-х проект быстро набирал практические возможности. Появились SSL, cookies, Telnet, сборки для разных операционных систем и пакеты для Linux. Пользователи получили удобную команду, но её можно было применять только как отдельную программу: другой продукт либо запускал процесс curl, либо заново решал те же сетевые задачи внутри собственного кода.

libcurl превратил программу в строительный блок

Весной 2000 года внутреннее устройство curl серьёзно переработали ради библиотечного интерфейса, а в августе версия 7.1 принесла первый неэкспериментальный API libcurl. Уже в том же месяце появилась сторонняя привязка для PHP. Это был более существенный шаг, чем добавление очередного протокола, потому что разработчики получили возможность встроить сетевой движок в свою программу и управлять им через функции библиотеки.

Командная утилита и библиотека решают близкие, но не одинаковые задачи. CLI удобна человеку, shell-скрипту или системе сборки: команда описывает передачу, выполняется и возвращает результат. libcurl работает внутри длительно живущего приложения, где программа сама управляет соединениями, обработчиками данных, параллельными операциями и ошибками. При этом ей не приходится отдельно реализовывать URL, прокси, аутентификацию, TLS, cookies и особенности каждого поддерживаемого протокола.

Именно библиотека позволила curl выйти далеко за пределы терминала. Пользователь приложения может никогда не видеть это название, хотя передача данных внутри программы выполняется libcurl. Командная версия тоже продолжила распространяться как стандартная системная утилита, но подсчитать все установки невозможно: curl входит в операционные системы, поставляется через многочисленные зеркала и приезжает как часть другого программного обеспечения. Долговечность проекта при этом нельзя приписывать одному человеку. Стенберг остаётся ведущим разработчиком, а изменения, тестирование и разбор ошибок давно выполняет международное сообщество.

WebSocket решает другую сетевую задачу

HTTP-запрос удобно представить как законченную операцию: клиент задаёт метод, адрес, заголовки и тело, а сервер возвращает ответ. Современный HTTP допускает повторное использование соединений и потоковую передачу, поэтому различие с WebSocket нельзя свести к фразе «HTTP закрывается, а WebSocket остаётся открытым». Разница прежде всего в модели взаимодействия.

RFC 6455, опубликованный IETF в декабре 2011 года и подготовленный Иэном Фетте и Алексеем Мельниковым, стандартизовал протокол для двустороннего обмена сообщениями между браузерным клиентом и сервером. Соединение начинается с HTTP/1.1-запроса с заголовками Upgrade: websocket и Connection: Upgrade. Если сервер принимает переход, дальнейший обмен идёт уже кадрами WebSocket поверх того же TCP-соединения, а каждая сторона может отправлять сообщения независимо от другой.

Такая модель подходит чатам, совместным редакторам, панелям с живыми показателями и другим интерфейсам, где новые данные появляются не только в ответ на очередной запрос пользователя. WebSocket не заменяет HTTP API: обычно приложение использует обычные запросы для загрузки и изменения ресурсов, а постоянное соединение оставляет для событий, которые должны приходить без регулярного опроса сервера.

Что именно делает API Sandbox

API & Web Sandbox объединяет эти две повседневные задачи в соседних вкладках. cURL Converter не выполняет запрос и не пытается воспроизвести весь curl. Он разбирает URL, метод -X или --request, заголовки -H, несколько вариантов --data, Basic Auth через -u и явный --url, а затем переносит получившуюся структуру запроса в один из двадцати вариантов. Среди них Fetch API, Axios, нативный Node.js, Python, PHP, Go, C#, Java, Swift, Rust, HTTPie, Wget, PowerShell и коллекция Postman.

Неизвестный параметр приводит к понятной ошибке, но некоторые флаги командной строки, например --location, --insecure, --silent, --include, --verbose и --compressed, пропускаются, поскольку они описывают выполнение curl или вывод, а не базовую структуру запроса. Поэтому результат следует читать как заготовку для кода. Конвертер не переносит файлы и multipart-формы, cookies, клиентские сертификаты, прокси, сложные схемы аутентификации и все особенности shell. Кроме того, сгенерированный браузерный fetch подчиняется CORS и другим ограничениям браузера, даже если исходная команда успешно работает в терминале.

WebSocket Tester, напротив, действительно открывает соединение через браузерный API WebSocket. Он принимает адрес ws:// или wss://, отправляет текстовые сообщения, показывает время и направление событий, хранит до 200 последних записей и по желанию форматирует JSON. Двоичные сообщения отмечаются в журнале без просмотра содержимого; произвольные заголовки, выбор подпротокола и настройка кадров интерфейс не поддерживает. На странице, открытой по HTTPS, также следует использовать защищённый адрес wss://, иначе браузер может заблокировать смешанный контент.

Для быстрой проверки вставьте в конвертер простую команду с -X, -H и -d, сравните сгенерированные варианты и обратите внимание, какая часть запроса сохраняется в каждом языке. Во второй вкладке лучше подключаться к собственному тестовому WS/WSS-серверу: тогда журнал покажет открытие соединения, отправленные сообщения, ответы и код закрытия без передачи данных через промежуточный сервис API Sandbox.

Похожие инструменты

API и веб-песочницаПревращайте команды cURL в код на JavaScript, Python, PHP или Go, либо открывайте живое WebSocket-соединение и наблюдайте за сообщениями — прямо в браузере.JSON ToolboxПроверяйте синтаксис, форматируйте или минифицируйте данные и просматривайте вложенные API-ответы и конфиги в виде дерева.JWT InspectorДекодируйте JWT в читаемый header и payload, проверяйте срок действия и время выпуска и проверяйте подписи HS256, RS256 или ES256 локально.Генератор пар ключейГенерируйте пары ключей Ed25519 или RSA (2048/4096) через Web Crypto API — публичный ключ в формате OpenSSH, приватный ключ в PEM, отпечаток SHA256 и скачивание файлов — всё локально.Telegram Webhook TesterРазбор webhook-апдейтов Telegram Bot API, повторная отправка на любой endpoint и проверка или подпись initData Mini App через HMAC-SHA256 — полностью в браузере.Telegram Stars InvoiceСборка и проверка payload createInvoiceLink с корректными единицами суммы для Stars, обычных валют и валют без дробной части, экспорт в cURL, Node, Python и PHP.Webhook Signature VerifierПроверка подписей webhook для семи провайдеров: точная подписываемая строка, окно защиты от replay и экспорт кода верификации для Node, Python, PHP и Go.