UDP, TCP & DNS Rough Cut

Transkript

1 UDP, TCP & DNS Rough Cut Peter Sturm Universität Trier Einordnung in OSI-Modell Internet-Protokolle: SFTP, SSH, SMTP, DNS, NTP, HTTP,... Ebene 4-7 RPC-Protokolle PVM, MPI, Corba,... UDP TCP Ebene 3 IP / ICMP / ARP / RARP / (Routingprotokolle) Ebene 1-2 IEEE 802.X X.25 Peter Sturm, Universität Trier 1

2 IP-Protokoll (IPv4) 20 Byte Header Version Header Length Type of service v hl tos Total Length identification f Fragment offset(13) Time to live protocol Header checksum source address destination address Maximale Größe eines IP-Datagramm 64 Kbyte inkl. Header Ebene 3: Oben und Unten Internet-Protokolle: SFTP, SSH, SMTP, DNS, NTP, HTTP,... Ebene 4-7 RPC-Protokolle PVM, MPI, Corba,... UDP TCP Ebene 3 IP / ICMP / ARP / RARP / (Routingprotokolle) Ebene 1-2 IEEE 802.X X.25 Peter Sturm, Universität Trier 2

3 ARP Address Resolution Protocol Verbindet die Teile der Ebene 3 Zielnetz erreicht, Zielrechner noch nicht Letzte Meile Rechner a:7b:00:21:98:ff Ethernet 4f:3b:11:29:8:f Rechner 2 5f:29:12:31:f2: Rechner 3 Peter Sturm, Universität Trier 3

4 Rechner 1 Routing a:7b:00:21:98:ff Ethernet 4f:3b:11:29:8:f Rechner 2 5f:29:12:31:f2: Rechner 3 Rechner 1 Routing a:7b:00:21:98:ff != => Default Router Ethernet f:3b:11:29:8:f Rechner 2 5f:29:12:31:f2: Rechner 3 Peter Sturm, Universität Trier 4

5 Rechner 1 ARP a:7b:00:21:98:ff Ethernet 4f:3b:11:29:8:f Rechner 2 5f:29:12:31:f2: Rechner 3 Rechner 1 ARP a:7b:00:21:98:ff == J Ethernet 4f:3b:11:29:8:f Rechner 2 5f:29:12:31:f2: Rechner 3 Peter Sturm, Universität Trier 5

6 Rechner 1 ARP a:7b:00:21:98:ff Ethernet Who has ? 4f:3b:11:29:8:f Rechner 2 5f:29:12:31:f2: Rechner 3 Rechner 1 ARP a:7b:00:21:98:ff 5f:29:12:31:f2:9 has ? Ethernet 4f:3b:11:29:8:f Rechner 2 5f:29:12:31:f2: Rechner 3 Peter Sturm, Universität Trier 6

7 Rechner 1 ARP a:7b:00:21:98:ff Ethernet 4f:3b:11:29:8:f Rechner 2 5f:29:12:31:f2: Rechner 3 UDP Ebene 4-7 UDP TCP Ebene 3 IP / ICMP / ARP / RARP / (Routingprotokolle) Ebene 1-2 Peter Sturm, Universität Trier 7

8 UDP UDP = User Datagram Protocol Best-Effort Nachrichtenverluste Keine Ordnung Keine Flußkontrolle UDP-Multicast Angabe einer Multicast-IP-Adresse als Empfänger Meist von Sysadmins ausgeschaltet UDP Source port UDP length Destination port UDP checksum 8 Byte Header Maximales Datagramm 64 Kbyte inkl. Header Peter Sturm, Universität Trier 8

9 TCP Ebene 4-7 UDP TCP Ebene 3 IP / ICMP / ARP / RARP / (Routingprotokolle) Ebene 1-2 Reliable Streams Peter Sturm, Universität Trier 9

10 Features Reliable Behandlung transienter Fehler Keine Nachrichtenverluste Stream Reihenfolge-erhaltend First-In First-Out (FIFO) Sendegranulat geht verloren Voll-Duplex Arbeitspferd des Internets Quittungsbetrieb Sender Empfänger Timeout setzen Timeout ACK Peter Sturm, Universität Trier 10

11 Gründe Reaktion auf Nachrichtenverluste Erkennen von Netzpartitionen Erkennen von Ausfällen Empfänger Kommunikationssystem Flußkontrolle langsame Empfänger Quittungsbetrieb Timeout setzen Sender Empfänger Sender Empfänger Receive + Timeout setzen Timeout NACK Timeout ACK Positive Quittung (Implizite Wiederholung) Negative Quittung (Explizite Anforderung) Peter Sturm, Universität Trier 11

