recursal/MDN huggingface dataset:
HTTP/2
======

**HTTP/2** 는 HTTP 네트워크 프로토콜의 주요 개정판입니다.

HTTP/2의 주요 목표는 "지연 시간"을 감소시키는 것입니다. 전체 요청과 응답 멀티플렉싱을 가능하게 하여 대기 시간을 줄이고, HTTP 헤더 필드를 효율적으로 압축함으로써 프로토콜 오버헤드를 최소화하고, 요청에 대한 우선 순위를 결정하고 서버 푸시 지원을 추가하는 것입니다.

HTTP/2는 어떤 방식으로도 HTTP의 어플리케이션 의미를 수정하지 않습니다. HTTP 메서드, 상태 코드, URI, 헤더 필드와 같은 HTTP 1.1의 핵심 개념은 그대로 유지하는 대신, HTTP/2는 전체 프로세스를 관리하는 클라이언트-서버 사이의 데이터의 형식(프레임)과 전송 방식을 수정하여 새로운 프레임 계층 내에서 어플리케이션 복잡성을 숨깁니다. 결과적으로, 기존의 모든 어플리케이션은 수정 과정을 거치지 않고 전달될 수 있습니다.

같이 보기
-----

* MDN의 HTTP 설명
* 위키피디아의 HTTP/2
* 용어 사전
    + HTTP
    + Latency
암호화 스위트 (Cipher suite)
======================

암호화 스위트는 키 교환 알고리즘, 인증 방법, 대량 암호화 암호 및 메시지 인증 코드의 조합입니다.

TLS와 같은 암호화시스템에서는, 클라이언트와 서버는 안전하게 통신을 시작하기 전에 암호화 스위트에 동의해야 합니다. 일반적인 암호화 스위트는 ECDHE\_RSA\_WITH\_AES\_128\_GCM\_SHA256 또는 ECDHE-RSA-AES128-GCM-SHA256 유사하고 다음을 나타냅니다.

* 키 교환을 위한 ECDHE (타원 곡선 일시적인 Diffie-Hellman)
* 인증을 위한 RSA
* AES-128을 암호로 사용하고, Galois/Counter Mode (GCM)를 블록 암호 운용 방식으로 사용
* 해시 기반 메시지 인증 코드인 SHA-256 (HMAC)
같이 보기
-----

* Mozilla는 TLS에 대한 암호화 스위트 선택을 권장합니다
Copyleft
========

Copyleft는 일반적으로 라이선스를 지칭하는 용어로서, 그러한 라이선스는 해당 저작물의 재배포가 원래 라이선스와 동일한 라이선스의 대상이 되어야 한다는 것을 나타내기 위해 사용됩니다. copyleft 라이선스의 예로는 GNU GPL(소프트웨어용)과 Creative Commons SA(Share Alike) 라이선스(예술 작품에서)가 있습니다.

같이 보기
-----

* Wikipedia의 Copyleft
스크롤 컨테이너 (Scroll container)
===========================

**스크롤 컨테이너(scroll container)** 는 스크롤 막대가 있는지 여부에 관계없이, 콘텐츠를 스크롤할 수 있는 요소 상자입니다. CSS `overflow` 속성이 `scroll`로 설정되거나 `overflow`가 `auto`로 설정되고 콘텐츠가 컨테이너를 넘어갈 때 사용자 에이전트는 요소 상자에 스크롤 막대를 추가해 스크롤 컨테이너로 만들어줍니다.

요소 상자의 콘텐츠가 테두리 상자를 넘으면, 사용자는 스크롤 막대를 사용해 화면 요소에서 숨겨졌던 잘린 콘텐츠를 스크롤 할 수 있습니다.

스크롤 컨테이너에는 스크롤포트와 스크롤 막대가 포함되어 있습니다.

스크롤포트(Scrollport)
-----------------

스크롤포트는 스크롤 컨테이너의 보이는 부분이며 스크롤 컨테이너의 패딩 상자와 일치합니다. 스크롤 막대는 내용을 볼 수 있도록 스크롤포트 안과 밖으로 내용을 이동하는 데 사용됩니다.
느슨한 모드 (Sloppy mode)
====================

ECMAScript 5 이상에서는 스크립트가 탄력성(일부 실패가 전체에 영향을 끼치지 않는 특성)을 향상하기 위해 여러 가지 방법으로 JavaScript의 의미를 변경하고 문제가 발생했을 때 무슨 일이 일어나고 있는지 더 쉽게 이해할 수 있는 새로운 엄격 모드를 선택할 수 있습니다.

일반적이고 엄격하지 않은 JavaScript 모드를 **느슨한 모드** 라고도 합니다. 이것은 공식적인 명칭은 아니지만, 중요한 JavaScript 코드를 작성하는 데 시간을 투자한다면 이 이름을 접하게 될 가능성이 높습니다.

같이 보기
-----

* Speaking JavaScript 책, 7번째 부분 ("JavaScript Syntax")에 있는 "엄격 모드".
거짓같은 값
======

**거짓 같은 값**(Falsy, **falsey**로 쓰이기도 함) 값은 Boolean 문맥에서 `false`로 평가되는 값입니다.

JavaScript는 조건절, 반복문 등 불리언 값이 필요한 곳에서 형 변환을 이용해 특정 값을 불리언 값으로 변환합니다.

다음은 JavaScript의 거짓 같은 값들입니다:

| 값 | 타입 | 설명 |
| --- | --- | --- |
| null | Null | `null` 키워드는 아무런 값도 없음을 의미합니다. |
| undefined | Undefined | `undefined`는 원시값을 의미합니다. |
| `false` | Boolean | `false` (en-US) 키워드. |
| NaN | Number | `NaN`은 숫자가 아님을 의미합니다. |
| `0` | Number | The `Number` 0, `0.0`, `0x0` 등도 포함합니다. |
| `-0` | Number | The `Number` 음수 0, `-0.0`, `-0x0` 등도 포함합니다. |
| `0n` | BigInt | The `BigInt` 0, `0x0n` 등도 포함합니다. Note that there is no `BigInt`에 음수 0가 없다는 것에 주목하세요. `0n`의 음수 0은 `0n`입니다. |
| `""` | String | 비어있는 string 값, also `''` 및 ````도 포함합니다.. |
| `document.all` | Object | JavaScript의 유일한 거짓같은 객체는 내장 `document.all`입니다. |

