Call trace linux что это

Debian // Call Trace

Последний Stable Debian. На борту: squid, postfix, dovecot, LAMP. Вот что выдаёт в логе. С Дебианом вожусь впервые и многое непонятно, но стараюсь вроде всё найти в нете. С этим маюсь уже неделю. Никак не пойму что это, критично ли это. Понимаю что что-то с сидюком, но он работает нормально. Что сие может означать?

Aug 13 22:11:36 gateway kernel: [17795.124760] Call Trace:
Aug 13 22:11:36 gateway kernel: [17795.124790] [] :ide_cd_mod:cdrom_do_newpc_cont+0x0/0x2b
Aug 13 22:11:36 gateway kernel: [17795.124799] [] schedule_timeout+0x1e/0xad
Aug 13 22:11:36 gateway kernel: [17795.124816] [] :ide_core:ide_do_request+0x8cd/0x930
Aug 13 22:11:36 gateway kernel: [17795.124825] [] :ide_cd_mod:cdrom_newpc_intr+0x0/0x5e1
Aug 13 22:11:36 gateway kernel: [17795.124840] [] :ide_core:ide_do_request+0x1c/0x930
Aug 13 22:11:36 gateway kernel: [17795.124847] [] wait_for_common+0xcf/0x13a
Aug 13 22:11:36 gateway kernel: [17795.124852] [] default_wake_function+0x0/0xe
Aug 13 22:11:36 gateway kernel: [17795.124870] [] :ide_core:ide_do_drive_cmd+0xe2/0x109
Aug 13 22:11:36 gateway kernel: [17795.124882] [] :ide_cd_mod:ide_cd_queue_pc+0x42/0xca
Aug 13 22:11:36 gateway kernel: [17795.124889] [] :ide_cd_mod:ide_cd_queue_pc+0x42/0xca
Aug 13 22:11:36 gateway kernel: [17795.124895] [] blk_rq_init+0x1c/0x85
Aug 13 22:11:36 gateway kernel: [17795.124905] [] :ide_cd_mod:cdrom_read_tocentry+0xb1/0xc3
Aug 13 22:11:36 gateway kernel: [17795.124927] [] blk_end_sync_rq+0x0/0x2e
Aug 13 22:11:36 gateway kernel: [17795.124938] [] :ide_cd_mod:ide_cd_read_toc+0x101/0x3c8
Aug 13 22:11:36 gateway kernel: [17795.124952] [] :ide_cd_mod:idecd_revalidate_disk+0x14/0x1b
Aug 13 22:11:36 gateway kernel: [17795.124959] [] __invalidate_device+0x3a/0x42
Aug 13 22:11:36 gateway kernel: [17795.124964] [] check_disk_change+0x4f/0x76
Aug 13 22:11:36 gateway kernel: [17795.124973] [] :cdrom:cdrom_open+0x983/0xa14
Aug 13 22:11:36 gateway kernel: [17795.124980] [] dput+0x1c/0xdd
Aug 13 22:11:36 gateway kernel: [17795.124984] [] kobject_get+0x12/0x17
Aug 13 22:11:36 gateway kernel: [17795.124989] [] get_disk+0x40/0x5b
Aug 13 22:11:36 gateway kernel: [17795.124994] [] exact_lock+0xc/0x14
Aug 13 22:11:36 gateway kernel: [17795.125003] [] :ide_cd_mod:idecd_open+0x5b/0x89
Aug 13 22:11:36 gateway kernel: [17795.125007] [] blkdev_open+0x0/0x5d
Aug 13 22:11:36 gateway kernel: [17795.125012] [] do_open+0xd1/0x2e8
Aug 13 22:11:36 gateway kernel: [17795.125019] [] blkdev_open+0x0/0x5d
Aug 13 22:11:36 gateway kernel: [17795.125023] [] blkdev_open+0x2e/0x5d
Aug 13 22:11:36 gateway kernel: [17795.125029] [] __dentry_open+0x12c/0x238
Aug 13 22:11:36 gateway kernel: [17795.125037] [] do_filp_open+0x3d7/0x7c4
Aug 13 22:11:36 gateway kernel: [17795.125045] [] :cdrom:cdrom_release+0x1a7/0x1e4
Aug 13 22:11:36 gateway kernel: [17795.125055] [] iput+0x27/0x60
Aug 13 22:11:36 gateway kernel: [17795.125062] [] get_unused_fd_flags+0x71/0x115
Aug 13 22:11:36 gateway kernel: [17795.125070] [] do_sys_open+0x46/0xc3
Aug 13 22:11:36 gateway kernel: [17795.125076] [] system_call_after_swapgs+0x8a/0x8f
Aug 13 22:11:36 gateway kernel: [17795.125085]
Aug 13 22:13:45 gateway kernel: [17923.972736] hald-addon-st D0000000000000000 0 3459 3431
Aug 13 22:13:45 gateway kernel: [17923.972742] ffff81002c105878 0000000000000082 0000000000000000 ffffffffa0117b00
Aug 13 22:13:45 gateway kernel: [17923.972747] ffff81002c0c94f0 ffffffff804f8480 ffff81002c0c9778 0000000037987400
Aug 13 22:13:45 gateway kernel: [17923.972752] ffffffffa0117b90 0000000000000000 00000000ffffffff 0000000000000000

