The Transport Layer: TCP and UDP Chap 1 Foundation The Transport Layer: TCP and UDP Chap 2

Basic Philosophy of TCP/IP Simple core, complex edge Edge can be hosts, edge routers, network boundaries, etc. Why? Scalable, flexibility for different complexities at edge

Internet Architecture Mesh of separate networks connected at exchange points Tier 1 providers carry full Internet routing tables no defaults Tier 2+ providers carry subset and point to upstream default

Overview of TCP/IP Protocols

Transport services and protocols provide logical communication between app processes running on different hosts transport protocols run in end systems send side: breaks app messages into segments, passes to network layer rcv side: reassembles segments into messages, passes to app layer more than one transport protocol available to apps Internet: TCP and UDP application transport network data link physical network data link physical network data link physical network data link physical logical end-end transport network data link physical network data link physical application transport network data link physical

Transport vs. network layer network layer: logical communication between hosts transport layer: logical communication between processes relies on, enhances, network layer services Household analogy: 12 kids sending letters to 12 kids processes = kids app messages = letters in envelopes hosts = houses transport protocol = Ann and Bill network-layer protocol = postal service

Internet transport-layer protocols reliable, in-order delivery (TCP) congestion control flow control connection setup unreliable, unordered delivery: UDP no-frills extension of “best-effort” IP services not available: delay guarantees bandwidth guarantees application transport network data link physical network data link physical network data link physical network data link physical logical end-end transport network data link physical network data link physical application transport network data link physical

UDP: User Datagram Protocol “no frills,” “bare bones” Internet transport protocol “best effort” service, UDP segments may be: lost delivered out of order to app connectionless: no handshaking between UDP sender, receiver each UDP segment handled independently of others Why is there a UDP? no connection establishment (which can add delay) simple: no connection state at sender, receiver small segment header no congestion control: UDP can blast away as fast as desired

UDP: more often used for streaming multimedia apps other UDP uses loss tolerant rate sensitive other UDP uses DNS SNMP reliable transfer over UDP: add reliability at application layer application-specific error recovery! 32 bits source port # dest port # Length, in bytes of UDP segment, including header length checksum Application data (message) UDP segment format

TCP Overview full duplex data: connection-oriented: flow controlled: bi-directional data flow in same connection MSS: maximum segment size connection-oriented: handshaking (exchange of control msgs) init’s sender, receiver state before data exchange flow controlled: sender will not overwhelm receiver point-to-point: one sender, one receiver reliable, in-order byte steam: no “message boundaries” pipelined: TCP congestion and flow control set window size send & receive buffers

TCP segment structure source port # dest port # application data 32 bits application data (variable length) sequence number acknowledgement number Receive window Urg data pnter checksum F S R P A U head len not used Options (variable length) URG: urgent data (generally not used) counting by bytes of data (not segments!) ACK: ACK # valid PSH: push data now (generally not used) # bytes rcvr willing to accept RST, SYN, FIN: connection estab (setup, teardown commands) Internet checksum (as in UDP)

Reliable Transfer in TCP Host A Host B Seq=42, ACK=79, data = ‘C’ Seq=79, ACK=43, data = ‘C’ Seq=43, ACK=80 User types ‘C’ host ACKs receipt of echoed receipt of ‘C’, echoes back ‘C’ time simple telnet scenario Sliding Window

TCP Connection Setup and Teardown Establishment: Three-Way Handshake Termination

Sliding Window Each byte has a sequence number ACKs are cumulative NextByteRead Each byte has a sequence number ACKs are cumulative Sending side LastByteAcked  LastByteSent  LastByteWritten Bytes between LastByteAcked and LastByteWritten must be buffered Receiving side NextByteRead < NextByteExpected  LastByteRcvd + 1 Bytes between NextByteRead and LastByteRcvd must be buffered

TCP State Transition Diagram

TIME_WAIT State MSL: maximum segment lifetime 30 sec in BSD-derived implementation 2 min in RFC 1122 Reason for the TIME-WAIT state(waiting for 2MSL) to implement TCP’s full-duplex connection termination reliably termination 중에 lost, duplicated packet 문제를 해결하기 위해 to allow old duplicate segments to expire in the network 같은 host의 같은 port로 연결되는 next TCP connection에 그전 session의 packet을 제거하기 위해

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

How demultiplexing works host receives IP datagrams each datagram has source IP address, destination IP address each datagram carries 1 transport-layer segment each segment has source, destination port number (recall: well-known port numbers for specific applications) host uses IP addresses & port numbers to direct segment to appropriate socket 32 bits source port # dest port # other header fields application data (message) TCP/UDP segment format

