Каждый раз, когда вы передаете данные по сети, они как-то перетекают от вашего компьютера к серверу или другому компьютеру. Как это происходит? Вы, наверно, скажете, что с помощью специального сетевого протокола, и будете правы. Но существует множество разновидностей протоколов. Какой и когда используется? Зачем они нужны? Как они работают? Вот на эти вопросы я сейчас постараюсь дать ответ. Прежде чем разбираться с протоколами, нам необходимо узнать, что такое модель взаимодействия открытых систем (OSI — Open Systems Interconnection), которая была разработана Международной организацией по стандартам (ISO — International Organization for Standardization). В соответствии с этой моделью, сетевое взаимодействие делится на семь уровней. Физический уровень— передача битов по физическим каналам (коаксиальный кабель, витая пара, оптоволоконный кабель). Здесь определяются характеристики физических сред и параметры электрических сигналов. Канальный уровень — передача кадра данных между любыми узлами в сетях типовой топологии или соседними узлами в сетях произвольной топологии. В качестве адресов на канальном уровне используются МАС-адреса. Сетевой уровень — доставка пакета любому узлу в сетях произвольной топологии. На этом уровне нет никаких гарантий доставки пакета. Транспортный уровень — доставка пакета любому узлу с любой топологией сети и заданным уровнем надежности доставки. На этом уровне имеются средства для установления соединения, буферизации, нумерации и упорядочивания пакетов. Уровень сеанса — управление диалогом между узлами. Обеспечена возможность фиксации активной на данный момент стороны. Уровень представления — предоставляется возможность преобразования данных (шифрование, сжатие). Прикладной уровень — набор сетевых сервисов (FTP, E-mail и др.) для пользователя и приложения. Если вы внимательно прочитали обо всех уровнях, то, наверно, заметили, что первые три уровня обеспечиваются оборудованием, таким как сетевые карты, маршрутизаторы, концентраторы, мосты и др. Последние три — операционной системой или приложением. Четвертый уровень является промежуточным. Как работает протокол по этой модели? Все начинается с прикладного уровня. Пакет попадает на этот уровень, и к нему добавляется заголовок. После этого прикладной уровень отправляет этот пакет на следующий уровень (уровень представления). Здесь ему также добавляется свой собственный заголовок, и пакет отправляется дальше. И так до физического уровня, который занимается непосредственно передачей данных и отправляет пакет в сеть. Другая машина, получив пакет, начинает обратный отсчет. Пакет с физического уровня попадает на канальный. Канальный уровень убирает свой заголовок и поднимает пакет выше (на уровень сети). Уровень сети убирает свой заголовок и поднимает пакет выше. Так пакет поднимается до уровня приложения, где остается чистый пакет без служебной информации, которая была прикреплена на исходном компьютере перед отправкой пакета. Передача данных не обязательно должна начинаться с седьмого уровня. Если используемый протокол работает на четвертом уровне, то процесс передачи начнется с него, и пакет будет подниматься вверх до физического уровня для отправки. Количество уровней в протоколе определяет его потребности и возможности при передаче данных. Чем ниже находится протокол (ближе к прикладному уровню), тем больше у него возможностей и больше накладных расходов при передаче данных (длиннее и сложнее заголовок). Рассматриваемые в данной книге протоколы будут находиться на разных уровнях, поэтому будут иметь разные возможности. Корпорация Microsoft реализовала протокол TCP/IP в модели OSI по-своему (с небольшими отклонениями от стандарта). Я понимаю, что модель OSI справочная, и предназначена только в качестве рекомендации, но нельзя же было так ее изменять, ведь принцип оставлен тот же, хотя изменились названия и количество уровней. Рис. 4.1. Модель OSI и вариант от MS Сетевые протоколы Прежде чем начинать писать сетевые программы, необходимо разобраться с сетевыми протоколами, понять основу и принципы их работы. В этом разделе я остановлюсь на самых важных моментах, которые необходимо знать программисту для правильного принятия решения. Вы увидите основные различия и сможете понять, что нельзя просто взять первый попавшийся протокол и написать с его помощью любую программу. Иногда выбор бывает очень сложным, но от него зависит будущее программы. Протокол IP Если посмотреть на схему сетевой модели (см. рис. 4.1), то можно увидеть, что протокол IP находится на сетевом уровне. Из этого можно сделать вывод, что IP выполняет сетевые функции — доставка пакета любому узлу в сетях произвольной топологии. Протокол IP при передаче данных не устанавливает виртуального соединения и использует датаграммы (пакеты данных) для отправки информации от одного компьютера к другому. Это значит, что по протоколу IP пакеты просто отправляются в сеть без ожидания подтверждения о получении данных (АСК Acknowledgment), а значит, без гарантии доставки пакетов и, соответственно, без гарантии целостности данных. Если хотя бы один пакет из 100 необходимых не дойдет до адресата, то данные нарушатся, и собрать их в единое целое будет невозможно. Все необходимые действия по подтверждению и обеспечению целостности данных должны обеспечивать протоколы, работающие на более высоком уровне. Каждый IP-пакет содержит адреса отправителя и получателя, идентификатор протокола, TTL (время жизни пакета) и контрольную сумму для проверки целостности пакета. Как видите, здесь есть контрольная сумма, которая все же позволяет узнать целостность пакета. Но об этом узнает только получатель. Когда компьютер-получатель принял пакет, то он проверяет контрольную сумму только для себя. Если сумма сходится, то пакет обрабатывается, иначе просто игнорируется. А компьютер-отправитель не сможет узнать об ошибке, возникшей в пакете, и повторить посылку. Именно поэтому соединение по протоколу IP нельзя считать надежным. Сопоставление адреса ARP и RARP Протокол ARP (Address Resolution Protocol, протокол определения адреса) предназначен для определения аппаратного (MAC) адреса компьютера в сети по его IP-адресу. Прежде чем данные смогут быть посланы на какой-нибудь компьютер, отправитель должен знать аппаратный адрес получателя. Именно для этого и предназначен ARP. Когда компьютер посылает ARP-запрос на поиск аппаратного адреса, то протокол сначала ищет этот адрес в локальном кэше. Если уже были обращения по данному IP-адресу, то информация о МАС-адресе должна сохраниться в кэше. Если ничего не найдено, то в сеть посылается широковещательный запрос, который получат все компьютеры сети. Они получат этот пакет и проверят адрес. Тот, кому принадлежит искомый IP, ответит на запрос, указав свой МАС-адрес. Так как этот адрес должен быть уникальным (прошивается в сетевом устройстве на заводе-изготовителе), то и ответ должен быть один. Но вы должны учитывать, что есть средства подделки МАС-адресов (хакеры иногда используют этот прием в своих целях), и может возникнуть ситуация, когда ответ придет от двух машин. Протокол RARP (Revers Address Resolution Protocol, обратный протокол определения адреса) определяет IP-адрес по известному МАС-адресу. Процесс поиска адресов абсолютно такой же. Транспортные протоколы На транспортном уровне мы имеем два протокола: UDP и TCP. Оба они работают поверх IP. Это значит, что, когда пакет TCP или UDP опускается на уровень ниже для отправки в сеть, он попадает на уровень сети прямо в лапы протокола IP. Здесь пакету добавляется сетевой адрес, TTL и другие атрибуты протокола IP. После этого пакет идет дальше вниз для физической отправки в сеть. Голый пакет TCP не может быть отправлен в сеть, потому что он не имеет информации о получателе, эта информация добавляется к пакету с IP-заголовком на уровне сети. Давайте теперь рассмотрим каждый протокол в отдельности. Быстрый UDP Как и IP, протокол UDP для передачи данных не устанавливает соединения с сервером. Данные просто выбрасываются в сеть, и протокол даже не заботится о доставке пакета. Если данные на пути к серверу испортятся или вообще не дойдут, то отправляющая сторона об этом не узнает. Так что, по этому протоколу, как и по голому IP, не желательно передавать очень важные данные. Благодаря тому, что протокол UDP не устанавливает соединения, он работает очень быстро (в несколько раз быстрее TCP, о котором чуть ниже). Из-за высокой скорости его очень удобно использовать там, где не нужно заботиться о целостности данных. Таким примером могут служить радиостанции в Интернете. Звуковые данные просто выплескиваются в глобальную сеть, и если слушатель не получит одного пакета, то максимум, что он заметит — небольшое заикание в месте потери. Но если учесть, что сетевые пакеты имеют небольшой размер, то эта задержка будет практически незаметна. Большая скорость — большие проблемы с безопасностью. Так как нет соединения между сервером и клиентом, то нет никакой гарантии в достоверности данных. Протокол UDP больше подвержен спуфингу (spoofing , подмена адреса отправителя), поэтому построение на нем защищенных сетей затруднено. Итак, UDP очень быстр, но его можно использовать только там, где данные не имеют высокой ценности (возможна потеря отдельных пакетов) и не секретны (UDP больше подвержен взлому). Медленный , но надежный TCP Как я уже сказал, протокол TCP лежит на одном уровне с UDP и работает поверх IP, который используется для отправки данных. Именно поэтому протоколы TCP и IP неразрывно связаны и их часто объединяют одним названием TCP/IP. В отличие от UDP-протокол TCP устраняет недостатки своего транспорта (IP). В этом протоколе заложены средства установления связи между приемником и передатчиком, обеспечение целостности данных и гарантии их доставки. Когда данные отправляются в сеть по TCP, то на отправляющей стороне включается таймер. Если в течение определенного времени приемник не подтвердит получение данных, то будет предпринята еще одна попытки отправки данных. Если приемник получит испорченные данные, то он сообщит об этом источнику и попросит снова отправить испорченные пакеты. Благодаря этому обеспечивается гарантированная доставка данных. Когда нужно отправить сразу большую порцию данных, не вмещающихся в один пакет, то они разбиваются на несколько TCP-пакетов. Пакеты отправляются порциями по несколько штук (зависит от настроек стека). Когда сервер получает порцию пакетов, то он восстанавливает их очередность и собирает данные вместе (даже если пакеты прибыли не в том порядке, в котором они отправлялись). Из-за лишних накладных расходов на установку соединения подтверждение доставки и повторную пересылку испорченных данных протокол TCP намного медленней UDP. Зато TCP можно использовать там, где нужна гарантия доставки и большая надежность. Хотя надежность нельзя назвать сильной (нет шифрования, сохраняется возможность взлома), но она приемлемая и намного больше, чем у UDP. По крайней мере, тут спуфинг не может быть реализован так просто, как у UDP, и в этом вы убедитесь, когда прочтете про процесс установки соединения. Хотя возможно все, и хакеры умеют взламывать и ТСР-протокол. Опасные связи TCP Давайте посмотрим, как протокол TCP обеспечивает надежность соединения. Все начинается еще на этапе попытки соединения двух компьютеров в следующей последовательности: Клиент, который хочет соединиться с сервером, отправляет SYN-запрос на сервер, указывая номер порта, к которому он хочет подсоединиться, и специальное число (чаще всего случайное). Сервер отвечает своим сегментом SYN , содержащим специальное число сервера. Он также подтверждает приход SYN-пакета со стороны клиента с использованием АСК-ответа, где специальное число, отправленное клиентом, увеличено на 1. Клиент должен подтвердить приход SYN от сервера с использованием АСК — специальное число сервера плюс 1. Получается, что при соединении клиента с сервером они обмениваются специальными числами. Эти числа и используются в дальнейшем для обеспечения целостности и защищенности связи. Если кто-то другой захочет вклиниться в установленную связь (с помощью спуфинга), то ему надо будет подделать эти числа. Но так как они большие и выбираются случайным образом, то такая задача достаточно сложная, хотя Кевин Митник в свое время смог решить ее. Но это уже другая история, и не будем уходить далеко в сторону. Стоит еще отметить, что приход любого пакета подтверждается АСК-ответом, что гарантирует доставку данных. Прикладные протоколы — загадочный NetBIOS NetBIOS (Network Basic Input Output System, базовая система сетевого ввода/вывода) — это стандартный интерфейс прикладного программирования. А проще говоря, это всего лишь набор API-функций для работы с сетью (хотя весь NetBIOS состоит только из одной функции, но зато какой...). NetBIOS был разработан в 1983 году компанией Sytek Corporation специально для IBM. Система NetBIOS определяет только программную часть передачи данных, т.е. как должна работать программа для передачи данных по сети. А вот как будут физически передаваться данные, в этом документе не говорится ни слова, да и в реализации отсутствует что-нибудь подобное. Если посмотреть на рис. 4.1, то можно увидеть, что NetBIOS находится в самом верху схемы. Он расположен на уровнях сеанса, представления и приложения. Такое его расположение — лишнее подтверждение моих слов. NetBIOS только формирует данные для передачи, а физически передаваться они могут только с помощью других протоколов, например, TCP/IP, IPX/SPX и т.д. Это значит, что NetBIOS является независимым от транспорта. Если другие варианты протоколов верхнего уровня (только формирующие пакеты, но не передающие) привязаны к определенному транспортному протоколу, который должен передавать сформированные данные, то пакеты NetBIOS может передавать любой другой протокол. Прочувствовал силу? Представьте, что вы написали сетевую программу, работающую через NetBIOS. А если вы еще не знаете, то она будет прекрасно работать как в UNIX/Windows-сетях через TCP, так и в Novell-сетях через IPX. С другой стороны, для того, чтобы два компьютера смогли соединиться друг с другом по NetBIOS, необходимо, чтобы на обоих стоял хотя бы один общий транспортный протокол. Если один компьютер будет посылать NetBIOS -пакеты через TCP, а другой — с помощью IPX, то эти компьютеры друг друга не поймут. Транспорт должен быть одинаковый. Стоит сразу же отметить, что не все варианты транспортных протоколов по умолчанию могут передавать по сети NetBIOS-пакеты. Например, IPX/SPX сам по себе этого не умеет. Чтобы его обучить, нужно иметь "NWLink IPX/SPX/NetBIOS Compatible Transport Protocol". Так как NetBIOS чаще всего использует в качестве транспорта протокол TCP, который работает с установкой виртуального соединения между клиентом и сервером, то по этому протоколу можно передавать достаточно важные данные. Целостность и надежность передачи будет осуществлять TCP/IP, a NetBIOS дает только удобную среду для работы с пакетами и программирования сетевых приложений. Так что если вам нужно отправить в сеть какие-либо файлы, то можно смело положиться на NetBIOS. NetBEUI В 1985 году уже сама IBM сделала попытку превратить NetBIOS в полноценный протокол, который умеет не только формировать данные для передачи, но и физически передавать их по сети. Для этого был разработан NetBEUI (NetBIOS Extended User Interface, расширенный пользовательский интерфейс NetBIOS). Он предназначен именно для описания физической части передачи данных протокола NetBIOS. Сразу хочу отметить, что NetBEUI является немаршрутизируемым протоколом, и первый же маршрутизатор будет отбиваться от таких пакетов как теннисистка от мячиков . Это значит, что если между двумя компьютерами стоит маршрутизатор и нет другого пути для связи, то им не удастся установить соединение через NetBEUI. Сокеты Windows Сокеты (Sockets) — это всего лишь программный интерфейс, который облегчает взаимодействие между различными приложениями. Современные сокеты родились из программного сетевого интерфейса, реализованного в ОС BSD UNIX. Тогда этот интерфейс создавался для облегчения работы с TCP/IP на верхнем уровне. С помощью сокетов легко реализовать большинство известных протоколов, которые используются каждый день при выходе в Интернет. Достаточно только назвать HTTP, FTP, POP3, SMTP и далее в том же духе. Все они используют для отправки своих данных или TCP, или UDP и легко программируются с помощью библиотеки sockets/winsock. Протоколы IPX/SPX Осталось только рассказать еще о нескольких протоколах, которые встречаются в повседневной жизни чуть реже, но зато они не менее полезны. Первые на очереди — это IPX/SPX. Протокол IPX (Internetwork Packet Exchange, межсетевой обмен пакетами) сейчас используется, наверно, только в сетях фирмы Novell. В наших любимых окошках есть специальная служба Клиент для сетей Novell, с помощью которой вы сможете работать в таких сетях. IPX работает подобно IP и UDP — без установления связи, а значит, без гарантии доставки и всех последующих достоинств и недостатков. SPX (Sequence Packet Exchange, последовательный обмен пакетами) — это транспорт для IPX, который работает с установлением связи и обеспечивает целостность данных. Так что если вам понадобится надежность при использовании IPX, то используй связку IPX/SPX или IPX/SPX11. Сейчас IPX уже теряет свою популярность, но еще помнятся времена DOS, когда все сетевые игры работали через этот протокол. Как видите, в Интернете протоколов целое море, но большинство из них взаимосвязано, как, например, HTTP—TCP—IP. Протокол, предназначенный для одной цели, может оказаться абсолютно непригодным для другой, потому что создать что-то идеальное невозможно. У каждого будут свои достоинства и недостатки. И все же модель OSI , принятая еще на заре Интернета, не утратила своей актуальности до сих пор. По ней работает все и вся. Главное ее достоинство — скрывать сложность сетевого общения между компьютерами, с чем старушка OSI справляется без особых проблем. Сетевые порты Прежде чем вы начнете писать собственные программы, надо разобраться с еще одним понятием — сетевой порт. Допустим, что вашему компьютеру на сетевую карту пришел пакет данных. Как операционная система должна определить, для какой программы пришли данные: для Internet Explorer, для почтового клиента или для вашей программы? Чтобы определить это, используются порты. Когда программа соединяется с сервером, то она открывает на вашем компьютере какой-нибудь сетевой порт и сообщает серверу, что именно с этим портом она работает. После этого сервер будет посылать на ваш компьютер пакеты данных, в которых будет указан сетевой адрес компьютера и номер порта. По IP-адресу пакет будет доставлен до вашего компьютера, а по номеру порта операционная система определит, что именно для вашей программы предназначается пришедший пакет. Для соединения с сервером вам надо знать не только IP-адрес сервера, но и порт, на котором работает программа, потому что на сервере может работать множество сетевых программ, и все они используют свои порты. Из всего вышесказанного следует, что только одна программа может открыть определенный порт. Если бы две программы могли открывать, например, 21-й порт, то Windows (или любая другая операционная система) уже не смогла бы определить, какой из двух программ пришли данные. Номер порта — это число от 1 до 65 535. Для передачи такого числа по сети достаточно всего лишь двух байт, поэтому это не будет накладно для сети. Я рекомендую использовать для своих целей порты с номерами более 1024, потому что среди меньших значений очень много зарегистрированных номеров, и у вашей программы увеличивается вероятность конфликта с другими сетевыми программами. (c) Фленов М.Е. - Программирование на С++ глазами хакера Глава 4 Работа с сетью
Сразу видно что Фленов писал... Выдернул из общеизвественой инфы в сети куски, собрал и "написал" книжку. Не читайте это г@вно. Почитайте любую книжку, по FreeBSD например. Там очень хорошо и подробно расписано как например разрешаются ARP запросы, если оба компа находятся в разных локалках? Как пакеты гуляют в p2p сетях? В части о не безопасности TCP, ничего о VPN не написано... Фленов по моему занимается, компиляцией разных источников, и написание книг для школьников 9-11 классов которые изучают информатику. ЗЫ: Сам когда то читал вот таких вот... авторов, мля... И не понимал них в сетях)
