UNИX, осень 2008, 11 лекция (от 10 декабря)

Материал из eSyr's wiki.

Артём Гавриченков. Заканчивание рассказа про DNs.

Как устроен резолвинг доменных имён. Есть некоторый список корневых серверов (официально, 11), есть ряд доменов первого уровня, это нац. домены (ru, us, fr, tv) и домены общего назначения (com, org, name). Далее есть второго уровня и так далее.

Также мы успели поговорить, что во время резолвинга запрашиваем запись опр. типа (напримеР, если по имени неолбх. получить IP адрес), один из трёх типов записей: A (IPv4), AAAA (IPv6), A6 (IPv6, deprecated). Помимо этого есть ряд других типов записей: MX (лответственный за почту домен; за счёт этого работает доменная служба гугла: она обр. к серверу и смотрит на mx-запись, а она должна указывать на гугл), SRV (запись для серверов. умеет то же, что и mx, но для любого сервиса). Помимо этого, есть записи типа CNAME и PTR. Что такое cname: предположим, есть какой-то такой сервер, например, uneex.ru, и хочется разместить ftp-сервер с доменным именем ftp.uneex.ru, но второй сервер мы не хотим заводить, поэтому мы пишем CNAME и в нём указываем домен, на который надо смотреть. Есть ещё DNAME, он для зоны.

Когда маленькие пушистые зверьки с альдебарана были маленькими и пушистыми, был /etc/hosts, у которого был очень простой формат. Очень легко командой grep искалось не олько соответствие имени зосту, но и хоста имени. На основе этого даже работала кое-какая диагностика. В году так 94, когда dns работал в полную силу, так, как сейчас, кто-то подсчитал, что уже в 94 году таким же обращом получить ip из системы dns хотя бы только по адр. типа A, делаем след. образом: пойти на первый попавшийся зост, посмотреть у него, пойти на след. и так далее. Понятно, что это долго. Поэтому была придумана запись PTR.

Допустим, есть след. схема: Есть маршрутизатор, который маршрутизирует 192.x.x.x, далее есть марш., марш. 192.168.x.x, и так далее. Можно заметить, что деревья похожи. Собственно, их в RFC и объединили: ввели домен arpa, там поддомен in-addr, и далее ip: таким образом адрес 192.168.1.3 будет выглядить так: доменное имя строится от листа к корню (mirror.yandex.ru), таким же оббразом будем передавать записи типа PTR: 3.1.168.192.in-addr.arpa. Таким обр. очень просто получить имя хоста по имени. Кроме того, в RFC было записано, что для любого внешнего IP должна быть запись вида PTR. На самом еле это не выполняетсмя ни разу.

И так сложилась жизнь, что благодаря этому сложилась возм. для фильтрации спама --- если приходит письмо с адреса, у которого нет PTR.

Ещё бывает Forward Confirmed Reverse DNS. Вот пришёл нам пакет с некоего адреса. По ptr получаем dns, по a получаем ip. Тогда это FCRDNS, если ip совпали. Только если это проходит, от хоста можно получать почту, иначе можно спокойно фильтровать, так как это хост, пор который провайдер не знает, что с него ходит почта. Т. о., помимо нач. цели, которой служил RDNS --- диагностика неполадок сети, появился второй пример использования --- проверка хоста на валидность.

Всё это хорошо, красиво и прекрасно было, пока не началось ipv6 заканчиваться. После чего начали раздавать не большие подсети, а поменьше. И тогда появилась сложность. Поскольку такая ситуация: нам выдали подсети из одной подсети C, в результате DNS один, а претендуют на него двое. После чего была придумана такая вещь: всесто записи типа PTR будет ыдаваться типа CNAME, и CNAME вида 1.corbin1.1.168.192 (для ip 192.168.1.1).

Почему в ipv6 всё лучше: там не делегируются подсети меньше /64. Но при этом ращмер гранулирования --- полубайт: ...a.8.0.b.c.f.ip6.arpa.

Про whois.

