[Economist] World Wide Wait

World Wide Wait

Feb 12th 2010 |
From The Economist online

The faster the internet becomes, the slower it loads pages
인터넷이 빨라질수록 페이지 로드 시간은 길어진다

최근의 웹 페이지들을 불러오는데 얼마나 오래 걸리는지 신경 써 본적이 있는가? 하나의 링크를 클릭하고 기다리고, 또 기다리고, 조금 더 기다리면 내용이 찔끔찔끔 표시된다. 만약 10초 정도 이후까지 아무 일이 일어나지 않는다면 참을성 없는 필자는 브라우져의 Stop 버튼을 누르고 Reload 버튼을 누른다. 필사적인 상태에서는 같은 링크를 두 번째 탭, 혹은 세 번째 탭에서까지 로드 해보고 웹 사이트의 서버에 페이지를 위한 다수의 요청을 퍼붓는다. 만약 그마저 실패한다면 넌더리를 내며 포기하고 대신 신문을 읽는다.

인터넷의 초창기 시절, 대부분의 웹 유저들이 전화선 연결에 의존하던 시절에는 브라우저는 부가적인 것이 없었으며, 웹 그래픽은 투박한 GIF 파일이었고, 8초가 사람들이 원하는 페이지가 로드 될 때까지 기다리는 시간의 최대치로 여겨졌다. 사람들을 다른 곳으로 발길을 돌리지 않도록 하기 위해 웹 디자이너들은 HTML 코드를 핵심만 남기고 가볍게 만들었고, 스타일시트 데이터나 자바 스크립트를 다른 곳에 하나의 파일로 모아 더 효과적으로 캐시할 수 있게 하고, 이미지는 적게 사용하고 더 작은 크기를 가지는 PNG나 JPEG과 같은 파일을 사용 가능하게 되자마자 즉시 수용했다. 텍스트와 비교하면 사진은 최소 1000단어와 동일한 전송 시간이 필요하다.

필자가 이코노미스트의 첫 번째 웹 사이트를 작성했던 1994년에는 일반적인 웹 페이지는 50킬로바이트 근처의 크기였고, 전화선을 이용한 모뎀은 1초에 3킬로바이트 이상을 전송할 수 없었다. “8초 규칙”을 지키기 위해서 사진은 최소한으로 사용되어서 어떤 페이지도 로딩을 시작하는데 3~4초 이상 걸리지 않았고, 완료 시 까지 20초가 걸리지 않았다. 아이러니한 것은 광대역이 널리 사용 가능하게 되어 전체적인 접속 속도가 급격히 늘어나고 있는 와중에도 웹 페이지를 로드 하는데 걸리는 시간은 더 늘어난 것처럼 보인다는 것이다.

필자는 DSL 연결이 수명을 다해간다는 사실을 인정한다. 하지만 지역 전화 교환기로부터 5km 떨어진 곳에서도 광대역 접속 속도는 과거 몇 년 동안 지역 회선이 개선되고 반향 제거 코일 같은 과거의 시설들이 접속 배전함에서 제거 됨으로써 초당 65킬로바이트에서 90킬로바이트로 증가했다. 

물론, 필자는 초당 650킬로바이트 이상의 속도를 케이블을 통해 얻을 수 있다. 하지만 그것은 멋진 위성-TV 서비스를 버려야 하는 것을 의미한다. 이뿐 아니라 광 케이블은 내가 살고 있는 언덕까지 설치되려면 아직도 멀었다. 만약 현재의 DSL 연결을 위해 매달 내는 21불 대신 140불을 지불하면 초당 6메가 이상으로 인터넷에 접속할 수 있게 될 것이다.

70배의 속도 증가에 비해서 7배의 가격 상승은 할인으로 보인다. 하지만 필자는 순수한 속도의 증가가 가차없이 엄격한 로딩 문제를 해결할 수 있을지 의문이다. 비록 못미더운 DSL 연결로도 일단 웹 사이트의 서버가 ( 그리고 그 경로에 있는 모든 컴퓨터와 광고, 그래픽, 그 외의 잡다한 레이아웃을 위해 사용되는 컴퓨터들 ) 브라우저의 요청에 반응하기 시작하면 페이지들은 충분히 빨리 보여진다. 문제는 우선 서버로부터 응답을 받아내는 것이다.

