 |
Как отключить TLS-расширение ECH для решения проблем с Cloudflare в РФ |
[комментарии]
|
| | Роскомнадзор начал блокировать в РФ соединения к сайтам, использующим TLS-расширение ECH (Encrypted Client Hello). Блокировка привела к массовым проблемам с сайтами, работающими через сеть доставки контента Cloudflare, которую используют примерно [[https://w3techs.com/technologies/details/cn-cloudflare 19% всех сайтов]] в интернете (по [[https://www.netcraft.com/blog/october-2024-web-server-survey/ другим данным]] 16% (31 млн) активных сайтов или 23.83% из миллиона самых популярных сайтов).
...
[Слишком большой объем текста. Скрыт. Для просмотра см. продолжение]
|
| |
 |
|
|
|
|
Актуальность опции 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 байтов становится не столь актуальной.
|
| |
|
|
|
Полезные пакеты, которые можно установить на сервер для диагностики сбоев (доп. ссылка 1) |
[комментарии]
|
| | Минимальный набор пакетов для диагностики проблем, которые рекомендуется заранее установить на серверы, чтобы не тратить время на установку дополнительных пакетов или поиск специализированных live-дистрибутивов.
...
[Слишком большой объем текста. Скрыт. Для просмотра см. продолжение]
|
| |
|
|
|
Обход блокировки сотовыми операторами использования смартфона в качестве точки доступа |
[комментарии]
|
| | Некоторые сотовые операторы начали вводить в практику блокировку или замедление
доступа для соединений, установленных со сторонних устройств, подключающихся
через смартфон, работающий в режиме точки доступа ("tethering").
Как правило подобные блокировки основываются на привязке к TTL и обойти их
можно увеличив TTL с 64 до 65, что скроет наличие дополнительного хоста в цепочке.
В системах на базе ядра Linux:
sysctl net.ipv4.ip_default_ttl=65
Во FreeBSD:
sysctl net.inet.ip.ttl=65
Изменить TTL для транзитных пакетов в Linux можно при помощи пакетного фильтра:
iptables -t mangle -A POSTROUTING -o usb0 -j TTL --ttl-set 65
|
| |
|
|
|
Решение проблемы с uTP-протоколом uTorrent (доп. ссылка 1) |
Автор: Zzz
[комментарии]
|
| | По многочисленным наблюдениям системных администраторов различных компаний предоставляющих доступ к сети интернет, с начала февраля 2010 года наблюдается ежедневный лавинообразный рост количества пакетов в сети, их фрагментация, а также существенный рост исходящего трафика. Данная проблема связана с новой версией торрент-клиента uTorrent вышедшего 3 февраля 2010 года с поддержкой протокола uTP, работающего поверх UDP. Призванный снизить нагрузку на провайдеров протокол uTP в результате привел к обратному эффекту.
...
[Слишком большой объем текста. Скрыт. Для просмотра см. продолжение]
|
| |
|
|
|
Tshark для мониторинга запросов http (доп. ссылка 1) |
Автор: CHAPPAY
[комментарии]
|
| | Tshark из комплекта сниффера Wireshark (http://www.wireshark.org/) позволяет наглядно проследить запросы к http-серверу.
...
[Слишком большой объем текста. Скрыт. Для просмотра см. продолжение]
|
| |
|
|
|
Решение проблемы с крахом Net-SNMP |
[обсудить]
|
| | В один прекрасный момент Net-SNMP начал слетать с оставлением в логе ошибки:
...
[Слишком большой объем текста. Скрыт. Для просмотра см. продолжение]
|
| |
|
|
|
|
|
Как увеличить размер таблицы контроля сессий ip_conntrack в Linux |
[комментарии]
|
| | Если ядро ругается "kernel: ip_conntrack: table full, dropping packet.", причину флуда
(скорее всего вирус или сканирование портов) можно найти по списку /proc/net/ip_conntrack
Если просто общая загрузка большая, увеличить размер таблицы можно через /proc/sys/net/ipv4/ip_conntrack_max
Также можно увеличить размерность хэша через параметр hashsize модуля ip_conntrack:
/etc/modules.conf:
options ip_conntrack hashsize=N
Более тонкий тюнинг можно произвести через переменные определенные в /proc/sys/net/ipv4/netfilter
|
| |
|
|
|
Примеры использования ngrep для выборки и просмотра содержимого пакетов (доп. ссылка 1) |
Автор: Mayank Sharma
[комментарии]
|
| | ngrep служит для отображения проходящих сетевых пакетов удовлетворяющих заданной маске.
Как мне кажется ngrep гораздо проще и удобнее, чем tcpdump. Вот несколько примеров:
Показать содержимое всех пакетов, прошедших по 80 порту, со словом google
ngrep google port 80
Вывод пакетов удовлетворяющих маске по одному в строке, для интерфейса eth0:
ngrep -i \'game*|chat|recipe\' -W byline -d eth0
Слушать весь SMTP трафик на всех сетевых интерфейсах:
ngrep -i \'rcpt to|mail from\' -d any tcp port smtp
Показать текущее время для каждого совпадения (кто и когда заходит на машину телнетом):
ngrep -q -t -wi "login" port 23
|
| |
|
|
|
Почему в FreeBSD 5.3 не работает форвадинг пакетов (ipfw fwd) (доп. ссылка 1) |
Автор: Bushi
[комментарии]
|
| | Это ошибка в FreeBSD 5.3, патч здесь:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/71910
|
| |
|
|
|
Как сгенерировать IPv6 пакет для отладки сети. (доп. ссылка 1) |
[обсудить]
|
| | # netwox 142 --device "Eth0" --eth-dst "0:8:9:a:b:c" --ip6-src "fec0:0:0:1::1"
--ip6-dst "fec0:0:0:1::2" --tcp-src "1234" --tcp-dst "80" --tcp-syn
# netwox 142 --device "Eth0" --eth-src "00:11:22:33:44:55" --eth-dst "0:8:9:a:b:c"
--ip6-src "fec0:0:0:1::1" --ip6-dst "fec0:0:0:1::2" --tcp-src "1235" --tcp-dst "80" --tcp-syn
142 - код операции "Spoof EthernetIp6Tcp", netwox - http://laurentconstantin.by.ru/ru/
|
| |
|
|
|
Почему при использовании туннеля возникают проблемы с некоторыми хостами. (доп. ссылка 1) |
[комментарии]
|
| | Выход - поставить на интерфейсе туннеля MTU 1500, вместо 1476.
Проблема возникает при попытке протолкнуть пакет размером 1500 байт
с выставленным DF (don't fragment запрещена фрагментация) битом через интерфейс 1476 байт.
Другие решения:
interface ethernet0
ip policy route-map clear-df
route-map clear-df permit 10
match ip address 101
set ip df 0
access-list 101 permit tcp 10.1.3.0 0.0.0.255 any
или
interface tunnel0
ip tcp adjust-mss 1436
|
| |
|
|
|
В чем может быть причина неработы ассиметричного рутинга под Linux. (доп. ссылка 1) |
[обсудить]
|
| | Linux отказывается маршрутизировать пакеты между двумя сетевыми
картами, кода пакет входит через один интерфейс и выходит через другой, если
включен rp_filter (RFC1812).
Необходимо отключить rp_filter:
/sbin/sysctl -w net.ipv4.conf.default.rp_filter = 0
/sbin/sysctl -w net.ipv4.conf.all.rp_filter = 0
Для FreeBSD можно посоветовать:
в /etc/rc.conf: tcp_extensions="NO"
или sysctl -w net.inet.tcp.rfc1323=0
А так же sysctl -w net.inet.tcp.rfc1644=1 и sysctl -w net.inet.tcp.rfc1323=0
|
| |
|
|
|
С чем может быть связаны потери пакетов и нестабильная работа ethernet карт ? (доп. ссылка 1) |
[комментарии]
|
| | Приходилось сталкиваться с проблемами согласования режимов работы карт Intel EtherExpress 100 и
Reltek RTL-8139 c коммутаторами и концентраторами различных производителей. Несогласование
проявляется, например в работе карты в режиме half-duplex, а свича в
full-duplex и т.д. (в linux: /sbin/mii-tool -F 100baseTx-FD eth0)
|
| |
|
|
|
Почему выкачиваются данные с машины нормально, как только пытаюсь что-то закачать - соединение останавливается, даже через ssh больше 5 мин. не удается поработать. Другие машины работают нормально. |
[комментарии]
|
| | Неоднократно замечена проблема работы сетевых карт на базе RealTek 8129/8139 (машины под FreeBSD,
но с другими ОС тоже проявляется) с некоторыми концентраторами и коммутаторами.
Проявляется в замирании сессий до истечения таймаута.
Диагностика: ping -s N remote_ip, при больших N не проходят.
Решение: Смените сетевую карту, например, на Intel EtherExpress Pro.
|
| |
|
|
|
Почему лог почтового сервера изобилует сообщениями о разрыве по Timeout, часто, при приеме большого объема данных, прокачка останавливается и замирает до истечения таймаута ? |
[комментарии]
|
| | Вероятные причины: Туннель, блокировка ICMP, "path MTU discovery" и ECN
(Explicit Congestion Notification,
ECN проявляется в основном при доступе через Proxy).
При блокировке ICMP трафика, возможно блокируется не только
echo_replay/echo_request ICMP сообщения,
но и другие важные сообщения
передаваемые по ICMP. При блокировке ICMP сообщений типа 3.4 (fragmentation
needed and DF set) возможно
нарушение нормальной фрагментации пакетов, что вполне может проявляться как
внезапная остановка передачи
данных большого объема и разрыв сесcии по таймауту, например, если на пути
трафика встречается туннель.
Одним из путей решением проблемы, является установка на туннеле MTU > 1500 и
отмена блокировки ICMP трафика.
Проблемы с ECN в Linux лечатся:
echo 0 >/proc/sys/net/ipv4/tcp_ecn
path MTU discovery:
Linux: echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc
FreeBSD: sysctl -w net.inet.tcp.rfc1323=0
|
| |
|
|
