KR102555349B1

KR102555349B1 - 네트워크 관리의 목적들을 위하여 도메인 명칭들을 추적하기 위한 시스템 및 방법

Info

Publication number: KR102555349B1
Application number: KR1020197034712A
Authority: KR
Inventors: 션 브라운; 존 버넷; 벤 하도른; 휴고 가르자; 에단 노드네스
Original assignee: 오팡가 네트웍스, 인크.
Priority date: 2017-04-28
Filing date: 2018-04-27
Publication date: 2023-07-12
Also published as: US20210119923A1; EP3616075A1; US11711309B2; EP3616075B1; US10911361B2; EP3616075A4; US20180316618A1; ES2963965T3; KR20200002987A; US20220377017A1; US11411877B2; MX2019012686A; WO2018201084A1

Abstract

방법은 도메인 명칭 시스템(DNS) 서버로부터 제1 클라이언트 디바이스로 송신되는 제1 데이터 패킷 - 제1 데이터 패킷은 DNS 응답임 - 을 가로채는 단계, 제1 데이터 패킷으로부터 제1 인터넷 프로토콜(IP) 어드레스 및 제1 호스트명을 추출하는 단계, 및 식별 테이블의 제1 엔트리에서 제1 IP 어드레스 및 제1 호스트명을 저장하는 단계를 포함한다.

Description

네트워크 관리의 목적들을 위하여 도메인 명칭들을 추적하기 위한 시스템 및 방법

관련 출원에 대한 상호-참조

이 특허 문서는 모든 목적들을 위하여 참조로 본원에 포함되는, 2017년 4월 28일자로 출원된 미국 특허 가출원 제62/491,581호의 이익을 주장한다.

데이터는 네트워크 트래픽의 형태로 네트워크를 횡단할 수 있다. 네트워크 트래픽은 2 개의 종점(endpoint)들 사이의 네트워크에 걸쳐 송신되는 하나 이상의 캡슐화된 패킷(encapsulated packet)들을 포함할 수도 있다. 예를 들어, 데이터 패킷은 데이터 네트워크를 컨텐츠 서버(content server)로부터 사용자 장비(user equipment)까지 횡단한다.

네트워크 트래픽을 식별하는 것은 다양한 네트워크 관리 및 분석 애플리케이션들을 위하여 중요하다. 역사적으로, 네트워크 트래픽은 그 네트워크들 상에서의 트래픽 패턴들 및 소비자 거동을 이해하기 위하여 네트워크 서비스 제공자들에 의해 이용되었다.

네트워크 트래픽은 인터넷 내에서 감독 자율성, 인가, 및/또는 제어의 영역을 정의하는 식별 스트링(identification string)에 의해 식별될 수 있다. 예를 들어, 네트워크 트래픽은 네트워크 트래픽의 종점들을 식별하는 호스트명(hostname)들에 의해 식별될 수 있다.

호스트명들과 같은 네트워크 식별 정보는 개별적인 데이터 흐름들에서 데이터 패킷들의 애플리케이션 계층 데이터의 심층 패킷 검사(deep packet inspection)를 수행함으로써 유도될 수 있다. 그러나, 전통적인 수단을 이용하여 네트워크 트래픽을 식별하는 것은 전송 계층 보안성(Transport Layer Security)(TLS) 또는 보안 소켓들 계층(Secure Sockets Layer)(SSL)에 의한 암호화의 채택으로 어렵고, 시간-소비적이고, 그렇지 않을 경우에는 성가신 것으로 되었다. 데이터 패킷들의 페이로드들은 이제 암호화된다. 그 결과, 심층 패킷 검사 기법들(예컨대, 애플리케이션 계층 데이터로 판독하는 것)에 의존하였던 과거의 구현예들은 이제 대부분의 그 데이터를 은닉하는 암호화로 인해 더 이상 실행가능하지 않다.

심층 패킷 검사는 다른 단점들을 가진다. 예를 들어, 심층 패킷 검사는 또한 역사적으로, 네트워크들을 위한 부정적인 부작용들을 갖는 고가의 연산 동작으로 되었다.

따라서, 암호화된 데이터 패킷들을 반송하는 네트워크 트래픽을 식별하기 위한 것으로서, 연산적으로 고가의 심층 패킷 검사 프로세스들을 요구하지 않는 새로운 전략은 네트워크 분석 및 관리 기법들을 수행하기 위하여 유리할 것이다.

본 개시내용의 다양한 실시예들에서, 방법은 도메인 명칭 시스템(domain name system)(DNS) 서버로부터 제1 클라이언트 디바이스로 송신되는 제1 데이터 패킷 - 제1 데이터 패킷은 DNS 응답임 - 을 가로채는 단계; 제1 데이터 패킷으로부터 제1 인터넷 프로토콜(internet protocol)(IP) 어드레스 및 제1 호스트명을 추출하는 단계; 및 식별 테이블(identification table)의 제1 엔트리에서 제1 IP 어드레스 및 제1 호스트명을 저장하는 단계를 포함한다.

실시예에서, 방법은 컨텐츠 서버로부터 제2 클라이언트 디바이스로 송신되는 제2 데이터 패킷을 가로채는 단계; 제2 데이터 패킷의 헤더(header)로부터 제1 IP 어드레스를 추출하는 단계; 제2 데이터 패킷의 특성을 결정하는 단계; 및 결정된 특성으로 식별 테이블의 제1 엔트리를 업데이팅하는 단계를 더 포함한다.

실시예에서, 결정된 특성은 제2 데이터 패킷에서의 바이트(byte)들의 양, 제2 데이터 패킷의 타임스탬프(timestamp), 또는 그 조합이다.

실시예에서, 방법은 식별 테이블이 미리 결정된 크기를 초과할 때, 결정된 특성에 기초하여 식별 테이블로부터 제1 엔트리를 프루닝(pruning)하는 단계를 더 포함한다.

실시예에서, 방법은 컨텐츠 서버로부터 제2 클라이언트 디바이스로 송신되는 제2 데이터 패킷을 가로채는 단계; 제2 데이터 패킷의 헤더로부터 제2 IP 어드레스를 추출하는 단계; 식별 테이블에서의 제2 엔트리를 액세스함으로써 제2 IP 어드레스와 연관된 특성을 식별하는 단계; 및 제2 IP 어드레스와 연관된 특성에 기초하여 제2 데이터 패킷을 포함하는 데이터 흐름을 관리하는 단계를 더 포함한다.

실시예에서, 데이터 흐름을 관리하는 단계는 데이터 흐름이 네트워크의 과잉 네트워크 용량을 넘어서 제2 사용자 디바이스로 전송되게 하는 단계를 포함한다.

실시예에서, 제2 데이터의 페이로드(payload)는 암호화되고, 제2 IP 어드레스는 복호화를 수행하지 않으면서 헤더로부터 추출된다.

실시예에서, 제2 IP 어드레스와 연관된 특성은 제2 IP 어드레스와 연관된 호스트명, 제2 IP 어드레스와 연관된 전송된 바이트들의 양, 제2 IP 어드레스와 연관된 타임스탬프, 또는 그 조합이다.

실시예에서, 제1 데이터 패킷으로부터 IP 어드레스 및 호스트명을 추출하는 단계는 DNS 응답에서의 자원 레코드(resource record)(RR)들로부터 IP 어드레스 및 호스트명을 판독하는 단계를 포함한다.

실시예에서, DNS 응답에서의 RR들로부터 IP 어드레스 및 호스트명을 판독하는 단계는 DNS 응답의 'RDATA' 필드에서 IP 어드레스를 판독하는 단계, 및 DNS 응답의 'NAME' 필드에서 호스트명을 판독하는 단계를 포함한다.

실시예에서, 식별 테이블은 해시 테이블(hash table)이다.

본 개시내용의 다양한 실시예들에 따르면, 시스템은 프로세서; 및 프로그램 커맨드들을 저장하는 메모리 - 프로그램 커맨드들은, 프로세서에 의해 실행될 때, 제1 프로세서로 하여금: 도메인 명칭 시스템(DNS) 서버로부터 제1 클라이언트 디바이스로 송신되는 제1 데이터 패킷 - 제1 데이터 패킷은 DNS 응답임 - 을 가로채게 하고; 제1 데이터 패킷으로부터 제1 인터넷 프로토콜(IP) 어드레스 및 제1 호스트명을 추출하게 하고; 그리고 식별 테이블의 제1 엔트리에서 제1 IP 어드레스 및 제1 호스트명을 저장하게 함 - 를 포함한다.

실시예에서, 프로그램 커맨드들은, 프로세서에 의해 실행될 때, 추가로 프로세서로 하여금, 컨텐츠 서버로부터 제2 클라이언트 디바이스로 송신되는 제2 데이터 패킷을 가로채게 하고; 제2 데이터 패킷의 헤더로부터 제1 IP 어드레스를 추출하게 하고; 제2 데이터 패킷의 특성을 결정하게 하고; 그리고 결정된 특성으로 식별 테이블의 제1 엔트리를 업데이팅하게 한다.

실시예에서, 프로그램 커맨드들은, 프로세서에 의해 실행될 때, 추가로 프로세서로 하여금, 컨텐츠 서버로부터 제2 클라이언트 디바이스로 송신되는 제2 데이터 패킷을 가로채게 하고; 제2 데이터 패킷의 헤더로부터 제2 IP 어드레스를 추출하게 하고; 식별 테이블에서의 제2 엔트리를 액세스함으로써 제2 IP 어드레스와 연관된 특성을 식별하게 하고; 그리고 제2 IP 어드레스와 연관된 특성에 기초하여 제2 데이터 패킷을 포함하는 데이터 흐름을 관리하게 한다.

실시예에서, 프로세서는 DNS 응답에서의 자원 레코드(RR)들로부터 IP 어드레스 및 호스트명을 판독함으로써, 제1 데이터 패킷으로부터 IP 어드레스 및 호스트명을 추출한다.

실시예에서, DNS 응답에서의 RR들로부터 IP 어드레스 및 호스트명을 판독하는 것은 DNS 응답의 'RDATA' 필드에서 IP 어드레스를 판독하는 것, 및 DNS 응답의 'NAME' 필드에서 호스트명을 판독하는 것을 포함한다.

본 개시내용의 다양한 실시예들에 따르면, 시스템은 제1 프로세서 및 제1 메모리를 포함하는 도메인 명칭 시스템(DNS) 스파이(spy) - 제1 메모리는 프로그램 커맨드들을 저장하고, 프로그램 커맨드들은, 제1 프로세서에 의해 실행될 때, 제1 프로세서로 하여금: 복수의 제1 데이터 패킷들 - 제1 데이터 패킷들의 각각은 DNS 응답임 - 로부터 복수의 인터넷 프로토콜(IP) 어드레스들 및 복수의 호스트명들을 각각 추출하게 하고; 그리고 식별 테이블 - 식별 테이블은 복수의 IP 어드레스들에 의해 인덱싱됨 - 의 복수의 엔트리들에서 복수의 IP 어드레스들 및 복수의 호스트명들을 저장하게 함 -; 및 제2 프로세서 및 제2 메모리를 포함하는 전송 관리기 - 제2 메모리는 프로그램 커맨드들을 저장하고, 프로그램 커맨드들은, 제2 프로세서에 의해 실행될 때, 제2 프로세서로 하여금: 비-DNS 패킷의 헤더로부터 제2 IP 어드레스를 추출하게 하고; 제2 IP 어드레스를 포함하는 복수의 엔트리들 중의 하나를 판독하여 액세스함으로써, 제2 IP 어드레스에 대응하는 제2 호스트명을 결정하게 하고; 그리고 제2 호스트명에 기초하여 데이터 흐름 - 데이터 흐름은 제2 패킷을 포함함 - 을 관리하게 함 - 를 포함한다.

