This lesson looks at the nature of network connections. We'll introduce the concept of ports, which help connect network packets to particular software and services. Then we'll discuss two protocols, TCP and UDP, that define how network packets move from one host to another.
http://www.usna.edu/, the browser asks for the name to be resolved by DNS and discovers it's 22.214.171.124, and then sends its GET request to 126.96.36.199 on port 80 because everyone "knows" web servers use port 80 (it is a "convention").
:then the number after the domain name (or IP Address). For example
http://www.usna.edu:80tells the browser to use port 80 (which it would've done anyway), while
http://www.usna.edu:53tells the browser to use port 53. This request will fail, of course, because USNA's web server isn't listening on port 53, it's listening on 80. DNS name servers listen on port 53.
netstatrequires an Administrator shell.
netstatthat shows you what port/protocol combinations are currently in use on your machine (It's a shell utility on both Windows and UNIX). A sample netstat output might include an entry like this:
Active Internet connections Proto Local Address Foreign Address State ... TCP 10.53.33.254:60503 188.8.131.52:https ESTABLISHED ...
iad23s07-in-f21.1e100.netwas one of Google's mail servers because I had my gmail account open at the time and I know it uses HTTPS because of the lock icon displayed in Chrome's location bar. I confirmed my suspicion by running
nslookup mail.google.com, which resolved to the same address of 184.108.40.206.
What this tells us is that there is an established
connection between my machine (10.53.33.254) on port 60503 and a server at 220.127.116.11.
nslookup 18.104.22.168 tells me that's the address
for iad23s07-in-f21.1e100.net, which I know to be a Google mail server
because that's the only secure web page I had open at the time) bound
to the port associated with the https protocol, which my list of port
numbers tells me is port 443.
I can view all server processes running on my machine by name and
process ID by running
netstat with the following
options in an Administrator shell:
C:\> netstat -bno Active Connections Proto Local Address Foreign Address State PID TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 900 RpcSs [svchost.exe] TCP 0.0.0.0:3389 0.0.0.0:0 LISTENING 1448 CryptSvc [svchost.exe] TCP 0.0.0.0:49152 0.0.0.0:0 LISTENING 544 [wininit.exe] TCP 0.0.0.0:49376 0.0.0.0:0 LISTENING 608 [services.exe] UDP 0.0.0.0:68 0.0.0.0:0 LISTENING 988 Dhcp [svchost.exe] ⋮
netstat -alnpHowever, to really get all the process numbers and program names, you should run this as
root, i.e. run it like this:
sudo netstat -alnpWe can correlate the
netstatoutput with the output of
psto determine the names of the programs that are using networked services; e.g.
nk) is a very flexible and powerful tool. It can be used in mode similar to a "client" or a "server".
-loption (listen) and nk then acts like a server, "listening" for a connection request, accepting the first one it receives, then echoing whatever gets sent to it to the screen, and taking whatever gets typed on the screen and sending it to the client whose connection request it accepted.
nccommand instead of the
nkcommand. Actually, netcat was the original program written for UNIX and was then ported to Windows. For this class we use a slightly different version named netkitten. The UNIX netcat (
nc) and the Windows netkitten (
nk) are for the most part identical.
nc), see the manual page. To do this, open up a rona shell and type:
$ man nc
-uoption (UDP) uses UDP instead of TCP. Since this is connectionless, the server version accepts datagrams from any and all who send them, rather than making a connection with one client. As another consequence, the UDP server doesn't exit just because one of the clients exits.