WEBVTT

0:00:02.840000 --> 0:00:07.900000
 Hello and welcome to this video
 titled an introduction to TCP.

0:00:07.900000 --> 0:00:12.260000
 In this video I'm going to go over
 a brief history of how TCP came to

0:00:12.260000 --> 0:00:17.560000
 be. We're going to do a comparison
 of TCP to UDP.

0:00:17.560000 --> 0:00:22.060000
 I'm going to define this term of
 what is connection oriented mean.

0:00:22.060000 --> 0:00:25.620000
 And we're going to look at the various
 header fields that TCP applies

0:00:25.620000 --> 0:00:28.280000
 when it creates a TCP segment.

0:00:28.280000 --> 0:00:32.440000
 So let's start with
 the history of TCP.

0:00:32.440000 --> 0:00:37.540000
 TCP was originally developed by Stanford
 University in the 1970s and originally

0:00:37.540000 --> 0:00:43.440000
 TCP and IP were part of the same program
 called the Internet Transmission

0:00:43.440000 --> 0:00:45.760000
 Control Program.

0:00:45.760000 --> 0:00:54.420000
 IP is a protocol suite and ARPANET
 was the network infrastructure.

0:00:54.420000 --> 0:00:59.840000
 So as this mentions here TCP in very
 short order was decoupled or pulled

0:00:59.840000 --> 0:01:04.920000
 away from IP to keep them separate and
 to say consistent with a layered

0:01:04.920000 --> 0:01:07.560000
 approach to networking.

0:01:07.560000 --> 0:01:16.340000
 Alright, so what makes
 TCP different from UDP?

0:01:16.340000 --> 0:01:20.100000
 Well, first of all, let's start and
 talk about what makes them the same.

0:01:20.100000 --> 0:01:28.020000
 So both TCP and UDP create a header that
 header goes after the IP header.

0:01:28.020000 --> 0:01:31.140000
 Let's just draw this
 out right here.

0:01:31.140000 --> 0:01:41.100000
 So if I had two IP packets and these
 represent my IP headers right here,

0:01:41.100000 --> 0:01:44.880000
 both of them would have
 a header after that.

0:01:44.880000 --> 0:01:50.220000
 And that header could be TCP
 or that header could be UDP.

0:01:50.220000 --> 0:01:58.820000
 Now in IP we know we have a protocol
 field that is a value of what is

0:01:58.820000 --> 0:02:00.520000
 this IP carrying.

0:02:00.520000 --> 0:02:08.620000
 If IP is carrying UDP protocol value
 to 17, if it's carrying TCP, it's

0:02:08.620000 --> 0:02:11.340000
 protocol value 6.

0:02:11.340000 --> 0:02:16.640000
 Now what else makes TCP and UDP very
 similar to each other is that both

0:02:16.640000 --> 0:02:22.440000
 of them are able to keep track of individual
 sessions of the exact same

0:02:22.440000 --> 0:02:24.640000
 application by using port numbers.


0:02:24.640000 --> 0:02:33.380000
 We have a destination port number and
 TCP and UDP make use of that and

0:02:33.380000 --> 0:02:37.700000
 they have a source port number.

0:02:37.700000 --> 0:02:42.920000
 This way we can have multiplex or have
 multiple instances of the same

0:02:42.920000 --> 0:02:46.980000
 application running on a host, and that
 host can keep track of those individual

0:02:46.980000 --> 0:02:50.720000
 sessions by giving them
 different port numbers.

0:02:50.720000 --> 0:02:55.180000
 Here is where the difference
 between TCP and UDP ends.

0:02:55.180000 --> 0:03:00.560000
 TCP goes way above and beyond what
 we've just drawn right here.

0:03:00.560000 --> 0:03:03.240000
 So UDP is connectionless.

0:03:03.240000 --> 0:03:08.520000
 When a UDP datagram, or I should say
 when a UDP header is applied to your

0:03:08.520000 --> 0:03:13.440000
 data and then that data is given downstream
 to IP, there is no connection

0:03:13.440000 --> 0:03:15.040000
 oriented nature of that.

0:03:15.040000 --> 0:03:20.020000
 In other words, neither UDP nor IP is
 concerned with validating that the

0:03:20.020000 --> 0:03:30.940000
 destination exists, not
 the data that we sent.

0:03:30.940000 --> 0:03:33.560000
 That's all connection oriented.

0:03:33.560000 --> 0:03:37.300000
 UDP does not do that.

0:03:37.300000 --> 0:03:42.540000
 Also, how UDP expects to receive data
 from the upper layers is in small

0:03:42.540000 --> 0:03:45.580000
 discrete messages from
 upper layer protocols.