Connectionless demultiplexing Create sockets with port numbers: DatagramSocket mySocket1 = new DatagramSocket(99111); DatagramSocket mySocket2 = new DatagramSocket(99222); UDP socket identified by two-tuple: (dest IP address, dest port number) When host receives UDP segment: checks destination port number in segment directs UDP segment to socket with that port number IP datagrams with different source IP addresses and/or source port numbers directed to same socket

Connectionless demux (cont) DatagramSocket serverSocket = new DatagramSocket(6428); Client IP:B P2 client IP: A P1 P3 server IP: C SP: 6428 DP: 9157 SP: 9157 DP: 6428 DP: 5775 SP: 5775 SP provides “return address”

Connection-oriented demux TCP socket identified by 4-tuple: source IP address source port number dest IP address dest port number recv host uses all four values to direct segment to appropriate socket Server host may support many simultaneous TCP sockets: each socket identified by its own 4-tuple Web servers have different sockets for each connecting client non-persistent HTTP will have different socket for each request

Connection-oriented demux (cont) P1 client IP: A P4 P5 P6 P2 P1 P3 SP: 5775 DP: 80 S-IP: B D-IP:C SP: 9157 SP: 9157 DP: 80 DP: 80 Client IP:B server IP: C S-IP: A S-IP: B D-IP:C D-IP:C

Connection-oriented demux: Threaded Web Server P1 client IP: A P4 P2 P1 P3 SP: 5775 DP: 80 S-IP: B D-IP:C SP: 9157 SP: 9157 DP: 80 DP: 80 Client IP:B server IP: C S-IP: A S-IP: B D-IP:C D-IP:C

Socket programming Goal: learn how to build client/server application that communicate using sockets Socket API introduced in BSD4.1 UNIX, 1981 explicitly created, used, released by apps client/server paradigm two types of transport service via socket API: unreliable datagram reliable, byte stream-oriented a host-local, application-created, OS-controlled interface (a “door”) into which application process can both send and receive messages to/from another application process socket

Socket-programming using TCP Socket: a door between application process and end-end-transport protocol (UCP or TCP) TCP service: reliable transfer of bytes from one process to another controlled by application developer controlled by application developer process TCP with buffers, variables socket process TCP with buffers, variables socket controlled by operating system controlled by operating system internet host or server host or server

Socket programming with TCP Client must contact server server process must first be running server must have created socket (door) that welcomes client’s contact Client contacts server by: creating client-local TCP socket specifying IP address, port number of server process When client creates socket: client TCP establishes connection to server TCP When contacted by client, server TCP creates new socket for server process to communicate with client allows server to talk with multiple clients source port numbers used to distinguish clients (more in Chap 3) TCP provides reliable, in-order transfer of bytes (“pipe”) between client and server application viewpoint

Port Number

TCP Port Numbers and Concurrent Servers (1) foreign local ? 21 foreign local ? 21 foreign local 21 1500 12.106.32.254 206.168.112.219 foreign local ? 21 foreign local 1500 21 206.168.112.219 12.106.32.254 foreign local 21 1500 12.106.32.254 206.168.112.219

TCP Port Numbers and Concurrent Servers (2) foreign local 21 1500 12.106.32.254 206.168.112.219 foreign local 21 foreign local 1500 21 206.168.112.219 12.106.32.254 foreign local 1501 21 206.168.112.219 12.106.32.254 foreign local 21 1501 12.106.32.254 206.168.112.219

TCP Output Successful return from write means that we can reuse application buffer TCP must keep a copy of our data in the socket send buffer until ACK is received.

UDP Output Successful return from write means that the datagram or fragments of the datagram have been added to the datalink output queue

Buffer Size and Limitation Max. size of IP datagram IPv4: 65535 bytes including header(20 bytes) IPv6: 65535 bytes(payload) + 40 bytes(header) MTU (Max. Transmission Unit) Network이 전달해 줄 수 있는 최대 payload 크기(Ethernet에서 1500 bytes) path MTU: the smallest MTU in the path between two hosts Fragmentation is performed if datagram size > link MTU In IPv4: by host or router, IPv6: only by host DF bit in IPv4 header may be used for path MTU discovery Min. reassembly buffer size (guaranteed by any implementation) 576 bytes in IPv4, 1500 bytes in IPv6 MSS (Max. Segment Size): max TCP payload size to avoid IP fragmentation In Ethernet, MSS = MTU(1500) – IP header(20 or 40) – TCP header(20) = 1460 B (IPv4) or 1440 B (IPv6)

Standard Internet Services See /etc/services Services running on TCP or UDP Distinguished by protocol and port number A Service is a symbolic representation of port number

Protocol Usage by Common Internet Applications