nvariec
14.08.09 09:19:23 MSD

Kernel (Русский)

Состояние перевода: На этой странице представлен перевод статьи Kernel. Дата последней синхронизации: 10 июля 2021. Вы можете помочь синхронизировать перевод, если в английской версии произошли изменения.

Ядро Linux — ядро операционной системы, соответствующее стандартам POSIX, составляющее основу операционных систем семейства Linux.

Дистрибутив Arch Linux основан на ядре Linux. Помимо основной стабильной (stable) версии в Arch Linux можно использовать некоторые альтернативные ядра. В статье описываются доступные в официальных репозиториях версии ядер, возможные патчи, а также способы, которыми пользователи могут скомпилировать собственное ядро.

Пакет ядра устанавливается в файловую систему в каталоге /boot/ . Для загрузки нужного ядра при запуске системы необходимо соответствующим образом настроить загрузчик.

Официальные ядра

Помощь при работе с официальными ядрами можно найти на форуме и в баг-трекере.

Stable — «ванильное» ядро Linux с модулями и некоторыми патчами.

Hardened — ориентированное на безопасность ядро Linux с набором патчей, защищающих от эксплойтов ядра и пространства пользователя. Содержит больше защитных особенностей, чем linux .

Longterm — ядро и модули с долгосрочной поддержкой (Long Term Support, LTS).

Zen Kernel — результат коллективных усилий исследователей с целью создать лучшее из возможных ядер Linux для систем общего назначения. Подробности проекта можно найти на сайте liquorix.net (там же можно скачать двоичные файлы Zen-ядра для Debian).

Компиляция

Скомпилировать собственное ядро можно двумя способами:

/Arch Build System Преимущества — наличие готового PKGBUILD для пакета linux и удобство системы управления пакетами. /Традиционная компиляция Ручная загрузка архива файлов с исходными кодами ядра и их компиляция.

Нестандартное ядро чревато всевозможными проблемами в плане надёжности и стабильности работы, поэтому настоятельно рекомендуется использовать резервное копирование.
Arch Linux поддерживает только #Официальные ядра. Если вы работаете с другим ядром, то не забывайте упоминать это в запросах в поддержку.

Лучший способ повысить производительность — адаптировать ядро под свою систему, в первую очередь под архитектуру и тип процессора.
Если оставить в ядре только действительно нужные вам функции, то удастся уменьшить его размер и, следовательно, время сборки. Например, удалите из него Bluetooth, Video4Linux, 1000Mbit Ethernet и прочие вещи, которые на вашей машине точно не понадобятся.

Файлы конфигурации пакетов с ядрами Arch можно найти в исходниках (например, файл [1] из linux ). Если включена опция ядра CONFIG_IKCONFIG_PROC , то файл /proc/config.gz содержит настройки ядра, которое работает на вашей машине в данный момент.

Некоторые из перечисленных пакетов могут быть также доступны в двоичном виде в неофициальных репозиториях.

Ядра kernel.org

Git — ядро Linux, собранное из файлов с исходным кодом из git-репозитория Линуса Торвальдса.

Mainline — ядра, в которых появляются все нововведения. Выходят каждые 2-3 месяца.

Next — самые новейшие ядра, с улучшениями, которые будут добавлены в следующий mainline-выпуск.

Longterm 4.19 — LTS-ядро версии 4.19.

Longterm 5.4 — LTS-ядро версии 5.4.

