## 요구사항 및 사용 사례
이 문서는 두 가지 특정 요구사항을 다루는 API를 설명합니다:
### 네트워크와 통신하는 데 현재 사용되는 [연결 유형](https://wicg.github.io/netinfo/#dfn-connection-types)을
판별하기 위한 인터페이스 제공.
클라이언트 페이지에서 임시 방식으로 질의할 수 있어야 하며, [서비스 워커](https://w3c.github.io/ServiceWorker/v1/)에
노출되는 것과 같은 다른 컨텍스트에서도 사용할 수 있어야 합니다.
**사용 사례 예시:**
* 미디어 스트리밍이 주된 목적인 웹 애플리케이션은 재생 전에 `navigator.connection.type`을 확인할 수 있습니다.
이 값이 `'cellular'`로 설정되어 있으면, 모바일 네트워크 사업자가 대역폭에 대해 요금을 부과할 수 있음을
사용자에게 알리고, 이전에 캐시된 콘텐츠의 자동 재생만 시작할 수 있습니다.
* 서비스 워커를 사용하여 [설치](https://w3c.github.io/ServiceWorker/v1/#installation-algorithm) 중에 리소스를
[캐시](https://w3c.github.io/ServiceWorker/v1/#cache-objects)하는 웹 애플리케이션은 캐시할 수 있는 서로 다른
에셋 번들을 가질 수 있습니다: 무조건 캐시되는 중요 에셋 목록과, `navigator.connection.type`이 `'ethernet'` 또는
`'wifi'`일 때만 미리 캐시되는 더 크고 선택적인 에셋 번들입니다.
* [백그라운드
싱크](https://github.com/WICG/BackgroundSync/blob/master/explainer.md) 핸들러와 함께 서비스 워커를 사용하는
웹 애플리케이션은 현재 `navigator.connection.type` 값을 확인하고, 그 값이 `'ethernet'` 또는
`'wifi'`인 경우에만 `sync` 이벤트 핸들러 내부에서 데이터를 전송할 수 있습니다.
* 웹 애플리케이션은 네트워크 상태에 따라 오프라인 모드 활성화를 결정할 수 있습니다(예: EDGE로 충분하지
않을 때).
### 연결 유형이 변경되면 스크립트가 알림을 받을 수 있는 방법 제공.
이를 통해 개발자는 네트워크 연결 유형이 변경되었으며 어떤 방식으로든 영향을 줄 수 있음을 사용자에게 알리기 위해
사용자 인터페이스를 동적으로 변경할 수 있습니다. 또한 대량의 데이터 전송을 미루고 있던 애플리케이션이
고대역폭 네트워크가 감지되면 자동으로 시작할 수 있게 합니다.
**사용 사례 예시:**
* 미디어 스트리밍이 주된 목적인 웹 애플리케이션은 연결 유형의 업데이트에 응답하여 사용자 인터페이스를 동적으로
변경할 수 있습니다. 이는 사용자가 재생을 시도하고 일회성 질의를 수행할 때까지 기다리는 것보다 더 나은 사용자
경험을 제공할 수 있습니다. 이를 통해 애플리케이션은 사용자 상호작용에 앞서 연결에 대한 컨텍스트를 제공할 수
있습니다.
* 업로드 또는 다운로드를 허용하는 웹 애플리케이션은 `navigator.connection.type`이 `'cellular'`로 설정되어 있을 때
요청 시작을 미루고, 연결 변경에 대한 리스너를 추가할 수 있습니다. 고대역폭 네트워크 유형으로의
변경이 감지되면 요청이 자동으로 시작될 수 있습니다.
## 정의
명확히 하기 위해, megabit은 1,000,000비트이고, megabits per second는
다음을 전송하는 것과 동등합니다:
* 초당 1,000,000비트
* 초당 1,000킬로비트
* 초당 125,000바이트
* 초당 125킬로바이트
* 등등...
## 연결 유형
### 기반 연결 기술
이 절은 user agent가 사용 중인(있는 경우) connection types와
underlying connection
technology를 정의합니다:
- bluetooth
- 블루투스 연결.
- cellular
- 셀룰러 연결(예: EDGE, HSPA, LTE 등).
- ethernet
- 이더넷 연결.
- none
- 네트워크 연결 없음. 사용자가 링크를 따라가거나 스크립트가 원격 페이지를
요청할 때(또는 그러한 시도가 실패할 것을 알고 있을 때) 사용자 에이전트는 네트워크에 접속하지 않습니다 - 즉, HTML의
navigator.onLine === false와 동등합니다.
- mixed
- 사용자 에이전트가 여러 연결 유형을 사용하고 있습니다.
- other
- 알려져 있지만 열거된 연결 유형 중 하나가 아닌 연결 유형.
- unknown
- 사용자 에이전트가 네트워크 연결을 설정했지만, underlying
connection technology를 판별할 수 없거나 판별하려 하지 않습니다.
- wifi
- Wi-Fi 연결.
- wimax
- WiMAX 연결.
connection types는 이 API에서 ConnectionType 열거형으로 표현됩니다.
### ConnectionType 열거형
enum ConnectionType {
"bluetooth",
"cellular",
"ethernet",
"mixed",
"none",
"other",
"unknown",
"wifi",
"wimax"
};
### 유효 연결 유형
이 절은 effective connection types(ECT)를 정의합니다:
Table of effective connection types
| ECT |
최소 RTT (ms) |
최대 다운링크 (Kbps) |
설명 |
| slow-2g |
2000 |
50 |
네트워크는 텍스트 전용 페이지와 같은 작은 전송에만 적합합니다. |
| 2g |
1400 |
70 |
네트워크는 작은 이미지 전송에 적합합니다. |
| 3g |
270 |
700 |
네트워크는 고해상도 이미지, 오디오, SD 비디오와 같은 큰 에셋 전송에 적합합니다.
|
| 4g |
0 |
∞ |
네트워크는 HD 비디오, 실시간 비디오 등에 적합합니다. |
위의 왕복 시간 및 대역폭 값은 실제 사용자 측정 관찰에 기반합니다:
* `slow-2g`는 2G 관찰값의 66.6번째 백분위수입니다
* `2g`는 2G 관찰값의 50번째 백분위수입니다
* `3g`는 3G 관찰값의 50번째 백분위수입니다
위에 제공된 절대값은 2017년 4월에 캡처된 Android의 Chrome에 대한 실제 사용자 측정에 기반합니다.
사용자 에이전트는 측정 데이터의 변경을 반영하기 위해 향후 이 값을 업데이트할 수 있습니다(MAY).
effective connection types는 이 API에서 EffectiveConnectionType 열거형으로 표현됩니다.
### EffectiveConnectionType 열거형
enum EffectiveConnectionType {
"2g",
"3g",
"4g",
"slow-2g"
};
## NavigatorNetworkInformation 인터페이스
Navigator 및
WorkerNavigator 인터페이스는 NavigatorNetworkInformation을
믹스인하여 NetworkInformation 인터페이스에 대한 접근을 노출합니다.
interface mixin NavigatorNetworkInformation {
[SameObject] readonly attribute NetworkInformation connection;
};
Navigator includes NavigatorNetworkInformation;
WorkerNavigator includes NavigatorNetworkInformation;
## NetworkInformation 인터페이스
NetworkInformation 인터페이스는 사용자 에이전트가 현재 사용 중인 네트워크 연결에 대한 정보에 접근하는
수단을 제공합니다. EventTarget은
[[!DOM]]에 정의되어 있습니다.
[Exposed=(Window,Worker)]
interface NetworkInformation : EventTarget {
readonly attribute ConnectionType type;
readonly attribute EffectiveConnectionType effectiveType;
readonly attribute Megabit downlinkMax;
readonly attribute Megabit downlink;
readonly attribute Millisecond rtt;
attribute EventHandler onchange;
};
typedef unrestricted double Megabit;
typedef unsigned long long Millisecond;
이 절은 또한 사용자의 네트워크 상태에 대한 세부 정보를 노출하는 여러 HTTP 요청 헤더 필드를 정의하며,
서버는 이를 수신하도록 선택할 수 있습니다. 서버는 [[CLIENT-HINTS]]에 정의된 Client Hints 인프라를 통해
이를 수행할 수 있으며, 이는 [[CLIENT-HINTS-INFRASTRUCTURE]]에 정의된 처리 모델에 의해 바인딩됩니다.
### type 속성
type 속성은 가져올 때 사용자 에이전트가 사용 중인 connection type을 반환합니다.
### effectiveType 속성
effectiveType 속성은 가져올 때 최근에 관찰된 rtt 및 downlink 값의 조합을 사용하여
판별된 effective connection type을 반환합니다.
#### ECT 요청 헤더 필드
ECT 요청 헤더 필드는 사용자 에이전트가 요청을 보내는 시점의 effectiveType을 나타내는 토큰이며,
이는 EffectiveConnectionType 값 중 하나입니다.
이것은 값이 반드시 토큰이어야 하는 Structured Header입니다. [[STRUCTURED-HEADERS]]
### downlinkMax 속성
downlinkMax 속성은 upper bound on the downlink speed of the first network
hop를 나타냅니다. 보고되는 값은 megabits per second 단위이며,
underlying connection technology의 속성에 의해 결정됩니다.
### onchange 속성
onchange 이벤트 핸들러 속성은 steps to update the
connection values 중에 발생하는 "change" 이벤트를 처리합니다.
### downlink 속성
downlink 속성은 megabits per second 단위의 유효 대역폭 추정치를 나타내며, 가장 가까운
초당 25킬로비트의 배수로 반올림되고, 사설 주소 공간 [[!RFC1918]]으로 이루어진 연결을 제외한 최근 활성
연결 전반에 걸쳐 최근에 관찰된 애플리케이션 계층 처리량에 기반합니다. 최근 대역폭 측정 데이터가 없는
경우, 속성 값은 underlying connection
technology의 속성에 의해 결정됩니다.
#### `Downlink` 요청 헤더 필드
Downlink 요청 헤더 필드는 사용자 에이전트가 요청을 보내는 시점의 downlink 값을 나타내는
숫자입니다.
이것은 값이 반드시 십진수여야 하는 Structured Header입니다. [[STRUCTURED-HEADERS]]
### rtt 속성
rtt 속성은 밀리초 단위의 유효 왕복 시간 추정치를 나타내며, 가장 가까운 25밀리초의
배수로 반올림되고, 사설 주소 공간 [[!RFC1918]]으로 이루어진 연결을 제외한 최근 활성 연결 전반에 걸쳐
최근에 관찰된 애플리케이션 계층 RTT 측정값에 기반합니다. 최근 RTT 측정 데이터가 없는 경우, 속성 값은
underlying connection technology의 속성에 의해 결정됩니다.
#### `RTT` 요청 헤더 필드
RTT 요청 헤더 필드는 사용자 에이전트가 요청을 보내는 시점의 rtt 값을 나타내는
숫자입니다.
이것은 값이 반드시 정수여야 하는 Structured Header입니다. [[STRUCTURED-HEADERS]]
## 기반 연결 기술
underlying connection technology와 그 upper bound on the downlink speed
of the first network hop 사이의 관계는 새 네트워크 요청을 이행하는 데 사용될 수 있는 사용 가능한
네트워크 인터페이스에 의해 결정됩니다.
downlinkMax for an available interface는 table of maximum downlink speeds에 기록된 표준화된,
또는 일반적으로 받아들여지는 최대 다운로드 데이터 속도를 통해 결정됩니다. 가능한 경우, 이 값은 인터페이스의
현재 속성에 기반하여 더 정확한 상한값을 보고하도록 개선될 수 있습니다 - 예: 신호
세기, 변조 알고리즘, 그 외 다른 "network weather" 변수.
upper bound on the downlink speed of the first network hop는
href="#handling-changes-to-the-underlying-connection">기반 연결 변경 처리에 설명된 규칙에 의해 결정됩니다.
사용 가능한 네트워크 인터페이스와 그 세대 및 버전의 열거는 스크립트에 직접 노출되지
않습니다. 대신, `downlinkMax`는 사용 가능한 모든 인터페이스와 그 현재 네트워크 상태를 반영하는
megabits per second 단위의 단일 값을 노출합니다.
### 기반 연결 변경 처리
다른 connection type 또는 effective connection type으로의 전환, upper bound on the downlink speed of
the first network hop의 변경, 또는 유효 downlink나 rtt 추정치의 변경으로 인해
underlying connection technology의 속성이 변경되면, 사용자 에이전트는
steps to update the connection values를 실행해야 합니다(MUST):
1. new-type을 underlying connection
technology를 나타내는 connection type으로 둡니다.
1. new-effective-type을 현재 downlink 및 rtt 값에 의해 판별된
effective connection type으로 둡니다.
1. new-downlink를 다음의 결과로 둡니다:
1. downlink 값을 가장 가까운 초당 25킬로비트의 배수로 반올림합니다.
1. 결과 값이 `connection.downlink` 값보다 10% 더 크거나 작으면,
new-dowlink를 결과 값으로 설정합니다. 그렇지 않으면, new-downlink를
`connection.downlink` 값으로 설정합니다.
1. new-rtt를 다음의 결과로 둡니다:
1. rtt 값을 가장 가까운 25밀리초의 배수로 반올림합니다.
1. 결과 값이 `connection.rtt` 값보다 10% 더 크거나 작으면,
new-rtt를 결과 값으로 설정합니다. 그렇지 않으면, new-rtt를 `connection.rtt` 값으로 설정합니다.
1. new-type이 "none"이면, max-value를 `0`으로 설정합니다.
1. new-type이 "unknown"이면, max-value를 `+Infinity`로 설정합니다.
1. new-type이 "mixed"이면, max-value를 새 네트워크 요청을 처리하는 데 사용되는 인터페이스
구성에 적용 가능한 값으로 설정합니다 - 예: 여러 인터페이스가 사용될 수 있으면, 그
downlinkMax for an available interface 값을 합산합니다.
1. 그렇지 않으면, max-value를 downlinkMax for an available interface로 설정합니다.
1. max-value가 `connection.downlinkMax` 값과 같지 않거나, new-type이
`connection.type` 값과 같지 않거나, new-downlink가
`connection.downlink` 값과 같지 않거나, new-rtt가 `connection.rtt` 값과 같지 않으면:
1. networking task source를 사용하여, 다음을 수행하도록
data-cite="!HTML#queue-a-task">작업을 대기열에 넣습니다:
1. `connection.downlinkMax`를 max-value로 설정합니다.
1. `connection.type`을 new-type으로 설정합니다.
1. `connection.effectiveType`을 new-effective-type으로 설정합니다.
1. `connection.downlink`를 new-downlink로 설정합니다.
1. `connection.rtt`를 new-rtt로 설정합니다.
1. `NetworkInformation` 객체에서 `change`라는 이름의 이벤트를 발생시킵니다.
## 프라이버시 고려사항
네트워크 정보 API는 관찰된 종단 간 네트워크 대역폭과 지연 시간, 그리고 사용자 에이전트와 서버 사이의
첫 번째 네트워크 홉에 대한 정보를 노출합니다; 구체적으로, 연결 유형과 다운링크 속도의 상한값, 그리고
이 정보가 변경될 때마다의 신호입니다. 이러한 정보는 다음에 사용될 수
있습니다:
* 특정 시점에서 특정 네트워크의 특성(예: 유형 및 다운링크 추정치)에 기반하여, 그리고 일정 기간 동안
그러한 특성의 변경을 관찰함으로써 사용자를 지문 식별합니다.
* 하나 이상의 네트워크 사이의 전환(예: 유형, 다운링크 추정치, 시간에 따른 전환 순서)에 기반하여
사용자를 지문 식별합니다.
* 위 기준에 기반하여 사용자 위치(예: 집, 직장, 이동 중인지)를 추론합니다.
그러나 위의 고려사항은 새로운 것이 아니며, 충분히 동기가 부여된 공격자는 이미 다른 기술을 사용하여
그러한 정보를 얻을 수 있습니다:
* 공격자는 JavaScript를 사용하여 클라이언트에서 모든 네트워크 페치(동일 출처 또는 교차 출처)의
기간(예: 페치 시작부터 `onload` 이벤트까지의 시간)을 관찰할 수 있으며, Resource Timing API를 통해
동일한 페치에 대한 더 자세한 타이밍 데이터를 얻을 수 있습니다.
* 공격자는 WebRTC를 사용하여 STUN 또는 유사한 메커니즘을 통해 클라이언트의 공인 및 사설 IP 주소를
식별할 수 있습니다.
* 공격자는 서버에서 페치의 클라이언트 IP, 페치 기간, RTT, 전송 속도, 그 외 다른 저수준 소켓
지표를 관찰할 수 있습니다.
나아가, 위 전략 중 하나를 반복함으로써(예: 리소스의 주기적 페치 또는 새로 고침 호출을 통해;
주기적 SSE 또는 WebSocket 메시지를 통해; 주기적 STUN 요청을 통해 등), 공격자는 클라이언트의 연결 및
IP 주소의 성능 특성이 시간에 따라 변하는 것을 관찰할 수 있습니다. 그러면 이러한 데이터는 사용자 지문을
정교화하고, 사용자 위치(예: 집, 직장, 이동 중인지)를 추론하며, 다양한 행동 패턴을 추출하는 데 사용될 수
있습니다.
위 목록은 완전한 개요가 아닙니다. 그러나 위 예시가 보여주듯이, 공격은 발신자와 수신자
양쪽에서 모두 가능합니다:
* 공격자가 클라이언트로부터 모든 종류의 네트워크 페치를 시작하거나 관찰할 수 있다면, 그
성능 특성과 그것이 시간에 따라 어떻게 변하는지 관찰할 수 있습니다.
* 공격자가 클라이언트로 하여금 자신의 서버에서 리소스를 페치하도록 설득할 수 있다면, 마찬가지로
페치의 성능 특성과 그것이 시간에 따라 어떻게 변하는지 관찰할 수 있습니다.
클라이언트에서 시작되는 그러한 공격을 완화하려면 공격자가 네트워크 요청을 관찰하고 시작하는 것을
방지해야 합니다 - 예: 악의적인 당사자에 의한 사소한 콘텐츠 주입을 방지하기 위해 HTTPS를 사용하고; 모든
종류의 스크립트 리소스 페치를 방지하기 위해 JavaScript를 비활성화합니다. 발신자로부터의 공격 완화는
VPN 또는 HTTP 프록시 사용을 통해 가능합니다 - 예: 클라이언트의 실제 IP 주소를 숨기고, 추가 지연 시간을 도입하는 등.
따라서, 네트워크 정보 API는 네트워크 요청을 관찰하거나 만들 필요를 피함으로써 종단 간 네트워크
처리량, 지연 시간, 첫 번째 네트워크 홉에 대한 정보를 얻기 더 쉽게 만들지만, 충분히 동기가 부여된
공격자가 이미 이용할 수 없는 것은 아무것도 노출하지 않습니다.
클라이언트가 이러한 종류의 공격을 완화하고자 한다면, JavaScript를 비활성화하고, 모든 아웃바운드
요청이 신뢰할 수 있는 출처로 이루어지는지 모니터링하며, 익명화 VPN/프록시 서비스를 부지런히 활용해야 합니다.
## IANA 고려사항
다음 세 개의 HTTP 요청 헤더 필드는 HTTP/1.1 [[!RFC7231]]이 제공하는 지침을 고려하여, 메시지 헤더
필드의 영구 레지스트리(see [[!RFC3864]])에 추가되어야 합니다.
### `ECT` 요청 헤더 필드 등록
* Header Field Name: ECT
* Applicable Protocol: Hypertext Transfer Protocol (HTTP)
* Status: Standard
* Author/Change controller: W3C
* Specification document(s): W3C TR https://www.w3.org/TR/netinfo/
### `Downlink` 요청 헤더 필드 등록
* Header Field Name: Downlink
* Applicable Protocol: Hypertext Transfer Protocol (HTTP)
* Status: Standard
* Author/Change controller: W3C
* Specification document(s): W3C TR https://www.w3.org/TR/netinfo/
### `RTT` 요청 헤더 필드 등록
* Header Field Name: RTT
* Applicable Protocol: Hypertext Transfer Protocol (HTTP)
* Status: Standard
* Author/Change controller: W3C
* Specification document(s): W3C TR https://www.w3.org/TR/netinfo/
## 감사의 말
이 문서는 [[!HTML]] 명세의 라이선스가 허용하는 바에 따라
해당 명세의 텍스트를 재사용합니다.