0:03:45.580000 --> 0:03:49.200000
 If we have an upper layer protocol,
 an upper layer application that the

0:03:49.200000 --> 0:04:00.580000
 way it was designed to work is to model
 the transport layer, UDP can't

0:04:00.580000 --> 0:04:01.740000
 really handle that.

0:04:01.740000 --> 0:04:05.160000
 TCP can handle that.

0:04:05.160000 --> 0:04:08.760000
 And UDP provides no reliability
 or transmission.

0:04:08.760000 --> 0:04:12.540000
 TCP on the other hand is
 connection oriented.

0:04:12.540000 --> 0:04:16.300000
 And it can work with any format of data,
 including a constant stream of

0:04:16.300000 --> 0:04:21.220000
 bytes from upper layer protocols, and it
 gives us reliability with acknowledgments

0:04:21.220000 --> 0:04:24.140000
 and retransmissions.

0:04:24.140000 --> 0:04:27.000000
 Okay, so let's dig into a little bit more
 about what do we mean by a connection

0:04:27.000000 --> 0:04:29.820000
 oriented? What was
 that term means?

0:04:29.820000 --> 0:04:31.400000
 Well, a variety of things.

0:04:31.400000 --> 0:04:34.620000
 Number one, TCP verifies the
 existence of your peer.

0:04:34.620000 --> 0:04:37.780000
 It says, look, I'm not going to send
 data to that destination if I can't

0:04:37.780000 --> 0:04:41.380000
 confirm the destination
 is actually alive first.

0:04:41.380000 --> 0:04:42.880000
 UDP doesn't care about that.

0:04:42.880000 --> 0:04:45.540000
 UDP says, oh, give me your data.

0:04:45.540000 --> 0:04:47.020000
 I'll send it out.

0:04:47.020000 --> 0:04:48.380000
 Is the destination there?

0:04:48.380000 --> 0:04:49.560000
 Maybe, maybe not.

0:04:49.560000 --> 0:04:54.440000
 I don't care. TCP does a
 validation check first.

0:04:54.440000 --> 0:04:58.720000
 It negotiates parameters with that destination
 to control the exchange,

0:04:58.720000 --> 0:05:02.340000
 the flow of data that's
 going back and forth.

0:05:02.340000 --> 0:05:07.180000
 And TCP data is exchanged reliably using
 sequence numbers, acknowledgments,

0:05:07.180000 --> 0:05:10.320000
 flow control, and retransmissions.


0:05:10.320000 --> 0:05:15.220000
 And TCP can gracefully inform a peer
 of the need to close a connection.

0:05:15.220000 --> 0:05:20.800000
 You see, if I sent you a string of
 UDP datagrams, bam, bam, bam, bam,

0:05:20.800000 --> 0:05:25.520000
 bam, you'd be sitting there wondering,
 okay, is there more to come?

0:05:25.520000 --> 0:05:27.840000
 Should I sit here
 and wait for more?

0:05:27.840000 --> 0:05:29.200000
 UDP doesn't say, I'm done.

0:05:29.200000 --> 0:05:31.780000
 I'm finished. Send
 you on your way.

0:05:31.780000 --> 0:05:35.260000
 TCP does that. TCP says, finished.


0:05:35.260000 --> 0:05:37.900000
 Goodbye. I'm done with this.

0:05:37.900000 --> 0:05:43.200000
 All right, so let's look at some of the
 TCP header fields with some emphasis

0:05:43.200000 --> 0:05:44.980000
 on this reliability.

0:05:44.980000 --> 0:05:50.540000
 So we know that just like UDP, TCP
 makes use of source and destination

0:05:50.540000 --> 0:05:54.680000
 port numbers. So that is sort
 of common between the two.

0:05:54.680000 --> 0:05:56.520000
 Now, the port numbers
 are different.

0:05:56.520000 --> 0:06:02.540000
 In other words, applications that make
 use of UDP services will have unique

0:06:02.540000 --> 0:06:06.500000
 port numbers that are different than
 applications that make use of TCP

0:06:06.500000 --> 0:06:14.380000
 services. Most applications fall
 on one side or the other.

0:06:14.380000 --> 0:06:18.020000
 If you design that application, that
 programmer had to decide, do I want

0:06:18.020000 --> 0:06:23.080000
 this application to hook into TCP
 or do I want to hook into UDP?

0:06:23.080000 --> 0:06:25.220000
 Usually it's one or the other.

0:06:25.220000 --> 0:06:28.540000
 There are some applications out there
 that actually have hooks into both

0:06:28.540000 --> 0:06:32.780000
 and can choose UDP or TCP to
 do what they want to do.

0:06:32.780000 --> 0:06:34.660000
 But most are not like that.

