Netzwerkprotokolle

www.cash4online.tk
Verfügbare Informationen zu "Netzwerkprotokolle"

  • Qualität des Beitrags: 0 Sterne
  • Beteiligte Poster: xlimited
  • Forum: www.cash4online.tk
  • aus dem Unterforum: Internet & Netzwerk
  • Antworten: 1
  • Forum gestartet am: Sonntag 16.01.2005
  • Sprache: deutsch
  • Link zum Originaltopic: Netzwerkprotokolle
  • Letzte Antwort: vor 18 Jahren, 2 Monaten, 7 Tagen, 5 Stunden, 8 Minuten
  • Alle Beiträge und Antworten zu "Netzwerkprotokolle"

    Re: Netzwerkprotokolle

    xlimited - 22.01.2005, 02:34

    Netzwerkprotokolle
    Die Protokollfamilie TCP/IP

    Die Protokolle der TCP/IP-Familie wurden in den 70-er Jahren für den Datenaustausch in heterogenen Rechnernetzen (d. h. Rechner verschiedener Hersteller mit unterschiedlichen Betriebssystemen) entwickelt.

    TCP steht für 'Transmission Control Protocol' (Schicht 4) und IP für 'Internet Protocol' (Schicht 3). Die Protokollspezifikationen sind in sogenannten RFC-Dokumenten (RFC - Request for Comment) festgeschrieben und veröffentlicht. Aufgrund ihrer Durchsetzung stellen sie Quasi-Standards dar.

    Die Schichten 5 - 7 des OSI-Standards werden hier in einer Anwendungsschicht zusammengefasst, da die Anwendungsprogramme alle direkt mit der Transportschicht kommunizieren. In Schicht 4 befindet sich außer TCP, welches gesicherten Datentransport (verbindungsorientiert, mit Flußkontrolle (d. h. Empfangsbestätigung, etc.) durch Windowing ermöglicht, auch UDP (User Datagram Protocol), in welchem verbindungsloser und ungesicherter Transport festgelegt ist.
    Beide Protokolle erlauben durch die Einführung von sogenannten Ports den Zugriff mehrerer Anwendungsprogramme gleichzeitig auf ein- und diesselbe Maschine.

    In Schicht 3 ist das verbindungslose Internet-Protokoll (IP) angesiedelt. Datenpakete werden auf den Weg geschickt, ohne dass auf eine Empfangsbestätigung gewartet werden muß.
    IP-Pakete dürfen unter bestimmten Bedingungen sogar vernichtet werden. In Schicht 3 werden damit auch die IP-Adressen festgelegt.
    Hier findet auch das Routing, das heißt die Wegsteuerung eines Paketes von einem Netz ins andere statt. Ebenfalls in diese Ebene integriert sind die ARP-Protokolle (ARP - Address Resolution Protocol), die zur Auflösung (= Umwandlung) einer logischen IP-Adresse in eine physikalische (z. B. Ethernet-) Adresse dienen und dazu sogenannte Broadcasts (Datenpakete, durch die alle angeschloßenen Stationen angesprochen werden) verwenden.
    ICMP, ein Protokoll, welches den Austausch von Kontroll- und Fehlerpaketen im Netz ermöglicht, ist ebenfalls in dieser Schicht realisiert.

    Die Schichten 1 und 2 sind gegenüber Schicht 3 protokolltransparent. Sie können durch standardisierte Protokolle (z. B. Ethernet (CSMA/CD), FDDI, SLIP (Serial Line IP), PPP (Point-to-Point Protocol)) oder andere Übertragungsverfahren realisiert werden.

    Zur TCP/IP-Familie gehören mehrere Dienstprogramme der höheren OSI-Schichten (5 - 7), z. B.:


    Telnet (RFC 854)
    Ein virtuelles Terminal-Protokoll, um vom eigenen Rechensystem einen interaktiven Zugang zu einem anderen System zu realisieren.
    FTP (RFC 959)
    Dieses (File-Transfer-) Protokoll ermöglicht, die Dateidienste eines Fremdsystems interaktiv zu benutzen sowie die Dateien zwischen den Systemen hin und her zu kopieren.
    NFS (RFC 1094)
    Das Network File System ermöglicht den Zugriff auf Dateien an einem entfernten System so, als wären sie auf dem eigenen. Man nennt dies auch einen transparenten Dateizugriff. NFS basiert auf den zur TCP/IP-Familie gehörenden UDP- (User- Datagramm-) Protokollen (ebenfalls Schicht 4), RFC 768. Im Unterschied zu TCP baut UDP keine gesicherten virtuellen Verbindungen zwischen kommunizierenden Hosts auf. Aufgrund dieser Eigenschaft ist es für den Einsatz in lokalen Netzen vorgesehen.
    NNTP (RFC 977)
    Das Network News Transfer Protocol spezifiziert Verteilung, Abfrage, Wiederauffinden und das Absetzen von News-Artikeln innerhalb eines Teils oder der gesamten Internet-Gemeinschaft. Die Artikel werden in regional zentralen Datenbasen gehalten. Einem Benutzer ist es möglich, aus dem gesamten Angebot nur einzelne Themen zu abonnieren.
    SMTP (RFC 821/822)
    Das Simple-Mail-Transfer-Protokoll (RFC 821) ist ein auf der IP-Adressierung sowie auf der durch den RFC 822 festgelegten Namensstruktur basierendes Mail-Protokoll.
    DNS (RFC 920)
    Der Domain Name Service unterstützt die Zuordnung von Netz- und Host-Adressen zu Rechnernamen. Dieser Service ist z. B. erforderlich für die Anwendung von SMTP sowie in zunehmendem Maße auch für Telnet und FTP. Aus Sicherheitsgründen wendet sich der fremde Host an den DNS, um zu prüfen, ob der IP-Adresse des ihn rufenden Rechners auch ein (Domain-)Name zugeordnet werden kann. Falls nicht, wird der Verbindungsaufbau abgelehnt.
    Das Protokoll NetBeui NetBEUI wurde Mitte der achtziger Jahre von IBM vorgestellt und bildet die Grundlage vieler LAN-Umgebungen.
    Mit NetBEUI wird nicht nur ein einzelnes Protokoll sondern eine für Kommunikationsdienste komplette Umgebung bezeichnet, die NetBEUI-Umgebung, die sich aus drei Komponenten zusammensetzt:


    Der Schnittstelle NetBIOS,
    dem eigentlichen Protokoll NetBEUI
    und der Schnittstelle NDIS.
    NetBIOS (Netware Basic Input Output System) ist eine programmierte Schnittstelle, die zwischen der eigentlichen Anwendung und den Kommunikationsprotokollen liegt. Der Hauptbestandteil von NetBIOS ist sein Dienst zur Verwaltung logischer Namen, dem sog. Name-Service. Er erlaubt die Verwaltung logischer Namen in Verbindung mit MAC-Adressen. Die Namen entsprechen daher Synonymen für die MAC-Adressen der LAN-Adapter-Karten (Netzwerkkarten) bzw. ihrer jeweiligen Endgeräte.

    Das eigentliche Protokoll NetBEUI (NetBIOS Extended User Interface) erweitert NetBIOS um die nötigen Protokollfunktionen. Es benutzt zur Adressierung der Endgeräte die von NetBIOS verwalteten MAC-Adressen und liegt in Schicht 2 des OSI-Modells. Daraus resultiert eine wesentliche Eigenschaft: NetBEUI ist nicht routbar, da es keine Funktionen der Vermittlungsschicht (Schicht 3) zur softwaremäßigen Adressenvergabe besitzt. NetBEUI wurde als LAN-Protokoll konzipiert, um kleine Gruppen zu verbinden. Es findet daher besonders in Peer-to-Peer-Netzwerken Anwendung.

    NDIS (Network Driver Interface Specification) ist ein für die Schnittstellenfunktion zwischen den Protokollen und der LAN-Adapter-Karte erforderlicher Softwaretreiber, der auch in NetBEUI-Umgebungen verwendet wird.

    Das Protokoll IPX / SPX

    Das Internet Packet Exchange-Protokoll wurde von Novell entwickelt. Das Ziel von Novell war es, Interoperabilität in Netware-Netzen zu ermöglichen.

    In Verbindung mit den MAC-Protokollen stellt IPX Adressierungsmöglichkeiten zur Verfügung.
    Diese versetzen Netware-Router in die Lage, Datenpakete zu routen. Das eigentliche Routing basiert auf dem Routing Information Protocol (RIP).

    Eine IPX-Zieladresse (IPX destination Adress) beinhaltet folgende Routinginformationen:


    Netzwerknummer (4 Byte)
    eindeutige Zuordnung für jedes Segment
    Knotennummer (6 Byte)
    gebildet aus der Adresse der Datenendeinrichtung (DEE); identifiziert eine DEE eindeutig
    Socketnummer (2 Byte)
    identifiziert einen Prozess innerhalb der Datenendeinrichtung
    Im OSI-Referenzmodell finden wir IPX in der Schicht 3 (Netzwerkschicht) wieder. Es stellt einen verbindungslosen Dienst zur Verfügung. Dieser arbeitet nach dem "Best Effort-Prinzip", was nichts anderes bedeutet, als das keine Garantie für die ordnungsgemäße Übermittlung besteht.
    Wird auf eine gesicherte Übertragung Wert gelegt, so fällt dies in die Zuständigkeit höherer Protokolle.

    Das Protokoll SMTP

    Der urspüngliche Standard für SMTP - niedergelegt im RFC 821 - stammt aus dem Jahr 1982 und gilt, abgesehen von einigen Erweiterungen, nach wie vor.

    Dieser RFC 821 legte ein Minimum an Schlüsselworten fest, die jede Implementation von SMTP (d. h. die Verkörperung von SMTP in einem Programm) beherrschen muss.

    Dies sind:

    HELO Systemname - Beginn, Name des sendenden Systems
    MAIL FROM: - Übermittlung beginnen
    RCPT TO: - Empfänger des Briefes
    DATA - Beginn des Briefes
    RSET - Anfangsstatus wiederherstellen, Übermittlung abbrechen li>NOOP - nichts tun
    QUIT - SMTP Verbindung beenden
    Beim Verbindungsaufbau meldet sich der lokale MTA mit einer "Begrüßungszeile". Der lokale empfangende MTA wird mit "HELO" angesprochen und als sendender MTA der des Systems www.it-academy.cc angegeben. Der lokale MTA antwortet mit einem Zahlencode, der dem Sender-MTA signalisiert, dass seine geforderte Aktion in Ordnung geht. Die Klarschrift nach dem Zahlencode dient nur der besseren Lesbarkeit für den Menschen (z. B. für den, der Fehler suchen muss).

    Auf "MAIL FROM:" folgt die Adresse des Absenders, und auf "RCPT TO:" die des Empfängers. Auf das Schlüsselwort "DATA" folgt schließlich der ganze Brief, also sowohl die Kopfzeilen, als auch der Text. Der Empfänger-MTA wird solange Text erwarten, bis ihm der Sender-MTA über eine Zeile, die nur einen Punkt enthält, signalisiert, daß der Brief zu Ende ist.

    Nach der letzten Bestätigung des Empfänger-MTAs könnte der Sender den nächsten Brief übermitteln, wiederum beginnend mit "MAIL FROM:". Nach dem Empfang des Briefes kopiert der lokale MTA den Brief in die Postfach-Datei des Empfängers.

    Der RFC 821 legte noch einige weitere Schlüsselworte fest, z. B. "EXPN" für expand, welches eine Unterstützung von Mailing-Listen erlaubt, oder "VRFY" für verify, mittels dessen eine Bestätigung der Empfänger-Adresse gefordert werden kann. Eine ganze Reihe von RFCs haben den Standard für SMTP erweitert. Die erweiterte Version heißt nun offiziell ESMTP (für Extended SMTP). Hinzugekommen sind beispielsweise Schlüsselworte für die Unterstützung von 8bit-Briefen (z. B. solche mit Umlauten), und die Möglichkeit eine maximale Größe für Briefe, die empfangen werden, festzulegen.

    Das Protokoll POP & IMAP

    Auf Arbeitsplatzrechnern, die normalerweise nicht ständig eingeschaltet sind, erfordert E-Mail spezielle Betriebsweisen. Falls der Rechner in ein lokales Netz integriert ist, bietet sich eine Lösung über den Netzwerkserver oder einen speziellen Mail-Server an.

    Es gibt auch die Möglichkeit, direkt vom PC-Kompatiblen oder Macintosh auf eine Unix-Mailbox zuzugreifen. Voraussetzung dafür ist, dass der Arbeitsplatzrechner direkt mit TCP/IP am Ethernet angeschlossen ist oder über eine Modem-Verbindung per PPP-Protokoll angebunden ist. Die Mailer sind lokale Programme am PC oder Mac. Der Vorteil ist, daß man in der PC-Umgebung bleibt, und Dateien direkt aus dem PC-Directory-System versandt werden können. Die Mailbox des Benutzers liegt dabei selbst auf einem Mail-Server (Postfach). Der Zugriff vom PC auf das Mailsystem des Servers wird über den Client/Server-Mechanismus realisiert. Protokolle, die dieses erlaubt, sind POP ('Post Office Protocol') und IMAP ('Internet Message Access Protocol').

    POP, genauer POP 3, ist die bisher noch gebräuchlichste Methode, um E-Mails von einem Provider zu empfangen, wenn der eigene Rechner nicht ständig mit dem Internet verbunden ist. Das Prinzip und der Funktionsumfang von POP sind einfach:

    Die für den Empfänger bestimmten E-Mails landen beim Provider im Spool-Verzeichnis und müssen dort vom Empfänger abgeholt werden.
    Der Provider stellt einen POP-Server zur Verfügung, welcher die Schnittstelle des POP-Clients auf dem Empfänger-Rechner darstellt. Der lokale POP-Client kommuniziert mit dem POP-Server beim Provider. "Über ihn werden die vorhandenen E-Mails angeboten.

    Eine Kommunikation zwischen dem POP-Client und dem POP-Server beim Provider kann schematisch beispielsweise so aussehen:
    Client: Hast Du neue E-Mails für mich?
    Server: Ja, insgesamt fünf Stück!
    Client: Liste mir die Absender auf!
    Server: Meier, Mueller, Huber, Schulze
    Client: Zeige die E-Mails an!
    Server: ((Zeigt E-Mails an))
    Client: ((Speichert E-Mails ab))
    Client: Lösche alle angezeigten E-Mails
    Server: ((Löscht alle angezeigten E-Mails))

    IMAP löst das POP-Verfahren zunehmend ab und wird zum neuen Standard. Der Unterschied liegt unter anderem in der Funktionalität des IMAP-Verfahrens. Das Prinzip ist dem POP-Verfahren jedoch sehr ähnlich.

    Im Gegensatz zu POP3 verbleiben aber alle E-Mails zunächst auf dem IMAP-Server, welcher als zentrale Datenbank fungiert. Gerade für mobile Geräte wie PDAs ist dieses Verfahren geradezu ideal.

    Da sowohl Mail-Body als auch Attachments getrennt geladen werden können, müssen Sie Ihre E-Mails nicht erst herunterladen, um den Absender oder die Betreffzeile zu sehen, sondern können sich diese Informationen schnell ansehen, um dann zu entscheiden, welche E-Mails Sie wirklich lesen möchten.

    So können natürlich E-Mails auf dem IMAP-Server auch ohne vorherigen Download bereits löschen. Wie aus Ihrem Postfach gewohnt, können Sie mit IMAP aber auch Nachrichten oder komplette Ordner als gelesen oder ungelesen markieren.

    Domainname des POP- bzw. IMAP-Servers, d.h. System, auf dem die eigentliche Mailbox liegt.
    Benutzernummer auf diesem System
    Passwort für diese Benutzernummer
    für den Versand: Angabe des SMTP-Mail-Relayhosts

    POP/IMAP dient nur zum Abholen der Post vom Mail-Server. Der Versand von E-Mail vom PC oder Mac aus geschieht ganz normal mit SMTP (Simple Mail Transfer Protocol).

    Das Protokoll HTTP

    HTTP ist ein Protokoll der Applikationsschicht, das alle Möglichkeiten der Übertragung von Hypermedia-Informationen bietet. HTTP ist nicht Hardware- oder Betriebssystemabhängig. Seit 1990 ist dieses Protokoll im Einsatz und wird derzeit meist In der Version 'HTTP/1.0' verwendet.

    Heutige Informationssysteme benötigen weit mehr Funktionen als das einfache Senden und Empfangen von Nachrichten. Die Entwicklung von HTTP/1.0 ist nicht abgeschlossen. Es bietet die Möglichkeit, weitere Funktionalität zu entwickeln. Die Adressierung von Ressourcen erfolgt dabei mittels URls, die zum einen Orte (URL) oder Bezeichner (URN) sein können.
    Diese zeigen gleichzeitig den gewünschten Übertragungsmechanismus an. Nachrichten werden in der gleichen Form übertragen, wie sie auch bei normalem Mail-Transport verwandt werden.
    Dabei kommt oft MIME zum Einsatz. HTTP/1.0 ist auch für den Zugriff auf Server mit anderen Protokollen geeignet. So ist es WWW-Clients möglich, mit Servern und Gateways per SMTP, NNTP, FTP, Gopher und WAIS zu kommunizieren.

    Hauptfunktionen des HTTP:

    Die grundlegende Funktionsweise des HTTP folgt dem alten Frage-Antwort-Spiel. Ein fragendes Programm (WWW-Browser) öffnet eine Verbindung zu einem Programm, welches auf Fragen wartet (WWW-Server) und sendet ihm die Anfrage zu. Die Anfrage enthält, die Fragemethode, die URL, die Protokollversion, Informationen über den Dienst und möglicherweise etwas Inhalt in Form einer Nachricht. Der Server antwortet auf diese Frage mit einer Statusmeldung, auf die eine MIME-artige Nachricht folgt, die Informationen über den Server und eventuell schon das gefragte Dokument enthält.

    Direkt nach Beantwortung der Frage wird die Verbindung wieder abgebaut. So soll erreicht werden, dass die Leitungskapazitäten geschont werden. Derzeit finden HTTP-Verbindungen meist per TCP/IP statt. Das soll aber nicht heißen, dass HTTP nicht auch auf anderen Netzwerkprotokollen aufsetzen kann. Beide Seiten müssen auch dazu in der Lage sein, auf den vorzeitigen Abbruch der Kommunikation durch die andere Seite zu reagieren. Vorzeitiger Abbruch kann durch Aktionen von Benutzern, Programmfehler oder Überschreiten der Antwortzeiten ausgelöst werden. Durch den Abbruch der Verbindung durch eine der beiden Seiten wird der gesamte Vorgang abgebrochen.

    Struktur der HTTP-Botschaften:

    Jede Kommunikation zwischen zwei WWW-Programmen besteht aus HTTP-Botschaften, die in Form von Anfragen und Antworten zwischen Client und Server ausgetauscht werden. Eine HTTP-Botschaft (HTTP-Message) kann entweder ein Simple-Request, eine Simple-Response, ein Full-Request oder eine Full-Response sein. Die beiden zuerst genannten Botschaftstypen gehören zum HTTP/0.9-Standard. Die beiden letzten Typen gehören schon zum HTTP/1.0.

    Allgemeinfelder des Botschaftskopfes:

    Jedes der Felder eines HTTP-Botschaftenkopfes weist die gleiche Struktur auf. Im RFC 822 wurde definiert, daß jedes Feld mit einem Feldnamen und dem Feldinhalt erscheint. Auf den Feldnamen muss unbedingt ein Doppelpunkt folgen. Der Feldname kann alle Zeichen außer dem Doppelpunkt und der Escape-Sequenzen enthalten. Allgemeinfelder enthalten Informationen wie das Datum, die Message-ID, die verwendete MIME-Version und ein 'forwarded'-Feld, das angibt, ob das Dokument eigentlich von einer anderen Adresse stammt.

    Anfragen:

    Bei Anfragen wird zwischen einfachen und komplexen Anfragen unterschieden. Eine einfache Anfrage besteht nur aus einer Zeile, die angibt, welche Information gewünscht wird.
    Ein Beispiel:
    GET http://www.it-academy.cc
    Dabei wird nur die Methode (GET) und die URL des Dokumentes angegeben. Es werden keine weiteren Felder erwartet und vom adressierten Server wird auch nur ein ganz einfacher Antwortkopf zurückgesendet. Es kann aber auch eine komplexere Anfrage erzeugt werden. Dabei muss die Zeile aus dem obigen Beispiel noch die Version des HTT-Protokolls angehängt werden.
    In einem Beispiel würde das folgendermaßen aussehen:
    GET http://www.it-academy.cc HTTP/1.0
    Die Anfügung der HTTP-Version ist also der ganze Unterschied zwischen einer einfachen und einer komplexen HTTP-Anfrage. Der Unterschied zwischen einfacher und komplexer Anfrage wird aus Gründen der Kompatibilität gemacht. Ein Browser, der noch das alte HTTP/0.9 implementiert hat, wird nur eine einfache Anfrage losschicken können. Ein neuer Server muss dann eine Antwort, auch im Format des HTTP/0.9 zurücksenden.

    Felder einer komplexen Anfrage:

    Um die Anfrage näher zu spezifizieren, wurden weitere Felder eingeführt. In den Anfragefeldern stellen z. B. Informationen über den Server und den benutzten Browser.
    Weiterhin kann man dort Informationen über den Gegenstand der Übertragung bekommen. In der folgenden kurzen Übersicht sind alle möglichen Felder einer Anfrage aufgeführt.

    Anfragezeile (Request-Line)
    Informationsanfrage wie oben geschildert. Die zugehörigen Methoden folgen im nächsten Abschnitt.
    Allgemeiner Kopf (General-Header)
    Im allgemeinen Kopf werden allgemeine Informationen über die Nachricht übermittelt.
    Anfragekopf (Request-Header)
    In diesen Feldern kann der Browser weitere Informationen über die Anfrage und über den Browser selbst absetzen. Diese Felder sind optional und müssen nicht erscheinen.
    Gegenstandskopf (Entity-Header)
    In diesem Feld werden Einträge übermittelt, welche den Inhalt der Nachricht näher beschreiben.
    Gegenstand der Nachricht (Entity-Body)
    Vor dem eigentlichen Inhalt muss definitionsgemäß eine Leerzeile stehen. Der Inhalt ist dann in dem Format codiert, das in den Gegenstandsfeldern definiert wurde (meist HTML).
    Fragemethoden:
    Das an erster Stelle in einer Anfragezeile (Request-Line) stehende Wort beschreibt die Methode, die mit der nachfolgenden URL angewendet werden soll. Die Methodennamen müssen dabei immer groß geschrieben werden. Der Entwurf des HTTP-Standards erlaubt leicht eine Erweiterung. Kommen wir nun zur Bedeutung der einzelnen Methoden.
    GET
    Diese Methode gibt an, dass alle Informationen, die mit der nachfolgenden URL beschrieben werden, zum rufenden Client geholt werden sollen. Zeigt die URL auf ein Programm (CGI-Script), dann soll dieses Programm gestartet werden und die produzierten Daten liefern. Handelt es sich bei dem referenzierten Datum um eine Datei, dann soll diese übertragen werden.
    HEAD
    Diese Methode ist identisch zur Methode GET. Die Antworten unterscheiden sich nur darin, dass bei der Methode GET ein komplettes Dokument übertragen wird und bei HEAD nur die Meta-Informationen gesendet werden. Dies ist nützlich, um Links auszuprobieren oder um die Erreichbarkeit von Dokumenten zu testen. Bei Anwendung der Methode HEAD wird der Kopf des referenzierten HTML-Dokuments nach 'link' und 'meta' Elementen durchsucht.
    POST
    Diese Methode wird hauptsächlich für größere Datenmengen verwandt. Man stelle sich vor, ein HTML-Dokument enthält ein komplexes Formular. Per POST wird dem Server angezeigt, daß er auch die Daten im Körper der Botschaft bearbeiten soll. Verwendet, wird es hauptsächlich bei Datenblöcken, die zu einem verarbeitenden Programm übertragen werden. Die wirkliche Funktion, die durch POST auf dem adressierten Rechner angestossen wird, wird durch die URL bestimmt. Meist, sind es CGI-Scripte, die den Inhalt der Nachricht verarbeiten.
    PUT
    Die mit der Methode PUT übertragenen Daten sollen unter der angegeben URL gespeichert werden. Das soll ermöglichen, dass WWW-Seiten auch ohne direkten Zugriff auf den anbietenden Rechner erstellt und angeboten werden können. Wird ein Dokument mit der Methode PUT übertragen, dann wird unter dieser Adresse ein Dokument mit dem übertragenen Inhalt angelegt. War die Aktion erfolgreich, wird die Meldung '200 created' zurückgegeben.
    Existiert unter dieser Adresse schon ein Dokument, dann wird dieses überschrieben. War auch diese Aktion erfolgreich, dann wird nur '200 OK' zurückgemeldet. Der Hauptunterschied zwischen POST und PUT besteht darin, dass bei POST die URL eine Adresse eines Programmes referenziert, das mit den Daten umgehen kann. Bei PUT hingegen wird die URL als neue Adresse des Dokumentes gesehen, das gerade übertragen wurde. Meist jedoch ist die Methode PUT ausgeschaltet, weil Server-Betreiber befürchten, dass die Sicherheit, des Systems dadurch nicht mehr gewährleistet ist.
    DELETE
    Mit dieser Methode kann der Inhalt einer URI gelöscht werden. Diese Methode ist neben der Methode PUT eine der gefährlichsten. Wenn Server nicht richtig konfiguriert wurden, dann kann es mitunter vorkommen, dass alle Welt die Berechtigung zum Löschen von Ressourcen hat.
    LINK
    Mit dieser Methode können eine oder mehrere Verbindungen zwischen verschiedenen Dokumenten erzeugt werden. Es werden dabei keine Dokumente erstellt, sondern nur schon bestehende miteinander verbunden.
    UNLINK
    entfernt Verbindungen zwischen verschieden Ressourcen. Dabei wird nur die Verbindung gelöscht. Die Dokumente existieren trotzdem weiter. Mit diesen Methoden kann man alle möglichen Ressourcen erreichen, welche die verschiedenen Server zur Verfügung stellen. Die folgenden Felder beschreiben nun die Fragen etwas genauer. Es kann zum Beispiel verhindert werden, dass ungewollt umfangreiche Bilder übermittelt werden, wenn dies nicht gewünscht wird.



    Mit folgendem Code, können Sie den Beitrag ganz bequem auf ihrer Homepage verlinken



    Weitere Beiträge aus dem Forum www.cash4online.tk



    Ähnliche Beiträge wie "Netzwerkprotokolle"