NEXT (2장) NEXT (5장)

1.1 History
1.2 UUCP Networks
1.3 TCP/IP Networks
1.4 Linux Networking

1.1 History

네트워킹의 아이디어는 의사소통이라는 것만큼 오래된 것일 것이다. 북을 쳐서 메시지를 전하는 석기시대라고 가정하자. A 원시인이 B 원시인에게 돌 던지기 놀이를 하자고 초대하려 하나, B가 그 북소리를 듣기엔 너무도 멀리 떨어져 있다면 A가 할 수 있는 일은? 그는 1) B가 살고 있는 곳까지 찾아가거나, 2) 더 큰 북을 쓰거나, 3) A와 B 사이에 사는 C에게 메시지를 전해달라고 요청할 수 있을 것이다. 이들 중 마지막 것이 바로 네트워킹이다.

물론, 우리는 원시 농경시절 선조의 도구보단 훨씬 발전된 도구를 갖고 있다. 오늘날 우리는 전선의 다발, 광 케이블, 전파 등을 통하여, 토요일의 축구경기 약속을 맺기위해 컴퓨터로 통신한다. 다음에서 우리는 이러한 일들이 이루어지는데 대한 의미와 방법에 관해 다룰 것이다.

이 문서에서는 두 가지의 네트웍에 관해 기술할 것인데, 하나는 UUCP기반, 또 하나는 TCP/IP 기반이다. 이들은 두 컴퓨터간에 자료를 전달하는 프로토콜과 소프트웨어 패키지이다. 이 장에서 우리는 그 두 타입의 네트웍과, 그들 밑에 깔린 원리에 관해 살펴볼 것이다.

네트웍은 상호간에 교신(주로 전용 호스트들의 서비스에 의존하여) 할 수 있는 호스트(host)의 모음이라고 정의할 수 있다. 호스트들은 대부분 컴퓨터이지만 꼭 그래야만 하진 않다. 즉 X-터미널 또는 고지능 프린트도 호스트가 될 수 있다는 것이다. 작은 호스트의 집단 역시 사이트(site)라 불릴 수 있다.

커뮤니케이션은 언어나 코드의 정렬 없이는 불가능하다. 컴퓨터 네트웍에서 이런 언어들은 프로토콜(protocol)이라고 불리워 진다. 그러나 당신도 여기에 프로토콜에 관해 적혀 있다곤 생각치 않을 것이다. 대신, 정상회담 같은 곳에서 관찰되는 행동 양식 같은 고 수준으로 정형화된 코드라고 생각하자. 비슷한 양상에서, 프로토콜은 둘 이상의 호스트 간에 메시지를 교환하는 엄격한 룰일 뿐이다.

1.2 UUCP Networks

UUCP는 Unix-to-Unix Copy의 약자이다. 그것은 시리얼 라인(serial line)을 통하여 파일을 교환하고, 전송의 흐름을 통제하며, 리모트 호스트에서의 프로그램 실행을 초기화 하는 프로그램 패키지에서 출발한 것이다. 70년도 후반의 최초 implementation 이후로 몇번의 주된 변화가 있어 왔으나 그것이 제공하는 서비스에 있어서는 여전히 엄격하다. 그리고 아직도 dial-up 전화 링크에 기반한 광역 네트웍에 응용된다.

UUCP는 1977년 Bell Laboratories에서 그들의 Unix-개발 사이트와 교신하기 위해 개발되었다. 1978년 중반, 이 네트웍은 이미 80개의 사이트와 연결되었고 리모트 프린팅 같은 어플리케이션으로서 e-mail을 돌리고 있었다. 그러나 그 시스템은 주로 신 소프트웨어와 bugfix를 배포하는데 주로 사용되었다. 오늘날에는, UUCP는 더이상 UN*X환경에만 제한 되지 않고, 무료나 상용으로 AMigaOS, DOS, Atari's TOS 같은 여러 플랫폼(Platform)으로 포팅(porting)이 가능하다.

UUCP의 가장 큰 결점은 느린 속도이다. 전화 장비라는 것이 최대 전송률에 제한을 주는 것이고, 또 한가지로 UUCP링크가 영구적인 연결이 아니기 때문이다. 즉, 호스트가 일정 간격을 두고 dial-up으로 상호간에 연결을 하므로 mail message가 UUCP 네트웍을 통과하는데 걸리는 대부분의 소요시간은 다음번 연결을 기다리며 호스트의 디스크에 낭창하게 앉아 있는데 있는 것이다.

