计算机网络英文课件：Chapter3 Transport Layer

1、Transport Layer3-1Chapter 3Transport LayerComputer Networking: A Top Down Approach 4th edition. Jim Kurose, Keith RossAddison-Wesley, July 2007. Transport Layer3-2Chapter 3: Transport LayerOur goals: runderstand principles behind transport layer services:mmultiplexing/demultiplexingmreliable data tr

2、ansfermflow controlmcongestion controlrlearn about transport layer protocols in the Internet:mUDP: connectionless transportmTCP: connection-oriented transportmTCP congestion controlTransport Layer3-3Chapter 3 outliner3.1 Transport-layer servicesr3.2 Multiplexing and demultiplexingr3.3 Connectionless

3、 transport: UDPr3.4 Principles of reliable data transferr3.5 Connection-oriented transport: TCPmsegment structuremreliable data transfermflow controlmconnection managementr3.6 Principles of congestion controlr3.7 TCP congestion controlTransport Layer3-4Transport services and protocolsrprovide logica

4、l communication between app processes running on different hostsrtransport protocols run in end systems msend side: breaks app messages into segments, passes to network layermrcv side: reassembles segments into messages, passes to app layerrmore than one transport protocol available to appsmInternet

5、: TCP and UDPapplicationtransportnetworkdata linkphysicalapplicationtransportnetworkdata linkphysicallogical end-end transportTransport Layer3-5Transport vs. network layerrnetwork layer: logical communication between hostsrtransport layer: logical communication between processes mrelies on, enhances

6、, network layer servicesHousehold analogy:12 kids sending letters to 12 kidsrprocesses = kidsrapp messages = letters in envelopesrhosts = housesrtransport protocol = Ann and Billrnetwork-layer protocol = postal serviceTransport Layer3-6Internet transport-layer protocolsrreliable, in-order delivery (

7、TCP)mcongestion control mflow controlmconnection setuprunreliable, unordered delivery: UDPmno-frills extension of “best-effort” IPrservices not available: mdelay guaranteesmbandwidth guaranteesapplicationtransportnetworkdata linkphysicalnetworkdata linkphysicalnetworkdata linkphysicalnetworkdata lin

8、kphysicalnetworkdata linkphysicalnetworkdata linkphysicalnetworkdata linkphysicalapplicationtransportnetworkdata linkphysicallogical end-end transportTransport Layer3-7Chapter 3 outliner3.1 Transport-layer servicesr3.2 Multiplexing and demultiplexingr3.3 Connectionless transport: UDPr3.4 Principles

9、of reliable data transferr3.5 Connection-oriented transport: TCPmsegment structuremreliable data transfermflow controlmconnection managementr3.6 Principles of congestion controlr3.7 TCP congestion controlTransport Layer3-8Multiplexing/demultiplexingapplicationtransportnetworklinkphysicalP1applicatio

10、ntransportnetworklinkphysicalapplicationtransportnetworklinkphysicalP2P3P4P1host 1host 2host 3= process= socketdelivering received segmentsto correct socketDemultiplexing at rcv host:gathering data from multiplesockets, enveloping data with header (later used for demultiplexing)Multiplexing at send

11、host:Transport Layer3-9How demultiplexing worksrhost receives IP datagramsmeach datagram has source IP address, destination IP addressmeach datagram carries 1 transport-layer segmentmeach segment has source, destination port number rhost uses IP addresses & port numbers to direct segment to appr

12、opriate socketsource port #dest port #32 bitsapplicationdata (message)other header fieldsTCP/UDP segment formatTransport Layer3-10Connectionless demultiplexingrCreate sockets with port numbers:DatagramSocket mySocket1 = new DatagramSocket(12534);DatagramSocket mySocket2 = new DatagramSocket(12535);r

13、UDP socket identified by two-tuple:(dest IP address, dest port number)rWhen host receives UDP segment:mchecks destination port number in segmentmdirects UDP segment to socket with that port numberrIP datagrams with different source IP addresses and/or source port numbers directed to same socketTrans

