URLs (Netzwerkgrundlagen) – Anwendungsentwickler-Podcast #136

Dieser Beitrag ist Teil 1 von 5 in der Serie Netzwerkgrundlagen.

Um den Aufbau von URLs geht es in der einhundertsechsunddreißigsten Episode des Anwendungsentwickler-Podcasts.

Probeabo bei Audible (Affiliate)

Inhalt

Use Case

  • Was passiert technisch, wenn der Browser eine Website anzeigt?
    • Übrigens: Unterschied Website/Homepage: Eine Website ist die Gesamtheit an Inhalten des Anbieters, während die Homepage lediglich die Startseite des Angebots bezeichnet.
  • Der Client ruft eine Adresse im Browser auf und der Server liefert HTML zurück, das der Browser rendert (in eine grafische Darstellung umwandelt) und auf dem Client darstellt.
    • Übrigens: Intranet vs. Internet: Der grundsätzliche Vorgang ist derselbe, nur der Webserver steht im internen Netz bzw. ist nur aus dem internen Netz heraus erreichbar.

URLs

  • Woher wissen Client und Server, wohin sie ihre Daten schicken müssen?
  • Der Client muss zunächst die Zieladresse kennen. Dies ist meistens ein URL wie z.B. www.google.com
  • URL steht für Uniform Resource Locator.
  • Wie sind URLs aufgebaut?
    • Beispiel: http://blog.macke.it/posts/post.php?id=123#comments
    • Der erste Teil ist das sogenannte Schema oder Protokoll. Davon gibt es mehrere, nicht nur http, sondern z.B. auch noch ftp oder mailto (Pseudo-Protokoll).
    • Die Domain ist hierarchisch von rechts nach links absteigend aufgebaut. Die Top Level Domain ist z.B. de oder com. Danach kommt die eigentliche Domain mit ggfs. Subdomain und Hostname. Das www ist übrigens der Hostname (übliche Bezeichnung des Webservers) und nicht verpflichtend in einem URL!
    • Danach kommt der Pfad, der vergleichbar mit einem Pfad und einer Datei auf einer Festplatte ist. Das php steht für die Programmiersprache PHP, mit der Websites entwickelt werden können.
    • Nach dem Dateinamen können Parameter als Schlüssel/Wert-Paare angegeben werden, um z.B. mit einer physikalischen Datei unterschiedliche Artikel in einem Warenkorb anhand ihrer ID anzeigen zu können.
    • Zuletzt ist noch ein Abschnitt möglich, über den man z.B. direkt auf eine Überschrift mitten auf der aktuellen Seite springen kann. Das Zeichen # heißt übrigens „Hash“ und nicht „Hashtag“.
    • Benutzername und Passwort zum Zugriff auf die Ressourcen können ebenfalls angegeben werden. Sie werden vor die Domain geschrieben: http://benutzer:passwort@macke.it.

Literaturempfehlungen

Im guten alten IT-Handbuch für Fachinformatiker* werden in Kapitel 4 Netzwerkgrundlagen die meisten hier genannten Inhalte ausführlich erläutert. In meinem Buchclub gehe ich auf die Inhalte auch noch einmal im Detail ein.

Sascha Kersken - IT-Handbuch für Fachinformatiker: Für Fachinformatiker der Bereiche Anwendungsentwicklung und Systemintegration. Inkl. Prüfungsfragen und Praxisübungen (Affiliate)*

Links

Navigation der SerieIP-Adressen (Netzwerkgrundlagen) – Anwendungsentwickler-Podcast #137 >>
Polyglot Clean Code Developer
About the Author
Ausbildungsleiter für Fachinformatiker Anwendungsentwicklung und Systemintegration, IHK-Prüfer und Hochschuldozent für Programmierung und Software-Engineering.

