4 байта из 32-битного значения передаются в следующем порядке: сначала биты 0 - 7, затем биты 8 - 15, затем 16 - 23 и, наконец, 24 - 31. Такой порядок движения байтов называется big endian (big endian - метод хранения или передачи данных, при котором старший значащий бит или байт стоит первым) и обязателен для всех двоичных целых чисел в TCP заголовках при их передаче по сети. Это называется порядок сетевых байтов (network byte order). Машины, которые хранят двоичные целые в других форматах, как, например, в формате little endian (little endian - метод хранения или передачи данных, при котором младший значащий бит или байт стоит первым), должны конвертировать значения заголовков в соответствующий порядок сетевых байтов перед передачей данных.

Текущая версия протокола - 4, поэтому IP иногда называется IPv4.

Длина заголовка (header length) это количество 32-битных слов в заголовке, включая любые опции. Так как это 4-битное поле, оно ограничивает размер заголовка в 60 байт. В главе 8 мы увидим, что это ограничение сильно влияет на некоторые опции, такие как опция записи маршрута. Обычная величина в этом поле (когда отсутствуют опции) - 5.

Поле типа сервиса (TOS - type-of-service) состоит из 3-битного поля приставки (которое в настоящее время игнорируется), 4 бит TOS и неиспользуемого бита, который должен быть равен 0. 4 бита TOS следующие: минимальная задержка, максимальная пропускная способность, максимальная надежность и минимальная стоимость. Только один из этих 4 бит может быть установлен в единицу одновременно. Если все 4 бита равны 0, это означает обычный сервис.

Поле полной длины (total length) содержит полную длину IP датаграммы в байтах. Благодаря этому полю и полю длины заголовка, мы знаем, с какого места начинаются данные в IP датаграмме и их длину. Так как это поле состоит из 16 бит, максимальный размер IP датаграммы составляет 65535 байт. Это поле может изменяется в момент фрагментации и повторной сборки датаграммы.

Несмотря на то что существует возможность отправить датаграмму размером 65535 байт, большинство канальных уровней поделят подобную датаграмму на фрагменты. Более того, от хоста не требуется принимать датаграмму размером больше чем 576 байт. TCP делит пользовательские данные на части, поэтому это ограничение обычно не оказывает влияния на TCP. Что касается UDP, услугами которого пользуются многие приложения (RIP, TFTP, BOOTP, DNS, SNMP), то он ограничивает себя 512 байтами пользовательских данных, что даже меньше ограничения в 576 байт. Большинство приложений в настоящее время (особенно те, которые поддерживают NFS - Network File System) позволяют использовать IP датаграмму размером 8192 байта.

Однако, поле полной длины требуется в IP заголовке для некоторых каналов (как например, Ethernet), который дополняет маленькие фреймы до минимальной длины. Несмотря на то что минимальный размер фрейма Ethernet составляет 46 байт, IP датаграмма может быть еще меньше. Если поле полной длины не было представлено, IP уровень не будет знать, сколько 46-байтных фреймов Ethernet получится из IP датаграммы.

Поле идентификации (identification) уникально идентифицирует каждую датаграмму, отправленную хостом. Значение, хранящееся в поле, обычно увеличивается на единицу с посылкой каждой датаграммы. Мы обратимся к этому полю, когда будем рассматривать фрагментацию и обратную сборку в разделе "Фрагментация IP" главы 11. Там же мы рассмотрим поле флагов (flags) и поле смещения фрагментации (fragmentation offset).

Поле времени жизни (TTL - time-to-live) содержит максимальное количество пересылок (маршутизаторов), через которые может пройти датаграмма. Это поле ограничивает время жизни датаграммы. Значение устанавливается отправителем (как правило 32 или 64) и уменьшается на единицу каждым маршрутизатором, который обрабатывает датаграмму. Когда значение в поле достигает 0, датаграмма удаляется, а отправитель уведомляется об этом с помощью ICMP сообщения. Подобный алгоритм предотвращает зацикливание пакетов в петлях маршрутизации.

Поле протокола (protocol) указывает, какой протокол отправил данные через IP.

Контрольная сумма заголовка (header checksum) рассчитывается только для IP заголовка. Она не включает в себя данные, которые следуют за заголовком. ICMP, IGMP, UDP и TCP имеют контрольные суммы в своих собственных заголовках, которые охватывают их заголовки и данные.

