В чем отличие ngnix от golang?

Question

[NikitaW]

Всем привет. Решил пересесть с фронта на бек. Начал читать про сервера. И вообще запутался. Если Niginx - это веб-сервер. А go - это ЯП, на котором делают серверное приложение, то как go может работать на ngnix? Т.е это же две одинаковые вещи. Ток nginx - это уже все готовое, а на go надо все с нуля делать?

Answer 1

[Сергей Горностаев]

Ну раз с фронта пересели, то аналогию понять должны: В чëм отличие Google Chrome от JavaScript?

Comments

[AUser0]

И добавить нечего.

P.S. NikitaW, а веб-сервер и ЯП - это реально одинаковые вещи, да? Или просто ЯП может сделать всё то, что напрограммировал автор(ы) в своём веб-сервере. А?

[Sergio]

согласен если разговор бы шёл о чём-то вроде PHP, но для Go не очень пример

[Сергей Горностаев]

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

Answer 2

[Roman K]

nginx — это реверс-прокси
go — это яп.

в чём вопрос-то?

то как go может работать на ngnix?

nginx проксирует запрос в сервер на го, который пишет программист. Цепочка проксей может быть сколько угодно большой. Ты можешь поставить nginx -> nginx -> caddy -> nginx -> gin, никто не запрещает.

Comments

[NikitaW]

Т.е можно сказать nginx - это готовое решение, а на go уже можно свою логику писать? Так же можно и без nginx и apache обойтись. Только все с нуля надо будет писать?

[ThunderCat]

NikitaW, нжинкс - софт, позволяющий обращаться к физическому серверу по определенным протоколам (чаще всего это http/https). После получения запроса нжинкс (или любой другой вебсервер) поступает с запросом так, как прописывает в правилах админ. Чаще всего либо читает запрошенный ресурс из определенной папки сервера и отдает ее обратно клиенту, либо читает поток, отдаваемый другой программой, например скриптом на го или пхп.

[Станислав Макаров]

NikitaW

Так же можно и без nginx и apache обойтись. Только все с нуля надо будет писать?

Да, в определённом смысле вы правы. Действительно можно написать самому веб-сервис на Go и задеплоить его, чтобы он работал и принимал HTTP-запросы. Более того, в большинстве случаев в режиме разработки/отладки вы и будете запускать свой написанный на Go сервис и слать к нему запросы.

Но при приближении твоего проекта к боевому применению у тебя возникнут как минимум такие задачи:

• Вероятно помимо самого HTTP-сервиса ты захочешь ещё и сделать доступным для внешних посетителей какой-то веб-клиент. Иными словами, у тебя встанет задача отдавать посетителям статику. Да. ты можешь прикрутить для этого какую-то Go-библиотеку, такие наверняка есть, но фишка в том, что nginx - это очень хитрый сервер, написанный на Сях, архитектура которого очень хорошо справляется с отдачей статики очень большому числу клиентов. Кроме того, он очень эффективно использует всякие системные API, ну короче говоря он на этом собаку съел.
  
• Когда (и если) ты выставишь свой сервер во внешний интернет - то как только твой проект получит какую-то популярность - его сразу начнут долбать всякие нехорошие личности. DoS-ить, сканить на уязвимости, будут пытаться злоупотреблять API-вызовами и т.д. и т.п. Ты очень быстро захочешь поставить рейт-лимиты, банить по IP, банить по всяким паттернам в запросах, ограничивать доступ к определённым урлам и тому подобное, иначе твой сервис просто порвут. Nginx (и куча других решений) справится с этим гораздо лучше тебя, у него уже много настроек для этого
  
• Прежде чем отбиваться от китайских ботоферм, тебе нужно будет сначала узнать, что твой сервис завалили мусорными запросами и что он уже прилёг. Для этого нужно будет прикрутить мониторинг на каком-нибудь Prometheus. С этим тоже лучше справится Nginx/Envoy/HAProxy и прочие решения
  

