KR20120098894A - Ｈｔｔｐ 최적화, 멀티-호밍, 이동성 및 우선순위 - Google Patents

Ｈｔｔｐ 최적화, 멀티-호밍, 이동성 및 우선순위 Download PDF

Info

Publication number
KR20120098894A
KR20120098894A KR1020127018934A KR20127018934A KR20120098894A KR 20120098894 A KR20120098894 A KR 20120098894A KR 1020127018934 A KR1020127018934 A KR 1020127018934A KR 20127018934 A KR20127018934 A KR 20127018934A KR 20120098894 A KR20120098894 A KR 20120098894A
Authority
KR
South Korea
Prior art keywords
requests
parallel connections
packet data
connections
piped
Prior art date
Application number
KR1020127018934A
Other languages
English (en)
Other versions
KR101450293B1 (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 콸콤 인코포레이티드
Publication of KR20120098894A publication Critical patent/KR20120098894A/ko
Application granted granted Critical
Publication of KR101450293B1 publication Critical patent/KR101450293B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • 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/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/62—Establishing a time schedule for servicing the requests
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/14—Multichannel or multilink protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/08—Load balancing or load distribution
    • H04W28/09—Management thereof
    • H04W28/0958—Management thereof based on metrics or performance parameters
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/10—Flow control between communication endpoints
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/15—Setup of multiple wireless link connections
    • H04W76/16—Involving different core network technologies, e.g. a packet-switched [PS] bearer in combination with a circuit-switched [CS] bearer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/04—Registration at HLR or HSS [Home Subscriber Server]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices
    • H04W88/06—Terminal devices adapted for operation in multiple networks or having at least two operational modes, e.g. multi-mode terminals

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Databases & Information Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Information Transfer Between Computers (AREA)
  • Computer And Data Communications (AREA)

Abstract

병렬 하이퍼텍스트 전송 프로토콜(HTTP) 접속들 및 파이프라이닝을 결합하는 것은, 미처리 요청들의 수가 최소화되고 링크가 완전히 활용되는 상태를 유지하도록, 파이프라이닝된 요청들 및 병렬 접속들의 수를 실시간으로 변화시킴으로써, 증가하는 라운드 트립 시간(RTT)의 영향을 극복한다. HTTP 스택에서 요청들 및 접속들의 선택적 구성 및 스케줄링은 페이지 로드 시간을 개선하고 또한 객체 우선순위들에서의 변경들에 대한 더 큰 응답성을 제공한다. HTTP에 대한 애플리케이션 계층에서의 멀티-호밍 및 이동성이 처리된다. 멀티-호밍은, 특히 인터페이스들이 동일한 정도의 크기인 이용가능한 대역폭의 경우, 다운로드 시간을 개선시키는 다수의 인터페이스들, 예를 들어, WWAN 및 WLAN 인터페이스들의 동시 이용을 제공한다. 이동성은 디바이스가 이동할 때 스위칭 접속들을 제공한다. 이들은 조합되어 더 원활한 이동성을 제공한다. 서버 또는 네트워크 지원djqt이 이러한 방식으로 이동성이 제공될 수 있다.

Description

ＨＴＴＰ 최적화, 멀티-호밍, 이동성 및 우선순위{HTTP OPTIMIZATION, MULTI-HOMING, MOBILITY AND PRIORITY}
본 특허 출원은, 2009년 12월 18일에 출원되고 본 양수인에게 양도되고 본 명세서에 참조로 명백하게 포함되고 발명의 명칭이 "HTTP Optimization, Multi-Homing, Mobility and Priority"인 가출원 제 61/288,119호에 대해 우선권을 주장한다.
본 개시는 일반적으로 통신에 관한 것이고, 더 구체적으로는 무선 통신 네트워크에서 하이퍼텍스트(hypertext) 패킷 데이터 컨텐츠를 리트리브(retrieve)하기 위한 기술들에 관한 것이다.
하이퍼텍스트 전송 프로토콜(HTTP)은 웹 브라우저들 및 웹 애플리케이션들에 의해 이용되는 주요 통신 프로토콜이다. 컨텐츠 전달 네트워크들의 형태로 HTTP 프로토콜의 효율적인 동작을 지원하기 위해, 인터넷 내에서 큰 인프라구조가 성장하고 있다. 그 결과, 증가하는 수의 애플리케이션들이 HTTP 프로토콜로 이동하고 있다. 이러한 이동에 대한 다른 이유들(예를 들어, 네트워크 어드레스 변환(NAT) 및 방화벽 횡단(firewall traversal))이 존재하지만, 이는 메인 드라이버인 웹 인프라구조의 대량의 확장성을 레버리지하는 능력이다.
현재의 웹 사이트들은 각각 HTTP를 이용하여 개별적으로 요청되어야 하는 수십 또는 수백개의 객체들을 포함하여 종종 극도로 복잡하다. 객체들이 서버로부터 클라이언트로 전달될 수 있게 하는 속도를 개선하기 위해 HTTP 내에서 다양한 최적화들이 정의되어 왔다. 유선 네트워크들 내에서는 이 최적화들의 애플리케이션에 대해 상당량의 작업이 행해져 왔지만, 높은 라운드 트립 시간(RTT) 및 매우 가변적인 대역폭을 갖는 더 도전적인 모바일 환경들에서 이 특징들이 어떻게 동작하고 결합하는지를 이해하는 것은 풀리지 않은 문제점으로 남아있다. 특히, 많은 HTTP 작업은, 모바일 네트워크들의 특성들이 현재와는 상당히 다른 수년전에 수행되었음을 유의해야 한다.
하기 설명은 개시된 양상들 중 몇몇 양상들의 기본적 이해를 제공하기 위해 간략화된 요약을 제공한다. 이 요약은 포괄적인 개요는 아니며, 핵심적이거나 중요한 엘리먼트들을 식별하거나, 이러한 양상들의 범위를 기술하고자 하는 의도는 아니다. 그 유일한 목적은 후에 제시되는 더 상세한 설명에 대한 도입부로서 간략화된 형태로 설명된 특징들의 몇몇 개념들을 제시하기 위함이다.
일 양상에서, 패킷 데이터 통신을 위해 다수의 병렬 접속들을 구축하는 단계, 복수의 서버들 상에 각각 저장된 패킷 데이터 부분들로 이루어진 하이퍼텍스트 객체를 리트리브하기 위해, 다수의 병렬 접속들을 통해 복수의 파이프라이닝된(pipelined) 요청들을 송신하는 단계, 및 풀(full) 링크 활용을 유지하면서 미처리(outstanding) 요청들을 감소시키기 위해 병렬 접속들을 통한 파이프라이닝된 요청들 및 상기 병렬 접속들의 수를 동적으로 변화시키는 단계에 의한, 패킷 데이터 송신들을 위한 방법이 제공된다.
다른 양상에서, 패킷 데이터 통신들을 위한 적어도 하나의 프로세서가 제공된다. 제 1 모듈이 패킷 데이터 통신을 위해 다수의 병렬 접속들을 구축한다. 제 2 모듈이, 복수의 서버들 상에 각각 저장된 패킷 데이터 부분들로 이루어진 하이퍼텍스트 객체를 리트리브하기 위해, 다수의 병렬 접속들을 통해 복수의 파이프라이닝된 요청들을 송신한다. 제 3 모듈이, 풀 링크 활용을 유지하면서 미처리 요청들을 감소시키기 위해 병렬 접속들을 통한 파이프라이닝된 요청들 및 상기 병렬 접속들의 수를 동적으로 변화시킨다.
추가적 양상에서, 패킷 데이터 통신들을 위한 컴퓨터 프로그램 물건이 제공된다. 비일시적(non-transitory) 컴퓨터 판독가능 매체가 코드의 세트들을 저장한다. 코드들의 제 1 세트가 컴퓨터로 하여금, 패킷 데이터 통신을 위해 다수의 병렬 접속들을 구축하게 한다. 코드들의 제 2 세트가 컴퓨터로 하여금, 복수의 서버들 상에 각각 저장된 패킷 데이터 부분들로 이루어진 하이퍼텍스트 객체를 리트리브하기 위해, 다수의 병렬 접속들을 통해 복수의 파이프라이닝된 요청들을 송신하게 한다. 코드들의 제 3 세트가 컴퓨터로 하여금, 풀 링크 활용을 유지하면서 미처리 요청들을 감소시키기 위해 병렬 접속들을 통한 파이프라이닝된 요청들 및 상기 병렬 접속들의 수를 동적으로 변화시키게 한다.
추가적 양상에서, 패킷 데이터 통신들을 위한 장치가 제공된다. 장치는 패킷 데이터 통신을 위해 다수의 병렬 접속들을 구축하기 위한 수단을 포함한다. 장치는, 복수의 서버들 상에 각각 저장된 패킷 데이터 부분들로 이루어진 하이퍼텍스트 객체를 리트리브하기 위해, 다수의 병렬 접속들을 통해 복수의 파이프라이닝된 요청들을 송신하기 위한 수단을 포함한다. 장치는, 풀 링크 활용을 유지하면서 미처리 요청들을 감소시키기 위해 병렬 접속들을 통한 파이프라이닝된 요청들 및 상기 병렬 접속들의 수를 동적으로 변화시키기 위한 수단을 포함한다.
또 다른 양상에서, 패킷 데이터 통신을 위한 장치가 제공된다. 트랜시버가 패킷 데이터 통신을 위해 다수의 병렬 접속들을 구축한다. 트랜시버는, 복수의 서버들 상에 각각 저장된 패킷 데이터 부분들로 이루어진 하이퍼텍스트 객체를 리트리브하기 위해, 다수의 병렬 접속들을 통해 복수의 파이프라이닝된 요청들을 추가로 송신한다. 컴퓨팅 플랫폼이, 풀 링크 활용을 유지하면서 미처리 요청들을 감소시키기 위해 병렬 접속들을 통한 파이프라이닝된 요청들 및 상기 병렬 접속들의 수를 동적으로 변화시킨다.
상술한 목적 및 관련된 목적들을 달성하기 위해서, 하나 또는 그 초과의 양상들이, 아래에서 완전히 설명되고 특히 청구항에서 특정되는 특징들을 포함한다. 하기 설명 및 첨부된 도면들은 특정한 예시적인 양상들을 상세히 기술하고, 이 양상들의 원리들이 이용될 수 있는 다양한 방식들 중 오직 일부만을 표시한다. 다른 이점들 및 신규한 특징들은 도면들과 관련하여 고려할 때 하기 상세한 설명으로부터 명백해질 것이고, 개시된 양상들은 모든 이러한 양상들 및 이들의 균등물들을 포함하도록 의도된다.
본 개시의 특징들, 성질 및 이점들은 도면들과 관련하여 볼 때 아래에서 기술되는 상세한 설명으로부터 더 명백해질 것이고, 도면들에서 유사한 참조 부호들은 전체에 걸쳐 대응하는 부분을 식별한다.
도 1은 HTTP 최적화를 위한 통신 시스템의 개략도를 도시한다.
도 2a 및 도 2b는 HTTP 최적화를 위한 방법에 대한 흐름도를 도시한다.
도 3은 페이지 로딩 시간의 도식적 플롯을 라운드 트립 시간(RTT)의 함수로서 도시한다.
도 4는 단일한 지속적 접속에 대한 링크 이용 패턴의 도면을 도시한다.
도 5는 제 1 및 제 2 업링크 요청들 및 다운링크 응답에 대한 링크 이용 패턴의 도면을 도시한다.
도 6은 고정된 대역폭을 갖는 여러 RTT들에 대해 달성되는 최상의 페이지 다운로드 시간에 대한 그래프로된 플롯을 도시한다.
도 7은 HTTP 최적화를 위한 복수의 알고리즘들의 예시적인 관계들에 대한 도면을 도시한다.
도 8은 HTTP 최적화를 수행하는 모바일 단말에 대한 블록도를 도시한다.
도 9는 HTTP 최적화를 지원하는 노드에 대한 블록도를 도시한다.
도 10은 HTTP 최적화를 위한 전기 컴포넌트들의 로직 그룹을 갖는 모바일 디바이스에 적어도 부분적으로 상주하는 시스템에 대한 블록도를 도시한다.
도 11은 HTTP 최적화를 지원하기 위한 전기 컴포넌트들의 로직 그룹을 갖는 네트워크에 상주하는 시스템에 대한 블록도를 도시한다.
증가하는 라운드 트립 시간(RTT)의 영향을 극복하기 위해 병렬 HTTP 접속들 및 파이프라이닝을 결합하는 것에 이점들이 존재한다. 비록 병렬 접속들의 수가, 접촉되어야 하는 별개의 서버들의 세트에 의해 영향을 받을지라도, 일반적으로 알려진 브라우저들은 고정된 수의 병렬 접속들 및 고정된 수의 미처리 요청들을 이용한다.
본 혁신안의 일 양상은, 파이프라이닝된 요청들 및 병렬 접속들의 수를 실시간으로 변화시켜, 미처리 요청들의 수가 최소가 되게 하고 링크가 완전히 활용되게 하는 것이다.
예를 들어, 이 수들은, 요청된 데이터의 양에 기초하여 링크가 완전히 활용되는 것이 유지되는 것을 보장하기 위해 변화될 수 있지만, 아직 수신되지 않은 데이터의 양이 대역폭과 RTT의 곱을 초과해서는 안된다. 이 양들 모두는 계속하여 변한다. 또한, 미처리 데이터의 양은 정확하게 알려지지 않는데, 이것은 객체의 헤더가 도달할 때까지 객체 사이즈들이 알려지지 않기 때문이다.
하나의 가능성은, 이러한 모든 변수들에 대한 확률 모델을 구성하고, 유휴(idle)가 되는 링크의 전체 확률을 어떠한 임계치 아래로 유지하려 시도하는 것이다. 예를 들어, 객체 사이즈들에 대한 확률 모델은, 객체 유형(이미지, HTML, 자바스크립트, CSS 등)을 객체 사이즈에 대한 분포에 맵핑시키는 이력 데이터를 이용할 수 있다. 특히, 객체에 대해 이전에 캐시된 버전이 존재하면, 리턴될 데이터는, 객체가 변하지 않았기 때문에 제로이거나(또는 오히려 단지 HTTP 헤더들이거나), 또는, 구(old) 버전과 유사한 사이즈를 가질 새로운 버전이다.
따라서, 최근에 측정된 대역폭 및 라운드 트립 시간에 기초하여, 요청되었지만 수신되지 않은 데이터의 확률이 대역폭 RTT 곱을 초과할 때까지, 더 많은 객체들이 계속 파이프라이닝될 수 있다. 이 계산은, 대역폭 또는 라운드 트립 시간에서 더 많은 데이터 도달들 또는 변경들이 관측될 때에는 언제나 반복될 수 있다. 따라서, HTTP 접속 상에서 파이프라이닝된 요청들의 타겟 수는, 아래에서 더 상세히 설명되는 바와 같이 접속의 수명 동안 변할 수 있다.
이제, 도면들을 참조하여 다양한 양상들이 설명된다. 하기 기재에서는, 설명을 위해, 하나 또는 그 초과의 양상들의 철저한 이해를 제공하기 위해 다수의 특정한 세부사항들이 기술된다. 그러나, 이 특정한 세부사항들 없이도 다양한 양상들이 실시될 수 있음은 자명할 것이다. 다른 예들에서, 이 양상들의 설명을 용이하게 하기 위해, 주지의 구조들 및 디바이스들은 블록도 형태로 도시된다.
도 1에서는, 통신 시스템(100)에서, 모바일 디바이스, 액세스 단말 또는 사용자 장비(UE)(102)가, 복수의 서버들(112-114) 상에 저장된 객체들(106, 108, 110)을 포함하는 하이퍼텍스트 컨텐츠(104)에 대한 파이프라이닝된 요청들(103)을 행한다. 예시적인 양상에서, 모바일 디바이스(102)는, 객체들(106-110)을 수신하고 따라서 하이퍼텍스트 컨텐츠(104)를 렌더링하는데 요구되는 라운드 트립 시간(RTT)을 악화시키는 에어링크(116)를 통해 액세스를 획득한다. 일 양상에서, 모바일 디바이스(102)는 노드(예를 들어, 매크로셀, 펨토셀, 중계기)(119)와의 통신을 위한 라디오 트랜시버(118)를 가지며, 상기 노드(119)는 코어 네트워크(CN)(예를 들어, 인터넷)(124)에 호스팅되는 서버들(112-114)로의 인터넷 프로토콜 멀티미디어 서브시스템(IMS)(122)에 대한 무선 광역 네트워크(WWAN)(120)의 일부로서 서빙한다.
대안적으로 또는 추가적으로, 모바일 디바이스(102)는, CN(124)을 통해 서버들(112-114)에 액세스하기 위한 무선 로컬 영역 네트워크(WLAN)를 서빙하는 노드(128)와 통신하기 위한 트랜시버(126)를 갖는다.
대안적으로 또는 추가적으로, 모바일 디바이스(102)는, 개인 액세스 네트워크(PAN)(136)를 서빙하고 CN(124)을 통해 서버들(112-114)에 도달하기 위해 140에 도시된 바와 같은 WLAN(130) 또는 138에 도시된 바와 같은 WWAN(120)에 커플링되는 노드(134)와 통신하기 위한 트랜시버(132)를 갖는다.
일 양상에서, 트랜시버(들)(118, 126, 132)는 패킷 데이터 통신을 위한 다수의 병렬 접속들을 구축한다. 트랜시버(들)(118, 126, 132)는, 복수의 서버들 상에 각각 저장된 패킷 데이터 부분들로 이루어진 하이퍼텍스트 객체를 리트리브하기 위해, 다수의 병렬 접속들을 통해 복수의 파이프라이닝된 요청들을 추가로 송신한다.
모바일 디바이스(102)의 컴퓨팅 시스템(124)은, 풀 링크 활용을 유지하면서 미처리 요청들을 감소시키기 위해 병렬 접속들을 통한 파이프라이닝된 요청들 및 상기 병렬 접속들의 수를 동적으로 변화시키는 HTTP 최적화 모듈(144)을 갖는다.
도 2(도 2a 및 도 2b)에서, HTTP 최적화, 멀티-호밍(homing), 이동성 및 우선순위에 대한 예시적인 방법(200) 또는 동작들의 시퀀스가 도시되어 있다. 블록(204)은 패킷 데이터 통신을 위해 다수의 병렬 접속들을 구축하는 단계를 도시한다. 특정한 양상에서, 다수의 병렬 접속들을 구축하는 단계는 복수의 서버들 각각에 대한 접속들의 수를 최소화함으로써 달성된다(블록(206)). 다수의 병렬 접속들은, 늦거나 손실되는 요청된 패킷 데이터에 대한 전체 혼잡 응답을 감소시키기 위해 이용된다(블록(208)).
복수의 서버들 상에 각각 저장된 패킷 데이터 부분들로 이루어진 하이퍼텍스트 객체를 리트리브하기 위해, 다수의 병렬 접속들을 통해 복수의 파이프라이닝된 요청들이 송신된다(블록(210)).
풀 링크 활용을 유지하면서 미처리 요청들을 감소시키기 위해, 병렬 접속들을 통해 추가적인 파이프라이닝된 요청들을 송신하는 동안 상기 병렬 접속들의 수가 동적으로 변화된다(블록(212)). 예를 들어, 풀 링크 활용은 과도한(greedy) 자원 활용 또는 적시(JiT; Just-in-Time) 자원 활용을 수반할 수 있다.
예시적인 양상에서, 이러한 동적 변화는 대역폭 및 라운드 트립 시간을 추정함으로써 달성된다(블록(214)). 요청되었지만 수신되지 않은 패킷 데이터가 존재할 가능성이, 추정된 대역폭과 라운드 트립 시간의 곱을 초과할 때까지, 파이프라이닝된 요청들은 계속 송신된다(블록(216)).
예시적인 양상에서, 특히 HTTP 리트리벌을 용이하게 하는 네트워크에 의해 지원되는 경우, 하나 또는 그 초과의 추가적인 최적화들이 포함된다.
예를 들어, 패킷 데이터 부분들을 렌더링하기 위한 점진적(progressive) 순서화가 결정되고, 그 점진적 순서화와 관련하여 복수의 파이프라이닝된 요청들의 순서가 우선순위화된다(블록(218)). 리트리벌 동안 변경이 발생하면(블록(220)), 점진적 순서화는 재우선순위화되고, 프로세스는 업데이트된다(블록(222)).
다른 예로, 복수의 파이프라이닝된 요청들은 헤더 압축에 의해 요청된다(블록(224)).
추가적인 예로, 네트워크는, 모바일 디바이스에 의해 어떤 추가적 자원들이 요구될 수 있는지를 식별(예측)할 수 있다. 이러한 경우, 요청되지 않았던 서버 식별 자원들이 수신될 수 있다(블록(226)). 필요하지 않으면, 서버 식별 자원들을 취소하는 것으로써 응답하는 것은 오버-디-에어 자원들의 불필요한 소모를 회피하게 할 수 있다(블록(228)).
추가적 예로, 복수의 파이프라이닝된 요청들은 헤더 레인지(range) 특징을 이용하여 복수의 부분적으로 파이프라이닝된 요청들로서 송신될 수 있다(블록(230)).
또 다른 예로, 복수의 파이프라이닝된 요청들은 접속 라운드 로빈에 의해 멀티-호밍된 호스트들에 대한 링크들을 애그리게이트(aggregate)함으로써 송신될 수 있다(블록(232)). 그 다음, 이 멀티-호밍 능력의 관점에서 이동성은, 인터페이스가 이용불가능하게 되거나 이용가능하게 되는 것을 검출하고(블록(234)), 인터페이스를 이용하는 개방 접속들을 식별하고(블록(236)), 개방 접속들 상에서 발행(issue)된 불완전한 파이프라이닝된 요청들의 리스트를 구성하고(블록(238)), 식별된 개방 접속들, 인터페이스, 및 불완전한 파이프라이닝된 요청들의 리스트에 부분적으로 기초하여, 접속 라운드 로빈에 의해 병렬 접속들을 통한 파이프라이닝된 요청들 및 상기 병렬 접속들의 수를 동적으로 변화시킴으로써(블록(240)), 처리될 수 있다.
예시적인 양상에서, 모바일 디바이스는 각각의 인터페이스에 대한 별개의 도메인 명칭 서비스(DNS) 캐시를 유지할 수 있고, 운영 시스템 및 웹 브라우저 지원의 부재시에 네트워크 프록시들, 정적으로 정의된 루트(route)들 및 프록시 자동 구성(PAC) 스크립트들을 이용할 수 있다.
도 3은, nytimes.com에 대해 인에이블된 병렬 접속들 및 파이프라이닝에 의한 Firefox 웹 브라우저를 이용하여, 페이지 로딩 시간(초 단위)에 대한 더 긴 RTT의 효과를 그래프로된 플롯(300)으로 도시한다. 테스트된 페이지는 대략적으로 총 1.3MB의 데이터에 이르는 약 백(100)개의 객체들로 구성된다. 테스트는 고정된 대역폭 1.5MBit/s 링크를 통해 수행되었고, 더 높은 RTT 링크들을 시뮬레이션하기 위해 상이한 양의 추가적 지연들로 반복되었다. 풀 링크 활용에 의해, 페이지를 다운로드하는데 약 칠(7)초가 소요될 것이고, 실제로, 이것은 유선 네트워크들에서 관측될 수 있는 매우 낮은 라운드 트립 시간으로 달성되는 시간이다. 그러나, 명백하게, 링크 활용은, RTT가 증가함에 따라 RTT에 반비례하여 급격하게 감소한다.
이 실험은, RTT가 유선 네트워크들에서 통상적으로 발견되는 것보다 크다면, 최신식 웹 브라우저의 경우에도 중도적(modest) 대역폭의 링크를 완전히 활용하지 못하는 것을 증명한다. 추가적으로, (7s에서 21s로의 페이지 로딩 시간의 200% 증가는 매우 현저하지만, 100ms에서 300ms로의 200% 증가는 현저하지 않을 수 있다는 점에서) 결과적인 증가된 페이지 로딩 시간들은, 사용자 경험이 영향받는 영역 내에 완전히 있게 된다.
본 명세서에서 사용되는 링크 활용은, 네트워크가 제공하도록 준비된 자원들 모두를 활용할 수 있는 클라이언트의 능력을 지칭한다. EV-DO 또는 HSPA 시나리오에서, 하나의 사용자가 이러한 관점에서 링크를 "불충분하게 활용"하는 경우, 미사용된 용량은 다른 사용자들에게 제공되어, 전체적으로 무선 자원들의 불충분한 활용은 존재하지 않는다. 그럼에도 불구하고, 본 발명의 관점에서 열악한 링크 활용은 더 긴 페이지 로딩 시간들에서 관측되는 바와 같이 열악한 사용자 경험을 초래한다.
구체적인 예로, 열(10)명의 사용자들 각각이 1MB 파일을 요청하고(반드시 모두 동시일 필요는 없음), 네트워크가 8MBit/s의 공유된 용량을 갖는다면, 모든 사용자들에게 데이터를 전달하는데 10s가 소요될 것이다. 평균 대기 시간의 관점에서, 모든 사용자들에게 "병렬"로 전달하여 각각의 사용자에게 10s만큼 오래 소요되는 것보다 데이터를 "순차적으로" 서빙하여 각각의 사용자에게 1s가 소요되는 것이 더 양호하다.
객체 전달을 최적화하기 위해, HTTP에서 이용가능한 다양한 기술들이 이용될 수 있다.
지속적 접속들: 각각의 HTTP 요청에 대해 새로운 전송 제어 프로토콜(TCP) 접속이 구축되기 위해 요구되는 HTTP 1.0 규격. 각각의 TCP 접속 구축은 TCP 혼잡 제어의 슬로우 스타트 상태(phase)에 기인한 느린 송신 기간 및 SYN/ACK(동기화/확인응답) 교환을 의미하기 때문에, 이 요건은 객체 전달 시간의 관점에서 큰 비용을 요구한다.
HTTP1.1은, 다수의 요청들이 동일한 서버로 발행되는 경우를 더 양호하게 지원하기 위해 지속적 접속들을 도입하였다. 이 경우, 이전 응답의 수신이 완료된 후 새로운 HTTP 요청을 동일한 접속을 통해 전송함으로써 TCP 접속이 재사용된다. 이 접근방식에서, 요청의 전송과 응답의 제 1 패킷의 수신 사이의 시간(1 라운드 트립 시간) 동안 다운링크는 유휴이다.
단일한 지속적 접속에 대한 링크 이용 패턴(400)을 도 4로부터 볼 수 있고, 도 4에서, 업링크 요청들(402)과 다운링크 응답들(404) 사이의 갭들은 링크의 불충분한 활용을 (갭들의 형태로) 표시하고, RTT가 더 높으면 이러한 불충분한 활용이 더 악화된다는 사실을 표시한다.
RTT를 처리하지 않고 단순히 링크 대역폭을 증가시키는 본 개시의 이점은 링크 활용의 관점에서 그 자체로 성능을 개선하지는 않음을 인식해야 한다. 도 4를 더 참조하여, 대역폭을 증가시키는 것은 각각의 업링크 및 다운링크 블록을 시간의 함수로서 더 협소하게 할 것이지만(즉, 동일한 데이터가 더 짧은 시간에 전송됨) 갭들의 사이즈를 감소시키지는 않을 것이다. 실제로 갭들은 총 다운로드 시간의 더 큰 분율(fraction)을 표현할 것이어서, 이 경우 대역폭을 증가시키는 것은 링크 활용을 감소시킨다.
병렬 접속들: 현대의 브라우저들은 다수의 TCP 접속들을 동일하거나 상이한 서버들(또는 둘 모두)에 병렬로 개방한다. 이 기술의 효과는 두가지이다: 첫째로, 다수의 활성으로 송신되는 TCP 접속들의 애그리게이트의 혼잡 제어 동작은 단일 TCP 접속과 동등한 것으로 간주될 수 있지만 슬로우 스타트 동안 혼잡 윈도우의 훨씬 더 빠른 개방 및 각각의 패킷 드롭에 대한 훨씬 더 감소된 혼잡 응답을 갖는다. 둘째로, (지속적 접속들에 대해 전술된 바와 같이) 하나의 접속을 통한 송신이 간헐적인 경우, 송신들 사이의 유휴 기간들이 다른 접속들에 의해 이용되어, 링크 활용을 개선시킬 수 있다.
파이프라이닝: HTTP1.1은 실제로 제 1 요청에 대한 응답의 완료를 대기하지 않고 다수의 요청들이 전송되도록 허용한다. 이것은, 응답들 사이에서 링크가 유휴가 되는 것 없이, 서버가 응답들을 연속적으로(back-to-back) 전송하게 한다. HTTP가 요청들과 응답들을 매칭시키기 위한 다른 메커니즘을 제공하지 않기 때문에, 응답들은 요청들이 수신되었던 것과 동일한 순서로 전송되어야 한다.
파이프라이닝의 효과는, 제 1 및 제 2 업링크 요청들(502, 503) 및 다운링크 응답들(504)을 갖는 지속적 접속에 대한 링크 이용 패턴(500)에 대해 도 5에 도시되어 있다.
현대의 웹 브라우저들 모두는 상기 처음 2개의 기술들을 상당히 이용한다. 그러나, 파이프라이닝의 지원은 HTTP1.1 규격에 규정되어 있지만 어느 정도 동안에는 서버들 및 프록시들에서 통상적이 아니었고, 특히 투명한 프록시들의 경우에 고유의 실패 모드들의 몇몇 증거가 존재한다. 그 결과, 파이프라이닝의 구현 시에 어느 정도의 주의가 요구되au, 예를 들어, 실패 모드들을 검출하고 넌-파이프라이닝 동작에 완곡하게(gracefully) 대비하도록 주의하고, 이 기술이 성공적이었던 서버들의 화이트 리스트들을 유지하는 것이 요구된다. Opera 브라우저는 디폴트로 인에이블되는 파이프라이닝을 갖는다 (그리고 이러한 기술들을 명백하게 구현한다). Firefox에서는 파이프라이닝이 지원되지만 디폴트로 디스에이블된다. Safari 및 Chrome은 (현재는) 파이프라이닝을 지원하지 않는다.
브라우저들에서 파이프라이닝에 대한 폭넓은 지원이 존재하지 않는 이유는 도 3 및 전술된 문제점들로부터 명백하고: 링크의 브라우저 활용은 지속적 및 병렬적 접속들의 단독 이용을 통한 낮은 RTT 접속들에 대해 매우 높다. 컨텐츠 전달 네트워크들은 최근 몇년에 통상적인 웹 RTT들을 적극적으로 낮추어, 개선된 브라우징 수행을 유도하고(이것은 CDN들의 주요한 가치 명제임), 그 결과 대부분의 유선 및 무선 로컬 액세스 네트워크(WLAN) 웹 브라우징의 경우 인지되는 문제점이 거의 없다.
파이프라이닝이 지원되는 경우, 응답들 사이에 어떠한 갭도 없어야 할 것이기 때문에, 링크 활용은 단일 접속에 의해 100%일 것이 예상될 것이다. 그러나, 몇몇 경우들에서, 서버들은 요청들을 파이프라이닝된 형태로 허용할 수 있지만, 이전의 요청들이 완료될 때까지는 각각의 요청을 프로세싱하지 못할 수 있다. 이것은, 서버 프로세싱에 소요되는 시간과 동일한, 응답들 사이의 갭을 초래한다. 서버가 심하게 로딩되고, 응답을 생성하기 위한 스크립트 실행과 같은 복잡한 기능들을 수행해야 하고, 그리고/또는 외부 서버들(예를 들어, 데이터베이스들)을 참조해야 하는 경우, 이 시간은 상당할 수 있다.
입력 측에서는 파이프라이닝된 요청들을 허용하지만 출력 측에서는 직렬 요청들을 발행하는 중간적 프록시들이 존재하면, 동일한 효과가 관측될 수 있다. 서버들이 파이프라이닝된 요청들을 병렬로 프로세싱하는 경우에도, 주어진 응답을 전송해야 하는 시간에 도달했을 때 이러한 프로세싱의 결과들이 이용가능하지 않을 수 있다.
초기 실험들: 상기 데이터는, 무선 광역 네트워크(WWAN)와 같은 높은 RTT 링크들 상에서 웹 브라우징 성능의 개선을 위한 범주가 존재할 것임을 믿게 한다. 클라이언트와 중간적 프록시 사이에 파이프라이닝을 적용하고, 응답들을 순서없이(즉, 클라이언트와 프록시에 의해 지원되는 새로운 HTTP 확장을 통해) 리턴할 가능성을 추가적으로 도입하는 것으로부터 추가적 증거가 얻어진다. 이 접근방식에서, 클라이언트와 프록시 사이의 낮은 RTT는 단일 TCP 접속이 WWAN 링크를 완전히 활용하도록 허용하고 프록시는 출력 측에서 병렬 요청들을 발행하도록 설계되기 때문에 링크 활용이 개선된다. 요구된 자원들의 조기 식별이 또한 통합될 수 있다.
순서없는 응답들에 대한 HTTP 확장은, 타겟 HTTP 서버들에 의해 직접 지원되는 경우(그리고, 그 서버들이 요청들을 병렬로 프로세싱한다고 가정하면) 이점들을 제공할 수 있음을 유의해야 한다. 실험들은, Google SPDY에 대해 후술되는 범위까지를 제외하고는 이 접근방식을 추구하지 않았다고 믿어진다.
본 혁신안의 발전을 위해 수행되는 실험들은, 어떠한 프록시 전개도 요구되지 않는 경우(즉, 클라이언트 측 전용 기술들)를 처리한다. 명확화를 위해, 초기에는, 네트워킹을 제외한 모든 병목현상들이 제거된 "이상적 브라우저"에 촛점을 둔다. 구체적으로, "이상적 브라우저"는:
페이지를 렌더링하기 위해 요구되는 요청들의 완전한 세트에 대한 선험적(a priori) 지식을 갖고; 그리고
수신되는 대로 컨텐츠를 즉시 렌더링한다.
따라서, 페이지 로딩 시간에 대한 유일한 기여는 HTTP 프로토콜을 이용하여 네트워크를 통해 데이터를 전송하는데 요구되는 시간이다. "이상적 브라우저"는, (실제 웹 페이지 다운로드의 트레이스로부터 얻어진) 객체들의 리스트를 미리 공급받고, HTTP 지속적 접속들, 병렬 접속들 및 객체들을 다운로드하기 위한 파이프라이닝을 이용하는 알고리즘을 구현하는 Python 스크립트로서 구현된다. 모든 객체들을 다운로드하는데 소요되는 시간이 측정된다.
병렬 접속들, 파이프라이닝 및 네트워크 대역폭 및 RTT 사이의 상호작용을 더 잘 이해하기 위해, 한개(1)와 열개(10)의 병렬 접속들 사이 및 각각에 대해 한개(1)와 열개(10)의 미처리 요청들 사이에서 실험들이 수행되었다. (한개(1)의 미처리 요청은 표준 넌-파이프라이닝 접근방식에 대응하고, 'n'개의 미처리 요청들은, 초기에 'n'개의 요청들이 전송되고 응답이 완전히 수신될 때마다 새로운 요청이 후속적으로 전송됨을 의미한다).
상이한 네트워크 대역폭들 및 RTT들에 대한 결과들을 표 1-6에 나타낸다. 더 상세하게는, 실제 웹 서버 트레이스들 상에서 다수의 접속들 및 파이프라이닝의 상이한 구성들의 성능이 이상화된다. Wireshark를 이용하여 대중적 웹 사이트들로부터 웹 요청 트레이스가 수집된다. 다음으로, 요청 트레이스 파일을 생성하기 위해 덤프 파일이 프로세싱된다. 초기 실험들의 경우, 모든 요청들은 기지의(known) 업프론트(upfront)이고 순서대로 실행되는 것으로 가정된다. 객체들은 주요 서버, 즉, 해당 웹사이트를 포함하는 객체들의 불균형한 공유를 갖는 서버로부터 요청만 된다. 주요 서버 현상은 또한 대중적인 웹사이트들에 대한 특징이 된다.
하기 표 1은 다수의 접속들 및 파이프라이닝의 각각의 구성에 대해 관측되는 평균 다운로드 시간을 나타낸다.
Figure pct00001
하기 표 2-7은 다수의 접속들 및 파이프라이닝의 각각의 구성에 대해 관측되는 평균 다운로드 시간을 나타낸다.
Figure pct00002
Figure pct00003
Figure pct00004
Figure pct00005
Figure pct00006
이 실험들에서, 실험을 수행하는 동안 배경에서 임의의 것들이 다운로드된다.
Figure pct00007
요약의 방식으로, 도 6은, 1.5MBit/s의 고정된 대역폭을 갖는 상이한 RTT들에 대해, 그리고 또한 3G 접속 및 배경 트래픽을 갖는 3G 접속(둘 모두는 1.5MBit/s보다 더 높은 대역폭을 가짐)을 통해 달성된 최상의 페이지 다운로드 시간을 제시한다. 각각의 경우에 대한 주석들은, 최상의 결과가 달성된 병렬 접속들의 수 및 파이프라이닝의 양을 제공한다.
명확화를 위해, 이러한 실험들은 단일 서버 상에 상주하는 페이지 객체들의 90%로 제한되었지만, 본 혁신안의 양상들은 다수의 서버 결과들로 확장될 수 있음을 유의한다.
도 6으로부터의 본 개시의 이점에 의해, 원칙적으로 다운로드 시간은 도 3에서와 같이 RTT에 민감한 만큼 거의 민감할 필요가 없음을 인식해야 한다.
HTTP 최적화, 멀티-호밍, 이동성 및 우선순위:
본 혁신안은, HTTP 스택에서 요청들 및 접속들의 최적의 구성 및 스케줄링에 대한 문제를 처리하여, 예를 들어, 부분적으로 다운로드된 이미지를 더 이상 볼 수 없도록 웹 페이지가 스크롤될 때, 페이지 로드 시간을 개선하고 또한 객체 우선순위들에서의 변경들에 대한 더 큰 응답성을 제공한다.
본 발명은 또한 HTTP에 대한 애플리케이션 계층에서의 멀티-호밍 및 이동성에 대한 솔루션들을 고려한다. 멀티-호밍은, 특히 인터페이스들이 동일한 정도의 크기인 이용가능한 대역폭의 경우(이것은 흔한 경우이며, 이는 WLAN이 백홀-제한적이기 때문임), 다운로드 시간을 개선시키는 다수의 인터페이스들, 예를 들어, WWAN 및 WLAN 인터페이스들의 동시 이용을 제공한다. 이동성은, 디바이스가 이동할 때 접속들의 스위칭을 제공한다. 이들은 조합되어 더 원활한 이동성을 제공한다. 서버 또는 네트워크 지원을 각각 요구하는 다중-경로 전송 제어 프로토콜(MPTCP) 또는 MobileIP와 같은 전송 또는 네트워크 계층 솔루션들에 반해, 이러한 방식으로 서버 또는 네트워크 지원없이 이동성이 제공될 수 있다.
우선순위에서의 변경들에 대한 응답성을 개선하고 멀티-호밍 및 이동성 지원을 개선하기 위해, 멀티-호밍 및 이동성의 지원 뿐만 아니라 다수의 부분적 요청들의 이용을 위해 본 명세서에 설명되는 기술들은 신규한 것으로 믿어진다. 각각의 인터페이스에 대한 별개의 도메인 명칭 서비스(DNS) 캐시를 유지하는 기술은 또한 신규한 것으로 믿어진다.
마지막으로, 본 발명자들은 네트워크 프록시들, 정적으로 정의된 루트들 및 프록시 자동 구성(PAC) 스크립들의 이용을 통해, 운영 시스템 및 웹 브라우저 지원의 부재시에 본 명세서에 설명되는 기술들의 일부를 구현하기 위한 신규한 기술을 설명한다.
일반적 문제들은 다음과 같이 설명될 수 있다:
URL(Uniform Resource Locator)들의 세트의 형태로 요구되는 자원들의 세트에 의한 애플리케이션(예를 들어, 웹 브라우저)에 의해 HTTP 스택이 제공된다. 이들은 한번에 또는 일정 기간의 시간에 걸쳐 제공될 수 있다. HTTP 스택은, 이 자원들에 대한 요청들을 언제 어떻게 발행할지에 대한 관점에서 행할 몇몇 판정들을 갖는다. 구체적으로:
동일한 서버에서 다수의 자원들이 이용가능하면, 이 요청들은 단일 TCP 접속 상으로 파이프라이닝될 수 있다.
이것이 행해지면, 요청들의 순서가 판정될 필요가 있다.
파이프라이닝에 대한 지원은 범용적이거나 지속적이 아니고, 따라서, 미처리 요청들의 수를 제한하거나 파이프라이닝을 위한 다소의 서버 지원을 검출하는 것이 바람직할 수 있다.
서버는 순서없는 응답들에 대한 QC HTTP 확장들을 지원할 수 있고, 이 경우, 요청들의 순서화 및 미처리 요청들의 수에 대한 상이한 기준이 존재한다.
임의의 시간에 개방되어야 하는 병렬 TCP 접속들의 수에 대한 제한(bound)이 존재할 수 있고, 이것은, 상이한 서버들로의 접속들의 구축을 위한 순서를 선택할 필요가 있게 한다.
따라서, 기본적 문제는, 링크 활용이 최대가 되도록, TCP 접속들 및 이 접속들에 대한 HTTP 요청들 모두를 스케줄링하는 것이다. 이것을 문제 1이라 한다.
이 문제는 본 명세서에서, 특정한 서버들에서 이용가능한 자원들의 관점에서 설명됨을 유의한다. 이 서버들은 컨텐츠를 호스팅하는 원래의 웹 서버(원래의 서버) 또는 클라이언트와 원래의 서버 사이의 경로 상의 (투명하지 않은) 프록시 서버일 수 있다. 프록시 서버는 (CDN 프록시들의 경우) 특정한 자원 또는 자원들에 대해 특정될 수 있거나, (구성되거나 학습된 로컬 프록시의 경우) 임의의 자원에 대해 적용가능할 수 있다. 본 명세서에서 설명되는 문제들 및 알고리즘들은, 자원들을 리트리브하기 위해 클라이언트가 액세스하는 "서버"의 종류에 대해 독립적이고; 본 발명자들은 임의의 종류의 서버 상에 임의의 선택적인 서버 능력이 존재할 수 있다고 가정한다.
이 문제에 대한 다수의 강화들이 다음과 같이 구현될 수 있다:
요구되는 자원들에 대한 몇몇 종류의 우선순위 순서화가 존재하는 것이 통상적이다. 예를 들어, 웹 서버의 경우, 이미지들, 광고들 및 비디오들 이전에, 그리고 트래커들 또는 다른 보조 기능들을 발동시키기 전에, 레이아웃, 스타일, 스크립트 및 텍스트 자원들을 수신하는 것이 일반적으로 바람직하다. 이것은, 모든 자원들이 다운로드되기 전에 페이지 렌더링이 시작하는 것을 허용한다. 따라서, 자원들에 대한 우선순위 순서화에 대한 추가적 정보 및 그 순서로 또는 그 순서에 근접하게 자원들을 전달하는 추가적 목적을 문제 1에 더한 것이 강화된 문제이다. 이것을 문제 2라 한다.
다른 가능성은, 모든 자원들이 완전히 수신되기 전에 자원들의 우선순위 순서화가 변할 수 있다는 것이다(또한, 다운로드 프로세스 동안, 요구되는 리스트에 새로운 자원들이 추가될 수 있는 가능성을 포함하는 문제 1을 기억한다). 예를 들어, 이것은, 웹 페이지가 완전히 다운로드되기 전에 사용자가 웹 페이지를 스크롤하여, 가시적인 것들을 우선순위화하기 위해 자원들의 순서화가 변하는 경우 발생할 수 있다. 이 경우 추가적인 목적은, 이 변화 또는 우선순위를 준수(respect)하는 것, 및 변화 이후 이용가능한 자원들이 최고 우선순위 자원들에 전용되게 유지되도록 보장하는 것이다. 이것을 문제 3이라 한다.
다른 경우는, 클라이언트가 다수의 인터페이스들로의 액세스를 갖고 따라서 자원들을 호스팅하는 서버들로 다수의 경로들을 갖는 경우이다. 여기서, CDN들의 통상적 동작에 기인한 인터페이스에 의해 도메인 명칭들의 DNS 해상도(resolution)가 변할 수 있음 ?기존의 시스템들에서 지원되지 않는 것으로 믿어지는 것?을 고려하는 것이 중요할 것이다. 이 경우, 다수의 인터페이스들 전부에 대해 이용가능한 대역폭을 이용하는 추가적 목적에 의해 문제가 강화된다. 이것을 문제 4라 한다.
마지막으로, 이용가능한 인터페이스들의 세트가 변할 수 있는 것이 가능하다. 이 경우, 최소의 데이터 손실로 그리고 이용가능한 대역폭은 최고 우선순위 자원들에 전용되어야 하는 원리를 유지하면서, 효율적으로 변화가 처리되도록 요구된다. 이것을 문제 5라 한다.
요약하면, 문제 1은 URL들의 세트에 대한 요청 스케줄링 및 파이프라이닝의 최적의 이용과 관련된다. 그 목적은 대역폭 이용을 최적화하여, 페이지 다운로드 시간을 감소시키는 것이다.
문제 2는 URL들에 대한 우선순위 순서화 및 그 우선순위를 준수하기 위한 목적을 추가한다. 그 목적은 웹 페이지들의 점진적 렌더링을 가능하게 하여, 인지되는 페이지 다운로드 속도를 개선시키는 것이다.
문제 3은 우선순위들이 변경될 수 있도록 허용하는 것이다. 그 목적은, 대역폭이 높은 우선순위 객체들에 대해 빠르게 재할당되게 하여 사용자의 관심(focus)의 변경들(링크들의 클릭, 탭의 변경, 스크롤링 등)에 대한 응답성을 개선시키는 것이다.
문제 4는, 다수의 인터페이스들의 효율적 이용을 고려하여, 멀티-호밍 호스트에 대한 링크 애그리게이션(aggregation)을 통해 페이지 다운로드 시간을 개선시키는 것을 목적으로 한다.
문제 5는 이용가능한 인터페이스들에서의 변경들을 고려하여 이동성을 지원하는 것을 목적으로 한다.
HTTP 프로토콜에 기반한 이 문제점들에 대한 솔루션은 여기서는 전송 계층 대신에 HTTP 애플리케이션 계층에 촛점을 둔다.
기존의 솔루션들: 기존의 웹 브라우저들은 문제 1 및 어느 정도까지는 문제 2를 해결하려 시도한다. 그러나, 현재의 구현들은 몇몇 결점들을 갖는다. 첫째로, 요구되는 자원들(URL들)은 페이지가 다운로드됨에 따라 점진적으로 식별되며, 이것은, 클라이언트가 이미 알고 있는 장래에 요구되는 자원들에 대한 정보를 고려하지 않고 접속들을 개방 및 폐쇄하는 것에 대한 판정들이 행해짐을 의미한다.
둘째로, 기존의 브라우저들은 통상적으로 병렬 접속들의 수에 대한 임의적 제한을 갖는다. 다수의 병렬 접속들이 이점을 제공하는 것으로 예상되지 않는다. 통상적인 경험칙(rule-of-thumb)에 따르면, 여섯(6)개보다 많은 병렬 접속들에서 감소하는 리턴들이 존재하는 것으로 보인다. 그럼에도 불구하고, 종종 WWAN 네트워크들은 큰 네트워크측 다운링크 버퍼들을 갖도록 구성됨을 유의해야 한다. 이것은, 링크가 완전히 활용되고 있는 경우 높은 RTT들에 기여할 수 있다. 따라서, 다른 접속이 이미 링크를 활용하고 있으면, 병렬 접속들에 대한 TCP 슬로우 스타트는 매우 느릴 수 있다.
세째로, 기존의 브라우저들은 파이프라이닝을 항상 잘 이용하지는 않는다. 이것은, 파이프라이닝이 HTTP 프록시들에서 지속적으로 지원되지는 않기 때문이다. 또한, 프록시에 의한 파이프라이닝의 이용은, 전송될 다음 객체가 프록시에서 아직 이용가능하지 않기 때문에 TCP 접속이 유휴가 되는 "차단" 문제를 초래할 수 있다. 동일한 접속 상에서 요청되는 다른 객체가 프록시에서 이용가능하면, "순서없는 응답"으로서 그 객체를 대신 전송하는 것이 바람직할 것이다.
Google에서 최근 발표된 SPDY 프로젝트(http://dev.chromium.org/spdy)는 TCP와 HTTP 사이에 얇은 멀티플렉싱 계층을 삽입함으로써 문제 1 및 문제 2를 해결하는 것을 목적으로 한다. 이것은, 다수의 HTTP 트랜잭션(transaction)들이 단일 TCP 접속을 통해 할당된 우선순위들과 병렬로 발생하는 것을 허용한다. 저자들은 문제 3을 장래의 작업으로 식별한다. SPDY 프로젝트는 또한 HTTP 헤더 압축을 중요한 컴포넌트로 식별한다. WWAN이 구체적으로 언급되지 않지만, HTTP 요청 압축은 WWAN 네트워크들에 대해 특히 가치있을 수 있다.
본 개시는, 표준 HTTP 1.1에 기초하여 문제들 1-5를 점진적으로 처리하려는 예시적인 접근방식들을 분석한다. 또한, 성능을 추가로 개선할 수 있는 몇몇 최소의 선택적인 서버 향상들이 설명된다.
문제 1: 기본적 접속 및 요청 스케줄링: 이 섹션의 기본적 개념은 자원들의 식별, TCP 접속들의 구축 및 실제 요청들의 개별적 스케줄링을 취급하는 것이다. 첫째로, 요구되는 자원들이 식별되고, 따라서, 접촉이 요구되는 서버들의 완전한 세트가 알려지는 것으로 가정한다. 둘째로, 반드시 한번에 모두 접속되거나 반드시 서버당 하나의 접속이 구축되는 것은 아니지만, 이 서버들로 TCP 접속들이 구축된다. 세째로, 구축된 접속들에 요청들이 맵핑된다.
접속들의 개방을 결정해야 하는 2개의 원리들이 존재한다.
첫째로, 각각의 서버로의 접속들의 수를 최소화하고, 결과적으로 파이프라이닝을 이용한다. 이것은, 새로운 접속이 구축될 때마다 높은 가격이 지불되기 때문이다 (SYN/ACK 및 슬로우 스타트). 이것은, 다른 활성 접속들이 큰 큐잉(queuing) 지연 및 그에 따른 큰 RTT가 존재하는 것을 의미하는 경우 특히 사실이다.
둘째로, 패킷이 손실되거나 늦은 경우, 전체 혼잡 응답을 감소시키기 위해 다수의 병렬 접속들을 이용한다. 'n'개의 TCP 접속들이 존재하면, 단일 손실에 대한 응답은 결합된 혼잡 윈도우를 1/2n만큼 감소시키는 것이다.
이 두가지 목적들은, 명백하게 충돌하여, 이들의 트레이드-오프를 제어하는 파라미터들이 도입된다: Pmax를 병렬 TCP 접속들의 최대수라 하고, Pmin을 병렬 TCP 접속들의 최소수에 대한 타겟이라 한다. 그 목적은, Pmin에 따르는, 서버당 하나(1)의 접속을 구축하는 것이다.
n개의 URL들의 세트 U, U={U0, ..., Un-1}가 주어지면, 그로부터 m개의 고유한 서버들의 세트 S, S={S0, ..., Sm-1}가 식별될 수 있고, 여기서, m≤n이다. 기존의 웹 서버들에 대해 즉시 유용한 향상은, 페이지에 대해 가능한 한 많은 요구되는 URL들을 가능한 한 빨리 식별하는 것일 수 있음을 유의한다. 현재 이 프로세스는, 이것이 불필요한 렌더링 프로세스 및 다운로드와 인터트와인드된다(interwined).
서버들 Sj는 전체 주소 도메인 명칭(FQDN; Fully Qualified Domain Name)보다는 IP 어드레스에 의해 식별되는데, 이것은 다수의 FQDN들이 동일한 IP 어드레스에 맵핑될 수 있기 때문이다. (다수의 어드레스들로의 단일 FQDN 맵핑의 가능성이 이하 상세히 설명된다.) s(i)를 URL Ui에 대해 요구되는 서버의 인덱스라 하고(즉, Ui는 SS(i)로부터 획득될 수 있음), U(j)를 서버 Sj로부터 획득될 수 있는 URL들의 세트라 한다.
접속들을 구축하고 접속들에 요청들을 할당하기 위한 프로세스가 제공된다. 이 프로세스에서, 요청 기회는 새로운 요청을 발행하는 기회이다. 이것이 어떻게 정의되는지는, 요청/접속 매칭들에 앞선 커미팅(committing)과 접속들을 유휴가 되게 하는 것 사이의 트레이드오프이며, 이것은, 새로운 요청이 발행되기 전에 모든 요청들이 완료되기 때문이다. 몇몇 예들이 아래에 주어진다.
알고리즘 1:
1) k = 0 내지 m-1에 대해, uk := U(k) 라 함
2) (개방 접속들의 수) < Pmax이면
a. (Si로의 개방 접속이 존재하지 않고 ui ≠Ø 이도록 ∃ i)이면
i. Si로의 새로운 접속을 개방함
b. 그렇지 않고 (ui ≠Ø 이도록 ∃ i)이면
i. (개방 접속들의 수) < Pmin이면
1. Si로의 새로운 접속을 개방함.
c. 그렇지 않으면 STOP
3) 폐쇄하기 위해 접속 또는 요청 기회를 대기함
4) 요청 기회가 존재하면
a. C를 요청 기회를 갖는 접속이라 하고, i를, C가 접속하는 서버 Si의 인덱스라 함
b. ui ≠Ø 이면
i. 현재 발행된 요청들이 완료된 후 C를 폐쇄로 스케줄링함
c. 그렇지 않으면
i. 엘리먼트 u ∈ ui 를 선택함
ii. C 상에서 u에 대한 요청을 발행함
iii. ui : = ui-{u}라 함
5) (2)로 진행
이 프로세스의 동작은 요청 기회가 어떻게 정의되는지에 의존한다. 2가지 극단들이 다음과 같이 정의된다.
과도한 요청 기회: 이것은 서버로의 접속이 개방인 경우에는 항상 발생한다.
태만한(lazy) 요청 기회: 이것은, 접속 상에서 응답이 완전히 수신되는 경우에는 항상 발생한다.
과도한 요청 기회들의 경우, 모든 요청들은, 접속들의 최대수 Pmax에 종속하여, 즉시 발행된다. 요청들은 또한 Pmin을 준수하기 위해 다수의 접속들을 통해 동일한 서버로 분산될 수 있다. 그러나, 모든 요청들이 일단 발행되면, 변경할 기회가 없다. 하나의 접속 상에서의 요청들이 다른 접속 상에서의 요청들보다 완료하는데 훨씬 더 소요되기 때문에, Pmin개보다 적은 접속들이 존재하는 것이 발생할 수 있다.
태만한 요청 기회들의 경우, 프로세스에 걸쳐 Pmin이 준수된다. 그러나, 각각의 접속은 하나의 응답의 종료와 다음 응답의 시작 사이의 시간 동안 유휴로 남게되고, 이것은 하나의 라운드 트립 시간 플러스 서버 응답 시간으로 측정된다. 이것은, 파이프라이닝을 지원하지 않는 HTTP1.1 클라이언트들에 대한 표준 동작이다.
이상적으로, 요청 기회들에 대한 정의는 2개의 극단들 사이 어딘가에 존재할 것이다. 예를 들어, 요청 기회는, 응답을 수신할 나머지 시간이 하나의 라운드 트립 시간 플러스 서버 프로세싱 시간으로 추정될 때 발생할 수 있다. 그러나, 서버 프로세싱 시간은 미지이고, RTT만이 추정되고, 게다가 이 시간은 이전 응답에 대한 총 수신 시간보다 길 수 있다. 하기 설명에서, "적시"(JiT) 요청 기회들은, 가능한 한 늦지만 링크가 유휴가 되는 것은 회피하게 하는 충분한 시간에 요청이 발행되는 최적화 버전을 의미한다.
파이프라이닝의 서버 지원: 프록시 서버들은 파이프라이닝에 대한 지속적 지원을 제공하는 않는 것으로 알려져 있다. HTTP1.1 서버들(프록시들을 포함함)은 파이프라이닝된 요청들을 프로세싱하거나 무시하도록(즉, 실패하지 않도록) 요구받는다. 따라서, 하나보다 많은 요청이 발행된 경우, 서버가 파이프라이닝을 지원하는지 여부를 (제 2 응답이 후속하는지 여부에 의해) 결정하는 것은, 제 1 응답이 완전히 수신된 이후에 가능할 것이다. 서버가 파이프라이닝을 지원하지 않는 경우, 그 서버로부터 요청되었던 URL들은 제 1 URL을 제외하고는 그 서버에 대한 ui 세트로 리턴되어야 하고, 파이프라이닝 지원의 부재(absence)가 표시된다. 그 서버로의 후속 접속들은 최대 하나의 요청을 수신해야 한다.
순서없는 응답들: 표준 서버들은 파이프라이닝된 요청들의 응답들을 그 요청들이 수신되었던 순서대로 리턴한다. 서버들이 요청들을 다른 순서로 리턴하는 것을 허용하는 HTTP 확장이 정의된다. 이것은, 특히 프록시 서버의 경우 객체들이 이들이 요청된 것과는 다른 순서로 서버에서 이용가능해질 수 있기 때문에, 가치가 있다. 따라서, 순서대로의 객체 전달은 HOL(head-of-line) 차단 문제를 초래할 수 있다. 그럼에도 불구하고, 이 특징을 이용하기 위해, 다수의 요청들이 접속으로 파이프라이닝될 필요가 있다, 즉, 더 많은 요청들이 큐잉되면, HOL 차단의 기회는 감소되지만, 더 큰 커미트먼트(commitment)가 행해지고: 그 결과, 이 특징이 존재하는 경우에는 존재하지 않는 경우보다 접속 상에 더 많은 요청들을 발행하는 것이 바람직할 수 있다.
순서없는 확장은 요청들에 부가되는 "TransactionID" 헤더로 이루어진다. 순서없는 응답들은 대응하는 요청의 TransactionID 값을 반향(echo)한다. 응답에서 TransactionID 필드의 부재는, 서버가 순서없는 응답들을 지원하지 않음을 표시한다.
HTTP 헤더 압축: HTTP는 엔티티 바디(body)들의 gzip 압축은 지원하지만 요청들의 압축은 지원하지 않는다. Google SPDY 프로젝트는 HTTP 헤더 압축을 현저한 이점을 제공하는 것으로 식별하고, WWAN 네트워크들의 경우 요청 압축이 특히 유용할 것으로 예상될 수 있다.
헤더 압축은 하기와 같이 역호환가능한 HTTP 확장으로 쉽게 정의될 수 있다:
헤더 압축을 지원하는 클라이언트들은 제 1 요청에서, 기존의 Content-Encoding 헤더와 유사한 새로운 선택적 헤더로 이를 표시한다(예를 들어, Header-Encoding: gzip).
헤더 압축을 지원하는 서버들은 이 새로운 헤더를 인식하고, 압축된 헤더들에 의한 응답들을 리턴한다.
헤더 압축의 시작은, 새로운 요청 또는 응답이 예상되는 스트림에서 나타나는 표준 gzip 헤더에 의해 표시될 수 있다.
접속 상에서 요청들 또는 응답들의 시퀀스는 하나의 연속적 스트림으로 압축되어야 한다. 미압축 스트림이 요청들 또는 응답들의 연접(concatenation)으로부터 형성된다(각각의 종료하는 뉴라인(terminating newline)을 포함함). 각각의 요청 또는 응답의 종료에서 플러시(flush) 포인트가 존재해야 하고, 따라서, 이것은 후속 정보의 수신없이 완전히 디코딩될 수 있다.
압축이 시작되기 전에 전송된 미압축 요청들 또는 응답들은 압축에 대한 정적 딕셔너리(dictionary)로 이용되어야 한다.
서버 식별된 자원들: Google SPDY는, 그 자원이 요구될 것이라고 서버가 인식하는 인스턴스들에서, 클라이언트가 요청하지 않은 자원들을 서버가 그 클라이언트에 리턴할 가능성을 인식한다. 또한, 클라이언트가 요청하기를 원할 수 있는 자원들의 제안들을 서버가 제공할 가능성이 존재한다.
전자의 옵션은 클라이언트가 요청을 취소할 능력을 요구하는 한편, 후자의 옵션은 그러한 능력에 대한 요구없이 동일한 목적 대부분을 달성한다.
제안된 접근방식의 단순한 구현은, 순서없는 응답들이 지원되는 경우, 특수한 트랜잭션 ID 및 요청 URL을 갖는, 서버-식별된 자원에 대한 응답 헤더를 서버가 전송하는 것이다. 이것은, 캐시-관련 정보(Date, ETags, 캐시-제어 디렉티브들)가 포함되도록 허용하여, 클라이언트가 자신의 캐시를 참조하고 객체를 요청할지 여부를 결정할 수 있게 한다.
요청들의 취소: 전술된 순서없는 확장이 지원되면, 트랜잭션 ID를 갖는 요청을 참조함으로써 요청을 취소하는 새로운 방법이 손쉽게(trivally) 추가될 수 있다. 이것은, 파이프라인에서 더 많은 요청들이 큐잉 업되도록 허용하는데 유용할 수 있는 (따라서, HOL 차단의 기회를 감소시키는) 한편, 필요하다면 이 커미트먼트를 여전히 반전시킬 수 있다.
문제 2: 요청 우선순위화: 문제 2는 URL들의 세트 U가 우선순위 순서를 갖는 추가된 가능성을 도입한다. 일반화의 손실없이, 리스트 U0, ..., Un-1은 최고 우선순위가 최초가 되는 우선순위 순서인 것으로 가정한다. 또한, 더 낮은 우선순위의 객체들 이전에 더 높은 우선순위 객체들이 전달되는 목적이 추가된다.
이 새로운 목적은 이용가능한 대역폭 이용을 최대화하는 원래의 목적에 대해 부수적임을 유의한다: 즉, 대역폭 이용을 최대화하기 위해 필요하다면 객체들을 우선순위 순서없이 전달하는 것이 허용가능하다 (그렇지 않으면, 엄격한 우선순위 순서로 요청들을 발행하고, 각각의 요청 이후 다른 요청을 발행하기 전에 그 요청이 완료되기를 대기함으로써, 이 요건이 충족될 것이다.)
우선순위화를 지원하기 위해 알고리즘 1은 하기와 같이 변형된다:
알고리즘 2
1) U에 대한 순서화는, 서버들을 그 서버 상에서 이용가능한 최고 우선순위 자원의 순서로 배치함으로써 S에 대한 순서화를 유도한다. 그 다음, 각각의 세트 ui가 또한 자명한 방식으로 순서화된다.
2) 알고리즘 1에 후속하여, 단계 2 (a), 2 (b) 및 4 (c) (i)를 제외하고는, 선택된 i의 값이 적어도 그러한 값일 것이다.
문제 3: 우선순위에서의 변경들: Google SPDY 프로토콜은, TCP와 HTTP 사이에 얇은 멀티플렉싱 계층을 제공하고, 이를 이용하여 다수의 요청들/응답 트랜잭션들을 동일한 접속으로 멀티플렉싱함으로써, 이 요건을 처리하는 것을 목적으로 한다. 기존의 기술들과의 차이는 다음과 같이 보여질 수 있다:
파이프라이닝은 다수의 요청/응답 트랜잭션들이 TCP 접속을 공유하는 것을 허용하지만, 응답들이 순차적으로 및 순서대로 리턴되도록 요구한다.
순서없는 응답(One-shot-web)에 의한 파이프라이닝은 응답들이 다른 순서로 리턴되는 것을 허용하지만, 응답들은 여전히 순차적이다(각각의 응답은 다음 응답이 시작하기 전에 완료되어야 한다).
병렬 TCP 접속들은 응답들이 병렬로 (IP 계층에서 멀티플렉싱되어) 전송되는 것을 허용하지만, 트랜잭션들은 독립적으로 진행하여: 서로에 대한 우선순위를 조정할 방법은 없다.
따라서, SPDY 프로토콜은 응답의 순차적 완료에 대한 요건 없이 파이프라이닝의 이점들을 획득하는 것을 목적으로 한다.
먼저, 알고리즘 2에서, 태만한 또는 적시의 요청 기회들이 이용되면, 각각의 ui 세트 내에서 요청되지 않은 자원들의 우선순위를 임의의 시간에 재순서화하는 것이 항상 가능함을 유의해야 한다. 이러한 단순한 접근방식은 상당한 이점들을 제공할 수 있다 (이것을 알고리즘 2a라 함).
이제, HTTP 부분적 요청들(즉, Range 헤더들을 갖는 HTTP 요청들)의 이용에 기초하여 더 정교한 입도로 우선순위 변경들을 처리하는 대안적 방식을 설명한다.
첫째로, R을 바이트 단위의 최대 요청 사이즈라 한다. 사이즈 R 또는 그 미만인 피스(piece)의 요구된 자원들에 대한 요청들이 발행된다. 알고리즘 2에서, 각각의 URL, ui는 쌍(URL, Byte Range)에 의해 대체된다. 이 쌍들은 Byte Range [0, R-1] 및 애플리케이션에 의해 제공되는 URL들로 초기화된다.
그 다음, 하기 절차가를 추가하는 것이 추가되어 알고리즘 3을 형성한다:
URL에 대한 제 1 응답 헤더의 수신 시에, 객체 사이즈 F를 획득한다. 그 다음, F>R이면, Byte Range들 [R, 2R-1], [2R, 3R-1], …, [rR, F-1] 및 동일한 URL을 갖는 ui 내의 r := ceil( F / R ) - 1 개의 추가적 엔트리들을 구성한다. ui 내의 엔트리들의 순서는 전술된 바와 같은 URL들의 우선순위 순서화에 기초해야 함을 유의한다.
이 방식에서, 우선순위 변경이 발생하는 경우, 접속 상에서 요청되었으며 수신되지는 않은 미처리 데이터의 양은 R개 이하이고, 따라서, 더 낮은 순위 자원들에 대해 자원들이 전용되는 기간은 감소된다.
적시(JiT) 요청 기회들을 효율적으로 지원하기 위해, R은, 하나의 라운드 트립 시간에서 송신될 수 있는 데이터의 양보다 커야 할 것이다. R은 측정된 라운드 트립 시간들 및 데이터 레이트들에 따라 변해야 할 것이다.
문제 4: 멀티-호밍에 대한 지원: 멀티-호밍된 호스트는, 다수의 접속된 인터페이스들을 갖고 따라서 인터넷으로의 다수의 루트들을 갖는 호스트이다. 멀티-호밍된 호스트의 경우의 목적은, 다수의 인터페이스들을 동시에 이용하여 다운로드 속도를 개선하는 것이다.
첫째로, HTTP 스택이, 이용가능한 인터페이스들에 대한 지식 및 TCP 접속으로 하여금 특정 인터페이스를 이용하도록 지시할 능력을 갖는다고 가정한다. 이것은 기존의 호스트 운영 시스템(OS) 구현들에서의 경우가 아니고, 따라서 이를 달성하기 위해 몇몇 작업이 요구된다. 이러한 OS 개선들에 앞서, 가능한 대안은, 별개의 인터페이스들을 통해 도달가능한 HTTP 프록시 서버들을 제공하고, 각각의 서버에 대한 패킷들을 상이한 인터페이스를 통해 지향시키는 이 서버들에 대한 명시적 루트들을 클라이언트 라우팅 테이블 내에 정의하는 것이다. 이 방식으로, 프록시 서버를 선택하는 것은 이용될 인터페이스를 결정하게 하고, 그 인터페이스와 연관된 프록시로 접속들을 지향시킴으로써 접속들이 인터페이스로 지향될 수 있다.
프록시 서버의 선택은, 주어진 URL에 대해 이용될 프록시를 결정하는 자바스크립트 함수를 사용자가 특정하도록 허용하는 프록시 자동구성 스크립트들의 이용을 통해 기존의 웹 브라우저 구현들에서 제어될 수 있다. 이 접근방식은, 요청들이 인터페이스들에 걸쳐 정적으로 분산되는 것, 예를 들어, 특정 백분율의 요청들이 하나의 인터페이스에 분산되고 나머지가 다른 인터페이스에 분산되는 것을 허용한다.
요청들의 1/N을 proxy_a에 지향시키고 나머지를 proxy_b에 지향시키는 적절한 스크립트를 아래에 나타낸다.
var N = 2;
function FindProxyForURL(url, host)
{
var i = url.length % N;
if (i == 0)
return "PROXY proxy_a:8080; "
else if (i == 1)
return "PROXY proxy_b:8080; "
}
이 스크립트에서 URL의 길이는 해시(hash) 함수로서 이용된다. 대안적 해시 함수들이 또한 이용될 수 있다.
TCP 접속들을 특정한 인터페이스들로 지향시키는 OS-기반 능력이 주어지면, 본 명세서에서는 알고리즘 4로 지칭되는 단순한 멀티-호밍 접근방식은 알고리즘 2에 후속하는 것으로, TCP 접속들을 이용가능한 인터페이스들에 걸쳐 라운드-로빈 방식으로 분산시키는 것이다.
알고리즘 5를 획득하기 위해 알고리즘 3에 동일한 향상이 행해질 수 있다. 알고리즘 4와 비교하면, 객체에 대한 부분적 요청들이 접속들에 걸쳐 분산될 것이기 때문에 큰 객체가 다수의 인터페이스들에 걸쳐 분할될 수 있는 것이 장점이다.
이 경우들에서 Pmin을 적어도 인터페이스들의 수로 설정하는 것이 바람직하다.
멀티-호밍 및 DNS: CDN들의 정규의 동작에 기인하여, DNS 해상도의 결과는, 호스트의 인터넷으로의 접속점(point of attachment) 및 요청이 먼저 전송되는 DNS 서버에 의존하여 상이할 수 있다. 기존의 호스트 OS들은 이에 대해 본 발명의 지식을 고려하지 않는다.
HTTP 및 CDN들의 특정한 경우에서, 상이한 해상도 결과들에 대한 이유는 CDN이 접속점에 "근접한" 적절한 프록시를 식별한다는 점이다. 각각의 인터페이스에 대해 정확한 프록시를 이용하는 것이 매우 바람직하다.
문제 5: 이동성: 문제 4(멀티-호밍)에 대한 솔루션이 주어지면, 이동성에 대한 지원이 감소되어, 전송 동안 인터페이스가 셧다운되는 경우들 및 새로운 인터페이스가 이용가능하게 되는 경우를 처리하는 문제를 축소시킨다.
알고리즘 4는 하기와 같이 이동성을 지원하는 알고리즘 6을 획득하도록 향상된다:
인터페이스가 중지된(go down) 경우, 그 인터페이스를 이용하는 개방 접속들을 식별하고 그 접속들 상에서 발행된 불완전한 요청들의 리스트를 구성한다. 그 자원들을 적절한 ui 세트들에 다시 추가하고 프로세스를 계속한다.
인터페이스가 발생하는(come up) 경우, 접속이 구축되어야 하는 그 다음 시간의 선택을 위해 이 인터페이스를 이용가능하게 한다.
둘 모두의 경우들에서, Pmin이 인터페이스들의 수에 기초하여 설정되면, Pmin을 변형하는 것을 고려한다.
하기와 같이 알고리즘 7을 획득하기 위해 알고리즘 5에 대해 유사한 향상들이 행해질 수 있다.
인터페이스가 중지된 경우, 그 인터페이스를 이용하는 개방 접속들을 식별하고 그 접속들 상에서 발행된 불완전한 요청들의 리스트를 구성한다. 그 요청들을 적절한 ui 세트들에 다시 추가하고 프로세스를 계속한다. 진행중인 바이트 범위 [a, b]에 대한 임의의 요청들에 대해, 수신된 최종 바이트 c를 식별하고, 바이트 범위 [c+1, b]에 대한 요청을 적절한 ui 세트에 추가한다.
인터페이스가 발생하는 경우, 접속이 구축되어야 하는 그 다음 시간의 선택을 위해 이 인터페이스를 이용가능하게 한다.
둘 모두의 경우들에서, Pmin이 인터페이스들의 수에 기초하여 설정되면, Pmin을 변형하는 것을 고려한다.
도 7은 전술된 일곱(7)개의 알고리즘들의 예시적인 관계를 도시하는 도면(700)이다. 본 개시의 이점에 의해, 자원 식별(702), 접속 구축(704) 및 요청 스케줄링(706)의 분리에 대한 기본적 개념들이 알고리즘 1(708)의 시작으로부터 적용되고, 알고리즘 1(708)은 과도한 또는 JIT 요청 동작들(710)을 활용할 수 있음을 인식해야 한다. 알고리즘 1(708)은, 이용가능한 어떠한 선택적 서버 능력들(예를 들어, 파이프라이닝(712), 순서없는 응답들(714), 헤더 압축(716), 서버 식별된 자원들(718) 및 HTTP 취소 능력(720))도 최상으로 이용할 수 있게 하지만, 이들 모두가 이용가능한 것이 아니면 여전히 개선들을 제공한다.
알고리즘 2(722)는 과도한 또는 JiT 요청 동작들(726)에 부가하여 간단한 요청 우선순위화(724)를 추가한다. 알고리즘 2(722)에 기초한 알고리즘 2a(728)에서, 적시 요청 기회들(732)에 이용하기 위해 재-우선순위화(730)가 제공된다. 알고리즘 2A(728)에 기초할 수 있는 알고리즘 4(734)는 라운드-로빈 기반으로 접속들을 인터페이스들에 할당함으로써 멀티-호밍(736)을 제공한다. 알고리즘 4(734)에 기초하는 알고리즘 6(738)은, 라운드-로빈 기반으로 인터페이스들에 접속들을 할당함으로써 이 간단한 모델로도 지원될 수 있는 이동성(740)을 제공한다.
알고리즘 3(742)은 요청 재-우선순위화(746) 및 JiT 요청 동작들(748)에 의한 부분적 요청들(744)을 이용하여 더 정교한 입도의 재-우선순위화를 제공한다. 이 접근방식은 또한, 알고리즘 5(750)에서 멀티-호밍(752)으로 확장될 때 및 알고리즘 7(754)에서 이동성(756)으로 확장될 때 이점들을 제공한다.
도 8은, 본 명세서에서 설명되는 기능의 다양한 양상들을 구현하는데 이용될 수 있는 다른 시스템(800)의 블록도이다. 일례에서, 시스템(800)은 모바일 단말(802)을 포함한다. 도시된 바와 같이, 모바일 단말(802)은 하나 또는 그 초과의 기지국들(804)로부터 신호(들)를 수신할 수 있고, 하나 또는 그 초과의 안테나들(808)을 통해 하나 또는 그 초과의 기지국들(804)에 송신할 수 있다. 또한, 모바일 단말(802)은 안테나(들)(808)로부터 정보를 수신하는 수신기(810)를 포함할 수 있다. 일례에서, 수신기(810)는 수신된 정보를 복조하는 복조기(812)와 동작가능하게 연관될 수 있다. 그 다음, 복조된 심볼들은 프로세서(814)에 의해 분석될 수 있다. 프로세서(814)는, 모바일 단말(802)과 관련된 데이터 및/또는 프로그램 코드들을 저장할 수 있는 메모리(816)에 커플링될 수 있다. 또한, 모바일 단말(802)은 본 명세서에 설명된 방법들을 수행하기 위해 프로세서(814)를 이용할 수 있다. 모바일 단말(802)은 또한 안테나(들)(808)를 통한 송신기(820)에 의한 송신을 위해 신호를 멀티플렉싱할 수 있는 변조기(818)를 포함할 수 있다.
모바일 단말(802)은, 복수의 서버들 상에 각각 저장된 패킷 데이터 부분들로 이루어진 하이퍼텍스트 객체를 리트리브하기 위해, 다수의 병렬 접속들을 통해 복수의 파이프라이닝된 요청들을 기지국들(804)에 추가로 송신한다. 메모리(816) 내에서 프로세서(814)에 의해 실행되는 HTTP 최적화 컴포넌트(822)는 병렬 접속들을 통해 파이프라이닝된 요청들 및 상기 병렬 접속들의 수를 동적으로 변화시켜, 풀 링크 활용을 유지하면서 미처리 요청들을 감소시킨다.
도 9는, 본 명세서에서 설명되는 기능의 다양한 양상들을 구현하는데 이용될 수 있는 시스템(900)의 블록도이다. 일례에서, 시스템(900)은 기지국 또는 노드 B(902)를 포함한다. 도시된 바와 같이, 노드 B(902)는 하나 또는 그 초과의 수신(Rx) 안테나들(906)을 통해 하나 또는 그 초과의 UE들(904)로부터 신호(들)를 수신할 수 있고, 하나 또는 그 초과의 송신(Tx) 안테나들(908)을 통해 하나 또는 그 초과의 UE들(904)에 송신할 수 있다. 또한, 노드 B(902)는 수신 안테나(들)(906)로부터 정보를 수신하는 수신기(910)를 포함할 수 있다. 일례에서, 수신기(910)는 수신된 정보를 복조하는 복조기(912)와 동작가능하게 연관될 수 있다. 그 다음, 복조된 심볼들은 프로세서(914)에 의해 분석될 수 있다. 프로세서(914)는, 코드 클러스터들, 액세스 단말 할당들, 그와 관련된 룩업 테이블들, 고유 스크램블링 시퀀스들과 관련된 정보 및/또는 다른 적절한 유형들의 정보를 저장할 수 있는 메모리(916)에 커플링될 수 있다. 일례에서, 노드 B(902)는 또한, 송신 안테나(들)(908)를 통한 송신기(920)에 의한 송신을 위해 신호를 멀티플렉싱할 수 있는 변조기(918)를 포함할 수 있다.
메모리(916) 내에서 프로세서(914)에 의해 실행되는 HTTP 최적화 지원 컴포넌트(922)는 UE(904)에 의해 요청될 수 있는 능력들(예를 들어, 파이프라이닝, 순서없는 응답들, 헤더 압축, 서버 식별된 자원들 및 HTTP 취소 능력)을 제공하여 HTTP 통신들을 최적화시킨다.
도 10을 참조하면, 패킷 데이터 통신들을 위한 시스템(1000)이 도시되어 있다. 예를 들어, 시스템(1000)은 적어도 부분적으로 사용자 장비(UE) 내에 상주할 수 있다. 시스템(1000)은 기능 블록들을 포함하는 것으로 도시되어 있고, 이 기능 블록들은 컴퓨팅 플랫폼, 프로세서, 소프트웨어 또는 이들의 조합(예를 들어, 펌웨어)에 의해 구현되는 기능들을 표현하는 기능 블록들일 수 있음이 인식될 것이다. 시스템(1000)은 함께 동작할 수 있는 전기 컴포넌트들의 로직 그룹(1002)을 포함한다. 예를 들어, 로직 그룹(1002)은 패킷 데이터 통신을 위해 다수의 병렬 접속들을 구축하기 위한 전기 컴포넌트(1004)를 포함할 수 있다. 또한, 로직 그룹(1002)은, 복수의 서버들 상에 각각 저장된 패킷 데이터 부분들로 이루어진 하이퍼텍스트 객체를 리트리브하기 위해, 다수의 병렬 접속들을 통해 복수의 파이프라이닝된 요청들을 송신하기 위한 전기 컴포넌트(1006)를 포함할 수 있다. 또한, 로직 그룹(1002)은 풀 링크 활용을 유지하면서 미처리 요청들을 감소시키기 위해 병렬 접속들을 통한 파이프라이닝된 요청들 및 상기 병렬 접속들의 수를 동적으로 변화시키기 위한 전기 컴포넌트(1008)를 포함할 수 있다. 또한, 시스템(1000)은 전기 컴포넌트들(1004-1008)과 연관된 기능들을 실행하기 위한 명령들을 보유하는 메모리(1020)를 포함할 수 있다. 메모리(1020)의 외부에 있는 것으로 도시되어 있지만, 전기 컴포넌트들(1004-1008) 중 하나 또는 그 초과는 메모리(1020) 내에 존재할 수 있음을 이해할 것이다.
도 11에는 패킷 데이터 통신을 위한 장치(1102)가 도시되어 있다. 장치(1102)는 패킷 데이터 통신을 위해 다수의 병렬 접속들을 구축하기 위한 수단(1104)을 포함한다. 장치(1102)는 복수의 서버들 상에 각각 저장된 패킷 데이터 부분들로 이루어진 하이퍼텍스트 객체를 리트리브하기 위해, 다수의 병렬 접속들을 통해 복수의 파이프라이닝된 요청들을 송신하기 위한 수단(1106)을 포함한다. 장치(1102)는 풀 링크 활용을 유지하면서 미처리 요청들을 감소시키기 위해 병렬 접속들을 통한 파이프라이닝된 요청들 및 상기 병렬 접속들의 수를 동적으로 변화시키기 위한 수단(1108)을 포함한다.
당업자들은, 본 명세서에 개시된 양상들과 관련하여 설명된 다양한 예시적인 로직 블록들, 모듈들, 회로들 및 알고리즘 단계들이 전자 하드웨어, 컴퓨터 소프트웨어 또는 이 둘의 조합으로 구현될 수 있음을 추가로 인식할 것이다. 하드웨어 및 소프트웨어의 이러한 상호 호환성을 명확히 예시하기 위해, 다양한 예시적인 컴포넌트들, 블록들, 모듈들, 회로들 및 단계들이 일반적으로 그들의 기능적 관점에서 앞서 기술되었다. 이러한 기능이 하드웨어로 구현되는지 또는 소프트웨어로 구현되는지 여부는 특정 애플리케이션 및 전체 시스템에 대해 부과된 설계 제한들에 의존한다. 당업자들은 설명된 기능을 각각의 특정 애플리케이션에 대해 다양한 방식들로 구현할 수 있지만, 이러한 구현 결정들이 본 개시의 범위를 벗어나는 것을 야기하는 것으로 해석되어서는 안 된다.
본 출원에서 사용되는 바와 같이, 용어들 "컴포넌트", "모듈", "시스템" 등은, 하드웨어, 하드웨어 및 소프트웨어의 조합, 소프트웨어, 또는 실행중인 소프트웨어와 같은 컴퓨터-관련 엔티티를 지칭하도록 의도된다. 예를 들어, 컴포넌트는 프로세서 상에서 실행되는 프로세스, 프로세서, 객체, 실행가능한 것, 실행 스레드, 프로그램, 및/또는 컴퓨터일 수 있지만, 이들로 제한되는 것은 아니다. 예시로서, 서버 상에서 실행되는 애플리케이션 및 서버 모두가 컴포넌트일 수 있다. 하나 또는 그 초과의 컴포넌트들은 프로세스 및/또는 실행 스레드 내에 상주할 수 있고, 일 컴포넌트는 하나의 컴퓨터 내에 로컬화될 수 있고, 그리고/또는 2개 또는 그 초과의 컴퓨터들 사이에 분산될 수 있다.
본 명세서에서 용어 "예시적인"은 예, 예시, 또는 예증으로서 기능하는 것을 의미하는 것으로 사용된다. "예시적인" 것으로서 본 명세서에서 설명되는 임의의 양상 또는 설계는 다른 양상들 또는 설계들에 비하여 반드시 바람직하거나 유리한 것으로서 해석할 필요는 없다.
다수의 컴포넌트들, 모듈들 등을 포함할 수 있는 시스템들의 관점에서 다양한 양상들이 제시될 것이다. 다양한 시스템들은 추가적 컴포넌트들, 모듈들 등을 포함할 수 있고, 그리고/또는 도면들과 관련하여 설명되는 모든 컴포넌트들, 모듈들 등을 포함하지는 않을 수 있음을 이해하고 인식할 것이다. 이 접근방식들의 조합이 또한 이용될 수 있다. 본 명세서에서 설명되는 다양한 양상들은, 터치 스크린 디스플레이 기술들 및/또는 마우스-및-키보드 유형의 인터페이스들을 활용하는 디바이스들을 포함하는 전기 디바이스들 상에서 수행될 수 있다. 이러한 디바이스들의 예들은, 컴퓨터들(데스크탑 및 모바일), 스마트폰들, 개인 휴대 정보 단말들(PDAs), 및 유선 및 무선 모두의 다른 전자 디바이스들을 포함한다.
또한, 본 명세서에서 개시되는 양상들과 관련하여 설명된 다양한 예시적인 로직 블록들, 모듈들 및 회로들은 범용 프로세서, 디지털 신호 프로세서(DSP), 주문형 집적회로(ASIC), 필드 프로그래머블 게이트 어레이(FPGA) 또는 다른 프로그래머블 로직 디바이스, 이산 게이트 또는 트랜지스터 로직, 이산 하드웨어 컴포넌트들, 또는 본 명세서에서 설명된 기능들을 수행하도록 설계된 것들의 임의의 조합에 의해 구현 또는 수행될 수 있다. 범용 프로세서는 마이크로프로세서일 수 있지만, 대안적으로, 프로세서는 임의의 종래의 프로세서, 제어기, 마이크로제어기 또는 상태 머신일 수 있다. 또한, 프로세서는 컴퓨팅 디바이스들의 조합, 예를 들어 DSP 및 마이크로프로세서의 조합, 복수의 마이크로프로세서들, DSP 코어와 결합된 하나 또는 그 초과의 마이크로프로세서들, 또는 임의의 다른 이러한 구성으로서 구현될 수 있다.
또한, 하나 또는 그 초과의 버전들은, 개시된 양상들을 구현하도록 컴퓨터를 제어하기 위해 소프트웨어, 펌웨어, 하드웨어 또는 이들의 임의의 조합을 생성하는 표준 프로그래밍 및/또는 엔지니어링 기술들을 이용하는 방법, 장치 또는 제조 물품으로서 구현될 수 있다. 본 명세서에서 사용되는 용어 "제조 물품"(또는 대안적으로, "컴퓨터 프로그램 물건")은 임의의 컴퓨터 판독가능 디바이스, 캐리어 또는 매체(media)로부터 액세스 가능한 컴퓨터 프로그램을 포함하도록 의도된다. 예를 들어, 컴퓨터 판독가능 매체는 자기 저장 디바이스들(예를 들어, 하드 디스크, 플로피 디스크, 자기 스트립들, 등), 광학 디스크들(예를 들어, 컴팩트 디스크(CD), 디지털 다기능 디스크(DVD), 등), 스마트 카드들, 및 플래쉬 메모리 디바이스들(예를 들어, 카드, 스틱)을 포함하지만, 이들로 제한되는 것은 아니다. 또한, 전자 메일을 송신 및 수신하거나 인터넷 또는 로컬 영역 네트워크(LAN)와 같은 네트워크에 액세스하는데 이용되는 것들과 같은 컴퓨터 판독가능 전자 데이터를 반송하기 위해 반송파가 활용될 수 있음을 인식해야 한다. 물론, 이 분야의 당업자들은, 개시된 양상들의 범주를 벗어남이 없이 이 구성에 대한 다수의 변형들이 행해질 수 있음을 인식할 것이다.
본 명세서에 개시된 양상들과 관련하여 설명되는 방법 또는 알고리즘의 단계들은 직접적으로 하드웨어, 프로세서에 의해 실행되는 소프트웨어 모듈, 또는 이 둘의 조합으로 구현될 수 있다. 소프트웨어 모듈은 RAM 메모리, 플래쉬 메모리, ROM 메모리, EPROM 메모리, EEPROM 메모리, 레지스터들, 하드디스크, 착탈식 디스크, CD-ROM, 또는 이 분야에 공지된 임의의 다른 형태의 저장 매체에 상주할 수 있다. 예시적인 저장 매체는, 프로세서가 저장 매체로부터 정보를 판독하고, 저장 매체에 정보를 기록할 수 있도록 프로세서에 커플링될 수 있다. 대안적으로, 저장 매체는 프로세서에 통합될 수 있다. 프로세서 및 저장 매체는 ASIC에 상주할 수도 있다. ASIC는 사용자 단말에 상주할 수 있다. 대안적으로, 프로세서 및 저장 매체는 사용자 단말에서 이산 컴포넌트들로서 상주할 수 있다.
개시된 양상들의 상기 설명은 이 분야의 당업자가 본 개시를 이용하거나 또는 실시할 수 있도록 제공된다. 이 양상들에 대한 다양한 변형들은 이 분야의 당업자들에게 쉽게 명백할 것이며, 본 명세서에 정의된 일반적인 원리들은 본 개시의 사상 또는 범주를 벗어남이 없이 다른 실시예들에 적용될 수 있다. 따라서, 본 개시는 본 명세서에 도시된 실시예들에 한정되는 것으로 의도되지 않고, 본 명세서에 개시된 원리들 및 신규한 특징들과 부합하는 가장 넓은 범위에 따른다.
위에서 설명된 예시적인 시스템들의 관점에서, 개시된 요지에 따라 구현될 수 있는 방법들이 몇몇 흐름도들을 참조하여 설명되었다. 설명의 단순화를 위해, 방법들은 일련의 블록도들로 도시 및 설명되지만, 몇몇 블록들은 상이한 순서들로 그리고/또는 본 명세서에서 도시되고 설명되는 것과는 다른 블록들과 동시에 발생할 수 있기 때문에, 청구되는 요지는 블록들의 순서에 의해 제한되지 않음을 이해하고 인식할 것이다. 또한, 본 명세서에서 설명되는 방법들을 구현하기 위해, 도시된 모든 블록들이 요구되지는 않을 수 있다. 또한, 본 명세서에 개시된 방법들은, 이러한 방법들을 컴퓨터들로 전달 및 전송하는 것을 용이하게 하기 위해 제조 물품 상에 저장될 수 있음을 추가로 인식해야 한다. 본 명세서에서 사용되는 바와 같은 용어 제조 물품은 임의의 컴퓨터 판독가능 디바이스, 캐리어 또는 매체로부터 액세스될 수 있는 컴퓨터 프로그램을 포함하도록 의도된다.
본 명세서에 참조로 통합된 것으로 언급된 임의의 특허, 공보 또는 다른 개시 자료는, 전체적으로 또는 부분적으로, 그 통합된 자료가 기존의 정의들, 또는 본 개시에 기술된 다른 개시 자료와 충돌하지 않는 범위에서만 본 명세서에 통합됨을 인식해야 한다. 따라서, 필요한 범위까지, 본 명세서에 명시적으로 기술된 개시는 본 명세서에 참조로 통합된 임의의 충돌하는 자료를 대체한다. 본 명세서에 참조로 통합된 것으로 언급되지만, 본 명세서에 기술된 기존의 정의들, 진술들, 또는 다른 개시 자료와 충돌하는 임의의 자료 또는 그 일부는, 그 통합된 자료와 기존의 개시 자료 사이에 충돌이 발생하지 않는 범위에서만 통합될 것이다.

