KR20120062845A

KR20120062845A - 컨텐츠 전송 네트워크를 통한 청크식 다운로드

Info

Publication number: KR20120062845A
Application number: KR1020127007982A
Authority: KR
Inventors: 그레고르 엔. 퍼디 에스알.
Original assignee: 애플 인크.
Priority date: 2009-08-28
Filing date: 2010-08-17
Publication date: 2012-06-14
Also published as: CN102484652A; KR101424362B1; EP2454868A1; WO2011025694A1; US20110055312A1; JP5514315B2; JP2013503390A

Abstract

파일은 CDN로부터 집합적으로 전체 파일을 이루는 일련의 바이트 범위들 또는 청크들의 형태로 다운로드 된다. 클라이언트 컴퓨터는 첫번째로 DNS(domain name server)로부터 서버 주소를 요청함으로써 CDN로부터 파일을 요청할 수 있으며, 이는 다운로드 요청에 대한 서비스를 제공할 하나보다 많은 서버를 반환함으로써 청크들 형태의 파일의 다운로딩을 촉진할 수 있다. 대안적으로, DNS 서버는 클라이언트에게 DNS서버로부터 파일의 각각의 바이트 범위를 개별적으로 요청하도록 지시할 수 있어, 그 DNS 서버는 가장 바람직한 서버로 그 요청을 개별적으로 지향시킬 수 있다. 대안적으로, DNS에 의해 반환된 서버는 일련의 바이트 범위들에 대한 서비스를 동시에 제공하기 위해 일련의 범위들에 대한 요청들을 다른 서버들에 재지향 시킬 수 있다.

Description

컨텐츠 전송 네트워크를 통한 청크식 다운로드{CHUNKED DOWNLOADS OVER A CONTENT DELIVERY NETWORK}

본 출원은 그 전체가 참조로서 본 명세서에 통합되고, 2009년 8월 28일에 출원된 발명의 명칭이 "CHUNKED DOWNLOADS OVER A CONTENT DELIVERY NETWORK"인 미국특허출원번호 제12/550,190 호의 우선권을 주장한다.

본 기술은 컨텐츠 전송 네트워크(content delivery network)로부터 파일을 다운로드하는 것에 관한 것이고, 더 상세하게는 컨텐츠 전송 네트워크로부터, 집합하여 전체의 파일을 이루는, 복수의 바이트 범위들(byte ranges)을 동시에 다운로드하는 것에 관한 것이다.

인터넷은 매체, 소프트웨어, 애플리케이션들 및 다른 파일들과 컨텐츠를 배포하는데 흔히 사용된다. 업체들 및 다른 컨텐츠 공급자들은 다운로드를 위한 여러 파일들을 제공한다. 예를 들어, 연예 산업에서, 고객들은 그들의 컴퓨터에 다운로드 하기 위한 음악 또는 영화들을 구매할 수 있다. 소프트웨어 산업에서, 고객들 및 사용자들은 그들의 컴퓨터에 다운로드 하기 위한 소프트웨어 및/또는 업그레이드들을 구매할 수 있다. 그러나, 고객들 및 사용자들이 그러한 파일들을 다운로드하기 위해, 파일들은 온라인으로 호스트되어 있어야만 한다. 공급자가 공급하는 컨텐츠를 그가 호스트하는 것이 일반적이다. 그러나, 공급자가 수많은 사용자들이 다운로드 하기를 원하는 유명한 파일을 호스트한다면, (사용자들에 대해 요청된 데이터의 실제 전송을 수행하는) 공급자의 웹 서버는 모든 방대한 요청들 및 전송들 때문에 느려질 수 있다. 따라서, 공급자들이 그들의 파일을 배포하기 위해 Akamai와 같은 CDN(Content Delivery Network)을 사용하는 것이 점점 더 흔해지고 있다.

CDN 서버(들)에 파일들을 업로드함으로써 또는 공급자로부터 필요에 따라 파일들을 패치(fetch)하도록 CDN을 구성함으로써, 콘텐츠 공급자는 CDN을 통해 파일을 다운로드 가능하도록 만든다. CDN은 보통 여러 장소에 걸쳐 다수의 웹 서버들을 가지고 있으며, 각각의 웹 서버는 공급자들에 의해 업로드된 파일(들)을 캐쉬하거나, 저장하거나, 또는 어떻게든 그 파일에 대한 액세스를 갖는다. 연관된 특정한 프로토콜들이 시간에 따라 변화할 수 있지만, 현재의 실무에서는, 컨텐츠 공급자로부터 파일을 다운로드 하려는 사용자의 요구는 아래의 단계들에 따라 CDN에 의해 처리된다: 첫째, 사용자의 컴퓨터는 그 파일에 대한 호스트의 IP(Internet Protocol) 주소를 찾기 위한 표준 DNS(Domain Name Service) 쿼리를 만든다. CDN에 의해서 동작되는 DNS 서버들은 이 DNS 쿼리를 처리한다. 그 후, CDN은 컨텐츠 공급자의 웹 서버 대신에, CDN의 웹 서버들 중 어느 하나로부터 사용자가 파일을 다운로드해야 하는지를 결정한다. 둘째, CDN은 선택된 호스트의 IP 주소로 DNS 쿼리에 응답한다. 셋째, 사용자의 컴퓨터상의 소프트웨어는, 그 후, 그 단일 CDN 웹 서버로부터 전체 파일을 다운로드한다. 그러나, CDN의 단일 웹 서버로부터 전체 파일을 다운로드하는 것은 단점들을 갖는다.

CDN과는 다르게, P2P(Peer-To-Peer) 파일 공유 네트워크에서는, 사용자들은 서로에게서 청크 단위로 파일 다운로드를 시도한다. P2P 네트워크에서, 각각의 사용자들은 통상적으로 요청된 파일의 서로 다른 청크들을 다운로드 할 수 있는 다수의 소스(피어)를 찾을 수 있다. 따라서, 다운로드의 유효기간 중에 P2P 소스들 중 하나가 느려지게 되더라도, 사용자로의 전반적인 전송은 현저하게 영향을 받지는 않는다. 그러나, CDN에서는, 사용자는 통상적으로 단일 웹 서버로부터 전체 파일을 다운로드하기 때문에, 그 웹 서버가 (높은 작업 부하와 네트워크 정체 등 때문에) 느려지게 된다면, 다운로드는 현저하게 영향을 받을 것이다(느려지거나 심지어 연결이 끊김). 더욱이, P2P 네트워크에서는, 다운로드를 촉진하기 위해 다른 이용 가능 소스들(피어들)이 활용되는 반면, CDN에서는, 통상적으로 다른 적절한 웹 서버들이 활용되지 않는다. 이런 방식으로, P2P 네트워크에서는 부하가 분산되고 밸런스가 맞춰지지만, 반면 CDN은 이를 구현할 수 없다. 그럼에도 불구하고, P2P 네트워크도 단점들을 갖는다. 업체들 및 다른 컨텐츠 공급자들은 P2P 네트워크와 관련된 부정적인 결점들 때문에 그들의 컨텐츠를 배포하기 위해 P2P 네트워크들을 활용하는 것을 주저한다. P2P 네트워크에서, 컨텐츠의 배포에 대한 제어가 부족하여(예를 들어, 어떠한 피어도 또 다른 피어와 컨텐츠를 공유할 수 있다), 컨텐츠의 불법 사용들(저작권 침해, 불법 복사 등)을 야기할 수 있다. 더욱이, 각각의 특정한 P2P 네트워크에 접속하기 위해 사용자가 부가적인 특정 클라이언트 소프트웨어를 다운로드하지 않는 한, 사용자는 P2P 네트워크를 사용할 수 없으며, 이로 인해 사용자 측에서는 P2P 네트워크를 덜 공정하게 사용하게 된다.

