12  Intro to Computer Networks

These days using a computer is basically synonymous with using a computer network. When you visit a website, print a document, or login to your email, you are making use of a computer network.

This chapter is an introduction to how computer networks work. This chapter is heavy on introducing mental models for how network traffic works. There is no lab in this chapter.

The computer network we’re most familiar with is the biggest of them all: The Internet. But there are myriad other networks, like the very small private network of the devices (phones, computers, TVs, etc) connected to your home wifi router, to the somewhat larger VPN (which stands for virtual private network) you might connect to for school or work.

The good news is that computer networks are basically all the same. If you understand one, you understand them all. Each step in the process is governed by a protocol that defines what is valid.

There are two basic levels of protocols that are helpful to understand – the transport + address layer, and the application layer.

Just as you and your friend could communicate in any number of human languages, computers define what a valid message is with an application layer protocol.

There are numerous application layer protocols. Some you will see in this book include SSH for access to the terminal on a remote machine, (S)FTP for file transfers, SMTP for email, LDAP(S) for authentication and authorization, and websockets for persistent bi-directional communication, which is what the Shiny and Streamlit packages use.

The most common application layer protocol, used for all standard web traffic, is hypertext transfer protocol (http), which we discussed in some depth in Chapter 4 on using APIs for data science purposes.

For the purposes of this chapter, we’re going to completely set aside physical network infrastructure. Yes, there are wires, cables, satellites, routers, server farms, and more that allow computer networking to work. For the purposes of this chapter, we’re going to focus entirely on the software side of networking.

One cool thing about the cloud is that it allows you to abstract away all of the physical hardware and focus completely on how the software interacts.

12.1 TCP/IP and the mail

Let’s start by imagining you have a penpal, who lives in an apartment building across the country.¹

Let’s say you’ve got some juicy gossip to share with your penpal. Because this gossip is so juicy, you’re not going to put it on a postcard. You’d write your letter, put it inside an envelope, address the letter to the right spot, and put it in the mail.

You trust the postal service to take your letter, deliver it to the correct address, and then your friend will be able to read your letter.

The process of actualy getting data from one computer to another is governed by the TCP/IP protocol and is called packet switching.²

When a computer has data to send to another computer, it takes that information and packages it up into a bundle called a packet.³

The data in the packet is like the contents of your letter.

Just as the postal service defines permissible envelope sizes and address formats, the TCP/IP protocol defines what a packet has to look like from the outside, including what constitutes a valid address.

A uniform resource locator (URL) is the way to address a specific resource on a network.

