웹의 리소스 식별하기 - HTTP

웹의 리소스 식별하기
===========

HTTP 요청 대상을 "리소스"라고 하며 리소스의 특성은 더 이상 정의되지 않습니다. 리소스는 문서, 사진 등으로 그 어떤 것이든 될 수 있습니다. 각 리소스는 리소스 식별을 위해 HTTP 전체에서 사용되는 URI(Uniform Resource Identifier)로 식별됩니다.

URL과 URN
--------

### URL

가장 일반적인 URI 형식은 **웹 주소**로 알려진 URL(Uniform Resource Locator)입니다.

```url
https://developer.mozilla.org
https://developer.mozilla.org/en-US/docs/Learn/
https://developer.mozilla.org/en-US/search?q=URL
```

이러한 URL 중 하나를 브라우저의 주소 표시줄에 입력하여 URL과 연결되는 페이지(리소스)를 로드할 수 있도록 지시할 수 있습니다.

URL은 여러 부분으로 구성되는데, 일부는 필수 사항이고 나머지는 선택 사항입니다. 더 복잡한 예는 다음과 같습니다.

```url
http://www.example.com:80/path/to/myfile.html?key1=value1&key2=value2#SomewhereInTheDocument
```

### URN

URN(Uniform Resource Name)은 특정 네임스페이스에서 이름으로 리소스를 식별하는 URI입니다.

```url
urn:isbn:9780141036144
urn:ietf:rfc:7230
```

두 URN은 다음을 나타냅니다.

* George Orwell의 책, Nineteen Eighty-Four
* IETF 명세 7230, Hypertext Transfer Protocol (HTTP/1.1): 메시지 구문과 라우팅
URI(Uniform Resource Identifier) 문법
-----------------------------------

### 스키마 또는 프로토콜

![프로토콜](/ko/docs/Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web/mdn-url-protocol@x2.png)

`http://`는 프로토콜로, 브라우저가 사용해야 하는 프로토콜을 나타냅니다. 일반적으로 프로토콜은 HTTP이거나 보안 버전인 HTTPS입니다. 웹은 이 두 가지 중 하나를 사용하지만, 브라우저는 메일 클라이언트를 여는 `mailto:` 또는 파일 전송을 처리하는 `ftp:`와 같은 다른 프로토콜을 처리하는 방법도 알고 있으므로 이러한 프로토콜을 보더라도 놀라지 않으셔도 됩니다. 일반적인 스키마는 다음과 같습니다.

| 스키마 | 설명 |
| --- | --- |
| data | Data URL |
| file | 호스트별 파일 이름 |
| ftp | 파일 전송 프로토콜 |
| http/https | 하이퍼 텍스트 전송 프로토콜 (보안) |
| javascript | URL내 JavaScript 코드 |
| mailto | 전자 메일 주소 |
| ssh | 보안 쉘 |
| tel | 전화 |
| urn | 통합 자원 이름 |
| view-source | 리소스의 소스코드 |
| ws/wss | 웹 소켓 연결 (보안) |

### 인증

![도메인 이름](/ko/docs/Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web/mdn-url-domain@x2.png)

`www.example.com`은 네임스페이스를 관리하는 도메인 이름 또는 기관입니다. 도메인 이름은 요청중인 웹 서버를 나타냅니다. 또는, IP 주소를 직접 사용할 수도 있으나, 편의성이 떨어져, 웹에서는 자주 사용되지 않습니다.

### 포트

![포트](/ko/docs/Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web/mdn-url-port@x2.png)

이 경우 포트는 `:80`입니다. 포트는 웹 서버의 리소스에 접근하는 데 사용되는 기술적인 "게이트"를 나타냅니다. 웹 서버가 HTTP 프로토콜의 표준 포트(HTTP의 경우 80, HTTPS의 경우 443)를 사용하여 리소스에 접근하는 경우엔 일반적으로 포트가 생략됩니다. 표준 포트를 사용하지 않는다면, 필수로 입력해주어야 합니다.

### 경로

![파일에 대한 경로](/ko/docs/Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web/mdn-url-path@x2.png)

`/path/to/myfile.html`은 웹 서버의 리소스 경로입니다. 초기 웹에서는, 이와 같은 경로가 웹 서버의 물리적 파일 위치를 나타냈습니다. 하지만 요즘에는 물리적 파일을 나타내는 것이 아닌 웹 서버에서 처리를 추상화하는 것에 불과합니다.

### 쿼리

![매개변수](/ko/docs/Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web/mdn-url-parameters@x2.png)

`?key1=value1&key2=value2`는 웹 서버에 제공되는 추가 매개변수입니다. 이러한 매개변수는 `&` 기호로 구분된 키/값 쌍의 목록입니다. 웹 서버는 이러한 매개변수를 사용하여 리소스를 사용자에게 반환하기 전에 추가적인 작업을 수행할 수 있습니다. 각 웹 서버에는 매개변수를 사용하는 고유한 규칙이 있으며 특정 웹 서버가 매개변수를 처리하는 방법을 알 수 있는 신뢰할만한 유일한 방법은 웹 서버 소유자에게 문의하는 것입니다.

### 프레그먼트

![앵커](/ko/docs/Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web/mdn-url-anchor@x2.png)

`#SomewhereInTheDocument`는 리소스 자체의 다른 부분에 대한 앵커입니다. 앵커는 리소스 내부의 일종의 '북마크'를 나타내며 브라우저에 해당 '북마크된' 지점에 있는 콘텐츠를 표시하는 방향을 제공합니다. 예를 들어, HTML 문서에서 브라우저는 앵커가 정의된 지점으로 스크롤합니다. 비디오나 오디오 문서에서 브라우저는 앵커가 나타내는 시간으로 이동하려고 시도합니다. 프래그먼트 식별자라고도 하는 # 뒤의 부분은 요청과 함께 서버로 전송되지 않는다는 점에 유의할 필요가 있습니다.

사용 일람
-----

HTML 콘텐츠에서 URL을 사용할 때, 일반적으로 URL 스키마 중의 일부만 사용해야 합니다. 하위 리소스(즉 더 큰 문서의 일부로 로드되는 파일)를 참조할 때는 HTTP 및 HTTPS 스키마만 사용해야 합니다. 점점 더 많은 브라우저에서 보안상의 이유로 FTP를 사용하여 하위 리소스를 로드하는 지원을 제거하고 있습니다.

일부 브라우저는 FTP 콘텐츠 로드를 다른 애플리케이션에 위임할 수 있지만, 최상위 수준(예, 브라우저의 URL 표시줄 또는 링크 대상에 직접 입력)에서 여전히 FTP를 사용할 수 있습니다.

예제
--

```url
https://developer.mozilla.org/en-US/docs/Learn
tel:+1-816-555-1212
git@github.com:mdn/browser-compat-data.git
ftp://example.org/resource.txt
urn:isbn:9780141036144
mailto:help@supercyberhelpdesk.info
```

명세
--

| Specification |
| --- |
| HTTP Semantics # uri |

같이 보기
-----

* URL이란 무엇인가?
* IANA URI 체계 목록


Resource URLs - HTTP

Resource URLs
=============

**비표준:** 이 기능은 비표준이므로 실제 프로덕션에서 사용하지 마세요. 모든 사용자 환경에서 작동하지 않을 수 도 있으며, 미래에 호환성 문제가 생길 수 있습니다.

`resource:` 스키마가 앞에 붙은 URL은 리소스 URL은 Firefox 및 Firefox 브라우저 확장 프로그램에서 내부적으로 리소스를 로드하는 데 사용되지만, 일부 정보는 브라우저가 연결하는 사이트에서도 사용할 수 있습니다.

구문
--

리소스 URL은 접두사 (`resource:`)와 로드하려는 리소스를 가리키는 URL의 두 부분으로 구성됩니다.

```url
resource://<url>
```

예를 들어,

```url
resource://gre/res/svg.css
```

리소스 URL('->')에 화살표가 있으면, 첫 번째 파일이 다음 파일을 로드했음을 의미합니다.

```url
resource://<File-loader> -> <File-loaded>
```

자세한 내용은 웹에서 리소스 식별을 참조하세요.

이 글에서는, 내장 리소스를 가리키기 위해 Firefox에서 내부적으로 사용되는 리소스 URI에 중점을 둡니다.

위협
--

`resource:` URL을 통해 공유된 정보 중 일부는 다음에서 사용할 있기 때문입니다. 웹사이트, 웹페에지는 내부 스크립트를 실행하고 심각한 보안 및 개인정보 보호 문제가 될 수 있는, 기본 환경 설정을 포함하여 Firefox의 내부 리소스를 검사할 수 있습니다.