Чтобы рассчитать контрольную сумму IP для исходящей датаграммы, поле контрольной суммы сначала устанавливается в 0. Затем рассчитывается 16-битная сумма с поразрядным дополнением (One's complement - поразрядное дополнение к двоичной системе.) (заголовок целиком воспринимается как последовательность 16-битных слов). 16-битное поразрядное дополнение этой суммы сохраняется в поле контрольной суммы. Когда IP датаграмма принимается, вычисляется 16-битная сумма с поразрядным дополнением. Так как контрольная сумма, рассчитанная приемником, содержит в себе контрольную сумму, сохраненную отправителем, контрольная сумма приемника состоит из битов равных 1, если в заголовке ничего не было изменено при передаче. Если в результате не получились все единичные биты (ошибка контрольной суммы), IP отбрасывает принятую датаграмму. Сообщение об ошибке не генерируется. Теперь задача верхних уровней каким-либо образом определить, что датаграмма отсутствует, и обеспечить повторную передачу.

ICMP, IGMP, UDP и TCP используют такой же алгоритм расчета контрольной суммы. Также TCP и UDP включают в себя различные поля из IP заголовка, в дополнение к своим собственным заголовкам и данным.

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

Каждая IP датаграмма содержит IP адрес источника (source IP address) и IP адрес назначения (destination IP address).

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

· безопасность и обработка ограничений (для военных приложений),

· запись маршрута (запись каждого маршрута и его IP адрес),

· временная марка (запись каждого маршрута, его IP адрес и время),

· свободная маршрутизация от источника (указывает список IP адресов, через которые должна пройти датаграмма)

· жесткая маршрутизация от источника (то же самое, что и в предыдущем пункте, однако IP датаграмма должна пройти только через указанные в списке адреса).

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

Поле опций всегда ограничено 32 битами. Байты заполнения, значение которых равно 0, добавляются по необходимости. Благодаря этому IP заголовок всегда кратен 32 битам (как это требуется для поля длины заголовка).

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

Маршрутизация - это процесс выбора маршрута следования пакета. Устройство, совершающее этот выбор, называется маршрутизатором. Маршрутизаторы работают на третьем уровне модели OSI. Используя для выбора маршрута лишь адрес сети, а адрес хоста отбрасывает. Чтобы выделить из IP адреса адрес сети, применяется маска сети. Но одними лишь формальными формулировками сыт не будешь. Поэтому будем смотреть более глубже.

Для начала разберем, что же такое маршрут. Маршрут - это направление. Хотя многие привыкли представлять себе сразу весь пройденный путь пакетом, изображая его как последовательность ребер графа (представляющего сеть логически), но с точки зрения отдельного маршрутизатора это немного не так. Каждый маршрутизатор может сказать на какой интерфейс или какому следующему маршрутизатору отправить пакет, таким образом задав направление движение. Собрав последовательно эти направления, мы получим весь путь следования.

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

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

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

Следующее действие - это процесс сравнения адреса сети. Итак, имея таблицу маршрутизации, нам нужно выбрать наилучший маршрут. Для этого существует от двух до трех этапов. Сначала сравнивается адрес сети на наибольшее сходство. Если таких маршрутов несколько, то выбираются маршруты с наименьшей административной дистанцией. И наконец, среди оставшихся выбирается маршрут с наименьшей метрикой. Административная дистанция - это степень доверия источнику. Маршрутизаторы, имеющие один источник динамических маршрутов или производящие лишь статическую маршрутизацию, сравнивают только адреса сетей и метрики. К слову, на каждом компьютере тоже имеется таблица маршрутизации, и когда вы хотите запросить страницу из Internet, компьютер совершает аналогичные действия по выбору маршрута.

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

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

Пусть у нас имеется три маршрута на сети 10.0.1.0/24, 10.0.2.0/24 и 10.0.3.0/24. Причем маршруты на первую и третью сети одинаковы. В этом случае можно уменьшить количество записей таблицы маршрутизации, ускорив этим процесс поиска наилучшего маршрута. Для этого мы объединим первый и третий маршруты, после чего остаются только два маршрута. Причем объединить мы можем любой покрывающей сетью, например, 10.0.0.0/8. Маршрутизация будет продолжать правильно работать, так как для сети 10.0.2.0/24 будет выбран маршрут с наибольшим совпадением (точнее полным) адреса сети, а для остальных адресов из 10.0.0.0/8 будет выбран обобщенный маршрут. Как вы уже заметили, маршрутизатор начинает отправлять пакеты на несуществующие сети (из-за сети 10.0.0.0/8), и, хотя такие пакеты выбросятся дальше, это займет ресурсы маршрутизатора, поэтому может являться плохим подходом. Объединение маршрутов называется префиксной агрегацией или суммаризацией маршрутов.

Различается всего два вида маршрутизации: статическая и динамическая.

Статическая маршрутизация

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

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

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

Динамическая маршрутизация

Динамическая маршрутизация совершается за счет динамических протоколов маршрутизации. При их помощи маршрутизатор строит и обновляет свою таблицу маршрутизации.

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

Динамические протоколы маршрутизации делятся на внешние и внутренние. А внутренние в свою очередь на дистанционно-векторные протоколы и протоколы link state (состояния канала).

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

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

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

На одном маршрутизаторе могут одновременно работать множество протоколов маршрутизации. Они также могут анонсировать одинаковые сети. Представим, что есть сеть, в которой каждый маршрутизатор соединен со всеми остальными (такая топология называется full mesh). Таким образом в одну сеть мы можем попасть разными способами. Но давайте запустим в такой сети разные протоколы маршрутизации, например RIP и EIGRP. Выберем для рассмотрения маршрутизатор, на котором работают оба эти протокола. Проблема состоит в том, что метрика в протоколе RIP может принимать значение от 1 до 15, в то время как в EIGRP она принимает довольно таки внушительные значения. Если сверять метрику, то сети анонсированные протоколом RIP, будут считаться более приоритетными. Выходит, что метрики разных протоколов нельзя сравнивать. И как известно, EIGRP строит более качественные маршруты, поэтому нужен какой-то промежуточный шаг в сравнении маршрутов. Компания Cisco использует для этого понятие административной дистанции. Каждому протоколу присвоено уникальное значение, которое задает степень доверия, и чем оно ниже, тем протокол считается предпочтительней. Поэтому перед сравнением метрики, мы выбираем только один протокол для каждой сети. Но значение административной дистанции для протокола можно и менять на маршрутизаторах Cisco, но это изменение остается в силах только в пределах маршрутизатора.

DHCP (англ. Dynamic Host Configuration Protocol -- протокол динамической конфигурации узла) - это сетевой протокол, позволяющий компьютерам автоматически получать IP-адрес и другие параметры, необходимые для работы в сети TCP/IP. Данный протокол работает по модели «клиент-сервер». Для автоматической конфигурации компьютер-клиент на этапе конфигурации сетевого устройства обращается к т. н. серверу DHCP, и получает от него нужные параметры. Сетевой администратор может задать диапазон адресов, распределяемых сервером среди компьютеров. Это позволяет избежать ручной настройки компьютеров сети и уменьшает количество ошибок. Протокол DHCP используется в большинстве крупных (и не очень) сетей TCP/IP.

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

Стандарт протокола DHCP был принят в октябре 1993 года. Действующая версия протокола (март 1997 года) описана в RFC 2131. Новая версия DHCP, предназначенная для использования в среде IPv6, носит название DHCPv6.

Протокол DHCP предоставляет три способа распределения IP-адресов:

· Ручное распределение. При этом способе сетевой администратор сопоставляет аппаратному адресу (обычно MAC-адресу) каждого клиентского компьютера определённый IP-адрес. Фактически, данный способ распределения адресов отличается от ручной настройки каждого компьютера лишь тем, что сведения об адресах хранятся централизованно (на сервере DHCP), и потому их проще изменять при необходимости.

· Автоматическое распределение. При данном способе каждому компьютеру на постоянное использование выделяется произвольный свободный IP-адрес из определённого администратором диапазона.

· Динамическое распределение. Этот способ аналогичен автоматическому распределению, за исключением того, что адрес выдаётся компьютеру не на постоянное пользование, а на определённый срок. Это называется арендой адреса. По истечении срока аренды IP-адрес вновь считается свободным, и клиент обязан запросить новый (он, впрочем, может оказаться тем же самым).

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

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

Некоторыми из наиболее часто используемых опций являются:

· IP-адрес маршрутизатора по умолчанию;

· маска подсети;

· адреса серверов DNS;

· имя домена DNS.

Некоторые поставщики программного обеспечения могут определять собственные, дополнительные опции DHCP.

Протокол DHCP является клиент-серверным, то есть в его работе участвуют клиент DHCP и сервер DHCP. Передача данных производится при помощи протокола UDP, при этом сервер принимает сообщения от клиентов на порт 67 и отправляет сообщения клиентам на порт 68.

Все сообщения протокола DHCP разбиваются на поля, каждое из которых содержит определённую информацию. Все поля, кроме последнего (поля опций DHCP), имеют фиксированную длину.

Поле	Описание	Длина (в байтах)
op	Тип сообщения. Может принимать два значения: BOOTREQUEST (1, запрос от клиента к серверу) и BOOTREPLY (2, ответ от сервера к клиенту).	1
htype	Тип аппаратного адреса. Например, для MAC-адреса Ethernet 10 Мбит/с это поле принимает значение 1.	1
hlen	Длина аппаратного адреса в байтах. Для MAC-адреса Ethernet - 6.	1
hops	Количество промежуточных маршрутизаторов (так называемых агентов ретрансляции DHCP), через которые прошло сообщение. Клиент устанавливает это поле в 0.	1
xid	Уникальный идентификатор транзакции, генерируемый клиентом в начале процесса получения адреса.	4
secs	Время в секундах с момента начала процесса получения адреса. Может не использоваться (в этом случае оно устанавливается в 0).	2
flags	Поле для флагов -- специальных параметров протокола DHCP.	2
ciaddr	IP-адрес клиента. Заполняется только в том случае, если клиент уже имеет собственный IP-адрес и способен отвечать на запросы ARP (это возможно, если клиент выполняет процедуру обновления адреса по истечении срока аренды).	4
yiaddr	'your' (client) IP address	4
siaddr	IP-адрес сервера. Возвращается в предложении DHCP (см. ниже).	4
giaddr	IP-адрес агента ретрансляции, если таковой участвовал в процессе доставки сообщения DHCP до сервера.	4
chaddr	Аппаратный адрес (обычно MAC-адрес) клиента.	16
sname	Необязательное имя сервера в виде нуль-терминированной строки.	64
file	Необязательное имя файла на сервере, используемое бездисковыми рабочими станциями при удалённой загрузке. Как и sname, представлено в виде нуль-терминированной строки.	128
options	Поле опций DHCP. Здесь указываются различные дополнительные параметры конфигурации. В начале этого поля указываются четыре особых байта со значениями 99, 130, 83, 99 («волшебные числа»), позволяющие серверу определить наличие этого поля.	переменная

Рассмотрим пример процесса получения IP-адреса клиентом от сервера DHCP. Предположим, клиент ещё не имеет собственного IP-адреса, но ему известен его предыдущий адрес -- 192.168.1.100. Процесс состоит из четырёх этапов.

Обнаружение DHCP. В начале клиент выполняет широковещательный запрос по всей физической сети с целью обнаружить доступные DHCP-серверы. Он отправляет сообщение типа DHCPDISCOVER, при этом в качестве IP-адреса источника указывается 0.0.0.0 (так как компьютер ещё не имеет собственного IP-адреса), а в качестве адреса назначения -- широковещательный адрес 255.255.255.255.

Клиент заполняет несколько полей сообщения начальными значениями:

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

· В поле chaddr помещается аппаратный адрес (MAC-адрес) клиента.

· В поле опций указывается последний известный клиенту IP-адрес. В данном примере это 192.168.1.100. Это необязательно и может быть проигнорировано сервером.

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

Предложение DHCP. Получив сообщение от клиента, сервер определяет требуемую конфигурацию клиента в соответствии с указанными сетевым администратором настройками. В данном случае DHCP-сервер согласен с запрошенным клиентом адресом 192.168.1.100. Сервер отправляет ему ответ (DHCPOFFER), в котором предлагает конфигурацию. Предлагаемый клиенту IP-адрес указывается в поле yiaddr. Прочие параметры (такие, как адреса маршрутизаторов и DNS-серверов) указываются в виде опций в соответствующем поле.

Это сообщение DHCP-сервер отправляет хосту пославшему (DHCPDISCOVER) на его MAC, при определенных обстоятельствах может распространяться, как широковещательная рассылка. Клиент может получить несколько различных предложений DHCP от разных серверов; из них он должен выбрать то, которое его «устраивает».

Запрос DHCP. Выбрав одну из конфигураций, предложенных DHCP-серверами, клиент отправляет запрос DHCP (DHCPREQUEST). Он рассылается широковещательно; при этом к опциям, указанным клиентом в сообщении DHCPDISCOVER, добавляется специальная опция -- идентификатор сервера -- указывающая адрес DHCP-сервера, выбранного клиентом (в данном случае -- 192.168.1.1).

Подтверждение DHCP. Наконец, сервер подтверждает запрос и направляет это подтверждение (DHCPACK) клиенту. После этого клиент должен настроить свой сетевой интерфейс, используя предоставленные опции.

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

Отказ DHCP. Если после получения подтверждения (DHCPACK) от сервера клиент обнаруживает, что указанный сервером адрес уже используется в сети, он рассылает широковещательное сообщение отказа DHCP (DHCPDECLINE), после чего процедура получения IP-адреса повторяется. Использование IP-адреса другим клиентом можно обнаружить, выполнив запрос ARP.

Отмена DHCP. Если по каким-то причинам сервер не может предоставить клиенту запрошенный IP-адрес, или если аренда адреса удаляется администратором, сервер рассылает широковещательное сообщение отмены DHCP (DHCPNAK). При получении такого сообщения соответствующий клиент должен повторить процедуру получения адреса.

Освобождение DHCP. Клиент может явным образом прекратить аренду IP-адреса. Для этого он отправляет сообщение освобождения DHCP (DHCPRELEASE) тому серверу, который предоставил ему адрес в аренду. В отличие от других сообщений DHCP, DHCPRELEASE не рассылается широковещательно.

Информация DHCP. Сообщение информации DHCP (DHCPINFORM) предназначено для определения дополнительных параметров TCP/IP (например, адреса маршрутизатора по умолчанию, DNS-серверов и т. п.) теми клиентами, которым не нужен динамический IP-адрес (то есть адрес которых настроен вручную). Серверы отвечают на такой запрос сообщением подтверждения (DHCPACK) без выделения IP-адреса.

7. Протокол TCP

Transmission Control Protocol (TCP) (протокол управления передачей) -- один из основных сетевых протоколов Интернет, предназначенный для управления передачей данных в сетях и подсетях TCP/IP.

Выполняет функции протокола транспортного уровня модели OSI.

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

Реализация TCP, как правило, встроена в ядро системы, хотя есть и реализации TCP в контексте приложения.

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

Формат TCP-сегмента
Бит	0 -- 3	4 -- 9	10 -- 15	16 -- 31
0	Порт источника	Порт назначения
32	Номер последовательности
64	Номер подтверждения
96	Смещение данных	Зарезервировано	Флаги	Окно
128	Контрольная сумма	Указатель важности
160	Опции (необязательное)
160/192+	Данные

Порт источника. Порт источника идентифицирует порт, с которого отправлены пакеты.

Порт назначения. Порт назначения идентифицирует порт, на который отправлен пакет.

TCP-порты. Существует набор сервисов (использующих для передачи данных TCP), за которыми закреплены определенные порты:

· 21 -- FTP

· 23 -- Telnet

· 25 -- SMTP

· 80 -- HTTP

· 110 -- POP3

· 194 -- IRC (Internet Relay Chat)

· 443 -- HTTPS (Secure HTTP)

· 1863 -- MSN Messenger

· 2000 -- Cisco SCCP (VoIP)

· 8008 -- alternate HTTP

· 8080 -- alternate HTTP

Номер последовательности. Номер последовательности выполняет две задачи:

1. Если установлен флаг SYN, то это начальное значение номера последовательности и первый байт данных -- это номер последовательности плюс 1.

2. В противном случае, если SYN не установлен, первый байт данных -- номер последовательности

Поскольку TCP-поток в общем случае может быть длиннее, чем число различных состояний этого поля, то все операции с номером последовательности должны выполняться по модулю 2^32. Это накладывает практическое ограничение на использование TCP. Если скорость передачи коммуникационной системы такова, чтобы в течение MSL (максимального времени жизни сегмента) произошло переполнение номера последовательности, то в сети может появиться два сегмента с одинаковым номером, относящихся к разным частям потока, и приёмник получит некорректные данные.

Номер подтверждения. Если установлен флаг ACK, то это поле содержит номер последовательности, ожидаемый получателем в следующий раз. Помечает этот сегмент как подтверждение получения.

Смещение данных. Это поле определяет размер заголовка пакета TCP в 32-битных словах. Минимальный размер составляет 5 слов, а максимальный -- 15, что составляет 20 и 60 байт соответственно. Смещение считается от начала заголовка TCP.

Зарезервирован. Зарезервировано (6 бит) для будущего использования и должны устанавливаться в ноль. Из них два (7-й и 8-й) уже определены:

· CWR (Congestion Window Reduced) -- Поле «Окно перегрузки уменьшено» -- флаг установлен отправителем, чтоб указать, что получен пакет с установленным флагом ECE.

· ECE (ECN-Echo) -- Поле «Эхо ECN» -- указывает, что данный хост способен на ECN (явное уведомление перегрузки) и для указания отправителю о перегрузках в сети.

Флаги (управляющие биты). Это поле содержит 6 битовых флагов:

· URG -- Поле "Указатель важности" задействовано (англ. Urgent pointer field is significant)

· ACK -- Поле "Номер подтверждения" задействовано (англ. Acknowledgement field is significant)

· PSH -- (англ. Push function) инструктирует получателя протолкнуть данные, накопившиеся в приемном буфере, в приложение пользователя

· RST -- Оборвать соединения, сбросить буфер (очистка буфера) (англ. Reset the connection)

· SYN -- Синхронизация номеров последовательности (англ. Synchronize sequence numbers)

· FIN (англ. final, бит) -- флаг, будучи установлен, указывает на завершение соединения (англ. FIN bit used for connection termination).

Контрольная сумма. Поле контрольной суммы -- это 16-битное дополнение суммы всех 16-битных слов заголовка и текста. Если сегмент содержит нечетное число октетов в заголовке или тексте, последние октеты дополняются справа 8 нулями для выравнивания по 16-битовой границе. Биты заполнения (0) не передаются в сегменте и служат только для расчёта контрольной суммы. При расчёте контрольной суммы значение самого поля контрольной суммы принимается равным 0.

Указатель важности. 16-битовое значение положительного смещения от порядкового номера в данном сегменте. Это поле указывает порядковый номер октета которым заканчиваются важные (urgent) данные. Поле принимается во внимание только для пакетов с установленным флагом URG.

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

· Установка соединения

· Передача данных

· Завершение соединения

Состояния сеанса TCP

CLOSED Начальное состояние узла. Фактически фиктивное

LISTEN Сервер ожидает запросов установления соединения от клиента

SYN-SENT Клиент отправил запрос серверу на установление соединения и ожидает ответа

SYN-RECEIVED Сервер получил запрос на соединение, отправил ответный запрос и ожидает подтверждения

ESTABLISHED Соединение установлено, идёт передача данных

FIN-WAIT-1 Одна из сторон (назовём её узел-1) завершает соединение, отправив сегмент с флагом FIN

CLOSE-WAIT Другая сторона (узел-2) переходит в это состояние, отправив, в свою очередь сегмент ACK и продолжает одностороннюю передачу

FIN-WAIT-2 Узел-1 получает ACK, продолжает чтение и ждёт получения сегмента с флагом FIN

LAST-ACK Узел-2 заканчивает передачу и отправляет сегмент с флагом FIN

TIME-WAIT Узел-1 получил сегмент с флагом FIN, отправил сегмент с флагом ACK и ждёт 2*MSL секунд, перед окончательным закрытием соединения

CLOSING Обе стороны инициировали закрытие соединения одновременно: после отправки сегмента с флагом FIN узел-1 также получает сегмент FIN, отправляет ACK и находится в ожидании сегмента ACK (подтверждения на свой запрос о разъединении)

8. Система DNS

DNS (англ. Domain Name System - система доменных имён) - компьютерная распределённая система для получения информации о доменах. Чаще всего используется для получения IP-адреса по имени хоста (компьютера или устройства), получения информации о маршрутизации почты, обслуживающих узлах для протоколов в домене (SRV-запись).

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

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

DNS обладает следующими характеристиками:

· Распределённость хранения информации. Каждый узел сети в обязательном порядке должен хранить только те данные, которые входят в его зону ответственности и (возможно) адреса корневых DNS-серверов.

· Кеширование информации. Узел может хранить некоторое количество данных не из своей зоны ответственности для уменьшения нагрузки на сеть.

· Иерархическая структура, в которой все узлы объединены в дерево, и каждый узел может или самостоятельно определять работу нижестоящих узлов, или делегировать (передавать) их другим узлам.

· Резервирование. За хранение и обслуживание своих узлов (зон) отвечают (обычно) несколько серверов, разделённые как физически, так и логически, что обеспечивает сохранность данных и продолжение работы даже в случае сбоя одного из узлов.

DNS важна для работы Интернета, ибо для соединения с узлом необходима информация о его IP-адресе, а для людей проще запоминать буквенные (обычно осмысленные) адреса, чем последовательность цифр IP-адреса. В некоторых случаях это позволяет использовать виртуальные серверы, например, HTTP-серверы, различая их по имени запроса. Первоначально преобразование между доменными и IP-адресами производилось с использованием специального текстового файла HOSTS, который составлялся централизованно и обновлялся на каждой из машин сети вручную. С ростом Сети возникла необходимость в эффективном, автоматизированном механизме, которым и стала DNS.

DNS была разработана Полом Мокапетрисом в 1983 году. В 1987 была изменена спецификация DNS, а также были добавлены дополнительные возможности в базовые протоколы.

Дополнительные возможности

· поддержка динамических обновлений

· безопасные соединения (DNSSEC)

· поддержка различных типов информации (SRV-записи)

Ключевыми понятиями DNS являются:

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

Домен - название зоны в системе доменных имён (DNS) Интернета, выделенной какой-либо стране, организации или для иных целей. Структура доменного имени отражает порядок следования зон в иерархическом виде; доменное имя читается слева направо от младших доменов к доменам высшего уровня (в порядке повышения значимости), корневым доменом всей системы является точка ('.'), следом идут домены первого уровня (географические или тематические), затем - домены второго уровня, третьего и т. д. (например, для адреса ru.wikipedia.org домен первого уровня - org, второго wikipedia, третьего ru). На практике точку в конце имени часто опускают, но она бывает важна в случаях разделения между относительными доменами и FQDN (англ. Fully Qualifed Domain Name, полностью определённое имя домена).

Поддомен (англ. subdomain) - имя подчинённой зоны. (например, wikipedia.org - поддомен домена org, а ru.wikipedia.org - домена wikipedia.org). Теоретически такое деление может достигать глубины 127 уровней, а каждая метка может содержать до 63 символов, пока общая длина вместе с точками не достигнет 254 символов. Но на практике регистраторы доменных имён используют более строгие ограничения.

DNS-сервер - специализированное ПО для обслуживания DNS. DNS-сервер может быть ответственным за некоторые зоны и/или может перенаправлять запросы вышестоящим серверам.

DNS-клиент - специализированная библиотека (или программа) для работы с DNS. В ряде случаев DNS-сервер выступает в роли DNS-клиента.

Ответственность (англ. authoritative) - признак размещения зоны на DNS-сервере. Ответы DNS-сервера могут быть двух типов: ответственные (когда сервер заявляет, что сам отвечает за зону) и неответственные (англ. Non-authoritative), когда сервер обрабатывает запрос, и возвращает ответ других серверов. В некоторых случаях вместо передачи запроса дальше DNS-сервер может вернуть уже известное ему (по запросам ранее) значение (режим кеширования).

DNS-запрос (англ. DNS query) - запрос от клиента (или сервера) серверу. Запрос может быть рекурсивным или нерекурсивным. Нерекурсивный запрос либо возвращает данные о зоне, которая находится в зоне ответственности DNS-сервера (который получил запрос) или возвращает адреса корневых серверов (точнее, адрес любого сервера, который обладает большим объёмом информации о запрошенной зоне, чем отвечающий сервер). В случае рекурсивного запроса сервер опрашивает серверы (в порядке убывания уровня зон в имени), пока не найдёт ответ или не обнаружит, что домен не существует. На практике поиск начинается с наиболее близких к искомому DNS-серверов, если информация о них есть в кеше и не устарела, сервер может не запрашивать DNS-серверы). Рекурсивные запросы требуют больше ресурсов от сервера (и создают больше трафика), так что обычно принимаются от «известных» владельцу сервера узлов (например, провайдер предоставляет возможность делать рекурсивные запросы только своим клиентам, в корпоративной сети рекурсивные запросы принимаются только из локального сегмента). Нерекурсивные запросы обычно принимаются ото всех узлов сети (и осмысленный ответ даётся только на запросы о зоне, которая размещена на узле, на DNS-запрос о других зонах обычно возвращаются адреса корневых серверов).

