Как два байта переслать?

Что может быть проще пересылки текстового сообщения «Hello!» с одного компьютера на другой? Да ничего сложного! Сейчас всё придумаем, а заодно заново изобретём велосипед.


Как два байта переслать? Osi, Телекоммуникации, IT, Интернет, Длиннопост

Физический уровень


Для передачи воспользуемся обычным куском медной проволоки. Закодируем послание в двоичный код и будем подавать напряжение, когда надо будет передать единицу, и отключать, когда передаём ноль. На приёмнике сигнала, соответственно, будем расшифровывать сигнал по такому же принципу.


Предварительно договоримся, что каждому символу мы сопоставим определённое число, а затем передавать представление этого числа в двоичной форме.

Как два байта переслать? Osi, Телекоммуникации, IT, Интернет, Длиннопост

На выходе из приёмника у нас получится вот такой вот график напряжения:

Как два байта переслать? Osi, Телекоммуникации, IT, Интернет, Длиннопост

Теперь осталось просто взять и расшифровать этот сигнал на приёмнике. Включив передачу, мы обнаружили, что реальный мир быстро разрушил наши теоретические построения. Приёмник получил вовсе не то, что мы ожидали:

Как два байта переслать? Osi, Телекоммуникации, IT, Интернет, Длиннопост

Оказалось, что на приёмное устройство включилось несколько позднее передающего, а кроме того, генераторы тактовой частоты у приёмника и передатчика несколько различаются. Хоть на них и написано 100 МГц, выяснилось, что приёмник работает с частотой 101,3 МГц, а передатчик – с частотой 100,9 МГц.


Разумеется, можно было бы оснастить два устройства высокоточными атомными часами, или использовать для синхронизации сигналы GPS (см. Маршрут построен), но это сильно дороже, чем мы рассчитывали. Вот, если бы нам удалось передать приёмнику тактовый сигнал передатчика. Подумав немного, мы решили добиться этого, закодировав сигнал, разделив каждый такт на 2 части. Ноль мы кодируем падением потенциала, а единицу – ростом:

Как два байта переслать? Osi, Телекоммуникации, IT, Интернет, Длиннопост

Ура, нам удалось передать короткий текст с одного компьютера на другой! (А заодно мы заново изобрели Манчестерское кодирование, которое применяется в настоящее время в технологии Ethernet. Если вы зачистите пару проводов в сетевом кабеле и подключите их к осциллографу, вы увидите на экране картинку, очень похожую на эту:

Как два байта переслать? Osi, Телекоммуникации, IT, Интернет, Длиннопост

Существуют и другие виды физического кодирования сигнала, но, чтобы описать их все, мне не хватит ни времени, ни места в посте).


Кстати об Ethernet-кабеле (Витой паре) – хотя внутри него находятся 8 проводов, для передачи сигнала со скоростью до 100 Мбит /с достаточно всего четырёх из них. Все восемь требуются лишь для передачи со скоростью свыше 1 Гбит/с.


Канальный уровень


Мы построили физический канал связи, но все наши проблемы пока не решены. Пока мы передавали короткие наборы данных, всё было прекрасно. Но на длинных пакетах данных очень часто возникала проблема «сдвига фазы». Приёмник просто не знает, где кончается одно сообщение, и начинается другое:

Как два байта переслать? Osi, Телекоммуникации, IT, Интернет, Длиннопост

Нам нужен какой-то способ разделять разные блоки данных между собой, назовём их кадры (или фрейм, 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) приобретает следующий вид:

Как два байта переслать? Osi, Телекоммуникации, IT, Интернет, Длиннопост

Ура, мы заново изобрели протокол 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.


Но что, если у нас несколько сетей? Собственно, само слово «Интернет» это подразумевает. Если всё очень сильно упростить, то интернет – это совокупность локальных сетей, подключённых к крупным магистральным «хабам» (маршрутизаторам, хостам), с прямым соединением:


Как два байта переслать? Osi, Телекоммуникации, IT, Интернет, Длиннопост

Допустим, нам необходимо передать наше «Hello!» с компьютера А на компьютер В:

Как два байта переслать? Osi, Телекоммуникации, IT, Интернет, Длиннопост

Даже, если мы и знаем 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) и номер интерфейса (условно - сетевого адаптера) по которому следует передавать данные на нужный адрес.

