Week 9 Preview: TCP - savannahc502/SavC-TechJournal-NET215 GitHub Wiki
Information on this page may be paraphrased or copied from Champlain College materials. Avoid coping as you may be committing plagiarism. This is for note-taking and academic purposes only.
TCP Intro Video
TCP: Transport Control Protocol that occurs at OSI Transport Layer 4
IP vs. TCP
- Uses the "best effort" delivery method -- gets the data to a primary destination and that's it.
- TCP is a Layer 4 Protocol that improves upon the "best effort" when needed! It provides reliable transport service.
- Guarantees prompt and reliable communication
- Data is delivered in exactly the same order it was sent
- No loss or duplication
- This is how TCP views the underlying Internet -- everything below it is "just the network"
- TCP uses IP to carry messages
- IP treats TCP messages as data to be transferred by examining the header
The Service TCP Provides to Applications
- Connection Orientation
- An application must first request a connection to a destination
- Point-to-Point Communication
- Each TCP connection has exactly two endpoints
- Complete Reliability
- TCP guarantees that the data sent across a connection will be delivered completely and in order
- Full Duplex Communication
- Allows data to flow in either direction at the same time
TCP Header
Source and Destination Port
- A TCP header first contains the Source and Destination Port
- 16-bit numbers (0-65,535)
- Source POrt helps identify the "application" sending the packet
- Destination Port helps identify the "application" to receive the packet
- This can be seen in a Wireshark capture
Sequence and Acknowledgement
- 32-bit numbers to keep track of communication
- Sequence is tracking what is being sent in that direction
- Acknowledgement is tracking what has been received in that direction
TCP Flags:
- TCP Flags are found in specific locations in the TCP header
- A "1" indicates that the flag is set
- A "0" indicates that the flag is not set.
- Examples of flags:
- URG: 106
- ACK: 107
- PSH: 108
- RST: 109
- SYN: 110
- FIN: 111
TCP Features to Focus on in NET-215:
- Connection-Orientation: Establishing connections with the 3-way handshake and session teardown
- Sequencing: Keeping track of data in both directions of the TCP communication
- Reliability: Acknowledging the receipt of packets so that missing ones are detected and re-sent
TCP 3-Way Handshake Video
- Reliable Connection Startup
- TCP allows two applications to reliably start communication using the 3-way handshake
- During the 3-way handshake to start a connection...
- ... each side sends a control message that specifies an initial buffer size (for flow control) and a sequence number
- TCP's 3-way exchange is necessary and sufficient to ensure unambiguous agreement
- despite packet loss, duplication, delay, and replay events
- The handshake ensures that TCP will not open or close a connection until both ends have agreed.
The TCP 3-way SYN/ACK Packets
- The first packet in the handshake is a synchronization segment (SYN flag set in the TCP header) from client to server
- The second packet in the handshake is a SYN/ACK
- It acknowledges (ACK Flag) the SYN and session started from the client to the server
- It sends its own SYN to start the session from server to client (bi-directional communication)
- Does both in same, which is why it's both SYN and ACK Flagged
- The third packet in the handshake is the ACK (acknowledgment) from the Client back to the Server that the Server-to-Client session is up.
- This is the visualization of the connection establishment that the TCP 3-way handshake completes
TCP Connection Termination
TCP also has a session termination process
- Graceful Connection Shutdown
- TCP ensures that both sides have agreed to shut down the connection
- A connection that is left open can be a security risk
- TCP FIN segments to close
- FIN flag is used to close the connection
- a FIN and ACK are sent in each direction to guarantee that all data has arrived before the connection is terminated
- This is the visualization of the connection termination that the TCP 3-way handshake completes
- Sometimes this may be a four-way if the delivery is not complete
TCP Sequence Numbers Video
TCP requires each end of a connection to generate a random 32-bit sequence number that becomes the initial sequence in that direction.
- Why random sequence numbers? (SEQ #'s)
- Random SEQ's are used to prevent people guessing the sequence number and stealing someone's session (the probability of selecting a random value that matches the sequence used on a previous connection is low).
- If an application attempts to establish a new TCP connection after a computer reboots:
- TCP chooses a new random number so TCP avoids replay problems -- sequence numbers on the new connection will differ from sequence numbers used on the old connection.
TCP SEQ Numbers
- SYN, SYN/ACK, FIN, and FIN/ACK are simple packets and will always increase the sequence number by
ONE- ACK packets do not consume a sequence number
- However, every time a system sends a packet with data, it will increase the SEQ# by the number of BYTES it sent to the prior packet:
- This allows for the packets to be placed in the correct order when received
- Imagine the starting sequence number is 500 and then sends data...
- This is one direction of the communication
- Sequence #'s increase based on Bytes
Visual Example of SEQ and ACK:
Acknowledgment #'s
- Ack #'s indicate what has been received so far
- Simply, the initial SEQ# plus all of the Bytes received
- Acknowledgements don't have to be sent for every packet received
- Like the example below, could receive three packets and then send an ACK
- Example:
- A system receives these three packets
- The starting SEQ# was 500
- It would send back the ACK# 3460
- 500 and 2960 = 3459
- A bit tricky, but 500 is considered byte 0
- It is expecting SEQ 3460 next!
- 500 and 2960 = 3459
SEQ and ACK - Sequencing/Retransmission
- SEQ and ACK numbers can also indicate dropped or missing packets
- If a system does not receive a proper ACK#, it can re-send (later in these notes)
SEQ Numbers in WireShark
- Right-click on packet stream > Protocol Preferences > Check "Relative Sequence Numbers"
TCP Sliding Windows Video
Sliding Window Acknowledgement System: This is the process TCP uses to deal with reliability and flow control
TCP Overview:
- Assigns a unique consecutive sequence number based on bytes sent
- The receiver uses the numbers to put data in the correct order
- Can also be used to discard duplicate packets and identify missing ones
TCP Uses Positive Acknowledgment with Retransmission (PAR):
- Message 4 lost in transit
- Using message id's (SEQ#'s in TCP)
- Receiver is setting a Limit on messages it can receive with ACK
- Sender using a timer
Sequence numbers on their own are not enough
- What happens when Device A sends all its packets? --> What if there is a flow control issue that requires B to take more time?
TCP Window Size
- The receiver can inform the sender of a "limit" to the number of bytes it can receive
- This field tells the sender how much data can be sent on the wire before an ACK is received
- This is set in the 16bit "window" field in the TCP header, also known as the "TCP Receive Window"
- If the receiver is not able to process the data as fast as it arrives,
- gradually the receive buffer will fill
- and it will reduce the TCP window size in its ACKS
- this will alert the sender to reduce the amount of data sent and/or allow the receiver time to clear the buffer
Known as a sliding window since the limit can grow and shrink over time.
TCP Sliding Windows - Handshake
- During the TCP 3-Way Handshake, client and the Server set their initial Window Size -- Server often smaller (it sends data), Client is larger (receives data)
- As data is transferred, we can see the client adjust its receive window
TCP Zero Window:
When a client advertises a zero for its window size:
- This indicates that the TCP receive buffer is full can it can not receive any more data
- It may have a stuck processor/busy with another task
- When the client resumes digesting data, it will send a TCP Window Update packet.
TCP Window Scale Factor Video
- On high-performance/reliable networks, 65,535 bytes between ACK's may be too low
- A TCP Option (in the options part of the header) was introduced to allow an exponential increase in Window size:
Window Scale Factor- This option is set in TCP Header during SYN headers of the Handshake
- Used for the rest of the session
- Window Scale is 2^x * 65,535, where x = scale factor (1-14)
- This option is set in TCP Header during SYN headers of the Handshake
TCP Adaptive Retransmission Video
Flow Control Challenges: Congestion
Congestion Results in Delay
- If congestion persists, the device will run out of memory and begin discarding packets
- Retransmission can be used to recover lost packets, but retransmission sends more packets into the network
- If the situation persists, the network can become unusable
- TCP attempts to avoid congestion collapse by monitoring the network and reacting quickly once congestion starts through
Sliding Window and Retransmission Optimizations
Adaptive Retransmission
- TCP chose to make TCP's retransmission adaptive to avoid the issues that arise with a fixed timeout
TCP Estimated Round Trip Time
- As it sends data packets and receives ACKs, TCP generates a sequence of round-trip estimates
- It uses a statistical function to produce an exponential weighted moving average of RTT and an estimate of variance
- Weights the most recent transmissions more heavily to adapt to changing network conditions
- Using a weighted average helps TCP reset the retransmission timer
Adaptive Retransmission
- TCP estimates round-trip delay for each active connection by measuring the time needed to receive a response and records the time at which the message was sent
- When a response arrives
- TCP subtracts the time the message was sent from the current time to produce a new estimate of the round-trip delay for that connection
- When a response arrives
- Timers are calculated by the system/upper layer application or by using the TCP Timestamp OPTION
TCP Adaptive Retransmission works well for both when the delay remains constant and when the delay starts to vary
Preview Quiz Notes
- Red Box Indicates the 3-Way Handshake for Connection
- Packet 1: Client Syncornizing with the Server
- Packet 2: Server Acknowledges and Synchronizes with the Client
- Packet 3: Client Acknowledges and the Connection is Established
- Orange Box Indicates the 3-Way Termination Sequence
- Packet 8: The Server acknowledges that it is ready to end the transmission and initiates the FIN flag
- Packet 9: The Client acknowledges this but is not ready to end
- This is why the termination of a 4-way handshake in this instance
- Packet 10: The Client acknowledges the ending of the handshake and sends a FIN flag
- Packet 11: The Server sends a final acknowledgment and the connection is terminated.