Рубрикатор

Все материалы, относящиеся к сетевым технологиям.

(материалы даны в хронологической последовательности, как они появлялись в номерах)


из номера за 17 июня 1998

Возьмусь все-таки осветить вопрос о повышении скорости dial-up соединения с 33600бит/сек до 57600бит/сек. Насколько я сам это понял. Вообще, протокол V.34 был разработан для стандартных аналоговых телефонных линий. Попросту говоря V.34 универсален, т.е. может работать где угодно. Почему такое ограничение - 33600бит/сек? Что, уже больше нельзя? Почему именно нужно было выдумывать протокол Х2 (и 56КFLASH)? Как я понял, практический потолок (33,6) для пропускной способности аналоговый модем - АТС - аналоговый модем обусловлен преобразователей сигнала (в цифру и обратно) на АТС и наличием некоторой RC/LC контура из проводов от конкретного модема до собственно, телефонной станции.
 
Что такое цифровая станция? Это такая штука, которая аналоговый сигнал с телефонного аппарата (или обычного модема) преобразует в цифровой код, а потом направляет этот пакет нужному абоненту, соответственно, для него раскодируя обратно. Старые, обычные станции имели или шаговые переключатели (ну очень старые) или релюшки или каким-то образом мультиплексировали (или де-это длинное слово) аналоговый сигнал. Цифровая станция, ясное дело, удобнее. Быстрее, умнее и т.д. (сейчас, в основном, везде такие)

Что вообще, происходит, когда два модема (любых) цепляются через цифровую станцию? АТС, преобразует приходящий аналоговый сигнал от модема (1) в цифирь посредством АЦП (аналогово-цифровой преобразователь), потом передает цифровой пакет куда надо, далее этот пакет преобразуется обратно в аналоговый сигнал и уходит на другой модем (2). Так вот, основная "потеря" скорости происходит на этапе модем - АЦП, т.е. при преобразовании аналогового сигнала в цифру. Потому как эти самые АЦП вносят помехи в сигнал. Судите сами - модем преобразует Вашу цифровую информацию в аналоговый сигнал, который потом нужно так закодировать в цифру, чтоб все это раскодированное нормально понялось на другом конце провода. Не хочу здесь вспоминать про математику, но существующий предел полосы пропускания у АТС накладывает практическое ограничение на пропускную способность обычного телефонного канала - 33.6кбит/сек - и все. (более подробно я здесь описывать не буду, если есть желание, можно почитать хорошую статью про Х2 и все эти извраты с атээсками на IXBT в разделе описание технологии Х2).

А вот при преобразовании цифра-аналог потеря не такая большая, как при преобразовании аналог-цифра.  То есть, на этапе приема информации от АТС можно получать эти самые 64000бит/сек. Что и использует технология Х2. В самом деле, если модем напрямую подключить к цифровому каналу АТС, то отпадет одно преобразование аналог-цифра от , допустим, провайдерского модема (3), и следовательно, к пользователю (1) пойдет поток ~57кбит/сек через один только ЦАП, который ничего и не "режет".  От пользователя (1) исходящий поток к провайдеру (3) все-таки останется в районе 33кбит/сек, так как от одного преобразования АЦП никуда не деться. Но фокус в том, что по статистике, юзер качает "к себе" в 10 раз больше, нежели "отдает". Так что, тут просто "золотой" случай! :-)
 
Ага! Вот я сразу же задался таким же вопросом: "а что если и пользовательский комплект подключить напрямую к цифровому входу АТС?". Так вот, очень классно получится. Будем иметь 2 канала по 64кбит/сек! Потоки уже не будут ограничены никакими АЦП. Но я так думаю, что напрямую подключиться не у всех получится :-(
 
Можно конечно,  возразить, что есть ISDN, но адаптеры для ISDN стоят дорого и обслуживание цифровой линии до АТС стоит немалые деньги.
 
Какой реальной скорости достигают те, кто уже имеет подобное счастье? Из Америки пишут, что подключаются в среднем на 42-48кбит/сек. Имеют download 4кбайт/сек вместо 3.5кбайт/сек (на 33.6кбит). И связь не всегда устойчивая. Грешат, конечно, на "лапшу" до АТС-ки.
 
Я тут как-то неосторожно написал в предыдущем номере "а нужно ли это провайдеру?". Ведь скорости уже близки к 64кбит на выделенной линии, а за выделенное подключение и за постоянный диал-ап как-то несколько разные суммы надо платить. Вот я и задал вопрос таким хитрым образом :-))
В результате, по крайней мере от 3 совершенно различных провайдеров получил ответы, что "НУЖНО!". Конкуренция, значит :-)) По крайней мере один из них сказал мне, что цены не будут изменяться для пользователей Х2 модемов. А выгода очевидна - "у нас такой сервис есть, а воон у них нету, - подключайтесь к нам!". И вся недолга :-).

из номера за 2 августа 1998

Позволю себе поразмышлять над скорым будущим скачком скорости интернет соединений. Считается, что самые быстрые подключения существуют у провайдера (от 64кбит до 2Мбит), потому как у конечного пользователя в большинстве своем и того меньше, в основном 28.8кбит и точка. Не сдвинуться. Я уже как-то писал большую статью о том, что есть де такие счастливцы, которые юзают X2 модемы и имеют 50кбит сверху и наверх 33600, но весь фокус в том, что и 50кбит, и даже 128кбит - не удовлетворяют сегодняшних потребностей, которые растут просто скачкообразно. Даже поиграть элементарный MP3 нужно поток 128кбит в секунду, да ведь еще в это время хочется веб посерфить и файлик мегов в 30-40 качнуть не забыть, и в реал-видео чего-ньть поглядеть. Вот такие потребности. Скромные кстати. Потому как никто еще виртуал-реалити не шшупал. А дело это говорят весьма жоркое на битосекунды... (потому как например, как же передать те же самые мегабайты текстур, звука и пр.? ... oops, вызываю огонь :-))).
 
А вот представьте, что в одночасье у всех несчастных юзеров стало вдруг не 28800, а скажем 8Мегабит в секудну к "себе" и 1Магабит от "себя", а? Гуд-бай провайдер со скоростями ниже чем хотя бы 10Мегабит. Сейчас у провайдеров в большинстве своем 2Мегабита, ну, даже десять, вполне удовлетворительно для сотни-другой одновременно сидящих на диал-апах и выделенках пользователей, которые даже если очень захотят, такую линию не загрузят. Давайте посчитаем 33.6кбит умножим на 100, получится три с половиной мегабита. А вот если на линию сядут два-три юзера с модемом, указанном выше, то при указанных "скромных" потребностях провайдер просто сядет в лужу со своими пусть хоть тридцатью мегабитами.
 
А где ж такие модемы-то я видал? Да, видал вот. Причем ничего сенсационнго я Вам и не вещаю.
Э-э-э... погодите, я не просто так про модемы заговорил. Нифига! никакой наколки, забегая вперед скажу, что по обычной медной паре. Вот так! И никаких ISDN, да к тому же ISDN только 128 кбит и все.
 
Ведь фишка-то в том, что коммуникации подразумевают не только телефонную линию, которая и связывает нас с внешним миром, а еще есть и кабельное телевидение. Вот америкнцы и подумали - а чего это такой хороший кабель с такой замечательной полосой пропускания пропадает? Скока там на нем можно выжать? Оказалось - 1.5 (полтора!) мегабита к себе (домой) и 300 (триста!) килобит наружу. И модемчики недорогие (200 баков) и плата за постоянне подключение - 40-50 баков в месяц. Даже для нас, согласитесь это не очень-то внапряг. А выгоды сами представите.

