Історія ДО а: домен, протокол порт

11 січня 1982, двадцять два фахівця з інформатики зустрілися, щоб обговорити «комп'ютерну пошту» (нині відому як "електронна пошта"). Серед учасників був майбутній засновник Sun Microsystems, хлопець, який зробив Zork, чувак, створив NTP, і ще один, який переконав уряд платити за Unix. Перед ними стояло завдання вирішити проблему: в ARPANET було 455 хостів, і ситуація виходила з під контролю.

Проблема виникла із-за того, що ARPANET переходив з оригінального протоколу NCP на протокол TCP/IP, на якому зараз існує Інтернет. Після такого переходу швидко повинно було з'явитися безліч об'єднаних мереж (inter...net), яким потрібна ієрархічна система доменів, щоб ARPANET міг резолвить свої домени, а інші мережі — свої.
В той час були інші мережі: «COMSAT», «CHAOSNET», «UCLNET» і «INTELPOSTNET». Їх обслуговували групи університетів і компаній в США, які хотіли обмінюватися інформацією і які могли дозволити собі орендувати 56 тисяч з'єднань у телефонній компанії і купити PDP-11 для маршрутизації.
В початковій архітектурі ARPANET головний Центр Мережевої Інформації (Network Information Center, NIC) відповідав за спеціальний файл, у якому міститься список всіх хостів мережі. Він називався HOSTS.TXT, аналогічно файлу
/etc/hosts
в сучасних Linux або macOS. Будь-яка зміна в мережі вимагало від NIC підключатися до кожного вузла мережі по FTP (протокол, створений в 1971 року), що сильно підвищувало навантаження на інфраструктуру.
Зберігання всіх хостів Інтернету в одному файлі, звичайно, не могло вважатися масштабованим методом. Але пріоритетним питанням була електронна пошта. Вона була головним завданням адресації. У підсумку, вони вирішили створити ієрархічну систему, в якій можна було б запитати у віддаленої системи інформацію про домен або набір доменів. Іншими словами: «Рішення полягало в тому, щоб розширити існуючий поштовий ідентифікатор виду 'user@host' до 'user@host.domain', де 'domain' може бути ієрархією доменів». Так народився домен.

Важливо зазначити, що такі архітектурні рішення були прийняті без будь-яких припущень про те, як домени будуть використовуватися в майбутньому. Вони були обумовлені лише простотою реалізації: це вимагало мінімальних змін в існуючих системах. Однією з пропозицій було формувати поштову адресу
<user>.<host>@<domain>
. Якщо б у поштових імена тих днів уже не було б точок, то сьогодні ви, можливо, писали б мені на zack.eager@io
UUCP та Bang Path
Вважається, що головна функція операційної системи — це визначити кілька різних назв для одного і того ж об'єкта, так щоб система була постійно зайнята стеженням за всіма взаємовідносинами між різними іменами. Мережеві протоколи, схоже, ведуть себе так само.

— Девід Д. Кларк, 1982
Ще одне відхилено пропозиція полягала в тому, щоб відокремити домен оклику. Наприклад, для підключення до хосту ISIA в мережі ARPANET потрібно було б написати !ARPA!ISIA. Можна було б використовувати шаблони: !ARPA!* — всі хости мережі ARPANET.
Такий метод адресації не те щоб шалено відрізнявся від стандарту, навпаки, це була спроба підтримки стандарту. Система поділу з допомогою знака оклику використовувалася в інструменті для передачі даних UUCP, створеному в 1976 році. Якщо ви читаєте цю статтю в macOS або Linux, то uucp швидше всього все ще встановлений і доступний в терміналі.
ARPANET з'явилася в 1969 році і швидко перетворилася в потужний інструмент обміну інформацією… серед декількох університетів та урядових організацій, які мали до неї доступ. Інтернет у знайомому нам вигляді став доступний широкій публіці в 1991 році, через двадцять один рік. Але це не означає, що користувачі комп'ютерів не обмінювалися інформацією.

