5.4. TCP/IP

TCP/IP - это соответствующий промышленным стандартам набор протоколов, предназначенный для поддержки межсетевых связей между региональными сетями (WAN). TCP/IP разработан в 1969 году Управлением ARPA (Advanced Research Projects Agency) Министерства обороны США для экспериментальной сети, известной под названием ARPANET (ARPA Network). Цель разработки TCP/IP заключалась в том, чтобы обеспечить высокоскоростные коммуникационные соединения между отдельными сетями. Впоследствии ARPANET превратилась во всемирное сообщество сетей - Интернет.
Протоколы TCP/IP соответствуют четырехуровневой концептуальной модели, известной как модель DARPA. Уровни в этой модели называются так: прикладной, транспортный, межсетевой и сетевой интерфейс. Каждый уровень в модели DARPA соответствует одному или более уровням в семиуровневой модели OSI (Open Systems Interconnection). Архитектура протоколов TCP/IP показана на рис. 24.

Рис. 24. Архитектура TCP/IP
Уровень сетевого интерфейса (network interface layer), также известный как уровень сетевого доступа (network access layer), отвечает за передачу TCP/IP-пакетов в сетевую среду и прием этих пакетов из сетевой среды. TCP/IP независим от способа доступа к сети, формата кадров и сетевой среды. Благодаря этому TCP/IP можно использовать для соединения сетей разных типов, построенных, в частности, на технологиях LAN (Ethernet, Toking Ring) и WAN (X.25, Frame Relay). Независимость от сетевой технологии позволяет адаптировать TCP/IP к новым технологиям вроде ATM (Asynchronous Transfer Mode). Уровень сетевого интерфейса предоставляет функциональность канального и физического уровней в модели OSI.
Межсетевой уровень (internet layer) отвечает за поддержку адресации, пакетов и маршрутизации. Базовые протоколы этого уровня - IP, ARP, ICMP и IGMP. Межсетевой уровень аналогичен сетевому уровню в модели OSI.
Транспортный уровень (transport layer), также известный как уровень транспорта между хостами (host-to-host transport layer), предоставляет прикладному уровню сеансовые коммуникационные службы и обеспечивает поддержку дейтаграмм. Базовые протоколы этого уровня - TCP и UDP. Транспортный уровень предоставляет всю функциональность транспортного уровня в модели OSI и часть функциональности ее сеансового уровня.
Прикладной уровень (application layer) обеспечивает приложениям доступ к сервисам других уровней и определяет протоколы, по которым приложения могут обмениваться данными. На прикладном уровне предусмотрено довольно много протоколов и постоянно разрабатываются новые. Наиболее распространенные протоколы прикладного уровня - те, которые применяются для обмена пользовательской информацией:

  • HTTP (Hypertext Transfer Protocol) - протокол для передачи файлов, образующих содержимое Web-страниц в World Wide Web;
  • FTP (File Transfer Protocol) - протокол для интерактивной передачи файлов;
  • SMTP (Simple Mail Transfer Protocol) - протокол для передачи почтовых сообщений и вложений.