두 컴퓨터가 서로 정보를 교환하기 전에 그들은 서로 이야기하는 것에 동의해야 한다. 일반적인 경우, 이는 사용자의 컴퓨터가 호스트 컴퓨터에 요청을 보내야 하고 이에 대한 응답이 다시 사용자에게 전달되어야 한다. 오직 이 “핸드쉐이킹” 과정 이후에야 정보의 교환이 시작된다. 이 왕복의 요청과 응답에 걸리는 시간이 네트워크의 대기 시간을 결정한다.

이 대기 시간은 전자기 신호가 왕복해야 할 거리를 광속으로 나눈 것 이하로 줄어들 수는 없다. 예를 들어, 필자는 샌프란시스코의 동료로부터 400마일이 떨어진 로스엔젤레스의 집에 산다. 이론상으로는 이 두 장소를 왕복하는 최소 시간은 4.3 밀리세컨드이다. 하지만 보통 다른 컴퓨터에 “Ping”을 보낼 때, 왕복 시간은 일반적으로 700 밀리세컨드이다. 이것도 꽤나 빠른 속도이지만 얼마나 많은 시간이 요청을 처리하기 위한 다양한 서버들을 기다리는데 필요한지 보여준다.

메시지들이 꼼짝 없이 붙들려 있어야 하는 곳들이 전송되는 길 곳곳에 있다. 라우팅 서버에서는 데이터가 트래픽에 따라 목적지를 향해 서로 다르게 분배되어야 하는 큐가 점점 길어질 수 있다. 그중 최악은 ISP 쪽의 DNS라 불리는 도메인 네임 서버가 이용자가 방문하고자 하는 사이트(예를 들어 www.economist.com)를 실제 인터넷 주소(216.35.68.215)로 변환하느라 정신이 없이 바쁜 상황이다. 만약 안다면, 웹 사이트의 실제 숫자 주소를 장황한 URL 이름 대신에 시도해보라. 응답시간을 절반으로 줄일 수도 있다.

DNS 변환에서든, 라우팅 컴퓨터에서든, 아니면 호스트 서버 자체에서든 이러한 병목 현상들은 대부분 인프라가 처리할 수 있는 것 이상으로 인터넷 트래픽이 혼합되는 양상이 변해온 것에 기인한다. 한때 단지 50킬로바이트의 텍스트와 조그만 그림들로 이루어졌던 웹 사이트가 현재에는 음악, 비디오와 애니메이션으로 이루어진다. 유투브, Hulu, 아이튠즈, 비트 토런트도 이러한 문제를 겪고 있다.

이동 통신사의 사설 망에서 문제는 더 심각해진다. 통신사들은 가입자들의 스마트폰을 사용하면서 페이스북을 확인하고 유투브에서 비디오를 보고, 대화형 게임을 하는 등, 요구를 맞춰주기 위해 노력하고 있다. 중간 범위의 스마트폰들은 보통 한 달에 100메가바이트 정보의 데이터를 소비하지만, 완벽한 브라우징 환경과 수 천 개의 다운로드형 어플리케이션을 갖춘 더 발전된 애플의 아이폰이나 모토롤라의 드로이드 같은 모델에서는 한 달에 500메가바이트 이상을 소비하는 경향이 있다. 곧 출시가 임박한 무선 모뎀을 갖춘 아이패드 같은 태블릿 컴퓨터에서는 다운로드 데이터 사용량이 한 달에 1기가바이트에 달할 수도 있다. (이번주 비지니스 섹션의 lead story 참고)

그리고 이것은 단지 시작에 불과하다. 인터넷의 상황을 보면, UCLA에 의해 운영되는 네트워크 기상 보고에 따르면 미국 기업의 웹 사이트들의 평균 지연시간은 현재 350ms 근처이다. 구글의 지연시간이 150ms, 페이스북이 285ms, 그리고 유투브가 515ms이다. 영상회의, 고해상도 실시간 비디오, 원격 수술 등 다음 세대의 인터넷 어플리케이션들이 구현되기 위해서 이러한 지연시간들은 상당한 양 짧아질 필요가 있다.