이러한 제약에도 불구하고 세상엔 아직도 많은 UUCP 사이트가 존재한다. 그것들은 대부분, 취미가가 운영하거나, 개인사용자에게 일정요금을 받고 네트웍에 접근시켜주는 ISP(Internet Service Provider)형식으로 운영되는데, UUCP가 인기를 누리는 주된 원인은 당연히 Big Internet Cable에 컴퓨터를 연결하는 것보다 비용이 저렴하기 때문이다. 컴퓨터를 하나의 UUCP 노드(node: 네트웍의 분기점이나 단말장치의 접속점)로 만들기 위해 필요한 것이라곤 단지 모뎀, 작동중인 UUCP Implementation, 그리고 mail과 news를 제공하길 원하는 또 다른 UUCP 노드 뿐이다.

1.2.1 How to Use UUCP

UUCP에 내재된 원리는 단순하다. 즉, 그것의 이름이 가리키듯, 그것은 단순히 한 호스트로 부터 다른 호스트로 file을 복사하는 것이다. 그러나 그 뿐 아니라 리모트 호스트에서 어떤 작업을 수행 하게도 한다.

당신의 머신이 swim이라는 가상의 호스트에 접근이 허용되어 있고, 당신이 lpr 커맨드를 실행시키고 싶다고 할 때, 다음과 같이 커맨드라인에 적어주면 이 문서를 swim에서 프린트 할 수 있을 것이다.

     $ uux -r swim!lpr !netguide.dvi

UUCP의 또 다른 특성은 job들을 여러 호스트(그들의 협력하에)를 통해 포워드 시킬수 있다는 것이다. swim이 많은 량의 UN*X aplication archive를 지닌 groucho라는 곳과 UUCP 링크가 되어 있다고 가정할 때, tripwire-1.0.tar.gz라는 파일을 당신의 사이트로 다운로드하고 싶다면 다음과 같이 하면된다.

     $ uucp -mr swim!groucho!~/security/tripwire-1.0.tar.gz trip.tgz

생성된 job은 groucho로부터 파일을 가지고 오도록 swim에 요청하고, 당신의 사이트에 trip.tgz라는 이름으로 저장되고 파일의 도착을 알리는 mail이 전달될 것이다. 이것은 3단계에 의해 수행되는데, 첫번째로 당신의 사이트가 swim에게 job을 보낸다. 다음으로 swim이 groucho와 접속한 뒤 파일을 다운로드한다. 그리고 마지막은 swim에서 당신의 사이트로 실제 전송하는 것이다.

현재 UUCP에 의해 제공되는 가장 중요한 서비스는 mail과 news이다. 이에 관해선 다음에 다룰 것이므로 여기선 간략한 소개만 하도록 한다.

Electronic mail(짧게는 email)은 리모트 호스트에 접근하는 방법을 몰라도 사용자가 message를 교환할 수 있도록 한다. 당신의 사이트에서 목적 사이트까지 message를 보내는 임무는 mail handling system에 의해 완벽하게 수행된다. UUCP 환경에선 mail은 주로 수신자 주소와 mail message를 넘겨주도록, rmail 커맨드를 이웃한 호스트에 실행함으로써 운반된다. rmail은 목적지에 도착할 때 까지 message를 포워드 시킬 것이다. 이것에대해선 Chapter 13에서 보다 더 자세히 다를 것이다.

News는 배포된 bulletin board system의 모음이라고 말하는 것이 가장 정확할 것이다. 종종, 이러한 관점에서는 Usenet News를, 집계된 것만 120,000이나 되는 사이트들이 참여하고 있는 news exchange network으로 본다. Usenet의 기원은 1979년, Unix V7과 함께 UUCP가 릴리즈 된 후, Unix community에서의 일반정보교환의 아이디어를 갖고 있던 세 명의 대학원생이 몇개의 script를 집어 넣어 만든 것이며, 그것이 최초의 netnews system이다. 1980년 이 네트웍은 북 캘로리아에 소재한 두 대학의 duke, unc, 그리고 phs에 연결되었고, 이 이외에도 Usenet은 성장했다. 물론 그것이 UUCP기반 네트웍에 기원한다고 해도 이제 더 이상 하나의 단일 네트웍에만 제한되지 않는다.

기본적인 정보의 요소는 특정 주제 전용의 newsgroup 계층에 포스팅된 글이다. 대부분의 사이트는 선택된 newsgroup 만을 수신하는데, 이는 하루당 평균 60MB에 이른다.

UUCP 세계에서, news는 일반적으로 요청된 group의 글을 수집하여 몇개의 batch(컴퓨터로 일괄처리되는 job의 묶음 - 역자주)로 packing하여 UUCP링크를 따라 수신 사이트로 보내진다. 그리고 수신 사이트는 보내온 news를 unpacking하고 그 외의 추가 프로세스를 수행하는 rnews 커맨드를 제공한다.

마지막으로 UUCP는 일반 접근을 허용하는 많은 dial-up archieve 사이트의 매개체이다. UUCP를 이용해서 guest 사용자로 login하여 일반인이 접근가능한 파일을 다운로드할 수 있다. 이러한 guest 계정은 종종 login명으로 쓰이고 그것의 password는 uucp/nuucp 혹은 그와 유사한 것들이다.

