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

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

Перейти к: навигация, поиск

Внимание: Вы не представились системе. Ваш IP-адрес будет записан в историю изменений этой страницы.

Правка может быть отменена. Пожалуйста, просмотрите сравнение версий, чтобы убедиться, что это именно те изменения, которые вас интересуют, и нажмите «Записать страницу», чтобы изменения вступили в силу.

Текущая версия Ваш текст
Строка 1: Строка 1:
-
* '''Диктофонная запись:''' http://esyr.org/lections/audio/uneex_2008_winter/uneex_08_12_03.ogg
+
Сегодня прикл. уровень TCP/IP в Linux.
-
<gallery>
+
Первыое — DNS.
-
Изображение:Uneex 081203 desk 1.jpg
+
-
Изображение:Uneex 081203 desk 2.jpg
+
-
</gallery>
+
-
 
+
-
= Лекция =
+
-
== Вступление ==
+
-
Сегодня прикладной уровень TCP/IP в Linux.
+
-
 
+
-
Первое — DNS.
+
В прошлый раз мы закончили на том, как самому написать сетевой сервер.
В прошлый раз мы закончили на том, как самому написать сетевой сервер.
-
Тема, которую лектор не затронет — RPC.
+
Тема, которуб лектор на затронет — RPC.
-
Казалось бы, мы обсудили весь функционал в linux для работы с сетью, тем не менее, есть одна базовая система, без правильной настройки которой ей пользоваться трудно.
+
Казалось бы , мы обсудили весь функц. в linux для работы с сетью, тем не менее, есть одна без система, без правильной настр. которой ей пользоваться трудно.
-
== Проблема ==
+
Откуда омденная система имён растёт. Что мы имеем на уровне ip: что мы имеем виду под интернетом — дост. жёсткую систему раздачи адресов, связанную с топологией сети. Когда приним. решение о выдаче ip-адресов, это решение, эти циферки, которые будут выданы, берутся не с потолка. Сущ. центр. орг., которая их раздаёт, сущ. всякие держатели больших пулов, которые разд. их дальше. У на сеть руцентр. То есть, если нужно подкл. неск. десятков компьютеров, то выбирается орг., где цены лучше, и там их покупаешь. У этой арх. есть три недостатка:
-
Откуда доменная система имён растёт?
+
* IP адрес — такая штука, которую сложно запомнить. Один можно запомнить, а вот сотню адресов сложно. Эта задача решалась, и очень простым способом: есть /etc/hosts, в котором перечислены в очень простом формате — ip-адрес и его имена. пока в интернете было компьютеров 20—30, это замечательно работало. Когда их стало больше, задумались о том, что надо по-другому орг. эту архитектуру.
-
Что мы имеем на уровне ip: что мы имеем виду под интернетом — доступную жёсткую систему раздачи адресов, связанную с топологией сети.
+
* Как только выяснилось, что интернет это не три локальных сети, а монго сетей, то как опр. по ip-адресу компьютер. Точнее, как отр. адм. принадл. компьютера по сравн. с его жёсткой ip-адресацией, которая зависит искл. от топологии сети. Необх. сист. именования, отвязанная от топоолгии сети.
-
Когда принимается решение о выдаче ip-адресов, это решение, эти циферки, которые будут выданы, берутся не с потолка.
+
* Понтие адм. принадл. имеет оборотное свойство: проблема не только в том, чтобы по имени компьютера выяснить, зачем он вообще нужен, проблема в том, чтобы грамотно раздать людям из разл. зон. адм. отв. права раздавать эти имена.
-
Существует центральная организация, которая их раздаёт, существуют всякие держатели больших пулов, которые раздают их дальше.
+
Задача при этом такова: нужно придумать имена, при том именс должны отр. адм. структуру нтернета, и нужно рещить задачу, чтобы каждый адм. именовал свои компьютеры. Это посл. намекает на распр. систему, которая будет заниматься преобразованием имён в ip-адреса и обратно.
-
У нас есть руцентр.
+
Каким обр. это сейчас решается с помощью DNS? Сущ. некая орг., которая принимает решение о заведен корневых домненов. ICANN. (недавно она продавилась под китайами и решила начала раздавать корневые домены в нац. языках). Корневой домаен, домен первогоуровня это некое окончание, самая общ. часть. Домаенов первого уровня бывает неск. вдидов: в соотв. с неким предн., национальные и разные друие, принятые недавно. Их немного, в район двух сотен. Кроме того, в этой рг. надо зарег., чтобы разд. домены в зоне ru. Это озн. зона тв. внутри этой зоны лежит на этой орг (в случае с ru это руцентр), и ICANn уже практ. всё равно, что ам творится. Аналогично у руцентра рег. некая орг., которая говорит, что отв., например, за зону msu.ru, и дальше она уже отв. за неё. И тут уже, помимо разд. зон, ещё раздаются имён компьютерам в этом домене.
-
То есть, если нужно подключить несколько десятков компьютеров, то выбирается организация, где цены лучше, и там их покупаешь.
+
-
 
