<center>
[[Файл:DomainNameSystem.jpg]]
</center>

{|class="wikitable" width=300px align=right
! Назва:
| Domain Name Server
|-
! Рівень (по моделі OSI):
| Прикладний
|-
! Сімейство:
| TCP/IP
|-
! Порт/ID:
| 53/TCP, 53/UDP
|-
! Призначення протоколу:
| Розширення доменних імен
|-
! Специфікація:
| RFC 1034 , RFC 1035 / STD 13
|-
! Основні реалізації (клієнти):
| Вбудована у всі мережеві ОС
|-
! Основні реалізації (сервери):
| BIND, PowerDNS або Microsoft DNS Server
|}

'''DNS''' (англ. ''Domain Name System'' - система доменних імен) - це розподілена комп'ютерна система для отримання інформації про домени. Найчастіше використовується для отримання IP-адреси по імені хоста (комп'ютера або пристрою), отримання інформації про маршрутизацію пошти , обслуговуваних вузлах для протоколів у домені (SRV-запис).

Розподілена база даних DNS підтримується за допомогою ієрархії DNS-серверів, взаємодіючи за певним протоколом.

Основою DNS є представлення про ієрархічну структуру доменного імені та зонах.
*Кожен сервер, відповідаючи за ім'я, може делегувати відповідальність за подальшу частину домену іншому серверу (з адміністративної точки зору - іншій організації або людині), що дозволяє покласти відповідальність за актуальність інформації на сервери різноманітних організацій (людей), відповідаючи тільки за «свою» частину доменного імені.

*Зона (zone) це окремо адмініструються частина дерева DNS. Наприклад, домен другого рівня '''''noao.edu''''' це окрема зона. Багато доменів другого рівня поділені на менші зони. Наприклад, університет може поділити свою зону на підзони по факультетах, а компанія може поділити себе на зони за принципом поділу на філії або відділи.

== Ключові характеристики DNS ==
DNS володіє наступними характеристиками:
* '''''Розподільність адміністрування'''''. Відповідальність за різні частини ієрархічної структури несуть різні люди та організації.
* '''''Розподільність збереження інформації'''''. Кожен вузол мережі в обов'язковому порядку повинен зберігати тільки ті данні, які належать до його зону відповідальності і (можливо) адреси кінцевих DNS-серверів.
* '''''Кеширування інформації'''''. Вузол може зберігати деяку кількість даних не із власної зони відповідальності для зменшення навантаження на мережу.
* '''''Ієрархічна структура''''', у якій усі вузли об'єднані у дерево, а кожен вузол може або самостійно визначати роботу нижчих за ієрархію вузлів, або делегувати ( передавати) їх іншим вузлам.
* '''''Резервування'''''. За збереження та обслуговування своїх вузлів (зон) відповідають (зазвичай) декілька серверів, розподілених як фізично, так і логічно, що забезпечує зберігання даних та продовження роботи навіть у разі виходу з ладу одного з вузлів.

DNS важлива для роботи мережі Інтернет, так як для з'єднання з вузлом необхідна інформація про його IP-адресу, а для людей легше запам'ятати символьні (зазвичай змістовні) адреси, ніж послідовність цифр IP-адрес. У деяких випадках це дозволяє використовувати віртуальні сервери, наприклад, HTTP-сервери, розрізняючи їх по імені запиту. Спочатку перетворення між доменними та IP-адресами відбувалося з використанням спеціального текстового файлу '''hosts''', який складався централізовано та автоматично відправлявся на кожну з машин у своїй локальній мережі. З ростом Мережі виникла необхідність в ефективному, автоматизованому механізмі, яким і стала DNS.

DNS була розроблена Полом Мокапетрісом у 1983 році; оригінальне опис механізмів роботи міститься в стандартах RFC 882 та RFC 883. У 1987 публікація RFC 1034 і RFC 1035 змінила специфікацію DNS і скасувала RFC 882 та RFC 883 як застарілі.

== Додаткові можливості ==
* Підтримка динамічних оновлень
'''Захист даних ('''DNSSEC''') і транзакцій ('''TSIG''')'''
Криптографічні підпису DNSSEC застосовуються до даних по зоні, динамічним оновленням і транзакцій DNS. Крім того, вони використовуються для підтвердження відсутності даних DNS. DNSSEC передбачає три нові записи ресурсів - KEY RR, SIG RR і NXT RR.

KEY RR містить відкритий ключ, що належить імені домена, вказаною в KEY RR. Це не сертифікат відкритого ключа. Механізм забезпечення можливостей пошуку сертифікатів відкритих ключів передбачається DNSSEC WG, але не для цілей захисту даних DNS. Він надається в якості додаткового бонусу, завдяки якому DNS може застосовуватися для запиту сертифікатів відкритих ключів на все, що може бути представлено за допомогою імені домену. Цю можливість забезпечує CERT RR.

SIG RR містить переважно криптографічний підпис, дату закінчення терміну придатності підпису і визначення даних DNS, до яких ця підпис ставиться. NXT RR дозволяє перевірити (за рахунок використання криптографії), що RR для даного імені DNS не існує. Таким чином, відсутність даної RR може бути підтверджено доказово.

Іншим аспектом DNSSEC є підпис транзакції (Transaction Signature, TSIG). TSIG відрізняється від інших підписів DNS тим, що вона створюється з використанням шифрування з секретними ключами. Ми розглянемо TSIG пізніше.

Протокол DNSSEC як такої не забезпечує конфіденційності даних або контролю доступу. Однак конкретні його реалізації можуть передбачати ті чи інші механізми забезпечення конфіденційності і контролю доступу. Причина відсутності такого стандартного механізму в DNS в тому, що вихідний протокол DNS призначався для роботи з загальнодоступними даними. Заклопотаність витоком інформації щодо імен та місцезнаходження систем і можливість атак на кшталт "відмова в обслуговуванні" породжує попит на механізми забезпечення конфіденційності і контролю доступу. Цей попит відбивається в реалізаціях DNS.

[[Файл:Dnsdef2.jpg|600px | center]]

Наприклад, реалізація BIND передбачає контроль доступу для запобігання пересилання зони не уповноваженою на те системам. Крім того, вона дозволяє заборонити серверів DNS відповідати на запити певних систем. Сьогодні конфіденційність частково забезпечується за рахунок застосування брандмауерів і так званої розщепленої DNS для утруднення доступу з зовнішньої мережі до внутрішньої інформації DNS.

Internet Software Consortium (ISG) - некомерційна організація, що займається реалізацією базових протоколів Internet у вигляді відкритих кодів, - додала два механізми захисту для наділення сервера DNS можливостями DNSSEC. Перший визначає автентичність даних в системі на підставі перевірки факту їх підписи адміністратором вузла, від якого вони нібито вчинили

* Підтримка різноманітних типів інформації (SRV-записи)

