KR20080015422A

KR20080015422A - 긴 지연 링크를 통한 ｈｔｔｐ의 성능을 향상시키는 방법및 장치

Info

Publication number: KR20080015422A
Application number: KR1020077028212A
Authority: KR
Inventors: 코링 창; 크리쉬나 라마다스; 로크 엔. 호
Original assignee: 벤투리 와이어리스, 인코포레이티드
Priority date: 2005-05-04
Filing date: 2006-05-04
Publication date: 2008-02-19
Also published as: CA2607740A1; US20120089662A1; WO2006119465A3; US7945692B2; US20100115122A1; US8010693B2; EP1877907A2; AU2006243783A1; US20100185779A1; WO2006119465A2; US9043389B2; JP2008541239A; US20060253546A1; US20120324037A1; US7860997B2; US8108457B2; US8296353B2; US7694008B2; US7860998B2; IL187145A0

Abstract

본 발명은 집합적이며 흐름 제어된 채널(aggregated and flow-controlled channel)을 통해 객체들을 동시에 사전 인출(pre-fetch)함으로써 긴 지연 링크(long-latency link)를 통한 HTTP의 성능을 향상시키는 것에 대한 것이다. 에이전트 및 게이트웨이는 함께, 웹 브라우저가 긴 지연 데이터 링크를 통하여 인터넷 웹 사이트로부터 HTTP 콘텐츠를 좀 더 빠르게 인출하는 것을 돕는다. 게이트웨이 및 에이전트는 상주 브라우저가 객체를 요구하기 전에 객체가 마련되어 호스트 플랫폼에서 이용가능하게 되는 방식으로 선택적인 포함 객체(embedded object)의 인출을 조정한다. 브라우저에게 즉시 객체를 이용할 수 있는 것처럼 보이게 함으로써, 브라우저가 객체의 처리를 완료하여 많이 기다리지 않고 다음 객체를 요구하게 할 수 있다. 이와 같이 포함 객체를 즉시 이용할 수 없으면, 브라우저는 긴 지연 링크를 통해 그 요구 및 대응 응답을 기다린다.

브라우저, 게이트웨이, 웹서버, 전송 매커니즘

Description

긴 지연 링크를 통한 ＨＴＴＰ의 성능을 향상시키는 방법 및 장치{METHOD AND APPARATUS FOR INCREASING PERFORMANCE OF HTTP OVER LONG-LATENCY LINKS}

본 발명은 컴퓨터 네트워크의 성능 향상에 관한 것이다. 보다 구체적으로는, 본 발명은 집합적이며 흐름 제어된 채널(aggregated and flow-controlled channel)을 통해 객체들을 동시에 사전 인출(pre-fetch)함으로써 긴 지연 링크(long-latency link)를 통한 HTTP의 성능을 향상시키는 것에 대한 것이다.

인터넷 웹 페이지는 많은 유형의 URL 및 객체를 포함하고 있다. 인터넷 웹 페이지를 디스플레이하는 표준 브라우저들은 그들의 웹 서버 저장소로부터 이들 객체 중 일부를 동시에(in parallel) 인출할 수 있다. 객체들을 동시에 인출하는 브라우저의 능력을 사용하는 방안은 브라우저가 포함된 객체를 많이 갖는 페이지를 디스플레이하는데 걸리는 시간을 감소시킨다. 그러나, 병렬 처리(parallelism)의 정도는 자바스크립트(JavaScript) 및 스타일시트(StyleSheet)와 같은 어떠한 유형의 객체를 다운로딩할 때 기존 시스템과의 호환성(backward compatibility), TCP 흐름 제어(flow control)의 유효성 및 브라우저 구현의 단순화로 인해 제한된다. 현재 잘 알려져 있는 웹 브라우저는 언제나 순차적으로 자바스크립트를 다운로드하고, 별개의 단계에서 스타일시트를 다운로드한다.

객체를 순차적으로 인출하면 무선 액세스 네트워크와 같은 고 지연의 저 대역폭 네트워크 내의 그러한 URL에 대한 엔드 유저의 경험을 저하시킨다. 즉, 서버는 새로운 요구가 도착하기를 기다리고 있지만, 클라이언트는 이전의 해당 응답이 수신될 때까지 이들을 송신하지 않는다. 이 때문에 링크는 사용 중에 있게 된다.

브라우저 상의 범용 캐시는 동일한 웹 페이지를 재방문하는데 걸리는 시간을 단축하기 위해 사용된다. 그러나, 범용 캐시는 무선 링크를 통해 웹페이지에 처음 방문하는 것을 도와주지는 않는다. 또한, 브라우저가 다른 웹사이트로부터의 후속 인출로부터 객체를 보관하기 위해 그 캐시의 부분을 제거한 경우에는, 다음의 재방문에 도움이 되지 않는다. 따라서, 범용 캐시를 사용하는 것이 성능 면에 있어서 일관적이며 예측 가능한 향상을 제공하지는 않는다.

HTTP 1.1 요구 파이프라이닝 표준(HTTP 1.1 Request Pipelining standard)(RFC 2616)은 양측이 이것을 지원하는 경우에 적절히 실시된다면 병렬 처리의 정도가 증가할 수 있게 한다. 그러나, 현대의 브라우저는 기존 시스템과의 호환성, 구현의 단순화, 흐름 제어의 유효성과 같은 많은 이유로 최적의 방법으로 이것을 사용하지 않는다. 따라서, 이 표준은 브라우저 동작을 변경하지 않고, 따라서 항상 링크 사용을 최적화하는데 실패한다.

브라우저 동작을 변경하지 않는 저 대역폭 및 고 지연 네트워크에서 순차적 액세스의 부정적인 효과를 경감시키는 방법 및 장치를 제공하는 것이 바람직하다.

본 발명은 브라우저 동작을 변경시키지 않고 저 대역폭 및 고 지연 네트워크에서 순차적 액세스의 부정적인 영향을 경감시킨다. 이것은 다른 다운로딩 전략에 의해, 즉 에이전트로부터 게이트웨이 서버로 사전 인출하는 것에 의해 긴 지연 링크를 통한 병렬 처리의 정도를 증가시킴으로써 달성된다. 낮은 정도의 병렬 처리 문제는 HTTP 트랜잭션에 대한 지연 및 대역폭 제한이 사실상 없는 에이전트와 브라우저 사이로 제한된다. 따라서, 이 문제점이 경감된다.

일실시예에서, 본 발명은 필요한 객체를 브라우저를 호스팅하는 플랫폼에서 이용가능하게 준비시키는 해당 서버 소프트웨어와 통신하는 소프트웨어(클라이언트)를 포함한다. 브라우저가 순서대로 또는 최적보다 덜한(less-than-optimal)동시성의 정도로 소스 웹 서버로부터 객체를 다운로드하려고 할 때 긴 지연 링크에 대한 활용이 낮아진다. 이것은 엔드 유저가 경험하는 주 지연의 원인이 된다. 이 지연은 본 발명의 사전 인출 메커니즘을 이용함으로써 크게 감소될 수 있다. 따라서, 본 발명은 집합적이며 흐름 제어된 채널을 통해 동시에 객체들을 사전 인출함으로써 긴 지연 링크를 통한 HTTP의 성능을 증가시킨다. 에이전트 및 게이트웨이는 함께, 웹 브라우저가 긴 지연 데이터 링크를 통하여 인터넷 웹 사이트로부터 HTTP 콘텐츠를 좀 더 빠르게 인출하는 것을 돕는다. 게이트웨이 및 에이전트는 상주 브라우저가 객체를 요구하기 전에 객체가 마련되어 호스트 플랫폼에서 이용가능하게 되는 방식으로 선택적인 포함 객체(embedded object)의 인출을 조정한다. 브라우저에게 즉시 객체를 이용할 수 있는 것처럼 보이게 함으로써, 브라우저가 객체의 처리를 완료하여 많이 기다리지 않고 다음 객체를 요구하게 할 수 있다. 이와 같이 포함 객체를 즉시 이용할 수 없으면, 브라우저는 긴 지연 링크를 통해 그 요구 및 대응 응답을 기다린다. 본 발명은 브라우저에 히스토리를 캐시하는 것에 한정되지 않는다. 본 발명은 브라우저가 특정 객체를 요구하기 전에, 고도의 동시 방식으로 게이트웨이 서버로부터 선택적인 인출을 활발히 수행한다. 본 발명은 웹 브라우저 및 엔드 소스 서버로부터 어떠한 지원도 요구하지 않는다. 또한 고도의 병렬 처리 하에서 어떠한 흐름 제어 문제도 일으키지 않는다. 따라서, 본 발명은 특히 많은 자바스크립트 및 스타일 시트를 사용하는 웹 사이트에서 클라이언트-서버 실시예의 HTTP 성능을 향상시킨다.

