QUIC SUPPORTS CONNECTION MIGRATION
The third major improvement in QUIC is the fact that connections can stay alive longer.
QUIC의 세 번째 주요 개선 사항은 연결이 더 오래 유지될 수 있다는 사실입니다.
Did You Know?
We often use the concept of a “connection” when talking about web protocols. However, what exactly is a connection?
우리는 웹 프로토콜에 대해 이야기할 때 종종 "연결"이라는 개념을 사용합니다. 그러나 정확하게 연결이란 무엇입니까?Typically, people/ speak /of a TCP connection once there has been a handshake between two endpoints (say, the browser or client and the server).
일반적으로 사용자들은 두 엔드포인트(예: 브라우저 또는 클라이언트와 서버) 간에 handshake가 이루어지면 TCP 연결에 대해 말합니다.This is why UDP is often (somewhat misguidedly) said to be “connectionless”, because it doesn’t do such a handshake.
UDP가 그런 handshake를 하지 않기 때문에 종종 (다소 잘못된) "연결 없음"이라고 말하는 이유입니다.However, the handshake is really nothing special: It’s just a few packets with a specific form being sent and received.
그러나, 이 핸드쉐이크는 특별한 것이 아닙니다: 그것은 단지 특정 형태의 패킷이 몇 개만 송수신됩니다.
It has a few goals, main among them being to make sure there is something on the other side and that it’s willing and able to talk to us.
그것은 몇 가지 목표를 가지고 있는데, 그 중 주요 목표는 반대쪽에 무언가가 있는지 확인하고 우리와 대화할 수 있도록 하는 것입니다.
It’s worth repeating here that QUIC also performs a handshake, even though it runs over UDP, which by itself doesn’t.
이곳에서 다시 한 번 강조할 가치가 있는 것은 QUIC이 UDP 위에서 실행되지만 UDP 자체는 그렇지 않아도 QUIC이 핸드셰이크를 수행한다는 점입니다.
So, the question becomes, how do those packets arrive at the correct destination?
그렇다면 문제는 저 패킷이 정확한 목적지에 어떻게 도착하는지 입니다.
On the Internet, IP addresses are used to route packets between two unique machines.
인터넷상에서 IP 주소는 두개의 고유한 시스템 간의 패킷을 라우팅하는데 사용됩니다.
However, just having the IPs for your phone and the server/ isn’t/ enough, because both want to be able to run multiple networked programs at each end simultaneously.
그러나 전화기와 서버에 대한 IP만 가지고는 충분하지 않습니다. 왜냐하면 둘 다 각 엔드에서 여러 네트워크 프로그램을 동시에 실행할 수 있기를 원하기 때문입니다.
This is why each individual connection is also assigned a port number on both endpoints to differentiate connections and the applications they belong to.
이 때문에 각 개별 연결에는 연결과 해당 연결이 속한 응용 프로그램을 구별하기 위해 양쪽 엔드포인트에 포트 번호도 할당됩니다.
Server applications typically have a fixed port number depending on their function (for example ports 80 and 443 for HTTP(S), and port 53 for DNS), while clients usually choose their port numbers (semi-)randomly for each connection.
서버 응용 프로그램은 일반적으로 기능에 따라 고정된 포트 번호(예: HTTP(S)의 경우 포트 80 및 443, DNS의 경우 포트 53)를 가지며, 클라이언트는 일반적으로 각 연결에 대해 포트 번호를 무작위로 선택합니다.
(As such, to define a unique connection across machines and applications), we/ need these four things, the so-called 4-tuple: client IP address + client port + server IP address + server port.
따라서 시스템과 애플리케이션 간에 고유한 연결을 정의하려면 클라이언트 IP 주소 + 클라이언트 포트 + 서버 IP 주소 + 서버 포트 등 4가지가 필요합니다.
In TCP, connections are identified by just the 4-tuple.
TCP에서 연결은 4-튜플만으로 식별됩니다.
So, if just one of those four parameters changes, the connection becomes invalid and needs to be re-established (including a new handshake).
따라서 이 네 개의 매개 변수 중 하나만 변경되면 연결이 무효화되고 (새 핸드셰이크를 포함하여) 다시 설정해야 합니다.
To understand this, imagine the parking-lot problem:
이를 이해하려면 주차장 문제를 상상해 보십시오.
You are currently using your smartphone inside of a building with Wi-Fi.
현재 Wi-Fi가 있는 건물 안에서 스마트폰을 사용하고 있습니다.
As such, you have an IP address on this Wi-Fi network.
따라서 이 Wi-Fi 네트워크에 IP 주소가 있습니다.
If you now move outside, your phone might switch to the cellular 4G network.
이제 외부로 이동하면 휴대폰이 셀룰러 4G 네트워크로 전환될 수 있습니다.
Because this is a new network, it will get a completely new IP address, because those are network-specific.
이것은 새로운 네트워크이기 때문에 완전히 새로운 IP 주소를 얻을 것입니다. 왜냐하면 그것들은 네트워크 고유의 것이기 때문입니다.
Now, the server will see TCP packets coming in from a client IP that it hasn’t seen before (although the two ports and the server IP could, of course, stay the same).
이제 서버는 이전에 보지 못한 클라이언트 IP에서 TCP 패킷이 들어오는 것을 볼 수 있습니다(물론 두 포트와 서버 IP는 동일하게 유지될 수 있습니다).
This is illustrated below.
이것은 아래에 설명되어 있습니다.
But how can the server know that these packets from a new IP belong to the “connection”?
그러나 서버는 어떻게 새로운 IP의 이러한 패킷이 "연결"에 속한다는 것을 알 수 있습니까?
How does it know these packets don’t belong to a new connection from another client in the cellular network that chose the same (random) client port (which can easily happen)?
이것은 다른 클라이언트가 동일한 (임의의) 클라이언트 포트를 선택한 이동 통신망에서 새 연결에 해당하지 않는 패킷인지 어떻게 알 수 있습니까? (이것은 쉽게 발생할 수 있습니다).
Sadly, it cannot know this.
슬프게도, 그것은 이를 알 수 없습니다.
Because TCP was invented before we were even dreaming of cellular networks and smartphones, there is, for example, no mechanism that allows the client to let the server know it has changed IPs.
TCP는 우리가 셀룰러 네트워크와 스마트폰을 꿈꾸기도 전에 발명되었기 때문에 예를 들어 클라이언트가 IP를 변경했다는 것을 서버에 알릴 수 있는 메커니즘이 없습니다.
There isn’t even a way to “close” the connection, because a TCP reset or fin command sent to the old 4-tuple wouldn’t even reach the client anymore.
이전 4-튜플로 전송된 TCP 리셋 또는 핀 명령이 더 이상 클라이언트에 도달하지 못하기 때문에 연결을 "닫을" 수 있는 방법도 없습니다.
As such, in practice, every network change means (that existing TCP connections can no longer be used).
따라서 실제로 모든 네트워크 변경은 기존 TCP 연결을 더 이상 사용할 수 없음을 의미합니다.
원글: https://www.smashingmagazine.com/2021/08/http3-core-concepts-part1/
