[00:00:01.23] SY: (Music): Welcome to the CodeNewbie podcast, where we talk to people on their coding journey in hopes of helping you on yours. I'm your host Saron and today we're talking about networking. If you got a technical interview, or if you've researched technical interview questions, then you've probably heard this one: when you go to Google.com, what happens? From the user's perspective, you get the page for Google.com. But how did that happen, on a technical level?

[00:00:37.16] JE: I'm Julia Evans, I'm a computer programmer and I work at Stripe. And in my spare time I like to write a programming blog where I write about what I talk about why I'm writing that program.

[00:00:44.17] SY: She created this really great zine, called Networking! Ack!, a computer networking zine. So, I invited her on the show. Today she gives us a really friendly intro to the world of computer networking. After this.

One of the best parts of being a coder is finally being able to bring your passions to life. You have the skills to design, to code, to create the thing you're excited about, and share that passion with the world. And Hover can help you with the first step, of sharing your passion with the world - getting your domain name. They've got a really beautiful and easy to use interface where you can find and register your new domain name in just a few steps. And to give you full control, they separate your domain name from your hosting, so you're never stuck with one service. They keep your domain name safe while giving you the flexibility to use whatever hosting service is best for you. They also give you free "who is" privacy, so your personal information is safe, too. To get started, go over to Hover.com/newbie to save ten percent off your first purchase. That's hover.com/newbie. Link is in the show notes. (Music)

[00:01:49.25] So today we're talking specifically about networking, and we're not talking about the job networking kind that everybody loves, we're talking about technical networking stuff. So when we mention the word networking, Julia, how would you even describe that? Where do you begin to define what that means?

[00:02:12.01] JE: So when I say networking, I mean computer networking, what's happening right now is we're in different places in the world. I'm in Montreal and you're somewhere else, and we're talking to each other in real time. And so for that to happen, information has to be sent from my computer on my laptop to you somewhere completely different. And how does that information get sent? That's computer networking. And there's a lot of different things involved. And the reason that I think it's exciting is that it all seems really mystical when you start trying to learn about it. Like, I did a computer science degree, but I never took a computer networking class. Like a few years after I graduated, I was like, I have no idea what's happening when I get a webpage, really. Like I kind of vaguely understood the basics, but I didn't really understand what was going on. And eventually I was able to figure it out - and that's kind of what I want to talk about. Because I think the small stuff, which you totally can understand and it takes a while but it's not magic.

[00:03:12.17] SY: What was the first step in you understanding it? Where did you begin?

[00:03:16.05] JE: So the very first step was this program called Netcat - you know the program Cat that you can use to take two files and concatenate them and write them to disk? You have a program, you run it through Cat, and it gets copied somewhere else, basically. So Netcat is like Cat but over a computer network, so someone showed me that you can do this thing with Netcat where it's like, let's say I'm in my apartment, and I want to send a huge file to someone else, who's in the same apartment as me. It turns out that you can do this really easily, because if you're in the same place, you don't need to put the file in Dropbox, because you're in the same apartment. So there's no reason why the file needs to go to Dropbox's server and then come all the way back to your apartment, because you're in the same place. So you can do this cool thing that you can start up a web server on your computer, and then have someone else in the same house connect directly to that web server, and send you the file. And it can get sent at like 300 megabytes/a second or whatever, because you're right next to each other, and it's not dependent on your home internet speed at all.

[00:04:21.10] SY: Wait so, does that mean - ok, so I have a web server, so there's a link, I assume, that that person can then go to?

[00:04:30.25] JE: So there's no link - ok, let me try to explain how it works. So I start a web server, and every web server has a port - so let's say I start my web server on port 999, and Netcat is like the simplest possible web server, so basically all it knows how to do is receive data and write data. So what I can do with Netcat is I can start up a web server on my computer, and I can be like please receive data, and redirect that to a file. So this is the dumbest web server in existence - it does not know how to give you webpages, it does not give you anything, all it does is grab data and it puts it into a file.

[00:05:11.02] SY: So you start the web server - I'm a friend in the apartment who wants to send you data - what do I do?

[00:05:17.10] JE: I've kind of set up Netcat in a receiving mode, and then you can use Netcat in a sending mode, you get my IP address on the home network - like, you know how when you're on the home network, you get this address that's like

192.168 something point something? I give them that IP address, and then they use the port 999, and then they connect to that with Netcat, and then they use Cat to pipe the file into Netcat, and then Netcat takes all that data and just sends it to my computer.

[00:05:45.15] SY: And I'm assuming outputs it to a file?

[00:05:47.09] JE: Yeah, and then on my end I write it into a file.

