Last time specific protocols: Application architectures HTTP - PDF document

Last time � specific protocols: � Application architectures � HTTP � client-server � P2P � SMTP, POP, IMAP � hybrid � DNS � Application service � P2P requirements: � reliability, bandwidth, delay � Internet transport service model � connection-oriented, reliable: TCP � unreliable, datagrams: UDP 2/4-07 Datakommunikation - Jonny Pettersson, UmU Last time Most importantly: learned about protocols � typical request/reply � control vs. data msgs message exchange: � in-band, out-of-band � client requests info or � centralized vs. decentralized service � stateless vs. stateful � server responds with � reliable vs. unreliable msg data, status code transfer � message formats: � “complexity at network � headers: fields giving edge” info about data � data: info being communicated 2/4-07 Datakommunikation - Jonny Pettersson, UmU 1

Transport Layer 1 Lecture Overview: Lecture goals: � transport layer services � understand some of the � multiplexing/demultiplexing principles behind transport layer services: � connectionless transport: UDP � principles of reliable data � multiplexing/demultiplex transfer ing � reliable data transfer � instantiation and � Next lecture implementation of UDP in � connection-oriented transport: TCP the Internet • reliable transfer � More next time… • flow control • connection management � principles of congestion control � TCP congestion control 2/4-07 Datakommunikation - Jonny Pettersson, UmU Transport services and protocols � provide logical communication application between app’ processes transport network running on different hosts data link network physical data link l o network g physical � transport protocols run in i data link c a physical l end systems e n network d - data link � transport vs network layer e n physical network d data link services: t r physical a n s � network layer: data transfer network p o data link r t between end systems physical � transport layer: data application transport transfer between processes network data link � relies on, enhances, network physical layer services 2/4-07 Datakommunikation - Jonny Pettersson, UmU 2

Transport-layer protocols Internet transport services: Application � reliable, in-order unicast delivery (TCP) � congestion control UDP TCP � flow control � connection setup � unreliable (“best-effort”), IP unordered unicast or multicast delivery: UDP Link � services not available: � real-time � bandwidth guarantees Physical � reliable multicast 2/4-07 Datakommunikation - Jonny Pettersson, UmU End-to-end protocol Two forces shape the end-to-end protocol � Applications has demands on the supplied service � Underlying network protocol has limitations 2/4-07 Datakommunikation - Jonny Pettersson, UmU 3

Multiplexing/demultiplexing Multiplexing at send host: Demultiplexing at rcv host: gathering data from multiple delivering received segments sockets, enveloping data with to correct socket header (later used for demultiplexing) = socket = process P4 application P1 P2 P3 P1 application application transport transport transport network network network link link link physical physical physical host 3 host 1 host 2 2/4-07 Datakommunikation - Jonny Pettersson, UmU How demultiplexing works � host receives IP datagrams � each datagram has source 32 bits IP address, destination IP source port # dest port # address � each datagram carries 1 transport-layer segment other header fields � each segment has source, destination port number (recall: well-known port application numbers for specific data applications) (message) � host uses IP addresses & port numbers to direct segment to appropriate socket TCP/UDP segment format 2/4-07 Datakommunikation - Jonny Pettersson, UmU 4

Connectionless demux � UDP socket identified by two-tuple: (dest IP address, dest port number) P1 P2 P1 P3 SP: 6428 SP: 6428 DP: 9157 DP: 5775 SP: 9157 SP: 5775 client DP: 6428 DP: 6428 Client server IP: A IP:B IP: C SP provides “return address” 2/4-07 Datakommunikation - Jonny Pettersson, UmU Connection-oriented demux � TCP socket identified � Server host may support by 4-tuple: many simultaneous TCP sockets: � source IP address � source port number � each socket identified by its own 4-tuple � dest IP address � Web servers have � dest port number different sockets for � recv host uses all four each connecting client values to direct segment to appropriate � non-persistent HTTP will have different socket for socket each request 2/4-07 Datakommunikation - Jonny Pettersson, UmU 5

