TCP Reliability and Security: Key Concepts Explained

Name: TCP a : Ensuring Your Data Gets There & in the Right Order! - Computerphile
Uploaded: 2026-06-13T13:00:35+00:00
Duration: 17 min 26 s
Channel: Computerphile
Description: Summary and key takeaways on TCP Reliability and Security: Key Concepts Explained, covering The Role of the Transport Layer TCP acts as a wrapper that hides

Computerphile

Jun 13, 2026

•

17 min video

•

2 min read

YouTube video ID: IADOV8UZO34

Source: YouTube video by Computerphile — Watch original video

PDF

TCP acts as a wrapper that hides the “leaky pipe” of the internet, masking data loss, corruption, and out‑of‑order delivery. It provides a reliable byte‑stream interface that lives only on end devices; the network itself does not implement TCP. The protocol is defined by RFC 9293, which superseded RFC 793 in 2022.

TCP Mechanisms

State Tracking and Sockets

Both ends maintain a state machine that tracks the connection status. Data is divided into segments, each prefixed with a header containing source and destination ports, sequence numbers, and flags.

The Three‑Way Handshake

The sender transmits a SYN packet to request a connection.
The receiver replies with a SYN‑ACK, acknowledging the request and proposing its own sequence.
The sender completes the exchange with an ACK, establishing a socket pair.
Sequence numbers start with a random value for security, and the acknowledgement number always indicates the next expected byte.

Sequence and Acknowledgement Numbers

The sender assigns a sequence number to every byte. The receiver acknowledges the next expected byte, allowing the sender to detect gaps. If out‑of‑order data arrives, the receiver holds it and continues to ACK the last in‑order byte, signaling the missing segment.

Error Handling

When a packet is lost or corrupted, the receiver does not advance its acknowledgement number. “Triple duplicate” ACKs—three identical ACKs—signal that a specific packet was lost, prompting immediate retransmission. Timeouts serve as a fallback, triggering retransmission of any unacknowledged data after a delay.

Performance and Security

Flow Control and the Window

Sending an ACK for every packet would be inefficient, so TCP uses “flights” of packets. The window size determines how many packets may be in flight before an ACK is required, probing the network to find optimal capacity.

SYN Flood Vulnerabilities

The three‑way handshake reserves resources on the server before the connection is fully established. An attacker can exploit this by sending many SYN packets without completing the handshake, exhausting server resources and causing a denial‑of‑service condition. This is analogous to the Slow Loris attack.

“Its job is to pretend that this manky leaky pipe that's corrupting and dropping our data, pretend that doesn't exist and pretend we've got a nice reliable pipeline.”
“The RFC, the request for comments, is what we internet people take as our kind of bibles of how these things work.”
“It's like if I ask you for a high five and then leave you hanging.”
“If I can get a hundred or a thousand or a whole botnet to do that to you, that synflood attack nibbles away all of the resources of your computer.”

Takeaways

TCP hides network instability by presenting a reliable byte‑stream interface that operates solely on end devices.
The three‑way handshake (SYN, SYN‑ACK, ACK) establishes a socket pair and uses random initial sequence numbers for security.
Triple duplicate ACKs and timeout mechanisms work together to detect lost packets and trigger retransmission.
The window size enables multiple packets to be in flight, improving throughput while maintaining flow control.
SYN flood attacks exploit the resource reservation step of the handshake, allowing attackers to exhaust server resources and cause denial of service.

Frequently Asked Questions

How does the TCP three‑way handshake establish a reliable connection?

The handshake creates a synchronized socket pair by exchanging SYN, SYN‑ACK, and ACK packets. The initial SYN requests a connection, the SYN‑ACK acknowledges the request and offers its own sequence number, and the final ACK confirms both sides, establishing stateful communication ready for reliable data transfer.

Who is Computerphile on YouTube?

Computerphile is a YouTube channel that publishes videos on a range of topics. Browse more summaries from this channel below.

Does this page include the full transcript of the video?

Yes, the full transcript for this video is available on this page. Click 'Show transcript' in the sidebar to read it.

Helpful resources related to this video

If you want to practice or explore the concepts discussed in the video, these commonly used tools may help.

Computer Networking A Top Down Approach Book Recommended

This textbook provides a comprehensive, structured explanation of TCP and transport layer protocols, perfect for someone studying the concepts in the video.

