Modul 8: UDP, TCP, SCTP - Prof. Dr. Martin Leischner

Hochschule
Bonn-Rhein-Sieg
Prof. Dr. Martin Leischner
Netzwerksysteme und TK
Modul 8: UDP, TCP, SCTP
08.05.2016 15:24:53
© M. Leischner
8.1
UDP - User Datagram Protocol
8.2
TCP - Transfer Control Protocol
8.3
SCTP – Stream Control Transmission
Protocol
Netze, BCS, 2. Semester
Folie 1
Hochschule
Bonn-Rhein-Sieg
Prof. Dr. Martin Leischner
Netzwerksysteme und TK
End-to-End Protokolle: Einordnung + Aufgabenstellung
Applikationen und
Anwendungsprozesse
Applikation
Applikation
Anwendungsschicht 5-7
VoIP
SS7-Signalisierung
FTP
http
DHCP
POP3
SCTP TCP
Netzwerkschicht 3
UDP
IP
Dienste + QoS der
Netzwerkschicht
Leitungsschicht 2
Ethernet
Bitübertragungsschicht 1
08.05.2016 15:24:53
© M. Leischner
Mapping
Transportschicht 4
netznahe
Protokolle,
SNMP Dienste,
Anwendungen
Anforderungen
der Anwendungen
und Dienste
100Base-T
Netze, BCS, 2. Semester
WLAN
ATM
PPP
SDH
Folie 2
Hochschule
Bonn-Rhein-Sieg
Prof. Dr. Martin Leischner
Netzwerksysteme und TK
Lernziele:
Nach Durcharbeiten dieses
Teilkapitels sollen Sie das
Grundkonzept von UDP darstellen
können.
8.1 Demultiplexdienst
UDP (User
Datagram
Protocol)
08.05.2016 15:24:53
© M. Leischner
Netze, BCS, 2. Semester
Folie 3
Hochschule
Bonn-Rhein-Sieg
Prof. Dr. Martin Leischner
Netzwerksysteme und TK
UDP Demultiplexing (Ports und Sockets)
Anwendung
Anwendung
Anwendung
Socket
(Programmier=
schnittstelle)
Port
(abstraktes
Konzept)
Queues
Demultiplexing
UDP
ankommendes Paket
08.05.2016 15:24:53
© M. Leischner
Netze, BCS, 2. Semester
Folie 4
UDP Multiplexing
geht analog.
Hochschule
Bonn-Rhein-Sieg
Prof. Dr. Martin Leischner
Netzwerksysteme und TK
UDP Header
0
16
31
IP Header
UDP Source Port
UDP Destination Port
UDP Message Length
UDP Checksum
Data
...
Source Port:
Enthält den Port des versendenden Hosts;
optionale Angabe, d.h. wenn angegeben, ist dies der Port, an den
eine evtl. Antwort gehen soll
Destination Port:
Zielport, wohin das Datagramm geschickt wird
Message Length:
Gibt die Gesamtlänge des Datagramms an
Checksum:
Prüfsumme über UDP-Header sowie IP-Pseudoheader
(Protokollnummer+IP-Adressen)
Stellt sicher, dass der richtige Port und der richtige Host erreicht
worden sind.
08.05.2016 15:24:53
© M. Leischner
Netze, BCS, 2. Semester
Folie 5
Hochschule
Bonn-Rhein-Sieg
Prof. Dr. Martin Leischner
Netzwerksysteme und TK
Lernziele:
Nach Durcharbeiten dieses
Teilkapitels sollen Sie
Grundelemente, Grundkonzepte und
grundlegende Funktionen von TCP
darstellen können.
8.2 Streamingdienst
TCP (Transfer
Control Protocol)
08.05.2016 15:24:53
© M. Leischner
Netze, BCS, 2. Semester
Folie 6
Hochschule
Bonn-Rhein-Sieg
Prof. Dr. Martin Leischner
Netzwerksysteme und TK
8.2.1 TCP Problemstellung,
Aufgabe und
Lösungsansätze
08.05.2016 15:24:53
© M. Leischner
Netze, BCS, 2. Semester
Folie 7
Hochschule
Bonn-Rhein-Sieg
Prof. Dr. Martin Leischner
Netzwerksysteme und TK
Problemstellung: Zuverlässige Transportleistung über
unzuverlässige Netzwerkschicht
Eigenschaften der IP-Netzwerkschicht:
Aufteilung der Information in Pakete
Mehrfaches Übertragen von Paketen
Maximale Paketgrößen
Paketverluste bei der Übertragung
IP ist (nur)
paketorientiertes
Best-Effort-Netz
Empfang fehlerhafter Pakete
Umordnung der Paketreihenfolge
Wechselnde Paketübertragungszeiten
Speicherfähigkeit des Netzes
Was soll TCP leisten?
TCP stellt einen zuverlässigen bidirektionalen
Bytestrom zur Verfügung
08.05.2016 15:24:53
© M. Leischner
Netze, BCS, 2. Semester
Für TCP gibt
es viel zu tun
Folie 8
Hochschule
Bonn-Rhein-Sieg
Prof. Dr. Martin Leischner
Netzwerksysteme und TK
Überblick TCP
Grundeigenschaften:
wichtige Folie!
Punkt-zu-Punkt-Verbindung
Streaming-Schnittstelle
Byteorientiert
keine Fragment-/Segmentgrenzen
Zuverlässige, verbindungsorientierte Übertragung
Drei Phasen: Verbindungsaufbau, Nutzdatenübertragung, Verbindungsabbau
Zuverlässiger Verbindungsaufbau, Initialisierung des Empfänger/Sender-Kontexts
( Three-Way-Handshake)
Zuverlässige Nutzdatenübertragung ( Retransmission)
zuverlässiger Verbindungsabbau
Vollduplex-Verbindung
bidirektionaler Datenfluss in derselben Verbindung
Optimale maximale Segmentgröße (512-1500 Bit) beachten
Flusskontrolle und Überlastkontrolle
08.05.2016 15:24:53
© M. Leischner
Netze, BCS, 2. Semester
Folie 9
Hochschule
Bonn-Rhein-Sieg
Prof. Dr. Martin Leischner
Netzwerksysteme und TK
Begriffsklärung: Fluss- und Überlastkontrolle
Ziel der Kontrollmechanismen:
Effiziente Nutzung der Bandbreite
eines verbindungslosen Netzes durch Sender und Empfänger .
Fenster-Flusskontrolle:
Kontrollmechanismen, die auf Fenstergrößen (=Puffergrößen) beruhen.
Meachanismen zur effizienten Nutzung der Bandbreite
= Flusskontrolle !
Receiver
Flow Control
(flow control)
TCP:
advertised
window
(awnd)
= ÜberlastNetwork
kontrolle !
Flow Control
(congestion control)
End-zu-End
Überlastkontrolle
netzassistierte
Überlastkontrolle
TCP: congestion
window (cwnd)
08.05.2016 15:24:53
© M. Leischner
Netze, BCS, 2. Semester
Folie 10
Flow control:
keep sender from
overrunning receiver
Congestion control: keep
sender from
overrunning network
Anzeichen für Überlastsituationen im
Netz:
• Paketverlust (Pufferüberlauf
Router)
• lange Wartezeit (Queues in den
Routern)
• Übertragungswiederholungen
Hochschule
Bonn-Rhein-Sieg
Prof. Dr. Martin Leischner
Netzwerksysteme und TK
8.2.2 Flusskontrolle mit
Sliding-Window
08.05.2016 15:24:53
© M. Leischner
Netze, BCS, 2. Semester
Folie 11
Hochschule
Bonn-Rhein-Sieg
Prof. Dr. Martin Leischner
Netzwerksysteme und TK
Prinzip des Sliding-Window: Zuverlässigkeit + Effizienz
A
B
A
B
A
B
A
B
Sliding Window
(Piggybacking)
unbestätigtes
Senden
Stop-and-Wait
Sliding-Window
(bei TCP)
unzuverlässig
effizient
zuverlässig
ineffizient
zuverlässig
effizient
zuverlässig
effizient
08.05.2016 15:24:53
© M. Leischner
Netze, BCS, 2. Semester
Folie 12
Hochschule
Bonn-Rhein-Sieg
Prof. Dr. Martin Leischner
Netzwerksysteme und TK
Sliding-Window - detaillierter
Sender
Empfänger
Anwendung produziert 2
Segmente
Seg 1
Seg 2
Diese Segmente liegen im
Sendepuffer und im
Sendefenster
--Sendefenster
-----
Was ist der Unterschied zwischen
Sendepuffer und Sendefenster?
Sendepuffer
Was ist die Aufgabe von
Sendepuffer und Sendefenster?
Größe des Sendepuffers: 5
Größe des Sendefensters: 3
Zeit
08.05.2016 15:24:53
© M. Leischner
Netze, BCS, 2. Semester
Folie 13
Hochschule
Bonn-Rhein-Sieg
Prof. Dr. Martin Leischner
Netzwerksysteme und TK
Sliding-Window - detaillierter
Sender
Seg 1
Seg 1
Seg 2
Seg 2
Empfänger
Was passiert jetzt??
Beide Segmente können
gesendet werden
ACK 1
--Sendefenster
Auswirkungen auf den
ACK 2
Sendepuffer und das
Sendefenster?
----Sendepuffer
Zeit
08.05.2016 15:24:53
© M. Leischner
Netze, BCS, 2. Semester
Folie 14
Hochschule
Bonn-Rhein-Sieg
Prof. Dr. Martin Leischner
Netzwerksysteme und TK
Sliding-Window - detaillierter
Sender
Seg 1
Seg 1
Seg 2
Seg 2
Seg 3
Empfänger
Seg 3
Sendefenster
Anwendung produziert zwei
weitere Segmente
Was macht der Sender?
ACK 1
ACK 2
Seg 4
ACK 3
--Sendepuffer
Zeit
08.05.2016 15:24:53
© M. Leischner
Netze, BCS, 2. Semester
Folie 15
Hochschule
Bonn-Rhein-Sieg
Prof. Dr. Martin Leischner
Netzwerksysteme und TK
Sliding-Window - detaillierter
Sender
Empfänger
Anwendung produziert ein
Seg 1
weiteres Segment
Seg 2
Seg 3
Was passiert?
ACK 1
ACK 2
Seg 1
Was wäre, wenn sie zwei
ACK 3
Seg 2
weitere Segmente produziert?
Seg 3
Sendefenster
Seg 4
Seg
--- 5
Sendepuffer
Zeit
08.05.2016 15:24:53
© M. Leischner
Netze, BCS, 2. Semester
Folie 16
Hochschule
Bonn-Rhein-Sieg
Prof. Dr. Martin Leischner
Netzwerksysteme und TK
Sliding-Window - detaillierter
Sender
Empfänger
ACK 1 kommt nun beim Sender
Seg 1
an
Seg 2
Seg 3
Was passiert?
ACK 1
ACK 2
Seg 1
ACK 3
Seg 2
Seg 3
Sendefenster
Seg 4
Seg 5
Sendepuffer
Zeit
08.05.2016 15:24:53
© M. Leischner
Netze, BCS, 2. Semester
Folie 17
Hochschule
Bonn-Rhein-Sieg
Prof. Dr. Martin Leischner
Netzwerksysteme und TK
Sliding-Window - detaillierter
Sender
Empfänger
Schieben des Fensters
Versenden von Segment 4
Seg 1
Seg 2
Seg 3
ACK 1
ACK 2
Seg 2
ACK 3
Seg 3
Seg 4
Seg 4
Sendefenster
Seg 5
ACK 4
--Sendepuffer
Zeit
08.05.2016 15:24:53
© M. Leischner
Netze, BCS, 2. Semester
Folie 18
Hochschule
Bonn-Rhein-Sieg
Prof. Dr. Martin Leischner
Netzwerksysteme und TK
Sliding-Window - detaillierter
Sender
Empfänger
Nun kommt ACK 2
Was passiert?
Seg 1
Seg 2
Seg 3
ACK 1
ACK 2
ACK 3
Seg 2
Seg 4
Seg 3
Seg 4
ACK 4
Sendefenster
Seg 5
--Sendepuffer
Zeit
08.05.2016 15:24:53
© M. Leischner
Netze, BCS, 2. Semester
Folie 19
Hochschule
Bonn-Rhein-Sieg
Prof. Dr. Martin Leischner
Netzwerksysteme und TK
Sliding-Window - detaillierter
Sender
Empfänger
Schieben des Fensters
Versenden von Seg 5
Seg 1
Seg 2
Seg 3
Seg 3
ACK 1
ACK 2
Für Fortgeschrittene:
ACK 3
Was passiert, wenn ACK 4 und
ACK 5 vor ACK 3 kommen?
Seg 4
Seg 4
Seg 5
Sendefenster
Seg 5
Frage an alle:
ACK 4
Wie groß soll das Sendefenster
sein?
ACK 5
---
Wer legt das Sendefenster
Sendepuffer
fest?
Zeit
08.05.2016 15:24:53
© M. Leischner
Netze, BCS, 2. Semester
Folie 20
Hochschule
Bonn-Rhein-Sieg
8.2.3
08.05.2016 15:24:53
© M. Leischner
Prof. Dr. Martin Leischner
Netzwerksysteme und TK
TCP HeaderAufbau
Netze, BCS, 2. Semester
Folie 21
Hochschule
Bonn-Rhein-Sieg
Prof. Dr. Martin Leischner
Netzwerksysteme und TK
TCP-Header
IP-Header
8
TCP-Header
TCP-Data
16
24
Source Port
Destination Port
Sequence Number
Acknowledgement Number
Data
Offset
Reserved
U A P R S F
R C S S Y I
G K H T N N
Urgent Pointer
Options (variable Länge)
Data
Netze, BCS, 2. Semester
Bytes –
nicht
Pakete/Seg
mente !
Window Size („Vorabsenden“)
Checksum
08.05.2016 15:24:53
© M. Leischner
32
Folie 22
Padding
Hochschule
Bonn-Rhein-Sieg
Prof. Dr. Martin Leischner
Netzwerksysteme und TK
Aufbau des TCP-Headers
Source Port:
Destination Port:
16-Bit-Feld für lokalen TCP-User (Applikation)
16-Bit-Feld für remote TCP-User (Applikation)
Sequence number: Position des aktuellen Blocks im laufenden Strom.
Zeigt auf das erste neue Byte.
Acknowledgment Number: Nächste Sequenznummer, die erwartet wird.
Vorhergehende Nummern wurden korrekt empfangen.
Data Offset:
Flags:
08.05.2016 15:24:53
© M. Leischner
Länge des TCP-Headers in 32 Bit Blöcken
URG
Urgent-Pointer-Flag (für Vorrang-Daten)
ACK
Acknowledgement-Flag (Bestätigung)
PSH
Push-Flag (direkte Weiterleitung an Anwendung)
RST
Reset-Flag (Beenden der Verbindung aufgrund eines Fehlers)
SYN
Synchronization-Flag (Synchronisationsvorgang)
FIN
Final-Flag (ordentlicher Verbindungsabbau)
Netze, BCS, 2. Semester
Folie 23
Hochschule
Bonn-Rhein-Sieg
Prof. Dr. Martin Leischner
Netzwerksysteme und TK
Aufbau des TCP-Haeders (Fortsetzung)
Window Size:
die noch verfügbare Puffergröße auf Empfangsseite,
wichtige Info für den Sender, dient der Flusssteuerung
Urgent Pointer:
Zeiger auf Ende von dringlichen Daten
Ckecksum:
Prüfsumme über Header, Daten und einen Pseudoheader
zum Schutz gegen fehlgeleitete Segmente
Options:
Padding:
MSS (Maximum Segment Size) bei Verbindungsaufbau
08.05.2016 15:24:53
© M. Leischner
Fülldaten für 32 Bit-Grenze
Netze, BCS, 2. Semester
Folie 24
Hochschule
Bonn-Rhein-Sieg
Prof. Dr. Martin Leischner
Netzwerksysteme und TK
8.2.4 TCP Verbindungsablauf
(vereinfacht)
08.05.2016 15:24:53
© M. Leischner
Netze, BCS, 2. Semester
Folie 25
Hochschule
Bonn-Rhein-Sieg
Prof. Dr. Martin Leischner
Netzwerksysteme und TK
TCP-Verbindungsablauf (Normalfall, vereinfacht)
Client
ISN=1763
WinSize=512
Server
SYN FIN ACK seq#=1763
ack#=
Win=512
keine Daten
ack#=1764
Win=1536
keine Daten
SYN FIN ACK seq#=1764
ack#=74
Win=512
keine Daten
SYN FIN ACK seq#=1764
ack#=74
Win=512
10 Byte Daten
ack#=1774
Win=1536
3 Byte Daten
ack#=77
Win=512
5 Byte Daten
ack#=1779
Win=1536
keine Daten
ack#=78
Win=512
keine Daten
ack#=1780
Win=1536
keine Daten
SYN FIN ACK
Verbindungsaufbau
Verbindungsphase
SYN FIN ACK
seq#=73
seq#=74
SYN FIN ACK seq#=1774
SYN FIN ACK
Verbindungsabbau
SYN FIN ACK seq#= 1779
SYN FIN ACK
08.05.2016 15:24:53
© M. Leischner
seq#=77
Netze, BCS, 2. Semester
seq#=78
Folie 26
ISN=73
WinSize=1536
Hochschule
Bonn-Rhein-Sieg
Prof. Dr. Martin Leischner
Netzwerksysteme und TK
TCP Verbindungsmanagement (mit blauem Client-Life-Cycle)
CLOSED
starting point
appl:passive open
---
Client-normalZyklus
appl:active open
send:SYN
LISTEN
recv:SYN
send:SYNACK
recv:RST
appl:close
or timeout
---
simultaneous open
--recv:SYN
SYN_RCVD
SYN_SENT
send:SYN-ACK
recv:SYNACK
recv:ACK
send:ACK
---
ESTABLISHED
ED
appl:close
Data transfer state
send:FIN
CLOSE_WAIT
IT
recv:FIN
send:ACK
appl:close
send:FIN
FIN_WAIT1
recv:FIN
send:ACK
CLOSING
simultaneous close
LAST_ACK
recv:ACK
---
recv:ACK
recv:FIN-ACK
recv:ACK
---
send:ACK
---
passive close
recv:FIN
FIN_WAIT2
08.05.2016 15:24:53
© M. Leischner
send:ACK
active close
TIME_WAIT
Netze, BCS, 2. Semester
Folie 27
Hochschule
Bonn-Rhein-Sieg
Prof. Dr. Martin Leischner
Netzwerksysteme und TK
8.2.5 TCP
Überlastkontrolle
08.05.2016 15:24:53
© M. Leischner
Netze, BCS, 2. Semester
Folie 28
Hochschule
Bonn-Rhein-Sieg
Prof. Dr. Martin Leischner
Netzwerksysteme und TK
Phasen der Überlastkontrolle
Paketverlust
Start der TCP-Übertragung
Slow Start (Aufbau eines Gleichgewichts
= Equilibrium))
biff
buff
Daten
Erhalt des Gleichgewichts
Optimale Einstellung des RTOs (Jacobson/Karel Algorithmus)
Maximierung der Auslastung (–> Additive Increase, Überlastfenster (=
spezielle Fenstergröße für Überlastkontrolle) wächst linear)
Reaktion auf Überlastungsanzeichen
Stabilisierung der Situation (–> Multiplicative Decrease, Überlastfenster wird
halbiert)
Sicherstellung einer kontinuierlichen, unterbrechungsfreien Datenflusses
Fairness der Resourcenverteilung
automatisch
durch AIMD (= Additive IncreaseFolie
/ Multiplicative
Decrease)
29
Netze, BCS, 2. Semester
08.05.2016 15:24:53
© M. Leischner
Hochschule
Bonn-Rhein-Sieg
Prof. Dr. Martin Leischner
Netzwerksysteme und TK
Slow Start
Ziel von Slow Start:
Rasches Heranführen der TCP-Verbindung an das Gleichgewicht
Strategie:
Progressives Testen der Belastbarkeit der Strecke Sender-Empfänger (bis in
die Überlast hinein)
Paketverluste (–> Retransmission Time Out) werden als Kennzeichen für eine
Überlastsituation gewertet.
(Dies ist kritisch für mobile TCP –> niedrige Übertragungsrate)
Beruhigung des Netzes nach dem Eintreten einer Überlastsituation (Leeren
der Router-Queues am Engpass)
Einsatz:
Beim Start einer Verbindung
nach Ablauf des Retransmission-Timers
nach langer passiver TCP-Phase
08.05.2016 15:24:53
© M. Leischner
Netze, BCS, 2. Semester
Folie 30
Hochschule
Bonn-Rhein-Sieg
Prof. Dr. Martin Leischner
Netzwerksysteme und TK
TCP Sägezahnverhalten
ssthresh (twnd = target window)
Überlastfenster
Paketverlust+
Timeout
Slowstart
Additive
Increase
Fast Recovery
Fast Retransmit
Paketverlust+
Timeout
Zeit
08.05.2016 15:24:53
© M. Leischner
Netze, BCS, 2. Semester
Folie 31
Hochschule
Bonn-Rhein-Sieg
Prof. Dr. Martin Leischner
Netzwerksysteme und TK
Lernziele:
8.3
08.05.2016 15:24:53
© M. Leischner
Nach Durcharbeiten dieses
Teilkapitels sollen Sie Motivation und
ausgewählte Grundkonzepte von
STCP darstellen können.
Streamingdienst SCTP
(Stream Control
Transmission Protocol)
Netze, BCS, 2. Semester
Folie 32
Hochschule
Bonn-Rhein-Sieg
Prof. Dr. Martin Leischner
Netzwerksysteme und TK
Geschichte, Motivation und Überblick
TCP und UDP klassische Transportprotokolle (späte 60er Jahre)
UDP: unzuverlässiger Paketdienst; geeignet für Multicast und Broadcast
TCP: zuverlässiger, byteorientierter, unicast Streamingdienst
Spezielle Anforderungen beim Transport von Signalisierungsdaten im
Sprachverkehr führte zur Entwicklung des SCTP-Protokolls
Unterstützung eines Nachrichtenkonzepts
Unterstützung von mehreren unabhängigen Nachrichtenströmen
(Problem „Head of Line Blocking“) Multi-Streaming
Unterstützung alternativer Netzwerkpfade Multi-Homing
Überwachung der Netzwerkpfade und Endpunkte
Selektive Bestätigung von übertragenen Daten
Optionale Reihenfolgesicherung
Sicherer Verbindungsaufbau (DoS-Angriffe)
Oktober 2000: Die Signaling Transport (SIGTRAN) Gruppe der Internet
Engineering Task Force (IETF) definiert im RFC 2960 das Stream Control
Transmission Protocol
08.05.2016 15:24:53
© M. Leischner
Netze, BCS, 2. Semester
Folie 33
Hochschule
Bonn-Rhein-Sieg
Prof. Dr. Martin Leischner
Netzwerksysteme und TK
SCTP-Transportarchitektur
Konzept der Assoziation, die mehrere logische Ströme umfasst
Unterstützung von Multihoming und Multistreaming.
logische Ströme in einer
Assoziation
SCTP nutzende Applikation
SCTP-Assoziation
SCTP
Transportschicht
IP-Netzwerkschicht
SCTP
Transportschicht
LQWHUQHW
mehrere IP-Adressen
08.05.2016 15:24:53
© M. Leischner
Netze, BCS, 2. Semester
SCTP nutzende Applikation
Folie 34
IP-Netzwerkschicht
Hochschule
Bonn-Rhein-Sieg
Prof. Dr. Martin Leischner
Netzwerksysteme und TK
Multi-Streaming
aus: Unurkhaan, Esbold: Secure End-to-End Transport over SCTP - A new security extension for SCTP, Dissertation; 2005
Begrenzung von „Head of Line Blocking“ (HoLB):
Übertragung der Nutzdaten erfolgt über unabhängige Kanäle bzw. Streams.
Der Verlust eines Chunks (Pakets) beeinflusst nicht alle anderen Streams.
08.05.2016 15:24:53
© M. Leischner
Netze, BCS, 2. Semester
Folie 35
Hochschule
Bonn-Rhein-Sieg
Prof. Dr. Martin Leischner
Netzwerksysteme und TK
Multi-Homing
Zuordnung von mehrere IP-Adressen zum Endpunkt einer Assoziation (Port
bleibt gleich).
Dadurch sind mehrere Pfade möglich; für jeden Pfad wird ein kompletter
Parametersatz für Fluss- und Überlastkontrolle gehalten.
Ein ausgesuchter Pfad (primärer Pfad) überträgt Daten, die restlichen Pfade
sind redundant. (Zukünftiges Konzept: Concurrent Multipath Transfer, CMT)
SCTP
Assoziation
SCTP
Assoziation
IP-Netzwerkschicht
IP-Netzwerkschicht
,QWHUQHW
primärer Pfad
08.05.2016 15:24:53
© M. Leischner
Netze, BCS, 2. Semester
Folie 36
IP-Adressen