EE 122 Transport Protocols Kevin Lai October 16 2002 Motivation IP provides a weak but efficient service model best effort packets can be delayed dropped reordered duplicated packets have limited size why IP packets are addressed to a host how to decide which application gets which packets How should hosts send into the network every sends as fast as they can drop many packets network is under utilized congestion collapse laik cs berkeley edu 2 Transport Protocol TCP UDP Provides more than the underlying network protocol more reliability in order delivery at most once delivery supports messages of arbitrary length provide a way to decide which packets go to which applications multiplexing demultiplexing govern how hosts should send data to prevent congestion collapse congestion control and avoidance laik cs berkeley edu IP Transport Layer Networking Layer Link Layer Physical Layer 3 UDP User Datagram Protocol minimalistic transport protocol same best effort service model as IP messages can be larger than one packet but still limited 64KB uses fragmentation provides multiplexing demultiplexing to IP does not provide congestion control advantage over TCP does not increase end toend delay over IP application example video audio streaming laik cs berkeley edu 4 TCP Transmission Control Protocol reliable in order and at most once delivery messages can be of arbitrary length provides multiplexing demultiplexing to IP provides congestion control and avoidance increases end to end delay over IP e g file transfer chat laik cs berkeley edu 5 Headers IP IP header used for IP routing fragmentation error detection UDP header used for multiplexing demultiplexing error detection TCP header used for multiplexing demultiplexing flow and congestion control Receiver Sender data Application Application TCP UDP data TCP UDP TCP UDP TCP UDP data IP IP laik cs berkeley edu data IP TCP UDP data TCP UDP data 6 IP Header 0 4 8 Version HLen TOS Identification TTL Comments 16 19 Flags 31 Length Fragment offset Protocol Header checksum Source address Destination address 20 bytes Options variable Payload HLen header length only in 32 bit words 5 HLen 15 TOS Type of Service Differentiated Service 6 bits Explicit Congestion Notification ECN 2 bits Length the length of the entire datagram segment header data Flags Don t Fragment DF and More Fragments MF Protocol identifies the transport protocol Header checksum uses 1 s complement laik cs berkeley edu 7 Fragmentation What happens if router has to forward an IP packet that is larger than allowed by a data link layer Break the IP packet into smaller IP packets and provide a way to reassemble set more fragments bit in all fragments but last set the fragment offset of fragment to be offset in 8byte offsets from beginning of original packet set the packet len to be length of this fragment laik cs berkeley edu 8 Fragmentation Issues Sending host had better be changing the IP ID Loose one fragment loose them all Reassembly is complex requires per packet state Only reassemble at destination Fragmentation can be avoided using Path Maximum Transmission Unit Discovery PMTU most TCP implementations use PMTU laik cs berkeley edu 9 UDP Header 0 16 31 Destination port Source port UDP length UDP checksum Payload variable Source and destination ports use port address space UDP length is UDP packet length including UDP header and payload but not IP header Optional UDP checksum is over UDP packet why have UDP checksum in addition to IP checksum why not have just the UDP checksum why is the UDP checksum optional laik cs berkeley edu 10 Port Addressing Need to decide which application gets which packets Solution map each socket to a port Client must know server s port separate 16 bit port address space for UDP and TCP src IP src port dst IP dst port uniquely identifies TCP connection Well known ports 0 1023 everyone agrees which services run on these ports e g ssh 22 http 80 on UNIX must be root to gain access to these ports why ephemeral ports most 1024 65535 given to clients e g chatclient gets one of these laik cs berkeley edu 11 TCP Header 0 4 10 16 Destination port Source port Sequence number Acknowledgement Advertised window Flags HdrLen Checksum Urgent pointer 31 Options variable Payload variable Sequence number acknowledgement and advertised window used by sliding window based flow control Flags SYN FIN establishing terminating a TCP connection ACK set when Acknowledgement field is valid URG urgent data Urgent Pointer says where non urgent data starts PUSH don t wait to fill segment RESET abort connection laik cs berkeley edu 12 TCP Challenges how to provide reliable in order and at most once delivery sliding window need to synchronize sender and receiver connection establishment e g exchange initial sequence numbers prevent sender from sending too fast for receiver flow control estimate RTT for flow control and timeouts how to initially decide on sending rate slow start estimate how much bandwidth is available in network congestion avoidance slow down sending rate when we were sending too fast congestion control laik cs berkeley edu 13 Connection Establishment How it works Three way handshake Goal agree on a set of parameters the start sequence number for each side Starting sequence numbers are random Server Client initiator Active Open connect SYN Seq Num listen x k x 1 c A d n a y eqNum S K C A d n SYN a ACK Ack y Passive Open accept 1 allocate buffer space laik cs berkeley edu 14 Three way Handshake Rationale Three way handshare adds 1 RTT delay Why not just start sending data immediately congestion control network could be congested SYN 40 bytes Data 1500 bytes packets which are dropped at a link waste the bandwidth of all previous links smaller packets waste less bandwidth SYN acts as cheap probe of network conditions laik cs berkeley edu 15 More Rationale protection from denial of service 1 attacker could use one host to fake many SRC IP address spoofing and send many SYNs to server server must devote resources e g buffer space for open connections server would run out of resources and become very slow or crash 3 way handshake requires client to reply before server allocates significant resources protection from denial of service 2 client and server begin connection using wellknown sequence number instead of random one attacker guesses sequence number inserts bogus packets into stream laik cs berkeley edu 16 Even More Rationale protection from delayed packets client
View Full Document
Unlocking...