11 ms·
Network protocols for anyone who knows a programming language
- airstrike 8y agoSuch an interesting read. Thanks!
- twtw 8y agoOne 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 8y agoYeah, 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 8y agoThe 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 8y agoOddly, nothing has changed in the way God made the universe in the intervening years. Some things are timeless.
- markdog12 8y ago> 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 8y agoKind 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.
- mig39 8y agoIs it also to allow other nodes on the network to communicate, especially if they're on the same collision domain?
- supahfly_remix 8y agoNo. Wired ethernet hasn't used collison-based protocols in a long time. It's point-to-point now, not shared.
- dublin 8y agoActually, even though most connections are switched point-to-point these days, any properly functioning implementation (definitely up through 100Mbps) must still implement CSMA/CD. It's required for proper functioning of Ethernet hubs and some bridges!
- bogomipz 8y ago>"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.
- WrtCdEvrydy 8y agoI love the ending... just goes to show that anything you build may be around for years longer than you expect.
- coreypreston 8y agoThat's a romantic way to look at technical debt! :-P
- jandrese 8y agoIt's not technical debt, it's more like technical ex-girlfriends.
- blattimwind 8y agoThough we actually have 9k jumbo frames, which work quite well for bulk data transfer (over fast links).
- collinmanderson 8y agoI think we'd have http header compression regardless of packet size. Headers usually make up the majority of an http request. It makes sense to compress that.
- canada_dry 8y agoWith 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 8y ago"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 8y agoNot 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...)
- coreypreston 8y agoWhat do you see as an issue in technical writing, if anything past not concise or well written?
- rco8786 8y agoWhat a fantastic article. Thanks!
- teacpde 8y agoAwesome stuff, thanks for sharing (didn't know it's subscription based)
- pests 8y agoThe 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. :)
- robbrit 8y ago> 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.
- nindalf 8y agoI 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
- geezerjay 8y agoGreat stuff. Thanks for sharing that link.
- robpalmer 8y agoThat book is one of the most useful engineering books I have ever read. Top quality theory with practical application.
- EnFinlay 8y agoIt seems every intro to networking goes into the headers of each layer's most common protocol.
- tastroder 8y agoThat's a good thing imho, at least if accompanied by something that gives you the more practical perspective on layers 4 and above as well (which is probably where many curricula fail). Of course it's more interesting to do fun stuff with fancy JSON APIs or create a funky WiFi mesh, it's even likely to be more relevant to most people's future job since not that many people focus on networking. But it's a foundation that can be interesting and help many optimizations down the road, it simply is not academias primary and exclusive focus to prepare students for some job. Just like many people take other stuff from CS programs that you simply don't learn in a 3 month Python course, undertanding of networking protocols is something that _may_ help and give you an advantage for future problem solving. It might even be thought inspiring enough for you to focus on in the first place.
- 8y ago
- commonsense1234 8y agovery well written. thank you!!
- 7373737373 8y agoI'd love to see a similar explanation of the most common routing protocols for programmers.
- Wowfunhappy 8y agoWhy 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.
- starik36 8y agoDon't know about TCP. In the 90s, I hand implemented a data/file transfer protocol over trunking radio - a very data unfriendly medium with pretty bad loss rates. I thought about "I lost a packet" message, but if it got lost in transmission, sender would never know to resend the packet. Instead, the sender had the responsibility of keeping track of which packets it received an ACK for. If it didn't receive the ACK, it would resend the packet within a certain interval and wait for another ACK.
- benjamincburns 8y agoThanks to cumulative windowing, it does have a dropped packet signal: https://en.wikipedia.org/wiki/Transmission_Control_Protocol#Dupack-based_retransmission https://en.wikipedia.org/wiki/Transmission_Control_Protocol#...
- mhandley 8y agoHow 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.
- kevintb 8y agoExcellent article! Love everything published by DAS.
- lpmay 8y agoI 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...
- 9dev 8y agoThe 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 ;)
- kingosticks 8y agoMy 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.