Содержание

Введение
Характеристики работы сети
Получение статистики работы сети
Использование простых тестов передачи данных через сеть
Диагностика проблемы
Заключение
Ресурсы для скачивания
Похожие темы
Комментарии

Анализ производительности сети в UNIX

Методы быстрого обнаружения проблем производительности в UNIX

Мартин Браун (Martin C. Brown)
Опубликовано 27.12.2010

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

Проблемы производительности также могут повлиять на надежность ваших приложений и оборудования. Они могут быть вызваны ошибками работы сети, а иногда даже сами могут являться причиной таких ошибок. Чтобы выяснить причины проблемы сети, сначала нужно понять природу этой проблемы. Обычно проблема связана либо с задержкой передачи данных (латентностью), либо с пропускной способностью сети.

Зачастую проблемы производительности работы сети обусловлены аппаратными ресурсами, когда скорость работы приложения ограничивается параметрами сетевого оборудования. Проблемы производительности также обычно связаны с определенным протоколом или системой, например NFS, или доступом через Web. С помощью средств операционной системы можно идентифицировать источник проблемы, чтобы далее предпринять соответствующие действия.

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

Определение базового уровня производительности
Определение источника проблемы
Получение статистики
Идентификация узкого места

Характеристики работы сети

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

Латентность сети

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

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

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

Пропускная способность сети

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

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

Например, интерфейс Ethernet с пропускной способностью 1 Гбит/с может передавать 1 Гбит данных на один подключенный к сети компьютер, или по 100 Мбит одновременно на 10 компьютеров, или по 10 Мбит на 100 компьютеров. Разумеется, на практике редко возникают ситуации, когда требуется максимальная пропускная способность сети. На сервер приходит много сотен маленьких запросов с множества различных компьютеров, поэтому поддерживаемая сервером пропускная способность может быть существенно больше суммарной пропускной способности клиентов.

Получение статистики работы сети

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

Тестирование на определение базовой производительности сети следует проводить в контролируемых условиях. В идеале тесты следует выполнить как в изоляции (когда нет другого сетевого трафика), так и при типичной загрузке сети. Это даст вам две базовые оценки.

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

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

Измерение латентности

Программа ping хорошо известна всем сетевым администраторам как простой инструмент проверки доступности и латентности сетевого устройства. Ping посылает устройству ICMP-пакеты и может работать с большинством машин, как с клиентами, так и с серверами, если они сконфигурированы так, чтобы отвечать на ICMP-запросы. Фактически ping посылает устройству эхо-пакет и ожидает, что устройство пришлет ему содержимое этого пакета обратно.

Во время работы ping может отслеживать время, которое проходит между посылкой пакета и получением ответа, и поэтому он является эффективным инструментом измерения времени отклика удаленной системы. В простейшем случае можно посылать на машину эхо-запросы и получать время ответа на них (листинг 1).

Листинг 1. Использование ping для определения латентности

$ ping example

PING example.example.pri (192.168.0.2): 56 data bytes
64 bytes from 192.168.0.2: icmp_seq=0 ttl=64 time=0.169 ms
64 bytes from 192.168.0.2: icmp_seq=1 ttl=64 time=0.167 ms
^C
--- example.example.pri ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.167/0.168/0.169/0.001 ms

Чтобы остановить процесс ping используйте сочетание клавиш Control-C. В Solaris и AIX® для посылки нескольких эхо-пакетов и получения информации о времени их передачи нужно использовать параметр -s. Для получения средней базовой задержки можно с помощью параметра -c (в Linux®) указать количество пакетов. В Solaris/AIX для этого необходимо указать размер пакета (по умолчанию 56 байт) и количество пакетов, которые следует послать, чтобы вам не приходилось вручную завершать процесс. В дальнейшем это можно использовать для автоматического извлечения информации о времени задержки (листинг 2).

Листинг 2. Задаем размер пакета при использовании ping в Solaris/AIX

$ ping -s example 56 10
PING example: 56 data bytes
64 bytes from example.example.pri (192.168.0.2): icmp_seq=0. time=0.143 ms
64 bytes from example.example.pri (192.168.0.2): icmp_seq=1. time=0.163 ms
64 bytes from example.example.pri (192.168.0.2): icmp_seq=2. time=0.146 ms
64 bytes from example.example.pri (192.168.0.2): icmp_seq=3. time=0.134 ms
64 bytes from example.example.pri (192.168.0.2): icmp_seq=4. time=0.151 ms
64 bytes from example.example.pri (192.168.0.2): icmp_seq=5. time=0.107 ms
64 bytes from example.example.pri (192.168.0.2): icmp_seq=6. time=0.142 ms
64 bytes from example.example.pri (192.168.0.2): icmp_seq=7. time=0.136 ms
64 bytes from example.example.pri (192.168.0.2): icmp_seq=8. time=0.143 ms
64 bytes from example.example.pri (192.168.0.2): icmp_seq=9. time=0.103 ms