도 1은 본 개시내용의 실시예에 따른 시스템 아키텍처를 예시한다.
도 2는 본 개시내용의 실시예에 따른 시스템 아키텍처를 예시한다.
도 3a는 본 개시내용의 실시예에 따른 클라이언트 디바이스를 예시한다.
도 3b는 본 개시내용의 실시예에 따른 도메인 명칭 시스템(DNS) 스파이를 예시한다.
도 3c는 본 개시내용의 실시예에 따른 DNS 서버를 예시한다.
도 3d는 본 개시내용의 실시예에 따른 전송 관리기를 예시한다.
도 3e는 본 개시내용의 실시예에 따른 컨텐츠 서버를 예시한다.
도 4는 본 개시내용의 실시예에 따른 데이터 패킷을 예시한다.
도 5는 본 개시내용의 실시예에 따른 DNS 응답을 예시한다.
도 6은 본 개시내용의 실시예에 따른 식별 테이블을 예시한다.
도 7은 본 개시내용의 실시예에 따른, DNS 응답으로부터 호스트명 및 인터넷 프로토콜(IP) 어드레스를 추출하는 방법을 예시한다.
도 8은 본 개시내용의 실시예에 따른, 새로운 엔트리를 식별 테이블에 추가하는 방법을 예시한다.
도 9는 본 개시내용의 실시예에 따른, 비-DNS 패킷의 길이를 결정하는 방법을 예시한다.
도 10은 본 개시내용의 실시예에 따른, 비-DNS 패킷의 타임스탬프를 결정하는 방법을 예시한다.
도 11은 본 개시내용의 실시예에 따른, 식별 테이블의 엔트리를 업데이팅하는 방법을 예시한다.
도 12는 본 개시내용의 실시예에 따른, 식별 테이블을 이용하여 데이터 흐름을 관리하는 방법을 예시한다.
도 13은 본 개시내용의 실시예에 따른, 식별 테이블을 이용하여 엘리펀트 흐름(elephant flow)을 식별하고 페이싱(pacing)하는 방법을 예시한다.
도 14는 본 개시내용의 실시예에 따른, 식별 테이블의 크기를 제어하는 방법을 예시한다.
도 15는 본 개시내용의 실시예에 따른, 식별 테이블을 생성하고, 이용하고, 업데이팅하는 방법을 예시한다.

본 개시내용의 다양한 실시예들은, 서버로부터 송신된 도메인 명칭 서비스(DNS) 응답들을 식별하고, DNS 응답들에 기초하여 컨텐츠 전달 네트워크(content delivery network)(CDN) 서버의 인터넷 프로토콜(IP) 어드레스(들)와 도메인 명칭 사이의 맵핑을 생성하기 위하여 DNS 응답들을 파싱(parsing)하고, 이 도메인 명칭에 의해 클라이언트로부터 서버로의 특정 데이터 흐름을 추가로 식별하고, 맵핑된 도메인 명칭/서버 IP 어드레스에 기초하여 트래픽 관리 정책 또는 통계 수집을 적용하고, 전송된 데이터의 중요성 및 활성(activity)에 기초하여 맵으로부터의 엔트리들을 제거하고/만료시키고, 이전에 언급된 데이터 흐름들 상의 통계적 데이터를 전체적으로, 또는 도메인 명칭에 의해 결정된 바와 같이 수집하고/저장하고, 수집된 통계적 데이터의 전체를 분석함으로써 주어진 네트워크 상의 가장 중요한 도메인 명칭(들)을 결정하기 위한 시스템 및 방법에 관한 것이다.

실시예에 따르면, 디바이스, 시스템, 방법, 또는 그 조합은 데이터 흐름들에서의 애플리케이션 레벨 패킷 데이터가 암호화되더라도, 다양한 데이터 흐름들의 호스트명 및 대응하는 서버 IP 어드레스들의 맵핑(mapping) 또는 캐시(cache)를 캡처하고 생성하기 위하여 이용될 수 있다.

본원에서 이용된 바와 같이, 용어 "호스트명"은 특정 호스트, 컨텐츠 제공자, 컨텐츠, 또는 그 조합의 명칭을 지칭한다. 호스트명은 예를 들어, 별명(nickname), 노드명, 도메인 명칭, 웹 어드레스(web address), 또는 그 조합이다.

실시예에서, 역방향 DNS 룩업 테이블(lookup table)이 생성된다. 디바이스는 테이블을 액세스하고, 네트워크를 횡단하는 데이터 흐름들의 하나 또는 양자의 종점들을 식별하기 위하여 테이블 내의 엔트리들을 이용한다. 디바이스는 식별된 종점들에 기초하여 네트워크 관리 정책들을 구현한다. 예를 들어, 전송 관리기는 테이블을 액세스하고, 특정 데이터 흐름의 종점이 상대적으로 부담스러운 데이터 흐름들과 역사적으로 연관되었다는 것을 식별하기 위하여 테이블을 이용하고, 데이터 흐름을 페이싱한다.

도 1은 본 개시내용의 실시예에 따른 시스템(100) 아키텍처를 예시한다.

시스템(100)은 클라이언트 디바이스(110), 제1 네트워크(120), DNS 스파이(130), 제2 네트워크(140), 및 DNS 서버(150)를 포함한다.

클라이언트 디바이스(110)는 하나 이상의 사용자들로부터 하나 이상의 입력들을 수신하고, 제1 및 제2 네트워크들(120 및 140)을 통해 DNS 서버와 통신하도록 구성된다. 클라이언트 디바이스(110)는 예를 들어, 데스크톱 컴퓨터(desktop computer), 랩톱 컴퓨터(laptop computer), 태블릿 디바이스(tablet device), 스마트폰(smartphone), 전자-판독기(e-reader), 스마트 시계(smart watch), 스마트 텔레비전(smart television), 또는 그 조합이다.

제1 네트워크(120)는 클라이언트 디바이스(110) 및 DNS 스파이(130)를 서로에게 접속하는 유선 또는 무선 네트워크이다. 다양한 실시예들에 따르면, 제1 네트워크(120)는 머신들, 데이터베이스들, 및 디바이스들 사이 또는 그 중에서의 통신을 가능하게 하는 임의의 네트워크일 수도 있다. 따라서, 제1 네트워크(120)는 광역 액세스 네트워크(wide access network)(WAN), 유선 네트워크, 섬유 네트워크, 무선 네트워크(예컨대, 이동 또는 셀룰러 네트워크), 셀룰러 또는 전기통신 네트워크(예컨대, WiFi, 이동 통신들을 위한 글로벌 시스템(Global System for Mobile Communications)(GSM), 유니버셜 이동 전기통신 시스템(Universal Mobile Telecommunications System)(UMTS), 롱텀 에볼루션(Long Term Evolution)(LTE) 네트워크), 또는 그 임의의 적당한 조합일 수도 있다. 네트워크(130)는 사설 네트워크, 공개 네트워크(예컨대, 인터넷), 또는 그 임의의 적당한 조합 중의 하나 이상의 부분들을 포함할 수도 있다. 특정 실시예에서, 제1 네트워크(120)는 라디오 액세스 네트워크(radio access network)(RAN)에 링크하는 서브-노드(sub-node)들의 핵심 집합을 포함한다.

DNS 스파이(130)는 제1 네트워크(120) 및 제2 네트워크(140)를 통해 클라이언트 디바이스(110)와 DNS 서버(150) 사이에서 접속된다. 다양한 실시예들에서, DNS 스파이(130)는 DNS 서버(150)로부터 클라이언트 디바이스(110)로 전송된 DNS 응답들을 가로채고, DNS 응답들에서의 호스트명/IP 어드레스 쌍들에 기초하여 식별 테이블을 생성하고 및/또는 업데이팅하도록 구성된다. DNS 스파이(130)는 제1 네트워크(120), 제2 네트워크(140), 또는 양자를 횡단하는 다른 유형들의 패킷들(예컨대, 비-DNS 데이터 패킷들)을 또한 가로챌 수도 있고, 가로채어진 패킷들의 특성들에 기초하여 식별 테이블을 업데이팅할 수도 있다. 예를 들어, DNS 스파이(130)는 가로채어진 비-DNS 패킷으로부터 유도된 크기, 타임스탬프, 또는 양자로, 호스트명/IP 어드레스 쌍을 포함하는 현존하는 엔트리를 업데이팅할 수도 있다.

제2 네트워크(140)는 DNS 스파이(130) 및 DNS 서버(150)를 서로에게 접속하는 유선 또는 무선 네트워크이다. 특정 실시예에서, 제2 네트워크(140)는 인터넷이다.

DNS 서버(150)는 클라이언트 디바이스(110)를 포함하는 다양한 클라이언트 디바이스들로부터의 DNS 요청들에 응답하여 DNS 응답들을 생성하도록 구성된 서버 디바이스이다. 특정 호스트명을 특정하는 DNS 요청을 수신할 시에, DNS 서버(150)는 특정 호스트명과 연관된 IP 어드레스를 룩업(look up)한다. DNS 서버(150)는 그 다음으로, IP 어드레스를 요청 디바이스로 송신하여, 요청 디바이스는 호스트명과 연관된 컨텐츠 서버를 액세스할 수 있다.

실시예에서, 클라이언트 디바이스(110)는 제1 및 제2 네트워크들(120 및 140)과 같은 하나 이상의 네트워크들을 통해 DNS 요청을 DNS 서버(150)로 송신한다. DNS 응답은 호스트명, 예를 들어, "YOUTUBE" 또는 "YOUTUBE.COM"과 같은 비디오-호스팅 웹사이트(video-hosting website)의 명칭을 포함한다.

DNS 서버(150)가 DNS 요청을 수신할 때, DNS 서버(150)는 DNS 요청으로부터 호스트명을 추출하고, 호스트명과 연관된 IP 어드레스를 룩업한다. DNS 서버(150)는, 호스트명 및 호스트명과 연관된 IP 어드레스를 포함하는 DNS 응답을 생성한다. DNS 서버(150)는 제1 및 제2 네트워크들(120 및 140) 상에서 DNS 응답을 다시 클라이언트 디바이스(110)로 송신한다.

DNS 스파이(130)는 DNS 응답을 가로챈다. DNS 응답은 암호화되지 않으므로, DNS 스파이(130)는 복호화를 수행하지 않으면서, DNS 응답으로부터 호스트명 및 IP 어드레스를 추출한다. DNS 스파이(130)는 그 다음으로, 식별 테이블의 엔트리에서 호스트명/IP 어드레스 쌍을 저장한다. DNS 스파이(130)는 다수의 DNS 응답들을 가로채고 검사함으로써, 다수의 호스트명/IP 어드레스 쌍들을 식별 테이블의 엔트리들로 맵핑한다.

실시예에 따르면, DNS 스파이(130)는 트리거링 이벤트가 발생할 때에 식별 테이블을 프루닝함으로써, 식별 테이블의 크기를 제어한다. 예를 들어, DNS 스파이(130)는 식별 테이블이 미리 결정된 크기에 도달할 때, 식별 테이블에서의 하나 이상의 엔트리들을 삭제한다.

다양한 실시예들에서, DNS 서버(150)는 주어진 IP 어드레스에 기초하여 호스트명을 반환할 수 없다. 그러나, 식별 테이블을 액세스하는 디바이스(예컨대, 전송 관리기)는 특정 IP 어드레스를 포함하는 엔트리를 식별함으로써, 특정 IP 어드레스와 연관된 호스트명을 결정할 수 있다. DNS 스파이(130)에 의해 생성된 식별 테이블은 그러므로, 다양한 실시예들에 따라, 역방향 DNS 룩업 동작을 수행하기 위하여 이용될 수 있다.