Субдомен - дополнительное доменное имя 3-го уровня в основном домене. Может указывать как на документы корневого каталога, так и на любой подкаталог основного сервера. Например, если у вас есть домен вида mydomain.ru, вы можете создать для него различные поддомены вида mysite1.mydomain.ru, mysite2.mydomain.ru и т. д.

Система DNS содержит иерархию серверов DNS. Каждый домен или поддомен поддерживается как минимум одним авторитетным сервером DNS (от англ. authoritative -- авторитетный, заслуживающий доверия; в Рунете применительно к DNS и серверам имен часто употребляют и другие варианты перевода: авторизированный, авторитативный), на котором расположена информация о домене. Иерархия серверов DNS совпадает с иерархией доменов.

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

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

Протокол DNS использует для работы TCP- или UDP-порт 53 для ответов на запросы. Традиционно запросы и ответы отправляются в виде одной UDP датаграммы. TCP используется для AXFR-запросов.

Рассмотрим на примере работу всей системы.

Предположим, мы набрали в браузере адрес ru.wikipedia.org. Браузер спрашивает у сервера DNS: «какой IP-адрес у ru.wikipedia.org»? Однако, сервер DNS может ничего не знать не только о запрошенном имени, но даже обо всём домене wikipedia.org. В этом случае имеет место рекурсия: сервер обращается к корневому серверу -- например, 198.41.0.4. Этот сервер сообщает -- «У меня нет информации о данном адресе, но я знаю, что 204.74.112.1 является авторитетным для зоны org.» Тогда сервер DNS направляет свой запрос к 204.74.112.1, но тот отвечает «У меня нет информации о данном сервере, но я знаю, что 207.142.131.234 является авторитетным для зоны wikipedia.org.» Наконец, тот же запрос отправляется к третьему DNS-серверу и получает ответ - IP-адрес, который и передаётся клиенту - браузеру.