+
-
У этой архитектуры есть три недостатка:
+
-
* IP адрес — такая штука, которую сложно запомнить. Один можно запомнить, а вот сотню адресов сложно. Эта задача решалась, и очень простым способом: есть '''/etc/hosts''', в котором перечислены в очень простом формате ip-адрес и его имена. Пока в интернете было компьютеров 20—30, это замечательно работало. Когда их стало больше, задумались о том, что надо по-другому организовать эту архитектуру.
+
-
* Как только выяснилось, что интернет это не три локальных сети, а много сетей, то возникла проблема определения по ip-адресу компьютера. Точнее, как определить административную принадлежность компьютера по сравнению с его жёсткой ip-адресацией, которая зависит исключительно от топологии сети. Необходима система именования, отвязанная от топологии сети.
+
-
* Понятие административной принадлежности имеет оборотное свойство: проблема не только в том, чтобы по имени компьютера выяснить, зачем он вообще нужен, проблема в том, чтобы грамотно раздать людям из различных зон административной ответственности права раздавать эти имена.
+
-
 
+
-
Задача при этом такова: нужно придумать имена, при том имена должны отражать административную структуру интернета, и нужно решить задачу, чтобы каждый администратор именовал свои компьютеры. Это намекает на распределённую систему, которая будет заниматься преобразованием имён в ip-адреса и обратно.
+
-
 
+
-
== DNS как решение ==
+
-
Каким образом это сейчас решается с помощью DNS?
+
-
Существует некая организация, которая принимает решение о заведении корневых домненов --- ICANN. (недавно она продавилась под китайцами и решила начать раздавать корневые домены в национальных языках).
+
-
 
+
-
Корневой домен, домен первого уровня это некое окончание, самая общая часть.
+
-
Доменов первого уровня бывает несколько видов в соответствии с неким предназначением, национальные и разные другие, принятые недавно.
+
-
Их немного, в районе двух сотен.
+
-
 
+
-
Кроме того, в этой организации надо зарегистрироваться, чтобы раздавать домены в зоне ru.
+
-
Это определяет, что ответственность внутри этой зоны лежит на зарегистрированной организации (в случае с ru это руцентр), и ICANN уже практически всё равно, что там творится.
+
-
 