Longterm 5.10 — LTS-ядро версии 5.10.

Longterm 5.15 — LTS-ядро версии 5.15.

Неофициальные ядра

Ck — патч от Con Kolivas, повышение быстродействия для настольных систем с любым типом нагрузки.

Clear — патчи проекта Clear Linux от Intel. Содержит улучшения производительности и безопасности.

GalliumOS — ядро Linux с патчами GalliumOS для Хромбуков.

Libre — без проприетарных или обфусцированных драйверов устройств.

Liquorix — ядро, собранное из исходного кода Zen с настройками для Debian. Разработан для настольных, мультимедийных и игровых систем, часто используется в качестве замены основному ядру Debian. Создатель патча Liquorix, Damentz, также является разработчиком набора патчей Zen.

pf-kernel — набор неплохих улучшений, не вошедших в mainline. Сопровождается разработчиком ядра. Предоставляет порты улучшений для новых версий ядра, если они не были выпущены официально. Наиболее важные нововведения — UKSM.

Репозиторий, linux-pfAUR от разработчика pf-kernel, post-factum.

Realtime kernel — поддерживается небольшой группой разработчиков, возглавляемой Ingo Molnar. Патч позволяет применять kernel preemption практически ко всему ядру за исключением небольших участков кода («raw_spinlock critical regions»). Этого удалось добиться за счёт замены большинства спинлоков ядра на мьютексы с поддержкой наследования приоритета, а также перемещением всех прерываний (в том числе и программных) в потоки ядра.

Tkg — ядро с набором патчей для планировщиков PDS и Project C / BMQ. Стандартный планировщик CFS также доступен. Изменения нацелены на улучшение баланса интерактивность/производительность в играх. Автор и сопроводитель — Etienne Juvigny (Tk-Glitch).

VFIO — патч ядра от Alex Williamson с поддержкой PCI Passthrough для KVM на некоторых машинах.

XanMod — улучшение производительности ядер рабочих станций, игровых компьютеров, медиацентров и других систем. Включает планировщик MuQSS, планировщик ввода-вывода BFQ, алгоритм дедупликации памяти в реальном времени UKSM, алгоритм управления перегрузками TCP BBR, расширенный набор команд для архитектуры x86_64 и другие изменения.

Решение проблем

Паника ядра

Паника ядра (kernel panic) возникает, когда ядро Linux попадает в состояние невосстановимого сбоя. Это состояние обычно возникает из-за ошибок в драйверах оборудования, в результате чего система попадает в deadlock, не реагирует на запросы и требует перезагрузки. Непосредственно перед deadlock генерируется диагностическое сообщение, состоящее из: состояния компьютера, когда произошел сбой, трассировки (call trace), ведущей к функции ядра, распознавшей сбой, и списка загруженных в данный момент модулей. К счастью, паники ядра случаются нечасто при использовании основных версий ядра — таких, которые поставляются из официальных репозиториев — но когда они случаются, необходимо знать, как с ними бороться.

Примечание: Паники ядра иногда называются oops или kernel oops. Хотя и то, и другое возникает в результате сбоя, oops является более общим явлением, поскольку не обязательно приводит к deadlock — иногда ядро может восстановиться после oops, убив проблемную задачу и продолжив работу.

Совет: Передайте параметр ядра oops=panic при загрузке или запишите 1 в /proc/sys/kernel/panic_on_oops , чтобы заставить восстановимый oops выдавать панику. Это рекомендуется сделать, если вас волнует небольшая вероятность получения нестабильной системы после восстановления из oops, что может затруднить диагностику будущих ошибок.

Изучение сообщения паники

Если паника ядра происходит очень рано в процессе загрузки, вы можете увидеть в консоли сообщение «Kernel panic — not syncing:», но после запуска systemd сообщения ядра обычно перехватываются и записываются в системный журнал. Однако, когда возникает паника, диагностическое сообщение, выдаваемое ядром, почти никогда не записывается в файл журнала на диске, потому что компьютер попадает в deadlock до того, как system-journald получит шанс записать журнал. Поэтому единственный способ просмотреть сообщение о панике — это просмотреть его на консоли в момент возникновения (не прибегая к установке kdump crashkernel). Вы можете сделать это, загрузившись со следующими параметрами ядра и попытавшись воспроизвести панику на tty1:

systemd.journald.forward_to_console=1 console=tty1

