Лекция
Сразу хочу сказать, что здесь никакой воды про ip, и только нужная информация. Для того чтобы лучше понимать что такое ip, порт соединения, polling, web socket, comet , настоятельно рекомендую прочитать все из категории Основы интернет и веб технологий. Кликните на вариант (или варианты ответов), если он правильный - то будет подсвечен зеленым цветом и вам будет зачислено пару монеток, а если неверный - то красным и будет снята монетка. Удачи в прохождении онлайн теста!
Основу транспортных средств стека протоколов TCP/IP составляет протокол межсетевого взаимодействия - Internet Protocol (IP). К основным функциям протокола IP относятся:
Пакет IP состоит из заголовка и поля данных. Заголовок пакета имеет следующие поля:
Максимальная длина поля данных пакета ограничена разрядностью поля, определяющего эту величину, и составляет 65535 байтов, однако при передаче по сетям различного типа длина пакета выбирается с учетом максимальной длины пакета протокола нижнего уровня, несущего IP-пакеты. Если это кадры Ethernet, то выбираются пакеты с максимальной длиной в 1500 байтов, умещающиеся в поле данных кадра Ethernet.
Протоколы транспортного уровня (протоколы TCP или UDP), пользующиеся сетевым уровнем для отправки пакетов, считают, что максимальный размер поля данных IP-пакета равен 65535, и поэтому могут передать ему сообщение такой длины для транспортировки через интерсеть. В функции уровня IP входит разбиение слишком длинного для конкретного типа составляющей сети сообщения на более короткие пакеты с созданием соответствующих служебных полей, нужных для последующей сборки фрагментов в исходное сообщение.
В большинстве типов локальных и глобальных сетей определяется такое понятие как максимальный размер поля данных кадра или пакета, в которые должен инкапсулировать свой пакет протокол IP. Эту величину обычно называют максимальной единицей транспортировки - Maximum Transfer Unit, MTU. Сети Ethernet имеют значение MTU, равное 1500 байт, сети FDDI - 4096 байт, а сети Х.25 чаще всего работают с MTU в 128 байт.
Работа протокола IP по фрагментации пакетов в хостах и маршрутизаторах иллюстрируется рисунком 4.1.
Пусть компьютер 1 связан с сетью, имеющей значение MTU в 4096 байтов, например, с сетью FDDI. При поступлении на IP-уровень компьютера 1 сообщения от транспортного уровня размером в 5600 байтов, протокол IP делит его на два IP-пакета, устанавливая в первом пакете признак фрагментации и присваивая пакету уникальный идентификатор, например, 486. В первом пакете величина поля смещения равна 0, а во втором - 2800. Признак фрагментации во втором пакете равен нулю, что показывает, что это последний фрагмент пакета. Общая величина IP-пакета составляет 2800+20 (размер заголовка IP), то есть 2820 байтов, что умещается в поле данных кадра FDDI.
Рис. 4.1. Фрагментация IP-пакетов при передаче между сетями с разными
максимальными размерами пакетов. К1 и Ф1 канальный и физический уровень сети 1,
К2 и Ф2 канальный и физический уровень сети 2
Далее компьютер 1 передает эти пакеты на канальный уровень К1, а затем и на физический уровень Ф1, который отправляет их маршрутизатору, связанному с данной сетью.
Маршрутизатор видит по сетевому адресу, что прибывшие два пакета нужно передать в сеть 2, которая имеет меньшее значение MTU, равное 1500. Вероятно, это сеть Ethernet. Маршрутизатор извлекает фрагмент транспортного сообщения из каждого пакета FDDI и делит его еще пополам, чтобы каждая часть уместилась в поле данных кадра Ethernet. Затем он формирует новые пакеты IP, каждый из которых имеет длину 1400 + 20 = 1420 байтов, что меньше 1500 байтов, поэтому они нормально помещаются в поле данных кадров Ethernet.
В результате в компьютер 2 по сети Ethernet приходит четыре IP-пакета с общим идентификатором 486, что позволяет протоколу IP, работающему в компьютере 2, правильно собрать исходное сообщение. Если пакеты пришли не в том порядке, в котором были посланы, то смещение укажет правильный порядок их объединения.
Отметим, что IP-маршрутизаторы не собирают фрагменты пакетов в более крупные пакеты, даже если на пути встречается сеть, допускающая такое укрупнение. Это связано с тем, что отдельные фрагменты сообщения могут перемещаться по интерсети по различным маршрутам, поэтому нет гарантии, что все фрагменты проходят через какой-либо промежуточный маршрутизатор на их пути.
При приходе первого фрагмента пакета узел назначения запускает таймер, который определяет максимально допустимое время ожидания прихода остальных фрагментов этого пакета. Если таймер истекает раньше прибытия последнего фрагмента, то все полученные к этому моменту фрагменты пакета отбрасываются, а в узел, пославший исходный пакет, направляется сообщение об ошибке с помощью протокола ICMP.
Рассмотрим теперь принципы, на основании которых в сетях IP происходит выбор маршрута передачи пакета между сетями.
Сначала необходимо обратить внимание на тот факт, что не только маршрутизаторы, но и конечные узлы - компьютеры - должны принимать участие в выборе маршрута. Пример, приведенный на рисунке 4.2, демонстрирует эту необходимость. Здесь в локальной сети имеется несколько маршрутизаторов, и компьютер должен выбирать, какому из них следует отправить пакет.
Рис. 4.2. Выбор маршрутизатора конечным узлом
Длина маршрута может существенно измениться в зависимости от того, какой маршрутизатор выберет компьютер для передачи своего пакета на сервер, расположенный, например, в Германии, если маршрутизатор 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-адрес - адрес следующего маршрутизатора, которому нужно передать пакет. Вместе с пакетом следующему маршрутизатору передается ответственность за выбор следующего шага маршрутизации. Одношаговый подход к маршрутизации означает распределенное решение задачи выбора маршрута. Это снимает ограничение на максимальное количество транзитных маршрутизаторов на пути пакета.
(Альтернативой одношаговому подходу является указание в пакете всей последовательности маршрутизаторов, которые пакет должен пройти на своем пути. Такой подход называется маршрутизацией от источника - Source Routing. В этом случае выбор маршрута производится конечным узлом или первым маршрутизатором на пути пакета, а все остальные маршрутизаторы только отрабатывают выбранный маршрут, осуществляя коммутацию пакетов, то есть передачу их с одного порта на другой. Алгоритм Source Routing применяется в сетях IP только для отладки, когда маршрут задается в поле Резерв (IP OPTIONS) пакета.)
В случае, если в таблице маршрутов имеется более одной строки, соответствующей одному и тому же адресу сети назначения, то при принятии решения о передаче пакета используется та строка, в которой указано наименьшее значение в поле "Расстояние до сети назначения".
При этом под расстоянием понимается любая метрика, используемая в соответствии с заданным в сетевом пакете классом сервиса. Это может быть количество транзитных маршрутизаторов в данном маршруте (количество хопов от hop - прыжок), время прохождения пакета по линиям связи, надежность линий связи, или другая величина, отражающая качество данного маршрута по отношению к конкретному классу сервиса. Если маршрутизатор поддерживает несколько классов сервиса пакетов, то таблица маршрутов составляется и применяется отдельно для каждого вида сервиса (критерия выбора маршрута).
Для отправки пакета следующему маршрутизатору требуется знание его локального адреса, но в стеке TCP/IP в таблицах маршрутизации принято использование только IP-адресов для сохранения их универсального формата, не зависящего от типа сетей, входящих в интерсеть. Для нахождения локального адреса по известному IP-адресу необходимо воспользоваться протоколом ARP.
Конечный узел, как и маршрутизатор, имеет в своем распоряжении таблицу маршрутов унифицированного формата и на основании ее данных принимает решение, какому маршрутизатору нужно передавать пакет для сети N. Решение о том, что этот пакет нужно вообще маршрутизировать, компьютер принимает в том случае, когда он видит, что адрес сети назначения пакета отличается от адреса его собственной сети (каждому компьютеру при конфигурировании администратор присваивает его IP-адрес или несколько IP-адресов, если компьютер одновременно подключен к нескольким сетям). Когда компьютер выбрал следующий маршрутизатор, то он просматривают кэш-таблицу адресов своего протокола ARP и, может быть, находит там соответствие IP-адреса следующего маршрутизатора его MAC-адресу. Если же нет, то по локальной сети передается широковещательный ARP-запрос и локальный адрес извлекается из ARP-ответа.
После этого компьютер формирует кадр протокола, используемого на выбранном порту, например, кадр Ethernet, в который помещает МАС-адрес маршрутизатора. Маршрутизатор принимает кадр Ethernet, извлекает из него пакет IP и просматривает свою таблицу маршрутизации для нахождения следующего маршрутизатора. При этом он выполняет те же действия, что и конечный узел.
Одношаговая маршрутизация обладает еще одним преимуществом - она позволяет сократить объем таблиц маршрутизации в конечных узлах и маршрутизаторах за счет использования в качестве номера сети назначения так называемого маршрута по умолчанию - default, который обычно занимает в таблице маршрутизации последнюю строку. Если в таблице маршрутизации есть такая запись, то все пакеты с номерами сетей, которые отсутствуют в таблице маршрутизации, передаются маршрутизатору, указанному в строке default. Поэтому маршрутизаторы часто хранят в своих таблицах ограниченную информацию о сетях интерсети, пересылая пакеты для остальных сетей в порт и маршрутизатор, используемые по умолчанию. Подразумевается, что маршрутизатор, используемый по умолчанию, передаст пакет на магистральную сеть, а маршрутизаторы, подключенные к магистрали, имеют полную информацию о составе интерсети.
Особенно часто приемом маршрутизации по умолчанию пользуются конечные узлы. Об этом говорит сайт https://intellect.icu . Хотя они также в общем случае имеют в своем распоряжении таблицу маршрутизации, ее объем обычно незначителен, так как маршрутизация для компьютера - не основное занятие. Главная роль в маршрутизации пакетов в концепции протокола IP отводится, естественно, маршрутизаторам, которые должны обладать гораздо более полными таблицами маршрутизации, чем конечные узлы. Конечный узел часто вообще работает без таблицы маршрутизации, имея только сведения об IP-адресе маршрутизатора по умолчанию. При наличии одного маршрутизатора в локальной сети этот вариант - единственно возможный для всех конечных узлов. Но даже при наличии нескольких маршрутизаторов в локальной сети, когда проблема их выбора стоит перед конечным узлом, задание маршрута по умолчанию часто используется в компьютерах для сокращения объема их маршрутной таблицы.
Другим способом разгрузки компьютера от необходимости ведения больших таблиц маршрутизации является получение от маршрутизатора сведений о рациональном маршруте для какой-нибудь конкретной сети с помощью протокола ICMP.
Кроме маршрута default, в таблице маршрутизации могут встретиться два типа специальных записей - запись о специфичном для узла маршруте и запись об адресах сетей, непосредственно подключенных к портам маршрутизатора.
Специфичный для узла маршрут содержит вместо номера сети полный IP-адрес, то есть адрес, имеющий ненулевую информацию не только в поле номера сети, но и в поле номера узла. Предполагается, что для такого конечного узла маршрут должен выбираться не так, как для всех остальных узлов сети, к которой он относится. В случае, когда в таблице есть разные записи о продвижении пакетов для всей сети N и ее отдельного узла, имеющего адрес N,D, при поступлении пакета, адресованного узлу N,D, маршрутизатор отдаст предпочтение записи для N,D.
Записи в таблице маршрутизации, относящиеся к сетям, непосредственно подключенным к маршрутизатору, в поле "Расстояние до сети назначения" содержат нули.
Еще одним отличием работы маршрутизатора и конечного узла при выборе маршрута является способ построения таблицы маршрутизации. Если маршрутизаторы обычно автоматически создают таблицы маршрутизации, обмениваясь служебной информацией, то для конечных узлов таблицы маршрутизации создаются, как правило, вручную администраторами, и хранятся в виде постоянных файлов на дисках.
Существуют различные алгоритмы построения таблиц для одношаговой маршрутизации. Их можно разделить на три класса:
Независимо от алгоритма, используемого для построения таблицы маршрутизации, результат их работы имеет единый формат. За счет этого в одной и той же сети различные узлы могут строить таблицы маршрутизации по своим алгоритмам, а затем обмениваться между собой недостающими данными, так как форматы этих таблиц фиксированы. Поэтому маршрутизатор, работающий по алгоритму адаптивной маршрутизации, может снабдить конечный узел, применяющий алгоритм фиксированной маршрутизации, сведениями о пути к сети, о которой конечный узел ничего не знает.
Фиксированная маршрутизация
Этот алгоритм применяется в сетях с простой топологией связей и основан на ручном составлении таблицы маршрутизации администратором сети. Алгоритм часто эффективно работает также для магистралей крупных сетей, так как сама магистраль может иметь простую структуру с очевидными наилучшими путями следования пакетов в подсети, присоединенные к магистрали.
Различают одномаршрутные таблицы, в которых для каждого адресата задан один путь, и многомаршрутные таблицы, определяющие несколько альтернативных путей для каждого адресата. При использовании многомаршрутных таблиц должно быть задано правило выбора одного из них. Чаще всего один путь является основным, а остальные - резервными.
Простая маршрутизация
Алгоритмы простой маршрутизации подразделяются на три подкласса:
Адаптивная маршрутизация
Это основной вид алгоритмов маршрутизации, применяющихся маршрутизаторами в современных сетях со сложной топологией. Адаптивная маршрутизация основана на том, что маршрутизаторы периодически обмениваются специальной топологической информацией об имеющихся в интерсети сетях, а также о связях между маршрутизаторами. Обычно учитывается не только топология связей, но и их пропускная способность и состояние.
Адаптивные протоколы позволяют всем маршрутизаторам собирать информацию о топологии связей в сети, оперативно отрабатывая все изменения конфигурации связей. Эти протоколы имеют распределенный характер, который выражается в том, что в сети отсутствуют какие-либо выделенные маршрутизаторы, которые бы собирали и обобщали топологическую информацию: эта работа распределена между всеми маршрутизаторами.
Рассмотрим на примере интерсети, приведенной на рисунке 4.3, каким образом происходит взаимодействие компьютеров через маршрутизаторы и доставка пакетов компьютеру назначения.
Рис. 4.3. Пример взаимодействия компьютеров через интерсеть
Пусть в приведенном примере пользователь компьютера cit.dol.ru, находящийся в сети Ethernet с IP-адресом 194.87.23.0 (адрес класса С), хочет взаимодействовать по протоколу FTP с компьютером s1.msk.su, принадлежащем сети Ethernet с IP-адресом 142.06.0.0 (адрес класса В). Компьютер cit.dol.ru имеет IP-адрес 194.87.23.1.17, а компьютер s1.msk.su - IP-адрес 142.06.13.14.
1. Пользователь компьютера cit.dol.ru знает символьное имя компьютера s1.msk.su, но не знает его IP-адреса, поэтому он набирает команду
> ftp s1.msk.su
для организации ftp-сеанса.
В компьютере cit.dol.ru должны быть заданы некоторые параметры для стека TCP/IP, чтобы он мог выполнить поставленную перед ним задачу.
В число этих параметров должны входить собственный IP-адрес, IP-адрес DNS-сервера и IP-адрес маршрутизатора по умолчанию. Так как к сети Ethernet, к которой относится компьютер cit.dol.ru, подключен только один маршрутизатор, то таблица маршрутизации конечным узлам этой сети не нужна, достаточно знать IP-адрес маршрутизатора по умолчанию. В данном примере он равен 194.87.23.1.
Так как пользователь в команде ftp не задал IP-адрес узла, с которым он хочет взаимодействовать, то стек TCP/IP должен определить его самостоятельно. Он может сделать запрос к серверу DNS по имеющемуся у него IP-адресу, но обычно каждый компьютер сначала просматривает свою собственную таблицу соответствия символьных имен и IP-адресов. Такая таблица хранится чаще всего в виде текстового файла простой структуры - каждая его строка содержит запись об одном символьном имени и его IP-адресе. В ОС Unix такой файл традиционно носит имя HOSTS.
2. Будем считать, что компьютер cit.dol.ru имеет файл HOSTS, а в нем есть строка
142.06.13.14 s1.msk.su.
Поэтому разрешение имени выполняется локально, так что протокол IP может теперь формировать IP-пакеты с адресом назначения 142.06.13.14 для взаимодействия с компьютером s1.msk.su.
3. Протокол IP компьютера cit.dol.ru проверяет, нужно ли маршрутизировать пакеты для адреса 142.06.13.14. Так как адрес сети назначения равен 142.06.0.0, а адрес сети, к которой принадлежит компьютер, равен 194.87.23.0, то маршрутизация необходима.
4. Компьютер cit.dol.ru начинает формировать кадр Ethernet для отправки IP-пакета маршрутизатору по умолчанию с IP-адресом 194.87.23.1. Для этого ему нужен МАС-адрес порта маршрутизатора, подключенного к его сети. Этот адрес скорее всего уже находится в кэш-таблице протокола ARP компьютера, если он хотя бы раз за последнее включение обменивался данными с компьютерами других сетей. Пусть этот адрес в нашем примере был найден именно в кэш-памяти. Обозначим его МАС11, в соответствии с номером маршрутизатора и его порта.
5. В результате компьютер cit.dol.ru отправляет по локальной сети кадр Ethernet, имеющий следующие поля:
| DA (Ethernet) | ... | DESTINATION IP | ... | ... | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| МАС11 | 142.06.13.14 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
6. Кадр принимается портом 1 маршрутизатора 1 в соответствии с протоколом Ethernet, так как МАС-узел этого порта распознает свой адрес МАС11. Протокол Ethernet извлекает из этого кадра IP-пакет и передает его программному обеспечению маршрутизатора, реализующему протокол IP. Протокол IP извлекает из пакета адрес назначения и просматривает записи своей таблицы маршрутизации. Пусть маршрутизатор 1 имеет в своей таблице маршрутизации запись
142.06.0.0 135.12.0.11 2 1,
которая говорит о том, что пакеты для сети 142.06. 0.0 нужно передавать маршрутизатору 135.12.0.11, подключенному к той же сети, что и порт 2 маршрутизатора 1.
7. Маршрутизатор 1 просматривает параметры порта 2 и находит, что он подключен к сети FDDI. Так как сеть FDDI имеет значение максимального транспортируемого блока MTU больше, чем сеть Ethernet, то фрагментация поля данных IP-пакета не требуется. Поэтому маршрутизатор 1 формирует кадр формата FDDI, в котором указывает MAC-адрес порта маршрутизатора 2, который он находит в своей кэш-таблице протокола ARP:
| DA (FDDI) | ... | DESTINATION IP | ... | ... | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| МАС21 | 142.06.13.14 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
8. Аналогично действует маршрутизатор 2, формируя кадр Ethernet для передачи пакета маршрутизатору 3 по сети Ethernet c IP-адресом 203.21.4.0:
| DA (Ethernet) | ... | DESTINATION IP | ... | ... | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| МАС32 | 142.06.13.14 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
9. Наконец, после того, как пакет поступил в маршрутизатор сети назначения - маршрутизатор 3, появляется возможность передачи этого пакета компьютеру назначения. Маршрутизатор 3 видит, что пакет нужно передать в сеть 142.06.0.0, которая непосредственно подключена к его первому порту. Поэтому он посылает ARP-запрос по сети Ethernet c IP-адресом компьютера s1.msk.su (считаем, что этой информации в его кэше нет), получает ответ, содержащий адрес MACs1, и формирует кадр Ethernet, доставляющий IP-пакет по локальной сети адресату.
| DA (Ethernet) | ... | DESTINATION IP | ... | ... | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| МАСs1 | 142.06.13.14 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Часто администраторы сетей испытывают неудобства, из-за того, что количество централизовано выделенных им номеров сетей недостаточно для того, чтобы структурировать сеть надлежащим образом, например, разместить все слабо взаимодействующие компьютеры по разным сетям.
В такой ситуации возможны два пути. Первый из них связан с получением от 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 (рисунок 4.4). Этот адрес используется маршрутизатором, соединяющим сеть с остальной частью интерсети. И пусть среди всех станций сети есть станции, слабо взаимодействующие между собой. Их желательно было бы изолировать в разных сетях. Для этого сеть можно разделить на две сети, подключив их к соответствующим портам маршрутизатора, и задать для этих портов в качестве маски, например, число 255.255.255.0, то есть организовать внутри исходной сети с централизовано заданным номером две подсети класса C (можно было бы выбрать и другой размер для поля адреса подсети). Извне сеть по-прежнему будет выглядеть, как единая сеть класса В, а на местном уровне это будут две отдельные сети класса С. Приходящий общий трафик будет разделяться местным маршрутизатором между подсетями.
Рис. 4.4. Пример использования масок для структурирования сети
Необходимо заметить, что, если принимается решение об использовании механизма масок, то соответствующим образом должны быть сконфигурированы и маршрутизаторы, и компьютеры сети.
Порт - цифровой номер, который является программным адресом, используемым для взаимодействия различных конечных точек (сетевых устройств, хостов) в современных компьютерных сетях на транспортном уровне модели OSI. Порты используются в транспортных протоколах TCP, UDP, SCTP, DCCP и позволяют различным программам и сетевым службам на одном хосте получать данные в IP-пакетах независимо друг от друга. Всякое взаимодействие двух хостов подразумевает использование как минимум одного порта получателя, и как правило, порта источника. Номер порта, добавленный к IP-адресу компьютера, завершает идентификацию возможного сеанса связи. То есть, пакеты данных направляются по сети к определенному IP-адресу назначения, а затем, по достижении конечного компьютера, далее направляется конкретному процессу, связанному с номером порта назначения. Принцип использования портов зависит от протокола, который их использует. Порт хоста назначения конкретного сетевого взаимодействия обычно известен приложению заранее. Порт хоста-источника сетевого пакета может назначаться как динамически для каждого нового сеанса связи, так и быть постоянным, статическим. Для TCP-соединения порт хоста-отправителя особенно важен, так как именно на него должен прийти ответ и подтверждение доставки пакета от хоста-получателя. Для SCTP в рамках ассоциации может использоваться несколько портов хоста-источника и несколько портов хоста-назначения (таким образом в данном протоколе достигается более высокая надежность сеанса связи и скорость передачи). В случае, если определенный номер постоянно закреплен за определенной программой на хосте и может постоянно использоваться для приема и / или передачи данных, то говорят что такой порт является "открытым". Сходная терминология открытый порт или закрытый (заблокированный) порт используется в сетевых брандмауэрах. Если конкретная программа ожидает передачи на определенный порт и держит его открытым, говорят, что программа "слушает порт". Номера портов, рекомендованные и используемые для конкретных специфических целей, т.е. для сетевых сервисов, выделяет и регистрирует IANA (Internet Assigned Numbers Authority), однако на практике часто встречаются случаи их неофициального применения.
Логотип Викиучебника Имеется викиучебник по теме
«Порт (компьютерные сети)»
Ввиду значительного распространения протоколов TCP и UDP, чаще всего упоминая порты в сети подразумевают порты именно для этих транспортных протоколов. Сетевые сервисы в SCTP и DCCP обычно используют номера, соответствующие их реализациям в TCP и UDP (при наличии).
Номер порта является 16-разрядным целым двоичным числом, таким образом, порты возможны в диапазоне от 1 до 65535 (для TCP, номер порта 0 зарезервирован и не может быть использован). Для UDP порт источника не является обязательным и нулевое значение означает отсутствие порта.
Порты отправителя и получателя
TCP- или UDP-пакеты всегда содержат два поля номера порта: отправителя и получателя. Тип обслуживающей программы определяется портом получателя поступающих запросов, и этот же номер является портом отправителя ответов. «Обратный» порт (порт отправителя запросов, он же порт получателя ответов) при подключении по TCP определяется клиентом произвольно (хотя номера меньше 1024 и уже занятых портов не назначаются), и для пользователя интереса не представляет.
Использование обратных номеров портов в UDP зависит от реализации.
Состояния порта
Активные порты протоколов транспортного уровня во многих операционных системах (Windows, Unix-подобные) могут быть обнаружены с помощью команды NetStat или nmap (в UNIX / Linux).
Возможны следующие состояния порта, показываемые netstat и nmap:
Состояние Описание
open программа-сервер готова принимать подключения
listen сервер слушает данный порт
filtred файрвол или иная причина не позволяет nmap’у определить открыт или закрыт порт
closed
Технология Comet – модель работы Веб-приложения, при которой постоянное HTTP-соединение позволяет Веб-серверу отправлять ( push ) данные браузеру без дополнительного запроса со стороны браузера [13, 14, 15, 16]. Название " Comet " используется для обозначения множества техник, позволяющих достичь такого взаимодействия. Общее у этих методов то, что они основаны на технологиях, непосредственно поддерживаемых браузером, таких как JavaScript, а не на плагинах. Теоретически подход Comet отличается от изначальной концепции Всемирной паутины, при которой браузер запрашивает страницу полностью или частично для того, чтобы обновить страницу. Однако на практике приложения Comet обычно используют Ajax с "long polling" для проверки наличия новой информации на сервере.
13.5.1. HTTP server push
HTTP server push (так же называемое HTTP streaming) – механизм отправки данных с Веб-сервера к Веб-браузеру (рис. 13.4) [15]. HTTP server push может быть реализовано посредством нескольких механизмов. Основной – это когда Веб-сервер не закрывает соединение после отправки ответа клиенту. Веб-сервер оставляет соединение открытым, так что если произойдет событие, то оно может быть отправлено одному или множеству клиентов. Иначе данные составляются в очередь до следующего запроса клиента. Большинство серверов реализуют эту функциональность через CGI (например, NPH скрипты в Apache).
Рис. 13.4. Схема работы Comet – HTTP-streaming
Другой механизм относится к специальному MIME type, называемый multipart/x-mixed-replace, который был введен Netscape в 1995. Веб-браузер интерпретирует это как изменения документа всякий раз, когда сервер сообщает о новой версии клиенту. Сегодня это все еще поддерживается Firefox, Opera и Safari, но традиционно игнорируется Internet Explorer. Это применимо к HTML-документам, но также для потокового отображения картинок для приложений работающих с Веб-камерой.
WHATWG Web Applications 1.0 предлагает включить механизм "проталкивания" содержимого клиенту. 1 сентября 2006 браузер Opera реализовала эту новую экспериментальную технологию в функциональности с названием "Server-Sent Events". Сейчас это часть стандартов HTML5. Другой, относящейся к вопросу, частью HTML5 стали Веб-сокеты, которые доступны в Google Chrome, начиная с версии 4.0.249.0, и существуют так же JavaScript библиотеки, эмулирующие работу Веб-сокетов.
В последнее время часто можно услышать выражение real-time web, за которым, как говорят, будущее Интернета. По сути, это набор технологий, который позволяет получать в реальном времени данные добавляемые в Сеть. Частным случаем этой идеи является real-time search – поиск в реальном времени.
На данный момент существует несколько поисковиков в реальном времени, а так же несколько экспериментов от гигантов вроде компании Google. Остаются не решенными некоторые практические вопросы, например определение релевантности в поисковой выдаче, но сама технология трансляции данных в браузер пользователя вполне работоспособна.
13.5.2. Pooling
Один из способов узнать, нет ли на сервере каких либо обновлений, применять технологию AJAX, с определенным интервалом времени делать запрос на сервер (рис. 13.5) [15].
Рис. 13.5. Пример асинхронных запросов в AJAX – short polling
Такой тип взаимодействия называется polling (от англ. poll – тянуть), именно вытягиванием данных и занимается браузер. Преимущества перед полным обновлением страницы очевидны, но есть и недостатки. Главным из них является "холостая работа" – часто браузер делает сотни запросов, а в ответ узнает, что новых данных нет. Именно для решения этой проблемы и появилась технология long polling, позволяющая делать запросы, которые возвращают результат, как только он появляется. Пример взаимодействия показан на рис. 13.6 [15].
Рис. 13.6. Пример долгих асинхронных запросов – long polling
Эта техника является золотой серединой между простым AJAX и сложным HTTP-streaming. Главным преимуществом является то, что клиент создает всего одно соединение, через которое получает данные от сервера в реальном времени. Главными недостатками можно назвать сложность реализации и несоответствие духу протокола HTTP.
WebSocket — протокол связи поверх TCP-соединения, предназначенный для обмена сообщениями между браузером и веб-сервером в режиме реального времени.
В настоящее время в W3C осуществляется стандартизация API Web Sockets. Черновой вариант стандарта этого протокола утвержден IETF.
WebSocket разработан для воплощения в веб-браузерах и веб-серверах, но он может быть использован для любого клиентского или серверного приложения. Протокол WebSocket — это независимый протокол, основанный на протоколе TCP. Он делает возможным более тесное взаимодействие между браузером и веб-сайтом, способствуя распространению интерактивного содержимого и созданию приложений реального времени.
WebSocket особенно хорош для сервисов, которые нуждаются в постоянном обмене данными, например онлайн игры, торговые площадки, работающие в реальном времени, уведомления, чаты и т.д.
Для установления соединения WebSocket клиент и сервер используют протокол, похожий на HTTP. Клиент формирует особый HTTP-запрос, на который сервер отвечает определенным образом.
До редакции черновика протокола номер 75 включительно соединение WebSocket устанавливалось следующим образом. Запрос клиента:
GET /demo HTTP/1.1 Upgrade: WebSocket Connection: Upgrade Host: example.com Origin: http://example.com WebSocket-Protocol: sample
Ответ сервера, подтверждающий переход на WebSocket:
HTTP/1.1 101 Web Socket Protocol Handshake Upgrade: WebSocket Connection: Upgrade WebSocket-Origin: http://example.com WebSocket-Location: ws://example.com/demo WebSocket-Protocol: sample
Сразу после отправки ответа WebSocket-соединение считается установленным, клиент и сервер могут начинать двунаправленный обмен сообщениями по этому же TCP-соединению. Для передачи текстового сообщения (в кодировке UTF-8) необходимо перед ним передать нулевой байт, а после — байт со значением 255.
2 июня 2010 года в протокол WebSocket были внесены поправки, изменившие процедуру установления соединения WebSocket без сохранения обратной совместимости. В 76-й редакции черновика протокола WebSocket добавлена защита от поддельных запросов. Клиент, поддерживающий новую схему, присылает следующий запрос:
В запрос добавлены новые заголовки «Sec-WebSocket-Key1» и «Sec-WebSocket-Key2» и 8-байтовое тело запроса. Все они генерируются клиентом случайным образом.
Ответ сервера, подтверждающий переход на WebSocket:
Ответ содержит новые названия заголовков («Sec-WebSocket-Origin», «Sec-WebSocket-Location», «Sec-WebSocket-Protocol» вместо «WebSocket-Origin», «WebSocket-Location», «WebSocket-Protocol») и 16-байтное тело ответа, вычисляемое следующим образом:
Примечания.
Несмотря на «похожесть» новых запросов и ответов на запросы и ответы протокола HTTP, они таковыми не являются. Например, в запросе есть тело, но в заголовках поле «Content-Length» отсутствует (что нарушает соглашения HTTP).
Серверной части следует поддерживать оба вида клиентов и отличать их по наличию или отсутствию в запросе заголовков Sec-WebSocket-Key1 и Sec-WebSocket-Key2.
В версию 07 черновика протокола от 22 апреля 2011 были внесены изменения.
В отличие от протокола 76, согласно которому данные передаются без шифрования , каждый байт передаваемых от клиента (браузера) серверу данных в этой версии протокола обязательно маскируется 4-байтовой маской . Она создается для каждого сообщения заново.
Передаваемое сообщение теперь имеет заголовок, в котором содержатся такие данные, как:
Взаимодействие между клиентом и сервером начинается с запроса от клиента:
Ответ сервера имеет следующий вид:
Ответ содержит заголовок Sec-WebSocket-Protocol с единственным протоколом, выбраным сервером (chat) из всех поддерживаемых клиентом (chat, superchat). Заголовок Sec-WebSocket-Accept формируется следующим образом:
(в приведенном примере получится 
)
Пример реализации вышеуказанного алгоритма на языке PHP:
rfc-frame
11 декабря 2011 года протокол приобрел статус RFC.
Вместо заголовка Sec-WebSocket-Origin теперь используется просто Origin.
Протокол Web Socket определяет две URI-схемы, ws: (нешифрованное соединение) и wss: (шифрованное соединение).
Для установки соединения клиентский скрипт создает объект WebSocket, в конструктор которого передает параметр WebSocket URI, и определяет функции обратного вызова при соединении, получении сообщения и разрыве соединения.
В настоящее время WebSocket поддерживается в следующих браузерах:
Проверить поддержку браузером WebSocket можно, пройдя по ссылке: http://caniuse.com/#feat=websockets.
В конце ноября 2010 Adam Barth опубликовал результаты исследования надежности используемого протокола . По его результатам выяснилось, что в случае использования прозрачных прокси-серверов возможна подмена кеша передаваемых данных с тем, что пользователи вместо реальных данных будут получать версию данных от злоумышленника. Проблема оказалась достаточно серьезной для того, чтобы разработчики Firefox и Opera объявили о том, что в будущих версиях их браузеров поддержка веб-сокетов будет по умолчанию отключена вплоть до устранения проблемы небезопасности данного протокола (хотя осталась возможность их включить).
1. Что такое протокол IP?
2. Какое назначение у портов в протоколе IP?
3. Какой диапазон портов считается зарезервированным для системных служб?
4. Что такое Polling в контексте веб-технологий?
5. Какой из следующих методов используется для постоянного соединения между клиентом и сервером?
6. Какой из следующих методов основан на идее "держать соединение открытым" для получения данных в реальном времени?
7. Что такое Comet в веб-разработке?
8. Какой порт используется для HTTP-соединений по умолчанию?
9. Какой порт используется для HTTPS-соединений по умолчанию?
10. Какой из следующих методов не является протоколом обмена данными?
11. Какой из следующих протоколов является протоколом межсетевого взаимодействия?
12. Какой метод позволяет серверу отправлять данные клиенту без запроса со стороны клиента?
13. Какой из следующих методов использует постоянное соединение для передачи данных?
14. Какой метод предполагает отправку запроса на сервер и ожидание ответа?
15. Какой из следующих методов позволяет избежать постоянных запросов на сервер?
16. Какой протокол используется для управления передачей данных поверх IP?
17. Какой порт обычно используется для FTP?
18. Какой из следующих протоколов не является ориентированным на соединение?
19. Какой метод обычно используется для передачи данных в режиме реального времени?
20. Какой метод позволяет серверу "поддерживать" соединение с клиентом?
А как ты думаешь, при улучшении ip, будет лучше нам? Надеюсь, что теперь ты понял что такое ip, порт соединения, polling, web socket, comet и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Основы интернет и веб технологий
Ответы на вопросы для самопроверки пишите в комментариях, мы проверим, или же задавайте свой вопрос по данной теме.
Комментарии
Оставить комментарий
Основы интернет и веб технологий
Термины: Основы интернет и веб технологий