В епоху до інтернету використовувався спосіб прямого підключення однієї машини до іншої через телефонну мережу. Наприклад, якщо ви хотіли послати мені файл, то ваш модем подзвонив би мою модему, і файл був би переданий. Щоб зробити з цього якусь подобу мережі, був придуманий UUCP.
У цій системі у кожного комп'ютера був файл із списком вузлів, про які йому відомо, їх телефонні номери та логін та пароль для хоста. Далі потрібно змайструвати маршрут від поточної машини до цільової через набір інших хостів:
sw-hosts!digital-lobby!zack

Такий адресу використовувався не тільки для передачі файлів або прямого підключення до комп'ютера, але і як адресу електронної пошти. В епоху до поштових серверів вам не вдалося б послати мені листа, якщо мій комп'ютер був відключений.
В той час, як ARPANET був доступний тільки топовим університетам, UUCP дозволив з'явитися «підпільного» інтернету для простих людей. Він був основою і для Usenet і для системи BBS.
DNS
Система DNS, яку ми досі використовуємо, була запропонована в 1983 році. Якщо зробити DNS-запит за допомогою утиліти dig, наприклад, то відповідь буде приблизно таким:
;; ANSWER SECTION:
google.com. 299 IN A 172.217.4.206
Це означає, що
google.com
доступний за адресою
172.217.4.206
. Як ви напевно знаєте,
A
означає, що це запис адреси, яка пов'язує домен з IPv4-адреси. Число 299 — це час життя (time to live, TTL), скільки ще секунд ця запис вважається валидной поки не знадобиться робити новий запит. Але що таке
IN
?
IN
це "Internet". Поряд з іншими деталями, це поле прийшло з минулого, в якому було кілька конкуруючих мереж, і їм потрібно було спілкуватися один з одним. Інші потенційні значення для цього поля це CH для CHAOSNET, HS для Hesiod (назву сервісу системи Athena). CHAOSNET давно закрився, але сильно модифікована версія Athena все ще використовується студентами MIT. Список класів DNS доступний на сайті IANA, але не дивно, що зазвичай використовується тільки один з потенційних варіантів.
TLD
Ймовірність того, що будуть створені якісь інші TLD вкрай низька.

— Джон Постел,
1994
Коли було вирішено, що доменні імена повинні розташовуватися ієрархічно, залишилося визначити корінь ієрархії. Такий корінь позначається крапкою
.
. Закінчувати всі доменні імена точкою — семантично вірно, і такі адреси будуть працювати в браузері:
google.com.

