Редактирование: UNИX, осень 2008, 11 лекция (от 10 декабря)
Материал из eSyr's wiki.
Внимание: Вы не представились системе. Ваш IP-адрес будет записан в историю изменений этой страницы.
ПРЕДУПРЕЖДЕНИЕ: Длина этой страницы составляет 40 килобайт. Страницы, размер которых приближается к 32 КБ или превышает это значение, могут неверно отображаться в некоторых браузерах. Пожалуйста, рассмотрите вариант разбиения страницы на меньшие части.
Правка может быть отменена. Пожалуйста, просмотрите сравнение версий, чтобы убедиться, что это именно те изменения, которые вас интересуют, и нажмите «Записать страницу», чтобы изменения вступили в силу.
Текущая версия | Ваш текст | ||
Строка 10: | Строка 10: | ||
Помимо этого есть ряд других типов записей: MX (ответственный за почту домен; за счёт этого работает доменная служба гугла (Google DomainService): она обращается к серверу и смотрит на MX-запись, а она должна указывать на гугл), SRV (запись для серверов, умеет то же, что и MX, но для любого сервиса). | Помимо этого есть ряд других типов записей: MX (ответственный за почту домен; за счёт этого работает доменная служба гугла (Google DomainService): она обращается к серверу и смотрит на MX-запись, а она должна указывать на гугл), SRV (запись для серверов, умеет то же, что и MX, но для любого сервиса). | ||
Помимо этого, есть записи типа CNAME и PTR. | Помимо этого, есть записи типа CNAME и PTR. | ||
- | |||
- | === Запись CNAME === | ||
Что такое CNAME: предположим, есть какой-то такой сервер, например, uneex.ru, и хочется разместить ftp-сервер с доменным именем ftp.uneex.ru, но второй сервер мы не хотим заводить, поэтому мы пишем CNAME и в нём указываем домен, на который надо смотреть. | Что такое CNAME: предположим, есть какой-то такой сервер, например, uneex.ru, и хочется разместить ftp-сервер с доменным именем ftp.uneex.ru, но второй сервер мы не хотим заводить, поэтому мы пишем CNAME и в нём указываем домен, на который надо смотреть. | ||
Есть ещё DNAME, он для зоны. | Есть ещё DNAME, он для зоны. | ||
Строка 17: | Строка 15: | ||
=== Запись PTR === | === Запись PTR === | ||
- | Когда маленькие пушистые зверьки с Альдебарана были маленькими и пушистыми, был | + | Когда маленькие пушистые зверьки с Альдебарана были маленькими и пушистыми, был /etc/hosts, у которого был очень простой формат. |
Очень легко командой grep искалось не только соответствие имени хосту, но и хоста имени. | Очень легко командой grep искалось не только соответствие имени хосту, но и хоста имени. | ||
На основе этого даже работала кое-какая диагностика. | На основе этого даже работала кое-какая диагностика. | ||
- | |||
В году так 1994, когда DNS работал в полную силу (так, как сейчас), получить ip из системы dns хотя бы только по адресу типа A, можно было только следующим образом: пойти на первый попавшийся хост, посмотреть у него, пойти на след. и так далее. | В году так 1994, когда DNS работал в полную силу (так, как сейчас), получить ip из системы dns хотя бы только по адресу типа A, можно было только следующим образом: пойти на первый попавшийся хост, посмотреть у него, пойти на след. и так далее. | ||
Понятно, что это долго. | Понятно, что это долго. | ||
Строка 28: | Строка 25: | ||
Допустим, есть следующая схема: есть маршрутизатор, который маршрутизирует 192.x.x.x, далее есть маршрутизатор 192.168.x.x, и так далее. | Допустим, есть следующая схема: есть маршрутизатор, который маршрутизирует 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 и объединили: ввели домен arpa, там поддомен in-addr, и далее ip: таким образом адрес 192.168.1.3 будет выглядить так: доменное имя строится от листа к корню (mirror.yandex.ru), таким же образом будем передавать записи типа PTR: | + | |
- | + | ||
- | + | ||
Таким образом очень просто получить имя хоста по имени. | Таким образом очень просто получить имя хоста по имени. | ||
Кроме того, в RFC было записано, что для любого внешнего IP должна быть запись вида PTR. | Кроме того, в RFC было записано, что для любого внешнего IP должна быть запись вида PTR. | ||
На самом деле это выполняется не всегда. | На самом деле это выполняется не всегда. | ||
- | === Практическая польза от PTR === | ||
И так сложилась жизнь, что благодаря этому появилась возможность для фильтрации спама --- если приходит письмо с адреса, у которого нет PTR, высока вероятность, что это спам, фильтруем. | И так сложилась жизнь, что благодаря этому появилась возможность для фильтрации спама --- если приходит письмо с адреса, у которого нет PTR, высока вероятность, что это спам, фильтруем. | ||
Строка 43: | Строка 36: | ||
По PTR получаем dns, а по A получаем ip. | По PTR получаем dns, а по A получаем ip. | ||
Тогда это FCRDNS, если ip совпали. | Тогда это FCRDNS, если ip совпали. | ||
- | |||
Только если это проходит, от хоста можно получать почту, иначе можно спокойно фильтровать, так как это хост, про который провайдер не знает, что с него ходит почта. | Только если это проходит, от хоста можно получать почту, иначе можно спокойно фильтровать, так как это хост, про который провайдер не знает, что с него ходит почта. | ||
Таким образом, помимо начальной цели, которой служил RDNS --- диагностика неполадок сети, появился второй пример использования --- проверка хоста на валидность. | Таким образом, помимо начальной цели, которой служил RDNS --- диагностика неполадок сети, появился второй пример использования --- проверка хоста на валидность. | ||
- | === Ipv4 vs IPv6 === | ||
Всё это хорошо, красиво и прекрасно было, пока не началось ipv4 заканчиваться. | Всё это хорошо, красиво и прекрасно было, пока не началось ipv4 заканчиваться. | ||
После чего начали раздавать не большие подсети, а поменьше. | После чего начали раздавать не большие подсети, а поменьше. | ||
И тогда появилась сложность. | И тогда появилась сложность. | ||
Поскольку такая ситуация: нам выдали подсети из одной подсети C, в результате DNS один, а претендуют на него двое. | Поскольку такая ситуация: нам выдали подсети из одной подсети C, в результате DNS один, а претендуют на него двое. | ||
- | После чего была придумана такая вещь: | + | После чего была придумана такая вещь: всесто записи типа PTR будет выдаваться типа CNAME, и CNAME вида 1.corbin1.1.168.192 (для ip 192.168.1.1). |
- | + | ||
Почему в ipv6 всё лучше: там не делегируются подсети меньше /64. | Почему в ipv6 всё лучше: там не делегируются подсети меньше /64. | ||
- | Но при этом размер гранулирования --- полубайт: | + | Но при этом размер гранулирования --- полубайт: ...a.8.0.b.c.f.ip6.arpa. |
- | + | ||
- | == Про Whois == | + | == Про Whois. == |
Адреса и подсети выдаются не абы каму. | Адреса и подсети выдаются не абы каму. | ||
Для каждого владельца адреса существует информация о нём (или о провайдере, который его выдал динамически). | Для каждого владельца адреса существует информация о нём (или о провайдере, который его выдал динамически). | ||
Существует сервис, который позволяет выдать эту информацию для любого заданного адреса. | Существует сервис, который позволяет выдать эту информацию для любого заданного адреса. | ||
- | Есть утилита | + | Есть утилита whois и http://ripe.net. |
Можно запросить информацию о владельце адреса, о его контактных данных, адресе организации и так далее. | Можно запросить информацию о владельце адреса, о его контактных данных, адресе организации и так далее. | ||
- | + | Whois может использоваться не только для получения данных об ip, но и о доменном имени. | |
Это работает. | Это работает. | ||
Строка 95: | Строка 84: | ||
И делать его начали для того, чтобы реализовывать NFS. | И делать его начали для того, чтобы реализовывать NFS. | ||
Идея появилась в 76 году, есть RFC 707. | Идея появилась в 76 году, есть RFC 707. | ||
- | В заголовке | + | В заголовке рфц заложено, что главное в нём --- разделение ресурсов. |
- | В 86 была реализация от | + | В 86 была реализация от сана, а в 88 было RFC. |
Вторая версия появилась в 95 году. | Вторая версия появилась в 95 году. | ||
- | |||
Наверное, стоит рассмотреть с программистской точки зрения, чем удалённый вызов отличается от локального. | Наверное, стоит рассмотреть с программистской точки зрения, чем удалённый вызов отличается от локального. | ||
Как осуществляется локальный вызов: у нас есть общеизвестное место, через которое передаём параметры, и откуда получаем результат (стек, регистры, память), дальше производится пляска, в стек записываются параметры, точка возврата и так далее, всё это известно, поскольку выполняется в одном адресном пространстве. | Как осуществляется локальный вызов: у нас есть общеизвестное место, через которое передаём параметры, и откуда получаем результат (стек, регистры, память), дальше производится пляска, в стек записываются параметры, точка возврата и так далее, всё это известно, поскольку выполняется в одном адресном пространстве. | ||
- | И что делать в случае | + | И что делать в случае своего адресного пространства? |
Можно отображать, но это бред. | Можно отображать, но это бред. | ||
- | Поэтому жёстко сказано, что всё предаётся по | + | Поэтому жёстко сказано, что всё предаётся по значеннию. |
В связи с RPC есть два RFC: 1831, который определяет транспорт, и который определяет формат данных. | В связи с RPC есть два RFC: 1831, который определяет транспорт, и который определяет формат данных. | ||
Почему так много реализаций RPC: RFC, который возможно является стандартом, гибкий, не накладывающий ограничений. | Почему так много реализаций RPC: RFC, который возможно является стандартом, гибкий, не накладывающий ограничений. | ||
- | Каноническая реализация --- вызов синхронный. | + | Каноническая реализация --- вызов синхронный. |
RFC не говорит о том, что это нужно делать синхронно, и все современные реализации асинхронны. | RFC не говорит о том, что это нужно делать синхронно, и все современные реализации асинхронны. | ||
- | |||
Понятно, в чём проблема синхронного вызова: вызвали и ждём --- или ждём, или повторно дёргаем, но тогда непонятно, сколько раз она выполнена. | Понятно, в чём проблема синхронного вызова: вызвали и ждём --- или ждём, или повторно дёргаем, но тогда непонятно, сколько раз она выполнена. | ||
Поэтому некие минимальные ограничения на транспорт налагаются, в частности сопоставление ответа с запросом. | Поэтому некие минимальные ограничения на транспорт налагаются, в частности сопоставление ответа с запросом. | ||
- | Как это работает | + | Как это работает: чтобы вызвать на удалённом хосте удалённую функцию, нам нужно её идентифицировать: поэтому в RPC есть три беззнаковых значения --- номер программы, функции и версии. |
- | + | ||
- | + | ||
- | + | ||
- | Тут интересно то, что номера не возникают из бухты-барахты, а ими заведует тот же | + | Тут интересно то, что номера не возникают из бухты-барахты, а ими заведует тот же sun. |
- | Если вы написали программу и хотите, чтобы все о ней знали, то нужно написать e-mail на | + | Если вы написали программу и хотите, чтобы все о ней знали, то нужно написать e-mail на rpc@sun.com и сказать об этом. |
- | + | Про утилиты, которые можно непосредственно использовать: самая главная утилита --- rpcinfo. | |
- | Про утилиты, которые можно непосредственно использовать: самая главная утилита --- | + | |
Она позволяет обращаться к серверу, на котором есть программа, которая использует удалённый вызов процедур, и получать с него информацию. | Она позволяет обращаться к серверу, на котором есть программа, которая использует удалённый вызов процедур, и получать с него информацию. | ||
- | + | -p --- полезная опция: указываем имя хоста, по этой команде клиент подключается к удалённому серверу, запрашивает множество программ, по этим программам выдаются функции которые у них есть, с версиями и именами. Обычно там можно увидеть nfs. | |
- | + | ||
Каким образом мы соединяемся с удалённым сервером: понятно, что rpcinfo соединяет по какому-то порту? | Каким образом мы соединяемся с удалённым сервером: понятно, что rpcinfo соединяет по какому-то порту? | ||
Строка 137: | Строка 119: | ||
Третья часть доклада посвящена p2p, зовут дендика Алексеевский Даниил, и он имеет к этому некое косвенное отношение. | Третья часть доклада посвящена 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. | |
- | На uneex.ru/LecturesCMC это написано. | ||
= Конспект Kda: = | = Конспект Kda: = |