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
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
ARP Address Resolution Protocol Verbindet die Teile der Ebene 3 Zielnetz erreicht, Zielrechner noch nicht Letzte Meile Rechner 1 192.168.42.15 3a:7b:00:21:98:ff Ethernet 4f:3b:11:29:8:f1 192.168.42.16 Rechner 2 5f:29:12:31:f2:9 192.168.42.17 Rechner 3 Peter Sturm, Universität Trier 3
Rechner 1 Routing 192.168.42.15 3a:7b:00:21:98:ff Ethernet 4f:3b:11:29:8:f1 192.168.42.16 Rechner 2 5f:29:12:31:f2:9 192.168.42.17 Rechner 3 Rechner 1 Routing 192.168.42.15 3a:7b:00:21:98:ff 192.168.42!= 192.168.44 => Default Router Ethernet 192.168.44.9 4f:3b:11:29:8:f1 192.168.42.16 Rechner 2 5f:29:12:31:f2:9 192.168.42.17 Rechner 3 Peter Sturm, Universität Trier 4
Rechner 1 ARP 192.168.42.15 3a:7b:00:21:98:ff Ethernet 4f:3b:11:29:8:f1 192.168.42.16 Rechner 2 5f:29:12:31:f2:9 192.168.42.17 Rechner 3 Rechner 1 ARP 192.168.42.15 3a:7b:00:21:98:ff 192.168.42 == 192.168.42 J Ethernet 4f:3b:11:29:8:f1 192.168.42.16 Rechner 2 5f:29:12:31:f2:9 192.168.42.17 Rechner 3 Peter Sturm, Universität Trier 5
Rechner 1 ARP 192.168.42.15 3a:7b:00:21:98:ff Ethernet Who has 192.168.42.17? 4f:3b:11:29:8:f1 192.168.42.16 Rechner 2 5f:29:12:31:f2:9 192.168.42.17 Rechner 3 Rechner 1 ARP 192.168.42.15 3a:7b:00:21:98:ff 5f:29:12:31:f2:9 has 192.168.42.17? Ethernet 4f:3b:11:29:8:f1 192.168.42.16 Rechner 2 5f:29:12:31:f2:9 192.168.42.17 Rechner 3 Peter Sturm, Universität Trier 6
Rechner 1 ARP 192.168.42.15 3a:7b:00:21:98:ff Ethernet 4f:3b:11:29:8:f1 192.168.42.16 Rechner 2 5f:29:12:31:f2:9 192.168.42.17 Rechner 3 UDP Ebene 4-7 UDP TCP Ebene 3 IP / ICMP / ARP / RARP / (Routingprotokolle) Ebene 1-2 Peter Sturm, Universität Trier 7
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
TCP Ebene 4-7 UDP TCP Ebene 3 IP / ICMP / ARP / RARP / (Routingprotokolle) Ebene 1-2 Reliable Streams Peter Sturm, Universität Trier 9
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
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
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
Kontinuierliches Senden NACK 2,3 ACK 1-5 Sender 1 2 3 4 5 6 2 3 7 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
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=4 11 10 9 8 7 6 5 4 3 2 1 Nicht Gesendet Quittiert Fenster n=4 ACK 5 11 10 9 8 7 6 5 4 3 2 1 Nicht Gesendet Quittiert Fenster n=4 11 10 9 8 7 6 5 4 3 2 1 Nicht Gesendet Quittiert Peter Sturm, Universität Trier 14
Sliding-Window-Protokolle Fenster n=4 11 10 9 8 7 6 5 4 3 2 1 Nicht Gesendet Quittiert Fenster n=4 11 10 9 8 7 6 5 4 3 2 1 Fenster n=4 11 10 9 8 7 6 5 4 3 2 1 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
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
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:03.483508 IP localhost.50484 > localhost.50244: S 4033456674:40334566 74( 0) win 65535 <mss 16344,nop,wscale 3,nop,nop,timesta mp 387601565 0,sackOK,eol> 11:42:03.483560 IP localhost.50244 > localhost.50484: S 2074141348:20741413 48( 0) ack 4033456675 win 65535 <mss 16344,nop,wscale 3,nop,nop,timesta mp 387601565 387601565,sackOK,eo l> 11:42:03.483573 IP localhost.50484 > localhost.50244:. ack 1 win 65535 <nop,nop,timestam p 387601565 387601565> 11:42:03.483585 IP localhost.50244 > localhost.50484:. ack 1 win 65535 <nop,nop,timestam p 387601565 387601565> 11:42:03.483621 IP localhost.50484 > localhost.50244: P 1:101(100) ack 1 win 65535 <nop,nop,timestam p 387601565 387601565> 11:42:03.483636 IP localhost.50244 > localhost.50484:. ack 101 win 65535 <nop,nop,timestam p 387601565 387601565> 11:42:06.484445 IP localhost.50484 > localhost.50244: P 301:401(100) ack 1 win 65535 <nop,nop,timestam p 387601595 387601585> 11:42:06.484537 IP localhost.50244 > localhost.50484:. ack 401 win 65535 <nop,nop,timestam p 387601595 387601595> 11:42:07.484721 IP localhost.50484 > localhost.50244: F 401:401(0) ack 1 win 65535 <nop,nop,timestam p 387601605 387601595> 11:42:07.484813 IP localhost.50244 > localhost.50484:. ack 402 win 65535 <nop,nop,timestam p 387601605 387601605> 11:42:07.484838 IP localhost.50484 > localhost.50244:. ack 1 win 65535 <nop,nop,timestam p 387601605 387601605> Peter Sturm, Universität Trier 17
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:03.483508 IP localhost.50484 > localhost.50244: S 4033456674:40334566 74( 0) win 65535 <mss 16344,nop,wscale 3,nop,nop,timesta mp 387601565 0,sackOK,eol> 11:42:03.483560 IP localhost.50244 > localhost.50484: S 2074141348:20741413 48( 0) ack 4033456675 win 65535 <mss 16344,nop,wscale 3,nop,nop,timesta mp 387601565 387601565,sackOK,eo l> 11:42:03.483573 IP localhost.50484 > localhost.50244:. ack 1 win 65535 <nop,nop,timestam p 387601565 387601565> 11:42:03.483585 IP localhost.50244 > localhost.50484:. ack 1 win 65535 <nop,nop,timestam p 387601565 387601565> 11:42:03.483621 IP localhost.50484 > localhost.50244: P 1:101(100) ack 1 win 65535 <nop,nop,timestam p 387601565 387601565> 11:42:03.483636 IP localhost.50244 > localhost.50484:. ack 101 win 65535 <nop,nop,timestam p 387601565 387601565> 11:42:06.484445 IP localhost.50484 > localhost.50244: P 301:401(100) ack 1 win 65535 <nop,nop,timestam p 387601595 387601585> 11:42:06.484537 IP localhost.50244 > localhost.50484:. ack 401 win 65535 <nop,nop,timestam p 387601595 387601595> 11:42:07.484721 IP localhost.50484 > localhost.50244: F 401:401(0) ack 1 win 65535 <nop,nop,timestam p 387601605 387601595> 11:42:07.484813 IP localhost.50244 > localhost.50484:. ack 402 win 65535 <nop,nop,timestam p 387601605 387601605> 11:42:07.484838 IP localhost.50484 > localhost.50244:. ack 1 win 65535 <nop,nop,timestam p 387601605 387601605> Peter Sturm, Universität Trier 18
Verbindungsaufbau Client Initial Sequence Number SYN, ISN Client (active open) SYN, ISN ACK ISN Client + 1 (passive open) ACK, ISN + 1 3 Way Handshake Timeout beim Verbindungsaufbau 12:35:02.643496 IP 136.199.51.192.50802 > 136.199.51.194.4242: S 3852088826:3852088826( 0) win 65535 <mss 1460,nop,wscale 3,nop,nop,timestam p 387633313 0,sackOK,eol> 12:35:03.614692 IP 136.199.51.192.50802 > 136.199.51.194.4242: S 3852088826:3852088826( 0) win 65535 <mss 1460,nop,wscale 3,nop,nop,timestam p 387633322 0,sackOK,eol> 12:35:04.616383 IP 136.199.51.192.50802 > 136.199.51.194.4242: S 3852088826:3852088826( 0) win 65535 <mss 1460,nop,wscale 3,nop,nop,timestam p 387633332 0,sackOK,eol> 12:35:05.617975 IP 136.199.51.192.50802 > 136.199.51.194.4242: S 3852088826:3852088826( 0) win 65535 <mss 1460,sackOK,eol> 12:35:06.619513 IP 136.199.51.192.50802 > 136.199.51.194.4242: S 3852088826:3852088826( 0) win 65535 <mss 1460,sackOK,eol> 12:35:07.621131 IP 136.199.51.192.50802 > 136.199.51.194.4242: S 3852088826:3852088826( 0) win 65535 <mss 1460,sackOK,eol> 12:35:09.624411 IP 136.199.51.192.50802 > 136.199.51.194.4242: S 3852088826:3852088826( 0) win 65535 <mss 1460,sackOK,eol> 12:35:13.630349 IP 136.199.51.192.50802 > 136.199.51.194.4242: S 3852088826:3852088826( 0) win 65535 <mss 1460,sackOK,eol> 12:35:21.643850 IP 136.199.51.192.50802 > 136.199.51.194.4242: S 3852088826:3852088826( 0) win 65535 <mss 1460,sackOK,eol> 12:35:37.668238 IP 136.199.51.192.50802 > 136.199.51.194.4242: S 3852088826:3852088826( 0) win 65535 <mss 1460,sackOK,eol> 12:36:09.714995 IP 136.199.51.192.50802 > 136.199.51.194.4242: S 3852088826:3852088826( 0) win 65535 <mss 1460,sackOK,eol> Peter Sturm, Universität Trier 19
Verbindungsabbau Client FIN Half Close ACK FIN ACK TCP API Peter Sturm, Universität Trier 20
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
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
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
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
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
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
(C) Peter Sturm, Universität Trier 27
Client (C) (C#) Peter Sturm, Universität Trier 28
Client (C#) DNS Peter Sturm, Universität Trier 29
Mapping Names to IP Addresses Name Service Client 136.199.51.201 Name Service 136.199.54.116 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
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
Root s Root- Record Peter Sturm, Universität Trier 32
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? 209.85.148.103! TLD DE TLD COM 209.85.148.103! 209.85.148.103! maps.google.com? Your Provider google.com maps.google.com? 209.85.148.103! Your host Example: Query for maps.google.com Peter Sturm, Universität Trier 33
Iterative Querying Root maps.google.com? TLD DE.COM maps.google.com? TLD COM Iterative Queries Your Provider google.com maps.google.com? 209.85.149.102 google.com maps.google.com? 209.85.149.102 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
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 136.199.199.105 A 7200 www-neu.uni-trier.de 2001:0db8:85a3:3d AAAA 7200 uni-trier.de dns.uni-trier.de NS 7200 www.uni-trier.de www-neu.uni-trier.de CNAME 7200 uni-trier.de rzmail.uni-trier.de MX 7200 Peter Sturm, Universität Trier 35
DNS Messages Transaction ID 16 16 Flags 16 16 Numberof questions Numberof answer records 16 16 Numberof authority records Numberof additional records Questions Answer records Authority records Additional records DNS Query Peter Sturm, Universität Trier 36
DNS Response Non-authoritative reply Authoritative nameservers Peter Sturm, Universität Trier 37