1. should first consider websocket .

2. in multiple requests, it is found that there is an occasional timeout in the middle of the request, so it is obviously not appropriate to adopt option 2.

   this is just an exception that needs to be handled, because in either case, timeouts or network errors can occur. This is the part that should be considered and handled, not the part that can be excluded, even if you use solution 1 or websocket .

3. if option 1 is adopted, there will be more problems.

   • because the same origin request only allows 6 TCP connection (chrome), on the browser, if it is not processed in a timely manner, there will be a pile of requests in the Queuing/Stalled state.
   • the same request is affected by the cache lock and is in the Stalled state.
   • because browsers reuse TCP connections, if multiple original TCP connections are not available, they will wait in the Stalled state for a long time.

PS: for the questions raised in point 3 of the appeal, please refer to the Queuing and Stalled sections of Network Resource Timing .

you can try to request again in 2 seconds in the successful callback recursively

callback, you will encounter the recursive depth limit of js.
therefore, it is better to use a timer.
you just set the timeout for ajax, and the timer will not repeat at the same time.
in addition, it is possible to cancel a previous request before a new request.

at this time, it shows the advantage of using setTimeout instead of setInterval . The subject may wish to use Baidu

I also recommend the websocket recommended upstairs.
this belongs to instant messaging. For specific examples, please see the message notice on this website.
uses socket.io