Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
PAGE 36
FAQ
по курсу лекций Кузнецова В.В.
Информационные сети и коммуникации.
Список вопросов на экзамен
|
[1] [1.1] Классификация IP-адресов. Понятие номера сети и номера узла. [1.2] 1.2. Модель OSI. Физический уровень. [1.3] 1.3. Модель OSI. Канальный уровень. [1.4] 1.4. Модель OSI. Сетевой уровень. [1.5] 1.5. Модель OSI. Транспортный уровень. [1.6] 1.6. Модель OSI. Сеансовый уровень. [1.7] 1.7. Модель OSI. Уровень представления. [1.8] 1.8. Модель OSI. Прикладной уровень. [1.9] 1.9. Адресация в IP-сетях. [1.10] 1.10. Протоколы ARP и RARP. Их место в стеке протоколов IP. [1.11] 1.11. Маршрутизация в IP-сетях. [1.12] 1.12. Структуризация IP-сетей с помощью масок. [1.13] 1.13. Протокол TCP. Его место в стеке протоколов TCP/IP. [1.14] 1.14. Протокол UDP. Его место в стеке протоколов TCP/IP. [1.15] 1.15. Протоколы надёжной доставки пакетов. Концепция квитирования. [1.16] 1.16. Маршрутизаторы. Их место в сетевой модели OSI. [1.17] 1.17. Понятие маршрута. Принципы построения таблиц маршрутизации. [1.18] 1.18. Понятие топологии сети. Средства объединения сетей с произвольной топологией. [1.19] 1.19. Понятие стека сетевых протоколов. Стек протоколов TCP/IP. [1.20] 1.20. Понятие сетевого интерфейса. Модель сетевого интерфейса для IP-сети.
[2] [2.1] 2.1. Технология клиент-сервер. [2.2] 2.2. Событийная модель соединения сокетов. [2.3] 2.3. Особенности программирования сетевого приложения. [2.4] 2.4. Этапы организации соединения сокетов. [2.5] 2.5. Организация сетевого соединения со стороны клиента. [2.6] 2.6. Организация сетевого соединения со стороны сервера. [2.7] 2.7. Особенности программирования приложения-клиента. [2.8] 2.8. Особенности программирования приложения-сервера. [2.9] 2.9. Сокеты. Понятие гнездового соединения. [2.10] 2.10. Сокеты, как средство межпрограммного взаимодействия. [2.11] 2.11. Сокеты. Их место в сетевой модели OSI. [2.12] 2.12. Сокеты. Их место в стеке протоколов IP. [2.13] 2.13. Сокеты в ОС Windows. Технология Windows Sockets. [2.14] 2.14. Средства библиотеки MFC для работы с сокетами. [2.15] 2.15. Организация работы с сокетами средствами языка C++. [2.16] 2.16. Передача данных через сокет. [2.17] 2.17. Приём данных через сокет. [2.18] 2.18. Способы закрытия сетевого соединения между сокетами. [2.19] 2.19. Типы сокетов. Область их применения. [2.20] 2.20. Понятие номера порта для протоколов транспортного уровня сетевой модели OSI. |
Три основных класса IP-адресов
IP-адрес имеет длину 4 байта и обычно записывается в виде четырех чисел, представляющих значения каждого байта в десятичной форме, и разделенных точками, например: 128.10.2.30 - традиционная десятичная форма представления адреса, 10000000 00001010 00000010 00011110 - двоичная форма представления этого же адреса. Структура IP-адреса:
|
Класс А |
0 |
N сети (1 байт) + N узла (3 байта) |
||||
|
Класс B |
1 |
0 |
N сети (2 байта) + N узла (2 байта) |
|||
|
Класс C |
1 |
1 |
0 |
N сети (3 байта) + N узла (1 байт) |
||
|
Класс D |
1 |
1 |
1 |
0 |
адрес группы multicast |
|
|
Класс E |
1 |
1 |
1 |
1 |
0 |
зарезервирован |
Адрес состоит из двух логических частей - номера сети и номера узла в сети. Какая часть адреса относится к номеру сети, а какая к номеру узла, определяется значениями первых битов адреса:
В таблице приведены диапазоны номеров сетей, соответствующих каждому классу сетей.
|
Класс |
Наименьший адрес |
Наибольший адрес |
|
A |
01.0.0 |
126.0.0.0 |
|
B |
128.0.0.0 |
191.255.0.0 |
|
C |
192.0.1.0. |
223.255.255.0 |
|
D |
224.0.0.0 |
239.255.255.255 |
|
E |
240.0.0.0 |
247.255.255.255 |
В протоколе IP существует несколько соглашений об особой интерпретации IP-адресов:
Уже упоминавшаяся форма группового IP-адреса - multicast - означает, что данный пакет должен быть доставлен сразу нескольким узлам, которые образуют группу с номером, указанным в поле адреса. Узлы сами идентифицируют себя, то есть определяют, к какой из групп они относятся. Один и тот же узел может входить в несколько групп. Такие сообщения в отличие от широковещательных называются мультивещательными. Групповой адрес не делится на поля номера сети и узла и обрабатывается маршрутизатором особым образом.
В протоколе IP нет понятия широковещательности в том смысле, в котором оно используется в протоколах канального уровня локальных сетей, когда данные должны быть доставлены абсолютно всем узлам. Как ограниченный широковещательный IP-адрес, так и широковещательный IP-адрес имеют пределы распространения в интерсети - они ограничены либо сетью, к которой принадлежит узел - источник пакета, либо сетью, номер которой указан в адресе назначения. Поэтому деление сети с помощью маршрутизаторов на части локализует широковещательный шторм пределами одной из составляющих общую сеть частей просто потому, что нет способа адресовать пакет одновременно всем узлам всех сетей составной сети.
Часто администраторы сетей испытывают неудобства, из-за того, что количество централизовано выделенных им номеров сетей недостаточно для того, чтобы структурировать сеть надлежащим образом, например, разместить все слабо взаимодействующие компьютеры по разным сетям.
В такой ситуации возможны два пути. Первый из них связан с получением от NIC дополнительных номеров сетей. Второй способ, употребляющийся более часто, связан с использованием так называемых масок, которые позволяют разделять одну сеть на несколько сетей.
Маска – это число, двоичная запись которого содержит единицы в тех разрядах, которые должны интерпретироваться как номер сети.
Например, для стандартных классов сетей маски имеют следующие значения:
255.0.0.0 - маска для сети класса А,
255.255.0.0 - маска для сети класса В,
255.255.255.0 - маска для сети класса С.
Источники:
http://www.citforum.ru/nets/ip/glava_3.shtml
http://www.citforum.ru/nets/ip/glava_4.shtml#_4_5
Международная Организация по Стандартам (International Standards Organization, ISO) разработала модель, которая четко определяет различные уровни взаимодействия систем, дает им стандартные имена и указывает, какую работу должен делать каждый уровень. Эта модель называется моделью взаимодействия открытых систем (Open System Interconnection, OSI) или моделью ISO/OSI.
В модели OSI взаимодействие делится на семь уровней или слоев. Каждый уровень имеет дело с одним определенным аспектом взаимодействия. Таким образом, проблема взаимодействия декомпозирована на 7 частных проблем, каждая из которых может быть решена независимо от других. Каждый уровень поддерживает интерфейсы с выше- и нижележащими уровнями.
Модель OSI описывает только системные средства взаимодействия, не касаясь приложений конечных пользователей. Приложения реализуют свои собственные протоколы взаимодействия, обращаясь к системным средствам. Следует иметь в виду, что приложение может взять на себя функции некоторых верхних уровней модели OSI, в таком случае, при необходимости межсетевого обмена оно обращается напрямую к системным средствам, выполняющим функции оставшихся нижних уровней модели OSI.
Приложение конечного пользователя может использовать системные средства взаимодействия не только для организации диалога с другим приложением, выполняющимся на другой машине, но и просто для получения услуг того или иного сетевого сервиса, например, доступа к удаленным файлам, получение почты или печати на разделяемом принтере.
Пример. Итак, пусть приложение обращается с запросом к прикладному уровню, например к файловому сервису. На основании этого запроса программное обеспечение прикладного уровня формирует сообщение стандартного формата, в которое помещает служебную информацию (заголовок) и, возможно, передаваемые данные. Затем это сообщение направляется представительному уровню. Представительный уровень добавляет к сообщению свой заголовок и передает результат вниз сеансовому уровню, который в свою очередь добавляет свой заголовок и т.д. Некоторые реализации протоколов предусматривают наличие в сообщении не только заголовка, но и концевика. Наконец, сообщение достигает самого низкого, физического уровня, который действительно передает его по линиям связи.
Когда сообщение по сети поступает на другую машину, оно последовательно перемещается вверх с уровня на уровень. Каждый уровень анализирует, обрабатывает и удаляет заголовок своего уровня, выполняет соответствующие данному уровню функции и передает сообщение вышележащему уровню.
Физический уровень. Этот уровень имеет дело с передачей битов по физическим каналам, таким, например, как коаксиальный кабель, витая пара или оптоволоконный кабель. К этому уровню имеют отношение характеристики физических сред передачи данных, такие как полоса пропускания, помехозащищенность, волновое сопротивление и другие. На этом же уровне определяются характеристики электрических сигналов, такие как требования к фронтам импульсов, уровням напряжения или тока передаваемого сигнала, тип кодирования, скорость передачи сигналов. Кроме этого, здесь стандартизуются типы разъемов и назначение каждого контакта.
Функции физического уровня реализуются во всех устройствах, подключенных к сети. Со стороны компьютера функции физического уровня выполняются сетевым адаптером или последовательным портом.
Примером протокола физического уровня может служить спецификация 10Base-T технологии Ethernet, которая определяет в качестве используемого кабеля неэкранированную витую пару категории 3 с волновым сопротивлением 100 Ом, разъем RJ-45, максимальную длину физического сегмента 100 метров, манчестерский код для представления данных на кабеле, и другие характеристики среды и электрических сигналов.
Источники:
http://www.nestor.minsk.by/sr/2000/11/01104.html
Модель OSI описана в разделе 1.2.
Канальный уровень. На физическом уровне просто пересылаются биты. При этом не учитывается, что в некоторых сетях, в которых линии связи используются (разделяются) попеременно несколькими парами взаимодействующих компьютеров, физическая среда передачи может быть занята. Поэтому одной из задач канального уровня является проверка доступности среды передачи. Другой задачей канального уровня является реализация механизмов обнаружения и коррекции ошибок. Для этого на канальном уровне биты группируются в наборы, называемые кадрами (frames). Канальный уровень обеспечивает корректность передачи каждого кадра, помещая специальную последовательность бит в начало и конец каждого кадра, чтобы отметить его, а также вычисляет контрольную сумму, суммируя все байты кадра определенным способом и добавляя контрольную сумму к кадру. Когда кадр приходит, получатель снова вычисляет контрольную сумму полученных данных и сравнивает результат с контрольной суммой из кадра. Если они совпадают, кадр считается правильным и принимается. Если же контрольные суммы не совпадают, то фиксируется ошибка.
В протоколах канального уровня, используемых в локальных сетях, заложена определенная структура связей между компьютерами и способы их адресации. Хотя канальный уровень и обеспечивает доставку кадра между любыми двумя узлами локальной сети, он это делает только в сети с совершенно определенной топологией связей, именно той топологией, для которой он был разработан. К таким типовым топологиям, поддерживаемым протоколами канального уровня локальных сетей, относятся общая шина, кольцо и звезда. Примерами протоколов канального уровня являются протоколы Ethernet, Token Ring, FDDI, 100VG-AnyLAN.
В локальных сетях протоколы канального уровня используются компьютерами, мостами, коммутаторами и маршрутизаторами. В компьютерах функции канального уровня реализуются совместными усилиями сетевых адаптеров и их драйверов.
В глобальных сетях, которые редко обладают регулярной топологией, канальный уровень обеспечивает обмен сообщениями между двумя соседними компьютерами, соединенными индивидуальной линией связи. Примерами протоколов "точка - точка" (как часто называют такие протоколы) могут служить широко распространенные протоколы PPP и LAP-B.
Адреса, используемые на канальном уровне в локальных сетях, часто называют МАС-адресами.
Источники:
http://www.nestor.minsk.by/sr/2000/11/01104.html
Модель OSI описана в разделе 1.2.
Сетевой уровень. Этот уровень служит для образования единой транспортной системы, объединяющей несколько сетей с различными принципами передачи информации между конечными узлами. Рассмотрим функции сетевого уровня на примере локальных сетей. Протокол канального уровня локальных сетей обеспечивает доставку данных между любыми узлами только в сети с соответствующей типовой топологией. Это очень жесткое ограничение, которое не позволяет строить сети с развитой структурой, например, сети, объединяющие несколько сетей предприятия в единую сеть, или высоконадежные сети, в которых существуют избыточные связи между узлами. Для того, чтобы, с одной стороны, сохранить простоту процедур передачи данных для типовых топологий, а с другой стороны, допустить использование произвольных топологий, используется дополнительный сетевой уровень. На этом уровне вводится понятие "сеть". В данном случае под сетью понимается совокупность компьютеров, соединенных между собой в соответствии с одной из стандартных типовых топологий и использующих для передачи данных один из протоколов канального уровня, определенный для этой топологии.
Таким образом, внутри сети доставка данных регулируется канальным уровнем, а вот доставкой данных между сетями занимается сетевой уровень.
Сообщения сетевого уровня принято называть пакетами (packets). При организации доставки пакетов на сетевом уровне используется понятие "номер сети". В этом случае адрес получателя состоит из номера сети и номера компьютера в этой сети.
Сети соединяются между собой специальными устройствами, называемыми маршрутизаторами. Маршрутизатор - это устройство, которое собирает информацию о топологии межсетевых соединений и на ее основании пересылает пакеты сетевого уровня в сеть назначения. Для того, чтобы передать сообщение от отправителя, находящегося в одной сети, получателю, находящемуся в другой сети, нужно совершить некоторое количество транзитных передач (hops) между сетями, каждый раз выбирая подходящий маршрут. Таким образом, маршрут представляет собой последовательность маршрутизаторов, через которые проходит пакет.
Проблема выбора наилучшего пути называется маршрутизацией и ее решение является главной задачей сетевого уровня. Эта проблема осложняется тем, что самый короткий путь не всегда самый лучший. Часто критерием при выборе маршрута является время передачи данных по этому маршруту, оно зависит от пропускной способности каналов связи и интенсивности трафика, которая может изменяться с течением времени. Некоторые алгоритмы маршрутизации пытаются приспособиться к изменению нагрузки, в то время, как другие принимают решения на основе средних показателей за длительное время. Выбор маршрута может осуществляться и по другим критериям, например, надежности передачи.
На сетевом уровне определяется два вида протоколов. Первый вид относится к определению правил передачи пакетов с данными конечных узлов от узла к маршрутизатору и между маршрутизаторами. Именно эти протоколы обычно имеют в виду, когда говорят о протоколах сетевого уровня. К сетевому уровню относят и другой вид протоколов, называемых протоколами обмена маршрутной информацией. С помощью этих протоколов маршрутизаторы собирают информацию о топологии межсетевых соединений. Протоколы сетевого уровня реализуются программными модулями операционной системы, а также программными и аппаратными средствами маршрутизаторов.
Примерами протоколов сетевого уровня являются протокол межсетевого взаимодействия IP стека TCP/IP и протокол межсетевого обмена пакетами IPX стека Novell.
Источники:
http://www.nestor.minsk.by/sr/2000/11/01104.html
Модель OSI описана в разделе 1.2.
Транспортный уровень. На пути от отправителя к получателю пакеты могут быть искажены или утеряны. Хотя некоторые приложения имеют собственные средства обработки ошибок, существуют и такие, которые предпочитают сразу иметь дело с надежным соединением. Работа транспортного уровня заключается в том, чтобы обеспечить приложениям или верхним уровням стека - прикладному и сеансовому - передачу данных с той степенью надежности, которая им требуется. Модель OSI определяет пять классов сервиса, предоставляемых транспортным уровнем. Эти виды сервиса отличаются качеством предоставляемых услуг: срочностью, возможностью восстановления прерванной связи, наличием средств мультиплексирования нескольких соединений между различными прикладными протоколами через общий транспортный протокол, а главное – способностью к обнаружению и исправлению ошибок передачи, таких как искажение, потеря и дублирование пакетов.
Выбор класса сервиса транспортного уровня определяется, с одной стороны, тем, в какой степени задача обеспечения надежности решается самими приложениями и протоколами более высоких, чем транспортный, уровней, а с другой стороны, этот выбор зависит от того, насколько надежной является вся система транспортировки данных в сети. Так, например, если качество каналов передачи связи очень высокое, и вероятность возникновения ошибок, не обнаруженных протоколами более низких уровней, невелика, то разумно воспользоваться одним из облегченных сервисов транспортного уровня, не обремененных многочисленными проверками, квитированием и другими приемами повышения надежности. Если же транспортные средства изначально очень ненадежны, то целесообразно обратиться к наиболее развитому сервису транспортного уровня, который работает, используя максимум средств для обнаружения и устранения ошибок – с помощью предварительного установления логического соединения, контроля доставки сообщений с помощью контрольных сумм и циклической нумерации пакетов, установления тайм-аутов доставки и т.п.
Как правило, все протоколы, начиная с транспортного уровня и выше, реализуются программными средствами конечных узлов сети – компонентами их сетевых операционных систем. В качестве примера транспортных протоколов можно привести протоколы TCP и UDP стека TCP/IP и протокол SPX стека Novell.
Источники:
http://www.nestor.minsk.by/sr/2000/11/01104.html
Модель OSI описана в разделе 1.2.
Сеансовый уровень. Сеансовый уровень обеспечивает управление диалогом для того, чтобы фиксировать, какая из сторон является активной в настоящий момент, а также предоставляет средства синхронизации. Последние позволяют вставлять контрольные точки в длинные передачи, чтобы в случае отказа можно было вернуться назад к последней контрольной точке, вместо того, чтобы начинать все с начала. На практике немногие приложения используют сеансовый уровень, и он редко реализуется.
Источники:
http://www.nestor.minsk.by/sr/2000/11/01104.html
Модель OSI описана в разделе 1.2.
Уровень представления. Этот уровень обеспечивает гарантию того, что информация, передаваемая прикладным уровнем, будет понятна прикладному уровню в другой системе. При необходимости уровень представления выполняет преобразование форматов данных в некоторый общий формат представления, а на приеме, соответственно, выполняет обратное преобразование. Таким образом, прикладные уровни могут преодолеть, например, синтаксические различия в представлении данных. На этом уровне может выполняться шифрование и дешифрование данных, благодаря которому секретность обмена данными обеспечивается сразу для всех прикладных сервисов. Примером протокола, работающего на уровне представления, является протокол Secure Socket Layer (SSL), который обеспечивает секретный обмен сообщениями для протоколов прикладного уровня стека TCP/IP.
Источники:
http://www.nestor.minsk.by/sr/2000/11/01104.html
Модель OSI описана в разделе 1.2.
Прикладной уровень. Прикладной уровень - это в действительности просто набор разнообразных протоколов, с помощью которых пользователи сети получают доступ к разделяемым ресурсам, таким как файлы, принтеры или гипертекстовые Web-страницы, а также организуют свою совместную работу, например, с помощью протокола электронной почты. Единица данных, которой оперирует прикладной уровень, обычно называется сообщением (message).
Существует очень большое разнообразие протоколов прикладного уровня. Приведем в качестве примеров хотя бы несколько наиболее распространенных реализаций файловых сервисов: NCP в операционной системе Novell NetWare, SMB в Microsoft Windows NT, NFS, FTP и TFTP, входящие в стек TCP/IP.
Источники:
http://www.nestor.minsk.by/sr/2000/11/01104.html
Каждый компьютер в сети TCP/IP имеет адреса трех уровней:
Локальный адрес узла, определяемый технологией, с помощью которой построена отдельная сеть, в которую входит данный узел. Для узлов, входящих в локальные сети - это МАС-адрес сетевого адаптера или порта маршрутизатора, например, 11-А0-17-3D-BC-01. Эти адреса назначаются производителями оборудования и являются уникальными адресами, так как управляются централизовано. Для всех существующих технологий локальных сетей МАС-адрес имеет формат 6 байтов: старшие 3 байта - идентификатор фирмы производителя, а младшие 3 байта назначаются уникальным образом самим производителем. Для узлов, входящих в глобальные сети, такие как Х.25 или frame relay, локальный адрес назначается администратором глобальной сети.
IP-адрес, состоящий из 4 байт, например, 109.26.17.100. Этот адрес используется на сетевом уровне. Он назначается администратором во время конфигурирования компьютеров и маршрутизаторов. IP-адрес состоит из двух частей: номера сети и номера узла. Номер сети может быть выбран администратором произвольно, либо назначен по рекомендации специального подразделения Internet (Network Information Center, NIC), если сеть должна работать как составная часть Internet. Обычно провайдеры услуг Internet получают диапазоны адресов у подразделений NIC, а затем распределяют их между своими абонентами.
Номер узла в протоколе IP назначается независимо от локального адреса узла. Деление IP-адреса на поле номера сети и номера узла - гибкое, и граница между этими полями может устанавливаться весьма произвольно. Узел может входить в несколько IP-сетей. В этом случае узел должен иметь несколько IP-адресов, по числу сетевых связей. Таким образом IP-адрес характеризует не отдельный компьютер или маршрутизатор, а одно сетевое соединение.
Символьное доменное имя, например, SERV1.IBM.COM. Этот адрес назначается администратором и состоит из нескольких частей, например, имени машины, имени организации, имени домена. Такой адрес, называемый также DNS-именем, используется на прикладном уровне, например, в протоколах FTP или telnet.
Источники:
http://www.citforum.ru/nets/ip/glava_3.shtml#_3_4
В протоколе IP-адрес узла, то есть адрес компьютера или порта маршрутизатора, назначается произвольно администратором сети и прямо не связан с его локальным адресом, как это сделано, например, в протоколе IPX. Подход, используемый в IP, удобно использовать в крупных сетях и по причине его независимости от формата локального адреса, и по причине стабильности, так как в противном случае, при смене на компьютере сетевого адаптера это изменение должны бы были учитывать все адресаты всемирной сети Internet (в том случае, конечно, если сеть подключена к Internet'у).
Локальный адрес используется в протоколе IP только в пределах локальной сети при обмене данными между маршрутизатором и узлом этой сети. Маршрутизатор, получив пакет для узла одной из сетей, непосредственно подключенных к его портам, должен для передачи пакета сформировать кадр в соответствии с требованиями принятой в этой сети технологии и указать в нем локальный адрес узла, например его МАС-адрес. В пришедшем пакете этот адрес не указан, поэтому перед маршрутизатором встает задача поиска его по известному IP-адресу, который указан в пакете в качестве адреса назначения. С аналогичной задачей сталкивается и конечный узел, когда он хочет отправить пакет в удаленную сеть через маршрутизатор, подключенный к той же локальной сети, что и данный узел.
Для определения локального адреса по IP-адресу используется протокол разрешения адреса Address Resolution Protocol, ARP. Протокол ARP работает различным образом в зависимости от того, какой протокол канального уровня работает в данной сети - протокол локальной сети (Ethernet, Token Ring, FDDI) с возможностью широковещательного доступа одновременно ко всем узлам сети, или же протокол глобальной сети (X.25, frame relay), как правило не поддерживающий широковещательный доступ. Существует также протокол, решающий обратную задачу - нахождение IP-адреса по известному локальному адресу. Он называется реверсивный ARP - RARP (Reverse Address Resolution Protocol) и используется при старте бездисковых станций, не знающих в начальный момент своего IP-адреса, но знающих адрес своего сетевого адаптера.
В локальных сетях протокол ARP использует широковещательные кадры протокола канального уровня для поиска в сети узла с заданным IP-адресом.
Узел, которому нужно выполнить отображение IP-адреса на локальный адрес, формирует ARP запрос, вкладывает его в кадр протокола канального уровня, указывая в нем известный IP-адрес, и рассылает запрос широковещательно. Все узлы локальной сети получают ARP запрос и сравнивают указанный там IP-адрес с собственным. В случае их совпадения узел формирует ARP-ответ, в котором указывает свой IP-адрес и свой локальный адрес и отправляет его уже направленно, так как в ARP запросе отправитель указывает свой локальный адрес. ARP-запросы и ответы используют один и тот же формат пакета. Так как локальные адреса могут в различных типах сетей иметь различную длину, то формат пакета протокола ARP зависит от типа сети. На рисунке 3.2 показан формат пакета протокола ARP для передачи по сети Ethernet.
Тип оборудования - это тип интерфейса, для которого отправитель ищет адрес; код содержит 1 для Ethernet. Поле типа протокола позволяет использовать пакеты ARP не только для протокола IP, но и для других сетевых протоколов. Для IP значение этого поля равно 080016. HA-Len - длина аппаратного адреса; PA-Len - длина протокольного адреса (длина в байтах, например, для IP-адреса PA-Len=4). Поле код операции определяет, является ли данный пакет ARP-запросом (код = 1), ARP-откликом (2), RARP-запросом (3), или RARP-откликом (4).
Узел, отправляющий ARP-запрос, заполняет в пакете все поля, кроме поля искомого локального адреса (для RARP-запроса не указывается искомый IP-адрес). Значение этого поля заполняется узлом, опознавшим свой IP-адрес.
В глобальных сетях администратору сети чаще всего приходится вручную формировать ARP-таблицы, в которых он задает, например, соответствие IP-адреса адресу узла сети X.25, который имеет смысл локального адреса. В последнее время наметилась тенденция автоматизации работы протокола ARP и в глобальных сетях. Для этой цели среди всех маршрутизаторов, подключенных к какой-либо глобальной сети, выделяется специальный маршрутизатор, который ведет ARP-таблицу для всех остальных узлов и маршрутизаторов этой сети. При таком централизованном подходе для всех узлов и маршрутизаторов вручную нужно задать только IP-адрес и локальный адрес выделенного маршрутизатора. Затем каждый узел и маршрутизатор регистрирует свои адреса в выделенном маршрутизаторе, а при необходимости установления соответствия между IP-адресом и локальным адресом узел обращается к выделенному маршрутизатору с запросом и автоматически получает ответ без участия администратора.
Источники:
http://www.citforum.ru/nets/ip/glava_3.shtml#_3_4
http://book.itep.ru/4/44/arp_446.htm
Под маршрутизацией понимается процесс доставки сообщения из одной подсети в другую. Рассмотрим теперь принципы, на основании которых в сетях IP происходит выбор маршрута передачи пакета между сетями.
Сначала необходимо обратить внимание на тот факт, что не только маршрутизаторы, но и конечные узлы - компьютеры - должны принимать участие в выборе маршрута. Пример, приведенный на рисунке, демонстрирует эту необходимость. Здесь в локальной сети имеется несколько маршрутизаторов, и компьютер должен выбирать, какому из них следует отправить пакет.
Длина маршрута может существенно измениться в зависимости от того, какой маршрутизатор выберет компьютер для передачи своего пакета на сервер, расположенный, например, в Германии, если маршрутизатор 1 соединен выделенной линией с маршрутизатором в Копенгагене, а маршрутизатор 2 имеет спутниковый канал, соединяющий его с Токио.
В стеке TCP/IP маршрутизаторы и конечные узлы принимают решения о том, кому передавать пакет для его успешной доставки узлу назначения, на основании так называемых таблиц маршрутизации (routing tables). Следующая таблица представляет собой типичный пример таблицы маршрутов, использующей IP-адреса сетей:
|
Адрес сети назначения |
Адрес следующего маршрутизатора |
Номер выходного порта |
Расстояние до сети назначения |
|
56.0.0.0 |
198.21.17.7 |
1 |
20 |
|
56.0.0.0 |
213.34.12.4. |
2 |
130 |
|
116.0.0.0 |
213.34.12.4 |
2 |
1450 |
|
129.13.0.0 |
198.21.17.6 |
1 |
50 |
|
198.21.17.0 |
- |
2 |
0 |
|
213. 34.12.0 |
- |
1 |
0 |
|
Default |
198.21.17.7 |
1 |
- |
В этой таблице в столбце "Адрес сети назначения" указываются адреса всех сетей, которым данный маршрутизатор может передавать пакеты. В стеке TCP/IP принят так называемый одношаговый подход к оптимизации маршрута продвижения пакета (next-hop routing) - каждый маршрутизатор и конечный узел принимает участие в выборе только одного шага передачи пакета. Поэтому в каждой строке таблицы маршрутизации указывается не весь маршрут в виде последовательности IP-адресов маршрутизаторов, через которые должен пройти пакет, а только один IP-адрес - адрес следующего маршрутизатора, которому нужно передать пакет. Вместе с пакетом следующему маршрутизатору передается ответственность за выбор следующего шага маршрутизации. Одношаговый подход к маршрутизации означает распределенное решение задачи выбора маршрута. Это снимает ограничение на максимальное количество транзитных маршрутизаторов на пути пакета.
В случае, если в таблице маршрутов имеется более одной строки, соответствующей одному и тому же адресу сети назначения, то при принятии решения о передаче пакета используется та строка, в которой указано наименьшее значение в поле "Расстояние до сети назначения".
При этом под расстоянием понимается любая метрика, используемая в соответствии с заданным в сетевом пакете классом сервиса. Это может быть количество транзитных маршрутизаторов в данном маршруте (количество хопов от hop - прыжок), время прохождения пакета по линиям связи, надежность линий связи, или другая величина, отражающая качество данного маршрута по отношению к конкретному классу сервиса. Если маршрутизатор поддерживает несколько классов сервиса пакетов, то таблица маршрутов составляется и применяется отдельно для каждого вида сервиса (критерия выбора маршрута).
Для отправки пакета следующему маршрутизатору требуется знание его локального адреса, но в стеке TCP/IP в таблицах маршрутизации принято использование только IP-адресов для сохранения их универсального формата, не зависящего от типа сетей, входящих в интерсеть. Для нахождения локального адреса по известному IP-адресу необходимо воспользоваться протоколом ARP.
Конечный узел, как и маршрутизатор, имеет в своем распоряжении таблицу маршрутов унифицированного формата и на основании ее данных принимает решение, какому маршрутизатору нужно передавать пакет для сети N. Решение о том, что этот пакет нужно вообще маршрутизировать, компьютер принимает в том случае, когда он видит, что адрес сети назначения пакета отличается от адреса его собственной сети (каждому компьютеру при конфигурировании администратор присваивает его IP-адрес или несколько IP-адресов, если компьютер одновременно подключен к нескольким сетям). Когда компьютер выбрал следующий маршрутизатор, то он просматривают кэш-таблицу адресов своего протокола ARP и, может быть, находит там соответствие IP-адреса следующего маршрутизатора его MAC-адресу. Если же нет, то по локальной сети передается широковещательный ARP-запрос и локальный адрес извлекается из ARP-ответа.
После этого компьютер формирует кадр протокола, используемого на выбранном порту, например, кадр Ethernet, в который помещает МАС-адрес маршрутизатора. Маршрутизатор принимает кадр Ethernet, извлекает из него пакет IP и просматривает свою таблицу маршрутизации для нахождения следующего маршрутизатора. При этом он выполняет те же действия, что и конечный узел.
Одношаговая маршрутизация обладает еще одним преимуществом - она позволяет сократить объем таблиц маршрутизации в конечных узлах и маршрутизаторах за счет использования в качестве номера сети назначения так называемого маршрута по умолчанию - default, который обычно занимает в таблице маршрутизации последнюю строку. Если в таблице маршрутизации есть такая запись, то все пакеты с номерами сетей, которые отсутствуют в таблице маршрутизации, передаются маршрутизатору, указанному в строке default. Поэтому маршрутизаторы часто хранят в своих таблицах ограниченную информацию о сетях интерсети, пересылая пакеты для остальных сетей в порт и маршрутизатор, используемые по умолчанию. Подразумевается, что маршрутизатор, используемый по умолчанию, передаст пакет на магистральную сеть, а маршрутизаторы, подключенные к магистрали, имеют полную информацию о составе интерсети.
Особенно часто приемом маршрутизации по умолчанию пользуются конечные узлы. Хотя они также в общем случае имеют в своем распоряжении таблицу маршрутизации, ее объем обычно незначителен, так как маршрутизация для компьютера - не основное занятие. Главная роль в маршрутизации пакетов в концепции протокола IP отводится, естественно, маршрутизаторам, которые должны обладать гораздо более полными таблицами маршрутизации, чем конечные узлы. Конечный узел часто вообще работает без таблицы маршрутизации, имея только сведения об IP-адресе маршрутизатора по умолчанию. При наличии одного маршрутизатора в локальной сети этот вариант - единственно возможный для всех конечных узлов. Но даже при наличии нескольких маршрутизаторов в локальной сети, когда проблема их выбора стоит перед конечным узлом, задание маршрута по умолчанию часто используется в компьютерах для сокращения объема их маршрутной таблицы.
Другим способом разгрузки компьютера от необходимости ведения больших таблиц маршрутизации является получение от маршрутизатора сведений о рациональном маршруте для какой-нибудь конкретной сети с помощью протокола ICMP.
Кроме маршрута default, в таблице маршрутизации могут встретиться два типа специальных записей - запись о специфичном для узла маршруте и запись об адресах сетей, непосредственно подключенных к портам маршрутизатора.
Специфичный для узла маршрут содержит вместо номера сети полный IP-адрес, то есть адрес, имеющий ненулевую информацию не только в поле номера сети, но и в поле номера узла. Предполагается, что для такого конечного узла маршрут должен выбираться не так, как для всех остальных узлов сети, к которой он относится. В случае, когда в таблице есть разные записи о продвижении пакетов для всей сети N и ее отдельного узла, имеющего адрес N,D, при поступлении пакета, адресованного узлу N,D, маршрутизатор отдаст предпочтение записи для N,D.
Записи в таблице маршрутизации, относящиеся к сетям, непосредственно подключенным к маршрутизатору, в поле "Расстояние до сети назначения" содержат нули.
Еще одним отличием работы маршрутизатора и конечного узла при выборе маршрута является способ построения таблицы маршрутизации. Если маршрутизаторы обычно автоматически создают таблицы маршрутизации, обмениваясь служебной информацией, то для конечных узлов таблицы маршрутизации создаются, как правило, вручную администраторами, и хранятся в виде постоянных файлов на дисках.
Существуют различные алгоритмы построения таблиц для одношаговой маршрутизации. Их можно разделить на три класса:
Независимо от алгоритма, используемого для построения таблицы маршрутизации, результат их работы имеет единый формат. За счет этого в одной и той же сети различные узлы могут строить таблицы маршрутизации по своим алгоритмам, а затем обмениваться между собой недостающими данными, так как форматы этих таблиц фиксированы. Поэтому маршрутизатор, работающий по алгоритму адаптивной маршрутизации, может снабдить конечный узел, применяющий алгоритм фиксированной маршрутизации, сведениями о пути к сети, о которой конечный узел ничего не знает.
В состав пакета входит поле «время жизни», которое занимает 1 байт и указывает предельный срок, в течение которого пакет может перемещаться по сети. Время жизни данного пакета измеряется в секундах и задается источником передачи средствами протокола IP. На шлюзах и в других узлах сети по истечении каждой секунды из текущего времени жизни вычитается единица; единица вычитается также при каждой транзитной передаче (даже если не прошла секунда). При истечении времени жизни пакет аннулируется.
Источник:
http://www.citforum.ru/nets/ip/glava_4.shtml#_4_3
Часто администраторы сетей испытывают неудобства, из-за того, что количество централизовано выделенных им номеров сетей недостаточно для того, чтобы структурировать сеть надлежащим образом, например, разместить все слабо взаимодействующие компьютеры по разным сетям.
В такой ситуации возможны два пути. Первый из них связан с получением от NIC дополнительных номеров сетей. Второй способ, употребляющийся более часто, связан с использованием так называемых масок, которые позволяют разделять одну сеть на несколько сетей.
Маска – это число, двоичная запись которого содержит единицы в тех разрядах, которые должны интерпретироваться как номер сети.
Например, для стандартных классов сетей маски имеют следующие значения:
255.0.0.0 - маска для сети класса А,
255.255.0.0 - маска для сети класса В,
255.255.255.0 - маска для сети класса С.
В масках, которые использует администратор для увеличения числа сетей, количество единиц в последовательности, определяющей границу номера сети, не обязательно должно быть кратным 8, чтобы повторять деление адреса на байты.
Пример. Пусть, например, маска имеет значение 255.255.192.0 (11111111 11111111 11000000 00000000). И пусть сеть имеет номер 129.44.0.0 (10000001 00101100 00000000 00000000), из которого видно, что она относится к классу В. После наложения маски на этот адрес число разрядов, интерпретируемых как номер сети, увеличилось с 16 до 18, то есть администратор получил возможность использовать вместо одного, централизованно заданного ему номера сети, четыре:
129.44.0.0 (10000001 00101100 00000000 00000000)
129.44.64.0 (10000001 00101100 01000000 00000000)
129.44.128.0 (10000001 00101100 10000000 00000000)
129.44.192.0 (10000001 00101100 11000000 00000000)
Например, IP-адрес 129.44.141.15 (10000001 00101100 10001101 00001111), который по стандартам IP задает номер сети 129.44.0.0 и номер узла 0.0.141.15, теперь, при использовании маски, будет интерпретироваться как пара: 129.44.128.0 - номер сети, 0.0. 13.15 - номер узла.
Таким образом, установив новое значение маски, можно заставить маршрутизатор по-другому интерпретировать IP-адрес. При этом два дополнительных последних бита номера сети часто интерпретируются как номера подсетей.
Еще один пример. Пусть некоторая сеть относится к классу В и имеет адрес 128.10.0.0. Этот адрес используется маршрутизатором, соединяющим сеть с остальной частью интерсети. И пусть среди всех станций сети есть станции, слабо взаимодействующие между собой. Их желательно было бы изолировать в разных сетях. Для этого сеть можно разделить на две сети, подключив их к соответствующим портам маршрутизатора, и задать для этих портов в качестве маски, например, число 255.255.255.0, то есть организовать внутри исходной сети с централизовано заданным номером две подсети класса C (можно было бы выбрать и другой размер для поля адреса подсети). Извне сеть по-прежнему будет выглядеть, как единая сеть класса В, а на местном уровне это будут две отдельные сети класса С. Приходящий общий трафик будет разделяться местным маршрутизатором между подсетями.
Необходимо заметить, что, если принимается решение об использовании механизма масок, то соответствующим образом должны быть сконфигурированы и маршрутизаторы, и компьютеры сети.
Источник:
http://www.citforum.ru/nets/ip/glava_4.shtml#_4_3
В стеке протоколов TCP/IP протокол TCP (Transmission Control Protocol) работает так же, как и протокол UDP, на транспортном уровне. Он обеспечивает надежную транспортировку данных между прикладными процессами путем установления логического соединения.
Единицей данных протокола TCP является сегмент. Информация, поступающая к протоколу TCP в рамках логического соединения от протоколов более высокого уровня, рассматривается протоколом TCP как неструктурированный поток байт. Поступающие данные буферизуются средствами TCP. Для передачи на сетевой уровень из буфера "вырезается" некоторая непрерывная часть данных, называемая сегментом.
В протоколе TCP предусмотрен случай, когда приложение обращается с запросом о срочной передаче данных (бит PSH в запросе установлен в 1). В этом случае протокол TCP, не ожидая заполнения буфера до уровня размера сегмента, немедленно передает указанные данные в сеть. О таких данных говорят, что они передаются вне потока - out of band.
Не все сегменты, посланные через соединение, будут одного и того же размера, однако оба участника соединения должны договориться о максимальном размере сегмента, который они будут использовать. Этот размер выбирается таким образом, чтобы при упаковке сегмента в IP-пакет он помещался туда целиком, то есть максимальный размер сегмента не должен превосходить максимального размера поля данных IP-пакета. В противном случае пришлось бы выполнять фрагментацию, то есть делить сегмент на несколько частей, для того, чтобы он вместился в IP-пакет.
Аналогичные проблемы решаются и на сетевом уровне. Для того, чтобы избежать фрагментации, должен быть выбран соответствующий максимальный размер IP-пакета. Однако при этом должны быть приняты во внимание максимальные размеры поля данных кадров (MTU) всех протоколов канального уровня, используемых в сети. Максимальный размер сегмента не должен превышать минимальное значение на множестве всех MTU составной сети.
В протоколе TCP также, как и в UDP, для связи с прикладными процессами используются порты. Номера портам присваиваются аналогичным образом: имеются стандартные, зарезервированные номера (например, номер 21 закреплен за сервисом FTP, 23 - за telnet), а менее известные приложения пользуются произвольно выбранными локальными номерами.
Однако в протоколе TCP порты используются несколько иным способом. Для организации надежной передачи данных предусматривается установление логического соединения между двумя прикладными процессами. В рамках соединения осуществляется обязательное подтверждение правильности приема для всех переданных сообщений, и при необходимости выполняется повторная передача. Соединение в TCP позволяет вести передачу данных одновременно в обе стороны, то есть полнодуплексную передачу.
Соединение в протоколе TCP идентифицируется парой полных адресов обоих взаимодействующих процессов (оконечных точек). Адрес каждой из оконечных точек включает IP-адрес (номер сети и номер компьютера) и номер порта. Одна оконечная точка может участвовать в нескольких соединениях.
Установление соединения выполняется в следующей последовательности:
Источник:
http://www.citforum.ru/nets/ip/glava_6.shtml
Задачей протокола транспортного уровня UDP (User Datagram Protocol) является передача данных между прикладными процессами без гарантий доставки, поэтому его пакеты могут быть потеряны, продублированы или прийти не в том порядке, в котором они были отправлены.
В то время, как задачей сетевого уровня является передача данных между произвольными узлами сети, задача транспортного уровня заключается в передаче данных между любыми прикладными процессами, выполняющимися на любых узлах сети. Действительно, после того, как пакет средствами протокола IP доставлен в компьютер-получатель, данные необходимо направить конкретному процессу-получателю. Каждый компьютер может выполнять несколько процессов, более того, прикладной процесс тоже может иметь несколько точек входа, выступающих в качестве адреса назначения для пакетов данных.
Пакеты, поступающие на транспортный уровень, организуются операционной системой в виде множества очередей к точкам входа различных прикладных процессов. В терминологии TCP/IP такие системные очереди называются портами. Таким образом, адресом назначения, который используется на транспортном уровне, является идентификатор (номер) порта прикладного сервиса. Номер порта, задаваемый транспортным уровнем, в совокупности с номером сети и номером компьютера, задаваемыми сетевым уровнем, однозначно определяют прикладной процесс в сети.
Назначение номеров портов прикладным процессам осуществляется либо централизовано, если эти процессы представляют собой популярные общедоступные сервисы, типа сервиса удаленного доступа к файлам TFTP (Trivial FTP) или сервиса удаленного управления telnet, либо локально для тех сервисов, которые еще не стали столь распространенными, чтобы за ними закреплять стандартные (зарезервированные) номера.
Локальное присвоение номера порта заключается в том, что разработчик некоторого приложения просто связывает с ним любой доступный, произвольно выбранный числовой идентификатор, обращая внимание на то, чтобы он не входил в число зарезервированных номеров портов. В дальнейшем все удаленные запросы к данному приложению от других приложений должны адресоваться с указанием назначенного ему номера порта.
Протокол UDP ведет для каждого порта две очереди: очередь пакетов, поступающих в данный порт из сети, и очередь пакетов, отправляемых данным портом в сеть.
Хотя к услугам протокола UDP может обратиться любое приложение, многие из них предпочитают иметь дело с другим, более сложным протоколом транспортного уровня TCP. Дело в том, что протокол UDP выступает простым посредником между сетевым уровнем и прикладными сервисами, и, в отличие от TCP, не берет на себя никаких функций по обеспечению надежности передачи. UDP является дейтаграммным протоколом, то есть он не устанавливает логического соединения, не нумерует и не упорядочивает пакеты данных.
С другой стороны, функциональная простота протокола UDP обуславливает простоту его алгоритма, компактность и высокое быстродействие. Поэтому те приложения, в которых реализован собственный, достаточно надежный, механизм обмена сообщениями, основанный на установлении соединения, предпочитают для непосредственной передачи данных по сети использовать менее надежные, но более быстрые средства транспортировки, в качестве которых по отношению к протоколу TCP и выступает протокол UDP. Протокол UDP может быть использован и в том случае, когда хорошее качество каналов связи обеспечивает достаточный уровень надежности и без применения дополнительных приемов типа установления логического соединения и квитирования передаваемых пакетов.
Источник:
http://www.citforum.ru/nets/ip/glava_5.shtml
В рамках соединения правильность передачи каждого сегмента должна подтверждаться квитанцией получателя. Квитирование - это один из традиционных методов обеспечения надежной связи. Идея квитирования состоит в следующем.
Для того, чтобы можно было организовать повторную передачу искаженных данных отправитель нумерует отправляемые единицы передаваемых данных (далее для простоты называемые кадрами). Для каждого кадра отправитель ожидает от приемника так называемую положительную квитанцию - служебное сообщение, извещающее о том, что исходный кадр был получен и данные в нем оказались корректными. Время этого ожидания ограничено - при отправке каждого кадра передатчик запускает таймер, и если по его истечению положительная квитанция на получена, то кадр считается утерянным. В некоторых протоколах приемник, в случае получения кадра с искаженными данными должен отправить отрицательную квитанцию - явное указание того, что данный кадр нужно передать повторно.
Существуют два подхода к организации процесса обмена положительными и отрицательными квитанциями: с простоями и с организацией "окна".
Метод с простоями требует, чтобы источник, пославший кадр, ожидал получения квитанции (положительной или отрицательной) от приемника и только после этого посылал следующий кадр (или повторял искаженный). Из рисунка 6.1 видно, что в этом случае производительность обмена данными существенно снижается - хотя передатчик и мог бы послать следующий кадр сразу же после отправки предыдущего, он обязан ждать прихода квитанции. Снижение производительности для этого метода коррекции особенно заметно на низкоскоростных каналах связи, то есть в территориальных сетях.
Во втором методе (с организацией окна) для повышения коэффициента использования линии источнику разрешается передать некоторое количество кадров в непрерывном режиме, то есть в максимально возможном для источника темпе, без получения на эти кадры ответных квитанций. Количество кадров, которые разрешается передавать таким образом, называется размером окна. Рисунок иллюстрирует данный метод для размера окна в W кадров. Обычно кадры при обмене нумеруются циклически, от 1 до W. При отправке кадра с номером 1 источнику разрешается передать еще W-1 кадров до получения квитанции на кадр 1. Если же за это время квитанция на кадр 1 так и не пришла, то процесс передачи приостанавливается, и по истечению некоторого тайм-аута кадр 1 считается утерянным (или квитанция на него утеряна) и он передается снова.
Если же поток квитанций поступает более-менее регулярно, в пределах допуска в W кадров, то скорость обмена достигает максимально возможной величины для данного канала и принятого протокола.
Этот алгоритм называют алгоритмом скользящего окна. Действительно, при каждом получении квитанции окно перемещается (скользит), захватывая новые данные, которые разрешается передавать без подтверждения.
В протоколе TCP реализована разновидность алгоритма квитирования с использованием окна. Особенность этого алгоритма состоит в том, что, хотя единицей передаваемых данных является сегмент, окно определено на множестве нумерованных байт неструктурированного потока данных, поступающих с верхнего уровня и буферизуемых протоколом TCP.
Квитанция посылается только в случае правильного приема данных, отрицательные квитанции не посылаются. Таким образом, отсутствие квитанции означает либо прием искаженного сегмента, либо потерю сегмента, либо потерю квитанции.
В качестве квитанции получатель сегмента отсылает ответное сообщение (сегмент), в которое помещает число, на единицу превышающее максимальный номер байта в полученном сегменте. Если размер окна равен W, а последняя квитанция содержала значение N, то отправитель может посылать новые сегменты до тех пор, пока в очередной сегмент не попадет байт с номером N+W. Этот сегмент выходит за рамки окна, и передачу в таком случае необходимо приостановить до прихода следующей квитанции.
Источник:
http://www.citforum.ru/nets/ip/glava_6.shtml
Среди протоколов канального уровня некоторые обеспечивают доставку данных в сетях с произвольной топологией, но только между парой соседних узлов (например, протокол PPP), а некоторые - между любыми узлами (например, Ethernet), но при этом сеть должна иметь топологию определенного и весьма простого типа, например, древовидную.
При объединении в сеть нескольких сегментов с помощью мотов или коммутаторов продолжают действовать ограничения на ее топологию: в получившейся сети должны отсутствовать петли. Действительно, мост или его функциональный аналог - коммутатор - могут решать задачу доставки пакета адресату только тогда, когда между отправителем и получателем существует единственный путь. В то же время наличие избыточных связей, которые и образуют петли, часто необходимо для лучшей балансировки нагрузки, а также для повышения надежности сети за счет существования альтернативного маршрута в дополнение к основному.
Сетевой уровень позволяет передавать данные между любыми, произвольно связанными узлами сети.
Реализация протокола сетевого уровня подразумевает наличие в сети специального устройства - маршрутизатора. Маршрутизаторы объединяют отдельные сети в общую составную сеть. К каждому маршрутизатору могут быть присоединены несколько сетей (по крайней мере две).
Маршрутиза́тор или ро́утер (от англ. router) — сетевое устройство, на основании информации о топологии сети и определённых правил принимающее решения о пересылке пакетов сетевого уровня модели OSI между различными сегментами сети. Работает на более высоком уровне, нежели коммутатор и является более совершенным по своей функциональности, чем сетевой мост.
Зам. Маршрутиза́тор – устройство, имеющее более одного сетевого интерфейса. (В.В. Кузнецов).
В сложных составных сетях почти всегда существует несколько альтернативных маршрутов для передачи пакетов между двумя конечными узлами. Задачу выбора маршрутов из нескольких возможных решают маршрутизаторы, а также конечные узлы.
Маршрут - это последовательность маршрутизаторов, которые должен пройти пакет от отправителя до пункта назначения.
Маршрутизатор выбирает маршрут на основании своего представления о текущей конфигурации сети и соответствующего критерия выбора маршрута. Обычно в качестве критерия выступает время прохождения маршрута, которое в локальных сетях совпадает с длиной маршрута, измеряемой в количестве пройденных узлов маршрутизации (в глобальных сетях принимается в расчет и время передачи пакета по каждой линии связи).
Для того, чтобы иметь информацию о текущей конфигурации сети, маршрутизаторы обмениваются маршрутной информацией между собой по специальному протоколу. Протоколы этого типа называются протоколами обмена маршрутной информацией (или протоколами маршрутизации).
Источник:
http://www.citforum.ru/nets/ip/glava_1.shtml#_1_3
Сетевой уровень позволяет передавать данные между любыми, произвольно связанными узлами сети. Реализация протокола сетевого уровня подразумевает наличие в сети специального устройства - маршрутизатора. Маршрутизаторы объединяют отдельные сети в общую составную сеть. К каждому маршрутизатору могут быть присоединены несколько сетей (по крайней мере две).
Маршрут - это последовательность маршрутизаторов, которые должен пройти пакет от отправителя до пункта назначения.
В стеке TCP/IP маршрутизаторы и конечные узлы принимают решения о том, кому передавать пакет для его успешной доставки узлу назначения, на основании так называемых таблиц маршрутизации (routing tables). В этой таблице в столбце "Адрес сети назначения" указываются адреса всех сетей, которым данный маршрутизатор может передавать пакеты. В каждой строке таблицы маршрутизации указывается один IP-адрес - адрес следующего маршрутизатора, которому нужно передать пакет. В случае, если в таблице маршрутов имеется более одной строки, соответствующей одному и тому же адресу сети назначения, то при принятии решения о передаче пакета используется та строка, в которой указано наименьшее значение в поле "Расстояние до сети назначения". При этом под расстоянием понимается любая метрика, используемая в соответствии с заданным в сетевом пакете классом сервиса.
Существуют различные алгоритмы построения таблиц для одношаговой маршрутизации. Их можно разделить на три класса:
Независимо от алгоритма, используемого для построения таблицы маршрутизации, результат их работы имеет единый формат. За счет этого в одной и той же сети различные узлы могут строить таблицы маршрутизации по своим алгоритмам, а затем обмениваться между собой недостающими данными, так как форматы этих таблиц фиксированы. Поэтому маршрутизатор, работающий по алгоритму адаптивной маршрутизации, может снабдить конечный узел, применяющий алгоритм фиксированной маршрутизации, сведениями о пути к сети, о которой конечный узел ничего не знает.
Фиксированная маршрутизация. Этот алгоритм применяется в сетях с простой топологией связей и основан на ручном составлении таблицы маршрутизации администратором сети. Алгоритм часто эффективно работает также для магистралей крупных сетей, так как сама магистраль может иметь простую структуру с очевидными наилучшими путями следования пакетов в подсети, присоединенные к магистрали.
Различают одномаршрутные таблицы, в которых для каждого адресата задан один путь, и многомаршрутные таблицы, определяющие несколько альтернативных путей для каждого адресата. При использовании многомаршрутных таблиц должно быть задано правило выбора одного из них. Чаще всего один путь является основным, а остальные - резервными.
Простая маршрутизация. Алгоритмы простой маршрутизации подразделяются на три подкласса:
Адаптивная маршрутизация. Это основной вид алгоритмов маршрутизации, применяющихся маршрутизаторами в современных сетях со сложной топологией. Адаптивная маршрутизация основана на том, что маршрутизаторы периодически обмениваются специальной топологической информацией об имеющихся в интерсети сетях, а также о связях между маршрутизаторами. Обычно учитывается не только топология связей, но и их пропускная способность и состояние.
Адаптивные протоколы позволяют всем маршрутизаторам собирать информацию о топологии связей в сети, оперативно отрабатывая все изменения конфигурации связей. Эти протоколы имеют распределенный характер, который выражается в том, что в сети отсутствуют какие-либо выделенные маршрутизаторы, которые бы собирали и обобщали топологическую информацию: эта работа распределена между всеми маршрутизаторами.
Источник:
http://www.citforum.ru/nets/ip/glava_4.shtml#_4_3
Как только компьютеров становится больше двух, возникает проблема выбора конфигурации физических связей или топологии. Под топологией сети понимается конфигурация графа, вершинам которого соответствуют конечные узлы сети (например, компьютеры) и коммуникационное оборудование (например, маршрутизаторы), а ребрам — электрические и информационные связи между ними. Число возможных конфигураций резко возрастает при увеличении числа связываемых устройств.
От выбора топологии связей зависят многие характеристики сети. Например, наличие между узлами нескольких путей повышает надежность сети и делает возможной балансировку загрузки отдельных каналов. Простота присоединения новых узлов, свойственная некоторым топологиям, делает сеть легко расширяемой. Экономические соображения часто приводят к выбору топологий, для которых характерна минимальная суммарная длина линий связи.
Среди множества возможных конфигураций различают полносвязные и неполносвязные:
Полносвязная топология соответствует сети, в которой каждый компьютер непосредственно связан со всеми остальными. Несмотря на логическую простоту, это вариант громоздкий и неэффективный. Чаще этот вид топологии используется в многомашинных комплексах или в сетях, объединяющих небольшое количество компьютеров.
Все другие варианты основаны на неполносвязных топологиях, когда для обмена данными между двумя компьютерами может потребоваться промежуточная передача данных через другие узлы сети.
Ячеистая топология (mesh1) получается из полносвязной путем удаления некоторых возможных связей. Ячеистая топология допускает соединение большого количества компьютеров и характерна для крупных сетей.
В сетях с кольцевой конфигурацией данные передаются по кольцу от одного компьютера к другому. Главное достоинство "кольца" в том, что оно по своей природе обладает свойством резервирования связей. В то же время в сетях с кольцевой топологией необходимо принимать специальные меры, чтобы в случае выхода из строя или отключения какой-либо станции не прерывался канал связи между остальными станциями "кольца".
Топология "звезда" образуется в том случае, когда каждый компьютер с помощью отдельного кабеля подключается к общему центральному устройству, называемому концентратором. В функции концентратора входит направление передаваемой компьютером информации одному или всем остальным компьютерам сети. В роли концентратора может выступать как компьютер, так и специализированное устройство, такое как многовходовый повторитель, коммутатор или маршрутизатор. К недостаткам топологии типа "звезда" относится более высокая стоимость сетевого оборудования, связанная с необходимостью приобретения специализированного центрального устройства. Кроме того, возможности наращивания количества узлов в сети ограничиваются количеством портов концентратора.
Иногда имеет смысл строить сеть с использованием нескольких концентраторов, иерархически соединенных между собой связями типа "звезда". Получаемую в результате структуру называют также деревом. В настоящее время дерево является самым распространенным типом топологии связей, как в локальных, так и в глобальных сетях.
Особым частным случаем конфигурации звезда является конфигурация "общая шина". Здесь в роли центрального элемента выступает пассивный кабель, к которому по схеме "монтажного ИЛИ" подключается несколько компьютеров. Основными преимуществами такой схемы являются низкая стоимость и простота наращивания, т.е. присоединения новых узлов к сети. Самым серьезным недостатком "общей шины" является ее недостаточная надежность. Другой недостаток "общей шины" — невысокая производительность.
В то время как небольшие сети, как правило, имеют типовую топологию — "звезда", "кольцо" или "общая шина", для крупных сетей характерно наличие произвольных связей между компьютерами. В таких сетях можно выделить отдельные произвольно связанные фрагменты (подсети), имеющие типовую топологию, поэтому их называют сетями со смешанной топологией.
Современные вычислительные сети часто строятся с использованием нескольких различных базовых технологий - Ethernet, Token Ring или FDDI. Такая неоднородность возникает либо при объединении уже существовавших ранее сетей, использующих в своих транспортных подсистемах различные протоколы канального уровня, либо при переходе к новым технологиям, таким, как Fast Ethernet или 100VG-AnyLAN.
Именно для образования единой транспортной системы, объединяющей несколько сетей с различными топологиями и принципами передачи информации между конечными узлами, и служит сетевой уровень. Когда две или более сетей организуют совместную транспортную службу, то такой режим взаимодействия обычно называют межсетевым взаимодействием (internetworking). Для обозначения составной сети в англоязычной литературе часто также используется термин интерсеть (internetwork или internet).
Создание сложной структурированной сети, интегрирующей различные базовые технологии, может осуществляться и средствами канального уровня: для этого могут быть использованы некоторые типы мостов и коммутаторов. Однако возможностью трансляции протоколов канального уровня обладают далеко не все типы мостов и коммутаторов, к тому же возможности эти ограничены. В частности, в объединяемых сетях должны совпадать максимальные размеры полей данных в кадрах, так как канальные протоколы, как правило, не поддерживают функции фрагментации пакетов.
Реализация протокола сетевого уровня подразумевает наличие в сети специального устройства - маршрутизатора. Маршрутизаторы объединяют отдельные сети в общую составную сеть. К каждому маршрутизатору могут быть присоединены несколько сетей (по крайней мере две). В сложных составных сетях почти всегда существует несколько альтернативных маршрутов для передачи пакетов между двумя конечными узлами.
Зам. Под физической топологией понимается конфигурация связей, образованных отдельными частями кабеля, а под логической - конфигурация информационных потоков между компьютерами сети. Во многих случаях физическая и логическая топологии сети совпадают. (Олиферы)
Источники:
http://www.coop.chuvashia.ru/kartuzov/it/Books/02/Olifer/network/networkbasics/4/1.html
http://www.citforum.ru/nets/ip/glava_1.shtml#_1_4
Сетево́й протоко́л — набор правил, позволяющий осуществлять соединение и обмен данными между двумя включёнными в сеть компьютерами. Разные протоколы зачастую описывают лишь разные стороны одного типа связи; взятые вместе, они образуют стек протоколов.
TCP/IP (Transmission Control Protocol/Internet Protocol) представляет собой семейство протоколов, основным назначением которых является обеспечение возможности полезного сосуществования компьютерных сетей, основанных на разных технологиях. В 1969 году Агентство перспективных исследовательских проектов министерства обороны США (DARPA - Department of Defense Advanced Research Project Agency) поддержало и финансировало проект, посвященный поиску общей основы связи сетей с разной технологией. В результате выполнения этого проекта была образована единая виртуальная сеть, получившая название Internet. В Internet для связи независимых сетей, или доменов используется набор шлюзов. Каждый индивидуальный узел сети (Host) идентифицируется уникальным адресом, называемым адресом в Internet.
Для разрешения проблемы различий в форматах кадров, используемых в разных сетях, был определен универсальный формат пакета данных, называемого IP-датаграммой (Internet Protocol Datagram), состоящего из заголовка и порции данных и поэтому похожего на обычный сетевой кадр. Однако порция данных IP-датаграммы сама содержится внутри сетевого кадра, т.е. IP-датаграмма погружается в сетевой кадр конкретного формата и поэтому может передаваться в разных сетях, входящих в Internet. Все узлы, шлюзы и сети Internet должны быть в состоянии понимать IP-датаграммы.
Полное семейство протоколов, основанных на использовании IP-датаграмм, называется TCP/IP. Наиболее важными и базисными протоколами этого семейства (или стека, как его часто называют) являются протоколы IP и TCP. Большая часть коммуникационных средств ОС UNIX основывается на использовании протоколов стека TCP/IP.
Существуют разногласия в том, как вписать модель TCP/IP в модель OSI, поскольку уровни в этих моделях не совпадают. Вот как традиционно протоколы TCP/IP вписываются в модель OSI:
|
7 |
Прикладной |
напр. HTTP, SMTP, SNMP, FTP, Telnet, scp, NFS, RTSP |
|
6 |
Представительный |
напр. XML, XDR, ASN.1, SMB, AFP |
|
5 |
Сеансовый |
напр. TLS, SSH, ISO 8327 / CCITT X.225, RPC, NetBIOS, ASP |
|
4 |
Транспортный |
напр. TCP, UDP, RTP, SCTP, SPX, ATP, DCCP, BGP, GRE |
|
3 |
Сетевой |
напр. IP, ICMP, IGMP, CLNP, ARP, RARP, OSPF, RIP, IPX, DDP |
|
2 |
Канальный |
напр. Ethernet, Token ring, PPP, HDLC, X.25, Frame relay, ISDN, ATM, MPLS |
|
1 |
Физический |
напр. электричество, радио, лазер |
Обычно в стеке TCP/IP верхние 3 уровня (прикладной, представительный и сеансовый) модели OSI объединяют в один — прикладной. Поскольку в таком стеке не предусматривается унифицированный протокол передачи данных, функции по определению типа данных передаются приложению. Упрощенно интерпретацию стека TCP/IP можно представить так:
|
5 |
Прикладной«7 уровень» |
напр. HTTP, FTP, DNS (RIP, работающий поверх UDP, и BGP, работающий поверх TCP, являются частью сетевого уровня) |
|
4 |
Транспортный |
напр. TCP, UDP, RTP, SCTP, DCCP (протоколы маршрутизации, подобные OSPF, что работают поверх IP, являются частью сетевого уровня) |
|
3 |
Межсетевой |
Для TCP/IP это IP (IP) (вспомогательные протоколы, вроде ICMP и IGMP работают поверх IP, но являются частью сетевого уровня; ARP не работает поверх IP) |
|
2 |
Канальный |
напр. Ethernet, Token ring, и подобные. |
|
1 |
Физический |
напр. физическая среда и принципы кодирования информации, T1, E1 |
Источники:
http://ru.wikipedia.org/wiki/Сетевой_протокол
http://ru.wikipedia.org/wiki/Стек_протоколов
http://ru.wikipedia.org/wiki/TCP/IP
В компьютерных сетях сетевым интерфейсом называют:
Зам. Наш любимый преподаватель по всей видимости имел ввиду некий набор программных и аппаратных средств, используемых для обеспечения взаимодействия двух узлов сети.
Сетевая карта или сетевой адаптер - это плата расширения, вставляемая в разъем материнской платы (main board) компьютера. Также существуют сетевые адаптеры стандарта PCMCIA для нотебуков (notebook), они вставляются в специальный разъем в корпусе нотебука. Или интегрированные на материнской плате компьютера, они подключаются по какой либо локальной шине. Появились Ethernet сетевые карты подключаемые к USB (Universal Serial Bus) порту компьютера.
Сетевые платы характеризуются своей
Для определения точки назначения пакетов (frames) в сети Ethernet используется MAC-адрес. Это уникальный серийный номер присваиваемый каждому сетевому устройству Ethernet для идентификации его в сети. При работе сетевые адаптеры просматривают весь проходящий сетевой трафик и сравнивают в каждом пакете адрес назначения и свой MAC-адрес. Если таковой находится, то устройсво (адаптер) декодирует этот пакет и его обработка продолжается на более высоком уровне модели OSI (канальный и сетевой). Существуют также специальные способы по рассылке пакетов всем устройствам сети одновременно (broadcasting). MAC-адрес имеет длину 6 байт и обычно записывается в шестнадцетиричном виде, например 12:34:56:78:90:AB.
Каждый компьютер в сети IP имеет еще и IP-адрес, состоящий из 4 байт, например, 109.26.17.100. Этот адрес используется на сетевом уровне. Он назначается администратором во время конфигурирования компьютеров и маршрутизаторов. IP-адрес состоит из двух частей: номера сети и номера узла. Номер сети может быть выбран администратором произвольно, либо назначен по рекомендации специального подразделения Internet (Network Information Center, NIC), если сеть должна работать как составная часть Internet. Обычно провайдеры услуг Internet получают диапазоны адресов у подразделений NIC, а затем распределяют их между своими абонентами.
Номер узла в протоколе IP назначается независимо от локального адреса узла. Деление IP-адреса на поле номера сети и номера узла - гибкое, и граница между этими полями может устанавливаться весьма произвольно. Узел может входить в несколько IP-сетей. В этом случае узел должен иметь несколько IP-адресов, по числу сетевых связей. Таким образом IP-адрес характеризует не отдельный компьютер или маршрутизатор, а одно сетевое соединение.
При совпадении IP-адреса назначения в принимаемом пакете и своего собственного этот пакет обрабатывается на сетевом уровне и передается на транспортный.
Источники:
http://ru.wikipedia.org/wiki/Сетевой_интерфейс
http://www.tula.net/tgpu/resources/yakushin/html_labs/lab01/lab01netadapt.htm
http://www.citforum.ru/nets/ip/glava_3.shtml#_3_1
В компьютерной сети можно одновременно пользоваться разнообразной информацией. В компьютерных сетях вместо словосочетания "источник информации" используется слово "сервер", происходящее от англ. server - "обслуживающий", а клиент - это просто тот, кто запрашивает информацию у сервера. Вот и все!
Клиент-сервер (англ. Сlient/Server) — сетевая архитектура, в которой устройства являются либо клиентами, либо серверами. Клиентом (front end) является запрашивающая машина (обычно ПК), сервером (back end) — машина, которая отвечает на запрос. Оба термина (клиент и сервер) могут применяться как к физическим устройствам, так и к программному обеспечению.
В информационных технологиях клие́нт — это аппаратный или программный компонент вычислительной системы, посылающий запросы серверу. Программа, являющаяся клиентом, взаимодействует с сервером, используя определенный протокол. Она может запрашивать с сервера какие-либо данные, манипулировать данными непосредственно на сервере, запускать на сервере новые процессы и т. п. Полученные от сервера данные клиентская программа может предоставлять пользователю или использовать как-либо иначе, в зависимости от назначения программы. Программа-клиент и программа-сервер могут работать как на одном и том же компьютере, так и на разных. Во втором случае для обмена информацией между ними используется сетевое соединение.
Се́рвер (англ. server от англ. to serve — служить) — в информационных технологиях — программный компонент вычислительной системы, выполняющий сервисные функции по запросу клиента, предоставляя ему доступ к определённым ресурсам. Для взаимодействия с клиентом (или клиентами, если поддерживается одновременная работа с несколькими клиентами) сервер выделяет необходимые ресурсы межпроцессного взаимодействия (разделяемая память, пайп, сокет, и т. п.) и ожидает запросы на открытие соединения (или, собственно, запросы на предоставляемый сервис). В зависимости от типа такого ресурса, сервер может обслуживать процессы в пределах одной компьютерной системы или процессы на других машинах через каналы передачи данных (например COM-порт) или сетевые соединения.
В зависимости от выполняемых задач одни серверы, при отсутствии запросов на обслуживание, могут простаивать в ожидании. Другие могут выполнять какую-то работу (например, работу по сбору информации), у таких серверов работа с клиентами может быть второстепенной задачей.
Формат запросов клиента и ответов сервера определяется протоколом. Спецификации открытых протоколов описываются открытыми стандартами, например протоколы Интернета определяются в документах RFC.
Чаще всего понятия «клиент» и «сервер» описывают распределение ролей при выполнении конкретной задачи, а не вычислительные мощности. На одном и том же компьютере могут одновременно работать программы, выполняющие как клиентские, так и серверные функции. Например, веб-сервер может, в качестве клиента, получать данные для формирования страниц от SQL-сервера (так работает Википедия).
Источники:
http://www.mstu.edu.ru/education/materials/telecommlab/lab_010.html
http://ru.wikipedia.org/wiki/Клиент-сервер
http://ru.wikipedia.org/wiki/Клиент_(программный)
http://ru.wikipedia.org/wiki/Сервер_(приложение)
Класс WinSock позволяет работать с сокетами в рамках трех подходов, против двух классических. А именно, обычная блокирующая передача данных, неблокирующая передача данных, событийно ориентированная передача данных.
При 3 подходе создаваемый сокет имеет ряд связанных с ним событий, реакцию на которые определяет пользователь.
Общеизвестный факт, что все ПО развивается в сторону унификации интерфейса, это позволяет значительно упростить и ускорить его использование для пользователя. Вполне логично, что унификация программного API приводит к более эффективному и грамотному его использованию программистами, которые выступают в роли потребителей API. В событийном подходе мы исходим от события, мы знаем для какого сокета есть новости.
Если задуматься на тему что такое поступление новых данных в сокет или, например, что такое закрытие сокета с другой стороны. Можно придти к простому выводу - это события. Такие же события, как наступления времени Х или любое другое событие в программе. Более того, абсолютно законна постановка вопроса: "ждем пока произойдет какое-нибудь событие или пока придут данные от сокета". Поэтому это правильно и логично, что и работа с сокетами должна строится на событиях.
Для работы с сокетами в ходе лаб использовался класс CAsyncSocket, который инкапсулирует возможности работы с WinSock. Основными событиями в данном классе являются следующие:
|
OnAccept |
Уведомляет слушающий сокет (сервера) о приходе запроса на установление соединения от удаленного сокета (клиента; метод Accept). |
|
OnClose |
Уведомляет сокет о разрыве соединения с ним. |
|
OnConnect |
Уведомляет сокет, пытающийся установить соединение, о том, что попытка соединения завершена (как успешно, так и с ошибкой). |
|
OnReceive |
Уведомляет сокет о наличии в буфере принятых данных, которые могут быть прочитаны с помощью вызова Receive. |
|
OnSend |
Уведомляет сокет о возможности передачи данных с помощью вызова Send. |
Источники:
http://www.kalinin.ru/programming/network/12_12_00.shtml
http://msdn2.microsoft.com/en-us/library/09353w3t(VS.80).aspx
Чтобы две программы могли общаться друг с другом через сеть, каждая из них должна создать сокет. Каждый сокет обладает двумя основными характеристиками: протоколом и адресом, к которым он привязан. Протокол задаётся при создании сокета и не может быть изменён впоследствии. Адрес сокета задаётся позже, но обязательно до того, как через сокет пойдут данные. Формат адреса сокета определяется конкретным протоколом. В частности, для протоколов TCP и UDP адрес состоит из IP-адреса сетевого интерфейса и номера порта.
При использовании TCP сервер сам не является инициатором подключения, но может работать с любым подключившимся клиентом, какой бы у него ни был адрес. Для сервера принципиально, какой порт он будет использовать - если порт не определён заранее, клиент не будет знать, куда подключаться. Поэтому номер порта является важным признаком для сервера. С другой стороны, клиенту обычно непринципиально, какой порт будет у его сокета, поэтому чаще всего сервер использует фиксированный порт, а клиент оставляет выбор системе.
Протокол UDP не поддерживает соединение, но при его использовании часто одно приложение тоже можно условно назвать сервером, а другое - клиентом. Сервер создаёт сокет и ждёт, когда кто-нибудь что-нибудь пришлёт и высылает что-то в ответ, а клиент сам отправляет что-то куда-то. Поэтому, как и в случае TCP, сервер должен использовать фиксированный порт, а клиент может выбирать любой свободный.
В программе-сервер закладывается способность ожидать появления запроса от клиента на определенном порту. Для этого используется отдельный сокет. Для установления соединения с каждым клиентом сервер выделяет один сокет. Клиенту для организации взаимодействия с сервером необходим один сокет. Таким образом для создания N соединений будет задействован 2N + 1 сокет.
Источники:
http://www.delphikingdom.com/asp/viewitem.asp?catalogid=1021
http://home.tula.net/angel/les15.html
Если у сервера не осталось свободных сокетов для подключения очередного клиента, то необходимо организовать соединение с фиктивным сокетом для продвижения очереди запросов, после чего сразу же его разорвать.
Для организации соединения с сервером клиент создает сокет (функция Create(), номер порта не важен) и отправляет запрос на подключение к сокету сервера Connect(m_ipaddr, m_port). При завершении попытки вызывается событие OnConnect(ErrCode). При установке соединения ErrCode = 0.
Для организации сетевого соединения сервер создает слушающий сокета с заданным номером порта (функция Create(n_port), IP адрес присваивается сам) и запускает его на прослушивание среды (функция Listen());
При приеме от клиента запроса на подключение (событие OnAccept) сервер выделяет клиенту сокет для организации соединения (метод Accept для выделяемого сокета).
Приложение клиент должно имеет один сокет для установления соединения с сервером.
В программе-сервер закладывается способность ожидать появления запроса от клиента на определенном порту. Для этого используется отдельный сокет. Для установления соединения с каждым клиентом сервер выделяет один сокет.
Каждый процесс может создать слушающий сокет и привязать его к какому-нибудь порту компьютера. Слушающий процесс обычно находится в цикле ожидания, то есть просыпается при появлении нового соединения. При этом сохраняется возможность просто проверить наличие соединений на данный момент, установить тайм-аут для операции и так далее.
Обычно клиент явно подсоединяется к слушателю, после чего любое чтение или запись через его файловый дескриптор будут на самом деле передавать данные между ним и сервером.
Зам. Такое соединение точка-точка между 2 сокетами по всей видимости называется гнездовым.
Источник:
http://ru.wikipedia.org/wiki/Сокет_(программный_интерфейс)
Сокетом (от англ. socket - гнездо, розетка) называется специальный объект, создаваемый для отправки и получения данных через сеть. Этот объект создаётся внутри библиотеки сокетов, а программист, использующий эту библиотеку, получает уникальный номер (дескриптор) этого сокета. Конкретное значение этого дескриптора не несёт для программиста никакой полезной информации и может быть использовано только для того, чтобы при вызове функции из библиотеки сокетов указать, с каким сокетом требуется выполнить операцию.
Чтобы две программы могли общаться друг с другом через сеть, каждая из них должна создать сокет. Каждый сокет обладает двумя основными характеристиками: протоколом и адресом, к которым он привязан. Протокол задаётся при создании сокета и не может быть изменён впоследствии. Адрес сокета задаётся позже, но обязательно до того, как через сокет пойдут данные. В некоторых случаях привязка сокета к адресу может быть неявной.
Каждый сокет имеет два буфера: для входящих и для исходящих данных. При отправке данных они сначала кладутся в буфер исходящих, и лишь затем отправляются в фоновом режиме. Программа в это время продолжает свою работу. При получении данных сокет кладёт их в буфер для входящих, откуда они затем могут извлекаться программой.
После организации соединения сокетов любое чтение или запись через файловый дескриптор одного из них будут на самом деле передавать данные между ним и парным ему сокетом другого приложения.
Источник:
Надергано из предыдущих вопросов.
Когда мы создаем сокет (socket - гнездо), мы получаем возможность доступа к нужному нам уровню OSI. Ну а дальше мы можем использовать соответствующие вызовы для взаимодействия с ним. Сокеты устроены таким образом, что они могут взаимодействовать с ОС на любом уровне OSI, скрывая ту часть реализации, которой мы не интересуемся
В то время, как задачей сетевого уровня является передача данных между произвольными узлами сети, задача транспортного уровня заключается в передаче данных между любыми прикладными процессами, выполняющимися на любых узлах сети. Действительно, после того, как пакет средствами протокола IP доставлен в компьютер-получатель, данные необходимо направить конкретному процессу-получателю. Каждый компьютер может выполнять несколько процессов, более того, прикладной процесс тоже может иметь несколько точек входа, выступающих в качестве адреса назначения для пакетов данных.
Пакеты, поступающие на транспортный уровень, организуются операционной системой в виде множества очередей к точкам входа различных прикладных процессов. В терминологии TCP/IP такие системные очереди называются портами. Таким образом, адресом назначения, который используется на транспортном уровне, является идентификатор (номер) порта прикладного сервиса. Номер порта, задаваемый транспортным уровнем, в совокупности с номером сети и номером компьютера, задаваемыми сетевым уровнем, однозначно определяют прикладной процесс в сети.
Зам. На лабах мы юзали сокеты с номерами порта и IP адресом, то есть их средства доступа к транспортному уровню и сетевому уровню. На консультации было сказано, что каким-то боком туда относится и сеансовый уровень. Типа, сервер ведущий, клиент ведомый или что-то такое.
Источники:
http://www.gamedev.ru/articles/?id=80201&page=3
http://www.citforum.ru/nets/ip/glava_5.shtml
Зам. Понятие стека протоколов IP отсутствует. Его нет в природе. Протокол IP является базовым для стека TCP/IP. Возможно, имелся ввиду именно этот стек.
Чтобы две программы могли общаться друг с другом через сеть, каждая из них должна создать сокет. Каждый сокет обладает двумя основными характеристиками: протоколом и адресом, к которым он привязан. Протокол задаётся при создании сокета и не может быть изменён впоследствии. Адрес сокета задаётся позже, но обязательно до того, как через сокет пойдут данные. Формат адреса сокета определяется конкретным протоколом. В частности, для протоколов TCP и UDP адрес состоит из IP-адреса сетевого интерфейса и номера порта.
Протокол IP (RFC 791) используется для ненадёжной доставки данных от одного узла сети к другому. Это означает, что на уровне этого протокола (третий уровень сетевой модели OSI) не даётся гарантий надёжной доставки пакета до адресата. В частности, пакеты могут прийти не в том порядке, в котором были отправлены, оказаться повреждёнными или не прибыть вовсе. Гарантии безошибочной доставки пакетов дают протоколы более высокого (транспортного) уровня сетевой модели OSI — например, TCP — которые используют IP в качестве транспорта.
В протоколе TCP также, как и в UDP, для связи с прикладными процессами используются порты. Номера портам присваиваются аналогичным образом: имеются стандартные, зарезервированные номера (например, номер 21 закреплен за сервисом FTP, 23 - за telnet), а менее известные приложения пользуются произвольно выбранными локальными номерами.
Зам. На лабах мы юзали сокеты с номерами порта и IP адресом, то есть их средства доступа к транспортному уровню (протокол TCP) и сетевому уровню (протокол IP) стека TCP/IP. На консультации было сказано, что каким-то боком туда относится и сеансовый уровень OSI (прикладной TCP/IP). Типа, сервер ведущий, клиент ведомый или что-то такое.
Источники:
http://ru.wikipedia.org/wiki/IP
Windows API (application programming interfaces) — общее наименование для целого набора базовых функций интерфейсов программирования приложений операционных систем семейств Windows и Windows NT корпорации Майкрософт. Является самым прямым способом взаимодействия приложений с Windows. Для создания программ, использующих Windows API, Майкрософт выпускает SDK, который называется Platform SDK и содержит документацию, набор библиотек, утилит и других инструментальных средств. Windows API был изначально спроектирован для использования в программах, написанных на языке C (или C++). Работа через Windows API — это наиболее близкий к системе способ взаимодействия с ней из прикладных программ.
Через Windows API доступна технология работы с сокетами Windows Sockets.
Сокеты Windows (Winsock) - это интерфейс прикладного программирования, разработанный на основе сокетов Беркли. Сокеты Беркли используются на различных ОС, а Winsock - для Windows 3.х, Windows NT, Windows 95. В состав Winsock входит множество функций из интерфейса Беркли. Кроме того имеется ряд специфических функций, позволяющих использовать интерфейс Windows. Спецификация Winsock описывает стандарт, по которому программы Windows обязаны общаться с сетями TCP/IP. Корпорация Microsoft не имеет имущетсвенных прав на стандарт Winsock. Цель разработки - создание единого интерфейса прикладного программирования с TCP/IP. В UNIX интерфейс сокетов был встроен в систему. Интерфейс Winsock не входит в состав Windows, а реализован в виде динамически загруженной библиотеки DLL.
API Winsock содержит набор функций. Спецификация Winsock разбивает их на три группы:
- функции сокетов в стиле Бекркли включены в Winsock API;
- функции для работы с базами данных, позволяющие программам получать информацию об именах доменов, протоколах и т.д.
- функции, распределяющие набор функций интерфейса сокетов Беркли.
Кроме того все функции можно разделить на две большие группы: блокирующие и не блокирующие. Блокирующая функция заставляет вызвавшую ее программу ждать окончательно сетевой операции ввода-вывода. Не блокирующая функция не ждет окончания ожидания.
Изначально сокеты были встроены в Unix. Затем библиотеки были разработаны для других систем. Несмотря на различия в операционных системах, исходные тексты программ различаются несущественно. Чтобы выполнить определенные действия, нужно вызвать соответственные функции.
Исходники:
http://ru.wikipedia.org/wiki/Windows_API
http://home.tula.net/angel/les15.html
http://home.tula.net/angel/les17.html
MFC поддерживает WinSock через два класса: CAsyncSocket и CSocket. CAsyncSocket - это класс, который инкапсулирует возможности работы с WinSock API. CSocket - это более высокоуровневый класс, который происходит от CAsyncSocket. И естественно обеспечивает работу более высокого уровня.
Как и для многих других объектов MFC, создание сокета состоит из двух этапов: создание объекта класса путем вызова его конструктора и создание системного сокета путем вызова функции Create.
Конструктор класса CAsyncSocket не принимает никаких параметров, поскольку просто создает новый пустой объект. Вся работа по фактической инициализации сокета выполняется функцией Create.
Функция Create принимает ряд параметров, как показано в ее прототипе: BOOL Create( UNIT nSocketPort = О, int nSocketType = SOCK_STREAM, long lEvent = FD_READ | FD_WRITE | FD_OOB | FD_ACCEPT |FD_CONNECT | FD_CLOSE, LPCTSTR IpszSocketAddress = NULL ) ;
Первый параметр определяет номер порта, ассоциируемого с сокетом. По умолчанию он равен 0, т.е. система сама должна выбирать порт по своему усмотрению. Во многих случаях, особенно в приложениях типа "сервер", бывает необходимо ассоциировать с сокетом номер порта, заранее известный при разработке приложения. Приложения-клиенты используют этот порт для обмена данными с сервером.
Параметр nSocketType указывает тип сокета — сокет потока (SOCKSTREAM) или сокет дейтаграмм (SOCK_DGRAM).
Параметр lEvent определяет события, в случае которых приложение получает извещение от системы. По умолчанию генерируются сообщения для всех предусмотренных событий.
В последнем параметре указывается сетевой адрес для привязки сокета. По умолчанию он равен 0, что означает привязку сокета к адресу локального компьютера, однако можно указать и другой адрес. Для IP-реализации интерфейса WinSock это будет строка, содержащая нужный IP-адрес — например, 192.9.200.93.
Кроме того, класс CAsyncSocket автоматически выполняет распознавание машинных имен, так что можно указывать адреса наподобие ftp.racotek.com.
Для получения адреса, ассоциированного с сокетом, используется метод GetSockName класса CAsyncSocket.
Большинство методов класса CAsyncSocket возвращает true, если вызов выполнен успешно, и falsе если произошла ошибка. В последнем случае код ошибки можно получить вызовом функции CAsync Socket::GetLastError.
Отправка и прием дейтаграмм. Для сокета (объекта класса CAsyncSockets) типа SOCK_DGRAM в классе имеются специальные методы. Они могут использоваться для посылки дейтаграмм по указанному адресу без лишних операций по открытию отдельного соединения или получения дейтаграммы и адреса ее отправителя из других приложений.
Сокеты потоков в приложениях-клиентах подсоединяются к серверу путем вызова метода Connect, который может принимать два набора параметров. Первая версия метода Connect принимает в качестве параметров машинный адрес в виде ASCII-строки, например 192.9.200.93 или ftp.racotek.com, а также номер порта. Во вторую версию передается структура SOCKADDR, хранящую информацию об адрее. Функция Connect возвращает значение TRUE, если подключение прошло успешно, и FALSE, если произошла ошибка. В этом случае для получения кода ошибки вызывается функция GetLastError. По умолчанию для извещения о событиях в классе CAsyncSocket используются обратные дозвоны. В этом случае, если функция Connect не полностью выполняет подключение, она возвращает значение FALSE и при последующем вызове функции GetLastError возвращается значение WSAEWOULDBLOCK.
По завершении работы Connect независимо от того, был ли вызов успешным или нет, вызывается обработчик сообщений — функция OnConnect. Функция OnConnect может перекрываться в классах, производных от CAsyncSocket. Вот ее прототип:
virtual void OnConnect( int nErrorCode };
Если параметр nErrorCode равен 0, соединение открыто успешно и сокет готов к приему и посылке данных. Если при попытке подключения произошла ошибка, параметр nErrorCode будет содержать код этой ошибки.
После создания сокета потока на сервере путем вызова конструктора класса и метода Create сокет может приступить к ожиданию запросов на подключение. Это выполняется вызовом метода Listen класса CAsyncSocket. Он принимает в качестве параметра количество запросов на подключение, которое должно скопиться во входной очереди для удовлетворения запроса или возвращения клиентам кода WSAECONNREFUSED, обозначающего отказ в подсоединении к серверу. По умолчанию это значение равно 5,
Для удовлетворения запроса и подключения клиента используется метод Accept. Вот прототип этого метода:
virtual. BOOL Accept( CAsyncSocketSi rConnectedSocket, SOCKADDR* IpSockAddr = NULL, int* IpSockAddrLen = NULL ) ;
Первый параметр — адрес сокета, управляющего новым соединением. Это должна быть ссылка на сокет, предварительно созданный путем вызова конструктора класса CAsyncSocket, но без вызова метода Create. Кроме того, в метод передается указатель на структуру SOCKADDR и ее длину; эта структура заполняется адресом сокета клиента.
Функция Accept обычно вызывается из метода OnAccept, который может перекрываться в классах, производных от CAsyncSocket. Метод OnAccept вызывается всякий раз, когда во входной очереди сокета CAsyncSocket появляется запрос на подключение к серверу.
Таким образом, методу Accept нет нужды ожидать запросы в блокирующем режиме. В функцию OnAccept передается один параметр — код ошибки. Если это 0, все идет нормально и вызов Accept должен пройти успешно.
Посылка данных через сокет потока выполняется методом Send класса CAsyncSocket. Как и его аналог в интерфейсе WinSock С API, функция Send принимает указатель на буфер и длину буфера данных. Можно также передать в нее параметр flags со значением MSG_DOUNTROUTE для пересылки данных без маршрутизации или со значением MSG_OOB для пересылки привилегированных данных.
Если извещающая функция OnSend реализована в производном классе, она вызывается после освобождения буфера, при готовности сокета к следующей операции по пересылке данных.
Однако такое извещение обычно применяется только в приложениях с большим объемом обмена данными, а стандартная реализация этой функции в классе CAsyncSocket не делает ничего. Напротив, функция OnReceive довольно часто переопределяется в классах, производных от CAsyncSocket. Она вызывается при поступлении данных на сокет; данные будут находиться в его буфере, пока приложение не прочитает их путем вызова метода Receive класса CAsyncSocket.
Метод CAsyncSocket:: Receive принимает указатель на буфер и его длину, а также необязательный параметр flags, который может иметь значение MSG_PEEK для чтения данных без удаления их из буфера (чтобы их можно было прочитать следующими вызовами Receive) или MSG_OOB для чтения привилегированных данных. Функция Receive считывает такой объем данных, какой доступен во входной очереди сокета, но не больше, чем указано в переданном параметре длины буфера. Если соединение закрывается корректно, метод Receive возвращает 0, иначе SOCKET_ERROR; функция GetLastError в этом случае возвращает значение WSACONNRESET.
Код SOCKET_ERROR возвращается также при возникновении любой другой ошибки, код которой можно получить вызовом функции WSAGetLastError .
После завершения работы с сокетом (объектом класса CAsyncSocket) его необходимо закрыть методом Close для освобождения системных ресурсов, ассоциированных с сокетом. Метод Close автоматически вызывается из деструктора класса CAsyncSocket при явном удалении объекта или выходе его за допустимый диапазон.
Поведение функции Close определяется параметрами сокета SO_LINGER и SO_DONTLINGER. С помощью метода Disable для данного сокета класса CAsyncSocket можно заблокировать (запретить) посылку или прием данных, либо обе эти операции. Обычно это делается, только если сокет скоро должен закрыться, чтобы его нельзя было использовать повторно. Для явного освобождения системных ресурсов в этом случае также необходимо вызывать метод Close.
Источники:
http://helpsite.narod.ru/vc/mfc/268.htm
Програмирование сокетов идет поэтапно:
1.Создание сокета
2.Привязка сокета к локальным именам
3.Установка связи
4.Передача данных
5.Закрытие сокета
Для работы с сокетами средствами языка C++ можно создать объект класса CAsyncSocket и использовать его члены. См. предыдущий билет.
// функция реакции на возможность передачи
void CProtocol::OnSend(int ErrCode)
{
CAsyncSocket::OnSend(ErrCode);
m_SendDataSize = 0;
while (m_SendDataSize < m_SendMemory.GetSize()) // пока есть данные для отправки
{
int n = Send(((BYTE*)m_SendMemory.GetAddr() + m_SendDataSize), m_SendMemory.GetSize()-m_SendDataSize); // запись в буфер сетевухи
// Анализ ошибок
if (n == SOCKET_ERROR)
{
ErrCode = GetLastError();
if (ErrCode != WSAEWOULDBLOCK)
{
CString s;
s.Format("Ошибка при передаче! Код ошибки %u", ErrCode);
MessageBox(0,s,"Сообщение",MB_OK);
Close();
}
}
else m_SendDataSize+= n;
}
m_SendMemory.Alloc(0);
m_SendDataSize = 0;
}
// функция посылки данных
void CProtocol::SendPacket(const void* p, DWORD size)
{
m_SendMemory.AddToMemory(&size, sizeof(DWORD)); // добавление размера данных
m_SendMemory.AddToMemory((BYTE*)p, size); // и свмих данных
OnSend(0);
}
// получение данных
void CProtocol::OnReceive(int ErrCode)
{
CAsyncSocket::OnReceive(ErrCode);
if (m_IsReceiveSize) // Прием размера данных
{
int n = Receive((BYTE*)&m_ReceiveSize+m_ReceiveDataSize, sizeof(DWORD)-m_ReceiveDataSize);
// Анализ ошибок
if (n == SOCKET_ERROR)
{
ErrCode = GetLastError();
if (ErrCode != WSAEWOULDBLOCK)
{
CString s;
s.Format("Ошибка при приеме длины! Код ошибки %u", ErrCode);
MessageBox(0,s,"Сообщение",MB_OK);
Close();
}
}
else
// Анализ принятых данных
{
m_ReceiveDataSize+= n;
if (m_ReceiveDataSize == sizeof(DWORD)) // при приеме длины полностью
{
m_IsReceiveSize = false;
m_ReceiveData.Alloc(m_ReceiveSize);
m_ReceiveDataSize = 0;
}
}
}
else
// Прием самих данных
{
int n = Receive((BYTE*)m_ReceiveData.GetAddr()+m_ReceiveDataSize, m_ReceiveSize-m_ReceiveDataSize);
// Анализ ошибок
if (n == SOCKET_ERROR)
{
ErrCode = GetLastError();
if (ErrCode != WSAEWOULDBLOCK)
{
CString s;
s.Format("Ошибка при приеме собщения! Код ошибки %u", ErrCode);
MessageBox(0,s,"Сообщение",MB_OK);
Close();
}
}
else
// Анализ принятых данных
{
m_ReceiveDataSize+= n;
if (m_ReceiveDataSize == m_ReceiveSize) // при завершении приема пакета
{
m_ReceiveDataSize = 0;
m_IsReceiveSize = true;
//AfxMessageBox("Принят пакет!");
OnReceivePacket();
}
}
}
}
Как оказалось, их 3:
Сокетом (от англ. socket - гнездо, розетка) называется специальный объект, создаваемый для отправки и получения данных через сеть. Этот объект создаётся внутри библиотеки сокетов, а программист, использующий эту библиотеку, получает уникальный номер (дескриптор) этого сокета. Конкретное значение этого дескриптора не несёт для программиста никакой полезной информации и может быть использовано только для того, чтобы при вызове функции из библиотеки сокетов указать, с каким сокетом требуется выполнить операцию.
Чтобы две программы могли общаться друг с другом через сеть, каждая из них должна создать сокет. Каждый сокет обладает двумя основными характеристиками: протоколом и адресом, к которым он привязан. Протокол задаётся при создании сокета и не может быть изменён впоследствии. Адрес сокета задаётся позже, но обязательно до того, как через сокет пойдут данные. В некоторых случаях привязка сокета к адресу может быть неявной.
После организации соединения сокетов любое чтение или запись через файловый дескриптор одного из них будут на самом деле передавать данные между ним и парным ему сокетом другого приложения.
Сокеты, независимо от вида, деляться на три типа: потоковые, сырые(windows их не "держит") и дейтаграммные. Потоковые сокеты работают с установкой соединения, обеспечивая надежную идентификацию обеих сторон и гарантируют целостность и успешность доставки данных, опираются на протокол TCP. Дейтаграммные сокеты работают без установки соединения и не обеспечивают ни идентификации отправителя, ни контроля успешности доставки данных, зато они быстрее потоковых, опираються на протокол UDP. Сырые сокеты, они предоставляют возможность ручного формирования TCP\IP пакетов.
Источник:
http://tehnofil.ru/?id=91
После того, как пакет средствами протокола IP доставлен в компьютер-получатель, данные необходимо направить конкретному процессу-получателю. Каждый компьютер может выполнять несколько процессов, более того, прикладной процесс тоже может иметь несколько точек входа, выступающих в качестве адреса назначения для пакетов данных.
Пакеты, поступающие на транспортный уровень, организуются операционной системой в виде множества очередей к точкам входа различных прикладных процессов. В терминологии TCP/IP такие системные очереди называются портами. Таким образом, адресом назначения, который используется на транспортном уровне, является идентификатор (номер) порта прикладного сервиса. Номер порта, задаваемый транспортным уровнем, в совокупности с номером сети и номером компьютера, задаваемыми сетевым уровнем, однозначно определяют прикладной процесс в сети.
Назначение номеров портов прикладным процессам осуществляется либо централизовано, если эти процессы представляют собой популярные общедоступные сервисы, типа сервиса удаленного доступа к файлам TFTP (Trivial FTP) или сервиса удаленного управления telnet, либо локально для тех сервисов, которые еще не стали столь распространенными, чтобы за ними закреплять стандартные (зарезервированные) номера.
Локальное присвоение номера порта заключается в том, что разработчик некоторого приложения просто связывает с ним любой доступный, произвольно выбранный числовой идентификатор, обращая внимание на то, чтобы он не входил в число зарезервированных номеров портов. В дальнейшем все удаленные запросы к данному приложению от других приложений должны адресоваться с указанием назначенного ему номера порта.