프로그래밍 팁과 강좌

도메인 네임 서비스

령이 — Thu, 04 Feb 2010 19:05:32 +0900

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

령이 — Thu, 04 Feb 2010 17:23:29 +0900

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

령이 — Thu, 04 Feb 2010 17:22:45 +0900

컴퓨터 네트워크 용어

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

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

다.

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 시스템의 복잡한 토폴로지에 대한 지원을 추가한

것이다.

XLL 이란?

령이 — Thu, 04 Feb 2010 12:56:22 +0900

XLL(eXtensible Linking Language)는 XML 문서를 위한 링크 기술 언어이다.

HTML에 도입되는 링크 기능을 더욱 발전시키고 하이퍼텍스트에 대해 이 후의 연구 결과로 얻은 것이다.

XLL은 HTML의 링크와 동등한 기능을 모두 갖는다. 하이퍼텍스트(hyperText)의 최근 연구 결과에 기본한 6개의 기능을 도입한다.

어떠한 엘리먼트로도 링크를 표현할 수 있다.
링크를 어떻게 처리할 것인지에 대한 정보를 지정할 수 있다.
XML 문서에 전혀 포함되지 않은 리소스를 도입가능 하다.
한 개의 링크가 3개 이상의 리소스를 갖는 것이 가능하다.
리소스와 링크를 분리가능 하다.
쌍방향 링크를 기술할 수 있다.

entity 와 entity 선언

령이 — Thu, 04 Feb 2010 12:50:25 +0900

XML에는 엔터티라는 보조적인 구성이 있다.

엔터티에는 외부 파싱(parsing)되지 않은 엔터티, 외부 파싱된 엔터티, 내부 파싱된 엔터티, 파라미터(parameter) 엔터티가 있다.

1. 외부 파싱되지 않은 엔터티

XML 문서에서는 표현가능 하지 않은 정보, 예를 들면 이미지와 도형을 참조하기 위한 구성이 외부 파싱되지 않은(XML 문법으로 구문해석 되지 않는) 엔터티이다.

외부 파싱되지 않은 엔터티는 엘리먼트의 속성값으로 사용하는 것이 가능하다. 속성값 이외에는 외부 파싱되지 않은 엔터티를 사용하는 것이 가능하지 않다.

DTD에서는 파싱되지 않은 엔터티를 값으로 갖는 속성을 속성 목록 선언의 키워드 ENTITY로 표시한다.

엘리먼트형 '검사'가 속성 '렌트겐'을 갖도록 하는 속성 목록 선언은 아래와 같이 한다.

<!ATTLIST 검사

렌트겐 ENTITY #IMPLIED >

2. 외부 파싱된 엔터티

긴 XML 문서를 복수의 파일로 분할하기 위한 것이 외부 파싱된 (XML 문법으로 구문해석 되는) 엔터티이다.

XML 문서의 일부를 파일로 저장할 때 XML 문서에서 외부 파싱된 엔터티로서 다루는 것이 가능하다.

파일에 없어도 URL로 참조하는 것이 가능하다.

3. 내부 파싱된 엔터티

내부 파싱된 엔터티의 구성은 외부 파싱된 엔터티와 거의 같다. 차이점은 파일을 지정하는 것으로 문자열을 직접 지정하는 것뿐이다.

내부 파싱된 엔터티는 빈번히 사용하는 문자열을 표현하는데 편리하다.

4. 파라미터 엔터티

파라미터 엔터티는 DTD 중에서만 사용 가능한 파싱된 엔터티이다.

파라미터 엔터티를 사용하면 동일한 것을 몇 번 반복 기술하는 것이 아니고 한번의 기술로 가능하다.

파라미터 엔터티에는 내부 파라미터 엔터티와 외부 파라미터 엔터티가 있다.

내부 파라미터 엔터티는 내부 파싱된 엔터티와 같이 문자열을 직접 지정하여 선언한다.

선언할 때는 <!ENTITY 와 파라미터 엔터티명 사이에 '%'가 필요하다. 외부 파라미터 엔터티는 외부 파싱된 엔터티와 같이 URL을 직접 지정한다.

외부 파라미터 엔터티에 대해서도 선언시 '%'가 필요하다.

XML과 SGML의 관계

령이 — Thu, 04 Feb 2010 12:46:38 +0900

XML은 SGML의 서브 집합이다.

시작 태그, 종료 태그, 엘리먼트, 내용, 논리 구조, 속성, 문서형 정의(DTD), 엘리먼트형 선언, 속성 목록 선언, 문서형 선언은 모두 SGML에서도 있다.

XML 선언과 부호화 선언은 SGML에 있는 처리 명령의 특수형으로 도입되고 있다.

SGML을 사용하는 데는 많은 어려움을 느끼는 사람들이 있다. 한가지 이유는 SGML 이라는 규격이 복잡하기 때문이다.

