Upload
clinton-cox
View
101
Download
9
Tags:
Embed Size (px)
DESCRIPTION
Chapter 4 Transport Layer. CIS 81 Networking Fundamentals Rick Graziani Cabrillo College [email protected] Spring 2010. This Presentation. For a copy of this presentation and access to my web site for other CCNA, CCNP, and Wireless resources please email me for a username and password. - PowerPoint PPT Presentation
Citation preview
Chapter 4Transport Layer
CIS 81 Networking Fundamentals
Rick Graziani
Cabrillo College
Spring 2010
2
This Presentation
For a copy of this presentation and access to my web site for other CCNA, CCNP, and Wireless resources please email me for a username and password. Email: [email protected] Web Site: www.cabrillo.edu/~rgraziani
3
Note
This presentation is not in the order of the book or online curriculum. This presentation also contains information beyond the curriculum.
Transport Layer Overview
5
Transport Layer
Transport Layer: Responsible for creating and maintaining a logical connection
between the endpoints What are the two protocols at the transport layer?
TCP – Transmission Control Protocol UDP – User Datagram Protocol
TCP UDP
6
Application Header + data
TCP Header UDP Header
or
PDU: Segment
PDU: Data
What is the application PDU called?
What is the transport PDU called?
7
UDP
TCP
TCP/UDP TCP/UDP
The Layer 4 data stream is a: Logical connection between the endpoints Provides transport services
End-to-end service
8
DataHTTP Header
TCP Header
IP Header
Data Link Header
Data Link Trailer
IP PacketData Link Header
Data Link Trailer
IP PacketData Link Header
Data Link Trailer
IP PacketData Link Header
Data Link Trailer
IP PacketData Link Header
Data Link Trailer
IP PacketData Link Header
Data Link Trailer
IP PacketData Link Header
Data Link Trailer
DataHTTP Header
TCP Header
IP Header
Data Link Header
Data Link Trailer
Reminder of encapsulation/decapsulation
9
Focus on Transport LayerTCP
TCP
10
Primary responsibilities: Tracking the individual communication between applications
Who is the client? Which application? Which process? Identifying the different applications (HTTP, FTP, etc.)
Segmenting data Managing each segment Reassembling the segments
Transport Layer
www.cisco.com
TCP Segment
TCP Segment
TCP Segment
TCP Segment
11
What two protocols are at the Transport Layer? TCP UDP
IP is a best-effort delivery service. What does that mean? No guarantees Best-effort service “Unreliable service”
TCP/UDP is responsible for extending IP’s delivery service between two end systems.
segment segment
12
TCP vs. UDP
TCP provides: Reliable delivery Error checking Flow control Congestion control Ordered delivery Connection establishment Applications:
HTTP FTP SMTP Telnet MSN messenger
UDP provides: Unreliable delivery No error checking No flow control No congestion control No ordered delivery No connection establishment Applications
DNS (usually) DHCP RTP (Real-Time Protocol) VoIP
Why would any application use UDP? What is the “cost” of all this reliability and flow control of TCP?
Streaming media, real-time multiplayer games and voice over IP (VoIP) applications that do not require reliability mechanisms and may even be hindered by them.
13
A single client may have multiple transport connections with multiple servers.
Notice that TCP is a connection-oriented service (two-way arrow) between the hosts, whereas UDP is a connectionless service (one-way arrow) . (later)
TCPTCP
TCP
TCP
TCP
TCP
HTTPHTTP
FTP
TCP
SMTP
TCP
Cabrillo Web Server
ISP’s Email and FTP Server
Port Numbers: TCP and UDP
15
Both TCP and UDP use ports (or sockets) numbers to pass information to the upper layers.
0 15 16 31
16-bit Source Port Number
16-bit Destination Port Number
32-bit Sequence Number
32 bit Acknowledgement Number
4-bit Header Length
6-bit (Reserved)
URG
ACK
PSH
RST
SYN
FIN
16-bit Window Size
16-bit TCP Checksum
16-bit Urgent Pointer
Options (if any)
Data (if any)
TCP Header
HTTP is Port 80
UDP Header
16
The application this TCP segment came from.
The application this TCP segment is going to.
The application this TCP segment came from.
The application this TCP segment is going to.
17
Application Header + dataPort numbers are used by
the receiver so it knows which application it should
send the “Data” to.
Application Header + dataPort numbers are used to
by the sender to tell the receiver which network
application it should use for the “Data”.
Port Number
Port Number
18
http://www.iana.org/assignments/port-numbers
The Internet Assigned Numbers Authority (IANA) assigns port numbers.
19
Well Known Ports (Numbers 0 to 1023) Reserved for common services and
applications Client: TCP destination port Server: TCP source port
Well Known or Registered Port Number
Well Known or Registered Port Number
20
Well Known or Registered Port Number
Well Known or Registered Port Number
Registered Ports (Numbers 1024 to 49151) Assigned to user processes or
applications. Non-common applications.
Client: TCP destination port Server: TCP source port
May also be used as dynamic or private port (next).
21
Dynamic or Private Ports (Numbers 49152 to 65535) Also known as Ephemeral Ports Usually assigned dynamically to client applications when initiating a
connection. Client: TCP source port Server: TCP destination port
May also include the range of Registered Ports (Numbers 1024 to 49151)
Well Known or Registered Port Number
Private/Dynamic Port Number
Well Known or Registered Port Number
Private/Dynamic Port Number
22
Client Server
Telnet
23
Client sends TCP segment with: Destination Port: 23 (Well known port number) Source Port: 1028 (Dynamic Port assigned by client)
Client TCP Header0 15 16 31
16-bit Source Port Number
16-bit Destination Port Number
32-bit Sequence Number
32 bit Acknowledgement Number
4-bit Header Length
6-bit (Reserved)
URG
ACK
PSH
RST
SYN
FIN
16-bit Window Size
16-bit TCP Checksum
16-bit Urgent Pointer
Options (if any)
Data (if any)
231028
Data for Telnet
Client Server
24
Server responds with TCP segment with: Destination Port: 1028 (Dynamic Port assigned by client) Source Port: 23 (Well known port number)
Server TCP Header0 15 16 31
16-bit Source Port Number
16-bit Destination Port Number
32-bit Sequence Number
32 bit Acknowledgement Number
4-bit Header Length
6-bit (Reserved)
URG
ACK
PSH
RST
SYN
FIN
16-bit Window Size
16-bit TCP Checksum
16-bit Urgent Pointer
Options (if any)
Data (if any)
102823
Data for Telnet
Client Server
25
Notice the difference in how source and destination port numbers are used with clients and servers:
Client (initiating Telnet service): Destination Port = 23 (telnet) Source Port = 1028 (dynamically assigned)
Server (responding to Telnet service): Destination Port = 1028 (source port of client) Source Port = 23 (telnet)
26
Same client to same server - Two different HTTP sessions Client: Same destination port Client: Different source ports to uniquely identify this web session.
4989049888
27
C:\Users\rigrazia>netstat -n
Active Connections
Proto Local Address Foreign Address State TCP 192.168.1.101:49888 198.133.219.25:80 TIME_WAIT TCP 192.168.1.101:49890 198.133.219.25:80 TIME_WAIT
C:\Users\rigrazia>
TCP or UDP
Source Port
Destination IP
Destination Port Connection State
Source IP
4989049888
28
What makes each connection unique? How does the server know which source port 49888 is who?
Connection defined by the pair of numbers: Source IP address, Source port (From Client to Server) Destination IP address, Destination port (From Server to
Client) Different connections can use the same destination port on server
host as long as the source ports or source IPs are different.
192.168.1.101
172.16.5.5
Destination Port
8080
80
Source Port
49890
49888
Source Port
198.133.219.2549888
www.cisco.com
29
Note: When downloading a web document and its objects it is common that there will be several TCP sessions created.
netstat –n www.cisco.comwww.google.com
TCP or UDP Source Port
Destination IPDestination Port
Connection StateSource IP
30
Using NetStat
Open a web browser. Open a command prompt window (Start->Run->cmd) Enter a URL of your choice. Type netstat –n in the command window. Questions:
What is/are the source ports on your client? What is/are the destination ports on your client? What would be the source port(s) on the server? What would be the destination port(s) on the server? What application layer protocol is being used? How can you tell? What transport layer protocol is being used?
Trying more at home: Use netstat to look at other networking applications such as FTP
or Telnet.
Connectionless Transport: UDP
32
UDP
What do you notice looking at the UDP protocol? No frills, barebones transport protocol.
Destination and Source Ports Length and Checksum (used for error checking)
RFC 768 Connectionless transport
No “handshaking” (no connection establishment) as with TCP (coming) Unreliable delivery No error checking No flow control No congestion control No ordered delivery
0 15 16 31
16-bit Source Port Number
16-bit Destination Port Number
16-bit UDP Length
16-bit UDP Checksum
Data (if any)
?
33
UDP
source port -- the number of the calling port destination port -- the number of the called port UDP length -- the length of the UDP header checksum -- the calculated checksum of the header and data fields data -- upper-layer protocol data
0 15 16 31
16-bit Source Port Number
16-bit Destination Port Number
16-bit UDP Length
16-bit UDP Checksum
Data (if any)
34
UDP
Why would an application developer choose UDP rather than TCP? Finer application-layer control
TCP will continue to resend segments that are not acknowledged. Applications that use UDP can tolerate some data loss:
Streaming video VoIP (Voice over IP)
Application decides whether or not to resend entire file: TFTP
0 15 16 31
16-bit Source Port Number
16-bit Destination Port Number
16-bit UDP Length
16-bit UDP Checksum
Data (if any)
35
UDP
No connection establishment TCP uses a three-way handshake to establish a connection (coming) UDP does not – it just blasts away the data to the sender. No delay to establish connection.
0 15 16 31
16-bit Source Port Number
16-bit Destination Port Number
16-bit UDP Length
16-bit UDP Checksum
Data (if any)
Time
UDP segmentUDP segmentUDP segmentUDP segment
Client Server
36
UDP
No connection state UDP does not maintain connection state as does TCP (coming)
Used for reliability and flow control. Server can support more active clients when not maintaining state
information Small packet header overhead
TCP header has 20 bytes of overhead. UDP header has only 8 bytes of overhead
0 15 16 31
16-bit Source Port Number
16-bit Destination Port Number
16-bit UDP Length
16-bit UDP Checksum
Data (if any)
Time
UDP segmentUDP segmentUDP segmentUDP segment
Client Server
37
Note on UDP
Note: Multimedia Applications and UDP There is an issue (controversy) with multimedia applications over UDP. UDP offers no congestion control (as we will see with TCP) Congestion control is needed to prevent the network from entering and
staying in a congested state. If all applications were using UDP, because of congestion, very few
UDP packets would be delivered and this would also cause TCP traffic rates to dramatically decrease.
Many applications give you a choice of TCP or UDP.
38
Online Gaming
Game data – Server and client need make sure all data (moves, actions, etc) reach the other end reliably.
Voice chat – Some missing data can be tolerated (up to a point). Retransmission would cause delay.
Question: Do the World of Warcraft servers use TCP or UDP?
Answer: TCP for game data, UDP for voice chat.
Why?
39
UDP Checksum (FYI)
UDP checksum provides error detection, any changed bits or missing segments. Simplified explanation (see RFC 1071 for more details): Sender
UDP adds 16 bit ‘words’ keeping a cumulative sum. Performs one's complement of the sum of all the 16-bit words in the segment.
Convert 0’s to 1’s and 1’s to 0’s This result is put in the checksum field of the UDP segment.
Receiver UDP adds 16 bit ‘words’ keeping a cumulative sum Adds 1’s (ones) complement If no errors are introduced into the segment, then the Total at the receiver will be
1111111111111111.
0 15 16 31
16-bit Source Port Number
16-bit Destination Port Number
16-bit UDP Length
16-bit UDP Checksum
Data (if any)
Time
UDP segmentUDP segmentUDP segmentUDP segment
Client Server
Cumulative Sum: 1100101011001010
1s complement: 0011010100110101
Total: 1111111111111111
Final Checksum
40
UDP Checksum (FYI)
What if there is an error? UDP does nothing to recover the error. It is up to the application layer protocol (example TFTP) to decide what to do,
such as prompt the user to download/upload the entire file again.
0 15 16 31
16-bit Source Port Number
16-bit Destination Port Number
16-bit UDP Length
16-bit UDP Checksum
Data (if any)
Time
UDP segmentUDP segmentUDP segmentUDP segment
Client Server
Cumulative Sum: 1100101011001010
1s complement: 0011000100110101
Total: 1111101111111111
Final Checksum
41
Connection-oriented Transport: TCP
43
TCP
TCP provides reliable delivery on top of unreliable IP TCP provides:
Reliable delivery Error checking Flow control Congestion control Ordered delivery Connection establishment
0 15 16 31
16-bit Source Port Number
16-bit Destination Port Number
32-bit Sequence Number
32 bit Acknowledgement Number
4-bit Header Length
6-bit (Reserved)
URG
ACK
PSH
RST
SYN
FIN
16-bit Window Size
16-bit TCP Checksum
16-bit Urgent Pointer
Options (if any)
Data (if any)
44
TCP
source port -- the number of the calling port destination port -- the number of the called port sequence number -- the number used to ensure correct sequencing of the arriving
data acknowledgment number -- the next expected TCP octet HLEN -- the number of 32-bit words in the header reserved -- set to 0 code bits -- the control functions (e.g. setup and termination of a session) window -- the number of octets that the sender is willing to accept checksum -- the calculated checksum of the header and data fields urgent pointer -- indicates the end of the urgent data option -- one currently defined: maximum TCP segment size data -- upper-layer protocol data
0 15 16 31
16-bit Source Port Number
16-bit Destination Port Number
32-bit Sequence Number
32 bit Acknowledgement Number
4-bit Header Length
6-bit (Reserved)
URG
ACK
PSH
RST
SYN
FIN
16-bit Window Size
16-bit TCP Checksum
16-bit Urgent Pointer
Options (if any)
Data (if any)
45
TCP: Connection Establishment
For a connection to be established, the two end stations must synchronize on each other's TCP initial sequence numbers (ISNs).
Sequence numbers : Track the order of packets Ensure that no packets are lost in transmission.
The initial sequence number is the starting number used when a TCP connection is established.
Exchanging beginning sequence numbers during the connection sequence ensures that lost data can be recovered.
0 15 16 31
16-bit Source Port Number
16-bit Destination Port Number
32-bit Sequence Number
32 bit Acknowledgement Number
4-bit Header Length
6-bit (Reserved)
URG
ACK
PSH
RST
SYN
FIN
16-bit Window Size
16-bit TCP Checksum
16-bit Urgent Pointer
Options (if any)
Data (if any)
46
Three-way Handshake
Step 1: The three-way handshake happens before any data, HTTP Request (GET),
is sent by the client. A TCP client begins the three-way handshake by sending a segment with
the SYN (Synchronize Sequence Number) control flag set, indicating an initial value in the sequence number field in the header.
The sequence number is the Initial Sequence Number (ISN), is randomly chosen and is used to begin tracking the flow of data from the client to the server for this session.
Client
SYN, SEQ=8563
SYN Received
Web Server
Note: ISNs do not start a 0 or 1. There are several reasons for this including segments that may still be in buffers and also security issues. (Beyond the scope of this presentation.)
0 15 16 31
16-bit Source Port Number
16-bit Destination Port Number
32-bit Sequence Number
32 bit Acknowledgement Number
4-bit Header Length
6-bit (Reserved)
URG
ACK
PSH
RST
SYN
FIN
16-bit Window Size
16-bit TCP Checksum
16-bit Urgent Pointer
Options (if any)
Data (if any)
47
Three-way Handshake
Step 2: The TCP server needs to acknowledge the receipt of the SYN segment. Server sends a segment back to the client with:
ACK flag set indicating that the Acknowledgment number is significant. The value of the acknowledgment number field is equal to the client
initial sequence number plus 1. This is called an expectational acknowledgement – the next byte
this host expects to receive (more soon). SYN flag is set with its own random ISN for the Sequence number
Client
SYN, SEQ=8563
SYN, ACK, SEQ=1678 ACK=8564
SYN Received
SYN, ACK Received
Web Server
0 15 16 31
16-bit Source Port Number
16-bit Destination Port Number
32-bit Sequence Number
32 bit Acknowledgement Number
4-bit Header Length
6-bit (Reserved)
URG
ACK
PSH
RST
SYN
FIN
16-bit Window Size
16-bit TCP Checksum
16-bit Urgent Pointer
Options (if any)
Data (if any)
48
Three-way Handshake
Step 3: TCP client responds with a segment containing an ACK that is the
response to the TCP SYN sent by the server. The value in the acknowledgment number field contains one more than the
initial sequence number received from the server. The client can now send application data encapsulated in TCP segment.
HTTP Request (GET)
Client
SYN, SEQ=8563
SYN, ACK, SEQ=1678 ACK=8564
ACK, SEQ=8564 ACK=1679
SYN Received
SYN, ACK Received
ACK Received
Web Server
HTTP Request (GET)
0 15 16 31
16-bit Source Port Number
16-bit Destination Port Number
32-bit Sequence Number
32 bit Acknowledgement Number
4-bit Header Length
6-bit (Reserved)
URG
ACK
PSH
RST
SYN
FIN
16-bit Window Size
16-bit TCP Checksum
16-bit Urgent Pointer
Options (if any)
Data (if any)
49 Step 1: Client sends ISN, SEQ=8563 (last four digits)
50 Step 2: Server responds with ACK=8564, own ISN, SEQ=1678
51 Step 3: Client sends ACK=1679
52 Client now sends HTTP Request (GET) to Web Server
53
TCP: Connection Termination
1. When the client has no more data to send in the stream, it sends a segment with the FIN flag set.
2. The server sends an ACK to acknowledge the receipt of the FIN to terminate the session from client to server.
3. The server sends a FIN to the client, to terminate the server to client session.
4. The client responds with an ACK to acknowledge the FIN from the server.
0 15 16 31
16-bit Source Port Number
16-bit Destination Port Number
32-bit Sequence Number
32 bit Acknowledgement Number
4-bit Header Length
6-bit (Reserved)
URG
ACK
PSH
RST
SYN
FIN
16-bit Window Size
16-bit TCP Checksum
16-bit Urgent Pointer
Options (if any)
Data (if any)
54
Packet Tracer Exercise: TCP Connection and Termination
Use your file for the Packet Tracer lab: PT-DHCP-DNS-HTTP Open Packet Tracer (wait for green lights then click on Simulation mode) Edit Filters: TCP, DNS, HTTP On a client, open a web browser and type www.cabrillo.edu Click Capture/Forward to watch the packets and examine the protocols. Why didn’t a TCP 3-way handshake happen before the client sent a DNS
request to the DNS server? Why did a TCP 3-way handshake happen before the client sent a HTTP
Request message to the web server?
55
Flow Control and Reliability
Reliability Guaranteed delivery
Flow Control Flow control makes sure these buffers do not receive more data than
the connection can handle.
0 15 16 31
16-bit Source Port Number
16-bit Destination Port Number
32-bit Sequence Number
32 bit Acknowledgement Number
4-bit Header Length
6-bit (Reserved)
URG
ACK
PSH
RST
SYN
FIN
16-bit Window Size
16-bit TCP Checksum
16-bit Urgent Pointer
Options (if any)
Data (if any)
56
Flow Control and Reliability This window size specifies the number of bytes, starting with the
acknowledgment number, that the receiving host's TCP layer is currently prepared to receive.
Included in every TCP segment starting with three-way handshake. TCP is a full duplex service
Client and server specify their own window sizes.
0 15 16 31
16-bit Source Port Number
16-bit Destination Port Number
32-bit Sequence Number
32 bit Acknowledgement Number
4-bit Header Length
6-bit (Reserved)
URG
ACK
PSH
RST
SYN
FIN
16-bit Window Size
16-bit TCP Checksum
16-bit Urgent Pointer
Options (if any)
Data (if any)
Client Window Size=5,000
Server Window
Size=10,000
57
Receive Window Sending host can send only that amount of data before getting an acknowledgment and
window update from this (the receiving) host. Send Window (not a TCP field) The TCP Receive Window size of the other host.Client Example Receive Window Size=5,000 bytes – Server can only send 5,000 bytes before it receives
an acknowledgement. Send Window Size = 10,000 bytes – Server told the client that it can send the server
10,000 bytes before receiving an acknowledgment.
Client Window Size=5,000
Server Window
Size=10,000Server’s Send Window: 10,000
My Receive Window: 10,000My Receive
Window: 5,000
Client’s Send Window: 5,000
“I can send 10,000 bytes without hearing an ACK, and I can only receive 5,000 bytes at a time.”
“I can send 5,000 bytes without hearing an ACK, and I can only receive 10,000 bytes at a time.”
58
Flow Control and ReliabilityApplication Data (100,000 bytes)
1-1000 1001-2000 2001-3000 3001-4000 4001-5000
Flow control and reliability are intertwined . When TCP has a large file (such an image) it breaks it into equal chunks, with the last
chunk typically smaller. Each chunk of data with TCP header is known as a segment. The size of the chunk is known as the MSS (Maximum Segment Size)
TCP Options field (later) In the following example:
Web Server has a: MSS of 1000 bytes (To be completely accurate in the diagram the MSS would
include the data plus the TCP header.) Client
Window Size of 5,000 bytes
…
TCP 1-1000 TCP Segment
59
Sequence Number and Acknowledgements Remote host sends TCP segments with a Sequence Number.
Note: This is the first byte in the of data in the segment.
0 15 16 31
16-bit Source Port Number
16-bit Destination Port Number
32-bit Sequence Number
32 bit Acknowledgement Number
4-bit Header Length
6-bit (Reserved)
URG
ACK
PSH
RST
SYN
FIN
16-bit Window Size
16-bit TCP Checksum
16-bit Urgent Pointer
Options (if any)
Data (if any)
60
This is known as a Stop-and-Wait windowing protocol.
Server must wait for acknowledgment before continuing to send data.
A better method? Sliding Windows
Next! Send Window Byte:
This is the last byte that can be sent before receiving an ACK
Client
SEQ=1,001 (to 2,000)
Web Server
SEQ=2,001 (to 3,000)
SEQ=3,001 (to 4,000)
SEQ=4,001 (to 5,000)
ACK=5,001
SEQ=1 (to 1,000)
SEQ=6,001 (to 7,000)
SEQ=7,001 (to 8,000)
SEQ=8,001 (to 9,000)
SEQ=9,001 (to 10,000)
ACK=10,001
SEQ=5,001 (to 6,000)
….
Client Window Size=5,000
Client Window Size=5,000
Server Window
Size=10,000
Server Window
Size=10,000…
…
Send Window: Byte 10,000
Send Window: Byte 15,000
Server Window
Size=10,000
…SEQ=10,001 (to 11,000)
Send Window=5,000
Client has a Window Size of 5,000 bytes
Client Window Size=5,000
MSS of 1,000 bytes
61
TCP Window Size TCP provides full-
duplex service, which means data can be flowing in each direction, independent of the other direction.
Receiver sends acceptable window size to sender during each segment transmission (flow control)
If too much data being sent, acceptable window size is reduced
If more data can be handled, acceptable window size is increased
Client
SEQ=1,001 – 2,000
Web Server
SEQ=2,001 – 3,000SEQ=3,001 – 4,000SEQ=4,001 – 5,000
ACK=5,001
SEQ=1 – 1,0001
SEQ=6,001 – 7,000SEQ=7,001 – 8,000SEQ=8,001 – 9,000SEQ=9,001 – 10,000
ACK=10,001
SEQ=5,001 – 6,000
….
Client Window Size=5,000
Client Window Size=5,000
Server Window
Size=10,000
Server Window
Size=10,000
…
…
Send Window: Byte 10,000
Send Window: Byte 15,000
Server Window
Size=10,000
…SEQ=10,001 – 11,000
Send Window=5,000
62
Sliding Window Protocol Sliding window algorithms are a method of flow control for network data transfers using
the receivers Window size. The sender computes its usable window, which is how much data it can immediately
send. Over time, this sliding window moves to the rights, as the receiver acknowledges data. The receiver sends acknowledgements as its TCP receive buffer empties. The terms used to describe the movement of the left and right edges of this sliding
window are:1. The left edge closes (moves to the right) when data is sent and acknowledged.2. The right edge opens (moves to the right) allowing more data to be sent. This happens
when the receiver acknowledges a certain number of bytes received.3. The middle edge open (moves to the right) as data is sent, but not yet acknowledged.
Octets sent
Not ACKed
Usable Window
Can send ASAP
Working Window size
Usable Window
Can send ASAP
Initial Window size
Sliding Windows
63
1 2 3 4 5 6 7 8 9 10 11 12 13
2
3
Host B gives Host A a window size of 6 (octets). Host A begins by sending octets to Host B: octets 1, 2, and 3 and slides it’s
window over showing it has sent those 3 octets. Host A will not increase its usable window size by 3, until it receives an
ACKnowldegement from Host B that it has received some or all of the octets. Host B, not waiting for all of the 6 octets to arrive, after receiving the third octet
sends an expectational ACKnowledgement of “4” to Host A.
ACK 4
Octets sent
Not ACKed
Usable Window
Can send ASAP
Window size = 6 Octets received
1 2 3 4 5 6 7 8 9 10 11 12 13 1 2 3 4 5 6 7 8 9 10 11 12 13
1 2 3 4 5 6 7 8 9 10 11 12 13
1
Host A - Sender Host B - Receiver
0 15 16 31
16-bit Source Port Number
16-bit Destination Port Number
32-bit Sequence Number
32 bit Acknowledgement Number
4-bit Header Length
6-bit (Reserved)
URG
ACK
PSH
RST
SYN
FIN
16-bit Window Size
16-bit TCP Checksum
16-bit Urgent Pointer
Options (if any)
Data (if any)
TCP Header
64
1 2 3 4 5 6 7 8 9 10 11 12 13
1 2 3 4 5 6 7 8 9 10 11 12 13
2
3
ACK 4
Host A does not have to wait for an acknowledgement from Host B to keep sending data, not until the window size reaches the window size of 6, so it sends octets 4 and 5.
Host A receives the acknowledgement of ACK 4 and can now slide its window over to equal 6 octets, 3 octets sent – not ACKed plus 3 octets which can be sent asap.
4
5
1 2 3 4 5 6 7 8 9 10 11 12 13
1 2 3 4 5 6 7 8 9 10 11 12 13
ACK 6
Octets sent
Not ACKed
Usable Window
Can send ASAP
Window size = 6
1
1 2 3 4 5 6 7 8 9 10 11 12 13 1 2 3 4 5 6 7 8 9 10 11 12 13
1 2 3 4 5 6 7 8 9 10 11 12 13
Host B - ReceiverHost A - Sender
65
1 2 3 4 5 6 7 8 9 10 11 12 13
1 2 3 4 5 6 7 8 9 10 11 12 13
2
3
ACK 4
More sliding windows
4
5
1 2 3 4 5 6 7 8 9 10 11 12 13
1 2 3 4 5 6 7 8 9 10 11 12 13
ACK 6
Octets sent
Not ACKed
Usable Window
Can send ASAP
1 2 3 4 5 6 7 8 9 10 11 12 13
7
6
9
8
1 2 3 4 5 6 7 8 9 10 11 12 13
1 2 3 4 5 6 7 8 9 10 11 12 13
1 2 3 4 5 6 7 8 9 10 11 12 13
1 2 3 4 5 6 7 8 9 10 11 12 13
1 2 3 4 5 6 7 8 9 10 11 12 13 1 2 3 4 5 6 7 8 9 10 11 12 13
1 2 3 4 5 6 7 8 9 10 11 12 13
1
Host B - ReceiverHost A - Sender
Window size = 6
66
Default 8K for Windows, 32K for Linux, There are various unix/linux/microsoft programs that allow you to modify the default
window size. I do not recommend that you mess around with this unless you know what you are doing. “Disclaimer: Modifying the registry can cause serious problems that may
require you to reinstall your operating system. We cannot guarantee that problems resulting from modifications to the registry can be solved. Use the information provided at your own risk.”
NOTE: I take no responsibility for this software or any others!
67
Client
SEQ=1,001 – 2,000
Web Server
SEQ=2,001 – 3,000
SEQ=3,001 – 4,000
SEQ=4,001 – 5,000
ACK=2,001
SEQ=1 – 1,000
SEQ=6,001 – 7,000
SEQ=7,001 – 8,000
SEQ=8,001 – 9,000
SEQ=9,001 – 10,000
Etc.
SEQ=5,001 – 6,000
ACK=6,001
Web Server has a: MSS of 1000 bytes
Client has a Window Size of 5,000 bytes
Send Window: Byte 5,000
Send Window: Byte 7,000 2,001 to 7,000
Send Window: Byte 11,000 6,001 to 11,000
Server can now continue sending without having to wait for an acknowledgement.
Send Window Byte: This is the last byte that can be sent before receiving an ACK
Send Window=5,000
68
Reliable Data Transfer
TCP’s reliable data service is on top of IP’s unreliable, best-effort service. TCP uses a single retransmission timer for all of it’s segments within a
TCP connection. How this timer is calculated is beyond the scope of this presentation (too
many slides already ) See RFC 2988
The TCP retransmission timer is associated with the oldest unacknowledged segment sent.
We will see three simple examples to explain how this works. The last two examples are FYI.
My reliable puppy Luigi
69
Client Web Server
Web Server sends data. Starts TCP retransmission
timer. Client:
Segment received Sends ACK But ACK from Client gets
lost (dropped somewhere) Web Server
Waiting for ACK. TCP Retransmission
Timer expires. Retransmits segment.
Client Receives segment but
discards it. Resends ACK
Web Server Receives ACK
SEQ=92, 8 bytes data
ACK=100
X (loss)
Timeout
SEQ=92, 8 bytes data
ACK=100
(TCP Retransmission Timer)
Scenario 1: Loss of an ACK
70
Client Web Server Web Server:
Sends 2 segments Starts timer for oldest segment,
SEQ=92 Waits for ACK
Client: Receives both segments Sends 2 separate ACKs
Web Server: Neither ACK has arrived yet Timer for SEQ=92 expires Resends segment SEQ=92 Restarts timer for SEQ=92 As long as the ACK for the second
segment arrives before the new timeout expires, the second segment will not be retransmitted.
Client: Receives retransmitted SEQ=92
segment. Discards segment Re-sends ACK=120 for next byte
needed
SEQ=92, 8 bytes data
ACK=100
seq 92 Timeout
ACK=120
SEQ=100, 20 bytes data
ACK=120
SEQ=92, 8 bytes data
seq 92 Timeout
(TCP Retransmission Timer)
This ACK tells the Web Server that both segments have been received.
FYI Scenario 2: ACK arrives after timer expires
71
Client Web Server Web Server:
Sends 2 segments Starts timer for oldest segment, SEQ=92 Waits for ACK
Client: Receives both segments Sends 2 separate ACKs ACK for first segment, ACK=100, is lost
Web Server: Before timer expires for SEQ=92 ACK
(ACK=100), receives ACK=120 Web Server knows that Client has
received everything up to byte 119. Does not need to resend either of the two
segments.
SEQ=92, 8 bytes data
seq 92 Timeout
SEQ=100, 20 bytes data
ACK=120
(TCP Retransmission Timer)
FYI Scenario 3: Loss of first ACK
ACK=100
X (loss)
72
A few more notes on Window Size, Timers, etc.
Both hosts in the TCP connection constantly advertise their Window Size to the remote host in each segment sent. Remember, TCP is a full duplex service – data can be sent and received in
both directions. Receive Window Size may be increased or decreased due to flow control
(buffers) or congestion (network). The effects on TCP are very similar.
0 15 16 31
16-bit Source Port Number
16-bit Destination Port Number
32-bit Sequence Number
32 bit Acknowledgement Number
4-bit Header Length
6-bit (Reserved)
URG
ACK
PSH
RST
SYN
FIN
16-bit Window Size
16-bit TCP Checksum
16-bit Urgent Pointer
Options (if any)
Data (if any)
0 15 16 31
16-bit Source Port Number
16-bit Destination Port Number
32-bit Sequence Number
32 bit Acknowledgement Number
4-bit Header Length
6-bit (Reserved)
URG
ACK
PSH
RST
SYN
FIN
16-bit Window Size
16-bit TCP Checksum
16-bit Urgent Pointer
Options (if any)
Data (if any)
73
A few more notes on Window Size, Timers, etc.
The host may reduce it’s Window Size if: ACKs not arriving before retransmission timer expires or not arriving at all.
This may also cause the host to increase it’s retransmission timer interval.
Could be a sign of congestion. Receive buffers are decreasing, filling up.
The host may increase it’s Window Size if: ACKs are received before retransmission timer expires Receive buffers are increasing, less bits to process.
0 15 16 31
16-bit Source Port Number
16-bit Destination Port Number
32-bit Sequence Number
32 bit Acknowledgement Number
4-bit Header Length
6-bit (Reserved)
URG
ACK
PSH
RST
SYN
FIN
16-bit Window Size
16-bit TCP Checksum
16-bit Urgent Pointer
Options (if any)
Data (if any)
0 15 16 31
16-bit Source Port Number
16-bit Destination Port Number
32-bit Sequence Number
32 bit Acknowledgement Number
4-bit Header Length
6-bit (Reserved)
URG
ACK
PSH
RST
SYN
FIN
16-bit Window Size
16-bit TCP Checksum
16-bit Urgent Pointer
Options (if any)
Data (if any)
74
Client
SEQ=1,001 – 2,000
Web Server
SEQ=2,001 – 3,000
SEQ=3,001 – 4,000
SEQ=4,001 – 5,000
ACK=2,001 Window=7,000
SEQ=1 – 1,000
SEQ=6,001 – 7,000
SEQ=7,001 – 8,000
SEQ=8,001 – 9,000
SEQ=9,001 – 10,000
Etc.
SEQ=5,001 – 6,000
ACK=6,001 Window=9,000
Web Server has a: MSS of 1000 bytes
Client has an initial Window Size of 5,000 bytes
SEQ=10,001 – 11,000
Send Window: Byte 5,000
Send Window: Byte 9,000 2,001 to 9,000 (Win=7,000)
Send Window: Byte 15,000 6,001 to 15,000 (Win=9,000)
Client increases its Window Size. Send Window Byte: This is the last byte that can be sent before receiving an
ACK
Send Window=5,000
Window=5,000
75
Last few notes
This has been a very brief look at TCP. TCP has many components, some of which we have started to become
familiar with. Some other TCP topics which may be of interest to you:
Slow Start SACK NAK Timer calculations Congestion algorithms and windows
Whew!
76
0 15 16 31
16-bit Source Port Number
16-bit Destination Port Number
32-bit Sequence Number
32 bit Acknowledgement Number
4-bit Header Length
6-bit (Reserved)
URG
ACK
PSH
RST
SYN
FIN
16-bit Window Size
16-bit TCP Checksum
16-bit Urgent Pointer
Options (if any)
Data (if any)
UDP and TCP TCP
TCP provides: Reliable delivery Error checking Flow control Congestion control Ordered delivery (Connection establishment)
UDP provides: Unreliable delivery No error checking No flow control No congestion control No ordered delivery (No connection
establishment)
UDP
77
Note of Interest – TCP Reset
If a station involved in a TCP session notices that it is not receiving acknowledgements for anything it sends, the connection is now unsynchronized, and the connection should send a reset.
Issues: TCP Reset Attacks: http://kerneltrap.org/node/3072 ISP’s resetting user sessions: http://www.youtube.com/watch?
v=FrmS19ej73E
0 15 16 31
16-bit Source Port Number
16-bit Destination Port Number
32-bit Sequence Number
32 bit Acknowledgement Number
4-bit Header Length
6-bit (Reserved)
URG
ACK
PSH
RST
SYN
FIN
16-bit Window Size
16-bit TCP Checksum
16-bit Urgent Pointer
Options (if any)
Data (if any)
Hey, I’m sending segments but I’m not getting any
Acks. I’m going to reset this connection.
78
Although, published in 1994, written by the late Richard Stevens, it is still regarded as the definitive book on TCP/IP.
TCP/IP Illustrated, Vol. 1 W. Richard Stevens Addison-Wesley Pub Co ISBN: 0201633469
Computer Networking
James Kurose and Keith Ross ISBN 0321227352
University level text book Variety of networking topics. An excellent extension to CIS
81 material
79
Tech Note (FYI) Sender: The value in the sequence number is the first byte in the data stream. So, how does the receiver know how much data was sent, so it knows what value to send
in the acknowledgement? Receiver: Using the sender’s IP packet and TCP segment information, the value of the
ACK is: IP Length: (IP header) Total length - Header length - TCP header length (TCP header): Header length ------------------------------------------------- Length of data in TCP segment
ACK = Last Sequence Number acked + Length of data in TCP segment
Check Sequence Number to check for missing segments and to sequence out-of-order segments.
Remember that the ACK is for the sequence number of the byte you expect to receive. When you ACK 101, that says you've received all bytes through 100. This ignores SACK.
80
TCP MSS = 1460
Data = 1460 octets
20 octets 20 octets 1460 octets
1500 octets
Determining TCP MTU Typically, an end system uses the "outgoing interface MTU" minus 40 as its
reported MSS. For example, an TCP over IP over Ethernet MSS value is 1460 (1500 - 40 =
1460). When a host (usually a PC) initiates a TCP session with a server, it negotiates
the TCP segment size by using the maximum segment size (MSS) option field in the TCP SYN packet. (curriculum say IP segment).
The value of the MSS field is determined by the maximum transmission unit (MTU) configuration on the host.
The default Ethernet MTU value for a PC is 1500 bytes. (curriculum says MSS)
TCP MSS defines the maximum size of the data in the TCP segment.
Ethernet MTU defines the maximum size of the data in the Ethernet frame.
The host using Ethernet, MTU of 1500 octets so I will set my MSS to 1460.
Chapter 4Transport Layer
CIS 81 Networking Fundamentals
Rick Graziani
Cabrillo College