So far, we've mostly focused on TCP, which is a connection-oriented protocol.

A connection-oriented protocol is one that establishes a connection, and

uses this to ensure that all data has been properly transmitted.
A connection at the transport layer implies that every segment of data
sent is acknowledged.
This way, both ends of the connection always know which bits of data have
definitely been delivered to the other side and which haven't.
Connection-oriented protocols are important because the Internet is a vast
and busy place.
And lots of things could go wrong while trying to get data from point
A to point B.
You might remember from our lesson about the physical layer that even some minor
crosstalk from a neighboring twisted pair in the same cable can be enough to make
a cyclical redundancy check fail.
This could cause the entire frame to be discarded, yikes.
If even a single bit doesn't get transmitted properly,
the resulting data is often incomprehensible by the receiving end.
And remember that at the lowest level,
a bit is just an electrical signal within a certain voltage range.
But there are plenty of other reasons why traffic might not reach its destination
beyond line errors.
It could be anything.
Pure congestion might cause a router to drop your traffic in favor of forwarding
more important traffic.
Or a construction company could cut a fiber cable connecting two ISPs,
anything's possible.
Connection-oriented protocols, like TCP, protect against this by forming
connections and through the constant stream of acknowledgments.
Our protocols at lower levels of our network model, like IP and Ethernet,
do use checksums to ensure that all the data they received was correct.
But did you notice that we never discussed any attempts at resending data that
doesn't pass this check?
That's because that's entirely up to the transport layer protocol.
At the IP or Ethernet level, if a checksum doesn't compute,
all of that data is just discarded.
It's up to TCP to determine when to resend this data.
Since TCP expects an ack for every bit of data it sends,
it's in the best position to know what data successfully got delivered and
can make the decision to resend a segment if needed.
This is another reason why sequence numbers are so important.
While TCP will generally send all segments in sequential order,
they may not always arrive in that order.
If some of the segments had to be resent due to errors at lower layers,
it doesn't matter if they arrive slightly out of order.
This is because sequence numbers allow for
all of the data to be put back together in the right order.
It's pretty handy.
Now, as you might have picked up on,
there's a lot of overhead with connection-oriented protocols like TCP.
You have to establish the connection.
You have to send a stream of constant streams of acknowledgements.
You have to tear the connection down at the end.
That all accounts for a lot of extra traffic.
While this is important traffic, it's really only useful if you absolutely,
positively have to be sure your data reaches its destination.
You can contrast this with connectionless protocols.
The most common of these is known as UDP, or User Datagram Protocol.
Unlike TCP, UDP doesn't rely on connections, and
it doesn't even support the concept of an acknowledgement.
With UDP, you just set a destination port and send the packet.
This is useful for messages that aren't super important.
A great example of UDP is streaming video.
Let's imagine that each UDP datagram is a single frame of a video.
For the best viewing experience, you might hope that every single frame makes
it to the viewer, but it doesn't really matter if a few get lost along the way.
A video will still be pretty watchable unless it's missing a lot of its frames.
By getting rid of all the overhead of TCP,
you might actually be able to send higher quality video with UDP.
That's because you'll be saving more of the available bandwidth for
actual data transfer, instead of the overhead of establishing connections and
acknowledging delivered data segments.

Application layer
Welcome to our lesson about the application layer.
We're almost done covering all aspects of our networking module,
which means you've already learned how computers process electrical or
optical signals to send communication across a cable, at the physical layer.
We've also covered how individual computers can address each other and
send each other data using ethernet at the data link layer.
We've discussed how the network layer is used by computers and
routers to communicate between different networks using IP.
And in our last lesson, we covered how the transportation layer
ensures that data is received and sent by the proper applications.
You're chock full of layers of new information.
Now, we can finally talk about how those actual applications send and
receive data using the application layer.
Just like with every other layer,
TCP segments have a generic data section to them.
As you might have guessed, this payload section is actually the entire contents of
whatever data applications want to send to each other.
It could be contents of a web page, if a web browser is connecting to a web server.
This could be the streaming video content of your Netflix app on your PlayStation
connecting with the Netflix servers.
It could be the contents of a document your word processor is sending
to a printer.
And many more things.
There are a lot of protocols used at the application layer,
and they are numerous and diverse.
At the data link layer, the most common protocol is ethernet.
I should call out that wireless technologies do use other protocols at
this layer, which we'll cover in a future module.
At the network layer, use of IP is everywhere you look.
At the transport layer, TCP and UDP cover most of the use cases.
But at the application layer, there are just so
many different protocols in use, it wouldn't make sense for us to cover them.
Even so, one concept you can take away about application layer protocols
is that they're still standardized across application types.
Let's dive a little deeper into web servers and web browsers for an example.
There are lots of different web browsers.
You could be using Chrome, Internet Explorer, Safari, you name it.
They'll need to speak the protocol.
The same thing is true for web servers.
In this case, the web browser would be the client, and
the web server would be the server.
The most popular web servers are Microsoft IIS, Apache, and nginx.
But they also need to speak the same protocol.
This way, you ensure that no matter which browser you're using,
you'd still be able to be speak to any server.
For web traffic, the application layer protocol is known as HTTP.
All of these different web browsers and web servers have to communicate using
the same HTTP protocol specifications in order to ensure interoperability.
The same is true for most other classes of application.
You might have dozens of choices for an FTP client, but
they all need to speak the FTP protocol in the same way.