Как два байта переслать? Osi, Телекоммуникации, IT, Интернет, Длиннопост

Но даже с 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) в интернет? Если открыть на компьютере свойства сетевого подключения, мы увидим картину, похожую на эту:

Как два байта переслать? Osi, Телекоммуникации, IT, Интернет, Длиннопост

Как видно, адрес «шлюза» (Default gateway) обычно настраивается при подключении (Примечание: современные локальные сети могут конфигурировать подключение без участие пользователя). Так же здесь мы можем увидеть загадочное 255.255.255.0 – маску подсети. Она говорит нам о том, что у всех устройств в нашей локальной сети адреса первых 24 бит совпадают. Почему 24 бит? Достаточно посмотреть на эту «маску» в двоичном представлении: 11111111 11111111 11111111 00000000. Единицей промаркированы совпадающие биты в адресах. С такой маской в одной сети может одновременно находиться до 256 устройств. В крупных сетях маска может быть иной.


Эта конфигурация сети говорит о том, что на любой адрес, начинающийся с 192.168.0 можно пересылать сообщения по локальной сети, а информацию, предназначенную для других получателей – отправлять на «шлюз». Но возникает вопрос, адрес «шлюза» – это 4 ничего не значащих для нас цифры, ведь, чтобы отправить что-либо по сети Ethernet, нам необходим MAC адрес для этого устройства. Как водится в сетевом мире, и на это имеется свой протокол, который называется ARP – Address Resolution Protocol (протокол определения адреса).

Как два байта переслать? Osi, Телекоммуникации, IT, Интернет, Длиннопост

Простыми словами, в процессе отправки этого запроса по всем компьютерам в нашей сети, мы спрашиваем: «Эй, у кого тут адрес 192.168.0.1?». Шлюз примет это сообщение и ответит аналогичным пакетом, в котором будет указан код операции 2 (ответ) и заполненное поле, где будет указан его MAC-адрес.


На стороне получателя при получении информации извне, шлюз формирует точно такой же запрос, на который отвечает устройство-получатель, сообщая свой MAC-адрес.


Примечание: в жизни всё обычно несколько сложнее, так как IP-адреса внутри локальной сети не являются глобально-уникальными, и в функции шлюза так же входит обязанность по их преобразованию (трансляции). Данная техника имеет название NAT (Network Address Translation).


Теперь, имея физический адрес нашего шлюза и IP-адрес нашего получателя, мы, наконец, можем отправить информацию с текстовым сообщением «Hello!».


Для этого, в уже знакомый нам Ethernet фрейм мы вкладываем IP-пакет. Его структуру можно лицезреть ниже на рисунке (показана структура пакета версии 4). Заголовок пакета состоит из нескольких «слов», длиной 2 байта (32 бит):

Как два байта переслать? Osi, Телекоммуникации, IT, Интернет, Длиннопост

Отдельно здесь хочу уделить внимание полю 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.

Как два байта переслать? Osi, Телекоммуникации, IT, Интернет, Длиннопост

Начало сеанса TCP, также называемый «рукопожатие» (handshake), проходит так:


1. Клиент, который намеревается установить соединение, посылает серверу сегмент с номером последовательности и флагом SYN. Примечание – в целях безопасности (во избежание злонамеренной подмены номера пакета по пути следования, номер последовательности генерируется случайным образом).


2. Сервер, при готовности принять соединение, запоминает его номер последовательности и посылает клиенту сегмент со своим сгенерированным номером последовательности и установленными флагами SYN и ACK (синхронизация и подтверждение). Если сервер не готов к соединению, отправляется флаг RST.


3. Клиент, получив подтверждение, запоминает номер последовательности сервера и так же посылает пакет с флагом ACK.


Трёхэтапного согласования на практике обычно достаточно для перевода соединения в состояние «установлено» (established). После этого как клиент, так и сервер, могут начинать передачу данных друг другу. Получение каждого пакета подтверждается пакетом с флагом ACK, а так же номер подтверждения – то есть, первоначальный номер последовательности плюс количество полученных байт. Если приходит пакет с номером более ожидаемого, он «буферизируется» – запоминается в специально-выделенной области памяти, которая называется «буфером» в ожидании своей очереди.


