Vrede op localhost en gebroken illusies
Toen ik op school zat, bestond mijn hele wereld uit localhost. Zelfs als ik zoiets als XAMPP installeerde en een bulletinboard maakte met PHP, was het een wereld die alleen op mijn computer draaide.
Toen ik voor het eerst bij het bedrijf kwam, had ik het geluk voornamelijk verantwoordelijk te zijn voor het front-end onderhoud. Het was een beheerderspagina gebaseerd op Quasar (Vue.js) en de moeilijkheidsgraad van de taak was niet hoog. Het enige wat ik hoefde te doen was de typefout corrigeren of de API aanroepen die mijn senioren al goed hadden gemaakt met axios.get() en deze op het scherm weergeven.
Destijds was axios als een toverstaf voor mij. Ook al ken ik de ingewikkelde principes niet, ik heb gewoon de URL ingevoerd en de gegevens werden snel opgehaald. Ik had ook een brutale gedachte: “Er is niets speciaals aan de communicatie tussen de front-end en de back-end, toch?”
Maar de vrede duurde niet lang. Dit komt omdat ik een ‘levende full-stack’ ontwikkelaar was bij een klein en middelgroot bedrijf dat geen mankracht had.
Al snel kwam het moment waarop ik mijn eigen API moest maken voor een nieuwe functie, in plaats van het scherm aan te passen. Ik startte een server met Spring Boot, die ik snel van YouTube leerde, en stuurde een verzoek vanaf de frontend. Het enige dat op mijn scherm verscheen, waren echter rode CORS-fouten en Time-out-fouten, geen gegevens.
“Het werkte prima toen ik het als lokale variabele doorgaf, maar waarom kan ik niet gewoon het netwerk gebruiken?”
Het verplaatsen van variabele A naar variabele B op mijn computer (Localhost) was een 100% gegarandeerd veilige methode. Maar de wereld buiten de LAN-kabel was anders. Het leek op een kruispunt met een kapot verkeerslicht, en mijn gegevens waren een vrachtwagen die op die gevaarlijke weg reed. Al die tijd was ik alleen maar bezig met het laden en versturen van de vrachtwagen, maar ik had geen idee welke route de vrachtwagen nam of hoe deze was verdeeld.
Leveringssysteem in digitaal logistiek centrum
Laten we ons wereldbeeld van het ‘digitale logistieke centrum’ uitbreiden. Nu moeten we de items (gegevens) die in onze fabriek (computer) zijn gemaakt, leveren aan klanten (servers) ver weg.
1. Pakket: standaard verzenddoos
Het maakt niet uit hoe groot de gegevens zijn die we willen verzenden (bijvoorbeeld een video van 1 GB), deze kunnen niet in één keer worden verzonden. Dit komt omdat de wegen smal zijn en de vrachtwagens klein. Daarom hebben we de gegevens in zeer kleine stukjes geknipt en in gestandaardiseerde dozen gestopt. Dit is een ‘pakket’.
2. IP (Internet Protocol): Adres en navigatie
Wat kan ik doen als ik alleen een doos heb? Je moet weten waar je heen moet.
3. TCP/UDP: verschillen in bezorgmethoden
Nu moeten we beslissen naar welke vrachtwagen we de dozen willen sturen.
[Codeverificatie] Het echte gezicht van HTTP is slechts tekst
De HTTP die we gewoonlijk gebruiken, is eigenlijk alleen maar de ‘inhoud van de brief’ die wordt vervoerd in een bestelwagen genaamd TCP. Laten we op de meest primitieve manier (Socket) met de Naver-server praten zonder browser of bibliotheek. Je zult zien hoe eenvoudig HTTP is, slechts een stukje tekst.
import socket
# 1. TCP-socket aanmaken (telefoon opnemen)
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
# 2. Verbinden met Naver-server (223.130.195.200) op poort 80 (nummer kiezen)
# Naver IP kan veranderen (controleer met 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. HTTP-verzoekbericht opstellen (schrijf wat je wilt zeggen)
# Meest ruwe vorm van een HTTP-verzoek
request = "GET / HTTP/1.1rnHost: [www.naver.com](https://www.naver.com)rnrn"
# 4. Versturen (spreken)
sock.send(request.encode())
# 5. Antwoord ontvangen (luisteren)
response = sock.recv(4096)
print(response.decode())
# 6. Verbinding sluiten (ophangen)
sock.close()
Uitvoeringsresultaten (gedeeltelijk):
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>
Analyse: dit is alles wat er intern gebeurt als we axios.get() aanroepen.
HTTP is geen speciale technologie, het is slechts een belofte die is gedaan om “teksten uit te wisselen met behulp van dit protocol (protocol) wanneer we communiceren.”
Afweging in de praktijk: betrouwbaarheid of snelheid
In de praktijk, vooral in de backend-ontwikkeling, komt er een moment dat je moet kiezen tussen TCP en UDP. (Natuurlijk gebruiken de meeste op TCP gebaseerde HTTP)
HTTP/3, dat vaak wordt gesteld in recente interviewvragen, is het product van deze afweging. Het internet dat we gebruiken (HTTP/1.1, HTTP/2) draait op TCP. Omdat gegevens nooit vernietigd mogen worden.
Maar de tijden zijn veranderd. Mensen willen 4K-video zonder onderbrekingen bekijken. Het nauwgezette verificatieproces van TCP (Handshake) en functies zoals “Stand in line (Head of Line Blocking)” zijn nu frustrerend geworden.
Dat dacht Google. “Hé, laten we gewoon UDP gebruiken. We kunnen het ongemak op applicatieniveau gewoon wegnemen. Het is belangrijk om het snel te verzenden!”
Dit is het QUIC protocol en vormt de basis van HTTP/3. Het is een trend in de moderne technologie die onvoorwaardelijke stabiliteit (TCP) heeft opgegeven en voor overweldigende snelheid (UDP) heeft gekozen, ook al betekende dit het nemen van risico’s.
Sluiting: stel je een onzichtbare weg voor
Nu weten we hoe de gegevens worden opgedeeld (pakketten) en op welke vrachtwagen (TCP/UDP) ze reizen.
Wanneer een API-verzoek op de frontend mislukt, denk dan niet alleen maar: “Is de server dood?” zoals vroeger. “Oh, is de 3-weg handshake mislukt? Is het pakket door de router in het midden gedropt? Of heeft DNS het adres niet gevonden?” Als je je een netwerklaag als deze kunt voorstellen, ben je niet langer ‘slechts een codeur’
Nu zijn de goederen uit onze fabriek veilig bij de klant aangekomen. Maar hoe ontvangt een klant dit artikel, pakt het uit en toont het op het scherm? Hoe wordt de door ons verzonden HTML-code weergegeven in de browser?
De volgende keer zullen we het hebben over de eindbestemming van webontwikkeling, de principes van browserweergave.