14、port Layer3-11Connectionless demux (cont)DatagramSocket serverSocket = new DatagramSocket(6428);ClientIP:BP2client IP: AP1P1P3serverIP: CSP: 6428DP: 9157SP: 9157DP: 6428SP: 6428DP: 5775SP: 5775DP: 6428SP provides “return address”Transport Layer3-12Connection-oriented demuxrTCP socket identified by 4

15、-tuple: msource IP addressmsource port numbermdest IP addressmdest port numberrrecv host uses all four values to direct segment to appropriate socketrServer host may support many simultaneous TCP sockets:meach socket identified by its own 4-tuplerWeb servers have different sockets for each connectin

16、g clientmnon-persistent HTTP will have different socket for each requestTransport Layer3-13Connection-oriented demux (cont)ClientIP:BP1client IP: AP1P2P4serverIP: CSP: 9157DP: 80SP: 9157DP: 80P5P6P3D-IP:CS-IP: AD-IP:CS-IP: BSP: 5775DP: 80D-IP:CS-IP: BTransport Layer3-14Connection-oriented demux: Thr

17、eaded Web ServerClientIP:BP1client IP: AP1P2serverIP: CSP: 9157DP: 80SP: 9157DP: 80P4P3D-IP:CS-IP: AD-IP:CS-IP: BSP: 5775DP: 80D-IP:CS-IP: BTransport Layer3-15PortProtocolUse21FTPFile transfer23TelnetRemote login25SMTPE-mail69TFTPTrivial File Transfer Protocol79FingerLookup info about a user80HTTPWo

18、rld Wide Web110POP-3Remote e-mail access119NNTPUSENET news Some assigned portsTransport Layer3-16Chapter 3 outliner3.1 Transport-layer servicesr3.2 Multiplexing and demultiplexingr3.3 Connectionless transport: UDPr3.4 Principles of reliable data transferr3.5 Connection-oriented transport: TCPmsegmen

19、t structuremreliable data transfermflow controlmconnection managementr3.6 Principles of congestion controlr3.7 TCP congestion controlTransport Layer3-17UDP: User Datagram Protocol RFC 768r“no frills,” “bare bones” Internet transport protocolr“best effort” service, UDP segments may be:mlostmdelivered

20、 out of order to apprconnectionless:mno handshaking between UDP sender, receivermeach UDP segment handled independently of othersWhy is there a UDP?rno connection establishment (which can add delay)rsimple: no connection state at sender, receiverrsmall segment headerrno congestion control: UDP can b

21、last away as fast as desiredTransport Layer3-18UDP: moreroften used for streaming multimedia appsmloss tolerantmrate sensitiverother UDP usesmDNSmSNMPrreliable transfer over UDP: add reliability at application layermapplication-specific error recovery!source port #dest port #32 bitsApplicationdata (

22、message)UDP segment formatlengthchecksumLength, inbytes of UDPsegment,includingheaderTransport Layer3-19UDP checksumSender:rtreat segment contents as sequence of 16-bit integersrchecksum: addition (1s complement sum) of segment contentsrsender puts checksum value into UDP checksum fieldReceiver:rcom

23、pute checksum of received segmentrcheck if computed checksum equals checksum field value:mNO - error detectedmYES - no error detected. Goal: detect “errors” (e.g., flipped bits) in transmitted segment (RFC 1071)Transport Layer3-20Internet Checksum ExamplerNotemWhen adding numbers, a carryout from th

24、e most significant bit needs to be added to the resultrExample: add two 16-bit integers1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 01 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 11 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 11 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 01 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1wraparoundsumchecksumTransport Layer3-21Chapter

25、3 outliner3.1 Transport-layer servicesr3.2 Multiplexing and demultiplexingr3.3 Connectionless transport: UDPr3.4 Principles of reliable data transferr3.5 Connection-oriented transport: TCPmsegment structuremreliable data transfermflow controlmconnection managementr3.6 Principles of congestion contro

26、lr3.7 TCP congestion controlTransport Layer3-22Principles of Reliable data transferrimportant in app., transport, link layersrtop-10 list of important networking topics!rcharacteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt)Transport Layer3-23Reliabl

27、e data transfer: getting startedsendsidereceivesiderdt_send(): called from above, (e.g., by app.). Passed data to deliver to receiver upper layerudt_send(): called by rdt,to transfer packet over unreliable channel to receiverrdt_rcv(): called when packet arrives on rcv-side of channeldeliver_data():

