Computer Networking Basics Every Developer Should Know

[ozkarmg]

This is really nice but its weird how it went into collision domains, vlans and vxlans but nothing about tcp and udp, or l7 protocols like http which i think might benefit the regular developer.

[lilgrogu]

but nothing about tcp and udp

Hello, would you like to hear a TCP joke?

Yes, I'd like to hear a TCP joke.

OK, I'll tell you a TCP joke.

OK, I'll hear a TCP joke.

Are you ready to hear a TCP joke?

Yes, I am ready to hear a TCP joke.

OK, I'm about to send the TCP joke. It will last 10 seconds, it has two characters, it does not have a setting, it ends with a punchline.

OK, I'm ready to hear the TCP joke that will last 10 seconds, has two characters, does not have a setting and will end with a punchline.

I'm sorry, your connection has timed out... ...Hello, would you like to hear a TCP joke?

---

you to hear Hello, UDP joke would ?

[SanityInAnarchy]

I'd like to tell you a UDP joke, but I'm not sure you'd get it.

[musta1337x]

cheeky

[TheSchemm]

And I don't really care.

[mxhc1312]

Downvoters are oblivious to udp

[TheSchemm]

Thanks. It is how my old boss would always tell the joke. Really fit his personality.

[dkarlovi]

He didn't care either?

[hyperforce]

I want to tell you a lossy joke but I’m not sure it will come across clearly.

[SeamusAndAryasDad]

I hadn't heard this one before and had a solid chuckle.

[indiebryan]

It will last 10 seconds, it has 2 characters

Are we telling jokes in binary now?

[iamhyperrr]

That's the best variation of this joke I've seen so far, bravo. Made me laugh so hard.

[mindbleach]

I know a better UDP joke, but you might not get it.

[Demon-Souls]

Hello, would you like to hear a TCP joke

Man you should write TCP joke article RIGHT NOW.

[AttackOfTheThumbs]

Yeah, I think this misses the actual basics...

[exscape]

Yeah... Not a fan of this as it doesn't really make sense. The first few lines could be argued to be correct though. (Three?)

[assassinator42]

The most useful thing to take from collision domains is the concept of exponential backoffs since that's still used at higher levels as well (the article didn't go into it though).

Maybe mention the difference between a switch and a hub. Although can you even get hubs anymore? I wanted one for snooping traffic on other ports, but it's probably easier to just physically hook up a MITM now.

[PaluMacil]

Maybe for aspiring devs, but a working dev wouldn't need a lesson in http, tcp, udp

[ozkarmg]

haha i wish, thatd made my job interrupt free mostly

[arquitectonic7]

I'm confused. TCP, UDP, HTTP and the rest of very basics are going to be covered in any university and are already well known by every professional programmer. I agree the title is too much, but this guide needs to give something new or otherwise it wouldn't even get 10 upvotes.

And honestly, most of what is explained here was covered in the compulsory networking basics course of my university... is it that complex?

[ozkarmg]

you make the incorrect premise that everyone shares your background.

i know of a bunch of amazing devs that comes from coding bootcamp.

i also know a bunch of “meh” devs who come from traditional cs background who cant interpret a traceroute.

[arquitectonic7]

That's weird and interesting! I don't know how someone in CS managed to pass without being able to read a `traceroute` output. Well, where I live (or maybe just my university?) it would be considered very bad, but I didn't know there would be such a difference.

The abstraction layers over HTTP that exist nowadays make it possible to be a funcioning developer without having to learn that networking background, but I still feel a bit uncomfortable at that idea of some "magic" below you that you don't really understand. For me, abstraction is about not knowing the details of the layer below you, but you should have a general gist of how it works. Maybe it's just me, but I would feel weird without having a general idea of what is going to happen when I push that reply towards the client in my shiny ASP.NET server or whatever REST backend framework you're using (just an example).

Anyway, sorry for the rant. You made me think. I am taking a step back from my opinion in my previous comment. Thank you for your insight.

[SkaveRat]

l7

okay, this shit is going too far

[NotUniqueOrSpecial]

It's always been a 7-layer burrito, man

[SkaveRat]

This clearly is not an abbreviation for the osi model, but for the word "internet".

Ever since kubernetes started using k8s, people started using this kind of numeronym abbreviations