[00:05:49.20] SY: Very cool. Ok, let's bring it back to computer networking. How did Netcat help you understand how networking works?

[00:05:58.23] JE: So I think that this is a really cool example because it kind of forces you to think about what's actually happening when you do networking. With something like this, you're like wait, can I send files directly in the same apartment from one computer to another, and what does that mean? It seems more confusing, but it's fundamentally a lot simpler. So if you can break down how it works, then you really have to understand the ideas.

[00:06:21.26] SY: Yeah, let's break it down in networking fundamentals. What are all of the pieces, the concepts, involved in this Netcat example?

[00:06:31.02] JE: So in this example, there are two pieces. One of them is the IP address piece. So there are a lot of different networking protocols, and here we only care about two, which is good. So one of them is -

[00:06:45.20] SY: Wait, how many would we care about?

[00:06:48.05] JE: Ok, well, do you want me to just tell you acronyms?

[00:06:52.03] SY: Sure, let's hear the acronym list, that sounds like a fun game.

[00:06:54.17] JE: Ok, well, let's say I'm going to Google.com and I'm getting a webpage. If you're going to Google.com, the protocols that are involved are - there's IP for the IP address, there's TCP, there's DNS, there's HTTP, there's also because Google is always going to serve you a secure site, there's SSL or TLS. Secretly behind the scenes there's BGP, but that's kind of advanced. There's ethernet, there's WiFi, I think that's it.

[00:07:26.05] SY: Wow, what's interesting about that list is I've heard about just about all of them except for the VG thing you mentioned, I hadn't heard of that one before, but the rest of them, I don't think I knew that they were protocols. Obviously, I'd heard of DNS, I'd worked with it, I've done DNS management, like domain names, but I don't think I've ever thought of it as a protocol. What is a protocol? Let's start with that - in this context anyway, what makes all of these different things protocols?

[00:07:51.20] JE: In networking, everything is a message, right? If I'm sending you my voice right now, fundamentally I'm sending you a bunch of messages - maybe thousands or millions of messaging. And each of those messages has a specific format, all of the formats have names. So I guess when I say protocol, I mean like a format that has a name.

[00:08:19.11] SY: Yeah, so like structured, organized, yeah. Interesting - so let's go back to Netcat, what are the two protocols we're using again?

[00:08:27.17] JE: So for Netcat, the two protocols are IP and TCP. So did you know that any time you send a message on the internet, it could get lost at any time?

[00:08:38.24] SY: I did know that, which is nuts. Like I assume everything I send can always be found.

[00:08:45.15] JE: Right, but it's not - it can't. Like a lot of messages just get lost. So if I'm sending you a message, some computer somewhere in the middle can just be like, oh no, I'm too busy, oh goodness, I give up. They have a lot of buffers in them, and those buffers get full, and it'll just be like, oh well. Those messages are lost forever.

[00:09:11.01] SY: Wait, does it at least tell me if it's lost my message?

[00:09:14.13] JE: No, often not. It will just silently drop your message, and that's it.

[00:09:15.28] SY: That's not enough honest with me, God.

[00:09:21.01] JE: It's upsetting. So given this it's kind of remarkable that the internet works at all, because if anything can just get lost at any time, when you're downloading a picture of a cat, you'd expect the picture of the cat to get garbled or be missing its tail or something. But in reality what we see is that the internet works and that we get data reliably. So the thing that's happening that lets us actually get data reliably is TCP, which stands for something transmission control protocol, which is not very descriptive -

[00:09:52.26] SY: It sounds important, but doesn't really tell me very much.

[00:09:53.13] JE: But what it is is what let's us send data reliably to each other. So anytime you're downloading a website, that always uses TCP. Because when you download a website, you expect to get it back. So anytime you're sending a message and you expect to get exactly the thing that was sent, you're using TCP. Not all networking works this way, but a lot of the networking that we do in our day to day lives works this way.

[00:10:16.09] SY: So I would think that if TCP helps guarantee that I actually get the thing that I requested in its entirety, then everything would use TCP! So why would you use something else?

[00:10:27.13] JE: Because TCP kind of has some overhead, because it's going to retry, and sometimes you don't want to retry - a common example of a time when you might not want to retry is actually when doing voice. So for example you're Skyping with someone and you're sending them voice packets - if something goes wrong in the network, and a bunch of packets get lost, it's probably better for the chat application to just drop all of that and have you try again, to say your words again, instead of having the thing that you said arrive five seconds late.

[00:11:04.25] SY: Ah, then you get a delay.

[00:11:05.28] JE: Because then you get a delay, which is not what you want.

[00:11:07.27] SY: That makes sense.

