recursal/MDN huggingface dataset:
도메인 (Domain)
============

도메인은 자체 리소스를 제어하는 인터넷 내의 권한입니다. '도메인 네임'은 URL 계층 구조의 일부로 이 권한을 지정하는 방법입니다. 일반적으로, 브랜드 이름처럼 가장 기억에 남는 부분입니다.

정규화된 도메인 이름(Fully Qualified Domain Name, FQDN)에는 인터넷의 DNS 시스템을 사용하여 이름별로 이 권한을 명확하게 검색하는 데 필요한 모든 부분이 포함되어 있습니다.

예를 들어, "developer.mozilla.org"에서,

1. 'org'는 최상위 도메인으로 불려집니다. 최상위 도메인은 IANA에 의해 인터넷 표준으로 등록되어 있습니다. 여기서, 'org'는 최상위 '도메인 레지스트리'에 정의된 '조직'을 의미합니다.
2. 'mozilla'는 도메인입니다. 도메인을 소유하고 싶다면 최상위 도메인 등록 기관에 등록할 수 있는 여러 등록 기관 중 하나에 등록해야 합니다.
3. '개발자'는 '하위 도메인'으로, 도메인 소유자로서 우리가 직접 정의할 수 있습니다. 많은 소유자는 자신의 월드 와이드 웹 리소스를 가리키기 위해 하위 도메인 'www'를 선택하지만, 이 방법은 필수는 아닙니다(다소 선호도도 떨어졌습니다).
같이 보기
-----

* 위키백과의 도메인 네임
호스트 (Host)
==========

호스트는 인터넷 (또는 로컬 네트워크)에 연결된 장치입니다. 서버라는 일부 호스트는 웹페이지 제공, 파일 및 이메일 저장과 같은 추가 서비스를 제공합니다.

호스트는 하드웨어 인스턴스일 필요는 없습니다. 호스트는 가상머신에 의해 생성될 수 있습니다. 가상 머신에 의해 생성된 호스트를 '가상 호스팅'이라고 합니다.

같이 보기
-----

* 위키백과의 호스트
Hyperlink
=========

하이퍼링크는 웹 페이지 또는 데이터 항목을 서로 연결합니다. HTML에서 `<a>`요소는 웹페이지의 한 지점(예: 텍스트 문자열 또는 이미지)에서 다른 웹페이지(또는 동일한 페이지)의 다른 지점으로 연결되는 하이퍼링크를 정의합니다.

같이 보기
-----

* Wikipedia Hyperlink
* MDN 가이드 하이퍼링크
* Links in HTML Documents - W3C
* HTML a - hyperlink - W3C
* `<a>` on MDN
* `<link>` on MDN
Character encoding
==================

인코딩은 바이트와 텍스트 간의 매핑을 정의합니다. 바이트 시퀀스는 다양한 텍스트 해석을 허용합니다. 특정 인코딩(예를 들면 UTF-8 등)을 지정함으로써, 바이트 시퀀스를 해석하는 방법을 지정합니다.

예를 들어, HTML에서 우리는 일반적으로 아래 줄과 같이 UTF-8의 문자 인코딩을 선언합니다.


```html
<meta charset="utf-8" />
```


이 방법은 HTML 문서에서 인간 언어의 문자를 사용할 수 있도록 보장하며, 그것들은 신뢰성 있게 표시될 것입니다.

같이 보기
-----

* Character encoding on W3C
* Wikipedia의 Character encoding
자리 표시자 이름 (Placeholder names)
=============================

자리 표시자 이름(placeholder names)은 "당사자 A(Party A)", "도청자(eavesdropper)" 및 "악의적인 공격자(malicious attacker)"와 같은 용어를 사용하지 않고, 대화 참가자를 나타내기 위해 암호학에서 일반적으로 사용됩니다.

가장 일반적으로 사용되는 이름은 아래와 같습니다.

* *Alice* 및 *Bob*, 서로에게 메시지를 보내고 싶은 두 당사자, 때때로 세 번째 참가자인 *Carol*이 합류합니다.
* *Eve*, *Alice*와 *Bob*의 대화를 도청하는 수동적 공격자
* *Mallory*, 대화를 수정하고 오래된 메시지를 재생할 수 있는 적극적인 공격자(중간자, *man-in-the-middle*)
재전송 공격 (Replay attack)
======================

웹 보안에서, '재전송 공격 (Replay attack)'은 공격자가 이전에 전송된 메시지를 가로채서 나중에 다시 전송하여 원래의 메시지와 동일한 자격 증명을 얻을 때 발생하며, 잠재적으로 다른 페이로드나 명령이 포함되어 있는 메시지를 다시 보내 공격하는 것을 의미합니다.

수신자가 전송의 신뢰성을 확인하는 데 사용 가능한 고유하고 일회성의 식별자를 각 메시지에 포함시키고 있으면 재생 공격을 방지할 수 있습니다. 이 식별자는 세션 토큰 또는 '한 번만 사용되는 숫자(number used only once, nonce)' 형식을 가질 수 있습니다.

같이 보기
-----

* 위키백과의 Replay attack
CDN
===

CDN (Content Delivery Network)는 많은 장소에 걸쳐 분산된 서버들의 그룹입니다. 이러한 서버들은 데이터의 중복 복사본들을 저장하여, 서버가 최종 사용자와 가장 가까운 서버를 기준으로 데이터 요청을 처리할 수 있습니다. CDN은 높은 트래픽에도 영향을 덜 받는 빠른 서비스를 제공할 수 있습니다.

CDN은 Bootstrap, jQuery 같은 라이브러리들의 스타일시트 및 JavaScript 파일(정적 애셋)을 전송하는데 널리 쓰입니다. 라이브러리 파일을 위해 CDN을 사용하는 것이 선호되는 이유는 여러 가지가 있습니다.