Першим TLD був
.arpa
. Користувачі могли використовувати свої старі імена хостів ARPANET в період переходу. Наприклад, якщо моя машина була в минулому зареєстрована як
hfnet
, то мій новий адресу було б
hfnet.arpa
. Це було тимчасовим рішенням для періоду зміни системи. Серверним адміністраторам потрібно було прийняти важливе рішення: який з п'яти TLD їм вибрати? “.com", ".gov", ".org", ".edu" або ".mil"?
Коли кажуть, що DNS має ієрархією, мають на увазі, що є набір кореневих DNS-серверів, які відповідають, наприклад, за перетворення
.com
в адреси DNS-серверів зони
.com
, які в свою чергу повернуть відповідь на питання «як дістатися до
google.com
». Коренева зона DNS складається з тринадцяти кластерів DNS-серверів. Кластерів тільки 13, тому що більше не поміщається в один пакет UDP. Історично склалося, що DNS працює через UDP, тому відповідь на запит не може бути довшим 512 байт.
Прихований текст
; This file holds the information on root name servers needed to
; initialize cache of Internet domain name servers
; (e.g. reference this file in the "cache . "
; configuration file of BIND domain name servers).
;
; This file is made available by InterNIC 
; under anonymous FTP as
; file /domain/named.cache
; on server FTP.INTERNIC.NET
; -OR - RS.INTERNIC.NET
;
; last update: March 23, 2016
; related version of root zone: 2016032301
;
; formerly NS.INTERNIC.NET
;
. 3600000 NS A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4
A.ROOT-SERVERS.NET. 3600000 AAAA 2001:503:ba3e::2:30
;
; FORMERLY NS1.ISI.EDU
;
. 3600000 NS B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET. 3600000 A 192.228.79.201
B.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:84::b
;
; FORMERLY C.PSI.NET
;
. 3600000 NS C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12
C.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:2::c
;
; FORMERLY TERP.UMD.EDU
;
. 3600000 NS D.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET. 3600000 A 199.7.91.13
D.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:2d::d
;
; FORMERLY NS.NASA.GOV
;
. 3600000 NS E.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10
;
; FORMERLY NS.ISC.ORG
;
. 3600000 NS F.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241
F.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:2f::f
;
; FORMERLY NS.NIC.DDN.MIL
;
. 3600000 NS G.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4
;
; FORMERLY AOS.ARL.ARMY.MIL
;
. 3600000 NS H.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET. 3600000 A 198.97.190.53
H.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:1::53
;
; FORMERLY NIC.NORDU.NET
;
. 3600000 NS I.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17
I.ROOT-SERVERS.NET. 3600000 AAAA 2001:7fe::53
;
; OPERATED BY VERISIGN, INC.
;
. 3600000 NS J.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET. 3600000 A 192.58.128.30
J.ROOT-SERVERS.NET. 3600000 AAAA 2001:503:c27::2:30
;
; OPERATED BY RIPE NCC
;
. 3600000 NS K.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET. 3600000 A 193.0.14.129
K.ROOT-SERVERS.NET. 3600000 AAAA 2001:7fd::1
;
; OPERATED BY ICANN
;
. 3600000 NS L.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET. 3600000 A 199.7.83.42
L.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:9f::42
;
; OPERATED BY WIDE
;
. 3600000 NS M.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33
M.ROOT-SERVERS.NET. 3600000 AAAA 2001:dc3::35
; End of file

Кореневі DNS-сервери знаходяться в сейфах, всередині закритих клітин. На сейфі стоять годинник, щоб перевіряти, чи не зламали відеоспостереження. Враховуючи, як повільно працює реалізація DNSSEC, злом одного з цих серверів дозволить зломщикові перенаправити трафік користувачів інтернету. Це сценарій найкрутішого фільму, який ще жодного разу не зняли.
Не дивно, що DNS-сервера топових TLD дуже рідко змінюються. 98% запитів до кореневих DNS-сервера — це запити помилково, зазвичай із-за того, що клієнти не кешують свої результати як треба. Це стало такою проблемою, що кілька операторів кореневих серверів додали спеціальні сервери тільки для того, щоб відповідати «йди!» всім людям, які роблять зворотні запити DNS за своїм локальних IP-адрес.
Сервера TLD адмініструються різними компаніями і урядами по всьому світу (Verisign відповідає за
.com
). Коли ви купуєте домен в зоні
.com
, приблизно 18 центів йде в ICANN, і 7 доларів 85 центів йдуть в Verisign.
Punycode
Рідко буває, що кумедну назву, яке розробники придумали для свого проекту, стає остаточним, публічним ім'ям продукту. Можна назвати бази даних компаній Delaware (тому що в цьому штаті зареєстровані всі компанії), але можна не сумніватися: коли справа дійде до продакшену, вона буде називатися CompanyMetadataDatastore. Але зрідка, коли всі зірки сходяться і начальник у відпустці, одна назва пробирається крізь щілину.
Punycode — це система для кодування unicode в іменах доменів. Проблема, яку вона вирішує, проста: як записати 比薩.com коли всі системи інтернету побудовані навколо алфавіту ASCII, в якому самий екзотичний символ — це тільда?
не Можна просто перемкнути доменні імена на unicode. Вихідні документи, які відповідають за домени, зобов'язують кодувати їх у ASCII. Кожне пристрій в інтернеті за останні сорок років, включаючи маршрутизатори Cisco, Juniper, які використовувалися для доставки цієї сторінки, працюють з урахуванням цього умови.
Сам веб ніколи не обмежувався ASCII. Спочатку стандартом повинен був ISO 8859-1, який включав в себе всі символи ASCII, плюс набір спеціальних символів на зразок ¼ та літери з діакритичними знаками на кшталт ä. Але цей стандарт включав тільки латинські символи.
Це обмеження HTML'а було остаточно виключено 2007, і в тому ж році Юнікод став найпопулярнішим стандартом кодування символів у вебі. Але домени все ще працювали через ASCII.

