Потрібна більш технічна відповідь на питання інтерв'ю про те, як Інтернет працює від початку до кінця [закрито]

Протягом останніх двох тижнів я проводив інтерв'ю з 5-ма окремими людьми, і троє з цих п’яти запитали мені це питання: Поясніть, що відбувається між натисканням на "Google.com" та сторінкою, що виходить на екран. В основному, як працює Інтернет. Через три рази я вважаю, що мені краще бути готовим, якщо я коли-небудь знову отримаю це питання.

Я знаю деякі речі, але я не повністю впевнений, що моя відповідь досить хороша. В основному я зазначу, що DNS-сервер перекладає "google.com" в IP-адресу. Я якось обробляю TCP / IP, потім розповідаю про веб-сервер, який буквально обслуговує запитувані сторінки, які надсилаються назад до браузера, який браузер потім інтерпретує та відображає.

Як я вже говорив, я не впевнений, що моя відповідь є достатньо технічною. Які кроки я пропускаю?

Для чого це варто, два з цих трьох разів були в одній і тій же компанії, і мене передзвонили на третє співбесіду з ними, тому я не можу занадто сильно бомбити .

1. Ваш веб-переглядач спочатку має вигляд ОС у файлі "хостів" для запису, який переведе ім'я домену на IP-адресу. Це успадкована функція, успадкована від ARPANET, коли в одному текстовому файлі можна було містити зрозумілі імена для кожного комп'ютера, доступного через ARPANET, і для кожного комп'ютера, підключеного до нього, мати відносно недавню копію. Раніше воно мало деяке значення в невеликих мережах комп’ютерів, у яких не було NetBIOS або подібних протоколів іменування вузлів, але в наш час це, швидше за все, мішень для хакерів (які можуть використовувати його для обходу DNS і спрямування вашого комп'ютера на сайти вони контролюють) як будь-яке законне використання клієнтського комп'ютера або його користувача / власника.
2. Припустимо, що на вашому комп'ютері немає запису HOSTS для цього домену, ваш браузер надсилає запит UDP на сервер DNS, налаштований в настройках Інтернету ОС для використовуваного з'єднання, передаючи "ім'я хоста", також ім'я домену запиту (все між "http: //" та першою косою або переднім косою чергою після наступного; тобто "www.google.com"). Цей DNS-сервер зазвичай належить або вашій компанії, або місцевому постачальнику послуг Інтернету.
   • UDP розшифровується як "Універсальний протокол дейтаграми" і є протоколом "транспортного рівня" в тому ж класі, що і TCP (над протоколом "мережевого рівня" IP-протоколом, нижче протоколів "прикладного рівня", таких як HTTP, FTP, SMTP тощо) ). У той час як TCP передбачає багато можливостей перевірки помилок та відмовок (додавання додаткових даних та збільшення накладних витрат), UDP використовує набагато більш легкий підхід, збільшуючи пропускну здатність даних; компроміс полягає в тому, що протокол не підтримує функції, доступні в TCP, такі як розділення великих даних на кілька пакетів (тому повідомлення повинні бути невеликими) або повторна відправка пакетів, втрачених під час транзиту. Це добре для невеликих простих повідомлень (наприклад, DNS) та потокових даних телеметричного типу, де не важливо, чи втрачено один пакет.
3. Цей DNS-сервер знатиме одну з трьох речей: як перекласти це доменне ім’я безпосередньо в IP-адресу (тобто це "авторитетний сервер імен" або ANS для цього домену); IP-адреса ANS або її батька; або власний сервер батьків імен, який з більшою ймовірністю знає, як досягти ANS. Якщо сервер не переводить запит сам, він пересилатиме запит або «вниз» до відомого ANS, або «вгору» до його батьківського NS, і цей процес повторюється рекурсивно.
   • "Корінь" цієї структури дерева - це єдиний сервер, який не робить нічого, крім переадресації будь-яких запитів, які він отримує, на один із ряду "домену верхнього рівня" або TLD-серверів. Наприклад, є сервер імен ".com", який знає, як знайти IP-адресу будь-якого домену ".com" на планеті (пересилаючи ці запити до серверів імен рівня ISP). Ці TLD перенаправляють запити на сервери доменних імен, які не відомі жодним DNS в межах певної "гілки" Інтернету, що належить провайдеру.
