스타호스트

Outlook 에서 이메일 포트 변경하기

2010-07-15T20:49:20+09:00

* 본 설명은 2010년 12월 이메일 발송포트(25번)차단 및 587포트 전환을 위한 설명 입니다.

* 스타호스트 에서 유료 사용자인 동시에 아웃룩 으로 이메일을 송수신 하시는 분들을 위한 메뉴얼 입니다.

* Outlook 2007 이외에 Outlook, Outlook Express, Outlook 2000, Outlook 2003 에서도 설정 위치만 다를 뿐 방법은 같습니다.

* 본 설명은 유료 호스팅에서 제공하는 기능으로 무료웹호스팅 에서는 이메일 기능을 제공하지 않고 있습니다.

1. 메뉴에서 [도구] > [계정 설정]을 선택합니다.

2. 계정 설정 창에서 붉은색 박스의 변경 을 클릭 합니다.

3. 계정 변경 창에서 오른쪽 하단의 기타 설정을 클릭 합니다.

4. 상단의 고급 탭을 클릭 후 보내는 메일 서버(SMTP) 에 587 을 작성 후 확인을 클릭 합니다.

5. 계정 변경 창에서 오른쪽 상단의 계정 설정 테스트를 클릭 하여 메일 송수신이 정상적으로 되는지 확인 합니다.

6. 계정 설정 테스트가 성공한 그림 입니다.

제로보드 XE 1.4.3 으로 업데이트시 확인 사항

2010-07-06T21:33:50+09:00

* 제로보드 XE 1.4.2.x 에서 1.4.3 으로 쉬운설치로 업데이트 후 생기는 약간의 문제에 대해서 설명 합니다.

* 쉬운설치로 업데이트 하신 후 아래의 과정을 순서대로 진행하시길 권합니다.

* 반드시 한번 이상 정독 하신 후 업데이트를 진행하시기 바랍니다!
* 아래의 방법은 저희 스타호스트 서버에서 진행된 테스트 이므로 타 서버와 증상이 다를 수 있습니다.

* 이 오류는 제로보드XE 에서 발생하는 문제로 서버마다 증상이 다를수는 있으나 이번 업데이트시 거의 공통적으로 발생하는 문제임을 알려드립니다.

[XE 코어 업데이트]

1. 자신의 홈페이지의 제로보드XE 관리자로 로그인 합니다.

2. Settings 를 클릭하여 시작모듈을 어떤것을 쓰고 있었는지 기억해 둡니다.

3. 시스템 관리 --> 쉬운설치에서 XpressEngine Core ver. 1.4.3 업데이트 클릭 후 비번 입력후 확인

4. 업데이트 완료

[XE 코어 업데이트 후 증상]

1. XE 제어판이 모두 영문으로 보입니다.

2. 오른쪽 상당의 Settings 를 클릭 후 시작 모듈을 보면 () 처럼 되어 있어서 홈페이지가 뜨지 않습니다.

3. 왼쪽 상단의 제어판 이미지를 클릭 하면 모듈에 몇가지가 붉은색으로 되어 있습니다.

[XE 코어 업데이트 후 해결방법]

1. 왼쪽 상단의 제어판 이미지를 클릭 후 모듈에 나온 붉은색 부분이 나온 모듈 세개를 update 버튼을 클릭하여 업데이트 합니다.

2. 오른족의 "캐시파일 재생성" 버튼을 클릭 하여 캐시파일을 재성생 해줍니다.

3. 오른쪽 상단의 Settings 를 클릭 하여 중간에 Language 를 "한국어" 로 선택 후 오른쪽 아래에 "저장" 을 클릭 합니다.

(최 하단의 FTP 등록 이 아닌 FTP 계정 정보 입력 전에 나오는 "저장" 을 클릭 하여야 합니다)

4. 오른쪽 상단의 Settings 를 클릭 하여 시작 모듈 에서 업데이트 전에 사용중이던 시작모듈을 등록해 줍니다.

5. 2번에서 실행했던 오른쪽 아래에 "저장" 을 클릭 합니다.

(최 하단의 FTP 등록 이 아닌 FTP 계정 정보 입력 전에 나오는 "저장" 을 클릭 하여야 합니다)

본인의 홈페이지에 접속해 봅니다.

업데이트 전에 운영하셨던 홈페이지가 뜬다면, 정상적으로 완료된것입니다.

수고하셨습니다.

P.S.

위와 같이 진행 하여도 문제가 발생하는 경우 제로보드 코어 공식 사이트에 방문 해보시기 바랍니다.

또한 payment 모듈을 사용하시는 분이 계시다면 아래의 제로보드 공식 사이트에 방문 해보시기 바랍니다.

http://xe.xpressengine.net/

구글 앱스 사용하기(DNS 레코드 설정-독립 도메인 사용)

2010-03-26T08:48:01+09:00

========== DNS 레코드 설정(CNAME)으로 독립 도메인을 구글앱스로 연동하기 ==========

※ 주의 : DNS Record 설정은 고급 사용자만 사용하시기 바라며, 충분한 사전지식 없이 사용하시면 사이트에 치명적인 오류가 생길 수 있습니다. 본 메뉴얼 이외의 방법을 사용하시려면 충분한 사전 지식을 습득하신 후 사용하시기 바랍니다.
* 본 설명은 유료서비스 회원들이 DNS 레코드 설정(CNAME)으로 본인의 독립 도메인의 서브도메인으로 구글이메일 또는 구글칼린더 등으로 접속이 가능하게 해주는 방법을 설명 합니다. 예를들어 본인의 도메인 앞에 mail. 을 붙여서 구글앱스의 이메일과 연동하실 수 있습니다.
예)
[홈페이지] http://demo.starhost.co.kr
[구글이메일] http://mail.demo.starhost.co.kr
[구글칼린더] http://calendar.demo.starhost.co.kr

* 구글 앱스의 이메일 및 도메인 소유권 확인과 MX 레코드를 이용하는 방법은 본 사이트의 "제어판 메뉴얼" 에 있는 구글 앱스 사용하기(MX Record 설정) 을 참고 하시기 바라며, MX 레코드를 이용하는 방법으로 구글앱스를 사용중이거나 셋팅이 완료 되었다는 가정하에 본 설명은 진행 합니다. 반드시 MX 레코드로 구글앱스와 연동이 되는 것이 선행되어 있어야 서브도메인과 연동이 가능 합니다.
http://www.starhost.co.kr/xe/control_manual/5371

00. 아래의 예제는 demo.starhost.co.kr 을 예제로 합니다.

01. 구글앱스 관리자로 로그인 합니다.(접속이 안된다면 01-2. 번으로 방법을 달리하여 접속을 시도하세요)
01-1. http://www.google.com/a/cpanel/domain/new?hl=ko 접속 후 만들어준 도메인 이름을 입력후 접속 합니다.

01-2. 위의 방법이 안되면, 아래의 링크에 접속 후 오른쪽의 "기존 사용자 로그인"을 클릭하여으로 도메인 관리를 선택후 로그인 합니다.
(이 때에는 구글앱스 생성시 관리자로 등록한 이메일과 비밀번호가 필요합니다)
http://www.google.com/a/

- 도메인 입력에 demo.starhost.co.kr
- 도메인 관리 선택 후 "이동" 클릭

02. 애플리케이션 로그인 정보가 뜨면, 관리자로 등록해준 "사용자 이름" 과 "비밀번호"를 입력 후 로그인 합니다.

03. 로그인된 화면에서 "이메일"을 클릭 합니다.