В данном случае при разрешении имени, то есть в процессе поиска IP по имени:

· браузер отправил известному ему DNS-серверу т. н. рекурсивный запрос -- в ответ на такой тип запроса сервер обязан вернуть «готовый результат», то есть IP-адрес, либо сообщить об ошибке;

· DNS-сервер, получив запрос от клиента, последовательно отправлял итеративные запросы, на которые получал от других DNS-серверов ответы, пока не получил авторитетный ответ от сервера, ответственного за запрошенную зону.

В принципе, запрошенный сервер, мог бы передать рекурсивный запрос «вышестоящему» DNS-серверу и дождаться готового ответа.

Запрос на определение имени обычно не идёт дальше кэша DNS, который сохраняет ответы на запросы, проходившие через него ранее. Вместе с ответом приходит информация о том, сколько времени разрешается хранить эту запись в кэше.

DNS используется в первую очередь для преобразования символьных имён в IP-адреса, но он также может выполнять обратный процесс. Для этого используются уже имеющиеся средства DNS. Дело в том, что с записью DNS могут быть сопоставлены различные данные, в том числе и какое-либо символьное имя. Существует специальный домен in-addr.arpa, записи в котором используются для преобразования IP-адресов в символьные имена. Например, для получения DNS-имени для адреса 11.22.33.44 можно запросить у DNS-сервера запись 44.33.22.11.in-addr.arpa, и тот вернёт соответствующее символьное имя. Обратный порядок записи частей IP-адреса объясняется тем, что в IP-адресах старшие биты расположены в начале, а в символьных DNS-именах старшие (находящиеся ближе к корню) части расположены в конце.

