Was ist HTTP?

Ganz vorne in der Adresse einer Website steht „http://“ (oder „https://“). Dies be­zeich­net das HTTP-Protokoll, das Ihr Web­brow­ser verwendet, um eine Webseite auf­zu­ru­fen. Wir stellen Ihnen das Konzept von HTTP vor, erklären die Un­ter­schie­de zwischen den Versionen und zeigen, mit welchen anderen Konzepten HTTP zu­sam­men­hängt.

HTTP steht für „Hypertext Transfer Protocol“. Es wurde von Tim Berners-Lee am CERN (Schweiz) zusammen mit den anderen Konzepten ent­wi­ckelt, die die Grund­la­gen fürs World Wide Web bilden: HTML und URI. Während HTML (Hypertext Markup Language) definiert, wie eine Webseite aufgebaut wird, legt die URL (Uniform Resource Locator) – eine Unterform des URI – fest, wie die Ressource (z. B. eine Webseite) im Web adres­siert werden muss. HTTP hingegen regelt, wie diese Seite vom Server zum Client über­tra­gen wird.

Und was bedeutet ei­gent­lich „Hypertext“, der Begriff, der in den Ab­kür­zun­gen HTTP und HTML vorkommt? Gemeint ist damit ein Konzept, das uns allen wohl­ver­traut ist: das Verlinken von Dateien. In einer Webseite werden Hy­per­links platziert, die auf andere Seiten führen.

Wenn Sie in Ihrem Web­brow­ser eine In­ter­net­adres­se eingeben und kurz darauf eine Webseite angezeigt bekommen, hat Ihr Browser über HTTP mit dem Webserver kom­mu­ni­ziert. Bildlich aus­ge­drückt ist HTTP die Sprache, in der Ihr Web­brow­ser mit dem Webserver spricht, um ihm mit­zu­tei­len, was verlangt wird.

Ur­sprüng­lich diente HTTP lediglich dazu, von einem Webserver ein HTML-Dokument an­zu­for­dern. Heute wird das Protokoll sehr viel­fäl­tig ein­ge­setzt:

• Browser fordern über HTTP alle Arten von Medien an, die auf modernen Webseiten verwendet werden: Text, Bilder, Videos, Pro­gramm­code usw.
• An­wen­dungs­pro­gram­me nutzen HTTP, um Dateien und Updates von ent­fern­ten Servern zu laden.
• Die REST-API ist eine auf HTTP ba­sie­ren­de Lösung zum Ansteuern von Web­ser­vices.
• Ebenfalls eine HTTP-basierte Tech­no­lo­gie ist WebDAV.
• In der Machine-to-Machine-Kom­mu­ni­ka­ti­on (z.B. via Web­ser­vices) wird HTTP als Protokoll für die Kom­mu­ni­ka­ti­on zwischen Web­ser­vices verwendet.
• Auch Me­di­en­play­er nutzen HTTP.
• Zugriffe auf eine Datenbank im Web, d. h. die CRUD-Ope­ra­tio­nen, können ebenfalls über HTTP erfolgen.

Die Ge­schich­te von HTTP begann 1989, als Tim Berners-Lee mit seinem Team am CERN (Schweiz) begann, das World Wide Web zu ent­wi­ckeln. Die Urversion von HTTP trug die Ver­si­ons­num­mer 0.9 und wurde „Einzeiler-Protokoll“ genannt. Sie konnte lediglich eine HTML-Datei von einem Server abrufen.

Der Server tat nichts anderes, als die ent­spre­chen­de Datei zu über­mit­teln. Deshalb konnte diese Pro­to­koll­ver­si­on auch nur HTML-Dateien handhaben.

1996 beschrieb die Internet En­gi­nee­ring Task Force (IETF) im Memo RFC1945 die Version HTTP/1, al­ler­dings erst als un­ver­bind­li­chen Vorschlag. Neu wurde ein Header ein­ge­führt, der sowohl die Anfrage des Clients als auch die Antwort des Servers genauer spe­zi­fi­zie­ren konnte. U. a. wurde das Header-Feld „Content-Type“ ein­ge­führt, das es er­mög­lich­te, auch andere Dateien als HTML zu über­mit­teln. Kurz zu­sam­men­ge­fasst hatte diese HTTP-Version die folgenden Ei­gen­schaf­ten:

• Ver­bin­dungs­los: Der Client baut die Ver­bin­dung zum Server auf, setzt seine Anfrage ab, der Server antwortet – dann wird die Ver­bin­dung ge­schlos­sen. Für die nächste Anfrage muss der Client die Ver­bin­dung wieder neu aufbauen. Dies ist um­ständ­lich, weil eine Webseite in der Regel aus mehreren Dateien besteht und jede von ihnen mittels einer ei­gen­stän­di­gen Anfrage „geholt“ werden muss.
• Zu­stands­los: Die beiden Parteien – Client und Server – „vergessen“ einander gleich wieder. Wenn der Client sich das nächste Mal beim Server anmeldet, weiß dieser nicht, dass der Client ihn schon einmal angefragt hatte.
• Me­di­en­un­ab­hän­gig: Über HTTP kann jede Art von Dateien über­mit­telt werden, solange beide Seiten wissen, wie sie mit dem je­wei­li­gen Dateityp umgehen müssen.

