HTTP 1.1持久连接：Android GET / POST：[FIN / ACK]即将到来

Question

I am consuming HTTP GET/POST request in an Android Applicaton, Its doing well(Request And response) however when i refer to wireshark LOG there is [FIN, ACK] is coming, is it means my connection is closing or what? My requirement is to make the connection persistent. So my question is why FIN/ACK is coming and if it is closing the connection then where i am leaving?

WireShark LOG and Request/Response content are below:

For GET/POST:

Request:

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

Response:

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 LOG:

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

Answer 1

Based on the packet capture the connection close is initiated by the server shortly after the response was sent. If and how long the server is keeping the connection open for the next HTTP request within the same TCP connection solely depends on the server side and there is no way for the client to tune this. All the client can do is to nicely ask the server to keep the connection open for another request, which you do by using HTTP/1.1 and also by sending (a redundant) Connection: keep-alive . There is no way for the client to enforce persistent connection or to enforce a minimum time how long the server should wait for the next request.