Наиболее важные типы DNS-записей:

· Запись A (address record) или запись адреса связывает имя хоста с адресом IP. Например, запрос A-записи на имя referrals.icann.org вернет его IP адрес -- 192.0.34.164

· Запись AAAA (IPv6 address record) связывает имя хоста с адресом протокола IPv6. Например, запрос AAAA-записи на имя K.ROOT-SERVERS.NET вернет его IPv6 адрес -- 2001:7fd::1

· Запись CNAME (canonical name record) или каноническая запись имени (псевдоним) используется для перенаправления на другое имя

· Запись MX (mail exchange) или почтовый обменник указывает сервер(ы) обмена почтой для данного домена.

· Запись NS (name server) указывает на DNS-сервер для данного домена.

· Запись PTR (pointer) или запись указателя связывает IP хоста с его каноническим именем. Запрос в домене in-addr.arpa на IP хоста в reverse форме вернёт имя (FQDN) данного хоста (см. Обратный DNS-запрос). Например, (на момент написания), для IP адреса 192.0.34.164: запрос записи PTR 164.34.0.192.in-addr.arpa вернет его каноническое имя referrals.icann.org. В целях уменьшения объёма нежелательной корреспонденции (спама) многие серверы-получатели электронной почты могут проверять наличие PTR записи для хоста, с которого происходит отправка. В этом случае PTR запись для IP адреса должна соответствовать имени отправляющего почтового сервера, которым он представляется в процессе SMTP сессии.

