The WebRTC section of the article seemed weird in general. The reason WebRTC doesn't specify signaling requirements is that clients can use any communications m

The WebRTC section of the article seemed weird in general. The reason WebRTC doesn't specify signaling requirements is that clients can use any communications mechanism they'd like for signaling, and in the case where you are using WebRTC as sever-push mechanism, the "signaling" server and the server you want to receive pushes from could be the same server, allowing the use of "regular" HTTP as the transport for your "signaling" data. With QUIC & HTTP/3, and things like RFC 8441 & 9220, you could well be using UDP with non-WebRTC protocols, and TCP stacks & routers tend to be pretty well tuned these days, so UDP doesn't necessarily have much of an advantage in this kind of use case. If you check out the benchmark the article uses, it specifically breaks out using "unreliable WebRTC/WebTransport". The "unreliable" looks to be referring to UDP (I despise how people misleadingly associate UDP with "unreliable"). They also have "reliable WebRTC/WebTransport", which appears to be using TCP. In the latter case, they actually found in some cases WebTransport doing a tad better in the face of packet loss, which is interesting. I haven't looked at the details of the tests, but in my experience benchmarching WebRTC is not as straightforward as one might expect; it's entirely possible the nature of the benchmark itself is leading to WebRTC's better & worse performance.