* CDN을 통해서 라이브러리의 정적 애셋을 제공하면 라이브러리의 자체 서버에 요청 부담이 줄어듭니다.
* 대부분의 CDN들은 전 세계에 서버를 가지고 있습니다. 따라서 CDN 서버들은 지리학적으로 특정 라이브러리의 서버보다 사용자와 더 가깝습니다. 지리학적 거리는 지연시간에 비례하여 영향을 미칩니다.
* CDN들은 이미 적절한 캐시 설정이 되어있습니다. CDN을 사용하면 자체 서버의 정적 애셋을 위한 추가적인 설정을 하지 않아도 됩니다.
세션 하이재킹 (Session Hijacking)
===========================

**세션 하이재킹 (Session Hijacking)** 은 공격자가 두 컴퓨터 간의 유효한 세션을 장악할 때 발생합니다. 공격자는 시스템에 침입하여 데이터를 스누핑하기 위해 유효한 세션 ID를 훔칩니다.

대부분의 인증은 TCP 세션이 시작될 때만 발생합니다. TCP 세션 하이재킹에서는, 공격자가 세션 중간에 두 시스템 간의 TCP 세션을 장악하여 접근 권한을 획득합니다.

![공격자는 웹 서버와 상호 작용하는 사용자로부터 합법적인 세션 ID를 스니핑하고 접근한 다음, 해당 세션 식별자를 사용하여 일반 사용자와 서버 간의 세션을 스푸핑하여, 사용자의 세션을 익스플로잇(취약점 공격)을 실행하고 서버에 직접 접근합니다](/ko/docs/Glossary/Session_Hijacking/session_hijacking_3.jpg)

### 세션 하이재킹이 발생하는 이유는 아래와 같습니다

* 유효하지 않은 세션 ID에 대한 계정 잠금이 없습니다.
* 취약한 세션 ID 생성 알고리즘
* 안전하지 않은 취급
* 무기한 세션 만료 시간
* 짦은 세션 ID
* 일반 텍스트로 전송
### 세션 하이재킹 과정

1. **스니프(Sniff):** 중간자(man-in-the-middle, MITM) 공격을 수행합니다. 공격받는 컴퓨터와 서버 사이의 자기 자신을 위치시킵니다.
2. **모니터링(Monitor):** 서버와 사용자 사이에 흐르는 패킷을 관찰합니다.
3. **차단(Break):** 공격받는 컴퓨터의 연결을 종료시킵니다.
4. **제어(Take control):** 세션을 제어합니다.
5. **주입(Inject):** 공격받는 컴퓨터의 세션 ID를 사용하여 서버에 새로운 패킷을 주입합니다.
### 세션 하이재킹으로부터의 보호

* 보안 쉘(SSH)을 사용하여 보안 통신 채널을 생성합니다.
* HTTPS 연결을 통해 인증 쿠키를 전달합니다.
* 사용자가 세션을 종료할 수 있도록 로그아웃 기능을 구현합니다.
* 로그인 성공 후 세션 ID를 생성합니다.
* 사용자와 웹 서버 간에 암호화된 데이터를 전달합니다.
* 문자열이나 길이가 긴 난수를 세션 키로 사용합니다.
같이 보기
-----

* 위키백과의 세션 하이재킹
그리드 컨테이너 (Grid container)
=========================

요소에 `grid` 또는 `inline-grid` 값을 사용하면 해당 요소가 CSS 그리드 레이아웃을 사용하여 **그리드 컨테이너**로 변환되고, 바로 밑의 모든 자식 요소도 그리드 요소가 됩니다.

요소가 그리드 컨테이너가 되면 **그리드 서식 지정 컨텍스트**가 설정됩니다. 바로 밑의 자식 요소는 이제 `grid-template-columns` 및 `grid-template-rows` (en-US)를 사용하여 정의된 명시적 그리드 또는 요소가 '명시적 그리드' 외부에 배치될 때 생성된 '암시적 그리드'에 배치될 수 있습니다.

같이 보기
-----

### 속성 참고서

* `grid-template-columns`
* `grid-template-rows` (en-US)
* `grid-auto-columns` (en-US)
* `grid-auto-rows` (en-US)
* `grid` (en-US)
* `grid-template` (en-US)
### 더 읽어보기

* CSS 그리드 레이아웃 안내서: 그리드 레이아웃의 기본 개념
뷰포트
===

컴퓨터 그래픽스에서, 뷰포트(viewport)는 현재 화면에 보여지고 있는 다각형(보통 직사각형)의 영역입니다. 웹 브라우저에서는, 현재 창에서 문서를 볼 수 있는 부분(전체화면이라면 화면 전체)을 말합니다. 뷰포트 바깥의 콘텐츠는 스크롤 하기 전엔 보이지 않습니다.

뷰포트 중에서도 지금 볼 수 있는 부분을 \*\*시각적 뷰포트\*\*라고 부릅니다. 사용자가 두 손가락으로 대상을 확대 및 축소하는 동작과 같은 특정 상황에서, 레이아웃 뷰포트의 크기는 변하지 않지만 시각적 뷰포트는 더 작아집니다.

같이 보기
-----

* 시각적 뷰포트 API (en-US)
* 위키백과 뷰포트 (컴퓨터 과학)
* 두 가지의 뷰포트 이야기 (호환모드)
* MDN 용어 사전의 Visual viewport
* MDN 용어 사전의 Layout viewport
SDP
===

**세션 기술 프로토콜 (Session Description Protocol, SDP)** 은 피어 투 피어(peer-to-peer) (en-US) 연결을 설명하는 표준입니다. SDP에는 오디오 및 비디오의 코덱, 소스 주소, 타이밍 정보가 포함되어 있습니다.

아래는 일반적인 SDP 메시지입니다.
```

v=0
o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVP 31
a=rtpmap:31 H261/90000
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
```


SDP는 단독으로 사용되지 않으며, RTP and RTSP와 같은 프로토콜에 의해 사용됩니다. SDP는 세션을 설명하는 방법으로, SDP를 사용하는 WebRTC의 구성요소이기도 합니다.

같이 보기
-----

* WebRTC 프로토콜
* 위키백과의 세션 기술 프로토콜
그리드 (Grid)
==========

