Сети16-30x

Оглавление
16)FDM .......................................................................................................................................................... 4
Частотное разделение каналов .................................................................................................................. 4
17)FHSS ......................................................................................................................................................... 5
Методы расширения спектра ..................................................................................................................... 5
18)GPRS ......................................................................................................................................................... 7
Архитектура .............................................................................................................................................. 7
Принцип работы ...................................................................................................................................... 7
Интеграция с Интернетом....................................................................................................................... 8
Применение ............................................................................................................................................. 8
19)GSM .......................................................................................................................................................... 9
Общие сведения ...................................................................................................................................... 9
Предоставляемые услуги ......................................................................................................................10
Преимущества и недостатки ................................................................................................................10
20)HDLC .......................................................................................................................................................12
История...................................................................................................................................................12
Типы станций .........................................................................................................................................12
Логические состояния ...........................................................................................................................12
Режимы состояния передачи ...............................................................................................................13
Конфигурации канала ...........................................................................................................................13
Кадры......................................................................................................................................................14
Структура кадров ...............................................................................................................................14
Типы кадров .......................................................................................................................................15
21)HFC .........................................................................................................................................................18
22)HTML ......................................................................................................................................................20
Общее представление ..........................................................................................................................20
Браузеры ................................................................................................................................................20
Версии ....................................................................................................................................................21
Перспективы ..........................................................................................................................................21
Структура HTML-документа ..................................................................................................................22
Варианты DOCTYPE для HTML 4.01 ...................................................................................................23
Варианты DOCTYPE для HTML 5 ........................................................................................................23
Браузерные войны ................................................................................................................................23
23)HTTP .......................................................................................................................................................25
Преимущества .......................................................................................................................................25
Простота .............................................................................................................................................25
Расширяемость ..................................................................................................................................25
Распространённость ..........................................................................................................................26
Недостатки и проблемы........................................................................................................................26
Большой размер сообщений ............................................................................................................26
Отсутствие «навигации» ...................................................................................................................26
Нет поддержки распределённости ..................................................................................................26
Программное обеспечение ..................................................................................................................27
Клиенты ..............................................................................................................................................27
Исходные серверы ............................................................................................................................28
Прокси-серверы .................................................................................................................................28
История развития ..................................................................................................................................28
HTTP/0.9 ..............................................................................................................................................28
HTTP/1.0 ..............................................................................................................................................28
HTTP/1.1 ..............................................................................................................................................28
HTTP/1.2 ..............................................................................................................................................28
Структура протокола .............................................................................................................................29
Стартовая строка................................................................................................................................29
Методы ...............................................................................................................................................30
Коды состояния..................................................................................................................................32
Заголовки ...........................................................................................................................................33
Тело сообщения.................................................................................................................................34
Примеры диалогов HTTP.......................................................................................................................35
Обычный GET-запрос ........................................................................................................................35
Перенаправления ..............................................................................................................................35
Докачка и фрагментарное скачивание ............................................................................................37
Основные механизмы протокола ........................................................................................................38
Частичные GET ...................................................................................................................................38
Условные GET .....................................................................................................................................39
Согласование содержимого .............................................................................................................39
Множественное содержимое ..........................................................................................................41
Особенности протокола ........................................................................................................................42
24)ICMP .......................................................................................................................................................44
Технические подробности ....................................................................................................................44
Использование ICMP-сообщений ........................................................................................................44
Формат пакета ICMP ..............................................................................................................................45
Типы пакетов ICMP (полный список) ...............................................................................................45
25)IMAP.......................................................................................................................................................47
Описание протокола IMAP....................................................................................................................47
Методы проверки подлинности пользователя в IMAP ..................................................................48
Клиентская часть протокола IMAP ...................................................................................................49
Преимущества по сравнению с POP3 ..................................................................................................50
26)ISP...........................................................................................................................................................52
Россия .....................................................................................................................................................52
27)ITU ..........................................................................................................................................................53
Задачи МСЭ ............................................................................................................................................53
Структура МСЭ .......................................................................................................................................53
28)LAN .........................................................................................................................................................55
Локальная вычислительная сеть ..............................................................................................................55
Содержание ...........................................................................................................................................55
Построение сети ....................................................................................................................................55
Адресация ..............................................................................................................................................56
LAN и VPN ...............................................................................................................................................57
29)LMDS ......................................................................................................................................................58
LMDS..........................................................................................................................................................58
Как расшифровывается LMDS ........................................................................................................58
Технология LMDS как решение "последней мили" ....................................................................59
30)MAC........................................................................................................................................................60
[править]Механизм контроля доступа к каналу ..........................................................................60
MAC-адрес ..................................................................................................................................................61
[править]Смена MAC-адреса ...........................................................................................................63
16)FDM
http://en.wikipedia.org/wiki/Frequency-division_multiplexing
Частотное разделение каналов
Материал из Википедии — свободной энциклопедии
Частотное разделение каналов, Мультиплексирование с разделением по частоте
(англ. Frequency-Division Multiplexing, FDM)
Разделение каналов осуществляется по частотам. Так как радиоканал обладает
определённым спектром, то в сумме всех передающих устройств и получается
современная радио связь. Например: спектр сигнала для мобильного телефона 8 Мгц.
Если мобильный оператор даёт абоненту частоту 880 МГц, то следующий абонент, может
занимать частоту 880+8=888 МГц. Таким образом, если оператор мобильной связи имеет
лицензионную частоту 800—900 Мгц, то он способен обеспечить около 12 каналов, с
частотным разделением.
Частотное разделение каналов применяется в технологии X-DSL. По телефонной лапше
передаются сигналы различной частоты: телефонный разговор-0,3-3,4 Кгц а для передачи
данных используется полоса от 28 до 1300 Кгц.
Очень важно фильтровать сигналы. Иначе будут происходить наложения сигналов, из-за
чего связь может сильно ухудшиться.
17)FHSS
Есть только на английской вики.
http://en.wikipedia.org/wiki/FHSS
Со скачкообразной перестройкой частоты с расширенным спектром (FHSS) является метод
передачи радиосигналов за счет быстрого переключения носителя среди многих частотных
каналов, с использованием псевдослучайной последовательности известны как передатчик и
приемник. Он используется в качестве нескольких методов доступа в скачкообразной
перестройкой частоты Code Division Multiple Access (FH-CDMA) схеме.
С расширенным спектром передачи предлагает три основных преимущества по сравнению с
фиксированной частотой передачи:
Расширением спектра сигналов высокой устойчивостью к узкополосных помех.Процесс
повторного сбора распространения сигнала распространяется сигнал помехи, заставляя его
отступать на задний план.
Расширением спектра сигналов трудно перехватить.Сигнала FHSS просто выглядит как
увеличение фонового шума для узкополосного приемника.Перехватчик сможет лишь перехватить
передачу, если последовательность псевдослучайных было известно.
С расширенным спектром передачи может поделиться полосе частот со многими типами
обычных передач с минимальным вмешательством.Расширением спектра сигналов добавить
минимальным уровнем шума в узких частот связи, и наоборот. В результате, пропускная
способность может быть использована более эффективно.
Методы расширения спектра
Материал из Википедии — свободной энциклопедии
Одним из способов повышения эффективности передачи информации с помощью
модулированных сигналов через канал с сильными линейными искажениями
(замираниями) является расширение спектра, приводящее к увеличению базы сигнала.
В существующих на сегодняшний день системах для этой цели используются три метода:


псевдослучайная перестройка рабочей частоты (ППРЧ) (англ. FHSS — Frequency Hopping
Spread Spectrum). Суть метода заключается в периодическом скачкообразном изменении
несущей частоты по некоторому алгоритму, известному приемнику и передатчику.
Преимущество метода — простота реализации. Метод используется в Bluetooth;
расширение спектра методом прямой последовательности (ПРС) (англ. DSSS — Direct
Sequence Spread Spectrum). Метод по эффективности превосходит ППРЧ, но сложнее в
реализации. Суть метода заключается в повышении тактовой частоты модуляции, при этом
каждому символу передаваемого сообщения ставится в соответствие некоторая
достаточно длинная псевдослучайная последовательность (ПСП). Метод используется в
таких системах как CDMA и системах стандарта IEEE 802.11;

расширение спектра методом линейной частотной модуляции (ЛЧМ) (англ. CSS — Chirp
Spread Spectrum). Суть метода заключается в перестройке несущей частоты по линейному
закону. Метод используется в радиолокации и в некоторых радиомодемах[1].
18)GPRS
GPRS (англ. General Packet Radio Service — пакетная радиосвязь общего пользования) —
надстройка над технологией мобильной связи GSM, осуществляющая пакетную передачу данных.
GPRS позволяет пользователю сети сотовой связи производить обмен данными с другими
устройствами в сети GSM и с внешними сетями, в том числе Интернет. GPRS предполагает
тарификацию по объёму переданной/полученной информации, а не по времени, проведённому
онлайн.
Архитектура
Служба передачи данных GPRS надстраивается над существующей сетью GSM. На
структурном уровне систему GPRS можно разделить на две части: подсистему базовых
станций (BSS) и опорную сеть GPRS (GPRS Core Network).
В BSS входят все базовые станции и контроллеры, которые поддерживают пакетную
передачу данных. Для этого BSC (Base Station Controller) дополняется блоком управления
пакетами — PCU (Packet Controller Unit), а BTS (Base Tranceiver Station) — кодирующим
устройством GSM в форматы, используемые протоколами TCP/IP.
Шлюзы с внешними сетями (Internet, intranet, X.25) называют GGSN (Gateway GPRS
Support Node). Обмен информацией между SGSN и GGSN происходит на основе IPпротоколов.
Также в состав GPRS Core входят DNS (Domain Name System) и Charging Gateway (шлюз
для связи с системой тарификации).
Принцип работы
При использовании GPRS информация собирается в пакеты и передаётся через
неиспользуемые в данный момент голосовые каналы, такая технология предполагает
более эффективное использование ресурсов сети GSM. При этом, что является
приоритетом передачи — голосовой трафик или передача данных — выбирается
оператором связи. Федеральная тройка в России использует безусловный приоритет
голосового трафика перед данными, поэтому скорость передачи зависит не только от
возможностей оборудования, но и от загрузки сети. Возможность использования сразу
нескольких каналов обеспечивает достаточно высокие скорости передачи данных,
теоретический максимум при всех занятых таймслотах TDMA составляет 171,2 кбит/c.
Существуют различные классы GPRS, различающиеся скоростью передачи данных и
возможностью совмещения передачи данных с одновременным голосовым вызовом.
Передача данных разделяется по направлениям «вниз» (downlink; DL) — от сети к
абоненту, и «вверх» (uplink, UL) — от абонента к сети. Мобильные терминалы
разделяются на классы по количеству одновременно используемых таймслотов для
передачи и приёма данных. Современные телефоны (июнь 2006) поддерживают до 4-х
таймслотов одновременно для приёма по линии «вниз» (то есть могут принимать 85
кбит/с по кодовой схеме CS-4), и до 2-х для передачи по линии «вверх» (class 10 или 4+2).
Абоненту, подключенному к GPRS, предоставляется виртуальный канал, который на
время передачи пакета становится реальным, а в остальное время используется для
передачи пакетов других пользователей. Поскольку один канал могут использовать
несколько абонентов, возможно возникновение очереди на передачу пакетов, и, как
следствие, задержка связи. Например, современная версия программного обеспечения
контроллеров базовых станций допускает одновременное использование одного
таймслота шестнадцатью абонентами в разное время и до 5 (из 8) таймслотов на частоте,
итого — до 80 абонентов, пользующихся GPRS на одном канале связи (средняя
максимальная скорость при этом 21,4*5/80 = 1,3 кбит/с на абонента). Другой крайний
случай — пакетирование таймслотов в один непрерывный с вытеснением голосовых
абонентов на другие частоты (при наличии таковых и с учётом приоритета). При этом
телефон, работающий в режиме GPRS, принимает все пакеты на одной частоте и не тратит
времени на переключения. В этом случае скорость передачи данных достигает
максимально возможной, как и описано выше, 4+2 таймслота (class 10).
Технология GPRS использует GMSK-модуляцию. В зависимости от качества
радиосигнала, данные, пересылаемые по радиоэфиру, кодируются по одной из 4-х
кодовых схем (CS1—CS4). Каждая кодовая схема характеризуется избыточностью
кодирования и помехоустойчивостью, и выбирается автоматически в зависимости от
качества радиосигнала.
Интеграция с Интернетом
GPRS по принципу работы аналогична Интернету: данные разбиваются на пакеты и
отправляются получателю (необязательно одним и тем же маршрутом), где происходит их
сборка. При установлении сессии каждому устройству присваивается уникальный адрес,
что по сути превращает его в сервер. Протокол GPRS прозрачен для TCP/IP, поэтому
интеграция GPRS с Интернетом незаметна конечному пользователю. Пакеты могут иметь
формат IP или X.25, при этом не имеет значения, какие протоколы используются поверх
IP, поэтому есть возможность использования любых стандартных протоколов
транспортного и прикладного уровней, применяемых в Интернете (TCP, UDP, HTTP,
HTTPS, SSL, POP3, XMPP и др.). Также при использовании GPRS мобильный телефон
выступает как клиент внешней сети, и ему присваивается IP-адрес (постоянный или
динамический).
Применение

Мобильный доступ в Интернет с приемлемой скоростью передачи данных, быстрым
соединением и тарификацией по количеству переданных/полученных данных.

Мобильный и безопасный доступ сотрудников к корпоративным сетям, удалённым базам
данных, почтовым и информационным серверам предприятий.

Телеметрия. Устройство может оставаться в подключённом состоянии, не занимая при
этом отдельный канал. Такая услуга востребована службами охраны (сигнализация),
банками и платёжными системами (установка банкоматов, терминалов оплаты услуг), в
промышленности (датчики и счётчики различного рода, например по ходу нефте- и
газопроводов).

Спутниковый мониторинг транспорта
19)GSM
GSM (от названия группы Groupe Spécial Mobile, позже переименован в Global System for Mobile
Communications) (русск. СПС-900) — глобальный цифровой стандарт для мобильной сотовой
связи, с разделением частотного канала по принципу TDMA и средней степенью безопасности.
Разработан под эгидой Европейского института стандартизации электросвязи (ETSI) в конце 80-х
годов.
TDMA (англ. Time Division Multiple Access — множественный доступ с разделением по
времени) — способ использования радиочастот, когда в одном частотном интервале
находятся несколько абонентов, разные абоненты используют разные временные слоты
(интервалы) для передачи. Является приложением мультиплексирования канала с
разделением по времени (TDM — Time Division Multiplexing) к радиосвязи.
Таким образом, TDMA предоставляет каждому пользователю полный доступ к интервалу
частоты в течение короткого периода времени (в GSM один частотный интервал делится
на 8 временных слотов). TDMA в настоящее время является доминирующей технологией
для мобильных сотовых сетей и используется в стандартах GSM, TDMA (ANSI-136), PDC.
Общие сведения
GSM относится к сетям второго поколения (2 Generation) (1G — аналоговая сотовая связь,
2G — цифровая сотовая связь, 3G — широкополосная цифровая сотовая связь,
коммутируемая многоцелевыми компьютерными сетями, в том числе Интернет).
Сотовые телефоны выпускаются для 4 диапазонов частот: 850 МГц, 900 МГц, 1800 МГц,
1900 МГц.
В зависимости от количества диапазонов, телефоны подразделяются на классы и
вариацию частот в зависимости от региона использования.

Однодиапазонные — телефон может работать на одной из частот. В настоящее время не
выпускаются, но существует возможность ручного выбора определённой частоты в
некоторых моделях телефонов, например Motorola C115, или с помощью инженерного
меню телефона.

Двухдиапазонные (Dual Band) — для Европы, Азии, Африки, Австралии 900/1800 и
850/1900 для Америки и Канады.

Трёхдиапазонные (Tri Band) — для Европы, Азии, Африки, Австралии 900/1800/1900 и
850/1800/1900 для Америки и Канады.

