use bytes_acked instead of delivered to get the sent bytes, it is acc…

[hzxuzhonghu]

…urate

What type of PR is this?

What this PR does / why we need it:

previously from the access log , we can see the sent_bytes=14566 from one side, but received_bytes=29257 from the other peer, it is totally unconsistent.

accesslog: 2025-05-08 07:41:31.436041742 +0000 UTC src.addr=10.244.0.14:49056, src.workload=ws-client, src.namespace=default, dst.addr=10.244.0.11:8080, dst.service=ws-server-service.default.svc.cluster.local, dst.workload=ws-server, dst.namespace=default, start_time=2025-05-08 03:38:34.201259611 +0000 UTC, direction=INBOUND, state=BPF_TCP_ESTABLISHED, sent_bytes=14566, received_bytes=280, packet_loss=0, retransmissions=0, srtt=457us, min_rtt=38us, duration=1.4577234782131e+07ms
accesslog: 2025-05-08 07:41:31.436079898 +0000 UTC src.addr=10.244.0.14:49056, src.workload=ws-client, src.namespace=default, dst.addr=10.244.0.11:8080, dst.service=ws-server-service.default.svc.cluster.local, dst.workload=ws-server, dst.namespace=default, start_time=2025-05-08 03:38:34.201135327 +0000 UTC, direction=OUTBOUND, state=BPF_TCP_ESTABLISHED, sent_bytes=3, received_bytes=29257, packet_loss=0, retransmissions=0, srtt=41600us, min_rtt=40us, duration=1.4577234944571e+07ms

With this, now it is consistent.

accesslog: 2025-05-12 02:39:40.614457387 +0000 UTC src.addr=10.244.0.35:48174, src.workload=ws-client, src.namespace=default, dst.addr=10.244.0.34:8080, dst.service=ws-server-service.default.svc.cluster.local, dst.workload=ws-server, dst.namespace=default, start_time=2025-05-12 02:30:10.106157639 +0000 UTC, direction=INBOUND, state=BPF_TCP_ESTABLISHED, sent_bytes=7526, received_bytes=280, packet_loss=0, retransmissions=0, srtt=465us, min_rtt=37us, duration=570508.299748ms
accesslog: 2025-05-12 02:39:40.614494768 +0000 UTC src.addr=10.244.0.35:48174, src.workload=ws-client, src.namespace=default, dst.addr=10.244.0.34:8080, dst.service=ws-server-service.default.svc.cluster.local, dst.workload=ws-server, dst.namespace=default, start_time=2025-05-12 02:30:10.106051195 +0000 UTC, direction=OUTBOUND, state=BPF_TCP_ESTABLISHED, sent_bytes=281, received_bytes=7526, packet_loss=0, retransmissions=0, srtt=44188us, min_rtt=30us, duration=570508.443573ms

Which issue(s) this PR fixes:
Fixes #

Special notes for your reviewer:

Does this PR introduce a user-facing change?:

[Copilot]

Pull Request Overview

This PR fixes an inconsistency in the access log by using tcp_sock->bytes_acked instead of tcp_sock->delivered to determine the sent bytes, ensuring that sent and received bytes are logged consistently.

• Update the metric used for sent bytes in the TCP probe
• Provide a clarifying comment regarding the usage of bytes_acked

[hzxuzhonghu]

/assign @Kuromesi @LiZhenCheng9527

[kmesh-bot]

@hzxuzhonghu: GitHub didn't allow me to assign the following users: Kuromesi.

Note that only kmesh-net members with read permissions, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time.
For more information please see the contributor guide

In response to this:

/assign @Kuromesi @LiZhenCheng9527

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 46.31%. Comparing base (5d434e0) to head (3f0912e).
Report is 12 commits behind head on main.

see 2 files with indirect coverage changes

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 410c184...3f0912e. Read the comment docs.

🚀 New features to boost your workflow:

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

[LiZhenCheng9527]

/lgtm
/approve

[kmesh-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: LiZhenCheng9527

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [LiZhenCheng9527]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[kmesh-bot]

In response to a cherrypick label: new pull request created: #1392