Сложилась ситуация, что участвую в проекте, который работает с достаточно большой нагрузкой. Как уже написал — 36 млн запросов в час. Я много чего прочитал и перепробовал за последний месяц, настраивая сервер; хотелось бы просто сжато и компактно выдать тезисно то, что работает хорошо в такой конфигурации.

Первое, что я заметил — множество советов как все настроить под большую нагрузку. Читайте их внимательно, обычно в тексте найдете, что речь про «высокую нагрузку» в 15-20 тысяч клиентов в сутки. У нас клиентов примерно миллион, активных, ежедневных.

У нас нет денег и мы все делаем за свой счет, поэтому экономим. Итог — весь миллион клиентов обслуживается на одном сервере, вот на таком — EX-60 на hetzner.

В данной статье для виртуализации используется KVM/libvirt, но сразу отмечу, статья не столько о KVM, сколько именно об особенностях преимуществах использования Open vSwitch для объединения виртуальных и физических сетевых устройств посредством технологии VLAN (802.1q). В былинные времена для проброса тегированного трафика в гипервизор использовались всевозможные костыли и подпорки различной степени неожиданности (tuntap, brctl, vconfig, ebtables и прочее), что приводило к захламлению операционной системы, хостящей гипервизор, большим количеством ненужных виртуальных сетевых интерфейсов, мозолящих глаза в выводе ifconfig и вообще огорчало администраторов необходимостью строить стандартное сетевое устройство (коммутатор) из отдельных частей как какой-то велосипед. Помимо поддержки 802.1q от коммутатора на самом деле сегодня требуется еще много функций. Так необходимость в виртуальном устройстве максимально соответствующем по функционалу стандартному современному управляемому коммутатору привела к появлению проекта Open vSwitch (далее — OVS).

Рисунок 1: Проект песочницы

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

Инструменты, традиционно используемые для прослушивания трафика (tshark, о котором мы уже писали, а также ngrep и tcpdump) для этой цели подходят плохо: функциональность для работы с протоколом HTTP у них ограничена.

Для анализа HTTP-трафика существует более специализированное, простое и эффективное решение. Знакомьтесь: mitmproxy. На русском языке подробных публикаций о нем почти нет. В этой статье мы поделимся своим опытом работы с mitmproxy и надеемся, что и вам он окажется полезным.