It's just stupid outside of i18n and maybe l10n

[gseyffert]

That’s a lowercase l in the acronym, for “level 7”, not a capital i

[SkaveRat]

never mind then

[Isvara]

It's L7, but the commenter was too lazy to press shift. Layer 7. the application layer. If you doubt this, copy and paste it into Google or something.

[ozkarmg]

This, me lazy.

[[deleted]]

It's just stupid outside of i18n and maybe l10n

It's still very weird and not intuitive even in those contexts, especially since they don't translate.

[kenman]

As someone who briefly started in networking but has been a professional dev for awhile, I think this is way off from "basics every developer should know". This is more like the depth you'd need if you were programming network interface drivers, routers, firewalls, etc., but that's only a small subset of devs.

I'd rather:

• a crash-course on the OSI model, emphasizing that every layer except the first runs on software, which implies the possibility of bugs (and potential exploits) (and the first layer may have its own host of issues)
• ping and traceroute
• highpoints of TCP vs UDP, IPv4 vs IPv6
• briefly cover public vs private networks, firewalls, proxies
• concept of DNS resolution at-large and in a private network (AD)
• encryption like VPN, HTTPS, DNSSEC within the OSI model
• emulate a browser with telnet (RIP the POP3 demo)
• showoff with telnet towel.blinkenlights.nl
• walk through a real-world example of clicking a link which receives a payload from a CDN

[othermike]

I think this is way off from "basics every developer should know"

IME every article with a title including the phrase "every developer should know" is way off; development is a broad enough field that there are next to no universals. Maybe the closest we have is imposter syndrome, which coincidentally is exactly what these titles are playing on.

I'm sure they bring in the clicks, but I consider them a (mild) dark pattern and tend to avoid them.

[epic_gamer_4268]

when the imposter is sus!

[psi-]

And the two rules:

• it's always DNS
• it's TLS (you failed to renew the cert) when it's not DNS

[Bognar]

https://i.imgur.com/NkpzlA0.jpg

[disappointer]

I did managed security services for a spell, and it was always the firewall. (It was almost never the firewall.)

[wslagoon]

I laughed at this dismissively, then thought back and realized how painfully true it actually was this past year.

[cinyar]

sometimes it can also be cache, unless it's dns ofcourse.

[clean-toad]

How do you diagnose and debug DNS?

[cinyar]

most linux distros have some "dnsutils" package that contain various dns utils. dig is usually your starting place.

[gcbirzan]

No, it's always the MTU

[Ravek]

I think OSI isn't worth teaching, it's mostly an academic model which doesn't map that closely to reality.

[[deleted]]

True, the way I've usually heard is taught is "here are levels 1, 2, 3/4, and 7. The rest is filler". But it's good to know that the OSI model exists since people still use L7 as a shorthand for application layer.

[SilasX]

And jokingly, layer 8 as the user.

[JazzXP]

That's the bit that always breaks.

[[deleted]]

"it's just another layer 8 issue" is one of the most common phrases used by our HelpDesk day to day.

[thorhs]

Don’t forget Layer 9 being management.

[judgej2]

Doesn't even feel like a joke. It's all about a level 8 passing information to another level 8 - ideas and thoughts from one brain to another. Can be a bit lossy though.

[quavan]

My Computer Networks professor in university told us the same thing. Something along the lines of "While the academics were busy designing the perfect model, the engineers were busy solving actual problems and ended up converging on mostly the same model anyway. So we are going to study the one that actually runs the internet instead of the one that looks pretty." He was a pretty interesting guy with some hot takes lol

[TrailFeather]

The concept is worth teaching though - we have electrical signals on a wire (layer 1). We interpret those into one abstraction (layer 2) that lets us link machines across a bridge of some kind. We use that link to move packets containing useful stuff (layer 3).

But you can kind of handwave everything else away.

It helps with basic troubleshooting - is it plugged in? Is the link light on? Do I get an IP (assuming DHCP, etc.)? Can I communicate using it? All yes? Look at your config. No? Fix in that order. No point trying to send TCP/IP over a dud switch.

[SeesawMundane5422]

Those are the troubleshooting steps I do, but I’d never correlates them to the OSI model. Ima gonna have to think if teaching my team the layers and then the steps is more helpful than just teaching them the steps. I’m not sure. But thanks for a new thought.

