6 ms·
What really helped me understand and troubleshoot network communications at the socket level was the book by W. Richard Stevens[0]. I think this is because he s
by TYPE_FASTER 4y ago
What really helped me understand and troubleshoot network communications at the socket level was the book by W. Richard Stevens[0]. I think this is because he starts with an introduction to TCP, and builds from there. Knowing TCP states and transitions is important to reading packet dumps, and in general debugging networking.
Also, no matter what platform you're using, there is probably a socket implementation somewhere at the core. You're best off understanding how sockets work, then understanding how the platform you're working with uses sockets[1].
Once I read the W. Richard Stevens book, I was able to read and understand RFCs for protocols like HTTP to know how things should work. Then you're better prepared to figure out if a behavior is due to your code, or an implementation of the protocol in your device, or the device on the other end of the network connection, or some intermediary device.
[0] - http://www.kohala.com/start/unpv12e.html http://www.kohala.com/start/unpv12e.html
[1] - https://docs.microsoft.com/en-us/windows/win32/winsock/porting-socket-applications-to-winsock https://docs.microsoft.com/en-us/windows/win32/winsock/porti...
- hinkley 4y agoThere were many authors in that era who had practically compulsory books. Stevens is one of the few to have two. His Unix Programming book was referred to as the Bible.
- sophacles 4y agoI still refer back to APUE often and push my junior folks to read it.
- Agingcoder 4y agoThe Linux programming interface, by Michael Kerrisk, is an excellent modern update.
- lanstin 4y agoWe had to debug an issue with ARP during a deploy of docker containers a year or two ago. A nearly complete understanding of the lower layers is not that much knowledge and quite useful at times.
- 5e92cb50239222b 4y ago"Nearly complete"? No matter how deep your knowledge is, you're only scratching the surface. To pick a small example, there's something like 20 TCP congestion avoidance algorithms alone (many are available in the mainline Linux kernel, and they can be picked depending on the task and network at hand), and I believe it took something like a decade of research, trial and error to solve the bufferbloat problem. https://en.wikipedia.org/wiki/TCP_congestion_control https://en.wikipedia.org/wiki/TCP_congestion_control https://lwn.net/Articles/616241/ https://lwn.net/Articles/616241/
- hn_go_brrrrr 4y agoOnly CUBIC and BBR seem to have any meaningful usage, however: https://www.comp.nus.edu.sg/~ayush/images/sigmetrics2020-gordon.pdf https://www.comp.nus.edu.sg/~ayush/images/sigmetrics2020-gor...
- icedchai 4y agoI tried out BBR on a system that had a ton of packet loss. It made a tremendous difference!
- n_kr 4y ago> No matter how deep your knowledge is, you're only scratching the surface. I understand this is just emphasis, but no, its not magic, its not innate ability, its just software man! If you have dug deep enough, and understood it, that's it. Key phrase is IMO 'understood', but that's universal.
- aflag 4y agoI think the point is that it may be impossible for a single human to have "nearly complete understanding" of how the networking stack work. But maybe what was meant was nearly complete understanding of the fundamentals. That's certainly achievable. But networking in the kernel is a beast of a thing with specialists in small parts of it. But I don't think there's a single human that know nearly all that those specialists know combined.
- Dowwie 4y agofor those unfamiliar with C, if anyone can recommend sufficient reference material to understand the C examples presented in the book, that would be helpful
- throwaway1777 4y agoYou’re opening a can of worms but Kernigan and Ritchie wrote the canonical book on C and you cant go wrong with that.
- quietbritishjim 4y agoIt's with stressing how different the K&R book is from books in the past that introduce a programming language. Usually those sort of books are fairly long and you end up with a decent but incomplete understanding. With K&R, it's quite short, it's an easy going read, and yet when you get to the end you've covered the whole of C (even the standard library!).
- harry8 4y agoLet's be controversial. K&R is lovely, I learned from it, everything good everyone says about it is true and K & R and both beautiful, sexy, clever, kind and wonderous men. If you are learning programming (and who among us isn't?), the code examples stink to high heaven. No really. Don't program like that! K&R didn't! If you're learning programming and C it will teach you a bunch of really bad habits /because/ it is a book for experienced programmers with fully developed taste and the examples were designed to illustrate a particular facet of the language as pithily as possible. It's great for that. I realize any criticism of the sacred texts will result in inspiring revulsion and possibly bile among those who think of such things as above criticism and any commentary is about the shortcomings of the commentator not the holy book but there it is... It's 2022 and I'm old enough to take it. ;-) Alistair Moffat "Programming, Problem Solving and Abstraction" is one I found that seems better to learn C programming. Maybe other people have better recommendations than that..? Separate to that "The C Puzzle Book" is superb when you're learning to really thoroughly understand pointers, arrays and so on. Koenig's "C Traps and Pitfalls" isn't bad for some of the dark corners.
- waynesonfire 4y agocurious whether the book help w/ understanding routing and firewalls?
- tptacek 4y agoVery yes on both, especially with firewalls.
- TYPE_FASTER 4y agoYes. To really understand routing and firewalls, I'd suggest implementing a firewall for yourself using Linux or OpenBSD. I call out OpenBSD because when I went through that process years ago, OpenBSD was lightweight from resource and complexity perspectives, so I could focus on network configuration. There might be better options with Linux these days, it's been a long time since I looked.
- waynesonfire 4y agolike at the kernel level? even if not, seems like a such a great exercise. i guess i'm also interested in routing... any tips on creating a network of computers to experiment with? I guess ideally, you'd have real hardware to assemble, . what's the next best option? VMs? jails w/ vnet?
- TYPE_FASTER 4y agoBack then, I put OpenBSD on a spare P133 with two network adapters to do something like this: https://www.openbsd.org/faq/pf/example1.html https://www.openbsd.org/faq/pf/example1.html VM and/or containers make sense today. I've got an old Mac Pro tower I found on Craigslist in the basement. 64G of RAM for it was less than $150. Since Cisco offers virtual versions of their routers, you can look at what people are doing to build home labs for practicing for Cisco certifications. The homelab subreddit has a lot of interesting examples of peoples' setups as well.
- buzer 4y agoIt depends a bit on what you want to learn exactly. E.g. do you want to just learn about basic routing, BGP, MPLS, certain vendor specific stuff (like Cisco) etc. If you mostly just want to try out what you can archive on Linux you can get quite far with doing things via network namespaces (+whatever software you want to use, e.g. BIRD or Quagga) these days. Large pro on doing things via namespaces is that you can set them up & tear them down a lot quicker compared to VMs or physical hardware & scripting those steps is a lot easier. VMs & physical hardware provide more ways to do things. At least in the past there were various limitations on what you could do emulate with Cisco VMs for example (especially on some more advanced Nexus features).
- gwright 4y agoI had the privilege of working for Rich as a junior developer and then later with him as a co-author. He was my mentor and friend. Seeing messages like this over 30 years later really makes my day and reminds me how much I miss him.
- swellguy 4y agoNot to cause offense, but can you indicate his cause of death? This idle question has been in my mind since 2002 or so when I used his books in graduate school. Was surprised to realize he was already dead back then.
- cantrevealname 4y agoAccording to Wikipedia[1], he died in 1999 at the age of 48, which is so young that I also would like to know what happened. He was apparently healthy and working and just fine a week before his death. But there's a bizarre resistance among some people regarding discussing cause of death. If a President suddenly died, we shouldn't ask about cause of death "out of respect"? I'm a big believer in privacy, but it's silly to not talk about cause of death after someone has passed away. In fact, we should know causes in order to improve all our lives (to be more cautious of heart disease, or suicide, or motorcycle accidents, etc.). [1] https://en.wikipedia.org/wiki/W._Richard_Stevens https://en.wikipedia.org/wiki/W._Richard_Stevens
- bruce511 4y agoSometimes though (and I'm not saying it was in this case) the cause of death is perceived as stigmatising, and so is withheld to protect the person's name, or protect the family. This happened, for example, with Isaac Asimov who died in 1992. He contracted Aids from a blood transfusion [1]. In the 80s and 90s this was sufficiently stigmatising to warrent being kept quiet. Today things like drug overdosing and suicide are sometimes considered shameful,and details are suppressed. Or worse; imagine having to answer that your relative was shot by police while shooting kids in an elementary school... In truth people die of embarrassing things all the time, so in some societies it is impolite to ask. Again, to be clear I am NOT suggesting that there was anything shameful about this death, I'm making a more general point about the nature of reporting cause of death. [1] https://en.wikipedia.org/wiki/Isaac_Asimov https://en.wikipedia.org/wiki/Isaac_Asimov