'CSS 그리드(grid)'는 `display` (en-US) 속성의 `grid` 값을 사용하여 정의됩니다. `grid-template-rows` (en-US) 및 `grid-template-columns` 속성을 사용하여 그리드의 열과 행을 정의할 수 있습니다.

이러한 속성을 사용해 정의하는 그리드는 '명시적 그리드'라고 할 수 있습니다.

이 명시적 그리드 외부에 콘텐츠를 배치하거나 자동 배치에 의존하고 그리드 알고리즘이 그리드 요소들을 보관하기 위해 추가 행 또는 열 트랙을 생성해야 하는 경우, 그러면 암시적 그리드에 추가 트랙이 생성됩니다.'암시적 그리드'는 정의된 트랙 외부에 추가되는 콘텐츠로 인해 자동으로 생성되는 그리드입니다.

아래 예제에서는 3개의 열과 2개의 행으로 구성된 '명시적 그리드'를 만들었습니다. 그리드의 '세 번째' 행은 '암시적 그리드' 행 트랙으로, 명시적 트랙을 채우는 6개 항목보다 많기 때문에 형성됩니다.

예제
--
```

\* {
  box-sizing: border-box;
}

.wrapper {
  border: 2px solid #f76707;
  border-radius: 5px;
  background-color: #fff4e6;
}

.wrapper > div {
  border: 2px solid #ffa94d;
  border-radius: 5px;
  background-color: #ffd8a8;
  padding: 1em;
  color: #d9480f;
}
```



```css
.wrapper {
  display: grid;
  grid-template-columns: 1fr 1fr 1fr;
  grid-template-rows: 100px 100px;
}
```



```html
<div class="wrapper">
  <div>One</div>
  <div>Two</div>
  <div>Three</div>
  <div>Four</div>
  <div>Five</div>
  <div>Six</div>
  <div>Seven</div>
  <div>Eight</div>
</div>
```

같이 보기
-----

* 그리드 레이아웃의 기본 개념
* 속성 참고서
    + `grid-template-columns`
    + `grid-template-rows` (en-US)
    + `grid` (en-US)
    + `grid-template` (en-US)
CSS 객체 모델 (CSS Object Model, CSSOM)
===================================

**CSS 객체 모델 (CSS Object Model, CSSOM)**은 문서의 스타일 관련 (CSS) 정보를 읽고 수정하기 위한 API 세트입니다. 즉, DOM을 사용해 JavaScript에서 문서의 구조와 내용을 읽고 수정할 수 있는 방식과 비슷하게, CSSOM을 사용하여 JavaScript에서 문서의 스타일을 읽고 수정할 수 있습니다.

같이 보기
-----

* 페이지 채우기: 브라우저 작동 방식
NaN
===

NaN (Not a Number, 숫자가 아님)은 정의되지 않은 값 또는 표현할 수 없는 값, 특히 부동 소수점 계산 결과를 의미하는 숫자 데이터 타입입니다.

예를 들어, NaN는 무한대, 0으로 나눈 결과, 누락된 값 또는 음수의 제곱근(허수지만, 부동 소수점 숫자는 실수입니다)을 나타낼 수 있습니다.

실제로는, JavaScript 프로그램에서 두 개의 변수를 나누면, 결과는 NaN이 될 수 있고, JavaScript에서 "undefined"로 미리 정의되어 있습니다. 따라서 이 나누기로 인해 프로그램이 중단될 수 있습니다. 이제, 이 계산이 훨씬 더 큰 알고리즘의 작은 부분이라면, 실제로 오류가 발생한 위치를 파악하는 것은 정말 힘들 것입니다. 운이 좋게도, 결과는 NaN이고 나누는 수가 0이 될 수 있다는 것을 알고 있기 때문에, 먼저 이런 계산을 방지하거나 어디서 발생하는지 알려주는 테스트 조건을 설정할 수 있습니다.

같이 보기
-----

* 위키백과의 NaN
* JavaScript의 NaN
웹 분산 저작 및 버전 관리 (Web Distributed Authoring and Versioning, WebDAV)
==================================================================

**웹 분산 저작 및 버전 관리(Web Distributed Authoring and Versioning, WebDAV)** 는 웹 개발자가 클라이언트에서 원격으로 콘텐츠를 갱신할 수 있게 해주는 HTTP 확장 프로그램입니다.

WebDAV는 단독으로 사용되는 경우가 거의 없지만, CalDAV (원격 접근 달력) 및 CardDAV (원격 접근 주소록)이라는 두 가지 확장이 매우 일반적으로 사용됩니다.

WebDAV를 사용하면 클라이언트가 아래를 수행할 수 있습니다.

* 웹페이지 메타데이터(예, 작성자 또는 생성 날짜) 추가, 삭제 및 검색
* 모든 미디어 타입의 페이지를 관련 페이지에 연결
* 문서 세트를 생성하고 계층적으로 목록을 검색
* 웹페이지 복사 및 이동
* 한 번에 두 명 이상이 문서를 편집하지 못하도록 잠금
같이 보기
-----

* 위키백과의 WebDAV
* 명세서:
    + RFC 2518
    + RFC 3253
    + RFC 3744
XLink
=====

XLink는 XML과 XML 또는 기타 문서 간의 링크를 설명하는 데 사용되는 W3C 표준입니다. 처리 방법을 결정하기 위해 일부 동작은 구현에 달려있습니다.

단순 XLink는 Firefox(적어도 SVG 및 MathML에서) 지원되지만, XLink가 포함된 일반 XML 문서를 로드하고 XML 트리에서 관련 포인트를 클릭하려고 하면 링크로 작동하지 않습니다.

XLink 1.0이 일반 링크에 대해 번거롭다고 생각하는 사람들을 위해, XLink 1.1에서 단순 링크에 `xlink:type="simple"`을 지정할 필요가 없어졌습니다.

XLink는 SVG, MathML 및 기타 중요한 표준에서 사용됩니다.

### 명세서

