Я использую websockets для передачи видео-y изображений с сервера, написанного на Go, клиенту, который является HTML-страницей. Ниже приведен мой опыт работы с Chrome.
Я получаю изображения через обработчик onmessage websocket. При получении изображения мне может потребоваться выполнить несколько задач асинхронно, прежде чем я смогу отобразить изображение. Даже если эти задачи еще не закончены, может произойти еще одно onmessage(). Я не хочу ставить в очередь изображения, так как на данный момент я не могу действовать так же быстро, как это происходит на сервере, и потому, что нет смысла отображать старые изображения. Я также не хочу бросать эти изображения, я не хочу их вообще получать.
Будет ли клиент использовать традиционное TCP-соединение, он просто прекратит чтение из соединения. Это приведет к заполнению буфера приема, закрытию окна приема и, в конечном итоге, приостановке отправки изображений на сервере. Как только клиент начнет чтение, буферы приема будут пусты, откроется окно приема, и сервер возобновит передачу. Каждый раз, когда мой сервер начинает отправлять изображение, он выбирает самый свежий. Это самое лучшее поведение, а также контроль потока TCP гарантируют разумное поведение во многих случаях.
Возможно ли иметь функции управления потоком TCP, на которых основаны веб-сайты, с веб-окнами? Меня особенно интересует решение, которое зависит от управления потоком TCP и управления потоком на уровне приложений, поскольку это приводит к нежелательной дополнительной задержке.