== Термінологія і принципи роботи ==
Основна область застосування DNS це перетворення імені хоста (Під "хостом" мається на увазі комп'ютер або сервер, підключеної до локальної мережі, або інтернету.) в IP-адресу та надання даних про маршрутизації пошти.

Принцип роботи.
Коли користувач запускає веб-браузер в вводить назву домену сайту, його ПК відправляє запит до DNS-сервера інтернет-провайдера для отримання IP-адреси, на якому знаходиться домен (1).
Якщо DNS-сервери провайдера не виявляють у своєму кеші інформації про запитуваній сайт, то відправляють запит на кореневі DNS-сервери (2).

Кореневий DNS-сервер шукає в своїй базі даних інформацію про сервери імен хостинг-провайдера, на яких присутній цей сайт. Далі, він повідомляє з кешируючого DNS-сервера провайдера (3).

Після того, як кешуючий DNS-сервер провайдера отримує інформацію про сервери імен провайдера він опитує будь-який з них (4) і, у разі отримання позитивного результату отримання IP-адреси (5), поміщає в кеш (Кешування використовується для того, щоб знизити як навантаження на інтернет-канали, так і для прискорення отримання результату запиту).
Після цього DNS-сервер провайдера передає IP-адреса браузеру користувача, який здійснив запит сайту (6).

І вже після цього браузер, отримавши IP-адреса запитуваного сайту, переходить на сам сайт (7 і 8).
<center>
[[Файл:workDNS.jpg]]
</center>

'''Ключовими поняттями DNS є:'''
* '''''Домен''''' (англ. domain - область) - вузол в дереві імен, разом з усіма підлеглими йому вузлами (якщо такі є), тобто іменована ''гілка'' або ''піддерево'' в дереві імен. Структура доменного імені зображає порядок проходження вузлів в ієрархії; доменне ім'я читається зліва направо від молодших доменів до доменів вищого рівня (в порядку підвищення значимості), кореневим доменом всієї системи є крапка ('.'), нижче йдуть домени першого рівня (географічні або тематичні ), потім - домени другого рівня, третього і т. д. (наприклад, для адреси '''ua.wikipedia.org''' домен першого рівня - '''org''', другого '''wikipedia''', третього '''ua'''). На практиці крапку в кінці імені часто опускають, але вона буває важлива у випадках поділу між відносними доменами і FQDN (англ. ''Fully Qualifed Domain Name'', повністю визначене ім'я домену).
* '''''Піддомен''''' (англ. subdomain) - підлеглий домен. (Наприклад, '''wikipedia.org''' - піддомен домену '''org''', а '''ua.wikipedia.org''' - домену '''wikipedia.org'''). Теоретично такий розподіл може досягати глибини 127 рівнів, а кожна мітка може містити до 63 символів, поки загальна довжина разом з точками не досягне 254 символів. Але на практиці реєстратори доменних імен використовують більш суворі обмеження. Наприклад, якщо у вас є домен виду '''mydomain.ru''', ви можете створити для нього різні піддомени виду '''mysite1.mydomain.ru''', '''mysite2.mydomain.ru''' і т. д.
* '''''Ресурсний запис''''' - одиниця зберігання і передачі інформації в DNS. Кожний ресурсний запис має ім'я (тобто прив'язаний до певного доменного імені, вузлу в дереві імен), тип і поле даних, формат і зміст якого залежить від типу.
* '''''Зона''''' - частина дерева доменних імен (включаючи ресурсні записи), що розміщується як єдине ціле на деякому сервері доменних імен (DNS-сервер), а частіше - одночасно на декількох серверах. Метою виділення частини дерева в окрему зону є передача відповідальності за відповідний Домен іншій особі або організації, так зване Делегування. Як зв'язкова частина дерева, зона всередині теж являє собою дерево. Якщо розглядати простір імен DNS як структуру із зон, а не окремих вузлів / імен, теж виходить дерево; виправдано казати про батьківські і дочірні зони, про старших і підлеглих. На практиці, більшість зон 0-го і 1-го рівня ('.', '''ru''', '''com''', ...) складаються з єдиного вузла, якому безпосередньо підпорядковуються дочірні зони. У великих корпоративних доменах (2-го і більше рівнів) іноді зустрічається утворення додаткових підлеглих рівнів без виділення їх у дочірні зони.
* '''''Делегування''''' - операція передачі відповідальності за частину дерева доменних імен іншій особі або організації. За рахунок делегування в DNS забезпечується розподільність адміністрування та зберігання. Технічно делегування виражається у виділенні цієї частини дерева в окрему зону, та розміщення цієї зони на DNS-сервер, керованому цією особою чи організацією. При цьому в батьківську зону включаються «склеюючи» ресурсні записи ('''NS''' і '''А'''), що містять покажчики на DNS-сервера дочірньої зони, а вся інша інформація, що відноситься до дочірньої зоні, зберігається вже на DNS-серверах дочірньої зони.
* '''''[[DNS сервер|DNS-сервер]]''''' - спеціалізоване ПО для обслуговування DNS, а також комп'ютер, на якому це ПЗ виконується. DNS-сервер може бути відповідальним за певні зони і / або може перенаправляти запити серверам, що знаходяться вище за ієрархією.
* '''''[[DNS клієнт|DNS-клієнт]]''''' - спеціалізована бібліотека (або програма) для роботи з DNS. У ряді випадків DNS-сервер виступає в ролі DNS-клієнта.
* '''''Авторитетність''''' (англ. authoritative) - ознака розміщення зони на DNS-сервері. Відповіді DNS-сервера можуть бути двох типів: ''авторитетні'' (коли сервер заявляє, що сам відповідає за зону) і ''неавторитетний'' (англ. Non-authoritative), коли сервер обробляє запит, і повертає відповідь інших серверів. У деяких випадках замість передачі запиту далі DNS-сервер може повернути вже відоме йому (за запитами раніше) значення (режим кешування).
* '''''[[DNS запити|DNS-запит]]''''' (англ. DNS query) - запит від клієнта (або сервера) серверу. Запит може бути ''рекурсивним'' або ''нерекурсивним''.

Система DNS містить ієрархію DNS-серверів, відповідну до ієрархії зон. Кожна зона підтримується як мінімум одним авторитетним сервером DNS (від англ. ''Authoritative'' - авторитетний), на якому розташована інформація про домен.

Ім'я та IP-адреса не тотожні - одина IP-адреса може мати безліч імен, що дозволяє підтримувати на одному комп'ютері безліч веб-сайтів (це називається віртуальний хостинг). Зворотне теж справедливо - одному імені можна порівнювати безліч IP-адрес: це дозволяє створювати балансування навантаження.

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

=== [[Рекурсія]] ===

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

'''DNS- запит''' може бути ''рекурсивним'' - що вимагає повного пошуку, - і ''нерекурсивним'' (чи ''ітеративним'') - що не вимагає повного пошуку.

Аналогічно, '''DNS- сервер''' може бути ''рекурсивним'' (що уміє виконувати повний пошук) і ''нерекурсивним'' (що не уміє виконувати повний пошук). Деякі програми DNS- серверів, наприклад, BIND, можна конфігурувати так, щоб запити одних клієнтів виконувалися ''рекурсивно'', а запити інших - ''нерекурсивний''.

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

У разі ''рекурсивного'' запиту '''DNS- сервер''' опитує сервери(в порядку убування рівня зон в імені), поки не знайде відповідь або не виявить, що домен не існує. (На практиці пошук розпочинається з найбільш близьких до шуканого DNS- серверів, якщо інформація про них є в кеші і не застаріла, сервер може не просити інші DNS- сервери.)

Розглянемо на прикладі роботу усієї системи.

Припустимо, ми набрали в браузері адресу <tt>ru.wikipedia.org</tt>. Браузер запитує у сервера DNS : "яка IP- адреса у <tt>ru.wikipedia.org</tt>"?
Проте, сервер DNS може нічого не знати не лише про запрошене ім'я, але навіть про увесь домен <tt>wikipedia.org</tt>.
В цьому випадку сервер звертається до ''кореневого серверу'' - наприклад, 198.41.0.4. Цей сервер повідомляє - "У мене немає інформації про цю адресу, але я знаю, що 204.74.112.1 є відповідальним за зону <tt>org</tt>". Тоді сервер DNS направляє свій запит до 204.74.112.1, але той відповідає "У мене немає інформації про цей сервер, але я знаю, що 207.142.131.234 є відповідальним за зону <tt>wikipedia.org</tt>". Нарешті, той же запит вирушає до третього DNS- сервера і отримує відповідь - IP- адреса, яка і передається клієнтові - браузеру.

В даному випадку при дозволі імені, тобто в процесі пошуку IP по імені:
* браузер відправив відомому йому DNS- серверу ''рекурсивний'' запит - у відповідь на такий тип запиту сервер зобов'язаний повернути "готовий результат", тобто IP- адреса, або порожня відповідь і код помилки NXDOMAIN;
* DNS- сервер, що отримав запит від браузеру, послідовно відправляв ''нерекурсивні'' запити, на які отримував від інших DNS- серверів відповіді, поки не отримав відповідь від сервера, відповідального за запрошену зону;
* інші згадувані DNS- сервери обробляли запити ''нерекурсивний'' (і, швидше за все, не стали б обробляти запити рекурсивно, навіть якщо б така вимога стояла в запиті).

Іноді допускається, щоб запрошений сервер передавав ''рекурсивний'' запит "вищестоящому" DNS- серверу і чекав готової відповіді.

При ''рекурсивній'' обробці запитів усі відповіді проходять через DNS- сервер, і він дістає можливість ''кешуровати'' їх. Повторний запит на ті ж імена зазвичай не йде далі ''за кеш'' сервера, звернення до інших серверів не відбувається взагалі. Допустимий час зберігання відповідей в ''кеші'' приходить разом з відповідями(поле ''TTL'' '''ресурсного запису''').

Рекурсивні запити вимагають більше ресурсів від сервера(і створюють більше трафіку), так що зазвичай приймаються від "відомих" власникові сервера вузлів(наприклад, провайдер надає можливість робити рекурсивні запити тільки своїм клієнтам, в корпоративній мережі рекурсивні запити приймаються тільки з локального сегменту). Нерекурсивні запити зазвичай приймаються від усіх вузлів мережі(і змістовна відповідь дається тільки на запити про зону, яка розміщена на вузлі, на DNS- запит про інші зони зазвичай повертаються адреси інших серверів).

=== Зворотний DNS- запит ===
DNS використовується в першу чергу для перетворення символьних імен в IP- адреси, але він також може виконувати зворотний процес. Для цього використовуються вже наявні засоби DNS. Річ у тому, що із записом DNS можуть бути зіставлені різні дані, у тому числі і яке-небудь символьне ім'я. Існує спеціальний домен <tt>in - addr.arpa</tt>, записи в якому використовуються для перетворення IP- адрес в символьні імена. Наприклад, для отримання DNS- імені для адреси <tt>11.22.33.44</tt> можна запросити у DNS- сервера запис <tt>44.33.22.11.in - addr.arpa</tt>, і той поверне відповідне символьне ім'я. Зворотний порядок запису частин IP- адреси пояснюється тим, що в IP- адресах старші біти розташовані на початку, а в символьних DNS- іменах старші(що знаходяться ближче до кореня) частини розташовані у кінці.

== Приклад структури доменного імені ==
<center>
[[Файл:Dnsexam.jpg]]
</center>
Першочерговим завданням DNS-сервера є забезпечення трансляції доменних імен в IP-адреси. Для адресації вузлів Інтернету використовуються спеціальні числові «коди» - IP-адреси. Система доменних імен якраз служить для виконання перетворень між символьними і числовими адресами. Традиційна IP-адреса може бути записана за допомогою чотирьох чисел в десятковій системі числення, наприклад: 192.168.175.13 або 194.85.92.93.

DNS дозволяє зіставити числову IP-адресу і символьну, наприклад: 194.85.92.93 = test.ru. При цьому символьна адреса в DNS являє собою текстовий рядок, складений за особливими правилами. Найважливіше з цих правил - ієрархія доменів.

Система адрес DNS має деревоподібну структуру. Вузли цієї структури називаються доменами. Кожен домен може містити безліч «підлеглих» доменів. Основою даної ієрархічної структури імен т.зв. "Корінь дерева" є точка ("."). Корінь єдиний для всіх доменів. Як правило, при введенні URL, крапка наприкінці адреси не ставиться, проте вона використовується в описах DNS. Цікаво, що про існування кореневого домену зараз пам'ятають лише фахівці. Втім, його можна і вказати. Адресний рядок із зазначенням кореневого домену виглядає, наприклад, так: «site.test.ru.» - тут кореневий домен відділений останньої, крайньої праворуч, крапкою.

Нижче кореня лежать домени першого рівня (зони). Їх небагато - COM, NET, ORG, MIL, BIZ, INFO, GOV (є ще кілька) і домени держав, наприклад, RU. Ще нижче знаходяться домени другого рівня, наприклад, test.ru. Ще нижче - третього і т.д. Рівні розділяються крапками.

DNS сервер не ізольований. Кожному DNS-СЕРВЕРУ відомі адреси кореневих DNS-серверів. При запиті, DNS-сервер або сам знає відповідь, або знає у кого запитати. Якщо простежити проходження запиту, картина складається досить цікаво. При налаштуванні користувачеві вказується два DNS сервера (первинний і вторинний). Адреси dns серверів вказується провайдером.

Користувач відправляє запит первинному DNS серверу. Сервер, у свою чергу, отримавши запит, або відповідає, якщо відповідь йому відома, або відправляє запит на вищого рівня сервер. Якщо вищого рівня сервер не відомий, запит відправляється на кореневий DNS сервер. Так виглядає висхідна (восходящяя) ієрархія. Далі запит починає спускатися вниз від кореневого сервера до сервера першого рівня, той – до СЕРВЕРУ другого рівня і т.д.

DNS сервера бувають рекурсивними і нерекурсивними. Рекурсивні сервера завжди повертають користувачеві відповідь. Тобто, вони самостійно опитують інші DNS сервера. Рекурсивні сервера зручно використовувати в локальних мережах. Вони кешують проміжні відповіді, таким чином, при наступних запитах відповіді будуть повертатися набагато швидше. Нерекурсивні сервера повертають користувачеві всі відсилання, так що клієнт повинен самостійно опитувати вказаний сервер. Нерекурсивні сервера зазвичай стоять на верхніх щаблях ієрархії. Вони отримують багато запитів, а для кешування потрібні багато ресурсів. Таким чином, кешування на таких серверах не проводиться.

== Записи DNS ==
Записи DNS, або ''Ресурсні записи'' (англ. Resource Records, RR) - одиниці зберігання і передачі інформації в DNS. Кожен ресурсний запис складається з наступних полів:

* '''''Ім'я''''' (NAME) - доменне ім'я, до якого прив'язана або якому «належить» дана ресурсна запис. Ім'я буває абсолютним (FQDN - Fully Qualified Domain Name) і відносним. Абсолютне ім'я закінчується крапкою. Якщо ж ім'я вказати без крапки в кінці, це ім'я буде вважатися відносним і йому автоматично додається ім'я поточного домену;
* '''''TTL''''' (Time To Live) - допустимий час зберігання даної ресурсної записи в кеші не відповідального DNS-сервера. Даний параметр вказується в секундах;
* '''''Тип''''' (TYPE) ресурсного запису - визначає формат і призначення даного ресурсного запису;
* '''''Клас''''' (CLASS) ресурсного запису; теоретично вважається, що DNS може використовуватися не тільки з TCP / IP, але і з іншими типами мереж, код у полі клас визначає тип мережі;
* '''''Довжина поля даних''''' (RDLEN);
* '''''Поле даних''''' (RDATA), формат і зміст якого залежить від типу запису.

Найбільш важливі типи DNS-записів:

* '''''Запис A''''' (''address record'') або запис адреси, що зв'язує ім'я хоста з IP адресою. Наприклад, запит A-запису на ім'я '''''referrals.icann.org''''' поверне його IP адресу - '''''192.0.34.164'''''
* '''''Запис AAAA''''' (''IPv6 address record'') зв'язує ім'я хоста з адресою протоколу '''IPv6'''. Наприклад, запит AAAA-запису на ім'я '''''K.ROOT-SERVERS.NET''''' поверне його '''IPv6''' адресу - '''''2001:7 fd:: 1'''''
* '''''Запис CNAME''''' (''canonical name record'') або канонічний запис імені (псевдонім) використовується для перенаправлення на інше ім'я
* '''''Запис MX''''' (''mail exchange'') або поштовий обмінник вказує сервер обміну поштою для даного домену.
* '''''Запис NS''''' (''name server'') вказує на DNS-сервер для даного домену.
* '''''Запис PTR''''' (''pointer'') або запис покажчика, що зв'язує IP адресу хоста з його канонічним ім'ям. Запит у домені '''''in-addr.arpa''''' на IP хоста в ''reverse'' формі поверне ім'я ('''FQDN''') даного хоста.
* '''''Запис SOA''''' (''Start of Authority'') або початковий запис зони вказує, на якому сервері зберігається еталонна інформація про даний домен, містить контактну інформацію особи, відповідального за дану зону, таймінги (параметри часу) кешування зонної інформації та взаємодії DNS-серверів.
* '''''Запис SRV''''' (''server selection'') вказує на сервери для сервісів, використовується, зокрема, для '''''Jabber''''' і '''''Active Directory'''''.
* '''''Запис TXT''''' коментарі або якась інша інформація
* '''''Запис HINFO''''' опис "заліза" комп'ютера

'''Базовий формат запису виглядає так:'''

[ім'я] [час] [клас] [тип] [дані]

== Зарезервовані доменні імена ==
Документ RFC 2606 (Reserved Top Level DNS Names - Зарезервовані імена доменів верхнього рівня) визначає назви доменів, які слід використовувати в якості прикладів (наприклад, в документації), а також для тестування. Крім '''''example.com''''', '''''example.org''''' і '''''example.net''''', до цієї групи також входять '''''test''''', '''''invalid''''' та ін.

== Інтернаціональні доменні імена ==
Доменне ім'я може складатися тільки з обмеженого набору '''ASCII''' символів, дозволяючи набрати адресу домену незалежно від мови користувача. '''ICANN''' затвердив засновану на '''''Punycode''''' систему '''IDNA''', перетворюючи будь-який рядок в кодуванні ''Unicode'' в допустимий DNS набір символів.

== Програмне забезпечення DNS ==
Сервери імен:
* '''BIND''' (Berkeley Internet Name Domain)
* '''Djbdns''' (Daniel J. Bernstein 's DNS)
* '''MaraDNS'''
* '''NSD''' (Name Server Daemon)
* '''PowerDNS'''
* '''OpenDNS'''
* '''Microsoft DNS Server''' (в серверних версіях операційних систем Windows NT)
* '''MyDNS'''

== Інформація про домен ==
Багато доменів верхнього рівня підтримують сервіс '''''whois''''', який дозволяє дізнатися, кому делеговано домен і іншу технічну інформацію.

== Реєстрація домену ==
Реєстрація домену - процедура отримання доменного імені. Полягає у створенні записів, що вказують на адміністратора домену, в базі даних DNS. Порядок реєстрації та вимоги залежать від обраної доменної зони. Реєстрація домену може бути виконана як організацією-реєстратором, так і приватною особою, якщо це дозволяють правила обраної доменної зони.

[[Служба DNS]]

== [[Сторінка питань з DNS/DHCP]] ==

[[category:Комп'ютерні мережі]]

Accelerated Mobile Pages (AMP)

2018-11-08T09:32:12Z

3524693: /* Групи в amp-geo */

<center>
[[Файл:Accelerated_Mobile_Pages.jpg|600px]]
</center>

'''Accelerated Mobile Pages'''
Accelerated Mobile Pages (AMP) – це технологія з відкритим вихідним кодом, що дозволяє створювати веб-сторінки, які швидко завантажуються в мобільному браузері. Використовуючи AMP-версії цільових сторінок, ви підвищуєте зручність роботи з вашим сайтом для мобільних користувачів.
Створено компанією Google в 2015 році.
По суті всі подібні сторінки є статичними або умовно-динамічними, так як припускають використання відправки форм, а також iframe.

Справа в тому, що на сайті використовуються спеціальні теги, кількість і функціонал яких строго обмежені. Завдання розробника полягає в тому, щоб зібрати те що треба з доступних йому схем, які вирішать проблему замовника.
Google знаходе ці спеціальні теги і кешує інформацію в них. Після цього, коли користувач шукає щось в Гуглі, браузер на тлі підгружає інформацію з CDN Гугла, в спеціальний iframe і при переході по посиланню відкриває вже завантажену сторінку в спеціальному вікні.
Сторінки з AMP ранжуються вище інших запитів в пошуку за рахунок того, що відповідають вимогам до швидкої завантаженні і адаптовані під мобільні пристрої

==Історія==
Проект AMP був анонсований компанією Google 7 жовтня 2015 року. Більше 30 новинних видань та декількох технологічних компаній, включаючи Twitter, Pinterest, LinkedIn та WordPress, були попередньо оголошені в якості партнерів проекту AMP.

Вперше протестувати технологію користувачам вдалося в лютому 2016 року, коли Google почав показувати версії AMP веб-сторінок у результатах мобільного пошуку. Ссылки AMP в пошукової системі Google ідентифікуються значком. У лютому 2017 року, через рік після публічного запуску AMP, компанія Adobe повідомила, що на AMP-сторінках припадає 7% всього веб-трафіка для провідних видань у Сполучених Штатах. У травні 2017 року компанія Google повідомила, що глобальне охоплення технологією швидкого завантаження сторінок складає більше 2 мільярдів AMP-сторінок, опублікованих у всьому світі. В червні 2017 року Twitter розпочав посилання на сторінки AMP від своїх прикладних програм для iOS та Android.

==Переваги використання AMP-сторінок в Google Рекламі==

[[Файл: АМР_ua.jpg|700px]]

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

==Відсутність кастомних скриптів==
Перше і найголовніше на відміну від стандартних сайтів - це неможливість вставки "звичайних" скриптів. Тобто велика частина функціоналу, зав'язана на динамічній зміні (дії при натисканні, анімація, фільтрація, модальні вікна), стає недоступною.
Рішення - використання доступних компонентів і iframe.
Доступні компоненти дозволяють домогтися, нехай і не повною, реалізації звичних фіч, але представляють їм гідну заміну і оптимізовані для швидкого завантаження.
З їх допомогою можна зробити бокове меню, карусель, надсилання форми, під-завантажений контент, рекламу та інше.
Кожен компонент пов'язаний зі своєю js-бібліотекою, яку потрібно підключити для його використання на сайті.

У коді сторінки не повинно бути inline-стилів
Ще одна особливість, яка повинна торкнутися в першу чергу текстового редактора, так як редагування стилів там проходить inline. Елементи з атрибутами типу style = "color: ...", не є валідними, а зміна кольору або розміру шрифту запише це властивість в код.
Структурована схема даних (structured data)

Для включення статей до збірки "Top stories google" до сторінок повинні бути додані схеми даних з короткою інформацією про статті, автора, видавництві, логотип компанії, а також дати публікації і зміни статті.
Використання структурних даних не є обов'язковою умовою, але для того щоб пошуковик коректно відобразив дані і зміни при редагуванні, потрібно поміщати цю схему на сайт. Фактично використання AMP без цієї схеми стає безглуздим.

Приклад схеми даних для сторінки типу "стаття"<br />

<Script>
type = "application / ld + json">{
"@context": "http://photo.org",
"@type": "NewsArticle",
"MainEntityOfPage": {
"@type": "WebPage",
"@id": "https://google.com/photo"
},
"Headline": "Article headline",
"Image": {
"@type": "ImageObject",
"Url": "photo.jpg",
"Height": 800,
"Width": 800
},
"DatePublished": "2015-02-05T08: 00: 00 + 08: 00",
"DateModified": "2015-02-05T09: 20: 00 + 08: 00",
"Author": {
"@type": "Person",
"Name": "John Doe"
},
"Publisher": {
"@type": "Organization",
"Name": "Google",
"Logo": {
"@type": "ImageObject",
"Url": "https://google.com/photo.jpg",
"Width": 600,
"Height": 60
}
},
"Description": "A most wonderful article"
}
</ Script><br />

Деякі значення є обов'язковими. Для структурної схеми даних так само є свій валідатор. Інформація щодо заповнення та обов'язкові поля для схеми типу "стаття" можна подивитися тут.
Там же можна знайти інформацію по іншим типам схем. (Книги, Курси, Музика, Підкасти, Рецепти, Огляди, ТV і Фільми, Відео)

==Деякі особливості==
'''Логотип компанії'''

Є ряд вимог до логотипу: https://developers.google.com/search/docs/data-types/articles#AMPlogo guidelines
Хочу звернути увагу, що розмір повинен бути не більше і не менше 60x600px хоча б по одній зі сторін. Бажано дотримуватися висоту 60px (наприклад, 450x60px). Зображення менших розмірів, але в тих же пропорціях, що і 60x600px (наприклад 450x45px), перевірку не пройдуть.<br />

Дата публікації і дата зміни
Дата публікації є обов'язковим параметром.
Дата зміни - рекомендованим.
Google кешує зміст статей, і дізнатися, коли він піде перевіряти всі статті на сайті знову, неможливо. Тому, якщо дата останнього зміни буде відрізнятися, буде простіше зрозуміти, що потрібно зробити новий кеш. <br />
Інакше можлива ситуація, коли користувач не побачить важливих змін.

==Спільні зусилля==
AMP побудовано завдяки глибокій співпраці з тисячами розробників, видавців та веб-сайтів, платформ поширення та технологічних компаній. На сьогоднішній день опубліковано більше 1.5B сторінок AMP, а 100+ провідних аналітиків, постачальники рекламних технологій та CMS підтримують формат AMP.

==Відсутність звичайних <img> тегів в документі==
Всі зображення на сторінці повинні бути описані в особливому тезі <amp-img>, що ускладнює вставку зображень користувачем через текстовий редактор. Для інших елементів, де висновок зображень прописаний "руками", досить поправити верстку. Так само, якщо використовуються карусель або lightbox, потрібно вставити аналоги з компонентів

==Інтеграція рекламної мережі з компонентом <amp-consent>==

Реалізації DoubleClick і AdSense <amp-ad> тепер підтримують <amp-consent>, включаючи не персональну рекламу. Перегляньте детальну документацію про те, коли і як подавати не персоналізовані оголошення з DoubleClick і AdSense.

'''<amp-ima-video> підтримка <amp-consent>''' Видавці тепер можуть збирати згоду, використовуючи компонент <amp-ima-video>.
Використання параметра <amp-geo> для конфігурації на основі геолокації <amp-consent>
AMP надає спосіб налаштування <amp-consent> з віддаленим викликом, використовуючи поле checkConsentHref . Якщо ви хочете включити логіку на основі геолокації для <amp-consent>, вам потрібно буде вирішити геолокацію на стороні сервера та відповідно налаштувати відповідь checkConsentHref . До цих пір було неможливо мати логіку на основі геолокації без встановлення віддаленого сервера.

'''Компонент <amp-geo>''' нещодавно запущений, щоб увімкнути зміст змісту, виходячи з приблизного місце +знаходження користувачів, на рівні коду країни ISO. Тепер ви можете використовувати цю функцію в поєднанні з <amp-consent>, що також означає, що ви можете пропустити implementation checkConsentHref, якщо ваші потреби в конфігурації не виходять за межі географічного розташування. Оформити замовлення за зразком ampbyexample.com <amp-geo> або документацію <amp-consent> .

'''<amp-consent> підтримка в історіях AMP'''
Незабаром <amp-consent> буде доступний для використання з <amp-story>. Для випадку <amp-story> лише для випадку, більшість інтерфейсу користувача буде попередньо налаштовано, хоча для вибору виразів, що висвітлюють, для виду і відчуття, крім повного контролю над текстовим вмістом, існують вигідні варіанти. Крім того, всі інтерфейси користувача <amp-consent> в історіях AMP будуть блокувати (тобто користувацький інтерфейс для згоди не матиме додаткової кнопки закриття).

'''Нові функції в <amp-consent>'''
support checkConsentHref для пар основних значень: ця функція дозволяє кінцевій точці checkConsentHref реагувати на пари ключових значень, які можуть бути поширені та використані для реалізації рекламної мережі. Це корисно для видавців, які хочуть передавати додаткову інформацію про конфігурацію в рекламні мережі для показу відповідних оголошень. Ця інформація доступна для компонентів AMP, які очікують на <amp-consent> для вирішення.

'''Тайми в <amp-consent>:'''
За допомогою цієї функції видавці можуть розблокувати компоненти, які очікують на згоду після певного тайм-ауту. Функція також дозволяє видавцям налаштувати стан згоди, який буде отримано компонентами AMP, заблокованими за згодою.

==Технологія AMP==
Формат AMP складається з:
AMP HTML - мова HTML, в якому частина тегів замінена на еквівалентні AMP-теги, а частина заборонена для використання.
AMP JS - в роботі використовується власна JS-бібліотека, що дозволяє елементам сторінки завантажувати асинхронно.
Google AMP Cache - в процесі індексування AMP-сторінок, пошукова система кеширует її дані і відтворює зі своїх серверів.
==Як зв'язати оголошення з AMP-сторінкою==
AMP-сторінку можна вибрати як цільову для оголошення, як і будь-яку іншу мобільну сторінку. Вам потрібно лише вказати відповідну URL-адресу в полі "Мобільний URL" для оголошення або ключового слова. Після цього користувачі, натиснувши на оголошення, перейдуть на AMP-сторінку.

Accelerated Mobile Pages (AMP)

2018-11-08T09:30:12Z

3524693: /* Динамічна гео-персоналізація */

<center>
[[Файл:Accelerated_Mobile_Pages.jpg|600px]]
</center>

'''Accelerated Mobile Pages'''
Accelerated Mobile Pages (AMP) – це технологія з відкритим вихідним кодом, що дозволяє створювати веб-сторінки, які швидко завантажуються в мобільному браузері. Використовуючи AMP-версії цільових сторінок, ви підвищуєте зручність роботи з вашим сайтом для мобільних користувачів.
Створено компанією Google в 2015 році.
По суті всі подібні сторінки є статичними або умовно-динамічними, так як припускають використання відправки форм, а також iframe.

Справа в тому, що на сайті використовуються спеціальні теги, кількість і функціонал яких строго обмежені. Завдання розробника полягає в тому, щоб зібрати те що треба з доступних йому схем, які вирішать проблему замовника.
Google знаходе ці спеціальні теги і кешує інформацію в них. Після цього, коли користувач шукає щось в Гуглі, браузер на тлі підгружає інформацію з CDN Гугла, в спеціальний iframe і при переході по посиланню відкриває вже завантажену сторінку в спеціальному вікні.
Сторінки з AMP ранжуються вище інших запитів в пошуку за рахунок того, що відповідають вимогам до швидкої завантаженні і адаптовані під мобільні пристрої

==Історія==
Проект AMP був анонсований компанією Google 7 жовтня 2015 року. Більше 30 новинних видань та декількох технологічних компаній, включаючи Twitter, Pinterest, LinkedIn та WordPress, були попередньо оголошені в якості партнерів проекту AMP.

Вперше протестувати технологію користувачам вдалося в лютому 2016 року, коли Google почав показувати версії AMP веб-сторінок у результатах мобільного пошуку. Ссылки AMP в пошукової системі Google ідентифікуються значком. У лютому 2017 року, через рік після публічного запуску AMP, компанія Adobe повідомила, що на AMP-сторінках припадає 7% всього веб-трафіка для провідних видань у Сполучених Штатах. У травні 2017 року компанія Google повідомила, що глобальне охоплення технологією швидкого завантаження сторінок складає більше 2 мільярдів AMP-сторінок, опублікованих у всьому світі. В червні 2017 року Twitter розпочав посилання на сторінки AMP від своїх прикладних програм для iOS та Android.

==Переваги використання AMP-сторінок в Google Рекламі==

[[Файл: АМР_ua.jpg|700px]]

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

==Відсутність кастомних скриптів==
Перше і найголовніше на відміну від стандартних сайтів - це неможливість вставки "звичайних" скриптів. Тобто велика частина функціоналу, зав'язана на динамічній зміні (дії при натисканні, анімація, фільтрація, модальні вікна), стає недоступною.
Рішення - використання доступних компонентів і iframe.
Доступні компоненти дозволяють домогтися, нехай і не повною, реалізації звичних фіч, але представляють їм гідну заміну і оптимізовані для швидкого завантаження.
З їх допомогою можна зробити бокове меню, карусель, надсилання форми, під-завантажений контент, рекламу та інше.
Кожен компонент пов'язаний зі своєю js-бібліотекою, яку потрібно підключити для його використання на сайті.

У коді сторінки не повинно бути inline-стилів
Ще одна особливість, яка повинна торкнутися в першу чергу текстового редактора, так як редагування стилів там проходить inline. Елементи з атрибутами типу style = "color: ...", не є валідними, а зміна кольору або розміру шрифту запише це властивість в код.
Структурована схема даних (structured data)

Для включення статей до збірки "Top stories google" до сторінок повинні бути додані схеми даних з короткою інформацією про статті, автора, видавництві, логотип компанії, а також дати публікації і зміни статті.
Використання структурних даних не є обов'язковою умовою, але для того щоб пошуковик коректно відобразив дані і зміни при редагуванні, потрібно поміщати цю схему на сайт. Фактично використання AMP без цієї схеми стає безглуздим.

Приклад схеми даних для сторінки типу "стаття"<br />

<Script>
type = "application / ld + json">{
"@context": "http://photo.org",
"@type": "NewsArticle",
"MainEntityOfPage": {
"@type": "WebPage",
"@id": "https://google.com/photo"
},
"Headline": "Article headline",
"Image": {
"@type": "ImageObject",
"Url": "photo.jpg",
"Height": 800,
"Width": 800
},
"DatePublished": "2015-02-05T08: 00: 00 + 08: 00",
"DateModified": "2015-02-05T09: 20: 00 + 08: 00",
"Author": {
"@type": "Person",
"Name": "John Doe"
},
"Publisher": {
"@type": "Organization",
"Name": "Google",
"Logo": {
"@type": "ImageObject",
"Url": "https://google.com/photo.jpg",
"Width": 600,
"Height": 60
}
},
"Description": "A most wonderful article"
}
</ Script><br />

Деякі значення є обов'язковими. Для структурної схеми даних так само є свій валідатор. Інформація щодо заповнення та обов'язкові поля для схеми типу "стаття" можна подивитися тут.
Там же можна знайти інформацію по іншим типам схем. (Книги, Курси, Музика, Підкасти, Рецепти, Огляди, ТV і Фільми, Відео)

==Деякі особливості==
'''Логотип компанії'''

Є ряд вимог до логотипу: https://developers.google.com/search/docs/data-types/articles#AMPlogo guidelines
Хочу звернути увагу, що розмір повинен бути не більше і не менше 60x600px хоча б по одній зі сторін. Бажано дотримуватися висоту 60px (наприклад, 450x60px). Зображення менших розмірів, але в тих же пропорціях, що і 60x600px (наприклад 450x45px), перевірку не пройдуть.<br />

Дата публікації і дата зміни
Дата публікації є обов'язковим параметром.
Дата зміни - рекомендованим.
Google кешує зміст статей, і дізнатися, коли він піде перевіряти всі статті на сайті знову, неможливо. Тому, якщо дата останнього зміни буде відрізнятися, буде простіше зрозуміти, що потрібно зробити новий кеш. <br />
Інакше можлива ситуація, коли користувач не побачить важливих змін.

==Спільні зусилля==
AMP побудовано завдяки глибокій співпраці з тисячами розробників, видавців та веб-сайтів, платформ поширення та технологічних компаній. На сьогоднішній день опубліковано більше 1.5B сторінок AMP, а 100+ провідних аналітиків, постачальники рекламних технологій та CMS підтримують формат AMP.

==Відсутність звичайних <img> тегів в документі==
Всі зображення на сторінці повинні бути описані в особливому тезі <amp-img>, що ускладнює вставку зображень користувачем через текстовий редактор. Для інших елементів, де висновок зображень прописаний "руками", досить поправити верстку. Так само, якщо використовуються карусель або lightbox, потрібно вставити аналоги з компонентів

==Інтеграція рекламної мережі з компонентом <amp-consent>==

Реалізації DoubleClick і AdSense <amp-ad> тепер підтримують <amp-consent>, включаючи не персональну рекламу. Перегляньте детальну документацію про те, коли і як подавати не персоналізовані оголошення з DoubleClick і AdSense.

'''<amp-ima-video> підтримка <amp-consent>''' Видавці тепер можуть збирати згоду, використовуючи компонент <amp-ima-video>.
Використання параметра <amp-geo> для конфігурації на основі геолокації <amp-consent>
AMP надає спосіб налаштування <amp-consent> з віддаленим викликом, використовуючи поле checkConsentHref . Якщо ви хочете включити логіку на основі геолокації для <amp-consent>, вам потрібно буде вирішити геолокацію на стороні сервера та відповідно налаштувати відповідь checkConsentHref . До цих пір було неможливо мати логіку на основі геолокації без встановлення віддаленого сервера.

'''Компонент <amp-geo>''' нещодавно запущений, щоб увімкнути зміст змісту, виходячи з приблизного місце +знаходження користувачів, на рівні коду країни ISO. Тепер ви можете використовувати цю функцію в поєднанні з <amp-consent>, що також означає, що ви можете пропустити implementation checkConsentHref, якщо ваші потреби в конфігурації не виходять за межі географічного розташування. Оформити замовлення за зразком ampbyexample.com <amp-geo> або документацію <amp-consent> .

'''<amp-consent> підтримка в історіях AMP'''
Незабаром <amp-consent> буде доступний для використання з <amp-story>. Для випадку <amp-story> лише для випадку, більшість інтерфейсу користувача буде попередньо налаштовано, хоча для вибору виразів, що висвітлюють, для виду і відчуття, крім повного контролю над текстовим вмістом, існують вигідні варіанти. Крім того, всі інтерфейси користувача <amp-consent> в історіях AMP будуть блокувати (тобто користувацький інтерфейс для згоди не матиме додаткової кнопки закриття).

'''Нові функції в <amp-consent>'''
support checkConsentHref для пар основних значень: ця функція дозволяє кінцевій точці checkConsentHref реагувати на пари ключових значень, які можуть бути поширені та використані для реалізації рекламної мережі. Це корисно для видавців, які хочуть передавати додаткову інформацію про конфігурацію в рекламні мережі для показу відповідних оголошень. Ця інформація доступна для компонентів AMP, які очікують на <amp-consent> для вирішення.

'''Тайми в <amp-consent>:'''
За допомогою цієї функції видавці можуть розблокувати компоненти, які очікують на згоду після певного тайм-ауту. Функція також дозволяє видавцям налаштувати стан згоди, який буде отримано компонентами AMP, заблокованими за згодою.

==Групи в amp-geo==

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

'''1. Як зазначено вище, включіть сценарій amp-geo у вашому документі'''

'''2. Замість того, щоб просто включити порожній тег amp-geo, налаштуйте ISOCountryGroups для зменшення кількості коду, який ви повинні написати, щоб вказати поведінку в декількох локалах.'''

<code>In the document <body>:

<amp-geo layout=”nodisplay”>

<script type="application/json">{

“ISОСountrуGroups”

{ "soccer": [ "au", "ca", "ie", "nz", "us", "za" ]

"football": [ "unknown" ]}

}</script>

</amp-geo><br /></code>

'''3. Як і в попередньому прикладі, позначте документ CSS, щоб змінити вміст на основі приблизного місце знаходження користувача'''

<code>In the <style amp-custom> tag:

/* defaults */

.football:after { content: 'football';}

/* override */

.amp-geo-group-soccer .football:after { content: 'soccer' }

In the document <body>:

<div>

The game is called

<span class='football'></span>!
</div>
</code>

Якщо користувач перебуває в будь-якому з локалей, налаштованих на "футбол", то в тексті буде показано "Гра називається футболом!" В іншому випадку текст буде читати "Гра називається футболом!"
Ви можете знайти інший, більш складний приклад на AMP за прикладом , і дізнатись про більш розширені можливості функції в офіційній документації ; Наприклад, ви можете інтегрувати amp-geo з вашою аналітикою за допомогою змінної заміни або використовувати його в більш складних взаємодіях через amp-bind.

==Технологія AMP==
Формат AMP складається з:
AMP HTML - мова HTML, в якому частина тегів замінена на еквівалентні AMP-теги, а частина заборонена для використання.
AMP JS - в роботі використовується власна JS-бібліотека, що дозволяє елементам сторінки завантажувати асинхронно.
Google AMP Cache - в процесі індексування AMP-сторінок, пошукова система кеширует її дані і відтворює зі своїх серверів.
==Як зв'язати оголошення з AMP-сторінкою==
AMP-сторінку можна вибрати як цільову для оголошення, як і будь-яку іншу мобільну сторінку. Вам потрібно лише вказати відповідну URL-адресу в полі "Мобільний URL" для оголошення або ключового слова. Після цього користувачі, натиснувши на оголошення, перейдуть на AMP-сторінку.

Accelerated Mobile Pages (AMP)

2018-11-08T09:25:51Z

3524693: /* Відсутність кастомних скриптів */

<center>
[[Файл:Accelerated_Mobile_Pages.jpg|600px]]
</center>

'''Accelerated Mobile Pages'''
Accelerated Mobile Pages (AMP) – це технологія з відкритим вихідним кодом, що дозволяє створювати веб-сторінки, які швидко завантажуються в мобільному браузері. Використовуючи AMP-версії цільових сторінок, ви підвищуєте зручність роботи з вашим сайтом для мобільних користувачів.
Створено компанією Google в 2015 році.
По суті всі подібні сторінки є статичними або умовно-динамічними, так як припускають використання відправки форм, а також iframe.

Справа в тому, що на сайті використовуються спеціальні теги, кількість і функціонал яких строго обмежені. Завдання розробника полягає в тому, щоб зібрати те що треба з доступних йому схем, які вирішать проблему замовника.
Google знаходе ці спеціальні теги і кешує інформацію в них. Після цього, коли користувач шукає щось в Гуглі, браузер на тлі підгружає інформацію з CDN Гугла, в спеціальний iframe і при переході по посиланню відкриває вже завантажену сторінку в спеціальному вікні.
Сторінки з AMP ранжуються вище інших запитів в пошуку за рахунок того, що відповідають вимогам до швидкої завантаженні і адаптовані під мобільні пристрої

==Історія==
Проект AMP був анонсований компанією Google 7 жовтня 2015 року. Більше 30 новинних видань та декількох технологічних компаній, включаючи Twitter, Pinterest, LinkedIn та WordPress, були попередньо оголошені в якості партнерів проекту AMP.

Вперше протестувати технологію користувачам вдалося в лютому 2016 року, коли Google почав показувати версії AMP веб-сторінок у результатах мобільного пошуку. Ссылки AMP в пошукової системі Google ідентифікуються значком. У лютому 2017 року, через рік після публічного запуску AMP, компанія Adobe повідомила, що на AMP-сторінках припадає 7% всього веб-трафіка для провідних видань у Сполучених Штатах. У травні 2017 року компанія Google повідомила, що глобальне охоплення технологією швидкого завантаження сторінок складає більше 2 мільярдів AMP-сторінок, опублікованих у всьому світі. В червні 2017 року Twitter розпочав посилання на сторінки AMP від своїх прикладних програм для iOS та Android.

==Переваги використання AMP-сторінок в Google Рекламі==

[[Файл: АМР_ua.jpg|700px]]

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

==Відсутність кастомних скриптів==
Перше і найголовніше на відміну від стандартних сайтів - це неможливість вставки "звичайних" скриптів. Тобто велика частина функціоналу, зав'язана на динамічній зміні (дії при натисканні, анімація, фільтрація, модальні вікна), стає недоступною.
Рішення - використання доступних компонентів і iframe.
Доступні компоненти дозволяють домогтися, нехай і не повною, реалізації звичних фіч, але представляють їм гідну заміну і оптимізовані для швидкого завантаження.
З їх допомогою можна зробити бокове меню, карусель, надсилання форми, під-завантажений контент, рекламу та інше.
Кожен компонент пов'язаний зі своєю js-бібліотекою, яку потрібно підключити для його використання на сайті.

У коді сторінки не повинно бути inline-стилів
Ще одна особливість, яка повинна торкнутися в першу чергу текстового редактора, так як редагування стилів там проходить inline. Елементи з атрибутами типу style = "color: ...", не є валідними, а зміна кольору або розміру шрифту запише це властивість в код.
Структурована схема даних (structured data)

Для включення статей до збірки "Top stories google" до сторінок повинні бути додані схеми даних з короткою інформацією про статті, автора, видавництві, логотип компанії, а також дати публікації і зміни статті.
Використання структурних даних не є обов'язковою умовою, але для того щоб пошуковик коректно відобразив дані і зміни при редагуванні, потрібно поміщати цю схему на сайт. Фактично використання AMP без цієї схеми стає безглуздим.

Приклад схеми даних для сторінки типу "стаття"<br />

<Script>
type = "application / ld + json">{
"@context": "http://photo.org",
"@type": "NewsArticle",
"MainEntityOfPage": {
"@type": "WebPage",
"@id": "https://google.com/photo"
},
"Headline": "Article headline",
"Image": {
"@type": "ImageObject",
"Url": "photo.jpg",
"Height": 800,
"Width": 800
},
"DatePublished": "2015-02-05T08: 00: 00 + 08: 00",
"DateModified": "2015-02-05T09: 20: 00 + 08: 00",
"Author": {
"@type": "Person",
"Name": "John Doe"
},
"Publisher": {
"@type": "Organization",
"Name": "Google",
"Logo": {
"@type": "ImageObject",
"Url": "https://google.com/photo.jpg",
"Width": 600,
"Height": 60
}
},
"Description": "A most wonderful article"
}
</ Script><br />

Деякі значення є обов'язковими. Для структурної схеми даних так само є свій валідатор. Інформація щодо заповнення та обов'язкові поля для схеми типу "стаття" можна подивитися тут.
Там же можна знайти інформацію по іншим типам схем. (Книги, Курси, Музика, Підкасти, Рецепти, Огляди, ТV і Фільми, Відео)

==Деякі особливості==
'''Логотип компанії'''

Є ряд вимог до логотипу: https://developers.google.com/search/docs/data-types/articles#AMPlogo guidelines
Хочу звернути увагу, що розмір повинен бути не більше і не менше 60x600px хоча б по одній зі сторін. Бажано дотримуватися висоту 60px (наприклад, 450x60px). Зображення менших розмірів, але в тих же пропорціях, що і 60x600px (наприклад 450x45px), перевірку не пройдуть.<br />

Дата публікації і дата зміни
Дата публікації є обов'язковим параметром.
Дата зміни - рекомендованим.
Google кешує зміст статей, і дізнатися, коли він піде перевіряти всі статті на сайті знову, неможливо. Тому, якщо дата останнього зміни буде відрізнятися, буде простіше зрозуміти, що потрібно зробити новий кеш. <br />
Інакше можлива ситуація, коли користувач не побачить важливих змін.

==Спільні зусилля==
AMP побудовано завдяки глибокій співпраці з тисячами розробників, видавців та веб-сайтів, платформ поширення та технологічних компаній. На сьогоднішній день опубліковано більше 1.5B сторінок AMP, а 100+ провідних аналітиків, постачальники рекламних технологій та CMS підтримують формат AMP.

==Відсутність звичайних <img> тегів в документі==
Всі зображення на сторінці повинні бути описані в особливому тезі <amp-img>, що ускладнює вставку зображень користувачем через текстовий редактор. Для інших елементів, де висновок зображень прописаний "руками", досить поправити верстку. Так само, якщо використовуються карусель або lightbox, потрібно вставити аналоги з компонентів

==Інтеграція рекламної мережі з компонентом <amp-consent>==

Реалізації DoubleClick і AdSense <amp-ad> тепер підтримують <amp-consent>, включаючи не персональну рекламу. Перегляньте детальну документацію про те, коли і як подавати не персоналізовані оголошення з DoubleClick і AdSense.

'''<amp-ima-video> підтримка <amp-consent>''' Видавці тепер можуть збирати згоду, використовуючи компонент <amp-ima-video>.
Використання параметра <amp-geo> для конфігурації на основі геолокації <amp-consent>
AMP надає спосіб налаштування <amp-consent> з віддаленим викликом, використовуючи поле checkConsentHref . Якщо ви хочете включити логіку на основі геолокації для <amp-consent>, вам потрібно буде вирішити геолокацію на стороні сервера та відповідно налаштувати відповідь checkConsentHref . До цих пір було неможливо мати логіку на основі геолокації без встановлення віддаленого сервера.

'''Компонент <amp-geo>''' нещодавно запущений, щоб увімкнути зміст змісту, виходячи з приблизного місце +знаходження користувачів, на рівні коду країни ISO. Тепер ви можете використовувати цю функцію в поєднанні з <amp-consent>, що також означає, що ви можете пропустити implementation checkConsentHref, якщо ваші потреби в конфігурації не виходять за межі географічного розташування. Оформити замовлення за зразком ampbyexample.com <amp-geo> або документацію <amp-consent> .

'''<amp-consent> підтримка в історіях AMP'''
Незабаром <amp-consent> буде доступний для використання з <amp-story>. Для випадку <amp-story> лише для випадку, більшість інтерфейсу користувача буде попередньо налаштовано, хоча для вибору виразів, що висвітлюють, для виду і відчуття, крім повного контролю над текстовим вмістом, існують вигідні варіанти. Крім того, всі інтерфейси користувача <amp-consent> в історіях AMP будуть блокувати (тобто користувацький інтерфейс для згоди не матиме додаткової кнопки закриття).

'''Нові функції в <amp-consent>'''
support checkConsentHref для пар основних значень: ця функція дозволяє кінцевій точці checkConsentHref реагувати на пари ключових значень, які можуть бути поширені та використані для реалізації рекламної мережі. Це корисно для видавців, які хочуть передавати додаткову інформацію про конфігурацію в рекламні мережі для показу відповідних оголошень. Ця інформація доступна для компонентів AMP, які очікують на <amp-consent> для вирішення.

'''Тайми в <amp-consent>:'''
За допомогою цієї функції видавці можуть розблокувати компоненти, які очікують на згоду після певного тайм-ауту. Функція також дозволяє видавцям налаштувати стан згоди, який буде отримано компонентами AMP, заблокованими за згодою.

==Динамічна гео-персоналізація==
Документи AMP часто подається з сторонньої кеш-пам'яті; це означає, що не завжди зрозуміло, як підтримувати динамічний або персоналізований вміст. Існує цілий ряд компонентів і методів для досягнення багатьох з цих випадків використання ( amp-list , amp-state , amp-форма та amp-iframe, щоб назвати декілька), але існують деякі спільні випадки, які може зробити команда AMP набагато простіше

Зокрема, підприємства часто хочуть змінювати вміст за географічним розташуванням користувача. Найкращий спосіб зробити це для сторінок на різних мовах - це використання атрибута hreflang , але це не найкраще рішення для сторінок із невеликою гео-залежною варіацією, як-от реклама для певного мовного каталогу. Ось чому ми створили компонент amp-geo, який готовий до тестування та націлений на повний реліз наступного тижня.<br />

'''amp-geo'''
amp-geo дозволяє легко змінювати невеликі розділи веб-вмісту для користувачів на основі наближення розташування користувачів на рівні країни, подібно до рівня ISO-коду країни . Як розробник, є лише кілька кроків:

'''''1. Включіть сценарій amp-geo''''' ''

<code>In the document <body>:

<amp-geo layout=”nodisplay”></amp-geo></code>

'''''2. Включіть amp-geo тег''''' ''

<code>In the document <body>:

<amp-geo layout=”nodisplay”></amp-geo></code>

'''''3. Позначте свій документ за допомогою CSS, щоб змінити вміст на основі приблизного місце знаходження користувача''''' ''

<code>In the <style amp-custom> tag:

/* defaults */

.flag { background-image: "./starsandstripes.png"; }

/* override */

.amp-iso-country-ca .flag { background-image: "./mapleleaf.png"; }

In the document <body>:

<div height=”300” width=”500” layout=”responsive” class=”flag”>

</div><br /></code><br />

==Групи в amp-geo==

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

'''1. Як зазначено вище, включіть сценарій amp-geo у вашому документі'''

'''2. Замість того, щоб просто включити порожній тег amp-geo, налаштуйте ISOCountryGroups для зменшення кількості коду, який ви повинні написати, щоб вказати поведінку в декількох локалах.'''

<code>In the document <body>:

<amp-geo layout=”nodisplay”>

<script type="application/json">{

“ISОСountrуGroups”

{ "soccer": [ "au", "ca", "ie", "nz", "us", "za" ]

"football": [ "unknown" ]}

}</script>

</amp-geo><br /></code>

'''3. Як і в попередньому прикладі, позначте документ CSS, щоб змінити вміст на основі приблизного місце знаходження користувача'''

<code>In the <style amp-custom> tag:

/* defaults */

.football:after { content: 'football';}

/* override */

.amp-geo-group-soccer .football:after { content: 'soccer' }

In the document <body>:

<div>

The game is called

<span class='football'></span>!
</div>
</code>

Якщо користувач перебуває в будь-якому з локалей, налаштованих на "футбол", то в тексті буде показано "Гра називається футболом!" В іншому випадку текст буде читати "Гра називається футболом!"
Ви можете знайти інший, більш складний приклад на AMP за прикладом , і дізнатись про більш розширені можливості функції в офіційній документації ; Наприклад, ви можете інтегрувати amp-geo з вашою аналітикою за допомогою змінної заміни або використовувати його в більш складних взаємодіях через amp-bind.

==Технологія AMP==
Формат AMP складається з:
AMP HTML - мова HTML, в якому частина тегів замінена на еквівалентні AMP-теги, а частина заборонена для використання.
AMP JS - в роботі використовується власна JS-бібліотека, що дозволяє елементам сторінки завантажувати асинхронно.
Google AMP Cache - в процесі індексування AMP-сторінок, пошукова система кеширует її дані і відтворює зі своїх серверів.
==Як зв'язати оголошення з AMP-сторінкою==
AMP-сторінку можна вибрати як цільову для оголошення, як і будь-яку іншу мобільну сторінку. Вам потрібно лише вказати відповідну URL-адресу в полі "Мобільний URL" для оголошення або ключового слова. Після цього користувачі, натиснувши на оголошення, перейдуть на AMP-сторінку.

Accelerated Mobile Pages (AMP)

2018-11-08T09:24:51Z

3524693:

<center>
[[Файл:Accelerated_Mobile_Pages.jpg|600px]]
</center>

'''Accelerated Mobile Pages'''
Accelerated Mobile Pages (AMP) – це технологія з відкритим вихідним кодом, що дозволяє створювати веб-сторінки, які швидко завантажуються в мобільному браузері. Використовуючи AMP-версії цільових сторінок, ви підвищуєте зручність роботи з вашим сайтом для мобільних користувачів.
Створено компанією Google в 2015 році.
По суті всі подібні сторінки є статичними або умовно-динамічними, так як припускають використання відправки форм, а також iframe.

Справа в тому, що на сайті використовуються спеціальні теги, кількість і функціонал яких строго обмежені. Завдання розробника полягає в тому, щоб зібрати те що треба з доступних йому схем, які вирішать проблему замовника.
Google знаходе ці спеціальні теги і кешує інформацію в них. Після цього, коли користувач шукає щось в Гуглі, браузер на тлі підгружає інформацію з CDN Гугла, в спеціальний iframe і при переході по посиланню відкриває вже завантажену сторінку в спеціальному вікні.
Сторінки з AMP ранжуються вище інших запитів в пошуку за рахунок того, що відповідають вимогам до швидкої завантаженні і адаптовані під мобільні пристрої

==Історія==
Проект AMP був анонсований компанією Google 7 жовтня 2015 року. Більше 30 новинних видань та декількох технологічних компаній, включаючи Twitter, Pinterest, LinkedIn та WordPress, були попередньо оголошені в якості партнерів проекту AMP.

Вперше протестувати технологію користувачам вдалося в лютому 2016 року, коли Google почав показувати версії AMP веб-сторінок у результатах мобільного пошуку. Ссылки AMP в пошукової системі Google ідентифікуються значком. У лютому 2017 року, через рік після публічного запуску AMP, компанія Adobe повідомила, що на AMP-сторінках припадає 7% всього веб-трафіка для провідних видань у Сполучених Штатах. У травні 2017 року компанія Google повідомила, що глобальне охоплення технологією швидкого завантаження сторінок складає більше 2 мільярдів AMP-сторінок, опублікованих у всьому світі. В червні 2017 року Twitter розпочав посилання на сторінки AMP від своїх прикладних програм для iOS та Android.

==Переваги використання AMP-сторінок в Google Рекламі==

[[Файл: АМР_ua.jpg|700px]]

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

==Відсутність кастомних скриптів==
Перше і найголовніше на відміну від стандартних сайтів - це неможливість вставки "звичайних" скриптів. Тобто велика частина функціоналу, зав'язана на динамічній зміні (дії при натисканні, анімація, фільтрація, модальні вікна), стає недоступною.
Рішення - використання доступних компонентів і iframe.
Доступні компоненти дозволяють домогтися, нехай і не повною, реалізації звичних фіч, але представляють їм гідну заміну і оптимізовані для швидкого завантаження.
З їх допомогою можна зробити бокове меню, карусель, надсилання форми, під-завантажений контент, рекламу та інше.
Кожен компонент пов'язаний зі своєю js-бібліотекою, яку потрібно підключити для його використання на сайті.

У коді сторінки не повинно бути inline-стилів
Ще одна особливість, яка повинна торкнутися в першу чергу текстового редактора, так як редагування стилів там проходить inline. Елементи з атрибутами типу style = "color: ...", не є валідними, а зміна кольору або розміру шрифту запише це властивість в код.
Структурована схема даних (structured data)

Для включення статей до збірки "Top stories google" до сторінок повинні бути додані схеми даних з короткою інформацією про статті, автора, видавництві, логотип компанії, а також дати публікації і зміни статті.
Використання структурних даних не є обов'язковою умовою, але для того щоб пошуковик коректно відобразив дані і зміни при редагуванні, потрібно поміщати цю схему на сайт. Фактично використання AMP без цієї схеми стає безглуздим.

==Приклад схеми даних для сторінки типу "стаття"==<br />

<Script>
type = "application / ld + json">{
"@context": "http://photo.org",
"@type": "NewsArticle",
"MainEntityOfPage": {
"@type": "WebPage",
"@id": "https://google.com/photo"
},
"Headline": "Article headline",
"Image": {
"@type": "ImageObject",
"Url": "photo.jpg",
"Height": 800,
"Width": 800
},
"DatePublished": "2015-02-05T08: 00: 00 + 08: 00",
"DateModified": "2015-02-05T09: 20: 00 + 08: 00",
"Author": {
"@type": "Person",
"Name": "John Doe"
},
"Publisher": {
"@type": "Organization",
"Name": "Google",
"Logo": {
"@type": "ImageObject",
"Url": "https://google.com/photo.jpg",
"Width": 600,
"Height": 60
}
},
"Description": "A most wonderful article"
}
</ Script><br />

Деякі значення є обов'язковими. Для структурної схеми даних так само є свій валідатор. Інформація щодо заповнення та обов'язкові поля для схеми типу "стаття" можна подивитися тут.
Там же можна знайти інформацію по іншим типам схем. (Книги, Курси, Музика, Підкасти, Рецепти, Огляди, ТV і Фільми, Відео)

==Деякі особливості==
'''Логотип компанії'''

Є ряд вимог до логотипу: https://developers.google.com/search/docs/data-types/articles#AMPlogo guidelines
Хочу звернути увагу, що розмір повинен бути не більше і не менше 60x600px хоча б по одній зі сторін. Бажано дотримуватися висоту 60px (наприклад, 450x60px). Зображення менших розмірів, але в тих же пропорціях, що і 60x600px (наприклад 450x45px), перевірку не пройдуть.<br />

Дата публікації і дата зміни
Дата публікації є обов'язковим параметром.
Дата зміни - рекомендованим.
Google кешує зміст статей, і дізнатися, коли він піде перевіряти всі статті на сайті знову, неможливо. Тому, якщо дата останнього зміни буде відрізнятися, буде простіше зрозуміти, що потрібно зробити новий кеш. <br />
Інакше можлива ситуація, коли користувач не побачить важливих змін.

==Спільні зусилля==
AMP побудовано завдяки глибокій співпраці з тисячами розробників, видавців та веб-сайтів, платформ поширення та технологічних компаній. На сьогоднішній день опубліковано більше 1.5B сторінок AMP, а 100+ провідних аналітиків, постачальники рекламних технологій та CMS підтримують формат AMP.

==Відсутність звичайних <img> тегів в документі==
Всі зображення на сторінці повинні бути описані в особливому тезі <amp-img>, що ускладнює вставку зображень користувачем через текстовий редактор. Для інших елементів, де висновок зображень прописаний "руками", досить поправити верстку. Так само, якщо використовуються карусель або lightbox, потрібно вставити аналоги з компонентів

==Інтеграція рекламної мережі з компонентом <amp-consent>==

Реалізації DoubleClick і AdSense <amp-ad> тепер підтримують <amp-consent>, включаючи не персональну рекламу. Перегляньте детальну документацію про те, коли і як подавати не персоналізовані оголошення з DoubleClick і AdSense.

'''<amp-ima-video> підтримка <amp-consent>''' Видавці тепер можуть збирати згоду, використовуючи компонент <amp-ima-video>.
Використання параметра <amp-geo> для конфігурації на основі геолокації <amp-consent>
AMP надає спосіб налаштування <amp-consent> з віддаленим викликом, використовуючи поле checkConsentHref . Якщо ви хочете включити логіку на основі геолокації для <amp-consent>, вам потрібно буде вирішити геолокацію на стороні сервера та відповідно налаштувати відповідь checkConsentHref . До цих пір було неможливо мати логіку на основі геолокації без встановлення віддаленого сервера.

'''Компонент <amp-geo>''' нещодавно запущений, щоб увімкнути зміст змісту, виходячи з приблизного місце +знаходження користувачів, на рівні коду країни ISO. Тепер ви можете використовувати цю функцію в поєднанні з <amp-consent>, що також означає, що ви можете пропустити implementation checkConsentHref, якщо ваші потреби в конфігурації не виходять за межі географічного розташування. Оформити замовлення за зразком ampbyexample.com <amp-geo> або документацію <amp-consent> .

'''<amp-consent> підтримка в історіях AMP'''
Незабаром <amp-consent> буде доступний для використання з <amp-story>. Для випадку <amp-story> лише для випадку, більшість інтерфейсу користувача буде попередньо налаштовано, хоча для вибору виразів, що висвітлюють, для виду і відчуття, крім повного контролю над текстовим вмістом, існують вигідні варіанти. Крім того, всі інтерфейси користувача <amp-consent> в історіях AMP будуть блокувати (тобто користувацький інтерфейс для згоди не матиме додаткової кнопки закриття).

'''Нові функції в <amp-consent>'''
support checkConsentHref для пар основних значень: ця функція дозволяє кінцевій точці checkConsentHref реагувати на пари ключових значень, які можуть бути поширені та використані для реалізації рекламної мережі. Це корисно для видавців, які хочуть передавати додаткову інформацію про конфігурацію в рекламні мережі для показу відповідних оголошень. Ця інформація доступна для компонентів AMP, які очікують на <amp-consent> для вирішення.

'''Тайми в <amp-consent>:'''
За допомогою цієї функції видавці можуть розблокувати компоненти, які очікують на згоду після певного тайм-ауту. Функція також дозволяє видавцям налаштувати стан згоди, який буде отримано компонентами AMP, заблокованими за згодою.

==Динамічна гео-персоналізація==
Документи AMP часто подається з сторонньої кеш-пам'яті; це означає, що не завжди зрозуміло, як підтримувати динамічний або персоналізований вміст. Існує цілий ряд компонентів і методів для досягнення багатьох з цих випадків використання ( amp-list , amp-state , amp-форма та amp-iframe, щоб назвати декілька), але існують деякі спільні випадки, які може зробити команда AMP набагато простіше

Зокрема, підприємства часто хочуть змінювати вміст за географічним розташуванням користувача. Найкращий спосіб зробити це для сторінок на різних мовах - це використання атрибута hreflang , але це не найкраще рішення для сторінок із невеликою гео-залежною варіацією, як-от реклама для певного мовного каталогу. Ось чому ми створили компонент amp-geo, який готовий до тестування та націлений на повний реліз наступного тижня.<br />

'''amp-geo'''
amp-geo дозволяє легко змінювати невеликі розділи веб-вмісту для користувачів на основі наближення розташування користувачів на рівні країни, подібно до рівня ISO-коду країни . Як розробник, є лише кілька кроків:

'''''1. Включіть сценарій amp-geo''''' ''

<code>In the document <body>:

<amp-geo layout=”nodisplay”></amp-geo></code>

'''''2. Включіть amp-geo тег''''' ''

<code>In the document <body>:

<amp-geo layout=”nodisplay”></amp-geo></code>

'''''3. Позначте свій документ за допомогою CSS, щоб змінити вміст на основі приблизного місце знаходження користувача''''' ''

<code>In the <style amp-custom> tag:

/* defaults */

.flag { background-image: "./starsandstripes.png"; }

/* override */

.amp-iso-country-ca .flag { background-image: "./mapleleaf.png"; }

In the document <body>:

<div height=”300” width=”500” layout=”responsive” class=”flag”>

</div><br /></code><br />

==Групи в amp-geo==

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

'''1. Як зазначено вище, включіть сценарій amp-geo у вашому документі'''

'''2. Замість того, щоб просто включити порожній тег amp-geo, налаштуйте ISOCountryGroups для зменшення кількості коду, який ви повинні написати, щоб вказати поведінку в декількох локалах.'''

<code>In the document <body>:

<amp-geo layout=”nodisplay”>

<script type="application/json">{

“ISОСountrуGroups”

{ "soccer": [ "au", "ca", "ie", "nz", "us", "za" ]

"football": [ "unknown" ]}

}</script>

</amp-geo><br /></code>

'''3. Як і в попередньому прикладі, позначте документ CSS, щоб змінити вміст на основі приблизного місце знаходження користувача'''

<code>In the <style amp-custom> tag:

/* defaults */

.football:after { content: 'football';}

/* override */

.amp-geo-group-soccer .football:after { content: 'soccer' }

In the document <body>:

<div>

The game is called

<span class='football'></span>!
</div>
</code>

Якщо користувач перебуває в будь-якому з локалей, налаштованих на "футбол", то в тексті буде показано "Гра називається футболом!" В іншому випадку текст буде читати "Гра називається футболом!"
Ви можете знайти інший, більш складний приклад на AMP за прикладом , і дізнатись про більш розширені можливості функції в офіційній документації ; Наприклад, ви можете інтегрувати amp-geo з вашою аналітикою за допомогою змінної заміни або використовувати його в більш складних взаємодіях через amp-bind.

==Технологія AMP==
Формат AMP складається з:
AMP HTML - мова HTML, в якому частина тегів замінена на еквівалентні AMP-теги, а частина заборонена для використання.
AMP JS - в роботі використовується власна JS-бібліотека, що дозволяє елементам сторінки завантажувати асинхронно.
Google AMP Cache - в процесі індексування AMP-сторінок, пошукова система кеширует її дані і відтворює зі своїх серверів.
==Як зв'язати оголошення з AMP-сторінкою==
AMP-сторінку можна вибрати як цільову для оголошення, як і будь-яку іншу мобільну сторінку. Вам потрібно лише вказати відповідну URL-адресу в полі "Мобільний URL" для оголошення або ключового слова. Після цього користувачі, натиснувши на оголошення, перейдуть на AMP-сторінку.

2018-10-18T08:54:23Z

3524693:

'''''<font color='black' size=6>Єлькін Валетин Ілліч</font>'''''
[[Файл:Valintin.jpg|міні|праворуч]]

== Про себе ==
Я - студент. Навчаюся на фізико-математичному факультеті спеціальності інформатика.

==Моя група==
[[Група 26, спеціальність "Інформатика", 2015-2016 н.р.]]

[[Група 36, спеціальність "Інформатика", 2015-2018 н.р.|Список групи]]

== Проекти в яких беру участь ==

*[[Навчальна обчислювальна практика. Спеціальність "Інформатика". ІІ курс]]<br />
*[[Історія комп'ютерної техніки]]
[[Epson LX-800]] <font color="red">'''Єлькін Валентин,26 група'''</font>

[[Epson FX-1170]]<font color="red">'''Єлькін Валентин,26 група'''</font>

== Мої роботи ==

*[[Стінгазета до НОП на тему "Послідовність завантаження ПК", Єлькін Валентин, №26 гр, 2015-2016]]

[[Accelerated Mobile Pages (AMP)]]

[[Test marshrytizator]]

==Електронний журнал==
[https://docs.google.com/spreadsheets/d/1NdBtIiYDBSGMgPU-M29RxJ-yssrXSkbSKrZvtGuvOiU/edit?usp=sharing Електронний журнал]

== Мої роботи ==

===[[Екстримальний ігровий ПК для ентузіастів. Intel 2015]]===

*[[Процесор Intel® Core™ i5-4690K]]

*[[Intel Q87 Chipset. СПК]]

*[[Різниця між DDR2 і DDR.СПК]]

*[[Будова відеокарти комп'ютера.СПК]]

*[[Як працюють звукові карти ПК. СПК]]

*[[Твердотельный диск 800Gb Intel SSD 750 Series, PCI-E СПК]]

*[[Корпус Thermaltake Level 10 Limited Edition.СПК]]

*[[Водяное охлаждение Hyper Watercooling Kit 4.СПК]]

*[[Монитор 31.5" Монитор ASUS PQ321QE. СПК]]

*[[Наушники Razer Tiamat 7.1 СПК]]

===Обробка зображень та мультимедіа===

== Лабораторні роботи: ==
<div style=" style="margin: auto; text-align: center;">
{| class="wikitable" border="1" width="75%"
| colspan="8" height="3em" | <font size=4> [[Обробка_зображень_та_мультимедіа|Обробка зображень та мультимедіа:]] </font>
|-
| ЗАВДАННЯ
| [[Обробка зображень лабораторна 1 |ЛР №1]]
| [[Обробка зображень лабораторна 6 |ЛР №2]]
| [[Обробка зображень лабораторна 2 |ЛР №3]]
| [[Обробка зображень лабораторна 4 |ЛР №4]]
| [[Обробка зображень лабораторна 10|ЛР №5]]
| [[Обробка зображень лабораторна 12|ЛР №6]]
| [[Обробка зображень лабораторна 16|ЛР №7]]
|-
| ПОСИЛАННЯ
|[[http://wiki.kspu.kr.ua/index.php/%D0%9A%D0%BE%D1%80%D0%B8%D1%81%D1%82%D1%83%D0%B2%D0%B0%D1%87:3524693 | №1]]
| [[ Лабораторна робота 2 Єлькін |Текст ]]
| [[ Лабораторна робота 3 Єлькін |зображення ]]
| [[ Лабораторна робота 4 Єлькін |Колір в зображеннях]]
| [[ Лабораторна робота 5 Єлькін | Звук]]
| [[ Лабораторна робота 6 Єлькін | Відео ]]
| [[ Лабораторна робота 7 Єлькін | Мультимедіа ]]

|-
|}
</div>

Користувач:3524693

2018-10-18T08:54:11Z

3524693:

'''''<font color='black' size=6>Єлькін Валетин Ілліч</font>'''''
[[Файл:Valintin.jpg|міні|праворуч]]

== Про себе ==
Я - студент. Навчаюся на фізико-математичному факультеті спеціальності інформатика.

==Моя група==
[[Група 26, спеціальність "Інформатика", 2015-2016 н.р.]]

[[Група 36, спеціальність "Інформатика", 2015-2018 н.р.|Список групи]]

== Проекти в яких беру участь ==

*[[Навчальна обчислювальна практика. Спеціальність "Інформатика". ІІ курс]]<br />
*[[Історія комп'ютерної техніки]]
[[Epson LX-800]] <font color="red">'''Єлькін Валентин,26 група'''</font>

[[Epson FX-1170]]<font color="red">'''Єлькін Валентин,26 група'''</font>

== Мої роботи ==

*[[Стінгазета до НОП на тему "Послідовність завантаження ПК", Єлькін Валентин, №26 гр, 2015-2016]]

[[Accelerated Mobile Pages (AMP)]]
[[Test marshrytizator]]

==Електронний журнал==
[https://docs.google.com/spreadsheets/d/1NdBtIiYDBSGMgPU-M29RxJ-yssrXSkbSKrZvtGuvOiU/edit?usp=sharing Електронний журнал]

== Мої роботи ==

===[[Екстримальний ігровий ПК для ентузіастів. Intel 2015]]===

*[[Процесор Intel® Core™ i5-4690K]]

*[[Intel Q87 Chipset. СПК]]

*[[Різниця між DDR2 і DDR.СПК]]

*[[Будова відеокарти комп'ютера.СПК]]

*[[Як працюють звукові карти ПК. СПК]]

*[[Твердотельный диск 800Gb Intel SSD 750 Series, PCI-E СПК]]

*[[Корпус Thermaltake Level 10 Limited Edition.СПК]]

*[[Водяное охлаждение Hyper Watercooling Kit 4.СПК]]

*[[Монитор 31.5" Монитор ASUS PQ321QE. СПК]]

*[[Наушники Razer Tiamat 7.1 СПК]]

===Обробка зображень та мультимедіа===

== Лабораторні роботи: ==
<div style=" style="margin: auto; text-align: center;">
{| class="wikitable" border="1" width="75%"
| colspan="8" height="3em" | <font size=4> [[Обробка_зображень_та_мультимедіа|Обробка зображень та мультимедіа:]] </font>
|-
| ЗАВДАННЯ
| [[Обробка зображень лабораторна 1 |ЛР №1]]
| [[Обробка зображень лабораторна 6 |ЛР №2]]
| [[Обробка зображень лабораторна 2 |ЛР №3]]
| [[Обробка зображень лабораторна 4 |ЛР №4]]
| [[Обробка зображень лабораторна 10|ЛР №5]]
| [[Обробка зображень лабораторна 12|ЛР №6]]
| [[Обробка зображень лабораторна 16|ЛР №7]]
|-
| ПОСИЛАННЯ
|[[http://wiki.kspu.kr.ua/index.php/%D0%9A%D0%BE%D1%80%D0%B8%D1%81%D1%82%D1%83%D0%B2%D0%B0%D1%87:3524693 | №1]]
| [[ Лабораторна робота 2 Єлькін |Текст ]]
| [[ Лабораторна робота 3 Єлькін |зображення ]]
| [[ Лабораторна робота 4 Єлькін |Колір в зображеннях]]
| [[ Лабораторна робота 5 Єлькін | Звук]]
| [[ Лабораторна робота 6 Єлькін | Відео ]]
| [[ Лабораторна робота 7 Єлькін | Мультимедіа ]]

|-
|}
</div>