Experiment with Go http

[roman-khimov]

No description provided.

[codecov]

Codecov Report

❌ Patch coverage is 0% with 299 lines in your changes missing coverage. Please review.
✅ Project coverage is 28.18%. Comparing base (31835d3) to head (d781e28).

Files with missing lines	Patch %	Lines
pkg/services/object/server.go	0.00%	201 Missing ⚠️
cmd/neofs-node/grpc.go	0.00%	43 Missing ⚠️
pkg/network/cache/clients.go	0.00%	30 Missing ⚠️
pkg/services/object/get.go	0.00%	22 Missing ⚠️
cmd/neofs-node/config.go	0.00%	1 Missing ⚠️
cmd/neofs-node/netmap.go	0.00%	1 Missing ⚠️
cmd/neofs-node/object.go	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3973      +/-   ##
==========================================
- Coverage   28.34%   28.18%   -0.17%     
==========================================
  Files         681      681              
  Lines       45756    46016     +260     
==========================================
  Hits        12969    12969              
- Misses      31555    31815     +260     
  Partials     1232     1232              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[roman-khimov]

What we need here is to finish this prototype with an end-to-end GET data transport over HTTP, from S3 gateway (additional branch there) to SN. Many things can be improved here performance-wise, but we're interested in a quick prototype first, so many of object service internals are still left as is and just two proto-encoded byte arrays are pushed to the client (that needs to parse them).

[End-rey]

Ran load against target (HTTP/2) vs base (gRPC): REP3, 4 KB and 4 MB objects, 1/4/16 threads/node.

Result: at 1 thread everything is within the margin of error, but the gap grows steadily as threads increase - the prototype scales worse under concurrency.

Test	Size	1	4	16
PUT	4 KB	+0.9%	0.0%	−5.4%
PUT	4 MB	−6.6%	−13.3%	−15.8%
GET	4 KB	−7.3%	−12.4%	−13.2%
GET	4 MB	−1.8%	−5.8%	−9.6%

PUT wasn't changed - the regression comes from the node now serving gRPC over net/http instead of the native gRPC server.

Likely cause of the degradation with more threads: stock net/http2 serializes concurrent streams on a single connection (no write batching like gRPC's loopyWriter), so the more parallel requests there are, the more they queue up on one connection.