인터넷 표준

Internet Standard

컴퓨터 네트워크 공학에서의 인터넷 표준은 인터넷에 적합한 기술의 규범적 규격을 가리킨다. 인터넷 표준은 인터넷이 기능할 수 있도록 하는 다른 소스로부터의 하드웨어와 소프트웨어의 상호작용을 허용한다.[1] 그들은 세계 통신의 언어적 프랑카다.[2]

컴퓨터 네트워크 엔지니어링에서 인터넷 표준은 인터넷에 적용되는 기술이나 방법론의 규범적 규격이다. 인터넷 표준은 인터넷 엔지니어링 태스크포스(IETF)에 의해 만들어지고 발행된다.

IETF에 대한 엔지니어링 기여금은 인터넷 초안으로 시작하여 의견 요청으로 승격될 수 있으며, 결국 인터넷 표준이 될 수 있다.

인터넷 표준은 기술적 성숙도와 유용성이 특징이다. 또한 IETF는 제안된 표준을 덜 성숙하지만 안정적이고 잘 검토된 규격으로 정의한다. 초안 표준은 2011년에 중단된 세 번째 분류다. 초안 표준은 제안된 표준 이후 인터넷 표준 이전에 발생한 중간 단계였다.

RFC 2026에 삽입된 경우:

일반적으로, 인터넷 표준은 안정적이고 잘 이해되고 기술적으로 유능하며, 상당한 운영 경험을 가진 다중적이고 독립적이며 상호운용 가능한 구현을 가지고 있으며, 상당한 대중적 지원을 받고 있으며, 인터넷의 일부 또는 전체 부분에서 유용하다고 인정된다.

개요

인터넷 표준은 의견 요청(RFC) 또는 RFCs 세트에 의해[3] 문서화된다. 표준 또는 표준의 일부가 되는 규격은 인터넷 초안으로 시작되며, 보통 몇 번의 개정 후에 RFC 편집자가 RFC로 승인하고 발행하며 제안된 표준이라고 라벨을 붙인다. 나중에 RFC는 만기가 허용 가능한 수준에 도달했을 때 추가 시퀀스 번호와 함께 인터넷 표준으로 승격된다. 집합적으로, 이러한 단계는 표준 트랙으로 알려져 있으며, RFC 2026 및 RFC 6410에 정의되어 있다. History라는 라벨은 표준 트랙이 설정되기 전에 발행된 사용되지 않는 표준 트랙 문서 또는 오래된 RFC에 적용된다.

인터넷 엔지니어링 스티어링 그룹(IESG)으로 대표되는 IETF만이 표준 트랙 RFC를 승인할 수 있다. 인터넷 표준의 최종 목록은 공식 인터넷 프로토콜 표준에서 유지된다. 이전에 STD 1은 목록의 스냅샷을 유지 관리하는 데 사용되었다.[4]

인터넷 표준의 역사와 목적

인터넷 표준은 기기가 네트워크에 연결할 때 따라야 하는 규칙 집합이다. 기술이 발전했기 때문에, 컴퓨터들 사이의 관여의 규칙은 그것과 함께 진화해야만 했다. 이것들은 오늘날 사용되고 있는 프로토콜이다. 이들 대부분은 인터넷 시대 훨씬 이전에 개발되었고, 개인용 컴퓨터가 만들어진 지 얼마 되지 않은 1970년대까지 거슬러 올라간다.

TCP/IP

최초의 인터넷이 가동된 공식 날짜는 1983년 1월 1일이다.[5] TCP/IP(Transfer Control Protocol/Internet Protocol)가 발효되었다. ARPANET(Advanced Research Projects Agency Network)와 방위 데이터 네트워크는 프로토콜을 구현하는 네트워크였다. 이러한 프로토콜들은 서버들간의 연결이 작동하는 규칙을 정의하기 때문에 인터넷이 작동하는 방법의 필수적인 부분으로 간주된다. 그것들은 오늘날에도 글로벌 네트워크를 통해 데이터가 전송되는 다양한 방법을 구현함으로써 사용되고 있다.

IPsec