Четырехдиапазонные (Quad Band) — поддерживают все диапазоны 850/900/1800/1900.
В стандарте GSM применяется GMSK модуляция с величиной нормированной полосы
ВТ — 0,3, где В — ширина полосы фильтра по уровню минус 3 дБ, Т — длительность
одного бита цифрового сообщения.
GSM на сегодняшний день является наиболее распространённым стандартом связи. По
данным ассоциации GSM (GSMA) на данный стандарт приходится 82% мирового рынка
мобильной связи, 29% населения земного шара использует глобальные технологии GSM.
В GSMA в настоящее время входят операторы более чем 210 стран и территорий.
Предоставляемые услуги
GSM обеспечивает поддержку следующих услуг:




Услуги передачи данных (синхронный и асинхронный обмен данными, в том числе
пакетная передача данных — GPRS). Данные услуги не гарантируют совместимость
терминальных устройств и обеспечивают только передачу информации к ним и от них.
Передача речевой информации.
Передача коротких сообщений (SMS).
Передача факсимильных сообщений.
Дополнительные (необязательные к предоставлению) услуги:






Определение вызывающего номера и ограничение такого определения.
Безусловная и условная переадресация вызова на другой номер.
Ожидание и удержание вызова.
Конференц-связь (одновременная речевая связь между тремя и более подвижными
станциями).
Запрет на определённые пользователем услуги (международные звонки, роуминговые
звонки и др.)
Голосовая почта.
и многие другие услуги.
Преимущества и недостатки
Преимущества стандарта GSM:







Меньшие по сравнению с аналоговыми стандартами (NMT-450, AMPS-800) размеры и вес
телефонных аппаратов при большем времени работы без подзарядки аккумулятора. Это
достигается в основном за счёт аппаратуры базовой станции, которая постоянно
анализирует уровень сигнала, принимаемого от аппарата абонента. В тех случаях, когда он
выше требуемого, на сотовый телефон автоматически подаётся команда снизить
излучаемую мощность.
Хорошее качество связи при достаточной плотности размещения базовых станций.
Большая ёмкость сети, возможность большого числа одновременных соединений.
Низкий уровень индустриальных помех в данных частотных диапазонах.
Улучшенная (по сравнению с аналоговыми системами) защита от подслушивания и
нелегального использования, что достигается путём применения алгоритмов шифрования
с разделяемым ключом.[уточнить]
Эффективное кодирование (сжатие) речи. EFR-технология была разработана фирмой Nokia
и впоследствии стала промышленным стандартом кодирования/декодирования для
технологии GSM.[уточнить]
Широкое распространение, особенно в Европе, большой выбор оборудования. На
сегодняшний день стандарт GSM поддерживают 228 операторов, официально
зарегистрированных в Ассоциации операторов GSM из 110 стран.

Возможность роуминга. Это означает, что абонент одной из сетей GSM может
пользоваться сотовым телефонным номером не только у себя «дома», но и перемещаться
по всему миру переходя из одной сети в другую не расставаясь со своим абонентским
номером. Процесс перехода из сети в сеть происходит автоматически, и пользователю
телефона GSM нет необходимости заранее уведомлять оператора (в сетях некоторых
операторов, могут действовать ограничения на предоставление роуминга своим
абонентам, более детальную информацию можно получить обратившись
непосредственно к своему GSM оператору)
Недостатки стандарта GSM:


Искажение речи при цифровой обработке и передаче.
Связь возможна на расстоянии не более 120 км[1][2] от ближайшей базовой станции даже
при использовании усилителей и направленных антенн. Поэтому для покрытия
определённой площади необходимо большее количество передатчиков, чем в NMT-450 и
AMPS.
20)HDLC
High-Level Data Link Control (HDLC) — бит-ориентированный[1] кодопрозрачный
сетевой протокол управления каналом передачи данных канального уровня сетевой
модели OSI, разработанный ISO.
Текущим стандартом для HDLC является ISO 13239.
HDLC может быть использован в соединениях с множественным доступом, но в
настоящее время в основном используется в соединениях точка-точка с использованием
асинхронного сбалансированного режима (ABM).
История
HDLC был разработан на основе протокола SDLC (англ.) фирмы IBM. Его несильно
изменённые дочерние протоколы — LAPB (англ.), LAPM (англ.), LAPF (англ.),
LAPD (англ.) были встроены ITU соответственно в стеки протоколов X.25, V.42 (англ.),
Frame Relay, ISDN. Также HDLC был базой при разработке кадровых механизмов в
протоколе PPP, широко используемом в Интернете.
Типы станций



Первичная (ведущая) станция (Primary terminal) ответственна за управление каналом и
восстановление его работоспособности. Она производит кадры команд. В соединениях
точка-многоточка поддерживает отдельные связи с каждой из вторичных станций.
Вторичная (ведомая) станция (Secondary terminal) работает под контролем ведущей,
отвечая на её команды. Поддерживает только 1 сеанс связи.
Комбинированная станция (Combined terminal) сочетает в себе функции как ведущей, так
и ведомой станций. Производит и команды и ответы. Только соединения точка-точка.
Логические состояния
Каждая из станций в каждый момент времени находится в одном из 3 логических
состояний :

Состояние логического разъединения (LDS — Logical Disconnect State)
Если вторичная станция находится в режиме нормального разъединения (NDM), то она
может принимать кадры только после получения явного разрешения от первичной. Если
же в асинхронном режиме разъединения (ADM), то вторичная станция может самовольно
инициировать передачу.

Состояние инициализации (IS — Initialization State)
Используется для передачи управления на удалённую комбинированную станцию и для
обмена параметрами между удалёнными станциями.

Состояние передачи информации (ITS — Information Transfer State)
Всем станциям разрешено вести передачу и принимать информацию. Станции могут
находиться в режимах NRM, ARM, ABM.
Режимы состояния передачи
HDLC поддерживает три режима логического соединения, отличающиеся ролями
взаимодействующих устройств:

Режим нормального ответа (Normal Response Mode, NRM) требует инициации передачи в
виде явного разрешения на передачу от первичной станции. После использования канала
вторичной станцией (ответа на команду первичной), для продолжения передачи она
обязана ждать другого разрешения. Для выбора права на передачу первичная станция
проводит круговой опрос вторичных. Используется в основном в соединениях точкамноготочка.

Режим асинхронного ответа (Asynchronous Response Mode, ARM) даёт возможность
вторичной станции самой инициировать передачу. В основном используется в
соединениях типа кольцо и многоточечных с неизменной цепочкой опроса, так как в этих
соединениях одна вторичная станция может получить разрешение на передачу от другой
вторичной и в ответ начать передачу. То есть разрешение на передачу передаётся по типу
маркера (token). За первичной станцией сохраняются обязанности по инициализации
линии, определению ошибок передачи и логическому разъединению. Позволяет
уменьшить накладные расходы, связанные с началом передачи.

Асинхронный сбалансированный режим (Asynchronous Balanced Mode, ABM)
используется комбинированными станциями. Передача может быть инициирована с
любой стороны, может происходить в полном дуплексе. В режиме ABM оба устройства
равноправны и обмениваются кадрами, которые делятся на кадры-команды и кадрыответы.
Конфигурации канала
Для обеспечения совместимости между станциями, которые могут менять свой
статус(тип), в протоколе HDLC предусмотрены 3 конфигурации канала:

Несбалансированная конфигурация (UN — Unbalanced Normal) обеспечивает работу 1
первичной и одной или нескольких вторичных станций в (симплексном)полудуплексном и
полнодуплексном режимах, с коммутируемым или некоммутируемым каналом.

Симметричная конфигурация (UA — Unbalanced Asynchronous) обеспечивает
взаимодействие двух двухточечных несбалансированных станций. Используется 1 канал
передачи, в который мультиплексируются и команды и ответы. В данное время не
используется.

Сбалансированная конфигурация (BA — Balanced Asynchronous) состоит из 2
комбинированных станций. Передача в(симплексном) полудуплексном и
полнодуплексном режимах, с коммутируемым или некоммутируемым каналом. Каждая
станция несёт одинаковую ответственность за управление каналом.
Кадры
Кадры HDLC можно передавать, используя синхронные и асинхронные соединения. В
самих соединениях нет механизмов определения начала и конца кадра, для этих целей
используется уникальная в пределах протокола флаговая последовательность (FD —
Frame Delimiter) '01111110'(0x7E в шестнадцатеричном представлении), помещаемая в
начало и конец каждого кадра. Уникальность флага гарантируется использованием
битстаффинга в синхронных соединениях и байтстаффинга в асинхронных. Битстаффинг
— вставка битов, здесь — бита 0 после 5 подряд идущих битов 1. Битстаффинг работает
только во время передачи информационного поля (поля данных) кадра. Если передатчик
обнаруживает, что передано подряд пять единиц, то он автоматически вставляет
дополнительный ноль в последовательность передаваемых битов (даже если после этих
пяти единиц и так идёт ноль). Поэтому последовательность 01111110 никогда не появится
в поле данных кадра. Аналогичная схема работает в приемнике и выполняет обратную
функцию. Когда после пяти единиц обнаруживается ноль, он автоматически удаляется из
поля данных кадра. В байтстаффинге используется escape-последовательность, здесь —
'01111101'(0x7D в шестнадцатеричном представлении), то есть байт FD(0x7E) в середине
кадра заменяется последовательностью байтов (0x7D, 0x5E), а байт (0x7D) —
последовательностью байтов (0x7D, 0x5D).
Во время простоя среды передачи при синхронном соединении FD постоянно передаётся
по каналу для поддержания битовой синхронизации. Может иметь место совмещение
последнего бита 0 одного флага и начального бита 0 следующего. Время простоя также
называется межкадровым временны́м заполнением.
Структура кадров
Структура кадра HDLC, включая флаги FD:
Флаг Адрес Управляющее поле Информационное поле
8 бит 8 бит 8 или 16 бит
FCS Флаг
0 или более бит, кратно 8 16 бит 8 бит

Флаги FD — открывающий и закрывающий флаги, представляющие собой коды 01111110,
обрамляют HDLC-кадр, позволяя приемнику определить начало и конец кадра. Благодаря
этим флагам в HDLC-кадре отсутствует поле длины кадра. Иногда флаг конца одного кадра
может (но не обязательно) быть начальным флагом следующего кадра.

Адрес выполняет свою обычную функцию идентификации одного из нескольких
возможных устройств только в конфигурациях точка-многоточка. В двухточечной
конфигурации адрес HDLC используется для обозначения направления передачи — из сети
к устройству пользователя (10000000) или наоборот (11000000).

Управляющее поле занимает 1 или 2 байта. Его структура зависит от типа передаваемого
кадра. Тип кадра определяется первыми битами управляющего поля: 0 —
информационный, 01 — управляющий, 11 — ненумерованный тип. В структуру
управляющего поля кадров всех типов входит бит P/F, он по-разному используется в
кадрах-командах и кадрах-ответах. Например, станция-приемник при получении от
станции-передатчика кадра-команды с установленным битом P немедленно должна
ответить управляющим кадром-ответом, установив бит F.

Информационное поле предназначено для передачи по сети пакетов протоколов
вышележащих уровней - сетевых протоколов IP, IPX, AppleTalk, DECnet, в редких случаях —
прикладных протоколов, когда те выкладывают свои сообщения непосредственно в кадры
канального уровня. Информационное поле может отсутствовать в управляющих кадрах и
некоторых ненумерованых кадрах.

Поле FCS (Frame Check Sequence) — контрольная последовательность, необходимая для
обнаружения ошибок передачи. Её вычисление в основном производится методом
циклического кодирования с производящим полиномом X16+X12+X5+1 (CRC-16) в
соответствии с рекомендацией CCITT V.41. Это позволяет обнаруживать всевозможные
кортежи ошибок длиной до 16 бит вызываемые одиночной ошибкой, а также 99,9984 %
всевозможных более длинных кортежей ошибок. FCS составляется по полям Адрес,
Управляющее поле, Информационное поле. В редких случаях используются другие методы
циклического кодирования. После просчёта FCS на стороне приёмника он отвечает
положительной или отрицательной квитанцией. Повтор кадра передающей стороной
выполняется по приходу отрицательной квитанции или по истечении тайм-аута.
Типы кадров
I-кадры (информационные кадры, кадры данных)
Предназначены для передачи данных пользователя. В процессе передачи
информационных блоков осуществляется их нумерация в соответствии с алгоритмом
скользящего окна. После установления соединения данные и положительные квитанции
начинают передаваться в информационных кадрах. Логический канал HDLC является
дуплексным, так что информационные кадры, а значит, и положительные квитанции
могут передаваться в обоих направлениях. Если же потока информационных кадров в
обратном направлении нет или же нужно передать отрицательную квитанцию, то
используются управляющие кадры. При работе HDLC для обеспечения надёжности
передачи используется скользящее окно размером в 7 кадров (при размере управляющего
поля 1 байт) или 127 (при размере управляющего поля 2 байта). Для поддержания
алгоритма окна в информационных кадрах станции-отправителя отводится 2 поля:


N(S) - номер отправляемого кадра;
N(R) - номер кадра, который станция ожидает получить от своего партнера по диалогу.
Предположим для определенности, что станция А отправила станции В информационный
кадр с некоторыми значениями NA(S) и NA(R). Если в ответ на этот кадр приходит кадр
от станции В, в котором номер посланного этой станцией кадра NB(S) совпадает с
номером ожидаемого станцией А кадра NA(R), то передача считается корректной. Если
станция А принимает кадр-ответ, в котором номер отправленного кадра NB(S) неравен
номеру ожидаемого NA(R), то станция А этот кадр отбрасывает и посылает
отрицательную квитанцию REJ (отказ) с номером NA(R). Приняв отрицательную
квитанцию, станция В обязана повторить передачу кадра с номером NA(R), а также всех
кадров с большими номерами, которые она уже успела отослать, пользуясь механизмом
скользящего окна.
I-кадры также содержат бит опрос/ответ P/F (poll/final). В режиме NRM ведущий
терминал использует бит P для опроса, ведомый — бит F в последнем I-кадре ответа. В
режимах ARM и ABM биты P/F используются для форсирования ответа.
Команда/
Формат упр. поля
Описание
Ответ
C/R
8…7…6…5…4…3…2…1…..
Данные пользователя .-N(R)-… P/F…..-N(S)-..0
S-кадры (управляющие)
Используются для контроля потока ошибок передачи. В управляющих кадрах передаются
команды и ответы в контексте установленного логического соединения, в том числе
запросы на повторную передачу искаженных информационных блоков:
Готов к Приёму (RR)



Используется как положительная квитанция (до N(r)-1).
Ведущая станция может сделать опрос, установив бит P.
Ведомая станция на опрос может ответить кадром с установленным F битом, если у неё
нет данных для передачи.
Не готов к Приёму (RNR)



Используется как положительная квитанция и запрос остановить передачу I-кадров до
получения следующего кадра RR.
Ведущая или Комбинированная станции могут установить бит P для уточнения статуса
приёма ведомой/комбинированной станции.
Ведомая/комбинированная станции могут ответить установкой бита P как индикации
занятости станции.
Неприем (REJ)


Часто используется как отрицательная квитанция приемника
Неприем кадров последнего окна (повтор передачи с кадра N(r))
Выборочный Неприем(SREJ)

Неприем конкретного кадра (повтор передачи одного кадра)
Имя
Команда/
Описание
Info
Ответ
Формат упр. поля
8…7…6…5…4…3…2…1…..
C/R
Положительная
квитанция
Готов к
приёму Iкадра
.-N(R)-… P/F…0…0…0…1
Не готов к Приёму
C/R
(RNR)
Положительная
квитанция
Не готов к
Приёму
.-N(R)-… P/F…0…1…0…1
Неприем (REJ)
Отрицательная
квитанция
Повтор N
кадров
.-N(R)-… P/F…1…0…1…0
Готов к Приёму
(RR)
C/R
Выборочный
Неприем (SREJ)
C/R
Отрицательная
квитанция
Повтор 1
кадра
.-N(R)-… P/F…1…1…0…1
U-кадры(ненумерованные)
Предназначены для установления и разрыва логического соедиения, а также
информирования об ошибках.
Поле М ненумерованных кадров содержит коды, определяющие тип команд, которыми
пользуются два узла на этапе установления соединения (например, SABME, UA, REST).