0:06:34.660000 --> 0:06:37.920000
 Now, we also have
 a sequence number.

0:06:37.920000 --> 0:06:42.680000
 So this is how we can confirm that
 you actually received my data.

0:06:42.680000 --> 0:06:46.160000
 When I send out my TCP segment, there's
 going to be a sequence number

0:06:46.160000 --> 0:06:49.980000
 in there that eventually you are going to
 have to acknowledge in the acknowledgment

0:06:49.980000 --> 0:06:56.400000
 number field. We also have a header
 length about how long the TCP header

0:06:56.400000 --> 0:07:01.760000
 is. Reserve doesn't really
 apply control flags.

0:07:01.760000 --> 0:07:04.460000
 Now, we're not going to talk specifically
 about control flags in this

0:07:04.460000 --> 0:07:05.720000
 particular video.

0:07:05.720000 --> 0:07:10.660000
 That's used more for when you initially
 set up a TCP session from the

0:07:10.660000 --> 0:07:14.200000
 beginning, and that will be covered
 in a subsequent video.

0:07:14.200000 --> 0:07:19.300000
 Window size. This is something that's
 really very fascinating with the

0:07:19.300000 --> 0:07:22.380000
 way TCP works. Now, imagine
 this for a moment.

0:07:22.380000 --> 0:07:29.180000
 Imagine that you are the
 YouTube server, okay?

0:07:29.180000 --> 0:07:32.460000
 You are YouTube, and I
 am a laptop, all right?

0:07:32.460000 --> 0:07:37.140000
 I send a message to you saying, hey,
 can you start playing for me the

0:07:37.140000 --> 0:07:40.160000
 latest Avengers Endgame movie?

0:07:40.160000 --> 0:07:42.680000
 No problem. So you start
 streaming it to me.

0:07:42.680000 --> 0:07:46.600000
 Now, right now, YouTube is the
 only application I have up.

0:07:46.600000 --> 0:07:48.400000
 That's the only thing that
 I'm doing on the network.

0:07:48.400000 --> 0:07:49.300000
 So I'm just sitting back.

0:07:49.300000 --> 0:07:54.240000
 Now, my laptop is receiving the TCP
 video that you're sending down to

0:07:54.240000 --> 0:07:59.660000
 me, okay? Now, let's say all of a sudden
 I start opening up other network

0:07:59.660000 --> 0:08:03.120000
 applications. Maybe another instance
 of YouTube, and another instance

0:08:03.120000 --> 0:08:06.360000
 of YouTube, and start checking
 my email stuff like that.

0:08:06.360000 --> 0:08:10.460000
 Well, all this stuff that's coming into
 my laptop, coming down to me from

0:08:10.460000 --> 0:08:15.140000
 the network, it all has to be stored
 in memory someplace on my laptop,

0:08:15.140000 --> 0:08:18.540000
 while my processor processes
 those packets.

0:08:18.540000 --> 0:08:21.020000
 I've only got a certain
 amount of memory.

0:08:21.020000 --> 0:08:25.600000
 So, when we first started and you were
 the only thing talking to me, all

0:08:25.600000 --> 0:08:26.700000
 that memory was yours.

0:08:26.700000 --> 0:08:29.620000
 You could send me that YouTube video
 as fast as you wanted, and I could

0:08:29.620000 --> 0:08:33.980000
 process it. But as I start opening up
 more and more instances of YouTube,

0:08:33.980000 --> 0:08:38.540000
 and now email and web browsing and other
 stuff, now I start having a problem.

0:08:38.540000 --> 0:08:43.380000
 I start saying, okay, I need you to
 slow down because I'm starting to

0:08:43.380000 --> 0:08:45.040000
 get overwhelmed here.

0:08:45.040000 --> 0:08:47.280000
 That's what the window
 size is for.

0:08:47.280000 --> 0:08:51.600000
 You see, when you send me your TCP segment,
 I'm going to acknowledge it.

0:08:51.600000 --> 0:08:53.480000
 I'm going to say, yep, I got that.


0:08:53.480000 --> 0:08:56.120000
 Now, TCP is a little bit
 more complex than that.

0:08:56.120000 --> 0:08:59.300000
 It's not, you send me one
 segment, I acknowledge it.

0:08:59.300000 --> 0:09:01.520000
 You send me another segment,
 I acknowledge it.

0:09:01.520000 --> 0:09:03.040000
 TCP doesn't work that way.

0:09:03.040000 --> 0:09:06.440000
 Typically, the way TCP works is that
 you can send me a bunch of segments,

0:09:06.440000 --> 0:09:08.600000
 and this will be negotiated.