----example PING Statistics----
10 packets transmitted, 10 packets received, 0% packet loss
round-trip (ms)  min/avg/max/stddev = 0.103/0.137/0.163/0.019

Пример, приведенный в листинге 2, выполнялся в период отсутствия активности в сети. Если бы проверяемая машина (или сама сеть) были заняты во время теста, то время отклика могло оказаться значительно больше. Инструмент ping сам по себе не всегда позволяет обнаружить отклонение от нормы, но иногда его применение помогает быстро понять, есть ли какая-либо проблема, которую нужно проанализировать.

Поскольку ping можно отключать, перед его использованием (для получения времени задержки), необходимо убедиться в том, что машина доступна.

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

Использование sprayd

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

С учетом этого spray можно использовать, чтобы определить, загружена ли сеть большим объемом трафика, так как утеря пакетов, посланных без установления соединения (UDP) может означать, что сеть (или машина) слишком заняты.

Функция Spray есть в Solaris, AIX и некоторых других вариантах UNIX. Для использования spray может быть потребуется включить его демон (обычно с помощь inetd). Когда демон sprayd запущен, можно выполнить spray, указав ему имя машины (листинг 3):

Листинг 3. Использование spray

$ spray tiger
sending 1162 packets of length 86 to tiger ...
        101 packets (8.692%) dropped by tiger
        70 packets/sec, 6078 bytes/sec

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

Использование простых тестов передачи данных через сеть

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

Например, определить пропускную способность сети при передаче файлов с помощью NFS можно с помощью следующего простого теста. Создадим с помощью mkfile большой файл (например, размером 2 ГБ: $ mkfile 2g 2gbfile) и затем замерим, сколько времени занимает его передача по сети на другую машину (листинг 4).

Листинг 4. Замеряем время передачи файла по сети на другую машину

$ time cp /nfs/mysql-live/transient/2gbfile .

real	3m45.648s
user	0m0.010s
sys	0m9.840s

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

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

Листинг 5. Автоматизируем копирование и замер времени с помощью сценария Perl

#!/usr/bin/perl
               
use Benchmark; 
use File::Copy;
use Data::Dumper;
                 
my $file = shift or die "Need a file to copy from\n";
my $srcdir = shift or die "Need a source directory to copy from\n";
my $count = shift || 10;
                        
my $t = timeit($count,sub {copy(sprintf("%s/%s",$srcdir,$file),$file)}); 
                 
printf("Time is %.2fs\n",($t->[0]/$count));

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

Листинг 6. Выполняем сценарий Perl

$ ./timexfer.pl 2gbfile /nfs/mysql-live/transient 20
Time is 28.45s

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

Диагностика проблемы

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

Сначала следует попробовать «достучаться» до машины с помощью ping. Если машина не отвечает на запросы ping, и другие способы связи через сеть также не работают, то в первую очередь нужно проверить кабели и убедиться в физическом наличии сетевого соединения.

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

При большом времени отклика ping, полученном от одной машины, следует выполнить ping какой-нибудь другой машины сети, в идеале находящейся на другом коммутаторе. Это позволит понять, с чем связана эта проблема: с сетью или конкретной машиной.

Проверяем статистику работы сети

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

В Linux получить некоторую базовую статистическую информацию о работе сети можно с помощью инструмента ifconfig (листинг 7).

Листинг 7. Получаем базовую статистическую информацию о сети с помощью ifconfig

$ ifconfig eth1
eth1      Link encap:Ethernet  HWaddr 00:1a:ee:01:01:c0  
          inet addr:192.168.0.2  Bcast:192.168.3.255  Mask:255.255.252.0
          inet6 addr: fe80::21a:eeff:fe01:1c0/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:7916836 errors:0 dropped:78489 overruns:0 frame:0
          TX packets:6285476 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:11675092739 (10.8 GiB)  TX bytes:581702020 (554.7 MiB)
          Interrupt:16 Base address:0x2000

Для нас важными являются строки, начинающиеся с RX и TX, в которых показана информация о посланных и полученных пакетах. Значение packets (пакеты) отображает количество переданных пакетов. Показатели errors (ошибки), dropped (потерянные пакеты) и overruns (переполнения) говорят о том, как много пакетов сигнализирует об определенной ошибке. Если количество потерянных пакетов велико по отношению к количеству посланных пакетов, то это может говорить о загруженности сети.

Также на любой платформе можно получить расширенную статистическую информацию с помощью программы netstat. В Linux этот инструмент предоставляет подробную статистику работы основных протоколов, например информацию о передаче TCP-IP и UDP пакетов. Кроме того, эта информация содержит и некоторую базовую статистику (листинг 8).

