Google IT Cert – Week 9 – Transport and Application Layers

This is week 9 of the Google Professional IT Certification course on

.   .   .

Introduction to the Transport and Application Layers

an illustration of a 5 layer networking model
The 5-Layer Networking model.

This week we’re continuing on with the two final layers in the ol’ 5-layer network protocol model. The first three layers deal with nodes communicating to other nodes on a LAN or on a remote network. Now, we will be looking at how programs communicate with each other. The whole point of networking computers together is to be able to have programs share data with each other. I guess I had never thought about that but yes, that is the whole point.

The Transport Layer “allows traffic to be directed to specific network applications,” while the Application Layer “allows these applications to communicate in a way they understand.”


The transport layer is responsible for some very essential functions, including multiplexing and demultiplexing traffic, making long-running connections and verifying data integrity by checking and data verification.

Multiplexing means that the transport layer, unique in this capability, allows nodes on the network to send traffic to multiple receiving services. Demultiplexing is that process in reverse and at the receiving end, allowing multiple pieces of traffic coming in to the same node to be delivered to the appropriate receiving service.

illustration of the concept of multiplexing and demultiplexing
Multiplexing and demultiplexing.

Multiplexing and demultiplexing is accomplished by the transport layer by using ports. “A port is a 16-bit number that’s used to direct traffic to specific services running on a networked computer.” This is accomplished by utilizing the concept of the client/server relationship, where one service (server) sends data to another service when requested (client), and “listens” on specific ports for incoming requests.

For example, port 80 is used for HTTP, or unencrypted web traffic. The port is usually denoted after the IP address, so when a server sends back data about a webpage at, it will be received by whichever service requested data from that IP on port 80. This notation of IP address and port is known as a socket address or socket number.

This same computer could also be using File Transfer Protocol (FTP), which is an older protocol used for sending files between computers, but it is still used today. FTP usually listens on port 21, so to connect to an FTP service on that same computer we would direct traffic to

Dissection of a TCP Scheme

When network traffic is misbehaving, an IT support tech may need to closely analyze that traffic in order to troubleshoot. Huh… makes sense.

The same way an Ethernet frame encapsulates an IP datagram, and IP datagram encapsulates a TCP segment. The payload section of an Ethernet frame is just the contents of an IP datagram. An IP datagram also has a payload section, and this is the TCP Segment. A TCP segment is made of a TCP header and a data section. This data section is another payload section, where the Application layer places data.

So many layers!

The TCP Header is made of many fields containing many pieces of data.

  • Source Port/Destination Port: (16 bits each) The destination port is the port of service the traffic is intended for. The source port is “a high-numbered port chosen from a special section of ports known as ephemeral ports.” These are important so that data is sent to the application that requested it.
  • Sequence Number: 32 bits – used to keep track of where in a sequence of TCP segments this one is supposed to go, because any operation is going to require long sequences of packets.
  • Acknowledgement Number: 32 bits – this works along with the sequence number. It is the number of the next expected segment. In theoretical terms, if a sequence number is 1, and the acknowledgement number is 2, the application receiving the data can expect sequence number 2 after number 1.
  • Data Offset Field (Header Length): 4 bits – communicates how long the TCP header is for this segment.
  • [empty] 6 bits:
  • Control Flags: 6 bits – explanation coming in a video later
  • TCP Window: 16 bits – “specifies the range of sequence numbers that might be sent before an acknowledgment is required.” This helps make sure that the sending device is only sending data that is likely to be received.
  • Checksum: 16 bits – just like the checksums at the IP and Ethernet layers, the checksum is calculated at the receiving end after all the data in a segment has been received, and is calculated for the entire segment (and compared to the checksum in the header), to make sure that no data has been lost or corrupted.
  • Urgent Pointer Field: 16 bits – used in conjunction with one of the TCP control flags to highlight segments that may be more important than others. This is an old feature that may not be used very much anymore.
  • Options Field: (0 to 16 bits) – Again, rarely used anymore, but can be used for “more complicated flow control protocols.”
  • Padding: (varies) – a series of zeroes to ensure that the payload section begins at the expected place.
  • Data Payload.

 TCP Control Flags and the Three-way Handshake

TCP is a protocol that creates connections to send long strings of data segments. This contrasts with other protocols at lower layers of our networking model, like Ethernet and IP, which only send individual packets. TCP creates these connections by using TCP Control Flags in a very specific order.

The first flag is known as URG, or “urgent.” This is defined as “a value of one here indicates that the segment is considered urgent and that the urgent pointer field has more data about this.” Again, this “feature” has never been widely used and you will not normally see it.

The second flag is ACK, which stands for “acknowledged.” A value of 1 in this field means that the acknowledgement number field should be inspected.

The third flag is PSH, or “push.” This means that the sending device wants the receiving device to send any currently-buffered data to the receiving application as soon as possible. Buffering is a computing procedure that means a block of data is held in one place before being sent somewhere else. In terms of TCP, this helps send large pieces of data more efficiently.