Як ви могли здогадатися, Punycode не був першою спробою вирішити цю проблему. Ви напевно чули про UTF-8, популярний спосіб кодування Unicode в байти (число 8 у назві "UTF-8" означає 8 біт в одному байті). 2000 кілька членів Інженерного ради Інтернету (Internet Engineering Task Force) придумали UTF-5. Ідея полягала в кодуванні Юнікод пятибитными наборами. Далі кожні п'ять біт зв'язувалися з дозволеним символом (A-V і 0-9) в доменних іменах. Наприклад, якщо б у мене був сайт про вивчення японської мови, то адреса 日本語.com перетворився б у загадковий M5E5M72COA9E.com.
У такого методу є кілька недоліків. По-перше, символи A-V і 0-9 використовуються в закодованому виведення. Тобто, якщо потрібно використовувати один з цих символів в самій назві домену, то їх довелося б кодувати як і інші символи. Виходять дуже довгі імена, і це серйозна проблема: кожен сегмент домену обмежений 63 символами. Домен на Бирманского мовою був би обмежений 16 символами. Але у всій цій затії є цікаві наслідки, наприклад, Юнікод таким чином можна передавати через код Морзе або телеграмою.
Окремим питанням було те, як клієнти будуть розуміти, що домен був закодований саме таким способом, і можна показувати користувачеві реальне ім'я замість M5E5M72COA9E.com в адресному рядку. Було кілька пропозицій, наприклад, задіяти невикористану біт у відповіді DNS. Але це був «останній невикористану біт в заголовку», і люди, які відповідають за DNS «дуже не хотіли віддавати його».
Ще одна ідея полягала в тому, щоб додавати
ra--
на початку кожного доменного імені, яке використовує цей спосіб кодування. час (середина квітня 2000 року) не було ні одного домену, який починався б з
ra--
. Я знаю інтернет, тому впевнений: хто-то відразу купив домен
ra—
всім на зло відразу після публікації того, пропозиції.
Остаточне рішення було прийнято в 2003 — використовувати формат Punycode. Він включав в себе дельта-кодування, яке допомагало значно скоротити закодовані доменні імена. Дельта-кодування — це особливо хороша ідея у випадку з доменами, тому що швидше за все всі символи доменного імені знаходяться приблизно в одній області таблиці Unicode. Наприклад, два символи з Фарсі будуть ближче один до одного, ніж символ з Фарсі і символ з Хінді. Щоб зрозуміти, як це працює, давайте поглянемо на приклад з такої безглуздої фрази:
يذؽ
У незакодированном вигляді це три символи
[1610, 1584, 1597]
(на основі їх положення в Юнікод). Щоб закодувати їх, давайте спочатку відсортуємо їх (запам'ятавши вихідний порядок):
[1584, 1597, 1610]
. Тепер можна зберегти найменше значення (
1584
), і відстань (дельту) до наступного символу
13
), і до наступного (
23
), так що передавати і зберігати потрібно менше інформації.
Далі Punycode ефективно (дуже ефективно!) кодує ці цілі числа, символи, дозволені в доменних іменах, і додає
xn—
в початок рядка щоб повідомити клієнтів про кодування імені. Можна помітити, що всі символи Юнікоду зібрані в кінці домену. Вони зберігають не лише значення символів, але і їх положення в імені. Наприклад, адреса 熱狗sales.com перетвориться на
xn--sales-r65lm0e.com
. Коли ви вводите символи Юнікоду в адресний рядок браузера, вони завжди кодуються таким способом.
Ця трансформація могла б бути прозорою, але тоді може виникнути серйозна проблема безпеки. Є символи Юнікоду, які виводяться на екран ідентично існуючих символів ASCII. Наприклад, ви швидше за все не помітите різницю між кириличної літери «а» і латинської «a»). Якщо я зареєструю кириличний аmazon.com (xn--mazon-3ve.com), то ви можете не зрозуміти, що перебуваєте на іншому сайті. З цієї причини на сайті .ws, виглядає у вашому браузері нудно:
xn--vi8hiv.ws
.
Протокол
Перша частина URL — це протокол, по якому потрібно виробляти з'єднання. Найпоширеніший протокол це
http
. Це простий протокол для передачі документів, що Тім Бернерс-Лі розробив спеціально для інтернету. Це був не єдиний варіант. Деякі вважали, що потрібно використовувати Gopher. Gopher був розроблений спеціально для відправки структурованих даних, за аналогією зі структурою файлового дерева.
Наприклад, при запиті на
/Cars
можна отримати таку відповідь:
1Chevy Camaro /Archives/cars/cc gopher.cars.com 70
iThe Camero is a classic fake (NULL) 0
iAmerican Muscle car fake (NULL) 0
1Ferrari 451 /Factbook/ferrari/451 gopher.ferrari.net 70

