이성주 (하이텔:linuxlee)
|
이 글은 Linux Gazette에 실렸던 기사입니다. 이전까지의 기사에서 Ron Jenkins가 권하는 방법대로 가정내 네트워크를 실제 설치해봤습니다. 이제는 자신만의 설정이 필요한 때라고 생각해서인지 Ron이 성능향상의 방법을 소개합니다. 설치된 여러분의 시스템이 정말로 실용적이 되기 위해서 성능과 개선에 대한 Ron의 조언을 참조하시기 바랍니다. 많은 경험과 뛰어난 감각으로 실제적인 성능향상의 팁을 제공하고 있는 이 기사는 다음의 장소에서 원문을 보실 수 있습니다. 계속해서 알찬 내용을 소개해주는 Ron Jenkins에게 감사의 말을 하고 싶습니다. http://www.linuxgazette.com/issue38/jenkins7.html
I. 인터넷 게이트웨이 성능 개선 및 팁 이번의 기사는 지난달까지의 기사에서 좀더 발전된 설정사항과 인터넷 게이트웨이의 성능을 향상시킬 수 있는 몇가지 괜찮은 생각, 팁, 트릭등을 살펴볼 것이다. 각 설치가 배포본마다 다르기 때문에 일반적인 것으로 할 것이다. 이 과정에서는 다음과 같은 주제를 다룰 것이다. ■ 성능 개선에 대한 개론 이번 내용은 필자의 이전 설치과정을 이미 읽었다고 생각하고 작성한 것이다. 또한 이기사의 전체적으로 필자는 WAN 연결과 PPP 연결이라는 말을 섞어서 사용할 것이다.
1. 성능 개선에 대한 개론 성능향상은 다른 주제처럼 향상의 비용과 개선의 양을 서로 비교분석하는 것이 필요하다. 여기서 우리가 관심있는 사항은 우리의 게이트웨이의 성능을 향상시키는 것으로 다양한 기술을 사용하지만 될 수 있는대로 비용은 저렴하게 하도록 할 것이다. 여기서 몇가지 방법이 제시되는데 거기에는 반대급부가 있다. 다음의 제안이 여러분 각자의 상황에는 맞지 않을 수도 있다. 여기의 기술들은 실제적이고 측정이 가능하면서 성능향상이 눈에 보이는 것이다. 그리고 이것들은 오랜기간동안 분석하거나 또는 여러 가지 통계적인 보고방법을 시험하여 분명하게 나타난다. 게이트웨이 장비에 대한 성능을 정확하게 측정하는 것이 효과적인 개선의 기본이다. 지금까지 보아와서 각 기술에 대해서는 익숙하기 때문에 여기서는 이러한 기술에 대한 적절한 측정방법을 소개하고 성능향상의 양과 비율에 대해서 정확하게 측정할 것이다.
2. 성능 향상을 위한 기술 비록 논의된 아이디어나 기술이 다른 형식의 장비(예를 들어 파일서버나 워크스테이션)에 적용될 수 있지만 기본적으로는 이 내용은 게이트웨이 장비의 한정된 성능향상에 집중되어 있다. 이러한 가정을 염두에 두고 다음의 기술들은 게이트웨이 장비의 작동과 속도의 최대한의 향상을 제공하는 것을 목적으로 한다. ■ WAN 연결속도 업그레이드 마지막으로 필자는 일반적인 팁과 트릭을 소개할 것인데 이 것들은 주로 여러분의 게이트웨이의 향상을 위한 내용과 성능을 측정하는데 사용될 수 있는 것들이다.
■ WAN 연결속도 업그레이드 인터넷 게이트웨이의 성능을 증가시키는 가장 효과적인 방법은 인터넷 연결속도를 업그레이드 하는 것이다. 이것은 전용선이나 또는 다이얼업 연결의 형태가 될 수 있다. 이것을 고려했을 때 몇가지 선택사항이 있을 수 있다. 많은 ISP는 “듀얼 모뎀” 서비스를 제공한다. 이것은 두 개의 각각의 모뎀 연결을 멀티링크 PPP를 사용하여 하나로 묶어주는 것이다. 성능향상은 두 개의 각각의 연결의 합보다는 약간 모자란다. 흔히 “윈모뎀” 이라고 불리우는 소프트웨어 모뎀이 아닌 56K 모뎀이 선택사항이 될 수 있다. 필자는 여러분에게 외장 모뎀이 잘 작동할 것이라는 것을 말해두고 싶다. 그리고 만약 내장 모뎀이라면 절대 위에 말한 소프트모뎀을 사용하면 안된다. 이것만 아니라면 아마 잘 작동할 것이다. 현재 BRI(Basic Rate Interface)로 알려진 ISDN(Integrated Services Digital Network)도 게이트웨이 장비의 성능을 향상시킬 수 있는 주목할 만한 방법이다. 필자의 지역에서 ISDN은 무제한 사용에 월 $80.00 정도 비용이 든다. 필자의 지역에서 다이얼업 ISDN 접속에 대한 비용은 $50.00 이고 전체(라인 비용과 ISP 접속비용의 합)은 약 $130.00 정도이다. 다른 가능한 방법은 케이블 모뎀이지만 필자는 이 장비에 대해서는 거의 아는 것이 없다. 왜냐하면 필자의 지역에서는 서비스가 이루어지지 않기 때문이다. 그래서 필자는 이것이 얼마나 비용면에서 효과적인지 알 수 없다. 일부지역에서는 Digital Satellite Network 시스템이 사용 가능할 수 있다. 이것도 위성으로부터 깨끗한 수신이 보장되는 한은 좋은 선택이 될 수 있다. 그러나 위성 연결은 단방향일 때가 많다. 즉 원거리 위성에서 자신의 PC로만 전송이 가능한 것이다. 이것을 보통 하향링크(downlink)라고 불린다. 상향링크(uplink)나 원거리 네트워크에 대한 여러분의 요구에 대해서 위성과는 다른 분리된 접근방법이 요구된다. 이것은 보통 간단한 모뎀으로부터 전용선까지 어떠한 것으로도 될 수 있다. ■ WAN 접속 성능을 측정하기 이것을 할 수 있는 몇 개의 프로그램이 유틸리티가 있다. 필자는 netwatch 라는 프로그램을 사용하는 편이고 이 프로그램은 네트워크를 모니터링하거나 여러분의 라우터의 속도를 측정하는데 손쉬운 도구가 될 수 있다. 이 유틸리티는 레드햇의 일반적인 배포본에는 포함되어 있지 않지만 슬랙웨어 3.6에는 포함되어 있다. 레드햇 미러링 사이트에 조금 지난버전의 RPM 파일이 있다. 장소는 /powertools 디렉토리이다. 여러분이 사용할지도 모르는 압축선택사항의 효율성뿐만 아니라 WAN 연결의 실시간 조건을 점검하기 위해서 pppstats 라는 유틸리티도 도움이 될 수 있다. 이 유틸리티는 슬랙웨어나 레드햇 장비 모두에서 사용할 수 있다. ■ 하드웨어 업그레이드 로컬 네트워크 접속에 대한 성능을 향상시키기 위해서 RAM과 디스크 서브시스템을 좋은 것으로 하는 것이다. 여러분의 메인보드가 메모리를 다루기에 충분한 캐쉬를 제공한다면 게이트웨이 장비나 여러분의 서버에 많은 RAM을 넣어두는 것이 좋다. 다른 중대한 영역은 디스크 서브시스템이다. 비록 여기에는 ATA 기술(EIDE, UDMA 등)이라는 중요한 발전사항이 있지만 원래 이것의 표준은 상당히 버겁고 연속적인 사용이기 때문에 높은 성능은 아직까지 SCSI(Small Computer Systems Interface)와 SCSI 장치이다. IDE 장치에 대한 알아야 할 가장 중요한 것은 연속적인(SEQUENTIAL) 접근 장치라는 것이다. 즉 이것은 한 요청이 끝날때까지 다음 요청은 대기 상태에 있다는 것을 의미한다. SCSI 장치는 동시적(CONCURRENT) 접근 장치이다. 즉 동시에 여러 곳에서 동시에 다중요청이 가능하다는 것이다. IDE 장치와 그에 상응하는 SCSI 장치사이의 가격차이가 과거에는 많았지만 현재에는 거의 무시할 만하다. 최소한 울트라(20MBS)정도의 드라이버를 구하고 울트라와이드(40MBS) 드라이브라면 더욱 좋다. SCSI 서브시스템은 다음의 네가지 기본적인 부분으로 구성되어 있다. 호스트어댑터는 PC에 장착하고 SCSI 장치와 컴퓨터사이의 통신을 담당한다. SCSI 버스는 발생하는 데이터의 상호교환을 담당한다. 보통 40이나 50핀 케이블을 사용하고 이것은 호스트의 속도에 따라서 다르다. SCSI 장치는 디스크나 스캐너 테이프 드라이브 그리고 많은 다른 장치들이다. 버스에 장착할 수 있는 장치의 개수는 호스트의 속도에 따라 다르지만 IDE 호환장치같이 네 개로 제한되어 있진 않다. 테미네이션 장치. 이전기사에서 보았던 네트워크 버스에서와 같이 SCSI 버스도 양쪽 끝에 터미네이션이 필요하다. 이것은 10BASE2 동축케이블 네트워크와 같다. 터미네이션은 능동이나 수동으로 될 수 있는데 이것은 추가적인 장치가 더 붙을 수 있느냐 아니냐에 달려있다. 주로 외장장치에 관련된다. U2W 장치는 필자가 언급하진 않았지만 여러분이 알고 있을지도 모른다. 이러한 장치에 대한 지원은 필자가 아는 한 현재 개발단계에 있다. 그래서 이러한 장치에 대한 언급은 조금 미루도록 하겠다. 게다가 이것은 매우 비싸다. 참고사항 : 아래에 언급할 케이블링 기술을 구현할 계획이 아니라면 디스크 서브시스템의 업그레이드는 성능향상은 그렇게 크지 않을 것이다. 간단한 라우팅과 매스커레이딩은 커널에서
담당하여 빠르게 수행되고 디스크를 최소한도로 사용한다. ■ 소프트웨어 업그레이드 소프트웨어의 향상이라는 측면에서는 고려해야할 몇가지 선택사항이 있다. PPP 소프트웨어 - 여러분은 PPP 소프트웨어를 업그레이드해야할지도 모른다. 이 경우는 배포본이 PPP 버전 2.3.0보다 더 높은 버전을 제공하지 않는 경우이다. 이 버전은 요구(demand) 다이얼링 선택사항을 지원한다. 그래서 diald 와 같은 추가적인 항목이 필요없게 된다. 또한 ppp-xx에 근거를 두고 설치시에 준비되며 그것들이 작동을 하기 위해서 몇가지 편집이 필요하지만 매우 효율적인 스크립트 방법을 지원한다. 이러한 파일은 보통 /etc/ppp나 또는 /usr/sbin 에 위치한다. 자료 압축 - 자료 압축 이론은 이 기사의 범위를 넘어서는 것이지만 간략하게 압축방법에 대한 개관과 이것이 WAN 인터페이스를 통하여 오고가는 트래픽에 얼마만큼 속도 향상에 기여하는지 알아보자. ● Van Jacobson(VJ) 압축- 이것은 대부분의 리눅스 배포본의 PPP 데몬의 기본설정이다. ● BSD 압축(bsdcomp) - 다른 압축 방법으로 보통은 기본설정되어 있지 않다. 모듈로 로딩할 수 있고 또는 다시 커널을 컴파일해서 커널에 직접 집어넣을 수 있다. ● 수축 압축 - 다른 압축방법이고 기본적으로는 활성화되어 있지 않다. 이러한 압축 방법들을 조합해서 사용하는 것은 PPP 연결시에 명백하게 성능향상을 만들 수도 있고 그렇지 않을 수도 있다. 각각의 것을 활성화시키거나 비활성화 시키기 위해서는 pppd 맨 페이지를 참고한다. 그것들이 제대로 동작하는지 확인하려면 netwatch 등을 통해서 변화에 대한 속도의 비교를 해보면 되고 pppstats를 사용하여 얼마만큼의 압축이 이루어지는지를 확인해 보면 된다. ● BIND - BIND(Berkley Internet Name Daemon) 이것은 보통 named 으로 불리는 것으로 IP 어드레스에 대한 호스트네임을 알려주는 서비스를 한다. 그래서 DNS (Domain Name Service) 라는 말로 사용된다. 여러분이 완전한 형태의 DNS 서버를 운영하는 것은 실용적이지 않지만 “caching only” 네임서버를 운영하는 것은 도움이 될 것이다. 인터넷에 어떠한 객체에 대한 요구를 할 때마다 즉 웹페이지나 ftp 사이트, 뉴스서버 등등을 요구할때마다 호스트네임/객체의경로 형태의 요구가 이루어진다. 이러한 요구들은 밖으로 나갈때는 resolv.conf 파일에 지정된 DNS 서버를 사용한다. DNS 시스템이 계층적이기 때문에 여러분의 resolv.conf 파일에 적은 DNS 서버는 거의 밑바닦 지점에 위치하는 것이다. 여러분의 DNS서버는 오직 자신의 네트워크(여기서는 여러분의 ISP)에 속한 로컬 머신에 대한 것만 알고 있다. 이 정보는 “zone” 파일이라고 불리는 곳에 ASCII 텍스트 파일로 되어 있고 “zone”에 대한 정보와 도메인의 표준형태를 가지고 있다. 만약 이러한 장비가 어떤 요청을 알 수 없다면 다음 더 높은 장치에 묻게 된다. 그래서 필요하다면 최상위까지 간다. 그래서 질의는 “root.servers” 의 책임이 된다. 즉 *.com, *edu, *.net 등의 도메인등에 대해서 알려주게 되는 것이다. 마지막으로 어떤점에서는 많은 상호간의 통신이 WAN 연결에서 이루어진 후에 여러분이 요구한 호스트네임이 IP 어드레스로 변환되어져서 요구한 컴퓨터까지 되돌아갈 수 있는 것이다. 명확하게 이렇게 뒤에서 이루어지는 통신의 양이 생각보다 많다. 캐쉬 네임서버는 간단하다. 즉 한번 IP 어드레스를 해석한 내용의 이름을 일정시간 동안 기억하고 있는 것으로 네임서버는 지역적으로 요청을 서비스하고 자신의 네트워크 밖으로는 서비스하지 않는 것이다. 이것은 두가지 점에서 좋은 방법이다. 즉 이름해석을 좀더 빨리 할 수 있고 WAN에 대한 트래픽을 줄일 수 있는 것이다. 이것에 대한 단점은 아주 “새로운” 요구가 들어왔을때는 속도가 좀더 느려진다는 것이다. 그러나 어디서나 반대급부는 있는 것으로 보통의 이러한 지연은 그렇게 크지 않다. 그래서 이 기술은 보통의 경우 아주 괜찮은 방법이다. * 일단. 여러분의 ISP가 root.servers 파일에 포함된 것들에 속해있는 다른 네트워크에 대해서 알고 있다면 가능하다. 그러나 여기에서의 시나리오에는 관계없는 이야기이다. * 실제적으로 BIND는 많은 프로그램으로 구성되어 있고 각각은 특별한 일을 수행한다. 가장 중요한 부분은 해석기이다. Apache - Apache http 서버는 캐쉬기능을 활성화시킬 수 있다. 그리고 이것은 WAN 트래픽에 맞추어서 줄어들 수 있다. Apache 문서를 찾아서 활용하기 바란다. Squid - 이것은 웹의 프록시/캐쉬 소프트웨어이다. 이것은 무제한으로 설정할 수 있고 많은 서비스를 지원한다. Squid에 대해서 알아보려면 여러분의 설정을 잘 해놨다면 문서의 끝에 있는 리소스 부분을 확인해보면 된다. Leafnode - 이것은 NNTP(Network News Transport Protocol) 서버로서 대부분의 유닉스 설치에서 사용되어진다. 매우 작고 설정이 쉬우며 보통의 인터넷 News 소프트웨어가 차지하는 디스크 공간보다 적은 공간을 차지한다. 물론 반대급부가 있는데 이것은 확장성이 좋지 않다는 것이고 처음에 선택한 뉴스그룹으로부터 기사를 받아올 때 WAN 대역폭을 거의 대부분 사용하게 된다. (이러한 혼잡을 최소화하는 방법으로 ‘일반적인 팁과 트릭’에서 cron 부분을 확인한다.) Leafnode 에 대해서 더 자세한 사항을 보려면 해당 문서를 참조한다. ■ 캐쉬 선택사항 ● 캐쉬 옵션의 이득 - 어떤 문서(예를들면 웹 페이지나 뉴스의 기사)나 또는 데이터 객체(예를들면 IP 해석을 위한 도메인네임)를 로컬에 저장할때마다 이것은 여러분의 게이트웨이가 여러분의 요청사항을 로컬에서 서비스할 수 있고 따라서 여러분의 WAN(PPP) 연결을 통한 트래픽의 양을 줄여주는 것이다. 이것은 매우 좋은 일이고 속도에서도 증가된 점을 확실히 알 수 있으며 WAN 연결은 다른 요청이나 일을 위해서 남겨둘 수 있게 된다. 추가적으로 만약 디스크의 공간이 충분하다면 여러분에게 필요한 뉴스를 스풀링하는 것도 좋은 생각이다. 이것은 로컬네트워크를 유즈넷 스풀로 접근할 수 있게 하여 다운로드한 후(보통 fetch 라고 불리우고 이것은 여러분의 대역폭을 모두 사용하여 집어온다) 로컬네트워크에 저장하고 WAN을 종료한다. ● 캐쉬 옵션의 단점 - 그러나 여기에도 반대급부가 있다. 이러한 형식의 캐쉬작업은 “고정될” 가능성이 있거나 거의 변화가 없게 되는 경우가 있다. 캐쉬서비스에 주어진 만료 인자(여러분의 로컬장비에 문서와 객체가 머무르는 시간)에 따라서 여러분은 “어제의 뉴스”를 볼 가능성도 있다. 이것은 부분적으로 웹 캐쉬영역에서 고려할 사항이지만 뉴스도 실시간으로 갱신되지 않는 문제가 발생한다. ● 캐쉬 전용 네임서버의 구성 - BIND는 여러분의 장비에 이미 설치되어있을지도 모르지만 이것은 설치시에 여러분의 선택에 따라서 달라진다. 만약 배포본이 BIND 버전 8.1.x나 그 이상이 아니라면 업그레이드를 하도록 한다. 4.x.x 버전은 더 이상 개발이 되지 않고 있으며 8.x.x에 새로운 기능들이 추가되었다. 새로운 기능에는 동적인 zone 전송과 구성의 간편함등이 포함되어서 업그레이드의 가치가 있다. BIND를 개발하고 유지하는 ISC(Internet Software Consortium)의 URL 부분에서 자료를 얻을 수 있다. ● 슬랙웨어 3.6 - 슬랙웨어 배포판은 네임서버를 활성화시키는데 몇가지 작업이 필요하다. 이것은 할만한 일이고 여러분이 이것을 설정할 때 여러분은 이것이 어떻게 작동을 하는지에 대해서 좀더 많은 것을 알게 될 것이다. 그래서 그들이 개발할 때 문제를 고치고 점검을 할 수 있도록 도움을 줄 수 있을 것이다. 먼저 /var/named 라는 디렉토리가 필요하다. 만약 없다면 만든다. 다음으로 루트 서버들의 리스트를 가진 파일이 필요하다. 그리고 여러분의 로컬 정보로서 서비스할 수 있는 파일(zone 파일)도 필요하다. 이러한 파일들은 root.cache 그리고고 127.0.0 이라고 불리었다. 이 두파일의 예는 DNS-HOWTO에 나와있다. 마지막으로 여러분은 named.conf 파일이 필요하다. 이것은 BIND의 시작시 넘겨줄 인자들을 가지고 있다. 캐쉬 네임서버로서 사용한다면 다음의 항목들에 대해서만 잘 보면 된다 // Config file for caching only
name server C/C++ 프로그래밍언어에 익숙한 사람이라면 named.conf 파일의 문법에 유사성이 있다는 것을 알 것이다. 간단하게 처음 부분은 작업디렉토리를 지정하는 것이고 두 번째 부분은 루트 서버파일을 지정하는 것이고 마지막부분은 여러분의 “zone” 파일이다. 이 설정파일은 /etc/디렉토리에 위치하고 있다. 마지막으로 여러분의 resolv.conf 파일을 편집한다. 즉 게이트웨이 장비가 처음에 우리의 네임서버를 찾고 그 다음에 ISP를 찾게 한다. search home.net 그런다음 여러분의 home.net 클라이언트들도 이름해석을 위해서 게이트웨이 장비를 사용하도록 바꾼다. search home.net ● 레드햇 5.x - RPM으로 설치할 때 자동적으로 캐쉬서버가 설치될 것이다. 만약 그렇지 않았다면 위의 필요한 파일을 확인하고 named.conf를 예를 보면서 적절히 설정한다.
3. 일반적인 팁과 트릭 ● 늦은 밤에 cron을 이용한 트릭 - Cron(chronometer의 약자이다.)은 사용하기 편한 데몬이다. 이 데몬은 사용자가 입력할 필요없이 지정한 날의 지정한 시간에 스크립트나 명령어를 수행한다. 이러한 방식은 유닉스 장비에서 필요한 많은 매우 단순한 작업들 - 예를들면 로그 파일처리, ftp 작업, 또는 우리의경우에 뉴스와 캐쉬서버 역할등 - 을 자동화시켜준다. 해야할 작업은 crontab 이라는 파일에 포함되어 있다. 이 파일이 여러분의 시스템에 하나 이상 있을 수 있다. 즉 설치시에 어떻게 설정했느냐 그리고 얼마나 많은 사용자들이 있느냐에 따라 달려 있다. 이 파일들은 /var/spool/cron/crontabs 디렉토리에 있다. ● cron으로 작업을 자동화하기 - crontab 파일에 항목을 편집하거나 더하기 위해서는 crontab -e 명령을 사용한다. 일단 파일이 열리면 항목들이 다음 형식으로 나타난다. <분> <시간> <날짜> <주> <달> 명령어 설정이 필요없는 부분은 별표(*)로 나타난다. 예를들면 leafnode를 계획하는데 사용자들에 최대한 부담을 주지 않는 아침 이른 시간에 다운로드할 수 있도록 하기를 원할 것이다. 이러한 뉴스를 가져오는 작업을 아침 4:00에 시작하려 한다면 항목을 다음과 같다. 0 4 * * * /usr/sbin/fetch ● cron에서 스크립트 호출하기 - 종종 연속된 명령을 실행시키거나 하나 또는 그 이상의 명령어에 많은 옵션을 주어야 하는 경우가 있다. 쉘 프로그램을 해보자. 이것은 연속된 명령을 실행하는 내용이다. 즉 마지막 명령어가 실행된 후에 끝나는 것이다. 이것은 몇가지를 손질해야 한다. 사실은 이전에 만든 unicom 파일은 쉘 스크립트이다. 예제로서 여러분은 wtmp 파일을 제거하고 매 한 시간마다 새로운 파일을 만든다고 생각해 보자. 이러한 것을 하기 위한 스크립트는 다음과 같다. #!/bin/sh #all scripts should start
with your preferred shell 이러한 쉘 스크립트는 여러분의 시스템에 있는 많은 에디터를 사용해서 만들 수 있다. 이제 이 파일이름을 wtmpclean 이라고 붙여보자. 이것을 시스템에서 실행되게 하려면 chmod 명령으로 권한을 바꿔줘야 한다. chmod +x wtmpclean 이 스크립트를 cron에서 매시간 마다 실행되게 하려면 여러분의 crontab 항목에 다음을 추가시킨다. 0 * * * * /usr/sbin/wtmpclean ● 웹 브라우저의 캐쉬 설정 - 네트스케이프는 브라우저가 디스크와 메모리 캐쉬를 얼마만큼 사용할 것인지를 지정할 수 있는 항목이 있다. 즉 브라우저가 요청한 내용 - html 페이지, gif, jpg 등등 - 을 유지하기 위해서 디스크와 램의 여유를 두는 것이다. 이러한 설정을 하기 위해서는 네트스케이프 메뉴의 Edit/Preferences/Advanced/Cache 항목을 설정한다. 여기에서 램과 디스크의 공간을 제한시켜주는 것이다. 여러분은 필요한 디스크와 메모리 캐쉬의 크기를 늘이거나 줄일 수 있고 얼마나 자주 브라우저가 WAN을 통하여 원래의 문서와 비교를 해서 갱신시킬 것인가를 지정할 수 있다. 이전에 언급한 제한 사항을 유념해둔다. 이것은 만약 여러분이 갱신이 매우 자주 일어나는 주식거래등과 같은 것만 보지 않는다면 “Once per session”으로 설정하는 것이 최선일 것 같다. ● 모뎀의 성능향상 - 대부분의 모뎀은 추가적인 기능을 사용함으로써 성능을 향상시킬 수도 있다. 해당 모뎀의 매뉴얼을 보고 실험을 해본다. ● 데이터 라인의 점검 - 한 달에 한번 정도는 전화회사에 여러분의 전화라인에 대한 점검을 받아서 통신을 위해서 선로를 최적화 시킨다. 이것은 여러분에게 유용할 수도 있는 것으로 대부분의 도시지역이 아닌 곳에서는 도움이 될 것이다.
II. 진보된 네트워크 서비스 이번에는 좀더 진보된 서비스를 시험해볼 것이다. 이것은 여러분이 여러분의 가정내 네트워크에서 사용할 수도 있고 하지 않을 수 도 있을 것이다. 특별히 우리는 연결 스크립트, 자동 전화걸기 수행, 시간 동기화를 좀더 합리적으로 하기 위해서 일부 옵션을 사용할 것이다. 이번에서 우리는 다음과 같은 부분을 관심있게 볼 것이다. ■ 연결 스크립트의 옵션을 자신의 상황에
맞추기
1. 연결 스크립트의 옵션을 자신에게 맞추기 필자는 여러분의 PPP 소프트웨어가 버전 2.3 이상이어야 한다고 그다지 강조하지 않았다. 이 버전에는 추가기능이 있는데 다음과 같은 것들을 가능하게 한다. 버전 2.3 이상 에서는 예전에 유사한 기능을 수행하기 위해서 보조적인 프로그램을 실행시키는 대신에 스크립트 자체에서 직접적으로 실행되는 것들이 생겼다. ● 자동재연결(Auto-reconnect) - 이 옵션은 연결 스크립트의 “persist” 옵션을 사용하여 가능하게 한다. 이옵션을 사용함으로써 우리가 이전에 사용하였던 pppupd 소프트웨어를 사용할 필요가 없어졌다. ● 자동전화걸기(Demand Dialing) - 이 옵션은 연결 스크립트의 “demand” 키워드를 사용하여 가능하게 된다. 이것은 diald 와 같은 패키지외의 프로그램이 필요없게 되었다. 그래서 이러한 옵션들의 이점을 이용한 새로운 버전의 스크립트는 다음과 같다. 연결 스크립트 예제 #!/bin/sh chat 스크립트가 필요한 부분은 변경되지 않았다. 단지 이것은 초기의 터미널 로그인을 다루는 것이고 PPP 데몬에 넘겨주는 것이다. 또한 만약 여러분 ISP의 “무제한 사용” 이라는 것이 매일 10시간 내지는 12시간으로 제한을 받을 것일 수 있다. 필자는 만약 이러한 경우라면 다른 ISP로 옮기라도 강력히 권하고 싶다. 만약 계속 사용할 것이라고 한다면 자동 전화걸기 기능이 필요할 것이다. 여러분이 매 시간에 수동으로 연결을 원하지 않는다면 또는 여러분이 인터넷을 사용하는 시간이 정기적이라면 여러분은 아마 cron 에 연결과 연결을 종료하는 내용을 적어서 실행시키기를 원할 것이다. 예를 들면 여러분은 매일 오전 8:00 에서 오후 8:00까지 연결하는 것으로 하자. 그리고 자동적으로 이과정이 이루어지도록 하자. 여러분은 간단히 “crontab -e” 명령으로 crontab 파일을 열어서 다음과 두 행을 추가시키자. 0 8 * * * /path/to/your/connect/script 또는 우리가 사용한 우리의 예제를 계속사용하자. 0 8 * * * /sbin/unicom
2. 시간 동기화 비록 우리는 이것에 대해서 자주 생각할
필요는 없지만 시간은 컴퓨터와 프로그램에 적당한 작동을 하게
할 때 매우 중요하다. 유닉스와 리눅스는 부분적으로 시간에 대해서 매우 모순된다. 그리고 만약 두 개의 장비가 서로 시간이 일치하지 않으면 여러분의 프로세스와 데이터에 귀찮은 일이 생길 수도 있다. 간단히 여기에 시간을 정확히 측정하기 위한 두가지 방법이 있다. 내장장치(보통 CMOS 클럭) 으로부터 또는 외부 자원(타임 서버 또는 주파수 표준등)으로부터 시간을 설정할 수 있다. 이러한 것은 예전에 아마추어 라디오를 사용해본 사람에게는 익숙한 것이다. 그리고 가능한 주파수는 정부가 소유하고 있지만 여러분에게 사용할 만한 것이 몇 개 있기는 하다. 여러분의 내장 CMOS 클럭은 신뢰할 수 없고 연속적인 전원공급에 의존하고 있다. 그리고 현재 우리에게는 우리의 장비들을 동기화시키는데 집중할 것이기 때문에 우리는 네트워크의 외부의 소스에서 원하는 것을 가져올 것이다. 시간에 대한 “절대표준”은 Colorado의 Fort Collins의 NIST(National Institutes of Standards and Technology)에 있는 원자시계이다. 이 표준을 여러분의 네트워크를 동기화 시키고 모뎀이 연결을 하기 위해서나 GPS에 라디오 주파수 수신의 범위를 지정하는데는 여러 가지 방법이 있다. 우리는 인터넷을 통해서 이러한 동기화를 할 것이다. 이러한 목적을 위해서 거의 표준처럼 사용되는 NTP(Network Time Protocol)이라고 불리우는 것이 있다. 일부시스템(예를 들면 레드햇 기반의 시스템)은 ntp나 xntp 가 자동적으로 설치되곤 했다. 좀더 많은 자료를 원한다면 관련문서를 참조한다. 만약 슬랙웨어를 기반으로 사용한다면 여러분은 같은 작동을 하기 위해서 netdate 라 불리는 유틸리티를 사용할 수 있다. 여러분은 netdate를 직접 시작할 수 있다. 이것은 cron 으로 해서 스크립트를 돌리면 되는 것이다. 관련문서를 참조한다. 어떠한 시스템이든지 하나 나 또는 그 이상의
서버를 지정해서 정확한 자료를 얻도록 하는 것이 필요하다. 첫 번째 계층서버는 위성전파나 또는 모뎀에 의해서 보통 원자시계에 직접적으로 논리적인 연결을 가지는 서버이다. 위성전파나 모뎀은 좀더 정확한 시간측정을 위한 연결 외부장치이다. 두 번째 계층 서버는 첫 번째 계층서버로부터 데이터를 얻고 그것을 두 번째 계층의 다른 장치에 전달하고 세 번째 계층 서버에게도 전달한다. 대부분의 홈 애플리케이션과 업무 애플리케이션은 “실시간”이 필요치 않다. 두번째 서버 계층 정도가 여러분의 필요에 적합하다. ntp 소프트웨어와 타임서버에 대한 것은 리소스 섹션을 본다.
3. 자동 전화걸기 만약 위의 설명을 잘 따랐다면 이것이 논쟁점이 될 것이다. 만약 여러분이 PPP 소프트웨어를 2.3 이상으로 올리지 않았다면 여러분은 diald 나 또는 그외 유사한 기능의 요구 다이얼링 기능을 가지는 것들이 필요할 것이다. diald 나 또는 다른 프로그램에 대한 구성은 이 문서의 범위밖이다. 관련된 프로그램문서와 맨페이지를 참조한다. 다음에는 프린터 서비스를 정복해 봅시다.
III. 참고문헌 ■ 기사 : 이전 기사들 ■ 다른문서들 Pppd man pages ■ 좀더 깊이있는 정보를 얻을 수 있는 곳 ● 웹 ● Squid Software: ● 뉴스그룹 ● 프린터 |