전반적인 다운로드 속도를 개선할 수 있는 방법으로 CDN이 파일들의 분할된 다운로딩을 제공가능하게 하는 솔루션에 대한 필요성이 존재한다.

본 명세서에 개시된 컨셉들의 부가적인 특징들 및 이점들은 후속하는 명세서에 설명되고, 어느 정도는 명세서로부터 명백해지며, 또는 설명된 기술들의 실시에 의해 학습될 수 있을 것이다. 컨셉들의 특징들 및 이점들은 첨부된 청구항들에서 특별하게 지적된 수단들 및 조합들에 의해 실현될 수 있고 만족 될 수 있다. 설명된 기술들의 이런 특징 및 다른 특징들은 후속하는 설명 및 첨부된 청구항들로부터 더 완전히 명백해질 것이며, 또는 본 명세서에 설명된 것과 같이 개시된 컨셉들의 실시에 의해 학습될 수 있을 것이다.

본 명세서는 CDN(Content Delivery Network)으로부터 파일을 청크 단위로 전송하는 컴퓨터 구현된 방법들 및 구성들을 설명한다. 본 명세서에 개시된 것들은 파일을 이루는 바이트들의 범위를 동시에 다운로드함으로써 CDN로부터 파일들을 다운로드 하기 위해 기존의 CDN 시스템들 또는 클라이언트 디바이스들 상의 기존 소프트웨어를 변경하기 위한 실시예들이다.

일부 실시예들에서, 클라이언트들은 종래의 A-레코드에서 지명된 서버의 IP 주소를 요청하고, 그 후에, 반환된 IP 주소로부터 파일을 이루는 바이트들의 범위들을 요청하기 위해 CDN의 기존 DNS(domain name service)를 활용할 것이다. 그러한 실시예들에서, 클라이언트 디바이스들은 원하는 파일의 바이트 범위들에 대해 IP 주소에 의해 식별된 CDN 말단 서버의 반복된 요청들을 만들도록 구성되고, 클라이언트 컴퓨터에 의해 재조립될 청크 형태의 파일의 다운로드를 수신하도록 구성된다.

일부 실시예들에서, DNS는 요청된 다운로드를 제공하기 위한 CDN 말단 서버 후보들에 맵핑된 IP 주소의 리스트를 포함하는 DNS 엔트리의 새로운 형태를 수신하고 반환하도록 구성되었다. 이런 실시예들에서, 클라이언트는 DNS로부터 다중-IP 주소 검색을 요청할 수 있고, DNS는 지명된 서버에 맵핑된 서버들의 모든 IP 주소들의 리스트를 가지는 "청크-레코드(chunk-record)"를 반환할 수 있다. 그 후, 클라이언트는 청크-레코드의 정보를 활용하여 그 안에서 식별된 서버로부터 바이트들의 범위들을 요청할 수 있다. 또다시, 클라이언트는 파일을 포함하는 바이트들의 범위들에 대한 다수의 요청들을 만들도록 구성되고, 클라이언트 컴퓨터에 의해 재조립될 청크 형태의 파일의 다운로드를 수신할 수 있다.

일부 실시예들에서, DNS는 종래의 A-레코드를 반환할 수 있지만, A-레코드에는 다양한 제어부들이 붙어있다. 예를 들어, 이들 실시예들에서, DNS는 짧은 TTL(time-to-live)을 또는 A-레코드의 사용을 제한하기 위한 다른 명령들과 함께 A-레코드를 반환할 수 있다. 클라이언트는 지명된 서버의 IP 주소를 요청할 수 있고, DNS는 충분히 짧은 TTL과 함께 이 정보를 포함하는 A-레코드를 반환할 수 있어서, 식별된 서버의 하나의 요청을 만드는 것만이 유용하다. 이 방법을 이용하여, 청크들로 파일 다운로드를 시도하는 클라이언트는 A-레코드에서 식별된 말단 서버로부터 제1 청크를 요청할 것이나, 후속하는 청크들에 대해서는, 클라이언트는 파일을 이루는 다음 바이트 범위를 제공하기 위해 서버의 IP 주소를 재요청하는 것이 필요할 것이다. 이러한 방식으로, 시스템은 DNS 서버들 내에서 공통인 지능적 라우팅 능력들을 반복적으로 이용할 수 있고, 서버 CDN 말단 서버들에 걸쳐 주어진 파일에 대한 복수의 청크 단위의 요청들의 부하에 대해 균형을 유지할 수 있다.

일부 실시예들에서, CDN 웹 서버들은 다운로드 요청들을 다수의 서버들에 라우팅하는데 사용될 수 있다. 이들 실시예들에서, DNS 서버는 임의의 다른 설명된 실시예들에 대하여 설명된 특성들을 취할 수 있다. 클라이언트는 바이트들의 범위에서 원하는 파일에 대한 요청을 계속적으로 할 수 있으나, CDN 웹 서버들은 다운로드 요청들을 수신하고, 그 요청들에 대해 선택적으로 서비스하거나 그 요청을 CDN 내의 또 다른 서버로 재지시할 수 있다. 이러한 방식으로, CDN 웹 서버는 DNS의 로직과 유사한 라우팅 로직이 부여될 수 있고, 따라서 다수의 서버들에 걸친 일련의 요청들에 대한 균형을 맞출 수 있다.

본 명세서에 설명된 실시예들에서, DNS 서버는 다양한 등급의 제어 로직을 가질 수 있다. 예를 들어, 또한 짧은 TTL 실시예와 별개로 또는 그에 부가하여, DNS는 또한 임의의 서버에 대한 요청들의 수에 관한 제한들, 대다수의 최적의 서버들에 관한 랭킹들, 수용될 수 있는 바이트 범위들에 관한 제한들, 및 설명된 실시예들을 수행하는데 유용할 수 있는 또 다른 제어 로직과 같은 정보를 반환할 수 있다.

더욱이, 다양한 실시예들에서 설명된 클라이언트 컴퓨터들은 어느 서버들로부터 바이트 범위들을 요청할지, 얼마나 많은 동시 요청, 사이즈 또는 요청들을 선택하기 위한 최적화 로직 및 다양한 최적화 파라미터들을 선택하기 위한 다른 로직을 사용하도록 구성될 수 있다. 클라이언트 컴퓨터들은 파일을 이루는 바이트들의 범위들을 요청하기 전에 파일 크기를 요청하도록 구성될 수도 있다.

또한 설명된 실시예들을 실행하는데 유용하거나 필요한 클라이언트 디바이스, CDN 네트워크의 컴포넌트들과 같은 다양한 디바이스들이 개시된다. 더욱이, 디바이스들 및 컴포넌트들의 시스템들도 개시된다. 유사하게, 설명된 실시예들은 본 명세서에 설명된 방법들을 수행하도록 다양한 프로세서-기반 디바이스들에 명령을 내리는데 유용한, 저장된 컴퓨터 판독 가능 명령들을 갖는 컴퓨터 프로그램 제품에 기록될 수 있다.