· Запись SOA (Start of Authority) или начальная запись зоны указывает, на каком сервере хранится эталонная информация о данном домене, содержит контактную информацию лица, ответственного за данную зону, тайминги кеширования зонной информации и взаимодействия DNS-серверов.

· Запись SRV (server selection) указывает на серверы для сервисов, используется, в частности, для Jabber.

Зарезервированные доменные имена

Документ RFC 2606 (Reserved Top Level DNS Names -- Зарезервированные имена доменов верхнего уровня) определяет названия доменов, которые следует использовать в качестве примеров (например, в документации), а также для тестирования. Кроме example.com, example.org и example.net, в эту группу также входят test, invalid и др.

Доменное имя может состоять только из ограниченного набора ASCII символов, позволяя набрать адрес домена независимо от языка пользователя. ICANN утвердил основанную на Punycode систему IDNA, преобразующую любую строку в кодировке Unicode в допустимый DNS набор символов.

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

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

9. Практическая часть

9.1 Создание физической и логической топологии компьютерной сети для предприятия

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

В приложении 2 приведена физическая топология компьютерной сети и план помещения.

9.2 Обоснование тех или иных сред передачи данных между сегментами сети

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

Для обеспечения связи с удалённым офисом выбрана беспроводная среда передачи данных и технология WiFi. Выбор обоснован тем, что удаление офиса составляет 5-6 км, и прокладка оптоволоконного кабеля будет экономически невыгодна. Кроме того, к качеству и скорости соединения не предъявляется высоких требований.

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