4. Після того, як авторитетний сервер імен знайдений і переведе доменне ім'я в IP-адресу, ця адреса повертається клієнту та його браузеру. Якщо ANS не може бути знайдений протягом "часу проживання" запиту (TTL; максимальна кількість разів, коли запит повинен бути переданий між серверами, щоб уникнути нескінченного циклу між неправильно налаштованими серверами), помилка повертається клієнту вузлом на який запит "тайм-аут" (або вузол, який є авторитетним сервером для домену, але не може перекласти певний префікс домену).
5. Після цього браузер для HTTP-з'єднання надсилає запит "TCP SYN" на IP-адресу та вказаний порт (або HTTP-порт 80 за замовчуванням) для встановлення з'єднання. Це запит на рівні протоколу, накладений поверх IP-заголовка "мережевого рівня", який містить таку інформацію, як бажаний порт відповіді клієнта ("вихідний порт"), налаштування для зв'язку TCP, такі як розмір сегмента, масштаб вікна та використання додаткових функцій протоколу.
6. Запит направляється на "рівні зв'язку" (керуючи тим, як власне електричні ланцюги маніпулюють для передачі даних, що містяться в мережевому, транспортному та прикладному шарах) через структуру Інтернету; як правило, дані будуть проходити по дроту або волокні до центрального офісу вашого будинку або бізнесу (це називається "остання миля" і, як правило, схема, що представляє найбільшу вузьку смугу до пропускної здатності), яка є більшою чи меншою мірою "наземною" Інформаційне автострада. Тоді CO має доступ до високопропускних труб (Т-носії, SONET тощо), які передають ваш запит разом з мільярдами інших людей по всій земній кулі до ЦО місця призначення, який пересилає його до сервера або мережі призначення.
   • Ця "маршрутизація IP" працює концептуально подібним чином, як роздільна здатність DNS; Інтернет-провайдери "найвищого рівня" присвоюють ICANN всім мережам IP класу (кожній можливій адресі дається відомий перший байт), а інші Інтернет-провайдери знають, кому належить ця мережа класу A і як отримати дані до найближчої "фронту" цієї мережі двері ", використовуючи інформацію в" таблиці маршрутизації ". Потім цей провайдер верхнього рівня орендує блоки адрес, деякі місцевим провайдерам, інші безпосередньо корпоративним користувачам, і ці Інтернет-провайдери та корпорації мають маршрутизатори, які використовують IP-адресу (та власні таблиці маршрутизації), щоб визначити, чи надсилати пакети до інших поблизу мікросхем, збоку до інших локальних маршрутизаторів провайдера або до магістралей і маршрутизаторів вищого рівня.
