Что может быть проще пересылки текстового сообщения «Hello!» с одного компьютера на другой? Да ничего сложного! Сейчас всё придумаем, а заодно заново изобретём велосипед.
Физический уровень
Для передачи воспользуемся обычным куском медной проволоки. Закодируем послание в двоичный код и будем подавать напряжение, когда надо будет передать единицу, и отключать, когда передаём ноль. На приёмнике сигнала, соответственно, будем расшифровывать сигнал по такому же принципу.
Предварительно договоримся, что каждому символу мы сопоставим определённое число, а затем передавать представление этого числа в двоичной форме.
На выходе из приёмника у нас получится вот такой вот график напряжения:
Теперь осталось просто взять и расшифровать этот сигнал на приёмнике. Включив передачу, мы обнаружили, что реальный мир быстро разрушил наши теоретические построения. Приёмник получил вовсе не то, что мы ожидали:
Оказалось, что на приёмное устройство включилось несколько позднее передающего, а кроме того, генераторы тактовой частоты у приёмника и передатчика несколько различаются. Хоть на них и написано 100 МГц, выяснилось, что приёмник работает с частотой 101,3 МГц, а передатчик – с частотой 100,9 МГц.
Разумеется, можно было бы оснастить два устройства высокоточными атомными часами, или использовать для синхронизации сигналы GPS (см. Маршрут построен), но это сильно дороже, чем мы рассчитывали. Вот, если бы нам удалось передать приёмнику тактовый сигнал передатчика. Подумав немного, мы решили добиться этого, закодировав сигнал, разделив каждый такт на 2 части. Ноль мы кодируем падением потенциала, а единицу – ростом:
Ура, нам удалось передать короткий текст с одного компьютера на другой! (А заодно мы заново изобрели Манчестерское кодирование, которое применяется в настоящее время в технологии Ethernet. Если вы зачистите пару проводов в сетевом кабеле и подключите их к осциллографу, вы увидите на экране картинку, очень похожую на эту:
Существуют и другие виды физического кодирования сигнала, но, чтобы описать их все, мне не хватит ни времени, ни места в посте).
Кстати об Ethernet-кабеле (Витой паре) – хотя внутри него находятся 8 проводов, для передачи сигнала со скоростью до 100 Мбит /с достаточно всего четырёх из них. Все восемь требуются лишь для передачи со скоростью свыше 1 Гбит/с.
Канальный уровень
Мы построили физический канал связи, но все наши проблемы пока не решены. Пока мы передавали короткие наборы данных, всё было прекрасно. Но на длинных пакетах данных очень часто возникала проблема «сдвига фазы». Приёмник просто не знает, где кончается одно сообщение, и начинается другое:
Нам нужен какой-то способ разделять разные блоки данных между собой, назовём их кадры (или фрейм, frame) чтобы приёмник мог точно знать, где заканчивается один пакет, и начинается другой. Поскольку всё, что мы можем передавать – это нули и единицы, договоримся о специальном символе-разделителе, например, такой последовательности: 01111110. Теперь, перед началом пакета мы всегда будем посылать эту последовательность, а приёмник будет знать, что получает новый кадр. Тут возникает вопрос, а как поступить, если в передаваемых данных так же встретится подобная комбинация бит? Давайте тогда договоримся, что если внутри кадра нам требуется передать более 5 последовательных единиц подряд, то вместо 111111 мы будем передавать 1111101 – то есть, вставлять нолик после каждых 5 единиц. Приёмник, с другой стороны, так же будет настроен на то, чтобы игнорировать этот ноль. Чтобы не терять синхронизацию, во время простоя приёмник будет постоянно передавать последовательность-разделитель во время установленного соединения.
Когда же требуется установить новое соединение и установить синхронизацию по частоте будем пользоваться следующим соглашением – сначала несколько наносекунд молчания, длительность должна соответствовать как минимум длительности передачи 96 бит (12 блоков по 8 бит или октетов). Это нужно для того, чтобы точно удостовериться, что данные в настоящий момент не передаются. Затем будет посылаться преамбула – 56 бит повторяющихся пар нулей и единиц: 10101010101010101010101010101010101010101010101010101010 – так приёмник сможет точно измерить длительность, с которой будут передаваться биты. Затем мы передадим уже знакомую последовательность начал кадра: 01111110, после чего – наше сообщение.
Мы более-менее успешно справлялись только с одним видом соединения – от одной точки к другой (или по-английски Point-to-Point). А соглашение и правила, по которым мы условились осуществлять передачу, давайте назовём ПРОТОКОЛ. Но тут мы решили организовать компьютерную сеть, состоящую из нескольких компьютеров. Можно, конечно, оснастить каждую пару компьютеров отдельным каналом связи, но проще будет подумать, какие необходимо внести изменения в наш протокол, чтобы можно было бы передавать сообщение по одному физическому каналу на любой из подключённых к нему приёмников.
Для начала необходимо как-то идентифицировать компьютеры в нашей сети. К счастью, каждое приёмо-передающее устройство имеет нечто вроде уникального 6-значного (48 бит) серийного номера, который обычно записывается в шестнадцатеричном виде через двоеточие, например e0:62:0f:1a:02:2d, иначе он называется MAC-адрес (от Media Access Control – управление доступом к среде).
То есть внутри нашего кадра мы теперь будем сначала передавать MAC-адрес приёмного устройства на компьютере-получателе, затем свой адрес (чтобы нам могли ответить), затем укажем подсказку, какие данные внутри, затем – сами данные, после чего – их контрольную сумму (её посчитаем по алгоритму CRC-32, о котором, может быть, я расскажу в другой раз. Тема интересная).
Наш кадр (Ethernet frame) приобретает следующий вид:
Ура, мы заново изобрели протокол Ethernet, одну из разновидностей протокола HLDC (High-Level Data Link Control).
Что передать в качестве типа данных? Давайте пока передадим 0001000 00000000 (0x800), а потом к этому вернёмся.
Тут стоит сказать, что есть одна разновидность HLDC под названием Point-to-Point protocol или сокращённо PPP, которая чуть отличается от вышеприведённой схемы. Поскольку, как следует из названия, он используется для связи вида «точка-к-точке», в поле адрес получателя всегда вносится 11111111 (FF), а в адрес получателя – всегда 00000011 (3). Почему? Так повелось исторически.
Сетевой уровень
И так, теперь, получая по локальной сети кадр данных, приёмник может проверить, а ему ли предназначается данное сообщение. Он сверит MAC-адрес, указанный в кадре со своим MAC-адресом, и, если данные предназначаются не ему – попросту проигнорирует его. Есть, правда, и способ передачи данных на все компьютеры, подключённые к нашей сети. Для этого, в качестве адреса получателя мы должны указать FF:FF:FF:FF:FF:FF – все единицы в двоичном представлении. В этом случае сообщение получит каждое подключённое устройство.
Примечание для параноиков: несмотря на это, при помощи небольших ухищрений данные, предназначенные другой машине, можно просмотреть из любой другой точки сети, эта техника называется «сниффинг», а программы, предназначенные для этого – снифферы или по-умному – анализатор пакетов. Один из наиболее известных и бесплатных Wireshark.
Но что, если у нас несколько сетей? Собственно, само слово «Интернет» это подразумевает. Если всё очень сильно упростить, то интернет – это совокупность локальных сетей, подключённых к крупным магистральным «хабам» (маршрутизаторам, хостам), с прямым соединением:
Допустим, нам необходимо передать наше «Hello!» с компьютера А на компьютер В:
Даже, если мы и знаем MAC-адрес компьютера В (а это в большинстве случаев не так), то при отправке пакета данных с компьютера А, внутри этой сети нет компьютера B, и, соответственно, адресат наше сообщение не получит. Получается, нам необходим какой-то иной адрес, который будет универсальным для любой сети, подключённой к Интернету. При помощи этого адреса, хабы смогут пробрасывать сообщение между различными локальными сетями, зная, к какому именно хабу подключена сеть, где находится компьютер адресата.
Совершенно ясно, что нам необходим новый протокол, который мы так и назовём: Интернет протокол (IP – Internet protocol), а адрес компьютера по этому соглашению – IP-адрес.
В настоящее время чаще всего используется схема адресации версии 4 (IPv4), где адрес состоит из 32 бит (4 октетов), которые записывают в виде десятичных цифр вида 192.168.0.1 или 127.0.0.1. Как нетрудно посчитать, такая схема может максимально адресовать 4 294 967 295 устройств, поэтому сейчас активно внедряется версия 6 (IPv6), в котором на адрес отведено аж 128 бит, вместо 32, чего с лихвой должно хватить на пару ближайших столетий.
Когда на хаб, соединённый сетью А передаются данные для сети B, используя данную адресацию, можно построить требуемый маршрут для передачи. Для этого на каждом из таких компьютеров имеется таблица адресов (таблица маршрутизации или routing table) и номер интерфейса (условно — сетевого адаптера) по которому следует передавать данные на нужный адрес.
Но даже с IP версии 4, поддерживать на каждом хабе адресную таблицу, состоящую из 4 млрд. записей непрактично и вовсе невозможно, когда речь идёт об IPv6. Вместо этого, в адресной таблице (таблице маршрутизации) можно указывать целые группы адресов.
Например, компьютер в сети B имеет IP адрес 47.58.3.83. На хабе «Афина» (названия условны) в таблице маршрутизации указано: пакеты на 47.58/16 отправлять по интерфейсу 2 (на «Аид»).
Сокращение /16 означает любой адрес назначения, где первые 16 бит соответствуют 47.58. Таблица маршрутизации может содержать и уточнение, например 47.58.3/24 → 3 (на «Зевс»). В данном случае пакет будет направлен на хаб «Зевс», потому что чем больше степень уточнения (24 бит вместо 16), тем более высокий приоритет имеет запись.
Но таблицы маршрутизации не решают проблему, как компьютеру в одной локальной сети передать информацию на компьютер в другой сети. Собственно, мы подходим к тому, что внутрь Ethernet кадра, описанного выше, мы должны вложить IP пакет, где будет указано, на IP адрес необходимо доставить информацию.
И ещё – как узнать, какой именно из компьютеров в нашей локальной сети подключён к какому-либо из хабов, то есть, является «шлюзом» (Gateway) в интернет? Если открыть на компьютере свойства сетевого подключения, мы увидим картину, похожую на эту:
Как видно, адрес «шлюза» (Default gateway) обычно настраивается при подключении (Примечание: современные локальные сети могут конфигурировать подключение без участие пользователя). Так же здесь мы можем увидеть загадочное 255.255.255.0 – маску подсети. Она говорит нам о том, что у всех устройств в нашей локальной сети адреса первых 24 бит совпадают. Почему 24 бит? Достаточно посмотреть на эту «маску» в двоичном представлении: 11111111 11111111 11111111 00000000. Единицей промаркированы совпадающие биты в адресах. С такой маской в одной сети может одновременно находиться до 256 устройств. В крупных сетях маска может быть иной.
Эта конфигурация сети говорит о том, что на любой адрес, начинающийся с 192.168.0 можно пересылать сообщения по локальной сети, а информацию, предназначенную для других получателей – отправлять на «шлюз». Но возникает вопрос, адрес «шлюза» – это 4 ничего не значащих для нас цифры, ведь, чтобы отправить что-либо по сети Ethernet, нам необходим MAC адрес для этого устройства. Как водится в сетевом мире, и на это имеется свой протокол, который называется ARP – Address Resolution Protocol (протокол определения адреса).
Простыми словами, в процессе отправки этого запроса по всем компьютерам в нашей сети, мы спрашиваем: «Эй, у кого тут адрес 192.168.0.1?». Шлюз примет это сообщение и ответит аналогичным пакетом, в котором будет указан код операции 2 (ответ) и заполненное поле, где будет указан его MAC-адрес.
На стороне получателя при получении информации извне, шлюз формирует точно такой же запрос, на который отвечает устройство-получатель, сообщая свой MAC-адрес.
Примечание: в жизни всё обычно несколько сложнее, так как IP-адреса внутри локальной сети не являются глобально-уникальными, и в функции шлюза так же входит обязанность по их преобразованию (трансляции). Данная техника имеет название NAT (Network Address Translation).
Теперь, имея физический адрес нашего шлюза и IP-адрес нашего получателя, мы, наконец, можем отправить информацию с текстовым сообщением «Hello!».
Для этого, в уже знакомый нам Ethernet фрейм мы вкладываем IP-пакет. Его структуру можно лицезреть ниже на рисунке (показана структура пакета версии 4). Заголовок пакета состоит из нескольких «слов», длиной 2 байта (32 бит):
Отдельно здесь хочу уделить внимание полю TTL (время жизни) и зачем оно нужно. Если посмотреть на диаграмму с маршрутизаторами чуть выше, не всегда можно надеяться на то, что таблицы маршрутизации на всём пути следования настроены как надо. Предположим, IP-пакет, отправленный с «Афины» на «Аида», но тот, вместо того, чтобы передать его «Посейдону», передал его на «Гермес», который, в свою очередь, имеет правило маршрутизации, предписывающее передавать пакеты обратно на «Афину». Получается своеобразная «петля», и пакет бы передавался так вечно, если бы не «время жизни». С ним, пройдя определённое количество маршрутизаторов, пакет будет благополучно уничтожен (не дойдя до адресата).
Теперь же, заполнив этот «бланк электронного отправления», мы можем приступить непосредственно к установлению связи с компьютером в другой сети, зная, что маршрутизаторы на пути следования этого пакета данных смогут доставить его получателю.
Транспортный уровень
Если вы невнимательно читали, я напомню, что внутрь одного PPP-фрейма может влезть максимум 1500 октетов (байт). Соответственно, если объём передаваемых данных больше этого значения, нам необходимо будет разбить их на несколько фрагментов и упаковать их каждый – в свой IP-пакет. Здесь нас подстерегает ещё несколько проблем.
Мы не знаем, по каким именно маршрутам будут пересылаться наши пакеты, мы не знаем, все ли из них будут доставлены (это называется потеря пакетов или packet loss), и нам никто не гарантировал того, что получены они будут именно в том порядке, что отправлялись.
Данные проблемы могут возникнуть из-за физических повреждений на линиях связи, их перегрузкой, когда с множества компьютеров передаются большие объёмы данных, и маршрутизаторы вынуждены отбрасывать пакеты с низким приоритетом, обновлениями таблиц маршрутизации на пути следования пакетов, отказом оборудования и ещё тысячей и одной других причин.
Ещё одну проблему представляет ситуация, когда между двумя компьютерами одновременно ведётся два или более «разговоров» (например, пересылается файл и осуществляется видеозвонок).
Соответственно, нам нужен механизм (да, угадали – ещё один протокол), который бы позволял нам узнавать, был ли доставлен пакет и повторно отправлять их, если это вдруг произошло, а также определять какой из пакетов к какому из «разговоров» (или соединений) относится.
На помощь приходит Протокол управления передачей или TCP (Transmission Control Protocol), который призван решить все перечисленные проблемы, обеспечивая гарантированную передачу данных по ненадёжным каналам связи.
Пользователям достаточно знать, что, когда устанавливается TCP-соединение, между двумя устройствами как бы пробрасывается «труба», и любой поток данных, вошедших с одного конца, рано или поздно появится на другом, без потерь, искажений и в нужной последовательности (разумеется, если не произойдёт разрыва соединения, но и в этом случае отправитель будет знать, что данные не доставлены получателю).
Примечание: внутри IP пакета вовсе не обязательно должен находиться TCP пакет. Есть и другие протоколы транспортного уровня (UDP, ICMP, но описывать их все будет очень долго).
Проблема идентификации соединения («разговора») решается как обычно в компьютерном мире их нумерацией. При соединении с каким-либо компьютером, мы указываем протоколу TCP номер порта – произвольное 16-битное число, при помощи которого протокол будет определять, к какому именно соединению относится тот или иной пакет. Можно пользоваться любым незанятым портом, однако некоторые номера, всё же, используются под конкретные нужды конкретными протоколами более высокого уровня (да, да, там «наверху» ещё много протоколов). Так, например, всем известный протокол http (с которым работает веб-браузер) использует по умолчанию порт 80, древний протокол Telnet – порт 23, SSH – 22, и т. д.
Далее, протокол TCP разбивает передаваемые данные на фрагменты, так, чтобы «впихнуть» их в IP-пакеты, которые, в свою очередь, будут «упакованы» в Ethernet-фреймы. Но перед этим, фрагменты нумеруются по порядку, и каждому из фрагментов присваивается свой номер.
«Разговор» двух машин по протоколу TCP может быть двунаправленным, то есть, обе машины могут как посылать, так и принимать данные. При получении каждого нового пакета, машина генерирует ответ-подтверждение, которое так же нумеруется. Так обе стороны точно знают, какие данные были переданы, а какие – ещё нет.
Кроме этого, дополнительно в TCP-протоколе предусмотрены 9 однобитовых флагов, позволяющие более точно регулировать процесс обмена данными. Для экономии места я опишу только часть:
SYN – Бит синхронизации, этот флаг устанавливается только на первом пакете.
ACK – Бит подтверждения – у всех пакетов после первого SYN, должен устанавливаться данный флаг.
RST – сброс соединения
FIN – последний пакет.
Общая структура заголовка TCP пакета показана на диаграмме. Обратите внимание, что порядок бит – обратный (младшие биты слева). Так, например, число 100 (0x64) должно быть указано в обратном порядке: 00100110.
Начало сеанса TCP, также называемый «рукопожатие» (handshake), проходит так:
1. Клиент, который намеревается установить соединение, посылает серверу сегмент с номером последовательности и флагом SYN. Примечание – в целях безопасности (во избежание злонамеренной подмены номера пакета по пути следования, номер последовательности генерируется случайным образом).
2. Сервер, при готовности принять соединение, запоминает его номер последовательности и посылает клиенту сегмент со своим сгенерированным номером последовательности и установленными флагами SYN и ACK (синхронизация и подтверждение). Если сервер не готов к соединению, отправляется флаг RST.
3. Клиент, получив подтверждение, запоминает номер последовательности сервера и так же посылает пакет с флагом ACK.
Трёхэтапного согласования на практике обычно достаточно для перевода соединения в состояние «установлено» (established). После этого как клиент, так и сервер, могут начинать передачу данных друг другу. Получение каждого пакета подтверждается пакетом с флагом ACK, а так же номер подтверждения – то есть, первоначальный номер последовательности плюс количество полученных байт. Если приходит пакет с номером более ожидаемого, он «буферизируется» – запоминается в специально-выделенной области памяти, которая называется «буфером» в ожидании своей очереди.
Для того, чтобы передающая сторона не отправляла данные интенсивнее, чем их может обработать приёмник, TCP содержит средства управления потоком. Для этого используется поле «окно». В сегментах, направляемых от приёмника передающей стороне, в поле «окно» указывается текущий размер приёмного буфера. Передающая сторона сохраняет размер окна и отправляет данных не более, чем указал приёмник. Если приёмник указал нулевой размер окна, то передача данных в направлении этого узла не происходит, пока приёмник не сообщит о большем размере окна.
Когда требуется завершить соединение, его закрытие так же происходит в три этапа.
1. Посылка серверу от клиента флага FIN на завершение соединения.
2. Сервер посылает клиенту флаги ответа ACK , FIN, что соединение закрыто.
3. После получения этих флагов клиент закрывает соединение и в подтверждение отправляет серверу ACK , что соединение закрыто.
Как мы убедились, наши «два байта», которые мы хотели переслать, были в действительности упакованы в своеобразную «матрёшку»:
И это ещё только вершина айсберга. В этом посте весьма поверхностно описаны всего 3 из 7 уровней сетевой модели OSI (Open Systems Interconnections) – де-факто стандарта, связующего огромное количество разнообразных протоколов, которые используются в настоящее время в телекоммуникационных системах. Чтобы описать их все (со всеми протоколами), потребуется издать весьма толстую книгу, написанную сухим техническим текстом без «разжёвывания», поэтому, да простят меня сисадмины и специалисты по телекоммуникациям, если я не сказал чего-то важного, по их мнению.
Как видите, простая поговорка «Просто, как два байта переслать» имеет весьма непростой подтекст.
©
