KR102612711B1

KR102612711B1 - 네트워크 기반 서비스들을 위한 파이어 앤 포겟 오프로드 메커니즘

Info

Publication number: KR102612711B1
Application number: KR1020217040983A
Authority: KR
Inventors: 앙투안 진 지르발
Original assignee: 넷플릭스, 인크.
Priority date: 2019-05-17
Filing date: 2020-05-15
Publication date: 2023-12-13
Also published as: AU2020279111A1; SG11202112793TA; JP2022531940A; US20200366761A1; EP3970347A1; BR112021023051A2; AU2020279111B2; US11212368B2; JP7344315B2; KR20220007696A; WO2020236650A1; CA3139917A1; CN113841373A; US20220124173A1; MX2021014020A

Abstract

다양한 실시예들에서는, 프록시 애플리케이션이 네트워크 기반 서비스와 연관된 요청들을 처리한다. 동작 중에, 상기 프록시 애플리케이션은 클라이언트 애플리케이션으로부터 수신된 제1 요청이 서버 머신으로부터 상기 제1 요청에 대한 응답이 오프로딩될 수 있음을 지시한다고 결정한다. 상기 프록시 애플리케이션은, 상기 제1 요청을 상기 서버 머신에 송신하기 전에, 상기 제1 요청에 대한 응답을 상기 클라이언트 애플리케이션에 송신한다. 상기 응답은 상기 서버 머신이 상기 제1 요청을 성공적으로 처리했음을 지시한다. 유리하게는, 상기 클라이언트 애플리케이션은, 상기 응답을 수신하면, 상기 서버 머신에 관계없이 제2 요청을 개시할 수 있다.

Description

네트워크 기반 서비스들을 위한 파이어 앤 포겟 오프로드 메커니즘

관련 출원들에 대한 상호 참조

본 출원은 2019년 5월 17일자로 출원된 미국 특허 출원 일련 번호 제16/416,108호의 이익을 주장하고, 해당 출원은 이로써 인용에 의해 본 명세서에 포함된다.

본 발명의 실시예들은 일반적으로 클라이언트-서버 아키텍처들에 관한 것으로, 보다 구체적으로는, 네트워크 기반 서비스들을 위한 파이어 앤 포겟 오프로드 메커니즘에 관한 것이다.

많은 클라이언트 애플리케이션들은 TCP(Transmission Control Protocol)를 통한 버전 1.0 또는 1.1("1.x")의 HTTP(Hypertext Transfer Protocol)를 이용하여 네트워크 기반 서비스들에 액세스한다. 그렇게 함에 있어서, 클라이언트 애플리케이션은 클라이언트 애플리케이션과 네트워크 기반 서비스 간에 TCP 연결(들)을 통해 송신되는 HTTP 트랜잭션들을 통해 네트워크 기반 서비스와 상호작용한다. 전형적인 클라이언트 애플리케이션은 비교적 적은 수의 interactive HTTP 트랜잭션들 및 비교적 많은 수의 informational HTTP 트랜잭션들을 개시한다. interactive HTTP 트랜잭션에서는, 클라이언트 애플리케이션이 클라이언트 애플리케이션과 상호작용하고 있는 사용자에게 제공될 필요가 있는 데이터, 예컨대 홈페이지에 대한 디스플레이 정보를 다운로드한다. informational HTTP 트랜잭션에서는, 클라이언트 애플리케이션이 네트워크 기반 서비스가 정보 제공 목적으로 사용하는 하나 이상의 서버 머신에 데이터를 업로드한다. 예를 들어, 클라이언트 애플리케이션은 이벤트 로그들(event logs), 클라이언트 애플리케이션의 성능을 지시하는 메트릭 로그들(metric logs), 및/또는 클라이언트 애플리케이션이 적절하게 실행중임을 지시하는 "하트비트들(heartbeats)"을 업로드할 수 있다.

TCP를 통한 HTTP/1.x(HTTP/1.x over TCP)를 이용하는 것에 대한 하나의 단점은 informational HTTP 트랜잭션들의 양(volumn)이 주어진 클라이언트 애플리케이션과 연관된 interactive HTTP 트랜잭션들의 송신 및 처리를 크게 지연시킬 수 있다는 점이다. TCP를 통한 HTTP/1.x에서는, 각각의 HTTP 트랜잭션이 전용 TCP 연결을 필요로 한다. 또한, 클라이언트 애플리케이션들이 실행되는 클라이언트 플랫폼들은 종종 동시 TCP 연결들의 수를 2개 내지 6개의 연결로 제한한다. 그리고, 잘 이해되는 바와 같이, 업로드 속도가 보통 다운로드 속도보다 느리다. 결과적으로, 다양한 시점들에서, 이용가능한 TCP 연결들 모두가 informational HTTP 트랜잭션에만 할당될 수 있다. 임의의 계류중인 interactive HTTP 트랜잭션은, HTTP 트랜잭션의 비교적 느린 업로드 부분을 포함하여, informational HTTP 트랜잭션들 중 하나가 완료될 때까지 기다려야 한다. 계류중인 interactive HTTP 트랜잭션과 연관된 데이터를 다운로드하는 데 있어서의 결과적인 지연은 전반적인 사용자 경험의 저하를 야기할 수 있다.

위의 문제들을 해결하기 위한 노력으로, 일부 클라이언트 애플리케이션들은 이용가능한 TCP 연결들 중 적어도 하나를 informational HTTP 트랜잭션들에 할당하는 반면, 다른 TCP 연결들은 interactive HTTP 트랜잭션들에 할당한다. 그러나, 이러한 접근법에 의하면, interactive HTTP 트랜잭션들이 이용할 수 있는 TCP 연결들의 수가 informational HTTP 트랜잭션들의 실제 양과 관계없이 자동으로 감소된다. interactive HTTP 트랜잭션들의 양이 비교적 적은 경우, 그러한 감소는 바람직하지 않을 수 있다. 또한, informational HTTP 트랜잭션들에 할당된 TCP 연결(들)의 용량이 초과되면, 클라이언트 애플리케이션은 결국 informational HTTP 트랜잭션들을 통해 네트워크 기반 서비스에 송신되는 정보를 드롭(drop)하게 될 수 있다.

위의 문제들을 해결하기 위한 다른 접근법에서는, 일부 클라이언트 애플리케이션들이 HTTP/2를 구현하는데, 여기서는 다수의 HTTP 트랜잭션들이 각각의 TCP 연결을 통해 다중 송신될 수 있다. 클라이언트 애플리케이션이 HTTP/2를 구현할 때 각각의 TCP 연결을 통해 임의의 수의 informational HTTP 트랜잭션들과 동시에 임의의 수의 interactive HTTP 트랜잭션들을 개시할 수 있기 때문에, 하나 이상의 interactive HTTP 트랜잭션을 통해 사용자에게 제공될 필요가 있는 데이터를 다운로드하는 데 있어서의 지연이 감소될 수 있다. 그러나, 일부 클라이언트 플랫폼들은 HTTP/2를 지원하지 않고, 이는 이러한 해결 방안의 효능을 감소시킨다.

전술한 내용이 예시하는 바와 같이, 본 기술분야에서 필요한 것은 네트워크 기반 서비스들과 연관된 요청들을 처리하기 위한 보다 효과적인 기법들이다.

본 발명의 일 실시예는 네트워크 기반 서비스와 연관된 요청들을 처리하기 위한 컴퓨터 구현 방법을 설명한다. 이 방법은 클라이언트 애플리케이션으로부터 수신된 제1 요청이 서버 머신으로부터 상기 제1 요청에 대한 응답이 오프로딩될 수 있음을 지시한다고 결정하는 단계; 및 상기 제1 요청을 상기 서버 머신에 송신하기 전에, 상기 서버 머신이 상기 제1 요청을 성공적으로 처리했음을 지시하는 상기 제1 요청에 대한 제1 응답을 상기 클라이언트 애플리케이션에 송신하는 단계를 포함하고, 상기 클라이언트 애플리케이션은, 상기 제1 응답을 수신하면, 제2 요청을 개시할 수 있다.

종래 기술에 비해 개시된 기법들의 적어도 하나의 기술적 이점은, 개시된 기법들에 의하면, TCP를 통한 HTTP/1.x를 구현하는 클라이언트 애플리케이션에 대해 interactive HTTP 트랜잭션들이 informational HTTP 트랜잭션들에 의해 지연될 가능성이 적다는 점이다. 특히, 프록시 서버가 클라이언트 애플리케이션으로부터 송신된 informational HTTP 트랜잭션에 응답하자마자, 클라이언트 애플리케이션은 백-엔드 서버로부터의 응답을 기다릴 필요 없이 연관된 TCP 연결을 폐쇄 또는 재사용할 수 있다. 따라서, 클라이언트 애플리케이션이 모든 이용가능한 TCP 연결들을 informational HTTP 트랜잭션들을 위해 이용하고 interactive HTTP 트랜잭션들의 송신 및 처리를 지연시킬 가능성이 적다. 이들 기술적 이점은 종래 기술의 접근법들에 비해 하나 이상의 기술 진보를 나타낸다.

위에 언급된 다양한 실시예들의 특징들이 상세하게 이해될 수 있도록, 다양한 실시예들을 참조하여, 위에 간략하게 요약된, 본 발명의 개념들에 대한 보다 상세한 설명을 할 수 있고, 그 실시예들 중 일부가 첨부 도면들에 예시되어 있다. 그러나, 첨부 도면들은 본 발명의 개념들의 전형적인 실시예들만을 예시하고 있으므로 어떤 식으로든 범위를 제한하는 것으로 간주되어서는 안 된다는 점, 그리고 다른 동등하게 효과적인 실시예들이 존재한다는 점에 유의해야 한다.
도 1은 본 발명의 하나 이상의 양태를 구현하도록 구성된 시스템에 대한 개념적 예시이다.
도 2는 본 발명의 다양한 실시예들에 따른, 동작 동안의 도 1의 가속 시스템들 중 하나의 가속 시스템에 대한 보다 상세한 예시이다.
도 3은 본 발명의 다양한 실시예들에 따른, 도 2의 프록시 애플리케이션에 대한 보다 상세한 예시이다.
도 4는 본 발명의 다양한 실시예들에 따른, 네트워크 기반 서비스와 연관된 요청을 처리하기 위한 방법 단계들의 흐름도이다.

이하의 설명에서는, 다양한 실시예들에 대한 보다 철저한 이해를 제공하기 위해 다수의 특정 상세들이 설명된다. 그러나, 본 기술분야의 기술자는 이들 특정 상세 중 하나 이상이 없이도 본 발명의 개념들이 실시될 수 있다는 것을 알 수 있을 것이다.

사용자들은 전형적으로 인터넷 연결된 클라이언트 디바이스들 상에서 실행중인 클라이언트 애플리케이션들을 통해 미디어 스트리밍 서비스와 상호작용한다. 예를 들어, 스마트 텔레비전 상에서 실행중인 클라이언트 애플리케이션이 사용자들이 미디어 스트리밍 서비스에 의해 제공되는 미디어 콘텐츠를 브라우징, 검색, 선택, 다운로드, 및 스트리밍할 수 있게 할 수 있다. 많은 클라이언트 애플리케이션은 TCP를 통한 HTTP/1.x를 이용하여 미디어 스트리밍 서비스에 액세스한다. 그렇게 함에 있어서, 클라이언트 애플리케이션은 HTTP 트랜잭션들을 통해 미디어 스트리밍 서비스와 상호작용한다. 전형적인 클라이언트 애플리케이션은 비교적 적은 수의 interactive HTTP 트랜잭션들 및 비교적 많은 수의 informational HTTP 트랜잭션들을 개시한다. interactive HTTP 트랜잭션에서는, 클라이언트 애플리케이션이 클라이언트 애플리케이션과 상호작용하고 있는 사용자에게 제공될 필요가 있는 데이터, 예컨대 홈페이지에 대한 디스플레이 정보를 다운로드한다. informational HTTP 트랜잭션에서는, 클라이언트 애플리케이션이 미디어 스트리밍 서비스가 정보 제공 목적으로 사용하는 하나 이상의 서버 머신에 데이터를 업로드한다. 예를 들어, 클라이언트 애플리케이션은 이벤트 로그들, 클라이언트 애플리케이션의 성능을 지시하는 메트릭 로그들, 및/또는 스트리밍 세션이 활성임을 지시하는 "하트비트들"을 업로드할 수 있다.

TCP를 통한 HTTP/1.x를 이용하는 것에 대한 하나의 단점은 informational HTTP 트랜잭션들의 양이 주어진 클라이언트 애플리케이션과 연관된 interactive HTTP 트랜잭션들의 송신 및 처리를 크게 지연시킬 수 있다는 점이다. TCP를 통한 HTTP/1.x에서는, 각각의 HTTP 트랜잭션이 전용 TCP 연결을 필요로 한다. 또한, 클라이언트 애플리케이션들이 실행되는 클라이언트 플랫폼들은 종종 동시 TCP 연결들의 수를 2개 내지 6개의 연결로 제한한다. 그리고, 잘 이해되는 바와 같이, 업로드 속도가 보통 다운로드 속도보다 느리다. 예를 들어, ISP(Internet Service Provider)는 최대 5 Mbps(Megabits per second)의 업로드 속도 대 최대 250 Mbps의 다운로드 속도를 갖는 서비스의 계층을 제공할 수 있다. 결과적으로, 다양한 시점들에서, 이용가능한 TCP 연결들 모두가 informational HTTP 트랜잭션에만 할당될 수 있다. 임의의 계류중인 interactive HTTP 트랜잭션은, HTTP 트랜잭션의 비교적 느린 업로드 부분을 포함하여, informational HTTP 트랜잭션들 중 하나가 완료될 때까지 기다려야 한다. 계류중인 interactive HTTP 트랜잭션과 연관된 데이터를 다운로드하는 데 있어서의 결과적인 지연은 전반적인 사용자 경험의 저하를 야기할 수 있다. 예를 들어, 사용자는, 선택된 비디오와 연관된 정보를 보기 위해 50 밀리초를 기다리는 대신에, 1초를 기다릴 수 있다.

그러나, 개시된 기법들에 의하면, TCP를 통한 HTTP/1.x를 구현하는 클라이언트 애플리케이션들에 대해 interactive HTTP 트랜잭션들이 informational HTTP 트랜잭션들에 의해 지연될 가능성이 적다. 일 실시예에서는, 하나 이상의 클라이언트 애플리케이션과 미디어 스트리밍 서비스를 제공하는 백-엔드 서버 간의 중개자의 역할을 하는 프록시 서버 상에서 프록시 애플리케이션이 실행된다. 프록시 서버와 백-엔드 서버는 HTTP/2 over TCP를 통해 통신하는데, 여기서는 다수의 HTTP 트랜잭션들이 각각의 TCP 연결을 통해 다중 송신될 수 있다.

일부 실시예들에서는, 클라이언트 애플리케이션이 informational HTTP 트랜잭션을 개시하는 각각의 요청에 "파이어 앤 포겟(fire-and-forget)" 헤더를 추가한다. 프록시 애플리케이션은, 요청을 수신하면, 요청이 파이어 앤 포겟 헤더를 포함하는지 여부에 기초하여 요청에 대해 오프로딩을 활성화할지를 결정한다. 프록시 애플리케이션이 요청에 대해 오프로딩을 활성화하면, 프록시 애플리케이션은 요청을 백-엔드 서버에 송신하기 전에 성공적인 일반 응답(successful generic response)을 클라이언트 애플리케이션에 송신한다. 성공적인 일반 응답은 백-엔드 서버가 요청을 성공적으로 처리했음을 의도적으로 그리고 잘못되게 지시한다. 요청에 대해 오프로딩이 활성인지 여부에 관계없이, 프록시 애플리케이션은 요청을 백-엔드 서버에 송신한다. 오프로딩이 활성이면, 프록시 애플리케이션은 백-엔드 서버로부터 수신된 응답을 폐기한다. 그렇지 않으면, 프록시 애플리케이션은 백-엔드 서버로부터 수신된 응답을 클라이언트 애플리케이션에 송신한다.