`null` 및 `undefined` 값은 또한 nullish입니다..

예제
--

다음은 거짓 같은 값의 예시입니다. 거짓 같은 값은 불리언 문맥에서 false로 변환되므로, 아래의 모든 `if` 블록은 실행되지 않습니다.


```js
if (false) {
  // 도달할 수 없습니다.
}

if (null) {
  // 도달할 수 없습니다.
}

if (undefined) {
  // 도달할 수 없습니다.
}

if (0) {
  // 도달할 수 없습니다.
}

if (-0) {
  // 도달할 수 없습니다.
}

if (0n) {
  // 도달할 수 없습니다.
}

if (NaN) {
  // 도달할 수 없습니다.
}

if ("") {
  // 도달할 수 없습니다.
}
```

### 논리 AND 연산자, &&

첫 번째 객체가 거짓 같은 값이라면, 해당 객체를 반환합니다.


```js
console.log(false && "dog");
// ↪ false

console.log(0 && "dog");
// ↪ 0
```

같이 보기
-----

* 참 같은 값
* 형 변환
* 불리언
* 불리언 변환
웹 성능 (Web performance)
======================

**웹 성능(Web performance)** 은 콘텐츠를 요청한 시점부터 요청한 콘텐츠가 사용자의 브라우저에 표시될 때까지의 객관적인 시간, 객관적인 렌더링 시간, 로드 시간 및 런타임에 대한 주관적인 사용자 경험입니다.

객관적으로, 웹 페이지나 웹 애플리케이션이 다운로드되고, 사용자의 웹 브라우저에 표시되고, 반응형 및 상호작용을 할 수 있게 되는 데 걸리는 측정 가능한 시간(밀리초)입니다. 이것은 초당 프레임 수이며, 사용자 상호 작용에 메인 스레드를 사용할 수 없는 시간입니다. 주관적으로, 사용자가 콘텐츠를 요청한 시점과 사용자가 요청한 콘텐츠가 사용 가능하고 그렇게 느낄 때까지 걸리는 시간이 느리거나, 빠르다고 '느끼는지' 여부에 대한 사용자의 인식입니다.

같이 보기
-----

* 웹 성능 배우기
* 인지 성능
실시간 스트리밍 프로토콜 (Real-time streaming protocol, RTSP)
==================================================

실시간 스트리밍 프로토콜 (Real-time streaming protocol, RTSP)은 서버와 클라이언트 사이에서 미디어 스트리밍이 발생하는 방식을 제어하는 네트워크 프로토콜입니다. 기본적으로, RTSP는 비디오를 스트리밍할 때 '일시 중지'/'재생'을 클릭하면 어떤 일이 발생하는지 설명하는 프로토콜입니다. 컴퓨터가 리모콘이고 스트리밍 서버가 텔레비전이라고 비유하면, RTSP는 리모콘 명령이 TV에 어떤 영향을 미치는지 설명합니다.

같이 보기
-----

* 위키백과의 RTSP
* RFC 7826 (프로토콜의 작동 방식을 정확하게 표시한 문서 중 하나)
* 용어사전
    + RTSP
Database
========

**데이터베이스** 는 검색, 구조화 및 확장과 같은 일부 작업을 더 쉽게 수행할 수 있도록 조직된 데이터를 수집하는 저장 시스템입니다.

웹 개발에서, 대부분의 데이터베이스는 데이터를 조직하기 위해 관계형 데이터베이스 관리 시스템(RDBMS)을 사용하며 SQL으로 프로그래밍합니다. 그러나, NoSQL이라 불리는 일부 데이터베이스는 데이터를 조직하기 위해 앞서 설명한 매커니즘을 따르지 않습니다.

유명한 서버측 RDBMS로는 MySQL(또는 MySQL을 포크한 MariaDB), SQL Server, Oracle Database가 있습니다. 반면에 유명한 NoSQL의 예로는 MongoDB, Cassandra, Redis 등이 있습니다.

브라우저에는 IndexedDB라는 자체 데이터베이스 시스템도 있습니다.

같이 보기
-----

* 위키피디아의 Database
* 용어사전
    + IndexedDB
    + SQL
FTU
===

최초 사용 시간 (First Time Use, FTU)은 Firefox 운영체제가 있는 기기에 Gecko 버전을 실행할 때 로드가 되는 애플리케이션입니다.

FTU를 사용하여 여러 가지 중요한 옵션(예, 시간대, Wi-Fi 세부 정보, 기본 언어, 연락처 가져오기)을 설정하거나 '전화 둘러보기'를 통해 장치에 대해 자세히 알아볼 수 있습니다.
분산 서비스 거부 (Distributed Denial of Service, DDoS)
===============================================

분산 서비스 거부(Distributed Denial of Service, DDoS)는 서버 리소스를 마비시키고 합법적인 사용자를 차단하기 위해, 손상된 다수의 시스템이 단일 대상을 공격하도록 만드는 공격입니다.

일반적으로 많은 사람들이 다수의 봇을 사용해 은행이나 신용 카드 결제 게이트웨이와 같은 유명 웹 서버를 공격합니다. DDoS는 컴퓨터 네트워크 및 CPU 리소스 관리와 관련이 있습니다.

일반적인 DDoS 공격에서, 공격자는 하나의 컴퓨터 시스템의 취약점을 악용하고 이 컴퓨터를 DDoS 마스터로 만드는 것부터 시작합니다. 봇마스터라고 알려지는 공격 마스터는 다른 취약한 시스템을 식별하고 맬웨어로 감염시킵니다. 결국 공격자는 제어되는 기계에 지정된 대상에 공격하도록 지시합니다.

DDoS 공격에는 두 가지 유형이 있습니다. 네트워크 중심 공격(대역폭을 사용하여 서비스에 과부하) 및 애플리케이션 계층 공격(애플리케이션 호출로 서비스 또는 데이터베이스에 과부하)이 있습니다. 대상에 대한 데이터 오버플로로 인해 대상 시스템이 포화되어 합법적인 트래픽에 응답할 수 없거나 매우 느리게 응답합니다(따라서 '서비스 거부'라는 이름이 붙었습니다). 감염된 컴퓨터의 소유자는 일반적으로 자신의 컴퓨터가 손상되었다는 사실을 알지 못하고, 서비스 손실도 겪게 됩니다.