도 2는 본 개시내용의 실시예에 따른 시스템(200) 아키텍처를 예시한다.

시스템(200)은 클라이언트 디바이스(210), 제1 네트워크(220), DNS 스파이(230), 제2 네트워크(240), DNS 서버(250), 제3 네트워크(260), 전송 관리기(270), 제4 네트워크(280), 및 컨텐츠 서버(290)를 포함한다. 도 2는 클라이언트 디바이스(210), 제1 네트워크(220), DNS 스파이(230), 제2 네트워크(240), DNS 서버(250), 제3 네트워크(260), 전송 관리기(270), 제4 네트워크(280), 및 컨텐츠 서버(290)의 각각 중의 하나를 오직 예시하지만, 시스템(200)은 다양한 실시예들에 따라, 클라이언트 디바이스(210), 제1 네트워크(220), DNS 스파이(230), 제2 네트워크(240), DNS 서버(250), 제3 네트워크(260), 전송 관리기(270), 제4 네트워크(280), 및 컨텐츠 서버(290)의 각각 중의 복수를 포함할 수 있다. 예를 들어, 다수의 클라이언트 디바이스들(210)은 제1 네트워크(220), 제3 네트워크(260), 또는 양자에 접속될 수 있고, 다수의 DNS 서버들(250)은 제2 네트워크(240)에 접속될 수 있고, 다수의 컨텐츠 서버들(290)은 제4 네트워크(280)에 접속될 수 있다.

다양한 실시예들에서, 클라이언트 디바이스(210), 제1 네트워크(220), DNS 스파이(230), 제2 네트워크(240), 및 DNS 서버(250)는 도 1에 대하여 위에서 설명된 클라이언트 디바이스(110), 제1 네트워크(120), DNS 스파이(130), 제2 네트워크(140), 및 DNS 서버(150)와 등가적이다. 어떤 실시예들에서, 제1 네트워크(220)는 제3 네트워크(260)와 동일하고, 제2 네트워크(240)는 제4 네트워크(280)와 동일하다. 따라서, DNS 스파이(230), 전송 관리기(270), 또는 양자는 클라이언트 디바이스(210)와 DNS 서버(250), 클라이언트 디바이스(210)와 컨텐츠 서버(290), 또는 양자의 사이에 있다.

클라이언트 디바이스(210)가 DNS 서버(250)로부터 요청된 IP 어드레스를 포함하는 DNS 응답을 수신할 때, 클라이언트 디바이스(210)는 IP 어드레스를 포함하는 컨텐츠에 대한 요청을 생성한다. 클라이언트 디바이스(210)는 제3 및 제4 네트워크들(260 및 280) 상에서 컨텐츠에 대한 요청을 컨텐츠 서버(290)로 송신한다.

제3 및 제4 네트워크들(260 및 280)와 연관된 장비는 IP 어드레스를 이용하여 컨텐츠에 대한 요청을 컨텐츠 서버(290)로 라우팅한다. 특정 실시예에서, 제3 네트워크(260)는 제1 네트워크(220)이고, 제4 네트워크(280)는 제2 네트워크(240)이다.

컨텐츠 서버(290)가 컨텐츠에 대한 요청을 수신할 때, 컨텐츠 서버(290)는 요청된 컨텐츠를 클라이언트 디바이스(210)로 송신한다.

다양한 실시예들에서, 클라이언트 디바이스(210)로부터의 컨텐츠에 대한 요청, 컨텐츠 서버(290)로부터의 컨텐츠, 또는 양자는 하나 이상의 데이터 패킷들의 형태로 각각 송신된다. 데이터 패킷들은 예를 들어, 비-DNS 데이터 패킷들이다.

전송 관리기(270)는 클라이언트 디바이스(210)로부터 컨텐츠 서버(290)로 송신된 컨텐츠에 대한 요청, 컨텐츠 서버(290)로부터 클라이언트 디바이스(210)로 송신된 하나 이상의 데이터 패킷들, 또는 양자를 가로채도록 구성된다. 다양한 실시예들에 따르면, 전송 관리기(270)는 하나 이상의 클라이언트 디바이스들과 하나 이상의 컨텐츠 서버들 사이의 제3 네트워크(260) 상에서 수송된 데이터 패킷들을 가로챈다.

전송 관리기(270)는 클라이언트 디바이스(210)와 컨텐츠 서버(290) 사이에서 위치된다. 실시예에서, 전송 관리기(270)는 제3 네트워크(260)를 제4 네트워크(280)에 접속하는 경계 트래픽 응집점(border traffic aggregation point)에 있다. 제3 네트워크(260)가 3 세대 파트너십 프로젝트(3rd Generation Partnership Project)(3GPP) 표준 이동 네트워크인 예에서, 응집점은 패킷 데이터 네트워크(Packet Data Network)(PDN)-게이트웨이 코어 엘리먼트에 접속하고 인터넷으로 외향하는 sGi-LAN의 일부이다. 제3 네트워크(260)가 4G 네트워크인 예에서, 응집점은 게이트웨이 GPRS 지원 노드(gateway GPRS support node)(GGSN)-게이트웨이에 접속하고 인터넷으로 외향하는 Gi-LAN의 일부이다. 그러나, 다른 실시예들에서, 전송 관리기(270)는 다른 곳에서 위치된다.

전송 관리기(270)는 제3 네트워크(260) 상에서 송신된 데이터 트래픽을 관리한다. 어떤 실시예들에서, 전송 관리기(270)는 제3 네트워크(260)를 통한 데이터 트래픽을 관리함으로써, 제3 네트워크(260)에서, 네트워크 자원들을 최적화하거나, 혼잡을 완화시키거나, 다른 데이터 관리 동작들을 수행하거나, 또는 그 조합을 행하도록 구성된다. 예를 들어, 전송 관리기(270)는 전송 관리기(270)에서 저장된 하나 이상의 정책들에 기초하여 클라이언트 디바이스(210)와 컨텐츠 서버(290) 사이의 데이터 흐름을 페이싱한다. 전송 관리기(270)는 데이터 흐름이 제3 네트워크(260)에 대해 상대적으로 부담스러운 것을 식별하거나, 제3 네트워크(260)가 현재 혼잡한 것으로 결정하거나, 데이터 흐름이 제3 네트워크(260)를 횡단하는 다른 데이터 흐름들과 비교하여 상대적으로 중요하지 않은 것으로 결정하거나, 또는 그 조합을 행한 후에, 데이터 흐름을 페이싱한다.

전송 관리기(270)는 데이터 흐름을 스로틀링(throttling)함으로써, 데이터 흐름에서의 데이터 패킷들을 일시적으로 저장함으로써, 데이터 흐름이 제3 네트워크(260) 이외의 네트워크를 횡단할 것을 요구함으로써, 또는 그 조합을 행함으로써, 데이터 흐름을 페이싱한다. 예를 들어, 전송 관리기(270)는 WIFI 네트워크가 클라이언트 디바이스(210)를 컨텐츠 서버(290)에 접속할 때, 데이터 흐름 내의 데이터 패킷들이 제3 네트워크(260)가 아니라, 로컬 WIFI 네트워크를 횡단할 것을 요구함으로써, 데이터 흐름을 페이싱할 수도 있다.

데이터 흐름들의 페이싱에 관한 추가의 세부사항들은, 2016년 3월 3일자로 출원되었고 이로써, 그 전체적으로 참조로 포함된 "SYSTEMS AND METHODS FOR PACING DATA FLOWS"라는 명칭의 공동으로-양도된 미국 출원 제15/060,486호에서 발견될 수도 있다.

다양한 실시예들에서, 전송 관리기(270)는 제3 네트워크(260)를 횡단하는 엘리펀트 흐름들을 선택적으로 페이싱한다. 엘리펀트 흐름은 제3 네트워크(260)에 대해 상대적으로 부담스러운 데이터 흐름이다. 예를 들어, 엘리펀트 흐름은 임계치보다 더 큰 전송된 데이터의 양을 포함하는 데이터 흐름, 임계치 기간을 초과하는 기간을 갖는 데이터 흐름, 특정한 파일 유형을 갖는 데이터 패킷들을 포함하는 데이터 흐름, 또는 그 조합이다.

일부 실시예들에서, 데이터 흐름은 데이터 흐름과 연관된 호스트명을 식별함으로써 엘리펀트 흐름으로서 식별될 수 있다. 실시예에서, 데이터 흐름이 엘리먼트 흐름들을 생성할 가능성이 있는 것으로 이전에 알려졌던 호스트에 속하는 것으로 식별되거나 이 호스트로부터의 것일 때, 전송 관리기(270)는 데이터 흐름을 엘리펀트 흐름으로서 식별한다. 예를 들어, 전송 관리기(270)가 컨텐츠 서버(290)가 상당한 양의 네트워크 자원들을 요구하는 데이터 패킷을 송신하는 호스트, 예컨대, 비디오 스트리밍 서비스(예컨대, YOUTUBE.COM, NETFLIX.COM 등)와 연관된다는 것을 식별할 때, 전송 관리기(270)는 컨텐츠 서버(290)와 클라이언트 디바이스(210) 사이의 데이터 흐름을 엘리펀트 흐름으로서 자동적으로 식별할 것이고, 데이터 흐름을 페이싱할 것이다. 또 다른 예에서, 전송 관리기(270)가 컨텐츠 서버(290)가 게이밍 서비스(gaming service)(예컨대, POKEMON GO 등)와 연관된다는 것을 식별할 때, 전송 관리기(270)는 컨텐츠 서버(290)와 클라이언트 디바이스(210) 사이의 데이터 흐름을 엘리펀트 흐름으로서 자동적으로 식별할 것이고, 데이터 흐름을 페이싱할 것이다. 엘리펀트 흐름들의 관리에 관한 추가의 세부사항들은, 2017년 9월 13일자로 출원되었고 이로써, 그 전체적으로 참조로 포함된 "DIRECTED HANDOVER OF ELEPHANT FLOWS"라는 명칭의 공동으로-양도된 미국 출원 제15/703,908호에서 발견될 수도 있다.

실시예에서, 전송 관리기(270)는 본 개시내용의 다양한 실시예들에 따라, 컨텐츠 서버(290)와 연관된 호스트명을 식별함으로써, 관리를 위하여 컨텐츠 서버(290)와 클라이언트 디바이스(210) 사이의 데이터 흐름을 식별한다. 전송 관리기(270)는 제3 네트워크(260)를 횡단하는, 컨텐츠 서버(290)와 클라이언트 디바이스(210) 사이에서 송신된 데이터 패킷들을 가로챔으로써 호스트명을 식별한다.

데이터 패킷들은 호스트명을 식별하는 정보를 포함하지만, 이 정보는 암호화된다. 예를 들어, 호스트명은 데이터 패킷들의 각각의 암호화된 페이로드 내에 포함된다.

데이터 패킷들을 복호화하는 것이 아니라, 실시예에서, 전송 관리기(270)는 데이터 패킷들 중의 하나로부터 컨텐츠 서버(290)의 IP 어드레스를 추출함으로써, 스토리지(storage)(232)에서 저장된 정보 테이블을 액세스함으로써, 추출된 IP 어드레스를 포함하는 정보 테이블에서의 엔트리를 식별함으로써, 그리고 식별된 엔트리를 판독하는 것에 의해 호스트명을 결정함으로써, 컨텐츠 서버(290)의 호스트명을 식별한다. 정보 테이블은 다양한 실시예들에 따라, DNS 스파이(230)에 의해 생성된다.