Говоря коротко - как всегда, всё дело в специализации софта и разнице между теорией и суровой боевой практикой. Нафига усложнять себе жизнь в своём веб-сервисе, если можно поставить его за надёжным промышленным прокси-сервером, а в сервисе сосредоточиться на бизнес-логике.

Answer 3

[Ипатьев]

На самом деле эта путаница по-человечески очень понятна и объяснима.
Вы, как фронтендер, воспринимаете "веб-сервер" как такой черный ящик, "то место, откуда фронт запрашивает данные".

В то время как этот термин может означать несколько разных понятий.
1. Веб-сервер в вашем, широком понимании. Бэкенд целиком.
2. Также веб-сервером может называться и сам компьютер, на котором все это крутится.
3. В более узком смысле - это программа, которая принимает НТТР запросы. Вот это nginx и есть. Но сам по себе, без помощи других программ, он не может полностью представлять услуги веб-сервера. Например, в нем нет базы данных. Это, скорее, как правильно написали в соседнем ответе - такой прокси-сервер, который частично обрабатывает запросы сам (например к статическим файлам), а частично - проксирует запросы на другие программы.

И вот на Го (или РНР, Питоне, JS, C#) как раз и пишется эта программа, которая, к примеру, обращается в БД, получает нужные данные и отдает их Nginx-у, который уже и возвращает их клиенту

Comments

[Lynn «Кофеман»]

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

[DollyPapper]

Lynn «Кофеман», с чего вы взяли что он будет плохой и тормозящий? Это PHP не может жить без фронтенд сервера, такова его природа, а вот go и прочие ноды жс спокойно живет и без этого. Роль жикса в приложениях на го заключается разве что в раздаче статики и proxy_pass. Ну и терминации SSL, хотя тот же go сам это может делать из коробки,нужно лишь немного функций из стандартной либы повызывать

[Lynn «Кофеман»]

DollyPapper, потому что те кто способен написать не кривой код не задают таких вопросов.

[Lynn «Кофеман»]

> раздаче статики и proxy_pass. Ну и терминации SSL

сделать это по простому очень просто. А вот дальше начинаются нюансы. Как не сожрать всю память, как работать одновременно с десятками тысяч клиентов? Как защитится от всяких атак и кривых запросов? И из таких мелочей в результате и набирается понимание что лучше сосредоточится на основной функции твоего приложения, а всю рутину отдать на откуп программе которая специально для этого написана и все эти мелочи уже учтены.

[ThunderCat]

DollyPapper,

Это PHP не может жить без фронтенд сервера

php -S localhost:8000
Все вышеперечисленные языки, "обходящиеся" без сервера, будут страдать точно так же, так как нжинкс не просто прокладка, а хорошо настроенный инструмент, написанный под конкретные задачи, с которыми сложно справиться средствами серверных языков, и смысл реализовать еще один веб сервер как бы отсутствует в большинстве случаев. Ну и для универсализации. То что в языки встроен функционал, способный обслуживать запросы, не делает их вебсервером-в-себе.

[Максим Федоров]

ThunderCat,

php -S localhost:8000
Все вышеперечисленные языки, "обходящиеся" без сервера, будут страдать точно так же

Если речь про голанг, то тут мимо (не также), стандартный сервер в го — супер-быстрый и легкий (в силу строения языка), по сути в nginx не нуждается... ну собственно на го и стандартном сервере в go написан "аналог" nginx — roadrunner, но и без шаманства, простой helloworld или детское поделие — уже мощное решение в гошке с этой точки зрения. Просто особенность языка по части асинхронщины и мощная стандартная либа

[Adamos]

Максим Федоров,

стандартный сервер в го... по сути в nginx не нуждается...

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

[ThunderCat]

Максим Федоров, Проблема не в том что он не быстрый, или что-то не может, а проблема в том что есть софт, заточенный под конкретные задачи. С готовым обслуживанием и кучей настроек, стандартизирующий область. Писать сервер на ЯП - вынос обслуживания в код, вместо обслуживания сервиса, что может быть приемлемо для какого-то кастомного решения или домашней поделки, но для бизнеса гемор и боль.

[Максим Федоров]

ThunderCat, в го не надо его писать, любое приложение на го — уже готовый сервер :) ну почти, если с http работает