Для того, чтобы передающая сторона не отправляла данные интенсивнее, чем их может обработать приёмник, TCP содержит средства управления потоком. Для этого используется поле «окно». В сегментах, направляемых от приёмника передающей стороне, в поле «окно» указывается текущий размер приёмного буфера. Передающая сторона сохраняет размер окна и отправляет данных не более, чем указал приёмник. Если приёмник указал нулевой размер окна, то передача данных в направлении этого узла не происходит, пока приёмник не сообщит о большем размере окна.


Когда требуется завершить соединение, его закрытие так же происходит в три этапа.


1. Посылка серверу от клиента флага FIN на завершение соединения.

2. Сервер посылает клиенту флаги ответа ACK , FIN, что соединение закрыто.

3. После получения этих флагов клиент закрывает соединение и в подтверждение отправляет серверу ACK , что соединение закрыто.


Как мы убедились, наши «два байта», которые мы хотели переслать, были в действительности упакованы в своеобразную «матрёшку»:

Как два байта переслать? Osi, Телекоммуникации, IT, Интернет, Длиннопост

И это ещё только вершина айсберга. В этом посте весьма поверхностно описаны всего 3 из 7 уровней сетевой модели OSI (Open Systems Interconnections) – де-факто стандарта, связующего огромное количество разнообразных протоколов, которые используются в настоящее время в телекоммуникационных системах. Чтобы описать их все (со всеми протоколами), потребуется издать весьма толстую книгу, написанную сухим техническим текстом без «разжёвывания», поэтому, да простят меня сисадмины и специалисты по телекоммуникациям, если я не сказал чего-то важного, по их мнению.


Как видите, простая поговорка «Просто, как два байта переслать» имеет весьма непростой подтекст.

Вы смотрите срез комментариев. Показать все
526
Автор поста оценил этот комментарий
Шик, даёшь повышение качества контента на пикабу!
До уровня приложений допишете ведь, да?
раскрыть ветку (107)
462
Автор поста оценил этот комментарий

Я знаю хороший анекдот про UDP.

Но он может до вас не дойти.

раскрыть ветку (48)
279
Автор поста оценил этот комментарий

Я знаю хороший про tcp, и если он до вас не дойдет, я повторю снова

раскрыть ветку (34)
66
Автор поста оценил этот комментарий

И ГОСТ, и ISO согласны, что есть 7 уровней рассказывания шуток.

37
Автор поста оценил этот комментарий
А кто знает отличную шутку про ARP?
раскрыть ветку (18)
55
Автор поста оценил этот комментарий

Мне в детстве дед про TTL рассказывал, но он умер. :(

раскрыть ветку (2)
Автор поста оценил этот комментарий
Дед?
раскрыть ветку (1)
28
Автор поста оценил этот комментарий

0xdead

7
DELETED
Автор поста оценил этот комментарий
Продуктивные денёк, теперь кроме анекдота про udp ещё два знаю. Спасибо.
раскрыть ветку (1)
10
Автор поста оценил этот комментарий

ветки комментов на пикабу конечно дело интересное, но лучше ссылка где можно почитать больше шуток https://tproger.ru/devnull/sysadmins-humor/

6
Автор поста оценил этот комментарий
ФМС?
раскрыть ветку (6)
44
Автор поста оценил этот комментарий

Я все читал взахлёб. Всё так понятно было....  Но когда дошел до:

«Если вы невнимательно читали, я напомню, что внутрь одного PPP-фрейма может влезть максимум 1500 октетов (байт).»


Я почувствовал

Предпросмотр
раскрыть ветку (2)
7
Автор поста оценил этот комментарий
Это нормально. Он хотя бы первую часть на пальцах объяснил. А дальше как в трешаке: понеслось и рубят все всех.
раскрыть ветку (1)
Автор поста оценил этот комментарий

Какое точное сравнение

7
Автор поста оценил этот комментарий
Стоит как-то таджик в очереди за регистрацией... Или вы про что?
Автор поста оценил этот комментарий

Можно где то Вас почитать от а до я?

раскрыть ветку (1)
1
Автор поста оценил этот комментарий
2
Автор поста оценил этот комментарий

А я знаю неплохую про SCTP.

раскрыть ветку (3)
1
Автор поста оценил этот комментарий
И я теперь тоже знаю неплохую про SCTP.
раскрыть ветку (1)
Автор поста оценил этот комментарий
А я знаю неплохую про SCP
Автор поста оценил этот комментарий

Ну же)

