Все пытаюсь понять основное назначение сервисов\программ типа 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>Ещё более хороший прокси умеет самостоятельно отдавать статику без какого-либо "прогрева кэша", что позволяет получить хорошую скорость сразу после старта, а не через сутки работы.
Если я новостной сайт, о каком прогреве идет речь? Загнал все сегодняшние статьи в кэш и все. Что нужно сутки кэшировать? Что за данные, какая предметная область?
Здравствуйте, Sharov, Вы писали:
S> Я правильно понимаю, что когда я вбиваю www.test.com, мой запрос попадает сначала прокси? Т.е. www.test.com:80 это реально адрес прокси, который получает от меня запрос,
Да, конкретно www.test.com:80 твой запрос сегодня примет nginx/1.16.1
S> устанавливает со мной соединение, а уже от себя обращается к реальному серверу, например 192.168.1.123, который html и отдает.
Да.
S> Если я новостной сайт, о каком прогреве идет речь? Загнал все сегодняшние статьи в кэш и все. Что нужно сутки кэшировать? Что за данные, какая предметная область?
Новости читают не только за сегодня, но и за вчера и недельной давности. Например, 11 сентября 2020 года может быть повышенный спрос на новости 2001 года.
S>> Если я новостной сайт, о каком прогреве идет речь? Загнал все сегодняшние статьи в кэш и все. Что нужно сутки кэшировать? Что за данные, какая предметная область? AB>Новости читают не только за сегодня, но и за вчера и недельной давности. Например, 11 сентября 2020 года может быть повышенный спрос на новости 2001 года.
Так что там сутки прогревать, можно и за месяц, они(заметки) небольшие + ssd? Что за данные, для которых нужны сутки? Это уже какие-то гигантские порталы, все обо всем...
Здравствуйте, Sharov, Вы писали:
S> Так что там сутки прогревать, можно и за месяц, они(заметки) небольшие + ssd? Что за данные, для которых нужны сутки? Это уже какие-то гигантские порталы, все обо всем...
Сами тексты новостей действительно небольшие, но в кэшах лежат обычно не они, а готовые куски верстки, отресайзеные оптимизированные изображения и т.д. Чтобы система не стоила космических денег под каждую задачу выбирается главный ресурс и жертвуется остальными. Например, медиа файлы обычно хранят на больших но медленных хранилищах. Медиа-прокси же должны иметь хорошую сеть, но один такой прокси-сервер не в состоянии закэшировать весь медиа-танк и холодный старт приводит к тому, что кэш будет прогреваться (до полного заполнения выделенного ресурса RAM/HDD) длительное время на "длинном хвосте" менее частых (но более разнообразных) запросов.
При чем не обязательно должен быть гигантский портал. Типичная контент-помойка типа пикабу или яплакал легко за месяц нагенерирует сотню-другую GB данных.
Здравствуйте, Sharov, Вы писали: S>Я правильно понимаю, что когда я вбиваю www.test.com, мой запрос попадает сначала прокси? Т.е. www.test.com:80 это реально адрес прокси, который получает от меня запрос, S>устанавливает со мной соединение, а уже от себя обращается к реальному серверу, например 192.168.1.123, который html и отдает.
Ну, для начала надо посмотреть в настройки браузера. В них может быть прописан статический прокси или скрипт для динамического выбора прокси.
Например, 192.0.0.1:8080.
Клиент идёт по этому адресу и указывает Host: www.test.com.
Далее, вот уже этот прокси, как правило, идёт по "официальному" пути — резолвит www.test.com через DNS, и получает IP адрес.
Уже в этот момент всё может стать интересно, т.к. DNS может мапиться на геораспределённые сервера CDN, т.е. пользователь из РФ получит другой IP адрес, чем пользователь из США.
Теперь мы подключаемся к найденному IP адресу по порту 80, и опять отдаём ему хидер Host: www.test.com.
По этому адресу запросто может стоять nginx, который смотрит на Host и URL запроса, и принимает решение:
— отдать статику из локального файла (а делает он это очень хорошо)
— отдать данные из кэша
— связаться с апстрим-сервером, например backend.hosting.local, который может вообще не торчать наружу в интернет. S>>Ещё более хороший прокси умеет самостоятельно отдавать статику без какого-либо "прогрева кэша", что позволяет получить хорошую скорость сразу после старта, а не через сутки работы. S>Если я новостной сайт, о каком прогреве идет речь? Загнал все сегодняшние статьи в кэш и все. Что нужно сутки кэшировать? Что за данные, какая предметная область?
Как вы себе представляете процесс "загона сегодняшних статей в кэш"?
Обычный, прямолинейный прокси стартует с пустым кэшем. Вот пришёл входящий запрос — поехали в апстрим (а это дорого и долго!), получили ответ, сохранили в кэш, отдали клиенту.
Получили другой запрос, получили ответ, сохранили в кэш, отдали клиенту.
С точки зрения основного сервера, пустой прокси неотличим от обычного клиента — он всё видит в первый раз.
Статика — это такие ресурсы, у которых стоит Expiration:Never. Единожды попав в кэш прокси, они остаются там навсегда (ну, более-менее навсегда, до вытеснения).
Поэтому более эффективный способ — заранее скопировать их на прокси сервер, т.к. Bulk copy через низкоуровневые протоколы файлового трансфера эффективнее, чем тянуть их же по кусочкам через http.
Но для такого прокси сервер должен понимать, что /styles/main.css должен мапиться в папку на локальном диске; а /content/today.html нужно тащить с апстрима.
То есть появляется описание конфигурации прокси, правила роутинга, вопросы перезапуска при смене правил, и т.п.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>1)А можно базовый и дурацкий вопрос с тз. работы сокетов во всем этом? Вот у нас сервер регистрирует(bind) сокет на 80 порту, вот у нас куча запросов S>в этот сокет и мы либо создаем отдельный поток для обслуживания, либо что-то неблокирующее(не суть). Т.е. куча запросов на один сокет\порт, S>а как они будут отдаваться? Все через этот единственный сокет или для каждого запроса будет свой отдельный сокет(но тогда ответ клиенту придет не с 80 порта)?
S>2)Еще вопрос, отчасти связанный с 1. Вот у меня rp, вот у меня 80 порт и пара серверов(бд\веб) в бэке, т.е. всего получается мне нужно не более 3-х сокетов?
Сокет идентифицируется адресом-портом клиента и адресом-портом сервера. При accept'е создается новый сокет, удаленная пара адрес-порт и локальная пара адрес-порт. Локальный порт будет 80ый. Для каждого клиента (соединения), таким образом, исходящий серверный порт будет таки 80ым, но сокеты будут разные.
А как обслуживать сокеты — по потоку на сокет, или на всех (на пул) асинхронных сокетов по потоку — это дело хозяйское
Здравствуйте, Sharov, Вы писали:
T>>>Конкретно про nginx можно почитать интервью с его автором https://xakep.ru/2012/01/09/58122/ M>>Прошло 7 лет. M>>Интересно, как их коммерческие дела? На чем зарабатывают?
S>За 600$ млн. продали nginx.
Это не ответ. До этого же зарабатывали как-то, и покупатель, видимо, хочет тоже зарабатывать. Вряд ли чисто для себя приобрёл
Здравствуйте, Marty, Вы писали:
M>Сокет идентифицируется адресом-портом клиента и адресом-портом сервера. При accept'е создается новый сокет, удаленная пара адрес-порт и локальная пара адрес-порт. Локальный порт будет 80ый. Для каждого клиента (соединения), таким образом, исходящий серверный порт будет таки 80ым, но сокеты будут разные. M>А как обслуживать сокеты — по потоку на сокет, или на всех (на пул) асинхронных сокетов по потоку — это дело хозяйское
Вдогонку вопрос: а как сокет льет данные в карту? Вот у меня ~60000 сокетов, которые отличаются только ip\port клиента. Под каждый сокет у меня есть буфер в памяти, так? Каждый буфер как-то отображается в память карты (DMA?), какая там механика после send?
Здравствуйте, Marty, Вы писали:
S>>За 600$ млн. продали nginx. M>Это не ответ. До этого же зарабатывали как-то, и покупатель, видимо, хочет тоже зарабатывать. Вряд ли чисто для себя приобрёл
Своя компания была, зарабатывали консалтингом, вестимо.
Здравствуйте, Sharov, Вы писали:
S>Вдогонку вопрос: а как сокет льет данные в карту? Вот у меня ~60000 сокетов, которые отличаются только ip\port клиента. Под каждый сокет у меня есть буфер в памяти, так? Каждый буфер как-то отображается в память карты (DMA?), какая там механика после send?
Как хочет, так и льет. Твои юзер-спейс буфера сокету пофигу, хоть один буф используй. Как только ты сделал send, то там уже твоими данными занимается реализация стека TCP/IP, а как она уже в сетевуху льет, это вообще третий вопрос
Здравствуйте, Marty, Вы писали:
M>Как хочет, так и льет. Твои юзер-спейс буфера сокету пофигу, хоть один буф используй. Как только ты сделал send, то там уже твоими данными занимается реализация стека TCP/IP, а как она уже в сетевуху льет, это вообще третий вопрос
Воот, самое интересное. И как стек льет, какие механизмы?
Здравствуйте, Sharov, Вы писали:
M>>Как хочет, так и льет. Твои юзер-спейс буфера сокету пофигу, хоть один буф используй. Как только ты сделал send, то там уже твоими данными занимается реализация стека TCP/IP, а как она уже в сетевуху льет, это вообще третий вопрос
S>Воот, самое интересное. И как стек льет, какие механизмы?