Claims (29)

  1. 패킷 데이터 통신들을 위한 방법으로서,
    패킷 데이터 통신을 위해 다수의 병렬 접속들을 구축하는 단계;
    복수의 서버들 상에 각각 저장된 패킷 데이터 부분들로 이루어진 하이퍼텍스트 객체를 리트리브하기 위해, 상기 다수의 병렬 접속들을 통해 복수의 파이프라이닝된(pipelined) 요청들을 송신하는 단계; 및
    풀(full) 링크 활용을 유지하면서 미처리(outstanding) 요청들을 감소시키기 위해 상기 병렬 접속들을 통한 파이프라이닝된 요청들 및 상기 병렬 접속들의 수를 동적으로 변화시키는 단계를 포함하는,
    패킷 데이터 통신들을 위한 방법.
  2. 제 1 항에 있어서,
    상기 복수의 파이프라이닝된 요청들을 송신하는 단계는 무선 광역 네트워크의 노드에 액세스하는 단계를 더 포함하는, 패킷 데이터 통신들을 위한 방법.
  3. 제 1 항에 있어서,
    상기 파이프라이닝된 요청들 및 상기 병렬 접속들의 수를 동적으로 변화시키는 단계는,
    대역폭 및 라운드 트립 시간을 추정하는 단계; 및
    요청되었지만 수신되지 않은 패킷 데이터가 존재할 가능성이 상기 추정된 대역폭과 라운드 트립 시간의 곱을 초과할 때까지, 파이프라이닝된 요청들의 송신을 계속하는 단계를 더 포함하는, 패킷 데이터 통신들을 위한 방법.
  4. 제 1 항에 있어서,
    상기 패킷 데이터 통신을 위해 다수의 병렬 접속들을 구축하는 단계는,
    상기 복수의 서버들 각각에 대한 접속들의 수를 최소화하는 단계;
    늦거나 손실되는 요청된 패킷 데이터에 대한 전체 혼잡 응답을 감소시키기 위해, 상기 다수의 병렬 접속들을 이용하는 단계; 및
    상기 접속들의 수를 최소화시키려는 목적과 상기 전체 혼잡을 감소시키기 위해 상기 다수의 병렬 접속들을 이용하려는 목적의 충돌을 최적화하기 위해, 상기 파이프라이닝된 요청들 및 상기 병렬 접속들의 수를 동적으로 변화시키는 단계를 더 포함하는, 패킷 데이터 통신들을 위한 방법.
  5. 제 1 항에 있어서,
    상기 패킷 데이터 부분들을 렌더링하기 위해 점진적 순서화를 결정하는 단계; 및
    상기 점진적 순서화과 관련하여, 상기 복수의 파이프라이닝된 요청들의 순서를 우선순위화하는 단계를 더 포함하는, 패킷 데이터 통신들을 위한 방법.
  6. 제 1 항에 있어서,
    상기 풀 링크 활용을 유지하는 것은 과도한(greedy) 요청 기회를 활용하는 것을 더 포함하는, 패킷 데이터 통신들을 위한 방법.
  7. 제 1 항에 있어서,
    상기 풀 링크 활용을 유지하는 것은 적시(just-in-time) 요청 기회를 활용하는 것을 더 포함하는, 패킷 데이터 통신들을 위한 방법.
  8. 제 1 항에 있어서,
    상기 복수의 파이프라이닝된 요청들을 송신하는 단계는 헤더 압축을 요청하는 단계를 더 포함하는, 패킷 데이터 통신들을 위한 방법.
  9. 제 1 항에 있어서,
    요청되지 않았던 서버 식별된 자원들을 수신하는 단계를 더 포함하는, 패킷 데이터 통신들을 위한 방법.
  10. 제 9 항에 있어서,
    상기 서버 식별된 자원들이 불필요하다고 결정하는 단계; 및
    상기 서버 식별된 자원들을 취소하는 단계를 더 포함하는, 패킷 데이터 통신들을 위한 방법.
  11. 제 1 항에 있어서,
    상기 복수의 파이프라이닝된 요청들을 송신하는 단계는, 헤더 레인지(range) 특징을 이용하여, 복수의 부분적으로 파이프라이닝된 요청들을 송신하는 단계를 더 포함하는, 패킷 데이터 통신들을 위한 방법.
  12. 제 1 항에 있어서,
    상기 복수의 파이프라이닝된 요청들을 송신하는 단계는,
    인터페이스가 이용불가능하게 된 것 또는 인터페이스가 이용가능하게 된 것을 검출하는 단계;
    상기 인터페이스를 이용하는 개방 접속들을 식별하는 단계;
    상기 개방 접속들 상에서 발행된 불완전한 파이프라이닝된 요청들의 리스트를 구성하는 단계; 및
    상기 식별된 개방 접속들, 상기 인터페이스, 및 상기 불완전한 파이프라이닝된 요청들의 리스트에 부분적으로 기초한 접속 라운드 로빈 방식으로, 상기 병렬 접속들을 통한 파이프라이닝된 요청들 및 상기 병렬 접속들의 수를 동적으로 변화시키는 단계를 더 포함하는, 패킷 데이터 통신들을 위한 방법.
  13. 제 1 항에 있어서,
    각각의 인터페이스에 대한 별개의 도메인 명칭 서비스(DNS) 캐시를 유지하는 단계를 더 포함하는, 패킷 데이터 통신들을 위한 방법.
  14. 패킷 데이터 통신들을 위한 적어도 하나의 프로세서로서,
    상기 적어도 하나의 프로세서는,
    패킷 데이터 통신을 위해 다수의 병렬 접속들을 구축하기 위한 제 1 모듈;
    복수의 서버들 상에 각각 저장된 패킷 데이터 부분들로 이루어진 하이퍼텍스트 객체를 리트리브하기 위해, 상기 다수의 병렬 접속들을 통해 복수의 파이프라이닝된 요청들을 송신하기 위한 제 2 모듈; 및
    풀 링크 활용을 유지하면서 미처리 요청들을 감소시키기 위해 상기 병렬 접속들을 통한 파이프라이닝된 요청들 및 상기 병렬 접속들의 수를 동적으로 변화시키기 위한 제 3 모듈을 포함하는,
    패킷 데이터 통신들을 위한 방법.
  15. 패킷 데이터 통신들을 위한 컴퓨터 프로그램 물건으로서,
    상기 컴퓨터 프로그램 물건은 코드의 세트들을 저장하는 비일시적(non-transitory) 컴퓨터 판독가능 매체를 포함하고,
    상기 코드의 세트들은,
    컴퓨터로 하여금, 패킷 데이터 통신을 위해 다수의 병렬 접속들을 구축하게 하기 위한 코드들의 제 1 세트;
    상기 컴퓨터로 하여금, 복수의 서버들 상에 각각 저장된 패킷 데이터 부분들로 이루어진 하이퍼텍스트 객체를 리트리브하기 위해, 상기 다수의 병렬 접속들을 통해 복수의 파이프라이닝된 요청들을 송신하게 하기 위한 코드들의 제 2 세트; 및
    상기 컴퓨터로 하여금, 풀 링크 활용을 유지하면서 미처리 요청들을 감소시키기 위해 상기 병렬 접속들을 통한 파이프라이닝된 요청들 및 상기 병렬 접속들의 수를 동적으로 변화시키게 하기 위한 코드들의 제 3 세트를 포함하는,
    컴퓨터 프로그램 물건.
  16. 패킷 데이터 통신들을 위한 장치로서,
    상기 장치는,
    패킷 데이터 통신을 위해 다수의 병렬 접속들을 구축하기 위한 수단;
    복수의 서버들 상에 각각 저장된 패킷 데이터 부분들로 이루어진 하이퍼텍스트 객체를 리트리브하기 위해, 상기 다수의 병렬 접속들을 통해 복수의 파이프라이닝된 요청들을 송신하기 위한 수단; 및
    풀 링크 활용을 유지하면서 미처리 요청들을 감소시키기 위해 상기 병렬 접속들을 통한 파이프라이닝된 요청들 및 상기 병렬 접속들의 수를 동적으로 변화시키기 위한 수단을 포함하는,
    패킷 데이터 통신들을 위한 장치.
  17. 패킷 데이터 통신들을 위한 장치로서,
    상기 장치는,
    패킷 데이터 통신을 위해 다수의 병렬 접속들을 구축하기 위한 트랜시버 ?상기 트랜시버는 추가적으로, 복수의 서버들 상에 각각 저장된 패킷 데이터 부분들로 이루어진 하이퍼텍스트 객체를 리트리브하기 위해, 상기 다수의 병렬 접속들을 통해 복수의 파이프라이닝된 요청들을 송신하기 위한 것임; 및
    풀 링크 활용을 유지하면서 미처리 요청들을 감소시키기 위해 상기 병렬 접속들을 통한 파이프라이닝된 요청들 및 상기 병렬 접속들의 수를 동적으로 변화시키기 위한 컴퓨팅 플랫폼을 포함하는,
    패킷 데이터 통신들을 위한 장치.
  18. 제 17 항에 있어서,
    상기 트랜시버는 추가적으로, 무선 광역 네트워크의 노드에 액세스함으로써 상기 복수의 파이프라이닝된 요청들을 송신하기 위한 것인, 패킷 데이터 통신들을 위한 장치.
  19. 제 17 항에 있어서,
    상기 컴퓨팅 플랫폼은 추가적으로,
    대역폭 및 라운드 트립 시간을 추정하고; 그리고
    요청되었지만 수신되지 않은 패킷 데이터가 존재할 가능성이 상기 추정된 대역폭과 라운드 트립 시간의 곱을 초과할 때까지, 파이프라이닝된 요청들의 송신을 계속함으로써,
    상기 파이프라이닝된 요청들 및 상기 병렬 접속들의 수를 동적으로 변화시키기 위한 것인, 패킷 데이터 통신들을 위한 장치.
  20. 제 17 항에 있어서,
    상기 컴퓨팅 플랫폼은 추가적으로,
    상기 복수의 서버들 각각에 대한 접속들의 수를 최소화하고;
    늦거나 손실되는 요청된 패킷 데이터에 대한 전체 혼잡 응답을 감소시키기 위해, 상기 다수의 병렬 접속들을 이용하고; 그리고
    상기 접속들의 수를 최소화시키려는 목적과 상기 전체 혼잡을 감소시키기 위해 상기 다수의 병렬 접속들을 이용하려는 목적의 충돌을 최적화하기 위해, 상기 파이프라이닝된 요청들 및 상기 병렬 접속들의 수를 동적으로 변화시킴으로써,
    패킷 데이터 통신을 위해 상기 다수의 병렬 접속들을 구축하기 위한 것인, 패킷 데이터 통신들을 위한 장치.
  21. 제 17 항에 있어서,
    상기 컴퓨팅 플랫폼은 추가적으로,
    상기 패킷 데이터 부분들을 렌더링하기 위해 점진적 순서화를 결정하고; 그리고
    상기 점진적 순서화과 관련하여, 상기 복수의 파이프라이닝된 요청들의 순서를 우선순위화하기 위한 것인, 패킷 데이터 통신들을 위한 장치.
  22. 제 17 항에 있어서,
    상기 컴퓨팅 플랫폼은 추가적으로, 과도한 요청 기회를 활용함으로써 풀 링크 활용을 유지하기 위한 것인, 패킷 데이터 통신들을 위한 장치.
  23. 제 17 항에 있어서,
    상기 컴퓨팅 플랫폼은 추가적으로, 적시 요청 기회를 활용함으로써 풀 링크 활용을 유지하기 위한 것인, 패킷 데이터 통신들을 위한 장치.
  24. 제 17 항에 있어서,
    상기 트랜시버는 추가적으로, 헤더 압축을 요청함으로써 상기 복수의 파이프라이닝된 요청들을 송신하기 위한 것인, 패킷 데이터 통신들을 위한 장치.
  25. 제 17 항에 있어서,
    상기 트랜시버는 추가적으로, 요청되지 않았던 서버 식별된 자원들을 수신하기 위한 것인, 패킷 데이터 통신들을 위한 장치.
  26. 제 25 항에 있어서,
    상기 컴퓨팅 플랫폼은 추가적으로, 상기 서버 식별된 자원들이 불필요하다고 결정하고, 상기 서버 식별된 자원들을 취소하기 위한 것인, 패킷 데이터 통신들을 위한 장치.
  27. 제 17 항에 있어서,
    상기 트랜시버는 추가적으로, 헤더 레인지 특징을 이용하여 복수의 부분적으로 파이프라이닝된 요청들을 송신함으로써, 상기 복수의 파이프라이닝된 요청들을 송신하기 위한 것인, 패킷 데이터 통신들을 위한 장치.
  28. 제 17 항에 있어서,
    상기 컴퓨팅 플랫폼은 추가적으로,
    인터페이스가 이용불가능하게 된 것 또는 인터페이스가 이용가능하게 된 것을 검출하고;
    상기 인터페이스를 이용하는 개방 접속들을 식별하고;
    상기 개방 접속들 상에서 발행된 불완전한 파이프라이닝된 요청들의 리스트를 구성하고; 그리고
    상기 식별된 개방 접속들, 상기 인터페이스, 및 상기 불완전한 파이프라이닝된 요청들의 리스트에 부분적으로 기초한 접속 라운드 로빈 방식으로, 상기 병렬 접속들을 통한 파이프라이닝된 요청들 및 상기 병렬 접속들의 수를 동적으로 변화시키기 위한 것인, 패킷 데이터 통신들을 위한 장치.
  29. 제 17 항에 있어서,
    상기 컴퓨팅 플랫폼은 추가적으로, 각각의 인터페이스에 대한 별개의 도메인 명칭 서비스(DNS) 캐시를 유지하기 위한 것인, 패킷 데이터 통신들을 위한 장치.