2
Автор поста оценил этот комментарий
Только про MTU знаю обалд
Автор поста оценил этот комментарий

И я тоже знаю неплохую про SCTP.

1
Автор поста оценил этот комментарий

А я вот пока суд да дело, рассказал шутку про IP. Не слушали? Сами виноваты.

раскрыть ветку (1)
1
Автор поста оценил этот комментарий
Дело завели за шутку про IP. И до суда дошло. Не шутите про IP, лучше про MAC.
Автор поста оценил этот комментарий

Шлю я, шлю я ей за пакетом пакет...

ещё комментарии
33
Автор поста оценил этот комментарий

А я знаю про пейджер


- Але оператор? До меня не доходят сообщения!

- Попробуйте прочитать их еще раз...

5
Автор поста оценил этот комментарий
Но он может до вас не дойти.
Нам пофигу.

У нас флажковая азбука и морзянка.

***---***

Иллюстрация к комментарию
раскрыть ветку (10)
27
Автор поста оценил этот комментарий

Даже у азбуки Морзе есть протокол, регулирующий длительность точки, тире и интервала между символами.

раскрыть ветку (2)
18
Автор поста оценил этот комментарий

ну вот, пришел и все усложнил..

1
Автор поста оценил этот комментарий

И вот поэтому есть вопросы к финалу фильма "Паразиты" (который корейский, вышел вот в этом году).

Без спойлеров не получится, но там такая дичь с азбукой Морзе, что списать это можно только на условности мира, типа "магический реализм".

3
Автор поста оценил этот комментарий
Нужен протокол TCP поверх Morse
раскрыть ветку (5)
3
DELETED
Автор поста оценил этот комментарий
И где то телеграфист в сторонке:
Иллюстрация к комментарию
1
Автор поста оценил этот комментарий

Если есть RFC 1149, уверен, что и насчёт Морзе тоже есть.

И не ошибся:

https://8ch9azbsfifz.github.io/moip/

раскрыть ветку (1)
3
Автор поста оценил этот комментарий
Это MorseOverIP, а TCPOverMorse, как по мне, гораздо интереснее
Автор поста оценил этот комментарий

Если серьёзно, то для радио есть AMPRNet, APRS, TCP/IP over AX.25, WinLink.

раскрыть ветку (1)
Автор поста оценил этот комментарий
Это понятно. Но поверх Морзе - это особый вид извращений, такого ещё никто не делал.
Автор поста оценил этот комментарий
Помню в ранних танках, которые ВоТ, когда прокачиваешь танк, была "флажковая радиостанция"... угарно было прокачивать радиус действия)))))
Автор поста оценил этот комментарий

Мне больше "по душе" такое изложение Немного о сетевых понятиях (осторожно мат)

42
Автор поста оценил этот комментарий
Это что думать надо будет? Не, нам ваш интернет нахуй ненужон
Иллюстрация к комментарию
77
Автор поста оценил этот комментарий
Ловите хабрушника !
раскрыть ветку (2)
14
DELETED
Автор поста оценил этот комментарий

На митап побежал =>

раскрыть ветку (1)
Автор поста оценил этот комментарий

На хакатон

20
DELETED
Автор поста оценил этот комментарий
Не хера не понял, но так сука интересно!
9
Автор поста оценил этот комментарий

Ну к примеру в курсе "Сети для самых маленьких" момент с уровнями гораздо проще и нагляднее описан. Описан на примере ICMP запроса. Тут все таки очень много текста, который по итоге не умещается.

раскрыть ветку (2)
11
Автор поста оценил этот комментарий

Да, там годнота.

Здесь тоже годно, но картинку с вложениями уровней я бы вывернул наизнанку.

И в какой-то момент все резко усложняется.

раскрыть ветку (1)
2
Автор поста оценил этот комментарий
А меня забавляют эти перемежевания, когда аосле описания работы очередного протокола идет "разговор" между компьютерами
8
Автор поста оценил этот комментарий
Вероятность такого исхода 50/50
раскрыть ветку (4)
6
Автор поста оценил этот комментарий
0 из 1
раскрыть ветку (3)
5
Автор поста оценил этот комментарий
FIN
раскрыть ветку (2)
4
Автор поста оценил этот комментарий
ACK, FIN
раскрыть ветку (1)
2
Автор поста оценил этот комментарий

