Transportskiktets uppgifter Transportskiktet Sidorna 280-301, 326-330 i boken Transportskiktet kopplar samman tillämpningar Nätskiktet förmedlar meddelanden från maskin till maskin Transportskiktet lägger till en noggrannare adress inom maskinen Transportskiktet erbjuder tjänster för tillämpningar Tillförlitlig/otillförlitlig överföring Meddelandeförmedling (datagram) eller bytestream (virtuell kontakt) Transportskiktet förverkligas med olika alternativa protokoll TCP erbjuder tillämpningen en tillförlitlig bytestream UDP erbjuder tillämpningen en otillförlitlig datagramförmedling UDP UDP User Datagram Protocol Standarden RFC-768 Paketets syntax Source port Length Data Destination port UDP checksum Port är ett 16-bitigt nummer som syftar på en tillämpning Kontrollsumman räknas över både pakethuvud och data Inte nödvändig UDP-meddelandet kapslas i ett IP-meddelande: IP header UDP header UDP data UDP erbjuder ett otillförlitligt datagram-orienterat transportskiktsprotokoll Viktigaste tilläggstjänsten på IP är portadresser Lätt, inget tillstånd, ingen förbindelse, enkel att förverkliga, snabb (ingen återsändning) UDP-tillämpningar: DNS, Radius, NTP, SNMP, RTP (VoIP) UDP-kapning (DNS) DNS-sökning, Ethernet-ram 23 riku@mole $ dig a tapas.nixu.fi @194.197.118.20 ;; got answer: ;; QUESTIONS: ;; tapas.nixu.fi, type = A, class = IN ;; ANSWERS: tapas.nixu.fi. 3600 A 194.197.118.24 ;; AUTHORITY RECORDS: nixu.fi. 3600 NS ns2.tele.fi. nixu.fi. 3600 NS ns.nixu.fi. nixu.fi. 3600 NS ns.tele.fi. ;; ADDITIONAL RECORDS: ns2.tele.fi. 35619 A 193.210.19.190 ns.nixu.fi. 3600 A 193.209.237.29 ns.tele.fi. 555991 A 193.210.19.19 ns.tele.fi. 555991 A 193.210.18.18 ;; Total query time: 88 msec ;; FROM: mole.nixu.fi to SERVER: 194.197.118.20 ;; MSG SIZE sent: 31 rcvd: 175 24 riku@mole $ ETHER: Packet 1 arrived at 11:19:24.80 ETHER: Packet size = 73 bytes
DNS-sökning, IP-pakethuvud DNS-sökning, UDP-pakethuvud IP: Version = 4 IP: Header length = 20 bytes IP: Type of service = 0x00 IP: xxx.... = 0 (precedence) IP:...0... = normal delay IP:... 0... = normal throughput IP:....0.. = normal reliability IP: Total length = 59 bytes IP: Identification = 35734 IP: Fragment offset = 0 bytes IP: Time to live = 255 seconds/hops IP: Protocol = 17 (UDP) IP: Header checksum = 7e65 IP: Source address = 194.197.118.22 IP: Destination address = 194.197.118.20 IP: No options UDP: Source port = 38325 UDP: Destination port = 53 (DNS) UDP: Length = 39 UDP: Checksum = E34A DNS-sökning, pakethuvud och data DNS-svar, pakethuvud 0: 0800 2074 f12c 0000 3b80 0e93 0800 4500.. t.,..;...e. 16: 003b 8b96 4000 ff11 7e65 c2c5 7616 c2c5.;..@...~e..v... 32: 7614 95b5 0035 0027 e34a 000a 0100 0001 v...5.'.j... 48: 0000 0000 0000 0574 6170 6173 046e 6978...tapas.nix 64: 7502 6669 0000 0100 0100 u.fi... Härifrån framåt visas bara väsentliga fält i pakethuvudet ETHER: Packet size = 217 bytes IP: Total length = 203 bytes IP: Protocol = 17 (UDP) IP: Header checksum = 8ed6 IP: Source address = 194.197.118.20 IP: Destination address = 194.197.118.22 UDP: Source port = 53 UDP: Destination port = 38325 UDP: Length = 183 UDP: Checksum = AD48 DNS-svarets pakethuvud och data TCP 0: 0000 3b80 0e93 0800 2074 f12c 0800 4500..;... t.,..e. 16: 00cb 7a95 4000 ff11 8ed6 c2c5 7614 c2c5..z.@...v... 32: 7616 0035 95b5 00b7 ad48 000a 8580 0001 v..5...h... 48: 0001 0003 0004 0574 6170 6173 046e 6978...tapas.nix 64: 7502 6669 0000 0100 01c0 0c00 0100 0100 u.fi... --- some reply data deleted --- 208: 087b db00 04c1 d212 124f.{... Transmission Control Protocol Standarden RFC-793 Erbjuder som tjänst virtualförbindelse och tillförlitlig bytestream Tillämpningens bytestream delas in i mindre block som förmedlas som IP-meddelanden Egenskaper Kontrollsumma, tidsutlösning, flödeskontroll vid stockning Håller ordning på blocken, slänger duplikat TCP används av de flesta tillämpningarna: SMTP, HTTP (WWW), NNTP (News),...
TCP-pakethuvud TCP-pakethuvud Hdrlen Source port number Reserv. TCP checksum Sequence number Acknowledgment number Flags Options (if any) Data (if any) Destination port number Window size Urgent pointer Portarna representerar sändande och mottagande tillämpning Sekvensnumret anger vilken byte (ordningsnummer) i flödet den första data-byten är Bekräftelsenumret anger ordningsnumret för följande förväntade byte Flaggor (bitar) URG meddelandets urgent pointer anger data som bör läsas direkt före övrig data i buffern ACK meddelar att bekräftelsenumret anger mängden mottagen data PSH anger att ny data inte följer omedelbart efter detta meddelande, så datat kan skickas vidare RST nollställer förbindelserna SYN betyder synkronisering i samband med öppnandet av förbindelsen FIN stänger förbindelsen TCP-pakethuvud TCP dataflöde Fönsterstorlek anger hur många byte mottagaren är villig att ta emot, d.v.s. hur många byte sändaren kan skicka i väntan på bekräftelse Används i flödeskontroll Urgent pointer pekar på sista byten av brådskande data Används t.ex. om användaren ger ett interrupt-kommando under en telnet-session Optioner används bl.a. för att ta reda på vad som är största tillåtna segmentstorlek eller för att ta i bruk sändningsfönster Mottagaren skickar bekräftelsepaket som anger upp till vilken byte (sekvensnummer) data har mottagits Om ett paket försvinner, orsakar tidsutlösning (timeout) en omsändning waiting for ack Client packet gets lost retransmission ACK Server TCP dataflöde Uppkoppling av TCP-förbindelse Glidande fönster hjälper utnyttja kapaciteten bättre Fönstrets storlek beror på inställningar, stockningskontroll, mängden minne o.s.v. Känt som three-way handshake Client Server waiting for ack Client packet 1 packet 2 packet 3 ACK 1 & 2 ACK 3 Server active open SYN SYN + ACK ACK passive open
active close Client FIN ACK FIN ACK Nerkoppling av TCP-förbindelse Server passive close Nerkopplingen kan startas av vilkendera parten som helst I allmänhet stängs tillämpningsskiktets session först Notera att en TCP-förbindelse i själva verket är två samtidiga simplexförbindelser TCP:s brister Sändfönstrets storlek I grundversionen av standarden är maximistorleken 64 kbyte Max kapacitet = max fönster storlek / round trip time Felhantering TCP antar att tappade paket beror på stockning i nätet Internet antas bestå av förbindelser av hög kvalitet Stockningskontroll (behandlas på Datornät -kursen) förverkligas genom att minska sändfönstret, vilket minskar trafiken Nuförtiden tappas paket också p.g.a. störningar i radiotrafiken Rätt lösning skulle här vara omsändning En kapad SMTP-session 1. SYN klient->server (Ethernet-pakethuvud) 24 riku@mole $ telnet jalopeno 25 Trying 194.197.118.20... Connected to jalopeno. Escape character is '^]'. 220-jalopeno.nixu.fi ESMTP Sendmail 8.6.12/8.6.12 ready at Sat, 5 Oct 1996 11:24:29 +0300 220 ESMTP spoken here QUIT 221 jalopeno.nixu.fi closing connection Connection closed by foreign host. 25 riku@mole $ ETHER: Packet 1 arrived at 10:58:0.62 ETHER: Packet size = 60 bytes 1. SYN klient->server (IP-pakethuvud) 1. SYN klient->server (TCPpakethuvud) IP: Version = 4 IP: Header length = 20 bytes IP: Type of service = 0x00 IP: xxx.... = 0 (precedence) IP:...0... = normal delay IP:... 0... = normal throughput IP:....0.. = normal reliability IP: Total length = 44 bytes IP: Identification = 63629 IP: Fragment offset = 0 bytes IP: Time to live = 255 seconds/hops IP: Header checksum = 1188 IP: No options TCP: Sequence number = 760886272 TCP: Acknowledgement number = 0 TCP: Data offset = 24 bytes TCP: Flags = 0x02 TCP:..0.... = No urgent pointer TCP:...0... = No acknowledgement TCP:... 0... = No push TCP:....0.. = No reset TCP:.....1. = Syn TCP:......0 = No Fin TCP: Window = 8760 TCP: Checksum = 0x17a1 TCP: Urgent pointer = 0 TCP: Options: (4 bytes) TCP: - Maximum segment size = 1460 bytes
1. SYN klient->server (SMTP-data) Härifrån framåt visas endast relevanta delar av pakethuvuden 2. SYN+ACK server->klient TCP: Sequence number = 2371738143 TCP: Acknowledgement number = 760886273 TCP: Flags = 0x12 (ACK, SYN) TCP: Options: (4 bytes) TCP: - Maximum segment size = 1460 bytes 3. ACK klient->server 4. Data server->klient TCP: Sequence number = 760886273 TCP: Acknowledgement number = 2371738144 TCP: Flags = 0x10 (ACK) TCP: No options TCP: Sequence number = 2371738144 TCP: Acknowledgement number = 760886273 TCP: Flags = 0x18 (ACK, PSH) SMTP: "220-jalopeno.nixu.fi ESMTP Sendmail 8.6.12/8.6.12 ready" 5. Bekräftelse klient->server 6. Data klient->server IP: No options TCP: Sequence number = 760886273 TCP: Acknowledgement number = 2371738258 TCP: Flags = 0x10 (ACK) TCP: Sequence number = 760886273 TCP: Acknowledgement number = 2371738258 TCP: Flags = 0x18 (ACK, PSH) SMTP: "QUIT\r\n"
7. Bekräftelse server->klient (innehåller data) 8. Servern börjar koppla ner TCP: Sequence number = 2371738258 TCP: Acknowledgement number = 760886279 TCP: Flags = 0x18 (ACK, PSH) SMTP: "221 jalopeno.nixu.fi closing connection\r\n" TCP: Sequence number = 2371738299 TCP: Acknowledgement number = 760886279 TCP: Data offset = 20 bytes TCP: Flags = 0x11 (ACK, FIN) 9. Klienten bekräftar tidigare data och nerkopplingsramen 10. Klienten kopplar även ner TCP: Sequence number = 760886279 TCP: Acknowledgement number = 2371738300 TCP: Flags = 0x10 (ACK) TCP: Sequence number = 760886279 TCP: Acknowledgement number = 2371738300 TCP: Flags = 0x11 (ACK, FIN) 11. Servern bekräftar nerkopplingen TCP: Sequence number = 2371738300 TCP: Acknowledgement number = 760886280 TCP: Flags = 0x10 (ACK) Automatic Repeat Request
ARQ Automatic repeat request är en allmän benämning för ett antal tekniker, som bl.a. TCP utnyttjar ARQ-metoder kan utnyttjas på olika nivåer och lämpligt alternativ kan väljas enligt behov Den metoden TCP använder är alltså inte det ända alternativet Planeraren väljer lösning enligt situationen Tillförlitlighet med hjälp av omsändning Hur förverkliga tillförlitlig transmission över ett otillförlitligt skikt? End-to-end T.ex. TCP Länk för länk T.ex. X.25, HDLC En lösning: ARQ ARQ är ett abstrakt koncept eller en princip, inte ett protokoll ARQ-tekniker utnyttjas i många protokoll Gemensamt för dessa tekniker är att bortkommen data ersätts med omsändning Basic ARQ ARQ och sekvensnummer Data (SDU) kapslas i paket (PDU), med pakethuvud och kontrollsumma Kallas även informationsram För signalering finns kontrollramar (control frame), som inte innehåller data från högre skikt Dessutom mekanism för tidsutlösning (timeout) Sender 1. A packet is sent 3. A packet is re-sent after a timeout Packets in transit 2. A packet is lost Receiver Vad händer om ramen mottas och bekräftas efter att tidsutlösningen skett hos sändaren? 4. A simple acknowledgment is sent Sändare och mottagare tappar lätt synkroniseringen Ett problem som alla protokoll måste beakta Synkroniseringen kan upprätthållas med att lägga till että sekvensnummer i varje ram För en enkel stop-and-wait ARQ räcker i teorin ett enbits sekvensnummer Stop-and-wait betyder att bara en ram åt gången är på väg En sekvensbit räcker inte om det finns risk för att nätet duplicerar ramar Stop-and-wait är i allmänhet inte speciellt effektiv Med större sekvensnummer kan flere ramar vara på väg samtidigt ARQ:n kontrollramar Tre grundmeddelanden som tillåter en mängd olika ARQ-implementationer Alla implementationer utnyttjar inte alla meddelanden T.ex. TCP utnyttjar bara ACK ACK, acknowledgment, bekräftelse, positivt svar NAK, negative acknowledgment, negativt svar ENQ, enquiry, förfrågan Stop-and-Wait ARQ och tappade ramar Bara en informationsram skickas åt gången Regel: endast informationsramar bekräftas, kontrollramar bekräftas inte När en ram tappats Skickar sändaren ramen på nytt efter tidsutlösningen (ingen ACK) eller Svarar sändaren på ENQ-meddelandet med den senast skickade ramen On sändaren inte får en bekräftelse, skickas ett ENQmeddelande Mottagaren skickar senaste ACK-meddelandet Nu är sändaren medveten om mottagarens tillstånd och informationsöverföringen är åter synkroniserad
Go-Back-N ARQ... Go-Back-N ARQ Tillräcklig nummerrymd för sekvensnumren och glidande fönster Mottagaren bekräftar bara ramar som kommit i rätt ordning Om en informationsram tappas, omsänds denna ram och alla följande ramar Sändaren noterar att en ram tappats med tidsutlösning, eller Mottagaren skickar ett NAK-meddelande när det kommer en ram som inte är i rätt sekvens Mottagaren behöver en buffert på en ram Sändarens buffert måste vara lika stor som sändfönstret (alla ramar som sänts men inte ännu bekräftats) Om en ACK-kontrollram tappas, kan den ersättas av en senare ACK Go-Back-N ARQ är effektivare än stop-and-wait ARQ Fönstret hjälper hålla transmissionskanalen fylld med data Latens försämrar stop-and-wait ARQ:s effekt märkbart TCP påminner om Go-Back-N ARQ TCP använder inte NAK-meddelanden TCP:s sekvensnummer anger överförda byte, inte ramar Selective Repeat ARQ Sammanfattning Mottagaren kan också skicka NAK-meddelanden för saknade ramar. Endast dessa ramar omsänds. Mottagaren måste ja tillräckligt buffertminne Effektivare är Go-Back-N ARQ on felsannolikheten är stor Transportskiktet behövs för att koppla samman tillämpningar Nätskiktet förmedlar meddelanden från maskin till maskin En tillämpning per maskin år inte en bra abstraktion Arkitekturen kunde byggas upp på andra sätt TCP och IP reflekterar planerarnas världsbild: det finns maskiner och i maskinerna tillämpningar Temat går utanför kursen, men teknologier som MPLS och HIP indikerar att det finns alternativa världsbilder