미래는 매혹적이다. Netflix는 Full-HD 사진의 해상도(1080p라 불리는, 사진에 총 1080의 선을 가진)와 5.1 채널의 입체음향을 가지는  주문형 실시간 비디오 서비스를 제공할 것이라고 발표했다. 깨끗하고, 조밀한 영상과 선명한 음질을 구현하기 위해서는 각 회선당 1초에 1메가의 대역폭과 60ms 이하의 지연시간이 요구된다.

인터넷 서비스 제공자들에게 이는 투자를 상당히 증가 시킨다는 것을 의미한다. 하지만 엄청나게 많은 라우터를 인터넷에 추가하는 것은 일을 더 복잡하게 만들 뿐 지연시간 문제를 해결 하는 데는 별 도움이 안될 수 있다. 무엇을 하든, 그것은 사실 잠재적인 병목현상의 수를 증가시킬 수 있다. 닷컴 붐으로 잘 나가던 시절에 설치되었지만 10여 년 전 거품이 꺼진 뒤부터 거리 지하에 방치되어있는 “Dark fiber”를 사용하는 것이 더 나은 해결책일 것이다. 이는 다수의 보안 회사들이 조용히 진행하던 일이었다. 자동화된 주식거래에서 1밀리초를 단축하는 일이 100만불의 수익증가를 불러오는 이 상황에서 지연시간이 0에 가까운 사설 광 네트워크를 구축하는 것은 충분히 매력적이다.

사실, 구글은 이번 주 통신사들이 새로운 광 인터넷을 구축하기를 기다리며 시간을 허비하지 않겠다고 발표했다. 구글은 초당 100메가바이트를 50,000에서 500,000명의 사람들에 제공 가능한 낮은 지연시간을 가지는 광 네트워크를 만들 계획을 세우고 있다. 운이 좋으면, 다른 모든 인터넷 서비스 제공업체들이 이를 알게 될 것이다.

영어 원문