АСК

18
Автор поста оценил этот комментарий
Ну, тут тс кратко пересказал книгу "компьютерные сети" Таненбаума. Может даже где-то скопипастил
раскрыть ветку (11)
30
Автор поста оценил этот комментарий
Все так эту книгу хвалят. Наверное, надо будет почитать.
раскрыть ветку (9)
18
Автор поста оценил этот комментарий
Если тут пишут, что ты её скопипастил, а на самом деле ты и вправду не читал её, то и нахрен оно тебе не надо.
раскрыть ветку (1)
6
Автор поста оценил этот комментарий

Тут описан классический Ethernet, а у Таненбаума описан комутируемый

2
DELETED
Автор поста оценил этот комментарий
А ваша фамилия, случайно, не Таненбаум?
1
Автор поста оценил этот комментарий
Спасибо тс. Лет 30 уже с компами и как бы все это знал, но многие вещи было очень интересно узнать. Детям дам почитать :)
1
Автор поста оценил этот комментарий
IBM PC для пользователя - почитай 😜
раскрыть ветку (1)
1
Автор поста оценил этот комментарий

Фигурнов - форева!

Автор поста оценил этот комментарий
Поверхностная книга, которая даёт только базовое представление о строении компьютерных сетей от начала их формирования до сегодняшних дней. Впрочем, все книги про сети, которые мне попадались, для начального(среднего уровня) содержат то, что тс написал. Но, следует сказать, что мне в самом начале познания о сетях, такой пост зашёл бы.
Автор поста оценил этот комментарий

Замечательный пост, продолжай в том же духе!

Автор поста оценил этот комментарий

Стоит. Хотя бы для того чтобы осовременить текст)

Автор поста оценил этот комментарий
И слава богу!
3
Автор поста оценил этот комментарий

Мне прям захотелось написать пост про работу телефонии через ip сеть, но боюсь так же разжевать не получится)

раскрыть ветку (3)
Автор поста оценил этот комментарий
Пишите, Шура, с удовольствием почитаем
Автор поста оценил этот комментарий

пиши, интересно почитать

DELETED
Автор поста оценил этот комментарий
Всегда хотел знать как ip телефония работает. Пиши конечно!
2
Автор поста оценил этот комментарий
Согласен, отличное объяснение!

Я, правда, "поплыл" ещё на сетевом уровне: ну мак-адрес - это понятно. А как они все "по одной трубе" общаются? Каждое устройство ожидает пока все сигналы в проводе стихнут и только потом начинает возбуждать свои? Кто этим дирижирует?
раскрыть ветку (17)
9
Автор поста оценил этот комментарий

Работа эзернета- разговор вежливых людей в темноте: говорит один - остальные слушают, после речи все вежливо молчат, если начинают говорить одновременно, то все замолкают, ибо конфуз. Вот и вся суть.

раскрыть ветку (4)
5
Автор поста оценил этот комментарий

Не слушай этого старпёра. В современном Full Duplex эзернете и сетевых устройствах с отдельными доменами коллизий на каждом линке у кажого направления передачи сигнала своя среда (жила кабеля, или несколько жил). Они физически не могут одновременно зажечь сигнал одном месте. Потому что одного места нет. А вот то, о чём он пишет называется CSMA/CD. Его вполне реально встретить, но всё реже и реже.

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

Хорош! Держи плюсик 😂😂😂😂

2
Автор поста оценил этот комментарий

А в конце этой соединенной цепочки компьютеров стоит Терминатор и отбивает пакеты обратно по проводу, не давая им выпасть из дырки на конце?

раскрыть ветку (1)
Автор поста оценил этот комментарий

Маркировку терминатор уже забыл 😂 вот она старость 😂

2
Автор поста оценил этот комментарий
В ethernet используется практически не модифицированный протокол множественного доступа ALOHA. Если кратко, это протокол случайного доступа, что означает, что как такогого менеджера нет. У каждого абонента есть вероятность отправки сообщения в окно, которую он условно увеличивает если повезло и уменьшает - если нет. А алгоритмов есть множество. В LTE используется наоборот - схема с менеджером, который конкретно говорит - вот сейчас передавай ты - тогда получается плюс-минус честно с очередями и приоритетами. Но у неё есть издержки на сервисный канал, что крадёт пропускную способность. Это если на пальцах. Вообще окей гугл канал с множественным доступом.
раскрыть ветку (10)
2
Автор поста оценил этот комментарий

