LINUX.ORG.RU

FastCGI vs HTTP

 ,


0

1

Добрый день! Задался таким вопросом - Зачем вообще придумали протокол fastcgi когда уже существовал http. CGI понятно - сервер запустил скипт, передал ему переменные, скрипт отработал отдал страничку серверу, сервер клиенту. На каждый вызов новый процесс. Но в FastCGI мы уже демонизируем интерпритатор, слушаем какой то порт, зачем было создавать еще протокол, оборачивать все в fastcgi записи, если можно было передать данные просто http?

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

Harald ★★★★★
()

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

tz4678 ★★
()

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

EvilFox ★★
()
Последнее исправление: EvilFox (всего исправлений: 2)

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

deep-purple ★★★★★
()
Ответ на: комментарий от EvilFox

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

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

deep-purple ★★★★★
()

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

r_asian ★☆☆
()
10 марта 2020 г.

просто http

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

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

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

annulen ★★★★★
()
Последнее исправление: annulen (всего исправлений: 1)

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

anonymous
()

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

kovalev_94
() автор топика
Ответ на: комментарий от deep-purple

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

kovalev_94
() автор топика
Ответ на: комментарий от kovalev_94

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

kovalev_94
() автор топика
Последнее исправление: kovalev_94 (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

kovalev_94
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.