Spokój na localhost i zniszczone złudzenia
Kiedy byłem w szkole, cały mój świat był localhost. Nawet gdybym zainstalował coś takiego jak XAMPP i stworzył tablicę ogłoszeń przy użyciu PHP, był to świat, który działał tylko na moim komputerze.
Kiedy dołączyłem do firmy, miałem to szczęście, że byłem odpowiedzialny głównie za utrzymanie front-endu. Była to strona administracyjna oparta na Quasarze (Vue.js), a stopień trudności zadania nie był wysoki. Jedyne, co musiałem zrobić, to poprawić literówkę lub wywołać API, które moi seniorzy już dobrze stworzyli za pomocą axios.get() i wyświetlić je na ekranie.
W tamtym czasie axios był dla mnie jak magiczna różdżka. Mimo że nie znam skomplikowanych zasad, po prostu wpisałem adres URL i dane zostały szybko pobrane. Przyszła mi też bezczelna myśl: „Nie ma nic specjalnego w komunikacji między frontendem a backendem, prawda?”
Ale pokój nie trwał długo. Dzieje się tak dlatego, że byłem programistą full-stack żyjącym w stylu życia w małej i średniej firmie, w której brakowało siły roboczej.
Wkrótce przyszedł moment, w którym zamiast modyfikować ekran, musiałem stworzyć własne API dla nowej funkcji. Uruchomiłem serwer za pomocą Spring Boot, o czym szybko dowiedziałem się z YouTube, i wysłałem żądanie z frontonu. Jednak na moim ekranie pojawiły się tylko czerwone błędy CORS i błędy Timeout, a nie dane.
„Działało dobrze, gdy przekazałem to jako zmienną lokalną, ale dlaczego nie mogę po prostu skorzystać z sieci?”
Przeniesienie zmiennej A do zmiennej B na moim komputerze (Localhost) było metodą ze 100% gwarancją bezpieczeństwa. Ale świat poza kablem LAN był inny. To było jak skrzyżowanie z zepsutą sygnalizacją świetlną, a moje dane dotyczyły ciężarówki jadącej tą niebezpieczną drogą. Przez cały ten czas po prostu ładowałem ciężarówkę i wysyłałem ją, ale nie miałem pojęcia, jaką trasę pokonała ciężarówka ani jak została podzielona.
System dostaw w cyfrowym centrum logistycznym
Poszerzmy nasze spojrzenie na świat „cyfrowego centrum logistycznego”. Teraz musimy dostarczyć elementy (dane) wyprodukowane w naszej fabryce (komputer) do klientów (serwerów) daleko.
1. Opakowanie: standardowe pudełko wysyłkowe
Bez względu na to, jak duże dane chcemy wysłać (np. film o rozmiarze 1 GB), nie można wysłać ich wszystkich na raz. Dzieje się tak dlatego, że drogi są wąskie, a ciężarówki małe. Dlatego kroimy dane na bardzo małe kawałki i umieszczamy je w standardowych pudełkach. To jest „Pakiet”.
2. IP (protokół internetowy): Adres i nawigacja
Co mogę zrobić, jeśli mam tylko pudełko? Musisz wiedzieć, dokąd iść.
3. TCP/UDP: Różnice w metodach dostarczania
Teraz musimy zdecydować, do której ciężarówki wysłać pudła.
[Weryfikacja kodu] Prawdziwą twarzą HTTP jest tylko tekst
HTTP, którego powszechnie używamy, to tak naprawdę „treść listu” przewożonego w ciężarówce dostawczej zwanej TCP. Porozmawiajmy z serwerem Naver w najbardziej prymitywny sposób (Socket) bez przeglądarki i biblioteki. Zobaczysz, jak prosty jest protokół HTTP, wystarczy kawałek tekstu.
import socket
# 1. Utworz socket TCP (podnies sluchawke)
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
# 2. Polacz z serwerem Naver (223.130.195.200) na porcie 80 (wybierz numer)
# IP Naver moze sie zmienic (sprawdz nslookup [www.naver.com](https://www.naver.com))
target_host = "[www.naver.com](https://www.naver.com)"
target_port = 80
sock.connect((target_host, target_port))
# 3. Napisz wiadomosc zadania HTTP (zapisz, co chcesz powiedziec)
# Najbardziej surowa forma zadania HTTP
request = "GET / HTTP/1.1rnHost: [www.naver.com](https://www.naver.com)rnrn"
# 4. Wyslij (mow)
sock.send(request.encode())
# 5. Odbierz odpowiedz (sluchaj)
response = sock.recv(4096)
print(response.decode())
# 6. Zamknij polaczenie (rozlacz)
sock.close()
Wyniki wykonania (częściowe):
HTTP/1.1 200 OK
Server: NWS
Date: Mon, 01 Jan 2024 00:00:00 GMT
Content-Type: text/html; charset=UTF-8
...
<html>...</html>
Analiza: to wszystko, co dzieje się wewnętrznie, gdy wywołujemy funkcję axios.get().
HTTP nie jest specjalną technologią, to po prostu obietnica złożona w celu „wymiany tekstów przy użyciu tego protokołu (protokołu) podczas komunikacji”.
Kompromis w praktyce: niezawodność czy szybkość
W praktyce, zwłaszcza przy tworzeniu back-endu, przychodzi moment, w którym musisz wybrać pomiędzy TCP a UDP. (Oczywiście większość korzysta z protokołu HTTP opartego na protokole TCP).
Produktem tego kompromisu jestHTTP/3, który jest często zadawany w ostatnich pytaniach podczas rozmów kwalifikacyjnych. Internet, z którego korzystamy (HTTP/1.1, HTTP/2) działa na TCP. Ponieważ danych nigdy nie należy niszczyć.
Ale czasy się zmieniły. Ludzie chcą oglądać filmy w rozdzielczości 4K bez zakłóceń. Skrupulatny proces weryfikacji protokołu TCP (uzgadnianie) i funkcje takie jak „Stanie w kolejce (blokowanie szefa linii)” stały się teraz frustrujące.
Tak pomyślał Google. „Hej, po prostu użyjmy UDP. Możemy po prostu zaradzić niepokojom na poziomie aplikacji. Ważne, aby wysłać to szybko!”
To jest protokół QUIC i stanowi podstawę protokołu HTTP/3. Jest to trend współczesnej technologii, który porzucił bezwarunkową stabilność (TCP) i wybrał przytłaczającą prędkość (UDP), nawet jeśli oznaczało to podjęcie pewnego ryzyka.
Zamykanie: wyobraź sobie niewidzialną drogę
Teraz wiemy, w jaki sposób dane są dzielone (pakiety) i jaką ciężarówką (TCP/UDP) podróżują.
Kiedy żądanie interfejsu API nie powiedzie się w interfejsie użytkownika, nie myśl tylko: „Czy serwer jest martwy?” jak wcześniej. „Och, czy 3-kierunkowe uzgadnianie nie powiodło się? Czy pakiet został odrzucony przez router w środku? A może DNS nie znalazł adresu?” Jeśli możesz sobie wyobrazić taką warstwę sieci, nie jesteś już „tylko programistą”
Teraz towar z naszej fabryki bezpiecznie dotarł do klienta. Ale w jaki sposób klient otrzymuje ten przedmiot, rozpakowuje go i wyświetla na ekranie? Jak przesłany przez nas kod HTML będzie wyświetlany w przeglądarce?
Następnym razem porozmawiamy o ostatecznym celu tworzenia stron internetowych, czyli zasadach renderowania przeglądarki.