위에서 설명된 실시예들이 구현되는 방식을 가장 잘 설명할 뿐만 아니라, 발명의 또 다른 이점들 및 특징들을 정의하기 위해, 더 구체적인 설명이 아래에 제공되고 첨부된 도면에서 도시된다. 이들 도면들이 본 발명의 단지 예시적인 실시예들을 묘사하고, 따라서 본 발명의 범주를 제한하는 것으로 여겨지지 않는다는 것을 이해하면서, 예시들은 첨부되는 도면들을 이용하여 더 특별하고 자세하게 묘사되고 설명될 것이다.
도 1은 예시적인 컴퓨팅 디바이스를 도시한 것이다.
도 2는 예시적인 시스템 실시예를 도시한 것이다.
도 3은 주어진 주소로부터 파일 다운로드에 대한 요청을 처리하는 방법의 실시예를 도시한 것이다.
도 4는 주어진 주소로부터 파일 다운로드에 대한 요청을 처리하는 방법의 실시예를 도시한 것이다.
도 5는 주어진 주소로부터 파일 다운로드에 대한 요청을 처리하는 방법의 실시예를 도시한 것이다.
도 6은 예시적인 시스템 실시예를 도시한 것이다.
도 7은 말단 서버 재지시 실시예의 방법 실시예를 도시한 것이다.
도 8은 말단 서버 재지시 실시예의 시스템 실시예를 도시한 것이다.
도 9는 서버의 지능 라우팅의 실시예를 도시한 것이다.

개시된 방법들 및 구성들의 다양한 실시예들은 아래에서 자세히 논의된다. 특정 구현들이 설명되지만, 이 설명은 설명의 목적으로만 이루어짐을 이해해야 한다. 관련 분야의 숙련자는 다른 컴포넌트들, 구성들 및 단계들이 본 명세서의 개념 및 범주를 벗어나지 않고 사용될 수 있음을 인식할 것이다.

도 1을 참조하면, 휴대 가능하거나 고정될 수 있는 범용 컴퓨팅 디바이스(100)가 도시되며, 이 디바이스는 프로세싱 유닛(processing unit)(CPU)(120), 및 ROM(read only memory)(140) 및 RAM(random access memory)(150)과 같은 시스템 메모리를 포함하는 다양한 시스템 컴포넌트들을 프로세싱 유닛(120)에 연결하는 시스템 버스(110)를 포함한다. 다른 시스템 메모리(130)도 사용 가능할 수 있다. 시스템은 하나보다 많은 CPU(120)를 갖는 컴퓨팅 디바이스 상에서 또는 더 큰 프로세싱 능력을 제공하기 위해 함께 네트워크 형성된 컴퓨팅 디바이스들의 그룹 또는 클러스터 상에서 동작할 수 있다는 것이 이해될 수 있다. 시스템 버스(110)는 임의의 다양한 버스 아키텍쳐를 이용하는 메모리 버스 또는 메모리 제어기, 주변 버스, 및 로컬 버스를 포함하는 버스 구조들의 임의의 몇몇 형태들일 수 있다. ROM(140)등에 저장된 BIOS(basic input/output)는, 시동 중에, 컴퓨팅 디바이스(100) 내의 소자들 간에 정보를 전달하는 것을 도와주는 기본 루틴(basic routine)을 제공할 수 있다. 컴퓨팅 디바이스(100)는 하드 디스크 드라이브(160), 자기 디스크 드라이브, 광 디스크 드라이브, 테이프 드라이브 등과 같은 스토리지 디바이스들을 더 포함한다. 스토리지 디바이스(160)는 드라이브 인터페이스에 의해 시스템 버스(110)에 연결되어 있다. 드라이브들 및 관련된 컴퓨터 판독 가능 매체들은 컴퓨팅 디바이스(100)를 위한 컴퓨터 판독 가능 명령어들, 데이터 구조체들, 프로그램 모듈들 및 다른 데이터의 비휘발성 스토리지를 제공한다. 일 양태에서, 특정한 기능을 수행하는 하드웨어 모듈은 그 기능을 수행하기 위해 CPU, 버스, 디스플레이 등과 같은 필요한 하드웨어 컴포넌트들에 관하여 유형의 컴퓨터-판독 가능 매체에 저장된 소프트웨어 컴포넌트를 포함한다. 기본 컴포넌트들은 본 분야의 숙련자들에게 공지되어 있고, 그 디바이스가 작은지, 핸드헬드 컴퓨팅 디바이스인지, 데스크탑 컴퓨터인지 또는 커다란 컴퓨터 서버인지와 같이, 그 디바이스의 형태에 따라 적절한 변형들이 예상된다.

본 명세서에 설명된 예시적인 환경은 하드 디스크를 채택하지만, 자기 카세트들, 플래쉬 메모리 카드들, 디지털 만능 디스크들, 카트리지들, RAM들(random access memories), ROM(read only memory)과 같이 컴퓨터에 의해 액세스 가능한 데이터를 저장할 수 있는 다른 형태들의 컴퓨터 판독 가능 매체가 예시적인 동작 환경에서 또한 사용될 수 있다는 것이 본 분야의 숙련자들에 의해 이해되어야 한다.

컴퓨팅 디바이스(100)와 사용자의 상호작용을 가능하게 하기 위해서, 입력 디바이스(190)는 음성을 위한 마이크로폰, 제스쳐 또는 그래픽 입력을 위한 터치-감지 스크린, 키보드, 마우스, 동작 입력, 음성 등과 같은 임의의 수의 입력 메카니즘을 나타낸다. 입력은 그 제공자에 의해 음성 검색 쿼리의 시작을 알리는 데 사용될 수 있다. 또한, 디바이스 출력(170)은 본 분야의 숙련자들에게 공지된 다수의 출력 메카니즘들 중 하나 이상일 수 있다. 예를 들어, 디스플레이들 또는 스피커들에 연결될 수 있거나, 그것들을 포함할 수 있는 비디오 출력 또는 오디오 출력 디바이스들이 일반적이다. 부가적으로, 또한 비디오 출력 및 오디오 출력 디바이스들은 이들 특화된 기능들의 강화된 성능을 위한 특화된 프로세서들도 포함할 수 있다. 일부 예들에서, 멀티모달 시스템들(multimodal systems)은 사용자로 하여금 컴퓨팅 디바이스(100)와 통신하기 위한 다양한 형태들의 입력을 제공할 수 있게 한다. 통신 인터페이스(180)는 일반적으로 사용자 입력 및 시스템 출력을 지배하고 관리한다. 임의의 특정한 하드웨어 구성상에서 동작하는 개시된 방법들 및 디바이스들에 대한 제한은 없고, 따라서 기본적인 특징들은 개선된 하드웨어 또는 펌웨어 구성들이 개발됨에 따라, 그것들로 쉽게 대체될 수 있다.