4 comments on “URLs (Netzwerkgrundlagen) – Anwendungsentwickler-Podcast #136

  1. Marcel sagt:

    Hallo Stefan,

    hast Du einer verlässliche Quelle, woher die 81% PHP Marktanteile kommen, die man selber nachvollziehen kann?
    Würde mich sehr als Argumentgrundlage interessieren, da ich oft Zahlen hören und gefragt werden, wo ich diese her habe und wie die zustande kommen.

    GGDVG

  2. Stefan Macke sagt:

    Hallo Marcel, schau mal hier: https://w3techs.com/ Die werten 10 Millionen Websites aus und da ist PHP Anfang 2019 bei 79% Marktanteil. WordPress allein hat schon 30% Marktanteil aller Website.

  3. Julian Schweinsberg sagt:

    Ersteinmal:

    URLs sind eine tolle Sache: Sie sind einheitlich aufgebaut und die Liste der Protokolle ist erweiterbar.

    Zur „selben“ Zeit (Gopher: [September 1991][1], WWW: „Sommer 1991“) als der erste WWW-Browser kursierte (URLs sind effektiv mit dem WWW einhergegangen) sah es bei Gopher im Bezug auf Hyperlinks bzw. dem Referenzieren von „Dritt-Protokoll“-Ressourcen anders aus: Nach RFC 1436 gibt es 14 verschiedene Menüitemtypen, davon beziehen sich nur 3 auf andere Protokolle (zusätzlich: mindestens finger und HTTP 0.9 kann man theoretisch mittels Itemtyp „0“ abdecken). Im Vergleich zu Systemen die URLs benutzen „ein Witz“.

    (URLs sind mithilfe einer [Konvention][7] „neuerdings“ auch in Gopher benutzbar)

    Ich denke schon, dass der Hostname „www“ praktische Relevanz hat:

    Anders als bei einigen anderen Protokollen gibt es für HTTP keine spezifizierten SRV-Records im DNS. HTTP muss somit immer (wenn nicht anders in der URL angegeben) auf Port 80 auf dem Host laufen auf den der Domainname/Hostname aus der URL (eventuell über Umwege) im DNS zeigt.

    Wenn ich nun aus idiologischen oder sicherheitstechnischen Gründen meinen HTTP-Server nicht auf dem selben Host wie meinen Gopher-Server laufen lassen will, dann muss einer der beiden Server auf einen anderen Host ausweichen und benötigt einen anderen Hostnamen. Und da bieten sich die Hostnamen aus RFC 2219 (unteranderem „www“) an.

    Jetzt mal abgesehen von diesem Nicht-Grund, hier ein realistischer (mir ist im Nachhinein aufgefallen, dass das derselbe ist…):

    Wer sagt, dass ich nicht irgendwann einmal meinen HTTP-Server auf einen anderen Host umziehen werde, dessen Hostname dann von dem der Domain (da läuft dann nur mein Gopher-Server drauf :P) abweicht (verwirrend: Die „Domain“ kann Domainname und Hostname sein), dann werden alle alten Hyperlinks nicht mehr funktionieren.

    Aber frei nach dem Motto „Cool URIs don’t change“ wollen wir das nicht.

    Einfachste Lösung: Der Hostname „www“ zeigt im DNS via CNAME auf den momentanen Host mit HTTP-Server und man benutzt von Anfang an in allen Hyperlinks den „www“-Hostnamen. Diese Indirektion erlaubt es uns den HTTP-Server irgendwo anders hinzuschieben ohne andere Dienste zu beeinträchtigen. „www“ beschreibt somit nicht mehr den Hostnamen sondern den Verweis auf den HTTP-Server „an sich“. (Ein Ersatz für den nicht existierenden SRV-Record für HTTP minus der Portangabe und noch anderen Dingen)

    [1]: * gopher://cyber.dabamos.de/0/gopher/articles/Usenet_Gopher_Announcement.txt „10. September 1991 – Client und Server veröffentlicht“ (Valide gopher://-URLs werden mindestens in der Vorschau ignoriert und aus dem Inhalt entfernt)

    [7]: * gopher://gopher.quux.org/0/Archives/Mailing Lists/gopher/gopher.2002-02|/MBOX-MESSAGE/34

  4. Stefan Macke sagt:

    Hallo Julian, vielen Dank für die Ergänzung. Aber: Gopher!? Nutzt das (noch) jemand? 😀 Ansonsten finde ich die Idee mit dem DNS-Eintrag für „www“ gut, wenn man später den Server ändern will.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax