TCP/IP с человеческим лицом.
вот. что-то мне захотелось написать про то, чем я постоянно занимаюсь, со стороны разработки, и то, что постоянно пользуют миллионы людей и , в особенности и частности те, кто читает , например мой блог, даже не задумываясь о том, как это выглядит с обратной, изнаночной стороны -- сетевых технологиях.
итак часть первая: протокол UDP для чайников.
многие наверное пользуются скайпом, аськой и прочими прибабахами, для того, чтобы, в частности, баловаться веб-камерами и видеочатами. ну так вот, потоковое видео и аудио гоняются по сети именно по протоколу UDP.
ну так что же это такое?
чтобы не грузить наукообразными терминами, давайте представим себе маленькую комнату, в которой сидят одни сплошные блондинки в ужасающем количестве, которые постоянно треплются на совершенно бесполезные темы, никто никого не слушает, но каждая выхватывает из общего гама то, что ей хочется услышать .
вот это и есть описание этого протокола "на пальцах".
зачем же нужен такой, казалось бы бесполезный и безответственный простокол? а вот в том-то и дело, что при большом шуме в сети, при значительной нагрузке на канальном уровне мы выигрываем на прикладном, за счет того, что протокол UDP не требует подтверждения доставки пакета, этим облегчается жизнь приложению, которое, этот собственно, пакет отправило и транспорту, которому это, в принципе, нафик не надо, но так потребовали "сверху".
ну действительно, какая нам разница, если по пути потеряется 5-6 кадров из каждой секунды вашего видео? останется еще 25-24 -- качество от этого не потеряется даже близко, а вот софтине и транспорту не нужно париться проверкой их доставки -- таким образом ваше видео меньше тормозит.
UDP расшифровывается как Протокол Пользовательских Датаграмм, потому как UDP-шные пакетики, в общем-то не являются в полной мере пакетами, ибо могут повредиться и расстерять имеющиеся в них даные по дороге, именно поэтому их именуют словом "датаграмма", типо пользователь написал какие-то данные и послал, а как они дойдут -- это уже его не факает, лишь бы послать, "на получателя" (discover whom it may concern) и "до востребования" (time to live limit).
часть вторая: протокол TCP для кофейников.
ну вот, представьте себе.. например университет .
преподаватель (сервер) рассылает студентам (клиентам) какие-то данные. по истечении срока ТСР-сессии, которая может считаться по умолчанию установленной (семестра) сервер должен получить от клиента подтверждение (экзамен) того, что клиент получил пакет и все данные в нем такие, какими они были отправлены, то есть должны совпадать контрольные суммы (оценка). если пакет доставлен (студент получил допуск к экзамену) и доставлен он в том виде, который приемлем для его правильной расшифровки (3-ка и больше), тогда пакет считается доставленным, если же нет -- (недопуск и/или несовпадение контрольной суммы -- меньше тройки), тогда назначается повторная доставка пакета (повторный курс) с последующей проверкой доставки и целостности.
вот это и есть протокол ТСР -- Протокол Управления Транспортом.
зачем нужен такой сложный и громоздкий протокол? а нужен он нам, когда требуется четко знать, что данные , которые мы отправили, доставлены точно по адресу и в том виде , в котором мы его отравили.
для примера возьмем почту -- если потеряется часть заголовка почтового сообщения -- такое сообщение никогда не дойдет к получателю, поэтому почта ходит только по ТСР, на транспортном уровне.
более того, снижается нагрузка на сеть, хотя в то же самое время она повышается на уровне транспорта и аппликухи.
часть треться: протокол ARP в пятничных терминах.
все, наверное слышали, что такое IP-аддресс, множество раз встречали его упоминание в разных страшных словосочетаниях типа "проверка по IP-аддрессу", "забанить по айпишнику" и так далее...
простые смертные пользователи и, кроме того, всякое ламмо, считают, что айпишник такой-то машины в сети -- зто последняя инстанция, выше только боги.
на самом деле это не так. IP-адресс, это всего-то набор десятично упакованных шестнадцатиричных цифр, который используется как абстракция на реальный, физический МАС-аддресс такой-то сетевой карточки, просто чтобы облегчить себе жизнь в таких случаях:
- когда просто фпадло писать ШЕСТЬ шестнадцатиричных (и только!!!) цифр через двоеточие
- когда надо присвоить одной карточке несколько адрессов (в случае с МАС-ом возможен только один аддресс в один момент времени и сменить его довольно сложно)
- когда надо ставить такое-то доменное имя в соответствие такому-то айпишнику (ДНС-ы не работают с МАС-ами)
- когда надо, чтобы на одном айпишнике видело несколько доменных имен (апач никаких аддрессов кроме айпишников не признает)
- _______ну есть еще несколько случаев, которые я тут приводить не буду по причине их сложности________
ну так вот, а чтобы поставить в соответствие одному или нескольким IP-аддрессам какой-то МАС и существует Протокол Разрешения Аддрессов -- ARP.
вот такая вот фраза: "барышня с сиськами , одетыми в черный лифчик 3,5 размера с розовым бантиком между чашечками" может означать все что угодно, точно так же, как айпи-аддресс, например, 172.16.10.81 может быть присвоен фактически любой машине в частной сети класса В.
а вот если мы скажем что-то вроде : Лена Головач сегодня в черном лифчике 3,5 размера с розовым бантиком между чашечками -- вот тогда станет понятно (напрмер машинам именно из этой сети -- мальчегам и девочкам из компании той самой Лены), что вполне определенная барышня сегодня одела свои сиськи в достаточно прогнозируемый предмет туалета.
ну так вот, в данном случае "Лена Головач" -- это МАС-аддресс, то есть физический, уникальный аддресс такого-то сетевого интерфейса, а "сиськи в черном лифчике 3,5 размера с розовым бантиком между чашечками" -- это всего-лишь прикладная абстракция на физический интрефейс, то есть IP-аддресс, применмимый только для данноого сегмента сети -- для компании девочки Лены.
ну.. пока хватит, шота я устал, да и обед у меня уже закончился.
to be continued ....
vitalego