Установка режима (SNRM, SNRME, SARM, SARME, SABM, SABME, UA, DM, RIM, SIM, RD, DISC)
Ненумерованная информация (UP, UI)
Восстановление (FRMR, RSET)
o Неверное поле управления
o Превышена длина поля данных
o Неверная длина для данного типа кадров
o Неверный номер кадра
Остальные (XID, TEST)
21)HFC
Есть только в английской вики, поэтому переведена.
http://en.wikipedia.org/wiki/Hybrid_fibre-coaxial
Гибридная волоконно-коаксиальная
Материал из Википедии, свободной энциклопедии
В этой статье не привести любые ссылки или источники.
Пожалуйста, помогите улучшить эту статью, добавив ссылок на достоверные источники. Проверки
могут быть оспаривается и удалена. (Август 2007)
Гибридная волоконно-коаксиальная (HFC) представляет собой термин телекоммуникационной
отрасли для широкополосной сети, которая сочетает в себе оптического волокна и коаксиального
кабеля. Было обычно используются глобально операторами кабельного телевидения с начала
1990-х. См. диаграмму ниже типичной архитектуры для сетей HFC.
Схема сети HFC
Волоконно-оптическую сеть простирается от головной станции мастер кабельных операторов ",
иногда до региональных головных станций, и выходить, чтобы hubsite окрестности, и, наконец, к
волоконно-оптическим узлом, который служит где-то от 25 до 2000 домов. Мастер головной
станции, как правило, спутниковые антенны для приема дальних сигналов видео, а также IPмаршрутизаторы агрегирования. Некоторые мастера головные станции также дом телефонного
оборудования для предоставления телекоммуникационных услуг для общества. Региональных
или района головной станции / хаба приема видеосигнала от мастера головной станции и
добавить к нему общественных, образовательных и правительственных доступа (PEG) каналов
кабельного телевидения в соответствии с местными властями франчайзинга или вставлять
целевой рекламы, что хотел бы обратиться к местным области. Различные услуги кодируются,
модулированные и upconverted на РФ носителей, в сочетании на одной электрического сигнала и
вставляется в широкополосного оптического передатчика. Этот оптический передатчик
преобразует электрический сигнал в течение оптически модулированный сигнал, который
посылается на узлах. Волоконно-оптические кабели подключения головной станции или
концентратора для оптических узлов в точка-точка или звезда топологии, а в некоторых случаях, в
охраняемой топологии кольцо.
Волоконно-оптический узел имеет широкополосный оптический приемник, который преобразует
вниз по течению оптически модулированный сигнал, поступающий от головного узла / хаба
электрический сигнал будет дома. Сегодня, вниз по течению сигнала радио частоты
модулированного сигнала, который обычно начинается в 50 МГц и в диапазоне от 550 МГц до
1000 МГц на верхнем конце. Волоконно-оптический узел также содержит обратный / обратного
канала передатчик, который посылает сообщение из дома обратно в головной станции. В
Северной Америке этот обратный сигнал модулированный радиочастотный от 5 до 42 МГц в то
время как в других частях мира, диапазон от 5 до 65 МГц.
Оптическая часть сети обеспечивает большую степень гибкости. Если Есть не так много волоконнооптических кабелей в узел, спектральным разделением каналов может быть использована для
объединения нескольких оптических сигналов на одном волокне. Оптические фильтры
используются для объединения и раскола оптическом диапазоне на одном волокне. Например,
ниже по течению сигнал может быть на длине волны 1310 нм и на обратный сигнал может быть на
длине волны 1550 нм в. Существуют также методы поставить несколько ниже по течению и вверх
по течению сигналов на одном волокне, поместив их на разных длинах волн.
Коаксиальная часть сети соединяет 25 до 2000 домов (500 типично) в древесно-филиал
конфигурации от узла. Усилители радиочастотные используются с интервалами для преодоления
затухания кабеля и пассивных потерь электрических сигналов, вызванных расщепления или
«поколачивания» коаксиальный кабель. Магистральные кабели коаксиального связаны с
оптическим узлом и форме коаксиального основу которой меньше кабелей распределения
подключения. Магистральные кабели также несут питания переменного тока, которое
добавляется к кабельной линии на как правило, либо 60В или 90В от источника питания и
мощности вставки. Мощность добавляется к кабельной линии так, чтобы ствол и усилителираспределители не нужны личности, внешнего источника питания. Из магистральных кабелей,
кабелей меньшего распределения подключены к порту магистральный усилитель для выполнения
радиосигнала и переменного тока до отдельных улиц. При необходимости линия наполнители,
которые меньше усилителей распределения, повысить сигналы сохранить власть телевизионного
сигнала на таком уровне, что телевизор может принять. Распределение линии, затем "постучал" в
и используются для подключения отдельных капель клиентов дома. Эти краны проходят РФ
сигнала и блок питания переменного тока, если Есть телефонии устройства, которые должны
резервное питание надежность предоставляемых коаксиальный энергосистемы. Кран
прекращается в маленький коаксиальный падение помощью стандартного разъема типа винт
известный как "F" разъем. Падение затем подключен к дому, где земля блок защищает систему от
бродячих напряжения. В зависимости от конструкции сети, сигнал может быть передан через
разветвитель на несколько телевизоров. Если слишком много разветвители используются для
подключения нескольких телевизоров, уровни сигнала будет уменьшаться, и качество
изображения на аналоговых каналов телевизоров мимо тех раскольников войдет, требующих
использования «капля» или «дом» усилителя.
22)HTML
Вы говорите что на HTML невозможно программировать. По-моему вы просто жутко наелись
конфет…(с)Денис попов
HTML (от англ. HyperText Markup Language — «язык разметки гипертекста») —
стандартный язык разметки документов во Всемирной паутине. Большинство веб-страниц
создаются при помощи языка HTML (или XHTML). Язык HTML интерпретируется
браузером и отображается в виде документа, в удобной для человека форме.
HTML является приложением («частным случаем») SGML (стандартного обобщённого
языка разметки) и соответствует международному стандарту ISO 8879. XHTML же
является приложением XML.
Общее представление
Язык HTML был разработан британским учёным Тимом Бернерсом-Ли приблизительно в
1989—1991 годах в стенах Европейского совета по ядерным исследованиям в Женеве
(Швейцария). HTML создавался как язык для обмена научной и технической
документацией, пригодный для использования людьми, не являющимися специалистами в
области вёрстки. HTML успешно справлялся с проблемой сложности SGML путём
определения небольшого набора структурных и семантических элементов —
дескрипторов. Дескрипторы также часто называют «тегами». С помощью HTML можно
легко создать относительно простой, но красиво оформленный документ. Помимо
упрощения структуры документа, в HTML внесена поддержка гипертекста.
Мультимедийные возможности были добавлены позже.
Изначально язык HTML был задуман и создан как средство структурирования и
форматирования документов без их привязки к средствам воспроизведения
(отображения). В идеале, текст с разметкой HTML должен был без стилистических и
структурных искажений воспроизводиться на оборудовании с различной технической
оснащённостью (цветной экран современного компьютера, монохромный экран
органайзера, ограниченный по размерам экран мобильного телефона или устройства и
программы голосового воспроизведения текстов). Однако современное применение
HTML очень далеко от его изначальной задачи. Например, тег <TABLE>, несколько раз
использованный для форматирования страницы, которую вы сейчас читаете, предназначен
для создания в документах самых обычных таблиц, но, как можно убедиться, здесь нет ни
одной таблицы. С течением времени, основная идея платформонезависимости языка
HTML была отдана в своеобразную жертву современным потребностям в
мультимедийном и графическом оформлении.
Браузеры
Текстовые документы, содержащие разметку на языке HTML (такие документы
традиционно имеют расширение .html или .htm), обрабатываются специальными
приложениями, которые отображают документ в его форматированном виде. Такие
приложения, называемые «браузерами» или «интернет-обозревателями», обычно
предоставляют пользователю удобный интерфейс для запроса веб-страниц, их просмотра
(и вывода на иные внешние устройства) и, при необходимости, отправки введённых
пользователем данных на сервер. Наиболее популярными на сегодняшний день
браузерами являются Internet Explorer, Mozilla Firefox, Apple Safari, Google Chrome и
Opera (см.: Браузер#Рыночные доли).
Версии






RFC 1866 — HTML 2.0, одобренный как стандарт 22 сентября 1995 года;
HTML 3.2[1] — 14 января 1997 года;
HTML 4.0[2] — 18 декабря 1997 года;
HTML 4.01[3] (изменения, причём более значительные, чем кажется на первый взгляд) — 24
декабря 1999 года;
ISO/IEC 15445:2000[4] (так называемый ISO HTML, основан на HTML 4.01 Strict) — 15 мая
2000 года.
HTML 5[5] — в разработке. Конец разработки запланирован на 2014 год.
Официальной спецификации HTML 1.0 не существует. До 1995 года существовало
множество неофициальных стандартов HTML. Чтобы стандартная версия отличалась от
них, ей сразу присвоили второй номер.
Версия 3 была предложена Консорциумом всемирной паутины (W3C) в марте 1995 года и
обеспечивала много новых возможностей, таких как создание таблиц, «обтекание»
изображений текстом и отображение сложных математических формул. Даже при том, что
этот стандарт был совместим со второй версией, реализация его была сложна для
браузеров того времени. Версия 3.1 официально никогда не предлагалась, и следующей
версией стандарта HTML стала 3.2, в которой были опущены многие нововведения версии
3.0, но добавлены нестандартные элементы, поддерживаемые браузерами Netscape
Navigator и Mosaic.
В версии HTML версии 4.0 произошла некоторая «очистка» стандарта. Многие элементы
были отмечены как устаревшие и нерекомендованные (англ. deprecated). В частности,
элемент font, используемый для изменения свойств шрифта, был помечен как устаревший
(вместо него рекомендуется использовать таблицы стилей CSS).
В 1998 году консорциум Всемирной паутины начал работу над новым языком разметки,
основанном на HTML 4, но соответствующим синтаксису XML. Впоследствии новый
язык получил название XHTML. Первая версия XHTML 1.0 одобрена в качестве
Рекомендации консорциума Всемирной паутины 26 января 2000 года.
Планируемая версия XHTML 2.0 должна была разорвать совместимость со старыми
версиями HTML и XHTML, но 2 июля 2009 года консорциум Всемирной паутины
объявил, что полномочия рабочей группы XHTML2 истекают в конце 2009 года. Таким
образом, была приостановлена вся дальнейшая разработка стандарта XHTML 2.0[6].
Перспективы
В настоящее время Консорциум всемирной паутины разрабатывает HTML версии 5.
Черновой вариант спецификации языка появился в Интернете 20 ноября 2007 года.
Сообществом WHATWG (англ. Web Hypertext Application Technology Working Group),
начиная с 2004 года, разрабатывается спецификация Web Applications 1.0, часто
неофициально называемая «HTML 5», которая расширяет HTML (впрочем, имея и
совместимый с XHTML 1.0 XML-синтаксис) для лучшего представления семантики
различных типичных страниц, например форумов, сайтов аукционов, поисковых систем,
онлайн-магазинов и т. д., которые не очень удачно вписываются в модель XHTML 2.
Структура HTML-документа
HTML — теговый язык разметки документов. Любой документ на языке HTML
представляет собой набор элементов, причём начало и конец каждого элемента
обозначается специальными пометками — тегами. Элементы могут быть пустыми, то
есть не содержащими никакого текста и других данных (например, тег перевода строки
<br>). В этом случае обычно не указывается закрывающий тег. Кроме того, элементы
могут иметь атрибуты, определяющие какие-либо их свойства (например, размер шрифта
для элемента font). Атрибуты указываются в открывающем теге. Вот примеры
фрагментов HTML-документа:



<strong>Текст между двумя тегами — открывающим и закрывающим.</strong>
<a href="http://www.example.com">Здесь элемент содержит атрибут
href.</a>
А вот пример пустого элемента: <br>
Регистр, в котором набрано имя элемента и имена атрибутов, в HTML значения не имеет
(в отличие от XHTML). Элементы могут быть вложенными. Например, следующий код:
<b>
Этот текст будет полужирным,
<i>а этот - ещё и курсивным</i>
</b>
даст такой результат:
Этот текст будет полужирным, а этот - ещё и курсивным
Кроме элементов, в HTML-документах есть и сущности (англ. entities) — «специальные
символы». Сущности начинаются с символа амперсанда и имеют вид &имя; или &#NNNN;,
где NNNN — код символа в Юникоде в десятеричной системе счисления.
Например, © — знак авторского права (©). Как правило, сущности используются для
представления символов, отсутствующих в кодировке документа, или же для
представления «специальных» символов: & — амперсанда (&), < — символа
«меньше» (<) и > — символа «больше» (>), которые некорректно записывать
«обычным» образом, из-за их особого значения в HTML.
Подробнее по этой теме см.: Элементы HTML.
Подробнее по этой теме см.: Википедия:Специальные символы.
Каждый HTML-документ, отвечающий спецификации HTML какой-либо версии, должен
начинаться со строки объявления версии HTML <!DOCTYPE…>, которая обычно выглядит
примерно так:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
Если эта строка не указана, то добиться корректного отображения документа в браузере
становится труднее.
Далее обозначается начало и конец документа тегами <html> и </html> соответственно.
Внутри этих тегов должны находиться теги заголовка (<head></head>) и тела
(<body></body>) документа.
Варианты DOCTYPE для HTML 4.01

Строгий (Strict): не содержит элементов, помеченных как «устаревшие» или «не
одобряемые» (deprecated).
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">

Переходный (Transitional): содержит устаревшие теги в целях совместимости и упрощения
перехода со старых версий HTML.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">

С фреймами (Frameset): аналогичен переходному, но содержит также теги для создания
наборов фреймов.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
"http://www.w3.org/TR/html4/frameset.dtd">
Варианты DOCTYPE для HTML 5
В HTML 5 используется только один вариант DOCTYPE:
<!DOCTYPE HTML>
Браузерные войны
Основная статья: Война браузеров
В середине 1990-х годов основные производители браузеров — компании Netscape и
Microsoft — начали внедрять собственные наборы элементов в HTML-разметку.
Создалась путаница из различных конструкций для работы во Всемирной паутине,
доступных для просмотра то в одном, то в другом браузере. Особенно большие трудности
были при создании кросс-браузерных программ на языке JavaScript. Веб-мастерам
приходилось создавать несколько вариантов страниц или прибегать к другим
ухищрениям. На какое-то время проблема потеряла актуальность по двум причинам:


Из-за вытеснения браузером Internet Explorer всех остальных браузеров. Соответственно,
проблема веб-мастеров становилась проблемой пользователей альтернативных
браузеров.
Благодаря усилиям производителей других браузеров, которые либо следовали
стандартам W3C (как Mozilla и Opera), либо пытались создать максимальную
совместимость с Internet Explorer.
На современном этапе можно констатировать рост популярности браузеров, следующих
рекомендациям W3C (это Mozilla Firefox и другие браузеры на движке Gecko; Safari,
Google Chrome и другие браузеры на движке WebKit; Opera с движком Presto). Доля
Internet Explorer на данный момент составляет менее 50 %.
В современной практике существует возможность упростить разработку кроссбраузерных программ на языке JavaScript, с помощью различных библиотек и
фреймворков. Например таких как jQuery.
23)HTTP
HTTP (сокр. от англ. HyperText Transfer Protocol — «протокол передачи гипертекста») —
протокол прикладного уровня передачи данных (изначально — в виде гипертекстовых
документов). Основой HTTP является технология «клиент-сервер», то есть предполагается
существование потребителей (клиентов), которые инициируют соединение и посылают
запрос, и поставщиков (серверов), которые ожидают соединения для получения запроса,
производят необходимые действия и возвращают обратно сообщение с результатом. HTTP
в настоящее время повсеместно используется во Всемирной паутине для получения
информации с веб-сайтов. В 2006 году в Северной Америке доля HTTP-трафика
превысила долю P2P-сетей и составила 46 %, из которых почти половина — это передача
потокового видео и звука[1].
HTTP используется также в качестве «транспорта» для других протоколов прикладного
уровня, таких как SOAP, XML-RPC, WebDAV.
Основным объектом манипуляции в HTTP является ресурс, на который указывает URI
(англ. Uniform Resource Identifier) в запросе клиента. Обычно такими ресурсами являются
хранящиеся на сервере файлы, но ими могут быть логические объекты или что-то
абстрактное. Особенностью протокола HTTP является возможность указать в запросе и
ответе способ представления одного и того же ресурса по различным параметрам:
формату, кодировке, языку и т. д. Именно благодаря возможности указания способа
кодирования сообщения клиент и сервер могут обмениваться двоичными данными, хотя
данный протокол является текстовым.
HTTP — протокол прикладного уровня, аналогичными ему являются FTP и SMTP. Обмен
сообщениями идёт по обыкновенной схеме «запрос-ответ». Для идентификации ресурсов
HTTP использует глобальные URI. В отличие от многих других протоколов, HTTP не
сохраняет своего состояния. Это означает отсутствие сохранения промежуточного
состояния между парами «запрос-ответ». Компоненты, использующие HTTP, могут
самостоятельно осуществлять сохранение информации о состоянии, связанной с
последними запросами и ответами. Браузер, посылающий запросы, может отслеживать
задержки ответов. Сервер может хранить IP-адреса и заголовки запросов последних
клиентов. Однако сам протокол не осведомлён о предыдущих запросах и ответах, в нём не
предусмотрена внутренняя поддержка состояния, к нему не предъявляются такие
требования.
Преимущества
Простота
Протокол настолько прост в реализации, что позволяет с лёгкостью создавать клиентские
приложения.
Расширяемость
Возможности протокола легко расширяются благодаря внедрению своих собственных
заголовков, с помощью которых можно получить необходимую функциональность при
решении специфической задачи. При этом сохраняется совместимость с другими
клиентами и серверами: они будут просто игнорировать неизвестные им заголовки.
Распространённость
При выборе протокола HTTP для решения конкретных задач немаловажным фактором
является его распространённость. Как следствие, это обилие различной документации по
протоколу на многих языках мира, включение удобных в использовании средств
разработки в популярные IDE, поддержка протокола в качестве клиента многими
программами и обширный выбор среди хостинговых компаний с серверами HTTP.
Недостатки и проблемы
Большой размер сообщений
Использование текстового формата в протоколе порождает соответствующий недостаток:
большой размер сообщений по сравнению с передачей двоичных данных. Из-за этого
возрастает нагрузка на оборудование при формировании, обработке и передаче
сообщений. Для решения данной проблемы в протокол встроены средства для
обеспечения кэширования на стороне клиента, а также средства компрессии
передаваемого контента. Нормативными документами по протоколу предусмотрено
наличие прокси-серверов, которые позволяют получить клиенту документ с наиболее
близкого к нему сервера. Также в протокол было внедрено diff-кодирование, чтобы
клиенту передавался не весь документ, а только его изменённая часть.
Отсутствие «навигации»
Хотя протокол разрабатывался как средство работы с ресурсами сервера, у него
отсутствуют в явном виде средства навигации среди этих ресурсов. Например, клиент не
может явным образом запросить список доступных файлов, как в протоколе FTP.
Предполагалось, что конечный пользователь уже знает URI необходимого ему документа,
закачав который, он будет производить навигацию благодаря гиперссылкам. Это вполне
нормально и удобно для человека, но затруднительно, когда стоят задачи автоматической
обработки и анализа всех ресурсов сервера без участия человека. Решение этой проблемы
лежит полностью на плечах разработчиков приложений, использующих данный протокол.
Например, со стороны клиента используются веб-пауки — специальные программы,
которые составляют список ресурсов сервера, проходя по всем найденным гиперссылкам.
Со стороны сервера данная проблема решается с помощью карты сайта (англ. site map) —
специальной веб-страницы, где перечислены все доступные для посещения ресурсы. Она
предназначена не только для людей, играя аналогичную содержанию в книге роль, но и
полезна для тех же роботов-пауков, т.к. позволет уменьшить глубину — минимальное
необходимое количество переходов с главной страницы. Для тех же целей служат файлы
формата Sitemap, которые предназначены уже непосредственно для роботов.
Полностью эта проблема решена в расширяющем HTTP протоколе WebDAV с помощью
добавленного метода PROPFIND. Данный метод позволяет не только получить дерево
каталогов, но и список параметров каждого ресурса.
Нет поддержки распределённости
Протокол HTTP разрабатывался для решения типичных бытовых задач, где само по себе
время обработки запроса должно занимать незначительное время или вообще не
приниматься в расчёт. Но в промышленном использовании с применением
распределённых вычислений при высоких нагрузках на сервер протокол HTTP
оказывается беспомощен. В 1998 году W3C предложил альтернативный протокол HTTPNG (англ. HTTP Next Generation) для полной замены устаревшего с акцентированием
внимания именно на этой области[2]. Идею его необходимости поддержали крупные
специалисты по распределённым вычислениям, но данный протокол до сих пор находится
на стадии разработки.
Программное обеспечение
Всё программное обеспечение для работы с протоколом HTTP разделяется на три
большие категории:



