A new TCP (and possibly TLS) handshake/ has to be executed/ to set up a new connection/, and, depending on the application-level protocol, in-process actions/ would need/ to be restarted.
새 연결을 설정하려면 새 TCP(및 아마도 TLS) 핸드셰이크를 실행해야 하며 응용 프로그램 수준 프로토콜에 따라 프로세스 중 작업을 다시 시작해야 합니다.
For example, if you were downloading a large file over HTTP, then that file/ might have to be re-requested/ from the start (for example, if the server doesn’t support range requests).
예를 들어 HTTP를 통해 대용량 파일을 다운로드하는 경우 처음부터 해당 파일을 다시 요청해야 할 수 있습니다(예를 들어 서버가 범위 요청을 지원하지 않는 경우).
Another example is live video conferencing, where you/ might have/ a short blackout/ (when switching networks).
또 다른 예는 네트워크를 전환할 때 짧은 정전이 발생할 수 있는 라이브 화상 회의입니다.
Note that there are other reasons why the 4-tuple might change (for example, NAT rebinding), which we’ll discuss more in part 2.
4-튜플이 변경될 수 있는 다른 이유(예: NAT 리바인딩)가 있습니다. 이에 대해서는 파트 2에서 자세히 설명하겠습니다.
Restarting the TCP connections can thus have a severe impact (waiting for new handshakes, restarting downloads, re-establishing context).
따라서 TCP 연결을 다시 시작하면 심각한 영향을 미칠 수 있습니다(새로운 핸드셰이크 대기, 다운로드 다시 시작, 컨텍스트 다시 설정).
To solve this problem, QUIC introduces a new concept named the connection identifier (CID).
이 문제를 해결하기 위해 QUIC는 연결 식별자(CID)라는 새로운 개념을 도입합니다.
Each connection is assigned another number on top of the 4-tuple (that uniquely identifies it between two endpoints).
각 연결에는 두 엔드포인트 사이에서 고유하게 식별되는 4-튜플 위에 다른 번호가 할당됩니다.
Crucially, because this CID is defined at the transport layer in QUIC itself,/ it doesn’t change when moving between networks!
결정적으로, 이 CID는 QUIC 자체의 전송 계층에서 정의되기 때문에 네트워크 간에 이동할 때 변경되지 않습니다!
This is shown in the image below.
이것은 아래 이미지에 나와 있습니다.
To make this possible, the CID is included at the front of each and every QUIC packet (much like how the IP addresses and ports are also present in each packet).
이를 가능하게 하기 위해 CID는 각 QUIC 패킷의 전면에 포함됩니다(각 패킷에 IP 주소와 포트가 있는 것과 같습니다).
(It’s actually one of the few things in the QUIC packet header that aren’t encrypted!)
(사실 QUIC 패킷 헤더에서 암호화되지 않은 몇 안 되는 것 중 하나입니다!)
(With this set-up), even (when one of the things in the 4-tuple/ changes),/ the QUIC server and client/ only need to look/ at the CID to know (that it’s the same old connection), and then they can keep using it.
이 설정을 사용하면, 4-튜플에 있는 것들 중 하나가 바뀌어도 QUIC 서버와 클라이언트는 CID를 보기만 하면 CID가 동일한 오래된 연결임을 알 수 있고 계속 사용할 수 있습니다.
There is no need for a new handshake, and the download state can be kept intact.
새로운 악수가 필요 없으며 다운로드 상태를 그대로 유지할 수 있습니다.
This feature is typically called connection migration.
이 기능을 일반적으로 연결 마이그레이션이라고 합니다.
This is, in theory, better for performance, but as we will discuss in part 2, it’s, of course, a nuanced story again.
이것은 이론적으로는 성능이 더 좋습니다, 하지만 2부에서 논의하겠지만, 당연히 다시 미묘한 이야기입니다.
There are other challenges to overcome with the CID.
CID로 극복해야 할 다른 과제가 있습니다.
For example, if we would indeed use just a single CID, it would make it extremely easy for hackers and eavesdroppers to follow a user across networks and, by extension, deduce their (approximate) physical locations.
예를 들어, 실제로 단일 CID만 사용한다면 해커와 도청자가 네트워크를 가로질러 사용자를 추적하는 것이 매우 쉬워지고, 나아가 그들의 (대략적인) 물리적 위치를 추론할 수 있습니다.
To prevent this privacy nightmare, QUIC changes the CID every time a new network is used.
이러한 프라이버시 악몽을 방지하기 위해 QUIC는 새로운 네트워크를 사용할 때마다 CID를 변경합니다.
That might confuse you, though: Didn’t I just say that the CID is supposed to be the same across networks?
하지만 그건 혼란스러울 수 있어요: 제가 방금 말한 CID는 네트워크 간에 동일해야 한다고 하지 않았나요?
Well, that was an oversimplification.
음, 그건 너무 단순화된 것이었습니다.
What really happens internally is that the client and server/ agree/ on a common list of (randomly generated) CIDs/ that all map to the same conceptual “connection”.
실제로 내부적으로 일어나는 일은 클라이언트와 서버가 모두 동일한 개념의 "연결"에 매핑되는 (임의로 생성된) CID의 공통 목록에 동의하는 것입니다.
For example, they both know that CIDs K, C, and D in reality all map to connection X.
예를 들어, 그들은 CIDs K, C, 그리고 D가 사실상 모두 연결 X에 매핑된다는 것을 알고 있습니다.
As such, while the client might tag packets with K on Wi-Fi, it can switch to using C on 4G.
따라서 클라이언트는 Wi-Fi에서 K로 패킷을 태그할 수 있지만 4G에서는 C를 사용하는 것으로 전환할 수 있습니다.
These common lists are negotiated fully encrypted in QUIC, so potential attackers won’t know that K and C are really X,/
이러한 공통 목록은 QUIC에서 완전히 암호화된 상태로 협상되기 때문에 잠재적인 공격자는 K와 C가 정말 X라는 것을 알 수 없지만
but the client and server would know this, and they can keep the connection alive.
클라이언트와 서버는 이를 알 수 있으며 연결을 유지할 수 있습니다.
QUIC는 사용자 추적을 방지하기 위해 여러 개의 협상된 연결 식별자(CID)를 사용합니다.
It gets even more complex, because clients and servers will have different lists of CIDs that they choose themselves (much like they have different port numbers).
클라이언트와 서버는 스스로 선택한 서로 다른 CID 목록을 가지게 되어서 (포트 번호가 서로 다른 것처럼) 더욱 복잡해집니다.
This is mainly to support with routing and load balancing in large-scale server set-ups, as we’ll see in more detail in part 3.
이는 주로 대규모 서버 설정에서 라우팅 및 로드 밸런싱을 지원하기 위한 것으로, 파트 3에서 자세히 살펴보겠습니다.
Takeaway
The key takeaway here is that in TCP, connections are defined by four parameters that can change when endpoints change networks.
여기서 중요한 점은 TCP에서 엔드포인트가 네트워크를 변경할 때 변경할 수 있는 4개의 매개 변수로 연결이 정의된다는 것입니다.
As such, these connections sometimes need to be restarted, leading to some downtime.
따라서 이러한 연결을 다시 시작해야 하는 경우가 있으며, 이로 인해 다운타임이 발생하기도 합니다.
QUIC adds another parameter to the mix, called the connection ID.
QUIC는 연결 ID라고 하는 다른 매개 변수를 믹스에 추가합니다.
Both the QUIC client and server know (which connection IDs map to which connections) and are thus more robust against network changes.
QUIC 클라이언트와 서버 모두 어떤 연결 ID가 어떤 연결에 매핑되는지 알고 있으므로 네트워크 변경에 대해 더 강력합니다.
모르는 단어
intact: 손상되지 않은, 손대지 않은
eavesdroppers: 도청자
deduce: 추론하다, 추리하다
oversimplification: 지나치게 단순화
robust: 강력한, 튼튼한
원글: https://www.smashingmagazine.com/2021/08/http3-core-concepts-part1/
