FastCGI vs HTTP

может потому, что FastCGI проще, чем HTTP

Веб не ограничивается одни лишь HTTP(1.0, 1.1, 2, 3), есть еще вебсокеты… Есть еще такой момент, что используются неблокирующие сокеты. Демон на php постоянно пишет в сокет и не ждет пока серверный процесс из сокета прочитает данные, а поэтому нужна дополнительная мета-информация типа requestId, длины содержимого и т.д.

Раньше в языках (и ныне в бомж-языках) не было http-библиотек (встроенного веб-сервера), зато был простой как дрова CGI, а FastCGI его идейное развитие. У вебсерверов был интерфейс к этому CGI/FastCGI и никто в здравом уме на тот момент не думал реализовывать веб-сервер в стандартной библиотеке языка.
FastCGI лишён мишуры присущей http типа его заголовков и т.п.
Может работать как по порту так и по юникс-сокету (чем обычно пользовались ибо быстрее), однако не везде он одинаково полезен, например в golang этот FastCGI оказывается существенно медленнее http-библиотеки с её дальнейшим проксированием в nginx, тем более http там можно пустить тоже по юникс-сокету, так что реализацию надо учитывать.

расскажи мне, карл, как ты будешь распараллеливать фцги на апстримы, бекенды и прочий балансинг?

этот FastCGI оказывается существенно медленнее http-библиотеки с её дальнейшим проксированием в nginx

наоборот - нжинкс проксирует в цги

Чтобы каждый мог выполнять звездато свою задачу, а не нагружаться чужими.

просто http

HTTP - это не просто. Это текстовый протокол с кучей версий, подводных камней и редко используемых фич. Сделать эффективную реализацию сложно, сделать реализацию, которая будет работать с любыми клиентами еще сложнее, сделать реализцию, устойчивую к действиям кулхацкеров, пытащихся переполнить буферы или найти корнер-кейс в парсере, чтобы поломать систему - высший пилотаж.

А FastCGI - бинарный протокол с единственной версией. Приложение тратит меньше времени на борьбу с HTTP [*], так как это уже сделал за него реверс-прокси, и его никто случайно или специально не выставит голым задом в интернет к кулхацкерам, так как интернет не умеет в FastCGI

[*] Разработчики uWSGI посчитали, что этот FastCGI все же не является максимально эффективным, и запилили свой бинарный протокол с б и ш.

Любой проект расписывает почему он лучше других, ты можешь ознакомиться с этими моментами написав разработчикам или почитав доки.

Я тебе больше скажу: можно вообще ни CGI, ни fastCGI не использовать, а напрямую из веб-страницы работать с серверным демоном. Достаточно делать POST/GET запросы не на 80-й порт, который перехватывает апач или нжинкс, а на другой >1023!

Мне вот недавно лень было с вебсокетами заморачиваться для одной простой штуки, сделал именно так. Но если запросов по нескольку в секунду, понятное дело, лучше вебсокеты использовать, чтобы уменьшить накладные расходы (все равно ведь POST/GET обрастают жирной шапкой, и для пересылки пары байт фактически приходится несколько сотен гонять).

Спасибо большое! Теперь более менее понятно.

а ты быстрый!

Ого. А можно по подробнее? Просто я так понимаю это в любом случае будет делаться с помощью JS, а у него я знаю только XMLHTTPRequest и Fetch, которые вроде как через http работают.

Я просто путешествую во времени) правда только в одну сторону…

Все очень просто. Смотри здесь: я запускаю демон. Он слушает определенный порт (в данном случае 4444 или что ты выберешь через аргумент командной строки). При коннекте на этот порт, если ты подключился к сокету напрямую (неткатом или из своего приложения), работа идет как обычно. Но если ты вызываешь сокет из веба, то приходит соответствующая шапка → демон это определяет и данные высылает уже в веб-обертке, как нужно для ответа на POST или GET запрос.

Соответственно, из веб-морды у меня периодически отправляется POST-запрос для получения текущего значения фокуса, а если нужно какую-то команду отправить, выполняем другой POST-запрос с этой командой. Т.е. все, как и при работе с CGI, с тем лишь отличием, что вместо POST/GET host/cgi-bin/cginame?parameters=values ты делаешь POST/GET host:4444/?parameters=values

При этом, понятное дело, вместо того, чтобы запускать очередную копию CGI веб-сервер ничего не делает, т.к. его 80-й и/или 8080-й порт никто не опрашивал!

Аааа. Все, кажись понял. Все жирного веб-сервера или менее жирного fastcgi просто демон который умеет парсить post get и все.

P.S. По ссылке прошел, но честно говоря сложновато сишный код читать, поэтому в коде не лазил.

P.P.S. Спасибо!

сложновато сишный код читать А на чем ты веб собирался писать? Не на паскале же!

Нууу, вот Go например. Ну вообще конечно надо си подучить.