도 1은 본 발명에 따른 긴 지연 링크를 통한 HTTP의 성능을 향상시키기 위한 방법 및 장치를 구현하는 시스템 아키텍처의 개략적인 블록도.

도 2는 본 발명에 따른 모듈 상호작용의 개요를 도시한 개략적인 블록도.

도 3은 본 발명에 따른 로컬 캐시를 통한 연결 흐름을 도시한 흐름도.

도 4는 본 발명에 따른 로컬 캐시로부터의 연결 흐름을 도시한 흐름도.

도 5는 본 발명에 따른 HTML 처리 연결 후의 사전 인출 관계를 도시한 개략적인 블록도.

정의(Definitions)

HTTP: 하이퍼 텍스트 전송 프로토콜(Hyper Text Transfer Protocol) - 웹 페이지, 문서 등을 인터넷을 통해 전송하기 위한 TCP/IP 기반의 프로토콜

HTML: 하이퍼 텍스트 마크업 랭귀지(Hyper Text Markup Language).

API: 애플리케이션 프로그래밍 인터페이스(Application Programming Interface).

VTP: 전송 프로토콜(A Transport Protocol).

XML: 확장 하이퍼 텍스트 마크업 랭귀지(Extension Hyper Text Markup Language).

오늘날, 공개적으로 이용가능한 HTTP 브라우저는, TCP 접속 수가 증가함에 따라 흐름 제어 효과가 감소함으로 인해, 웹 서버에 대해 제한된 수의 동시 TCP 접속을 오픈한다. 이것은 페이지 객체의 다운로딩에 대한 동시성의 정도를 제한한다. 상기 HTTP1.1 파이프라이닝 표준은, 요구에 대한 응답이 수신되기 전에 동일 TCP 접속을 통해 복수의 요구를 전송할 수 있게 함으로써 이 문제를 해결하고자 한다. 그러나, 기존 시스템과의 호환성 문제 및 브라우저와 서버의 한계로 인해, 흔히 동시성의 정도는 낮다.

또한, 자바스크립트 및 캐스캐이딩 스타일 시트(Cascading Style Sheets)와 같은 여러 유형의 객체는 흔히 구현의 단순화로 인해 브라우저에 의해 순차적으로 다운로딩된다. 이것은 응답을 기다리는데 소비된 시간으로 인해 동시성의 정도를 더욱 감소시켜, 긴 지연 링크의 사용을 감소시킨다.

본 발명의 바람직한 실시예는, 독립적인 흐름 제어 메커니즘(VTP)을 사용함으로써 브라우저 호스트 플랫폼과 소스 웹(또는 프록시) 서버 사이에서 가상적으로 오픈되는 TCP 접속 수에 관계없고, 따라서 객체를 동시에 다운로딩하는데 유용한, 에이전트 및 게이트웨이 시스템을 포함한다. 클라이언트측에서 캐시를 사용함으로써, 엔드 브라우저 및 소스 웹 서버의 구현(implementation)에 관계없이 에이전트가 웹 객체를 인식하는 순간에 웹 객체들이 동시에 다운로딩될 수 있다.

도 1은 본 발명에 따른 긴 지연 링크를 통한 HTTP의 성능을 향상시키는 방법 및 장치를 구현하는 시스템 아키텍처의 개략적인 블록도이다. 바람직한 시스템에서 다음과 같은 네 개의 주요한 구성요소가 있다. 즉, 통상 호스트 플랫폼(10) 내에 있는 브라우저(11), 사전 인출 기능부를 구비한 에이전트(17) 및 웹 객체 캐시(13)를 포함하는 클라이언트(12), 흐름 제어 채널을 구비한 긴 지연 링크(19)를 통해 상기 클라이언트와 통신하는 서버(14) 및 상기 서버(14)와 통신하는 오리지널 웹 서버(16)가 있다. 종래 기술에서, 브라우저 요구는 신호 메시지 및 전송 프로토콜(VTP) 하에서의 흐름 제어로 변환되어 서버로 라우팅된다. 서버는 요구를 원래의 정규 HTTP 요구로 변환하여 오리지널 웹 서버로 전송하고, 응답이 다시 서버로 전송된다. 그 다음에, 이것은 처리되고, 공지되어 있는 손실 또는 무손실 기법을 이용하여 압축되며, VTP를 통해 다시 클라이언트로 전송된다. 클라이언트는 압축된 메시지를 다시 브라우저에게 제공한다. 바람직한 실시예는 전술한 UDP 기반의 VTP 흐름 제어 및 전송 프로토콜을 사용한다(USPN 6,529,516 및 USPN 6,115,384 를 참고하라. 이들은 본 명세서에 참고로서 완전히 포함된다).

병렬 처리의 정도가 낮고 요구의 수가 적은 경우, 본 발명은 많은 브라우저가 병렬 방식보다는 순차 방식으로 자바스크립트 및 스타일 시트를 브랜치한다는 것을 인식한다. 따라서, 본 발명은 명시적으로 이 유형의 객체를 사전 인출함으로써 전체적인 성능을 크게 향상시킨다.

예를 들면, 웹 페이지는 여러 개의 자바스크립트 및 스타일 시트와 많은 GIF를 가질 수 있다. 이들은 웹 페이지의 구성요소의 일부이며, 이들은 웹 페이지를 렌더링하는데 사용된다. 웹 페이지는 또한 부가적인 HTML, JPEG 및 FLASH 등을 포함할 수 있다.

본 발명자는 시스템을 느리게 하는 주요한 요소로서 두 개의 객체, 즉 자바스크립트 및 스타일 시트를 인식하였지만, 본 발명은 단지 이들 객체의 사전 인출에 한정되지는 않는다. 브라우저가 이미 일부 병렬 인출을 실행할 수도 있지만, 자바스크립트 및 스타일 시트는 통상 인출되지도 않고, 인출되고 있는 객체의 유형을 식별하기 위한 어떠한 노력도 행해지지 않는다. 이들 유형의 객체와 같은 어떠한 객체를 선택적으로 사전 인출함으로써, 시스템의 성능이 크게 향상된다. 따라서, 바람직한 실시예는, 자바스크립트 및 스타일 시트 사전 인출(현재의 바람직한 실시예의 경우)을 포함하는 클라이언트측의 선택적 사전 인출을 실행한다.

본 발명은 바람직하게는 프리페처(17) 및 캐시(18) 콤포넌트를 포함하는데, 후자는 시스템의 클라이언트 부에 제공된다. 사전 인출을 위해, 시스템은 또한 파서(parser), 사전 인출 핸들러, 및 사전 인출된 객체를 유지하기 위한 저장 시스템 을 포함한다(이하에 보다 상세히 논의함).

동작 시에, 브라우저는 객체를 요구한다. 객체는 서버를 통해 클라이언트로 전송된다. 만약 객체가, 예를 들어 HTML과 같은 웹페이지의 기술(description)이면, 클라이언트는 에이전트를 위해 그것을 분석하고, 웹 페이지가 그 안에 소정의 콤포넌트를 갖고 있는 지 판정한다. 바람직한 실시예에서는, 파서가 예를 들어 웹 페이지에 자바스크립트 또는 스타일 시트가 있는지 판정한다. 만약 이들이 있다면, 사용자의 브라우저에 의해 이들 객체가 요구되기를 기다리지 않고, 이들 객체가 에이전트에 의해 웹 서버로부터 획득된다. 따라서, 웹 페이지가 사용자에게 돌아올 때, 웹 페이지가 브라우저로 돌아가며, 동시에 자바스크립트가 인출되는 동안 그 페이지가 멈추지 않는다.

