209 lines
8.1 KiB
TeX
209 lines
8.1 KiB
TeX
|
\subsection{Wie funktioniert das Internet?}
|
||
|
|
|
||
|
|
Wir stellen uns das Internet als abstrakte Wolke vor, bei dem
|
||
|
|
jeder Nutzer eine Adresse hat, und über diese mit anderen kommunizieren kann.
|
||
|
|
Also Analogie dient der Briefversand, der grundsätzlich ähnlich funktioniert.
|
||
|
|
|
||
|
|
Ein Teilnehmer am Internet zeichnet sich aus durch
|
||
|
|
\begin{itemize}
|
||
|
|
\item Seine konkrete \vocab{IP-Adresse}.
|
||
|
|
\item Den \vocab{Port}, den er verwendet.
|
||
|
|
\item Das Protokoll, über das er kommuniziert (üblicherweise TCP oder UDP)
|
||
|
|
\end{itemize}
|
||
|
|
|
||
|
|
\todoimg{3-1 11}
|
||
|
|
|
||
|
|
|
||
|
|
\subsection{Das \acf{ip}}
|
||
|
|
|
||
|
|
Zur Zeit wird \vocab{IPv4}, d.h.~die vierte Version des \acl{ip}, verwendet.
|
||
|
|
|
||
|
|
\Ac{ip} ist ein \vocab{Netzwerkprotokoll}, d.h.~es dient zur Kommunikation von
|
||
|
|
\begin{itemize}
|
||
|
|
\item Rechner-Router
|
||
|
|
\item Router-Router
|
||
|
|
\end{itemize}
|
||
|
|
im Netzwerk.
|
||
|
|
|
||
|
|
Das \acf{ip} sendet hierzu immer sogenannte \vocab{IP-Datagramme} auf einmal, deren Länge durch $64 \unit{KByte}$ begrenzt ist. In der Praxis kann diese jedoch kleiner sein, und ist durch die Netzwerke beschränkt. Das Ziel des Datagrammes wird durch die IP-Adresse angegeben, die $32$ Bit lang ist.
|
||
|
|
|
||
|
|
\begin{warning}
|
||
|
|
Datagramme können \alert{verloren} gehen sowie \alert{verdoppelt}, \alert{verfälscht} oder in \alert{falscher Reihenfolge} ausgeliefert werden. IP hat hierzu keinerlei Garantien.
|
||
|
|
\end{warning}
|
||
|
|
|
||
|
|
Das neuere Protokoll \vocab{IPv6} funktioniert ähnlich wie IPv4. Es vergrößert den Adressraum auf 128 Bit und ermöglicht es so, jedem Gerät im Internet eine eigene Adresse zuzuweisen.
|
||
|
|
|
||
|
|
\subsection{Das \acf{udp}}
|
||
|
|
|
||
|
|
Das \ac{udp} ist ein minimales \vocab{Transportprotokoll}. Es arbeitet nur in Endgeräten und nutzt den Dienst von IP um mit anderen Zielrechnern zu kommunizieren.
|
||
|
|
\ac{udp} nutzt Ports, um mehrerer Prozesse gleichzeitig zu unterstützen.
|
||
|
|
|
||
|
|
\begin{warning}
|
||
|
|
Da \ac{udp} auf \ac{ip} aufsetzt und keine zusätzlichen Garantien bietet, ist \ac{udp} ebenfalls unzuverlässig.
|
||
|
|
\end{warning}
|
||
|
|
|
||
|
|
Ein \ac{udp} Datagramm besteht aus
|
||
|
|
\begin{itemize}
|
||
|
|
\item Source Port
|
||
|
|
\item Länge der übermittelten Daten
|
||
|
|
\item Destination Port
|
||
|
|
\item Checksum
|
||
|
|
\item übertragene Daten
|
||
|
|
\end{itemize}
|
||
|
|
|
||
|
|
Die Checksumme ist hierbei tatsächlich der einzige (optionale!) Schutz vor Datenkorruption.
|
||
|
|
|
||
|
|
Im Gegensatz zum \ac{tcp} ist \ac{udp} verbindungslos.
|
||
|
|
|
||
|
|
\subsection{Das \acf{tcp}}
|
||
|
|
|
||
|
|
Das \ac{tcp} ist wesentlich aufwendiger als \ac{udp},
|
||
|
|
löst aber die Unzuverlässigkeiten des IP.
|
||
|
|
Auch hier werden source und destination port angegeben, jedoch auch weitaus mehr Metainformationen,
|
||
|
|
die Folgendes sicherstellen:
|
||
|
|
\begin{itemize}
|
||
|
|
\item Verlorene Datagramme werden wiederholt.
|
||
|
|
\item Verdoppelte Datagramme werden verworfen.
|
||
|
|
\item Datagramme werden potenziell umsortiert, um die Reihenfolge sicherzustellen.
|
||
|
|
\item Verfälschte Datagramme werden erkannt (Checksumme) und ggf.~wiederholt.
|
||
|
|
\end{itemize}
|
||
|
|
|
||
|
|
Der größte Unterschied hierbei ist jedoch vor allem, dass \alert{eine feste Verbindung}
|
||
|
|
zwischen Sender und Empfänger aufgebaut werden muss, um \ac{tcp} zu nutzen.
|
||
|
|
Hierzu \vocab[Verbindungsaufbau!initiieren]{initiiert} ein Anwenderprogramm einen Verbindungsaufbau. Akzeptiert die gegenüberliegende Seite diesen Verbindungsaufbau, können Daten in beide Richtungen versendet werden.
|
||
|
|
|
||
|
|
\begin{table}[htpb]
|
||
|
|
\centering
|
||
|
|
\begin{minipage}{0.45\textwidth}
|
||
|
|
\begin{tabular}{l | l}
|
||
|
|
Decimal & Description \\
|
||
|
|
\hline
|
||
|
|
$0$ & Reserved \\
|
||
|
|
$1$ & TCP Multiplexer \\
|
||
|
|
$5$ & Remote Job Entry \\
|
||
|
|
$7$ & Echo \\
|
||
|
|
$9$ & Discard \\
|
||
|
|
$11$ & Active Users \\
|
||
|
|
$13$ & Daytime \\
|
||
|
|
$15$ & Network status program \\
|
||
|
|
$17$ & Quote of the Day \\
|
||
|
|
$19$ & Character Generator \\
|
||
|
|
$20$ & File Transfer Protocol (data) \\
|
||
|
|
$21$ & File Transfer Protocol \\
|
||
|
|
$22$ & ssh (secure shell) \\
|
||
|
|
$23$ & Telnet \\
|
||
|
|
$25$ & SMTP (Mail Transfer) \\
|
||
|
|
$37$ & Time \\
|
||
|
|
$42$ & Host Name Server \\
|
||
|
|
$43$ & Who is \\
|
||
|
|
\end{tabular}
|
||
|
|
\end{minipage}
|
||
|
|
\begin{minipage}{0.45\textwidth}
|
||
|
|
\begin{tabular}{l | l}
|
||
|
|
Decimal & Description \\
|
||
|
|
\hline
|
||
|
|
$53$ & Domain Name Server \\
|
||
|
|
$77$ & Any private RJE service \\
|
||
|
|
$79$ & Finger \\
|
||
|
|
$80$ & World Wide Web HTTP \\
|
||
|
|
$93$ & Device Control Protocol \\
|
||
|
|
$95$ & SUPDUP Protocol \\
|
||
|
|
$101$ & NIC Host Name Server \\
|
||
|
|
$102$ & ISO-TSAP \\
|
||
|
|
$103$ & X.400 Mail Service \\
|
||
|
|
$104$ & X.400 Mail Sending \\
|
||
|
|
$111$ & Sun Microsystems RPC \\
|
||
|
|
$113$ & Authentication Service \\
|
||
|
|
$117$ & UUCP Path Service \\
|
||
|
|
$119$ & USENET News Transfer Protocol \\
|
||
|
|
$129$ & Password Generator Protocol \\
|
||
|
|
$139$ & NETBIOS Session Service \\
|
||
|
|
$160-223$ & Reserved \\
|
||
|
|
\end{tabular}
|
||
|
|
\end{minipage}
|
||
|
|
\caption{Well-Known Ports bei der Verwendung von \ac{tcp}}
|
||
|
|
\label{tab:well-known-tcp-ports}
|
||
|
|
\end{table}
|
||
|
|
|
||
|
|
\begin{table}[htpb]
|
||
|
|
\centering
|
||
|
|
\begin{minipage}{0.45\textwidth}
|
||
|
|
\begin{tabular}{l | l}
|
||
|
|
Decimal & Description \\
|
||
|
|
\hline
|
||
|
|
$0$ & Reserved \\
|
||
|
|
$7$ & Echo \\
|
||
|
|
$9$ & Discard \\
|
||
|
|
$11$ & Active Users \\
|
||
|
|
$13$ & Daytime \\
|
||
|
|
$15$ & Who is up or NETSTAT \\
|
||
|
|
$17$ & Quote of the Day \\
|
||
|
|
$19$ & Character Generator \\
|
||
|
|
$22$ & ssh (secure shell) \\
|
||
|
|
$37$ & Time \\
|
||
|
|
$42$ & Host Name Server \\
|
||
|
|
$43$ & Who is \\
|
||
|
|
$53$ & Domain Name Server \\
|
||
|
|
\end{tabular}
|
||
|
|
\end{minipage}
|
||
|
|
\begin{minipage}{0.45\textwidth}
|
||
|
|
\begin{tabular}{l | l}
|
||
|
|
Decimal & Description \\
|
||
|
|
\hline
|
||
|
|
$67$ & Bootstrap Protocol Server \\
|
||
|
|
$68$ & Bootstrap Protocol Client \\
|
||
|
|
$69$ & Trivial File Transfer \\
|
||
|
|
$80$ & World Wide Web HTTP \\
|
||
|
|
$111$ & Sun Microsystems RPC \\
|
||
|
|
$123$ & Network Time Protocol \\
|
||
|
|
$161$ & SNMP net monitor \\
|
||
|
|
$162$ & SNMP traps \\
|
||
|
|
$512$ & UNIX comsat \\
|
||
|
|
$513$ & UNIX rwho daemon \\
|
||
|
|
$514$ & system log \\
|
||
|
|
$525$ & Time daemon \\
|
||
|
|
\end{tabular}
|
||
|
|
\end{minipage}
|
||
|
|
\caption{Well-Known Ports bei der Verwendung von \ac{udp}}
|
||
|
|
\label{tab:well-known-udp-ports}
|
||
|
|
\end{table}
|
||
|
|
|
||
|
|
|
||
|
|
\autoref{tab:well-known-tcp-ports} und \autoref{tab:well-known-udp-ports} zeigen Ports von \ac{tcp} und \ac{udp}, die standardmäßig für die Server-Prozesse der
|
||
|
|
beschriebenen Dienste vorhergesehen sind.
|
||
|
|
Prinzipiell spricht nichts dagegen, über einen dieser Ports andere Verbindungen zu realisieren,
|
||
|
|
allerdings erfordert das Verwenden eines Ports $< 1024$ in den meisten UNIX-Umgebungen Administrator-Rechte.
|
||
|
|
|
||
|
|
Client-Anwendungen verwenden üblicherweise einen beliebigen Port.
|
||
|
|
Betriebssysteme vergeben hierfür \vocab{Dynamic Ports} (zwischen \code{49152 = 0xC000} und \code{65535 = 0xFFFF}).\footnote{Unter Linux teilweise auch $32768$ bis $61000$. Ursprünglich waren alle Ports $\ge 1024$ für Client-Anwendungen vorgesehen.}
|
||
|
|
|
||
|
|
\todoimg{3-1 21}
|
||
|
|
|
||
|
|
\subsection{\ac{tcp} und \ac{udp} über \ac{ip}}
|
||
|
|
Wir fassen also zusammen, dass \ac{tcp} und \ac{udp} über \ac{ip} kommunizieren.
|
||
|
|
Die (potenziell vielen) Router, die zwischen den beiden Endgeräten sitzen, müssen jedoch
|
||
|
|
nichts von \ac{udp} oder \ac{tcp} wissen, sie kommunizieren nur über \ac{ip}.
|
||
|
|
|
||
|
|
\subsection{Das Format eines \ac{ip}-Datagrammes}
|
||
|
|
Ein \ac{ip}-Datagramm umfasst insbesondere
|
||
|
|
\begin{itemize}
|
||
|
|
\item Quelle und Ziel als IP-Adressen: 32 Bit (IPv4) oder 128 Bit (IPv6)
|
||
|
|
\item Das Protokoll der höheren Schicht (nur als Spezifikation, z.B.~\ac{tcp} oder \ac{udp}).
|
||
|
|
\item Einige Kontrollfunktionen.
|
||
|
|
\end{itemize}
|
||
|
|
|
||
|
|
\subsection{Vergleich von \ac{tcp} und \ac{udp} über \ac{ip}}
|
||
|
|
Bei der Abwägung, welches der beiden Protokolle man verwenden sollte,
|
||
|
|
sollte Folgendes beachtet werden:
|
||
|
|
|
||
|
|
\begin{itemize}
|
||
|
|
\item \ac{tcp} ist zuverlässig, verbindungsorientiert und eignet sich für Byte-Streams. Es entsteht allerdings ein erheblicher Overhead.
|
||
|
|
\item \ac{udp} ist ein minimaler Dienst, der möglichst wenig Overhead erzeugt.
|
||
|
|
\end{itemize}
|
||
|
|
|
||
|
|
\subsection{IPC}
|
||
|
|
Die Netzwerkkommunikation ist insbesondere ein Fall von IPC, die jedoch auch Kommunikation zwischen Prozessen auf verschieden Rechnern ermöglicht.
|
||
|
|
Diese Prozesse können u.U.~auf verschiedenen Betriebssystemen laufen.
|
||
|
|
Netzwerkkommunikation ermöglicht auch IPC auf dem gleichen System, hierzu wird die Loopback-Adresse \code{127.0.0.1} bzw. \code{::1} verwendet.
|
||
|
|
Außerdem stehen \vocab{Unix Domain Sockets} zur Verfügung, die das selbe API verwenden, aber nur für die Kommunikation innerhalb eines Systems verwendet werden.
|