[00:11:09.21] JE: It's like the classic example of when you don't want TCP, and there are also some more computer-y situations when you're sending data and you either want it to arrive right away or not at all, or you just can't afford the overhead.

[00:11:19.05] SY: Yeah, interesting. So if it's not TCP, if we're doing the other thing that is ok with losing information, what is that thing called?

[00:11:29.14] JE: That's called UDP.

[00:11:31.20] SY: What does that stand for, do you know?

[00:11:32.05] JE: Something datagram protocol. User datagram protocol? I think. And the idea is that I'm just sending you - I think datagram is like telegram, I've sent you a bunch of data, and I've just thrown it at you, and it either gets there or it doesn't, it just hopes for the best. That's actually how DNS works, I just sent you a DNS request, then if the server gets the request it sends me a response back, and then if I don't get it, it's my job to try again.

[00:11:57.15] SY: Ok, so the Netcat thingie uses TCP? Is that what we decided?

[00:12:04.15] JE: It can actually use both, but the case we're talking about, where we're sending a file - if you're sending a file and you want someone to get all of the bytes - oh I didn't mention another thing about networking that's really important. Which is that if you're sending someone packets - messages on the internet - they could arrive in any order. So if I sent you ten messages, they could arrive like completely scrambled.

[00:12:24.09] SY: Whoa! That's not good!

[00:12:24.22] JE: So this is the other key thing that TCP helps you solve, it actually helps you rearrange the packets in the right order.

[00:12:31.04] SY: Yeah, interesting.

[00:12:32.14] JE: So there's a cool thing that can happen with networking - this is kind of a digression, but I think a really cool one -

there's no guarantee that if I send you messages, that they'll even take the same path. So I could send you a message, and it could go through New York, and I could send you a different one and it could go through Illinois, and I could send you a different one and it could go through Australia.

[00:12:50.15] SY: Literally?

[00:12:51.11] JE: Yeah, because it has to go somewhere in the world, right? Like I am somewhere in the world and you are somewhere else and it has to go through other physical places in the world to get to you. Even during the same connection, there's no guarantee that the packets will get sent through the same places in the world.

[00:13:04.05] SY: Wow, so ok let me ask you this - is it the case that ideally would take the same path, but I try to and then that computer is like eh, nope, sorry I'm busy, you have to go find a different train? Is the ideal process to take the same path and it just doesn't work, or does it not care how it gets there?

[00:13:22.07] JE: I guess like, your computer when it sends data has no notion of what paths even exist. And every computer that's routing a packet only has local information about what's around it. If I'm sending something, I'm not saying, oh, you should go through this path. I'm just saying, please try to send this packet to this IP address and get it there somehow.

[00:13:44.00] SY: It's kind of like hitchhiking! Right, you're standing on the road and you see a truck -

[00:13:49.14] JE: I think it's a pretty good metaphor for how routing works.

[00:13:53.01] SY: Interesting. Ok, so, TCP in terms of how it helps with the organization - is it that once it arrives it looks around and says wait a minute, this is not the right order and it puts everything in its place?

[00:14:06.14] JE: Yeah, so, basically I think the thing we've learned that packets can get out of order, is that if you just have messages, like if I just sent you parts of a file without any extra information about where they belong in the file, it won't work. So we need to add some extra information to the data that we're sending. Which is where we get into structure and protocols. So for the TCP protocol, every packet has an offset, and everything is in terms of bytes, because the TCP protocol doesn't know - it has no idea what the data you're sending is. You're just sending zeros and ones, as far as it's concerned. It doesn't know if it's a cat or an HTTP request or it could be anything. So every TCP packet, there's an offset, so it can be like, ok, these are bytes, one million to one million and two hundred, and this is in a packet, because everything in networking is a chunk of data. So you think you have streams - TCP tricks you into thinking you can have a stream, but generally everything is in a packet. Because every packet has the start and the end on it, when it gets to the other end, it can get reassembled.

[00:15:15.13] SY: Ok, we start with a file, let's say the cat picture that I want to send you with Netcat. But we end in terms of it actually, what TCP sees, it ends with packet. So we start with a picture, we end with a packet. What does that processing, what does that translation - to break down the image that I see into those packets?

[00:15:37.24] JE: So your operating system does that. From the perspective of Netcat is in charge of that, the operating system provides something called the socket interface, which is a jargon term you might have heard.

[00:15:51.06] SY: I haven't, what is that?

[00:15:52.22] JE: It's the thing that answers the question that you just asked. So you're like, what lets you just send data and then break it down into packets? The interface that lets you do that is called the socket interface.