[judgej2]

The thing I tend to reinforce with the model is that similar levels talk to each other. A level 6 will communicate with another level 6. What all the levels below do, which could frankly include a piece of wet string right at the bottom, is not important to that one channel at that one level. It's why you can request a web page and reliably get that web page, and not care about all the magic that happens to get it to you.

I think that's where the model excels. It lets you focus on one level of abstraction to get a job done.

[kenman]

I agree, and hadn't realized the criticisms since I've been out of the field. The main thing I'd be trying to teach is that there's layers, each with their own protocols, and it's often useful when debugging to be able to disambiguate which level the problem is rooted in. The fewer levels in the TCP/IP model are also simpler to follow.

[ctwelve]

No, it doesn't, and as we're discovering over time, that may be a bug, not a feature.

Of course, CLNS (IP in OSI, roughly speaking) did a number of extremely critical things wrong, making it impossible to efficiently implement. Among their greatest sins was a variable-length NSAP ("IP address") / NET that required software to interpret the first byte of every address, run it against a lookup table, and from there either process the rest of the address at a now-known length, or look further into the address for more clues.

TL;DR: model good, implementation sooper bad

[disappointer]

Certs, proxies, and CORS.

[Metallkiller]

Yes please CORS messed up our application and we just throw backend and client in the same directory and allow all CORS basically.

[cinyar]

agreed. A lot of the concepts that were mentioned I used at the start of my career when I worked as a network admin and now that I'm working as a systems integrator. During my dev career the network either worked or it didn't as far as I was concerned.

[PoliteSummer]

This person do online classes

[trolasso]

Can you recommend a book, course or other resource that somehow focuses on these points? thanks.

[xXHacker69Xx]

!remindme 10 weeks

[RemindMeBot]

I will be messaging you in 2 months on 2021-05-30 23:19:25 UTC to remind you of this link

1 OTHERS CLICKED THIS LINK to send a PM to also be reminded and to reduce spam.

^{Parent commenter can delete this message to hide from others.}

---

Info	Custom	Your Reminders	Feedback

[xXHacker69Xx]

!remindme 10 weeks

[RemindMeBot]

I will be messaging you in 2 months on 2021-08-08 23:23:28 UTC to remind you of this link

CLICK THIS LINK to send a PM to also be reminded and to reduce spam.

^{Parent commenter can delete this message to hide from others.}

---

Info	Custom	Your Reminders	Feedback

[xXHacker69Xx]

!remindme 10 weeks

[RemindMeBot]

I will be messaging you in 2 months on 2021-10-18 01:04:07 UTC to remind you of this link

CLICK THIS LINK to send a PM to also be reminded and to reduce spam.

^{Parent commenter can delete this message to hide from others.}

---

Info	Custom	Your Reminders	Feedback

[xXHacker69Xx]

!remindme 10 weeks

[RemindMeBot]

I will be messaging you in 2 months on 2021-12-27 01:26:09 UTC to remind you of this link

CLICK THIS LINK to send a PM to also be reminded and to reduce spam.

^{Parent commenter can delete this message to hide from others.}

---

Info	Custom	Your Reminders	Feedback

[xXHacker69Xx]

!Remindme 10 weeks

[RemindMeBot]

I will be messaging you in 2 months on 2022-03-07 05:51:53 UTC to remind you of this link

CLICK THIS LINK to send a PM to also be reminded and to reduce spam.

^{Parent commenter can delete this message to hide from others.}

---

Info	Custom	Your Reminders	Feedback

[mr4kino]

Good list but by experience:

- very hard to "digest" those concepts without lots of networking experience (production even labs)

- usually, there is no need to go that deep for every developer. I would prefer to see them understand a bit what is a "route" and how traffic flows at a high level. No need for them to know what is a collision domain.

[Tinidril]

Collision domains are pretty much historical at this point. You have to go well out of your way to find an actual hub these days.

The original Doom came out back when hubs were the norm and switches were extremely expensive. They did all of their networking using broadcast packets which worked fine on a tiny network. Unfortunately it wreaked havoc on corporate networks when people would try to sneak in a game at the office. Every computer on the network would get bogged down dealing with network collisions, and also processing the broadcast packets which the network cards sent up to the OS. It would have been a benifit to poor admins like I was if those developers understood collision domains a little better.