인터넷 프로토콜 시큐리티는 여러 기기 간의 연결에서 암호화의 무결성을 보장하는 프로토콜의 모음입니다. 이 프로토콜의 목적은 공공 네트워크를 보호하는 것이다. IETF 데이터트랙터에 따르면, 그것의 창조에 헌신한 그룹이 1992년 11월 25일에 존재하도록 제안되었다.[6] 반년 후 이 단체는 창설되었고 얼마 지나지 않아 1993년 중반에 초안이 발표되었다.

HTTP

하이퍼텍스트 전송 프로토콜은 월드 와이드 웹의 맥락에서 오늘날 가장 일반적으로 사용되는 프로토콜 중 하나이다. HTTP는 HTML(HyperText Mark Language)로 작성된 문서가 네트워크를 통해 교환되는 방식을 제어하기 위한 간단한 프로토콜이다. 이 프로토콜은 전체 하이퍼텍스트 시스템이 실질적으로 존재할 수 있도록 하는 웹의 백본이다. 팀 버너스-리가 이끄는 개발자 팀이 만들었다. 버너스 리는 1989년에 했던 창조의 제안의 책임이 있다. 1991년 8월 6일은 그가 공개 포럼에 HTTP의 첫 번째 완전한 버전을 발표한 날이다.[7] 이 날짜는 월드 와이드 웹의 공식 탄생일로 일부 사람들은 생각한다. HPPS는 창사 이래 지속적으로 발전해 왔으며, 네트워크 기술의 시간과 진전에 따라 더욱 복잡해지고 있다. 기본적으로 HTTP는 암호화되지 않으므로 실제로는 HTTPS가 사용되며, HTTPS Secure는 HTTPS Secure를 의미한다.

TLS/SSL

TLS는 서로 다른 두 엔드포인트가 견고하고 사적으로 상호 연결될 수 있도록 하는 표준이다. SSL의 대체품으로 TLS가 나왔으며, HTTPS 생성 전에 Secure Sockets Layers가 처음 도입되어 Netscape에 의해 생성되었다. 사실 HTTPS는 처음 나왔을 때 SSL을 기반으로 했다. IETF가 1999년 1월 RFC 2246에서 TLS 1.0을 지정하도록 데이터 암호화의 한 가지 공통적인 방법이 필요하다는 것이 명백했다.[8] 그 이후로 업그레이드가 되었다. TLS의 마지막 버전은 2018년 8월 RFC 8446에서 1.3이다.

OSI 모델

오픈 시스템 상호접속 모델은 1977년에 개발을 시작했다.[9] 그것은 국제표준화기구에 의해 만들어졌다. 그것은 1979년에 공식적으로 출판되어 사용 기준으로 채택되었다. 그 후 여러 차례 업데이트되었고 최종 버전도 업데이트되었다. 의정서가 최종 형태로 발표되기까지는 몇 년이 걸렸다. ISO 7498은 1984년에 발표되었다. 마지막으로 1995년에 OSI 모델이 다시 개정되어 컴퓨터 네트워크 분야에서 봉기 발전의 긴급한 필요를 충족시켰다.

UDP

사용자 데이터그램 프로토콜의 목표는 두 컴퓨터 사이에서 가능한 빠르고 효율적으로 통신할 수 있는 방법을 찾는 것이었다. 본질적으로 UDP는 데이비드 P에 의해 구상되고 실현되었다. 1980년 [10]리드 본질적으로 그것이 작동하는 방법은 정보를 보내기 위해 압축을 사용하는 것이다. 데이터는 데이터그램으로 압축되어 점 대 점으로 전송될 것이다. 이것은 정보 전송을 위한 안전한 방법임이 입증되었으며, 데이터 품질의 손실이라는 단점에도 불구하고 UDP는 여전히 사용되고 있다.

표준화 프로세스

표준이 되는 것은 인터넷 표준 프로세스 내의 2단계 과정이다: 제안된 표준과 인터넷 표준. 이를 성숙도 수준이라고 하며 그 과정을 표준 트랙이라고 한다.

RFC가 표준 트랙에 있는 제안의 일부인 경우, 첫 번째 단계에서 표준이 제안되고 이후 조직은 제안된 표준의 이행 여부를 결정한다. RFC 6410의 기준을 충족한 후(두 개의 별도 구현, 광범위한 사용, 에라타 없음 등), RFC는 인터넷 표준으로 발전할 수 있다.

