[HN Gopher] Entire Linux Network stack diagram (2024)
___________________________________________________________________
Entire Linux Network stack diagram (2024)
Author : hhutw
Score : 543 points
Date : 2025-10-20 03:33 UTC (19 hours ago)
(HTM) web link (zenodo.org)
(TXT) w3m dump (zenodo.org)
| ee99ee wrote:
| wow
| colordrops wrote:
| I'm surprised to realize I'm familiar with most of the stack just
| from decades of Linux usage and no formal study of the stack.
| elevation wrote:
| This place needs more of this kind of documentation.
|
| I failed to use IP tables for years. I bought books. I copied
| recipes from blog posts. Nothing made sense, everything I did was
| brittle. Until I finally found a schematic showing the flowchart
| of a packet through the kernel, which gives the exact order that
| each rule chain is applied, and where some of the sysctl values
| are enforced. All of a sudden, I could write rules that did
| exactly what I wanted, or intelligently choose between rules that
| have equivalent behaviors in isolation but which could have
| different performance implications.
|
| After studying the schematic, every would just work on the first
| try. A good schematic makes a world of difference!
| HotGarbage wrote:
| Was it this one?
| https://en.wikipedia.org/wiki/File%3aNetfilter-packet-flow.s...
| suprjami wrote:
| One of my favourite webpages. Have used it countless times
| over the years.
| UltraSane wrote:
| I use this all the time when writing iptable rules.
| immibis wrote:
| This also isn't complete because it doesn't show code between
| or around the various tables. I used to think of iptables as
| dumb filters that manipulate raw packets before/after the
| rest of the kernel sees them, but this view is wrong, and
| doesn't explain, for example, how it does NAT.
|
| And the answer is it doesn't do NAT. The code is already
| preparing to do NAT, and that code merely consults the table
| to find out what kind of NAT it should do. The diagram makes
| it look like you can just move a NAT rule to a filter or
| mangle rule because the kernel just applies these tables in
| sequence anyway, but you can't because they are consulted by
| different blocks of code for different purposes.
| Koffiepoeder wrote:
| Can you share the diagram? Would love to become iptables-
| enlightened.
| elevation wrote:
| Eventually I used more detailed diagrams, but this one was
| like a lightbulb going off:
|
| https://www.frozentux.net/iptables-
| tutorial/images/tables_tr...
|
| I couldn't find one that annotated where sysctl configurable
| were shown. But this is a useful annotation, even if it's an
| exercise for the reader.
| eptcyka wrote:
| It is time to be nftables enlightened instead.
| VTimofeenko wrote:
| Similar diagram, right in nftables wiki:
|
| https://wiki.nftables.org/wiki-
| nftables/index.php/Netfilter_...
| Arch-TK wrote:
| It's more of a netfilter (the thing behind iptables and
| nftables) diagram rather than just iptables.
|
| If you know how iptables maps to that diagram you are very
| likely to be able to quickly understand how nftables does
| too.
| eptcyka wrote:
| Sure, but we really shouldn't be encouraging the use of
| iptables in 2025.
| mmh0000 wrote:
| That's not realalistic for most of the Linux world.
|
| Soooo many systems are still using iptables even though
| we "should" be using nft everywhere.
|
| If you're going to be a Linux Sys/Net Admin today, you
| need an understanding of both systems.
| eptcyka wrote:
| If someone doesn't know iptables, they probably are not
| required to know it. You wouldn't recommend people to
| learn C++03, would you?
| jcynix wrote:
| Besides the diagram you'll find tutorials on
| https://www.frozentux.net/category/linux/iptables/ too.
|
| And at http://www.easyfwgen.morizot.net/ there's an old, but
| still useful generator for an iptables setup. That should
| help to understand iptables.
| PunchyHamster wrote:
| It is also worth mentioning TRACE target that will dump to logs
| which exact rule the packet hit, it's invaluable big firewalls.
| waynesonfire wrote:
| > I failed to use IP tables for years.
|
| Me too, then I discovered FreeBSD and pf tables. I _feel_ like
| an expert network engineer now. It took time and effort of
| course, but the learning process "clicked" for me all along the
| way and I was able to build on my understandings. Give it a
| try!
|
| https://docs.freebsd.org/en/books/handbook/firewalls/
|
| There was a recent book published on the tool, The Book of PF,
| 4th Edition
| jruohonen wrote:
| That's pretty cool!
|
| If someone could program a visualization tool that would generate
| such diagrams automatically, that would be even cooler (but
| likely a mission impossible).
| alhirzel wrote:
| Automatic generation would be really tough because of all the
| levels of abstraction traversed in this diagram in
| particular... But tools like Mermaid / PlantUML can get you in
| the ballpark, and PGF/TikZ could be a reasonable target if you
| want to attack that mission by generating text instead of
| images.
| hhutw wrote:
| For anyone who is interested, the author of this diagram also
| made a Linux disk I/O diagram
| (https://zenodo.org/records/15234151). These diagrams are from
| his book Operativni sustavi i racunalne mreze - Linux u primjeni
| (https://zenodo.org/records/17371946)
|
| Shout out to the brilliant and generous work of the author!
| N-Krause wrote:
| Do you know if there is a English version of the book?
| hhutw wrote:
| To my knowledge, sadly I can't find an English version of it.
| I'm too wishing for a future English version so that I can
| read it. But I guess it will be a lot of work to translate it
| into English.
| alfanick wrote:
| If the author agrees, I could try to learn Serbo-Croatian
| (I'm Polish, good with languages) and translate it to
| English. I'm kinda a burnout Linux geek, who cannot look at
| computers much more. Translating a book would be fun, but I
| would need some sponsoring. Amadeusz at [the old name of
| icloud].com
| dudek1337 wrote:
| the book is licenced under CC BY-SA so you should be OK
| with translating as long as you follow the licence terms.
|
| you could try do a first pass in an AI model to translate
| and then proof-read it for quicker translation. good luck,
| it would be fun and potentially impactful ;)
| fragmede wrote:
| You may want to find an email provider that has a better
| spam filter if you want people to actually contact you.
| stuxnet79 wrote:
| The Disk I/O diagram is excellent, thank you for sharing.
| roomey wrote:
| I'm not sure if this takes into account para-virtualized networks
| on VMs, ie. VMware vm's with "virtual" hardware access
|
| It's been a few years for me tho, so perhaps it's covered with
| the VM section.
|
| Lovely diagram, thanks for sharing it!
| SSLy wrote:
| These usually attach in the bridge or NAT flow.
| billfruit wrote:
| Is it possible we see the diagram as an svg? I am seeing it only
| as embedded in the pdf, and really difficult to read .
| makkes wrote:
| Click on "Download" below the embedded PDF viewer and you'll
| get the PDF.
| rfmoz wrote:
| Linux Kernel map is an other good one
| https://commons.wikimedia.org/wiki/File:Linux_kernel_map.png
| snvzz wrote:
| Fools admire complexity.
| 9dev wrote:
| There's complication, and there's complexity. Fools admire
| complication, engineers design solutions to complex problems.
| This is a diagram explaining the latter.
| KronisLV wrote:
| I think it was put pretty well by describing things as
| accidental complexity (of which you want as little as
| possible) and essential complexity, which is inherent to the
| problem domain that you're working with and which there is no
| way around for.
|
| The same thing could sometimes fall into different categories
| as well - like going for a microservices architecture when
| you need to serve about 10'000 clients in total vs at some
| point actually needing to serve a lot of concurrent requests
| at any given time.
| matu3ba wrote:
| > inherent to the problem domain that you're working with
| and which there is no way around for
|
| I'd phrase it to reasonable taken trade-offs for
| customer/user support and/or selling products.
|
| > going for a microservices architecture when you need to
| serve about 10'000 clients
|
| So far I am only aware of the use case to ship/release fast
| at cost of technical debt (non-synchronized master) of
| microservices. As I understand it, this is to a large
| degree due to git shortcomings and no more
| efficient/scalable replacement solution being in sight. Or
| can you explain further use cases with technical necessity?
| KronisLV wrote:
| 1. When you have a system where each component has
| significant complexity, to the point where if it was a
| monolith you'd have a 1M SLoC codebase that would be slow
| to work with - slow to compile, slow to deploy, slow to
| launch and would eat a lot of resources. At that point
| chances are that the business domain is so large that
| splitting up into smaller pieces wouldn't be out of the
| question.
|
| 2. Sometimes when you have vastly different workloads,
| like a bunch of parts of the system (maybe even the
| majority) that is just a CRUD and a small part that needs
| to deal with message queues, or digitally sign documents,
| or generate reports or do any PDF/Word/Excel/whatever
| processing. You could do this with a modular monolith but
| sometimes it's better to keep the dependencies of your
| project clean, especially in the case of subpar libraries
| that you have to use, so you at least can put all of the
| bullshit in one place. Also applies in cases where the
| load/stability of that one eccentric part is under
| question.
|
| 3. The tech stack might also differ a whole bunch of some
| of those use cases, for example if you need to process
| all sorts of binary data formats (e.g. satellite data) or
| do specific kinds of number crunching, or interact with
| LLMs, a lot of the time Python will be a really good
| solution for this, while that's not what you might be
| using in your stack throughout. So you might pick the
| right tool for the job and keep it as a separate service.
|
| 4. The good old org chart, sometimes you'll just have
| different teams with different approaches and will be
| working on different parts of the business domain - you
| already said that, but Conway's law is very much a thing
| that'd be silly to fight against all that much, because
| then you'd end up with an awkward monorepo, the tooling
| to make working which easy might just not be available to
| you.
| yjftsjthsd-h wrote:
| Where/how would you simplify it without losing features?
| mixedbit wrote:
| For containers you will also have own TCP/IP stack similarly to
| what is shown for VM on the diagram, this is done when a
| container uses slirp4netns to provide networking. An alternative
| is to use kernel TCP/IP stack, this is done when pasta is used
| for networking, diagram on this page shows the
| details:https://passt.top/passt/about/.
| RossBencina wrote:
| Any recommendations for a map of Linux user-space network
| management options?
| nolist_policy wrote:
| qdisc is too small in this diagram and to easy to miss.
| alhirzel wrote:
| s/Aplication/Application/g
| phrotoma wrote:
| Anyone figure out what the colour scheme means?
| PunchyHamster wrote:
| *simplified.
|
| Doesn't even go into iptables/nftables
| ainiriand wrote:
| If you look closely to iptables, iptables looks back at you.
| rolandog wrote:
| Thanks Hrvoje Horvat for such a detailed diagram! It'll help me
| learn the Network stack much, much easier.
|
| His book "Operativni sustavi i racunalne mreze - Linux u
| primjeni" [0] (Operating systems and computer networks - Linux in
| use) may well make learning Croatian worth it! Congrats on
| publishing, and thanks for such an invaluable contribution!
|
| [0]: https://zenodo.org/records/17371946
___________________________________________________________________
(page generated 2025-10-20 23:01 UTC)