Листинг 8. Использование netstat

$ netstat -s
Ip:
    8437387 total packets received
    1 with invalid addresses
    0 forwarded
    0 incoming packets discarded
    8437383 incoming packets delivered
    6820934 requests sent out
    6 reassemblies required
    3 packets reassembled ok
Icmp:
    502 ICMP messages received
    3 input ICMP message failed.
    ICMP input histogram:
        destination unreachable: 410
        echo requests: 82
        echo replies: 10
    1406 ICMP messages sent
    0 ICMP messages failed
    ICMP output histogram:
        destination unreachable: 1313
        echo request: 11
        echo replies: 82
IcmpMsg:
        InType0: 10
        InType3: 410
        InType8: 82
        OutType0: 82
        OutType3: 1313
        OutType8: 11
Tcp:
    8361 active connections openings
    6846 passive connection openings
    1 failed connection attempts
    164 connection resets received
    33 connections established
    8305361 segments received
    6688553 segments send out
    640 segments retransmitted
    0 bad segments received.
    676 resets sent
Udp:
    126083 packets received
    1294 packets to unknown port received.
    0 packet receive errors
    130335 packets sent
UdpLite:
TcpExt:
    5 packets pruned from receive queue because of socket buffer overrun
    6792 TCP sockets finished time wait in fast timer
    5681 delayed acks sent
    Quick ack mode was activated 11637 times
    150861 packets directly queued to recvmsg prequeue.
    74333 bytes directly in process context from backlog
    9141882 bytes directly received in process context from prequeue
    3608274 packet headers predicted
    42627 packets header predicted and directly queued to user
    77132 acknowledgments not containing data payload received
    374105 predicted acknowledgments
    2 times recovered from packet loss by selective acknowledgements
    77 congestion windows recovered without slow start after partial ack
    1 TCP data loss events
    17 timeouts after SACK recovery
    2 fast retransmits
    8 retransmits in slow start
    236 other TCP timeouts
    1453 packets collapsed in receive queue due to low socket buffer
    11634 DSACKs sent for old packets
    2 DSACKs sent for out of order packets
    2 DSACKs received
    77 connections reset due to unexpected data
    50 connections aborted due to timeout
    TCPDSACKIgnoredNoUndo: 1
    TCPSackShiftFallback: 23
IpExt:
    InBcastPkts: 4126

В Solaris и других вариантах UNIX информация, предоставляемая netstat, различается в зависимости от варианта Unix. Например, в Solaris выдается детальная статистика по каждому протоколу и отдельная информация по соединениям IPv4 и IPv6 (листинг 9). В этом листинге результат работы netstat показан в сокращенном виде.

Листинг 9. Использование netstat в Solaris

$ netstat -s

RAWIP   rawipInDatagrams    =   440     rawipInErrors       =     0
        rawipInCksumErrs    =     0     rawipOutDatagrams   =    91
        rawipOutErrors      =     0

UDP     udpInDatagrams      = 15756     udpInErrors         =     0
        udpOutDatagrams     = 16515     udpOutErrors        =     0

TCP     tcpRtoAlgorithm     =     4     tcpRtoMin           =   400
        tcpRtoMax           = 60000     tcpMaxConn          =    -1
        tcpActiveOpens      =  1735     tcpPassiveOpens     =    54
        tcpAttemptFails     =     2     tcpEstabResets      =    35
        tcpCurrEstab        =     2     tcpOutSegs          =13771839
        tcpOutDataSegs      =13975728   tcpOutDataBytes     =1648876686
        tcpRetransSegs      = 90215     tcpRetransBytes     =130340273
        tcpOutAck           =151539     tcpOutAckDelayed    =  5570
        tcpOutUrg           =     0     tcpOutWinUpdate     =    31
        tcpOutWinProbe      =    86     tcpOutControl       =  3750
        tcpOutRsts          =    63     tcpOutFastRetrans   =     6
        tcpInSegs           =7548720
        tcpInAckSegs        =2882026    tcpInAckBytes       =1648874900
        tcpInDupAck         =4413016    tcpInAckUnsent      =     0
        tcpInInorderSegs    =415007     tcpInInorderBytes   =367832646
        tcpInUnorderSegs    =  7650     tcpInUnorderBytes   =10389516
        tcpInDupSegs        =   222     tcpInDupBytes       = 74649
        tcpInPartDupSegs    =     0     tcpInPartDupBytes   =     0
        tcpInPastWinSegs    =     0     tcpInPastWinBytes   =     0
        tcpInWinProbe       =     0     tcpInWinUpdate      =     2
        tcpInClosed         =    33     tcpRttNoUpdate      =   660
        tcpRttUpdate        =2880379    tcpTimRetrans       =  2262
        tcpTimRetransDrop   =    10     tcpTimKeepalive     =   630
        tcpTimKeepaliveProbe=   314     tcpTimKeepaliveDrop =    17
        tcpListenDrop       =     0     tcpListenDropQ0     =     0
        tcpHalfOpenDrop     =     0     tcpOutSackRetrans   = 69348