1997 erschien die Version HTTP/1.1, be­schrie­ben im Memo RFC2068. Sie galt als erster „of­fi­zi­el­ler“ Standard und ist bis heute in Gebrauch. Er brachte wichtige Neue­run­gen gegenüber HTTP/1:

• Keepalive: Der Client hat die Mög­lich­keit, die Ver­bin­dung über eine Anfrage hinweg aufrecht zu erhalten (per­sis­tent con­nec­tion), indem er im Header seiner Anfrage ein keepalive („auf­recht­erhal­ten“) mitsendet.
• HTTP-Pipe­lining, sodass der Client eine nächste Anfrage senden kann, bevor er die Antwort auf die erste erhalten hat.
• In Chats kann der Browser unter Ver­wen­dung des MIME-Typs multipart/replace das Brow­ser­fens­ter ak­tua­li­sie­ren.
• Es können auch Daten vom Client zum Server über­tra­gen werden.
• Mit der neu ein­ge­führ­ten TRACE-Methode lässt sich der Weg vom Client zum Webserver verfolgen.
• Cache: Es gibt neue Me­cha­nis­men, um Inhalte zwi­schen­zu­spei­chern.
• Host: Ein HTTP-Request funk­tio­niert dank einer ent­spre­chen­den Spe­zi­fi­ka­ti­on im Header (Host) auch dann, wenn unter einer IP-Adresse mehrere ver­schie­de­ne Domänen gehostet werden – wie dies heut­zu­ta­ge bei der Mehrheit der Websites (Shared Web­hos­ting) der Fall ist.

Im Laufe der Jahre wurden die Websites immer größer und komplexer. Um eine moderne Website in den Browser zu laden, muss dieser mehrere Megabyte Daten anfordern und bis zu hundert einzelne HTTP-Requests absenden. Da HTTP/1.1 vorsieht, dass die Requests innerhalb einer Ver­bin­dung nach­ein­an­der ab­ge­ar­bei­tet werden, dauert der Sei­ten­auf­bau umso länger, je komplexer eine Webseite ist.

Deshalb ent­wi­ckel­te Google ein neues, ex­pe­ri­men­tel­les Protokoll namens SPDY (sprich: „Speedy“). Dieses stieß auf großes Interesse bei der Ent­wick­ler­ge­mein­de und mündete 2015 schließ­lich in die Ver­öf­fent­li­chung der Pro­to­koll­ver­si­on HTTP/2. Dieser neue Standard bringt u. a. folgende Neue­run­gen, die alle darauf abzielen, das Laden von Websites zu be­schleu­ni­gen:

• Binär: Das Protokoll basiert auf Bi­när­da­ten statt Text­da­tei­en.
• Multiplex: Client und Server können mehrere HTTP-Requests parallel absenden bzw. ver­ar­bei­ten.
• Kom­pri­mie­rung: Die Header werden kom­pri­miert; da sie in den vielen HTTP-Requests häufig fast identisch sind, beseitigt die Kom­pri­mie­rung unnötige Redundanz.
• Server Push: Wenn der Server vor­aus­se­hen kann, welche Daten der Client noch benötigen wird, kann er ihm diese von sich aus – ohne vor­gän­gi­gen HTTP-Request – in einen Client-Cache senden.

HTTP/2 konnte sich rasch eta­blie­ren; ins­be­son­de­re Websites mit viel Traffic stellten schon bald darauf um. Aktuell (Stand: Januar 2020) nutzen laut W3Techs rund 42 Prozent der Websites die Version HTTP/2.

Ein Schwach­punkt sämt­li­cher bis­he­ri­ger HTTP-Versionen war das zu­grun­de­lie­gen­de Trans­port­pro­to­koll TCP. Dieses verlangt, dass der Empfänger jedes Da­ten­pa­ket zu­rück­be­stä­tigt, bevor das nächste gesendet werden darf. Wenn nun ein Paket ver­lo­ren­geht, müssen alle anderen Pakete auf die erneute Über­tra­gung des ver­lo­re­nen warten. Fachleute sprechen bei einem solchen Fall von „Head-of-Line Blocking“.

Das neue HTTP/3 soll daher nicht mehr auf TCP aufbauen, sondern auf UDP, das keine der­ar­ti­gen kor­ri­gie­ren­den Maßnahmen verlangt. Ausgehend von UDP wurde das Protokoll QUIC (Quick UDP Internet Con­nec­tions) ent­wi­ckelt, das die Grundlage für HTTP/3 bilden soll.

Noch ist HTTP/3 nicht vom IETF definitiv ver­ab­schie­det worden. Dennoch nutzen laut W3Techs bereits knapp 3 Prozent der Websites QUIC bzw. HTTP/3.