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

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

Версия от 18:08, 3 декабря 2008; ESyr01 (Обсуждение | вклад)
(разн.) ← Предыдущая | Текущая версия (разн.) | Следующая → (разн.)
Перейти к: навигация, поиск

Сегодня прикл. уровень TCP/IP в Linux.

Первыое — DNS.

В прошлый раз мы закончили на том, как самому написать сетевой сервер.

Тема, которуб лектор на затронет — RPC.

Казалось бы , мы обсудили весь функц. в linux для работы с сетью, тем не менее, есть одна без система, без правильной настр. которой ей пользоваться трудно.

Откуда омденная система имён растёт. Что мы имеем на уровне ip: что мы имеем виду под интернетом — дост. жёсткую систему раздачи адресов, связанную с топологией сети. Когда приним. решение о выдаче ip-адресов, это решение, эти циферки, которые будут выданы, берутся не с потолка. Сущ. центр. орг., которая их раздаёт, сущ. всякие держатели больших пулов, которые разд. их дальше. У на сеть руцентр. То есть, если нужно подкл. неск. десятков компьютеров, то выбирается орг., где цены лучше, и там их покупаешь. У этой арх. есть три недостатка:

  • IP адрес — такая штука, которую сложно запомнить. Один можно запомнить, а вот сотню адресов сложно. Эта задача решалась, и очень простым способом: есть /etc/hosts, в котором перечислены в очень простом формате — ip-адрес и его имена. пока в интернете было компьютеров 20—30, это замечательно работало. Когда их стало больше, задумались о том, что надо по-другому орг. эту архитектуру.
  • Как только выяснилось, что интернет это не три локальных сети, а монго сетей, то как опр. по ip-адресу компьютер. Точнее, как отр. адм. принадл. компьютера по сравн. с его жёсткой ip-адресацией, которая зависит искл. от топологии сети. Необх. сист. именования, отвязанная от топоолгии сети.
  • Понтие адм. принадл. имеет оборотное свойство: проблема не только в том, чтобы по имени компьютера выяснить, зачем он вообще нужен, проблема в том, чтобы грамотно раздать людям из разл. зон. адм. отв. права раздавать эти имена.

Задача при этом такова: нужно придумать имена, при том именс должны отр. адм. структуру нтернета, и нужно рещить задачу, чтобы каждый адм. именовал свои компьютеры. Это посл. намекает на распр. систему, которая будет заниматься преобразованием имён в ip-адреса и обратно.

Каким обр. это сейчас решается с помощью DNS? Сущ. некая орг., которая принимает решение о заведен корневых домненов. ICANN. (недавно она продавилась под китайами и решила начала раздавать корневые домены в нац. языках). Корневой домаен, домен первогоуровня это некое окончание, самая общ. часть. Домаенов первого уровня бывает неск. вдидов: в соотв. с неким предн., национальные и разные друие, принятые недавно. Их немного, в район двух сотен. Кроме того, в этой рг. надо зарег., чтобы разд. домены в зоне ru. Это озн. зона тв. внутри этой зоны лежит на этой орг (в случае с ru это руцентр), и ICANn уже практ. всё равно, что ам творится. Аналогично у руцентра рег. некая орг., которая говорит, что отв., например, за зону msu.ru, и дальше она уже отв. за неё. И тут уже, помимо разд. зон, ещё раздаются имён компьютерам в этом домене.

И тут решаются все три задачи.

Такая орг. наз. доменной. Произошло от слова домен, которое озн. феод, владение феодала.

Под королём были домены первого уровня.

При этолм собл. при этом собл. приницп вассал мего вассала не мой вассал.

По этой причине это наз. доменная система.

Эта структура была зороша как самоорг. пока уровень связности был в пределахз одного уровня.

Как это устр. на самом нижнем уровне:

Есть /etc/services, в котором прописано соотв. сервисам портов.

клиент подкл. по ук. порту к серверу, за которым его ждут услуни.

manmachine: диапазон красныйх портов

К тому, что происх. при исп. данного пората данный порт не имеет. При этом было бы хорошо договориться, что опр. порт. соотв. опр. протоколу.

Это соотв. оно такое чисто для удобстве польз. Мы когда подкл. по 80 порту, то ожидаем всетитть http-сервер, и так далее.

Но всегда нужно иметь в виду, что на прикл. уровне это штука далеко не всегда встречающаяся.

В /etc/services модноу увидеть порт 53, которыйотв. как раз за dns.

Эта технология, технология привяз. службы к опр. порту явл. частью более общего мех., который сужает понятие просто прикл. протокол до понятия клиент-серв. прикл. протокол. Когда говорится о взаимод .по какому-то порту говорится имено о клиент-серверном взаимод. Это сущ. огранич. по сравнению с симметричной схемой. Это к тому, почему эта штука наз. services.