В общем, есть такой, к примеру, город в штате Флорида. Джексонвилл называется. Там уже народ рвется подключаться, и подключают. Запросто. Чего зря кабелям просто так видео гонять, пусть они еще "сверху" и интернет качают. Ну это я к примеру город привел, на самом деле, кроме него еще десяток штатов кабелизируется (слово-то какое). Так что практически EtherNet получается (из изображения понятно, что карточка вставляется в комп, да еще и в ISA слот). Не стоит и говорить, какой крутой тогда должен быть провайдер, чтобы клиент (не один!) мог чувствовать себя спокойно. Теперь на провайдера еще окромя нагрузки на жуткое расширение внешних каналов, ложится бремя улучшения своих межсерверных соединений и крутости всех серверов. Вот так-то.
 
А какой нам от этого толк, скажете вы? Мы этого кабельного телевидения и в глаза не нюхали! И будете правы. Нафиг не надо. Потому что есть круче. И по медной паре. По обычному телефонному кабелю. Не мешая даже вашему телефонному аппарату, функции которого я уже кстати, начал подзабывать. :-))
 
ADSL модемы (на IXBT про ADSL хорошо написано - рекомендую) используют особую технику цифрового кодирования, позволяющие получить до 8 (восьми!) мегабит к "себе" и до 1 (одного!) мегабита от "себя". Полсотни мегабайт минуты за четыре, вместо четырех с половиной часов с модемом на 28.8кбит. Cisco, 3Com, AT&T (вместе с Lucent), NEC, Motorola, Microsoft, в общем, кого только нет (список огромен), создают все вместе ADSL форум. Который и занимается проталкиванием этого нововведения. Что такое ADSL? Это Asymmetric Digital Subscriber Line - ассиметричная цифровая линия, а модемы построены на системе цифрового кодирования, которая позволяет достичь таких скоростей. Я подозреваю, что тут должы быть какие-то игры с АТСкой, которая должны быть в свою очередь однозначно цифровая, потому как не верится мне в 8 мегабит "просто так". Атээсочные АЦП и ЦАПы явно в этом случае отдыхают.
 
Но это в идеале, а пока "там" поключают по ADSL только 1.5Мб к "себе" и 256кб от "себя".
Кстати, цены на такое подключение и .... да, чуть не забыл! Там это выглядит так: в комп впихивается обычная Ethernet карточка, которая подцепляется к чудо-модему, который в свою очередь подцепляется навечно к линии. Модем стоит тоже в районе 200 баков, оплата в месяц - примерно такая же, как и у кабельных модемов - около 50 долларов. И все, хэваем фан, так сказать. (не, что-то не так... что-то с АТСкой, должно делаться... нигде я про это не нашел, но видать сервис этот у них просто подразумевается!)
 
Ну вот. Чем это может грозить? Как я уже написал, провайдеры должны стать круты немеряно, т.е. о скоростях 64, 128, 256 кбит можно забыть! А еще ведь никто не знает, как возрастет нагрузка на сервера. Ведь тем самым проклятым узким местом (bottleneck) в плане тормозов было соединение юзер-провайдер, и теперь его не станет, а свято место, как известно пусто не бывает. Значит оно где-то появится. Высчитать не сложно - внешние соединения провайдера - раз, межсерверные соединения у самого провайдера - два, мощности серверов у него же - три. Если еще с последними двумя можно разобраться, то вот насчет первого у меня сомнения. Стоимость например от Иркутска до Москвы оптической линии в 2Мегабита огромна (тысячи долларов в месяц) и я не уверен, что они подешевеют к моменту появления модемов ADSL. Тогда нужно параллельное решение ADSL для оптических линий. Хотя, связь с такими модемами провайдер начнет обеспечивать, конечно уже хорошенько подготовившись, что это я разволновался-то? :-))
 
С такими скоростями, я подозреваю, измениться может сама концепция интернета. Если в старину народ усиленно писал и читал книги, потому как теле- видео- не существовало, то теперь книги делят место с телевизором и видеомагнитофоном. Так же и интернет по проведенной аналогии станет местом не толко текстовых страничек и журналов, потому как видео-то станет очень даже доступным (с 8-мью то мегабитами!), а посему надо ожидать внедрения в интернет телевидения (уж такой-то лакомый кусок телекомпании ни за что не упустят!). Подключаться к интернету вообще, будет иметь смысл даже для самого заскорузлого скептика. Следовательно, адресов понадобится - дай Бог! Так что заканчивающаяся разработка нового типа IP протокола, с помощью которого можно будет выразить не 255 в четвертой степени адресов (ну не будем говорить о локальных сетках), а гораздо больше (настолько много, что разработчики обещают не беспокоиться).
 
С такими скоростями стоит ожидать и новых форматов языков для веба, которые будут иметь полный набор для видео- аудио- и виртуал-реалити. Когда это дойдет до "нас" - не знаю, но берусь предполагать - года через 3-4. А может кто в России уже видел/трогал эти самые ADSL приборчики? Нет, то что они давно здесь есть, понятно, а вот в действии?...


из номера за 6 ноября 1998

Интересно, а как устроена штука под названием "провайдер"? Хотя конечно, очень многие, читающие этот журнал могут сами кого хочешь поучить тому, что такое ISP, но я думаю, что кое-какие разъяснения будут полезны тем, у кого наглядное понятие "сеть" всегда ограничивалось визуально только модемом и проводом от него до телефонной розетки. А что там дальше...
Пожалуй я буду рассказывать, начиная с постановок задач. Что есть у провайдера изначально? Куча телефонных линий от юзеров. Т.е. он (ISP) занимает какие-то номера на телефонной станции, к которым впоследствии будет подцеплять свои модемы для связи с этими самыми юзерами. Конечно, на станции организовывается т.н. "серия номеров", когда на одном номере находится несколько линий, ведущих к провайдерской стойке (1).
 

telephone lines modem pool
1 2

Из стойки все линии приходят на модемный пул (2), (здесь - между ними в стойке - маршрутизаторы). Ну, в масштабном представлении это скорее будет набор модемов в одном корпусе (как и показано на рис.2), а не просто куча отдельных модемов. На рис.2 видны две стойки по 16 и 8 линий (US Robotics).
В принципе, можно уже подключать эти модемы к компьютеру через специальную мультипортовую карту, но есть путь гораздо лучше - через специальный маршрутизатор, применение которого может сильно разгрузить основной сервер.
Суть построения сети на основе IP протокола такова: каждому компьютеру после подключения к сети назначается свой IP адрес, а значит какой-то прибор должно так направлять пакеты с информацией, чтобы они доходили туда, куда надо, т.е. разбираться со всеми адресами в сети. В общем случае скажем так: сколько компьютеров, столько и адресов. Как это все провернуть?
Например, от вашего компьютера ушел пакет на сервер провайдера (несколько утрировано, но пусть так) с запросом ресурса по адресу 195.46.160.45 (простыми словами говоря, вы хотите посмотреть последний анекдот). Вот. Что должна сделать аппаратура у провайдера? Переслать ваш запрос на указанный адрес. Т.е. мы запрашиваем www.anekdot.ru, тут понятно - есть DNS, который нам сопоставит мнемонику с реальным IP адресом. Но что дальше? Где этот адрес находится? Задача и решается с помощью специальных маршрутизаторов, которые держат в себе массив адресов, но не всех, конечно, а только основные части, т.е. устройство знает, что если запрос пришел по ресурсу в сети 195.46.х.х, то он должен будет отправить его на другой IP адрес (где обычно находится другой маршрутизатор), который у него прописан для этой сети, а тот (другой) уже будет разбираться дальше и т.д. Основную роль маршрутизатор играет в качестве именно пересылки пакетов по местам назначения. А навороты для работы с модемными массивами есть не у всех - это уже специальная фича - как раз для провайдеров. Очень непростая машинка, надо сказать. Но и цена у ней соответствующая - порядка 3-4 тысяч долларов. На рис.2 можно видеть два маршрутизатора (между модемами), которые как раз и занимаются этим делом у провайдера. Кроме этого, у маршрутизаторов есть еще одна функция: динамическое назначение IP адресов клиентам. Поэтому, можно заметить, что ваш IP адрес различается в большинстве случаев в последних одной-двух частях, а первые 2-3 остаются неизменными. Первые - это постоянный адрес вашей сетки, а последний - выделенная вам часть ее в виде адреса. Это не касается тех, кто "сидит" на выделенных линиях - у них IP адрес постоянно один и тот же. Это вызвано тем, что если они захотят сопоставить свой IP в соответствии с именем, то они могут спокойно это сделать, потому как динамически выделенному адресу это сделать не в пример труднее.