Компонент поддержки протоколов TCP/IP, устанавливаемый в сетевой операционной системе, - это набор протоколов для подключения к сети, называемых базовыми протоколами TCP/IP. Все прочие приложения и протоколы из набора протоколов TCP/IP опираются на базовые сервисы, предоставляемые протоколами IP, ARP, ICMP, IGMP, TCP и UDP.
IP - это не требующий соединений ненадежный протокол, ответственный главным образом за адресацию и маршрутизацию пакетов между хостами. Поскольку этот протокол не требует соединений, перед обменом данными сеанс не устанавливается. А ненадежность заключается в том, что доставка пакетов не гарантируется. IP всегда предпринимает максимум усилий для доставки пакета. IP-пакеты могут быть потеряны, доставлены не в том порядке, продублированы или задержаны. Такого рода ошибки IP не исправляет. За подтверждение приема пакета и восстановление потерянных пакетов отвечает протокол более высокого уровня, например, TCP. Протокол IP определен в RFC 791.
ARP. При посылке IP-пакетов в средах, построенных на сетевых технологиях разделяемого доступа (Ethernet или Token Ring), необходимо преобразование МАС-адресов (media access control) в IP-адреса. Эта задача возлагается на протокол ARP, определенный в RFC 826.
ICMP - этот протокол поддерживает средства диагностики и сообщает об ошибках, когда доставить пакеты не удается. ICMP не делает протокол IP надежнее. Он просто сообщает об ошибках и обеспечивает обратную связь в определенных ситуациях. ICMP-сообщения передаются как IP-дейтаграммы, не требующие подтверждения о приеме, а значит, они тоже ненадежны. Протокол ICMP определен в RFC 792.
IGMP - данный протокол управляет членством хоста в группах IP-рассылки (IP multicast groups), также называемых группами хостов (host groups). Хосты, входящие в такую группу, «слушают» IP-трафик, направляемый на определенный адрес. Этот трафик поступает на единственный МАС-адрес, но обрабатывается несколькими IP-хостами. Протокол IGMP определен в RFC 1112 и 2236.
TCP - это надежный транспортный протокол, требующий соединения. Данные передаются сегментами. Перед обменом данными по этому протоколу хосты должны установить соединение. Надежность достигается за счет присвоения порядкового номера каждому передаваемому сегменту. Хост-получатель передает подтверждение о приеме (АСК) каждого сегмента. Такое подтверждение должно поступать в течение определенного периода. Если отправитель не получает АСК, он повторно передает соответствующие данные. TCP определен в RFC 793.
UDP предоставляет не требующую соединений службу дейтаграмм, которая обеспечивает ненадежную доставку данных, передаваемых в виде сообщений. Это означает, что UDP не гарантирует ни доставку дейтаграмм, ни правильную последовательность доставляемых пакетов. В UDP не поддерживается восстановление потерянных данных за счет их повторной передачи. UDP используется приложениями, которые не требуют подтверждения приема данных и обычно передают данные небольшими порциями. Данный протокол определен в RFC 768.
Каждый TCP/IP-хост идентифицируется логическим IP-адресом. IP-адрес - это адрес сетевого уровня, независимый от адреса канального уровня (например, от МАС-адреса сетевого адаптера). Уникальный IP-адрес необходим для каждого хоста и сетевого компонента, использующего коммуникационную связь по TCP/IP.
IP-адрес имеет длину 32 бита и изображается в виде четырех 8-битных десятичных чисел, разделенных точками, например, 192.168.2.45. Такая форма записи называется точечной десятичной записью (dotted decimal notation), каждое из 8-битных чисел иногда носит название октета (octet) или квадранта (quad). IP-адреса определяют не столько компьютеры, сколько сетевые интерфейсы. Система с двумя платами сетевых адаптеров или с одним сетевым адаптером и модемным соединением с сервером TCP/IP, имеет два IP-адреса.
IP-адрес всегда выделяет часть своих битов для идентификации сети и часть битов для идентификации узла, однако их количество, используемое для каждой из этих целей, не всегда одно и то же. Маска подсети (subnet mask) представляет собой 32-битное двоичное число, биты которого позиционно соответствуют битам IP-адреса. Установленный бит маски подсети означает, что связанный с ним бит IP-адреса есть часть идентификатора сети, в то время как бит со значением 0 предполагает, что соответствующий бит IP-адреса участвует в обозначении идентификатора узла.
Для того чтобы IP-адрес однозначно идентифицировал  компьютер критически важно, чтобы никакие два интерфейса не могли иметь одинаковые IP-адреса. В частной сети администраторы должны убедиться, что каждый адрес уникален. Они могут выполнить это, отслеживая вручную все адреса, ассоциированные с их сетями и узлами, или используя сервис DHCP (Dynamic Host Configuration Protocol, протокол динамической конфигурации узла) для присвоения адресов автоматически. В Интернете процедура выделения IP-адресов возложена на Internet Assigned Numbers Authority (IANA, Агентство по выделению имен и уникальных параметров протоколов Интернета).
Сообществом Интернета определено пять классов адресов, соответствующих сетям различных размеров. TCP/IP поддерживает адреса классов А, В и С. Класс адреса задает, сколько битов в IP-адресе отводится под идентификаторы сети и хоста. А значит, класс адреса также определяет максимальное количество сетей данного класса и хостов в каждой из этих сетей.
Адреса класса A назначаются сетям с очень большим количеством хостов. Старший бит в адресе класса A всегда равен 0. Следующие 7 битов (завершающие первый октет) образуют идентификатор сети. Остальные 24 бита (последние три октета) представляют идентификатор хоста. Таким образом, класс A допускает максимум 126 сетей, а в каждой из них - до 16 777 214 хостов.
Адреса класса B назначаются сетям среднего и большого размера. Два старших бита в адресе класса B всегда являются комбинацией двоичных чисел 1 и 0. Следующие, 14 битов (завершающие первые два октета) образуют идентификатор сети. Остальные 16 битов (последние два октета) представляют идентификатор хоста. Таким  образом, класс B допускает максимум 16 384 сети, а в каждой из них - до 65 534 хостов.
Адреса класса C назначаются малым сетям. Три старших бита в адресе класса C всегда являются комбинацией двоичных чисел 1, 1 и 0. Следующие 21 бит (завершающие первые три октета) образуют идентификатор сети. Остальные 8 битов (последний октет) представляют идентификатор хоста. Таким образом, класс C допускает максимум 2 097 152 сети, а в каждой из них - до 254 хостов.
Адреса класса D резервируются для адресов групповой IP-рассылки. Четыре старших бита в адресе класса D всегда являются комбинацией двоичных чисел 1,1,1 и 0. Остальные биты содержат адрес, известный заинтересованным хостам.
Класс E предусматривает единственный экспериментальный адрес, зарезервированный на будущее. Четыре старших бита в адресе класса E всегда являются комбинацией двоичных чисел 1, 1, 1 и 1.
Регистрируемые IP-адреса выделяются сетям, соединенным с Интернетом и имеющим компьютеры, к которым предполагается доступ из других сетей. Частной сети, не имеющей выхода в Интернет, нет необходимости в этой процедуре. Поэтому в сети, полностью изолированной от Интернета, администраторы могут использовать любые IP-адреса, которые сочтут нужными, до тех пор, пока они не повторяются у компьютеров сети. Если же какой-либо из компьютеров в такой сети все-таки подключить каким-либо способом к Интернету,  возникнет потенциальная возможность конфликта между внутренним адресом компьютера сети и IP-адресом другого компьютера в Интернете. Для предотвращения подобных конфликтов стандарты TCP/IP определи диапазоны IP-адресов, предназначенные для применения в незарегистрированных сетях (они показаны в табл. 2.). Такие адреса не присваивают ни одной из зарегистрированных сетей и, исходя из этого, могут совершенно свободно использоваться любой организацией, частной или общественной.
Таблица 2.
Нерегистрируемые IP-адреса


