un — Проксі та Оригіни

un

гість

1 / ?

Чи знаходиться що-небудь перед кожною веб-службою

Привіт

Якщо ви введете example.com у браузер, ви майже ніколи не досягнете машини, яка справно виконує додаток. Ви досягнете машини, яка переказує запит до однієї, яка це робить. Ця машина, яка переказує, має назву: реверс-проксі.

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

Після закінчення ви розумієте:

- Різницю між клієнтом, проксі та оригіном

- Чому проксі перед початковою точкою захищає, масштабує та дозволяє замінювати частини без того, щоб хто-небудь помічав

- Три завдання, які виконує реверс-проксі одночасно: приховування початкової точки, завершення TLS та розподілення навантаження між репліками

- Як запит переходить від браузера до проксі, а потім до верхнього рівня та назад, крапкою за краплею

Після закінчення ви з впевненістю зможете розв'язувати завдання щодо розміщення проксі, відділення повноважень на межі та чому станова проксі-шар множиться дешево, а окрема початкова точка - ні.

Форвардний проксі проти Реверс-проксі

Дві напрямки проксі

Обидва види проксі стоять між двома сторонами та передають дані. Вони відрізняються тими, які сторони вони представляють.

Форвардний проксі: стоїть перед групою клієнтів. Клієнти знають про проксі; зовнішній сервер бачить адресу проксі, а не адресу клієнта. Корпоративні виходи проксі, фільтри вмісту та SOCKS-проксі підходять до цього типу.

Реверс-проксі: стоїть перед групою серверів. Зовнішній світ (клієнти) спілкується з адресою проксі; клієнти не знають, що реальний сервер приховується за ним. almost every public web service uses one.

Мнемонічний прийом: форвардний проксі приховує клієнтів від серверів. Реверс-проксі приховує сервери від клієнтів.

Чи потрібно турбуватися про напрямок? Робота, моди невдачі та кордон безпеки відрізняються. Форвардний проксі турбується про те, з ким його користувачі спілкуються; реверс-проксі турбується про те, з ким його сервери спілкуються.

Клієнт, який відправляє дані через обидва види одночасно, проходить: client -> forward_proxy -> internet -> reverse_proxy -> origin.

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

Чому Так Много на Схилу

Схил Забезпечує Себе

Обертовий проксі виконує три роботи одночасно. Кожна з них виправдує шар; коли всі три адреси однієї і тієї ж адреси, то пояснює, чому майже кожна виробнича веб-архітектура має ту саму форму на передній стороні.

Робота 1: Приховати початок. Проксі відповідає на публічному IP. Задачі знаходяться на приватних IP, які інтернет не може досягти. Атакувальник, який хоче дістатися до початкової точки, спочатку повинен компрометувати проксі.

Робота 2: Закінчувати TLS. Проксі має сертифікат для example.com та дешифрує входячі HTTPS-запити. Задачі спілкуються з проксі на внутрішньою мережею, яка вважається довірою, в HTTP (або простішому внутрішньому TLS). Політика обновлення сертифікату та шифрів знаходяться в одній точці.

Робота 3: Роздавати навантаження. Проксі вирішує, яка задача оброблятиме кожен запит. Задачі позаду одного проксі утворюють пул; проксі обирає одну для кожного запиту за стратегією (в кружалу, найменший обсяг роботи, хеш за заголовком). Додання потужності означає додання задачі до пул, а не повідомлення кожному клієнту нової адреси.

Кожна робота - це маленький програмний код. Разом вони пояснюють, чому шар, такий простий як 'Caddy перед Python-аплікацією', має більше ваги у дизайні, ніж сама Python-аплікація.

Обертовий проксі, яке виконує три роботи: приховувати початок, закінчувати TLS, роздавати навантаження

Проектування для Трьох

Ваші команда працює над невеликим API на одній Python-процесі, який слухає порт 8000 на одній VM. Трафік став достатньо великим, щоб одна VM не могла виконувати свої функції, а також огляд безпеки виявив, що VM має публічний IP та має свій власний сертифікат TLS.

Ви вирішуєте поставити обертовий проксі на перед. Нарисуйте схему: куди вказує DNS, де живе сертифікат, як навантаження доходить до задач, а також що зміниться в початковій VM?

Пройдіть через нову архітектуру. Обговоріть всі чотири елементи: мету DNS, місцезнаходження закінчення TLS, стратегію розподілу навантаження та те, що початкова VM зберігає або втрачає.

Заміна компонента без того, щоб хто-небудь помітив

Індиректність купує свободу

Стара комп'ютерна наукова поглядає: кожен проблем можна вирішити, додавши шар індиректності (окрім проблеми з надто-many шарів індиректності). Відвертий проксі є одним з найкористливіших індиректностей у розподілених системах.

Що купує ви:

- Змінні backends. Перемістити додаток з Python до Go? Мігрувати з одного датацентру до іншого? Розгортати нову версію без downtime? Кожен з цих процесів відбувається позаду стабільної публічної адреси. Нічого не змінюється для користувачів.

- Незалежне масштабування. ТIER проксі масштабується на основі пропускної здатності та CPU на рівні TLS. Backend tier масштабується на основі роботи додатка. Кожен рісає на своїй власній осі, оскільки вони живуть на різних машинах.

- Забезпечення відокремленості. Погана розгортання на backend не виводить публічну адресу. Проксі залишається в роботі; ви вводите поправки або відкат yourselves; світ знову підключається, коли backend відновлюється.