종래 기술에 비해 개시된 기법들의 적어도 하나의 기술적 이점은, 개시된 기법들에 의하면, TCP를 통한 HTTP/1.x를 구현하는 클라이언트 애플리케이션에 대해 interactive HTTP 트랜잭션들이 informational HTTP 트랜잭션들에 의해 지연될 가능성이 적다는 점이다. 특히, 프록시 서버가 클라이언트 애플리케이션으로부터 송신된 informational HTTP 트랜잭션에 응답하자마자, 클라이언트 애플리케이션은 백-엔드 서버로부터의 응답을 기다릴 필요 없이 연관된 TCP 연결을 폐쇄 또는 재사용할 수 있다. 따라서, 클라이언트 애플리케이션이 모든 이용가능한 TCP 연결들을 informational HTTP 트랜잭션들을 위해 이용하고 interactive HTTP 트랜잭션들의 송신 및 처리를 지연시킬 가능성이 적다. 그 결과, 클라이언트 애플리케이션을 통해 미디어 스트리밍 서비스에 의해 제공되는 전형적인 사용자 경험이 개선된다. 이들 기술적 이점은 종래 기술의 접근법들에 비해 하나 이상의 기술 진보를 나타낸다.

시스템 개관

도 1은 본 발명의 하나 이상의 양태를 구현하도록 구성된 시스템(100)에 대한 개념적 예시이다. 도시된 바와 같이, 시스템(100)은 네트워크 기반 서비스 시스템(102), 임의의 수의 클라이언트 디바이스들(104), 및 임의의 수의 가속 시스템들(106)을 제한 없이 포함한다. 설명 목적으로, 유사한 대상들의 다수의 인스턴스들이 대상을 식별하는 참조 번호들 및 필요한 경우 해당 인스턴스를 식별하는 괄호 번호들로 표시된다.

네트워크 기반 서비스 시스템(102), 클라이언트 디바이스들(104), 및 가속 시스템들(106)은 통신 네트워크(도시되지 않음)를 통해 통신한다. 통신 네트워크는 데이터 통신을 용이하게 하도록 구성된 복수의 네트워크 통신 시스템, 예컨대 라우터들 및 스위치들을 포함한다. 본 기술분야의 기술자들은, 잘 알려진 인터넷 통신 네트워크를 배치하는 데 실시되는 기술들을 포함하여, 통신 네트워크를 구축하기 위한 많은 기술적으로 실현가능한 기법들이 존재한다는 것을 인식할 것이다.

네트워크 기반 서비스 시스템(102)은 전세계에 걸쳐 분산되어 있고 네트워크 기반 서비스(예를 들어, 스트리밍 미디어 서비스)와 연관된 데이터를 수신, 송신, 처리, 및/또는 저장하는 상호연결된 노드들의 네트워크를 제한 없이 포함한다. 상호연결된 노드들은 이들 원하는 기능을 수행하기 위한 소프트웨어, 펌웨어, 및 하드웨어의 임의의 적합한 조합을 포함할 수 있다. 특히, 네트워크 기반 서비스 시스템(102)은 공동 위치하거나 서로 물리적으로 분산될 수 있는 다수의 컴퓨팅 디바이스들을 포함한다. 예를 들어, 이들 컴퓨팅 디바이스는 하나 이상의 범용 PC, 매킨토시, 워크스테이션, 리눅스 기반 컴퓨터, 서버 컴퓨터, 하나 이상의 서버 풀, 또는 임의의 다른 적합한 디바이스를 포함할 수 있다. 컴퓨팅 디바이스들은 임의의 기술적으로 실현가능한 방식으로, 예컨대 대응하는 애플리케이션 프로그래밍 인터페이스들("API들")을 통해 원격으로 액세스할 수 있는 하나 이상의 프로그램을 저장 및 실행한다. 다양한 실시예들에서는, 임의의 수의 컴퓨팅 디바이스들이 하나 이상의 클라우드 컴퓨팅 환경들(즉, 캡슐화된 공유 리소스들, 소프트웨어, 데이터 등)에서 구현될 수 있다.

각각의 클라이언트 디바이스(104)는 소프트웨어 애플리케이션들을 실행하고 통신 네트워크를 통해 다른 디바이스들과 통신할 수 있는 임의의 유형의 디바이스일 수 있다. 예를 들어, 클라이언트 디바이스(104(1))는 태블릿, 셋톱 박스, 스마트 텔레비전, 게임 콘솔, 스트리밍 미디어 플레이어, 스마트폰과 같은 모바일 디바이스 등일 수 있다. 클라이언트 디바이스들(104)은 임의의 수의 물리적 위치들에 걸쳐 분산될 수 있다. 클라이언트 디바이스들(104) 각각은 임의의 적절한 입력 디바이스들(예컨대 키패드, 터치 스크린, 마우스, 또는 정보를 수용할 수 있는 다른 디바이스), 출력 디바이스들, 대용량 스토리지 매체, 또는 데이터를 수신, 처리, 저장, 및 통신하기 위한 다른 적합한 컴포넌트들을 포함할 수 있다. 입력 디바이스 및 출력 디바이스 둘 다는 자기 컴퓨터 디스크, CD-ROM과 같은 고정식 또는 이동식 스토리지 매체를 포함할 수 있다. 각각의 클라이언트 디바이스(104)는 임의의 수의 프로세서들 및 임의의 수의 메모리들을 임의의 조합으로 제한 없이 포함할 수 있다. 임의의 수의 클라이언트 디바이스들(104)이 임의의 기술적으로 실현가능한 방식으로 멀티프로세싱 환경을 제공할 수 있다.

각각의 클라이언트 디바이스(104)는 특정 동작들을 위해 네트워크 기반 서비스 시스템(102)에 의존하는 컴퓨터 하드웨어 및/또는 컴퓨터 소프트웨어를 포함한다. 특히, 각각의 클라이언트 디바이스(104)는 각각이 임의의 수의 소프트웨어 애플리케이션들을 실행하는 임의의 수의 클라이언트 플랫폼들을 포함할 수 있다. 클라이언트 플랫폼들의 예들은 웹 브라우저들, 스마트 텔레비전 운영 체제(OS)들, 휴대폰 OS들, 비디오 게임 콘솔 OS들 등을 제한 없이 포함한다. 다양한 동작들을 수행하기 위해 통신 네트워크를 통해 네트워크 기반 서비스 시스템(102)과 통신하는 소프트웨어 애플리케이션들은 본 명세서에서 "클라이언트 애플리케이션들"이라고 지칭된다.

일부 실시예들에서는, 클라이언트 애플리케이션이 네트워크 기반 서비스 시스템(102)에 요청들을 발행함으로써 동작한다. 클라이언트 디바이스(104)는 네트워크 기반 서비스 시스템(102)과의 네트워크 연결을 확립하고 이어서 해당 네트워크 연결을 통해 네트워크 기반 서비스 시스템(102)에 요청을 송신한다. 네트워크 기반 서비스 시스템(102)은, 요청을 수신하는 것에 응답하여, 요청을 처리하고 네트워크 연결을 통해 클라이언트 애플리케이션에 역으로 송신되는 응답을 생성한다. 요청을 발행하고 대응하는 응답을 수신하는 프로세스는 본 명세서에서 "트랜잭션"이라고 지칭된다. 클라이언트(104) 상에서 실행중인 클라이언트 애플리케이션과, 요청을 처리하는 네트워크 기반 서비스 시스템(102)의 부분 사이의 왕복(round trip)은 본 명세서에서 트랜잭션 왕복이라고 지칭된다. 일반적으로, 클라이언트(104)가 요청을 처리하는 네트워크 기반 서비스 시스템(102)의 부분으로부터 멀수록, 트랜잭션 왕복의 지연이 커진다. 또한, 네트워크 연결의 혼잡이 클수록, 트랜잭션 왕복의 지연이 커진다.

가속 시스템들(106)은 트랜잭션 왕복 지연들을 감소시키기 위해 네트워크 기반 서비스 시스템(102)과 클라이언트 디바이스들(104) 간의 중개자로서 동작한다. 가속 시스템들(106)은 전세계에 걸쳐 분산되어 있는 그리고 각각이 클라이언트 디바이스들(104)과 네트워크 기반 서비스 시스템(102) 간의 중개자로서 동작하는 상호연결된 시스템들의 네트워크를 포함한다. 주어진 가속 시스템(106)이 주어진 클라이언트 디바이스(104)와의 네트워크 연결을 확립하고 해당 연결을 통해 요청을 수신한다. 가속 시스템(106)은 네트워크 기반 서비스 시스템(102)과의 네트워크 연결을 통해 요청의 처리를 용이하게 한다.

다양한 실시예들에서는, 임의의 수의 가속 시스템들(106)이 ISP(Internet Service Provider)와 연관된 네트워크 내에 임베딩될 수 있다. 일부 그러한 실시예들에서는, 가속 시스템(106(x))이 ISP와 연관된 네트워크 내에 임베딩되어 있다면, 가속 시스템(106(x))은 ISP와 연관되어 있는 그리고/또는 ISP에 가입하는 클라이언트 디바이스들(104)만 액세스할 수 있다. 동일한 또는 다른 실시예들에서는, 임의의 수의 가속 시스템들(106)이 인터넷 익스체인지 포인트(Internet exchange point) 내에서 또는 그와 연관하여 그리고 ISP와 독립적으로 동작할 수 있다. 인터넷 익스체인지 포인트는 그를 통해 ISP들 및 CDN(content delivery network)들이 인터넷 트래픽을 교환하는 물리적 인프라이다.

가속 시스템(106)이 네트워크 기반 서비스 시스템(102)과 클라이언트 디바이스(104) 간의 중개자로서 동작할 때, 다음과 같은 적어도 2가지 이유로 트랜잭션들을 실행하기 위해 요구되는 시간이 감소된다. 첫째, 일부 실시예들에서는, 가속 시스템(106)이 일반적으로 네트워크 기반 서비스 시스템(102)에 비해 클라이언트 디바이스(104)에 물리적으로 더 가깝다. 따라서, 클라이언트 디바이스(104)와 가속 시스템(106) 간에 네트워크 연결을 확립하기 위해 필요한 임의의 왕복 시간들이 클라이언트 디바이스(104)와 네트워크 기반 서비스 시스템(102) 간에 네트워크 연결이 확립될 필요가 있는 경우에 비해 더 짧다. 둘째, 일부 실시예들에서는, 가속 시스템(106)이 다수의 클라이언트 디바이스들(104)로부터 발신되는 많은 양의 요청들을 가지고 있음으로 인해, 가속 시스템(106)은 네트워크 기반 서비스 시스템(102)과의 일관되고, 미리 확립되고, 미리 인증된 네트워크 연결을 갖는다. 따라서, 각각의 요청에 대해 네트워크 기반 서비스 시스템(102)과의 네트워크 연결이 확립되고 인증될 필요가 없다.

본 명세서에 도시된 시스템(100)은 예시적인 것이고 변형들 및 수정들이 가능하다는 것을 알 것이다. 예를 들어, 시스템(100)의 다양한 컴포넌트들 간의 연결 토폴로지는 원하는 대로 수정될 수 있다. 본 명세서에 기술된 기법들은 제한적인 것이 아니라 예시적인 것이고, 본 발명의 더 넓은 사상 및 범위를 벗어나지 않고 변경될 수 있다는 점에 유의한다. 다양한 실시예들에서는, 본 명세서에 개시된 임의의 수의 기법들이 구현될 수 있는 반면, 다른 기법들이 임의의 기술적으로 실현가능한 방식으로 생략될 수 있다.

단지 설명 목적으로, 도 2 내지 도 4는 TCP 연결들 및 HTTP 프로토콜의 특정 버전들의 컨텍스트에서 시스템(100)의 기능성을 기술하고 있다. 그러나, 본 명세서에 기술된 기법들은 제한적인 것이 아니라 예시적인 것이고, 본 발명의 더 넓은 사상 및 범위를 벗어나지 않고 변경될 수 있다. 본 기술분야의 통상의 기술자들은 기술된 실시예들 및 기법들의 범위 및 사상을 벗어나지 않고 많은 수정들 및 변형들을 알 수 있을 것이다.

도 2는 본 발명의 다양한 실시예들에 따른, 동작 동안의 도 1의 가속 시스템들(106) 중 하나의 가속 시스템에 대한 보다 상세한 예시이다. 보다 정확하게는, 도 2는 임의의 수의 클라이언트 디바이스들(104(1)-104(N)) 상에서 실행중인 임의의 수의 클라이언트 애플리케이션들(220(1)-220(M))과, 가속 시스템(106(1))에 포함된 프록시 서버(240)와, 네트워크 기반 서비스 시스템(102)에 포함된 백-엔드 서버(270) 간의 상호작용들을 예시하고 있다.

백-엔드 서버(270)는 네트워크 기반 서비스 시스템(102)에 포함된 임의의 수의 컴퓨팅 디바이스를 제한 없이 포함한다. 컴퓨팅 디바이스들 각각은 네트워크 기반 서비스 시스템(102)에 대한 HTTP 요청들을 처리하고 그에 응답하는 임의의 수 및 유형의 소프트웨어 애플리케이션들을 실행할 수 있다.

프록시 서버(240)는 가속 시스템(106(1))에 포함된 컴퓨팅 디바이스이다. 대안의 실시예들에서는, 프록시 서버(240)가 가속 시스템(106(1))에 포함된 임의의 수의 컴퓨팅 디바이스들을 포함할 수 있다. 도시된 바와 같이, 클라이언트 디바이스들(104)과 프록시 서버(240)는 클라이언트/프록시 TCP 연결들(230)을 통한 HTTP/1.1을 이용하여 통신한다. 프록시 서버(240)와 백-엔드 서버(270)는 프록시/백-엔드 TCP 연결들(260)을 통한 HTTP/2를 이용하여 통신한다. 동작 중에, 프록시 서버(240)는 HTTP 트랜잭션들을 실행하기 위해 요구되는 시간을 감소시키기 위해 클라이언트 디바이스들(104(1)-104(N))과 백-엔드 서버(270) 간의 중개자의 역할을 한다. 프록시 서버(240)는 때때로 "역방향 프록시 서버(reverse proxy server)"라고 지칭된다.

프록시 서버(240)는 다음과 같은 적어도 3가지 이유로 HTTP 트랜잭션을 실행하기 위해 요구되는 시간을 감소시킨다. 첫째, 프록시 서버(240)는 일반적으로 백-엔드 서버(270)에 비해 클라이언트 디바이스들(104(1)-104(N))에 물리적으로 더 가깝다. 특히, 일부 실시예들에서는, 프록시 서버(240)가 클라이언트 디바이스들(104(1)-104(N))과 또한 연관되어 있는 ISP와 연관된 네트워크 내에 임베딩된다. 따라서, 클라이언트 디바이스(104)와 프록시 서버(240) 간에 네트워크 연결을 확립하기 위해 필요한 임의의 왕복 시간들이 클라이언트 디바이스(104)와 백-엔드 서버(270) 간에 네트워크 연결이 확립될 필요가 있는 경우에 비해 더 짧다. 둘째, 일부 실시예들에서는, 프록시 서버(240)가 다수의 클라이언트 디바이스들(104)로부터 발신되는 많은 양의 요청들을 가지고 있음으로 인해, 프록시 서버(240)는 백-엔드 서버(270)와의 임의의 수의 일관되고, 미리 확립되고, 미리 인증된 프록시/백-엔드 TCP 연결들(260)을 가진다. 따라서, 각각의 HTTP 요청에 대해 백-엔드 서버(270)와의 TCP 연결이 확립되고 인증될 필요가 없다.