* XLink 1.0
* XLink 1.1 (현재 초안입니다)
### 같이 보기

* XML
* Code snippets:getAttributeNS (en-US) - 이 DOM 메서드를 지원하지 않는 일부 브라우저를 처리하기 위한 래퍼
WebGL
=====

**WebGL** ('Web Graphics Library')은 인터랙티브한 2D/3D 그래픽을 그리는 JavaScript API입니다.

Khronos 그룹에서 OpenGL ES 2.0에 기반한 WebGL을 관리하고 있습니다.

렌더링 표면을 제공하는 HTML `<canvas>` 요소 내부에서 WebGL을 사용할 수 있습니다.

현재 모든 주요 browsers가 WebGL을 지원하지만, 사용 가능 여부는 외부 요인(예. GPU 지원)에 의해 달라질 수 있습니다.

같이 보기
-----

* 위키백과의 WebGL
* WebGL 지원 확인
* MDN의 WebGL
* WebGL 지원 표
구문 오류 (Syntax error)
====================

미리 정의된 구문을 잘못 사용하여 발생한 예외입니다. 소스 코드를 컴파일하거나 구문 분석하는 동안 구문 오류가 감지됩니다.

예를 들어, JavaScript 함수를 정의할 때 닫는 중괄호(`}`)를 생략하면, 구문 오류가 발생합니다. 브라우저 개발자 도구에는 콘솔에 JavaScript 및 CSS 구문 오류를 표시합니다.

같이 보기
-----

* 위키백과의 구문 오류
* `SyntaxError` JavaScript 객체
RSS
===

**RSS** (Really Simple Syndication)는 사이트 업데이트를 게시하기 위해 설계된 여러 XML 문서 형식을 나타냅니다. 웹 사이트의 RSS 피드에 구독하면, 웹 사이트는 피드(feed)라는 RSS 문서로 정보 및 업데이트를 RSS 리더로 보내므로 즐겨찾는 모든 웹 사이트를 수동으로 확인할 필요가 없습니다.

같이 보기
-----

* 위키백과의 RSS
* 최신 명세
Simple response header
======================

CORS-safelisted response header에 포함된 이전에 사용된 용어입니다.
Accent (악센트)
============

**악센트**는 일반적으로 색 구성표 내에서 보다 실용적인 배경 및 전경 색과 대조되는 밝은 색입니다. 이는 전부는 아니지만 많은 플랫폼의 시각적 스타일에서 존재합니다.

웹에서는 `<input>` (en-US) 요소의 컨트롤의 활성에 대해 악센트가 사용되는 경우가 있고, 그 예로 체크박스의 체크된 배경이 있습니다.

같이 보기
-----

### 악센트 관련 CSS

요소의 CSS `accent-color` (en-US) 속성을 적절한 `<color>` 값으로 설정하여 지정된 요소의 악센트 색상을 설정할 수 있습니다.
메타데이터
=====

**메타데이터**의 가장 단순한 정의는 데이터를 설명하는 데이터입니다. 예를 들어, HTML은 데이터입니다. 그리고 HTML의 `<head>` 안에는 문서 작성자나 문서 요약과 같이 문서를 설명하는 데이터, 즉 메타데이터를 넣을 수 있습니다.

같이 보기
-----

* 학습: metadata 배우기
* 위키백과 메타데이터
* MDN의 `<meta>` 요소 문서
식별자
===

**식별자**는 코드 내의 변수, 함수, 혹은 속성을 식별하는 문자열입니다.

JavaScript에서, 식별자는 대소문자를 구별하며 유니코드 글자, `$`, `_`, 숫자(0-9)로 구성할 수 있지만, 숫자로 시작할 수는 없습니다.

식별자는 코드의 일부이지만 문자열은 데이터이기 때문에, 식별자와 문자열은 다릅니다. JavaScript에서 식별자를 문자열로 변환하는 방법은 없지만, 어떤 경우 문자열을 분석해 식별자로 사용할 수 있습니다.

같이 보기
-----

* 위키피디아의 식별자
* Glossary
    + Identifier
    + Scope
    + string
    + Unicode
전역 변수 (Global variable)
=======================

전역 변수는 전역 범위에 선언된 변수입니다. 즉, 다른 모든 범위에서 볼 수 있는 변수입니다.

JavaScript에서는 전역 객체의 속성입니다.

같이 보기
-----

* 위키백과의 전역 변수
핑거프린팅 (Fingerprinting)
======================

**핑거프린팅(Fingerprinting)** 은 브라우저와 기본 운영체제의 고유한 기능을 수집하고 결합하여, 웹사이트에서 특정 브라우저(더 나아가 특정 사용자)를 식별하는 방식입니다. 핑거프린팅에는 아래가 포함될 수 있습니다.

* 브라우저 버전
* 시간대 및 선호하는 언어
* 시스템에서 사용할 수 있는 비디오 또는 오디오 코덱 세트
* 시스템에 설치된 글꼴
* 브라우저 설정 상태
* 컴퓨터의 디스플레이 크기 및 해상도

웹사이트는 기기에서 JavaScript와 CSS를 실행하여 이와 같은 위와 같은 정보를 검색할 수 있으며, 이 데이터를 결합하여 브라우저에 대한 고유한 핑거프린팅을 생성할 수 있으며, 이는 웹에서 사용자를 추적하는 데 사용될 수 있습니다.

웹 표준은 식별 정보를 수집하는 웹 사이트의 기능을 최소화하는 방식으로 설계되었으며, 브라우저는 일반적으로 자체 보호 기능도 추가합니다.

같이 보기
-----

* 웹사이트가 귀하의 브라우저를 지문 인식하는 데 사용할 수 있는 데이터를 표시하는 도구인 Cover Your Tracks
* 핑거프린팅을 방지하기 위한 명세서 작성자의 모범 사례인 웹 명세서에서 브라우저 핑거프린팅 완화
QUIC
====

**QUIC**은 UDP 상에 구현된 다중 전송 프로토콜입니다. HTTP/3의 전송 계층으로 TCP 대신 사용됩니다.

