1
play

1 Chapter 3 outline Multiplexing/demultiplexing Multiplexing at - PDF document

Chapter 3: Transport Layer Our goals: Transport Layer understand learn about transport principles behind layer protocols in the transport layer Internet: services: UDP: connectionless multiplexing/ transport


  1. Chapter 3: Transport Layer Our goals: Transport Layer  understand  learn about transport principles behind layer protocols in the transport layer Internet: services: UDP: connectionless  multiplexing/  transport demultiplexing TCP: connection-  reliable data  oriented transport transfer TCP congestion control  flow control  congestion control  1 2 Transport services and protocols Chapter 3 outline  3.1 Transport-layer applicatio 3.5 Connection-oriented provide logical   n services transport communication between app transport: TCP network network data link processes running on data link physical logical end-end transport  3.2 Multiplexing and network physical segment structure data link  different hosts physical demultiplexing reliable data transfer network  transport protocols run in end  data link physical network flow control systems   3.3 Connectionless data link physical connection management  send side: breaks app  transport: UDP network data link 3.6 Principles of messages into segments,  physical passes to network layer  3.4 Principles of congestion control applicatio rcv side: reassembles  n reliable data transfer 3.7 TCP congestion transport  segments into messages, network data link control passes to app layer physical more than one transport  protocol available to apps Internet: TCP and UDP 3  4 Internet transport-layer protocols Transport vs. network layer  network layer: reliable, in-order Household analogy:  applicatio n logical delivery (TCP) transport sending letters network network communication data link congestion control data link  physical logical end-end transport processes = people network physical  between hosts data link flow control physical  app messages = letters  network connection setup  transport layer: data link  in envelopes physical network data link unreliable, unordered logical  physical hosts = houses  delivery: UDP network communication transport protocol = data link  physical between processes no-frills extension of sorting and collecting  “best-effort” IP applicatio mail within house relies on, enhances, n  transport services not available:  network network layer network-layer protocol  data link physical delay guarantees services = postal service  bandwidth guarantees  5 6 1

  2. Chapter 3 outline Multiplexing/demultiplexing Multiplexing at send host: Demultiplexing at rcv host:  3.1 Transport-layer 3.5 Connection-oriented gathering data from multiple  delivering received segments services sockets, enveloping data with transport: TCP to correct socket header (later used for  3.2 Multiplexing and segment structure  demultiplexing) demultiplexing reliable data transfer  = socket = process flow control   3.3 Connectionless connection management P4 application P1 P2  application P3 P1 application transport: UDP 3.6 Principles of  transport transport transport  3.4 Principles of congestion control network network network reliable data transfer 3.7 TCP congestion  link control link link physical physical physical host 3 host 1 host 2 7 8 Connectionless demultiplexing How demultiplexing works host receives IP datagrams   Create sockets with port When host receives  each datagram has 32 bits  numbers: UDP segment: source IP address, source port # dest port # destination IP address checks destination port sin1.sin_port = 1234;  each datagram carries 1 number in segment  bind(socket1, &sin1, …); transport-layer segment other header fields directs UDP segment to sin2.sin_port = 1235;  each segment has  socket with that port source, destination port bind(socket2, &sin2, …); number number  UDP socket identified by IP datagrams with application  host uses IP addresses & port  two-tuple: data numbers to direct segment to different source IP appropriate socket (message) addresses and/or source ( dest IP address, dest port number) port numbers directed to same socket TCP/UDP segment format 9 10 Connectionless demux (cont) Connection-oriented demux sin.sin_port = 6428; bind(sock, &sin, …);  TCP socket Server host may support  many simultaneous TCP identified by 4-tuple: P1 P2 P1 sockets: P3 source IP address  each socket identified by  source port number  its own 4-tuple dest IP address Web servers have SP: 6428 SP: 6428   DP: 9157 DP: 5775 different sockets for dest port number  each connecting client  recv host uses all SP: 9157 SP: 5775 non-persistent HTTP will DP: 6428 DP: 6428  client Client four values to direct server have different socket for IP: A IP:B IP: C segment to each request appropriate socket SP provides “return address” (returned by recvfrom ) 11 12 2

  3. Connection-oriented demux: Connection-oriented demux (cont) Threaded Web Server P1 P1 P1 P4 P5 P6 P2 P3 P1 P4 P2 P3 SP: 5775 SP: 5775 DP: 80 DP: 80 S-IP: B S-IP: B D-IP:C D-IP:C SP: 9157 SP: 9157 SP: 9157 SP: 9157 client DP: 80 DP: 80 Client DP: 80 DP: 80 client Client server server IP: A S-IP: A S-IP: B IP:B IP: A S-IP: A S-IP: B IP:B IP: C IP: C D-IP:C D-IP:C D-IP:C D-IP:C 13 14 Chapter 3 outline UDP: User Datagram Protocol [RFC 768]  3.1 Transport-layer “no frills,” “bare bones”  3.5 Connection-oriented  Internet transport protocol Why is there a UDP? services transport: TCP “best effort” service, UDP  no connection   3.2 Multiplexing and segments may be: segment structure  establishment (which lost  demultiplexing reliable data transfer  can add delay) delivered out of order  flow control   3.3 Connectionless to app simple: no connection  connection management  connectionless: state at sender, receiver  transport: UDP 3.6 Principles of  no handshaking small segment header    3.4 Principles of between UDP sender, congestion control no congestion control: receiver  reliable data transfer 3.7 TCP congestion  UDP can blast away as each UDP segment  control fast as desired handled independently of others 15 16 UDP checksum UDP: more often used for Goal: detect “errors” (e.g., flipped bits) in transmitted  32 bits streaming multimedia segment apps source port # dest port # Length, in Sender: loss tolerant bytes of UDP checksum length Receiver:  segment, treat segment rate sensitive  compute checksum of   including contents as sequence received segment  other UDP uses header of 16-bit integers check if computed checksum  DNS equals checksum field value:  checksum: addition  Application SNMP (1’s complement sum) NO - error detected   data of segment contents YES - no error detected. reliable transfer over (message)   But maybe errors UDP: add reliability at sender puts  nonetheless? More later application layer checksum value into …. UDP segment format UDP checksum field application-specific  error recovery! 17 18 3

  4. Principles of Reliable data Chapter 3 outline transfer important in app., transport, link layers  3.1 Transport-layer  3.5 Connection-oriented  top-10 list of important networking topics!  services transport: TCP  3.2 Multiplexing and segment structure  demultiplexing reliable data transfer  flow control   3.3 Connectionless connection management  transport: UDP 3.6 Principles of   3.4 Principles of congestion control reliable data transfer 3.7 TCP congestion  control characteristics of unreliable channel will determine  complexity of reliable data transfer protocol (rdt) 19 20 Principles of Reliable data Principles of Reliable data transfer transfer important in app., transport, link layers important in app., transport, link layers   top-10 list of important networking topics! top-10 list of important networking topics!   characteristics of unreliable channel will determine characteristics of unreliable channel will determine   complexity of reliable data transfer protocol (rdt) complexity of reliable data transfer protocol (rdt) 21 22 Reliable data transfer: getting started Reliable data transfer: getting started We’ll: rdt_send(): called from above, (e.g., deliver_data(): called by rdt by app.). Passed data to to deliver data to upper incrementally develop sender, receiver sides of  deliver to receiver upper layer reliable data transfer protocol (rdt) consider only unidirectional data transfer  but control info will flow on both directions!  send receive use finite state machines (FSM) to specify  side side sender, receiver event causing state transition actions taken on state transition state: when in this state “state” next state state event 1 uniquely determined by 2 udt_send(): called by rdt, rdt_rcv(): called when packet actions next event to transfer packet over arrives on rcv-side of channel unreliable channel to receiver 23 24 4

Recommend


More recommend