침입자의 통제를 받는 컴퓨터를 좀비 또는 봇이라고 합니다. 공동 감염된 컴퓨터의 네트워크는 봇넷 또는 좀비 군대로 알려져 있습니다. Kaspersky Labs과 Symantec은 스팸, 바이러스, 웜이 아닌 봇넷을 인터넷 보안에 대한 가장 큰 위협으로 식별했습니다.

미국 컴퓨터 비상 준비팀(US-CERT)은 서비스 거부 공격의 증상을 다음과 같이 정의합니다.

* 비정상적으로 느린 네트워크 성능(파일 열기 또는 웹 사이트 접근)
* 특정 웹사이트를 이용할 수 없음
* 어떤 웹사이트에도 접속할 수 없음
* 스팸 이메일 수신량이 급격히 증가함(이러한 유형의 DoS 공격은 이메일 폭탄으로 간주됨)
* 무선 또는 유선 인터넷 연결 끊김
* 웹이나 인터넷 서비스에 대한 장기간의 접근 거부
같이 보기
-----

* 위키백과의 서비스 거부 공격
스태킹 컨텍스트 (Stacking context)
===========================

**스태킹 컨텍스트 (Stacking context)** 는 마치 책상 위의 카드를 옆으로 늘어놓거나 서로 겹치게 만들 수 있듯, 웹 페이지에서 어떤 요소가 위에 그려지는지 결정하는 방법입니다.

같이 보기
-----

* stacking context에 대한 설명과 예제
Digital certificate
===================

디지털 인증서는 공개적으로 알려진 암호화 키를 조직에 바인딩하는 데이터 파일입니다.

디지털 인증서에는 일반 이름(예, mozilla.org)과 같은 조직(e.g., Mozilla 회사) 또한 위치(Mountain View)에 대한 정보가 포함되어 있습니다.

디지털 인증서는 가장 일반적으로 인증 기관에 의해 서명되어 인증서의 신뢰성을 증명합니다.

같이 보기
-----

* 위키백과의 디지털 인증서
리소스 타이밍 (Resource Timing)
=========================

성능 문제를 진단하려면 리소스 단위의 성능 데이터가 필요합니다. 리소스 타이밍 API (en-US)는 페이지가 로드될 때 가져오는 각 개별 리소스에 대한 타이밍 정보를 캡처할 수 있는 JavaScript API입니다.

같이 보기
-----

* 리소스 타이밍 API 사용하기 (en-US)
* 서버 타이밍(Server Timing)
불리언
===

컴퓨터 과학에서 **불리언(boolean)** 은 논리적인 데이터 유형입니다. 불리언은 `참(true)` 혹은 `거짓(false)` 값 만을 가질 수 있습니다.

Javascript에서 불리언 조건은 어떤 코드 부문이 실행되어야 할 지(예를 들어 if 절 안에서) 또는 어떤 코드 부문을 반복해야 할지(예를 들어 for 문 안에서) 결정하는 데 사용합니다.

아래는 불리언이 쓰일 수 있는 예시를 보여주는 유사코드입니다(실행 가능한 코드는 아닙니다).


```js
/\* JavaScript if문 \*/
if (boolean conditional) {
  // 조건이 참일 경우 실행되는 코드
}
if (boolean conditional) {
  console.log("boolean conditional resolved to true");
} else {
  console.log("boolean conditional resolved to false");
}
/\* JavaScript for 루프 \*/
for (control variable; boolean conditional; counter) {
  // 조건이 참일 경우 반복해서 실행할 코드
}
```


불리언이란 이름은 기호 논리학 분야의 선구자인 영국 수학자 조지 불의 이름을 따왔습니다.

여기까지 일반적인 소개였습니다. The term **불리언**이라는 용어는 문맥에 따라 더 구체적인 의미를 가질 수 있습니다. 다음을 읽어보세요.

Boolean (JavaScript)
JavaScript에서의 **불리언**은 `true` 또는 `false`일 수 있는 Primitive입니다.
Boolean attribute (ARIA)
ARIA의 **불리언 속성**은 열거 목록에 `true` 또는 `false`를 포함하는 Enumerated입니다.
Boolean attribute (HTML)
HTML의 **불리언 속성** 은 `true` 또는 `false`일 수 있는 속성입니다.
### 같이 보기

* 위키피디아의 불리언 자료형
구문분석 (Parse)
============

구문분석(Parsing)이란 프로그램을 분석하고 런타임 환경이 실제로 실행할 수 있는 내부 형식(예, 브라우저 내부의 JavaScript 엔진)으로 변환하는 것을 의미합니다.

브라우저는 HTML을 구문분석 하는 것을 통해 DOM 트리로 만듭니다. HTML 구문분석에는 토큰화 (en-US) 및 트리 구성이 포함됩니다. HTML 토큰에는 시작 태그와 끝 태그는 물론 속성 이름과 값도 포함됩니다. 문서의 형식이 올바른 경우, 구문 분석이 간단하고 빠릅니다. 구문분석기는 토큰화된 입력을 문서로 구문 분석하여 트리를 구축합니다.

HTML 구문분석기가 이미지와 같은 논블록킹 리소스를 찾으면, 브라우저는 해당 리소스를 요청하고 구문분석을 계속합니다. CSS 파일이 발견되면 구문분석을 계속할 수 있지만, 특히 `async` 또는 `defer` 속성이 없는 `<script>` 태그의 경우에는 렌더링을 차단하고 HTML 구문 분석을 일시 중지합니다.

브라우저가 CSS 스타일을 발견하면, 텍스트를 CSS 객체 모델(CSSOM)로 구문 분석합니다. CSS 객체 모델 데이터 구조는 레이아웃 스타일 지정 및 페인팅에 사용됩니다. 그런 다음 브라우저는 콘텐츠를 화면에 그릴 수 있도록 두 구조 모두에서 렌더링 트리를 생성합니다. JavaScript도 다운로드 되어 구문 분석된 후 실행됩니다.

