NOTE: Catch up with the previous posts in this post series:

Part 1: Overview

The Network Stack has four layers: Application, Transport, Network (or Internet) and Physical. This post will cover the top two layers: Application and Transport and together they help the destination computer identify what type of data it’s receiving through the network.

The application layer has network applications: clients and servers that the users can interact with. Examples of network client applications are web browsers, email apps, etc. Examples of network server applications are web servers, email servers, secure shell (ssh), etc. The network clients connect to network servers to make things work.

The network clients use the operating system’s transport layers and protocols so the two top layers (application and transport) work closely together (TCP and UPD are the most common transport protocols). The network servers listen and respond to actions initiated by network clients by interacting with network ports.

A port is a number that associated with an IP address helps to identify a connection to a specific server in a host. In more simple terms and using an analogy: if I say that I live on 123 Main st, apt 34, the 123 Main st part is the IP, and 34 is the port – literally the door to my house! There are many people living (services running) on 123 Main st but only I live on apt 34 and if you want to pay me a visit, you have to knock on door 34.

By convention there are some ports reserved for specific services and the network standards document RFC6335 lists these ports (it’s also possible to see a list under /etc/services in a Linux computer). Some common ones are:

• 22 for ssh
• 23 for telnet
• 80 for http
• 443 https

So an application can use the TCP protocol to open a connection between one local port on its own computer and a port on a remote host, but the communication will only be established if the remote host has a process listening on that port.

It’s the TCP implementation in the operating system that breaks a stream of data into packets. The packets can arrive out of order and the TCP will be in charge of checking and fixing the stream. In a TCP connection there is back and forth communication and confirmation between client and server.

UDP is a much simpler transport layer protocol: a host sends a message (packet) to a port on a remote server but there’s no check, no corrections, no data stream, only single messages. It’s usually used for video streaming (if one of the packets get lost, it’s no big deal!). While TCP connections resemble a dialogue, the UDP will look more like a monologue.

Troubleshooting the application and transport layers

Even though we can separate the network stack into neat layers, in practice they are tightly connected, so many tools for diagnostics and troubleshooting will end up displaying information from multiple layers.

Here are some ways to find out what is going on primarily in the top two layers – note that these are all command line tools:

lsof

lsof -n -i

List the programs currently using or listening to ports in your localhost (this command also tracks open files). If it’s run as root, it will display processes from multiple users. It can be useful to see which ports are opened and if there are any network client connections. If you’re only interested in one specific port, add that port number to the command as show below:

lsof -n -i:port\_number

ss

ss is the replacement for the now obsolete (and most famous) netstat. It shows sockets statistics and similar information that netstat displays, like all the network connections.

In the command below, the -n is for “numeric” and will display addresses instead of host names and the -t is to limit the output to TCP connections only. This document shows the various states of a TCP connection. If you use option -a, it will display listening and non-listening connections (for TCP, this means all connections in the “established” state).

ss -nt

tcpdump

This will list every packet that is going through your network along with its content, so be mindful when running this command since you will expose all non-encrypted data.

tcpdump has many filters (they are called primitives in this case), and if you’re interested in one specific port, that’s how you run it:

tcpdump port port\_number\_goes\_here

nc

nc, also known as netcat, can connect to remote TCP/UDP ports, listen on ports, scan ports, and some more useful stuff. It only terminates when the other side of the connection ends the connection – you can end a connection by hitting CTRL-C _. You can initiate a TCP connection to a _host on a specific port by running (this is an example of a network client):

nc host port

Or you can listen (sit and wait) for a connection on a specific port by running (this is an example of a network server):

netcat -l -p port\_number\_goes\_here

nmap

nmap will list all accessible port in a remote host, so once again be mindful of using this tool – you might need to ask for permission. To list all accessible port on a host (name or ip), run:

nmap host

Phew! That was lot and yet, believe me, I only scratched the surface. There’s a lot more (much more!) to be said about these two layers. Maybe some other time! I will cover the other layers in future posts.

The post Networking for Developers – part 2: application and transport layers_ was originally published at _flaviabastos.ca