Серверы как основные поставщики услуг хранения и обработки информации (обработка
запросов).
Клиенты — конечные потребители услуг сервера (отправка запроса).
Прокси для выполнения транспортных служб.
Для отличия конечных серверов от прокси в официальной документации используется
термин origin server (рус. исходный сервер). Разумеется, один и тот же программный
продукт может одновременно выполнять функции клиента, сервера или посредника в
зависимости от поставленных задач. В спецификациях протокола HTTP подробно
описывается поведение для каждой из этих ролей.
Клиенты
Первоначально протокол HTTP разрабатывался для доступа к гипертекстовым
документам Всемирной паутины. Поэтому основными реализациями клиентов являются
браузеры (агенты пользователя). Популярные браузеры (в алфавитном порядке):
Epiphany, Google Chrome, Internet Explorer, Konqueror, Mozilla Firefox, Opera, Safari.
См также: Список браузеров и Сравнение браузеров
Для просмотра сохраненного содержимого сайтов на компьютере без соединения с
Интернетом были придуманы оффлайн-браузеры. Среди известных HTTrack и Offline
Explorer.
При нестабильном соединении для загрузки больших файлов используются менеджеры
закачек. Они позволяют в любое время докачать указанные файлы после потери
соединения с веб-сервером. В ОС Windows популярны программы Download Master,
FlashGet, Free Download Manager, GetRight, ReGet. В Linux — графический менеджер
закачек KGet и d4x (Downloader For X). Многие пользователи Linux предпочитают
использование Wget — программы для загрузки файлов, которая сама по себе не является
менеджером закачек.
Виртуальные атласы, такие как Google Планета Земля и NASA World Wind, тоже
используют HTTP.
Нередко протокол HTTP используется программами для скачивания обновлений.
Целый комплекс программ-роботов используется в поисковых системах Интернета. Среди
них веб-пауки (краулеры), которые производят проход по гиперссылкам, составляют базу
данных ресурсов серверов и сохраняют их содержимое для дальнейшего анализа.
См. также: Список поисковых машин, Архив Интернета
Исходные серверы
Основные реализации: Apache, Internet Information Services (IIS), lighttpd, nginx.
См. также: Список веб-серверов
Прокси-серверы
Основные реализации: Squid, UserGate, Multiproxy, Naviscope, Nginx.
См. также: Список веб-серверов
История развития
HTTP/0.9
HTTP был предложен в марте 1991 года Тимом Бернерсом-Ли, работавшим тогда в CERN,
как механизм для доступа к документам в Интернете и облегчения навигации посредством
использования гипертекста. Самая ранняя версия протокола HTTP/0.9 была впервые
опубликована в январе 1992 г. (хотя реализация датируется 1990 годом). Спецификация
протокола привела к упорядочению правил взаимодействия между клиентами и серверами
HTTP, а также чёткому разделению функций между этими двумя компонентами. Были
задокументированы основные синтаксические и семантические положения.
HTTP/1.0
В мае 1996 года для практической реализации HTTP был выпущен информационный
документ RFC 1945, что послужило основой для реализации большинства компонентов
HTTP/1.0.
HTTP/1.1
Текущая версия протокола, принята в июне 1999 года[прим 1]. Новым в этой версии был
режим «постоянного соединения»: TCP-соединение может оставаться открытым после
отправки ответа на запрос, что позволяет посылать несколько запросов за одно
соединение. Клиент теперь обязан посылать информацию об имени хоста, к которому он
обращается, что сделало возможной более простую организацию виртуального хостинга.
HTTP/1.2
Первоначально 1995 работая проектов документа PEP - механизм выдвижения для HTTP
(предложил протокол выдвижения протокола, сокращенный PEP) подготовил Консорциум
world wide web и представлено к Internet engineering task force. PEP первоначально был
предназначен стать различая характеристикой HTTP/1.2.[4] В более поздно Проекты PEP
работая, однако, справка к HTTP/1.2 извлеклась. Экспериментально RFC 2774, Рамки
выдвижения HTTP, больше subsumed PEP. Оно было опубликовано в феврале 2000.
Структура протокола
Каждое HTTP-сообщение состоит из трёх частей, которые передаются в указанном
порядке:
1. Стартовая строка (англ. Starting line) — определяет тип сообщения;
2. Заголовки (англ. Headers) — характеризуют тело сообщения, параметры передачи и
прочие сведения;
3. Тело сообщения (англ. Message Body) — непосредственно данные сообщения.
Обязательно должно отделяться от заголовков пустой строкой.
Заголовки и тело сообщения могут отсутствовать, но стартовая строка является
обязательным элементом, так как указывает на тип запроса/ответа. Исключением является
версия 0.9 протокола, у которой сообщение запроса содержит только стартовую строку, а
сообщения ответа только тело сообщения.
Стартовая строка
Стартовые строки различаются для запроса и ответа. Строка запроса выглядит так:
GET URI — для версии протокола 0.9.
Метод URI HTTP/Версия — для остальных версий.
Здесь:



Метод (англ. Method) — название запроса, одно слово заглавными буквами. В версии
HTTP 0.9 использовался только метод GET, список запросов для версии 1.1 представлен
ниже.
URI определяет путь к запрашиваемому документу.
Версия (англ. Version) — пара разделённых точкой арабских цифр. Например: 1.0.
Чтобы запросить страницу данной статьи, клиент должен передать строку:
GET /wiki/HTTP HTTP/1.0
Стартовая строка ответа сервера имеет следующий формат:
HTTP/Версия КодСостояния Пояснение
Здесь:



