
Network Protocols - signa11
https://www.destroyallsoftware.com/compendium/network-protocols/97d3ba4c24d21147
======
djrogers
Evan as a 20+ year network engineer, I don't think I've run across an article
about networking that balances depth and breadth so well. All of the
information presented is high-level enough to retain (at least as a big
picture), but detailed enough to avoid hand-wavy 'magic networks'
descriptions.

Bravo - well done.

Edit - Also worth adding that this article is a rarity in that the details are
actually accurate! Even things I read in networking books and trades often
have egregious errors - usually due to the breadth of the topic matter.

~~~
catern
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.

~~~
djrogers
To call this "inaccurate" because it's missing out on what is mostly an
unnecessary detail is going way too far.

BGP is _the_ routing protocol on the internet, and it's a fairly common one to
see inside enterprise networks as well - iBGP is for routing inside an AS.
Describing OSPF, IS-IS, etc would have just made things a little more
complicated without adding anything.

~~~
catern
Maybe I don't understand the realities of networking as well as I though. But
my understand was that once packets enter my ISP's network, on my home
connection, the rest of the way they get routed to me with protocols other
than BGP. That's quite a lot of routing being done with non-BGP protocols.

~~~
dsr_
Between major networks, BGP.

Inside the major network to your cable headend or similar: OSPF or IS-IS or
something else - in the largest ISPs, a combination of iBGP to get things to
right area and then OSPF, IS-IS or EIGRP in medium areas.

Inside your house: almost always static routes, no protocol for exchanging
reachability info.

------
have_faith
As a front-end web developer with no formal computer science background or
traditional programming experience I find these kinds of articles extremely
valuable. I like to understand as much as possible, at least conceptually,
what happens throughout the stack even if I don't touch it. Does anyone have
any links to anything similar? perhaps for the Linux kernel or other lower
level systems but with a top down overview like this? Especially anything that
would build on this article. Effects and unexpected phenomena that manifest in
networks like this also would be interesting.

