Записки программиста

Сетевой протокол PostgreSQL можно считать стандартом. Многие новые СУБД реализуют именно его. Что не удивительно, ведь протокол открыт, имеет готовые клиенты для всех популярных языков программирования (см заметки о psycopg2, pgx, JDBC, …), а также всякие полезные штуки вроде PgBouncer. Давайте же разберемся, как этот протокол устроен.

Wiznet W5500 — это Ethernet-контроллер с интерфейсом SPI. Чип поддерживает стандарты 10baseT и 100baseT. Характерной особенностью контроллера является то, что он имеет аппаратную реализацию TCP/IPv4. Это позволяет существенно разгрузить работающий с ним микроконтроллер. Wiznet W5500 поддерживает до 8 сокетов и имеет суммарно 16 Кб памяти на прием и еще 16 Кб на передачу. Эта память может быть распределена между сокетами произвольным образом. Давайте же разберемся, как работать с этим чипом на примере МК STM32.

Беспроводные роутеры имеют несколько неприятных особенностей. Во-первых, они небезопасны, если только не разобраться с установкой OpenWrt. Во-вторых, со временем они перестают выпускаться, а значит, если ваш роутер сломается, вам придется разбираться с установкой OpenWrt на совершенно другой роутер. В-третьих, как правило, они довольно ограничены в ресурсах, а значит возложить на роутер какие-то дополнительные функции может быть проблематично. Между тем, абсолютно любой компьютер под управлением Linux может быть настроен в качестве полноценного Wi-Fi роутера, что решает проблемы безопасности, повторяемости и производительности. Для примера, рассмотрим создание беспроводного роутера на базе одноплатного компьютера Raspberry Pi.

Благодаря заметке Изучаем Ethernet-фреймы с помощью осциллографа теперь мы знаем, как физически осуществляется передача данных по Ethernet-кабелю. Однако описанный в посте подход не слишком удобен для полноценной отладки какого-то устройства, работающего с Ethernet. Есть несколько решений этой проблемы. Например, можно воспользоваться старым Ethernet-хабом (но нынче их не так-то просто найти) или настроить зеркалирование портов на Ethernet-свиче. Но в рамках этого поста мы рассмотрим альтернативное решение, которое заключается в использовании платы Throwing Star LAN Tap.

Практически в любой книге по компьютерным сетям вы без труда найдете описание Ethernet-пакетов, ровно как и пакетов IP, TCP, UDP и прочих. Но в тех источниках, что мне встречались, описание это было довольно высокоуровневым, в терминах байтов, которые как-то передаются по витой паре. Но как конкретно единички и нолики представляются при помощи напряжения или тока? Давайте выясним!

Иногда бывает нужно синтегрироваться со Slack, Gitter, или подобного рода веб-чатом. Например, посылать в него сообщение при происшествии определенного события. К сожалению, подобные сервисы имеют сильно разные и иногда не слишком удобные для этих целей API. Зато многие, включая тот же Slack и Gitter, позволяют ходить в них по IRC. Более того, с помощью программы bitlbee по IRC можно ходить еще и в Skype, Jabber, Twitter и многое другое. Грех этим не воспользоваться.

При отладке программ бывает удобно посмотреть, что они передают по сети. Для решения этой задачи существует множество программ-снифферов. Проблема в том, что они бывают не слишком удобны. Так, tcpdump всегда выводит IP- и TCP-заголовки пакетов, а мне они не всегда интересны. Этого недостатка лишен tcpflow, однако он не работает с UDP и имеет больно уж широкий вывод в консоль. Столкнувшись с этим в очередной раз, я решил написать маленький сниффер, который был бы удобен лично мне. Оказалось, что пишутся снифферы очень просто.

Когда-то давно мы настраивали фаервол в Linux с помощью iptables. При этом отмечалось, что утилиту iptables я нахожу исключительно неудобной по сравнению с FreeBSD’шным ipfw. Сегодня мы наконец-то познакомимся с этим ipfw и постараемся ответить на вопрос, действительно ли он удобнее. Отмечу, что на момент написания этих строк FreeBSD предлагает аж три фаервола на выбор — ipfw, pf и ipf. Однако по моим представлениям из них ipfw используется чаще всего.

Пришло время научиться работать с Linux Containers, более известными под названием LXC. Далее мы будем рассматривать LXC в контексте Debian и Ubuntu, но написанное во многом будет применимо и для других дистрибутивов Linux. Мы коснемся не только основ использования LXC, но и узнаем, как настроить bridged сеть, ограничить количество ресурсов, используемых контейнером, и даже осилим unprivileged containers.

Сейчас наблюдается большой ажиотаж в отношении технологий контейнерной виртуализации. И почему-то в этом контексте особенно часто упоминается Docker, словно это вообще единственное решение для создания контейнеров. А тем временем существует технология, которая не только ничем не уступает Docker, но и по некоторым оценкам опережает ее как минимум лет на пять. Технология эта называется OpenVZ. О причинах малой популярности OpenVZ мне остается только гадать. Однако, надеюсь, что данная статья хотя бы отчасти исправит положение дел.