1.3 TCP/IP Networks

UUCP가 저렴한 네트웍 커넥션이란 점에선 좋은 선택일지 몰라도, 그것이 가지는 store-and-forward 기술이 경직된 것임을 입증하는 몇몇 상황이 존재하는데, 예를 들자면 Local Area Network(LAN)이 그러한 것이 되겠다. LAN은 보통 같은 건물 내, 혹은 같은 층에 있는 소수의 컴퓨터들이 상호간에 동일한 작업환경을 제공하도록 연결됨으로써 이루어진다. 전통적으로 이들 호스트(host) 상호간에 파일을 공유하거나 다른 머신에 존재하는 어플리케이션도 실행할 수 있다.

이러한 task는 근본적으로 다른 방식의 네트웍 접근을 필요로 한다. job description(작업 수행 순서도라고 보면됨)에 따라 전체파일을 포워드(forward)하는 대신, 모든 데이터를 작은 조각(혹은 packet)으로 나누어 즉시 목적지 호스트로 보내져 그 곳에서 재 조합된다. 이런 방식의 네트웍을 packet-switched 네트웍이라 하고, 타 종류들 중에서도 이것은 네트웍 너머에서 반 능동적인 어플리케이션 실행을 가능케 한다. 이것의 비용은 그 소프트웨어의 복잡성(혹은 정교성?)에 따라 증가한다.

UN*X system(또 non-UN*X site)가 채용한 해답은 TCP/IP라 알려져 있다. 이 절에서 그에 내재된 개념을 살펴보도록 하자.

1.3.1 Introduction to TCP/IP-Network

TCP/IP의 기원은 1969년에 United States DARPA(Defence Advenced Research Project Agency)가 착수한 연구 프로젝트에서 찾을 수 있다. 시험적인 네트웍이었던 ARPANET, 이것은 성공적인 것으로 판명되어 1975년에 실제 작전 가능한 것으로 변환 되었다.

1987년, TCP/IP는 표준으로 채택되어 모든 네트웍 호스트가 그것을 사용하게 되었다. ARPANET이 인터넷으로 성장하게 되었을 때, (1990년에 ARPANET 자체는 사라졌음에도) TCP/IP의 사용은 인터넷 전체로 퍼지게 되었다. 대부분의 주목할 만한 대상은 LAN이었지만, ISDN과 같은 고속 디지털 전화장비의 출현으로, dial-up 네트웍도 전송수단의 하나로써의 미래를 기약하게 되었다.

TCP/IP를 논함에 있어 구체적인 사항을 보여주기 위해 다음 절에서는 Fredland에 위치한 Groucho Marx University(GMU)를 예로서 들 것이다. 다수의 학과가 자신의 로컬 네트웍을 운영하고, 이들 중 몇몇은 하나를 공유하기도 하며, 어떤 곳은 여러개의 로컬 네트웍을 운영하기도 한다. 그들은 모두 내부적으로 연결되어 있고, 하나의 고속 link로 인터넷과 연결되어 있다.

당신의 리눅스 머신이 수학과내에 erdos라는 이름의 호스트로 (UN*X 호스트로 이루어진) LAN에 연결되어 있다고 가정하자. 이 때, 물리학과의 quark에 접근하려 한다면, 다음의 명령어를 입력하면 된다.

        $ rlogin guark.physics
        Welcome to the Physics Department at GMU
        (ttyq2) login:

프롬프트에 login name을 andres라 넣고 패스워드를 입력하라. 그러면 quark쉘이, 마치 당신이 그 시스템 콘솔에 앉아 있는 것 처럼 주어질 것이다. 그 쉘을 빠져 나오면 다시 자기 머신의 프롬프트로 돌아온다. 지금 당신은 지금 막, TCP/IP가 제공하는 즉흥적이고도 능동적인 프로그램인 remote login을 사용해 보 았다.

quark에 연결되어 있는 동안, X11 기반 어플리케이션, 즉 function plotting 프로그램 또는 PostScrip previewer같은 것을 실행시키고 싶다고 하자. 이들 어플리케이션이 당신 호스트의 화면으로 표시되도록 하기 위해선 DISPLAY 환경변수를 지정해야 한다.

        $ export DISPLAY=erdos.maths:0.0

이제, 어플리케이션을 실행시키면 그것은 quark대신, 당신의 X서버와 접촉하여 당신의 화면에 그 프로그램의 모든 윈도우를 표시할 것이다. 물론, 이것은 erdos의 X11서버가 실행중이라는 가정하에서 가능하다. 이의 요지는 TCP/IP가 quark와 erdos사이에 X11패킷을 주고 받음으로써 마치 단일 system을 사용하고 있다는 환상을 준다. 여기서의 네트웍은 대부분 투명성을 지닌다.