인터넷 표준 프로세스는 특히 BCP 9(현재 RFC 2026 및 RFC 6410)와 같은 몇 가지 "최상의 현재 관행" 문서에 정의되어 있다. 이전에는 제안된 표준, 초안 표준 및 인터넷 표준의 세 가지 표준 성숙도 수준이 있었다. RFC 6410은 이것을 두 가지 성숙 수준으로 줄였다.

제안 표준

RFC 2026은 원래 제안된 표준이 미숙한 규격으로 특징지어졌으나, 이 입장은 RFC 7127에 의해 무효화되었다.[11]

제안된 표준 규격은 안정적이고, 알려진 설계 선택을 해결했으며, 상당한 커뮤니티 검토를 받았으며, 가치 있는 것으로 간주될 수 있을 만큼 충분한 지역사회 관심을 누리고 있는 것으로 보인다. 일반적으로 제안된 표준으로 명세서를 지정하기 위해서는 구현이나 운영 경험이 필요하지 않다.

제안된 표준은 구현이 인터넷에 배치될 수 있는 품질이다. 그러나 모든 기술 규격과 마찬가지로, 그러한 기술을 규모에 맞게 구현한 경험이 수집되었을 때 문제가 발견되거나 더 나은 해결책이 확인되면 제안된 표준을 개정할 수 있다.

많은 제안된 표준은 실제로 인터넷에 배치되고 안정적 프로토콜로 광범위하게 사용된다. 실제 관행은 표준 수준의 순서를 통한 완전한 진행은 일반적으로 매우 드물며, 대부분의 인기 있는 IETF 프로토콜은 제안된 표준에 남아 있다.[12]

드래프트 스탠더드

2011년 10월에 RFC 6410은 두 번째와 세 번째 성숙도 수준을 하나의 초안 표준으로 통합하였다. 기존의 오래된 공개초안 기준서에서는 그러한 분류가 유지된다. IESG는 2년(2013년 10월) 후에 기존 초안 표준을 제안 표준으로 재분류할 수 있다.

인터넷 표준

인터넷 표준은 높은 수준의 기술적 성숙도와 특정 프로토콜 또는 서비스가 인터넷 커뮤니티에 상당한 이익을 제공한다는 일반적인 믿음으로 특징지어진다. 일반적으로 인터넷 표준은 프로토콜, 메시지 형식, 스키마 및 언어를 정의함으로써 인터넷 상의 시스템의 상호운용성을 다룬다. 인터넷 표준의 가장 기본적인 것은 인터넷 프로토콜을 정의하는 것이다.

인터넷 표준은 서로 다른 벤더에 의해 생산된 하드웨어와 소프트웨어가 함께 작동할 수 있도록 보장한다. 소프트웨어와 하드웨어는 한 번에 한 레이어씩 개발할 수 있기 때문에 표준을 갖추면 서로 다른 네트워크를 연결하는 소프트웨어와 하드웨어의 개발이 훨씬 쉬워진다. 일반적으로 데이터 통신에 사용되는 표준을 프로토콜이라고 한다.

모든 인터넷 표준에는 STD 시리즈의 번호가 부여된다. 시리즈는 2013년까지 첫 문서인 STD 1(RFC 5000)에 요약되어 있었으나, RFC 7100에서는 이 관행이 폐기되었다. 인터넷 표준의 최종 목록은 현재 RFC 편집자에 의해 유지되고 있다.[13]

IETF 편집자에게 제출되어 RFC로 수락된 문서는 수정되지 않으며, 문서를 변경해야 할 경우 다시 제출하고 새로운 RFC 번호를 할당한다. RFC가 인터넷 표준(STD)이 되면 STD 번호가 할당되지만 RFC 번호는 그대로 유지된다. 인터넷 표준이 업데이트되면 그 번호는 변경되지 않지만 다른 RFC 또는 RFCs 집합을 가리킨다. 예를 들어 2007년 RFC 3700은 인터넷 표준(STD 1)이었으며 2008년 5월에는 RFC 5000으로 대체되었다. RFC 3700은 역사적 지위를 받았고, RFC 5000은 STD 1이 되었다.

인터넷 표준 목록은 원래 STD 1로 발행되었지만, RFC Editor에 의해 유지되는 온라인 목록을 선호하여 이 관행이 포기되었다.[14]

인터넷 표준의 조직