웹 페이지는 기술 객체(description object)이다. 이것은 콤포넌트 객체들을 기술한다. 메인 페이지는 일반적으로 나타나는 첫 번째 객체이고, 페이지를 렌더링하는데 필요한 것을 나타낸다. 종종, 브라우저는 한번에 자바스크립트 및 스타일 시트 객체를 인출한다. 그러한 객체가 인출될 때마다, 사용자는 지연 시간 동안 기다려야 한다. 본 발명자는 브라우저가 GIF, JPEG, 또는 FLASH와 같은 다른 유형의 객체에 대해서는 그렇지 않다는 것을 관측하였다. 통상의 브라우저는 다른 유형의 객체를 적어도 어느 정도까지는 동시에 인출하고, 어떤 유형의 객체는 한번에 하나씩만 인출한다.

브라우저는 페이지 기술을 분석하고, 페이지 기술이 브라우저에 의해 분석되는 동안, 파싱 요소가 또한 페이지 기술을 분석하여 자바스크립트 및 스타일 시트 를 식별한다. 이들 특정 객체는 일반적으로 순차적으로 인출되는 유형이다. 사전 인출 메커니즘을 사용하여, 브라우저가 페이지를 로딩하고 있는 동안, 동시에 브라우저는 오리지널 웹 서버로 가서 이들 객체를 인출한다. 시스템은 이들 객체를 인출하여 이들을 캐시에 넘겨주며, 따라서 이들 객체는 이제 캐시에 존재한다. 그 결과, 웹 페이지의 구축을 완료하기 위해 이들 객체를 순차적으로 획득하기 위해, 그에 따르는 지연을 가지고 시스템을 횡단해 나가기보다는, 웹 페이지 로딩을 완료하기 위해 클라이언트에만 액세스하면 된다. 이것은 시스템의 속도를 상당히 증가시킨다. 따라서, 본 발명은 병렬 처리 및 선택적인 사전 인출을 이용하여 왕복시간(round trip)이 단축된 느낌을 준다.

기능적 사양(Functional Specification)

문제점 정의(Problem Definitio)

현재의 클라이언트 아키텍처에서는, 브라우저에 의해 요구될 때 HTML 페이지가 인출된다. 어떤 경우에는, 브라우저가 자바스크립트와 같은 페이지를 순차적으로 요구한다. 순차적인 요구는, 병렬 처리가 없기 때문에, VTP를 최대화하지 않는다. VTP를 최대화하기 위해, 클라이언트에 대해 사전 인출이 요구된다.

가정(Assumptions)

본 발명의 실시예는 브라우저가 자바스크립트와 같은 어떠한 파일에 대한 HTML 요구를 순차적으로 수행한다고 가정한다.

요건(Requirements)

본 발명은 다음 요건을 갖는 클라이언트 사전 인출 특징을 충족시킨다.

· XML을 통해 구성 가능한 속성

· 브라우저 요구를 기초로 한 HTML 페이지 우선순위

· 상이한 실행기간 동안의 비지속성(Non-persistence over different running session)

· HTML 파일 사전 인출 수행

기능(Functionality)

포스트 HTML 처리(post HTML processing), 클라이언트측 사전 인출 제어(client side pre-fetch control) 및 파일 캐시(file cache) 기능이 요구된다.

포스트 HTML 처리 모듈은 HTML 페이지를 분석하여 파일 확장자에 관계없이 사전 인출할 URL의 리스트를 검색하기 위한 것이다. 이 URL의 리스트는 클라이언트 사전 인출 제어 모듈에 제공된다.

클라이언트 측 사전 인출 제어 모듈은 식별된 객체에 대한 HTTP 요구를 수행한다.

파일 캐시는 영구 저장장치에 사전 인출 파일을 국부적으로 캐싱하는 것을 처리한다.

용도(Usability)

본 발명은 바람직하게는 엔드 유저가 파일 인출을 가능하게 하거나 또는 불가능하게 한다. 이 특징을 위해, GUI는 이 특징을 허용 또는 불허하는 옵션을 제공한다. 불허하는 경우, 로컬 캐시된 파일 및 내부 사전 인출 기록이 소거된다.

디자인 사양(Design Specification)

이 논의는 포스트 HTML 처리, 클라이언트 사전 인출 제어 및 파일 캐시 모듈을 위한 디자인의 상세를 제공한다.

개요(Overview)

도 2는 모듈 상호작용의 개요를 도시한 개략적인 블록도이다. 도 2에서, 브라우저(11)는 OS 소켓층(20)을 통해 프로토콜부(25)와 상호작용한다. OS 소켓층은 압축기 층(23) 및 전송 메커니즘(22)과 상호작용하는 애플리케이션층(21)과 상호작용한다. HTTP 처리 모듈(24)은 본 발명의 동작에 대해 핵심으로, 애플리케이션 층 및 압축기 층 외에 포스트 HTML 처리 모듈(27) 및 클라이언트 사전 인출 제어 모듈(26)과 상호작용하며, 클라이언트 사전 인출 제어 모듈(26)은 파일 캐시 제어부(18)와 상호작용한다.

모듈 디자인(Module Design)

다음의 논의는 각각의 서브시스템, 즉 포스트 HTML 처리, 클라이언트 사전 인출 제어 및 파일 캐시를 위한 모듈 디자인을 설명한다. 이하에서 논의되는 도 3 내지 5 각각에서 동작 흐름은 예를 들어 "1*"와 같은 숫자와 별표에 의해 표시된다.

도 3은 로컬 캐시를 통한 연결 관계를 도시한 흐름도이다. 사용자가 웹 페이지를 보기 위해 브라우저에 액세스할 때(1*), OS 소켓 층/VLSP는 애플리케이션 층과와 통신한다(2*). 포스트 HTML 처리 모듈이 액세스되고(3*), 애플리케이션 층에 출력을 리턴한다(4*). 그 다음에 애플리케이션은 전송 모듈에 액세스하여 웹 페이지를 인출하고(5*), 파일 캐시 모듈에 액세스하며(6*), 파일 캐시 모듈이 OS 소켓 층/VLSP에 웹 페이지를 리턴한다(7*).

도 4는 로컬 캐시로부터의 연결 관계를 도시한 흐름도이다. 프로토콜 모듈이 활성화되면, OS 소켓 층/VLSP에 액세스하고(1*), 그 다음에 애플리케이션 층에 액세스한다(2*). 애플리케이션 층은 포스트 HTML 처리 모듈과 상호작용하고(3*, 4*), 그 다음에 애플리케이션 층은 전송 모듈을 사용하며(5*), 그 후 캐시 콘텐츠를 OS 소켓 층/VLSP에 제공한다(6*).

도 5는 사전 인출 포스트 HTML 처리 관계를 도시한 개략적인 블록도이다. 여기서, 서버는 OS 소켓 층에 액세스한다(1*). VLSP는 애플리케이션층과 통신하고(2*), 그 다음에 HTTP 처리 모듈과 통신한다(3*). 이 흐름은 포스트 HTML 처리 모듈로 진행하고(4*), 이 포스트 HTML 처리 모듈은 클라이언트 사전 인출 제어 모듈과 상호작용한다(5*). 클라이언트 사전 인출 제어 모듈은 전송 모듈과 상호작용하고(6*), 전송 모듈은 프로토콜 모듈과 통신한다(7*). 프로토콜 모듈은 요구된 결과를 OS 소켓 층/VLSP로 리턴한다(8*).

포스트 HTML 처리 모듈 설계(Post HTML Processing Module Design)

포스트 HTML 처리 모듈은 사전 인출할 URL의 리스트를 생성한다. 각각의 URL은 클라이언트 사전 인출 제어 모듈로 공급된다.

클라이언트 사전 인출 제어 모듈 설계(Client Prefetch Control Module Design)

클라이언트 사전 인출 제어 모듈은 페이지를 인출할 지의 여부 및 그 때를 결정하는 판정 로직을 포함한다. 사전 인출 URL은 색인 링크 리스트 구조(a index linked list structure)에 저장된다. URL이 사전 인출되어야 한다고 결정되면, 로컬 캐시 모듈로의 우회 접속이 이루어진다. 캐시 어드레스 및 포트 번호는 로컬 캐시 모듈에 질의함으로써 결정된다. 접속이 이루어지고 로컬 캐시로부터 데이터가 수신되면, 접속은 즉시 종료된다. 따라서, 로컬 캐시는 접속이 종료될 때에도 다운로드를 계속하도록 구성되어야 한다.

VTP(UDP) 전송 디자인(VTP(UDP) Transport Design)

동작의 개요

