네트워킹을 하고자 한 생각은 아마 전자통신만큼 오래되었을 것이다. 석기 시대 때, 살았던 사람들을 잘 관찰해보면, 각 개인의 의사를 전달하기 위해서, 북을 사용해 왔다. 'A'라는 동 굴인이 돌 던지기 게임을 위해, 'B'라는 동굴인을 자기집에 초대하고 싶어한다고 가정하자. 그러나, 그들은 너무 멀리 떨어져서 살고 있기 때문에, 'A'가 북을 쳐서 'B'가 들리게끔 했 다. 그럼 'A'가 할 수 있었던 다른 방법은 없었을까? 1) 그는 'B'가 있는 장소로 직접 걸어 갈 수도 있었고, 더욱 커다란 북을 사용할 수도 있었으며, 그들 사이에서 중간쯤에 살고 있 는 'C'를 메시지를 전달하게 할 수도 있었다. 이 마지막 방법이 바로 네트워킹이다.
물론, 네트워킹은 우리 선조들의 방법과 도구에서 무수히 발전해 온 것이다. 요즈음에는, 토요일 축구시합{{. 유럽에서는 아직도 이와 같은 근본정신을 특별한 날에 보여주고 있다. 약속을 하기위해서, 광학섬유나 마이크로웨이브와 같은 거대한 선로를 통 해서 서로서로 얘기를 주고받을 수 있는 컴퓨터를 가지고 있다. 다음에 전선같은 골치아픈 얘기는 잊어버리고, 축구에 관한 이야기 뿐만 아니라, 이러한 전통이 이루어 지게된 유래에 대해서 다룰 것이다.
우리는 이 안내서에서 두 가지 형태의 네트워킹 즉, UUCP를 기초로 한 것과 TCP/IP를 토대로 한 것을 다루게 될 것이다. 이것들은 두 컴퓨터 사이에서 데이터를 전송하기에 적합 한 프로토콜이며, 소프트웨어 패키지이다. 이 장에서는, 이 두가지 네트워킹에 대한 기본적 인 개념에 대해서 논의할 것이다.
우리는 네트워크를 참여자간에 데이터를 공급해 주는 몇몇 호스트들의 서비스에 의존함 으로써 각 컴퓨터와 통신할 수 있는 host 모음으로 정의를 내린다. 호스트들이 컴퓨터 일때 도 있고, 그렇지 않을 때도 있다; 그 호스트는 X-terminal이나 인텔리전트 프린터가 될 수 있다. 소규모 host 집합을 site라 부르기도 한다.
통신은 몇몇 언어나 코드의 정렬없이는 불가능하다. 이러한 언어들을 총괄하여 protocols 이라 부른다. 하지만 여러분이 여기에 프로토콜을 쓸 생각은 하지말아야 한다. 이를테면 헤 드가 만날 때 오히려 코드의 동작이 일정한 형태를 갖추었는지 살펴보아라. 매우 유사한 형 태로써, 컴퓨터에서 사용하는 프로토콜들은 네트워크가 두 개 이상의 호스트 사이에서 메시 지를 교환하기 위한 엄격한 규칙에 지나지 않는다.
UUCP는 Unix-to-Unix Copy를 줄인 말이다. 프로그램 패키지로 일을 시작하는 이 것은 시 리얼 라인을 통해서 파일을 전송하고, 전송된 것을 스케줄하며, 리모트 사이트상에 있는 실 행 프로그램들을 시작시킨다. 70년대 후반에 첫 실행을 거친 이후로 많은 변화를 겪어 왔었 지만, 그것이 제공하는 서비스들은 여전히 스파르타식으로 행해지고 있다. 이것의 주요 어플 리케이션은 여전히 다이얼업 전화 연결을 토대로 하고 있는 광 지역 정보 통신망에서 동작 한다.
처음에 UUCP는 1977년 벨 연구소에서 유닉스 개발 사이트 간에 통신을 하기 위해 개발 되었다. 1978중반에, 이 네트워크는 무려 80개 사이트에 연결되었다. 이것은 리모트 프린팅 뿐만아니라 어플리케이션으로써 전자우편이 통용되고 있었다. 그러나 이 시스템에서 중점적 으로 하는 일은 새로운 소프트웨어를 배포하고, 버그를 고치는 일이었다. 그 시대에는 많은 것을 변화시키진 못했다. 오늘날 UUCP는 더 이상 UN★X에 제한되어 있지 않다. 그리고 AmigaOS, DOS, Atari's TOS 등의 다양한 플랫폼에서 사용할 수 있는 공개용과 상업용 포트가 있다.
UUCP 네트워크의 주요 단점중에 하나는 대역폭이 적다는 것이다. 한편, 최대 전송률을 가지는 전화 설비 지역이 많은 제한을 가진다는 것이다. 다른 한편으로는 UUCP 링크는 그 연결이 거의 영구적이다; 대신에 호스트들은 오히려 규칙적인 간격을 두고 서로 다이얼업 으로 접속한다. 그러므로, 대부분의 시간이 메일 메시지를 UUCP 네트워크로 전송시키는 데 에 소비된다. 그래서 몇몇 호스트의 디스크는 하는일 없이 빈둥거리게 되며, 연결이 성립되 는 다음 시간까지 기다리게 된다.
이러한 제한에도 불구하고, 여전히 많은 UUCP 네트워크가 전세계에서 운영되고 있으며, 개개의 사용자들이 적당한 가격으로 이 네트워크에 접근하고 있다. UUCP가 인기 있는 가 장 주요한 요인으로는 The Big Internet Cable로 연결되어 있는 여러분의 컴퓨터와 비교해 서 그 가격이 매우 싸다는 것이다. UUCP 노드를 가지는 컴퓨터로 만들기 위해 UUCP 실행 이 가능한 하나의 모뎀이 필요하며, 다른 UUCP 노드가 메일과 뉴스를 받는 데에 기꺼이 여러분을 만족시켜 줄 것이다.
UUCP는 그것의 이름 지시기가 비교적 단순하다: 그것은 기본적으로 하나의 호스트에서 다 른 호스트로 파일을 복사한다. 그것은 또한 리모트 호스트상에서 확실하게 작업을 수행시킨 다. 여러분의 컴퓨터가 swim이라는 이름을 가진 가상의 호스트로 접근해서, 인쇄 명령인 lpr을 실행한다고 가정하자. 그러면 여러분은 swim - bash 쉘(GNU Bourne Again Shell)을 사용할 경우, 여러분은 느낌표(!)로 빠져나가야 할 지도 모른다. 왜냐하면 bash는 그것을 history 문자로 사용하기 때문이다. 상에서 이 책을 인쇄하기 위해 명령행에서 다음을 입력할 수 있다.
$ uux -r swim!lpr !netguide.dvi
UUCP 형태의 명령어로써 uux는 swim을 위한 하나의 job을 스케줄한다. 이 작업은 입 력 파일인 netguide.dvi로 이루어져 있으며, 이 파일을 lpr로 보내주기를 요청할 것이다. -r 옵션은 uux에게 직접 리모트 시스템을 부르지 않게끔 말해준다. 하지만 연결이 확립 될 때까 지 작업을 저장시켜준다. 이러한 작업을 spooling이라 부른다.
UUCP의 또 다른 특성으로는, 여러 호스트를 거쳐서 작업과 파일들을 표면화 시켜준다 는 점이다. 위 예제에서 본 swim이라는 가상의 호스트가 groucho와 연결한 하나의 UUCP 를 가진다고 가정하자. groucho는 UNIX 어플리케이션의 거대한 아카이브를 유지시켜준다. 여러분의 사이트로 tripwire-1.0.tar.gz 파일을 다운로드 하기 위해 다음과 같은 명령을 쓸 수 있다.
$ uucp -mr swim!groucho!~/security/tripwire-1.0.tar.gz trip.tgz
생성된 작업은 groucho로부터 파일을 가져오기 위해 swim을 요청할 것이며, 그 것을 여 러분의 사이트로 보내준다. UUCP는 그 파일을 trip.tgz로 저장할 것이며, 파일의 도착 을 알 리는 편지를 여러분에게 통보해 줄 것이다. 이것은 세 단계로 되어 있다. 첫 번째 단계는 여 러분의 사이트가 swim을 위한 작업을 보내준다. 다음 단계로 swim이 groucho 와 접촉했 을 때, 그 파일을 다운로드한다. 마지막으로, swim에서 실제 여러분의 호스트로 파일 을 전 송한다.
오늘날 UUCP 네트워크에서 제공하는 가장 중요한 서비스로는 전자우편과 뉴스가 있다. 우리는 나중에 이러한 것들을 다루게 될 것이다. 이것들에 대한 간단한 소계를 다음 단락에 서 보여주고 있다.
전자우편 - 간략한 소계 - 여러분은 이러한 호스트에 접근하는 방법을 몰라도 리모트 호스트 상에 있는 사용자들과 서로 메시지를 교환하기 위해 전자우편을 사용할 것이다. 여 러분의 사이트에서 목적 사이트로 메시지를 보내는 작업은 메일 처리 시스템에 의해 완전히 수행된다. UUCP 환경에서, 메일은 수신 주소와 메일 메시지를 전하려고 하는 인접호스트 상에서 대개 rmail 명령을 주면 메일을 전송하게 된다. rmail 명령은 메시지를 다른 호스트 로 전송하게 되며, 그 메시지는 목적 호스트에 도착하게 된다. 우리는 이 부분을 13장에서 자세하게 다룰 것이다.
News는 게시판 시스템에 여러 종류로 분류되어 기술되어 있다. 대개 이러한 형태를 유 즈넷 뉴스라고 부르며, 이것은 참여하고 있는 사이트 수가 무려 120,000개에 달하는 뉴스 교 환망 으로 가장 널리 알려져 있다. 최초의 유즈넷 데이터는 1979년으로 거슬러 올라가 보면, 새로운 Unix V7과 함께 UUCP가 배포된 이후에, 세명의 졸업생들이 Unix 환경하에서 일반 적인 정보를 교환하자는 생각에서 출발하였다. 그들은 몇몇 쉘 스크립트로 뉴스 프로그램을 작성하였고, 이것이 최초의 넷뉴스 시스템이 되었다. 1980년에 이 네트워크는 North Carolina 대학에서 만들어낸 유즈넷 최초의 사이트인 duke, unc 그리고 phs를 연 결하였다. 그리고 나서, 유즈넷은 마침내 성장하기 시작하였다. 비록 유즈넷이 UUCP를 기반으로 하는 최초의 네트워크임에도 불구하고, 더 이상 하나의 독립된 형태의 네트워크로 제한하지 않는 다.
정보에 있어서 가장 기본적인 단위는 기사이다. 하나의 계층화된 뉴스그룹들이 특정 주 제별로 제공되는 기사들을 게시할 것이다. 모든 뉴스그룹들이 대부분의 사이트를 선택하게 되며, 가치있는 기사들이 하루에 60MB정도 등록된다.
UUCP 세계에서, 뉴스는 요청한 그룹들로부터 모든 기사들을 모아놓고, 몇 개의 batches 라고 하는 곳에 그것들을 묶어놓고, UUCP 링크를 거쳐서 보내게 된다. 이것들은 수신 사이 트에 보내지게 되며, 나중에 이것들을 풀기 위해서는 rnews 명령을 사용하면 된다.
마지막으로, UUCP는 공용 엑세스를 제공하기 위한 많은 다이얼 업 아카이브 사이트를 위한 선택매체가 될 수도 있다. 여러분은 UUCP를 가지고 그것들을 다이얼 업하거나, guest 사용자로 로긴해서, 그 사이트로 접근할 수 있으며, 공개적으로 접근가능한 아카이브 지역에 서 파일들을 전송받을 수도 있다. 이들 guest계정은 대개 로긴명과 패스워드로 uucp/nuucp 또는 그와 유사한 것들을 가진다.
비록 UUCP를 선택하는 이유가 적은 비용으로도 네트워크로 연결할 수 있다는 점이라할지 라도, store-and-forward 기술에서는 다루기 힘든 상태가 많이 있음이 증명되었다. 예를 들 어 Local Area Networks (LANs). 이러한 것들은 대개 같은 빌딩이나 심지어는 같은 층에 위치하고 있는 소수의 컴퓨터로 구성되어 있다. 그것은 동질의 작업환경을 제공해주기 위해 연결되어 있다. 전형적으로, 여러분은 이러한 호스트들 사이에서 파일을 공유하거나, 다른 기계에 깔려있는 어플리케이션들을 실행하고 싶어할 것이다.
이러한 작업은 네트워크로 연결을 할 때, 완전히 다른 접근법이 필요하다. 작업지시기에 따라 파일 전체를 발송하지 않고, 모든 자료를 더 작은 덩어리 (패킷)로 나누어 놓고, 목적 호스트 즉, 그것들이 모여있는 곳으로 즉시 발송한다. 이 네트워크 형태를 packet-switched 네트워크라고 부른다. 다른 네트워크 중에서도 이것은 네트워크를 통한 대화식 어플리케이 션을 실행하기 위한 것이다. 물론 소프트웨어적인 면에서 보면 대단히 복잡해 진다.
UNIX 시스템과 비 UNIX 사이트에서 가지고 있는 해결방안으로써 TCP/IP라고 알려진 프로토콜을 채택하고 있다. 이 절에서는 TCP/IP에 관한 기초적인 개념들을 다루게 된다.
TCP/IP는 1969년 미 국방성에서 DARPA (Defense Advanced Research Projects Agency) 라는 연구 프로젝트로 시작하였다. 이것은 ARPANET라는 실험용 네트워크로써 1975년에 일반인들도 사용가능한 형태로 변환되었다.
1983년에, 새로운 형태의 프로토콜인 TCP/IP가 표준 프로토콜로 채택되었으며, 그 네트 워크에 있는 모든 호스트들은 이 네트워크를 사용하기 위해 TCP/IP 프로토콜을 필요로 하 게 되었다. ARPANET이 마침내 인터넷 (1990년, ARPANET 그 자체가 또 다른 형태로 변 한것)으로 성장하였을 때 TCP/IP의 사용은 인터넷의 한계를 넘어서 네트워크로 퍼져나갔 다. 가장 주목할 만한 것으로는 UNIX 지역 통신망을 들 수 있지만, ISDN과 같은 빠른 디 지털 전화 설비의 출현이 있은 후, 그것은 또한 미래에는 다이얼업 네트워크를 위한 전송도 가능하리라고 본다.
다음 절에서는 TCP/IP에 관한 자새한 정보를 논의해 볼까 한다. 하나의 예를 들자면, Fredland의 어딘가에 위치하고 있을 Groucho Marx University (GMU)를 고려해 볼 것이다. 몇몇 부서들은 하나의 망을 공유하는 경우도 있고, 그 밖의 대부분의 부서들은 자체적으로 하나의 망을 가지는 경우, 또 다른 경우로 하나의 부서가 여러개의 망을 가지는 경우가 있 다. 이것들은 서로 연결되어 있으며, 단독 고속 링크를 통하여 인터넷으로 떠나기도 한다.
여러분의 컴퓨터가 Mathematics Department에 있는 UNIX 호스트 (그 이름은 erdos) 에 LAN으로 연결되어 있다고 가정하자. quark라고 부르는 Physics Department에 있는 호스 트로 접근하기 위해, 다음과 같은 명령을 입력하라.
$ rlogin quark.physics
Welcome to the Physics Department at GMU
(ttyq2) login:
프롬프트에서, andres라고 하는 여러분의 로긴명과 패스워드를 입력하라. 그러면 quark 에서 마치 시스템의 콘솔 환경에 여러분이 안주해 있는 것처럼, 입력할 수 있게 하기 위하 여, 하나의 쉘을 준다. 여러분이 그 쉘을 빠져나가면, 다시 여러분 자신의 기계로 되돌아 가 게 된다. 여러분은 동시에 작용할 수 있는 것, 즉 TCP/IP에서 제공하고 있는 대화식 어플리 케이션인 remote login을 사용하여 왔었다.
여러분은 quark로 접속해 들어가는 동안 플로팅 프로그램이나, PostScript previewer 기 능과 같이, X11을 토대로 하는 어플리케이션을 쓰고 싶어 할지도 모른다. 여러분의 호스트 화면상에 이러한 어플리케이션을 출력하기 위해서는 DISPLAY 환경 변수를 설정해야 한다:
$ export DISPLAY=erdos.maths:0.0
만약 어플리케이션을 지금 당장 실행시킨다면, quark 대신에 X 서버와 접촉하게 될 것 이고, 화면에는 풀 윈도우로 표현될 것이다. 물론, 이것은 여러분이 erdos상에서 X11을 실 행시킬 필요가 있다. 여기에 있는 이 점은 TCP/IP가 quark와 erdos를 허가하는 것이며, 이 것은 앞으로는 X11 패킷을 보내고, 뒤로는 여러분이 단독 시스템에 있는 것같이 만들어 준 다. 이 네트워크는 거의 여기에선 앞뒤가 투명하게 되어 있다.
TCP/IP 네트워크에서 또 하나 중요한 어플리케이션으로는 NFS (표준 Network Fiie Sy stem)을 들 수 있다. 이것은 네트워크 투명성을 표시하는 또다른 형태이다. 왜냐하면, 그것 은 기본적으로 다른 호스트로부터 디렉토리 계층을 마운트하기 때문이다. 그래서, 그것들이 로컬 파일 시스템으로 나타난다. 예를 들어, 사용자의 홈 디렉터리들는 LAN상에 있는 다른 모든 호스트들을 디렉터리와 마운트함으로써, 중앙 서버에 존재할 수 있다. 이 작업은 사용 자들이 어떤 호스트든지 접근해 들어갈 수 있으며, 같은 홈 디렉터리에 있는 사용자 파일을 발견하게 된다. 유사하게, 오직 한 대의 기계에 TEX와 같은 거대한 양의 디스크 영역이 필 요한 어플리케이션을 설치하는 것이나, 다른 기계에 이러한 디렉터리들을 전송하는 것도 가 능하게 되었다. 우리는 11장에서 NFS에 대해 자세하게 다룰 것이다.
물론, 이것들은 TCP/IP 네트워크에서 여러분이 할 수 있는 것중 한가지 예에 불과하다. TCP/IP 네트워크에서는 무한한 가능성을 내다볼 수 있다.
우리는 지금 TCP/IP를 구현할 수 있는 방법에 아주 가까워져 가고 있다. 다음절에서는 하드웨어를 예로 들면서, 작업에 몰두해 보자.
LAN을 통해서 사용하는 하드웨어 형태중에서 일반적으로 가장 널리 사용하는 것이 Ether- net이다. 이더넷은 커넥터, 탭이나 트랜스 시버를 통하여 그것에 접속하게 되는 하나의 단독 케이블로 이루어져있다. 초당 10M bit를 전송할 수 있는 이더넷이 그다지 비싸지 않기 때문 에 상당한 인기를 구가하고 있다.
이더넷에는 세 가지 기본적인 요소 즉, thick, thin 그리고 twisted pair로 이루어져 있다. Thin과 Thick 이더넷는 각각 하나의 동축케이블을 사용하고 있으며. 대역과 여러분이 이 케이블에 호스트를 접속시키는 방법이 다르다. Thin Ethernet은 꼬인선에 접속되어 있는 T 형 "BNC" 커넥터를 컴퓨터 뒷부분에 있는 플러그에 꽂아 넣는다. Thick Ethernet은 핀을 이용해서 선에 작은 구멍을 뚫고, 거기에 트랜스 시버를 꽂아 넣는다. 여러개의 호스트를 트 랜스 시버에 연결할 수 있다. Thin 과 thick Ethernet 선은 각각 최대 200 또는 500미터까 지 사용할 수 있고, 이것을 10base-2 그리고 10base-5라고 부른다. Twisted pair는 원래 전 화 설치시 찾을 수 있었던, 두 개의 동선으로 이루어진 케이블이다. 그러나 대개 10base-T 라고 알려진 하드웨어가 추가적으로 필요하다.
비록 thick Ethernet에 흐스트를 추가시키는 작업이 약간은 힘들다 할지라도, 그것은 네 트워크를 망가뜨리지 않는다. thinnet 설치시 호스트를 추가하기 위해서는, 적어도 몇분만이 라도 네트워크 서비스를 중단시켜 두어야 한다. 왜냐하면, 커넥터에 꽂을 선을 잘라야 하기 때문이다.
대부분의 사람들을 가격이 싸다는 이유로 thin Ethernet을 더 좋아하는 경향이 있다: PC 카드는 적어도 US 달러로 $50정도 되고, 전선은 미터당 2내지 3센트정도이다. 그러나 대용 량 필요로 하는 곳에는 thick Ethernet가 더 적당하다. 예를 들면, GMU의 수학부는 thick Ethernet를 사용한다. 그래서, 네트워크에 호스트를 추가할 때마다 서비스를 중단시키는 일 은 없을 것이다.
이더넷 기술의 약점이라고 한다면, 케이블 길이에 제한이 있다는 것이다. 그래서, LAN을 사용할 경우, 방해가 되는 부분이다. 그러나, 여러 이더넷 부분들은 리피터, 브릿지, 또는 라 우터를 사용해서, 서로를 연결할 지도 모른다. 리피터는 단순히 두 개 이상의 요소들 시이에 있는 신호들을 복사한다. 그래서, 모든 부분들이 하나의 이더넷인 것처럼 행동한다. 필요 조 건이라면, 네트워크에다가 두 개의 호스트에 네 개이상의 호스트를 달순없다. 브리지와 라우터는 더욱더 복잡하게 되어 있다. 이것들은 들어오는 데이터를 분석해서, 로컬 호스트상에 수신 호스트가 없다면, 그것을 앞쪽으로 끄집어 낸다.
이더넷은 하나의 호스트가 같은 이더넷상에 있는 다른 호스트로 최고 1500바이트 패킷 (또는 프레임)을 보내주는 버스 시스템처럼 작동한다. 그 호스트는 이더넷 보드의 펌웨어로 여섯 바이트씩 주소화되어 있다. 이러한 주소들은 대개 두 개의 숫자가 콜론으로 구별되어 여섯 개씩 순차적으로 쓰여져있다. 예를 들어, aa:bb:cc:dd:ee:ff.
프레임은 하나의 스테이션이 마치 접속되어 있는 모든 스테이션처럼 보이게끔 해서 보낸 다. 하지만 목적 호스트는 실제로 스테이션을 찾아내어서 처리한다. 만약 두 개의 스테이션 을 동시에 보내려고 시도했을 때, 발생하는 충돌은 두 개의 스테이션의 보내기를 중지시킴 으로써 그러한 문제가 해결되며, 몇분후에 재시도한다.
Groucho Marx University와 같은 거대한 장소에서, 이더넷는 오직 하나의 형태로 사용되는 것은 아니다. Groucho Marx University에서, LAN의 각 부는 campus backbone으로 연결되 어 있고, 그것은 FDDI (Fiber Distributed Data Interface)를 사용하는 광학섬유전선 이다. FDDI는 전송중인 자료를 완전히 다르게 접근하여 사용한다. 이것은 기본적으로, 여기저기에 보내는 즉 다시말해서, 만약 그것이 토큰을 포착한다면 하나의 스테이션이 단지 프레임을 보내기 위해 허가하게 될 tokens의 수를 포함한다. FDDI의 주요 이점으로는 100Mbps 의 속도를 낼 수 있고, 최대 선길이가 최고 200km까지 가능하다는 것이다.
먼거리의 네트워크을 연결하기 위해, 다른 종류의 기계가 자주 사용되며, 그 기계는 X.25 에 기초를 두고 있다. U.S.에 있는 Tymnet나 독일에 있는 Datex-P와 같은 Public Data N- etwork는 이 서비스를 제공하고 있다. X.25는 즉, Packet Assembler/Disassembler 또는 PAD와 같은 특별한 하드웨어를 필요로 한다. X.25는 네트워킹 프로토콜을 정의함에도 불구 하고, TCP/IP 그리고 다른 프로토콜을 사용하고 있는 네트워크를 접속하기 위해 자주 사용 된다. IP 패킷이 X.25에 정밀하게 표시할 수 없게된 이후에, 그것들은 단순히 X.25에 싸여서 네트워크에 보내지게 된다.
자주, 무선 아마추어들은 네트워크에 접속하기 위해 대개 그들의 컴퓨터를 장비로 사용 한다: 이것은 packet radio 또는 ham radio라 부른다. ham radio에 의해 사용되 는 프로토콜 을 우리는 AX.25라 부른다. 이것은 X.25에서 유래한 것이다.
다른 기술로는 사용자체가 좀 느리지만 값은 싼 다이얼업 엑세스를 위한 시리얼 라인을 포함하고 있다. 이것들은 이직도 패킷을 보내기 위해, SLIP나 PPP와 같은 또 다른 프로토 콜을 필요로 한다. 이것은 아래에 기술되어 있다.
물론 여러분의 네트워크를 하나의 이더넷으로 제한하길 원치 않을 것이다. 이상적으로 말하 면, 어떤 하드웨어를 사용하고 있는지 또는 얼마나 많은 서브유니트를 가지고 있는지에 상 관없이 네트워크를 사용하고 싶어할 것이다. 예를 들어, Groucho Marx University와 같은 거대한 장소에서, 여러분은 대개 여러 가지 방법으로 접속해야 하고, 여러개로 분리되어 있 는 이더넷를 가지고 있을 것이다. GMU에서, 수학부는 두 개의 이더넷s을 사용한다: 하나는 교수들이나 졸업생들을 위해 빠른 기계를 사용하는 네트워크와 또 다른 하나는 학생들을 위 해 조금 더 느린 기계를 사용하는 네트워크가 있다. 둘다 FDDI campus backbone에 연결되 어 있다.
이 연결은 이른바 gateway라고 하는 제공된 호스트에 의해 처리된다. 게이트웨이는 두 개의 이더넷과 광학섬유전선 사이에서 그것들을 복사함으로써, 들어오는 패킷과 나가는 패 킷을 처리한다. 예를 들어, 만약 여러분이 Maths Department에 있고, 리눅스 컴퓨터에서 Physics Department의 LAN 상에 있는 quark 호스트로 접근하고 싶다면, 네트워킹 소 프트 웨어는 패킷을 quark로 직접 보낼 수 없다. 왜냐하면, 같은 이더넷상에 있는 것이 아 니기 때문이다. 그래서 게이트웨이가 운송업자 역할을 한다. 백본을 사용해서, sophus라 이 름지 어진 게이트웨이는 Physics Department에 있는 동급의 게이트웨이인 niels에게 이들 패킷 을 보낸다. niels는 목적 호스트로 패킷을 전달하는 역할을 한다. erdos와 quark의 데이터 흐름도는 그림 1.1에 나와 있다.
그림 1.1: erdos에서 quark으로 자료를 세 단계로 보내는 과정
리모트 호스트로 보내는 자료의 방향을 계획하는 작업을 routing라고 하며, 이러한
관계로
볼 때, 패킷은 대개 datagrams에 적용된다. 이러한 작업을 용이하게 하기 위해, 하드
웨어와
독립적으로 사용되는 단독 프로토콜 즉, IP 또는 Internet Protocol이 자료 교환작업을
제어
한다. 2장에서, IP와 라우팅에 관해 좀 더 상세하게 다룰 것이다.
IP의 주요 잇점으로는 물리적으로 다른 네트워크를 외관상으로 동질의 네트워크로 변화 시켜준다. 이것을 인터네트워킹이라고 하고, 그 결과 발생하는 "meta-network"를 internet이 라 부른다. 여기에서 an internet과 the Internet은 미묘한 차이점이 있다는 것을 주의하라.
물론, IP는 또한 하드웨어를 독립적으로 어드레싱하는 작업이 필요하다. 이러한 작업은 IP 어드레스라고 부른는 하나의 유일무일한 32비트 수를 각 호스트에 할당함으로써 완성된 다. 하나의 IP 어드레스는 대개 네 개의 십진수를 도트문자로 구별해놓고, 각자리에 8비트씩 분배해 놓는다. 예를 들어, quark는 0x954C0C04라는 IP 어드레스를 가지고 있고, 그것은 다시 149.76.12.4로 표현한다. 이러한 형태를 dotted quad notation이라고 부른다.
자 그럼, 여러분은 우리가 세가지 다른 형태의 주소를 가지고 있다고 말할 것이다. 즉, 첫 번째는 quark와 같은 호스트명, 그리고 IP 어드레스, 마지막으로, 6바이트 이더넷 주소와 같은 하드웨어 주소가 있다. 어쨋든간에, 이러한 모든 주소들이 하나같이 일치해야된다. 그 래서, 여러분이 rlogin quark라고 입력하면, 네트워킹 소프트웨어는 quark의 IP 어드레스를 줄 수 있게 된다. 즉, IP가 어떤 자료를 Physics Department's 이더넷로 넘겨줄 때, 그것은 어떻게해서 든지 이더넷 어드레스를 IP 어드레스와 일치시켜야 한다.
지금 이점에 대해서 자세하게 논의할 순 없지만, 2장에서 이것을 다루기로 하겠다. 지금 은 hostname resolution이라고 부르는 주소들을 찾는 단계와 호스트 명을 IP 어드레 스와 일치시키는 것, 문자들을 하드웨어 주소로 일치시키는 과정을 기억하는 것만으로도 충분하 다.
사실 시리얼 라인에서, SLIP 또는 Serial Line IP라고 알려진 표준 프로토콜이 자주 쓰인다. CSLIP 또는 compress SLIP는 SLIP을 변형시킨 것이며, 이것은 시리얼 링크에 의해 제공되 는 대역폭을 상대적으로 낮게 사용하기 위해서 IP 헤더를 압축하는 작업을 한다. - SLIP은 RFC 1055에 기술되어 있다. 헤더를 압축하는 작업을 하는 CSLIP는 RFC 1144를 토대로 해서, 기술되어 있다. PPP 또는 Point-to-Point Protocol이라고 하는 또 다른 시리얼 프로토콜이 있다. PPP는 SLIP보다 더 많은 특징을 가지고 있다. SLIP에서는 제공하지 못하는 PPP만의 주요한 이점 으로는 IP 데이터그램을 전송하는 데에 제한이 없다는 것이다. 그것은 전달되는 어떠한 형 태의 데이터그램도 허용할 수 있게끔 제작되어 있다.
물론 요즈음에는 하나의 호스트에서 다른 호스트로 자료를 보내는 기능만 있는 것은 아니 다. 만약 여러분이 quark로 접속하고자 한다면, erdos상에 있는 rlogin 프로세스와 quark 상에 있는 쉘 프로세스 사이에 믿을 수 있는 연결을 가지고 싶어할 것이다. 그리하여, 이 정 보가 보내지고 이것은 송신기에 의해 패킷으로 나누어지게 되며, 수신기에 의해 문자 스트림으로 다시 합쳐지게 되는 것이다. 이것이 사소한 것처럼 보이지만 매우 어려운 작업을 수 반하고 있다.
IP에 관한 지식이 매우 중요하긴 하지만 그렇게 믿을 수 있는 것은 아니다. 여러분의 E- thernet상에 있는 열 명의 사람이 GMU의 FTP서버로부터 XFree86 최신 배포본을 전송받는 다고 가정하자. 여기서 발생하는 부하량은 실로 엄청날 것이며, 이것을 게이트웨이가 처리할 것이다. 왜냐하면, 전송속도가 매우 느릴 것이고, 메모리의 양이 부족할 지도 모르기 때문이 다. 지금 만약 여러분이 quark로 패킷을 보내고자 한다면, sophus가 잠시동안 버퍼 영역을 벗어날지도 모르기 때문에 그러한 것을 기대하기란 어렵다. IP는 단순하게 그것을 삭제함으 로써 그러한 문제를 해결한다. 그러면 패킷은 사라지며, 그것은 다시 되부를 수도 없다. 데 이터를 보존하고 완성하며, 에러를 찾아내어서 재전송하는 것이 통신 호스트의 주요 임무이 다.
이러한 작업은 아직도 TCP 또는 Transmission Control Protocol이라고 하는 또 다 는 프로토콜에 의해 수행되며, IP의 최상위에서 작업한다. TCP 본질적인 특성이라고 한다면, 여러분의 호스트와 리모트 머신상에 있는 두 개의 프로세스들을 단순히 연결시켜주는 착각 을 일으키게 하기 위해 IP를 사용하는 것이다. 그래서, 여러분은 자료가 어떤 경로롤 거치는 지는 알 필요가 없다. TCP 연결은 본질적으로 읽기도 하고 쓰기도 하는 프로세스 둘 다를 가지고 있는 송수신 파이프와 같이 동작한다. 즉 전화통화를 생각해 보면 된다.
TCP는 두 개의 호스트를 수반하고 있는 IP를 거친 연결의 종점과 각 호스트상에 있는 이른바 port 수를 동일하게 간주한다. 포트들은 네트워크 연결을 위한 연결장치 관 점에서 본 것이다. 한가지 예를 들어 만약 여러분이 전화선을 변형시킬 수 있다면, IP 어드레스는 지역 코드 ( 즉, 도시와 연관시킬 수 있는 숫자)와 비교할 수 있고, 포트 번호는 로컬 코드 (즉, 각 개인의 전화와 연관시킬 수 있는 숫자)와 비교할 수 있다.
rlogin을 예로 들어 보면, 클라이언트 어플리케이션 (rlogin)은 erdos상에 있는 하나의 포트를 열어주고, quark상에 있는 포트 번호 513에 연결시키며 rlogind 서버가 그 뒤를 따르는 것으로 알려져 있다. 이것으로 TCP 연결을 확립시킨다. 이러한 연결을 사용해서, rlogind가 인증 절차를 수행시키면 쉘이 나타나게 된다. 그 쉘의 표준 입력과 출력을 TCP가 연결되어 있는 곳에 전송시킨다. 그래서 여러분의 기계에서 rlogin라고 입력하게 되면, 이 입력된 신호가 TCP 스트림을 통과하게 될 것이고, 쉘의 표준 입력으로 받아들여지게 되는 것이다.
물론 TCP가 TCP 네트워킹에서 사용자 프로토콜로써만 존재하는 것은 아니다. 비록 rlogin 과 같은 어플리케이션에 적합한 프로토콜이라 하더라도, 그것에 수반되어 있는 오버헤드는 NFS와 같은 어플리케이션에는 대단히 부적합하다. 대신에, TCP와 유사한 프로토콜인 UDP 또는 User Datagram Protocol을 사용한다. TCP와 같이 UDP 또한 리모트 머신상에 있는 어떤 포트에 서비스를 접속하기 위해 하나의 어플리케이션을 허용하고 있지만, 이것을 위한 연결을 확립해 놓진 않는다. 대신에, 여러분이 단독 패킷을 목적 서비스에 보내기 위해 사용 할 수도 있다.
여러분이 각 부의 중앙 NFS 서버 - galois로부터 계층적으로 TEX 디렉토리에 마운 트 되어 있고, LATEX 사용방법에 대해 기술해 놓은 문서를 보고 싶어한다고 가정하자. 우선 파일 전체를 에디터로 읽어 들여라. 하지만, galois로 TCP 연결을 확립하고, 파일을 보내고, 그것을 다시 배포하는 데에는 너무나도 많은 시간이 걸릴 것이다. 대신에, galois로 만들어 진 하나의 요청 즉, 이것은 한쌍의 UDP 패킷에 있는 파일을 보내는 것이며, 속도면에서 훨 씬 더 빠르다. 하지만 UDP는 손실된 패킷이나 충돌이 일어난 패킷을 보존하지 않는다. 이 러한 경우에 가장 적절한 어플리케이션으로는 NFS가 있으며, 이것은 그러한 패킷들을 보호 해준다.
포트는 네트워크 연결을 위한 연결 포인트로 볼 수 있다. 만약 하나의 어플리케이션이 어떤 서비스를 제공하고자 한다면, 그것은 하나의 포트에 그 자체를 연결시키고, 클라이언트를 기 다린다. (이것을 포트에 listening 한다고 부른다.) 이 서비스를 사용하길 원하는 클라 이언트 는 로컬 호스트에 하나의 포트를 할당하고, 리모트 호스트 상에 있는 서버의 포트에 연결시 킨다.
포트의 중요한 특성중에 하나로는 연결이 클라이언트와 서버사이에서 이루어지고, 서버 의 다른 복사본들이 서버 포트에 연결되며, 더욱더 많은 클라이언트를 위해 listen한다. 이를 테면, 이것은 모두다가 같은 포트 513을 사용해서, 같은 호스트에 여러 다른 원격 접속을 동 시에 허가한다. TCP는 이러한 서로를 간에 연결을 확립할 수 있다. 왜냐하면, 그것들이 모 두 다른 호스트나 포트에서 발달한 것이기 때문이다. 예를 들어, 만약 여러분이 erdos 에서 quark로 접속한다면, 첫 번째 rlogin 클라이언트가 로컬 포트 1023을 사용할 것이고, 두 번 째 클라이언트는 포트 1022를 사용할 것이다. 하지만 둘 다는 quark의 포트 513에 연 결될 것이다.
이 예제에서 포트의 사용은 하나의 클라이언트가 특별한 서비스를 얻기 위해서 특별한 포 트를 연결하는 랑데부 포인트로 볼 수 있다. 클라이언트의 순서를 위해 적절한 포트 번호를 식별하기 위해서는, 이러한 번호를 할당할 수 있는 양쪽의 시스템 관리자사이에 그러한 합 의가 이루어져야 한다. rlogin과 같이 널리 사용되는 서비스를 위해, 이러한 번호들은 중점 적으로 관리되어야 한다. 이것은 IETF - Internet Engineering Task Force에 의해 이 루어 지며, 그것은 할당 번호가 붙은 RFC를 정기적으로 배포한다. 이것은 다른 것들 중에 well-known services로 할당된 포트 번호들을 기술한다. 리눅스는 그러한 번호 를 위해 /etc/services라고 부르는 파일 매핑 서비스 명을 사용한다. 그것은 The services and proto cols Files (9.3절)에서 자세하게 기술할 것이다.
비록 TCP 와 UDP 연결이 포트들에 의존하고 있다 하더라도 이들 번호들은 절대 충돌 이 일어나지 않는다. 이 의미는 TCP 포트 513은 UDP 포트 513과 다르다는 것이다. 사실상, 이들 포트들은 두 개의 다른 서비스 즉, rlogin (TCP) 와 rwho (UDP)와 같은 두 개의 다른 서비스를 엑세스 포인트로 제공한다.
UNIX 운영 체제에서, 모든 작업과 위에서 기술한 프로토콜을 수행하는 소프트웨어는 대개 리눅스에서와 같이 커널의 일부분이다. UNIX 세계에서 가장 일반적으로 사용하는 프로그 래밍 인터페이스는 Berkeley Socket Library이다. 그것의 이름은 소켓을 포트로 보고 플러 그를 꽂아 접속하는 것과 같이 포트를 연결한다는 유추에서 유래한 것이다. 그것은 리모트 호스트와 전송 프로토콜 그리고 서비스를 명시하기 위해 (bind(2)) 호출을 사용한다. 이것으 로 인해 프로그램은 (using connect(2), listen(2), 그리고 accept(2))를 연결하거나 들을 수 있다. 소켓 라이브러리가 다소 보편적이기는 하지만, 그것은 소켓 (AF_INET 소켓)을 기본 으로 하는 TCP/IP 클래스 뿐만아니라 연결 지역을 기계 (AF_UNIX 클래스)로 조종하는 클래스를 제공한다. 몇몇 실행으로 XNS (Xerox Networking System) 프로토콜 또는 X.25 와 같은 또 다른 클래스 또 한 처리할 수 있다.
리눅스에서, 소켓 라이브러리는 표준 libc C 라이브러리의 일부분이다. 현재, 그것은 AF_INET와 AF_UNIX 소켓만을 지원하지만, Novell의 네트워킹 프로토콜 지 원을 통합시 키는 노력으로 인해, 마침내 하나 이상의 소켓 클래스를 통합시킬 수 있게 되었다.
리눅스는 전세계의 프로그래머들이 이루어낸 노력의 결과이며, 전세계 네트워크 없이는 가 능하지 못했다. 이미 초기 단계에서 여러 사람들이 네트워크 호환 작업을 이루어낸 것도 과 히 놀랄만한 것도 아니다. 이미 초기 단계에서 UUCP를 리눅스 상에서 실행에 옮겼으며, 1992년 가을에 Ross Biro와 다른 사람들이 TCP/IP를 기초로한 네트워킹을 시작하였고, 그 것은 Net-1으로 알려지게 되었다.
1993년 Ross가 개발 활동을 중단한 이후, Fred van Kempen이 새롭게 작업에 착수하기 시작하였고, 그러한 노력으로, Net-2를 만들어 내게 되었다. 1992년 여름에 첫 공식 배포본 인 Net-2d를 만들어 냈다. (이것은 0.99.10 커널의 일부분이다.) 그리고 여러 사람들 중에서 Alan Cox가 Net-2Debugged를 유지하고 실험하고 있었다. 심각한 버그를 수정하고, 코드에 여러 가지 수정작업이 이루어진 이후로, 그 이름이 Net-3으로 바뀜으로써 드디어 Linux 1.0 을 배포하기에 이르렀다. 현재에는 여러 가지 네트워킹 코드가 공식 커널 배포본에 포함되 어 있다.
Net-3는 가장 광범위하게 변화하는 이더넷 보드 뿐만아니라, SLIP (시리얼 라인을 통해 네트워크 전송), 그리고 PLIP (패러랠 라인을 통해 네트워크 전송)을 위한 장치 드라이버를 제공한다. 랜 환경에서 가장 잘 동작하는 TCP/IP 구현을 가지고 있는 리눅스는 Net-3와 함 께 상업용 PC 유닉스를 능가하는 동작 가능 시간을 보여주고 있다. 현재 개발하고 있는 취 지는 인터넷 호스트 상에서 안정성있게 리눅스를 실행하는 것을 목표로 두고 활동하고 있 다.
이러한 작업을 더욱 용이하게 해주는 것으로써, 여러 가지 프로젝트가 추진중에 있으며, 리눅스의 융통성을 강화하는 데에 큰 몫을 해줄 것이다. PPP (Point-to-Point Protocol, 시 리얼 라인을 통해서 네트워크 전송을 하는 또 다른 방법)를 위한 드라이버가 현재 베타 단 계에 있으며, ham radio를 위한 AX.25 드라이버는 알파 단계에 와 있다. Alan Cox는 또한 Novell의 IPX 프로토콜을 위한 드라이버를 구현하고 있지만, 완전한 네트워킹을 위해 적합 한 호환성을 가지기 위한 노력으로 인해, Novell의 IPX 프로토콜 개발은 잠시 동안 주춤하 고 있다. 왜냐하면, 필요한 문서를 Novell 측에서 마지못해 제공해 주었기 때문이다. 장래가 유망한 또 다른 사업으로는, 유닉스를 위한 NetBIOS 서버인 samba가 있었으며, Andrew Tridgell에 의해 만들어 지고 있다.- NetBIOS는 lanmanager와 작업그룹들을 토대로 동작하는 Windows와 같이 어플리케이션상에 있는 프로토콜이다.
그 동안에, Fred는 Net-2e의 개발 작업을 계속 진행하였으며, 더욱 더 개선된 네트워킹 계 층을 제작했다. 이 글을 쓰고 있는 현 시점에서, Net-2e는 여전히 베타 소프트웨어였다. Net-2e의 가장 주목할 만한 점이라면, DDI,Device Driver Interface를 합병한 것이 었다. DDI는 항상 동일한 엑세스와 모든 네트워킹 장치와 프로토콜을 위한 구성법을 제공하였다.
Linux와 FreeBSD를 위한 ISDN을 만들어낸 Matthias Urlichs는 또 다른 TCP/IP 네트워킹 을 구현하였다. 이 작업을 위해 그는 몇몇 BSD 네트워킹 코드를 Linux 커널에 집적시켰다.
그러나 미래를 예견할 수 있었다 하지만 Net-3는 그대로 머물러 있었다. 현재 Alan은 ham radio amateurs를 사용하는 AX.25 프로토콜의 구현 작업을 하고 있다. 의심할 여지 없 이 커널을 위해 "module"이라는 코드를 개발하여 네트워킹 코드에 새로운 활력을 불어 넣 어 주었다. Modules은 여러분이 커널 실행시간에 드라이버를 추가할 수 있게끔 해준다.
네트워크를 구현하는 방법이 다르다 할지라도 모든 사람들은 같은 서비스를 제공하기 위 해 노력했다. 그래도 커널과 장치 레벨 사이에 주요한 차이점은 있었다. 그래서, 여러분들은 Net-2d 또는 Net-3, 그리고 vice versa로부터 유틸리티를 가지는 Net-2e 커널을 동작시키 는 시스템을 구성할 수는 없을 것이다. 이것은 단지 커널 내부를 다루는 명령을 제공해 줄 뿐이며, 오히려 어플리케이션이나 rlogin 또는 telnet과 같은 일반적인 네트워킹 명령에 더욱 더 가깝다.
그렇지만, 이러한 모든 네트워크 버전의 차이점이 여러분을 걱정시킬만큼의 문제거리는 아니다. 여러분이 개발 활동에 참여하지 않더라도, 여러분이 사용하는 TCP/IP 코드에 대해 걱정할 필요는 없는 것이다. 공식 커널 배포는 항상 커널에서 표현하는 네트워킹 코드와 호 환하는 네트워킹 도구집을 수반할 것이다.
리눅스 네트워크 코드의 최신 버전은 anonymous FTP를 사용하는 여러 사이트에서 구할 수 있다. Net3를 위한 공식 FTP 사이트는 sun.site.unc.edu 사이트의 system/Network/sunacm에 미러되어 있는 sunacm.swan.ac.uk이다. Net-2e의 최신 패치 키트와 바이너리들은 ftp.aris.com에서 찾아볼 수 있다. Matthias Urlichs' BSD-derived 네트워킹 코드는 ftp.ira.uka.de의 /pub/system/linux/netbsd방에서 구할 수 있다.
최신 커널은 uic.funet.fi의/pub/OS/Linux/PEOPLE/Linux에서 찾아 볼 수 있다.; sunsite와 tsx-11.mit.edu사이트가 이 디렉토리를 미러시켜 놓았다.
이 책을 통해서, 우리는 주로 설치와 구성에 관한 개관을 다룰 것이며, 특히 관리면을 집중 적으로 다룰 것이다. - 서비스를 셋팅한 후에, 여러분은 실행작업 역시 유지시켜 줘야 한다. 그러면 여러분에겐 mail과 news와 같은 서비스도 필요하게 될것이며, 여러분의 시스템을 최신식으로 유지하기 위해 루틴 작업도 해줄 필요가 있게 된다. 다음 장에서 이러한 작업에 관해 자세하게 다루어 보자.
에러 상태나 예상치 못한 일들을 대비하여 어플리케이션 로그 파일과 시스템을 검사하는 일은 시스템을 유지시키기 위한 최소한의 작업이다. 일반적으로, 여러분은 대개, 이러한 작 업을 하기 위해, 한 쌍의 관리 쉘 스크립트를 작성해서, 이것들을 cron 항목에 넣어 두고 정 기적으로 실행하고 싶어할 것이다. smail 과 C News와 같은 몇몇 주요한 어 플리케이션의 소스 배포에 있어서는 그런 스크립트를 포함시키고 있다. 여러분이 필요한 것이 무어인지, 더 좋아하는 것이 무엇인지 파악해서, 스크립트를 작성해야 한다.
cron 작업에서 얻어지는 출력은 관리 계정으로 우송된다. 많은 어플리케이션들은 에러 보고서, 사용량 또는 root 계정으로 요약하는 로그파일을 보낼 것이다. 만약 여러분이 root 계정으로 자주 로그인 한다면, 이것은 대단히 민감해질 것이다. ; 여러분의 개인 계정으로 root의 메일을 전송하기 위해서는 14장에서도 언급하게될 mail alias를 설정하는 것도 좋은 방법이 될 것이다.
하지만 여러분은 여러분의 사이트를 주의깊게 설정해야 한다. Murphy's law는 표면화되 는 몇몇 문제들을 보증해준다. 그러므로, 시스템을 유지시킨다는 것은 그러한 불평거리를 쓸 모 있게 만든다는 의미이다. 대개 사람들은 시스템 관리자가 적어도 root 계정을 사용해서, email을 통해 접근한다고 예상하고 있지만, 관리 측면에서 확실하게 책임을 져야할 사람들 이 접근하기 위해 일반적으로 사용하는 또 다른 주소가 있다. 이를테면, 작동불능 상태의 메 일 구성에 대해 불평하는 것은 대개 postmaster로 주소화 되어 있다. ; news 시스템 에 관 한 문제거리들은 newsmaster 이나 usenet으로 보고가 될지도 모른다. hostmaster 로 발송되는 메일은 호스트의 기본 네트워크 서비스와 만약 여러분이 네임 서버를 실행하 고 있다면, DNS 네임 서비스를 담당하고 있는 사람에게 재전송되어야 한다.
네트워크 환경에 있어서 시스템 관리 측면의 또 다른 중요한 작업으로는 침입자로부터 여러 분의 시스템과 사용자를 보호하는 것이다. 부주의하게 시스템을 관리하는 것은 고의적으로 사람들에게 표적을 제공하는 것과 마찬가지이다. ; 패스워드를 추측하는 것에서부터 Ethern et을 기웃거리는 일은 공격 범위를 줄여주는 결과를 초래할 것이며, 날조된 메일 메시지에 서 데이터 손실까지 또는 사용자의 사생활 침해와 같은 문제를 일으키게 된다. 우리는 그것 들이 발생할 수도 있는 배경을 논의하면서, 그러한 특별한 문제에 관해 해결방안을 모색할 것이다.
이 절에서는 시스템 보안을 다루는 기본적인 기술과 그에 따른 예를 들어 보일 것이다. 물론, 이 화제들로 여러분이 직면하게 될 모든 보안 문제들을 다룰수는 없다. ; 단지 일어날 수 있는 문제들을 다룰뿐이다. 그래서, 보안에 관련되어 있는 좋은 책을 읽는 것 또한 중요 하며, 그것이 시스템을 네트워크에 올려놓기 위해선 필수적이다. Simon Garfinkel의 "Practical UNIX Security" ([Spaf93]을 참조하라.) 는 상당히 추천할 만 한 책이다.
시스템 보안은 좋은 시스템을 관리하기위해 시작되었다. 이것은 중요한 모든 파일과 디 렉토리의 소유권과 허가권을 검사하고, 특별하게 사용하는 계정의 상태를 확인하는 작업도 포함하고 있다. 이를테면, COPS 프로그램은 보기드문 허가 또는 다른 예외적인 상황들을 위해, 파일시스템과 일반적인 구성 파일들을 검사할 것이다. 그리고 사용자의 패스워드를 어 떤 특별한 규칙에 따라 추측하기 힘들게 만드는 것도 현명한 방법이다. 이를테면, 쉐도우 패 스워드는 적어도 다섯 개의 문자를 가지는 패스워드를 필요로 한다. 그 패스워드에는 대소 문자와 번호를 포함하고 있다.