0:09:08.600000 --> 0:09:09.700000
 I will negotiate with you.

0:09:09.700000 --> 0:09:12.900000
 Hey, you can send me 10 segments, and
 then I'll acknowledge all 10 of

0:09:12.900000 --> 0:09:14.600000
 them, or something
 along that nature.

0:09:14.600000 --> 0:09:21.660000
 But here's the point, is that initially,
 when we do our negotiation of

0:09:21.660000 --> 0:09:25.200000
 our session, I will tell you right
 at the beginning, hey, can you send

0:09:25.200000 --> 0:09:26.520000
 me this YouTube video?

0:09:26.520000 --> 0:09:31.280000
 By the way, you can send me up to like
 15 TCP segments at a time, because

0:09:31.280000 --> 0:09:35.220000
 I'm totally free and clear, and then
 I'll acknowledge that big block.

0:09:35.220000 --> 0:09:38.760000
 So send me big blocks of data at once,
 and then I'll acknowledge it every

0:09:38.760000 --> 0:09:40.260000
 time you do that.

0:09:40.260000 --> 0:09:45.240000
 But as I start freaking out, because
 I've got lots of things going on

0:09:45.240000 --> 0:09:49.740000
 now, my memory's starting to get capped
 out, I can use this window size

0:09:49.740000 --> 0:09:55.660000
 field, and I can say, hey, can you reduce
 that down to maybe six TCP segments?

0:09:55.660000 --> 0:09:59.440000
 I know I previously told you 15, but
 can we shrink it down to like maybe

0:09:59.440000 --> 0:10:02.080000
 six, and then I'll acknowledge it?


0:10:02.080000 --> 0:10:04.200000
 That's what the window
 size is used for.

0:10:04.200000 --> 0:10:08.720000
 It's for me to be able to tell you,
 hey, you can send me more, or you

0:10:08.720000 --> 0:10:10.520000
 need to start sending me less.

0:10:10.520000 --> 0:10:13.960000
 It's a way of me doing flow control,
 controlling the flow of information

0:10:13.960000 --> 0:10:17.200000
 as you're sending it to me.

0:10:17.200000 --> 0:10:22.640000
 We also have a checksum and an urgent
 pointer, and where the urgent pointer

0:10:22.640000 --> 0:10:34.840000
 comes into play is, let's say that, okay,
 let's say that you were a Cisco

0:10:34.840000 --> 0:10:39.080000
 router, and I'm someone who's
 teleneting into you.

0:10:39.080000 --> 0:10:42.580000
 Okay, I'm telene, I'm trying to get
 your command line so I can control

0:10:42.580000 --> 0:10:53.660000
 you. All right, so I'm typing characters
 on my keyboard, okay, and all

0:10:53.660000 --> 0:10:57.340000
 of a sudden there's a problem, and
 I realize, oh, real quickly, I have

0:10:57.340000 --> 0:10:58.400000
 to hit the escape key.

0:10:58.400000 --> 0:11:02.140000
 Something's happening on you as I'm
 typing my characters, and I realize

0:11:02.140000 --> 0:11:05.520000
 that you're about to crash and die,
 so I need to hit the escape key on

0:11:05.520000 --> 0:11:09.180000
 my keyboard and send that to you, and
 I need you to process that escape

0:11:09.180000 --> 0:11:14.220000
 key right now, because if you don't
 process it, something bad's going

0:11:14.220000 --> 0:11:18.940000
 to happen. So this is where, when I
 send you the, when I send you my TSP

0:11:18.940000 --> 0:11:22.280000
 segment that's got the escape key in
 it, I might set the urgent pointer

0:11:22.280000 --> 0:11:25.920000
 saying, hey, this is urgent, you
 need to process this right now.

0:11:25.920000 --> 0:11:29.680000
 Maybe everything I've been sending you,
 you've been storing in your buffer,

0:11:29.680000 --> 0:11:33.420000
 waiting till you got a certain amount
 stored up, and then you're going

0:11:33.420000 --> 0:11:35.220000
 to send it up to your
 CPU for processing.

0:11:35.220000 --> 0:11:41.940000
 The urgent pointer says, now, process
 this, now, this is urgent.

0:11:41.940000 --> 0:11:46.220000
 And then we might have some TCP options,
 and this is why we have a header

0:11:46.220000 --> 0:11:50.340000
 length, because the header of TCP is
 variable in size, and then we have

0:11:50.340000 --> 0:11:55.060000
 our data after that, which in this case
 would be your HTTP data, or your

0:11:55.060000 --> 0:11:57.500000
 FTP data, or something
 along those lines.

0:11:57.500000 --> 0:12:03.380000
 And that concludes this video
 on an introduction to TCP.