While so, so, so much of this is rarely the network, knowing how to look under the covers and see what's actually hitting the wire (versus what the API call asked for) leads to far, far faster resolution of problems.
It's frustrating to me that so many people see this as a mystery of "knowing networking" when it's really just basic protocol analysis.
That's fine. But every developer should have a basic understanding of networking. But that can also be dangerous.
I still have people in the company who swear you can't have more than 65k incoming connections to a machine, because "that's how many ports there are". Don't get me started on all the misconceptions on TCP_TW_REUSE AND TCP_TW_RECYCLE. Lengthy discussions because apparently "TIME_WAIT is bad and uses up ports! "(see also, 65k). For context, these are servers, with multiple clients, from different source IPs.
If you're going to read it, though, find a used copy of the original Stevens' first edition, not that terrible desecrated second edition.
This is one of the best written textbooks, if not the best, I have ever read.
* An Engineering Approach to Computer Networking: ATM Networks, the Internet, and the Telephone Network by S.Keshav
* TCP/IP Illustrated Vol -I by Richard Stevens (any edition will do).
* Effective TCP/IP programming by Jon Snader.