- Роздільні обставини в одному місці. Обмеження швидкості, блокування гео, запис запиту, редагування заголовків, кешування, стиснення відповіді: всі живуть на проксі. Backend код залишається зосередженим на додатку.

Без проксі кожен з цих проблем повинен існувати всередині процесу додатка. З проксі вони живуть на одному шарі, який одна команда керує.

Ціна: ще один шар, який потрібно керувати. Досвідчені команди приймають ціну тому, що шар проксі сам працює безстандартно та масштабується горизонтально; заміна одного проксі на два не вимагає координації.

Блакитно-зелений розгортання через проксі

Ваша команда працює над версією 1 API на трьох виробничих машинах ВМ (блакитна пулі) позаду відвертого проксі. Ви хочете розгорнути версію 2 з можливістю відкатитися назад за 30 секунд, якщо щось пішло не так.

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

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

Від Браузера до Бекенду та Назад

Настіпуй Один Запит Від Кінця До Кінця

Надішліть HTTPS GET https://api.example.com/users/42 через проксі, яке знаходиться перед пулом бекендів.

Гід 1: Розв'язання DNS. Браузер просить розв'язувача про api.example.com. Розв'язувач повертає публічний IP проксі (наприклад, 203.0.113.10). Браузер відкриває TCP-з'єднання з 203.0.113.10:443.

Гід 2: Рукопоживання TLS. Проксі представляє свій сертифікат для api.example.com. Браузер перевіряє сертифікат, сторони погоджуються щодо сесійної ключі, та відкривається шифрований канал.

Гід 3: HTTP-запит всередині TLS. Браузер відправляє GET /users/42 HTTP/1.1\nHost: api.example.com\n.... Проксі дешифрує байти запиту.

Гід 4: Вибір бекенду. Проксі переглядає свій пул бекендів для api.example.com та обирає один бекенд (наприклад 10.0.0.21:8000) за своєю стратегією розподілу навантаження.

Гід 5: Верхній запит. Проксі відкриває (або використовує знову) звичайне HTTP-з'єднання з 10.0.0.21:8000 та відправляє запит. Проксі може змінювати заголовки під час передачі: додати X-Forwarded-For: <client-ip>, встановити Host: правильно, видалити заголовки, які передаються через всі гіди, такі як Connection.

Гід 6: Обробка бекендом. Бекенд-застосування читає запит, запитує базу даних, будує JSON-відповідь.

Гід 7: Верхня відповідь. Бекенд відправляє відповідь назад до проксі у вигляді звичайного HTTP.

Гід 8: Крайня відповідь. Проксі може змінювати або стискувати відповідь, шифрувати її назад через сесію TLS, та відправляти до браузера.

Гід 9: Життя з'єднання. TLS-сесія, як правило, залишається відкритою для наступного запиту (HTTP/2 мультиплексує багато запитів на одне з'єднання). З'єднання проксі-бекенд часто відстежується для повторного використання.

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

Життя циклу запиту: браузер, DNS, проксі, TLS, верхній, бекенд, відповідь

Де Витратився Час?

Користувач скаргує, що API відчувається повільно. Ви вимірюєте та знаходите, що запит займає 850 мс від початку до кінця. Серверні журнали на стороні сервера показують, що додаток обробив запит за 40 мс. Логи проксі показують, що проксі витратило 50 мс на свою роботу (рутування TLS + маршрутизація + запис відповіді).

Де пішов інший 760 мс? Вкажіть принаймні два кандидати, які живуть поза проксі та процесингом сервера, та поясніть, як кожен з них з'явиться в вимірах.

Розробка мінімальної корони для нової послуги

Синтез

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

Тепер застосуйте це.

Маленька команда планує запустити нову послугу під назвою notes.example.com. Користувачі будуть читати та писати персональні нотатки. Команда запустить два виробничі модулі (VM) на початку та планує збільшити їх до десяти протягом наступного року. Користувачам потрібно HTTPS, поступове розгортання нових версій та приховування публічного доступу до IP серверів.

Розробіть архітектуру корони для notes.example.com. Розгляньте: де вказує DNS, де живе сертифікат TLS, як запити досягають сервера, що відбувається, коли вони зростають від двох до десяти серверів, та одну перетинуючу проблему (обмеження швидкості, логування, редагування заголовків тощо), яку ви додасте на короні, а не всередині додатку.

Там, де ця курса йде далі

Ця лекція встановила форму шару корони. Чотири наступні лекції в цьому курсі будуть на ньому будувати:

- Безстандартова Горизонтальна Масштабування: чому проксі рівень (& задні частини позаду нього) збільшується дешево, та математика для розміщення відмінних кількості копій.

- Розділення Вхід/Вихід: чому в кінцевому результаті єдина проксі коробка, яка обробляє як вхідне, так і вихідне спотворювання, зрештою зазнає несподіваних невдач, та як розділити шари.

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

- Наблюдність та Ємність: що вимірювати на кордоні, щоб ви дізналися, що щось пошкоджено до того, як користувачі.

Кожен урок стоїть сам по собі. Взяте разом вони надають вам працюючий модель розуму веб-штормового флоту.

Парний урок: geometry_of_proxies_and_origins перекладає все в цьому урокі в напрямок графу та досліджує, що теорія графів каже вам про шлях запиту.

Добре зроблено. Надалі.