명확한 설명을 위해, 설명적인 시스템 실시예는 ("프로세서"로 라벨링 된 기능 블럭들을 포함하는) 개별 기능 블럭들을 포함하는 것으로 표현된다. 이들 블럭들이 나타내는 기능들은 소프트웨어를 실행할 수 있는 하드웨어를 포함하지만 이들에 제한되지는 않는 공유 또는 전용 하드웨어의 사용을 통해 제공될 수 있다. 예를 들어, 도 1에 표현된 하나 이상의 프로세서들의 기능들은 단일 공유 프로세서 또는 다수의 프로세서들에 의해 제공될 수 있다("프로세서"라는 용어의 사용은 소프트웨어를 수행할 수 있는 하드웨어만을 지칭하는 것으로 해석되어서는 안된다). 설명적인 실시예들은 마이크로 프로세서 및/또는 DSP(digital signal processor) 하드웨어, 후술하는 동작들을 수행하는 소프트웨어를 저장하기 위한 ROM(read-only memory), 및 결과들을 저장하기 위한 RAM(random access memory)을 포함할 수 있다. VLSI(very large scale integration) 하드웨어 실시예들 뿐만 아니라 범용 DSP 회로와 조합하여 커스텀 VLSI 회로 또한 제공될 수 있다.

다양한 실시예들의 논리적 동작들은:(1) 범용 컴퓨터 내의 프로그램 가능한 회로 상에서 작동하는 일련의 컴퓨터로 구현된 단계들, 동작들, 또는 절차들, (2) 특별한 사용을 위한 프로그램 가능한 회로 상에서 작동하는 일련의 컴퓨터로 구현된 단계들, 동작들, 또는 절차들, (3) 프로그램 가능한 회로들 내의 상호 연결된 기계 모듈들 또는 프로그램 엔진들로서 구현된다.

본 시스템 및 방법은 CDN(Content Delivery Network)을 통해 사용자에게 청크 단위로 파일을 배포하는데 특히 유용하다. 높은 레벨에서 클라이언트 컴퓨터는 범위들 또는 청크들의 단위로 다운로드 될 파일들을 요청하도록 구성될 수 있다. 예를 들어, 10-메가 바이트의 파일은 세 개의 다른 청크들로 다운로드를 제공하기 위해 1-3,000,000 및 3,000,001-6,000,000 및 6,000,001-10,000,000 바이트의 범위들로 다운로드 될 수 있다. 파일은 다운로드 효율성과 속도를 극대화하기 위해 임의의 바이트들 범위의 임의의 수의 청크들로 나누어질 수 있다.

청크식 다운로드 요청들을 서비스하기 위한 CDN(200)은 도 2에 도시되며, CDN의 적어도 하나의 말단 서버(218, 220, 222)는 클라이언트 디바이스(230, 232)에 다운로드하기 위한 요청된 파일(204)의 청크(224, 226, 228)를 제공할 수 있다. 일부 실시예들에서, 본 시스템 및 방법은 인터넷 연결을 통해 수행되지만, 본 발명의 원리는 전자 디바이스들의 상호 통신을 촉진시키는 다양한 네트워크들에 적용가능하다.

컨텐츠 공급자(202)는 다운로드를 위한 사용자 또는 클라이언트를 호스트하도록 CDN(200)에 파일(204)을 제공할 수 있다. 컨텐츠 공급자(202)는 CDN에 다운로드될 파일(204)을 전송하기 위해 CDN(200)과 통신한다. 이 통신은 인터넷 상에서 행해질 수도 있고, 그렇지 않을 수도 있다. CDN의 상위-레벨/루트/부모 서버(206)는 CDN 전체에 파일(208, 212, 216)을 배포하며, CDN 내에 중간 네트워크(210) 및/또는 중간-레벨 서버들(214)이 있을 수도 있고, 아닐 수도 있다. CDN 내의 임의의 레벨들 상의 임의의 서버들(206, 210, 214, 218, 220, 222)은 컴퓨팅 디바이스로 구현될 수 있다. 네트워크 전체에 파일(204)을 배포함으로써, 더 많은 서버들이 주어진 파일에 대한 요청에 대해 서비스하기 위해 존재한다. 더욱이, 요청에 대해 서비스하는 많은 서버들이 존재하기 때문에, 그것들은 지리적으로 분산될 수 있어서, 서버들은 다운로드를 위한 파일들을 요청하는 다양한 클라이언트들에 대해, 지리적으로, 비교적 지역적일 수 있다.

말단 서버들(218, 220, 222)은 파일을 요청하는 클라이언트에게 파일을 운반함으로써 다운로드 요청들을 서비스한다. 도 2에서 도시된 실시예에서, 다수의 말단 서버들(218, 220, 222)은 청크들(224, 226, 228)로 다운로드된 파일(204)에 대한 요청을 서비스하고 있다. 말단 서버(218)는 청크(224)를 클라이언트(230)에 보내고, 반면 서버(220)는 청크(226)를 보내고 서버(222)는 청크(228)를 보낸다. 또한 사용자 디바이스(232)는 다수의 말단 서버들로부터 파일을 청크 단위로 수신하는 것으로 도시된다.

도 2에는 또한 CDN(200)의 일부인 DNS(domain name service)(238)가 도시된다. DNS는 클라이언트에 의해 제공된 URL에 기초하여 IP 주소에 대한 요청을 수신하고, 다운로드 요청에 대해 서비스하기 위한 말단 서버의 IP 주소를 식별하는 DNS 주소 레코드(A-레코드)를 반환한다. 클라이언트는 말단 서버에 직접적으로 접속하기 위해 반환된 IP 주소를 사용한다. 본 분야에서 공지된 바와 같이, DNS는 요청에 대해 가장 효율적으로 서비스할 수 있는 말단 서버를 식별하는데 사용될 수 있는, 요청의 소스에 대한 지리적 근접성, 대역폭, 네트워크 정체 및 다른 파라미터들과 같은 네트워크 효율 파라미터들에 기초하여 어느 말단 서버가 요청에 대해 서비스할 것인지를 결정할 수 있다. 즉, DNS는 다운로드 요청에 대한 서비스를 가장 효율적으로 제공할 수 있는 말단 서버의 IP 주소를 클라이언트에게 반환함으로써 다운로드 요청들을 지능적으로 라우팅할 수 있다.

일부 실시예들에서, DNS는 네트워크 효율 파라미터들 외의 파라미터들에 기초하여 말단 서버의 IP 주소를 반환한다. 예를 들면, 일부 실시예들에서, DNS는 동일한 클라이언트 컴퓨터에 최근에 반환된 주소와 다른 말단 서버의 IP 주소를 반환할 수 있다.

일부 실시예들에서, DNS는 새로운 타입의 DNS 레코드인 청크-레코드에 대한 요청을 수용하도록 더 변경되었으며, 이 청크-레코드는 다운로드 요청에 대해 잠재적으로 서비스할 수 있는 몇 개의 말단 서버들에 대응하는 IP 주소들의 리스트를 포함한다.