+
-
Аналогично у руцентра регистрируется некая организация, которая говорит, что она отвечает, например, за зону msu.ru.
+
-
И тут уже, помимо раздачи зон, ещё раздаются имёна компьютерам в этом домене.
+
И тут решаются все три задачи.
И тут решаются все три задачи.
-
Такая организация называется доменной.
+
Такая орг. наз. доменной. Произошло от слова домен, которое озн. феод, владение феодала.
-
Произошло от слова домен, которое означает феод, владение феодала.
+
Под королём были домены первого уровня.
Под королём были домены первого уровня.
-
При этом соблюдался принцип: '''вассал моего вассала не мой вассал'''.
+
При этолм собл. при этом собл. приницп вассал мего вассала не мой вассал.
-
По этой причине это и называется доменная система.
+
По этой причине это наз. доменная система.
-
Эта структура была хороша как самоорганизация, пока уровень связности был в пределах одного уровня.
+
Эта структура была зороша как самоорг. пока уровень связности был в пределахз одного уровня.
-
== Сервисы ==
+
Как это устр. на самом нижнем уровне:
-
Как это устроено на самом нижнем уровне:
+
-
Есть '''/etc/services''', в котором прописано соответствие сервисам портов.
+
Есть /etc/services, в котором прописано соотв. сервисам портов.
-
Клиент подключается по указанному порту к серверу, за которым его ждут услуги.
+
клиент подкл. по ук. порту к серверу, за которым его ждут услуни.
-
manmachine: диапазон красных портов
+
manmachine: диапазон красныйх портов
-
К тому, что происходит при использовании данного порта данный порт отношения не имеет. При этом было бы хорошо договориться, что определённый порт соответствовал определённому протоколу.
+
К тому, что происх. при исп. данного пората данный порт не имеет. При этом было бы хорошо договориться, что опр. порт. соотв. опр. протоколу.
-
Это соответствие существует чисто для удобства пользователя. Мы когда подключаемся по 80 порту, ожидаем встретить http-сервер, и так далее.
+
Это соотв. оно такое чисто для удобстве польз. Мы когда подкл. по 80 порту, то ожидаем всетитть http-сервер, и так далее.
-
Но всегда нужно иметь в виду, что на прикладном уровне это штука далеко не всегда встречающаяся.
+
Но всегда нужно иметь в виду, что на прикл. уровне это штука далеко не всегда встречающаяся.
-
В /etc/services можно увидеть порт 53, который отвечает как раз за dns.
+
В /etc/services модноу увидеть порт 53, которыйотв. как раз за dns.
-
Эта технология привязки службы к определённому порту является частью более общего механизма, который сужает понятие просто прикладного протокола до понятия клиент-серверного прикладного протокола.
+
Эта технология, технология привяз. службы к опр. порту явл. частью более общего мех., который сужает понятие просто прикл. протокол до понятия клиент-серв. прикл. протокол. Когда говорится о взаимод .по какому-то порту говорится имено о клиент-серверном взаимод. Это сущ. огранич. по сравнению с симметричной схемой. Это к тому, почему эта штука наз. services.
-
Когда говорится о взаимодействии по какому-то порту, говорится именно о клиент-серверном взаимодействии.
+
-
Это существенное ограничение по сравнению с симметричной схемой.
+
-
Это к тому, почему эта штука называется services.
+
-
Этот сервер, но в случае dns он заявлен как отвечающицй на tcp, так и на udp.
+
Этот сервер, но в случае dns он заявлен как отвечающицй на tcp, так и на udp. Почему так: запрос на преобр. ip-адреса в доменное имя и обр. как правило укл. в один. пакет. Соотв., ответ тоже, как правило, укл. в один пакет. Поск. такой запрос и такой ответ предст. собой датаграмму, почему бы его не исп. К тому же, исп. TCP утяжелило бы обмен примерно в 4 раза.
-
Почему так: запрос на преобразование ip-адреса в доменное имя и обратно как правило укладывается в один пакет.
+
-
Соответственно, ответ тоже, как правило, укладывается в один пакет.
+
-
Поскольку такой запрос и такой ответ представляют собой датаграмму, почему бы не использовать протокол датаграмм?
+
-
К тому же, использование TCP утяжелило бы обмен примерно в 4 раза.
+
-
Клиентская часть, resolver, есть практически на любой машине.
+
Клиентская часть, resolver, есть прак. на любой машине. Если его нет, то пользователь считает, что интернета нет.
-
Если его нет, то пользователь считает, что интернета нет.
+
-
Есть '''/etc/resolv.conf''', где указано, где находится DNS сервер.
+
Есть /etc/resolv.conf, где указано, где нах. DNS сервер.
-
К слову о FQDN, полном имя домена: в '''/etc/resolv.conf''' указываются две вещи: какие компьютеры являются dns-серверами, и вторая информация --- список доменов, в которых будет производиться поиск, если вы указали не полное имя, а краткое.
+
К слову, FQDN, полное имя домена, в /etc/resolv.conf указ. две вещи: какие компьютеры явл. dns-серверами, и вторая инфомация --- список доменов, в которых будет производиться поиск, если вы указали не полное имя, а краткое.
-
'''/etc/resolv.conf''' может не использоваться, если resolver запускается в chroot (например, так в alt).
+
/etc/resolv.conf может не исп., если resolver запускается в chroot (анпример, так в alt). Поэтому, например, если руками модиф. файл, далеко не сразу службы, которые его исп., начнут его исп.
-
Поэтому, например, при ручной модификации файла, далеко не сразу службы, которые его используют, начнут его использовать.
+
-
== Архитектура ==
+
Теперь об арзитектуре. Очевидно, с т. з. программы рещализация долнжа быть такая: есть понятие "сервер", этот сервер. Каждая орг. должна иметь такого рода севрвер, которая предост. услуги преобр. имён и адресов в соотв. с теми именами, которые есть.
-
Теперь об архитектуре.
+
-
Очевидно, с точки зрения программы реализация должна быть такая: есть понятие "сервер", это сервер.
+
-
Каждая организация должна иметь такого рода сервер, который предоставляет услуги преобразования имён и адресов в соответствие с теми именами, которые есть.
+
-
Каждый доменный сервер должен знать всю информацию об именах в своём домене и информацию о серверах, которые обслуживают зоны в домене.
+
Каждый доменный сервер должен знать всю инф. об именах в своём домене и инф. о серверазх, которые обслуж. зоны в домене.
-
Получается, что эта такая иерархически распределённая база данных.
+
Получается, что эта такая иерарх. распред. база данных.
-
Далее. вот прописал какой-то сервер в качестве сервера доменных имён.
+
Далее. вот прописал какой-то сервер в качестве сервера доменных имён. Далее вопрос: я же хочу спрашивать не только имена в этом домене, но и всякие другие. Должен ли он иметь full view? Конечно, нет. Хорошо, а как он будет узнавать? Никак, он скажет, спроси у корневого. Спрашиваем у корневого: он говорит, я не знаю, знаю про com. Кто знает про com, знает только про cdrom.com. А тот уже знает про ftp.cdrom.comю
-
Далее вопрос: я же хочу спрашивать не только имена в этом домене, но и всякие другие.
+
-
Должен ли он иметь full view?
+
-
Конечно, нет.
+
-
 