QUIC는 HTTP 연결에 대해 보다 빠른 설정과 낮은 대기 시간을 제공하도록 설계되었습니다.

* TCP에서는, 초기 TCP 핸드셰이크 뒤에 선택적으로 TLS 핸드셰이크가 따라옵니다. 이는 데이터가 전송되기 전에 완료되어야 합니다. 이제 TLS 거의 어디에나 존재하므로, QUIC는 TLS 핸드셰이크를 초기 QUIC 핸드셰이크에 통합하여 설정 중에 교환해야 하는 메시지 수를 줄입니다.
* HTTP/2는 다중화 프로토콜로, 여러 개의 동시 HTTP 트랜잭션을 허용합니다. 그러나 트랜잭션은 단일 TCP 연결을 통해 다중화됩니다. 즉, TCP 계층에서의 패킷 손실 및 후속 재전송으로 인해 모든 트랜잭션이 차단될 수 있습니다. QUIC는 UDP를 통해 실행하고 각 스트림에 대해 별도로 패킷 손실 감지 및 재전송을 구현하여 이를 방지합니다. 즉, 패킷 손실은 패킷이 손실된 특정 스트림만 차단한다는 의미입니다.
같이 보기
-----

* RFC 9000: the QUIC 명세
* RFC 9114: the HTTP/3 명세
DOS 공격 (DoS attack)
===================

DoS (서비스 거부)는 서버에 요청이 너무 많이 들어와 서버 리소스의 합법적인 사용을 방해하는 네트워크 공격입니다.

컴퓨터에는 계산 능력이나 메모리와 같은 제한된 리소스가 있습니다. 제한된 리소스들이 모두 소모되면, 프로그램이 정지되거나 충돌하여 사용할 수 없게 될 수 있습니다. DoS 공격은 이러한 리소스를 소모시키고 합법적인 사용자가 서버나 네트워크를 이용할 수 없게 만들거나, 최소한 서버 성능 하락을 가져오는 다양한 기술로 이루어져 있습니다.

공격을 받는 컴퓨터의 계산 용량을 소진시키기 위해 다수의 서버를 사용하는 분산 서비스 거부 공격(Distributed Denial of Service, DDoS)도 있습니다.

### DoS 공격의 종류

DoS 공격은 특정 종류의 공격이라기 보단, 하나의 범주에 가깝습니다. 다음은 DoS 공격 유형의 대략적인 목록입니다.

* 대역폭 공격
* 서비스 요청 폭주
* SYN 플러딩 공격
* ICMP 플러드 공격
* peer-to-peer(P2P) 공격
* 영구적인 DoS 공격
* 애플리케이션 레벨 플러드 공격
같이 보기
-----

* 위키백과의 서비스 거부 공격
* OWASP의 서비스 거부
* DDoS
암호 (Cipher)
===========

암호학에서, **암호**는 평문을 읽을 수 없게 암호화하고, 다시 복호화할 수 있는 알고리즘입니다.

암호는 정보화 시대 이전부터 널리 사용되었습니다 (예, 대체 암호, 전치 암호 및 순열 암호), 일회용 패드를 제외하고는 그 어느 것도 암호학적으로 안전하지 않았습니다.

최신 암호는 암호해석을 통해 발견한 공격을 견딜 수 있도록 설계되었습니다. 모든 공격 방법이 발견되었다는 보장은 아니지만, 각 알고리즘은 알려진 공격 클래스를 기준으로 판단됩니다.

암호는 데이터의 연속 블록 또는 버퍼에 대한 블록 암호 또는 연속적인 데이터 흐름(주로 소리와 영상)의 스트림 암호의 두 가지 방식으로 작동합니다.

또한, 키 처리 방법에 따라 분류됩니다.

* 대칭 키 알고리즘은 동일한 키를 사용하여 메시지를 암호화 및 복호화합니다. 또한 메시지를 기밀로 유지하려면 키를 안전하게 전송해야 합니다.
* 비대칭 키 알고리즘은 암호화와 복호화에 서로 다른 키를 사용합니다.
같이 보기
-----

* 암호 on Wikipedia
* 암호화와 복호화
* MDN 웹 문서 용어사전
    + 블록 암호 운용 방식
    + 암호
    + 암호문
    + 암호알고리즘 집합
    + 암호분석
    + 암호학
    + 복호화
    + 암호화
    + 키
    + 평문
    + 공개키 암호화
    + 대칭키 암호화
고수준 프로그래밍 언어 (High-level programming language)
==============================================

 고수준 프로그래밍 언어는 컴퓨터 작동의 세부 사항으로부터 \*\*중요한 추상화
 \*\*를 가지고 있습니다. 고수준 프로그래밍 언어는 사람이 쉽게 이해할 수 있도록 설계되었으므로 다른 소프트웨어로 번역해야 합니다. 저수준 프로그래밍 언어와 달리 자연어 요소를 사용하거나, 컴퓨팅 시스템의 중요한 영역을 자동화(또는 완전히 숨기는 방법으로)하여 저수준 언어에 비해 개발 프로세스를 더 간단하고 이해하기 쉽게 만들 수 있습니다. 제공된 추상화의 양은 프로그래밍 언어가 얼마나 "고수준"인지 정의합니다.

자동으로 기계 코드로 번역되지만, 인간의 논리에 더 가까운 언어에 대한 아이디어는 1950년대 컴퓨터 과학에 도입되었습니다. 특히 널리 유포된 최초의 고급 언어인 Fortran을 만든 **John Backus** (IBM)의 작업에 감사를 드립니다. 이러한 혁신으로 Backus는 Turing 상을 받았습니다.
사이트 (Site)
==========

비공식적으로, '사이트'는 웹페이지 모음이고, 동일한 도메인에서 제공되며 단일 조직에서 유지관리하는 웹사이트입니다.

브라우저는 때때로 서로 다른 사이트를 정확하게 구별해야 합니다. 예를 들어, 브라우저는 `SameSite` (en-US) 쿠키를 쿠키를 설정한 동일한 사이트로만 보내야 합니다.

