KR20220024697A - 네트워크 트래픽 관리의 개선을 위한 패킷 확인 응답 기술 - Google Patents

네트워크 트래픽 관리의 개선을 위한 패킷 확인 응답 기술 Download PDF

Info

Publication number
KR20220024697A
KR20220024697A KR1020227001799A KR20227001799A KR20220024697A KR 20220024697 A KR20220024697 A KR 20220024697A KR 1020227001799 A KR1020227001799 A KR 1020227001799A KR 20227001799 A KR20227001799 A KR 20227001799A KR 20220024697 A KR20220024697 A KR 20220024697A
Authority
KR
South Korea
Prior art keywords
packet
proxy server
receiving device
packets
acknowledgment
Prior art date
Application number
KR1020227001799A
Other languages
English (en)
Other versions
KR102654182B1 (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 KR20220024697A publication Critical patent/KR20220024697A/ko
Application granted granted Critical
Publication of KR102654182B1 publication Critical patent/KR102654182B1/ko

Links

Images

Classifications

    • H04L67/2809
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • H04L67/562Brokering proxy services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46Interconnection of networks
    • H04L12/4633Interconnection of networks using encapsulation techniques, e.g. tunneling
    • H04L67/2814
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • H04L67/563Data redirection of data network streams
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22Parsing or analysis of headers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/40Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

프록시 서버(700)는 송신 장치로부터 수신 장치(600)를 위해 의도된 패킷을 수신한다. 프록시 서버(700)는 프록시 서버(700)가 패킷을 나중에 수신 장치(600)로 전달할 것임을 나타내는 약속 프레임(300)을 수신 장치(600)로 송신한다. 수신 장치(600)는 프록시 서버(700)로부터 약속 프레임(300)을 수신하고, 패킷의 확인 응답을 프록시 서버(700)를 통해 송신 장치로 송신한다. 프록시 서버(700)는 수신 장치(600)로부터의 패킷의 확인 응답을 송신 장치로 포워딩하고, 확인 응답을 송신 장치로 포워딩한 후 패킷을 수신 장치(600)로 전달한다. 수신 장치(600)는 패킷의 확인 응답을 프록시 서버(700)를 통해 송신 장치로 송신한 후 프록시 서버(700)로부터 패킷을 수신한다.

Description

네트워크 트래픽 관리의 개선을 위한 패킷 확인 응답 기술
본 출원은 일반적으로 통신 네트워크 상의 패킷 트래픽 관리에 관한 것으로서, 특히 프록시 서버(proxy server)를 포함하는 패킷 확인 응답 기술(packet acknowledgement technique)에 관한 것이다.
QUIC(Quick User Datagram Protocol (UDP) Internet Connections)는 무결성 보호 헤더와 암호화된 페이로드가 있는 UDP 기반의 스트림 다중화된 보안 전송 프로토콜(UDP-based, stream-multiplexed, secure transport protocol)이다. 운영 체제 커널(operating system kernel)에 상주하는 TCP(Transmission Control Protocol)를 사용하는 기존의 전송 프로토콜 스택과 달리, QUIC는 애플리케이션 계층에서 쉽게 구현될 수 있다. 이는 새로운 특징(features)의 진화(evolution), 혼잡 제어 및 구현의 측면에서 많은 유연성을 가져온다. QUIC는 IETF(Internet Engineering Task Force)에서 진행 중이다.
QUIC는 사용자 평면에서 주요 전송 프로토콜이 될 가능성이 있는 후보(candidate)이다. (오늘날 주로 HTTP/HTTPS를 통해 실행되는) 대부분의 웹 애플리케이션은 QUIC로 마이그레이션(migration)될 것으로 예상된다.
QUIC와 TCP의 중요한 차이점은 QUIC가 암호화된 프로토콜이라는 것이다. TCP 위에서 실행되는 프로토콜은 일반적으로 TLS(Transport Layer Security) 프로토콜에 의해 보호된다. TLS가 페이로드를 보호하지만, TCP 헤더는 노출된 상태로 유지된다. 반면, QUIC는 페이로드와 패킷 헤더를 모두 보호한다.
QUIC 패킷은 2개의 별개의 키를 사용하여 보호되며, 하나는 패킷 헤더를 보호하기 위한 것이고, 다른 하나는 패킷 페이로드를 보호하기 위한 것이다. 또한, QUIC 패킷 헤더는 TCP보다 적은 필드로 구성된다. 대신에, QUIC는 확인 응답과 같은 전송 관련 정보를 위해 보호된 패킷 페이로드의 일부인 프레임을 사용한다.
QUIC는 상이한 IP 주소와 포트 간의 연결의 마이그레이션을 허용한다. 이러한 마이그레이션은 암시적으로(예를 들어, NAT(Network Address Translation) 상태의 재바인딩(rebinding)으로 인해) 또는 명시적으로(예를 들어, 클라이언트가 사용 가능하게 되면 별개의 액세스 네트워크를 사용하기로 결정하기 때문에) 발생할 수 있다.
혼잡 제어(congestion control)는 TCP 또는 QUIC와 같은 안정적인 전송 프로토콜의 중요한 구성 요소이다. 혼잡 제어의 목적은 네트워크가 혼잡해지는 것을 방지하고, 혼잡이 발생할 경우, 사용 가능한 대역폭을 활용하면서 네트워크가 혼잡한 상태를 유지하는 것을 방지하는 것이다. 혼잡 제어 알고리즘은 일반적으로 송신자에서만 구현되며, 어떠한 특정 프로토콜 지원을 필요로 하지 않는다. 송신자측과 수신자측 모두를 지원할 필요가 있는 알고리즘이 있지만, 이러한 알고리즘은 인터넷에 널리 배포(deploy)되지 않는다. 많은 혼잡 제어 알고리즘은 혼잡을 추론하는 데 사용하는 신호의 타입, 혼잡에 응답하는 방법 및 대역폭을 검색하는 방법에 따라 구별된다.
전형적인 혼잡 제어 알고리즘은 손실 기반(loss-based)이다. 즉, 이러한 알고리즘은 패킷 손실을 혼잡 지표(congestion indicator)로서 사용하며, 일반적으로 혼잡 응답으로서 AIMD(Additive Increase Multipliable Decrease) 모델을 구현한다. AIMD 기반 혼잡 제어 응답은 혼잡 이벤트가 검출될 때까지 CWIN(Congestion Window)을 선형적으로 증가시키며, 이 시점에서 이는 승수 요소만큼 CWIN을 감소시킨다. 가장 일반적인 AIMD 알고리즘은 (New) Reno이다. 다른 일반적인 손실 기반 혼잡 제어 알고리즘은 가장 최근의 손실 이벤트의 윈도우 크기 주변에 변곡점이 있는 3차 함수로서 CWIN을 증가시키는 CUBIC이다.
다른 알고리즘은 송신률(sending rate)과 혼잡 응답을 제어하기 위해 지연 및/또는 비트레이트(bitrate) 측정을 혼잡의 지표로서 함께 사용한다. 이러한 알고리즘은 지연 측정이 일반적으로 패킷 손실보다 더 일반적으로 사용 가능하기 때문에 네트워크 혼잡을 완화하는 데 보다 능동적인 경향이 있으며, 혼잡 이외의 이유로 (예를 들어, 무선 환경의 채널 손상(channel corruption)으로 인해) 패킷 손실이 발생하는 네트워크에서도 더 잘 작동한다.
프록시(proxy)는 다른 장치(예를 들어, 송신 장치 및/또는 수신 장치와 같은 하나 이상의 통신 엔드포인트(endpoint))를 대신하여 네트워크 트래픽을 처리하는 중개 프로그램 또는 네트워크 장치이다. 클라이언트와 서버 엔드포인트 사이의 통신에서, 프록시는 예를 들어 엔드포인트 중 하나 또는 둘 다를 대신하여 요청하기 위해 클라이언트 엔드포인트에 대한 서버 및/또는 서버 엔드포인트에 대한 클라이언트의 역할을 할 수 있다. 요청은 내부적으로 처리되거나 번역과 함께 다른 서버로 전달하여 처리될 수 있다. 더욱이, 프록시는 혼잡 제어 및/또는 다른 유익한 서비스를 제공하는 데 사용될 수 있다.
"투명 프록시(transparent proxy)"는 프록시 인증 및 식별에 필요한 것 이상으로 요청 또는 응답을 수정하지 않는 프록시이다.
"비투명 프록시(non-transparent proxy)"는 그룹 주석 서비스(group annotation service), 미디어 타입 변환, 프로토콜 감소(protocol reduction) 및/또는 익명 필터링(anonymity filtering)과 같은 일부 부가된 서비스를 사용자 에이전트(user agent)에 제공하기 위한 요청 또는 응답을 수정하는 프록시이다.
"역방향 프록시(reverse proxy)"는 기본적으로 실제 서버인 것처럼 가장하는 프록시이지만(클라이언트 또는 클라이언트 프록시에 관한 한), 일반적으로 방화벽 계층 뒤에 있는 실제 서버로 요청을 전달한다.
"PEP(Performance Enhancement Proxy)”는 경로상의 링크 또는 서브네트워크의 특성으로 인해 기본 성능이 저하되는 네트워크 경로 상에서 프로토콜의 성능을 개선하는 데 사용된다.
상술한 바의 관점에서 볼 때, 프록시는 예를 들어 통신 엔드포인트 간의 혼잡 제어를 강화함으로써 네트워크에서 중요한 역할을 할 수 있음이 명백하다. 이러한 프록시를 구현하기 위한 많은 솔루션은 통신이 TCP를 기반으로 할 때 잘 이해되지만, 이러한 프록시는 TCP와 QUIC 프로토콜 간의 차이를 고려할 때 통신이 QUIC를 기반으로 하는 경우 동일하거나 유사한 이점을 제공하지 못할 수 있다. 따라서, QUIC를 포함하는 네트워크 통신을 위한 새로운 기술이 필요할 수 있다.
본 개시의 실시예는 일반적으로 패킷이 실제로 전달되기 전에 패킷을 전달한다는 약속(promise)에 기초하여 패킷을 확인 응답하는 것에 관한 것이다. 이러한 실시예는 다양한 상이한 프로토콜을 사용하여 엔드포인트 간의 통신을 위해 혼잡 제어가 수행될 수 있게 할 수 있다. 특히, 프록시는 수신된 패킷을 버퍼링하고, 해당 패킷을 나중에 전달하기로 약속하는 수신 장치로 약속 프레임을 송신하며, 응답 시 즉, 패킷을 실제로 수신하기 전에 수신 장치로부터 패킷의 확인 응답을 수신할 수 있다. 이러한 확인 응답은 패킷의 송신자로 포워딩(forwarding)될 수 있으며, 이는 예를 들어 프록시가 혼잡 제어를 위해서나 다른 네트워크 관리 관련 이유로 패킷을 보유하고 있을지라도 패킷이 전달된 것처럼 패킷을 계속 송신할 수 있다.
따라서, 본 개시의 실시예는 수신 장치에 의해 구현되는 방법을 포함한다. 방법은 프록시 서버가 나중에 송신 장치로부터 수신 장치로 패킷을 전달할 것임을 나타내는 약속 프레임을 프록시 서버로부터 수신하는 단계를 포함한다. 방법은 프록시 서버를 통해 패킷의 확인 응답을 송신 장치로 송신하는 단계를 더 포함한다. 방법은 프록시 서버를 통해 패킷의 확인 응답을 송신 장치로 송신한 후에 프록시 서버로부터 패킷을 수신하는 단계를 더 포함한다.
일부 실시예에서, 방법은, 프록시 서버로부터, 송신 장치 및 약속 프레임에 의해 송신된 추가의 패킷을 포함하는 제1 캡슐화 패킷을 수신하는 단계를 더 포함한다. 프록시 서버로부터 약속 프레임을 수신하는 단계는 제1 캡슐화 패킷 내에서 약속 프레임을 수신하는 단계를 포함한다. 이러한 일부 실시예에서, 패킷의 확인 응답을 송신하는 단계는 제2 캡슐화 패킷으로 패킷의 확인 응답을 송신하는 단계를 포함하고, 제2 캡슐화 패킷은 제1 캡슐화 패킷의 확인 응답을 더 포함하고, 패킷의 확인 응답은 또한 추가의 패킷을 확인 응답한다.
일부 실시예에서, 방법은 약속 프레임에서 패킷의 패킷 수(packet number)를 수신하는 단계를 더 포함한다. 패킷 수는 프록시 서버가 패킷을 나중에 수신 장치로 전달할 것임을 나타낸다. 이러한 일부 실시예에서, 방법은, 약속 프레임에서, 프록시 서버가 나중에 수신 장치로 전달할 것을 약속하는 프록시 서버에 의해 수신된 부가적인 패킷에 상응하는 하나 이상의 부가적인 패킷 수의 인디케이션(indication)을 수신하는 단계를 더 포함한다. 하나 이상의 부가적인 패킷 수의 인디케이션은 패킷 바로 앞에 얼마나 많은 인접한 패킷이 부가적인 패킷에 포함되고, 약속 프레임에 따라 나중에 수신 장치로 전달될 것으로 약속되는지를 명시하는 수를 포함한다. 이러한 일부 실시예에서, 방법은, 약속 프레임에서, 프록시 서버에 의해 송신 장치로부터 수신되지 않은 다른 패킷에 상응하고, 약속 프레임에 따라, 수신 장치로의 다른 패킷의 전달이 프록시 서버에 의해 약속되지 않음을 나타내는 하나 이상의 다른 패킷 수의 추가의 인디케이션을 수신하는 단계를 더 포함한다. 이러한 일부 실시예에서, 다른 패킷은 연속적이며, 패킷 바로 앞의 인접한 패킷 바로 앞에 있으며, 하나 이상의 부가적인 패킷 수의 인디케이션은 다른 패킷 바로 앞에 얼마나 많은 인접한 패킷이 부가적인 패킷에 포함되고, 약속 프레임에 따라, 프록시 서버에 의해 나중에 수신 장치(600)로 전달될 것으로 약속되는지를 명시하는 추가의 수를 더 포함한다.
일부 실시예에서, 약속 프레임은 얼마나 많은 패킷 범위가 약속 프레임에 의해 나타내어지는지를 나타내는 범위 카운트 필드(range count field)를 포함한다.
일부 실시예에서, 방법은, 약속 프레임에서, 프록시 서버가 패킷을 나중에 수신 장치로 전달할 것임을 나타내기 위해 패킷의 패킷 수를 인코딩하는 패킷의 암호화된 부분을 수신하는 단계를 더 포함한다. 방법은 프록시 서버가 나중에 수신 장치로 전달할 패킷을 식별하기 위해 약속 프레임에 포함된 패킷의 암호화된 부분을 해독하는 단계를 더 포함한다. 이러한 일부 실시예에서, 방법은, 약속 프레임에서, 얼마나 많은 패킷이 약속 프레임에 따라 나중에 수신 장치로 전달되는 것으로 약속되는지를 나타내는 패킷 카운트를 수신하는 단계를 더 포함한다.
다른 실시예는 프록시 서버에 의해 구현되는 방법에 관한 것이다. 방법은 송신 장치로부터 수신 장치를 위해 의도된 패킷을 수신하는 단계를 포함한다. 방법은 프록시 서버가 패킷을 나중에 수신 장치로 전달할 것임을 나타내는 약속 프레임을 수신 장치로 송신하는 단계를 더 포함한다. 방법은 수신 장치로부터 송신 장치로 패킷의 확인 응답을 포워딩하는 단계를 더 포함한다. 방법은 확인 응답을 송신 장치로 포워딩한 후에 패킷을 수신 장치로 전달하는 단계를 더 포함한다.
일부 실시예에서, 방법은 수신 장치를 위해 의도된 추가의 패킷을 수신하는 단계, 및 추가의 패킷 및 약속 프레임을 포함하는 제1 캡슐화 패킷을 수신 장치로 송신하는 단계를 더 포함한다. 약속 프레임을 수신 장치로 송신하는 단계는 제1 캡슐화 패킷 내에서 약속 프레임을 송신하는 단계를 포함한다. 이러한 일부 실시예에서, 패킷의 확인 응답을 포워딩하는 단계는 수신 장치로부터 패킷의 확인 응답 및 나머지 부분을 포함하는 제2 캡슐화 패킷을 수신하는 단계를 포함한다. 나머지 부분은 제1 캡슐화 패킷의 확인 응답을 포함한다. 패킷의 확인 응답을 포워딩하는 단계는 패킷의 확인 응답을 나머지 부분 없이 송신 장치로 송신하는 단계를 더 포함한다. 패킷의 확인 응답은 또한 추가의 패킷을 확인 응답한다.
일부 실시예에서, 방법은 프록시 서버가 패킷을 나중에 수신 장치로 전달할 것임을 나타내기 위해 약속 프레임에 패킷의 패킷 수를 포함하는 단계를 더 포함한다. 이러한 일부 실시예에서, 방법은 프록시 서버가 부가적인 패킷을 나중에 수신 장치로 전달할 것을 나타내기 위해 송신 장치로부터 수신된 부가적인 패킷에 상응하는 하나 이상의 부가적인 패킷 수의 인디케이션을 약속 프레임에 포함하는 단계를 더 포함한다. 하나 이상의 부가적인 패킷 수의 인디케이션은 패킷 바로 앞에 얼마나 많은 인접한 패킷이 부가적인 패킷에 포함되고, 약속 프레임에 따라 나중에 수신 장치로 전달될 것으로 약속되는지를 명시하는 수를 포함한다. 이러한 일부 실시예에서, 방법은, 약속 프레임에 따라, 프록시 서버가 수신 장치로의 다른 패킷의 전달을 약속하지 않음을 나타내기 위해 송신 장치로부터 수신되지 않은 다른 패킷에 상응하는 하나 이상의 다른 패킷 수의 추가의 인디케이션을 약속 프레임에 포함하는 단계를 더 포함한다. 이러한 일부 실시예에서, 다른 패킷은 연속적이며, 패킷 바로 앞의 인접한 패킷 바로 앞에 있다. 하나 이상의 부가적인 패킷 수의 인디케이션은 다른 패킷 바로 앞에 얼마나 많은 인접한 패킷이 부가적인 패킷에 포함되고, 약속 프레임에 따라, 나중에 수신 장치로 전달될 것으로 약속되는지를 명시하는 추가의 수를 더 포함한다.
일부 실시예에서, 방법은 약속 프레임이 얼마나 많은 패킷 범위가 약속 프레임에 의해 나타내어지는지를 나타내는 범위 카운트 필드를 포함하는 것을 더 포함한다.
일부 실시예에서, 방법은 프록시 서버가 패킷을 나중에 수신 장치로 전달할 것임을 나타내기 위해 패킷의 패킷 수를 인코딩하는 패킷의 암호화된 부분을 약속 프레임에 포함하는 단계를 더 포함한다. 이러한 일부 실시예에서, 방법은 얼마나 많은 패킷이 약속 프레임에 따라 나중에 수신 장치로 전달되는 것으로 약속되는지를 나타내는 패킷 카운트를 약속 프레임에 포함하는 단계를 더 포함한다.
다른 실시예는 상응하는 장치를 포함한다. 하나 이상의 이러한 실시예는 프록시 서버가 나중에 송신 장치로부터 수신 장치로 패킷을 전달할 것임을 나타내는 약속 프레임을 프록시 서버로부터 수신하고, 패킷의 확인 응답을 프록시 서버를 통해 송신 장치로 송신하도록 구성된 수신 장치를 포함한다. 수신 장치는 또한 패킷의 확인 응답을 프록시 서버를 통해 송신 장치로 송신한 후 프록시 서버로부터 패킷을 수신하도록 더 구성된다.
일부 실시예에서, 수신 장치는 수신 장치에 대해 상술한 방법 중 임의의 것을 수행하도록 더 구성된다.
일부 실시예에서, 수신 장치는 처리 회로 및 처리 회로에 통신 가능하게 결합된 인터페이스 회로를 포함하며, 처리 회로는 수신 장치에 대해 상술한 방법 중 임의의 것을 수행하도록 구성된다.
또 다른 실시예는 송신 장치로부터 수신 장치를 위해 의도된 패킷을 수신하고, 프록시 서버가 패킷을 나중에 수신 장치로 전달할 것임을 나타내는 약속 프레임을 수신 장치로 송신하도록 구성된 프록시 서버를 포함한다. 프록시 서버는 수신 장치로부터 송신 장치로 패킷의 확인 응답을 포워딩하고, 확인 응답을 송신 장치로 포워딩한 후 패킷을 수신 장치로 전달하도록 더 구성된다.
일부 실시예에서, 프록시 서버는 프록시 서버에 대해 상술한 방법 중 임의의 것을 수행하도록 더 구성된다.
일부 실시예에서, 프록시 서버는 처리 회로 및 처리 회로에 통신 가능하게 결합된 인터페이스 회로를 포함하고, 처리 회로는 프록시 서버에 대해 상술한 방법 중 임의의 것을 수행하도록 구성된다.
다른 실시예는 상응하는 시스템, 컴퓨터 프로그램, 및 캐리어(carrier)를 포함한다.
특정 실시예가 아래에서 설명되었지만, 이러한 일부 실시예가 어떤 경우에 아래에서 더 설명되는 바와 같이 아래에서 설명되는 하나 이상의 특징을 포함할 수 있다는 것이 주목되어야 한다.
본 개시의 양태는 예로서 예시되고, 유사한 요소를 나타내는 유사한 참조 부호를 갖는 첨부된 도면에 의해 제한되지 않는다. 일반적으로, 참조 수의 사용은 하나 이상의 실시예에 따라 묘사된 주제(subject matter)를 참조하는 것으로서 간주되어야 하는 반면, 도시된 요소의 특정 사례에 대한 논의는 거기에 문자 명시(예를 들어, 일반적으로 연결(140a, 140b)의 특정 사례에 대한 논의와 대조적인 바와 같은 연결(140)에 대한 논의)를 첨부할 것이다.
도 1은 본 개시의 하나 이상의 실시예에 따라 클라이언트, 서버와 프록시 사이의 TCP 통신의 예를 도시하는 개략적인 블록도이다.
도 2는 본 개시의 하나 이상의 실시예에 따라 클라이언트, 서버와 프록시 사이에서 교환되는 메시지의 예를 도시하는 시그널링 다이어그램이다.
도 3은 본 개시의 하나 이상의 실시예에 따라 클라이언트, 서버와 프록시 사이의 QUIC 통신의 예를 도시하는 개략적인 블록도이다.
도 4 및 도 5는 본 개시의 하나 이상의 실시예에 따라 클라이언트, 서버와 프록시 사이에서 교환되는 메시지의 예를 도시하는 시그널링 다이어그램이다.
도 6 내지 도 8은 본 개시의 실시예에 따른 예시적인 프레임 구조를 도시하는 개략적인 블록도이다.
도 9 및 10은 본 개시의 실시예에 따른 예시적인 방법을 도시하는 흐름도이다.
도 11은 본 개시의 하나 이상의 실시예에 따른 예시적인 수신 장치를 도시하는 개략적인 블록도이다.
도 12는 본 개시의 하나 이상의 실시예에 따른 예시적인 프록시 서버를 도시하는 개략적인 블록도이다.
TCP 기반 PEP는 일반적으로 RAN(Radio Access Network)과 같은 액세스 네트워크의 역학에 맞게 조정되는 트래픽을 가속화하고 혼잡 제어를 수행하기 위해 셀룰러 네트워크에 배치(deploy)된다. 이는 통상적으로 종단 간(end-to-end) TCP 연결을 두 개의 별개의 연결, 하나는 서버와 프록시 사이의 연결이고, 다른 하나는 프록시와 클라이언트 사이의 연결로 분할함으로써 작동한다. 이러한 방식으로, 두 개의 별개의 제어 루프가 설정되고, 프록시는 각각의 제어 루프에서 적절한 혼잡 제어를 수행하기 위해 얼마나 많은 데이터가 확인 응답되고/되거나 버퍼링될 필요가 있는지를 조절할 수 있다. TCP 헤더와 페이로드가 일반적으로 난독화되지 않고, 보안(예를 들어, 무결성 보호)이 프로토콜에 내장되어 있지 않다는 점을 감안할 때, TCP 프록시는 일반적으로 통신 엔드포인트 중 하나로부터 명시적 구성 또는 동의를 필요로 하지 않는다.
도 1은 단일 연결일 수 있는 것을 2개의 별개의 연결(140a, 140b)로 나누는 통상적인 TCP 프록시(110)의 예를 도시하며, 이의 각각은 자체 혼잡 제어 루프를 갖는다. TCP 프록시(110)는 애플리케이션 계층 데이터를 하나의 연결(140b)에서 다른 연결(140a)로(일부 실시예에서는 그 반대로) 포워딩한다. 통신 엔트포인트(즉, 이 예에서 TCP 클라이언트(120) 및 TCP 서버(130))는 TCP 프록시(110)에 대한 명시적 지식을 필요로 하지 않는다.
도 2는 TCP 프록시(110), TCP 클라이언트(120) 및 TCP 서버(130) 사이의 예시적인 메시징을 도시한다. 도 2에 도시된 바와 같이, TCP 프록시(110)는 서버로부터 수신된 패킷 P1-P4에 대한 확인 응답 ACK2, ACK4를 송신할 수 있고, 클라이언트로 포워딩된 패킷 P1-P4에 대한 확인 응답 ACK2, ACK4를 수신할 수 있다. 도시되지 않았지만, TCP 프록시(110)는 부가적 또는 대안적으로 TCP 클라이언트(120)로부터 수신된 패킷에 대한 확인 응답을 송신할 수 있고, TCP 서버(130)로 포워딩된 패킷에 대한 확인 응답을 수신할 수 있다. 또한, TCP 프록시(110)는 수신하는 패킷의 송신률을 조절할 수 있고, 패킷이 포워딩되는 구간에서 혼잡 제어를 수행하기에 충분한 데이터가 버퍼링됨을 보장할 수 있다. 따라서, 혼잡 제어는 연결(140a 및 140b) 중 하나 또는 둘 다에 대해 개별적으로 수행될 수 있다.
도 2에 도시된 특정 예에서, TCP 프록시(110)는 특정 송신률로 TCP 서버(130)로부터 패킷을 수신하고, TCP 프록시(110)가 패킷을 TCP 클라이언트(120)로 패킷이 수신된 것보다 더 천천히 포워딩할 수 있도록 수신된 패킷을 버퍼에 저장한다. 다른 실시예(도시되지 않음)에서, TCP 프록시(110)는 이전에 수신된 패킷의 버퍼를 사용하여 패킷이 수신된 것보다 더 빠르게(즉, 버퍼에 패킷이 부족하지 않은 한) 패킷을 포워딩할 수 있다. 이전에 논의된 바와 같이, 일부 실시예에서, TCP 프록시(110)는 TCP 클라이언트(120)로부터 시작되고 TCP 서버(130)로 향하는 패킷에 대해 유사한 기능을 수행할 수 있다.
QUIC에는 인증 및 암호화와 같은 보안이 내장되어 있기 때문에, QUIC 프록시(위에서 논의된 TCP 프록시(110)와 대조적임)는 일반적으로 통신 엔드포인트 중 적어도 하나로부터의 명시적 구성 및 동의를 필요로 한다. QUIC 포워딩 프록시의 전형적인 실시예에는 여러 보안 컨텍스트(context)가 있으며, 즉, 하나의 "내부" 컨텍스트(이는 클라이언트와 서버 간에 종단 간 보호를 제공함)와 적어도 하나의 "외부" 컨텍스트(이는 엔드포인트와 프록시 간의 통신을 보호함)가 있다.
도 3에 도시된 바와 같이, 공통 QUIC 프록시 배치(deployment)가 QUIC 클라이언트(220)와 QUIC 프록시(210) 사이에 설정된 연결(140d)을 위한 하나의 외부 보안 컨텍스트를 가질 것이지만, QUIC 프록시(220)와 QUIC 서버(230) 사이에는 이러한 외부 보안 컨텍스트가 없다. 대신, 종단간 연결(140c)의 QUIC 패킷은 연결(140d)을 통해 QUIC 클라이언트(220)와 QUIC 프록시(210) 사이에서 터널링(tunneling)되고, QUIC 프록시(210)와 QUIC 서버(230) 사이에서 UDP 데이터그램을 사용한다. 이러한 배치에서, 종단간 연결(140c)은 상술한 바와 같이 2개의 별개의 연결(140a, 140b)로 분할되지 않고, 종단간 혼잡 제어 루프는 QUIC 서버(230)와 QUIC 클라이언트(220) 사이에서 발생할 수 있다.
그럼에도 불구하고, QUIC 프록시(210)와 QUIC 클라이언트(220) 사이의 외부 보안 컨텍스트는 또한 QUIC 프록시(210)가 QUIC 서버(230)의 송신 동작에 영향을 미칠 기회를 갖지 않고 혼잡 제어될 수 있다. 이러한 일부 실시예에서, 이것은 종단간 혼잡 제어 루프와 프록시 대 클라이언트 제어 루프 간의 최적이 아닌 성능 및 상호 작용으로 이어질 수 있다. QUIC 프록시(210)는 자신의 외부 보안 컨텍스트를 갖는 외부 QUIC 연결(140d)에서 종단 간 연결(140c)의 일부를 캡슐화하기 때문에, QUIC 프록시(210)는 QUIC 서버(230)로부터 수신된 데이터를 직접 확인 응답할 기회를 갖지 않는다. 대신에, 도 4에 도시된 바와 같이, QUIC 프록시(210)는 클라이언트로부터의 확인 응답을 기다리고, 이에 응답하여 상응하는 확인 응답을 서버로 송신한다.
도 4는 QUIC 클라이언트(220)와 QUIC 프록시(210) 사이의 외부 연결(140d)에서 종단간 QUIC 연결(140c)의 일부를 캡슐화하는 QUIC 프록시(210)의 특정 예를 도시한다. (예를 들어, 위에서 논의된 바와 같이) TCP PEP와 비교되는 바와 같은 이러한 타입의 프록시에서 중요한 차이점은 종단 간 연결(140c)이 분할되지 않기 때문에 프록시가 QUIC 서버(230)로부터 수신된 패킷을 직접 확인 응답할 기회를 갖지 못하며, 2개의 혼잡 제어 루프가 QUIC 클라이언트(220)와 QUIC 프록시(210) 사이에 계층화되어 잠재적으로 최적이 아닌 상호 작용으로 이어진다는 것이다.
본 개시의 특정 실시예가 QUIC 프로토콜에 대해 구체적으로 그려질지라도, 다른 실시예는 유사한 발명의 개념을 사용하는 다른 프로토콜, 프록시, 엔드포인트, 및/또는 장치에 마찬가지로 용이하게 적용될 수 있다는 것이 주목되어야 한다. 따라서, 아래에서 논의되는 임의의 특정 프록시, 엔드포인트 또는 시그널링이 QUIC 프로토콜을 지원하는 것이 필수적이라고 간주되지 않아야 한다. 즉, 본 명세서에 설명된 특정 실시예는 QUIC 프로토콜이 사용되는 환경에 특히 적합할 수 있다.
위의 관점에서, 본 개시의 하나 이상의 실시예는 하나 이상의 다른 통신 피어(peer)로부터 수신한 패킷에 대해 피어에게 통지하고, 이러한 패킷을 안정적으로 전달할 것을 약속하는 QUIC 프록시(210)에 관한 것이다. 이러한 정보를 수신하면, 피어는 다른 통신 피어를 향한 이러한 패킷의 수신을 즉시 확인 응답하여, 송신자가 CWIN을 더 빨리 열 수 있도록 한다. 이것은 결과적으로 프록시가 데이터를 버퍼링하고 혼잡 제어 루프를 관리할 수 있도록 하여, 좋지 않은 혼잡 제어 루프 상호 작용의 위험을 줄이고 종단 간 통신 피어 간의 데이터 전송의 진행을 여전히 허용한다.
특히, 본 개시의 실시예는 QUIC 프록시(210)를 통해 하나 이상의 QUIC 서버(230)를 향해 하나 이상의 QUIC 연결(140c)을 설정하는 QUIC 클라이언트(220)를 포함한다. QUIC 클라이언트(220)와 QUIC 프록시(210) 사이에서, 하나 이상의 종단간 QUIC 연결(140c)은 단일 QUIC 연결(140d)에 캡슐화된다. 즉, QUIC 클라이언트(220) 및 QUIC 프록시(210)는 QUIC 서버(230)로부터 전송된 데이터가 QUIC 클라이언트(220)를 향해 전달되기 전에 QUIC 프록시(210)에 의해 캡슐화되도록 캡슐화하는 QUIC 연결(140d)의 엔드포인트이다. QUIC 프록시(210)가 QUIC 클라이언트(220)를 향해 송신하는 것보다 더 높은 속도로 QUIC 프록시(210)가 QUIC 서버(230)로부터 데이터를 수신할 때, QUIC 프록시(210)는 수신하고 전달하기로 약속한 패킷에 관한 정보를 QUIC 클라이언트(220)로 송신한다. QUIC 프록시(210)가 전달하기로 약속한 QUIC 프록시(210)에 의해 수신된 패킷에 관한 이러한 정보를 수신하는 것에 응답하여, QUIC 클라이언트(220)는 관련 내부 QUIC 연결(140c)에 대한 상응하는 QUIC 확인 응답을 QUIC 서버(230)로 송신한다.
이러한 실시예는 QUIC 프록시가 적절하게 구성된 단일 연결 엔드포인트에 의해 지원되는 PEP 기능을 수행할 수 있게 할 수 있다. 상술한 예에서, QUIC 프록시(210)는 내부 계층의 서버측 혼잡 제어와의 최적인 아닌 상호 작용을 줄이면서 QUIC 클라이언트를 지원하는 특정 네트워크(예를 들어, RAN, 위성 네트워크)에 맞춤화된 혼잡 제어 메커니즘을 적용할 수 있다. 더욱이, QUIC 프록시(210)의 사용은 QUIC 패킷 페이로드의 종단간 기밀성(confidentiality)을 깨뜨리지 않는다. 대신에, 실시예에 따르면, 내부 연결(140c)의 암호화된 패킷 수는 QUIC 프록시(210)에 가시적이다. 이러한 수를 사용한 보고는 QUIC 프록시(210)가 QUIC 프록시(210)에 보유된 패킷을 식별하고 전달하기로 약속하기에 충분함으로써, QUIC 클라이언트(220)는 혼잡 제어를 지원하기 위해 확인 응답을 다시 QUIC 서버(230)로 송신할 수 있다. 또한, 다중 병렬 종단간 연결(140c)은 QUIC 프록시(210)와 QUIC 클라이언트(220) 사이의 단일 혼잡 제어 루프 내에서 관리될 수 있으며, 이는 다중 연결(140) 간의 자원 공유가 향상되도록 할 수 있다.
상술한 관점에서, 도 5에 도시된 바와 같이, 본 개시의 실시예는 QUIC 클라이언트(220)를 향해 송신되는 외부 QUIC 계층에서 하나 이상의 QUIC 서버(230)로부터 수신하는 패킷을 캡슐화하는 QUIC 프록시(210)를 포함한다. (도 5에 도시된 바와 같이) QUIC 프록시(210)는 나중에 QUIC 클라이언트(210)로의 송신을 위해 QUIC 서버(230)로부터 부가적인 패킷을 수신하고 버퍼링할 경우(예를 들어, QUIC 프록시는 혼잡 제어 이유로 이러한 부가적인 패킷을 아직 포워딩할 수 없음), QUIC 프록시(210)는 이러한 아직 포워딩되지 않은(not-yet-forwarded) 패킷의 패킷 수를 포함하는 "약속 프레임"을 부가한다. QUIC 클라이언트(220)는, 약속 프레임을 수신하면, 이러한 패킷이 실제로 QUIC 클라이언트(220)에 의해 수신된 것처럼 패킷을 송신한 QUIC 서버(230)를 향해 이러한 패킷을 확인 응답한다. 이것은 QUIC 서버(230)가 QUIC 클라이언트(220)와 QUIC 서버(230) 사이의 데이터 전송을 진행하도록 한다. 즉, QUIC 서버(230)는 패킷이 QUIC 클라이언트(220)로 전달된 것처럼 패킷을 계속 송신할 수 있으며, 이에 의해 클라이언트 레그(leg) 상에서 수행되는 혼잡 제어가 종단간 통신(140c)의 서버 레그 상에서 송신률을 늦추는 것을 방지할 수 있다.
도 5의 특정 예에는 4가지 타입의 패킷이 있으며, 이는 설명을 위해 SC, PC, CP 및 CS 패킷으로서 라벨링(labeling)된다. SC 패킷은 QUIC 서버(230)에 의해 송신된 패킷이며, QUIC 클라이언트(220)를 위해 의도된 데이터를 반송한다. PC 패킷은 QUIC 프록시(210)에 의해 QUIC 클라이언트(220)로 송신된 패킷이다. 이러한 PC 패킷은 하나 이상의 SC 패킷을 포함할 수 있으며, 어떤 경우에는 QUIC 프록시(210)가 수신하고, 전달할 것을 약속하며, 아직 송신하지 않은 패킷의 패킷 수를 명시하는 프레임을 포함한다. CP 패킷은 QUIC 클라이언트(220)에 의해 QUIC 프록시(210)로 송신된 패킷이다. CP 패킷은 QUIC 클라이언트(220)에 의해 실제로 수신된 패킷의 확인 응답을 포함한다. 어떤 경우에, 이러한 CP 패킷은 QUIC 클라이언트(220)에 의해 송신되고 QUIC 서버(230)를 위해 의도된 패킷인 하나 이상의 CS 패킷을 캡슐화한다. CS 패킷은 QUIC 클라이언트(220)에 의해 실제로 수신된 패킷의 확인 응답과 QUIC 프록시(210)가 전달하기로 약속한 패킷을 포함한다.
이제 도 5에 도시된 다이어그램의 흐름에 따라, 데이터는 QUIC 프록시(210)를 통해 QUIC 서버(230)로부터 QUIC 클라이언트(220)를 향한 패킷으로(즉, SC 패킷으로) 송신된다. QUIC 프록시(210)는 SC 패킷을 PC 패킷으로 캡슐화하고, 이러한 PC 패킷을 QUIC 클라이언트(220)로 포워딩한다. QUIC 프록시(210)는 캡슐화 PC 패킷의 일부(이 예에서는 PC1과 PC2에서)에 프레임(즉, 약속 프레임)을 포함한다. 이러한 부가적인 프레임은 QUIC 프록시(210)가 수신하고 QUIC 클라이언트(220)로 전달하려는 패킷(즉, 지금까지 수신된 SC1-4 패킷)의 패킷 수를 나타낸다. QUIC 클라이언트(220)는 QUIC 클라이언트(220)에 의해 수신된 SC 패킷 및 QUIC 프록시(210)가 전달하기로 약속한 SC 패킷의 확인 응답을 포함하는 CS 패킷을 QUIC 서버(230)로 송신한다. CS 패킷은 실제로 수신된 SC 패킷(즉, QUIC 프록시(210)에 의해 약속되었지만 아직 도착하지 않은 패킷은 아님)을 확인 응답하는 CP 패킷에 의해 캡슐화된다. CS 패킷을 포함하는 CP 패킷을 수신하는 것에 응답하여, QUIC 프록시(210)는 CP 패킷을 캡슐화 해제하고, CS 패킷을 QUIC 서버(230)로 포워딩한다.
상술한 관점에서, QUIC 프록시(210)는 개개의 패킷을 식별하기 위한 어떤 방식을 필요로 할 수 있다. 위에서 논의한 바와 같이, QUIC 패킷 수는 일반적으로 QUIC 패킷 페이로드를 암호화하는 데 사용되는 것과 상이한 키를 사용하여 암호화되는 QUIC 패킷 헤더의 일부이다. 따라서, 약속 프레임의 구조는 QUIC 프록시(210)가 종단간 헤더 보호 키에 액세스하는지 여부에 따라 달라질 수 있다. QUIC 클라이언트(220)가 종단간 헤더 보호 키를 QUIC 프록시(210)에 노출하면, QUIC 클라이언트(220)는 키가 도출된 후(예를 들어, 바람직하게는 이러한 키를 이러한 제1 패킷에 부가함)에 QUIC 프록시(210)를 향해 송신된 패킷에 헤더 보호 키를 부가할 수 있다. 일반적으로, 각각의 종단간 연결(140c)은 자신의 헤더 보호 키를 가질 가능성이 높다.
위에서 논의된 바와 같이, 약속 프레임은 QUIC 프록시(210)가 QUIC 서버(230)로부터 수신하고, QUIC 클라이언트(220)에 전달하기로 약속한 하나 이상의 종단간 QUIC 패킷 수의 세트를 포함한다. 약속 프레임의 구조는 QUIC 프록시(210)가 종단간 헤더 보호 키에 액세스하는지 여부에 따라 달라질 수 있다. 약속 프레임의 예시적인 구조가 아래에서 논의되고, 도 6-8에 도시되어 있지만, 다른 예는 다른 구조를 가질 수 있다. 즉, 여러 실시예는 하나 이상의 QUIC 연결(140)의 암호화된 패킷 수와 암호화되지 않은 패킷 수가 어떻게 처리될 수 있는지에 대한 유사한 일반적 개념을 적용한다. 또한, 약속 프레임은 실시예에 따라 코어 QUIC 전송 프로토콜의 일부일 수 있거나 QUIC 페이로드로서 송신될 수 있다는 것이 주목되어야 한다. 또한, 위에서 논의된 바와 같이, 비-QUIC 프로토콜에 적용되는 실시예는 유사한 특징 및 변형을 가질 수 있다.
일부 실시예에서, QUIC 프록시(210)는 종단간 패킷 헤더를 해독하고(예를 들어, 클라이언트로부터 QUIC 헤더 보호 키를 수신한 후), QUIC 프록시(210)가 전달하기로 약속하는 하나 이상의 패킷을 식별하는 약속 프레임을 생성한다. 일부 실시예에서, 약속 프레임은 약속된 패킷을 나타내기 위한 하나 이상의 필드를 포함한다. 예를 들어, 약속 프레임은 전달을 위해 약속된 특정 패킷의 수를 명시하는 필드, 특정 패킷의 뒤를 잇거나 선행하는 인접한 패킷의 범위를 나타내는 필드, 및/또는 예를 들어 약속된(및/또는 약속되지 않은) 인접한 패킷의 하나 이상의 추가의 범위를 나타내는 하나 이상의 필드를 포함할 수 있다.
도 6은 이러한 예를 도시한다. 약속 프레임(300)은 가장 큰 수신된 필드(310), 범위 카운트 필드(320), 제1 범위 필드(330) 및 범위 필드(340)를 포함한다. 가장 큰 수신된 필드(310)는 프록시에 의해 수신되고 향후 클라이언트로 전달하기 위해 약속된 가장 큰 패킷 수를 나타낸다. 범위 카운트 필드(320)는 약속 프레임(300)이 제1 범위 및/또는 범위 필드(330, 340)를 사용하여 나타내는 패킷 수의 범위를 나타낸다. 프록시가 가장 큰 수신된 패킷까지 모든 패킷을 수신한 경우, 이러한 필드는 0일 수 있다.
제1 범위는 가장 큰 수신된 필드(310)에서 나타내어진 패킷 이전의 인접한 패킷의 수를 나타낸다. 따라서, 가장 큰 수신된 필드(310)가 정수 값 999로 설정되고, 제1 범위 필드(330)가 6으로 설정되면, 이는 QUIC 프록시(210)가 패킷 수 999 및 이의 6개의 선행 패킷(즉, 패킷 993-999)을 수신하고, 이러한 패킷을 나중에 QUIC 클라이언트(220)로 전달할 것을 약속한다는 것을 나타낼 수 있다.
범위 필드(340)는 교대로 약속되지 않고 약속되는 인접한 패킷의 하나 이상의 부가적인 범위를 나타낸다. 이러한 필드는 QUIC 프록시(210)가 QUIC 클라이언트(220)에 약속할 수 있는 패킷 사이에 갭이 있을 때 유용할 수 있다. 예를 들어, QUIC 프록시(210)가 아직 수신하지 않은 패킷, 또는 오류를 포함하고 포워딩하기에 적절하지 않은 수신된 패킷이 있을 수 있다.
따라서, 가장 큰 수신된 필드(310)가 값 999를 나타내고, 제1 범위 필드(330)가 값 6을 나타내며, 범위 필드(340)가 값 4, 6 및 5를 나타내는 경우, 패킷 수 993-999는 (상술한 예에서 논의되고, 가장 큰 수신된 필드 및 제1 범위 필드(310, 330)에 의해 나타내어지는 바와 같이) 약속되고, 989-992는 (범위 필드(340)의 제1 값에 의해 나타내어지는 바와 같이) 전달을 위해 약속되지 않으며, 패킷 983-988은 (범위 필드(340)의 제2 값에 의해 나타내어지는 바와 같이) 약속되며, 패킷 978-982는 (범위 필드(340)의 제3 값에 의해 나타내어지는 바와 같이) 약속된다. 이러한 예에서, 범위 카운트 필드(320)는 제1 범위 필드(330)에 나타내어진 범위, 및 범위 필드(340)에 나타내어진 3개의 범위를 나타내기 위해 4로 설정될 수 있다.
일부 실시예에서, 가장 큰 수신된 필드, 범위 카운트 필드, 제1 범위 필드 및 범위 필드(310, 320, 330, 340)의 각각은 약속 프레임(300)에 포함되지만, 다른 실시예에서는 부가적인 필드, 더 적은 필드 또는 다른 필드가 약속 프레임(300)에 포함될 수 있다. 예를 들어, 하나의 패킷만이 약속되고 있다면, 약속 필드는 가장 큰 수신된 필드(310)를 포함할 수 있고, 범위 카운트 필드, 제1 범위 필드 및 범위 필드(320, 330, 340)를 생략할 수 있다. 다른 실시예에서, 가장 큰 수신된 필드(310)는 약속되는 하나의 패킷을 명시할 수 있고, 다른 필드 중 하나 이상은 0일 수 있다.
다른 실시예에서, 약속 프레임(300)은 가장 큰 수신된 필드(310) 및 제1 범위 필드(330)를 포함할 수 있고, (예를 들어, 하나의 범위만이 약속될 때) 범위 카운트 필드 및 범위 필드를 생략할 수 있다.
다른 실시예에서, 약속 프레임(300)은 범위 카운트 필드 및 제1 범위 필드(320, 330)를 생략할 수 있고, 추가의 범위가 나타내어지지 않을 때 범위 필드(340)에 나타내어진 범위의 세트를 0으로 종료할 수 있다.
이러한 필드의 각각은 각각의 의미를 전달하기 위한 적절한 타입일 수 있다. 예를 들어, 가장 큰 수신된 필드, 범위 카운트 필드 및 제1 범위 필드(310, 320, 330)는 가변 길이의 정수 필드일 수 있고, 범위 필드(340)는 하나 이상의 가변 길이의 정수 서브필드를 포함할 수 있다. 다른 실시예는 고정된 길이의 필드를 포함할 수 있거나 다른 데이터 타입(예를 들어, 텍스트)을 나타낼 수 있다.
일부 실시예에서, 프록시는 수신된 QUIC 패킷의 헤더에 액세스할 수 없다. 예를 들어, QUIC 프록시(210)는 종단간 헤더 보호 키에 액세스할 수 없다. 이러한 적어도 일부 실시예에서, QUIC 프록시(210)는 암호화된 헤더 데이터를 약속 프레임(300)에 부가한다. QUIC 프록시(210)가 QUIC 클라이언트(220)에 통지할 각각의 패킷에 대해, QUIC 프록시(210)는 헤더를 해독하는데 필요한 원시 패킷 데이터를 추출한다. 패킷 수를 해독하는 데 필요한 데이터는 패킷 수 필드의 시작으로부터의 4 옥텟과 패킷 헤더에 따르는 암호화된 패킷 데이터의 N 옥텟으로 구성된다. N의 정확한 값은 사용 중인 암호화 알고리즘에 따라 달라진다. 예를 들어, QUIC 사양의 적어도 하나의 버전에서, 해당 값은 항상 16이다.
패킷 수는 QUIC 헤더의 불변의 일부가 아니기 때문에, (새로운 QUIC 버전에 명시된 바와 같은) 새로운 암호화 알고리즘은 패킷 수를 해독하는 데 필요한 옥텟의 수를 변경할 수 있다. 따라서, 일부 실시예에서, QUIC 클라이언트(220)는 패킷 수를 해독하는데 필요한 헤더의 부분이 패킷 내에 위치되는 QUIC 프록시(210)로 시그널링한다. 예를 들어, QUIC 클라이언트(220)는 필요한 암호화된 패킷 데이터 옥텟이 시작되는 곳을 나타내는 헤더의 시작으로부터의 오프셋을 QUIC 프록시(210)로 시그널링할 수 있고, N의 값은 헤더를 해독하는 데 필요한 암호화된 패킷 데이터의 옥텟의 수를 나타낸다. 이러한 실시예는 QUIC 프록시(210)가 패킷 헤더의 관련 섹션을 약속 프레임(300)으로 복사하여, QUIC 클라이언트(220)가, 이러한 약속 프레임(300)을 수신할 때, 이러한 섹션을 해독하고, QUIC 프록시(210)에 의해 향후 전달을 위해 수신되고 약속된 패킷의 수를 결정할 수 있도록 할 수 있다. 이러한 실시예는 헤더 보호 방식의 특정 양태가 QUIC의 향후 버전에서 변경될지라도 QUIC 프록시(210)가 약속 프레임(300)을 QUIC 클라이언트(220)에 제공할 수 있게 할 수 있다.
도 7은 패킷 수가 암호화되는 약속 프레임(300) 구조의 예를 도시한다. 약속 프레임(300)은 패킷 카운트 필드(350) 및 보호된 패킷 헤더 부분 필드(360)를 포함한다. 이 예에서, 패킷 카운트 필드(350)는 QUIC 프록시(210)가 예를 들어, 약속 프레임(300)과 함께 제공되는 패킷에 전체적 또는 부가적으로 관찰한 패킷의 정수를 나타낸다. 특히, 도 5에 도시된 바와 같이, 약속 프레임(300)은 QUIC 클라이언트(220)로 송신되는 동일한 PC 패킷에 캡슐화된 SC 패킷 이외의 하나 이상의 패킷을 식별할 수 있다. 이 예에서, 암호화된 패킷 수 및 해독에 필요한 연관된 데이터 세트는 패킷 카운트 필드(350)에 나타내어진 만큼의 패킷에 대한 패킷 카운트 필드(350) 뒤에(즉, 보호된 패킷 헤더 부분 필드(360)에) 부가되어, QUIC 클라이언트(220)가 약속되는 하나 이상의 패킷을 결정하기 위해 이러한 조각(piece)을 사용할 수 있다.
도 8은 QUIC 프록시(210)가 패킷 수에 액세스할 수 없을 때(예를 들어, 패킷이 암호화되어 있고, QUIC 프록시(210)가 헤더의 관련 부분을 해독하는데 필요한 헤더 보호 키를 갖고 있지 않기 때문에) 패킷의 전달을 약속하기 위한 약속 프레임(300)의 다른 예를 도시한다. 이 예에서, 패킷 수를 해독하는 데 필요한 필드의 길이는 각각의 패킷에 대해 동일하다. 따라서, 이러한 예시적인 약속 프레임(300)에서는 특정 길이 필드가 인코딩되지 않는다. 대신, 이러한 약속 프레임(300)은, 약속된 각각의 패킷에 대해, 보호된 헤더 부분 필드(370) 및 샘플링된 보호된 페이로드 부분 필드(380)를 포함한다. 이 예에서, 보호된 헤더 부분 필드(370) 및 샘플링된 보호된 페이로드 부분 필드(380)는 각각 32비트 및 128비트의 길이를 갖는다. 다른 예는 단일 보호된 헤더 부분 필드(370) 및 하나 이상의 샘플링된 보호된 페이로드 부분 필드(380)를 포함할 수 있다. 예를 들어, 보호된 헤더 부분이 각각의 패킷에 대해 동일한(또는 도출 가능한) 경우, QUIC 클라이언트(220)가 제공된 단일 보호된 헤더 부분 필드의 정보를 기반으로 패킷 수를 해독하기 위해 올바른(correct) 정보를 사용하는 것에 의존할 수 있음에 따라, 보호된 헤더 부분 필드(370)의 정보는 각각의 패킷에 대해 명시적으로 포함될 필요가 없다.
위에서 논의된 바와 같이, 특정 실시예의 다양한 특징 및 개념을 설명하기 위해, QUIC 프로토콜을 지원하는 프록시, 클라이언트 및 서버의 맥락에서 예가 논의되었다. 다른 실시예는 다른 프로토콜을 사용할 수 있다. 실제로, (예를 들어, 특정 통합된 보안 특징으로 인해) 패킷의 아이덴티티(identity; ID)를 암호화하거나 달리 난독화하는 다른 프로토콜은 동일하거나 유사한 개념을 적용하는 데 적합할 수 있다.
상술한 모든 것을 고려하여, 도 9에 도시된 바와 같이, 본 개시의 실시예는 수신 장치(예를 들어, QUIC 연결에 대한 엔드포인트)에 의해 구현되는 방법(800)을 포함한다. 방법(800)은 프록시 서버가 나중에 송신 장치로부터의 패킷을 수신 장치로 전달할 것임을 나타내는 약속 프레임(300)을 프록시 서버로부터 수신하는 단계를 포함한다(블록(810)). 방법(800)은 패킷의 확인 응답을 프록시 서버를 통해 송신 장치로 송신하는 단계(블록(820)), 및 패킷의 확인 응답을 프록시 서버를 통해 송신 장치로 송신한 후 프록시 서버로부터 패킷을 수신하는 단계(블록(830))를 더 포함한다.
다른 실시예는 도 10에 도시된 바와 같이 프록시 서버에 의해 구현되는 방법(850)을 포함한다. 방법(850)은 송신 장치로부터 수신 장치를 위해 의도된 패킷을 수신하는 단계를 포함한다(블록(860)). 방법(850)은 프록시 서버가 패킷을 나중에 수신 장치로 전달할 것임을 나타내는 약속 프레임(300)을 수신 장치로 송신하는 단계를 더 포함한다(블록(870)). 방법(850)은 수신 장치로부터의 패킷의 확인 응답을 송신 장치로 포워딩하는 단계(블록(880)) 및 확인 응답을 송신 장치로 포워딩한 후 패킷을 수신 장치로 전달하는 단계(블록(890))를 더 포함한다.
또한, 도 11에 도시된 바와 같이, 다른 실시예는 수신 장치(600)를 포함한다. 도 11의 수신 장치(600)는 처리 회로(610) 및 인터페이스 회로(630)를 포함한다. 처리 회로(610)는 예를 들어, 하나 이상의 버스를 통해 인터페이스 회로(630)에 통신 가능하게 결합된다. 일부 실시예에서, 네트워크 노드(600)는 예를 들어 하나 이상의 버스를 통해 처리 회로(610)에 통신 가능하게 결합된 메모리 회로(620)를 더 포함한다. 특정 실시예에 따르면, 처리 회로(610)는 본 명세서에 설명된 방법(예를 들어, 도 9에 도시된 방법(800)) 중 하나 이상을 수행하도록 구성된다. 부가적 또는 대안적으로, 수신 장치(600)는 실시예에 따라 (QUIC 클라이언트(220), QUIC 서버(230), 및/또는 사용자 장치(User Equipment; UE)와 같은) QUIC 연결에 대한 엔드포인트일 수 있다.
또한, 도 12에 도시된 바와 같이, 다른 실시예는 프록시 서버(700)(예를 들어, QUIC 프록시(210))를 포함한다. 도 12의 프록시 서버(700)는 처리 회로(710) 및 인터페이스 회로(730)를 포함한다. 처리 회로(710)는 예를 들어 하나 이상의 버스를 통해 인터페이스 회로(730)에 통신 가능하게 결합된다. 일부 실시예에서, 프록시 서버(700)는 예를 들어 하나 이상의 버스를 통해 처리 회로(710)에 통신 가능하게 결합된 메모리 회로(720)를 더 포함한다. 특정 실시예에 따르면, 처리 회로(710)는 본 명세서에 설명된 방법(예를 들어, 도 10에 도시된 방법(850)) 중 하나 이상을 수행하도록 구성된다. 부가적 또는 대안적으로, 프록시 서버(700)는 네트워크 노드, QUIC 프록시(210), 액세스 노드, 기지국, 게이트웨이, 라우터, 스위치, 및/또는 다른 네트워크 장치일 수 있다.
장치(600, 700)의 처리 회로(610, 710)는 하나 이상의 마이크로프로세서, 마이크로 제어기, 하드웨어 회로, 이산 논리 회로, 하드웨어 레지스터, 디지털 신호 프로세서(digital signal processor; DSP), 필드 프로그램 가능한 게이트 어레이(field-programmable gate array; FPGA), 애플리케이션 특정 집적 회로(application-specific integrated circuit; ASIC) 또는 이의 조합을 포함할 수 있다. 예를 들어, 처리 회로(610, 710)는 메모리 회로(620, 720)에 저장된 컴퓨터 프로그램(660, 760)의 소프트웨어 명령어를 실행할 수 있는 프로그램 가능한 하드웨어일 수 있으며, 이에 의해 처리 회로(610, 710)가 구성된다. 다양한 실시예의 메모리 회로(620, 720)는 솔리드 스테이트 미디어(solid state media)(예를 들어, SRAM, DRAM, DDRAM, ROM, PROM, EPROM, 플래시 메모리, 솔리드 스테이트 드라이브 등), 이동식 저장 장치(예를 들어, SD(Secure Digital) 카드, miniSD 카드, microSD 카드, 메모리 스틱, 썸 드라이브(thumb-drive), USB 플래시 드라이브, ROM 카트리지, 범용 미디어 디스크), 고정된 드라이브(예를 들어, 자기 하드 디스크 드라이브) 등을 전체적으로 또는 임의의 조합으로 포함하지만, 이에 제한되지 않는 휘발성 또는 비휘발성 여부에 관계없이 통상의 기술자에 알려져 있거나 개발될 수 있는 임의의 비일시적 기계 판독 가능 매체를 포함할 수 있다.
인터페이스 회로(630, 730)는 각각의 장치(600, 700)의 입출력(I/O) 데이터 경로를 제어하도록 구성된 제어기 허브(controller hub)일 수 있다. 이러한 I/O 데이터 경로는 통신 네트워크를 통해 신호를 교환하기 위한 데이터 경로, 사용자와 신호를 교환하기 위한 데이터 경로, 및/또는 네트워크 노드(600, 700)의 구성 요소 사이에서 내부적으로 데이터를 교환하기 위한 데이터 경로를 포함할 수 있다. 예를 들어, 인터페이스 회로(630, 730)는 셀룰러 네트워크, 이더넷 네트워크 또는 광 네트워크 중 하나 이상을 통해 통신 신호를 송수신하도록 구성된 송수신기를 포함할 수 있다. 인터페이스 회로(630, 730)는 단일 물리적 구성 요소로서, 또는 연속적으로 또는 별개로 배치되는 복수의 물리적 구성 요소로서 구현될 수 있으며, 이들 중 임의의 것은 임의의 다른 것에 통신 가능하게 결합될 수 있거나 처리 회로(610, 710)를 통해 임의의 다른 것과 통신할 수 있다. 예를 들어, 인터페이스 회로(630, 730)는 통신 네트워크를 통해 통신 신호를 송신하도록 구성된 송신기 회로(640, 740) 및 통신 네트워크를 통해 통신 신호를 수신하도록 구성된 수신기 회로(650, 750)를 포함할 수 있다. 유사하게, 인터페이스 회로(630, 730)는 디스플레이 및/또는 키보드를 포함할 수 있다. 다른 실시예는 및/또는 상술한 것 및/또는 이의 등가물의 다른 순열 및/또는 배열을 포함할 수 있다.
도 11에 도시된 수신 장치(600)의 실시예에 따르면, 처리 회로(610)는 프록시 서버(700)가 나중에 송신 장치로부터의 패킷을 수신 장치(600)로 전달할 것임을 나타내는 약속 프레임(300)을 프록시 서버(700)로부터 수신하고, 패킷의 확인 응답을 프록시 서버(700)를 통해 송신 장치로 송신하도록 구성된다. 처리 회로(610)는 패킷의 확인 응답을 프록시 서버(700)를 통해 송신 장치로 송신한 후 프록시 서버(700)로부터 패킷을 수신하도록 더 구성된다.
도 12에 도시된 프록시 서버(700)의 실시예에 따르면, 처리 회로(710)는 송신 장치로부터 수신 장치(600)를 위해 의도된 패킷을 수신하고, 프록시 서버(700)가 패킷을 나중에 수신 장치(600)로 전달할 것임을 나타내는 약속 프레임(300)을 수신 장치(600)로 송신하도록 구성된다. 처리 회로(710)는 수신 장치(600)로부터의 패킷의 확인 응답을 송신 장치로 포워딩하고, 확인 응답을 송신 장치로 포워딩한 후 패킷을 수신 장치(600)로 전달하도록 더 구성된다.
본 개시의 다른 실시예는 상응하는 컴퓨터 프로그램을 포함한다. 이러한 일 실시예에서, 컴퓨터 프로그램은, 수신 장치(600)의 처리 회로 상에서 실행될 때, 수신 장치(600)가 상술한 각각의 처리 중 임의의 것을 수행하게 하는 명령어를 포함한다. 이러한 다른 실시예에서, 컴퓨터 프로그램은, 프록시 서버(700)의 처리 회로 상에서 실행될 때, 프록시 서버(700)가 상술한 각각의 처리 중 임의의 것을 수행하게 하는 명령어를 포함한다. 어느 쪽이든 컴퓨터 프로그램은 상술한 수단 또는 유닛에 상응하는 하나 이상의 코드 모듈을 포함할 수 있다.
실시예는 컴퓨터 프로그램 제품이 컴퓨팅 장치에 의해 실행될 때 본 명세서의 실시예 중 임의의 것의 단계를 수행하기 위한 프로그램 코드 부분을 포함하는 컴퓨터 프로그램 제품을 더 포함한다. 이러한 컴퓨터 프로그램 제품은 컴퓨터 판독 가능한 기록 매체에 저장될 수 있다.
본 명세서에 개시된 임의의 적절한 단계, 방법, 특징, 기능 또는 이점은 하나 이상의 가상 장치의 하나 이상의 기능 유닛 또는 모듈을 통해 수행될 수 있다. 각각의 가상 장치는 이러한 다수의 기능 유닛을 포함할 수 있다. 이러한 기능 유닛은 디지털 신호 프로세서(DSP), 특수 목적 디지털 로직 등을 포함할 수 있는 다른 디지털 하드웨어 뿐만 아니라 하나 이상의 마이크로프로세서 또는 마이크로 제어기를 포함할 수 있는 처리 회로를 통해 구현될 수 있다. 처리 회로는 메모리에 저장된 프로그램 코드를 실행하도록 구성될 수 있으며, 이는 판독 전용 메모리(read-only memory; ROM), 랜덤 액세스 메모리(random-access memory; RAM), 캐시 메모리, 플래시 메모리 장치, 광학 저장 장치 등과 같은 하나 또는 여러 타입의 메모리를 포함할 수 있다. 메모리에 저장된 프로그램 코드는 본 명세서에 설명된 하나 이상의 기술을 수행하기 위한 명령어 뿐만 아니라 하나 이상의 통신 및/또는 데이터 통신 프로토콜을 실행하기 위한 프로그램 명령어를 포함한다. 일부 구현에서, 처리 회로는 각각의 기능 유닛이 본 개시의 하나 이상의 실시예에 따라 상응하는 기능을 수행하게 하는 데 사용될 수 있다.
일반적으로, 본 명세서에 사용된 모든 용어는 상이한 의미가 명백히 부여되거나 사용되는 문맥에서 암시되지 않는 한 관련 기술 분야에서 통상적인 의미에 따라 해석되어야 한다. 요소, 장치, 구성 요소, 수단, 단계 등에 대한 모든 참조는 명시적으로 달리 언급되지 않는 한 요소, 장치, 구성 요소, 수단, 단계 등의 적어도 하나의 인스턴스(instance)를 참조하는 것으로 공개적으로 해석되어야 한다. 본 명세서에 개시된 임의의 방법의 단계는 단계가 다른 단계를 따르거나 선행하는 것으로서 명시적으로 설명되지 않는 한 및/또는 단계가 다른 단계를 따르거나 선행해야 함을 암시하지 않는 한 개시된 정확한 순서로 수행될 필요는 없다. 본 명세서에 개시된 임의의 실시예의 임의의 특징은 적절한 경우에 임의의 다른 실시예에 적용될 수 있다. 마찬가지로, 임의의 실시예의 임의의 이점은 임의의 다른 실시예에 적용될 수 있고, 그 반대도 적용될 수 있다. 첨부된 실시예의 다른 목적, 특징 및 이점은 설명으로부터 명백할 것이다.
유닛이라는 용어는 전자, 전기 장치 및/또는 전자 장치의 분야에서 일반적인 의미를 가질 수 있으며, 예를 들어 전기 및/또는 전자 회로, 장치, 모듈, 프로세서, 메모리, 논리 솔리드 스테이트 및/또는 이산 장치, 본 명세서에 설명된 것과 같은 각각의 태스크(task), 절차, 계산, 출력 및/또는 표시 기능을 수행하기 위한 컴퓨터 프로그램 또는 명령어를 포함할 수 있다.
본 명세서에서 고려되는 실시예의 일부는 첨부된 도면을 참조하여 보다 완전하게 설명된다. 그러나, 다른 실시예는 본 명세서에 개시된 주제의 범위 내에 포함된다. 개시된 주제는 본 명세서에 설명된 실시예로만 제한되는 것으로서 해석되지 않아야 한다. 오히려, 이러한 실시예는 통상의 기술자에게 주제의 범위를 전달하기 위해 예로서 제공된다.

Claims (30)

  1. 수신 장치(600)에 의해 구현되는 방법(800)에 있어서,
    프록시 서버(700)가 나중에 송신 장치로부터의 패킷을 수신 장치(600)로 전달할 것임을 나타내는 약속 프레임(300)을 프록시 서버(700)로부터 수신하는 단계(810);
    프록시 서버(700)를 통해 패킷의 확인 응답을 송신 장치로 송신하는 단계(820);
    프록시 서버(700)를 통해 패킷의 확인 응답을 송신 장치로 송신한 후에 프록시 서버(700)로부터 패킷을 수신하는 단계(830)를 포함하는, 수신 장치(600)에 의해 구현되는 방법(800).
  2. 제 1 항에 있어서,
    프록시 서버(700)로부터, 송신 장치 및 약속 프레임(300)에 의해 송신된 추가의 패킷을 포함하는 제1 캡슐화 패킷을 수신하는 단계를 더 포함하며;
    프록시 서버(700)로부터 약속 프레임(300)을 수신하는 단계는 제1 캡슐화 패킷 내에서 약속 프레임(300)을 수신하는 단계를 포함하는, 수신 장치(600)에 의해 구현되는 방법(800).
  3. 제 1 항 또는 제 2 항에 있어서,
    패킷의 확인 응답을 송신하는 단계는 제2 캡슐화 패킷으로 패킷의 확인 응답을 송신하는 단계를 포함하고;
    제2 캡슐화 패킷은 제1 캡슐화 패킷의 확인 응답을 더 포함하며;
    패킷의 확인 응답은 또한 추가의 패킷을 확인 응답하는, 수신 장치(600)에 의해 구현되는 방법(800).
  4. 제 1 항 내지 제 3 항 중 어느 한 항에 있어서,
    약속 프레임(300)에서 패킷의 패킷 수를 수신하는 단계를 더 포함하며, 패킷 수는 프록시 서버(700)가 패킷을 나중에 수신 장치(600)로 전달할 것임을 나타내는, 수신 장치(600)에 의해 구현되는 방법(800).
  5. 제 1 항 내지 제 4 항 중 어느 한 항에 있어서,
    약속 프레임(300)에서, 프록시 서버(700)가 나중에 수신 장치(600)로 전달할 것을 약속하는 프록시 서버(700)에 의해 수신된 부가적인 패킷에 상응하는 하나 이상의 부가적인 패킷 수의 인디케이션을 수신하는 단계를 더 포함하며;
    하나 이상의 부가적인 패킷 수의 인디케이션은 패킷 바로 앞에 얼마나 많은 인접한 패킷이 부가적인 패킷에 포함되고, 약속 프레임(300)에 따라 나중에 수신 장치(600)로 전달될 것으로 약속되는지를 명시하는 수를 포함하는, 수신 장치(600)에 의해 구현되는 방법(800).
  6. 제 1 항 내지 제 5 항 중 어느 한 항에 있어서,
    약속 프레임(300)에서, 프록시 서버(700)에 의해 송신 장치로부터 수신되지 않은 다른 패킷에 상응하고, 약속 프레임(300)에 따라, 수신 장치(600)로의 다른 패킷의 전달이 프록시 서버(700)에 의해 약속되지 않음을 나타내는 하나 이상의 다른 패킷 수의 추가의 인디케이션을 수신하는 단계를 더 포함하는, 수신 장치(600)에 의해 구현되는 방법(800).
  7. 제 1 항 내지 제 6 항 중 어느 한 항에 있어서,
    다른 패킷은 연속적이며, 패킷 바로 앞의 인접한 패킷 바로 앞에 있으며;
    하나 이상의 부가적인 패킷 수의 인디케이션은 다른 패킷 바로 앞에 얼마나 많은 인접한 패킷이 부가적인 패킷에 포함되고, 약속 프레임(300)에 따라, 프록시 서버(700)에 의해 나중에 수신 장치(600)(600)로 전달될 것으로 약속되는지를 명시하는 추가의 수를 더 포함하는, 수신 장치(600)에 의해 구현되는 방법(800).
  8. 제 1 항 내지 제 7 항 중 어느 한 항에 있어서,
    약속 프레임(300)은 얼마나 많은 패킷 범위가 약속 프레임(300)에 의해 나타내어지는지를 나타내는 범위 카운트 필드(320)를 포함하는, 수신 장치(600)에 의해 구현되는 방법(800).
  9. 제 1 항 내지 제 3 항 중 어느 한 항에 있어서,
    약속 프레임(300)에서, 프록시 서버(700)가 패킷을 나중에 수신 장치(600)로 전달할 것임을 나타내기 위해 패킷의 패킷 수를 인코딩하는 패킷의 암호화된 부분을 수신하는 단계; 및
    프록시 서버(700)가 나중에 수신 장치(600)로 전달할 패킷을 식별하기 위해 약속 프레임(300)에 포함된 패킷의 암호화된 부분을 해독하는 단계를 더 포함하는, 수신 장치(600)에 의해 구현되는 방법(800).
  10. 제 1 항 내지 제 9 항 중 어느 한 항에 있어서,
    약속 프레임(300)에서, 얼마나 많은 패킷이 약속 프레임(300)에 따라 나중에 수신 장치(600)로 전달되는 것으로 약속되는지를 나타내는 패킷 카운트를 수신하는 단계를 더 포함하는, 수신 장치(600)에 의해 구현되는 방법(800).
  11. 프록시 서버(700)에 의해 구현되는 방법(850)에 있어서,
    송신 장치로부터 수신 장치(600)를 위해 의도된 패킷을 수신하는 단계(860);
    프록시 서버(700)가 패킷을 나중에 수신 장치(600)로 전달할 것임을 나타내는 약속 프레임(300)을 수신 장치(600)로 송신하는 단계(870);
    수신 장치(600)로부터의 패킷의 확인 응답을 송신 장치로 포워딩하는 단계(880); 및
    확인 응답을 송신 장치로 포워딩한 후에 패킷을 수신 장치(600)로 전달하는 단계(890)를 포함하는, 프록시 서버(700)에 의해 구현되는 방법(850).
  12. 제 11 항에 있어서,
    수신 장치(600)를 위해 의도된 추가의 패킷을 수신하는 단계; 및
    추가의 패킷 및 약속 프레임(300)을 포함하는 제1 캡슐화 패킷을 수신 장치(600)로 송신하는 단계를 더 포함하며;
    약속 프레임(300)을 수신 장치(600)로 송신하는 단계는 제1 캡슐화 패킷 내에서 약속 프레임(300)을 송신하는 단계를 포함하는, 프록시 서버(700)에 의해 구현되는 방법(850).
  13. 제 11 항 또는 제 12 항에 있어서,
    패킷의 확인 응답을 포워딩하는 단계는,
    수신 장치(600)로부터 패킷의 확인 응답 및 나머지 부분 - 나머지 부분은 제1 캡슐화 패킷의 확인 응답을 포함함 - 을 포함하는 제2 캡슐화 패킷을 수신하는 단계; 및
    패킷의 확인 응답 - 패킷의 확인 응답은 또한 추가의 패킷을 확인 응답함 - 을 나머지 부분 없이 송신 장치로 송신하는 단계를 포함하는, 프록시 서버(700)에 의해 구현되는 방법(850).
  14. 제 11 항 내지 제 13 항 중 어느 한 항에 있어서,
    프록시 서버(700)가 패킷을 나중에 수신 장치(600)로 전달할 것임을 나타내기 위해 약속 프레임(300)에 패킷의 패킷 수를 포함하는 단계를 더 포함하는, 프록시 서버(700)에 의해 구현되는 방법(850).
  15. 제 11 항 내지 제 14 항 중 어느 한 항에 있어서,
    프록시 서버(700)가 부가적인 패킷을 나중에 수신 장치(600)로 전달할 것을 나타내기 위해 송신 장치로부터 수신된 부가적인 패킷에 상응하는 하나 이상의 부가적인 패킷 수의 인디케이션을 약속 프레임(300)에 포함하는 단계를 더 포함하며;
    하나 이상의 부가적인 패킷 수의 인디케이션은 패킷 바로 앞에 얼마나 많은 인접한 패킷이 부가적인 패킷에 포함되고, 약속 프레임(300)에 따라 나중에 수신 장치(600)로 전달될 것으로 약속되는지를 명시하는 수를 포함하는, 프록시 서버(700)에 의해 구현되는 방법(850).
  16. 제 11 항 내지 제 15 항 중 어느 한 항에 있어서,
    약속 프레임(300)에 따라, 프록시 서버(700)가 수신 장치(600)로의 다른 패킷의 전달을 약속하지 않음을 나타내기 위해 송신 장치로부터 수신되지 않은 다른 패킷에 상응하는 하나 이상의 다른 패킷 수의 추가의 인디케이션을 약속 프레임(300)에 포함하는 단계를 더 포함하는, 프록시 서버(700)에 의해 구현되는 방법(850).
  17. 제 11 항 내지 제 16 항 중 어느 한 항에 있어서,
    다른 패킷은 연속적이며, 패킷 바로 앞의 인접한 패킷 바로 앞에 있으며;
    하나 이상의 부가적인 패킷 수의 인디케이션은 다른 패킷 바로 앞에 얼마나 많은 인접한 패킷이 부가적인 패킷에 포함되고, 약속 프레임(300)에 따라, 나중에 수신 장치(600)로 전달될 것으로 약속되는지를 명시하는 추가의 수를 더 포함하는, 프록시 서버(700)에 의해 구현되는 방법(850).
  18. 제 11 항 내지 제 17 항 중 어느 한 항에 있어서,
    약속 프레임(300)이 얼마나 많은 패킷 범위가 약속 프레임(300)에 의해 나타내어지는지를 나타내는 범위 카운트 필드(320)를 포함하는, 프록시 서버(700)에 의해 구현되는 방법(850).
  19. 제 11 항 내지 제 13 항 중 어느 한 항에 있어서,
    프록시 서버(700)가 패킷을 나중에 수신 장치(600)로 전달할 것임을 나타내기 위해 패킷의 패킷 수를 인코딩하는 패킷의 암호화된 부분을 약속 프레임(300)에 포함하는 단계를 더 포함하는, 프록시 서버(700)에 의해 구현되는 방법(850).
  20. 제 11 항 내지 제 19 항 중 어느 한 항에 있어서,
    얼마나 많은 패킷이 약속 프레임(300)에 따라 나중에 수신 장치(600)로 전달되는 것으로 약속되는지를 나타내는 패킷 카운트를 약속 프레임(300)에 포함하는 단계를 더 포함하는, 프록시 서버(700)에 의해 구현되는 방법(850).
  21. 수신 장치(600)에 있어서,
    처리 회로(610) 및 처리 회로(610)에 통신 가능하게 연결된 인터페이스 회로(630)를 포함하며, 처리 회로(610)는,
    프록시 서버(700)가 나중에 송신 장치로부터의 패킷을 수신 장치(600)로 전달할 것임을 나타내는 약속 프레임(300)을 프록시 서버(700)로부터 수신하고;
    패킷의 확인 응답을 프록시 서버(700)를 통해 송신 장치로 송신하며;
    패킷의 확인 응답을 프록시 서버(700)를 통해 송신 장치로 송신한 후 프록시 서버(700)로부터 패킷을 수신하도록 구성되는, 수신 장치(600).
  22. 제 21 항에 있어서,
    처리 회로(610)는 제 2 항 내지 제 10 항 중 어느 한 항의 방법을 수행하도록 더 구성되는, 수신 장치(600).
  23. 수신 장치(600)에 있어서,
    프록시 서버(700)가 나중에 송신 장치로부터의 패킷을 수신 장치(600)로 전달할 것임을 나타내는 약속 프레임(300)을 프록시 서버(700)로부터 수신하고;
    패킷의 확인 응답을 프록시 서버(700)를 통해 송신 장치로 송신하며;
    패킷의 확인 응답을 프록시 서버(700)를 통해 송신 장치로 송신한 후 프록시 서버(700)로부터 패킷을 수신하도록 구성되는, 수신 장치(600).
  24. 제 23 항에 있어서,
    제 2 항 내지 제 10 항 중 어느 한 항의 방법을 수행하도록 더 구성되는, 수신 장치(600).
  25. 프록시 서버(700)에 있어서,
    처리 회로(710) 및 처리 회로(710)에 통신 가능하게 연결된 인터페이스 회로(730)를 포함하며, 처리 회로(710)는,
    송신 장치로부터 수신 장치(600)를 위해 의도된 패킷을 수신하고;
    프록시 서버(700)가 패킷을 나중에 수신 장치(600)로 전달할 것임을 나타내는 약속 프레임(300)을 수신 장치(600)로 송신하고;
    수신 장치(600)로부터의 패킷의 확인 응답을 송신 장치로 포워딩하며;
    확인 응답을 송신 장치로 포워딩한 후 패킷을 수신 장치(600)로 전달하도록 구성되는, 프록시 서버(700).
  26. 제 25 항에 있어서,
    처리 회로는 제 12 항 내지 제 20 항 중 어느 한 항의 방법을 수행하도록 더 구성되는, 프록시 서버(700).
  27. 프록시 서버(700)에 있어서,
    송신 장치로부터 수신 장치(600)를 위해 의도된 패킷을 수신하고;
    프록시 서버(700)가 패킷을 나중에 수신 장치(600)로 전달할 것임을 나타내는 약속 프레임(300)을 수신 장치(600)로 송신하고;
    수신 장치(600)로부터의 패킷의 확인 응답을 송신 장치로 포워딩하며;
    확인 응답을 송신 장치로 포워딩한 후 패킷을 수신 장치(600)로 전달하도록 구성되는, 프록시 서버(700).
  28. 제 27 항에 있어서,
    제 12 항 내지 제 20 항 중 어느 한 항의 방법을 수행하도록 더 구성되는, 프록시 서버(700).
  29. 컴퓨터 프로그램(660, 760)으로서,
    장치의 처리 회로(610, 710) 상에서 실행될 때, 처리 회로(610, 710)가 제 1 항 내지 제 28 항 중 어느 한 항에 따른 방법(800, 850)을 수행하게 하는 명령어를 포함하는, 컴퓨터 프로그램(660, 760).
  30. 제 29 항의 컴퓨터 프로그램(660, 760)을 포함하는 캐리어로서,
    전자 신호, 광학 신호, 무선 신호, 또는 컴퓨터 판독 가능한 저장 매체 중 하나인, 캐리어.
KR1020227001799A 2019-07-03 2020-06-25 네트워크 트래픽 관리의 개선을 위한 패킷 확인 응답 기술 KR102654182B1 (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201962870119P 2019-07-03 2019-07-03
US62/870,119 2019-07-03
PCT/EP2020/067816 WO2021001250A1 (en) 2019-07-03 2020-06-25 Packet acknowledgement techniques for improved network traffic management

Publications (2)

Publication Number Publication Date
KR20220024697A true KR20220024697A (ko) 2022-03-03
KR102654182B1 KR102654182B1 (ko) 2024-04-02

Family

ID=71170594

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020227001799A KR102654182B1 (ko) 2019-07-03 2020-06-25 네트워크 트래픽 관리의 개선을 위한 패킷 확인 응답 기술

Country Status (5)

Country Link
US (1) US20220360644A1 (ko)
EP (1) EP3994862B1 (ko)
KR (1) KR102654182B1 (ko)
CO (1) CO2022000228A2 (ko)
WO (1) WO2021001250A1 (ko)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116888948A (zh) * 2021-05-04 2023-10-13 华为技术有限公司 用于根据修改后的quic协议生成数据传输报文的数据传输控制器和方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120033579A1 (en) * 2008-07-17 2012-02-09 Huawei Technologies Co., Ltd. Data transmission method and apparatus
US20140189093A1 (en) * 2012-12-29 2014-07-03 Netronome Systems, Inc. Efficient intercept of connection-based transport layer connections
US20170026483A1 (en) * 2015-07-24 2017-01-26 Canon Kabushiki Kaisha Methods, devices and computer programs enabling data to be pushed in a network environment comprising proxies

Family Cites Families (44)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5537533A (en) * 1994-08-11 1996-07-16 Miralink Corporation System and method for remote mirroring of digital data from a primary network server to a remote network server
US6359882B1 (en) * 1997-04-01 2002-03-19 Yipes Communications, Inc. Method and apparatus for transmitting data
US6496481B1 (en) * 1998-07-16 2002-12-17 Industrial Technology Research Institute Data transfer method for wire real-time communications
US7181623B2 (en) * 2000-03-28 2007-02-20 University Of Maryland Scalable wide-area upload system and method
US7072979B1 (en) * 2000-06-28 2006-07-04 Cisco Technology, Inc. Wide area load balancing of web traffic
GB0018119D0 (en) * 2000-07-24 2000-09-13 Nokia Networks Oy Flow control
JP3377994B2 (ja) * 2000-11-14 2003-02-17 三菱電機株式会社 データ配信管理装置およびデータ配信管理方法
US8516054B2 (en) * 2000-12-20 2013-08-20 Aurea Software, Inc. Message handling
WO2002093867A2 (en) * 2001-05-16 2002-11-21 Bytemobile, Inc. Service-based compression of content within a network communication system
US20040033806A1 (en) * 2002-08-16 2004-02-19 Cellglide Technologies Corp. Packet data traffic management system for mobile data networks
EP1588526A1 (en) * 2003-01-28 2005-10-26 Telefonaktiebolaget LM Ericsson (publ) Method and device for congestion notification in packet networks indicating several different congestion causes
US8238241B2 (en) * 2003-07-29 2012-08-07 Citrix Systems, Inc. Automatic detection and window virtualization for flow control
US7698453B2 (en) * 2003-07-29 2010-04-13 Oribital Data Corporation Early generation of acknowledgements for flow control
US9219579B2 (en) * 2004-07-23 2015-12-22 Citrix Systems, Inc. Systems and methods for client-side application-aware prioritization of network communications
US7480301B2 (en) * 2004-12-16 2009-01-20 International Business Machines Corporation Method, system and article for improved TCP performance during retransmission in response to selective acknowledgement
US8073118B2 (en) * 2005-02-03 2011-12-06 Vonage Network Llc Providing effective advertising via synchronized telephone and data streams
JP4627669B2 (ja) * 2005-03-16 2011-02-09 アラクサラネットワークス株式会社 パケット転送装置およびその転送制御方式
US20080304481A1 (en) * 2005-07-12 2008-12-11 Paul Thomas Gurney System and Method of Offloading Protocol Functions
US20150117462A1 (en) * 2006-01-31 2015-04-30 Sigma Designs, Inc. Method for encapsulating a message
AU2007210948A1 (en) * 2006-02-01 2007-08-09 Bob Tang Immediate ready implementation of virtually congestion free guaranteed service capable network: external internet NextGenTCP NextGenFTP NextGenUDPs
US8463843B2 (en) * 2006-05-26 2013-06-11 Riverbed Technology, Inc. Throttling of predictive ACKs in an accelerated network communication system
US9270944B2 (en) * 2007-02-14 2016-02-23 Time Warner Cable Enterprises Llc Methods and apparatus for content delivery notification and management
US8891388B2 (en) * 2008-12-08 2014-11-18 Zte Corporation Path node determining method, media path establishing method, and signaling media gateway
US8248942B2 (en) * 2009-01-27 2012-08-21 Cisco Technology, Inc. Monitoring of real-time transport protocol (RTP) packet flow along RTP path
CA2785842A1 (en) * 2009-12-31 2011-07-07 Bce Inc. Method and system for increasing performance of transmission control protocol sessions in data networks
US8745204B2 (en) * 2010-03-12 2014-06-03 Cisco Technology, Inc. Minimizing latency in live virtual server migration
US8626893B2 (en) * 2010-06-17 2014-01-07 Interdigital Patent Holdings, Inc. Application layer protocol support for sleeping nodes in constrained networks
GB2485765B (en) * 2010-11-16 2014-02-12 Canon Kk Client based congestion control mechanism
FR2971662B1 (fr) * 2011-02-10 2013-03-15 Commissariat Energie Atomique Methode de communication asynchrone pour reseau de capteurs sans fil
US8773976B1 (en) * 2011-03-03 2014-07-08 Sprint Spectrum L.P. Method and system for communication acknowledgement
US20130223364A1 (en) * 2012-02-24 2013-08-29 Qualcomm Incorporated Ack channel design for early termination of r99 uplink traffic
US20130250853A1 (en) * 2012-03-20 2013-09-26 Qualcomm Incorporated Methods and apparatuses to improve round trip time in transfer control protocol using accelerated acknowledgement messages
US9887925B2 (en) * 2013-03-04 2018-02-06 Gilat Satellite Networks Ltd. Network performance enhancement
JP2014192811A (ja) * 2013-03-28 2014-10-06 Fujitsu Ltd 中継装置及び通信方法
US20150019620A1 (en) * 2013-07-09 2015-01-15 Kaminario Technologies Ltd. High availability for communications based on remote procedure calls
KR102264477B1 (ko) * 2013-07-12 2021-06-15 캐논 가부시끼가이샤 푸시 메시지 제어를 이용하는 적응적 데이터 스트리밍 방법
US10516617B2 (en) * 2014-11-10 2019-12-24 APS Technology 1 LLC Network throughput
JP6436853B2 (ja) * 2015-05-25 2018-12-12 キヤノン株式会社 通信装置、通信方法、及びプログラム
JP6584171B2 (ja) * 2015-07-02 2019-10-02 キヤノン株式会社 通信装置、通信方法及びプログラム
US9967077B2 (en) * 2015-10-22 2018-05-08 Harris Corporation Communications device serving as transmission control protocol (TCP) proxy
US10425344B2 (en) * 2015-12-18 2019-09-24 Avago Technologies International Sales Pte. Limited Avoiding dropped data packets on a network transmission
KR102658608B1 (ko) * 2017-01-20 2024-04-19 삼성전자 주식회사 Vr 컨텐츠의 생성 방법 및 장치
US10330784B2 (en) * 2017-04-07 2019-06-25 Qualcomm Incorporated Secure range determination protocol
US20190199835A1 (en) * 2018-11-28 2019-06-27 Manasi Deval Quick user datagram protocol (udp) internet connections (quic) packet offloading

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120033579A1 (en) * 2008-07-17 2012-02-09 Huawei Technologies Co., Ltd. Data transmission method and apparatus
US20140189093A1 (en) * 2012-12-29 2014-07-03 Netronome Systems, Inc. Efficient intercept of connection-based transport layer connections
US20170026483A1 (en) * 2015-07-24 2017-01-26 Canon Kabushiki Kaisha Methods, devices and computer programs enabling data to be pushed in a network environment comprising proxies

Also Published As

Publication number Publication date
EP3994862A1 (en) 2022-05-11
US20220360644A1 (en) 2022-11-10
CO2022000228A2 (es) 2022-04-29
WO2021001250A1 (en) 2021-01-07
EP3994862B1 (en) 2023-08-16
KR102654182B1 (ko) 2024-04-02

Similar Documents

Publication Publication Date Title
US10694005B2 (en) Hardware-based packet forwarding for the transport layer
US10616379B2 (en) Seamless mobility and session continuity with TCP mobility option
Kumar et al. Implementation and analysis of QUIC for MQTT
US9509663B2 (en) Secure distribution of session credentials from client-side to server-side traffic management devices
CN106716951B (zh) 用于优化隧道流量的方法和装置
US20180288179A1 (en) Proxy for serving internet-of-things (iot) devices
US9027129B1 (en) Techniques for protecting against denial of service attacks
US10897509B2 (en) Dynamic detection of inactive virtual private network clients
US7684414B2 (en) System and method for using performance enhancing proxies with IP-layer encryptors
CN110875799A (zh) 一种传输控制方法和装置
US20150373135A1 (en) Wide area network optimization
US11777915B2 (en) Adaptive control of secure sockets layer proxy
KR102654182B1 (ko) 네트워크 트래픽 관리의 개선을 위한 패킷 확인 응답 기술
WO2021208088A1 (en) Method and apparatus for security communication
Seggelmann Sctp: Strategies to secure end-to-end communication
US20230379150A1 (en) Methods and apparatuses for providing communication between a server and a client device via a proxy node
WO2023159346A1 (en) Communication devices and methods therein for facilitating ipsec communications
WO2024092655A1 (en) Method and communication device for communication using ipsec
US20220338095A1 (en) Base station assisted information centric network
Thornburgh RFC 7016: Adobe's Secure Real-Time Media Flow Protocol
Ganiga et al. A Detailed Study of Transport Layer SCT Protocol and its Security Solutions

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