Chapter 4. Connection Management
(해석 또는 이해가 잘못된 부분이 있다면 댓글로 편하게 알려주세요.)
❤️ 원문 번역 ❤️
Parallel Connections
As we mentioned previously, a browser could naively process each embedded object serially by completely requesting the original HTML page, then the first embedded object, then the second embedded object, etc. But this is too slow!
-
앞에서 이야기했듯이 브라우저는 원본 HTML 페이지를 완전히 요청한 후 각각의 임베디드 객체를 첫 번째부터 순차적으로 직렬 프로세싱합니다.
-
하지만 직렬 방식은 너무나도 느립니다.
HTTP allows clients to open multiple connections and perform multiple HTTP transactions in parallel, as sketched in Figure 4-11. In this example, four embedded images are loaded in parallel, with each transaction getting its own TCP connection.
-
HTTP는 Figure 4-11과 같이 클라이언트가 여러 개의 연결을 생성하고 여러 개의 HTTP 트랜잭션을 병렬적으로 수행할 수 있게합니다.
-
이 예시에서 4개의 임베디드 이미지는 각각의 트랜잭션이 고유한 TCP 연결을 통해 병렬로 로딩됩니다.
Parallel Connections May Make Pages Load Faster
Composite pages consisting of embedded objects may load faster if they take advantage of the dead time and bandwidth limits of a single connection. The delays can be overlapped, and if a single connection does not saturate the client’s Internet bandwidth, the unused bandwidth can be allocated to loading additional objects.
-
단일 연결에 대해 데드 타임과 대역폭 제한을 활용하여 임베디드 객체로 구성된 복합 페이지를 더 빠르게 로딩할 수 있습니다.
** 데드타임 : 객체를 로딩하는 대기 상태 -
지연은 중첩될 수 있고, 만약 단일 연결이 클라이언트의 인터넷 대역폭을 가득 채우지 않는다면 사용되지 않는 대역폭이 추가 객체를 로딩하는 데 할당될 수 있습니다.
Figure 4-12 shows a timeline for parallel connections, which is significantly faster than Figure 4-10. The enclosing HTML page is loaded first, and then the remaining three transactions are processed concurrently, each with their own connection.* Because the images are loaded in parallel, the connection delays are overlapped.
-
Figure 4-12는 병렬 연결의 타임라인을 보여줍니다. 병렬 연결은 Figure 4-10에 비해 확실히 더 빠릅니다.
-
가장 먼저 전체 HTML 페이지가 로딩되고, 나머지 3가지 트랜잭션은 각각의 고유한 연결에서 병렬 프로세싱됩니다.
-
이미지는 병렬로 로딩되기 때문에, 연결 지연이 중첩됩니다.
Parallel Connections Are Not Always Faster
Even though parallel connections may be faster, however, they are not always faster. When the client’s network bandwidth is scarce (for example, a browser connected to the Internet through a 28.8-Kbps modem), most of the time might be spent just transferring data. In this situation, a single HTTP transaction to a fast server could easily consume all of the available modem bandwidth. If multiple objects are loaded in parallel, each object will just compete for this limited bandwidth, so each object will load proportionally slower, yielding little or no performance advantage.
-
병렬 연결이 대체로 빠르기는 하나 항상 빠른 것은 아닙니다.
-
클라이언트의 네트워크 대역폭이 매우 작을 때(28.8Kbps 모뎀을 통해 인터넷에 연결된 브라우저), 대부분의 시간은 데이터를 전송하는 데 소요될 것입니다.
-
이와 같은 상황에서는 빠른 서버로 향하는 하나의 HTTP 트랜잭션이 이용 가능한 전체 모뎀 대역폭을 쉽게 소비할 수 있습니다.
-
만약 여러 개의 객체가 병렬로 로딩되면 각각의 객체는 제한된 대역폭을 차지하기 위해 경쟁할 것입니다. 따라서 객체들이 부분적으로 더 느리게 로딩되어 성능적 이점을 거의 얻지 못합니다.
Also, a large number of open connections can consume a lot of memory and cause performance problems of their own. Complex web pages may have tens or hundreds of embedded objects. Clients might be able to open hundreds of connections, but few web servers will want to do that, because they often are processing requests for many other users at the same time. A hundred simultaneous users, each opening 100 connections, will put the burden of 10,000 connections on the server. This can cause significant server slowdown. The same situation is true for high-load proxies.
-
또한 열린 연결의 수가 많을수록 메모리를 많이 소비하여 자체적으로 성능 문제를 일으킵니다.
-
복잡한 웹 페이지는 수십 혹은 수백 개의 임데디드 객체를 가지고 있을지도 모릅니다.
-
그러나 클라이언트가 수백 개의 연결을 열 수 있다 하더라도 웹 서버는 이것을 원치 않습니다. 웹 서버는 동시에 수많은 다른 유저들의 요청을 처리하기 때문입니다.
-
백 명에 유저가 동시에 100개의 연결씩 연다면 서버에는 10000개의 연결 뭉치가 들어오게 됩니다.
-
이것은 서버의 속도를 심각하게 저하시킵니다.
-
동일한 상황은 로드량이 많은 프록시에서도 발생합니다.
In practice, browsers do use parallel connections, but they limit the total number of parallel connections to a small number (often four). Servers are free to close excessive connections from a particular client.
-
실제로 브라우저는 병렬 연결을 사용하지만 전체 병렬 연결의 숫자를 작은 수(통상 4개)로 제한합니다.
-
서버는 특정 클라이언트로부터의 과도한 연결을 자유롭게 닫을 수 있습니다.
Parallel Connections May “Feel” Faster
Okay, so parallel connections don’t always make pages load faster. But even if they don’t actually speed up the page transfer, as we said earlier, parallel connections often make users feel that the page loads faster, because they can see progress being made as multiple component objects appear onscreen in parallel. Human beings perceive that web pages load faster if there’s lots of action all over the screen, even if a stopwatch actually shows the aggregate page download time to be slower!
-
이제 병렬 연결이 항상 페이지 로딩을 빠르게 만드는 것은 아니라는 사실을 알았습니다.
-
하지만 병렬 연결이 실제 페이지 전송의 속도를 높이는 것은 아닙니다. 앞서 이야기한 것처럼 병렬 연결은 보통 유저 입장에서 페이지 로딩이 더 빠르게 느껴지도록 만드는 것입니다. 유저가 여러 개의 컴포넌트 객체가 화면에 동시에 생성되는 과정을 볼 수 있기 때문입니다.
-
사람은 전체 스크린에 많은 동작이 이루어질 때 로딩 속도가 더 빠르다고 인식합니다. 실제로 스톱워치가 전체 페이지를 다운로드 하는 시간이 더 느려지는 것을 보여주더라도 이러한 인식은 변하지 않습니다.
🧡 요약 정리 🧡
Parallel Connections
-
클라이언트가 여러 개의 연결을 생성하고 여러 개의 HTTP 트랜잭션을 병렬적으로 수행
-
실제 전송 속도에는 변화 X
-
장점 : 지연 중첩 -> 여러 객체를 동시 로딩 가능 (유저 입장에서 여러 컴포넌트 객체가 화면에 동시 생성되어 로딩이 빠르게 느껴진다)
-
한계 : 네트워크의 대역폭이 매우 작을 때 효과적으로 작동 X, 연결의 수가 많아지면 여러 클라이언트의 요청을 받는 서버의 속도 저하, CPU와 메모리 낭비
💛 감상 💛
-
고봉밥 텍스트를 겪고 나니 이제는 그냥 그림이 있는 것에 감사하기로 했습니다!!
-
교수님께서 병렬 연결이 항상 좋은 것은 아니라며 스쳐 지나가듯이 이야기했던 것이 정확히 무슨 의미였는지 알게 되었습니다. 만약 Parallel이 그 자체로 이미 훌륭한 기술이었다면 Multiplexing이 고안되지 않았을 겁니다.
-
나온 지가 꽤 오래된 책인데 HTTP 연결에 대해 어떻게 이렇게 다양한 최적화 방안을 떠올렸는지 신기할 따름입니다.
