TCP bzw HTTP Protokoll?
Ich bin etwas verwirrt, also soweit ich weiß wird ja beides bei einer Anfrage an einen server genutzt, aber in welcher Reihenfolge oder sind die durcheinander oder ist tcp doch nur ein Teil von http?Und warum hat tcp einen three way handshake, wenn http dieverbindung schon abgesicher hat? Ich bin so derbe verwirrt, würde mich über eine ausführliche Antwort freuen, da diese beiden Themen irgendwie immer nur einzelnd, aber nie kombiniert erklärt werden...
5 Antworten
TCP ist es egal, ob HTML oder Mail oder Stream läuft, ist das Fundament sozusagen. Das "Handshake" ist die Quittung, dass die Pakete korrekt angekommen sind, egal, was die Pakete im Einzelnen beinhalten.
HTML ist dann der Dateninhalt von einem bis mehreren IP-Paketen, ist also eine Ebene höher.
Um bei Deiner Terminologie zu bleiben: TCP ist das Transport"medium", welches HTML oder was auch sonst enthalten kann.
Stell Dir einen Zirkus vor, um das Zelt zu transportieren, braucht es etlicher LKWs. also IP-Pakete. Wenn ein LKW am neuen Standort angekommen ist, teilt der Fahrer mit "angekommen" und lädt ab. Wenn alle LKWs angekommen sind, erfolgt eine Komplettmeldung, jetzt kann der auf die LKWs verteilte Inhalt zum Zelt aufgebaut werden. Das klappt aber nur, wenn alle Pakete äh LKWs angekommen sind.
Das Zelt ist dann ein HTML-Teil, TCP/IP-Quittungen haben nichts mit Absichern zu tun, sie garantieren nur fehlerfreien Transport. Wenn ein LKW ein Problem (Panne, was auch immer) hat, muss dessen Transportinhalt ja neu initiiert, ausgeführt werden. Das ist Sache des IP-Protokolls.
HTTP kümmert sich um sowas nicht, es erwartet, vollständiges bekommen zu haben.
Mal etwas lax erklärt.
Das geht auch aus dem OSI-Modell im Prinzip so hervor. HTML braucht TCP/IP, aber TCP/IP braucht nicht HTML.
WICHTIG: Ich meine natürlich immer HTTP statt HTML! Da war Kaffeemangel usw. aktiv... sorry.
Und http gibt den auftrag für die Lieferung und setzt die Lieferung wieder zusammen?
TCP/IP ist doch eine bidirektionale Angelegenheit. Wenn ein Client per TCP/IP an einen Server sendet, findet zuerst ein TCP/IP-Handshake statt bez. Vollständigkeit usw. Das ist der aufgerufenen Web-Seite aber völlig egal, diese interpretiert den HTML-Inhalt und antwortet dann mit was auch immer. Diese Antwort gelangt wiederum via TCP/IP samt beschriebener Handshakes zum Client, nur eben "umgekehrt". Dem Client sein Browser ist das TCP/IP-Zeugs egal, er interpretiert dann die Antwort vom Server, verlässt sich dabei auf das IP-Protokoll, welches die Vollständigkeit der Antwort garantiert.
Was immer dann weiter HTML-seits abläuft, TCP/IP ist für Vollständigkeit usw. zuständig, hat nichts mit den HTML-Aktionen zu tun.
Zu HTTP steht hier alles drin, so gut und so viel kann ich gar nicht schreiben... ;)
https://www.ionos.de/digitalguide/hosting/hosting-technik/was-ist-http/
korrigier bloß dein HTML wenn du von HTTP sprichst . TCP->HTTP->HTML , von HTML hat der Fragende übrigens gar nciht geredet . nur das jetzt nicht noch ein lesender das ganze falsch versteht, den HTML ist dann noch mal eine Ebene höher eingebettet in den ganzen HTTP prozess , könnte aber auch über jedes andere protokoll übertragen werden . das es eigentlich gar nichts damit zu tun hat . es ist ja nur eine markuplanguage .
da hast Du natürlich Recht - sorry, hoffe, es ist noch nicht zu spät für den FS... ;--)) (Ich brauche KAFFEEEEE!!)
kurz gesagt, TCP verbindet deine Netzwerkkarte mit der Servernetzwerkkarte
wenn es die verbindung gibt , wird darin eine verbindungs zwischen z.b. deinem browser und der serversoftware gemacht .
ergo http ist eine andwendungsprotokoll , wärend tcp ein netzwerkprotokoll ist .
und eine anwendung brauch ein netzwerk um mit anderen anwendungen im netzwerk reden zu können . jeder dieser teile macht seine arbeit eigenständig . und jeder der teile brauch auch seine eigene verbindungs logik . quasi ist immer alles geschachtelt , der eine transportiert die payloads (nutzerdaten) damit er das machen kann muss er eine verbindung aufbauen und das andere kann dann bei der verbindung darüber kommunizieren . und praktisch hast du 65000 einzelne logische leitungen (ports pro ip) in deiner netzwerkkarte , könntest also 65000 verbdinugnen zu einzelnen diensten aufbauen , wie und was die miteinander reden ist dem tcp egal . das transportier nur infos an den richtigen port .
wie beim telefon ... ob du chineisch oder deutsch sprichst und ein vertrag verhandelst mit deinem kunden , erstmal musst du eine verbindung aufbauen und ihn anrufen . ob du dann selber mit HALLO / 你好 oder GUTEN TAG / 再会 und auf antwort wartest, interressiert das telefon doch nicht ;) ohne telefonverbindung kannst auch nicht mit deinem Kunden reden .
Du kannst mit TCP eine HTTP anfrage bauen, aber nicht umgekehrt. HTTP -> Anfrage, Daten übermitteln und zurückgeben. TCP -> Anfrage, Daten übermitteln und zurückgeben und Tür offenhalten, für weitere Kommunikation. Kurz gesagt. Ist in der Praxis natürlich komplexer
TCP ist kein Teil von HTTP, beides sind unabhängige Protokolle. Sie werden in einer bestimmten Reihenfolge abgearbeitet. Bei einer Netzwerkkommunikation hast Du immer eine Verschachtelung mehrerer Protokolle, z. B.
Bits auf der Leitung -> Ethernet -> IP -> TCP -> HTTP
IP kann IPv4 oder IPv6 sein. Statt TCP kann auch für bestimmte Anwendungen UDP verwendet werden:
Bits auf der Leitung -> Ethernet -> IP -> UDP -> DNS
Und warum hat tcp einen three way handshake, wenn http dieverbindung schon abgesicher hat?
Das ist ein Problem der Wortwahl. Bei HTTP wird nichts abgesichert. Allenfalls bei HTTPS kann man von "absichern" sprechen. Das bedeutet aber etwas anderes als das "Absichern" bei TCP. TCP sorgt dafür, dass auf dem Transportweg keine Daten verloren gehen bzw. sorgt dafür, dass Daten, die verloren gegangen sind, neu gesendet werden. Zudem sorgt TCP für eine Flusskontrolle, um besser mit Engpässen auf dem Transportweg umgehen zu können. Das alles kann HTTP(S) nicht leisten. Die "Absicherung" bei HTTPS ist eine kryptografische Absicherung. So wird sichergestellt, dass Du mit dem aufgerufenen Server kommunizierst, dass die Daten verschlüsselt und damit gegen Mitlesen geschützt sind und dass die Daten gegen Manipulation geschützt sind.
Schau dir das OSI Referenzmodell an.
hab ich, daher denk ich ja das tcp ein teil von http ist, das erklärt aber nicht warum tcp noch einen 3 way handshake braucht, wenn http die verbindung einweg absichert
und warum heißt es http request, wenn es doch eigentlich dcp request heißen müsste?