+
-
Хорошо, а как он будет узнавать?
+
-
Никак, он скажет, спроси у корневого.
+
-
Спрашиваем у корневого: он говорит, я не знаю, знаю про com.
+
-
Кто знает про com, знает только про cdrom.com.
+
-
А тот уже знает про ftp.cdrom.com.
+
Вот это — рекурсивный запрос.
Вот это — рекурсивный запрос.
Строка 123: Строка 69:
При этом делается такая прогулка.
При этом делается такая прогулка.
-
Если бы все компьютеры в интернете работали бы так, то к корневым серверам было бы слишком много запросов.
+
Если бы все компьютьеры в интирнете работали бы так, то к корневым серверам было бы слишком много запросов. Поэтому обычно так не делают, хотя можно. Поэтому обычно можно сначала послать прямой запрос своему dns-серверу, колторый уже может ответить да, нет, не знаю. Кроме того, клиентские машины обычно не делают рекурсивные запросы, они посылают только прямые, а уже dns-сервер занимается рекурсивным запросом и занимается кжшированием. Почему это улчше: елси целая сеть ломится по какому-то ip, то в кэше останутся ip dns-серверов для ежё для com и cdrom.com.
-
Поэтому обычно так не делают, хотя можно.
+
-
Поэтому обычно можно сначала послать прямой запрос своему dns-серверу, который уже может ответить да / нет / не знаю.
+
-
Кроме того, клиентские машины обычно не делают рекурсивные запросы, они посылают только прямые, а уже dns-сервер занимается рекурсивным запросом и занимается кешированием.
+
-
Почему это лучше: если целая сеть ломится по какому-то ip, то в кеше останутся ip dns-серверов ещё для com и cdrom.com.
+
-
Для того, чтобы не происходило злоупотребление, есть практика рекурсивные запросы выполнять только для своих хостов.
+
Для того, чтобы не происзодило злоупотребление, есть практика рекурсивные запросы выполнять только для своих хостов.
-
=== Кэш запросов ===
+
Тепер, что кас. способову увел. безобразия:
-
Теперь, что касается способов увеличения безобразия.
+
* Кэш
-
В каждой такой таблице соответствия ip-адресов и имён, которые хранит dns-сервер, есть ttl. Она говорит, какое время полученная запись может считаться валидной. Зачем это сделано: чтобы если понадобится изменить ip-адрес, об этом узнали через некоторое время. Обычно TTL выставляется в сутки. Если же у вас сеть меняется часто, то можно уменьшить ttl, но нужно быть готовым к увеличению нагрузки.
+
* В каждой такой таблице соотв. ip-адрсеов и имён, которые хранит dns-сервер есть ttl. Она говорит, какой время полученная запись может считаться валидной. Зачем это сделано: чтобы если понадобится изменить ip-адрес, об ээтом узнали через некоторое время. Обычно TTL выставляется у сутки. Если же у вас сеть меняется часто, то можно уменьшить ttl, но нужно быть готовым к увелич. нагрузки.
-
Есть ещё expired, который используется, если ttl просрачивается, а dns недоступен.
+
Есть ещё expired, который исп., если ttl просрачивапется, а dns недоступен.
-
=== Дополнительные возможности ===
+
Есть ещё одна идея, которая позв. убыстрить и увеличить связность: обычно для кжадой зоны указывается неск. серверов (минимум 2), при этом хорошо, чтобы они были в разных подсетях класса B. Это увле. надёжность. В слчаях, когда нужно обращаться напрямую, тут возникает вопрос, кто истина в посл. инстанции. И тут возникает механизм передачи зон. То есть редакт. зона на одной машине, а скач. на другой. И он тоже призн. авторитетным.
-
Есть ещё одна идея, которая позволяет убыстрить и увеличить связность: обычно для каждой зоны указывается несколько серверов (минимум 2), при этом хорошо, чтобы они были в разных подсетях класса B.
+
-
Это увеличивает надёжность.
+
-
В случаях, когда нужно обращаться напрямую, тут возникает вопрос, кто истина в последней инстанции.
+
-
И тут возникает механизм передачи зон.
+
-
То есть редактируется зона на одной машине, а скачивается на другой.
+
-
И он тоже признаётся авторитетным.
+
-
По какому признаку принимается решение, что данный сервер авторитетен на вопросы про DNS?
+
По какому призн. принимается реш., что данный сервер авторитетен на вопросы про DNS. Помимо преоюр. имён адреса DNS оказ. услуги по преобр. имён во что угодно. A — адреса. NS — списки авторитетных адресов для данного домена. MX — адрес.имя постового сервера. TXT — текст.
-
Помимо преобразования имён адреса, DNS оказывает услуги по преобразованию имён во что угодно.
+
-
* A — адреса.
+
-
* NS — списки авторитетных адресов для данного домена.
+
-
* MX — адрес/имя почтового сервера.
+
-
* TXT — произвольный текст.
+
-
DNS-сервера используются для того, чтобы хранить информацию о спамерах.
+
DNS-сервера исп. для того, чтобы хранить инф. о спамерах. Оно устр. именно как dns-сервер. Ему скармливается ip задом наперёд, и по ответу понятно, что это за ip.
-
Оно устроено именно как dns-сервер.
+
-
Ему скармливается ip задом наперёд, и по ответу понятно, что это за ip.
+
-
Остались две с половиной темы:
+
Остались две темы:
-
* Завершить DNS
+
* Заверш DNS
* RPC
* RPC
* p2p
* p2p
- 
-
= Конспект Kda =
 