JavaScript 구문 분석은 컴파일 타임 동안, 또는 메소드 호출 중인 경우와 같이 구문분석기가 호출될 때마다 수행됩니다.

같이 보기
-----

* 위키백과의 Parse
UTF-8
=====

UTF-8(UCS Transformation Format 8)은 월드 와이드 웹의 가장 일반적인 문자 인코딩입니다. 각 문자는 1~4바이트로 표시됩니다. UTF-8은 ASCII와 역호환되며 표준 유니코드 문자를 나타낼 수 있습니다.

처음 128개의 UTF-8 문자는 처음 128개의 ASCII 문자(숫자 0-127)와 정확히 일치하며, 이는 기존 ASCII 텍스트가 이미 유효한 UTF-8임을 의미합니다. 다른 모든 문자는 2~4바이트를 사용합니다. 각각의 바이트는 인코딩 목적으로 남겨진 비트가 있습니다. 비 ASCII 문자가 저장을 위해 1 바이트 이상을 요구하기 때문에, 바이트가 분리되고 재결합되지 않은 상태로 실행하면 손상될 위험이 있습니다.

같이 보기
-----

* 위키백과의 UTF-8
* 유니코드 웹사이트의 UTF-8에 대한 FAQ
도메인 샤딩 (Domain sharding)
========================

브라우저는 각 도메인의 활성 연결 수를 제한합니다. 해당 제한을 초과하는 리소스를 동시에 다운로드할 수 있도록 \*\*도메인 샤딩(Domain sharding)\*\*은 콘텐츠를 여러 하위 도메인으로 분할합니다. 여러 도메인을 사용하여 여러 리소스를 제공하는 경우, 브라우저는 더 많은 리소스를 동시에 다운로드할 수 있으므로, 페이지 로드 시간이 빨라지고 사용자 경험이 향상됩니다.

성능 측면에서, 도메인 샤딩의 문제는 각 도메인에 대한 추가 DNS 조회 비용과 각 TCP 연결 설정에 따른 오버헤드입니다.

HTTP 요청의 초기 응답은 일반적으로 다운로드 해야 하는 JavaScript, CSS, 이미지 및 기타 미디어 파일과 같은 기타 리소스를 나열하는 HTML 파일입니다. 브라우저는 도메인 당 활성 연결 수를 제한하므로, 리소스를 순차적으로 다운로드해야 해서 단일 도메인에서 필요한 모든 리소스를 제공하는 데 속도가 느려질 수 있습니다. 도메인 샤딩을 사용하면 필요한 다운로드가 둘 이상의 도메인에서 제공되므로, 브라우저가 필요한 리소스를 동시에 다운로드할 수 있습니다. 그러나, 다중 도메인은 DNS 조회로 인해 초기 로드 시간이 느려지므로, 안티패턴입니다.

HTTP2는 무제한 동시 요청을 지원하므로 HTTP/2가 활성화되면 도메인 샤딩이 더 이상 필요하지 않게 됩니다.

같이 보기
-----

* TLS
* DNS
* HTTP/2
GZip 압축 (GZip compression)
==========================

gzip은 파일 압축 및 압축 해제에 사용되는 파일 형식입니다. 파일 크기를 더 작게 만들어 더 빠른 네트워크 전송을 가능하게 하는 Deflate 알고리즘을 기반으로 합니다. gzip은 일반적으로 웹 서버와 최신 브라우저에서 지원됩니다. 즉, 서버는 파일을 보내기 전에 자동으로 gzip으로 압축할 수 있고, 브라우저는 파일을 받으면 압축을 풀 수 있습니다.

같이 보기
-----

* gzip 홈페이지
* 위키백과의 gzip
유효 연결 타입 (Effective connection type)
====================================

\*\*유효 연결 타입 (Effective connection type, ECT)\*\*은 실제 연결이 광대역이나 Wi-Fi 테더링이더라도, 브라우저가 페이지를 요청하는 시간과 유효 연결 타입 사이의 시간을 기준으로 3G와 같은 셀룰러 연결 타입을 반환하는, 측정된 네트워크 성능을 나타냅니다.

'`slow-2g`', '`2g`', '`3g`'과 '`4g`' 값은 관찰되는 왕복 시간과 다운링크 값을 사용하여 결정됩니다.

| 유효 연결 타입 | 최소 왕복 시간 | 최대 다운링크 | 설명 |
| --- | --- | --- | --- |
| `slow-2g` | 2000ms | 50 Kbps | 이 네트워크는 텍스트 전용 페이지와 같은 소규모 전송에만 적합합니다. |
| `2g` | 1400ms | 70 Kbps | 이 네트워크는 작은 이미지 전송에 적합합니다. |
| `3g` | 270ms | 700 Kbps | 이 네트워크는 고해상도 이미지, 오디오, SD 비디오 등 대용량 리소스를 전송하는 데 적합합니다. |
| `4g` | 0ms | ∞ | 이 네트워크는 HD 비디오, 실시간 비디오 등에 적합합니다. |

유효타입 (en-US)은 네트워크 정보 API의 속성으로, navigator.connection 객체를 통해 JavaScript에 노출됩니다. 유효 연결 타입을 보려면, 지원 브라우저의 개발자 도구 콘솔을 열고 다음을 입력하세요.


```js
navigator.connection.effectiveType;
```

같이 보기
-----

* 네트워크 정보 API
* `NetworkInformation` (en-US)
* `NetworkInformation.effectiveType` (en-US)
* `ECT` (en-US)
OTA
===

**무선 펌웨어 업데이트(Over The Air, OTA)** 는 중앙 서버에서 연결된 장치의 소프트웨어를 자동으로 갱신하는 것을 말합니다. 특정 업데이트 모음을 수신하는 모든 장치 소유자는 동일한 '채널'에 있으며, 각 장치는 종종 여러 채널(예, 프로덕션 또는 엔지니어링 빌드)에 접근할 수 있습니다.

같이 보기
-----

* 위키백과의 Over-the-air programming
ASCII
=====

**미국정보교환표준부호**(*American Standard Code for Information Interchange*) 또는 **ASCII**는 문자, 숫자, 구두점, 제어문자를 디지털 형태로 바꾸어주는 대표적인 문자 인코딩 방식입니다. 2007년부터 웹에서는 UTF-8이 주로 쓰이고 있습니다.