셋째, 프록시 서버(240)와 백-엔드 서버(270)는 HTTP/2를 이용하여 통신한다. 잘 알려진 바와 같이, HTTP/2는 HTTP/1.x에 비해 매우 다양한 성능 개선을 구현한다. 특히, HTTP/2에서는 다수의 HTTP 트랜잭션이 각각의 연결(예를 들어, 프록시/백-엔드 TCP 연결(260(1)))을 통해 다중 송신된다. 따라서, 동시 HTTP 상호작용들의 수가 반드시 제한되는 것은 아니다. 일부 실시예들에서는, 프록시 서버(240)가 정상 동작 동안에는 도달할 가능성이 없는 동시성 한도(concurrency limit)를 확립한다. 예를 들어, 일부 실시예들에서는, 프록시 서버(240)가 2개의 프록시/백-엔드 TCP 연결(260(1) 및 260(2))을 통해 백-엔드 서버(270)에 연결하고 TCP 연결마다 50개의 동시 HTTP 트랜잭션의 동시성 한도를 확립한다. 따라서, 프록시 서버(240)와 백-엔드 서버(270) 간에 최대 100개의 HTTP 트랜잭션이 동시에 실행될 수 있다.

도시된 바와 같이, 프록시 서버(240)는 프로세서(112) 및 메모리(116)를 제한 없이 포함한다. 프로세서(112)는 명령어들을 실행할 수 있는 임의의 명령어 실행 시스템, 장치, 또는 디바이스일 수 있다. 예를 들어, 프로세서(112)는 중앙 처리 유닛(CPU), 그래픽 처리 유닛(GPU), 제어기, 마이크로컨트롤러, 상태 머신, 또는 이들의 임의의 조합을 포함할 수 있다. 메모리(116)는, 컴퓨트 인스턴스(110)의 프로세서(112)에 의한 사용을 위해, 소프트웨어 애플리케이션들 및 데이터와 같은 콘텐츠를 저장한다.

메모리(116)는, RAM(random access memory), ROM(read only memory), 플로피 디스크, 하드 디스크, 또는 로컬 또는 원격의 임의의 다른 형태의 디지털 스토리지와 같은, 쉽게 입수할 수 있는 메모리 중 하나 이상일 수 있다. 일부 실시예들에서는, 스토리지(도시되지 않음)가 메모리(116)를 보충하거나 대체할 수 있다. 스토리지는 프로세서(112)가 액세스할 수 있는 임의의 수 및 유형의 외부 메모리들을 포함할 수 있다. 예를 들어, 그리고 제한 없이, 스토리지는 보안 디지털 카드(Secure Digital Card), 외부 플래시 메모리, 휴대용 CD-ROM(compact disc read-only memory), 광학 스토리지 디바이스, 자기 스토리지 디바이스, 또는 전술한 것들의 임의의 적합한 조합을 포함할 수 있다. 대안의 실시예들에서는, 프록시 서버(240)가 임의의 수의 프로세서들(112) 및 임의의 수의 메모리들(116)을 임의의 조합으로 제한 없이 포함할 수 있다. 동일한 또는 다른 실시예들에서는, 프록시 서버(240)에 포함된 임의의 수의 컴퓨팅 디바이스들이 임의의 기술적으로 실현가능한 방식으로 멀티프로세싱 환경을 제공할 수 있다.

프록시 서버(240)는 클라이언트 애플리케이션들(220)이 백-엔드 서버(270)를 통해 네트워크 기반 서비스에 액세스하는 것을 가능하게 하는 하나 이상의 애플리케이션을 구현하도록 구성된다. 각각의 애플리케이션은 프록시 서버(240)의 단일 메모리(116)에 상주하고 프록시 서버(240)의 단일 프로세서(112) 상에서 실행되는 것으로 기술된다. 그러나, 본 기술분야의 기술자들은 인식할 것이지만, 각각의 애플리케이션의 기능성은 임의의 수의 컴퓨팅 디바이스들의 메모리들(116)에 상주하고 임의의 수의 컴퓨팅 디바이스들의 프로세서들(112) 상에서 실행되는 임의의 수의 다른 애플리케이션들에 걸쳐 분산될 수 있다. 또한, 임의의 수의 애플리케이션들의 기능성이 단일 애플리케이션 또는 서브시스템에 통합될 수 있다.

클라이언트 애플리케이션들(220) 각각은 TCP를 통한 HTTP 1.x를 이용하여 네트워크 기반 서비스 시스템(102)에 액세스한다. 그렇게 함에 있어서, 클라이언트 애플리케이션들(220) 각각은 클라이언트/프록시 TCP 연결들(230) 중 하나 이상을 통해 프록시 서버(240)와 상호작용한다. 각각의 클라이언트/프록시 TCP 연결(230)은 클라이언트 디바이스들(104) 중 하나에서 실행중인 클라이언트 애플리케이션들(220) 중 하나를 프록시 서버(240)에 연결한다. 클라이언트 애플리케이션(220(1))에 대해 도시된 바와 같이, 클라이언트 애플리케이션들(220) 각각은 최대 TCP 연결들(204)과 연관된다. 최대 TCP 연결들(204(1))은 클라이언트 애플리케이션(220(1))이 각각의 네트워크 기반 서비스 시스템(102)에 대해 가질 수 있는 TCP 연결들의 최대 수를 특정한다. 전형적으로, 최대 TCP 연결들(204)은 클라이언트 애플리케이션(220)을 실행하는 클라이언트 플랫폼(예를 들어, 웹 브라우저, 스마트 텔레비전 운영 체제 등)에 의해 설정되고 시행된다. 단지 설명 목적으로, 클라이언트 애플리케이션(220(1))에 대한 최대 TCP 연결들(204)은 3개이다. 따라서, 클라이언트 애플리케이션(220(1))은 최대 3개의 클라이언트/프록시 TCP 연결들(230)을 확립할 수 있다.

TCP를 통한 HTTP/1.x에서는, 각각의 HTTP 트랜잭션이 전용 TCP 연결을 필요로 한다. 전형적인 클라이언트 애플리케이션(220)은 비교적 적은 수의 interactive HTTP 트랜잭션들 및 비교적 많은 수의 informational HTTP 트랜잭션들을 개시한다. interactive HTTP 트랜잭션에서는, 클라이언트 애플리케이션(220)이 클라이언트 애플리케이션(220)과 상호작용하고 있는 사용자에게 제공될 필요가 있는 데이터, 예컨대 홈페이지에 대한 디스플레이 정보를 다운로드한다. informational HTTP 트랜잭션에서는, 클라이언트 애플리케이션(220)이 네트워크 기반 서비스 시스템(102)이 정보 제공 목적으로 사용하는 백-엔드 서버(270)에 데이터를 업로드한다. 예를 들어, 클라이언트 애플리케이션(220)은 이벤트 로그들, 클라이언트 애플리케이션(220)의 성능을 지시하는 메트릭 로그들, 및/또는 클라이언트 애플리케이션(220)이 적절하게 실행중임을 지시하는 "하트비트들"을 업로드할 수 있다.

TCP를 통한 HTTP/1.x를 이용하는 것에 대한 하나의 단점은 informational HTTP 트랜잭션들의 양이 주어진 종래의 클라이언트 애플리케이션과 연관된 interactive HTTP 트랜잭션들의 송신 및 처리를 크게 지연시킬 수 있다는 점이다. 종래의 클라이언트 애플리케이션이 TCP 연결들의 최대 수로 제한될 뿐만 아니라, 또한 업로드 속도가 보통 다운로드 속도보다 느리다. 결과적으로, 다양한 시점들에서, 이용가능한 TCP 연결들 모두가 informational HTTP 트랜잭션에만 할당될 수 있다. 임의의 계류중인 interactive HTTP 트랜잭션은, HTTP 트랜잭션의 비교적 느린 업로드 부분을 포함하여, informational HTTP 트랜잭션들 중 하나가 완료될 때까지 기다려야 한다. 계류중인 interactive HTTP 트랜잭션과 연관된 데이터를 다운로드하는 데 있어서의 결과적인 지연은 전반적인 사용자 경험의 저하를 야기할 수 있다.

본 명세서에서 앞서 기술된 바와 같이, 위의 문제들을 해결하기 위한 노력들은 interactive HTTP 트랜잭션들이 이용할 수 있는 TCP 연결들의 수를 자동으로 감소시키고, informational HTTP 트랜잭션들을 통해 네트워크 기반 서비스에 송신되는 정보를 드롭할 위험을 증가시키고/시키거나, 제한된 적용가능성을 갖는다.

백-엔드 서버의 오프로딩

위의 문제들을 보다 효과적으로 해결하기 위해, 프록시 서버(240)는 프록시 애플리케이션(250)을 제한 없이 포함한다. 도시된 바와 같이, 프록시 애플리케이션(250)은 메모리(116)에 상주하고 프록시 서버(240)의 프로세서(112) 상에서 실행된다. 프록시 애플리케이션(250)은, 클라이언트 애플리케이션들(220)과 백-엔드 서버(270) 간의 중개자의 역할을 하면서, 정보 제공 업로드들에 대한 임의의 수의 HTTP 요청들에 응답하여, 백-엔드 서버(270)로부터 선택적으로 오프로딩한다. 정보 제공 업로드에 대한 HTTP 요청 및 대응하는 HTTP 응답은 본 명세서에서 informational HTTP 트랜잭션이라고 지칭된다.

HTTP/1.x 요청(232(x))을 생성할 때, 대응하는 HTTP/1.x 응답(234(x))이 클라이언트 애플리케이션(220)에 중요하지 않다면, 클라이언트 애플리케이션(220)은 HTTP/1.x 요청(232(x))에 "파이어 앤 포겟" 헤더를 추가할 수 있다. 본 기술분야의 기술자들은 인식할 것이지만, 대응하는 HTTP/1.x 응답(234(x))이 클라이언트 애플리케이션(220)에 중요하지 않은 HTTP/1.x 요청(232(x))은 전형적으로 데이터를 업로드하기 위해 사용되는 HTTP 메서드(method), 예컨대 "POST" 또는 "PUT"을 특정한다.

파이어 앤 포겟 헤더는 HTTP/1.x 요청(232(x))에 대한 응답이 백-엔드 서버(270)로부터 프록시 애플리케이션(250)으로 오프로딩될 수 있음을 프록시 애플리케이션(250)에 지시한다. informational HTTP 상호작용이 전형적으로 연관된 클라이언트 애플리케이션(220)에 미치는 유일한 영향은 잠재적으로 다른 HTTP 상호작용들을 지연시키고, 이로써 클라이언트 애플리케이션(220)의 성능을 감소시키는 것이라는 점에 유의한다. 이러한 이유로, 일부 실시예들에서는, 클라이언트 애플리케이션들(220)이 informational HTTP 상호작용을 개시하는 각각의 HTTP/1.x 요청(232)에 파이어 앤 포겟 헤더를 추가한다.

파이어 앤 포겟 헤더는 명칭 "Fire-and-Forget" 및 성공 코드 리스트(성공 코드 파라미터에 대한 하나 이상의 값)를 제한 없이 포함한다. 명칭 "Fire-and-Forget"은 대응하는 HTTP/1.x 응답(234(x))이 중요하지 않음을 지시한다. 성공 코드 리스트는 각각이 HTTP/1.x 응답(234(x))이 성공적임을 지시하는 하나 이상의 상태 코드를 특정한다. 예를 들어, HTTP/1.x 요청(232(x)) 내의 파이어 앤 포겟 헤더에 대한 성공 코드 리스트는 "200, 204"를 특정할 수 있고, HTTP/1.x 요청(232(y)) 내의 파이어 앤 포겟 헤더의 성공 코드 리스트는 "200"을 특정할 수 있다.

HTTP/1.x 요청(232(x))이 파이어 앤 포겟 헤더를 포함하고 있다면, HTTP/1.x 요청(232(x))은 HTTP/1.x 요청(232(x))과 연관된 중요성의 레벨과 상관되는 지속성 레벨(persistence level)과 연관된다. HTTP1.x 요청(232(x))에 대한 지속성 레벨은 HTTP1.x 요청(232(x))에 포함되는 "지속성" 헤더를 통해 특정될 수 있다. HTTP1.x 요청(232(x))이 지속성 헤더를 포함하고 있지 않다면, HTTP1.x 요청(232(x))은 디폴트 지속성 레벨과 연관된다.

지속성 헤더는 명칭 "Persistence" 및 지속성 레벨(지속성 파라미터에 대한 값)을 제한 없이 포함한다. 각각의 허용된 지속성 레벨은 백-엔드 서버(270)가 연관된 HTTP 요청(232)의 버전을 성공적으로 처리하지 못하는 경우에 프록시 애플리케이션(250)이 수행해야 하는 상이한 에러 핸들링(error-handling) 프로세스와 연관된다. 보다 정확하게는, HTTP 요청(232(x))에 대한 지속성 레벨은 백-엔드 서버가 HTTP.2 요청(262(x))을 성공적으로 처리하지 못하는 경우에 프록시 애플리케이션(260)이 수행해야 하는 에러 핸들링 프로세스를 특정한다. HTTP/2 요청(262(x))은 HTTP/1.x 요청(232(x))의 HTTP/2 버전이다.

프록시 애플리케이션(250)은, 클라이언트 애플리케이션들(220) 중 하나로부터 HTTP/1.x 요청(232(x))을 수신하면, HTTP/1.x 요청(232(x))에 대해 오프로딩을 활성화할지를 결정한다. 일부 실시예들에서는, 프록시 애플리케이션(250)은 HTTP/1.x 요청(232(x))이 파이어 앤 포겟 헤더를 포함하고 있다면 HTTP/1.x 요청(232(x))에 대해 오프로딩을 활성화한다. 다른 실시예들에서는, 프록시 애플리케이션(250)은 HTTP/1.x 요청(232(x))이 파이어 앤 포겟 헤더 및 임의의 수의 추가적인 기준을 포함하는지 여부에 기초하여 HTTP/1.x 요청(232(x))에 대해 오프로딩을 활성화할지를 결정할 수 있다.

예를 들어, 다양한 실시예들에서는, 프록시 애플리케이션(250)은 HTTP/1.x 요청(232(x))이 파이어 앤 포겟 헤더 및 최대 동시 오프로드들(도 1에 도시되지 않음)을 포함하는지 여부에 기초하여 HTTP/1.x 요청(232(x))에 대해 오프로딩을 활성화할지를 결정한다. 최대 동시 오프로드들은 임의의 주어진 시간에 오프로딩이 활성일 수 있는 HTTP/1.x 요청들(232)의 최대 수를 특정한다. HTTP/1.x 요청(232(x))이 파이어 앤 포겟 헤더를 포함하고 오프로딩이 활성인 HTTP1.x 요청들(232)의 총수가 최대 동시 오프로드들보다 작다면, 프록시 애플리케이션(250)은 HTTP/1.x 요청(232(x))에 대해 오프로딩을 활성화한다. 그렇지 않으면, 프록시 애플리케이션(250)은 HTTP/1.x 요청(232(x))에 대해 오프로딩을 활성화하지 않는다. 프록시 애플리케이션(250)은 임의의 기술적으로 실현가능한 방식으로 오프로딩을 추적하고 활성화할 수 있다.

예를 들어, 일부 실시예들에서는 그리고 도 3과 관련하여 더 상세히 기술되는 바와 같이, 프록시 애플리케이션(250)이 Go 언어로 작성되고 각각의 HTTP/1.x 요청(232)은 상이한 실행 스레드를 통해 처리된다. 오프로딩 기능성은 오프로딩 기능성을 실행하는 스레드의 수를 최대 동시 오프로드들로 제한하는 HTTP.handler에 포함된다.