- 
-
Сначала анекдот.
 
-
На сайте про линукс в разделе «Методические пособия» стали публиковать результаты работы группы.
 
-
Первое, что видит человек, это необработанные конспекты.
 
-
«Лектор жалуется на ...».
 
- 
-
Сегодня начало разговора о прикладном уровне Линукс.
 
-
Лектор планировал рассказать про три вещи, но расскажет, скорее всего, про одну.
 
-
DNS.
 
-
В прошлый раз мы закончили на том, как писать свой сетевой сервер.
 
-
У нас есть концепция файлового ввода-вывода, асинхронного ввода-вывода.
 
-
Сокеты, оказывается, поддерживают read и write.
 
-
Тема RPC сегодня не будет затронута.
 
-
Шла речь о сетевом сервере.
 
- 
-
Есть функциональность, о которой не задумываются.
 
-
Ошибка в DNS приводит к тому, что пользователь приходит и говорит, что у него нет Интернета.
 
-
Давайте сначала поставим задачу.
 
-
Откуда доменная система имен растет?
 
-
Что мы имеем, возвращаясь назад на уровень IP?
 
-
Что мы имеем, когда говорим об Интернете?
 
-
Достаточно жесткая политика раздачи IP-адресов.
 
-
Топология Интернета, которая меняется.
 
-
Когда принимается решение о выдаче пространства адресов, эти цифры, которые будут выданы, берутся не с потолка.
 
-
Существуют держатели больших пулов IP-адресов, которые раздают их дальше.
 
-
Если нужно подключить несколько десятков компьютеров, нужно сказать об этом держателю.
 
- 
-
Недостаток первый, самоочевидный.
 
-
IP vs. DNS.
 
-
IP-адрес практически невозможно запомнить.
 
-
9-12 цифр запомнить еще можно.
 
-
Но сотни адресов запомнить не реально.
 
-
Поэтому одна из задач в том, чтобы придумать имена.
 
-
Эта задача решалась, очень простым способом.
 
-
В каталоге /etc есть файл hosts, в котором перечислены в простом формате соответствия адресов и имен компьютеров.
 
-
Он есть даже в Windows.
 
-
Было популярно модифицировать в 90-е гг. содержимое этого файла.
 
-
Файл высокоприоритетный.
 
-
Если мы впишем туда соответствие, оно будет использовано.
 
-
Пока было 20-30 компьютеров, все было хорошо.
 
-
При появлении нового компьютера вписывали вручную на каждой машине.
 
- 
-
Потом компьютеров стало очень много.
 
-
Как только выяснилось, что Интернет — это не три локальные сети, а большая структура, возник вопрос, как определить по IP-адресу, чей он.
 
-
Административная принадлежность.
 
-
Не выяснение адреса человека, а само понимание, что компьютер принадлежит проекту freebsd.org и т.п.
 
-
Принадлежность компьютера организации, отвязанная от топологии.
 
- 
-
Также нужно понять, зачем компьютер в сети нужен.
 
-
Также задача раздачи прав на присваивание имен.
 
- 
-
В файл вносим изменения при появлении новых компьютеров.
 
-
При большом количестве компьютеров это не работает.
 
-
Нужна операция преобразования имен компьютеров в адреса.
 
-
IP выдает провайдер, а имена администратор сети.
 
- 
-
Передача полномочий.
 
- 
-
Нужны имена, нужно, чтобы имена отражали административную структуру Интернета, нужно решить задачу, чтобы администратор именовал свои компьютеры, а к чужим не имел доступ.
 
-
Распределенная система управления именами.
 
- 
-
Каким образом эта задача решается с помощью DNS?
 
-
Во-первых, существует некая организация, которая принимает решение о заведении корневых доменов.
 
-
Эта организация называется ICANN.
 
-
В ней принимаются решения.
 
-
Недавно принято решение о том, чтобы можно было в доменных именах использовать не только латинский алфавит.
 
-
Давнишняя передряга с русскими доменными именами.
 
- 
-
Существует организация, принимающая решения о легализации корневых доменов.
 
-
Корневой домен используется в качестве генерального окончания имени компьютера.
 
-
Старые .org, .com, .net, потом по странам .ru, .uk, su, несколько лет назад появились .info, .biz.
 
-
Важно другое.
 
-
Их не так много.
 
-
Первых около десятка, вторых в районе количества стран, третьих тоже несколько десятков.
 
-
В общем, немного.
 
- 
-
Помимо того, что эта организация принимает решение о доменах, в ней нужно зарегестрироваться организациям, которые будут выдавать адреса в соответствующих зонах.
 
-
Зона ответственности за домен .ru лежит на зарегестрированной организации, а не на ICANN.
 
-
Организация в свою очередь выдает права на домен, например, msu.ru.
 
-
Взаимодействие с организациями, владеющими доменами второго уровня.
 
-
Отвечать за имена компьютеров в этом домене.
 