TCP/IP 네트워킹에 있어, 또 한가지 중요한 응용법은 NFS로, 이것은 Network File System의 약자이다. 이는 네트웍을 투명성 있게 만드는 또다른 형태인데, 그 이유는 그것이 다른 호스트에서 디렉토리 영역을 마치 local FS(FileSystem)처럼 mount하도록 한다는 것이다. 예를 들자면, 모든 사용자의 홈 디렉토리는 중앙 서버머신에 존재하고, LAN상의 다른 호스트는 그 디렉토리를 mount하는 상황이 있는데, 이의 효과는 사용자가 어느 호스트에서 login하더라도 동일한 홈 디렉토리를 사용할 수 있게 한다. 이와 비슷하게, (TEX 같이)디스크 용량을 많이 차지하는 어플리케이션을 하나의 머신에 설치하고, 다른 머신에 이 디렉토리를 export 시킬수도 있다. 이러한 NFS에 대해선 Chapter 11에서 다시 다루고자 한다.

물론, 이들은 단지 TCP/IP 네트웍에서 할 수 있는 일의 예제일 뿐이고, 그의 가능성은 무궁무진하다

1.3.2 Ethernets

LAN에서 가장 많이 쓰이는 하드웨어 종류는 보통 이더넷(Ethernet)으로 알려져 있다. 그것은 connector, tap 또는 transceiver를 통해 단일 케이블과 연결된 호스트들로 이루어져 있다. 단순한 이더넷의 경우, 설치시 비용이 저렴하고 초당 10Megabit의 속도 때문에 인기가 있다.

이더넷은 세가지 종류가 있다. 즉, 세부적으로 thick,thin, 그리고 twisted pair라 불리는 것들이다. thin과 thick 이더넷은 각각 동축의 케이블을 이용하지만, 이 케이블의 두께와 이를 호스트에 연결하는 방식이 다르다. thin이더넷은 T형의 "BNC" 커넥터를 케이블에 삽입하여 컴퓨터 뒤쪽 플러그에 끼워 돌린다. thick 이데넷은 케이블에 작은 구멍을 내어 "vampire tab"으로 transceiver를 연결해야 한다. thin, thick 이더넷 케이블은 각각 세부적으로 200, 500 미터 거리까지 놓일 수 있으며, 이를 10 base-2, 10base-5라 부른다. twisted pair는 전화 설치시 볼 수 있는 구리선 2개로 이루어진 케이블을 사용한다. 그러나 보통, 이 외에도 추가적인 하드웨어를 필요로 하는데, 그것은 10base-T라 알려져 있다.

thick 이더넷 상에서 호스트 추가가 약간 조잡하긴 하지만, 그것이 네트웍을 다운시키지는 않는다. 그러나 thin net의 경우, 적어도 몇분간은 네트웍 서비스를 중단해야만 한다. 왜냐 하면, 커넥터를 끼우기 위해 케이블을 절단해야 하기 때문이다.

대부분의 사람들이 thin 이더넷을 제안하는데, 그 원인은 바로 저렴한 비용이다. 즉, PC card는 미화 50$ 정도밖에 안되고, 케이블은 미터당 몇센트 정도이기 때문이다. 그러나 큰 규모의 설치시에는 thick 이더넷이 더 적당하다. 예를 들어, GMU의 수학과에선 thick 이더넷을 사용한다. 그러므로 새 호스트 추가시 네트웍 흐름이 붕괴되진 않을 것이다.

이더넷 기술을 저해하는 한가지 요인은 케이블 길이의 제한으로, 이는 LAN이외의 사용을 가로 막는다. 그러나 몇몇 이더넷 세그먼트는 각각 repeater, bridge, 혹은 router로 연결될 수 있다. repeater는 단순히 둘 또는 여러 세그먼트 사이의 신호를 복사하여 마치 모든 세그먼트가 하나의 이더넷인 것처럼 함께 동작하도록 한다. 타이밍 요구상, 네트웍상의 어떤 두 호스트에 4개이상의 repeater는 존재할 수 없다. Bridge와 router는 이보다 좀더 복잡하다. 그것들은 전달된 데이터를 분석하고 수취하는 호스트가 local 이더넷에 존재하지 않을 경우에만 그를 포워드 시킨다.

호스트가 1500바이트에 이르는 패킷(혹은 frame)을 동일 이더넷 상의 다른 호스트에게 보낼 수 있는 상황에서의 이더넷은 마치 bus system처럼 동작한다. 호스트는 이더넷 보드의 firmware(특정 목적의 논리 설계를 정하는 마이크로 프로그램 - 역자주)에 hardcode된 6바이트 수로써 주소화 된다. 이 주소는 흔히 일련의 2자리 16진수를 각각 콜론으로 나누어 표기한다. 즉, aa:bb:cc:dd:ff처럼 말이다.