HTTP/1.x 요청(232(x))에 대해 오프로딩이 활성이면, 프록시 애플리케이션(250)은 HTTP/요청(232(x))이 수신된 클라이언트/프록시 TCP 연결(230)을 이용하여 "성공적인" 일반 HTTP/1.x 응답(234(x))을 클라이언트 애플리케이션(220)에 송신한다. 그 후 클라이언트 애플리케이션(220)은 클라이언트/프록시 TCP 연결(230)을 재사용 또는 폐쇄할 수 있다. 성공적인 일반 HTTP/1.x 응답(234(x))은 백-엔드 서버(270)가 HTTP/1.x 요청(232(x))을 성공적으로 처리했음을 의도적으로 그리고 잘못되게 지시한다. 프록시 애플리케이션(250)은 임의의 기술적으로 실현가능한 방식으로 성공적인 일반 HTTP/1.x 응답(234(x))을 생성할 수 있다.

예를 들어, 일부 실시예들에서는, 프록시 애플리케이션(250)은 HTTP/1.x 요청(232(x))의 파이어 앤 포겟 헤더의 성공 코드 리스트에 특정된 상태 코드들 중 하나를 포함하는 성공적인 일반 HTTP/1.x 응답(234(x))을 생성한다. 예를 들어, 성공 코드 리스트가 200의 상태 코드를 포함하고 있다면, 프록시 애플리케이션(250)은 "200 OK" HTTP 상태 라인 및 빈 본문(empty body)을 갖는 성공적인 일반 HTTP/1.x 응답(234(x))을 생성할 수 있다. 본 기술분야의 기술자들은 인식할 것이지만, "HTTP 상태 라인"은 연관된 이유 문구(예를 들어, "OK")를 동반하는 상태 코드(예를 들어, 200)이다. 200의 상태 코드는 백-엔드 서버(270)가 HTTP/1.x 요청(232(x))을 성공적으로 처리했음을 지시한다. 다른 예에서, 성공 코드 리스트가 204의 상태 코드를 포함하고 있다면, 프록시 애플리케이션(250)은 "204 No Content" HTTP 상태 라인을 갖는 성공적인 일반 HTTP/1.x 응답(234(x))을 생성할 수 있다. 204의 상태 코드는 백-엔드 서버(270)가 HTTP/1.x 요청(232(x))을 성공적으로 처리했고 어떠한 콘텐츠도 반환하고 있지 않음을 지시한다.

후속하여, HTTP/1.x 요청(232(x))에 대해 오프로딩이 활성인지 여부에 관계없이, 프록시 애플리케이션(250)은 HTTP/1.x 요청(232(x))을 HTTP/2 요청(262(x))으로 변환한다. HTTP/2 요청(262(x))은 HTTP/1.x 요청(232(x))의 HTTP/2 버전이다. 프록시 애플리케이션(250)은 임의의 기술적으로 실현가능한 방식으로 HTTP/1.x 요청(232(x))을 HTTP/2 요청(262(x))으로 변환할 수 있다. 그 후 프록시 애플리케이션(250)은 프록시/백-엔드 TCP 연결들(260) 중 하나를 통해 HTTP/2 요청(262(x))을 백-엔드 서버(270)에 송신하려고 시도한다. HTTP/1.x 트랜잭션과는 대조적으로, 임의의 수의 HTTP/2 요청들(262) 및 임의의 수의 HTTP/2 응답들(264)이 프록시/백-엔드 TCP 연결들(260) 각각을 공유할 수 있기 때문에, 임의의 수의 HTTP/2 트랜잭션들이 동시에 실행될 수 있다.

HTTP/2 요청(262(x))에 대해 오프로딩이 활성이 아니고 프록시 애플리케이션(250)이 백-엔드 서버(270)로부터 HTTP/2 응답(264(x))을 성공적으로 수신하면, 프록시 애플리케이션(250)은 HTTP/2 응답(264(x))을 HTTP1.x 응답(234(x))으로 변환한다. HTTP/1.x 응답(234(x))은 HTTP/2 응답(264(x))의 HTTP/1.x 버전이다. 프록시 애플리케이션(250)은 임의의 기술적으로 실현가능한 방식으로 HTTP/2 응답(264(x))을 HTTP1.x 응답(234(x))으로 변환할 수 있다. 그 후 프록시 애플리케이션(250)은 HTTP/요청(232(x))이 수신된 클라이언트/프록시 TCP 연결(230)을 이용하여 HTTP/1.x 응답(234(x))을 프록시 애플리케이션(250)에 송신한다. 그 후 클라이언트 애플리케이션(220)은 클라이언트/프록시 TCP 연결(230)을 재사용 또는 폐쇄할 수 있다.

HTTP/2 요청(262(x))에 대해 오프로딩이 활성이 아니고 프록시 애플리케이션(250)이 백-엔드 서버(270)로부터 HTTP/2 응답(264(x))을 수신하지 않으면, 프록시 애플리케이션(250)은 "서버 에러" HTTP/2 응답(264(x))을 생성한다. 프록시 애플리케이션(250)은 다양한 이유로 백-엔드 서버(270)로부터 HTTP/2 응답(262(x))을 수신하지 않을 수 있다. 예를 들어, 백-엔드 서버(270)가 과부하가 될 수 있다. 서버 에러 HTTP 응답(264(x))은 서버 에러 때문에 HTTP/1.x 요청(232(x))이 성공하지 않았음을 지시한다. 예를 들어, 일부 실시예들에서는, 서버 에러 HTTP 응답(264(x))이 "502 Bad Gateway" HTTP 상태 라인을 갖는다. 502의 상태 코드는 프록시 서버(240)가 백-엔드 서버(270)로부터 무효 응답을 수신했음을 지시한다.

오프로딩이 HTTP/2 요청(262(x))에 대해 오프로딩이 활성이고 프록시 애플리케이션(250)이 백-엔드 서버(270)로부터 성공을 지시하는 HTTP/2 응답(264(x))을 수신하면, 프록시 애플리케이션(250)은 HTTP/2 응답(264(x))을 폐기한다. 프록시 애플리케이션(250)은 임의의 기술적으로 실현가능한 방식으로 HTTP/2 응답(264(x))이 성공을 지시하는지를 결정할 수 있다. 예를 들어, 일부 실시예들에서는, 프록시 애플리케이션(250)이 HTTP/1 요청(232(x))과 연관된 성공 코드 리스트에 기초하여 HTTP/2 응답(264(x))이 성공을 지시하는지를 결정한다. HTTP/2 응답(264(x))에 포함된 상태 코드가 성공 코드 리스트에 포함된 상태 코드들 중 하나와 일치하면, 프록시 애플리케이션(250)은 HTTP/2 응답(264(x))이 성공을 지시한다고 결정한다. 그렇지 않으면, 프록시 애플리케이션(250)은 HTTP/2 응답(264(x))이 성공을 지시하지 않는다고 결정한다.

HTTP/2 요청(262(x))에 대해 오프로딩이 활성이고 프록시 애플리케이션(250)이 백-엔드 서버(270)로부터 HTTP/2 응답을 수신하지 않으면, 프록시 애플리케이션(250)은 지속성 레벨에 따라 에러 핸들링 프로세스를 실행한다. 유사하게, HTTP/2 요청(262(x))에 대해 오프로딩이 활성이고 프록시 애플리케이션(250)이 백-엔드 서버(270)로부터 성공을 지시하지 않는 HTTP/2 응답(264(x))을 수신하면, 프록시 애플리케이션(250)은 지속성 레벨에 따라 에러 핸들링 프로세스를 실행한다.

프록시 애플리케이션(250)은 임의의 기술적으로 실현가능한 방식으로 임의의 수 및 유형의 허용할 수 있는 지속성 레벨들에 기초하여 임의의 수 및 유형의 에러 핸들링 프로세스들을 구현할 수 있다. 예를 들어, 일부 실시예들에서는, 허용할 수 있는 지속성 레벨들이 "낮음(low)", "중간(medium)", "높음(high)"(디폴트 지속성 레벨), 및 "내구성 있음(durable)"이다. HTTP/1.x 요청(232(x))에 대한 지속성 레벨이 낮음이면, 프록시 애플리케이션(250)은 HTTP/1.x 요청(232(x))에 대해 더 이상의 동작을 수행하지 않는다. 지속성 레벨이 중간이면, 프록시 애플리케이션(250)은 비교적 짧은 간격을 두고 최대 3회의 재송신 시도를 수행한다. 재송신 시도는 HTTP/2 요청(262(x))을 백-엔드 서버(270)에 재송신하려는 시도이다.

지속성 레벨이 높음이면, 프록시 애플리케이션(250)은 프록시 애플리케이션(250)이 백-엔드 서버(270)로부터 성공을 지시하는 HTTP/2 응답(264(x))을 수신할 때까지 재송신 시도들을 수행한다. 최대 동시 오프로드들에 도달하면, 프록시 애플리케이션(250)은 더 이상 오프로딩을 활성화하지 않고 대신에 동기 프록시 동작들을 수행한다는 점에 유의한다. 결과적으로, 높음의 지속성 레벨은 프록시 애플리케이션(250)에서 백로그(backlog)를 야기하지 않는다.

지속성 레벨이 내구성 있음이면, 프록시 애플리케이션(250)은 재시작들에 걸쳐 살아남기 위해 HTTP/2 요청(262(x))을 영구 스토리지(예를 들어, 디스크)에 기입하고 프록시 애플리케이션(250)이 백-엔드 서버(270)로부터 성공을 지시하는 HTTP/2 응답(264(x))을 수신할 때까지 재송신 시도들을 수행한다. 에러 핸들링 프로세스 동안의 임의의 시점에, 프록시 애플리케이션(250)이 백-엔드 서버(270)로부터 성공을 지시하는 HTTP/2 응답(264(x))을 수신하면, 프록시 애플리케이션(250)은 HTTP/2 응답(264(x))을 폐기하고 에러 핸들링 프로세스를 종료한다.

각각의 클라이언트 애플리케이션(220)은 임의의 기술적으로 실현가능한 방식으로 각각의 HTTP/1.x 요청(232)에 대한 지속성 레벨을 결정할 수 있다. 예를 들어, 일부 실시예들에서는, 하트비트들이 비교적 빈번하게 발생하므로, 클라이언트 애플리케이션들(220)은 하트비트들의 업로딩을 수반하는 각각의 HTTP/1.x 요청(232)에 낮음의 지속성 레벨을 특정하는 지속성 헤더를 포함시킨다. 이벤트 로그들 및 메트릭 로그들은 전형적으로 덜 빈번하게 생성되기 때문에, 클라이언트 애플리케이션들(220)은 이벤트 로그들 또는 메트릭 로그들을 업로드하는 것을 수반하는 HTTP/1.x 요청들(232)에 지속성 헤더를 포함시키지 않고, 이로써 연관된 지속성 레벨들을 높음으로 디폴트 설정한다.

단지 설명 목적으로, 도 2는 클라이언트 애플리케이션(220(1)), 프록시 애플리케이션(250), 및 백-엔드 서버(270) 간의 일련의 상호작용들을 일련의 번호가 매겨진 버블들로서 묘사한다. 클라이언트 애플리케이션(220(1))은 클라이언트 디바이스(104(1)) 상에서 실행되고 3의 최대 연결들(204(1))을 가진다.

클라이언트 애플리케이션(220(1))은, 네트워크 기반 서비스 시스템(102)과 상호작용하기 위해, 4개의 HTTP/1.x 요청(232(1)-232(4))을 생성한다. HTTP/1.x 요청들(232(1)-232(4)) 각각은 네트워크 기반 서비스 시스템(102)을 호스트로서 특정한다. HTTP/1.x 요청들(232(1), 232(2), 및 232(4)) 각각은 다운로드에 대한 요청이고 파이어 앤 포겟 헤더를 포함하고 있지 않다. 대조적으로, HTTP/1.x 요청(232(3))은 이벤트 로그의 업로드에 대한 요청이고 파이어 앤 포겟 헤더를 포함한다. 그 후 클라이언트 애플리케이션(220(1))은 HTTP/1.x 요청들(232(1)-232(4))을 프록시 애플리케이션(250)에 송신하려고 시도한다.

클라이언트 애플리케이션(220(1))이 최대 3개의 TCP 연결들로 제한되기 때문에, 클라이언트 디바이스(104)는 제각기 HTTP/1.x 요청들(232(1)-232(3))에 대해 3개의 클라이언트/프록시 TCP 연결들(230(1)-(3))을 생성한다. HTTP/1.x 요청들(232) 각각이 전용 클라이언트/프록시 TCP 연결(230)을 요구하고 이용가능한 클라이언트/프록시 TCP 연결들(230) 모두가 사용중이기 때문에, HTTP/1.x 요청(232(4))의 송신이 지연된다.

클라이언트 디바이스(104(1))와 프록시 서버(240)는, HTTP/1.X 요청(232(x))에 대한 클라이언트/프록시 TCP 연결(230(x))을 생성하기 위해, TCP 핸드셰이크와 이어서 TLS(transport layer security) 핸드셰이크를 수행한다. TCP 핸드셰이크는 클라이언트 디바이스(104)와 프록시 서버(240)가 서로 통신하기 위해 TCP 통신 세션을 협상하고 시작하는 메커니즘이다. TLS 핸드셰이크는 클라이언트 디바이스(104(1))와 프록시 서버(240)가 보안 통신 세션을 확립하기 위해 필요한 보안 키들을 교환하는 메커니즘이다.

1-3으로 번호가 매겨진 버블들로 묘사된 바와 같이, 프록시 애플리케이션(250)은 제각기 클라이언트/프록시 TCP 연결들(230(1)-230(3))을 통해 HTTP/1.x 요청들(232(1)-232(3))을 수신한다. 프록시 애플리케이션(250)은 HTTP/1.x 요청(232(3))이 파이어 앤 포겟 헤더를 포함하고 현재 동시 오프로드들의 총수가 최대 동시 오프로드들보다 작다고 결정한다. 따라서, 4로 번호가 매겨진 버블로 묘사된 바와 같이, 프록시 애플리케이션(250)은 HTTP/1.x 요청(232(3))에 대해 오프로딩을 활성화하고 HTTP 상태 라인 "200 OK"를 갖는 HTTP/1.x 응답(234(3))을 클라이언트/프록시 TCP 연결(230(3))을 통해 클라이언트 애플리케이션(220(1))에 송신한다.

프록시 애플리케이션(250)은 HTTP/1.x 요청들(232(1)-232(3))을 제각기 HTTP/2 요청들(262(1)-262(3))로 변환하고, HTTP/2 요청들(262(1)-262(3))을 백-엔드 서버(270)에 송신하려고 시도한다. 유리하게는, 프록시 서버(240)와 백-엔드 서버(270)는 임의의 수의 미리 확립되고 미리 인증된 프록시/백-엔드 TCP 연결들(260)을 생성하기 위해 TCP 핸드셰이크 및 TLS 핸드셰이크를 앞서 수행하였다. 또한, 프록시 서버(240)와 백-엔드 서버(270) 간의 비교적 많은 양의 트래픽으로 인해, 프록시/백-엔드 TCP 연결들(260)은 지속적이다. 결과적으로, 프록시 서버(240)는 어떤 추가적인 핸드셰이크도 수행하지 않고 클라이언트/프록시 TCP 연결(230(1))을 통해 HTTP/2 요청들(262(1)-262(3))을 백-엔드 서버(270)에 송신하기 시작한다. 보다 정확하게는, 프록시 서버(240)는 HTTP/2 요청들(262(1)-262(3))을 프록시/백-엔드 TCP 연결(260(1))을 통해 임의의 수의 다른 HTTP/2 요청들(262) 및/또는 HTTP/2 응답들(264)과 함께 다중 송신한다.