Класс сети

Диапазон адресов

Класс А

От 10.0.0.0 до 10.255.255.255

Класс В

От 172.16.0.0 до 172.31.255.255

Класс С

От 192.168.0.0 до 192.168.255.255

Теоретически, IP-адреса, присваиваемые компьютерам сети, вовсе не должны обязательно соответствовать физическим сегментам сети, но стандартная практика доказывает, что это - все-таки достаточно обосновано, очевидно, что организация, за которой закреплен IP-адрес класса B, не будет иметь 65 534 узла в одном сегменте сети, а создаст сетевой комплекс из множества сегментов, соединенных маршрутизаторами,  коммутаторами и другими устройствами. Для поддержки многосегментной сети, идентифицируемой одним IP-адресом, практикуется создание подсетей в соответствии с физическими сетевыми сегментами.
Подсетью (subnet) называется часть адреса сети, образуемая путем заимствования некоторого количества битов идентификатора узла в качестве адреса подсети. В процессе назначения сетевых адресов компьютерам, составляющих подсеть, потребуется модифицировать маску подсети для каждого из них, отразив «одолженные» биты в качестве адреса сети, вместо адреса узла.
Например, можно создать подсеть на базе адреса сети класса B, используя третий квадрант, изначально предназначенный для адреса узла, в качестве адреса подсети.  Изменение маски  подсети с 255.255.0.0 на 255.255.255.0 позволяет разделить адрес класса B на 254 подсети по 254 узла в каждой. Затем можно присвоить каждому физическому сегменту сети индивидуальное значение третьего квадранта, выделив для адресов индивидуальных компьютеров только четвертый квадрант. В результате, маршрутизаторы будут направлять трафик в нужный сегмент сети, ориентируясь на значение третьего квадранта.
Для идентификации компьютеров аппаратное и программное обеспечение в сетях TCP/IP полагается на IP-адреса, поэтому для доступа к сетевому ресурсу в параметрах программы вполне достаточно указать IP-адрес, чтобы программа правильно поняла, к какому хосту ей нужно обратиться. Например, команда http://203.23.106.33 откроет начальную страницу на корпоративном Web-сервере. Однако пользователи обычно предпочитают работать с символьными именами компьютеров, и операционные системы локальных сетей приучили их к этому удобному способу.
В операционных системах, которые первоначально разрабатывались для работы в локальных сетях, таких как Novell NetWare, Microsoft Windows или IBM OS/2, пользователи всегда работали с символьными именами компьютеров. Так как локальные сети состояли из небольшого числа компьютеров, то использовались так называемые плоские имена, состоящие из последовательности символов, не разделенных на части. Примерами таких имен являются: NW1_1, mail2. Для установления соответствия между символьными именами и МАС - адресами в этих операционных системах применялся механизм широковещательных запросов.
Для стека TCP/IP, рассчитанного в общем случае на работу в больших территориально распределенных сетях, подобный подход оказывается неэффективным по нескольким причинам. Во-первых, плоские имена не дают возможности разработать единый алгоритм обеспечения уникальности имен в пределах большой сети. А во-вторых, широковещательный способ установления соответствия между символьными именами и локальными адресами хорошо работает только в небольшой локальной сети, не разделенной на подсети. В крупных сетях, где общая широковещательность не поддерживается, нужен другой способ разрешения символьных имен.
Для эффективной организации именования компьютеров в больших сетях естественным является применение иерархических составных имен. В стеке TCP/IP применяется доменная система имен, которая имеет иерархическую древовидную структуру, допускающую использование в имени произвольного количества составных частей (рис. 25).

