I have a hand drawn diagram of what’s what in web terminology – well okay, there’s too much to include but the very basics of what you need to get online. Here comes my attempt to document this is a neater format – so what’s what and what do you need?
The Website – or codebase
Let’s start with the most basic – you want a new website. Let’s build it! This is a blog to we can say that’s done now as there isn’t an actual time frame. Now, you could technically open the website as a file on your computer – assuming we have just written HTML. Most of the time, we would write something in a preprocessor so that each user sees content relevant to them. It wouldn’t be useful if we all shared the same 1 shopping cart on a website. This means you need a program to decide that if “Alice” is speaking to me I should change the “Username” field to “Alice” while if “Bob” is speaking to me, you guessed it I should change “Username” to “Bob”. Then, in most cases you will need a database behind the system as well. But for simplicity let’s say everything about the website is on your computer, perhaps in a docker container. So the development is a bunch of files – that’s the bulk of the work, but there are ongoing bits we need to talk about.
The Server
If you open the website on your computer, that’s great, but if a customer wants to visit your website, you aren’t going to send them the entire website and tell them to run it on their computer are you? (The answer to this should be no). So you will instead “host” the site on a server. In other words, the server will serve the website to them. Here comes our first bit of terminology. So how do we do this – technically, if you have no firewall, you can just pass on your IP address and they can see it running on your computer. Heads up – this is a terrible idea, and most people have a firewall whether they realize it or not! Additionally, what happens if you turn your computer off? You guessed it, the site stops working. The internet is based on always on. So what if you leave your computer on 24 hours a day? Well, you have software updates, and most consumer devices aren’t designed to run full time, this is why Hard Drives which had physical moving parts, offered specialized devices for CCTV systems and so on – these products were designed to run 24/7 – so if you are still hard pressed on doing this you could buy specialized equipment sure – but even this can break. Okay, so you rent a server, host the site there and people can access the website via that server, that server can also run the database – or you could host that separately, but that’s for another blog post.
The Domain Name
You’re doing well – you’ve got your site and it’s on a server! And you’ve followed that you need an IP address to get to that. An IP address (IPv4) looks like this: 1.2.3.4 – but those numbers can go up to 255! So this isn’t really a great way to communicate with your customers. (To make matters worse, there is a shortage of IPv4 addresses, if we ever move to IPv6 these look like 1:2:3:4:5:6:7:8 – but wait there’s more – these go far far higher than 255, they go to ffff. Don’t recognise that number? Yes ffff is a number. Unlike IPv4 which uses base 10, IPv6 uses hexadecimal, or base 16 numbers. In base 10, we add another digit when we hit 10, in base 16 we do this when we hit 16 – so 16 would actually be written as 10. (Confusing right?). This means 10 is written as a, 11 as b and so on to 15 (f). Imagine trying to market an IP address like that! Introducing the Domain Name. Domain Name servers resolve a human readable name into an IP address. So you purchase (or rent may be a better term), a Top Level Domain (TLD) .com or a global Top Level Domain (gTLD) like a .com.au, a .co.uk, .fr etc. You then configure the Domain Name servers to resolve your domain to your website for ‘A’ requests. Domain Name servers have a web like ability to share data, but the exact workings of this is for another blog post! They all communicate to ensure everyone gets re-directed to your website. At this point we really need to go off in two directions – let’s start with SSL and then head to email.
Secure Sockets Layer (SSL) and HTTPS
Hang on, I hear you saying! I’ve got my website, it’s being hosted and I’ve got a domain name pointing to the server. Surely I am done now!!! Well yes – your website will now work – but when visitors view your site they will see the message “Not secure” in the URL bar. Why is this? Websites work using the Hyper Text Transport Protocol. This has been around for a long time and defines a way to transport hypertext (of which websites are). It did a great job when websites were things we could read only. But we’ve moved a long way since then – now days websites include users feeding information back, username, passwords, and most concerning – credit card numbers. If someone is watching your connection, they would get access to all of this. Luckily the IT world moves fast, so we have HTTPS – Hyper Text Transport Protocol Secure. The S on the end makes all the difference. This uses some form of encryption (such as SSL) to make sure you have a secure connection between the visitor to your website, and the server. Once upon a time these were only used by big financial institutions and the like – but these days this is common place and should be present on ALL websites. This gives you the padlock instead of the “Not Secure” message. Now we have our website up and running!
Right – so I have my website – everything is done right? And people will just contact me. Not so fast. Welcome to the world of email. Email, is not a website. You may notice I referred in the section on Domains to ‘A’ records. Well, these determine how websites should react, but they are not the only records Domain Name Servers (DNS) hold. A website, www.prudentpixel.com looks very different to an email address hello@prudentpixel.com and indeed the behaviour in dealing with the two is also very different. Another type of record a DNS server should hold are the ‘MX’ records (and yes there will usually be multiple of these). This tells the Mail eXchange how to deal with any emails for something @prudentpixel.com. In the case of DNS, we don’t care who the email is addressed to, just where. As a side note – email can get very complicated, we are going to simplify things here to talk about a basic setup – but I do want to acknowledge things can get very detailed in this section. Okay, so Alice sends an email to Bob. Alice doesn’t know the IP address of Bob’s email server – because who would, so Alice uses Bob’s domain name. We hit up the DNS and tell it we need the MX record for Bob’s domain – this provides us with the location of Bob’s email server. We then reach out to Bob’s email server, complete a handshake and pass over the email – the email server is running the program that determines who the email should go to, or in the event that it doesn’t know that person, declines to accept the email. If Bob uses webmail, he then communicates with his mail server via an A record, because that’s a website, and on the server, behind the scenes, it will deal with reading the email, but all Mail eXchange goes through the MX record. The mail server is usually a different server to the web server, as it will also look at the IP address giving it the email and this will help determine the likelihood of the email being spam.
Show us the picture!
Still hanging out for the hand drawn picture explaining all this? Right here it is:
What can I say… If I didn’t work in IT I’m sure I would’ve been an artist!