Этот сервер, но в случае dns он заявлен как отвечающицй на tcp, так и на udp. Почему так: запрос на преобр. ip-адреса в доменное имя и обр. как правило укл. в один. пакет. Соотв., ответ тоже, как правило, укл. в один пакет. Поск. такой запрос и такой ответ предст. собой датаграмму, почему бы его не исп. К тому же, исп. TCP утяжелило бы обмен примерно в 4 раза.

Клиентская часть, resolver, есть прак. на любой машине. Если его нет, то пользователь считает, что интернета нет.

Есть /etc/resolv.conf, где указано, где нах. DNS сервер.

К слову, FQDN, полное имя домена, в /etc/resolv.conf указ. две вещи: какие компьютеры явл. dns-серверами, и вторая инфомация --- список доменов, в которых будет производиться поиск, если вы указали не полное имя, а краткое.

/etc/resolv.conf может не исп., если resolver запускается в chroot (анпример, так в alt). Поэтому, например, если руками модиф. файл, далеко не сразу службы, которые его исп., начнут его исп.

Теперь об арзитектуре. Очевидно, с т. з. программы рещализация долнжа быть такая: есть понятие "сервер", этот сервер. Каждая орг. должна иметь такого рода севрвер, которая предост. услуги преобр. имён и адресов в соотв. с теми именами, которые есть.

Каждый доменный сервер должен знать всю инф. об именах в своём домене и инф. о серверазх, которые обслуж. зоны в домене.

Получается, что эта такая иерарх. распред. база данных.

Далее. вот прописал какой-то сервер в качестве сервера доменных имён. Далее вопрос: я же хочу спрашивать не только имена в этом домене, но и всякие другие. Должен ли он иметь full view? Конечно, нет. Хорошо, а как он будет узнавать? Никак, он скажет, спроси у корневого. Спрашиваем у корневого: он говорит, я не знаю, знаю про com. Кто знает про com, знает только про cdrom.com. А тот уже знает про ftp.cdrom.comю

Вот это — рекурсивный запрос.

При этом делается такая прогулка.

Если бы все компьютьеры в интирнете работали бы так, то к корневым серверам было бы слишком много запросов. Поэтому обычно так не делают, хотя можно. Поэтому обычно можно сначала послать прямой запрос своему dns-серверу, колторый уже может ответить да, нет, не знаю. Кроме того, клиентские машины обычно не делают рекурсивные запросы, они посылают только прямые, а уже dns-сервер занимается рекурсивным запросом и занимается кжшированием. Почему это улчше: елси целая сеть ломится по какому-то ip, то в кэше останутся ip dns-серверов для ежё для com и cdrom.com.

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

Тепер, что кас. способову увел. безобразия:

  • Кэш
  • В каждой такой таблице соотв. ip-адрсеов и имён, которые хранит dns-сервер есть ttl. Она говорит, какой время полученная запись может считаться валидной. Зачем это сделано: чтобы если понадобится изменить ip-адрес, об ээтом узнали через некоторое время. Обычно TTL выставляется у сутки. Если же у вас сеть меняется часто, то можно уменьшить ttl, но нужно быть готовым к увелич. нагрузки.

Есть ещё expired, который исп., если ttl просрачивапется, а dns недоступен.

Есть ещё одна идея, которая позв. убыстрить и увеличить связность: обычно для кжадой зоны указывается неск. серверов (минимум 2), при этом хорошо, чтобы они были в разных подсетях класса B. Это увле. надёжность. В слчаях, когда нужно обращаться напрямую, тут возникает вопрос, кто истина в посл. инстанции. И тут возникает механизм передачи зон. То есть редакт. зона на одной машине, а скач. на другой. И он тоже призн. авторитетным.

По какому призн. принимается реш., что данный сервер авторитетен на вопросы про DNS. Помимо преоюр. имён адреса DNS оказ. услуги по преобр. имён во что угодно. A — адреса. NS — списки авторитетных адресов для данного домена. MX — адрес.имя постового сервера. TXT — текст.

DNS-сервера исп. для того, чтобы хранить инф. о спамерах. Оно устр. именно как dns-сервер. Ему скармливается ip задом наперёд, и по ответу понятно, что это за ip.

Остались две темы:

  • Заверш DNS
  • RPC
  • p2p


UNИX, осень 2008


Лекции

01 02 03 04 05 06 07 08 09 10 11 12


Календарь

Октябрь
01 08 15 22 29
Ноябрь
05 12 19 26
Декабрь
03 10 17
Семинары

01 02


Календарь

Сентябрь
01
Ноябрь
02


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

Эта статья ещё не вычитана. Пожалуйста, вычитайте её и исправьте ошибки, если они есть.
Личные инструменты
Разделы