한 곳에서 보내진 프레임은 연결된 모든 곳에 보여지나, 단지 목적지 호스트만이 이를 받아 처리한다. 만약 두 곳이 동시에 보내려 한다면 충돌이 일어나는데, 이는 두 곳이 전송을 중단함으로써 해결되며 얼마간의 시간후 다시 시도한다.

1.3.3 Other Types of Hardware

Groucho Marx University같이 보다 큰 규모의 설치에서는 이더넷만이 사용되진 않는다. Groucho Marx University에서 각 학과의 LAN은 campus backbone, 즉 FDDI(Fiber Distributed Data Interface)를 돌리는 광섬유 케이블에 연결되어 있다. FDDI는 데이터 전송(즉 기본적으로 일정수의 token을 주위로 보내는 것을 의미함)에 있어서, station이 token을 잡아 내었을 때만 프레임을 보내게 하는, 사뭇 다른 방식의 접근을 사용한다. 이 FDDI의 주된 장점은 100M bps(초당 100메가 바이트)에 이르는 속도와 200KM에 이르는 최대 케이블 길이이다.

원거리의 네트웍을 연결시키기 위해선 X.25표준에 기반한 다른 종류의 장비가 사용된다. 미국의 Tymnet 또는 독일의 Datex-P같은 Public Data Network이라 불리는 곳에서 이 서비스를 많이 제공한다. X.25는 Packet Assembler/Disassembler, 줄여서 PAD라 부르는 특수한 하드웨어를 요구한다. X.25는 자신만의 네트웍 프로토콜 셋을 정의하나 TCP/IP나 다른 프로토콜을 사용하는 네트웍에 연결할 때도 종종 사용된다. IP 패킷이 단순히 X.25로 map될 수 없기 때문에(혹은 그 반대의 경우) 그것들은 단순히 X.25 패킷을 캡슐화 하여 네트웍 너머로 보낸다.

종종, 아마추어 무선기사는 그들의 장비를 컴퓨터의 통신장비로 사용하기도 하는데, 이것을 packet radio 또는 ham radio라 부른다. 이에 사용되는 프로토콜을 가리켜 AX.25라 하는데, 이것은 X.25에서 유래한 것이다.

느리지만 저렴한 또 한가지 기술은 전화연결을 위한 serial line이다. 이것은 패킷을 전송하기 위해, 차후에 다룰 SLIP이나 PPP같은 또 하나의 프로토콜을 사용한다.

1.3.4 The Internet Protocol

물론, 당신의 네트웍이 이더넷에 한정되는 건 원치 않을 것이다. 이상적으로는, 무슨 하드웨어 상에서 실행되든, 어떻게 많은 하부단위로 구성되는 지에 상관없이 네트웍을 사용하길 원할 것이다. 예를 들어 Groucho Marx University와 같은 대규모의 설치에서 연결된 이더넷은 보통 몇개로 나누어 진다. GMU에서 수학과는 2개의 이더넷을 가동하고 있는데, 교수와 대학원생을 위한 빠른 머신의 네트웍이, 그리고 학생들을 위한 느린 머신의 것이 존재한다. 양쪽 모두 FDDI campus backbone에 연결되어 있다.

이러한 연결은 게이트웨이(gateway)라 불리는 전용 호스트에 의해 조정된다. 그리고 이 게이트웨이는 반입되거나 반출되는 패킷을 양 이더넷간과 광섬유 케이블간에 복사함으로써 조정한다. 예를 들어 수학과에 있는 당신의 리눅스 머신에서 물리학과의 quark에 접근하고자 한다면, 이 때 이들은 동일 이더넷상에 존재하지 않으므로 네트워킹 소프트웨어는 quark에 직접 패킷을 보낼 수 없다. 그러므로 그것은 포워드로서의 임무를 수행하는 게이트웨이에 의존하게 된다. (sophus라는 이름의) 게이트웨이는 물리학과의 niels라는 동료 게이트웨이에게 backbone을 통해 이들 패킷을 포워드 시키고, niels는 이를 받아, 다시 목적지 호스트에 배달하게 된다. erdos와 quark의 데이터 흐름은 그림 1.1과 같다.

그림 1.1: erdos에서 quark로 데이터그램을 보내는 과정

리모트 호스트에 데이터를 돌리는 이러한 구조를 라우팅(routing)이라 하고, 패킷은 종종 이 구절에서 데이터그램이라 불릴 것이다. 용이함을 위해, 하드웨어 독립적인 프로토콜, 즉 IP(Internet Protocol)에 의해 데이터그램 교환이 관리된다. IP와 라우팅에 관해서는 2장에서 보다 자세히 다루고자 한다.

