Подходит ли платформа для начинающих без опыта работы?

Да, курсы разбиты по уровням: Junior, Middle, Senior. Начинающие могут стартовать с базовых тем Python, Docker и алгоритмов и постепенно двигаться к более сложным темам.

Как быстро можно подготовиться к собеседованию на позицию Junior разработчика?

При занятиях 1–2 часа в день — от 2 до 4 недель на основные темы. Платформа анализирует слабые места по результатам квизов и строит персональный план подготовки.

Какие технологии охватывает платформа?

Python, FastAPI, Django, Docker, алгоритмы и структуры данных, Agile/Scrum, SQL, CI/CD, системный дизайн, код-ревью и более 50 других тем для разработчиков.

Платформа бесплатная?

Большинство учебных материалов и квизов доступны бесплатно после регистрации. Регистрация занимает менее минуты.

Как платформа помогает найти работу программистом?

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

tcp_l4_balancing

TCP mode и L4 балансировка

Балансировка баз данных, кастомные протоколы, pure TCP

TCP mode и L4 балансировка

Балансировка на транспортном уровне для баз данных, кастомных протоколов, pure TCP трафика.

Отличия TCP mode от HTTP mode

Характеристика	HTTP Mode (L7)	TCP Mode (L4)
Анализ протокола	HTTP заголовки, path	Сырой TCP поток
Маршрутизация	По URL, headers, cookies	По IP, порту
Модификация	Заголовки, URL	Недоступна
Health checks	HTTP GET/POST	TCP connect
Производительность	Выше overhead	Минимальный overhead
Use cases	Веб-серверы, API	БД, Redis, кастомные протоколы

Базовая конфигурация TCP mode

defaults
    mode tcp
    timeout connect 5s
    timeout client 30m
    timeout server 30m

frontend mysql_front
    bind *:3306
    default_backend mysql_servers

backend mysql_servers
    balance leastconn
    server db1 192.168.1.10:3306 check
    server db2 192.168.1.11:3306 check

Особенности:

mode tcp — отключает HTTP анализ
Длинные таймауты для persistent соединений
balance leastconn — для равномерной нагрузки

Балансировка MySQL

Базовая конфигурация

backend mysql_servers
    mode tcp
    balance leastconn
    
    option mysql-check user haproxy
    server db1 192.168.1.10:3306 check port 3306
    server db2 192.168.1.11:3306 check port 3306

MySQL health check:

option mysql-check — использует MySQL protocol
user haproxy — пользователь для проверки

Создание пользователя для health checks

CREATE USER 'haproxy'@'%' IDENTIFIED BY 'healthcheck';
GRANT USAGE ON *.* TO 'haproxy'@'%';
FLUSH PRIVILEGES;

Проверка:

mysql -h db1 -u haproxy -phealthcheck -e "SELECT 1"

Read/Write разделение

# Write (master)
frontend mysql_write
    bind *:3307
    default_backend mysql_master

backend mysql_master
    mode tcp
    balance leastconn
    option mysql-check user haproxy
    server master 192.168.1.10:3306 check

# Read (replicas)
frontend mysql_read
    bind *:3308
    default_backend mysql_replicas

backend mysql_replicas
    mode tcp
    balance leastconn
    option mysql-check user haproxy
    server replica1 192.168.1.11:3306 check
    server replica2 192.168.1.12:3306 check

Приложение:

# Write
write_conn = mysql.connect(host='haproxy', port=3307)

# Read
read_conn = mysql.connect(host='haproxy', port=3308)

Балансировка PostgreSQL

Базовая конфигурация

backend pg_servers
    mode tcp
    balance leastconn
    
    option pgsql-check user haproxy
    server db1 192.168.1.10:5432 check
    server db2 192.168.1.11:5432 check

Создание пользователя:

CREATE USER haproxy WITH PASSWORD 'healthcheck';

PgBouncer за HAProxy

backend pgbouncer_servers
    mode tcp
    balance leastconn
    
    # PgBouncer не поддерживает health checks, используем TCP check
    server pgb1 192.168.1.10:6432 check
    server pgb2 192.168.1.11:6432 check