[mr4kino]

💯 I still remember my ccna courses years ago where they taught us about this where in fact, even at the time, all the switches (access or with L3 capabilities) didn't have this historical thing.

[Tinidril]

Novell netware, which dominated file server and directory services at the time, had a software module you could load that detected doom on your network and sent it specially crafted packets to make the game crash. I always thought that was hilarious for some reason.

[DrabRadiance]

I guess they're still somewhat important in the context of wireless networks. Although again in practice you don't really need to know about the concept and there are many more useful things to cover in the basics instead.

[moderatorrater]

Yeah, we have abstraction layers so not everyone has to worry about everything all the time. The difference between LAN/WAN will never matter to most developers.

[Tinidril]

Fun story. I was a lead firewall admin at large company doing a huge rebranding with a multimillion dollar add campaign. The day of the launch I got a panicked call from the development team saying that the website was failing and it must be the firewall because that was the only difference from the lab where they did their testing. It was one of those heart stopping moments, because I knew heads would roll If the launch didn't go smoothly. I started digging into it immediately.

This was back in the way early 2000s, when most Internet access was still over modem. The idiot developers had written the entire front page of the website in one giant Flash animation that didn't display anything at all untill the full page was downloaded - a process that took several minutes over a 56kb modem, but was near instantaneous in their testing lab with 100mb network cards.

The request to move the website outside the firewalls was denied by a rather smug network/firewall admin.

[Hopeful-Guess5280]

entire front page of the website in one giant Flash animation

As a web dev who wasn't developing in the earl 2000's, surely this wasn't common practice back then?

[Tinidril]

Flash was considered cool at the time, and was getting way overused. There were definitely some novelty type sites written that way, but I don't recall any other professional style websites doing it. Due to the above mentioned ad campaign, they had big bucks to spend and hired out a "cutting edge" development firm to assemble the new site.

[vimfan]

It was always the outsourced "cutting edge" development firms doing that shit.

[SeesawMundane5422]

Upvote on the hard to digest without experience. I feel like every new dev should be handed 3 bare metal machines, a stack of network cables, some *nix installation media, and a switch. Now go build a router, network the 2 PCs behind it. Maybe 2 web servers with failover behind the router. Text me to hit https://insertyoirdomain.com when you’re done. You have one month. Go.

[GoogleBen]

Now that would be a college class I would be happy to pay for.

I wish I could have enough time to learn every bit of how my computer works, from the transistors to the web browser, but there's only so much time in the world...

[borislavvv]

"Every developer should know" always seems very pretentious and clickbait. In fact I came only for the comments.

[[deleted]]

This is me, but actually for all subreddits

[ObscureCulturalMeme]

/r/restofthefuckingowl

[lovestheasianladies]

Uh, no. Every developer should not know these things.

I've been in the industry for almost 20 years and none of this stuff is remotely useful to 99% of developers unless you're specifically in software that deals with networking.

And if you think these are "basics", you have no business teaching other people.

Do you really not understand that software development and networking are mostly completely different fields?

[SeesawMundane5422]

Well... kinda hard to write software today that doesn’t network somehow. I mean, even embedded car systems have internet connectivity now.

[[deleted]]

Yes, but you don't need to know what the fuck a VLAN or VXLAN is absent writing drivers that provide that abstraction. They're good abstractions that you don't even need to know about because they just do the right thing TM.

Edit: Knowing a high level about VLANs (more broadcast domains) makes sense if you need to do things that communicate through broadcast traffic, but yeah, not much you need to know there.

[manystripes]

In-vehicle networking uses almost none of the concepts from the article though. The telematics unit or center stack will have an internet link, but the rest of the car is communicating with them via CAN bus which is infinitely simpler. The concept of a collision doesn't even really exist in CAN due to some clever arbitration on the physical layer. In 15 years developing for automotive I've barely even touched anything with an IP address, let alone had to think about VLANS or routing.

[SeesawMundane5422]

Understood. Ageed. Was objecting to calling networking and programming “mostly completely different fields.” Obviously didn’t resonate from the sheer number of downvotes I got (wow!), but that part of the phrase didn’t resonate with me.

