Какие N основных инструментов / методологий используются для диагностики и устранения сетевых проблем?
Например, в локальной сети, где пользователи могут постоянно подключаться к внешнему серверу, но любые соединения с интенсивным использованием данных нестабильны; как бы вы начали решать проблемы с сетью?
Я полагаю, что такие факторы, как перегрузка, ограничения полосы пропускания, ограничения пропускной способности и т. Д., Являются факторами, но я не знаю, как диагностировать эти проблемы.
Меня особенно интересуют среды LAN (а не WAN)
Это очень обширная тема, но для начала отметим, что сниффер сети \ пакетов - бесценный инструмент. Доступно много. Я обычно использую несколько инструментов в зависимости от типа сетевой проблемы. Я использую Wireshark в основном для устранения проблем между двумя конкретными устройствами (клиент-сервер, сервер-сервер и т. Д.), А также Colasoft Capsa для устранения проблем с перегрузкой и использованием. Wireshark очень хорош в отображении основных моментов сетевых разговоров, но может быть немного ошеломляющим при попытке «визуализировать» общую проблему перегрузки или использования. Colasoft Capsa намного лучше подходит для «визуального» взгляда на проблему.
Если вы испытываете медленную сетевую связь \ производительность (из-за перегрузки и \ или использования), вам нужно поискать следующее:
Большое количество сетевых широковещательных рассылок (либо на сетевом уровне, либо на физическом уровне) и \ или большое количество повторных передач TCP и медленных подтверждений.
Большое количество широковещательных рассылок может указывать на неправильно настроенную или неисправную сетевую карту, хост, коммутатор, программное обеспечение, драйвер и т. Д., А также может указывать на заражение вредоносным ПО где-то в сети. Широковещательные передачи могут вызывать перегрузку и, в свою очередь, высокую загрузку сетевых каналов (портов коммутатора), поскольку каждый хост должен прослушивать широковещательный трафик, чтобы определить, предназначен ли этот трафик для себя.
Повторные передачи TCP и медленные подтверждения также указывают на перегрузку сети. Перегрузка приводит к медленной передаче и получению пакетов и к тому, что ACK принимаются "поздно", вынуждая передающий хост повторно передать пакет, для которого он ожидает ACK. Если у вас есть перегрузка, которая является причиной повторных передач и медленных подтверждений, вы можете быть уверены, что это вызывает проблемы с производительностью.
Я использовал mtr (traceroute на основе экрана linux) с медленной скоростью пинга (от 1 до 2) в минуту для отслеживания реакции на конечную точку. Если один или несколько коммутаторов перегружены, они показывают пропущенные эхо-запросы или медленные ответы. Это может быть результатом проблем с дуплексом.
При некоторых условиях я видел, как маршрутизаторы Cisco работают в полудуплексном режиме на каналах, жестко закодированных в полнодуплексный режим. Проблемы двусторонней печати можно проверить, передав большой файл в обе стороны. В одном направлении он будет намного медленнее, чем в другом. Это сделало установку пакетов по сети невозможной.
Может оказаться полезным сброс счетчиков ошибок на всех интерфейсах (хост и маршрутизатор). Счетчики ошибок должны иметь нулевое или низкое значение и не увеличиваться с заметной скоростью.
Если вы испытываете замедление передачи TCP с интенсивным использованием данных, вы МОЖЕТЕ страдать от «глобальной синхронизации», когда все участники TCP на линии в конечном итоге примерно синхронно увеличивают размер окна TCP (количество оставшихся байтов, разрешенное до получен ACK).
Чем больше окно передачи TCP, тем быстрее данные перекачиваются между A и B. Когда у вас есть несколько хостов, отправляющих TCP (в одном направлении) по одному каналу, пропускная способность, используемая для этого канала, будет колебаться в зависимости от размера окна все хозяева. Когда канал не перегружен, размер окна TCP будет увеличиваться до тех пор, пока пакеты не начнут сбрасываться (обычно для всех сеансов TCP одновременно), а размер окна TCP не будет установлен на самый низкий размер, который может быть, разгрузка канала. Затем, когда нет места перегрузки, все отправители синхронно увеличивают размер окна.
Если вы посмотрите на график использования коротких интервалов, это должно быть очевидно по нарастанию и резкому падению «пилы», когда используется полная пропускная способность канала. Возможно, вам понадобится что-то, что будет опрашивать использование вашего WAN-соединения чаще, чем каждые пять минут, я бы сказал, что поминутной статистики может быть достаточно, но вам, возможно, придется опускаться до каждые 5-10 секунд.
Наилучший из известных мне способов устранить это - включить взвешенное случайное раннее отбрасывание, по существу отбрасывая пакеты до того, как канал WAN будет перегружен, чтобы окна TCP для всех хостов в локальной сети были отделены друг от друга.
не уверен, что ваш дом с окнами, но следующий блог будет полезен также получить анализатор tcp от MS Research, это довольно круто.