[00:16:06.16] SY: Huh, interesting. So as far as my Netcat thing is concerned, it doesn't have to worry about breaking it down, it already has that - that's already happened by some other tool, some other process.

[00:16:18.11] JE: Right, so just like, hey operating system give me a "socket," and then it starts writing data to that and the operating system deals with it. And then it will break the data down into packets, if it needs to retry sending it, it'll retry and then when it's done it will end the connection.

[00:16:34.16] SY: Wait, are sockets related to web sockets?

[00:16:37.21] JE: That's the same word.

[00:16:39.23] SY: Oh, ok.

[00:16:41.25] JE: So they'll say web sockets. Yeah. They're related to web sockets.

[00:16:45.13] SY: Ok, so anything else we should know about our TCP and how that works?

[00:16:51.01] JE: Maybe we should talk about one more thing about TCP, which is how does it know whether to retry or not?

[00:16:54.15] SY: Oh yeah, let's talk about that.

[00:16:55.11] JE: Because I said that the operating system will decide whether it should retry sending the packet, but how can it know? Because I said that if the packet gets lost, no one tells you that the packet gets lost. Basically, every packet has a number on it, which is like how far in the stream it is, like how far in the stream of data it is or how far in the file it is. So what the receiving server will do, every so often, is it will send something called an Ack, or acknowledgement, where it's like hey, I got all of the bytes up to one million, so then the person sending the data will know, ok, I don't need to send anything before one million anymore. And then if something hasn't been acked for too long, then it will retry and it will send again.

[00:17:36.26] SY: Interesting.

[00:17:37.11] JE: So it's actually pretty simple.

[00:17:38.27] SY: Yeah, it sounds like a basic - it's not exactly a call and response, but sort of like that, right, just a receipt that says hey, done this.

[00:17:47.16] JE: Yeah, it's just like I send you data and you're like, I got it. I'm like, great, and then I send you more data, and then you don't really reply and I'm like, ok, I'll just try again.

[00:17:58.11] SY: (Laughs) That's hilarious, and you get the silent treatment, it's like I'm sorry, let me apologize one more time.

[00:18:03.03] JE: Yeah, yeah exactly. It's all just the silent treatment or helpful acknowledgements.

[00:18:11.10] SY: I never knew the internet could be so emotional! Ok, let's talk about the IP. How does that fit in?

[00:18:18.29] JE: We could start by talking about the IP in the context of my apartment.

[00:18:22.18] SY: Sure.

[00:18:25.12] JE: One interesting thing is like when you send a packet, you think of sending it to an IP address, but when I send a packet to something in my apartment, it doesn't actually get delivered according to the IP address, it gets delivered according to this other thing called the Mac address, which you might have seen. It's this weird number, it's like, it's hexadecimal, which means it'll look like 5cdfae, I think it's like twelve pairs long or something. Every computer has a unique one of these - so my laptop has one, your laptop has one, and when you're on a local network inside your apartment, packets that get sent to my laptop will have the physical address of my laptop on them. Which is like not how you think about networking -

[00:19:12.02] SY: Yeah, not at all.

[00:19:12.15] JE: As having physical addresses, but that's actually how it works at the local level. Which is kind of cool. Because you can actually have lots of IP addresses throughout your life - you can go to a cafe, you can get one IP address, then you're at home, and you get a different one, and then you fly somewhere else and you get a different one.

[00:19:28.05] SY: Just collecting IP addresses all over the place.

[00:19:29.26] JE: Yeah, they're very ephemeral. And Mac addresses are the thing that are stamped onto your computer at birth. So when I send a message to someone else in my living room, I actually have to figure out what their Mac address is, but basically I'm like hey, who has this IP address, and then someone will tell me, they're like oh it's me. You just send it to this Mac address and then I'll send it to them. But you can only get that if you're really directly connected to someone.

[00:19:54.00] SY: Ok so when you say directly connected, do you mean in terms of physical distance, do we mean connected to the same area network?

[00:20:04.11] JE: Connected to the same router.

[00:20:05.22] SY: Ok, router. There we go. Yeah.

[00:20:08.18] JE: So what happens is if I'm sending a packet to an IP address in my room, I can just send it to their Mac address directly, there's no problem. But then most of the time, it'll be somewhere else, so what I'll do is I'll send it to my router and I'll be like, hey, try to get it there.

[00:20:26.11] SY: Do your best, I believe in you.

[00:20:27.10] JE: Yeah, exactly, I believe in you. And sometimes it's like oh that IP address doesn't exist, or there's no - you know. And that's kind of how all networking works, is you're either sending a packet to something on your local network, which you can talk to directly, or you're asking another device to intermediate for you. Like you're talking to your home router or a corporate router or something - and you're like hey, please get this to its destination. And then send the response back to me.