보다 정확한 정의를 위해 사이트는 도메인 이름의 '등록 가능한 도메인' 부분에 의해 결정됩니다. 등록 가능한 도메인은 공개 접미사 목록의 항목과 바로 앞의 도메인 네임 부분으로 구성됩니다. 예를 들면, `theguardian.co.uk`, `sussex.ac.uk` 및 `bookshop.org`가 모두 등록 가능한 도메인임을 의미합니다.

이 정의에 따라, `support.mozilla.org` 및 `developer.mozilla.org`는 동일한 사이트의 일부입니다. `mozilla.org`는 등록 가능한 도메인이기 때문입니다.

일부 상황에서는, 사이트를 차별화할 때 이 체계가 고려되기도 합니다. 이렇게 하면 `http://vpl.ca`와 `https://vpl.ca`가 다른 사이트가 됩니다. 이러한 스키마를 포함하면 안전하지 않은(HTTP) 사이트가 보안(HTTPS) 사이트와 동일한 사이트로 처리되는 것을 방지할 수 있습니다. 이러한 방식을 고려한 정의를 'schemeful same-site'라고도 합니다. 이와 같이, 더 엄격한 정의는 `SameSite` (en-US) 쿠키 처리 규칙에 적용됩니다.

예제
--

`mozilla.org`의 등록 가능한 도메인이 동일하므로 다음 사이트는 동일합니다.

* `https://developer.mozilla.org/en-US/docs/`
* `https://support.mozilla.org/en-US/`

포트가 관련이 없기 때문에, 다음은 동일한 사이트입니다.

* `https://example.com:8080`
* `https://example.com`

두 URL의 등록 가능한 도메인이 다르기 때문에 동일한 사이트가 아닙니다.

* `https://developer.mozilla.org/en-US/docs/`
* `https://example.com`

다음은 스키마가 고려되는 경우 동일한 사이트이거나 다른 사이트입니다.

* `http://example.com`
* `https://example.com`
같이 보기
-----

* URL이란 무엇인가요
* Origin
* 동일 출처 정책
ECMAScript
==========

**ECMAScript**는 JavaScript의 기반이 되는 스크립팅 언어 명세입니다. Ecma International은 ECMAScript 표준화를 담당하고 있습니다.

같이 보기
-----

* 위키피디아의 ECMAScript
* ECMAScript
프레스토 (Presto)
=============

프레스토(Presto)는 버전 15까지 오페라 브라우저를 구동하는 데 사용된 독점 브라우저 레이아웃 엔진이었습니다. 이후 Opera 브라우저는 블링크 레이아웃을 엔진을 사용하는 Chromium을 기반으로 합니다.

같이 보기
-----

* 위키백과의 프레스토 레이아웃 엔진
코드 포인트 (Code point)
===================

\*\*코드 포인트 (code point)\*\*는 텍스트를 표현하기 위한 시스템(예, 유니코드)에서 추상 문자를 나타내기 위해 할당된 숫자입니다. 유니코드에서, 코드 포인트는 "U+1234" 형식으로 표현됩니다. 여기서 "1234"는 할당된 숫자입니다. 예를 들어, 문자 "A"에는 U+0041이라는 코드 포인트가 할당됩니다.

UTF-8 및 UTF-16과 같은 문자 인코딩 형식은 유니코드 코드 포인트를 연속된 바이트로 인코딩하는 방법을 결정합니다. 다른 인코딩 형식은 동일한 코드 포인트를 다른 연속된 바이트로 인코딩할 수 있습니다. 예를 들어, 코드 포인트가 U+0424인 키릴 문자 "Ф"는 UTF-8에서는 `0xd0a4`로, UTF-16에서는 `0x0424`로 인코딩됩니다.

같이 보기
-----

* 유니코드 표준: 코드 포인트와 문자
페이지 예측 (Page prediction)
========================

**페이지 예측 (Page prediction)** 은 활성화되면, 사용자가 콘텐츠를 요청하기 전에 사용자가 방문할 가능성이 있는 리소스를 다운로드 하도록 브라우저에 지시하는 브라우저 기능 또는 스크립트입니다. 페이지 예측은 예측된 콘텐츠를 거의 즉시 로드할 수 있도록 하여 성능을 향상시킵니다. 그러나, 페이지 예측은 사용자가 검색하지 않는 콘텐츠를 다운로드할 수도 있습니다.

일부 웹 애플리케이션에는 검색 기록 및 관련 검색을 기반으로 검색 텍스트와 주소 표시줄 URL을 완성하는 예측 기능이 포함되어 있습니다. 예를 들어, 사용자가 주소 표시줄에 입력하면, 브라우저는 사용자가 요청을 제출하기 전에 주소 표시줄의 현재 텍스트를 검색 엔진에 보낼 수 있습니다.

브라우저 페이지 예측 및 예측 서비스는 더 빠른 페이지 로드를 가능하게 하지만, 추가 대역폭을 소비합니다. 또한, 사전 로드된 웹사이트와 삽입된 콘텐츠는 방문하지 않았더라도 방문한 것처럼 쿠키를 설정하고 읽을 수 있습니다.

같이 보기
-----

* prerender
* prefetch
명령문 (Statement)
===============

컴퓨터 프로그래밍 언어에서, **명령문(statement)** 은 작업을 명령하는 코드 줄입니다. 모든 프로그램은 일련의 명령문으로 구성됩니다.

같이 보기
-----

* 위키백과의 명령문 (컴퓨터 과학)
* JavaScript 명령문과 선언문
CORS 허용 목록에 있는 응답 헤더 (CORS-safelisted response header)
======================================================

'CORS 허용 목록에 있는 응답 헤더 (CORS-safelisted response header)'는 클라이언트 스크립트에 노출되어도 '안전'하다고 생각되는 CORS 응답의 HTTP 헤더입니다. 허용된 응답 헤더만 웹페이지에서 사용할 수 있습니다.

