Или типа на "почему этот метод в АПИ высылает Х а не У?" отвечает что-нибудь типа "потому что в базе находится Х.". Твою-то налево, понятно что я спрашиваю, с чего оно в базе лежит вместо У.
Да вот как раз-таки ни фига непонятно. Бесят люди, которые задают вопрос про X, получают ответ, а потом недовольны, что ты ответил именно на то, что они спросили. А ты должен был догадаться, что вопрос на самом деле про Y.
Если про Windows — то у Руссиновича и Соломона в книге "Внутреннее Устройство Windows", если про Linux — то основы почитать можно у Бовета и Чезатти в "Understanding the Linux kernel", а потом уже в дайджестах на lwn.net и в документации на ядро.
Сейчас полно доступных онлайновых курсов от ведущих университетов не этой страны. Например, очень крутые курсы от мти и калтеха. Какой при этом смысл вообще в отечественном высшем образовании с кучей устаревших программ с дополнительными реально ненужными предметами на первых курсах, если только не ради "корочки"? Вот только не нужно тут про развитие кругозора и то, что отечественные ВУЗы якобы учат правильно мыслить и решать широкий круг задач.
Ну так в чём проблема-то? Возьмите и реализуйте поддержку этих алгоритмов в ядре, отправьте патчи в мейл-лист ментейнерам подсистемы криптографии. Нужно не только их реализовать и добавить, но и сопровождать. Видимо, эти алгоритмы настолько сильно никому особо и не нужны непосредственно в ядре.
В алгоритме есть проблемы, кстати. 1. Не учитывается случай, что шаблон может быть длиннее строки, в которой он ищется, или может быть пустым. 2. Бесполезные итерации в конце поиска.
Патчи только предложены — отправлены в списки рассылки подсистем, которые они затрагивают. После этого данные патчи должны быть одобрены мейнтейнерами этих подсистем, а уже только потом Линус вольёт их в основную ветку.
Для команды пинг можно добавить пример с запретом фрагментации и указанием размера полезной нагрузки — позволяет удобно диагностировать проблемы с MTU.
Было бы полезнее добавить пример использования команды traceroute для трейса с помощью tcp-syn пакетов, что позволит посмотреть более полный путь в случае хитрых файерволлов.
Почему-то в примерах сначала идёт команда ip route для просмотра маршрутов, а вот примеры по управлению маршрутами (добавление и удаление) приведены уже с использованием комады route, которая как deprecated, а в некоторых дистрибутивах уже и отсутствует. Хотя даже краткая справка по утилите ip займёт несколько статей. Тоже самое касается и netstat, вместо которой сейчас принятно использовать более продвинутые ss (для просмотра информации по открытым сокетам) и nstat (для просмотра различных счётчиков сетевого стека).
Для просмотра правил iptables лучше использовать команду iptables-save -c, которая выведет все правила со счётчиками во всех таблицах (а не только в таблице filter, как iptables -L). Для изменения правил безопаснее использовать iptables-apply, которая откатывает правила, если изменения не подтвердить в течение тайм-аута. Приведённая команда очистки правил (iptables -F) в большинстве случаев приведёт к полной недоступности сервера, если в политике filter/INPUT стоит DROP, а в подавляющем большинстве случаев это именно так.
В общем, шпаргалка устарела на несколько лет, содержит обрывочные сведения, и вряд ли будет полезна новичкам в Linux. Вместо этого для новичков (и не только) был бы более полезен пошаговый алгоритм диагностики и устранения проблем с сетью в Linux. На крайний случай, даже просто перечень ссылок на учебники и хаутушки окажется более полезен.
Хуже всего, что никаких метрик на этот случай не предусмотрели. Отловить источник проблемы можно лишь догадавшись, почему такое странное ограничение (20), или через запуск strace на процессе, который лишь покажет, что setsockopt с опцией IP_ADD_MEMBERSHIP по какой-то причине возвращает ошибку ENOBUFS.
Используется именно MAX, а не AND. При проверке используется макрос IN_DEV_RPFILTER, который в свою очередь использует макрос IN_DEV_MAXCONF, который уже использует макрос max. У переменных sysctl подобная логика может различаться. Для уточнения лучше читать либо документацию, либо исходники.
Есть одна особенность, которая не позволяет отключить данным образом rp_filter. Дело в том, что применяется значение max(all, <iface>), т.е. если у вас в конфиге интерфейса net.ipv4.conf.${iface}.rp_filter = 1, а net.ipv4.conf.all.rp_filter = 0, то для интерфейса будет использоваться значение rp_filter = 1. Правильнее не отключать rp_filter совсем, а использовать так называемый loose-режим, который смягчает правила rp_filter, и будет отбрасывать пакеты лишь в том случае, если до источника этих пакетов вообще нет маршрута. Если же маршрут до источника есть, но он не совпадает с интерфейсом, на который пришли пакеты, то они всё равно будут пропущены, а не отброшены, как при rp_filter = 1 (strict-режим).
По-моему, диагностику лучше всего начинать с просмотра статистики через nstat -az. В кейсе 1 сразу можно было бы увидеть инкрементирование счётчика TcpExtIPReversePathFilter (количество отброшенных rp_filter-ом пакетов), а в кейсе 2 — TcpExtTCPTimeWaitOverflow. Третий кейс интересный, и я когда-то тоже натыкался на это ограничение по-умолчанию на сервере, который работал с кучей мультикаст групп.
Технически REDIRECT является подвидом DNAT, с той лишь разницей, что адрес назначения (destination) переписывается на primary-адрес интерфейса, с которого получен пакет (вот так это реализовано для IPv4 и для IPv6). Локальные же пакеты будут перенаправляться на порт на адресе 127.0.0.1. Отсюда следует одна неочевидная особенность — если вы перенаправляете пакеты на какой-то порт, но ваше приложение не слушает порт на интерфейсе, на который пришёл пакет, то ничего не заработает — счётчики на правиле будут увеличиваться, но в ответ клиенту будут улетать tcp-reset'ы или icmp-port-unreachable (если там UDP). Точно так же, например, не получится перенаправлять входящие извне пакеты приложению, которое слушает только 127.0.0.1. Если же на интерфейсе нет адреса вообще (например, если вы используете unnumbered-интерфейс), то пакеты будут отброшены. И так как это завязано на коннтраке, то не забывайте очищать таблицу коннтрака после изменения правил; а так же учтите, что под это правило попадают только пакеты соединений с состоянием NEW, то есть только первый пакет соединения, которого ещё нет в таблице коннтрака. Отловить же эти пакеты в других цепочках можно через конструкцию "-m conntrack --ctstate DNAT". Вот как-то так.
Cake — ещё одна дисциплина очереди, которая разрабатывается в рамках проекта bufferbloat. Подробнее тут.
Cubic — один из алгоритмов управления перегрузкой (congestion control) в tcp. Используется по-умолчанию. Статья в википедии.
В tc реализованы как policer, так и shaper трафика. Причём алгоритмов шейпинга несколько, с различными возможностями и сложностью настройки. Это именно шейперы, которые в случае необходимости, «придерживают» пакеты в буфере, выравнивая скорость передачи данных. Алгоритмы контроля перегрузки (congestion control) протокола TCP на конечных хостах уже после подстраиваются под задержки и потери сегментов, замедляя и ускоряя передачу данных.
Вы так говорите, как будто в одиночку всем этим занимались. Судя по Вашему профилю и стилю общения, Вы управленец, а не инженер. Лично у меня предвзятое отношение к призам для управленцев, которые выдаются другими управленцами.
А есть ли в планах выпуск второго тома "Внутреннее устройство Windows"?
Да вот как раз-таки ни фига непонятно. Бесят люди, которые задают вопрос про X, получают ответ, а потом недовольны, что ты ответил именно на то, что они спросили. А ты должен был догадаться, что вопрос на самом деле про Y.
Если про Windows — то у Руссиновича и Соломона в книге "Внутреннее Устройство Windows", если про Linux — то основы почитать можно у Бовета и Чезатти в "Understanding the Linux kernel", а потом уже в дайджестах на lwn.net и в документации на ядро.
Сейчас полно доступных онлайновых курсов от ведущих университетов не этой страны. Например, очень крутые курсы от мти и калтеха. Какой при этом смысл вообще в отечественном высшем образовании с кучей устаревших программ с дополнительными реально ненужными предметами на первых курсах, если только не ради "корочки"? Вот только не нужно тут про развитие кругозора и то, что отечественные ВУЗы якобы учат правильно мыслить и решать широкий круг задач.
Ну так в чём проблема-то? Возьмите и реализуйте поддержку этих алгоритмов в ядре, отправьте патчи в мейл-лист ментейнерам подсистемы криптографии. Нужно не только их реализовать и добавить, но и сопровождать. Видимо, эти алгоритмы настолько сильно никому особо и не нужны непосредственно в ядре.
Для команды пинг можно добавить пример с запретом фрагментации и указанием размера полезной нагрузки — позволяет удобно диагностировать проблемы с MTU.
Было бы полезнее добавить пример использования команды traceroute для трейса с помощью tcp-syn пакетов, что позволит посмотреть более полный путь в случае хитрых файерволлов.
Почему-то в примерах сначала идёт команда
ip routeдля просмотра маршрутов, а вот примеры по управлению маршрутами (добавление и удаление) приведены уже с использованием комадыroute, которая как deprecated, а в некоторых дистрибутивах уже и отсутствует. Хотя даже краткая справка по утилите ip займёт несколько статей. Тоже самое касается и netstat, вместо которой сейчас принятно использовать более продвинутыеss(для просмотра информации по открытым сокетам) иnstat(для просмотра различных счётчиков сетевого стека).Для просмотра правил iptables лучше использовать команду
iptables-save -c, которая выведет все правила со счётчиками во всех таблицах (а не только в таблице filter, какiptables -L). Для изменения правил безопаснее использоватьiptables-apply, которая откатывает правила, если изменения не подтвердить в течение тайм-аута. Приведённая команда очистки правил (iptables -F) в большинстве случаев приведёт к полной недоступности сервера, если в политике filter/INPUT стоит DROP, а в подавляющем большинстве случаев это именно так.В общем, шпаргалка устарела на несколько лет, содержит обрывочные сведения, и вряд ли будет полезна новичкам в Linux. Вместо этого для новичков (и не только) был бы более полезен пошаговый алгоритм диагностики и устранения проблем с сетью в Linux. На крайний случай, даже просто перечень ссылок на учебники и хаутушки окажется более полезен.
Хуже всего, что никаких метрик на этот случай не предусмотрели. Отловить источник проблемы можно лишь догадавшись, почему такое странное ограничение (20), или через запуск
straceна процессе, который лишь покажет, чтоsetsockoptс опциейIP_ADD_MEMBERSHIPпо какой-то причине возвращает ошибкуENOBUFS.Используется именно MAX, а не AND. При проверке используется макрос IN_DEV_RPFILTER, который в свою очередь использует макрос IN_DEV_MAXCONF, который уже использует макрос max. У переменных sysctl подобная логика может различаться. Для уточнения лучше читать либо документацию, либо исходники.
Есть одна особенность, которая не позволяет отключить данным образом rp_filter. Дело в том, что применяется значение
max(all, <iface>), т.е. если у вас в конфиге интерфейсаnet.ipv4.conf.${iface}.rp_filter = 1, аnet.ipv4.conf.all.rp_filter = 0, то для интерфейса будет использоваться значениеrp_filter = 1. Правильнее не отключатьrp_filterсовсем, а использовать так называемый loose-режим, который смягчает правилаrp_filter, и будет отбрасывать пакеты лишь в том случае, если до источника этих пакетов вообще нет маршрута. Если же маршрут до источника есть, но он не совпадает с интерфейсом, на который пришли пакеты, то они всё равно будут пропущены, а не отброшены, как приrp_filter = 1(strict-режим).По-моему, диагностику лучше всего начинать с просмотра статистики через
nstat -az. В кейсе 1 сразу можно было бы увидеть инкрементирование счётчикаTcpExtIPReversePathFilter(количество отброшенных rp_filter-ом пакетов), а в кейсе 2 —TcpExtTCPTimeWaitOverflow. Третий кейс интересный, и я когда-то тоже натыкался на это ограничение по-умолчанию на сервере, который работал с кучей мультикаст групп.Cubic — один из алгоритмов управления перегрузкой (congestion control) в tcp. Используется по-умолчанию. Статья в википедии.