|
|
Актуальность опции TCP_NODELAY для распределённых приложений (доп. ссылка 1) |
[комментарии]
|
| Один из инженеров Amazon Web Services (AWS) разобрал заблуждения, связанные
с повышением эффективности передачи мелких сообщений при использовании
алгоритма Нейгла, применяемого по умолчанию в TCP/IP стеке.
Рекомендации сводятся к отключению по умолчанию алгоритма Нейгла через
выставление опции TCP_NODELAY для сетевых сокетов при помощи вызова setsockopt.
setsockopt(descriptor, SOL_TCP, TCP_NODELAY, &one, sizeof(one));
Алгоритм Нейгла позволяет агрегировать мелкие сообщения для снижения трафика -
приостанавливает отправку новых сегментов TCP до получения подтверждения о
приёме ранее отправленных данных. Например, без применения агрегирования при
отправке 1 байта, дополнительно отправляется 40 байтов с заголовками пакета. В
современных условиях использование алгоритма Нейгла приводит к заметному
возрастанию задержек, неприемлемых для интерактивных и распределённых приложений.
Приводится три основных довода в пользу использования по умолчанию опции
TCP_NODELAY, отключающей алгоритм Нейгла:
1. Несовместимость алгоритма Нейгла с оптимизацией "delayed ACK", при которой
ACK-ответ направляется не сразу, а после получения ответных данных. Проблема в
том, что в алгоритме Нейгла поступление ACK-пакета является сигналом для
отправки агрегированных данных, а если ACK-пакет не поступил, отправка
выполняется при наступлении таймаута. Таким образом, возникает замкнутый круг и
ACK-пакет как сигнал не работает, так как другая сторона не получает данные
из-за их накопления на стороне отправителя, а отправитель не отправляет их до
таймаута, так как не получает ACK-пакет.
2. RFC для алгоритма Нейгла принят в 1984 году и он не рассчитан на параметры
современных высокоскоростных сетей и серверов в датацентрах, что приводит к
возникновению проблем с отзывчивостью. Задержка между отправкой запроса и
получением ответа (RTT) в современных сетях составляет 0.5 мс + несколько
миллисекунд при обмене данными между датацентрами в одном регионе + до сотни
миллисекунд при отправке по всему миру. За эти миллисекунды современный сервер
способен выполнить огромный объём работы.
3. Современные распределённые приложения давно не отправляют единичные байты
данных, а агрегирование мелких данных обычно реализуется на уровне приложения.
Даже если размер полезных данных составляет 1 байт, то, как правило, фактически
размер отправляемой информации существенно возрастает после применения
сериализации, использования API-обвязок в JSON и отправки с использованием
TLS-шифрования. Экономия 40 байтов становится не столь актуальной.
|
|
|
|
|
Диапазоны IP-адресов облачных сервисов Amazon, Google, OVH, DigitalOcean и Microsoft (доп. ссылка 1) |
[комментарии]
|
| Иногда на сервере возникает необходимость динамического определения подключения пользователя, транзитно использующего окружение в одном из арендуемых облачных сервисов.
... [Слишком большой объем текста. Скрыт. Для просмотра см. продолжение]
|
|
|
|
|
Домашний шлюз на Raspberry Pi |
Автор: Павел Самсонов
[комментарии]
|
| Нам понадобится: Raspberry Pi (у меня Raspberry Pi 1 модель B), вторая сетевая карта с интерфейсом USB (например, DLink DUB-E100) и
SD карта с записанным образом Raspbian.
... [Слишком большой объем текста. Скрыт. Для просмотра см. продолжение]
|
|
|
|
|
Использование нескольких сетевых стеков в Linux |
Автор: Roman Timofeev ( ^rage^ )
[комментарии]
|
| В linux относительно давно появилась такая замечательная вещь, как неймспейсы (namespaces). Основное применение данной технологии - контейнерная виртуализация, но и на маршрутизаторе можно придумать много разных применений, так как среди неймспейсов есть "network namespaces".
... [Слишком большой объем текста. Скрыт. Для просмотра см. продолжение]
|
|
|
|
|
Multicast во FreeBSD без igmpproxy (доп. ссылка 1) (доп. ссылка 2) |
Автор: nuclight
[комментарии]
|
| Иван Рожук опубликовал скрипт [[http://www.netlab.linkpc.net/download/software/FreeBSD/mcastbridge/mcastbr2.sh mcastbr2.sh]] для проброса multicast через шлюз на базе FreeBSD штатными средствами netgraph, без использования неработающих у многих igmpproxy и mrouted.
... [Слишком большой объем текста. Скрыт. Для просмотра см. продолжение]
|
|
|
|
|
Запись и повторное проигрывание трафика |
[комментарии]
|
| Для симулирования трафика, перехваченного сниффером и сохранённого в формате pcap, удобно использовать сочетание утилит tcpreplay (http://tcpreplay.synfin.net/) для непосредственной переотправки трафика и tcprewrite (http://tcpreplay.synfin.net/wiki/tcprewrite) для замены IP-адресов и других параметров пакетов. Повторная генерация потока может быть полезна для оценки поведения различных программ на различные атаки, при изучении причин сбоев в сетевом ПО или при проведении нагрузочного тестирования (можно менять интенсивность отправки пакетов).
... [Слишком большой объем текста. Скрыт. Для просмотра см. продолжение]
|
|
|
|
|
Передача статических маршрутов в DHCP (доп. ссылка 1) |
[комментарии]
|
| В основную секцию файла конфигурации DHCP сервера нужно прописать:
... [Слишком большой объем текста. Скрыт. Для просмотра см. продолжение]
|
|
|
|
|
Настройка IPv6 в Ubuntu Linux (доп. ссылка 1) |
Автор: pridumal.org.ua
[комментарии]
|
| Имеем Ubuntu 8.10 Intrepid Ibex Server Edition, выходящий в сеть по PPP и работающий с интранет IP через NAT.
... [Слишком большой объем текста. Скрыт. Для просмотра см. продолжение]
|
|
|
|
|
Настройка IPv6 в Debian GNU/Linux (доп. ссылка 1) |
[комментарии]
|
| IPv6 соединение будем туннелировать через брокер туннелей (Tunnel Broker),
так как не все ISP поддерживают прямое IPv6 соединение.
... [Слишком большой объем текста. Скрыт. Для просмотра см. продолжение]
|
|
|
|
|
Подключение FreeBSD к IPv6 - поднимаем туннель через IPv4-сети провайдера (доп. ссылка 1) |
Автор: Litos
[комментарии]
|
| Итак, пришло время поднять IPv4-IPv6 gateway, чтобы ходить в мир "другого интернета", коим он скоро будет.
... [Слишком большой объем текста. Скрыт. Для просмотра см. продолжение]
|
|
|
|
|
Пример настройки ng_neflow для нескольких интерфейсов. |
Автор: stalex
[комментарии]
|
| #cat ng5_netflow.sh
... [Слишком большой объем текста. Скрыт. Для просмотра см. продолжение]
|
|
|
|
|
Прозрачный редирект порта, используя xinetd и netcat (доп. ссылка 1) |
[комментарии]
|
|
После переноса сервиса на новый сервер, на старом можно организовать сервис заглушку,
осуществляющий редирект следующим образом:
/etc/xinetd.d/smtp-tcp
service smtp
{
disable = no
socket_type = stream
protocol = tcp
user = nobody
wait = no
server = /bin/nc
# server = /usr/bin/netcat
server_args = -w 2 192.168.1.1 25
}
где 192.168.1.1 адрес нового сервера, nc - утилита netcat, "-w 2" - таймаут в 2 сек.
|
|
|
|
|
Изменение имени сетевого интерфейса в Linux |
Автор: NuclearCat
[комментарии]
|
| /sbin/ifconfig ppp1 down
/sbin/ip link set ppp1 name my_ppp
/sbin/ifconfig my_ppp up
|
|
|
|
|
Статические маршруты через isc-dhcpd |
Автор: Артем Бохан
[комментарии]
|
| Согласно RFC 3442 через dhcp можно отдавать таблицу маршрутизации.
Изначально эта опция не поддерживается isc-dhcpd, но опцию можно добавить.
... [Слишком большой объем текста. Скрыт. Для просмотра см. продолжение]
|
|
|
|
|
Настройка беспроводной 80211 карты под FreeBSD (доп. ссылка 1) |
Автор: toxa
[комментарии]
|
| kldload bridge
sysctl net.link.ether.bridge.enable="1"
sysctl net.link.ether.bridge.config="wi0,fxp0"
sysctl net.inet.ip.forwarding="1"
ifconfig wi0 ssid toxawlan channel 11 media DS/11Mbps mediaopt hostap up stationname "toxawlan"
|
|
|
|
|
|
tcpdump для просмотра содержимого пакетов по определенным портам. (доп. ссылка 1) |
[комментарии]
|
| tcpdump -X -s 1500 -n -i fxp0 (tcp port 443) or (tcp port 994)
Если нужно выбрать трафик в котором не фигурируют IP 1.2.3.190 и
192.168.20.254, а также внутренние
пересылки между адресами 192.168.20 сети, можно использовать правило фильтрации:
not host 1.2.3.190 and not host 192.168.20.254 and not (dst net 192.168.20.0/24 and src net 192.168.20.0/24)
|
|
|
|
|
Как в FreeBSD добавить/убрать алиас для сетевого интерфейса |
[комментарии]
|
| Добавить: ifconfig fxp0 inet 192.168.1.1 netmask 255.255.255.255 alias
Убрать: ifconfig fxp0 inet 192.168.1.1 netmask 255.255.255.255 -alias
|
|
|
|
|
Табличка с сетевыми масками. (доп. ссылка 1) |
[комментарии]
|
| адресов в подсети, 255.255.255.x маска, /x маска, .0 - cisco acl маска.
0 .255 /32 .0
2 .254 /31 .1
4 .252 /30 .3
8 .248 /29 .7
16 .240 /28 .15
32 .224 /27 .31
64 .192 /26 .63
128 .128 /25 .127
256 .0 /24 .255
|
|
|
|