Cisco
3
 В верхней части рис.3 находится два концентратора, которые как раз могут держать такие выделенные каналы (в данном случае - на оптике) для корпоративных сетей, где есть свой сервер, который уже сам распределяет права между своими пользователями. Да и просто на этих концентраторах могут "висеть" компы. Самого провайдера, например. Модемов, конечно никаких не надо, их место занимают преобразователи из оптики (на рис.3 можно видеть внизу). А если линия простая, Ethernet например, витая пара или даже коаксиал - то прямо втыкаем в концентратор. В Switch, то бишь. Концентраторы, в свою очередь, подцеплены к маршрутизатору.
В общем, схему провайдер-клиент можно представить следующим образом:
ISP-user schem
4
Что вообще, происходит после того, как вы дома или на работе (если у вас связь с ISP не через локальную сеть) нажимаете кнопку "Установить связь"? После набора номера, ваш модем [1] соединится с провайдерским [2]. Хотя, пожалуй, стоит рассказать, как это происходит глядя "с того конца" - с провайдерского. К маршрутизатору [3] подцеплен модемный пул [2], которые маршрутизатор, кстати, настраивает на автоответ. После поступлении звонка и успешного прохождении handshaking'а, оба модема, вместе с линией между ними, начинают представлять уже просто транспорт для связи маршрутизатор - ваш компьютер. И все, о них уже можно не вспоминать. Маршрутизатор на первом этапе должен договориться с вашей системой (он ведь не знает, какая у вас стоит) об авторизации вашего подключения. Для этого существует несколько специальных протоколов. Windows использует протокол CHAP. После того, как маршрутизатор это сделает, он посылает пакет с именем и паролем на авторизующий сервер [5]. После этого, маршрутизатор должен договориться с вашим компьютером о протоколе, на котором ваша система будет общаться с интернетом в дальнейшем. Для Windows этот протокол называется PPP - это вы можете увидеть в настройках. После получения положительного ответа с сервера, маршрутизатор еще должен назначить вам очередной IP адрес, какой у него есть свободный на данный момент, но только из определенного назначенного диапазона. Например, к маршрутизатору подключено 16 линий. Внутрь маршрутизатора прописывается диапазон адресов, среди которых он и может выбирать. Например: с 195.146.60.10 по 195.146.60.25 - как раз 16 адресов. Вот в этом ранге ваш адрес и будет. Все - связь установлена, и на вашем компьютере это отражается соответствующим образом. Ну, а если пароль был неправильным, то маршрутизатор просто отрубает свой модем от линии. Для корпоративных сетей [1a] все проще - они просто напрямую (или через концентратор) включены в маршрутизатор, и адрес сети уже прописан.
Крутая штука, этот маршрутизатор получается. Берет, как видите, на себя достаточно большую часть работы вкупе с тем, что занимается еще и собственно, маршрутизацией. По сути дела, это - отдельный компьютер. У него даже свой IP адрес есть. На него можно зайти, как на сервер, запрограммировать его как надо и т.п.
В общем, без него никуда.
Ну, и, само-собой, у провайдера есть сервер, который собственно содержит в себе базу юзеров, занимается обработкой почты, ftp, http и т.п. Т.е. минимально провайдер просто для предоставления услуг по подключению в интернет способен обойтись только одним компьютером, который может просто заниматься авторизацией, тут и 386-я пойдет. Остальное будет делать маршрутизатор.
unix - rulez!
5
На рис.5 - сервер моего провайдера. Вернее, два сервера. Кружка сисадмина - это просто уже как аксессуар :) На обоих тачках стоит, ясен пень - юникс (а что же еще?!), одна тачка, говоря языком классики "мыло тоссит", другая - собственно, www, ftp и прочие навески...

 


из номера за 11 ноября 1998

Те, кто знает, что такое ftp, POP3, SMTP и http - могут смело эту статейку (for Dummies) пропустить.
Продолжая тему о провайдерах, заодно и отвечу на вопросы о типе маршрутизаторов.
 

cisco 2500
1

На рис.1 видны две стойки по 16 и 8 линий (US Robotics Total Control), а между ними - два маршрутизатора фирмы Cisco, которые собственно с ними и работают.
Сперва попытаюсь разобрать работу ISP (Internet Service Provider), начиная с работы Unix-сервера.Для нормальной работы ISP необходимо организовать кроме авторизующей машины (о чем я рассказывал в прошлом номере) еще и почтовый сервер. Надо отметить, что почта, которую вы пишите или вам пишут, сперва попадает на почтовый сервер провайдера (я рассматриваю тот случай, когда почтовый ящик заведен именно на сервере провайдера). Причем, работа с почтовым сервером идет с использованием своих протоколов: SMTP (Send Mail Transfer Protocol и POP3 (Post Office Protocol version 3).  После того, как почтовый сервер получит от вас письмо, он его положит в очередь на отправку, где находятся и письма от других пользователей. Причем обязательно проверит на правильность заполнения поля адресата, да еще и если адресат находится на этом же сервере, то проверит наличие его имени, и сразу же скажет, есть такой у него или нет. При дальних адресах, конечно, почтовик посылает письмо на указанный сервер, который уже сам будет дальше разбираться с вашей корреспонденцией. Иногда, кстати, вы могли видеть пришедшие вам обратно ваши же письма, адресат которых так или иначе не существовал, о чем вам и сообщал Mail Delivery Daemon - рассыльщик писем. Этим тоже занимается почтовая машина, которая и отправляет вам обратно письма с неверным полем "to:".
Кроме этого, у провайдера есть и другие услуги по предоставлению ресурсов. Один из основных - ftp сервер. Аббревиатура от file transfer protocol. То бишь, работа с файлами сервера напрямую, например, как с отдельным диском. Это наиболее простое в понимании общение с сервером провайдера. Естественно, там находится очень много нужных (и ненужных) провайдеру и пользователям файлов, доступ к которым разграничен по степени причастности к ним. Практически, на сервере любого ISP есть пользователь с именем anonymous ("неназвавшийся") с любым (почти) паролем или вообще, без него. Права у такого пользователя, естественно, минимальны и он сможет читать только те директории, которые специально выложены на всеобщее обозрение. С софтом, например. Но есть директория с именем incoming, куда может записывать свои файлы даже пользователь с правами anonymous. Также может читать. Стирать ничего нельзя. Эта директория специально используется для приема файлов и обмена. Ftp сервис полезен тем, что поддерживает докачку файлов в прямом виде при работе с программами, созданными для этого. CuteFTP или FAR commander например. Можно без боязни потерять связь выкачивать откуда-нибудь огромные файлы. В следующей сессии просто можете указать "возобновить", и программа начнет качать с того места, где было прервано, а не сначала. А вот докачку _от вас_ практически никакой ftp сервер не поддерживает. Копирования файлов с любого удаленного сервера _к вам_ - называется download, а _от вас_ - upload.
Да, чуть не забыл, когда вы заходите под именем anonymous на какой-нибудь сервер, вы можете получить облом по нескольким причинам: 1) там юзерам с таким именем вообще доступ запрещен 2) исчерпан лимит соединений. В первом случае можно успокоиться и идти лесом, а второй случай указывает на то, что системный администратор так настроил сервер, что больше определенного числа пользователей не могут одновременно быть соединены логически с его ftp сервером. Делается это для того, чтобы излишне не перегружать канал провайдера. А вам, следовательно, остается только подождать, пока кто-нибудь освободит соединение.

 