표준화 과정은 세 단계로 나뉜다.

  1. 제안된 표준은 구현해야 하는 표준이며 언제든지 변경할 수 있음
  2. 강변이 미래 인터넷 표준을 형성할 것에 대비하여 표준 초안을 신중하게 테스트했다.
  3. 인터넷 표준은 성숙한 표준이다.

인터넷 표준 기구로는 인터넷 엔지니어링 태스크포스(IETF), 인터넷 소사이어티(ISOC), 인터넷 아키텍처 보드(IAB), 인터넷 연구 태스크포스(IRTF), 월드 와이드 웹 컨소시엄(W3C) 등 5개 기관이 있다. 모든 조직은 현재의 인터넷 단계에서 경쟁력을 유지하기 위해 인터넷 언어를 사용하고 표현해야 한다. 인터넷 표준 프로세스의 기본 목표는 기술적 우수성 보장, 조기 구현 및 테스트, 완벽하고 간결하며 쉽게 이해할 수 있는 기록이다.

인터넷 표준의 작성과 개선은 지속적인 노력이며, 이와 관련하여 인터넷 엔지니어링 태스크 포스가 중요한 역할을 한다. 이러한 표준은 인터넷 엔지니어링 태스크포스(IETF)에 의해 형성되고 이용 가능하다. 이러한 표준을 만들기 위해 잘 문서화된 절차를 사용하는 것은 선도적인 인터넷 표준 협회다. 일단 회람되면, 그러한 표준들은 비용 없이 쉽게 접근할 수 있게 된다.

1993년까지 미국 연방정부는 IETF를 지원하고 있었다. 현재, 인터넷 소사이어티의 인터넷 건축 위원회(IAB)가 그것을 감독한다. 정식 가입 필수품이 없고 정식 가입 절차도 없는 상향식 조직이다. W3C(World Wide Web Consortium, W3C) 및 기타 표준 개발 조직과 주의 깊게 협력한다. 더욱이, 그것은 지역 책임자에게 제안되고 구성되는 작업 그룹에 크게 의존한다. IETF는 IETF 조건과 전략의 확장을 위해 작업 그룹에 의존하고 있으며, 인터넷이 더 우수하게 작동하도록 하는 것을 목표로 하고 있다.[15] 작업 그룹은 지역 책임자의 지시에 따라 운영되며 합의를 진행한다. 제안된 헌장을 IESG와 IAB 메일링 리스트에 배포하고 승인한 후에는 공공 IETF에 추가로 전달된다. 모든 실무그룹들의 완전한 합의를 얻어 그 제안을 채택하는 것이 꼭 필요한 것은 아니다. IETF 워킹그룹은 협정이 강한지 확인하기 위해 재청구를 해야 한다.

마찬가지로, 작업 그룹은 접근법, 행위, 심사뿐만 아니라 인터넷과 인터넷 연계 약정의 기능에 적합한 혁신을 포함하는 비망록인 RFC의 배치에서 문서를 생산한다. 즉, Requests for Comments(RFCs)는 주로 네트워크 문장과 상관관계가 있는 표준 네트워크 프로토콜을 성숙시키기 위해 사용된다. 일부 RFC는 정보 생산을 목적으로 하는 반면, 다른 RFC는 인터넷 표준을 발행해야 한다. RFC의 최종 형태는 표준으로 변환되어 숫자로 발행된다. 그 후, 더 이상 결론 양식에 대한 의견이나 변형이 허용되지 않는다.[16] 이 과정은 인터넷과 관련된 문제에 대해 만장일치의 견해를 생성하고 서로 다른 결함에 대한 해결책으로 인터넷 표준을 개발하기 위해 모든 영역에서 뒤따른다. IETF가 초점을 맞추고 지역 담당자와 함께 다양한 실무 그룹을 사용하는 공통 분야는 8개다. "일반" 영역에서는 인터넷 표준을 작동하고 개발한다. "응용프로그램" 영역에서는 웹 관련 프로토콜과 같은 인터넷 응용 프로그램에 집중한다. 나아가, PPP 확장의 형태로 인터넷 인프라 개발에도 효과가 있다. 또한 IETF는 원격 네트워크 관찰과 같은 네트워크 프로세스에 대한 원칙과 설명을 확립한다. 예를 들어, IETF는 인터넷 프로토콜 스위트(TCP/IP)를 포괄하는 기술 표준의 확대를 강조한다. 인터넷 아키텍처 위원회(IAB)는 IRTF(Internet Research Task Force)와 함께 혁신 기술을 이용한 IETF의 활동에 대응한다.