XML은 SGML을 간략히 하여 설계하고 있다. SGML에 있는 기능내 주용하지 않은 명세중 내장 곤란한 것은 XML에서 크게 줄였다.

XML에서는 인터넷 시대에 맞춰 기능이 추가되고 있다.

이들의 기능은 원래 SGML에는 없다. 이중 한가지가 URL이다.

URL에 의해서 외부 파싱된 엔터티(entity)와 외부 파실되지 않은 엔터티를 참조하고 XML 문서의 일부로서 취급하는 것이 가능하다.

또한 DTD를 URL에 의해서 참조하는 것도 가능하다.

적정 형식의 문서를 인식하는 것도 인터넷을 의식한 것이다.

SGML에는 올바른 문서이외는 인식하지 못한다. DTD가 필수적이 아니므로 WWW 서버 측에서 문서 작성시만 DTD를 사용하고 WWW 클라이언트 측에서는 문서만을 배포하고 DTD는 배포하지 않는 것이 가능하다.

클라이언트 측에 XML 문서를 교환하지 않는 경우에 이와 같은 이용 형태는 일반적이다.

XML 과 HTML 의 관계

령이 — Thu, 04 Feb 2010 12:44:51 +0900

HTML도 SGML을 이용하여 규정된 마크업 언어의 한가지이다.

XML은 마크업 언어를 규정하기 위해 일반화한 것이지만 HTML은 한 개의 마크업 언어이다.

HTML은 태그가 사양에서 일미 결정되는데 비해 XML에서는 응용의 요구에 따라 태그를 규정한다.

XML은 HTML을 치환하는 것은 아니다.

표시, 인쇄하기 위한 정보를 세상에 배포하는데는 HTML이 큰 역할을 하고 이후도 널리 사용될 것이다.

마크업 언어를 XML로 규정할 때 HTML에 있는 <ul>, <li> 등의 태그를 가질 수 있다.

범용적인 태그를 정의할 때 가능한 것은 HTML에 맞추면 학습의 부담을 줄일 수 있다.

그러나 문서 전체에 대해 HTML로 거의 충분할 경우에도 임의 특정 부분에 대해 응용 고유의 처리가 필요한 경우가 있다.

문서형 정의를 갖는 XML 문서

령이 — Thu, 04 Feb 2010 12:40:05 +0900

XML에서는 고유하게 태그를 도입할 수 있다.

XML에서는 어떠한 시작 태그, 종료 태그, 공 엘리먼트 태그가 사용되고 어떠한 속성이 사용되는 가를 문서형 정의라는 구조에 의해 규정하는 것이 가능하다.

다시 말하면 한 개의 문서형 정의는 한 개의 마크업 언어를 규정한다. 문서형 정의는 영어로 Document Type Definition(DTD) 이다.

<!ELEMENT 진료기록 (환자, 진료일시, 치료)>
<!ELEMENT 환자 (성, 이름)>

<!ATTLIST 환자 성별 CDATA#REQUIRED

연령 CDATA#REQUIRED

보험증번호 CDATA#REQUIRED