Адреса и подсети выдаются не абы каму. Для каждого владельца адреса существует инф. о нём (или о провайдере, который его выдал динамически). Сущ. сервис, который позв. выдать эту инф. для любого заданного адреса. Есть утилита whois и http://ripe.net. Можно запросить инф. о владельце адреса, о его конт. данныз, адпресе орг. и так далее.

Whois может исп. не только для получ. данных об ip, но и об доменном имени. Это работает.

Павел. Рассказывает, потому что напросился, а Гоша разрешил.

Рассказывать парсер будет про RPC, и ему кажет, что он знает про rpc больше, чем некоторые из нас.

В википедии написано, что RPC позв. вызывать функции в другом адр. пространстве, но это ни о чём не говорит.

О цонцепции: Необх. в RPC возн. по нес. причинам

• Когда она возн. (в 70-х годах, когда был бум произв. машин, но в расп. сисит. есть компьютеры послоабже, посильнее, и кусок посложнее было бы круто считать на мощной машине)
• Рещшение задачи разд. ресурсов: принтеры, файлы, whatever

Если вспомнить как пишется каноническое сетевое прилож с беркли сокетами, то это дост. рутинная операция.

На самом деле, RPC как класс технологий, стандарта RPC нет, и каждый горазд созд. их сколько угодно, и их довольно меого, не все созд. вещи плохи.

Open Network Communication RPC, кноничный RPC, про который есть RFC.

Как обычно, разраб. раньше, чем проектировался. И делать его начали для того, чтобы реализовывать NFS. Идея появлиась в 76 году, есть RFC 707. В заголовке рфц заложено, что главное в нём --- разд. ресурсов. В 86 была реализ. от сана, а в 88 было RFC. Вторая версия появилась в 95 году. Наверное, стоит рассм. с прогр. точки зрения, чем удалённый вызов отл. от локального.

Как осущ. лок: у нас есть общеизв. место, через которое передаём параметры, и откуда рез. получаем (стек, регистры, память), дальше произв. пляска, в стек запис. параметры, точка возщвр. и так далее, всё это известно, поск. вып. в одном адр. пр-ве. И что делать в случае своего адр. пр-ва? Можно отобрадать, но это бред. Пожтому жёстко сказано, что всё предаётся по значеннию.

В связи с c RPC есть два RFC : 1831, который опр. транспорт, и ...., который опр. формат данных.

Почему так многор елази RPC: RFC? RJNJHSQ DJPV/ ZDK/ CNFYLFHNJV? UB,RBQ? YT YFRK/ JUHFYBXTYBQ? RFYJYBX HTFKBP ---вызов синхронный. RFC не говорито то том, что это нужно делать синхронно, и все совр. реализ. асинхронны. Понятно, в чём проблема синхр. вызова: вызвали и ждём --- или ждём, или аовторно дёргаем, но тогда непонятно, сколько раз она выполнена. Поэтому некие минимальные огр. на ранспорт нлаагаются, в част. сопост. ответа с запросом.

Как это работает: тобы вызвать на уд. зосте уд. функцию, нам нужно её идент: поэтому в RPC есть три беззн. значения --- номер программы, функции и версии. Тут интересно то, что номера возн. из бухты-барахзты, а ими заведует тот же sun. Если вы написали программу и хотите, тобы все о неё знали, то нужно написать e-mail на rpc@sun.com и сказать об этом.

Про утилиты, которые можно непоср. использовать: самая главная утилита --- rpcinfo. Он позв. обр. к серверу, на котором есть прогр., которая исп. уд. вызов процедур, и получать с него информацию. -p --- опц. указывается имя хоста, по этой команже клиент подкл. к уд. серверу, запр. множество программ, по этим программам выд. функции которые униз есть с версиями и именами. бычно там можно увдиеть nfs.

Каким обр. мы соед. с уд. сервером: понятно, что rpcinfo соед. по какому-то порту. По какому? Можно догоовртиься, что исп. такой-то порт, поэтому порту rpc выделоен порт 111, где висит portmap, который и заведует всеми rpc-шными программами, и rpc-программы регистрируются в портмапе.

Третья часть доклада посвящена p2p, зовут дендика Алексеевский Даниил, и он имеет к этому некое косвенное отношение.