Совет: Если сообщение о панике прокручивается слишком быстро, попробуйте передать параметр ядра pause_on_oops=секунды при загрузке.

Пример сценария: плохой модуль

Можно сделать предположение о том, какая подсистема или модуль вызывает панику, используя информацию в диагностическом сообщении. В этом сценарии мы имеем панику на некотором воображаемом компьютере во время загрузки. Обратите внимание на строки, выделенные жирным:

kernel: BUG: unable to handle kernel NULL pointer dereference at (null) [1] kernel: IP: fw_core_init+0x18/0x1000 [firewire_core] [2] kernel: PGD 718d00067 kernel: P4D 718d00067 kernel: PUD 7b3611067 kernel: PMD 0 kernel: kernel: Oops: 0002 [#1] PREEMPT SMP kernel: Modules linked in: firewire_core(+) crc_itu_t cfg80211 rfkill ipt_REJECT nf_reject_ipv4 nf_log_ipv4 nf_log_common xt_LOG nf_conntrack_ipv4 . [3] kernel: CPU: 6 PID: 1438 Comm: modprobe Tainted: P O 4.13.3-1-ARCH #1 kernel: Hardware name: Gigabyte Technology Co., Ltd. H97-D3H/H97-D3H-CF, BIOS F5 06/26/2014 kernel: task: ffff9c667abd9e00 task.stack: ffffb53b8db34000 kernel: RIP: 0010:fw_core_init+0x18/0x1000 [firewire_core] kernel: RSP: 0018:ffffb53b8db37c68 EFLAGS: 00010246 kernel: RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 kernel: RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffffc16d3af4 kernel: RBP: ffffb53b8db37c70 R08: 0000000000000000 R09: ffffffffae113e95 kernel: R10: ffffe93edfdb9680 R11: 0000000000000000 R12: ffffffffc16d9000 kernel: R13: ffff9c6729bf8f60 R14: ffffffffc16d5710 R15: ffff9c6736e55840 kernel: FS: 00007f301fc80b80(0000) GS:ffff9c675dd80000(0000) knlGS:0000000000000000 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 kernel: CR2: 0000000000000000 CR3: 00000007c6456000 CR4: 00000000001406e0 kernel: Call Trace: kernel: do_one_initcall+0x50/0x190 [4] kernel: ? do_init_module+0x27/0x1f2 kernel: do_init_module+0x5f/0x1f2 kernel: load_module+0x23f3/0x2be0 kernel: SYSC_init_module+0x16b/0x1a0 kernel: ? SYSC_init_module+0x16b/0x1a0 kernel: SyS_init_module+0xe/0x10 kernel: entry_SYSCALL_64_fastpath+0x1a/0xa5 kernel: RIP: 0033:0x7f301f3a2a0a kernel: RSP: 002b:00007ffcabbd1998 EFLAGS: 00000246 ORIG_RAX: 00000000000000af kernel: RAX: ffffffffffffffda RBX: 0000000000c85a48 RCX: 00007f301f3a2a0a kernel: RDX: 000000000041aada RSI: 000000000001a738 RDI: 00007f301e7eb010 kernel: RBP: 0000000000c8a520 R08: 0000000000000001 R09: 0000000000000085 kernel: R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000c79208 kernel: R13: 0000000000c8b4d8 R14: 00007f301e7fffff R15: 0000000000000030 kernel: Code: 04 25 00 00 00 00 01 00 00 00 bb f4 ff ff ff e8 73 43 9c ec 48 kernel: RIP: fw_core_init+0x18/0x1000 [firewire_core] RSP: ffffb53b8db37c68 kernel: CR2: 0000000000000000 kernel: ---[ end trace 71f4306ea1238f17 ]--- kernel: Kernel panic - not syncing: Fatal exception [5] kernel: Kernel Offset: 0x80000000 from 0xffffffff810000000 (relocation range: 0xffffffff800000000-0xfffffffffbffffffff kernel: ---[ end Kernel panic - not syncing: Fatal exception

[1] Указывает тип ошибки, вызвавшей панику. В данном случае это была ошибка программиста.
[2] Указывает, что паника произошла в функции под названием fw_core_init в модуле firewire_core.
[3] Указывает, что firewire_core был последним загруженным модулем.
[4] Указывает, что функция, вызвавшая функцию fw_core_init, была do_one_initcall.
[5] Указывает на то, что это сообщение oops на самом деле является паникой ядра, и система ушла в deadlock.

Мы можем предположить, что паника произошла во время инициализации модуля firewire_core при его загрузке. (Тогда можно предположить, что аппаратное обеспечение компьютера несовместимо с данной версией модуля драйвера firewire из-за ошибки программиста, и придётся ждать новой версии). Тем временем, самый простой способ заставить компьютер снова работать — это предотвратить загрузку проблемного модуля. Это можно сделать одним из двух способов:

Если модуль загружается в процессе работы initramfs, перезагрузитесь с параметром ядра rd.blacklist=firewire_core .
Иначе перезагрузитесь с параметром ядра module_blacklist=firewire_core .

Отладка регрессий

Прежде всего проверьте ядро linux-mainline AUR на предмет того, не была ли проблема уже решена. В прикреплённом комментарии указан репозиторий с уже собранными ядрами, так что собирать ядро вручную не придётся.

Если проблема проявляется не слишком часто, то имеет смысл попробовать LTS-ядро ( linux-lts ). Старые версии LTS-ядер можно найти в архиве Arch Linux.

Если избавиться от проблемы не удалось, попробуйте локализовать баг в linux-git AUR , после чего сообщите о нём в баг-трекер ядра. Важно проверять ванильное непропатченное ядро, чтобы убедиться, что причиной ошибки является не патч. Если проблемы вызывает патч, то сообщите об этом его автору.

Примечание: Локализация местонахождения бага в коде может занять много времени, поскольку придётся многократно пересобирать ядро.

Смотрите также

O’Reilly — Linux Kernel in a Nutshell — электронная книга «Ядро Linux в двух словах».
Какую из stable-версий ядра лучше использовать? от Greg Kroah-Hartman.
Документация ядра Linux

Traceroute и Tracert — утилиты-близнецы? Что такое трассировка сети

Для большинства поставщиков управляемых услуг (MSP), системных администраторов и технических специалистов, команды Traceroute и Tracert являются первыми сигналами для устранения неполадок, связанных с задержкой сети или проблемами с подключением. Но что это?

Что такое Traceroute и Tracert

Traceroute или Tracert – это утилита, служащая для диагностики сети. Она отслеживает пути, по которым пакеты данных проходят от источника к хосту назначения, что позволяет администраторам оперативно решить проблемы с подключением.

В Windows эта команда называется Tracert, а в Linux и MacOS – Traceroute.

Traceroute и Tracert в основном работают одинаково – они предоставляют информацию о пути пакета данных из одной точки сети на конкретный IP-сервер. Когда данные передаются между двумя точками, они должны проходить через несколько устройств (например, маршрутизаторы).

Traceroute сопоставляет каждый переход, предоставляет подробную информацию и время приёма-передачи (RTT), а также, по возможности, сообщает имя устройства и IP-адрес.

В то время как команда Ping может сообщить, есть ли проблема, Traceroute поможет вам точно определить, где именно она образовалась.

Представьте, что вы посещаете веб-сайт, и его страницы долго загружаются. В этом случае вы можете использовать Traceroute, чтобы определить, где происходят самые длительные задержки, чтобы добраться до источника самого сбоя.

Как работает Traceroute и Tracert?

По протоколу UDP (User Datagram Protocol – «протокол пользовательских датаграмм») Traceroute отправляет последовательность IP-пакетов. Всего таких пакетов по умолчанию может быть 3.
Первый пакет имеет время жизни (также известное как TTL (Time To Live) или лимит переходов), равное 1, второй пакет имеет TTL=2 и так далее.
Каждый раз, когда пакет передается новому маршрутизатору, TTL уменьшается на 1. Это сделано для предотвращения проблем с зацикливанием между серверами. Если бы не было TTL, пакет мог бы бесконечно долго перебрасываться между серверами.

Когда время жизни достигает 0, пакет отбрасывается, а маршрутизатор возвращает сообщение об ошибке. Отправляя пакеты таким образом, Traceroute гарантирует, что каждый маршрутизатор на пути отклонит пакет и отправит ответ.

Всё о трассировке

Что такое трассировка?

Трассировка или точнее распределённая трассировка – это возможность отслеживать запросы по мере их прохождения через распределённые системы путём сбора данных о том, как они передаются от одной службы к другой.

Данные трассировки помогают понять поток запросов и определить, где в системе возникают сбои или проблемы с производительностью и почему.

Например, запрос может пройти через несколько служб и пройти туда и обратно через различные микрослужбы, чтобы достичь завершения.

Хотя трассировки существуют уже давно, тенденция к распределённым архитектурам, микросервисам и контейнеризации сделала их важной частью большой системы наблюдения. Ведь наличие механизма, позволяющего понять поток данных, необходимо для обслуживания серверов и устранения неполадок.

Трассировка, наряду с журналами и метриками, занимает важное место в системе. В то время как журналы предоставляют сведения о конкретных событиях, таких как обращение к базе данных и запись в файл или сообщение об ошибке, трассировка соединяет цепочку связанных событий.

Одна трассировка маршрута даёт представление о:

каждом шаге, через который прошёл запрос;
количестве времени, затраченном на каждое действие;
общем времени, которое понадобилось на его обработку.

В то время, как журналы предоставляют подробные сведения об активности, выполняемой каждой службой в процессе, ведение журнала трассировки обеспечивает полную запись цепочки событий, инициированных первоначальным запросом.

Эта информация бесценна для отладки сложных проблем и оптимизации вашей системы.

Как работает трассировка?

Прежде чем перейти к трассировке, важно узнать, что приложения могут быть монолитными или микросервисными.

Монолитное приложение разрабатывается как единый функциональный модуль, в то время как приложение с микросервисной архитектурой разбивается на модульные службы, каждая из которых выполняет основную функцию приложения и часто управляется специальной командой.

Микросервисы используются для создания многих современных приложений, поскольку они упрощают тестирование и развёртывание быстрых обновлений, а также предотвращают возникновение единой точки отказа.

Но устранение неполадок с микрослужбами может оказаться сложной задачей, поскольку они часто работают на базе сложной серверной архитектуры, а запросы могут включать в себя последовательности вызовов нескольких служб.

Используя трассировку, разработчики могут визуализировать весь путь запроса – от интерфейса к серверу – и точно определить любые сбои производительности, которые возникают на этом пути.

Платформы трассировки начинают собирать данные в момент подачи запроса. Например, когда пользователь отправляет форму на веб-сайте. Это создаёт уникальный идентификатор трассировки.

Этот процесс позволяет идентифицировать каждый запрос, вызов и процесс и соответствующим образом расставлять приоритеты в своих усилиях по устранению неполадок.

Для получения результатов трассировки в том числе используются команды Traceroute и Tracert.

Разница между Traceroute и Tracert

Принцип работы у Traceroute и Tracert один, однако разница между ними состоит не только в операционных системах.

Напоминаем, что команда Tracert обслуживает Windows, а Traceroute работает на Linux и MacOS.

Tracert

Tracert, в отличие от своего Linux-двойника, реализован на основе протокола ICMP, а не UDP.
Tracert отправляет эхо-запрос ICMP (ICMP Echo Request) с TTL=1.
Первый маршрутизатор проверяет адрес назначения, чтобы выяснить был ли отправлен запрос именно ему.
Узнав, что цель пакета – другой хост, маршрутизатор отбрасывает его, и TTL становится равным 0.
Затем маршрутизатор 1 отправляет ICMP-сообщение с указанием информации о себе и причине проблемы источнику пакета: «Time-To-Live Exceeded» или «Time Exceeded in transit».
Благодаря этому сообщению Tracert записывает маршрутизатор 1 как первый транзитный участок или, как его ещё называют, «хоп, прыжок».

Процесс передачи пакета между промежуточными маршрутизаторами продолжится, пока переменная (TTL ICMP-запроса), не станет равна количеству «прыжков» между узлом-отправителем и узлом-получателем, и пакет не будет получен хостом назначения или количество сетевых переходов не превысит максимальное значение для Tracert – 30.

Когда целевой хост проверит IP-адрес назначения и узнает, что запрос был направлен именно ему, он отправит эхо-ответ ICMP (ICMP Echo Request), что даст утилите понять, что процесс передачи завершён.

Traceroute

В чём ещё отличие Traceroute от Tracert? В Traceroute схема схожая, практически идентичная.

Целевому хосту направляется фрагментированный UDP-запрос. Таким образом, отправляется сразу несколько пакетов с TTL: TTL=1, TTL=2 и TTL=3.

Вот только раз эта утилита не отправляет эхо-запрос ICMP, как она понимает, что трассировка подошла к концу?

Всё просто: в каждом пакете содержатся данные о порте отправителя (Source) и порте получателя (Destination). Destination порт по умолчанию закрытый (34434), поэтому утилита Traceroute сразу понимает, что процесс передачи данных завершён, когда получает ответ с сообщением о недоступности порта «Destination port unreachable» (Хост/Порт недостижим). Иными словами, запрос достиг целевого хоста.

Как использовать Traceroute и Tracert?

В основном пользователи могут использовать команду Traceroute или Tracert через обычную командную строку. Однако точный метод его запуска зависит от операционной системы компьютера.

Давайте посмотрим, как запустить команду Traceroute или Tracert в Windows, Linux и macOS.

Перейдите в меню Пуск.
Выберите Выполнить.
Введите cmd и нажмите ОК. Это откроет командную строку.
Введите команду tracert и затем впишите имя хоста или IP-адрес назначения. Пример: tracert www.nic.ru
Нажмите Enter.

Откройте приложение Терминал. Это можно сделать при помощи сочетания клавиш CTRL + Shift + T.
Впишите команду traceroute вместе с именем хоста или IP-адресом. Пример: traceroute www.nic.ru
Нажмите Enter.

Раньше это действие можно было выполнить через встроенное приложение Сетевая утилита, но на данный момент она не поддерживается компанией Apple. Поэтому:

Запустите приложение Терминал.
Введите команду traceroute и имя хоста или IP-адрес назначения. Пример: traceroute www.nic.ru
Нажмите Enter.

Также можно добавить дополнительные параметры в команду Traceroute или Tracert, чтобы сделать ваши результаты более точными. Вот некоторые расширенные параметры трассировки:

Команда	Описание
-d	Команда Traceroute в Linux по умолчанию отправляет пробные пакеты UDP. Вы можете использовать эту опцию, чтобы преобразовать их в пакеты ICMP.
-h maximum_hops	Укажите максимальное количество переходов, включённых в процесс Tracert. Если вы не измените значение, оно будет соответствовать максимальному значению по умолчанию, равному 30 хопам.
-n	Поможет исключить доменные имена из результатов Traceroute.
-q number of packets	По умолчанию Traceroute отправляет три пакета. Вы можете изменить это число с помощью этой опции, за которой следует указать нужное количество пакетов.
-m max_ttl	Укажите максимальное количество переходов для процесса трассировки. Значение по умолчанию равно 30.
-w wait_time	Установите максимальное время ожидания для каждого ответа.
-p	Установите порт назначения для запроса.
-f	Укажите с какого TTL начать. По умолчанию значение равно 1.
-4	Задействование протокола IPv4.
-6	Задействование протокола IPv6.

Как читать результаты Tracert

После выполнения команды Tracert или Traceroute система представит результаты в виде множества строк. Отчёт может несколько отличаться в зависимости от вашей операционной системы, но обычно он содержит одну и ту же информацию.

Стандартные результаты Tracert или Traceroute включают в себя несколько строк, описывающих каждый переход, который проходит пакет для достижения хоста назначения. Каждая строка разделена на столбцы с различной информацией.

Давайте рассмотрим каждый столбец и его детали.

Число хопов	Имя хоста/IP-адрес	RTT 1	RTT 2	RTT 3
5	83.169.204.90	182.729 ms	174.127 ms	165.767 ms
8	192.168.43.1	5.735 ms	8.287 ms	6.694 ms
9	198.18.8.1	24.408 m	33.209 ms	26.241 ms

Число хопов – первый столбец количество сделанных “прыжков”.

IP-адрес или имя хоста – этот столбец раскрывает IP-адрес или имя хоста устройства на этом конкретном переходе.

RTT – это круговая задержка или время приёма-передачи, которое показывает, сколько времени требуется каждому пакету, чтобы достичь определенного IP-адреса и вернуться на ваш компьютер. Существует три разных столбца RTT, так как Traceroute по умолчанию отправляет три UDP-пакета.

Если время трассировки истекает на определенном узле, это может означать, что в данном месте возникла проблема или что маршрут неверен, что не позволяет пакету достичь пункта назначения. В результатах это представлено как:

Число хопа	Имя хоста/IP-адрес	RTT 1	RTT 2	RTT 3
13	(Request timed out.)	*	*	*

Заключение

Команда Traceroute и Tracert – это полезный и простой в использовании инструмент диагностики сети. Как правило, это ещё и первый способ устранения неполадок с подключением.

В этой статье вы узнали, чем эта утилита может отличаться в зависимости от вашей операционной системы, как использовать команду и читать полученные результаты.

Утилиты Traceroute и Tracert

Traceroute — это утилита, которая позволяет проследить маршрут следования данных до удаленного адресата в сетях TCP/IP. В Linux используется команда Traceroute, а в Windows — Tracert. При помощи этих команд можно увидеть путь пакета данных от вашего компьютера до целевого сервера или сайта.

Как работают Tracert и Traceroute

Когда вы пытаетесь открыть сайт, браузер отправляет сообщение (запрос) серверу, на котором этот сайт находится. Сообщение на своём пути проходит через маршрутизаторы. Они решают, куда дальше передать сообщение, чтобы гарантированно его доставить адресату. В трассировке маршрутизаторы еще называют хопами (хоп — прыжок) или узлами. Количество узлов, через которые на своем пути пройдет запрос, можно узнать при помощи утилит Tracert и Traceroute. Узлы, которые не являются целевыми для запроса, называют транзитными.

Утилита Traceroute формирует UDP-датаграмму (сообщение, которое нужно доставить целевому серверу), упаковывает ее в IP-пакет и передаёт первому транзитному узлу. В заголовке такого IP-пакета есть поле TTL (Time To Live) — время жизни пакета. Оно определяет количество хопов, через которые пакет может пройти. На каждом узле TTL уменьшается на единицу. Если на пути к удаленному адресату время жизни пакета станет равно 0, маршрутизатор отбросит пакет и отправит источнику ICMP-сообщение об ошибке «Time Exceeded» (время истекло).

Этот принцип лежит в основе работы утилит Tracert и Traceroute, однако между ними есть отличия. Рассмотрим каждую утилиту отдельно.

Tracert отправляет на хост назначения ICPM-запрос «Echo Request» с TTL=1. Первый маршрутизатор, который получит запрос, проверяет, кому он предназначен. Если маршрутизатор не является целевым хостом, он уменьшает TTL на 1, отбрасывает пакет и отправляет ICMP-сообщение источнику, так как время жизни теперь равно 0. В этом сообщении маршрутизатор указывает информацию о себе и причину дропа пакета. Получив сообщение, Tracert запоминает этот маршрутизатор как первый хоп (прыжок) и отправляет следующий пакет, но уже с TTL=2. Первый хоп успешно обрабатывает новый пакет, уменьшает время его жизни на 1 и передаёт дальше. Следующий маршрутизатор тоже выполняет проверку хоста назначения и, если пакет предназначен не ему, уменьшает TTL, отбрасывает пакет и отправляет ICMP-сообщение источнику. Tracert запоминает второй хоп, снова увеличивает TTL на 1 и отправляет следующий пакет. Эти действия будут повторяться до тех пор, пока пакет не достигнет целевого хоста. Когда запрос попадет к целевому хосту, этот хост в ответ направит ICMP «Echo Reply». Источник воспримет это как завершение трассировки.

Утилита Traceroute вместо ICMP-запроса отправляет 3 UDP-пакета на определенный порт целевого хоста и ожидает ответа о недоступности этого порта. Первый пакет отправляется с TTL=1, второй с TTL=2 и так далее, пока запрос не попадет адресату. Отличие от Tracert в том, как Traceroute понимает, что трассировка завершена. Так как вместо ICMP-запроса он отправляет UDP-запрос, в каждом запросе есть порт отправителя (Sourсe) и порт получателя (Destination). По умолчанию запрос отправляется на закрытый порт 34434. Когда запрос попадёт на хост назначения, этот хост отправит ответ о недоступности порта «Destination port unreachable» (порт назначения недоступен). Это значит, что адресат получил запрос. Traceroute воспримет этот ответ как завершение трассировки.

Если Tracert работает по протоколу ICMP, то какой протокол используется командой Traceroute? По умолчанию используется протокол UDP, но traceroute может отправить и ICMP-запрос «Echo Request», как Tracert. Такой способ пригодится, если хоп не отвечает на UDP-пакет.

Как использовать Traceroute и Tracert

Если у вас кириллический домен

Кириллические домены необходимо вводить в формате Punycode. Для перевода домена в Punycode воспользуйтесь сервисом.