이하의 논의는 본 발명의 바람직한 실시예의 실시와 관련하여 사용될 수 있는 유형의 UDP 기반의 VTP 프로토콜의 디자인에 대한 것이다.

이 프로토콜은 TCP와 같이 순차적이며, 신뢰할 수 있는 데이터 전송을 제공한다. 그러나, 이 프로토콜은 고 대역폭 변화 및 패킷 손실율을 갖는 환경에 보다 적합한 다른 레이트 제어 메커니즘을 이용한다. 또한, 이 프로토콜은 두 호스트 사이의 단일 흐름 제어 채널을 통한 몇몇 전송 흐름을 멀티플렉싱하는 것을 지원한다. 이 프로토콜의 주 목적 중 하나는, 고 대역폭, 고 지연 및/또는 고 패킷 드롭과 같이 TCP를 적용하기 힘든 분야에 적용하기 위한 것이다. 무선 상에서의 TCP의 일부 단점으로는, 작은 최초 전송 윈도우(small initial send window), 큰 최대 전송 윈도우 사이즈(large maximum send window size), 매우 공격적인 혼잡 제어 메커니즘(very aggressive congestion control mechanisms)이 있다.

이 프로토콜은 TCP에 의해 제공된 신뢰할 수 있는 데이터의 전송을 제공한다. 그러나, 이 프로토콜은 고 대역폭 변화 및 패킷 손실율을 갖는 환경에 보다 적합한 다른 레이트 제어 메커니즘을 이용한다. 또한, 이 프로토콜은 두 호스트 사이의 단일 채널을 통한 복수의 애플리케이션 데이터 흐름을 멀티플렉싱하는 것을 지원한다. 이것은 두 호스트 사이에 TCP 접속 수가 많을 때 경험할 수 있는 흐름 제어 효과가 감소한다는 부작용 없이, 이들 두 호스트 사이에서 애플리케이션 대화의 수를 크게 증가시킨다.

접속 설정(Connection Establishment)

UDP는 무접속 데이터그램 지향 프로토콜이다. VTP에서, 논리 접속은 다음과 같은 이유로 클라이언트와 서버 사이에 설정되어야 한다.

· 순차 전송을 보장하는 일련번호의 교환

· 서버측에서 접속하는 클라이언트의 인증

· 각 단으로부터의 파라미터 획득 및 개시

두 호스트 간의 VTP 접속은 임의의 애플리케이션 레벨 흐름이 설정되기 전에 설정된다. VTP 접속이 설정되면, 두 VTP 접속 호스트 간의 개별 애플리케이션 대화는 3선 핸드셰이킹(three-way hand-shaking)을 요구하지 않는다. VTP 엔드 포인트 전환 메커니즘(end-point redirecting mechanism)은 TCP 흐름이 긴 설정 지연을 체감하지 않고 이 VTP 터널로 전환되게 한다.

VTP 접속 설정은 개별 애플리케이션 흐름(TCP 흐름)으로부터 제어 패킷 및 데이터 패킷의 전송을 보장하기 위한 인증 및 일련번호 교환을 포함한다.

서버와의 사전 접속이 없었다면, 새로운 접속이 오픈된다. 접속 오픈 요구는 REQ_CONN(request connection) 패킷을 서버에게 송신함으로써 클라이언트로부터 개시된다. REQ_CONN 및 REQ_ACK 패킷과 일치하는 모든 REQ_CONN 패킷에 접속 요구 식별자가 보내진다. 클라이언트는 이 패킷을 송신한 후에 타이머 작동을 개시해야 한다. 만약 REQ_CONN 타이머가 고장나면, 상이한 접속 요구 식별자를 갖는 다른 REQ_CONN 패킷을 송신한다. 몇몇 n(구성가능한 파라미터) 개의 REQ_CONN 패킷을 송신한 후에 다른 측으로부터 응답이 없으면, 클라이언트는 포기하고 "접속을 설정할 수 없음"을 방문객(caller)에게 보고한다. 클라이언트는 REQ_CONN 패킷을 송신한 후에, 종료된 (VTP_CLOSED)로부터 "접속 진행 중(connection in progress)"(VTP_REQ_CONN) 상태로 그 접속 상태를 변경한다.

서버는 소켓을 오픈하고 클라이언트 접속 요구를 감시하는 일부 공지되어 있는 포트에 결합한다. 서버는 REQ_CONN 패킷을 획득할 때마다, REQ_CONN+ACK 패킷을 송신함으로써 REQ_CONN 패킷에 응답하여 새로운 실제 접속 노드를 할당해야 한다. 이 때, 서버는 그 접속을 "접속 설정"(VTP_EST) 상태로 변경한다. 클라이언트가 REQ_CONN+ACK 패킷을 획득하면, 실제 접속 노드를 "접속 설정" 상태로 변경할 수 있다.

클라이언트는 서버의 ACK 패킷을 갖는 REQ_CONN+ACK 패킷을 확인한다. 클라이언트는 REQ_CONN 및 REQ_CONN+ACK 패킷으로부터 서버로 왕복 시간을 추론할 수 있으며, 서버는 클라이언트로부터의 REQ_CONN+ACK 및 REQ_CONN 패킷으로부터 자신과 이 클라이언트 사이의 왕복 시간을 추론할 수 있다. 각 단은 네트워크를 식별하기 위해 가능한 자주 RTT 평가치를 획득해야 한다.

만약 실제 접속이 성공적으로 오픈되면, 데이터는 ta_send()를 호출함으로써 가상 접속을 보낼 수 있다.

데이터 흐름 및 명시적인 레이트 흐름 제어(Data Flow and Explicit Rate Flow Control)

임의의 전송층의 목적 중 하나는 효율적으로 데이터를 송신하고 네트워크로부터 가능한 최대의 처리량(throughput)을 얻는 것이다. 접속이 설정되면, 송신기와 수신기 사이의 임의의 중간 라우터가 다운되거나 또는 그 경로 내의 하나 이상의 링크를 사용하는 좀 더 새로운 몇몇 접속이 설정될 수 있다. 송신기는 네트워 크에서 혼잡을 일으키는 어떠한 데이터도 송신해서는 안 된다. 송신기가 수신기로부터 어떠한 피드백도 획득하지 않고 보낼 수 있는 데이터량을 "송신 윈도우(send window)"라고 하며, 이것은 다음과 같이 구해진다.

Send_Window = (const1 * 대역폭(bandwidth) * 지연(delay)) + (const2 * N)

여기서, 대역폭은 병목 링크 대역폭(아래에 설명함)이고, 지연은 송신기와 수신기 사이의 왕복 시간이며, const1은 대역폭과 지연 추정치를 정정하기 위한 정수 상수이고, const2는 드롭된 ACK 패킷을 나타내는 정수 상수이며, N은 ACK를 송신하기 전에 수신된 최대 바이트이다.

접속 처리량은 네트워크가 전달할 수 있는 데이터량 및 수신기가 이 데이터를 애플리케이션 층에 전달하기 전에 이 데이터를 저장하는 버퍼 공간의 양에 의해 제한된다. 본 발명에서, 수신기 버퍼는 제약(constraint)으로서 간주되지 않는다. 네트워크가 이제 병목이기 때문에, 중간 라우터 및 송신 호스트에서의 버퍼를 고려하면 송신기는 네트워크가 허용할 수 있는 것보다 더 많은 데이터를 보낼 수 없다. 예를 들어, 1 Mbps 링크를 갖는 송신기 및 수신기가 128 kbps 링크에 의해 상호접속된다. 처리량은 이제 128 kbps(16KBytes/s) 링크로 제한된다. 만약 송신기가 송신할 데이터가 예를 들어 2 MB이면, 이들은 중간 라우터에서 드롭될 수 있기 때문에 이들 데이터 전부를 신속하게 쏟아낼 수 없다. 정확하게 말하면, 송신기는 1초에 16 KB를 넘어 송신해서는 안 된다. 따라서, 송신기가 자신으로부터 수신기로의 경로에서 병목 링크의 대역폭을 알고 있다면, 도중에 어떠한 패킷도 드롭되지 않도록 송신율을 조절할 수 있다.

