모든 요청이 Unix 네트워크 설계에 직접적인 영향을 미쳤습니까?

모든 요청이 Unix 네트워크 설계에 직접적인 영향을 미쳤습니까?

리눅스에 대해 더 알고 싶어요이것은 나의 가장 지속적인 감정 중 하나 여야합니다.

하지만 나는 역사책을 펼칠 때 가장 많은 것을 배우고, 어쩌면 내가 배운 것에 대해 가장 만족감을 느끼는 경우가 많다.

/etc/dev내가 모르는 그 안에 무엇이 숨겨져 있는 걸까 ? 음, 파일. 모든 것이 파일입니다.

그런데 이 파일을 거기에 넣는 것은 무엇입니까?

역사는 그들을 현재의 위치에 두고, 역사가 어떻게 쓰여지는지를 결정합니다, yadda yadda yadda.

~에 따르면man hosts

   Historical Notes
       RFC 952 gave the original format for the host table, though it has since changed.

       Before the advent of DNS, the host table was the only way of resolving hostnames on the fledgling Internet.  Indeed, this file could
       be created from the official host data base maintained at the Network Information Control Center (NIC), though  local  changes  were
       often  required to bring it up to date regarding unofficial aliases and/or unknown hosts.  The NIC no longer maintains the hosts.txt
       files, though looking around at the time of writing (circa 2000), there are historical hosts.txt files on the  WWW.   I  just  found
       three, from 92, 94, and 95.

엄청난. 그래서 그것은 나에게 씹을만한 것을 제공합니다. 저는 Linux가 어떻게 작동하는지 알고 싶었고, 특히 Linux 네트워크가 왜 그렇게 보이는지 알고 싶었기 때문에 RFC 952를 읽었습니다.

그런데 아, 잠깐만요...이건정말 짧다. 그리고 수백 개의 RFC 문서가 있습니다. 잘...

이러한 문제를 해결하기 전에 먼저 알아야 할 점은,모두RFC(Request for Comments) 문서의 내용이 Unix 및 Linux의 디자인에 직접적인 영향을 줍니까? 전부 이해해야 할까요, 아니면 일부만 이해해야 할까요?

답변1

아니요, 그렇지 않습니다. 일부는 심지어 가지고 있지도 않습니다적용하다유닉스로. 유닉스 초기에는 수십 개의 운영체제가 있었고, 출시 이후에도 수십 개가 더 등장했습니다. 그 중 다수는 ARPANET에 있으며,그들을인터넷에 성공적으로 로그인했습니다. 일부 RFC는 IPv6 주소를 쓰는 올바른 방법과 같은 전역 사항을 설명합니다(RFC 4291), MD5를 어떻게 구현해야 합니까(RFC 1321), 또는 머리 위로 날아다니는 돼지를 감상해 보는 것은 어떨까요(RFC 1925). Windows Kerberos 암호 변경 프로토콜(RFC 3244).

지금 보고 있는 것 중 상당수는 경험적 결정입니다.~ 후에표준화되다.

Unix 네트워킹에 대해 배우고 싶다면 아마도 가장 좋은 방법은 Unix에 관한 책일 것입니다. 알고 싶다면초기 Unices의 소스 코드를 읽는 것은 흥미로운 일입니다. 하지만 쉽지는 않을 것이다. :)

답변2

유닉스 계열 시스템의 최근 역사를 검토하고 싶다면 다음을 읽어 보는 것이 좋습니다.4.4 BSD 운영 체제의 설계 및 구현. 오래되었지만 UNIX 개념도 마찬가지입니다. 네트워킹은 4.3 BSD 운영 체제의 일부로 특별히 설계되었으며, 이는 물론 이 책에서 심도 있게 논의됩니다. GNU/Linux 시스템은 이 모델을 따르지만 처음부터 다시 작성되었습니다. 나중에 작성된 네트워킹 코드는 다른 많은 운영 체제에도 등장했습니다.

표준의 경우 상호 운용성을 달성하려면 모든 것을 정의해야 합니다. 따라서 이와 관련하여 모든 RFC는 Unix 네트워크 설계 등에 영향을 미칠 수 있습니다. 일부 RFC는 구현되지 않으며 사람들은 원하는 RFC를 자유롭게 구현하고 이를 구현하는 프로그램을 모든 사람이 사용할 수 있도록 만들 수 있습니다.

기본적으로 POSIX는 UNIX 시스템과 관련하여 많은 것을 지정하므로 확인하고 싶을 수도 있습니다. UNIX 시스템을 대상으로 하고 몇 가지 요구 사항을 지정하기 때문에 이것이 정말로 필요한 것이라고 생각합니다. GNU/Linux 시스템은 항상 POSIX와 호환되는 것은 아니며 오래되고 녹슨 것으로 간주될 수 있으므로 일부 대체적이고 비표준적인 방법이 등장했습니다. 이는 이식 가능한 프로그램/시스템을 개발하는 개발자의 문제입니다.

답변3

RFC는 아마도 Unix(또는 해당 운영 체제)의 작동 방식을 이해하는 방법에 대한 최고의 자료는 아닐 것입니다.

RFC는 다양한 시스템이 상호 운용되고 세상에 어느 정도 건전한 상태가 되도록 작업을 수행하는 표준 방법을 문서화합니다.

Unix 또는 Linux가 RFC를 구현하는 방식이 항상 동일하지는 않습니다.

RFC에서 표준과 프로토콜에 대해 많은 것을 배우게 되지만 운영 체제별 구현에 대해서는 반드시 많은 것을 배우지는 않습니다.

답변4

RFC는 제가 처음 컴퓨팅을 배우기 시작했을 때 제가 접했던 접점 중 하나이기도 했습니다. 내 이론은 기본 네트워크 규칙(TCP, DNS, HTTP 등)을 이해할 수 있다면 문제가 발생할 때 문제를 해결할 준비가 더 잘 된다는 것입니다. 아니면 적어도 그들이 왜 잘못되었는지 정확히 찾아낼 수 있어야 합니다.

RFC는 프로그래머가 오타로 인해 버그가 발생하는 지점까지 네트워크 스택(등)을 작성할 때 따라야 하는 규칙서입니다. (내 생각에는 SMTP가 오래전부터 있었던 것 같습니다.)

개인적으로는 그 위에 무엇이 구축되었는지 이해하는 데 좋은 기반을 제공했습니다. 기본 규칙서를 이해하면 문제를 (때때로) 더 쉽게 이해할 수 있습니다.

이것은 문제가 있을 때 다른 사람들이 로그를 보는 동안 나는 종종 Wireshark와 RFC를 파헤친다는 것을 의미합니다.

Unix나 다른 운영 체제에 대해 구체적으로 가르쳐주지는 않을 수도 있지만, 최소한 인터넷/네트워크를 구축하는 핵심 RFC를 이해하면 다른 사람들이 가질 수 없는 지식 상자를 확실히 얻을 수 있습니다.

관련 정보