따라서, 전송 관리기(270)는 데이터 흐름들 내의 개별적인 데이터 패킷들을 복호화하는 것이 아니라, DNS 스파이에 의해 생성된 정보 테이블을 액세스함으로써, 제3 네트워크(260)를 횡단하는 데이터 흐름들을 관리한다.

일부 실시예들에서, DNS 스파이(230), 전송 관리기(270), 및 스토리지(232)는 별도의 그리고 상호접속된 디바이스들이다. 다른 실시예들에서, DNS 스파이(230), 전송 관리기(270), 및 스토리지(232)는 동일한 디바이스이다.

도 3a 내지 도 3e는 본 개시내용의 다양한 실시예들에 따른 디바이스들을 예시한다. 도 3a 내지 도 3e에서 도시된 디바이스들 중의 임의의 것은 그 머신, 데이터베이스, 또는 디바이스를 위하여 본원에서 설명된 기능들을 수행하기 위하여 특수-목적 컴퓨터가 되도록 소프트웨어에 의해 수정된(예컨대, 구성되거나 프로그래밍된) 범용 컴퓨터에서 구현될 수도 있다. 또한, 도 3a 내지 도 3e에서 예시된 머신들, 데이터베이스들, 또는 디바이스들 중의 임의의 2 개 이상은 단일 머신으로 조합될 수도 있고, 임의의 단일 머신, 데이터베이스, 또는 디바이스를 위하여 본원에서 설명된 기능들은 다수의 머신들, 데이터베이스들, 또는 디바이스들 중에서 재분할될 수도 있다.

도 3a는 본 개시내용의 실시예에 따른 클라이언트 디바이스(310)를 예시한다. 클라이언트 디바이스(310)는 이동 디바이스들(예컨대, 랩톱들, 스마트폰들, 태블릿 컴퓨터들 등), 컴퓨팅 디바이스들, 셋톱 박스들, 차량 컴퓨팅 디바이스들, 게이밍 디바이스들 등과 같은 다양한 유형들의 사용자 디바이스들을 포함할 수도 있다. 클라이언트 디바이스(310)는 Microsoft® Windows®, Mac OS®, iOS®, Google® Chrome®, Linux®, Unix®, 또는 Symbian®, Palm®, Windows Mobile®, Google® Android®, Mobile Linux® 등을 포함하는 임의의 다른 이동 오퍼레이팅 시스템과 같은 다양한 상이한 오퍼레이팅 시스템들을 지원할 수도 있고 작동시킬 수도 있다.

클라이언트 디바이스(310)는 인터페이스(312), 프로세서(314), 스토리지(316), 및 하나 이상의 앱(app)들(316)을 포함한다.

인터페이스(312)는 예를 들어, 터치 스크린, 키보드, 카메라, 하나 이상의 센서들, 또는 그 조합을 포함한다. 실시예에서, 클라이언트 디바이스(310)는 인터페이스(312)를 통해 사용자로부터 입력을 수신한다. 특정 실시예에서, 입력은 컨텐츠의 출발지(source)의 호스트명을 특정한다. 예를 들어, 입력은 인터넷 상의 특정 웹사이트의 유니버셜 자원 로케이터(universal resource locator)(URL) 어드레스를 특정한다.

프로세서(314)는 프로그램 커맨드들을 실행한다. 스토리지(316)는 예를 들어, 프로세서(312)에 의해 실행되는 프로그램 커맨드들을 저장한다. 실시예에서, 스토리지(316)는 로컬 메모리이다.

클라이언트 디바이스(310)는 하나 이상의 앱들(316)을 작동시킨다. 실시예에서, 하나 이상의 앱들(316)은 인터넷 브라우저 애플리케이션(internet browser application), 비디오 스트리밍 애플리케이션(video streaming application), 비디오 게임 앱(video game app) 등을 포함한다.

실시예에서, 클라이언트 디바이스(316)는 알려진 호스트명과 연관된 컨텐츠 서버의 IP 어드레스를 요청하고, 요청된 IP 어드레스를 식별하는 DNS 응답을 수신하도록 구성된다. 클라이언트 디바이스(316)는 추가로, IP 어드레스를 이용하여 요청을 컨텐츠 서버로 송신함으로써 컨텐츠를 요청하고, 하나 이상의 데이터 패킷들의 형태로 컨텐츠 서버로부터 요청된 컨텐츠를 수신한다.

도 3b는 본 개시내용의 실시예에 따른 DNS 스파이(330)를 예시한다. DNS 스파이(330)는 인터페이스(332), 프로세서(334), 제1 스토리지(336), 및 제2 스토리지(390)를 포함한다.

제2 스토리지(390)는 DNS 스파이(330)에 의해 생성된 식별 테이블(392)을 저장한다. 식별 테이블(392)은 실시예에 따라, 복수의 IP 어드레스/호스트명 쌍들을 각각 식별하는 복수의 엔트리들을 포함한다. 제2 스토리지(390)는 DNS 스파이(330)의 내부에서 예시되지만, 제2 스토리지(390)는 실시예에서, DNS 스파이(330)로부터 분리되어 있는 스트로지 디바이스일 수도 있다.

다양한 실시예들에서, DNS 스파이(330)는 하나 이상의 DNS 서버들과 하나 이상의 클라이언트 디바이스들 사이에서 위치된다. 하나 이상의 DNS 서버들 및 하나 이상의 클라이언트 디바이스들로부터 송신된 DNS 응답은 DNS 스파이(220)를 통과하거나, DNS 스파이(220)에 의해 가로채어진다. DNS 스파이(220)는 예를 들어, DNS 응답들에서의 자원 레코드(resource record)(RR)들로부터 호스트명들 및 IP 어드레스를 판독한다. DNS 응답의 RR들에서의 호스트명 및 IP 어드레스는 암호화되지 않는다.

DNS 스파이(330)는 DNS 응답들로부터 복수의 호스트명/IP 어드레스 쌍들을 식별한다. DNS 스파이(220)는 제2 스토리지(390)에서, 식별 테이블(392)에서의 호스트명/IP 어드레스 쌍들을 저장한다. 실시예에서, 호스트명/IP 어드레스 쌍들은 식별 테이블(392)에서의 개개의 엔트리들 내에 포함된다.

다양한 실시예들에서, 식별 테이블(392)은 전송 관리기와 같은 다른 디바이스들에 의해 액세스가능하다. 전송 관리기는 예를 들어, 식별 테이블(392)에서의 엔트리들을 판독함으로써 네트워크 트래픽을 관리할 수 있다.

도 3c는 본 개시내용의 실시예에 따른 DNS 서버(350)를 예시한다. DNS 서버(350)는 프로세서(352), 스토리지(354), 및 DNS 레코드들(358)을 포함한다.

프로세서(352)는 스토리지(354)에서 저장된 하나 이상의 정책들(356)을 실행한다. 예를 들어, 프로세서(352)는 스토리지(354)에서 저장된 프로그램 커맨드들을 실행한다.

DNS 서버(350)가 호스트명을 포함하는 DNS 요청을 수신할 때, DNS 서버(350)는 호스트명과 연관된 IP 어드레스에 대한 DNS 레코드들(358)을 검색한다. IP 어드레스는 예를 들어, 호스트명과 연관된 컨텐츠 서버를 위한 IP 어드레스이다. DNS 레코드들(358)은, DNS 서버(350)가 주어진 호스트명과 연관된 IP 어드레스를 검색할 수 있지만, 주어진 IP 어드레스와 연관된 호스트명을 검색할 수 없도록 구조화된다.

DNS 서버(350)는 그 다음으로, 호스트명 및 IP 어드레스를 포함하는 복수의 RR들을 포함하는 DNS 응답을 생성한다. DNS 서버(350)는 DNS 응답을 DNS 요청의 출발지로 송신한다. 예를 들어, DNS 요청이 클라이언트 디바이스로부터 송신될 때, DNS 서버(350)는 DNS 응답을 클라이언트 디바이스로 송신한다.

도 3d는 본 개시내용의 실시예에 따른 전송 관리기(370)를 예시한다.

전송 관리기(270)는 하나 이상의 조건들이 만족될 때에 네트워크를 횡단하는 데이터 트래픽을 관리하도록 구성된다. 일부 실시예들에서, 전송 관리기(370)는 과잉 네트워크 대역폭 또는 과잉 네트워크 용량을 사용하거나 이용하는 전달 정책을 통해 컨텐츠의 전달을 지시하거나 관리하는 전달 관리기이다. 네트워크 대역폭 또는 네트워크 용량의 과잉은 네트워크의 총 용량 및/또는 네트워크의 총 사용량을 고려하여 네트워크에서 이용가능한(예컨대, 아이들(idle) 또는 자유로운(free)) 것으로 결정되는 네트워크 대역폭 또는 네트워크 용량일 수도 있다. 일부 실시예들에서, 네트워크 제공자는 네트워크의 총 용량 및/또는 네트워크의 총 사용량을 고려하여 네트워크에서 이용가능한 과잉 네트워크 용량의 양을 결정한다. 과잉 네트워크 용량은 통계적으로 또는 동적으로 결정될 수도 있고, 그러므로, 네트워크를 위한 결정된 과잉 네트워크 용량은 긴 또는 짧은 시간 스케일들에 대하여, 및/또는 하나의 서비스 제공자 내지 또 다른 것 사이에서 시간 경과에 따라(예컨대, 피크 이용 주기들 동안에) 실질적으로 및/또는 무작위적으로 변동될 수도 있다.

그러므로, 과잉 용량은 대역폭의 실제적인 및/또는 현재의 사용량과 총 용량(또는 총 용량의 미리 결정된 백분율) 사이의 자유 대역폭 또는 용량일 수도 있다. 그러므로, 전송 관리기(370)는, 그렇지 않을 경우에는 이용 중이지 않을 현재 과소이용된 네트워크들 상에서, 및/또는 네트워크를 공유하는 다른 데이터 트래픽과 연관된 수송 성능에 실질적으로 영향을 주거나 수송 성능을 변경하지 않으면서, 데이터를 전달하는 경로들 또는 프로토콜들과 같은, 네트워크들의 자유롭거나, 이용가능하거나, 아이들이거나, 또는 그렇지 않을 경우에는 과잉인 대역폭들 또는 용량들을 사용하는 다양한 선택된 전달 정책들 또는 프로토콜들 상에서, 컨텐츠 제공자들(예컨대, 컨텐츠 서버들), 네트워크 에지 캐시(network edge cache)들, 및 클라이언트 디바이스들 사이의 컨텐츠의 전달을 지시할 수도 있거나 관리할 수도 있다.

과잉 네트워크 용량을 이용한 컨텐츠의 전달에 관한 추가의 세부사항들은, 그 전부가 이로써 그 전체적으로 참조로 포함되는, ADAPTIVE FILE DELIVERY SYSTEM AND METHOD라는 명칭으로 2009년 3월 3일자로 등록된, 공동-양도된 미국 특허 제7,500,010호, ADAPTIVE FILE DELIVERY SYSTEM AND METHOD라는 명칭으로 2013년 11월 19일자로 등록된 미국 특허 제8,589,585호, SYSTEM AND METHOD FOR PROGRESSIVE DOWNLOAD USING SURPLUS NETWORK CAPACITY라는 명칭으로 2010년 4월 15일자로 출원된 미국 특허 출원 공개 제2010/0198943호, 및 SYSTEM AND METHOD FOR PROGRESSIVE DOWNLOAD WITH MINIMAL PLAY LATENCY라는 명칭으로 2013년 1월 3일자로 출원된 미국 특허 출원 공개 제2013/0124679호에서 발견될 수도 있다.

