Introduction to TCP

Post on 27-Jan-2016

27 Views

Category:

Documents

0 Downloads

Preview:

Click to see full reader

DESCRIPTION

Introduction to TCP. A first look at the sockets API for ‘connection-oriented’ client/server application programs. Benefits of TCP. Communication is ‘transparently reliable’ Data is delivered in the proper sequence An application programmer does not need to worry about issues such as: - PowerPoint PPT Presentation

Transcript

Introduction to TCP

A first look at the sockets API for ‘connection-oriented’ client/server

application programs

Benefits of TCP

• Communication is ‘transparently reliable’• Data is delivered in the proper sequence• An application programmer does not need

to worry about issues such as:– Lost or delayed packets– Timeouts and retransmissions– Duplicated packets– Packets arriving out-of-sequence– Flow and congestion control

network layer

transport layer

application layer

Overview

T C P T C P

port P port Q … … ……

I P I P

unreliable IP datagrams

process A process B

reliable TCP byte-stream connection

Transport-Layer’s duties

• Create the illusion of a reliable two-way point-to-point connection linking a client application with a server application– Manage the ‘error-control’ mechanism– Manage the ‘flow-control’ mechanism– Manage the connection’s ‘persistence’– Manage the connection’s ‘shutdown’

Interaction overview

socket()

bind()

listen()

accept()

read()

write()

close()

socket()

bind()

connect()

write()

read()

close()

The ‘server’ application

The ‘client’ application

3-way handshake

data flow to server

data flow to client

4-way handshake

What is a ‘connection’?

• An application’s socket is ‘connected’ if it has a defined pair of socket-addresses:– An IP-address and port-number for the ‘host’– An IP-address and port-numbet for the ‘peer’

138.202.192.14

‘hopper.usfca.edu’

port 80

138.202.171.14port 53124

USF’s web-server

138.202.171.14

‘hrn23501.usfca.edu’

port 53124

138.202.192.14port 80

classroom workstation

2-way data stream

Layout of TCP header

destination port address

sequence number

acknowledgment number

HeaderLength

options and padding

source port address

32-bits

window size

urgent pointer

FIN

SYN

RST

PSH

ACK

URG

reserved

checksum

Sequence number

data

(256 bytes)

The sequence number field defines the number being assigned to the first byte of data contained in this segment. During connection setup, each party to the connection uses a random number generator to get the value it will assign to the first byte of data it will transmit, called its initial sequence number (ISN). Thereafter, the sequence number in each succeeding segment will equal the sequence number used in the prior segment plus the number of data bytes in that prior segment. By this scheme the receiver can arrange all the incoming data bytes in the proper order, even if some segments happen to arrive out-of-order.

data

(256 bytes) data

(256 bytes) data

(232 bytes)

ISN ISN + 256 ISN + 512 ISN + 768

segmented stream of 1000 bytes

Acknowledgment number

• This field holds the number of the byte that the source of this segment is expecting to receive next from its connection partner

• This field’s value is meaningful only when this segment’s ACK control flag bit is set

sender receiver

9, 8, 7 6, 5 4, 3, 2, 1

ACK 5

TCP Header Length

• Like IP headers, the TCP Header’s length is expressed in multiples of 32-bits: it’s at least 5 (i.e., 20-bytes) if there aren’t any ‘TCP Options’ included in the TCP header

• The amount of DATA in a TCP packet can be calculated from the IP Header’s ‘Total Length’ field, minus the number of bytes that comprise these two headers (IP header + TCP header)

IP header TCP header DATA

Total Length (in bytes)

Control flags

URG

ACK

PSH

RST

SYN

FIN

5 4 3 2 1 0

Legend: FIN = Terminate the connection SYN = Synchronize sequence numbers RST = Reset the connection PSH = Push the data ACK = The value in the acknowledgement field is valid URG = The value in the urgent pointer field is valid

Establishing the connection

server application(passive)

client application

(active)

timeline

SYN J

SYN K, ACK J+1

ACK K+1

The 3-way Handshake

Exchanging data

server application(passive)

client application

(active)

timeline

PSH+ACK

ACK

ACK

PSH+ACK

A typical Request and Reply transaction

Connection shutdown

server application(passive)

client application

(active)

timeline

ACK+FIN