Next is the RST flag, or “reset.” This is used when one side of a TCP connection has not been able to “recover” from a series of missing or “malformed” segments. This allows one device to say to the other, “wait, I have no idea what you’re telling me—just start over from the beginning.”

The fifth flag is SYN (synchronize), used when the TCP connection is first established, to ensure that the receiving device knows to examine the sequence number field.

The final flag is FIN, which means “finish.” When this field has a value of 1 it means the sending computer has no more data to send and the connection may be closed.

Here is kind of a typographical illustration

Computer A and B are establishing a TCP connection:




This process, the initial SYNCHRONIZE, the response of SYNCHRONIZE/ACKNOWLEDGEMENT, and the final responding ACKNOWLEDGEMENT, is known as the Three-Way Handshake. A handshake, in computer networking is a way for devices to establish that they are both using the same protocol and will be able to communicate.

After this handshake in the example here, both computers have established the TCP connection and may communicate. Once both computers have each sent a SYN/ACK pair to each other they are operating in full duplex, and any segment sent in either direction will be responded to by a TCP segment with the ACK field set.

When one of the devices is ready to close the connection, something called a Four-Way Handshake occurs. Here, computer B is closing the connection:





In theory, a TCP connection can stay open in simplex mode, but this does not happen. Virtually every time a connection is closed by one device the four-way handshake takes place and the connection is closed completely.

 TCP Socket States

A socket is “the instantiation of an end-point in a potential TCP connection.” What the hell does this mean? An instantiation is defined here as “the actual implementation of something defined elsewhere.” Okay, well, great… what does that mean?

TCP sockets require that programs “instantiate” them, whereas, for example, ports are just “more of a virtual, descriptive thing.” I hate to say it but I may understand what what’s-his-face is talking about.

Put another way: A program can send traffic to any port it wants, but will only get a response if a program has opened a socket on that port.

Here are some of the most common states that a TCP socket can be set to:

LISTEN: A TCP socket is ready and listening for incoming connections. This is only seen on the server side.

SYN_SENT: A synchronization request has been sent but the connection has not yet been created. This is only seen on the client side.

SYN-RECEIVED: A socket that was in a LISTEN state received a SYN request and has sent back a SYN/ACK, but has not received the final ACK from the client. This is seen on the server side only.

ESTABLISHED: The TCP connection is fully created and working properly and both sides can send data back and forth to each other. This state is seen on both the client and server.

FIN_WAIT: A FIN has been sent but the ACK from the other device has not been received. This state is seen on both client and server.

CLOSE_WAIT: The connection has been close “at the TCP layer,” but the application that opened the socket has not “released” the socket yet. (Both client and server sides.)

CLOSED: The connection has been terminated and communication is no longer possible. (Client and server sides.)

There are other socket states that exist, and it is important to remember that socket state names can vary between operating systems. TCP is a protocol, so it must function universally, but how things are described can change, so be sure to understand the terminology for whatever systems you’re working with.

Connection-Oriented and Connectionless Protocols

TCP is what is known as a connection-oriented protocol, meaning that two devices establish a link and send and receive data and validate that those transmissions have been properly received. A transport layer connection assures that every segment of data sent is acknowledged when it is received.

Because a bit is just an electrical signal within a specific voltage range, there is a very real need for connection-oriented protocols.

While the lower-layer protocols like IP and Ethernet use checksums to validate data, they do not go as far as TCP. TCP establishes a connection that will require data to be re-sent if it is not properly received.

The sequence numbers are very important for just that reason – if a segment of TCP data is lost and re-sent, it will not arrive along with its neighboring segments. It is because of the sequence numbers that the data will be able to be reconstructed properly.

Connection-oriented protocols like TCP require a lot of overhead to work properly. Think about all those handshakes and acknowledgements. But if all that quality control isn’t necessary, there are connectionless protocols.

The most common connectionless protocol is User Datagram Protocol, or UDP. Unlike TCP, UDP doesn’t require any connections or acknowledgements. UDP simply sets a destination port and sends the packets. This is useful for traffic that isn’t “that important.” An example of UDP is streaming video: If one datagram is one frame of video (in the real world I don’t think it is) you would like to have each frame arrive at the right time and in good working order. But if one frame is missing, at 60 frames-per-second, say, it won’t really matter to the viewer if that one frame is missing. UDP allows for less bandwidth usage when the data being sent is not as critical.

System Ports vs Ephemeral Ports

This is a reading section all about ports.

A port is a 16-bit number, used to represent a location for data to be delivered in the multiplexing/demultiplexing setup we have in the transport layer. A 16-bit number can be anything from 0 to 65,535.

The IANA has decreed that ports are split up into sections thusly:

Port 0 is not used for network traffic, but can be used for communication between programs on the same computer.

Ports 1-1023 are known as system ports, or well-known ports. These are the “official” ports for common network services like HTTP (port 80), FTP (port 21). Most operating systems require admin-level creds to start a program that listens on a system port.

Ports 1024-49,151 are known as registered ports. These are used for many network services that may not be as common as those used by system ports.  Port 3306 is used by many databases. A registered port is usually registered with the IANA, but not always. On most systems any user can start a program that listens on a registered port.

