HTTP-сервер, способный проксировать запросы

Question

По соображениям производительности мне пришлось переписать часть нашей веб-инфраструктуры.

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

Вы можете запустить его, как это слушать на порту 8080:

./webapp 8080 

Хотя это работает безупречно и гораздо быстрее, чем раньше, его ограничением является один-соединение-на-времени характер применения , Вы не можете одновременно обслуживать HTML-страницы, Javascript и изображения более чем одним соединением только с одним экземпляром приложения.

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

./webapp 10000 
./webapp 10001 
./webapp 10002 
./webapp 10003 
./webapp 10004 
./webapp 10005 
./webapp 10006 
./webapp 10007 
./webapp 10008 
./webapp 10009 

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

Обратный прокси также должен поддерживать SSL от клиента к себе. Поддержка SPDY была бы плюсом, но не обязательна.

Мой вопрос: Какие HTTP-обратные прокси-серверы могли бы работать в качестве интерфейса в моем сценарии? Если вы знаете более одного, что является плюсами и минусами каждого из них?

Answer 1

Какова ваша мотивация для подключения только одного сервера? Это звучит как ужасный выбор для веб-сервера. Каждый клиентский браузер, как правило, отправляет десятки запросов параллельно при появлении вашего сайта.

Если вы создадите процесс по TCP-соединению, вы получите плохие характеристики. На самом деле, что вы ищете здесь многопоточный сервер вместо инфраструктуры мульти-процессов (что является точкой, имеющих различные процессы?)

Тем не менее, есть несколько путей, которые вы можете пойти вниз:

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

• Вы остаетесь с одиночной резьбой webapp, но вы поддерживаете список сокетов, которые вы слушаете, и вы соединяете их со своим «приятелем», которым они направляют трафик (обратите внимание, что он работает в обоих направлениях) , Тем не менее, это не будет оптимальной производительностью, потому что вы можете быть привязаны к ядру.

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

Если бы я был вами, я обратился бы непосредственно к решению 3, потому что это просто лучший выбор. Это не так уж сложно, так как он близок к вашему однопоточному подходу (только пара сокетов), и он не имеет производительности для процессов forking по всему месту.

Я не думаю, что вы найдете веб-сервер, который соответствует вашим потребностям, потому что это не стандартный способ справиться с такими ситуациями, и я сомневаюсь, что кто-то нашел время, чтобы развить его :)

Edit:

Хорошо, я понимаю вашу проблему из вашего редактирования.

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

Если вы думаете об этом, вы действительно пытаетесь реализовать одну сторону прокси, а другая сторона - переадресация на ваш webapp. Поэтому вы должны использовать методы прокси ИМХО.

Answer 2

Похоже, что вам необязательно нужен обратный прокси-сервер, а скорее балансировщик нагрузки. Я установил HAProxy, чтобы каждый процесс webapp считался одним бэкэнд, а затем выполнял балансировку по кругу, чтобы каждое новое соединение переходило к следующему процессу в списке.

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

Answer 3

Nginx является хорошим вариантом

Плюсы:

• поддерживает завершение SSL
• Поддержка load balancing из коробки
• Upstream keepalive Connections
• поддерживает SPDY (без сервера толчок, хотя) , Последняя версия добавляет поддержку http2 с удаленным spdy.

Минусы:

• Вы должны жёстко вверх по течению серверов в конфигурации Nginx, как показано ниже. Нет простого способа прочитать настройки сервера восходящего потока через переменные среды, если вы обновляете их динамически.

  http { 
      upstream myapp1 { 
       server localhost:10000; 
       server localhost:10001; 
       server localhost:10002; 
      } 
      server { 
       listen 443 ssl spdy; 
  
       location/{ 
        proxy_pass http://myapp1; 
       } 
      } 
  }