도 3 내지 도 5는 다운로드 요청에 대한 서비스를 제공할 말단 서버의 IP 주소를 클라이언트에게 제공하기 위해 DNS에 의존하는 설명된 시스템의 실시예들을 도시한다. 예를 들어, 도 3에서, 종래의 DNS는 공급된 URL에 대응하는 IP 주소(302)에 대한 요청을 수신하고, 요청에 대해 서비스할 수 있는 CDN 말단 서버에 맵핑하는 IP 주소(304)를 가지는 A-레코드를 반환한다. 위에서 논의된 바와 같이, DNS는 네트워크 효율성들에 관한 정보 및 컨텐츠 운반 네트워크에 연관된 정보에 기초하여 적절한 말단 서버를 선택할 수 있다. 반환된 IP 주소를 이용하여, 클라이언트는 원하는 파일의 일부분을 이루는 바이트의 제1 범위를 요청하고, CDN 말단 서버는 그 요청(306)을 수신하고 그에 대해 서비스한다. 동시에, 또는 거의 동시에, 클라이언트는 동일한 서버로부터 제2 바이트 범위(308)를 요청하고, 모든 바이트 범위들이 요청되거나 모든 파일이 다운로드될 때까지 추가적인 바이트 범위들(310)의 요청을 계속한다. 일부 실시예들에서, 클라이언트는 임의의 새로운 바이트들의 범위를 위해 302에서 시작하는 프로세스를 반복할 수도 있다.

도 4는 실시예를 도시하며, 이 실시예에서 DNS는 다운로드 요청에 대해 서비스할 수 있는 몇 개의 CDN 말단 서버들의 IP 주소들을 가지는 새로운 형태의 레코드, 이하에서는, 청크-레코드를 반환하도록 변경될 수 있다. 클라이언트는 주어진 URL(315)에 대응하는 다중-주소 검색에 대한 요청을 보낼 수 있고, DNS는 그 요청을 수신한다. 요청(315)에 응답하여, DNS는 요청(316)에 대해 서비스할 수 있는 서버들의 리스트를 포함하는 청크-레코드를 반환할 수 있다. 이 서버들의 리스트를 이용하여, 클라이언트는 CDN(317, 318, 319)에 의해 수신되는 복수의 요청들을 만들어 낼 수 있다. 각각의 요청들은 전체 파일을 포함하는 분리된 또는 겹치는 바이트들의 범위들에 대한 것일 수 있다. 각각의 요청은 동일한 CDN 말단 서버에 보내질 수 있으나, 바람직하게는 요청들은 청크-레코드에 포함된 IP 주소들의 리스트에 대응하는 서버들 사이에 분산될 것이다.

이들 실시예에서, 청크-레코드에 나타나 있는 어떤 말단 서버로부터 바이트들의 범위를 요청할 것인지를 궁극적으로 결정하는 것은 클라이언트 디바이스이이다. 클라이언트는 라운드 로빈 형태의 선택 프로세스를 이용하여 이 선택을 할 수 있으며, 이 프로세스에서 클라이언트는 청크-레코드에서 식별된 서버로부터 차례로 요청할 수 있다. 대안으로, 클라이언트는 바이트들의 범위에 대한 임의의 주어진 요청을 위해 리스트로부터 IP 주소를 무작위로 선택할 수 있다. 그러나, 일부 실시예들에서는, 클라이언트는 어느 정도는 지능적인 시스템을 갖출 수 있어서, 클라이언트는 최적화 로직에 기초하여 청크-레코드 내에서 식별된 서버를 선택할 수 있다. 예를 들어, 클라이언트는 다양한 IP 주소들로부터의 요청에서 다운로드 속도를 모니터할 수 있고, 최고의 성능을 가진 서버를 더 자주 재사용할 수 있다. 클라이언트는 또한 동일한 서버에서 다수의 요청을 하는 것이 이익이 되는지를 결정하기 위해 이미 요청된 다운로드들을 모니터할 수 있고, 그에 따라, 그 서버에 대해 새로운 요청들을 할 수 있다. 다른 최적화 로직은 다운로드 될 파일의 청크들을 요청할 IP 주소를 선택하는 데 사용될 수 있다. 더욱이, 예시적인 실시예들 이외에도 위에서 설명된 하나 이상의 특징들은 유용할 수 있고, 이들 특징들이 이 실시예에 특정한 것으로 여겨져서는 안 된다는 것을 이해해야 한다.

일부 실시예들에서, 316에서 반환된 청크-레코드는 또한 레코드 내에 나열된 서버들에 관한 부가적인 정보를 포함할 수 있다. 예를 들어, 특별한 A-레코드는 또한 요청에 대해 서비스하는데 어떤 서버가 가장 적합한지를 표시하는 서버들의 랭킹들을 포함한다. 청크-레코드는 또한 특정한 서버로부터 얼마나 큰 크기의 바이트 범위가 최적으로 요청되어야 하는지에 관한 정보를 포함할 수 있다. 사용자 디바이스의 위치를 설명하는 정보, CDN 말단 서버들의 네트워크 정체를 설명하는 정보, CDN 말단 서버들에 의해 서비스될 요청들의 양을 설명하는 정보 등과 같은 다른 정보도 유용할 수 있고, 청크-레코드 내에 포함될 수 있다.

도 5는 DNS 서버가 매우 낮은 TTL을 갖는 통상의 A-레코드를 반환하는 실시예들을 도시한다. DNS는 클라이언트로부터 IP 주소에 관한 요청(320)을 수신하고, DNS는 낮은 TTL(323)을 가지는 A-레코드를 클라이언트에 반환한다. 클라이언트에 반환된 임의의 레코드가 반환된 IP 주소에 한 번 연결하기에 충분할 만큼만 오래 살아있도록(유효하도록) TTL은 충분이 짧아야 한다. 따라서, TTL은 1분보다 작아야 하고, 더 바람직하게는 1초보다 더 작아야하다. 일부 실시에들에서는, TTL은 100 ㎳보다 더 작다. 클라이언트가 낮은 TTL을 갖는 A-레코드를 수신할 때, 클라이언트는 326에서의 A-레코드 내에서 식별된 IP 주소로부터 파일의 제1 범위를 요청한다. CDN 내의 말단 서버는, 그 후, 그 요청에 대해 서비스한다. 한편, 아마도 320, 323 및 326들이 수행되는 동안, 클라이언트는 DNS(321)로부터 파일의 제2 청크를 요청할 수 있으며, DNS는 그 요청을 충족시킬 최고의 서버를 다시 계산하고, 324에서 짧은 TTL을 갖는 또 다른 A-레코드에서 그 서버의 IP 주소를 반환할 것이다. 다음으로, 327에서 클라이언트는 A-레코드에서 식별된 서버로부터 제2 청크를 요청하여 그 요청에 대해 서비스하게 할 수 있다. 이 방법은 모든 청크들이 요청되거나 다운로드 될 때까지 계속될 수 있다. 예를 들어, 제1 및 제2 청크들이 다운로드 되는 동안, 방법은, 반복적인 방식으로, 부가적인 바이트들의 범위들을 요청하는 것(322), 낮은 TTL을 갖는 A-레코드들을 수신하는 것(325), 및 A-레코드에서 식별된 서버로부터 다음 청크를 요청하는 것(328)을 계속한다.