9.3 Расчёт сети

Исходные данные задания: количество узлов сети - 100; количество подсетей - 10; максимальное количество узлов в подсети - 10; настроить узлы в подсетях: 1) 1, 2, 5, 7, 9 2) 3, 4, 5, 6, 7

Возьмём за исходную сеть для расчётов сеть с адресом 192.168.1.0 и маской подсети 255.255.255.0 (/24). Данная сеть позволяет адресовать 254 узла максимум. Запишем маску подсети в двоичном виде:

11111111.11111111.11111111.00000000

Чтобы выделить в данной сети подсети, нужно в последнем октете часть старших бит использовать для нумерации подсетей. Число 10 умещается в 4 бита (2⁴ = 16 > 10). Поэтому четырём старшим битам последнего октета присвоим 1 - это будет означать, что данный бит является частью номера сети. В итоге получим следующую маску подсети:

11111111.11111111.11111111.11110000

Комбинация IP-адреса и маски подсети в двоичном виде будет выглядеть так:

11000000.10101000.00000001.00000000

11111111.11111111.11111111.11110000

Определим адреса подсетей, а также адреса узлов в подсетях.

Подсеть №1
Адрес подсети	11000000.10101000.00000001.00010000 192.168.1.16
Маска подсети	11111111.11111111.11111111.11110000 255.255.255.240 /28
Широковещательный адрес	11000000.10101000.00000001.00011111 192.168.1.31
Адреса узлов
Узел 1	192.168.1.17
Узел 2	192.168.1.18
Узел 3	192.168.1.19
…	…
Узел 10	192.168.1.26