기본적으로, 허용 목록에는 다음과 같은 응답 헤더가 포함됩니다.

* `Cache-Control`
* `Content-Language`
* `Content-Length`
* `Content-Type`
* `Expires`
* `Last-Modified`
* `Pragma`

`Access-Control-Expose-Headers`를 사용하여 허용 목록에 부가적인 헤더를 추가할 수 있습니다.

**참고:** `Content-Length`헤더는 허용된 원래 응답 헤더 집합의 일부가 아닙니다. [ref]를 참고해주세요.

예제
--

### 허용 목록의 확장

`Access-Control-Expose-Headers` 헤더를 사용하여 CORS 허용 목록에 있는 응답 헤더 목록을 확장할 수 있습니다.


```http
Access-Control-Expose-Headers: X-Custom-Header, Content-Encoding
```

같이 보기
-----

* HTTP
* HTTP headers
* `Access-Control-Expose-Headers`
* 용어사전
    + CORS
    + CORS 허용 목록에 있는 요청 헤더
    + 금지된 헤더 이름
    + 요청 헤더
캐럿 (Caret)
==========

**캐럿(Caret)** (때때로 "텍스트 커서(text cursor)"라고도 함)은 텍스트 입력이 삽입될 위치를 나타내기 위해 화면에 표시되는 표시기입니다.

대부분의 사용자 인터페이스는 얇은 수직선이나 깜박이는 문자 크기의 상자를 사용하여 캐럿을 나타내지만 이는 다를 수 있습니다. 텍스트의 이 지점을 **삽입 지점**이라고 합니다. '캐럿'이라는 단어는 텍스트 삽입 지점과 마우스 커서를 구별합니다.

웹에서, 캐럿은 `<input>` (en-US) 및 `<textarea>` (en-US) 요소는 물론 `contenteditable` 속성이 설정된 모든 요소의 삽입 지점을 나타내는 데 사용됩니다. 따라서 사용자가 요소의 내용을 편집할 수 있습니다.

같이 보기
-----

* 위키백과의 캐럿 네비게이션
### 캐럿 관련 CSS

요소의 CSS `caret-color` (en-US) 속성을 적절한 `<color>` 값으로 설정하여 특정 요소의 편집 가능한 콘텐츠에 대한 캐럿 색상을 설정할 수 있습니다.

### 캐럿을 표시할 수 있는 HTML 요소

이러한 요소는 텍스트 입력 필드 또는 상자를 제공하므로 캐럿을 사용합니다.

* `<input type="text">` (en-US)
* `<input type="password">` (en-US)
* `<input type="search">` (en-US)
* `<input type="date">`, `<input type="time">` (en-US), and `<input type="datetime-local">` (en-US)
* `<input type="number">` (en-US), `<input type="range">` (en-US)
* `<input type="email">` (en-US), `<input type="tel">` (en-US) 및 `<input type="url">` (en-US)
* `<textarea>` (en-US)
* 콘텐츠 편집이 가능한 속성이 설정된 모든 요소
가상 요소 (Pseudo-element)
======================

CSS에서, **가상 요소(pseudo-element)** 선택자는 선택할 특정 HTML 요소가 없는 시나리오에서 문서 콘텐츠의 일부에 스타일을 적용합니다. 예를 들어, 각 단락의 첫 글자를 자체 요소에 넣는 대신 `p``::first-letter` (en-US)를 사용하여 모든 단락의 스타일을 지정할 수 있습니다.

같이 보기
-----

* 가상 요소
WebP
====

**WebP**는 Google이 개발한 무손실/손실 압축 이미지 포맷입니다.

### 같이 보기

* 위키백과의 WebP
메인 스레드 (Main thread)
====================

**메인 스레드(main thread)** 는 브라우저가 사용자 이벤트와 페인트를 처리하는 곳입니다. 기본적으로, 브라우저는 단일 스레드를 사용하여 페이지의 모든 JavaScript를 실행하고 레이아웃, 리플로우 및 가비지 컬렉션을 수행합니다. 오래 실행되는 JavaScript 함수가 스레드를 차단하여 페이지가 응답하지 않고, 사용자 경험이 저하될 수 있다는 것을 의미합니다.

서비스 워커 (en-US)와 같은 웹 워커 (en-US)를 의도적으로 사용하지 않는 한, JavaScript는 메인 스레드에서 실행되기 때문에, 스크립트로 인해 이벤트 처리 또는 페인팅이 지연되기 쉽습니다. 메인 스레드에 필요한 작업이 적을수록, 메인 스레드는 사용자 이벤트, 페인트에 더 많이 응답할 수 있으며, 일반적으로 사용자에게 응답할 수 있습니다.

같이 보기
-----

* 비동기 JavaScript
* Web worker API
* Service worker API
* 용어 사전
    + Thread
Nullish 값
=========

JavaScript 에서 Nullish 값은 `null`또는 `undefined`값 중 하나입니다. Nullish 값은 항상 falsy 입니다.
라우터
===

웹에서 **라우터**는 다음 3가지로 정의합니다.

1. 네트워크 계층에서, 라우터는 데이터 패킷 방향을 결정하는 네트워크 장치입니다. 라우터는 사용자가 인터넷과 상호작용할 수 있도록 관련 업체에서 배포합니다.
2. 애플리케이션 계층에서, Single-page application의 경우, 라우터는 주어진 URL로 표시되는 웹 페이지를 결정하는 라이브러리입니다. 이 미들웨어 모듈은 다음 페이지를 열기 위해 렌더링 되는 파일에 대한 경로가 제공되는 모든 URL 기능에 사용됩니다.
3. 서비스 계층의 API 구현에서, 라우터는 요청을 구문 분석하고 요청을 프로그램 내의 다양한 핸들러로 보내거나 라우팅하는 소프트웨어 구성 요소입니다. 라우터 코드는 일반적으로 처리기의 응답을 수락하고 요청자에게 반환하는 것을 용이하게 합니다.
같이 보기
-----

네트워크 계층의 정의인 경우