12 Speicherfähigkeit des Mediums Speicherfähigkeit des Mediums Abstand zur Erde (Juni 2016): 20.1 Milliarden Kilometer Roundtrip-Zeit: 37h, 16min, 34s Raumsonde Voyager 2 Annahme 100 Mbit pro Sekunde: 1.6 Tbyte Speicherkapazität Peter Sturm, Universität Trier 12

13 Kontinuierliches Senden NACK 2,3 ACK 1-5 Sender Empfänger Nachrichten nummerieren Selektive Wiederholung Go-Back-N Probleme Komplexe Protokolle Hoher Pufferbedarf Schlechtes Hochlastverhalten Sender paßt sich dem Tempo des Empfängers nicht an Flußkontrolle Ziele Tempo von Sender und Empfänger anpassen Speicherkapazität des Mediums optimal nutzen Begrenzt viele unquittierte Pakete Peter Sturm, Universität Trier 13

14 Sliding-Window-Protokolle Fenster unquittierter Nachrichten Sender kann Empfänger um maximal n Nachrichten vorauslaufen Innerhalb des Fensters Quittungsbetrieb analog kontinuierlichem Senden Bei n austehenden Quittungen Blockade des Senders Sliding-Window-Protokolle Fenster n= Nicht Gesendet Quittiert Fenster n=4 ACK Nicht Gesendet Quittiert Fenster n= Nicht Gesendet Quittiert Peter Sturm, Universität Trier 14

15 Sliding-Window-Protokolle Fenster n= Nicht Gesendet Quittiert Fenster n= Fenster n= TCP Header Source Port (16 Bit) Destination Port (16 Bit) Sequence Number (32 Bit) Acknowledgement Number (32 Bit) Header Length Flags Window Size (16 Bit) TCP Checksum (16 Bit) Urgent Pointer (16 Bit) Optionen (falls vorhanden) URG ACK PSH RST SYN FIN Peter Sturm, Universität Trier 15

16 Portnummer Sender/Empfänger Bestandteile Sequence Number Laufende Nummer des ersten Datenbytes in der Nachricht Vorschlag bei Aufbau der Verbindung Acknowledgement Number Laufende Number des Datenbytes, das Sender als nächstes erwartet Header Length Länge in Einheiten von 4 Byte (max. 60 Byte Header) Window Size Aktuelle Fenstergröße Checksum Prüfsumme über TCP-Header und Daten Urgent Pointer Zeigt auf das letzte dringende Datenbyte im Paket URG Urgent Pointer im Header ist gültig ACK Acknowledgement Number ist gültig PSH Daten schnellstmöglich an Anwendung weitergeben RST Verbindungen zurücksetzen Die Flags SYN Sequenznummer beim Verbindungsaufbau synchronisieren FIN Sender beendet Datenübertragung Peter Sturm, Universität Trier 16

17 All Flags on RFC 1025 [J.B. Postel, 1987, TCP and IP Bake Off ] calls a segment with the maximum combination of allowable flag bits turned on at once (SYN, URG, PSH, FIN, and 1 byte of data) a Kamikaze packet. It s also known as a nastygram, Christmas tree packet, and lamp test segment Es gab TCP/IP-Protokollstacks, die bei einem Kamikaze Packet einfach abgestürzt sind und das Betriebssystem gleich mitgerissen haben. Beispiel für eine TCP-Verbindung 11:42: IP localhost > localhost.50244: S : ( 0) win <mss 16344,nop,wscale 3,nop,nop,timesta mp ,sackOK,eol> 11:42: IP localhost > localhost.50484: S : ( 0) ack win <mss 16344,nop,wscale 3,nop,nop,timesta mp ,sackOK,eo l> 11:42: IP localhost > localhost.50244:. ack 1 win <nop,nop,timestam p > 11:42: IP localhost > localhost.50484:. ack 1 win <nop,nop,timestam p > 11:42: IP localhost > localhost.50244: P 1:101(100) ack 1 win <nop,nop,timestam p > 11:42: IP localhost > localhost.50484:. ack 101 win <nop,nop,timestam p > 11:42: IP localhost > localhost.50244: P 301:401(100) ack 1 win <nop,nop,timestam p > 11:42: IP localhost > localhost.50484:. ack 401 win <nop,nop,timestam p > 11:42: IP localhost > localhost.50244: F 401:401(0) ack 1 win <nop,nop,timestam p > 11:42: IP localhost > localhost.50484:. ack 402 win <nop,nop,timestam p > 11:42: IP localhost > localhost.50244:. ack 1 win <nop,nop,timestam p > Peter Sturm, Universität Trier 17