Рис. 25. Пространство доменных имен
Иерархия доменных имен аналогична иерархии имен файлов, принятой во многих популярных файловых системах. Дерево имен начинается с корня, обозначаемого здесь точкой «.». Затем следует старшая символьная часть имени, вторая по старшинству символьная часть имени и т. д. Младшая часть имени соответствует конечному узлу сети.
Совокупность имен, у которых несколько старших составных частей совпадают, образуют домен имен (domain). Например, имена wwwl.zil.mmt.ru, ftp.zil.mmt.ru, yandex.ru и sl.mgu.ru входят в домен ru, так как все эти имена имеют одну общую старшую часть - имя ru. Необходимо подчеркнуть, что компьютеры входят в домен в соответствии со своими составными именами, при этом они могут иметь различные IP-адреса, принадлежащие к различным сетям и подсетям.
Соответствие между доменными именами и IP-адресами может устанавливаться как средствами локального хоста, так и средствами централизованной службы. На раннем этапе развития Internet на каждом хосте вручную создавался текстовый файл с известным именем hosts. Этот файл состоял из некоторого количества строк, каждая из которых содержала одну пару «IP-адрес - доменное имя», например 102.54.94.97 - rhino.acme.com.
По мере роста Internet файлы hosts также росли, и создание масштабируемого решения для разрешения имен стало необходимостью. Таким решением стала специальная служба - система доменных имен (Domain Name System, DNS). DNS - это централизованная служба, основанная на распределенной базе отображений «доменное имя - IP-адрес».
Служба DNS использует текстовые файлы почти такого формата, как и файл hosts, и эти файлы администратор также подготавливает вручную. Однако служба DNS опирается на иерархию доменов, и каждый сервер службы DNS хранит только часть имен сети, а не все имена, как это происходит при использовании файлов hosts. Каждый DNS-сервер кроме таблицы отображений имен содержит ссылки на DNS-серверы своих поддоменов. Эти ссылки связывают отдельные DNS-серверы в единую службу DNS. Ссылки представляют собой IP-адреса соответствующих серверов.
Процедура разрешения DNS-имени во многом аналогична процедуре поиска файловой системой адреса файла по его символьному имени. Процедура поиска адреса файла по символьному имени заключается в последовательном просмотре каталогов, начиная с корневого. Для определения IP-адреса по доменному имени также необходимо просмотреть все DNS-серверы, обслуживающие цепочку поддоменов, входящих в имя хоста, начиная с корневого домена.
Для ускорения поиска IP-адресов DNS-серверы широко применяют процедуру кэширования проходящих через них ответов. Чтобы служба DNS могла оперативно отрабатывать изменения, происходящие в сети, ответы кэшируются на определенное время - обычно от нескольких часов до нескольких дней.

 
Hosted by uCoz