Выбор правила маршрутизации
Я думаю, что причина того, что вы не видите происходящего системного вызова, заключается в том, что некоторые системные вызовы Linux (особенно . связанные со временем, такие как gettimeofday (2) и time (2) ), имеют специальные реализации через vDSO , который содержит несколько оптимизированные реализации некоторых системных вызовов. :
«vDSO» (виртуальный динамический общий объект) - это небольшая разделяемая библиотека , которую ядро автоматически отображает в адресное пространство всех приложений пользовательского пространства.
Ядро предоставляет некоторые системные вызовы, которые в конечном итоге часто используются в коде пользовательского пространства, вплоть до того, что такие вызовы могут влиять на общую производительность. Это связано как с частотой вызова, так и с накладными расходами на переключение контекста , которые возникают в результате выхода из пользовательского пространства и входа в ядро .
Теперь в руководстве упоминается, что необходимая информация просто помещается в память, чтобы процесс мог получить к ней прямой доступ (в конце концов, текущее время не является большим секретом). Я не знаю точной реализации и мог только догадываться о роли счетчика временных меток ЦП в файле it.
Итак, оптимизацию выполняет не glibc, а ядро. Его можно отключить, установив vdso = 0 в командной строке ядра , и его можно будет скомпилировать. Однако я не могу найти, можно ли отключить его на стороне glibc (по крайней мере, без исправления библиотеки).
По этому вопросу о SE есть много другой информации и источников.
В вопросе вы сказали:
После просмотра последнего проекта POSIX, часть ответа ясна: есть способ запросить часы у ЦП, но GNU glibc ошибочно навязала эту реализацию своим пользователям.
Что я считаю довольно смелым заявлением. Я не вижу никаких доказательств того, что пользователям что-то «неправильно навязывают», по крайней мере, не в ущерб им. Реализация vDSO используется почти всеми процессами Linux, запущенными в текущих системах, а это означает, что если бы она работала некорректно, уже были бы услышаны очень громкие жалобы. Также вы сами сказали, что время получено правильно.
Цитата, которую вы даете из руководства clock_gettime , кажется, только упоминает, что вызов должен поддерживать идентификаторы часов, возвращаемые clock_getcpuclockid , а не что-либо о поведении CLOCK_REALTIME ] или gettimeofday .
ip ruleимеет опцию priority. Параметр приоритета — это первый способ выбора таблицы маршрутизации. Правило с более низким значением priorityбудет использоваться перед более высоким. Позвонив по номеру ip rule show, вы увидите правила, напечатанные с их приоритетом слева.
[priority]: [rule]
Для полноты картины цитата изman ip-rule:
priority PREFERENCE
the priority of this rule. PREFERENCE is an unsigned integer value, higher number means lower priority, and rules get processed in order of increasing number. Each rule should have an explicitly set unique priority value. The options preference and order are synonyms with priority.
Акцент мой.
Итак, прежде всего, лучше всего использовать уникальный приоритет для каждого правила, тогда не может быть двусмысленности. В случае правил с одинаковым приоритетомони будут оцениваться в том порядке, в котором они были добавлены. Если правила являются взаимоисключающими, это не представляет большого риска (, например два правила, которые совпадают на разных исходных IP-адресах от других хостов ). Если ваши правила добавляются автоматически, это, вероятно, означает, что будет использоваться файл правил, который находится первым в алфавитном порядке, что не является лучшим способом определения маршрутизации.
Как я пришел к выводу, что используются первые добавленные правила:
- Создана виртуальная машина (vm1 )с двумя интерфейсами в одной сети (192.168.0.1/24 и 192.168.0.2/24 ).
- Создал еще одну виртуальную машину (vm2 )в сети (192.168.0.3/24)
- Созданы две таблицы маршрутизации,
table1иtable2на vm1
ip route add default dev eth0 table table1
ip route add default dev eth1 table table2
- Создано два правила с разными приоритетами
ip rule add to 192.168.0.3 table table1 priority 10
ip rule add to 192.168.0.3 table table2 priority 11
- пропинговать vm2 с vm1
tcpdump -i eth0 host 192.168.0.3показывает пингtcpdump -i eth1 host 192.168.0.3нет
Это ожидаемое поведениеpriority
- По поводу -добавьте правило table2 с приоритетом 10, ping по-прежнему появляется только на
eth0.ip rule showперечисляет правилоtable1перед правиломtable2. - Удалить правило table1, ping появляется на eth1.
- Re -добавить правило table1, ping все еще на eth1.
ip rule showперечисляет правилоtable2передtable1.
IP-адрес источника не участвует в выборе маршрута. Маршрут выбирается путем обхода таблицы маршрутизации :для каждой записи в таблице, сравнения префикса назначения сети (, т. е. пункта назначения сети И маски сети )с IP-адресом назначения И маской сети. Если они равны, у нас есть совпадение. После проверки каждой записи в таблице маршрутизации, если есть несколько совпадений, выберите запись с самым длинным префиксом. Если нет совпадения, нет пути к месту назначения. Маршрут по умолчанию всегда совпадает, поскольку длина префикса равна нулю.
Если пункт назначения не является локальной -ссылкой, в соответствующей записи будет указан адрес шлюза, и процесс повторяется для адреса шлюза. Наконец, пакет отправляется с заполненными адресами источника и получателя. Используется исходный адрес назначения, а адрес источника берется из окончательного правила сопоставления маршрута (поле srcв выводе ip route).