1 / 137

INFO 330 Computer Networking Technology I

INFO 330 Computer Networking Technology I. Chapter 3 The Transport Layer Glenn Booker. Transport Layer. The Transport Layer handles logical communication between processes

wang-summers
Télécharger la présentation

INFO 330 Computer Networking Technology I

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. INFO 330Computer Networking Technology I Chapter 3 The Transport Layer Glenn Booker INFO 330 Chapter 3

  2. Transport Layer The Transport Layer handles logical communication between processes It’s the last layer not used between processes for routing, so it’s the last thing a client process and the first thing a server process sees of a packet By logical communication, we recognize that the means used to get between processes, and the distance covered, are irrelevant INFO 330 Chapter 3

  3. Transport vs Network Notice we didn’t say ‘hosts’ in the previous slide…that’s because The network layer provides logical communication between hosts Mail analogy Let’s assume cousins (processes) want to send letters to each other between their houses (hosts) They use their parents (transport layer) to mail the letters, and sort the mail when it arrives INFO 330 Chapter 3

  4. Transport vs Network The letters travel through the postal system (network layer) to get from house to house The transport layer doesn’t participate in the network layer activities (e.g. most parents don’t work in the mail distribution centers) The transport layer protocols are localized in the hosts Routing isn’t affected by anything the transport layer added to the messages INFO 330 Chapter 3

  5. Transport vs Network Following the analogy, different people might have to pick up and sort the mail; they’re like using different transport layer protocols And the transport layer protocols (parents) are often at the mercy of what services the network layer (postal system) provides Some services can be provided at the transport layer, even if the network layer doesn’t (e.g. reliable data transfer or encryption) INFO 330 Chapter 3

  6. Two Choices Here we choose between TCP and UDP In the transport layer, a packet is a segment In the network layer, a packet is a datagram The network layer is home to the Internet Protocol (IP) IP provides logical communication between hosts IP makes a “best effort” to get segments where they belong – no guarantees of delivery, or delivery sequence, or delivery integrity INFO 330 Chapter 3

  7. IP Each host has an IP address Common purpose of UDP and TCP is extend delivery of IP data to the host’s processes This is called transport-layer multiplexing and demultiplexing Both UDP and TCP also provide error checking That’s it for UDP – data delivery and error checking! INFO 330 Chapter 3

  8. TCP TCP also provides reliable data transfer (not just data delivery) Uses flow control, sequence numbers, acknowledgements, and timers to ensure data is delivered correctly and in order TCP also provides congestion control TCP applications share the available bandwidth (they watched Sesame Street!) UDP takes whatever it can get (greedy little protocol) INFO 330 Chapter 3

  9. Multiplexing & Demultiplexing At the destination host, the transport layer gets segments from the network layer Needs to deliver these segments to the correct process on that host Do so via sockets, which connect processes to the network Each socket has a unique identifier, whose format varies for UDP and TCP INFO 330 Chapter 3

  10. Multiplexing & Demultiplexing Demultiplexing is getting the transport layer segment into the correct socket Hence Multiplexing is taking data from various sockets, applying header info, breaking it into segments, and delivering it to the network layer Multiplexing and demultiplexing are used in any kind of network; not just in the Internet protocols INFO 330 Chapter 3

  11. Multiplexing & Demultiplexing delivering received segments to correct socket gathering data from multiple sockets, enveloping data with header (later used for demultiplexing) = socket = process application P4 application application P1 P2 P3 P1 transport transport transport network network network link link link physical physical physical host 3 Multiplexing at send host: Demultiplexing at rcv host: host 2 host 1 INFO 330 Chapter 3

  12. Mail Analogy Multiplexing is when a parent collects letters from the cousins, and puts them into the mail Demultiplexing is getting the mail, and handing the correct mail to each cousin Here we need unique socket identifiers, and some place in the header for the socket identifier information INFO 330 Chapter 3

  13. Segment Header Hence the segment header starts with the source and destination port numbers Each port number is a 16-bit (2 byte) value (0 to 65,535) Well known port numbers are from 0 to 1023 (210 -1) After the port numbers are other headers, specific to TCP or UDP, then the message INFO 330 Chapter 3

  14. UDP Multiplexing UDP assigns a port number from 1024 to 65,535 to each socket, unless the developer specifies otherwise UDP identifies a socket only by destination IP address and destination port number The port numbers for source and destination are switched (inverted) when a reply is sent So a segment from port 19157 to port 46428 generates a reply from 46428 to 19157 INFO 330 Chapter 3

  15. TCP Multiplexing TCP is messier, of course TCP identifies a socket by four values: Source IP address, source port number, destination IP address, and destination port number Hence if UDP gets two segments with the same destination IP and port number, they’ll both go to the same process TCP tells the segments apart via source IP/port INFO 330 Chapter 3

  16. TCP Multiplexing So if you have two HTTP sessions going to the same web server and page, how can TCP tell them apart? Even though the destination IP and port (80) are the same, and the two sessions (processes) have the same source IP address, they have different source port numbers INFO 330 Chapter 3

  17. Port scanning Apps called port scanners (e.g. nmap) can scan the ports on a computer and see which are open This tell us what apps are running on that host Then target attacks on those apps Another security vulnerability is to leave ports open you aren’t using Could accept TCP connections INFO 330 Chapter 3

  18. Web Servers & TCP Each new client connection often uses a new process and socket to send HTTP requests and get responses But a thread (lightweight process) can be used, so a process can have multiple sockets for each thread INFO 330 Chapter 3

  19. UDP The most minimal transport layer has to do multiplexing and demultiplexing UDP does this and a little error checking and, well, um, that’s about it! UDP was defined in RFC 768 An app that uses UDP almost talks directly to IP Adds only two small data fields to the header, after the requisite source/destination addresses There’s no handshaking; UDP is connectionless INFO 330 Chapter 3

  20. UDP for DNS DNS uses UDP A DNS query is packaged into a segment, and is passed to the network layer The DNS app waits for a response; if it doesn’t get one soon enough (times out), it tries another server or reports no reply Hence the app must allow for the unreliability of UDP, by planning what to do if nothing comes back INFO 330 Chapter 3

  21. UDP Advantages Still UDP is good when: You want the app to have detailed control over what is sent across the network; UDP changes it little No connection establishment delay No connection state data in the end hosts; hence a server can support more UDP clients than TCP Small packet header overhead per segment TCP uses 20 bytes of header data, UDP only 8 bytes INFO 330 Chapter 3

  22. UDP Apps Other than DNS, UDP is also used for Network management (SNMP) Routing (RIP) Multimedia and telephony (various protocols) Remote file server (NFS) The lack of congestion control in UDP can be a problem when lost of large UDP messages are being sent – can crowd out TCP apps INFO 330 Chapter 3

  23. UDP Header The UDP header has four two-byte fields in two lines (8 B total) Source port number; Destination port number Length; Checksum Length is the total length of the segment, including headers, in bytes The checksum is used by the receiving app to see if errors occurred INFO 330 Chapter 3

  24. Checksum Noise in the transmission lines can lose bits of data or rearrange them in transit Checksums are a common method to detect errors (RFC 1071) To create a checksum: Find the sum of the binary digits of the message The checksum is the 1s (ones) complement of the sum If message is uncorrupted, sum of message plus checksum is all ones 1111111111111… INFO 330 Chapter 3

  25. 1s Complement? The 1s complement is a mirror image of a binary number – change all the zeros to ones, and ones to zeros So the 1s complement of 00101110101 is 11010001010 UDP does error checking because not all lower layer protocols do error checking This provides end-to-end error checking, since it’s more efficient than every step along the way INFO 330 Chapter 3

  26. UDP That’s it for UDP! The port addresses, the message length, and a checksum to see if it got there intact Now see what happens when we want reliable data transfer INFO 330 Chapter 3

  27. Reliable Data Transfer Distinguish between the service model, and how it’s really implemented Service model: From the app perspective, it just wants a reliable transport layer to connect sending and receiving processes Service implementation: In reality, the transport layer has to use an unreliable network layer (IP), so transport has to make up for the unreliability below it INFO 330 Chapter 3

  28. Reliable Data Transfer The sending process will give the transport layer a message rdt_send (rdt = reliable data transfer) The transport protocol will convert to udt_send (udt = unreliable data transfer; Fig 3.8 has typo) and give to the network layer At the receiving end, the protocol gets rdt_rcv from the network layer, The protocol will convert to deliver_data and give it to the receiving application process INFO 330 Chapter 3

  29. Reliable Data Transfer network layer App sees this service model But our transport protocol has to do this INFO 330 Chapter 3

  30. Reliable Data Transfer Here we’ll refer to the data as packets, rather than distinguish segments, etc. Also consider that we’ll pretend we only have to send data one direction (unidirectional data transfer) Bidirectional data transfer is what really occurs, but the sending and receiving sides get switched Time to build a reliable data transfer protocol, one piece at a time INFO 330 Chapter 3

  31. Reliable Data Transfer v1.0 For the simplest case, called rdt1.0, assume the network is completely reliable Finite state machines (FSMs) for the sender and receiver each have one state – waiting for a call The sending side (rdt_send) makes a packet (make_pkt) and sends it (udt_send) The receiving side (rdt_rcv) extracts data from the packet (extract), and delivers it to the receiving app (deliver_data) INFO 330 Chapter 3

  32. Reliable Data Transfer v1.0 Here a packet is the only unit of data No feedback to sender is needed to confirm receipt of data, and no control over transmission rate is needed INFO 330 Chapter 3

  33. Reliable Data Transfer v2.0 Now allow bit errors in transmission But all packets are received, in the correct order Need acknowledgements to know when a packet was correct (OK, 10-4) versus when it wasn’t (please repeat); called positive and negative acknowledgements, respectively These types of messages are typical for any Automatic Repeat reQuest (ARQ) protocol INFO 330 Chapter 3

  34. Reliable Data Transfer v2.0 So allowing for bit errors requires three capabilities Error detection to know if a bit error occurred Receiver feedback, both positive (ACK) and negative (NAK) acknowledgements Retransmission of incorrect packets INFO 330 Chapter 3

  35. Reliable Data Transfer v2.0 INFO 330 Chapter 3

  36. Reliable Data Transfer v2.0 Sending FSM (cont.) The left state waits for a packet from the sending app, makes a packet with a checksum (make_pkt) Then the left state sends the packet (udt_send) It moves to the other state (waiting for ACK/NAK) If it gets a NAK response (errors detected), then it resends the packet (udt_send) until it gets it right If it gets an ACK response (no errors), then it goes back to the other state to wait for the next packet from the app INFO 330 Chapter 3

  37. Reliable Data Transfer v2.0 Notice this model does nothing until it gets the NAK/ACK, so it’s a stop-and-wait protocol Receiving FSM The receiving side uses the checksum to see if the packet was corrupted If it was (&& corrupt) send a NAK response If it wasn’t (&& notcorrupt), extract and deliver the data, and send an ACK response But what if the NAK/ACK is corrupted? INFO 330 Chapter 3

  38. Reliable Data Transfer v2.0 Three possible ways to handle NAK/ACK errors Add another type of response to have the NAK/ACK repeated; but what if that response got corrupted? Leads to long string of messages… Add checksum data to the NAK/ACK, and data to recover from the error Resend the packet if the NAK/ACK is garbled; but introduces possible duplicate packets INFO 330 Chapter 3

  39. Reliable Data Transfer v2.1 TCP and most reliable protocols add a sequence number to the data from the sender Since we can’t lose packets yet, a one-bit number is adequate to tell if this is a new packet or a repeat of the previous one This gives our new model rdt version 2.1 INFO 330 Chapter 3

  40. Reliable Data Transfer v2.1 sender INFO 330 Chapter 3

  41. Reliable Data Transfer v2.1 Now the number of states are doubled, since we have sequence numbers 0 or 1 So in make_pkt(1, data, checksum)the 1 is the sequence number Sequence number alternates 010101 if everything works; if a packet is corrupted, the same sequence number is expected two or more times Start at ‘Wait for call 0’ state; when get packet, send it to network with sequence 0 Then wait for ACK or NAK with sequence 0 INFO 330 Chapter 3

  42. Reliable Data Transfer v2.1 If the packet was corrupt, or got a NAK, resend that packet (upper right loop) Otherwise wait for call with sequence 1 from app When call 1 is received, make and send the packet with sequence 1 (desired outcome) Then wait for a NAK/ACK with sequence 1 If corrupt or got a NAK, resend (lower left loop) Otherwise go to waiting for a sequence 0 call from the app Repeat cycle INFO 330 Chapter 3

  43. Reliable Data Transfer v2.1 receiver INFO 330 Chapter 3

  44. Reliable Data Transfer v2.1 The receiver side doubles in # of states When waiting for seq 0 state If the packet has sequence 0 and isn’t corrupt, extract and deliver the data, and send an ACK; go to wait for seq 1 state If the packet was corrupt, reply with a NAK If the packet has sequence 1 and was not corrupt (it’s out of order) send an ACK and keep waiting for a seq 0 packet Mirror the above for starting from ‘wait for seq 1’ state INFO 330 Chapter 3

  45. Reliable Data Transfer v2.2 Could achieve the same effect without a NAK (for corrupt packet) if we only ACK the last correctly received packet Two ACKs for the same packet (duplicate ACKs) means the packet after the second ACK wasn’t received correctly The NAK-free protocol is called rdt2.2 INFO 330 Chapter 3

  46. Reliable Data Transfer v2.2 INFO 330 Chapter 3

  47. Reliable Data Transfer v2.2 Again, the send and receive FSMs are symmetric for sequence 0 and 1 Sender must now check the sequence number of the packet being ACK’d (see isACK message) The receiver must include the sequence number in the make_pkt message FSM on page 211 also has oncethru variable to help avoid duplicate ACKs INFO 330 Chapter 3

  48. Reliable Data Transfer v3.0 Now account for the possibility of lost packets Need to detect packet loss, and decide what to do about it The latter is easy with the tools we have (ACK, checksum, sequence #, and retransmission), but need a new detection mechanism Many possible loss detection approaches Focus on making the sender responsible for it INFO 330 Chapter 3

  49. Reliable Data Transfer v3.0 Sender thinks a packet lost when packet doesn’t get to receiver, or the ACK gets lost Can’t wait for worst case transmission time, so pick a reasonable time before error recovery is started Could result in duplicate packets if it was still on the way; but rdt2.2 can handle that For the sender, retransmission is ultimate solution – whether packet or ACK was lost INFO 330 Chapter 3

  50. Reliable Data Transfer v3.0 Knowing when to retransmit needs a countdown timer Count time from sending a packet to still not getting an ACK If time is exceeded, retransmit that packet Works the same if packet is lost or ACK is lost Since packet sequence numbers alternate 0-1-0-1-etc., is called an alternate-bit protocol INFO 330 Chapter 3

More Related