из номера за 6 декабря 1998

Сисадминские байки

      ...Итак, сервер передает вашему браузеру пакеты с информацией. Т.е. с затребоваными ресурсами. По 80-му порту. Это уже обсуждалось в 44 номере. И все бы хорошо, если бы не одно "но". Кодировки. Это настоящий бич для локальных версий программного обеспечения. Т.е. различное представление символов национального языка. С латинскими буквами все просто. Они всегда находятся на одном и том же месте в таблице символов. Кириллица же, например, представлена несколькими видами расположения в таблице. Эти способы расположения и имеют знакомые названия KOI, WIN, DOS (alt), MAC и т.п. Например, в кодировке DOS (alt) код русской буквы "А" - 128, а в кодировке WIN ее код уже будет 192. Историю и "этнос" типов кодировок я здесь рассматривать не буду. Тем более, что в одном из прошедших номеров я давал хорошую ссылку на сайт, где все-все про них написано.

      Ну а интернет-то здесь при чем? Ведь по идее можно договориться использовать файлы только в KOI или скажем в WIN кодировке. А дело в том, что различные операционные системы используют свои кодировочные таблицы. Например, для юникса это KOI, и естественно, что системный администратор старается все текстовые файлы на сервере привести к единому "знаменателю", т.е. только в KOI. Сисадмин NT web-сервера естественно клонит к WIN кодировке.

      "Стягивая" html файл вы еще (вернее ваш браузер) можете знать в какой кодировке написано содержимое файла (например, по META тегу, прописываемому в заголовке файла). К тому же сервер может узнавать, в какой кодировке на данный момент "хочет" получать файлы ваш браузер. Но в общем случае, кроме человека, ничто не сможет определить однозначно, в какой точно кодировке лежит любой текстовый файл. Приходится как-то это дело упорядочивать, брать какие-то соглашения и т.п.

      Допустим, ваш браузер желает видеть windows (1251) кодировку, а на сервере она лежит в KOI. Перекодировкой может заниматься сам сервер. Поэтому на многих сайтах можно видеть кнопочки [win] [koi] [iso] и т.д. Хотя сейчас это уже и не модно, я расскажу все таки как происходит перекодировка на сервере. Когда вы тыкаете допустим на [lat], вы даете команду серверу направлять текстовый поток уже не через 80 порт, а через 8105 порт. например, www.irk.ru:8105/dir1/dir2/... таким образом файл будет обработан следующим образом: встречающиеся русские буквы программа перекодировки на сервере заменит на латинские. И выдаст вам через порт 8105. А вот если с этого же порта вы затребуете не текстовый файл, а скажем, zip или rar, то сервер этот момент просечет (в зависимости от настроек) и его перекодировать не будет, а направит вам по обычному 80-му порту, дабы не попортить его перекодировкой.

      Но сейчас все немного попроще: апач на "той" стороне от юзера знает, какую кодировку в данный момент хочет видеть браузер у пользователя. И сам подбирает таблицу перекодировки.

      На сегодня, если META tag стоит правильно (то есть та кодировка в которой и написан текст), то все браузеры его будут правильно показывать, по крайней мере, последние версии. То же самое и с почтой - если Content-Transfer-Encoding в заголовке письма соответствует содержимому, то  во всех программах будет показываться все правильно. Естетственно, когда такого заголовка или тега нет, либо они не соответствуют содержимому, то получиться может все что угодно.

      Кстати, почему-то я так и не нашел ни у кого ответа на вопрос, "а почему бы всем провайдерам не договориться выкладывать файлы только в какой-то одной кодировке?". Сейчас сильный разнобой. Кто в KOI, кто в WIN. Иногда встречаются такие перлы: текст лежит в WIN, сервер думает что там KOI и перекодирует его в WIN. Получается как бы WIN->WIN. Это вызывает просто несварение у многих программ. Особенно такая беда встречается у многих почтовых серверов. Применение, например, в NN view->encoding->... результата не даст. Потому как encoding сделан, собственно, как viewer - он просто пытается посмотреть на код с "разных сторон" кодировочных таблиц. Лечится обратной перекодировкой в KOI. Такие казусы вполне могут быть результатом неправильной настройки сервера.

      Теперь - FTP. File Transfer Protocol был рожден чуть ли не вместе с юниксом. Общение с юзером в действительности происходит через два порта (понимайте слово "порт" просто как виртуальное устройство). 21 порт - команды для FTP сервера, 20 порт - данные. Такое разделение, по видимому было придумано для того, чтобы множить потоки 20-го порта, а для управления использовать только один 21-й. Это даст возможность во время передачи например дать команду cd (change directory) и/или команду на передачу другого файла. Да еще такое разделение дает возможность множить потоки данных на 20 порт, не создавая множества ftp-сессий с сервером. В случае ограничения соединений - это было бы удачным решением. Почему "было бы" ? Потому как, что-то я не знаю ни одной программы, которая бы так делала. Приходится открывать еще одну сессию. А можно было бы просто раздробить потоки данных по 20-му порту. Почему никто так и не написал такого софта, непонятно...

      Само по себе разделение вообще-то достаточно интересная штука, хотя можно обойтись и без него. Но, повторяю, ftp сервис был придуман давно, и работа через два порта видимо что-то подразумевала еще, но... Давно это было :))

      Кстати говоря, у ftp сервера достаточно интересный набор команд, о которых мы и не подозреваем подчас. За нас их выполняет ftp программа (Cute, FAR или даже Windows-commander, да много каких). Особенно в CuteFTP можно видеть какие именно команды он подает. Например, чтобы показать вам директорию на удаленном сервере выполняется две команды: cd dir - сменить директорию, pwd - напечатать директорию, выдавая поток с информацией вам.

 

 


из номера за 10 декабря 1998

Сисадминские байки

Работа сетей достаточно сложная штука. Хотя бы потому, как IP протокол сам по себе асинхронен. Т.е. посылающая сторона должна ждать подтверждение от принимающей стороны. Есть конечно, еще и UDP протокол, который подтверждений не требует. Этим протоколом общаются между собой сервера для обмена информацией по DNS. Ну, про UDP позже, а вот насчет IP - подробнее:
Разберем простой пример: у вас модем на 33600 (до провайдера), и у провайдера канал "наружу", допустим, 2Мб. Вы в настоящий момент вытягиваете тяжелый файл с сервера, находящимся где-то далеко. Скорость download'а в идеале будет примерно 3.5кб/с (сжатого файла). Т.е. ваша машина будет получать от модема 3.5 кила в секунду. Но вот с "того" сервера, откуда производится download - с какой скоростью будут уходить пакеты? И как вообще, _ваши_ 33600 умещаются в провайдерском канале 2Мб? Может это как-то ограничено?
 