전송 관리기(370)는 인터페이스(372), 프로세서(374), 큐(queue)(376), 관리기(378), 및 스토리지(380)를 포함한다.

프로세서(374)는 스토리지(380)에서 저장된 하나 이상의 정책들(382)을 실행한다. 예를 들어, 프로세서(374)는 스토리지(380)에서 저장된 프로그램 커맨드들을 실행한다. 전송 관리기(370)의 다양한 기능들은 프로세서(374)에 의해 실행된다.

전송 관리기(370)는 네트워크를 횡단하는 데이터 흐름들의 특성들 및 네트워크 자체의 특성들을 식별하고, 특성들에 기초하여 데이터 흐름들을 관리한다. 실시예에서, 전송 관리기(370)는 데이터 흐름에서의 데이터 패킷을 가로챔으로써, 데이터 패킷으로부터 데이터 패킷의 출발지의 IP 어드레스를 판독함으로써, 그리고 식별 테이블을 액세스하는 것에 의해 데이터 패킷의 출발지의 호스트명을 식별함으로써, 관리를 위하여 데이터 흐름을 식별한다.

예를 들어, 전송 관리기(370)가 데이터 흐름의 출발지의 호스트명에 기초하여, 네트워크를 횡단하는 데이터 흐름이 엘리펀트 흐름인 것으로 결정할 때, 전송 관리기(370)는 데이터 흐름을 페이싱한다. 특정 예에서, 전송 관리기(370)는 큐(376)에서 엘리펀트 흐름의 패킷들을 포함하는 데이터를 일시적으로 저장하고, 과잉 네트워크 용량이 이용가능할 때, 네트워크의 과잉 네트워크 용량을 넘어서 패킷들을 그 목적지로 선택적으로 배출(release)한다.

도 3e는 본 개시내용의 실시예에 따른 컨텐츠 서버(390)를 예시한다. 컨텐츠 서버(390)는 인터페이스(392), 프로세서(394), 및 스토리지(396)를 포함한다.

프로세서(394)는 스토리지(396)에서 저장된 하나 이상의 정책들(392)을 실행한다. 예를 들어, 프로세서(394)는 스토리지(396)에서 저장된 프로그램 커맨드들을 실행한다. 컨텐츠 서버(390)의 다양한 기능들은 프로세서(394)에 의해 실행된다.

컨텐츠 서버(390)는 출발지로부터 컨텐츠에 대한 요청을 수신하고, 요청에 응답하여, 스토리지(396)에서 저장된 파일들(398) 중의 하나 이상을 송신한다. 컨텐츠 서버(390)는 예를 들어, 복수의 데이터 패킷들의 형태로 하나 이상의 파일들(398)을 송신한다.

컨텐츠 서버(390)는 다양한 상이한 미디어, 및 비디오 컨텐츠(예컨대, 영화들, 텔레비전 쇼들, 뉴스 프로그래밍, 비디오 클립들), 이미지 컨텐츠(예컨대, 이미지 또는 픽처 슬라이드쇼(slideshow)들), 오디오 컨텐츠(예컨대, 라디오 프로그래밍, 음악, 팟캐스트(podcast)들) 등과 같은 다른 컨텐츠 유형들을 제공할 수도 있다. 컨텐츠 서버(390)는, 다양한 미디어 전송 프로토콜들(예컨대, 하이퍼텍스트 전송 프로토콜(Hypertext Transfer Protocol)(HTTP), 파일 전송 프로토콜(File Transfer Protocol)(FTP), HTTP 라이브 스트리밍(HTTP Live Streaming)(HLS), HTTP 동적 스트리밍(HTTP Dynamic Streaming)(HDS), HTTP 스무스 스트리밍(HTTP Smooth Streaming)(HSS), 동적 적응적 스트리밍 오버 HTTP(Dynamic Adaptive Streaming over HTTP)(DASH), 실시간 스트리밍 프로토콜(Real Time Streaming Protocol)(RTSP) 등)을 통해 컨텐츠를 요청 디바이스들(예컨대, 사용자 장비(110a 내지 110c))로 전달할 수도 있고, 전송할 수도 있고, 수송할 수도 있고, 및/또는 그렇지 않을 경우에는 제공할 수도 있는 네트워크 에지 캐시들(도시되지 않음)로, 미디어 파일들 및 다른 컨텐츠를 전달할 수도 있고, 전송할 수도 있고, 수송할 수도 있고, 및/또는 그렇지 않을 경우에는 제공할 수도 있다.

도 4는 본 개시내용의 실시예에 따른 데이터 패킷(400)을 예시한다. 데이터 패킷(400)은 헤더(410) 및 페이로드(420)를 포함한다.

헤더(410)는 출발지 IP 어드레스(412) 및 목적지 IP 어드레스(414)를 포함한다. 출발지 IP 어드레스(412)는 데이터 패킷(400)의 출발지의 IP 어드레스이고, 목적지 IP 어드레스(414)는 데이터 패킷(400)의 목적지의 IP 어드레스이다. 헤더(410)는 실시예에 따라, 암호화되지 않는다.

페이로드(420)는 하나 이상의 파일들(422)을 포함한다. 페이로드(420)는 예를 들어, 애플리케이션 계층 데이터를 포함한다. 페이로드(420)는 암호화된다.

실시예에서, 데이터 패킷(400)은 컨텐츠 서버와 클라이언트 디바이스 사이에서 송신되고, 전송 관리기에 의해 가로채어진다.

도 5는 본 개시내용의 실시예에 따른 DNS 응답(500)을 예시한다.

DNS 응답(500)은 복수의 RR들(510)을 포함한다. 예를 들어, RR들(510)은 RDATA 필드(512) 및 NAME 필드(514)를 포함한다. RDATA 필드(512)는 IP 어드레스를 포함하고, NAME 필드(514)는 IP 어드레스와 연관된 호스트명을 포함한다.

실시예에서, DNS 응답(500)은 DNS 서버로부터 클라이언트 디바이스로 송신된다. 또한, DNS 응답(500)은 암호화되지 않는다. DNS 스파이는 예를 들어, DNS 서버로부터 클라이언트 디바이스로 송신된 DNS 응답(500)을 가로채고, 복호화를 수행하지 않으면서, RDATA 필드(512)로부터 IP 어드레스를, 그리고 NAME 필드(514)로부터 호스트명을 판독한다.

도 6은 본 개시내용의 실시예에 따른 식별 테이블(600)을 예시한다.

식별 테이블(600)은 복수의 엔트리들(610_1 내지 610_N)을 포함하고, 여기서, N은 식별 테이블(600)의 크기이다. 엔트리들(610_1 내지 610_N)의 각각은 특정 호스트명/IP 어드레스 쌍에 대응한다. 식별 테이블(600)은 실시예에서, 호스트명/IP 어드레스 쌍들의 IP 어드레스들에 의해 인덱싱된 캐시 테이블이다.

엔트리들(610_1 내지 610_N)의 각각은 IP 어드레스, 호스트명, IP 어드레스로부터의 데이터 패킷의 최후 활성 시간, 및 IP 어드레스로부터 송신된 데이터 트래픽과 연관된 누적 바이트들의 양을 포함한다.

이 개시내용에서, 최후 활성 시간 및 누적 바이트들의 양과 같은 필드들은 대응하는 호스트명/IP 어드레스 쌍들의 "특성들"로 칭해질 수도 있다. 실시예에서, 특성들은 식별 테이블(600)에서 하나 이상의 가장 덜 중요한 엔트리들을 식별하기 위하여 DNS 스파이에 의해 이용된다. DNS 스파이는 그 다음으로, 프루닝 동작에서 식별 테이블(600)로부터 가장 덜 중요한 엔트리들을 프루닝할 수도 있다.

일부 실시예들에서, 특성들은 상대적으로 부담스러운 데이터 흐름들과 연관된 호스트명/IP 어드레스 쌍들을 식별하기 위하여 전송 관리기에 의해 이용된다. 예를 들어, 전송 관리기는 누적 바이트들의 상대적으로 큰 양들을 포함하는 엔트리들을 엘리펀트 흐름들과 연관될 가능성이 있는 것으로서 식별한다.

다양한 실시예들에 따르면, 엔트리들(610_1 내지 610_N)의 각각은 DNS 스파이에 의해 생성되고 업데이팅되고, 스토리지에서 저장된다.

도 7은 본 개시내용의 실시예에 따른, DNS 응답으로부터 호스트명 및 IP 어드레스를 추출하는 방법(700)을 예시한다. 방법(700)은 예를 들어, DNS 스파이에 의해 수행될 수도 있다.

S710에서, 패킷이 수신된다. 실시예에서, 패킷은 그것이 DNS 서버로부터 클라이언트 디바이스로 송신되고 있을 때에 가로채어진다.

S720에서, 패킷은 DNS 응답으로서 식별된다.

패킷이 DNS 응답으로서 식별된 후에, 호스트명 및 IP 어드레스는 S730에서, DNS 응답으로부터 추출된다. 호스트명 및 IP 어드레스는 DNS 응답에서의 RR들로부터 판독된다. 예를 들어, 호스트명은 자원 레코드들에서의 NAME 필드로부터 판독되고, IP 어드레스는 자원 레코드들에서의 RDATA 필드로부터 판독된다.

도 8은 본 개시내용의 실시예에 따른, 새로운 엔트리를 식별 테이블에 추가하는 방법(800)을 예시한다. 실시예에서, 방법(800)은 DNS 스파이에 의해 수행된다.

호스트명 및 IP 어드레스 쌍은 S810에서 결정된다. 예를 들어, 호스트명 및 IP 어드레스는 DNS 응답으로부터 판독된다.

도 9는 본 개시내용의 실시예에 따른, 비-DNS 패킷의 길이를 결정하는 방법(900)을 예시한다. 방법(900)은 예를 들어, DNS 스파이에 의해 수행된다.

S910에서, 데이터 패킷이 수신된다. 실시예에서, 데이터 패킷은 컨텐츠 서버와 클라이언트 디바이스 사이에서 송신되는 동안에 가로채어진다.

데이터 패킷은 S920에서, 비-DNS 패킷으로서 식별된다. 데이터 패킷은 DNS 요청 또는 DNS 응답이 아니다. 비-DNS 패킷은 예를 들어, 비디오 스트리밍 패킷이다.

S930에서, 데이터 패킷의 크기가 결정된다. 예를 들어, 패킷 내에 포함된 바이트들의 수가 결정된다.

도 10은 본 개시내용의 실시예에 따른, 비-DNS 패킷의 타임스탬프를 결정하는 방법(1000)을 예시한다. 방법(1000)은 예를 들어, DNS 스파이에 의해 수행된다.

S1010에서, 데이터 패킷이 수신된다. 실시예에서, 데이터 패킷은 컨텐츠 서버와 클라이언트 디바이스 사이에서 송신되는 동안에 가로채어진다.

데이터 패킷은 S1020에서, 비-DNS 패킷으로서 식별된다. 데이터 패킷은 DNS 요청 또는 DNS 응답이 아니다. 비-DNS 패킷은 예를 들어, 비디오 스트리밍 패킷이다.

다음으로, S1030에서, 패킷과 연관된 타임스탬프가 결정된다. 예를 들어, 타임스탬프는 데이터 패킷이 수신되는 시간이다. 또 다른 예에서, 타임스탬프는 비-DNS 패킷으로부터 직접적으로 유도된다.

도 11은 본 개시내용의 실시예에 따른, 식별 테이블의 엔트리를 업데이팅하는 방법(1100)을 예시한다. 방법(1100)은 예를 들어, DNS 스파이에 의해 수행된다.

