Multimedia Communications @CS.NCTU Lecture 3: Networking – TCP/UDP [Computer Networking, Ch3] Instructor: Kate Ching-Ju Lin ( 林靖茹 ) Slides modified from “Computer Networking: A Top-Down Approach” 6th Edition
Chapter 3: Transport Layer our goals: • Understand principles • Learn about Internet behind transport layer transport layer protocols: services: • UDP: connectionless transport • multiplexing, demultiplexing • TCP: connection-oriented reliable transport • reliable data transfer • TCP congestion control • flow control • congestion control
Outline • Transport-layer services • Multiplexing and demultiplexing • Connectionless transport: UDP • Connection-oriented transport: TCP • Segment structure • Reliable data transfer • Flow control • Connection management • Congestion Control
Transport Services and Protocols application • Provide logical communication transport network data link between app processes physical running on different hosts • Transport protocols run in end systems • send side: breaks app messages into segments, passes to network layer • recv side: reassembles segments application transport into messages, passes to app network data link layer physical • Available transport protocols • TCP and UDP
Transport vs. Network Layer household analogy: • Network layer: 12 kids in Ann’s house • logical communication between hosts sending letters to 12 kids in Bill’s house: • Host-to-host • hosts = houses • processes = kids • Transport layer: • app messages = letters in • logical communication envelopes between processes relies • transport protocol = Ann on, enhances, network and Bill who demux to in- layer services house siblings • network-layer protocol = • End-to-end (process-to- postal service process)
Internet Transport Protocols • Reliable, in-order delivery: application transport TCP network data link physical • congestion control network network data link • acknowledgement data link physical physical network • flow control data link physical • connection setup network data link • Unreliable, unordered physical network delivery: UDP data link physical network • no-frills extension of “best- data link application physical transport network effort” IP network data link data link physical physical • Send as many as possible • Services not available: • delay guarantees • bandwidth guarantees
Outline • Transport-layer services • Multiplexing and demultiplexing • Connectionless transport: UDP • Connection-oriented transport: TCP • Segment structure • Reliable data transfer • Flow control • Connection management • Congestion Control
Multiplexing/Demultiplexing multiplexing at sender: demultiplexing at receiver: handle data from multiple use header info to deliver sockets, add transport header received segments to correct (later used for demultiplexing) socket (unique proc ID) application P1 P2 application application socket P4 P3 transport process network transport transport link network network physical link link physical physical
How Demultiplexing Works? • Host receives IP datagrams 32 bits • each datagram has source IP source port # dest port # address, destination IP address • each datagram carries one other header fields transport-layer segment • each segment has source, destination port number Application data • host uses IP addresses & port (payload) numbers to direct segment to appropriate socket TCP/UDP segment format
Outline • Transport-layer services • Multiplexing and demultiplexing • Connectionless transport: UDP • Connection-oriented transport: TCP • Segment structure • Reliable data transfer • Flow control • Connection management • Congestion Control
UDP: User Datagram Protocol [RFC 768] • “ No frills, ” “ bare bones ” • Pros: Internet transport • low latency protocol • no state à support more • “ Best effort ” service, UDP users segments may be: • smaller packet header • lost • UDP use: • delivered out-of-order • streaming multimedia apps to app (loss tolerant, rate sensitive) • Connectionless: • DNS • no handshaking between UDP sender, • SNMP receiver • Reliable transfer over UDP: • each UDP segment • add reliability at handled independently application layer via error of others recovery
UDP: Segment Header length, in bytes of 32 bits UDP segment, including header src port # dst port # checksum length why is there a UDP? • no connection establishment (which can application data add delay) (payload) • simple: no connection state at sender, receiver • small header size • no congestion control: UDP segment format UDP can blast away as fast as desired
UDP Checksum Goal: detect “ errors ” in transmitted segment • Sender • Receiver • treat segment • compute checksum of received segment contents, including header fields, as • check if computed checksum equals sequence of 16-bit checksum field value integers • NO - error detected • checksum: addition • YES - no error detected. (one’s complement But maybe errors sum) of segment nonetheless? More contents later …. • sender puts checksum value into UDP checksum field
Internet Checksum: Example example: add two 16-bit integers 1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 1 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 wraparound 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 sum 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0 checksum 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1 Note: when adding numbers, a carryout from the most significant bit needs to be added to the result
Outline • Transport-layer services • Multiplexing and demultiplexing • Connectionless transport: UDP • Connection-oriented transport: TCP • Segment structure • Reliable data transfer • Flow control • Connection management • Congestion Control
What is Reliable Data Transfer? • Important in application, transport, link layers • top-10 list of important networking topics! • Characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt)
What is Reliable Data Transfer? • Important in application, transport, link layers • top-10 list of important networking topics! • Characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt)
What is Reliable Data Transfer? • Important in application, transport, link layers • top-10 list of important networking topics! • Characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt)
TCP: Overview RFCs: 793,1122,1323, 2018, 2581 • Full duplex data: • Point-to-point: • bi-directional data flow • one sender, one in same connection receiver • MSS: maximum segment • Reliable, in-order size byte steam: • Connection-oriented: • no “ message boundaries ” • Three-way handshaking (exchange of control • Pipelined: msgs) inits sender, • TCP congestion and receiver state before flow control set data exchange window size • Flow controlled: • sender will not overwhelm receiver
TCP Segment Structure 32 bits URG: urgent data counting source port # dest port # (generally not used) by bytes sequence number of data ACK: ACK # (not segments!) acknowledgement number valid head not receive window U A P R S F PSH: push data now len used # bytes (generally not used) checksum Urg data pointer rcvr willing to accept RST, SYN, FIN: options (variable length) connection estab (setup, teardown commands) application data Internet (variable length) checksum (as in UDP)
TCP Seq. Numbers, ACKs outgoing segment from sender Sequence numbers: • source port # dest port # sequence number byte stream “ number ” of acknowledgement number • rwnd first byte in segment’s checksum urg pointer data window size N Acknowledgements: • seq # of next byte • expected from other side sender sequence number space cumulative ACK • sent sent, not- usable not ACKed Q : how receiver handles yet ACKed but not usable ( “ in-flight ” ) yet sent out-of-order segments incoming segment to sender • A: TCP spec doesn ’ t say, - up source port # dest port # to implementor sequence number acknowledgement number A rwnd checksum urg pointer
TCP Seq. Numbers, ACKs Host B Host A User types ‘ C ’ host ACKs receipt Seq=42, ACK=79, data = ‘ C ’ of ‘ C ’ , echoes back ‘ C ’ Seq=79, ACK=43, data = ‘ C ’ host ACKs receipt of echoed ‘ C ’ Seq=43, ACK=80 simple telnet scenario
TCP Round Trip Time, Timeout Q: how to set TCP Q: how to estimate RTT? timeout value? • SampleRTT : measured • longer than RTT, but RTT time from segment varies transmission until ACK • too short: premature receipt timeout, unnecessary • ignore retransmissions retransmissions • SampleRTT will vary, • too long: slow reaction want estimated RTT to segment loss “smoother” • average several recent measurements, not just current SampleRTT
Recommend
More recommend