[Максим Федоров]

Adamos,

Или нанять стандартного админа, который будет это делать, не зная никаких языков.

Если написано го-приложение, то как минимум есть гофер и шанс стандартного админа почти нулевой

[ThunderCat]

Максим Федоров, Еще раз - перекладывать ответственность за обработку запросов из сервиса в приложение не лучшая идея, размазывание ответственности есть показатель непонимания как работает бизнес. Сервер и его софт обслуживает админ, а программисты не занимаются прикладными административными задачами по типу переадресаций, привязки доменов и разруливанием/кэшированием статики. По этому 99,8% серверов работают через прокси сервисы а-ля нжинкс/апач/лайтхттп. Хотя в своих работах не на дядю вы вольны использовать что угодно и как угодно, экономя время и место на диске без "лишних серверов".

[Ипатьев]

мне кажется, это один из тех споров, в котором все стороны правы
и ломать копья тут совершенно не обязательно :)

[DollyPapper]

ThunderCat,

php -S localhost:8000

, ну мы же не прям про поделку говорим, а про хоть сколько то работающее решение. При таком запуске поправьте меня если я не прав, но пхп сможет одномоментно обслужить только одно подключение. Для этого и существуют всякие fpm и mod_php, которые процессы спавнят и между ними раскидывают запросы. А когда у нас есть прослойка с fpm, то тут уже без nginx не обойтись, потому что протокол общения другой. По этому я и сказал, что пхп не может жить без фронт сервера.

[ThunderCat]

DollyPapper, Так это для разработки, но тем не менее - обслуживание запросов он осуществляет. Другие языки тоже не сказать чтобы сильно пользуются встроенными веб серверами на проде. Почему - я уже объяснил выше.

По этому я и сказал, что пхп не может жить без фронт сервера.

Уточню, что не может на проде, что как раз не нужно от слова совсем. Для протестить локально этого хватает.

Answer 4

[res2001]

Веб сервер занимается обслуживанием сетевых соединений, передачей данных по сети и т.п. вещами.
Приложения на go, PHP и прочих питонах вызываются веб сервером для генерации ответа на пользовательский HTTP запрос, в приложение в качестве параметра передается сам запрос. В простейшем случае, веб-сервер в качестве ответа может просто возвращать статический файл на диске, а не запускать программу.
Таким образом приложение напрямую не взаимодействует по сети с клиентом, а работает через посредника - веб-сервер.

Comments

[NikitaW]

Ну кажись понял, тогда чем отличается статический файл от динамического? Ну вот HTML файл ты вернул браузеру - это статика?

[res2001]

NikitaW, Чаще всего это статика. Но могут быть варианты в зависимости от настроек веб-сервера.
Сейчас статика это обычно картинки, js скрипты, css и т.п. файлы, на которые могут быть ссылки в html коде.
Динамика - это ответ, сгенерированный приложением на лету.
Я не веб-разработчик, так что специфическими терминами могу не владеть, но некоторую основу знаю.

[NikitaW]

Т,е. один и тот же файл при разных условиях может быть статикой или динамикой?

[res2001]

NikitaW, И да и нет :)
На сколько я в курсе, веб-сервер можно настроить так, чтобы он воспринимал, например, расширение html как запуск приложения, в этом случае html файл может восприниматься как скрипт PHP.
Тогда запускается этот скрипт и генерирует динамический ответ клиенту. Т.е. в этом случае html файл должен действительно содержать PHP код.
Обычно так не делают, но, по моему, запрета на подобные шаманства нет.

[Adamos]

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

[NikitaW]

Adamos, а в каком случае на разные запросы может быть одинаковый ответ?
Можно пример пж, а то не оч понял

[Adamos]

NikitaW, например, кто бы откуда бы ни запросил /favicon.ico - на все эти запросы будет один и тот же ответ.
Вне зависимости от айпи, авторизации, фазы луны и прочих факторов.
А насчет "на разные" вы, собственно, придумали сами. Я этого не говорил.