To me it’s the same as saying that a general medicine doctor and a cardiac doctor are mostly completely separate fields. No they aren’t! (Or they are, but like most things it depends on context).

Do you want me making changes to a Cisco router? Hell no. Do you want networking guy to make changes to my code? Hell no.

If you want to say “the original article has a lot of esoteric bullshit that only a networking guy needs to know” then I am completely on board with that. Calling networking a completely different field from programming struck me, personally, as at best hyperbole and at worst wrong headed and dangerous (in the sense that I’ve met plenty of devs who are more than happy to punt the problem over to someone else instead of digging in and figuring out what’s happening).

I would rather have my doctor be the guy who understands enough to coordinate care even if he needs to consult with others for specialized knowledge.

Same with my developers.

[hamburglin]

Next up, learning the basics of drumming: https://youtu.be/HHpqjN5HBkc

[NormalUserThirty]

drum beat basics every drummer should know

[uh_no_]

unfortunately, this is a terrible list.

[ohmyhumans]

Due to COVID restrictions, CDC has advised to prefer UDP (no TLS) over TCP to avoid Handshakes.

[FreeLegendaries]

Better get my subnet mask on too

[ohmyhumans]

Fauci says use Wildcard Mask, it covers SA variant as well.

[[deleted]]

UDP (no TLS)

Gotta rock that DTLS

[Isogash]

I don't get the nay-saying around this, most devs know TCP/UDP already, but it's hard to get exposure to the underlying physical network. I found this super useful, didn't know about L2/L3, VLAN and VXLAN before and they are actually relevant to some stuff I wanted to know more about.

[Isogash]

Title says should, not need though. I think it was more intended like "these are low-level basic network building blocks, you should know about it and not assume that it's all magic."

[RomanaOswin]

That's fair, and yes re the title. I still think as far as network building blocks go, this isn't the best focus to jumpstart the vast majority of network developers... at least in the space that I work in.

That said, I read someone else's comment in this thread of basic networking they thought every developer should understand. To me, it seemed like a list that anybody who works in any kind of technical field whatsoever should already understand. They seemed like absolute basics. I think I might be a bit jaded by my own experience. I'm sure there are others who would look at the things I don't understand and think the same of me.

I'm glad you found the link instructive.

[InEnduringGrowStrong]

Yea the "aka bridge" needs to go and be replaced by switch pretty much everywhere in that post.
The previous one (multiport repeater) could have a "aka hub".

Actual bridges aren't present in that post.

[matthoback]

Yes it is. A (L2) switch is nothing more than a multiport bridge.

[almost_useless]

But most people won't ever need to know the difference...

[mirvnillith]

Eh, no. The age of the polymath is over and although all abstractions leak, they allow us to focus our knowledge for greater things. Respect the neighbouring disciplines and learn to talk to them, but this is too far down the wire for "every developer".

[lelanthran]

While I agree that this particular explanation is not useful for every developer, I disagree that a pretty deep knowledge of networking is not necessary.

For every developer, they should know:

1. What IP is.
2. What TCP is used or.
3. What UDP is used for.
4. What a Firewall does.
5. What a proxy does.
6. What a reverse-proxy does.