Версия — пара разделённых точкой арабских цифр как в запросе.
КодСостояния (англ. Status Code) — три арабские цифры. По коду статуса определяется
дальнейшее содержимое сообщения и поведение клиента.
Пояснение (англ. Reason Phrase) — текстовое короткое пояснение к коду ответа для
пользователя. Никак не влияет на сообщение и является необязательным.
Например, на предыдущий наш запрос клиентом данной страницы сервер ответил
строкой:
HTTP/1.0 200 OK
Методы
Метод HTTP (англ. HTTP Method) — последовательность из любых символов, кроме
управляющих и разделителей, указывающая на основную операцию над ресурсом.
Обычно метод представляет собой короткое английское слово, записанное заглавными
буквами. Обратите внимание, что название метода чувствительно к регистру.
Каждый сервер обязан поддерживать как минимум методы GET и HEAD. Если сервер не
распознал указанный клиентом метод, то он должен вернуть статус 501 (Not Implemented).
Если серверу метод известен, но он не применим к конкретному ресурсу, то возвращается
сообщение с кодом 405 (Method Not Allowed). В обоих случаях серверу следует включить
в сообщение ответа заголовок Allow со списком поддерживаемых методов.
Кроме методов GET и HEAD, часто применяется метод POST.
OPTIONS
Используется для определения возможностей веб-сервера или параметров соединения для
конкретного ресурса. В ответ серверу следует включить заголовок Allow со списком
поддерживаемых методов. Также в заголовки ответа может включаться информация о
поддерживаемых расширениях.
Предполагается, что запрос клиента может содержать тело сообщения для указания
интересующих его сведений. Формат тела и порядок работы с ним в настоящий момент не
определён. Сервер пока должен его игнорировать. Аналогичная ситуация и с телом в
ответе сервера.
Для того чтобы узнать возможности всего сервера, клиент должен указать в URI
звёздочку — «* ». Запросы «OPTIONS * HTTP/1.1 » могут также применяться для проверки
работоспособности сервера (аналогично «пингованию») и тестирования на предмет
поддержки сервером протокола HTTP версии 1.1.
Результат выполнения этого метода не кэшируется.
GET
Используется для запроса содержимого указанного ресурса. С помощью метода GET
можно также начать какой-либо процесс. В этом случае в тело ответного сообщения
следует включить информацию о ходе выполнения процесса.
Клиент может передавать параметры выполнения запроса в URI целевого ресурса после
символа «? »:
GET /path/resource?param1=value1&param2=value2 HTTP/1.1
Согласно стандарту HTTP, запросы типа GET считаются идемпотентными[3] —
многократное повторение одного и того же запроса GET должно приводить к одинаковым
результатам (при условии, что сам ресурс не изменился за время между запросами). Это
позволяет кэшировать ответы на запросы GET.
Кроме обычного метода GET, различают ещё условный GET и частичный GET. Условные
запросы GET содержат заголовки If-Modified-Since, If-Match, If-Range и подобные.
Частичные GET содержат в запросе Range. Порядок выполнения подобных запросов
определён стандартами отдельно.
HEAD
Аналогичен методу GET, за исключением того, что в ответе сервера отсутствует тело.
Запрос HEAD обычно применяется для извлечения метаданных, проверки наличия ресурса
(валидация URL) и чтобы узнать, не изменился ли он с момента последнего обращения.
Заголовки ответа могут кэшироваться. При несовпадении метаданных ресурса с
соответствующей информацией в кэше копия ресурса помечается как устаревшая.
POST
Применяется для передачи пользовательских данных заданному ресурсу. Например, в
блогах посетители обычно могут вводить свои комментарии к записям в HTML-форму,
после чего они передаются серверу методом POST и он помещает их на страницу. При
этом передаваемые данные (в примере с блогами — текст комментария) включаются в
тело запроса. Аналогично с помощью метода POST обычно загружаются файлы на сервер.
В отличие от метода GET, метод POST не считается идемпотентным[3], то есть многократное
повторение одних и тех же запросов POST может возвращать разные результаты
(например, после каждой отправки комментария будет появляться одна копия этого
комментария).
При результатах выполнения 200 (Ok) и 204 (No Content) в тело ответа следует включить
сообщение об итоге выполнения запроса. Если был создан ресурс, то серверу следует
вернуть ответ 201 (Created) с указанием URI нового ресурса в заголовке Location.
Сообщение ответа сервера на выполнение метода POST не кэшируется.
PUT
Применяется для загрузки содержимого запроса на указанный в запросе URI. Если по
заданному URI не существовало ресурса, то сервер создаёт его и возвращает статус 201
(Created). Если же был изменён ресурс, то сервер возвращает 200 (Ok) или 204 (No
Content). Сервер не должен игнорировать некорректные заголовки Content-*
передаваемые клиентом вместе с сообщением. Если какой-то из этих заголовков не может
быть распознан или не допустим при текущих условиях, то необходимо вернуть код
ошибки 501 (Not Implemented).
Фундаментальное различие методов POST и PUT заключается в понимании предназначений
URI ресурсов. Метод POST предполагает, что по указанному URI будет производиться
обработка передаваемого клиентом содержимого. Используя PUT, клиент предполагает,
что загружаемое содержимое соответствует находящемуся по данному URI ресурсу.
Сообщения ответов сервера на метод PUT не кэшируются.
PATCH
Аналогично PUT, но применяется только к фрагменту ресурса.
DELETE
Удаляет указанный ресурс.
TRACE
Возвращает полученный запрос так, что клиент может увидеть, какую информацию
промежуточные серверы добавляют или изменяют в запросе.
LINK
Устанавливает связь указанного ресурса с другими.
UNLINK
Убирает связь указанного ресурса с другими.
CONNECT
Преобразует соединение запроса в прозрачный TCP/IP туннель, обычно чтобы
содействовать установлению защищенному SSL соединению через не шифрованный
прокси.
Коды состояния
Основная статья: Список кодов состояния HTTP
Код состояния является частью первой строки ответа сервера. Он представляет собой
целое число из трех арабских цифр[4]. Первая цифра указывает на класс состояния. За
кодом ответа обычно следует отделённая пробелом поясняющая фраза на английском
языке, которая разъясняет человеку причину именно такого ответа. Примеры:
201 Webpage Created
403 Access allowed only for registered users
507 Insufficient Storage
Клиент узнаёт по коду ответа о результатах его запроса и определяет, какие действия ему
предпринимать дальше. Набор кодов состояния является стандартом, и они описаны в
соответствующих документах RFC. Введение новых кодов должно производиться только
после согласования с IETF. Клиент может не знать все коды состояния, но он обязан
отреагировать в соответствии с классом кода.
В настоящее время выделено пять классов кодов состояния.
1xx Informational (рус. Информационный)
В этот класс выделены коды, информирующие о процессе передачи. В HTTP/1.0
сообщения с такими кодами должны игнорироваться. В HTTP/1.1 клиент должен быть
готов принять этот класс сообщений как обычный ответ, но ничего отправлять серверу не
нужно. Сами сообщения от сервера содержат только стартовую строку ответа и, если
требуется, несколько специфичных для ответа полей заголовка. Прокси-серверы подобные
сообщения должны отправлять дальше от сервера к клиенту.
2xx Success (рус. Успешно)
Сообщения данного класса информируют о случаях успешного принятия и обработки
запроса клиента. В зависимости от статуса сервер может ещё передать заголовки и тело
сообщения.
3xx Redirection (рус. Перенаправление)
Коды класса 3xx сообщают клиенту что для успешного выполнения операции необходимо
сделать другой запрос (как правило по другому URI). Из данного класса пять кодов 301,
302, 303, 305 и 307 относятся непосредственно к перенаправлениям (жарг. редирект).
Адрес, по которому клиенту следует произвести запрос, сервер указывает в заголовке
Location. При этом допускается использование фрагментов в целевом URI.
4xx Client Error (рус. Ошибка клиента)
Класс кодов 4xx предназначен для указания ошибок со стороны клиента. При
использовании всех методов, кроме HEAD, сервер должен вернуть в теле сообщения
гипертекстовое пояснение для пользователя.
Для запоминания значений кодов с 400 по 417 существуют приёмы иллюстративной
мнемотехники[5]
5xx Server Error (рус. Ошибка сервера)
Коды 5xx выделены под случаи неудачного выполнения операции по вине сервера. Для
всех ситуаций, кроме использования метода HEAD, сервер должен включать в тело
сообщения объяснение, которое клиент отобразит пользователю.
Заголовки
Основные статьи: Заголовки HTTP, Список заголовков HTTP
Заголовки HTTP (англ. HTTP Headers) — это строки в HTTP-сообщении, содержащие
разделённую двоеточием пару параметр-значение. Формат заголовков соответствует
общему формату заголовков текстовых сетевых сообщений ARPA (см. RFC 822).
Заголовки должны отделяться от тела сообщения хотя бы одной пустой строкой.
Примеры заголовков:
Server: Apache/2.2.11 (Win32) PHP/5.3.0
Last-Modified: Sat, 16 Jan 2010 21:16:42 GMT
Content-Type: text/plain; charset=windows-1251
Content-Language: ru
В примере выше каждая строка представляет собой один заголовок. При этом то, что
находится до первого двоеточия, называется именем (англ. name), а что после неё —
значением (англ. value).
Все заголовки разделяются на четыре основных группы:
1. General Headers (рус. Основные заголовки) — должны включаться в любое сообщение
клиента и сервера.
2. Request Headers (рус. Заголовки запроса) — используются только в запросах клиента.
3. Response Headers (рус. Заголовки ответа) — только для ответов от сервера.
4. Entity Headers (рус. Заголовки сущности) — сопровождают каждую сущность сообщения.
Именно в таком порядке рекомендуется посылать заголовки получателю.
Все необходимые для функционирования HTTP заголовки описаны в основных RFC,
ссылки на которые есть в конце этой статьи. При этом если вам не будет хватать
существующих, то можете смело вводить свои. Традиционно к именам таких
дополнительных заголовков добавляют префикс «X-» для избежания конфликта имён с
возможно существующими. Например, как в заголовках X-Powered-By или X-Cache.
Некоторые разработчики используют свои индивидуальные префиксы. Примерами таких
заголовков могут служить Ms-Echo-Request и Ms-Echo-Reply, введённые корпорацией
Microsoft для расширения WebDAV.
Тело сообщения
Этот раздел статьи ещё не написан.
Согласно замыслу одного из участников Википедии, на этом месте должен располагаться
специальный раздел.
Вы можете помочь проекту, написав этот раздел.
Тело HTTP сообщения (message-body), если оно присутствует, используется для передачи
тела объекта, связанного с запросом или ответом. Тело сообщения (message-body)
отличается от тела объекта (entity-body) только в том случае, когда применяется
кодирование передачи, что указывается полем заголовка Transfer-Encoding.
message-body = entity-body
| <entity-body закодированно согласно
Transfer-Encoding>
Поле Transfer-Encoding ДОЛЖНО использоваться для указания любого кодирования
передачи, примененного приложением в целях гарантирования безопасной и правильной
передачи сообщения. Поле Transfer-Encoding - это свойство сообщения, а не объекта, и,
таким образом, может быть добавлено или удалено любым приложением в цепочке
запросов/ответов.
Правила, устанавливающие допустимость тела сообщения в сообщении, отличны для
запросов и ответов.
Присутствие тела сообщения в запросе отмечается добавлением к заголовкам запроса
поля заголовка Content-Length или Transfer-Encoding. Тело сообщения (message-body)
МОЖЕТ быть добавлено в запрос только когда метод запроса допускает тело объекта
(entity-body) .
Включается или не включается тело сообщения (message-body) в сообщение ответа
зависит как от метода запроса, так и от кода состояния ответа. Все ответы на запрос с
методом HEAD НЕ ДОЛЖНЫ включать тело сообщения (message-body), даже если
присутствуют поля заголовка объекта (entity-header), заставляющие поверить в
присутствие объекта. Никакие ответы с кодами состояния 1xx (Информационные), 204
(Нет содержимого, No Content), и 304 (Не модифицирован, Not Modified) НЕ ДОЛЖНЫ
содержать тела сообщения (message-body). Все другие ответы содержат тело сообщения,
даже если оно имеет нулевую длину.
Примеры диалогов HTTP
Обычный GET-запрос
Запрос клиента:
GET /wiki/страница HTTP/1.1
Host: ru.wikipedia.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9b5) Gecko/2008050509
Firefox/3.0b5
Accept: text/html
Connection: close
(пустая строка)
Ответ сервера:
HTTP/1.0 200 OK
Date: Wed, 11 Feb 2009 11:20:59 GMT
Server: Apache
X-Powered-By: PHP/5.2.4-2ubuntu5wm1
Last-Modified: Wed, 11 Feb 2009 11:20:59 GMT
Content-Language: ru
Content-Type: text/html; charset=utf-8
Content-Length: 1234
Connection: close
(далее следует запрошенная страница в HTML)
Аналогично выглядит ответ 203. Что существенно, непосредственно запрашиваемые
данные отделены от HTTP-заголовков с помощью CRLF CRLF (двух переводов строки).
Перенаправления
Предположим, что у вымышленной компании Example Corp. есть основной сайт по адресу
http://example.com и домен-псевдоним example.org. Клиент посылает запрос страницы «О
компании» на вторичный домен (часть заголовков опущена):
GET /about.html HTTP/1.1
Host: example.org
User-Agent: MyLonelyBrowser/5.0
Так как домен example.org не является основным и компания не собирается в будущем его
использовать в других целях, их сервер вернёт код для постоянного перенаправления,
указав в заголовке Location целевой URI:
HTTP/1.x 301 Moved Permanently
Location: http://example.com/about.html#contacts
Date: Thu, 19 Feb 2009 11:08:01 GMT
Server: Apache/2.2.4
Content-Type: text/html; charset=windows-1251
Content-Length: 110
(пустая строка)
<html><body><a href="http://example.com/about.html#contacts">Click
here</a></body></html>
В заголовке Location можно указывать фрагменты как в данном примере. Браузер не
указал фрагмент в запросе, так как его интересует весь документ. Но он автоматически
прокрутит страницу до фрагмента «contacts», как только загрузит её. В тело ответа также
был помещён коротенький HTML-документ с ссылкой, с помощью которой посетитель
попадёт на целевую страницу, если браузер не перейдёт на неё автоматически. Заголовок
Content-Type содержит характеристики именно этого HTML-пояснения, а не документа,
который находится по целевому URL.
Допустим, эта же компания Example Corp. имеет несколько региональных
представительств по всему миру. И для каждого представительства у них есть сайт с
соответствующим ccTLD. Запрос главной страницы основного сайта example.com может
выглядеть так:
GET / HTTP/1.1
Host: example.com
User-Agent: MyLonelyBrowser/5.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ru,en-us;q=0.7,en;q=0.3
Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7
Сервер принял во внимание заголовок Accept-Language и сформировал ответ с
временным перенаправлением на российский сервер test.ru, указав его адрес в заголовке
Location:
HTTP/1.x 302 Found
Location: http://test.ru/
Cache-Control: private
Date: Thu, 19 Feb 2009 11:08:01 GMT
Server: Apache/2.2.6
Content-Type: text/html; charset=windows-1251
Content-Length: 82
(пустая строка)
<html><body><a href="http://test.ru">Example Corp. Россия</a></body></html>
Обратите внимание на заголовок Cache-Control. Значение «private» сообщает остальным
серверам (в первую очередь прокси) что ответ может кэшироваться на стороне клиента. В
противном случае не исключено, что следующие посетители из других стран будут
переходить всё время не в своё представительство.
Для перенаправления также используются коды ответа 303 (See Other) и 307 (Temporary
Redirect).
Докачка и фрагментарное скачивание
Допустим, вымышленная организация предлагает скачать с сайта видео прошедшей
конференции по адресу http://example.org/conf-2009.avi объёмом примерно 160 МБ.
Рассмотрим, как происходит докачивание этого файла в случае сбоя и как менеджер
закачек организовал бы многопоточную загрузку нескольких фрагментов.
В обоих случаях клиенты произведут свой первый запрос наподобие этого:
GET /conf-2009.avi HTTP/1.0
Host: example.org
Accept: */*
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98)
Referer: http://example.org/
Заголовок Referer указывает, что файл был запрошен с главной страницы сайта.
Менеджеры закачек обычно тоже его указывают, чтобы эмулировать переход со страницы
сайта. Без него сервер может ответить 403 (Access Forbidden), если не допускаются
запросы с других сайтов. В нашем случае сервер вернул успешный ответ:
HTTP/1.1 200 OK
Date: Thu, 19 Feb 2009 12:27:04 GMT
Server: Apache/2.2.3
Last-Modified: Wed, 18 Jun 2003 16:05:58 GMT
ETag: "56d-9989200-1132c580"
Content-Type: video/x-msvideo
Content-Length: 160993792
Accept-Ranges: bytes
Connection: close
(пустая строка)
(двоичное содержимое всего файла)
Заголовок Accept-Ranges информирует клиента о том, что он может запрашивать у
сервера фрагменты, указывая их смещения от начала файла в байтах. Если этот заголовок
отсутствует, то клиент может предупредить пользователя, что докачать файл, скорее
всего, не удастся. Исходя из значения заголовка Content-Length, менеджер закачек
поделит весь объём на равные фрагменты и запросит их по отдельности, организовав
несколько потоков. Если сервер не укажет размер, то клиенту параллельное скачивание
реализовать не удастся, но при этом он сможет докачивать файл, пока сервер не ответит
416 (Requested Range Not Satisfiable).
Допустим, на 84-ом мегабайте соединение с Интернетом прервалось и процесс загрузки
приостановился. Когда соединение с Интернетом было восстановлено, менеджер закачек
автоматически послал новый запрос на сервер, но с указанием выдать содержимое с 84ого мегабайта:
GET /conf-2009.avi HTTP/1.0
Host: example.org
Accept: */*
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98)
Range: bytes=88080384Referer: http://example.org/
Сервер не обязан помнить, какие и от кого запросы были до этого, и поэтому клиент снова
вставил заголовок Referer, как будто это его самый первый запрос. Указанное значение
заголовка Range говорит серверу — «выдай содержимое от 88080384-ого байта до самого
конца». В связи с этим сервер вернёт ответ:
HTTP/1.1 206 Partial Content
Date: Thu, 19 Feb 2009 12:27:08 GMT
Server: Apache/2.2.3
Last-Modified: Wed, 18 Jun 2003 16:05:58 GMT
ETag: "56d-9989200-1132c580"
Accept-Ranges: bytes
Content-Range: bytes 88080384-160993791/160993792
Content-Length: 72913408
Connection: close
Content-Type: video/x-msvideo
(пустая строка)
(двоичное содержимое от 84-ого мегабайта)
Заголовок Accept-Ranges здесь уже не обязателен, так как клиент уже знает об этой
возможности сервера. О том, что передаётся фрагмент, клиент узнаёт по коду 206 (Partial
Content). В заголовке Content-Range содержится информация о данном фрагменте:
номера начального и конечного байта, а после слэша — суммарный объём всего файла в
байтах. Обратите внимание на заголовок Content-Length — в нём указывается размер
тела сообщения, то есть передаваемого фрагмента. Если сервер вернёт несколько
фрагментов, то Content-Length будет содержать их суммарный объём.
Теперь вернёмся к менеджеру закачек. Зная суммарный объём файла «conf-2009.avi»,
программа поделила его на 10 равных секций. Начальную менеджер загрузит при самом
первом запросе, прервав соединение как только дойдёт до начала второго. Остальные он
запросит отдельно. Например, 4-я секция будет запрошена со следующими заголовками
(часть заголовков опущена — см. полный пример выше):
GET /conf-2009.avi HTTP/1.0
Range: bytes=64397516-80496894
Ответ сервера в этом случае будет следующим (часть заголовков опущена — см. полный
пример выше):
HTTP/1.1 206 Partial Content
Accept-Ranges: bytes
Content-Range: bytes 64397516-80496894/160993792
Content-Length: 16099379
(пустая строка)
(двоичное содержимое 4-ой части)
Если подобный запрос отправить серверу, который не поддерживает фрагменты, то он
вернёт стандартный ответ 200 (OK) как было показано в самом начале, но без заголовка
Accept-Ranges.
См. также частичные GET, байтовые диапазоны, ответ 206, ответ 416.
Основные механизмы протокола
Частичные GET
HTTP позволяет запросить не сразу всё содержимое ресурса, а только указанный
фрагмент. Такие запросы называются частичные GET, возможность их выполнения
необязательна (но желательна) для серверов. Частичные GET в основном используются для
докачки файлов и быстрого параллельного скачивания в нескольких потоках. Некоторые
программы скачивают заголовок архива, выводят пользователю внутреннюю структуру, а
потом уже запрашивают фрагменты с указанными элементами архива.
Для получения фрагмента клиент посылает серверу запрос с заголовком Range, указывая в
нём необходимые байтовые диапазоны. Если сервер не понимает частичные запросы
(игнорирует заголовок Range), то он вернёт всё содержимое со статусом 200, как и при
обычном GET. В случае успешного выполнения сервер возвращает вместо кода 200 ответ
со статусом 206 (Partial Content), включая в ответ заголовок Content-Range. Сами
фрагменты могут быть переданы двумя способами:


В ответе помещается заголовок Content-Range с указанием байтовых диапазонов. В
соответствии с ними фрагменты последовательно помещаются в основное тело. При этом
Content-Length должен соответствовать суммарному объёму всего тела.
Сервер указывает медиа тип multipart/byteranges для основного содержимого и
передаёт фрагменты указывая соответствующий Content-Range для каждого элемента
(см. также Множественное содержимое).
См. также пример диалога докачки и фрагментарного скачивания.
Условные GET
Метод GET изменяется на "условный GET", если сообщение запроса включает в себя поле
заголовка "If-Modified-Since". В ответ на условный GET, тело запрашиваемого ресурса
передается только, если он изменялся после даты, указанной в заголовке "If-ModifiedSince". Алгоритм определения этого включает в себя следующие случаи:



