Як чытаць страты пакетаў, перш чым вінаваціць кабель

Два працэнты страт на працягу доўгага запуску ping здаюцца лічбай, з якой можна нешта рабіць, і гэта рэдка так. Яна не кажа, дзе прапалі адказы, ці прапалі яны разам і як менавіта перажыла гэты інтэрвал пэўная праграма. Страты, раўнамерна размеркаваныя па хвіліне, і страты, сабраныя ўнутры аднаго абмену, даюць вельмі розныя вынікі для аднаго і таго ж працэнта.

Параўнайце тры вымярэнні замест таго, каб давяраць аднаму: што ўбачыў зонд, што зрабілі лічыльнікі інтэрфейса і чаго на самай справе чакала праграма.

Што насамрэч вымярае працэнт ping

Зонд рэха правярае адзін напрамак аднаго пратаколу з адным памерам пакета, з той хуткасцю, якую вы выбралі. Тунель, які нясе вялікую выгрузку, робіць зусім іншае, і канал, які губляе малыя зонды, не абавязкова той канал, які шкодзіць перадачы. Працэнт таксама знішчае інфармацыю пра час, якая найбольш важная, бо дзесяць страчаных адказаў у адным залпе не тое самае, што дзесяць страчаных адказаў з інтэрвалам у гадзіну. Ён таксама не можа сказаць, які бок тунеля нешта страціў.

Трымайце вынік зонда як падказку пра шлях. Затым шукайце час і мяжу, якія яго стварылі.

Параўноўвайце дэльты лічыльнікаў, а не пажыццёвыя сумы

Здыміце адзнакі з адбіткамі часу да і пасля акна, у якім з’явіўся сімптом, на абодвух канцах і на любым порце камутатара, які вы кантралюеце. Запісвайце аб’ём трафіку разам з памылкамі, скідамі і зменамі стану канала, бо ненулявая сума, якая назапасілася за месяцы, апісвае гісторыю, а не гэты інцыдэнт. Лічыльнік, які зрушыўся на тры падчас прастою, — гэта іншае назіранне, чым лічыльнік, які паказвае тры тысячы і ніколі не змяняўся.

ip -s link show dev eth0
nstat -az TcpRetransSegs TcpExtTCPTimeouts
date -u +%Y-%m-%dT%H:%M:%SZ

Пакеты, скінутыя з-за памылак прыёму, і пакеты, скінутыя з іншых прычын, жывуць у асобных лічыльніках, і гэта розніца змяняе наступныя крокі. Лічыльнікі памылак паказваюць на фізічны ўзровень або ўзровень драйвера, а ціск чэргаў і скіды палітыкі — кудысьці вышэй. Захоўвайце таксама напрамак і імя інтэрфейса, бо рост памылак прыёму на ўзыходным канале і лічыльнік пакетаў тунеля не ўзаемазаменныя.

Калі драйвер паказвае падрабязныя фізічныя лічыльнікі, чытайце іх па дакументацыі гэтага адаптара. Прызначэнне аднаго значэння кожнаму полю з назвай “drop” у двух вытворцаў — гэта шлях, якім звычайная асаблівасць уліку ператвараецца ў дыягназ абсталявання.

Як страчаны сегмент робіцца доўгім чаканнем

Праграма можа чакаць значна даўжэй за адзін кругавы шлях пасля страты сегмента. TCP ацэньвае час кругавога шляху, вылічвае з гэтай ацэнкі таймер паўторнай перадачы і адступае, калі паўторная перадача таксама не ўдаецца, таму адзін страчаны сегмент у няўдалы момант можа спыніць запыт на прыкметны інтэрвал. Гэты механізм апісаны ў RFC 6298, і ён тлумачыць, чаму частата страт, якая выглядае дробязнай, усё ж можа адчувацца.

Але не кожная паўза — гэта тайм-аўт паўторнай перадачы. Тое ж чаканне можа прыйсці ад развязання імёнаў, павольнага сервера або праграмы, якая паўтарае свой запыт пасля збою. Аддзяляйце гэтыя выпадкі, сумяшчаючы няўдалую аперацыю з назіраннямі транспарту і з уласнымі падзеямі сесіі тунеля. Перапынак на шляху даных без перападлучэння — гэта іншая падзея, чым свежы ручны абмен і абмен уліковымі данымі.

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

Змяняйце адну мяжу, не рухаючы іншыя

Калі доказы паказваюць на лакальны канал, заменіце ўхвалены кабель або порт як кантраляванае параўнанне і пакіньце ўсё астатняе як ёсць. Трымайце канчатковы пункт, праграму і нагрузку супастаўнымі і змяняйце роўна адну мяжу за спробу. Параўнанне дротавага ноўтбука з бесправодным, калі адначасова мяняюцца выхады і пратаколы, не дае нічога, што можна было б аднесці да прычыны.

Чыстыя лакальныя лічыльнікі не сведчаць пра астатні шлях. Яны абмяжоўваюць тую частку, якую вы бачыце, і сумленны справаздачны запіс кажа, якія межы назіраліся, а якія не. У рэшце рэшт вам патрэбна сцвярджэнне, што адно назіранне змянілася, калі адбылося адно ўмяшанне, а не гісторыя пра дрэнны кабель, узведзеная ва ўніверсальнае правіла.