Purpose
To begin to understand how a computer communicates on the modern network you need to understand network ports and sockets in TCP/IP. This is probably the most basic concept to networking. In Windows, and in other platforms, there are some tools that will also help us in reviewing our ports and connections on any given machine. I have no plan to rewrite was has already been written, so if you are looking to learn how these protocols work at a deep level, please refer to the tomes already written. What we will cover are the basic high-level concepts that go along with ports and sockets to get a conceptual understanding of how these are used so that we can improve in our troubleshooting and administrative functions.
If you are looking for the depth of knowledge I would suggest the MSPress Books by Joseph Davies; I have read the Cybex, Cisco press, O’Reilly and some others when I was trying to first learn networking (and since to hone my skills), and I have to say that these books by Joseph Davies are far and beyond the best I have ever read. In fact I make it a point to read as many of his books as I can since I learn so well from his teaching. Here are some links.
2000 <-Read once, partially.
2003 <-I’ve read this one 11 times in total, my 2nd favorite book J
2008 <-Read once, partially
Note: If you are looking to buy any of these I would highly recommend that you look on half.com or some other similar site. One year I bought ~10 of these around Christmas, and gave them out as gifts to co-workers, not my most popular Christmas, but what can I say, I loved the book.
I will be using the terms Client and Server throughout this document. I use these in the most theoretical terms. for further explanation please see: What is a Network Client
A Network Port
Chances are you are familiar with the term a network port. It is basically an identifier that we use when networking to indicate what service a network packet is destined for, or sent from. Imagine that we did not use these ports. Two computers may exchange data on the network. Each of these computers could send and receive data, but when the computer receiving the data tries to send it to the applicable service or application, if there were more than one, how would it know where it goes? Ports allow us to run thousands of applications and services on a single machine without stepping on each other while communicating on the network.
Historically there are 2 types of ports used in TCP/IPv4. The first are well-known ports. These are ports 1 – 1024. Then there are “High” or “Ephemeral” ports. These are 1025-65535 [Note: Well-known ports have now extended into the historical High-Port range]. Typically when a Client is connecting to a service provided on another host it will set the destination port to the well-known port for that service. For instance CIFS, used for network file sharing, uses TCP port 445. Most Client applications do not have a set, well-known port to use as their source, so they allow TCP to choose randomly from the pool of available ephemeral ports.
A Network Socket
Understanding of a network socket is a bit more elusive, though the concept is very simple. A network socket (or winsock) is simply the combination of an IP and port such as 1.1.1.1:445 (See RFC 147). We use a socket to initialize and track a network connection. For instance, when establishing a network connection between two hosts, I will source the initial packet (and all following packets) from my network socket, and send to yours. When you receive the packet you will swap the source and destination and add this to your connections table. Let’s look at this in an example of a remote file share connection (using CIFS, TCP 445).
Client IP – 1.1.1.1
Server IP – 2.2.2.2
When the Client initializes the connection is will send to the Servers IP and the well-known port for CIFS. The Server side socket will look like this: 2.2.2.2:445
The Client will source the packet from its IP address , and since file sharing applications do not typically use a well-known source port (nor do many applications at all), it will choose from a random high port, let’s say 1025. So the Client side socket will look like this: 1.1.1.1:1025
Together these make a connection. The only difference between the Client and the Server will be the perspective of who sent and who received. This means that what the Client used as a destination socket, the Server uses as a source socket, and vice versa. Here is an example:
Source Destination
On the Client 1.1.1.1:1025 2.2.2.2:445
On the Server 2.2.2.2:445 1.1.1.1:1025
Port States
Every network port on a Server or Client is in a certain state. The state of the network port determines what can and cannot be done with it. For instance in our situation above, for the Client to have made a successful connection to the Server on TCP port 445, the Server would have needed to have the port in the Listening state. This means that there is a service on the Server listening for incoming connections to that port. The states you can be in depend on the protocol that you use. For instance UDP has no Established state, as it is connectionless. The only two states we will concern ourselves with in this document, are the Listening (UDP/TCP) and the Established (TCP) states. For more details on port/connection states, see one of the TCP/IP tech references (2000, 2003, 2008)
Tools
During troubleshooting I often find the need to know what ports a Server is listening on or what connections are active to any given Server. From here you can glean how many Clients are benefiting from this Server, what services it is providing to network clients and what connections are active. Microsoft has two sets of fantastic tools to help us administer our devices in this way.
Netstat
Netstat is a command line tool built into every version of windows from Win7 / 2008 all the ways back to NT and DOS. There is even a version for Unix based OSs. Reviewing the output given from Netstat can really help to better understand network ports. Let’s take a look at the Netstat output for our network file sharing example from above.
(view in a Netstat -ano output on the Client):
Proto Local Address Foreign Address State PID
TCP 1.1.1.1:1025 2.2.2.2:445 ESTABLISHED 4
(view in a Netstat -ano output on the Server):
Proto Local Address Foreign Address State PID
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING 4
TCP 2.2.2.2:445 1.1.1.1:1025 ESTABLISHED 4
On the Server side of things we see one thing we do not see on the client, the listening port. This is basically a port that is opened by a service in a passive state, meaning that the service is saying something like “I do not have anything to send at the moment, but if someone sends me something, I am all ears”. This listening port is how nearly every network conversation starts. You will notice that the IP of the listening port is 0.0.0.0; this is the unspecified address, meaning basically any IP (On the Server-side any IP it has, on the Client-side any IP that the Server does not have). For a Server to truly be a network resource this is needed, otherwise Client could never make a connection. [Note:If a client tries to connect to a server on a port that it is not listening on, the client connection will fail, usually with a TCP Reset, and maybe a “ICMP-Destination Port Unreachable” message].
There is one other key to note from this Netstat output, and that is the final column or the PID. Many of you probably recognize this, but for those that may not, this is the Process Identifier. You can map this back to the service or application that opened this port on this local machine. To do this, you can use taskmgr, TCP View,… or our next command line tool.
Tasklist
Tasklist is a great command line tool, and in conjunction with Netstat, gives us a very quick, and in box (meaning that it is installed with the OS itself), method to find out what connections we have, and what service made them. In our example above we see that in the Established and Listening connections we have the PID of 4. This is a well-known PID, not in the sense that it is necessarily reserved, but in the sense that pretty much every time you see it you know the process it is referring to; System. But, what if you did not know? In most instances you may have an idea what service or application is using what port, but here is how you can be sure, even if the process is running in a svchost instance. At a command line run: tasklist /svc
Here is a sample output:
Image Name PID Services
========================= ======== ====================
System Idle Process 0 N/A
System 4 N/A
smss.exe 268 N/A
csrss.exe 384 N/A
lsass.exe 516 KeyIso, ProtectedStorage, SamSs
winlogon.exe 620 N/A
svchost.exe 748 RpcEptMapper, RpcSs
So now between the netstat -ano and tasklist /svc outputs we know what network connections are established, who they are established to, and what service/application established/received those connections. Over the years this has become second nature to me, and it has really improved my troubleshooting skills, hopefully it will do the same for you.