<!ELEMENT 성 (#PCDATA)>

<!ELEMENT 이름 (#PCDATA)>

<!ELEMENT 진료일시 EMPTY >

<!ATTLIST 진료일시 년 CDATA#REQUIRED

월 CDATA#REQUIRED

일 CDATA#REQUIRED

<!ELEMENT 치료 (투약*, 주사*)>

<!ELEMENT 투약 (#PCDATA)>

<!ELEMENT 주사 (#PCDATA)>

1. 엘리먼트형 선언

엘리먼트형 선언은 엘리먼트의 형을 정의하는 것이다.

엘리먼트형 선언에 정의된 엘리먼트형은 시작 태그와 종료 태그의 이름으로서 사용하는 것이 가능하다.

엘리먼트형 선언은 '<!ELEMENT'로 시작하고, 엘리먼트형 내용 모델이 오고 '>'로 끝나는 텍스트이다. 예를 들면 위 예의 1행에 있는 엘리먼트형 선언에서는 엘리먼트형이 '진료기록', 내용 모델이 '(환자, 진료일시, 치료)'이다.

이 선언에 의해서 <진료기록>이라는 시작 태그, </진료기록>이라는 종료 태그가 사용된다.

시작 태그 <진료기록>에서 종료 태그 </진료기록>까지의 텍스트에 의해 표현되는 엘리먼트 내용은 엘리먼트형 '진료기록'에 속한다.

내용 모델은 정의된 엘리먼트형에 속하는 엘리먼트가 어떠한 내용을 갖는가를 기술한다. 이 예에서는 엘리먼트형 '진료기록'에 속하는 엘리먼트의 내용은

엘리먼트형 '환자'에 속하는 엘리먼트

엘리먼트형 '진료일시'에 속하는 엘리먼트

엘리먼트형 '치료'에 속하는 엘리먼트

의 3가지가 이 순서로 병행하여 오는 것을 나타낸다.

다음의 엘리먼트형 선언은 내용 모델 중에 "*"가 사용된다.

<!ELEMENT 치료 (투약*, 주사*)>

이는 0번 이상 반복됨을 나타낸다. 그래서 엘리먼트형 '치료'에 속하는 엘리먼트의 내용은 먼저 엘리먼트형 '투약'에 속하는 엘리먼트가 0번 이상 사용되고, 다음에 엘리먼트형 '주사'에 속하는 엘리먼트가 0번 이상 사용된다.

추가로 만일 '*' 대신 '+'가 사용되면 1번이상 올 수 있음을 나타내고, '*', '+'가 없으면 한번 올 수 있음을 나타낸다.

내용으로 태그 이외의 문자열만을 갖는 엘리먼트의 경우, 엘리먼트형 선언은 다음과 같이 된다.

<!ELEMENT 성 (#PCDATA)>

내용 모델 (#PCDATA)는 일반 문자열을 나타낸다. 즉, 엘리먼트형 '성'에 속하는 엘리먼트의 내용은 간단한 문자열인 것을 나타낸다.

다시 말하면 시작 태그 <성>과 종료 태그</성> 사이에는 간단한 문자열만이 오는 것을 나타낸다.

마지막으로 키워드 EMPTY를 사용한 엘리먼트형 선언을 나타낸다.

<!ELEMENT 진료일시 EMPTY>

이와 같이 선언된 엘리먼트형에 속하는 엘리먼트는 내용을 갖지 않는다.

공 엘리먼트 태그로 표현하면 시작 태그의 직후에 종료태그를 위치하여 표현한다.

이러한 경우, 목록이나 그림, 수식등을 표현할 때도 이와 같이 선언하여 사용할 수 있다.

2. 속성 목록 선언

속성 목록 선언은 어느 엘리먼트형에 속하는 엘리먼트에 대해 이것이 어떠한 속성을 갖는가 정의하는 것이다. 위의 DTD는 다음 속성 목록 선언을 포함한다.

<!ATTLIST 환자

성별 CDATA#REQUIRED

연령 CDATA#REQUIRED

보험증번호 CDATA#REQUIRED

위 속성 목록 선언은 엘리먼트형 '환자'를 나타내는 시작 태그는 3개의 속성을 갖는 것으로 규정한다.

속성명 '성별'과 값, 속성명 '연령'과 값, 속성명 '보험증번호'와 값의 3개이다. 다음의 시작 태그는 이 속성 목록 선언에 따른다.

<환자 성별="남" 연령="38" 보험증번호="12345">

3. 문서형 선언과 올바른(valid) XML 문서

XML 문서는 문서형 선언이라는 구성에 의해 DTD를 참조한다.

예를 들면 루트 엘리먼트의 엘리먼트형이 '진료기록'인 DTD가 C드라이브 바로 아래 record.dtd.라는 파일로 저장되어 있다고 하자.

이것을 참조하기 위해 문서형 선언을 다음과 같이 표시한다.

<!DOCTYPE 진료기록 SYSTEM file:///C:/record.dtd>

문서형 선언은 XML 선언의 바로 아래에 위치한다.

위의 예에서 DTD는 파일로 저장하지만 URL로 참조가능 하므로 네트워크상의 어떠한 위치에도 가능하다.

이 경우 다음과 같이 문서형 선언을 쓴다. 여기서 'SYSTEM'은 해당 DTD가 현재 사용하고 있는 시스템내에 있음을 말하며, 이 대신 'PUBLIC'를 사용하면 이미 공용화된 파일을 참조함을 나타낸다.

<!DOCTYPE 진료 기록 SYSTEM http://Web.medical.ac.kr/record.dtd>

문서형 선언을 갖고 문서형 선언으로 지정된 DTD에 따르는 XML 문서를 '올바른 XML 문서'라 한다.

4. 적정 형식(well-formed)의 XML 문서

XML 에서는 문서가 DTD를 갖지 않아도 인식할 수 있다.

이와 같은 문서를 '적정 형식의 XML 문서'라 한다.

또한 DTD를 갖는 문서에서도 DTD에 따르지 않는 것이 XML 에서는 허용된다.

예를 들면 DTD에 선언되지 않은 엘리먼트형을 사용하는 것이 허용된다. 이와 같은 문서도 적정 형식의 XML 문서이다.

적정 형식의 문서는 문서형 선언을 갖고 있어도 갖지 않은 구성을 할 수 있다.

갖는 경우도 문서형 선언에 지정된 DTD에 따를 필요는 없다. 그러나 필요한 XML의 구문 규칙에 따르는 것이다.

결국 시작 태그와 종료 태그 형식이 올바른 것, 시작 태그를 갖는 속성의 형식이 올바른 것, 시작 태그와 종료 태그의 대응이 올바른 것 등이다.

DTD에 따라서 작성된 올바른 XML 문서에서도 WWW으로 배포된 기존에 편집되지 않은 것이 고려된다.

이 경우 DTD까지 WWW으로 배포될 필요는 없다. 즉, 서버 측에는 올바른 XML 문서이지만 클라이언트 측에는 적정 형식의 XML 문서로

사용된다.

문서형 정의를 갖지 않는 XML 문서

령이 — Thu, 04 Feb 2010 12:39:30 +0900

XML 문서는 문서형 정의를 갖지 않는 문서와 문서형 정의를 갖는 문서로 나눠진다.

<?xml version="1.0" encoding="UTF-8"?>
<진료기록>

<환자 성별="남" 연령="29" 보험증번호="12345">

    <성>홍</성>

    <이름>길동</이름>

</환자>

<진료일시 년="1998" 월="8" 일="15"/>

<치료>

    <투약>비타민B1</투약>

    <주사>페니실린</주사>

</치료>

</진료기록>

1. XML 선언

XML 문서의 선두 행을 XML 선언이라 한다. XML 문서의 선두에 반드시 와야 한다. 이는 XML 문서가 XML 사양 제 1.0버전

에 따르고 UTF-8로 부호화되는 것을 나타낸다.

2. 시작 태그와 종료 태그

시작 태그는 HTML과 같이 "<" 와 ">"로 둘러싼 문자열로 표시된다. 위 예에서는 아래 7개의 시작 태그가 있다.

<진료 기록>, <환자 성명="남" 연령"29" 보험증번호="12345">, <성>, <이름>, <치약>, <투약>, <주사>

또한 종료 태그는 "</" 와 ">"로 둘러싼 문자열이다. 이것도 HTML과 동일하다. 위 예는

</성>, </이름>, </환자>, </투약>, </주사>, </치료>, </진료 기록>

3. 엘리먼트와 내용

시작 태그와 종료 태그는 원칙적으로 1대 1 대응한다. 대응하는 시작 태그에는 종료 태그까지를 '엘리먼트'라 한다. 시작 태그

와 종료 태그에 둘러싼 부분을 '엘리먼트의 내용'이라 한다.

XML에는 종료 태그가 필수이지만 HTML에서는 종료 태그를 생략할 수 있다.

4. 공 엘리먼트 태그

XML에서는 시작 태그와 종료 태그이외에도 HTML에 없는 특별한 태그가 있다. 이것은 "<" 와 "/>"로 둘러싼 문자열이다. 위의 예에서는

<진료일시 년="1998" 월="5" 일="15"/>

이 그 예이다. 이와 같은 태그를 공(empty) 엘리먼트 태그라 한다. 단독으로 1개 엘리먼트를 표시한다. 이 엘리먼트는 내용을

유지하지 않는다.

5. 논리 구조

엘리먼트는 다른 엘리먼트를 포함한다. 예를 들면 <환자 성명="남" 연령="29" 보험증번호="12345">에서 </환자>까지의 테

스트에 의해 표현되는 엘리먼트는

<성>에서 </성>까지 텍스트에 의해서 표현되는 엘리먼트
<이름>에서 </이름>까지 텟스트에 의해 표현되는 엘리먼트

의 2가지를 포함한다. <치료>에서 </치료>가지 텍스트에 의해 표현되는 엘리먼트도 마찬가지이다.

XML 문서에는 루트(root) 엘리먼트로서 최상위 엘리먼트가 반드시 하나 존재한다. 위 예에서는 <진료기록>에서 </진

료기록>까지의 텍스트에 의해서 표현되는 엘리먼트가 이것이다. XML 문서를 구성하는 모든 엘리먼트는 루트 엘리

먼트에 직접적 혹은 간접적으로 포함된다. 즉, XML 문서는 엘리먼트의 계층 구조로 구성된다. 이 계층구조를 '논리

구조'라 말한다.

어느 엘리먼트가 직접적으로 포함하는 엘리먼트를 이의 자식 엘리먼트라 하고, 이 엘리먼트가 직접 혹은 간접으로 포

함하는 엘리먼트를 자손 엘리먼트라 한다. 역으로 임의 엘리먼트를 직접적으로 포함하는 엘리먼트를 부모 엘리먼트

라 하고 간접적으로 포함하는 엘리먼트를 조상 엘리먼트라 한다.

6. 속 성

엘리먼트의 부가적인 성질을 표현하기 위한 것이 속성이다.

속성은 이름과 값에 대하여 시작 태그와 공 엘리먼트 태그의 일부로 표현된다.

위 예에서는 시작 태그 <환자 성별="남" 연령="29" 보험증번호="12345">와 공 엘리먼트 태그 <진료일시 년="1998" 월="5" 일="18"/>이 속성을 갖는다.

이름 '성별'과 값 '남'이 속성이다. 이름 '월'과 값 '5'의 속성, 이름 '일'과 값 '18'이 속성이다.

XML의 위치와 구성

령이 — Thu, 04 Feb 2010 11:55:04 +0900

SGML(Standard Generalized Markup Language)은 문서를 기술하기 위한 언어로, SGML은 ISO에 의해서 1986년에 국제 규격으로 제정되었다.

SGML은 XML보다는 꽤 이전에 존재하고, 고유 태그를 도입하여 Markup 언어를 사용하는데 있어서 XML과 차이점이 없다.

그러나 SGML은 복잡하여 대규모 규격으로 사용되는 것으로 어려운 것으로 알려지고 있다.

HTML이 지금까지 널리 보급된 것은 간단한 태그에 의해 간단히 단락 등을 표현할 수 있는 것이 큰 이유이다.

그러나 HTML은 확장성을 갖지 않는 언어로 문제가 된다.

XML도 또한 SGML에 의해 설계된 언어이다. 고유 태그를 도입하여 Markup 언어를 작성할 수 있는 이점을 가지고 SGML의 복잡성을 대폭 간략

화 하였으며, XML은 HTML과 SGML 양쪽의 장점을 갖춘 언어로 언급된다.

XML 문장은 논리구조와 문서형 정의(DTD)의 2가지 부분으로 구성된다.

XML 문장의 본체는 논리구조 이다. 엘리먼트(element)는 시작 태그와 종료 태그에 의해 표현된다.

두 가지 태그의 사이에 어느 것이든 이 엘리먼트의 내용이고, 이것이 논리 구조를 표현한다.

문서형 정의는 고유 태그를 도입하여 Markup 언어를 정의하는 부분이다. 문서형 정의는 HTML 문서에 포함되지 않지만 XML과 SGML 문서에

는 포함된다. HTML의 경우 HTML 전용 브라우저 내에 문서형 정의가 모두 포함되어 잇는 것으로 언급된다.

XML에 관련된 용어 해설

령이 — Thu, 04 Feb 2010 11:53:23 +0900

CDF (Channel Definition Format) : WWW 페이지의 푸쉬형 배포를 위한 메타 데이터를 표현하는 형식으로 XML로 작성된다.

CDF는 Microsoft사가 중심으로 추진하고 있다.

CSS (Cascading Style Sheet) : HTML 문서 배치(행간, 폰트크기, 색 등)를 지정하는 스타일 시트에 대한 사양으로 W3C에서 제정이 진행되고 있다. 1997년 11월에는 새로운 권고안으로 CSS2가 발표되었다.

CTD (Document Object Model) : HTML 문서, XML 무서, CSS 시트일 시트를 이용하는 응용 프로그램에 대한 인터페이스를 정의하기 위한 사양으로 W3C에서 제정을 추진하고 있다.

Empty 엘리먼트 태그 : 내용을 갖지 않는 엘리먼트를 나타내는 태그로 empty 엘리먼트 태그는 "<"로 시작하고, 다음에 엘리먼트 형이 오고, "/>"로 종료된다.

MathML (Mathematical Markup Language) : 수식을 기술하기 위한 언어로 XML를 이용하여 작성된다. MathML에 의해 기술된 수식을 HTML 문서 중에 이용하는 것으로 하고 있다. MathML은 W3C에서 제정이 추진되고 있다.

MCF-XML (Meta Content Framework using XML) : 확장 가능한 XML언어와 MCF가 사용하는 기본적인 어휘, 용도에 따른 어휘를 확장하는 기능으로부터 구성되고, 메타 데이터의 기술을 위한 강력한 구조이다. Netscape Communication사가 XML을 가지고 MCF를 수정하여 W3C에 제안하였다.

SGML (Standard Generalized Markup Language) : 구조화 문서를 표현하기 위한 국제규격(ISO/IEC 8879)이다. SGML은 1986년에 제정되었고, 주로 메뉴얼 등의 전자출판에 이용되고 있다.

SMIL (Synchronized Multimedia Integration Language) : WWW상의 멀티미디어 데이터를 구성하여 표현을 기술하기 위한 언어로 W3C에서 제정을 추진하고 있다. SMIL 표현은 WWW상의 텍스트, 음성, 정지화상, 동화상등의 데이터를 이용한다. SMIL도 XML에 기본하고 있다.

W3C (World Wide Web Consortium) : WWW관련 사양의 제정 활동을 행하는 비영리 단체이다. XML, XLL, XSL, RDF, DOM, HTML, HTTP, CSS 등의 중요한 사양이 W3C에서 제정되었다.

XLL (eXtensible Linking Language) : XML 문서의 링크를 기술하기 위한 언어이다. XLL은 W3C에서 제정이 추진되고 있다.

XML (eXtensible Markup Language) : 확장 가능한 마크업 언어로 SGML의 근대화된 부분 집합이다. XML은 W3C에서 제정이 추진되고 있다.

XML-Data : 논리 구조를 가지고, 네트워크 구조에 관련된 데이터를 WWW상에서 교환하기 위해 Microsoft사가 정한 사양이다. XML-Data에는 데이터와 메타 데이터로 기술하는 언어로서 XML을 사용한다.

XML 선언 : XML 문서의 선두에 위치하는 선언으로 XML 선언에는 XML 사양의 버전, 문서의 부호화 방식 등을 기술한다.

XML 파서 : XML 문서를 해석하고, 속성을 갖는 엘리먼트의 트리 구조를 작서하는 프로그램이다. 응용 프로그램은 XML 문서를 직접 취급하는 것이 아니고, 파서가 생성한 트리 구조를 취급한다.

XML 파서는 XML 문서가 적정 형식인가 아닌가의 검증과 올바른 것인가 아닌가를 검증한다.

XSL (eXtensible Stylesheet Language) : XML 문서의 스타일 시트를 기술하기 위한 언어이다. XSL은 W3C에서 제정이 진행되고 있다.

구조화 문서 : 배치 정보에 대신하여 논리 구조를 갖는 문서이다. 배치에 관한 정보는 논리구조에서 자동적으로 생성된다. 구조화 문서에서는 문서를 작성할 때 배치의 명세에 대해 고려할 필요가 없기 때문에 문서를 효율 좋게 작성하는 것이 가능하다.

내부 entity : XML 문서 중에 위치하는 entity로 내부 entity는 텍스트로 참조된다.

내용 : 엘리먼트의 시작 태그와 종료 태그사이에 있는 엘리먼트와 문자 데이터이다.

내용 모델 : 엘리먼트형 선언의 일부로서 엘리먼트가 어떠한 내용을 갖는 것이 가능한지를 기술한다.

논리구조 : 문서가 논리적으로 어떻게 분할되는가를 나타내는 것으로 XML 에서는 엘리먼트의 계층 구조가 논리 구조이다.

로케이터 : 리소스를 참조하기 위해 지정하는 것으로, 간단한 로케이터는 URL이다.

로케이터 엘리먼트 : XLL의 확장 링크의 로케이터를 표현하는 엘리먼트이다.

속성 : 엘리먼트에 부가된 이름과 값의 조합으로 구성된다. 속성은 엘리먼트의 시작 태그 중에 명과 속성값의 사이에 '='를 갖는 형식으로 표현된다.

리소스 : WWW상에 있는 정보로 URL로 참조 가능하다.

링크 : 2개 이상의 리소스를 관련 짓는 것으로 HTML에서는 A(Anchor) 엘리먼트가 링크를 표현하지만, XML에서는 XLL 언어를 이용하여 링크를 표현한다.

링크 엘리먼트 : XLL 링크를 표현하는 엘리먼트 이다.

마크업 언어 : 텍스트에 마크업(예를 들면 태그를 삽입)을 행하는 문서를 기술하기 위한 언어이다. HTML은 마크업 언어이지만 XML과 SGML은 마크업 언어를 정의하기 위한 메타 언어로 마크업 언어 자체는 아니다.

메타 데이터 : 데이터에 대한 데이터로 WWW상의 문서에 대한 메타 데이터는 문서의 URL, 문서의 갱신 시간간격, 문서의 작성자명 등 여러가지가 고려되고 있다.

문서형 선언 : XML 문서에서 DTD를 참조하기 위한 선언이다. 문서형 선언은 XML의 URL, 문서의 갱신 시간간격, 문서의 작성자명 등 여러가지가 고려되고 있다.

배치 정보 : 문서가 페이지와 컬럼 등이 표시 영역에 어떻게 분할되는가를 나타내는 것이다. 예를 들면 그림과 표가 어떠한 페이지의 어떠한 위치에 놓이는가 등의 정보를 배치 정보라 한다.

속성 목록 선언 : DTD중에 위치하는 선언으로 속성 이름과 값에 대해 기술한다.

스타일 시트 : 구조화 문서를 어떻게 배치할 것인가를 지정한 것이 스타일 시트이다. HTML을 위한 스타일 시트로서는 CSS가 W3C에서 제정되고 있고, XML을 위한 스타일 시트로는 XSL이 W3C에서 제정되고 있다.

시작 태그 : 엘리먼트의 시작 위치를 나타내기 위해 문서중에 삽입하는 태그이다. "<"로 시작하고 다음에 엘리먼트 명이 오고 ">"로 종료한다. 엘리먼트 형과 ">"의 사이에는 속성의 이름과 값의 조합이 몇 개라도 기술될 수 있다.

Entity : XML 문서의 내부 또는 외부에 위치하는 텍스트 또는 2진 데이터로 XML 문서중에서는 entity 참조에 의해서 참조되는 것을 총칭한다. entity를 참조하는데는 먼저 DTD에서 entity를 선언할 필요가 있다.

Entity 선언 : XML 문서에서 entity 참조에 의해 참조하는 텍스트 또는 2진 데이터를 미리 DTD내에 선언하는 것이다.

엘리먼트 : XML문서를 구성하는 단위로, 시작 태그와 선두 문서로부터 종료 태그의 끝 문자까지가 하나의 엘리먼트 이다. 내용을 갖는 엘리먼트로 부터 공(empty)엘리먼트 태그로 표현하는 것도 가능하다.

엘리먼트형 : 엘리먼트 형 선언에 의해서 선언된 이름으로, 선언된 이름은 시작 태그, 종료 태그, 공 엘리먼트 태그에 사용된다.

엘리먼트형 선언 : DTD중에 선언되는 것으로 엘리먼트 형과 내용 모델을 기술한다.

올바른 문서 : 문서형 선언을 갖고, 문서형 선언에 지정된 DTD에 따르는 XML 문서이다.

외부 entity : XML 문서의 외부에 위치한 entity이다. 외부 파싱된 entity 와 외부 파싱되지 않은 entity의 두가지 종류가 있다.

외부 파싱된 entity : XML 문서의 외부에 위치한 entity로 텍스트로서 참조된다.

외부 파싱되지 않은 entity : XML 문서의 외부에 위치한 entity로 이진 데이터로 참조된다.

이름공간 : 다른 DTD에서 정의된 이름을 동일 문서에 혼재하기 위한 구성으로 XML에서 중요한 차기 확장 항목이다.

적정 형식 문서 : 올바른 XML 문서와 비교되는 것으로, 모든 XML 문서를 가르킨다. 적정형식의 문서는 올바른 XML 문서이외 DTD를 갖지 않는 XML 문서와 DTD에 따르지 않는 XML 문서를 포함한다.

종료 태그 : 요소의 종료 위치를 표현하기 위해 문서 중에 삽입하는 태그로, "</"로 시작하고, 다음에 엘리먼트 명이 위치하고, ">"로 종료한다.

파라미터 entity : DTD로부터 참조되는 entity로 내부 파라미터 entity와 외부 파라미터 entity의 두 종류가 있다.

포맷터 : 논리 구조를 갖는 문서와 스타일 시트를 입력하여 배치를 행하는 프로그램이다. 포맷터에 의해 생성된 문서는 표시/인쇄가 가능하다.

표준 링크 : XLL에서 정한 두 종류의 링크내에서 보다 간단한 링크이다. HTML 링크를 기본으로 하여 기능을 확장한 것이다.

푸쉬형 모델 : WWW 페이지의 배포에 있어서 서버와 브라우저의 역할 분담 모델의 한 가지이다.

푸쉬형 모델에서는 WWW 페이지를 언데 배포할 것인가를 결정하는 것은 서버측이다.

Microsoft사의 Internet Explorer 4.0에서는 CDF를 사용하여 푸쉬형 모델에 의해 WWW 페이지의 배포를 실현하고 있다.

풀형 모델 : WWW 페이지의 배포에 있어서 서버와 브라우저의 역할 분담 모델의 한 가지이다. 풀형 모델은 WWW 페이지를 언데 배포할 것인가 결정하는 것은 WWW 브라우저를 사용하는 사용자이다.

XML 의 정의와 특징

령이 — Wed, 03 Feb 2010 20:38:34 +0900

HTML은 국제 표준인 SGML에서 파생되어 나온 언어이고, HTML의 딜레마는 SGML을 완전히 지원하지 못하는 데 있다.

SGML 신봉자들이 SGML 그 자체로는 웹상에서 그대로 적용하기는 힘들다는 것을 깨닫고 XML을 탄생시켰다.

결국 XML은 SGML의 간략화된 버전으로서, SGML의 실용적인 부분집합으로 볼 수 있는 언어이다.

즉 SGML의 장점들을 최대한 수용하는 한편 웹상의 응용을 용이하게 하기 위하여 SGML의 특정 부분을 발췌, 요약 처리하여 학습과 어플리케

이션 상에서의 구현을 쉽게 할 수 있도록 만든 것이다.

XML은 SGML의 장점을 계승한 언어이다.

따라서 SGML이 가지고 있는 확장(Extensibility), 구조(Structure), 검증(Validation)의 특성을 고스란히 계승하고 있다.

이는 바로 XML이 HTML과 다른 특징이자 장점이다. 이를 좀 더 자세히 본다면, XML은 다음과 같은 장점을 가지고 있다.

1. 정보 제공자는 자기 마음대로 새로운 태그 세트와 속성을 정의할 수 있다. 즉 사용자가 자신의 편의에 따라 혹은 자신의 데이터를 구분하고자, 새로운 태그 세트를 임의로 만들 수 있다.

2. 문서의 구조는 연속적인 중첩을 허용한다. 즉 XML은 HTML이 지원하지 않는 객체 지향적 구조 혹은 데이터베이스 스키마의 구성을 위해 필요한 여러번의 중첩을 허용하고 있다.

3. 문서 구조의 검증이 필요한 어플리케이션을 위하여 문법적인 구별을 문서 안에서 제공할 수 있다. 즉 어플리케이션이 어떠한 문서를 받아들일 때 그 문서의 오류를 쉽게 판단할 수 있게 된다.

사실 위에 제시된 특징들은 모두 SGML의 특징이자 장점이다. 다만 XML은 SGML의 모든 장점을 그대로 상속받고, 이를 조금 더 배우기 쉽고, 표현하기 쉽고, 응용하기 쉽도록 제작된 언어인 것이다.

HTML Document 구조태그

령이 — Wed, 03 Feb 2010 19:12:29 +0900

위의 태그들은 html로 작성된 문서의 구조를 표시하기 위해 사용된다.
<html>태그는 문서가 HTML로 작성된 것을 표시하는 것으로
문서전체의 가장 처음과 마지막에 위치한다.
<head> 태그안에는 문서의 제목이나 특징, 제작자의 정보등
문서에 관한 정보를 기술한다. 이속에 기술된 정보는 <title>~</title>로
같혀진 텍스트 외에는 화면에 출력되지 않는다.
그리고 <body>~</body>태그 안에 들어있는 내용이 브라우저에 표시되는
문서가 된다. 이 태그들의 순서가 바뀌어서는 안된다.

HTML 태그 명령어 //

령이_ — Tue, 02 Feb 2010 14:08:44 +0900

HTML 명령어 정리

<TITLE>웹브라우저의 윈도우 타이틀 바의 제목</TITLE>

<BR>한 줄을 띄어 준다.

<HR>줄 긋기

<HR SIZE=n>두께 n 픽셀

<HR WIDTH=n>길이 n 픽셀

<HR ALIGN=[LEFT, RIGHT, CENTER]>[왼쪽,오른쪽,가운데]정렬

<CENTER>...</CENTER>문단의 가운데에 정렬

주석달기

<BLINK>깜빡거리는 문자</BLINK>

<EM>강조화면상에서 이탤릭체</EM>

<STRONG>EM보다 강한 강조로 볼드체로 보인다.

<VAR>변수 이름을 표시할 때 사용, 이탤릭체로 표시</VAR>

<CITE>부분인용 택으로 화면상에서 이탤릭체로 표시

<DFN>용어 정의 택으로 화면상에서 볼드체로 표시</DFN>

<KBD>사용자 키보드 입력으로 사용자가 입력하는 글꼴은 고정폭문자로 화면에 표시 된다.</KBD>

<CODE>타이핑한 컴퓨터 프로그램 코드를 표시할 때 사용하는 택으로 화면상에는 고 정폭 문자로 표시</CODE>

<U>목록의 아이템 작성

<DIR>주로 디렉토리의 리스트 등을 표시</DIR>

<IMG SRC="그림파일이름.GIF또는JPG" ALIGN=[TOP, MIDDLE, BOTTOM]>그림의 [윗부분

,가운데, 아래와 글의 윗부분]에 글을 정렬

<IMG SRC="그림파일이름.GIF또는JPG" ALT="그림설명“>그림을 볼수 없을 때 그림 대 신 ALT로 지정해문 문자를 화면에 표시함

<BODY BGCOLOR="#ffffff TEXT="#??????"LINK="#??????"VLINK="#??????"

ALINK="#??????"BACKGROUND="그림파일.JPG>#코드 값의 색을 바탕색, 본문, 링크

,방문한 링크, 활성화 링크색, 배경그림으로 지정

<TABLE BORDER=n CELLSPACING=n WIDTH=n HEIGHT=n>테두리 두께 n, 셀간격n, 가로

세로50인 표

<FRAME SRC="파일명“>이미지나 URL을 지정한다.

<FRAME SRC="파일명.HTML" NAME"...">지정된 프레임을 부르고 그 분활된 창의 이름 을~~~로 지정한다.

<...TARGET...>NAME으로 지정한 분활된 창을 조절한다. 예를 들면 링크를 시키거나 그림을 부를 때 분활된 상태에서 TARGET을 지정하면 TARGET에 해당 하는 창에서 URL이 나타나거나 그림을 불러올수 있다.

<FRAME SCROLLNG="[YES, NO, AUTO]">분활된창의 스크롤 바를 지정, 없앰, 자동선택