Server architecture?

Question

Nginx

Hi all. Now there is such a server architecture:

The application makes calculations in a loop every 100 ms, creates a local tcp connection (with the nginx server), sends information ~ 30-40 bytes through this connection with a POST request, closes the connection.

Naturally, this is very slow, and there are several reasons:

• 100 ms, quite a small interval
  
• A TCP connection is created every update cycle (I know about Keep-alive, but will it help?)
  
• Basically a POST request. The HTTP protocol is flawed for such things.
  

I ask you to help speed up all this.
Firstly, there was an idea not to create a connection every time, but to keep Keep-alive, but the fact is that there can be thousands of such applications running at the same time, and all this on one host. I don't know which is better: to keep the server permanently connected or to re-create it.

Also, it's probably worth throwing out the POST request and HTTP altogether.

Will this implementation be better: I
throw out nginx altogether (it was a link between the application that distributed information and clients that read GET requests)
Clients directly connect via TCP to the server, configure, say information about themselves and then name the udp port, the application connects with it and starts sending a data stream directly.

What do you say, I will be grateful for any hint.

Answer 1

Yes, the second option with related UDP is preferable. There is, however, something to think about.
1. Will clients be able to connect via UDP (is there a firewall)? Of course, you can use UDP 53…
2. How will you distribute clients? When working via HTTP, the client turns out to be browser-based, i.e. distribution for free. Any socket-based client will have to be distributed in binary form.
3. You should also think about udp vs tcp. If you have a server and a client within the same locale, then definitely - udp. If the order in which the client receives packets over the Internet is important to you, then you will have to implement some kind of your own protocol with numbering inside udp.
As uTorrent practice shows, the reimplementation of TCP to UDPdelivers a profit. But you need to soberly assess that 20% of the gain in speed will cost 80% of the complexity of the code.
If you don’t want to write your transport with a delivery guarantee, but you still need a delivery guarantee, then you can use TCP, scoring a small overhead. Or maybe really take uTP .

Answer 2

Use ZeroMQ to communicate. There are bindings for any language, I guess.

Answer 3

Of course http is redundant here. Sending data to an open persistent socket connection will be faster. Did such by one machine and between remote.