클라이언트 애플리케이션(220(1))이 HTTP/1.x 응답(234(3))을 수신할 때, 클라이언트 디바이스(104(1))는 지연된 HTTP/1.x 요청(232(4))에 대해 클라이언트/프록시 TCP 연결(230(3))을 재생성(예를 들어, 폐쇄, 재확립, 및 재인증)한다. 대안의 실시예들에서는, 클라이언트 디바이스(104(1))가 클라이언트/프록시 TCP 연결(230(3))을 폐쇄, 재설정, 및 재인증하지 않고 지연된 HTTP/1.x 요청(232(4))에 대해 클라이언트/프록시 TCP 연결(230(3))을 재사용할 수 있다. 그 후 클라이언트 디바이스(104(1))는 클라이언트/프록시 TCP 연결(230(3))을 통해 HTTP/1.x 요청(232(4))을 프록시 서버(240)에 송신하기 시작한다.

유리하게는, 프록시 서버(240)는 백-엔드 서버(270)에 비해 클라이언트 디바이스(104(1))에 물리적으로 더 가깝다. 그 결과, 5로 번호가 매겨진 버블로 묘사된 바와 같이, 프록시 애플리케이션(250)은 HTTP/2 요청(262(1)-262(3))이 백-엔드 서버(270)에 도달하기 전에 HTTP/1.x 요청(232(4))을 수신한다. 프록시 애플리케이션(250)은 HTTP/1.x 요청(232(4))을 HTTP/2 요청들(262(4))로 변환하고 HTTP/2 요청(262(4))을 백-엔드 서버(270)에 송신하려고 시도한다. 프록시 서버(240)는 HTTP/2 요청(262(4))을 프록시/백-엔드 TCP 연결(260(1))을 통해 HTTP/2 요청들(262(1)-262(3)) 및 임의의 수의 다른 HTTP/2 요청들(262) 및/또는 HTTP/2 응답들(264)과 함께 다중 송신한다.

후속하여, 6-8로 번호가 매겨진 버블들로 묘사된 바와 같이, 백-엔드 서버(270)는 프록시/백-엔드 TCP 연결(260(1))을 통해 HTTP/2 요청들(262(1), 262(2), 및 262(4))을 수신한다. HTTP/2 요청(262(3))이 업로드를 수반하기 때문에, HTTP/2 요청(262(3))은 백-엔드 서버(270)에 도달하기 위해 더 긴 기간을 요구한다. 백-엔드 서버(270)는 HTTP/2 요청들(262(1), 262(2), 및 262(4))을 처리하고 제각기 HTTP/2 응답들(264(1), 264(2), 및 264(4))을 생성한다. 백-엔드 서버(270)는 프록시/백-엔드 TCP 연결(260(1))을 통한 프록시 애플리케이션(250)으로의 HTTP/2 응답들(264(1), 264(2), 및 264(4))의 송신을 개시한다.

9-11로 번호가 매겨진 버블들로 묘사된 바와 같이, 프록시 애플리케이션(250)은 프록시/백-엔드 TCP 연결(260(1))을 통해 HTTP/2 응답들(264(1), 264(2), 및 264(4))을 성공적으로 수신한다. HTTP/1.x 요청들(234(1), 232(2), 및 232(4))에 대해 오프로딩이 활성이 아니기 때문에, 프록시 애플리케이션(250)은 HTTP/2 응답들(264(1), 264(2), 및 264(4))을 제각기 HTTP/1.x 응답들(234(1), 234(2), 및 234(4))로 변환한다. 그 후 프록시 애플리케이션(250)은 클라이언트/프록시 TCP 연결(230(1))을 통한 HTTP1.x 응답(234(1))의 송신, 클라이언트/프록시 TCP 연결(230(2))을 통한 HTTP1.x 응답(234(2))의 송신, 및 클라이언트/프록시 TCP 연결(230(3))을 통한 HTTP1.x 응답(234(4))의 송신을 개시한다.

HTTP/1.x 응답들(234(1), 234(2), 및 234(4))이 클라이언트 애플리케이션(220(1))으로 이동중인 동안, 백-엔드 서버(270)는 HTTP/2 요청(262(3))을 수신한다(12로 번호가 매겨진 버블로 묘사됨). 백-엔드 서버(270)는 HTTP/2 요청(262(3))을 처리하고, HTTP/2 응답(264(3))을 생성하고, 프록시/백-엔드 TCP 연결(260(1))을 통한 프록시 애플리케이션(250)으로의 HTTP/2 응답(264(3))의 송신을 개시한다.

13-15로 번호가 매겨진 버블들로 묘사된 바와 같이 그리고 HTTP/2 응답(264(3))이 프록시 애플리케이션(250)으로 이동중인 동안, 클라이언트 애플리케이션(220(1))은 HTTP/1.x 응답들(234(1), 234(2), 및 234(4))을 수신한다. 후속하여, 16으로 번호가 매겨진 버블로 묘사된 바와 같이, 프록시 애플리케이션(250)은 HTTP/2 응답(264(3))을 수신한다. HTTP/1.x 요청(232(3))에 대해 오프로딩이 활성이고 HTTP/2 응답(264(3))이 백-엔드 서버(270)가 HTTP/1.x 요청(232(3))을 성공적으로 처리했음을 지시하기 때문에, 프록시 애플리케이션(250)은 HTTP/2 응답(264(3))을 폐기한다.

단지 설명 목적으로, 도 2 내지 도 3은 TCP 연결들 및 HTTP 프로토콜의 특정 버전들의 컨텍스트에서 시스템(100)의 기능성을 기술하고 있다. 그러나, 본 명세서에 기술된 기법들은 제한적인 것이 아니라 예시적인 것이고, 본 발명의 더 넓은 사상 및 범위를 벗어나지 않고 변경될 수 있다. 본 기술분야의 통상의 기술자들은 기술된 실시예들 및 기법들의 범위 및 사상을 벗어나지 않고 많은 수정들 및 변형들을 알 수 있을 것이다.

일반적으로, 본 명세서에 개관된 기법들은 네트워크 기반 서비스들에 요청들을 송신하기 전에 네트워크 기반 서비스들에 대한 선택된 요청들에 응답하여 성공적인 일반 응답들을 반환하는 것에 적용가능하다. 대안의 실시예들에서는, 요청들 및 응답들이 임의의 수 및 유형의 송신 프로토콜들을 따를 수 있고 임의의 수 및 유형의 연결들을 통해 송신될 수 있다. 일반적으로, 프록시 애플리케이션(250)은, 클라이언트 애플리케이션(220)으로부터 수신된 HTTP 요청에 응답할 때, HTTP 요청의 HTTP 포맷으로 HTTP 응답을 생성하거나 클라이언트 애플리케이션(220)에 중계한다. 프록시 애플리케이션은, HTTP 요청을 백-엔드 서버(270)에 중계할 때, 백-엔드 서버(270)로의 HTTP 요청의 버전의 가장 효율적인 송신을 보장하기 위해 HTTP 요청에 대해 임의의 수의 변환 동작들을 수행할 수 있다.

예를 들어, 일부 대안의 실시예들에서는, 임의의 수의 클라이언트 애플리케이션들(220)이 HTTP/2를 구현한다. 클라이언트 애플리케이션은, HTTP/2 요청(262(x))을 생성할 때, 대응하는 HTTP/2 응답(264(x))이 중요하지 않음을 지시하기 위해 HTTP/2 요청(262(x))에 파이어 앤 포겟 헤더를 추가할 수 있다. 프록시 애플리케이션(250)은 HTTP/2 요청(262(x))이 파이어 앤 포겟 헤더 및 최대 동시 오프로드들을 가지고 있는지 여부에 기초하여 HTTP/2 요청(262(x))에 대해 오프로딩을 활성화할지를 결정한다. HTTP/2 요청(262(x))에 대해 오프로딩이 활성이면, 프록시 애플리케이션(250)은 성공적인 일반 HTTP/2 응답(264)을 클라이언트 애플리케이션(220)에 송신한다. HTTP/2 요청(262(x))에 대해 오프로딩이 활성인지 여부에 관계없이, 프록시 애플리케이션(250)은 HTTP/2 요청(262(x))을 백-엔드 서버(270)에 송신하려고 시도한다. HTTP/2 요청(262(x))에 대해 오프로딩이 활성이면, 프록시 애플리케이션(250)은 백-엔드 서버(270)로부터 수신된 임의의 HTTP/2 응답(264(x))을 폐기한다. HTTP/2 요청(262(x))에 대해 오프로딩이 활성이 아니고 프록시 애플리케이션(250)이 HTTP/2 요청(262(x))을 백-엔드 서버(270)에 송신하지 못하면, 프록시 애플리케이션(250)은 서버 에러 HTTP/2 응답을 클라이언트 애플리케이션(220)에 송신한다. 그렇지 않고, HTTP/2 요청(262(x))에 대해 오프로딩이 활성이 아니면, 프록시 애플리케이션(250)은 백-엔드 서버(270)로부터 수신된 HTTP/2 응답(264(x))을 클라이언트 애플리케이션(220)에 송신한다.

대안의 실시예들에서는, 파이어 앤 포겟 헤더 및 지속성 헤더가 임의의 기술적으로 실현가능한 방식으로 특정될 수 있고 임의의 양 및 유형의 관련 정보를 포함할 수 있다. 예를 들어, 일부 실시예들에서는, 파이어 앤 포겟 헤더가 성공 코드 리스트를 특정하지 않는다. 그러한 실시예들에서는, 프록시 애플리케이션(250)이 임의의 기술적으로 실현가능한 방식으로 각각의 HTTP/2 응답(264)이 성공을 지시하는지를 결정할 수 있다. 예를 들어, 프록시 애플리케이션(250)은 미리 결정된 성공 코드 리스트를 구현할 수 있다. 동일한 또는 다른 실시예들에서는, 지속성 헤더들이 구현되지 않고, 파이어 앤 포겟 헤더가 는 옵션으로 지속성 레벨을 특정한다.

도 3은 본 발명의 다양한 실시예들에 따른, 도 2의 프록시 애플리케이션(250)에 대한 보다 상세한 예시이다. 단지 설명 목적으로, 도 3은 Go 프로그래밍 언어로 작성된 프록시 애플리케이션(250)의 예를 기술하고 있다. 그러나, 본 명세서에 기술된 기법들은 제한적인 것이 아니라 예시적인 것이고, 본 발명의 더 넓은 사상 및 범위를 벗어나지 않고 변경될 수 있다. 특히, 프록시 애플리케이션(250)은 임의의 수 및 유형의 알고리즘들을 실행할 수 있고 임의의 수(하나를 포함함)의 기술적으로 실현가능한 프로그래밍 언어들 및/또는 스크립팅 언어들로 작성될 수 있다.

도시된 바와 같이, 프록시 애플리케이션(250)은 HTTP 라이브러리 계층(310), 파이어 앤 포겟 프록시 핸들러(320), 임의의 수의 핸들러들(330), 및 프록시 핸들러(340)를 제한 없이 포함한다. HTTP 라이브러리 계층(310)은 프록시 서버(240)에 대한 각각의 HTTP/1.x 요청(232)을 상이한 실행 스레드로서 수신하도록 구성된다. HTTP 라이브러리 계층(310)은, HTTP/1.x 요청(232(x))을 수신하면, 네스팅된 HTTP 핸들러들의 양방향 파이프라인에 연관된 실행 스레드의 제어를 전달한다.

양방향 파이프라인은, 순방향으로 순차적으로, 파이어 앤 포겟 프록시 핸들러(320), 임의의 수의 핸들러들(330), 및 프록시 핸들러(340)를 포함한다. 대안의 실시예들에서는, 임의의 수의 핸들러(330)가 파이프라인 내의 파이어 앤 포겟 프록시 핸들러(320)에 선행할 수 있고 임의의 수의 핸들러(330)가 파이프라인 내의 프록시 핸들러(340)에 후속할 수 있다.

HTTP 핸들러들 각각은 2개의 인수, 즉 http.ResponseWriter 및 http.Request에 대한 포인터를 갖는 유형 http.HandlerFunc이다. http.Request는 HTTP/1.1 요청(232(x))를 나타내는 데이터 구조이다. http.responseWriter는 HTTP/1.1 요청(232(x))에 대한 HTTP/1.x 응답(234(x))을 생성하여 송신한다. HTTP 핸들러가 http.responseWriter에 데이터를 기입하면, http.responseWriter는 HTTP/1.1 요청(232(x))이 수신된 클라이언트/프록시 TCP 연결(230)을 통해 대응하는 HTTP/1.x 응답(234(x))을 송신한다. 또한, 파이프라인 내의 다양한 HTTP 핸들러들이 HTTP/1.1 요청(232(x))에 대한 HTTP 응답을 나타내는 http.Response 데이터 구조에 액세스한다.

HTTP 핸들러들 각각은 http.Request를 통해 HTTP/1.1 요청(232(x)) 및/또는 HTTP/2 요청(262(x))과 연관된 임의의 수 및 유형의 동작들을 수행할 수 있다. 유사하게, HTTP 핸들러들 각각은 http.Response를 통해 HTTP/.1 응답(234(x)) 및/또는 HTTP/2 응답(264(x))과 연관된 임의의 수 및 유형의 동작들을 수행할 수 있다. HTTP 핸들러들 각각은 또한 http.responseWriter에 기입하고, 어느 방향으로든 파이프라인 내의 다음 HTTP 핸들러에 제어를 전달하고, 파이프라인을 통한 제어 전파를 중지하는 등을 할 수 있다.

HTTP/1.1 요청(232(x))과 연관된 실행 스레드가 HTTP 라이브러리 계층(310)에 들어갈 때, HTTP 라이브러리 계층(310)은 HTTP/1.1 요청(232(x))을 나타내는 http.Request 및 http.responseWriter을 생성한다. 그 후 HTTP 라이브러리 계층(310)은 순방향으로 전파를 개시하기 위해 파이프라인 내의 제1 HTTP 핸들러에 제어를 전달한다. 도 3에 묘사된 실시예에서는, 파이프라인 내의 제1 HTTP 핸들러가 파이어 앤 포겟 핸들러(320)이다.

도시된 바와 같이, 파이어 앤 포겟 핸들러(320)는 HTTP 헤더 트리거(324), 최대 동시 오프로드들(322) 및 오프로딩 동작들(326)을 제한 없이 포함한다. HTTP 헤더 트리거(324)는 파이어 앤 포겟 헤더를 구별하는 명칭 "Fire-and-Forget"을 특정한다. 최대 동시 오프로드들(322)은 임의의 주어진 시간에 오프로딩이 활성일 수 있는 HTTP/1.x 요청들(232)(즉, 스레드들)의 최대 수를 특정한다. 오프로딩 동작들(326)은 실행 스레드에 대해 오프로딩이 활성일 때 실행되는 파이어 앤 포겟 핸들러(320)에서의 동작들이다.

파이어 앤 포겟 핸들러(320)가 실행 스레드의 제어를 수신할 때, 파이어 앤 포겟 핸들러(320)는 HTTP 헤더 트리거(324)에 기초하여 HTTP/1.1 요청(232(x))이 파이어 앤 포겟 헤더를 포함하는지를 결정한다. 파이어 앤 포겟 핸들러(320)가 HTTP/1.1 요청(232(x))이 파이어 앤 포겟 헤더를 포함하고 있지 않다고 결정하면, 파이어 앤 포겟 핸들러(320)는 순방향으로 통과(pass-through)의 역할을 한다. 보다 정확하게는, 파이어 앤 포겟 핸들러(320)는, 오프로딩 동작들(326)을 실행하지 않고 파이프라인에서 순방향으로 다음에 있는 핸들러(330(1))에 제어를 전달한다.