IP의 가장 큰 잇점은 물리적으로 다른 네트웍을 외관상 동일한 네트웍으로 변환시키는데 있다. 이를 가리켜 internetworking이라 하고, "meta-network"(여러종류의 다른 네트웍이 결합된 - 역자주)의 결과물을 일컬어 하나의 internet이라 한다. 일반명사로서의 internet과 고유명사로서의 Internet의 미묘한 차이가 바로 이에 있다. 후자는 전 세계적인 'internet'의 공식적인 이름이다.

물론, IP는 하드웨어 독립적인 주소화 구조를 필요로 한다. 이는 IP 주소라고하는 독특한 32비트 수를 각 호스트에 부여함으로써 이루어진다. IP 주소는 보통 4개의 10진수로 표기되며, 이들은 각각 8비트씩 '.'으로 나뉜다. 예를 들어, quark의 IP주소가 0x954C0C04이라고 할 때, 이는 다시 149.76.12.4로 표기될 수 있다. 이러한 양식을 dotted quad notation이라고 한다.

이제, 우리는 주소의 3가지 다른 양식을 알고 있다. 하나는 quakr와 같은 호스트명(hostname)이고, 또 하나는 IP 주소, 그리고 마지막으로 이더넷의 6바이트 주소와 같은 하드웨어 주소이다. 이들은 어쨌든 일치되어야 한다. 그래서 rlogin quark를 쳤을 때, 네트워킹 소프트웨어가 quark의 IP 주소를 얻어서 IP가 데이터를 물리학과의 이더넷으로 전달하면, 그것은 또 어떠한 절차에 의해 그 IP와 상응하는 이더넷 주소를 찾아낼 것이다. 그리고 그것은 다소 혼란스럽다.

우리는 이에관해 여기서 논하진 않고, 대신에 다음 Chapter2 에서 다룰 것이다. 지금은 주소를 찾는 이러한 단계가, 호스트명을 IP주소로 매핑할 때는 hostname resolution이라고 하고, IP 주소를 하드웨어 주소로 매핑할 때는 address resolution이라 부른다는 것만 기억하면 된다.

1.3.5 IP over Serial Lines

시리얼 라인(serial line)상에서, SLIP(Serial Line IP)라는 "사실상의" 표준이 종종 사용된다. SLIP을 보완할 것이 CSLIP(compressed SLIP)이며 IP 헤더를 압축함으로써 시리얼 링크가 제공하는 비교적 낮은 대역폭을 보다 잘 사용할 수 있게 한다. 또 다른 시리얼 프로토콜은 PPP(Point-to-Point Protocol)이다. PPP에는 link negotiation(링크양도) phase를 비롯하여, SLIP보다 더 많은 특성이 있다. 그러나 그것이 SLIP보다 더 나은 한가지 이유는 그것이 IP 데이터그램만을 전송하는데 그치지 않고 다른 어떤 종류의 데이터그램도 전송하도록 설계된데 있다.

1.3.6 The Transmission Control Protocol

물론 데이터그램을 한 호스트에서 다른 것으로 보내는 것이 이야기의 전부는 아니다. 만약 당신이 quark에 login한다면, erdos의 rlogin 프로세스와 quark의 쉘 프로세스 간에 신뢰성 있는 연결을 수립하길 원할 것이다. 그리하여 오가는 정보는 sender에 의해 패킷으로 나누어지고, reciever에 의해 다시 문자의 흐름으로 재 조합된다. 사소한 것처럼 보이지만, 이것에는 골치아픈 task들이 따른다.

IP에 관해 알아야할 아주 중요한 것은 그것이 의도적으로 신뢰성이 없다는 것이다. 당신 이더넷상의 열명의 사람들이 일제히 GMU의 FTP서버에서 XFree86의 최신판을 전송받는다고 가정해보자. 이것이 초래하는 전송량은 게이트웨이가 다루기엔 너무도 크게 될 것이다. 왜냐하면 너무 느리고, 메모리를 소진하게 될 것이기 때문이다. 지금 만약 quark로 패킷을 보낸다면, sophus는 당분간 버퍼 영역이 사라지고, 그것을 포워딩 시킬수도 없다. 이경우 IP는 단순히 그 패킷을 파기해 버림으로써 이 문제를 해결한다. 이 패킷은 되살릴 수 없이 사라지므로 데이터의 보존성과 완전성을 체크하고 에러발생시 재 전송하는 것은 통신하고있는 호스트의 임무이다.