Балансировка Redis

Базовая конфигурация

backend redis_servers
    mode tcp
    balance leastconn
    
    option tcp-check
    tcp-check send PING\r\n
    tcp-check expect string +PONG
    server redis1 192.168.1.10:6379 check
    server redis2 192.168.1.11:6379 check

TCP health check:

tcp-check send PING\r\n — отправляет PING
tcp-check expect string +PONG — ожидает PONG

Redis Sentinel

backend redis_master
    mode tcp
    balance leastconn
    
    # Проверка что сервер master
    option tcp-check
    tcp-check send INFO\ replication\r\n
    tcp-check expect string role:master
    server redis1 192.168.1.10:6379 check
    server redis2 192.168.1.11:6379 check

Балансировка MongoDB

Базовая конфигурация

backend mongo_servers
    mode tcp
    balance leastconn
    
    option tcp-check
    tcp-check send-binary \x43\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\xd4\x07\x00\x00\x00\x00admin\x2e\x24\x63\x6d\x64\x00\x00\x00\x00\x00\xff\xff\xff\xff\x19\x00\x00\x00\x01\x69\x73\x4d\x61\x73\x74\x65\x72\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
    tcp-check expect binary \x01\x00\x00\x00
    server mongo1 192.168.1.10:27017 check
    server mongo2 192.168.1.11:27017 check

Примечание: Для MongoDB лучше использовать native replica set routing.

Балансировка gRPC

gRPC over HTTP/2

frontend grpc_front
    bind *:50051
    mode tcp
    default_backend grpc_servers

backend grpc_servers
    mode tcp
    balance roundrobin
    
    # gRPC health checking protocol
    option tcp-check
    tcp-check send-binary \x00\x00\x00\x00\x12\x10\x2f\x67\x72\x70\x63\x2e\x68\x65\x61\x6c\x74\x68\x2e\x48\x65\x61\x6c\x74\x68\x2f\x43\x68\x65\x63\x6b\x00\x00\x00\x00\x00
    tcp-check expect binary \x00\x00\x00\x00
    
    server grpc1 192.168.1.10:50051 check
    server grpc2 192.168.1.11:50051 check

Балансировка SMTP

Базовая конфигурация

frontend smtp_front
    bind *:25
    mode tcp
    default_backend smtp_servers

backend smtp_servers
    balance roundrobin
    
    option smtp-check
    server smtp1 192.168.1.10:25 check
    server smtp2 192.168.1.11:25 check

SMTPS (порт 465)

frontend smtps_front
    bind *:465
    mode tcp
    default_backend smtps_servers

backend smtps_servers
    balance roundrobin
    server smtps1 192.168.1.10:465 check ssl verify none
    server smtps2 192.168.1.11:465 check ssl verify none

Балансировка SSH

frontend ssh_front
    bind *:22
    mode tcp
    default_backend ssh_servers

backend ssh_servers
    balance leastconn
    server ssh1 192.168.1.10:22 check
    server ssh2 192.168.1.11:22 check

Использование:

Jump host для доступа к серверам
Audit SSH сессий
Rate limiting SSH подключений

TCP health checks

Basic TCP check

backend tcp_servers
    mode tcp
    server server1 192.168.1.10:8080 check

Поведение:

HAProxy пытается установить TCP соединение
Успех = соединение установлено
Неудача = connection refused/timeout

TCP check с отправкой данных

backend custom_servers
    mode tcp
    
    option tcp-check
    tcp-check send GET /health HTTP/1.0\r\n\r\n
    tcp-check expect string 200 OK
    
    server server1 192.168.1.10:8080 check

TCP check с бинарными данными

backend binary_servers
    mode tcp
    
    option tcp-check
    tcp-check send-binary \x00\x01\x02\x03
    tcp-check expect binary \x04\x05\x06\x07
    
    server server1 192.168.1.10:9000 check

Connection limits в TCP mode

Ограничение соединений