Він представляє два автомобіля, додаткову мета-інформацію про них і вказівку адреси, де можна отримати більше інформації. Ідея була в тому, що клієнт обробляє цю інформацію і приведе її в зручний вид, де записи пов'язані з кінцевими сторінками.

Першим популярним протоколом був FTP. Його створили в 1971 році для отримання списків і завантаження файлів на віддалених машинах. Gopher був логічним продовженням цієї ідеї, так як він пропонував схожий лістинг, але також включав механізми отримання мета-інформації про записи. Це означає, що його можна було використовувати і для інших завдань, на зразок стрічки новин або простої бази даних. Однак, йому не вистачало волі і простоти, які характеризують HTTP і HTML.
HTTP — це дуже простий протокол, особливо в порівнянні з альтернативами зразок FTP або навіть HTTP/2, популярність якого росте. По-перше, HTTP повністю текстовий, в ньому не використовуються магічні бінарні елементи (які могли б значно поліпшити продуктивність). Тім Бернерс-Чи правильно вирішив, що текстовий формат дозволить поколінням програмістів легше розробляти і налагоджувати програми, що використовують HTTP.
HTTP також не робить ніяких припущень із приводу змісту. Незважаючи на те, що він був розроблений спеціально для передачі HTML, він дозволяє вказати тип утримання (з допомогою MIME
Content-Type
, який був новим винаходом в свій час). Сам протокол досить простий.
Запит:
GET /index.html HTTP/1.1
Host: www.example.com

Можливу відповідь:
HTTP/1.1 200 OK
Date: Mon, 23 May 2005 22:38:34 GMT
Content-Type: text/html; charset=UTF-8
Content-Encoding: UTF-8
Content-Length: 138
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
ETag: "3f80f-1b6-3e1cb03b"
Accept-Ranges: bytes
Connection: close

<html>
<head>
<title>An Example Page</title>
</head>
<body>
Hello World, this is a very simple HTML document.
</body>
</html>