도 6은 시스템 실시예를 도시한다. 클라이언트 디바이스(330)는 DNS 서버(332)로부터 다운로드(334)하기 위한 파일을 제공할 지명된 서버에 대응하는 IP 주소를 요청한다. DNS 서버(332)는 CDN(340)의 다른 컴퓨터들과 통신(342)하여 부가적인 요청들을 처리하는 그들의 능력, 범위지정된 요청들을 처리하는 능력, 네트워크 정체 및 요청에 대해 가장 효율적으로 서비스할 수 있는 말단 서버들(344)에 요청들을 지능적으로 라우팅하는데 도움이 되는 다른 요인들을 모니터한다. DNS(332)는 하나 이상의 말단 서버들의 IP 주소를 클라이언트에 통신한다(336). 클라이언트는 CDN(340)으로부터 청크들 상태의 파일을 요청하고(339), 두 개 이상의 일련의 통신들(338)에서 파일의 청크들을 수신한다.

도 7은 말단 서버로 하여금 다운로드 요청을 재지시할 수 있게 함으로써 청크들의 파일들의 다운로딩을 촉진시키기 위해 CDN의 말단 서버들을 활용하는 실시예들을 수행하는 방법을 도시한다. 이들 실시예들에서, 각각의 CDN 말단 서버는 사용자 디바이스의 위치에 대해 설명적인 정보, 다른 CDN 말단 서버들의 작업부하, 가용성, 네트워크 정체 등에 대해 설명적인 정보에 액세스할 수 있다. 즉, CDN 말단 서버는 DNS 서버와 유사한 지능 라우팅 능력을 가지도록 구성된다.

도 7에서 도시된 바와 같이, DNS 서버는 클라이언트(400)로부터 지명된 서버의 IP 주소에 관한 요청을 수신한다. DNS 서버는 CDN이 청크식 다운로딩(402)에 대해 서비스할 수 있음을 클라이언트에게 선택적으로 통지하고, 파일 다운로드 요청(404)에 대해 서비스하기 위한 말단 서버의 제1 IP 주소를 반환한다. 제1 말단 서버가 파일을 다운로드하는 요청(406)을 수신할 때, 그 말단 서버는 그 요청이 범위지정된 요청인지를 결정하기 위해 그 요청을 처리한다(408). 만약, 요청이 전체 파일을 다운로드 하기 위한 요청이라면, 제1 말단 서버는 요청에 대한 서비스(412)할 제2 말단 서버로 요청(410)을 재지시할 수 있다. 제2 말단 서버는 요청을 더 잘 처리할 수 있는 제2 말단 서버를 식별할 수 있는 제1 말단 서버들의 지능적 라우팅 능력들(위에서 설명된 DNS 능력들과 유사함)에 기초하여 제1 말단 서버에 의해 선택된다. 그러나, 일부 실시예들에서, 제1 말단 서버는 또한 그가 요청에 대해 서비스하는 데 가장 적합한 것으로 결정할 수 있고, 그 후, 그 자신이 요청에 대해 서비스할 수 있다.

408로 되돌아가서, 만약 요청이 범위지정된 요청이라면, 제1 말단 서버는 앞으로 부가적인 요청들이 더 있을 것이라고 가정할 수 있고, 그 자신의 지능적 라우팅 능력들을 이용하여 범위 지정된 요청의 현재의 부분에 대해 서비스하기 위한 서버를 선택하고 클라이언트를 그 서버로 재지시(414) 시킬 수 있다. 이어서, 클라이언트가 재지시되는 말단 서버는 요청에 대해 서비스할 수 있다(416). 동시에, 제1 말단 서버는 또한 요청된 파일에 대한 제2 또는 다음번 바이트들의 범위를 수신(418)할 수 있고, 그 요청을 임의의 이전 범위들에 대한 것과 동일하거나 상이한 서버들로 재지시(420)시켜 그 서버에 의해 서비스되게 할 수 있다(422). 바이트들의 범위에 대한 요청을 수신하고, 그 요청을 새로운 서버에 재지시하고, 그 요청에 대해 서비스하는 프로세스는 모든 바이트들이 서비스되거나 또는 다운로드될 때까지 계속될 수 있다(424).

일부 실시예들에서는, 요청을 수신하는 제1 말단 서버 자신이 요청에 대해 서비스할 수 있다. 이는 제1 말단 서버가 그가 그 요청에 대해 서비스하는 데 가장 적합하다고 결정하는 경우에 바람직할 수 있다. 일부 실시예들에서, 일부 말단 서버들은 무한적인 재지시를 막기 위해, 항상 요청들에 대해 서비스하고 절대 재지시하지 않도록 프로그램된다. 또한 일부 실시예들에서는, 요청이 지시되는 횟수가 기록되고, 허용되는 재지시의 횟수에 대해 한계가 정해진다. 그러한 실시예들에서, 허용되는 재지시의 횟수에 대한 한계를 이미 초과한 재지시된 요청을 수신하는 임의의 서버는 반드시 그 요청에 대해 서비스해야 한다.

재지시의 프로세스는 본 분야에서 공지된 임의의 프로세스들에 의해, 예를 들어, 요청을 뒤로 미루거나 클라이언트에게 바이트들에 대한 요청을 다시하라고 지시하는 것에 의해 이루어질 수 있다.

도 8은 말단 서버 재지시 실시예들의 시스템 실시예를 도시한다. 도면은 CDN의 일부를 도시하며, 여기서는 CDN의 두 개의 브랜치가 서로 다른 도시들에 위치된다. 중간 서버들(434 및 436)은 나머지 네트워크로부터 파일들을 수신하고, 수신된 파일들을 동일한 도시 내의 말단 서버들에 배포한다. 도시된 바와 같이, 서버(434)는 도시 1에 모두 위치하는 말단 서버들(438, 440, 442)에 파일들을 배포할 수 있다. 마찬가지로, 서버(436)는 도시 2에 모두 위치하는 말단 서버들(444, 446, 448)에 파일들을 배포할 수 있다.

다운로드될 파일을 구성하는 바이트들의 제1 범위의 최초 요청에 대해, 클라이언트 컴퓨터(430)는 DNS(432)로부터 IP 주소를 요청하고, DNS는 요청을 처리할 근처의 말단 서버의 IP 주소를 A-레코드의 형태로 반환한다. 클라이언트(430)와 DNS(432) 간의 통신은 452로 도시된다.

이어서, 클라이언트(430)는, 말단 서버(438)를 찾도록 DNS(432)에 의해 클라이언트(430)에 주어진 IP 주소를 이용하여 말단 서버(438)에 대해 범위 지정된 요청(450)을 만든다. 그 자신이 요청에 대해 서비스하는 것 대신에, 말단 서버(438)는 말단 서버(440)가 요청에 대해 더 잘 서비스할 것이라고 결정하고, 클라이언트 컴퓨터(430)를 말단 서버(440)에 재지시하고(454), 이후에 이 서버는 요청에 대해 서비스한다(456).

클라이언트 컴퓨터(430)가 임의의 후속하는 요청을 만들어 낼 때, 클라이언트 컴퓨터는 이전에 수신된 A-레코드를 캐쉬에 저장할 수 있기 때문에 DNS(432)에 다시 쿼리할 필요가 없다. 그러나, 일부 실시예들에서, 클라이언트(430)와 DNS(432) 간의 추가적인 통신이 발생할 수 있다. 예를 들어, 만약, A-레코드가 짧은 TTL을 가지거나 초기 요청 후에 후속하는 요청이 오래 걸린다면, DNS와의 부가적인 통신이 요구될 것이다.

