shopkeeper/korean_wiki_content_only_120125 huggingface dataset:
원래 사용 목적 중 하나는 웹 폼이라고도 알려진 HTML 폼의 내용을 담는 것이었다. 특히, codice_3, codice_4, codice_5 필드를 포함하는 폼이 제출될 때, 필드의 내용은 다음과 같이 쿼리 문자열로 인코딩된다.
명확한 표준은 없지만, 대부분의 웹 프레임워크는 단일 필드에 여러 값을 연결할 수 있도록 허용한다(예: codice_9).
폼의 각 필드에 대해 쿼리 문자열은 codice_10 쌍을 포함한다. 웹 폼에는 사용자에게 보이지 않는 필드가 포함될 수 있으며, 이러한 필드는 폼이 제출될 때 쿼리 문자열에 포함된다.
이 규칙은 W3C 권장 사항이다. 1999년 권장 사항에서 W3C는 모든 웹 서버가 앰퍼샌드 외에 쌍반점 구분자를 지원할 것을 권장했다. 이는 HTML 문서 내의 URL에서 앰퍼샌드를 이스케이프할 필요 없이 application/x-www-form-urlencoded 쿼리 문자열을 허용하기 위함이었다. 2014년부터 W3C는 쿼리 구분자로 앰퍼샌드만 사용할 것을 권장한다.
폼 콘텐츠는 폼 제출 방식이 GET일 때만 URL의 쿼리 문자열로 인코딩된다. 제출 방식이 POST일 때도 기본적으로 동일한 인코딩이 사용되지만, 결과는 수정된 URL에 포함되는 대신 HTTP 요청 본문으로 제출된다.
인덱스 검색.
HTML 폼이 HTML에 추가되기 전에는 브라우저가 – 요소를 단일 행 텍스트 입력 컨트롤로 렌더링했다. 이 컨트롤에 입력된 텍스트는 기본 URL 또는 속성으로 지정된 다른 URL에 대한 GET 요청에 쿼리 문자열로 추가되어 서버로 전송되었다. 이는 웹 서버가 제공된 텍스트를 쿼리 기준으로 사용하여 일치하는 페이지 목록을 반환할 수 있도록 하기 위함이었다.
인덱스 검색 컨트롤에 입력된 텍스트가 제출되면 다음과 같이 쿼리 문자열로 인코딩된다.
요소는 더 이상 사용되지 않으며 대부분의 브라우저가 이를 지원하거나 렌더링하지 않지만, 인덱스 검색의 흔적은 여전히 남아 있다. 예를 들어, 이는 브라우저 URL 퍼센트 인코딩 내에서 더하기 기호 'codice_11'를 특별히 처리하는 원인이다(현재 인덱스 검색이 폐기되면서 codice_13과 거의 중복된다). 또한 일부 CGI를 지원하는 웹 서버(예: 아파치 HTTP 서버)는 쿼리 문자열에 등호 'codice_6'가 포함되어 있지 않으면 쿼리 문자열을 명령줄 인수로 처리한다(CGI 1.1 섹션 4.4에 따름). 일부 CGI 스크립트는 HTML에 포함된 URL에 대한 이러한 역사적인 동작에 여전히 의존하고 사용한다.
URL 인코딩.
일부 문자는 URL의 일부가 될 수 없으며(예: 공백), 일부 다른 문자는 URL에서 특별한 의미를 가진다. 예를 들어, 문자 codice_15는 문서의 하위 섹션(또는 프래그먼트)을 추가로 지정하는 데 사용될 수 있다. HTML 폼에서 문자 codice_6는 이름과 값을 구분하는 데 사용된다. URI 일반 구문은 이 문제를 해결하기 위해 URL 인코딩을 사용하는 반면, HTML 폼은 모든 그러한 문자에 퍼센트 인코딩을 적용하는 대신 일부 추가 대체를 수행한다. SPACE는 'codice_11' 또는 "codice_13"으로 인코딩된다.
HTML 5는 "GET" 메서드로 HTML 폼을 웹 서버에 제출하기 위한 다음 변환을 지정한다. 다음은 알고리즘에 대한 간략한 요약이다.
틸데("codice_27")에 해당하는 옥텟은 RFC3986에 따라 쿼리 문자열에서 허용되지만, HTML 폼에서는 "codice_34"로 퍼센트 인코딩되어야 한다.
SPACE를 'codice_11'로 인코딩하고 "그대로" 문자를 선택하는 것은 이 인코딩을 RFC 3986과 구별한다.
HTML 페이지에 다음과 같이 폼이 포함되어 있다면:
&lt;form action="/cgi-bin/test.cgi" method="get"&gt;
&lt;input type="text" name="first" /&gt;
&lt;input type="text" name="second" /&gt;
&lt;input type="submit" /&gt;
사용자가 두 텍스트 상자에 "this is a field"와 "was it clear (already)?"라는 문자열을 입력하고 제출 버튼을 누르면, 프로그램 codice_36 (위 예시에서 codice_37 요소의 codice_38 속성으로 지정된 프로그램)는 다음 쿼리 문자열을 받게 된다.
codice_39.
폼이 서버에서 CGI 스크립트에 의해 처리되는 경우, 스크립트는 일반적으로 쿼리 문자열을 codice_40이라는 환경 변수로 받게 된다.
쿼리 문자열을 받는 프로그램은 그 일부 또는 전체를 무시할 수 있다. 요청된 URL이 프로그램이 아닌 파일에 해당하면 전체 쿼리 문자열은 무시된다. 그러나 쿼리 문자열의 사용 여부와 관계없이 이를 포함한 전체 URL은 서버 로그 파일에 저장된다.
이러한 사실을 통해 쿼리 문자열은 HTTP 쿠키와 유사한 방식으로 사용자를 추적하는 데 사용될 수 있다. 이를 위해서는 사용자가 페이지를 다운로드할 때마다 고유 식별자를 선택하여 페이지에 포함된 모든 링크의 URL에 쿼리 문자열로 추가해야 한다. 사용자가 이 링크 중 하나를 따라가자마자 해당 URL이 서버에 요청된다. 이런 식으로 이 페이지의 다운로드는 이전 페이지와 연결된다.
예를 들어, 다음이 포함된 웹 페이지가 요청될 때:
&lt;a href="foo.html"&gt;see my page!&lt;/a&gt;
&lt;a href="bar.html"&gt;mine is better&lt;/a&gt;
codice_41와 같은 고유한 문자열이 선택되고, 페이지는 다음과 같이 수정된다.
&lt;a href="foo.html?e0a72cb2a2c7"&gt;see my page!&lt;/a&gt;
&lt;a href="bar.html?e0a72cb2a2c7"&gt;mine is better&lt;/a&gt;
쿼리 문자열을 추가해도 페이지가 사용자에게 표시되는 방식은 변경되지 않는다. 예를 들어, 사용자가 첫 번째 링크를 따라가면 브라우저는 서버에 codice_42 페이지를 요청하고, 서버는 codice_43 뒤의 내용을 무시하고 예상대로 codice_44 페이지를 보내면서 해당 링크에도 쿼리 문자열을 추가한다.
이런 식으로 이 사용자의 모든 후속 페이지 요청은 동일한 쿼리 문자열 codice_41을 전달하여 이 모든 페이지가 동일한 사용자에 의해 조회되었음을 확인할 수 있다. 쿼리 문자열은 종종 웹 버그와 함께 사용된다.
추적에 사용되는 쿼리 문자열과 HTTP 쿠키의 주요 차이점은 다음과 같다.
HTTP 사양에 따르면:
요청 줄 길이에 대한 다양한 임시적인 제한이 실제로 발견된다. 모든 HTTP 발신자와 수신자는 최소한 8000 옥텟의 요청 줄 길이를 지원하는 것이 권장된다.
URL이 너무 길면 웹 서버는 414 Request-URI Too Long HTTP 상태 코드로 실패한다.
이러한 문제에 대한 일반적인 해결책은 GET 대신 POST를 사용하고 매개변수를 요청 본문에 저장하는 것이다. 요청 본문의 길이 제한은 일반적으로 URL 길이 제한보다 훨씬 높다. 예를 들어, POST 크기 제한은 기본적으로 IIS 4.0에서는 2MB이고 IIS 5.0에서는 128KB이다. Apache2에서는 codice_46 지시어를 사용하여 제한을 구성할 수 있으며, 이는 요청 본문에 허용되는 바이트 수를 0(무제한 의미)에서 2147483647(2GB)까지 지정한다.
타이포스쿼팅(Typosquatting)은 URL 하이재킹, 스팅 사이트, 사촌 도메인 또는 가짜 URL이라고도 불리며, 도메인 사냥꾼의 한 형태이자 브랜드 재킹일 수 있다. 인터넷 사용자가 웹 브라우저에 웹사이트 주소를 입력할 때 저지르는 오타와 같은 실수에 의존한다. 사용자가 실수로 잘못된 웹사이트 주소를 입력하면 사이버 사기꾼이 소유한 대체 웹사이트를 포함하여 어떤 URL로든 연결될 수 있다.
타이포스쿼터의 URL은 일반적으로 피해자 사이트 주소와 유사하며, 타이포스쿼팅 사이트는 다음과 같은 형태를 띨 수 있다.
유사한 오용 사례:
타이포스쿼터의 사이트에 접속하면 사용자는 복사되거나 유사한 로고, 웹사이트 레이아웃 또는 콘텐츠를 통해 실제로 실제 사이트에 접속했다고 착각할 수 있다. 스팸 이메일은 때때로 타이포스쿼팅 URL을 사용하여 사용자를 예를 들어 특정 은행 사이트처럼 보이는 악성 사이트로 유인한다.
타이포스쿼터가 오타 도메인을 구매하는 데는 몇 가지 다른 이유가 있다.
버라이즌 커뮤니케이션스, 루프트한자, 레고 그룹을 비롯한 많은 기업들이 타이포스쿼팅된 도메인 이름을 적극적으로 추적하는 것으로 명성을 얻었다. 예를 들어, 레고는 UDRP 절차를 통해 309건의 사례를 처리하는 데 약 를 지출했다.
유명인들도 자신의 도메인 이름을 추적해 왔다. 대표적인 예로는 농구 선수 디르크 노비츠키의 DirkSwish.com에 대한 UDRP 소송과 배우 에바 롱고리아의 EvaLongoria.org에 대한 UDRP 소송이 있다.
Google.com의 오타 버전인 Goggle.com은 2006년 컴퓨터 보안 회사 맥아피의 웹 안전 홍보 대상이었다. 당시 이 사이트에 접속하면 드라이브 바이 다운로드를 통해 스파이셰리프라는 불법 스파이웨어 프로그램과 같은 상당량의 악성 소프트웨어가 설치되는 것을 묘사했다. 나중에 해당 URL은 google.com으로 리디렉션되었다. 2018년 확인 결과, 사용자들을 애드웨어 페이지로 리디렉션했으며, 2020년 애드가드가 호스팅하는 개인 DNS 확인자를 통해 사이트에 접속하려는 시도는 해당 페이지가 악성 소프트웨어로 식별되어 사용자 인터넷 보안을 위해 차단되었다. 2022년 중반에는 정치 블로그로 바뀌었다. 그러나 2025년 8월 현재 goggle.com은 더 이상 운영되지 않는다.
기업 타이포스쿼팅의 또 다른 예는 유튜브 사용자를 대상으로 하는 yuube.com으로, 이 URL을 악성 웹사이트나 페이지로 URL 리다이렉션하도록 프로그래밍하여 사용자에게 악성 "보안 검사 확장"을 추가하도록 요청한다. 마찬가지로, www.airfrance.com은 www.arifrance.com에 의해 타이포스쿼팅되어 사용자들을 할인 여행을 미끼로 하는 웹사이트로 유도했지만(현재는 에어 프랑스의 악성 소프트웨어 경고로 리디렉션된다), 다른 예로는 equifacks.com (Equifax.com), experianne.com (Experian.com), tramsonion.com (TransUnion.com)이 있다. 이 세 개의 타이포스쿼팅된 사이트는 코미디언 존 올리버가 자신의 쇼 존 올리버의 라스트 위크 투나잇(Last Week Tonight)을 위해 등록했다. 2019년에는 2020년 미국 대통령 선거와 관련된 550개 이상의 타이포스쿼팅이 발견되었다.
매그니버 랜섬웨어는 주로 크롬 및 엣지 사용자를 대상으로 도메인 입력 시 발생하는 오타를 악용한 타이포스쿼팅 방식으로 유포되고 있다.
2024년 동료 심사를 거친 연구는 이더리움 이름 서비스, 언스토퍼블 도메인, ADA핸들과 같은 블록체인 기반 명명 시스템에서 타이포스쿼팅에 대한 최초의 대규모 측정을 제공한다. 연구원들은 인기 있는 도메인 이름과 소셜 미디어 계정에 연결된 ID를 포함한 수천 건의 암호화폐 거래가 실수로 스쿼팅 주소로 전송된 것을 확인했다.
미국에서는 1999년 Anticybersquatting Consumer Protection Act (ACPA)에 타이포스쿼팅에 대처하기 위한 조항(섹션 3(a), 15 USC 1117을 수정하여 하위 섹션 (d)(2)(B)(ii) 포함)이 포함되어 있다.
2006년 4월 17일, 전도사 제리 폴웰은 크리스토퍼 람파렐로가 www.fallwell.com을 사용하도록 허용하는 결정을 미국 연방 대법원에서 재심사하는 데 실패했다. 팔웰의 이름에 대한 그럴듯한 오타에 의존하여, 람파렐로의 그라이프 사이트(gripe site)는 잘못 연결된 방문자들에게 근본주의 설교자의 동성애에 대한 신랄한 비난에 반박하기 위한 성경적 참고 자료를 제시한다. 람파렐로 대 폴웰 사건에서 고등 법원은 "상표 보유자를 비판하는 불만 사이트의 도메인 이름에 상표를 사용하는 것은 사이버 스쿼팅에 해당하지 않는다"는 2005년 미국 제4순회항소법원의 의견을 유지시켰다.
WIPO 해결 절차.
UDRP에 따라, 상표 보유자는 WIPO에 타이포스쿼터(일반적인 사이버 스쿼터와 마찬가지로)에 대한 소송을 제기할 수 있다. 소송인은 등록된 도메인 이름이 자신의 상표와 동일하거나 오인 혼동의 우려가 있으며, 등록자가 도메인 이름에 대한 합법적인 이익이 없고, 도메인 이름이 악의로 사용되고 있음을 입증해야 한다.
인라인 링크(Inline linking, 핫링크, 피기백킹, 직접 링크, 오프사이트 이미지 캡처, 대역폭 도용, 또는 리칭, leeching)는 한 웹사이트의 연결된 객체(대개 이미지)를 다른 웹사이트의 웹 페이지에 사용하거나 삽입하는 행위를 말한다. 이 과정에서 두 번째 사이트는 객체를 직접 호스팅하지 않고 원본 소스에서 직접 로드하여 호스팅 사이트에 인라인 링크를 생성한다.
HTTP와 인라인 링크.
월드 와이드 웹의 기반 기술인 하이퍼텍스트 전송 프로토콜(HTTP)은 링크의 종류를 구분하지 않는다. 모든 링크는 기능적으로 동일하다. 결과적으로 리소스는 원래 위치에 관계없이 모든 서버에서 링크되어 웹 페이지로 로드될 수 있다.
웹사이트를 방문할 때 브라우저는 먼저 웹 페이지의 텍스트 콘텐츠가 포함된 HTML 문서를 다운로드한다. 이 문서에는 다른 HTML 파일, 이미지, 스크립트 또는 스타일시트를 포함한 추가 리소스가 참조될 수 있다. HTML 내에서 codice_1 태그는 페이지에 표시될 이미지의 URL을 지정한다. codice_1 태그가 서버를 지정하지 않으면 웹 브라우저는 이미지가 부모 페이지와 동일한 서버에 호스팅되어 있다고 가정한다(예: codice_3). codice_1 태그에 절대 URL이 포함되어 있으면 브라우저는 외부 서버에서 이미지를 검색한다(예: codice_5).
브라우저가 이러한 이미지가 포함된 HTML 페이지를 다운로드하면, 브라우저는 원격 서버에 연락하여 이미지 콘텐츠를 요청한다.
한 사이트 내에서 다른 사이트의 콘텐츠를 표시하는 기능은 웹의 하이퍼텍스트 미디어의 원래 디자인의 일부이다. 일반적인 용도는 다음과 같다.
논란이 되는 용도.
사이트 간의 경계가 모호해지면 사이트가 사용자의 기대치를 위반할 때 다른 문제가 발생할 수 있다. 다른 경우에는 인라인 링크가 악의적인 목적으로 사용될 수 있다.
대부분의 웹 브라우저는 인라인 링크에 대한 URL을 맹목적으로 따르는데, 이는 빈번한 보안 불만 사항이다. 삽입된 이미지는 사용자를 추적하거나 제3자에게 정보를 전달하기 위한 웹 버그로 사용될 수 있다. 많은 광고 필터링 브라우저 도구는 이러한 동작을 다양한 정도로 제한한다.
일부 서버는 HTTP 리퍼러 헤더를 사용하여 핫링크를 감지하고 예상 이미지 또는 미디어 클립 대신 비난 메시지를 동일한 형식으로 반환하도록 프로그래밍되어 있다. 대부분의 서버는 호스팅된 미디어를 인라인 링크로부터 부분적으로 보호하도록 구성할 수 있는데, 일반적으로 미디어를 제공하지 않거나 다른 파일을 제공하는 방식이다.
URL 재작성은 이미지 및 미디어에 대한 핫링크 시도를 거부하거나 대체 리소스로 리디렉션하는 데 자주 사용된다(예: 아파치 HTTP 서버의 mod_rewrite). 비디오 파일, 음악 파일, 애니메이션(예: 어도비 플래시)을 포함한 대부분의 전자 미디어는 이런 방식으로 리디렉션될 수 있다.
다른 해결책들은 일반적으로 URL 재작성과 일부 사용자 정의 복잡한 서버 측 스크립팅을 결합하여 짧은 시간 동안 핫링크를 허용하거나, 더 복잡한 설정에서는 핫링크를 허용하되 품질과 크기가 줄어든 대체 이미지를 반환하여 원격 서버에서 요청될 때 대역폭 부하를 줄인다. 모든 핫링크 방지 조치는 제3자 웹사이트의 사용자 경험을 저하시킬 위험이 있다.
인라인 링크로 인한 저작권 문제.
저작권법적 고려사항과 관련하여 인라인 링크에 대한 가장 중요한 법적 사실은 인라인 링커가 이미지 파일의 복사본을 자체 인터넷 서버에 배치하지 않는다는 것이다. 오히려 인라인 링커는 이미지 소유자가 이미지 파일을 배치한 서버를 가리키는 포인터를 자체 인터넷 서버에 배치한다. 이 포인터는 사용자의 브라우저가 소유자의 서버로 이동하여 사용자 컴퓨터로 이미지 파일을 가져오도록 한다. 미국 법원은 이를 저작권 분석에서 결정적인 사실로 간주했다. 따라서 Perfect 10, Inc. v. Amazon.com, Inc.에서, 미국 제9연방항소법원은 인라인 링크가 미국 저작권법을 위반하지 않는 이유를 다음과 같이 설명했다.
구글은...사용자의 컴퓨터 화면에 나타나는 인라인 링크된 이미지를 저작권법상 전체 크기의 침해 사진 이미지 사본으로 표시하지 않는다. 구글의 컴퓨터는 사진 이미지를 저장하지 않으므로, 구글은 저작권법상 이미지 사본을 가지고 있지 않다. 다시 말해, 구글은 "저작물이 고정되어...그로부터 저작물을 인지, 복제 또는 달리 전달할 수 있는...어떤 물질적 대상"도 가지고 있지 않으므로 사본을 전달할 수 없다. 구글은 이미지 사본을 전달하는 대신, 사용자 브라우저를 전체 크기 사진 이미지를 저장하는 웹사이트 게시자의 컴퓨터로 안내하는 HTML 지침을 제공한다. 이러한 HTML 지침을 제공하는 것은 사본을 보여주는 것과 동일하지 않다. 첫째, HTML 지침은 텍스트 줄이지 사진 이미지가 아니다. 둘째, HTML 지침 자체는 침해 이미지가 사용자 컴퓨터 화면에 나타나게 하지 않는다. HTML은 단순히 이미지 주소를 사용자 브라우저에 제공한다. 브라우저는 침해 이미지를 저장하는 컴퓨터와 상호 작용한다. 침해 이미지가 사용자 컴퓨터 화면에 나타나게 하는 것은 이 상호 작용이다. 구글은 침해 이미지에 대한 사용자의 접근을 용이하게 할 수 있다. 그러나 그러한 지원은 기여 책임 문제만 제기하며 저작권 소유자의 표시 권리에 대한 직접 침해를 구성하지 않는다. ...인라인 링크와 프레이밍이 일부 컴퓨터 사용자에게 단일 구글 웹 페이지를 보고 있다고 믿게 할 수 있지만, 저작권법은...[그러한] 행위로부터 저작권 보유자를 보호하지 않는다...
웹 스타일 시트(style sheet)는 웹 디자인에서 콘텐츠와 표현의 분리의 한 형태로, 웹 페이지의 마크업(HTML 또는 XHTML)이 페이지의 의미론적 콘텐츠와 구조를 포함하지만 시각적 레이아웃(스타일)은 정의하지 않는다. 대신, 스타일은 CSS 또는 XSLT와 같은 스타일시트 언어를 사용하여 외부 스타일 시트 파일에서 정의된다. 이 디자인 접근 방식은 페이지의 마크업이 스타일과 구조를 모두 정의했던 이전 방법론을 대체했기 때문에 "분리"로 식별된다.
이 방법론의 기본 철학은 관심사 분리의 특정 사례이다.
스타일과 콘텐츠의 분리는 장점이 있지만, 널리 사용되는 웹 브라우저의 CSS 구현 개선 후에야 실용적이 되었다.
전반적으로 스타일 시트를 활용하는 사이트의 사용자 경험은 해당 기술을 사용하지 않는 사이트보다 일반적으로 더 빠르다. '전반적으로' 첫 페이지는 스타일 시트와 콘텐츠를 모두 전송해야 하므로 더 느리게 로드될 수 있다. 이후 페이지는 스타일 정보를 다운로드할 필요가 없으므로 더 빠르게 로드된다. CSS 파일은 이미 브라우저의 캐시에 있기 때문이다.
모든 프레젠테이션 스타일을 하나의 파일에 담아두면 유지보수 시간을 줄이고 오류 발생 가능성을 낮춰 프레젠테이션 일관성을 향상시킬 수 있다. 예를 들어, 특정 유형의 텍스트 요소와 관련된 글꼴 색상은 단일 파일에서 짧은 문자열 하나만 변경하면 전체 웹사이트에서 지정하고 쉽게 수정할 수 있다. 각 개별 페이지에 스타일을 포함하는 다른 접근 방식은 모든 파일을 번거롭고 시간이 많이 걸리며 오류가 발생하기 쉬운 편집을 요구할 것이다.
XHTML 또는 HTML과 함께 CSS를 사용하는 사이트는 다양한 브라우저(크롬, 인터넷 익스플로러, 모질라 파이어폭스, 오페라, 사파리 등)에서 유사하게 보이도록 조정하기 쉽다.
CSS를 사용하는 사이트는 Lynx와 같이 그래픽 콘텐츠를 표시할 수 없는 브라우저 또는 CSS를 사용할 수 없을 정도로 매우 오래된 브라우저에서 "정상적으로 저하"된다. 브라우저는 CSS 3 문장과 같이 이해하지 못하는 CSS를 무시한다. 이를 통해 다양한 사용자 에이전트가 스타일 시트를 렌더링할 수 없거나 그래픽 기능을 염두에 두고 설계되지 않았더라도 사이트의 콘텐츠에 액세스할 수 있다. 예를 들어, 점자 디스플레이를 출력에 사용하는 브라우저는 레이아웃 정보를 완전히 무시할 수 있으며, 사용자는 여전히 모든 페이지 콘텐츠에 액세스할 수 있다.
페이지의 레이아웃 정보가 외부에 저장되어 있으면, 사용자는 레이아웃 정보를 완전히 비활성화하여 사이트의 기본 콘텐츠를 여전히 읽을 수 있는 형태로 남겨둘 수 있다. 사이트 작성자는 여러 스타일 시트를 제공할 수도 있으며, 이를 통해 콘텐츠를 변경하지 않고도 사이트의 모양을 완전히 변경할 수 있다.
대부분의 최신 웹 브라우저는 사용자에게 자체 스타일 시트를 정의할 수 있도록 허용하며, 여기에는 작성자의 레이아웃 규칙을 재정의하는 규칙을 포함할 수 있다. 이를 통해 사용자는 예를 들어 방문하는 모든 페이지의 모든 하이퍼링크를 굵게 표시할 수 있다. 스타일리시 및 스타일러스와 같은 브라우저 확장 기능이 이러한 사용자 스타일 시트 관리를 용이하게 하기 위해 만들어졌다.
의미론적 파일에는 작성자가 전달하려는 의미만 포함되므로 문서 콘텐츠의 다양한 요소의 스타일이 매우 일관적이다. 예를 들어, 제목, 강조된 텍스트, 목록 및 수학적 표현은 모두 외부 스타일 시트에서 일관되게 적용된 스타일 속성을 받는다. 작성자는 작성 시점에 스타일 속성에 대해 걱정할 필요가 없다. 이러한 프레젠테이션 세부 사항은 프레젠테이션 순간까지 연기될 수 있다.
프레젠테이션 세부 정보를 프레젠테이션 시점까지 연기하는 것은, 새로운 매체에 맞춰 이미 준비된 새로운 스타일 시트를 적용하고 의미론적 문서의 요소 또는 구조적 어휘와 일치시키기만 하면 문서를 완전히 다른 프레젠테이션 매체에 쉽게 재활용할 수 있음을 의미한다. 웹 페이지용으로 신중하게 작성된 문서는 단순히 새로운 스타일 시트를 적용하는 것만으로 헤더와 푸터, 페이지 번호, 생성된 목차를 포함하는 하드 바운드 볼륨으로 쉽게 인쇄될 수 있다.
오늘날의 실질적인 단점.
2006년 현재, 사양(예: XHTML, XSL, CSS) 및 이러한 사양을 구현하는 소프트웨어 도구는 초기 성숙 단계에 도달하고 있다. 따라서 콘텐츠와 스타일을 분리하는 이 방법을 채택하려는 작성자가 직면하는 몇 가지 실질적인 문제가 있다.
구문 분석 및 생성 도구 없는 협소한 채택.
스타일 사양은 상당히 성숙하고 계속해서 성숙해지고 있지만, 소프트웨어 도구는 적응 속도가 느렸다. 대부분의 주요 웹 개발 도구는 여전히 혼합된 프레젠테이션-콘텐츠 모델을 채택하고 있다. 따라서 작업을 위한 GUI 기반 도구를 찾는 작성자와 디자이너는 의미론적 웹 방식을 따르기 어렵다는 것을 알게 된다. GUI 도구 외에도 일반화된 스타일 시트를 위한 공유 저장소가 이러한 방법의 채택을 도울 것이다.
아이패드 에어(iPad Air)는 다음 뜻이 있다.
소니 태블릿 P(Sony Tablet P, 이전 코드명: 소니 S2)는 소니그룹이 소니 태블릿 시리즈의 일부로 제조한 태블릿 컴퓨터이다.
이 장치는 와이드 스크린을 가진 소니 바이오 P의 안드로이드 버전으로 출시되었다.
이 장치는 VAIO P 시리즈를 닮은 힌지형 클램셸 레이아웃으로 결합된 두 개의 터치스크린 상호 작동 디스플레이를 가지고 있다. 2011년 11월에 소니 태블릿 시리즈의 두 번째로 사용 가능한 멤버로 출시되었다. 권장 소매가는 599달러이다.
독특한 클램셸 디자인 덕분에 장치를 반으로 접어 주머니에 넣을 수 있었지만, 이 기능으로 인해 화면이 커다란 검은색 힌지로 반으로 나뉘어 게임을 하거나 책을 읽는 것이 불편해졌고 이는 태블릿 P의 가장 심각한 결함으로 지적되었다. 태블릿 P는 2012년 말까지 북미에서 단종되었으며, 얼마 후 안드로이드 4.0.4로의 마지막 소프트웨어 업데이트를 받았다.
더 버지는 혁신적인 디자인을 칭찬했지만, 듀얼 스크린에 최적화되지 않은 타사 앱은 좋지 않은 경험을 제공한다고 언급했다. 이 제품은 회고적으로 실패한 제품으로 불렸다.
전자 플라이트 백(Electronic flight bag, EFB)은 조종 크루가 종이를 적게 사용하여 비행 관리 작업을 더 쉽고 효율적으로 수행할 수 있도록 돕는 전자 정보 관리 장치이다. 여기에는 조종 크루 운용 매뉴얼, 항해 차트 등 조종사의 기내 플라이트 백에서 흔히 볼 수 있는 참고 자료가 포함된다. 또한 EFB는 이륙 성능 계산과 같이 일반적으로 수동으로 수행되는 다른 기능을 자동화하기 위한 특수 목적 소프트웨어 애플리케이션을 호스팅할 수 있다. EFB라는 이름은 조종사가 조종실로 가져가는 무거운 (최대 이상) 서류 가방인 전통적인 조종사의 플라이트 백에서 유래했다.
EFB는 주로 조종실/비행갑판 또는 객실에서 사용하도록 고안되었다. 대형 항공기와 터빈 항공기의 경우, FAR 91.503은 항공기에 항해 차트가 비치되어야 한다고 규정한다. 운영자의 항해 차트 정보의 유일한 출처가 EFB에 포함되어 있다면, 운영자는 EFB가 고도에 관계없이 감압 이벤트 중에도 계속 작동하며 그 후에도 작동함을 입증해야 한다.
초기 EFB의 전신은 1990년대 초 페덱스의 개별 조종사들이 개인 노트북을 사용하여 항공기 성능 계산을 수행했던 것이다. 이들은 공항 성능 노트북 컴퓨터라고 불렸고 상업용 기성 컴퓨터였으며 휴대용으로 간주되었다.
조종사의 전체 키트 가방을 대체하기 위해 특별히 설계된 최초의 진정한 EFB는 1999년 앤젤라 매슨이 전자 키트 가방(EKB)으로 특허를 받았다. 2003년 10월 KLM 항공은 보잉 777 항공기에 최초로 설치된 EFB를 수락했다. 보잉 EFB 하드웨어는 아스트로노틱스 코퍼레이션 오브 아메리카에서 제작했으며, 소프트웨어 애플리케이션은 젭슨과 보잉이 모두 제공했다. 2005년, 최초의 상업용 Class 2 EFB가 Avionics Support Group, Inc.에 발행되었으며, EFB의 일부로 Constant Friction Mount(cfMount)가 포함되었다. 이 설치는 마이애미 에어의 보잉 B737NG에서 수행되었다.
2009년 콘티넨털 항공은 Class 2 전자 플라이트 백 플랫폼에서 "자체 항공기" 위치를 표시하는 젭슨 공항 지표면 이동 지도(AMM)를 사용하여 세계 최초의 비행을 성공적으로 완료했다. AMM 애플리케이션은 고해상도 데이터베이스를 사용하여 공항 지도를 동적으로 렌더링한다.
개인 컴퓨팅 기술이 더욱 소형화되고 강력해짐에 따라, EFB는 전 세계의 모든 항공 차트를 단일 3파운드(1.4kg) 컴퓨터에 저장할 수 있게 되었다. 이는 전 세계 종이 차트에 일반적으로 필요한 80파운드(36kg)에 비해 크게 줄어든 무게이다. EFB를 사용하면 안전성이 향상되고, 승무원이 운용 절차 및 비행 관리 정보에 더 쉽게 접근할 수 있으며, 항공승무원이 더 안전한 이착륙을 위한 항공기 성능과 적재 계획을 위한 항공기 중량 및 균형을 정확하게 계산할 수 있도록 하여 안전을 강화한다.
공군특수작전사령부 (AFSOC)는 2011년 12월에 출시된 3,000대 이상의 아이패드 기반 EFB 초기 물량을 구매했다. 비슷한 구매로, 항공 수송 사령부는 최대 18,000대의 아이패드 기반 EFB 계약을 시작했다. 공군특수작전사령부는 전 세계 모든 사용자에게 NGA(National Geo-Spatial Intelligence Agency)의 월간 비행 정보 간행물(FLIP) 데이터셋을 전송하는 보안 방법을 내부적으로 개발했다.
2011년 조종실 아이패드를 EFB로 시범 사용한 후, 델타 항공은 2013년 8월 조종사들이 개인 태블릿을 EFB로 사용할 수 있도록 허용하는 정책을 교체할 것이라고 발표했다. 델타는 2월 FAA 승인 후 2014년 5월까지 모든 조종사에게 새로운 인증된 EFB를 제공할 계획이었다. EFB로 사용되는 아이패드의 초기 파손 위험은 견고한 케이스 설계로 해결되었다. 그러나 AFSOC의 아이패드 구매는 러시아산 소프트웨어 조달 문제가 최종 사용자에게 잠재적인 위험을 노출할 수 있다는 보안 우려로 인해 2012년 2월 취소되었다.
EFB는 처음에는 여러 하드웨어 클래스와 소프트웨어 유형으로 나뉘었다.
기존 EFB 하드웨어 클래스는 다음과 같다:
EFB는 처음에 세 가지 소프트웨어 범주로 분류된 광범위한 애플리케이션을 호스팅할 수 있다.
Type C 애플리케이션은 감항성 요구 사항의 적용을 받는 것으로 간주되었으며, 따라서 DO-178/ED-12 목표에 따라 개발되어야 하며 Class 3 EFB에서 실행되어야 한다.
현재 EFB는 "휴대용"(PED) 또는 "설치형"으로 분류된다. 휴대용은 이전 Class 1 및 2의 구분을 통합한 것으로 볼 수 있으며, 설치형은 기존 Class 3와 동일하다. 이러한 단순화는 혼란을 줄이고 이미 발표된 EASA 및 ICAO 지침과 조화를 이루기 위해 이루어졌다.
2017년 AC 120-76D가 발표되면서 Type C 애플리케이션에 대한 언급이 삭제되었으며, 이러한 기능은 더 이상 EFB 기능이 아니다.
미국 연방 항공국.
FAR Part 91 운영자(개인 및 기업 운영자를 포함하여 영리 목적으로 비행하지 않는 자)는 조종사-기장 권한을 사용하여 PED인 EFB 사용을 승인할 수 있지만, OpSpecs(Part 135, Part 121)를 사용하는 운영자는 다음 요구 사항에 따라 OpSpecs 프로세스를 통해 운영 승인을 받아야 한다.
유럽 연합 항공 안전국.
유럽 내 운영자를 위한 전자 플라이트 백(EFB)의 감항성 및 운영 고려 사항에 대한 지침은 EASA AMC 20-25가 적용된다.
영국 군용 항공국.
영국 국방부는 Regulatory Article 1340에 설명된 대로 EFB의 감항성을 특정 항공기 유형에 대해 '항공 시스템의 기본이 아닌 장비(ENBAS)'로 분류하는 방식을 취한다. 형식 감항 당국(TAA)과 지원 전달팀은 EFB 장치 자체가 해당 항공기의 감항성에 부정적인 영향을 미치지 않도록 이 승인을 담당한다. 특정 애플리케이션 사용 승인에 관해서는 항공 책임자(ADH) 체인의 책임이다.
EFB는 다음 뜻이 있다.
존 조지프 오브라이언(, 1866년 7월 13일~1913년 5월 13일)은 캐나다의 프로 야구 선수로, 포지션은 2루수였다. 1891년부터 1899년까지 메이저 리그 베이스볼(MLB)의 브루클린 그룸스, 시카고 콜츠, 루이빌 커늘스, 워싱턴 세너터스, 볼티모어 오리올스, 피츠버그 파이리츠에서 선수로 뛰었다. 마이너 리그에서도 오랜 기간 선수 생활을 이어갔으며, 1904년에는 베이츠 칼리지 야구부의 감독을 맡았다.
픽션북(FictionBook)은 러시아에서 시작되어 인기를 얻은 개방형 XML 기반 전자책 형식이다. FictionBook 파일은 버전에 따라 또는 파일 확장자를 갖는다. 모든 FB2/FB3 지원 리더는 ZIP 압축 FictionBook 파일( 또는 )도 지원한다.
FictionBook2 형식은 전자책의 레이아웃을 정의하기보다는 전자책의 구조를 설명한다. 예를 들어, 에피그래프, 구절 및 인용문을 위한 특별한 태그가 있다. 저자 이름, 제목, 출판사 등 모든 전자책 메타데이터도 전자책 파일에 존재한다. 이로 인해 이 형식은 자동 처리, 색인 생성, 전자책 컬렉션 관리 및 다른 형식으로의 쉬운 자동 변환에 편리하다.
소프트웨어 및 하드웨어 지원.
FB2는 전자책 단말기인 FBReader, AlReader, Haali Reader, STDU Viewer, CoolReader, 아큘러, Ectaco jetBooks, IOS용 Documents 등 일부에서 지원된다. 파이어폭스는 FB2 Reader 확장을 설치하여 FictionBook2를 읽을 수 있다. 많은 하드웨어 공급업체가 펌웨어에서 FictionBook2를 지원한다: 유럽의 BeBook One, BeBook Mini 및 BeBook Club (및 기타 Hanlin V3 및 V5 기반 장치), 모든 PocketBook Readers, COOL-ER 장치, Cybook Opus]] 및 Cybook Gen3, ASUS Eee Reader DR900. Hanvon N516 디자인 기반 장치는 사용자 지정 OpenInkpot 펌웨어를 설치하면 FictionBook을 읽을 수 있다. Azbooka 516의 경우 공장 기본값이다. 아마존의 아마존 킨들, 반스 &amp; 노블의 반스 &amp; 노블 눅, 소니 장치는 FictionBook을 직접 지원하지 않는다.
FictionBook2 파일( 및 )로의 변환 및 변환은 크로스 플랫폼 전자책 관리 소프트웨어인 캘리버를 통해 가능하다. FictionBook2 형식으로의 변환 및 변환은 Pandoc을 통해서도 가능하다.
FictionBook3.
FictionBook3는 FictionBook2를 확장하기 위한 베타 제안이다.
FictionBook2와 FictionBook3는 두 가지 면에서 다르다: FB2는 단일 XML 파일로 구성되어 있으며, 그림은 Base64 인코딩된 "이진" 블록으로 내장되어 추가 파일이 필요 없다. FB3는 ePub 형식과 유사한 디렉터리 구조를 가지며 멀티미디어 콘텐츠의 레이아웃 및 임베딩을 통합한다.
FB3는 레이아웃 기능을 추가하고 그림을 Base64 인코딩된 블록으로 내장할 필요성을 제거하지만, 대부분 FB2에서 확립된 개념을 따른다.
2025년 8월 현재 2008년 이후로 베타 사양에 대한 업데이트가 없으며 인기 있는 전자책 리더 소프트웨어는 이를 지원하지 않는다.
소니 태블릿 S(Sony Tablet S)는 2011년 9월 소니가 출시한 태블릿 컴퓨터이다. "독특한 비대칭 디자인"을 특징으로 하는 태블릿 S는 구글의 안드로이드 3.1 허니콤 운영체제를 실행하며, 멀티터치 디스플레이, 1 GHz 엔비디아 테그라 2 듀얼 코어 프로세서, 와이파이 기능, 전면 및 후면 카메라, 블루투스, 적외선 센서를 갖추고 있다. 또한 소니 엔터테인먼트 네트워크에 접속할 수 있도록 구성되어 있으며, PlayStation Certified 및 DLNA 호환된다. 태블릿 S는 소니의 첫 번째 현대 태블릿 컴퓨터였다. 이 제품은 소니의 새로운 자회사인 소니 모바일이 개발할 엑스페리아 태블릿 S로 대체되었다.
태블릿 S의 주요 특징은 기기 두께가 로 얇아지는 "독특한 비대칭 디자인"이다. 이러한 "랩" 효과는 "뒷주머니에 구겨 넣은 펼쳐진 문고판이나, 한 페이지가 보이도록 뒤로 접힌 잡지"를 연상시키며, 들고 있을 때 토크의 양을 줄여준다. 소니는 이 "무게 중심이 다른 디자인"이 "안정성과 그립감을 제공하며, 안정감과 가벼움을 선사하여 몇 시간 동안 편안하게 사용할 수 있도록 한다"고 주장한다.
태블릿 S는 , 1280×800 픽셀 해상도를 가진 TFT LCD를 사용하며, 소니의 독점적인 TruBlack 디스플레이 기술을 사용한다. 이는 회사의 브라비아 TV 라인업에서 사용되는 것과 동일한 기술이다.
이 태블릿은 1 GHz ARM Cortex-A9 듀얼 코어 프로세서와 ULP GeForce GPU로 구성된 엔비디아 테그라 T20 SoC를 사용하며, 1 GB RAM과 16 또는 32 GB의 내부 저장 공간, 그리고 최대 32 GB의 SD 메모리 카드 지원을 제공한다.
다른 온보드 기능으로는 가속도계, 3축 자이로스코프, 자기계 (디지털 나침반), GPS 수신기, 802.11b/g/n 와이파이, 블루투스 v2.1 + EDR, 적외선, Micro USB, 마이크, 3.5 mm 헤드폰 잭, 0.3 MP 전면 카메라 및 5 MP 후면 카메라가 포함된다.
다른 안드로이드 장치와 마찬가지로, 태블릿 S에는 하드웨어 내비게이션 버튼이 없으며, 모든 버튼은 지속적인 화면 버튼으로 구현된다. 장치에 있는 유일한 물리적 버튼은 한쪽의 움푹 들어간 부분에 있는 전원 버튼과 볼륨 로커이다.
이 태블릿은 독점적인 전원 커넥터를 사용한다.
태블릿 S1은 초기에 안드로이드 3.1 허니콤과 함께 출시되었지만, 출시 직후 3.2 업데이트가 제공되었다. 또한 4월 말 (일본과 미국에서) 안드로이드 4.0.3으로 업그레이드되었다. 이 태블릿은 맞춤형 운영체제 버전을 사용한다. 소니 장치에만 있는 기능 및 애플리케이션은 다음과 같다:
소니 태블릿 S는 PlayStation Certified 장치임에도 불구하고, PlayStation Store 업데이트로 인해 PS one 클래식을 구매할 수 없게 되었다. 대신, 태블릿 S 소유자는 오리지널 콘텐츠만 구매할 수 있게 되었다.
2012년 9월, 소니 태블릿 S는 안드로이드 4.0.3 릴리스 5a로 주요 업데이트를 받았다. 이 업데이트에는 다음과 같은 주요 변경 사항이 포함되었다.
소니 태블릿 S는 2013년 2월에 출시될 안드로이드 4.1 젤리빈으로의 업데이트가 확정되었다. 그러나 소니가 커뮤니티 게시판에 "1세대 태블릿(소니 태블릿 S)에 대한 젤리빈 업데이트 로드맵이 없다"는 게시물(나중에 삭제됨)을 올리면서 젤리빈 4.1 업데이트는 비공식적으로 취소되었다.
평론가들은 소니 태블릿 S의 독특한 ("완전히 새로워진") 디자인을 칭찬하며 대체로 긍정적인 평가를 내렸다. 월스트리트 저널은 "태블릿 S는 아이패드를 따라하려는 것처럼 보이지 않는, 신뢰할 수 있는 회사에서 나온 독특한 태블릿을 원하는 구매자들에게 어필할 것"이라고 말했고, PC 월드는 "[소니]는 오랜 세월 동안 디자인 감각을 잃지 않았으며, 이 모델은 소니의 독창성과 세련미를 절실히 필요로 하는 태블릿 시장에 가져왔다"고 평가했다. 시드니 모닝 헤럴드의 애셔 모세스(Asher Moses)는 이 제품을 "최고의 안드로이드 태블릿"이라고 불렀다.
부정적인 의견은 기기의 높은 가격과 낮은 빌드 품질에 집중되었다. 테크 블로그 기즈모도는 이를 "플라스틱 같음"이라고 표현하며, 소니가 무게를 줄이기 위해 품질이 낮은 재료를 사용하여 "매우 평범한 사진 촬영 중 심하게 긁혔다"고 지적하고, 떨어뜨리면 "백만 조각으로 부서질 것"이라고 평했다. 타임은 태블릿 S가 아이패드와 경쟁하려는 소니의 포부에 미치지 못한다고 보며, 평론가 재러드 뉴먼(Jared Newman)은 하워드 스트링어 소니 CEO의 발언을 인용하며 "태블릿 S가 스트링어가 생각하는 것이라면, 나는 소니의 미래를 위해 슬퍼할 것"이라고 말했다. 익스퍼트리뷰스(ExpertReviews)는 비디오 출력이 없는 것이 성가신 단점이라고 썼다. 일부 평론가들은 낮은 해상도 화면과 오래된 소프트웨어에 대해 태블릿을 비판했다.
태블릿 S는 소비자 기술협회(Consumer Electronics Association)의 CES 혁신 디자인 및 엔지니어링 어워드 2012에서 "태블릿, E-리더 및 넷북" 부문에서 수상의 영예를 안았다.
컴퓨터 망에서 링크-로컬 주소(Link-local address)는 로컬 링크, 즉 호스트가 연결된 서브네트워크 내의 통신에만 유효한 네트워크 주소이다. 링크-로컬 주소는 일반적으로 링크-로컬 주소 자동 구성으로 알려진 프로세스를 통해 자동으로 할당되며, 이는 자동 IP, 자동 사설 IP 주소 지정 (APIPA, IPv4에 특화), 및 무상태 주소 자동 구성 (SLAAC, IPv6에 특화)으로도 알려져 있다. 대부분의 링크-로컬 주소는 유니캐스트이지만, 항상 그런 것은 아니다. 예를 들어, ()로 시작하는 IPv6 주소와 ()로 시작하는 IPv4 주소는 링크-로컬인 멀티캐스트 주소이다.
링크-로컬 주소는 네트워크 세그먼트를 넘어 고유성이 보장되지 않는다. 따라서 라우터는 링크-로컬 소스 또는 목적지 주소를 가진 데이터 패킷을 전달하지 않는다.
IPv4 링크-로컬 유니캐스트 주소는 주소 블록 (부터 까지)에서 할당된다. IPv6에서는 유니캐스트 링크-로컬 주소가 블록 에서 할당된다.
주소 할당.
링크-로컬 주소는 관리자가 수동으로 할당하거나 자동 운영체제 절차에 의해 할당될 수 있다. 인터넷 프로토콜 (IP) 네트워크에서는 대개 무상태 주소 자동 구성을 사용하여 할당되며, 이 프로세스는 종종 추계학적 프로세스를 사용하여 링크-로컬 주소의 값을 선택하고, 각 세션에 대해 다른 의사 무작위 주소를 할당한다. 그러나 IPv6에서는 개인 정보 보호 및 보안상의 이유로 더 이상 사용되지 않지만, 인터페이스 MAC 주소에서 규칙 기반 방식으로 링크-로컬 주소를 파생할 수도 있다.
IPv4에서는 링크-로컬 주소가 일반적으로 동적 호스트 구성 프로토콜 (DHCP)과 같은 외부의 상태 유지 주소 구성 메커니즘이 없거나, 다른 주요 구성 방법이 실패했을 때만 사용된다. IPv6에서는 링크-로컬 주소가 다른 범위의 주소와 함께 항상 할당되며, 다양한 프로토콜 구성 요소의 내부 기능에 필요하다.
국제 인터넷 표준화 기구 (IETF)는 링크-로컬 주소 지정을 위해 IPv4 주소 블록 ()을 예약했다. 이 범위 전체가 이 목적으로 사용될 수 있지만, 첫 256개와 마지막 256개 주소 ( 및 )는 미래 사용을 위해 예약되어 있으며 이 동적 구성 메커니즘을 사용하는 호스트에 의해 선택되어서는 안 된다. 링크-로컬 주소는 다른 주소 할당 수단이 없는 경우 호스트 내부, 즉 무상태 주소 자동 구성을 통해 인터페이스에 할당된다.
동일한 인터페이스에서 링크-로컬 주소와 전역적으로 라우팅 가능한 주소와 같이 다른 범위의 IPv4 주소를 동시에 사용하면 혼란과 복잡성이 증가할 수 있다. 따라서 호스트는 링크-로컬 주소를 할당하기 전에 네트워크에서 DHCP 서버를 찾는다.
자동 주소 구성 프로세스에서 네트워크 호스트는 예약된 범위 내에서 무작위 후보 주소를 선택하고 주소 결정 프로토콜 (ARP) 프로브를 사용하여 네트워크에서 해당 주소가 사용 중이 아닌지 확인한다. ARP 프로브에 대한 회신이 수신되면 후보 IP 주소가 이미 사용 중임을 나타낸다. 새로운 무작위 후보 IP 주소가 생성되고 프로세스가 반복된다. ARP에 대한 회신이 없을 때 프로세스가 종료되며, 이는 후보 IP 주소를 사용할 수 있음을 나타낸다.
링크-로컬 주소가 할당된 후 전역적으로 라우팅 가능한 주소 또는 사설 IP 주소를 사용할 수 있게 되면, 일반적으로 새로운 연결에는 새로운 주소를 선호해야 하지만 링크-로컬 주소를 통한 통신은 여전히 가능하다.
마이크로소프트는 이 주소 자동 구성 방법을 자동 사설 IP 주소 지정 (APIPA)이라고 부른다.
인터넷 프로토콜 버전 6 (IPv6)에서 주소 블록 은 링크-로컬 유니캐스트 주소 지정을 위해 예약되어 있다. 링크-로컬 주소의 네트워크 구성 요소 64비트 중 최상위 10비트 (1111111010)는 IANA가 링크-로컬 주소를 위해 예약한 "글로벌 라우팅 프리픽스"에 해당하며, "서브넷 ID" (나머지 54비트)는 0이다.
IPv4와 달리 IPv6는 라우팅 가능한 주소도 할당된 경우에도 IPv6 프로토콜이 활성화된 모든 네트워크 인터페이스에 링크-로컬 주소가 필요하다. 결과적으로 IPv6 호스트는 일반적으로 IPv6가 활성화된 각 네트워크 인터페이스에 둘 이상의 IPv6 주소가 할당되어 있다. 링크-로컬 주소는 이웃 탐색 프로토콜의 IPv6 서브레이어 작업과 DHCPv6와 같은 다른 IPv6 기반 프로토콜에 필요하다.
링크-로컬 IPv6 주소를 사용하여 호스트에 연결할 때, 패킷이 올바른 인터페이스로 전송될 수 있도록 주소에 영역 인덱스를 추가해야 한다.
IPv6에서는 주소가 무상태 (메모리 없음) 또는 상태 유지 (메모리 있음) 메커니즘에 의해 할당될 수 있다. IPv6 무상태 주소 자동 구성은 이웃 탐색 프로토콜 (NDP)의 구성 요소로 수행된다. 주소는 라우팅 프리픽스와 네트워크 인터페이스의 고유 식별자로부터 형성된다.
NDP 라우팅 프리픽스 광고를 통해 라우터 또는 서버 호스트는 모든 링크 연결 인터페이스에 구성 정보를 알릴 수 있으며, 이는 로컬 또는 전역 라우팅 목적을 위해 수신 인터페이스에 추가 IP 주소 할당을 유발한다. 이 프로세스는 프리픽스 서버가 호스트에 대한 개별 할당을 수신하거나 기록하지 않기 때문에 때때로 무상태로 간주된다. 고유성은 주소 선택 방법론에 의해 자동으로 보장된다. MAC 주소 기반일 수도 있고, 무작위일 수도 있다. 자동 중복 주소 감지 알고리즘은 할당 오류를 방지한다.
일부 대규모 블록의 IPv4 주소는 이전의 클래스 A 네트워크 블록으로, (IANA)를 통해 인터넷 할당 번호 관리 기관(ICANN) 또는 대륙별 인터넷 레지스트리에 의해 단일 조직 또는 관련 조직 그룹에 전체가 할당된다.
각 블록에는 256 = 2 = 16,777,216개의 주소가 포함되며, 이는 IP 주소의 마지막 세 가지 구분된 세그먼트의 전체 범위를 포함한다. 이는 256개의 /8 주소 블록이 전체 IPv4 공간에 들어맞는다는 것을 의미한다.
IPv4 주소 고갈이 마지막 단계로 접어들면서, 이전에는 을 사용했던 스탠퍼드 대학교와 같은 일부 조직은 고갈 날짜를 늦추는 데 도움이 되도록 할당된 블록(이 경우 아태지역 네트워크 정보센터)을 반환했다.
대륙별 인터넷 레지스트리에 할당된 /8 블록 목록.
대륙별 인터넷 레지스트리 (RIR)는 전 세계 특정 지역 내에서 IP를 할당한다.
이 목록에는 모든 대륙별 인터넷 레지스트리 또는 국가 인터넷 레지스트리에 대한 현재 /8 블록 할당이 포함되지 않을 수 있다.
원래 IPv4 할당 주소 블록 목록.
원래 IPv4 주소 블록 목록은 1981년 9월에 발행되었다. 이전 버전의 문서에서 네트워크 번호는 IPv4에서 사용된 32비트 숫자가 아닌 8비트 숫자였다. 당시 이전에 나열되지 않았던 세 개의 네트워크(42.rrr.rrr.rrr, 43.rrr.rrr.rrr 및 44.rrr.rrr.rrr)가 추가되었다.
RFC 790의 관련 부분은 약간의 변경과 함께 여기에 재현되어 있다.
캐리어급 NAT(Carrier-grade NAT, CGN 또는 CGNAT)은 대규모 NAT(large-scale NAT, LSN)으로도 알려져 있으며, IPv4 네트워크 설계에서 ISP가 사용하는 네트워크 주소 변환 (NAT) 유형이다. CGNAT를 사용하면 최종 사이트, 특히 주거용 네트워크는 네트워크 운영자의 네트워크에 내장된 미들박스 네트워크 주소 변환기 장치에 의해 사설망 주소로 구성되며, 이는 공용 IPv4 주소로 변환되어 많은 최종 사용자 간에 소규모 공용 주소 풀을 공유할 수 있도록 한다. 이는 기본적으로 ISP 수준에서 기존의 고객 구내 NAT 기능을 반복한다.
캐리어급 NAT는 IPv4 주소 고갈을 완화하는 데 자주 사용된다.
CGN의 한 사용 시나리오는 NAT444로 불리는데, 이는 공용 인터넷의 인터넷 서비스에 대한 일부 고객 연결이 고객의 사설망, 통신사의 사설망, 공용 인터넷이라는 세 가지 다른 IPv4 주소 지정 도메인을 통과하기 때문이다.
또 다른 CGN 시나리오는 듀얼 스택 라이트(Dual-Stack Lite)로, 통신사 네트워크가 IPv6를 사용하므로 두 개의 IPv4 주소 지정 도메인만 필요하다.
CGNAT 기술은 2000년에 모바일 네트워크의 GPRS 배포에서 대량의 IPv4 주소에 대한 즉각적인 요구를 수용하기 위해 처음 사용되었다. CGNAT 배포는 2014년 1,200개에서 2016년 3,400개로 증가했으며, 연구된 배포의 28.85%가 모바일 운영자 네트워크에 나타났다.
공유 주소 공간.
ISP가 CGN을 배포하고 주소 공간을 사용하여 고객 게이트웨이에 번호를 매기면 고객 네트워크가 이미 주소 공간을 사용하는 경우 주소 충돌 및 라우팅 실패의 위험이 발생한다.
이로 인해 일부 ISP는 ARIN 내에서 CGN을 위한 새로운 사설 주소 공간을 할당하는 정책을 개발하게 되었지만, ARIN은 이 문제가 일반적인 할당 문제가 아니라 기술적 목적(RFC 2860에 따름)을 위한 주소 예약이라고 지적하며 정책을 구현하기 전에 IETF에 위임했다.
IETF는 을 발표하여, ISP CGN 배포에서 인바운드 및 아웃바운드 인터페이스 모두에서 동일한 네트워크 접두사가 발생하는 것을 처리할 수 있는 공유 주소 공간을 자세히 설명했다. ARIN은 이 할당을 위해 인터넷 할당 번호 관리기관에 주소 공간을 반환했다. 할당된 주소 블록은 100.64.0.0/10, 즉 100.64.0.0부터 100.127.255.255까지의 IP 주소이다.
IPv4 주소가 공용인지 여부를 평가하는 장치는 새로운 주소 공간을 인식하도록 업데이트되어야 한다. NAT 장치에 더 많은 사설 IPv4 주소 공간을 할당하는 것은 IPv6로 전환할 필요성을 늦출 수 있다.
캐리어급 NAT의 비판자들은 다음과 같은 측면을 주장한다:
6rd는 인터넷 서비스 제공자(ISP)의 IPv4 인프라에서 IPv6 신속 배포(IPv6 rapid deployment)를 용이하게 하는 메커니즘이다.
이 프로토콜은 IPv4 네트워크를 통해 IPv6 패킷을 전송하는 기존 메커니즘인 6to4에서 파생되었으며, 최종 사용자의 ISP 네트워크 내에서 전적으로 작동하여 6to4 설계에 내재된 주요 아키텍처 문제를 피한다는 중요한 변경 사항이 있다. 6rd라는 이름은 IPv6의 신속한 배포를 가능하게 하는 것과 비공식적으로 발명가인 레미 데프레의 이니셜(RD)을 모두 참조한다.
6rd 원칙과 ISP 프리에 의한 첫 번째 적용에 대한 설명은 RFC 5569에 게시되어 있다. 국제 인터넷 표준화 기구에서 인터넷 표준화를 위해 준비된 6rd 사양은 RFC 5969로 제공된다.