S1110에서, 비-DNS 패킷의 IP 어드레스 및 특성이 결정된다. 실시예에서, 비-DNS 패킷은 컨텐츠 서버와 클라이언트 디바이스 사이에서 가로채어진다. 예에서, IP 어드레스는 데이터 패킷의 출발지의 IP 어드레스이고, 비-DNS 패킷의 비-암호화된 헤더로부터 IP 어드레스를 판독함으로써 결정된다. 실시예에 따르면, 특성은 데이터 패킷의 크기, 데이터 패킷의 타임스탬프, 또는 그 조합이다.

S1120에서, 식별 테이블에서의 엔트리가 식별된다. 엔트리는 예를 들어, IP 어드레스 및 IP 어드레스와 연관된 호스트명을 포함한다.

엔트리는 S1130에서, 특성에 기초하여 업데이팅된다. 예를 들어, 엔트리가 IP 어드레스 필드, 호스트명 필드, 최후 활성 시간 필드, 및 누적 바이트들의 수 필드를 포함할 때, 최후 활성 시간 필드는 데이터 패킷의 타임스탬프에 기초하여 업데이팅되고, 누적 바이트들의 수 필드는 데이터 패킷의 크기에 기초하여 업데이팅된다.

도 12는 본 개시내용의 실시예에 따른, 식별 테이블을 이용하여 데이터 흐름을 관리하는 방법(1200)을 예시한다. 방법(1200)은 예를 들어, 전송 관리기에 의해 수행된다.

S1210에서, 데이터 흐름에서의 패킷이 수신된다. 패킷은 예를 들어, 헤더 및 페이로드를 포함하는 데이터 패킷이다. 헤더는 비암호화된다. 페이로드는 암호화되고, 애플리케이션 계층 데이터를 포함한다.

S1220에서, IP 어드레스는 패킷의 헤더로부터 식별된다. IP 어드레스는 패킷의 목적지를 표시한다. 실시예에서, 패킷의 출발지의 IP 어드레스는 패킷의 헤더를 판독함으로써 유도된다. IP 어드레스는 예를 들어, 컨텐츠 서버의 IP 어드레스이다.

S1230에서, 식별된 IP 어드레스와 연관된 호스트명은 식별 테이블을 액세스함으로써 결정된다. 식별 테이블은 복수의 엔트리들에서의 복수의 IP 어드레스/호스트명 쌍들을 포함한다. 실시예에서, 식별 테이블은 IP 어드레스들에 의해 인덱싱되는 캐시 테이블(cache table)이다. 따라서, 식별된 IP 어드레스와 연관된 호스트명은 식별된 IP 어드레스를 포함하는 식별 테이블에서의 엔트리를 식별함으로써 그리고 식별된 엔트리에서의 대응하는 호스트명을 판독함으로써 결정될 수 있다.

데이터 흐름은 S1240에서, 식별된 호스트명에 기초하여 관리된다. 예를 들어, 데이터 흐름은 식별된 호스트명이 네트워크에 대해 부담스러운 데이터 트래픽과 역사적으로 연관되었던 호스트에 대응하는 것으로 결정될 때에 페이싱된다. 특정 예에서, 데이터 흐름은 식별된 호스트명에 기초하여 엘리펀트 흐름으로서 식별되고, 데이터 흐름은 페이싱된다.

도 13은 본 개시내용의 실시예에 따른, 식별 테이블을 이용하여 엘리펀트 흐름을 식별하고 페이싱하는 방법(1300)을 예시한다. 방법(1300)은 예를 들어, 전송 관리기에 의해 수행된다.

S1310에서, 데이터 흐름에서의 패킷이 수신된다. 패킷은 예를 들어, 비-DNS 데이터 패킷이다. 실시예에서, 패킷의 복사본은 일시적으로 캐싱되고, 패킷 자체는 배출되어, 패킷은 임의의 상당한 지연들 없이 그 목적지에 도달할 수 있다.

S1320에서, IP 어드레스는 패킷의 헤더로부터 식별된다. 실시예에서, IP 어드레스는 패킷의 목적지 또는 패킷의 출발지를 표시한다. 다양한 실시예들에서, 패킷의 목적지를 표시하는 IP 어드레스, 및 패킷의 출발지를 표시하는 IP 어드레스가 양자 모두 결정된다. IP 어드레스는 예를 들어, 컨텐츠 서버의 IP 어드레스이다.

식별된 IP 어드레스와 연관된 호스트명은 S1330에서, 식별 테이블을 액세스함으로써 결정된다. 식별 테이블은 복수의 이전에 식별된 호스트명/IP 어드레스 쌍들을 저장하고, IP 어드레스에 의해 인덱싱된다. 실시예에서, 호스트명은 식별된 IP 어드레스를 포함하는 엔트리로부터 취출(retrieve)된다.

S1340에서, 데이터 흐름은 호스트명에 기초하여, 엘리펀트 흐름인 것으로 결정된다. 예를 들어, 데이터 흐름은 호스트명이 알려진 비디오 스트리밍 호스트를 표시할 때에 엘리펀트 흐름으로서 식별된다.

데이터 흐름이 엘리펀트 흐름인 것으로 결정된 후에, 데이터 흐름은 S1350에서 페이싱된다. 실시예에서, 네트워크를 횡단하는 데이터 흐름에서의 복수의 데이터 패킷들은 데이터 흐름이 엘리펀트 흐름인 것으로 결정된 후에 관리된다. 예를 들어, 데이터 흐름의 데이터 패킷들은 과잉 네트워크 용량을 넘어서 선택적으로 라우팅될 수도 있다. 특정 실시예에서, 그 데이터 흐름의 데이터 패킷들은 데이터 흐름에서의 데이터 패킷들을 수신하는 클라이언트 디바이스에 접속되는 WIFI 네트워크와 같은, 상이한 네트워크가 이용가능할 때, 상이한 네트워크 상에서 선택적으로 라우팅된다.

도 14는 본 개시내용의 실시예에 따른, 식별 테이블의 크기를 제어하는 방법(1400)을 예시한다. 방법(1400)은 예를 들어, DNS 스파이에 의해 수행된다.

S1410에서, 새로운 엔트리는 식별 테이블에 추가된다. 새로운 엔트리는 호스트명/IP 어드레스 쌍을 포함한다. 예를 들어, 새로운 엔트리는 식별 테이블 내에 이전에 포함되지 않았던 호스트명/IP 어드레스 쌍을 포함한다.

S1420에서, 식별 테이블의 크기는 미리 결정된 크기를 초과하는 것으로 결정된다. 다양한 실시예들에서, 크기는 인덱스들의 수, 식별 테이블을 저장하기 위하여 요구된 메모리의 양, 또는 그 조합으로서 정의된다.

S1430에서, 식별 테이블의 하나 이상의 엔트리들은 식별 테이블로부터 프루닝된다. 예를 들어, 하나 이상의 엔트리들은 식별 테이블로부터 삭제된다.

하나 이상의 프루닝된 엔트리들은 다양한 방법들로 식별될 수 있다. 일부 실시예들에서, 하나 이상의 엔트리들은 식별 테이블의 가장 덜 중요한 엔트리들이다. 가장 덜 중요한 엔트리들은 식별 테이블의 특성들 필드들에 기초하여 식별될 수 있다. 예를 들어, 엔트리들의 각각이 호스트명/IP 어드레스 쌍들에 대응하는 가장 최근에 관찰된 데이터 패킷을 표시하는 타임스탬프를 포함할 경우에, 가장 오래된 타임스탬프들을 갖는 엔트리들은 식별 테이블로부터 프루닝된다. 또 다른 예에서, 엔트리들의 각각이 호스트명/IP 어드레스 쌍들에 대응하도록 관찰된 전송된 바이트들의 수를 포함할 경우에, 전송된 바이트들의 최저 수를 갖는 엔트리들은 식별 테이블로부터 프루닝된다. 일부 실시예들에서, 하나 이상의 엔트리들은 다수의 기준들의 조합에 기초하여 식별된다.

하나 이상의 프루닝된 엔트리들의 수는 다양한 방법들로 또한 식별될 수 있다. 예를 들어, 식별 테이블이 그 최대 크기에 도달할 때, 엔트리들의 미리 결정된 백분율은 식별 테이블로부터 삭제된다.

도 15는 본 개시내용의 실시예에 따른, 식별 테이블을 생성하고, 이용하고, 업데이팅하는 방법(1500)을 예시한다.

S1520에서, 패킷이 수신된다. 예를 들어, 패킷은 그것이 클라이언트 디바이스로 송신되고 있을 때에 가로채어진다.

S1520에서, 패킷은 가로채어지고, DNS 응답, TCP 또는 UDP 페이로드 패킷의 어느 하나로서 식별되거나, 그 어느 것으로도 식별되지 않는다.

패킷이 DNS 응답일 때, 패킷은 그 다음으로 파싱되고, 호스트명 및 하나 이상의 IP 어드레스들은 S1330에서, DNS 응답으로부터 추출된다. 실시예에 따르면, 추출된 데이터는 패킷이 시스템에 의해 유지되는 시간의 양을 제한하고 클라이언트/서버 통신 레이턴시(latency)에 대한 임의의 영향을 제거하기 위하여, 패킷이 배출된 후에 분석하기 위한 독립적인 프로세스를 위하여 인큐잉(enqueue)된다.

패킷이 DNS 응답이 아닐 때, S1520에서, 패킷이 송신 제어 프로토콜(transmission control protocol)(TCP) 또는 사용자 데이터그램 프로토콜(user datagram protocol)(UDP) 패킷과 같은 비-DNS 패킷인지 여부를 결정하기 위하여 패킷이 검사된다.

패킷이 TCP/UDP 패킷일 때, 패킷의 페이로드의 길이는 S1524에서 검사된다. 패킷이 인큐잉되고 배출되어, 페이로드 길이는 패킷이 시스템에 의해 유지되는 시간의 양을 제한하고 클라이언트/서버 통신 레이턴시에 대한 임의의 영향을 제거하기 위하여, 독립적인 프로세스에서 검사된다. 예를 들어, 패킷은 S1330에서 수행된 독립적인 프로세스와 유사하게 인큐잉되고 취급되어, 페이로드 길이는 패킷이 배출된 후에 결정되고 분석된다.

패킷이 DNS 응답 또는 TCP/UDP 패킷의 어느 것도 아닐 경우에, 패킷은 S1522에서 배출된다.

S1532에서는, 식별 테이블에서의 추출된 IP 어드레스의 존재가 결정된다. 예를 들어, 인큐잉된 항목들의 각각은 판독되고, 식별 테이블에서의 복수의 엔트리들과 비교된다.

추출된 IP 어드레스를 포함하는 현존하는 테이블 엔트리가 존재하지 않을 경우에, 식별 테이블은 S1540에서 가득 차거나 그렇지 않은 것으로 결정된다.

식별 테이블이 가득 차지 않을 때, 새로운 테이블 엔트리가 S1540에서 생성된다. 다양한 실시예들에 따르면, 새로운 테이블 엔트리들의 생성은 식별 테이블을, 다양한 호스트명/IP 어드레스 쌍들이 서로에 맵핑되는 DNS 캐시로서 구축한다.

엔트리가 존재할 경우에, 엔트리는 S1534에서, 패킷에 기초하여 업데이팅된다. 테이블 엔트리는 일부 예들에서, 다음의 필드들을 포함한다: IP 어드레스, 도메인 명칭, 최후 활성 시간, 및 누적 바이트들. 엔트리들은 식별 테이블에서 저장된다. 식별 테이블은 예를 들어, IP 어드레스에 의해 인덱싱된 해시 테이블(hash table)이다.

