Hacker News Reader

Comment by tootie | Hacker News Reader

Networking is probably not what you're looking for. You are probably more interested in DevOps and architecture. Topics like DNS and edge caching. Reverse proxies are typically web servers (ie nginx) or cloud services like API Gateways. Things like TCP are rarely relevant unless you're doing serious micro optimization.

View on HN

IDK about OP but this is exactly what I'm looking for. Do you have some good books/courses for the same?

I was also interested in this, instead of all the TCP/IP resources mentioned here. You may find the Interconnect section of this book helpful: https://pragprog.com/titles/mnee2/release-it-second-edition/

It covers:

- DNS

- Load Balancing

- Demand Control

- Network Routing

- Discovering Services

- Migratory Virtual IP Addresses

I've never been much for following courses and really the best way to learn is practice. Working with a cloud stack like AWS is a great start. Try to setup a an app server behind a load balancer, CDN (Cloudfront) and DNS (Route53). Read up on VPCs, what a CIDR block denotes. The core functions of these kinds of appliances is actually really simple. Just routing, caching and occasionally transforming requests. The ins and outs of specific products (ie CloudFront vs Cloudflare) is going to most useful and you get that from reading product docs. That and learning to use command-line tools like curl, dig and maybe tracert if you're feeling fancy.

On the contrary, I’d say the details of TCP/IP are inseparable from the design, implementation, and practical understanding/configuration of these elements.

I disagree. I learned the structure of TCP frame in college and that's the last time I've looked at one. 99% of my job is at layer 7. Understanding bits like TLS handshake and http headers is plenty.

And now you’re here handing out authoritative and contextual advice on what to study. Like it or not, you’re still using what you learned. A merely superficial awareness wouldn’t suffice.

The whole point of the internet stack is to abstract away the details of the lower layers.

A web developer does not need to know TCP. They need to know HTTP. Even if they did know stuff about lower level networking the browser completely locks you out of that level.

The abstractions are super leaky. Infrastructure fundamentals are consequently significant in all applications. Failure or refusal to understand and inwardly digest this leads inexorably to bad software, or more precisely, bad systems. Web developers that do not know TCP/IP and do not wish to are a consequent burden to everyone else; a fountain of horrors arises, from latency issues to security blunders, when mechanical sympathy is disregarded.

I still disagree. As a web dev, there is absolutely nothing you can do to affect the networking stack. This is all completely buried in web servers and the like. Most CDNs are complete SaaS tools where you can't anything beyond the highest-level. Everything devs do to optimize performance is at the application layer. You can observe things like latency or number of connections and change your code or infra, but you're absolutely never going to inspect a packet. Unless you're actually developing those web servers.

I have countless times inspected packets on the wire when writing web applications, and there is tons we do to ensure service behaviour aligns with the networking stack.

I have also inspected traffic when investigating/writing patches for server code or the kernel, but that’s a completely separate matter.

What’s more, most nontrivial application code causes additional network activity, from DNS queries to database connections, calls to external APIs et cetera. The all-the-world-is-HTTP fallacy is how wheels get reinvented, but badly, as with websockets or JWTs.

Reply on news.ycombinator.com