Download presentation
Presentation is loading. Please wait.
Published byCory McKenzie Modified over 9 years ago
1
CEN 5501C - Computer Networks - Spring 2007 - UF/CISE - Newman1 Computer Networks Transport Layer
2
CEN 5501C - Computer Networks - Spring 2007 - UF/CISE - Newman2 Transport Layer Objectives Goals –Deals with end host pacing, congestion control –Provides internal addresses on host (ports) Upward multiplexing –Reliable, end-to-end data delivery Challenges –Network reliability – lost, delayed, duplicated, out of order packets –Network delay variation (RTT estimation)
3
CEN 5501C - Computer Networks - Spring 2007 - UF/CISE - Newman3 Transport Layer Protocols UDP (User Datagram Protocol) TCP (Transmission Control Protocol) SCTP (Stream Control Transmission Prot) DCCP (Datagram Congestion Ctl Prot) RTP (Realtime Transport Protocol) ATP (AppleTalk Transaction Protocol) NetBEUI (NetBIOS Extended User Interf.)
4
CEN 5501C - Computer Networks - Spring 2007 - UF/CISE - Newman4 User Datagram Protocol “Passthrough” for IP –Upward multiplexing –No reliability guarantees at all –No congestion control Fields (8 bytes!) –Src & Dest Port (16 bits each) –Optional checksum (16 bits) –16-bit length (including header) See IETF RFC 768IETFRFC 768
5
CEN 5501C - Computer Networks - Spring 2007 - UF/CISE - Newman5 Transmission Control Protocol Much more complex –Upward multiplexing –Reliable, in-order byte stream delivery –Congestion control –No timing guarantees/QoS Session Semantics –Setup: 3-way handshake (SYN, SYN-ACK,ACK) –Use: sequence #s, ACKs –Teardown: FIN, FIN-ACK See RFC 793, RFC2581, RFC 3168RFC 793RFC2581RFC 3168
6
CEN 5501C - Computer Networks - Spring 2007 - UF/CISE - Newman6 Stream Control Transmission Protocol Multiple Stream Service –Upward multiplexing –Reliable, in-order delivery –Congestion control –Message streams –Multihoming support See RFC 2960 (protocol), RFC 3286 (text)RFC 2960RFC 3286
7
CEN 5501C - Computer Networks - Spring 2007 - UF/CISE - Newman7 Datagram Congestion Control Protocol Intermediate between TCP and UDP –Upward multiplexing –Order, reliability not guaranteed –Congestion control –No timing guarantees/QoS Session semantics (setup, use, teardown) See RFC 4340RFC 4340
8
CEN 5501C - Computer Networks - Spring 2007 - UF/CISE - Newman8 RTP For realtime traffic –Has ports for upward multiplexing –Marker bit –Payload type –32-bit Timestamp for delivery jitter –No congestion control –16-bit Sequence numbers, but no order guarantee –Runs on top of UDP –See RFC 3550RFC 3550
9
CEN 5501C - Computer Networks - Spring 2007 - UF/CISE - Newman9 AppleTalk Transaction Protocol Part of AppleTalk self-configuration –AppleTalk addr resolution protocol (AARP) hosts automatically generate own NW addrs –Name Binding Protocol (NBP) like DNS Proprietary Request/Response/ACK exchanges –1 req pkt could garner up to 8 resp pkts –Requestor sent bitmap selective ACK At-least-once and exactly-once options
10
CEN 5501C - Computer Networks - Spring 2007 - UF/CISE - Newman10 AppleTalk Data Stream Protocol Late addition to AppleTalk suite Proprietary TCP-like, except: –Host can reject a connection –No half-open connections See http://en.wikipedia.org/wiki/AppleTalk
11
CEN 5501C - Computer Networks - Spring 2007 - UF/CISE - Newman11 NetBIOS Extended User Interface Unrouted network-and-transport layer –Can only be used in a broadcast domain A.k.a. NetBIOS Frame (NBF) Uses IEEE 802.2 type 1 for name svc, datagram Uses IEEE 802.2 type 2 for session svc.
12
CEN 5501C - Computer Networks - Spring 2007 - UF/CISE - Newman12 Back to TCP Fields (20 bytes!) –Src & Dest Port (16 bits each) –32-bit sequence #, ACK # (byte stream) –4-bit Header Length (in 32-bit words) –Reserved (6 bits) –Flags (6 bits) –16-bit Window size (bytes willing to Rx) –Checksum (16 bits) –Urgent pointer –Options (0 or more 32-bit words)
13
CEN 5501C - Computer Networks - Spring 2007 - UF/CISE - Newman13 TCP Flags URG –Urgent pointer valid (offset in current segment) ACK – ACK field is valid PSH – deliver immediately (don’t buffer) RST – Reset connection (abort) SYN – Synchronize (3-way handshake) FIN – Finish (normal close connection)
14
CEN 5501C - Computer Networks - Spring 2007 - UF/CISE - Newman14 TCP Session Initiation Syn, X, - Syn, ACK, Y, X+1 ACK, X+1, Y+1 Host AHost B Normal Three-way Handshake -Client makes connection req -Server responds (half-open Connection now) -Client confirms -Data transfer begins -Syn Flooding Attack…
15
CEN 5501C - Computer Networks - Spring 2007 - UF/CISE - Newman15 TCP Initiation Mishaps Syn, X, - Syn, ACK, Y, X+1 Host A Host B Syn, Y, - Syn, ACK, X, Y+1 Call Collision Syn, ACK, W, Z+1 RST Unknown/Late
16
CEN 5501C - Computer Networks - Spring 2007 - UF/CISE - Newman16 TCP States CLOSED – no active/pending connection LISTEN – server waits for incoming call SYN RCVD – connection req received, wait for ACK SYN SENT – connection requested, wait for SYN-ACK ESTAB – normal data transfer state FIN WAIT 1 – application has said it’s done (active) FIN WAIT 2 – other side has agreed to release (active) TIMED WAIT – wait for all packets to die off (active) CLOSING – both sides closed simultaneously (active) CLOSE WAIT – other side initiated a release (passive) LAST ACK – wait for all packets to die off (passive)
17
CEN 5501C - Computer Networks - Spring 2007 - UF/CISE - Newman17 TCP State Machine - Open SYN/SYN-ACK ESTABLISHED CLOSED LISTEN SYN SENT SYN RCVD SYN-ACK/ACK Connect/SYN Send/SYN Close/- Listen/- RST/- SYN/SYN-ACK ACK/- Close/FIN FIN WAIT 1 Normal Server Normal Client Unusual
18
CEN 5501C - Computer Networks - Spring 2007 - UF/CISE - Newman18 TCP State Machine - Close ESTABLISHED CLOSED CLOSINGCLOSE WAIT SYN RCVD FIN-ACK/ACK ACK/- (Timeout) FIN/ACK Close/FIN FIN WAIT 1 Close/FIN FIN WAIT 2 FIN/ACK TIMED WAIT ACK/- LAST ACK FIN/ACK Close/FIN ACK/- [Active Close] [Passive Close]
19
CEN 5501C - Computer Networks - Spring 2007 - UF/CISE - Newman19 TCP Transmission Policy Sender not required to send as soon as application delivers data Windows not tied directly to ACKs, but also to receive window size Receiver may ACK when segt received, when receive window changes, etc.
20
CEN 5501C - Computer Networks - Spring 2007 - UF/CISE - Newman20 TCP Transmission Example empty 2K Appl writes 2 K bytes 2K, seq=0 Receiver’s 4K buffer 04K ACK=2048, WIN=2048 Appl writes 3 K bytes 2K, seq=2048 ACK=4096, WIN=0 Sender may send up to 2 K bytes 1K, seq=4096 ACK=4096, WIN=2048 Sender blocked 2K Full 2K Appl reads 2 K bytes 1K ACK=5020, WIN=1024
21
CEN 5501C - Computer Networks - Spring 2007 - UF/CISE - Newman21 TCP Telnet Example Interactive editor – reacts on every keystroke Sender sends each character on arrival –41 bytes (1 char + 20 TCP + 20 IP) Receiver sends 40-byte ACK Editor reads byte, Rx updates WIN (40 more) Editor processes character, echoes it –41 more bytes! Total of 162 bytes in 4 datagrams per char!!
22
CEN 5501C - Computer Networks - Spring 2007 - UF/CISE - Newman22 TCP Solution Delayed ACKs can alleviate this Wait 500 ms before sending ACK Gives time for read, echo, so only 1 DG sent –Ack timer needed, reverse flow trigger –Also trigger ACK on second segment arrival Still inefficient (82 bytes in 2 DGs) Nagle’s Algorithm helps further!
23
CEN 5501C - Computer Networks - Spring 2007 - UF/CISE - Newman23 Nagle’s Algorithm Sender side solution When data arrives one byte at a time, send first byte, then buffer rest until ACKed When ACK arrives, or when MSS can be filled, or if half WIN filled, send all chars in buffer in a single segment Huge bandwidth savings! Widely used. Disable if using mouse, avoid jerkiness
24
CEN 5501C - Computer Networks - Spring 2007 - UF/CISE - Newman24 Silly Window Syndrome Receiver’s buffer Sender sends 1 byte room for 1 byte Full 40 bytes ACK Appl reads 1 byte 40 bytes hdrs 1 byte of data Full
25
CEN 5501C - Computer Networks - Spring 2007 - UF/CISE - Newman25 Clark’s Solution Prevent Rx from sending window update for one byte Rx forced to wait until WIN >= MSS, or buffer is half empty, whichever is smaller Sender should not send tiny segments Wait until full MSS or half receiver’s buffer size, whichever smaller
Similar presentations
© 2024 SlidePlayer.com. Inc.
All rights reserved.