식별 테이블이 가득 찰 때, 식별 테이블에서의 하나 이상의 가장 덜 중요한 엔트리들은 S1544에서 프루닝된다. 즉, 해시 테이블은 구성가능한 최대 길이를 가져서, 식별 테이블은 어떤 크기를 초과하지 않는다. 식별 테이블이 최대 길이를 가질 때, 식별 테이블은 실시예에서, 그 크기의 백분율로 프루닝될 수도 있다. 또 다른 실시예에서, 미리 결정된 수의 엔트리들이 프루닝된다. 엔트리들은 예를 들어, 식별 테이블로부터 삭제됨으로써 프루닝된다.

다양한 실시예들에서, 가장 덜 중요한 엔트리들은 식별 테이블로부터 프루닝된다. 실시예에서, 가장 덜 중요한 엔트리들은 레코딩된 누적 바이트들의 최저 수, 레코딩된 가장 빠른 최후 활성 시간, 또는 그 조합을 포함하는 엔트리들이다. 예를 들어, 누적 바이트들의 최저 수에 대응하는 엔트리들의 백분율이 먼저 제거되고, 동률(tie)의 경우에, 가장 빠른 최후 활성 시간에 대응하는 엔트리들이 제거된다.

S1546에서, 하나 이상의 엔트리들이 제거되는 것으로 결정될 때, 방법(1500)은 S1542로 복귀하여, 새로운 엔트리는 식별 테이블의 최대 크기를 초과하지 않으면서, 패킷에 기초하여 식별 테이블에서 생성된다.

다양한 실시예들에서, 네트워크를 통한 데이터 트래픽은 식별 테이블을 액세스함으로써 관리된다. 식별 테이블은 IP 어드레스에 의해 질의함으로써 액세스되고, 이것은 또 다른 시스템(또는 DNS 스파이 통합을 갖는 시스템)이 상기 IP 어드레스의 도메인 명칭을 획득하는 것을 허용할 것이다. 하나의 버전에서, 이 데이터는 특정 도메인을 갖는 모든 트래픽 상에서의 세밀한 통계의 수집을 활성화하는 통계 수집 시스템에 의해 이용가능하게 된다. 궁극적으로, 이 통계는 특정된 네트워크 상에서의 상부 n 개의 도메인들을 결정하기 위하여 이용될 수 있다.

특정 도메인 상에서 수집될 수 있는 세밀한 통계적 데이터의 일부 예들은: 총 업스트림/다운스트림 바이트들, 레이턴시, 스루풋, 굿풋(Goodput), 라디오 액세스 유형(Radio access type), 혼잡 비율, 특정된 누적 전송된 바이트 임계치를 충족시킨 흐름들(표준 흐름들, 엘리펀트 흐름들 등)에서 전송된 바이트들, 시각 및/또는 위치에 의해 나누어진 통계들, 또는 그 조합을 포함한다(그러나 이것으로 제한되지는 않음).

실시예들은 예를 들어, 트래픽을 병목 네트워크 혼잡의 시간들로부터 과잉 네트워크 용량의 다음의 인접한 순간들로 이동시킴으로써, 시간에 있어서 총합 사용자 트래픽(aggregate user traffic)을 더 균등하게 분배시키는 방식으로 공유된 액세스 네트워크들에 걸쳐 패킷 데이터 컨텐츠를 전달하기 위한 시스템 및 방법을 제공한다. 트래픽의 이 재분배의 순 효과는 (네트워크가 모든 사용자들을 위한 충분한 스루풋 용량(throughput capacity)을 공급할 수 없는) 피크 사용량 및 혼잡의 간격들을 감소시킬 수도 있고, 이것은 사용자들을 위하여, 네트워크 서비스 품질이 열화되기 전의 더 높은 허용된 총합 네트워크 사용으로 귀착될 수 있다.

용어 "과잉 네트워크 용량"("아이들 용량"으로서 또한 알려짐)은 일부 실시예들에서, 네트워크 상에서 데이터의 부분들 또는 전부를 전송하기 위한 발명의 실시예들에 의해 이용될 수도 있지만, 그렇지 않을 경우에는 미이용되는 공유된 네트워크 용량(예컨대, 네트워크 대역폭, 네트워크 자원들)을 의미하는 것으로 이해된다. 다시 말해서, 네트워크 용량이 X이고 현재의 총합 네트워크 트래픽 부하가 Y일 경우에, 이용가능한 과잉 용량은 X-Y이고, 여기서, Y는 X보다 더 클 수 없다. 실시예에서, 과잉 네트워크 용량을 이용하는 목표들 중의 하나는 데이터를 전송하기 위하여 용량 Y의 일부 또는 전부를 이용하기 위한 것이고, 이것은 Y가 제로(zero)일 경우에, 전송이 느려지거나 정지되고, 채널을 네트워크를 공유하는 다른 사용자들의 트래픽에 넘겨준다는 것을 암시한다. 일부 시나리오들에서, 공유된 멀티-사용자 데이터 네트워크들에서의 과잉 네트워크 용량은 순시적(transient)이고, 시시각각 무작위적으로 변동할 수 있다. 또한, 정의된 바와 같은 과잉의 이용은 네트워크 용량의 정당한-몫(fair-share) 또는 유사한 경쟁적인 공유된 이용과는 구분될 수도 있다(예컨대, 총합 트래픽 부하가 네트워크 용량 제한 X를 초과할 때, 네트워크를 공유하는 N 사용자들의 각각은 네트워크 용량의 X/N 몫을 받음).

특정 실시예에서, 시스템은 연관된 클라이언트 IP 어드레스 및 목적지 서버 IP 어드레스에 기초하여 데이터 트래픽 흐름을 고유하게 식별할 수도 있다. 시스템은 그 다음으로, 스루풋(throughput), 전달된 바이트들, 다른 특성들, 또는 그 조합과 같은 파라미터들에 기초하여, 트래픽을 큰 흐름으로서 특성화할 수도 있다. 시스템은 예를 들어, 전송 관리기이다.

시스템은 DNS 스파이에 의해 생성된 식별 테이블에 질의할 수도 있고, 서버 IP 어드레스가 연관되는 호스트명이 알려진 비디오 제공자(예컨대, YOUTUBE)에 속하는 것으로 결정할 수도 있다. 따라서, 데이터 흐름이 그 크기 및 알려진 목적지로 인해 실제로 비디오라는 하나의 결론이 행해질 수 있다.

이 정보는 전송 관리기에 의해 이용가능하게 될 수도 있고, 이것은 특정된 관리 규칙들이 (이 예에서, YOUTUBE와 같은) 특정 도메인에 속할 수도 있거나 속하지 않을 수도 있는 (이 예에서, 비디오와 같은) 트래픽의 특정된 서브세트에 적용되는 것을 가능하게 한다. 규칙들은 관리된 트래픽이 공유된 대역폭을 다른 트래픽에 넘겨주거나(즉, 과잉 네트워크 용량을 이용함), 그렇지 않을 경우에 우선순위화되거나, 또는 임의의 특정 관리를 적용하지 않는 것으로 표기되는 것을 보장하는 정책들을 포함할 수도 있다.

다양한 실시예들에 따르면, DNS 스파이는 1) 트래픽 특성화/관리/통계 프로세스들로부터의 DNS 호스트명/IP 어드레스 분해 프로세스의 분리, 2) 암호화된 트래픽 흐름들에 대한 세밀한 통계 수집을 수행하기 위한 그 능력, 3) 외부 조작을 요구하지 않으면서, 실시간으로 호스트명/IP 맵핑들을 변경하는 것에 적응하는 동적 DNS 캐시의 생성, 및 4) 네트워크 효율들을 개선시키기 위하여 트래픽 관리를 지향하는 호스트명/IP 어드레스 맵핑의 적용과 같은 다수의 특성들로 동작한다.

실시예에 따르면, 시스템은 그 자신의 내부 이용을 위한 가상적 DNS 캐시를 구축하지만, 가상적 DNS 서버로서 작용하지는 않는다. 시스템은 네트워크에 걸쳐 전송된 DNS 응답 패킷들을 가로채고, DNS 응답 패킷들로부터 정보를 추출하고, 추출된 정보에 기초하여 테이블을 구축하지만, 네트워크에 걸쳐 전송된 DNS 응답 패킷들을 수정하거나 조작하지 않는다.

본 개시내용의 실시예들은 특정 호스트명들로의, 그리고 특정 호스트명들로부터의 트래픽을 식별하고 추적하기 위하여 이용될 수 있다. 하나의 버전에서, 수집된 도메인 명칭 정보는 트래픽의 서브세트, 트래픽의 단일 흐름들, 또는 양자에 대한 통계를 수집하는 시스템에 제공될 수 있다. 또 다른 버전에서, 정보는 UE 단말들로의, 그리고 UE 단말들로부터의 컨텐츠 전달을 관리하는 시스템에 제공될 수 있고, 시스템은 도메인 명칭에 기초하여 특정된 관리 정책들을 적용할 것이다.

본 개시내용의 다양한 실시예들을 포함하는 시스템 및 방법들은 다양한 클라이언트 디바이스들과 컨텐츠 서버들 사이의 데이터 트래픽을 분석하고 관리하기 위하여 이용되지만, 컨텐츠를 요청하는 클라이언트 디바이스들 상에서 설치된 사용자 앱, 또는 컨텐츠를 제공하는 컨텐츠 서버에 대한 수정을 요구하지 않고, 이것은 이동 셀룰러 네트워크들과 같은 상업적 네트워크들로의 급속한 전개를 가능하게 한다.

본 개시내용의 다양한 실시예들은 컨텐츠 전달, 무선 네트워크들, 보안성, 및 다른 기술적 분야들과 연관된 다수의 기술적 문제들을 해결한다.

예를 들어, IP 어드레스들을 호스트명들로 맵핑하는 식별 테이블을 생성함으로써, 네트워크 트래픽은 효과적으로 분석될 수 있고, 데이터 흐름들은 고가의 복호화 동작들을 연산적으로 수행하지 않으면서 관리를 위하여 식별될 수 있다.

예를 들어, 데이터 흐름들과 연관된 호스트명들에 기초하여 네트워크를 횡단하는 데이터 흐름들을 선택적으로 관리함으로써, 네트워크 자원들은 효율적으로 보존될 수 있고, 네트워크 혼잡은 효율적으로 방지될 수 있다.

예를 들어, 식별 테이블의 가장 덜 중요한 엔트리들을 선택적으로 프루닝함으로써, 식별 테이블의 크기는 관리불가능하게 되지 않지만, 식별 테이블은 그럼에도 불구하고, 네트워크를 횡단하는 새로운 데이터 흐름들을 관리하기 위하여 관련될 가능성이 있는 IP 어드레스들 및 호스트명들의 레코드들을 유지한다.

본 기술의 양태들은 특정 예들에 대하여 설명되었지만, 본 기술의 실시예들은 이 예들에 의해 제한되지는 않는다. 예를 들어, 본 기술분야에서의 통상의 기술자들은 컨텐츠를 사용자 디바이스들로 사전-전달하는 것이 본 기술의 범위 또는 사상으로부터 이탈하지 않으면서, 다양한 다른 알고리즘들 및 프로세스들에 따라 수행될 수도 있다는 것을 인식할 것이다.

Claims