그러나, 파이어 앤 포겟 핸들러(320)가 HTTP/1.1 요청(232(x))이 파이어 앤 포겟 헤더를 포함한다고 결정하면, 파이어 앤 포겟 핸들러(320)는 최대 동시 오프로드들(322)에 기초하여 HTTP/1.1 요청(232(x))에 대해 오프로딩을 활성화할지를 결정한다. 일반적으로, 파이어 앤 포겟 핸들러(320)는 오프로딩이 활성인 HTTP/1.1 요청들(232)의 총수를 최대 동시 오프로드들(322)로 제한한다.

파이어 앤 포겟 핸들러(320)는 임의의 기술적으로 실현가능한 방식으로 오프로딩이 활성인 HTTP/1.x 요청들(232)의 총수를 추적하고 제한할 수 있다. 예를 들어, 일부 실시예들에서는, 파이어 앤 포겟 핸들러(320)가 임의의 주어진 시간에 오프로딩이 활성인 스레드들의 총수를 제한하기 위해 GO 언어의 동시성 특징들(예를 들어, 채널들)을 사용할 수 있다. 다른 실시예들에서는, 파이어 앤 포겟 핸들러(320)가 오프로딩이 활성인 실행 스레드들의 카운트를 유지하고 그 카운트를 최대 동시 오프로드들(322)과 비교할 수 있다. 그 카운트가 최대 동시 오프로드들(322)과 동등하다면, 파이어 앤 포겟 핸들러(320)는 HTTP/1,1 요청(232(x))에 대해 오프로딩을 가능하게 하지 않고 순방향으로 통과의 역할을 한다. 보다 정확하게는, 파이어 앤 포겟 핸들러(320)는, 오프로딩 동작들(326)을 실행하지 않고 파이프라인에서 순방향으로 다음에 있는 핸들러(330(1))에 제어를 전달한다.

대안의 실시예들에서는, 파이어 앤 포겟 핸들러(320)가 임의의 기술적으로 실현가능한 방식으로 HTTP/요청(232(x))에 대해 오프로딩을 활성화할 수 있다. 예를 들어, 파이어 앤 포겟 핸들러(320)는 HTTP/요청(232(x))과 연관된 오프로드 플래그를 거짓(false)으로 초기화할 수 있다. HTTP/요청(232(x))이 파이어 앤 포겟 헤더를 포함하고 오프로딩이 활성인 HTTP 요청의 총수가 최대 동시 오프로드들(322)보다 작다면, 파이어 앤 포겟 핸들러(320)는 오프로드 플래그를 참(true)으로 설정한다. 오프로드 플래그가 거짓이면, 파이어 앤 포겟 핸들러(320)는 오프로딩 동작들(326)을 실행하지 않는다. 그렇지 않으면, 파이어 앤 포겟 핸들러(320)는 오프로딩 동작들(326)을 실행한다.

파이어 앤 포겟 핸들러(320)가 실행 스레드의 제어를 유지하고 있다면, HTTP/1,1 요청(232(x))에 대해 오프로딩이 활성이고 파이어 앤 포겟 핸들러(320)는 오프로딩 동작들(326)을 실행하기 시작한다. 파이어 앤 포겟 핸들러(320)는 성공적인 일반 HTTP/1.x 응답(234(x))을 생성한다. 그 후 파이어 앤 포겟 핸들러(320)는 성공적인 일반 HTTP/1.x 응답(234(x))을 http.responseWriter에 기입한다. 이에 응답하여, http.responseWriter은 HTTP/1.1 요청(232(x))이 수신된 클라이언트/프록시 TCP 연결(230)을 통해 성공적인 일반 HTTP/1.x 응답(234(x))을 송신한다. http.responseWriter에 기입하는 것은 실행 스레드에 대해 논블로킹 동작(non-blocking operation)이라는 점에 유의한다. 파이어 앤 포겟 핸들러(320)는, http.responseWriter에 기입한 후에, 파이프라인에서 순방향으로 다음에 있는 핸들러(330(1))에 실행 스레드의 제어를 전달한다.

핸들러들(330) 각각은 파이프라인 내의 다음 HTTP 핸들러에 실행 스레드의 제어를 전달하기 전에 임의의 수 및 유형의 동작들을 수행할 수 있다. 실행 스레드의 제어가 프록시 핸들러(340)에 전달될 때, 프록시 핸들러(340)는 HTTP/1.x 요청(232(x))을 HTTP/2 요청(262(x))으로 변환한다. 그 후 프록시 핸들러(340)는 HTTP/2 요청(262(x))을 백-엔드 서버(270)에 송신하려고 시도한다. HTTP/2 요청(262(x))을 백-엔드 서버(270)에 송신하는 것은 프록시 핸들러(340)가 HTTP/2 응답(264(x))을 수신하거나 프록시 핸들러(340)가 백-엔드 서버(270)가 대응하는 HTTP/2 응답을 송신하지 못한다고 결정할 때까지 실행 스레드를 블로킹한다. 프록시 핸들러(340)가 백-엔드 서버(270)가 대응하는 HTTP/2 응답을 송신하지 못한다고 결정하면, 프록시 핸들러(340)는 HTTP/1.x 요청(232(x))과 연관된 성공 코드 리스트에 포함되지 않은 상태 코드를 갖는 서버 에러 HTTP/2 응답(264(x))을 생성한다. 후속하여, 프록시 핸들러(340)는 프록시 핸들러(340)가 제어를 수신한 HTTP 핸들러에 실행 스레드의 제어를 반환하고, 이로써 역방향으로 파이프라인의 전파를 개시한다.

파이어 앤 포겟 핸들러(320)에 실행 스레드의 제어가 반환될 때, 파이어 앤 포겟 핸들러(320)는 오프로딩 동작들(326) 외부 또는 내부에서 실행을 재개한다. HTTP/요청(232(x))에 대해 오프로딩이 활성이 아니면, 파이어 앤 포겟 핸들러(320)는 오프로딩 동작들(326) 외부에서 실행을 재개한다. 파이어 앤 포겟 핸들러(320)는 HTTP/2 응답(264(x))을 HTTP/1.x 응답(234(x))으로 변환한다. 그 후 파이어 앤 포겟 핸들러(320)는 HTTP/1.x 응답(234(x))을 http.responseWriter에 기입한다. 이에 응답하여, http.responseWriter은 HTTP/1.x 요청(232(x))이 수신된 클라이언트/프록시 TCP 연결(230)을 통해 HTTP/1.x 응답(234(x))을 송신한다.

그러나, HTTP/1.x 요청(232(x))에 대해 오프로딩이 활성이 아니면, 파이어 앤 포겟 핸들러(320)는 오프로딩 동작들(326) 내부에서 실행을 재개한다. HTTP/2 응답(264(x))의 상태 코드가 성공을 지시하면, 파이어 앤 포겟 핸들러(320)는 실행 스레드를 종료한다. 그렇지 않으면, 파이어 앤 포겟 핸들러(320)는 HTTP/1.x 요청(232(x))과 연관된 지속성 레벨에 대응하는 에러 핸들링 절차를 실행한다.

본 명세서에서 앞서 기술된 바와 같이, HTTP/2 응답(264(x))의 상태 코드가 HTTP/1.x 요청(232(x))과 연관된 성공 코드 리스트에 포함된 상태 코드들 중 하나와 일치하면, 파이어 앤 포겟 핸들러(320)는 HTTP/2 응답(264(x))이 성공을 지시한다고 결정한다. 그렇지 않으면, 파이어 앤 포겟 핸들러(320)는 HTTP/2 응답(264(x))이 성공을 지시하지 않는다고 결정한다. 일반적으로, 백-엔드 서버(270)는 HTTP/2 응답(264(x))에 임의의 상태 코드를 포함시킬 수 있다. 결과적으로, 백-엔드 서버(270)에 의해 HTTP/2 응답(264(x))이 생성된다면, HTTP/2 응답(264(x))은 성공 코드 리스트에 따라 성공을 지시할 수 있거나 그렇지 않을 수 있다. 대조적으로, 백-엔드 서버(270)가 HTTP/2 요청(262(x))에 응답하지 못했음을 지시하기 위해 프록시 핸들러(340)에 의해 HTTP/2 응답(264(x))이 생성된다면, HTTP/2 응답(264(x))은 성공 코드 리스트에 따라 성공을 지시하지 않는다.

파이어 앤 포겟 핸들러(320)는, 에러 핸들링 절차를 실행하는 것의 일부로서, 실행 스레드가 파이어 앤 포겟 핸들러(320)와 프록시 핸들러(340) 간에 앞뒤로 반복적으로 전파되게 할 수 있다. 에러 핸들링 절차는 다사다난하게 실행 스레드를 종료한다.

본 명세서에 기술된 프록시 애플리케이션(250)은 예시적인 것이고 변형들 및 수정들이 가능하다는 것을 알 것이다. 예를 들어, 대안의 실시예들에서는, 파이어 앤 포겟 핸들러(320)가 임의의 기술적으로 실현가능한 방식으로 HTTP/요청(232(x))에 대해 오프로딩이 활성인지를 프록시 핸들러(340)에 지시할 수 있다. HTTP/요청(232(x))에 대해 오프로딩이 활성이 아니면, 프록시 핸들러(340)는 HTTP/1.x 응답(234(x))을 생성하여 http.responseWriter에 기입한다. 그 후 프록시 핸들러(340)는 실행 스레드를 종료한다.

단지 설명 목적으로, 도 3은 클라이언트 애플리케이션(220(1))으로부터 수신되는 도 2의 HTTP/1.x 요청(232(3))과 연관된 실행 스레드의 제어를 일련의 번호가 매겨진 버블들로서 묘사한다. HTTP/1.x 요청(232(3))은 요청 라인, HOST 헤더, 파이어 앤 포겟 헤더, 및 본문을 제한 없이 포함한다. 요청 라인은 POST 메서드, 요청 목표 "/upload", 및 프로토콜 버전 HTTP/1.1을 특정한다. POST 메서드는 요청 목표 "/upload"를 생성 또는 수정하기 위해 백-엔드 서버(270)에 HTTP/1.x 요청(232(3))의 본문(도시되지 않음)을 전송한다. HOST 헤더는 백-엔드 서버(270)의 도메인 명칭 "www.XYZ.com"을 특정한다. 파이어 앤 포겟 헤더는 명칭 "Fire-and-Forget" 및 200의 상태 코드를 포함하는 성공 코드 리스트를 특정한다. HTTP/1.x 요청(232(3))이 지속성 헤더를 포함하고 있지 않기 때문에, HTTP/1.x 요청(232(3))은 높음의 디폴트 지속성 레벨과 연관된다.

1로 번호가 매겨진 버블로 묘사된 바와 같이, HTTP/1.x 요청(232(3))과 연관된 실행 스레드가 HTTP 라이브러리 계층(310)에 들어간다. HTTP 라이브러리 계층(310)은 HTTP/1.x 요청(232(3))을 나타내는 http.Request 및 http.responseWriter을 생성하고 이어서 파이어 앤 포겟 핸들러(320)에 제어를 전달한다. HTTP/1.x 요청(232(3))이 파이어 앤 포겟 헤더를 포함하고 있기 때문에, 파이어 앤 포겟 핸들러(320)는 최대 동시 오프로드들(322)에 기초하여 HTTP/1.x 요청(232(3))에 대해 오프로딩을 활성화할지를 결정한다. 단지 설명 목적으로, 오프로딩이 활성인 HTTP/1.x 요청(232)의 총수는 최대 동시 오프로드들(322)보다 작다. 그러므로, 파이어 앤 포겟 핸들러(320)는 HTTP/1.x 요청(232(3))에 대해 오프로딩을 활성화하고 오프로딩 동작들(326)을 실행하기 시작한다.

2로 번호가 매겨진 버블로 묘사된 바와 같이, 파이어 앤 포겟 핸들러(320)는 논블로킹 방식으로 성공적인 일반 HTTP 응답(234(x))을 클라이언트 애플리케이션(220(1))에 송신하도록 http.responseWriter을 구성한다. 그 후 파이어 앤 포겟 핸들러(320)는 프록시 핸들러(340)가 실행 스레드의 제어를 수신할 때까지 실행 스레드가 파이프라인을 통해 순방향으로 전파되게 한다. 프록시 핸들러(340)는 HTTP/1.x 요청(232(3))을 HTTP/2 요청(262(3))으로 변환한다.

3으로 번호가 매겨진 버블로 묘사된 바와 같이, 프록시 핸들러(340)는 HTTP/2 요청(262(3))을 백-엔드 서버(270)에 송신한다. 그 후 실행 스레드는 4로 번호가 매겨진 버블로 묘사된 "504 Gateway Timeout" HTTP 상태 라인을 특정하는 HTTP/2 응답(264(3))을 수신한다. 후속하여, 프록시 핸들러(340)는 실행 스레드가 파이어 앤 포겟 핸들러(320)에 도달할 때까지 파이프라인을 통해 역방향으로 전파되게 한다.

파이어 앤 포겟 핸들러(320)는 오프로딩 동작들(326) 내부에서 실행을 재개한다. HTTP/2 응답(264(3))이 성공적인 상태 코드를 특정하고 있지 않기 때문에, 파이어 앤 포겟 핸들러(320)는 높음의 지속성 레벨에 대응하는 에러 핸들러 프로세스를 실행한다. 보다 구체적으로는 그리고 5로 번호가 매겨진 버블로 묘사된 바와 같이, 파이어 앤 포겟 핸들러(320)는 재송신 시도(328)를 수행한다. 파이어 앤 포겟 핸들러(320)는, 재송신 시도(328)를 실행하기 위해, 프록시 핸들러(320(1))에 실행 스레드의 제어를 전달하고, 실행 스레드는 프록시 핸들러(340)에 도달할 때까지 파이프라인을 통해 순방향으로 재전파된다.

6으로 번호가 매겨진 버블로 묘사된 바와 같이, 프록시 핸들러(340)는 HTTP/2 요청(262(3))을 백-엔드 서버(270)에 재송신하려고 시도한다. 후속하여 그리고 7로 번호가 매겨진 버블로 묘사된 바와 같이, 프록시 핸들러(340)는 "200 OK"의 HTTP 상태 라인을 특정하는 HTTP/2 응답(264(3'))을 수신한다. 프록시 핸들러(340)는 실행 스레드가 파이어 앤 포겟 핸들러(320)에 도달할 때까지 파이프라인을 통해 역방향으로 재전파되게 한다. 파이어 앤 포겟 핸들러(320)는 에러 핸들링 프로세스 내부에서 실행을 재개한다. HTTP/2 응답(264(3'))의 상태 코드가 성공을 지시하고 있기 때문에, 파이어 앤 포겟 핸들러(320)는 실행 스레드를 종료한다.

본 명세서에 기술된 기법들은 제한적인 것이 아니라 예시적인 것이고, 본 발명의 더 넓은 사상 및 범위를 벗어나지 않고 변경될 수 있다는 점에 유의한다. 본 기술분야의 통상의 기술자들은 기술된 실시예들 및 기법들의 범위 및 사상을 벗어나지 않고 많은 수정들 및 변형들을 알 수 있을 것이다. 특히, 프록시 애플리케이션(250)의 기능성이 임의의 기술적으로 실현가능한 방식으로 구현될 수 있다. 예를 들어, 대안의 실시예들에서는, 프록시 애플리케이션(250)이 HTTP 핸들러 기능들의 파이프라인 대신에 임의의 수(하나를 포함함) 및 유형의 기능들을 포함할 수 있다.