Ports 49,152 to 65,535 are typically (in most OS and in this course) are known as the ephemeral ports, used for outbound connections. While the exact ranges of registered ports and ephemeral ports will vary, it is important to know that a modern OS will never use a system port for outbound communication.

There is an extended reading on TCP/UDP ports and services here.


A firewall is “a device that blocks traffic that meets certain criteria.” This is a critical concept and is a foundation of network security, as it keeps unwanted traffic from entering your network.

There are firewalls that can inspect traffic at the application layer, as well as simply blocking ranges of IP addresses. But they are most commonly working in the transport layer, configured to block traffic to certain ports, while allowing traffic to other ports.

A simple example would be a small business with a server and several workstations. The server is acting as a fileshare for the LAN, but is also hosting a website. The firewall can allow any traffic on port 80 (HTTP) so that people can view the website, but block any external IP address from using any other port.

All major operating systems have built-in firewalls, and they are also commonly built into routers.

Bam! Quiz time.


This layer is the final layer in the 5-layer networking model we’ve been using. All the previous layers “support” the application layer, which allows computer programs to utilize computer networking.

As we already mentioned, TCP segments have a “payload” section, which contains all the data any applications actually want to send to each other.

There are many, many different protocols used in the application layer, but they are all still standardized. You may have lots of different browsers but they all need to use the same application protocols. The same goes for web servers, the most common being Microsoft IIS, Apache, and nginx. Because protocols are followed, any browser can speak to any web server. The protocol used for web pages is HTTP, or HTTPS.

There are dozens of FTP clients, but they all communicate using the same FTP protocols. The “P” means “protocol.”


 The Application Layer and the OSI Model

We have been working with a simplified 5-layer networking model. There are tons of different ways to represent these concepts, including 4-layer, 7-layer, and everything else. But a common one found in the networking world is called the Open Systems Interconnection Model, or OSI Model.

The OSI model is rigorously defined, so it is something of a standard across the industry. It is a 7-layer model adding a Session Layer and Presentation Layer between the Transport and Application layers.








The Session layer is responsible for “facilitating” communication between applications and the transport layer. It takes all the data from the lower layers and un-encapsulates it, handing it off to the presentation layer.

This presentation layer takes that un-encapsulated application layer data and makes sure that it can be understood by the application. This is the part of the OS where encryption or compression may take place.

With these two layers there is no encapsulation taking place, which means that we have been considering the session layer and presentation layer as part of the application layer in the 5-layer model.

Best to be familiar with both.

All the Layers Working in Unison

This is a really involved video presenting some “exercise” scenarios for this week’s lessons on the Transport and Application layers. This is a point-by-point explanation of the last three weeks. I am not going to write this all out. Lots of IP addresses!

So, in conclusion, 3 weeks of work go into sending one TCP SYN request from one computer to another.



This week: 15 question quiz and some kind of peer-graded assignment.

I got 14/15 on the quiz because I said “multiplexing” instead of “demultiplexing.” I need to review this.

“In your own words, describe what happens at every step of our network model when a node on one network establishes a TCP connection with a node on another network. You can assume that the two networks are both connected to the same router.”

Let’s say that computer A wants to get a webpage from computer B. First, an application, such as a browser, on computer A creates a TCP request to its local network stack. It consults its own routing table and determines that the connection it wants to make is on another network, because the web site’s address is outside its own LAN’s IP range, meaning it will have to send all traffic to its own gateway, the router, first.

Next, the sending node creates an ARP broadcast, using the MAC address FF:FF:FF:FF:FF:FF, indicating that it needs to find the device with the IP of the website.

When the router receives the ARP message, it responds to computer A with its own MAC address, and can begin creating the packet to send to the web server.

Because this is a TCP connection it will need to use a TCP port to establish the connection with the server, which is determined by the network stack of the OS.The TCP segment (Transport layer) is created with the flag SYN in the TCP header, along with the sequence number, all of which is then encapsulated in the Network Layer IP datagram, which calculates the checksum..

This is all encapsulated in the Ethernet frame at the data link layer, where another checksum is calculated and the TTL is set at 64.

This is then sent over the physical layer to the router over wifi or Ethernet, using 802.11 or 10 base T.

The router checks the Ethernet frame checksum and inserts its own IP and MAC address in the Source fields of the headers, and re-encapsulates them all in new datagram and Ethernet Frame. TTL is deprecated by 1. This packet is then sent to the receiving node, where the same process will happen again with a new TCP segment including a SYN/ACK flag.

We’ll have to wait and see how the rest of the class grades my assignment, but until then, I’m going to go back and watch the subnetting videos from last week again and again.

Next week, we are on to WEEK 10 of the course, (Week 4 of Course II) Networking Services.

AmazonBasics Lightning to USB A Cable - Apple MFi Certified - White - 6 Feet

Garmin 010-03717-54 Forerunner 235 - Black/Gray

WD 4TB Elements Portable External Hard Drive - USB 3.0



One thought on “Google IT Cert – Week 9 – Transport and Application Layers”

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.