[00:20:52.11] SY: Yeah. Ok, so that is if it's someone sitting next to you, same network, you're connected to the same WiFi - if we are sending something through the internet internet, what are the parts of that that would be different?

[00:21:10.02] JE: This is where this weird BGP thing comes in. So BGP is kind of like the hitchhiking thing, it's the hitchhiking protocol, so I'm like ok, send this to Google, and then my router is like alright, and probably what my router will do is send the packet to my internet service provider. Because they give me internet and so it'll send the packet to them and then they have these huge tables on their routers, they have these big routers in their data centers that are not like my home router and they have these tables that say hey, here are all IP ranges on the internet, and here's where you should send every packet.

[00:21:48.19] SY: Yeah. So it looks at the fact that you sent it to Google.com and it maps it out to an actual place to send that.

[00:21:54.20] JE: Yeah, but what it actually looks at is the IP address for Google.com.

[00:21:59.12] SY: So if it falls within a range it knows where to go.

[00:22:01.25] JE: And then it will kind of just get sent in the right direction and then every router will keep doing that, and then maybe at some point you'll get to Google and then Google will have the IP address and then it will do something, it'll send it somewhere in its internet network.

[00:22:15.01] SY: Interesting - that seems like a whole lot of work considering how fast it is to actually get to Google.com.

[00:22:21.13] JE: Right, yeah. Well, the cool thing about packets is that they travel at the speed of light, so I think to go - I always forget exactly the number, but to go halfway around the world at the speed of light, it's somewhere between fifty and a hundred milliseconds, which is not really that fast, if you want to go to Australia and back ten times from here, it'll take you like a second. If you're expecting something to be real time, people notice this in gaming, because you're trying to - maybe you're playing some first person shooter, I never played these, but I think your reflexes get important and you want to be able to react to stuff really fast. And so it actually becomes really important to be physically close because the speed of light isn't fast enough.

[00:23:03.01] SY: Yeah, yeah. And is it also why it's helpful to use things like CDMs and connect to servers and data centers that are just physically closer to you?

[00:23:12.22] JE: Yeah exactly. In practice when you talk to Google, you often won't talk to their server - I assume they have a lot of servers in California, but if you're not in California, you probably won't be talking to Google server in California. They'll have a data center somewhere closer to you. Or their CDMs - my blog uses a CDM, so it'll be cached somewhere locally, so when I talk to my blog, then I'm actually talking to a server in Montreal. So I can get it very quickly.

[00:23:40.02] SY: Very cool. Ok so that's one difference is the whole hitchhiking thing that obviously we don't have to do if the person is sitting right next to us - what's another difference when I'm going to Google.com versus sending you a file locally with - what is it, app cat? Cat app? Netcat.

[00:23:59.16] JE: Netcat. I mean, a lot of the other pieces are the same. You're using the same protocol, and sometimes you're probably using the same networking stack because the networking - I run Linux on my computer, and a lot of servers also run Linux, so in a real way the software that's processing these packets is kind of the same. And I think that's one thing that's very cool to me about networking, a lot of these things are the same. The stuff that's happening on my computer when I do networking in my head is the same in a lot of ways as what's happening on fancy websites that are processing of millions of things per second.

[00:24:39.19] SY: Next up - we get into the security part of networking. What makes HTTPS more secure than just HTTP? And if I wanted to send encrypted data, where does that fit in? She also shares her secret to how she's written so much great content, and been so consistent in her blogging over the years. After this.

When I learned to code, I was so excited to finally bring my passions to life. I could build things that I really cared about, and share them with the world. And the first step in sharing is getting a great domain name. That's where Hover comes in. They've got a really slick and easy to use interface, they've got awesome domain names to pick from, and they separate your domain from your hosting so you have full control and flexibility over your online identity. So go to hover.com/newbie to save ten percent off your first purchase. That's hover.com/newbie. Link is in the show notes.

[00:25:35.03] So actually let's talk about security a little bit. When we go to a secure site, when we go to a HTTPS versus just an HTTP, what is actually happening? What makes it more secure?

[00:25:48.19] JE: Ok so there are two parts of this. There's how do you know that the server you're talking to is actually Google.com? A., which is very important. And how do you send data securely between those two sites. And I think it's important to realize that those are different. Because you can very easily send data extremely insecurely to someone who's not who they claim they are. And that's not good. And I think when people talk about certificates, and especially when people get angry about certificates, they're often more concerned about the question of whether the person is who they say they are, rather than whether the data is being encrypted correctly. So which piece would you rather talk about?

