KR102076523B1 - 하이브리드 http 및 udp 콘텐츠 전달 - Google Patents

하이브리드 http 및 udp 콘텐츠 전달 Download PDF

Info

Publication number
KR102076523B1
KR102076523B1 KR1020157007312A KR20157007312A KR102076523B1 KR 102076523 B1 KR102076523 B1 KR 102076523B1 KR 1020157007312 A KR1020157007312 A KR 1020157007312A KR 20157007312 A KR20157007312 A KR 20157007312A KR 102076523 B1 KR102076523 B1 KR 102076523B1
Authority
KR
South Korea
Prior art keywords
udp
request
client
http
response
Prior art date
Application number
KR1020157007312A
Other languages
English (en)
Other versions
KR20150048179A (ko
Inventor
미로슬라프 포넥
앤드류 올네스
Original Assignee
아카마이 테크놀로지스, 인크.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 아카마이 테크놀로지스, 인크. filed Critical 아카마이 테크놀로지스, 인크.
Publication of KR20150048179A publication Critical patent/KR20150048179A/ko
Application granted granted Critical
Publication of KR102076523B1 publication Critical patent/KR102076523B1/ko

Links

Images

Classifications

    • 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/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/165—Combined use of TCP and UDP protocols; selection criteria therefor
    • 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/1066—Session management
    • H04L65/1101—Session 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]
    • 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/14—Session management
    • 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/02—Protocol performance
    • 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/08—Protocols for interworking; Protocol conversion
    • 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/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/164—Adaptation or special uses of UDP protocol

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Multimedia (AREA)
  • Information Transfer Between Computers (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

하이브리드 HTTP/UDP 전달 프로토콜은 오버레이와 같은 네트워크를 통한 비디오 및 다른 컨텐츠의 전달을 위해 상당한 개선들을 제공한다. 그 접근법은 특히 HTTP-기반 스트리밍에 대한 문제점들(예를 들어, 느린 스타트업 시간들, 리버퍼링, 및 낮은 비트레이트들)을 해결하는데 유용하다. 일반적으로, 프로토콜은 HTTP 페이즈 및 UDP 페이즈와 같은 2개의 페이즈들을 갖는다. HTTP 페이즈에서, 클라이언트는 HTTP GET 요청을 서버에 전송한다. GET 요청은, 클라이언트가 프로토콜을 통한 UDP-기반 전달을 사용하길 원한다는 것을 서버에 알리는 전송 헤더를 포함한다. 서버는 이 모드를 거절하고 본래 HTTP 모드에 계속 있을 수 있거나, 또는 그 서버는 UDP 페이즈에 들어가기 위해서 어떻게 연결을 수행하는지를 클라이언트에 알리는 헤더 정보를 갖는 빈 응답을 전송함으로써 응답할 수 있다. UDP 페이즈에서, 클라이언트는 연결을 개시하고, 오리지널 요청된 컨텐츠를 UDP를 통해 수신한다.

Description

하이브리드 HTTP 및 UDP 콘텐츠 전달{HYBRID HTTP AND UDP CONTENT DELIVERY}
본 출원은 일반적으로 네트워크를 통한 데이터 통신에 관한 것이다.
분산형 컴퓨터 시스템들은 종래 기술에서 잘 알려져 있다. 하나의 그런 분산형 컴퓨터 시스템은, 통상적으로 서비스 제공자에 의해 동작되고 관리되는 "콘텐츠 전달 네트워크" 또는 "CDN"이다. 서비스 제공자는 통상적으로, 서비스 제공자의 공유 인프라구조를 사용하는 제 3 자들(고객들) 대신 콘텐츠 전달 서비스를 제공한다. 이런 타입의 분산형 시스템은 때때로 "오버레이 네트워크"라 지칭되고 통상적으로, 콘텐츠 전달, 애플리케이션 가속, 또는 위탁된 오리진 사이트 인프라구조의 다른 지원 같은 다양한 서비스들을 가능하게 하도록 설계된 소프트웨어, 시스템들, 프로토콜들 및 기술들과 함께, 네트워크 또는 네트워크들에 의해 링크된 자율(autonomous) 컴퓨터들의 콜렉션을 지칭한다. CDN 서비스 제공자는 통상적으로, 고객 포탈에서 프로비저닝되고 그 다음 네트워크로 디플로이(deploy)되는 디지털 속성들(웹사이트 같은)을 통해 서비스 전달을 제공한다.
설명된 타입의 오버레이 네트워크들은 네트워크 내 서버로부터의 HTTP-기반 스트리밍을, 비디오 스트림을 수신하고 이를 다시 스크린에 재생하는 클라이언트에 제공한다. 클라이언트들은 데스크톱 컴퓨터, 모바일 디바이스(스마트 폰들, 테블릿들), 셋톱-박스들, 스마트 텔레비전들 또는 어플라이언스들(appliances), 또는 임의의 다른 네트워크 연결 디바이스들 상에서 운용할 수 있다. 통상적인 HTTP-기반 스트리밍 이용 경우에 대해, 클라이언트는 DNS를 통해 IP 어드레스에 대한 네임(예를 들어, CDN 호스트네임)을 풀고 그 어드레스와 연관된 서버에 TCP 연결을 형성한다. 일단 설정되면, 클라이언트는 원하는 콘텐츠, 예를 들어 미디어 프레그먼트에 대한 HTTP GET 요청을 전송한다. 서버는 표준 HTTP 응답 바디 내 콘텐츠 데이터로 응답한다. 연결은 종종 추가 요청들 및 응답들을 위하여 개방 상태로 유지된다.
HTTP(Hypertext Transfer Protocol)를 사용하는 표준 접근법들은, (전송 제어 프로토콜/인터넷 프로토콜(TCP/IP) 연결에 부가하여(on top of)) HTTP 프로토콜을 통해 요청을 하고, (동일한 TCP/IP 연결을 통해) HTTP 응답에서 요청된 데이터를 포함하는 응답을 수신한다. 대안적인 스트리밍 접근법들은, 사용자 데이터그램 프로토콜(UDP) 또는 TCP에 부가하여, 요청들 및 응답들(제어 메시지들 포함) 둘 다에 대한 프로토콜을 사용한다. 또 다른 접근법들은 HTTP 세션을 통해 몇몇 프로토콜을 터널링한다.
오늘날 많은 최종 사용자들은 느린 스타트업 시간들, 리버퍼링, 및 낮은 비트레이트들 같은 HTTP-기반 스트리밍에 의한 문제들을 경험한다. 이들 사용자들의 연결성은 종종 고품질 비디오에 대해 충분히 큰 대역폭을 나타내지만, 서버와 클라이언트 사이의 왕복 시간들 및 패킷 손실 특성들은, 주로 표준 TCP-기반 구현들이 그런 네트워크들에 대해 비효율적으로 동작하기 때문에, 스트리밍 성능에 부정적인 영향을 미친다.
따라서 비디오 스트리밍 품질을 개선하는 새로운 기술들을 제공할 필요가 있다. 본원의 개시는 관련 종래 기술과 연관된 이들 및 다른 문제들을 처리한다.
하이브리드 HTTP/UDP 전달 프로토콜은 오버레이와 같은 네트워크를 통한 비디오 및 다른 컨텐츠의 전달을 위해 상당한 개선들을 제공한다. 그 접근법은 특히 HTTP-기반 스트리밍에 대한 문제점들(예를 들어, 느린 스타트업 시간들, 리버퍼링, 및 낮은 비트레이트들)을 해결하는데 유용하다.
일반적으로, 프로토콜은 HTTP 페이즈 및 UDP 페이즈와 같은 2개의 페이즈들을 갖는다. HTTP 페이즈에서, 클라이언트는 HTTP GET 요청을 서버에 전송한다. GET 요청은, 클라이언트가 프로토콜을 통한 UDP-기반 전달을 사용하길 원한다는 것을 서버에 알리는 전송 헤더를 포함한다. 서버는 이 모드를 거절하고 통상의(ordinary) HTTP 모드에 계속 있을 수 있거나, 또는 그 서버는 UDP 페이즈에 들어가기 위해서 어떻게 연결을 수행하는지를 클라이언트에 알리는 헤더 정보를 갖는 빈 응답을 전송함으로써 응답할 수 있다. UDP 페이즈에서, 클라이언트는 연결을 개시하고, 오리지널 요청된 컨텐츠를 UDP를 통해 수신한다.
삭제
하이브리드 접근법은 UDP 프로토콜을 통한 컨텐츠 전송을 위해 별도의 채널을 추가함으로써 종래의 HTTP-기반 스트리밍과 상이하다. 일단 클라이언트가 서버에 연결되면, 클라이언트는 원하는 컨텐츠, 예를 들어 미디어 프래그먼트에 대한 HTTP GEP 요청을 전송하고, 자신이 응답의 바디의 전달을 위해 UDP 연결을 사용하길 원한다는 것을 나타내는 HTTP 헤더를 포함시킨다. 클라이언트는 또한 UDP 전달에 대한 임의의 선호도들(예를 들어, 순방향 에러 정정(FEC) 또는 다른 파라미터들)을 포함할 수 있다. 서버는, 프로토콜을 사용하도록 프로비저닝되는 경우, 빈 바디(컨텐츠-길이 : 0) 답신으로 응답한다. 그 응답은 바람직하게는 프록시들이 도중에 응답을 캐싱하는 것을 막기 위해서 다양한 헤더들을 또한 포함한다. 응답 헤더들에서, 클라이언트는 UDP 프로토콜(또는, 또한, 예를 들어 다중-소스 컨텐츠 획득을 위한 다른 가외의 대안적인 서버 기준들)을 통해 동일 서버에 어떻게 연결할지에 관한 정보를 찾는다. 이러한 정보는 통상적으로 IP 어드레스, UDP 포트 번호, 선택적으로는 일부 다른 특정 포트 번호(동일한 서버의 UDP 포트 상에 많은 이러한 연결들이 있을 수 있기 때문에, 통신이 어떤 플로우에 속하는지를 식별하기 위함), 버전, 및 토큰 T를 포함한다. 일단 이러한 정보가 서버로부터 수신되면, 클라이언트는 HTTP 응답 헤더들에 제공되는 정보(IP 어드레스, UDP 포트 번호, 다른 포트 번호 등)에 기초하여 서버에 SYN UDP 패킷을 전송함으로써 UDP 연결을 개시한다. 이러한 요청은 바람직하게 HTTP 응답으로부터의 토큰 T를 또한 포함한다. 토큰을 사용하여, 서버는 따라서, UDP 패킷을 전송하는 클라이언트가 이전 HTTP 응답을 확인했다는 것 및 이러한 SYN 패킷이 프로세싱되어야 한다는 것을 검증할 수 있다. SYN은 바람직하게는 클라이언트의 ISN(Initial Sequence Number)을 또한 포함한다. 서버는 SYN_ACK 패킷으로 응답하고, 그 SYN_ACK 패킷은 클라이언트의 SYN 패킷으로부터의 확인응답된 ISN 값을 포함한다. SYN_ACK는 또한 서버의 ISN 값을 포함한다. 이어서, 클라이언트는 토큰 T를 또한 다시금 포함하는 SYN_ACK 패킷으로부터의 서버의 확인응답된 ISN을 포함하는 SYN_ACK_ACK 패킷을 통해 SYN_ACK의 수신을 확인한다. 토큰 T 및 ISN들의 확인들은 양 측들이 통신에 참여하고 있고 이전 패킷들 모두를 확인한다는 것을 보장하기 위한 조치로서 기능한다. (HTTP 응답, SYN 및 SYN_ACK_ACK 패킷들에 있는) 토큰은 또한 이러한 특정 클라이언트와 서버 간의 다른 HTTP 요청들을 위한 연결의 거절을 용이하게 한다. 일단 핸드쉐이크가 이러한 방식으로 완료되면, UDP-기반 연결은 설정되게 고려되고; 이어서 서버는 (어쩌면 FEC-인코딩된) 컨텐츠를 갖는 데이터 패킷들을 전송하기 시작한다. 컨텐츠는, UDP가 사용되지 않는 경우, 오리지널 HTTP 응답 바디에 있는 것과 동일하다.
위의 설명은 청구대상의 더욱 적절한 특징들 중 일부를 요약한 것이다. 이러한 특징들은 단순히 예시적인 것으로 해석되어야 한다. 많은 다른 유리한 결과들이 개시된 청구대상을 상이한 방식으로 적용함으로써 또는 설명될 요지를 변경함으로써 획득될 수 있다.
청구대상 및 청구대상의 이점들의 더 완전한 이해를 위해, 첨부 도면들과 함께 취해지는 다음의 설명들에 대한 참조가 이제 이루어지며, 도면들에서:
도 1은 콘텐츠 전달 네트워크(CDN)로서 구성된 알려진 분산형 컴퓨터 시스템을 도시하는 블록도이고;
도 2는 대표적인 CDN 에지 머신 구성이고;
도 3은 본 개시의 기본 하이브리드 HTTP/UDP 데이터 전달 접근방식을 도시하는 도면이고; 그리고
도 4는 부가적으로 상세하게 본 개시의 하이브리드 HTTP/UDP 전달 기술에 대한 동작 시나리오를 도시하는 도면이다.
도 1은 본 명세서의 기술들에 의해 (아래에 설명되는 바와 같이) 확장되는 알려진 분산형 컴퓨터 시스템을 도시한다.
도 1에 도시된 바와 같은 알려진 시스템에서, 분산형 컴퓨터 시스템(100)은 CDN으로서 구성되고, 인터넷 주변에 분산된 한 세트의 머신들(102a-n)을 갖는 것으로 가정된다. 통상적으로, 머신들 대부분은 인터넷의 에지 가까이, 즉, 최종 사용자 액세스 네트워크들에 또는 최종 사용자 액세스 네트워크들에 인접하게 로케이팅되는 서버들이다. NOCC(network operations command center)(104)는 시스템의 다양한 머신들의 동작들을 관리한다. 웹사이트(106)와 같은 제 3 자 사이트들은, 분산형 컴퓨터 시스템(100)으로의, 특히, "에지" 서버들로의 콘텐츠(예를 들어, HTML, 임베디드 페이지 오브젝트들, 스트리밍 미디어, 소프트웨어 다운로드들 등)의 전달을 오프로딩(offload)한다. 통상적으로, 콘텐츠 제공자들은, 주어진 콘텐츠 제공자 도메인들 또는 서브-도메인들을, 서비스 제공자의 권한 도메인 네임 서비스(authoritative domain name service)에 의해 관리되는 도메인들로 (예를 들어, DNS CNAME에 의해) 에일리어싱(aliasing)함으로써, 자신들의 콘텐츠 전달을 오프로딩한다. 콘텐츠를 원하는 최종 사용자들은, 그러한 콘텐츠를 더 신뢰적으로 그리고 효율적으로 획득하기 위해 분산형 컴퓨터 시스템으로 지향된다. 상세하게 도시되지 않았지만, 분산형 컴퓨터 시스템은 또한, 분산형 데이터 수집 시스템(108)과 같은 다른 인프라구조를 포함할 수 있고, 분산형 데이터 수집 시스템(108)은, 모니터링, 로깅(logging), 경보(alert)들, 빌링(billing), 관리 및 다른 운영상의 그리고 관리상의 기능들을 가능하게 하기 위해, 에지 서버들로부터 사용량(usage) 및 다른 데이터를 수집하고, 구역 또는 구역들의 세트에 걸쳐 그러한 데이터를 어그리게이팅(aggregate)하고, 그러한 데이터를 다른 백-엔드 시스템들(110, 112, 114 및 116)에 전달한다. 분산형 네트워크 에이전트들(118)은 네트워크뿐만 아니라 서버 부하들을 모니터링하고, 네트워크, 트래픽, 및 부하 데이터를 DNS 쿼리 핸들링 메커니즘(115)에 제공하고, DNS 쿼리 핸들링 메커니즘(115)은 CDN에 의해 관리되고 있는 콘텐츠 도메인들에 대해 권한이 있다(authoritative). 분산형 데이터 전송 메커니즘(120)은 제어 정보(예를 들어, 콘텐츠를 관리하고 부하 밸런싱을 가능하게 하는 등의 메타데이터)를 에지 서버들로 분산시키기 위해 이용될 수 있다.
도 2에 예시된 바와 같이, 주어진 머신(200)은 하나 또는 둘 이상의 애플리케이션들(206a-n)을 지원하는 운영 시스템 커널(이를 테면, 리눅스 또는 그 변형)(204)을 실행시키는 상용제품 하드웨어(commodity hardware)(예를 들어, 인텔 펜티엄 프로세서)(202)를 포함한다. 콘텐츠 전달 서비스들을 가능하게 하기 위해, 예를 들어, 주어진 머신들은 통상적으로, HTTP (웹) 프록시(207), 네임 서버(208), 로컬 모니터링 프로세스(210), 및 분산형 데이터 수집 프로세스(212)와 같은 애플리케이션들의 세트를 실행한다. 더욱 일반적으로, 프록시(207)는 프로그램 명령들을 포함하는 소프트웨어이고, 명령들은 메모리에 홀딩되고 필요에 따라 프로세서(또는 다수의 프로세서들)에 의해 실행된다.
스트리밍 미디어에 대해, CDN 머신은 일반적으로, 지원되는 미디어 포맷들에 의해 요구되는 하나 또는 그보다 많은 미디어 서버들, 예컨대 윈도우즈 미디어 서버(WMS: Windows Media Server) 또는 플래시 서버를 포함한다. 전용 미디어 서버들의 사용에 대한 대안은 전송 프로토콜로서 HTTP를 사용한다. HTTP 기반 라이브 스트림 및 VOD 기반 전달을 위한 아키텍처들이 미국 공개공보 제20110173345호에 기술된다. 그 접근법은 CDN 내에서 구현되며, 전달될 콘텐츠 스트림을 레코딩 단계(tier)를 이용하여 레코딩하고, 플레이어 단계를 이용하여 스트림을 플레이하는 고 레벨 기능들을 포함한다. 스트림을 레코딩하는 단계는 스트림이 CDN 엔트리 포인트에서 소스 포맷으로 수신될 때 시작되는 한 세트의 하위 단계들을 포함한다. 다음에, 스트림은 중간 포맷(IF: intermediate format)으로 변환되는데, IF는 CDN 내에서 스트림을 전달하기 위한 내부 포맷이며 스트림 적하 목록(stream manifest), 한 세트의 하나 또는 그보다 많은 프래그먼트 인덱스들(FI: fragment indexes) 및 한 세트의 IF 프래그먼트들을 포함한다. 요청 클라이언트가 고스트 기반 프록시와 같은 CDN HTTP 프록시와 연관될 때 플레이어 프로세스가 시작된다. 스트림 또는 그 일부에 대한 요청의 HTTP 프록시에서의 수신에 응답하여, HTTP 프록시는 (아카이브(archive) 또는 데이터 저장소로부터) 스트림 적하 목록 및 적어도 하나의 프래그먼트 인덱스를 리트리브한다. 프래그먼트 인덱스를 사용하여, IF 프래그먼트들이 HTTP 프록시로 리트리브되어, 타깃 포맷으로 변환된 다음, 클라이언트 요청에 응답하여 서빙된다. 소스 포맷은 타깃 포맷과 동일할 수도 또는 상이할 수도 있다. 바람직하게는, HTTP 프록시에 의해 HTTP를 통해 모든 프래그먼트들이 액세스되고, 캐싱되고, 서빙된다. 다른 실시예에서, 주문형 스트림(VOD)을 전달하는 방법은 (레코딩 단계 대신에) 이전(translation) 단계를 사용하여 IF 컴포넌트들의 생성 및/또는 처리를 관리한다.
CDN 에지 서버는 하나 또는 그보다 많은 확장된 콘텐츠 전달 피처들(feature s)을, 바람직하게는, 구성 시스템을 사용하여 에지 서버들에 분배되는 구성 파일들을 사용하여, 바람직하게는 도메인 특정, 고객 특정 단위로 제공하도록 구성된다. 주어진 구성 파일은 바람직하게는 XML 기반형이며, 하나 또는 그보다 많은 고급 콘텐츠 처리 피처들을 가능하게 하는 한 세트의 콘텐츠 처리 규칙들(rules) 및 지시들(directives)을 포함한다. 구성 파일은 데이터 전송 메커니즘을 통해 CDN 에지 서버에 전달될 수 있다. 미국 특허 제7,111,057호는 에지 서버 콘텐츠 제어 정보를 전달 및 관리하기 위한 유용한 인프라구조를 설명하며, 이러한 그리고 다른 에지 서버 제어 정보는 CDN 서비스 제공자 자체, 또는 오리진 서버를 작동시키는 콘텐츠 제공자 고객(엑스트라넷 등을 통해)에 의해 프로비저닝될 수 있다.
CDN 인프라구조는 다수의 제 3 자들에 의해 공유되기 때문에, 이는 본 명세서에서 간혹 멀티 테넌트(multi-tenant) 공유 인프라구조로 지칭된다. CDN 프로세스들은 인터넷 상에서 공개적으로 라우팅 가능한 노드들에, 모바일 네트워크들에, 기업 기반 사설 네트워크들에 또는 이들 근처에 로케이팅된 노드들 내에서 또는 이들 근처에, 또는 이들의 임의의 결합에 로케이팅될 수 있다.
메타데이터 구성 가능한 (도 2의 프록시(207)와 같은) 오버레이 네트워크 웹 프록시는 본 명세서에서 간혹 글로벌 호스트 또는 고스트 프로세스로 지칭된다.
CDN은 예컨대, 미국 특허 제7,472,178호에 기술된 저장용 서브시스템을 포함할 수 있으며, 이 특허의 개시는 인용에 의해 본 명세서에 포함된다.
CDN은 고객 콘텐츠의 중간 캐싱을 제공하도록 서버 캐시 계층 구조를 작동시킬 수 있는데; 이러한 하나의 캐시 계층 구조 서브시스템은 미국 특허 제7,376,716호에 기술되며, 그 개시는 인용에 의해 본 명세서에 포함된다.
CDN은 미국 공개공보 제20040093419호에 기술된 방식으로 클라이언트 브라우저, 에지 서버 및 고객 오리진 서버 사이에서의 보안 콘텐츠 전달을 제공할 수 있다. 여기에서 기술된 바와 같은 보안 콘텐츠 전달은 한편으로는 클라이언트와 에지 서버 프로세스 사이에서, 그리고 다른 한편으로는 에지 서버 프로세스와 오리진 서버 프로세스 사이에서 SSL 기반 링크들을 실시한다. 이는 SSL로 보호되는 웹 페이지 및/또는 이것의 컴포넌트들이 에지 서버를 통해 전달될 수 있게 한다.
오버레이로서, CDN 자원들은 (개인적으로 관리될 수 있는) 기업 데이터 센터들과 제 3 자 서비스형 소프트웨어(SaaS: software-as-a-service) 제공자들 사이의 광역 네트워크(WAN: wide area network) 가속 서비스들을 가능하게 하는데 사용될 수 있다.
CDN은 또한 HD 스트리밍과 같은 다양한 콘텐츠 전달 기능들을 가능하게 하기 위한 클라이언트-측 소프트웨어를 제공할 수 있다. 하나의 접근법에서, 클라이언트는 2 개의 컴포넌트들을 포함한다. 제 1 컴포넌트는, HD 콘텐츠의 적응형 또는 동적 비트레이트 전달을 가능하게 하는 제 3 자(예를 들면, Adobe Flash 또는 Microsoft Silverlight) 컴포넌트들에 기초할 수 있는 비-지속적인, 브라우저 내 미디어 플레이어이다. 제 2 컴포넌트는 "클라이언트-측" 콘텐츠 전달을 수행할 수 있는 지속적인 데몬(persistent daemon) 형태의 인터페이스이다. 클라이언트-측 전달은, 인터페이스를 실행하고 동일한 콘텐츠를 이전에 다운로딩한 다른 최종 사용자들 및 CDN 에지 서버들 둘 모두로부터 콘텐츠를 다운로딩하는 것을 의미한다.
통상적인 HTTP-기반 스트리밍 사용 경우에 대해, 클라이언트는 DNS를 통해 네임(예를 들면, 도메인 네임, 호스트네임 등)을 IP 어드레스로 분해(resolve)하고, 그 어드레스와 연관된 서버에 대한 TCP 연결을 행한다. 일단 설정되면, 클라이언트는 원하는 콘텐츠, 예를 들면, 미디어 프래그먼트에 대한 HTTP GET 요청을 전송한다. 서버는 표준 HTTP 응답 바디 내의 콘텐츠 데이터로 응답한다. 연결은 추가적인 요청들 및 응답들을 위해 개방 상태로 유지된다.
위의 배경설명(background)을 고려하여, 본 개시물의 요지가 이제 설명된다.
스트리밍 및 다운로드들을 위한 하이브리드 HTTP + UDP 접근법
본 개시물은 인터넷을 통해 미디어 및 다른 콘텐츠를 전달하기 위한 새로운 접근법이며, 표준 HTTP-기반 전달을 대체 또는 보충한다. 기존의 표준 스트리밍 및 다운로드 접근법들과 비교하여 주요 차이는 HTTP-기반 요청 및 UDP-기반 응답의 결합이다.
도 3은 본 개시물의 기본적인 접근법을 예시한 다이어그램이다. 이러한 도면에 사용된 바와 같이, 서버(300)는 통신의 서버-측을 지칭하고, 클라이언트(302)는 클라이언트-측을 지칭한다. 서버 및 클라이언트 컴포넌트들은 본 개시물의 HTTP 요청-UDP 응답 기능을 실행하도록 구성되었다. 이러한 예시적인 시나리오에서, 클라이언트(302)는 정해진 바이트 범위들의 관심있는 콘텐츠, 예를 들면, 비디오의 프래그먼트들, 소프트웨어 다운로드 또는 다른 콘텐츠에 대한 HTTP GET 요청들(이들 중 하나가 (304)에 도시됨)을 행한다. 각각의 HTTP 요청은, 클라이언트가 UDP 응답을 수신하도록 인에이블되게 코딩하도록 서버에 지시하는 HTTP 헤더(또는 등가의 대역외(out-of-band) 데이터 구조)를 포함한다. 예시된 바와 같이, 단계(306)에서, 서버(300)는 HTTP 헤더들 및 바디를 포함하는 HTTP 응답으로 HTTP GET 요청에 응답한다. 그러나, 이러한 응답은 몇몇의 측면들에서 종래의 HTTP 응답과 상이하다. 특히, HTTP 응답 헤더들은 서버가 UDP 연결을 위해 리스닝(listen)하는 UDP IP:포트의 식별, 및 선택적으로, 시크릿 토큰(T1)과 같은 데이터 스트링을 포함한다. 그러나, HTTP 응답 바디는 비어 있다(즉, HTTP 응답 바디는 HTTP GET 요청에 의해 요청된 콘텐츠가 전혀 없다(콘텐츠를 포함하지 않는다)). 첫 번째의 2 개의 통신들은 TCP를 통해 발생한다. 본 개시물에 따라, 이후, HTTP 바디에 포함되었을 콘텐츠는 예시된 후속 UDP-기반 연결에 의해 UDP를 통해 전달된다. 특히, 단계(308)에서, HTTP 응답을 수신한 클라이언트는 SYN을 HTTP 응답에서 식별되는 서버의 UDP IP:포트로 발행한다. SYN은 (보안 목적으로) 시크릿 토큰(T1)을 포함할 수 있다. 단계(310)에서, 서버는 시크릿 토큰(T2)을 포함하는 SYNACK를 클라이언트로 리턴한다. 단계(312)에서, 클라이언트는 시크릿 토큰(T2)을 포함하는 ACK로 응답한다. 토큰들은, 오리지널 HTTP 응답을 수신하는 클라이언트만이 요청된 오리지널 콘텐츠를 수신할 수 있다는 것을 보장한다. 다음, 단계(314)에서, 서버는 UDP를 통해 전달된, 요청된 데이터 패킷들로 응답한다.
바람직하게는, HTTP 연결은 (통상적으로 동일하거나 상이한 콘텐츠의 부가적인 바이트 범위들에 대한) 하나 또는 그 초과의 부가적인 HTTP 요청들을 수신하도록 유지(kept-alive)(지속적으로 유지)되며, 요청된 콘텐츠는 이러한 방식으로 UDP를 통해 전달된다.
선택적인 개선은 FEC(forward error correction) 또는 (UDP 전달을 위한) 패킷들의 다른 인코딩을 이용하는 것이다.
다음은 하이브리드 HTTP/UDP 프로토콜의 바람직한 실시예의 부가적인 세부사항들을 제공한다. 도 4는 이러한 하이브리드 HTTP/UDP 연결 초기화 및 이용 시나리오를 예시한다. 위에서 주지된 바와 같이, 하이브리드 접근법은 UDP 프로토콜을 통한 콘텐츠 전송을 위한 별개의 채널을 부가함으로써 차별화된다. 본 명세서에서의 접근법에서, 클라이언트(400)는 DNS(예를 들어, 오버레이 네트워크 당국(overlay network authoritative) DNS)를 통해 네임을 IP 어드레스로 분해하고 그 네트워크에서 에지 서버(402)로의 TCP 연결을 행한다. 일단 설정되면, 단계(404)에서, 클라이언트는 원하는 콘텐츠에 대한 HTTP GET 요청, 예를 들어, 미디어 프래그먼트(media fragment)를 전송하고, 자신이 응답의 바디의 전달을 위해 UDP 연결을 이용하기를 바란다고 표시하는 HTTP 헤더(또는 이와 유사한 것)를 포함한다. 클라이언트는 또한 UDP 전달에 관한 임의의 선호도들(예를 들어, FEC(forward error correction) 또는 다른 파라미터들)을 포함할 수 있지만, 통상적으로 그것은 이러한 선호도들을 따를지를 결정하는 서버에 달려있다. 서버는, UDP 프로토콜의 오브젝트 인에이블드 이용에 대한 메타데이터 프로세싱을 가정하여, 단계(406)에서, 빈(empty) 바디(콘텐츠-길이: 0) 대답으로 응답한다. 응답은 또한 바람직하게는, 프록시들이 도중에 응답을 캐싱하는 것을 방지하기 위해 다양한 헤더들을 포함한다. 응답 헤더들에서, 클라이언트는 UDP 프로토콜을 통해 동일한 서버에 어떻게 연결할지에 관한 정보(또는, 또한 예를 들어, 다중-소스 콘텐츠 획득을 위해 다른 추가의 대안적인 서버 레퍼런스들)를 발견한다. 이 정보는 통상적으로 IP 어드레스를 포함한다(그 이유는, 예를 들어, 지금까지의 연결은 명시적인 프록시 연결을 통하였을 것이지만, 클라이언트는 자신이 통신하고 있는 서버 IP 어드레스에 대한 가시성(visibility)을 갖지 않을 수 있기 때문이다). 리턴된 정보는 또한 UDP 포트 번호, (동일한 서버의 UDP 포트 상에 다수의 이러한 연결들이 있을 수 있기 때문에 통신이 어느 플로우(flow)에 속하는지를 식별하기 위해) 선택적으로 일부 다른 특별 포트 번호, 버전 및 위에서 설명된 바와 같은 토큰 T를 포함한다.
이러한 정보가 서버(402)로부터 수신되면, 클라이언트(400)는 HTTP 응답 헤더들에서 제공된 정보(IP 어드레스, UDP 포트 번호, 다른 포트 번호 등)에 기초하여 서버에 SYN UDP 패킷을 전송함으로써, 단계(408)에서, UDP 연결을 개시한다. 이 요청은 또한 바람직하게는, HTTP 응답으로부터의 토큰 T를 포함한다. 토큰을 이용하여, 서버는 이에 따라 UDP 패킷을 전송하는 클라이언트가 이전의 HTTP 응답을 봤다는 것, 그리고 이러한 SYN 패킷이 프로세싱되어야 한다는 것(그렇지 않으면, 서버에 의해 수신된 모든 예상되지 않은 패킷들은 전송자에게로의 어떠한 응답도 없이 조용히 드롭됨)을 검증할 수 있다. 예시된 바와 같이, 바람직하게는, SYN은 또한 클라이언트의 초기 시퀀스 번호(ISN1)를 포함한다. 단계(410)에서, 서버(402)는, 클라이언트의 SYN 패킷으로부터 확인응답된 ISN1 값을 포함하는 SYN_ACK 패킷으로 응답한다. SYN_ACK는 또한 서버의 ISN 값(ISN2)을 포함한다. 단계(412)에서, 클라이언트는 그 후, 재차 토큰 T를 또한 포함하는 SYN_ACK 패킷으로부터 서버의 확인응답된 ISN(즉, ISN2)을 포함하는 SYN_ACK_ACK 패킷으로 SYN_ACK의 수신을 확인한다. ISN들 및 토큰 T의 확인들은 양자 모두의 당사자들이 통신에 참여하고 이전의 패킷들 모두를 보고 있다는 것을 보장하기 위한 조치로서의 역할을 한다. 토큰(HTTP 응답에서, SYN 및 SYN_ACK_ACK 패킷들)은 이러한 특정한 클라이언트와 서버 인스턴스 간의 다른 HTTP 요청들에 대한 연결의 재사용을 가능하게 한다. 핸드쉐이크(handshake)가 이러한 방식으로 완료되면, UDP-기반 연결은 설정된 것으로 고려되고; 이에 따라 단계(414)에서, 서버는 그 후 (가능하게는 FEC-인코딩된) 콘텐츠를 갖는 데이터 패킷들의 전송을 시작한다. 콘텐츠는 UDP가 이용되지 않는 경우 오리지널 HTTP 응답 바디에 있었던 것과 동일하다. 바람직하게는, 서버는 데이터 패킷들을 계속 전송하고 클라이언트는 확인응답들(ACK)로 응답한다. ACK들은 혼잡 제어를 가능하게 하는데 이용될 수 있다. 핸드쉐이크 및 데이터 전달 동안, 클라이언트는 또한 RST 패킷들과 같은 몇몇 제어 메시지들을 TCP에 유사하게 전송할 수 있다(예를 들어, 단계(416)). 클라이언트는 또한, FEC가 이용되는 경우에, 예를 들어, 현재의 FEC 블록이 성공적으로 디코딩되었고, 다음 블록이 서버에 의해 전송되어야 한다고 표시하는, 서버에 의해 전송된 인코딩된 데이터의 흐름을 제어하기 위한 특별한 패킷들을 전송한다.
추가로 도 4에 나타내어진 바와 같이, 초기 연결 설정 및 교환 이후, 클라이언트(400)는 다음 피스의 콘텐츠를 요청할 수 있다. 그 목적을 달성하기 위해서, 단계(418)에서, 클라이언트(400)는 다음 프래그먼트에 대한 (예를 들어, 동일한 도메인 네임으로) GET 요청을 발행한다. 요청은 HTTP 요청에 대한 기존의 TCP 연결을 이용하여 전송될 수 있으며, 기존의 UDP 연결은 응답을 위해 사용된다. 응답은, 단계(420)에서, 서버(402)로부터 전달된다. 이것은 예시적인 시나리오의 설명을 완성한다.
통상적으로, UDP를 통한 프로토콜 연결은 (TCP를 통한 HTTP와 유사하게) 한번에 하나의 세션을 지원할 뿐이다. 접근법이 연결마다 명백한 멀티플렉싱을 제공하지 않지만, 많은 연결들이 동일한 UDP 포트를 통해 작동할 수 있다; 이와 같이, 운영 시스템의 관점에서, 다수의 연결 시나리오는 멀티플렉싱의 외관을 갖는다. 따라서, 일 실시예에서, 다수의 UDP 포트들(스택 당 하나)가 이용가능한 CPU 프로세싱 자원들을 더욱 양호하게 활용하도록 하나의 서버에서 사용될 수 있다.
바람직하게는, TCP 연결(HTTP용)과 UDP 연결들 둘 모두가 요청을 만족한 후에 연결을 유지한다. 이후, 다른 URL 오프젝트가 다운로드되어야할 경우(예를 들어, 스트림의 다음 미디어 프래그먼트), 연결들 둘 모두는, 이들이 (타임아웃들(timeouts) 전체에 걸쳐) 여전히 연결 상태인 것으로 간주되는 경우 재사용된다(또는 재사용될 수 있다). 바람직하게는, TCP 및 UDP 연결들은, 각각 하나의 HTTP GET 요청에 대한 것 이외는 어떠한 방식으로 커플링되거나 또는 결합되지 않으며, 이들 각각은 다른 것에 영향을 끼치지 않고 밀접해 있을 수 있고, 이들 각각은 추가적인 요청들에 대해 독립적으로 재사용될 수 있다. 새로운 HTTP GET 요청이 TCP 연결을 통해서 (기존의 UDP 연결들이 재사용될 것이라는 것을 나타내는 HTTP 헤더들을 통해서) 전송되고, 서버는 TCP를 통해 HTTP (빈) 응답을 전송함으로써 그리고 또한 기존의 UDP 연결을 통해 요청된 오브젝트의 바디를 전송함으로써 즉시 응답한다.
새로운 프래그먼트에 대한 새로운 UDP 패킷들을 프로세싱하기 전에, (FEC-인코딩 데이터가 사용될 경우) 프로토콜을 통해 들어오는 FEC-인코딩 데이터의 디코딩에 필수적인 세부사항들 모두를 포함하기 때문에, 클라이언트는 통상적으로 완전한 HTTP 응답을 먼저 획득해야만 한다. 또한, 현재 데이터 전달이 완료되기 전에 새로운 HTTP GET 요청을 전송하는 것 (그리고 데이터 전달을 위한 기존의 연결의 재사용을 요청하는 것)이 가능하다. 이것은 기존 전달을 중단시키는 것으로 이어지고, 새로운 요청은 즉시 만족된다. 이를 위해 요구되는 각 측으로부터의 어떠한 별도의 확인도 존재하지 않는데, 이는 이 프로토콜을 따르는 모든 각각의 데이터 패킷이 그 패킷이 "속하는" HTTP 응답의 ID를 포함하기 때문이다; 따라서, 새로운 HTTP 요청에 속하는 데이터 패킷들이 클라이언트에 의해 용이하게 식별된다.
바람직하게는, 프로토콜-특정 정보가, HTTP/1.1의 요건을 따르는 전달 HTTP 헤더 값들을 통해 서버와 클라이언트 사이에서 교환된다. 특수 사용자-에이전트(UA) 스트링이 또한 (프로토콜을 구현하도록 인에이블되는 클라이언트로부터의) 클라이언트 HTTP 요청에 포함될 수 있다. 앞서 주목된 바와 같이, 프로토콜이 사용되는 경우, 서버로부터의 HTTP 응답은 빈 바디를 포함하고 연결을 행하는 방법(또는 연결을 재사용하는 방법)에 관한 세부사항들을 가진 추가적인 전송 헤더를 갖는다. 보다 구체적으로, 서버는, 전송 헤더를 파싱하고, 다음의 것: 하이브리드 프로토콜이 사용되는 경우 HTTP 상태(status) 코드 202를 갖는 HTTP 응답(그리고 헤더는 연결 엔드포인트와 토큰 세부사항들을 포함한다), 프로토콜이 사용되는 경우 상태 코드 202를 갖는 HTTP 응답(그리고 상기 헤더는, 요청 헤더에서 클라이언트에 의해 요청되는 바와 같이, 기존의 프로토콜 연결이 재사용되는 것을 의미하는 토큰 키들과 엔드포인트를 포함하지 않는다), 또는 임의의 상태 코드를 가진 HTTP 응답 (이는, 프로토콜이 사용되지 않는 경우에 이용될 수 있는 것으로, 즉, 프로토콜을 식별하는 어떠한 전송 헤더도 존재하지 않는 것과 같이, 서버가 HTTP 사양에 따라서 거동할 것이고 응답이 바디 내에 자원 데이터를 포함함) 중 하나를 전송함으로써 요청에 응답한다. 둘 모두에서의 202 응답 코드가 중단되는 경우, 응답은 프록시 서버들에 의해 캐싱 불가능하지만, (보통의 서버 메타데이터 세팅들에 의해 제어됨에 따라) 세 번째 것은 캐싱가능하다. (HTTP 202 응답으로) 서버에 의해 부과되는 안티-캐싱 헤더들은, 예를 들어, Pragma: no-cache, Cache-Control:private, must-revalidate, Date, Expires, Cache-Control: no-store, no-cache, max-age=0, 및 Vary:"*"를 포함한다.
토큰은 선택적이다. 토큰은, 32개의 대문자(upper-case) 16진수들로서 표현된 128-비트의 부호없는(unsigned) 정수일 수도 있다. 엔드포인트는 키이며, 그 키의 존재는, 그것이 콘텐츠를 수신하기 위해 (프로토콜을 통하여) 새로운 연결을 설정해야 한다는 것을 클라이언트에게 표시한다. 엔드포인트에 대한 포맷은 [IP_address]-[UDP_port_number]-[destination_port_number]일 수도 있다.
변형 실시예에서, UDP 전달은 멀티캐스트 UDP일 수도 있다. 이러한 변형에서, 상술된 바와 같이, 클라이언트는 서버로의 HTTP 요청을 행하며, HTTP 서버는 빈 바디(empty body)를 포함하는 응답으로 응답한다. HTTP 응답은 또한, 하이브리드 프로토콜에 대한 전송 헤더를 포함하며, 이러한 경우, 헤더는 멀티캐스트 그룹 어드레스를 포함한다. 그 후, 클라이언트는 멀티캐스트 그룹에 참가하고, 요청된 콘텐츠를 수신한다. 멀티캐스트 그룹에 참가하고 멀티캐스트 UDP 패킷들을 수신하는 것은, 네트워크들 내의 클라이언트들에 대한 자동 멀티캐스트 터널링(AMT)에 의해 (옵션으로) 가능해질 수 있으며, 여기서, 네이티브(native) IP 멀티캐스트가 지원되지 않는다. 일단 콘텐츠가 수신되면, 클라이언트는 멀티캐스트 그룹을 떠날 수 있다. 많은 클라이언트들에 의한 (스트림의 세그먼트일 수 있는) 동일한 파일에 대한 임의의 수의 요청들은 동일한 멀티캐스트 그룹을 통해 충족될 수 있다. 이것을 가능하게 하기 위해, 서버는 파일의 데이터를 멀티캐스트 그룹에 전송한다. 바람직하게, 데이터는 FEC-인코딩되어 전송된다. 따라서, 예를 들어, 파일 사이즈가 1MB이면, 서버는, 미리-구성된 레이트로 몇몇 미리 구성된 시간의 양 동안 (클라이언트들에 의한 파일의 디코딩을 위해 유용한) 파일의 데이터에 대한 정보를 포함하는 FEC 패킷들을 전송하는 것을 유지한다. 예를 들어, 서버는 몇몇 정의된 시간 기간 동안 8Mbps(즉, 초당 1MB)로 1MB 파일을 전송할 수도 있다. 그 시간 기간 내에서, 모두 동일한 파일을 요청하는 모든 클라이언트들는 동일한 멀티캐스트 그룹을 사용한다. 이러한 접근법은 자원들을 절약하며, 많은 수신기들로의 인기있는 콘텐츠(라이브 스트림들 또는 소프트웨어 업데이트들)의 전달을 지원할 수 있으면서, 멀티캐스트를 통해 그 콘텐츠의 단일 카피를 전송한다. 파일이 멀티캐스트 그룹으로 전송되고 있는 지속기간은, 클라이언트들에 의한 파일에 대한 요구에 기초하여 동적으로 연장될 수 있으며, 즉, 파일에 대한 요청들이 존재하는 한, 서버는 그 파일을 멀티캐스트 채널로 전송하는 것을 유지한다. 클라이언트들은 임의의 시간에 멀티캐스트 그룹에 참가할 수 있으며, FEC 인코딩으로 인해, 그 클라이언트들은 단지, 오리지널 파일을 디코딩하기에 충분한 데이터를 수신할 필요가 있는 한, 참가할 필요가 있다. 최적화로서, 서버들은 다수의 멀티캐스트 그룹들 상에서 동일한 파일의 콘텐츠를 병렬로 전송할 수도 있으며, 클라이언트들은 그 그룹들 중 다수(그 모두는 오리지널 HTTP 응답의 헤더에서 리턴될 것임)에 참가할 수도 있어서, 그들의 다운로드 용량을 더 잘 이용하고, (FEC가 다수의 자원들로부터의 데이터를 용이하게 결합하는 것을 허용함으로써) 파일들을 더 신속하게 수신하게 한다.
알 수 있는 바와 같이, 접근법은, (프로토콜을 사용하도록 구성된) 서버로의 HTTP 요청을 행하는 (하이브리드 HTTP-UDP 프로토콜을 사용하도록 구성된) 클라이언트에 의해 작동하며, 그 후, 그 서버는 HTTP 요청에 대한 응답으로서 UDP를 통해 미디어 또는 파일 콘텐츠를 리턴한다. 이러한 접근법은 제공자가, HTTP-기반 웹서버에 구축된 액세스 제어, 인증, QoS 리포팅, GEO-위치 및 다른 피처들을 포함하는 HTTP에 대해 이용가능한 표준 CDN 인프라구조를 사용 또는 레버리지할 수 있게 하면서, UDP의 상단 상에서 미디어 또는 파일 데이터 전송의 완전한 제어를 제공한다. 완전한 제어를 제공하는 것은, (패킷 손실 및 레이턴시와 같은) 네트워킹 특징들이 최적화되지 않은 경우라도 더 양호한 경험 및 제어를 제공하기 위해 (상술된 바와 같은) 순방향 에러 정정과 같은 패킷들의 맞춤형 혼잡 제어 접근법들 및/또는 인코딩을 제한없이 포함한다. 따라서, 그러한 경우, 접근법은, 종래의 다운로드들 및 스트리밍 솔루션들로부터의 HTTP의 기존의 피처들을 사용하는 이점들과 데이터의 UDP-기반 전송의 이점들을 결합시킨다. 하이브리드 접근법은, 그 접근법이 전송될 것을 제어하기 위해 기존의 HTTP-기반 솔루션들을 사용하지만 동시에 미디어 또는 다른 콘텐츠에 대해 UDP-기반 데이터 전송을 사용하는 것으로부터 이득을 얻기 때문에 매우 유리하다. UDP 통신이 가능하지 않은 경우들에서, 표준 HTTP는, 모든 각각의 클라이언트가 데이터를 수신할 수 있다는 것을 보장하기 위해 요청 및 응답 둘 모두에 대해 사용된다. UDP에 대한 지원은 HTTP를 통해 전달된다.
애플리케이션 및 서버가 접근법을 직접적으로 사용할 수 있거나, 또는 이 기능에 대한 지원을 부가시키는데 프록시가 사용될 수 있다. 예컨대, (다운로드들을 위한) 브라우저 또는 스트리밍 애플리케이션이 HTTP를 통해서만 프록시에 요청을 행할 수 있거나 또는 프록시를 통해 요청을 행할 수 있고, 그런 다음 프록시는, 서버와 통신할 때, 이 접근법을 사용한다. 바람직하게는, 프록시가 하이브리드 HTTP 및 UDP-기반 프로토콜을 통해 서버와 통신하는 반면에, 클라이언트-대-프록시 통신은 HTTP-전용이다. 유사하게, 이 접근법에 대한 지원을 부가시키기 위해 웹 서버가 (명백하게 또는 명시적으로) 프록시를 사용할 수 있다.
스트리밍을 위해, 접근법이 임의의 기존의 HTTP-기반 스트리밍 기술들에 대해 잘 동작한다는 장점이 부가된다.
더욱 일반적으로는, 서버로부터 클라이언트로의 HTTP 스트리밍이 요구될 때마다, 본원에 설명된 접근법이 구현될 수 있다. 클라이언트는, 비디오 스트림을 수신하고 그것을 다시 스크린에 재생시키는 측을 지칭한다. 클라이언트들은 데스크톱 컴퓨터, 모바일 디바이스(스마트 폰들, 태블릿들 등), 셋-톱 박스들, 스마트 텔레비전들, 또는 임의의 다른 연결된 디바이스들 상에서 실행을 할 수 있다. 서버는 스트림 데이터를 클라이언트에 전송하는 측이다. 본원에서 지칭된 바와 같이, HTTP-기반 스트리밍은, 재생을 위한 스트림을 구성하기 위한 오브젝트들을 요청 및 다운로딩하는데 HTTP 프로토콜만을 사용하는 임의의 비디오 스트리밍을 지칭한다. 비-제한적 예들은 Apple HLS, Adobe HDS, Microsoft SmoothStreaming, 및 MPEG-DASH을 포함한다. 본원의 접근법은, 라이브 및 온-디맨드 스트리밍, 예컨대 H.264 비디오 엘러멘터리 스트림으로 구성된 프로그램 스트림을 포함하는 MPEG-2 전송 스트림, 및 AAC 오디오 엘러멘터리 스트림을 지원하는데 사용될 수 있다. 본 예는 물론 제한시키는 것으로 의도되지 않는다.
본원에 설명된 HTTP/UDP 하이브리드 전달 접근법은 비디오 스트리밍 품질을 개선한다. 접근법은 기존의 HTTP-기반 스트리밍 솔루션들에 명백하게 맞춰질 수 있다. 하이브리드 접근법이 미디어 데이터 전송에 대한 패킷 손실 및 레이턴시의 부정적 영향을 크게 감소시켜, 이로써 스트리밍 품질을 크게 개선한다.
본원에 설명된 기술의 클라이언트 파트는 하나 또는 그 초과의 플랫폼들(예컨대, iOS, Android 등)에 대한 소프트웨어 개발 키트(SDK)로서 구현될 수 있고, SDK는, 하이브리드 HTTP/UDP 접근법을 이용하여 호환 가능한 모바일 앱들이 콘텐츠를 다운로딩/스트리밍하는 것을 가능케 하기 위해 플랫폼들 상의 애플리케이션들에서 사용될 수 있다. 따라서, 예컨대, 애플리케이션은 자신의 API를 통해 URL 오브젝트들을 다운로딩하는데 SDK를 사용할 수 있거나, 또는 애플리케이션은 SDK에 의해 생성된 로컬 HTTP 서버를 사용하여 그로부터 스트리밍/다운로딩할 수 있다.
하이브리드 프로토콜은 특히, FEC-기반 UDP 전달과 같은 다른 기술들 및 진화된 혼잡 제어 기술들과 커플링될 때, 상당한 이점들을 제공한다. FEC는 리던던시를 이용함으로써 패킷 손실을 극복하는 잘 알려진 기술이다. FEC에서, 패킷들(여기서, 각각의 패킷은 한 피스의 데이터를 표현함)의 오리지널 흐름을 전송하는 것 대신에, 전송측(sender)은 데이터를 패킷들의 새로운 세트(여기서, 각각의 패킷은 추가 패리티 데이터를 가지는 오리지널 데이터의 다양한 부분들에 대한 정보를 홀딩함)로 인코딩한다. 새로운 세트는 일반적으로, 오리지널 데이터에 비해 크기가 더 크다. 인코딩된 데이터의 수신기는 디코딩을 수행하고, 그것이 충분히 코딩된 패킷들을 수신하면, 오리지널 데이터를 재구성한다. 데이터를 재구성하기 위해, 보통 오리지널 데이터 크기와 동일한 인코딩 데이터의 양만이 수신될 필요가 있거나, 약간 더 많이 수신될 필요가 있다. 이것은 전달이 손실되게는 하지만, 여전히 데이터의 재전송에 대한 어떠한 필요성 없이도 오리지널 데이터를 디코딩할 수 있다. 서로 다른 손실 레이트들 및 애플리케이션들에 적합한 다양한 FEC 코드들이 존재한다. IETF 신뢰성있는 멀티캐스트 워킹 그룹은 컨텐츠를 신뢰성있게 전달하는데 이용될 특정된 3개의 FEC 방식들, 즉, RaptorQ(RFC(6330)에서 설명됨), LDPC(Low-density parity-check)(RFC(5170)에서 설명됨) 및 Reed-Solomon (RFC(5510)에서 설명됨)을 갖는다. 다른 공지된 FEC 기술들은 RaptorQ의 이전 버전인 Raptor R10(RFC(5053)에 설명됨)을 포함한다. Akamai®FastTCP™과 같은 혼잡 제어 방식들은 서버로부터 클라이언트로 전송되는 데이터 패킷들에 대한 커스텀 혼잡 제어를 가능하게 하도록 이용하기 위해 적응될 수 있다. 일반적으로, 이러한 공지된 방식은 큐잉 지연을 이용하여 네트워크 혼잡을 측정한다. 전송측에 있어서, CWND(congestion window)는 전송할 바이트들의 수를 제어하는데 이용된다. 초기에 그리고 방식에 따라, CWND는 전송 지연을 매칭 업하기 위해 신속하게 증가되고, 그 다음, (패킷들이 경로를 따라 큐잉되는 바와 같이) 큐잉 지연의 변화를 매칭 업하기 위해 덜 공격적으로 조정된다. 전송측은 그것의 네트워크 변화들에 적응하기 위해 CWND를 조정한다.
본원에 설명된 기술은, 표준 TCP 또는 다수의 병렬 TCP 연결들과 비교하여, 랜덤 환경(비-혼잡(non-congestive)) 손실 및 높은 레이턴시 하에서 전체 쓰루풋의 증가를 제공한다. 이 기술은 또한 더욱 정확한 대역폭 추정 및 진보된 혼잡 검출을 통해 쓰루풋의 안정성의 증가를 제공한다. 게다가, 이 기술은, 스타트-업 시간에서의 감소, 재버퍼링 이벤트들의 품질 및 지속기간에서의 감소, 및 비트레이트 스위칭의 주파수에서의 감소를 제공한다. 전술한 전부는, 더 긴 뷰잉 시간 및 더 양호한 사용자 경험을 유도한다. 설명된 기술은 또한 스트리밍에 대해 표준 HTTP 접근법을 이용하는 매끄러운 페일-백(smooth fail-back) 모드를 제공한다.
변형으로서, 전달의 UDP-기반 부분은 다중경로(multipath)를 통해 수행될 수 있다. 일반적으로, 다중경로는 다수의 소스들(예를 들어, 다수의 에지 서버들, 최종 사용자 피어들 등)로부터의 동시의 다운로딩을 지칭한다. 다중경로는 또한, 동일한 서버(또는 피어)가 네트워크 내 상이한 경로들을 통해 동시에 다수 회 다운로딩하기 위해 이용되는 시나리오를 지칭한다. 이러한 방식들은 FEC 코딩이 구현될 때 유용할 수 있는데, 이는 FEC는 어떠한 조정(reconciliation)도 없이 수많은 소스들로부터의 데이터를 조합하는 것을 허용하기 때문이다. 특정 상황들에서, 다수의 소스들로부터 동시에 다운로딩하는 것(그리고 이들 소스들을 자신들의 수행에 따라 심지어는 동적으로 변경시키는 것)은, UDP 페이즈에 관련되는 동안 구현될 수 있다.
대표적인 구현예에서, 본 요지의 기능은, 프로세서에 의해 실행되는 컴퓨터 프로그램 명령들로서 소프트웨어에서 구현된다.
더 일반적으로, 본 명세서에 설명된 기술들은, 앞서 설명된 기능을 함께 조장하거나 또는 제공하는 일 세트의 하나 또는 그 초과의 컴퓨팅-관련 엔티티들(시스템들, 머신들, 프로세스들, 프로그램들, 라이브러리들, 기능들 등)을 이용하여 제공된다. 통상의 구현예에서, 소프트웨어가 실행되는 대표적인 머신은 상용제품 하드웨어, 운영 시스템, 애플리케이션 런타임 환경, 및 주어진 시스템 또는 서브시스템의 기능을 제공하는 일 세트의 애플리케이션들 또는 프로세스들 및 연관된 데이터를 포함한다. 설명된 바와 같이, 기능은 독립형 머신에서 또는 분산형 머신들의 세트에 걸쳐 구현될 수 있다. 이 기능은 서비스로서, 예를 들어, SaaS 솔루션으로서 제공될 수 있다.
상기 내용이 본 발명의 특정한 실시예들에 의해 수행되는 동작들의 특정 순서를 설명하였지만, 대안적인 실시예들이 상이한 순서의 동작들을 수행하고, 특정한 동작들을 결합시키고, 특정한 동작들을 오버랩시키는 등을 할 수도 있기 때문에, 그러한 순서는 예시적이라는 것이 이해되어야 한다. 주어진 실시예에 대한 본 명세서에서의 참조들이, 설명된 실시예가 특정한 피처, 구조, 또는 특징을 포함할 수도 있다는 것을 표시하지만, 모든 각각의 실시예가 특정한 피처, 구조, 또는 특징을 반드시 포함하지는 않을 수도 있다.
기재된 요지는 방법 또는 프로세스의 맥락에서 설명되었지만, 주제 개시는 또한, 본원의 동작들을 수행하기 위한 장치와 관련된다. 이러한 장치는 요구되는 목적들을 위해 특별하게 구성될 수도 있거나, 또는 상기 장치는, 컴퓨터에 저장된 컴퓨터 프로그램에 의해 선택적으로 활성화되거나 또는 재구성되는 범용 컴퓨터를 포함할 수도 있다. 이러한 컴퓨터 프로그램은, 컴퓨터 시스템 버스에 각각 커플링되고, 광학 디스크, CD-ROM, 및 자기-광학 디스크를 포함하는 임의의 타입의 디스크, ROM(read-only memory), RAM(random access memory), 자기 또는 광학 카드, 또는 전자 명령들을 저장하기에 적절한 임의의 타입의 미디어와 같은(그러나, 이에 제한되지 않음) 컴퓨터 판독가능 저장 매체에 저장될 수도 있다.
시스템의 주어진 컴포넌트들이 개별적으로 설명되었지만, 당업자는, 기능들 중 몇몇이 주어진 명령들, 프로그램 시퀀스들, 코드 부분들 등에서 공유되거나 또는 결합될 수도 있다는 것을 이해할 것이다.
바람직하게, 기능은 애플리케이션 계층 솔루션에서 구현될 수 있지만, 식별된 기능들의 부분들이 운영 시스템 등에 구축될 수도 있기 때문에, 이는 제한이 아니다.
기능은, HTTP 외에도 HTTPS과 같은 다른 애플리케이션 계층 프로토콜들로, 또는 유사한 동작 특징들을 갖는 임의의 다른 프로토콜로 구현될 수 있다.
일반적으로, 클라이언트-측 또는 서버-측의 연결을 구현할 수 있는 컴퓨팅 엔티티의 타입에 대한 어떠한 제한도 존재하지 않는다. 임의의 컴퓨팅 엔티티(시스템, 머신, 디바이스, 프로그램, 프로세스, 유틸리티 등)는 클라이언트 또는 서버로서 동작할 수 있다.
청구되는 것은 다음과 같다.

Claims (14)

  1. 데이터 전달 방법으로서,
    하드웨어 플랫폼상에서 실행되는 서버에서,
    콘텐츠 오브젝트를 식별하는 HTTP 요청을 지속적인 연결을 통해 클라이언트로부터 수신하는 단계 ― 상기 HTTP 요청은 상기 클라이언트가 원하는 UDP 전달에 대한 선호도들과 함께 상기 HTTP 요청에 대한 응답의 바디(body)의 전송을 위해 상기 클라이언트가 UDP 연결을 이용하기를 원한다는 표시를 포함하는 HTTP 요청 헤더를 포함함 ―;
    헤더 및 응답 바디를 포함하는 상기 HTTP 요청에 대한 응답을 상기 클라이언트로 리턴하는 단계 ― 상기 헤더는 보안 토큰을 포함하고 상기 응답 바디는 상기 서버와 연관된 IP 어드레스 및 UDP 포트 번호를 식별하며, 상기 응답 바디는 요청된 콘텐츠 오브젝트가 없음 ―;
    상기 IP 어드레스 및 UDP 포트 번호에 관한 UDP 요청을 상기 클라이언트로부터 수신하는 단계 ― 상기 UDP 요청은 상기 보안 토큰을 포함함 ―; 및
    상기 HTTP 요청에서 식별된 상기 콘텐츠 오브젝트를 포함하는 상기 UDP 요청에 대한 응답을 상기 UDP 연결을 통해 리턴하는 단계 ― 상기 콘텐츠 오브젝트는 상기 응답 바디에서 리턴되지 않음 ―
    를 포함하는, 데이터 전달 방법.
  2. 제 1항에 있어서,
    상기 클라이언트와 상기 서버 사이에 지속적인 HTTP 연결을 유지하는 단계를 더 포함하는, 데이터 전달 방법.
  3. 제 2항에 있어서,
    상기 클라이언트로부터 적어도 하나의 추가적인 HTTP 요청을 수신하는 단계; 및
    상기 적어도 하나의 추가적인 HTTP 요청에 대한 UDP-기반 응답을 리턴하는 단계
    를 더 포함하는, 데이터 전달 방법.
  4. 삭제
  5. 제 1항에 있어서,
    상기 UDP 요청에 대한 응답을 리턴하기 전에, 상기 서버는 상기 UDP 요청이 또한 상기 보안 토큰을 포함함을 확인하는, 데이터 전달 방법.
  6. 제 1항에 있어서,
    상기 헤더는 또한, 상기 서버와 상기 클라이언트 사이의 하나 또는 그 초과의 프록시들이 상기 HTTP 요청에 대한 응답을 캐싱하는 것을 막는 정보를 포함하는, 데이터 전달 방법.
  7. 장치로서,
    프로세서;
    컴퓨터 프로그램 명령들을 보유하는 컴퓨터 메모리를 포함하며;
    상기 컴퓨터 프로그램 명령들은,
    콘텐츠 오브젝트를 식별하는 요청을 지속적인 연결을 통해 클라이언트로부터 수신하기 위한 프로그램 코드 ― 상기 요청은 제 1 전송 프로토콜(transport protocol)을 통해 전달되고, 상기 요청은 상기 클라이언트가 원하는 제 2 전송 프로토콜 연결을 통한 전달에 대한 선호도들과 함께 상기 요청에 대한 응답의 바디의 전송을 위해 상기 클라이언트가 상기 제 2 전송 프로토콜 연결을 이용하기를 원한다는 표시를 포함하는 제 1 전송 프로토콜 요청 헤더를 포함함 ―;
    상기 요청에 대한 응답을 상기 클라이언트로 리턴하기 위한 프로그램 코드 ― 상기 응답은 상기 제 1 전송 프로토콜을 통해 전달되고, 상기 응답은 콘텐츠 오브젝트 요청 대신에 빈(empty) 응답 바디, 및 적어도 제 1 정보 및 제 2 정보를 포함하는 전송 헤더를 포함하고, 상기 제 1 정보는 상기 제 1 전송 프로토콜과 상이한 제 2 전송 프로토콜을 통해 상기 콘텐츠 오브젝트가 획득될 수 있는 어드레스 및 포트 번호를 식별하고, 상기 제 2 정보는 상기 요청이 상기 요청을 발행한 클라이언트에 의해 수신됨을 확인할 때 후속하여 사용되며, 상기 제 2 정보는 보안 토큰을 포함함 ―; 및
    상기 보안 토큰을 포함하고 상기 제 2 전송 프로토콜을 통해 전달되는 요청의 상기 어드레스에서의 수신에 응답하는 프로그램 코드 ― 상기 프로그램 코드는 상기 제 1 전송 프로토콜을 통해 전달된 상기 응답에서 리턴되지 않는 상기 콘텐츠 오브젝트를 상기 제 2 전송 프로토콜 연결을 통해 리턴하기 위해 상기 제 2 전송 프로토콜을 통해 전달되는 상기 요청에 대한 응답으로 동작됨 ―
    를 포함하는, 장치.
  8. 제 7항에 있어서,
    상기 제 1 전송 프로토콜은 HTTP이며,
    상기 제 2 전송 프로토콜은 유니캐스트 및 멀티캐스트 중 하나를 통한 UDP인, 장치.
  9. 삭제
  10. 제 7항에 있어서,
    상기 콘텐츠 오브젝트는 순방향 에러 정정(FEC) 코딩 방식에 따라 리턴되는, 장치.
  11. 제 7항에 있어서,
    상기 어드레스는, 한 세트의 멀티캐스트 그룹 어드레스들 및 멀티캐스트 그룹 어드레스 중 하나인, 장치.
  12. 서비스 제공자가 HTTP-기반 스트리밍을 사용하여 에지 서버들로부터 비디오 전달을 제공하는 멀티-테넌트 오버레이 네트워크 환경(multi-tenant overlay network environment)에서 동작하는 시스템으로서,
    하드웨어 프로세서에서 실행되는 서버-측 프로그램 코드를 포함하는 제 1 머신; 및
    하드웨어 프로세서에서 실행되는 클라이언트-측 프로그램 코드를 포함하는 제 2 머신을 포함하고,
    상기 서버-측 프로그램 코드는,
    콘텐츠 오브젝트를 식별하는 HTTP 요청을 지속적인 연결을 통해 상기 클라이언트-측 프로그램 코드로부터 수신하고 ― 상기 HTTP 요청은 클라이언트가 원하는 UDP 전달에 대한 선호도들과 함께 상기 HTTP 요청에 대한 응답의 바디의 전송을 위해 상기 클라이언트가 UDP 연결을 이용하기를 원한다는 표시를 포함하는 HTTP 요청 헤더를 포함함 ―,
    헤더 및 응답 바디를 포함하는 상기 HTTP 요청에 대한 응답을 상기 클라이언트-측 프로그램 코드로 리턴하고 ― 상기 헤더는 보안 토큰을 포함하고 상기 서버-측 프로그램 코드와 연관된 UDP IP 어드레스 및 포트 번호를 식별하며, 그리고 상기 응답 바디는 요청된 상기 콘텐츠 오브젝트가 없음 ―,
    상기 UDP IP 어드레스 및 포트 번호에 관한 UDP 요청을 상기 클라이언트-측 프로그램 코드로부터 수신하며 ― 상기 UDP 요청은 상기 보안 토큰을 포함함 ―, 그리고
    상기 응답 바디에서 리턴되지 않고 상기 HTTP 요청에서 식별된 상기 콘텐츠 오브젝트를 포함하는, 상기 UDP 요청에 대한 상기 UDP 연결을 통한 응답을 상기 클라이언트-측 프로그램 코드로 리턴하도록 동작하며,
    상기 클라이언트-측 프로그램 코드는,
    상기 콘텐츠 오브젝트를 식별하는 상기 HTTP 요청을 상기 지속적인 연결을 통해 상기 서버-측 프로그램 코드에 전송하며,
    상기 보안 토큰을 포함하고 상기 서버-측 프로그램 코드와 연관된 상기 UDP IP 어드레스 및 포트 번호를 식별하는 상기 헤더 및 요청된 상기 콘텐츠 오브젝트가 없는 상기 응답 바디를 포함하는, 상기 HTTP 요청에 대한 응답을 수신하며,
    상기 UDP IP 어드레스 및 포트 번호에 관한 상기 UDP 요청을 전송하며 ― 상기 UDP 요청은 HTTP 응답에서 제공되었던 상기 보안 토큰을 포함함 ―, 그리고
    상기 응답 바디에서 리턴되지 않고 상기 HTTP 요청에서 식별되었던 상기 콘텐츠 오브젝트를 포함하는, 상기 UDP 요청에 대한 응답을 수신하도록 동작하는, 멀티-테넌트 오버레이 네트워크 환경에서 동작하는 시스템.
  13. 삭제
  14. 제 12항에 있어서,
    상기 UDP 요청은 상기 보안 토큰을 포함하며,
    상기 서버-측 프로그램 코드는 상기 UDP 요청이 또한 상기 보안 토큰을 포함함을 상기 서버-측 프로그램 코드가 확인하는 경우에 상기 UDP 요청에 대한 응답을 리턴하도록 추가로 동작하는, 멀티-테넌트 오버레이 네트워크 환경에서 동작하는 시스템.
KR1020157007312A 2012-08-24 2013-08-24 하이브리드 http 및 udp 콘텐츠 전달 KR102076523B1 (ko)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201261692950P 2012-08-24 2012-08-24
US61/692,950 2012-08-24
US13/974,087 US9628542B2 (en) 2012-08-24 2013-08-23 Hybrid HTTP and UDP content delivery
US13/974,087 2013-08-23
PCT/US2013/056534 WO2014032036A1 (en) 2012-08-24 2013-08-24 Hybrid http and udp content delivery

Publications (2)

Publication Number Publication Date
KR20150048179A KR20150048179A (ko) 2015-05-06
KR102076523B1 true KR102076523B1 (ko) 2020-02-12

Family

ID=50149020

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020157007312A KR102076523B1 (ko) 2012-08-24 2013-08-24 하이브리드 http 및 udp 콘텐츠 전달

Country Status (6)

Country Link
US (4) US9628542B2 (ko)
EP (1) EP2888857B1 (ko)
JP (1) JP6278531B2 (ko)
KR (1) KR102076523B1 (ko)
CN (1) CN104662865B (ko)
WO (1) WO2014032036A1 (ko)

Families Citing this family (44)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8560604B2 (en) 2009-10-08 2013-10-15 Hola Networks Ltd. System and method for providing faster and more efficient data communication
US9241044B2 (en) 2013-08-28 2016-01-19 Hola Networks, Ltd. System and method for improving internet communication by using intermediate nodes
US9380351B2 (en) * 2014-01-17 2016-06-28 Lg Display Co., Ltd. Apparatus for transmitting encoded video stream and method for transmitting the same
US20150271226A1 (en) * 2014-03-18 2015-09-24 Qualcomm Incorporated Transport accelerator implementing a multiple interface architecture
US9866655B2 (en) 2014-03-31 2018-01-09 Akamai Technologies, Inc. Server initiated multipath content delivery
WO2015160953A2 (en) * 2014-04-16 2015-10-22 Pixia Corp. Method and system of transmitting data over a network using a communication protocol
US11073822B2 (en) * 2014-09-25 2021-07-27 Siemens Aktiengesellschaft Provision of process values in a process installation
EP3243317B1 (en) * 2015-01-05 2024-04-10 Convida Wireless, LLC Machine-to-machine protocol indication and negotiation
US11057446B2 (en) 2015-05-14 2021-07-06 Bright Data Ltd. System and method for streaming content from multiple servers
CN106330997B (zh) 2015-06-19 2019-08-09 网宿科技股份有限公司 一种用于移动终端应用的内容分发的方法和系统
CN106549916A (zh) * 2015-09-18 2017-03-29 中兴通讯股份有限公司 组播传输方法、装置及系统
CN106686410B (zh) * 2015-11-09 2019-05-07 中国电信股份有限公司 Hls流媒体传输方法以及装置
US9985890B2 (en) * 2016-03-14 2018-05-29 International Business Machines Corporation Identifying a local congestion control algorithm of a virtual machine
US10397079B2 (en) * 2016-09-27 2019-08-27 Netscout Systems, Inc. Video delivery performance analysis for EMBMS
CN106453356B (zh) * 2016-10-25 2019-08-02 网宿科技股份有限公司 无线网络双边加速传输方法和系统
US10334052B2 (en) 2016-10-28 2019-06-25 Caterpillar Inc. System and method for communicating negotiated groups of parameters
JP6467395B2 (ja) * 2016-11-25 2019-02-13 キヤノン株式会社 画像送信装置、画像受信装置、それらの制御方法および画像通信システム
CN108234433A (zh) * 2016-12-22 2018-06-29 华为技术有限公司 用于处理视频业务的方法和装置
CN106790564A (zh) * 2016-12-27 2017-05-31 北京小度互娱科技有限公司 推送数据的方法及装置
CN106487819B (zh) * 2016-12-29 2019-11-15 北京奇艺世纪科技有限公司 一种通过udp代理http请求的方法和装置
US11088940B2 (en) 2017-03-07 2021-08-10 Akamai Technologies, Inc. Cooperative multipath
US10594661B1 (en) * 2017-06-13 2020-03-17 Parallels International Gmbh System and method for recovery of data packets transmitted over an unreliable network
US10652300B1 (en) * 2017-06-16 2020-05-12 Amazon Technologies, Inc. Dynamically-generated encode settings for media content
EP3767494B1 (en) 2017-08-28 2023-02-15 Bright Data Ltd. Method for improving content fetching by selecting tunnel devices
US11381339B2 (en) * 2017-11-06 2022-07-05 Code On Network Coding, Llc System and technique for generating, transmitting and receiving network coded (NC) quick UDP internet connections (QUIC) packets
CN110166506B (zh) * 2018-02-12 2021-11-19 中国移动通信有限公司研究院 超文本传输协议Http的连接方法及节点设备
US10819562B2 (en) * 2018-07-24 2020-10-27 Zscaler, Inc. Cloud services management systems utilizing in-band communication conveying situational awareness
TWI692233B (zh) 2018-12-19 2020-04-21 財團法人工業技術研究院 基於用戶資料報協定及傳輸控制協定之協同傳輸方法及傳輸裝置
EP4075304B1 (en) 2019-02-25 2023-06-28 Bright Data Ltd. System and method for url fetching retry mechanism
CN113475084B (zh) * 2019-02-27 2024-02-02 英国电讯有限公司 多播辅助传送
US11411922B2 (en) 2019-04-02 2022-08-09 Bright Data Ltd. System and method for managing non-direct URL fetching service
CN110535751B (zh) * 2019-08-19 2023-01-24 深圳追一科技有限公司 一种消息响应方法、装置、计算机设备和存储介质
CN111385349B (zh) * 2020-02-07 2021-07-16 北京达佳互联信息技术有限公司 通信处理方法、装置、终端、服务器及存储介质
US11622024B2 (en) 2020-09-25 2023-04-04 Forcepoint Llc Cloud-based explicit proxy
US11695736B2 (en) 2020-09-25 2023-07-04 Forcepoint Llc Cloud-based explicit proxy with private access feature set
US12015594B2 (en) 2020-09-25 2024-06-18 Forcepoint Llc Policy integration for cloud-based explicit proxy
CN112492004B (zh) * 2020-11-17 2023-02-17 深圳市晨北科技有限公司 本地通信链接的建立方法及设备、系统及存储介质
US11811734B2 (en) * 2021-06-17 2023-11-07 Prosimo Inc Protocol switching for connections to zero-trust proxy
CN113630439B (zh) * 2021-06-30 2023-05-05 网宿科技股份有限公司 实时通信rtc连接方法、服务器及存储介质
DE112022004642T5 (de) * 2021-09-30 2024-08-22 Denso Corporation Datenkommunikationssystem, zentrumsvorrichtung, mastervorrichtung, aktualisierungsdatenplatzierungsprogramm und aktualisierungsdatenbeschaffungsprogramm
WO2023129183A1 (en) * 2021-12-30 2023-07-06 17Live Japan Inc. System, method and computer-readable medium for streaming data accessing
CN114615237B (zh) * 2022-03-22 2024-03-29 阿里巴巴（中国）有限公司 流媒体通信方法、系统、设备及存储介质
US12081585B2 (en) * 2022-03-25 2024-09-03 Roblox Corporation Online game network demultiplexer with denial-of-service prevention
US20240146986A1 (en) * 2022-10-31 2024-05-02 Adobe Inc. Automatic deferred edge authentication for protected multi-tenant resource management systems

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050262251A1 (en) * 2004-05-03 2005-11-24 Microsoft Corporation Fast startup for streaming media
US20080086523A1 (en) * 2006-08-18 2008-04-10 Akamai Technologies, Inc. Method of data collection in a distributed network
WO2010132462A2 (en) * 2009-05-14 2010-11-18 Microsoft Corporation Http-based authentication
US20110231569A1 (en) * 2009-09-22 2011-09-22 Qualcomm Incorporated Enhanced block-request streaming using block partitioning or request controls for improved client-side handling

Family Cites Families (44)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6704786B1 (en) * 1997-12-15 2004-03-09 Sun Microsystems, Inc. Network and end-host efficiency for web communication
US7010582B1 (en) * 2000-06-26 2006-03-07 Entrust Limited Systems and methods providing interactions between multiple servers and an end use device
US7111057B1 (en) 2000-10-31 2006-09-19 Akamai Technologies, Inc. Method and system for purging content from a content delivery network
US7340505B2 (en) 2001-04-02 2008-03-04 Akamai Technologies, Inc. Content storage and replication in a managed internet content storage environment
US7463591B1 (en) * 2001-06-25 2008-12-09 Juniper Networks, Inc. Detecting data plane liveliness of a label-switched path
EP1470497A1 (en) * 2002-01-12 2004-10-27 Coretrust, Inc. Method and system for the information protection of digital content
FI116017B (fi) * 2002-01-22 2005-08-31 Netseal Mobility Technologies Menetelmä viestien lähettämiseksi turvallisten mobiiliviestintäyhteyksien läpi
JP2003304523A (ja) * 2002-02-08 2003-10-24 Ntt Docomo Inc 情報配信システム、情報配信方法、情報配信サーバ、コンテンツ配信サーバ及び端末
AU2003226128A1 (en) * 2002-03-27 2003-10-13 First Virtual Communications System and method for traversing firewalls with protocol communications
US7133905B2 (en) 2002-04-09 2006-11-07 Akamai Technologies, Inc. Method and system for tiered distribution in a content delivery network
US20040093419A1 (en) 2002-10-23 2004-05-13 Weihl William E. Method and system for secure content delivery
CN1764897B (zh) * 2003-03-28 2010-11-10 汤姆森特许公司 用于传输基于媒体的文件的系统和方法
US20050165849A1 (en) * 2003-08-05 2005-07-28 G-4, Inc. Extended intelligent video streaming system
EP1693999A4 (en) * 2003-12-11 2011-09-14 Panasonic Corp PACK STATION DEVICE
US7577749B1 (en) * 2004-12-03 2009-08-18 Ux Ltd. Emulation of persistent HTTP connections between network devices
US20070174880A1 (en) * 2005-07-05 2007-07-26 Optibase Ltd. Method, apparatus, and system of fast channel hopping between encoded video streams
DE102005033211A1 (de) * 2005-07-13 2007-01-18 Deutsche Thomson-Brandt Gmbh Verfahren zur Feststellung der Aktivität eines Gerätes in einem Netzwerk verteilter Stationen sowie Netzwerkstation für die Durchführung des Verfahrens
US8191119B2 (en) * 2005-11-01 2012-05-29 Cisco Technology, Inc. Method for protecting against denial of service attacks
US9432433B2 (en) * 2006-06-09 2016-08-30 Qualcomm Incorporated Enhanced block-request streaming system using signaling or block creation
CN101523379A (zh) * 2006-08-18 2009-09-02 阿卡麦科技公司 分布式网络中的数据收集方法
GB0621433D0 (en) * 2006-10-27 2006-12-06 3G Scene Ltd Networking application
CN101743717B (zh) * 2007-04-23 2014-06-18 诺基亚公司 用于优化去往漫游客户的下载用户服务递送的系统和方法
JP2009140290A (ja) * 2007-12-07 2009-06-25 Fujitsu Ltd コンテンツ中継装置、コンテンツ中継システム及びコンテンツ中継方法並びにプログラム
US8667175B2 (en) * 2008-03-13 2014-03-04 Cisco Technology, Inc. Server selection for routing content to a client using application layer redirection
EP2173078A1 (en) * 2008-10-01 2010-04-07 Thomson Licensing Network device and method for setting up an IPTV session
JP2010093576A (ja) * 2008-10-08 2010-04-22 Sony Corp 受信装置、受信方法およびコンピュータプログラム
US8849988B2 (en) * 2008-11-25 2014-09-30 Citrix Systems, Inc. Systems and methods to monitor an access gateway
US8214515B2 (en) * 2009-06-01 2012-07-03 Trion Worlds, Inc. Web client data conversion for synthetic environment interaction
US8681668B2 (en) * 2009-10-09 2014-03-25 Media Patents, S.L. Methods and apparatus for transmitting multicast traffic in a data network
US8117322B1 (en) * 2009-12-10 2012-02-14 Google Inc. Latency reduction on HTTP servers
US8539102B2 (en) * 2010-06-21 2013-09-17 Comcast Cable Communications, Llc Downloading a code image to remote devices
US8880707B2 (en) * 2010-09-17 2014-11-04 Deutsche Telekom Ag Heterogeneous network access on devices with one or more network interfaces
US9510061B2 (en) * 2010-12-03 2016-11-29 Arris Enterprises, Inc. Method and apparatus for distributing video
EP2536175B1 (en) * 2011-06-14 2014-08-13 Telefonaktiebolaget L M Ericsson (publ) Method, apparatus and computer program for a network node including a PCEF for establishing a user plane session
US9380079B2 (en) * 2011-06-29 2016-06-28 Cable Television Laboratories, Inc. Content multicasting
US8924581B1 (en) * 2012-03-14 2014-12-30 Amazon Technologies, Inc. Managing data transfer using streaming protocols
US9537920B2 (en) * 2012-05-18 2017-01-03 Google Technology Holdings LLC Enforcement of trick-play disablement in adaptive bit rate video content delivery
US9215131B2 (en) * 2012-06-29 2015-12-15 Cisco Technology, Inc. Methods for exchanging network management messages using UDP over HTTP protocol
KR102110627B1 (ko) * 2012-07-05 2020-05-13 구글 테크놀로지 홀딩스 엘엘씨 적응적 비트레이트 스트리밍에서 대역폭 할당을 위한 방법들 및 디바이스들
JP6461791B2 (ja) * 2012-08-07 2019-01-30 フィリップス ライティング ホールディング ビー ヴィ 時限照明制御
US9438488B2 (en) * 2012-11-09 2016-09-06 Citrix Systems, Inc. Systems and methods for appflow for datastream
EP2984796B1 (en) * 2013-04-12 2020-09-23 Nec Corporation Method and system for providing an information centric network with a software defined network
US20150046568A1 (en) * 2013-08-11 2015-02-12 Imvision Software Technologies Ltd. Method and system for playing multicast over-the-top (ott) content streams
IL309988A (en) * 2021-07-26 2024-03-01 Bright Data Ltd Emulation of a web browser in a dedicated relay unit

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050262251A1 (en) * 2004-05-03 2005-11-24 Microsoft Corporation Fast startup for streaming media
US20080086523A1 (en) * 2006-08-18 2008-04-10 Akamai Technologies, Inc. Method of data collection in a distributed network
WO2010132462A2 (en) * 2009-05-14 2010-11-18 Microsoft Corporation Http-based authentication
US20110231569A1 (en) * 2009-09-22 2011-09-22 Qualcomm Incorporated Enhanced block-request streaming using block partitioning or request controls for improved client-side handling

Also Published As

Publication number Publication date
US20200021672A1 (en) 2020-01-16
EP2888857B1 (en) 2021-11-10
US20220038558A1 (en) 2022-02-03
KR20150048179A (ko) 2015-05-06
US10425507B2 (en) 2019-09-24
CN104662865A (zh) 2015-05-27
JP2016500205A (ja) 2016-01-07
US11924311B2 (en) 2024-03-05
EP2888857A1 (en) 2015-07-01
WO2014032036A1 (en) 2014-02-27
JP6278531B2 (ja) 2018-02-14
US20170223149A1 (en) 2017-08-03
US11153417B2 (en) 2021-10-19
EP2888857A4 (en) 2016-05-04
US9628542B2 (en) 2017-04-18
US20140059168A1 (en) 2014-02-27
CN104662865B (zh) 2018-06-08

Similar Documents

Publication Publication Date Title
US11924311B2 (en) Hybrid HTTP and UDP content delivery
US11088940B2 (en) Cooperative multipath
EP2897340B1 (en) Routing proxy for adaptive streaming
US11477262B2 (en) Requesting multiple chunks from a network node on the basis of a single request message
KR102123933B1 (ko) 비동기식 데이터 딕셔너리들을 이용하는 멀티-테넌트 공유 인프라구조에서의 스트림-기반 데이터 중복 제거
KR102110421B1 (ko) 클라이언트 장치에 시청각 컨텐츠를 전달하는 시스템 및 방법
KR102506107B1 (ko) 오디오-비주얼 라이브 콘텐츠 전달을 위한 방법 및 시스템
US9918349B2 (en) Proxy node and method
CN111567011B (zh) 使用跨层信息提高视频服务和WEB服务的QoE的方法
CN107113332B (zh) 用于分发媒体流的装置、方法和计算机可读介质
EP4264950A1 (en) Multisource media delivery systems and methods

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