-
Помимо поддоменов, есть компьютеры, имена которых заканчиваются на .ru.
 
-
Например, www.ru.
 
-
Им владеет «Демос».
 
-
msu.ru поступает также.
 
-
Организация сидит в Главном здании.
 
-
Она раздает домены третьего уровня, например, cmc.msu.ru.
 
-
Также отвечает за имена в зоне msu.ru.
 
-
Например, www.msu.ru.
 
- 
-
Мы решаем обе задачи, в смысле, все три.
 
-
Мы присваиваем имена.
 
-
До седьмого уровня имена даже запоминаются.
 
-
Имена в реальности отражают структуру Интернета (кто взял ответственность за имена).
 
-
Именованием компьютеров внутри домена ведает нижележащая организация.
 
-
По этой причине такую иерархию назвали доменной.
 
-
В русском языке есть слово д`омен (владения феодала внутри феода).
 
-
Помним, что устройство феодальной собственности имело иерархическую структуру.
 
-
Король владел всем, у него были феодалы первого уровня, у них феодалы второго уровня.
 
-
«Вассал моего вассала не мой вассал».
 
-
Принцип тот же самый.
 
- 
-
Король владеет всем, наделяет правами собственности на домены первого уровня.
 
-
Организация взаимодействует со своими вассалами, работает со своим уровнем.
 
-
Что делается на нижних уровнях, организацию не волнует.
 
-
Доменная система хорошо себя оправдала в эпоху феодализма.
 
-
Еще эта структура была хороша как самоорганизующая, до тех пор, пока уровень воздействия между слоями был ограничен.
 
-
Крестьяне не могли ворваться в город.
 
- 
-
Все прекрасно, осталось это реализовать.
 
-
Что об этом думают компьютеры?
 
-
Ситуация следующая.
 
-
Есть корневые серверы, их немного.
 
- 
-
Как это устроено на нижнем уровне?
 
-
Как было сказано в начале лекции, есть файл /etc/services.
 
-
Разговор о сетях.
 
-
Порт — число, по которому ожидает некий сервис.
 
-
На транспортном уровне это один из элементов адреса, а на прикладном — такая штука, за которой нас ждут услуги.
 
-
При этом, как было сказано в прошлый раз, было бы неплохо договориться, какой порт за какие услуги отвечает.
 
-
На траспортном уровне разделение потоков.
 
-
К собственно приложению это число (порт) прямого отношения не имеет.
 
-
Было бы удобно договориться о том, что определенный порт соответствует приложению, которое будет ждать пользователя, подключившегося к порту.
 
- 
-
Существует организация IANA, которая занимается следующим.
 
-
Взяла на себя роль стандартизатора.
 
-
Есть два понятия — well-known services, secure services.
 
-
После долгих обсуждений и доказательства, что это нужный сервис и неплохо его привязать к номеру портов, в список соответствий номеров портов сервисам вписывается новый файл.
 
-
Во FreeBSD список больше, чем в Линукс.
 
-
Даже есть сервис Gandalf.
 
-
Соответствие чисто для удобства пользователя.
 
-
Мы подключаемся к 80 порту и ожидаем, что нас встретит веб-сервер.
 
-
На 443 порту ожидаем защищенный веб-сервер.
 
-
На прикладном уровне порт — штука, не всегда встречающаяся.
 
-
FTP сервер можно запустить, чтобы он читал данные из стандартного ввода.
 
-
Порт не обязателен.
 
-
Есть исключения.
 
-
Внутри протокола FTP заложена передача адреса компьютера и порта, к которому надо подключиться.
 
-
Важно, что он передает порт.
 
-
В SMTP нет понятия порт, а в FTP есть.
 
- 
-
В файле /etc/services есть порт 53, отвечающий за DNS.
 
-
Технология привязывания службы к порту является частью более общего механизма, который сужает понятие прикладной протокол до клиент-серверного протокола.
 
-
Когда речь идет об услугах, речь идет о клиент-серверном взаимодействию.
 
-
Подключаемся по условленному порту, нам оказывают услуги.
 
-
Бывает обмен симметричный.
 
-
Когда речь идет о подключении непонятно откуда на 80 порт, тот, кто подключается — клиент, а тот, к кому подключились — сервер, обмен асимметричный.
 
- 
-
53 порт.
 
-
Сервер, о котором идет речь, в случае DNS заявлен как отвечающий и по TCP, и по UDP.
 
-
UDP используется чаще.
 
-
Почему?
 
-
Запрос укладывается в один пакет.
 
-
Какой адрес у такого имени?
 
-
Ответ тоже укладывается в один пакет.
 
-
Адреса нет.
 
-
Или, наоборот, выдается адрес.
 
-
Используем протокол для датаграмм.
 
-
Использование протокола TCP утяжелило бы трафик в несколько раз.
 
-
А с трафиком проблема сильная.
 
- 
-
Клиент-сервер.
 
-
Это значит, что машина-клиент должна иметь клиентскую часть и должна знать, где находится серверная часть.
 
-
Куда подключаться, кому слать запрос.
 
-
Асимметричность.
 
-
Клиентская часть есть на любом компьютере, подключающемся к Интернету.
 
-
Никаких yandex.ru в TCP нет.
 
-
Имена — понятие прикладного уровня.
 
-
Нужно преобразовать имя в адрес.
 
- 
-
Есть файл /etc/resolv.conf, который описывает некоторые понятия.
 
-
FQDN — полное доменное имя, начиная от корня.
 
-
Не Вася, а Вася.msu.ru.
 
-
В файле указывается, какие компьютеры являются серверами.
 
-
А также список доменов, в которых будет производиться поиск, если мы указали не полное имя, а краткое.
 
-
Если ищем cmc, и указано search msu.ru, будет искаться cmc.msu.ru.
 
-
Часто файл лежит не в /etc, или копируется и подсовывается в «правильное место».
 
-
В Альте лежит в /var/resolv.
 
-
Службе нужна вся сеть.
 
-
Потенциально она опасна.
 
-
Ее читали все эксперты.
 
-
Но ее нужно запускать в изолированном окружении.
 
-
Тот кусок, который пользуется, не видит нормального окружения.
 
-
Если руками модифицировать этот файл, далеко не сразу службы, которые им пользуются, начнут им пользоваться.
 
-
В Альте нужно запустить специальную команду.
 
- 
-
По архитектуре (как реализовано).
 
-
С точки зрения программы реализация такая.
 
-
У нас имеется понятие сервер.
 
-
Каждая организация должна иметь такого рода сервер, который обеспечивает услуги по преобразовании имен в адреса в соответствии с правилами.
 
-
Каждый доменный сервер должен знать всю информацию об именах в своем домене, и всю информацию о серверах поддоменов (и так далее по вложенным доменам).
 
- 
-
Что получается?
 
-
Распределенная иерархическая база данных, представляющая собой строгое дерево.
 
-
Устроена следующим образом.
 
-
Есть корневые сервера.
 
-
Каждый делает одно и то же.
 
-
Их 12 просто потому, что их должно быть много.
 
-
Сервера первого уровня.
 
-
Сервер зоны .ru знает компьютеры и поддомены.
 
-
Сервер .msu.ru знает компьютеры и поддомены и т.д.
 
- 
-
Есть компьютер.
 
-
Прописал сервер в качестве доменного сервера.
 
-
Вопрос первый.
 
-
Хочу спрашивать адреса не только в зоне cmc.msu.ru, а все.
 
-
Следует ли, что сервер должен знать все адреса?
 
-
Нет.
 
-
Как узнавать информацию о cdrom.com?
 
-
Ответ очевиден.
 
-
Если мой сервер не знает, он должен посылать в правильное место, спроси у того, кто знает.
 
-
Какое правильное место cmc.msu.ru может предложить?
 
-
Никакое.
 
-
Дальше идем по цепочке вверх до корневого сервера.
 
-
Корневой сервер спрашивает у сервера зоны .com.
 
-
Тот у cdrom.com.
 
- 
-
Рекурсивный запрос.
 
-
Прогулка по иерархии.
 
-
Выбирается наиболее подходящий сервер для начала, затем спрашиваем про вассала, у того про его вассала.
 
-
Если бы все работали вышеописанным методом, в области подключения корневых серверов были бы перегрузки.
 
-
Ситуация более сложная и более разумная.
 
-
Рекурсивный запрос позволен не всем.
 
-
Рекурсивный запрос может делат кто угодно.
 
-
Но так не делают.
 
-
Клиент посылает не рекурсивный запрос, а прямой.
 
-
Либо получаем IP, либо нет.
 
-
Третий вариант — таймаут.
 
-
Прямой запрос — вот IP, либо IP у имени нет, либо не знаю.
 
-
При обращении к серверу с прямым запросом, сервер может отказаться отвечать.
 
-
Допустим, что существует небольшое число DNS-серверов.
 
-
Компьютеров миллионы, серверов тысячи.
 
-
В несколько раз больше, чем доменов.
 
- 
-
Обычный компьютер посылает прямой запрос DNS-серверу.
 
-
А сервер начинает всю эту штуку с рекурсивными запросами.
 
-
Когда придет ответ серверу, он посылает ответ клиенту.
 
-
Каждый клиент не занимается рекурсивным запросом, не ломится на корневой сервер.
 
-
А локальные серверы кэшируют ответы.
 
-
Почему это лучше?
 
-
Если целая сеть ломится на сервер и хочет распознать адрес, в кэше останутся адреса других серверов.
 
-
Будем знать адрес сервера .com, сервера cdrom.com, можем не лезть на корневой сервер.
 
-
Чем больше запросов, тем больше используется кэш в серверах.
 
- 
-
Мы с домена в cmc.msu.ru пошлем запрос на cdrom.com.
 
-
Если спросим о sourceforge.com, нас пошлют.
 
-
Своим сервер бы ответил, а чужим нет.
 
-
Адреса, которые указаны в resolv.conf, специфичны, они дадут послать запрос и сделать его рекурсивным.
 
-
Другие серверы не дадут делать такие запросы.
 
- 
-
Это ограничительные способы.
 
-
Достичь производительности путем ограничений тяжело, будет только хуже ее использовать.
 
-
Что касается способов увеличения быстродействия.
 
-
В каждой таблице (зоне ответственности) соответствия имен и адресов имеется TTL (time to live).
 
-
В течение этого времени закэшированная запись будет валидна.
 
-
Если наш сервер рассказал про ftp.cdrom.com, он закэширует эти данные.
 
-
Если администраторы cdrom.com что-то изменят, мы потом узнаем об этом.
 
-
В течение обычно суток считается, что адрес не меняется.
 
-
Если же IP меняются постоянно (раз в час), ставим TTL раз в час и в 24 раза увеличится нагрузка на сеть.
 
-
С одной стороны гарантируется механизм кэширования, с другой стороны есть управляемость кэшами, которые засели непонятно где.
 
- 
-
Помимо этого есть понятие устаревания записи, когда она не просто удаляется из кэша, а если она устарела, ей даже доверять нельзя.
 
-
Запись устарела, а DNS-сервер упал.
 
-
Запись держится в кэше.
 
-
Нам отвечают «Вот вам информация не первой свежести».
 
-
Потом же (через неделю) запись просто удалится из кэша в любом случае.
 
- 
-
Еще одна идея, которая позволяет убыстрить и увеличить надежность системы.
 
-
Мы упоминали о том, что сервер может не отвечать, не обязательно потому что перестал функционировать, а могла пропасть связность с Интернетом.
 
-
При регистрации регистрируем не менее двух серверов.
 
-
Должны находиться в разных сетях класса B.
 
-
Зачем это делается?
 
-
И тот, и другой сервер являются авторитетными.
 
-
К ним пойдет запрос, тот и другой сервер будут возвращаться в качестве ответа на рекурсивный запрос.
 
-
Если один из них не работает, будет опрошен второй.
 
-
Это в два раза увеличит надежность.
 
-
На кэширование это никак не влияет.
 
-
Увеличит таймаут.
 
- 
-
Тут другая проблема.
 
-
У какого сервера мы имеем право спрашивать окончательную истину?
 
-
Мы спрашиваем о том, кто такой cdrom.com.
 
-
Кто ответил, родной сервер или наш.
 
-
Когда мы хотим узнать, кто отвечает за cdrom.com, мы не можем полагаться на кэши.
 
-
Или хотим насильственно кэшировать зону.
 
-
Обращаемся к авторитетному серверу.
 
-
Но их минимум два.
 
-
Такого не бывает.
 
-
Один primary, другой secondary.
 
-
Межсерверная передача зон.
 
-
Можем договориться с товарищем, чтобы на его сервер скачивалась наша зона.
 
-
Если у провайдера записан и сервер товарища, и наш сервер, получаем, что истина в последней инстанции — другой сервер, но наш тоже авторитетен.
 
- 
-
По какому признаку принимается решение о авторитетности?
 
-
Помимо услуг по преобразованию имен в адреса, оказываются услуги о преобразовании имен в другие штуки.
 
-
Запись A — адрес.
 
-
Запись NS — список адресов, которые являются авторитетными для данного домена.
 
-
Запись MX — адрес сервера, отвечающего за пересылку почты для данного домена.
 
-
Тип TXT — посылаем имя, возвращается текст.
 
-
DNS можно пользоваться, как базой данных.
 
- 
-
DNS-сервера используются для хранения информации о спамерах.
 
-
У нас зависло две темы.
 
-
В следующий раз завершение DNS, RPC, peer-to-peer.
 
{{UNИX, осень 2008}}
{{UNИX, осень 2008}}
{{Lection-stub}}
{{Lection-stub}}

Пожалуйста, обратите внимание, что все ваши добавления могут быть отредактированы или удалены другими участниками. Если вы не хотите, чтобы кто-либо изменял ваши тексты, не помещайте их сюда.
Вы также подтверждаете, что являетесь автором вносимых дополнений, или скопировали их из источника, допускающего свободное распространение и изменение своего содержимого (см. eSyr's_wiki:Авторское право).
НЕ РАЗМЕЩАЙТЕ БЕЗ РАЗРЕШЕНИЯ ОХРАНЯЕМЫЕ АВТОРСКИМ ПРАВОМ МАТЕРИАЛЫ!


Отменить | Справка по редактированию (в новом окне)

Шаблоны, использованные на этой странице:

Получено с http://esyr.us/wiki/UN%D0%98X%2C_%D0%BE%D1%81%D0%B5%D0%BD%D1%8C_2008%2C_10_%D0%BB%D0%B5%D0%BA%D1%86%D0%B8%D1%8F_%28%D0%BE%D1%82_03_%D0%B4%D0%B5%D0%BA%D0%B0%D0%B1%D1%80%D1%8F%29
Разделы