같이 보기
-----

Wikipedia의 ASCII
영역 (Gamut)
==========

색상의 \*\*영역 (Gamut)\*\*은 일반적으로 디스플레이나 인쇄 장치가 나타낼 수 있는 색상의 하위 집합입니다.

어떤 디스플레이나 프린터도 인간의 눈이 인지할 수 있는 전체 색상의 범위를 표현할 수 없습니다. 장치 'gamut'는 색상의 범위를 지원하는 세트를 나타냅니다.

전통적으로, 웹 개발에서, 사용되는 유일한 색영역은 '표준 빨강-녹색-파랑(Standard Red-Green-Blue, sRGB)'였습니다. sRGB의 각 기본 색상에 대해서 3바이트를 사용합니다. 그러나, '와이드 컬러(wide-color)' 모니터와 전문 프린터는 이 범위를 사용하여 표현할 수 없는 더 넓은 범위의 색상을 지원합니다.

2021년부터, 브라우저는 영화 산업에서 널리 사용되는 P3 및 rec2020와 같은 다른 영역에 대한 기능을 제공하기 시작했습니다.

개발자는 `color-gamut` (en-US) 미디어 기능을 사용하여 더 넓은 영역을 지원하는 장치에 대해서 다양한 색상 세트를 정의할 수 있습니다. LCH 원통형 좌표계에 대해 `lch()` (en-US) 또는 Lab 좌표계에 대해 `lab()` (en-US)과 같은 특정 CSS 함수를 사용하여 RGB 영역 외부의 색상을 설명할 수 있습니다.

같이 보기
-----

* 위키백과의 Gamut
미들웨어 (Middleware)
=================

미들웨어는 시스템의 일부가 데이터를 통신하고 관리할 수 있도록 하는 모든 소프트웨어 또는 서비스에 대한 (느슨하게 정의된) 용어입니다. 컴포넌트와 입력/출력 간의 통신을 담당하는 소프트웨어이므로, 개발자는 애플리케이션의 특정 목적에 집중할 수 있습니다.

서버 사이드 웹 애플리케이션 프레임워크에서, 미들웨어라는 용어는 데이터베이스 접근과 같은 작업을 처리하기 위해 프레임워크의 요청 및 응답 처리를 하고, 파이프라인에 추가할 수 미리 구축되어 있는 소프트웨어 컴포넌트를 가리키는 데 더 구체적으로 사용되는 경우가 대부분입니다.

같이 보기
-----

* 위키백과의 미들웨어(분리된 애플리케이션)
* 위키백과의 미들웨어
연속적인 미디어 (Continuous Media)
===========================

연속 미디어(Continuous media)란 소스와 대상(destination) 사이에 시간적인 관계가 있는 데이터를 의미합니다. 연속적인 미디어의 가장 일반적인 예로는 오디오와 모션 비디오가 있습니다. 연속적인 미디어는 소스와 대상(sink) 사이에 "엄격한" 시간적인 관계가 있는 실시간(대화형)이거나, 관계가 덜 엄격한 스트리밍(재생)일 수 있습니다.

CSS는 인쇄 매체를 포함한 다양한 상황에서 사용될 수 있습니다. 그리고 일부 CSS, 특히 레이아웃에 사용되는 CSS는 컨텍스트에 따라 다르게 동작합니다.

따라서 연속적인 미디어는 콘텐츠가 분리되지 않은 컨텍스트를 식별합니다. 연속적인 미디어는 끊임없이 재생될 수 있습니다. 화면에 표시되는 웹 콘텐츠는 음성 콘텐츠와 마찬가지로 연속적인 미디어입니다.
멱등성
===

동일한 요청을 한 번 보내는 것과 여러 번 연속으로 보내는 것이 같은 효과를 지니고, 서버의 상태도 동일하게 남을 때, 해당 HTTP 메서드가 **멱등성**을 가졌다고 말합니다.

다른 말로는, 멱등성 메서드에는 통계기록 등을 제외하면 어떠한 부수효과(side effect)도 존재해서는 안됩니다. 예를 들어, 서버는 모든 요청을 받은 시간과 함께 기록할 수 있습니다. 멱등성(Idempotency)는 클라이언트가 의도한 효과에만 적용됩니다. 예를 들어, POST 요청은 데이터를 서버로 보내려고 하거나, DELETE 요청은 서버에서 리소스를 삭제하려고 합니다.

safe 메서드는 `PUT` and `DELETE`와 마찬가지로 멱등적입니다. `POST` 메서드는 멱등성이 아닙니다.

멱등성을 따질 땐 실제 서버의 백엔드 상태만 보면 되며, 각 요청에서 반환하는 응답 코드는 다를 수 있습니다. 첫 번째 `DELETE` 요청이 `200`을 반환한다면, 그 이후는 아마 `404`를 반환할 것입니다. `DELETE`가 멱등성을 가진다는 것은, REST API에서 개발자는 `DELETE` 메서드를 사용해 "목록의 마지막 항목 제거" 기능을 구현해서는 안 된다는 것입니다.

다만, 서버는 메서드의 멱등성을 보장하지 않으며, 일부 애플리케이션은 잘못된 구현으로 멱등성 제약을 어길 수도 있습니다.

`GET /pageX HTTP/1.1`는 안전한(읽기 전용) 메서드이기 때문에 멱등성을 가집니다. 그 동안 서버의 데이터가 업데이트된 경우, 다음에 하는 호출은 클라이언트에 다른 데이터를 반환할 수 있습니다.

`POST /add_row HTTP/1.1`은 멱등성을 가지지 않습니다. 여러 번 호출되면 여러 행을 추가합니다.


```http
POST /add\_row HTTP/1.1
POST /add\_row HTTP/1.1   -> Adds a 2nd row
POST /add\_row HTTP/1.1   -> Adds a 3rd row
```


`DELETE /idX/delete HTTP/1.1`의 상태 코드는 응답마다 달라질 수 있지만, 그럼에도 멱등성을 가집니다.


```http
DELETE /idX/delete HTTP/1.1   -> Returns 200 if idX exists
DELETE /idX/delete HTTP/1.1   -> Returns 404 as it just got deleted
DELETE /idX/delete HTTP/1.1   -> Returns 404
```

