chapter 4 transport layer - univ-reims.fr4 udp tcp tcp/udp tcp/udp the layer 4 data stream is a:...
Post on 02-Aug-2020
32 Views
Preview:
TRANSCRIPT
Chapter 4 Transport Layer
2
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
3
Application Header + data
TCP Header UDP Header
or
PDU: Segment
PDU: Data
What is the application PDU called?
What is the transport PDU called?
4
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
5
Data HTTP Header
TCP Header
IP Header
Data Link Header
Data Link Trailer
IP Packet Data Link Header
Data Link Trailer IP Packet Data Link
Header Data Link Trailer
IP Packet Data Link Header
Data Link Trailer IP Packet Data Link
Header Data Link Trailer
IP Packet Data Link Header
Data Link Trailer IP Packet Data Link
Header Data Link Trailer
Data HTTP Header
TCP Header
IP Header
Data Link Header
Data Link Trailer
Reminder of encapsulation/decapsulation
6
Focus on Transport Layer TCP
TCP
7
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
8
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
9
TCP vs. UDP
TCP provides: Reliable delivery Error checking Flow control Congestion control Ordered delivery Connection establishment Applications:
HTTP FTP 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) SMTP 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.
10
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) .
TCP TCP
TCP
TCP
TCP
TCP
HTTP HTTP
FTP
UDP
SMTP
UDP
Web Server
ISP’s Email and FTP Server
Port Numbers: TCP and UDP
12
Both TCP and UDP use ports (or sockets) numbers to pass information to the upper layers.
TCP Header
HTTP is Port 80
UDP Header
13
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.
14
Application Header + data Port numbers are used by
the receiver so it knows which application it should
send the “Data” to.
Application Header + data Port numbers are used to
by the sender to tell the receiver which network
application it should use for the “Data”.
Port Number
Port Number
15
http://www.iana.org/assignments/port-numbers
The Internet Assigned Numbers Authority (IANA) assigns port numbers.
16
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
17
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).
18
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
19
Client Server
Telnet
20
Client sends TCP segment with: Destination Port: 23 (Well known port number) Source Port: 1028 (Dynamic Port assigned by client)
Client TCP Header
23 1028
Data for Telnet
Client Server
21
Server responds with TCP segment with: Destination Port: 1028 (Dynamic Port assigned by client) Source Port: 23 (Well known port number)
Server TCP Header 1028 23
Data for Telnet
Client Server
22
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)
23
Same client to same server - Two different HTTP sessions Client: Same destination port Client: Different source ports to uniquely identify this web session.
49890 49888
24
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
49890 49888
25
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
80 80 80
Source Port
49890
49888
Source Port
198.133.219.25 49888
www.cisco.com
26
Note: When downloading a web document and its objects it is common that there will be several TCP sessions created.
netstat –n www.cisco.com www.google.com
TCP or UDP Source Port
Destination IP Destination Port
Connection State Source IP
27
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
29
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
?
30
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
31
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
32
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.
Time
UDP segment UDP segment UDP segment UDP segment
Client Server
33
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
Time
UDP segment UDP segment UDP segment UDP segment
Client Server
34
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.
35
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?
Connection-oriented Transport: TCP
37
TCP
TCP provides reliable delivery on top of unreliable IP TCP provides:
Reliable delivery Error checking Flow control Congestion control Ordered delivery Connection establishment
38
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
39
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.
40
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.)
41
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
42
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)
43 Step 1: Client sends ISN, SEQ=8563 (last four digits)
44 Step 2: Server responds with ACK=8564, own ISN, SEQ=1678
45 Step 3: Client sends ACK=1679
46 Client now sends HTTP Request (GET) to Web Server
47
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.
48
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.
49
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.
Client Window Size=5,000
Server Window
Size=10,000
50
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,000 Server’s Send Window: 10,000
My Receive Window: 10,000 My 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.”
51
Flow Control and Reliability
Application 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 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 Client aWindow Size of 5,000 bytes
…
TCP 1-1000 TCP Segment
52
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.
53
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
54
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,000
SEQ=3,001 – 4,000
SEQ=4,001 – 5,000
ACK=5,001
SEQ=1 – 1,0001
SEQ=6,001 – 7,000
SEQ=7,001 – 8,000
SEQ=8,001 – 9,000
SEQ=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
55
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
56
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
TCP Header
57
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 - Receiver Host A - Sender
58
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 - Receiver Host A - Sender
Window size = 6
59
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!
60
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
61
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.
62
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
63
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
seq 92 Timeout
SEQ=100, 20 bytes data
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
64
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
(TCP Retransmission Timer)
FYI Scenario 3: Loss of first ACK
X (loss)
65
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.
66
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.
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 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
68
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
top related