Важно представить себе работу протокола, чтобы немного разобраться с этими "простыми" вопросами. Наверное, не стоит представлять себе "толстый" канал провайдера, как содержащий в себе кучу маленьких подканальчиков на 33600, 14400 и т.д. по числу пользователей. Скорее, это будет просто совокупность хождения всех пакетов туда-сюда.
Хм... вообще, я эту прелюдию написал, чтоб немного самому раскачаться. Тут вот какой момент: если вы допустим, "сказали" далекому серверу подать вам вооон тот файл, и он начал его добросовестно вам передавать, и совсем не знал, что после 2-3 минут передачи у вас отрубят свет, произодет крах вашей системы или еще какая бяка, которая временно или надолго отрубит вас от сети. Куда денутся пакеты с информацией? И вообще, как серверу узнать, что вы все еще хотите принимать файл или уже нажали "Cancel", потому как поняли что энное количество мегабайт со скоростью 4б/с вам еще долго не вытянуть... И почему при закачке файла (к вам) по ftp скорость сначала растет, а потом может и упасть? Почему она вообще, сначала растет?
Попробую ответить так: потому как удаленный сервер не знает, на какой скорости вы подключены и начинает слать вам пакеты, скажем по 700 байт, а после того, как придет подтверждение, он уже решает, повысить размер пакета или нет. После того, как ваша система приняла пакет с информацией, она должна отослать подтверждение о приеме тому серверу, откуда она этот пакет получила. Это и есть асинхронная передача данных.
 
Но существует еще и такое понятие, как время жизни пакета - TTL (time to live) - оно устанавливается в каждом пакете для того, чтобы не засорять сети "умершими" данными. Причем, когда такой пакет находясь даже уже в пути, в маршрутизаторе, исчерпает свое время жизни, маршрутизатор его преспокойно грохнет. Посему, если вы приняли пакет, отослали на него подтверждение и "тот" сервер послал вам следующий, а вы в это время как раз скоропостижно "рухнули", то пакет умрет, а "тот" сервер, не получив ожидаемого подтверждения, успешно закроет сессию. Умер, так умер. Но только попеременно передавать-принимать пакеты с подтверждениями немного неинтересно. Гораздо красивее запустить какую-то кучку пакетов, а потом получать на них подтверждения. Так и образуется стек FIFO (первым вошел-первым вышел) IP пакетов. Которые гуськом торопятся попасть к вам в тачку. Опять-таки, торопиться они могут перегоняя друг друга, фрагментируясь и дефрагментируясь по дороге, а нормальное фифо собирается tcp логикой уже из приемных буферов. И, кстати, нюкалка teardrop основана на неправильном задании размеров фрагментов пакетов, отчего у сборщика крыша съезжает напрочь и ваша тачка честно виснет.
В TCP есть такое понятие, как "окно". Это значит, что передающая сторона передает несколько пакетов, не дожидаясь подтверждения на первые пакеты. Т.е. с передающей стороны уходит сразу достаточно большой кусок данных, которые оседают в различных буферах пока не протиснутся в клиентские 33600. Для вышеупомянутого "окна" существует механизм регулирования в зависимости от скорости в канале передачи.
 
Очередь большой не делается, а делается она исходя из некоей статистики, собранной за предыдущее время - так сервер пытается понять, с какой скоростью и какого размера пакеты вы успеваете прокачивать. А вот если попадется такая ситуация, что половину из пакетов стоящих в очереди вы приняли, а на следующем пакете получился облом (ну не принялся он...). Что произойдет с остальными пакетами стоящими в очереди? Они благополучно умрут, т.к. на сервер от вас пойдет команда перепослать пакеты с номера такого-то, начиная с того места, где произошел обрыв, а эти пакеты бросят умирать.
 
Подводя итог, можно сказать, что скорость выкачки зависит: от того, насколько быстро приходят пакеты к вам, от того, насколько быстро доходят от вас подтверждения на них другому серверу. Следовательно, если на канале "висит" много пользователей и особенно таких, у которых скорость выше чем у вас, то их пакеты будут  ходить чаще (у них ведь время ответа будет меньше), и следовательно, ваши пакеты могут не успевать проскакивать между потоком их пакетов и будут тормоза. Что и можно наблюдать на загруженных серверах или каналах. Пробки как раз и возникают таким образом - стоит пакетам скопиться где-нибудь и - все. Особенно, если из-за этого маршрутизатором будет сброшен какой-нибудь пакет соединения, тогда приемник (ваша тачка) подождет еще некоторое время (таймаут) в надежде дождаться отброшенного пакета, и только после этого пошлет запрос передатчику на перепосылку утерянного пакета.


из номера за 24 декабря 1998

Сисадминские байки. из склепа :)

Вся системная кухня работы DNS серверов и взаимодействия между ними (и с ними) считается достаточно сложной, пожалуй самой сложной после работы систем нижнего уровня по передаче пакетов IP. Постараюсь немного раскрыть некоторые особенности работы всей системы domain name service (DNS) с точки зрения конечного пользователя - сервера провайдера. (хотя, кстати, DNS сервер провайдера, в принципе, от корневого DNS сервера ничем не отличается) Ранее я объяснял некоторые вещи со стороны юзера, но вот....
 
Начем, разумеется, с начала. Допустим вы хотите получить настоящее имя (типа some.isp.ru), которое будет известно всем. Первое: вы его можете получить у вашего провайдера. Тогда у вас получится нечто типа <ваше_имя>.<имя_домена_провайдера>.ru. Например: cooler.irk.ru. Ведь, хозяином домена второго уровня (irk.) является провайдер и он вправе раздавать домены третьего уровня (своего) всем кому пожелает. Так что получить имя домена <cooler> несложно. А вот если мы хотим получить домен второго уровня? Ну... чтоб было. :))
 
Например, хотим www.domen.ru. Очевидно, нам по аналогии нужно спросить хозяина домена верхнего уровня, т.е. <.ru>. Этим доменом владеет компания РосНИИРОС  -  она же и занимается регистрацией доменов второго уровня в России. Причем, компания владеет такими популярными (черт знает с какой точки зрения) доменами второго уровня как .COM.RU, .ORG.RU, .NET.RU, .EDU.RU, .PP.RU, .AC.RU и тд. Поэтому, если вы захотите иметь домен типа dars.com.ru - то, опять же - к владельцу домена <.com.ru> (которым опять таки является РосНИИРОС).
 
Ага, но ведь  неплохо бы для начала получить свой IP адресок. Без него-то вообще, никак. А еще лучше - сетку адресов. Чтоб можно было подсети делать. Или свои поддомены раздавать под этими адресами. Сетка IP адресов получается там же - в www.ripn.net. Кстати, за нее тоже деньги хорошие нужно платить.
 
Ладно, ок, у нас есть  свой уникальный IP адрес. Теперь, мы хотим, чтобы человек, набрав www.domen.ru попал к нам на сервер (вернее, скажем, чтобы ему вернулся правильный IP адрес в ответ на это имя). Естественно, нужно прописать имя domen (кстати, имя domen еще свободно :)) в DNS серверах. Это произойдет после того, как РосНИИРОС зарегистрирует это имя. Для этого, нужно сначала по крайней мере в двух различных серверах DNS (первичном и вторичном, причем, эти сервера должны находиться в разных IP сетях) прописать (пока,  наперед, так сказать) свое соответсвие IP адреса и имени. После этого послать заявку и... все. Собственно, это и есть кратко описанный путь регистрации своего домена второго уровня. Да, чуть не забыл: еще денежку надо заплатить :))
Т.е. простыми словами говоря, ведущему зоны (.ru) сообщается, где будет находиться зона .domen. И тогда он делегирует вашему DNS серверу полномочия на преобразования имен с вашим доменом второго уровня. Ну, например, кто-то полез спрашивать "а гдей-то у нас находится адрес site.domen.ru?" А ему будет говориться - а вон, лезь-ка на сам .domen.ru - он тебе все и расскажет.

