
Network protocols for anyone who knows a programming language - kalimatas
https://www.destroyallsoftware.com/compendium/network-protocols?share_key=97d3ba4c24d21147
======
nindalf
I took a networking course in college and I didn'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.

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 - [https://hpbn.co](https://hpbn.co)

~~~
mrmuagi
I'd largely echo your sentiment, but luckily our professor had a hands-on
attitude. This involved actually coding things that used those concepts. We
had to implement a non-recursive DNS resolver and a FTP server. Reading the
RFCs and chewing out something that worked (mostly) was real fun.

~~~
audiolion
Same here, we did examine headers and learn about the layers of networking,
but we were also given the link to
[https://www.ietf.org/rfc/rfc1035.txt](https://www.ietf.org/rfc/rfc1035.txt)
and told to implement a DNS resolver in C. We also did a peer-to-peer client.
You learn a lot more by implementing it.

------
canada_dry
With the current state of generally terrible technical writing and my ever
decreasing attention span it's bloody refreshing to read a concise and well
written explanation of a highly technical subject!

I'll definitely have to check out the rest of their 'compendium':
[https://www.destroyallsoftware.com/compendium](https://www.destroyallsoftware.com/compendium)

~~~
specialist
_" current state of generally terrible technical writing"_

I've served the technical writing role a few times.

If it (your product) is hard to describe, you probably did it wrong. At the
very least, keep trying until things make sense. Better mental models,
metaphors, workflows, whatever.

I was once asked (by a school principle, former writing teacher) why software
developers are such terrible writers. I replied that all the good software
developers I know are also good writers. That if you can write an essay, you
can also code. The problem is that most people are terrible writers,
programmers included.

I will admit that writing is harder than programming. Because people are far
more interesting, complicated, nuanced than computers.

Reading someone else's code is the closest thing we have to mind reading. More
so than prose. IMHO.

Miscommunication and ambiguity is the norm. We all just have to accept that
and keep trying.

~~~
dublin
Not only that, the very idea of clear, literate explanations is really a core
part of the entire Internet ethos, heavily influenced by UNIX. (Read
[http://theody.net/elements.html](http://theody.net/elements.html) \- you'll
be glad you did...)

This was revolutionary back in the days when most protocol specs were
proprietary and designed to protect the priesthood (usually of a particular
vendor)rather than facilitate interoperability. It's hard to imagine now, but
one of the big reasons TCP/IP won was that it actually encouraged
interoperability and interworkability. (Jan Stefferud drew a distinction
between those two terms in this context...)

------
twtw
One interesting note re: 8b/10b encoding. The motivation in the article is
accurate, but not the whole story (never is, in the analog world).

Nowadays, 8b/10b (or more realistically 128b/130b) is critical to enable clock
recovery by making sure the signal transitions frequently enough.

> Computers can't count past 1

Reminds me of this excellent quote: "Every idiot can count to one" \- Bob
Widlar

~~~
pjc50
Yeah, that section is a little ropey; the real way to think of high-speed
networking systems is not that they send _levels_ but that they send _edges_.
Levels can drift around all over the place, and in a fast system the level at
one end is not the same as the level at the other.

This line of thinking makes clearer what signal reflections are and why they
are a problem, and what the role of eye diagrams is.

~~~
vvanders
The Art of Electronics[1] has a _fantastic_ section on differential signaling
and common mode voltage. That book is a treasure even today despite being
published initially in 1980.

[1]
[https://en.wikipedia.org/wiki/The_Art_of_Electronics](https://en.wikipedia.org/wiki/The_Art_of_Electronics)

~~~
dublin
Oddly, nothing has changed in the way God made the universe in the intervening
years. Some things are timeless.

------
pests
The slow start mentioned in the transmission control section has an
interesting history.

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.

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.

The inventor of that algorithm posts here frequently if he wants to comment on
my post about this again. :)

~~~
swinglock
[https://en.m.wikipedia.org/wiki/Nagle%27s_algorithm](https://en.m.wikipedia.org/wiki/Nagle%27s_algorithm)

~~~
teacpde
It is awesome that two of the wiki references are the author's comments here
on HN.

------
robbrit
> HTTP/2 has header compression because of the RAM limitations of networking
> devices in the late 1970s.

And this is why engineering is interesting. Your design choices can have lots
of unintended side effects.

------
markdog12
> 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.

~~~
supahfly_remix
Kind of! They allow systems with slightly different clock rates to adjust. A
system sending data nominally at 10 Gb/s can actually run slightly faster to a
system running slightly slower b/c their timing bases (crystals) oscillate at
slight different frequencies.

~~~
bogomipz
>"They allow systems with slightly different clock rates to adjust."

Adjust to what? Ethernet is not synchronous its asynchronous. There is no
shared clock.

The interframe gap goes back to the days of CSMA/CD. The interframe gap was
the period during which end stations would contend for the shared medium.
Without this an end station could continuously stream and monopolize the
network.

~~~
dublin
Back when I worked at Chevron in the early 90s, I noticed that new SGI
workstations were _way_ faster NFS servers than anything else, even the Suns.
It took me a bit in those days (Ethernet network analyzers were over $50K
then, so hard to borrow even in a big, rich company) to figure out why:

It took 6 Ethernet frames to send a single 8K NFS block, and regaining the
carrier could be pretty time-consuming if there was other traffic. So SGI
implemented a really elegant cheat that technically violated the Ethernet
standards, but dramatically improved performance for the entire network, and
especially their NFS servers: They simply never let anyone else get a chance
to talk until they'd sent the entire block, "hogging" the carrier by going
straight from the last bit of the previous frame to the preamble of the next
one. It was a very clever way of more-or-less getting jumbo frames years
before they became part of the standard!

~~~
bogomipz
Interesting. I knew someone that worked for an ISP in 90's who had an odd SGI
workstation amongst their standard SUN boxes for hosting customer sites. The
SGI box was regarded to be faster than the newer SUN boxes. Eventually all
customers were migrated off of the SGI box except one customer who refused and
threatened to sue. I wonder if the reason for the performance gains of the SGI
were the same as yours.

I believe 802.11n reduced the interframe gap down to a two microseconds for
transmissions to the same receiver.

------
9dev
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
_still_ can't switch from MySQL to Postgres by simply swapping the driver.
Compare that to transmitting TCP over avian carriers ;)

------
lpmay
I love this article, but I just can't help but pick at this nit I have with
the "charging the capacitors" part. I'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's capacitance :-) ), holding the capacitors at any fixed voltage for
any length of time does not change how "charged up" it is at all. I would
believe that there is a "line balancing" goal to the transmissions, but I'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...

------
kingosticks
My nitpick would be the example Cisco router:

> 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's
> 13,333,333,333 packets per second in a single 19 inch rack!

The ASR 9922 is 20 slots of 3.2Tbps per slot. That's a 64Tbps chassis so
that's 5,333,333,333 packets per second in a single 19 inch rack. Cisco's
160Tbps number is their hypothetical multi-chasis setup. Which is fun to
market but non-sensical to build/purchase.

------
7373737373
I'd love to see a similar explanation of the most common routing protocols for
programmers.

------
Wowfunhappy
Why doesn't TCP have an "I lost a packet" message? Is it just that no one
thought of it until too late? Hacking around the problem by sending multiple
ACK's sounds inefficient.

~~~
mhandley
How would the receiver know a packet was lost? If only one packet was sent, it
cannot know, so you always need a retransmit timer at the sender as the
ultimate backstop for reliability. Any other trigger of retransmissions is an
optimization.

Now, why not a NACK rather than relying on duplicate ACKs? First, the NACK can
get lost, so you'd probably want to trigger fast retransmit off of duplicate
ACKs anyway for efficiency. But when should the receiver send a NACK? Given
that packets can be reordered, likely you want to wait for a few subsequent
packets to arrive before you send the NACK. In that time, you've been acking
the arriving packets. So your NACK will arrive just after the sender has
concluded the packet was lost from the arriving duplicate ACKs. At this point
the NACK is serving no purpose.

Even if you wanted to change TCP and assume no packets were reordered, so send
a NACK as soon as the packet after the missing one arrives, you'd still be
ACKing the arriving packet (which due to TCP's cumulative ACK appears to the
sender as a duplicate ACK). The sender could just as well retransmit after one
duplicate ACK and get he same behaviour. In the end, sending a NACK doesn't
really add anything.

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

~~~
coreypreston
That's a romantic way to look at technical debt! :-P

~~~
jandrese
It's not technical debt, it's more like technical ex-girlfriends.

------
teacpde
Awesome stuff, thanks for sharing (didn't know it's subscription based)

------
kevintb
Excellent article! Love everything published by DAS.

------
airstrike
Such an interesting read. Thanks!

------
commonsense1234
very well written. thank you!!

------
rco8786
What a fantastic article. Thanks!