18 Kind Options 0 End of option (kind = 0) 1 No operation (kind = 1) Padding auf Vielfaches von 4 Byte 2 len 4 MSS Maximum segment size (kind = 2) Window scale factor (kind = 3) 3 len 3 sc Timestamp (kind = 4) 4 len 10 Timestamp Value Timestamp Reply Optionen in einer TCP-Verbindung 11:42: IP localhost > localhost.50244: S : ( 0) win <mss 16344,nop,wscale 3,nop,nop,timesta mp ,sackOK,eol> 11:42: IP localhost > localhost.50484: S : ( 0) ack win <mss 16344,nop,wscale 3,nop,nop,timesta mp ,sackOK,eo l> 11:42: IP localhost > localhost.50244:. ack 1 win <nop,nop,timestam p > 11:42: IP localhost > localhost.50484:. ack 1 win <nop,nop,timestam p > 11:42: IP localhost > localhost.50244: P 1:101(100) ack 1 win <nop,nop,timestam p > 11:42: IP localhost > localhost.50484:. ack 101 win <nop,nop,timestam p > 11:42: IP localhost > localhost.50244: P 301:401(100) ack 1 win <nop,nop,timestam p > 11:42: IP localhost > localhost.50484:. ack 401 win <nop,nop,timestam p > 11:42: IP localhost > localhost.50244: F 401:401(0) ack 1 win <nop,nop,timestam p > 11:42: IP localhost > localhost.50484:. ack 402 win <nop,nop,timestam p > 11:42: IP localhost > localhost.50244:. ack 1 win <nop,nop,timestam p > Peter Sturm, Universität Trier 18

19 Verbindungsaufbau Client Initial Sequence Number SYN, ISN Client (active open) SYN, ISN ACK ISN Client + 1 (passive open) ACK, ISN Way Handshake Timeout beim Verbindungsaufbau 12:35: IP > : S : ( 0) win <mss 1460,nop,wscale 3,nop,nop,timestam p ,sackOK,eol> 12:35: IP > : S : ( 0) win <mss 1460,nop,wscale 3,nop,nop,timestam p ,sackOK,eol> 12:35: IP > : S : ( 0) win <mss 1460,nop,wscale 3,nop,nop,timestam p ,sackOK,eol> 12:35: IP > : S : ( 0) win <mss 1460,sackOK,eol> 12:35: IP > : S : ( 0) win <mss 1460,sackOK,eol> 12:35: IP > : S : ( 0) win <mss 1460,sackOK,eol> 12:35: IP > : S : ( 0) win <mss 1460,sackOK,eol> 12:35: IP > : S : ( 0) win <mss 1460,sackOK,eol> 12:35: IP > : S : ( 0) win <mss 1460,sackOK,eol> 12:35: IP > : S : ( 0) win <mss 1460,sackOK,eol> 12:36: IP > : S : ( 0) win <mss 1460,sackOK,eol> Peter Sturm, Universität Trier 19

20 Verbindungsabbau Client FIN Half Close ACK FIN ACK TCP API Peter Sturm, Universität Trier 20

21 Symmetrisch? Geht nicht! Erst verbinden, dann senden! Asymmetrisch Passiver Part Wartet auf Verbindungswünsche Aktiver Part Initiiert eine Verbindung Client Peter Sturm, Universität Trier 21

22 Client Ansatz Passive Seite (): 1. Socket erzeugen 2. Socket an Portnummer binden 3. Initialisierung der Verbindungsannahme (listen) 4. Auf Verbindungswunsch warten (accept) Aktive Seite (Client): 1. Socket erzeugen 2. ermitteln (IP-Adresse, Portnummer) 3. Verbindung aufbauen (connect) Client Client Client Apparat 2 Peter Sturm, Universität Trier 22

23 Listen, Accept und Connect -Seite Initialisierung des passiven Wartens: retcode = listen ( int socket, int queue_length ) Socket wird passiv Auf Verbindungswünsche warten: retcode = accept ( int socket, sockaddr_in *client, int *client_len ) Client-Seite Verbindungswunsch herstellen: retcode = connect ( int socket, sockaddr_in *server, int server_len ) Ablauf eines Verbindungsaufbaus (1) Sockets erzeugen Client cs as cs = socket(...,sock_stream,0); as = socket(...,sock_stream,0); Peter Sturm, Universität Trier 23