그러나, DNS와의 어떠한 통신도 요구되거나 필요하지 않다고 가정하면, 클라이언트(430)는 후속하는 범위지정된 요청들을 A-레코드에서 식별된 말단 서버, 이 경우 말단 서버(438)에 전송한다(458). 말단 서버(438)는 요청에 대해 서비스하기 위한 가장 최적의 말단 서버를 다시 계산하고, 서버(446)를 최적의 서버로 결정한다. 서버(446)는 그것이 다른 도시에 있더라도 선택될 수 있다는 점에 유의한다. 말단 서버(438)는 요청을 서버(446)로 재지시시키며(460), 이 서버가 요청에 대해 서비스한다(462).

도 9는 청크식 요청에 대해 서비스할 최고의 말단 서버를 결정하는 방법을 도시한다. 위에서 언급한 바와 같이, 이 결정은 DNS서버 및/또는 CDN 말단 서버에 의해 수행될 수 있다. 수신된 다운로드 요청들을 지능적으로 라우팅하기 위해서, DNS 또는 말단 서버는 말단 서버가 청크식 요청들을 처리할지 여부(807), 사용자 디바이스의 위치(800), 사용자 디바이스에 위상적으로 인접하는(근처의) 각각의 말단 서버의 위치(802), 클라이언트에 대한 말단 서버의 지리적 근접성(803), 사용자 디바이스 각각의 근처의 말단 서버의 작업 부하(804), 사용자 디바이스 근처의 각각의 말단 서버의 가용성(806), 네트워크 정체(808) 등을 포함하는, 그러나 이에 제한적이지는 않는, 복수의 입력들을 수신하고 처리한다. 이들 입력들에 기초하여, 특별한 파일에 대한 특정 요청의 서비스를 제공하는 말단 서버의 능력을 나타내는 품질 스코어가 각각의 이용 가능한 말단 서버들(810)에 대해 계산된다. 사용자 디바이스에 가장 가까운 말단 서버가 요청에 대한 서비스를 제공하기 위한 가장 바람직한 서버인 것은 아닐 수 있다. 예를 들어, 더 근접하는 서버가 많은 작업 부하를 가지거나 이용 가능하지 않다면, 다운로드를 요청하는 클라이언트 디바이스로부터 더 멀리 떨어진 말단 서버보다 더 기하학적으로 근접하는 말단 서버가 요청에 대해 서비스하는 데 덜 바람직한 것으로 간주 될 수 있다. 순위화된 리스트가 품질 스코어에 기초하여 생성될 수 있다(812). DNS 서버 또는 말단 서버는 반환 서버 모듈(816)을 통해 클라이언트에게 서버 랭킹 모듈(814)에 의해 결정된 비교적 높은 품질 스코어를 가지는 적어도 하나의 말단 서버의 IP 주소를 반환한다(820).

일부 실시예에서, 말단 서버는 또한 동일 기술을 이용하여 그가 또는 다른 말단 서버들이 요청에 대해 서비스하기 위한 가장 바람직한 서버인지를 결정하도록 구성될 수 있다. 그러한 경우에, 말단 서버는 다른 말단 서버들에 대한 품질 스코어들을 반환할 수 있고, 그 스코어들에 기초하여 말단 서버는 그 자신이 요청에 대해 서비스하거나 또는 더 바람직한 말단 서버에 클라이언트를 재지시할 수 있다.

본 명세서에 설명된 실시예들에 관하여, 사용자 측은 또한 청킹(chunking)을 적당하게 다루기 위해 특별한 기능들을 가질 수 있다. 만약 사용자 측이 청크식 다운로딩을 다루는 기능들을 가지고 있지 않다면, 사용자 측은 단지 그 파일을 넌-청크식 방식으로 다운로드 할 것이다(예를 들어, 사용자 디바이스는 CDN 내의 하나의 말단 서버로부터 전체 파일을 다운로드한다). 특별한 기능들은 사용자가 획득해야할 다운로드 관리 소프트웨어를 통해 또는 청크식 다운로딩을 다룰 수 있는 내재된 능력들을 가지는 웹 브라우저들을 통해 구현될 수 있다. 하나의 특별한 기능은 DNS 서버 CDN에 의해 전송된 청크-레코드를 요청하고 사용할 수 있는 능력을 가질 수 있다. 더욱이, 사용자 측에서의 중요한 기능은 파일의 다운로드된 청크들을 처리하고 원래의 파일을 형성하기 위해 그 청크들을 재결합할 수 있는 능력이다.

위에서 도시되고 설명된 방법들이 별개의 실시예들로 설명되는 반면, 각각의 실시예들의 요소들은 다른 실시예들에 적용될 수 있고, 따라서 그것들은 서로에게 배타적인 것으로 여겨져서는 안된다는 것을 이해해야 한다.

본 발명의 범위 내의 실시예들은 또한 컴퓨터-실행 가능 명령들 또는 데이터 구조체들을 갖거나 저장하기 위한 컴퓨터-판독 가능 매체들을 포함할 수 있다. 그러한 컴퓨터-판독 가능 매체는 범용 또는 특별한 목적의 컴퓨터에 의해 액세스될 수 있는 임의의 이용 가능한 매체일 수 있다. 예시의 그리고 제한되지 않는 방식으로, 그러한 유형의 컴퓨터-판독 가능 매체는 컴퓨터-실행가능 명령들 또는 데이터 구조체들의 형태로 원하는 프로그램 코드 수단들을 갖거나 저장하는데 사용될 수 있는 RAM, ROM, EEPROM, CD-ROM 또는 다른 광학 디스크 스토리지, 자기 디스크 스토리지 또는 다른 자기 스토리지 디바이스들 또는 임의의 다른 매체를 포함할 수 있다. 컴퓨터-실행 가능 명령들은 범용 컴퓨터, 특별한 목적의 컴퓨터, 또는 특별한 목적의 프로세싱 디바이스로 하여금 특정한 기능 또는 기능들의 그룹을 수행하도록 하는, 예를 들어, 명령들 및 데이터를 포함한다. 또한 컴퓨터 실행 가능한 명령들은 독립형 또는 네트워크 환경들 내의 컴퓨터들에 의해 실행되는 프로그램 모듈들을 포함한다. 일반적으로, 프로그램 모듈들은 특정한 작업들을 수행하거나 특정한 추상적인 데이터 형태들을 구현하는 루틴들, 프로그램들, 객체들, 컴포넌트들 및 데이터 구조체들을 포함한다. 데이터 구조체들과 연관된 컴퓨터-실행 가능한 명령들 및 프로그램 모듈들은 본 명세서에 개시된 방법들의 단계들을 수행하기 위한 프로그램 코드 수단들의 예들을 나타낸다. 그러한 실행 가능한 명령들 또는 연관된 데이터 구조체들의 특정한 순서는 그 단계들에서 설명된 기능들을 구현하기 위한 행위들에 대응하는 예들을 나타낸다.