[00:26:30.07] SY: Well I guess let's do the verify who you are, who you say you are. That sounds like problems of the internet in general.

[00:26:38.15] JE: It is problems of the internet. So the way it works is - maybe let's pick a different website, maybe let's pick Neopets.com.

[00:26:46.16] SY: Ooh! Neopets! Yeah.

[00:26:48.02] JE: Because it's extremely important that when you go to Neopets.com, that you're not being intercepted by someone trying to steal your Neopets password. What happens is there are these certificate authorities, and what I do if I'm Neopets.com, is I say, hey I'm Neopets.com, and they make you prove it to them somehow. There are different ways you can prove it, one way you can prove that you are who you say you are is they'll give you a file to put on your website, and then you put the file on your website, and then they see it and they're like oh you control that website so you must own it. So that's a pretty simple way to prove you are who you say you are. But there are other ways. There are more fancy certs that are called extended validation certs, where you need to get a lawyer to find something and show them the business documents and get them to say, I really am this corporation. And then if you get one of the certificates, you get a fancier thing in the browser, which says Neopets.com Incorporated. But anyway, I'll send them a thing, a certificate-signing request, which is ok - what's a certificate signing request? When you're encrypting data, you have this thing called a private key, which is like a secret that you use to encrypt the data. And an important part of a certificate is actually a cryptographic key. Like if you download the certificate for Neopets.com, you'll download a public key from them. So when you do a sign-in request you'll say hey, this is the public key I want to use when I'm doing cryptography for my certificate, this is when I want it to be valid from, this is when I want it to be valid until, this is the name on the certificate - it's for Neopets.com, and I think there's a few other pieces of information, but those are the important ones. So you wrap those altogether and then you send that to the certificate authority, and then they sign it, basically, with their secret key, which only they have. So there's this kind of interesting thing, where if I see a certificate for Neopets.com, how do I know that someone trustworthy signed it, right? Like how do I know to trust that person? And the way you can know who to trust is actually, you have a list of files on your computer that are hard-coded there, and they don't really change that much, it's just a list of a hundred people who your computer trusts, and that's it. Which is kind of cool. You'd think it'd be more dynamic than that, but it's not. It's just this list of a hundred people.

[00:29:26.24] SY: So by people -

[00:29:28.07] JE: Or a hundred organizations.

[00:29:28.07] SY: Ok, so those are the people who do the signing thing, who do that part of things.

[00:29:33.07] JE: Yeah.

[00:29:32.21] SY: Interesting.

[00:29:35.15] JE: And typically they'll be part of your browser, Chrome or Firefox will ship the list of trusted certificate.

[00:29:42.17] SY: Interesting, so SSL - at least the part that we're talking about - is I am who I say I am because this trusted organization that you have a list of on your computer doesn't really change has checked me out, has given me this file thingy to put on my computer or on my - where that website is hosted. And therefore, we have all agreed that I am who I say I am and you are safe to trust me. Does that roughly sum it up?

[00:30:11.22] JE: Right.

[00:30:12.28] SY: Ok, that's not too bad!

[00:30:14.11] JE: That's exactly it.

[00:30:15.10] SY: Ok so that's one side of being secure and all that. What is the encrypting data part of things, where does that fit in with how computer networking happens?

[00:30:27.01] JE: Here there's a protocol called SSL, or TLS. This is a weird thing that I think could be good to clear up. I assume that there are reasons other than to confuse us, but yeah, I usually treat SSL and TLS as being synonyms because it's easier. So how does encryption work? This is a good question. I'm trying to figure out how to answer this in a useful way.

[00:30:49.03] SY: Actually, let me ask you this - do you feel like this still falls under the networking umbrella? Or is that tangential enough that it doesn't make sense to cover it in this interview?

[00:30:58.22] JE: It's definitely another layer on top of networking. So we talked about TCP where you're sending streams of data, so encryption lives one level about that, where instead of sending streams of data, you're sending encrypted streams of data.

[00:31:14.09] SY: Yeah.

[00:31:15.25] JE: So it doesn't really care what's in the streams at all - it just knows that it's encrypting.

[00:31:20.06] SY: Interesting. So is it - you know we talked about data like hitchhiking across things and trying to get to its final destination. Is it that the road it takes on its way there is protected and encrypted, or is that before it even gets on the first truck it's already been encrypted, and now its encrypted version is being passed around through the internet?

[00:31:43.20] JE: So before it even gets on the first truck, it's encrypted. Because in some sense - this is important, because in some sense you can spy on network traffic if you want. Like if someone in my house is sending data over the internet, I could just look at it, right?

[00:31:58.09] SY: So weird that we can do that!