Дендик выбрал неск. конкретных протоколов, о которых стоит расск. боьшле всего.

Что такое p2p? Это общая идея, как можно расп. данные в сети. До этого все проотколы осн. на клиент-серверной парадигме. В коакой-то момент люди посмотрели на ситуацию с HTTP и увидели, что есть клиенты, которые с него пост. что-то спрашивают, весь трафик в итоге ходит через канал сервера и серверу приходится много платить за трафик. Но если клиентов много, то наверняка наёдтся тот, у которого данные уже есть. В этом и осн. идея.

p2p-сети бывают разные по своей расп., и дендик начнёт с классификации. Степени расп. бывают такие:

• Центр. сеть. Сеть, имеющ. центр. Сеть., расч. на то, что есть сервер, знает обо всех клиентах и у какого что есть. И когда приходит новый клиент, он спрашивает , где есть какой-то фалй
• Промежут. стадия
• Полностью децентр. Клиент как-то приходит в сеть, поиском по сети пытается найти, что ему нужно. Такие сети бывают постр. на разных алгоритмах, но ...

EDonkey. Обр. она неизв. когда. Как она устроена: по большей части это неизв, протокол закрытый, все реализ. протокола ..., есть смутное понятие сервера и клиента. Что творится между серверами, неизвестно. Клиенты есть двух типов: те клиенты, которые имеют возм. откр. соед. и слушать порт (High ID) и те, которые такой возм. не имеют (Low ID). Как происх. добыча данных из edonkey: во-первых, всякий файл ищется по его хэшу. Хэш исп. md4. Во вторых: чтобы получить файл, сервер занимается поиском, как --- неизв, в рез-те ответ ---- качай с сервера или с high id. Опять же неизв., могут ли серверы ретранслировать данные. Данные можно нарез. куски станд. аразмера --- примерно 10к, ходят с щэшом, можно получать распред. Некоотрым людям стало это в опр. момент не очень нравиться, и они стали докручивать это со стороны клиента. Например, держать у себя список клиентов и обмен. с соседями. В конце концов, нек. программы могут сущ. в таком режиме: получить списки клиентов и общ. только с клиентами, не тргая сервера. Но этоо опять таки чревато и неприятно, поск. это нестанд. расширения, по которому могут договориваться разве что два экз. одной программы. Ещё одна важная фишка6 в нём каким-то обр. реализ. поиск. на серверах, причём, судя по всему, поиска не было до первого неофиц. сервера.

Далее, для развития edonkey люди начали изобр. свои протоколы. Один из них --- Kademlia. В основе лежит DHT --- Ditributed Hash Table. В чём её суть: сначала надо договориться о таких понятиях, как ID --- имя машины, Key и Value. Договорённость первая --- это строки какой-то длины, и важно, что Id и ключи имеют равную длину. Мы опр. функцию, которая по двум id или по паре id-ключ умеет находить расстояние. На этих двух предположениях строится довольно простой способ, как искать данные в сети, про котрую изнач. почти ничего неизв: есть машины, с id, кажая машина хранит списки машин для кажлого бита, у которых отличие в id нач. с данного бита. Поиск стр. на 4 операциях: ping (проверить, что машина жива), store и find. Можно попросить машину зранить кусочек данных (если мы уже знаём её ip, порт). Поиск ведётся след. образом: для поиска снач. надо получить ключ, потом ищем по списку в каждом из конц. кругов, и в каждом уруге примерно один. количество соседей и подд. дост.ю надёжные. Снач. ищется во внкутр. круге, нахдоим ососеда и просим найти его соседа, самых близких к данному ключу, адльше для след. и так далее. Понятно, как теперь найти машину, на которой хранится заданная битовая строчка. Теперь понятно, как это работает.

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

Трекер умеет вып. тодлько одну операцию --- какие клиенты с этим файлом ещё есть, Обычно, на трекерах реализ. разные хитрые политики: ....

Bittorrent постоянно расширяется, и недавно запихали в него такую вещь, что некие клиенты сами явл. трекерами. И при этом поиск трекеров ведётся через DHT.