KR102007105B1 - 개선된 클라이언트-주도형의 서버 디바이스에 의한 자원의 푸시 - Google Patents
개선된 클라이언트-주도형의 서버 디바이스에 의한 자원의 푸시 Download PDFInfo
- Publication number
- KR102007105B1 KR102007105B1 KR1020177023038A KR20177023038A KR102007105B1 KR 102007105 B1 KR102007105 B1 KR 102007105B1 KR 1020177023038 A KR1020177023038 A KR 1020177023038A KR 20177023038 A KR20177023038 A KR 20177023038A KR 102007105 B1 KR102007105 B1 KR 102007105B1
- Authority
- KR
- South Korea
- Prior art keywords
- data
- push
- client
- server
- request
- Prior art date
Links
- 238000000034 method Methods 0.000 claims abstract description 115
- 238000004891 communication Methods 0.000 claims abstract description 14
- 230000004044 response Effects 0.000 claims description 69
- 238000001914 filtration Methods 0.000 claims description 40
- 238000006467 substitution reaction Methods 0.000 claims description 14
- 238000010276 construction Methods 0.000 claims description 7
- 238000004590 computer program Methods 0.000 claims description 3
- 230000005540 biological transmission Effects 0.000 abstract description 15
- 230000006870 function Effects 0.000 description 41
- 230000008569 process Effects 0.000 description 32
- 230000003044 adaptive effect Effects 0.000 description 18
- 238000012545 processing Methods 0.000 description 18
- 230000007246 mechanism Effects 0.000 description 10
- 238000013459 approach Methods 0.000 description 9
- 230000006399 behavior Effects 0.000 description 9
- 238000012546 transfer Methods 0.000 description 9
- 238000012360 testing method Methods 0.000 description 7
- 230000008901 benefit Effects 0.000 description 6
- 230000015654 memory Effects 0.000 description 6
- 239000000872 buffer Substances 0.000 description 5
- 238000009877 rendering Methods 0.000 description 5
- 230000003068 static effect Effects 0.000 description 5
- 238000012384 transportation and delivery Methods 0.000 description 5
- 210000001072 colon Anatomy 0.000 description 4
- 230000001419 dependent effect Effects 0.000 description 4
- 238000000605 extraction Methods 0.000 description 4
- 230000002123 temporal effect Effects 0.000 description 4
- 238000013475 authorization Methods 0.000 description 3
- 238000004422 calculation algorithm Methods 0.000 description 3
- 230000008859 change Effects 0.000 description 3
- 230000009467 reduction Effects 0.000 description 3
- 101100242901 Quaranfil virus (isolate QrfV/Tick/Afghanistan/EG_T_377/1968) PB2 gene Proteins 0.000 description 2
- 101150082826 Segment-2 gene Proteins 0.000 description 2
- 101100194052 Thogoto virus (isolate SiAr 126) Segment 2 gene Proteins 0.000 description 2
- 230000002457 bidirectional effect Effects 0.000 description 2
- 238000006243 chemical reaction Methods 0.000 description 2
- 230000006835 compression Effects 0.000 description 2
- 238000007906 compression Methods 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 239000000284 extract Substances 0.000 description 2
- 239000012634 fragment Substances 0.000 description 2
- 101150013335 img1 gene Proteins 0.000 description 2
- 101150071665 img2 gene Proteins 0.000 description 2
- 238000003780 insertion Methods 0.000 description 2
- 230000037431 insertion Effects 0.000 description 2
- 238000013507 mapping Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 101100242890 Quaranfil virus (isolate QrfV/Tick/Afghanistan/EG_T_377/1968) PA gene Proteins 0.000 description 1
- 101100247669 Quaranfil virus (isolate QrfV/Tick/Afghanistan/EG_T_377/1968) PB1 gene Proteins 0.000 description 1
- 101150025928 Segment-1 gene Proteins 0.000 description 1
- 101150027881 Segment-3 gene Proteins 0.000 description 1
- 101150091797 Segment-4 gene Proteins 0.000 description 1
- 101100242902 Thogoto virus (isolate SiAr 126) Segment 1 gene Proteins 0.000 description 1
- 101100242891 Thogoto virus (isolate SiAr 126) Segment 3 gene Proteins 0.000 description 1
- 230000001133 acceleration Effects 0.000 description 1
- 230000009471 action Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 239000003795 chemical substances by application Substances 0.000 description 1
- 230000002708 enhancing effect Effects 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- AWSBQWZZLBPUQH-UHFFFAOYSA-N mdat Chemical compound C1=C2CC(N)CCC2=CC2=C1OCO2 AWSBQWZZLBPUQH-UHFFFAOYSA-N 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 238000013439 planning Methods 0.000 description 1
- 238000002360 preparation method Methods 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 230000000153 supplemental effect Effects 0.000 description 1
- 230000001052 transient effect Effects 0.000 description 1
- 239000002699 waste material Substances 0.000 description 1
- 230000003936 working memory Effects 0.000 description 1
Images
Classifications
-
- H04L67/26—
-
- 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/55—Push-based network services
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/95—Retrieval from the web
- G06F16/957—Browsing optimisation, e.g. caching or content distillation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/83—Admission control; Resource allocation based on usage prediction
-
- H04L65/4084—
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
- H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
- H04L65/613—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for the control of the source by the destination
-
- 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
-
- 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]
-
- H04L67/42—
-
- 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
- H04N21/454—Content or additional data filtering, e.g. blocking advertisements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/47—End-user applications
- H04N21/472—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
- H04N21/4722—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content for requesting additional data associated with the content
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/637—Control signals issued by the client directed to the server or network components
- H04N21/6377—Control signals issued by the client directed to the server or network components directed to server
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
-
- 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/22—Parsing or analysis of headers
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Multimedia (AREA)
- Databases & Information Systems (AREA)
- Computer Security & Cryptography (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- Human Computer Interaction (AREA)
- Information Transfer Between Computers (AREA)
- Computer And Data Communications (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Abstract
본 발명은, HTTP 통신 네트워크를 통한 데이터 전송, 예를 들어, 데이터 스트리밍에 관한 것이다. 서버와 클라이언트 사이에서 데이터를 전송하는 방법은, 서버에서: 클라이언트부터, 제1 데이터를 획득하라는 HTTP 요청을 수신 ―이 HTTP 요청은 서버 상의 제1 데이터의 식별을 허용하는 제1 데이터 식별 정보를 포함하고, 제2 데이터를 푸시하는 것에 관련된 표시를 포함하는 하나 이상의 추가 헤더 필드를 포함함― 하는 단계; 제1 데이터를 검색하여 클라이언트에 전송하는 단계; 및 확인응답 데이터 ―이 확인응답 데이터는 제2 데이터를 푸시하는 것에 관련된 표시를 나타냄― 를 클라이언트 디바이스에 전송하는 단계를 포함한다.
Description
본 발명은 HTTP(HyperText Transfer Protocol) 통신 네트워크를 통한 데이터 전송, 예를 들어, 데이터 스트리밍, 더 정확하게는 클라이언트 주도형의 서버 디바이스에 의한 자원의 푸시에 관한 것이다.
DASH(Dynamic Adaptive Streaming over HTTP의 약자) 미디어 콘텐츠 스트리밍 등의 HTTP를 통한 통신에서는, 클라이언트 디바이스가 서버 디바이스에게 많은 양의 데이터를 요청할 수 있다. 이렇게 하기 위해, 클라이언트 디바이스는 대개 HTTP 요청들을 아마도 HTTP 요청 내의 하나 이상의 추가 헤더(예를 들어, URI(uniform resource identifier, 유니폼 리소스 식별자)로 식별되는 자원 내의 바이트 범위를 제공하는 Range 헤더)와 함께 전송하고, 요청들 각각은, 메소드(예를 들어, "GET")와 서버 디바이스 상의 요청된 데이터를 식별하고 위치파악하는 URI로 구성된 요청 라인을 포함한다.
서버 디바이스가 아직 클라이언트 디바이스에 의해 요청되지 않은 데이터를 자발적으로 푸시할 수 있도록 하는 서버 푸시 기능이 개발되었다. 이것은 웹 자원 로딩 시간을 감소시키기 위한 유용한 기능이다.
서버 푸시 기능은, 서버 디바이스가 요청되지 않은 웹 자원 표현을 클라이언트 디바이스에 전송하는 것을 허용하기 위해 (단일의 기존 접속 내에서, 수 개의 요청/응답을 교환하는 것을 가능하게 하는, 즉, 수 개의 스트림을 갖는 것을 가능하게 하는) HTTP/2에서 도입되었다. 웹 페이지 등의 웹 자원은 일반적으로 다른 자원으로의 링크를 포함하며, 자원들 그 자체는 다른 자원으로의 링크를 포함할 수 있다. 웹 페이지를 완전히 디스플레이하기 위해, 모든 링크된 및 하위-링크된 자원들이 클라이언트 디바이스에 의해 검색될 필요가 있다. 이 증분적 검색은, 특히 모바일 네트워크 등의 높은 레이턴시의 네트워크에서, 웹 페이지의 느린 디스플레이로 이어질 수 있다.
주어진 웹 페이지에 대한 요청을 수신할 때, 서버 디바이스는 요청된 자원의 전체 처리를 위해 어떤 다른 자원이 필요한지를 결정할 수 있다. 요청된 자원 및 링크된 자원을 동시에 전송함으로써, 서버 디바이스는 웹 페이지의 로딩 시간의 감소를 허용한다. 따라서, 푸시 기능을 이용하여, 서버 디바이스는 주어진 자원이 요청될 때 추가 자원 표현을 전송할 수 있다.
데이터의 푸시는 또한, DASH와 관련하여, 예를 들어 WO 2015/004276호로 공개된 출원인의 출원에서 제안되었다.
이 공보는, 특히 DASH-기반 통신의 정황에서 데이터 스트리밍을 향상시켜 사용자 환경을 최적화하는 것을 추구한다. 이것은 종래의 메커니즘에서, 클라이언트 및 서버 디바이스는 약속된 데이터가 원하는 시간에 전송되고 수신될 것인지를 알지 못할 수도 있기 때문이다: 클라이언트 디바이스는 비디오 세그먼트들이 언제 및 어떤 순서로 전송될 것인지를 알지 못할 수 있기 때문이다. 또한, 서버 디바이스에 의해 푸시되거나 공지된 약속된 데이터는 (시간이 지남에 따라 달라질 수 있는) 클라이언트 디바이스의 요구사항과 불일치할 수 있으므로, 특히 서버 측에서의 자원 낭비로 이어질 수 있다. 따라서, 공보 WO 2015/004276호는, 서버 디바이스와 클라이언트 디바이스 사이의 푸시 정책 공유를 제안한다.
이러한 공유는 클라이언트 디바이스가 어떤 데이터가 푸시될 것인지를 미리 알게 하고, 이러한 푸시의 취소를 준비하여 네트워크 대역폭의 낭비를 피하는 것을 돕는다.
그러나, 이 공보에서 제안된 메커니즘은, 특히 XML 기반 DASH "미디어 프리젠테이션 설명" 파일(MPD)에 푸시 정책을 적용하여 푸시 정책에 따라 어떤 데이터 또는 자원을 푸시할지를 결정할 수 있기 위해, 서버 디바이스가 DASH에 대한 정교한 지식을 가질 것을 요구한다.
MPD 파일은 미디어 세그먼트들 내로의 미디어 콘텐츠의 구조를 기술한다는 것을 상기한다. MPD 파일은 서버 디바이스와 클라이언트 디바이스 사이에서 교환되며, 클라이언트 디바이스가 미디어 콘텐츠의 전달을 제어하도록, 즉, 각각의 미디어 세그먼트를 개별적으로 요청하도록 허용하는 정보를 클라이언트 디바이스에 제공한다.
이러한 정황에서, 본 발명은 서버 디바이스와 클라이언트 디바이스 사이에서 데이터를 전송하는 방법을 제공하며, 이 방법은, 서버 디바이스에서, 다음과 같은 단계들을 포함한다:
클라이언트 디바이스로부터, 제1 데이터를 획득하라는 HTTP 요청을 수신 ―HTTP 요청은 서버 디바이스 상의 제1 데이터의 식별을 허용하는 제1 데이터 식별 정보를 포함하고, 제2 데이터를 푸시하는 것에 관련된 표시를 포함하는 하나 이상의 추가 헤더 필드를 포함함― 하는 단계;
제1 데이터를 검색하여 클라이언트 디바이스에 전송하는 단계;
확인응답 데이터 ―확인응답 데이터는 제2 데이터를 푸시하는 것에 관련된 표시를 나타냄― 를 클라이언트 디바이스에 전송하는 단계;
하나 이상의 추가 헤더 필드 및 아마도 제1 데이터 식별 정보만을 이용하여, 서버 디바이스 상의 제2 데이터의 식별을 허용하는 제2 데이터 식별 정보를 결정하는 단계.
따라서, 본 발명의 방법은 클라이언트 디바이스가 서버 디바이스에 의해 적용된 푸시 정책에 비추어 그 거동을 적응시키는 것을 가능하게 한다.
실시예들에서, 이 방법은:
클라이언트 디바이스로의 제2 데이터의 푸시를 공지하는 푸시 약속 메시지를 전송하고/하거나 제2 데이터를 클라이언트 디바이스에 푸시하는 단계를 더 포함한다.
실시예들에서, 확인응답 데이터는 제2 데이터를 푸시하기 위한 표시를 나타낸다.
실시예들에서, 확인응답 데이터는 HTTP 요청에 응답하여 어떠한 제2 데이터도 푸시되지 않을 것임을 나타낸다.
실시예들에서, 제2 데이터를 푸시하는 것에 관련된 표시는 제2 데이터를 푸시하는 것에 관련된 적어도 2개의 상이한 표시를 포함하는 목록을 포함한다.
실시예에서, 확인응답 데이터는 제2 데이터를 푸시하는 것에 관련된 적어도 2개의 상이한 표시 중 하나의 표시를 포함하며, 제2 데이터를 푸시하는 것에 관련된 적어도 2개의 상이한 표시 중 상기 하나의 표시는 클라이언트 디바이스에 푸시될 제2 데이터를 식별하는데 이용된다.
실시예들에서, 제2 데이터를 푸시하는 것에 관련된 표시는 제2 데이터의 데이터 타입과 연관되며, 이 데이터 타입은 설명 데이터 타입(description data type) 또는 콘텐츠 데이터 타입(content data type)을 포함하고, 제2 데이터는 콘텐츠 데이터 또는 설명 데이터에 속한다.
실시예들에서, 제2 데이터를 푸시하는 것에 관련된 표시는 미디어 프리젠테이션 설명 업데이트를 푸시하는 것에 관한 것이다.
실시예들에서, 확인응답 데이터는 제2 데이터를 푸시하는 것에 관련된 표시를 포함하며, 확인응답 데이터 내의 제2 데이터를 푸시하는 것에 관련된 표시는 HTTP 요청 내의 제2 데이터를 푸시하는 것에 관련된 표시와는 상이하다.
실시예들에서, 제2 데이터를 푸시하는 것에 관련된 표시는 적어도 하나의 고유 식별자를 포함하고, 이 적어도 하나의 고유 식별자는 제2 데이터를 푸시하기 위한 지시(directive) 및 푸시될 제2 데이터의 식별을 나타내거나, 제2 데이터를 푸시하지 말라는 지시를 나타낸다.
실시예들에서, 고유 식별자는 중앙집중식 저장소에서 정의된다.
실시예들에서, 고유 식별자는 적어도 하나의 파라미터의 함수로서 설정된다.
본 발명의 또 다른 목적에 따르면, 서버 디바이스와 클라이언트 디바이스 사이에서 데이터를 전송하는 방법이 제공되고, 이 방법은, 클라이언트 디바이스에서, 다음과 같은 단계들을 포함한다:
서버 디바이스로부터 획득될 데이터를 식별하는 단계;
식별된 데이터로부터 제1 데이터를 획득하라는 HTTP 요청 ―HTTP 요청은 서버 디바이스 상의 제1 데이터의 식별을 허용하는 제1 데이터 식별 정보를 포함하고, 서버 디바이스가 제2 데이터를 푸시하라는 또는 제2 데이터를 푸시하지 말라는 표시를 포함하는 하나 이상의 추가 헤더 필드를 포함함― 을 생성하는 단계;
제1 데이터를 획득하고 제2 데이터를 푸시하거나 푸시하지 말도록 서버 디바이스를 구동하기 위해 HTTP 요청을 서버 디바이스에 전송하는 단계;
HTTP 요청을 전송하는 것에 응답하여, 서버 디바이스로부터 확인응답 데이터 ―확인응답 데이터는 제2 데이터를 푸시하는 것에 관련된 표시를 나타냄― 를 수신하는 단계;
여기서, 하나 이상의 추가 헤더 필드는, 하나 이상의 추가 헤더 필드 및 아마도 제1 데이터 식별 정보에만 기초하여, 서버 디바이스 상의 식별된 데이터로부터의 제2 데이터의 식별을 허용하는 제2 데이터 식별 정보를 정의한다.
따라서, 본 발명의 방법은 클라이언트 디바이스가 서버 디바이스에 의해 적용된 푸시 정책에 비추어 그 거동을 적응시키는 것을 가능하게 한다.
실시예들에서, 확인응답 데이터는 제2 데이터를 푸시하기 위한 표시를 나타낸다.
실시예들에서, 확인응답 데이터는 HTTP 요청에 응답하여 어떠한 제2 데이터도 푸시되지 않을 것임을 나타낸다.
실시예들에서, 제2 데이터를 푸시하는 것에 관련된 표시는 제2 데이터를 푸시하는 것에 관련된 적어도 2개의 상이한 표시를 포함하는 목록을 포함한다.
실시예들에서, 확인응답 데이터는 제2 데이터를 푸시하는 것에 관련된 적어도 2개의 상이한 표시 중 하나의 표시를 포함하며, 제2 데이터를 푸시하는 것에 관련된 적어도 2개의 상이한 표시 중 상기 하나의 표시는 클라이언트 디바이스에 푸시될 제2 데이터를 식별하기 위해 서버 디바이스에 의해 이용된다.
실시예들에서, 제2 데이터를 푸시하는 것에 관련된 표시는 제2 데이터의 데이터 타입과 연관되며, 이 데이터 타입은 설명 데이터 타입 또는 콘텐츠 데이터 타입을 포함하고, 제2 데이터는 콘텐츠 데이터 또는 설명 데이터에 속한다.
실시예들에서, 제2 데이터를 푸시하는 것에 관련된 표시는 설명 데이터를 푸시하는 것에 관한 것이다.
실시예들에서, 확인응답 데이터는 제2 데이터를 푸시하는 것에 관련된 표시를 포함하며, 확인응답 데이터 내의 제2 데이터를 푸시하는 것에 관련된 표시는 HTTP 요청 내의 제2 데이터를 푸시하는 것에 관련된 표시와는 상이하다.
실시예들에서, 제2 데이터를 푸시하는 것에 관련된 표시는 적어도 하나의 고유 식별자를 포함하고, 이 적어도 하나의 고유 식별자는 제2 데이터를 푸시하기 위한 지시(directive) 및 푸시될 제2 데이터의 식별을 나타내거나, 제2 데이터를 푸시하지 말라는 지시를 나타낸다.
실시예들에서, 고유 식별자는 중앙집중식 저장소에서 정의된다.
실시예들에서, 고유 식별자는 적어도 하나의 파라미터의 함수로서 설정된다.
본 발명의 또 다른 목적에 따르면, 서버 디바이스와 클라이언트 디바이스 사이에서 데이터를 전송하는 방법이 제공되고, 이 방법은, 서버 디바이스에서, 다음과 같은 단계들을 포함한다:
클라이언트 디바이스로부터, 제1 데이터를 획득하라는 HTTP 요청을 수신 ―HTTP 요청은 서버 디바이스 상의 제1 데이터의 식별을 허용하는 제1 데이터 식별 정보를 포함하고, 하나 이상의 추가 헤더 필드를 포함함― 하는 단계;
제1 데이터를 검색하여 클라이언트 디바이스에 전송하는 단계; 및
하나 이상의 추가 필드 내에 포함된 제2 데이터를 푸시하는 것에 관련된 표시의 함수로서 제2 데이터를 클라이언트 디바이스에 푸시하거나 푸시하지 않는 단계.
본 발명의 방법은 유용한 데이터를 클라이언트 디바이스에 푸시하는 서버 디바이스의 능력을 향상시킨다.
실시예들에서, 제2 데이터를 푸시하는 것에 관련된 표시는 제2 데이터를 푸시하는 것에 관련된 적어도 2개의 상이한 표시를 포함하는 목록을 포함한다.
실시예들에서, 제2 데이터를 푸시하는 것에 관련된 표시는 제2 데이터의 데이터 타입과 연관되며, 이 데이터 타입은 설명 데이터 타입 또는 콘텐츠 데이터 타입을 포함하고, 제2 데이터는 콘텐츠 데이터 또는 설명 데이터에 속한다.
실시예들에서, 제2 데이터를 푸시하는 것에 관련된 표시는 설명 데이터를 푸시하는 것에 관한 것이다.
실시예들에서, 제2 데이터를 푸시하는 것에 관련된 표시는 적어도 하나의 고유 식별자를 포함하고, 이 적어도 하나의 고유 식별자는 제2 데이터를 푸시하기 위한 지시(directive) 및 푸시될 제2 데이터의 식별을 나타내거나, 제2 데이터를 푸시하지 말라는 지시를 나타낸다.
실시예들에서, 고유 식별자는 중앙집중식 저장소에서 정의된다.
실시예들에서, 고유 식별자는 적어도 하나의 파라미터의 함수로서 설정된다.
본 발명의 또 다른 목적에 따르면, 서버 디바이스와 클라이언트 디바이스 사이에서 데이터를 전송하는 방법이 제공되고, 이 방법은, 클라이언트 디바이스에서, 다음과 같은 단계들을 포함한다:
서버 디바이스로부터 획득될 데이터를 식별하는 단계;
식별된 데이터로부터 제1 데이터를 획득하라는 HTTP 요청 ―HTTP 요청은 서버 디바이스 상의 제1 데이터의 식별을 허용하는 제1 데이터 식별 정보를 포함하고, 서버 디바이스가 제2 데이터를 푸시하라는 또는 제2 데이터를 푸시하지 말라는 표시를 포함하는 하나 이상의 추가 헤더 필드를 포함함― 을 생성하는 단계; 및
제1 데이터를 획득하고 제2 데이터를 푸시하거나 푸시하지 말도록 서버 디바이스를 구동하기 위해 HTTP 요청을 서버 디바이스에 전송하는 단계.
본 발명의 방법은 유용한 데이터를 클라이언트 디바이스에 푸시하는 서버 디바이스의 능력을 향상시킨다.
실시예들에서, 제2 데이터를 푸시하는 것에 관련된 표시는 제2 데이터를 푸시하는 것에 관련된 적어도 2개의 상이한 표시를 포함하는 목록을 포함한다.
실시예들에서, 제2 데이터를 푸시하는 것에 관련된 표시는 제2 데이터의 데이터 타입과 연관되며, 이 데이터 타입은 설명 데이터 타입 또는 콘텐츠 데이터 타입을 포함하고, 제2 데이터는 콘텐츠 데이터 또는 설명 데이터에 속한다.
실시예들에서, 제2 데이터를 푸시하는 것에 관련된 표시는 설명 데이터를 푸시하는 것에 관한 것이다.
실시예들에서, 제2 데이터를 푸시하는 것에 관련된 표시는 적어도 하나의 고유 식별자를 포함하고, 이 적어도 하나의 고유 식별자는 제2 데이터를 푸시하기 위한 지시 및 푸시될 제2 데이터의 식별을 나타내거나, 제2 데이터를 푸시하지 말라는 지시를 나타낸다.
실시예들에서, 고유 식별자는 중앙집중식 저장소에서 정의된다.
실시예들에서, 고유 식별자는 적어도 하나의 파라미터의 함수로서 설정된다.
본 발명의 또 다른 목적에 따르면, 클라이언트 디바이스에 의해 서버 디바이스로부터 데이터를 수신하는 방법이 제공되며, 이 방법은, 클라이언트 디바이스에서, 다음과 같은 단계들을 포함한다:
제1 데이터를 획득하라는 HTTP 요청을 전송 ―HTTP 요청은 서버 디바이스 상의 제1 데이터의 식별을 허용하는 제1 데이터 식별 정보를 포함하고, 하나 이상의 추가 헤더 필드를 포함함― 하는 단계;
클라이언트가, 서버 디바이스가 제1 데이터와는 상이한 임의의 제2 데이터를 푸시하기를 원하지 않는다면, HTTP 요청에 응답하여 서버 디바이스에 의해 임의의 제2 데이터가 푸시되기를 클라이언트가 원하지 않는다는 것을 나타내는 정보 항목을 하나 이상의 추가 헤더 필드 중 적어도 하나에 삽입하는 단계; 및
HTTP 요청을 서버 디바이스에 전송하는 단계.
따라서, 본 발명의 방법은 서버 디바이스로부터 클라이언트 디바이스로 푸시되는 쓸모없는 데이터의 전송을 방지한다.
실시예들에서, 임의의 제2 데이터가 서버에 의해 푸시되기를 클라이언트가 원하지 않는다는 것을 나타내는 정보는 적어도 하나의 고유 식별자를 포함하고, 이 적어도 하나의 고유 식별자는 제2 데이터를 푸시하지 말라는 지시를 나타낸다.
실시예들에서, 고유 식별자는 중앙집중식 저장소에서 정의된다.
실시예들에서, 고유 식별자는 적어도 하나의 파라미터의 함수로서 설정된다.
본 발명의 또 다른 목적에 따르면, 서버 디바이스로부터 클라이언트 디바이스로 데이터를 전송하는 방법이 제공되며, 이 방법은, 서버 디바이스에서, 다음과 같은 단계들을 포함한다 :
클라이언트 디바이스로부터, 제1 데이터를 획득하라는 HTTP 요청 ―HTTP 요청은 서버 디바이스 상의 제1 데이터의 식별을 허용하는 제1 데이터 식별 정보를 포함하고, 하나 이상의 추가 헤더 필드를 포함함― 을 수신하는 단계;
제1 데이터를 검색하여 클라이언트 디바이스에 전송하는 단계; 및
HTTP 요청에 응답하여 서버가 제1 데이터와는 상이한 임의의 제2 데이터를 푸시하지 않을 것임을 나타내는 정보 항목을 클라이언트에 전송하는 단계.
따라서, 본 발명의 방법은 서버 디바이스로부터 클라이언트 디바이스로 푸시되는 쓸모없는 데이터의 전송을 방지한다.
실시예들에서, 서버가 임의의 제2 데이터를 푸시하지 않을 것임을 나타내는 정보는 적어도 하나의 고유 식별자를 포함하고, 이 적어도 하나의 고유 식별자는 제2 데이터를 푸시하지 말라는 지시를 나타낸다.
실시예들에서, 고유 식별자는 중앙집중식 저장소에서 정의된다.
실시예들에서, 고유 식별자는 적어도 하나의 파라미터의 함수로서 설정된다.
본 발명의 또 다른 목적에 따르면, 클라이언트 디바이스에 의해 서버 디바이스로부터 데이터를 수신하는 방법이 제공되며, 이 방법은, 클라이언트 디바이스에서, 다음과 같은 단계들을 포함한다:
제1 데이터를 획득하라는 HTTP 요청을 전송 ―HTTP 요청은 서버 디바이스 상의 제1 데이터의 식별을 허용하는 제1 데이터 식별 정보를 포함하고, 하나 이상의 추가 헤더 필드를 포함함― 하는 단계;
클라이언트가, 서버 디바이스가 제1 데이터와는 상이한 임의의 제2 데이터를 푸시하기를 원하지 않는다면, HTTP 요청에 응답하여 서버 디바이스에 의해 임의의 제2 데이터가 푸시되기를 클라이언트가 원하지 않는다는 것을 나타내는 정보 항목을 하나 이상의 추가 헤더 필드 중 적어도 하나에 삽입하는 단계;
HTTP 요청을 서버 디바이스에 전송하는 단계;
HTTP 요청을 전송하는 것에 응답하여, 서버 디바이스로부터 확인응답 데이터 ―확인응답 데이터는 서버가 제1 데이터와는 상이한 임의의 제2 데이터를 푸시하지 않을 것임을 나타내는 정보 항목을 포함함― 를 수신하는 단계.
따라서, 본 발명의 방법은 서버 디바이스로부터 클라이언트 디바이스로 푸시되는 쓸모없는 데이터의 전송을 방지한다.
실시예들에서, 임의의 제2 데이터가 서버에 의해 푸시되기를 클라이언트가 원하지 않는다는 것을 나타내는 정보는 적어도 하나의 고유 식별자를 포함하고, 이 적어도 하나의 고유 식별자는 제2 데이터를 푸시하지 말라는 지시를 나타낸다.
실시예들에서, 서버가 임의의 제2 데이터를 푸시하지 않을 것임을 나타내는 정보는 적어도 하나의 고유 식별자를 포함하고, 이 적어도 하나의 고유 식별자는 제2 데이터를 푸시하지 말라는 지시를 나타낸다.
실시예들에서, 고유 식별자는 중앙집중식 저장소에서 정의된다.
실시예들에서, 고유 식별자는 적어도 하나의 파라미터의 함수로서 설정된다. 본 발명의 또 다른 목적에 따르면, 서버 디바이스로부터 클라이언트 디바이스로 데이터를 전송하는 방법이 제공되며, 이 방법은, 서버 디바이스에서, 다음과 같은 단계들을 포함한다 :
클라이언트 디바이스로부터, 제1 데이터를 획득하라는 HTTP 요청 ―HTTP 요청은 서버 디바이스 상의 제1 데이터의 식별을 허용하는 제1 데이터 식별 정보를 포함하고, HTTP 요청에 응답하여 서버에 의해 임의의 제2 데이터가 푸시되는 것을 클라이언트가 원하지 않는다는 것을 나타내는 정보 항목을 포함하는 하나 이상의 추가 헤더 필드를 포함함― 을 수신하는 단계;
제1 데이터를 검색하여 클라이언트 디바이스에 전송하는 단계; 및
HTTP 요청에 응답하여 서버가 제1 데이터와는 상이한 임의의 제2 데이터를 푸시하지 않을 것임을 나타내는 정보 항목을 클라이언트에 전송하는 단계.
따라서, 본 발명의 방법은 서버 디바이스로부터 클라이언트 디바이스로 푸시되는 쓸모없는 데이터의 전송을 방지한다.
실시예들에서, 서버가 임의의 제2 데이터를 푸시하지 않을 것임을 나타내는 정보는 적어도 하나의 고유 식별자를 포함하고, 이 적어도 하나의 고유 식별자는 제2 데이터를 푸시하지 말라는 지시를 나타낸다.
실시예들에서, 임의의 제2 데이터가 서버에 의해 푸시되기를 클라이언트가 원하지 않는다는 것을 나타내는 정보는 적어도 하나의 고유 식별자를 포함하고, 이 적어도 하나의 고유 식별자는 제2 데이터를 푸시하지 말라는 지시를 나타낸다.
실시예들에서, 고유 식별자는 중앙집중식 저장소에서 정의된다.
실시예들에서, 고유 식별자는 적어도 하나의 파라미터의 함수로서 설정된다. 실시예들에서, 하나 이상의 추가 헤더 필드는 하나 이상의 선택사항적 헤더 필드이다.
실시예들에서, 제1 및 제2 데이터 식별 정보는 각각 제1 및 제2 URI(uniform resource identifier)를 포함한다.
실시예들에서, 하나 이상의 선택사항적 헤더 필드는 HTTP 요청의 콘텐츠로부터 제2 URI를 생성하는 적어도 하나의 구성 규칙(construction rule)을 포함한다.
실시예들에서, 하나 이상의 선택사항적 헤더 필드는 변동-부분 정보와 대체 정보를 포함하고, 변동-부분 정보는 기준 URI에서 적어도 하나의 변동하는 하위부분을 식별하고, 대체 정보는 기준 URI에서 식별된 변동하는 하위부분을 대체하여 제2 URI 또는 URI들을 정의하기 위한 적어도 하나의 대체 값을 포함한다.
실시예들에서, 기준 URI는 수신된 HTTP 요청에 포함된 제1 URI를 포함한다.
실시예들에서, 변동-부분 정보는, 대체 정보에 포함된 각각의 대체 값 또는 값들을 이용하여 대체하기 위한 기준 URI 내의 2개 이상의 하위부분을 식별한다.
실시예들에서, 변동-부분 정보는 각각의 우선순위 레벨을 기준 URI 내의 2개 이상의 하위부분 각각과 연관시켜 각각의 우선순위 레벨에 따라 2개 이상의 하위부분의 대체 값을 연속적으로 고려한다.
실시예들에서, 추가 헤더 필드는 명시적으로 제2 URI를 포함한다.
실시예들에서, 제1 데이터 식별 정보는 서버 디바이스 상의 메인 자원을 식별하는 제1 URI(uniform resource identifier)를 포함하며, 메인 자원의 하위부분을 제1 데이터로서 정의하는 하위부분 정보를 포함한다; 및
선택사항적 헤더 필드는 제2 데이터 식별 정보를 정의하도록 제1 데이터 식별 정보 내의 하위부분 정보를 대체하기 위한 대체 하위부분 정보를 포함한다.
실시예들에서, 하위부분 정보는 메인 자원 내의 바이트들의 범위 값을 포함한다.
실시예들에서, 제1 및 제2 데이터는, 각각, DASH 매니페스트 프리젠테이션 설명(DASH manifest presentation description)에서 제1 및 제2 데이터 식별 정보에 의해 식별된 미디어 세그먼트 또는 미디어 콘텐츠 하위부분이다.
본 발명의 또 다른 목적에 따르면, 서버 디바이스와 클라이언트 디바이스 사이에서 데이터를 전송하는 방법이 제공되고, 이 방법은, 서버 디바이스에서, 다음과 같은 단계들을 포함한다:
클라이언트 디바이스로부터, 제1 데이터를 획득하라는 HTTP 요청 ―HTTP 요청은 서버 디바이스 상의 제1 데이터의 식별을 허용하는 제1 데이터 식별 정보를 포함하고, 제2 데이터의 식별을 허용하는 하나 이상의 선택사항적 헤더 필드를 포함함― 을 수신하는 단계; 제1 데이터를 검색하여 클라이언트 디바이스에 전송하는 단계; 및 선택사항적 헤더 필드가 HTTP 요청 내에 존재한다면:
서버 디바이스 상의 제2 데이터의 식별을 허용하는 제2 데이터 식별 정보를, 선택사항적 헤더 필드 및 아마도 제1 데이터 식별 정보만을 이용하여, 즉, HTTP 요청의 콘텐츠만을 이용하여 결정하는 단계; 및
클라이언트 디바이스로의 제2 데이터의 푸시를 공지하는 푸시 약속 메시지를 전송하고/하거나 제2 데이터를 클라이언트 디바이스에 푸시하는 단계를 더 포함한다.
클라이언트의 관점에서, 본 발명은 서버 디바이스와 클라이언트 디바이스 사이에서 데이터를 전송하는 방법을 제공하며, 이 방법은, 클라이언트 디바이스에서, 다음과 같은 단계들을 포함한다:
서버 디바이스로부터 획득될 데이터를 식별하는 단계;
식별된 데이터로부터 제1 데이터를 획득하라는 HTTP 요청 ―HTTP 요청은 서버 디바이스 상의 제1 데이터의 식별을 허용하는 제1 데이터 식별 정보를 포함하고, 선택사항적 헤더 필드 및 아마도 제1 데이터 식별 정보에만(즉, HTTP 요청의 콘텐츠에만) 기초하여, 서버 디바이스 상의 식별된 데이터로부터 제2 데이터의 식별을 허용하는 제2 데이터 식별 정보를 정의하는 하나 이상의 선택사항적 헤더 필드를 포함함― 을 생성하는 단계;
제1 데이터를 획득하고 제2 데이터를 푸시하도록 서버 디바이스를 구동하기 위해 HTTP 요청을 서버 디바이스에 전송하는 단계.
상관적으로, 본 발명은 클라이언트 디바이스와 데이터를 교환하기 위한 서버 디바이스를 제공하며, 이 디바이스는 다음의 단계들을 실행하도록 구성된 적어도 하나의 마이크로프로세서를 포함한다:
클라이언트 디바이스로부터, 제1 데이터를 획득하라는 HTTP 요청을 수신 ―HTTP 요청은 서버 디바이스 상의 제1 데이터의 식별을 허용하는 제1 데이터 식별 정보를 포함하고, 제2 데이터의 식별을 허용하는 하나 이상의 선택사항적 헤더 필드를 포함함― 하는 단계;
제1 데이터를 검색하여 클라이언트 디바이스에 전송하는 단계; 및
선택사항적 헤더 필드가 HTTP 요청에 존재한다면 :
서버 디바이스 상의 제2 데이터의 식별을 허용하는 제2 데이터 식별 정보를, 선택사항적 헤더 필드 및 아마도 제1 데이터 식별 정보만을 이용하여 결정하는 단계;
클라이언트 디바이스로의 제2 데이터의 푸시를 공지하는 푸시 약속 메시지를 전송하고/하거나 제2 데이터를 클라이언트 디바이스에 푸시하는 단계를 더 포함한다.
또한, 본 발명은 서버 디바이스와 데이터를 교환하기 위한 클라이언트 디바이스를 제공하며, 이 디바이스는 다음의 단계들을 실행하도록 구성된 적어도 하나의 마이크로프로세서를 포함한다:
서버 디바이스로부터 획득될 데이터를 식별하는 단계;
식별된 데이터로부터 제1 데이터를 획득하라는 HTTP 요청 ―HTTP 요청은 서버 디바이스 상의 제1 데이터의 식별을 허용하는 제1 데이터 식별 정보를 포함하고, 선택사항적 헤더 필드 및 아마도 제1 데이터 식별 정보에만 기초하여, 서버 디바이스 상의 식별된 데이터로부터 제2 데이터의 식별을 허용하는 제2 데이터 식별 정보를 정의하는 하나 이상의 선택사항적 헤더 필드를 포함함― 을 생성하는 단계;
제1 데이터를 획득하고 제2 데이터를 푸시하도록 서버 디바이스를 구동하기 위해 HTTP 요청을 서버 디바이스에 전송하는 단계.
HTTP/2에서, 푸시 약속 메시지는 대응하는 데이터의 실제 푸시에 선행한다. 다른 프로토콜들, 특히 Web Sockets 또는 SPDY(SPeeDY의 약어) 등의 양방향 프로토콜은 앞선 푸시 공지없이 제2 데이터를 직접 푸시할 수 있다.
본 발명의 덕택에, 클라이언트 디바이스는 서버 디바이스에 의한 푸시 메커니즘을 효율적으로 제어하면서 하위 호환성(backward compatibility)을 가능하게 한다. 이것은 푸시 데이터와 클라이언트 요구 사이의 불일치를 감소시킨다. 이것은, 클라이언트 디바이스가 푸시되기를 원하는 제2 데이터(자원 또는 자원의 일부)가 종래의 HTTP 요청의 선택사항적 헤더 필드를 이용하여 정의되기 때문이다. 또한, 하위 호환성은, 서버 디바이스가 종래의 것이라면, 즉, 선택사항적 헤더 필드를 지원하지 않는다면, 서버 디바이스는 처리 에러없이 종래의 방식으로 HTTP 요청을 여전히 처리할 수 있다는 사실로부터 비롯된다.
선택사항적 헤더 필드를 인식하지만 푸시 기능을 지원하지 않는 서버의 경우, 서버는, 서버가 콘텐츠 서버가 아니고 릴레이 서버인 경우, 선택사항적 헤더 필드로부터의 정보를 이용하여 자원을 미리 가져올 수 있다.
또한, 본 발명은, 예를 들어 DASH 지식이 없는 저숙련 서버에 의존하는 것을 가능하게 한다. 이것은, 푸시될 제2 데이터의 식별이 MPD 파일 등이 처리될 것을 요구하지 않기 때문이다. 본 발명에 따르면, 선택사항적 헤더 필드 및 아마도 제1 데이터 식별 정보만이 이러한 식별을 수행하는데 이용된다.
따라서, 본 발명의 실시예는, 클라이언트-주도형 서버 푸시 접근법을 포함한, 서버-가이드형 스트리밍을 위한 경량의 메커니즘을 제공한다. 실시예들은 DASH 네트워크의 정황에서 구현될 수 있다.
본 발명의 실시예들은 기존 HTTP/2 기능과 호환가능하다. 이러한 특징들은 본 발명의 실시예들을 구현하는데 유익하게 이용될 수 있다.
네트워크 성능이 전반적으로 향상된다.
방법 및 디바이스의 선택사항적 특징들은 종속항에서 정의된다. 이들 중 일부는 방법과 관련하여 이하에서 설명된다. 그러나 이들은 대응하는 디바이스에도 적용될 수 있다.
한 실시예에서, 제1 및 제2 데이터 식별 정보는 각각 제1 및 제2 URI(uniform resource identifier)를 포함한다.
특정한 실시예에서, 하나 이상의 선택사항적 헤더 필드는 HTTP 요청의 콘텐츠로부터 제2 URI를 생성하는 적어도 하나의 구성 규칙(construction rule)을 포함한다. 즉, 선택사항적 헤더 필드는 구성 규칙을 이용하여 제2 URI 또는 URI들을 묵시적으로 정의한다. 앞서 추론된 바와 같이, 구성 규칙은 선택사항적 헤더 필드와 아마도 제1 URI만을 이용하여 제2 URI 또는 URI들을 획득한다.
예를 들어, 하나 이상의 선택사항적 헤더 필드는 변동-부분 정보와 대체 정보를 포함하고, 변동-부분 정보는 기준 URI에서 적어도 하나의 변동하는 하위부분을 식별하고, 대체 정보는 기준 URI에서 식별된 변동 하위부분을 대체하여 제2 URI 또는 URI들을 정의하기 위한 적어도 하나의 대체 값을 포함한다. 따라서, 이 규정은 구성 규칙이 어떻게 이용될 수 있는지를 정의한다.
특정한 특징에 따르면, 기준 URI는, 수신된 HTTP 요청에 포함된 제1 URI를 포함한다. 환언하면, 구성 규칙(대체 프로세스)은, 제1 URI, 즉, 요청된 제1 데이터의 URI에 적용된다. 이것은, (일반적일 수 있는) 구성 규칙이 요청된 제1 데이터로부터 푸시될 제2 데이터를 유추하지만, HTTP 요청의 콘텐츠만을 이용한다는 것을 의미한다.
또 다른 특정한 특징에 따르면, 변동-부분 정보는, 대체 정보에 포함된 각각의 대체 값 또는 값들을 이용하여 대체하기 위한 기준 URI 내의 2개 이상의 하위부분을 식별한다. 따라서, 복잡한 제2 URI들이 제1 URI로부터 생성될 수 있다.
역시 또 다른 특정한 특징에 따르면, 변동-부분 정보는 각각의 우선순위 레벨을 기준 URI 내의 2개 이상의 하위부분 각각과 연관시켜 각각의 우선순위 레벨에 따라 2개 이상의 하위부분의 대체 값을 연속적으로 고려한다. 이러한 규정 덕택에, 클라이언트 디바이스는 제2 URI들을 주문하고 그에 따라 제2 데이터가 서버 디바이스에 의해 푸시되는 순서를 구동한다.
일부 실시예들에서, 선택사항적 헤더 필드는 명시적으로 제2 URI를 포함한다. 이것은, 예를 들어 구성 규칙을 이용한 제2 URI 또는 URI들의 묵시적 정의와는 상반된다.
다른 실시예들에서, 제1 데이터 식별 정보는 서버 디바이스 상의 메인 자원을 식별하는 제1 URI(uniform resource identifier)를 포함하며, 메인 자원의 하위부분을 제1 데이터로서 정의하는 하위부분 정보를 포함한다; 및
선택사항적 헤더 필드는 제2 데이터 식별 정보를 정의하도록 제1 데이터 식별 정보 내의 하위부분 정보를 대체하기 위한 대체 하위부분 정보를 포함한다.
하위부분 정보의 예는 DASH에서 이용되는 Range 파라미터이다. 이 예에서, 하위부분 정보는 메인 자원 내의 바이트들의 범위 값을 포함한다.
실시예들에 따르면, 제1 및 제2 데이터는, 각각, DASH 매니페스트 프리젠테이션 설명(DASH manifest presentation description)에서 제1 및 제2 데이터 식별 정보에 의해 식별된 미디어 세그먼트 또는 미디어 콘텐츠 하위부분이다. DASH의 URI는 대개 전체 미디어 세그먼트를 식별하는 반면, DASH Range 파라미터를 이용하는 것은 미디어 콘텐츠/세그먼트 하위부분을 식별하는 것을 가능하게 한다는 점에 유의한다.
공지된 종래 기술에 비해, 클라이언트 디바이스가 서버 푸시 기능을 구동 또는 가이드하는 것을 도울 필요성이 역시 있다. 이러한 정황에서, 본 발명은 또한, 서버 디바이스와 클라이언트 디바이스 사이에서 데이터를 전송하는 방법을 제공하며, 이 방법은, 서버 디바이스에서, 다음과 같은 단계들을 포함한다:
클라이언트 디바이스로부터, 제1 데이터를 획득하라는 HTTP 요청 ―HTTP 요청은 하나 이상의 필터링 파라미터를 포함하는 제1 선택사항적 헤더 필드를 포함함― 을 수신하는 단계;
제1 데이터를 검색하여 클라이언트 디바이스에 전송하는 단계; 및
제1 선택사항적 헤더 필드가 HTTP 요청에 존재한다면:
HTTP 요청으로부터 획득된 메인 자원을 이용하여 데이터 세트를 식별하는 단계;
하나 이상의 필터링 파라미터를 이용하여 식별된 세트의 각각의 데이터를 필터링하여 제2 데이터의 목록을 획득하는 단계; 및
제2 데이터를 클라이언트 디바이스에 푸시하는 단계.
푸시 약속 기능을 포함하는 프로토콜에서, 이 방법은, 제2 데이터를 푸시하기 전에, 푸시 약속 메시지를 전송하여 제2 데이터의 푸시를 클라이언트 디바이스에 공지하는 단계를 더 포함한다.
클라이언트의 관점에서, 본 발명은 서버 디바이스와 클라이언트 디바이스 사이에서 데이터를 전송하는 방법을 제공하며, 이 방법은, 클라이언트 디바이스에서, 다음과 같은 단계들을 포함한다 : 제1 데이터를 획득하라는 HTTP 요청 ―HTTP 요청은 하나 이상의 필터링 파라미터를 포함하는 제1 선택사항적 헤더 필드를 포함함― 을 생성하는 단계;
제1 데이터를 획득하고 필터링 파라미터들에 따라 HTTP 요청으로부터 추론된 메인 자원에서 참조되는 제2 데이터를 푸시하도록 서버 디바이스를 구동하기 위해 HTTP 요청을 서버 디바이스에 전송하는 단계.
하나 이상의 필터링 파라미터는:
자원 타입을 정의하고; 자원 타입 또는 타입들은 애플리케이션 타입, 텍스트 타입, 이미지 타입, 비디오 타입, 오디오 타입 중 하나 이상의 타입을 포함한다; 또는 DASH 미디어 프리젠테이션 설명 내의 요소들의 식별자들을 이용하여 하나 이상의 데이터 그룹을 식별한다; 또는
메인 자원의 하위부분을 식별하는 시간 범위들을 이용하여 제1 선택사항적 헤더 필드에서 정의된다.
또한, 푸시 약속 메시지가 수신될 수 있다.
상관적으로, 본 발명은 클라이언트 디바이스와 데이터를 교환하기 위한 서버 디바이스를 제공하며, 이 디바이스는 다음의 단계들을 실행하도록 구성된 적어도 하나의 마이크로프로세서를 포함한다:
클라이언트 디바이스로부터, 제1 데이터를 획득하라는 HTTP 요청 ―HTTP 요청은 하나 이상의 필터링 파라미터를 포함하는 제1 선택사항적 헤더 필드를 포함함― 을 수신하는 단계;
제1 데이터를 검색하여 클라이언트 디바이스에 전송하는 단계; 및
제1 선택사항적 헤더 필드가 HTTP 요청에 존재한다면:
HTTP 요청으로부터 획득된 메인 자원을 이용하여 데이터 세트를 식별하는 단계;
하나 이상의 필터링 파라미터를 이용하여 식별된 세트의 각각의 데이터를 필터링하여 제2 데이터의 목록을 획득하는 단계; 및
제2 데이터를 클라이언트 디바이스에 푸시하는 단계.
하나 이상의 필터링 파라미터는:
자원 타입을 정의하고; 자원 타입 또는 타입들은 애플리케이션 타입, 텍스트 타입, 이미지 타입, 비디오 타입, 오디오 타입 중 하나 이상의 타입을 포함한다; 또는 DASH 미디어 프리젠테이션 설명 내의 요소들의 식별자들을 이용하여 하나 이상의 데이터 그룹을 식별한다; 또는
메인 자원의 하위부분을 식별하는 시간 범위들을 이용하여 제1 선택사항적 헤더 필드에서 정의된다.
또한, 본 발명은 서버 디바이스와 데이터를 교환하기 위한 클라이언트 디바이스를 제공하며, 이 디바이스는 다음의 단계들을 실행하도록 구성된 적어도 하나의 마이크로프로세서를 포함한다:
제1 데이터를 획득하라는 HTTP 요청 ―HTTP 요청은 하나 이상의 필터링 파라미터를 포함하는 제1 선택사항적 헤더 필드를 포함함― 을 생성하는 단계;
제1 데이터를 획득하고 필터링 파라미터들에 따라 HTTP 요청으로부터 추론된 메인 자원에서 참조되는 제2 데이터를 푸시하도록 서버 디바이스를 구동하기 위해 HTTP 요청을 서버 디바이스에 전송하는 단계.
이 접근법의 예시적인 예시는 메인 HTML 웹 페이지를 제1 데이터로서 요청하는 것이다. 그 다음, 선택사항적 헤더 필드는 HTML 페이지에서 참조된 하위자원의 타입 또는 타입들을 푸시해야하는지를 정의할 수 있다. 따라서 선택사항적 헤더 필드는 필터링 파라미터로서 작용한다. 예를 들어, 이것은, jpg 이미지들의 부분집합만을 푸시하기 위하여 하위자원들을 필터링하는 필터링 파라미터 "images/*.jpg"를 제공할 수 있다.
선택사항적 헤더 필드를 통한, 요청에 의해 식별된 데이터에 적용할 필터링 파라미터의 이용을 통해, 클라이언트 디바이스에 의한 서버 푸시 기능의 향상된 제어가 획득된다.
다시 한번, 이러한 선택사항적 헤더 필드의 이용은 서버측에서의 하위 호환성을 허용한다.
따라서, 본 발명의 실시예는, 클라이언트-주도형 서버 푸시 접근법을 포함한, 서버-가이드형 스트리밍을 위한 경량의 메커니즘을 제공한다. 실시예들은 DASH 네트워크의 정황에서 구현될 수 있다.
본 발명의 실시예들은 기존 HTTP/2 기능과 호환가능하다. 이러한 특징들은 본 발명의 실시예들을 구현하는데 유익하게 이용될 수 있다.
네트워크 성능이 전반적으로 향상된다.
방법 및 디바이스의 선택사항적 특징들은 종속항에서 정의된다. 이들 중 일부는 방법과 관련하여 이하에서 설명된다. 그러나 이들은 대응하는 디바이스에도 적용될 수 있다.
실시예들에서, 메인 자원은 제1 데이터이다. 이것은, HTTP 요청만으로 서버 디바이스가 푸시될 모든 제2 데이터를 효율적으로 식별할 수 있다는 것을 의미한다. 서버 디바이스는, 전술된 종래 기술의 경우에서와 같이 DASH 지식 등의 추가 지식을 요구하지 않는다. 따라서, 덜 숙련된 서버 디바이스가 이용될 수 있다.
다른 실시예들에서, HTTP 요청은, 서버 디바이스 상의 메인 자원을 식별하는 URI(uniform resource identifier)를 정의하는 제2 선택사항적 헤더 필드를 포함한다. 이러한 실시예는, 클라이언트 디바이스가 메인 자원을 먼저 획득하고, 메인 자원으로부터 적절한 제2 데이터를 실제로 선택하는 필터링 파라미터를 식별(및 선택사항적 헤더 필드를 이용하여 정의)하기 위하여 메인 자원을 분석할 것이 필요할 때 구현될 수 있다. 사실상, 이러한 경우, 클라이언트 디바이스는, 메인 자원의 콘텐츠에 아직 액세스하지 않았기 때문에 메인 자원을 요청할 때 필터링 파라미터를 정의할 수 없다.
이 규정 덕택에, 클라이언트는, 자원 타입별 자원들의 목록을 정의할 수 있는 서버에 저장된 정적 구성 파일(static configuration file)을 지정할 수 있다. 이러한 정적 구성 파일을 이용하는 것은, 자원 타입 필터링 파라미터들에 기초하여 자원을 식별하기 위해 저숙련 서버를 요구한다.
역시 또 다른 실시예들에서, 2개(또는 그 이상)의 필터링 파라미터는 2개(또는 그 이상)의 각각의 데이터 그룹 및 2개의 각각의 우선순위 레벨과 연관된다; 필터링 단계는 제2 데이터의 정렬된 목록을 획득하기 위해 각각의 데이터가 속한 그룹들의 우선순위 레벨에 따라 제2 데이터를 순서대로 정렬한다; 푸시 단계는 정렬된 목록에 따라 제2 데이터를 푸시한다. 클라이언트 측에서는, 2개의 필터링 파라미터가 2개의 데이터 그룹 및 2개의 우선순위 레벨과 연관된다는 것을 의미한다; 제2 데이터는 자신이 속하는 그룹의 우선순위 레벨에 따라 순서대로 수신된다. 이것은, 클라이언트 디바이스가 푸시된 데이터를 수신하기를 원하는 순서를 효율적으로 구동하는 것을 가능하게 한다.
역시 또 다른 실시예들에서, 각각의 필터링 파라미터는 자원 타입을 정의한다; 자원 타입 또는 타입들은, 애플리케이션 타입(예를 들어, 자바스크립트), 텍스트 타입(예를 들어, CSS 또는 HTML), 이미지 타입(예를 들어, png 또는 jpg), 비디오 타입(예를 들어, mp4 또는 webm) 오디오 타입(예를 들어, mp3 또는 wav)으로부터의 하나 이상의 타입을 포함한다.
이 규정은 특히, 웹 페이지 로딩 등의, html 또는 그 유사한 것의 교환에 적용된다. 물론, 임의의 이러한 자원 타입을 세분화하면 특정한 콘텐츠(예를 들어, 이미지 또는 Javascript 함수와 같은 내장된 함수)의 로딩을 효율적으로 구동하는데 도움이 될 수 있다.
역시 또 다른 실시예들에서, 제1 선택사항적 헤더 필드 내의 하나 이상의 필터링 파라미터는, DASH 미디어 프리젠테이션 설명 내의 요소들의 식별자를 이용하여 하나 이상의 데이터 그룹을 식별한다. 이러한 요소들은, DASH MPD의 AdaptationSet 요소, Presentation 요소 또는 Segment 요소를 포함할 수 있다. 한 실시예에서, HTTP 요청에 의해 요청된 제1 데이터는 DASH MPD이다. 물론, 한 변형 예에서, DASH MPD는 전술된 제2 선택사항적 헤더 필드에서 명시될 수 있다.
이 규정은 클라이언트 디바이스가 MPD에 의해 정의된 미디어 콘텐츠의 일부 부분들의 푸시를 제어하는 것을 가능하게 한다.
역시 또 다른 실시예들에서, 하나 이상의 필터링 파라미터는, 메인 자원의 하위부분을 식별하는 시간 범위들, 예를 들어 DASH 요청에서 이용된 시간 범위를 이용하여 제1 선택사항적 헤더 필드에서 정의된다. 이전 조항과 마찬가지로, 이것을 통해 클라이언트 디바이스는 DASH를 이용하여 스트리밍된 미디어 콘텐츠의 하위부분이 서버 디바이스에 의해 푸시되는 방법을 제어할 수 있다.
본 발명의 또 다른 양태는, 디바이스의 마이크로프로세서 또는 컴퓨터 시스템에 의해 실행될 때, 디바이스로 하여금 앞서 정의된 임의의 방법을 수행하게 하는 프로그램을 저장한 비일시적 컴퓨터 판독가능한 매체에 관한 것이다.
비일시적 컴퓨터 판독가능한 매체는, 방법 및 디바이스와 관련하여 상기 및 하기에서 설명된 것과 유사한 특징 및 이점들, 특히, 서버 푸시 기능 및 저숙련 서버 디바이스의 클라이언트 제어를 향상시키는 특징 및 이점들을 가질 수 있다.
본 발명의 역시 또 다른 양태는, 앞서 정의된 임의의 방법의 각각의 단계를 실행하기 위해 구성된 수단을 포함하는 디바이스에 관한 것이다.
본 발명의 또 다른 양태는, 실질적으로 첨부된 도면들 중 도 3a 또는 도 3b 또는 도 5a 또는 도 5b 또는 도 6a 또는 도 7b 또는 도 8을 참조하여 도시되고 설명된 바와 같이, 서버 디바이스와 클라이언트 디바이스 사이에서 자원을 전송하는 방법에 관한 것이다.
본 발명에 따른 방법들의 적어도 일부는 컴퓨터로 구현될 수 있다. 따라서, 본 발명은, 완전히 하드웨어 실시예, (펌웨어, 상주 소프트웨어, 마이크로-코드 등을 포함한) 완전히 소프트웨어 실시예, 또는 여기서는 "회로", "모듈" 또는 "시스템"이라 부를 수 있는 소프트웨어 및 하드웨어 양태를 결합한 실시예의 형태를 취할 수 있다. 또한, 본 발명은, 매체에 구현된 컴퓨터 이용가능한 프로그램 코드를 갖는 표현의 임의의 유형 매체(tangible medium)로 구현된 컴퓨터 프로그램 제품의 형태를 취할 수도 있다.
본 발명은 소프트웨어로 구현될 수 있으므로, 본 발명은, 임의의 적합한 캐리어 매체 상에서 프로그램가능한 장치에 제공하기 위한 컴퓨터 판독가능한 코드로서 구현될 수 있다. 유형 캐리어 매체는, 플로피 디스크, CD-ROM, 하드 디스크 드라이브, 자기 테이프 디바이스 또는 고체 메모리 디바이스 등의 저장 매체를 포함할 수 있다. 일시적인 캐리어 매체는, 전기 신호, 전자 신호, 광 신호, 음향 신호, 자기 신호, 또는 전자기 신호, 예를 들어, 마이크로파 또는 RF 신호 등의, 신호를 포함할 수 있다.
본 발명의 다른 특징 및 이점들은 첨부된 도면을 참조하여 비제한적인 예시적인 실시예에 대한 이하의 설명으로부터 명백해질 것이다 :
도 1a는, 그래프를 이용하여, 웹 페이지 등의 메인 자원에 상호링크된 자원 세트를 나타낸다;
도 1b 및 도 1c는, 각각, 푸시 기능을 이용하지 않는 그리고 푸시 기능을 이용하는, 도 1a의 메인 자원의 로딩을 나타낸다;
도 1d는 푸시 기능이 구현될 때 클라이언트 디바이스의 종래의 단계들을 플로차트를 이용하여 나타낸다;
도 1e는 푸시 기능이 구현될 때 서버 디바이스의 종래의 단계들을 플로차트를 이용하여 나타낸다;
도 2는 웹 페이지를 로딩하기 위한 HTTP 교환을 나타낸다;
도 3은 종래 기술에 따른 DASH-지향형 클라이언트-서버 시스템을 나타낸다;
도 3a는 본 발명의 실시예들이 구현될 수 있는 클라이언트-서버 시스템을 나타낸다;
도 3b는 본 발명의 실시예들이 구현될 수 있는 DASH-지향형 클라이언트-서버 시스템을 나타낸다;
도 4a는 미디어 프리젠테이션의 구축을 나타낸다;
도 4b는 DASH 미디어 프리젠테이션 설명, MPD, 파일의 구조를 나타낸다;
도 5a는 도 3a의 시스템에서 클라이언트의 거동을 나타내는 주요 단계들을 도시한다;
도 5b는 도 3b의 시스템에서의 스트리밍-지향형 클라이언트의 거동을 나타내는 주요 단계들을 도시한다;
도 6a는 도 3a 또는 도 3b의 시스템에서의 서버의 거동을 나타내는 주요 단계들을 도시한다;
도 6b는 본 발명에 따른 푸시 헤더의 예시적인 구조를 나타낸다;
도 7a는 SegmentTemplate을 갖는 예시적인 MPD 파일을 나타낸다;
도 7b는 도 7a의 MPD 파일에 기초하여 본 발명을 구현하는 클라이언트-서버 교환을 나타낸다;
도 8은 DASH 스트리밍의 정황에서 본 발명에 따른 푸시 헤더들의 예들을 나타낸다;
도 9는 실시예들에 따른 디바이스들의 개략도이다;
도 10은 수 개 레벨에서의 템플릿 URI들의 선언을 나타내는 MPD 샘플을 도시한다;
도 11a 내지 도 11e는 서버 내에서 푸시 정책 통보를 확인응답하는 예들을 나타낸다;
도 12a 및 도 12b는 고유 식별자들에 기초하여 클라이언트와 서버 사이에서 푸시 정책들에 관한 정보를 교환하는 예를 나타낸다.
도 1a는, 그래프를 이용하여, 웹 페이지 등의 메인 자원에 상호링크된 자원 세트를 나타낸다;
도 1b 및 도 1c는, 각각, 푸시 기능을 이용하지 않는 그리고 푸시 기능을 이용하는, 도 1a의 메인 자원의 로딩을 나타낸다;
도 1d는 푸시 기능이 구현될 때 클라이언트 디바이스의 종래의 단계들을 플로차트를 이용하여 나타낸다;
도 1e는 푸시 기능이 구현될 때 서버 디바이스의 종래의 단계들을 플로차트를 이용하여 나타낸다;
도 2는 웹 페이지를 로딩하기 위한 HTTP 교환을 나타낸다;
도 3은 종래 기술에 따른 DASH-지향형 클라이언트-서버 시스템을 나타낸다;
도 3a는 본 발명의 실시예들이 구현될 수 있는 클라이언트-서버 시스템을 나타낸다;
도 3b는 본 발명의 실시예들이 구현될 수 있는 DASH-지향형 클라이언트-서버 시스템을 나타낸다;
도 4a는 미디어 프리젠테이션의 구축을 나타낸다;
도 4b는 DASH 미디어 프리젠테이션 설명, MPD, 파일의 구조를 나타낸다;
도 5a는 도 3a의 시스템에서 클라이언트의 거동을 나타내는 주요 단계들을 도시한다;
도 5b는 도 3b의 시스템에서의 스트리밍-지향형 클라이언트의 거동을 나타내는 주요 단계들을 도시한다;
도 6a는 도 3a 또는 도 3b의 시스템에서의 서버의 거동을 나타내는 주요 단계들을 도시한다;
도 6b는 본 발명에 따른 푸시 헤더의 예시적인 구조를 나타낸다;
도 7a는 SegmentTemplate을 갖는 예시적인 MPD 파일을 나타낸다;
도 7b는 도 7a의 MPD 파일에 기초하여 본 발명을 구현하는 클라이언트-서버 교환을 나타낸다;
도 8은 DASH 스트리밍의 정황에서 본 발명에 따른 푸시 헤더들의 예들을 나타낸다;
도 9는 실시예들에 따른 디바이스들의 개략도이다;
도 10은 수 개 레벨에서의 템플릿 URI들의 선언을 나타내는 MPD 샘플을 도시한다;
도 11a 내지 도 11e는 서버 내에서 푸시 정책 통보를 확인응답하는 예들을 나타낸다;
도 12a 및 도 12b는 고유 식별자들에 기초하여 클라이언트와 서버 사이에서 푸시 정책들에 관한 정보를 교환하는 예를 나타낸다.
위에서 간략하게 소개된 바와 같이, 본 발명은 HTTP 통신 네트워크를 통한 데이터 전송에 관한 것이다. 응용 예는 DASH 등의 적응형 데이터 스트리밍이다.
HTTP는, 웹 자원, 통상적으로 웹 페이지를 전송하는데 이용되는 프로토콜이다. HTTP는 클라이언트와 서버를 암시한다:
클라이언트는 서버에 요청을 전송하고, 요청은 "요청_라인(request_line)"으로 구성되며 선택사항으로서 상이한 종류의 "헤더들"이 후속된다. "request-line"은 대개, 아마도 Range 헤더 등과 함께, 서버 상의 요청된 자원 또는 데이터를 식별하는 "Request-URI" 파라미터와 함께 메소드(예를 들어, "GET")를 포함한다.
서버는 웹 자원의 표현을 포함하는 응답과 함께 클라이언트의 요청에 응답한다.
요청 및 응답은, 다양한 부분들, 특히 HTTP 헤더를 포함하는 메시지이다. HTTP 헤더는, 값과 함께 명칭을 포함한다. 예를 들어 "Host : en.wikipedia.org"를 고려하면, "Host"는 헤더 명칭이고, 그 값은 "en.wikipedia.org"이다. 이것은 질의된 자원의 호스트를 나타내는데 이용된다(예를 들어, HTTP를 설명하는 Wikipedia 페이지는 HTTP://en.wikipedia.org/wiki/HTTP에서 이용가능하다). HTTP 헤더는 클라이언트 요청 및 서버 응답에서 나타난다다.
HTTP의 새로운 버전인 HTTP/2는 스트림을 통해 요청/응답을 교환할 수 있다. 스트림은, HTTP/2 접속 내에서 HTTP 요청 및 응답 교환마다 생성된다. 요청과 응답의 콘텐츠, 의사-헤더 및 헤더를 전달하기 위하여 스트림 내에서 프레임들이 교환된다.
HTTP/2는 다음과 같은 상이한 의미를 갖는 제한된 프레임 세트를 정의한다:
-HEADERS : HTTP 헤더의 전송을 위해 제공된다
o HTTP/2는 더 엄격한 규칙을 따르는 의사-헤더로부터 헤더(선택 사항, 즉, 처리 디바이스에서 이해할 수 없을 때 무시됨)를 구분한다. 후자는 HTTP 메소드와 request-URI를 나타내기 위해 이전 HTTP 버전들에서 정의된 요청-라인(request-line)의 맵핑에 대응한다. 현재 문서에서 "HTTP 헤더" 또는 "헤더"는 명시적으로 지정되는 의사-헤더가 아닌 선택사항적 헤더를 지정하기 위한 것이다.
o 또한, 현재의 문서에서, "Request-URI"는, RFC2616에 정의된 Request-URI(즉 "request-line"에서 이용된 서버 상의 요청된 자원을 식별하는 파라미터) 또는 HTTP/2 의사-헤더로의 그 균등물/변환물을 지정하기 위한 것이다.
- DATA : HTTP 메시지 콘텐츠의 전송을 위해 제공된다.
- PUSH_PROMISE : 푸시된 콘텐츠를 공지하기 위해 제공된다.
- PRIORITY : 스트림의 우선순위를 설정하기 위해 제공된다.
- WINDOW_UPDATE : 제어 흐름 윈도우의 값을 업데이트하기 위해 제공된다.
- SETTINGS : 구성 파라미터를 전달하기 위해 제공된다.
- CONTINUATION : 헤더 블록 조각들의 시퀀스를 계속하기 위해 제공된다.
- RST_STREAM: 스트림을 종료 또는 취소하기 위해 제공된다.
HTTP/2에서, 요청은 제1 HEADER 프레임 + 하나 이상의 DATA 프레임으로 변환되고, 여기서, HTTP/1.x의 요청-라인은 HTTP/2 명세에서 설명된 의사-헤더 필드로 변환된다.
본 설명은, 클라이언트로부터 서버에 전송되는 메시지를 지정하기 위해 "요청"또는 "HTTP 요청"을 이용하고, 서버로부터 클라이언트의 메시지를 지정하기 위해 응답" 또는 "HTTP 응답"을 이용한다. 요청 및 응답 외에도, 서버에서 개시되는 클라이언트로의 메시지에 대응하는 통보 또는 서버 통보에 대해서도 설명한다. 이 표현법은 HTTP/1.x 및 HTTP/2와 호환된다.
요청되지 않은 웹 자원 표현을 서버가 클라이언트에 전송하는 것을 허용하기 위해 HTTP/2에서 서버에 의해 푸시가 도입되었다. 웹 페이지 등의 웹 자원은 일반적으로 다른 자원으로의 링크를 포함하며, 자원들 그 자체는 다른 자원으로의 링크를 포함할 수 있다. 웹 페이지를 완전히 디스플레이하기 위해, 모든 링크된 및 하위-링크된 자원들이 클라이언트에 의해 검색될 필요가 있다. 이 증분적 검색은, 특히 모바일 네트워크 등의 높은 레이턴시의 네트워크에서, 웹 페이지의 느린 디스플레이로 이어질 수 있다.
주어진 웹 페이지에 대한 요청을 수신할 때, 서버는 요청된 자원의 전체 처리를 위해 어떤 다른 자원이 필요한지를 알 수 있다. 요청된 자원 및 링크된 자원을 동시에 전송함으로써, 서버는 웹 페이지의 로딩 시간의 감소를 허용한다. 따라서, 푸시 기능을 이용하여, 서버는 주어진 자원이 요청될 때 추가 자원 표현을 전송할 수 있다.
링크된 자원의 예로서, 도 1a는 서버가 소유한 자원 세트의 그래프를 그들의 관계와 함께 보여준다. 자원 세트는 서로 얽혀 있다: R1, R2, R3 및 R4는 클라이언트가 적절하게 처리하기 위해 함께 다운로드할 필요가 있는 자원이다.
또한, 하위 자원 A 내지 H가 정의된다. 이들 하위 자원은 1, 2 또는 3개의 자원과 관련된다. 예를 들어, A는 R1에 링크되고, C는 R1, R2, 및 R4에 링크된다.
도 1e의 플로차트를 참조하여, 푸시 기능을 구현하는 서버의 예시적인 동작 모드가 설명된다.
단계 100 동안, 서버는 초기 요청을 수신한다. 그 다음, 서버는 단계 101 동안 응답의 일부로서 푸시할 자원을 식별하고 단계 102 동안 PUSH 약속 메시지를 클라이언트에 전송한다. 그 다음, 단계 103 동안 콘텐츠 응답의 전송을 시작한다. PUSH 약속 메시지는, 예를 들어, 도 1a에 도시된 종속성에 기초하여, 서버가 푸시할려고 계획하고 있는 다른 자원을 식별한다. 이들 메시지들은, 어떤 푸시된 자원이 전송될 것인지를 미리 클라이언트가 알 수 있도록 하기 위해 전송된다. 특히, 이것은, 클라이언트가 동시에 푸시되고 있는 자원 또는 푸시될 자원에 대한 요청을 전송하는 위험을 감소시킨다. 이러한 위험을 더욱 감소시키기 위하여, 서버는 푸시 약속에 기술된 자원을 참조하여 응답의 임의의 부분을 전송하기 이전에 푸시 약속 메시지를 전송해야 한다. 이것은 또한, 클라이언트가 약속된 자원을 원하지 않는다면 약속된 자원의 푸시 취소를 요청하는 것을 허용한다. 그 다음, 서버는 단계 104 동안에 응답 및 모든 약속된 자원을 전송한다. 프로세스는 단계 105 동안 종료한다.
도 1b와 도 1c는, 푸시 기능을 이용하지 않는 웹 페이지 로딩 및 푸시 기능을 이용한 웹 페이지 로딩을 나타낸다.
도 1b는 서버 PUSH 기능을 이용하지 않는 HTTP 교환을 도시한다: 클라이언트는 R1을 요청하고: 그 다음, R2, A, B, C 및 D를 발견하고 이들을 요청한다. 클라이언트는 이들을 수신한 후, R3, R4, F 및 G를 요청한다. 마지막으로 클라이언트는 H 및 I 하위 자원을 요청한다. 따라서, 모든 필요한 자원 : 자원 R1 내지 R4 및 하위 자원 A 내지 I에 대한 요청이 전송되어야 한다. 또한, 이 프로세스는 전체 자원 세트를 검색하기 위해 4회의 왕복을 요구한다.
도 1c는, 서버에 의한 직접 접속된 하위 자원의 푸시 기능을 이용하는 HTTP 교환을 나타낸다. R1을 요청한 후, 서버는 A, B, C 및 D를 전송하고 푸시한다. 클라이언트는 R2를 식별하고 이것을 요청한다. 서버는 R2를 전송하고 F와 G를 푸시한다. 마지막으로 클라이언트는 R3, R4를 식별하고 이들 자원을 요청한다. 서버는 R3, R4를 전송하고 H와 I를 푸시한다. 따라서 요청 수는 요소들 R1 내지 R4로 제한된다. 요소들 A 내지 I는 도 1a에 도시된 종속성에 기초하여 서버에 의해 클라이언트에 "푸시"됨으로써, 연관된 요청을 불필요하게 한다. 이 프로세스는 전체 자원 세트를 검색하는기 위해 3회의 왕복을 요구한다.
따라서, 도 1b 및 도 1c에 나타낸 바와 같이, 서버가 푸시 기능을 이용할 때, 어떤 자원을 그 하위 자원과 함께 로딩하는데 필요한 HTTP 왕복(요청 + 응답)의 횟수가 감소된다. 이것은 특히 모바일 네트워크 등의 레이턴시가 높은 네트워크의 경우에 유용하다.
자원 세트, 통상적으로, 웹 페이지와 그 하위 자원의 로딩 시간을 감소시키기 위하여, HTTP/2는 복수의 요청 및 응답 우선순위들을 병렬로 교환할 수 있다. 도 2에 나타낸 바와 같이, 웹 페이지는, JavaScript, 이미지 등의 수개의 자원의 다운로드를 요구할 수 있다. 초기 HTTP 교환(200) 동안, 클라이언트는 HTML 파일을 검색한다. 이 HTML 파일은, 2개의 JavaScript 파일(JS1, JS2), 2개의 이미지(IMG1, IMG2), 1개의 CSS 파일 및 1개의 HTML 파일에 대한 링크를 포함한다. 교환(201) 동안, 클라이언트는 각각의 파일에 대한 요청을 전송한다. 도 2의 교환(201)에서 주어지는 순서는 웹 페이지 순서에 기초한다 : 클라이언트는 링크가 발견되자마자 요청을 전송한다. 그 다음, 서버는 JS1, CSS, IMG1, HTML, IMG2 및 JS2에 대한 요청을 수신하고, 이들 요청들을 그 순서로 처리한다. 그 다음, 클라이언트는 이들 자원을 그 순서로 검색한다.
클라이언트는, 웹 페이지 설명(HTML 파일)에서 참조되는 하위 자원을 다운로드하기 위한 적절한 순서를 원할 수도 있다. 이러한 경우, 특히 이 순서를 이용하여 푸시 기능을 구현하기 위해 서버가 이 정보를 갖는 것이 가치가 클 수 있다.
도 1d의 플로차트는 푸시 기능이 구현될 때 클라이언트 측에서의 프로세스를 나타낸다.
클라이언트가 서버로부터 검색할 자원을 식별하면, 먼저 단계 106 동안 대응하는 데이터가 이미 그 캐시 메모리 내에 있는지의 여부를 체크한다. 자원이 이미 캐시 메모리 내에 존재하는 경우(예), 단계 107에서 자원이 검색된다. 캐싱된 데이터는, 이전 요청으로부터 검색된 데이터이거나 이전에 서버에 의해 푸시된 데이터일 수 있다. 캐시 메모리에 없는 경우(아니오), 클라이언트는 단계 108 동안 요청을 전송하고 서버의 응답을 기다린다.
서버로부터 프레임의 수신시, 클라이언트는 단계 109 동안 그 프레임이 PUSH 약속에 대응하는지의 여부를 체크한다. 데이터 프레임이 PUSH 약속에 대응한다면(예), 단계 110 동안, 클라이언트는 PUSH 약속을 처리한다. 이렇게 하기 위해, 클라이언트는 푸시될 자원을 식별한다. 클라이언트가 자원을 수신하기를 원하지 않는다면, 클라이언트는 에러 메시지를 서버에 전송하여 서버가 그 자원을 푸시하지 않게 할 수 있다. 그렇지 않으면, 클라이언트는 대응하는 푸시된 콘텐츠를 수신할 때까지 PUSH 약속을 저장한다. PUSH 약속은, 서버가 약속된 자원을 푸시하고 있는 동안 클라이언트가 그 약속된 자원을 요청하지 않도록 하는데 이용된다.
데이터 프레임이 PUSH 약속에 대응하지 않는 경우(아니오), 단계 111 동안, 그 프레임이 푸시된 데이터에 관련된 데이터 프레임인지 여부가 체크된다. 푸시된 데이터에 관련된 경우(예), 클라이언트는 단계 112 동안 푸시된 데이터를 처리한다. 푸시된 데이터는 클라이언트 캐시 내에 저장된다.
프레임이 푸시된 데이터에 관련된 데이터 프레임이 아닌 경우(아니오), 단계 113 동안, 프레임이 서버로부터 수신된 응답에 대응하는지가 검사된다. 프레임이 서버로부터의 응답에 대응하는 경우(예), 응답은 단계 114 동안 처리된다(예를 들어, 애플리케이션에 전송됨).
그렇지 않은 경우(아니오), 단계 115 동안 프레임이 응답의 종료를 식별하는지(예)의 여부가 체크된다. 이 경우, 프로세스는 단계 116 동안 종료된다. 그렇지 않으면, 프로세스는 단계 109로 되돌아 간다.
따라서, 클라이언트는 응답과 약속된 자원을 수신하는 것으로 보인다. 따라서, 검색된 웹 페이지를 디스플레이하는 브라우저 등의 애플리케이션에 의해 응답이 이용되는 동안 약속된 자원은 일반적으로 클라이언트 캐시에 저장된다. 클라이언트 애플리케이션이 푸시된 자원들 중 하나를 요청하면, 그 자원은 네트워크 지연을 초래하지 않고 클라이언트 캐시로부터 즉시 검색된다.
캐시 내의 푸시된 자원의 저장은 캐시 제어 지시를 이용하여 제어된다. 캐시 제어 지시는 응답의 제어에도 이용된다. 이들 지시는 특히 프록시에 적용가능하다: 푸시여부에 관계없이 모든 자원은 프록시 또는 클라이언트에 의해 저장될 수 있다.
앞서 언급된 바와 같이, 클라이언트는 웹 페이지 설명(HTML 파일)에서 참조된 하위 자원을 다운로드하기 위한 적절한 순서를 갖기를 원할 수 있으므로, 서버 측의 푸시 기능을 구동해야 한다. 본 발명은, 예를 들어 클라이언트가 제1 자원을 요청한 후에 원할 수도 있는 특정한 세트의 (하위) 자원 또는 (하위) 자원의 일부(들)을 서버에게 통보하기 위하여, 이에 관해 현재의 상황을 개선시키고자하는 것이다. 특히, 본 발명은, 최소의 지능을 갖춘 서버, 예를 들어 클라이언트가 (하위) 자원을 식별하기 위한 웹 페이지 설명 등을 처리하는 지식이 없는 서버에 적합하게 하는 것을 추구한다.
본 발명에 대한 이러한 필요성은, HTTP를 통한 HTTP 스트리밍의 정황에서, 예를 들어, 푸시 기능을 이용할 때 DASH 등의 적응형 HTTP 스트리밍의 정황에서 증가된다.
HTTP를 통한 미디어 스트리밍의 일반적인 원리가 도 3에 예시되어 있다. HTTP를 통한 적응형 미디어 스트리밍의 대부분의 새로운 프로토콜 및 표준은 이 원리에 기초한다. 이것은, 이하의 설명에서 참조하는 DASH의 경우이다.
미디어 서버(300)는 클라이언트(310)에 데이터를 스트리밍한다. 미디어 서버는 미디어 프리젠테이션을 저장한다. 예를 들어, 미디어 프리젠테이션(301)은 오디오 및 비디오 데이터를 포함한다. 오디오 및 비디오는 동일한 파일에 인터리빙될 수 있다. 미디어 프리젠테이션의 구축 방법은 도 4a를 기준하여 이하에서 설명된다. 미디어 프리젠테이션은, 독립적으로 어드레싱되고 다운로드될 수 있는 MP4 세그먼트 등의, 작은 독립적인 및 연속적인 시간 세그먼트(302a, 302b 및 302c)로 시간적으로 분할된다. 이들 시간 세그먼트들 각각에 대한 미디어 콘텐츠의 다운로드 주소(HTTP URL)는 서버에 의해 클라이언트에 대해 설정된다. 오디오/비디오 미디어 콘텐츠의 각각의 시간 세그먼트는 하나의 HTTP 주소와 연관된다.
미디어 서버는 또한, 미디어 콘텐츠 특성(예를 들어, 미디어의 타입 : 오디오, 비디오, 오디오-비디오, 텍스트 등)을 포함하는 미디어 프리젠테이션의 콘텐츠를 기술하는 매니페스트 파일 문서(manifest file document)(304)(그 예가 도 7a에 도시됨) 등), 인코딩 포멧(예를 들어, 비트레이트, 타이밍 정보 등), 시간 미디어 세그먼트들 및 관련된 URL들의 목록을 저장한다. 대안으로서, 이 문서는, 시간 미디어 세그먼트들 및 연관된 URL들의 명시적 목록을 재구축하는 것을 가능하게 하는 템플릿 정보를 포함한다. 이 문서는 XML(eXtensible Markup Language)을 이용하여 작성될 수 있다.
매니페스트 파일이 클라이언트에 전송된다. 단계 305 동안 매니페스트 파일을 수신하면, 클라이언트는 미디어 콘텐츠의 시간 세그먼트와 HTTP 어드레스 사이의 연관관계를 통보받는다. 또한, 매니페스트 파일은 클라이언트에게 미디어 프리젠테이션의 콘텐츠(이 예에서는 인터리빙된 오디오/비디오)에 관한 정보를 제공한다. 이 정보는, 해상도, 비트레이트 등을 포함할 수 있다.
수신된 정보에 기초하여, 클라이언트의 HTTP 클라이언트 모듈(311)은 매니페스트 파일에 기술된 미디어 콘텐츠의 시간 세그먼트들을 다운로드하기 위한 HTTP 요청(306)을 방출할 수 있다. 서버의 HTTP 응답(307)은 요청된 시간 세그먼트를 전달한다. HTTP 클라이언트 모듈(311)은 응답으로부터 시간 미디어 세그먼트를 추출하여 미디어 엔진(312)의 입력 버퍼(307)에 제공한다. 마지막으로, 미디어 세그먼트는 각각의 단계(308 및 309) 동안 디코딩되어 디스플레이될 수 있다.
미디어 엔진(312)은 적절한 시간에 발행될 다음 시간 세그먼트를 요청하기 위하여 DASH 제어 엔진(313)과 상호작용한다. 다음 세그먼트는 매니페스트 파일에서 식별된다. 요청이 발행되는 시간은 수신 버퍼(307)가 가득 찼는지의 여부에 의존한다. DASH 제어 엔진(313)은 버퍼가 과부하되거나 완전히 비는 것을 방지하기 위해 버퍼를 제어한다.
미디어 프리젠테이션 및 매니페스트 파일의 생성은 도 4a를 참조하여 설명된다. 단계들 400 및 401 동안, 오디오 및 비디오 데이터가 취득된다. 그 다음, 오디오 데이터는 402 동안 압축된다. 예를 들어, MP3 표준이 이용될 수 있다. 또한, 비디오 데이터는 단계 403 동안 병렬로 압축된다. MPEG4, MPEG/AVC, SVC, HEVC 또는 확장가능한 HEVC 등의 비디오 압축 알고리즘이 이용될 수 있다. 일단 오디오 및 비디오 데이터의 압축이 수행되고 나면, 오디오 및 비디오 기본 스트림(404, 405)이 이용 가능하다. 기본 스트림들은 단계 406 동안 전역 미디어 프리젠테이션으로 캡슐화된다. 예를 들어, ISO BMFF 표준(또는 AVC, SVC, HEVC, HEVC의 스케일가능한 확장판으로의 ISO BMFF 표준의 확장 등)은 인코딩된 오디오 및 비디오 기본 스트림의 콘텐츠를 전역 미디어 프리젠테이션으로서 기술하는데 이용될 수 있다. 이에 의해 획득된 캡슐화된 미디어 프리젠테이션(407)은, 단계 408 동안, XML 매니페스트 파일(409)을 생성하는데 이용된다. 미디어 프리젠테이션(407)에서 비디오 데이터(401) 및 오디오 데이터(400)의 수 개의 표현이 획득, 압축, 캡슐화 및 기술될 수 있다.
도 4b에 나타낸 특정한 경우의 MPEG/DASH 스트리밍 프로토콜에 있어서, 매니페스트 파일은 "미디어 프리젠테이션 설명"(또는 "MPD" 파일)이라 불린다. 이 파일의 루트 요소(root element)는, 모든 프리젠테이션에 적용되는 속성을 포함하는 MPD 요소 + 프로필 또는 스키마 등의 DASH 정보이다. 미디어 프리젠테이션은 Period 요소로 표현되는 기간(temporal period)들로 분할된다. MPD 파일(410)은 각각의 기간에 관련된 모든 데이터를 포함한다. 이 정보를 수신함으로써, 클라이언트는 각각의 기간 동안의 콘텐츠를 알고 있다. 각각의 Period(411)에 대해, AdaptationSet 요소가 정의된다.
한 가능한 구성은, 프리젠테이션에 포함된 미디어 타입마다 하나 이상의 AdaptationSet를 갖는 것이다. 비디오에 관련된 AdaptationSet(412)는 서버에서 이용가능한 인코딩된 비디오의 상이한 가능한 표현들에 관한 정보를 포함한다. 각각의 표현은 Representation 요소에 설명되어 있다. 예를 들어, 제1 표현은 640x480의 공간 해상도로 인코딩되고 500 kbits/s의 비트 레이트로 압축된 비디오일 수 있다. 제2 표현은 동일한 비디오이지만 250 kbits/s의 비트 레이트로 압축될 수 있다.
각각의 비디오는, 클라이언트가 비디오에 관련된 HTTP 주소를 알고 있다면 HTTP 요청에 의해 다운로드될 수 있다. 각각의 표현의 콘텐츠와 HTTP 주소 사이의 연관은, 추가 레벨의 설명: 시간 세그먼트들을 이용하여 이루어진다. 각각의 비디오 표현은 시간 세그먼트(413)(통상적으로 수 초)들로 분할된다. 각각의 시간 세그먼트는 HTTP 주소(URL 또는 1 바이트 범위의 URL)를 통해 액세스될 수 있는 서버에 저장된 콘텐츠를 포함한다. MPD 파일에서 시간 세그먼트를 기술하기 위해 수 개의 요소들이 이용될 수 있다: SegmentList, SegmentBase 또는 SegmentTemplate.
또한, 특정한 세그먼트가 이용가능하다: 초기화 세그먼트. 초기화 세그먼트는, 캡슐화된 비디오 스트림을 기술하는 MP4 초기화 정보(비디오가 ISO BMFF 또는 그 확장판을 이용하여 캡슐화된 경우)를 포함한다. 예를 들어, 이것은 클라이언트가 비디오에 관련된 디코딩 알고리즘을 인스턴스화하는 것을 돕는다.
초기화 세그먼트 및 미디어 세그먼트의 HTTP 주소는 MPD 파일에서 표시된다. 본 설명에서, "세그먼트"는, 시간적 프래그먼트(예를 들어, 미디어가 ISO/IEC 14496 Part 12 및 Part 15에 따라 캡슐화될 때 mp4 파일에서 하나 이상의 moof + mdat 박스) 또는 시간적 세그먼트(예를 들어, "styp" 표시로 시작하는 mp4 세그먼트)를 가리키는데 이용된다는 점에 유의한다.
도 7a에서, 예시적인 MPD 파일이 도시되어 있다. 도시된 MPD 파일에서 2개의 비디오 표현이 기술되어 있다. 제1 표현은, 저해상도 버전("Representation id ="h264bl_low""이고, 제2 표현은 고해상도 버전("Representation id = "h264bl_full"")이다. 양쪽 비디오 표현은 동일한 AdaptationSet에 포함되어 있고 각각의 표현으로부터의 각각의 세그먼트는 SegmentTemplate URL을 통해 어드레싱된다("media="mp4-live-$RepresentationlD$-$Number$.m4s"" 여기서, $RepresentationlD$는 2개의 가능한 비디오 사이에서 다르고, $Number$는 비디오 내의 위치에 따라 다르다).
명료성을 위해, 가능한 연관된 오디오 스트림들은 표시되지 않고, 이들은 또 다른 AdaptationSet에서 기술될 수 있으며, 각각은 대안적 버전을 가진다.
스트리밍 세션을 시작할 때, DASH 클라이언트는 매니페스트 파일을 요청한다. 일단 수신되고 나면, 클라이언트는 매니페스트 파일을 분석하고, 그 환경에 적합한 AdaptationSet 세트를 선택한다. 그 다음, 클라이언트는, MPD에서, 각각의 AdaptationSet 내에서, 대역폭, 디코딩 및 렌더링 능력과 호환되는 표현을 선택한다. 그 다음, 클라이언트는, 미디어 디코더들에 대한 초기화 정보(도 7a의 예에서 SegmentTemplate@initialization URL)와 함께 시작하여, 요청될 세그먼트들의 목록을 미리 구축한다. 디코더들에 의해 초기화 정보가 수신되면, 디코더들은 초기화되고 클라이언트는 제1 미디어 데이터를 요청하고 실제로 디스플레이를 시작하기 전에 최소 데이터 양을 버퍼링한다.
이들 복수의 요청/응답은, 스트리밍 세션의 시작에서 지연을 도입할 수 있다. 서비스 제공 업체들이 그들의 클라이언트들이 비디오를 시청하지 않고 서비스를 떠나는 것을 지켜볼 위험이 있다. 클라이언트에 의해 수행된 제1 미디어 데이터 청크에 대한 초기 HTTP 요청과 미디어 데이터 청크가 실제로 재생을 시작하는 시간 사이의 시간을 시작 지연(start-up delay)으로 지정하는 것이 일반적이다. 이것은 네트워크 왕복 시간뿐만 아니라 미디어 세그먼트의 크기에 의존한다 : 세그먼트가 길수록, 시작 지연이 더 길다.
또한, 라이브 스트리밍에서, 클라이언트가 미디어 세그먼트를 요청할 때, 이 세그먼트가 서버 상에서 아직 준비되지 않았을 수 있다. 레이턴시를 감소시키기 위해, 세그먼트 길이를 감소시킬 가치가 있다. 그러나, 세그먼트 길이의 이러한 감소는 요청/응답의 수를 극적으로 증가시켜 심각한 네트워크 트래픽 오버헤드를 초래할 수 있다.
이러한 트래픽 오버헤드 증가를 감소시키기 위해, 제안된 방법은 서버에서의 HTTP/2의 푸시 기능을 이용하여 오직 서버의 주도로 데이터를 클라이언트에 푸시할 수 있도록 하는 것이다. 더 일반적으로, HTTP와 관련하여, 이러한 접근법(푸시 기능의 이용)은 HTTP 클라이언트와 HTTP 서버 사이의 왕복 횟수(및 그에 따라 레이턴시)를 감소시켜 소정 자원을 많은 하위 자원들(예를 들어 css, jscript, images를 포함하는 웹 페이지; 또는 세그먼트들의 목록을 포함하는 DASH 매니페스트)로 조직화할 수 있다.
전술된 바와 같이, HTTP를 통한 DASH 스트리밍의 정황에서 푸시 기능의 이러한 이용은 공보 WO 2015/004276호에서 이미 제안되어 있다.
이 공보에서 제안된 메커니즘은, 서버 디바이스가 DASH에 대한 정교한 지식을 가지고 있어야 하고, 특히 푸시 정책에 따라 푸시할 데이터 또는 자원을 결정하기 위해 MPD 파일에 푸시 정책을 적용할 수 있어야 한다는 것을 요구한다.
이러한 메커니즘은 HTTP를 통한 적응형 스트리밍의 몇 가지 유용한 양태와는 상반한다.
더 정확하게 말하면, HTTP를 통한 적응형 스트리밍은, 클라이언트는 일반적으로 그 목적을 위해 멀티미디어 콘텐츠의 최상의 버전을 선택할 수 있기 때문에 클라이언트가 스트리밍을 안내한다는 가정에 기초한다. 예를 들어, 클라이언트는 폼팩터 및 화면 해상도에 기초하여 HD 또는 SD 비디오를 요청할지를 알 수 있다. HTTP를 통한 적응형 스트리밍을 위한 푸시 기능의 이용은 이러한 거동을 유지하여, 클라이언트가 푸시된 데이터와 관련하여 서버를 완전히 구동할 수 있게 해야 한다.
또한, MPEG DASH 표준 등의 HTTP를 통한 적응형 스트리밍은 서버 측에서의 지능을 거의 필요하지 않는다: 클라이언트에 의해 전송된 HTTP 요청이 간단하기 때문에 매니페스트 및 미디어 세그먼트를 제공하기 위해 단순 HTTP 서버로 충분한다. 이러한 서버의 단순성은, HTTP의 표준 웹 이용을 넘어서는 서버 자원에 관한 추가 비용을 요구하지 않고도 많은 수의 스트리밍 클라이언트를 제공하는 것을 가능하게 한다. 특히, 많은 수의 스트리밍 클라이언트는 표준 HTTP 최적화 기술을 이용하여 콘텐츠 전달 네트워크를 통해 관리될 수 있다. HTTP를 통한 적응형 스트리밍을 위한 푸시 기능의 이용은 이러한 서버 단순성을 유지해야 한다.
본 발명은 HTTP의 일반적인 정황에서 푸시 기능의 이용을 개선하는 것을 목표로 한다. 이것은 특히 HTTP를 통한 스트리밍 및 DASH 등의 HTTP를 통한 적응형 스트리밍에 적용된다. 그러나, 본 발명은 바람직하게는 HTTP를 통한 적응형 스트리밍의 기존의 유용한 기능을 가능한 한 많이 유지해야 한다. 이것은, 다음과 같은 요건들 중 가능한 한 많은 것들이 충족되어야 한다는 것을 의미한다:
서버에 의해 푸시되는 (클라이언트에 대해) 잠재적인 쓸모없는 데이터를 피하기 위해 클라이언트-제어형 전송을 보존하는 것;
앞서 언급된 확장성 이점을 유지하기 위해 서버 측에서의 특정한 애플리케이션 지식의 이용을 방지하는 것;
본 발명을 구현하지 않는 레거시 클라이언트 및/또는 서버 사이의 상호운용성 및 캐시 능력을 유지하기 위하여 종래의 방식으로 자원 및 하위 자원을 요청하는 방법을 보존하는 것. 예를 들어, DASH 세그먼트의 경우, 요청된 세그먼트를 처리하기 위한 특정한 동작(예를 들어, request-URI의 변환 등)을 요구하는 임의의 요청 포멧의 도입을 회피해야 한다; 서버 측 처리를 낮게 유지한다.
본 발명의 사상은, 제1 데이터 또는 자원을 요청하는 종래의 HTTP 요청에, 클라이언트가 (가능한 경우 푸시 메커니즘을 이용하여) 수신하기를 원하는 추가 자원/데이터 또는 자원들을 결정하기 위한 힌트를 서버에 제공하거나, 클라이언트가 임의의 추가 자원을 수신하기를 원하지 않는다고 서버가 결정하기 위한 힌트를 제공하는, 선택사항적 정보를 포함하는 것이다. 특히, 이러한 힌트는, 추가 자원/데이터 또는 자원들의 결정이 정황 정보 또는 요청 외부의 정보를 이용하지 않는 방식으로 정의된다. HTTP 요청은, 추가 자원/데이터 또는 자원들의 정의에 관한 자체-설명적 요청으로서 간주될 수 있다.
이러한 힌트의 예는 이하에서 설명되며, 명시적 URI/URL 또는 URI/URL들의 목록, 자체-설명적 HTTP 요청에 기초한 구성 규칙을 이용하는 묵시적 URI들/URL들, 및 자원/데이터의 규칙 필터링을 포함한다.
본 발명에 따른 서버 측 방법은 서버 디바이스와 클라이언트 디바이스 사이에서 데이터를 전송하는 것을 추구하며, 서버 디바이스에서, 다음과 같은 단계들을 포함한다 :
클라이언트 디바이스로부터, 제1 데이터를 획득하라는 HTTP 요청 ―HTTP 요청은 서버 디바이스 상의 제1 데이터의 식별을 허용하는 제1 데이터 식별 정보를 포함하고, 제2 데이터의 식별을 허용하는 하나 이상의 선택사항적 헤더 필드를 포함함― 을 수신하는 단계; 제1 데이터를 검색하여 클라이언트 디바이스에 전송하는 단계; 및 선택사항적 헤더 필드가 HTTP 요청 내에 존재한다면:
서버 디바이스 상의 제2 데이터의 식별을 허용하는 제2 데이터 식별 정보를, 선택사항적 헤더 필드 및 아마도 제1 데이터 식별 정보만을 이용하여 결정하는 단계; 즉, HTTP 요청은 제2 자원을 결정하기에 자체적으로 충분한다, 즉, 자체-설명적이다; 및
클라이언트 디바이스로의 제2 데이터의 푸시를 공지하는 푸시 약속 메시지를 전송하고/하거나 제2 데이터를 클라이언트 디바이스에 푸시하는 단계를 더 포함한다.
특정한 실시예들에 따르면, 확인응답 데이터가 클라이언트에 전송되어, 서버가 클라이언트에 의해 요청된 제2 데이터 또는 추가 자원을 푸시할 것임을 클라이언트에게 통보하거나, 서버가 임의의 제2 데이터 또는 추가 자원을 푸시하지 않을 것임을 통보하거나, 서버가 전송할 수 있는 제2 데이터 또는 추가 자원/데이터 또는 자원들을 클라이언트가 결정하기 위한 힌트를 제공한다.
본 발명에 따른 클라이언트 측 방법은 서버 디바이스와 클라이언트 디바이스 사이에서 데이터를 전송하는 것을 추구하며, 클라이언트 디바이스에서, 다음과 같은 단계들을 포함한다: 서버 디바이스로부터 획득될 데이터를 식별하는 단계;
식별된 데이터로부터 제1 데이터를 획득하라는 HTTP 요청 ―HTTP 요청은 서버 디바이스 상의 제1 데이터의 식별을 허용하는 제1 데이터 식별 정보를 포함하고, 선택사항적 헤더 필드 및 아마도 제1 데이터 식별 정보에만(즉, HTTP 요청의 콘텐츠에만) 기초하여, 서버 디바이스 상의 식별된 데이터로부터 제2 데이터의 식별을 허용하는 제2 데이터 식별 정보를 정의하는 하나 이상의 선택사항적 헤더 필드를 포함함― 을 생성하는 단계;
제1 데이터를 획득하고 제2 데이터를 푸시하도록 서버 디바이스를 구동하기 위해 HTTP 요청을 서버 디바이스에 전송하는 단계.
특정한 실시예들에 따르면, 클라이언트는, 푸시 요청에 관한 확인응답 데이터의 수신시, 제2 데이터 또는 추가 자원을 획득하기 위한 전략을 채택한다.
제1 데이터 식별 정보는 대개, HTTP 요청(또는 HTTP/2 의사-헤더로의 변환)의 "요청-라인"의 일부를 형성하는 request-URI에 대응한다는 점에 유의한다.
본 발명에 의해 제안된 접근법은 상기 요건들의 전부 또는 일부를 충족시킨다.
우선, 본 발명의 방법들은 클라이언트가 서버에 데이터를 요청하는 동안 푸시할 하나 이상의 추가적인 또는 관련된 자원을 표시하는 것을 가능하게 한다. 클라이언트는 이들 자원을 이들 자원에 대한 특정한 요청을 전송하지 않고 수신할 것이므로, 네트워크 트래픽 및 레이턴시가 감소된다.
또한, 본 발명의 방법들은, (본 발명에 따른 선택사항적 헤더에 대한 서버의 지원에 따라) 클라이언트가 추가 자원을 수신할지 또는 추가 자원을 요청해야 하는지를 (PUSH 약속 프레임을 통해) 통보받을 수 있게 한다. 따라서, 기존의 스트리밍 서버와의 하위 호환성이 유지되고 기능 배치가 더욱 용이해져야 한다.
또한, 본 발명의 방법들은, 애플리케이션-특유의 지식을 요구하지 않고 서버가 클라이언트에게 푸시할 다음 자원(들)을 용이하게 식별할 수 있게 한다. 따라서, 서버 측에서의 처리가 제한되고, 많은 수의 클라이언트가 동일한 서버에게 요청하는 것이 인가될 수 있다.
도 3a는 본 발명의 구현을 위한 클라이언트/서버 시스템의 일반적인 예시를 보여준다. 이하에서는, 비디오가 미디어 또는 콘텐츠의 특정한 경우인 것으로 알려져 있는 자원을 지정하기 위해 "비디오", "미디어" 또는 "콘텐츠"에 대한 참조가 무차별적으로 이루어진다. 유사하게, 서버로부터 클라이언트로 전송할 미디어 자원의 설명 파일을 지정하기 위해 "MPD"또는 "매니페스트"또는 "스트리밍 매니페스트" 또는 "HTML 페이지"에 대한 참조가 무차별적으로 이루어진다.
본 발명은, 도 3a에 도시된 바와 같이, 클라이언트와 서버 사이의 HTTP 통신, 특히 데이터 스트리밍을 개선하는 것을 목표로 하며, 더 정확하게는, 자원 로딩을 위한 시간 및 네트워크 트래픽 오버헤드 양쪽 모두를 낮추는 것을 목적으로 한다.
서버(350)는, 클라이언트(380)가 다운로드할 수 있는 자원을 저장한다. 서버 상의 자원은 하위 자원들(352a, b, c)을 참조하거나 포함하는 메인 자원(351)들로 분류된다.
예를 들어, 메인 자원은 HTML 페이지일 수 있고, 하위 자원은 CSS 자원, 이미지 및/또는 미디어 파일, Java 스크립트 코드 또는 메인 자원에서 참조되는 다른 HTML 페이지일 수 있다. 이들 자원들의 액세스 권한 및 구성은 정적 구성 파일(355)에서 설명될 수 있다.
클라이언트(380)에 의해 발행된 HTTP 요청은, 요청을 자원 식별 및 헤더 처리로 분해하는 요청 파서(357)를 포함하는 HTTP 프로세서(356)에 의해 수신되고 처리된다.
본 발명은 푸시 헤더 프로세서(358)에 의해 수행되는 하나의 특정한 헤더 처리에 관한 것이다. 후자는, 후술되는 바와 같이 HTTP 요청에서 선택사항적인, 하나 이상의 특유의 푸시 헤더(들)를 처리하는 책임을 진다. 앞서 간략하게 소개된 바와 같이, 하나 이상의 특유의 푸시 헤더(들)로부터 및 HTTP 요청만을 이용하여, 서버는 추가 자원들을 푸시하기 위하여 추가 자원들에 대한 하나 이상의 참조를 생성할 수 있다.
자원 관리자(360)는, 자원의 존재/부재/신선도를 체크하고 요청된 자원을 다시 HTTP 프로세서(356)에게 제공하는 책임을 진다. 그 다음, 응답 생성기(359)는 클라이언트에 전송되는 하나 이상의 HTTP 응답(HTTP/1.x) 또는 프레임(HTTP/2) 내에 이들 제공된 자원들을 캡슐화한다.
클라이언트(380)는, 사용자가 수 개의 클라이언트 모듈에 의해 처리되는 콘텐츠를 선택하고, 이와 상호작용하며 시청하기 위한 사용자 인터페이스(381)를 갖는다.
사용자 인터페이스(381)는, 사용자 클릭을, HTTP 클라이언트(382)의 요청 스케줄러(383)에 의해 처리되는 추가 콘텐츠에 대한 요청으로 변환한다. 추가 콘텐츠에 대한 요청은 다운로드할 자원들의 목록으로 변환될 수 있다. HTTP 클라이언트(382)는 HTTP 서버(350)와의 통신을 처리한다.
HTTP 클라이언트는, 서버(350)에게 자원을 요청하기 위해 HTTP 요청(HTTP1.x) 또는 프레임(HTTP/2)을 구축하는 요청 생성기(384)를 포함한다.
본 발명에 따르면, HTTP 클라이언트(382)는, 특정한 모듈, 즉, 푸시 헤더 생성기(385)를 포함하고, 푸시 헤더 생성기(385)는, 요청 스케쥴러(383)에서 대기중인 다음 자원 또는 자원들을 나타내고/나타내거나 푸시 정책, 푸시 전략 또는 푸시 지시를 나타내는, 앞서 언급된 특정한 (선택사항적인) 푸시 헤더를 HTTP 요청 내에 삽입하는 것을 책임진다. 특정한 실시예들에 따르면, 푸시 헤더는 푸시 타입 및 아마도 연관된 파라미터를 포함할 수 있다.
서버로부터 수신된 응답 또는 통보는, 데이터를 추출하여 클라이언트 캐시/메모리(387)에 저장하는 응답 파서(386)에 의해 처리된다. 응답 헤더에서 전달되는 정보는 또한 HTTP 클라이언트(311)에 의해 수신되고 처리되며, (예를 들어, DASH 애플리케이션이 XmlHTTPRequest를 이용하여 자바스크립트 코드로 작성된 경우) DASH 제어 엔진(313)에 이용가능하게 될 수 있다.
이들 데이터는, 데이터를 파싱(389)하여 적절한 디코딩 모듈(390)에 발송하는 렌더링 엔진(388)에 의해 이용된다. 이 데이터에 기초하여, 후자는 사용자 인터페이스(381) 상에 렌더링하기 위해 재구성된 데이터를 디스플레이(391)에 제공한다.
본 발명에 따르면, 파싱 모듈(389)은, 수신된 데이터의 콘텐츠를 분석하여 잠재적으로 사용자의 관심대상이 되는 임의의 추가 자원을 식별할 수 있다. 이러한 경우에, 파싱 모듈(389)은 요청 스케쥴러(383)에서 이들 추가 자원을 첨부한다.
클라이언트의 거동은 도 5a에 예시되어 있고, 서버의 거동은 도 6a에 예시되어 있다.
도 5a를 참조하면, 단계 551에서, 클라이언트는, 예를 들어 HTML 또는 스트리밍 매니페스트의 웹 페이지 등의, HTTP 요청을 이용하여 메인 자원을 요청한다. 웹 페이지에 대한 HTML 코드는 단계 552에서 (모듈(389)을 이용하여) 파싱되어 웹 페이지를 구성하는 자원을 식별한다. 파싱 결과를 이용하여, 클라이언트는 전체 페이지를 렌더링할 수 있기 위해 다운로드할 필요가 있는 자원 목록을 식별한다. 이것은 단계 553이고, 자원 목록은 스케쥴러(383)에 저장된다.
단계 554에서, 클라이언트는 제1 식별된 자원을 서버로부터 획득하기 위해 제1 HTTP 요청을 생성하여 전송한다. 본 발명에 따르면, 클라이언트(모듈(385))는 또한, 특유의 푸시 헤더에서, 서버에 의해 푸시되고자 하는 추가/관련 자원의 목록을 표시할 수 있다. 이것이 단계 555이다. 특유의 푸시 헤더에 대한 신택스(syntax)의 예가 이하에서 제공된다.
단계 556에서 서버로부터 하나 이상의 응답을 수신하면, 클라이언트(모듈(384))는 데이터의 푸시를 공지하는 서버 통보(즉, PUSH 약속)가 수신되었는지의 여부를 체크한다(단계 557). 제1 자원에 대한 데이터가 완전히 수신되면, 체크가 중단할 수 있다. 이것은, 특유의 푸시 헤더에 의해 정의된 추가/관련 자원에 관한 어떠한 PUSH 약속도 요청된 제1 자원에 대응하는 스트림의 폐쇄 이후에는 전송될 수 없기 때문이다. 여기서, 그 특유의 푸시 헤더를 지원하지 않는 서버는 이 헤더에서 정의된 추가/관련 자원에 대한 PUSH 약속을 전송하지 않을 것이고 단순히 헤더를 무시할 것이라는 점을 상기한다.
체크가 부정적이면, 수신된 데이터는 요청된 제1 자원의 데이터일 뿐이다. 따라서, 이들은 단계 560에서 모듈(384)에 의해 처리되어 렌더링 엔진(388)에 제공된다. 그 다음, 프로세스는 단계 555로 되돌아 가서, 요청 스케쥴러(383)에 저장된 추가 자원을 요청한다(단계 561).
체크가 긍정적이면, 즉, 서버가 특유의 푸시 헤더에서 클라이언트에 의해 제안된 자원들의 일부를 푸시할 것임을 공지한다면, 클라이언트는 요청 스케쥴러(382) 내의 다운로드할 자원 목록을 업데이트하여 그로부터 푸시된 자원을 철회한다. 이것이 단계 558이다. 그 다음, 클라이언트는, 다운로드할 더 이상의 자원이 요청 스케쥴러(382)에 남아 있지 않을 때까지 반복하기 전에(단계 561 및 단계 555로 루프하기 전에), 제1 자원에 대한 데이터(단계 560) 및 다른 추가/관련 자원에 대한 데이터를 처리한다(단계 559).
이제 도 6a를 돌아가면, 서버(350)는 클라이언트(380)에 의한 HTTP 요청에서 제공된 특유의 푸시 헤더를 처리하기 위해 전용 "푸시 헤더" 프로세서(358)를 이용한다는 것을 상기한다. 또한, HTTP 프로세서(356)는, HTTP 요청을 파싱하고, 요청된 제1 자원의 URI 및 선택사항적 헤더 또는 헤더(들)을 포함한, 요청에 포함된 다양한 파라미터를 추출하는 역할을 책임진다. 따라서, HTTP 프로세서(358)는, 특정한 (선택사항적인) 푸시 헤더를 그 이름을 통해 식별한 다음, 처리를 위해 그것을 푸시 헤더 프로세서(358)에 포워딩한다.
단계 601에서, 서버는 클라이언트(380)로부터 요청을 수신 및 처리하여, 메인 자원, 예를 들어, 스트리밍의 정황에서 스트리밍 매니페스트를 획득한다. 이것은 HTTP 프로세서(356)에 의해 처리된다.
그 다음, 단계 602에서, 서버는 매니페스트 데이터를 전송함으로써 응답한다. 단계 603에서, 서버는 제1 자원을 요청하는 새로운 요청을 클라이언트로부터 수신하고, 대개는 제1 자원은 매니페스트 데이터에서 참조된다. 이것은 미디어 스트리밍의 정황에서 미디어 세그먼트일 수 있다.
이 요청에서, 클라이언트는 또한, 특유의 푸시 헤더를 이용하여, 관심있는 추가 또는 관련 자원을 표시할 수도 있다. 따라서, 단계 604에서, 서버는, 이러한 특유의 푸시 헤더가 요청에 포함되어 있는지의 여부를 체크한다.
이것이 포함되고 기재되어 있다면, 서버는 특유의 푸시 헤더를 특유의 푸시 헤더 프로세서(358)에 제공한다. 후자는, 후술하는 바와 같이 푸시 헤더의 상이한 부분들을 파싱하여 클라이언트에 의해 표시된 추가 또는 관련 자원에 대한 하나 이상의 참조를 생성한다. 이것이 단계 605이다.
선택사항으로서, 서버는, 자신이 푸시할 수 있는지의 여부에 관계없이, 소유하고 있는 자원 목록 내의 각각의 자원을 선언하는 미리-구성된 인가 파일(authorization file)을 가질 수 있다. 이러한 인가 파일은 단계 606에서 검토되어 단계 605에서 획득된 일부 참조를 유효성확인하거나 무효화할 수 있다.
서버는, 인가 파일에 따라 그 푸시가 인가된 자원들에 대해서만 푸시 공지 메시지(예를 들어, PUSH PROMISE 프레임)로 클라이언트에게 통보한다. 이것이 단계 607이다. HTTP/2에서, PUSH PROMISE 프레임은, 단계 605에서 식별된 자원마다 하나의 PUSH PROMISE 프레임을 동반하여, 클라이언트의 요구에 대응하는 스트림 상에서 전송된다. 단계 607에 후속하는 단계 608에서, 서버는 요청된 제1 자원(즉, 스트리밍의 정황에서 제1 미디어 세그먼트)을 요청 클라이언트에 전송한다.
특유의 푸시 헤더가 존재하지 않거나 지원되지 않으면(테스트 604 거짓), 또는 식별된 자원에 대해 푸시가 전혀 인가되지 않으면(테스트 606 거짓), 요청된 제1 자원만이 단계 608에서 클라이언트에 다시 전송된다.
요청된 제1 자원의 전송 다음에, 서버는 대응하는 스트림을 닫고, 클라이언트에 의해 취소되지 않는 한, 푸시 공지 메시지(PUSH PROMISE 프레임)를 통해 공지된 스트림을 이용하여 단계 605에서 식별된 추가 또는 관련 자원에 대한 데이터를 푸시한다. 이것이, 전송이 하나 이상의 DATA 프레임을 전송하는 것에 의존할 수 있는 단계 609이다.
전술된 바와 같이, 특정한 실시예들에 따르면, 서버가 클라이언트에 의해 요청된 제2 데이터 또는 추가 자원을 푸시하지 않을 것임을 클라이언트에게 통보하거나, 서버가 임의의 제2 데이터 또는 추가 자원을 푸시하지 않을 것임을 통보하거나, 서버가 전송할 수 있는 제2 데이터 또는 추가 자원/데이터 또는 자원들을 클라이언트가 결정하기 위한 힌트를 제공하기 위해, 확인응답 데이터가 클라이언트에 전송된다.
따라서, 참조번호 610으로 예시된 바와 같이, 수신된 요청에 응답하여 전송되는 응답에 확인응답 데이터를 추가하여 서버가 클라이언트에 의해 요청된 제2 데이터 또는 추가 자원을 푸시할 것임을 클라이언트에게 통보하거나, 서버가 임의의 제2 데이터 또는 추가 자원을 푸시하지 않을 것임을 통보하거나, 서버가 전송할 수 있는 제2 데이터 또는 추가 자원/데이터 또는 자원들을 클라이언트가 결정하기 위한 힌트를 제공할 수 있다. 이러한 확인응답 데이터의 예는 도 11a 내지 도 11e를 참조하여 주어진다.
도 3b는, 데이터 스트리밍, 예를 들어, DASH의 정황에서, 클라이언트-서버 시스템을 예시한다. 도 3에서와 동일한 컴포넌트는 동일한 참조 번호를 갖는다.
먼저, 다운로드할 미디어 세그먼트를 결정하는 것을 책임지는 DASH 제어 엔진(313)에서, DASH 제어 엔진(313) 내의 요청 스케줄링 모듈에 의해 추론된 다운로드할 다음 세그먼트의 목록을 HTTP 클라이언트(311)에게 전달하기 위해 추가 모듈이 추가된다.
이 정보는, HTTP 클라이언트(311)에서 특정한 "푸시 헤더" 생성기(314)에 의해 처리된다. 다운로드할 다음 세그먼트들의 목록으로부터, 푸시 헤더 생성기(314)는, 예를 들어, 다운로드할 다음 세그먼트들의 목록을 특유의 푸시 헤더의 상이한 부분들에 맵핑함으로써, 특유의 푸시 헤더에 대한 적절한 신택스를 생성하는 것을 담당한다.
푸시 헤더 생성기(314)에 의해 출력된 특유의 푸시 헤더는, 현재의 HTTP 요청에 삽입하기 위해 HTTP 클라이언트(311)에 공급된다.
서버 측에서, HTTP 프로세서(320) 및 푸시 헤더 프로세서(321)는 도 3a를 참조하여 전술된 HTTP 프로세서(356) 및 푸시 헤더 프로세서(358)와 유사하지만, 스트리밍 및 DASH 지향형이다.
도 5b는 도 3b의 시스템에서의 스트리밍-지향형 클라이언트의 거동을 나타내는 주요 단계들을 도시한다.
단계 501에서, 클라이언트(310)는, 원하는 미디어와 연관된 스트리밍 매니페스트를 스트리밍 서버(300)에게 요청한다. 스트리밍 매니페스트를 수신하면, 클라이언트(310)는 단계 502에서 이를 파싱한 다음, 단계 503에서 비디오 표현(video Representation)을 선택한다.
미디어의 스트리밍 동안에 반복적으로, 클라이언트는 다운로드를 위해 서버에게 요청할 다음 세그먼트를 선택한다. 이것이 단계 504이다.
그 다음, 단계 505는 클라이언트가 필요로 할 미래의 세그먼트들을 식별하는 것으로 구성된다. 이 결정은, DASH 제어 엔진(313) 내의 요청 스케쥴러가 미래 세그먼트에 관해 예상하는 것: 예를 들어, 곧 스위칭될 것인지 또는 동일한 표현 레벨(Representation level)에 머무를 것인지를 결정하는 것으로 구성된다.
다음 세그먼트 또는 세그먼트들의 다운로드를 예상하기 위하여, 클라이언트는 추후의 렌더링에 요구되는 미래의 세그먼트들의 개수 "K"(K는 클라이언트에 의해 설정됨)를 식별할 수 있다.
예를 들어, 이것은 MPD 내의 SegmentList를 직접 파싱하여 현재 세그먼트로부터 다음 K개의 세그먼트를 검색하거나, MPD에서 제공된 SegmentTemplate을 이용하여 다음 K개의 세그먼트에 대한 세그먼트 수를 계산하거나, 세그먼트가 바이트 범위를 통해 어드레싱될 때 mp4 박스로부터의 다음 K 바이트 범위를 계산함으로써 이루어질 수 있다.
그러나, 단계 505의 식별 프로세스에서 상이한 선택 기준이 이용될 수 있다.
적응형 스트리밍의 정황에서, 선택 기준은 표현들(Representations) 사이에서 스위칭될 때 클라이언트의 스위칭 전략을 포함할 수 있다. 예를 들어, 클라이언트가 적극적인 스위칭 전략을 채택할 때, K는 더 정교한 스위칭 세분성을 허용하기 위해 (예를 들어, 5초 미만을 커버하는 세그먼트의 수에 대응하는) 로우(low)로서 정의되는 것이 바람직하다. 반면에, 클라이언트가 보수적인 전략을 채택하고 너무 빈번하게 스위칭하지 않을 때, K는 더 크게 설정될 수 있다(예를 들어, 10초보다 큰 세그먼트 수).
여전히 적응형 스트리밍의 정황에서, 또 다른 선택 기준은 서버의 PUSH PROMISE 기능을 포함할 수 있다. 예를 들어, 서버가 적절한 시간에 클라이언트에 의해 제안된 만큼의 세그먼트를 약속하거나 전송할 수 없다면, 클라이언트는 K 값을 감소시키기 위해 이 정보를 고려할 수 있다. 이것은 결과적으로 매번 푸시할 미디어 세그먼트가 더 적어진다는 것을 암시한다.
여전히 적응형 스트리밍의 정황에서, 또 다른 선택 기준은 클라이언트의 선행인출(pre-fetching) 전략을 포함할 수 있다. 예를 들어, 클라이언트는 고속 탐색 목적을 위해 상이한 기간들의 시작 부분에 있는 제1 세그먼트들을 선택할 수 있다. 또는 비디오 애플리케이션이 비디오의 가장 인기있는 부분에 관한 정보를 제공한다면, 이러한 가장 인기있는 부분에 대응하는 제1 세그먼트를 선택하는 것을 포함할 수 있다.
또 다른 가능한 스트리밍-지향형 선택 기준은 매니페스트 MPD의 분석으로부터 발생할 수 있다. 예를 들어, 클라이언트는 서버에게 선택된 Representation과 연관된 세그먼트를 푸시할 것을 제안할 수 있다. 이것은 연관된 Representation들 사이의 연관 Id로 용이하게 결정될 수 있다. 이 제안은 associationType 정보에 따라 달라질 수 있다. 또한, 의존적 Representation의 경우, 강화 층(enhancement layer)을 위한 세그먼트가 푸시를 위해 제안될 수 있다.
더 일반적으로, 예를 들어 웹 페이지(도 3a 및 5a 참조) 등의, HTTP를 통한 자원 다운로드에서, 클라이언트(웹 브라우저, HTML 렌더러)는 메인 자원을 분석하여 그 내부에서 참조된 다운로드하기를 원하는 하위 자원을 신속하게 식별할 수 있다. HTML 메인 자원을 파싱함으로써, 클라이언트는 예를 들어 다음과 같은 것들에 의존할 수 있다:
- "선행인출(pre-fetching)" 또는 "다음(next)"을 나타내는 "rel" 값을 갖는 <link> 요소들;
- 예를 들어 CSS 자원을 선택하는 스타일시트 관련 자원을 나타내는 <link> 요소들;
- 예를 들어 자바 스크립트 코드에 대응하는 하위 자원들을 선택하는 <script> 요소들;
- <img> 및/또는 <video>와 같은 미디어 요소들.
잠재적으로 HTML 페이지에서 선언되는 이들 요소로부터, 클라이언트는 "href" 속성을 통해 URI들의 목록을 선택할 수 있다. 이 URI들의 목록은, 예를 들어 자원 타입별로, 하나 이상의 특유의 푸시 헤더에 배치되거나, 단일 헤더에서 URI들의 목록으로 연결되거나 공지된 Accept HTTP 헤더 내의 "q" 값과 유사한 우선순위들을 갖는 목록으로서 조직화될 수 있다.
K개의 추가 자원 또는 관련 자원을 선택하고 식별하는 단계 505 후에, 클라이언트는 단계 504에서 식별된 다음 세그먼트를 획득하기 위해 HTTP 요청을 생성한다. 이것이 단계 506이다.
다음 세그먼트의 URL 또는 바이트 범위를 갖는 SegmentBase URL이 (요청 라인을 형성하는 HTTP 메소드에 추가하여) HTTP 요청을 형성하는데 이용된다.
본 발명에 따르면, 추가 단계 507는, HTTP 클라이언트(311)의 푸시 헤더 프로세서(314)가 단계 505에서 DASH 제어 엔진(313)에 의해 결정된 미래 세그먼트들(즉, 추가 자원들)의 목록을 획득하고 이들 미래 세그먼트들을 정의하도록 특유의 푸시 헤더를 설정하는 것으로 구성된다.
클라이언트가 서버에 의해 푸시되기를 원하는 미래 세그먼트를 선언하는 수 개의 방법들이 이하에서 설명된 바와 같이 구현될 수 있다.
다음 세그먼트에 대한 요청 라인을 포함하고 추가 세그먼트들의 푸시를 제안하기 위한 특유의 푸시 헤더를 포함하는 HTTP 요청이 일단 준비되고 나면, 이 요청은 여전히 단계 507에서 HTTP 클라이언트(311)에 의해 서버(300)에 전송된다.
단계 508에서 서버로부터의 응답을 수신하면, 클라이언트는, 서버가 특유의 푸시 헤더에서 정의된 추가 세그먼트를 전송하기 위한 주도권을 잡을 것이라는 것을 나타내는 푸시 공지 통보를 서버가 전송하는지의 여부를 체크한다. 이 체크는 단계 509이다.
푸시 공지 통보는, 예를 들어 HTTP/2에서 미래의 세그먼트당 하나 이상의 PUSH PROMISE 프레임을 이용하여 이루어질 수 있다.
단계 504에서 선택된 요청된 다음 세그먼트에 대한 데이터가 완전히 수신되고(대응하는 스트림은 서버에 의해 닫히고), 푸시 공지 통보가 수신되지 않았다면(테스트 509 거짓), HTTP 클라이언트(311)는 요청할 다음 세그먼트는 바로 다음 세그먼트라는 것을 DASH 제어 엔진에게 통보한다. 이것이 단계 510이다.
그렇지 않은 경우(테스트 509 참), 새로운 HTTP 요청을 이용하여 요청할 다음 세그먼트는 푸시될 것으로 약속된 마지막 세그먼트 바로 다음의 것이다. 클라이언트 측에서의 업데이트는 단계 511에서 수행된다. 한편, K개의 미래 세그먼트들에 대한 데이터는 단계 512에서 서버로부터 HTTP 클라이언트에 의해 수신된다.
단계 510 및 512에 이어, 프로세스는 스트리밍이 중단될 때까지 프로세스를 반복하기 위해 단계 505로 되돌아 간다.
대안으로서, 클라이언트(310)는, HTTP 클라이언트(311)에서, 획득할 K개의 미래 세그먼트들의 처리를 구현할 수 있다. 이러한 구현에서, 다운로드할 다음 세그먼트(들)를 결정할 책임을 지는 것은 HTTP 클라이언트이다. 그러면, HTTP 클라이언트(311)에 의해 수신된 푸시된 데이터는, DASH 제어 엔진(313)을 위해 미리 클라이언트 캐시(307)를 채워, 다음 세그먼트를 요청할 때 DASH 애플리케이션 레벨에서의 인지된 레이턴시가 감소되게 할 것이다.
특정한 실시예들에 따르면, 클라이언트는, 푸시 요청에 관한 확인응답 데이터의 수신시, 예를 들어 제2 데이터 또는 추가 자원을 획득하기 위한 전략을 채택하기 위해 수신된 확인응답 데이터를 처리한다(단계 513). 이러한 확인응답 데이터를 처리하는 예는 도 11a 내지 도 11e를 참조하여 주어진다.
이제 특유의 푸시 헤더의 신택스로 돌아가면, 모든 HTTP 헤더와 같이, 이것은 {name, value} 쌍으로 식별되며, 그 명칭과 값은 콜론 ':'으로 분리된다.
헤더 명칭은, 예를 들어, "Push-Request"이거나, 또 다른 기존 헤더 명칭과 충돌하지 않는 기타 임의의 명칭일 수 있다. 애플리케이션 전용 헤더라면, 그 명칭은 애플리케이션 명칭: 예를 들어, 상이한 케이스와 정합하는 "DASH-Push-Request" 또는 "HTML-Push-Request"로 시작할 수 있다
이하에서는, 애플리케이션-관련된 접두사가 없는 일반 헤더를 고려한다.
특유의 푸시 헤더의 목적은, 하나 이상의 고유 자원 식별자(URI) 또는 로케이터(URL) 등을 정의하여 (서버에) 제공함으로써, 제1 자원을 요청하는 클라이언트에 대한 추가 자원 또는 관심대상 자원의 일부를 식별하는 것이다. 본 발명에 의해 제공되는 바와 같이, HTTP 요청은 이들 추가 자원을 결정하기에 자체-충분해야 한다, 즉, 외부 또는 정황 정보를 요구하지 않아야 한다.
추가적인 자원 또는 자원의 일부를 정의하는 다양한 실시예가 고려될 수 있다.
실시예들에서, 특유의 푸시 헤더는 이들 추가 자원을 식별하는 URI 또는 URL을 명시적으로 포함한다. 예를 들어:
< Push-Request: HTTP://server/path/segment-2.mp4 >
다른 실시예들에서, 이들은 구성 규칙을 통해 지시되며, 이 규칙은 특유의 푸시 헤더에 삽입된다. 즉, 추가 관심 자원들의 목록은 구성 규칙으로서 표현된다. 특유의 푸시 헤더의 신택스는 도 6b에 도시된 바와 같을 수 있다.
헤더(650)의 헤더 값은, 예약된 문자, 예를 들어, ';'으로 분리된 3개의 별개의 부분으로 구성된다.
제1 부분(652)은, 2개의 다른 부분에 의해 정의된 구성 규칙이 HTTP 요청의 어느 부분에 적용되어야 하는지를 정의하는 "지원"이다. 특히, 이러한 URI 또는 URL은 HTTP 요청에서 설정된 request-URI의 전부 또는 일부일 수 있다.
따라서 "지원"이라는 단어는 초기 request-URI 자체를 참조할 수 있지만, HTTP 요청에 있는 또 다른 HTTP 헤더를 참조할 수도 있다.
제2 부분(653)은, 상기 지원로부터의 추출 패턴, 즉, 지원 부분(652)에 의해 참조되는 URI 또는 URL의 변동 부분을 정의한다.
예를 들어, request-URI 등의 변동 부분은 예약된 문자를 이용하여 명시적으로 표시될 수 있다. 한 변형예에서, 변동 부분은, 추출 및 수정할 request-URI의 일부 등을 나타내는 정규 표현으로 표현될 수 있다.
따라서, 제2 부분(653)은 변동 부분 정보를 포함하고 URI 템플릿의 형태를 취할 수 있다.
상기 지원이 또 다른 HTTP 헤더인 경우, 표시할 추출 패턴이 없거나, 예를 들어 880(이하 참조)과 같이, 전체 헤더 값이 대체할 패턴으로서 표시된다.
마지막 부분(654)은 선택사항으로서 제2 부분(653)에 의해 정의된 변동 부분의 대체로서 적용될 하나 이상의 대체 값을 포함한다.
대체 값은, 콜론(또는 임의의 전용 분리자)으로 구분된 값들의 목록 또는 값들의 범위 또는 심지어 범위들의 목록을 이용하여 정의될 수 있다. 이러한 경우, 푸시 헤더 프로세서(321/358)는 값들의 목록 또는 범위(들)에 걸쳐 반복하여 대체 값으로서 많은 URL을 추론해야 한다.
예를 들어, 제1 및 제2 부분이 병합될 때 :
< Push-Request: HTTP://server/path/segment-{1}.mp4; {2-5} >
여기서 {1}은 변동 부분을 정의하고 {2-5}는 대체 값이다.
3개의 별개의 부분을 갖는 또 다른 예는 다음과 같다:
< Push-Request: request-URI; segment-{1}.mp4; {2-5} >
여기서, "request-URI"가 지원인 경우. "segment-{1}.mp4"는 변동 부분 {1}을 갖는 지원에 의해 정의된 URI의 일부이고, {2-5}는 대체 값이다.
문제는 가능한 한 일반적인 구성 규칙을 구축하는 것이다. 이러한 구축에 대한 예시적인 주요 양태는 적응형 스트리밍의 정황에서 제공된다.
DASH에는 미디어 세그먼트들 또는 미디어 콘텐츠 하위부분들 : SegmentTemplate, SegmentBase 또는 SegmentList를 설명하는 다양한 방법이 제공되며, 이들 3개 중 한번에 하나만이 Representation, AdaptationSet 또는 Period 요소에서 존재한다.
SegmentTemplate은, 클라이언트가 다운로드하기를 원하는 다음 세그먼트에 관한 힌트를 서버에게 제공하기 위한 URI 템플릿을 용이하게 구축하기 위한 가장 편리한 방법이다. 이것은, SegmentTemplate이 매니페스트에서 정의된 세그먼트 URL의 어느 부분이 예를 들어 표현의 고유 식별자 또는 표현의 대역폭 등에 따라 달라지려하는지를 명확하게 표시하기 때문이다. 이 경우, 클라이언트에 의한 K개의 미래 세그먼트의 식별은, DASH 제어 엔진(313)에서 이용가능한 표준 템플릿 해결 프로세스보다 많은 능력을 요구하지 않는다.
이것은 도 7a의 예의 경우이다. URI 템플릿 "mp4-live-$RepresentationlD$-$Number$.m4s"로부터, 동일한 Representation "h264bl_low"의 현재 세그먼트 N 이후의 K개 세그먼트를 지정하는 구성 규칙을 정의하는 것은 용이하다.
< Push-Request: "mp4-live-h264bl_low-{1}.m4s"; {(N+1)-(N+K)} >
SegmentList 접근법의 경우, 클라이언트는, 나열된 세그먼트들의 URI들 사이에서 반복되는 패턴을 식별한 다음, 세그먼트 URL들 목록을 나타내는 일반 규칙을 추론하기 위하여 MPD 파일을 선행-처리할 수 있다.
대안으로서, MPD 분석기는 이 작업을 오프라인으로 수행하고 SegmentList를 새로운 요소, 속성 또는 기술자로 주석부기하여 이용될 수 있는 URI 템플릿을 제공할 수 있다. 이것은 클라이언트 측에서의 처리를 가속한다. 요소 또는 속성으로서, URI 템플릿은 SegmentList 요소 내에 정의될 수 있다. 기술자로서, 이것은 SegmentList의 부모 요소(예를 들어, Representation 요소 레벨)에서 정의될 수 있다.
도 10은 세그먼트들의 설명을 위해 SegmentList 요소를 이용하는 MPD 샘플(1000)을 제공한다. SegmentList는 SegmentURL 요소들의 열거를 포함한다. 이 MPD 샘플에서, 동일한 비디오 콘텐츠에 대한 2개의 대안적 표현(1002, 1003)이 동일한 AdaptationSet(1001) 내에서 설명된다.
각각의 Representation 내의 SegmentURL 목록을 파싱함으로써, 클라이언트는, 세그먼트 인덱스를 제외하고, URL들이 대체로 일정하다는 것을 용이하게 결정할 수 있다.
그 다음, 1005 및 1006에서 제공된 예시적인 URI 템플릿과 같은 주석이 부모 Representation 요소에 추가될 수 있다(Representation당 최대 하나의 SegmentList이므로). (@templateURI 속성에서) 이 주석 덕분에, 푸시될 목록 내의 하나 이상의 세그먼트를 표시하려는 클라이언트는 특유의 푸시 헤더에 @templateURI 값을 복사하여 붙여넣기만하면 된다.
클라이언트에 대한 URI 템플릿의 이용을 더욱 간소화하기 위해, 획득된 @templateURI(1005 및 1006)의 어느 부분이 하나의 Representation으로부터 또 다른 Representation으로 변하는지를 체크할 수 있다. 이것은, 이 예(1000)에서, 동일한 AdaptationSet 내에 복수의 Representation이 존재하기 때문이다. 이로 인해, 이번에는 복수의 변수 또는 변동 부분을 동반하여 AdaptationSet 레벨에서 또 다른 템플릿 속성이 생성된다(1007 참조).
따라서, 한 레벨로부터 다른 레벨로, @templateURI 속성을 점진적으로 일반화하는 것이 가능하다. 따라서, 일반화 프로세스는, SegmentURL 값이 매우 유사할 때까지 부모 요소(들)에 관해 반복될 수 있다.
@templateURI 주석(1007)에 관해서는, URI 템플릿이 복수의 변수 또는 변동 부분을 포함하는 경우가 발생할 수 있다. 이러한 경우, 변동 부분들이 그들 각각의 대체 값에 의한 대체를 위해 연속적으로 고려되어야 하는 순서를 결정하는 것은 클라이언트이다. 따라서 클라이언트는 각각의 변동 부분을 우선순위 레벨 레벨과 연관시켜 이들 변동 부분들을 고려할 때 서버가 미리정의된 순서를 따르게 강제할 수 있다.
선택사항으로서, @templateURI 속성 외에도, @templateURI 속성의 하나 이상의 변동-부분에 대해 가능한 값들의 범위를 표시하기 위해 @templateValue 속성이 역시 제공될 수 있다. 가능한 값들의 범위는 MPD, 즉, 도 10의 예에서 SegmentURL들의 목록에 기초하여 결정된다.
예를 들어, 주석들(1005 및 1006) 외에도, @templateValue 속성은 주석들(1005 및 1006) 각각과 함께 선언되어 동일한 값 범위: @templateValue="{1-6}"를 정의할 수 있다.
AdaptationSet 레벨에서 추가된 @templateURI의 경우, @templateValue 속성은 다음 값들을 취한다: @templateValue="low:hd;{1-6}", 여기서, 'low' 및 'hd' 문자열은 표현 식별자에 대응하는 제1 변수 "level'에 대한 가능한 값들을 열거하고 범위 {1-6}은 세그먼트 인덱스에 대응하는 제2 변수 'nb'에 대한 가능한 값들을 열거한다.
도 6b에 도시된 특유의 푸시 헤더의 신택스로 돌아가서, 실시예는 특유의 푸시 헤더를 기술할 때 추출 패턴(들)(653)을 표현하기 위해 URI 템플릿 상의 RFC 6570 및 다음과 같은 문법을 이용한다.
"푸시 헤더"는 다음과 같이 정의될 수 있다:
push_request = "Push-Request:" header_name";"uri_template * (";" definition)
with header_name = "URI" | HeaderName
HeaderName은 상이한 HTTP 버전들의 명세에서 미리 정의된 헤더 명칭에 대응한다.
uri_template 파라미터는 잠재적으로 확장판과 함께 RFC 6570에서 정의된 URI 템플릿이다. 이 템플릿은, 중괄호 사이에 정의되고 그 명칭이 숫자인, 변수 또는 변동 부분을 포함할 수 있다. 예를 들어 : /server/video{1}.mp4는 하나의 변동 파라미터를 가진 uri_template이고 /server/{1}/image{2}.jpg는 또 다른 uri_template이지만 2개의 변동 파라미터를 가진다.
가장 단순한 경우는 {1}과 동일한 uri_template에 대응하며 이것은 전체 지원이 선언된 정의, 즉, 대체 값으로 대체되어야 한다는 것을 의미한다. 또한, 임의의 선언된 변수가 없는 uri_template은 전체 지원(652)이 uri_template 값으로 대체되어야 한다는 것을 의미한다. 예를 들어 support = "URI"이고 uri_template = "/server/resource2.ext"이면, 특유의 푸시 헤더는 임의의 추가 처리없이 클라이언트에 의해 제안된 자원의 URI가 /server/resource2.ext라는 것을 나타낸다.
마지막 선택사항적 정의 파라미터는 하나 이상의 대체 값을 선언한다. 제1 정의는 uri_template의 제1 변수에 대한 대체 값(들)에 대응하며, 제2 정의는 제2 변수에 대한 대체 값(들)에 대응하는 등등이다. uri_template 파라미터들(즉, 추출 패턴들)만큼의 정의 파라미터(즉, 대체 값 세트)가 있어야 한다.
따라서, 이러한 "정의"는 값(들) 및/또는 목록(들) 및/또는 범위(들)을 포함한다:
정의 = 값| 목록 | 범위
여기서 값은 대체 값을 문자의 문자열로 표현하는 제1 가능성이다;
목록 = 값 | 범위 *(":" 값 | 범위)는 대체 값들을 콜론으로 분리된 값들 목록(또는 값들의 범위)으로서 표현하는 제2 가능성이다. 콤마 문자는 통상적으로 동일한 헤더에 대한 수 개의 값들을 분리하는데 이용되기 때문에, 값들을 분리하기 위해 콤마 문자보다 콜론 문자가 선호된다는 점에 유의한다.
범위 = "{"시작" - "끝"}"는 대체 값들을 범위로서 표현하는 제3 가능성이다. 이것은, '시작'과 '끝' 사이의 모든 값들의 목록으로 해석되어야 하며, '시작'과 '끝' 양쪽 모두 포함된다. 이것은 정수 값에 대해서만 가능하다.
정의 파라미터 내의 변수 값의 포멧팅은 디폴트 포멧이다. 값들의 범위에 대한 포멧팅 문제를 방지하기 위해, 범위 내의 값의 포멧팅은, 특히 선행하는 0에 대해, 시작 및 끝 값의 포멧팅을 따라야 한다. 예를 들어, 범위가 '{8-10}'으로 지정된다면, 생성된 값들은 : '8, 9, 10'이다. 범위가 '{08-10}'으로 지정된다면, 생성된 값들은 '08, 09, 10'이다.
주석(1007)을 참조하여 위에서 간략하게 소개된 바와 같이, 특유의 푸시 헤더는 2개 이상의 변동 부분(즉, 변수)을 갖는 URI 템플릿을 포함할 수 있다. 특유의 푸시 헤더에 의해 정의된 추가 자원들이 서버에 의해 푸시될 순서는, 2개 이상의 변동 부분이 서버에 의해 연속적으로 고려(즉, 확장)되는 방법에 직접 의존한다. 따라서, 이 순서는 특유의 푸시 헤더에서 추론되어야 한다.
uri_template 규칙에서 변수들을 확장하기 위한 예시적인 알고리즘은, 변수들의 순서가 제공된다고 가정하면, 다음과 같다 :
1. uri_template들의 목록 획득하기
첫번째 변수 확장의 경우(제공된 순서에 따른 첫번째), 특유의 푸시 헤더에서 정의된 uri_template이 이용된다.
(제공된 순서에 따른) 후속 변수 확장(들)의 경우, 이전 변수(들)의 확장으로부터 발생한 uri_template들의 목록이 이용된다.
2. 획득된 목록 내의 각각의 uri_template은 다음과 같이 획득된 uri_template들의 목록으로 대체된다:
확장 단계에서 고려되는 변수의 각각의 값에 대해, uri_template이 복제되고 URI 템플릿 내부의 변수가 대체 값 중 하나로 대체된다.
이것은, URI들(또는 헤더 값들)의 최종 목록에서, (예를 들어, 1로 정의된) 첫 번째 순서의 변수가 가장 천천히 변하고 (가장 큰 수로 정의된) 마지막 순서의 변수가 가장 빨리 변한다.
예를 들어, 구성 규칙 <'Push-Request: URI; {1}-{2}; a:b; 1:2'>는 다음과 같은 정렬된 목록으로 이어진다:
- 'a-1'
- 'a-2'
- 'b-1'
- 'b-2'
구성 규칙 <'PushRequest: URI; {2}-{1}; a:b; {1-3}'>는 다음과 같은 정렬된 목록으로 이어진다:
- 'a-1'
- 'b-1'
- 'a-2'
- 'b-2'
- 'a-3'
- 'b-3'
대안으로서, 복수의 변수에 대한 처리 및 대체 순서는 특정한 연산자로서 표현될 수 있다. RFC 6570은 연산자 확장을 위한 일부 문자를 예약한다. 한 실시예에서, '@'문자는 순서를 나타내기 위해 이용될 수 있다 : 연산자의 값이 클수록, 처리 순서가 커진다. 이 대안적인 실시예에서, 상기 2개의 예는 다음과 같이 된다:
구성 규칙 <Push-Request : URI; {foo@1}-{bar@2}; a:b; 1:2> 여기서, "foo" 및 "bar"는 변수 명칭이고 각각 값들 "a" 및 "b"와 "1" 및 "2"로 다음과 같은 순서로 대체된다:
- 'a-1'
- 'a-2'
- 'b-1'
- 'b-2'
구성 규칙 <Push-Request : URI; {foo@2}-{bar@1}; a:b; {1-3}>은 다음과 같은 정렬된 목록으로 이어진다:
- 'a-1'
- 'b-1'
- 'a-2'
- 'b-2'
- 'a-3'
- 'b-3'
상기 예들은 HTTP 헤더에서 하나의 특유의 푸시 헤더를 이용하지만, 다른 실시예들은 2개 이상의 푸시 헤더를 이용할 수 있다.
예를 들어, 클라이언트가 상이한 타입들의 수 개의 자원에 관심이 있고/있거나 구성 규칙을 제공하기가 너무 어려울 때, 특유의 푸시 헤더의 복수의 인스턴스를 이용하기로 결정할 수 있다.
한 예로서, 웹 페이지 다운로드의 가속이 추구된다면, 클라이언트는 웹 페이지를 구성하는 하위 자원의 종류마다 하나의 푸시 헤더를 생성할 수 있다: 이미지에 대해 하나, 스타일 시트에 대해 하나, 스크립트 코드에 대해 하나, 등등).
이러한 상황에서, 각각의 특유의 푸시 헤더의 값은 일부 타입들의 하위 자원들을 필터링하는 필터링 파라미터처럼 거동한다. 하위 자원들이 참조되는 메인 자원은, HTTP 요청에 의해 명시적으로 요청된 자원(즉, request-URI의 자원)일 수 있다는 점에 유의한다.
복수 인스턴스의 푸시 헤더를 갖는 것은 URI/URL들의 추가 목록으로 이어지고, 각각의 인스턴스는 푸시할 별도의 자원 세트를 정의한다.
복수 인스턴스의 특유의 푸시 헤더를 정당화하는 또 다른 경우는, 클라이언트가 초기 요청에서 상이한 지원들로부터의 부분들 : 예를 들어, request-URI의 일부 및 Range 헤더의 바이트 범위 값을 갖기를 원하는 때 또는 2개의 별개의 헤더의 수정을 표시하려고 할 때를 포함한다. 이러한 상황에서, 클라이언트는 2개(또는 그 이상)의 특유의 푸시 헤더를 넣을 수 있다 : 하나는 URI 변경을 위한 것이고 다른 하나는 범위 수정을 위한 것이다. 처리된 헤더들은 새로운 URI들 및 연관된 새로운 바이트 범위들을 갖는 결합된 인스턴스로 이어질 것이다.
복수의 푸시 헤더에 기초한 복수의 헤더 변경의 경우, 각각의 푸시 헤더 처리는 대응하는 대체 값들에 대응하는 URI/헤더들의 세트를 생성하며: 생성된 세트들의 모든 가능한 조합, 즉, 헤더들의 각각의 URI/세트에 대한 대체 값들 사이의 가능한 모든 조합을 제공함으로써 최종 자원 목록이 획득된다는 점에 유의한다.
실시예들에서, 특유의 푸시 헤더는 uri_template 명세에 대한 대안으로 이용될 수 있다.
uri_template 파라미터가 상대 URI를 나타낼 때, 푸시 헤더 프로세서는 절대 URI를 생성하기 위해 원본 request-URI로부터의 상대 경로를 고려해야 한다.
그러나, 실시예들에서, 베이스 URI나 또 다른 베이스 URI는, 또 다른 특정한 헤더에서 또는 Push-Request 헤더 내의 파라미터로서 명시될 수 있다. 이것은, 예를 들어, 매니페스트에서 복수의 BaseURL이 선언되어 있는 DASH에서 유용하다. 따라서, 클라이언트가 일부 자원이 푸시되기를 원한다면, 특유의 푸시 헤더를 갖는 제1 베이스 URL을 이용하여 제1 서버를 테스트할 수 있고, 어떠한 푸시 약속도 수신되지 않는다면, 다음 요청에서 baseURL을 변경하여 제2 서버가 특유의 푸시 헤더를 지원하는지를 테스트할 수 있다.
특유의 푸시 헤더에서 베이스 URI의 변경을 나타내는 예시적인 방법은, uri_template 파라미터 이후에 설정된 추가 파라미터 "var_base"를 포함한다. var_base 파라미터는 새로운 베이스 URI 값을 선언한다.
예를 들어, HTTP 요청의 요청 라인이
GET /server1 /video/segment-1.mp4이면,
특유의 푸시 헤더는 다음과 같을 수 있다
<Push-Request: URI; segment-{1}.mp4; {2-4}; var_base=/AnotherServer/video/>
이 구성 규칙은 다음과 같은 추가 자원들의 목록을 생성한다:
http://AnotherServer/video/segment-2.mp4
http://AnotherServer/video/segment-3.mp4
http://AnotherServer/video/segment-4.mp4
대안으로서, URI 템플릿 RFC 6570을 이용하여 uri_template 파라미터를 선언하는 것 대신에, 정규 표현식이 제공될 수 있다.
상호운용성 목적을 다루는 실시예들에서, 특유의 푸시 헤더는 2개의 별개의 헤더로 분할된다 :
- 클라이언트의 관심대상의 자원을 나타내는 제1 헤더. 이것은 전술된 특유의 푸시 헤더이다;
- 클라이언트가 서버 푸시를 수락한다는 것을 서버에게 나타내는 제2 헤더. 이것은 접속 셋업에서 협상될 수 있지만, 푸시된 데이터를 수락할 수 있을 때 및 푸시를 취소할 위험이 높을 때(예를 들어, 클라이언트가 너무 빈번한 전환을 수반하며 확립된 비디오 모드를 경험하지 못할 때) 클라이언트가 서버에 알려주기 위해 유용할 수 있다.
이 제2 헤더는 또한, 푸시를 지원하지 않는 네트워크 중개자(예를 들어, CDN)들에 대해 유용하다: 이들은 여전히, 제1 푸시 헤더를 네트워크 엣지에 가까운 자원을 미리 가져오기 위한 힌트로 해석할 수 있다.
본 발명의 특유의 푸시 헤더는 스트리밍 클라이언트가 상이한 DASH 상황들을 개선하는 것을 도울 수 있다 :
- 예를 들어, 클라이언트가 다음 세그먼트에 관해 예상하기를 원할 때;
- 또는 클라이언트가 비디오 내의 타임 오프셋을 탐색하고자 할 때;
- 또는 클라이언트가 주어진 기간에 다음 세그먼트를 전송할 것이라고 서버를 신뢰할 때;
- 또는 클라이언트가 스위칭에 관해 예상하려고 할 때;
- 또는 클라이언트가 연관된 자원에 관심이 있을 때;
- 또는 클라이언트가 비-멀티플렉싱된 오디오-비디오 세그먼트를 요청할 때.
이러한 경우에, 비디오 세그먼트를 요청할 때, 그것은 대응하는 오디오 세그먼트에 대한 관심을 나타낼 수 있다.
또 다른 실시예에서, 대체 값들은 또 다른 전용 헤더(이하의 "Push-Values")에 놓여질 수 있으며, 다음과 같은 헤더들의 세트로 이어진다(여기서 헤더 명칭들은 단지 예일 뿐이다):
Push-Request: header_name ";" uri_template
Push-Values: definition [ * (";" definition)]
이 또 다른 실시예에서, 후술되는 예(850)는 다음과 같이 재작성될 수 있다 :
GET /server/video/Rep-R1/segment-01.mp4
Push-Request: URI; segment-{1}.mp4;
Push-Values: 02 : 10
마찬가지로, 후술되는 예(865)는 다음과 같이 된다:
GET /server/video/Rep-R1/segment-01.mp4
Push-Request: URI; Rep-{1}/segment-{2}.mp4
Push-Values: R1 : R2; {01-03}
대안으로서, 하나보다 많은 변수 파라미터가 푸시 특유 헤더에서 선언될 때, 각각의 변수 파라미터에 대한 대체 값은 그 자신의 "Push-Values" 헤더에서 선언될 수 있다. 이러한 경우, "Push-Values" 헤더는 값 또는 값들의 목록 또는 값들의 범위를 후속 동반하는 변수 파라미터 명칭을 포함해야 한다. 예를 들어:
GET /server/video/Rep-R1 /segment-01.mp4
Push-Request: URI; Rep-{var1}/segment-{var2}.mp4
Push-Values: var1=R1 : R2
Push-Values: var2={01-03}
다른 예시적인 재작성은 상기 재작성 예에서 용이하게 추론될 수 있다.
또 다른 대안에서, 도 6b에 도시된 푸시 특유 헤더의 각각의 부분은 대응하는 별개의 헤더에 놓일 수 있다; 예를 들어, 다음과 같다(헤더 명칭은 단지 예일 뿐이다):
Push-Support: URI
Push-Pattern: segment-{var}.mp4
Push-Values: var=02:10
도 7a, 도 7b, 및 도 8을 참조하여, 이제, URI 템플릿을 이용한 DASH에 대한 특유의 푸시 헤더들의 예들이 설명된다.
도 7a 및 도 7b는 DASH 표준을 이용한 HTTP를 통한 적응형 스트리밍의 정황에서 본 발명의 이용 예를 제공한다. 도 7a는, 스트리밍 클라이언트에게 각각의 미디어 세그먼트를 다운로드할 위치(즉, URI)를 표시하는 SegmentTemplate 요소(701)를 포함하는 예시적인 MPD(700)이다. 클라이언트는 원하는 또는 가능한 공간 해상도 및 대역폭에 따라 2개의 대안적인 비디오 Representation(702 및 703) 중에서 선택할 수 있다.
도 7b는, 본 발명이 구현될 때의 클라이언트-서버 교환을 설명하며, 클라이언트와 서버가 HTTP/2를 이용하여 통신한다고 가정한다.
클라이언트(750)는 먼저, 단계 752에서 HTTP GET 요청을 통해 서버(751)에게 MPD, 스트리밍 매니페스트를 요청한다. 단계 753에서, 서버는 HTTP 응답을 전송하여 MPD 파일을 클라이언트에 반환한다.
MPD 수신시, 클라이언트는 단계 754에서 이것을 파싱하여 미디어 디코더를 셋업하기 위한 초기화 정보를 식별한다.
그 다음, 단계 755에서, 클라이언트는 또 다른 HTTP GET 요청을 전송하여 이 초기화 세그먼트를 획득한다. 서버는, HTTP 응답에서, 요청된 초기화 세그먼트 파일을 제공한다. 이것이 단계 756이다.
한편 또는 예속해서(단계 757), 클라이언트는 그 선호도/특성에 따라 적절한 Representation을 식별한다. 이 단계는, 클라이언트가 비디오 판독을 시작하는데 필요한 첫 번째 미디어 세그먼트와, (어떠한 Representation 스위칭 결정도 취해지지 않은 경우) 비디오 판독을 계속하기 위해 다운로드할 다음 세그먼트, 대개는, 동일한 Representation으로부터의 시간적으로 후속하는 미디어 세그먼트를 식별할 수 있게 한다. 클라이언트는, 매니페스트를 이용하여 이/이들 후속 세그먼트(들)에 대한 URI(들)을 추론할 수 있다.
그 다음, 단계 758에서, 클라이언트는 비디오 디스플레이를 시작하기 위하여 제1 미디어 세그먼트를 서버에게 요청한다.
본 발명을 이용하여, 클라이언트는, 요청(758)에서, 다운로드할 다음 미디어 세그먼트에 대한 URI(들)을 삽입한다. 이 삽입은 전용 HTTP 푸시 헤더(예를 들어, 요청 758의 "Push-Request" 헤더)에서 이루어진다. 이 특정한 HTTP 헤더에 대한 값들의 예가 이하에서 도 8을 참조하여 제공된다.
요청(758)에 응답하여, 본 발명을 지원하고 그에 따라 특유의 푸시 헤더를 이해하는 서버는, 자신이 푸시 헤더를 이해하며 자신(서버)이 클라이언트로의 데이터의 푸시의 주도권을 쥘 것이라고 공지한다는 것을 클라이언트에게 통보할 수 있다. 이것은, 서버-개시형 스트림 식별자를 클라이언트에게 제공하는 서버에 의해 전송된 PUSH PROMISE 프레임(759)의 목적이다.
서버는 또한, GET 요청의 목적인, 요청된 제1 세그먼트를, 하나 이상의 DATA 프레임(760)에서, 스트림 식별자로서의 GET 요청(758)의 스트림 식별자와 함께 전송한다.
마지막으로, 단계 759에서 교환된 서버-개시형 스트림 식별자를 참조하여, 서버는 요청(758)의 특정한 헤더에서 표시된 미디어 세그먼트에 대응하는 데이터를 하나 이상의 DATA 프레임(761)을 통해 푸시한다.
특정한 실시예에 따르면, 서버는, 클라이언트로부터의 푸시 요청, 즉, 식별된 추가 자원을 푸시하라는 요청, 식별된 푸시 정책, 전략 또는 지시를 이용하라는 요청, 또는 어떠한 추가 자원도 푸시하지 말라는 요청에 대해 확인응답한다. 이러한 확인응답은 푸시 약속 메시지의 HTTP 헤더에서 전송될 수 있다. 이것은, DASH 응답 헤더 프로세서(386)가 서버에 의해 이용된 푸시 정책을 DASH 제어 엔진(313)에게 통보하는 것을 가능하게 한다.
도 11a 내지 도 11e는, 서버(1101)가 클라이언트(1100)로부터 수신된 푸시 정책의 수신을 확인응답하고 자신이 적용할 또는 적용할 수 있는 푸시 정책에 대해 클라이언트에게 통보할 수 있게 하는, 서버(1101)와 클라이언트(1100) 사이의 푸시 정책 관리의 몇 가지 예를 나타낸다. 이들 예는, MPEG DASH와 같은, HTTP 상의 적응형 스트리밍(스트리밍 매니페스트에 기초하는 방법)에 기초한다.
도 11a는, 스트리밍 매니페스트(DASH의 경우 MPD)에 대한 초기 요청(1102)에서 클라이언트(1100)에 의한 푸시 정책의 표시의 전송을 나타낸다. 전술된 바와 같이, 이 표시는 전용 HTTP 푸시 헤더를 통해 전달될 수 있다.
수신시, 서버(1101)는 단계 1103에서 요청을 처리한다, 즉, 서버는 클라이언트(1100)에 제공될 자원(MPD)을 식별한다. 그 다음, 서버(1101)는 1102로 참조된 초기 요청에 대한 반환 코드와 함께 단계 1104에서 그 응답을 준비한다. 따라서, 요청된 자원이 이용가능하다면, 반환 코드는 HTTP 코드 200이다.
병렬로, 서버(1101)는 전용 HTTP 푸시 헤더에 포함된 푸시 정책 표시를 처리한다. 서버가 헤더를 이해할 수 있고 제안된 푸시 정책을 처리할 수 있다면, 서버는 클라이언트에 의해 제안된 푸시 정책을 확인응답한다. 이것은 1104로 참조된 응답에서 확인응답 데이터를 추가함으로써, 예를 들어, 1102로 참조된 요청에서와 동일한 정책 값을 갖는 동일한 전용 HTTP 푸시 헤더를 추가함으로써(이러한 경우, 푸시 응답 데이터는 푸시 정책 데이터와 동일하다) 이루어질 수 있다.
이것은, 서버가 제안된 푸시 정책을 기꺼이 이용할 것이라는 것을 클라이언트에게 표시한다.
따라서, 이러한 경우에, 1104로 참조된 응답에서 푸시 정책에 확인응답한 후에, 서버는 클라이언트에게 푸시하고자 하는 추가 데이터를 공지하기 시작한다. 이것은, 예를 들어, (DASH에서 세그먼트 당 하나의 PUSH PROMISE 프레임의 경우) HTTP/2로부터의 PUSH_PROMISE 프레임을 이용함으로씨 이루어질 수 있다.
서버는 바람직하게는, 표준에 기초하여, 클라이언트에 의해 1102로 참조된 요청에서 요청된 데이터(즉, MPD 파일)를 1104로 참조된 그 응답에 포함한다는 점에 유의한다.
1104로 참조된 이렇게-생성된 HTTP 응답이 클라이언트에 다시 전송되고 단계 1105에서 클라이언트에 의해 처리되는 동안, 서버는 공지된 추가 데이터(통상적으로, HTTP/2에서, 약속된 자원 당 하나의 DATA 프레임, 즉, DASH의 경우 세그먼트)를 클라이언트에 전송하는데 이용되는 데이터 스트림의 준비를 시작한다(단계 1106).
최종적으로, 클라이언트는 단계 1107 동안 미디어 프리젠테이션을 위한 첫 번째 세그먼트를 수신하기 시작하는 한편, 1102로 참조된 요청에 응답하여 전송된 MPD를 처리함으로써, 네트워크 트래픽을 절약하고 전송 지연을 감소시킨다.
대안으로서, 서버에 의해 전송된 확인응답 데이터는 예를 들어 "OK" 등의 단순한 값을 갖는 또 다른 전용 HTTP 푸시 헤더를 통해 시그널링될 수 있다는 점에 유의한다.
본 발명의 실시예를 구현하는 서버가 클라이언트에 의해 제안된 푸시 정책을 지원하고 적용할 때 서버가 클라이언트에 의해 제안된 푸시 정책에 대해 확인응답하는 것이 권장될 수 있다. 사실상, 이것은, 클라이언트가 서버에 의해 전송된 PUSH_PROMISE 프레임을 수락할지의 여부를 용이하게 결정하기 위한 적절한 정보이다.
클라이언트와 서버 사이의 이러한 첫 번째 왕복에 후속하여, 클라이언트는, 예를 들어, 단계들 1106 및 1107 동안 푸시된 세그먼트들에 후속되는 세그먼트에 대한 요청과 함께, 미디어 프리젠테이션의 스트리밍을 계속하기 위한 요청의 제출을 계속한다(단계 1108). 이 요청 내에서, 클라이언트는, 이전 요청에서와 동일한 푸시 정책 표시를 갖는 전용 HTTP 푸시 헤더를 1108로 참조된 요청에 추가함으로써, 동일한 푸시 정책을 유지하고 있음을 확정할 수 있다.
서버 측에서, 수신된 요청의 처리(단계 1109)는, 요청된 자원의 이용가능성 여부를 확인응답하고(예를 들어, HTTP 상태 코드 200 OK) 전용 HTTP 푸시 헤더에서 적용하고 있는 푸시 정책을 확인응답하는 응답과, 푸시될 추가 데이터 및 요청된 세그먼트 데이터의 공지의 전송(데이터의 실제 푸시는 표시되지 않지만, 응답(1109)을 따른다)으로 이어진다.
도 11b는, 서버가 클라이언트에 의해 제안된 푸시 정책을 구현할 수 없다는 것을 클라이언트에게 통보하는 푸시 정책 통보에 대해 확인응답하는 예를 나타낸다.
서버가 클라이언트에 의해 제안된 푸시 정책 표시를 지원하지 않는 경우, 서버는 단순히 그것을 무시할 수 있다.
그러나, 서버가 클라이언트에게 어떠한 푸시 정책도 이용하지 않을 것이라고 경고하는 것이 유용할 수 있다. 이것은 미래의 요청을 스케쥴링하기 위해 클라이언트에게 유용한 정보이다.
사실상, 클라이언트는 모든 세그먼트를 차례로 요청해야 할 것이다.
이 목적을 위해, 서버는 아무런 푸시도 수행되지 않는다는 것을 나타내는 특정한 푸시 지시, 예를 들어 "푸시-없음" 타입의 푸시 정책과 값이 없는 푸시 정책(또는 도 12b의 참조번호 1231로 등록된 정책)을 이용할 수 있다.
예시된 바와 같이, 제1 단계는, 스트리밍 매니페스트(DASH의 경우 MPD)에 대한 초기 요청(1111)에서 클라이언트(1100)에 의한 푸시 정책의 표시의 전송에 관한 것이다. 전술된 바와 같이, 이 표시는 전용 HTTP 푸시 헤더를 통해 전달될 수 있다.
수신시, 서버(1101)는 단계 1112에서 요청을 처리한다, 즉, 서버는 클라이언트(1100)에 제공될 자원(MPD)을 식별한다. 그 다음, 서버(1101)는 1102로 참조된 초기 요청에 대한 반환 코드와 함께 단계 1113에서 그 응답을 준비한다. 따라서, 요청된 자원을 이용하다면, 반환 코드는 HTTP 코드 200이다.
이 예에서 서버(1101)는 클라이언트에 의해 제안된 푸시 정책을 구현할 수 없다고 가정되기 때문에, 서버(1101)는, 서버가 제안된 푸시 정책을 이용하지 않을 것임을 클라이언트에 표시한다. 이것은, 도 11b(참조번호 1113)에 예시된 바와 같이 아무런 푸시도 수행되지 않을 것임을 나타내는 특정한 푸시 지시를 이용함으로써 이루어질 수 있다.
이러한 정보를 수신하면(단계 1114), 클라이언트(1100)는 단계 1115로부터 모든 세그먼트를 하나씩 요청해야 한다는 것을 안다.
선택사항으로서, (1115로 예시된 바와 같이) 전용 HTTP 푸시 헤더에서 그 요청에서와 동일한 "푸시 금지" 정책 표시를 설정함으로써 서버로부터 푸시된 어떠한 자원에도 의존하지 않는다는 것을 확정할 수 있다.
그 다음, 서버(1101)는 단계 1116에서 수신된 요청을 처리하고, "푸시 금지" 정책을 확인응답함으로써 및 요청에 대응하는 데이터를 전송함으로써 단계 1117에서 그 요청에 응답한다. 이들 2개 단계는 스트리밍 세션의 끝까지 반복된다.
대안으로서, 서버는 예약된 정보 코드(예를 들어, 클라이언트에게 "지원되지 않은 푸시 정책 모드"를 통보하는 103)를 갖는 또 다른 전용 HTTP 푸시 헤더를 이용할 수 있다.
역시 대안으로서, 클라이언트는 HTTP Expect 헤더를 통해 그 푸시 정책을 표시할 수 있고, 서버는 "Expectation failed"에 대한 417 코드를 표시하거나, 더 명확하게는, 클라이언트가 원하는 푸시 모드를 서버가 지원하지 않는다는 것을 나타내는 전용의 예약된 4xx 코드를 표시한다.
또 다른 실시예에서, 본 발명의 실시예를 구현하는 클라이언트는 서버가 본 발명을 지원하는지의 여부를 알지 못한다. 클라이언트가 모든 제어를 유지하기로 결정하고 "푸시 금지" 푸시 정책을 서버에 전송한다면, 서버가 헤더를 이해하지 못하기 때문에 서버에 의해 어떠한 확인응답도 다시 전송되지 않는다.
서버가 본 발명을 구현하지만 클라이언트가 이를 지원하지 않는 다른 실시예들에서, 클라이언트의 요청에서 어떠한 전용 HTTP 푸시 헤더도 수신하지 못한 서버는 "푸시 금지" 정책 표시를 이용해 확인응답하여 아무것도 푸시되지 않을 것임을 클라이언트에게 경고할 수 있다(서버는 클라이언트가 본 발명을 지원하는지의 여부를 알지 못하거나 단순히 선호사항을 표시하는 것을 망각했기 때문). 이렇게 함으로써, 서버는 쓸모없는 데이터를 전송하는 위험을 감수하지 않는다.
이러한 특정한 "푸시 금지" 정책의 목적은 특히 다음과 같은 것들을 나타내는데 이용될 수 있다:
- 클라이언트는 어떠한 푸시에도 관심이 없다; 또는
- 클라이언트는 일부 요청에 대해 푸시를 중단하기를 원한다.
이것은, 서버 푸시의 이용이 허용되는지를 서버에게 표시하기 위해 클라이언트에 의해 이용될 수 있는, HTTP/2에 의해 정의된 기존 SETTINGS_ENABLE_PUSH 설정 파라미터보다 세밀한 제어를 제공한다. 이 설정 파라미터는, 서버 푸시와 관련하여 어떠한 세분된 협상이나 제어 메커니즘도 제공하지 않는다. 사실상, 클라이언트와 서버가 이러한 협상 수단을 갖는 것이 유용할 수 있다. 예를 들어, SETTINGS_ENABLE_PUSH 설정 파라미터의 값은 서버가 서버 푸시를 이용하는 것을 허용하만, 클라이언트는 스트리밍 세션 내의 일부 또는 모든 요청에 대해 서버 푸시를 허용하지 않기를 원할 수도 있다. 예를 들어, 이것은 비디오 요소를 임베딩하고 있는 웹 페이지를 로딩할 때 클라이언트에게 유용할 수 있다. 클라이언트는, 푸시될 웹 페이지와 연관된 자원들(CSS, 이미지, 자바 스크립트)을 갖지만 미디어 세그먼트는 갖지 않는 것에 관심을 가질 수도 있다. 이러한 경우, 데이터를 푸시하는 것은 전체 접속에 대해 인에이블되지만 특정한 DASH 콘텐츠에 대해서는 클라이언트는 미디어 서버가 데이터를 푸시하는 것에 대해 선호를 표시할 것이다.
도 11c는, 클라이언트가 스트리밍 매니페스트에 대한 초기 요청에서 수 개의 푸시 정책을 제안하는, 푸시 정책 통보를 확인응답하는 예를 나타낸다. 즉, 도 11a 및 도 11b를 참조하여 설명된 바와 같이 하나의 단일 푸시 정책을 제안하는 것 대신에, 클라이언트는 지원하는 푸시 정책들의 목록을 전송한다.
예시된 바와 같이, 제1 단계는, 스트리밍 매니페스트(DASH의 경우 MPD)에 대한 초기 요청(1119)에서 클라이언트(1100)에 의한 지원하는 푸시 정책들의 목록의 전송에 관한 것이다. 이러한 목록은 바람직하게는 정렬된다(선호도 순서, 도 11c에는 표시되지 않음).
이 목적을 위해, 전용 HTTP 푸시 헤더는 생성되어 정책의 타입과 선호도 순서에 대한 선택사항적 파라미터를 전달한다. 예를 들어, 전용 HTTP 푸시 헤더는 기존의 Accept HTTP 헤더(https://tools.ietf.org/html/rfc7231#section-5.3.2를 참조)와 유사하게 "Accept-Push-Policy" HTTP 헤더로서 정의된다.
Accept 헤더는 주어진 미디어-타입에 다음과 같은 것들을 갖는 것을 허용한다 :
0*(0 이상) 특정한 미디어 타입 파라미터(예를 들어, charset); 이것은 예를 들어 요청을 발행하는 클라이언트에 의해 지원되는 미디어 타입들의 목록일 수 있다: *.jpg, *.png
0-1 "q" 파라미터(상대적 가중치 표시용)
0* 확장 파라미터("q" 파라미터는 임의의 확장 파라미터가 있는 경우 분리자로서 필수이다).
이것은 전용 HTTP 푸시 헤더로 이어질 것이다:
Accept-Push-Policy: <urn> [';' <urn-specific-param>*]; q=<N>
여기서 "q" 파라미터는 일부 전역 파라미터가 있는 경우 필수이다.
"q" 파라미터는, 상기 표현식의 정책 파라미터(들), <urn-specific-param>을, 있다면 (상기 표현식의 <urn>에 의해 표시된) 정책 타입으로부터 분리시키는, 품질 계수(quality factor)이다.
품질 계수는, 사용자 또는 사용자 에이전트가 0에서 1까지의 q 값 스케일을 이용하여, 정책 타입 및/또는 정책 값에 대한 상대적 선호도를 표시하는 것을 허용한다. 디폴트 값은 q = 1(더 높은 품질 계수 또는 선호되는 값)이다.
설명의 목적을 위해, 클라이언트는, 푸시 헤더 내의 다음과 같은 통보를 이용하여 하나의 요청된 세그먼트에 이어지는 다음 5개의 세그먼트를 푸시하도록 서버에게 요청할 수 있다:
Accept-Push-Policy: urn:mpeg:dash:fdh:push-next; 5
여기서, 첫번째 부분인 URN은 이용하려는 푸시 지시 또는 푸시 정책의 타입을 고유하게 식별한다. 분리자에 후속하는 두번째 파라미터(선택사항)는 이 푸시 정책에서 적용할 파라미터에 대응한다.
대안으로서, 정책 타입과 값 파라미터 사이의 다른 분리자들은 HTTP 헤더 값에서 분리자로서 이용될 수 있다(RFC 2616 참조).
클라이언트가 자신의 선호도에 따라 푸시 정책들의 정렬된 목록을 표시하는 것을 허용하는 대안적인 실시예는, 예를 들어 라이브 시나리오에서 서버에게 소정의 "다음" 세그먼트들을 이들이 서버상에서 준비되자마자 푸시할 것을 표시하기 위해 "q" 파라미터를 이용하는 것이다(도 12b의 참조번호 1230에 따라 등록된 표준 푸시 정책), 바람직하게는 3개의 세그먼트, 그렇지 않으면 5개의 세그먼트가 다음과 같이 표현될 수 있다:
Accept-Push-Policy: urn:mpeg:dash:fdh:push-next;3,
urn:mpeg:dash:fdh:push-next;5; q=0.5
클라이언트가, (초기화 및 첫 번째 비디오 세그먼트를 푸시하라는, MPD 요청으로부터의) 비디오의 (여기서는 아마도 도 12b의 1230에 따라 등록될 수도 있는, 독점적 푸시 정책으로부터의) 빠른 시작을 가능하게 하는 푸시 정책을 나타내는 또 다른 예로서, 선호도 순서 품질 레벨로서, 푸시 정책들의 정렬된 목록은 다음과 같이 표현될 수 있다:
Accept-Push-Policy: urn:canon:dash:fdh:push-fast-start;high,
urn:canon:dash:fdh:push-fast-start;mid; q=0.7,
urn:canon:dash:fdh:push-fast-start;low; q=0.3
또는 해상도에 대한 선호에 의해:
Accept-Push-Policy: urn:canon:dash:fdh:push-fast-start;HD,
urn:canon:dash:fdh:push-fast-start;SD; q=0.7
클라이언트가 다양한 종류의 데이터를 푸시할 것을 서버에 표시하기 위해, q에 대해 동일한 값을 갖는 2개의 상이한 푸시 정책들에 대한 표시를 요청 내에 포함시킬 수 있다. 이것은 그 요청에 대한 응답으로 적용될 2개의 정책으로서 서버에 의해 해석되어야 한다.
서버가 양쪽 모두를 적용할 수 있다면, 서버는, 그 응답 내의 전용 HTTP 푸시 헤더 내에, 동일한 q 값을 가진 이들 2개의 푸시 정책을 포함시킴으로써 클라이언트 제안에 확인응답한다.
반대로, 이들 둘 중 하나만 적용될 수 있다면, 이용된 푸시 정책을 전용 HTTP 푸시 헤더의 값으로서 이용하여 클라이언트 제안에 확인응답한다.
제안된 2개의 푸시 정책 중 어느 것도 적용될 수 없다면, 서버는, 푸시 금지 정책의 식별자(예를 들어, 등록된 값 1231 또는 이 목적을 위해 특별히 정의된 임의의 푸시 정책 타입)를 전용 HTTP 푸시 헤더에 추가함으로써 클라이언트의 제안에 확인응답한다.
도 11c로 돌아가서, 서버(1101)는, 단계 1120에서, 빠른 시작에 관한 것일 수 있는, 수신된 요청(1119)을 처리한다.
그 요청에 응답하여, 서버(1101)는 초기 요청에 대한 반환 코드와 함께 단계 1121에서 그 응답을 준비한다. 따라서, 요청된 자원이 이용가능하다면, 반환 코드는 HTTP 코드 200이다.
또한, 서버(1101)는, 잠재적으로 자신의 선호도와 일치하는 순서를 재고려하는, 동일한 Accept-Push-Policy 전용 HTTP 푸시 헤더를 이용하거나(이러한 경우, 첫 번째 것은 푸시할 다음 데이터를 공지하는데 이용되는 것이다), 바람직하게는 실제로 이용할 푸시 정책만을 목록으로부터 전달하는 또 다른 전용 HTTP 푸시 헤더를 이용함으로써, 클라이언트(1100)에 의해 제안된 푸시 정책들 중 하나를 확인응답한다.
예를 들어, 이러한 전용 HTTP 푸시 헤더는, "DASH-PUSH": urn:canon:dash:fdh:push-fast-start;low(여기서, 헤더의 명칭("DASH-PUSH")은 예로서 주어진 것이다)이거나, 파라미터의 정확한 값을 제공하지 않는 정책의 타입만일 수 있다, 예를 들어, "DASH-PUSH": urn:canon:dash:fdh:push-fast-start일 수 있다(이 경우 서버가 푸시할 미디어의 버전을 선택하게 한다).
이러한 확인응답 데이터는 단계 1122에서 클라이언트(1100)에 의해 수신된다.
병렬로, 서버(1101)는 공지된 추가 데이터를 클라이언트에 전송하는데 이용되는 데이터 스트림의 준비를 시작하고(단계 1123), 대응하는 데이터를 전송한다.
푸시된 데이터의 수신(단계 1124) 후에 클라이언트(1100)에 의해 전송된 다음 요청은, 다시 한번, 푸시 정책 표시, 예를 들어, 서버에 의해 확인응답된 선호되는 정책을 포함할 수 있다.
서버(1101)가 MPD 요청 내에서 수신된 제안된 푸시 정책들(단계 1120) 중 어떠한 것도 지원하지 않는 경우, 서버는, (예를 들어, 도 12b에서 1231로 참조된 등록된 URN, urn:mpeg:dash:fdh:push-none, 또는 그 목적을 위해 특별히 정의된 임의의 푸시 정책 타입을 통해) 전용 HTTP 푸시 헤더를 "푸시 금지" 정책으로 설정함으로써 클라이언트의 제안을 확인응답할 수 있다.
도 11d는, 클라이언트가 스트리밍 매니페스트에 대한 초기 요청에서 "푸시 금지" 정책을 제안하는, 푸시 정책 통보를 확인응답하는 예를 나타낸다. 다시 말해, 도 11d는 클라이언트가 처음에 Representation 선택에 관한 제어를 유지하기를 원하는 경우를 나타낸다.
예시된 바와 같이, 제1 단계는, 스트리밍 매니페스트(DASH의 경우 MPD)에 대한 초기 요청(1131)에서 클라이언트(1100)에 의한 "푸시 금지" 정책 표시의 전송에 관한 것이다.
따라서, 초기 요청(1131)은, 서버가 어떤 것을 푸시하는 것을 클라이언트가 원하지 않는다는 것을 명확하게 나타낸다. 예시의 목적을 위해, 이러한 "푸시 금지)" 정책은 다음과 같을 수 있다 : 도 12b의 참조번호 1230에 등록된, urn:mpeg:dash:fdh:push-none.
이러한 예는, 세션 시작시, 클라이언트가 빠른 시작에 관심이 없는 경우에 대응하므로, 서버로부터의 임의의 푸시를 방지한다(디폴트로, HTTP/2 서버는 클라이언트와 관련없는 무엇인가를 전송할 위험성을 갖고 푸시에 관한 주도권을 가질 수 있다).
도 11d에 도시된 바와 같이, 서버(1101)는 1133으로 참조된 그 응답에서 이 푸시 금지 정책에 확인응답한다.
요청 세그먼트들에 대해, 클라이언트는 MPD를 분석하여(단계 1134) 그것이 요청하는 것이 무엇인지를 더 잘 알게 되고, 그 분석의 결과로서, 서버에게 하나 또는 복수의 푸시 정책을 제안한다(단계 1135).
이에 응답하여, 서버(1101)는 약속된 데이터(표시되지 않음)를 푸시하도록 도 11a 또는 도 11c를 참조하여 설명된 바와 같이 푸시 정책에 확인응답한다.
당연히, 스트리밍 세션의 빠른 시작을 위한 푸시 정책은 다른 목적을 위해 이용될 수 있다. 예를 들어, 클라이언트는 MPD 요청 시간에서 푸시 정책을 표시하고(단계 1131), 서버는(도 11a 또는 도 11c를 참조하여 앞서 설명된 바와 같이) 긍정적으로 또는 부정적으로 확인응답하고, 결국 클라이언트에게 제1 세그먼트를 푸시할 것을 약속한다. 그 다음, 세그먼트들에 관한 연속된 요청들에 대해, 클라이언트는, 그 선택된 푸시 정책 또는 특정한 "푸시 금지" 정책을 이용함으로써 전송에 관한 모든 제어를 유지하기를 원하는지를 표시함으로써 서버가 푸시를 계속 유지할 것이라고 신뢰할 수 있는지를 결정할 수 있다.
클라이언트에 의해 표시된 푸시 정책이 무엇이든, 서버가 클라이언트에 의해 제안된 임의의 푸시 정책을 처리할 수 없고/없거나 대응하는 특정한 HTTP 헤더를 처리할 수 없다면(예를 들어, 도 6a의 테스트(604)가 거짓인 경우), 서버는 어떠한 종류의 확인응답도 전송할 수 없고, 그에 따라, 단순히 클라이언트로부터의 힌트를 무시할 것이라는 점에 유의한다.
반대로, 클라이언트에 의해 제안된 푸시 정책(또는 지시)을 처리하도록 구성되고 이것을 적용하기로 결정한 DASH 서버는, 푸시 정책(또는 지시)의 URN을 있다면 허용된 파라미터 값들과 함께 그 응답에서 이용함으로써 클라이언트 요청을 확인응답해야 한다. 복수의 푸시 정책이 클라이언트에 의해 표시되고 서버가 클라이언트에 의해 제안된 푸시 정책들의 목록의 푸시 정책들 중 하나를 지원하는 경우, 적용된 푸시 정책의 URN을 전용 HTTP 푸시 헤더에 넣음으로써 이용하기로 계획한 푸시 정책을 확인응답해야 한다.
선택사항으로서, 서버는, 이하에서 설명되고 도 11e에 예시된 바와 같이 다양한 방식으로 자신이 구현하는 대안적 푸시 정책들의 목록을 광고할 수 있다.
서버가 클라이언트에 의해 제안된 푸시 정책을 지원하지 않는 경우, 서버는 "푸시 금지" 전략에 대한 URL, 즉, urn:mpeg:dash:fdh:push-none을 이용함으로써 클라이언트에게 통보해야 한다. "푸시 금지" 정책을 동반한 확인응답 외에도, 또 다른 전용 HTTP 푸시 헤더에서, 자신이 지원하는 하나의 푸시 정책 또는 푸시 정책들의 목록을 공지할 수 있다. 확인응답과의 차이를 명확하게 하기 위해, 서버는 바람직하게는 또 다른 전용 HTTP 푸시 헤더를 이용한다. 하나의 푸시 정책을 공지하는지 또는 푸시 정책들의 목록을 공지하는지에 따라, Accept-Push-Policy 헤더 내에 주어진 신택스를 이용할 수 있다.
푸시 정책이 비-푸시 가능 서버(즉, 임의의 클라이언트로부터의 임의의 푸시 정책을 이해하지 못하는 서버, 예를 들어, 도 6a의 테스트(604)가 거짓인 서버)로 어드레싱될 때, 어떠한 종류의 확인응답도 없을 것이고 어떠한 푸시 정책의 광고도 클라이언트에게 시그널링될 수 없다는 점에 유의한다.
클라이언트가 푸시 정책을 제안하는 것을 돕기 위하여, 서버는 자신이 지원하는 푸시 정책들의 목록을 클라이언트에 전송할 수 있다. 이것은 다수의 방식으로 이루어질 수 있다.
예시의 목적을 위해, 서버에 의해 지원되는 푸시 정책들의 목록은 MPD에서 콘텐츠를 생성할 때 결정될 수 있고 하나 또는 수 개의 DASH 설명자로서 추자에 추가될 수 있다. 이들은, 원래의 서버에 의해 또는 Content Delivery Network 내의 서버들에 의해 지원되는 푸시 정책들의 표시를 제공한다.
이것은 또한, 이들이 DASH를 인식하는 경우 네트워크 중개자들에 의해 수행될 수도 있다.
이러한 기술자(descriptor)는, 특정한 scheme_id_uri 속성(예를 들어, "urn:mpeg:dash:fdh:pushDirective")에 의해 식별될 수 있다. 이러한 기술자에 대한 속성 값은, 푸시 정책의 타입(예를 들어, "urn:mpeg:dash:fdh:push-next" 또는 "urn:mpeg:dash:fdh:push-none")을 포함한다.
선택사항으로서, 다른 속성(예를 들어, param)은 푸시할 다음 세그먼트들의 개수와 같은 정책 파라미터를 포함할 수 있다. 이것은 다음과 같이 씌어질 것이다:<SupplementalProperty scheme_id_uri="urn:mpeg:dash:fdh:pushDirective" value=" urn:mpeg:dash:fdh:push-next" param="5" />. scheme_id_uri 및 value 속성들에 대한 값들은, DASH 표준에 의해 또는 최소한 1230 등의 등록 기관에 의해 정의되는 것으로 가정된다. 이것은, 예를 들어, scheme_id_uris를 통한 DASH, DASH 산업 포럼, 또는 대응하는 푸시 전략의 이점을 취하기 위해 클라이언트 및 서버에 관한 연관된 가이드라인들을 갖는 IANA일 수 있다.
또 다른 예에 따르면, 특정한 HTTP 헤더 필드, 예를 들어, "Supported-Push-Policies"는, 서버에 의해 지원되는 푸시 정책을 설명하는데 이용될 수 있다. 기본 구현에서, 이 헤더 필드의 값은, 지원되는 푸시 정책들의 식별자들의 콤마-분리된 목록이다.
이러한 특정한 HTTP 헤더 필드는, 예를 들어, 다음과 같다:
Supported-Push-Policies:urn:dash:adobe:k-push,urn:dash:canon:fast-start
더 풍부한 구현에서, 각각의 정책에 대해 지원되는 파라미터 값들은, ','로서, 분리된 목록으로서, 또는 범위로서 기술될 수 있다.
이러한 특정한 HTTP 헤더 필드는, 예를 들어 (정책 타입과 그 파라미터들 사이의 분리자로서 이용), 다음과 같을 수 있다:
Supported-Push-Policies: urn:dash:adobe:k-push;0-100, urn :dash :canon :fast-start ;low :medium
서버는 또한, 각각의 정책에 대한 "q" 파라미터를 추가함으로써 각각의 정책에 대한 그 선호도를 표시할 수 있다.
이러한 특정한 HTTP 헤더 필드는, 예를 들어, 다음과 같다:
Supported-Push-Policies: urn:dash:adobe:k-push;0-100;q=0.4, urn:dash:canon:fast-start;low:medium;q=0.9
예를 들어 웹 페이지의 애플리케이션 코드에서, HTML 메타 태그는 클라이언트가 전송을 향상시키기 위해 이용할 수 있는 일부 정책들을 나열할 수 있다.
이러한 HTML 메타 태그는, 예를 들어, 다음과 같다:
<meta name= ≪dash:fdh:pushDirective ≫ content= ≪ urn
:one_push_directive_ID≫ />
여기서 name 속성에 허용된 새로운 "dash:fdh:pushDirective" 값은 기존 확장 목록 : https :// wiki . whatwg . org / wiki / MetaExtensions 내에 등록될 수 있다. 이러한 등록은, 애플리케이션 서버가, 예를 들어 <video> 요소로서 웹 페이지에 내장된 미디어의 전달을 최적화하는 전략을 고려했다는 것을 웹 클라이언트가 통보받을 수 있게 한다. content 속성에 넣을 값은 도 12b의 1230에서 참조된 등록된 값들 중 하나 일 수 있다.
도 8은 DASH를 이용한 적응형 스트리밍의 경우 푸시 헤더들의 다양한 예들을 제공한다. 미디어(비디오)는 2개의 별개의 표현인 R1(810) 및 R2(820)로서 이용가능하며, 양쪽 모두는 시간적으로 정렬된 비디오 세그먼트(811 및 821)를 포함한다.
제1 예(830)는 표현 R1의 제1 세그먼트에 대한 클라이언트의 요청을 나타낸다. 이 요청은 또한, 푸시 헤더 "Push-Request"를 통해, 클라이언트가 세그먼트 번호 2를 미래의 세그먼트로서 관심이 있음을 나타낸다. 이렇게 하기 위해, 푸시 특유 헤더는 서버가 request-URI의 중괄호로 묶인 패턴 (헤더의 첫 번째 파라미터 : "URI"로 표시됨), 즉, request-URI 내의 문자열 "01"을, 마지막 파라미터(예(830)의 "02")에서 제공된 값들로 수정해야 한다는 것을 나타낸다. 한 대안은 다음과 같은 정규 표현식을 통해 대체 규칙을 나타낼 수 있다: Push-Request: URI; -＼(＼d＼+＼), -＼(%02d:＼1+1＼).
제2 예(840)는 표현 R1의 제1 세그먼트에 대한 클라이언트의 요청을 나타낸다. 이 요청은, 푸시 헤더 "Push-Request"를 통해, 클라이언트가 세그먼트 번호 02, 03, 04 및 05를 미래의 세그먼트로서 관심이 있음을 나타낸다. 미래 세그먼트들의 이 목록은 여기서는 간결성 및 간소화 목적을 위해 범위로서 표현된다. 다시 한번, 중괄호들 사이의 패턴은, 제공된 범위로 설정된 값들에 의해 초기 request-URI에서 반복적으로 대체되어 4개의 URL의 대응하는 목록을 구축해야 한다.
제3 예(850)는 표현 R1의 제1 세그먼트에 대한 클라이언트의 요청을 나타낸다. 이 요청은 또한, 푸시 헤더 "Push-Request"를 통해, 클라이언트가 세그먼트 번호 02 및 10을 미래의 세그먼트로서 관심이 있음을 나타낸다. 세그먼트 번호에 대한 관심은 클라이언트가 동영상을 빠르게 브라우징하는 것을 허용할 수 있다. 그 다음, 대체 값들은 콜론으로 분리된 값들의 목록으로서 제공된다. 더 많은 세그먼트(번호 02 내지 04, 및 10 내지 13)가 클라이언트에게 관심대상이 될 경우, 이들은 다음과 같이 범위들의 목록을 통해 시그널링될 수 있다:
Push-Request: URI; segment-{1}.mp4; {02-04} : {10-13}
제4 예(860)는 표현 R1의 제1 세그먼트에 대한 클라이언트의 요청을 나타낸다. 이 요청은 또한, 푸시 헤더 "Push-Request"를 통해, 클라이언트가 Representation R2 내의 세그먼트 번호 01을 미래의 세그먼트로서 관심이 있음을 나타낸다. 이것은, Representation R2가 베이스 버전 R1의 강화된 버전일 때 스케일링가능한 비디오에 대해 유용할 수 있다. 이 예는, request-URI 내의 대체할 (중괄호 사이의) 2개의 패턴의 존재에 의해 표시되는 request-URI 내의 복수의 패턴의 변형을 나타낸다.
제5 예(865)는 표현 R1의 제1 세그먼트에 대한 클라이언트의 요청을 나타낸다. 이 요청은 또한, 푸시 헤더 "Push-Request"를 통해, 클라이언트가 우선 Representation R2 내의 세그먼트 번호 01, Representation들 R1 및 R2 내의 세그먼트 02, 및 마지막으로 양쪽 Representation "R1" 및 "R2" 내의 세그먼트 03을, 미래의 세그먼트로서 관심있다는 것을 나타낸다. 이것은, (중괄호 사이의) 2개의 패턴의 존재에 의해 표시되며, 각각은 대체 순서를 나타낸다. 이 예에서, 제1 값 세트의 값들 "R1" 및 "R2"를 갖는 표현 식별자가 먼저 고려된 다음, 01 내지 03(양쪽 끝 값 포함) 범위의 값을 갖는 세그먼트 인덱스가 고려된다.
복수의 파라미터(2개의 표현들 각각에 관한 세그먼트 01 내지 03까지)를 반복하는 특별한 경우에 대해, 표현 R1 내의 제1 세그먼트는 두 번 제공된다(요청된 제1 세그먼트로서 한번, request-URI 참조; 및 푸시된 데이터로서 한번)는 점에 유의한다. 따라서, 서버는 획득된 URL들의 목록을 필터링하여 초기 request-URI에 대응하는 URL을 삭제할 수 있다.
제6 및 제7 예(870 및 880)는, 미디어 세그먼트들이 바이트 범위를 통해 어드레싱될 때, 예를 들어 미디어 세그먼트들이 세그먼트들의 바이트 범위를 제공하는 SegmentURL을 포함하는 SegmentBase 요소로서 기술되는 MPD에서, 헤더 이용을 나타낸다.
예(870)는 표현 R1의 제1 바이트에 대한 클라이언트의 범위 요청을 나타낸다. 이 요청은 또한, 푸시 헤더 "Push-Request"를 통해, 클라이언트가, "Rep-R1.mp4" 파일의 2001 바이트 오프셋에서 시작하여 3000 바이트 오프셋에서 끝나는 바이트 범위를 미래의 자원 부분으로서 관심있다는 것을 나타낸다.
제7 예(880)는 표현 R1의 제1 바이트에 대한 클라이언트의 범위 요청을 나타낸다. 이 요청은 또한, 푸시 헤더 "Push-Request"를 통해, 클라이언트가, "Rep-R1.mp4" 파일의 바이트 범위들의 목록, 먼저 2001 내지 3000(양쪽 끝 값 포함), 및 그 다음, 3001 내지 4000(양쪽 끝 값 포함)을 미래의 자원 부분으로서 관심있다는 것을 나타낸다.
도 8의 8번째 및 마지막 예(890)는 초기화 세그먼트에 대한 클라이언트의 요청을 나타낸다. 이 요청은 또한, 푸시 헤더 "Push-Request"를 통해, 클라이언트가 주어진 세그먼트를 미래의 세그먼트로서 관심있다는 것을 나타낸다; 여기서 패턴 식별도 없고 대체 값도 없이, 명시적이고 절대적인 URI가 제공된다.
상기 설명은 주로, 아마도 구성 규칙을 통해, 푸시될 특정한 자원을 정의하는 특유의 푸시 헤더에 중점을 둔다.
서버가 자원 타입을 자원 폴더에 맵핑하는 정적 구성 파일을 서버가 포함하는 일부 실시예들에서, 클라이언트는 특유의 푸시 헤더를 이용하여 클라이언트의 관심 자원을 필터링할 수 있다. 이러한 필터링은 예를 들어 전술된 단계 606 동안 발생할 수 있다.
이 필터링 접근법은, 클라이언트가 특유의 푸시 헤더에서 특정한 자원이나 적어도 이들 특정한 자원을 식별하는 규칙이 아니라 자원의 종류를 나타낼 때 유용할 수 있다.
예를 들어, 도 12a 및 도 12b를 참조하여 설명된 바와 같이, 푸시 정책들 또는 푸시 지시들을 명확하게 지정하기 위해 고유 식별자(예컨대, URN)들을 이용하는 것과 같은 대안들이 존재한다.
도 12a는, 스트리밍 매니페스트(DASH의 경우 MPD)에 대한 초기 요청(1201)에서 클라이언트(1200)에 의한 푸시 정책의 표시의 전송을 나타내고, 여기서, 상기 표시는 푸시 정책과 연관된 고유 식별자이다. 전술된 바와 같이, 이 표시는 전용 HTTP 푸시 헤더를 통해 전달될 수 있다.
수신시, 서버(1210)는 단계 1203에서 요청을 처리한다, 즉, 서버는 클라이언트(1200)에 제공될 자원(MPD)을 식별한다. 그 다음, 서버(1210)는 초기 요청에 대한 반환 코드와 함께 응답을 준비한다. 따라서, 요청된 자원이 이용가능하다면, 반환 코드는 HTTP 코드 200이다.
병렬로, 서버(1210)는 전용 HTTP 푸시 헤더에 포함된 고유 식별자의 함수로서 제안된 푸시 정책을 식별한다. 서버가 헤더를 이해할 수 있고 제안된 푸시 정책을 처리할 수 있다면, 서버는 클라이언트에 의해 제안된 푸시 정책을 확인응답한다. 이것은 응답(1204)에서 고유 식별자를 부가함으로써 이루어질 수 있다.
이것은, 서버가 제안된 푸시 정책을 기꺼이 이용할 것이라는 것을 클라이언트에게 표시한다.
푸시 정책들과 연관된 고유 식별자들은, 중앙집중식 레지스트리에서, 예를 들어, 도 12b에 나타낸 중앙집중식 레지스트리(1230)에서 정의될 수 있다. URN은 푸시 정책(또는 지시)을 고유한 식별을 허용한다. 푸시 정책(또는 지시)이 파라미터들을 요구할 때, 푸시 정책이 명확하게 지정되도록 상기 레지스트리로부터 링크된 명세에서 정의되어야 한다.
어떠한 중앙집중식 레지스트리도 정의되지 않은 경우, 전용 HTTP 푸시 헤더는 푸시 정책의 타입(예를 들어, 푸시될 세그먼트 수, 세그먼트가 푸시되어야 하는 지속기간, 또는 MPD 업데이트를 푸시하라는 표시)을 전달할 수 있다.
예시의 목적을 위해, 전용 HTTP 푸시 헤더에서 전달될 수 있는 푸시 정책의 타입은 다음과 같을 수 있다("Push-Request"는, 이 예에서, 전용 HTTP 푸시 헤더의 명칭임):
Push-Request: push-next
Push-Request: push-time
Push-Request: fast-start
Push-Request: mpd-update
선택사항으로서, 전용 HTTP 푸시 헤더는, 푸시 정책의 타입 및 제안된 푸시 정책에 대한 파라미터들(예를 들어, 세그먼트 수 및 푸시 지속기간(초 단위))를 전달할 수 있다. 따라서, 전용 HTTP 푸시 헤더 및 연관된 파라미터에서 전달될 수 있는 푸시 정책의 타입은 다음과 같다(여기서는 정책 타입과 파라미터 사이의 분리자를 이용):
Push-Request: push-next; 5
Push-Request: push-time; 2
Push-Request: fast-start; 2
Push-Request: mpd-update; patch
Push-Request: push-next;
더 일반적으로, 전용 HTTP 푸시 헤더는 다음과 같이 표현될 수 있다:
Push-Request: URN *[';' <urn-specific-params>]
마지막 예는 특정적이며 주어진 세그먼트로부터 모든 후속하는 것들의 푸시를 계속할 것을 서버에게 표시하는 것을 목표로 한다(즉, 클라이언트로부터 서버 주도형 모드).
몇 가지 가능한 값들과 연관된 일부 정책 타입들의 경우, 타입 + 파라미터를 하나의 URN으로서 등록하는 것이 유익할 수 있다는 점에 유의한다, 예를 들어 :
urn:mpeg:dash:fdh:2015:push-next-*
또는
urn:mpeg:dash:fdh:2015:push-time-2.
특정한 실시예들에 따르면, 푸시 정책을 푸시할 데이터 타입의 함수로서 제안하도록 푸시할 데이터의 관점에서 클라이언트가 자신의 희망사항을 명확하게 표현하도록 하는 옵션이 클라이언트에게 제공된다. 따라서, 사용자는, 도 12b의 중앙집중식 레지스트리(1230)에 나타낸 바와 같이, 세그먼트들에 관련된 푸시 전략들에 대한 세트 및 MPD 업데이트에 관련된 푸시 전략들에 대한 또 다른 세트를 정의할 수 있다.
이러한 실시예는, 클라이언트가 업데이트 프로세스를 자동화할 수 있도록, 특정한 MPD 업데이트 푸시 정책을 갖기 위해 유용한 것으로 드러났다. 사실상, MPD 업데이트 푸시를 제안하고 확인응답하는 것은, (통상적으로 MPD가 업데이트될 때 서버에 의해 이루어지는) MPD 만료 날짜를 나타내기 위해 미디어 세그먼트 내에 특별한 메타데이터 박스를 추가하는 것을 회피할 수 있게 한다.
예를 들어, 스트리밍 세션 중 소정 시점에서 확인응답된 MPD 업데이트에 대한 푸시 정책은, 서버가 MPD 업데이트를 푸시할 것을 약속하고 있다는 것을 클라이언트에 통보할 것이다.
게다가 상이한 종류들의 MPD 업데이트 푸시 정책들을 갖는 것은, 서버가 전체 MPD를 재전송할지(예를 들어, URN: urn:mpeg:dash:fdh:push-mpd-full) 또는 패치만을 전송할지(urn:mpeg:dash:fdh:push-mpd-patch)를 클라이언트가 통보받는 것을 허용할 수 있다. 대안으로서, MPD 업데이트에 대한 하나의 푸시 정책만이 정의될 수 있고, 전체 모드 또는 패치 모드가 파라미터가 된다.
도 11a 내지 도 11e는 이들 2종류의 푸시 정책의 이용을 나타낸다. 도 11a 내지 도 11e를 참조하여 설명되는 바와 같이, 클라이언트는 MPD를 요청함으로써 시작한다. 한편, 클라이언트는 MPD 업데이트와 세그먼트 양쪽 모두의 푸시 또는 이들 2개 종류의 데이터 중 하나만의 푸시에 대한 관심을 표시할 수 있다. 유사하게, 세그먼트에 대한 요청을 준비할 때, 클라이언트는 MPD 업데이트와 세그먼트 양쪽 모두 또는 이들 2개 종류의 데이터 중 하나에 대해서만 관심을 표시할 수 있다.
사실상, MPD-특유의 정책의 이용은, 언제라도 MPD 업데이트에 대한 희망을 표시하도록 세그먼트에 대한 요청에서 허용되어야 한다. 마찬가지로, MPD를 요청할 때 세그먼트-관련된 푸시 정책을 이용하는 것은, 클라이언트가 빠른 시작 스트리밍 세션을 갖는 것을 허용한다.
스트리밍 애플리케이션에 관한 주어진 예는, 예시의 목적을 위해 HTTP/2 프로토콜을 기반으로 하지만, WebSocket 등의 다른 양방향 프로토콜도 역시 이용될 수 있다는 점에 유의한다. 특히, 전용 HTTP 푸시 헤더는 다음과 같이 WebSocket의 바인딩에서 대체될 수 있다:
- URL : 요청된 자원의 URL을 나타낸다. 대응하는 JSON 파라미터는 "url"이다.
- PushDirective : 클라이언트가 선택한 PushDirective의 URN을 나타내며 JSON 명칭 "PushDirective"를 갖는다.
- pushDirective에 고유하고 이에 의해 정의된 값들을 나타내는 선택사항적 pushParams.
마찬가지로, 확인응답 메커니즘은 일부 전용 WebSocket 프레임들에서 JSON 파라미터를 이용할 수 있다.
예를 들어, 서버는 상이한 폴더들에서 데이터를 호스팅할 수 있다. 'path'는 메인 자원에 도달하기 위한 서버 상의 경로이고, 'path/image'는 이미지 자원을 포함하며, 'path/code'는 코드들, 예를 들어, 자바 스크립트 코드를 포함하고, 'path/style'은 CSS 자원을 포함하는, 등등이라고 가정한다. 이러한 정황에서, 클라이언트가 특유의 푸시 헤더에서 웹 페이지에서 선언된 모든 종류의 이미지(image/*) 또는 주어진 타입의 모든 이미지(image/*.jpg) 원한다는 것을 표시할 때, 서버 상의 구성 파일은 임의의 자원 디렉토리에 대해 푸시될 수 있는 이미지들의 목록을 나열해야 한다.
웹 페이지는, 요청의 request-URI에서 요청된 데이터일 수 있다. 한 변형에서, 웹 페이지는, 요청 내의 또 다른 선택사항적 헤더를 이용하여 식별될 수 있다.
필터링 접근법에 따르면, 본 발명은 서버 디바이스와 클라이언트 디바이스 사이에서 데이터를 전송하는 방법을 제공하며, 이 방법은, 서버 디바이스에서, 다음과 같은 단계들을 포함한다:
클라이언트 디바이스로부터, 제1 데이터를 획득하라는 HTTP 요청 ―HTTP 요청은 하나 이상의 필터링 파라미터를 포함하는 제1 선택사항적 헤더 필드를 포함함― 을 수신하는 단계;
제1 데이터를 검색하여 클라이언트 디바이스에 전송하는 단계; 및
제1 선택사항적 헤더 필드가 HTTP 요청에 존재한다면 :
HTTP 요청으로부터 획득된 메인 자원을 이용하여 데이터 세트를 식별하는 단계;
제2 데이터의 목록을 획득하기 위해 하나 이상의 필터링 파라미터를 이용하여 식별된 세트의 각각의 데이터를 필터링하는 단계; 및
제2 데이터를 클라이언트 디바이스에 푸시하는 단계.
클라이언트의 관점에서, 본 발명은 서버 디바이스와 클라이언트 디바이스 사이에서 데이터를 전송하는 방법을 제공하며, 이 방법은, 클라이언트 디바이스에서, 다음과 같은 단계들을 포함한다 : 제1 데이터를 획득하라는 HTTP 요청 ―HTTP 요청은 하나 이상의 필터링 파라미터를 포함하는 제1 선택사항적 헤더 필드를 포함함― 을 생성하는 단계;
제1 데이터를 획득하고 필터링 파라미터들에 따라 HTTP 요청으로부터 추론된 메인 자원에서 참조되는 제2 데이터를 푸시하도록 서버 디바이스를 구동하기 위해 HTTP 요청을 서버 디바이스에 전송하는 단계.
필터링 접근법으로서의 푸시 특유의 헤더의 이용이 이제 설명된다.
제1 예는, 클라이언트가, 타입에 따라 푸시될 하위 자원들의 우선순위화된 목록, 예를 들어, jss 및 css를 로딩한 다음 html 및 img를 로딩하는 것을 서버에 표시하기를 원할 때의 웹 페이지 로딩과 관련된다. 메인 자원이라고 불리는 웹 페이지는, 요청의 request-URI에서 정의된 요청된 페이지이다. 특유의 푸시 헤더는 다음과 같이 정의될 수 있다:
Push-Request:application/javascript;q=1,text/css;q=0.8,text/html;q=0.7, image/png;q=0.6, image/*;q=0.4
이것은, 클라이언트가 타입(예를 들어, MIME 타입, 콘텐츠 타입, 포멧 타입 또는 코덱 타입)에 따라 푸시될 자원들의 세트(예를 들어, 메인 자원에서 선언된 하위 자원들)를 원한다는 것을 서버에게 나타내는 표시이다.
여기서, 클라이언트에 의한 상대적인 선호도를 나타내는 Accept 헤더의 'q' 파라미터와 유사한 방식으로 'q' 파라미터를 이용하여 각각의 자원 타입에 우선순위 레벨이 제공된다. q = 0은 일부 자원 타입이 서버에 의해 푸시되는 것을 배제시킬 수 있게 한다는 점에 유의한다.
이 예에서, 우선순위 'q'는, 하위 자원들이 서버에 의해 푸시되어야 하는 (예를 들어, 선호되는 해상도에 따른) 클라이언트-선호 순서 또는 버전을 정의하는 것을 가능하게 한다. 그 결과, 서버는 푸시를 위한 데이터의 정렬된 목록을 제공하도록 하위 자원들을 필터링해야 한다.
제2 예는, 웹 페이지가 요청의 request-URI에서 정의된 요청된 데이터가 아닐 때, 웹 페이지의 이미지 로딩에 관한 것이다. 이러한 상황에서, 특유의 푸시 헤더의 지원 부분은, HTTP "Referer" 헤더를 명시적으로 나타낸다. 이것은, 클라이언트가 원하는 추가 자원이 Referer 헤더 값에 표시된 메인 자원의 하위 자원이라는 것을 나타내는 서버에 대한 표시이다. 선택사항으로서, 이하의 헤더들은, .png 이미지 포멧의 이미지에 우선권을 갖고, "Referer" HTTP 헤더에서 표시된 웹 페이지의 모든 이미지들의 로딩을 유도한다.
Push-Request: Referer; image/png;q=0.6, image/*;q=0.4
Referer: the_url_to-web-page
제3 예는, DASH 스트리밍, 더 구체적으로는 MPD 로딩 및 빠른 시작에 관한 것이다. 푸시 헤더는 다음과 같을 수 있는데, 여기서 MPD는 요청의 request-URI에서 정의된 요청된 데이터이다:
Push-Request: video/mp4;q=1, video/webm;q=0.4
이것은, "video/webm" MIME 타입을 가진 세그먼트가 아니라 "video/mp4" MIME 타입을 가진 미디어 세그먼트로 시작하는 것에 대한 클라이언트로부터의 선호도를 나타낸다. 동등한 예는 다음과 같이 쓸 수 있다:
Push-Request: URI; video.{1}; {video/*.mp4;q=1, video/webm;q=0.4}
상기 예에서, 메인 자원에 대한 URI, 즉, MPD에 기초하여, 서버는 클라이언트에 푸시할 mp4 포멧의 모든 비디오 세그먼트를 추론할 수 있다. 이 와일드카드 대체 값들에 의해, 주어진 매니페스트에 대한 또는 MPD 분석으로부터의 정적 구성 정보에 기초하여 푸시할 세그먼트들의 목록을 결정하는 것은 서버에게 달려 있다.
더 일반적으로, 클라이언트가, 예를 들어, 웹 페이지에서 자바 스크립트 코드나 CSS 하위 자원, 선언문을 다운로드하고, 동일한 요청에 대해, 자바 스크립트 코드와 CSS 하위 자원에서 각각 참조되는 하위 자원들을 역시 획득하기를 원한다는 것을 서버에게 표시하고자 할 때 유용할 수 있다.
제4 예는 비디오 스트리밍에 관한 것으로, 더 구체적으로는, 바이트 범위의 탐색에 관한 것이다. 미디어 콘텐츠 하위부분이 HTTP 요청에서 SegmentBase URL과 바이트 범위를 이용하여 요청된다면, 동일한 요청 내의 후속 푸시 헤더는 바이트 범위 [1400-4000]의 푸시를 유도한 다음 더 낮은 우선순위의 바이트 범위 [4000-6000]의 푸시를 유도하는 것을 가능하게 한다 :
Push-Request: Range; {1}; [1400-4000];q=1 : [4000-6000];q=0.8
제5 예는, DASH 응용의 경우, 메인 자원, 즉, 매니페스트와 관련된 푸시될 자원 세트를 설명한다. 이것은, 값 "Referer"를 갖는 특유의 푸시 헤더의 지원 부분을 통해 표시된다. 패턴 부분은 비디오 자원들의 세트를 나타내고, 와일드카드 대체 값들은 비디오 세그먼트 타입, 여기서는 mp4에 기초한 필터링 규칙을 나타낸다:
Push-Request: Referer; video.{1}; video/*.mp4
Referer: the_url_to-MPD
이것은, 클라이언트가 특유의 푸시 헤더에서 와일드카드 값을 이용하는 것을 허용한다.
Referer 헤더는 선택사항이지만 지능형 서버(MPD 인식)의 경우에 그 값은 서버가 클라이언트에 의해 표시된 세그먼트들 세트들(또는 더 일반적으로 (하위) 자원들)을 필터링하는 것을 도울 수 있다.
도 9는 실시예들에 따른 디바이스의 개략도이다. 디바이스는, 서버, 클라이언트 또는 프록시일 수 있다. 디바이스는, 실시예들에 따른 방법을 구현하도록 구성된 제어 유닛(901)을 위한 작업 메모리로서 이용될 수 있는 RAM 메모리(902)를 포함한다. 예를 들어, 제어 유닛은 ROM 메모리(903)로부터 로딩된 컴퓨터 프로그램의 명령어들을 실행하도록 구성될 수 있다. 프로그램은 또한, 하드 드라이브(906)로부터 로딩될 수도 있다.
디바이스는 또한, 단일 네트워크 인터페이스일 수 있는 네트워크 인터페이스(904)를 포함하거나, 네트워크 인터페이스들의 세트(예를 들어, 수 개의 무선 인터페이스, 또는 수개 타입의 유선 또는 무선 인터페이스)를 포함한다. 디바이스는, 사용자에게 정보를 디스플레이하고 사용자로부터 입력을 수신하기 위한 사용자 인터페이스(905)를 포함할 수 있다.
디바이스는 또한, 외부 디바이스들과 데이터를 수신 및/또는 전송하기 위한 입력/출력 모듈(907)을 포함할 수 있다.
본 발명의 도면 및 전술된 설명에서 상세히 도시되고 논의되었지만, 이와 같은 도시 및 설명은 예증적 또는 예시적으로 간주되어야 하고 제한적인 것이 아니며, 본 발명은 개시된 실시예만으로 제한되지 않는다. 도면, 개시내용, 및 첨부된 청구항들의 연구로부터, 특허청구된 본 발명을 실시하는데 있어서 개시된 실시예에 대한 다른 변형들이 본 기술분야의 통상의 기술자에 의해 이해되고 시행될 수 있다.
이러한 변형은, 특히, 본 발명의 요약 및/또는 첨부된 청구항들에서 개시된 실시예들을 결합함으로써 유도될 수 있다.
청구항들에서, 용어 "포함하는"은 다른 요소나 단계를 배제하는 것은 아니며, 부정 관사 "한(a)" 또는 "하나의(an)"는 복수를 배제하지 않는다. 하나의 프로세서 또는 기타의 유닛이 청구항들에서 인용된 수 개의 항목들의 기능을 이행할 수 있다. 상이한 피쳐들이 서로 상이한 종속항들에서 인용된다는 단순한 사실이, 이들 피쳐들의 조합이 유익하게 이용될 수 없다는 것을 나타내는 것은 아니다. 청구항들 내의 임의의 참조 부호는 본 발명의 범위를 제한하는 것으로 해석되어서는 안 된다.
Claims (29)
- 서버 디바이스와 클라이언트 디바이스 사이의 통신 방법으로서, 상기 서버 디바이스에서:
상기 클라이언트 디바이스로부터, 제1 데이터를 획득하기 위해서 HTTP 요청을 수신 ―상기 HTTP 요청은 상기 서버 디바이스 상의 상기 제1 데이터의 식별을 허용하는 제1 데이터 식별 정보를 포함하고, 상기 HTTP 요청은 상기 HTTP 요청에 의해 요청된 상기 제1 데이터가 아닌 제2 데이터를 식별하기 위한 제2 데이터 식별 정보를 포함하는 하나 이상의 추가 헤더 필드를 포함함― 하는 단계;
상기 클라이언트 디바이스로부터 수신된 상기 HTTP 요청에 응답하여 상기 제1 데이터를 상기 클라이언트 디바이스에 전송하는 단계;
상기 하나 이상의 추가 헤더 필드를 이용하여 상기 서버 디바이스 상의 상기 제2 데이터를 결정하는 단계; 및
상기 제1 데이터를 획득하기 위해서 상기 클라이언트 디바이스로부터 수신된 상기 HTTP 요청에 포함된 상기 하나 이상의 추가 헤더 필드를 이용하여 결정된 상기 제2 데이터를 상기 클라이언트 디바이스에 푸시하는 단계
를 포함하는 통신 방법. - 제1항에 있어서,
상기 제2 데이터를 푸시하기 전에, 상기 클라이언트 디바이스로의 상기 제2 데이터의 푸시를 공지하는 푸시 약속 메시지(push promise message)를 전송하는 단계를 더 포함하는 통신 방법. - 제1항에 있어서,
상기 제2 데이터를 푸시하기 전에, 확인응답 데이터 ―상기 확인응답 데이터는 상기 클라이언트 디바이스로 푸시될 상기 제2 데이터를 결정하는 데에 이용되는 상기 제2 데이터 식별 정보를 나타냄 ―를 상기 클라이언트 디바이스에 전송하는 단계를 더 포함하는, 통신 방법. - 제3항에 있어서, 상기 확인응답 데이터는 상기 제2 데이터의 푸시를 구동하는 푸시 정책을 나타내는, 통신 방법.
- 제3항에 있어서, 상기 HTTP 요청 내의 상기 제2 데이터 식별 정보는, 제2 데이터의 상이한 푸시 방식을 구동하는 2개 이상의 상이한 푸시 정책을 포함하는 목록을 포함하는, 통신 방법.
- 제4항에 있어서, 상기 확인응답 데이터는 제2 데이터를 푸시하기 위한 2개 이상의 상이한 푸시 정책 중 하나를 포함하고, 제2 데이터를 푸시하기 위한 2개 이상의 상이한 푸시 정책 중 상기 하나는, 상기 클라이언트 디바이스에 푸시될 상기 제2 데이터를 식별하는 데에 이용되는, 통신 방법.
- 제1항에 있어서, 상기 제2 데이터 식별 정보는 상기 제2 데이터의 데이터 타입과 연관되며, 상기 데이터 타입은 설명 데이터 타입 또는 콘텐츠 데이터 타입을 포함하고, 상기 제2 데이터는 콘텐츠 데이터 또는 설명 데이터에 속하는, 통신 방법.
- 제3항에 있어서, 상기 확인응답 데이터는 상기 HTTP 요청 내의 상기 제2 데이터 식별 정보와는 상이한 제2 데이터 식별 정보를 포함하는, 통신 방법.
- 제1항에 있어서, 상기 HTTP 요청 내의 상기 제2 데이터 식별 정보는 하나 이상의 고유 식별자를 포함하고, 상기 하나 이상의 고유 식별자는 제2 데이터를 푸시하기 위한 지시 및 푸시될 제2 데이터의 식별을 나타내거나, 제2 데이터를 푸시하지 말라는 지시를 나타내는, 통신 방법.
- 제1항에 있어서, 상기 하나 이상의 추가 헤더 필드는 하나 이상의 선택사항적 헤더 필드인, 통신 방법.
- 제10항에 있어서, 상기 HTTP 요청 내의 상기 제1 및 제2 데이터 식별 정보는 각각 제1 및 제2 URI(uniform resource identifier)를 포함하는, 통신 방법.
- 제11항에 있어서, 상기 하나 이상의 선택사항적 헤더 필드는 상기 HTTP 요청의 콘텐츠로부터 상기 제2 URI를 생성하는 하나 이상의 구성 규칙(construction rule)을 포함하는, 통신 방법.
- 제11항에 있어서, 상기 하나 이상의 선택사항적 헤더 필드는 변동-부분 정보와 대체 정보를 포함하고, 상기 변동-부분 정보는 기준 URI에서 하나 이상의 변동하는 하위부분을 식별하고, 상기 대체 정보는 상기 기준 URI에서 식별된 상기 변동하는 하위부분을 대체하여 상기 제2 URI 또는 URI들을 정의하기 위한 하나 이상의 대체 값을 포함하는, 통신 방법.
- 제1항에 있어서, 상기 제2 데이터를 식별하기 위한 상기 제2 데이터 식별 정보는, 상기 결정하는 단계에서 상기 클라이언트 디바이스로부터의 상기 HTTP 요청 내에 포함된 상기 하나 이상의 추가 헤더 필드를 이용하여 결정되는, 통신 방법.
- 서버 디바이스와 클라이언트 디바이스 사이의 통신 방법으로서, 상기 클라이언트 디바이스에서:
상기 서버 디바이스로 요청될 제1 데이터를 식별하는 단계;
상기 제1 데이터를 획득하기 위해서 HTTP 요청 ―상기 HTTP 요청은 상기 서버 디바이스에 의해 상기 서버 디바이스 상의 상기 제1 데이터를 식별하는 데에 이용되는 제1 데이터 식별 정보를 포함하고, 상기 HTTP 요청은 데이터를 푸시할지 또는 데이터를 푸시하지말지에 관한 상기 서버 디바이스에 대한 정보 항목을 포함하는 하나 이상의 추가 헤더 필드를 포함함― 을 생성하는 단계;
상기 제1 데이터를 획득하기 위해 상기 HTTP 요청 ― 상기 HTTP 요청은 데이터를 푸시할지 또는 데이터를 푸시하지 말지에 관한 상기 정보 항목을 포함하는 하나 이상의 추가 헤더 필드를 포함함 ―을 상기 서버 디바이스에 전송하는 단계; 및
상기 HTTP 요청의 전송에 응답하여, 상기 서버 디바이스로부터 상기 제1 데이터를 수신하는 단계를 포함하는, 통신 방법. - 서버 디바이스와 클라이언트 디바이스 사이의 통신 방법으로서, 상기 클라이언트 디바이스에서:
제1 데이터를 획득하기 위해서 HTTP 요청 ―상기 HTTP 요청은 하나 이상의 필터링 파라미터를 포함하는 제1 선택사항적 헤더 필드를 포함함― 을 생성하는 단계; 및
상기 제1 데이터를 획득하고 상기 필터링 파라미터들에 따라 상기 HTTP 요청에 기초하여 획득된 상기 제1 데이터에서 참조되는 제2 데이터를 푸시하기 위해 상기 서버 디바이스를 구동하도록 상기 제1 선택사항적 헤더 필드를 포함하는 상기 HTTP 요청을 상기 서버 디바이스에 전송하는 단계
를 포함하는, 통신 방법. - 제16항에 있어서, 상기 하나 이상의 필터링 파라미터는:
― 자원 타입을 정의하고; 상기 자원 타입 또는 타입들은, 애플리케이션 타입, 텍스트 타입, 이미지 타입, 비디오 타입, 오디오 타입 중 하나 이상의 타입을 포함하거나; 또는
― DASH 미디어 프리젠테이션 설명 내의 요소들의 식별자들을 이용하여 하나 이상의 데이터 그룹을 식별하거나; 또는
― 상기 HTTP 요청에 기초하여 획득되는 상기 제1 데이터의 하위부분을 식별하는 시간 범위들을 이용하여 상기 제1 선택사항적 헤더 필드에서 정의되는, 통신 방법. - 디바이스 내의 마이크로프로세서 또는 컴퓨터 시스템에 의해 로딩되고 실행될 때, 제1항, 제15항 및 제16항 중 어느 한 항에 따른 통신 방법을 상기 디바이스가 실행하게 하는 컴퓨터 프로그램의 명령어들을 저장한 컴퓨터-판독가능 저장 매체.
- 제1항, 제15항 및 제16항 중 어느 한 항에 따른 통신 방법의 각각의 단계를 실행하기 위해 구성된 수단을 포함하는 디바이스.
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
Applications Claiming Priority (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GB1501437.6A GB2534849A (en) | 2015-01-28 | 2015-01-28 | Client-driven push of resources by a server device |
| GB1501437.6 | 2015-01-28 | ||
| GB1509094.7A GB2534617A (en) | 2015-01-28 | 2015-05-27 | Improved client-driven push of resources by a server device |
| GB1509094.7 | 2015-05-27 | ||
| PCT/EP2016/050713 WO2016120089A1 (en) | 2015-01-28 | 2016-01-15 | Improved client-driven push of resources by a server device |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| KR20170106426A KR20170106426A (ko) | 2017-09-20 |
| KR102007105B1 true KR102007105B1 (ko) | 2019-08-02 |
Family
ID=52674078
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| KR1020177023038A KR102007105B1 (ko) | 2015-01-28 | 2016-01-15 | 개선된 클라이언트-주도형의 서버 디바이스에 의한 자원의 푸시 |
Country Status (7)
| Country | Link |
|---|---|
| US (2) | US10348846B2 (ko) |
| EP (1) | EP3251322B1 (ko) |
| JP (1) | JP6686029B2 (ko) |
| KR (1) | KR102007105B1 (ko) |
| CN (1) | CN107211022B (ko) |
| GB (3) | GB2534849A (ko) |
| WO (1) | WO2016120089A1 (ko) |
Families Citing this family (44)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP2953313A1 (en) * | 2014-06-05 | 2015-12-09 | Thomson Licensing | Method for operating a cache arranged along a transmission path between client terminals and at least one server, and corresponding cache |
| US11943289B2 (en) | 2014-10-14 | 2024-03-26 | Comcast Cable Communications, Llc | Manipulation of content transmissions |
| US11917002B2 (en) | 2014-10-14 | 2024-02-27 | Comcast Cable Communications, Llc | Manipulation and recording of content transmissions |
| US10880357B2 (en) * | 2014-12-23 | 2020-12-29 | Adobe Inc. | Reducing requests for media segments in streaming of multimedia content |
| GB2534849A (en) * | 2015-01-28 | 2016-08-10 | Canon Kk | Client-driven push of resources by a server device |
| GB2540632B (en) * | 2015-07-24 | 2018-05-16 | Canon Kk | Methods, devices and computer programs for pushing data in a network environment comprising cache servers |
| US10152080B2 (en) * | 2015-09-23 | 2018-12-11 | Adobe Systems Incorporated | Power efficient multimedia content streaming based on media segment duration |
| US10158682B2 (en) | 2015-09-23 | 2018-12-18 | Adobe Systems Incorporated | Power efficient multimedia content streaming based on a server push |
| CN106604077B (zh) * | 2015-10-14 | 2020-09-29 | 中兴通讯股份有限公司 | 自适应流媒体传输方法及装置 |
| US20180109577A1 (en) * | 2016-10-13 | 2018-04-19 | Sharp Laboratories Of America, Inc. | Systems and methods for enabling communications associated with digital media distribution |
| CN107959667B (zh) * | 2016-10-18 | 2020-10-09 | 华为技术有限公司 | 一种媒体分片的推送方法、服务器及客户端 |
| US20180176325A1 (en) * | 2016-12-15 | 2018-06-21 | Huawei Technologies Co., Ltd. | Data pre-fetching in mobile networks |
| CN108512876B (zh) * | 2017-02-27 | 2020-11-10 | 腾讯科技（深圳）有限公司 | 数据的推送方法及装置 |
| US11659057B2 (en) * | 2017-04-19 | 2023-05-23 | Comcast Cable Communications, Llc | Methods and systems for content delivery using server push |
| KR102307447B1 (ko) * | 2017-05-02 | 2021-09-30 | 삼성전자주식회사 | 네트워크 환경 모니터링에 기반하는 http 적응적 스트리밍 서버, 방법, 및 클라이언트 단말 |
| US11477305B2 (en) * | 2017-05-03 | 2022-10-18 | Comcast Cable Communications, Llc | Local cache bandwidth matching |
| US20190020734A1 (en) * | 2017-07-14 | 2019-01-17 | Comcast Cable Communications, Llc | Reduced content manifest size |
| US11622020B2 (en) * | 2017-08-31 | 2023-04-04 | Micro Focus Llc | Push control |
| JP6950408B2 (ja) * | 2017-09-28 | 2021-10-13 | 京セラドキュメントソリューションズ株式会社 | 情報処理システム、画像形成装置、および情報処理方法 |
| US10461884B2 (en) * | 2017-10-05 | 2019-10-29 | Comcast Cable Communications, Llc | Server selected variable bitrate streaming |
| GB2567665B (en) * | 2017-10-19 | 2022-06-22 | Arm Ip Ltd | Asset update service |
| US20190141075A1 (en) * | 2017-11-09 | 2019-05-09 | Monarx, Inc. | Method and system for a protection mechanism to improve server security |
| CN109981695B (zh) * | 2017-12-27 | 2021-03-26 | Oppo广东移动通信有限公司 | 内容推送方法、装置及设备 |
| CN109063142B (zh) * | 2018-08-06 | 2021-03-05 | 网宿科技股份有限公司 | 网页资源推送方法、服务器及存储介质 |
| US11716264B2 (en) * | 2018-08-13 | 2023-08-01 | Cisco Technology, Inc. | In situ triggered function as a service within a service mesh |
| CN109151492B (zh) * | 2018-09-29 | 2021-02-02 | 网宿科技股份有限公司 | 一种直播视频的快速启动方法及装置 |
| CN109359215B (zh) * | 2018-12-03 | 2023-08-22 | 江苏曲速教育科技有限公司 | 视频智能推送方法和系统 |
| US11159635B2 (en) | 2019-05-07 | 2021-10-26 | Hulu, LLC | Soft server push in video streaming |
| US11212368B2 (en) * | 2019-05-17 | 2021-12-28 | Netflix, Inc. | Fire-and-forget offload mechanism for network-based services |
| CN110730206A (zh) * | 2019-09-06 | 2020-01-24 | 浪潮金融信息技术有限公司 | 一种应用于新零售平台数据展示的数据服务方案 |
| US11425187B2 (en) * | 2019-09-30 | 2022-08-23 | Tencent America Llc. | Session-based information for dynamic adaptive streaming over HTTP |
| CN111427850A (zh) * | 2019-11-06 | 2020-07-17 | 杭州海康威视数字技术股份有限公司 | 一种显示报警文件的方法、装置及系统 |
| CN111586100B (zh) * | 2020-04-01 | 2022-04-22 | 富途网络科技(深圳)有限公司 | 目标对象消息发送装置及方法 |
| CN111988235B (zh) * | 2020-08-13 | 2023-05-09 | 暨南大学 | 一种基于多http/3连接的并行传输方法 |
| US20220078261A1 (en) * | 2020-09-10 | 2022-03-10 | Microsoft Technology Licensing, Llc | Controlling client/server interaction based upon indications of future client requests |
| CN112600823A (zh) * | 2020-12-09 | 2021-04-02 | 上海牙木通讯技术有限公司 | 句柄标识解析缓存方法、查询方法及句柄标识解析系统 |
| US11451602B2 (en) * | 2021-01-06 | 2022-09-20 | Tencent America LLC | Methods and apparatuses for dynamic adaptive streaming over HTTP |
| US11816177B2 (en) * | 2021-07-21 | 2023-11-14 | Yext, Inc. | Streaming static web page generation |
| CN114553947B (zh) * | 2022-01-29 | 2024-01-19 | 北京金堤科技有限公司 | 一种对消息进行处理的方法及装置 |
| US20230336599A1 (en) * | 2022-04-19 | 2023-10-19 | Tencent America LLC | Extensible Request Signaling for Adaptive Streaming Parameterization |
| CN115022280B (zh) * | 2022-06-16 | 2023-07-14 | 杭州楷知科技有限公司 | 一种nat探测的方法、客户端及系统 |
| CN114827633B (zh) * | 2022-06-17 | 2022-09-13 | 浙江华创视讯科技有限公司 | 一种媒体流容灾方法、装置和相关设备 |
| KR102663914B1 (ko) * | 2022-07-13 | 2024-05-13 | 주식회사 시큐다임 | 전자 장치 및 이에 의한 http 트래픽의 분석 방법 |
| US11824745B1 (en) * | 2022-12-15 | 2023-11-21 | Amazon Technologies, Inc. | Reverse engineering computer network system functionality |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20120198328A1 (en) | 2007-02-06 | 2012-08-02 | 5O9, Inc. | Contextual data communication platform |
| GB2516112A (en) | 2013-07-12 | 2015-01-14 | Canon Kk | Methods for providing media data, method for receiving media data and corresponding devices |
Family Cites Families (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| BR0214760A (pt) * | 2001-12-06 | 2004-11-09 | Access Co Ltd | Sistema e método para fornecer serviços de conteúdo de assinatura para dispositivos móveis |
| CN1881242A (zh) * | 2005-06-14 | 2006-12-20 | 张晓东 | 汽车行业跨企业供应链系统web应用平台 |
| CN101350820A (zh) * | 2008-08-29 | 2009-01-21 | 中兴通讯股份有限公司 | 一种推送业务代理网关对推送业务发起者的安全认证方法 |
| CN101370033B (zh) * | 2008-09-26 | 2011-09-14 | 成都市华为赛门铁克科技有限公司 | 一种推送消息的方法和设备 |
| CN102232298B (zh) * | 2011-04-07 | 2013-10-09 | 华为技术有限公司 | 媒体内容的传输处理方法、装置与系统 |
| GB2500229B (en) * | 2012-03-14 | 2014-08-06 | Canon Kk | Method,system and server device for transmitting a digital resource in a client-server communication system |
| KR102020363B1 (ko) * | 2012-10-31 | 2019-09-10 | 삼성전자 주식회사 | 적응형 스트리밍을 이용한 미디어 세그먼트 송수신 방법 및 장치 |
| CN103036960A (zh) * | 2012-12-07 | 2013-04-10 | 中国联合网络通信集团有限公司 | 一种信息推送方法、装置及系统 |
| EP3020208B1 (en) * | 2013-07-12 | 2022-03-09 | Canon Kabushiki Kaisha | Adaptive data streaming with push messages control |
| KR101924703B1 (ko) * | 2014-02-13 | 2019-02-20 | 코닌클리즈케 케이피엔 엔.브이. | 단일 메세지 요청에 기초하여 네트워크 노드로부터 다수의 청크 요청 |
| GB2534849A (en) * | 2015-01-28 | 2016-08-10 | Canon Kk | Client-driven push of resources by a server device |
-
2015
- 2015-01-28 GB GB1501437.6A patent/GB2534849A/en not_active Withdrawn
- 2015-05-27 GB GB1509094.7A patent/GB2534617A/en not_active Withdrawn
-
2016
- 2016-01-15 EP EP16700629.5A patent/EP3251322B1/en active Active
- 2016-01-15 WO PCT/EP2016/050713 patent/WO2016120089A1/en active Application Filing
- 2016-01-15 US US15/543,534 patent/US10348846B2/en active Active
- 2016-01-15 JP JP2017537233A patent/JP6686029B2/ja active Active
- 2016-01-15 KR KR1020177023038A patent/KR102007105B1/ko active IP Right Grant
- 2016-01-15 CN CN201680007911.4A patent/CN107211022B/zh active Active
- 2016-02-09 GB GB1602333.5A patent/GB2538832B/en active Active
- 2016-09-28 US US15/279,231 patent/US20170230442A1/en not_active Abandoned
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20120198328A1 (en) | 2007-02-06 | 2012-08-02 | 5O9, Inc. | Contextual data communication platform |
| GB2516112A (en) | 2013-07-12 | 2015-01-14 | Canon Kk | Methods for providing media data, method for receiving media data and corresponding devices |
Non-Patent Citations (1)
| Title |
|---|
| Intelligent brower initiated server pushing(WENTING TANG et al, IPCCC '00, 2000.02.20.) |
Also Published As
| Publication number | Publication date |
|---|---|
| CN107211022B (zh) | 2020-10-27 |
| GB2534617A (en) | 2016-08-03 |
| GB2538832B (en) | 2019-10-09 |
| JP2018509679A (ja) | 2018-04-05 |
| GB2534849A (en) | 2016-08-10 |
| GB2538832A (en) | 2016-11-30 |
| US20180013845A1 (en) | 2018-01-11 |
| WO2016120089A1 (en) | 2016-08-04 |
| EP3251322B1 (en) | 2021-11-24 |
| GB201602333D0 (en) | 2016-03-23 |
| KR20170106426A (ko) | 2017-09-20 |
| US10348846B2 (en) | 2019-07-09 |
| US20170230442A1 (en) | 2017-08-10 |
| CN107211022A (zh) | 2017-09-26 |
| GB201501437D0 (en) | 2015-03-11 |
| JP6686029B2 (ja) | 2020-04-22 |
| GB201509094D0 (en) | 2015-07-08 |
| EP3251322A1 (en) | 2017-12-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR102007105B1 (ko) | 개선된 클라이언트-주도형의 서버 디바이스에 의한 자원의 푸시 | |
| US11375031B2 (en) | Adaptive data streaming method with push messages control | |
| JP2016531466A5 (ko) | ||
| GB2534057A (en) | Methods for providing media data, method for receiving media data and corresponding devices | |
| GB2517060A (en) | Adaptive data streaming method with push messages control | |
| GB2575189A (en) | Adaptive client-driven push of resources by a server device | |
| GB2551674A (en) | Adaptive data streaming method with push messages control |
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 |