위 문단의 예에서, 송신 윈도우가 30 KB라고 하자. 여기에 있는 모든 데이터가 송신되기 때문에, 완전한 송신 윈도우 분량의 바이트가 한번에 송신될 수 있다. 이것은 다음 라우터에서 패킷의 버스트를 생성하고, 만약 이들 패킷을 홀딩할 버퍼 공간이 없으면, 이들은 바로 드롭되어 버린다. 이것을 회피하기 위해, 송신기가 대역폭을 알고 있으므로, 송신기는 제어된 방식으로 이들 바이트를 송신한다. 이것이 전송의 흐름 제어 특징이다. 이 접속에 이용가능한 대역폭이 동일하게 유지되는 한, 패킷을 드롭할 가능성은 적다. 송신 윈도우는 네트워크 혼잡을 회피할 필요가 있고 흐름 제어는 버스트를 회피할 필요가 있다.

송신기가 윈도우 분량의 바이트를 송신하면, 자신의 윈도우를 닫고 수신기로부터의 피드백을 기다린다. 이상적으로는, 만약 송신기가 송신할 데이터를 가지면, 모든 데이터가 다른 단에 도달할 때까지, 송신기는 데이터를 송신하는 것을 중단하지 않는다. 즉 송신기는 자신의 송신 윈도우를 닫지 않는다. 송신기는 수신기로부터 송신기가 보낸 데이터의 일부 또는 전부를 획득했다는 피드백을 받을 때까지 송신 윈도우를 다시 오픈한다. 송신기는 수신기에 의해 긍정적인 확인 응답을 받을 때까지 송신 윈도우 내의 데이터를 송신해서는 안 된다. 송신 윈도우를 항상 오픈하고 보다 많은 데이터를 위한 공간을 갖기 위해, 수신기는 가능한 자주 피드백을 송신해야 한다.

대역폭 및 전송에 대한 트립 타임(trip time)에 대한 정보가 효율적으로 작용하는 것은 분명하다. 다음 섹션은 VTP가 병목 대역폭 및 왕복 시간을 획득하는 방법을 설명한다.

왕복 시간(Round Trip Time)

왕복 시간(RTT)은 패킷이 다른 단(end)에 도착하였다가 돌아오는데 걸리는 시간이다. 이 시간은 송신기에서의 큐잉 및 전송 지연, 중간 라우터에서의 큐잉 및 처리 지연, 최종 호스트에서의 처리 지연을 포함한다. 트립 타임(TT)은 송신기로부터 수신기로 패킷이 전송되는데 걸리는 시간이다. VTP는 아래 수식을 이용하여 RTT를 추정한다.

RTT = (송신된 마지막 패킷으로부터 수신된 ACK까지의 시간) - (수신기에서의 지연) - ((pkt)의 사이즈/대역폭)

RTT는 송신기가 SACK에 응답하여 하나 이상의 패킷을 릴리스할 때에만, 즉 긍정적으로 확인된 경우에만 측정된다. 수식의 두 번째 항이 데이터 패킷을 필요로 하기 때문에, SACK가 수신기가 아무 것도 수신하지 않았다고 응답하면 RTT는 측정되지 않는다.

다음 예는 RTT 계산을 보여준다.

수신기 송신기

12 송신 <----시간 t1

34 송신 <----시간 t2

56 송신 <----시간 t3

t4---->1

t5---->3

t6---->6

t7---->SACK가 수신기가 1, 3, 6을 획득했다고 응답

SACK 도착 <----시간 t8

RTT@sender = (t8 - 13) - (t7 - 16) - ((pkt 6)의 사이즈/대역폭).

RTT는 송신 윈도우를 계산하는데 사용되고 재전송 타임아웃(후술함)을 추산하는데에도 사용된다. (실제) 접속을 개시한 클라이언트 트랜스포트는 REQ_CONN 및 REQ_CONN+ACK 패킷으로 접속 설정에서 RTT를 획득할 수 있다. 서버는 클라이언트의 ACK 패킷을 획득하면 클라이언트에 대한 RTT를 추론할 수 있다. 만약 클라이언트의 ACK 패킷이 드롭되면, 서버는 수신기로부터의 제 1 SACK로부터 위 수식을 사용하여 RTT를 유도해야 한다. 이것은 송신기가 각 패킷에 타임 스탬프를 송신할 것을 요구한다. SACK 패킷은 마지막 데이터 패킷으로부터 이 SACK로의 시간 차를 전달해야 한다.

WTO 송신(Send Window Close Timeout (WTO))

전술한 바와 같이, 송신기는 애플리케이션 층으로부터 획득한 마지막 데이터 패킷을 송신한 후에 또는 완전한 윈도우 분량의 바이트를 송신한 후에 중지해야 한다. 애플리케이션에 의해 송신된 각각의 모든 바이트가 순차적으로 에러 없이 수신기로 전달되는 것을 보장하는 것은 송신기에 달려 있다. 수신기는 수신한 패킷 및 수신하지 않은 패킷에 대한 피드백을 송신한다. 만약 수신한 패킷에 대한 피드백이 드롭되면, 송신기는 수신기에서 수신된 패킷에 대해 알 방법을 갖고 있어야 한다. 수신기가 송신되고 있는 패킷을 획득하고 있다는 것을 보장하기 위해, 송신기는 마지막 패킷 송신 후에 언젠가 만료될 타이머를 개시해야 한다. 이 타임아웃은 LTO(last packet ACK timeout)라고도 한다. 만약 송신기가 LTO 시간 내에 어떠한 피드백도 획득하지 못하면, "sack 요구(requesting sack)" 패킷을 송신하여 수신기가 피드백을 송신하게 한다(피드백 송신은 SACK에서 설명된다). LTO 타이머는 너무 이르게 또는 너무 늦게 만료되지 않도록 설정되어야 한다. 다음 두가지 이유에서 너무 이르게 만료되어서는 안 된다. 즉, 피드백이 이미 송신기로 가고 있거나 또는 너무 이른 타임아웃이 너무 많은 제약을 만들 수 있다. 파이프가 이 접속으로부터 더 이상 어떠한 패킷도 운반하고 있지 않은 이유로 타이머가 너무 늦게 만료되어서도 안 된다. LTO 수식은 아래와 같이 주어진다.

LTO = K5 * (RTT + bytes_sent/대역폭)

여기서, K5는 지연을 조정하기 위한 정수 상수이고, RTT는 송신기의 RTT이며, bytes_sent는 송신된 바이트의 총 수이고, 대역폭은 송신 레이트이다.

송신기가 완전한 송신 윈도우 분량의 바이트를 전송한 경우, 임의의 새로운 패킷의 송신을 중단해야 한다. 전송 층은 가상 접속 큐 내에서 송신할 보다 많은 데이터를 가질 때 이것이 발생하지 않도록 해야 한다. 송신 윈도우가 종료되고 송신기가 어떠한 패킷도 송신하고 있지 않다는 사실은 송신기가 파이프라인을 최대한 사용하고 있지 않다는 것을 의미한다. 수신된 패킷을 확인하는 SACK는 송신기가 송신 윈도우로부터 확인된 바이트를 릴리스할 수 있게 하며, 따라서 새로운 바이트가 송신될 여지를 제공한다.

송신기는 완전한 송신 윈도우를 송신한 후에 중단해야할 때마다 "WTO(send window close timer)"를 개시한다. WTO(send window close timer)는 다음과 같이 주어진다.

WTO = 2^M * Const * RTT

여기서, M은 최대 재시도 횟수이고, Const는 정수 상수이며, RTT는 클라이언트에 대한 송신기 RTT이다.

WTO가 만료되면, 송신기는 수신기에게 SACK를 송신하라고 요구하는 SEND_SACK이라고 하는 새로운 패킷을 송신해야 한다. 송신기는 정해진 횟수(M)까지 이들 SEND_SACK 패킷의 송신을 시도한다. 송신기는 최종 SEND_SACK 패킷 후에 어떠한 피드백도 획득하지 못하면, 실제 접속에서 모든 가상 접속을 닫아야 하고, 실제 접속에서 큐에 구속되지 않은 어떠한 패킷도 폐기해야 하며, 실제 접속을 릴리스해야 한다.

만약 네트워크가 어떠한 패킷도 드롭하지 않으면, WTO 타이머 상에 타임아웃은 없을 수도 있다.

대역폭(Bandwidth)

