Network protocols for anyone who knows a programming language

I took a networking course in college and I didn&#x27;t learn much, if anything. We used textbooks like Kurose and Ross that went deep into details like the header format of each packet of each layer. Ultimately, these were useless details that had no place in a textbook. It made me hate the subject.<p>I eventually learned the subject properly through High Performance Browser Networking. This is the one book I would recommend to any software developer. Available for free here - <a href="https:&#x2F;&#x2F;hpbn.co" rel="nofollow">https:&#x2F;&#x2F;hpbn.co</a>

With the current state of generally terrible technical writing and my ever decreasing attention span it&#x27;s bloody refreshing to read a concise and well written explanation of a highly technical subject!<p>I&#x27;ll definitely have to check out the rest of their &#x27;compendium&#x27;: <a href="https:&#x2F;&#x2F;www.destroyallsoftware.com&#x2F;compendium" rel="nofollow">https:&#x2F;&#x2F;www.destroyallsoftware.com&#x2F;compendium</a>

One interesting note re: 8b&#x2F;10b encoding. The motivation in the article is accurate, but not the whole story (never is, in the analog world).<p>Nowadays, 8b&#x2F;10b (or more realistically 128b&#x2F;130b) is critical to enable clock recovery by making sure the signal transitions frequently enough.<p>&gt; Computers can&#x27;t count past 1<p>Reminds me of this excellent quote: &quot;Every idiot can count to one&quot; - Bob Widlar

The slow start mentioned in the transmission control section has an interesting history.<p>Back when most internet packets were single characters representing keystrokes over something like Telnet, an algorithm was invented to wait a moment before sending ACKs in order to possobily piggy back out on the next data packet.<p>This ended up interplaying with TCP slow start and adaptaive congestion control for years and was only resolved in the early 2000s if if I recall correctly.<p>The inventor of that algorithm posts here frequently if he wants to comment on my post about this again. :)

&gt; HTTP&#x2F;2 has header compression because of the RAM limitations of networking devices in the late 1970s.<p>And this is why engineering is interesting. Your design choices can have lots of unintended side effects.

&gt; An interpacket gap of 96 bits (12 bytes) where the line is left idle. Presumably, this is to let the devices rest because they are tired.

The network stack is one of the most beautiful inventions in the whole tech space to me. All the involved layers nest so neatly, allowing to switch out any of them as necessary and simply unwrap at the receiving end. After years of witnessing programmers inventing new dependency injection schemes, I <i>still</i> can&#x27;t switch from MySQL to Postgres by simply swapping the driver. Compare that to transmitting TCP over avian carriers ;)

I love this article, but I just can&#x27;t help but pick at this nit I have with the &quot;charging the capacitors&quot; part. I&#x27;m not intimately familiar with Ethernet specifically, but I am an electrical engineer. Since the voltage on a capacitor is directly related to the charge it has stored ( scaled by a factor called it&#x27;s capacitance :-) ), holding the capacitors at any fixed voltage for any length of time does not change how &quot;charged up&quot; it is at all. I would believe that there is a &quot;line balancing&quot; goal to the transmissions, but I&#x27;d be willing to bet it is to avoid driving the isolation transformers into saturation, and has nothing to do with low pass filter capacitors...

My nitpick would be the example Cisco router:<p>&gt; As an example, Cisco ASR 9922 routers have a maximum capacity of 160 terabits per second. Assuming full 1,500 byte packets (12,000 bits), that&#x27;s 13,333,333,333 packets per second in a single 19 inch rack!<p>The ASR 9922 is 20 slots of 3.2Tbps per slot. That&#x27;s a 64Tbps chassis so that&#x27;s 5,333,333,333 packets per second in a single 19 inch rack. Cisco&#x27;s 160Tbps number is their hypothetical multi-chasis setup. Which is fun to market but non-sensical to build&#x2F;purchase.

I&#x27;d love to see a similar explanation of the most common routing protocols for programmers.

Why doesn&#x27;t TCP have an &quot;I lost a packet&quot; message? Is it just that no one thought of it until too late? Hacking around the problem by sending multiple ACK&#x27;s sounds inefficient.

I love the ending... just goes to show that anything you build may be around for years longer than you expect.

Awesome stuff, thanks for sharing (didn&#x27;t know it&#x27;s subscription based)

Excellent article! Love everything published by DAS.

Such an interesting read. Thanks!

very well written. thank you!!

What a fantastic article. Thanks!