KR1020127018934A 2009-12-18 2010-12-20 Ｈｔｔｐ 최적화, 멀티-호밍, 이동성 및 우선순위 KR101450293B1 (ko)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US28811909P 2009-12-18 2009-12-18
US61/288,119 2009-12-18
US12/965,698 2010-12-10
US12/965,698 US8964757B2 (en) 2009-12-18 2010-12-10 HTTP optimization, multi-homing, mobility and priority
PCT/US2010/061360 WO2011075738A1 (en) 2009-12-18 2010-12-20 Http optimization, multi-homing, mobility and priority

Publications (2)

Publication Number Publication Date
KR20120098894A true KR20120098894A (ko) 2012-09-05
KR101450293B1 KR101450293B1 (ko) 2014-10-13

Family

ID=43648746

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020127018934A KR101450293B1 (ko) 2009-12-18 2010-12-20 Ｈｔｔｐ 최적화, 멀티-호밍, 이동성 및 우선순위

Country Status (7)

Country Link
US (1) US8964757B2 (ko)
EP (1) EP2514164B1 (ko)
JP (2) JP5795327B2 (ko)
KR (1) KR101450293B1 (ko)
CN (1) CN102656863B (ko)
TW (1) TWI467968B (ko)
WO (1) WO2011075738A1 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20140092337A (ko) * 2012-11-16 2014-07-23 후아웨이 테크놀러지 컴퍼니 리미티드 대상을 획득하는 방법, 장치, 및 시스템