IETF는 조직이 전문지식의 "표준" 규정과 그들이 구상하는 사용에 집중하도록 하는 표준이다. IETF는 현재의 인터넷 및 TCP/IP 노하우와 관련된 사항에 집중한다. 그것은 수많은 워킹그룹(WG)으로 소외되며, 이들 모두는 라우팅이나 보안과 같은 특정 영역에서 표준과 기술을 발전시킬 책임이 있다. 실무그룹에 종사하는 사람들은 자원 봉사자로 장비판매업자, 네트워크 운영자, 다른 연구기관 등의 분야에서 근무한다. 첫째로, 그것은 노력이 담론해야 할 필수품에 대한 공통의 고려를 얻기 위해 노력한다. 그 후 IETF 워킹 그룹이 결성되고 IETF 회의의 영향력 있는 BoF(Birds of a Peather) 집회에서 생필품 통풍이 이루어진다.

인터넷 엔지니어링 태스크포스

IETF(Internet Engineering Task Force)는 최고의 인터넷 표준 조직이다. 그것은 인터넷 표준을 설정하기 위해 공개되고 잘 문서화된 과정을 따른다. IETF가 제공하는 자원은 RFC, 인터넷 초안, IANA 기능, 지적재산권, 표준 프로세스, 출판 및 RFC 접속 등이다.[17]

RFCs

  • 인터넷에 대한 기술 사양 및 참고 사항이 포함된 문서.
  • RFC라는 약어는 "Request For Comments"라는 구절에서 유래되었다 - 이것은 오늘날 더 이상 사용되지 않고 현재는 RFCs라고 간단히 언급되고 있다.[18]
  • 웹사이트 RFC Editor는 인터넷 표준, 초안 표준 및 제안된 표준의 공식 보관소다.[19]

인터넷 초안

  • IETF 및 해당 작업 그룹의 작업 문서.[20]
  • 다른 그룹은 작업 문서를 인터넷 드래프트로 배포할 수 있다.

지적재산권

  • 모든 IETF 표준은 자유롭게 보고 읽을 수 있으며, 일반적으로 허가나 지불 없이 누구나 자유롭게 구현할 수 있다.[21]

표준 프로세스

  • 규격을 만드는 과정은 간단하다. 규격은 인터넷 커뮤니티에 의해 광범위한 검토 과정을 거치고 경험을 통해 수정된다.[22]

RFC 게시 및 액세스

  • 검토 과정을 성공적으로 마친 인터넷 드래프트.
  • 출판을 위해 RFC 편집기에 제출됨.

인터넷 표준의 종류

인터넷 표준이 형성되는 두 가지 방법은 "de jure" 표준과 "사실상의" 표준 중 하나로 분류할 수 있다.[23] 사실상의 표준은 기술 커뮤니티 내에서 광범위하게 사용함으로써 표준이 된다. de jure 표준은 공식적으로 표준 개발 기관들에 의해 만들어진다.[23] 이 표준들은 인터넷 표준 과정을 거친다. 공통 de jure 표준은 ASCII, SCSI, 인터넷 프로토콜 제품군을 포함한다.[19]

인터넷 표준 사양

인터넷 표준 프로세스가 적용되는 사양은 다음 중 하나로 분류할 수 있다. 기술 명세서(TS)와 적용 가능성 명세서([24]AS). 기술 명세서는 프로토콜, 서비스, 절차, 관례 또는 형식의 모든 관련 측면을 기술하는 명세서다.[24] 여기에는 그 범위와 사용 의향 또는 "적용성 영역"이 포함된다. 그러나 인터넷 내의 TS 사용은 적용가능성 명세서에 의해 정의된다. AS는 특정 인터넷 기능을 지원하기 위해 TS를 어떻게 어떤 상황에서 적용할 수 있는지를 명시한다. AS는 관련 TS가 결합되는 방법을 식별하고 TS 프로토콜의 파라미터 또는 하위 기능을 명시한다. AS는 또한 인터넷 라우터, 터미널 서버 또는 데이터그램 기반 데이터베이스 서버와 같은 TS의 적용가능성의 도메인을 설명한다.[24] AS는 또한 다음과 같은 각 TS에 다음과 같은 "필수 수준" 중 하나를 적용한다.

  • 필수: 상호운용성을 달성하기 위해서는 참조된 TS의 구현이 필요하다. 예를 들어 IP와 ICMP를 구현하기 위해서는 인터넷 프로토콜 스위트를 사용하는 인터넷 시스템이 필요하다.[24]
  • 권장 사항: 참조된 TS의 구현은 필요하지 않지만 AS의 적용 영역에서는 바람직하다. 권장 TS의 기능, 특징 및 프로토콜을 시스템 개발에 포함시키는 것을 권장한다. 예를 들어, TELNET 프로토콜은 원격 액세스를 사용하려는 모든 시스템에 의해 구현되어야 한다.[24]
  • 선택적: 참조된 TS의 구현은 선택 사항이다. TS는 특정 환경에서만 필요하다. 예를 들어, DECNET MIB는 DECNET 프로토콜이 사용되는 환경에서 가치 있는 것으로 볼 수 있다.[24]