[00:31:59.24] JE: Like if some server in the middle is compromised, they can just read all the free data, or the NSA can do it, and of course they do. So like the cool thing about encryption is that people can't read your data. And the other cool thing about encryption is that they can't interfere with your data, like one thing that a lot of sketchy internet service providers do is they'll decide to insert ads or something into your web pages -

[00:32:27.27] SY: Oh what??

[00:32:28.06] JE: I don't know if you've ever seen that - it's so annoying.

[00:32:30.00] SY: I haven't, that's so inappropriate!

[00:32:30.26] JE: It's so inappropriate. But if you use encryption, they can't. Because they can't say oh there's this webpage, I'm just going to insert something in it, because they can't even know it's a webpage because it's all been encrypted.

[00:32:41.00] SY: So not only can they not see what's in it, they don't even know what it is.

[00:32:46.00] JE: Right, they don't know that it's a webpage - it could be anything. And so they certainly can't change it because they have no idea what it is.

[00:32:54.14] SY: Interesting.

[00:32:55.16] JE: And that's why I decided to use encryption for my website, actually, because I was like my website isn't secret, right, it's a public blog. But what I realized was, I don't want people to be inserting random ads into my website, I want people who are visiting my website to see it the way I wrote it, and that's it. And if I use encryption, then I can get that.

[00:33:17.09] SY: Yeah, very cool. I feel like we covered so much today - we talked about TCP, UDP, IP, we talked about the - what is that - Netcat - I keep wanting to call it Cat app, I don't know why.

[00:33:29.26] JE: We talked about hitchhiking.

[00:33:31.05] Sy: We talked about hitchhiking, yeah, we talked about DNS, we talked about a bunch of stuff. Of all of these topics - because you are a working developer, you code and build stuff on a daily basis, what of these topics, this conversation, has been most useful or applicable to what you do on the job?

[00:33:48.25] JE: So knowing how TCP works has been a little bit useful, because sometimes if I have two computers that can't talk to each other, understanding how TCP works makes it a lot easier to debug that, because I can be like, are any packets being sent from this computer to this computer? There's this program that I use called TCP dump, which will tell you exactly what packets are being sent and received. So I can just look at what's happening on the computer, and it makes it a lot easier to debug firewall issues. And my team at work is in charge of things like firewalls, so it's very relevant to me to be able to debug those issues when they come up. In practice my team owns a lot of networking stuff, like we own, we're in charge of a lot of that stuff, which is why I had to learn some of it. So I think I've had to use a lot of/all of this knowledge on the job.

[00:34:44.05] SY: That's awesome. And one thing I also just love and appreciate about you is the fact that not only do you create these awesome zines - and there is by the way a zine on networking, so if you want a visual representation of this conversation, definitely make sure to check out the networking zine, we have links, specifically to the networking one, in your show notes, so make sure to check that out. But the other thing I love about you, besides the fact that you make all of this great stuff, if that you make it pretty consistently - I was looking at your blog posts, and since December, 2012, you've been pretty regularly writing and sharing your knowledge - very technical knowledge, by the way - how do you do that? How have you managed to be so consistent and so regular in your creation and in your publishing?

[00:35:28.01] JE: So people ask me this a lot. One thing is I don't edit a lot, and I make a lot of mistakes in my blog posts, which is some sense on purpose, because if I'm going to write something, I don't have unlimited time, so I'll wake up Saturday morning, have an idea of something I want to say, maybe write for two or three hours, hit publish, and go to lunch.

[00:35:52.00] SY: Wow, that's awesome!

[00:35:55.00] JE: And the fact that I can do that is really important in being able to continue to write at all. And I've gotten pretty good at writing medium-good things quickly - they're not the best blog posts, but they're good blog posts and they're interesting and they say what I want to say. And I think it's been really important to focus on my writing stuff that's good over writing stuff that's perfect.

[00:36:22.16] SY: Yeah, absolutely. Have you always been that way, or did something happen to get you in that mindset of, I'm ok publishing mistakes here and there and it not being perfect?

[00:36:32.12] JE: So when I started blogging I was at this place called the Recur center where I was spending twelve weeks trying to become a better programmer. But another one of my goals was to get a job after, 'cause before I was at the Recur center I had a job which wasn't that great, and I wanted to have a job afterwards that was way better.

[00:36:52.25] SY: Yeah! Did that work?

[00:36:54.01] JE: It did!

[00:36:55.07] SY: Nice, wow.

[00:36:57.16] JE: Yeah, I wrote 48 blog posts, four days a week for twelve weeks.

[00:37:02.05] SY: That is so amazing.