예를 들어, Browserleaks의 스크립트는 사이트에서 실행할 수 있는 간단한 스크립트로 조회할 때 Firefox가 공개하는 내용을 강조합니다(https://browserleaks.com/firefox#more에서 코드를 찾을 수 있습니다).

firefox.js 파일은 기본 설정된 이름과 값을 pref() 함수에 전달합니다. 예를 들어,

```url
http://searchfox.org/mozilla-central/rev/48ea452803907f2575d81021e8678634e8067fc2/browser/app/profile/firefox.js#575
```

웹사이트는 이 `pref()` 함수를 재정의하고 `resource:///defaults/preferences/firefox.js` 스크립트를 사용하여 Firefox 기본 환경 설정을 쉽게 수집할 수 있습니다.

또한, 기본 설정의 일부 기본값은 플랫폼 및 로케일 등 웹사이트가 이러한 정보들을 사용하여 개별 사용자를 식별할 수 있는 정보를 기반으로 빌드 구성마다 다릅니다.

해결책
---

이 문제를 해결하기 위해, Mozilla 리소스 로드 동작을 변경했습니다. Firefox 버그 863246의 URI는 Firefox 57 (Quantum) (en-US)에 포함되었습니다.

과거에는 웹 콘텐츠가 원하는 `resource:` URI가 무엇이든, 즉 Firefox의 내부 리소스뿐만 아니라 확장 프로그램의 자산에도 접근할 수 있었습니다. 이제 이 행위는 기본적으로 금지되어 있습니다.

그러나 Firefox가 웹 콘텐츠의 리소스를 로드하는 것은 여전히 특정 상황에서는 필요한 부분입니다. 예를 들어, 소스 보기 페이지(View Page Source 또는 View Selection Source)를 열었을 때, `resource:` URI를 통해 `viewsource.css`가 필요하다는 것을 알 수 있습니다. 웹 콘텐츠에 노출되어야 하는 리소스에는 격리되어 있으며 민감하지 않은 리소스만 포함되어 있는 `resource://content-accessible/`이라는 새 위치로 이동되었습니다. 이러한 방법으로 우리는 필수적인 것을 유지할 수 있고, 리소스가 노출되어 대부분의 위협이 없어지게 되었습니다.

**참고:** 웹 및 확장 프로그램 개발자는 더 이상 리소스 URL을 시도하지 않는 것이 좋습니다.
 그들의 사용법은 기껏해야 해키였습니다.
 대부분의 사용법은 작동하지 않습니다.

명세서
---

리소스: 어떤 명세에도 아직 아무것도 정의되지 않았습니다.

브라우저 호환성
--------

리소스: 오직 Firefox만 지원합니다.

같이 보기
-----

* Web에서 리소스를 식별하기
* URL이란 무엇인가?
* IANA URI 체계 목록 (`resource:`은 이곳에서 다룹니다)


HTTP의 진화 - HTTP

HTTP의 진화
========

**HTTP** (HyperText Transfer Protocol)은 월드 와이드 웹의 기반이 되는 프로토콜입니다. 1989년부터 1991년까지 Tim Berners-Lee와 그의 팀이 개발한 HTTP는 유연함을 형성하는 동시에 단순함을 지키는 데 도움이 되는 많은 수정을 거쳐왔습니다. HTTP가 신뢰할 수 있는 실험실 환경에서 파일을 교환하도록 만들어진 프로토콜에서 고해상도와 3D 이미지와 비디오를 전달하는 현대 인터넷 미로로 어떻게 진화했는지 알아보려면 계속해서 읽어주세요.

월드 와이드 웹의 발명
------------

1989년 CERN에서 일하고 있던 Tim Berners-Lee는 인터넷을 통한 하이퍼텍스트 시스템을 만들기 위한 제안을 작성했습니다. 초기에 Mesh라고 불리던 그것은 1990년에 구현 과정에서 '월드 와이드 웹'으로 이름을 바꿨습니다. 기존의 TCP 그리고 IP 프로토콜 기반으로 만들어졌고, 4개의 기본 구성요소로 이루어져 있습니다.

* 하이퍼텍스트 문서를 표현하기 위한 텍스트 형식의 '하이퍼텍스트 마크업 언어' (HTML).
* 하이퍼텍스트 문서를 교환하기 위한 간단한 프로토콜인 '하이퍼텍스트 전송 프로토콜' (HTTP).
* 문서를 보여주기(그리고 수정하기) 위한 클라이언트인 '월드 와이드 웹(WorldWideWeb)'이라고 불리는 첫번째 브라우저.
* 문서에 접근하도록 해주는 서버, 'httpd'의 초기 버전.

이 네 개의 기본 구성 요소는 1990년 말에 완료되었으며, 첫번째 서버는 1991년 초에 CERN 외부에서 실행되었습니다. 1991년 8월 6일, 'alt.hypertext' 공개 뉴스 그룹의 Tim Berners-Lee의 포스트가 공개 프로젝트로써의 월드 와이드 웹의 공식적인 출발점으로 여겨집니다.

이렇게 초기 단계에 사용되던 HTTP 프로토콜은 매우 간단했습니다. 이후 HTTP/0.9 버전을 부여했으며 때로는 원-라인 프로토콜로 불리기도 했습니다.

HTTP/0.9 – 원-라인 프로토콜
--------------------

HTTP 초기 버전에는 버전 번호가 없었습니다. HTTP/0.9는 이후 버전과 구별하기 위해 0.9로 불리게 됐습니다. HTTP/0.9는 극히 단순합니다. 요청은 단일 라인으로 구성되며 리소스에 대한 경로로 가능한 메서드는 `GET`이 유일했습니다. 서버에 연결되면 프로토콜, 서버 및 포트가 필요하지 않으므로 전체 URL은 포함되지 않았습니다.

```http
GET /mypage.html
```

응답 또한 극도로 단순합니다. 오로지 파일 내용 자체로 구성됩니다.

```html
<html>
  A very simple HTML page
</html>
```

다음 발전 방향과는 다르게, HTTP 헤더가 없었는데 이는 HTML 파일만 전송될 수 있으며 다른 유형의 문서는 전송될 수 없음을 의미합니다. 상태 혹은 오류 코드도 없었습니다. 문제가 발생한 경우, 특정 HTML 파일이 만들어지고 사람이 처리할 수 있도록, 해당 파일 내부에 문제에 대한 설명이 HTML 파일에 추가되었습니다.

HTTP/1.0 – 확장성 만들기
------------------

HTTP/0.9는 매우 제한적이었으며, 브라우저와 서버를 통해서 빠르게 다양한 특징을 가지게 되었습니다.

* 각 요청 안에 버전 정보가 포함되어 전송되었습니다(`HTTP/1.0` 이 `GET` 라인에 붙은 형태).
* 상태 코드 라인 또한 응답의 시작 부분에 붙어 전송되었습니다. 브라우저가 요청에 대한 성공과 실패를 알 수 있고 그 결과에 대한 동작(예, 특정 방법으로 로컬 캐시를 갱신하거나 사용)을 할 수 있게 되었습니다.
* HTTP 헤더 개념은 요청과 응답 둘 다 도입되어, 메타데이터 전송이 가능해졌고, 프로토콜이 극도로 유연하고 확장성이 높아졌습니다.
* `Content-Type` 덕분에, 일반 HTML 파일들 외에 다른 문서들을 전송할 수 있었습니다.

다음은 일반적인 요청과 응답입니다:

```http
GET /mypage.html HTTP/1.0
User-Agent: NCSA\_Mosaic/2.0 (Windows 3.1)

200 OK
Date: Tue, 15 Nov 1994 08:12:31 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/html
<HTML>
A page with an image
 <IMG SRC="/myimage.gif">
</HTML>
```

두 번째 연결에 의한 이미지를 내려받기 위한 요청과 그에 대한 응답입니다.

```http
GET /myimage.gif HTTP/1.0
User-Agent: NCSA\_Mosaic/2.0 (Windows 3.1)

200 OK
Date: Tue, 15 Nov 1994 08:12:32 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/gif
(image content)
```

1991년부터 1995년 사이에 시도해보고 접근하는 방식으로 도입되었습니다. 서버와 브라우저는 기능을 추가하고, 새로운 기능이 관심을 끄는지 주시했습니다. 수많은 상호작용의 문제는 일반적이었습니다. 1996년 11월에, 문제를 해결하기 위해, 일반적인 실제 내용을 설명하는 정보 문서로 HTTP/1.0가 정의된 RFC 1945로 알려진 문서가 게시되었습니다.

HTTP/1.1 – 표준 프로토콜
------------------

그 동안, 적절한 표준화 작업이 진행되었습니다. 표준화 작업은 HTTP/1.0의 다양한 구현과 병행되었습니다. HTTP의 첫 번째 표준화 버전인 HTTP/1.1은 HTTP/1.0 이후 불과 몇 달 뒤인 1997년 초에 발표되었습니다.

HTTP/1.1은 모호함을 명확하게 하고 많은 개선 사항들을 도입했습니다.

* 연결을 재사용할 수 있어 시간이 절약됩니다. 단일 원본 문서 내로 포함된 리소스들을 표시하기 위해 더 이상 여러 번 연결을 열 필요가 없기 때문입니다.
* 파이프라이닝을 추가하여, 첫번째 요청에 대한 응답이 완전히 전송되기 전에 두번째 요청 전송을 가능케 하여, 통신 지연 시간이 단축되었습니다.
* 청크된 응답도 지원되었습니다.
* 추가적인 캐시 제어 메커니즘이 도입되었습니다.
* 언어, 인코딩 혹은 타입을 포함한 컨텐츠 협상이 도입되어, 클라이언트와 서버로 하여금 교환하려는 가장 적합한 컨텐츠에 대한 합의를 할 수 있습니다.
* `Host` 헤더 덕분에, 동일 IP 주소에 다른 도메인을 호스트하는 기능이 서버 배치가 가능해졌습니다.

다음은 하나의 단일 커넥션을 통한 요청의 전형적인 전체 흐름의 예시입니다.

```http
GET /en-US/docs/Glossary/Simple\_header 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
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,\*/\*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/en-US/docs/Glossary/Simple\_header

200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Wed, 20 Jul 2016 10:55:30 GMT
Etag: "547fa7e369ef56031dd3bff2ace9fc0832eb251a"
Keep-Alive: timeout=5, max=1000
Last-Modified: Tue, 19 Jul 2016 00:59:33 GMT
Server: Apache
Transfer-Encoding: chunked
Vary: Cookie, Accept-Encoding

(content)

GET /static/img/header-background.png 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
Accept: \*/\*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/en-US/docs/Glossary/Simple\_header

200 OK
Age: 9578461
Cache-Control: public, max-age=315360000
Connection: keep-alive
Content-Length: 3077
Content-Type: image/png
Date: Thu, 31 Mar 2016 13:34:46 GMT
Last-Modified: Wed, 21 Oct 2015 18:27:50 GMT
Server: Apache

(image content of 3077 bytes)
```

HTTP/1.1는 1997년 1월에 RFC 2068에서 처음 공개되었습니다.

15년 넘게 진행된 확장
-------------

HTTP의 확장성 덕분에 새로운 헤더와 메서드를 쉽게 만들 수 있었습니다. HTTP/1.1 프로토콜은 HTTP/2가 나오기 전인 1999년 6월에 공개된 RFC 2616과 2014년 6월에 공개된 RFC 7230-RFC 7235라는 두 번에 걸친 개정을 통해 개선되었고, 이 프로토콜은 15년 넘도록 매우 안정적이었습니다.

### 보안 전송을 위한 HTTP 사용

HTTP에 일어났던 가장 큰 변화는 1994년 말에 이루어졌습니다. 컴퓨터 서비스 회사인 Netscape Communications는 기본 TCP/IP 스택을 통해 HTTP를 전송하는 대신에, TCP/IP 스택 위에 추가적인 암호화된 전송 계층인 SSL을 만들어냈습니다. SSL 1.0은 대중에게 비공개였고, SSL 2.0과 후속 버전인 SSL 3.0을 통해 전자 상거래 웹사이트를 만들 수 있었습니다. 이를 위해서 서버와 클라이언트 간에 교환되는 메시지의 신뢰성을 암호화하고 보장했습니다. SSL은 결국 표준화되어 TLS가 되었습니다.

같은 기간에, 암호화된 전송 계층에 대한 필요하다는 것이 분명해졌습니다. 웹은 더 이상 학문적인 네트워크가 아니라, 광고주, 불특정 개인 혹은 범죄자가 가능한 한 많은 개인정보 데이터를 놓고 경쟁하는 정글이 되었습니다. HTTP를 통해 구축된 애플리케이션이 더욱 강력해지고 주소록, 이메일 혹은 사용자의 지리적 위치와 같은 수 많은 개인 정보에 접근하는 부분이 필요해짐에 따라, 전자 상거래 이외의 경우에서도 TLS에서 필요해졌습니다.

### 복잡한 애플리케이션을 위한 HTTP 사용

 Tim Berners-Lee는 원래 HTTP를 읽기 전용 도구로 생각하지 않았습니다.
 그는 사람들이 문서를 원격으로 추가하거나 이동시킬 수 있는, 분산된 파일 시스템의 한 종류로 웹을 만들고 싶었습니다. 1996년경에 HTTP는 저작을 허용하도록 확장되었으며 WebDAV라고 불리는 표준이 만들어졌습니다. WebDAV는 주소록 항목들을 다루기 위한 CardDAV 및 달력을 다루기 위한 CalDav와 같은 특정 애플리케이션들로 더 확장되었습니다. 그러나 이런 모든 \*DAV 확장들은 한 가지 결함이 있었는데, 서버에서 구현된 경우에만 사용할 수 있었습니다.

2000년에, HTTP 사용에 대한 새로운 패턴인 representational state transfer (또는 REST)가 설계가 되었습니다. API는 새로운 HTTP 메서드를 기반으로 하지 않았지만, 대신 기본 HTTP/1.1 메서드를 사용하여 특정 URI에 대한 접근에 의존했습니다. 이를 통해 모든 웹 애플리케이션에서 API가 브라우저나 서버를 업데이트하지 않고도 데이터를 검색하고 수정할 수 있게 되었습니다. 필요한 모든 정보는 웹 사이트가 표준 HTTP/1.1을 통해 제공되는 파일에 포함되었습니다. REST 모델의 단점은 각 웹사이트가 자체 비표준 RESTful API를 정의하고 이를 완전히 제어할 수 있다는 것입니다. 이는 클라이언트와 서버가 상호 운용 가능한 \*DAV 확장과 차이가 있습니다. RESTful API들은 2010년에 들어 매우 보편화되었습니다.

2005년 이후 웹 페이지에서 사용 가능한 API를 사용할 수 있게 되었습니다. 이 API 중 일부는 특정한 목적을 위해 HTTP 프로토콜에 확장을 생성합니다.

* 서버 전송 이벤트, 서버가 브라우저로 가끔 메시지를 푸쉬할 수 있습니다.
* 웹소켓은 기존 HTTP 연결을 업그레이드하여 만들 수 있는 새로운 프로토콜입니다.
### 웹의 보안 모델 완화

HTTP는 동일 출처 정책으로 알려진 웹 보안 모델과는 독립되어 있습니다. 사실, 현재의 웹 보안 모델은 HTTP이 만들어진 이후에 개발되었습니다! 몇 년에 걸쳐, 특정 제약 조건을 두고, 이 정책의 일부 제한 사항을 해제하는 것이 유용한 것으로 입증되었습니다. 서버는 새로운 HTTP 헤더 세트를 사용하여 이러한 제한을 언제, 얼마나 해제해야 하는지 클라이언트에 전송했습니다. 교차 출처 리소스 공유 (CORS) 및 컨텐츠 보안 정책 (CSP)과 같은 명세 안에 정의되었습니다.

큰 확장 외에, 다른 많은 헤더들이, 때로는 실험적으로만, 추가되었습니다. 주목할 만한 헤더는 프라이버시를 제어하기 위한 Do Not Track (`DNT` (en-US)) 헤더, `X-Frame-Options`, 혹은 `Upgrade-Insecure-Requests` (en-US)이 있지만, 더 많은 헤더들이 존재합니다.

HTTP/2 – 더 나은 성능을 위한 프로토콜
-------------------------

몇 년에 걸쳐, 웹 페이지는 더욱 복잡해졌습니다. 일부는 그 자체로 애플리케이션이기도 했습니다. 더 많은 시각적 미디어가 표시되고 상호작용을 위한 스크립트 코드의 양과 크기도 증가했습니다. 훨씬 더 많은 HTTP 요청을 통해, 많은 데이터가 전송되었고, 이를 통해 HTTP/1.1 연결에 복잡성과 오버헤드가 많이 발생했습니다. 이를 설명하기 위해, Google은 2010년 초반에 실험적인 프로토콜 SPDY를 구현했습니다. 클라이언트와 서버 간 데이터를 교환하는 이 대체 방법은 브라우저와 서버 모두에서 작업하는 개발자들의 관심을 끌었습니다. SPDY는 응답성 증가를 정의하고 중복 데이터 전송 문제를 해결하여 HTTP/2 프로토콜의 기반이 됩니다.

HTTP/2 프로토콜은 HTTP/1.1과 몇가지 특징이 다릅니다.

* 텍스트 프로토콜이 아닌 이진 프로토콜입니다. 읽을 수도 없고 수동으로 만들 수 없습니다. 이러한 장애물에도 불구하고, 향상된 최적화 기술을 구현할 수 있습니다.
* 다중화 프로토콜입니다. 동일한 연결을 통해 병렬 요청을 수행할 수 있어, HTTP/1.x 프로토콜의 제약을 없애줍니다.
* 헤더를 압축합니다. 요청 집합 간에 유사한 경우가 많으므로, 전송된 데이터의 중복과 오버헤드가 제거됩니다.
* 서버가 서버 푸시라는 메커니즘으로 클라이언트 캐시에 데이터를 저장할 수 있습니다.

2015년 5월에 공식적으로 표준화된 HTTP/2는 2022년 1월 전체 웹 사이트의 46.9%로 사용량 정점에 도달했습니다(these stats 참조). 트래픽이 많은 웹사이트는 데이터 전송 오버헤드와 그에 따른 예산을 절약하기 위한 노력의 일환으로 가장 빠르게 채택되었습니다.

HTTP/2가 웹사이트와 애플리케이션을 변경할 필요가 없었기 때문에 빠른 채택이 가능했을 확률이 높습니다. 이를 사용하려면, 최신 브라우저와 통신하는 최신 서버만 필요했습니다. HTTP/2 채택을 높이기 위해서는 제한된 그룹 집합만 필요했고, 레거시 브라우저와 서버 버전이 갱신되면서 웹 개발자의 큰 노력 없이도 자연스럽게 사용량이 늘어났습니다.

차세대-HTTP/2로의 진화
---------------

HTTP의 확장성은 여전히 새로운 기능을 추가하는 데 사용되고 있습니다. 특히 2016년에 등장한 HTTP 프로토콜의 새로운 확장을 예로 들 수 있습니다.

* `Alt-Svc` 지원은 좀 더 영리한 CDN 메커니즘을 따라, 신분 증명의 개념과 주어진 자원의 위치를 분리하도록 해줍니다.
* 클라이언트 힌트의 도입으로 브라우저 혹은 클라이언트가 요구사항이나 서버의 하드웨어 제약사항에 관한 정보를 사전에 미리 주고 받을 수 있게 되었습니다.
* `Cookie` 헤더에 보안 관련 접두사 도입은 보안 쿠키가 변경되지 않았다는 것을 보장하는데 도움을 줍니다.
HTTP/3 - QUIC를 통한 HTTP
----------------------

HTTP의 다음 주요 버전인 HTTP/3에서는 이전 버전의 HTTP와 동일한 의미를 가지지만, 전송 계층에서 TCP 대신 QUIC를 사용합니다. 2022년 10월까지 모든 웹사이트의 26%가 HTTP/3를 사용하고 있었습니다.

QUIC는 HTTP 연결에 대해서 훨씬 낮은 대기 시간을 제공하도록 설계되었습니다. HTTP/2와 마찬가지로, 다중화 프로토콜이지만, HTTP/2는 단일 TCP 연결을 통해 실행되어 TCP 계층에서 처리되는 패킷 손실 감지 및 재전송이 모든 스트림을 차단할 수 있습니다. QUIC는 UDP를 통해 여러 스트림을 실행하고 각 스트림에 대해 독립적으로 패킷 손실 감지 및 재전송을 구현하므로, 오류가 발생하면 해당 패킷에 데이터가 있는 스트림만 차단됩니다.

RFC 9114에 정의되어 있고, HTTP/3은 주요 브라우저에서 지원됩니다. Chromium(및 Chrome 및 Edge와 같은 변형) 및 Firefox도 지원대상에 포함됩니다.


일반 MIME 타입 - HTTP

일반 MIME 타입
==========

다음은 일반적인 확장자로 정렬된, 문서 타입과 관련된 MIME 타입의 포괄적인 목록입니다.

두 개의 주요 MIME 타입은 기본 타입에 있어 중요한 역할을 합니다.

* `text/plain`는 텍스트 파일을 위한 기본값입니다. 텍스트 파일은 인간이 읽을 수 있어야 하며 이진 데이터를 포함해서는 안됩니다.
* `application/octet-stream`는 다른 모든 경우를 위한 기본값입니다. 알려지지 않은 파일 타입은 이 타입을 사용해야 합니다. 브라우저들은 이런 파일들을 다룰 때, 소프트웨어 취약점과 발생할 수 있는 위험한 동작으로부터 보호하도록 특히 주의를 기울여야 합니다.

IANA는 MIME 미디어 타입의 공식적인 레지스트리로 공식적인 MIME 타입의 전체 목록을 관리합니다. 다음 표에 웹에 대한 몇 가지 중요한 MIME 타입들이 나와 있습니다.

| 확장자 | 문서 종류 | MIME 타입 |
| --- | --- | --- |
| `.aac` | AAC 오디오 | `audio/aac` |
| `.abw` | AbiWord 문서 | `application/x-abiword` |
| `.arc` | 아카이브 문서 (다중 파일 포함) | `application/x-freearc` |
| `.avif` | AVIF 이미지 | `image/avif` |
| `.avi` | AVI: 오디오 비디오 인터리브(Audio Video Interleave) | `video/x-msvideo` |
| `.azw` | 아마존 킨들 전자책 포맷 | `application/vnd.amazon.ebook` |
| `.bin` | 모든 종류의 이진 데이터 | `application/octet-stream` |
| `.bmp` | Windows OS/2 비트맵 그래픽 | `image/bmp` |
| `.bz` | BZip 아카이브 | `application/x-bzip` |
| `.bz2` | BZip2 아카이브 | `application/x-bzip2` |
| `.cda` | CD 오디오 | `application/x-cdf` |
| `.csh` | C-셸 스크립트 | `application/x-csh` |
| `.css` | 종속 스타일 시트 (CSS) | `text/css` |
| `.csv` | 쉼표로 구분된 값 (CSV) | `text/csv` |
| `.doc` | Microsoft 워드 | `application/msword` |
| `.docx` | Microsoft 워드 (OpenXML) | `application/vnd.openxmlformats-officedocument.wordprocessingml.document` |
| `.eot` | MS Embedded OpenType fonts | `application/vnd.ms-fontobject` |
| `.epub` | 전자출판물(Electronic publication) (EPUB) | `application/epub+zip` |
| `.gz` | GZip 압축 아카이브 | `application/gzip` |
| `.gif` | Graphics Interchange Format (GIF) | `image/gif` |
| `.htm`, `.html` | HyperText Markup Language (HTML) | `text/html` |
| `.ico` | Icon format | `image/vnd.microsoft.icon` |
| `.ics` | iCalendar format | `text/calendar` |
| `.jar` | Java Archive (JAR) | `application/java-archive` |
| `.jpeg`, `.jpg` | JPEG 이미지 | `image/jpeg` |
| `.js` | JavaScript | `text/javascript` (명세: HTML 및 RFC 9239) |
| `.json` | JSON 형식 | `application/json` |
| `.jsonld` | JSON-LD 형식 | `application/ld+json` |
| `.mid`, `.midi` | Musical Instrument Digital Interface (MIDI) | `audio/midi`, `audio/x-midi` |
| `.mjs` | JavaScript 모듈 | `text/javascript` |
| `.mp3` | MP3 오디오 | `audio/mpeg` |
| `.mp4` | MP4 비디오 | `video/mp4` |
| `.mpeg` | MPEG 비디오 | `video/mpeg` |
| `.mpkg` | Apple 설치 패키지 | `application/vnd.apple.installer+xml` |
| `.odp` | OpenDocument 프레젠테이션 문서 | `application/vnd.oasis.opendocument.presentation` |
| `.ods` | OpenDocument 스프레드시트 문서 | `application/vnd.oasis.opendocument.spreadsheet` |
| `.odt` | OpenDocument 텍스트 문서 | `application/vnd.oasis.opendocument.text` |
| `.oga` | OGG 오디오 | `audio/ogg` |
| `.ogv` | OGG 비디오 | `video/ogg` |
| `.ogx` | OGG | `application/ogg` |
| `.opus` | Opus 오디오 | `audio/opus` |
| `.otf` | OpenType 폰트 | `font/otf` |
| `.png` | Portable Network Graphics | `image/png` |
| `.pdf` | Adobe 휴대용 문서 형식 (PDF) | `application/pdf` |
| `.php` | Hypertext Preprocessor (**Personal Home Page**) | `application/x-httpd-php` |
| `.ppt` | Microsoft PowerPoint | `application/vnd.ms-powerpoint` |
| `.pptx` | Microsoft PowerPoint (OpenXML) | `application/vnd.openxmlformats-officedocument.presentationml.presentation` |
| `.rar` | RAR 아카이브 | `application/vnd.rar` |
| `.rtf` | Rich Text Format (RTF) | `application/rtf` |
| `.sh` | Bourne shell script | `application/x-sh` |
| `.svg` | Scalable Vector Graphics (SVG) | `image/svg+xml` |
| `.tar` | Tape Archive (TAR) | `application/x-tar` |
| `.tif`, `.tiff` | Tagged Image File Format (TIFF) | `image/tiff` |
| `.ts` | MPEG 전송 스트림 | `video/mp2t` |
| `.ttf` | TrueType Font | `font/ttf` |
| `.txt` | Text, (일반적으로 ASCII 또는 ISO 8859-*n*) | `text/plain` |
| `.vsd` | Microsoft Visio | `application/vnd.visio` |
| `.wav` | Waveform Audio Format | `audio/wav` |
| `.weba` | WEBM audio | `audio/webm` |
| `.webm` | WEBM video | `video/webm` |
| `.webp` | WEBP image | `image/webp` |
| `.woff` | Web Open Font Format (WOFF) | `font/woff` |
| `.woff2` | Web Open Font Format (WOFF) | `font/woff2` |
| `.xhtml` | XHTML | `application/xhtml+xml` |
| `.xls` | Microsoft Excel | `application/vnd.ms-excel` |
| `.xlsx` | Microsoft Excel (OpenXML) | `application/vnd.openxmlformats-officedocument.spreadsheetml.sheet` |
| `.xml` | XML | RFC 7303 (섹션 4.1)부터 `application/xml`을 권장하지만, `text/xml`은 여전히 가끔 사용됩니다. 내용이 해석되는 방식에 따라 `.xml` 확장자를 가진 파일에 특정 MIME 타입을 할당할 수 있습니다. 예를 들어, Atom 피드는 `application/atom+xml`이지만, `application/xml`은 유효한 기본값으로 사용됩니다. |
| `.xul` | XUL | `application/vnd.mozilla.xul+xml` |
| `.zip` | ZIP archive | `application/zip` |
| `.3gp` | 3GPP audio/video container | `video/3gpp`; 비디오가 포함되어 있지 않은 경우 `audio/3gpp` |
| `.3g2` | 3GPP2 audio/video container | `video/3gpp2`; 비디오가 포함되어 있지 않은 경우 `audio/3gpp2` |
| `.7z` | 7-zip archive | `application/x-7z-compressed` |


CORS errors - HTTP

CORS errors
===========

교차 출처 자원 공유 (CORS)는 서버가 same
 origin 정책(same-origin policy)을 완화할 수 있게 해 주는 표준입니다. 이는 일부
 교차 출처 요청은 명시적으로 허용하고 다른 요청은 거부하는 데 사용됩니다. 예를 들어서, 어떤 사이트가 embeddable service를 제공하는 경우, 특정 제한을
 완화하는 것이 필요할 수 있습니다. CORS 설정을 세팅하는 것은 그리 쉬운 일이 아니며, 도전일 수 있습니다. 이 페이지에서는, 몇 가지 일반적인 CORS 에러 메시지를 소개하고 그에 맞는 해결법을
 알아보겠습니다.

 만약 CORS 설정이 제대로 세팅되어 있지 않다면, 브라우저 콘솔에는 다음과 같은 메시지가 표시될 것입니다:
 `"Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at $somesite"`
 이 메시지는 CORS 보안 규칙 위반으로 인해 요청이 차단되었음을 알려줍니다. 이것은 꼭 설정 실수라고 볼 수는 없습니다.
 사실은 해당 요청이 유저 쪽의 웹 어플리케이션과 외부 서비스에 의해 거부당했을 수 있습니다. 하지만 만약 엔드포인트가 사용 가능한 걸로 확인된다면, 약간의 디버깅이 필요 할 수 있습니다.

이슈 파악하기
-------

CORS 설정 이슈를 근본적으로 이해하려면 어떤 요청이 문제이고 왜 문제인지를 파악할 필요가 있습니다. 다음 단계들을 따라하면 도움이 될 것입니다.

1. 웹사이트나 웹앱으로 이동하여 Developer Tools을 여세요.
2. 실패한 요청을 재현하고 나서 CORS 위반 에러 메시지가 떴다면 console을 확인하세요. 메시지는 다음과 같을 겁니다:

![Firefox console showing CORS error](/ko/docs/Web/HTTP/CORS/Errors/cors-error2.png)

에러 메시지 내용은 다음과 비슷할 수 있습니다.
```

Cross-Origin Request Blocked: The Same Origin Policy disallows
reading the remote resource at https://some-url-here. (Reason:
additional information here).
```

**참고:** \*\*Note:\*\*보안상의 이유로, CORS 요청에서 정확히 무엇을 위반했는지에 대한 사항은 *JavaScript 코드상에서 사용할 수 없습니다.* 코드상에서 알 수 있는 것은 에러가 발생했다는 것 뿐입니다.
 정확히 무엇이 잘못됐는지 파악하려면 브라우저 콘솔을 살피는 수밖에 없습니다.

CORS 에러 메시지
-----------

 Firefox 콘솔은 CORS에 의해 요청이 실패했을 때 메시지를 출력합니다. 에러내용의 일부분은 "Reason"에 관한 메시지로서 무엇이 잘못되었는지에 대한 힌트를 제공합니다.
 "Reason" 메시지들이 아래에 정리되어 있으니 더 자세한 에러에 대한 설명과 솔루션을 보고 싶으시다면 링크로 이동하세요.

* Reason: CORS disabled
* Reason: CORS request did not succeed
* Reason: CORS header 'Origin' cannot be
added
* Reason: CORS request external redirect
not allowed
* Reason: CORS request not http
* Reason: CORS header
'Access-Control-Allow-Origin' missing
* Reason: CORS header
'Access-Control-Allow-Origin' does not match 'xyz'
* Reason: Credential is not supported if the
CORS header 'Access-Control-Allow-Origin' is '\*'
* Reason: Did not find method in CORS header
'Access-Control-Allow-Methods'
* Reason: expected 'true' in CORS header
'Access-Control-Allow-Credentials'
* Reason: CORS preflight channel did not
succeed
* Reason: invalid token 'xyz' in CORS header
'Access-Control-Allow-Methods'
* Reason: invalid token 'xyz' in CORS header
'Access-Control-Allow-Headers'
* Reason: missing token 'xyz' in CORS
header 'Access-Control-Allow-Headers' from CORS preflight channel
* Reason: Multiple CORS header
'Access-Control-Allow-Origin' not allowed
더보기
---

* Glossary: CORS
* CORS introduction
* Server-side CORS settings (en-US)
* CORS enabled image
* CORS settings attributes (en-US)
* https://www.test-cors.org – page to test CORS requests


Reason: Did not find method in CORS header 'Access-Control-Allow-Methods' - HTTP

Reason: Did not find method in CORS header 'Access-Control-Allow-Methods'
=========================================================================

이유
--
```

Reason: Did not find method in CORS header 'Access-Control-Allow-Methods'
```

무엇이 문제인가요?
----------

CORS 요청에서 사용 중인 HTTP 메서드는 응답 `Access-Control-Allow-Methods` 헤더에 의해 지정된 메서드 목록에 포함되어 있지 않습니다. 이 헤더는 CORS를 사용하여 요청에 지정된 URL에 접근할 때 사용할 수 있는 HTTP 메서드의 쉼표로 구분되는 목록입니다. 요청이 다른 메소드를 사용하는 경우에, 이 오류가 발생합니다.

예를 들어, 응답에 다음이 포함된 경우

```http
Access-Control-Allow-Methods: GET,HEAD,POST
```

`PUT` 요청을 사용하려고 하면 이 오류와 함께 실패합니다.

서비스에 접근할 때 코드가 허용된 HTTP 메서드만 사용하는지 확인하세요.

**참고:** 서버의 `Access-Control-Allow-methods` 헤더에 인식되지 않거나 정의되지 않은 메서드 이름이 포함된 경우, 다른 오류가 발생합니다. `Reason: invalid token 'xyz' in CORS header 'Access-Control-Allow-Methods'`.

See also
--------

* CORS 에러
* 용어 사전: CORS
* CORS 소개
* HTTP 요청 메서드


Reason: CORS header 'Origin' cannot be added - HTTP

Reason: CORS header 'Origin' cannot be added
============================================

이유
--
```

Reason: CORS header 'Origin' cannot be added
```

무엇이 잘못되었는가?
-----------

 사용자 에이전트(user agent)가 필요한 `Origin`
 헤더를 HTTP 요청에 추가할 수 없습니다. 모든 CORS 요청에는 `Origin` 헤더가 있어야 합니다.

예를 들어, JavaScript 코드가 여러 도메인의 콘텐츠에 접근할 수 있는 향상된 권한으로 실행되는 경우에 발생할 수 있습니다.

같이 보기
-----

* CORS 에러
* Glossary: CORS
* CORS 소개


Reason: CORS disabled - HTTP

Reason: CORS disabled
=====================

원인
--
```

원인: CORS 비활성화
```

무엇이 문제인가요?
----------

CORS를 사용해야 하는 요청이 시도되었지만 사용자의 브라우저에서 CORS가 비활성화되어 있습니다. 이 경우 사용자는 브라우저에서 CORS를 다시 켜야 합니다.

 Firefox에서 CORS를 비활성화하는 기본 설정은 `content.cors.disable`입니다.
 `true`로 설정하면 CORS가 비활성화되므로 그럴 때마다 CORS 요청은 항상 실패하고 이 오류가 발생합니다.

더 보기
----

* CORS 에러
* Glossary: CORS
* CORS 소개


Reason: CORS request not HTTP - HTTP

Reason: CORS request not HTTP
=============================

이유
--
```

Reason: CORS request not HTTP
```

무엇이 잘못되었는가?
-----------

CORS 요청은 오직 HTTPS URL 스키마만을 사용할 수 있지만 요청에 의해 지정된 URL은 다른 타입이다. 이는 URL이 `file:///` URL을 사용해 로컬 파일을 지정할 경우 종종 발생한다.

이 문제를 해결하려면, `XMLHttpRequest`, Fetch APIs, 웹 폰트 (`@font-face`), WebGL textures, XSL 스타일시트와 같은 CORS를 포함하는 요청이 발생할 때 HTTPS URL을 사용하고 있는지 확인하도록 한다.

### Firefox 68에서의 로컬 파일 보안

Firefox 67 이전 버전에서 `file:///` URI를 사용하는 페이지를 열때 페이지의 오리진은 페이지가 열린 디렉토리로 정의된다. 동일한 디렉토리와 그 하위 디렉토리의 리소스들은 CORS 동일-오리진 규칙의 목적을 위한 동일 오리진을 갖는 것으로 처리된다.

CVE-2019-11730에 대한 응답으로, Firefox 68 이후 버전에서는 `file:///` URI를 사용해 열린 페이지의 오리진은 유니크한 것으로 정의된다. 그러므로, 동일 디렉토리나 그 하위 디렉토리의 다른 리소스들은 더 이상 CORS 동일-오리진 규칙을 충족하지 않는다. 이는 `privacy.file_unique_origin` 구성을 사용하여 기본으로 활성화되는 새로운 동작이다.

함께 보기
-----

* CORS 에러
* Glossary: CORS
* CORS 소개
* URL이 무엇인가?


Reason: CORS header 'Access-Control-Allow-Origin' missing - HTTP

Reason: CORS header 'Access-Control-Allow-Origin' missing
=========================================================

원인
--
```

원인 : CORS header 'Access-Control-Allow-Origin' missing
```

무엇이 문제인가요?
----------

CORS 요청에 대한 응답에 현재 오리진 내에서 작동하는 콘텐츠가 리소스에 액세스할 수 있는지 여부를 결정하는 데 사용되는 필수 `Access-Control-Allow-Origin` 헤더가 없습니다.

서버가 사용자의 제어 하에 있는 경우, 요청 사이트의 오리진을 `Access-Control-Allow-Origin` 헤더 값에 추가하여 액세스가 허용된 도메인 집합에 추가합니다.

예를 들어, `https://amazing.site` 사이트에 CORS를 사용하여 리소스에 액세스하려면 헤더는 다음과 같아야 합니다 :

```http
Access-Control-Allow-Origin: https://amazing.site
```

또한 `*` 와일드카드를 사용하여 모든 사이트에서 액세스할 수 있도록 사이트를 구성할 수도 있습니다. 공용 API에만 사용해야 합니다. 개인 API는 절대 `*`를 사용해서는 안 되며 대신 특정 도메인 또는 도메인이 설정되어 있어야 합니다. 또한 이 와일드카드는 `crossorigin` 속성이 `anonymous`로 설정된 요청에 대해서만 작동하며 요청에서 쿠키와 같은 자격 증명을 보내는 것을 방지합니다.

```http
Access-Control-Allow-Origin: \*
```

**경고:** 와일드카드를 사용하여 모든 사이트가 개인 API에 액세스할 수 있도록 허용하는 것은 좋지 않습니다.

 모든 사이트가 `*`를 사용하지 않고 CORS 요청을 수행할 수 있도록 하려면
 와일드카드(예: 자격 증명 사용)는 서버가 요청의 `Origin` 헤더 값을 읽고 해당 값을 사용하여 `Access-Control-Allow-Origin`을 설정해야 하며, 또한 일부 헤더가 오리진에 따라 동적으로 설정되고 있음을 나타내기 위해 `Vary: Origin` 헤더를 설정해야 합니다.

 헤더를 설정하는 정확한 명령문은 웹 서버에 따라 다릅니다. Apache에서 다음을 추가하십시오.
 Apache에서 다음과 같은 행을 서버의 구성에 추가합니다(해당하는 `<Directory>`, `<Location>`, `<Files>`, or `<VirtualHost>` 섹션 내). 구성은 일반적으로 `.conf` 파일(`httpd.conf`와 `apache.conf`와 같은 일반적인 이름) 또는 `.htaccess` 파일에 있습니다.
```

Header set Access-Control-Allow-Origin 'origin-list'
```

Nginx의 경우 이 헤더를 설정하는 명령은 다음과 같습니다 :
```

add_header 'Access-Control-Allow-Origin' 'origin-list';
```

더 보기
----

* CORS 에러
* Glossary: CORS
* CORS 소개


Reason: invalid token 'xyz' in CORS header 'Access-Control-Allow-Methods' - HTTP

Reason: invalid token 'xyz' in CORS header 'Access-Control-Allow-Methods'
=========================================================================

이유
--
```

Reason: invalid token 'xyz' in CORS header 'Access-Control-Allow-Methods'
```

무엇이 잘못되었나요?
-----------

서버에서 보낸 CORS 요청에 대한 응답에는 하나 이상의 잘못된 메서드 이름을 포함하는 `Access-Control-Allow-Methods` 헤더가 포함되어 있습니다.

`Access-Control-Allow-Methods` 헤더는 클라이언트가 CORS 요청에 대해 지원하는 HTTP 요청 메서드를 알리기 위해 서버에서 전송됩니다. 헤더의 값은 `GET`, `POST` 또는 `HEAD`와 같은 HTTP 메서드 이름들의 쉼표로 구분된 문자열입니다. 클라이언트 user agent에서 지정된 값을 인식하지 못하는 경우, 이 오류가 발생합니다.

이것은 `Access-Control-Allow-Methods` 헤더와 함께 유효하지 않거나 알 수 없는 메서드 이름을 더 이상 보내지 않도록 서버의 구성을 수정하여 서버 측에서만 해결할 수 있는 문제입니다. 클라이언트에서 사용 중인 사용자 에이전트 또는 HTTP 라이브러리가 최신인지 확인하는 것도 의미가 있습니다.

같이 보기
-----

* CORS 오류
* 용어 사전: CORS
* CORS 소개
* HTTP 요청 메서드


Reason: Credential is not supported if the CORS header 'Access-Control-Allow-Origin' is '*' - HTTP

Reason: Credential is not supported if the CORS header 'Access-Control-Allow-Origin' is '\*'
============================================================================================

원인
--
```

원인: Credential is not supported if the CORS header 'Access-Control-Allow-Origin' is '*'
```

무엇이 문제인가요?
----------

자격 증명 플래그가 설정된 상태에서 CORS요청이 시도되었지만 서버는 자격 증명 사용을 허용하지 않는 `Access-Control-Allow-Origin`값으로 와일드카드(`"*"`)를 사용하여 구성됩니다.

클라이언트 측에서 이 문제를 해결하려면 CORS 요청을 발행할 때 자격 증명 플래그의 값이 `false`인지 확인하십시오.

* `XMLHttpRequest`를 사용하여 이슈가 발생하는 경우 `withCredentials` (en-US)를 `true`로 설정하지 않았는지 확인하십시오.
* Server-sent events를 사용하는 경우 `EventSource.withCredentials` (en-US)가 (기본값) `false`인지 확인하십시오.
* Fetch API를 사용하는 경우 `Request.credentials`가 `"omit"`인지 확인하십시오.

대신 서버의 동작을 조정해야 하는 경우 클라이언트가 로드되는 원본에 대한 액세스 권한을 부여하도록 `Access-Control-Allow-Origin`값을 변경해야 합니다.

같이 보기
-----

* CORS 에러
* Glossary: CORS
* CORS 소개


Reason: invalid token 'xyz' in CORS header 'Access-Control-Allow-Headers' - HTTP

Reason: invalid token 'xyz' in CORS header 'Access-Control-Allow-Headers'
=========================================================================

이유
--
```

Reason: invalid token 'xyz' in CORS header 'Access-Control-Allow-Headers'
```

무엇이 문제인가요?
----------

서버에서 보낸 CORS 요청에 대한 응답에는 유효하지 않은 헤더 이름이 하나 이상 포함된 `Access-Control-Allow-Headers` 헤더가 포함되어 있습니다.

`Access-Control-Allow-Headers` 헤더는 preflight request에 대한 응답으로 서버에서 전송됩니다. 이를 통해 클라이언트는 CORS 요청에서 허용되는 HTTP headers를 알 수 있습니다. 클라이언트 user agent가 헤더에서 제공하는 쉼표로 구분된 값 중에서 인식하지 못하는 헤더 이름을 찾으면 오류가 발생합니다.

이것은 `Access-Control-Allow-Headers` 헤더와 함께 유효하지 않거나 알 수 없는 헤더 이름을 더 이상 보내지 않도록 서버 구성을 수정하여 서버 측에서만 수정할 수 있는 문제입니다. 클라이언트에서 사용 중인 사용자 에이전트 또는 HTTP 라이브러리가 최신인지 확인하는 것도 가치가 있을 수 있습니다.

같이 보기
-----

* CORS 에러
* 용어 사전: CORS
* CORS 소개
* HTTP 헤더


Reason: CORS header 'Access-Control-Allow-Origin' does not match 'xyz' - HTTP

Reason: CORS header 'Access-Control-Allow-Origin' does not match 'xyz'
======================================================================

원인
--
```

Reason: CORS header 'Access-Control-Allow-Origin' does not match 'xyz'
```

무엇이 문제인가요?
----------

요청의 오리진이 헤더의 `Access-Control-Allow-Origin`에서 허용하고 있는 오리진의 내용과 일치하지 않습니다. 이 오류는 두 개 이상의 `Access-Control-Allow-Origin` 헤더를 응답에 포함하였을 때도 발생할 수 있습니다.

사용자의 제어 하에 작동하는 서비스에서 CORS 요청을 사용하는 경우, `Access-Control-Allow-Origin` 헤더에 사용자의 오리진이 포함되어 있는지 확인합니다. 또 하나의 헤더만이 응답에 포함되어 있는지, 응답에 하나의 오리진만 포함되어 있는지 확인합니다.

 예제로 Apache에서는 서버 설정 시 아래의 명령어를 추가합니다. (서버 설정은 `<Directory>`, `<Location>`, `<Files>`, 또는 `<VirtualHost>` 섹션 내부에 존재합니다.)
 설정은 일반적으로 `.conf` 파일(`httpd.conf`와 `apache.conf`가 일반적인 이름)이나 `.htaccess` 파일에서 찾을 수 있습니다.

**경고:** HTTPS 또는 HTTP 프로토콜에서 반드시 origin 항목을 포함하여야 합니다.
```

Header set Access-Control-Allow-Origin 'origin'
```

Ngix에서는 아래 명령어를 이용하여 헤더를 설정할 수 있습니다.
```

add_header 'Access-Control-Allow-Origin' 'origin'
```

같이 보기
-----

* CORS 에러
* 용어 사전: CORS
* CORS 소개
* CORS 사용: 내 서버에 CORS를 추가하고 싶다면


Reason: CORS request did not succeed - HTTP

Reason: CORS request did not succeed
====================================

원인
--
```

원인: CORS 요청이 성공하지 못했습니다.
```

무엇이 문제인가요?
----------

네트워크 또는 프로토콜 수준에서 HTTP 연결이 실패했기 때문에 CORS를 사용하는 HTTP 요청이 실패했습니다. 이 에러는 근본적인 네트워크 에러이거나 그에 준하는 에러로 CORS와 직접적인 연관이 있는 것은 아닙니다.

더 보기
----

* CORS 에러
* Glossary: CORS
* CORS 소개


Reason: missing token 'xyz' in CORS header 'Access-Control-Allow-Headers' from CORS preflight channel - HTTP

Reason: missing token 'xyz' in CORS header 'Access-Control-Allow-Headers' from CORS preflight channel
=====================================================================================================

이유
--
```

Reason: missing token 'xyz' in CORS header 'Access-Control-Allow-Headers' from CORS preflight channel
```

무엇이 잘못되었나요?
-----------

`Access-Control-Allow-Headers` 헤더는 CORS 요청에 대해 지원하는 헤더를 알 수 있도록 서버에서 전송됩니다. `Access-Control-Allow-Headers` 값은 "`X-Custom-Information`" 또는 표준이지만 기본이 아닌 헤더 이름(항상 허용됩니다)과 같은 헤더 이름의 쉼표로 구분된 목록이어야 합니다.

이 오류는 명시적으로 허용되지 않은 헤더(즉, 서버에서 보낸 `Access-Control-Allow-Headers` 헤더에 지정된 목록에 포함되지 않는 경우에)를 사전 요청하려고 할 때 발생합니다. 이 문제를 해결하려면, 표시된 헤더를 허용하도록 서버를 갱신하거나, 해당 헤더를 사용하지 않도록 해야 합니다.

같이 보기
-----

* CORS 에러
* 용어 사전: CORS
* CORS 소개
* HTTP 헤더


Reason: Multiple CORS header 'Access-Control-Allow-Origin' not allowed - HTTP

Reason: Multiple CORS header 'Access-Control-Allow-Origin' not allowed
======================================================================

이유
--
```

Reason: Multiple CORS header 'Access-Control-Allow-Origin' not allowed
```

무엇이 잘못되었는가?
-----------

둘 이상의 `Access-Control-Allow-Origin` 헤더가 서버에서 전송되었습니다. 이것은 허용되지 않습니다.

서버에 접근할 수 있는 경우 `Access-Control-Allow-Origin` 헤더의 오리진을 다시 보낼 수 있도록 구현을 변경할 수 있습니다. 브라우저는 하나의 오리진 또는 null 값만 허용하므로 오리진 목록을 보낼 수 없습니다.

같이보기
----

* CORS 에러
* Glossary: CORS
* CORS 소개
* CORS 사용: 내 서버에 CORS를 추가하고 싶다면


Reason: CORS request external redirect not allowed - HTTP

Reason: CORS request external redirect not allowed
==================================================

이유
--
```

Reason: CORS request external redirect not allowed
```

무엇이 잘못되었나요?
-----------

CORS 요청이 CORS 요청 중에 허용되지 않는 원래 요청과 다른 출처의 URL에 대한 HTTP 리디렉션으로 서버에 의해 응답되었습니다.

예를 들어, `https://service.tld/fetchdata` 페이지가 요청되고, HTTP 응답은 "301 영구적으로 이동됨", "307 임시 리디렉션" 또는 "308 영구 리디렉션" 이고 `Location`이 `https://anotherservice.net/getdata`인 경우, 이러한 방식의 CORS 요청은 실패합니다.

문제를 해결하려면, 리디렉션에서 보고된 새 URL을 사용하도록 코드를 갱신하세요. 따라서 리디렉션을 피할 수 있습니다.

같이 보기
-----

* CORS 에러
* 용어 사전: CORS
* CORS 소개


Reason: expected 'true' in CORS header 'Access-Control-Allow-Credentials' - HTTP

Reason: expected 'true' in CORS header 'Access-Control-Allow-Credentials'
=========================================================================

이유
--
```

Reason: expected 'true' in CORS header 'Access-Control-Allow-Credentials'
```

무엇이 문제인가요?
----------

CORS 요청은 서버가 자격 증명 사용을 허용하도록 요구하지만, 서버의 `Access-Control-Allow-Credentials` 헤더의 값이 `true`로 설정되지 않아 사용할 수 없습니다.

클라이언트 측에서 이 문제를 해결하려면, 자격 증명 사용을 요청하지 않도록 코드를 수정하세요.

* `XMLHttpRequest`를 통해서 요청을 생성하는 경우, `withCredentials` (en-US)를 `true`로 설정하지 않았는지 확인합니다.
* 서버 전송 이벤트를 사용하는 경우, `EventSource.withCredentials` (en-US)이 `false`인지 확인합니다(기본값입니다).
* Fetch API를 사용하는 경우, `Request.credentials` 가 `"omit"`인지 확인합니다.

서버의 구성을 변경하여 이 오류를 제거하려면, 서버의 `Access-Control-Allow-Credentials` 헤더 값을 `true`로 설정합니다.

함께 보기
-----

* CORS 에러
* 용어 사전: CORS
* CORS 소개


Reason: CORS preflight channel did not succeed - HTTP

Reason: CORS preflight channel did not succeed
==============================================

원인
--
```

원인: CORS preflight 연결에 성공하지 못했습니다.
```

무엇이 문제인가요?
----------

CORS 요청에 preflight가 필요하며 preflight를 수행할 수 없습니다. preflight가 실패할 수 있는 몇 가지 이유가 있습니다.

* 이전에 이미 preflight를 수행한 교차 사이트 요청이 수행되었으며 preflight를 다시 수행하는 것은 허용되지 않습니다. 코드가 연결당 한 번씩만 preflight를 수행하는지 확인하십시오.
* 실행 전 요청에 일반적으로 발생할 수 있는 모든 종류의 네트워킹 오류가 발생했습니다.
더보기
---

* CORS 에러
* Glossary: CORS
* CORS 소개


431 Request Header Fields Too Large - HTTP

431 Request Header Fields Too Large
===================================

HTTP **`431 Request Header Fields Too Large`** 응답 코드는 HTTP 헤더의 크기가 너무 크기 때문에 처리가 불가능함을 알려준다. 요청 헤더의 크기를 줄인 후, 재요청을 할 수 있다.

431는 헤더 전체의 크기가 너무 크거나, 단일 헤더 필드가 너무 클 경우에 사용된다. 이 에러를 받는 유저를 위해 응답 body에 둘 중에 어느 경우인지 명시해줄 수 있다 — 이상적으로, 어느 헤더가 처리 불가능한지 알려주면 좋다. 그러면 쿠키를 삭제하는 것과 같이 유저가 문제를 해결할 수 있도록 도와준다.

서버가 431 상태 코드를 전송할 경우:

* `Referer` URL이 너무 긴 경우
* 요청에 많은 양의 Cookies 포함된 경우
Status
------
```

431 Request Header Fields Too Large
```

명세서
---

| Specification |
| --- |
| RFC 6585 # section-5 |

See also
--------

* `414 URI Too Long`
* Request header


307 Temporary Redirect - HTTP

307 Temporary Redirect
======================

HTTP **`307 Temporary Redirect`** 리다이렉트 상태 응답 코드는 요청한 리소스가 `Location` (en-US) 헤더에 주어진 URL 로 임시로 옮겨졌다는 것을 나타냅니다.

원래 요청한 메소드와 Body 를 재사용하여 요청을 리다이렉트 합니다. 여기서 메소드를 `GET`으로 바꾸기 위해서 `303 See Other`를 사용하시면 됩니다. 이것은 `PUT`요청에 업로드된 리소스가 아닌 "You successfully uploaded XYZ"와 같은 확인메시지 응답을 제공 하는데에 유용합니다.

`307`과 `302`가 유일하게 다른점은 `307`은 Method 와 Body 를 변경하지 않고 리다이렉트 요청을 하도록 보장합니다. `302`응답으로 인하여 일부 오래된 클라이언트들은 메소드를 `GET`으로 틀리게 변경하였습니다. GET이 아닌 다른 메소드에 `302`동작은 웹에서 예상되지 않지만 `307` 동작은 예상할수 있습니다. GET 요청에 대해서는 동일하게 동작 합니다.

상태
--
```

307 Temporary Redirect
```

명세
--

| Specification |
| --- |
| HTTP Semantics # status.307 |

브라우저 호환성
--------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

같이 보기
-----

* `302 Found`, the equivalent of this status code, but that may change the method used when it is not a `GET`.
* `303 See Other`, a temporary redirect that changes the method used to `GET`.
* `301 Moved Permanently`, a permanent redirect


400 Bad Request - HTTP

400 Bad Request
===============

HyperText Transfer Protocol (HTTP) **`400 Bad Request`** 응답 상태 코드는 서버가 클라이언트 오류(예: 잘못된 요청 구문, 유효하지 않은 요청 메시지 프레이밍, 또는 변조된 요청 라우팅) 를 감지해 요청을 처리할 수 없거나, 하지 않는다는 것을 의미합니다.

**경고:** 클라이언트는 요청을 수정하지 않고 동일한 형태로 다시 보내서는 안됩니다.

Status
------
```

400 Bad Request
```

명세서
---

| Specification |
| --- |
| HTTP Semantics # status.400 |


429 Too Many Requests - HTTP

429 Too Many Requests
=====================

HTTP **`429 Too Many Requests`** 응답 상태 코드는 사용자가 주어진 시간 동안 너무 많은 요청을 보냈음을 나타냅니다("속도 제한").

새로운 요청을 하기 전에 얼마나 오래 대기해야 하는지를 알려주는 `Retry-After` 헤더가 이 응답에 포함될 수 있습니다.

상태
--
```

429 Too Many Requests
```

예제
--

```http
HTTP/1.1 429 Too Many Requests
Content-Type: text/html
Retry-After: 3600
```

명세서
---

| Specification |
| --- |
| RFC 6585 # section-4 |

같이 보기
-----

* `Retry-After`
* HTTP/1.1: Status Code Definitions
* Python solution: How to avoid HTTP error 429 python


418 I'm a teapot - HTTP

418 I'm a teapot
================

HTTP **`418 I'm a teapot`** 클라이언트 오류 응답 코드는 서버가 찻주전자이기 때문에 커피 내리기를 거절했다는 것을 의미합니다. 일시적으로 커피가 없는 커피/차 주전자는 대신 503을 반환해야 합니다. 이 오류는 1998년과 2014년 만우절 농담이었던 하이퍼 텍스트 커피 주전자 제어 규약(Hyper Text Coffee Pot Control Protocol)에 대한 참조입니다.

일부 웹사이트는 자동화된 쿼리와 같이 처리하고 싶지 않은 요청에 대해 이 응답을 사용합니다.

상태
--

```http
418 I'm a teapot
```

명세서
---

| Specification |
| --- |
| RFC 2324 # section-2.3.2 |

브라우저 호환성
--------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

같이 보기
-----

* Wikipedia Hyper Text Coffee Pot Control Protocol


201 Created - HTTP

201 Created
===========

HTTP **`201 Created`** 는 요청이 성공적으로 처리되었으며, 자원이 생성되었음을 나타내는 성공 상태 응답 코드입니다. 응답이 반환되기 이전에 새로운 리소스가 생성되며, 응답 메시지 본문에 새로 만들어진 리소스 혹은 리소스에 대한 설명과 링크를 메시지 본문에 넣어 반환합니다. 그 위치는 요청 URL 또는 `Location` (en-US) 헤더 값의 URL 입니다.

이 상태 코드의 일반적인 사용 사례는 `POST` 요청에 대한 결과입니다.

상태
--

```http
201 Created
```

명세
--

| Specification |
| --- |
| HTTP Semantics # status.201 |

브라우저 호환성
--------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

같이 보기
-----

* HTTP request methods


404 Not Found - HTTP

404 Not Found
=============

 HTTP **`404 Not Found`** 클라이언트 오류 응답 코드는 서버가 요청받은 리소스를 찾을 수 없다는 것을 의미합니다.
 404 페이지를 띄우는 링크는 대체로 브로큰 링크(broken link) 또는 데드 링크(dead link)라고 부르며,
 link rot 대상일 수도 있습니다.

 404 상태 코드는 리소스가 일시적, 또는 영구적으로 사라졌다는 것을 의미하지는 않습니다. 리소스가 영구적으로 삭제되었다면
 404 상태 코드 대신 `410` (Gone) 상태 코드가 쓰여야 합니다.

상태
--

```http
404 Not Found
```

사용자 지정 에러 페이지
-------------

 많은 웹사이트들이 사용자에게 더 많은 도움을 주기 위해 404 페이지의 모습을 알맞게 재단합니다.
 예를 들어, 아파치 서버는 `.htaccess` 파일에 아래와 같은 코드를 작성해 설정할 수 있습니다.
```

ErrorDocument 404 /notfound.html
```

사용자 지정 404 페이지의 예시로는 404 page을 참고해보세요.

**참고:** 적당한 사용자 지정 디자인은 좋습니다. 404 페이지를 재밌게 만들되, 사용자를 혼란스럽게 하지는 마세요.

명세서
---

| Specification |
| --- |
| HTTP Semantics # status.404 |

브라우저 호환성
--------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

같이 보기
-----

* `410`
* HTTP\_404


303 See Other - HTTP

303 See Other
=============

 HTTP(HyperText Transfer Protocol) **`303 See Other`** 리디렉션 상태 응답 코드는 리디렉션이 요청한
 리소스 자체에 연결되지 않고 다른 페이지(예: 확인 페이지, 실제 개체 표시(HTTP range-14 참조) 또는 업로드 진행률 페이지)에 연결됨을 나타냅니다.
 이 응답 코드는 `PUT` 또는 `POST`의 결과로 다시 전송되는 경우가 많습니다.
 이 리디렉션 페이지를 표시하는 데 사용되는 방법은 항상 `GET`입니다.

상태
--

```http
303 See Other
```

명세서
---

| Specification |
| --- |
| HTTP Semantics # status.303 |

브라우저 호환성
--------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

같이 보기
-----

* `302 Found`, a temporary redirect
* `307 Temporary Redirect`, 사용된 메서드가 절대 변경되지 않는 이
 상태 코드와 동일합니다.


205 Reset Content - HTTP

205 Reset Content
=================

HTTP의 **`205 Reset Content`** 응답상태는 form의 내용을 지우거나, 캔버스 상태를 재설정하거나, UI를 새로 고치려면 client의 문서 화면 요소를 새로고침하라고 알려준다.

상태
--

```http
205 Reset Content
```

명세
--

| Specification |
| --- |
| HTTP Semantics # status.205 |

브라우저 호환성
--------

* 이 응답에 영속적인 연결의 본문이 잘못 포함된 경우 브라우저 동작이 달라집니다.
 자세한 내용은 204 No Content을 참조하세요.
같이 보기
-----

* `204` No Content


502 Bad Gateway - HTTP

502 Bad Gateway
===============

하이퍼텍스트 전송 프로토콜(HTTP) **`502 Bad Gateway`** 에러 응답코드는 서버가 게이트웨이나 프록시 서버 역할을 하면서 업스트림 서버로부터 유효하지 않은 응답을 받았다는 것을 의미합니다.

**참고:** Gateway 는 네트워킹에서 다른 것을 가르킬 수 있고 502 에러는 보통 여러분이 수정할 수 있는 것이 아니지만, 여러분이 접근하려고 하는 웹 서버 혹은 프록시의 수정이 필요합니다.

상태
--

```http
502 Bad Gateway
```

명세서
---

| Specification |
| --- |
| HTTP Semantics # status.502 |

브라우저 호환성
--------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

같이 보기
-----

* `504`
* HTTP/1.1: Status Code Definitions


410 Gone - HTTP

410 Gone
========

 하이퍼텍스트 전송 규약(HTTP) **`410 Gone`** 클라이언트 에러 응답 코드는 원본 서버에서 대상 리소스에 대해 더 이상 접근할 수
 없으며, 이 상태가 영구적일 가능성이 있음을 의미합니다.

이 상태가 일시적인지 영구적인지 알 수 없는 경우 `404` 상태 코드를 대신 사용해야 합니다.

**참고:** 410 응답은 기본적으로 캐시 가능합니다.

상태
--

```http
410 Gone
```

명세서
---

| Specification |
| --- |
| HTTP Semantics # status.410 |

브라우저 호환성
--------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

같이 보기
-----

* `404`
* 410 gone


408 Request Timeout - HTTP

408 Request Timeout
===================

HyperText Transfer Protocol (HTTP) **`408 Request Timeout`** 응답 상태 코드는 서버가 사용하지 않는 연결을 끊고 싶다는 것을 의미한다. 서버가 클라이언트의 요청 없이도 유휴 상태의 연결에 전송한다.

`408`은 서버가 계속해서 기다리기보다는 연결을 종료하기로 결정했다는 것을 알려주기 때문에, 서버는 응답에 "close" `Connection`헤더 필드를 추가해서 전송해야한다.

크롬, Firefox 27+, 그리고 인터넷 익스플로러 9와 같은 브라우저들이 서핑 속도를 높이기 위해 HTTP pre-connection 방식을 사용하기 때문에 이 응답이 더 많이 사용되고 있다.

**참고:** **Note: 어떤 서버들은 이 메세지를 전송하지 않고 연결을 종료할 수도 있다**.

Status
------
```

408 요청 시간 만료
```

명세서
---

| Specification |
| --- |
| HTTP Semantics # status.408 |

See also
--------

* `Connection`
* `X-DNS-Prefetch-Control` (en-US)


103 Early Hints - HTTP

103 Early Hints
===============

**실험적:** **이 기능은 실험적인 기능입니다.**
프로덕션 환경에서 사용하기 전에 브라우저 호환성 표를 주의 깊게 확인하세요.

 HTTP **`103 Early Hints`** 정보 상태 응답 코드는 서버가 응답을 준비하는 동안에도 사용자 에이전트가
 리소스를 미리읽어들일 수 있도록, 주로 `Link` (en-US) 헤더와 함께 사용됩니다.

상태
--

```http
103 Early Hints
```

명세서
---

| Specification |
| --- |
| An HTTP Status Code for Indicating Hints # section-2 |
| HTML Standard # early-hints |

브라우저 호환성
--------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

같이 보기
-----

* `Link` (en-US)


414 URI Too Long - HTTP

414 URI Too Long
================

HTTP **`414 URI Too Long`** 응답 코드는 클라이언트가 요청한 URI가 서버가 해석가능한 URI보다 더 길다는 것을 나타냅니다.

이 문제가 발생할 수 있는 몇 가지 보기 드문 상황이 있습니다.

* 클라이언트가 `POST` 요청을 부적절하게 긴 쿼리 정보를 가진 `GET` 요청으로 변환한 경우
* 클라이언트가 리디렉션 루프(예: 자신의 접미사를 가리키는 리디렉션된 URI 접두사)에 빠진 경우
* 또는 서버의 잠재적인 보안 허점을 악용하려는 클라이언트의 공격을 받는 경우
상태
--
```

414 URI Too Long
```

명세
--

| Specification |
| --- |
| HTTP Semantics # status.414 |

같이 보기
-----

* URI


425 Too Early - HTTP

425 Too Early
=============

하이퍼텍스트 전송 프로토콜(HTTP) **`425 Too Early`** 응답 상태 코드는 서버가 재전송 될 수 있는 요청을 처리하는 데 위험을 감수하기를 원하지 않으며, 이는 재전송 공격(replay attack)의 가능성을 만들 수 있다는 것을 나타냅니다.

상태
--

```http
425 Too Early
```

명세서
---

| Specification |
| --- |
| Using Early Data in HTTP # status |

브라우저 호환성
--------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.


411 Length Required - HTTP

411 Length Required
===================

 하이퍼텍스트 전송 규약(HTTP) **`411 Length Required`** 클라이언트 오류 응답 코드는 서버가 정의된
 `Content-Length` 헤더 없이 요청을 수락하지 않음을 나타냅니다.

**참고:** 사양에 따라 데이터를 일련의 큰 덩어리(chunk) 단위로 데이터를 전송할 때 `Content-Length` 헤더가 생략되며,
 각 청크의 시작 부분에서 현재 청크의 길이를 16진수 형식으로 추가해야 합니다. 자세한 내용은
 `Transfer-Encoding`을 참조하십시요.

상태
--

```http
411 Length Required
```

정의
--

| Specification |
| --- |
| HTTP Semantics # status.411 |

참고
--

* `Content-Length`
* `Transfer-Encoding`


409 Conflict - HTTP

409 Conflict
============

HTTP **`409 Conflict`** 응답 상태 코드는 서버의 현재 상태와 요청이 충돌했음을 나타냅니다.

 충돌은 `PUT` 요청에 대응하여 발생할 가능성이 가장 높습니다. 예를 들어 서버에 이미 있는 파일보다 오래된 파일을
 업로드하면 버전 제어 충돌이 발생하여 409 응답받을 수 있습니다.

상태
--

```http
409 Conflict
```

명세서
---

| Specification |
| --- |
| HTTP Semantics # status.409 |

브라우저 호환성
--------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

같이 보기
-----

* `PUT`


415 Unsupported Media Type - HTTP

415 Unsupported Media Type
==========================

HTTP **'415 지원되지 않는 미디어 유형'** 클라이언트 오류 응답 코드는 클라이언트가 보낸 페이로드가 지원하지 않는 형식이기 때문에 서버가 요청을 수락하지 않음을 나타냅니다.

형식 문제는 요청에 표시된 `Content-Type` 또는 `Content-Encoding`으로 인해 발생하거나 데이터를 직접 검사한 결과 발생할 수 있습니다.

상태
--
```

415 Unsupported Media Type
```

명세서
---

| Specification |
| --- |
| HTTP Semantics # status.415 |

같이 보기
-----

* `Content-Type`
* `Content-Encoding`
* `Accept`


424 Failed Dependency - HTTP

424 Failed Dependency
=====================

하이퍼텍스트 전송 프로토콜(HTTP) **`424 Failed Dependency`** 응답 상태 코드는 요청한 동작이 다른 동작에 의존하며 해당 동작이 실패한 경우에 해당 리소스에서 메서드를 수행할 수 없음을 나타냅니다.

보통 일반 웹 서버에서는 이 상태 코드를 반환하지 않습니다. 하지만 WebDAV와 같은 일부 다른 프로토콜에서는 이 코드를 반환할 수 있습니다. 예를 들어, WebDAV에서 `PROPPATCH` 요청을 보냈을 때 하나의 명령이 실패하면 자동으로 다른 모든 명령도 `424 Failed Dependency`로 실패합니다.

상태
--

| Specification |
| --- |
| RFC 4918 # section-11.4 |

같이 보기
-----

* `403` (Forbidden)


401 Unauthorized - HTTP

401 Unauthorized
================

 HTTP(하이퍼텍스트 전송 프로토콜) **`401 Unauthorized`** 응답 상태 코드는 요청된 리소스에 대한
 유효한 인증 자격 증명이 없기 때문에 클라이언트 요청이 완료되지 않았음을 나타냅니다.

 이 상태 코드는 사용자에게 인증 자격 증명을 입력하라는 메시지를 표시한 후 클라이언트가 리소스를 다시 요청할 수 있는
 방법이 포함된 HTTP `WWW-Authenticate` (en-US) 응답 헤더와 함께 전송됩니다.

 이 상태 코드는 `403 Forbidden` 상태 코드와 유사합니다.
 다만 이 상태 코드가 발생하는 상황에서 사용자 인증을 통해 리소스에 대한 액세스를 허용할 수 있습니다.

상태
--

```http
401 Unauthorized
```

응답 예시
-----

```http
HTTP/1.1 401 Unauthorized
Date: Wed, 21 Oct 2015 07:28:00 GMT
WWW-Authenticate: Basic realm="Access to staging site"
```

명세서
---

| Specification |
| --- |
| HTTP Semantics # status.401 |

브라우저 호환성
--------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

같이 보기
-----

* HTTP 인증
* `WWW-Authenticate` (en-US)
* `Authorization`
* `Proxy-Authorization` (en-US)
* `Proxy-Authenticate` (en-US)
* `403`, `407` (en-US)


200 OK - HTTP

200 OK
======

HTTP **`200 OK`** 는 요청이 성공했음을 나타내는 성공 응답 상태 코드입니다. 200 응답은 기본적으로 캐시 가능합니다.

성공의 의미는 다음과 같이 HTTP 요청 메서드에 따라 나뉩니다.

* `GET`: 리소스를 가져왔고 메시지 본문으로 전송되었다는 것을 의미합니다.
* `HEAD`: 메시지 본문 없이 표현 헤더가 응답에 포함되어 있다는 것을 의미합니다.
* `POST`: 리소스가 명시하는 행동의 결과가 메시지 본문에 전송되었다는 것을 의미합니다.
* `TRACE` (en-US): 서버가 요청받은 메시지가 메시지 본문에 포함되어 있다는 것을 의미합니다.

`PUT` 또는 `DELETE`의 성공 결과는 종종 `200 OK`가 아니라 `204` `No Content`(리소스를 새로 생성한 경우 `201` `Created` 입니다).

상태
--

```http
200 OK
```

명세
--

| Specification |
| --- |
| HTTP Semantics # status.200 |

브라우저 호환성
--------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

같이 보기
-----

* HTTP 요청 메서드


405 Method Not Allowed - HTTP

405 Method Not Allowed
======================

 하이퍼텍스트 전송 프로토콜(HTTP)의 **`405 Method Not Allowed`** 응답 상태 코드는 서버가 요청 메서드를 알고 있지만
 대상 리소스가 이 메서드를 지원하지 않음을 가리킵니다.

 서버는 405 코드를 응답할 경우 **반드시** **`Allow`** 헤더 필드를 생성해야 합니다. 이 필드에는 반드시 현재 대상 리소스에서
 지원하는 메서드의 리스트가 들어있어야 합니다.

상태
--

```http
405 Method Not Allowed
```

명세서
---

| Specification |
| --- |
| HTTP Semantics # status.405 |

같이 보기
-----

* `Allow`
* HTTP/1.1: Status Code Definitions
* How to Fix 405 Method Not Allowed
* Troubleshooting HTTP 405
 Footer


302 Found - HTTP

302 Found
=========

 HTTP(HyperText Transfer Protocol) **`302 Found`** 리디렉션 상태 응답 코드는 요청한 리소스가
 `Location` (en-US) 헤더에 지정된 URL로 일시적으로 이동되었음을 나타냅니다. 브라우저는 이 페이지로
 리디렉션되지만 검색 엔진은 리소스에 대한 링크를 업데이트하지 않습니다('SEO-speak'에서는 'link-juice'가 새
 URL로 전송되지 않는다고 합니다).

 명세서에서 리디렉션이 수행될 때 메서드(및 본문)가 변경되지 않도록 요구하더라도 모든 사용자 에이전트가 이를 준수하는
 것은 아닙니다. 여러분은 여전히 이러한 유형의 버그가 있는 소프트웨어를 찾을 수 있습니다. 따라서 따라서 `302` 코드는
 `GET` 또는 `HEAD` 메서드에 대한 응답으로만 설정하고 이 경우 메서드
 변경이 명시적으로 금지되므로 `307 Temporary Redirect` 를 대신 사용하는 것이
 좋습니다.

 사용하던 메서드를 `GET`으로 변경하려는 경우,
 `303 See Other`을 대신 사용하십시오.
 `PUT` 메서드에 대한 응답을 업로드된 리소스가 아니라 'You successfully updown XYZ'와
 같은 확인 메시지로 주고 싶을때 유용합니다.

상태
--

```http
302 Found
```

명세서
---

| Specification |
| --- |
| HTTP Semantics # status.302 |

브라우저 호환성
--------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

같이 보기
-----

* `307 Temporary Redirect`, 사용된 메서드가 절대 변경되지 않는 이 상태 코드와 동일합니다.
* `303 See Other`, `GET`에 사용되는 메서드를 변경하는 임시 리디렉션입니다.
* `301 Moved Permanently`, 영구 리다이렉션


204 No Content - HTTP

204 No Content
==============

 HTTP **`204 No Content`** 성공 상태 응답 코드는 요청이 성공했으나 클라이언트가
 현재 페이지에서 벗어나지 않아도 된다는 것을 나타냅니다.

 예를 들어, 위키 사이트에 "저장 후 편집 계속" 기능을 구현할 때 사용할 수 있습니다.
 이 경우 `PUT` 요청을 사용하여 페이지를 저장하고 `204 No Content` 응답을 전송하여
 편집기를 다른 페이지로 대체해서는 안 된다는 것을 나타냅니다.

204 응답은 기본적으로 캐시 가능하며, 캐시에서 가져온 응답인 경우 `ETag` 헤더를 포함합니다.

상태
--

```http
204 No Content
```

명세서
---

| Specification |
| --- |
| HTTP Semantics # status.204 |

브라우저 호환성
--------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

호환성 참고사항
--------

* 이 상태코드는 본문 없는 응답을 위한 상태 코드이지만, 서버에서 잘못되게 본문을 포함한 응답을 전달하는 경우가
 존재할 수 있습니다. 이 프로토콜은 사용자 에이전트 다양한 방법으로 처리하는 것을 허용하고 있습니다.
 이 명세에 대한 토론은 여기서 확인할 수 있습니다.
 보통 지속 연결에서 볼 수 있는 문제로, 잘못 포함된 본문이 이후 요청에 대한 별도의 응답을 담고 있을 수 있습니다.
 Apple Safari는 잘못 포함된 모든 데이터를 거부합니다. Google Chrome과 Microsoft Edge는 잘못된 데이터의
 최대 4바이트를 검사한 후, 유효한 별도의 요청을 찾지 못한 경우 폐기합니다. Firefox는 1킬로바이트 이상을 검사합니다.
같이 보기
-----

* HTTP 요청 메서드


503 Service Unavailable - HTTP

503 Service Unavailable
=======================

하이퍼텍스트 전송 프로토콜(HTTP) **`503 Service Unavailable`** 서버 에러 응답 코드는 서버가 요청을 처리할 준비가 되지 않은 것을 의미합니다.

흔하게는 서버가 점검을 위해 다운되거나 과부하 때문에 발생합니다. 이 응답은 일시적인 상황을 위해 사용되어야 하며, `Retry-After` HTTP 헤더는 가능하다면 서비스 복구를 위한 예상 시간을 포함해야 합니다.

**참고:** 이 응답(response)과 함께, 이 문제에 대해 설명하는 사용자 친화적 페이지가 전달되어야 합니다.

503 상태는 종종 일시적인 상황이며 응답은 일반적으로 캐시되지 않아야 하므로, 이 응답과 함께 전달되는 캐싱 관련 헤더들은 주의 깊게 다루어져야 합니다.

상태
--

```http
503 Service Unavailable
```

명세서
---

| Specification |
| --- |
| HTTP Semantics # status.503 |

브라우저 호환성
--------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

같이 보기
-----

* `Retry-After`
* HTTP/1.1: Status Code Definitions


422 Unprocessable Content - HTTP

422 Unprocessable Content
=========================

하이퍼텍스트 전송 프로토콜(HTTP) **`422 Unprocessable Content`** 응답 상태 코드는 서버가 요청 엔티티의 컨텐츠 형식을 이해했고 요청 엔티티의 문법도 올바르지만 요청된 지시를 처리할 수 없음을 나타냅니다.

**경고:** 클라이언트는 요청을 수정하지 않고 동일한 형태로 다시 보내서는 안됩니다.

상태
--

```http
422 Unprocessable Content
```

명세서
---

| Specification |
| --- |
| HTTP Semantics # status.422 |


413 Content Too Large - HTTP

413 Content Too Large
=====================

HTTP **`413 Content Too Large`** 응답 상태 코드는 요청 엔터티가 서버에 의해 정의된 제한보다 크다는 것을 나타냅니다. 서버는 연결을 닫거나 `Retry-After` 헤더 필드를 반환할 수 있습니다.

RFC 9110 이전에는 이 상태 코드 이름이 **`Payload Too Large`** 였습니다. 이 이름은 아직도 널리 사용되고 있습니다.

상태
--

```http
413 Content Too Large
```

명세서
---

| Specification |
| --- |
| HTTP Semantics # status.413 |

같이 보기
-----

* `Connection`
* `Retry-After`


100 Continue - HTTP

100 Continue
============

 HTTP **`100 Continue`** 정보 상태 응답 코드는 클라이언트가 서버로 보낸 요청에 문제가 없으니 다음 요청을
 이어서 보내도 된다는 것을 의미합니다. 만약 클라이언트의 작업이 완료되었다면 이 응답은 무시해도 됩니다.

 클라이언트가 서버로 하여금 이를 검토하게 하려면 첫 번째 요청에서 `Expect``: 100-continue`를
 헤더로 보내야 합니다. 이후, 클라이언트는 본문을 보내기 전에 서버가 `100 Continue` 상태 코드로 응답하길 기다려야 합니다.

상태
--

```http
100 Continue
```

명세서
---

| Specification |
| --- |
| HTTP Semantics # status.100 |

브라우저 호환성
--------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

같이 보기
-----

* `Expect`
* `417` (en-US)


426 Upgrade Required - HTTP

426 Upgrade Required
====================

 HTTP **`426 Upgrade Required`** 클라이언트 에러 응답 코드는 서버가 현재 프로토콜을 사용하여 요청을 처리하는 것은
 거부하지만 클라이언트가 다른 프로토콜로 업그레이드한 후에는 요청을 수행할 의향이 있음을 나타냅니다.

서버는 필요한 하나 이상의 프로토콜을 나타내기 위해 이 응답에 `Upgrade` (en-US) 헤더를 같이 보냅니다.

상태
--

```http
426 Upgrade Required
```

예제
--

```http
HTTP/1.1 426 Upgrade Required
Upgrade: HTTP/2.0
Connection: Upgrade
Content-Length: 53
Content-Type: text/plain
This service requires use of the HTTP/2.0 protocol
```

명세
--

| Specification |
| --- |
| HTTP Semantics # status.426 |

같이 보기
-----

* `Upgrade` (en-US)
* `101` `Switching Protocols`


308 Permanent Redirect - HTTP

308 Permanent Redirect
======================

 하이퍼텍스트 전송 프로토콜 (HTTP) **`308 Permanent Redirect`** 리디렉션 상태 응답 코드는 요청된 리소스가
 `Location` (en-US) 헤더에 지정된 URL로 확실히 이동되었음을 나타냅니다. 브라우저가 이 페이지로 리디렉션되고 검색엔진은 리소스에 대한 링크를 업데이트합니다('SEO-speak'에서는 'link-juice'가 새 URL로 전송됩니다).

요청 메서드와 본문은 변경되지 않지만, `301`은 때때로 `GET` 메서드로 잘못 변경될 수 있습니다.

**참고:** 일부 웹 응용 프로그램은
 `308 Permanent Redirect`를 비표준 방식 및 기타 목적으로 사용합니다.
 예를 들어, Google Drive는 `308 Resume Incomplete` 응답을 사용하여 불완전한 업로드가 중단된 경우 클라이언트에 알립니다(Google Drive 문서의 다시 시작할 수 있는 다운로드 수행을 참조하세요).

상태
--

```http
308 Permanent Redirect
```

명세
--

| Specification |
| --- |
| HTTP Semantics # status.308 |

브라우저 호환성
--------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

함께 보기
-----

* `301 Moved Permanently`, 이 상태 코드와 동일하지만, `GET`이 아닐 때 사용되는 메서드를 변경합니다.
* `302 Found`, 임시 리디렉션


304 Not Modified - HTTP

304 Not Modified
================

클라이언트 리디렉션 응답 코드 **`304 Not Modified`** 는 요청된 리소스를 재전송할 필요가 없음을 나타낸다. 캐시된 자원으로의 암묵적인 리디렉션이다. 이 는 `GET` 나 `HEAD` 요청처럼 요청 방법이 안전 한 경우 또는 요청이 조건부로 `If-None-Match` 또는 `If-Modified-Since` 헤더를 사용할 때 응답 된다.

이에 상응하는 `200` `OK` 응답에는 `Cache-Control`, `Content-Location`, `Date`, `ETag`, `Expires`, 그리고 `Vary` 가 포함되어 있었을 것이다.

**참고:** 브라우저의 개발자도구 네트워크 패널은 304 응답으로 이어지는 많은 요청을 생성하며, 로컬 캐시로 액세스 하는 것을 개발자에게 보여준다.

상태
--
```

304 Not Modified
```

명세
--

| Specification |
| --- |
| HTTP Semantics # status.304 |

브라우저 호환성
--------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

호환성 노트
------

* 이 응답에 영구 연결의 본문이 잘못 포함되어 있으면 브라우저 동작이 다릅니다. 자세한 내용은 204 No Content을(를) 참조하십시오.
같이 보기
-----

* `If-Modified-Since`
* `If-None-Match`


403 Forbidden - HTTP

403 Forbidden
=============

HTTP **`403 Forbidden`** 클라이언트 오류 상태 응답 코드는 서버에 요청이 전달되었지만, 권한 때문에 거절되었다는 것을 의미합니다.

이 상태는 `401`과 비슷하지만, 로그인 로직(틀린 비밀번호로 로그인 행위)처럼 반응하여 재인증(re-authenticating)을 하더라도 지속적으로 접속을 거절합니다.

상태
--

```http
403 Forbidden
```

응답 예시
-----

```http
HTTP/1.1 403 Forbidden
Date: Wed, 21 Oct 2015 07:28:00 GMT
```

명세
--

| Specification |
| --- |
| HTTP Semantics # status.403 |

브라우저 호환성
--------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

같이 보기
-----

* `401`
* HTTP/1.1: Status Code Definitions


505 HTTP Version Not Supported - HTTP

505 HTTP Version Not Supported
==============================

**`505 HTTP Version Not Supported`** 응답 코드는 요청에 사용된 HTTP 버전을 서버가 지원하지 않음을 의미합니다

상태
--

```http
505 HTTP Version Not Supported
```

명세서
---

| Specification |
| --- |
| HTTP Semantics # status.505 |

같이 보기
-----

* `Upgrade` (en-US)


202 Accepted - HTTP

202 Accepted
============

하이퍼텍스트 전송 프로토콜 (HTTP) **`202 Accepted`** 는 요청이 처리를 위해 수락되었으나, 아직 해당 요청에 대해 처리 중이거나 처리 시작되지 않았을 수 있다는 것을 의미합니다. 요청이 처리 중 실패할 수도 있기 때문에 요청은 실행될 수도 실행되지 않을수도 있습니다.

이 상태 코드는 모호합니다. 즉 HTTP가 나중에 요청 처리 결과를 나타내는 비동기 응답을 보낼 방법이 없다는 것을 의미합니다. 이는 다른 프로세스나 서버가 요청을 처리하는 경우 또는 일괄 처리를 위한 것입니다.

상태
--

```http
202 Accepted
```

명세
--

| Specification |
| --- |
| HTTP Semantics # status.202 |

같이 보기
-----

* `Accept`


300 Multiple Choices - HTTP

300 Multiple Choices
====================

 HTTP **`300 Multiple Choices`** 리디렉션 상태 응답 코드는 요청에 가능한 응답이 두 개 이상 있음을 의미합니다.
 사용자 에이전트 또는 사용자는 둘 중 하나를 선택해야 합니다. 응답 중 하나를 선택하는 표준화된 방법이 없기 때문에 이
 응답 코드는 거의 사용되지 않습니다.

서버는 선호하는 선택 항목이 있는 경우, `Location` (en-US)를 생성해야 합니다.

상태
--

```http
300 Multiple Choices
```

명세서
---

| Specification |
| --- |
| HTTP Semantics # status.300 |

같이 보기
-----

* `301` `Moved Permanently`
* `302` `Found`, 임시 리다이렉션
* `308` `Permanent Redirect`


206 Partial Content - HTTP

206 Partial Content
===================

HTTP **`206 Partial Content`** 는 `Range` 헤더에 기술된 데이터 범위에 대한 요청이 성공적으로 응답되어 본문에 해당되는 데이터를 담고 있다는 것을 알려줍니다.

만약 단일 범위 요청을 한 경우엔, 전체 응답의 `Content-Type`은 문서 타입으로 설정되며, `Content-Range`가 제공됩니다.

만약 다중 범위 요청에 대한 응답이라면, `Content-Type`는 `multipart/byteranges`로 되며 분할된 데이터의 응답은 `Content-Range`와 `Content-Type`로 각각의 범위를 기술합니다.

상태
--

```http
206 Partial Content
```

예제
--

응답이 단일 범위를 가지고 있는 경우,

```http
HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 2015 06:25:24 GMT
Last-Modified: Wed, 15 Nov 2015 04:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif

# 26012 bytes of partial image data…
```

응답이 여러 범위를 가지고 있는 경우,

```http
HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 2015 06:25:24 GMT
Last-Modified: Wed, 15 Nov 2015 04:58:08 GMT
Content-Length: 1741
Content-Type: multipart/byteranges; boundary=String\_separator

--String_separator
Content-Type: application/pdf
Content-Range: bytes 234-639/8000

# the first range
--String_separator
Content-Type: application/pdf
Content-Range: bytes 4590-7999/8000

# the second range
--String_separator--
```

명세
--

| Specification |
| --- |
| HTTP Semantics # status.206 |

브라우저 호환성
--------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

함께 참고할 내용
---------

* `If-Range`
* `Range`
* `Content-Range`
* `Content-Type`


501 Not Implemented - HTTP

501 Not Implemented
===================

 하이퍼텍스트 전송 프로토콜(HTTP) **`501 Not Implemented`** 서버 응답 코드는
 **요청을 수행할 수 있는 기능을 서버가 지원하지 않는다**는 것을 의미합니다.

 서버에서 추후 기능이 지원된다면 요청자에게 다시 확인해볼 수 있는 시점을 알려줄 수 있도록
 `Retry-After` 헤더를 전송해줄 수 있습니다.

`501` 은 서버가 요청 방법을 이해하지 못하거나 어떤 리소스를 지원하지 않은 경우에 적절합니다. 서버가 필수적으로 지원하는 메서드에는
 `GET` 와 `HEAD`가 있습니다.

 서버가 메서드를 이해하지만 고의적으로 지원하지 않는 경우에는 `405 Method Not Allowed`
 응답이 적합합니다.

**참고:**

* 501 오류는 사용자가 수정할 수 없고 접근하려는 서버에서 수정이 필요합니다.
* 캐시 헤더가 달리 지시가 있지 않는 이상, 501 응답은 기본적으로 캐시할 수 있습니다.

상태
--

```http
501 Not Implemented
```

명세서
---

| Specification |
| --- |
| HTTP Semantics # status.501 |

브라우저 호환성
--------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.


504 Gateway Timeout - HTTP

504 Gateway Timeout
===================

하이퍼텍스트 전송 프로토콜 (HTTP) **`504 Gateway Timeout`** 서버 에러 응답 코드는 서버가 게이트웨이 혹은 프록시의 역할을 하는 동안 시간 안에 업스트림 서버(upstream server)로부터 요청을 마치기 위해 필요한 응답를 받지 못했음을 나타냅니다.

**참고:** Gateway 는 네트워킹에서 다른 것을 가르킬 수 있고 504 에러는 보통 여러분이 수정할 수 있는 것이 아니지만, 여러분이 접근하려고 하는 웹 서버 혹은 프록시의 수정이 필요합니다.

상태
--

```http
504 Gateway Timeout
```

명세서
---

| Specification |
| --- |
| HTTP Semantics # status.504 |

브라우저 호환성
--------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

같이 보기
-----

* HTTP/1.1: Status Code Definitions
* `502`


203 Non-Authoritative Information - HTTP

203 Non-Authoritative Information
=================================

The HTTP **`203 Non-Authoritative Information`** 는 요청이 성공했지만 오리진 서버의 `200` (`OK`) 응답에서 proxy에 의해 포함된 페이로드가 수정되었음을 나타냅니다.

`203` 응답은 `Warning` (en-US) 헤더 코드의 변환 적용을 의미하는 `214` (en-US) 값과 유사하며, 모든 상태 코드가 있는 응답에 적용할 수 있다는 추가적인 이점이 있습니다.

상태
--

```http
203 Non-Authoritative Information
```

명세
--

| Specification |
| --- |
| HTTP Semantics # status.203 |

같이 보기
-----

* `200`
* Proxy server
* `Warning` (en-US)


406 Not Acceptable - HTTP

406 Not Acceptable
==================

하이퍼텍스트 전송 프로토콜(HTTP)의 **`406 Not Acceptable`** 클라이언트 에러 응답 코드는 서버가 요청의 주도적인 콘텐츠 협상 헤더에 정의된 허용 가능한 값 목록과 일치하는 응답을 생성할 수 없으며, 서버가 기본 표현을 제공하지 않음을 나타냅니다.

주도적인 콘텐츠 협상 헤더는 다음과 같습니다.

* `Accept`
* `Accept-Encoding`
* `Accept-Language`

실제로 이 오류가 사용되는 경우는 거의 드뭅니다. 서버는 최종 사용자에게 이런 비밀스럽고 수정하기 어려운 오류 코드로 응답하는 대신, 관련 헤더를 무시하고 사용자에게 실제 페이지를 제공합니다. 사용자가 이 결과에 완벽하게 만족하진 않더라도, 에러 코드보다는 선호할 것입니다.

서버가 이러한 오류 상태를 반환하는 경우, 메시지 본문에는 사용 가능한 리소스 표현 목록이 포함되어야 하며, 사용자가 그 중에서 선택할 수 있어야 합니다.

상태
--

```http
406 Not Acceptable
```

명세서
---

| Specification |
| --- |
| HTTP Semantics # status.406 |

브라우저 호환성
--------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

같이 보기
-----

* `Accept`
* `Accept-Encoding`
* `Accept-Language`
* HTTP 콘텐츠 협상


301 Moved Permanently - HTTP

301 Moved Permanently
=====================

 HTTP **`301 Moved Permanently`** 리디렉션 상태 응답 코드는 요청한 리소스가
 `Location` (en-US) 헤더에 주어진 URL로 완전히 옮겨졌다는 것을 나타냅니다. 브라우저는 이 페이지로
 리디렉트하고, 검색 엔진은 해당 리소스로 연결되는 링크를 갱신합니다.

**참고:** 명세에서는 리디렉션를 수행할 때 메서드와 본문이 변경되지 않아야 한다고 하지만, 모든 사용자 에이전트가 이 요구사항을 충족하지 않습니다. `301` 코드는 `GET`과 `HEAD` 메서드의 응답으로만 사용하고, `POST` 메서드에 대해서는 메서드 변경이 명시적으로 금지된 `308 Permanent Redirect` 사용이 바람직합니다.

상태
--

```http
301 Moved Permanently
```

예제
--

### 클라이언트 요청

```http
GET /index.php HTTP/1.1
Host: www.example.org
```

### 서버 응답

```http
HTTP/1.1 301 Moved Permanently
Location: http://www.example.org/index.asp
```

명세서
---

| Specification |
| --- |
| HTTP Semantics # status.301 |

브라우저 호환성
--------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

같이 보기
-----

* `308` `Permanent Redirect`, 사용된 메서드가 절대 변경되지 않는 이 상태 코드와 동일합니다.
* `302` `Found`, 임시 리다이렉트


500 Internal Server Error - HTTP

500 Internal Server Error
=========================

 하이퍼텍스트 전송 프로토콜 (HTTP) **`500 Internal Server Error`** 서버 에러 응답 코드는 요청을 처리하는
 과정에서 서버가 예상하지 못한 상황에 놓였다는 것을 나타냅니다.

 이 에러 응답은 "서버 에러를 총칭하는"(catch-all) 일반적인 응답입니다. 보통 이는 서버가 응답할 좀 더 좋은 5xx 에러 코드를
 못 찾은 것을 의미합니다. 종종 서버 관리자들은 미래에 같은 에러를 발생하는 것을 방지하기 위해 500 상태 코드 같은 에러 응답들에
 더 많은 자세한 내용을 남겨 둡니다.

상태
--

```http
500 Internal Server Error
```

명세서
---

| Specification |
| --- |
| HTTP Semantics # status.500 |

브라우저 호환성
--------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

같이 보기
-----

* HTTP/1.1: Status Code Definitions


416 Range Not Satisfiable - HTTP

416 Range Not Satisfiable
=========================

 하이퍼텍스트 트랜스퍼 프로토콜(HTTP) **`416 Range Not Satisfiable`** 에러 응답 코드는 서버가 요청받은 범위에
 대해서 서비스 할 수 없음을 알려줍니다. 아마도 이유는 그 문서가 그러한 범위를 지니고 있지 않거나, 또는
 `Range` 헤더 값이 문법적으로는 옳지만, 이해가 되지 않을 경우 그럴 수 있습니다.

 416 응답 메시지는 `Content-Range` 를 포함하여 만족할 수 없는 범위(그 경우 `'*'`) 뒤에
 `'/'`와 현재 리소스를 알려줍니다. 예: `Content-Range: */12777`

이 에러를 마주하면, 브라우저는 보통 명령을 취소하거나 전체 문서를 다시 요청합니다.

상태
--

```http
416 Range Not Satisfiable
```

명세서
---

| Specification |
| --- |
| HTTP Semantics # status.416 |

브라우저 호환성
--------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

함께 참고할 내용
---------

* `206` `Partial Content`
* `Content-Range`
* `Range`


101 Switching Protocols - HTTP

101 Switching Protocols
=======================

 HTTP **`101 Switching Protocols`** 응답 코드는 서버가 전환되는 프로토콜을 가리킵니다. 프로토콜은
 클라이언트로부터 받은 `Upgrade` (en-US) 헤더에 명시되어 있습니다.

 서버는 이 응답에 전환된 프로토콜을 나타내는 `Upgrade` (en-US) 헤더를 포함합니다. 이 절차는
 프로토콜 업그레이드 메커니즘 (en-US) 문서에 설명되어 있습니다.

상태
--

```http
101 Switching Protocols
```

예제
--

 전환되는 프로토콜은 WebSockets와 함께
 사용할 수 있습니다.

```http
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
```

명세서
---

| Specification |
| --- |
| HTTP Semantics # status.101 |

같이 보기
-----

* 프로토콜 업그레이드 메커니즘 (en-US)
* 웹소켓
* `Upgrade` (en-US)
* `426` `Upgrade Required`


미디어 및 Web Audio API 자동 재생 가이드 - 웹 미디어 기술

미디어 및 Web Audio API 자동 재생 가이드
=============================

페이지가 로드 되자마자 소리(또는 소리가 나는 영상)를 자동으로 재생하는 것은 사용자에게 별로 유쾌한 경험은 아닐겁니다. 미디어 자동 재생이 유용하려면 꼭 필요한 경우에 한하여 조심스럽게 쓰여야 합니다. 사용자가 이를 컨트롤 할 수 있게 여러 브라우저들은 미디어 자동 재생을 막는 기능을 제공하고 있습니다. I본 가이드 문서에서는 다양한 미디어와 Web audio API를 통한 자동 재생 기능에 대해 소개하고 자동 재생을 하는 법과 브라우저의 자동 재생 방지 기능에 깔끔하게 대처하는 법에 대해 알아봅니다.

`<video>` 엘리먼트에 오디어 트랙이 없거나 음소거인 경우에는 자동 재생 방지 기능에 영향받지 않습니다. 활성화된 오디오 트랙을 가진 미디어는 **audible**로 취급하고 자동 재생 방지 기능이 동작합니다. **Inaudible** 미디어는 그렇지 않습니다.

자동 재생과 자동 재생 방지
---------------

**자동 재생(autoplay)** 이라는 용어는 사용자의 재생 요청 없이 오디오를 재생하는 모든 기능을 총칭합니다. HTML attribute를 통해 재생하거나 사용자 입력 외의 코드에서 Javascript를 통해 재생하는 경우을 포합합니다.

이 말은 브라우저는 아래 두 경우 모두를 자동 재생 동작으로 인지하고 자동 재생 방지 기능을 적용한다는 의미입니다:

```html
<audio src="/music.mp4" autoplay></audio>
```

와

```js
audioElement.play();
```

아래 웹 기능과 API는 자동 재생 방지 기능에 영향을 받습니다:

* HTML `<audio>` (en-US), `<video>` 엘리먼트
* Web Audio API

사용자의 입장에서는 웹 페이지나 앱이 의도와 무관하게 소음을 내기 시작하면 불쾌하거나 거슬릴 가능성이 높습니다. 때문에 일반적으로 브라우저는 특정 조건 하에서만 자동 재생이 가능하도록 허용하고 있습니다.

### 자동 재생 가능 여부

일반적으로 아래 *조건 중 하나라도* 해당된다면 자동 재생이 가능하다고 볼 수 있습니다

* 음소거이거나 오디오 볼륨이 0
* 사용자가 사이트와 상호작용 함 (클릭, 터치, 키 누름 등.)
* 화이트리스트에 등록된 사이트; 브라우저가 판단하기에 사용자가 해당 사이트에서 미디어를 자주 재생하거나 수동으로 화이트 리스트에 사이트를 등록한 경우를 포함합니다.
* 자동 재생 정책이 허용으로 지정되어 `<iframe>` (en-US)와 document에서 자동 재생을 지원하는 경우

이외에는 자동 재생이 막힐겁니다. 정확한 차단 케이스나 사이트를 화이트리스트에 등재하는 방식 등은 브라우저마다 모두 다릅니다. 하지만 위의 케이스들이 좋은 가이드라인이 될 수 있겠죠.

자세한 것은 Google Chrome과 WebKit의 자동 재생 정책을 참조하세요.

**참고:** 사용자 인터랙션이 이루어지지 않은 탭에서 오디오가 포함된 미디어를 프로그램적으로 수행하면 일반적으로 차단됩니다. 차단 조건은 브라우저별로 몇 개 더 추가 될 수 있습니다.

미디어 엘리먼트 자동 재생
--------------

이제 자동 재생이 무엇인지, 자동 재생을 방지하는 것은 무엇인지에 대해 자세히 알아봅시다. 자페이지가 로드될 때 어떻게 자동으로 재생하는지, 자동 재생이 실패한 경우를 어떻게 알아내는 지 그리고 브라우저가 자동 재생을 금지한 경우 어떻게 대응할지 알아봅시다.

### autoplay 속성

가장 간단한 자동 재생 방법은 `<audio>` (en-US)나 `<video>` 엘리먼트에 `autoplay` (en-US) 속성을 추가하는 겁니다. 이는 `autoplay` 속성을 `true`로 지정하며, `autoplay`가 `true`면 아래 조건이 만족된 직후부터 자동 재생을 시도합니다:

* 페이지가 자동 재생 기능을 허용할 때
* 페이지 로드 중에 엘리먼트가 생성될 때
* 미디어의 끝까지 문제 없이 재생 가능할 정도로 충분한 데이터가 수신되었으며, 네트워크 품질에 큰 변화가 발생하지 않을 것으로 추정되는 경우.

#### 예제: autoplay 속성

`<audio>` (en-US) 엘리먼트의 `autoplay` 속성을 사용하는 경우는 아래와 같습니다:

```html
<audio id="musicplayer" autoplay>
  <source src="/music/chapter1.mp4" />
</audio>
```

#### 예제 2: 자동재생 실패 탐지

자동 재생 기능이 중요하거나, 자동 재생 실패 시 앱에 큰 영향이 가해진다면, 여러분은 아마도 자동 재생이 실패하는 시점을 알고 싶을겁니다. 안타깝게도 `autoplay` (en-US) 속성을 사용하는 경우, 자동 재생 성공 여부를 알아내는 것이 쉽지 않습니다. 자동 재생 실패 시 발생하는 이벤트가 없기 때문이죠. 게다가 익셉션 또는 콜백, 심지어 자동 재생이 되었을 때 켜지는 플래그조차 없습니다. 여러분이 할 수 있는 건 몇 가지 변수를 체크하거나 경험적으로 자동 재생이 동작했는지 판단할 수 밖에 없습니다.

더 좋은 방법으로는 앱의 동작 방식을 자동 재생 실패를 탐지하기보다 성공을 탐지하는 방향으로 조정하는 것입니다. 이 방법은 간단한데, 미디어 엘리먼트에서 `play (en-US)` 가 발생하길 기다리는 것입니다.

`play` 이벤트는 일시 정지된 후 재생될때와 자동 재생이 동작하는 두 경우 모두 발생합니다. 이 말은 즉 `play` 이벤트가 최초로 발생했다면 페이지가 열린 후 미디어가 처음으로 재생되었다는것을 알 수 있다는 말이죠.

아래 HTML 코드를 확인 해 보세요:

```html
<video src="myvideo.mp4" autoplay onplay="handleFirstPlay(event)"></video>
```

`<video>` 엘리먼트에 `autoplay` 속성이 설정되어 있으며, `onplay` 이벤트 핸들러도 지정되어 있습니다; 이벤트는 `handleFirstPlay()` 함수로 전달되며 `play` 이벤트를 인자로 받습니다.

`handleFirstPlay()` 는 아래와 같습니다:

```js
function handleFirstPlay(event) {
  let vid = event.target;

  vid.onplay = null;

  // Start whatever you need to do after playback has started
}
```

`Event` 객체의 `target` 프로퍼티로 비디오 엘리먼트 참조를 얻은 뒤에, 엘리먼트의 `onplay` 핸들러를 `null`로 세팅합니다. 이렇게 하면 향후 모든 `play` 이벤트가 핸들러로 전달되는 것을 방지합니다. 비디오 일시 정지 후 사용자가 재생하거나 백그라운드 탭으로 전환된 후 브라우저에 의해 자동으로 재생될 때 발생할 수 있습니다.

이 시점에서 여러분의 사이트나 앱은 비디오 시작 후 필요한 모든 작업을 수행할 수 있습니다.

**참고:** autoplay 또는 사용자가 직접 재생하는 경우에도 위 방법은 차이점은 없습니다.

### play() 메소드

사용자 입력 이벤트에서 시작된 컨텍스트 밖에서 오디오가 포함된 미디어를 재생하는 시나리오도 자동 재생(autoplay)라 부릅니다. 미디어 엘리먼트의 `play()` (en-US) 메소드를 호출하면 가능합니다.

**참고:** 가능하다면 `autoplay` 속성을 사용하는 걸 항상 추천합니다. 왜냐면 다른 방식으로 자동 재생하는 방법보다 `autoplay` 속성에 대한 지원이 더 잘 되어 있기 때문입니다. 또한 자동 재생 방식과 시점을 브라우저가 최적으로 결정할 수 있게 합니다.

#### 예시: 비디오 재생

아래는 문서 내의 첫번째 `<video>` 엘리먼트를 찾아 재생하는 간단한 예제입니다. `play()` 는 자동 재생 권한을 획득하기 전까지는 재생하지 않습니다.

```js
document.querySelector("video").play();
```

#### 예시: play() 실패 처리

`play()` (en-US) 메소드로 재생한 경우 자동 재생 실패를 탐지하는 것은 매우 쉽습니다. `play()` 함수가 재생 성공시 resolve되고 실패 시(자동 재생이 거부되거나) reject되는 `Promise`를 반환하기 때문이죠. 자동 재생이 실패한 경우 수동으로 사용자에게 자동 재생 권한을 요청하면 됩니다.

아래와 같은 코드로 해결할 수 있습니다:

```js
let startPlayPromise = videoElem.play();

if (startPlayPromise !== undefined) {
  startPlayPromise
    .catch((error) => {
      if (error.name === "NotAllowedError") {
        showPlayButton(videoElem);
      } else {
        // Handle a load or playback error
      }
    })
    .then(() => {
      // Start whatever you need to do only after playback
      // has begun.
    });
}
```

`play()`의 반환값이 `undefined`가 아닌 지 먼저 확인해야합니다. 과거 버전 HTML 표준에서는 `play()` 의 반환 값이 정의되어 있지 않기 때문입니다. Promise를 반환하여 재생 성공/실패를 알 수 있게 된 것은 최근의 일입니다. `undefined`인지 체크하여 구형 브라우저에서 오류가 발생하지 않도록 하세요.

그 후 promise에 `catch()` (en-US) 핸들러를 추가합니다. 핸들러는 에러의 `name` (en-US)이 `NotAllowedError`인지 체크합니다. 이는 재생이 실패한 이유가 자동 재생 금지 같은 퍼미션 문제인지 알 수 있습니다. 그 경우 여러분은 사용자가 직접 재생할 수 있도록 UI를 표시해야 합니다; `showPlayButton()` 함수가 하는 일이죠.

다른 에러도 적절하게 처리해 줍니다.

`play()`가 반환 한 promise가 에러 없이 resolveed 되면, `then()` 절에서 자동 재생 성공 후 하려는 뭐든지 수행하면 됩니다.

Web Audio API를 이용한 자동 재생
------------------------

웹사이트나 앱에서 Web Audio API의 `AudioContext` 같은 노드에서 `start()` 메소드를 호출하여 오디오를 자동 재생할 수 있습니다. 사용자 입력 컨텍스트에 벗어난 곳에서 호출할 경우에는 자동 재생 규칙이 적용됩니다.

*상세한 내용 추가 예정; Mozilla는 아직 자동 재생 방지 기능을 작업 중입니다. 다른 곳에 이미 구현되었다면 여기에 마음 껏 내용을 추가해 주세요...*

자동 재생 기능 정책
-----------

지금까지 설명한 브라우저 측의 자동 재생 관리 및 처리 기능도 있지만, 웹 서버도 자동 재생 여부를 결정할 수 있습니다. HTTP `Feature-Policy` (en-US) 헤더의 `autoplay` (en-US) 디렉티브가 해당 용도입니다. 존재만 하면 자동 재생할 때 쓸 수 있습니다. 기본적으로 `autoplay`의 allowlist는 `'self'` (*홑따옴표 포함*)이며, 현재 문서와 동일한 domain에만 허용하고 있습니다.

`'none'`으로 지정하여 전역으로 자동 재생을 막을 수 있습니다. `'*'` 는 모든 도메인에서 전송된 미디어를 자동 재생하도록 허용합니다. 오리진은 하나의 space 문자로 구분 됩니다.

**참고:** 명시된 feature policy는 현재 문서와 내부의 모든 `<iframe>` (en-US)에 적용됩니다. 단 `allow` (en-US) 어트리뷰트를 가진 iframe과 해당 프레임의 내부 프레임은 새로운 feature policy가 적용되며 상위의 feature policy는 무시됩니다.

`<iframe>`에 `allow` (en-US)를 추가하여 해당 프레임과 내부 프레임에 feature policy를 적용하면, `src` (en-US) 어트리뷰트에서 지정된 도메인에서만 미디어를 자동 재생 하도록 허용할 수 있습니다.

### 예시: document의 domain에서만 자동 재생 허용

`Feature-Policy` (en-US) 헤더를 사용하여 document의 origin에서만 자동 재생을 허용하는 예시입니다:
```

Feature-Policy: autoplay 'self'
```

`<iframe>` (en-US)에서 동일한 작업을 합니다:

```html
<iframe src="mediaplayer.html" allow="autoplay 'src'"> </iframe>
```

### 예시: 전체 화면에서 자동 재생 허용

이전 예시에 추가로 Fullscreen API 권한을 더하면 `Feature-Policy` 헤더는 아래와 같습니다. 도메인에 상관 없이 허용한 경우인데요; 필요하다면 도메인 제한을 추가할 수 있습니다.
```

Feature-Policy: autoplay 'self'; fullscreen
```

`<iframe>` 엘리먼트의 `allow` 프로퍼티를 통해서 동일한 작업을 하면 아래와 같습니다:

```html
<iframe src="mediaplayer.html" allow="autoplay 'src'; fullscreen"> </iframe>
```

### 예시: 특정 리소스만 자동 재생 허용

document(또는 `<iframe>`)의 도메인과 `https://example.media` 에서만 자동 재생을 허용하기 위해서는 `Feature-Policy` 를 아래와 같이 작성합니다:
```

Feature-Policy: autoplay 'self' https://example.media
```

그리하여 `<iframe>` (en-US) 역시 자신과 자식 프레임에서 자동 재생 정책을 사용하기 위해 아래와 같이 작성할 수 있습니다:

```html
<iframe
 width="300"
 height="200"
 src="mediaplayer.html"
 allow="autoplay 'src' https://example.media">
</iframe>
```

### 예시: 자동 재생 비활성

`autoplay` feature policy를 `'none'`으로 지정하면 전체 document, `<iframe>` 및 모든 내부 프레임에서 자동 재생이 불가능합니다. 헤더는 다음과 같습니다:
```

Feature-Policy: autoplay 'none'
```

`<iframe>`의 `allow` 어트리뷰트를 쓴다면:

```html
<iframe src="mediaplayer.html" allow="autoplay 'none'"> </iframe>
```

유용한 사례
------

자동 재생을 적절하게 활용하기 위한 팁과 사례들을 모아 보았습니다.

### Media control을 통해 자동 재생 실패 처리하기

자동 재생하는 대표적인 케이스는 본문이나 광고 또는 페이지의 메인 기능에 대한 프리뷰로써 짧은 비디오 클립을 자동으로 재생하는 경우입니다. 이 경우 두 가지 선택지가 있습니다: 오디오가 없는 비디오를 재생하거나, 오디오가 있어도 기본적으로 음소거하거나, 아래처럼요:

```html
<video src="/videos/awesomevid.webm" controls autoplay muted></video>
```

이 비디오 엘리먼트는 user control 어트리뷰트가 설정되어 있습니다 (보통 재생/일시정지, 비디오 타임라인 탐색, 볼륨 컨트롤, 음소거 등); 또한 `muted` 어트리뷰트가 포함되어 있어 자동 재생 되지만 음소거 상태입니다. 하지만 사용자는 볼륨 버튼을 클릭하여 음소거를 해제할 수 있죠.

브라우저 설정 옵션
----------

브라우저는 보통 자동 재생 동작 방식을 컨트롤하기 위한 사전 설정, 혹은 자동 재생 방지 처리법을 가지고 있습니다. 그런 사전 설정들 중에 웹개발자인 여러분들에게 중요하거나 유용할 사전 설정들을 나열해 보았습니다. 이 설정들은 테스트 및 디버깅에 필요할 뿐만 아니라 실제로 도입되기 전 준비하는 데에도 유용합니다.

### Firefox

* `media.allowed-to-play.enabled`
    + : `HTMLMediaElement.allowedToPlay` 프로퍼티의 노출 여부를 불리언 값으로 표현합니다. 현재는 기본값이 `false` 입니다(nightly builds는 예외로, 기본 값이 `true` 입니다). `false`라면, `HTMLMediaElement`에 `allowedToPlay` 프로퍼티가 없으며, `<audio>` (en-US)와 `<video>` 엘리먼트에도 없습니다.
* `media.autoplay.allow-extension-background-pages`
    + : 불리언 값으로, `true`라면 브라우저 확장의 백그라운드 스크립트가 오디오를 자동 재생 할 수 있습니다. `false`로 세팅하면 해당 기능을 막습니다. 기본 값은 `true`입니다.
* `media.autoplay.allow-muted`
    + : 불리언 값으로 (기본 값) `true`는 현재 음소거 상태인 오디오 자동 재생을 허용합니다. `false`로 바뀔 때 오디오 트랙이 포함된 미디어는 음소거 상태라도 자동 재생이 불가능합니다.
* `media.autoplay.block-webaudio`
    + : Web Audio API를 통한 자동 재생도 차단할 지 여부를 불리언값으로 표현합니다. 기본 값은 `true`입니다.
* `media.autoplay.default`
    + : 도메인 별 자동 재생 설정 값을 정수로 표현합니다. 허용 (`0`), 금지 (`1`), 확인 요청 (`2`). 기본 값은 `0`입니다.
* `media.autoplay.enabled.user-gestures-needed` (Nightly builds only)
    + : `media.autoplay.default` 값에 우선하여 사용자 제스쳐 적용 여부를 불리언 값으로 표현합니다. `media.autoplay.default` 값이 `0`이 *아닌* 경우(자동 재생이 기본으로 허용), 이 설정이 `true` 일 때 사용자 제스쳐를 통한 activation 후 오디오 트랙이 있는 미디어의 자동 재생이 가능해 집니다. 오디오가 없는 미디어는 제한되지 않습니다.
* `media.block-autoplay-until-in-foreground`
    + : 백그라운드 탭에서 미디어 재생 시 제한 여부를 불리언 값으로 표현합니다. 기본 값 `true`는 다른 값이 허용이더라도 포그라운드에 탭이 올라오기 전까지 자동 재생이 불가능합니다. 이 설정은 어느 탭에선가 오디오를 재생했는데 사용자는 찾지 못해 탭을 뒤적이는 등의 짜증나는 시츄에이션을 방지해 줍니다.
더 보기
----

* Web media technologies
* Video and audio content (en-US) (Learning guide)
* Using the Web Audio API
* Cross-browser audio basics (en-US)


HTML에서 오디오와 비디오 사용하기 - 웹 미디어 기술

HTML에서 오디오와 비디오 사용하기
====================

HTML의 `<audio>` (en-US)와 `<video>` 요소를 사용하면 오디오와 비디오 콘텐츠를 웹페이지에 삽입할 수 있습니다. 더 나아가, 이 요소들의 인터페이스는 브라우저 화면을 벗어나 코드를 통해 미디어를 조작하고 재생하는 데에 핵심이 됩니다. 이 가이드에서는 미디어 요소들과 HTML 콘텐츠 내에서 이들을 어떻게 사용하는지에 대해 알아봅니다.

>
> **참고**: 이 가이드는 MDN 곳곳에 흩어져 있는 문서를 단일 문서 혹은 문서 집합으로 통합할 예정입니다. 이 작업은 아직 계획된 일정이 없으나 곧 진행될 예정입니다. 지금은 찾으시는 내용 중 일부를 학습구역 문서 (en-US)에서 찾아볼 수 있습니다.
>
>
>

현재는 이런 객체들을 화면을 벗어나서 사용할 수 있는 가이드가 없지만 오디오와 비디오 조작하기 (en-US)를 참고하면 좋은 시작점이 될 수 있습니다.

### 더 보기

* 웹 미디어 기술


디지털 오디오 개요 - 웹 미디어 기술

디지털 오디오 개요
==========

디지털 형태로 오디오를 나타내는 데에는 몇 가지의 단계와 과정이 수반되며, 웹에서 실제로 사용되는 인코딩되었거나 압축된 오디오와 가공되지 않은 오디오 양 쪽에서 모두 사용될 수 있는 다수의 포맷들이 있습니다. 이 가이드에서는 어떻게 오디오가 디지털적으로 표현되는지, 그리고 어떻게 코덱이 웹에서의 사용을 위해 오디오를 인코딩하고 디코딩하는지를 고찰합니다.

오디오 샘플링하기
---------

오디오는 선천적으로 자연계의 아날로그적 특징입니다. 객체가 진동하며, 객체는 자신 주위의 분자들의 진동을 또한 유발합니다. 이 분자들은 인접한 다음의 분자에 영향을 주는 것을 이어가며, 진동을 음원으로부터 바깥으로 향하는 파동의 형태로 파동의 진폭이 (음량) 파동이 나아가며 사라질 때까지 전파합니다. 그렇다면, 실세계의 오디오 파동의 입도(granularity)는 음파가 이동해 나가는 매질의 각 분자에 대한 것입니다.

지구에서, 대부분의 오디오가 이동해 나가는 매질은 공기입니다. 몇몇 오디오는 물론 물 뿐만이 아니라 심지어 행성 자체를 구성하는 암석을 통해서도 이동하지만 (만약 여러분이 지진의 우르르 소리나 쾅 소리를 들어본 적이 있다면, 여러분은 이 현상을 경험한 것입니다), 여러분이 매일 듣는 거의 모든 소리들은 공기를 통해 여러분의 귀로 이동합니다.

사람이 매일 듣는 소리들은, 그렇다면, 실제로는 귀의 내부 작동을 유발하는 공기 중의 진동입니다. 파동의 각 진동에서 공기 분자가 더 멀리 움직일수록, 파동의 진폭은 더 높아지고, 소리의 크기는 더 커집니다. 분자가 더 빨리 진동할수록, 파동의 주파수는 더 높아집니다.

파동의 진폭(높이)이 높을수록, 그 순간에서의 소리는 더 큽니다. 파장이 더 짧을수록 (파동의 꼭대기들 간의 거리가 가까울수록), 생성되는 소리의 주파수 (혹은 음높이)는 더 높습니다.

![단순한 소리 파형](/ko/docs/Web/Media/Formats/Audio_concepts/audio-waveform.svg)

Amplitude: 진폭
Time: 시간

그러나, 컴퓨터는 디지털적입니다. 컴퓨터가 조작하고 처리할 수 있는 방식으로 음파를 나타내기 위해서는 (네트워크를 통해 전송하는 것은 차치하고), 소리는 디지털 형태로 전환되어야만 합니다. 이 과정을 **아날로그-디지털 변환**(analog to ditigal conversion)이라고 합니다 (줄여서 **A/D**).

포착된 오디오의 충실도(fidelity)에 영향을 주는 첫번째 요소는 **오디오 대역폭**(audio bandwidth)입니다. 즉, A/D 변환기가 디지털 형태로 포착하고 변환할 수 있는 오디오 주파수의 범위입니다. 오디오 대역폭은 또한, 만약 코덱이 소리를 인코딩하는 중에 어떠한 주파수 대역을 폐기하기로 선택한다면, 코덱에 의해서도 영향받습니다.

소리는 음파의 진폭을 나타내기 위해 전압이 다양한 전자의 흐름의 형태로 마이크나 다른 입력을 통해 컴퓨터로 입력됩니다. 이 아날로그 신호는 그리고 나서 규칙적인 구간마다 들어오는 파동의 진폭을 포착하면서, 그 데이터를 오디오 녹음 시스템에 의해 이해되는 형태의 수로 변환하는 회로에 의해 디지털 형태로 변환됩니다. 이 각각의 포착된 순간들을 **샘플**(sample)이라고 합니다. 이 모든 샘플들을 함께 이음으로써, 아래 사진에서 보이다시피 여러분은 근사적으로 원본 파동을 나타낼 수 있습니다.

![주기적으로 취해진 샘플들을 가지고 있는 오디오 파형](/ko/docs/Web/Media/Formats/Audio_concepts/audio-waveform-samples1.svg)

Amplitude: 진폭
Time: 시간

이 예제에서, 파란색 선은 오디오 파형(검정색 선)으로부터 취해진 샘플들을 나타냅니다. 정기적인 구간마다, A/D 변환기 회로망은 신호의 전압을 (이 경우) -1.0과 +1.0사이의 값으로써 읽습니다. 진폭은 이 시간 구간동안 다르기 때문에, A/D 변환기는 반드시 이 구간을 나타내는 값을 선택해야만 하는데, 이는 특정한 순간의 값을 취함으로써 (위의 그림에서는, 각 구간의 중간점이 그 값으로써 사용되었습니다), 혹은 각 샘플의 기간 동안의 진폭의 평균을 냄으로써 이루어집니다. 이 샘플 값들은 그리고 나서 그 시간에서의 파형의 진폭으로써 기록됩니다.

후에 이 소리를 재생하게 될 때, 이 진폭들은 원본 파형의 근사치를 생성하기 위해 사용됩니다. 원본의 정확한 복제본(매끄러운 파동)이 재생되는 대신, 거친 파동(파란색 선)이 재생됩니다.

더 자주 원본 오디오의 샘플을 취할수록, 원본에 더욱 가까워집니다. 초당 취해진 샘플의 수를 **샘플 레이트**(sample rate)라고 합니다. 상기의 파동과, 만약 두 배만큼, 혹은 10배만큼 더 샘플을 취했다면 파란색 디지털 파동이 얼마나 다르게 보일지 생각해 보십시오. 더 많이 샘플을 취할수록, 파동은 더욱 매끄러워집니다.

오디오 데이터 포맷과 구조
--------------

가장 기본적인 수준에서, 오디오는 샘플의 흐름으로써 표현되어지는데, 각 샘플은 오디오 신호의 전체 파형의 주어진 구간에서 측정된 오디오 파형의 진폭을 명시합니다. 오디오 파일 내부에서 각 샘플들에 대해 사용되는 몇 가지 포맷들이 있습니다. 대부분의 오디오 파일들은 각 샘플에 대해 16비트 signed integer를 사용하나, 다른 것들은 32비트 부동 소수점 값 또는 24비트 혹은 32비트 integer를 사용합니다. (웹에서의 사용을 발견하지 못할) 몇몇 오래된 오디오 파일 포맷들은 8비트 integer 샘플을 사용했습니다. 덧붙여서, 샘플은 signed 혹은 unsigned 값을 또한 사용할 수도 있습니다. 각 샘플의 크기는 **샘플 사이즈**(sample size)라고 합니다.

오디오 신호 내부의 각 오디오 소스(source)의 위치를 **채널**(channel)이라고 합니다. 각 채널은 주어진 순간에서 그 소스에 의해 생성되고 있는 오디오의 진폭을 나타내는 샘플을 포함하고 있습니다. 예를 들어, 스테레오 사운드에는, 두 개의 오디오 소스가 있습니다. 좌측에 있는 스피커와 우측에 있는 스피커입니다. 각 스피커는 하나의 채널로 표현되고, 오디오 신호에 포함되어 있는 채널의 수를 **채널 카운트**(channel count)라고 합니다.

다수의 채널을 가진 오디오 파일을 녹음하거나 생성하는 동안, 채널들은 일련의 **오디오 프레임**(audio frame)으로 조립되는데, 각 오디오 프레임은 오디오의 각 채널의 한 샘플로 이루어져 있습니다. 개개의 샘플은 한 순간에서의 소리의 진폭을 나타내는 수치적 값이고, 다양한 포맷으로 표현될 수 있습니다.

아마도 스테레오 오디오는 웹 오디오에서 가장 일반적으로 사용되는 채널 방식이고, 16비트 샘플이 현재 사용되는 일상적인 오디오의 대다수에 대해 사용됩니다. 16비트 스테레오 오디오에 대해, 아날로그 신호에서 취해지는 각 샘플은 두 개의 16비트 integer로 녹음되는데, 한 개는 좌측 채널이고 나머지 한 개는 우측 채널입니다. 이는 각 샘플은 32비트의 메모리를 요구한다는 것을 의미합니다. 48 kHz(초당 48,000 샘플)의 일반적인 샘플 레이트에서, 이것은 오디오의 매 초는 메모리의 192kB를 점유한다는 것을 의미합니다. 그러므로, 통상적인 3분의 노래는 약 34.5 MB의 메모리를 요구합니다. 이것은 많은 저장 공간이지만, 설상가상으로, 이것은 비교적 짧은 오디오에 대해 사용하기에 대단히 많은 양의 네트워크 대역폭이라는 것입니다. 이것이 왜 대부분의 디지털 오디오가 압축되는지에 대한 이유입니다.

오디오를 압축하고 압축 해제하는 과정은 오디오 코덱(**codec**, **CO**der/**DE**coder)을 사용해 오디오를 인코딩하고 디코딩함에 의해 수행됩니다. 수년 간, 많은 종류의 코덱들이 개발되었고, 그것들 중 몇 가지가 웹에서 일반적으로 사용됩니다. 웹 개발자가 친숙해지기에 가장 중요하고 유용한 코덱들에 대한 자세한 사항에 대해서는, 웹에서 사용되는 오디오 코덱에 대한 가이드 (en-US)를 참고해 보세요.

### 오디오 채널과 프레임

두 종류의 오디오 채널이 있습니다. 표준 오디오 채널은 대부분의 들을 수 있는 소리를 나타내기 위해 사용됩니다. 주된 좌측과 우측 채널에 대한 소리 뿐만이 아니라, 서라운드 사운드 스피커 (중앙, 후방 좌우측, 좌우측, 천장 채널 등등) 는 모두 표준 오디오 채널입니다. 특별한 **저주파 향상**(Low Frequency Enhancement, **LFE**) 채널은 오디오를 들을 때 감정적인 감각을 생성하기 위해 저주파 소리와 진동을 제공하기 위해 설계된 특별한 스피커에 대한 신호를 제공합니다. 이 LFE 채널은 보통 서브우퍼와 유사한 장치를 추진시킵니다.

모노 오디오는 한 개의 채널을 가지고 있고, 스테레오 사운드는 두 개의 채널을, 5.1 서라운드 사운드는 6개 (5개의 표준 채널과 한 개의 LFE), 등등입니다. 각 오디오 프레임은 오디오 신호에서 사용 가능한 모든 채널에 대한 샘플을 포함하고 있는 데이터 레코드입니다. 오디오 프레임의 크기는 샘플 사이즈 (단위: 바이트) 를 채널의 수로 곱함으로써 계산되므로, 스테레오 16비트 오디오의 한 프레임은 4바이트 길이이고 5.1 부동소수점 오디오의 한 프레임은 24바이트입니다 (샘플당 4바이트 곱하기 6채널).

**참고:** 몇몇 코덱은 실제로는 좌측과 우측 채널을 나누며, 코덱의 데이터 구조 내부에 별도의 블럭으로 채널들을 저장할 것입니다. 그러나, 오디오 프레임은 항상 사용 가능한 모든 채널의 모든 데이터로 구성됩니다.

오디오의 1초를 구성하는 프레임의 수는 사운드를 녹음할 때 사용된 샘플 레이트에 따라 다릅니다. 샘플 레이트는 음파가 각 초 동안 나눠진 구간의 수에 해당하므로, 샘플 레이트는 때때로 주파수로써 생각되고 (주기적으로 반복되는 무언가에 대한 설명으로써의 의미이지, 실제 오디오 주파수의 용어로써의 의미가 아닙니다), 초당 샘플 측정은 그러므로 헤르츠를 단위로써 사용합니다.

가장 일반적인 샘플 레이트는 다음과 같습니다.

8000 Hz

전화 통신에 사용되는 오디오에 대한 국제 G.711 표준은 8000 Hz (8 kHz) 의 샘플 레이트를 사용합니다. 이것은 인간의 말이 이해되기에 충분합니다.

44100 Hz

44.1 kHz 샘플 레이트는 컴팩트 디스크 (CD) 오디오에 대해 사용됩니다. CD는 압축되지 않은 16비트 스테레오 사운드를 44.1 kHz로 제공합니다. 컴퓨터 오디오도 또한 자주 이 주파수를 기본값으로 사용합니다.

48000 Hz

DVD의 오디오는 48 kHz로 녹음됩니다. 이것은 종종 컴퓨터 오디오에서도 사용됩니다.

96000 Hz

고해상도 오디오.

192000 Hz

초고해상도 오디오. 아직 일반적으로 쓰이지는 않지만, 이것은 시간이 흐름에 따라 변할 것입니다.

왜 44.1 kHz가 최소 "고 충실도" 샘플링 레이트로 여겨지는지에 대한 이유가 있습니다. 표본화 정리에 따르면, 소리를 정확히 재현하기 위해서는, 소리는 반드시 소리의 주파수의 두 배의 비율로 샘플링되어야만 합니다. 인간의 가청 범위는 약 20 Hz에서 20,000 Hz까지이므로, 사람들이 일반적으로 들을 수 있는 가장 높은 음높이의 소리를 재현하는 것은 40,000 Hz 이상의 샘플 레이트를 요구합니다.

에일리어싱에 의해 발생되는 왜곡을 방지하기 위해 로우패스 필터에 대한 추가적인 공간을 제공하기 위해서, 추가적인 2.05 kHz 천이 대역이 사전 샘플링 주파수에 추가됩니다 (결과적으로 22,050 Hz). 표본화 정리에 의하여 두 배를 하면 (예측하셨다시피) 44.1 kHz의 최종 최소 주파수가 됩니다.

고해상도 (96 kHz) 오디오는 몇몇 고급 오디오 시스템에서 사용되고, 이것과 초고해상도 (192 kHz) 오디오는 오디오 마스터링에 유용한데, 여기서는 최종 제품에 사용할 샘플 레이트로 다운샘플링하기 전에 소리를 조작하고 수정하는 동안 가능한 한 뛰어난 품질이 필요로 됩니다. 이것은 사진작가가 고객에게 웹사이트에서의 사용에 적합한 JPEG로 제공하기 전에 고해상도의 이미지를 수정하고 합성하는 방식과 비슷합니다.

### 오디오 파일 크기와 네트워크 대역폭

한 번 하나의 오디오 프레임의 크기와 얼마나 많은 초당 프레임들이 오디오 데이터를 이루는지를 알고 나면, 가공되지 않은 사운드 데이터 그 자체가 얼마나 많은 공간을 차지할지는 (그리고 그러므로 얼마나 많은 대역폭이 네트워크에서 소모될지는) 쉽게 계산될 수 있습니다.

예를 들어, 48 kHz로 녹음된 16비트 (2바이트) 의 샘플 사이즈를 가진 스테레오 오디오 클립 (즉, 두 개의 오디오 채널) 을 고려해 보세요.

2
×
2

bytes

sample

×
48000

samples

second

=
192000

bytes

second

=
192
kBps

2 \times 2\frac { bytes }{ sample } \times 48000\frac { samples }{ second } = 192000\frac { bytes }{ second } = 192 kBps

192 kBps에서, 저품질의 네트워크는 이미 단지 재생되는 하나의 오디오 스트림에 의해 혹사될 것입니다. 만약 네트워크가 또한 다른 것을 하고 있다면, 문제는 심지어 더 높은 대역폭의 네트워크에서도 발생합니다. 네트워크 용량에 대한 아주 많은 경쟁과 함께, 특히 느린 네트워크에서는, 이 양의 데이터는 어떤 종류의 실시간 어플리케이션에서라도 성공적으로 전송하기에는 너무 많을지도 모릅니다.

이 문제를 해결하기 위하여, 압축을 사용하여 오디오는 반드시 작게 만들어져야 합니다.

**참고:** 네트워크 대역폭은 분명히 (위의 오디오 샘플링하기에서 언급된) 오디오 대역폭과는 다른 것입니다.

오디오 압축 기본
---------

텍스트와 다른 많은 종류의 데이터와는 다르게, 오디오 데이터는 **소음이 강한** 경향이 있는데, 이는 오디오 데이터는 좀처럼 일련의 정확히 반복되는 바이트 또는 바이트 시퀸스로 구성되지 않음을 의미합니다. 그 결과로써, 오디오 데이터는 `zip` 같은 다목적 도구에 의해 사용되는 전통적인 알고리즘들을 사용하여 압축하기가 어려운데, 이러한 전통적인 알고리즘들은 보통 반복되는 데이터 시퀸스를 축약 표현으로 대체함으로써 작동합니다.

오디오를 압축할 때 적용할 수 있는 몇 가지 기법들이 있습니다. 대부분의 코덱들은 이 기법들의 조합을 사용하고, 다른 기법들을 또한 사용할 수도 있습니다.

할 수 있는 가장 단순한 일은 소음과 조용한 소리를 제거하는 필터를 적용하며, 모든 조용한 부분들을 소리가 없는 상태로 전환하고 신호를 매끄럽게 하는 것입니다. 이것은 소리가 없는 상태의 늘임을 생산할 수 있을 뿐만 아니라 다른 반복되거나 축약될 수 있는 거의 반복되는 신호들의 늘임 또한 생산할 수 있습니다.

오디오 대역폭을 좁게 하는 필터를 적용하며, 상관하지 않는 모든 오디오 주파수를 제거할 수 있습니다. 이것은 목소리만이 있는 오디오 신호에 특히 유용합니다. 이것을 하는 것은 데이터를 제거하며, 결과 신호를 더욱 압축하기 쉬울 가능성이 있게 만듭니다.

### 음향 심리학

만약 어떤 종류의 오디오를 가장 다룰 가능성이 높은지 안다면, 인코딩을 최적화할 그 종류의 소리에 특별히 적용가능한 특별한 필터링 기법들을 어쩌면 찾을 수 있습니다.

오디오에 대해 가장 일반적으로 사용되는 압축 방법은 **음악심리학** 의 과학을 적용합니다. 음향 심리학은 어떻게 인간이 소리를 인지하고, 맥락과 소리의 내용을 고려할 때, 어떻게 우리가 그 소리에 반응하는지에 우리가 듣는 오디오 주파수의 어떤 부분이 가장 중요한지를 연구하는 과학입니다. 소리의 주파수에서의 변화를 감지하는 능력이나, 오디오 신호의 주파수에 비해 인간의 전반적인 가청 범위, 오디오 위치 감지 등등의 요소 모두가 코덱에 의해 고려될 수 있습니다.

음향심리학의 소리 (말장난 아님) 이해를 사용하여, 인지되는 소리의 충실도를 최대화하면서 오디오의 압축된 크기를 최소화할 압축 방법의 설계는 가능합니다. 음향심리학을 이용한 알고리즘은 여기서 언급된 모든 기법들을 사용할 수도 있고, 거의 분명히 다른 것들 또한 적용할 것입니다.

이것 모두는 코덱을 선택하기 전에 질문되어야 하고 답변되어야만 하는 근본적인 질문이 있음을 의미합니다. 소리의 내용, 사용 맥락, 목표 청중을 고려할 때, 얼마간의 오디오 충실도를 잃는 것은 수용가능한가? 만약 그렇다면, 얼마나 가능한가? 혹은 데이터를 디코딩함에 있어, 그 결과는 소스 오디오와 동일해야만 함이 필수적인가?

### 손실 대 무손실 압축

만약 디테일과 어쩌면 충실도의 손실이 용인될 수 없고 달갑지 않다면, **무손실**(lossless) 코덱이 선호됩니다. 반면, 오디오 충실도의 어느 정도의 축소가 괜찮다면, **손실**(lossy) 코덱이 사용될 수 있습니다. 일반적으로, 손실 압축은 그 결과로 무손실 압축 방법에 비해 상당히 작은 출력을 낳습니다. 또한, 많은 손실 코덱들은 훌륭한데, 품질과 디테일의 손실이 평균적인 청취자가 알아차리기 힘들거나 심지어 불가능할 정도입니다.

**참고:** 소리 품질에 대한 고품질 손실 압축 알고리즘의 효과는 평균적인 사람이 감지하기 어려울 수 있는 반면, 일부 사람들은 이례적으로 좋은 청각을 가지고 있거나 손실 압축 기법에 의해 음악에 진행된 변화의 종류를 감지하는 데 특별히 능숙합니다.

오디오 코덱의 대부분은 손실 압축의 몇몇 형태를 사용하는데, 그 알고리즘들이 제공하는 더 좋은 압축 비율 때문입니다. 무손실 압축 알고리즘은 보통 간신히 원본의 압축되지 않은 사운드 데이터의 40-50% 크기와 다름없으나, 현대의 손실 압축 알고리즘은 오디오의 복잡도에 따라 오디오의 크기를 원본 크기의 5-20% 사이로 줄일 수 있습니다. 손실 압축으로 가능한 대단히 우수한 압축 비율은 보통 선택을 할 수 밖에 없게 만들고, 적절하거나 탁월한 오디오 품질은 잘 선택된 코덱 설정으로 가능합니다.

연구자들은 계속하여 오디오를 분석하고 압축하는 더 나은 방법을 창안하고 있어서, 압축 비율에서나 오디오 충실도에서 (혹은 둘 다에서) 다양한 개선을 제공하는 새로운 포맷들이 주기적으로 나옵니다.

무손실 오디오의 사용 경우는 다음과 같은 시나리오를 포함합니다.

* 청취자가 정밀한 오디오 재현을 기대하고 소리에 대해 변화되지 않은 오디오의 복잡한 디테일을 알아듣기에 충분한 귀를 가지고 있을 수 있는 상황
* 음악과 사운드 이펙트 생산 업무에서 사용되는 오디오 반복과 샘플
* 오디오 클립 또는 샘플이 리믹스되고 그리고 나서 압축될 수 있는 상황. 마스터링 과정에서 무손실 오디오를 사용하는 것은 사전에 압축된 데이터를 압축해 추가적인 품질 손실을 낳을 수 있는 상황을 방지합니다

손실 압축의 사용을 추천할 수 있는 요소는 다음을 포함합니다.

* 아주 큰 소스 오디오
* 무리가 가해진 저장소 (저장소 공간이 작기 때문이거나 큰 양의 사운드가 저장되어 있기 때문이거나)
* 오디오를 방송하기 위해 요구되는 네트워크 대역폭을 제한할 필요. 이것은 특히 라이브 스트림과 화상 회의에 중요합니다.
음향심리학 개론
--------

음향심리학의 디테일과 어떻게 오디오 압축이 이루어지는지에 뛰어드는 것은 이 문서의 범위를 아주 멀리 벗어나나, 어떻게 오디오가 일반적인 알고리즘에 의해 압축되는지에 대해 일반적인 개념을 아는 것은 유용하며 오디오 코덱 선택의 이해와 더 나은 선택을 내리는 것을 도울 수 있습니다.

손실 압축 알고리즘은 일반적으로 음향심리학을 사용하여 목적 청취자에게 잘 들리는 효과를 최소화하는 동시에 압축 비율을 개선할 수 있는 방법으로 오디오 파형의 어떤 요소가 손실될 수 있을지 혹은 억제될 수 있을 지 결정합니다. 파형이 쉽게 압축될 수 있게 만들기 위해 파형을 조작함으로써, 혹은 실제로는 들리지 않는 소리의 요소를 제거함으로써, 파형은 단순해지고, 이는 더욱 일관적이고 따라서 쉽게 압축되는 데이터를 결과로 낳습니다. 인간의 귀가 디코딩된 소리를 해석할 방식에 가장 중요한 주파수들만 포함하기 위해 오디오 대역폭을 제한하는 것은 압축 요소를 또한 향상시킬 수 있습니다.

인코딩되는 내용의 유형은 코덱의 선택에 영향을 미칠 수 있습니다. 특히, 음악의 파형은 거의 항상 오직 인간의 음성만을 포함하는 오디오 샘플의 파형보다 더욱 복잡합니다. 추가적으로, 인간의 음성은 인간의 귀가 감지할 수 있는 오디오 주파수 범위의 작은 부분을 사용합니다.

**참고:** 원래 명확히 인간 음성을 전송하기 위해 설계된 전화기 네트워크는 오직 300 Hz에서 3,000 Hz 까지의 주파수 대역 내의 오디오 (혹은 다른 종류의 신호) 를 전달할 수 있습니다. 이것은 낮은 영역에서 인간 회화의 전체 범위를 상당히 다루지 못하지만, 인간의 귀와 뇌가 쉽게 보정하는 파형의 충분한 양을 사용 가능합니다. 이것은 또한 인간은 일반적으로 아주 좁은 오디오 대역폭으로 제한된 회화를 듣는 것에 순응되어 있음을 의미합니다.

인간 회화는 비교적 좁은 주파수 대역을 사용합니다 (300 Hz에서 18,000 Hz 주변, 성별을 포함한 요소에 기인해 정확한 범위는 사람마다 다름). 추가적으로, 인간 회화 소리의 대부분은 500 Hz와 3,000 Hz 쯤 사이에 놓여 있는 경향이 있어, 말해지고 있는 단어를 이해하는 청자의 능력을 타협하는 일 없이 전체 파형의 상당한 부분을 탈락시키는 것을 가능케 합니다. 심지어 각 화자의 목소리의 음높이의 요소로 오디오 대역폭을 조정할 수도 있습니다.

이 모든 요소들 때문에, 그리고 회화 파형이 보통 음악보다 덜 복잡하기 때문에, 회화의 높은 (더욱 구체적으로는 "충분히 높은") 충실도의 재현이 비교적 적은 비트 레이트에서 달성될 수 있습니다.

일반적인 오디오를 압축하기 위해 고안된 압축 알고리즘이 오디오 파형을 분석할 때, 이것은 인간의 가청 범위 외부의 모든 것을 폐기할 수 있습니다 (아마 심지어는 더, 알고리즘이 얼마나 주파수 대역의 높은 부분 그리고/또는 낮은 부분에서의 디테일을 잃어버릴 위험을 감수하느냐에 따라). 이것은 코덱이 주파수가 약 20 Hz보다 낮거나 약 20,000 Hz (20 kHz) 보다 높은 오디오를 폐기할 수 있다는 것을 의미합니다. 이것은 소리의 오디오 대여곡을 좁히고, 그럼으로써 압축된 형태로 신호를 나타내는 데 요구되는 데이터의 양을 줄입니다. 오디오 대역폭은 회화 전용 코덱만큼 가까이 감소될 수 없지만, 이것은 여전히 도움이 되는 시작점입니다.

몇몇 사람들은 얼마간 이 범위 바깥을 들을 수 있습니다. 더욱 종종, 높은 주파수를 듣는 인간의 능력은 이것보다 꽤 낮습니다. 특히, 중년기에서, 이 주파수 범위의 높은 영역은 보통 20 kHz에서 12 kHz에서 14 kHz 주변으로 떨어진다는 것에 주목할 가치가 있습니다. 이는 소리의 독해성에 많이 영향을 주는 일 없이 높은 주파수는 종종 폐기될 수 있어, 유지할 필요가 있는 오디오 공간의 양을 상당히 줄일 수 있어, 그럼으로써 소리를 단순하고 압축하기 쉽게 만듦을 시사합니다.

이것은 아래의 사진에서 나타납니다. 아래의 사진은 인간의 가청 주파수 범위 (녹색) 를 인간 회화의 주파수 범위 (적색) 그리고 대다수의 인간 발성이 놓여 있는 주파수 범위 (황색) 과 비교합니다.

![인간의 회화 범위와 비교된 인간의 가청 범위를 보여주는 그림](/ko/docs/Web/Media/Formats/Audio_concepts/human-hearing-range.svg)

Human Speech (Core): 인간 회화 (핵심)
Human Speech (Full Range): 인간 회화 (전체 범위)
Human Hearing: 인간 가청 범위

이 범위 간의 큰 차이는 인간의 귀가 오디오 품질에서의 실제 변화를 감지하는 능력에 중대한 영향을 미치는 일 없이 오디오 데이터에서 디테일을 잃어버릴 공간을 제공합니다. 이 사실은 오디오를 압축할 때 사용될 수 있습니다.

음향심리학적 분석을 통해 소리를 단순화하는 것 외에, 코덱은 오디오의 크기를 더 단순화하고 감소시키기 위한 다른 알고리즘과 변환을 사용합니다. 만약 압축이 오디오에서 작동하는 방식에 대해 더 알고 싶다면, 위키피디아에서 오디오 데이터 압축를 살펴 보세요.

중요한 것은, 코덱은 이 모든 어려운 일들을 대신 한다는 점입니다. 이것이 많은 엔지니어링과 과학적 연구가 새로운 알고리즘과 코덱의 생성을 연구하는 이유입니다. 여러분이 해야 할 하나의 일은 옵션과 여러분의 사용 경우를 고려하고, 필요에 맞는 적절한 코덱을 선택하는 것입니다.

**참고:** 오디오 코덱의 선택에 대한 더욱 자세한 가이드에 대해서는, 웹 오디오 코덱 가이드 (en-US)의 오디오 코덱 선택하기 (en-US)를 참고해 보세요.

무손실 인코더 파라미터
------------

원본 오디오를 재현할 수 있는 필요를 고려했을 때 무손실 인코더는 압축률을 향상시키기 위해 오디오를 조작할 공간이 많이 적은데, 이는 이러한 인코더에서 설정할 수 있는 옵션들의 수에 제한이 됩니다. 이 옵션들은 인코더가 인코딩을 수행하고 그렇게 하기 위해 시간과 프로세서 파워를 소모하는 것이 허용되는 방법을 선택하는 데 빙빙 도는 경향이 있습니다.

이 파라미터들은 코덱에 따라 다양하나, 다음을 포함할 수 있습니다.

* 인코딩 과정의 특정한 단계 동안에 사용할 구체적인 알고리즘 명시하기
* 사용할 이 알고리즘들에 대한 파라미터들, 예를 들자면 오디오 모델링을 시도할 때 얼마나 깊은 예측 깊이를 사용할 것인지
* 오디오를 분석하는 동안 만들 검사(pass)의 수, 또는 주어진 알고리즘이 몇 번 실행되어야 하는지
손실 인코더 파라미터
-----------

대부분의 코덱은 압축을 (크기나 품질에 대해서) 다양한 방법으로 최적화하기 위해 조정할 수 있는 입력 값들을 가지고 있습니다. 손실 인코더를 사용할 때, 품질이 높을수록, 인코딩된 오디오는 더 클 것입니다. 이것 때문에, 대부분의 옵션들은 어떠한 방식으로든 품질과 크기에 동시에 영향을 미칩니다.

어떤 옵션들이 가능한지를 결정하기 위해 사용하는 인코딩 소프트웨어의 문서를 참고할 필요가 있는데, 이 옵션들은 코덱과 인코딩 소프트웨어 그 자체에 달려 있을 것입니다. 몇몇 코덱들은 조정할 수 있는 다수의 값들을 가지고 있고 (그 중 일부는 음향심리학과 코덱의 알고리즘에 모두에 대해서 깊은 이해를 요구할 수도 있습니다), 다른 코덱들은 설정할 수 있는 단순한 "품질" 파라미터를 제공하는데, 이는 자동으로 알고리즘의 다양한 프로퍼티들을 조정합니다.

### 비트 레이트

비트 레이트를 사용해 압축된 오디오의 품질을 제어할 두 개의 상호적으로 독점적인 방법이 있습니다. 첫번째 방법은 인코딩된 데이터의 평균 비트 레이트를 목표로 하는 것을 수반하는 반면, 두번째 방법은 비트 레이트가 다양한 것을 허용하며 목표로 할 일정한 품질 값을 명시하는 것을 수반합니다.

#### 평균 비트 레이트

출력 파일의 품질을 제어하기 위한 첫번째 방법은 오디오를 인코딩할 때 목표로 삼을 **평균 비트 레이트**(Average Bit Rate, **ABR**)를 명시하는 것입니다. 인코더는 인코딩된 사운드 파일을 재생할 때, 평균적으로, 오디오의 매 초에 대해 명시된 수의 비트를 사용하는 인코딩된 사운드 파일의 생성을 시도할 것입니다. 이것은 인코딩된 오디오 크기의 관점에서 품질을 제어합니다. 비트 레이트가 높을수록, 결과로 나오는 오디오 품질은 더 높을 것입니다. 오디오의 품질은 목표로 삼은 비트 레이트를 맞추기 위해 필요할 때 시간에 따라 변동될 것입니다.

ABR과 다소 유사한 것은 **CBR** (**일정한 비트 레이트**, Constant Bit Rate) 입니다. 얼마간의 변동을 허용하며 ABR은 주어진 수준에서 평균적으로 비트 레이트를 유지하는 것을 시도하는 반면, CBR은 오디오의 지속 기간 동안 실제로 고정된 비트 레이트를 사용합니다. CBR은 주로 목소리 전용 목적을 위해 설계된 코덱에서 사용되는데, 이러한 목적에서 주파수 범위와 변화는 적은 경향이 있어, CBR 인코딩이 오디오 품질에서의 가공 불가능한 변동 없이 작동할 수 있게 합니다.

#### 가변적인 비트 레이트

**가변적인 비트 레이트** (Variable Bit Rate, **VBR**) 인코딩은 인코더의 입력으로 **일정한 품질** 설정을 허용함으로써 작동합니다. 이는 오디오의 지속 기간 동안 유지할 품질 수준을 시사하며, 비트 레이트가 그 품질 수준을 달성하기 위해 필요할 때 변동할 것을 허용합니다. 품질에 최소의 영향을 주며 압축이 쉽게 달성되는 소리의 부분에서, 비트 레이트는 아주 낮을 수 있는 반면, 압축이 더욱 복잡한 영역에서는, 비트 레이트는 더 높을 것입니다.

### 오디오 주파수 대역폭

몇몇 코덱은 오디오 주파수 대역폭을 직접 설정할 수 있게 하는데, 이는 허용할 주파수 범위를 명시함으로써, 상한 그리고/또는 하한 주파수를 설정함으로써, 혹은 들어오는 신호의 기대되는 주파수 사용에 기반한 알고리즘을 어떻게 설정할 지를 결정하는 오디오 소스 유형을 명시함으로써 이루어집니다.

덧붙여, 몇몇 코덱은 LFE와 같은 특별한 제한된 주파수 대역폭 채널을 지원하는데, 이는 선천적으로 사용 가능한 주파수 범위를 제한합니다. LFE의 경우에, 오디오 주파수 대역폭은 서브우퍼나 유사한 오디오 경험 향상 장치에서의 사용에 적합한 주파수 범위로 제한됩니다.

몇몇 코덱은 특별한 사용 시나리오에 대해 특별히 의도된 특별한 프로파일을 제공하는데, 예를 들자면 VoIP같은 것이 있습니다. 이 프로파일들은 또한 오디오 주파수 대역폭에 기본으로 제한을 포함할 수도 있습니다.

### 조인트 스테레오(joint stereo)

보통, 스테레오 사운드는 채널당 하나의 샘플을 포함하고 있는 오디오 프레임에 의해 표현됩니다. 이것은 그 결과로 2⨉*sampleSize* 비트를 각각 요구하는 오디오 프레임을 낳는데, 여기서 *sampleSize* 는 각 오디오 샘플이 취하는 비트의 수입니다. 그러므로, 16비트 스테레오 오디오 녹음에 대해서, 각 샘플은 2⨉16 즉 32 비트의 공간을 사용합니다. 이것이 표준 좌/우 (L/R) 스테레오 혹은 **심플 스테레오**입니다.

**조인트 스테레오**는 보통 소리가 각 귀에 유사하게 입력된다는 것을 고려함으로써 스테레오 오디오 샘플을 더욱 공간 효율적인 방식으로 저장하는 방법입니다. 따라서, 각 채널의 샘플의 모든 비트를 저장하기보다는, 기초 진폭과 채널당 진폭 편차 값이 저장되고, 여기서 편차 값은 완전한 샘플보다 더 적은 비트를 사용할 수도 있습니다.

두 유형의 조인트 스테레오가 있습니다. mid-side와 intensity(강도)입니다. 오디오 파일의 지속 기간 동안, 인코더는 오디오 파일의 전개 동안 스테레오 신호를 표현하기 위해 어떤 포맷이 사용되고 있는지를 변경할 수 있습니다.

#### Mid-side 스테레오 코딩

**Mid-side 스테레오 코딩** (**MS**) 은 기본적인 **중앙 채널**(mid channel)을 포함하는 프레임을 녹음함으로써 작동하는데, 중앙 채널이란 원본 좌측과 우측 오디오 채널의 평균 진폭입니다. 이것은 본질적으로 스테레오 신호를 모노로 전환할 때 진폭으로 계산해야 하는 것입니다. 그리고 나서 **측면 채널**(side channel) 값을 저장합니다. 이 값은 좌측 채널의 원래 진폭을 결정하기 위해 **중앙 채널**에 더해지고, 우측 채널의 원래 값을 계산하기 위해 중앙 채널에서 빼질 수 있는 숫자입니다.

다른 말로 하자면, 좌측 채널 L과 우측 채널 R이 주어졌을 때, 샘플을 인코딩할 때 다음의 계산을 수행합니다.

mid
=

L
+
R

2

mid = \frac { L + R }{ 2 }

side
=

L
-
R

2

side = \frac { L - R }{ 2 }

그리고 나서 `mid` 와 `side` 값을 저장합니다. `mid` 는 여전히 (16비트와 같은) 샘플 사이즈와 같은 크기인 반면, `side` 의 값은 아마도 더 작은 수의 비트로 저장될 수 있는데, 왜냐하면 두 채널의 진폭이 아마도 비교적 유사하기 때문입니다. 인코더는 그리고 나서 프레임 당 총 비트의 이 더 작은 수를 취하고 크기를 더 줄이기 위해 추가적인 계산을 수행할 수 있습니다.

오디오를 디코딩할 때, 완전한 좌측과 우측 채널 값은 다음과 같이 계산됩니다.

L
=
mid
+
side

L\quad =\quad mid\quad +\quad side

R
=
mid
-
side

L\quad =\quad mid\quad -\quad side

그 자체로, mid-side 스테레오 코딩은 무손실이고, 무손실 그리고 손실 오디오 코덱 전부에서 일반적으로 사용됩니다. 디테일의 손실은 인코딩 과정의 다른 단계에서 옵니다.

#### Intensity 스테레오 코딩

**Intensity 스테레오 코딩**은 인간이 공간에서 소리의 위치를 결정하는 방식을 이용함으로써 인코딩된 오디오 비트 레이트를 줄입니다. 이것은 sound localization (소리 위치 감지) 이라고 합니다. 소리가 어디서 오는지에 따라 우리의 귀는 소리를 다른 시간에서 감지하기 때문에 우리는 스테레오로 듣습니다.

이것은 왜냐하면 우리의 귀는 몇 인치 정도 떨어져 있는데다, 머리의 다른 편에 있는 덕분입니다. 우측에서 오는 소리는 좌측 귀에 도착하기 전에 우측 귀에 도착합니다. 소리가 오고 있는 각도를 알아내기 위해 우리의 뇌는 우리 주변의 공간에서 소리가 어디 있는지를 이 시간 차이를 사용하여 결정합니다. 그러나, 오디오 신호의 주파수가 올라갈수록, 파장 또한 올라갑니다. 결국, 파장은 두 귀 사이의 거리를 넘어서는 데 도달하고, 분명하게 소리의 위치를 알아내는 것은 어렵거나 불가능해집니다.

이 정보를 알고 있는 채로, 우리는 하나의 채널 내에서 방향성을 결정하는 데 쓰이지 않는 주파수들을 병합함으로써 스테레오 오디오 신호를 근사적으로 표현할 수 있고, 그리고 나서 소리의 방향성을 나타내는 정보를 포함할 수 있습니다. 이것은 표현하는 데 더 적은 비트를 요구하나, 선천적으로 조금 손실적입니다.

같이 보기
-----

* 웹에서 사용되는 오디오 코덱에 대한 가이드 (en-US)