ACK

ACK

The 4-way Handshake

ACK+FIN

3-way handshake

SYN

ACK + SYN

ACK

‘request-and-reply’

ACK+PSH

ACK

ACK+PSH

ACK+FIN

4-way handshake

ACK+FIN

ACK

ACK+FIN

ACK

TCP Timers

• To achieve transparent reliability, the TCP subsystem maintains some internal timers

• One of these is the ‘Retransmission Timer’

• If a packet is sent, but its ACK does not arrive before this timer expires, then the packet will be ‘retransmitted’

• Of course, this could result in the receiver getting duplicate packets (if it’s a bit slow)

‘lost’ versus ‘late’

client application

server application

timeline

ACK

PSH+ACK

Busy server might be ‘slow’ to acknowledge

PSH+ACK

retransmit timeout

ACK arrives late same PSH arrives twice

‘piggyback’

• To reduce traffic-flow when possible, TCP delays sending an immediate ACK for an arriving data-packet, in case the receiver might soon have some data of its own to send back – in which case the ACK can ‘piggyback’ on the outgoing data PSH

• This mechanism, of course, requires TCP to maintain a ‘Delayed ACK’ timer

Delayed ACK senario

transport layer

application layer

T C P

port P ……

process A

buffer for outgoing data

buffer for incoming data

write read

Retransmittimer

DelayedACKtimer

KeepAlivetimer

WindowProbetimer

to/from the IP layer

Window Size

• During the ‘connection setup’ handshake, each host communicates to its partner a ‘window size’ parameter, to let be known some information about its capacity for buffering packets

• It also conveys its ‘MSS’ parameter (as a ‘TCP header option’) to inform its partner of its buffers’ Maximum Segment Size

MSS versus MTU

• A diagram shows the distinction between the protocol’s MSS (Maximum Segment Size) and the interface’s MTU (Maximum Transmission Unit); no TCP packets will be sent with a segment-size that’s larger

datalinkheader

IPheader

TCPheader

packetDATA

FCS

MSSMTU

Main TCP option types

• The TCP Header contains an options list, occupying from 0 to 11 longword values

• Each option is identified by an 8-bit ‘type’:• Type 0: End of the options list: data follows this• Type 1: No option: used for alignment padding• Type 2: Maximum Segment Size (MSS)• Type 3: Window scaling option (WSOPT)• Type 4: Selective Acknowledgments supported• Type 5: Selective Acknowledgment (SACK)• Type 8: Timestamp value and echo reply (TSOPT)

Option formats

• Option types 0 and 1 are single-bytes

• All other option types are at least 2-bytes, with the second byte containing the length

type2

length4

MSSvalue

type3

length3

WSOPTvalue

4 bytes 2 bytes

type4

length2

3 bytes

type8

length10

10 bytes

timestampvalue

timestamp echo replyvalue

Looking at TCP options

HLEN

HLEN

HLEN

‘Wrapped’ sequences

• The TCP header’s ‘Sequence Number’ is a 32-bit value, initially chosen at random

• It could happen that a large number gets selected as an Initial Sequence Number and that a large amount of data gets sent, thus causing the 32-bit field to ‘overflow’

• So how does the receiver tell a ‘wrapped sequence’ from a ‘late-arriving’ segment?

Type 8: TSOPT

• The TCP timestamps have two purposes:– RTTM: Round-Trip Time Measurement– PAWS: Protect Against Wrapped Sequences

TYPE (=8)

TimestampValue

TimestampEcho Reply

LENGTH (=10)

16 bits

The SACK option

• It conveys extended ‘acknowledgment’ information from a receiver to a sender about ‘gaps’ in the received data-stream

Type (=5) Length

Left Edge of first Block

Right Edge of first Block

. . .Left Edge of n-th Block

Right Edge of n-th Block

32-bits

2+n*8 bytes

no gaps here

no gaps here

Demo programs

• We put ‘tcpserver.cpp’ and ‘tcpclient.cpp’ on our class website, so you can watch actual TCP packets being exchanged by using our ‘nicwatch’ application (or some other packet-sniffer, e.g., ‘wireshark’)

• We deliberately used loops which write to, or read from, sockets one-byte-at-a-time so that you can observe ‘TCP buffering’!

top related