경로의 대역폭은 송신기로부터 수신기로 소정 갯수의 바이트를 전송하는데 걸리는 시간이다. 이 시간은 디바이스의 전송 시간과 링크 사이의 전파 시간의 합 을 포함한다. 링크는 두 호스트 사이의 매체, 유선 또는 무선이다. VTP는 송신기에서의 시간 차 없이 두 개의 패킷을 차례로 송신함으로써 경로의 대역폭을 측정한다. 패킷이 통과하는 링크의 대역폭에 따라서, 이들 두 패킷은 모두 수신기에서 약간의 시간차를 가지고 도착한다. 도착 시간은 recvfrom() 시스템 콜을 통해 UDP 소켓 버퍼로부터 패킷을 획득하는 시간이다. 예를 들어 4Mbps의 고속 링크에서는, 둘 이상의 패킷이 시간차 없이 도착할 수 있다. 다음은 4KB/s 링크 상에서 사이즈 1 KB의 두 개의 패킷을 송신함으로써 대역폭을 획득할 수 있는 방법을 보여준다.

c11 은 접속 1로부터의 패킷 1이고, c12는 접속 1로부터의 패킷 2이며, c21은 접속 2로부터의 패킷이다.

대역폭 = (c12 도착 시간(arrival time) - c11 도착 시간) / c12 패킷 사이즈

전송 지연을 무시하면, 1KB 패킷이 4KB/s 링크를 통과하는데 0.25초 걸린다.

제 1 경우:

송신기 | c12 | c11 | 수신기 bw = (0.5 - 0.25)/1 KB = 4

제 2 경우:

송신기 | c21 | c12 | c11 | 수신기 bw = (0.5 - 0.25)/1 KB = 4

제 3 경우:

송신기 | c12 | c21 | c11 | 수신기 bw = (0.75 - 0.25)/1 KB = 2

제 4 경우:

송신기 | c12 | c22 | c21 | c11 | 수신기 bw = (1 - 0.25)/1 KB = 1.33

제 1 경우에서, 접속 1은 링크를 사용하는 유일한 접속이며, 따라서 이 접속 1은 완전한 대역폭을 획득하는데, 이것은 전송이 보는 것이다. 제 2, 제 3, 제 4 경우에서, 새로운 접속(c2)이 동일 링크를 사용하고 있다. 이 때, 이상적으로는 접속 1에 대한 수신 전송이 2 KB/s의 대역폭을 검출해야 한다. 그러나, 위에서 도시된 바와 같이, 이것은 접속 1의 패킷이 이격되는 방법에 따라 1.33 KB/s 내지 4 KB/s의 어딘가로 변동할 수 있다. VTP는 대역폭을 지속적으로 평균화함으로써 2 KB/s에 가깝게 된다. 수신 전송은 SACK를 통해 현재의 수신 레이트를 알려줘야 한다.

만약 시퀀스 내의 두 패킷 사이의 시간 차가 0이면, VTP는 이것을 디폴트 최대 대역폭으로 측정한다.

SACK(Selective Acknowledgment)

SACK는 수신기로부터의 피드백이다. 수신기는 다음과 같은 이유로 수신한 데이터에 대한 피드백을 가능한 자주 송신해야 한다.

· 송신기측에서 송신 윈도우를 오픈한 채로 유지하도록

· 송신기가 손실하여 수신한 패킷에 대해 알 수 있도록

· 송신기가 수신기의 현재의 수신 레이트를 알 수 있도록.

SACK는 필요할 때에만 송신되어야 한다.

확인 처리(Processing ACKnowledgement)

수신기는 다음의 경우에 확인을 송신한다.

1. RTO 가 만료되는 때

2. 16 KB 또는 32 패킷을 차례로 수신할 때

3. 임의의 계류중인 ACK가 데이터 패킷에 의해 피기백 전송(piggyback)될 수 있을 때

4. 제 1 순서화되지 않은 패킷(First out of sequence packet)

5. 대역폭의 실질적인 변화

처음 세 경우의 ACK는 소실된/수신된 데이터 패킷에 대한 정보를 포함하고, 마지막 두 경우는 아무런 새로운 데이터 패킷도 수신기에 의해 수신되지 않는 경우에도 송신될 수 있다. 소실된/수신된 정보를 갖는 ACK 수신 시에, 송신기는 즉각 확인된 VBufs를 자유롭게 해야 한다. 만약 인입 ACK가 모든 것을 out_queue에서 긍정적으로 확인하면, 즉 송신하였지만 확인되지 않으면, 그리고 송신기가 송신할 것이 있으면, '다음 전송 타이머(next transmit timer)'를 삭제해야 하고 파이프가 깨끗이 비어졌기 때문에 새로운 데이터를 송신해야 한다.

(재)전송 정책((Re)transmission Policy)

송신기는 새로운 패킷이 현재의 송신 윈도우에 알맞으면 이 새로운 패킷을 송신할 수 있다. 그렇지 않으면, 송신기는 이 패킷을 가상 접속의 외부행 큐에 남겨두고, 송신 윈도우가 다음 SACK에 의해 오픈될 때 송신한다. 송신기는 새로운 패킷을 송신할 때마다, LTO 시간에서 만료되는 새로운 타이머를 개시해야 한다. LTO 시간은 송신 시간과 트립 타임을 포함한다. 이 타이머가 만료되면, 송신기는 REQUEST_SACK 패킷을 송신하고 타이머를 재시작한다. 만약 송신기가 N 개의 (구성가능한) REQUEST_SACK 패킷을 송신한 후에 수신기로부터 어떠한 응답도 획득하지 않으면, 송신기는 수신기와의 접속을 닫아야 한다. 송신기는 송신한 패킷이 현재의 대역폭 및 지연에 기초하여 네트워크 외부에 있다고 판단할 때까지 재전송해서는 안 된다. 만약 재전송 요구가 이 플라이트 타임(flight time) 내에서 수신되면, 송신기는 재전송 요구를 무시한다.

송신기는 한번에 완전한 송신 윈도우 분량의 바이트를 송신해서는 안 된다. 이것은 다음 라우터 또는 중간 라우터에서 패킷의 버스트를 유발하며 버퍼가 불충분할 경우 패킷 드롭을 일으킬 수도 있다. 이것을 회피하기 위해, 송신기는 패킷의 흐름을 경로의 대역폭 및 지연에 따라 이들을 이격시키는 시간 단위로 제어해야 한다.

접속 종료(Connection Termination)

애플리케이션 층은 임의의 시간에 가상 접속을 종료할 수도 있다. 전송 층 은 종료(close) 타입, 즉 중단(abort) 또는 원활한 종료(graceful close)의 접속 종료 패킷을 송신해야 한다. 전송 층이 이 가상 접속으로부터 다른 단으로 진행하는 어떠한 패킷도 드롭해야 하고 애플리케이션이 그 접속을 중단하고 있으면 타입 TP_ABORT의 새로운 패킷(헤더가 충분한 경우에만)을 송신해야 한다. 그렇지 않으면, 전송 층은 모든 패킷을 송신한 다음 VC를 종료해야 한다. 후자의 경우에, 전송 층은 이 시점에서 VC가 종료되어 있음을 전달하기 위해 VC의 최종 송출 패킷 내의 TP_CLOSE 비트를 설정한다. 가상 접속이 종료되면, 그 접속에 대해 어떠한 데이터도 송신 또는 수신되지 않는다. 수신 전송층은 애플리케이션층에게 다른 측이 접속 종료를 요구받았다는 것을 통지한다. 실제 접속은 절대 종료되지 않는다는 점에 주의하라. 실제 접속은 접속의 한 쪽이 끝날 때에만 종료된다.

체크섬 계산(Checksum Computation)

전송은 데이터가 다른 쪽에 에러없이 전달되는 것을 보장해야 한다. 전송 중의 비트 에러를 검출하기 위해, 수신기에 데이터그램을 전달하기 전에 전체 패킷에 대해 체크섬이 계산된다. 수신기는 도착한 패킷에 대한 체크섬을 재계산하여, 이것을 패킷 내의 체크섬과 비교해야 한다. 만약 체크섬이 다르면, 이것을 부정한 패킷으로 간주하여 폐기시킨다. 헤더 내의 체크섬 필드는 체크섬을 계산하기 전에는 제로라야 한다. 체크섬을 계산하기 위해, 모든 데이터를 16 비트 양으로 분할하고, 이들 각각의 1의 보수(complement) 합의 1의 보수를 계산한다. 이것은 인터넷에서의 체크섬 계산과 유사하다.

인증(Authentication)