공통 표준

웹 표준

TCP/IP 모델 & 관련 인터넷 표준 웹 표준은 월드 와이드 웹의 측면을 정의하는 인터넷 표준의 한 유형이다. 그들은 웹사이트의 구축과 렌더링을 허용한다. 월드와이드웹이 사용하는 세 가지 핵심 표준은 하이퍼텍스트 전송 프로토콜, HTML, URL이다.[25] 각각 웹 페이지의 내용과 레이아웃, 웹 페이지 식별자가 무엇을 의미하는지, 브라우저와 웹 서버 간의 데이터 전송을 명시한다.

네트워크 표준

네트워크 표준은 네트워킹 기술 및 프로세스에서 데이터 통신 규칙을 정의하는 인터넷 표준의 일종이다. 인터넷 표준은 다른 기기로 또는 다른 기기로의 통신 절차를 허용한다.

TCP/IP 모델과 관련하여, 각 계층의 공통 표준과 프로토콜은 다음과 같다.

공식 인터넷 프로토콜 표준

  • IETF가 최근 발간한 문서는 RDAP(Registration Data Access Protocol) Query Format 또는 RFC 9082라는 제목으로 RFC-Editor 사이트에 보관되어 있다.[27] 이 문서의 개요는 "RESTFLE" 웹 액세스 패턴을 사용하여 레지스트리에서 등록 정보를 검색하는 데 사용할 수 있는 HTTP URL을 구성하기 위한 통일된 패턴을 설명한다.[27] RDAP는 사용자가 현재 등록 데이터에 접근할 수 있도록 하며 WHOIS 프로토콜을 대체하기 위해 만들어졌다.[28]
  • 또 다른 인터넷 표준 프로토콜은 2021년 6월 IETF에 의해 발행되었는데, 이는 지역 인터넷 등록국(RIR)과 도메인 이름 등록국(DNR)에 의해 유지되고 있는 등록 정보를 나타내는 JSON 데이터 구조에 관한 정보를 포함하고 있다. 추상적인 것은 그러한 데이터 구조가 RDAP(Registration Data Access Protocol) 질의 응답을 형성하는 데 사용된다는 것이다. 이 문서는 RFC 7483을 쓸모없게 만든다.[29]

현재 인터넷 표준 문제

지금도 인터넷은 인터넷 표준 문제로 넘쳐난다. 2021년 10월 페이스북 이용자는 물론 왓츠앱, 메신저, 오큘러스, 인스타그램 등 관련 앱 이용자들이 6시간 동안 서비스를 받지 못하는 것을 알게 됐다. 회사 내부 통신 플랫폼인 Workplace에 의존함에 따라 회사 자체의 내부 통신까지 중단이 확대되었다.[30] 회사 밖에서는, 많은 사업체와 웹사이트들이 심각한 피해를 입었다. 많은 웹사이트들은 Like 버튼이나 코멘트 섹션에 대한 스크립트를 내장하고 있다; 그들은 존재하지 않는 것을 사용하려고 하기 때문에 로딩 시간이 증가했다. 다른 이들은 주문을 이행하고, 고객과 소통하며, 일반적으로 사업을 수행하기 위해 페이스북과 왓츠앱에 의존한다.