04. 상단에 있는 웹 주소 에서 URL 변경하기를 클릭 합니다.
(현재는 http://mail.google.com/demo.starhost.co.kr 처럼 긴 도메인 입니다.)

05. 두개의 선택 중 http://mail.demo.starhost.co.kr/ 을 선택 후 "계속"을 클릭 합니다.
(맞춤 URL을 사용하려면 도메인 호스트로 CNAME 레코드를 만들어야 합니다.)

06. 그림과 같이 CNAME 를 변경하라는 안내 메세지가 나옵니다.

07. 스타호스트 에서 제공하는 제어판(Siteowrx)에 본인의 계정으로 로그인 후 DNS Recored 에서 mail 관련 A 레코드를 삭제 합니다.
(mail의 A 레코드가 생성되어 있다면, mail.demo.starhost.co.kr 도메인을 접속하면 우리가 원하는 구글 이메일 접속 페이지가 아닌 자신의 홈페이지가 뜨게 되는 원인이 됩니다.)

07-1. 호스팅 관리-->DNS Records 를 클릭 합니다.

07-2. 반드시 하단에 있는 MX 레코드가 구글로 설정되어 있는지 확인 하시기 바랍니다.
(MX 레코드를 이용하는 방법으로 연동이 선행 되어 있다면, 작성되어 있을 것입니다. 만약 작성이 안되어 있다면, 본 사이트의 "제어판 메뉴얼" 에 있는 구글 앱스 사용하기(MX Record 설정) 을 참고 하시기 바랍니다.)

07-3. 다음의 그림에 있는것 처럼 호스트가 mail.demo.starhost.co.kr 이고, Type 가 A 레코드인 것을 왼쪽에 있는 "삭제" 를 클릭 하여 삭제 합니다.(이것을 삭제하지 않으면, mail.도메인 으로 접속시 구글앱스가 아닌 자신의 홈페이지로 접속이 되는 원인이 됩니다.)

08. DNS Records 설정에서 mail의 CNAME을 생성 합니다.
08-1. 상단의 Add an A, CNAME, or TXT Record 를 클릭 합니다.

08-2. 다음의 그림처럼 CNAME 을 생성 합니다.
Host: 에는 mail 을 작성 합니다. (캘린더의 경우엔 calendar 입력)
Type: 에는 CNAME 을 선택 합니다.
Target: 에는 구글에 나온 안내 처럼 ghs.google.com 을 입력 합니다.(사용자에 따라서 다를 수 있습니다.)

09. 완료가 되었다면 다음의 그림과 같이 CNAME 이 추가 됩니다.

10. 구글앱스 사이트로 돌아와 "다음 단계를 완료했습니다." 를 클릭 합니다.

11. 캘린더도 마찬가지고 CNAME 를 추가하여 사용하실 수 있습니다.

12. 수정이 완료된 후에는 구글에서는 1시간 정도 갱신의 시간이 걸립니다.

(상황에 따라서 본인이 접속하는 시간은 좀 더 길어질 수 있습니다.)

suPHP로 웹서버 보안을 강화하자

2010-02-19T01:55:16+09:00

작성자: 주인장 디지문
(http://www.digimoon.net/)

공식 사이트 : http://suphp.org

웹서버 보안을 위한 예방책으로 mod_suphp라는 아파치 웹서버 모듈을 소개하고자 합니다.
해외에서는 suPHP가 이미 널리 사용되고 있는 모양입니다. 그러나 국내엔 구글링 등을 통해 관련 한글문서를 검색해도 거의 자료가 나오지 않더군요. suPHP의 국내 확산을 위해 문서를 한 번 만들어 보았습니다.

suPHP란?

suPHP 는 일종의 PHP wrapper 기능과 Apache module (mod_suphp) 를 제공한다고 보면 된다.

각 사용자들의 cgi-bin 디렉토리에 PHP 바이너리를 넣지 않고도 PHP 스크립트를 실행할 수 있도록 하여주며 아파치의 suExec 를 필요로 하지도 않는다.

또한 로깅 기능도 제공하여 주고 있다.

▲ 원문출처: http://cafe.naver.com/ssyangcal/2151

사실 제 경우는 보안 문제를 떠나서 suPHP 도입이 상당히 끌리는 이유가 따로 있었으니 바로 웹호스팅 환경에서 계정별 디스크 quota 설정이 보다 더 용이해진다는 점이었습니다.
아파치 웹서버를 사용하는 경우 웹상에서 첨부파일 형식으로 업로드된 데이터의 경우는 해당 계정 소유권이 아닌 아파치 웹서버 소유권(nobody 또는 apache)으로 올라가기에 해당 계정의 홈디렉토리에서 아파치 소유권으로 올라가 있는 데이터는 nobody 또는 apache 계정의 쿼터 수치로 따로 계산되는 quota 설정의 맹점을 극복하기가 어려워질 수 밖에 없습니다.
그러나 suPHP를 도입하면 웹으로 데이터를 업로드한다 하더라도 아파치 웹서버 소유권이 아닌 해당 계정의 소유권으로만 올라가기에 정확한 쿼터 설정이 가능하게 됩니다.

이렇게 되면 또 하나 반가운 장점이 생기게 되는데 제로보드4, 그누보드, 텍스트큐브, XE 등과 같은 게시판 어플을 사용시 기존 아파치 소유권으로만 데이터가 들어가던 디렉토리와 파일을 FTP나 SSH 상에서 삭제할 수 없던 문제점도 해결된다는 겁니다.

위 2가지 장점만으로도 웹호스팅을 운영하고 있거나 운영을 계획하고 있던 분들께는 반가운 소식이 될 것으로 봅니다.

보안상 얻을 수 있는 장점으로는 shPHP 설정으로 디렉토리는 755, 파일은 644 이상의 퍼미션을 부여하지 않아도 정상적인 웹서비스가 가능해진다는 것입니다. other 퍼미션에 쓰기 권한을 주어야 설치가 가능했던 제로보드4, 그누보드 등을 비롯한 각종 어플리케이션을 설치할 때엔 707이나 777 퍼미션을 줄 필요 없이 그냥 설치를 진행하면 됩니다. 취약한 707, 777 퍼미션을 허용하지 않으니 웹크래킹 예방에 큰 도움이 될 수 있겠죠.

이렇게 보안과 기능상 이점을 두루 얻을 수 있는 suPHP를 CentOS 5.x 32bit에 도입해 보도록 하겠습니다.

APM 구성: Apache 2.0.63, PHP 5.2.10, MySQL 5.0.77, Zend Optimizer 3.3.3

suPHP 설치의 핵심은 php 설치 방식의 변화에 있습니다. 각종 문서에 두루 소개되어 있는 아파치 웹서버에 모듈형으로 연동하는 PHP엔 suPHP를 적용할 수 없습니다. PHP를 CGI 바이너리 형태로 설치해야 합니다.

▼ apache 컴파일 옵션 (prefork가 아닌 worker 방식으로 설치할 경우 suphp 작동 시 아파치 에러 로그에 child process 관련 에러를 내뿜는 경우가 있어 prefork로 설치할 것을 권장합니다)

[root@localhost ~]# ./configure --prefix=/usr/local/apache --enable-mods-shared=all --enable-ssl --with-mpm=prefork --enable-suexec --with-suexec --with-suexec-caller=nobody --with-suexec-docroot=/home --with-suexec-logfile=/usr/local/apache/logs/suexec.log --with-suexec-uidmin=500 --with-suexec-gidmin=500 --enable-cgid --enable-cache --enable-disk-cache --enable-mem-cache --enable-deflate

▼ php 컴파일 옵션

[root@localhost ~]# ./configure --prefix=/usr/local/php --enable-mod-charset --enable-safe-mode --enable-sigchild --enable-magic-quotes --with-libxml-dir --with-openssl --with-zlib --with-zlib-dir --with-bz2 --enable-calendar --with-curl --enable-dba --with-gdbm --enable-exif --enable-ftp --with-gd --with-jpeg-dir --with-png-dir --with-ttf --with-freetype-dir --enable-gd-native-ttf --with-gettext --with-imap --with-imap-ssl --with-kerberos --enable-mbstring --with-mhash --with-mcrypt --with-mysql=/usr/local/mysql --enable-sockets --with-regex=php --enable-sysvmsg --enable-sysvsem --enable-sysvshm --enable-wddx --enable-zend-multibyte --enable-force-cgi-redirect --enable-fastcgi

※ 여태 아파치에 DSO 방식으로 php를 연동해서 쓰던 옵션에서 다른 부분은 크게 손 볼 필요 없이 --with-apxs(아파치 2.x.x의 경우 --with-apxs2)만 제거하고 --enable-force-cgi-redirect --enable-fastcgi 옵션만 추가해 주면 무난하게 적용 가능할 것입니다.

APM 구성이 끝났으면 이제 mod_suphp 최신 소스를 배포 사이트에서 받아 설치합니다.
apr 패키지를 필요로 하므로 apr 관련 패키지를 먼저 설치합니다.

▼ apr 패키지 설치

[root@localhost ~]# yum -y install apr apr-devel

▼ suPHP 모듈 설치(DSO 방식으로 추가)

[root@localhost ~]# ./configure --sysconfdir=/usr/local/apache/conf --with-apr=/usr/bin/apr-1-config --with-apxs=/usr/local/apache/bin/apxs --with-apache-user=nobody --with-php=/usr/local/php/bin/php-cgi
[root@localhost ~]# make
[root@localhost ~]# make install

▼ 아파치 httpd.conf에 아래 설정 추가

LoadModule suphp_module modules/mod_suphp.so

▼ suphp.conf 파일 설정

[root@localhost ~]# cat /usr/local/apache/conf/suphp.conf

[global]
;Path to logfile
logfile=/usr/local/apache/logs/suphp.log

;Loglevel
loglevel=info

;User Apache is running as
webserver_user=nobody

;Path all scripts have to be in
docroot=/usr/local/apache/htdocs:${HOME}/www

;Path to chroot() to before executing script
;chroot=/mychroot

; Security options
allow_file_group_writeable=false
allow_file_others_writeable=false
allow_directory_group_writeable=false
allow_directory_others_writeable=false

;Check wheter script is within DOCUMENT_ROOT
check_vhost_docroot=true

;Send minor error messages to browser
errors_to_browser=false

;PATH environment variable
env_path=/bin:/usr/bin

;Umask to set, specify in octal notation
umask=022

; Minimum UID
min_uid=500

; Minimum GID
min_gid=500

[handlers]
;Handler for php-scripts
x-httpd-php="php:/usr/local/php/bin/php-cgi"

;Handler for CGI-scripts
x-suphp-cgi="execute:!self"
[root@localhost ~]#

▼ apache 가상호스트 설정(푸른색으로 추가한 부분)

<VirtualHost *:80>
DocumentRoot /home/aaa/www
ServerName www.aaa.com
ServerAlias aaa.com
<IfModule mod_suphp.c>
   suPHP_Engine On
   suPHP_UserGroup aaa aaa
   AddHandler x-httpd-php .html .htm .php .php3 .php4 .php5 .phtml .cgi .inc
   suPHP_AddHandler x-httpd-php .html .htm .php .php3 .php4 .php5 .phtml .cgi .inc
</IfModule>
</VirtualHost>

이제 제로보드나 그누보드 등을 설치해 보시기 바랍니다.
707, 777 퍼미션 변경을 어플리케이션에서 요구할 것이나 보안상 suPHP가 이를 막습니다. 퍼미션 변경 없이 그대로 진행 가능합니다.
그리고 게시판 상에서 파일을 첨부한 뒤 해당 파일이 업로드되어 있는 경로를 FTP나 SSH 쉘상에서 확인해 보면 종전까지는 nobody나 apache와 같은 웹서버 소유권으로만 올라가던 것이 이젠 해당 계정의 소유권으로 올라가 있는 것을 확인할 수 있을 것입니다.

이렇게 suPHP의 장점을 강조하며 포스팅을 해 보았으나 실제 테스트를 해 보니 이미 서비스 중인 웹서버에 도입하기에는 쉽지 않은 작업이 될 것으로 보입니다.
일단 제로보드4, 그누보드, XE, 텍스트큐브와 같은 각종 어플리케이션을 초기 설정값 그대로 사용하기에는 조금 어려운 점이 있을 수 있습니다. 설치 단계나 실 운영 중에 디렉토리나 파일 퍼미션을 707이나 777로 강제하는 소스가 있기 때문이죠. 제로보드4의 경우엔 기본 게시판 소스 뿐만 아니라 각종 플러그인, 스킨 게시판 소스 상에서의 적절한 수정 작업이 불가피했습니다.

일단 제로보드4의 경우 아래 소스는 필수적으로 수정해야 하는 것으로 테스트 결과 확인하였습니다.
bbs/lib.php 파일의 아래 부분 수정(994번째 줄 근처, 붉은색 부분처럼 수정)

// 파일을 삭제하는 함수
function z_unlink($filename) {
@chmod($filename,0755);
$handle = @unlink($filename);
if(@file_exists($filename)) {
@chmod($filename,0755);
$handle=@unlink($filename);
}
return $handle;
}

널리 사용되는 또다른 어플 중 하나인 XE(XpressEngine)의 경우는 게시판 설치 및 초기 운영 단계에서는 소스 수정이 필요 없었습니다.
어쨌든 여타 다른 어플리케이션의 경우 소스 수정이 불가피한 경우가 생긴다면 위에 소개한 제로보드4 소스 수정의 경우과 같이 게시물 작성 및 수정, 첨부파일 업로드 등에 관여하는 소스에서 퍼미션을 707 이상으로 강제하는 부분을 수정해야 하는 때일 것입니다.

그리고 또 하나 난관으로 작용하는 점이 있습니다. 아파치의 버추얼호스트 설정에서 root 소유권의 디렉토리 영역을 DocumentRoot 옵션으로 잡아 운영하고 있는 각종 소스에 대한 문제입니다. 주로 mrtg, webalizer, squirrelmail과 같은 웹브라우저를 통한 제어 및 열람을 지원하는 어플리케이션들이 이에 해당합니다.
suPHP는 보안상 UID/GID 500 이상의 시스템 계정 소유권에 한해서만 755, 644 퍼미션 이하의 디렉토리 및 파일의 웹접근을 허용하고자 하는 취지에서 고안되어 나온 모듈입니다. mrtg, webalizer 등의 문제까지 해결하고자 한다면 root를 비롯한 UID/GID 500 이하의 계정에도 suPHP를 통한 웹접근이 가능토록 suphp.conf 파일의 min_uid=500 , min_gid=500 옵션의 수치를 하향 조정하는 수 밖에 없게 되는데 이렇게 하면 보안으로서의 의미가 퇴색될 수 밖에 없습니다.
이를 극복하려면 cron을 이용하여 root로 생성되어 있는 파일을 주기적으로 특정 계정 소유권으로 강제 변환시키거나 suPHP를 적용하지 않는 Apache + PHP 세트를 하나 더 설치해서 운영하면 됩니다. 그리고 포트는 80번을 피한 다른 포트를 이용해야 하겠죠.

지금까지 suPHP 설치 방법과 장단점을 간략하게나마 열거해 보았습니다. 검색 사이트에서 수집되는 정보들만 확인한 바로는 국내엔 도입 사례가 많지 않은 것으로 보입니다. suPHP 환경에서 정상 작동하는 어플리케이션에 관한 정확한 정보 확산을 위해서는 suPHP 설치에 관한 자료가 먼저 확산되길 바라는 수 밖에 없겠습니다.

끝으로 본 문서를 작성하는데 큰 도움을 주신 스타호스트(http://starhost.co.kr) 운영자님께 깊은 감사의 뜻을 전합니다. 스타호스트님께서 suPHP 지원 어플리케이션 리스트를 계속 업데이트 중이시니 아래 URL 참고하시기 바랍니다.
http://www.starhost.co.kr/xe/hosting_tip/2898
http://demo.starhost.co.kr

.html 파일 에서 .php 코드를 인식하게 하는 방법

2010-02-09T15:58:19+09:00

.html 파일 에서 .php 코드를 인식하게 하는 방법 입니다.

1. 저희가 제공하는 제어판에 호스팅관리 --> Htaccess 를 클릭 합니다.
2. 디렉토리 옵션 관리에 전체 디렉토리 옵션에 "설치된 전체 .HTACCESS 가 없습니다." 라고 나온다면
추가를 클릭하여 만들어줍니다. 그 후 Enable 을 클릭하여 활성화 시켜줍니다.
3. 본인의 계정에 FTP로 접속 하시면 public_html 안에 .htaccess 파일이 있습니다.
파일을 보면 전부 주석 처리가 되어 있으실 텐데요..아무 위치에 다음과 같이 두줄을 추가 합니다.

AddType application/x-httpd-php .html
AddHandler x-httpd-php .html

4. 파일을 저장하실때 인코딩을 UTF-8 로 저장후 업로드 해줍니다.

간단한 테스트를 해보면 .html 파일도 .php 파일과 동일하게 인식이 됩니다.

* 될수 있으면 html 파일로 php 코딩을 하시는것 보다는 php코딩은 .php 파일로 하시는것이 좋습니다.

파일 구분도 되고, 나중에 예기치 않은 다른 문제가 생길수도 있으니까요..

참고
.htaccess 파일 쉽게 작성할 수 있도록 도와주는 곳
http://www.htaccesseditor.com/kr.shtml

top 명령어 및 옵션 정리와 설명

2010-02-08T06:25:31+09:00

top 명령 실행시 추가할 수 있는 옵션

    * (top) -d [sec]: 설정된 초단위로 Refresh
    * (top) -c      : command뒤에 인자값 표시

top 명령 실행 후 사용할 수 있는 옵션

    * shift + t     : 실행된 시간이 큰 순서로 정렬
    * shift + m     : 메모리 사용량이 큰 순서로 정렬
    * shift + p     : cpu 사용량이 큰 순서로 정렬
    * k             : Process 종료
          o k 입력 후 종료할 PID를 입력한다
          o signal을 입력하라 표시되면 9를 넣어준다
    * c             : 명령 인자 표시 / 비표시
    * l(소 문자엘)   : uptime line(첫번째 행)을 표시 / 비표시
    * space bar     : Refresh
    * u             : 입력한 유저 소유의 Process만 표시
          o which user: 와 같이 유저를 입력하라 표시될때 User를 입력
          o blank(공백) 입력시 모두 표시
    * shift + b     : 상단의 uptime 및 기타 정보값을 블락선택해 표시
    * f             : 화면에 표시될 프로세스 관련 항목 설정
    * o             : 화면에 표시될 프로세스 관련 항목들의 표시 순서를 변경
          o 변경 할 항목의 값을 대/소문자로 입력하면 항목의 위치가 이동됨

top 명령 실행 후 화면

top - 15:55:22 up 98 days, 14:29, 1 user, load average: 0.05, 0.04, 0.00
Tasks: 141 total,   1 running, 140 sleeping,   0 stopped,   0 zombie
Cpu(s): 0.2%us, 0.1%sy, 0.0%ni, 99.3%id, 0.4%wa, 0.0%hi, 0.0%si, 0.0%st
Mem:   4031448k total, 3306440k used,   725008k free,   263928k buffers
Swap: 8193140k total,     2900k used, 8190240k free, 1588424k cached

PID USER      PR NI VIRT RES SHR S %CPU %MEM    TIME+ COMMAND

각 행별 내용

    * top - 15:55:22 up 98 days, 14:29, 1 user, load average: 0.05, 0.04, 0.00

현재시간(15:55:22 ), uptime 값(up 98 day), 현재 로그인 된 사용자의 수(1 users), 시스템의 최근 1분, 5분, 15분에 대한 각각의 평균 부하율(load average: 0.03, 0.05, 0.05)
Load average: 작업의 대기시간. 값이 1이 나왔다면 1분 동안 평균 1개 정도의 프로세서가 대기상태에 있다는 것이다.
서버마다 차이가 있긴 하지만 5 정도면 서버가 부하를 받는 다고 생각한다. 과부하는 10 ~ 15이상이면 과부하라고 본다.

    * Tasks: 141 total,   1 running, 140 sleeping,   0 stopped,   0 zombie

전체 실행된 현재 프로세스의 수는 (141 total), 실행중인 프로세스 ( 1 running), 유휴상태의 프로세스(140 sleeping),
정지 된 프로세스( 0 stopped), 좀비 프로세스(0 zombie)

    * Cpu(s): 0.2%us, 0.1%sy, 0.0%ni, 99.3%id, 0.4%wa, 0.0%hi, 0.0%si, 0.0%st

사용자가 사용중인 CPU의 사용율(us), 시스템이 사용하는 CPU의 사용율(sy), NICE 정책에 의해 사용되는 CPU의 사용율(ni), 사용되지 않는 CPU의 미사용율(id), 입출력 대기상태의 사용율(wa)

    * Mem:   4031448k total, 3306440k used,   725008k free,   263928k buffers

전체 물리적인 메모리(total), 사용중인 메모리(used), 사용되지 않는 여유 메모리(free), 버퍼된 메모리(buffers)

    * Swap: 8193140k total,     2900k used, 8190240k free, 1588424k cached

전체 스왑 메모리(total), 사용중인 스왑 메모리(used), 남아있는 스왑메모리(free), 캐싱메모리(cached)

세부 정보 필드별 항목

PID USER      PR NI VIRT RES SHR S %CPU %MEM    TIME+ COMMAND

    * PID : 프로세스 ID (PID)
    * USER : 프로세스를 실행시킨 사용자 ID
    * PRI : 프로세스의 우선순위 (priority)
    * NI : NICE 값. 일의 nice value값이다. 마이너스를 가지는 nice value는 우선순위가 높음.
    * VIRT : 가상 메모리의 사용량(SWAP+RES)
    * RES : 현재 페이지가 상주하고 있는 크기(Resident Size)
    * SHR : 분할된 페이지, 프로세스에 의해 사용된 메모리를 나눈 메모리의 총합.
    * S : 프로세스의 상태 [ S(sleeping), R(running), W(swapped out process), Z(zombies) ]
    * %CPU : 프로세스가 사용하는 CPU의 사용율
    * %MEM : 프로세스가 사용하는 메모리의 사용율
    * COMMAND : 실행된 명령어

리눅스 명령어 필요없는 쉘 접속 끊기

2010-02-08T06:03:30+09:00

리눅스 명령어 필요없는 쉘 접속 끊기

보통 원격으로 서버를 관리 하다보면 필요없는 접속 을 죽일 필요가 생기는데 다음의 명령어로 해당 유저의 접속을 끊을 수 있습니다.

skill -KILL 로그인사용자이름

특정 터미널만 접속해제 해야 할 경우에는 다음과 같이 명령어로 접속을 끊을 수 있습니다.

skill -KILL -v pts/3

이라고 명령 을 내리면 pts/3 에 연결되어 있는 접속 이 끊어지게 됩니다.

제로보드XE - 1.4.0.x 에서 쉬운설치 사용시 정확한 FTP 정보 등록 하기

2010-02-06T00:07:17+09:00

* 현재 제로보드XE의 쉬운설치가 아주 안정적인 것은 아닙니다. 공식 사이트에서도 서버의 이용자 마다 오류가 있다는 글이 종종 올라오구 있구요.. 다행히 저희 서버에서는 FTP 설정만 잘 해주신다면 정상 설치가 가능하며 이용상에 아무런 불편이 없으십니다.

* 많은 분들이 제로보드XE 의 쉬운설치 이용시에 FTP 설정을 정확하게 하지 않으셔서 모듈 설치가 잘못 되어 이용하지 못하신 분들이 많을거라 생각하고 본 팁에서는 제로보드XE 상에서 쉬운설치를 원할하게 이용하실 수 있도록 FTP 설정방법에 대해 간략하게 설명해 드립니다.

* 가능한 제로보드XE-Core 업데이트는 파일을 직접 FTP로 업로드 해주어 업데이트를 해주는 것이 안전합니다.

* 본 예제는 제로보드XE 가 본인의 루트(http://도메인) 에 설치되어 있다고 가정하여 설명 합니다.

만약 제로보드XE 가 루트가 아닌 http://도메인/xe 에 설치되어 있다면 5번란에서 제로보드XE가 설치된 위치인 public_html 클릭후 xe를 클릭하여 제로보드xe가 설치된 폴더의 리스트를 확인합니다.

1. 본인의 제로보드XE에 관리자 권한으로 로그인 합니다.

2. 오른쪽 상단의 Settings 를 클릭하고 하단의 "FTP 계정정보 입력" 란으로 이동 합니다.

3. 아래의 그림과 같이 각 항목마다 빠짐없이 설정해 줍니다.

3-1. 아이디 : 저희가 계정을 발급해드린 정보를 참고로 하여 ftp@ 로 시작되는 FTP 계정명을 입력 합니다.
(저희가 제공해드리는 제어판(Siteworx)에서 FTP 계정명을 변경 하였다면 변경한 계정명으로 작성)

3-2. 비밀번호 : 발급해드린 정보를 참고로 하여 FTP 계정 비밀번호를 입력 합니다.

3-3. FTP 서버주소 : 127.0.0.1 을 입력합니다.

3-4. FTP Port : 21 을 입력 합니다.

3-5. 하단의 파란색의 "목록 가져오기" 를 클릭하여 줍니다.

4. 3-5에서 "목록 가져오기" 를 클릭해 주면 설치된 XE의 절대경로 에 폴더 리스트가 나타납니다. 여기서 public_html 을 클릭 합니다.

5. 4번 란에서 public_html 을 클릭하면 제로보드가 설치되어 있는 폴더의 리스트 들이 나타납니다.
(제로보드XE 의 설치가 루트(http://도메인) 이 아닌 http://도메인/xe 에 설치되어 있다면 public_html 클릭 후 xe 클릭을 한번 더 해줍니다.)

이 상태에서 오른쪽 하단의 "등록" 버튼을 클릭하여 FTP 등록을 완료 합니다.

간단한 DB 백업 강좌 // DB 백업 파일을 만들자!

2010-02-05T23:37:32+09:00

안녕하세요! 간단한 DB 백업 강좌 // DB 백업 파일을 만들자! 의 강의를 맞게된 령이입니다.

이번엔 백업 파일을 생성하는걸로 강의를 할 생각입니다. 사실 불러오는 것보다 일찍 했어야되는데, 저장하는 법을 모르시는 분들이 계셔서

올리겠습니다.

일단, SiteWorx 에 접속해서 ( 호스팅 관리 - Mysql - PhpMyAdmin ) 에 접속합니다.

그리고, DB 테이블이 있는 곳으로 갑니다. 우리의 목적은 이 테이블에 담긴 데이터를 저장하는 것입니다.

그리고 오른쪽을 주시하시면 "내보내기" 라는 메뉴가 보이실 겁니다. 그걸 클릭합니다...

그러면, 내보내기 메뉴의 내용이 나타납니다만, 위쪽 내용은 보실필요 없고 아래 쪽 내용에서 파일로 저장 이라는 곳의 박스를 체크하고,

압축을 하거나 안하거나는 여러분의 선택이며, 저는 압축을 하지 않고 저장하도록 설정을 맞추겠습니다. (사실상 DB의 용량은 많이 되지 않습니다.)

이제 뭐가남았을까요?? 그저 실행을 연타합니다!!

조금 기다리시면 저장 창이 뜨면서 바탕화면에 다운로드 받을 수 있습니다. 지금까지 수고하셨습니다.

부족한 강의를 봐주셔서 감사합니다 !! ^^

령이었습니다.

간단한 DB 백업 강좌 // 파일을 불러와 복구를 하자!

2010-02-05T23:18:55+09:00

안녕하세요!! DB 백업을 어려워 하시는 분들을 위해 간단한 강좌를 준비했습니다. 먼저 파일을 준비 했을때의 백업 할 때의 장면을

설명해 드릴려고 합니다.

일단 시작하기에 앞서, DB의 테이블을 모두 삭제했는지, 권한오류는 없는지, DB와 FTP의 정보가 맞는지 확인해 주세요.

령이는 둘다 한꺼번에 백업하여 같은 시점의 백업 자료를 불러오시는 것을 추천합니다.

본론으로 들어가 볼까요 ^^;;

일단, 제어판인 Siteworx 에 접속합니다.

그리고, 사이트의 접속하여 아래 경로로, (호스팅 관리 - Mysql - PhpMyAdmin) 클릭합니다.

그리고, DB를 눌러 테이블이 있는 곳으로 갑니다.

지금 이 화면에서, 오른쪽에 있는 화면을 주시하면, Imfort 라는 메뉴가 있는 것을 볼수가 있습니다. 클릭하세요.

자 이젠, 거의 다 끝났습니다. Imfort 메뉴로 들어가신 다음, 찾아보기를 클릭해서 저장했던 DB sql 파일을 불러옵니다.

그리고, 이젠 하나 뿐! 실행 버튼을 자신있게 꾹 눌러주면 끝입니다.

적용하면, Successfully 나, 그 비슷한 성공했던 단어가 나온다면 성공적으로 마친것입니다. 붉은색이라고 나온다면

DB를 비우지 않으셨거나 (테이블 삭제) 권한 오류가 있을 수 있습니다.

만약 오류가 나면 콜미~ 저를 불러주세요 ㅠ 부족한 실력이나마 힌트라도 생각해보겠습니다..

지금까지 간단한 DB 백업 강좌 // 파일로 백업을 하자! 의 령이였습니다~

Access Denied ... (유저명)@localhost < 오류 해결법 >

2010-02-05T17:11:01+09:00

안녕하세요! 많이들 궁금해하시는 오류 해결법! 여기서 보고 해결하시면 쉽습니다. 일단 Access Denied ... (유저명)@localhost 오류!

그 오류는.. XE 설치 과정 중 나타납니다. 다 썼는데 이게 나온다! 정말 짜증나지 않을 수 없습니다.

이 오류를 해결하기 위해 지우고 다시 까셔도 소용이 없을 것입니다. 그럴 땐, Starhost (관리자) 분께서 제공해주신 제어판에서 해결할 수

있습니다.

일단 제어판으로 들어갑니다. 로그인을 하신 후, 호스팅 관리 - Mysql - 유저에 들어갑니다. 그러면 이 장면을 보실 텐데,

이 장면에서 저는 소유 권한이 저렇게 되어있는데, 오류가 나신 분들은 None 이라고 되어져 있을겁니다. 이 때 오류 해결법을 해결해 봅시다.

일단, Mysql의 데이터베이스 메뉴에 들어갑니다. 그리고 메뉴 없에 Action 이라고 되어있는 곳에 사용자 관리로 들어가면 이 장면이 나옵니다.

물론 지금 회원분들께서는 데이터 베이스 유저 권한이 비어있는 상태로, 아래로는 보이지 않으나, 데이터베이스 유저 권한 위의

추가 버튼만 눌러주시면 !! 간단하고도 엄청난 오류 해결이 끝납니다. 이제 설치과정으로 XE를 설치하시면 됩니다.

오류 해결하셔서 축하드립니다!

도메인 네임 서비스

2010-02-04T19:05:32+09:00

DNS(Domain Name System)의 구성 요소

DNS의 구성은 크게 다음과 같이 5가지로 이루어진다.

① 호스트에 대한 계층적 네임 공간(namespace) 정의

② 분산 데이터베이스로서 구현된 호스트 테이블을 정의

③ 이 데이터베이스를 질의하기 위한 라이브러리 루틴

(BIND의 일부) 정의

④ 전자우편을 위한 개선된 라우팅 정의

⑤ naming 정보 교환을 위한 프로토콜을 정의

위의 내용들을 지금부터 하나하나 자세히 설명하겠다.

DNS 네임공간(Namespace)

인터넷에는 셀 수 없이 많은 컴퓨터들이 네트워크를 통해 연결되어 있다.

이렇게 많은 컴퓨터에 사람이 알기 쉽도록 이름을 붙인다고 생각해 보자.

무작위로 붙이면 어떨까? 그러면 아마도 원래의 목적에 부합되게, 즉 사람이

알기 쉽게 이름을 붙이는데도 실패할 것이고 또한 중복된 이름이 많이 생기게

될 것이다. 그래서 나온 방안이 이름을 계층적으로 부여하는 방법이다.

이 방법이 바로 도메인 네임 시스템(Domain Name System-DNS) 이다.

그러므로 DNS는 하나의 커다란 트리구조로 생각할 수 있는데 트리의 루트는

‘ . ’ 이고 그 밑은 최상위 단계 도메인(top level domain)이다.

이 최상위 단계 도메인은 역사적인 이유로 2개의 최상위 단계 도메인 그룹이

존재한다. 최초 인터넷의 전신인 ARPANET이 미국에서 시작하였기에 당시 부

여한 도메인 이름은 후에 인터넷으로 발전한 후에도 그대로 사용할 수밖에 없

어 이렇게 2개 그룹이 공존하게 된 것이다.

미국에서는 com, edu, gov, mil, net, org, int, arpa 등이고 미국 밖에서는 2문

자의 ISO 국가 코드를 사용한다(au, jp, kr, ca, dk, de, fi, fr, se, hk, ch 등).

하지만 근래 들어서는 gov, mil을 제외한 다른 도메인 명은 다른 나라에서도

많이 사용하고 있다.

---------------------------------------------------------------

최상위 단계 도메인 이름 의 미

---------------------------------------------------------------

com 미국내의 회사와 같은 상업적인 기관

edu 미국내의 교육기관

gov 미국내의 정부기관

mil 미국내의 군대 관련 기관

net 게이트웨이와 다른 관리 호스트에 대한 이름

org 이외의 기타 조직 기관

kr 한국

au 호주

ca 캐나다

ae 아랍 에미레이트 연합

zw 짐바브웨

---------------------------------------------------------------

미국 이외의 지역에서 쓰이는 국가코드 부여시 기관에 대한 구분은 다시

ac(academy), co(Commercial), re(Resea rch) 등의 이름을 그 이름 앞에 부여

함으로써 이루어진다. 이것이 두 번째 단계 도메인(Second level domain)이다.

‘www.lg.co.kr’이나 ‘www.inha.ac.kr’ 등의 인터넷 사이트 명을 생각하면

될 것이다.

또한 도메인 이름은 대소문자를 구분하지 않는다(case insensitive).

두 번째 단계 도메인들은 국외의 경우는 NIC(Network Info Center)에 의해 유

지되며 국내의 경우는 KRNIC(Korea Network Information Center)에서 담당한

다.

이러한 두 번째 단계 도메인 이름을 할당받기 위해서는 다음과 같은 일을 수행

해야 한다.

1. 도메인 이름 정하기

RFC1032에서는 두 번째 단계 도메인을 12자나 그 이하로 할 것을 추천하고

있다. 실제로는 64자까지 가능하다.

2. 두 번째 단계 도메인 이름 등록하기

미국의 경우는 Registration Services group of NIC에 신청하는데 신청 양식은

rs.internic.net에서 ftp로 구할 수 있다. 이 양식은 domain-template.txt라고 불

리고 template 디렉터리에 있다.

유럽의 경우는 RIPE(mcsun.eu.net)에 신청한다.

만약 인터넷에 처음 접속시키는 경우는 IP 주소도 함께 신청해야 한다.

양식은 internet-number-template.txt에 있다.

3. 자신의 하위(Sub) 도메인 만들기

우선 자신의 지역 네트워크에서 고유한 이름을 선택하고 새 도메인에 서버가

될 2개 이상의 호스트를 결정한다. 그리고 상위 도메인의 관리자와 협조한다.

BIND의 구성요소

앞서 설명했듯이 주소의 매핑을 해주고 질의에 응답하는 프로세스를 운영하는

호스트를 네임서버라 할 수 있고 이를 이용하는(질의하는) 호스트를 리솔버

(resolver)라 한다고 하였다.

이러한 네임서버와 리솔버가 구현된 일반적인 예가 BIND(Berkeley Internet

Name Domain Server)라고 했는데 이 BIND의 구성요소는 다음과 같다.

(1) 질의에 대답하는 named 데몬

(2) DNS를 이용하는 호스트 질의를 풀어주는 라이브러리 루틴

(3) DNS로의 명령어 라인 인터프리터(nslookup, dig, host명령)

1. named : BIND 네임 서버

named는 호스트이름과 IP 주소에 대한 질의에 대답한다. 만약 대답하지 못하

는 경우는 다른 서버에 물어보고 결과를 캐시한다.

named는 또한 zone transfer(도메인 서버사이의 데이터 복사) 수행을 책임진

다.

네임 서버는 3가지 종류로 동작한다. 여기서 종류는 데이터가 어디서 오는가와

서버가 도메인을 관리하는가로 구분한다.

각 도메인이나 서브도메인에 대해 하나의 주(primary) 네임 서버가 존재한다.

주(Primary) 서버는 디스크에 도메인 데이터의 마스터 복사본을 유지한다.

부(Secondary) 서버는 주(Primary) 서버로부터 zone transfer 동작을 통해 도

메인 데이터를 복사한다.

캐시전용(Caching-only) 네임 서버는 스타트업 파일로부터 몇 개의 중요한 시

스템의 주소를 로드하고 이곳에서 대답하는 질의의 응답을 캐싱해서 다른 나머

지 데이터를 얻는다.

2. 리솔버(Resolver) 라이브러리

DNS를 이용하기 전의 호스트 이름 매핑은 ‘/etc/hosts’에서 gethostbyname,

gethostbyaddr 라이브러리 루틴들에 의해 이루어진다.

이 정보가 DNS에 의해 제공되어지게 하기 위해서는 이 루틴들이 변경되어야

한다.

3. 셸 인터페이스

nslookup 명령어는 셸에서 DNS로 접근 가능하게 한다. 이외에도 dig같은 명령

어도 있는데 뒤에 자세히 설명하기로 하겠다.

DNS의 동작 원리

프로그램은 gethostbyname 루틴으로 호스트 이름을 IP 주소로 매핑한다. 호스

트가 DNS를 사용하도록 조정되어 있으면 gethostbyname은 DNS 리솔버를 이

용해 주소에 대한 네임 서버에게 질의 응답한다.

네임 서버는 재귀(recursive)나 비재귀(non-recursive) 두 가지 성격의 서버로

구분된다.

비재귀 서버는 게으른 서버인데 이유인즉 질의의 답을 모르면 알만한 다른 서

버로 질의를 보내라고만 응답하기 때문이다. 즉 모르면 자기는 책임지지 않는

다는 얘기다. 그러므로 클라이언트 쪽이 이러한 반응에 대해 받을 준비가 되어

있어야한다.

재귀 서버는 오직 실제 답과 에러 메시지만을 리턴한다(모르겠다고 안함). 기본

질의 응답 프로시저는 동일하다.

두 서버의 차이는 바로 주소를 모르는 경우 질의 응답의 책임을 자기가 지느냐

그렇지 않느냐에 따라 나타난다.

재귀 네임 서버의 부작용은 캐시가 중간 도메인의 정보를 가져야 한다는 점이

다.

이러한 점은 지역적인 네트워크에서는 별 문제가 없으나 com과 같은 상위의

도메인에서는 그 성능이 감소된다는데 문제가 있다.

이런 이유로 일반적으로 하위 레벨의 도메인에서는 재귀 네임 서버를 설치하고

상위 레벨의 도메인에서는 비재귀 네임 서버를 설치한다.

실제 대부분의 유닉스 리솔버 라이브러리는 자신의 네임 서버가 재귀 서버라고

가정한다.

자 실제의 예를 들어보기로 하자.

(예) lair.cs.colorado.edu 시스템에서 mammoth.cs.berkeley.edu 시스템의 주소를

찾는 경우이다.

우선 lair.cs.colorado.edu는 자신의 지역 네트워크 네임 서버인

ns.cs.colorado.edu에게 mammoth.cs.berkeley.edu의 주소를 묻는다.

ns.cs.colorado.edu가 재귀 네임 서버이므로 일단 cs.berkeley나 berkeley에 대해

서는 그 주소를 자기가 담당하지 않더라도 질의에 응답하기 위해 EDU에게 물

어본다.

EDU는 비재귀 네임 서버이므로 ns.cs.colorado.edu에게 berkeley.edu으로 가서

물어보라고 한다.

ns.cs.colorado.edu는 이를 수신하고 나서 다시 berkeley.edu에게 질의를 한다.

berkeley.edu도 주소를 모르지만 재귀 네임 서버이므로 질의를 cs.berkeley.edu

에게 보낸다.

cs.berkeley.edu는 mammoth.cs.berkeley.edu의 주소를 관리하는 네임 서버이므

로 질의의 응답으로 그 주소를 ns.cs.colorado.edu에게 돌려준다.

이와 같은 진행 과정을 거쳐 원하는 주소를 얻게 된다. 우리가 넷스케이프와

같은 웹 브라우저에서 주소를 입력했을 때 화면 하단에 ‘…lookup…’과 같은

메시지를 볼 수 있는데 이 상태가 바로 위에서 설명한 상위 도메인으로의 질의

과정이 되는 것이다.

이러한 질의 과정이 끝나면 그 결과로 ns.cs.colorado.edu는 mammoth의 주소

와 berkeley.edu의 주소를 캐시한다. 또한 berkeley.edu의 서버 또한 mammoth

의 주소를 캐시하게 되어 다시 같은 질의를 받으면 바로 응답하게 된다.

named 질의는 UDP 프로토콜과 포트 53을 사용하여 이루어지는데 응답 메시

지가 512 바이트가 넘는 경우는 TCP를 경유하게 된다.

참고로 zone transfer 동작도 TCP를 이용한다.

BIND 클라이언트에서의 고려 사항

다음 표는 BIND 사용에서의 고려할 사항을 나타낸 것이다.

---------------------------------------------------------------

기 능 대 상 비 고

---------------------------------------------------------------

도메인 네임 얻기 사이트 한 번

네임 서버 선택하기 사이트 한 번 이상

BIND distribution 얻기 사이트 한 번

리솔버 컨피그 하기 클라이언트 한 번 하고 분배

효율적인 리솔버 컨피그하기 클라이언트 각 서브넷에 대해하고 분배

부트시 named 구동하기 서버 각 네임 서버

부트 파일 컨피그 하기 서버 각 서버의 타입

캐시 파일 컨피그 하기 서버 한 번하고 분배

zone 파일 컨피그 주 네임 서버 한 번

zone 파일 업데이트하기 주 네임 서버 필요할 때마다

로그 파일 확인하기 로그 호스트 한 주에 최소 한 번

사용자 교육하기 모든 호스트 영원히

---------------------------------------------------------------

BIND를 사용하는 모든 호스트는 클라이언트이므로 지금부터는 클라이언트쪽

의 고려 사항을 이야기하겠다.

1. 리솔버 컨피그 하기

각 BIND 클라이언트는 ‘/etc/resolv.conf’ 파일을 가져야 한다. 이 파일에는

주소를 모르는 경우에 질의를 할 네임 서버의 리스트를 가진다.

형식은 다음과 같다.

; 주석

search <도메인명>

nameserver <IP주소>

주석은 반드시 첫 열에서 시작해야만 한다.

네임서버는 한 개에서 3개까지 나열할 수 있다. 실제 파일 내용을 예로 들면

다음과 같을 것이다.

search inha.ac.kr

; ns, guyber, huclons

nameserver 165.246.10.2

nameserver 165.246.10.3

▶ search 지시자는 도메인 이름이 생략된 경우 완전한 도메인 이름으로 만들

어 주기 위해 사용되는데 최대 6개의 이름이 올 수 있다.

▶ namesever 지시자는 최대 3개까지 올 수 있는데 말 그대로 네임 서버의 주

소를 등록한다.

첫 번째 등록된 네임 서버에게 먼저 질의한 후 응답이 없으면 그 다음 네임 서

버로 질의하게 된다.

만약 호스트 자체가 네임 서버인 경우는 제일 처음에 등록되어야 하며 주의할

점은 루프백 주소(127.0.0.0)를 사용하지 말고 실제 IP 주소를 사용해야 한다는

점이다. 약간의 버그 때문이라고 한다.

참고로 BIND 초기 버전에서는 search 지시자 대신 domain 지시자를 사용하기

도 한다. 하지만 RFC 1535에서는 search의 사용을 강력히 추천하고 있다.

2. 리솔버 테스팅하기

어떤 시스템에서는 DNS를 사용하기 위해서는 단지 ‘/etc/resolv.conf’ 파일

에 네임 서버만 등록해 주면 되는 것도 있는 반면 시스템에 따라서는

‘/etc/hosts’ 나 NIS 대신 DNS를 사용할 것을 시스템에 명시 해 주어야 하

는 것도 있다.

후자의 경우는 해당 매뉴얼을 참조해야 할 것이다.

‘/etc/resolv.conf’를 컨피그한 후 nslookup이나 dig 명령어를 사용하여 제대

로 DNS를 사용하는지 테스트한다.

dig(Domain Infomation Groper)는 nslookup 명령어보다 자세한 정보를 보여준

다.

그리고 나서 다시 telnet, rlogin, finger, talk 등의 명령어를 써서 테스트한다.

who 명령어를 이용해 IP 주소가 아닌 완전한 도메인 명이 나오는지 확인할 수

도 있다.

3. DNS로 전환 후

정적인 hosts 테이블에서 DNS로 전환한 후에 다른 시스템에 영향을 미치는

부분이 생기게 된다.

우선 부팅시 네트워크가 설정되기도 전에 ‘/etc/rc*’ 의 호스트명의 참조가

행해지는 경우는 당연히 그 호스트명을 알 수 없기에 결국 호스트명을 얻는데

실패할 수가 있다.

이러한 경우 부트 과정 초기에 호스트의 IP주소를 명기해 주는 방법이 있을 수

있고 이 외에 만약 시스템이 ‘/etc/hosts’ 와 DNS를 동시에 지원한다면 부

트시 필요한 서버 주소를 포함하는 ‘hosts’ 파일을 설치해주면 된다.

또 영향을 받는 부분으로는 이전에는 호스트명을 제대로 다 쓰지 않아도 되었

던 부분이 완전한 도메인 명을 써주어야 하는 경우가 생기는데 바로

‘/etc/exports’ 파일과 sendmail 프로세스의 참조에 관한 부분이다. 이 두 부

분에 관련된 도메인 명에는 모두 완전한 이름으로 명시하면 된다.

네임 서버 설치하기

1. named 데몬 설치

named 데몬이 부트될 때 수행되도록 스타트업 스크립트에 다음과 같은 형태로

스크립트를 추가한다.

(예) "/etc/rc.local" 에

if [ -x /usr/etc/in.named -a -r /etc/named.boot] ; then

/usr/etc/in.named ; echo -n ' named' > /dev/console

named 데몬은 구동되면서 ‘/etc/named.pid’ 파일에 자신의 프로세스 ID를

기록한다(BSDI에서는 ‘/var/run/ named.pid’).

만약 named 데몬에 시그널을 보내려면 위의 파일을 이용해 다음과 같이 명령

을 주면 된다.

kill -시그널번호 `cat /etc/named.pid`

참고로 IRIX에서는 이 파일이 없으므로 ‘killall -시그널번호 named’ 하면

된다.

named 데몬은 로그 파일 생성을 위해 syslog를 사용하므로 named 데몬을 구

동시키기 전에 먼저 syslogd 데몬을 구동시켜야 함을 명심하자.

만약 inetd 데몬을 이용해 named 데몬을 관리한다면 캐시 정보를 제대로 활용

하지 못하게 되므로(자꾸 캐시가 지워진다) 되도록 inetd 데몬을 이용해 named

데몬을 관리하는 일은 피하도록 하자.

2. ‘/etc/named.boot’ 파일

‘named.boot’ 파일은 각 zone(하나의 네임 서버가 관리하는 네트워크 공간)

에 대한 호스트의 역할과 DNS 데이터베이스를 복사하는 방법 등을 지정한다

(‘;’는 주석을 의미).

파일의 형식은 다음과 같다.

directory 디렉토리명

cache . 파일명

primary 존(zone) 파일명

secondary 존(zone) IP 주소 [....] 파일명

▶ directory 지시자 : 다음 라인부터 사용되는 파일명들의 상대적 경로를 지정

한다.

▶ cache 지시자 : 루트 네임 서버의 이름과 IP주소를 포함하는 파일을 지정한

다. 일반적으로 ‘/etc/named.ca’ 파일로 지정하나 많은 사이트들이 ‘/va

r’ 디렉터리로 옮겨 사용한다.

▶ primary 지시자 : 지정된 존(zone)에 대해 호스트가 주(Primary) 혹은 부

(Secondary) 서버임을 지정하고 존에 대한 데이터 파일이 있는 위치를 지

정한다.

▶ secondary 지시자 : 주(Primary) 서버의 IP 주소와 그 데이터를 복사해 캐

시할 데이터 파일을 지정한다.

하나의 네임 서버가 여러 개의 다른 존에 대한 서비스를 제공할 수 있다. 즉

named.boot 파일에 여러 개의 primary, secondary 지시자가 쓰일 수도 있다는

말이다.

이 외에 ‘named.boot’ 파일은 domain 지시자도 가질 수 있는데 이 지시자는

도메인 명이 완전히 쓰이지 않은 경우 이를 완전히 만들어 줄 때 추가되는 도

메인 명을 지정한다.

forwarders 지시자는 해당 네임 서버가 질의에 응답을 못하는 경우 그 질의를

보낼 다른 호스트를 지정한다. 여러 개도 지정 가능하다.

BIND 4.9에서는 컴파일 옵션으로 여러 다중 네트워크 클래스를 지원 가능하게

하고 있다. 또한 zone transfer가 불가능한 사이트를 지정할 수도 있다.

bogus 지시자는 특정의 네임 서버의 질의에는 응답을 거부하는 것을 지정한다.

xfrnets 지시자는 해당 서버의 데이터베이스를 복사 가능한 호스트들과 네트워

크 리스트를 지정한다.

사이트가 많은 도메인에 대한 부(Secondary) 서버인 경우는 관리의 편이를 위

해 include 지시자를 사용할 수도 있다.

sortlist란 예약어는 극히 사용할 일이 없지만 설명하자면 하나의 시스템이 여

러 개의 네트워크 카드를 끼울 수 있는 multiple network interface를 지원하는

경우의 질의에 대한 우선 순위를 지정하는 것이다.

테스팅과 디버깅

DNS 테스팅과 디버깅은 크게 named 데몬을 통한 것과 인터페이스 명령을 통

한 것으로 나뉜다.

1. named 데몬을 통한 디버깅

named 데몬은 에러나 이상 유무의 리포트에 syslog 체계를 이용한다.

---------------------------------------------------------------

단 계 원 인

---------------------------------------------------------------

crit 시리얼 번호가 일정하게 증가하지 않음

네임 서버 파일에 대한 접근 허가 문제

err malloc, open, close 등의 많은 시스템 에러

다음과 같은 데이터베이스 컨피그 에러

1. 2개의 root hints

(루트 네임서버의 이름과 주소)보다 더 적다

2. 도메인 이름이 너무 길다.

3. 알려지지 않은 리소스 레코드 타입

4. SOA 레코드가 없음

5. SOA 레코드가 중복

6. 알려지지 않은 지시자

7. CNAME 이 다른 데이터를 가짐

warning 또다른 데이터베이스 컨피그 에러

1. HINFO CPU 타입이 너무 길다(255자 이상).

2. HINFO OS 타입이 너무 길다(255자 이상).

3. TXT 레코드가 255자에서 잘림

notice 특정 서버로의 잘못된 전송

자기 자신에게로의 질의 시도

최대 질의수를 초과

서버를 다시 로딩

info 제 형태가 아닌 응답

---------------------------------------------------------------

위의 표는 named 데몬으로부터 생기는 syslog 메시지이다.

named 데몬의 디버그 단계는 0부터 11까지이다.

숫자가 클수록 정보가 자세하게 되는데 이는 d 플래그로 지정한다.

(예) named -d2

디버깅 정보는 ‘/var/tmp/named.run’ 파일에 기록된다. 또한 named 데몬은

USR1 시그널을 받으면 디버그 단계를 1만큼 올린다.

파일을 생성하는 시그널을 받으면 보통 ‘/var/tmp’ 나 ‘/usr/tmp’ 디렉터

리에 생성한다. USR2 시그널은 디버그 모드를 끈다. 만약 시그널 이름사용이

안된다면 ‘/usr/ include/signal.h’ 파일을 참조하면 된다.

INT 시그널은 ‘named_dump.db’ 파일로 데이터베이스를 덤프한다.

다음은 named 데몬이 이해하는 시그널들이다.

---------------------------------------------------------------

시그널 기 능

---------------------------------------------------------------

USR1 디버그 레벨을 1만큼 높임

USR2 디버깅을 해제

INT named_dump.db에 데이터베이스를 덤프

IOT/ABRT named.stats에 상태를 덤프

HUP 부트 파일과 데이터 파일들을 다시 로드

KILL named를 죽임

WINCH 들어오는 질의의 추적을 토글(BIND 4.9)

---------------------------------------------------------------

2. nslookup과 dig를 통한 디버깅

dig 명령을 이용해 eslab의 mx 레코드를 보고 싶다면

(예) dig eslab.inha.ac.kr. mx

---------------------------------------------------------------

명령어 기 능

---------------------------------------------------------------

help 전체 명령어 리스트를 보여준다.

exit 종료

server 호스트 현재 서버를 이용해 디폴트 서버를 세팅한다.

lserver 호스트 초기 서버를 이용해 디폴트 서버를 세팅한다.

set type=xxx 질의 타입을 지정한다.

set debug 디버깅 모드를 끈다.

set d2 디버깅을 수행한다.

ls 도메인 모든 호스트/주소 매핑을 보여준다.

---------------------------------------------------------------

이번에는 inha.ac.kr로부터 모든 레코드를 보려는 경우는

(예) dig @inha.ac.kr eslab.inha.ac.kr. any

위의 표는 nslookup의 명령들을 나타낸 것이다.

여러 OS에서의 차이점

1. 솔라리스

솔라리스는 BIND 4.8.3에 기반을 둔다.

솔라리스에서는 ‘/etc/nsswitch.conf’ 파일을 통해 BIND, NIS, NIS+ 와

‘/etc/hosts’ 파일과의 상호 작용을 지정한다.

파일에 ‘host : dns files’ 라고 지정하면 먼저 DNS를 참조한 후

‘/etc/hosts’파일을 참조한다.

SUN에서는 NIS+ 다음에 DNS를 참조할 것을 권장하고 있다.

다음은 파일명과 그 위치를 나타낸 것이다.

---------------------------------------------------------------

파 일 디렉토리 설 명

---------------------------------------------------------------

resolv.conf /etc Resolver 라이브러리 설정

in.named /etc 네임 서버 데몬

named-xfer /usr/sbin zone transfer 코드

named.boot /etc 네임 서버를 위한 부트 파일

named.pid /etc 프로세스 ID

named.run /var/tmp 디버그 모드에서의 출력

named.stats /var/tmp 상태정보 출력

named_dump.db /var/tmp 전체 데이터베이스 덤프

---------------------------------------------------------------

2. HP

HP 또한 BIND 4.8.3에 기반을 둔다.

HP는 참조 순서가 무조건 DNS, NIS, ‘/etc/hosts’ 파일 순이다.

특징적인 것은 관련 명령들이 추가적으로 있다는 것인데 host_to_named 명령

어는 ‘/etc/hosts’ 파일 형식의 데이터를 DNS의 리소스 레코드 형태로 변환

해 준다.

또한 sig_named 명령은 named 데몬에게 시그널을 전달하는 명령이다.

convert_rhosts 명령은 ‘/etc/newconfig/bind’ 디렉터리에 있는데 ‘.rhosts’

파일의 도메인 명을 완전한 도메인 명으로 변환해 주는 스크립트 파일이다. 한

번 훑어보면 도움이 될 것이다.

다음 표는 HP에서의 파일명과 그 위치이다.

---------------------------------------------------------------

파 일 디렉토리 설 명

---------------------------------------------------------------

resolv.conf /etc Resolver 라이브러리 설정

in.named /etc 네임 서버 데몬

named-xfer /etc zone transfer 코드

named.boot /etc 네임 서버를 위한 부트 파일

named.pid /etc 프로세스 ID

named.run /usr/tmp 디버그 모드에서의 출력

named.stats /usr/tmp 상태정보 출력

named_dump.db /usr/tmp 전체 데이터베이스 덤프

Zone 파일 /etc/newconfig/bind zond 파일의 디폴트 위치

---------------------------------------------------------------

3. IRIX

IRIX도 역시 BIND 4.8.3에 기반을 둔다.

‘/etc/config’ 파일에서 어떤 서비스가 컨피그 되었는지 가리킨다.

이 파일은 chkconfig 명령이나 텍스트 에디터로 수정될 수 있다.

서비스 참조 순서는 ‘/etc/resolv.conf’의 hostresorder 지시자로 지정한다. 만

약 ‘hostresorder bind local’ 과 같은 내용이 있다면 이는 DNS를 먼저 참조

한 후 ‘/etc/hosts’ 파일을 참조하라는 의미이다. 물론 여기서 NIS의 추가도

가능하다.

named.reload 명령은 named 데몬에게 hangup 시그널을 보내는 일을 한다.

named.restart 명령은 named 데몬을 죽이고 난 후 다시 시작시키기 때문에 캐

시가 청소되는 차이가 있다.

다음은 관련 파일과 그 위치이다.

---------------------------------------------------------------

파 일 디렉토리 설 명

---------------------------------------------------------------

resolv.conf /usr/etc Resolver 라이브러리 설정

in.named /usr/etc 네임 서버 데몬

named-xfer /usr/etc zone transfer 코드

named.boot /usr/etc/named.d 네임 서버를 위한 부트 파일

named.run /usr/tmp 디버그 모드에서의 출력

named.stats /usr/tmp 상태정보 출력

named_dump.db /usr/tmp 전체 데이터베이스 덤프

Zone 파일 /usr/etc/named.d zond 파일의 디폴트 위치

---------------------------------------------------------------

4. SunOS

SunOS는 리솔버가 NIS의 ypserv 데몬의 일부이다.

다시 말하면 NIS를 수행 안하면 DNS 서비스도 사용 못함을 의미한다.

BIND는 4.8.1을 기반으로 한다.

다음은 관련 파일들과 그 위치이다.

---------------------------------------------------------------

파 일 디렉토리 설 명

--------------------------------------------------------------

resolv.conf /etc Resolver 라이브러리 설정

in.named /usr/etc 네임 서버 데몬

named-xfer /usr/etc zone transfer 코드

named.boot /etc 네임 서버를 위한 부트 파일

named.pid /etc 프로세스 ID

named.run /var/tmp 디버그 모드에서의 출력

named.stats /var/tmp 상태정보 출력

named_dump.db /var/tmp 전체 데이터베이스 덤프

Zone 파일 /etc/named.* zond 파일의 디폴트 위치

---------------------------------------------------------------

5. OSF/1

OSF/1은 BIND 4.8.3을 기반으로 한다.

‘/etc/svc.conf’ 파일에서 서비스 참조 순위를 지정하는데 예를 들면

‘hosts=local, bind’ 라는 내용이 있으면 ‘/etc/ hosts’ 파일을 참조한 후

DNS를 참조함을 의미한다.

‘/etc/svc.conf’파일을 수정하려면 ‘/usr/sbin/svc setcup’ 스크립트를 사용

한다.

다음은 BIND 관련 파일과 그 위치이다.

---------------------------------------------------------------

파 일 디렉토리 설 명

---------------------------------------------------------------

resolv.conf /etc Resolver 라이브러리 설정

in.named /usr/sbin 네임 서버 데몬

named-xfer /usr/sbin zone transfer 코드

named.boot /etc/namedb 네임 서버를 위한 부트 파일

named.pid /var/run 프로세스 ID

named.run /var/tmp 디버그 모드에서의 출력

named.stats /var/tmp 상태정보 출력

named_dump.db /var/tmp 전체 데이터베이스 덤프

Zone 파일 /usr/local/domain zond 파일의 디폴트 위치

---------------------------------------------------------------

6. BSDI

BSDI는 BIND 4.9에 기반을 두면 무조건 DNS 다음에 ‘/etc/hosts’ 파일을

참조한다.

다음은 관련 파일과 그 위치이다.

---------------------------------------------------------------

파 일 디렉토리 설 명

---------------------------------------------------------------

resolv.conf /etc Resolver 라이브러리 설정

in.named /usr/sbin 네임 서버 데몬

named-xfer /usr/libexec zone transfer 코드

named.boot /etc 네임 서버를 위한 부트 파일

named.pid /var/run 프로세스 ID

named.run /var/tmp 디버그 모드에서의 출력

named.stats /var/tmp 상태정보 출력

named_dump.db /var/tmp 전체 데이터베이스 덤프

Zone 파일 /etc/namedb zond 파일의 디폴트 위치

---------------------------------------------------------------

TCP // IP 강좌 2

2010-02-04T17:23:29+09:00

4. ICMP Redirects

어떤 문제가 발생했을 때 송신자에게 알려주는 것이 ICMP redirect 패킷이다.

ICMP redirect 패킷을 받은 호스트는 라우팅 테이블을 갱신한다.

5. Subnetting

주소의 호스트 부분의 일부를 네트워크 부분으로 확장되도록 비트를 빌려주는

것을 서브넷이라 한다.

예를 들면 B 클래스의 4바이트 주소는 N.N.H.H로 해석되는데 만약 subnetting

이 3 바이트를 네트워크 넘버에 할당되면 주소는 N.N.N.H로 해석된다. 결국

하나의 B 클래스 네트워크 주소가 254개의 C 클래스와 유사한 네트워크로 바

뀐다.

바이트 경계로 네트워크와 호스트 부분으로 나누는 것은 일반적이다. 일반적이

지는 않지만 C 클래스도 2 바이트를 빌려주어 서브넷하는 경우도 가능하다.

서브넷은 서브넷 마스크를 통해 지정한다. 서브넷 마스크는 비트열로써 네트워

크 비트는 1로 호스트 비트는 0으로 이루어진다.

서브넷 마스크는 부팅될 때 ifconfig명령으로 네트워크 인터페이스 컨피그에 지

정한다. 커널은 일반적으로 기본 IP 클래스를 디폴트로 사용한다.

6. CIDR : Classless Inter-Domain Routing

(= Supernetting)

라우팅 소프트웨어는 IP 주소의 어느 비트들이 네트워크를 나타내는지 알 수

있어야 한다. 과거에는 주소 클래스 기반의 non-local 라우팅이 안되었다. 서브

넷은 autonomous 시스템 안에서만 이루어졌다.

인터넷의 급속한 성장으로 라우팅 문제가 발생했는데 해결은 한 번에 하나 이

상의 네트워크를 다루는 군집(aggregate) 라우트를 정의하는 것이었다.

CIDR(RFC1519)는 네트워크 넘버의 lower bit를 감추기 위해 마스킹을 사용하

여 효과적으로 하나의 라우트로 여러 네트워크를 묶는다. 그룹으로 묶기 위해

서는 주소가 인접해야 한다.

(예)199.128.0 199.128.1 199.128.2 199.128.3은 mask 0xFFFFFC00으로 묶인다.

전체 라우트 수를 줄이기 위해 supernetting은 주소할당과 수행될 라우팅을 계

층적이 되도록 하였다. 예로 ISP(Internet Service Provider)는 클라이언트에게

나누어주기 위해 큰 supernet를 배당 받을 수 있는 것이다.

7. 라우팅 전략 선택하기

라우팅 전략은 크게 4가지가 있다.

(1) 라우팅이 없다.

(2) 정적 라우팅

(3) 대부분 정적이고 클라이언트들은 RIP 업데이트를 참조

(4) 동적 라우팅

일반 라우팅 원칙은 다음과 같다.

(1) stand-alone 네트워크는 라우팅이 없다.

(2) 네트워크 밖으로 경로가 하나이면 그 네트워크의 클라이언트들은 long 게

이트웨이에 대해 디폴트 라우트.

(3) 한쪽은 여러 게이트웨이이고 다른 쪽은 world 게이트웨이인 경우 explicit

static 라우팅을 전자에, 디폴트 라우팅을 후자에 적용한다. 양쪽이 여러

게이트웨이이면 동적 라우팅적용.

(4) RIP를 사용하더라도 gated가 어떤 라우트들이 나가게 되는지를 지정하도

록 한다.

(5) 클라이언트들이 라우팅 업데이트에 대해 수동으로 참조하게 하려면

routed -q를 사용한다(gated도 가능).

(6) RIP가 주 라우팅 프로토콜이 아니면 gated로 passive 클라이언트를 위해

그 라우팅 정보를 번역하여 broadcast한다.

(7) routed는 모든 사람에 대해 참조하고 모든 것을 믿는다. gated는 더 많은

업데이트에 대한 조절을 제공한다.

(8) 네트워크가 political/administrative 경계를 걸치면 동적 라우팅을 요구한다.

(9) 중복되거나 루프를 포함하는 동적 네트워크는 가능하면 OSPF를 사용한다.

(10) EGP를 쓰려면 이웃의 autonomous 시스템에게 묻는다.

Setting up a Network

네트워크를 세팅하는 순서는 대략 다음과 같다.

(1) 네트워크의 물리적, 논리적 구조를 계획한다.

(2) IP 주소를 할당한다.

(3) 네트워크 하드웨어를 설치한다.

(4) 부팅될 때 네트워크 인터페이스를 컨피그하도록 호스트를 셋업한다.

(5) 라우팅 데몬을 셋업하거나 정적 라우트를 셋업한다. 둘다 할 수도 있다.

1. 인터넷 주소 얻기와 할당

네트워크 넘버는 InterNIC Registration Service에 의해 할당된다. 할당되는 IP

주소는 네트워크 인터페이스에 할당되는 것이다.

2. ifconfig : 네트워크 인터페이스 컨피그

ifconfig 명령어는 네트워크 인터페이스를 인에이블, 디스에이블 하거나 IP 주

소, broadcast 주소, 관련 서브넷 마스크를 셋업하며 다른 옵션이나 파라미터를

세트한다.

(예) ifconfig en0 128.138.240.1 up netmask 255.255.255.0

이서네트의 경우 일반적인 칩이 인텔(ie) 나 AMD(le) 이다. netstat -i 명령어

는 무슨 인터페이스가 시스템에 존재하는지 찾는다. 솔라리스에서는 ifconfig

plumb 명령으로 네트워크 인터페이스를 처음에 부착시켜 주어야 한다.

IP 주소를 컨피그하는 경우 Family항목을 inet으로 세트해야 한다. 어떤

ifconfig명령 버전은 생략될 때 자동으로 inet로 인식한다(HP와 BSDI는 inet으

로 명시). loopback 인터페이스는 lo0로 불린다. 로컬 호스트가 stand-alone 기

계에서도 네트워크 프로토콜과 서비스가 잘 작동하도록 하는 가상의 하드웨어

로 반드시 127.0.0.1(localhost)로 IP 주소를 할당해야 한다.

일반 옵션으로는

(1) netmask - 인터페이스에 대하여 서브넷 마스크를 세트한다(선, 솔라리스에

서는 /etc/networks, /etc/netmask파일의 논리적 이름을 쓸 수도 있다).

(2) broadcast - 인터페이스에 대하여 IP broadcast 주소를 지정한다. 바른

broadcast 주소는 호스트 부분이 모두 1로 세트된 것이다(SunOS에서는 0으

로).

(3) metric - 라우팅에 영향을 주는 옵션으로 보통 한 쪽에서 다른 쪽의 네트

워크로 패킷이 전송되는 시간이 1 hop인데 metric옵션은 인터페이스에 관련된

hop count로써 실세계의 비효율을 고려해 가상으로 높게 잡을 수 있다.

(예) ifconfig en0 128.138.240.1 up netmask 255.255.255.0 broadcast

128.138.240.255 -> 네트워크 클래스 B

‘ifconfig en0’와 같이 사용하면 현재의 컨피그 상태를 보여준다.

3. route : Configure static routes

route명령은 정적 라우트를 정의한다. 즉 명시적으로 라우팅 테이블을 가지는

것이다.

라우팅은 IP 계층에서 수행된다. 다른 호스트로 향하는 패킷이 도착하면 그 목

적지의 주소가 커널의 라우팅 테이블의 엔트리와 비교된다. 목적지의 네트워크

번호가 라우트의 것과 일치하면 패킷은 해당 라우트와 연관되는 다음 게이트웨

이 IP 주소로 진행된다.

라우팅에는 2가지의 특별한 경우가 있다.

첫 번째로 패킷은 직접 연결된 네트워크 위의 어떤 호스트를 향하는 경우 다음

게이트웨이는 지역 호스트의 자체 네트워크 인터페이스가 된다. 이 경우 패킷

은 직접 목적지로 보내지게 된다. 이러한 형태의 라우트는 네트워크 인터페이

스의 컨피그에 추가된다.

두 번째는 목적지 주소와 부합되는 라우트가 없는 경우 디폴트 라우트가 있으

면 그대로 수행되고 없으면 ICMP의 ‘network unreachable’메시지가 송신자

에게 보내진다. 디폴트 라우트는 보통 패킷을 다른 영리한 게이트웨이에게 보

낸다. 각 route 명령은 하나의 라우트를 추가하거나 삭제한다.

<형식>

route [-f] add(delete) [type] 목적지 gateway hop-count

route -f 명령은 라우트 테이블에서 모든 게이트웨이 엔트리를 제거한다.

[type]은 net, host 문자열을 가지는데 네트워크 주소가 아니라 특정 호스트를

지칭하는 완벽한 IP 주소에 부합되는 호스트 라우트를 제공한다.

참고： BSDI, OSF/1 시스템은 route -f 대신 route flush를 사용하며 net,

host 대신 -net, -host를 사용한다.

네트워크 디버깅

1. ping

ping 명령어는 ICMP 프로토콜의 ECHO-REQUEST 데이터그램을 이용하여

특정 호스트로부터 응답을 요구한다. 최하위층의 프로토콜로써 서버 프로세스

에게 아무 요구도 하지 않는다. 단지 서버가 동작하는지만을 체크한다.

또한 네크워크가 제대로 설정이 되있는지, 즉 라우팅이나 Address Resolution

scheme, 네트워크 게이트웨이 등을 확인 할 때도 좋다. 솔라리스, SunOS에서

는 ping에 -s 옵션을 주면 자세한 출력을 보여준다.

최근의 ping 명령어는 packet count 인자가 없으면 무한적으로 출력을 표시하

므로 <Ctrl-C>로 중지시켜야 한다. 아래는 그 출력예를 보인 것이다.

inhavision.inha.ac.kr> ping dragon

PING dragon (165.246.10.3): 56 data bytes

64 bytes from 165.246.10.3: icmp_seq=0 ttl=255 time=0 ms

64 bytes from 165.246.10.3: icmp_seq=1 ttl=255 time=0 ms

....

64 bytes from 165.246.10.3: icmp_seq=34 ttl=255 time=0 ms

64 bytes from 165.246.10.3: icmp_seq=35 ttl=255 time=0 ms

64 bytes from 165.246.10.3: icmp_seq=36 ttl=255 time=0 ms

64 bytes from 165.246.10.3: icmp_seq=37 ttl=255 time=0 ms

64 bytes from 165.246.10.3: icmp_seq=38 ttl=255 time=0 ms

----dragon PING Statistics----

39 packets transmitted, 39 packets received, 0%

packet loss

round-trip (ms) min/avg/max = 0/0/0 ms

위의 경우 39개의 패킷을 dragon 호스트에 보냈고 보낸 패킷을 모두 받았으며

잃어버린 패킷이 없음을 나타낸다. 즉 호스트가 제대로 연결됨을 의미한다. 끝

줄은 전송된 39개의 패킷의 최소, 평균, 최대 반응 시간을 나타낸 것인데 위의

경우는 시간이 너무 작아 0으로 나온 것이다(같은 네트워크 사이에서의 전송이

므로).

2. netstat 명령어

netstat 명령어는 네트워크와 관련된 상태정보를 보여준다. 다음은 보여줄 수

있는 상태의 종류이다.

(1) 네트워크의 연결 상황을 보여준다( 옵션 없이 사용 ).

(2) 인터페이스 설정 정보를 검사한다( -i 옵션 ).

(3) 라우팅 테이블을 조사한다(-n, -r 옵션, 여기서 -n 옵션은

호스트의 주소를 숫자로 표시하라는 옵션).

(4) 여러 네트워크 프로토콜에 대한 운용 상태 정보를 보여준다

(-s 옵션).

인자없이 쓰는 경우 활성화된 TCP 와 UDP 포트의 상황을 볼 수 있다. 또한

-a 옵션을 쓰면 연결을 기다리는 비활성화 된 서버도 볼 수 있다.

inhavision.inha.ac.kr> netstat

Active Internet connections

Proto Recv-Q Send-Q Local Address Foreign Address (state)

tcp 0 0 inhavision.20 pc11.stat.inha.a.1034 TIME_WAIT

tcp 0 0 inhavision.20 pc11.stat.inha.a.1033 TIME_WAIT

tcp 0 0 inhavision.ftp pc11.stat.inha.a.1032 ESTABLISHED

tcp 0 0 inhavision.pop3 165.246.161.23.4176 TIME_WAIT

tcp 0 0 inhavision.4842 blue.nowcom.co.k.telne SYN_SENT

tcp 0 0 inhavision.4840 blue.nowcom.co.k.telne ESTABLISHED

tcp 0 0 inhavision.telnet 165.246.11.58.1026 ESTABLISHED

tcp 0 0 inhavision.telnet 165.246.11.58.1024 ESTABLISHED

tcp 0 0 inhavision.telnet 165.246.11.8.1022 ESTABLISHED

tcp 0 736 inhavision.telnet annex.11074 ESTABLISHED

tcp 0 0 inhavision.4835 songdo4.telnet ESTABLISHED

tcp 0 0 inhavision.telnet 165.246.11.41.1145 ESTABLISHED

tcp 0 0 inhavision.4825 mv35ii.telnet ESTABLISHED

tcp 0 0 inhavision.4824 blue.nowcom.co.k.telne ESTABLISHED

tcp 0 0 inhavision.telnet owl.2166 ESTABLISHED

tcp 0 0 inhavision.telnet 165.246.11.5.1024 ESTABLISHED

tcp 0 0 inhavision.telnet 165.246.11.73.1028 ESTABLISHED

tcp 0 0 inhavision.4813 blue.nowcom.co.k.telne ESTABLISHED

tcp 0 0 inhavision.telnet 165.246.31.44.1120 ESTABLISHED

tcp 0 0 inhavision.telnet 165.246.10.200.1222 ESTABLISHED

tcp 0 1 inhavision.4762 blue.nowcom.co.k.telne ESTABLISHED

tcp 0 0 inhavision.telnet 165.246.11.123.1024 ESTABLISHED

위에서 SQ와 RQ는 로컬 호스트에 연결된 send, receive queue의 길이를 나타

낸다(TCP 연결 반대 방향은 큐의 길이가 다를 수 있다).

UDP는 비연결성 서비스 프로토콜인데 위의 상태는 TCP에 대해서만 의미를

가진다.

상태 필드에는 LISTENING, TIME_WAIT, ESTABLISH ED가 오는데

LiSTENING은 현재 서버가 연결을 위해 대기중임을 나타낸다. TIME_WAIT

는 종결 작업을 수행중인 연결에 대해 나타낸다. ESTABLISHED는 현재 연결

되었음을 나타낸다. 하나의 TCP 소켓은 동시에 여러 연결을 유지할 수 있다.

존재하지 않거나 접근 불가능한 서버의 접근 시도는 SYN_SENT 상태로 나타

낸다. -i 옵션은 네트워크 인터페이스를 보여준다고 했는데 다음은 그 예이다.

만약 간격 시간을 주면 해당 디폴트 인터페이스에 대해 그 간격마다 상태를 나

타낸다. 또한 ‘-I ifname’옵션은 다른 인터페이스 지정에 사용한다.

inhavision.inha.ac.kr> netstat -i

Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll

tu0 1500 DLI none 3064824 16 2248661 9 51719

tu0 1500 <Link> 08:00:2b:e4:aa:33 3064824 16 2248661 9 51719

tu0 1500 165.246.10 inhavision 3064824 16 2248661 9 51719

tu1 1500 DLI none 0 0 0 0 0

tu1 1500 <Link> 00:00:f8:21:01:6d 0 0 0 0 0

tu2 1500 DLI none 0 0 0 0 0

tu2 1500 <Link> 00:00:f8:20:68:ae 0 0 0 0 0

sl0* 296 <Link> 0 0 0 0 0

lo0 1536 <Link> 3788 0 3788 0 0

lo0 1536 loop localhost 3788 0 3788 0 0

위의 예에서 Ierrs와 Oerrs 필드를 유의해 보아야 한다. 두 필드의 수치가 높으

면 케이블에 문제가 있음을 의미한다. 그리고 Coll 필드는 충돌 패킷의 수를 나

타내는데 보통 전체 전송 패킷의 3 % 미만인데 이 보다 크면 네트워크가 매우

부하가 크다고 판단할 수 있다.

netstat -r 명령은 커널의 라우팅 테이블을 보여준다.

inhavision.inha.ac.kr> netstat -r -n

Routing tables

Destination Gateway Flags Refs Use Interface

Netmasks:

Inet 255.255.255.0

Route Tree for Protocol Family 2:

default 165.246.10.250 UG 31 1911758 tu0

127.0.0.1 127.0.0.1 UH 1 4 lo0

165.246.10 165.246.10.162 U 8 330973 tu0

Flags 필드의 상태는 다음의 내용을 나타낸다.

> U : 액티브

> G : 게이트웨이

> H : 호스트 라우트

> D : ICMP indirect로부터의 라우트

> GH : 중간 게이트웨이를 지나는 호스트 라우트

Refs 필드는 해당 라우트를 이용하는 현재 연결된 TCP 채널의 수를 나타낸다.

Use 필드는 이 경로를 통해 보낸 패킷의 수를 나타낸다.

‘netstat -s’ 옵션은 네트워크의 내부에 산재한 카운터들의 내용을 덤프한다.

즉 모든 IP, ICMP, TCP 네트워크 정보를 보여준다. 아래가 그 예이다. 물론

이를 완전히 이해하려면 각 프로토콜의 내부 구조까지 알아야 할 것이다. 각자

깊이 있게 공부해 보기 바란다.

inhavision.inha.ac.kr> netstat -s

ip:

2571036 total packets received

0 bad header checksums

0 with size smaller than minimum

0 with data size < data length

0 with header length < data size

0 with data length < header length

21 fragments received

0 fragments dropped (dup or out of space)

4 fragments dropped after timeout

0 packets forwarded

0 packets not forwardable

0 redirects sent

icmp:

1385 calls to icmp_error

0 errors not generated 'cuz old message was icmp

Output histogram:

echo reply: 78

destination unreachable: 1385

210 messages with bad code fields

0 messages < minimum length

0 bad checksums

0 messages with bad length

Input histogram:

echo reply: 156

destination unreachable: 873

source quench: 40

echo: 78

time exceeded: 186

78 message responses generated

igmp:

0 messages received

0 messages received with too few bytes

0 messages received with bad checksum

0 membership queries received

0 membership queries received with invalid field(s)

0 membership reports received

0 membership reports received with invalid field(s)

0 membership reports received for groups to which

we belong

0 membership reports sent

tcp:

2220561 packets sent

1391533 data packets (374488110 bytes)

15401 data packets (4036447 bytes) retrans

mitted

614095 ack-only packets (529432 delayed)

0 URG only packets

358 window probe packets

179457 window update packets

19710 control packets

2524087 packets received

1267515 acks (for 374548882 bytes)

20566 duplicate acks

0 acks for unsent data

1413242 packets (287394970 bytes) received

in-sequence

22507 completely duplicate packets

(3820434 bytes)

788 packets with some dup. data

(106444 bytes duped)

45963 out-of-order packets (20954711 bytes)

31 packets (15 bytes) of data after window

15 window probes

39623 window update packets

327 packets received after close

0 discarded for bad checksums

0 discarded for bad header offset fields

0 discarded because packet too short

6709 connection requests

11712 connection accepts

17025 connections established (including accepts)

19777 connections closed (including 8247 drops)

1864 embryonic connections dropped

1239852 segments updated rtt (of 1255340 attempts)

15642 retransmit timeouts

44 connections dropped by rexmit timeout

471 persist timeouts

760 keepalive timeouts

242 keepalive probes sent

446 connections dropped by keepalive

udp:

20616 packets sent

45597 packets received

0 incomplete headers

0 bad data length fields

0 bad checksums

1 full socket

26322 for no port (24937 broadcasts, 0 multicasts)

3. traceroute : Trace IP packets

traceroute 명령은 IP 패킷이 목적지에 도달하는데 통과하는 일련의 게이트웨이

를 보여준다. 사용형식은 목적지 호스트의 이름만을 인자로 주면 된다.

inhavision.inha.ac.kr> traceroute dragon

traceroute to dragon (165.246.10.3), 30 hops max,

40 byte packets

1 dragon (165.246.10.3) 1 ms 1 ms 0 ms

traceroute명령은 outbound 패킷의 time-to-live 필드를 세트하여 작동한다. 즉

타임 아웃이 될 때 현재의 게이트웨이가 출발지로 에러 메시지를 보내게 하여

알아내는 원리이다. 그리고 다시 time-to-live 필드값을 하나 증가시켜서 반복

한다.

4. tcpdump, etherfind, snoop : Monotor Traffic

위의 프로그램들은 네트워크에서의 traffic을 감시하여 사용자에 의해 지정된

조건을 만족하는 패킷을 찾아 프린트한다. etherfind명령은 SunOS의 tcpdump

이다. 솔라리스는 snoop를 가진다.

5. arp : Inspect and Manage Address Mapping

arp 명령은 IP주소를 하드웨어 주소로 매핑하는 커널 테이블에 접근한다.

이서네트에서 이 테이블은 ARP 프로토콜을 이용해 유지된다. 다른 하드웨어에

서는 직접 정의해야 한다.

‘arp -a’ 명령은 매핑 테이블의 내용을 보여준다. 이 테이블이 자동으로 유

지되는 경우는 최근 통신한 시스템을 보여준다. 다른쪽의 게이트웨이는 보이지

않고 해당 네트워크만을 보여준다. 다음은 그 예이다.

inhavision.inha.ac.kr> arp -a

mv35ii.inha.ac.kr (165.246.10.8) at 08-00-1b-01-21-1a

ticom.inha.ac.kr (165.246.10.9) at 02-cf-1f-e1-35-83

annex.inha.ac.kr (165.246.10.161) at 00-80-2d-01-84-83

nms.inha.ac.kr (165.246.10.2) at 08-00-20-18-e4-4a

? (165.246.10.250) at 08-00-02-05-f3-15

dragon (165.246.10.3) at 08-00-20-71-f5-00

‘arp -d 호스트명’은 테이블의 엔트리를 삭제한다.

‘arp -s 호스트명 주소’는 하나의 엔트리를 추가한다.

‘arp -f 파일명’은 컨피그 파일을 이용해 테이블을 셋업한다. 또한 arp 호스

트명 명령은 호스트의 IP주소를 보여준다.

그 외의 프로토콜

TCP/IP는 유닉스의 표준 통신 프로토콜이다. 이 외에도 APPLETALK,. IPX,

DECnet 등이 있다.

1. APPLETALK

애플 사에 의해 개발되었다. 원래 프린터 공유 목적으로 만들어 졌다. TCP/IP

와 마찬가지로 여러 하드웨어에서 동작한다. 시리얼 케이블인 경우는

LocalTalk이고 이서네트의 경우는 EtherTalk이다. 또한 MacTCP도 만들었다.

(1) EtherTalk

Phase 1은 최초로 개발된 것으로 약간의 문제가 있었다.

Phase 2는 Phase 1의 Broadcast문제를 Multicast로 대치하여 문제를 해결한

것이다. Phase 2는 SNAP(표준 802.3) 헤더의 패킷을 encapsulate 한다.

(2) LocalTalk

전화선을 사용한 네트워크를 지원한다. 230Kbps로 동작한다.

(3) AppleTalk 어드레싱

IP 주소와 같이 네트워크 번호와 노드 번호로 구성된다.

(4) AppleTalk Naming

AppleTalk 사이트에서의 디바이스들은 ‘Zone’으로 그룹핑된다. 각 엔트리

는 오브직트 이름과 타입 이름을 가진다.

2. IPX

IPX(Internetwork Packet Exchange)는 노벨 사에 의해 NetWare의 일부로 개

발된 프로토콜이다.

3. DECnet

DEC의 네트워크 상품 이름이다.

DECnet 주소는 전송 매체와는 독립적이다. 1바이트의 area(논리적 구조)와 2바

이트의 노드 번호로 조합되어 구성된다.

마치며

이번 달에는 유닉스 네트워크의 기본인 TCP/IP에 대한 기본적인 내용에 대해

서 다루었다. 사실 TCP/IP에 대해 자세히 설명하자면 책 한권은 되겠지만 이

글의 목적이 TCP/IP를 가지고 무엇을 해 보려는 것이 아니라 시스템 관리자의

입장에서 네트워크를 관리하는게 목적이므로 전체적인 윤곽과 필요한 내용만을

기술하였다.

사실 네트워크 분야라는 것이 매우 광범위하고 종류도 많아 공부하기가 여간

어려운 것이 아니다. 독자에게 부탁하고 싶은 것은 틈나는 데로 OSI 7계층에

대해 공부를 하면서 이론적인 틀을 잡으며 공부했으면 하는 것이다. 그래야 다

른 프로토콜을 새롭게 공부하는데 있어 쉽게 접근할 수 있을 것이라 생각하기

때문이다.

TCP // IP 강좌 1

2010-02-04T17:22:45+09:00

컴퓨터 네트워크 용어

네트워크 분야에서 용어의 정립은 매우 중요하다. 이제부터 설명하는 용어는

앞으로의 글을 이해하는데 가장 필수적이므로 확실히 이해하고 지나가기 바란

다.

1. 네트워크

약간씩 차이는 있을 수 있으나 독립된 컴퓨터들이 상호 연결된 컴퓨터들의 집

합을 의미하는 것으로 생각하면 될 것이다. 단 여기서 마스터, 슬래이브 관계의

컴퓨터 연결은 제외한다.

분산 시스템과의 차이는 분산 시스템이 모든 사용자에게 시스템 자체가 하나인

것처럼 보이게 하는 즉, 자동으로 일을 분산 처리하는 반면 네트워크에서는 사

용자가 작업을 명시적으로 각 기계에 지정하여 수행한다는 것이다. 분산 시스

템은 매우 특별한 소프트웨어를 가진 특별한 형태의 네트워크인 것이다. 여기

서 특별한 소프트웨어란 스스로 일을 처리하여 사용자에게는 여러 컴퓨터가 마

치 하나인 것처럼 보이게 하는 기능을 가진 소프트웨어를 일컫는다.

2. 인터넷(인터넷워크)

요즘 매우 흔히 들을 수 있는 단어이다. 그러나 이 말의 정확한 의미를 아는

사람은 그리 많지 않을 것이다. 인터넷이란 서로 다른 네트워크에 있는 컴퓨터

사이의 통신을 위한 두개 이상의 서로 다른 네트워크 연결을 의미한다.

인터넷의 목적은 물리적으로 다른 네트워크의 성질을 감추고 하나의 잘 구성된

단위 네트워크처럼 동작하도록 하는데 있다.

두개의 서로 다른 물리적 네트워크를 연결하는 한 방법은 두 네트워크를 붙이

는 게이트웨이를 사용하는 것이다. 때때로 라우터(router)라고도 한다.

3. 메시지, 프레임, 패킷

메시지란 의미를 지니는 데이터의 단위인 반면 다른 것들은 의미를 지니지 않

는다.

프레임은 저 수준의 네트워크 하드웨어를 언급할 때 쓰이는 패킷의 다른 명칭

이며 패킷은 각각 헤더와 데이터로 구성되어 네트워크에서 전송되는 데이터 형

태이다.

4. 게이트웨이, repeater, bridge

3개 모두 두 네트워크를 연결하는데 쓰이는 것들이지만 다른 점은 연결이 되는

위치이다.

repeater는 물리 층에서 단순히 전기적 신호를 복사하며 bridge는 데이터 링크

층에서 프레임을 다른 네트워크로 복사한다. 그리고 라우터는 네트워크 층에서

경로를 설정하여 패킷을 전송한다.

게이트웨이는 2개 이상의 네트워크를 상호 연결하는데 쓰이는 개체를 지칭하는

포괄적 용어이다.

참고：TCP/IP에서의 게이트웨이는 네트워크 층의 라우터를 지칭한다.

때때로 게이트웨이란 용어는 네트워크층 위의 각 층에서의 특정 대화를 수행

하는 소프트웨어를 나타내기도 한다. 그 예로 메일 게이트웨이는 전자 메일을

다른 형태로 변경한다.

repeater는 보통 하드웨어 장치이며 bridge와 라우터는 하드웨어 혹은 소프트웨

어로 구현될 수 있다. 라우터(게이트웨이)는 보통 위의 기능을 수행하는 전용

기계이다.

호스트가 하나 이상의 네트워크 인터페이스를 가지는 경우 multihomed 되었다

고 한다.

5. Fragmentation과 Reassembly

대부분의 네트워크 층은 데이터 링크 층의 특성에 따라 그들이 다룰 수 있는

최대 패킷 크기를 가진다. 이것이 MT U(Maximum Transmission Unit) 인데

간혹 전체적인 의미로도 사용된다.

이서네트의 경우 최대 1500바이트를 넘지 못하며 토큰 링의 경우는 4464바이트

를 넘지 못한다.

이러한 MTU로 인해 혹은 그 외의 이유로 생긴 것이 Fra gmentation인데

Fragmentation이란 데이터 스트림을 더 작은 조각으로 나누는 것이다. 어떤 네

트워크에서는 Segmen tation이란 단어를 쓰기도 한다. fragmentation의 역은

reas sembly이다. TCP/IP의 경우 IP층에서 이루어진다.

6. 라우팅(routing)

통신 네트워크는 2개의 기본 형태를 가진다.

(1) circuit-switched : 공중전화 시스템이 그 대표적 예로 일단

연결이 설정된 후에 비로소 통신하는 방식이다.

(2) packet-switched : 인터넷이 한 예이다. 전송할 정보들을 작

은 조각(패킷)으로 나누어 통신 선로를 서로 공유하며 보내는 방

식이다.

패킷이 갈 수 있는 각각의 길을 route라고 한다.

이 경로 결정은 네트워크 층에서 이루어지는데 실제 패킷이 전달되는 시간은

여러 상황에 따라 시시각각 변하므로 예측하기 매우 힘들다.

7. Mutiplexing과 Demultiproxing

multiplexing이란 여러 개를 하나로 연결하는 것을 의미한다. 네트워크 층에서

는 여러 개를 하나로 연결하는 것을 의미하는데 네트워크 층에서는 하나 이상

의 사용자 프로세스가 동시에 여러 규약을 사용 할 수 있는것인데 주어진 규약

이 데이터를 IP층에서 내려보낼 때 보내는 프로세스가 어느 규약에서 나온 것

인지를 알리는 것이다. 예를 들면 어떤 한 사용자 프로세스가 TCP와 UDP 프

로토콜을 모두 사용하는 경우가 될 것이다. 반대로 UDP가 IP층에서 데이터를

받는 경우 데이터를 규약을 통해 받아야 할 프로세스에게 알리는 것이

Demultiplexing(하나에서 여러 개로)이다. 이것을 위해 UDP/TCP는 사용자 프

로세스를 구분하기 위해 포트 번호를 가진다.

8. 포트(Port)

IP 주소는 하나의 시스템을 구분하고 포트는 특정 서비스나 프로세스를 구분한

다(TCP/UDP). 포트는 특정 메일박스 프로토콜을 지정하는 IP 주소를 보조하

는 2바이트 숫자이다.

9. Broadcast, Mutilcast

unicast 메시지는 특정 호스트로 데이터를 전송할 때 쓰이는 메시지이며

broadcast 메시지는 네트워크의 모든 호스트로 데이터를 보낸다. 그리고

multicast 메시지는 네트워크의 특정 그룹의 호스트로 데이터를 보낸다.

broadcast의 경우 다른 네트워크로 forwarding이 되지 않는다. 또한 이서네트

의 경우 broadcast일 때 특정 주소 비트가 1로 세트된다.

10. nesting(encapsulation)

각 프로토콜의 패킷이 다음 프로토콜에 의해 발생되는 패킷의 데이터 부분이

되는 것.

11. Modes of Service

OSI의 어떤 층 중 2개의 peer entity사이에서 제공되는 통신 서비스의 종류를

기술하는데는 여러 파라미터가 있다. 여기서는 transport 층이 응용 층에 제공

하는 서비스에 초점을 두고 설명한다.

(1) connection-oriented (virtual circuit)와 connectionless

(2) sequencing

(3) error control

(4) flow control

(5) byte stream 혹은 message

(6) full-duplex 혹은 half-duplex

connection-oriented 서비스는 통신 시작 전에 응용 프로그램 사이에 논리적인

연결이 되어 있어야 한다. 이것을 가상 회선이라 한다.

응용 프로그램 입장에서는 전용선을 가지는 것과 같은 착각을 일으키게 한다.

보통 다음의 3단계를 가진다.

(1) connection establishment

(2) Data transfer

(3) connection termination

connectionless 서비스(Datagram)는 데이터그램(datagram)이라 불리는 메시지

를 전송하는데 각각은 독립적이므로 전송을 위한 모든 정보를 가지고 있어야

한다. TCP/IP의 경우 TCP는 connection-oriented 서비스를 제공하며 UDP는

connectionless 서비스를 제공한다.

ISO/OSI 네트워크 모델

OSI(Open System Interconnection)란 여러 프로토콜들의 국제적 표준화를 위

해 ISO가 만든 개방형 시스템을 연결하는 모델이다.

OSI 모델은 그 자체가 네트워크 아키텍처는 아니다. 왜냐하면 OSI모델이 각

층에서 사용될 정확한 서비스나 프로토콜을 지정하고 있지는 않기 때문이다.

OSI는 단지 각 층이 무엇을 해야 할지만을 말하고 있다. OSI 모델은 7개의 계

층으로 구성된다.

1. 물리 층(Physical layer)

물리 층은 통신 채널을 통한 순수 데이터(raw bit)들의 전송과 관련된다.

디자인 이슈는 한 쪽에서 보낸 1비트를 다른 한쪽에서 어떻게 하면 그대로 전

송 받을 수 있을지를 확실하게 할 수 있는가 하는 점이다.

전형적인 문제로는 1(0)비트를 어떻게 나타낼 것인가, 전송의 방향은 어떻게 할

것인가, 최초 연결의 설정은 어떻게 할 것인가 등이다. 이러한 물리 층의 디자

인은 전기공학의 측면에서 생각될 수 있는 것이다.

2. 데이터 링크 층(Data Link layer)

데이터 링크 층의 주 업무는 순수 데이터 전송 설비를 네트워크 층에서 보았을

때 에러가 없어 보이는 전송 라인으로 변환시켜 주는 것이다. 즉, 송신자는 데

이터를 데이터 프레임이라는 작은 조각으로 나누어 순차적으로 전송하고 수신

자에 의해 되돌아오는 acknoledgement 프레임을 처리하여 에러에 대한 처리를

해 준다. 이런 프레임의 양쪽 끝에는 프레임의 경계를 알기 위해 특정 비트 패

턴을 붙인다.

프레임의 손상, 손실, 중복에 관해 처리하는 것도 담당한다.

3. 네트워크 층(Network layer)

네트워크 층은 서브넷(subnet)의 동작을 제어하는 것과 관련된다.

주요 디자인 이슈는 어떻게 패킷이 소스에서 목적지로 경로가 설정될지를 결정

하는 것이다.

라우트는 정적 테이블을 이용하여 터미널 세션과 같은 각 대화의 시작점에 결

정될 수 있다. 또는 현재의 네트워크 부하를 감안하여 동적으로 결정될 수도

있다.

네트워크 포화(congestion)의 제어도 이 네트워크 층이 맡는다.

heterogenous 네트워크(이형 네트워크 - 서로 다른 구조의 네트워크)가 서로

연결될 때 발생하는 여러 문제들, 즉 허용 패킷의 크기 문제나 어드레싱(이름

부여) 차이 문제들의 해결도 담당한다.

Broadcast 네트워크에서는 라우팅 문제가 간단하므로 네트워크 층이 매우 얇게

되거나 아예 없는 경우가 많다.

4. 트랜스포트 층(Transport layer)

기본 기능은 세션 층에서 데이터를 받아 필요하면 더 작은 부분으로 나누고 이

것을 네트워크 층으로 전송한 후 각 조각들이 모두 목적지로 바르게 도착했는

지를 확인하는 것이다. 덧붙여 세션 층을 하드웨어의 변화에 의한 변경으로부

터 분리한다.

일반적인 조건에서 트랜스포트 층은 세션 층이 요구하는 각 트랜스포트 층에

대해 구별되는 네트워크 연결을 생성한다. 만약 트랜스포트 층이 고효율이 필

요한 경우 네트워크 연결사이에서 데이터를 분할하여 다중 네트워크 연결을 생

성한다. 반면 네트워크 연결의 유지비용이 많이 드는 경우 트랜스포트 층은 비

용 절감을 위해 같은 네트워크 연결로의 트랜스포트 연결을 통합(multiplexing)

할 수 있다.

모든 경우 트랜스포트 층은 multiplexing을 세션 층에 대해 투명하게 해야 한

다.

트랜스포트 층은 또한 최종적 네트워크 사용자인 세션 층에 어떤 타입의 서비

스를 제공할지를 결정한다. 가장 유명한 형태의 트랜스포트 연결은 보낸 순서

대로 메시지를 전송하는 에러 없는 점대점(point-to-point) 채널이다. 또 다른

트랜스포트 서비스의 종류로는 전송 순서에 대한 보장 없는 독립된 메시지 전

송과 여러곳으로의 메시지의 방송(broadcasting)이다. 이러한 서비스의 종류는

연결이 구축될 때 결정된다.

트랜스포트 층은 진정한 end-to-end(source-to-destination)층이다. 다시 말하

면 소스 기계의 프로그램이 메시지 헤더와 제어 메시지를 이용해 목적지의 다

른 비슷한 프로그램과 대화한다. 1-3층은 각 기계와 그 주변 사이의 프로토콜

일 뿐 궁극적인 소스와 목적지 기계에 의한 것은 아니다. chained 형태인 1-3

층과 다른 점은 4-7층이 end-to-end 라는 것이다.

많은 호스트가 다중 프로그래밍 되므로 즉, 여러 개의 연결이 이루어지는 데

있어 메시지가 어떤 연결에 속하는지 알기 위한 정보도 또한 포함한다.

트랜스포트 층은 여러 메시지를 한 채널로 통합할 뿐 아니라 네트워크사이 연

결의 해제와 설정을 관리해야 한다. 이것을 위해서는 이름 부여 방법이 필요하

다. 또한 정보의 흐름을 조절하는 메커니즘도 있어야 한다.

5. 세션 층(Session layer)

크게 인증과 검증을 처리한다.

세션 층은 다른 기계의 사용자가 그들 사이의 세션을 설정하도록 한다. 세션은

트랜스포트 층과 같이 보통의 데이터 전송을 한다. 그러나 어떤 응용에서는 더

개선된 서비스를 제공한다. 또한 세션은 원격 로그인을 하거나 파일을 전송하

게 한다.

세션 층의 서비스 중 하나가 다이얼로그 컨트롤이다. 즉, 동시에 양 방향으로

할 것인가 한 방향으로만 전송할 것인가 등을 결정하는 것이다.

관련 세션 서비스가 토큰 매니지먼트이다. 이것은 토큰을 가진 쪽에서 적절한

행동을 취할 수 있게 한 것이다. 또 다른 세션 서비스가 syncronization이다.

파일을 전송할 때 중간에 끊기게 되는 경우 이 전에 끝났던 부분에 체크포인트

를 삽입하여 전송을 재개하면 다시 그곳에서부터 시작하게 하는 것이다.

6. 프리젠테이션 층(Presentation layer)

크게 데이터 문제와 압축을 처리한다.

프리젠테이션 층은 전송되는 정보의 문법과 의미에 관계된다. 서비스의 한 예

로는 기계마다 서로 다른 데이터 표현형식의 통일을 위해서 데이터를 표준 형

식으로 encode하는 것이다. 또한 데이터 압축과 암호화 등에도 관련된다.

7. 애플리케이션 층(Application layer)

최종사용자에게 서비스를 제공한다(mail, login 등).

애플리케이션 층은 일반적으로 쓰이는 여러 프로토콜을 포함한다. 예로 서로

다른 형식의 터미널 타입의 호환을 위해 가상의 네트워크 버츄얼 터미널을 정

의하여 실제 터미널을 이것으로 매핑하는 것이다. 또 다른 기능으로는 파일

전송이 있다. 서로 다른 파일 이름 지정 방법이나 문자 라인의 표현 방식을 서

로 호환되도록 하는 것이다.

이 외에도 e-mail, remote job entry, directiory lookup 등의 일도 수행한다.

TCP/IP 네트워크 모델

1. 링크 층

네트워크 하드웨어와 디바이스 드라이버를 책임진다.

TCP/IP는 이서네트와 토큰 링, RS-232 시리얼 라인에서 구현되었다.

2. 네트워크 층

기본 통신, 어드레싱, 라우팅을 책임진다.

(1) IP 데이터그램

모든 IP 데이터그램은 출발지와 도착지 주소를 가진다. 즉, 각 데이터그램이 독

립적인 경로를 가질 수 있다는 말이다.

또한 fragmentation이 책임도 가지며 기본적인 flow control도 제공한다.

(2) 인터넷 어드레스(전체 32비트)

multihomed인 경우 모든 인터넷 주소는 고유한 호스트를 지칭하지만 각 호스

트가 고유한 주소를 가지지는 않는다.

(3) 서브넷 어드레스

어떤 클래스의 인터넷 주소를 가진 기관이 원하는 경우 서브네트워크를 제공하

기 위해 가능한 호스트 주소 공간을 분할 할 수 있다.

예를 들면 class B의 주소를 가지는 경우 호스트 ID에 150개의 호스트를 할당

하고 이것들을 10개의 물리적 네트워크로 구성하기위한 첫 번째 방법으로는 물

리적인 구성을 무시하고 호스트 ID를 1에서 150까지 부여하는 것이다. 이 방법

은 모든 게이트웨이가 각각의 호스트가 어디 있는지 알아야 한다. 이 경우 새

로운 호스트를 추가할 때 각 게이트웨이의 라우팅 테이블의 갱신이 필요하다.

두 번째 방법이 서브넷을 이용하는 것이다. 즉 호스트 ID비트 중 8비트를 서브

넷 ID로 쓰는 것이다. 이 경우 첫 번째 방법과는 달리 게이트웨이 시스템은 서

브넷 ID를 가지고 라우팅에 사용한다. 새로운 호스트의 추가에도 갱신이 불필

요하다.

(4) Address Resolution

이서네트의 경우 48비트를 사용하는데 인터페이스 보드 제작 사에서 고유 번호

를 부여한다.

IP층이 인터넷 주소를 이서네트 주소로 변환하는 것을 Address Resolution이라

하고 디스크 없는 워크스테이션이 부트될 때 인터넷 주소를 결정하는 것을

Reverse Address Resolution이다.

ARP는 호스트가 특별한 패킷을 broadcast하여 특정 인터넷 주소를 가진 호스

트가 그 이서네트 주소에 응답하도록 할 수 있다. 응답을 받은 requesting 호스

트는 이서네트 주소를 인터넷 주소로 매핑하여 다음 데이터를 전송할 때 같은

주소를 계속 사용해 패킷을 전송하는 것이다.

RARP는 RARP서버가 32 비트 인터넷 주소와 대응되는 48비트 이서네트 주소

를 각 워크스테이션에 대해 가진다. 워크스테이션이 초기화 될 때 이서네트 주

소를 하드웨어 인터페이스로부터 얻어 이서네트 RARP 패킷(이서네트 주소를

가지고 인터넷 주소를 질의)을 broadcast한다. 이 때 RARP 서버만이 응답한

다.

3. 트랜스포트 층

네트워크에서 프로그램사이의 통신을 책임진다. TCP/UDP가 있는데 UDP는 IP

와 구별되는 2가지의 특징을 가진다.

> 포트 번호를 가진다.

> optional checksum를 가진다.

위의 2가지는 IP를 직접 사용하지 않고 UDP를 사용하는 충분한 이유가 된다.

4. 애플리케이션 층

최종 사용자 응용 프로그램들로 FTP, TFTP, BOOTP 등이 있다.

TCP/IP의 구성요소

1. 인터넷 프로토콜(IP)

실제 데이터를 한 기계에서 다른 기계로 보낸다.

모든 TCP, UDP, ICMP, IGMP 데이터가 IP 데이터그램으로 전송된다.

IP는 unreliable(비신뢰성), connectionless(비연결성) 데이터그램 전송 서비스를

제공한다. 비신뢰성의 예로는 만약 라우터 버퍼가 다 찬 경우 IP는 데이터그

램을 버리고 ICMP 메시지를 출발지로 되돌려 보낸다. 비연결성이란 각각의 데

이터그램이 다른 데이터그램과 독립적으로 다루어짐을 의미한다. 예를 들면 패

킷 A,B를 보내는 경우 둘은 서로 다른 경로를 경유하여 B,A순으로 도착할 수

있다는 것이다.

2. 인터넷 제어 메시지 프로토콜(ICMP)

에러 메시지, 라우팅 어시스턴스, echo request를 포함하는 IP에 대한 저 수준

의 지원

ICMP는 IP층의 일부로 여겨지곤 한다.

ICMP는 에러 메시지와 주의를 요하는 다른 조건들을 가지고 통신한다. ICMP

메시지는 보통 IP layer와 TCP나 UDP 같은 높은 계층에서도 작동한다.

어떤 ICMP 메시지는 사용자 프로세스에게 되돌려질 에러를 발생한다. ICMP

메시지는 IP 데이터그램에서 전송된다. 즉 IP 데이터그램에 encapsulation됨을

의미한다.

3. Address Resolution 프로토콜(ARP)

네트워크의 논리적 주소를 물리적인 하드웨어 주소로 변환한다.

4. User Datagram 프로토콜(UDP)와 Transmission Control 프로토콜(TCP)

IP를 통해 하나의 프로그램에서 다른 프로그램으로 데이터를 보내고(TCP),

UDP는 각 메시지에 대한 검증 없는 전송을 수행한다. UDP와 달리 TCP는 신

뢰성 있는 connection-base 전송을 한다.

호스트의 주소 지정

어떤 한 기계에 부여할 수 있는 주소는 크게 2가지인데 물리적인 주소(이서네

트 등의 주소)와 논리적인 주소(인터넷 주소)이다.

1. 하드웨어에 의한 가장 낮은 수준의 주소관리

(addressing)

▶ 이서네트의 경우는 6바이트의 주소를 할당한다.

▶ 토큰링은 2, 4, 6바이트의 주소를 가진다.

▶ point-to-point 네트워크(SLIP/PPP)는 주소를 가지지 않는다.

2. 인터넷 어드레싱

IP 어드레싱으로 알려진 것으로써 세계적으로 고유한 값을 가지며 시스템 종속

적인 성질을 가진다. 4바이트 IP 주소는 각 네트워크 장치에 할당된다.

3. IP 주소와 하드웨어 주소와의 매핑

링크 계층에 의해 구현되어 진다.

Broadcasting되는 네트워크에서는 ARP가 자동으로 해준다. 유닉스 시스템에

서는 IP 주소를 텍스트 이름으로 연관시켜 준다(‘/etc/hosts’ 파일을 사용하

거나 DNS를 사용한다).

인터넷 주소

인터넷 주소는 4바이트 주소로 네트워크 부분과 호스트 부분으로 나뉜다. 호스

트 부분은 네트워크에서의 시스템(기계)을 지정한다. 네트워크 부분은 주소가

참조하는 논리적 네트워크를 지정한다. 네트워크 부분에서 라우팅 결정이 이루

어진다. 관례적으로 10진수로 쓰인다.

인터넷 주소의 분류

전부 5개로 분류한다.

1. A 클래스

주요 네트워크로서 거의 할당하지 않는다. 형식은 N.H.H.H 이다(N이 네트워크

부분, H가 호스트 부분).

1.*.*.* ~ 128.*.*.*값을 가진다.

2. B 클래스

비교적 큰 사이트에 할당한다. 일반적으로 서브넷된다. 실제 얻기 어려운 주소

이다. 형식은 N.N.H.H 이다.

128.1.*.* ~ 191.255.*.*값을 가진다.

3. C 클래스

비교적 얻기 쉬운 주소이다.

형식은 N.N.N.H 이고 192.1.1.*~223.255.255.*값을 가진다.

4. D 클래스

Multicast 주소로 아직 개발중인 클래스이다.

224.*.*.* ~ 239.*.*.* 값을 가진다.

5. E 클래스

실험용으로 쓰이는 주소이다. 240.*.*.* ~ 254.*.*.* 값을 가진다.

참고：0.*.*.*와 127.*.*.* , 255.*.*.* 주소는 일반 IP 주소로는 쓰지 않고 특수

목적에 사용한다. 0.*.*.*는 자신의 네트워크를 지칭하며 127.*.*.*는 실제

가 아닌 가상의 네트워크인 loop back 네트워크를 가리킨다. 255.*.*.*는

broadcast 주소로 쓰인다.

Routing

시스템의 라우팅 테이블에 의한 라우팅이 이루어진다.

netstat 명령어로 라우팅 테이블을 검색할 수 있다.

inhavision.inha.ac.kr> netstat -r -n

Routing tables

Destination Gateway Flags Refs Use Interface

Netmasks:

Inet 255.255.255.0

Route Tree for Protocol Family 2:

default 165.246.10.250 UG 31 1911758 tu0

127.0.0.1 127.0.0.1 UH 1 4 lo0

165.246.10 165.246.10.162 U 8 330973 tu0

1. 라우팅 테이블 관리

(1) 정적 관리

route 명령어를 이용하여 주로 부팅할 때 추가해 준다.

(예) route add net 202.87.240.0 202.87.242.23 1

(2) 데몬에 의한 동적 관리

2. 라우팅 프로토콜

라우팅 프로토콜은 네트워크 사이의 정보 교환을 위해서 라우팅 데몬에 의해

사용되는 것이다.

각 프로트콜은 크게 2가지로 분류된다.

하나는 IGP(Interior Gateway Protocol)이고 다른 하나는 EGP(Exterior

Gateway Protocol)이다.

IGP는 autonomous system(하나의 중앙 제어에 묶인 네트워크 집합)의 라우팅

정보를 관리한다. EGP는 autonomous system들 사이의 라우팅을 관리한다.

EGP에 등록하기 위해서는 InterNIC의 autonomous system으로써 등록해야 한

다.

등록양식은 internic.net의 ftp나 HOSTMASTER@internic.net에 있다.

3. 라우팅 프로토콜의 종류

(1) Routing Infomation Protocol(RIP)

(2) Open Shortest Path First (OSPF)

(3) Interior Gateway Routing Protocol (IGRP)

(4) Exterior Gateway Protocol(EGP)

(5) Border Gateway Protocol(BGP)

(6) Distance Vector Multicast Routing Protocol(DVMRP)

RIP,OSPF,IGRP는 interior 프로토콜이다.

EGP, BGP는 exterior 프로토콜이다.

DVMRP 는 IP 멀티캐스팅 구현 실험에 사용된다.

RIP는 옛 XNS 프로토콜로 IP 네트워크에 채택되어 표준 유닉스 routed 데몬

에 의해 사용된다. cost metric은 hop cou nt로써 패킷이 흐르는 각 기계를 1

hop으로 계산하다. 이유는 경로가 길어지면 RIP가 도달할 수 없는 것으로 인

식하기 때문이다(16router 이상의 길이에선 RIP를 사용하기 힘들다).

OSPF는 최근 많이 쓰이는 새 프로토콜로 크고 복잡한 topology에 잘 동작한

다.

RIP에 비해 여러 장점을 가지는데 하나의 목적지로 여러 경로 관리에 좋은 점,

고수준 라우팅 정보를 공유하는 부분만으로 네트워크 분할이 가능한 점 등이

다.

IGRP는 대중적이지만 점점 사라지는 추세의 프로토콜이다.

EGP는 ARPANET 게이트웨이에 의해 불려진 오래 된 프로토콜로 cost metric

을 이용하며 특정 네트워크 topology를 가정한다. 최근 BGP로 대치되는 추세

이다.

BGP는 EGP에 autonomous 시스템의 복잡한 토폴로지에 대한 지원을 추가한

것이다.

이미지 파일 포맷을 알아보자

2010-02-04T13:10:33+09:00

우리가 컴퓨터를 사용하다보면 늘 접하는 파일 형식들이 있다.

예를 들어, 그래픽의 경우 bmp, gif, jpeg 등을 흔히 접하게 되고, 오디오의 경우 wav, mp3, ra, mid 등의 파일을 쉽게 볼 수 있다.

그러나 겉으로 드러나는 외양은 모두 같아 보이지만 안으로 들어가 보면 각 파일 형식들의 특징과 성격은 매우 다르다는 것을 알 수 있다.

즉, 같은 이미지라 할지라도 어떤 파일 형식은 용량이 크고 어떤 것은 작으며 어떤 것은 화질이 좋고 어떤 것은 그렇지 않는 등의 차이가 있다는 것이다.

그림을 단순히 감상할 때는 이러한 차이가 별 의미가 없지만 이미지를 편집하거나 디스크 공간을 고려한다면 이것은 한번쯤 생각해 볼만한 문제이다.

그래서 오늘 활용은 다양한 그래픽 포맷에 대해 알아보고자 한다.

대체 이렇게 다양한 파일 형식 사이에 어떤 특징과 차이가 있는지를 한번 생각해본다면 그래픽에 한층 자신감이 생길 것이다.

파워 유저로 가는 길은 튼튼한 기초에서 시작한다는 사실을 잊지말기를...

1. BMP

그래픽 데이터는 크게 비트맵 형식과 벡터 형식으로 나누어지는데, 전자는 우리들이 평소 사용하는 형식으로서 픽셀(도트, 혹은 점) 단위로 이미지 정보를 기억하고, 후자는 좌표 단위로 이미지를 기억한다. 쉽게 말하면 비트맵은 모눈종이에 그림을 그린 것이기 때문에 확대/축소를 하면 눈금이 커지거나 작아져서 이미지의 변형이 생기게 되고, 벡터 형식의 이미지는 그 좌표만 기억하기 때문에 확대/축소해도 이미지가 왜곡되는 현상은 일어나지 않는다. BMP는 MS에서 개발된 윈도우 표준의 비트맵 형식으로 윈도우 운영체제의 기본적인 그래픽 포맷이다. 윈도우가 시작되거나 끝날 때 보이는 로고 그림이나 바탕 화면에 보이는 배경 그림은 모두 BMP 형태의 파일이다. BMP는 그림 데이터를 비효율적으로 저장하므로 실제로 필요한 크기보다 큰 파일을 만들게 된다는 단점이 있다. 그러나 바탕 화면의 그림 만큼은 run-length encoding이라는 기법을 써서 크기를 줄이는 것이 가능하다.

2. GIF(Graphics Interchange Format)

웹에서 대부분의 컬러 그림과 배경 그림은 GIF 파일이다. 이 간결한 파일 형식은 적은 색을 쓰는 그래픽에 매우 적당한데, 한때는 온라인에서 가장 널리 쓰이는 파일 형식이었다. 그러나 JPEG 형식이 사진에 사용되면서 GIF는 기반을 잃게 되었다. GIF는 256 색으로 제한이 있는 반면, JPEG은 1천6백만 색까지 표현할 수 있어서 사진과 화질이 거의 같다.

1987년 컴퓨서브에서 개발된 GIF는 별로 주목을 끌지 못한 포맷이었는데, 인터넷의 활용이 늘어나면서 새롭게 부각되었다. 아마 웹에서 유용하다는 이점이 발견되지 않았다면 gif 포맷은 사라졌을지도 모를일이다. GIF87로 불리고 2년뒤 인터레이싱, 투명성, 애니메이션 등의 새로운 기능을 추가한 형식은 GIF89a로 알려져 있다. 사람들은 대개 두개의 GIF 버젼을 구분하지 않으므로 누군가 어떤 그림 형식을 그냥 [GIF]라고 하지 않고 [GIF89]라고 지칭한다면 그것은 애니메이션을 가리키는 것으로 보면된다.

① interlaced GIF

GIF89a 그래픽 표준의 한 특징인 인터레이스 GIF는 한번에 한 줄씩 이미지를 로딩하지 않고 선들이 교차되는 통로에서 이미지를 보여준다. 어떤 그래픽 뷰어와 웹 브라우저를 사용하느냐에 따라, 인터레이스 GIF는 [베네치아 블라인드(venetian blind)] 효과를 내기도 하고 단조로우며 투박한 이미지를 만들기도 한다. 인터레이스 GIF를 사용하는 페이지를 이용하면 적어도 이미지 윤곽을 빨리 볼 수 있다. 그러므로 그 페이지는 인터레이스 GIF를 사용하지 않는 페이지보다 로딩 속도가 빠르다. 인터레이스 GIF를 지원하지 않는 브라우저는 이미지를 보통 GIF 형태로 단순하게 보여준다.

② transparent GIF

GIF89 그래픽 표준의 한 특징인 투명 GIF(transparent GIF)를 이용하면 선택한 이미지의 배경화면을 볼 수 있는데, GIF를 만들 때 디자이너는 이미지 팔레트에서 한 색깔을 투명색으로 지정할 수 있다. 페이지 바탕색을 볼 수 있도록 투명색은 GIF 바탕색에 투과되어 이미지가 페이지에 떠있는 것처럼 보이게 된다.
투명 GIF는 보통 GIF처럼 이미지를 단순하게 보여주지 않는데, 요즘 대부분의 웹 브라우저는 투명 GIF를 지원한다.

3. JPEG(Joint Photographic Experts Group)

이 파일 형식은 많은 색을 사용하는 화상을 위한 것으로, Joint Photographic Experts Group 위원회에 의해 개발되었다. JPEG은 사진과 같이 색상 정보가 많이 들어 있는 그림을 GIF와 같은 유사한 파일 형식에 비해 더 잘 압축하는데, 원래의 색을 상당히 충실하게 보존한다. 따라서 JPEG 파일은 크기가 더 작아져 다운로드 시간과 하드디스크 공간을 절약할 수 있다. JPEG 파일은 압축 정도를 설정할 수 있는데, 압축을 많이하면 할수록 더 많은 색상 정보가 손실되고, 그에 따라 화질도 떨어지게 된다.

# progressive JPEG -위에서 아래까지 한번에 하나의 선만을 나타내는 보통 JPEG와는 달리, 프로그레시브 JPEG는 교차선들 위에서 두 번째 지날 때 선을 채우게된다. 그래픽 뷰어와 웹 브라우저 사용 여부에 따라 프로그레시브 JPEG는 베네치아 블라인드 효과를 내거나, 단조로우며 투박한 이미지를 만들게 되는 것이다. 프로그레시브 JPEG를 사용하는 페이지를 이용하면 적어도 이미지의 윤곽은 볼 수 있다. 또한 프로그레시브 JPEG를 사용하는 페이지는 일반 JPEG를 쓰는 페이지보다 로딩 속도가 빠르다.

대부분의 최신 브라우저들은 새로 선보인 프로그레시브 JPEG를 지원하고 있으며, 만일 브라우저가 프로그레시브 JPEG를 지원하지 않는다면 보통 JPEG 형태로 이미지들을 나타내게 되는 것이다.

4. PCX

PCX는 Zsoft가 자사의 초기 도스 기반의 그림 프로그램인 PC 페인트 브러시용으로 개발한 그래픽 포맷으로, 윈도우 이전까지 사실상 비트맵 그래픽의 표준이었다. PCX는 그래픽 압축시 런길이 코드(run-length code)를 쓰기 때문에 윈도우 표준 BMP보다 디스크 공간을 더 효율적으로 사용한다. 하지만 파일 크기가 크기 때문에 요즘은 잘 사용하지 않는다.

5. TIFF(Tagged Image File Format)

1980년대에 컴퓨터 플랫폼에서 그래픽 파일을 공유하는 것은 큰 골칫거리였다. 때문에 세계 어디에서나 사용할 수 있는 보편적인 그래픽 포맷이 필요했는데, TIFF는 이 문제를 해결할 목적으로 개발되었다. TIFF는 꼬리표가 붙은 이미지 파일 형식이라는 뜻으로 Aldus사와 Microsoft사가 공동으로 개발한 그래픽 파일 형식을 말한다. 이 기종간의 그래픽 데이터 교환을 목적으로 개발된 것으로, 기본적으로는 OS에 의존하지 않고 사용할 수 있어 해상도나 압축 방식 등을 기술할 수 있으며, 단색에서 컬러까지의 화상 데이터를 보존하기 위한 포맷으로 도트 표현 그림을 보존하는데 이용된다. 스캐너용 소프트웨어나 그래픽용 소프트웨어의 대부분이 TIFF 형식을 지원하여, 그레이 스케일(Gray Scale)로 표현된 이미지 파일을 스캐닝하거나 저장, 전송하는 데 널리 사용한다. 매킨토시와 윈도우의 이미지 교환을 위해서 사용하는 포맷이라고 생각해도 무난하다.

6. PICT

미국 애플 컴퓨터의 그래픽 파일 표준 포맷으로서, 대부분의 그래픽 소프트웨어는 이 포맷으로 작성된 파일을 인식할 수 있다. PICT로 보존하면 서로 다른 소프트웨어 사이에서도 데이터 교환이 가능하며, 극적인 효과를 위해 사용한 알파 채널과 이미지의 평범한 흰색이나 검은색 영역들을 압축한다.

7. PICS

미국 매크로미디어사의 멀티미디어 제작 프로그램인 디렉터에서 채용하고 있는 애니메이션용 파일 형식이다. 미국 애플 컴퓨터사의 그래픽 표준 포맷인 PICT 형식의 정지 화면을 하나의 파일에 넣어두고, 디렉터의 지시로 재생, 편집이 가능하다. 동영상 재생 기능을 갖춘 매킨토시용 소프트웨어의 대다수는 옵션으로 이 형식의 파일을 이용할 수 있다.

8. PNG(Portable Network Graphics)

PNG 포맷은 GIF 파일 형식의 문제점을 해결하면서 확장된 기능을 제공하기 위해 고안되었다. 웹에서 PNG는 GIF 파일에 비해 여러 가지 장점을 갖추고 있는데, 그 중에서 중요한 부분만 살펴보면 다음과 같다.
첫째는 GIF 보다 10~30% 정도의 뛰어난 압축률을 제공한다는 것이다.
둘째는 이미지의 투명성과 관련된 알파 채널에서 향상된 기능을 제공하는데, GIF 이미지는 투명 이미지 설정시 단지 한가지 색만을 투명으로 설정할 수 있으나 PNG는 254 수준의 투명성을 허락한다.마지막으로는 트루 컬러, 256 그레이 컬러, 256 컬러를 지원한다는 것이다. GIF 파일 형식은 최대 256 컬러만을 저장할 수 있는 반면, 이것은 트루 컬러(True color)까지 지원할 수 있다. 다만, PNG가 GIF 특성을 대신할 수 없는 것이 하나 있는데, PNG는 다중 이미지를 한 파일안에 저장할 수 없으므로 GIF 애니메이션처럼 애니메이션을 만들 수 없다는 것이 바로 그것이다. gif와 jpg에 이어 새롭게 떠오르고 있는 웹 이미지 포맷이라 할 수 있다.

9. WMF(Windows Meta File)

일반적으로 WMF라는 약자로 부르는 윈도우 메타 파일은 마이크로스프트 응용 프로그램을 위한 객체지향(벡터) 그래픽 파일 형식이다. Windows 환경에서 윈도우를 통하여 화면에 출력되는 그래픽 정보를 GDI 함수로 표현하는 파일이다.

10.RAW(범용)

말 그대로 범용 포맷이다. 응용 프로그램과 컴퓨터 플랫폼 사이에서 문서를 전송할 때 유연성이 뛰어난 파일 포맷이다. 범용 포맷은 파일에 있는 컬러 정보에 대한 내용을 일련의 바이트로 표시한 것이다. 각 픽셀은 2진 포맷으로 0부터 255까지로 표시하는데, 0은 검정색이고 255는 흰색을 의미한다.

자, 어떤가? 이제 여러 가지 그랙픽 포맷에 대한 개념이 좀 잡히는지? 약간은 어렵고 전문가적인 지식이 요구되는 부분도 있지만 개괄적인 특징만 알게 되었다면 오늘의 활용을 공부한 여러분의 노력은 대성공인 셈이다. 더 자세하고 풍부한 내용은 다음 기회에 또다른 강좌를 통해 채워나갈 것을 약속한다.