Conversation
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## master #4003 +/- ##
==========================================
- Coverage 26.77% 26.72% -0.06%
==========================================
Files 688 690 +2
Lines 46661 46817 +156
==========================================
+ Hits 12493 12510 +17
- Misses 33036 33173 +137
- Partials 1132 1134 +2 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
Benchmark tests were run on this branch against the 0.53 release. Throughput in ops/s. Very nice improvement for small objects, where the per-message signature dominates and the 1:1-hop skip removes it; large objects are bandwidth-bound, so any difference there is within the test's margin of error (no regression). REP3
EC6+2
|
|
very visible improvement for smaller data 🚀 it seems to me that this approach can be extended to user-SN connections too. If so, we can expect additional performance gains. Are there any blockers? (not for this PR) |
Yes, it can extend to client-SN and would help the read path. In my opinion two problems, though: client authorization can take a trickier path than node-to-node, and it may not be possible to cover all requests this way (but that's not for sure). Worth exploring, but not a drop-in like the node-to-node case. |
Storage nodes authenticate to each other with mutual TLS over their existing public gRPC port. A node dials with a sentinel SNI and is served the identity certificate, verified against the network map; clients keep getting the plain or server-TLS endpoint unchanged. Peers are pinned by their network-map key. Signed-off-by: Andrey Butusov <andrey@nspcc.io>
| req.VerifyHeader, err = neofscrypto.SignRequestWithBuffer(neofsecdsa.Signer(signer), req, nil) | ||
| if err != nil { | ||
| return nil, iprotobuf.BuffersSlice{}, err | ||
| if req.MetaHeader.Ttl > 1 { |
There was a problem hiding this comment.
It's always 1 now (and in similar cases).
There was a problem hiding this comment.
Noticed it, fixed it.
On the inter-node mTLS listener the peer is an authenticated network-map node, so verifying the per-request signature and signing the response are redundant for 1:1 (TTL<=1) hops and are skipped. Requests arriving on the plain public listener carry no TLS peer certificate and are always verified and signed, so clients remain unaffected. Signed-off-by: Andrey Butusov <andrey@nspcc.io>
|
After rebase the impact is still there: mTLS keeps a clear positive effect on GET workloads, while PUT remains mostly neutral to slightly negative. REP3
EC6+2
|
3 participants
Closes #4001.