28、 called by rdt to deliver data to upperTransport Layer3-24Reliable data transfer: getting startedWell:rincrementally develop sender, receiver sides of reliable data transfer protocol (rdt)rconsider only unidirectional data transfermbut control info will flow on both directions!ruse finite state mach

29、ines (FSM) to specify sender, receiverstate1state2event causing state transitionactions taken on state transitionstate: when in this “state” next state uniquely determined by next eventeventactionsTransport Layer3-25Rdt1.0: reliable transfer over a reliable channelrunderlying channel perfectly relia

30、blemno bit errorsmno loss of packetsrseparate FSMs for sender, receiver:msender sends data into underlying channelmreceiver read data from underlying channelWait for call from abovepacket = make_pkt(data)udt_send(packet)rdt_send(data)extract (packet,data)deliver_data(data)Wait for call from belowrdt

31、_rcv(packet)senderreceiverTransport Layer3-26Rdt2.0: channel with bit errorsrunderlying channel may flip bits in packetmchecksum to detect bit errorsrthe question: how to recover from errors:macknowledgements (ACKs): receiver explicitly tells sender that pkt received OKmnegative acknowledgements (NA

32、Ks): receiver explicitly tells sender that pkt had errorsmsender retransmits pkt on receipt of NAKrnew mechanisms in rdt2.0 (beyond rdt1.0):merror detectionmreceiver feedback: control msgs (ACK,NAK) rcvr-senderTransport Layer3-27rdt2.0: FSM specificationWait for call from abovesnkpkt = make_pkt(data

33、, checksum)udt_send(sndpkt)extract(rcvpkt,data)deliver_data(data)udt_send(ACK)rdt_rcv(rcvpkt) & notcorrupt(rcvpkt)rdt_rcv(rcvpkt) & isACK(rcvpkt)udt_send(sndpkt)rdt_rcv(rcvpkt) & isNAK(rcvpkt)udt_send(NAK)rdt_rcv(rcvpkt) & corrupt(rcvpkt)Wait for ACK or NAKWait for call from belowsen

34、derreceiverrdt_send(data)LTransport Layer3-28rdt2.0: operation with no errorsWait for call from abovesnkpkt = make_pkt(data, checksum)udt_send(sndpkt)extract(rcvpkt,data)deliver_data(data)udt_send(ACK)rdt_rcv(rcvpkt) & notcorrupt(rcvpkt)rdt_rcv(rcvpkt) & isACK(rcvpkt)udt_send(sndpkt)rdt_rcv(

35、rcvpkt) & isNAK(rcvpkt)udt_send(NAK)rdt_rcv(rcvpkt) & corrupt(rcvpkt)Wait for ACK or NAKWait for call from belowrdt_send(data)LTransport Layer3-29rdt2.0: error scenarioWait for call from abovesnkpkt = make_pkt(data, checksum)udt_send(sndpkt)extract(rcvpkt,data)deliver_data(data)udt_send(ACK)

36、rdt_rcv(rcvpkt) & notcorrupt(rcvpkt)rdt_rcv(rcvpkt) & isACK(rcvpkt)udt_send(sndpkt)rdt_rcv(rcvpkt) & isNAK(rcvpkt)udt_send(NAK)rdt_rcv(rcvpkt) & corrupt(rcvpkt)Wait for ACK or NAKWait for call from belowrdt_send(data)LTransport Layer3-30rdt2.0 has a fatal flaw!What happens if ACK/NAK

37、 corrupted?rsender doesnt know what happened at receiver!rcant just retransmit: possible duplicateHandling duplicates: rsender retransmits current pkt if ACK/NAK garbledrsender adds sequence number to each pktrreceiver discards (doesnt deliver up) duplicate pktSender sends one packet, then waits for

