Bug 1889313 - Golang test server – doesn’t support persistence in term of TCP session (sequential/pipelining HTTP requests on same TCP connection)
Summary: Golang test server – doesn’t support persistence in term of TCP session (sequ...
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: python-octavia-tests-tempest
Version: 16.1 (Train)
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: Carlos Goncalves
QA Contact: Bruna Bonguardo
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-10-19 11:12 UTC by Arkady Shtempler
Modified: 2020-10-20 08:19 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-10-20 08:19:29 UTC
Target Upstream Version:

Attachments (Terms of Use)
TCP connection is closed by golang app (should remain opened) (581.11 KB, application/vnd.tcpdump.pcap)
2020-10-19 11:12 UTC, Arkady Shtempler 		no flags Details
Standard HTTP server, all GETs are on the same TCP connection. (107.41 KB, application/vnd.tcpdump.pcap)
2020-10-19 11:14 UTC, Arkady Shtempler 		no flags Details
Add an attachment (proposed patch, testcase, etc.)

Description Arkady Shtempler 2020-10-19 11:12:11 UTC 
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
Comment 1 Arkady Shtempler 2020-10-19 11:14:03 UTC 
Created attachment 1722618 [details]
Standard HTTP server, all GETs are on the same TCP connection.
Comment 2 Gregory Thiemonge 2020-10-19 12:54:58 UTC 
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?
Comment 3 Arkady Shtempler 2020-10-20 08:11:42 UTC 
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!
Comment 4 Gregory Thiemonge 2020-10-20 08:19:29 UTC 
Closing the BZ, feel free to reopen it if you reproduce the bug
Note You need to log in before you can comment on or make changes to this bug.