7. Сервер отримує цей запит (за умови, що його не відхилено на нижньому рівні абстракції, як сокет або брандмауер), і якщо він вирішить прийняти з'єднання, він надішле "відповідь запиту" на відповідь "SYN-ACK". запит та уточнення власних уподобань (включаючи будь-які переваги клієнтів, які він може вмістити, але змінюючи будь-які, які він не може або які не були вказані).
8. Якщо клієнт підтримує зв’язок за допомогою набору параметрів, які надав сервер, він надішле відповідь ACK, і тепер з'єднання "встановлено".
9. Далі браузер надсилає запит "HTTP GET". Запит включає повний URI ресурсу, запитуваний браузером (хоча ми знаємо, що ми розмовляємо з www.google.com, ми надсилаємо цю рядок як частину запиту, щоб сервер міг, за бажанням, далі інтерпретувати доменне ім’я для направлення запиту). Цей запит може включати "куки"; дані, що зберігаються на клієнті, які можуть бути надані серверу для сприяння ефективному та зручному обробленню запиту (наприклад, визначенню уподобань користувача).
10. Сервер отримує GET-запит і спочатку вирішує, чи бажає він його шанувати (сервер, можливо, слухав запити до порту TCP 80, але очікує повідомлення від іншого протоколу програми, такого як FTP або VoIP; це рідко для порту 80, але більш поширений для інших типів портів). Ми будемо вважати, що він це приймає; сервер повертає відповідь HTTP, що містить запитуваний ресурс (у цьому випадку HTML для сторінки за замовчуванням, яка є всюдисущою пошуковою сторінкою Google). Відповідь може також включати «куки», які сервер просить клієнта зберігати (клієнт може чи не може цього робити).
11. HTML засвоюється браузером і надається, щоб намалювати сторінку у вікні браузера. Хоча це відбувається, більше HTTP GET запитів для Javascript, таблиць стилів, зображень та інших даних, необхідних для відображення всього вмісту сторінки в порядку, передбаченому HTML, надсилається клієнтом, а отримані дані надаються клієнтом сервер.
12. У минулому віці Google базувався на статичних формах; ви набрали те, що хотіли шукати, у текстове поле і натискаєте "Пошук" (або "Я відчуваю себе щасливим"). Коли ви це зробите, клієнт надсилає запит на пошту POST; запит містить місцезнаходження, вказане клієнтом, до якого слід надсилати інформацію, і, звичайно, саму інформацію. Ця інформація засвоюється сервером, який використовує її для пошуку результатів пошуку, і сервер створює сторінку цих результатів, яку він надсилає вам. Або він може перетворити пошукові терміни у "рядок запиту" та відповісти "переспрямуванням"; запит браузера надіслати ще один запит на інший URI, вказаний у повідомленні. Браузер зробить це, і тоді сервер створить та передасть цю сторінку.
13. В сучасний час титульна сторінка Google набагато динамічніша. Під час введення JavaScript, який виконується на клієнтській стороні в браузері, надсилає те, що ви вводите в Google, по "бічному каналу" (він використовує ті самі протоколи для зв'язку, але оскільки браузер сам не надсилає запити на цілі сторінки , екран браузера не очищається повністю і повторно малюється). На головній сторінці це використовується для надання підказів щодо запитів (автоматичне заповнення пропозицій щодо речей, які ви можете шукати, оскільки інші люди це робили недавно); на сторінці результатів це робить те саме, але також можна використовувати для надання результатів пошуку в режимі реального часу та повністю перемальовувати сторінку, не вимагаючи повного перезавантаження сторінки браузером. Ці типи хитрощів підпадають під загальний заголовок AJAX (Асинхронний JavaScript та XML,

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

Покинути згадки про файли cookie та брандмауери, тут би не вистачало кількох речей. Щось надсилати файли cookie можна сказати, щоб "Google.com" розпізнавав користувача та обслуговував сторінку, яка може відрізнятися від того, хто не ввійшов у Google. Існує також питання, де людина, яка це шукає: смартфон, планшет або звичайний комп'ютер (ноутбук або настільний ПК)?

Цікаво, чи можуть бути якісь побічні питання, які вам мали намір задати, але чи не це може бути фактором тут? Це більше питання про те, як Інтернет працює в Інтернеті, дещо ширше, включаючи електронну пошту та інші речі, які я думаю.

Я здогадуюсь, що це був більше перевірка ваших можливостей спілкування. Чи можете ви взяти досить технічне питання та розбити його, щоб технічні та нетехнічні зрозуміли його? До яких питань ви б відповіли, пояснивши, хтось відкриває домашню сторінку "Google.com" у своєму браузері? Ви робите купу припущень чи задаєте питання? У чомусь я розглядаю це як паралель із питанням білої дошки, коли речі залишаються досить розпливчастими, що або ви задасте питання, щоб ви могли дати точну правильну відповідь, або ви зробили припущення щодо надання відповіді.