전송층에서 실제 접속이 이루어지면, 각 단 사이에서 임의의 데이터가 전송되기 전에, 클라이언트 및/또는 서버의 인증은 인증 모듈에 의해 확인될 수 있다. 실제 접속은 인증 파라미터에 따라 이루어지지 않을 수도 있다. 예를 들어, 서버가 클라이언트를 인증하기를 원하지만 클라이언트가 인증을 거부하거나 클라이언트가 인증을 지원할 수 없으면, 실제 접속은 전송 레벨에서 거부된다.

보안(Security)

임의의 악의적인 해커가 시스템에 의해 송신되는 패킷처럼 보이는 패킷을 송신하는 것을 회피하기 위해 전송에서 보안이 제공된다. 실제 접속을 중단시킬 수 있는 한가지 방법은 클라이언트/서버에 의해 송신된 인증 패킷과 함께 시퀀스 내에 가짜 패킷을 송신하는 것이다. VTP 에서의 보안의 목적은 중간 공격에서 이러한 사람에 대해 어떠한 허점도 남겨두지 않는 것이다. 이것을 회피하기 위해, 각 단은 관여된 동등 실체(peer entity)에 의해서만 디코딩될 수 있는 PRSN(pseudo-random sequence number)을 송신한다.

클라이언트는 UI로부터의 전송 레벨에서 보안을 인에이블할 수 있다. 만약 전송이 안전하게 구성되지 않으면, 데이터 전송 및 확인 프로세스를 위해 일련번호를 사용한다. 본 발명은 바람직한 실시예와 관련하여 설명되지만, 당업자라면 다른 응용이 본 발명의 사상 및 범주로부터 벗어나지 않고 본 명세서에 개시된 사항 을 대체할 수도 있음을 쉽게 알 수 있을 것이다. 예를 들면, 사전 인출 메커니즘은 단순히 순차적으로 로딩되는 것들이 아니라, 임의의 선택된 객체들의 선택적인 사전 인출을 수행할 수 있다. 어느 객체가 선택적으로 사전 인출되는 지를 판정하기 위해 사전 인출 메커니즘은 다양한 발견학, 규칙 또는 적응적 동작에 응용할 수 있다. 또한, 웹 페이지는 사전 인출 메커니즘에 의해 해석되며 어느 객체가 선택적으로 사전 인출되는 지를 판정하는 메타태그를 포함할 수 있다.

따라서, 본 발명은 첨부한 청구범위에 의해서만 제한된다.

Claims

브라우저를 이용하여, 긴 지연 링크(long-latency link)를 통해 개별적으로 인출되어야 하는 복수의 웹 페이지 객체로 이루어진 웹 페이지를 디스플레이하는 장치에 있어서,

집합적이며 흐름 제어된 채널(aggregated and flow-controlled channel)을 통해 객체들을 동시에 선택적으로 사전 인출(pre-fetch)하는 수단과,

상기 브라우저에 상기 사전 인출된 객체를 인접하게 캐시하는 수단을 포함하되,

상기 웹 페이지 객체에 대한 순차적인 액세스는 브라우저 동작을 변경하지 않고 저 대역폭 및 고 지연 네트워크에서 제공되는

웹 페이지 디스플레이 장치.
제 1 항에 있어서,

상기 선택적으로 사전 인출하는 수단은 에이전트로부터 게이트웨이 서버로 상기 사전 인출을 수행하고,

낮은 정도의 병렬 처리는 상기 브라우저와 상기 에이전트 사이로 제한되는

웹 페이지 디스플레이 장치.
제 1 항에 있어서,

상기 선택적으로 사전 인출하는 수단은 대응 서버 모듈과 통신하여 필요한 웹 페이지 객체를 상기 브라우저를 호스팅하는 플랫폼상에서 이용가능하게 준비하는 모듈을 포함하는

웹 페이지 디스플레이 장치.
제 2 항에 있어서,

상기 에이전트와 상기 게이트웨이는 함께, 선택적인 삽입된 웹 페이지 객체의 인출을 조정함으로써 상기 웹 브라우저가 웹 페이지 객체들을 인출하는 것을 지원하고,

선택된 삽입된 웹 페이지 객체는 상기 브라우저에 국부적으로 이용가능하고,

상기 브라우저는 객체가 이용가능하기 전에 긴 지연 링크를 통한 요구 및 대응 응답을 기다릴 필요가 없는

웹 페이지 디스플레이 장치.
브라우저 및 호스트 플랫폼과 관련된 에이전트와,

소스 웹 서버와 통신하는 게이트웨이와,

상기 에이전트와 상기 게이트웨이 사이의 긴 지연 링크와,

상기 소스 웹 서버로부터 상기 저 지연 링크를 통해 상기 브라우저로 병렬로 웹 페이지 객체들을 다운로딩하는 독립적인 흐름 제어 메커니즘(VTP)과,

상기 브라우저와 상기 소스 웹 서버의 구현과 관계없이 상기 에이전트가 웹 페이지 객체를 식별하는 순간에 웹 페이지 객체가 선택적으로 병렬로 다운로딩되는 상기 호스트 플랫폼과 관련된 캐시를 포함하되,

선택된 삽입된 웹 페이지 객체만이 상기 에이전트에 의해 상기 캐시에서 상기 브라우저에 이용가능하게 되고,

상기 브라우저는 웹 객체가 이용가능하게 되기 전에 상기 긴 지연 링크를 통한 요구 및 대응 응답을 기다릴 필요가 없는

장치.
긴 지연 링크를 통한 HTTP의 성능을 향상시키는 장치에 있어서,

호스트 플랫폼 내의 브라우저와,

사전 인출 기능을 갖는 에이전트와 웹 객체 캐시를 포함하는 상기 플랫폼과 관련된 클라이언트로서, 상기 에이전트는 선택된 순차적으로 로딩된 웹 페이지 객체를 명시적으로 사전 인출하여 상기 사전 인출된 객체를 상기 웹 객체 캐시에 저장하는, 상기 클라이언트와,

흐름 제어 채널을 갖는 긴 지연 링크를 통해 상기 클라이언트와 통신하는 서버와,

상기 서버와 통신하는 오리지널 웹 서버를 포함하되,

상기 브라우저를 통한 요구에 따라 상기 오리지널 웹 서버로부터 요구되는 순차적으로 로딩된 웹 페이지 객체는 상기 에이전트를 통해 상기 웹 객체 캐시로 로딩되고,

상기 순차적으로 로딩된 웹 페이지 객체는 상기 요구 시에 상기 웹 객체 캐시에서 이용가능하며 이로부터 로딩되고,

상기 요구 및 그에 대한 응답은 상기 긴 지연 링크를 통하지 않는

HTTP의 성능을 향상시키는 장치.
제 6 항에 있어서,

상기 순차적으로 로딩된 객체는 자바스크립트 및 스타일 시트 중 어느 하나를 포함하는

HTTP의 성능을 향상시키는 장치.
긴 지연 링크를 통한 웹 페이지 로딩의 성능을 향상시키는 방법에 있어서,

클라이언트와 관련된 브라우저가 상기 긴 지연 링크의 제 1 단부로부터 웹 페이지를 요구하는 단계와,

게이트웨이가 상기 긴 지연 링크의 제 2 단부에서 상기 요구를 수신하고, 상기 게이트웨이가 오리지널 웹 서버로부터 웹 페이지 기술을 검색하고 상기 웹 페이지 기술을 상기 긴 지연 링크를 통해 상기 클라이언트에게 송신하는 단계와,

상기 브라우저가 상기 웹 페이지 기술을 수신하고 분석하는 단계와,

상기 웹 페이지를 로드하기 위해 상기 웹 페이지 기술이 상기 브라우저에 의해 조작되는 동안, 동시에, 일반적으로 순차적으로 인출되는 선택된 웹 페이지 객체 유형의 객체들을 식별하기 위해 상기 브라우저와 독립적으로 상기 페이지 기술 을 분석하는 단계와,

상기 브라우저가 상기 웹 페이지를 로딩하는 동안 동시에 상기 브라우저가 사전 인출 메커니즘을 이용하여 상기 오리지널 웹 서버에 액세스하여 상기 객체를 인출하는 단계와,

상기 사전 인출 메커니즘을 이용하여 상기 객체를 인출한 후에 상기 객체를 로컬 캐시에 저장하는 단계와,