서비스 손실의 원인은 정기적인 정비로 시작되었다. 페이스북은 여러 개의 시설을 갖추고 있으며, 이들 사이의 백본 연결이 얼마나 가능한지 알아보기 위해 명령이 내려졌다. 결국, 그것은 그들을 실수로 삭제했다. 전형적으로 그런 결함이 있는 명령은 실행되지 않았을 것이다. 그런데 명령을 확인하는 과정에서 버그가 생겼다.[31] 결과적으로, 이슈의 도미노 효과로, 페이스북의 DNS 서버는 데이터 센터를 찾을 수 없었다. 거기서부터 BGP 라우팅 정보는 인터넷의 나머지 부분에 광고되는 것을 중단했다.[32] 마치 페이스북과 다른 지점들이 존재에서 지워진 것 같았다.

인터넷 표준의 미래

인터넷은 사람들이 자유롭게 이용하고 커뮤니티가 감시할 수 있는 열린 운동장으로 여겨져 왔다. 하지만 대기업들은 그들의 필요에 가장 잘 맞게 그것을 형성하고 성형했다. 인터넷 표준의 미래도 다르지 않을 것이다. 현재 BGP(Border Gateway Protocol)와 DNS(Domain Name System) 등 널리 사용되지만 안전하지 않은 프로토콜이 있다.[32] 보안보다 혁신에 더 치중하는 공통 관행이 반영된 것이다. 기업들은 이러한 문제들을 개선할 힘을 가지고 있다. 인터넷이 업계의 손에 들어오면서 사용자는 이러한 표준에 존재하는 취약점을 보호하기 위해 기업에 의존해야 한다.[32]

BGP와 DNS를 안전하게 만드는 방법은 이미 존재하지만 널리 보급되지는 않았다. 예를 들어, RPKI(Routing Public Key Infrastructure)라는 기존의 BGP 안전장치가 있다. 안전하다고 알려져 있고 암호화된 서명이 되어 있는 노선의 데이터베이스다.[33] 이용자와 업체가 경로를 제출하고, 다른 이용자의 안전 여부를 확인한다. 더 널리 채택된다면, 더 많은 노선이 추가되고 확정될 수 있을 것이다. 하지만 RPKI는 탄력을 받고 있다. 2020년 12월 현재 기술 대기업 구글은 노선의 99%를 RPKI에 등록했다.[33] 그들은 기업들이 BGP 안전장치를 채택하는 것을 더 쉽게 만들고 있다. DNS는 채택률이 낮은 DNSSEC(DNS Security Extensions)의 보안 프로토콜도 가지고 있다. 기본적으로 DNS 검색 프로세스의 모든 단계에서 DNSSEC는 데이터에 서명을 추가하여 데이터 손상이 없음을 표시한다.[34]

인터넷 프로토콜 확보에 앞장선 기업도 있다. 그것을 더 널리 퍼뜨리는 것은 나머지 사람들에게 달려 있다.

참고 항목