[00:37:02.25] JE: And having done that, it became easier to write blog posts quickly. Because that was the rules, and I'd already been coding all day. So it was - I had to publish quickly, otherwise it wasn't going to happen.

[00:37:17.01] SY: That's the thing about constraints - sometimes it works in your favor, when you don't have a lot of time, you don't have a lot of money, you have to figure out a way to make it work within the rules that you have, so yeah. Once in a while it can come in handy - looks like you took advantage of those constraints.

[00:37:30.26] JE: And I think I learned by doing that that it's really not that predictable what people are going to find interesting or not, so in some sense it's better to make a lot of stuff that I like and that I think is interesting, but not stress too much about trying to optimize what other people are going to find interesting.

[00:37:47.05] SY: Yeah, such great advice. So next let's move on to some fill in the blanks - are you ready?

[00:37:52.01] JE: Yeah.

[00:37:52.16] SY: Number one - worst advice I've ever received is?

[00:37:55.04] JE: Ok so I thought about this a lot, and I determined that what happens is, if people give me advice that I don't like I kind of don't hear it/ignore it. So I have no idea.

[00:38:09.11] SY: That's awesome, that's a great filter to have. Ok, let me ask you a different question then - what is bad advice you heard given to newbies, to beginners?

[00:38:18.05] JE: I'm kind of blanking on - the only advice that I can think of is to focus on one thing, like if you're learning programming to take a programming language and stick to it. Which I think is pretty reasonable advice, but I've forgotten all the rest of the advice.

[00:38:41.15] SY: Ok, that's fine. Number two - my first coding project was about?

[00:38:48.09] JE: So, I wrote a hangman game on my TI-83 calculator in math class!

[00:38:51.19] SY: Neat! So you were one of those people - I was so jealous of those people, who knew how to program things in their TI-83, I never figured out how to do that. That's awesome.

[00:38:59.09] JE: It was really exciting to me, because I couldn't figure out to program before that - like I had this Windows computer and I didn't know how to program it, and then I got the calculator and somehow I figured out I could program it, and it was just the most exciting thing. The first time I had something that I could figure out how to program.

[00:39:13.13] SY: Yeah. Number three - one thing I wish I knew when I first started to code is?

[00:39:19.01] JE: When I started to program, I was fifteen, and I think I spent a few years, maybe three years, programming kind of in a, almost in a void. My mom bought me a computer, which was amazing, and I installed Linux on it, I had my own computer, and I figured out how to make Linux work -

[00:39:42.02] SY: Good for you!

[00:39:43.12] JE: And it was - was it Debbie and Sarge? Just when it got a good installer. Anyway, I got a programming book about how to write Pearl. And I feel like I lived in this space where I was just figuring things out on my own, at probably a relatively slow pace, and it was really great. I'm really happy that I had that, because there wasn't anyone telling me that I wasn't learning things fast enough or that I was going in the wrong direction - I didn't get any advice. And I feel like that was in some ways a great gift, because I could just do anything I wanted, and have fun with it.

[00:40:21.01] SY: I don't think I've ever heard someone say that the lack of guidance and the lack of mentorship was a good thing, but that's an interesting perspective. I feel like there's a lesson in that for people listening who maybe in a similar position, where they're kind of learning mostly by themselves, mostly in a vacuum, maybe there's a freedom in that that allows you to explore and try new things and figure out for yourself what should work and what feels right. And kind of go about it untainted by people's opinions and perspectives. That's interesting.

[00:40:55.19] JE: Yeah, and I think especially if you're, at the time I was in high school, right, so I was lucky in that I didn't have any pressures, I didn't need to, I was in school, I could just do stuff on the side, I had enough free time. I mean, obviously a lot of people who are learning to program aren't in that position, they have to maybe actually have a job, and support themselves, which I didn't have to do, but it's - I think if you are in that space I think it's really cool.

[00:41:20.09] SY: Yeah, absolutely. Well, thank you so much Julia for teaching us all about networking. Do you want to say goodbye?

[00:41:25.24] JE: Yeah, thank you so much for having me, this was wonderful.

[00:41:29.16] SY: And that's the end of the episode. Let me know what you think. Tweet me @CodeNewbies, or send me an email, hello@codenewbie.org. If you're in D.C. or Philly check out our local CodeNewbie meetup groups, we've got community coding sessions and awesome events each month, so if you're looking for real-life human coding interaction, look us up on meetup.com. For more info on the podcast, check out www.codenewbie.org/podcast, and join us for our weekly Twitter chats. We've got our Wednesday chats at 9 PM EST and our weekly coding check-in every Sunday at 2 PM EST. Thanks for listening, see you next week. (Music).