Является ли корректным завершение TCP соединения с браузером?

Да, завершение TCP соединения с браузером является корректным действием. Когда сервер закрывает TCP соединение после отправки HTTP ответа, это сигнализирует браузеру о том, что сервер закончил передачу данных, и браузер должен закрыть соединение.

Чтобы устранить проблему с веб-сервером, которая приводит к разрыву подключения браузера сразу после отправки HTTP ответа, можно попробовать следующие способы:

1. Проверить настройки веб-сервера: убедиться, что настройки сервера правильно настроены и соединение не закрывается автоматически после отправки ответа.

2. Проверить наличие ошибок в коде: возможно, веб-сервер отправляет некорректные заголовки или данные, что приводит к разрыву соединения. Проверьте код сервера на наличие ошибок.

3. Увеличить таймауты: если проблема связана с тем, что браузер не успевает получить ответ от сервера за отведенное время, попробуйте увеличить таймауты соединения на сервере.

4. Использовать Keep-Alive: включите механизм Keep-Alive для установления постоянного соединения между сервером и браузером, что позволит избежать повторного установления соединения для каждого запроса.

5. Проверить наличие сетевых проблем: возможно, проблема связана с сетью или прокси-сервером. Проверьте связь между сервером и браузером, а также возможные проблемы с прокси-сервером.

Вплоть до 29 пакета всё кажется идёт хорошо, но в 29 пакете браузер пытается отправить ACK, как я понял в ответ на FIN ACK, но похоже тут что-то не так.
 
 всё ок, браузер почему-то отправил сразу два ACK, без учета FIN (29) и с учетом FIN (30). Ну лишний пакет получился, и ладно. Последовательность FIN/ACK завершена корректно. 
 
 
У меня подозрение, что в после того как сервер в 28 пакете отправил FIN ACK он не дожидается ACK от клиента, верно ли это?
 
 не, там всё нормально 
 
 
но браузер тут-же создаёт новое подключение
 
 не, там браузер сразу два соединения создал. так делается для оптимизации - чтобы быстрее загрузить что-нибудь ещё. обычно на странице много контента и помимо первого GET образуются много других GET. Но в вашем случае этого не происходит и соединение не пригождается. 
 
 
не присылает никаких запросов в этом подключении
 
 видимо в index.html не было больше ничего, что можно запросить 
 
 
поскольку я хочу просто отправить ответ и закрыть соединение
 
 так и вышло, но в первом соединении. второе так и висело на всякий случай. 
 
 
в этом варианте клиенту с сервером чуть-чуть не хватило что-бы полностью обработать последовательность:
 
 да не чуть-чуть, здесь вместо закрытия по таймауту (FIN), на стороне сервера соединение закрылось по RST (видимо по закрытию приложения сервера или по системному таймауту), клиент и не думал начинать закрывать сокет. логично - браузер всё ещё надеется, что вы откроете другую страничку 
 
 
Правильно ли я понимаю, что сервер посылая FIN ACK не дожидается ACK и в целом неверно производит завершение TCP подключения, завершая соединение раньше времени?
 
 всё корректно дожидается, тут проблем нет 
 
 
Именно поэтому браузер инициирует повторное подключение, но не присылает никаких данных.
 
 нет, браузер именно сразу при подключении открывает два соединения (обратите внимание на два SYN в самом начале), для более быстрой обработки ваших запросов. разработчики браузера стараются как можно сильнее ускорить работу, вот и идут на такие ухищрения. 
 
 
Я попробовал отправлять запрос с помощью сторонней утилиты, в этом случае соединение завершается корректно
 
 а тут всего одно соединение, без второго висящего в ожидании. утилита проста как тапок, сказали подключиться, подключается, без дополнительных оптимизаций и соединений "на будущее" 
 
 
(я пробовал разные браузеры)
 
 видимо все браузеры конкурируют по скорости работы с Web и делают такую оптимизацию