QUIC KNOWS ABOUT MULTIPLE BYTE STREAMS
The second big difference between TCP and QUIC /is/ a bit more technical, and we/ will explore/ its repercussions in more detail in part 2.
TCP와 QUIC의 두번째 큰 차이점은 조금 더 기술적 입니다. 그리고 우리는 그 영향을 더 자세히 살펴볼 겁니다 파트2에서.
For now, though, we/ can understand/ the main aspects in a high-level way.
그러나 현재로서는 주요 측면을 높은 수준으로 이해할 수 있습니다.
Did You Know?
Consider first that even a simple web page / is made up / (of a number of independent files and resources).
먼저 간단한 웹 페이지조차도 여러 개의 독립적인 파일과 자원으로 이루어져 있다고 고려해보세요.
There’s HTML, CSS, JavaScript, images, and so on.
HTML, CSS, 자바스크립트, 이미지 등이 있습니다.
Each of these files / can be seen / (as a simple “binary blob”) a collection of zeroes and ones (that are interpreted in a certain way by the browser).
이러한 각 파일은 브라우저에 의해 특정한 방식으로 해석되는 0과 0의 집합인 단순한 "이진 블롭"으로 볼 수 있습니다.
When sending these files over the network, we don’t transfer them all at once.
이러한 파일을 네트워크를 통해 전송할 때 한 번에 모두 전송하지 않습니다.
Instead, they are subdivided into smaller chunks (typically, of about 1400 bytes each) and sent in individual packets.
대신, 그들은 더 작은 청크로 나뉘어져 있고 (일반적으로, 각각 약 1400바이트), 개별 패킷으로 전송됩니다.
As such, we/ can view /(each resource (as being) a separate “byte stream”), as data is downloaded or “streamed” piecemeal over time.
따라서 시간이 지남에 따라 데이터가 다운로드되거나 조각별로 "스트리밍"되기 때문에 각 리소스를 별도의 "바이트 스트림"으로 볼 수 있습니다.
For HTTP/1.1, (the resource-loading process) / is quite simple,/ because each file is given its own TCP connection and downloaded in full.
HTTP/1.1의 경우 각 파일에 자체 TCP 연결이 부여되고 전체적으로 다운로드되기 때문에 리소스 로드 프로세스가 매우 간단합니다.
For example, if we have files A, B, and C, we would have three TCP connections.
예를 들어, 파일 A, B, C가 있다면 TCP 연결이 세 개일 것입니다.
The first would see a byte stream of AAAA, the second BBBB, the third CCCC (with each letter repetition being a TCP packet).
첫 번째는 AAAA의 바이트 스트림, 두 번째는 BBB, 세 번째는 CCCC입니다(각각의 문자 반복은 TCP 패킷입니다).
This works but is also very inefficient because each new connection has some overhead.
이것은 작동하지만 각 새 연결에 약간의 오버헤드가 있기 때문에 매우 비효율적입니다.
In practice, browsers/ impose/ (limits on how many concurrent connections may be used) (and thus how many files may be downloaded in parallel) — typically, between 6 and 30 per page load.
일반적으로 브라우저는 페이지 로드당 6~30개의 파일을 병렬로 다운로드할 수 있는 동시 연결 수에 제한을 가합니다.
Connections/ are then reused to download a new file once the previous has fully transferred.
그런 다음 이전 파일이 완전히 전송되면 연결을 다시 사용하여 새 파일을 다운로드합니다.
These limits eventually started to hinder web performance on modern pages, which often load many more than 30 resources.
이러한 제한은 결국 30개 이상의 리소스를 로드하는 최신 페이지의 웹 성능을 저해하기 시작했습니다.
Improving this situation /was /one of the main goals for HTTP/2.
이러한 상황을 개선하는 것이 HTTP/2의 주요 목표 중 하나였습니다.
The protocol/ does/ this by no longer opening a new TCP connection for each file, but instead downloading the different resources over a single TCP connection.
프로토콜은 더 이상 각 파일에 대해 새로운 TCP 연결을 열지 않고 단일 TCP 연결을 통해 다른 리소스를 다운로드함으로써 이를 수행합니다.
This/ is achieved/ by “multiplexing” the different byte streams.
이는 서로 다른 바이트 스트림을 "다중화"함으로써 달성됩니다.
That’s a fancy way of saying that we / mix/ data of the different files (when transporting it).
전송할 때 서로 다른 파일의 데이터를 혼합한다는 멋진 표현입니다.
For our three example files,/ we/ would get/ a single TCP connection, and the incoming data might look like AABBCCAABBCC (although many other ordering schemes are possible).
세 개의 예제 파일의 경우 단일 TCP 연결이 가능하며 수신 데이터는 AABBCCAABBCC처럼 보일 수 있습니다(다른 많은 주문 방식도 가능하지만).
This seems simple enough /and indeed works quite well, making HTTP/2 typically just as fast or a bit faster than HTTP/1.1, but with much less overhead.
이것은 충분히 간단해 보이고 실제로 꽤 잘 작동하기 때문에 HTTP/2는 일반적으로 HTTP/1.1과 동일하거나 조금 빠르지만 오버헤드는 훨씬 적습니다.
모르는 단어
repercussions: 반작용
aspects: 관점, 측면
subdivided: 세분화하다
piecemeal: 단편적으로, 조각조각으로
impose: 도입하다, 부과하다, 속이다
concurrent: 동시의
hinder: 방해하다, 저지하다
원글: https://www.smashingmagazine.com/2021/08/http3-core-concepts-part1/