같이 보기
-----

* HTTP 명세의 멱등성 정의
* 멱등성 메서드 문서: `GET`, `HEAD`, `PUT`, `DELETE`, `OPTIONS`, `TRACE` (en-US)
* 비 멱등성 메서드 문서: `POST`,`PATCH`, `CONNECT`
해시 기반 메시지 인증 코드 (HMAC)
======================

\*\*해시 기반 메시지 인증 코드(Hash-based message authentication code, HMAC)\*\*는 암호학적인 메시지 인증에 사용되는 프로토콜입니다.

모든 종류의 암호화 함수를 사용할 수 있고, 그 강도는 기본 기능(예, SHA1 또는 MD5)과 선택한 비밀 키에 따라 다릅니다. 이러한 조합을 통해 HMAC 검증 알고리즘은 HMAC-SHA1과 같은 복합 이름으로 알려져 있습니다.

HMAC는 무결성과 인증을 모두 보장하는 데 사용됩니다.

같이 보기
-----

* HMAC on Wikipedia
* IETF의 RFC 2104
탐색 지시문 (Navigation directive)
=============================

**CSP 탐색 지시문 (Navigation directive)** 는 `Content-Security-Policy` (en-US) 헤더에 사용되며, 예를 들어 사용자가 탐색하거나 양식을 제출할 수 있는 위치를 제어합니다.

탐색 지시문은 `default-src` 지시문으로 대체되지 않습니다.

전체 목록은 탐색 지시문 (en-US)을 참조하세요.

같이 보기
-----

* https://www.w3.org/TR/CSP/#directives-navigation
* 다른 종류의 지시문:
    + Fetch directive
    + Document directive
    + Reporting directive
    + `block-all-mixed-content` (en-US)
    + `upgrade-insecure-requests` (en-US)
    + `trusted-types` (en-US)
* `Content-Security-Policy` (en-US)
WebRTC
======

**WebRTC** ('Web Real-Time Communication') API는 영상 채팅, 음성 통화, 그리고 P2P 파일 공유 웹 어플리케이션에서 사용할 수 있습니다.

WebRTC 의 3가지 주요 부분.

`getUserMedia()` (en-US)

기기의 카메라와 마이크를 같이 혹은 개별로 접속권한을 부여받으며, RTC connection에 신호를 연결할 수 있습니다.

`RTCPeerConnection` (en-US)

비디오 채팅 또는 음성 통화를 구성하기 위한 인터페이스입니다.

`RTCDataChannel` (en-US)

브라우저간에 peer-to-peer (en-US) 데이터 경로 설정방법을 제공합니다.

같이 보기
-----

* 위키백과의 WebRTC
* MDN의 WebRTC 자습서
* WebRTC 브라우저 지원
Lazy load
=========

\*\*Lazy Loading(지연 로딩)\*\*은 사용자의 행동이나 탐색 패턴에 기반해 사용자가 필요할 때 일부 자원(이미지 같은)을 지연해서 로드하는 전략입니다. 통상적으로 이 자원들은 스크롤하여 화면에 보여질 때 로드됩니다.

제대로 구현된 경우에는 자원 지연 로딩은 사용자에게 끊김이 없다는 느낌, 페이지가 움직이기 시작할 때까지 필요한 자원 감소, 대화형이 가능한 시간 등 초기 로드 성능 향상에 도움이 됩니다.

같이 보기
-----

* Lazy loading
NAT용 세션 탐색 유틸리티 (Session Traversal Utilities for NAT, STUN)
===========================================================

**NAT용 세션 탐색 유틸리티 (Session Traversal Utilities for NAT, STUN)** 는 네트워크 주소 변환 (Network Address Translator, NAT) 주변에서 데이터를 전송하기 위한 보조 프로토콜입니다. STUN은 IP 주소, 포트 및 NAT 뒤에 네트워크 컴퓨터의 연결 상태를 반환합니다.

같이 보기
-----

* 위키백과의 STUN
* WebRTC 프로토콜
### 기술적 참고서

* 명세서
깃 (Git)
=======

\*\*깃(Git)\*\*은 무료 오픈소스 분산 소스 코드 관리(SCM) 시스템입니다. 분산되어 있는 개발 팀이 코드 베이스를 쉽게 처리할 수 있습니다. 이전 SCM 시스템과 차별화되는 점은 마스터 레포지토리를 변경하거나 쓰기 권한이 없어도, 로컬 개발 시스템에서 일반적인 작업(분기, 커밋 등)을 수행할 수 있다는 것입니다.

같이 보기
-----

* 문서가 포함된 공식 웹사이트
* Git 기반 그래픽 프로젝트 호스팅인 깃헙(GitHub)
Forbidden response header name
==============================

**금지된 응답 헤더 이름**은 프로그래밍 방식으로 수정할 수 없는 HTTP 헤더의 이름(`Set-Cookie`)입니다.

같이 보기
-----

* Fetch 명세서: 금지된 응답 헤더 이름
* 금지된 헤더 이름 (용어 사전)
ICE
===

\*\*대화형 연결 구축 (Interactive Connectivity Establishment, ICE)\*\*은 네트워크 토폴로지에 관계없이(일반적으로 오디오 및 비디오 채탱용) 두 피어를 연결하기 위해 (다른 기술 중에서) WebRTC에서 사용하는 프레임워크입니다. 이 프로토콜을 사용하면 두 피어가 모두 네트워크 주소 변환 (Network Address Translator, NAT)를 사용하여 해당 로컬 네트워크의 다른 장치와 글로벌 IP 주소를 공유하는 경우에도 서로 연결을 찾고 설정할 수 있습니다.

ICE 프레임워크 알고리즘은 두 피어를 연결하기 위해 지연 시간이 가장 짧은 경로를 찾고, 아래 옵션을 순서대로 시도합니다.

1. 직접 UDP 연결 (이 경우에만 STUN 서버는 피어의 네트워크 연결 주소를 찾는 데 사용됩니다)
2. HTTP 포트를 통한 직접 TCP 연결
3. HTTPS 포트를 통한 직접 TCP 연결
4. relay/TURN 서버를 통한 간접 연결 (직접 연결이 실패한 경우. 예를 들어, 한 피어가 NAT 통과를 차단하는 방화벽 뒤에 있는 경우)
같이 보기
-----

