Network Protocols

Exactly, I thought the very same thing. In fact, I read it with a critical eye at first and as I got through I was quite pleased. I thought it was really cool to mention the 8b/10b encoding near the end. yes, well done indeed!

It's slightly inaccurate in that it doesn't mention any other routing protocol than BGP. BGP is used between Autonomous Systems, but within ASs usually other routing protocols are used.

You might find this interesting in the vein of weird networking things: https://www.ibiblio.org/harris/500milemail.html

As an old dude who went through engineering before networks were a major thing and worked some years on embedded devices, I also find these sorts of articles extremely interesting.

IMHO the classic is still TCP/IP illustrated by Richard W. Stevens.

I agree, I had a course about this topic in university and I was like "This is why I am here".

There are things you don't know that you don't know. And those always get you.

Pick a simple driver (for example, for a serial device / UART; [0] should be the Raspberry Pi's UART); prefer ARM, since this is more straightforward. From there, you can work your way up from how data arrives in controller registers, to how the driver handles the interrupt (you'll learn about ISRs and DSRs and how to read a microcontroller datasheet), to how the driver notifies the application program thread waiting on the data (you'll learn about scheduling), to how the read syscall transfers memory from kernel space to userspace. I'd not recommend diving directly into the network driver stack, since this has a lot or intermediary layers that do not further basic understanding[1].

Perhaps you should first try to get familiar with the Linux kernel's way of doing OO in C (if you are unfamiliar with this style; if you have done any modern C programming, it should not be a problem). (Do not start with the platform startup code; this would probably be too much for the start.)

[0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... (maybe a bit too complex, since it uses DMA)

[1] To be fair, the serial I/O layer has the tty layer as intermediary, so it's admittedly only slightly better

Same for me, although I studied computer science. I enjoy to read such nice written articles about technology. Even though most of the text was about stuff I already knew, there still was something new (maybe I just forgot?) for me: retransmission via ACK messages. But even if not, I still appreciate reading about this stuff again to freshen my knowledge. If I don't work on/with these topics regularly, I tend to forget about some of the details.

Linux Inside gitbook

https://www.gitbook.com/book/0xax/linux-insides/details

Check these comics they are mostly about linux and networking: https://jvns.ca/zines/

Depending on how deep you want to go:

https://www.coursera.org/learn/build-a-computer - This is a fantastic no-prerequisites course that has you actually implementing a functional CPU in 6 weeks starting from building basic logic gates out of NAND gates. There's a hands-on project every week to help you solidify your understanding of the lectures. The resources are also all available at their site: http://www.nand2tetris.org/. In case that sounds intimidating, I have no formal CS education either and couldn't implement any of the basic logic gates before I took the course, and I built a CPU by the end so I'm confident others can too. They have a "Part 2" to this course which has you build from the CPU to a functional operating system which would get you an introduction to how kernels work in general, although they recommend some programming experience for that part.

Hacking: The Art of Exploitation - Despite the name, this book is actually an excellent introduction to low-level behavior both on the CPU and on networks (it's split into distinct sections to cover each topic). I would recommend picking this up after the course linked above, because it's somewhat brief with its explanation of CPU architecture. A beginner's course in C programming might also be advisable since this does use some basic C code which might be challenging if you've never been exposed to it before.

Even as a relatively network-savy developer, the 8 to 10 bit translation done over the wire was news to me. I love these kinds of implementation details.

For Linux/Unix, I'm going to recommend a book, which for now is probably too ambitious: "Computer Systems: A Programmer's Perspective" by Bryant and O'Hallaron, a.k.a. "CSAPP".

http://csapp.cs.cmu.edu/3e/perspective.html

This book is targeted at working programmers:

    Most books on systems—computer architecture, compilers,
    operating systems, and networking—are written as if the
    reader were going to design and implement such a system.
    We call this the “builder's persepective.” We believe
    that students should first learn about systems in terms
    of how they affect the behavior and performance of their
    programs—a “programmer's perspective.” 

I'm recommending CSAPP to give you an idea of where the end lies. If you grok its material, you will know more about OS kernels than would be required for any typical front-end or back-end web development job.

After you read a bit on it, you can really learn a lot by opening wireshark and watching what's going on, googling for tutorials and documentation to understand the settings.

As a front end developer there is actually a lot of networking involved making requests to the servers. It's really helpful to have a high level picture of how http works, and what common networking failure modes are, so you can use better abstractions in your code, expect common failures and shown nice error messages or retry requests, test your app's connections using wirshark to make sure there aren't extra round trips slowing it down, etc.

Shameless plug but I cover a lot of lower level network and hardware effects for web developers in this book: https://unop.uk/book/

It's mainly aimed at people interested in ASP.NET Core but there are a lot of general performance tips in there. I have a EEE background and I think understanding things down to the transistor level can really help you write better software.

BTW Gary's WAT video is great fun if you haven't seen it.

I can thoroughly recommend "Internet Routing Architectures 2nd Edition" by Sam Halabi. It's an older text, but much of it is still relevant:

http://amzn.eu/5tCOQfW

It was my goto book when I worked on BGP-4 odds and sods.

For networking in particular, Andrew Tanenbaum's book "Computer Networking" [0] is quite good, and covers everything from the physical layer on up. The most recent edition is from 2010, but much of this doesn't change quickly so it's still quite relevant. I've found it extremely helpful at times.

[0] https://www.goodreads.com/book/show/8515228-computer-network...

I'm pretty surprised that no one has recommended the other articles on the same site. They are pretty excellent: https://www.destroyallsoftware.com/compendium

The screencasts are fantastic as well.

Expending on your correction, there are some appropriate diagrams in this article:

* https://www.allaboutcircuits.com/textbook/digital/chpt-3/log...

Any practical binary logic scheme is going to have an undefined zone in the middle because the gain of the devices used for the logic is not infinite and there would be problems caused if the gain was too high.

Being a blog is a temporary medium change. There are many hours of unix, git, and programming screencasts and a series on computation in those $29. If "per month" part feels too steep, nothing stops you from making it one time thing by downloading everything and cancelling subsequent payments.

https://www.destroyallsoftware.com/blog/2016/state-of-das-de...

$29/month feels alright if you're using it as a professional resource, i.e. you're an employed programmer.

As a student/learning resource, it seems quite steep. Yet, compared to traditional education, it's a screaming steal.

Pricing is hard.

I am out for a few years and haven't done too much with BGP, but iirc it heavily depends on your BGP configuration. BGP is a highly complex routing protocol and you can tweak it to your exact needs. On default it is just like RIP and takes the shortest path, except that RIP counts each router and BGP only counts the outbound routers.

The first thing that a BGP speaking router does is to look up the destination IP address in its table of autonomous system numbers (ASNs). An AS is a group of networks that are all under the control of the same policy maker. If you get your internet connectivity from one ISP, you fit in their AS. If you talk to multiple ISPs, you need to be your own AS (and have routable IP addresses assigned to that AS). Finally, the largest networks may be a confederation of several AS, either as a result of purchases or by deliberate policy.

BGP transmits reachability information by building paths of AS that are neighbors. Then, typically, it selects the shortest path of AS hops. (There are a lot of knobs to twiddle with here, both on the advertising side and on the deciding side.)

BGP doesn't care or know about numbers of router hops, just the number of AS between here and there.

There are lots of "network engineer in a box" products that map out performance and then twiddle knobs on your BGP router to select for best performance (or least cost, if some of your paths are more expensive than others.)

BGP doesn't inherently measure time for hops. The base setup is to use the path with the lowest number of unique Autonomous Systems (AS). But, there are also concepts of weight, where you can influence the chosen path manually. And, there's also "Multi-Exit Discriminator", or MED, where you can pass a metric to a peer on what the best path to a specific AS is.

Even that's an unfair simplification, though. Cisco has a pretty good page that shows how path choices are made: http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-...

There are products, though, that tweak these settings to pick for best performance, or lowest bandwidth cost.

The latter, BGP is simply a path metric. Your question reminded me though that Internap used to sell an appliance called FCP Flow Control Platform that would take the top 10% of destination ASNs from your edge(via Netflow)and run ping probes to them and allow you set the preference via iBGP to prefer routes with the lowest latency. It was nice in that you could route around network "brown outs" upstream. It has since turned into their Miro platform. There was also a similar appliance called Route Science. I was always surprised that there wasn't ever an open source version of something similar. Although you don't hear a lot about these appliances today. I think maybe because of the proliferation of CDN edge networks.

http://www.internap.com/network-services/miro-controller/

So you cannot directly copy their text, I would assume, and republish it since they charge a subscription for access to their articles.

Gary is a connoisseur for pixel-perfect large text that exactly fills the given space:

https://twitter.com/garybernhardt/status/780497807434100736 https://twitter.com/garybernhardt/status/760648828772941824

and

"What I really want to do is tell CSS to make text a certain width, but technology is not yet advanced enough!" https://twitter.com/garybernhardt/status/754036917864247297

I think you might be conflating MTU and frame size - IPv4 MTU (L3) can be up to 64kB, whereas jumbo frames (L2) can be up to the stated 9kB.

Isn't this a freely available promo article?

> This article is part of The Programmer's Compendium. > You can get access to the full Programmer's Compendium by subscribing to Destroy All Software.

If you are subscribed, the footer of the page reads as follows:

You can share this article! This URL can be posted anywhere you like, including in public. Anyone clicking on it can read the article without logging in. The URL is specific to your subscribed account, but no one outside of Destroy All Software can identify your account simply from the URL.

No, it's OK for this to be on HN. I'm doing an experiment with the compendium where the individual articles are publicly linkable, but navigating to one from the index requires a subscription.