| commit | d2529067e4a9ec21872b18156646080b3c1fda46 | [log] [tgz] |
|---|---|---|
| author | David Benjamin <[email protected]> | Tue Oct 22 17:53:35 2024 -0400 |
| committer | Boringssl LUCI CQ <[email protected]> | Mon Nov 11 23:45:46 2024 +0000 |
| tree | 64768306c18b2d0f7294730600591238bd3b4e5b | |
| parent | 571c76e919c0c48219ced35bef83e1fc83b00eed [diff] |
Use DTLS 1.3 ACKs to avoid retransmitting ACKed fragments This implements the first part of ACK processing: track which parts of each outgoing message have been ACKed, update when receiving an ACK, and use it to reduce retransmits. To do this, we also need to track the last handful of records we sent, and use that to correlate ACKs with packets. Test this by extending the new retransmit fragment to manage ACKs. The callback gets told record numbers, along with what message segments they cover, and may choose to ACK them. If it does, the ReadRetransmit expectations will be automatically updated. For now, I've made no attempt to test or handle post-handshake messages. That has a lot of subtle assumptions around there not being multiple concurrent transactions, so I think we'll tackle this later. This also does not handle: - Triggering retransmits when we receive partial ACKs. - Implicitly ACKing flights when we receive any part of the next flight. - Any kind of sending ACKs. Bug: 42290594 Change-Id: I9e81a7d5c8838d4d31fe828e9fd9871631fe38ed Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/72387 Reviewed-by: Nick Harper <[email protected]> Commit-Queue: David Benjamin <[email protected]>
BoringSSL is a fork of OpenSSL that is designed to meet Google's needs.
Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.
Programs ship their own copies of BoringSSL when they use it and we update everything as needed when deciding to make API changes. This allows us to mostly avoid compromises in the name of compatibility. It works for us, but it may not work for you.
BoringSSL arose because Google used OpenSSL for many years in various ways and, over time, built up a large number of patches that were maintained while tracking upstream OpenSSL. As Google's product portfolio became more complex, more copies of OpenSSL sprung up and the effort involved in maintaining all these patches in multiple places was growing steadily.
Currently BoringSSL is the SSL library in Chrome/Chromium, Android (but it's not part of the NDK) and a number of other apps/programs.
Project links:
To file a security issue, use the Chromium process and mention in the report this is for BoringSSL. You can ignore the parts of the process that are specific to Chromium/Chrome.
There are other files in this directory which might be helpful: