如果您不调用recv，则TCP / IP堆栈中的缓冲区在哪里？

Question

Say I have a server that listen's on Port X.

Several client's are connected to the server and send data via the send command.

What happens if the server does NOT have a recv routine to "flush" the buffer?

Does the buffer reside in your own process or in Windows?

Is it also possible to "DDos" still?

Answer 1

What happens if the server does NOT have a recv routine to "flush" the buffer?

The receive buffer that corresponds to this socket will fill up. When that has happened, UDP will silently discard incoming datagrams. TCP will discard incoming datagrams and not acknowledge them, triggering congestion control (halving the window size under Reno/XP or switching to the delay-window under CompoundTCP/Vista+).
When you remove some data from the buffer, UDP will resume accepting datagrams as if nothing had happened (it's your problem to figure out that you lost data!), and TCP will continue accepting and acknowledging packets, gradually increasing the window size again (data in the simulated stream will be consistent as if nothing was dropped, ever).

Does the buffer reside in your own process or in Windows?

It could be both, there is no urgent requirement for either, as long as it is managed/owned by the library layer it could as well reside in user space (though it's practically in kernel space). This is a detail that isn't important though, since you have no way of directly accessing the raw buffer either way. You can only access it via the API provided by your networking library (either Winsock functions or Berkeley-like socket functions).

Is it also possible to "DDos" still?

Yes. A DDoS is an attack that physically saturates the network cable. It does not matter a lot (or, at all) what you do on the software side. A DDoS needs to be addressed at a higher network layer (one that you usually don't have access to!). Once the rogue traffic made it past the "fat pipes" onto your server's subnet (or onto the router connecting it upstream), there is nothing more you can do.
Networks come in different physical (optical or electric) and logical (eg token) flavors, but in either case, there can only be one sender at any time on the cable. If someone saturates your line's capacity with a DDoS, neither you nor the router will be able to put packets on the wire, except occasionally, by chance. Routers, however, are built to have short forward queues and discard packets quickly when the queue fills up, so practically you're out of luck.

Answer 2

I don't have a very thorough understanding of TCP, so this layman's explanation may not be entirely correct. Relevant search terms to learn more are "flow control", "window", "throughput" and "saturation".

See what happens when tcp/udp server is publishing faster than client is consuming? , where the answer says "it won't": a connection allows only for a certain amount of data to be "in flight" and stop sending once it detects that maximum has been reached.

When all receive buffers (NIC, kernel) are full and not being processed by the receiving application, and the sender keeps sending data (maliciously not adhering to the TCP protocol), the receiving NIC will drop the incoming packets.

This will still cost bandwidth as the packets end up in the NIC, so yes, that is still a DDOS vulnerability.