Connection-oriented demux (cont) P1 P1 P4 P5 P6 P2 P3 SP: 5775 DP: 80 S-IP: B D-IP:C SP: 9157 SP: 9157 client DP: 80 DP: 80 Client server IP: A S-IP: A S-IP: B IP:B IP: C D-IP:C D-IP:C 2/4-07 Datakommunikation - Jonny Pettersson, UmU Connection-oriented demux: Threaded Web Server P1 P2 P1 P4 P3 SP: 5775 DP: 80 S-IP: B D-IP:C SP: 9157 SP: 9157 client DP: 80 DP: 80 Client server IP: A S-IP: A S-IP: B IP:B IP: C D-IP:C D-IP:C 2/4-07 Datakommunikation - Jonny Pettersson, UmU 6

UDP: User Datagram Protocol [RFC 768] � “no frills,” “bare bones” Internet transport Why is there a UDP? protocol � no connection � “best effort” service, UDP establishment (which can segments may be: add delay) � lost � simple: no connection state � delivered out of order at sender, receiver to app � small segment header � connectionless: � no congestion control: UDP � no handshaking between can blast away as fast as UDP sender, receiver desired � each UDP segment handled independently of others 2/4-07 Datakommunikation - Jonny Pettersson, UmU UDP: more � often used for streaming 32 bits multimedia apps � loss tolerant source port # dest port # Length, in � rate sensitive bytes of UDP length checksum segment, � other UDP uses including � DNS header � SNMP � reliable transfer over UDP: Application add reliability at data application layer (message) � application-specific error recovery! UDP segment format 2/4-07 Datakommunikation - Jonny Pettersson, UmU 7

UDP checksum Goal: detect “errors” (e.g., flipped bits) in transmitted segment Sender: Receiver: � treat segment contents � compute checksum of received as sequence of 16-bit segment integers � check if computed checksum � checksum: addition (1’s equals checksum field value: complement sum) of � NO - error detected segment contents � YES - no error detected � sender puts checksum But maybe errors value into UDP checksum nonetheless? More later … field 2/4-07 Datakommunikation - Jonny Pettersson, UmU UDP checksum (more) � the checksum is computed over � UDP header 0 16 31 � payload Source IP Address � pseudo header Destination IP Address • used to verify endconnections 0 Protocol UDP Length � why control errors in several layers? 2/4-07 Datakommunikation - Jonny Pettersson, UmU 8

Principles of Reliable data transfer � important in app., transport, link layers � top-10 list of important networking topics! � characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt) 2/4-07 Datakommunikation - Jonny Pettersson, UmU Reliable data transfer: getting started rdt_send(): called from above, deliver_data(): called by (e.g., by app.). Passed data to rdt to deliver data to upper deliver to receiver upper layer send receive side side udt_send(): called by rdt, rdt_rcv(): called when packet to transfer packet over arrives on rcv-side of channel unreliable channel to receiver 2/4-07 Datakommunikation - Jonny Pettersson, UmU 9

Reliable data transfer: getting started We’ll: � incrementally develop sender, receiver sides of reliable data transfer protocol (rdt) � consider only unidirectional data transfer � but control info will flow on both directions! � use finite state machines (FSM) to specify sender, receiver event causing state transition actions taken on state transition state: when in this state state “state” next state 1 event uniquely determined 2 actions by next event 2/4-07 Datakommunikation - Jonny Pettersson, UmU Rdt1.0: reliable transfer over a reliable channel � underlying channel perfectly reliable � no bit errors � no loss of packets � separate FSMs for sender, receiver: � sender sends data into underlying channel � receiver read data from underlying channel rdt_send(data) rdt_rcv(packet) Wait for Wait for call from call from extract (packet,data) packet = make_pkt(data) above below deliver_data(data) udt_send(packet) sender receiver 2/4-07 Datakommunikation - Jonny Pettersson, UmU 10