Записи соответствий (имен и IP адресов) на серверах DNS имеют много различных служебных  полей. Одним из них является поле "обновление". Оно указывает, через какое время нужно спросить вышестоящий (или другой) DNS сервер о соответствии имени и IP конкретного адреса и обновить его у себя.
О! Это я уже про кэш для DNS рассказываю. Ладно, пусть будет кэш. На самом деле, кэш у провайдера играет двойственную роль. Во-первых, это конечно, база данных каких-то записей соответствия имен, которые например, провайдер раздал своим пользователям. Например, мой домен третьего уровня cooler - он ведь только у провайдера хранится. А во-вторых, это собственно, кэш, для того, чтобы каждый раз не заставлять юзера ждать поиска имени далекого сервера, а сразу выдать ему готовое соответствие IP адресу. Конечно, там ведется статистика наиболее частоупотребимых имен и при случае переполнения DNS кэша, удаляться будут самые редкоупотребляемые. Известно, что DNS сервера общаются между собой по протоколу UDP (user datagram protocol). В отличие от TCP протокола, он не требует ответа на посланный пакет. (udp используется, где надо небольшие порции информации передавать не очень часто, просто кинул датаграмму и все, и не надо предварительно обмениваться пакетами для установления tcp сессии). Посылая друг другу запросы по цепочке для прямого или обратного преобразования имени, они в конце концов добираются до сервера, который содержит запись о нем.

Например, кроме сервера .irk.ru никто больше не знает о существовании домена третьего уровня "cooler". (Ну, еще правда могут знать вторичные DNS сервера, которые может заводить даже сам пользователь для того, чтобы каждый раз не лазить за именами в сеть). Таким образом, за домены уровней от 3-го отвечают какие-то отдельные сервера. Ну про это я уже писал.
 
Но я вот к чему клоню. Представьте, что если один сервер отослал другому запрос на расшифровку имени, а у того точно она (расшифровка) есть и он должен был возвратить ее запрашиваемому серверу, но вот взял, да не отресолвил его, а отослал этот запрос обратно, типа, разбирайся мол, сам. А тот обратно ему ( "твои уровни - сам и разбирайся...") Таким образом, возникает петля пересылок, называемая еще DNS storm (DNS шторм), которая растет как снежный ком, потому как общаются DNS сервера по протоколу UDP, который не предусматривает подтверждения на пакеты. И после того, как сервера напосылавшись запросов друг другу и устав ждать ответа на них, начинают слать еще и дополнительные запросы (типа - "ну ты там спишь, что ли?! - давай, ресолви мне адрес!"), тут-то все и начинается! Любой канал грузится по-черному.
 
После того, как сисадмины разберутся со своими серверами и кое-чего там поправят, нужно еще немного ждать, пока пакеты не прекратят хождение (ну много их, и в очереди они пока стоят!) и канал не разгрузится. Короче, пока шторм не уляжется :)) Такая коллизия кстати, имела место в действительности у одного суб-провайдера, который неправильно настроил свой DNS сервер (хотя он должен был ресолвить свои имена сам, а он вместо этого поставил forward на DNS сервер своего провайдера).
 
Мда... ну и напоследок: домен третьего уровня ваш провайдер просто обязан вам его у себя зарегистрировать, да еще и бесплатно. Сразу же оговорюсь: только если домен у провайдера подпадает под географическое название. Т.е. например irk.ru - похож на "Иркутск", поэтому они зарубать такие просьбы не должны. А уж домен irkutsk.ru и подавно должен вам пойти навстречу... Это условие при регистрации доменов второго уровня такое, и провайдер  его прекрасно знает :))

Что характерно, что .com .org .net получить куда проще, дешевле и быстрее, чем .ru

 


из номера за 10 марта 1999

Сисадминские байки.

Итак, что происходит, когда адрес какого-либо ресурса, необходимого Вам, меняется, скажем так, скоропостижно, или как там модно выражаться ... "аксидентально" (во! Кайф :))

Нда, ну так вот, для конкретизации, скажем, вы ходили на адрес cooler.irk.ru, у которого был реальный IP адрес 195.206.40.162 (скажем, журнал сидел на таком адресе, но не имел его - я бы разграничил эти понятия), а коварный сисадмин (чисто из желания насолить вам) взял и поменял его на 195.206.40.164. Детально: он взял, и из списка адресов на сервере, удалил строчку типа: cooler.irk.ru = 195.206.40.162, и поставил заместо нее - cooler.irk.ru = 195.206.40.164.
И когда Вы (вы - далеко) набрали строчку в браузере http://cooler.irk.ru, нажали Enter, что получили:
1. Браузер, видя, что ему в строке URL написали не циферку, посылает запрос на сервер вашего провайдера с просьбой дать ему нормальный IP адрес, чтобы было куда ломиться (как я уже раньше писал - эти запросы вы можете наблюдать в строке состояния NN как "Looking up host:такой-то").
2. Серверу провайдера пришел запрос от вашей тачки на прямое преобразование имени. У уважающего себя провайдера есть DNS кэш, который является неотъемлимой частью DNS сервера. Про DNS сервер и работу провайдера с DNS я уже байки рассказывал. Ну и, DNS сервер, не будь дурак, смотрит сначала в свой кэш, естественно, находит там запись cooler.irk.ru, и его соответствие (старое) - 195.206.40.162 и отсылает вашему браузеру.
3. Браузер, получив циферку (смена строчки состояния на "Contacting to host такой-то"), посылает пакет на машину с номером в сети 195.206.40.162 (т.е. на dsi.ru) с запросом типа "дай ресурс". Вместе с пакетом внутри уходит и обычный адрес (cooler.irk.ru) - это делается всегда, кстати. Сервер dsi.ru не забывает конечно отправить подтверждение на приемку TCP пакета "все понял, бжи, счас я тут разберусь" - и у вашего браузера строчка меняется на "Contacted, waiting for reply".
4. Все было бы просто. Если бы не...
Так как адрес 195.206.40.162 у моего провайдера является адресом множества виртуальных серверов (а их у dsi.ru крутится на юниксе около 50-ти, простыми словами говоря, адрес 195.206.40.162 имеют несколько доменов 3-го уровня, принадлежащих dsi.ru), то необходимо как-то просекать, что же именно хотят "снаружи", когда запрашивают что-либо именно с адреса 195.206.40.162. Для этого, на сервере (и на любой нормальной web-системе), существует специальный конфигурационный файл, где прописано, ресурс какой именно директории на диске отдавать "наружу". В этом как раз и помогает имя ресурса, которое идет вместе с пакетиком на сервер, т.е. например, cooler.irk.ru.
А вот если вы запросите то, чего не существует по адресу 195.206.40.162, что делать? Конечно, просто так "запросить" то, "чего не существует", не удастся, так как набрав типа lkjhfg.dsi.ru, вы получите grand-облом в виде несуществующего адреса. А если мы представим, что в пакете, который уйдет на dsi.ru, мы подправим имя ресурса на неправильное? Т.е. IP будет верным, а имя будет, ну, совершенно левым.
Но и такая ситуация обрабатывается сервером. У него есть список всех ресурсов, висящих на одном и том же IP адресе, т.е. на 195.206.40.162. Он проверит их все на совпадение и если нужного не окажется, он перебросит вас (ну не вас конечно, это я для простоты :)) на ресурс по умолчанию. На любой, какой пропишет сисадмин (ну, который коварный :)). Он прописал www.dsi.ru. И (еще раз повторю) убрал мою строчку cooler.irk.ru = 195.206.40.162 как раз из этого списка. Поэтому, cooler.irk.ru и считался неправильным на то время.
Но прописал другую cooler.irk.ru = 195.206.40.164.
И если раньше до моего журнала нельзя было добраться написав в браузере прямой IP адрес (195.206.40.162), то теперь можно, так как cooler оккупирует единолично адрес 195.206.40.164.
Вот, поэтому-то, пока DNS не обновился, все (кстати, вот в штатах обновился почему-то быстрее, чем на некоторых серверах в России, видимо, из-за различий в настройках DNS серверов провайдеров) те, кто видел сервер dsi.ru вместо cooler.irk.ru, как раз имели необновленный кэш DNS сервера своего провайдера. Спустя некоторое время (максимум 24 часа) DNS-изменения разошлись по всем серверам.

