Great question—UDP's connectionless nature makes these frequency and limitation questions super critical, since there's no built-in safety net like TCP has. Let's break this down step by step.

When deciding how often to send UDP datagrams, keep these practical points in mind:

• Sender-side resource constraints: Don't overlook your own system's limits. Blast out datagrams too quickly, and you'll fill up the kernel's send buffer (check OS-specific settings like Linux's net.core.wmem_max), leading to kernel-level packet drops before the data even hits the network. Your CPU and memory also need to keep up with generating and queuing those packets.
• Receiver's processing capacity: UDP doesn't wait for acknowledgments, so even if you send at a steady clip, the server might not keep up. If the server's receive buffer (e.g., net.core.rmem_max on Linux) fills up, incoming packets get dropped. The server's application also needs to read packets from the buffer quickly—slow processing here leads to the same problem.
• Network congestion & QoS: Routers prioritize traffic, and UDP gets no special treatment. During congestion, routers will drop UDP packets first (since TCP has built-in congestion control that backs off). Sending too frequently can trigger this more often, leading to higher packet loss rates.
• OS packet processing limits: Every OS has a maximum number of packets per second (PPS) it can handle. While modern systems can handle high PPS, pushing the limit can cause unexpected drops or increased latency.

First, quick math: 10KB per datagram every 2ms works out to ~40 Mbps of bandwidth (8 bits/byte × 10,000 bytes × 500 datagrams/second) and 500 packets per second (PPS). Here's where you might hit roadblocks:

Server-Side Restrictions #

• Network interface & stack tuning: Most modern gigabit NICs can handle 40 Mbps and 500 PPS easily, but default OS buffer settings might not. If the server's receive buffer is too small, those 10KB packets will pile up and overflow. You'll need to tune settings like net.core.rmem_default and net.core.rmem_max to accommodate incoming traffic.
• Application processing speed: The server's application needs to process 500 10KB packets every second. If each packet requires heavy parsing, database writes, or other CPU-intensive work, you might hit a CPU bottleneck. Slow processing means the application doesn't empty the receive buffer fast enough, leading to drops.
• Firewall/IDS rules: Many firewalls or intrusion detection systems (IDS) flag high-frequency UDP traffic as potential DDoS attacks. Your server's firewall might start blocking or throttling the traffic unless you explicitly whitelist your sender IP and adjust IDS thresholds.
• Competing system resources: If the server runs other applications, competition for CPU, memory, or network bandwidth can eat into the capacity needed for your UDP traffic.

ISP-Level Restrictions #

• Bandwidth caps: If your server's ISP plan has a bandwidth limit (common with shared hosting or residential plans), 40 Mbps might push against or exceed that cap. ISPs often throttle traffic or drop packets once you hit the limit.
• MTU & fragmentation issues: 10KB datagrams are way larger than the standard Ethernet MTU of 1500 bytes, so they'll split into multiple fragments. Fragmented UDP packets are more likely to be dropped by routers or ISPs—some networks limit or block heavily fragmented traffic to reduce overhead.
• Anti-abuse policies: ISPs monitor for unusual traffic patterns, and 500 UDP packets per second from a single source might trigger their anti-abuse systems. This could lead to temporary IP blocks or throttling unless you've pre-notified your ISP about your legitimate traffic.
• QoS prioritization: ISPs often prioritize TCP traffic (used for most web, email, and business services) over UDP. During peak network times, your UDP packets might be deprioritized, leading to higher latency or loss.

内容的提问来源于stack exchange，提问作者Joseph Conrad