Щоб вловити контекст, згадайте, що в основі мережі лежить IP протокол інтернету. IP відповідає за передачу маленького пакета даних (близько 1500 байтів) від одного комп'ютера іншому. Поверх цього — TCP, який відповідає за передачу більш великих блоків даних зразок цілих документів або файлів. TCP здійснює гарантовану доставку з допомогою безлічі IP-пакетів. Поверх цього живе протокол зразок HTTP або FTP, який вказує, який формат даних використовувати для пересилання за допомогою TCP (або UDP або іншого протоколу) щоб передати осмислені і зрозумілі дані.
Іншими словами, TCP/IP посилає купу байтів іншого комп'ютера, а протокол рівня HTTP пояснює, чим є ці байти і що вони означають.
Можна зробити свій протокол, якщо захочеться, збираючи байти з повідомлень TCP як завгодно. Єдина вимога полягає в тому, щоб одержувач говорив тією ж мовою. Тому прийнято стандартизувати ці протоколи.
Звичайно, існують менш важливі протоколи. Наприклад, є протокол цитати Quote of The Day (порт 17), і випадкового символу Random Characters (порт 19). Вони можуть здатися кумедними сьогодні, але вони допомагають зрозуміти важливість універсального протоколу для передачі документів, яким був HTTP.
Порт
Історію Gopher та HTTP можна простежити за їх номерами портів. Gopher — це 70, HTTP 80. Порт для HTTP було встановлено (швидше за все Джоном Постелом з IANA) за запитом Тіма Бернерса-Лі між 1990 і 1992 роками.
Концепція реєстрації «номерів портів» з'явилася ще до інтернету. В оригінальному протоколі NCP, на якому працювала мережа ARPANET, віддалені адреси були ідентифіковані за допомогою 40 бітів. Перші 32 вказували на віддалений хост, це схоже на те, як IP працює сьогодні. Останні 8 біт називалися також AEN («Another Eight-bit Number» або «Ще одне восьмибитное число»), і використовувалися для схожих з портом цілей: розділити повідомлення, що мають різні призначення. Іншими словами, адреса вказував на машину, куди потрібно доставити повідомлення, а AEN (або номер порту) вказував на додаток, якому потрібно надіслати повідомлення.
Вони швидко запросили, щоб користувачі реєстрували ці «номери сокетів» для обмеження потенційних колізій. Коли номери портів розширили до 16 біт в TCP/IP, процес реєстрації продовжився.
Не дивлячись на те, що в протоколів є порт за замовчуванням, має сенс дозволяти вручну вказувати порт для спрощення розробки локальної роботи з кількома сервісами на одній машині. Така ж логіка лежала в основі додавання
www.
адреси сайтів. У той час було складно уявити, щоб хтось отримував доступ до кореня свого домену щоб лише захостить «експериментальний» веб-сайт. Але якщо давати користувачам ім'я хоста для конкретної машини (
dx3.cern.ch
), то почнуться проблеми коли з'явиться необхідність замінити машину. Якщо використовувати загальний піддомен (
www.cern.ch
), то можна вільно змінювати місце, куди вказує цю адресу.
Те, що посередині
Ви, напевно, знаєте, що в URL подвійний слеш (
//
) стоїть між протоколом і другою частиною:
http://eager.io

Цей подвійний слеш був успадкований від комп'ютерної системи Apollo, яка була однією з перших мережевих робочих станцій. У команди Apollo з'явилася така ж проблема, що у Тіма Бернерса-Лі: їм потрібен був спосіб відокремлювати шлях від машини, в якій знаходиться цей шлях. Вони вирішили придумати спеціальний формат для шляху:
//ім'я комп'ютера/file/path/as/usual

І сер Тім скопіював цю схему. Насправді, тепер він шкодує про це рішення. Він хотів би, щоб домен (в нашому прикладі
example.com
) був би першою частиною шляху:
http:com/example/foo/bar/baz

Все інше
Ми розповіли про компонентах URL, які потрібні для підключення до конкретного додатком на віддаленій машині десь в інтернеті. У продовженні цієї статті ми поговоримо про компоненти URL, які обробляються віддаленим додатком, щоб повернути відповідь. Це шлях, фрагменти, запити і авторизація.
Хотілося б включити все це в один пост, але розмір вже починає лякати читачів. Але друга частина буде коштувати витраченого часу. Ми обговоримо альтернативні форми URL, які обмірковував Тім Бернерс-Лі, історію форм і як придумали синтаксис параметрів GET-запиту, і як 15 років сперечаються про спосіб створення незмінних URL.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.