38、 receiver responsestop and waitTransport Layer3-31rdt2.1: sender, handles garbled ACK/NAKsWait for call 0 from abovesndpkt = make_pkt(0, data, checksum)udt_send(sndpkt)rdt_send(data)Wait for ACK or NAK 0udt_send(sndpkt)rdt_rcv(rcvpkt) & ( corrupt(rcvpkt) |isNAK(rcvpkt) )sndpkt = make_pkt(1, data

39、, checksum)udt_send(sndpkt)rdt_send(data)rdt_rcv(rcvpkt) & notcorrupt(rcvpkt) & isACK(rcvpkt) udt_send(sndpkt)rdt_rcv(rcvpkt) & ( corrupt(rcvpkt) |isNAK(rcvpkt) )rdt_rcv(rcvpkt) & notcorrupt(rcvpkt) & isACK(rcvpkt) Wait for call 1 from aboveWait for ACK or NAK 1LLTransport Layer3

40、-32rdt2.1: receiver, handles garbled ACK/NAKsWait for 0 from belowsndpkt = make_pkt(NAK, chksum)udt_send(sndpkt)rdt_rcv(rcvpkt) & not corrupt(rcvpkt) & has_seq0(rcvpkt)rdt_rcv(rcvpkt) & notcorrupt(rcvpkt) & has_seq1(rcvpkt) extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(ACK,

41、 chksum)udt_send(sndpkt)Wait for 1 from belowrdt_rcv(rcvpkt) & notcorrupt(rcvpkt) & has_seq0(rcvpkt) extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)rdt_rcv(rcvpkt) & (corrupt(rcvpkt)sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)rdt_rcv(rcvpkt) & n

42、ot corrupt(rcvpkt) & has_seq1(rcvpkt)rdt_rcv(rcvpkt) & (corrupt(rcvpkt)sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)sndpkt = make_pkt(NAK, chksum)udt_send(sndpkt)Transport Layer3-33rdt2.1: discussionSender:rseq # added to pktrtwo seq. #s (0,1) will suffice. Why?rmust check if received ACK/N

43、AK corrupted rtwice as many statesmstate must “remember” whether “current” pkt has 0 or 1 seq. #Receiver:rmust check if received packet is duplicatemstate indicates whether 0 or 1 is expected pkt seq #rnote: receiver can not know if its last ACK/NAK received OK at senderTransport Layer3-34rdt2.2: a

44、NAK-free protocolrsame functionality as rdt2.1, using ACKs onlyrinstead of NAK, receiver sends ACK for last pkt received OKmreceiver must explicitly include seq # of pkt being ACKed rduplicate ACK at sender results in same action as NAK: retransmit current pktTransport Layer3-35rdt3.0: channels with

45、 errors and lossNew assumption: underlying channel can also lose packets (data or ACKs)mchecksum, seq. #, ACKs, retransmissions will be of help, but not enoughApproach: sender waits “reasonable” amount of time for ACK rretransmits if no ACK received in this timerif pkt (or ACK) just delayed (not los

46、t):mretransmission will be duplicate, but use of seq. #s already handles thismreceiver must specify seq # of pkt being ACKedrrequires countdown timerTransport Layer3-36rdt3.0 sendersndpkt = make_pkt(0, data, checksum)udt_send(sndpkt)start_timerrdt_send(data)Wait for ACK0rdt_rcv(rcvpkt) & ( corru

47、pt(rcvpkt) |isACK(rcvpkt,1) )Wait for call 1 from abovesndpkt = make_pkt(1, data, checksum)udt_send(sndpkt)start_timerrdt_send(data)rdt_rcv(rcvpkt) & notcorrupt(rcvpkt) & isACK(rcvpkt,0) rdt_rcv(rcvpkt) & ( corrupt(rcvpkt) |isACK(rcvpkt,0) )rdt_rcv(rcvpkt) & notcorrupt(rcvpkt) &

48、isACK(rcvpkt,1) stop_timerstop_timerudt_send(sndpkt)start_timertimeoutudt_send(sndpkt)start_timertimeoutrdt_rcv(rcvpkt)Wait for call 0from aboveWait for ACK1Lrdt_rcv(rcvpkt)LLLTransport Layer3-37rdt3.0 in actionTransport Layer3-38rdt3.0 in actionTransport Layer3-39Performance of rdt3.0rrdt3.0 works,