Подсеть №2
Адрес подсети	11000000.10101000.00000001.00100000 192.168.1.32
Маска подсети	11111111.11111111.11111111.11110000 255.255.255.240 /28
Широковещательный адрес	11000000.10101000.00000001.00101111 192.168.1.47
Адреса узлов
Узел 1	192.168.1.33
Узел 2	192.168.1.34
Узел 3	192.168.1.35
…	…
Узел 10	192.168.1.42

Подсеть №3
Адрес подсети	11000000.10101000.00000001.00110000 192.168.1.48
Маска подсети	11111111.11111111.11111111.11110000 255.255.255.240 /28
Широковещательный адрес	11000000.10101000.00000001.00111111 192.168.1.63
Адреса узлов
Узел 1	192.168.1.49
Узел 2	192.168.1.50
Узел 3	192.168.1.51
…	…
Узел 10	192.168.1.58

Подсеть №4
Адрес подсети	11000000.10101000.00000001.01000000 192.168.1.64
Маска подсети	11111111.11111111.11111111.11110000 255.255.255.240 /28
Широковещательный адрес	11000000.10101000.00000001.01001111 192.168.1.79
Адреса узлов
Узел 1	192.168.1.65
Узел 2	192.168.1.66
Узел 3	192.168.1.67
…	…
Узел 10	192.168.1.74

Подсеть №5
Адрес подсети	11000000.10101000.00000001.01010000 192.168.1.80
Маска подсети	11111111.11111111.11111111.11110000 255.255.255.240 /28
Широковещательный адрес	11000000.10101000.00000001. 01011111 192.168.1.95
Адреса узлов
Узел 1	192.168.1.81
Узел 2	192.168.1.82
Узел 3	192.168.1.83
Узел 10	192.168.1.90

Подсеть №6
Адрес подсети	11000000.10101000.00000001.01100000 192.168.1.96
Маска подсети	11111111.11111111.11111111.11110000 255.255.255.240 /28
Широковещательный адрес	11000000.10101000.00000001.01101111 192.168.1.111
Адреса узлов
Узел 1	192.168.1.97
Узел 2	192.168.1.98
Узел 3	192.168.1.99
…	…
Узел 10	192.168.1.106

Подсеть №7
Адрес подсети	11000000.10101000.00000001.01110000 192.168.1.112
Маска подсети	11111111.11111111.11111111.11110000 255.255.255.240 /28
Широковещательный адрес	11000000.10101000.00000001.01111111 192.168.1.127
Адреса узлов
Узел 1	192.168.1.112
Узел 2	192.168.1.113
Узел 3	192.168.1.114
…	…
Узел 10	192.168.1.121

Подсеть №8
Адрес подсети	11000000.10101000.00000001.10000000 192.168.1.128
Маска подсети	11111111.11111111.11111111.11110000 255.255.255.240 /28
Широковещательный адрес	11000000.10101000.00000001.10001111 192.168.1.143
Адреса узлов
Узел 1	192.168.1.129
Узел 2	192.168.1.130
Узел 3	192.168.1.131
Узел 10	192.168.1.138

Подсеть №9
Адрес подсети	11000000.10101000.00000001.10010000 192.168.1.144
Маска подсети	11111111.11111111.11111111.11110000 255.255.255.240 /28
Широковещательный адрес	11000000.10101000.00000001.10011111 192.168.1.159
Адреса узлов
Узел 1	192.168.1.145
Узел 2	192.168.1.146
Узел 3	192.168.1.147
…	…
Узел 10	192.168.1.154
Подсеть №10
Адрес подсети	11000000.10101000.00000001.10100000 192.168.1.160
Маска подсети	11111111.11111111.11111111.11110000 255.255.255.240 /28
Широковещательный адрес	11000000.10101000.00000001.10101111 192.168.1.175
Адреса узлов
Узел 1	192.168.1.161
Узел 2	192.168.1.162
Узел 3	192.168.1.163
…	…
Узел 10	192.168.1.170