Amazon →

Tcp Ip Illustrated Volume 1 Book

This is the definitive technical reference for TCP/IP protocols, offering deep dives into the RFCs and packet-level details mentioned in the lecture.

Amazon →

Network Protocol Analyzer Hardware Tap

A physical network tap allows users to capture and inspect real-world TCP traffic, helping them visualize the three-way handshake and packet headers.

Amazon →

Links may be affiliate links. We only include resources that are genuinely relevant to the topic.

Summarize another video

Full Transcript YouTube

We are continuing our deep dive down the
network stack. So if we remember our
network stack, we had our layers model
and the application
is delivering data via the transport
layer to the network layer. Today we're
looking at the transport layer and in
specific a transmission control
protocol. It's the big one really. It's
uh probably the most complicated of
them.
So let's have a look at the job it's got
to do. Let's motivate what we've got to
do. Let's just remember back to the last
one we were doing. We did use a
datagramgram protocol. And the job of
user datagramgram protocol is very
similar. My diagrams always start like
this. We have our pearly drawn laptop.
We have our pearly drawn server and we
have the internet drawn as a cloud.
Hooray. Now, we've got some applications
running on our laptop, some applications
running on the server, and
we want to get data from the app
through to the other app.
We want that data to go through the
internet. It's got to get between the
right program on on this laptop and the
right program on this server.
But ha, we've got the wilds of the
internet. So, anything can be in here.
It's It's not necessarily a benign
environment for our data, right? Things
can go wrong.
>> Those old maps used to say, "Here be
monsters."
>> Oh, exactly. Here be monsters. Let's
have that. That would be nice. So, what
we're going to do, let's abstract that
picture a little bit. And let's imagine
our application is sitting here.
And what we want is a nice reliable pipe
that we can pour by bites into. So byes
in here, byes
out here. But actually what we've got
underneath is a leaky pipe which we can
have data loss, data corruption
and packets might get out of order and
the job of our transport control
protocol sitting here and sitting here.
So it's only sitting on the end devices.
Its job is to pretend that this manky
leaky pipe that's corrupting and
dropping our data, pretend that doesn't
exist and pretend we've got a nice
reliable pipeline. Last time we
introduced the concept of a port which
tells us which application to come from
and go to. But now we're going to need a
lot more. A little apology before I
start because with UDP I could explain
more or less everything, right? with
TCP. I have not a hope. If you want the
the full gory details, it would be
RFC793
was the old one, but actually I
discovered 9293 obsoleted it in 2022.
Shows what happens if you don't stay
current. The RFC, the request for
comments, is what we internet people
take as our kind of bibles of how these
things work. So, we're going to need two
little mechanisms. We're going to need
what we call a state machine to track at
each end where we're up to and what
we're doing. And we're going to stick a
header onto our data. So, we've got our
big pipe of bytes that we want to send.
Going to chop them up into little bits.
And each of those little bits, we're
going to take that data and stick on the
front of it a header. And this beautiful
bit of uh asi art lovely shows us what
those bits we must stick should be. So
the way to read this diagram is this is
the zeroth one to first second third
one. The zeroth first second third bits
on the header. Uh like normal people
computer scientists always start
counting from zero not one. So the first
16 bytes are the source port the
application it's coming from the
destination port and so on and so on.
I'm not going to explain every single
bit of this. There's some things we'll
need to look at. There's a sequence
number and acknowledgement number, for
example, which we'll get on to later.
There's a bunch of flags that do
different things. So, these little
things are just zeros and ones that tell
us is this particular packet an SYN
packet? Is this particular packet an FIN
packet? And we'll talk about what that
sin, Finn, etc. means. There's other
things in there. as a checksum and we
talked about that with UDP so we know
what it is. A checksum is our way of
telling has this been corrupted. Now
we're going to need several mechanisms.
Uh the two that I'm going to really talk
about today are creating a connection
and
getting reliability.
So let's start with that first one
because this protocol needs to track
state.
We need to create a permanent struct
well we need to create a structure in
the computer's memory that's going to
stay there for the duration of us
sending data to and from that computer.
So we are going to need to have
something that's living on the uh
receiver and on the sender and that
structure we'll call it a socket is
going to stay there while we are sending
data. So what we want to do is create a
socket here a socket here connect them
up and those sockets connect directly
into the application. Bam bam bam. So
the first thing we're going to need then
is a way of saying to our computer, can
we set up a socket between these two?
It's what we call a threeway handshake.
It's it's a classic bit of um computer
science cuz we need three two will not
do us. We need to say say hello and that
hello is the sin the s packet. So the
person wanting to initiate the
connection sends a packet with this s
flag sent. So sin you the receiver send
back your own. So sin is kind of
synchronized kind of I want to set up a
socket with you. The receiver needs to
acknowledge the presence of that. So
it's going to send back an act but that
act is also sin because it's going to
say I would like to set up a socket with
you. Then we send back an act to
acknowledge that socket. So once you had
sin that way, sinac back that way and an
act back that way. Now we've got a
socket pair set up and that socket pair.
So if I put bytes into the the socket at
my end, they should be spat out at your
end identically in the right order with
no bits going missing.
In between
those bits can be corrupted, but we've
got to check some to account for it. But
um they can get out of order and they
can be lost. Now that's the next
problem. We deal with them in the same
way. So I think I've asked you this
question before actually. How might we
deal with the idea that a whole packet
can get lost?
>> Well, presumably they all have to kind
of have a some kind of sequence number
on them.
>> Precisely this. So we need a sequence
number. So we got a bam bam our sequence
number. And we also need a receipt pack,
right?
>> Receipt an an act. Another
>> an act. Yeah. So an SEQ and an act.
These are the things that's going to do
the job of ensuring that nothing is
lost.
So,
we're sending out our packets. We're
sending out our sequence numbers. And
the packet has a number indicating a
sequence. I'm going to skip over some
magic there because the sequence number
doesn't begin one. It's actually
genuinely important. it begins with a
random number that's impossible for
anybody to predict.
Security reasons why I won't go into the
magic of how that happens.
The application when it receives a
sequence number is going to send an
acknowledgement number and that
acknowledgement number is saying the
packet it wants next. So it's saying
okay I have seen packets four, five and
six. Can I have packet seven?
Now,
here's where we get into some
difficulties, shall we say? Not
difficulties, but some things that need
to be resolved. So, let's imagine I've
sent Now, I'm going to number these from
one. That's not really how that
numbering works. That numbering is
actually a bite numbering. Yeah. So, it
it it the sequence number is telling you
the bytes that are being sent. So, it
wouldn't really start for one, but let's
imagine I've sent over packets one, two,
and three, and they get to the other
end, but oh, oh dear, two is gone away.
Maybe it got corrupted. Maybe it was one
of the routters on the way was full. It
got dropped. So now you as the
application, you get one. We're sending
back an acknowledgement.
And that acknowledgement is the
acknowledgement associated with packet
one. Now I get three gh
I'm not going to throw it away but I
can't give it to the application. All
right because then our messages got out
of order.
Now I'm going to send back act one
again. Yeah. And by sending back that
act one I'm saying I've got some data
for you
but it's not the data I really wanted.
I've got I've got something. And I've
just realized my data is flowing this
way now from the laptop, but never mind.
Now the laptop realizes, ah, right, he
sent me back act one again. Something's
not gone right. And you you can send
some extra data. And eventually you're
going to realize, ah, all right, he's
after data 2 is after the piece of data
2. There's a lot of subtlety in there,
and I'll deal with those in the next
video of exactly or how the ways that
this can work. We're going to also need
some kind of time out mechanism.
Again, the subtleties in here. So, we're
going to need to say, well, I was hoping
to see act two, but I haven't. I'm going
to wait a little bit of time, and if we
haven't seen it, we're going to send
packet two again. We're going to assume
it's lost. There's other clues we can
use. So we can use the fact that if we
see act one several times, we call that
a duplicate. So I see act one, I see act
one again, I see act one again. And you
know, you don't have to be Sherlock
Holmes to detect we've got a problem,
right? We ah
we've got act one. We call it triple
duplicate if we've seen it once and
three more times and then we go, you
know what? Packet's lost. I'm going to
send it again. Bam. Send off another
copy of two.
So now we've got a mechanism whereby
we can get rid of our corrupted packets.
If our packets have got out of order,
well actually let me illustrate what
happens to be out of order cuz I haven't
done that yet. So let's imagine our our
our tardy packet two that got lost.
We've resent it. It shows up. So packet
two shows up. We can pop it in here. And
now we don't need to acknowledge two. We
can actually send out the act associated
with three to say not only have I got
two, happy day, I've got three as well.
So, and again, technically the
acknowledgement sent is the
acknowledgement requesting the next
bite. It's not really numbered three,
but it is the acknowledgement associated
with I have all the packets up to three.
Yeah. So
we've got our out of order, we've got
our corruptions, we've sort of got the
rudiments of a method for sending data
reliably.
We've we have got some problems
remaining and
one of those problems is if we think
about this, it's going to be real slow,
right?
Like if we were having this conversation
and I required you to acknowledge and
say yes after every word I'd go hey
>> yes
>> Sean
>> yes
>> we
>> yes
>> are
>> yes
>> going to talk about teach and the
conversation becomes very slow if I get
an acknowledgement for every packet and
send a packet and get an acknowledgement
it's just going to be painfully horribly
slow
so we need to send the packets It's
together in bunches. We call them
flights. And in the next video, we'll
talk a little bit about how that works.
But we need some mechanism of saying,
"All right, I am good. I'm happy to say
that this network can have 10 packets in
flight at once before I get any
acknowledgements at all."
And we need to kind of probe the network
and say, can you take a 100 packets? Can
you take a thousand? Can you take 10,000
packets? We need to know how big our
network is. This is something we call
the window. There's a window size on
there. Hopefully, it's not that window.
It's a different one, but uh that's a um
nothing to talk about with TCP. We need
to think about security. So, there's
there's a little aside here that that's
quite interesting because even in just
we always need to be thinking how can
this go wrong? How can it fail? How can
it be hacked? So even in just that
simple sin sinac act mechanism,
no matter how we do it, there's a little
hack in there. There's a little denial
of service. You might remember Mike did
a video about slow loris. So it's a
lovely little attack and and um slow
loris is an attack that kind of slowly
uses up all the resource on a web
server. With sin act, we've also got a
potential hack, what we call a sin flood
because these sack is very little.
They're carrying no data. They're just
basically just a header and saying, you
know, I would like to establish a
connection. It's almost nothing to them.
Very, very tiny packet. Yeah.
And the server computer, the server
computer needs to um say, okay, they
want to set up a connection. I'm going
to reserve a socket. I'm going to send
back a synak. Um,
it's reserved some memory. It's reserved
a little bit of its resources. It's
it's, you know, it's like if I ask you
for a high five and then leave you
hanging. So, so the sin flood, if you if
I send out
loads of these little tiny packets, I'm
just nibbling away tiny bits of memory
off your computer.
If I can get a hundred or a thousand or
a whole botn net to do that to you, that
sinflid attack nibbles away all of the
resources of your computer, suddenly you
can't serve your legitimate customers.
You're too busy dealing with my botnet
throwing a million sin packets at you.
It's quite an old school attack. There's
lots of ways of mitigating that
nowadays, but I think it's nice to just
realize that even in describing
something very very simple, we
immediately see a kind of security
hacking hole um that we need to work our
way around. And that's the kind of bad
world of the internet we live in today.
But with this, we've got all of our
mechanisms. I didn't talk about closing
a connection. That's the finac we've
actually done a video on that. The
goodbye problem. So green general
sitting on the hillside going uh what
can I do? These are the basic mechanisms
behind TCP. This will get us reliable
transport. If we fiddle with that window
size carefully,
we can get it sending efficiently.
Um so in the next video though, I want
to dig a I want to show you some
examples and dig a little bit into the
kind of ugliness and the the the the
difficulties of doing this in the real
world.
What you can be sure of is you've sent
this many packets or as far as you're
aware they're out there in the world.
You don't know how big the network
you're connecting to is because remember
you've got to connect to everybody,
right? They may be in Melbourne. They
may be in Beijing. They may be just next
door.

Help & FAQ

Is it Possible to Block Childrens' Access to Social Media? - Computerphile

Computerphile

Jun 16, 2026

TCP Mechanisms

State Tracking and Sockets

The Three‑Way Handshake

Sequence and Acknowledgement Numbers

Error Handling

Performance and Security

Flow Control and the Window

SYN Flood Vulnerabilities

Takeaways

Frequently Asked Questions

How does the TCP three‑way handshake establish a reliable connection?

Who is Computerphile on YouTube?

Does this page include the full transcript of the video?

Helpful resources related to this video

Share This Summary

Embed This Summary