본 분야의 숙련자들은 본 발명의 또 다른 실시예들이 퍼스널 컴퓨터들, 핸드-헬드 디바이스들, 다중-프로세서 시스템들, 마이크로 프로세서-기반 또는 프로그램 가능한 소비자 전자기기, 네트워크 PC들, 미니 컴퓨터들, 메인 프레임 컴퓨터들 등을 포함하는 많은 형태의 컴퓨터 시스템 구성들을 갖는 네트워크 컴퓨팅 환경들에서 실시될 수 있다는 것을 이해할 것이다. 실시예들은 통신 네트워크를 통해 (또는 하드 와이어드 링크들, 무선 링크들 또는 그것들의 결합에 의해) 링크된 로컬 또는 원거리 프로세싱 디바이스들에 의해 과제가 수행되는 분산 컴퓨팅 환경(distributed computing environment)들에서 실시될 수도 있다. 분산 컴퓨팅 환경에서, 프로그램 모듈들은 로컬 및 원거리 메모리 스토리지 디바이스 모두에 위치될 수 있다.

설명된 시스템의 다양한 단계들에서의 통신은 로컬 영역 네트워크, 토큰 링 네트워크(token ring network), 인터넷, 기업 인트라넷(corporate intranet), 802.11 시리즈 무선 신호들, 광 섬유 네트워크(fiber-optic network), 무선 또는 마이크로파 송신 등을 통해 수행될 수 있다. 근본적인 통신 기술이 변할 수 있더라도, 본 명세서에 설명된 기본적인 원리들은 여전히 적용 가능하다.

위에서 설명된 다양한 실시예들은 단지 설명적인 방식으로 제공되고, 발명을 제한하는 것으로 해석되어서는 안된다. 본 분야의 전문가들은 본 명세서에서 도시되고 설명된 후속하는 예시적인 실시예들 및 애플리케이션들 없이, 또한 본 명세서의 진정한 개념 및 범주를 벗어나지 않고도 본 발명에 행해질 수 있는 다양한 변경들과 변화들을 쉽게 알아차릴 것이다.

Claims

CDN(Content Delivery Network)으로부터 파일을 청크(chunk) 단위로 전송하는 방법으로서:
DNS(domain name service)에서 클라이언트가 청크 단위로 파일을 다운로드할 수 있는 서버의 IP 주소에 관한 DNS 요청을 상기 클라이언트로부터 수신하는 단계;
상기 요청을 서비스할 상기 CDN의 서버의 주소를 결정하라는 상기 DNS 요청을 처리하는 단계;
상기 클라이언트에게 상기 서버의 주소를 반환하는 단계;
상기 서버에서, 상기 파일에 대한 범위 지정된(ranged) 다운로드 요청들을 수신하는 단계; 및
상기 다운로드 요청들을 서비스하는 단계
를 포함하는 방법.
제1항에 있어서, 상기 서버는 적어도 두 개의 서버들을 포함하는 방법.
제1항 또는 제2항에 있어서, 상기 범위 지정된 요청들을 수신하기 전에, 지정된 파일의 사이즈를 반환하라는 바이트 요청을 상기 클라이언트로부터 수신하고, 상기 파일의 사이즈를 상기 클라이언트에게 반환하는 단계를 더 포함하는 방법.
제1항 내지 제3항 중 어느 한 항에 있어서, 청크 단위로 파일을 다운로드하라는 클라이언트로부터의 상기 요청은 상기 파일에 대한 상이한 지정된 바이트 범위들에 대한 일련의 다운로드 요청들을 포함하는 방법.
제1항 내지 제4항 중 어느 한 항에 있어서, 상기 DNS는 짧은 TTL(time-to-live)을 갖는 상기 서버의 IP 주소를 반환하며, 이에 따라 일련의 순차적인 요청들 각각이 다시 처리되는 방법.
제1항 내지 제5항 중 어느 한 항에 있어서, 상기 DNS 요청은 다수의 IP 주소에 대한 요청인 방법.
제1항 내지 제6항 중 어느 한 항에 있어서, 상기 DNS는 다운로드 요청을 서비스할 복수의 서버들을 포함하는 청크-레코드(chunk-record)를 반환하는 방법.
제7항에 있어서, 상기 수신된 범위 지정된 다운로드 요청들은 상기 청크-레코들에서 반환된 두 개 이상의 상기 서버들에서 수신되는 방법.
컴퓨터로 하여금 제1항 내지 제8항 중 어느 한 항에 기재된 방법을 포함하는 방법을 수행하도록 하기 위한 컴퓨터-판독 가능 코드가 저장된 컴퓨터-판독 가능 매체.
파일의 네트워크-기반 전송을 위한 시스템으로서,
세그먼트 단위로 파일을 다운로드하라는 요청들을 수신하도록 구성된 CDN(Content Delivery Netwrok) 내의 적어도 하나의 CDN 서버를 포함하며, 상기 CDN 서버(들)는 전체 파일을 이루는 상기 파일의 복수의 세그먼트에 대한 복수의 요청을 수신하고, 적어도 두 개의 범위의 적어도 일부를 동시에 전송함으로써 상기 요청을 서비스하도록 더 구성되는 시스템.
제10항에 있어서, 처음에 클라이언트로부터 IP 주소 요청을 수신하고, 상기 요청을 수신할 시에, 다운로드하라는 상기 요청을 서비스할 적어도 하나의 바람직한 CDN 서버를 결정하고, 상기 클라이언트에게 상기 적어도 하나의 CDN 서버의 IP 주소를 반환하는 DNS(domain name service) 서버를 더 포함하는 시스템.
제11항에 있어서, 상기 적어도 하나의 CDN 서버는 제1 CDN 서버이고, 상기 제1 CDN 서버는, 상기 파일을 세그먼트 단위로 다운로드하라는 요청들을 수신할 때, 각각의 수신된 요청에 대해 제2 CDN 서버가 상기 요청을 서비스하는 것이 더 바람직한지를 결정하도록 구성되고, 상기 제1 CDN 서버가 상기 제2 CDN 서버가 더 바람직하다고 결정하는 경우, 상기 제1 CDN 서버는 상기 요청을 서비스하기 위해 상기 제2 CDN 서버에게 상기 요청을 재지시하도록 구성된 시스템.
디바이스로서,
바이트 범위의 파일을 다운로드하라는 일련의 요청들을 만들도록 구성된 프로세서 - 집합적으로는 상기 일련의 요청들은 전체 파일을 이루는 전체의 바이트 범위에 대한 요청들을 포함함 -, 및
상기 프로세서로부터 다운로드하라는 상기 일련의 요청들을 수신하고, 서비스하기 위한 CDN(Content Delivery Network)으로 상기 요청들을 전송하도록 구성되고, 상기 CDN로부터 적어도 두 개의 서로 다른 바이트 범위들의 적어도 일부를 동시에 수신하도록 구성된 통신 인터페이스
를 포함하는 디바이스.
제13항에 있어서, 상기 프로세서는 일련의 바이트 범위로 파일을 다운로드하도록 프로그램된 웹 브라우저를 실행하도록 더 구성된 디바이스.
제13항에 있어서, 상기 프로세서는 상기 CDN로부터 재지시 명령을 수용하고, 상기 CDN 네트워크 내의 제2 서버로부터 상기 바이트 범위를 수신하라는 상기 재지시 명령을 따르도록 더 구성된 디바이스.
제13항에 있어서, 상기 프로세서는 얼마나 많은 다운로드 요청들이 동시에 행해져야 하는지 그리고 상기 바이트 범위가 어떤 서버로부터 요청되어야 하는지 중 적어도 하나를 결정하는 최적화 로직을 실행하도록 더 구성된 디바이스.