Уже давным давно не актуально для изернета - это все вымерло с появлением коммутаторов

раскрыть ветку (7)
Автор поста оценил этот комментарий
Тем не менее под капотом там ALOHA с p = 1/2 - два абонента ;)
раскрыть ветку (6)
4
Автор поста оценил этот комментарий

ну раз уж вам так хочется поддержать этот бессмысленный спор, то позвольте ответить что там в изернете и не алоха вовсе, а CSMA/CD, алоха был протокол/экспериментальная сеть построенная в гавайском университете в конце 60-ых и в принципе не предназначенная для общения более чем двух станций,  и человек который его разработал сделал позже усовершенствованный протокол CSMA/CD который поддерживал множество станций в одном сегменте и как раз лег в ранние стандарты изернета и был незаменим в 90-ых годах поскольку тогда станции сидели либо на толстом коаксиале либо же цеплялись к одному хабу, а все что выше, т.е. разные стандарты 100MB используют его только чтобы обеспечить обратную совместимость заложенную протоколом, ну и в конце добавлю что все современные стандарты начиная от 1G до 400G вообще никак не поддерживают  CSMA/CD.

раскрыть ветку (5)
Автор поста оценил этот комментарий

Прям как паровозом проехал своим исчерпывающим каментом по робким попыткам блеснуть познаниями Deerenarosа)

раскрыть ветку (1)
Автор поста оценил этот комментарий

Возможно, про алоху в эзернете затерли на платных курсах повышения компьютерной грамотности.

1
Автор поста оценил этот комментарий
Простому человеку в целом нафиг знать про csma/cd. 1g до 400g это вообще другая опера. Опять же ethernet - протокол, rj45 - разъём, а витая пара - кабель. Но вообще, ALOHA - это идея. Ознакомиться с алохой намного проще, чем погружаться в дебри различных версий ethernet. Ну типа, лан. Спор правда бесполезный, я теоретик - поэтому пишу про теорию. Мне интересно оптимизировать решешение не инженерно, а математически. Инженером по факту меня никто не выпускал из универа =)
раскрыть ветку (1)
Автор поста оценил этот комментарий

Ты заебал уже

Автор поста оценил этот комментарий

Ты забыл упомянуть про CSMA/CD.

Автор поста оценил этот комментарий

а в случае с оптическими сплиттерами как дела с коллизиями?

раскрыть ветку (1)
1
Автор поста оценил этот комментарий
Идеализированно - абсолютно так же. Сплитер тупой и делает "каждый с каждым" по общему каналу. То есть число абонентов становиться равно трём и более... Тут стоит заметить, что ethernet умеет в дуплекс и (как и оптика), что подразумевает свой канал на для каждого абонента при N=2. Но это частности и в них я не силён, увы.
Автор поста оценил этот комментарий
Свитч, коммутатор.
2
Автор поста оценил этот комментарий
Учебник Олифера в одном посте! Класс, продолжайте в том же духе. Подписался.
раскрыть ветку (1)
1
Автор поста оценил этот комментарий
Олиферов же, их там двое)
1
Автор поста оценил этот комментарий

а там всё тоже самое по сути, сочетание тех же приемов

но пишет прикольно это да, жаль что все эти знания совершенно бесполезны в реальном мире разработки, седьмой год работаю так ни одного сокета и не открыл

раскрыть ветку (1)
Автор поста оценил этот комментарий

Ну дак смотря кем работаешь. Писать ресты - конечно там оно не пригодится. А вот писать код для коммутаторов cisco, например, без этого нельзя

Автор поста оценил этот комментарий

Не успеет...

1
Автор поста оценил этот комментарий
Лови Ок, мастер
Автор поста оценил этот комментарий
-Как два байта переслать?
-Как два пальца обоссать...
раскрыть ветку (2)
Автор поста оценил этот комментарий

Тоже нужен протокол?

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

А как же... например классика: достал, поссал, забыл встряхнуть.

ещё комментарии
Вы смотрите срез комментариев. Чтобы написать комментарий, перейдите к общему списку