도 4는 본 발명의 다양한 실시예들에 따른, 네트워크 기반 서비스와 연관된 요청을 처리하기 위한 방법 단계들의 흐름도이다. 비록 방법 단계들이 도 1 내지 도 3의 시스템들에 관련하여 기술되지만, 본 기술분야의 기술자들은 방법 단계들을 임의의 순서로 구현하도록 구성되는 임의의 시스템이 본 발명의 범위 안에 포함된다는 것을 이해할 것이다.

도시된 바와 같이, 방법(400)은, 프록시 애플리케이션(250)이 클라이언트 애플리케이션들(220) 중 하나로부터 HTTP 요청을 수신하는 단계 402에서 시작된다. HTTP 요청은 HTTP/1.x 포맷(즉, HTTP/1.x 요청(232(x))) 또는 HTTP/2 포맷(즉, HTTP/2 요청(262(x)))일 수 있다. 단계 404에서는, 파이어 앤 포겟 핸들러(320)가 HTTP 요청이 파이어 앤 포겟 헤더 및 옵션으로 최대 동시 오프로드들(322)을 포함하고 있는지 여부에 기초하여 HTTP 요청에 대해 오프로딩을 활성화할지를 결정한다. 단계 406에서는, 파이어 앤 포겟 핸들러(320)가 HTTP 요청에 대해 오프로딩이 활성인지를 결정한다. 단계 406에서, 파이어 앤 포겟 핸들러(320)가 HTTP 요청에 대해 오프로딩이 활성이라고 결정하면, 방법(400)은 단계 408로 진행한다.

단계 408에서는, 파이어 앤 포겟 핸들러(320)가 HTTP 요청과 연관된 HTTP의 버전으로 성공적인 일반 HTTP 응답을 클라이언트 애플리케이션(220)에 송신한다. 단계 410에서는, 프록시 핸들러(340)가 HTTP 요청에 대응하는 HTTP/2 요청(262)을 백-엔드 서버(270)에 송신하려고 시도한다. HTTP 요청에 대응하는 HTTP/2 요청(262)은 HTTP 요청일 수 있다. 단계 412에서는, 파이어 앤 포겟 핸들러(320)가 프록시 핸들러(340)가 성공을 지시하는 HTTP/2 응답(264)을 수신했는지를 결정한다. 단계 412에서, 파이어 앤 포겟 핸들러(320)가 프록시 핸들러(340)가 성공을 지시하는 HTTP/2 응답(264)을 수신했다고 결정하면, 방법(400)은 종료된다.

그러나, 단계 412에서, 파이어 앤 포겟 핸들러(320)가 프록시 핸들러(340)가 성공을 지시하는 HTTP/2 응답(264)을 수신하지 않았다고 결정하면, 방법(400)은 단계 414로 진행한다. 단계 414에서는, 파이어 앤 포겟 핸들러(320)가 지속성 레벨에 기초하여 에러 핸들링 프로세스를 실행한다. 지속성 레벨은 HTTP 요청의 지속성 헤더에 특정되거나 디폴트 지속성 레벨과 동등하다. 에러 핸들링 프로세스는 임의의 수(0을 포함함)의 재송신 시도들(328)을 수반할 수 있다. 그 후 방법(400)은 종료된다.

이제 단계 408로 돌아가서, 파이어 앤 포겟 핸들러(320)가 HTTP 요청에 대해 오프로딩이 활성이 아니라고 결정하면, 방법(400)은 바로 단계 416으로 진행한다. 단계 416에서는, 프록시 핸들러(340)가 HTTP 요청에 대응하는 HTTP/2 요청(262)을 백-엔드 서버(270)에 송신하려고 시도한다. HTTP 요청에 대응하는 HTTP/2 요청(262)은 HTTP 요청일 수 있다.

단계 418에서는, 프록시 핸들러(340)가 대응하는 HTTP/2 응답(264)이 백-엔드 서버(270)로부터 수신되었는지를 결정한다. 단계 418에서, 프록시 핸들러(340)가 대응하는 HTTP/2 응답(264)이 백-엔드 서버(270)로부터 수신되었다고 결정하면, 방법(400)은 바로 단계 422로 진행한다. 단계 418에서, 프록시 핸들러(340)가 대응하는 HTTP/2 응답(264)이 백-엔드 서버(270)로부터 수신되지 않았다고 결정하면, 방법(400)은 단계 420으로 진행한다. 단계 420에서는, 프록시 핸들러(340)가 서버 에러 HTTP/2 응답(264)을 생성하고 방법(400)은 단계 422로 진행한다.

단계 422에서는, 파이어 앤 포겟 핸들러(320)가 HTTP/2 응답(264)의 버전을 클라이언트 애플리케이션(220)에 전송한다. 클라이언트 애플리케이션(220)으로부터 수신된 HTTP 요청이 HTTP/2 포맷이면, 파이어 앤 포겟 핸들러(320)는 HTTP/2 응답(264)을 클라이언트 애플리케이션(220)에 송신한다. 그렇지 않으면, 파이어 앤 포겟 핸들러(320)는 HTTP/2 응답(264)을 HTTP/1.x 응답(234)으로 변환하고 HTTP/1.x 응답(234)을 클라이언트 애플리케이션(220)에 송신한다. 그 후 방법(400)은 종료된다.

요컨대, 개시된 기법들을 이용하여, 프록시 애플리케이션은 TCP를 통한 HTTP/1.x를 구현하는 클라이언트 애플리케이션이 네트워크 기반 서비스에 액세스하기 위해 백-엔드 서버와 효율적으로 상호작용하는 것을 가능하게 할 수 있다. 클라이언트 애플리케이션은 대응하는 HTTP 응답이 중요하지 않음을 지시하기 위해 정보 제공 업로드에 대한 HTTP 요청에 "파이어 앤 포겟" 헤더를 추가할 수 있다. 파이어 앤 포겟 헤더는 성공적인 것으로 간주되어야 하는 상태 코드들의 성공 코드 리스트를 특정한다. 파이어 앤 포겟 헤더는 디폴트 지속성 레벨과 연관되고, 클라이언트 애플리케이션은 지속성 레벨을 명시적으로 특정하는 "지속성" 헤더를 HTTP 요청에 추가할 수 있다. 지속성 레벨은 HTTP 요청을 수신하는 백-엔드 서버에 대한 중요성의 레벨과 상관된다.

프록시 애플리케이션은 클라이언트 애플리케이션과 백-엔드 서버 간의 중개자의 역할을 하는 프록시 서버 상에서 실행된다. 프록시 애플리케이션은, 클라이언트 애플리케이션으로부터 HTTP 요청을 수신하면, HTTP 요청에 대해 오프로딩을 활성화할지를 결정한다. HTTP 요청이 파이어 앤 포겟 헤더를 가지고 있고 동시 오프로드들의 최대 수에 도달하지 않았다면, 프록시 애플리케이션은 HTTP 요청에 대해 오프로딩을 활성화한다. 그렇지 않으면, 프록시 애플리케이션은 HTTP 요청에 대해 파이어 앤 포겟을 활성화하지 않는다.

HTTP 요청에 대해 오프로딩이 활성이면, 프록시 애플리케이션은 성공적인 일반 HTTP 응답을 클라이언트에 송신한다. 성공적인 일반 HTTP 응답은 성공 코드 리스트에 포함된 상태 코드들 중 하나를 특정하고, 이로써 백-엔드 서버가 HTTP 요청을 성공적으로 수신하고 처리했음을 의도적으로 그리고 잘못되게 지시한다. 그 후 프록시 애플리케이션은 HTTP 요청의 HTTP/2 버전을 백-엔드 서버에 송신하려고 시도한다. 프록시 애플리케이션이 성공 코드 리스트에 따라 성공을 지시하는 HTTP/2 응답을 수신하면, 프록시 애플리케이션은 HTTP/2 응답을 폐기한다. 그렇지 않으면, 프록시 애플리케이션은 지속성 레벨에 기초하여 에러 핸들링 프로세스를 실행한다. 에러 핸들링 프로세스는 임의의 수의 재송신 시도들을 수반할 수 있다.

HTTP 요청에 대해 오프로딩이 활성이 아니면, 프록시 애플리케이션은 HTTP/1.x 요청의 HTTP/2 버전을 백-엔드 서버에 송신하려고 시도한다. 프록시 애플리케이션이 백-엔드 서버로부터 HTTP/2 응답을 수신하지 않으면, 프록시 애플리케이션은 서버 에러 HTTP/1.x 응답을 클라이언트 애플리케이션에 송신한다. 그렇지 않으면, 프록시 애플리케이션은 백-엔드 서버로부터 수신된 HTTP/2 응답의 HTTP/1.x 버전을 클라이언트 애플리케이션에 송신한다.

종래 기술에 비해 개시된 기법들의 적어도 하나의 기술적 이점은, 개시된 기법들에 의하면, TCP를 통한 HTTP/1.x를 구현하는 클라이언트 애플리케이션에 대해 interactive HTTP 트랜잭션들이 informational HTTP 트랜잭션들에 의해 지연될 가능성이 적다는 점이다. 특히, 프록시 서버가 클라이언트 애플리케이션으로부터 송신된 informational HTTP 트랜잭션에 응답하자마자, 클라이언트 애플리케이션은 백-엔드 서버로부터의 응답을 기다릴 필요 없이 연관된 TCP 연결을 폐쇄 또는 재사용할 수 있다. 따라서, 클라이언트 애플리케이션이 모든 이용가능한 TCP 연결들을 informational HTTP 트랜잭션들을 위해 이용하고 interactive HTTP 트랜잭션들의 송신 및 처리를 지연시킬 가능성이 적다. 또한, 프록시 서버가 후속하여 informational HTTP 트랜잭션과 연관된 정보를 백-엔드 서버에 업로드하려고 시도하기 때문에, 정보가 결국 드롭되게 될 가능성이 증가되지 않는다. 그리고 프록시 서버가 미리 확립되고 미리 인증된 TCP 연결들을 이용하여 HTTP/2를 통해 백-엔드 서버와 통신하므로, 클라이언트 애플리케이션과 백-엔드 서버 간의 통신 시간들이 단축된다. 이들 기술적 이점은 종래 기술의 접근법들에 비해 하나 이상의 기술 진보를 나타낸다.

1. 일부 실시예들에서는, 방법이 클라이언트 애플리케이션으로부터 수신된 제1 요청이 서버 머신으로부터 상기 제1 요청에 대한 응답이 오프로딩될 수 있음을 지시한다고 결정하는 단계; 및 상기 제1 요청을 상기 서버 머신에 송신하기 전에, 상기 서버 머신이 상기 제1 요청을 성공적으로 처리했음을 지시하는 상기 제1 요청에 대한 제1 응답을 상기 클라이언트 애플리케이션에 송신하는 단계를 포함하고, 상기 클라이언트 애플리케이션은, 상기 제1 응답을 수신하면, 제2 요청을 개시할 수 있다.

2. 조항 1의 방법으로서, 상기 제1 요청은 상기 서버 머신이 상기 제1 요청을 성공적으로 처리했음을 지시하는 상태 코드를 포함한다.

3. 조항 1 또는 조항 2의 방법으로서, 상기 제1 요청은 HTTP(Hypertext Transmission Protocol)/1.x와 연관되고, 상기 제1 요청을 상기 서버 머신에 송신하는 단계는 상기 제1 요청에 기초하여 HTTP/2와 연관된 제2 요청을 생성하는 단계; 및 상기 제2 요청을 상기 서버 머신에 제1 TCP(Transmission Control Protocol) 연결을 통해 HTTP/2와 연관된 적어도 제3 요청과 함께 다중 송신하는 단계를 포함한다.

4. 조항 1 내지 조항 3 중 어느 하나의 방법으로서, 상기 서버 머신이 상기 제1 요청을 성공적으로 처리하지 않았다고 결정하는 단계; 상기 제1 요청이 제1 지속성 레벨을 지시한다고 결정하는 단계; 및 상기 제1 지속성 레벨에 기초하여 하나 이상의 에러 핸들링 동작을 수행하는 단계 - 상기 하나 이상의 에러 핸들링 동작은 상기 서버 머신으로 하여금 상기 제1 요청을 성공적으로 처리하게 함 - 를 추가로 포함한다.

5. 조항 1 내지 조항 4 중 어느 하나의 방법으로서, 상기 제1 요청이 제1 지속성 레벨을 지시한다고 결정하는 단계는 상기 제1 요청이 상기 제1 지속성 레벨에 대응하는 지속성 파라미터에 대한 값을 특정하는 헤더 부분을 포함한다고 결정하는 단계를 포함한다.

6. 조항 1 내지 조항 5 중 어느 하나의 방법으로서, 상기 제1 요청은 상기 서버 머신에 업로드되고 있는 정보 제공 데이터를 포함한다.

7. 조항 1 내지 조항 6 중 어느 하나의 방법으로서, 상기 서버 머신으로부터 상기 제1 요청에 대한 제2 응답을 수신하는 단계; 및 상기 제2 응답을 상기 클라이언트 애플리케이션에 송신하는 대신에, 상기 제2 응답을 폐기하는 단계를 추가로 포함한다.

8. 조항 1 내지 조항 7 중 어느 하나의 방법으로서, 상기 클라이언트 애플리케이션은 TCP(Transmission Control Protocol) 연결을 통해 상기 제1 응답을 수신하고 상기 TCP 연결을 재사용하거나 재생성하여 상기 제2 요청을 개시한다.

9. 조항 1 내지 조항 8 중 어느 하나의 방법으로서, 상기 클라이언트 애플리케이션으로부터 수신된 상기 제2 요청이 상기 서버 머신으로부터 상기 제2 요청에 대한 응답이 오프로딩될 수 있음을 지시하지 않는다고 결정하는 단계; 상기 제2 요청을 바로 상기 서버 머신에 송신하는 단계; 및 상기 서버 머신으로부터 상기 제2 요청에 대한 제2 응답을 수신하면, 상기 제2 응답을 상기 클라이언트 애플리케이션에 송신하는 단계를 추가로 포함한다.

10. 조항 1 내지 조항 9 중 어느 하나의 방법으로서, 상기 제1 요청이 상기 제1 요청에 대한 응답이 오프로딩될 수 있음을 지시한다고 결정하는 단계는 상기 제1 요청이 상기 제1 요청에 대한 응답이 중요하지 않음을 지시하는 헤더 부분을 포함하는 것을 식별하는 단계를 포함한다.

11. 일부 실시예들에서는, 컴퓨터 구현 컴퓨터 판독가능 스토리지 매체가 명령어들을 포함하고, 이 명령어들은 프로세서에 의해 실행될 때, 상기 프로세서로 하여금 클라이언트 애플리케이션으로부터 수신된 제1 요청이 서버 머신으로부터 오프로딩될 수 있다고 결정하는 단계; 및 상기 제1 요청을 상기 서버 머신에 송신하기 전에, 상기 서버 머신이 상기 제1 요청을 성공적으로 처리했음을 지시하는 상기 제1 요청에 대한 제1 응답을 상기 클라이언트 애플리케이션에 송신하는 단계를 수행하게 하고, 상기 클라이언트 애플리케이션은, 상기 제1 응답을 수신하면, 제2 요청을 개시할 수 있다.

12. 조항 11의 하나 이상의 비일시적 컴퓨터 판독가능 매체로서, 상기 제1 요청은 HTTP(Hypertext Transmission Protocol)/1.x와 연관되고, 상기 제1 요청을 상기 서버 머신에 송신하는 단계는 상기 제1 요청에 기초하여 HTTP/2와 연관된 제2 요청을 생성하는 단계; 및 상기 제2 요청을 상기 서버 머신에 제1 TCP(Transmission Control Protocol) 연결을 통해 HTTP/2와 연관된 적어도 제3 요청과 함께 다중 송신하는 단계를 포함한다.