Постлюдия (не, ну есть же слово "прелюдия" :).
Зачем это было сделано? На самом деле, сисадмин вовсе и не собирался вас злить, он, если к нему вовремя подкатить с бутылкой (колы, например), оказывается добрейшей души человеком :))
Нужен был собственный ftp сервис для журнала. Удобно чтоб софт и mp3 качать было. Конечно, можно было обойтись и обычным ftp на ftp.irk.ru, но провайдеру необходимо как-то ограничить число одновременных ftp-соединений. Как разграничить именно ftp клиентов желающих ftp.irk.ru и клиентов, желающих ftp://cooler.irk.ru? Ftp сервер-то - один и тот же. И к тому же, anonymous соединениям нужно давать какую-то initial директорию. Во!
Поэтому, удобно дать ftp://cooler.irk.ru отдельный адрес, по этому адресу завести своего ftpd (pro ftpd), и у него уже поставить и ограничение на 10 пользователей (т.е. в одно и то же время, с сервером 195.206.40.164 по протоколу ftp могут соединиться не более 10 пользователей), и раздавать различные директории на разные имена. Например в файле конфигурации proftpd прописано, что пользователь, ломящийся на 195.206.40.164 по порту 21 (порт команд ftp) с именем mp3 и паролем mp3 должен получать IP пакетики из директории /MP3/ и chdir вверх сделать не сможет, ну и так далее, по запросам.

Вот, примерно такая кухня. За что поем мы песню сисадмину, отдаем салюты, несем тару и т.п.
Кстати, то что я описал, применимо к абсолютному большинству провайдеров на Руси, так что у Вас кухня примерно та же, можете не сомневаться.

При создании статьи был упоен напрочь сисадмин www.dsi.ru Макс.
Так что, если есть сугубо технические вопросы по существу - то это к нему


из номера за 23 ноября 1999

Сисадминские байки

 

Хочу немного поговорить на тему "глобальный трафик". Вот конечный пользователь подсоединен к провайдеру линией скажем, 33.6kbps. Провайдер, в свою очередь, подсоединен (имеет канал, скажем 2Мб) куда-то дальше - может быть, к другому провайдеру - более крупному. А вот где кончается эта цепочка - есть ли самый главный и самый большой провайдер?

Это я так специально вопрос поставил...

"Самого-самого" нет в таком смысле, в котором привычно было бы представить обычного провайдера. Есть компании-владельцы толстых каналов, по которым ездит не только интернет. Телефония, например, занимает очень даже большой трафик. Держатели каналов, разумеется, их продают как транспорт различным компаниям, уже конкретно занимающихся провайдерством. А то и сами вполне могут предоставлять интернет-услуги.

Каналов по миру очень много. Оптика, медь, спутники. В интернете есть даже специальный сервер, где можно поглядеть на глобальные карты телекоммуникаций по планете. И даже заказать себе на стенку в виде большой полиграфии :)

Но как-то же в начале это все организовывалось? Кто-то доминировал?

На примере страны, откуда это все и начиналось: - да, в начале было много мелких ISP и было две крупных точки обмена трафиком - MAE East и MAE West на западном и на восточном побережье. Мелкиие ISP туда коннектились и работали себе. А потом интернет стал настолько большим, что 100Мбитной сетки на MAEWest/East стало нехватать - появились более крупные компании со множеством коммуникаций и пропускной способностью на порядки выше. MAEWest & MAEEast существуют и по сей день, но там стоят такие тормоза, что все основные провайдеры имеют свои точки обмена трафиком, минуя "третьи" каналы.

Вот. Мы подошли к понятию "обмен трафиком" - т.е. пиринг (peering). Возьмем что-нибудь поглобальней. На примере той же страны.

Допустим, у Sprint'a (провайдер) на UUNET (тоже провайдер) в Лос-Анжелесе идет 10000Гб в день, а соединены они с UUNET'ом только в Нью-Йорке, т.е. чтобы из Спринта попасть в UUNET, трафик должен идти через всю страну, занимая дорогие магистральные каналы. Которые, между прочим, стоят больших денег и которые тот же Sprint мог бы занять, к примеру, междугородными телефонными разговорами.

Напрашивается решение - а какого черта так гонять трафик через всю страну? Спринт идет к UUNET и говорит:
"- вот тут у нас к вам 10000Гбайт в день из Лос-Анжелеса идет, давайте мы с вами где-нибудь соединимся, чтобы все эти гигабайты не гонять туда- сюда?"

UUNET смотрит - "О! а у нас к вам едет 50000Гбайт в день - вот здорово, и мы не будем их гонять туда-сюда!"

И они соединяются отдельным каналом. Называется это private peering. Т.е. полностью только свой обмен внутренним трафиком между провайдерами.

А вот, предположим, какой-нибудь Джон Смит со своей сетюшкой, где-нибудь в Айдахо приходит в UUNET и говорит: " - у меня к вам трафика много, давайте я с вами пириться буду?"
Что ему UUNET скажет? Правильно - иди дядя отсюда. Вот когда у тебя будет сетка по стране со многими точками обмена, тогда приходи, тогда поговорим. А хочешь сейчас - пожалуйста - покупай линию на 625Мб и гоняй свой трафик.

Почему так? А потому, что UUNET в данном случае невыгодно было принимать чужой трафик просто так - к нему-то из UUNET ничего не шло. Вернее, не нагружало uunet.

Или на примере городских провайдеров - вот допустим, в городе есть три разных провайдера, которые все уходят своими каналами куда-то "наружу". Так как и между ними будет трафик - его тоже невыгодно гонять по своим каналам через "далекие" страны и города. Они встречаются, договариваются о пиринге, ставят где-либо маршрутизатор, все к нему подключаются и хэвают фан, так сказать. Теперь запросы с одного провайдера к другому бегают по этому каналу - напрямую через этот маршрутизатор, а не занимают дорогие каналы "наружу". Так вот, кто-то еще решил заняться провайдерством, приходит на эту точку пиринга и говорит - хочу подключиться прямо в этот маршрутизатор. Что он поимеет? Он поимеет доступ к внутренним сетям этих трех провайдеров, а вот"наружу" его никто не пустит (хотя в принципе, конечно, могут). Ему даже, скорее всего, и подключиться не дадут - трафика-то к нему никакого. Провайдеры занимаются продажей трафика - они ему его и предложат - как обычному пользователю. Зачем им терять клиента? :))