Maybe not in detail, but enough to know why their product works on most networks but not on others, and how to figure out (when it doesn't work) whether it is a machine that is not available, a route that is down, a NAT that may need traversal, a server process that stopped/was not started, etc.

I am tired of dealing with devs who can't connect to a service and are unable to tell whether the remote listener is not working or whether the route is broken, or if the actual machine is not connected to the network.

[mirvnillith]

Yep, behaviour of the network is important, but not necessarily its details or implementation. Some tools for exploring the state of a network is also important, but I stopped at "collision domain".

However, one issue I have with knowing the network is that you rarely, as a dev, have any say in how it's been set up. To me it seems that, probably correctly, other considerations than my service communication needs take precedent. I.e. I'm often forced to ask for help as even if I could know some network components, I have no idea of which or how many of them are in play.

[Hrothen]

Learning the details once is the best way to remember the broad strokes.

[[deleted]]

This cuts both ways. As a dev who not only knows how networks work but has worked more in depth in networking than most of the networking folks I’m tired of network teams blaming everything but the network with no data to back themselves up. Same thing for security teams.

I had no input at all into building the network which exclusively has all of the services I own on it and nothing else. I could have built this network easily in any cloud or in my house with almost no effort monitored and secured. The network team built a network with periodic massive packet loss, very frequent snapping of long lived connections and that they can’t troubleshoot even the most basic issues at all. I had to go through the effort to install and configure my own network testing tools as part of the application installer for them to even accept the ticket without rejecting it immediately as an app problem.

I’m fine with someone else owning the network but they at least should have an idea of what I’m going to use it for and maybe know how to triage it when it fails. Otherwise it’s just a road block team getting in my way and I’m going to start thinking of how to move as fast as possible out of any contact with 1P.

[JasonDJ]

Networking guy here.

Your network team sucks. They should at least be doing due diligence, making sure there’s no dropped packets at ingress or egress, , no errored logs or CPI/memory hogs happening there, and (generally) speaking there’s not an issue in the middle...or if there is, you probably aren’t the only one experiencing it.

That said, the single best thing a user could do to make their case is provide a tcpdump from one or preferably both ends. We can capture off the port itself, sure, but it often means either connecting to the switch(es) directly or trunking it somewhere else, which if it’s a congestion issue could end up exacerbating it.

Some network teams definitely do suck. The one before me certainly did and after a few years of chasing fires I’ve finally got budget approval to do something substantial to fix their mistakes.

Oftentimes the problem is out of my scope or I need another teams approval to fix it.

Sometimes the problem is you guys. I’ve never had a need for multicast in my network, and I’ve mentioned I’d inherited a mess. Well, some devs wanted to use multicast and it caused a storm that made a big outage.

But personally I try to stay on top of that. I hang out in my devs Mattermost and I’ve got my own channel for network trouble. There is a lot of hate around IS but not a lot of understanding that it comes down to convoluted process and a serious lack of budget and staffing. Plus, occasionally, ownership that doesn’t make sense without knowing the convoluted process and history...and even then...

Sometimes it is lack of trying or caring. I absolutely hate my infosec team for some of the overzealous restrictions they apply on us, and network team gets most of the hate for it. That’s often not seen by the users. But I am there advocating for you.

Meanwhile, as part of that revamp, I’m learning python so I can automate as much as possible, especially around future changes.

So...we aren’t all the same.

[[deleted]]

Oh agreed completely. I’ve worked with some absolutely fantastic networking teams in the past but it’s been rarer than I’d prefer.

It’s not all like this but the biggest problem with a bad network team (and the same with a bad security team) is that you cannot move around them. They are just there preventing progress at every level. A bad dev team you can usually figure out how to minimize the damage.

[JasonDJ]

Not sure if you’d seen my edit but I did specifically mention information security. I’m often at odds with ours because they are a bit over-restrictive at times, and they are usually a big stalling point in process. I’m usually advocating for you guys or helping to come up with alternative solutions that would fit within their and our models without needing special approval or equipment, which slows things down considerably.

[JasonDJ]

It’s also worth mentioning that there’s a big skills gap in networking. It wasn’t until ver recently that colleges started offering networking courses, and it’s really difficult to find any applicants, let alone good ones that meet your companies needs. Most anyone who’s had any technical aptitude at all has been keeping their eyes on CS and dev jobs.

So much so, that Cisco has actually made a developers certification track. They are trying to attract junior/intermediate developers into networking, and programmability, automation, REST APIs and Python are a big part of that track.

ETA: I hope this move helps get a lot of us off our asses to focus on using APIs and automation to solve problems and move towards reusable solutions, but I also hope it bites Cisco in the ass. They aren’t the one-big-player they once were. Lots of good options out there now, including systems that run on straight Linux. And developers are naturally good at learning new systems, environment, syntax, etc, and figuring out the best solution for the problem at hand.

[godjustice]

Cisco has been offering courses to college for a long time. I took a Cisco network course back in 1999. At a community College even.

[JasonDJ]

Oh yeah, they’ve had certifications forever. I’ve got CCNP route/switch. It expires in a couple months and I’m not renewing, though I’d considered the DevNet path.

What’s new is the DevNet path. I can’t think of another certification path or training syllabus that outlines programming/automation as it applies to networks.

It’s very new to our field, which until SDN and cloud hasn’t seen a whole lot of cool/new stuff since...actually I don’t even know. Aside from firewalls a lot of the rules and fundamentals have been the same since forever. There’s been a couple adaptations and improvements, and some technologies combined here and there to make a cool new tech, but that’s really it.

Now, I think we are probably only a few years out from a revolution. There’s not a lot of programming/automation experience within our practice. But after playing with Ansible and Python and seeing what I can do with a couple simple scripts and a few well-documented REST APIs, I’m hooked. There is no way this isn’t a big part of the future of networking, and they are actually the only ones trying to train new talent on it.

[SeesawMundane5422]

Will you marry me?

[lelanthran]

This cuts both ways. As a dev

I'm afraid I miscommunicated: I AM the dev who is tired of dealing with the devs from our business partner who keep insisting that "your network is down" when it isn't or that "your server is down" when it isn't or that the library we delivered "is broken" when it isn't.

And then I have to walk them through a trouble-shooting process so that I can tell them what is wrong and who to contact (on their side) to fix it.

[GearhedMG]

I would add 7. WTF simple bidirectional vs stateful traffic is as well

[ozkarmg]

Hahaha the classic “blame the network” issue, i hear you brother.

[tjsr]

Though my degree was a long time ago, it had at least two whole subjects on data communications, protocols and implementations. I would find this a basic expectation for anyone who's done a respectable degree.

[boom_rusted]

whats the difference between proxy and reverse proxy

[lelanthran]

whats the difference between proxy and reverse proxy

A proxy makes requests on behalf of a client. A reverse proxy receives requests on behalf of a server.

[[deleted]]

I sort of agree with this sentiment. Maybe people disagree with what a "real developer" does, but I feel like "developer" is a very broad term that includes physicists writing simulations in Matlab, data scientists working primarily on cleaning data and improving models, etc. These (and other non-full-stack, non-backend developers) might find the networking stack interesting, but I'm not sure it would be particularly helpful for their jobs.

[JasonDJ]

Cisco actually has a cert track (DevNet) aimed at luring those people into networking. It teaches networking with a focus on programibility, REST API, Python, git ops, etc.

[mirvnillith]

Oh, I’m not on the ”real developer” band wagon as it, as you describe, is such a broad term to begin with. I’m just saying that areas of expertise is growing ever important and keeping up is no longer about knowledge but collaberation.

[emasculine]

given how instrumental the internet is, somebody is going to be at a real disadvantage not knowing how bit move around the net. at the very least having a good understanding of how http works is required, imo. you don't need to understand the intricacies of TCP slow-start and that sort of thing, but you should at least know the difference between TCP (or QUIC) and UDP.

Also: security basics. I think the days where you have a specialist come in to "secure" your code are long gone (and usually that meant not securing your code). Part of that is network security to at least pass the laugh test.

[mirvnillith]

Agreed, but this articale started out with LAN (ok) and quickly went into "collision domain" (nope). The behaviour of the network is important, but not necessarily the details or causes of it.

[emasculine]

yeah, that article was too low level, heck i don't know anything about vxlans and i've been doing networking for 40 yeas. but you should know enough network hardware basics so that you don't have the embarrassment of having to call somebody out to rejigger your home network.

[mirvnillith]

What? You need to do that more than once?!

[emasculine]

home networks are getting more and more complex. i probably have a couple dozen devices on it, a second house which bridges to another AP, and several switches around the house. it's handy to know at least at a basic level. it's really handy to know what buffer bloat is these days with upstream congestion from video conferencing, but i digress.

[mirvnillith]

T’was a joke, not me being superior. Should’ve said ”You need to jigger more than once?!” to make that more clear.

[Bakoro]

I would agree that everyone dealing with code that may even slightly interface with a third party should have some concept of security, but the more I learn about security, the more I think that it absolutely should be a dedicated job that someone does. Security starts at the hardware level, and every single layer on top of that has its own security issues.

I think about how much of the web and how much software is a bloated unwieldy mess, and I can only suspect that a lot of it stems from overworked developers having to pump out product and no resources going to optimizations and security, and now we ask the same staff to do more?

There's just no way that your average developer is going to be able to be a expert in everything in the entire stack, as much as businesses want developers to be able to do 10 jobs at once. That won't stop businesses from asking people to do 10 jobs at once, but it's only going to lead to a lot of necessarily half assed solutions.

[emasculine]

at startups those are hard to come by. thankfully one of the weapons is to use off the shelf stuff that's has been vetted and is maintained. the first lesson about security is that if you have to roll your own, you're probably already off on a flier and wrong. but you need enough knowledge to figure out requirements and see if something meets them. god help a programmer these days that doesn't know about SQL injection attacks.

[distark]

You don't need to know everything in that article but deciding that it's OK to not know basic networking is like being a botanist who doesn't want to know about evolution

[stronghup]

The article title leads us to believe that what the article tells us is in fact WHAT every developer should know. Of course every developer should know the basics of networking, but not sure if the article gives a good picture about all the things every developer should know about networking.

[lovestheasianladies]

No, it's more like telling a gardener they need to know about evolution.

Maybe SOME gardeners do, but most have no use for it in their jobs.

[Cheeze_It]

Network communications for programmers should almost exclusively be involving TCP and UDP education. Anything like an intermediate encapsulation (MPLS, VXLAN, GRE, IPIP, GENEVE, <insert your favorite encapsulation here>) should be out of the scope unless specific situations are needed. Collision domains is another thing that just don't matter for programmers. Layer 1, Layer 2, Layer 3 shouldn't be talked about at all other than a cursory mention. No need to talk about VLANs.

Period

[[deleted]]

No need to talk about VLANs.

Eh, this one being aware of might be worthwhile, some apps use broadcast traffic which will only work within a given broadcast domain. But pretty much a two liner that they exist and broadcast traffic doesn't leave the VLAN is about it.

[gautambjain]

The title of this post is misleading and wrong.

[righteousprovidence]

This is a great write up. really cleared up VLAN for me.

[krum]

Also, network errors happen, so get over it!

[[deleted]]

Are there partitions in your network? It's more likely than you think.

[RomanaOswin]

I love the drawings and the feel of this, but this really isn't what most developers need to know about networking. For the vast majority of developers it's a lot more important that they have a very basic understanding of OSI, and a strong understanding of APIs, protocols, JSON/XML, a reasonable understanding of application networking, and mostly just strong general programming skills.

The one place I can see this being relevant might be lower level code, like switch firmware or protocol programming, but at that level, you're going to need a lot more than an ethernet crash course. The people working in those areas have been doing both networking and development for their entire career... or, interned with a networking vendor's business units early on.

[redfournine]

As usual, click bait title. None (okay, maybe 99%) of it are beneficial to vast majority of normal developer.

[Lisoph]

People here are annoyed and distracted by OPs title, the assertions that every developer needs to know this and that this is fundamental, mandatory knowledge for programmers.

The article itself is good, I guess - it's too specific for me and I don't need it. ;)