이러한 일은 다른 프로토콜, 즉 TCP(Transmission Control Protocol)에 의해 수행되며, 이는 IP의 최상층에 위치하여 신뢰성 있는 서비스를 구축한다. TCP의 근본적인 특성은, 그것이 IP를 이용하여 당신의 호스트와 리모트 머신의 두 프로세스 간이 단순히 연결되어 있는 것 같은 환상을 줌으로써 당신의 데이터가 어떻게, 그리고 어떤 경로를 따라 이동하는지 신경쓰지 않토록 한다. TCP 커넥션은 근본적으로 양쪽다 읽고 쓰기가 가능한 두갈래의 파이프처럼 동작한다. 즉, 전화 통화 같다고 생각하면 되겠다.

TCP는 두 호스트의 IP 주소와 각 호스트상의 포트(port)라 불리는 수로써 커넥션의 말단 지점을 인식한다. 포트는 네트웍 연결에서 부착지점처럼 보인다. 전화를 예로써 들자면 지역번호는 IP 주소에, 개인별 번호는 포트에 비유된다.

rlogin에서, 클라이언트 프로그램(rlogin)은 erdos의 포트를 열고 quark의 513번 포트, 즉 rlogind 서버가 listen (특정 포트로 접근하는 클라이언트의 요청을 기다리는 것)하고 있는 곳에 연결한다. 이것이 TCP 커넥션을 수립하고, 이 커넥션을 사용하여 rlogind는 인증절차를 수행하고 쉘을 준다. 쉘의 표준입력과 출력은 TCP 커넥션으로 redirect되므로 당신머신의 rlogin에 쳐 넣은 것들은 TCP 스트림(stream)을 따라 통과하여 그 쉘의 표준 입력으로 전해진다.

1.3.7 The User Datagram Protocol

물론, TCP는 TCP/IP 네트워킹에서, 단지 사용자 프로토콜이지만은 않다. rlogin같은 프로그램에서는 적절할 지라도, NFS와 같은 프로그램에서는 과중한 경비가 든다. 그래서 TCP 대신에 형제(sibling) 프로토콜인 UDP(User Datagram Protocol)을 사용하는데, TCP와 마찬가지로 UDP 역시 원격 호스트의 특정 포트의 서비스에 접속할 수 있도록한다. 그러나 그것은 이를 위해 하나의 커넥션을 성립하는게 아니라, 대신 그 이름처럼 단일 패킷들을 목적 서비스에 보내는 것일 뿐이다.

가령, 학과의 중앙 NFS 서버(galios)의 TEX 디렉토리를 mount했다고 가정하고 LATEX의 사용법을 설명한 문서를 보길 원한다고 생각해 보자. 당신은 초기에 파일의 전부를 읽어내는 편집기를 실행하나, 그것은 galios와 TCP 커넥션을 성립하고, 파일을 보내고, 양도하기엔 너무도 과중하다. 그래서 그 대신에, galios로의 요청이 생기면 그것은 그 파일을 몇개의 UDP 패킷으로 나누어 보내는 데, 이 편이 훨씬 빠르다. 그러나, UDP는 패킷 유실이나 손상에 관해선 고려하지 않으므로 (이경우 NFS처럼) 어플리케이션이 이에 관해 조치하도록 한다.

1.3.8 More on Ports

포트는 네트웍 연결의 부착점 처럼 보인다. 만약 어떤 프로그램이 특정 서비스를 제공하길 원한다면, 그것은 자신을 포트에 부착시켜 놓고 클라이언트를 기다린다(이것을 포트상에서 listening한다고 한다). 이 서비스를 사용하고자 하는 클라이언트는 지역호스트의 포트를 할당하고 원격 호스트의 서비스 포트로 연결한다.

포트의 한가지 중요한 특성은, 연결이 클라이언트와 서버간에 성립되면, 또 다른 서버의 복제가 서버의 포트에 부착하여 더 많은 클라이언트를 기다리게 된다는 것이다. 이것은 가령 513번 포트를 사용하여 한 호스트에 동시에 remote login하는 것을 가능케 한다. TCP는 각각에서의 연결을 처리할 수 있는데, 이것은 그들 모두가 각각 다른 포트 또는 호스트에서 온 것이기 때문이다. 예를 들어, erdos에서 quark로 두개의 login을 한다면 첫번째 rlogin 클라이언트는 로컬 포트 1023을 사용하고 두번째는 1022번 포트를 사용할 것이다. 그러나 둘 모두 quark의 513번 포트에 같이 연결하게 된다.

위 예제는 포트가 랑데뷰 지점처럼 사용됨을 보여주는데, 그 지점에서 클라이언트는 특정 서비스를 얻기위해 특정 포트를 접촉한다. 클라이언트가 적절한 포트를 알기위해선, 양 시스템의 관리자 간에 협약이 수립되어 있어야 한다. rlogin같은 서비스가 광역적으로 쓰이기 위해선 이 숫자는 중앙적으로 관리되어야 한다. 이러한 일은 IETF(Internet Engeneering Task Force)에 의해 이루어 지며, 정기적으로 Assigned Numbers라는 주제의 RFC를 내 놓는다. 그것은 well-known services에 지정된 번호를 기술해 놓았다. 리눅스는 /etc/services라는 파일로 서비스를 수로 매핑해 놓았다. 이에 관해서는 The services and protocol Files 절에서 알아보도록 하자.