상기 브라우저가 상기 웹 페이지의 로딩을 완료하기 위해 상기 객체를 위한 상기 로컬 캐시에 액세스하는 단계를 포함하되,

상기 객체는 상기 브라우저가 상기 긴 지연 링크를 통해 상기 객체를 요구하지 않고 로딩되는

웹 페이지 로딩의 성능을 향상시키는 방법.
제 8 항에 있어서,

상기 분석하는 단계는 상기 웹 페이지 내에 자바스크립트 또는 스타일 시트가 있는 지의 여부를 판정하고,

상기 사전 인출 메커니즘은 상기 브라우저가 상기 웹 페이지를 로딩하는 것과 동시에 상기 객체를 인출하는

웹 페이지 로딩의 성능을 향상시키는 방법.
제 8 항에 있어서,

상기 사전 인출 메커니즘이 임의의 지정된 객체의 선택적인 사전 인출을 수행하는 단계를 더 포함하되,

상기 사전 인출 메커니즘은 사전 인출 동작이 상기 브라우저에 의해 이미 요구된 객체의 인출을 지연시키는 것에 대해 갖는 영향을 감소시키기 위해 어느 객체가 선택적으로 사전 인출되는 지를 판정하기 위해 발견학(heuristics), 규칙 및 적응적 동작 중 어느 하나를 적용하는

웹 페이지 로딩의 성능을 향상시키는 방법.
제 8 항에 있어서,

상기 웹 페이지는 중심 지점에서 임의의 발견학의 적용을 통해 상기 게이트웨이에 의해 제공되는 메타태그를 포함하며,

상기 방법은 어느 객체가 선택적으로 사전 인출되는 지를 판정하기 위해 상기 사전 인출 메커니즘을 이용하여 상기 메타태그를 해석하는 단계를 더 포함하는

웹 페이지 로딩의 성능을 향상시키는 방법.
브라우저로, 긴 지연 링크를 통해 개별적으로 인출되어야하는 복수의 웹 페이지 객체로 이루어진 웹 페이지를 디스플레이하는 방법에 있어서,

집합적이며 흐름 제어된 채널을 통해 객체들을 동시에 선택적으로 사전 인출하는 단계와,

상기 사전 인출된 객체를 인접하게 상기 브라우저에 캐시하는 단계를 포함하 되,

브라우저의 동작을 변경하지 않고 저 대역폭의 고 지연 네트워크에서 상기 웹 페이지 객체에 대한 순차적인 액세스가 제공되는

웹 페이지 디스플레이 방법.
제 12 항에 있어서,

상기 선택적으로 사전 인출하는 단계는 에이전트로부터 게이트웨이 서버로 상기 사전 인출을 수행하는 단계를 더 포함하고,

낮은 정도의 병렬 처리가 상기 브라우저와 상기 에이전트 사이로 제한되는

웹 페이지 디스플레이 방법.
제 12 항에 있어서,

상기 선택적으로 사전 인출하는 단계는 대응 서버 모듈과 통신하는 단계와, 필요한 웹 페이지 객체를 상기 브라우저를 호스팅하는 플랫폼 상에서 이용가능하게 준비하는 단계를 더 포함하는

웹 페이지 디스플레이 방법.
제 13 항에 있어서,

상기 에이전트와 상기 게이트웨이는 함께, 선택적인 삽입된 웹 페이지 객체 의 인출을 조정함으로써 상기 웹 브라우저가 웹 페이지 객체들을 인출하는 것을 지원하고,

선택된 삽입된 웹 페이지 객체는 상기 브라우저에 국부적으로 이용가능하고,

상기 브라우저는 객체가 이용가능하기 전에 긴 지연 링크에 대한 요구 및 대응 응답을 기다릴 필요가 없는

웹 페이지 디스플레이 방법.
긴 지연 링크를 통한 HTTP의 성능을 향상시키는 방법에 있어서,

호스트 플랫폼 내에서 브라우저를 사용하는 단계와,

사전 인출 기능을 갖는 에이전트와 웹 객체 캐시를 포함하는 상기 플랫폼과 관련된 클라이언트를 제공하는 단계로서, 상기 에이전트는 선택된 순차적으로 로딩된 웹 페이지 객체를 명시적으로 사전 인출하여 상기 사전 인출된 객체를 상기 웹 객체 캐시에 저장하는, 상기 클라이언트 제공 단계와,

흐름 제어된 채널을 갖는 긴 지연 링크를 통해 상기 클라이언트와 통신하는 서버를 제공하는 단계와,

상기 서버와 통신하는 오리지널 웹 서버에 액세스하는 단계를 포함하되,

상기 브라우저를 통한 요구에 따라 상기 오리지널 웹 서버로부터 요구되는 순차적으로 로딩된 웹 페이지 객체가 상기 에이전트를 통해 상기 웹 객체 캐시로 로딩되고,

상기 순차적으로 로딩된 웹 페이지 객체는 상기 요구 시에 상기 웹 객체 캐시에서 이용가능하며 이로부터 로딩되고,

상기 요구 및 그에 대한 응답은 상기 긴 지연 링크를 통하지 않는

HTTP의 성능을 향상시키는 방법.
제 16 항에 있어서,

상기 순차적으로 로딩된 객체는 자바스크립트 및 스타일 시트 중 어느 하나를 포함하는

HTTP의 성능을 향상시키는 방법.
긴 지연 링크를 통한 웹 페이지 로딩의 성능을 향상시키는 장치에 있어서,

상기 긴 지연 링크의 제 1 단부로부터 웹 페이지를 요구하는, 클라이언트와 관련된 브라우저로서, 웹 페이지 기술을 수신 및 분석하는 브라우저와,

상기 긴 지연 링크의 제 2 단부에서 상기 요구를 수신하고, 오리지널 웹 서버로부터 웹 페이지 기술을 검색하고 상기 웹 페이지 기술을 상기 긴 지연 링크를 통해 상기 클라이언트에게 송신하는 게이트웨이와,

상기 웹 페이지를 로드하기 위해 상기 웹 페이지 기술이 상기 브라우저에 의해 조작되는 동안, 동시에, 일반적으로 순차적으로 인출되는 선택된 웹 페이지 객 체 유형의 객체들을 식별하기 위해 상기 브라우저와 독립적으로 상기 페이지 기술을 분석하는 파서(parser)와,

상기 브라우저가 상기 웹 페이지를 로딩하는 동안 동시에 상기 오리지널 웹 서버에 액세스하여 상기 객체를 인출하기 위해 상기 브라우저가 이용하는 사전 인출 메커니즘과,

상기 사전 인출 메커니즘으로 상기 객체를 인출한 후에 상기 객체를 저장하는 로컬 캐시를 포함하되,

상기 브라우저는 상기 웹 페이지의 로딩을 완료하기 위해 상기 객체를 위한 상기 로컬 캐시에 액세스하고,

상기 객체는 상기 브라우저가 상기 긴 지연 링크를 통해 상기 객체를 요구하지 않고 로딩되는

웹 페이지 로딩의 성능을 향상시키는 장치.
제 18 항에 있어서,

상기 파서는 상기 웹 페이지 내에 자바스크립트 또는 스타일 시트가 있는 지의 여부를 판정하고,

상기 사전 인출 메커니즘은 상기 브라우저가 상기 웹 페이지를 로딩하는 것과 동시에 상기 객체를 인출하는

웹 페이지 로딩의 성능을 향상시키는 장치.
제 18 항에 있어서,

임의의 지정된 객체들의 선택적인 사전 인출을 수행하는 상기 사전 인출 메커니즘과 관련된 수단을 더 포함하되,

상기 사전 인출 메커니즘은 어느 객체가 선택적으로 사전 인출되는 지를 판정하기 위해 발견학(heuristics), 규칙 및 적응적 동작 중 어느 하나를 적용하는

웹 페이지 로딩의 성능을 향상시키는 장치.
제 18 항에 있어서,

상기 웹 페이지는, 다양한 흐름(flows)에 대해 집중 정보(centralized intelligence)를 적용하는, 상기 게이트웨이에 의해 에이전트에게 제공된 메타태그를 포함하며,

상기 장치는 어느 객체가 선택적으로 사전 인출되는 지를 판정하기 위해 상기 메타태그를 해석하는 상기 사전 인출 메커니즘과 관련된 수단을 더 포함하는

웹 페이지 로딩의 성능을 향상시키는 장치.