{
  "test_id": "T48",
  "verdict": "pass",
  "observed": "TLS(443, mendhak/http-https-echo) 목적지로 5개의 개별 curl 프로세스(각기 새 TCP 연결)를 보내자 tcp_proxy 클러스터(outbound|443||mock.istio-verify-ext.svc.cluster.local)의 upstream_cx_total이 1에서 6으로 정확히 5만큼 증가해 다운스트림 연결 5개가 업스트림 연결 5개를 1:1로 만들었음을 확인했다. 반대로 하나의 curl 프로세스로 같은 연결을 재사용해 3개 요청을 보낸 뒤에는 upstream_cx_total이 6에서 7로 단 1만 증가했고, verbose curl 트레이스에서도 'Connected to...' 1회 뒤에 'Re-using existing https: connection' 메시지가 2회 확인되어 연결 재사용이 실제로 일어났음을 뒷받침한다. 다만 ServiceEntry가 선언한 svc.homelab.local 호스트는 동일 ClusterIP를 갖는 기존 k8s Service의 전용 리스너(svc.cluster.local 클러스터, 역시 tcp_proxy)에 밀려 실제 트래픽을 받지 못했고, 기본 meshConfig의 proxyStatsMatcher가 /stats에서 per-cluster 통계를 배제하고 있어 client 파드에 sidecar.istio.io/statsInclusionRegexps 주석을 추가해 관측했다.",
  "claims": [
    {
      "doc": "gw__guide-egress-adoption-passthrough-vs-mtls",
      "cid": "C15",
      "empirical": "supports-claim",
      "note": "TLS passthrough(SE, MESH_EXTERNAL) 목적지로의 트래픽이 tcp_proxy로 처리되고, 다운스트림 연결 수와 업스트림 연결 수가 1:1로 정확히 일치함을 upstream_cx_total 델타(5회 개별 연결 -> +5)로 확인."
    },
    {
      "doc": "gw__src-egress-tcp-bottlenecks",
      "cid": "C1",
      "empirical": "supports-claim",
      "note": "L4 tcp_proxy는 HTTP 요청 단위가 아니라 TCP 연결 단위로 매핑되므로 연결 재사용 시 여러 요청을 보내도 업스트림 연결이 늘지 않음(3개 요청, 재사용 연결 1개 -> +1)을 확인해 커넥션 풀링/멀티플렉싱이 없다는 주장을 뒷받침."
    }
  ]
}