Co stoi na czele prawie każdej usługi webowej
Witamy
Jeśli wpiszesz example.com w przeglądarce, prawdopodobnie nigdy nie dotkniesz rzeczywistego serwera aplikacji. Dostajesz się do maszyny, która przekierowuje żądanie do tej, która potrafi to zrobić. Ta maszyna przekierowująca nosi nazwę: wstawiennictwo odwrotne.
Ten przekaz nauczysz się, co robi wstawiennictwo odwrotne, dlaczego prawie każda publiczna usługa webowa ukrywa się za jednym, oraz jakie trzy zadania warstwa brzegowa wykonuje jednocześnie.
Po zakończeniu zrozumiesz:
- Różnicę między klientem, proxy a pochodzeniem
- Dlaczego proxy przed pochodzeniem chroni, skaluje i pozwala na wymianę fragmentów bez względu na to, czy ktoś się o to zorientuje
- Trzy zadania, które wstawiennictwo odwrotne wykonuje jednocześnie: ukrywanie pochodzenia, zakończenie TLS, oraz rozdział obciążenia między replikami
- Jak żądanie podróżuje z przeglądarki do proxy, a następnie do górnych i z powrotem, krok po kroku
Po zakończeniu będziesz mógł z pewnością argumentować na temat umiejscowienia proxy, separacji zadań na brzegu oraz dlaczego warstwa proxy wielokrotnie wzrasta, podczas gdy pojedyncze pochodzenie nie rośnie.
Wstawiennictwo odwrotne vs Wstawiennictwo przód
Dwie kierunki proxy
Obie rodziny proxy stoją między dwiema stronami a przekazują dane. Różnią się stroną, którą reprezentują.
Wstawiennictwo przód: stoi na czele grupy klientów. Klienci wiedzą o proxy; serwer zewnętrzny widzi adres proxy, a nie adres klienta. Egress proxy korporacyjne, filtry treści i SOCKS proxy pasują do tego wzorca.
Wstawiennictwo odwrotne: stoi na czele grupy serwerów. Świat zewnętrzny (klienci) rozmawia z adresem proxy; klienci nie wiedzą, że prawdziwy serwer ukrywa się za nim. prawie każda publiczna usługa webowa korzysta z tego.
Pamiętnik: wstawiennictwo przód ukrywa klientów przed serwerami. Wstawiennictwo odwrotne ukrywa serwery przed klientami.
Dlaczego warto zwracać uwagę na kierunek? Zadanie, tryb awaryjny i granica bezpieczeństwa różnią się. Wstawiennictwo przód martwi się o to, z kim jego użytkownicy się komunikują. Wstawiennictwo odwrotne martwi się o to, z kim się kontaktuje jego serwery.
Klient przesyłający dane przez obie metody podróżuje: client -> forward_proxy -> internet -> reverse_proxy -> origin.
Dlaczego Tyle Jest na Krawędzi
Warstwa Krawędzi Wypracowuje Swój Żywot
Proxy odwrotny wykonuje trzy prace jednocześnie. Każda z nich usprawiedliwia warstwę; wykonywanie wszystkich trzech na tym samym adresie wyjaśnia, dlaczego niemal każda produkcyjna architektura webowa wygląda taki sam kształt na froncie.
Praca 1: Ukryj źródło. Proxy odpowiada na publiczny IP. Serwery tła znajdują się na prywatnych IP, których internet nie może dotrzeć. Atakujący, który chce uderzyć w źródło, musi najpierw zakłócić proxy.
Praca 2: Zakończ TLS. Proxy posiada certyfikat dla example.com i dekryptuje przychodzące żądania HTTPS. Serwery tła komunikują się w prostym HTTP (lub prostszym wewnętrznym TLS) z proxy za pośrednictwem zaufanego segmentu sieci. Polityka rotacji certyfikatów, odnowy certyfikatów i zaszyfrowania znajduje się w jednym miejscu.
Praca 3: Rozdzielanie obciążenia. Proxy wybiera, który serwer tła obsłuży każde żądanie. Serwery tła za jednym proxy tworzą pulę; proxy wybiera jeden na żądanie, korzystając z strategii (w kołowo, najmniej połączeń, hasz na nagłówku). Dodanie zdolności oznacza dodanie serwera tła do puli, a nie mówienie każdemu klientowi nowy adres.
Każda praca to mała programista. Razem wyjaśniają, dlaczego warstwa tak prosta jak 'Caddy przed aplikacją Python' ma więcej wag projektowych niż sama aplikacja Python.
Projektowanie dla wszystkich trzech
Twoja ekipa prowadzi mały API na pojedynczym procesie Pythona słuchającym na porcie 8000 na pojedynczej VM. Przepływ stał się tak duży, że jedna VM nie może utrzymać, a przegląd bezpieczeństwa wskazał, że VM ma publiczny IP i swoje certyfikat TLS.
Zdecydowałeś, że wstawi proxy odwrotny na froncie. Sporządź schemat: gdzie wskazuje DNS, gdzie znajduje się certyfikat, jak obciążenie dociera do serwerów tła oraz co się zmienia na oryginalnej VM?
Zamiana Składnika Bez Zauważenia Przez Klientów
Zastosowanie Pośrednictwa Wyzwala Wolność
Stara adnotacja z zakresu nauki o komputerach głosi: każdy problem można rozwiązać dodaniem warstwy pośrednictwa (z wyjątkiem problemu zbyt wielu warstw pośrednictwa). Odwrotny proxy to jedno z najbardziej użytecznych pośrednictw w systemach rozproszonych.
Co daje Ci to:
- Zamienne tłoczniki tylne. Przenieś aplikację z Pythona na Go? Przenieś się z jednego centrum danych do drugiego? Wprowadź nową wersję z zerowym czasem przestojowym? Każde z nich odbywa się za stabilną publiczną adresą. Nic nie zmienia się dla użytkowników.
- Odrębne skalowanie. Krok pośrednikowy skaluje się na podstawie pasażu i CPU na poziomie TLS. Krok tylne skaluje się na podstawie pracy aplikacji. Każde rośnie na własnej osi because they live on different machines.
- Zawężanie uszkodzeń. Źle zainstalowana aktualizacja na tylnej stronie nie wyłącza publicznego adresu. Proxy nadal działa; wprowadzasz poprawki lub cofasz zmiany; świat ponownie łączy się, gdy tylne odzyska się.
- Zagadnienia przecinające w jednym miejscu. Ograniczanie prędkości, blokowanie geograficzne, rejestrowanie żądań, modyfikowanie nagłówków, cacheowanie, kompresja odpowiedzi: to wszystko znajduje się na proxy. Kod backendu skupia się na aplikacji.
Bez proxy każde z tych problemów musi istnieć wewnętrznie w procesie aplikacji. Z proxy istnieją na jednym poziomie, który jeden zespół zarządza.
Koszt: kolejna warstwa do obsługi. Doświadczający zespoły akceptują koszt, ponieważ warstwa proxy sama stanowi stanu i skaluje się poziomo; zastąpienie jednego proxy dwoma wymaga żadnej koordynacji.
Przełączanie Blue/Green Przez Proxy
Twój zespół uruchamia wersję 1 API na trzech maszynach wirtualnych tylnej strony (zbiór niebieski) za pomocą odwrotnego proxy. Chcesz wdrożyć wersję 2 z możliwością szybkiego cofnięcia się w przypadku błędu w ciągu dwudziestu sekund.
Wprowadzasz trzy nowe maszyny wirtualne (zbiór zielony) z wersją 2, obok zielonego zbiornika, ale nie kierujesz jeszcze żadnego ruchu do nich.
Od Przeglądarki do Tła i Z powrotem
Śledź jedno Zapytanie od początku do końca
Śledź jedno HTTPS GET https://api.example.com/users/42 przez proxy odwrotny przed pulą tła.
Krok 1: Rozwiązywanie DNS. Przeglądarka pyta rozwiązywania DNS o api.example.com. Rozwiązywacz DNS zwraca publiczny IP proxy (np. 203.0.113.10). Przeglądarka otwiera połączenie TCP z 203.0.113.10:443.
Krok 2: Rękojmię TLS. Proxy prezentuje swoją certyfikat dla api.example.com. Przeglądarka weryfikuje certyfikat, strony uzgadniają klucz sesji, i otwiera kanał szyfrowany.
Krok 3: Zapytanie HTTP wewnętrznie TLS. Przeglądarka wysyła GET /users/42 HTTP/1.1\nHost: api.example.com\n.... Proxy odkodowuje bajty zapytania.
Krok 4: Wybór tła. Proxy konsultuje swoją pulę upstream dla api.example.com i wybiera jedno tło (np. 10.0.0.21:8000) stosując swoją strategię równoważenia obciążenia.
Krok 5: Zapytanie upstream. Proxy otwiera (lub wykorzystuje ponownie) połączenie HTTP zwykłe z 10.0.0.21:8000 i przekierowuje zapytanie. Proxy może modyfikować nagłówki podczas przekierowywania: dodaje X-Forwarded-For: <client-ip>, ustawia Host: poprawnie, usuwa nagłówki takie jak Connection.
Krok 6: Obliczenia tła. Aplikacja tła odczytuje zapytanie, kwerendy bazy danych, buduje odpowiedź JSON.
Krok 7: Odpowiedź upstream. Tło wysyła odpowiedź z powrotem do proxy jako HTTP zwykłe.
Krok 8: Odpowiedź brzegowa. Proxy może modyfikować lub kompresować odpowiedź, szyfrować ją z powrotem przez sesję TLS i wysyłać ją do przeglądarki.
Krok 9: Cykl życia połączenia. Sesja TLS pozostaje otwarta na następne zapytanie (HTTP/2 multiplexuje wiele zapytań na jednym połączeniu). Połączenie proxy-do-tła często puluje dla ponownego użycia.
Każde publiczne usługi internetowe stosuje pewną wariację tego kształtu. Znać kroki pozwala na rozumowanie o miejscach, gdzie opóźnienia gromadzą się, gdzie należy umieścić logowanie, i gdzie błąd może ukryć się.
Gdzie Poszły Minuty?
Użytkownik skarży się, że API czuje się powolne. Znajdziesz i stwierdzisz, że żądanie zajmuje 850 ms od początku do końca. Serwery logowania na stronie backend pokazują, że aplikacja obsłużyła żądanie w 40 ms. Logi proxy pokazują, że proxy spędziło 50 ms na swojej stronie pracy (rękojmię TLS + routowanie + zapisywanie odpowiedzi).
Projektuj minimalną krawędź dla nowego usługi
Synteza
Nauczysz się różnicy między forward a reverse proxy, trzech zadań, które reverse proxy wykonuje jednocześnie, dlaczego ukrywanie pochodzenia przynosi zyski każdorazowo, gdy musisz coś zmienić, oraz jak żądanie przepływa krok po kroku przez krawędź.
Teraz zastosuj to.
Mała ekipa planuje uruchomić nową usługę o nazwie notes.example.com. Użytkownicy będą czytali i wpisywali swoje osobiste notatki. Zespół zaczął z dwoma serwerami backend i planuje skalowanie do dziesięciu w ciągu roku. Chcą HTTPS dla użytkowników, stopniowe wdrażanie nowych wersji i brak publicznego wyświetlania IP backendów.
Gdzie ta kurs idzie dalej
Gdzie ta lekcja idzie dalej
Ta lekcja ustaliła kształt warstwy krawędzi. Cztery kolejne lekcje w tym kursie opierają się na nim:
- Bezstanowy Skalowanie W Pionie: dlaczego poziom proxy (& tłumacze znajdujące się za nim) można szybko powiększyć, & matematyka rozmiaru liczb odwrotów pod sztorm.
- Rozdział Prądów Wpływowych / Wypływowych: dlaczego pojedynczy box proxy obsługujący obie ruchliwości - wpływające & wypływające - kończy się w nieoczekiwany sposób, & jak podzielić warstwy.
- Tryby Awarii & Promieniowanie Eksplozji: jak zmiana konfiguracji rozprzestrzenia się w wyjątkowy wybór, & jak pisać nieodpowiedzialne aktywności, które zapobiegną powtórzeniu.
- Obserwacyjność & Pojemność: co mierzyć na krawędzi, aby dowiedzieć się, że coś jest złe przed użytkownikami.
Każde lekcja stoi samodzielnie. Wzięte razem dostarczają Ci funkcjonalny model mentalny floty skalowanej.
Lekcja towarzysząca: geometry_of_proxies_and_origins przekształca wszystko z tej lekcji w graf kierunkowy & bada, co teoria grafów mówi o ścieżce żądania.
Brawo. Dalej.