[#M_ more.. | less.. | 

EVER noticed how long it takes for web pages to load these days? You click on a link and wait and wait, and then wait some more, for the content to trickle in. If nothing has happened after ten seconds or so, your impatient correspondent hits the browser’s stop button followed by the reload key. In desperation, he sometimes loads the link into a second or even a third browser tab as well, and bombards the website’s server with multiple requests for the page. If that fails, he gives up in disgust and reads a newspaper instead.

Back in the early days of the internet, when most web users relied on dial-up connections, browsers were crude and web graphics were clumsy GIF files, eight seconds was considered the maximum people would stick around for a page to load. To increase “stickiness”, web designers pared their HTML code to the bone, collated their style-sheet data and JavaScripts into single files for more efficient caching elsewhere on the web, used fewer graphics and embraced the PNG and JPEG picture formats, with their smaller file sizes, as soon as they became available. Compared with text, pictures really were the equivalent of 1,000 words, at least when it came to the time taken to transmit them.

When your correspondent hand-coded The Economist’s first website back in 1994, a typical web page was about 50 kilobytes in size and dial-up modems could transfer no more than three kilobytes a second. To stay under the “eight-second rule”, pictures were kept to a minimum, so no page took more than three or four seconds to begin loading and never longer than 20 seconds to complete. The irony is that, with broadband nowadays more or less everywhere, overall connection speeds have gone up by leaps and bounds, yet the time taken to load web pages seems only to have got longer.

Your correspondent is admittedly near the end of the road for a digital subscriber line (DSL) connection. But even at three miles (5km) from the local telephone exchange, the speed of his broadband connection has inched up over the past few years from 65 kilobytes a second to more than 90 kilobytes a second—as the local line has been tweaked and legacy equipment like echo-cancelling coils removed from its junction boxes.

Sure, he could get 650 kilobytes a second or more from a cable connection. But that would mean ditching his otherwise excellent satellite-TV service. Besides, optical fibre is slowly working its way up his hillside. He could soon have access to the internet at more than six megabytes a second—providing he is prepared to pay $140 a month instead of $21 for his existing DSL connection.

A 70-fold increase in speed for a sevenfold increase in price would seem a bargain. But your correspondent is not sure that more raw speed will solve the glacial loading problem. Even with his wimpy DSL connection, pages are rendered quickly enough once the website’s servers (and all the other computers along the route, plus those used to host adverts, graphics and miscellaneous layout bits) start giving his browser’s request some attention. The trouble is getting their attention in the first place.

Before two computers can exchange information, they have to agree to talk to one another. Under normal conditions, this requires the user’s computer to send a request to the host computer, which then sends a response back to the user. Only after this “handshaking” is complete can the exchange of data commence. The time taken for this round-trip of request and acknowledgment determines the network’s latency.

The latency cannot be less than the distance the electromagnetic signal has to travel divided by the speed of light. For instance, your correspondent’s home in Los Angeles is 400 miles from a colleague’s in San Francisco. In theory, then, the shortest round-trip between the two locations is 4.3 milliseconds. But if you “ping” the other computer, you’ll get a round-trip time of typically 700 milliseconds. That is still pretty quick, but it shows just how much time is spent waiting around for the various servers involved to handle the request.

There are many places along the way where the message can get bogged down. Queues can build up at routing servers that switch data packages along different routes to their destinations depending on the traffic. Worst of all, the DNS (Domain Name Server) computers used by your ISP can be overwhelmed as they try to translate the names of all the websites subscribers want to visit (say, www.economist.com) into their actual internet addresses (216.35.68.215). If you know it, try using the website’s numerical address rather than its verbose URL (Universal Resource Locator) name. That can sometimes halve the response time.

The bottlenecks—whether at the DNS translators, the routing computers or the host’s own servers—stem largely from the way the mix of internet traffic has changed faster than the infrastructure used to carry it. Websites that were once just 50 kilobytes of text and tiny pictures now come with music, video and animated graphics. YouTube, Hulu, iTunes and BitTorrent have much to answer for.

It is even worse on the mobile phone companies’ proprietary networks. Carriers are struggling to keep up with demand as subscribers use their smart-phones to check Facebook, stream videos from YouTube and play interactive games. Where a mid-range smart-phone would consume about 100 megabytes of data a month, more advanced models like the Apple iPhone or Motorola Droid, with fully fledged browsers and access to thousands of downloadable applications, tend to consume over 500 megabytes a month. With the imminent arrival of tablet computers like the iPad, which come with wireless modems, the appetite for downloadable data could hit a gigabyte a month (see the lead story in this week’s Business section).

And this is just the beginning. On the internet, the average latency for corporate websites in America is currently around 350ms, according to the Network Weather Report operated by the University of California, Los Angeles. Google’s latency is 150ms, Facebook’s 285ms and YouTube’s 515ms. Such latencies will have to come down considerably if the next generation of internet applications, such as telepresence, high-definition video streaming and remote surgery, are to fulfil their promise.

The future is beckoning. Netflix has just announced an on-demand video-streaming service offering full high-definition picture quality (so-called 1080p, which has 1,080 lines in its picture) with 5.1-channel surround sound. Each stream being watched will require a megabyte a second of bandwidth and a latency of less than 60ms if it is to deliver crisp, pin-sharp video and pristine sound.

For the internet service providers, that means stepping up investment substantially. But adding a lot more routers to the internet would complicate matters hugely and do little to solve the latency problem. If anything, it would actually increase the number of potential bottlenecks.

A better solution might be to light up more of the “dark fibre” installed during the heady days of the dotcom boom, but left lying unused beneath the streets since the bubble burst nearly a decade ago. That is what a number of securities firms have been quietly doing. When shaving a millisecond off the time needed to execute automated trades can increase revenue by $100m, there is plenty of incentive to build private optical networks with latencies approaching zero.

Indeed, Google said this week that it was not going to hang around waiting for the telecoms industry to build the new optical web. The company is planning a low-latency fibre network that will be capable of delivering speeds of over 100 megabytes a second for communities of 50,000-500,000 people. With luck, other internet service providers everywhere will get the message.

_M#]