All the layers

Now that you know the basics of how every layer of out network model works, let's go
through an exercise to look at how everything works at every step of the way.
Spoiler alert, things are about to get a little geeky, in a good way.
Imagine three networks, network A will contain address space 10.1.1.0/24.
Network B Will contain address space 192.168.1.0/24,
and network C will be 172.16.1.0/24.
Router A sits between network A and network B.
With an interface configured with an IP of 10.1.1.1 on network A,
and an interface at 192.168.1.254 on network B.
There's a second router, router B, which connects networks B and C.
It has an interface on network B with an IP address of 192.168.1.1,
and an interface on network C with an IP address of 172.16.1.1.
Now let's put a computer on one of the networks.
Imagine it's a desktop, sitting on someone's desk at the workplace.
It'll be our client in this scenario, and we'll refer to it as computer 1.
It's part of Network A and has been assigned an IP address of 10.1.1.100.
Now, let's put another computer on one of our other networks.
This one is a server in a data center, it'll act as our server in this scenario,
and we'll refer to it as computer 2.
It's part of network C, and has been assigned an IP address of
172.16.1.100, and has a web server listening on port 80.
An end user sitting at computer 1 opens up a web browser and
enters 172.16.1.100 into the address bar, let's see what happens.
The web browser running on computer 1 knows it's been ordered to
retrieve a web page from 172.16.1.100.
The web browser communicates with the local networking stack, which is the part
of the operating system responsible for handling networking functions.
The web browser explains that it's going to want to establish
a TCP connection to 172.16.1.100, port 80.
The networking stack will now examine its own subnet.
It sees that it lives on the network 10.1.1.0/24,
which means that the destination 172.16.1.100 is on another network.
At this point, computer 1 knows that it'll have to send any data to its gateway for
routing to a remote network.
And it's been configured with a gateway of 10.1.1.1.
Next, computer 1 looks at its ARP table to determine what MAC address
of 10.1.1.1 is, but it doesn't find any corresponding entry.
Uh-oh, it's okay, computer A crafts an ARP request for
an IP address of 10.1.1.1,
which it sends to the hardware broadcast address of all Fs.
This ARP discovery request is sent to every node on the local network.
When router A receives this ARP message, it sees that it's the computer
currently assigned the IP address of 10.1.1.1.
So it responds to computer 1 to let it know about its
own MAC address of 00:11:22:33:44:55.
Computer 1 receives this response and now knows the hardware address of its gateway.
This means that it's ready to start constructing the outbound packet.
Computer 1 knows that it's being asked by the web browser to form
an outbound TCP connection, which means it'll need an outbound TCP port.
The operating system identifies the ephemeral port of 50000 as being
available, and opens a socket connecting the web browser to this port.
Since this is a TCP connection, the networking stack knows that before
it can actually transmit any of the data the web browser wants it to,
it'll need to establish a connection.
The networking stack starts to build a TCP segment.
It fills in all the appropriate fields in the header,
including a source port of 50000 and a destination port of 80.
A sequence number is chosen and is used to fill in the sequence number field.
Finally, the SYN flag is set, and a checksum for the segment is calculated and
written to the checksum field.
Our newly constructed TCP segment is now passed along to the IP layer
of the networking stack.
This layer constructs an IP header.
This header is filled in with the source IP, the destination IP, and
a TTL of 64, which is a pretty standard value for this field.
Next, the TCP segment is inserted as the data payload for the IP datagram.
And a checksum is calculated for the whole thing.
Now that the IP datagram has been constructed,
computer 1 needs to get this to its gateway, which it now knows
has a MAC address of 00:11:22:33:44:55,
so an Ethernet Datagram is constructed.
All the relevant fields are filled in with the appropriate data, most notably,
the source and destination MAC addresses.
Finally, the IP datagram is inserted as the data payload of the Ethernet frame,
and another checksum is calculated.
Now we have an entire Ethernet frame ready to be sent across the physical layer.
The network interface connected to computer 1 sends this binary data
as modulations of the voltage of an electrical current running across
a CAT6 cable that's connected between it and a network switch.
This switch receives the frame and inspects the destination MAC address.
The switch knows which of its interfaces this MAC address is attached to,
and forwards the frame across only the cable connected to this interface.
At the other end of this link is router A, which receives the frame and
recognizes its own hardware address as the destination.
Router A knows that this frame is intended for itself.
So it now takes the entirety of the frame and calculates a checksum against it.
Router A compares this checksum with the one in the Ethernet frame header and
sees that they match.
Meaning that all of the data has made it in one piece.
Next, Router A strips away the Ethernet frame,
leaving it with just the IP datagram.
Again, it performs a checksum calculation against the entire datagram.
And again, it finds that it matches, meaning all the data is correct.
It inspects the destination IP address and
performs a lookup of this destination in its routing table.
Router A sees that in order to get data to
the 172.16.1.0/24 network, the quickest path is one hop away via
Router B, which has an IP of 192.168.1.1.
Router A looks at all the data in the IP datagram,
decrements the TTL by 1, calculates a new checksum reflecting
that new TTL value, and makes a new IP datagram with this data.
Router B knows that it needs to get this datagram to router B,
which has an IP address of 192.168.1.1.
It looks at its ARP table, and sees that it has an entry for
192.168.1.1.
Now router A can begin to construct an Ethernet frame
with the MAC address of its interface on network B as the source.
And the MAC address on router B's interface on network B as the destination.
Once the values for all fields in this frame have been filled out,
router A places the newly constructed IP datagram into the data payload field.
Calculates a checksum, and places this checksum into place, and
sends the frame out to network B.
Just like before, this frame makes it across network B, and
is received by router B.
Router B performs all the same checks, removes the the Ethernet
frame encapsulation, and performs a checksum against the IP datagram.
It then examines the destination IP address.
Looking at its routing table,
router B sees that the destination address of computer 2, or
172.16.1.100, is on a locally connected network.
So it decrements the TTL by 1 again, calculates a new checksum, and
creates a new IP datagram.
This new IP datagram is again encapsulated by a new Ethernet frame.
This one with the source and destination MAC address of router B and computer 2.
And the whole process is repeated one last time.
The frame is sent out onto network C,
a switch ensures it gets sent out of the interface that computer 2 is connected to.
Computer 2 receives the frame, identifies its own MAC address as the destination,
and knows that it's intended for itself.
Computer 2 then strips away the Ethernet frame, leaving it with the IP datagram.
It performs a CRC and recognizes that the data has been delivered intact.
It then examines the destination IP address and recognizes that as its own.
Next, computer 2 strips away the IP datagram,
leaving it with just the TCP segment.
Again, the checksum for this layer is examined, and everything checks out.
Next, computer 2 examines the destination port, which is 80.
The networking stack on computer 2 checks to ensure that there's an open
socket on port 80, which there is.
It's in the listen state, and held open by a running Apache web server.
Computer 2 then sees that this packet has the SYN flag set.
So it examines the sequence number and stores that, since it'll need to put that
sequence number in the acknowledgement field once it crafts the response.
After all of that, all we've done is get a single
TCP segment containing a SYN flag from one computer to a second one.
Everything would have to happen all over again for
computer 2 to send a SYN-ACK response to computer 1.
Then everything would have to happen all over again for
computer 1 to send an ACK back to computer 2, and so on and so on.
Looking at all of this end to end hopefully helps show how all the different
layers of our networking model have to work together to get the job done.
I hope it also gives you some perspective in understanding how remarkable computer
networking truly is.
Even more remarkable than that, you [LAUGH] for making it through this module.
Now it's time to apply your new knowledge to the next assessment.
When you're done, I'll see in the next video, but first, another quiz,
you got this.
But even if you don't,
just review the material until you get more comfortable with this stuff.