Infrastruktur-Lernprojekt
Ein Lernprojekt, das Netzwerk- und Infrastrukturbausteine mit Standardbibliotheken nachbaut. Im öffentlichen main-Stand stehen aktuell ein Python-HTTP-Client, ein minimaler HTTP-Server und ein lokaler Go-DNS-MVP.
In Entwicklung
Der öffentliche main-Stand enthält drei kleine Netzwerkbausteine und ihre Tests. Sie sind bewusst isoliert und nachvollziehbar; die vollständige Service-Kette ist noch nicht integriert.
Der Client in http-server/client.py akzeptiert [http://]host[:port][/path], setzt standardmäßig Port 80, baut einen GET-Request nach HTTP/1.0 und liest Statuszeile, Header und Body aus dem Socket. Nicht unterstützte Transfer- und Content-Encoding werden explizit abgelehnt.
http-server/server.py bindet sequenziell an 0.0.0.0:8088, liest einen Request-Abschnitt und antwortet mit einer CRLF-gerahmten HTTP/1.1-Response, Content-Length, Connection: close und HELLO WORLD!.
dns-server/server.go beantwortet UDP-Anfragen auf 127.0.0.1:8053. Eine A-Anfrage für app.local liefert 127.0.0.1; unbekannte Namen werden als NXDOMAIN beantwortet, andere oder fehlerhafte Anfragen bleiben begrenzt.
http-server/tests/ prüft URL-Parsing, Client-Server-Integration, abgelehnte Verbindungen, HTTPS-Ablehnung und den Server-Smoke-Test. dns-server/server_test.go prüft bekannten Record, NXDOMAIN, nicht unterstützte Typen und fehlerhafte Pakete.
Die README-Dateien dokumentieren Start und Tests. ADRs halten die Entscheidung für Python-unittest sowie Go und die testnahe Struktur des DNS-MVP fest.
Die Zielkette bleibt eine Architektur-Roadmap, kein nachgewiesener End-to-End-Betrieb. Client, DNS-MVP und ein einzelner HTTP-Server existieren separat; Load Balancing und die Verbindung zu Redis sind noch nicht umgesetzt.
Der Python-Client ist der erste konkrete Baustein und stellt HTTP/1.0-GET-Anfragen über einen Socket.
Der Go-DNS-MVP beantwortet lokale A-Anfragen für app.local auf 127.0.0.1:8053.
Noch nicht implementiert; dieser Baustein soll später mehrere HTTP-Server ansprechen.
Ein minimaler Python-Server antwortet auf 0.0.0.0:8088; mehrere Server und die vorgeschaltete Verteilung sind geplant.
Noch nicht implementiert; ein Redis-Clone soll später einfache Zustands- und Datenabläufe ergänzen.
Der aktuelle Stand wächst von isolierten, getesteten Netzwerkbausteinen in Richtung einer verbundenen Lernumgebung. Jede neue Stufe bleibt am Code und an den Tests im Repository messbar.
Python-Sockets machen URL-Verarbeitung, Requests, Responses und einfache Verbindungsabläufe nachvollziehbar.
Ein kleiner Go-UDP-Dienst bildet eine begrenzte A-Auflösung mit festem lokalen Record ab.
Standardtoolchains, Smoke- und Verhaltenstests sowie ADRs halten die Lernschritte reproduzierbar.
Routing, Weiterleitung und Verteilung von Requests als getrennte Verantwortungen untersuchen.
Zustandsspeicherung und Prozessisolation als weitere Grundlagen nachbauen.
Heartbeat-, Registrierungs-, Producer-, Consumer- und persistente Objektabläufe ergänzen.
Beobachtung, Ressourcenverteilung und signierte TLS-Kommunikation als spätere Themen abbilden.
Der öffentliche main-Stand enthält einen Python-HTTP-Client, einen minimalen Python-HTTP-Server und einen Go-DNS-MVP. Alle drei Bausteine haben passende Tests; die End-to-End-Kette ist noch nicht gebaut.
Die Seite trennt deshalb belegten Repository-Stand von der README-Roadmap. Reverse Proxy, Load Balancer, Redis-Clone, Container Runtime und die weiteren Erweiterungen bleiben Ziele. Maßgeblich sind der Code, die Tests und die Dokumentation im öffentlichen Repository.
