KR102154788B1 - 무선 통신 시스템의 단말에서 DNS(Domain Name Service) 레졸루션 방법 및 장치 - Google Patents

무선 통신 시스템의 단말에서 DNS(Domain Name Service) 레졸루션 방법 및 장치 Download PDF

Info

Publication number
KR102154788B1
KR102154788B1 KR1020140133161A KR20140133161A KR102154788B1 KR 102154788 B1 KR102154788 B1 KR 102154788B1 KR 1020140133161 A KR1020140133161 A KR 1020140133161A KR 20140133161 A KR20140133161 A KR 20140133161A KR 102154788 B1 KR102154788 B1 KR 102154788B1
Authority
KR
South Korea
Prior art keywords
dns
information
communication interface
host name
inquiry
Prior art date
Application number
KR1020140133161A
Other languages
English (en)
Other versions
KR20160039882A (ko
Inventor
지앙웨이 쉬
이경훈
김진형
이진호
크리쉬나 마노하르 싱흐
Original Assignee
삼성전자주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 삼성전자주식회사 filed Critical 삼성전자주식회사
Priority to KR1020140133161A priority Critical patent/KR102154788B1/ko
Priority to EP15846781.1A priority patent/EP3203706B1/en
Priority to PCT/KR2015/010423 priority patent/WO2016053045A1/ko
Priority to US15/512,389 priority patent/US10448325B2/en
Publication of KR20160039882A publication Critical patent/KR20160039882A/ko
Application granted granted Critical
Publication of KR102154788B1 publication Critical patent/KR102154788B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W52/00—Power management, e.g. TPC [Transmission Power Control], power saving or power classes
    • H04W52/02—Power saving arrangements
    • H04W52/0209—Power saving arrangements in terminal devices
    • H04W52/0212—Power saving arrangements in terminal devices managed by the network, e.g. network or access point is master and terminal is slave
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5007—Internet protocol [IP] addresses
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/58—Caching of addresses or names
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

본 발명의 실시예들은 무선 통신 시스템의 단말에서 DNS(Domain Name Service) 레졸루션 방법 및 장치를 제공한다. 본 발명의 일 실시예에 따르면, 본 발명의 실시예에 따르면, 무선 통신 시스템의 단말에서 DNS 레졸루션 방법에 있어서, URL 프로토콜 핸들러로부터 호스트에 대한 DNS(Domain Name Service) 문의신호를 수신하면, 메모리에 저장된 DNS 캐쉬정보와 상기 DNS 문의신호에 포함된 DNS 문의정보를 비교하는 과정; 및 상기 DNS 캐쉬정보와 상기 DNS 문의정보의 비교 결과에 따라, 상기 호스트에 대응하는 IP 주소정보를 상기 URL 프로토콜 핸들러로 전송하는 과정을 포함한다.

Description

무선 통신 시스템의 단말에서 DNS(Domain Name Service) 레졸루션 방법 및 장치{A DNS resolution method in a terminal of a wireless communication system, and an apparatus therefor}
본 발명은 휴대용 단말기에서 다중 무선 접속(Multi-RAT(Radio Access Technology))에 관한 것으로, 적응적인 DNS 레졸루션을 이루기 위한 기술이다.
다운로드 부스터(download Booster)와 같은 다중 무선 접속기술은 와이파이(WiFi) 및 LTE에 따른 다운로드를 수행하기 위해 멀티 네트워크 인터페이스를 통해 HTTP 세션을 분배한다.
이때, HTTP 문의를 전송하기 전에, 휴대용 단말기는 우선적으로 호스트 네임으로부터 호스트 IP 주소를 얻을 필요가 있다. 이를 DNS(Domain Name Service) 레졸루션(resolution)이라 한다. 이에 따라, DNS 문의는 디폴트된 모바일 인터페이스를 통해 전송된다. 이것은 몇가지 이슈를 야기할 것이다. 즉, 서로 다른 네트워크 인터페이스들은 서로 다른 IP버전을 사용하는 경우가 있으며, 디폴트된 인터페이스 속도가 다른 인터페이스 속도보다 느린 경우가 발생할 수 있다. 즉, 2 종류 이상의 통신 인터페이스들을 사용하는 경우에, 각 통신 인터페이스들의 IP버전이 다른 경우에, DNS 레졸루션에 대한 두번째 문의에 대해 잘못된 결과를 초래할 수 있다.
또한, 디폴트로 설정된 인터페이스가 다른 인터페이스보다 상대적으로 느린 속도를 갖는 경우에, DNS 레졸루션을 위한 시간이 길어지는 문제점이 있다.
또한, 2 종류 이상의 통신 인터페이스들을 갖는 휴대용 단말기에서 DNS 쿼리가 2 종류 이상의 통신 인터페이스들로 모두 전송되는 경우에, 어느 하나의 인터페이스를 통해 DNS 레졸루션을 얻을 수는 있지만, 다른 통신 인터페이스의 경우에도 계속 활성화되어 있어서 전력 낭비를 초래한다. 또한, 보다 빠른 전송 속도를 갖는 통신 인터페이스를 통해, DNS 문의에 대한 DNS 레졸루션을 획득하였다고 하더라도, 느린 전송속도를 갖는 또 다른 인터페이스를 통해 HTTP 요청이 이루어지는 경우에는, HTTP 요청에 대해 빠른 응답을 받을 수 없다.
본 발명이 해결하고자 하는 과제는 다중 무선 접속(Multi-RAT) 시스템에서 전력 소모를 최소화하면서 효율적으로 DNS 레졸루션을 구현할 수 있도록 하는 무선 통신 시스템의 단말에서 DNS 레졸루션 방법 및 장치에 관한 것이다.
본 발명의 실시예에 따르면, 무선 통신 시스템의 단말에서 DNS 레졸루션 방법에 있어서, URL 프로토콜 핸들러로부터 호스트에 대한 DNS(Domain Name Service) 문의신호를 수신하면, 메모리에 저장된 DNS 캐쉬정보와 상기 DNS 문의신호에 포함된 DNS 문의정보를 비교하는 과정; 및 상기 DNS 캐쉬정보와 상기 DNS 문의정보의 비교 결과에 따라, 상기 호스트에 대응하는 IP 주소정보를 상기 URL 프로토콜 핸들러로 전송하는 과정을 포함한다.
본 발명의 다른 실시예에 따르면, 무선 통신 시스템의 단말에서 DNS 레졸루션 장치에 있어서, DNS 캐쉬정보를 저장하는 메모리; 및 URL 프로토콜 핸들러로부터 호스트에 대한 DNS 문의신호를 수신하면, 상기 메모리에 저장된 상기 DNS 캐쉬정보와 상기 DNS 문의신호에 포함된 DNS 문의정보를 비교하고, 상기 DNS 캐쉬정보와 상기 DNS 문의정보의 비교 결과에 따라, 상기 호스트에 대응하는 IP 주소정보를 상기 URL 프로토콜 핸들러로 전송하는 컨트롤러를 포함한다.
본 발명에 따르면, 이전의 DNS 레졸루션에 따라 캐쉬(저장)된 정보를 재사용할 수 있도록 함으로써, 현재의 DNS 레졸루션을 위한 시간을 최소화할 수 있다.
또한, 2 이상의 통신 인터페이스들 중에서 전송 속도가 보다 빠른 통신 인터페이스를 통해서 DNS 레졸루션을 수행할 수 있도록 함으로써, 고속의 HTTP 액세스를 구현할 수 있다.
또한, 2 이상의 통신 인터페이스들 중에서 사용되지 않는 통신 인터페이스에 대해서는 비활성화 상태를 유지하도록 함으로써, 전력 소모를 최소화할 수 있다.
본 발명 및 그의 효과에 대한 보다 완벽한 이해를 위해, 첨부되는 도면들을 참조하여 하기의 설명들이 이루어질 것이고, 여기서 동일한 참조 부호들은 동일한 부분들을 나타낸다.
도 1은 WiFi 및 3G/LTE를 각각 사용하는 통신 인터페이스들을 갖는 휴대용 단말기에서의 DNS 레졸루션 동작에 관한 일 실시예의 도면이다.
도 2는 WiFi 및 3G/LTE를 각각 사용하는 통신 인터페이스들을 갖는 휴대용 단말기에서의 DNS 레졸루션 동작에 관한 다른 실시예의 도면이다.
도 3은 WiFi 및 3G/LTE를 각각 사용하는 통신 인터페이스들을 갖는 휴대용 단말기에서의 DNS 레졸루션 동작에 관한 또 다른 실시예의 도면이다.
도 4는 WiFi 및 3G/LTE를 각각 사용하는 통신 인터페이스들을 갖는 휴대용 단말기에서의 DNS 레졸루션 동작에 관한 또 다른 실시예의 도면이다.
도 5는 WiFi 및 3G/LTE를 각각 사용하는 통신 인터페이스들을 갖는 휴대용 단말기에서의 DNS 레졸루션 동작에 관한 또 다른 실시예의 도면이다.
도 6은 WiFi 및 3G/LTE를 각각 사용하는 통신 인터페이스들을 갖는 휴대용 단말기에서의 DNS 레졸루션 동작에 관한 또 다른 실시예의 도면이다.
도 7은 본 발명에 따른 다중 무선 접속(Multi-RAT) 시스템을 위한 DNS 핸들러의 구조를 설명하기 위한 블록도이다.
도 8은 다중 무선 접속(Multi-RAT)을 위한 DNS 핸들링 절차의 예시적인 도면이다.
도 9는 DNS 캐쉬에 저장된 정보의 일 예를 나타내는 도면이다.
도 10은 복수개의 유효 인터페이스들로 DNS 문의이 전송되는 것을 설명하기 위한 도면이다.
도 11은 다중 무선 접속(Multi-RAT)을 위한 DNS 핸들링 절차의 또 다른 예의 도면이다.
도 12 a 및 도 12 b는 각각 DNS 캐쉬 매핑 절차를 예시한 도면이다.
도 13은 적어도 하나 이상의 통신 인터페이스들로 DNS 문의를 전송할 것인지를 결정하기 위한 알고리즘을 설명하기 위한 도면이다.
도 14는 DNS 문의를 DNS 서버로 전송하기 위한 예시적인 상태를 도시한 도면이다.
도 15는 도 14의 DNS 문의에 따른 DNS 응답을 예시한 도면이다.
도 16은 DNS 응답에 따라 URL 문의를 전송하기 위한 과정을 예시한 도면이다.
도 17은 본 발명의 일 실시예에 따른 무선 통신 시스템의 단말에서 DNS 레졸루션방법을 설명하기 위한 플로차트이다.
도 18은 DNS 문의신호를 적어도 하나 이상의 통신 인터페이스를 통해 DNS 서버로 전송하는 과정을 설명하기 위한 일 실시예의 플로차트이다.
도 19는 본 발명의 일 실시예에 따른 무선 통신 시스템의 단말에서 DNS 레졸루션 장치를 설명하기 위한 블록도이다.
도 20은 2 이상의 통신 인터페이스가 서로 다른 IP 버전을 갖는 경우를 예시한 것이다.
도 21은 2 이상의 통신 인터페이스가 서로 동일한 IP 버전을 갖는 경우를 예시한 것이다.
도 22는 DNS 캐쉬에 저장된 정보를 이용하여 DNS 레졸루션을 수행하는 경우를 예시한 것이다.
도 23은 2 이상의 통신 인터페이스가 서로 다른 전송 속도를 갖는 경우를 예시한 것이다.
도 24는 2 이상의 통신 인터페이스를 통해 수신된 DNS 응답 정보가 DNS 캐쉬에 저장된 상태에서 DNS 레졸루션을 수행하는 경우를 예시한 것이다.
도 25는 2 이상의 통신 인터페이스를 통해 DNS 응답신호를 수신한 URL 프로토콜 핸들러의 동작을 예시한 것이다.
도 26은 2 이상의 통신 인터페이스가 서로 다른 전송 속도를 갖는 경우에 DNS 핸들러의 동작을 예시한 것이다.
본 특허 명세서에서 본 발명의 원리들을 설명하기 위해 사용되는 도 1 내지 도 26은 단지 예시를 위한 것인 바, 발명의 범위를 제한하는 어떠한 것으로도 해석되서는 아니된다. 당해 분야에서 통상의 지식을 가진 자는 본 발명의 원리들이 적절하게 배치된 임의의 무선 통신시스템에서도 구현될 수 있음을 이해할 것이다.
도 1은 WiFi 및 3G/LTE를 각각 사용하는 통신 인터페이스들을 갖는 휴대용 단말기에서의 DNS(Domain Name Service) 레졸루션 동작에 관한 일 실시예의 도면이다.
도 1에 따르면, 어플리케이션 모듈에서 URL(Uniform Resource Locator) 프로토콜 핸들러로 접속을 위한 호스트를 요청하면(1), 웹 서버로부터 기 설정된 WiFi 인터페이스를 통해 IPv4에 대응하는 DNS 레졸루션을 수행하게 된다(2, 3, 4). 그 후, 3G/LTE 인터페이스가 활성화되어 있는 상태에서도, 두번째의 HTTP 요청에 따라, WiFi 인터페이스를 통해 IPv4에 대응하는 DNS 레졸루션을 수행하게 된다(5, 6). 그 후, HTTP 요청이 IPv6 로컬 IP 주소로부터 IPv4 웹서버로 전송되도록 시도됨으로 인해, 이러한 요청이 실패로 돌아가게 된다.
도 2는 WiFi 및 3G/LTE를 각각 사용하는 통신 인터페이스들을 갖는 휴대용 단말기에서의 DNS 레졸루션 동작에 관한 다른 실시예의 도면이다. 여기서, WiFi 인터페이스는 약한 신호를 갖으며, 3G/LTE는 강한 신호를 갖는 것으로 가정한다.
도 2에 따르면, 어플리케이션 모듈에서 URL 프로토콜 핸들러로 접속을 위한 호스트를 요청하면(1), DNS 서버로부터 기 설정된 WiFi 인터페이스를 통해 HTTP 요청을 위한 IPv4에 대응하는 DNS 레졸루션을 얻게 된다(2, 3, 4). 그 후, 3G/LTE 인터페이스가 활성화되어 있는 상태에서도, 두번째의 HTTP 요청에 따라, WiFi 인터페이스를 통해 IPv4에 대응하는 DNS 레졸루션을 얻게 된다(5, 6). 6번째 단계에서, 비록 3G/LTE 인터페이스가 고속의 전송 속도(예를 들어, 0.5[sec])를 갖음에도 불구하고, 두번째의 HTTP 요청에 따른 DNS 레졸루션은 약한 신호를 갖는 WiFi 인터페이스를 통해 수신됨으로 인해 오랜 시간(예를 들어, 10[sec])이 소요된다.
도 3은 WiFi 및 3G/LTE를 각각 사용하는 통신 인터페이스들을 갖는 휴대용 단말기에서의 DNS 레졸루션 동작에 관한 또 다른 실시예의 도면이다. 도 3에 따르면, DNS 문의는 활성화되어 있는 WiFi 인터페이스 및 3G/LTE 인터페이스로 모두 전송된다. 이에 따르면, 보다 빠른 전송 속도를 갖는 WiFi 인터페이스를 통해, DNS 레졸루션을 얻을 수는 있다. 그러나, 3G/LTE 인터페이스는 계속 활성화되어 있어서 전력 낭비를 초래한다.
도 4는 WiFi 및 3G/LTE를 각각 사용하는 통신 인터페이스들을 갖는 휴대용 단말기에서의 DNS 레졸루션 동작에 관한 또 다른 실시예의 도면이다. 도 4에 따르면, DNS 문의은 WiFi 인터페이스 및 3G/LTE 인터페이스 중 하나의 인터페이스로만 전송된다. 도 4 (a)에 도시된 바와 같이, "A.COM"에 대한 DNS 문의(Query)가 WiFi 인터페이스를 통해, DNS 서버로 전송되는 동안, 3G/LTE 인터페이스는 비활성화 상태로 존재한다. 그 후, 도 4 (b) 또는 도 4(c)에 도시된 바와 같이, 또 다른 "A.COM"의 DNS 문의가 활성화된 3G/LTE 인터페이스를 통해 DNS 서버로 전송되면, 항상 3G/LTE 인터페이스를 통해 DNS 레졸루션을 수행하게 된다. 그러나, 이전에 이미 WiFi 인터페이스를 통해 DNS 레졸루션을 수행했다는 점에서, 3G/LTE 인터페이스의 불필요한 동작에 따른 전력 소모를 초래한다. 또한, 3G/LTE 인터페이스를 통해 DNS 결과를 수신한다는 점에서, DNS 레졸루션을 위한 시간이 지연된다.
도 5는 WiFi 및 3G/LTE를 각각 사용하는 통신 인터페이스들을 갖는 휴대용 단말기에서의 DNS 레졸루션 동작에 관한 또 다른 실시예의 도면이다. 도 5에 따르면, 보다 빠른 전송 속도를 갖는 3G/LTE 인터페이스를 통해, DNS 문의에 대한 DNS 레졸루션을 획득하였다고 하더라도, 느린 전송속도를 갖는 WiFi 인터페이스를 통해 HTTP 요청이 이루어지는 경우에는, URL 프로토콜 핸들러가 HTTP 요청에 대해 빠른 응답을 받을 수 없다.
도 6은 WiFi 및 3G/LTE를 각각 사용하는 통신 인터페이스들을 갖는 휴대용 단말기에서의 DNS 레졸루션 동작에 관한 또 다른 실시예의 도면이다. 도 6에 따르면, 일반적으로 다중 무선 접속(Multi-RAT(Radio Access Technology))은 2번째 이후의 DNS 레졸루션에 대해서 다중 무선 접속 동작을 수행한다. 따라서, 처음에 요구되는 DNS 레졸루션에 대해서는 기 설정된 인터페이스(예를 들어, 느린 전송속도를 갖는 WiFi 인터페이스)를 통해서만 DNS 레졸루션을 수행하게 된다.
도 7은 본 발명에 따른 다중 무선 접속(Multi-RAT) 시스템을 위한 DNS 핸들러의 구조를 설명하기 위한 블록도이다. 도 7에 따르면, 스마트폰 단말기 내에 어플리케이션 모듈(100), URL 프로토콜 핸들러(110), DNS 핸들러(120), WiFi 통신 인터페이스(130) 및 3G/LTE 통신 인터페이스(140)를 포함한다. 특히, DNS 핸들러(120)는 컨트롤러(121), 네트워크 상태 메니져(122), 서브 핸들러 1(123), 서브 핸들러 2(125) 및 DNS 캐쉬(Cache:124)를 포함한다.
네트워크 상태 메니져(122)는 WiFi 통신 인터페이스(130) 및 3G/LTE 통신 인터페이스(140)의 연결 상태를 검출하고, 각 통신 인터페이스의 DNS 레졸루션 타임에 대한 히스토리 정보를 저장하고 있다.
DNS 캐쉬(124)는 호스트 IP와 함께 각 통신 인터페이스의 IP 버전 및 통신 인터페이스 ID를 매칭하여 저장하고 있다. 멀티플 IP 주소가 DNS 캐쉬(124)의 호스트 IP 및 이에 매칭되는 통신 인터페이스의 IP 버전과 일치한다면, DNS 캐쉬(124)는 호스트 IP 및 이에 매칭되는 통신 인터페이스에 대한 정보를 제공한다.
컨트롤러(121)는 URL 프로토콜 핸들러(110)로부터 DNS 문의(Query)을 수신하고, DNS 문의에 따른 DNS 응답신호에 대응하는 호스트 IP주소를 URL 프로토콜 핸들러(110)로 전송한다. 컨트롤러(121)는 DNS 캐쉬(124)와 네트워크 상태 메니져(122)를 체크하고, DNS 문의에 대한 수행 동작을 결정한다. 만일 DNS 캐쉬(124)에 DNS 문의에 따른 호스트 IP 및 IP 버전과 동일한 정보가 검색된다면, 컨트롤러(121)는 DNS 캐쉬(124)에 저장된 IP 주소를 URL 프로토콜 핸들러(110)로 전송한다.
DNS 문의에 따른 호스트 IP 및 IP 버전과 동일한 정보가 DNS 캐쉬(124)에 검색되지 않으면, 컨트롤러(121)는 기 설정된 조건에 따라 DNS 문의를 복수의 통신인터페이스들로 동시에 전송하거나, 상대적으로 빠른 통신 인터페이스로 전송한다.
서브 핸들러 1(123)는 WiFi 통신 인터페이스(130)와 각각 연결되어 있으며, 서브 핸들러 2(125)는 3G/LTE 통신 인터페이스(140)와 연결되어 있다. 다중 무선 접속(Multi-RAT)을 위해 복수개의 서브 핸들러들이 구비되어 있다.
WiFi 통신 인터페이스(130)는 WiFi DNS 서버(150)와 무선으로 연결되어 있으며, 3G/LTE 통신 인터페이스(140)는 3G/LTE DNS 서버(160)와 무선으로 연결되어 있다.
도 8은 다중 무선 접속(Multi-RAT)을 위한 DNS 핸들링 절차를 도시한 예시적인 도면이다.
도 8의 S200 및 S202 단계에서, 새로운 HTTP 요청이 있으면, DNS 문의가 DNS 핸들러로 전송된다. 도 8의 S204 및 S206 단계에서, DNS 핸들러가 DNS 캐쉬의 IP버전 및 호스트 네임을 체크하고, 채크한 결과에 따라 캐쉬된 IP 주소정보를 URL 프로토콜 핸들러로 제공한다.
도 9는 DNS 캐쉬에 저장된 정보의 일 예를 나타내는 도면이다. 만일, DNS 캐쉬에 저장된 정보가 DNS 문의에 대응하는 IP 버전 및 호스트 네임과 매치된다면, IP 버전 및 호스트 네임에 대응하는 IP 주소 정보를 URL 프로토콜 핸들러로 제공한다. 한편, DNS 캐쉬에 저장된 정보가 DNS 문의에 대응하는 호스트 네임과 매치되지만, DNS 문의에 대응하는 IP 버전과는 매치되지 않는다면, 그것은 캐쉬 미스에 해당하는 것으로 판단한다.
만일, DNS 캐쉬에 저장된 2개 이상의 정보가 DNS 문의에 대응하는 IP 버전 및 호스트 네임과 매치되고, 서로 다른 통신 인터페이스들을 갖는다면, 기 설정된 통신 인터페이스를 통한 IP 주소 정보를 URL 프로토콜 핸들러로 제공한다. 또한, DNS 캐쉬에 저장된 2개 이상의 정보가 DNS 문의에 대응하는 IP 버전 및 호스트 네임과 매치되고, 2개 이상 중 어느 하나의 IP 주소 정보가 존재하지 않는다면, 존재하는 IP 주소 정보를 URL 프로토콜 핸들러로 제공한다.
도 8의 S208 단계에서, 만일 캐쉬 미스에 해당한다면, 타겟 인터페이스와 동일한 IP버전을 갖는 모든 유효 인터페이스를 획득한다. 여기서, 유효 인터페이스는 유효 IP 주소와 연결된 인터페이스를 의미한다.
도 8의 S210 단계에서, 유효 인터페이스가 몇개인가를 확인한다. 도 8의 S212 단계에서, 유효 인터페이스가 1개에 해당한다면, DNS 문의을 유효 인터페이스에 대응하는 DNS 서브 핸들러로 전송한다.
도 8의 S214 단계에서, 유효 인터페이스가 복수개에 해당한다면, DNS 문의를 복수개의 유효 인터페이스들에 대응하는 복수개의 DNS 서브 핸들러들로 전송한다.
도 10은 복수개의 유효 인터페이스들로 DNS 문의가 전송되는 것을 설명하기 위한 도면이다. 도 10 (a)는 DNS 문의가 복수개의 유효 인터페이스들로 동시에 전송되는 것을 예시한 것이고, 도 10 (b)는 DNS 문의가 서로 시간을 달리하여 복수개의 유효 인터페이스들로 전송되는 것을 예시한 것이다. DNS 문의가 우선적으로 전송되는 인터페이스는 DNS 레졸루션 타임, 낮은 전력 소모 등을 고려하여 설정된다.
도 8의 S216 단계에서, 유효한 인터페이스가 없다면, 유효한 인터페이스가 존재하지 않는다는 정보를 URL 프로토콜 핸들러로 전송한다.
도 8의 S218 및 S220 단계에서, DNS 문의를 수신한 DNS 서브 핸들러들은 DNS 패킷을 생성하고, 생성된 DNS 패킷을 DNS 서브 핸들러들에 대응하는 인터페이스들로 각각 전송한다. 그 후, DNS 서브 핸들러들에 대응하는 인터페이스들로부터 DNS 패킷에 대응하는 DNS 응답을 수신한다.
도 8의 S222 단계에서, 수신된 DNS 응답을 DNS 캐쉬에 저장한다. 또한, 도 8의 S224 단계에서, 우선적으로 수신된 DNS 응답에 대응하는 IP 주소를 URL 프로토콜 핸들러로 전송한다.
도 11은 다중 무선 접속(Multi-RAT)을 위한 DNS 핸들링 절차의 또 다른 예의 도면이다.
도 11의 S300 및 S302 단계에서, 새로운 HTTP 요청이 있으면, URL 프로토콜 핸들러는 DNS 문의를 DNS 핸들러로 전송한다. S304 단계에서, DNS 핸들러는 DNS 캐쉬의 IP버전 및 호스트 네임을 체크한다. S306 단계에서, 채크한 결과에 따라, DNS 핸들러는 캐쉬된 IP 주소정보를 URL 프로토콜 핸들러로 전송한다. S308 단계에서, 만일 캐쉬 미스에 해당한다면, 모든 유효 인터페이스를 통해 DNS 서버로 DNS 문의를 전송한다. S310 단계에서, DNS 서버로부터 DNS 문의에 대응하는 DNS 응답을 수신하고, 수신된 DNS 응답을 DNS 캐쉬에 저장한다. S312 단계에서, 우선적으로 수신된 DNS 응답에 대응하는 IP 주소를 URL 프로토콜 핸들러로 전송한다.
도 12 a 및 도 12 b는 각각 DNS 캐쉬 매핑 절차를 예시한 도면이다.
도 12 a는 결정된 통신 인터페이스에 따른 DNS 캐쉬 매핑 절차를 예시한 것이다. 도 12a에 따르면, S400 단계에서, URL 프로토콜 핸들러는 결정된 통신 인터페이스에 따른 URL 문의신호를 DNS 핸들러로 전송한다. 이때, URL 프로토콜 핸들러는 통신인터페이스의 식별정보(예를 들어, InfX) 및 호스트 네임(예를 들어, Host X)이 포함된 DNS 매핑 요청신호를 URL 문의신호와 함께 DNS 핸들러로 전송한다. S402 단계에서, DNS 핸들러의 콘트롤러는 통신인터페이스의 식별정보(예를 들어, InfX)로부터 통신 인터페이스의 IP 버전(예를 들어, IPvX)을 획득한 후에, 호스트 네임(예를 들어, Host X) 및 IP 버전(예를 들어, IPvX)의 키값과 매핑되는 IP 주소정보를 DNS 캐쉬에게 요청한다. S404 단계에서, DNS 캐쉬는 호스트 네임(예를 들어, Host X) 및 IP 버전(예를 들어, IPvX)의 키값에 매핑되는 IP 주소정보를 검색한다. S406 단계에서, 매핑되는 IP 주소정보의 개수가 몇개 존재하는가를 판단한다. S408 단계에서, 매핑되는 IP 주소정보가 존재하지 않는다면, DNS 캐쉬 오류(Miss)라고 결정한다. S410 단계에서, 매핑되는 IP 주소정보가 단지 하나 존재한다면, 매핑된 IP 주소정보를 URL 프로토콜 핸들러로 전송한다. S412 단계에서, 매핑된 IP 주소정보가 2 이상 존재한다면, 매핑된 IP 주소정보들 중에서 통신인터페이스의 식별정보(예를 들어, InfX)와 일치하는 IP 주소정보가 존재하는가를 판단한다. S414 단계에서, 매핑된 IP 주소정보들 중에서 통신인터페이스의 식별정보(예를 들어, InfX)와 일치하는 것이 존재한다면, 통신인터페이스의 식별정보(예를 들어, InfX)와 일치하는 IP 주소정보를 URL 프로토콜 핸들러로 전송한다. S416 단계에서, 매핑된 IP 주소정보들 중에서 통신인터페이스의 식별정보(예를 들어, InfX)와 일치하는 것이 존재하지 않는다면, 매핑된 2이상의 IP 주소정보들 중에서 통신 우선순위가 높은 IP 주소정보를 URL 프로토콜 핸들러로 전송한다. 여기서, 통신 우선순위는 전력 소비 정도 또는 전송 속도 등을 고려하여 미리 설정되어 있으며, 예를 들어, Wi-Fi 통신 인터페이스가 1 순위로 설정되고, LTE 통신 인터페이스가 2순위로 설정될 수 있다.
도 12 b는 결정되지 않은 통신 인터페이스에 따른 DNS 캐쉬 매핑 절차를 예시한 것이다. 도 12b에 따르면, S420 단계에서, URL 프로토콜 핸들러는 결정되지 않은 통신 인터페이스에 따른 URL 문의신호를 DNS 핸들러로 전송한다. 따라서, URL 프로토콜 핸들러는 단지 호스트 네임(예를 들어, Host X)이 포함된 DNS 매핑 요청신호를 URL 문의신호와 함께 DNS 핸들러로 전송한다. S422 단계에서, DNS 핸들러의 콘트롤러는 호스트 네임(예를 들어, Host X)의 키값과 매핑되는 IP 주소정보를 DNS 캐쉬에게 요청한다. DNS 캐쉬는 호스트 네임(예를 들어, Host X)의 키값에 매핑되는 IP 주소정보를 검색한다. S424 단계에서, 매핑되는 IP 주소정보의 개수가 몇 개 존재하는가를 판단한다. S426 단계에서, 매핑되는 IP 주소정보가 존재하지 않는다면, DNS 캐쉬 오류(Miss)라고 결정한다. S428 단계에서, 매핑되는 IP 주소정보가 단지 하나 존재한다면, 매핑된 IP 주소정보를 URL 프로토콜 핸들러로 전송한다. S430 단계에서, 매핑된 IP 주소정보가 2 이상 존재한다면, 매핑된 2이상의 IP 주소정보들 중에서 통신 우선순위가 높은 IP 주소정보를 URL 프로토콜 핸들러로 전송한다.
도 13은 적어도 하나 이상의 통신 인터페이스들로 DNS 문의를 전송할 것인지를 결정하기 위한 알고리즘을 설명하기 위한 도면이다.
통신 인터페이스 Inf 1이 전력 절감을 위해 기 설정된 통신 인터페이스에 해당한다고 가정한다. 통신 인터페이스 Inf 1의 이전 DNS 레졸루션 타임(Inf 1 Time)이 제1 임계값(예를 들어, DNS 레졸루션을 위한 최소 시간 값)보다 작거나(S500), 통신 인터페이스 Inf 1의 이전 DNS 레졸루션 타임(Inf 1 Time)이 통신 인터페이스 Inf 2의 이전 DNS 레졸루션 타임(Inf 2 Time)의 제2 임계시간 범위 내에 해당하는 경우에(S502), DNS 문의는 단지 하나의 통신 인터페이스 Inf 1를 통해 DNS 서버로 전송된다(S504). 그러나, 통신 인터페이스 Inf 1의 이전 DNS 레졸루션 타임(Inf 1 Time)이 제2 임계시간 범위 내에 해당하지 않는 경우에, DNS 문의는 복수의 통신 인터페이스들을 통해 각각의 DNS 서버로 전송된다(S506).
DNS 문의가 하나의 통신 인터페이스 Inf 1를 통해 DNS 서버로 전송된 후에, 제3 임계값(예를 들어, DNS 레졸루션을 위한 평균 시간 값) 이내에 DNS 응답을 수신하는가를 판단한다(S508). 제3 임계값 이내에 DNS 응답을 수신하지 못하였다면, 다른 통신 인터페이스 Inf 2를 통해 DNS 문의를 DNS 서버로 전송한다(S510, S512, S514).
도 14는 DNS 문의를 DNS 서버로 전송하기 위한 예시적인 상태를 도시한 도면이고, 도 15는 도 14의 DNS 문의에 따른 DNS 응답을 예시한 도면이다.
도 14 (a)는 통신 인터페이스 Inf 1의 이전 DNS 레졸루션 타임(Inf 1 Time)이 제1 임계값(Min Threshold 1)보다 크고, 통신 인터페이스 Inf 2의 이전 DNS 레졸루션 타임(Inf 2 Time)의 제2 임계값(Threshold 2) 범위 내에 속하는 경우이다. 이 경우에는, 도 15 (a)에 도시된 바와 같이, DNS 문의이 모든 통신 인터페이스들(WiFi 및 3G/LTE)을 통해 DNS 서버로 전송되며, DNS 서버로부터 DNS 응답을 각각 수신 및 저장(캐쉬)한다. 그 후, 먼저 수신된 DNS 응답에 대응하는 IP 주소 정보를 URL 프로토콜 핸들러로 전송한다.
도 14 (b)는 통신 인터페이스 Inf 1의 이전 DNS 레졸루션 타임(Inf 1 Time)이 제1 임계값(Min Threshold 1)보다 작은 경우를 의미하고, 도 14 (c)는 통신 인터페이스 Inf 1의 이전 DNS 레졸루션 타임(Inf 1 Time)이 제1 임계값(Min Threshold 1)보다 크고, 통신 인터페이스 Inf 2의 이전 DNS 레졸루션 타임(Inf 2 Time)의 제2 임계시간 범위(Threshold 2) 내에 속하지 않는 경우를 의미한다. 도 14 (b) 및 도 14 (c)의 경우에는, 도 15 (b)에 도시된 바와 같이, DNS 문의가 기 설정된 통신 인터페이스(WiFi)를 통해 DNS 서버로 전송되며, DNS 서버로부터 통신 인터페이스(WiFi)를 통해 DNS 응답을 수신 및 저장(캐쉬)한다. 그 후, 수신된 DNS 응답에 대응하는 IP 주소 정보를 URL 프로토콜 핸들러로 전송한다.
도 15 (b)에서, DNS 문의가 기 설정된 통신 인터페이스(WiFi)를 통해 DNS 서버로 전송된 후에, DNS 서버로부터 제3 임계 시간(Threshold 3) 동안 DNS 응답을 수신하지 못하는 경우에는, 도 15 (c)에 도시된 바와 같이, 기 설정된 통신 인터페이스(WiFi)가 아닌 다른 통신 인터페이스(3G/LTE)를 통해 DNS 서버로 DNS 문의를 전송하며, DNS 서버로부터 통신 인터페이스(3G/LTE)를 통해 DNS 응답을 수신 및 저장(캐쉬)한다. 그 후, 수신된 DNS 응답에 대응하는 IP 주소 정보를 URL 프로토콜 핸들러로 전송한다. 또한, DNS 서버로부터 전송된 DNS 응답에 대응하는 정보는 캐쉬 공간에 저장되며, 다음 DNS 문의에 대한 네트워크 상태를 판단하기 위한 정보로서 이용된다.
한편, 복수의 통신 인터페이스들(WiFi 및 3G/LTE)을 통해 수신된 DNS 응답에 대응하는 IP 주소 정보를 URL 프로토콜 핸들러로 각각 전송할 때에, 각각의 통신 인터페이스들(WiFi 및 3G/LTE)을 식별하기 위한 통신 인터페이스 식별정보를 IP 주소 정보와 함께 URL 프로토콜 핸들러로 전송한다.
도 16은 DNS 응답에 따라 URL 문의를 전송하기 위한 과정을 예시한 도면이다. 도 16에 따르면, DNS 핸들러는 복수의 통신 인터페이스들로 동시 또는 순차적으로 DNS 문의를 전송하고(S600, S602, S604, S606, S608), DNS 서버로부터 DNS 응답신호를 수신한다(S610). DNS 핸들러는 수신된 DNS 응답신호에 대응하는 IP주소정보를 인터페이스 식별정보와 함께 URL 프로토콜 핸들러로 전송한다(S612). URL 프로토콜 핸들러는 IP 주소 정보와 함께 수신된 통신 인터페이스 식별정보를 확인함으로써, 우선 수신되는 IP 주소 정보가 어느 통신 인터페이스를 통해 수신되는가를 판단할 수 있다. 따라서, URL 프로토콜 핸들러는 우선 수신되는 IP 주소 정보에 대응하는 통신 인터페이스로 HTTP 요청을 전송할 수 있다(S614).
도 17은 본 발명의 일 실시예에 따른 무선 통신 시스템의 단말기에서 DNS 레졸루션방법을 설명하기 위한 플로차트이다.
URL 프로토콜 핸들러로부터 호스트에 대한 DNS 문의신호를 수신하면, 메모리에 저장된 DNS 캐쉬정보와 상기 DNS 문의신호에 포함된 DNS 문의정보를 비교한다(S700). 여기서, 메모리는 전술한 도 7의 DNS 캐쉬(124)에 대응하는 구성요소이다.
상기 DNS 캐쉬정보는 호스트 네임정보, 통신 인터페이스 식별정보, 통신 인터페이스에 대응하는 IP 버전정보 및 호스트 네임에 대응하는 IP 주소정보가 상호 매핑되어 있다. 예를 들어, 도 9에 도시된 바와 같이, 메모리에 저장된 DNS 캐쉬정보 (1)은 IP 버전정보에 해당하는 IPv6와, 호스트 네임정보에 해당하는 ABC와, 통신 인터페이스 식별정보에 해당하는 Inf0와, IP 주소정보에 해당하는 IP0이 상호 매핑되어 있다. 또한, DNS 캐쉬정보 (2)는 IP 버전정보에 해당하는 IPv4와, 호스트 네임정보에 해당하는 ABC와, 통신 인터페이스 식별정보에 해당하는 Inf1과, IP 주소정보에 해당하는 IP1이 상호 매핑되어 있다. 또한, DNS 캐쉬정보 (3)은 IP 버전정보에 해당하는 IPv6와 호스트 네임정보에 해당하는 ABC와 함께, 통신 인터페이스 식별정보에 해당하는 Inf0 및 Inf1과, IP 주소정보에 해당하는 IP2 및 IP3이 상호 매핑되어 있다. 즉, DNS 캐쉬정보는 상기 IP 버전정보 및 상기 호스트 네임정보가 각각 동일하고, 서로 다른 통신 인터페이스 식별정보 및 IP 주소정보를 적어도 2개 이상 포함할 수 있다. 또한, DNS 캐쉬정보 (4)는 IP 버전정보에 해당하는 IPv6와 호스트 네임정보에 해당하는 ABC와 함께, 통신 인터페이스 식별정보에 해당하는 Inf0 및 Inf1과, IP 주소정보에 해당하는 IP4 및 NoHost가 상호 매핑되어 있다. 여기서, NoHost가 의미하는 것은 IP 버전정보, 호스트 네임정보 및 통신 인터페이스 식별정보에 매핑되는 호스트 IP주소 정보가 존재하지 않음을 의미한다.
상기 DNS 문의신호는 통신 인터페이스 식별정보, 통신 인터페이스에 대응하는 IP 버전정보 및 호스트 네임정보 등을 갖는 DNS 문의정보를 포함하고 있다. 통신 인터페이스 식별정보, IP 버전정보 및 호스트 네임정보는 호스트의 IP 주소정보를 획득하기 위해 필요한 정보이다.
DNS 문의신호가 수신되면, 무선 통신 시스템의 DNS 레졸루션 장치는 메모리에 저장된 DNS 캐쉬정보와 상기 DNS 문의신호에 포함된 DNS 문의정보가 일치하는가를 비교한다.
S700 단계에서, 상기 DNS 캐쉬정보와 상기 DNS 문의정보가 일치한다면, 메모리에 저장된 IP 주소정보를 상기 URL 프로토콜 핸들러로 전송한다(S702). 상기 DNS 캐쉬정보에 포함된 IP 버전정보 및/또는 호스트 네임정보가 상기 DNS 문의정보에 포함된 IP 버전정보 및/또는 호스트 네임정보와 일치한다면, 상기 IP 버전정보 및/또는 상기 호스트 네임정보에 대응하는 IP 주소정보를 상기 URL 프로토콜 핸들러로 전송한다.
일 예로, DNS 문의신호에 포함된 IP 버전정보가 IPv6이고, 호스트 네임정보가 ABC에 해당하고, 메모리에 저장된 DNS 캐쉬정보가 도 9에 도시된 DNS 캐쉬 정보 (1) 내지 (4) 중에서 DNS 캐쉬 정보 (1)에 해당한다고 가정한다.
DNS 캐쉬정보 (1)은 IP 버전정보에 해당하는 IPv6와, 호스트 네임정보에 해당하는 ABC와, 통신 인터페이스 식별정보에 해당하는 Inf0와, IP 주소정보에 해당하는 IP0이 상호 매핑되어 있으므로, DNS 문의신호에 포함된 IP 버전정보 IPv6 및 호스트 네임정보 ABC가 DNS 캐쉬정보 (1)의 IP 버전정보 IPv6 및 호스트 네임정보 ABC와 일치하므로, DNS 캐쉬정보 (1)에 매핑된 통신 인터페이스 식별정보 Inf0와 IP 주소정보 IP0를 URL 프로토콜 핸들러로 전송한다.
또 다른 예로, DNS 문의신호에 포함된 IP 버전정보가 IPv6이고, 호스트 네임정보가 ABC에 해당하고, 메모리에 저장된 DNS 캐쉬정보가 도 9에 도시된 DNS 캐쉬 정보 (1) 내지 (4) 중에서 DNS 캐쉬 정보 (3)에 해당한다고 가정한다.
DNS 캐쉬정보 (3)은 IP 버전정보에 해당하는 IPv6와 호스트 네임정보에 해당하는 ABC와 함께, 통신 인터페이스 식별정보에 해당하는 Inf0 및 Inf1과, IP 주소정보에 해당하는 IP2 및 IP3이 상호 매핑되어 있다. 따라서, DNS 문의신호에 포함된 IP 버전정보 IPv6 및 호스트 네임정보 ABC가 DNS 캐쉬정보 (3)의 IP 버전정보 IPv6 및 호스트 네임정보 ABC와 일치하므로, DNS 캐쉬정보 (3)에 매핑된 통신 인터페이스 식별정보 Inf0와 IP 주소정보 IP2를 URL 프로토콜 핸들러로 전송하거나, 통신 인터페이스 식별정보 Inf1과 IP 주소정보 IP3을 URL 프로토콜 핸들러로 전송할 수 있다.
이때, 상기 IP 버전정보 및 상기 호스트 네임정보에 대응하는 상기 IP 주소정보가 적어도 2개 이상 존재한다면, 상기 2개 이상의 IP 주소정보들 중에서 기 설정된 방식에 따라, IP주소정보를 상기 URL 프로토콜 핸들러로 전송한다. 기 설정된 방식으로서, 상기 2개 이상의 IP 주소정보들 중에서 상대적으로 적은 전력을 소비하거나, 전송 속도가 빠른 통신 인터페이스에 대응하는 IP주소 정보를 상기 URL 프로토콜 핸들러로 전송한다. 예를 들어, DNS 캐쉬정보 (3)에 매핑된 정보 중에서 통신 인터페이스 식별정보 Inf0에 해당하는 WiFi 통신 인터페이스의 전송 속도가 통신 인터페이스 식별정보 Inf1에 해당하는 3G/LTE 통신 인터페이스보다 빠른 경우에는, 통신 인터페이스 식별정보 Inf0와 IP 주소정보 IP2를 URL 프로토콜 핸들러로 전송한다.
또 다른 예로, DNS 문의신호에 포함된 IP 버전정보가 IPv6이고, 호스트 네임정보가 ABC에 해당하고, 메모리에 저장된 DNS 캐쉬정보가 도 9에 도시된 DNS 캐쉬 정보 (1) 내지 (4) 중에서 DNS 캐쉬 정보 (4)에 해당한다고 가정한다.
DNS 캐쉬정보 (4)는 IP 버전정보에 해당하는 IPv6와 호스트 네임정보에 해당하는 ABC와 함께, 통신 인터페이스 식별정보에 해당하는 Inf0 및 Inf1과, IP 주소정보에 해당하는 IP4 및 NoHost가 상호 매핑되어 있다. 따라서, DNS 문의신호에 포함된 IP 버전정보 IPv6 및 호스트 네임정보 ABC가 DNS 캐쉬정보 (4)의 IP 버전정보 IPv6 및 호스트 네임정보 ABC와 일치하므로, DNS 캐쉬정보 (4)에 매핑된 통신 인터페이스 식별정보 Inf1과 IP 주소정보 IP4를 URL 프로토콜 핸들러로 전송한다. DNS 캐쉬정보 (4)는 통신 인터페이스 식별정보 Inf1에 매칭되는 IP 주소정보 IP4가 존재하지만, 통신 인터페이스 식별정보 Inf0에 매칭되는 IP 주소정보가 존재하지 않는다는 점(NoHost)에서, 통신 인터페이스 식별정보 Inf0 및 이에 대응하는 NoHost 정보가 URL 프로토콜 핸들러로 전송되지는 않는다.
S700 단계에서, 상기 DNS 캐쉬정보와 상기 DNS 문의정보가 일치하지 않는다면, 상기 DNS 문의신호를 적어도 하나 이상의 통신 인터페이스를 통해 DNS 서버로 전송한다(S704). 상기 DNS 캐쉬정보에 포함된 IP 버전정보 및 호스트 네임정보가 상기 DNS 문의정보에 포함된 IP 버전정보 및 호스트 네임정보와 일치하지 않는다면, 상기 DNS 문의신호를 통신 인터페이스를 통해 DNS 서버로 전송한다.
예를 들어, DNS 문의신호에 포함된 IP 버전정보가 IPv6이고, 호스트 네임정보가 ABC에 해당하고, 메모리에 저장된 DNS 캐쉬정보가 도 9에 도시된 DNS 캐쉬 정보 (1) 내지 (4) 중에서 DNS 캐쉬 정보 (2)에 해당한다고 가정한다. DNS 캐쉬정보 (2)는 IP 버전정보에 해당하는 IPv4와, 호스트 네임정보에 해당하는 ABC와, 통신 인터페이스 식별정보에 해당하는 Inf1과, IP 주소정보에 해당하는 IP1이 상호 매핑되어 있다. 따라서, DNS 문의신호에 포함된 IP 버전정보 IPv6는 DNS 캐쉬정보 (2)의 IP 버전정보 IPv4와 일치하지 않으므로, DNS 문의신호에 대응하는 정보가 DNS 캐쉬에 저장되어 있지 않은 미스(MISS) 상태에 해당한다. 이때에는, DNS 문의신호를 하나 이상의 통신 인터페이스를 통해 DNS 서버로 전송한다. S704 단계는 후술하는 도 18에서 상세히 설명한다.
S704 단계 후에, 상기 DNS 서버로부터 상기 DNS 문의신호에 대응하는 IP 주소정보를 포함하는 DNS 응답신호를 수신한다(S706). DNS 서버로부터 DNS 문의신호에 따른 DNS 응답신호를 네트워크를 통해 수신한다. DNS 응답신호는 DNS 문의신호를 DNS 서버로 전송한 통신 인터페이스를 통해 수신된다. 예를 들어, DNS 문의신호가 WiFi 통신 인터페이스를 통해 DNS 서버로 전송되었다면, DNS 응답신호가 WiFi 통신 인터페이스를 통해 수신된다. 또한, DNS 문의신호가 3G/LTE 통신 인터페이스를 통해 DNS 서버로 전송되었다면, DNS 응답신호가 3G/LTE 통신 인터페이스를 통해 수신된다.
S706 단계 후에, 상기 수신된 DNS 응답신호에 포함된 상기 IP 주소정보를 저장 및 상기 URL 프로토콜 핸들러로 전송한다(S708). 상기 DNS 문의신호에 대응하는 상기 DNS 응답신호가 상기 2 이상의 통신 인터페이스들을 통해 수신되는 경우에, 먼저 수신된 DNS 응답신호에 대응하는 IP 주소정보를 상기 URL 프로토콜 핸들러로 전송한다. 상기 DNS 문의신호에 대응하는 상기 DNS 응답신호가 상기 2 이상의 통신 인터페이스들을 통해 수신되는 경우에, 상기 2 이상의 통신 인터페이스들의 식별정보들을 상기 IP 주소정보와 함께 상기 URL 프로토콜 핸들러로 전송한다. 예를 들어, 복수의 통신 인터페이스들(WiFi 및 3G/LTE)을 통해 수신된 DNS 응답에 대응하는 IP 주소 정보를 URL 프로토콜 핸들러로 각각 전송할 때에, 각각의 통신 인터페이스들(WiFi 및 3G/LTE)을 식별하기 위한 통신 인터페이스 식별정보를 IP 주소 정보와 함께 URL 프로토콜 핸들러로 전송한다. 이에 따라, URL 프로토콜 핸들러는 IP 주소 정보와 함께 수신된 통신 인터페이스 식별정보를 확인함으로써, 우선 수신되는 IP 주소 정보가 어느 통신 인터페이스를 통해 수신되는가를 판단할 수 있다. 따라서, URL 프로토콜 핸들러는 우선 수신되는 IP 주소 정보에 대응하는 통신 인터페이스로 HTTP 요청을 전송한다.
한편, 상기 수신된 DNS 응답신호에 포함된 상기 IP 주소정보가 상기 DNS 캐쉬정보로서 메모리에 저장된다. 메모리는 상기 수신된 DNS 응답신호에 대응하는 IP 버전정보, 호스트 네임정보, 통신 인터페이스 식별정보 및 상기 DNS 서버로부터 수신된 IP 주소정보를 매핑하여 저장한다. 메모리에 저장된 DNS 캐쉬정보는 이후의 DNS 레졸루션을 위한 정보로서 이용된다.
도 18은 DNS 문의신호를 적어도 하나 이상의 통신 인터페이스를 통해 DNS 서버로 전송하는 과정을 설명하기 위한 일 실시예의 플로차트이다. 특히, 상기 통신 인터페이스의 종류가 적어도 2 이상에 해당한다면, 상기 2 이상의 통신 인터페이스들 중 적어도 하나 이상의 통신 인터페이스를 결정하고, 상기 결정된 통신 인터페이스를 통해 상기 DNS 문의신호를 상기 DNS 서버로 전송한다.
상기 통신 인터페이스의 종류가 적어도 2 이상에 해당한다면, 상기 2개 이상의 통신 인터페이스들 중에서 기 설정된 방식에 따라, 어느 하나의 통신 인터페이스를 결정한다. 기 설정된 방식으로서, 상기 2개 이상의 통신 인터페이스들 중에서 상대적으로 적은 전력을 소비하거나, 전송 속도가 빠른 통신 인터페이스를 결정한다. 예를 들어, WiFi 통신 인터페이스 및 3G/LTE 통신 인터페이스 등이 존재한다고 할 때, WiFi 통신 인터페이스의 전송 속도가 3G/LTE 통신 인터페이스보다 빠른 경우에는, DNS 문의신호를 DNS 서버로 전송하기 위한 통신 인터페이스로서 WiFi 통신 인터페이스를 결정한다.
2 이상의 통신 인터페이스들 중 하나에 해당하는 제1 통신 인터페이스를 통한 제1 DNS 레졸루션 시간이 제1 임계시간 이하에 해당하는가를 판단한다(S800). 제1 DNS 레졸루션 시간은 제1 통신 인터페이스에 의한 이전의 DNS 레졸루션에 따른 소요 시간을 의미한다. 즉, 이전 과정에서 제1 통신 인터페이스를 통해 DNS 레졸루션을 달성하는데 필요한 시간을 의미한다. 이러한, 제1 DNS 레졸루션 시간은 후술하는 네트워크 상태 관리부에 저장되어 있다. 예를 들어, 전술한 도 14에 도시된 바와 같이, 제1 통신 인터페이스(Inf 1)의 제1 DNS 레졸루션 시간(Inf 1 Time)이 제1 임계시간(Min Threshold 1) 이하에 해당하는가를 판단한다.
S800 단계에서, 상기 제1 DNS 레졸루션 시간이 상기 제1 임계시간 이하에 해당한다면, 상기 제1 통신 인터페이스를 통해 상기 DNS 문의신호를 상기 제1 통신 인터페이스에 대응하는 제1 DNS 서버로 전송한다(S802). 예를 들어, 전술한 도 14(b)에 도시된 바와 같이, 제1 통신 인터페이스(Inf 1)의 제1 DNS 레졸루션 시간(Inf 1 Time)이 제1 임계시간(Min Threshold 1) 이하에 해당한다면, DNS 문의신호를 제1 통신 인터페이스(Inf 1)와 네트워크로 연결되어 있는 제1 DNS 서버로 전송한다. 상기 제1 DNS 레졸루션 시간이 상기 제1 임계시간 이하에 해당한다면, 도 15 (b)에 도시된 바와 같이, DNS 문의가 제1 통신 인터페이스(WiFi)를 통해 제1 DNS 서버로 전송된다.
한편, S800 단계에서, 상기 제1 DNS 레졸루션 시간이 상기 제1 임계시간을 초과한다면, 상기 제1 DNS 레졸루션 시간이 상기 2 이상의 통신 인터페이스들 중 다른 하나에 해당하는 제2 통신 인터페이스를 통한 제2 DNS 레졸루션 시간의 제2 임계시간 범위 내에 해당하는가를 판단한다(S804). 제2 DNS 레졸루션 시간은 제2 통신 인터페이스에 의한 이전의 DNS 레졸루션에 따른 소요 시간을 의미한다. 즉, 이전 과정에서 제2 통신 인터페이스를 통해 DNS 레졸루션을 달성하는데 필요한 시간을 의미한다. 이러한, 제2 DNS 레졸루션 시간도 네트워크 상태 관리부에 저장되어 있다. 전술한 도 14에 도시된 바와 같이, 제1 통신 인터페이스(Inf 1)의 제1 DNS 레졸루션 시간(Inf 1 Time)이 제1 임계시간(Min Threshold 1) 보다 크다고 할 때, 제1 DNS 레졸루션 시간(Inf 1 Time)이 제2 DNS 레졸루션 시간(Inf 2 Time)의 제2 임계시간 범위(Threshold 2) 내에 속하는가를 판단한다.
S804 단계에서, 상기 제1 DNS 레졸루션 시간이 상기 제2 임계시간 범위 내에 해당하지 않는다면, 상기 제1 통신 인터페이스를 통해 상기 DNS 문의신호를 상기 제1 DNS 서버로 전송한다. 예를 들어, 전술한 도 14 (c)에 도시된 바와 같이, 제1 통신 인터페이스(Inf 1)의 제1 DNS 레졸루션 시간(Inf 1 Time)이 제1 임계시간(Min Threshold 1)보다 크고, 제2 통신 인터페이스(Inf 2)의 제2 DNS 레졸루션 시간(Inf 2 Time)의 제2 임계시간 범위(Threshold 2) 내에 속하지 않는 경우를 의미한다. 이때에도, 도 15 (b)에 도시된 바와 같이, DNS 문의신호가 제1 통신 인터페이스(WiFi)를 통해 제1DNS 서버로 전송된다.
그러나, S804 단계에서, 상기 제1 DNS 레졸루션 시간이 상기 제2 임계시간 범위 내에 해당한다면, 상기 DNS 문의신호를 상기 제1 통신 인터페이스 및 상기 제2 통신 인터페이스를 통해 각각 상기 제1 DNS 서버 및 상기 제2 통신 인터페이스에 대응하는 제2 DNS 서버로 전송한다(S806). 예를 들어, 도 14 (a)에 도시된 바와 같이, 제1 통신 인터페이스(Inf 1)의 제1 DNS 레졸루션 시간(Inf 1 Time)이 제1 임계시간(Min Threshold 1)보다 크고, 제2 통신 인터페이스(Inf 2)의 제2 DNS 레졸루션 시간(Inf 2 Time)의 제2 임계시간 범위(Threshold 2) 내에 속하는 경우이다. 이 경우에는, 도 15 (a)에 도시된 바와 같이, DNS 문의신호가 모든 통신 인터페이스들(WiFi 및 3G/LTE)을 통해 각각 제1 DNS 서버 및 제2 DNS 서버로 전송된다.
한편, S802 단계 후에, 상기 DNS 문의신호에 대응하는 상기 DNS 응답신호를 제3 임계시간 내에 수신하였는가를 판단한다(S808). 여기서, 제3 임계시간은 DNS 레졸루션을 위한 평균 시간에 해당한다. DNS 레졸루션을 위한 평균 시간은 각 DNS 레졸루션의 시간의 합산값을 DNS 레졸루션 횟수로 나눈 값을 의미한다.
S808 단계에서, 상기 DNS 응답신호가 상기 제3 임계시간 내에 수신되지 않았다면, 상기 2 이상의 통신 인터페이스들 중에서 제2 통신 인터페이스를 통해 상기 DNS 문의신호를 상기 제2 DNS 서버로 전송한다(S810). DNS 문의가 제1 통신 인터페이스를 통해 DNS 서버로 전송된 후에, 제3 임계값 이내에 DNS 응답을 수신하지 못하였다는 것은, 해당 통신 인터페이스의 전송 속도가 늦다는 것을 의미한다. 따라서, 이때에는, 도 15 (c)에 도시된 바와 같이, 제1 통신 인터페이스(WiFi)가 아닌 다른 통신 인터페이스 즉, 제2 통신 인터페이스(3G/LTE)를 통해 제2 DNS 서버로 DNS 문의신호를 전송한다.
도 19는 본 발명의 일 실시예에 따른 무선 통신 시스템의 단말기에서 DNS 레졸루션 장치를 설명하기 위한 블록도이다. 본 발명에 따른 DNS 레졸루션 장치(900)는 휴대용 단말기 내에 구비되어 있는 것으로, 휴대용 단말기는 DNS 레졸루션 장치(900) 이외에 URL 프로토콜 핸들러(910), 통신 인터페이스 1(920) 및 통신 인터페이스 2(930)을 포함하며, 휴대용 단말기의 일반적인 동작을 위한 구성요소는 도시되어 있지 않다. 기타 구성요소로서, 설명의 편의를 위해, DNS 서버 1(940) 및 DNS 서버 2(950)가 도시되어 있다. 한편, 도 19에서는 각각 2개의 DNS 서브 핸들러들과 통신 인터페이스들을 도시하였지만, 이것은 예시적인 것에 불과하며 필요에 따라 그 갯수는 증가할 수 있다.
여기서, 휴대용 단말기는 스마트 폰(smartphone), 태블릿 PC(tablet personal computer), 이동 전화기(mobile phone), 화상전화기, 전자북 리더기(e-book reader), 넷북 컴퓨터(netbook computer), PDA(personal digital assistant), PMP(portable multimedia player), MP3 플레이어, 모바일 의료기기, 카메라(camera), 또는 웨어러블 전자장치(wearable device)(예: 전자 안경과 같은 head-mounted-device(HMD), 전자 의복, 전자 팔찌, 전자 목걸이, 전자 앱세서리(appcessory), 전자 문신, 또는 스마트 와치(smart watch)) 등을 포함한다.
DNS 레졸루션 장치(900)는 메모리(901), 컨트롤러(902), 네트워크 상태 관리부(903), DNS 서브 핸들러 1(904) 및 DNS 서브 핸들러 2(905)를 포함한다.
메모리(901)는 DNS 캐쉬정보를 저장하고 있다. 메모리(901)는 호스트 네임정보, 통신 인터페이스 식별정보, 통신 인터페이스에 대응하는 IP 버전정보 및 호스트 네임에 대응하는 IP 주소정보 등을 상호 매핑하여 저장하고 있다. 메모리(901)는 상기 IP 버전정보 및 상기 호스트 네임정보가 각각 동일하고, 서로 다른 통신 인터페이스 식별정보 및 IP 주소정보를 적어도 2개 이상 포함할 수 있다.
컨트롤러(902)는 URL 프로토콜 핸들러(910)로부터 호스트에 대한 DNS 문의신호를 수신하면, 메모리(901)에 저장된 DNS 캐쉬정보와 DNS 문의신호에 포함된 DNS 문의정보를 비교하고, DNS 캐쉬정보와 DNS 문의정보의 비교 결과에 따라, 호스트에 대응하는 IP 주소정보를 URL 프로토콜 핸들러(910)로 전송한다. 여기서, DNS 문의정보는 통신 인터페이스 식별정보, IP 버전정보 및 호스트 네임정보 등을 포함한다.
컨트롤러(902)는 메모리(901)를 액세스하여, 상기 DNS 캐쉬정보에 포함된 IP 버전정보 및/또는 호스트 네임정보가 DNS 문의정보에 포함된 IP 버전정보 및/또는 호스트 네임정보와 일치한다면, IP 버전 정보 및/또는 호스트 네임정보에 대응하는 IP 주소정보를 상기 URL 프로토콜 핸들러(910)로 전송한다.
컨트롤러(902)는 상기 IP 버전정보 및 상기 호스트 네임정보에 대응하는 상기 IP 주소정보가 적어도 2개 이상 존재한다면, 상기 2개 이상의 IP 주소정보들 중에서 기 설정된 IP 주소정보를 상기 URL 프로토콜 핸들러로 전송한다. 이때, 컨트롤러(902)는 상기 2개 이상의 IP 주소정보들 중에서 상대적으로 적은 전력을 소비하거나, 전송 속도가 빠른 통신 인터페이스에 대응하는 IP주소 정보를 상기 URL 프로토콜 핸들러로 전송한다.
DNS 서브 핸들러 1(904) 및 DNS 서브 핸들러 2(905)는 각각 컨트롤러(902)의 제어에 따라, DNS 문의신호를 통신 인터페이스 1(920) 및 통신 인터페이스 2(930)를 통해 각각 DNS 서버 1(940) 및 DNS 서버 2(950)로 전송한다.
컨트롤러(902)는 메모리(901)를 액세스하여, DNS 캐쉬정보에 포함된 IP 버전정보 및 호스트 네임정보가 상기 DNS 문의정보에 포함된 IP 버전정보 및 호스트 네임정보와 일치하지 않는다면, 상기 DNS 문의신호를 DNS 서브 핸들러 1(904) 및 DNS 서브 핸들러 2(905) 중 적어도 하나의 통신 인터페이스를 통해 DNS 서버 1(940) 및/또는 DNS 서버 2(950)로 전송하도록 제어한다. 그 후, DNS 서버 1(940) 및/또는 DNS 서버 2(950)로부터 상기 DNS 문의신호에 대응하는 상기 IP 주소정보를 포함하는 DNS 응답신호를 상기 하나 이상의 통신 인터페이스를 통해 수신하면, 컨트롤러(902)는 상기 수신된 DNS 응답신호에 포함된 상기 IP 주소정보를 상기 URL 프로토콜 핸들러(910)로 전송한다.
컨트롤러(902)는 상기 통신 인터페이스의 종류가 적어도 2 이상에 해당한다면, 상기 2 이상의 통신 인터페이스들 중 적어도 하나 이상의 통신 인터페이스를 결정하고, 상기 결정된 통신 인터페이스를 통해 상기 DNS 문의신호를 상기 DNS 서버로 전송하도록 제어한다. 컨트롤러(902)는 상기 2개 이상의 통신 인터페이스들 중에서 상대적으로 적은 전력을 소비하거나, 전송 속도가 빠른 통신 인터페이스를 결정한다.
네트워크 상태 관리부(903)는 상기 적어도 하나 이상의 통신 인터페이스에 의한 이전의 DNS 레졸루션에 따른 소요 시간을 의미하는 DNS 레졸루션 시간을 저장 및 관리한다. 네트워크 상태 관리부(903)는 DNS 레졸루션이 수행된 각각의 통신 인터페이스 별로 구분하여 DNS 레졸루션 시간을 저장 및 관리한다. 예를 들어, 네트워크 상태 관리부(903)는 제1 통신 인터페이스를 통해 수행된 DNS 레졸루션에 따른 제1 DNS 레졸루션 시간을 저장하며, 제2 통신 인터페이스를 통해 수행된 DNS 레졸루션에 따른 제2 DNS 레졸루션 시간을 저장한다.
컨트롤러(902)는 네트워크 상태 관리부(903)를 액세스하여, 상기 2 이상의 통신 인터페이스들 중 하나에 해당하는 통신 인터페이스 1(920)을 통한 제1 DNS 레졸루션 시간이 제1 임계시간 이하에 해당하는가를 판단하고, 상기 제1 DNS 레졸루션 시간이 상기 제1 임계시간 이하에 해당한다면, 상기 통신 인터페이스 1(920)을 통해 상기 DNS 문의신호를 통신 인터페이스 1(920)에 대응하는 DNS 서버 1(940)로 전송하도록 제어한다.
컨트롤러(902)는 상기 제1 DNS 레졸루션 시간이 상기 제1 임계시간을 초과한다면, 상기 제1 DNS 레졸루션 시간이 상기 2 이상의 통신 인터페이스들 중 다른 하나에 해당하는 통신 인터페이스 2(930)를 통한 제2 DNS 레졸루션 시간의 제2 임계시간 범위 내에 해당하는가를 판단하고, 상기 제1 DNS 레졸루션 시간이 상기 제2 임계시간 범위 내에 해당하지 않는다면, 통신 인터페이스 1(920)을 통해 DNS 문의신호를 DNS 서버 1(940)로 전송하도록 제어한다.
컨트롤러(902)는 제1 DNS 레졸루션 시간이 제2 임계시간 범위 내에 해당한다면, DNS 문의신호를 통신 인터페이스 1(920) 및 통신 인터페이스 2(930)를 통해 각각 DNS 서버 1(940) 및 DNS 서버 2(950)로 전송하도록 제어한다.
컨트롤러(902)는 상기 결정된 통신 인터페이스를 통해 상기 DNS 문의신호를 상기 DNS 서버로 전송한 후에, 상기 DNS 문의신호에 대응하는 상기 DNS 응답신호를 제3 임계시간 내에 수신하였는가를 판단하고, 상기 DNS 응답신호가 상기 제3 임계시간 내에 수신되지 않았다면, 상기 2 이상의 통신 인터페이스들 중에서 어느 하나의 통신 인터페이스를 통해 상기 DNS 문의신호를 상기 DNS 서버로 전송하도록 제어한다. 제3 임계시간은 DNS 레졸루션을 위한 평균 시간에 해당한다.
컨트롤러(902)는 상기 DNS 문의신호에 대응하는 상기 DNS 응답신호가 상기 2 이상의 통신 인터페이스들을 통해 수신되는 경우에, 먼저 수신된 DNS 응답신호에 대응하는 IP 주소정보를 상기 URL 프로토콜 핸들러(910)로 전송한다. 이때, 컨트롤러(902)는 상기 DNS 문의신호에 대응하는 상기 DNS 응답신호가 상기 2 이상의 통신 인터페이스들을 통해 수신되는 경우에, 상기 2 이상의 통신 인터페이스들의 식별정보들을 상기 IP 주소정보와 함께 상기 URL 프로토콜 핸들러(910)로 전송한다.
컨트롤러(902)는 상기 수신된 DNS 응답신호에 포함된 상기 IP 주소정보를 상기 DNS 캐쉬정보로서 메모리(901)에 저장하도록 제어한다. 컨트롤러(902)는 상기 수신된 DNS 응답신호에 대응하는 IP 버전정보, 호스트 네임정보, 통신 인터페이스 식별정보와 각각 매핑하여 상기 IP 주소정보를 저장하도록 제어한다.
본 발명에 따르면, DNS 레졸루션에 대해 다음과 같은 동작 특성이 있다.
도 20은 2 이상의 통신 인터페이스가 서로 다른 IP 버전을 갖는 경우를 예시한 것이다. 도 20에 따르면, 통신 인터페이스 0이 IPv4에 해당하고, 통신 인터페이스 1이 IPv6에 해당하는 경우이다. DNS 핸들러가 IPv4에 대한 DNS 문의를 수신하면, DNS 문의가 통신 인터페이스 0을 통해 DNS 서버 1로 전송되고, DNS 핸들러가 IPv6에 대한 DNS 문의를 수신하면, DNS 문의가 통신 인터페이스 1을 통해 DNS 서버 2로 전송된다.
도 21은 2 이상의 통신 인터페이스가 서로 동일한 IP 버전을 갖는 경우를 예시한 것이다. 도 21에 따르면, 컨트롤러가 복수의 DNS 서브 핸들러들 및 통신 인터페이스들을 통해 DNS 문의를 DNS 서버로 전송하고, DNS 서버로부터 우선적으로 수신된 DNS 응답신호를 URL 프로토콜 핸들러로 전송한다. 이에 따르면, 각각의 통신 인터페이스의 전송속도에 따라, 보다 빨리 DNS 레졸루션을 수행할 수 있도록 한다.
도 22는 DNS 캐쉬에 저장된 정보를 이용하여 DNS 레졸루션을 수행하는 경우를 예시한 것이다. 도 22에 따르면, 이전의 DNS 응답에 따른 정보가 DNS 캐쉬에 저장되어 있는 경우에, 동일한 DNS 문의가 수신되면, DNS 캐쉬에 저장된 DNS 정보를 URL 프로토콜 핸들러로 전송한다. 이에 따르면, 각각의 통신 인터페이스와 이와 대응하는 DNS 서버에 접속하지 않은 상태에서도 신속하게 DNS 레졸루션을 수행할 수 있도록 한다.
도 23은 2 이상의 통신 인터페이스가 서로 다른 전송 속도를 갖는 경우를 예시한 것이다. 도 23에 따르면, 통신 인터페이스 WiFi가 통신 인터페이스 3G/LTE보다 전송 속도가 빠른 경우에, 통신 인터페이스 WiFi를 통해 DNS 레졸루션이 수행되며, 통신 인터페이스 3G/LTE는 대기 모드(Idle) 상태를 유지하게 된다. 이에 따라, 통신 인터페이스 3G/LTE의 비활성화로 인해 전력 소모를 방지할 수 있다.
도 24는 2 이상의 통신 인터페이스를 통해 수신된 DNS 응답 정보가 DNS 캐쉬에 저장된 상태에서 DNS 레졸루션을 수행하는 경우를 예시한 것이다. 도 24에 따르면, 어느 하나의 통신 인터페이스가 네트워크와 연결되어 있지 않다고 하더라도, DNS 캐쉬에 저장된 정보를 이용하여 DNS 레졸루션을 수행할 수 있다.
도 25는 2 이상의 통신 인터페이스를 통해 DNS 응답신호를 수신한 URL 프로토콜 핸들러의 동작을 예시한 것이다. 도 25에 따르면, URL 프로토콜 핸들러는 2 이상의 통신 인터페이스를 통해 수신한 DNS 응답신호 중에서 전송 속도가 보다 빠는 통신 인터페이스(예를 들어, 3G/LTE)를 통해 우선적으로 URL 문의를 전송할 수 있다.
도 26은 2 이상의 통신 인터페이스가 서로 다른 전송 속도를 갖는 경우에 DNS 핸들러의 동작을 예시한 것이다. 도 26에 따르면, 기 설정된 통신 인터페이스 WiFi를 통한 DNS 응답신호가 일정 시간이 지나도 수신되지 않는 경우에는 다른 통신 인터페이스 3G/LTE를 통해 DNS 문의를 할 수 있고, 이에 따라, 통신 인터페이스 3G/LTE를 통해 DNS 응답신호를 신속하게 수신할 수 있다.
본 발명의 청구항 및/또는 명세서에 기재된 실시 예들에 따른 방법들은 하드웨어, 소프트웨어, 또는 하드웨어와 소프트웨어의 조합의 형태로 구현될(implemented) 수 있다. 소프트웨어로 구현하는 경우, 하나 이상의 프로그램(소프트웨어 모듈)을 저장하는 컴퓨터 판독 가능 저장 매체가 제공될 수 있다. 컴퓨터 판독 가능 저장 매체에 저장되는 하나 이상의 프로그램은, 전자 장치(device) 내의 하나 이상의 프로세서에 의해 실행 가능하도록 구성된다(configured for execution). 하나 이상의 프로그램은, 전자 장치로 하여금, 본 발명의 청구항 및/또는 명세서에 기재된 실시 예들에 따른 방법들을 실행하게 하는 명령어(instructions)를 포함한다.
이러한 프로그램(소프트웨어 모듈, 소프트웨어)은 랜덤 액세스 메모리 (random access memory), 플래시(flash) 메모리를 포함하는 불휘발성(non-volatile) 메모리, 롬(ROM, Read Only Memory), 전기적 삭제가능 프로그램가능 롬(EEPROM, Electrically Erasable Programmable Read Only Memory), 자기 디스크 저장 장치(magnetic disc storage device), 컴팩트 디스크 롬(CD-ROM, Compact Disc-ROM), 디지털 다목적 디스크(DVDs, Digital Versatile Discs) 또는 다른 형태의 광학 저장 장치, 마그네틱 카세트(magnetic cassette)에 저장될 수 있다. 또는, 이들의 일부 또는 전부의 조합으로 구성된 메모리에 저장될 수 있다. 또한, 각각의 구성 메모리는 다수 개 포함될 수도 있다.
또한, 전자 장치에 인터넷(Internet), 인트라넷(Intranet), LAN(Local Area Network), WLAN(Wide LAN), 또는 SAN(Storage Area Network)과 같은 통신 네트워크, 또는 이들의 조합으로 구성된 통신 네트워크를 통하여 접근(access)할 수 있는 부착 가능한(attachable) 저장 장치(storage device)에 저장될 수 있다. 이러한 저장 장치는 외부 포트를 통하여 전자 장치에 접속할 수 있다. 또한, 통신 네트워크상의 별도의 저장장치가 휴대용 전자 장치에 접속할 수도 있다.
900: DNS 레졸루션장치
901: 메모리
902: 컨트롤러
903: 네트워크 상태 관리부
904: DNS 서브 핸들러 1
905: DNS 서브 핸들러 2
910: URL 프로토콜 핸들러
920: 통신 인터페이스 1
930: 통신 인터페이스 2
940: DNS 서버 1
950: DNS 서버 2

Claims (38)

  1. 무선 통신 시스템의 단말에서 DNS(Domain Name Service) 레졸루션(resolution) 방법에 있어서,
    URL(Uniform Resource Locator) 프로토콜 핸들러로부터 호스트에 대한 DNS(Domain Name Service) 문의신호를 수신하면, 메모리에 저장된 DNS 캐쉬정보와 상기 DNS 문의신호에 포함된 DNS 문의정보를 비교하는 과정과,
    상기 DNS 캐쉬정보에 포함된 IP(internet protocol) 버전정보 및 호스트 네임정보가 상기 DNS 문의정보에 포함된 IP 버전정보 및 호스트 네임정보와 일치하지 않는다면, 2 이상의 통신 인터페이스들 중 하나에 해당하는 제1 통신 인터페이스를 통한 제1 DNS 레졸루션(resolution) 시간이 제1 임계시간 이하에 해당하는가를 판단하는 과정과,
    상기 제1 DNS 레졸루션 시간이 상기 제1 임계시간 이하에 해당한다면, 상기 제1 통신 인터페이스를 통해 상기 DNS 문의신호를 상기 제1 통신 인터페이스에 대응하는 제1 DNS 서버로 전송하는 과정을 포함하고,
    상기 DNS 캐쉬정보는 전송 속도 및 전력 소비량 중 적어도 하나에 기반하여 설정되는 방법.
  2. 청구항 1에 있어서,
    상기 DNS 캐쉬정보는 호스트 네임정보, 통신 인터페이스 식별정보, 통신 인터페이스에 대응하는 IP 버전정보 및 호스트 네임에 대응하는 IP 주소정보 중 적어도 하나 이상의 정보를 포함하는 방법.
  3. 청구항 1에 있어서,
    상기 DNS 문의정보는 통신 인터페이스 식별정보, 통신 인터페이스에 대응하는 IP 버전정보 및 호스트 네임정보 중 적어도 하나를 포함하는 것을 특징으로 하는 방법.
  4. 청구항 1에 있어서,
    상기 DNS 캐쉬정보에 포함된 호스트 네임정보가 상기 DNS 문의정보에 포함된 호스트 네임정보와 일치한다면, 상기 호스트 네임정보에 대응하는 IP 주소정보를 URL 프로토콜 핸들러로 전송하는 과정을 더 포함 하는 방법.
  5. 청구항 1항에 있어서,
    상기 DNS 캐쉬정보에 포함된 IP 버전정보 및 호스트 네임정보가 상기 DNS 문의정보에 포함된 IP 버전정보 및 호스트 네임정보와 일치한다면, 상기 IP 버전정보 및 상기 호스트 네임정보에 대응하는 IP 주소정보를 URL 프로토콜 핸들러로 전송하는 과정을 더 포함 하는 방법.
  6. 삭제
  7. 삭제
  8. 청구항 1항에 있어서,
    DNS 응답신호를 저장하기 위하여, DNS 서버로부터 상기 DNS 문의신호에 대응하는 상기 DNS 응답신호를 수신하는 과정과,
    저장된 상기 DNS 응답신호에 포함된 IP 주소정보를 URL 프로토콜 핸들러로 송신하는 과정 더 포함하는 방법.
  9. 삭제
  10. 삭제
  11. 청구항 1에 있어서,
    상기 제1 DNS 레졸루션 시간이 상기 제1 임계시간을 초과한다면, 상기 제1 DNS 레졸루션 시간이 상기 2 이상의 통신 인터페이스들 중 다른 하나에 해당하는 제2 통신 인터페이스를 통한 제2 DNS 레졸루션 시간의 제2 임계시간 범위 내에 해당하는가를 판단하는 과정과,
    상기 제1 DNS 레졸루션 시간이 상기 제2 임계시간 범위 내에 해당하지 않는다면, 상기 제1 통신 인터페이스를 통해 상기 DNS 문의신호를 상기 제1 DNS 서버로 전송하는 과정을 더 포함하는 방법.
  12. 청구항 11에 있어서,
    상기 제1 DNS 레졸루션 시간이 상기 제2 임계시간 범위 내에 해당한다면, 상기 DNS 문의신호를 상기 제1 통신 인터페이스 및 상기 제2 통신 인터페이스를 통해 각각 상기 제1 DNS 서버 및 상기 제2 통신 인터페이스에 대응하는 제2 DNS 서버로 전송하는 과정을 더 포함 하는 방법.
  13. 삭제
  14. 청구항 8항에 있어서,
    상기 DNS 문의신호에 대응하는 상기 DNS 응답신호를 미리 지정된 제3 임계시간 내에 수신하였는가를 판단하는 과정과,
    상기 DNS 응답신호가 상기 제3 임계시간 내에 수신되지 않았다면, 복수의 통신 인터페이스들 중에서 어느 하나의 통신 인터페이스를 통해 상기 DNS 문의신호를 전송하는 것을 특징으로 하는 방법.
  15. 삭제
  16. 삭제
  17. 삭제
  18. 삭제
  19. 삭제
  20. 무선 통신 시스템의 단말에서 DNS(Domain Name Service) 레졸루션 장치에 있어서,
    DNS 캐쉬정보를 저장하는 메모리; 및
    URL(Uniform Resource Locator) 프로토콜 핸들러로부터 호스트에 대한 DNS(Domain Name Service) 문의신호를 수신하면, 상기 메모리에 저장된 상기 DNS 캐쉬정보와 상기 DNS 문의신호에 포함된 DNS 문의정보를 비교하고,
    상기 DNS 캐쉬정보에 포함된 IP(internet protocol) 버전정보 및 호스트 네임정보가 상기 DNS 문의정보에 포함된 IP 버전정보 및 호스트 네임정보와 일치하지 않는다면, 2 이상의 통신 인터페이스들 중 하나에 해당하는 제1 통신 인터페이스를 통한 제1 DNS 레졸루션(resolution) 시간이 제1 임계시간 이하에 해당하는가를 판단하고, 상기 제1 DNS 레졸루션 시간이 상기 제1 임계시간 이하에 해당한다면, 상기 제1 통신 인터페이스를 통해 상기 DNS 문의신호를 상기 제1 통신 인터페이스에 대응하는 제1 DNS 서버로 송신하는 컨트롤러를 포함하고,
    상기 DNS 캐쉬정보는 전송 속도 및 전력 소비량 중 적어도 하나에 기반하여 설정되는 장치.

  21. 청구항 20에 있어서,
    상기 DNS 캐쉬정보는 호스트 네임정보, 통신 인터페이스 식별정보, 통신 인터페이스에 대응하는 IP 버전정보 및 호스트 네임에 대응하는 IP 주소정보 중 적어도 하나 이상의 정보를 포함하는 장치.
  22. 청구항 20에 있어서,
    상기 DNS 문의정보는 통신 인터페이스 식별정보, 통신 인터페이스에 대응하는 IP 버전정보 및 호스트 네임정보 중 적어도 하나를 포함하는 장치.
  23. 청구항 20에 있어서, 상기 컨트롤러는
    상기 DNS 캐쉬정보에 포함된 호스트 네임정보가 상기 DNS 문의정보에 포함된 호스트 네임정보와 일치한다면, 상기 호스트 네임정보에 대응하는 IP 주소정보를 URL 프로토콜 핸들러로 전송하는 장치.
  24. 청구항 20에 있어서, 상기 컨트롤러는
    상기 DNS 캐쉬정보에 포함된 IP 버전정보 및 호스트 네임정보가 상기 DNS 문의정보에 포함된 IP 버전정보 및 호스트 네임정보와 일치한다면, 상기 IP 버전정보 및 상기 호스트 네임정보에 대응하는 IP 주소정보를 URL 프로토콜 핸들러로 전송하는 하는 장치.
  25. 삭제
  26. 삭제
  27. 청구항 20에 있어서, 상기 컨트롤러는
    DNS 응답신호를 저장하기 위하여, DNS 서버로부터 상기 DNS 문의신호에 대응하는 상기 DNS 응답신호를 수신하고,
    저장된 상기 DNS 응답신호에 포함된 IP 주소정보를 URL 프로토콜 핸들러로 전송하는 장치.
  28. 삭제
  29. 삭제
  30. 청구항 20에 있어서, 상기 컨트롤러는
    상기 제1 DNS 레졸루션 시간이 상기 제1 임계시간을 초과한다면, 상기 제1 DNS 레졸루션 시간이 상기 2 이상의 통신 인터페이스들 중 다른 하나에 해당하는 제2 통신 인터페이스를 통한 제2 DNS 레졸루션 시간의 제2 임계시간 범위 내에 해당하는가를 판단하고, 상기 제1 DNS 레졸루션 시간이 상기 제2 임계시간 범위 내에 해당하지 않는다면, 상기 제1 통신 인터페이스를 통해 상기 DNS 문의신호를 상기 제1 DNS 서버로 전송하도록 제어하는 장치.
  31. 청구항 30에 있어서, 상기 컨트롤러는
    상기 제1 DNS 레졸루션 시간이 상기 제2 임계시간 범위 내에 해당한다면, 상기 DNS 문의신호를 상기 제1 통신 인터페이스 및 상기 제2 통신 인터페이스를 통해 각각 상기 제1 DNS 서버 및 상기 제2 통신 인터페이스에 대응하는 제2 DNS 서버로 전송하도록 제어하는 장치.
  32. 청구항 27에 있어서, 상기 컨트롤러는
    상기 DNS 문의신호에 대응하는 상기 DNS 응답신호를 미리 지정된 제3 임계시간 내에 수신하였는가를 판단하고, 상기 DNS 응답신호가 상기 제3 임계시간 내에 수신되지 않았다면, 복수의 통신 인터페이스들 중에서 어느 하나의 통신 인터페이스를 통해 상기 DNS 문의신호를 상기 DNS 서버로 전송하도록 제어하는 장치.
  33. 삭제
  34. 삭제
  35. 삭제
  36. 삭제
  37. 삭제
  38. 삭제
KR1020140133161A 2014-10-02 2014-10-02 무선 통신 시스템의 단말에서 DNS(Domain Name Service) 레졸루션 방법 및 장치 KR102154788B1 (ko)

Priority Applications (4)

Application Number Priority Date Filing Date Title
KR1020140133161A KR102154788B1 (ko) 2014-10-02 2014-10-02 무선 통신 시스템의 단말에서 DNS(Domain Name Service) 레졸루션 방법 및 장치
EP15846781.1A EP3203706B1 (en) 2014-10-02 2015-10-02 Device and method for transmitting and receiving data to and from terminal in wireless communication system
PCT/KR2015/010423 WO2016053045A1 (ko) 2014-10-02 2015-10-02 무선 통신 시스템의 단말기에서 데이터를 송수신하는 장치 및 방법
US15/512,389 US10448325B2 (en) 2014-10-02 2015-10-02 Device and method for transmitting and receiving data to and from terminal in wireless communication system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020140133161A KR102154788B1 (ko) 2014-10-02 2014-10-02 무선 통신 시스템의 단말에서 DNS(Domain Name Service) 레졸루션 방법 및 장치

Publications (2)

Publication Number Publication Date
KR20160039882A KR20160039882A (ko) 2016-04-12
KR102154788B1 true KR102154788B1 (ko) 2020-09-11

Family

ID=55630987

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020140133161A KR102154788B1 (ko) 2014-10-02 2014-10-02 무선 통신 시스템의 단말에서 DNS(Domain Name Service) 레졸루션 방법 및 장치

Country Status (4)

Country Link
US (1) US10448325B2 (ko)
EP (1) EP3203706B1 (ko)
KR (1) KR102154788B1 (ko)
WO (1) WO2016053045A1 (ko)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10142282B2 (en) * 2012-11-05 2018-11-27 Pismo Labs Technology Limited Methods and gateways for processing DNS request
KR101942158B1 (ko) * 2016-11-04 2019-02-19 주식회사 시큐아이 네트워크 보안 방법 및 그 장치
CN109218050B (zh) * 2017-06-30 2021-07-13 贵州白山云科技股份有限公司 一种域名系统故障处理方法和系统
US10666603B2 (en) * 2017-07-13 2020-05-26 T-Mobile Usa, Inc. Optimizing routing of access to network domains via a wireless communication network
CN112565481B (zh) 2018-11-21 2022-04-12 Oppo广东移动通信有限公司 电子设备、域名查询方法及相关产品
CN110674098B (zh) * 2019-09-19 2022-04-22 浪潮电子信息产业股份有限公司 一种分布式文件系统中的域名解析方法

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100765238B1 (ko) 2006-08-24 2007-10-09 엘지전자 주식회사 이동통신단말의 ｄｎｓ 정보 획득방법 및 이를 위한이동통신단말기

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7444371B2 (en) * 2004-03-11 2008-10-28 At&T Intellectual Property Ii, L.P. Method and apparatus for limiting reuse of domain name system response information
CN100502367C (zh) * 2007-04-04 2009-06-17 华为技术有限公司 保存域名系统记录的方法、装置
US7970940B1 (en) * 2009-12-22 2011-06-28 Intel Corporation Domain name system lookup latency reduction
US8671221B2 (en) * 2010-11-17 2014-03-11 Hola Networks Ltd. Method and system for increasing speed of domain name system resolution within a computing device
GB2501416B (en) * 2011-01-07 2018-03-21 Seven Networks Llc System and method for reduction of mobile network traffic used for domain name system (DNS) queries
US8738765B2 (en) * 2011-06-14 2014-05-27 Lookout, Inc. Mobile device DNS optimization
KR20130014226A (ko) * 2011-07-29 2013-02-07 한국전자통신연구원 공격 트래픽 형태별 특성에 따른 ｄｎｓ 플러딩 공격 탐지 방법
US9215283B2 (en) 2011-09-30 2015-12-15 Alcatel Lucent System and method for mobility and multi-homing content retrieval applications
US8874790B2 (en) * 2011-12-30 2014-10-28 Verisign, Inc. DNS package in a partitioned network
KR20140036981A (ko) * 2012-09-16 2014-03-26 엘지전자 주식회사 클라이언트 기기 및 그 통신 수행 방법
US9866448B2 (en) * 2012-09-18 2018-01-09 Htc Corporation Electronic device and method for DNS processing
US9407530B2 (en) * 2012-09-21 2016-08-02 Interdigital Patent Holdings, Inc. Systems and methods for providing DNS server selection using ANDSF in multi-interface hosts
US9407701B2 (en) * 2012-12-14 2016-08-02 Apple Inc. Address family preference in multiple network interface environments
KR101482516B1 (ko) * 2013-03-20 2015-01-16 주식회사에어플러그 무선 통신망에의 추가 접속시의 망 사용을 제어하는 방법과 그 방법을 위한 장치
CN106878161B (zh) * 2013-05-23 2020-05-01 柏思科技有限公司 用于解析域名系统请求的方法和系统
WO2015031356A1 (en) * 2013-08-26 2015-03-05 Seven Networks, Inc. Enhanced caching of domain name system (dns) and reverse dns queries for traffic management for signaling optimization in a mobile network
US10296925B2 (en) * 2014-02-05 2019-05-21 PushSpring, Inc. Automatic profiling of a mobile device and/or its user
US9131032B1 (en) * 2014-03-10 2015-09-08 Cellco Partnership Methods and improvements in UICC polling mechanism for UICC management

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100765238B1 (ko) 2006-08-24 2007-10-09 엘지전자 주식회사 이동통신단말의 ｄｎｓ 정보 획득방법 및 이를 위한이동통신단말기

Also Published As

Publication number Publication date
WO2016053045A1 (ko) 2016-04-07
US10448325B2 (en) 2019-10-15
EP3203706A1 (en) 2017-08-09
US20170280386A1 (en) 2017-09-28
EP3203706B1 (en) 2020-04-15
EP3203706A4 (en) 2017-09-27
KR20160039882A (ko) 2016-04-12

Similar Documents

Publication Publication Date Title
KR102154788B1 (ko) 무선 통신 시스템의 단말에서 DNS(Domain Name Service) 레졸루션 방법 및 장치
US9325785B2 (en) Device, system, and method for client-governed session persistency between one or more clients and servers of a data center
RU2615057C2 (ru) Способ и устройство для доступа к web-странице и маршрутизатор
US9847907B2 (en) Distributed caching cluster management
US10462250B2 (en) Distributed caching cluster client configuration
US10474691B2 (en) Micro-staging device and method for micro-staging
US9549038B1 (en) Cacheable resource location selection
US10165507B2 (en) Network access method and apparatus applied to mobile application
US10812442B1 (en) Intelligent redirector based on resolver transparency
US10735528B1 (en) Geographic relocation of content source in a content delivery network
US20230041645A1 (en) Mobile application accelerator
US20170171301A1 (en) Method, device and system for load balancing configuration
US20170289243A1 (en) Domain name resolution method and electronic device
US20170155712A1 (en) Method and device for updating cache data
CN115801699A (zh) 一种cdn调度方法、设备及系统
US20140156788A1 (en) Persistent Connection between Network Devices
JP6484166B2 (ja) 名前解決装置、名前解決方法及び名前解決プログラム
TWI546688B (zh) 對網路位址進行處理的方法及相關的伺服器與非暫態電腦可讀取儲存媒體
US20220263759A1 (en) Addressing method, addressing system, and addressing apparatus
US11240172B2 (en) Methods and apparatuses for responding to requests for network resources implemented in a cloud computing infrastructure
JP2020194988A (ja) 通信制御方法および通信システム
US20170171349A1 (en) Method, Device and System for Transmitting Data
US11985133B1 (en) Gating access to destinations on a network
KR101565293B1 (ko) Ｈｔｔｐ 프로토콜을 사용한 디바이스 전력 최적화에 의한 디바이스 컨텐츠의 원격 액세스 및 운영
US20170012828A1 (en) Relay apparatus

Legal Events

Date Code Title Description
A201 Request for examination
E701 Decision to grant or registration of patent right