참조

  1. ^ Leiba, Barry (January 2008). "An Introduction to Internet Standards". IEEE Internet Computing. 12 (1): 71–74. doi:10.1109/MIC.2008.2. ISSN 1089-7801.
  2. ^ Cath, Corinne; Floridi, Luciano (April 2017). "The Design of the Internet's Architecture by the Internet Engineering Task Force (IETF) and Human Rights". Science and Engineering Ethics. 23 (2): 449–468. doi:10.1007/s11948-016-9793-y. ISSN 1353-3452.
  3. ^ Huitema, C.; Postel, J.; Crocker, S. (1995). "Not All RFCs are Standards". Ietf Request for Comments (RFC) Pages - Test. ISSN 2070-1721.
  4. ^ RFC 7100 "인터넷 공식 프로토콜 표준" 요약 문서 폐기
  5. ^ "A Brief History of the Internet". www.usg.edu. Retrieved 2021-12-08.
  6. ^ "IP Security Protocol (ipsec) -". datatracker.ietf.org. Retrieved 2021-12-08.
  7. ^ "Evolution of HTTP - HTTP MDN". developer.mozilla.org. Retrieved 2021-12-08.
  8. ^ "Transport Layer Security (TLS) - MDN Web Docs Glossary: Definitions of Web-related terms MDN". developer.mozilla.org. Retrieved 2021-12-08.
  9. ^ Alani, Mohammed M. (2014), "OSI Model", Guide to OSI and TCP/IP Models, Cham: Springer International Publishing, pp. 5–17, doi:10.1007/978-3-319-05152-9_2, ISBN 978-3-319-05151-2, retrieved 2021-12-08
  10. ^ "What Is UDP DiverseNet Inc". Retrieved 2021-12-08.
  11. ^ "Characterization of Specifications". Characterization of Proposed Standards. IETF. January 2014. sec. 3. doi:10.17487/RFC7127. RFC 7127. Retrieved March 11, 2016.
  12. ^ "IETF Review of Proposed Standards". Characterization of Proposed Standards. IETF. January 2014. sec. 2. doi:10.17487/RFC7127. RFC 7127. Retrieved March 11, 2016.
  13. ^ "Official Internet Protocol Standards".
  14. ^ RFC 7100
  15. ^ Ma, D.; Mandelberg, D.; Bruijnzeels, T. (August 2018). Simplified Local Internet Number Resource Management with the RPKI (SLURM). doi:10.17487/rfc8416. RFC 8416.
  16. ^ Knieps, Günter (September 2015). "ENTREPRENEURIAL TRAFFIC MANAGEMENT AND THE INTERNET ENGINEERING TASK FORCE". Journal of Competition Law and Economics. 11 (3): 727–745. doi:10.1093/joclec/nhv018. ISSN 1744-6414.
  17. ^ Society., Internet Engineering Task Force. Internet (2005). IETF journal. Internet Society. OCLC 746928702.
  18. ^ "RFCs". IETF. Retrieved 2021-12-08.
  19. ^ a b Internet Official Protocol Standards. May 2008. doi:10.17487/rfc5000. RFC 5000.
  20. ^ Farrel, A. (April 2014). Handling of Internet-Drafts by IETF Working Groups. doi:10.17487/rfc7221. RFC 7221.
  21. ^ Intellectual Property Rights in IETF Technology. March 2005. doi:10.17487/rfc3979. RFC 3979.
  22. ^ Hovey, R.; Bradner, S. (October 1996). The Organizations Involved in the IETF Standards Process. doi:10.17487/rfc2028. RFC 2028.
  23. ^ a b Nickerson; Muehlen (2006). "The Ecology of Standards Processes: Insights from Internet Standard Making". MIS Quarterly. 30: 467. doi:10.2307/25148769. JSTOR 10.2307/25148769.
  24. ^ a b c d e f Bradner, S. (October 1996). The Internet Standards Process -- Revision 3. doi:10.17487/rfc2026. RFC 2026.
  25. ^ Comer, Douglas (2015). Computer networks and Internets (Sixth ed.). Boston, MA. ISBN 978-0-13-358793-7. OCLC 870649960.
  26. ^ a b c d "Network Standards (Data Communications and Networking)". what-when-how.com. Retrieved 2021-12-08.
  27. ^ a b Hollenbeck, S.; Newton, A. (June 2021). Registration Data Access Protocol (RDAP) Query Format. doi:10.17487/rfc9082. RFC 9082.
  28. ^ Hollenbeck, S.; Carney, R. (May 2019). vCard Format Extensions: ICANN Extensions for the Registration Data Access Protocol (RDAP). doi:10.17487/rfc8605. RFC 8605.
  29. ^ Hollenbeck, S.; Newton, A. (June 2021). JSON Responses for the Registration Data Access Protocol (RDAP). doi:10.17487/rfc9083. RFC 9083.
  30. ^ Isaac, Mike; Frenkel, Sheera (2021-10-04). "Gone in Minutes, Out for Hours: Outage Shakes Facebook". The New York Times. ISSN 0362-4331. Retrieved 2021-12-08.
  31. ^ "Facebook explains how its October 4th outage started". Engadget. Retrieved 2021-12-08.
  32. ^ a b c Sherman, Justin (1 October 2020). "Mapping Private Sector Influence on the Internet: Starting with Internet Protocols". The Politics of Internet Security: Private Industry and the Future of the Web (Report). Atlantic Council. pp. 4–7. JSTOR resrep26661.5.
  33. ^ a b Newman, Lily Hay. "A Broken Piece of Internet Backbone Might Finally Get Fixed". Wired. ISSN 1059-1028. Retrieved 2021-12-08.
  34. ^ "DNSSEC: An Introduction". The Cloudflare Blog. 2014-10-07. Retrieved 2021-12-08.

외부 링크