Если код статуса ответа на запрос будет отличаться от "200 OK", или дата, указанная в поле
заголовка "If-Modified-Since" некорректна, ответ будет идентичен ответу на обычный
запрос GET.
Если после указанной даты ресурс изменялся, ответ будет также идентичен ответу на
обычный запрос GET.
Если ресурс не изменялся после указанной даты, сервер вернет код статуса "304 Not
Modified".
Использование метода условный GET направлено на разгрузку сети, так как он позволяет
не передавать по сети избыточную информацию.
Согласование содержимого
Согласование содержимого (англ. Content Negotiation) — механизм автоматического
определения необходимого ресурса при наличии нескольких разнотипных версий
документа. Субъектами согласования могут быть не только ресурсы сервера, но и
возвращаемые страницы с сообщениями об ошибках (403, 404 и т. п.).
Различают два основных типа согласований:


Управляемое сервером (англ. Server-Driven).
Управляемое клиентом (англ. Agent-Driven).
Одновременно могут быть использованы оба типа или каждый из них по отдельности.
В основной спецификации по протоколу (RFC 2616) также выделяется так называемое
прозрачное согласование (англ. Transparent Negotiation) как предпочтительный вариант
комбинирования обоих типов. Последний механизм не следует путать с независимой
технологией Transparent Content Negotiation (TCN, рус. Прозрачное согласование
содержимого, см. RFC 2295), которая не является частью протокола HTTP, но может
использоваться с ним. У обоих существенное различие в принципе работы и самом
значении слова «прозрачное» (transparent). В спецификации по HTTP под прозрачностью
подразумевается, что процесс не заметен для клиента и сервера, а в технологии TCN
прозрачность означает доступность полного списка вариантов ресурса для всех
участников процесса доставки данных.
Управляемое сервером
При наличии нескольких версий ресурса сервер может анализировать заголовки запроса
клиента, чтобы выдать, по его мнению, наиболее подходящую. В основном
анализируются заголовки Accept, Accept-Charset, Accept-Encoding, Accept-Languages
и User-Agent. Серверу желательно включать в ответ заголовок Vary с указанием
параметров, по которым различается содержимое по запрашиваемому URI.
Географическое положение клиента можно определить по удалённому IP-адресу. Это
возможно за счёт того что IP-адреса, как и доменные имена, регистрируются на
конкретного человека или организацию. При регистрации указывается регион, в котором
будет использоваться желаемое адресное пространство. Эти данные общедоступны, и в
Интернете можно найти соответствующие свободно распространяемые базы данных и
готовые программные модули для работы с ними (следует ориентироваться на ключевые
слова «Geo IP»). Следует помнить что такой метод способен определить местоположение
максимум с точностью до города (отсюда определяется и страна). При этом информация
актуальна только на момент регистрации адресного пространства. То есть, например, если
московский провайдер зарегистрирует диапазон адресов с указанием Москвы и начнёт
предоставлять доступ клиентам из ближайшего Подмосковья, то его абоненты могут на
некоторых сайтах наблюдать что они из Москвы, а не из, к примеру, Красногорска или
Дзержинского.
Управляемое сервером согласование имеет несколько недостатков:




