Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

net/http: server sets TCPConn writebuf through ConnContext hook will block the send of a big response body #50795

Open
chenjie199234 opened this issue Jan 25, 2022 · 5 comments
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@chenjie199234
Copy link

chenjie199234 commented Jan 25, 2022

What version of Go are you using (go version)?

1.17.6

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (go env)?

go env Output
linux amd64

What did you do?

&http.Server{
	ReadTimeout:    time.Second,
	IdleTimeout:    time.Second,
	MaxHeaderBytes: 1024,
	ConnContext: func(ctx context.Context, conn net.Conn) context.Context {
		(conn.(*net.TCPConn)).SetReadBuffer(2048)
		(conn.(*net.TCPConn)).SetWriteBuffer(2048)
		return ctx
	},
}
use this server and write 12K+ data to response's body
but only 4096 data send
same code,but set the buf to 4096,all data will be send
but when i send 1M+ data when the buf is set to 4096,the send data truncate too
why?

this is the tcpdump file
wireshark filter is tcp.stream eq 18
pod-capture.cap.zip

What did you expect to see?

all data should be send

What did you see instead?

it will block on tcp write,and only part of the data will be send
@mknyszek mknyszek changed the title net/http server set tcpconn writebuf through ConnContext hook will block send big response body net/http: server sets TCPConn writebuf through ConnContext hook will block the send of a big response body Jan 25, 2022
@mknyszek mknyszek added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jan 25, 2022
@mknyszek mknyszek added this to the Backlog milestone Jan 25, 2022
@mknyszek
Copy link
Contributor

CC @neild

@chenjie199234
Copy link
Author

@mknyszek
here is one request's trace info from pprof
it works on G1069312,and it finally blocks on internal/pool.(*FD).Write():283,no more trace info in this 60s.
trace.zip

@chenjie199234
Copy link
Author

here is one request's profile info from pprof
profile.zip

@chenjie199234
Copy link
Author

this is my self trace info
the start is the time when i get the request
the end is the time when the Write return

[TRACE] {"trace_id":"1643164511883031560_7626180989541976002","deep":1,"start":1643164511883037729,"end":1643165625828797709,"host_name":"supports-service-77cc9b447f-4btjv","role":"server","from_app":"unknown","from_ip":"10.136.207.227:23366","from_method":"unknown","from_path":"unknown","to_app":"psp-prod.supports","to_ip":"10.136.192.250","to_method":"POST","to_path":"/supports.gamelog/SearchLog","err_msg":"","err_code":0}

@chenjie199234
Copy link
Author

if delete

(conn.(*net.TCPConn)).SetReadBuffer(2048)
(conn.(*net.TCPConn)).SetWriteBuffer(2048)

every thing works fine
here is the trace from pprof after i delete it
trace-delete-set-buf.zip
why?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

2 participants