* ICE를 사용하는 주요 웹 관련 프로토콜인 WebRTC
* WebRTC 프로토콜
* ICE에 대한 IETF 명세서인 RFC 8445
* ICE 후보를 나타내는 인터페이스인 `RTCIceCandidate`
깊은 복사
=====

객체의 **깊은 복사**는 복사본의 속성이 복사본이 만들어진 원본 객체와 같은 참조(메모리 내의 같은 값을 가리킴)를 공유하지 않는 복사입니다. 따라서 원본이나 복사본을 변경할 때, 다른 객체가 변경되지 않는 것을 보장할 수 있습니다. 이러한 동작은 원본이나 복사본의 중첩된 속성을 변경하면 다른 객체도 변경될 수 있는 얕은 복사의 동작과 대조적입니다.

두 객체 `o1`과 `o2`는 관찰된 동작이 같다면 구조적으로 동일합니다. 이러한 동작에는 다음이 포함됩니다.

1. `o1`과 `o2`의 속성은 같은 이름과 순서입니다.
2. 두 객체의 속성 값은 구조적으로 동일합니다.
3. 두 객체의 프로토타입 체인은 구조적으로 동일합니다 (구조적으로 동일하다는 것은 이러한 객체는 보통 일반 객체이므로 둘 다 `Object.prototype`에서 상속된다는 것을 의미합니다).

구조적으로 동일한 객체는 같은 객체 (`o1 === o2`) 또는 복사본 (`o1 !== o2`)일 수 있습니다. 동일한 원시 값은 항상 동일하게 비교하기 때문에 복사본을 만들 수 없습니다.

이제 깊은 복사를 다음과 같이 보다 공식적으로 정의할 수 있습니다.

1. 두 객체는 같은 객체가 아닙니다 (`o1 !== o2`).
2. `o1`과 `o2`의 속성은 같은 이름과 순서입니다.
3. 두 객체의 속성 값은 서로의 깊은 복사 값입니다.
4. 두 객체의 프로토타입 체인은 구조적으로 동일합니다.

깊은 복사는 프로토타입 체인을 복사할 수도 있고 복사하지 않을 수도 있습니다 (그리고 자주 복사하지 않습니다). 그러나 구조적으로 동일하지 않은 프로토타입 체인을 가진 두 객체(예로, 하나는 배열이고 다른 하나는 일반 객체)는 서로의 복사본이 아닙니다.

속성이 모두 원시 값인 객체의 복사는 깊은 복사와 얕은 복사의 정의에 모두 부합합니다. 그렇지만 중첩된 속성이 없기 때문에 이런 복사의 깊이에 대해 이야기하는 것은 다소 쓸모가 없습니다. 보통 중첩된 속성을 변경하는 맥락에서 깊은 복사하는 것에 대해 이야기합니다.

JavaScript에서, 모든 표준 내장 객체의 복사 작업(전개 구문, `Array.prototype.concat()`, `Array.prototype.slice()`, `Array.from()`, `Object.assign()`, `Object.create()`)은 깊은 복사본을 생성하지 않습니다 (대신, 얕은 복사본을 생성합니다).

직렬화가 가능하다면 JavaScript 객체의 깊은 복사를 만드는 한 가지 방법은, `JSON.stringify()`를 사용하여 객체를 JSON 문자열로 변환한 다음, `JSON.parse()`로 문자열을 다시 (완전히 새로운) JavaScript 객체로 변환하는 것입니다.


```js
const ingredientsList = ["noodles", { list: ["eggs", "flour", "water"] }];
const ingredientsListDeepCopy = JSON.parse(JSON.stringify(ingredientsList));
```


깊은 복사는 원본 객체와 참조를 공유하지 않기 때문에 깊은 복사본에 어떠한 변경이 있어도 원본 객체에 영향을 주지 않습니다.


```js
// ingredientsListDeepCopy의 'list' 속성 값을 변경합니다.
ingredientsListDeepCopy[1].list = ["rice flour", "water"];
// ingredientsList의 'list' 속성은 변경되지 않습니다.
console.log(ingredientsList[1].list);
// Array(3) [ "eggs", "flour", "water" ]
```


그러나 위 코드의 객체는 직렬화할 수 있을 만큼 단순하지만, 많은 JavaScript 객체는 전혀 직렬화할 수 없습니다. 예를 들어, 함수 (클로저 포함), 심볼, HTML DOM API에서 HTML 요소를 나타내는 객체, 재귀 데이터, 그리고 많은 다른 경우가 있습니다. 이 경우 객체를 직렬화하기 위해 `JSON.stringify()`를 호출하면 실패할 것입니다. 그래서 이러한 객체의 깊은 복사본을 만드는 방법은 없습니다.

Web API `structuredClone()`은 또한 깊은 복사본을 만들고 원본에서 전송가능한 객체 (en-US)를 복사하는 대신 새로운 복사본으로 전송할 수 있는 장점이 있습니다. 또한 `Error`와 같은 더 많은 데이터 타입을 처리합니다. 그러나 `structuredClone()`은 JavaScript 언어 자체의 기능이 아니라 web API를 실행하는 브라우저 및 다른 JavaScript 호스트의 기능입니다. 그리고 직렬화할 수 없는 객체를 복제하기 위해 `structuredClone()`을 호출하면, `JSON.stringify()`를 호출해 직렬화하는 것과 같은 방식으로 실패할 것입니다.

같이 보기
-----

* 얕은 복사
* `window.structuredClone()`
복호화 (Decryption)
================

암호학에서, **복호화**는 암호문을 평문으로 변환하는 것입니다.

 복호화는 암호화의 기본 요소입니다. 암호라는 암호화 알고리즘을 사용하여 암호문 메시지를 일반 텍스트로 변환합니다.
 암호화와 마찬가지로, 최신 암호의 복호화는 특정 알고리즘과 키라는 비밀을 사용하여 수행됩니다. 알고리즘은 공개되는 경우가 많아, 암호화가 안전하게 유지된다면 키는 비밀로 유지되어야 합니다.

![복호화 기본 요소입니다](/ko/docs/Glossary/Decryption/decryption.png)