backend db_servers
    mode tcp
    balance leastconn
    
    # Лимит на сервер
    server db1 192.168.1.10:3306 check maxconn 100
    
    # Лимит на backend
    maxconn 500

Queue в TCP mode

backend db_servers
    mode tcp
    
    timeout queue 30s
    server db1 192.168.1.10:3306 check maxconn 100
    server db2 192.168.1.11:3306 check maxconn 100

Поведение:

Превышение maxconn — запросы в очередь
timeout queue — время ожидания в очереди

PROXY protocol в TCP mode

Отправка PROXY protocol

backend backend_servers
    mode tcp
    send-proxy-v2
    
    server server1 192.168.1.10:8080 check
    server server2 192.168.1.11:8080 check

Когда использовать:

Backend должен знать реальный IP клиента
Backend поддерживает PROXY protocol (Nginx, HAProxy)

Приём PROXY protocol

frontend tcp_front
    bind *:8080 accept-proxy
    mode tcp
    default_backend backend_servers

Full Example: Production Database

defaults
    mode tcp
    timeout connect 5s
    timeout client 30m
    timeout server 30m
    log global
    option tcplog

# MySQL Write
frontend mysql_write
    bind *:3307
    default_backend mysql_master

backend mysql_master
    balance leastconn
    option mysql-check user haproxy password healthcheck
    server master 192.168.1.10:3306 check inter 5s fall 3 rise 2

# MySQL Read
frontend mysql_read
    bind *:3308
    default_backend mysql_replicas

backend mysql_replicas
    balance leastconn
    option mysql-check user haproxy password healthcheck
    server replica1 192.168.1.11:3306 check inter 5s fall 3 rise 2
    server replica2 192.168.1.12:3306 check inter 5s fall 3 rise 2

# Redis
frontend redis_front
    bind *:6379
    default_backend redis_servers

backend redis_servers
    balance leastconn
    option tcp-check
    tcp-check send PING\r\n
    tcp-check expect string +PONG
    server redis1 192.168.1.20:6379 check inter 5s fall 3 rise 2
    server redis2 192.168.1.21:6379 check inter 5s fall 3 rise 2

# PostgreSQL
frontend pg_front
    bind *:5432
    default_backend pg_servers

backend pg_servers
    balance leastconn
    option pgsql-check user haproxy
    server pg1 192.168.1.30:5432 check inter 5s fall 3 rise 2
    server pg2 192.168.1.31:5432 check inter 5s fall 3 rise 2

Troubleshooting TCP mode

Проверка соединений

# Статус серверов
echo "show servers state" | socat /var/run/haproxy/admin.sock stdio

# Статистика по backend
echo "show stat" | socat /var/run/haproxy/admin.sock stdio

TCP dump

# Захват трафика
tcpdump -i any -s 0 -w haproxy-tcp.pcap port 3306

# Анализ в Wireshark
wireshark haproxy-tcp.pcap

Логи

# Логирование TCP соединений
option tcplog
log-format "%ci:%cp [%tr] %ft %b/%s %Tw/%Tc/%Tr/%Ta/%Tt %ST %B %actconn/%feconn/%beconn/%srv_conn/%retries"

Резюме

TCP mode для баз данных, Redis, кастомных протоколов
balance leastconn для длительных соединений
TCP health checks с option tcp-check
PROXY protocol для передачи IP клиента
Длинные таймауты для persistent соединений
Read/write разделение для MySQL

Что дальше

Изучим health checks глубокий: кастомные проверки, agent checks.

Проверьте свои знания

Вопросы ещё не добавлены

Вопросы для этой подтемы ещё не добавлены.

Характеристика

HTTP Mode (L7)

TCP Mode (L4)

Анализ протокола

HTTP заголовки, path

Сырой TCP поток

Маршрутизация

По URL, headers, cookies

По IP, порту

Модификация

Заголовки, URL

Недоступна

Health checks

HTTP GET/POST

TCP connect

Производительность

Выше overhead

Минимальный overhead

Use cases

Веб-серверы, API

БД, Redis, кастомные протоколы