* 위키백과의 라우터 (컴퓨터 공학)

애플리케이션 계층의 SPA에서의 정의인 경우, 가장 인기있는 SPA 프레임워크들은 그들의 라우팅 라이브러리가 있습니다.

* Angular 라우터
* React 라우터
* Vue 라우터
부모 객체 (Parent object)
=====================

주어진 속성 또는 메서드가 속한 객체입니다.

같이 보기
-----

* JavaScript의 상속 및 프로토타입에 대한 토론
엔티티 헤더
======

**경고:** HTTP/1.1 명세는 더 이상 엔티티, 엔티티 헤더 또는 엔티티 본문을 참조하지 않습니다. 일부 필드는 이제 Representation header 필드라고 합니다.

엔티티 헤더는 HTTP 메시지의 페이로드(예: 메시지 본문에 대한 메타데이터)를 나타내는 HTTP 헤더입니다. `Content-Length`, `Content-Language`, `Content-Encoding`, `Content-Type`, `Expires` 등과 같은 헤더는 엔티티 헤더에 포함됩니다. 엔티티 헤더는 HTTP 요청 및 응답 모두에 존재할 수 있습니다.

엔티티 헤더가 요청이나 응답 헤더가 아님에도 불구하고, 이러한 용어로 종종 포함됩니다.

다음 예제에서, `Content-Length`는 엔티티 헤더지만, `Host`와 `User-Agent` (en-US)는 request 헤더입니다.


```http
POST /myform.html HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Content-Length: 128
```

같이 보기
-----

* Representation header
POP3
====

**우체국 프로토콜 (Post Office Protocol, POP3)** 은 TCP 연결을 통해 메일 서버에서 이메일을 받기 위한 매우 일반적인 프로토콜입니다. POP3는 보다 더 복잡한 구조로 인해 구현하기가 더 어려운 최신 IMAP와 달리 폴더를 지원하지 않습니다.

클라이언트는 일반적으로 모든 메시지를 검색한 다음 서버에서 삭제하지만, POP3에서는 서버에 복사본을 보관할 수 있습니다. 거의 모든 이메일 서버와 클라이언트는 현재 POP3를 지원합니다.

같이 보기
-----

* 위키백과의 POP
* RFC 1734 (POP3 인증 메커니즘의 명세서)
* RFC 1939 (POP3 명세서)
* RFC 2449 (POP3 확장 메커니즘의 명세서)
* MDN 웹 문서 용어 사전:
    + IMAP
공개 키 암호화 방식 (Public-key cryptography)
=====================================

 공개 키 암호화(또는 비대칭 암호화)는 키가 쌍으로 제공되는 암호화 시스템입니다.
 키 중 하나에 의해 수행된 변환은 다른 키로만 실행 취소할 수 있습니다. 하나의 키 ('개인 키')는 비밀로 유지되고 다른 하나는 공개됩니다.

디지털 서명에 사용되는 경우, 개인 키는 서명에 사용되고 공개 키는 확인에 사용됩니다. 이것은 누구나 서명을 확인할 수 있지만, 해당 개인 키의 소유자만이 서명을 생성할 수 있음을 의미합니다.

암호화에 사용되는 경우, 공개 키는 암호화에 사용되고 개인 키는 복호화에 사용됩니다. 이는 암호화 키를 공개할 수 있다는 점에서 공개키 암호화 시스템이 대칭 암호화 시스템에 비해 이점을 제공합니다. 누구든지 개인 키 소유자에게 보내는 메시지를 암호화할 수 있지만 개인 키 소유자만이 메시지를 해독할 수 있습니다. 그러나, 일반적으로 대칭 알고리즘보다 훨씬 느리고 암호화할 수 있는 메시지 크기는 키 크기에 비례하므로 긴 메시지에 맞게 확장되지 않습니다.

결과적으로, 암호화 시스템에서는 대칭 알고리즘을 사용하여 메시지를 암호화한 다음, 공개 키 시스템에서 대칭 키를 암호화하는 것이 일반적입니다. 이러한 배열은 두 시스템의 이점을 모두 제공할 수 있습니다.

일반적으로 사용되는 공개 키 암호화 시스템은 RSA(서명 및 암호화용), DSA(서명용) 및 Diffie-Hellman(키 계약용)입니다.

같이 보기
-----

* Web Crypto API (en-US)
* MDN 웹 문서 용어 사전
    + Symmetric-key cryptography
구문 (Syntax)
===========

구문은 올바르게 구조화된 코드를 구성하는 문자열의 필수 조합과 순서를 지정합니다. 구문에는 일반적으로 Python의 들여쓰기 요구 사항과 같이 문법과 작성에 적용되는 규칙이 포함됩니다.

구문은 언어마다 다릅니다(예, HTML 및 JavaScript의 구문은 다름). 언어는 JavaScript 및 Python의 "피연산자 연산자 피연산자" 규칙과 같이 구문 측면에서 거의 유사점을 공유할 수 없습니다. 이것은 두 언어가 구문과 유사점을 공유한다는 의미가 아닙니다.

구문은 프로그래밍 언어(컴퓨터에 대한 명령)와 마크업 언어(문서 구조 정보) 모두에 동일하게 적용됩니다.

구문은 순서와 구조에만 적용됩니다. 이러한 지침은 또한 '의미 있는' 것이어야 하고 의미론적인 부분입니다.

컴파일을 올바르게 수행하려면 코드에 올바른 구문이 있어야 합니다. 그렇지 않으면 구문 오류가 발생합니다. 괄호 누락과 같은 작은 오류라도, 소스 코드가 성공적으로 컴파일되지 않을 수 있습니다.

간단하고, 읽기 쉽고, 간결한 결과를 생성하는 프레임워크는 "깨끗한" 구문을 가지고 있다고 합니다. 코드베이스가 "많은 구문"을 사용하는 경우, 동일한 기능을 달성하려면 더 많은 문자가 필요합니다.

같이 보기
-----

* 위키백과의 구문 (프로그래밍 언어)