복호화는 encryption의 반대이며 키가 비밀로 유지되는 경우, 특정 비밀을 알지 못한 채 복호화하는 것은 수학적으로 수행하기 어렵습니다. 얼마나 어려운지는 선택한 암호화 알고리즘의 보안에 따라 달라지고 암호화 분석의 진행과 함께 발전합니다.

같이 보기
-----

* 암호화와 복호화
국제화 (internationalization, I18N)
================================

국제화 (i18n ("internationalization" 부터 유래, 20자로 이루어진 단어))는 제품이나 서비스를 모든 대상 문화에 쉽게 적용할 수 있도록 하는 모범 사례입니다.

> 
> **국제화(Internationalization)**는 문화, 지역, 언어가 다양한 대상 고객을 위해 쉽게 현지화**할 수 있는** 제품, 애플리케이션 또는 문서 콘텐츠를 설계하고 개발하는 것입니다(W3C 정의에 따름).
> 
> 
> 

무엇보다도 국제화(i18n)에는 여러 가지 지원이 필요합니다.

* 문자 모음 (일반적으로 유니코드를 통함)
* 측정 단위 (통화, °C/°F, km/miles 등)
* 시간 및 날짜 형식
* 키보드 레이아웃
* 텍스트 방향
같이 보기
-----

* 위키백과의 i18n
* W3C의 i18n
* i18nguy.com의 i18n 자료
정적 타이핑 (Static typing)
======================

**정적 타입(statically-typed)** 언어는 컴파일 시간에 변수 타입이 알려진 언어(Java, C, or C++ 등) 입니다. 대부분의 언어에서는 프로그래머가 타입을 명시적으로 표시해야 합니다. (OCaml와 같이) 다른 경우에는, 타입 추론을 통해 프로그래머가 변수 타입을 표시하지 않을 수 있습니다.

같이 보기
-----

* 위키백과의 타입 시스템
상태 기계 (State machine)
=====================

상태 기계는 알고리즘을 설계하는 데 사용되는 수학적 추상화 표현입니다. 상태 기계는 일련의 입력을 읽고 해당 입력에 따라 다른 상태로 변경됩니다.

상태는 전환을 실행하는 것을 기다리는 시스템 상태에 대한 설명입니다. 전환은 조건이 충족되거나 이벤트가 수신될 때 실행되는 일련의 작업입니다. 상태 다이어그램에서, 원은 가능한 각 상태를 나타내고 화살표는 상태 간에 전환을 나타냅니다.

최종 상태를 보면, 해당 상태로 이어지는 일련의 입력에 대해 식별할 수 있습니다.

기본 상태 기계에는 두 가지 유형이 있습니다.

결정론적 유한 상태 기계

이 종류는 허용된 입력에 대해 하나의 가능한 전환만 허용합니다. 이는 `if x then doThis else doThat`이 불가능 하다는 "if" 명령문과 같습니다. 컴퓨터는 두 가지 옵션 중 '하나'를 수행해야 합니다.

비결정적 유한 상태 기계

어떤 상태가 주어지면, 입력은 둘 이상의 다른 상태로 이어질 수 있습니다.

'그림 1: 결정론적 유한 상태 머신'

![기계는 입력 X에 대해 상태 1에서 상태 2로 전환하고 입력 Y에 대해 상태 1에서 상태 3으로 전환합니다](/ko/docs/Glossary/State_machine/statemachine1.png)

'그림 1'에서, 상태는 상태 1에서 시작됩니다. 상태는 입력 'X'가 주어지면 상태 2로 변경되거나 입력 'Y'가 주어지면 상태 3으로 변경됩니다.

'그림 2: 비결정적 유한 상태 머신'

![기계는 상태 1에 남아 자체적으로 전환되거나 입력 X에 대해 상태 1에서 상태 2로 전환될 수 있습니다](/ko/docs/Glossary/State_machine/statemachine2.png)

'그림 2'에서, 'X'를 입력하면 상태가 지속되거나 상태 2로 변경될 수 있습니다.

모든 정규 표현식은 상태 기계로 표현될 수 있습니다.

같이 보기
-----

* 위키백과의 유한 상태 기계
* 위키백과의 UML 상태 기계
* 위키백과의 무어 기계
* 위키백과의 밀리 기계
CSP
===

CSP (콘텐츠 보안 정책Content Security Policy)는 XSS (en-US), clickjacking이나 데이터 주입과 같은 특정 웹사이트 관련 공격을 탐지 하거나 완화 하기 위해 사용됩니다.

기본적인 구현은 `Content-Security-Policy` (en-US)라고 불리는 HTTP 헤더를 기반으로 합니다.

같이 보기
-----

* 위키피디아의 콘텐츠 보안 정책
* MDN의 콘텐츠 보안 정책 문서 (en-US)
RAIL
====

**RAIL** 은 **Response, Animation, Idle, and Load** 의 축약어로, 2015년 Google Chrome 팀이 창안한 브라우저 내 사용자 경험과 성능에 중점을 둔 성능 모델입니다. RAIL의 성능의 핵심은 '사용자에게 초점을 맞추세요. 최종 목표는 사이트가 특정 장치에서 빠르게 작동하도록 만드는 것이 아니라 사용자를 행복하게 만드는 것'입니다. 상호 작용에는 페이지 로드, 유휴, 입력에 대한 응답, 스크롤 및 애니메이션의 4단계가 있습니다. 약어순으로 주요 원칙은 아래와 같습니다.

**응답(Response)**

**100ms** 이내에 사용자 입력을 승인하여 즉시 사용자에게 응답합니다.

**애니메이션(Animation)**

애니메이션을 적용할 때, 각 프레임을 **16ms** 미만으로 렌더링하여 일관성을 유지하고 버벅거림을 방지하세요.

**유휴(Idle)**

기본 JavaScript 스레드를 사용하는 경우, **50ms** 미만의 시간 동안 청크로 작업하여 사용자 상호작용을 위한 스레드를 확보합니다.

**로드(Load)**

**1초** 이내에 상호작용 가능한 콘텐츠를 제공합니다.

같이 보기
-----

* 권장 웹 성능 타이밍: 얼마나 길면 너무 길까요 (en-US)