import okhttp3.internal.connection.RealConnectionPool
import okhttp3.internal.connection.RealRoutePlanner
import okhttp3.internal.connection.RouteDatabase

/**
 * Manages reuse of HTTP and HTTP/2 connections for reduced network latency. HTTP requests that
 * share the same [Address] may share a [Connection]. This class implements the policy
 * of which connections to keep open for future use.
 *

efficiently makes your stuff load faster and saves bandwidth.

OkHttp is an HTTP client that’s efficient by default:

 * HTTP/2 support allows all requests to the same host to share a socket.
 * Connection pooling reduces request latency (if HTTP/2 isn’t available).
 * Transparent GZIP shrinks download sizes.
 * Response caching avoids the network completely for repeat requests.

 * OkHttp performs best when you create a single `OkHttpClient` instance and reuse it for all of
 * your HTTP calls. This is because each client holds its own connection pool and thread pools.
 * Reusing connections and threads reduces latency and saves memory. Conversely, creating a client
 * for each request wastes resources on idle pools.
 *
 * Use `new OkHttpClient()` to create a shared instance with the default settings:
 *
 * ```java

  // Timed Get
  // There are a few design constraints to consider
  // * We want to be responsive to small timeouts, unpark() has non trivial latency overheads (I
  //   have observed 12 micros on 64-bit linux systems to wake up a parked thread). So if the
  //   timeout is small we shouldn't park(). This needs to be traded off with the cpu overhead of

  // Timed Get
  // There are a few design constraints to consider
  // * We want to be responsive to small timeouts, unpark() has non trivial latency overheads (I
  //   have observed 12 micros on 64-bit linux systems to wake up a parked thread). So if the
  //   timeout is small we shouldn't park(). This needs to be traded off with the cpu overhead of

- Improved scheduling latency when many gated pods ([#124848](https://github.com/kubernetes/kubernetes/pull/124848), [@gabesaba](https://github.com/gabesaba)) [SIG Scheduling and Testing]

- Kubernetes is now built with go 1.21.11 ([#125369](https://github.com/kubernetes/kubernetes/pull/125369), [@cpanato](https://github.com/cpanato)) [SIG Release and Testing]

### Bug or Regression

- Improved scheduling latency when many gated pods ([#124866](https://github.com/kubernetes/kubernetes/pull/124866), [@gabesaba](https://github.com/gabesaba)) [SIG Scheduling and Testing]

- Added `apiserver.latency.k8s.io/authentication` annotation to the audit log to record the
  time spent authenticating slow requests. Also added `apiserver.latency.k8s.io/authorization`

- `kubelet` now emits a metric for end-to-end pod startup latency, including image pull. ([#121041](https://github.com/kubernetes/kubernetes/pull/121041), [@ruiwen-zhao](https://github.com/ruiwen-zhao))
- `kubelet` now exposes latency metrics of different stages of the node startup. ([#118568](https://github.com/kubernetes/kubernetes/pull/118568), [@qiutongs](https://github.com/qiutongs))

identified in large-scale clusters when deleting thousands of pods simultaneously across hundreds of nodes. Kubelets in this scenario can encounter temporarily increased latency of `delete pod` API calls -- above the target service level objective of 1 second. If you run clusters with this usage pattern and if pod deletion latency could be an issue for you, you might want to wait until the issue is resolved before you upgrade.

For more information and for updates on resolution of this...