방법으로서,
도메인 명칭 시스템(domain name system)(DNS) 서버로부터 제1 클라이언트 디바이스로 송신되는 제1 데이터 패킷 - 상기 제1 데이터 패킷은 DNS 응답임 - 을 가로채는 단계;
상기 제1 데이터 패킷으로부터 제1 인터넷 프로토콜(internet protocol)(IP) 어드레스 및 제1 호스트명을 추출하는 단계;
식별 테이블의 제1 엔트리에서 상기 제1 IP 어드레스 및 상기 제1 호스트명을 호스트명/IP 어드레스 쌍으로서 저장하는 단계;
컨텐츠 서버로부터 제2 클라이언트 디바이스로의 데이터 흐름에서 송신되는 제2 데이터 패킷을 가로채는 단계;
상기 제2 데이터 패킷의 헤더에서 제2 IP 어드레스를 식별하는 단계;
상기 제2 IP 어드레스가 상기 제1 엔트리에 있는지 여부를 결정하는 단계; 및
상기 제2 IP 어드레스가 상기 제1 엔트리에 있다는 결정에 응답하여:
상기 제1 엔트리를 사용하여 상기 데이터 흐름과 연관된 제1 특성을 결정하는 단계 - 상기 제1 특성은 상기 호스트명/IP 어드레스 쌍과 연관된 송신된 바이트들의 양을 포함함 -;
상기 제1 특성에 기초하여, 트래픽 관리 정책이 상기 데이터 흐름에 적용되어야 하는지 여부를 결정하는 단계;
상기 트래픽 관리 정책이 적용되어야 한다는 결정에 응답하여, 상기 트래픽 관리 정책을 상기 데이터 흐름에 적용하여 상기 제2 데이터 패킷을 상기 제2 클라이언트 디바이스에 전달하는 단계;
상기 제2 데이터 패킷의 제2 특성을 결정하는 단계; 및
상기 제2 특성으로 상기 식별 테이블의 상기 제1 엔트리를 업데이팅하는 단계
를 포함하는, 방법.
삭제
제1항에 있어서, 상기 제2 특성은 상기 제2 데이터 패킷에서의 바이트(byte)들의 양, 상기 제2 데이터 패킷의 타임스탬프(timestamp), 또는 그 조합인, 방법.
제3항에 있어서,
상기 식별 테이블이 미리 결정된 크기를 초과할 때, 상기 제2 특성에 기초하여 상기 식별 테이블로부터 상기 제1 엔트리를 프루닝(pruning)하는 단계를 더 포함하는, 방법.
삭제
제1항에 있어서, 상기 트래픽 관리 정책을 상기 데이터 흐름에 적용하는 단계는 상기 데이터 흐름이 네트워크의 과잉 네트워크 용량을 넘어서 상기 제2 클라이언트 디바이스로 전송되게 하는 단계, 상기 데이터 흐름을 스로틀링(throttling)하는 단계, 상기 데이터 흐름의 데이터 패킷들을 일시적으로 저장하는 단계, 상기 데이터 흐름을 리라우팅(rerouting)하는 단계 또는 그 조합을 포함하는, 방법.
제1항에 있어서, 상기 제2 데이터의 페이로드는 암호화되고, 그리고
상기 제2 데이터 패킷의 헤더의 IP 어드레스는 복호화를 수행하지 않으면서 식별되는, 방법.
제1항에 있어서, 상기 제1 특성은 상기 제2 IP 어드레스와 연관된 호스트명, 상기 제2 IP 어드레스와 연관된 타임스탬프, 또는 그 조합을 더 포함하는, 방법.
제1항에 있어서, 상기 제1 데이터 패킷으로부터 상기 IP 어드레스 및 상기 호스트명을 추출하는 단계는 상기 DNS 응답에서의 자원 레코드(resource record)(RR)들로부터 상기 IP 어드레스 및 상기 호스트명을 판독하는 단계를 포함하는, 방법.
제8항에 있어서, 상기 DNS 응답에서의 RR들로부터 상기 IP 어드레스 및 상기 호스트명을 판독하는 단계는 상기 DNS 응답의 'RDATA' 필드에서 상기 IP 어드레스를 판독하는 단계, 및 상기 DNS 응답의 'NAME' 필드에서 상기 호스트명을 판독하는 단계를 포함하는, 방법.
제1항에 있어서, 상기 식별 테이블은 해시 테이블(hash table)인, 방법.
시스템으로서,
프로세서; 및
프로그램 커맨드들을 저장하는 메모리
를 포함하고,
상기 프로그램 커맨드들은, 상기 프로세서에 의해 실행될 때, 상기 프로세서로 하여금,
도메인 명칭 시스템(DNS) 서버로부터 제1 클라이언트 디바이스로 송신되는 제1 데이터 패킷 - 상기 제1 데이터 패킷은 DNS 응답임 - 을 가로채게 하고;
상기 제1 데이터 패킷으로부터 제1 인터넷 프로토콜(IP) 어드레스 및 제1 호스트명을 추출하게 하고;
식별 테이블의 제1 엔트리에서 상기 제1 IP 어드레스 및 상기 제1 호스트명을 호스트명/IP 어드레스 쌍으로서 저장하게 하고;
컨텐츠 서버로부터 제2 클라이언트 디바이스로의 데이터 흐름에서 송신되는 제2 데이터 패킷을 가로채게 하고;
상기 제2 데이터 패킷의 헤더에서 제2 IP 어드레스를 식별하게 하고;
상기 제2 IP 어드레스가 상기 제1 엔트리에 있는지 여부를 결정하게 하고; 그리고
상기 제2 IP 어드레스가 상기 제1 엔트리에 있다는 결정에 응답하여:
상기 제1 엔트리를 사용하여, 상기 데이터 흐름과 연관된 제1 특성을 결정하게 하고 - 상기 제1 특성은 상기 호스트명/IP 어드레스 쌍과 연관된 송신된 바이트들의 양을 포함함 -;
상기 제1 특성에 기초하여 트래픽 관리 정책이 상기 데이터 흐름에 적용되어야 하는지 여부를 결정하게 하고;
상기 트래픽 관리 정책이 적용되어야 한다는 결정에 응답하여, 상기 트래픽 관리 정책을 상기 데이터 흐름에 적용하여 상기 제2 데이터 패킷을 상기 제2 클라이언트 디바이스에 전달하게 하고;
상기 제2 데이터 패킷의 제2 특성을 결정하게 하고; 그리고
상기 제2 특성으로 상기 식별 테이블의 상기 제1 엔트리를 업데이팅하게 하는, 시스템.
삭제
삭제
제12항에 있어서, 상기 프로세서는 상기 DNS 응답에서의 자원 레코드(RR)들로부터 상기 제1 IP 어드레스 및 상기 호스트명을 판독함으로써, 상기 제1 데이터 패킷으로부터 상기 제1 IP 어드레스 및 상기 호스트명을 추출하는, 시스템.
제15항에 있어서, 상기 DNS 응답에서의 RR들로부터 상기 제1 IP 어드레스 및 상기 호스트명을 판독하는 것은 상기 DNS 응답의 'RDATA' 필드에서 상기 제1 IP 어드레스를 판독하는 것, 및 상기 DNS 응답의 'NAME' 필드에서 상기 호스트명을 판독하는 것을 포함하는, 시스템.
시스템으로서,
제1 프로세서 및 제1 메모리를 포함하는 도메인 명칭 시스템(DNS) 스파이(spy) - 상기 제1 메모리는 프로그램 커맨드들을 저장하고, 상기 프로그램 커맨드들은, 상기 제1 프로세서에 의해 실행될 때, 상기 제1 프로세서로 하여금,
복수의 제1 데이터 패킷들로부터 복수의 맵핑들을 추출하게 하고 - 상기 제1 데이터 패킷들의 각각은 DNS 응답이고, 각각의 맵핑은 각각의 인터넷 프로토콜(IP) 어드레스 및 각각의 호스트명을 포함함 -; 그리고
식별 테이블 - 상기 식별 테이블은 상기 맵핑들의 상기 각각의 IP 어드레스들에 의해 인덱싱됨 - 의 복수의 엔트리들에서 상기 복수의 맵핑들을 각각의 호스트명/IP 어드레스 쌍들로서 저장하게 함 -; 및
제2 프로세서 및 제2 메모리를 포함하는 전송 관리기
를 포함하고,
상기 제2 메모리는 프로그램 커맨드들을 저장하고, 상기 프로그램 커맨드들은, 상기 제2 프로세서에 의해 실행될 때, 상기 제2 프로세서로 하여금,
데이터 흐름의 비-DNS 패킷의 헤더로부터 제2 IP 어드레스를 추출하게 하고;
상기 식별 테이블의 상기 복수의 엔트리들 중의 엔트리를 사용하여 상기 제2 IP 어드레스를 포함하는 제2 호스트명/IP 어드레스 쌍에 대응하는 송신된 바이트들의 양을 결정하게 하고 - 상기 엔트리는 상기 제2 호스트명/IP 어드레스 쌍을 포함함 -;
상기 송신된 바이트들의 양에 기초하여 트래픽 관리 정책을 상기 데이터 흐름에 적용할지 여부를 결정하게 하고;
상기 트래픽 관리 정책이 적용되어야 한다는 결정에 응답하여, 상기 트래픽 관리 정책을 상기 데이터 흐름에 적용하여 제2 데이터 패킷을 제2 클라이언트 디바이스에 전달하게 하고;
상기 비-DNS 패킷의 특성을 결정하게 하고; 그리고
상기 특성으로 상기 식별 테이블의 상기 엔트리를 업데이팅하게 하는, 시스템.
제12항에 있어서, 상기 데이터 흐름과 연관된 상기 제1 특성에 기초하여, 상기 트래픽 관리 정책이 상기 데이터 흐름에 적용되어야 하는지 여부를 결정하는 것은 상기 데이터 흐름이 엘리펀트 흐름(elephant flow)이라고 결정함으로써, 상기 데이터 흐름을 전송하는 네트워크가 혼잡한 것으로 결정함으로써, 상기 데이터 흐름이 상기 데이터 흐름을 전송하는 상기 네트워크에 부담이 될 것으로 결정함으로써, 상기 데이터 흐름이 상기 데이터 흐름을 전송하는 상기 네트워크에 의해 전송되는 다른 데이터보다 덜 중요하다고 결정함으로써, 또는 그 조합에 의해 상기 트래픽 관리 정책이 적용되어야 한다고 결정하는 것을 포함하는, 시스템.
제12항에 있어서, 상기 트래픽 관리 정책을 상기 데이터 흐름에 적용하는 것은 상기 데이터 흐름이 네트워크의 과잉 네트워크 용량을 넘어서 상기 제2 클라이언트 디바이스로 전송되게 하는 것, 상기 데이터 흐름을 스로틀링(throttling)하는 것, 상기 데이터 흐름의 데이터 패킷들을 일시적으로 저장하는 것, 상기 데이터 흐름을 리라우팅(rerouting)하는 것 또는 그 조합을 포함하는, 시스템.
제1항에 있어서, 상기 데이터 흐름과 연관된 상기 제1 특성에 기초하여, 상기 트래픽 관리 정책이 상기 데이터 흐름에 적용되어야 하는지 여부를 결정하는 단계는 상기 데이터 흐름이 엘리펀트 흐름(elephant flow)이라고 결정함으로써, 상기 데이터 흐름을 전송하는 네트워크가 혼잡한 것으로 결정함으로써, 상기 데이터 흐름이 상기 데이터 흐름을 전송하는 상기 네트워크에 부담이 될 것으로 결정함으로써, 상기 데이터 흐름이 상기 데이터 흐름을 전송하는 상기 네트워크에 의해 전송되는 다른 데이터보다 덜 중요하다고 결정함으로써, 또는 그 조합에 의해 상기 트래픽 관리 정책이 적용되어야 한다고 결정하는 단계를 포함하는, 방법.