HTTP 1.1 Постоянное соединение: Android GET / POST: прибывает [FIN / ACK]
Я использую HTTP-запрос GET / POST в Android-приложении, он работает хорошо (запрос и ответ), однако, когда я обращаюсь к Wireshark LOG, появляется [FIN, ACK], это означает, что мое соединение закрывается или что? Мое требование - сделать соединение постоянным. Итак, мой вопрос: почему приходит FIN / ACK, и если он закрывает соединение, то куда я ухожу?
Журнал WireShark и содержимое запроса / ответа приведены ниже:
Для GET / POST:
Запрос:
GET /api/application/addparam HTTP/1.1
Content-Type: application/json; charset=utf-8
User-Agent: okhttp/2.5.0
Authorization: Basic QURJOg==
Host: 10.92.33.190:8080
Connection: Keep-Alive
Ответ:
HTTP/1.1 200 OK
X-Powered-By: Express
Content-Type: application/json; charset=utf-8
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Content-Length: 558
Date: Fri, 18 May 2018 13:11:46 GMT
Connection: keep-alive
{
//JSON Here
}
ЖУРНАЛ WireShark:
692 28.537182 10.92.33.134 10.92.33.190 HTTP 329 POST /api/application/AddParam HTTP/1.1 (application/json)
693 28.541340 10.92.33.190 10.92.33.134 HTTP 345 HTTP/1.1 200 OK (application/json)
704 29.194478 10.92.33.190 10.92.33.134 TCP 66 8080 → 47074 [FIN, ACK] Seq=289 Ack=334 Win=66048 Len=0 TSval=285850628 TSecr=19045098
709 29.393729 10.92.33.134 10.92.33.190 TCP 66 47074 → 8080 [ACK] Seq=334 Ack=290 Win=88832 Len=0 TSval=19045619 TSecr=285850628
852 33.544459 10.92.33.190 10.92.33.134 TCP 66 8080 → 45502 [FIN, ACK] Seq=280 Ack=264 Win=66304 Len=0 TSval=285854978 TSecr=19045534
855 33.583848 10.92.33.134 10.92.33.190 TCP 66 45502 → 8080 [ACK] Seq=264 Ack=281 Win=88832 Len=0 TSval=19046038 TSecr=285854978
Ответы 1
На основе захвата пакета сервер инициирует закрытие соединения вскоре после отправки ответа. Если и как долго сервер поддерживает соединение для следующего HTTP-запроса в том же TCP-соединении зависит исключительно от сервера, и у клиента нет возможности настроить это. Все, что может сделать клиент, - это вежливо попросить сервер оставить соединение открытым для другого запроса, что вы делаете, используя HTTP / 1.1, а также отправляя (избыточный) Connection: keep-alive. Есть у клиента нет возможности принудительно установить постоянное соединение или установить минимальное время, сколько времени сервер должен ждать следующего запроса.
@SRam: то, что вы описываете, является нормальным потоком закрытия TCP-соединения: одна сторона начинает с FIN, чтобы сигнализировать, что она больше не будет отправлять данные, и как только другая сторона тоже отправит FIN, соединение считается закрытым (т.е. никто не отправит ничего больше). Важной частью вашей проблемы является то, какая сторона отправляет первый FIN, а в вашем случае это сервер.
Я полностью согласен с тем, что говорит: «Важной частью является то, какая сторона отправляет первый FIN, а в вашем случае это сервер». однако, на мой взгляд, liitlle, что HTTP1.1 поддерживает постоянное соединение по умолчанию, поэтому есть ли необходимость отправлять параметр «Connection: keep-alive» от клиента, потому что, если я не добавляю keep-alive, HTTP1.1 запрос добавляет это автоматически. Итак, есть ли способ предотвратить отправку сервером [FIN / ACK] через короткое время в 3-5 секунд. Или мы можем увеличить продолжительность отправки FIN с сервера?
@SRam: цитирую себя: «У клиента нет возможности принудительно установить постоянное соединение или установить минимальное время, в течение которого сервер должен ждать следующего запроса».. Другими словами, вы не можете изменить поведение серверов со стороны клиента, но для этого вам потребуется доступ к серверу.
Подскажите, пожалуйста, что это за «Продолжение» в запросе?
@SRam: Я понятия не имею, что вы пытаетесь сделать, но я думаю, что на ваш первоначальный вопрос был дан полный ответ. Если у вас есть дополнительные вопросы, не задавайте их в комментариях, а задайте новый вопрос, который включает всю необходимую информацию.
Спасибо за ответ, Штеффен. Иногда клиент также отправляет [FIN / ACK] после [FIN / ACK] сервера ... при необходимости я могу также прикрепить другой журнал wirehark: 409 16.644007 10.92.33.134 10.92.33.190 TCP 66 58340 → 8080 [FIN, ACK] Seq = 483 Ack = 299 Win = 88832 Len = 0 TSval = 19044343 TSecr = 285833018