Сервер только предполагает, какой вариант наиболее предпочтителен для конечного
пользователя, но не может знать точно, что именно нужно в данный момент (например,
версия на русском языке или английском).
Заголовков группы Accept передаётся много, а ресурсов с несколькими вариантами —
мало. Из-за этого оборудование испытывает избыточную нагрузку.
Общему кэшу создаётся ограничение возможности выдавать один и тот же ответ на
идентичные запросы от разных пользователей.
Передача заголовков Accept также может раскрывать некоторые сведения о его
предпочтениях, таких как используемые языки, браузер, кодировка.
Управляемое клиентом
В данном случае тип содержимого определяется только на стороне клиента. Для этого
сервер возвращает с кодом состояния 300 (Multiple Choices) или 406 (Not Acceptable)
список вариантов, среди которых пользователь выбирает подходящий. Управляемое
клиентом согласование хорошо, когда содержимое различается по самым частым
параметрам (например, по языку и кодировке) и используется публичный кэш. Основной
недостаток — лишняя нагрузка, так как приходится делать дополнительный запрос, чтобы
получить нужное содержимое.
Прозрачное согласование
Данное согласование полностью прозрачно для клиента и сервера. В данном случае
используется общий кэш, в котором содержится список вариантов, как для управляемого
клиентом согласования. Если кэш понимает все эти варианты, то он сам делает выбор, как
при управляемом сервером согласовании. Это снижает нагрузки с исходного сервера и
исключает дополнительный запрос со стороны клиента.
В основной спецификации по протоколу HTTP механизм прозрачного согласования
подробно не описан.
Множественное содержимое
Основная статья: MIME
Протокол HTTP поддерживает передачу нескольких сущностей в пределах одного
сообщения. Причём сущности могут передаваться не только в виде одноуровневой
последовательности, но в виде иерархии с вложением элементов друг в друга. Для
обозначения множественного содержимого используются медиатипы multipart/*. Работа
с такими типами осуществляется по общим правилам, описанным в RFC 2046 (если иное
не определено конкретным медиа типом). Если получателю не известно как работать с
типом, то он обрабатывает его так же, как multipart/mixed. Параметр boundary означает
разделитель между различными типами передаваемых сообщений.Например
передаваемый из формы параметр DestAddress передает значение e-mail адреса , а
последущий за ним элемент AttachedFile1 отправляет двоичное содержимое изображения
формата .jpg Со стороны сервера сообщения со множественным содержимым могут
посылаться в ответ на частичные GET при запросе нескольких фрагментов ресурса. В этом
случае используется медиа тип multipart/byteranges.
Со стороны клиента при отправке HTML-формы чаще всего пользуются методом POST.
Типичный пример: страницы отправки электронных писем со вложенными файлами. При
отправке такого письма браузер формирует сообщение типа multipart/form-data,
интегрируя в него как отдельные части, введённые пользователем, тему письма, адрес
получателя, сам текст и вложенные файлы:
POST /send-message.html HTTP/1.1
Host: mail.example.com
Referer: http://mail.example.com/send-message.html
User-Agent: BrowserForDummies/4.67b
Content-Type: multipart/form-data; boundary="Asrf456BGe4h"
Content-Length: (суммарный объём включая дочерние заголовки)
Connection: keep-alive
Keep-Alive: 300
(пустая строка)
(отсутствующая преамбула)
--Asrf456BGe4h
Content-Disposition: form-data; name="DestAddress"
(пустая строка)
brutal-vasya@example.com
--Asrf456BGe4h
Content-Disposition: form-data; name="MessageTitle"
(пустая строка)
Я негодую
--Asrf456BGe4h
Content-Disposition: form-data; name="MessageText"
(пустая строка)
Привет, Василий! Твой ручной лев, которого ты оставил
у меня на прошлой неделе, разодрал весь мой диван.
Пожалуйста забери его скорее!
Во вложении две фотки с последствиями.
--Asrf456BGe4h
Content-Disposition: form-data; name="AttachedFile1"; filename="horror-photo1.jpg"
Content-Type: image/jpeg
(пустая строка)
(двоичное содержимое первой фотографии)
--Asrf456BGe4h
Content-Disposition: form-data; name="AttachedFile2"; filename="horror-photo2.jpg"
Content-Type: image/jpeg
(пустая строка)
(двоичное содержимое второй фотографии)
--Asrf456BGe4h-(отсутствующий эпилог)
В примере в заголовках Content-Disposition параметр name соответствует атрибуту name
в HTML-тегах <INPUT> и <TEXTAREA>. Параметр filename равен исходному имени файла
на компьютере пользователя. Более подробная информация о формировании HTML-форм
и вложении файлов в RFC 1867.
Особенности протокола
Большинство протоколов предусматривают установление TCP-сессии, в ходе которой
один раз происходит авторизация, и дальнейшие действия выполняются в контексте этой
авторизации. HTTP же устанавливает отдельную TCP-сессию на каждый запрос; в более
поздних версиях HTTP было разрешено делать несколько запросов в ходе одной TCPсессии, но браузеры обычно запрашивают только страницу и включённые в неё объекты
(картинки, каскадные стили и т. п.), а затем сразу разрывают TCP-сессию. Для поддержки
авторизованного (неанонимного) доступа в HTTP используются cookies; причём такой
способ авторизации позволяет сохранить сессию даже после перезагрузки клиента и
сервера.
При доступе к данным по FTP или по файловым протоколам тип файла (точнее, тип
содержащихся в нём данных) определяется по расширению имени файла, что не всегда
удобно. HTTP перед тем, как передать сами данные, передаёт в заголовке строчку
«Content-Type: тип/подтип», позволяющую клиенту однозначно определить, каким
образом обрабатывать присланные данные. Это особенно важно при работе с CGIскриптами, когда расширение имени файла указывает не на тип присылаемых клиенту
данных, а на необходимость запуска данного файла на сервере и отправки клиенту
результатов работы программы, записанной в этом файле (при этом один и тот же файл в
зависимости от аргументов запроса и своих собственных соображений может порождать
ответы разных типов — в простейшем случае картинки в разных форматах).
Кроме того, HTTP позволяет клиенту прислать на сервер параметры, которые будут
переданы запускаемому CGI-скрипту. Для этого же в HTML были введены формы.
Перечисленные особенности HTTP позволили создавать поисковые машины (первой из
которых стала AltaVista, созданная фирмой DEC), форумы и Internet-магазины. Это
превратило Internet из «академической игрушки» в «коммерческий сервис»: появились
компании, основным полем деятельности которых стало предоставление доступа в Internet
(компании-провайдеры) и создание сайтов.
24)ICMP
ICMP (англ. Internet Control Message Protocol — межсетевой протокол управляющих сообщений) —
сетевой протокол, входящий в стек протоколов TCP/IP. В основном ICMP используется для
передачи сообщений об ошибках и других исключительных ситуациях, возникших при передаче
данных, например, запрашиваемая услуга недоступна, или хост, или маршрутизатор не отвечают.
Также на ICMP возлагаются некоторые сервисные функции.
Технические подробности
Протокол ICMP описан в RFC 792 (с дополнениями в RFC 950) и является стандартом
Интернета (входит в стандарт STD 5 вместе с IP). Хотя формально ICMP использует IP
(ICMP-пакеты инкапсулируются в IP пакеты), он является неотъемлемой частью IP и
обязателен при реализации стека TCP/IP. Текущая версия ICMP для IPv4 называется
ICMPv4. В IPv6 существует аналогичный протокол ICMPv6.
ICMP-сообщение строится из IP-пакетов, сгенерировавших ICMP-ответ. IP инкапсулирует
соответствующее ICMP-сообщение с новым заголовком IP (чтобы отправить ICMPсообщение обратно отправителю) и передает полученные пакеты дальше.
Например, каждая машина (такая, как маршрутизатор), которая перенаправляет IP-пакеты,
уменьшает Time to live (TTL) поля заголовка IP на единицу, если TTL достигает 0, ICMPсообщение о превышении TTL отправляется на источник пакета.
Каждое ICMP-сообщение инкапсулируется непосредственно в пределах одного IP-пакета,
и, таким образом, как и UDP, ICMP является ненадежным (надежным является TCP).
ICMP основан на протоколе IP. Его цели отличны от целей транспортных протоколов,
таких как TCP и UDP: он, как правило, не используется для передачи и приема данных
между конечными системами. ICMP не используется непосредственно в приложениях
пользователей сети (исключение составляют инструменты Ping и Traceroute).
Использование ICMP-сообщений
ICMP-сообщения (тип 12) генерируются при нахождении ошибок в заголовке IP-пакета
(за исключением самих ICMP-пакетов, дабы не привести к бесконечно растущему потоку
ICMP-сообщений об ICMP-сообщениях).
ICMP-сообщения (тип 3) генерируются маршрутизатором при отсутствии маршрута к
адресату.
Утилита Ping, служащая для проверки возможности доставки IP-пакетов использует
ICMP-сообщения с типом 8 (эхо-запрос) и 0 (эхо-ответ).
Утилита Traceroute, отображающая путь следования IP-пакетов, использует ICMPсообщения с типом 11.
ICMP-сообщения с типом 5 используются маршрутизаторами для обновления записей в
таблице маршрутизации отправителя.
ICMP-сообщения с типом 4 используются получателем (или маршрутизатором) для
управления скоростью отправки сообщений отправителем.
Формат пакета ICMP
Формат пакета ICMP
Бит
0—7
8—15
16—31
0
Тип
Код
Контрольная сумма
32 Содержание сообщения (зависит от значений полей «Код» и «Тип»)
Типы пакетов ICMP (полный список)




0 — Эхо-ответ
1 — Зарезервировано
2 — Зарезервировано
3 — Адресат недоступен
код 0 — Сеть недостижима
код 1 — Узел недостижим
код 2 — Протокол недостижим
код 3 — Порт недостижим
код 4 — Необходима фрагментация, но установлен флаг ее запрета (DF)
код 5 — Неверный маршрут от источника
код 6 — Сеть назначения неизвестна
код 7 — Узел назначения неизвестен
код 8 — Узел источник изолирован
код 9 — Сеть административно запрещена
код 10 — Узел административно запрещен
код 11 — Сеть недоступна для ToS
код 12 — Узел недоступен для ToS
код 13 — Коммуникации административно запрещены
код 14 — Нарушение порядка предпочтения узлов
код 15 — Активно отсечение порядка предпочтения


4 — Сдерживание источника (отключение источника при переполнении очереди)
5 — Перенаправление
код 0 — Перенаправление пакетов в сеть
Код 1 — Перенаправление пакетов к узлу
Код 2 — Перенаправление для каждого типа обслуживания (TOS)
Код 3 — Перенаправление пакета к узлу для каждого типа обслуживания




6 — Альтернативный адрес узла
7 — Зарезервировано
8 — Эхо-запрос
9 — Объявление маршрутизатора (RFC-1256)
код 0 — Нормальное объявление маршрутизатора
код 16 — Не маршрутизировать обычный трафик


10 — Запрос маршрутизатора (RFC-1256)
11 — Превышение временного интервала (для дейтаграммы время жизни истекло)
код 0 — Время жизни пакета (TTL) истекло при транспортировке
код 1 — Время жизни пакета (время сборки фрагментов) истекло при дефрагментации

12 — Неверный параметр (проблема с параметрами дейтаграммы: ошибка в IP-заголовке
или отсутствует необходимая опция)
код 0 — Указатель говорит об ошибке
код 1 — Отсутствует требуемая опция
код 2 — Некорректная длина



















13 — Запрос метки времени
14 — Ответ с меткой времени
15 — Информационный запрос
16 — Информационный ответ
17 — Запрос адресной маски (RFC-950)
18 — Отклик на запрос адресной маски (RFC-950)
19 — Зарезервировано (для обеспечения безопасности)
20-29 — Зарезервировано (для экспериментов на устойчивость к ошибкам)
30 — Трассировка маршрута (RFC-1393)
31 — Ошибка преобразования датаграммы (RFC-1475)
32 — Перенаправление для мобильного узла
33 — IPv6 Where-Are-You (где вы находитесь)
34 — IPv6 I-Am-Here (я здесь)
35 — Запрос перенаправления для мобильного узла
36 — Отклик на запрос перенаправления для мобильного узла
37 — Запрос доменного имени (Domain Name Request)
38 — Ответ на запрос доменного имени (Domain Name Reply)
39 — SKIP
40 — Photuris
код 0 — Зарезервировано
код 1 — Неизвестный индекс параметров безопасности (Unkown Security Parameters Index)
код 2 — Параметры безопасности верны, но произошла ошибка аутентификации (Valid
Security Parameters, but Authentication Failed)
код 3 — Параметры безопасности верны, но произошел сбой при расшифровке (Valid
Security Parameters, but Decryption Failed)
код 4 — Требуется проверка подлинности (Need Authentication)
код 5 — Требуется авторизация (Need Authorization)

41-255 — Зарезервировано
25)IMAP
IMAP (англ. Internet Message Access Protocol — «Протокол доступа к электронной почте
Интернета») — протокол прикладного уровня для доступа к электронной почте.
Аналогично POP3, служит для работы со входящими письмами, однако обеспечивает
дополнительные функции, в частности, возможность поиска по ключевому слову без
сохранения почты в локальной памяти.
IMAP предоставляет пользователю обширные возможности для работы с почтовыми
ящиками, находящимися на центральном сервере. Почтовая программа, использующая
этот протокол, получает доступ к хранилищу корреспонденции на сервере так, как будто
эта корреспонденция расположена на компьютере получателя. Электронными письмами
можно манипулировать с компьютера пользователя (клиента) без постоянной пересылки с
сервера и обратно файлов с полным содержанием писем.
Для отправки писем используется протокол SMTP.
Описание протокола IMAP
Как и POP3, протокол IMAP использует концепцию клиент-сервер с набором команд. С
помощью команд осуществляется передача сообщений электронной почты от сервера
клиенту. Клиент устанавливает для этой цели TCP-соединение с портом 143 на сервере.
Далее сервер должен ответить специальным сообщением-приглашением.
Пример сеанса по протоколу IMAP:
1 [jessica@shadrach jessical$ telnet localhost 143
2 Trying 127.0.0.1 ...
3 Connected to localhost.
4 Escape character is '^]'.
5 * OK shadrach.smallorg.org IMAP4rev1 V12.250 server ready
6 a001 LOGOUT
7 * BYE shadrach.smallorg.org IMAP4rev1 server terminating connection
8 a001 OK LOGOUT completed
9 Connection closed by foreign host.
10 [jessica@snadrach jessica]$
В строке 1 показана команда на открытие сеанса с помощью telnet с портом 143 (порт
IMAP по умолчанию). Строка 5 отображает приглашение, выданное сервером IMAP. В
строке 6 клиентом задана команда закончить сеанс с сервером. Затем сервер посылает
сообщение об окончании сеанса (строка 7) и закрывает соединение с клиентом.
Каждая команда, выдаваемая клиентом, предваряется уникальным идентификатором.
Сервер может затем использовать этот идентификатор в своих ответах, что позволяет
клиенту определить, к какой команде относится ответ сервера. Это особенно важно при
выполнении сервером нескольких команд за сеанс. Идентификатор обычно представляет
собой короткую строку алфавитно-цифровых символов, которая генерируется клиентом.
Так, в строке 6 листинга клиентом был выбран идентификатор a001. Если бы клиенту
потребовалось задавать и другие команды, то следующим идентификатором был бы a002
и т.д. Часто для упрощения идентификаторы команд в течение сеанса IMAP просто
последовательно увеличивают один из своих разрядов.
После установления соединения клиент находится в состоянии ожидания проверки
подлинности, так как для выполнения каких-либо операций со своим почтовым ящиком
на сервере он должен идентифицировать себя. После идентификации на сервере клиент
может использовать команды IMAP для управления сообщениями на сервере. Протоколом
IMAP предусмотрена возможность поддержки пользователем нескольких почтовых
ящиков на одном сервере. При этом клиент может читать, отправлять и удалять
сообщения в любом из принадлежащих ему почтовых ящиков. Это серьезный шаг вперед,
по сравнению с протоколом POP3.
Методы проверки подлинности пользователя в IMAP
Так же как и в протоколе POP3, в IMAP имеется несколько методов проверки
подлинности клиента. Некоторые из них обеспечивают больший уровень безопасности, по
сравнению с другими. В отличие от клиентов POP3, клиенты IMAP часто проводят
довольно длительные сеансы с сервером при обработке сообщений. Таким образом,
идентификатор пользователя и пароль не передаются по сети несколько раз в час, как это
обычно происходит при работе по протоколу POP3. Передача идентификатора
пользователя и пароля в зашифрованном виде остается актуальной и применяется по мере
возможности.
Команда LOGIN
Команда LOGIN позволяет клиенту при регистрации на сервере IMAP использовать
идентификатор пользователя и пароль в обычном текстовом виде. Хотя это и не
наилучший метод, все же иногда это единственная возможность подключиться к серверу.
В следующем листинге представлен сеанс IMAP с использованием команды LOGIN:
1 [katie@shadrach katie]$ telnet localhost 143
2 Trying 127.0.0.1...
3 Connected to localhost.
4 Escape character is '^]'.
5 * OK localhost IMAP4rev1 v12.250 server ready
6 a001 LOGIN katie boxcar
7 a001 OK LOGIN completed
8 a002 LOGOUT
9 * BYE shadrach.smallorg.org IMAP4rev1 server terminating connection
10 a002 OK LOGOUT completed
11 Connection closed by foreign host.
12 [katie@shadrach katie]$
В строке 6 видно, как пользователь katie регистрируется на сервере IMAP с помощью
команды LOGIN. В строке 7 показан ответ сервера. Сервер в ответе указал идентификатор
команды клиента (a001).
Команда AUTHENTICATE
С помощью команды AUTHENTICATE клиент может использовать при регистрации на
сервере IMAP альтернативные методы проверки подлинности. Индивидуальная проверка
подлинности пользователей не является обязательной и поддерживается не всеми
серверами IMAP. К тому же реализации такой проверки могут различаться в зависимости
от сервера. Когда клиент выдает команду AUTHENTICATE, сервер отвечает на нее
строкой вызова в кодировке base64. Далее в обязанности клиента входит ответ на вызов
сервера о проверке подлинности, также закодированный base64. Если на сервере не
поддерживается метод проверки подлинности, предложенный клиентом, он включает в
свой ответ отрицательное слово NO. После этого клиент должен продолжить переговоры
по согласованию метода проверки подлинности. Если все попытки определить метод
проверки подлинности потерпели неудачу, то клиент предпринимает попытку
зарегистрироваться на сервере посредством команды LOGIN. Пример сеанса с
применением AUTHENTICATE представлен в листинге:
1 [riley@shadrach riley]$ telnet localhost 143
2 Trying 127.0.0.1...
3 Connected to localhost.
4 Escape character is '^]'.
5 * OK localhost IMAP4rev1 v12.250 server ready
6 a1 AUTHENTICATE KERBEROS_V4
7 a1 NO AUTHENTICATE KERBEROS_V4 failed
8 a2 AUTHENTICATE GSSAPI
9 a2 NO AUTHENTICATE GSSAPI failed
10 a3 AUTHENTICATE LOGIN
11 + VXNlciBOYU1lAA==
12 *
13 a3 NO AUTHENTICATE LOGIN failed
14 a4 LOGIN riley firetruck
15 a4 OK LOGIN completed
16 a5 LOGOUT
17 * BYE shadrach.smallorg.org IMAP4rev1 server terminating connection
18 a5 OK LOGOUT completed
19 connection closed by foreign host.
20 [riley@shadrach riley]$
В строках 6–9 показаны попытки клиента согласовать с сервером IMAP метод проверки
подлинности. В строке 10 показано, что метод проверки, приемлемый и для клиента, и для
сервера, найден. Отвечая, сервер в строке 11 выдает кодированную строку с вызовом в
кодировке base64. Однако в строке 12 клиент отвергает попытку регистрации и
возобновляет ее лишь в строке 14 с помощью команды LOGIN.
Клиентская часть протокола IMAP
Флаги почтового сообщения IMAP
IMAP обладает хорошей системой флагов состояния почты. Каждое сообщение
снабжается флагом, который отображает его статус. Флаг может быть постоянным или
задаваться на время сеанса. Постоянные флаги могут изменяться клиентом и сохраняться
вне зависимости от сеансов. Флаги, назначаемые на время сеанса, действительны только
на время текущего сеанса IMAP.
Варианты флагов почтовых сообщений:






\Seen - Сообщение прочитано
\Answered - На сообщение послан ответ
\Flagged - Сообщение принудительно отмечено
\Deleted - Сообщение удалено
\Draft - Сообщение не окончено (черновик)
\Recent - Новое сообщение в почтовом ящике
Почтовому сообщению может соответствовать 0 флагов или несколько флагов.
Информация о флагах передается клиенту вместе с самим сообщением. В обязанности
клиента входит интерпретация флагов соответствующим образом.
Команды протокола
Доступные в любом состоянии:




CAPABILITY
NOOP — пустая команда, используется чтобы не разорвать сессию по тайм-ауту;
LOGOUT
STARTTLS
Доступные в неаутентифицированном состоянии:



STARTTLS
AUTHENTICATE
LOGIN
Доступные в аутентифицированном состоянии:










SELECT - принимает папку за текущую;
EXAMINE — аналогична SELECT, но доступ будет дан только для чтения;
CREATE — создать почтовый ящик;
DELETE — удалить почтовый ящик;
RENAME - переименовать почтовый ящик;
SUBSCRIBE
UNSUBSCRIBE
LIST - возвращает список папок в почтовом ящике;
LSUB
STATUS — информация о почтовом ящике, в том числе количество непрочитанных

сообщений;
APPEND — добавить сообщение в почтовый ящик.
Доступные в состоянии selected:








CHECK
CLOSE
EXPUNGE
SEARCH — поиск сообщений в почтовом ящике;
FETCH — получить сообщение или его часть;
STORE
COPY
UID
Экспериментальные/расширения:

X<atom> — любые команды, начинающиеся с «X» — экспериментальные.
В IMAP нет команды на перемещение сообщения из одного ящика в другой. Вместо этого,
нужно сделать COPY, а потом отметить сообщение на удаление. Некоторые IMAP-серверы
предоставляют команды из раздела расширенных для перемещения сообщения: например,
сервер GroupWise поддерживает команду XGWMOVE[1].
Преимущества по сравнению с POP3
IMAP был разработан для замены более простого протокола POP3 и имеет следующие
преимущества по сравнению с последним:







Письма хранятся на сервере, а не на клиенте. Возможен доступ к одному и тому же
почтовому ящику с разных клиентов. Поддерживается также одновременный доступ
нескольких клиентов. В протоколе есть механизмы, с помощью которых клиент может
быть проинформирован об изменениях, сделанных другими клиентами.
Поддержка нескольких почтовых ящиков (или папок). Клиент может создавать, удалять и
переименовывать почтовые ящики на сервере, а также перемещать письма из одного
почтового ящика в другой.
Возможно создание общих папок, к которым могут иметь доступ несколько
пользователей.
Информация о состоянии писем хранится на сервере и доступна всем клиентам. Письма
могут быть помечены как прочитанные, важные и т. п.
Поддержка поиска на сервере. Нет необходимости скачивать с сервера множество
сообщений для того, чтобы найти одно нужное.
Поддержка онлайн-работы. Клиент может поддерживать с сервером постоянное
соединение, при этом сервер в реальном времени информирует клиента об изменениях в
почтовых ящиках, в том числе о новых письмах.
Предусмотрен механизм расширения возможностей протокола.
Текущая версия протокола имеет обозначение IMAP4rev1 (IMAP, версия 4, ревизия 1).
Протокол поддерживает передачу пароля пользователя в зашифрованном виде. Кроме
того, IMAP-трафик можно зашифровать с помощью SSL.
26)ISP
Интернет-прова́йдер, иногда просто Провайдер, (англ. Internet Service Provider, ISP, букв.
"поставщик Интернет-услуги") — организация, предоставляющая услуги доступа к
Интернету и иные связанные с Интернетом услуги.
В число предоставляемых интернет-провайдером услуг могут входить:









широкополосный доступ в Интернет;
коммутируемый доступ в Интернет;
беспроводной доступ в Интернет;
выделение дискового пространства для хранения и обеспечения работы сайтов (хостинг);
поддержка работы почтовых ящиков или виртуального почтового сервера;
размещение оборудования клиента на площадке провайдера (колокация);
аренда выделенных и виртуальных серверов (VDS или VPS);
резервирование данных;
и другие.
Интернет-провайдеров можно разделить на типы в соответствии с предоставляемыми
услугами:






провайдеры доступа;
хостинг-провайдеры;
магистральные (англ. backbone) провайдеры;
канальные провайдеры;
провайдеры последней мили;
и другие.
Среди провайдеров доступа можно выделить первичных (магистральных) — имеющих
магистральные каналы связи в собственности — и вторичных (городских) — арендующих
каналы связи у первичных. Первичные провайдеры обычно продают трафик только в
больших объёмах и оказывают услуги другим провайдерам, а не индивидуальным
пользователям, хотя есть и исключения.
Россия
Эта статья или раздел описывает ситуацию применительно лишь к одному региону.
Вы можете помочь Википедии, добавив информацию для других стран и регионов.
С точки зрения российского права, интернет-провайдер — это оператор связи, имеющий
лицензию на один из следующих видов услуг:




Услуги связи по предоставлению каналов связи.
Услуги связи в сети передачи данных, за исключением передачи голосовой информации.
Услуги связи по передаче голосовой информации в сети передачи данных.
Телематические услуги связи.
Лицензии выдаются Роскомнадзором сроком до 5 лет[источник не указан 86 дней].
27)ITU
Междунаро́дный сою́з электросвя́зи (МСЭ, англ. International Telecommunication Union,
ITU) — международная организация, определяющая рекомендации в области
телекоммуникаций и радио, а также регулирующая вопросы международного
использования радиочастот (распределение радиочастот по назначениям и по странам).
Является специализированным учреждением ООН.
По состоянию на март 2011 года в МСЭ входит 192 страны[1] и более 700 членов по
секторам и ассоциациям (научно-промышленных предприятий, государственных и
частных операторов связи, радиовещательных компаний, региональных и международных
организаций). [2]
Стандарты (точнее, по терминологии МСЭ — рекомендации, англ. Recommendations) не
являются обязательными, но широко поддерживаются, так как облегчают взаимодействие
между сетями связи и позволяют провайдерам предоставлять услуги по всему миру.
Задачи МСЭ
Основной целью МСЭ является обеспечить для каждого человека легкий и доступный в
ценовом отношении доступ к информации и связи и направлены на оказание ощутимого
содействия в социально-экономическом развитии в интересах всех людей. Это
достигается либо путем разработки стандартов, используемых для создания
инфраструктуры предоставления услуг электросвязи во всем мире, путем справедливого
управления использованием радиочастотного спектра и спутниковых орбит, помогающих
донести беспроводные услуги до каждого уголка мира, либо посредством предоставления
поддержки странам в осуществлении их стратегий развития электросвязи. Целью Союза
также является обеспечение и расширение международного сотрудничества в
региональном использовании всех видов связи, совершенствование технических средств,
их эффективная эксплуатация.
Структура МСЭ
Штаб-квартира МСЭ находится в Женеве (Швейцария) рядом со зданием ООН.
Руководящий орган — Полномочная конференция, которая созывается раз в четыре года и
избирает Совет МСЭ в составе 46 членов, который проводит свои заседания ежегодно.
Представители всех стран-членов МСЭ на конференции по стандартизации в области
телекоммуникаций (англ. World Telecommunication Standardization Conference, WTSC)
определяют основные направления деятельности каждого сектора и формируют новые
рабочие группы и утверждают план работ на следующие четыре года.
Текущая структура МСЭ была определена в декабре 1992 г. и включает следующие
подразделения:



ITU-T (МСЭ-Т) — Сектор стандартизации электросвязи. Является преемником МККТТ
(CCITT).
ITU-R (МСЭ-Р) — Сектор радиосвязи. Является преемником МККР (CCIR) и МКРЧ.
ITU-D (МСЭ-Д) — Сектор развития электросвязи.
Все секторы имеют исследовательские комиссии. Сектор стандартизации электросвязи
(МСЭ-Т) в наибольшей степени связан (на данный момент) с волоконно-оптическими
сетями. Сектор образован организациями пяти классов:





класс A: национальные министерства и ведомства связи;
класс B: крупные частные корпорации, занимающиеся связью;
класс C: научные организации и предприятия, производящие оборудование связи;
класс D: международные организации, в том числе международная организация по
стандартизации (ISO);
класс E: организации из других областей, но заинтересованные в деятельности сектора.
28)LAN
Локальная вычислительная сеть
Материал из Википедии — свободной энциклопедии
(Перенаправлено с LAN)
Эта версия страницы ожидает проверки и может отличаться от последней подтверждённой,
проверенной 8 июня 2011.
Запрос «LAN» перенаправляется сюда; см. также другие значения.
Запрос «ЛВС» перенаправляется сюда; см. также другие значения.
Лока́льная вычисли́тельная сеть (ЛВС, локальная сеть, сленг. локалка; англ. Local Area
Network, LAN) — компьютерная сеть, покрывающая обычно относительно небольшую
территорию или небольшую группу зданий (дом, офис, фирму, институт). Также
существуют локальные сети, узлы которых разнесены географически на расстояния более
12 500 км (космические станции и орбитальные центры). Несмотря на такие расстояния,
подобные сети всё равно относят к локальным.
Содержание
[убрать]






1 Построение сети
2 Адресация
3 LAN и VPN
4 См. также
5 Литература
6 Ссылки
Построение сети
Существует множество способов классификации сетей. Основным критерием
классификации принято считать способ администрирования. То есть в зависимости от
того, как организована сеть и как она управляется, её можно отнести к локальной,
распределённой, городской или глобальной сети. Управляет сетью или её сегментом
сетевой администратор. В случае сложных сетей их права и обязанности строго
распределены, ведётся документация и журналирование действий команды
администраторов.
Компьютеры могут соединяться между собой, используя различные среды доступа:
медные проводники (витая пара), оптические проводники (оптические кабели) и через
радиоканал (беспроводные технологии). Проводные связи устанавливаются через Ethernet,
беспроводные — через Wi-Fi, Bluetooth, GPRS и прочие средства. Отдельная локальная
вычислительная сеть может иметь шлюзы с другими локальными сетями, а также быть
частью глобальной вычислительной сети (например, Интернет) или иметь подключение к
ней.
Чаще всего локальные сети построены на технологиях Ethernet или Wi-Fi. Следует
отметить, что ранее использовались протоколы Frame Relay, Token ring, которые на
сегодняшний день встречаются всё реже, их можно увидеть лишь в специализированных
лабораториях, учебных заведениях и службах. Для построения простой локальной сети
используются маршрутизаторы, коммутаторы, точки беспроводного доступа,
беспроводные маршрутизаторы, модемы и сетевые адаптеры. Реже используются
преобразователи (конвертеры) среды, усилители сигнала (повторители разного рода) и
специальные антенны.
Маршрутизация в локальных сетях используется примитивная, если она вообще
необходима. Чаще всего это статическая либо динамическая маршрутизация (основанная
на протоколе RIP).
Иногда в локальной сети организуются рабочие группы — формальное объединение
нескольких компьютеров в группу с единым названием.
Сетевой администратор — человек, ответственный за работу локальной сети или её части.
В его обязанности входит обеспечение и контроль физической связи, настройка активного
оборудования, настройка общего доступа и предопределённого круга программ,
обеспечивающих стабильную работу сети.
Технологии локальных сетей реализуют, как правило, функции только двух нижних
уровней модели OSI - физического и канального. Функциональности этих уровней
достаточно для доставки кадров в пределах стандартных топологий, которые
поддерживают LAN: звезда (общая шина), кольцо и дерево. Однако из этого не следует,
что компьютеры, связанные в локальную сеть, не поддерживают протоколы уровней,
расположенных выше канального. Эти протоколы также устанавливаются и работают на
узлах локальной сети, но выполняемые ими функции не относятся к технологии LAN.
Адресация
В локальных сетях, основанных на протоколе IPv4, могут использоваться специальные
адреса, назначенные IANA (стандарты RFC 1918 и RFC 1597):



10.0.0.0—10.255.255.255;
172.16.0.0—172.31.255.255;
192.168.0.0—192.168.255.255.
Такие адреса называют частными, внутренними, локальными или «серыми»; эти адреса не
доступны из сети Интернет. Необходимость использовать такие адреса возникла из-за
того, что при разработке протокола IP не предусматривалось столь широкое его
распространение, и постепенно адресов стало не хватать. Для решения этой проблемы был
разработан протокол IPv6, однако он пока малопопулярен. В различных
непересекающихся локальных сетях адреса могут повторяться, и это не является
проблемой, так как доступ в другие сети происходит с применением технологий,
подменяющих или скрывающих адрес внутреннего узла сети за её пределами — NAT или
прокси дают возможность подключить ЛВС к глобальной сети (WAN). Для обеспечения
связи локальных сетей с глобальными применяются маршрутизаторы (в роли шлюзов и
файрволов).
Конфликт IP адресов — распространённая ситуация в локальной сети, при которой в
одной IP-подсети оказываются два или более компьютеров с одинаковыми IP-адресами.
Для предотвращения таких ситуаций и облегчения работы сетевых администраторов
применяется протокол DHCP, позволяющий компьютерам автоматически получать IPадрес и другие параметры, необходимые для работы в сети TCP/IP.
LAN и VPN
Связь с удалённой локальной сетью, подключенной к глобальной сети, из
дома/командировки/удалённого офиса часто реализуется через VPN. При этом
устанавливается VPN-подключение к пограничному маршрутизатору.
Особенно популярен следующий способ организации удалённого доступа к локальной
сети:
1. Обеспечивается подключение снаружи к маршрутизатору, например по протоколу PPPoE,
PPTP или L2TP (PPTP+IPSec).
2. Так как в этих протоколах используется PPP, то существует возможность назначить
абоненту IP-адрес. Назначается свободный (не занятый) IP-адрес из локальной сети.
3. Маршрутизатор (VPN, Dial-in сервер) добавляет proxyarp — запись на локальной сетевой
карте для IP-адреса, который он выдал VPN-клиенту. После этого, если локальные
компьютеры попытаются обратиться напрямую к выданному адресу, то они после ARPзапроса получат MAC-адрес локальной сетевой карты сервера и трафик пойдёт на сервер,
а потом и в VPN-туннель.
29)LMDS
LMDS
LMDS представляет собой широкополосную систему беспроводных телекоммуникаций типа
«точка-многоточка», которая функционирует в диапазоне частот выше 20 ГГц (конкретный
диапазон зависит от страны и местного лицензирования диапазонов).
Система LMDS предназначена для одно- или двусторонней передачи голоса, данных, Интернеттрафика и видео. На сегодня широко распространенного русского акронима для LMDS не
существует, и даже в официальной русскоязычной документации специалисты пользуются для
обозначения этой системы именно англоязычным акронимом LMDS. В принципе, LMDS можно
перевести как локальная многоточечная распределительная система, но русский акроним такого
перевода, повторимся, в профессиональной терминологии пока не существует.
По своей сути технология LMDS - это сотовая система передачи информации для фиксированных
абонентов на основе радиоканала миллиметрового диапазона волн (для оборудования ДОК это
частота 40,5-43,5 ГГц). По принципу своей организации система LMDS копирует принцип
организации сети в мобильной сотовой связи. Для покрытия определенной территории (обычно
города) разворачивается сеть перекрывающихся сот, в центре каждой из которых устанавливается
базовая станция (БС). Одна БС системы LMDS позволяет охватить район в виде окружности (в
реальности – это многоугольник) с радиусом в несколько километров и подключить несколько
тысяч абонентских станций (АС). Сами БС в системе LMDS объединяются друг с другом
высокоскоростными наземными каналами связи либо радиоканалами.
[редактировать]
Как расшифровывается LMDS
L (local) — подчеркивает, что характеристики распространения радиоволн миллиметрового
диапазона ограничивают территорию действия сотой. Испытания различных
систем LMDS показывают, что радиус соты обычно не превышает 5-7 км.
M (multipoint) — показывает, что сигналы между БС и АС передаются по схеме «точкамноготочка» (вещательный метод). Для обратного канала, - в случае использования беспроводной
связи, используется уже схема «точка-точка».
D (distribution) — означает распространение полезного сигнального трафика: голоса, данных,
Интернет-трафика и видео.
S (service) — показывает коммерческий характер отношений между провайдером сервиса и
подписчиками (клиентами). Именно от провайдера (оператора электросвязи) зависит, какие
конкретно услуги из набора теоретически возможных будут предоставляться подписчикам сервиса.
[редактировать]
Технология LMDS как решение "последней мили"
Системы LMDS получают в последнее время широкое распространение в мире как альтернатива
кабельным сетям. Применение LMDS имеет ряд неоспоримых преимуществ перед кабельными
сетями, в которых абонентская и опорная сеть строится за счет прокладки коаксиальных или
оптических кабелей.
Основные преимущества технологии LMDS и то, чем она отличается от многих существующих
технологий "последней мили":
Во-первых, LMDS - это беспроводная система. Значит, не потребуется прокладка достаточно
дорогостоящих кабельных линий связи.
Во-вторых, сеть на основе LMDS может быть развернута за малый промежуток времени.
Установка и наладка клиентского оборудования занимает всего день, а то и несколько часов.
В-третьих, при возникновении необходимости переезда в другой район система может быть в
короткие сроки демонтирована и установлена в другом месте. Если новое место обслуживается
оператором LMDS, достаточно будет переставить только абонентский терминал.
В-четвертых, относительно невысокая стоимость владения. Стоимость развертывания
абонентского терминала и абонентская плата за канал LMDS меньше, чем за аналогичные по
скорости передачи проводные каналы.
30)MAC
Media Access Control (MAC), уровень управления доступом к среде (передачи) —
подуровень протокола передачи данных, также известен, как Medium Access Control. Является
подуровнем канального (второго) уровнямодели OSI. MAC обеспечивает адресацию и механизмы
управления доступом к каналам, что позволяет нескольким терминалам или точкам доступа
общаться между собой в многоточечной сети (например,
в локальной илигородской вычислительной сети).
Подуровень MAC выступает в качестве интерфейса между подуровнем управления логической
связью и физическим (первым) уровнем модели OSI, и эмулирует полнодуплексный логический
канал связи в многоточечной сети.
Механизм адресации
Основная статья: MAC-адрес
Механизм адресации уровня MAC называется физической адресацией или MAC-адресами.
MAC-адрес представляет собой уникальный серийный номер (см. OUI), который
присваивается каждому сетевому устройству (такому, как сетевая карта в компьютере
или сетевой коммутатор)[1] во время изготовления, и позволяет однозначно определить его
среди других сетевых устройств в мире. Это гарантирует, что все устройства в сети будут
иметь различные MAC-адреса (по аналогии с почтовыми адресами), что делает возможным
доставку пакетов данных в место назначения внутри подсети (англ. Subnetwork), т.е.
физической сети, состоящей из нескольких сегментов,
взаимосвязанных повторителями, хабами, мостами или свичами (но не IPмаршрутизаторами). IP-маршрутизаторы могут соединять несколько подсетей.
Примером физической сети может служить Ethernet-сеть, которая может быть расширена
точками доступа беспроводной локальной вычислительной сети (WLAN) и сетевыми
адаптерами WLAN, так как они делят те же 48-битные MAC-адреса, что и Ethernet.
MAC-уровень не требуется при полнодуплексной связи «точка-точка», но поля MAC-адреса
включены в некоторые протоколы «точка-точка» для обеспечения совместимости.
[править]Механизм
контроля доступа к каналу
Механизм контроля доступа к каналу, предоставляемый уровнем MAC, также известен,
как протокол множественного доступа. Данный протокол позволяет нескольким станциям
делить между собой одну среду передачи данных, к которой они подключены. Примерами
разделяемой физической среды могут служить сети с топологиями типа «шина», «кольцо», а
также сети, созданные с помощью сетевых концентраторов (хабов), беспроводные сети и
сети с полудуплексным подключением «точка-точка». Протокол множественного доступа
может определять и предотвращать коллизии пакетов (кадров) данных при условии, что в
качестве режима конкурирующего доступа используется метод доступа к каналу, или
зарезервированы ресурсы для установления логического канала (при использовании метода
доступа к каналу, основанному на методе кольцевого переключателя или разбиения среды на
каналы).
Механизм множественного доступа основан на схеме мультиплексирования физического
уровня.
Наиболее широко используемый протокол множественного доступа основывается на
протоколе CSMA/CD, используемом в Ethernet. Этот механизм используется только внутри
сетевого домена коллизий, например, в шине Ethernet или в сетевом концентраторе (хабе).
Сеть Ethernet может быть разделена на несколько доменов коллизий,
соединённых мостами и маршрутизаторами.
Протокол множественного доступа не используется в коммутируемых полнодуплексных
сетях, таких, как используемые сегодня коммутируемые сети Ethernet, но частично доступен в
оборудовании для обеспечения совместимости.
MAC-адрес
[править]
Материал из Википедии — свободной энциклопедии
У этого термина существуют и другие значения, см. MAC.
MAC-адрес (от англ. Media Access Control — управление доступом к среде, также Hardware Address) —
это уникальный идентификатор, присваиваемый каждой единице оборудования компьютерных сетей.
Большинствосетевых протоколов канального уровня используют одно из трёх пространств MACадресов, управляемых IEEE: MAC-48, EUI-48 и EUI-64. Адреса в каждом из пространств теоретически
должны быть глобально уникальными. Не все протоколы используют MAC-адреса, и не все протоколы,
использующие MAC-адреса, нуждаются в подобной уникальности этих адресов.
В широковещательных сетях (таких, как сети на основе Ethernet) MAC-адрес позволяет уникально
идентифицировать каждый узел сети и доставлять данные только этому узлу. Таким образом, MACадреса формируют основу сетей на канальном уровне, которую используют протоколы более высокого
(сетевого) уровня. Для преобразования MAC-адресов в адреса сетевого уровня и обратно применяются
специальные протоколы (например, ARP иRARP в сетях TCP/IP).
Адреса типа MAC-48 наиболее распространены; они используются в таких технологиях,
как Ethernet, Token ring, FDDI, WiMAX и др. Они состоят из 48 бит, таким образом, адресное
пространство MAC-48 насчитывает 248 (или 281 474 976 710 656) адресов. Согласно подсчётам IEEE,
этого запаса адресов хватит по меньшей мере до 2100 года.
EUI-48 от MAC-48 отличается лишь семантически: в то время как MAC-48 используется для сетевого
оборудования, EUI-48 применяется для других типов аппаратного и программного обеспечения.
Идентификаторы EUI-64 состоят из 64 бит и используются в FireWire, а также в IPv6 в качестве младших
64 бит сетевого адреса узла.
[править]Структура
MAC-адреса
Стандарты IEEE определяют 48-разрядный (6 октетов) MAC-адрес, который разделен на четыре части.
Первые 3 октета (в порядке их передачи по сети; старшие 3 октета, если рассматривать их
в традиционной бит-реверсной шестнадцатиричной записи MAC-адресов) содержат 24битный уникальный идентификатор организации (OUI)[1], или (Код MFG — Manufacturing,
производителя), который производитель получает в IEEE. При этом используются только младшие 22
разряда (бита), 2 старшие имеют специальное назначение:

первый бит указывает, для одиночного (0) или группового (1) адресата предназначен кадр

следующий бит указывает, является ли MAC-адрес глобально (0) или локально (1)
администрируемым.
Следующие три октета выбираются изготовителем для каждого экземпляра устройства. За
исключением сетей системной сетевой архитектуры SNA.
Таким образом, глобально администрируемый MAC-адрес устройства глобально уникален и
обычно «зашит» в аппаратуру.
Администратор сети имеет возможность, вместо использования «зашитого», назначить устройству
MAC-адрес по своему усмотрению. Такой локально администрируемый MAC-адрес выбирается
произвольно и может не содержать информации об OUI. Признаком локально администрируемого
адреса является соответствующий бит первого октета адреса (см. выше).
Для того, чтобы узнать MAC-адрес сетевого устройства используются следующие команды:

Windows — ipconfig /all — более подробно расписывает — какой MAC-адрес к какому
сетевому интерфейсу относится

Linux — ifconfig -a | grep HWaddr

FreeBSD — ifconfig|grep ether

HP-UX — /usr/sbin/lanscan

Mac OS X — ifconfig, либо в Системных Настройках > Сеть > выбрать подключение >
Дополнительно > Ethernet > Идентификатор Ethernet

QNX4 — netinfo -l

QNX6 — ifconfig или nicinfo
[править]Смена
MAC-адреса
Существует распространенное мнение, что MAC-адрес железно вшит в сетевую карту и сменить его
нельзя или можно только с помощью программаторов. На самом деле это не так. MAC-адрес легко
меняется программным путем, так как значение, указанное через драйвер, имеет более высокий
приоритет, чем зашитый в плату. Однако всё же существует оборудование, в котором смену MACадреса произвести невозможно иначе, как воспользовавшись программатором. Обычно это
телекоммуникационное оборудование, например, приставки для IP-TV (STB).
В Windows смену MAC-адреса можно осуществить встроенными средствами ОС. В свойствах сетевой
платы, во вкладке «Дополнительно» Свойство: Сетевой адрес, указывается нужный MAC-адрес.
В Linux MAC-адрес меняется одной командой от пользователя root:
# ifconfig ethN hw ether <mac-address>
где ethN — имя сетевого интерфейса.
В FreeBSD, OpenBSD:
# ifconfig ethN lladdr <mac-address>