Families Citing this family (83)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5591829B2 (ja) * 2009-12-28 2014-09-17 富士通株式会社 通信方法及び通信装置
US8516147B2 (en) * 2010-02-26 2013-08-20 Simula Innovation Sa Data segmentation, request and transfer method
US20120198079A1 (en) * 2011-02-01 2012-08-02 Benjamin Spink Parallel transmissions over http connections
US8667183B1 (en) * 2011-03-20 2014-03-04 Israel L'Heureux Server-side HTTP translator
US8612967B1 (en) 2011-05-31 2013-12-17 Sprint Communications Company L.P. Loading branded media outside system partition
WO2013079999A1 (en) * 2011-12-02 2013-06-06 Canon Kabushiki Kaisha Methods and devices for encoding and decoding messages
US8666383B1 (en) 2011-12-23 2014-03-04 Sprint Communications Company L.P. Automated branding of generic applications
US10455071B2 (en) 2012-05-09 2019-10-22 Sprint Communications Company L.P. Self-identification of brand and branded firmware installation in a generic electronic device
JP5918642B2 (ja) * 2012-06-29 2016-05-18 Kddi株式会社 Ｗｅｂコンテンツの配信装置
CN102907071B (zh) * 2012-07-26 2015-04-29 华为技术有限公司 一种数据传输方法、移动终端和代理服务器
JP2014057149A (ja) * 2012-09-11 2014-03-27 Toshiba Corp 通信装置、中継装置および通信方法
US9198027B2 (en) 2012-09-18 2015-11-24 Sprint Communications Company L.P. Generic mobile devices customization framework
ES2673122T3 (es) 2012-09-29 2018-06-19 Assia Spe, Llc Sistema de control optimizado para la agregación de múltiples conexiones de banda ancha a través de interfaces de radio
CN102970356A (zh) * 2012-11-08 2013-03-13 百度在线网络技术（北京）有限公司 云端服务器和客户端的通信方法、系统和装置
US20140143316A1 (en) * 2012-11-16 2014-05-22 Huawei Technologies Co., Ltd. Method, apparatus, and system for acquiring object
US10250655B2 (en) * 2012-12-31 2019-04-02 DISH Technologies L.L.C. Scheduling segment data delivery in an adaptive media stream to avoid stalling
US8909291B1 (en) 2013-01-18 2014-12-09 Sprint Communications Company L.P. Dynamic remotely managed SIM profile
US9100769B2 (en) 2013-02-08 2015-08-04 Sprint Communications Company L.P. System and method of storing service brand packages on a mobile device
US9549009B1 (en) 2013-02-08 2017-01-17 Sprint Communications Company L.P. Electronic fixed brand labeling
US9100819B2 (en) 2013-02-08 2015-08-04 Sprint-Communications Company L.P. System and method of provisioning and reprovisioning a mobile device based on self-locating
US9204286B1 (en) 2013-03-15 2015-12-01 Sprint Communications Company L.P. System and method of branding and labeling a mobile device
KR102164457B1 (ko) 2013-04-25 2020-10-14 삼성전자주식회사 다중 무선 억세스를 위한 전자 장치 및 그 방법
US9280483B1 (en) 2013-05-22 2016-03-08 Sprint Communications Company L.P. Rebranding a portable electronic device while maintaining user data
US20150043554A1 (en) * 2013-08-07 2015-02-12 Qualcomm Incorporated Management of interfaces for wireless communications
JP6211856B2 (ja) * 2013-08-08 2017-10-11 株式会社Ｎｔｔドコモ ユーザ端末、無線通信システム及び通信制御方法
US9532211B1 (en) 2013-08-15 2016-12-27 Sprint Communications Company L.P. Directing server connection based on location identifier
US9161209B1 (en) 2013-08-21 2015-10-13 Sprint Communications Company L.P. Multi-step mobile device initiation with intermediate partial reset
US9204239B1 (en) * 2013-08-27 2015-12-01 Sprint Communications Company L.P. Segmented customization package within distributed server architecture
US9125037B2 (en) 2013-08-27 2015-09-01 Sprint Communications Company L.P. System and methods for deferred and remote device branding
US9143924B1 (en) 2013-08-27 2015-09-22 Sprint Communications Company L.P. Segmented customization payload delivery
US10506398B2 (en) 2013-10-23 2019-12-10 Sprint Communications Company Lp. Implementation of remotely hosted branding content and customizations
US9743271B2 (en) 2013-10-23 2017-08-22 Sprint Communications Company L.P. Delivery of branding content and customizations to a mobile communication device
US9301081B1 (en) 2013-11-06 2016-03-29 Sprint Communications Company L.P. Delivery of oversized branding elements for customization
US9363622B1 (en) 2013-11-08 2016-06-07 Sprint Communications Company L.P. Separation of client identification composition from customization payload to original equipment manufacturer layer
US9161325B1 (en) 2013-11-20 2015-10-13 Sprint Communications Company L.P. Subscriber identity module virtualization
US9912631B2 (en) * 2013-12-26 2018-03-06 Fastly, Inc. Content node selection based on classless prefix
KR20150084307A (ko) * 2014-01-13 2015-07-22 삼성전자주식회사 네트워크에서 웹 로딩 시간 제어 방법 및 장치
US9392395B1 (en) 2014-01-16 2016-07-12 Sprint Communications Company L.P. Background delivery of device configuration and branding
US9420496B1 (en) 2014-01-24 2016-08-16 Sprint Communications Company L.P. Activation sequence using permission based connection to network
US9603009B1 (en) 2014-01-24 2017-03-21 Sprint Communications Company L.P. System and method of branding a device independent of device activation
KR102143620B1 (ko) 2014-02-17 2020-08-11 삼성전자주식회사 전자 장치에서 다중 인터페이스를 이용한 응용 계층의 요청 처리 장치 및 방법
US20150281367A1 (en) * 2014-03-26 2015-10-01 Akamai Technologies, Inc. Multipath tcp techniques for distributed computing systems
US9681251B1 (en) 2014-03-31 2017-06-13 Sprint Communications Company L.P. Customization for preloaded applications
US9660926B2 (en) 2014-05-30 2017-05-23 Apple Inc. Multi-stream scheduling and requests
US9426641B1 (en) 2014-06-05 2016-08-23 Sprint Communications Company L.P. Multiple carrier partition dynamic access on a mobile device
US20160037509A1 (en) * 2014-07-30 2016-02-04 Onavo Mobile Ltd. Techniques to reduce bandwidth usage through multiplexing and compression
US9787564B2 (en) * 2014-08-04 2017-10-10 Cisco Technology, Inc. Algorithm for latency saving calculation in a piped message protocol on proxy caching engine
WO2016030718A1 (en) * 2014-08-25 2016-03-03 Nokia Technologies Oy Methods and apparatus for wireless connection management
CN105468613A (zh) * 2014-09-01 2016-04-06 深圳富泰宏精密工业有限公司 智能调整运算资源的系统及方法
US9307400B1 (en) 2014-09-02 2016-04-05 Sprint Communications Company L.P. System and method of efficient mobile device network brand customization
US9992326B1 (en) 2014-10-31 2018-06-05 Sprint Communications Company L.P. Out of the box experience (OOBE) country choice using Wi-Fi layer transmission
CN107210923B (zh) 2014-12-04 2020-12-15 适应性频谱和信号校正股份有限公司 用于预测成功的dsl线路优化的方法和装置
WO2016108150A1 (en) * 2014-12-29 2016-07-07 Watchy Technology Private Limited System for increasing bandwidth available for data communication
US9357378B1 (en) 2015-03-04 2016-05-31 Sprint Communications Company L.P. Subscriber identity module (SIM) card initiation of custom application launcher installation on a mobile communication device
US9398462B1 (en) 2015-03-04 2016-07-19 Sprint Communications Company L.P. Network access tiered based on application launcher installation
US10185781B2 (en) * 2015-05-20 2019-01-22 Cbs Interactive Inc. Method and apparatus for determining bandwidth required for a page feature
US10165037B2 (en) 2015-05-20 2018-12-25 Cbs Interactive Inc. Method and apparatus for determining bandwidth required for a page feature
US11172273B2 (en) 2015-08-10 2021-11-09 Delta Energy & Communications, Inc. Transformer monitor, communications and data collection device
WO2017027682A1 (en) 2015-08-11 2017-02-16 Delta Energy & Communications, Inc. Enhanced reality system for visualizing, evaluating, diagnosing, optimizing and servicing smart grids and incorporated components
US10055966B2 (en) 2015-09-03 2018-08-21 Delta Energy & Communications, Inc. System and method for determination and remediation of energy diversion in a smart grid network
US11196621B2 (en) 2015-10-02 2021-12-07 Delta Energy & Communications, Inc. Supplemental and alternative digital data delivery and receipt mesh net work realized through the placement of enhanced transformer mounted monitoring devices
WO2017070646A1 (en) 2015-10-22 2017-04-27 Delta Energy & Communications, Inc. Data transfer facilitation across a distributed mesh network using light and optical based technology
US10791020B2 (en) * 2016-02-24 2020-09-29 Delta Energy & Communications, Inc. Distributed 802.11S mesh network using transformer module hardware for the capture and transmission of data
CN105915582B (zh) * 2016-03-28 2019-04-02 深圳市双赢伟业科技股份有限公司 路由器访问网页的方法及路由器
US9992786B2 (en) 2016-03-31 2018-06-05 At&T Intellectual Property I, L.P. Facilitation of multipath scheduling
US10193781B2 (en) 2016-04-14 2019-01-29 At&T Intellectual Property I, L.P. Facilitation of multipath transmission control protocols
US10182020B2 (en) * 2016-05-31 2019-01-15 Anchorfree Inc. System and method for improving an aggregated throughput of simultaneous connections
US10652633B2 (en) 2016-08-15 2020-05-12 Delta Energy & Communications, Inc. Integrated solutions of Internet of Things and smart grid network pertaining to communication, data and asset serialization, and data modeling algorithms
CN106357736B (zh) * 2016-08-26 2019-04-23 百度在线网络技术（北京）有限公司 用于传输文件的方法和装置
US9913132B1 (en) 2016-09-14 2018-03-06 Sprint Communications Company L.P. System and method of mobile phone customization based on universal manifest
US10021240B1 (en) 2016-09-16 2018-07-10 Sprint Communications Company L.P. System and method of mobile phone customization based on universal manifest with feature override
CN106790480B (zh) * 2016-12-12 2020-08-11 中国航空工业集团公司西安航空计算技术研究所 一种用于链路聚合链接条件下的文件传输方法
WO2018149581A1 (en) * 2017-02-15 2018-08-23 Nokia Solutions And Networks Oy Network multi-path proxy selection to route data packets
EP3593502B1 (en) 2017-03-07 2022-10-12 Akamai Technologies, Inc. Cooperative multipath
US10306433B1 (en) 2017-05-01 2019-05-28 Sprint Communications Company L.P. Mobile phone differentiated user set-up
CN109936510B (zh) * 2017-12-15 2022-11-15 微软技术许可有限责任公司 多路径rdma传输
CN110166506B (zh) * 2018-02-12 2021-11-19 中国移动通信有限公司研究院 超文本传输协议Http的连接方法及节点设备
CN110351319B (zh) * 2018-04-04 2022-04-01 中国移动通信有限公司研究院 一种请求消息传输方法、装置及传输设备
US11277463B2 (en) 2019-05-31 2022-03-15 Apple Inc. Application mobility enhancements
US11540195B2 (en) 2019-05-31 2022-12-27 Apple Inc. Cellular enhancements for application mobility
CN111988235B (zh) * 2020-08-13 2023-05-09 暨南大学 一种基于多http/3连接的并行传输方法
US11537678B1 (en) 2021-08-31 2022-12-27 International Business Machines Corporation Fast-tracking of web requests using a request digest
US11991525B2 (en) 2021-12-02 2024-05-21 T-Mobile Usa, Inc. Wireless device access and subsidy control