49、 but performance stinksrexample: 1 Gbps link, 15 ms e-e prop. delay, 1KB packet:Ttransmit=8*10*3b/pkt10*9 b/sec= 0.008 microsecmU sender: utilization fraction of time sender busy sending U sender = .008 30.008 = 0.00027 L / R RTT + L / R = L (packet length in bits)R (transmission rate, bps)=m1KB pkt

50、 every 30 msec - 33kB/sec thruput over 1 Gbps linkmnetwork protocol limits use of physical resources!Transport Layer3-40rdt3.0: stop-and-wait operationfirst packet bit transmitted, t = 0senderreceiverRTT last packet bit transmitted, t = L / Rfirst packet bit arriveslast packet bit arrives, send ACKA

51、CK arrives, send next packet, t = RTT + L / R U sender = .008 30.008 = 0.00027 L / R RTT + L / R = Transport Layer3-41Pipelined protocolsPipelining: sender allows multiple, “in-flight”, yet-to-be-acknowledged pktsmrange of sequence numbers must be increasedmbuffering at sender and/or receiverrTwo ge

52、neric forms of pipelined protocols: go-Back-N, selective repeatTransport Layer3-42Pipelining: increased utilizationfirst packet bit transmitted, t = 0senderreceiverRTT last bit transmitted, t = L / Rfirst packet bit arriveslast packet bit arrives, send ACKACK arrives, send next packet, t = RTT + L /

53、 Rlast bit of 2nd packet arrives, send ACKlast bit of 3rd packet arrives, send ACK U sender = .024 30.008 = 0.0008 microseconds 3 * L / R RTT + L / R = Increase utilizationby a factor of 3!Transport Layer3-43Go-Back-NSender:rk-bit seq # in pkt headerr“window” of up to N, consecutive unacked pkts all

54、owedrACK(n): ACKs all pkts up to, including seq # n - “cumulative ACK”mmay receive duplicate ACKs (see receiver)rtimer for each in-flight pktrtimeout(n): retransmit pkt n and all higher seq # pkts in windowTransport Layer3-44GBN: sender extended FSMWaitstart_timerudt_send(sndpktbase)udt_send(sndpktb

55、ase+1)udt_send(sndpktnextseqnum-1)timeoutrdt_send(data) if (nextseqnum no receiver buffering!mRe-ACK pkt with highest in-order seq #Waitudt_send(sndpkt)defaultrdt_rcv(rcvpkt) & notcurrupt(rcvpkt) & hasseqnum(rcvpkt,expectedseqnum) extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(expec

56、tedseqnum,ACK,chksum)udt_send(sndpkt)expectedseqnum+expectedseqnum=1sndpkt = make_pkt(expectedseqnum,ACK,chksum)LTransport Layer3-46GBN inactionTransport Layer3-47Selective Repeatrreceiver individually acknowledges all correctly received pktsmbuffers pkts, as needed, for eventual in-order delivery t

57、o upper layerrsender only resends pkts for which ACK not receivedmsender timer for each unACKed pktrsender windowmN consecutive seq #smagain limits seq #s of sent, unACKed pktsTransport Layer3-48Selective repeat: sender, receiver windowsTransport Layer3-49Selective repeatdata from above :rif next av

58、ailable seq # in window, send pkttimeout(n):rresend pkt n, restart timerACK(n) in sendbase,sendbase+N:rmark pkt n as receivedrif n=sendbase, advance window base to the unACKed pkt with smallest seq # senderpkt n in rcvbase, rcvbase+N-1rsend ACK(n)rout-of-order: bufferrin-order: deliver (also deliver

59、 buffered, in-order pkts), advance window to next not-yet-received pktpkt n in rcvbase-N,rcvbase-1rACK(n)otherwise: rignore receiverTransport Layer3-50Selective repeat in actionTransport Layer3-51Selective repeat: dilemmaExample: rseq #s: 0, 1, 2, 3rwindow size=3rreceiver sees no difference in two s

60、cenarios!rincorrectly passes duplicate data as new in (a)Q: what relationship between seq # size and window size?Transport Layer3-52rComparison of three sliding window protocols Each of sliding window protocols can be used in the actual environment, the differences of them are the efficiency, complexity and the need for buffer. The differences are the sizes of sending & receiving window : Alternating bit : 0 = size of Sending win