24 Ablauf eines Verbindungsaufbaus (2) -Adresse (Portnummer) festlegen Client cs as cs = socket(...,sock_stream,0); as = socket(...,sock_stream,0); bind(as,server_port); Ablauf eines Verbindungsaufbaus (3) -Socket wird passiv Client cs as cs = socket(...,sock_stream,0); as = socket(...,sock_stream,0); bind(as,server_port); listen(as,4); Peter Sturm, Universität Trier 24

25 Ablauf eines Verbindungsaufbaus (4) Verbindungswunsch des Clients Client cs as cs = socket(...,sock_stream,0); as = socket(...,sock_stream,0); bind(as,server_port); listen(as,4); connect(cs,server(host,port)); Ablauf eines Verbindungsaufbaus (5) akzeptiert Verbindungswunsch s Client cs as cs = socket(...,sock_stream,0); as = socket(...,sock_stream,0); bind(as,server_port); listen(as,4); connect(cs,server(host,port)); s = accept(as,...); Peter Sturm, Universität Trier 25

26 Ablauf eines Verbindungsaufbaus (6) Datenübertragung ns Client cs as cs = socket(...,sock_stream,0); as = socket(...,sock_stream,0); bind(as,server_port); listen(as,4); connect(cs,server(host,port)); ns = accept(ss,...); write(cs,...); write(cs,...); read(ns,...); Programmierung Peter Sturm, Universität Trier 26

27 (C) Peter Sturm, Universität Trier 27

28 Client (C) (C#) Peter Sturm, Universität Trier 28

29 Client (C#) DNS Peter Sturm, Universität Trier 29

30 Mapping Names to IP Addresses Name Service Client Name Service Domain Name Service (DNS) Hierarchischer Namensraum: balvenie.uni-trier.de Transformation Domain Name IP-Adresse (Lookup) IP-Adresse Domain Name (Reverse Lookup) UNIX-API gethostbyname() gethostbyaddr() IETF-Standard RFC 1034 (Konzepte) RFC 1035 (Implementierungsdetails) Gängige Implementierung Berkeley Internet Name Domain (BIND) Peter Sturm, Universität Trier 30

31 Organisation der DNS- Hierarchische Struktur Ausfallsicherheit Primary Name Secondaries Administrative Einheiten Zone named named named named named named named named Domain Name Service Root TLD TLD TLD Domain Domain Domain Domain Domain Domain Peter Sturm, Universität Trier 31

32 Root s Root- Record Peter Sturm, Universität Trier 32

33 DNS Hierarchy Root TLD DE TLD COM Your Provider uni-trier.de google.com Your host Recursive Querying maps.google.com? Root maps.google.com? ! TLD DE TLD COM ! ! maps.google.com? Your Provider google.com maps.google.com? ! Your host Example: Query for maps.google.com Peter Sturm, Universität Trier 33

34 Iterative Querying Root maps.google.com? TLD DE.COM maps.google.com? TLD COM Iterative Queries Your Provider google.com maps.google.com? google.com maps.google.com? Recursive Query Your host Example: Query for maps.google.com Einträge Ca. 20 verschiedene Eintragsformen Viele nicht mehr gültig Gängige Record -Einträge A: IPv4-Adresse AAAA: IPv6-Adresse NS: NS- CNAME: Kanonischer Name PTR: Pointer-Record HINFO: Host-Information MX: Mail Exchange Record Pointer-Query Gegeben IP-Adresse; Gesucht: Kanonischer Name in-addr.arpa Domain Peter Sturm, Universität Trier 34

35 Resource Record (RR) DNS Records Name Value Type TTL Record Types Hostname IPv4 Address A TTL Hostname IPv6 Address AAAA TTL Domain Authoritative Name NS TTL Alias Name Canonical Name CNAME TTL Domain Name of Mail MX TTL Resource Record (RR) Example DNS Records Name Value Type TTL Record Types www-neu.uni-trier.de A 7200 www-neu.uni-trier.de 2001:0db8:85a3:3d AAAA 7200 uni-trier.de dns.uni-trier.de NS www-neu.uni-trier.de CNAME 7200 uni-trier.de rzmail.uni-trier.de MX 7200 Peter Sturm, Universität Trier 35

36 DNS Messages Transaction ID Flags Numberof questions Numberof answer records Numberof authority records Numberof additional records Questions Answer records Authority records Additional records DNS Query Peter Sturm, Universität Trier 36

37 DNS Response Non-authoritative reply Authoritative nameservers Peter Sturm, Universität Trier 37