TCP Connection Management (Part - 1) Video Lecture - Computer Science Engineering (CSE)

so we are at the transport layer we
finished an overview of the PCP protocol
let's now dig into the details but first
a few questions
unlike UDP TCP is a connection-oriented
protocol in other words a connection has
to be established before you can start
sending data and during this connection
establishment both sides can exchange an
initiate stake variables for example
they can negotiate what is the maximum
segment size that they want to use they
can also exchange their initial sequence
numbers why this is happening we will
look at it shortly we can also figure
out what is the acknowledgement type
that you want to employ either selective
ACK or cumulative acknowledgment apart
from this you can also allocate
resources for example the buffer space
so for example once the connection
establishes both sides the sender and
the receiver are going to allocate some
buffer space for the send buffer and the
receive buffer how much is actually
allocated is a function of the operating
system so these numbers can range from 4
kilobytes all the way to megabytes in
fact you can configure these for example
in some Linux systems this value is 8
kilobytes so let's look at how a
connection is established simple if a
wants to talk with B it can send a
connection request V is going to
acknowledge this connection via a
connection grant then both a and B can
start exchanging data simple right
wrong things are often never so easy in
networks remember we are operating over
a best-effort service where packets can
get delayed they can get reordered so on
so forth so there is always the danger
of duplicates from earlier showing up so
view that as a hint and tell me what can
potentially go wrong in connection setup
so here is the problem
suppose you established a TCP connection
with your bank and before the actual
data
you set connection request connection
grant and then as part of this data
you're saying transfer 20 lakhs to some
account X now some of these packets
could have gotten delayed and the sender
would have free transmitted them and it
is quite possible that these
retransmissions got delayed arbitrarily
and after this connection terminated
they are again appearing at the other
end so this connection request is a
duplicate that is appearing at the bank
server so in response to this this Bank
thought it was a new connection and sent
a connection grant and here you are
wondering what the hell is happening why
am I getting some response from the bank
and in the meantime your previous packet
came and there you go you transferred
another 20 lakhs to account X and your
bank balance is now nil
you definitely don't want something like
this to happen so what is the solution
it's a bit tricky but nonetheless think
of how you can solve this problem
originally the TCP implementations did
exactly this but then this problem arose
and later they change the implementation
so here is the solution
the famous three-way handshake of TCP so
this idea was proposed by Tomlinson
suppose a wants to establish a
connection with B it is going to send
this initial packet this is the initial
synchronization packet and as part of
this packet it is going to tell B that I
am going to use sequence number starting
from X now in response to this packet B
is going to set the flag sin and ACK
where it is also synchronizing with a
and saying I am going to use sequence
number Y and it is acknowledging this
particular packet by saying I want X
plus 1 now a has to acknowledge this
packet so it is again going to set the
ACK field and it is acknowledging this
packet by
I want pie plus one and it can
potentially send data as part of this
connection by the way this is not needed
you could decide not to send data if you
are sending the data you are going to
start that particular sequence number
with X plus one so the takeaway from
this is the use of these distinct
sequence numbers that is one and the
other is that you send the packet the
other guy acknowledges and you
acknowledge the other guys packet so
this three-way handshake is very famous
the syn synack and AK in fact they're
quite a few jokes on it let me just tell
one it's not a great joke but
nonetheless so a TCP packet goes to a
bar and says I want beer please the
bartender asks you want beer
and the TCP packet says yes beer please
so this kind of captures the three-way
handshake yeah I know the joke isn't
great but I think you will remember the
3-way handshake better given that I have
said the joke so how does this solve the
problem let's look at it suppose there
was an earlier transfer and after this
particular transfer this duplicate
happens to end up at the server now it
doesn't know this is a duplicate so it
is now going to send a syn ACK and it is
going to select some other sequence
number earlier that sequence number was
Y now it has chosen Z and it is going to
acknowledge this particular sequence
number and now this other end will
wonder what does this I've never even
talked with the server again so it is
going to reset the connection while
acknowledging this particular packet so
as a consequence of this this connection
will never be established this is the
more interesting case where you have
both the syn packet and this data packet
duplicated so in this particular case
let's see what happens so again when you
receive this syn packet you are now
going to a kit with a new sequence
network
and now the earlier connection packet
has come about and here you are confused
I censored why is this acknowledging why
so something is wrong so you are going
to discard this packet and wait in the
meantime the other end will see this
packet worried what is happening and is
going to send a reset packet thereby
aborting the connection by the way if
this client were indeed not listening on
that particular port in other words it
closed that particular connection in
which case it is not going to send this
packet but even in this particular case
in order for the connection to complete
it needs this acknowledgement as I said
it's a three-way handshake it needs the
third handshake from the other end which
it will never get in which case it is
going to again close the connection
after waiting for some time so let me
spend a little bit more time on this
initial sequence numbers so when we were
describing the sliding window protocol
we always started with a sequence number
zero now the question is why don't we
just start with sequence number zero it
makes things a little bit less complex
as you saw here this distinction could
happen because these sequence numbers
differed so it's very important to use
different sequence numbers for the
different connections so that way the
segment's from the different connections
cannot get mixed up not only that there
is a security risk when using these
sequence numbers that are predictable
originally when the TCP was being
designed this was the goal so what they
did was to use a clock to choose these
signal sequence numbers so this clock
increments every four microseconds and
this so these 32 bit sequence numbers
were derived from this clock and given
that it is a 32 bit sequence number how
long will it take for the member to wrap
around roughly four hours by this time
the older packets would have definitely
been removed from the network because as
I mentioned at the
P layer these packets do have a time to
live field they are not going to live in
the internet forever but then this
predictable initial sequence numbers
were being used launch security attacks
I will cover a little bit more of this
as part of the quizzes but the point to
note is that this wasn't considered safe
so current implementations use random
initial sequence numbers to circumvent
the security threat so this is with
connection establishment so what do you
think of connection termination you
think this is easy