13. 조항 11 또는 조항 12의 하나 이상의 비일시적 컴퓨터 판독가능 매체로서, 상기 서버 머신이 상기 제1 요청을 성공적으로 처리하지 않았다고 결정하는 단계; 상기 제1 요청이 제1 지속성 레벨을 지시한다고 결정하는 단계; 및 상기 제1 지속성 레벨에 기초하여 하나 이상의 에러 핸들링 동작을 수행하는 단계 - 상기 하나 이상의 에러 핸들링 동작은 상기 서버 머신으로 하여금 상기 제1 요청을 성공적으로 처리하게 함 - 를 추가로 포함한다.

14. 조항 11 내지 조항 13 중 어느 하나의 하나 이상의 비일시적 컴퓨터 판독가능 매체로서, 상기 하나 이상의 에러 핸들링 동작은 상기 제1 요청을 영구 스토리지에 저장하는 하나 이상의 기입 동작을 포함한다.

15. 조항 11 내지 조항 14 중 어느 하나의 하나 이상의 비일시적 컴퓨터 판독가능 매체로서, 상기 제1 요청은 이벤트 로그, 상기 클라이언트 애플리케이션이 적절하게 실행중임을 지시하는 하트비트, 및 메트릭 로그 중 적어도 하나를 포함한다.

16. 조항 11 내지 조항 15 중 어느 하나의 하나 이상의 비일시적 컴퓨터 판독가능 매체로서, 상기 서버 머신으로부터 상기 제1 요청에 대한 제2 응답을 수신하는 단계; 및 상기 제2 응답을 상기 클라이언트 애플리케이션에 송신하는 대신에, 상기 제2 응답을 폐기하는 단계를 추가로 포함한다.

17. 조항 11 내지 조항 16 중 어느 하나의 하나 이상의 비일시적 컴퓨터 판독가능 매체로서, 상기 클라이언트 애플리케이션은 TCP(Transmission Control Protocol) 연결을 통해 상기 제1 응답을 수신하고 상기 TCP 연결을 재사용하거나 재생성하여 상기 제2 요청을 개시한다.

18. 조항 11 내지 조항 17 중 어느 하나의 하나 이상의 비일시적 컴퓨터 판독가능 매체로서, 상기 클라이언트 애플리케이션으로부터 수신된 상기 제2 요청이 상기 서버 머신으로부터 오프로딩될 수 있다고 결정하는 단계; 동시 오프로드들의 현재 수가 동시 오프로드들의 최대 수와 동등하다고 결정하는 단계; 상기 제2 요청을 바로 상기 서버 머신에 송신하는 단계; 및 상기 서버 머신으로부터 상기 제2 요청에 대한 제2 응답을 수신하면, 상기 제2 응답을 상기 클라이언트 애플리케이션에 송신하는 단계를 추가로 포함한다.

19. 조항 11 내지 조항 18 중 어느 하나의 하나 이상의 비일시적 컴퓨터 판독가능 매체로서, 상기 제1 요청이 오프로딩될 수 있다고 결정하는 단계는 상기 제1 요청이 상기 제1 요청에 대한 응답이 중요하지 않음을 지시하는 헤더 부분을 포함하는 것을 식별하는 단계를 포함한다.

20. 일부 실시예들에서는, 시스템이 명령어들을 저장하는 하나 이상의 메모리; 및 상기 하나 이상의 메모리에 결합되는 하나 이상의 프로세서를 포함하고, 상기 하나 이상의 프로세서는, 상기 명령어들을 실행할 때, 제1 연결을 통해 클라이언트 애플리케이션으로부터 수신된 제1 요청이 서버 머신으로부터 상기 제1 요청에 대한 응답이 오프로딩될 수 있음을 지시한다고 결정하고; 상기 제1 요청을 상기 서버 머신에 송신하기 전에, 상기 서버 머신이 상기 제1 요청을 성공적으로 처리했음을 지시하는 상기 제1 요청에 대한 제1 응답을 상기 클라이언트 애플리케이션에 송신하도록 구성되고, 상기 클라이언트 애플리케이션은, 상기 제1 응답을 수신하면, 상기 제1 연결을 재사용하거나 재생성하여 제2 요청을 개시할 수 있다.

임의의 방식으로, 청구항들 중 임의의 것에 기재된 청구항 요소들 중 임의의 것 및/또는 본 출원에서 기술된 임의의 요소들의 임의의 및 모든 조합들은 본 발명 및 보호의 고려되는 범위 안에 포함된다.

다양한 실시예들에 대한 설명들은 예시 목적으로 제시된 것이지, 총체적(exhaustive)이도록 또는 개시된 실시예들로 제한되도록 의도된 것은 아니다. 본 기술분야의 통상의 기술자들은 기술된 실시예들의 범위 및 사상을 벗어나지 않고 많은 수정들 및 변형들을 알 수 있을 것이다.

본 실시예들의 양태들은 시스템, 방법 또는 컴퓨터 프로그램 제품으로서 구현될 수 있다. 따라서, 본 개시내용의 양태들은 전적으로 하드웨어 실시예, 전적으로 소프트웨어 실시예(펌웨어, 상주 소프트웨어, 마이크로-코드 등을 포함함) 또는 본 명세서에서 모두 일반적으로 "모듈", "시스템", 또는 "컴퓨터"라고 지칭될 수 있는 소프트웨어 및 하드웨어 양태들을 조합한 실시예의 형태를 취할 수 있다. 또한, 본 개시내용에서 기술된 임의의 하드웨어 및/또는 소프트웨어 기법, 프로세스, 기능, 컴포넌트, 엔진, 모듈, 또는 시스템은 회로 또는 회로들의 세트로서 구현될 수 있다. 또한, 본 개시내용의 양태들은 컴퓨터 판독가능 프로그램 코드가 구현되어 있는 하나 이상의 컴퓨터 판독가능 매체(들)에 구현된 컴퓨터 프로그램 제품의 형태를 취할 수 있다.

하나 이상의 컴퓨터 판독가능 매체(들)의 임의의 조합이 이용될 수 있다. 컴퓨터 판독가능 매체는 컴퓨터 판독가능 신호 매체 또는 컴퓨터 판독가능 스토리지 매체일 수 있다. 컴퓨터 판독가능 스토리지 매체는, 예를 들어, 전자, 자기, 광학, 전자기, 적외선, 또는 반도체 시스템, 장치, 또는 디바이스, 또는 전술한 것들의 임의의 적합한 조합일 수 있지만, 이들로 제한되지 않는다. 컴퓨터 판독가능 스토리지 매체의 보다 구체적인 예들(비총체적인 리스트)은 다음에 언급된 것들을 포함할 것이다: 하나 이상의 와이어를 갖는 전기 연결, 휴대용 컴퓨터 디스켓, 하드 디스크, RAM(random access memory), ROM(read-only memory), EPROM(erasable programmable read-only memory) 또는 플래시 메모리, 광섬유, 휴대용 CD-ROM(compact disc read-only memory), 광학 스토리지 디바이스, 자기 스토리지 디바이스, 또는 전술한 것들의 임의의 적합한 조합. 본 문서의 컨텍스트에서, 컴퓨터 판독가능 스토리지 매체는 명령어 실행 시스템, 장치, 또는 디바이스에 의해 또는 그와 관련하여 사용하기 위한 프로그램을 포함하거나 저장할 수 있는 임의의 유형 매체일 수 있다.

위에서는 본 개시내용의 실시예들에 따른 방법들, 장치(시스템들) 및 컴퓨터 프로그램 제품들의 플로차트 예시들 및/또는 블록도들에 관련하여 본 개시내용의 양태들이 기술되었다. 플로차트 예시들 및/또는 블록도들의 각각의 블록, 및 플로차트 예시들 및/또는 블록도들 내의 블록들의 조합들은 컴퓨터 프로그램 명령어들에 의해 구현될 수 있다는 것을 이해할 것이다. 이들 컴퓨터 프로그램 명령어는 머신을 생성하기 위해 범용 컴퓨터, 특수 목적 컴퓨터, 또는 다른 프로그래머블 데이터 처리 장치의 프로세서에 제공될 수 있다. 명령어들은, 컴퓨터 또는 다른 프로그래머블 데이터 처리 장치의 프로세서를 통해 실행될 때, 플로차트 및/또는 블록도의 블록 또는 블록들에 특정된 기능들/동작들의 구현을 가능하게 한다. 그러한 프로세서들은, 제한 없이, 범용 프로세서들, 특수 목적 프로세서들, 응용 특정 프로세서들, 또는 필드 프로그래머블 게이트 어레이들일 수 있다.

도면들 내의 플로차트 및 블록도들은 본 개시내용의 다양한 실시예들에 따른 시스템들, 방법들 및 컴퓨터 프로그램 제품들의 가능한 구현들의 아키텍처, 기능성, 및 동작을 예시한다. 이와 관련하여, 플로차트 또는 블록도들 내의 각각의 블록은 특정된 논리 기능(들)을 구현하기 위한 하나 이상의 실행가능 명령어를 포함하는 모듈, 세그먼트, 또는 코드의 일부를 나타낼 수 있다. 일부 대안적인 구현들에서는, 블록에서 언급된 기능들이 도면들에서 언급된 순서를 벗어나 발생할 수 있다는 점에도 유의해야 한다. 예를 들어, 연속적으로 도시된 2개의 블록이, 사실상, 실질적으로 동시에 실행될 수 있거나, 그 블록들이, 수반된 기능성에 따라, 때때로 역순으로 실행될 수 있다. 블록도들 및/또는 플로차트 예시의 각각의 블록, 및 블록도들 및/또는 플로차트 예시 내의 블록들의 조합들이 특정된 기능들 또는 동작들을 수행하는 특수 목적 하드웨어 기반 시스템들, 또는 특수 목적 하드웨어 및 컴퓨터 명령어들의 조합들에 의해 구현될 수 있다는 점에도 유의해야 할 것이다.

전술한 내용은 본 개시내용의 실시예들에 관한 것이지만, 그것의 기본적인 범위를 벗어나지 않고 본 개시내용의 다른 그리고 추가 실시예들이 고안될 수 있고, 그것의 범위는 다음에 오는 청구항들에 의해 결정된다.

Claims

컴퓨터 구현 방법으로서,
상기 방법은:
클라이언트 애플리케이션으로부터 수신된 제1 요청이 서버 머신으로부터 상기 제1 요청에 대한 응답이 오프로딩될 수 있음을 지시한다고 결정하는 단계; 및
상기 제1 요청을 상기 서버 머신에 송신하기 전에, 상기 서버 머신이 상기 제1 요청을 성공적으로 처리했음을 지시하는 상기 제1 요청에 대한 제1 응답을 상기 클라이언트 애플리케이션에 송신하는 단계를 포함하고,
상기 클라이언트 애플리케이션은, 상기 제1 응답을 수신하면, 제2 요청을 개시할 수 있는, 방법.
제1항에 있어서,
상기 제1 요청은 상기 서버 머신이 상기 제1 요청을 성공적으로 처리했음을 지시하는 상태 코드를 포함하는, 방법.
제1항에 있어서,
상기 제1 요청은 HTTP(Hypertext Transmission Protocol)/1.x와 연관되고, 상기 제1 요청을 상기 서버 머신에 송신하는 단계는:
상기 제1 요청에 기초하여 HTTP/2와 연관된 제2 요청을 생성하는 단계; 및
상기 제2 요청을 상기 서버 머신에 제1 TCP(Transmission Control Protocol) 연결을 통해 HTTP/2와 연관된 적어도 제3 요청과 함께 다중 송신하는 단계를 포함하는, 방법.
제1항에 있어서,
상기 서버 머신이 상기 제1 요청을 성공적으로 처리하지 않았다고 결정하는 단계;
상기 제1 요청이 제1 지속성 레벨을 지시한다고 결정하는 단계; 및
상기 제1 지속성 레벨에 기초하여 하나 이상의 에러 핸들링 동작을 수행하는 단계 - 상기 하나 이상의 에러 핸들링 동작은 상기 서버 머신으로 하여금 상기 제1 요청을 성공적으로 처리하게 함 - 를 추가로 포함하는, 방법.
제4항에 있어서,
상기 제1 요청이 제1 지속성 레벨을 지시한다고 결정하는 단계는 상기 제1 요청이 상기 제1 지속성 레벨에 대응하는 지속성 파라미터에 대한 값을 특정하는 헤더 부분을 포함한다고 결정하는 단계를 포함하는, 방법.
제1항에 있어서,
상기 제1 요청은 상기 서버 머신에 업로드되고 있는 정보 제공 데이터를 포함하는, 방법.
제1항에 있어서,
상기 서버 머신으로부터 상기 제1 요청에 대한 제2 응답을 수신하는 단계; 및
상기 제2 응답을 상기 클라이언트 애플리케이션에 송신하는 대신에, 상기 제2 응답을 폐기하는 단계를 추가로 포함하는, 방법.
제1항에 있어서,
상기 클라이언트 애플리케이션은 TCP(Transmission Control Protocol) 연결을 통해 상기 제1 응답을 수신하고 상기 TCP 연결을 재사용하거나 재생성하여 상기 제2 요청을 개시하는, 방법.
제1항에 있어서,
상기 클라이언트 애플리케이션으로부터 수신된 상기 제2 요청이 상기 서버 머신으로부터 상기 제2 요청에 대한 응답이 오프로딩될 수 있음을 지시하지 않는다고 결정하는 단계;
상기 제2 요청을 바로 상기 서버 머신에 송신하는 단계; 및
상기 서버 머신으로부터 상기 제2 요청에 대한 제2 응답을 수신하면, 상기 제2 응답을 상기 클라이언트 애플리케이션에 송신하는 단계를 추가로 포함하는, 방법.
제1항에 있어서,
상기 제1 요청이 상기 제1 요청에 대한 응답이 오프로딩될 수 있음을 지시한다고 결정하는 단계는 상기 제1 요청이 상기 제1 요청에 대한 응답이 중요하지 않음을 지시하는 헤더 부분을 포함하는 것을 식별하는 단계를 포함하는, 방법.
명령어들을 저장하는 하나 이상의 비일시적 컴퓨터 판독가능 매체로서, 상기 명령어들은, 하나 이상의 프로세서에 의해 실행될 때, 상기 하나 이상의 프로세서로 하여금:
클라이언트 애플리케이션으로부터 수신된 제1 요청이 서버 머신으로부터 오프로딩될 수 있다고 결정하는 단계; 및
상기 제1 요청을 상기 서버 머신에 송신하기 전에, 상기 서버 머신이 상기 제1 요청을 성공적으로 처리했음을 지시하는 상기 제1 요청에 대한 제1 응답을 상기 클라이언트 애플리케이션에 송신하는 단계를 수행하게 하고,
상기 클라이언트 애플리케이션은, 상기 제1 응답을 수신하면, 제2 요청을 개시할 수 있는, 하나 이상의 비일시적 컴퓨터 판독가능 매체.
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
시스템으로서,
명령어들을 저장하는 하나 이상의 메모리; 및
상기 하나 이상의 메모리에 결합되는 하나 이상의 프로세서를 포함하고, 상기 하나 이상의 프로세서는, 상기 명령어들을 실행할 때,
제1 연결을 통해 클라이언트 애플리케이션으로부터 수신된 제1 요청이 서버 머신으로부터 상기 제1 요청에 대한 응답이 오프로딩될 수 있음을 지시한다고 결정하고;
상기 제1 요청을 상기 서버 머신에 송신하기 전에, 상기 서버 머신이 상기 제1 요청을 성공적으로 처리했음을 지시하는 상기 제1 요청에 대한 제1 응답을 상기 클라이언트 애플리케이션에 송신하도록 구성되고,
상기 클라이언트 애플리케이션은, 상기 제1 응답을 수신하면, 상기 제1 연결을 재사용하거나 재생성하여 제2 요청을 개시할 수 있는, 시스템.