Created attachment 1722617 [details] TCP connection is closed by golang app (should remain opened) # Scenario: Send several HTTP requests on the same TCP connection, for example with “python requests.Session()” # Actual Result: Golang server app drops(FIN) TCP connection after first respond in spite of the fact that the request is: HTTP1.1 + Connection: keep-alive is included in requests headers. See attached ark1.cap # Expected Result: HTTP server is able to keep TCP connection opened and to serve all the incoming HTTP requests as expected. See attached ynet.cap file
Created attachment 1722618 [details] Standard HTTP server, all GETs are on the same TCP connection.
Hi Arkady, I tried to reproduce it in my env with python-requests, and I don't see any FIN packets between the consecutive requests: 14:52:17.952832 IP 192.168.122.1.59688 > 192.168.122.229.8080: Flags [S], seq 1690615230, win 64240, options [mss 1460,sackOK,TS val 2896649802 ecr 0,nop,wscale 7], length 0 14:52:17.953111 IP 192.168.122.229.8080 > 192.168.122.1.59688: Flags [S.], seq 2043525237, ack 1690615231, win 28960, options [mss 1460,sackOK,TS val 1003638908 ecr 2896649802,nop,wscale 7], length 0 14:52:17.953141 IP 192.168.122.1.59688 > 192.168.122.229.8080: Flags [.], ack 1, win 502, options [nop,nop,TS val 2896649802 ecr 1003638908], length 0 14:52:17.953162 IP 192.168.122.1.59688 > 192.168.122.229.8080: Flags [P.], seq 1:152, ack 1, win 502, options [nop,nop,TS val 2896649802 ecr 1003638908], length 151: HTTP: GET / HTTP/1.1 14:52:17.953265 IP 192.168.122.229.8080 > 192.168.122.1.59688: Flags [.], ack 152, win 235, options [nop,nop,TS val 1003638908 ecr 2896649802], length 0 14:52:17.953447 IP 192.168.122.229.8080 > 192.168.122.1.59688: Flags [P.], seq 1:144, ack 152, win 235, options [nop,nop,TS val 1003638908 ecr 2896649802], length 143: HTTP: HTTP/1.1 200 OK 14:52:17.953461 IP 192.168.122.1.59688 > 192.168.122.229.8080: Flags [.], ack 144, win 501, options [nop,nop,TS val 2896649803 ecr 1003638908], length 0 14:52:18.955905 IP 192.168.122.1.59688 > 192.168.122.229.8080: Flags [P.], seq 152:325, ack 144, win 501, options [nop,nop,TS val 2896650805 ecr 1003638908], length 173: HTTP: GET / HTTP/1.1 14:52:18.956354 IP 192.168.122.229.8080 > 192.168.122.1.59688: Flags [P.], seq 144:287, ack 325, win 243, options [nop,nop,TS val 1003639911 ecr 2896650805], length 143: HTTP: HTTP/1.1 200 OK 14:52:18.956387 IP 192.168.122.1.59688 > 192.168.122.229.8080: Flags [.], ack 287, win 501, options [nop,nop,TS val 2896650806 ecr 1003639911], length 0 14:52:19.958583 IP 192.168.122.1.59688 > 192.168.122.229.8080: Flags [P.], seq 325:498, ack 287, win 501, options [nop,nop,TS val 2896651808 ecr 1003639911], length 173: HTTP: GET / HTTP/1.1 14:52:19.958917 IP 192.168.122.229.8080 > 192.168.122.1.59688: Flags [P.], seq 287:430, ack 498, win 252, options [nop,nop,TS val 1003640913 ecr 2896651808], length 143: HTTP: HTTP/1.1 200 OK 14:52:19.958955 IP 192.168.122.1.59688 > 192.168.122.229.8080: Flags [.], ack 430, win 501, options [nop,nop,TS val 2896651808 ecr 1003640913], length 0 14:52:20.962187 IP 192.168.122.1.59688 > 192.168.122.229.8080: Flags [P.], seq 498:671, ack 430, win 501, options [nop,nop,TS val 2896652811 ecr 1003640913], length 173: HTTP: GET / HTTP/1.1 14:52:20.962530 IP 192.168.122.229.8080 > 192.168.122.1.59688: Flags [P.], seq 430:573, ack 671, win 260, options [nop,nop,TS val 1003641917 ecr 2896652811], length 143: HTTP: HTTP/1.1 200 OK 14:52:20.962570 IP 192.168.122.1.59688 > 192.168.122.229.8080: Flags [.], ack 573, win 501, options [nop,nop,TS val 2896652812 ecr 1003641917], length 0 14:52:21.967605 IP 192.168.122.1.59688 > 192.168.122.229.8080: Flags [F.], seq 671, ack 573, win 501, options [nop,nop,TS val 2896653817 ecr 1003641917], length 0 14:52:21.968025 IP 192.168.122.229.8080 > 192.168.122.1.59688: Flags [F.], seq 573, ack 672, win 260, options [nop,nop,TS val 1003642922 ecr 2896653817], length 0 14:52:21.968065 IP 192.168.122.1.59688 > 192.168.122.229.8080: Flags [.], ack 574, win 501, options [nop,nop,TS val 2896653817 ecr 1003642922], length 0 Can you share the client script that generates the requests?
Hi Gregory! You are right Server App is OK, problem is not there. The problem occurred when the scenario was running through LB (listener port was 104 you could see it in ark1.cap) Unfortunately now I cannot reproduce it on my setup, working on that. As for this BZ, agree that you can close it, I'll keep you informed. Thanks!
Closing the BZ, feel free to reopen it if you reproduce the bug