TCP와 UDP가 같은 포트에 의존하더라도 이 수는 서로 충돌하지 않는다. 이것은 TCP 포트 513과 UDP포트 513간에 차이가 있다는 말이다. 사실상, 이 포트는 서로다른 두 서비스의 용도로 사용되는데, rlogin(TCP)와 rwho(UDP)가 그것이다.

1.3.9 The Socket Library

UN*X 상에서, 모든 일을 수행하는 소프트웨어와 위에 기술된 프로토콜은 보통 커널의 일부이며 이것은 리눅스의 경우에도 해당된다. UN*X 환경에서 일반적인 프로그래밍 인터페이스는 바로, Berkely Socket Library으로, 그 이름은 포트를 소켓으로 보고, 포트에 연결하는 것을 플러그를 꽃는 것에 비유한 데 유래한다. 그것은 리모트 호스트와 전송 프로토콜, 그리고 프로그램이 (connect(2), listen(2), and accept(2)를 사용하여) 연결할 수 있거나 청취하고 있는 서비스를 특정화 하는데 (bind(2))콜을 제공한다. 소켓 라이브러리는 다소 일반적인 것으로, 그것은 TCP/IP기반 소켓(AF_INET 소켓) 뿐만 아니라, 머신의 로컬 연결을 제어하는 클래스 (AF_UNIX 클래스)도 제공한다. 어떤 것은 XNS(Xerox Networking System)프로토콜이나 X.25같은 다른 클래스도 제어할 수 있다.

리눅스에서 소켓 라이브러리는 표준 libc C 라이브러리이다. 현행상, 그것은 AF_INET과 AF_UNIX 소켓만을 지원한다. 그러나 Novell의 네트워킹 프로토콜을 지원하도록 하자는 운동이 전개되고 있으므로 이들을 위한 하나 또는 그 이상의 소켓클래스가 추가될 것이다.

1.4 Linux Networking

세계 각지의 프로그래머들의 노력의 결과로, 전 세계적인 네트웍 없이 리눅스는 존재하지 않았을 것이다. 그래서 발전 초기에 몇몇 이들이 네트웍을 통해 그것을 공급하기 시작했다는 것은 별로 놀라운 일이 아니다. UUCP는 거의 시작단계에 리눅스에서 운영되었고, Ross Biro를 포함한 사람들이 Net-1라 알려진 것을 만들었을 때, 즉 1992년 가을 무렵에 시작된 TCP/IP 기반 네트워킹에 착수하게 되었다.

Ross가 1993년 5월에 실질적인 개발을 그만두게 된 후, Fred van Kempen은 새로운 시도, 즉 코드의 대부분을 다시 쓰는 일에 몰두했다. 계속되는 이러한 노력을 Net-2라 하고, 첫번째 릴리즈인 Net-2d는 1992년 여름에 (커널 0.99.10의 일부분으로서) 만들어 졌다. 그리고 이를 Alan Cox같은 몇몇 이들이 유지하고 확장한 것이 Net-2 Debugged이다. 수 차례의 디버깅과 코드의 개선 후, 그는 Linux 1.0이 릴리즈되자 그 이름을 Net-3로 바꾸었다. 이것이 현재 정식 커널 릴리즈에 포함된 네트워킹 코드이다. Net-3는 (시리얼 라인을 통해 네트웍을 사용할 수 있게) SLIP과 (pararell 포트를 위한)PLIP처럼, 다양한 디더넷 보드의 디바이스 드라이버를 광범위하게 제공하는데, Net-3에서, 리눅스는 로컬 네트웍 환경에서 잘 동작하는 TCP/IP implementation과 상용 PC unice에 육박하는 runtime을 지닌다. 현재의 발전방향은 인터넷 호스트로서 운용되기 위한 안정성과 신뢰성이다.

이러한 유용성 외에도, 리눅스를 다채롭게할 몇몇 프로젝트가 진행중이다. PPP(Point-to-Point Protocol의 약자로, 시리얼 라인을 통해 네트웍을 연결시키기 위한 또다른 수단)는 현재 Beta stage이고, ham radio용 AX.25는 Alpha stage이다. Alan Cox는 Novell의 IPX 프로토콜을 위한 드라이버를 만들었으나 Novell의 것과 완벽히 호환하는 것은 조금더 기다려야 할 것 같다. 그 이유는 Novell에서 필요한 문서를 제공하길 원치 않기 때문이다. 현재 착수 계획중인 것은 samba와, Andrew Tridgell이 만든 Unice를 위한 무료 NetBIOS 서버이다.