A full URL includes 4 pieces of information: \[ \overbrace{\text{https://}}^\text{protocol}\overbrace{\text{example.com}}^\text{address}\overbrace{\text{:443}}^\text{port}\overbrace{\text{/}}^\text{resource} \]

The protocol starts the URL. It is separated from the rest of the URL by ://.

Each of the rest of the pieces of the URL is needed to get to a specific resource and has a real-world analog.

The address is like the street address of your penpal’s building. It specifies the host where your data should go.⁴

A host is any entity on a network that can receive requests and send responses. So a server is a common type of host on a network, but so is a router, your laptop, and a printer.

The port is like your friend’s apartment. It specifies which service on the server to address.

Lastly, the resource dictates what resource you want on the server. It’s like the name on the address of the letter, indicating that you’re writing to your penpal, not their mom or sister.

This full URL may look a little strange to you. You’re probably used to just putting a standalone domain like \(google.com\) into your browser when you want to go to a website. That’s because https, port 443, and / are all defaults, so modern browsers don’t make you specify them.

But what if you make it explicit? Try going to https://google.com:443/. What do you get?

12.2 Ports get you to the right service

A port is a location on a server where a network connection is possible. It’s like the apartment number for the mail. Each port has a unique number 1 to just over 65,000. By default, the overwhelming majority of the ports on the server are closed for security reasons.

Your computer automatically opens ports to make outgoing connections, but if you want to allow someone to make inbound connections – like to access RStudio or a Shiny app on a server – you need to manually configure and open a port.

Any program that is running on a server and that you intend to be accessible from the outside is called a service. For example, we set up RStudio, JupyterHub, and a Plumber API as services in the lab in Chapter 11. Each service lives on a unique port on the server.

Since each service running on a server needs a unique port, it’s common to choose a somewhat random relatively high-numbered port. That makes sure it’s unlikely that the port will conflict with another service running on the server.

For example RStudio Server runs on port 8787 by default. According to JJ Allaire, there’s no special meaning to this port. It was chosen because it was easy to remember and not 8888, which some other popular projects had taken.

12.2.1 Special Port Cheatsheet

All ports below 1024 are reserved for common server tasks, so you can’t assign services to low-numbered ports.

There are also three common ports that will come up over and over. These are handy because if you’re using the relevant service, you don’t have to indicate if it’s using the default port.

Protocol	Default Port
HTTP	80
HTTPS	443
SSH	22

12.3 Assigning addresses

The proper address of a server on a network is defined by the Internet Protocol (IP) and is called an IP Address. IP addresses are mapped to human-friendly domains like \(google.com\) with the Domain Name Service (DNS).

Note

In this chapter, we’re going to set DNS aside and talk exclusively about IP Addresses.

Chapter 13 is all about DNS.

Every host on the internet has a public IP address.

A public IP address is an IP address that is valid across the entire internet. That means that each public IP address is unique across the entire internet. You can think of a public IP address like the public street address of a building.

But many hosts are not publicly accessible on the internet. Many are housed in private networks. A private network is one where the hosts aren’t directly accessible to the public. You can think of a host in a private network like a building inside a gated community. You may still be able to get there from the public, but you can’t just walk up to the building from the street. Instead you need to come in through the specific gates that have been permitted and approach only on the roads that are allowed.

TODO: Image of public IPs like street address, private like cul-de-sac

There are many different kinds of private networks. Some are small and enforced by connection to a physical endpoint, like the private network your WiFi router controls that houses your laptop, phone, TV, Xbox, and anything else you allow to connect to your router. In other cases, the network is a software network. Many organizations have virtual private networks (VPNs). In this case, you connect to the network via software. There may be resources you can only connect to inside your VPN and there also might be limitations about what you can go out and get.

There are a few different reasons for this public/private network split. The first is security. If you’ve got a public IP address, anyone on the internet can come knock on your virtual front door. That’s actually not so bad. What’s more problematic is that they can go all the way around the building looking for an unlocked side door. Putting your host inside a private network is a way to ensure that people can only approach the host through on the pathways you intend.

The second reason is convenience.

Private networks provide a nice layer of abstraction for network addresses.

You probably have a variety of network-enabled devices in your home, from your laptop and phone to your TV, Xbox, washing machine, and smart locks. But from the outside, your house has only one public IP address – the address of the router in your home. That means that your router has to keep track of all the devices you’ve got, but they don’t need to register with any sort of public service just to be able to use the internet.

As we’ll get into in Chapter 13, keeping track of IP Addresses is best left to machines. If you’re managing a complex private network, it’s really nice to give hostnames to individual hosts. A nice feature of a private hostname compared to a public address is that you don’t have to worry if the hostname is unique across the entire internet – it just has to be unique inside your private network.

12.3.1 Firewalls, allow-lists, and other security settings

One of the most basic ways to keep a server safe is to not allow traffic from the outside to come in. Generally that means that in addition to keeping the server ports themselves closed, you’ll also have a firewall up that defaults to all ports being closed.

In AWS, the basic level of protection for your server is called the security group. If you remember, we used a default security group in launching your server. When you want to go add more services to your server, you’ll have to open additional ports both on the server and in the security group.

In addition to keeping particular ports closed, you can also set your server to only allow incoming traffic from certain IP addresses. This is generally a very coarse way to do security, and rather fragile. For example, you could configure your server to only accept incoming requests from your office’s IP address, but what if someone needs to access the server from home or the office’s IP address is reassigned?

One thing that is not a security setting is just using a port that’s hard to guess. For example, you might think, “Well, if I were to put SSH on port 2943 instead of 22, that would be safer because it’s harder to guess!” I guess so, but it’s really just an illusion of security. There are ways to make your server safer. Choosing esoteric port numbers really isn’t it.

12.4 How packets are routed

The way packets travel from one computer to another is called routing. A router is a hardware or software device that route packets.

You can think of routers and public networks as existing in trees. Each router knows about the IP addresses downstream of it and also the single upstream default address.⁵

TODO: diagram of routers in trees

For example, the router in your house just keeps track of the actual devices that are attached to it. So if you were to print something from your laptop, the data would just go to your router and then to your printer.

On the other hand, when you look at a picture on Instagram, that traffic has to go over the public network. The default address for your home’s router is probably one owned by your internet service provider (ISP) for your neighborhood. And that router’s default address is probably also owned by your ISP, but for a broader network.

So your packet will get passed upstream to a sufficiently general network and then back downstream to the actual address you’re trying to reach.

Meanwhile, your computer just waits for a response. Once the server has a response to send, it comes back using the same technique. Obviously a huge difference between sending a letter to a penpal and using a computer network is the speed. Where sending a physical letter takes a minimum of days, sending and receiving packets over a network is so fast that the delay is imperceptible when you’re playing a multiplayer video game or collaborating on a document online.

12.5 How to recognize an IP address

You’ve probably seen IPv4 addresses many times. They’re four blocks of 8-bit fields (numbers between 0 and 255) with dots in between, so they look something like 65.77.154.233.

If you do the math, you’ll realize there are “only” about 4 billion of these. While we can stretch those 4 billion IP addresses to many more devices since most devices only have private IPs, we are indeed running out of public IPv4 addresses.

The good news is that smart people started planning for this a while ago. In the last few years, adoption of the new IPv6 standard has started. IPv6 addresses are eight blocks of hexadecimal (0-9 + a-f) digits separated by colons, with certain rules that allow them to be shortened, so 4b01:0db8:85a3:0000:0000:8a2e:0370:7334 or 3da4:66a::1 are both examples of valid IPv6 addresses.

IPv6 will coexist with IPv4 for a few decades and we’ll eventually switch entirely to IPv6. There’s no worry about running out of IPv6 addresses any time soon, because the total quantity of IPv6 addresses is a number with 39 zeroes.

12.5.1 Reserved IP Addresses

Most IPv4 addresses are freely available to be assigned, but there are a few that you’ll see in particular contexts and it’s useful to know what they are.

The first IP address you’ll see a lot is 127.0.0.1, also known as localhost or loopback. This is the way a machine refers to itself.

For example, if you open a Shiny app in RStudio Desktop, the app will pop up in a little window along with a notice that says

Listening on http://127.0.0.1:6311

That http://127.0.0.1 is indicating that your computer is serving the Shiny app to itself on the localhost address.

There are also a few blocks of addresses that are reserved for use on private networks, so they’re never assigned in public.

Code	Meaning
127.0.0.1	localhost or loopback – the machine that originated the request
192.168.x.x 172.16.x.x.x 10.x.x.x	Protected address blocks used for private IP addresses.

You don’t really need to remember these, but it’s very likely you’ve seen an address like 192.168.0.1 or 192.168.1.1 if you’ve ever tried to configure a router or modem for your home wifi.

Now you know why.

12.6 Basic network troubleshooting

Networking can be difficult to manage because there are so many layers where it can go awry. Let’s say you’ve configured a service on your server, but you just can’t seem to access it.

The ping command can be useful for checking whether your server is reachable on the network. For example, here’s what happens when I ping the domain where this book sits.

> ping -o do4ds.com                                                                        
PING do4ds.com (185.199.110.153): 56 data bytes
64 bytes from 185.199.110.153: icmp_seq=0 ttl=57 time=13.766 ms

--- do4ds.com ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 13.766/13.766/13.766/0.000 ms

This looks great – it sent 1 packet to the server and got one back. That’s exactly what I want. Seeing an unreachable host or packet loss would be an indication that my networking probably isn’t configured correctly somewhere between me and the server. I generally like to use ping with the -o option for sending just one packet – as opposed to continuously trying.

If ping fails, it means that my server isn’t reachable. The things I’d want to check is that I have the URL for the server correct, that DNS is configured correctly (see Chapter 13), that I’ve correctly configured any firewalls to have the right ports open (Security Groups in AWS), and that any intermediate networking devices are properly configured (see more on proxies in Chapter 17).

If ping succeeds but I still can’t access the server, curl is good to check. curl actually attempts to fetch the website at a particular URL. It’s often useful to use curl with the -I option so it just returns a simple status report, not the full contents of what it finds there.

For example, here’s what I get when I curl CRAN from my machine.

 > curl -I https://cran.r-project.org/                                                         
 
HTTP/1.1 200 OK
Date: Sun, 15 Jan 2023 15:34:19 GMT
Server: Apache
Last-Modified: Mon, 14 Nov 2022 17:33:06 GMT
ETag: "35a-5ed71a1e393e7"
Accept-Ranges: bytes
Content-Length: 858
Vary: Accept-Encoding
Content-Type: text/html

The important thing here is that first line. The server is returning a 200 HTTP status code, which means all is well. For more on HTTP status codes and how to interpret them, see Chapter 4.

If ping succeeds, but curl does not, it means that the server is up at the expected IP address, but the service is not accessible. At that point, you might check whether the right ports are accessible – it’s possible to (for example) have port 443 or 80 accessible on your server, but not the port you actually need for your service. You also might check on the server itself that the service is running and that it is running on the port you think it is.

If you’re running inside a container, you should check that you’ve properly configured the port inside container to be forwarded to the outside.

12.7 Comprehension Questions

1. What are the 4 components of a URL? What’s the significance of each?
2. What are the two things a router keeps track of? How does it use each of them?
3. Are there any inherent differences between public and private IP addresses?
4. What is the difference between an IP address and a port?
5. Let’s say you’ve got a server at 54.33.115.12. Draw a mind map of what happens when you try to SSH into the server. Your explanation should include the terms: IP Address, port, 22, default address, router, sever.

12.8 Lab: Making it accessible in one place

Note

This lab is somewhat advanced. If you just wanted to run one service on your server – say just RStudio or just the Plumber API, you could skip this lab and just configure the service to be available on port 80 and/or 443.

In this lab, we’re going to go from having to SSH tunnel to be able to use your data science workbench to making it available over the internet. That means we’re going to have to do 2 things: configure the networking to allow HTTP traffic and configure a real domain for our server.

Right now RStudio Server is ready to serve traffic inside our server on port 8787, JupyterHub is on 8000, and our Palmer Penguins API is on 8555. But right now nothing can get to them. So the first step is to allow traffic in.

The easiest thing we could do would be to just open up ports 8787 and 8000 to the world. It’s not the right answer, but it will “work”.

Tip

If you do want to try it to prove to yourself, go to the settings for your server’s security group and just add a custom TCP rule allowing access to ports 8787, 8000, and 8555 from anywhere. If you visit $SERVER_ADDRESS:8787 you should get RStudio, similarly with JupyterHub at $SERVER_ADDRESS:8000, and the API at $SERVER_ADDRESS:8555.

Ok, now close those ports back up so we can do this the right way.

If you did it this way, your users would have to remember these arbitrary ports to use your server. It’s also insecure because there isn’t a good way to secure these ports with SSL.⁶

The common solution to wanting to serve multiple services off of one server is to use a proxy. A proxy is a network device that reroutes traffic in various ways. Chapter 17 has more detail on proxies and why they’re a pain.

For the purpose of this lab, I’m going to give you a pre-built proxy to use.

Here are the steps to take on your server:

1. Install nginx with sudo apt install nginx.
2. Save a backup of nginx.conf, cp /etc/nginx/nginx.conf /etc/nginx/nginx-backup.conf.⁷
3. Edit the nginx configuration with sudo vim /etc/nginx/nginx.conf and replace it with:

/etc/nginx/nginx.conf

http {
  
  \# Enable websockets (needed for Shiny)
  map \$http_upgrade \$connection_upgrade { 
    default upgrade; '' close; 
  }
  
  server { listen 80;
    
    location /rstudio/ {
      # Needed only for a custom path prefix of /rstudio
      rewrite ^/rstudio/(.*)$ /$1 break;
      
      # Use http here when ssl-enabled=0 is set in rserver.conf
      proxy_pass http://localhost:8787;
      
      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection $connection_upgrade;
      proxy_read_timeout 20d;
      
      # Not needed if www-root-path is set in rserver.conf
      proxy_set_header X-RStudio-Root-Path /rstudio;
      
      # Optionally, use an explicit hostname and omit the port if using 80/443
      proxy_set_header Host $host:$server_port;
    }
    
    location /jupyter/ {
      # NOTE important to also set base url of jupyterhub to /jupyter in its config
      proxy_pass http://127.0.0a.1:8000;
      
      proxy_redirect   off;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header Host $host;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Forwarded-Proto $scheme;
      
      # websocket headers
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection $connection_upgrade;
    }
    
    location /palmer/ {
    #TODO
    }
  }

4. Test that your configuration is valid sudo nginx -t.
5. Start nginx sudo systemctl start nginx. If you see nothing all is well.

If you need to change anything, update the config and then restart with sudo systemctl restart nginx.

There’s one more thing you’ll have to do, which is to let RStudio and JupyterHub know that they’re on a subpath. Complex web apps like RStudio and JupyterHub frequently send people to a different subpath internally. In order to do so properly, they need to know to prepend all of those requests with the subpath.

RStudio accepts a header from the proxy that lets it know what path it’s on (see the X-RStudio-Root-Path header line in the nginx config). Jupyter needs to be explicitly told.

If you recall, we autogenerated the JupyterHub config with

 jupyterhub --generate-config
 sudo mkdir /etc/jupyterhub
 sudo mv jupyterhub_config.py /etc/jupyterhub

So you can go edit it with sudo vim /etc/jupyterhub/jupyterhub_config.py.

Find the line that reads # c.JupyterHub.bind_url = 'http://:8000'.

Tip

You can search in vim from normal mode with / <thing you're searching for>. Go to the next hit with n.

Uncomment that line and add a /jupyter on the end, so it reads c.JupyterHub.bind_url = 'http://:8000/jupyter'.

Start jupyterhub with a specific config file.

We already daemonized JupyterHub, you restarting it with sudo systemctl restart jupyterhub should pick up the new config.

---

1. For this analogy to work, everyone lives in apartment buildings rather than standalone houses.

2. TCP and IP are actually two separate protocols at different layers of the protocol stack. But they’re so closely linked that we can talk about them as one.

3. One of the biggest ways the mail is not like packet switching is that your message gets chopped up among lots of different packets, which are routed independently, and are reassembled when they get where they’re going. Works well for computers, not so well for real-world mail. It’s also pretty much an irrelevant detail, since this whole process works quite invisibly.

4. Often it’s not a single server at the address – but it behaves like one. It could instead be a proxy in front of a cluster of servers or even more complicated routing. All that matters is that it behaves like a single server from the outside.

5. There are actually a few different types of addresses used to do this. IP addresses are used for identifying network resources and the MAC address used for physical hardware. Your router is also responsible for assigning IP addresses to devices as they join the network via the dynamic host configuration protocol (DHCP). I’m glossing over all these details as they’re immaterial to the understanding important for this chapter.

6. As of this writing, JupyterHub supports configuring SSL in the product, but RStudio Server does not. Posit Workbench, the paid version of RStudio Server does support SSL configuration.

7. This is generally a good practice before you start messing with config files. Bad configuration is usually preferable to a service that can’t start at all because you’ve messed up the config so badly. It happens.