Все пытаюсь понять основное назначение сервисов\программ типа nginx. Скорее пытаюсь понять их генезис, для чего их разрабатывали изначально, какие проблемы решали, а не для чего и как
впоследствии стали использовать. Появление подобных инструментов продиктовано ростом нагрузки на соотв. узел\сервис. Т.е. как мне кажется, основная задача была в
удержании соединения клиента, коих много. Т.е. пока бд найдет данные, сервер отрендерит страницу и т.д. все это время связь с клиентом должна сохранятья, т.е. клиент
не должен отваливаться по таймауту только из-за каких-то задержек, а не из-за сбоя. Таким образом это некая абстракция, которая поддерживала связь с клиентом, в то
время как его запрос выполнялся. Такое себе прокси. Далее, допустим у нас начало 00-х и по идее одна машина может справиться с большим кол-ом запросов
одновременно, но удерживать многия тысячи соединений уже сильно накладно, т.е. развели по разным машинам дисковое io и сетевое io. Ну а далее, поскольку серверов понадобилось
сильно больше чем один, плюс async io в помощь, и появилась возможность накидывать новые ф-ии для этого промежуточного уровня -- load-balancer, health check, cdn(??) и т.д.
Является ли верным данный генезис, т.е. сначал это было прокси для мн-ва клиентских запросов, а далее логичное развитие в lb и т.д.? Или сразу в lb?
S>>Все пытаюсь понять основное назначение сервисов\программ типа nginx. T>Конкретно про nginx можно почитать интервью с его автором https://xakep.ru/2012/01/09/58122/
По ссылке:
На тот момент были уже другие похожие серверы, но все они не умели проксировать, они отдавали только статику.
Что он имеет в виду под "проксировать"? Что они не умели держать соединение, а просто были кэшем -- отдавали статику?
Я правильно понимаю, что умение держать соединение с клиентом, но при этом выполнять для него какие-то запросы и есть reverse proxy?
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, Twirl, Вы писали:
S>Что он имеет в виду под "проксировать"? Что они не умели держать соединение, а просто были кэшем -- отдавали статику? S>Я правильно понимаю, что умение держать соединение с клиентом, но при этом выполнять для него какие-то запросы и есть reverse proxy?
В тех системах с которыми я работал reverse proxy отдает то что лежит в кэше.
Если кэш устарел то:
1. Либо отдаем то что лежит в кэше и делаем одновременно запрос на бэкенд для подтягивания свежей версии (хорошо с точки зрения нагрузки, но не всегда возможно с точки зрения бизнес логики),
2. Либо делаем запрос на бэкенд, кэшируем, и отдаем клиенту
Если я правильно понимаю цитату, то раньше не было нормального вебсервера которые позволял бы иметь несколько бэкендов для одного сайта (lb) и кэшировать результат запросов в одном месте (proxy).
Здравствуйте, Sharov, Вы писали:
S>Что он имеет в виду под "проксировать"? Что они не умели держать соединение, а просто были кэшем -- отдавали статику? S>Я правильно понимаю, что умение держать соединение с клиентом, но при этом выполнять для него какие-то запросы и есть reverse proxy?
Нет, reverse proxy — это такая HTTP прокся, которая работает не как обычно, на стороне клиента, а на стороне сервера. Nginx это не только reverse proxy, он еще умеет самостоятельно раздавать статический контент.
Вообще, во времена, когда появился nginx, основным веб-сервером был апач. Апач — очень умный веб-сервер, но и очень тормозной в то же время. Идея заключалась в том, чтобы освободить апач от всех обязанностей, которые не требуют его ума, и переложить их на простенький, но при этом быстрый веб-сервер, и перекидывать апачу только ту работу, которую простой веб-сервер сам сделать не может. Кроме того, вот мы перекинули апачу запрос, он родил ответ, а потом его надо мучительно проталкивать клиенту по медленному интернету. А вместо этого можно быстро протолкнуть его по локальной сети nginx'у, и пусть уже nginx мучается с проталкиванием ответа клиенту, а апач займется чем-то ище.
В общем, изначальная идея была в том, чтобы разгрузить апач.
Здравствуйте, Pzz, Вы писали:
Pzz>В общем, изначальная идея была в том, чтобы разгрузить апач.
Добавлю еще пару задач, решаемых reverse proxy.
1. Безопасность. На фронт-хосте, размещаемом обычно в DMZ, у нас нет БД, логинов-паролей и другой чувствительной информации (при грамотной реализации конечно). Если и ломанут — не так страшно, передеплоили с нуля и вперед.
2. Гибкость в масштабировании. Если у нас нагрузка в основном на статику, мы масштабируем фронт, оставляя один бэк (который масштабировать как правило более затратно). Если нагрузка на базу, вычисления или другие сервисы, то масштабируем бэк, а с трафиком вполне может и один фронт справляться.
Здравствуйте, Twirl, Вы писали:
T>Конкретно про nginx можно почитать интервью с его автором https://xakep.ru/2012/01/09/58122/
Прошло 7 лет.
Интересно, как их коммерческие дела? На чем зарабатывают?
Здравствуйте, Mihas, Вы писали:
M>Здравствуйте, Twirl, Вы писали:
T>>Конкретно про nginx можно почитать интервью с его автором https://xakep.ru/2012/01/09/58122/ M>Прошло 7 лет. M>Интересно, как их коммерческие дела? На чем зарабатывают?
Здравствуйте, Pzz, Вы писали:
Pzz>Вообще, во времена, когда появился nginx, основным веб-сервером был апач. Апач — очень умный веб-сервер, но и очень тормозной в то же время. Идея заключалась в том, чтобы освободить апач от всех обязанностей, которые не требуют его ума, и переложить их на простенький, но при этом быстрый веб-сервер, и перекидывать апачу только ту работу, которую простой веб-сервер сам сделать не может. Кроме того, вот мы перекинули апачу запрос, он родил ответ, а потом его надо мучительно проталкивать клиенту по медленному интернету. А вместо этого можно быстро протолкнуть его по локальной сети nginx'у, и пусть уже nginx мучается с проталкиванием ответа клиенту, а апач займется чем-то ище. Pzz>В общем, изначальная идея была в том, чтобы разгрузить апач.
1)А можно базовый и дурацкий вопрос с тз. работы сокетов во всем этом? Вот у нас сервер регистрирует(bind) сокет на 80 порту, вот у нас куча запросов
в этот сокет и мы либо создаем отдельный поток для обслуживания, либо что-то неблокирующее(не суть). Т.е. куча запросов на один сокет\порт,
а как они будут отдаваться? Все через этот единственный сокет или для каждого запроса будет свой отдельный сокет(но тогда ответ клиенту придет не с 80 порта)?
2)Еще вопрос, отчасти связанный с 1. Вот у меня rp, вот у меня 80 порт и пара серверов(бд\веб) в бэке, т.е. всего получается мне нужно не более 3-х сокетов?
Здравствуйте, Sharov, Вы писали:
S>а как они будут отдаваться? Все через этот единственный сокет или для каждого запроса будет свой отдельный сокет(но тогда ответ клиенту придет не с 80 порта)?
Для каждого входящего соединения будет отдельный сокет. Начиная с HTTP/1.1, соединение не обязательно закрывать после каждого запроса (по взаимному согласию клиента и сервера), так что одно соединение может обслижить много запросов.
TCP-соединения идентифицируются не только локальным портом, а набором из 4-х параметров: {local-addr, local-port, remote-addr, remote-port}, так что local-port у них всех будет 80, это ничему не противоречит.
S>2)Еще вопрос, отчасти связанный с 1. Вот у меня rp, вот у меня 80 порт и пара серверов(бд\веб) в бэке, т.е. всего получается мне нужно не более 3-х сокетов?
Нет, тебе нужно много сокетов для обслуживания большого количества входящих соединений. Кроме того, прокся может решить использовать (и почти наверняка решит) по несколько соединений на каждый бакенд, чтобы пока обслуживается один долгий запрос, можно было посылать следущие.
Здравствуйте, Pzz, Вы писали:
Pzz>Для каждого входящего соединения будет отдельный сокет. Начиная с HTTP/1.1, соединение не обязательно закрывать после каждого запроса (по взаимному согласию клиента и сервера), так что одно соединение может обслижить много запросов. Pzz>TCP-соединения идентифицируются не только локальным портом, а набором из 4-х параметров: {local-addr, local-port, remote-addr, remote-port}, так что local-port у них всех будет 80, это ничему не противоречит.
А какой порт будет в ответе клиенту 80 или произвольный? Клиент же отправил запрос на 80 порт и он соотв. должен быть в ответе для tcp протокола.
Т.е. запрос от клиент всегда приходит по 80 порту, а ответ по произвольному?
Здравствуйте, Sharov, Вы писали:
Pzz>>Клиентский порт будет такой, какой выбрал себе клиент. Серверный порт будет 80.
S>Про клиента понятно, но как с сервера придет 80, если фактически сокет будет создан для данного клиента(соединения) на другом порту?
Он не будет создан на другом порту. TCP сокет идентифицируется четверкой параметров: {local-addr, local-port, remote-addr, remote-port}. Для всех входящих соединений на 80-м порту сервера, с точки зрения сервера local-port будет равен 80, а вот сочетание remote-addr+remote-port для них будет разное, по ним серверная машина эти соединения и будет различать.
Здравствуйте, Sharov, Вы писали:
S>Является ли верным данный генезис, т.е. сначал это было прокси для мн-ва клиентских запросов, а далее логичное развитие в lb и т.д.?
Да. Я лично застал этот процесс. Сначала была статика, потом CGI, потом прокси, потом прокси с маршрутами/правилами. И только после этого обозначились lb, fault tolerance и прочие вещи.
A>Да. Я лично застал этот процесс. Сначала была статика, потом CGI, потом прокси, потом прокси с маршрутами/правилами. И только после этого обозначились lb, fault tolerance и прочие вещи.
Я тут под прокси имел в виду необходимость поддерживать соединение с клиентом, когда его запрос на бэке выполняется + делать это для большого
кол-ва клиентов одновременно. Не уверен, что это прям каноническое прокси.
Здравствуйте, Sharov, Вы писали:
S>Я тут под прокси имел в виду необходимость поддерживать соединение с клиентом, когда его запрос на бэке выполняется + делать это для большого S>кол-ва клиентов одновременно. Не уверен, что это прям каноническое прокси.
Прям каноничнее некуда. Ровно все прокси ровно всегда делали ровно всё то же самое — эта возможность запроектирована на уровне самого протокола.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>>Я тут под прокси имел в виду необходимость поддерживать соединение с клиентом, когда его запрос на бэке выполняется + делать это для большого S>>кол-ва клиентов одновременно. Не уверен, что это прям каноническое прокси. S>Прям каноничнее некуда. Ровно все прокси ровно всегда делали ровно всё то же самое — эта возможность запроектирована на уровне самого протокола.
Здравствуйте, Sharov, Вы писали:
S>Какого протокола, http?
Да. В HTTP/1.1 есть хидер HOST, который позволяет серверу понять, к какому ресурсу "на самом деле" идёт обращение. Это первый необходимый шаг для того, чтобы проксирование работало.
Дальше: в спецификации большое внимание уделено тому, какой контент и когда можно кэшировать — как на уровне умолчаний, так и на уровне управления при помощи заголовков.
Дополнительно встроена возможность выполнять conditional get, для упрощения "обновления" кэша даже в тех случаях, когда невозможно статически принять решение о том, что сохранённая копия данных всё ещё приемлема.
Поэтому самый-самый простой прокси собственно ничем, кроме форвардинга запросов, и не занимается. Меньше этого прокси быть не может
Даже это может принести пользу. Например, решая проблему медленного клиента — т.е. служит тупо буфером, выравнивающим скорости доставки между модемом клиента и 10G Ethernet у веб-сервера.
Ну, или в самом простом случае прокси выступает как простая и надёжная защита основного веб-сервера от взлома.
Чуть более сложный прокси оборудован собственным кэшем; получив ответ от upstream сервера он не только отдаёт его клиенту, но и сохраняет в этот кэш, в соответствии с обнаруженными хидерами.
При последующих обращениях, прокси сначала проверяет свой локальный кэш, и если там нашлись подходящие данные, то отдаёт их сам, не дёргая upstream.
Ещё более хороший прокси умеет самостоятельно отдавать статику без какого-либо "прогрева кэша", что позволяет получить хорошую скорость сразу после старта, а не через сутки работы.
Ну, а дальше — нет предела совершенству.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Sharov, Вы писали:
S>>Какого протокола, http? S>Да. В HTTP/1.1 есть хидер HOST, который позволяет серверу понять, к какому ресурсу "на самом деле" идёт обращение. Это первый необходимый шаг для того, чтобы проксирование работало.
Я правильно понимаю, что когда я вбиваю www.test.com, мой запрос попадает сначала прокси? Т.е. www.test.com:80 это реально адрес прокси, который получает от меня запрос,
устанавливает со мной соединение, а уже от себя обращается к реальному серверу, например 192.168.1.123, который html и отдает.
S>Ещё более хороший прокси умеет самостоятельно отдавать статику без какого-либо "прогрева кэша", что позволяет получить хорошую скорость сразу после старта, а не через сутки работы.
Если я новостной сайт, о каком прогреве идет речь? Загнал все сегодняшние статьи в кэш и все. Что нужно сутки кэшировать? Что за данные, какая предметная область?