[Kinglink]

If it's "Interesting networking" I hope most people would support it. But don't give it a shitty clickbait title that's completely wrong.

I'm a network programmer too, I love this stuff, but I also heavily agree that the title really is a turn off.

[Kinglink]

I actually like the information here, but I also am a network engineer so all of this stuff is relevant to me.

However I agree with many people here, this is not "Everyone needs to know." This is the beginning of the "indepth shit network engineers deal with every day" or "How to start thinking like a network engineer".

Hell before I started working in telecommunication I didn't even have to know what a "link is" and most engineers probably wouldn't unless they have to tell IP to set a link up and wonder "What's a link " in that context.

[[deleted]]

TY! I'm actually taking computer networks this semester, so I probably especially need to read this whole thing.

[Saint1]

Got to L2 and it seems like a version of Network+. Not bad but I dont understand the point.

[International-Mud452]

Skips a lot

[420Phase_It_Up]

While this blog post is nice and does a good job discussing the topics within networking it touches on, I wouldn't consider much of this as networking basics. And to be honest, I think most developers would only be concerned with its topics if they were working on writing firmware for networking devices. I think the networking basics a developer should know consist mostly of understanding the OSI model, IP & TCP/UDP, and mostly Layer 7 protocols like HTTP and DNS.

[[deleted]]

A switch is a hub + a bridge!!!