...

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

Проверяем статистику NFS

Работая над неисправностями, связанными с соединениями NFS, или проблемами большинства других сетевых приложений, в первую очередь следует проверить, не вызваны ли они проблемами на самой машине, например высокой загрузкой центрального процессора (которая, конечно же, влияет на скорость обработки запросов). Простая проверка с помощью uptime и ps может вам сказать, насколько сильно занята данная машина.

Также можно проверить статистику работы сервиса NFS. Команда nfsstat генерирует детальную статистику работы как серверной, так и клиентской части сервиса NFS. Например, в листинге 10 мы выводим детальную статистику работы серверной части протокола NFS v3 сервиса NFS, используя параметры -s (сервер) и -v (версия).

Листинг 10. Вызов команды nfsstat с параметрами `-s` и `-v`

$ nfsstat -s -v3  

Server rpc:
Connection oriented:
calls      badcalls   nullrecv   badlen     xdrcall    dupchecks  dupreqs    
36118      0          0          0          0          410        0          
Connectionless:
calls      badcalls   nullrecv   badlen     xdrcall    dupchecks  dupreqs
75         0          0          0          0          0          0          

Server NFSv3:
calls     badcalls  
35847     0         
Version 3: (35942 calls)
null        getattr     setattr     lookup      access      readlink
15 0%       190 0%      83 0%       3555 9%     21222 59%   0 0%        
read        write       create      mkdir       symlink     mknod       
9895 27%    300 0%      7 0%        0 0%        0 0%        0 0%        
remove      rmdir       rename      link        readdir     readdirplus 
0 0%        0 0%        0 0%        0 0%        37 0%       20 0%       
fsstat      fsinfo      pathconf    commit      
521 1%      2 0%        1 0%        94 0%       

Server nfs_acl:
Version 3: (0 calls)
null        getacl      setacl      getxattrdir 
0 0%        0 0%        0 0%        0 0%

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

Время отклика ping в больших сетях

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

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

Например, в листинге 11 показан полученный с помощью traceroute маршрут передачи пакета между двумя офисами в Великобритании, использующими разные Интернет-провайдеры. В данном случае, ввиду ошибки, пакет не удается доставить до пункта назначения.

Листинг 11. Отслеживаем c помощью traceroute путь пакета между двумя офисами в Великобритании

$ traceroute gendarme.example.com
traceroute to gendarme.example.com (82.70.138.102), 30 hops max, 40 byte packets
 1  voyager.example.pri (192.168.1.1)  14.998 ms  95.530 ms  4.922 ms
 2  dsl.vispa.net.uk (83.217.160.18)  32.251 ms  95.674 ms  30.742 ms
 3  rt-gw1.tcm.vispa.net.uk (62.24.228.1)  49.178 ms  47.718 ms  123.261 ms
 4  195.50.119.249 (195.50.119.249)  47.036 ms  50.440 ms  143.123 ms
 5  ae-11-11.car1.Manchesteruk1.Level3.net (4.69.133.97)  92.398 ms  137.382 ms  
52.780 ms
 6  PACKET-EXCH.car1.Manchester1.Level3.net (195.16.169.90)  45.791 ms  140.165 ms  
35.312 ms
 7  spinoza-ae2-0.hq.zen.net.uk (62.3.80.54)  33.034 ms  39.442 ms  33.253 ms
 8  galileo-fe-3-1-172.hq.zen.net.uk (62.3.80.174)  34.341 ms  33.684 ms  33.703 ms
 9  * * *
10  * * *
11  * * *
12  * * *

В сетях небольшого размера, в которых, скорее всего, нет разделения сети с помощью маршрутизаторов, применение traceroute не принесет пользы. Как ping, так и traceroute, при определении проблемы полагаются на доступность машины в сети.

Теперь вы обладаете некоторыми знаниями и приемами, которые помогут вам решать проблемы производительности в сетях UNIX.

Заключение

Проблемы производительности сети UNIX довольно сложно идентифицировать с отдельного компьютера, особенно с учетом того, что обычно проблема распределена по всей сети. Тем не менее, обычно при помощи инструментов ping и/или traceroute можно сузить область поиска, получая информацию о производительности из разных точек сети. Определив некоторые точки входа, можно с помощью других сетевых инструментов получить более детальную информацию о работе протокола или приложения, вызывающего проблему. В этой статье мы рассмотрели некоторые простые методы получения информации о базовой производительности сети, а затем несколько инструментов, которые можно использовать для анализа проблемы.

Ресурсы для скачивания

этот контент в PDF