I wrote a web server for CP/M, the issue there was that the C library could only hold the state of a small number of FILE* at a time, because they were allocated statically.
In the DOS days, dynamic memory allocation was to be avoided if possible. Machines did not handle running out of memory gracefully. Often we'd unnecessarily fix the size of things to avoid run-time uncertainty.
A scientific Fortran code I once saw allocated all of the memory it would need at the beginning of the code in an array called 'a'. Then from there it would dole out portions to other parts of the program using common blocks.
But I'm not sure if accepted sockets fall into this category.
For the HTTP server in this article, no. It contains an embedded TCP/IP stack (linked into the HTTP server executable), which expects to talk to a network card driver TSR using the "Packet Driver" API (normally INT 0x60, but the interrupt to use is configurable). Network connections completely bypass the files subsystem in the DOS kernel
Nowadays, the vast majority of people doing TCP/IP on DOS [0] use Packet Driver, and what I just said is true for anyone using that. However, historically there were a huge array of DOS TCP/IP stacks, all implemented differently. It would be (somewhat surprising) news to me if any of them represented individual network connections as files in the DOS kernel, but not having looked at them all, I can't confidently say.
[0] which is almost all hobbyist/retrocomputing: I'm sure there are a few embedded systems running DOS surviving, but most of those likely don't do networking, and many of the few that do may be running something other than TCP/IP, so any remaining production TCP/IP use under DOS is likely quite rare
I have a blog post: https://incoherency.co.uk/blog/stories/rc2014-web-server.htm...
And a github repo: https://github.com/jes/cpmhttpd