Family Cites Families (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6212565B1 (en) 1998-08-26 2001-04-03 Sun Microsystems, Inc. Apparatus and method for improving performance of proxy server arrays that use persistent connections
US6820133B1 (en) * 2000-02-07 2004-11-16 Netli, Inc. System and method for high-performance delivery of web content using high-performance communications protocol between the first and second specialized intermediate nodes to optimize a measure of communications performance between the source and the destination
JP4818812B2 (ja) 2006-05-31 2011-11-16 株式会社日立製作所 フラッシュメモリストレージシステム
US7230921B2 (en) 2001-04-02 2007-06-12 Telefonaktiebolaget Lm Ericsson (Publ) Concurrent use of communication paths in a multi-path access link to an IP network
US6801940B1 (en) 2002-01-10 2004-10-05 Networks Associates Technology, Inc. Application performance monitoring expert
CN1182685C (zh) 2002-04-29 2004-12-29 清华大学 用于报文转发系统的队列管理方法
US7409454B2 (en) * 2003-06-02 2008-08-05 Microsoft Corporation Automatic detection of intermediate network device capabilities
WO2004114581A2 (en) * 2003-06-17 2004-12-29 Bytemobile, Inc. Method and system for dynamic interleaving
US20100211626A1 (en) * 2004-01-12 2010-08-19 Foundry Networks, Inc. Method and apparatus for maintaining longer persistent connections
US20060031520A1 (en) * 2004-05-06 2006-02-09 Motorola, Inc. Allocation of common persistent connections through proxies
JP2005341310A (ja) 2004-05-27 2005-12-08 Fujitsu Ten Ltd 通信装置
US7657618B1 (en) * 2004-10-15 2010-02-02 F5 Networks, Inc. Management of multiple client requests
WO2006055784A2 (en) 2004-11-19 2006-05-26 The Trustees Of The Stevens Institute Of Technology Multi-access terminal wiht capability for simultaneous connectivity to multiple communication channels
CN100486249C (zh) 2005-03-29 2009-05-06 华为技术有限公司 一种调整传输控制协议接收窗口的方法
JP2007043678A (ja) 2005-06-29 2007-02-15 Ntt Docomo Inc 通信端末及び通信方法
US20070124310A1 (en) 2005-07-26 2007-05-31 Novo Innovations, Inc. Distributed Computing System to Enable the Secure Exchange of Information Between Remotely Located Healthcare Applications
US7835743B2 (en) 2005-08-03 2010-11-16 Toshiba America Research, Inc. Seamless network interface selection, handoff and management in multi-IP network interface mobile devices
US8259739B2 (en) 2005-10-31 2012-09-04 Cisco Technology, Inc. Scatter and gather scheme for aggregating multiple high speed point-to-point interfaces
WO2007063585A1 (ja) 2005-11-30 2007-06-07 Fujitsu Limited 通信装置およびフレーム制御方法
JP2007281731A (ja) 2006-04-05 2007-10-25 Mitsubishi Electric Corp 通信装置及び通信方法及びプログラム
US7640358B2 (en) 2006-11-09 2009-12-29 Sharp Laboratories Of America, Inc. Methods and systems for HTTP streaming using an intelligent HTTP client
US8027293B2 (en) 2007-07-16 2011-09-27 Cellport Systems, Inc. Communication channel selection and use
JP5049069B2 (ja) 2007-08-02 2012-10-17 ソフトバンクテレコム株式会社 無線通信端末装置、及び通信ネットワークプログラム
JP5097620B2 (ja) 2008-06-03 2012-12-12 株式会社日立製作所 マルチパス通信システム
US20110314129A1 (en) 2009-12-18 2011-12-22 Ramin Rezaiifar Binding/aggregating multiple interfaces at application layer

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20140092337A (ko) * 2012-11-16 2014-07-23 후아웨이 테크놀러지 컴퍼니 리미티드 대상을 획득하는 방법, 장치, 및 시스템

Also Published As

Publication number Publication date
US8964757B2 (en) 2015-02-24
WO2011075738A1 (en) 2011-06-23
JP2013515399A (ja) 2013-05-02
EP2514164A1 (en) 2012-10-24
TW201141134A (en) 2011-11-16
EP2514164B1 (en) 2018-01-17
TWI467968B (zh) 2015-01-01
JP5795327B2 (ja) 2015-10-14
CN102656863A (zh) 2012-09-05
US20110222404A1 (en) 2011-09-15
KR101450293B1 (ko) 2014-10-13
JP2015164330A (ja) 2015-09-10
CN102656863B (zh) 2015-10-21

Similar Documents

Publication Publication Date Title
KR101450293B1 (ko) Ｈｔｔｐ 최적화, 멀티-호밍, 이동성 및 우선순위
JP5701902B2 (ja) アプリケーションレイヤにおける複数のインターフェースの結合／集約
US10313252B2 (en) Method and system for dynamic interleaving
EP2294515B1 (en) Request routing using network computing components
KR101346549B1 (ko) 네트워크 통신 파라미터를 설정하기 위한 기술
US20130103791A1 (en) Optimizing content delivery over a protocol that enables request multiplexing and flow control
US10070348B2 (en) Hypertext transfer protocol support over hybrid access
US11159642B2 (en) Site and page specific resource prioritization
US11115498B2 (en) Multi-path management
US20180091631A1 (en) Systems and methods for writing prioritized http/2 data to a socket buffer
CN110691149B (zh) 操作内容递送网络的方法、设备及操作原始服务器的方法
CN117596232A (zh) 流媒体快速启动方法、装置和系统
US11128733B2 (en) Server-side resource prioritization
EP3286967B1 (en) Technique for scheduling transmission of content in an access network
WO2023246488A1 (zh) 内容提供方法及装置
Khandaker et al. On-path vs off-path traffic steering, that is the question
EP2919439A1 (en) Requesting web content

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
LAPS Lapse due to unpaid annual fee