~~~
rectang
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](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.

~~~
arawde
This was the textbook for my intermediate operating systems class, and I'd
second this recommendation.

~~~
closeparen
This was the textbook for my first-year intro to systems and I'd recommend it
too!

------
manigandham
I always recommend the _High Performance Browser Networking_ book by Ilya
Grigorik for a fantastic overview of modern web protocols. It's also free to
read online.

[https://hpbn.co/](https://hpbn.co/)

------
devy
By the way, this is Gary Bernhardt's personal site. His lightning talk
"Wat"[1] from CodeMash 2012 was one of my all time favorite talks, witty and
right on!

[1]
[https://www.destroyallsoftware.com/talks/wat](https://www.destroyallsoftware.com/talks/wat)

------
andars
> In reality, our 5-volt CMOS system will consider anything above 1.67 volts
> to be a 1, and anything below 1.67 to be 0.

Worth noting that the region from 1.67 V to 3.33 V is undefined and systems in
practice will not behave nicely for signals in this range. A CMOS logic 1
needs to be above 2/3 Vdd to be reliably recognized.

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

* [https://www.allaboutcircuits.com/textbook/digital/chpt-3/log...](https://www.allaboutcircuits.com/textbook/digital/chpt-3/logic-signal-voltage-levels/)

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.

------
pololee
Very good reading. I'd also recommend Van Jacobson's talk
[https://www.youtube.com/watch?v=gqGEMQveoqg](https://www.youtube.com/watch?v=gqGEMQveoqg)
You'll learn some good stories about internet history.

He has done a lot of work on TCP congestion control, especially the fast
retransmission idea by using duplicate ACKs.

There is an interesting thing about TCP. A lot of popular TCP implementation
use city names, e.g. TCP Reno, TCP Vegas, TCP Westwood.

TCP Westwood is a very interesting implementation. It has very intelligent way
to estimate bandwidth, (not just based on duplicate ACKs). You may find this
paper very interesting. [http://netlab.cs.ucla.edu/internal/wiki-
internal/files/rohit...](http://netlab.cs.ucla.edu/internal/wiki-
internal/files/rohit2004sigcomm.pdf)

------
dronemallone
This article is missing quite a few things that's of interest to programmers:

1\. IPv4 fragmentation & reassembly

2\. Centralized (Dijkstra/OSPF) vs. Distributed routing (distance vector/RIP)
- stuff you see in Algorithms class

3\. TCP mechanisms: congestion control mechanisms that the user can configure
(Cubic/westwood/new reno), flow control, retransmission timer calculation
(exponential weighted moving average)

4\. explicit congestion notification and other add-ons, which can be enabled
in the OS by the user

5\. Active Queue Management and enabling QoS on your system: stochastic fair
queueing for example

6\. the recently introduced TCP Fast Open mechanism

7\. TCP auto tuning:
[http://kb.pert.geant.net/PERTKB/TCPBufferAutoTuning](http://kb.pert.geant.net/PERTKB/TCPBufferAutoTuning)

8\. Ethernet physical layer: you've left out modulation, and only discussed
encoding

9\. Multicast and spanning tree protocols

------
bogomipz
His articles are always fantastic. I wish he would consider publishing a book
however as $29/month to subscribe to a blog feels a bit steep.

~~~
elmigranto
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...](https://www.destroyallsoftware.com/blog/2016/state-of-das-
december-2016)

~~~
bogomipz
Oh that's interesting. Thanks for the link. The live streaming idea is
certainly exciting and compelling. Cheers.

------
Alex3917
So does BGP consider the amount of time it takes to traverse each hop, or are
routing tables built only based on the minimum number of hops it takes to
reach each destination?

~~~
IamMario
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.

~~~
bogomipz
>" BGP is a highly complex routing protocol and you can tweak it to your exact
needs."

BGP itself is actually a relatively simple protocol. The complexity really
comes from all the available configuration options.

------
iajr39r4
A bit off topic but, I noticed most of the titles on destroyallsoftware are
rendered as SVGs.

Why is that a better idea than just normal text?

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

~~~
tyingq
It's just the main headline title and subtitle. The actual article text and
subheaders are regular html.

So I would guess it's a just a personal preference for that typography that
they felt they couldn't get some other way.

The svg images do have correct alt tags with the right text.

~~~
steveklabnik
I believe that you're accurate; Gary cares a _lot_ about presentation, I
vaguely remember seeing him tweet about the kerning here or something.

------
Ericson2314
It's good, but... I wish it were more critical? Excluding the gross control
plain (as it wasn't the focus), there's some awkward overlap between IP and
Ethernet (link aspects).

My guess, that I'd love to see explicitly confirmed, is that it goes back to
the internet as the internetwork—lingua franca between existing networks an
idea predating the more technically-motivated concept of layed protocols
providing compounding abstractions.

I don't want to sound like a nit of an otherwise great piece, but without
criticism the history seems inevitable. Alternatives and hypotheticals are
good to keep design space from atrophing in the face of collective amnesia.

------
tyingq
I assume it's not mentioned to keep the article brief, but most devices these
days support MTU sizes greater than 1500 bytes. Jumbo Frames[1] allow for
ethernet packets of up to 9216 bytes.

Since they have to be fragmented back down to 1500 for devices that don't
support them, however, it's typically only used in closed internal networks,
like a SAN. People typically see about a 5% to 10% bump in performance.

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

~~~
packetized
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.

~~~
tyingq
Well yes, but they are closely related. You set the MTU/MRU to take advantage
of the availability of larger frames. There isn't some separate adjustment on
Linux, for example.

------
Myrmornis
This is great. Along similar lines, "Foundations of Network Programming" by
Brandon Rhodes (and originally John Goerzen) is fantastic (and not just for
python programmers as the python API is a pretty transparent wrapper over
POSIX APIs).

------
lttlrck
Alternative explanation of the 1500 byte MTU given in the last paragraph:

[https://networkengineering.stackexchange.com/a/2964](https://networkengineering.stackexchange.com/a/2964)

------
notdonspaulding
I love Gary Bernhardt's stuff.

I love this article because of the depth and detail which can be expected of
his work, but also because you get all the way to the last sentence before he
reveals the question which inspired him to do the deep dive.

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

------
RubenSandwich
I hate to be that guy. But I don't think this link was meant to be for the
general public. Gary Bernhardt, the author of this piece, posted this link to
this Twitter followers about 2 weeks ago to receive feedback. Remove the hash
at the end of the URL, '/97d3ba4c24d21147', and you'll see you'll be
redirected to purchase a subscription to Gary's screencasts and articles.

So if you are enjoying this article consider purchasing a subscription and
supporting more work like this.

~~~
frant-hartm
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.

~~~
RubenSandwich
Good point, I didn't notice that on the bottom. But I think my argument still
stands that a link posted to his Twitter followers is a lot different then it
posted for all of HN.

~~~
TeMPOraL
I disagree. Twitter is a broadcast medium. That's unlike e.g. Facebook, when
by default you target a specific audience (your Facebook friends).