..продолжение будет.

в создании статьи
принял участие blib

 


из номера за 23 февраля 2000

 

Сисадминские байки

Поговорить на тему NAT (network address translation) меня натолкнуло письмо одного из читателей, который недоумевал по поводу условностей, выставленных каким-то провайдером (дам ссылку, дабы можно было почитать в оригинале).

Итак, основная идея о том, можно ли однозначно узнать - использует ли клиентская машина роутер для локальной сети, т.е. типа WinGate, Winroute (или даже Linux IP Masquerading) или нет? Для этого, разберем работу приложений, использующих сетевые соединения. Для пояснения я приведу упрощенный рисунок для сетей класса С (они имеют IP адреса с 192.168.0.0 до 192.168.255.255) - такие адреса зарезервированы для внутренних локальных сетей и в открытом доступе их нет.

NAT

Для того, чтобы они могли как-то взаимодействовать с внешними сетями, необходима маршрутизация с трансляцией адреса. Т.е. грубо говоря, адрес 192.168.0.1 наружу не выпустишь - его нет в глобальных таблицах роутинга - никто не знает, где такой находится. Поэтому, придумали программные трансляторы сетевых адресов (NAT). На рисунке показана машина, имеющая реальный сетевой адрес (195.206.40.73), который "виден" в интернете - вот с него уже можно посылать и принимать пакеты. Все локальные тачки подключены к этой "основной" машине, на которой крутится какой-либо роутер (например, Wingate или Winroute, да или вообще, юникс). Что делает маршрутизатор: он принимает пакет от локальной машины и смотрит, куда этот пакет направлен - по какому адресу (и порту). Рассмотрим случай, когда необходимо пакет перенаправить "наружу". В этом случае, роутер как раз и должен сделать трансляцию адреса. Он запомнит локальный адрес машины с портом, который откроется на запрос соединения с удаленным ресурсом. Проще говоря, вместо запроса от 192.168.0.4:80 - (т.е. хотим получить http с машины №2) на основном компьютере будет устанавливаться соединение к примеру 195.206.40.73:3000 (в протоколе TCP порты используются для связи с прикладными процессами, адрес каждой из оконечных точек включает IP-адрес [номер сети и номер компьютера] и номер порта) - и будет это соединение запрашивать addr2:port (например какой-нибудь сайт в интернете, порт в этом случае известен - 80). У роутера лежит сопоставление адреса 192.168.0.4:80 локально открытому порту 3000 (со своим адресом 195.206.40.73) - т.е. роутер держит в течении сеанса связи это свое сопоставление. (на самом деле, роутер запоминает не 192.168.0.4:80, а 192.168.0.4:[другой порт] - как понимаете, так же как и всегда для связи процессов адресом больше 1024 - для простоты я написал 80).

Так вот, так как все внутреннее программное обеспечение основного компьютера тоже может быть завязано на этот программный роутер или открывать свои каналы связи и однозначно узнать, какая программа инициировала установку соединения, не представляется возможным. Практически, используя какие-либо "дыры" в программном обеспечении, что-то узнать можно. Например, Wingate оставляет открытым 23 порт (телнет) и честно приветствует зашедшего "привет, я - wingate". Но это совершенно частная ситуация - и даже она ничего не дает - может человек только прокси поставил "чисто для себя"?


из номера за 15 апреля 2000

 

Сисадминские байки

Порассуждаю немного на предмет протокола обмена на самом нижнем уровне в локальных сетях.

Сетевые взаимодействия разбиты на семь уровней, для каждого из которых определены стандартные функции. Уровни эти следующие: физический уровень - он работает с передачей информации по физическим каналам (коаксиальный кабель, витая пара, оптика). На этом уровне определяются характеристики среды передачи данных и параметры электрических сигналов. Следующие: канальный уровень, сетевой уровень, транспортный уровень, сеансовый уровень, уровень представления (данных) и прикладной уровень.

Все эти уровни описывает модель взаимодействия открытых систем (Open Systems Interconnection - OSI, разработана ISO).

Здесь я рассмотрю именно физический уровень для локальных сетей.

В самом деле, как сетевые карточки, зацепленные на один кабель (пусть даже и на витой паре) узнают, когда посылать пакет, а когда подождать, чтобы не выставлять сигнал в канале, мешая другим карточкам? (Я сразу оговорюсь, что все нижесказанное относится к локальным сетям. Для передачи данных на очень большие расстояния применяются несколько другие протоколы).

Кстати сказать, сам стандарт IEEE 802.3 содержит несколько спецификаций, описывающих топологию и тип используемого кабеля. Например, 10BASE-5 использует толстый коаксиальный кабель, 10BASE-2 - тонкий, 10BASE-F, -FB, -FL и FOIRL - оптический кабель. Наиболее популярна спецификация 10BASE-T, в которой для организации сети используется кабель на основе кабелей типа "витая пара". Хочу заметить, что название 802.3 произошло исторически вот как - в 1980 году IEEE (Institute of Electrical and Electronics Engineers) образовал рабочую группу, имя которой дал по названию года и месяца (февраль), а 3 - это обозначение подкомитета, который, как раз и стандартизовал CSMA/CD.

Стандарт CSMA/CD (множественный доступ к среде с детектированием несущей и обнаружением конфликтов) описывает то, каким образом Ethernet протокол должен регулировать обмен пакетами между сетевыми устройствами. Так, при использовании одного кабеля (с применением витой пары та же история, - там существуют хабы, которые являются повторителями) посылка пакета от одной станции к другой является своего рода броадкастом (broadcast), т.е. его будут вынуждены принять все станции, находящиеся на этой ветке. Взаимодействие со средой передачи происходит как бы монопольно. Т.е. только одна станция может передавать в одно время.

Как именно CSMA/CD регулирует посылки пакетов по одному каналу? Допустим, карточка хочет послать пакет в сеть - сначала она должна "послушать" канал на наличие несущей - а вдруг кто-то уже передает что-то? Тогда надо подождать. Когда канал становится свободен от несущей, карточка ждет случайное количество времени и начинает передачу (поднимает несущую).
Обратите внимание на слова "случайное количество времени". Это очень важная часть нижнего уровня протокола.

Очень резонно будет заметить, что при окончании передачи, сразу два (или более) сетевых устройства [почти] одновременно могут начать посылать свои пакеты. Эта ситуация называется коллизией. Как быть? Вот как раз, случайный промежуток времени не дает зациклиться передающим карточам - исключает бесконечную (вернее, очень долгую) коллизию. А как узнать, что при передаче произошла коллизия? Во время передачи своего пакета, станция "слушает" канал - и если свой пакет окажется испорченным, значит передачу надо повторить, подождав какое-то количество времени. Когда карточек на одном сегменте много, коллизии могут происходить достаточно часто - уже существует большая вероятность, что сразу несколько карточек могут начать передачу [почти] в одно и то же время. Кстати, на всякого рода хабах, коммутаторах существует индикация коллизий. Если таковые происходят слишком часто - видимо, следует пересмотреть количество станций в сегменте. Ну, и, разумеется, карточка всегда "слушает" канал - все пакеты надо принимать - а вдруг там окажется нужный? :) С разборкой самих пакетов уже разбираются верхние уровни - канальный и сетевой.Например, к сетевому уровню относится протокол TCP/IP.

 



 Пишите! Мне интересно будет Ваше мнение, замечания и пожелания. Указывайте в письме НЕсогласие на опубликование. Если ничего не будет указано - публикую по своему усмотрению. Если письмо не личное, конечно...

Журнал поддерживается ISP Деловая Сеть Иркутск