거의 고지에 다왔다.

이젠 우리가 만든 코드를 실제 FPGA보드에 올릴 차례다!

우리가 예상한데로 된다면 불이 반짝반짝 들어오는 Digital Clock이 완성되겠지!ㅋ

 

이젠 제일 아래를 선택하자. Configure Target Device라고 쓰여있다. 여기서 코드를 타겟 보드에 맞게 바꾸나 보다.

 

이거 뭔 말인지 잘 모르겠더라. 그냥 OK누르고 있으면 알아서 진행된다.

 

오 잘 됐다. 올 클리어다.ㅋ 쉽네??

잘 되었으면 창이 넘어가면서 칩 그림 두개가 뜬다. 오른쪽이 우리가 넣을 칩이고 왼쪽은 플래시메모리다.

우리는 일단 왼쪽에 넣어야 한다. 우클릭하고 Program을 누르자.

근데 에러가 뜨는 경우가 많다. 왜 그런지 잘 모르겠다. 아래 그림처럼 옆을 선택하고 Erase를 한 후에 다시 Program을 눌러보자.

 

에러 없이 잘 됐는가? 그럼 이제 불이 반딱 거릴 것이다.!!ㅋ

아 좋다.ㅋ

세번째 단계는 신스사이즈라고 불리는 단계이다.

컴파일과 거의 비슷한데 생성되는 코드가 타겟 보드 코드이며 실행되는 프로그램 형태가 아닌 게이트의 역할을 바꾸는 코드를 생성한다는 것이다. 사실 잘 모른다. 그냥 이렇게 이해하고 있다.

암튼 코드를 생성했으니 다음 단계는 Synthesize 단계이다. Coding->Synthesize라고 생각하면 된당.

 

Synthesize는 의외로 간단하다. Synthesize – XST를 더블 클릭하거나 그림처럼 우클릭해서 RUN을 선택하면 된다.

 

위 그림과 같이 녹색 체크바가 생성되었다면 성공!

다음 단계는 포트 연결인데 우리가 만든 코드는 외부와 데이터를 주고 받으려면 당연하겠지만 포트를 설정해줘야 한다.

Verilog Code에도 생성해 놨는데 anode와 seven_seg 변수가 그것이다. 아무튼 아래 그림과 같이 RUN을 선택한다.

 

 

그리고 아래 그림처럼 포트를 설정하는데 포트에 대한 정보는 해당 제품 매뉴얼을 봐야 한다.

 

Default 값으로 놔두고 그냥 OK선택하면 Synthesize와 Port설정은 끝이 난다.

프로젝트를 생성했으면 소스를 추가 해야지ㅋ

아래에 있는 VerilogHDL소스가 원본이기 때문에 알아서 컴파일 해보도록.

아무튼 에러없이 잘 작동하는 Verilog코드가 있다면 바로 FPGA에 구울 수 있다.

일단 소스를 추가 해줘야겠지? 작성된 소스를 Add 시킬 수도 있지만 난 New Source를 하겠다.

 

우리는 Verilog 코드를 쓸것이기 때문에 Verilog Module을 선택한다. 이름은 맘대로 하고~

 

포트 설정 페이지인데 아직 할 필요 없다 그냥 Next~

 

코드 파일이 생성되었다. 이제 이 파트의 마지막 단계다.

 

마지막 단계는 당연히 코드를 써넣는 거겠지? 아래 소스가 있으니 쉽게 할 수 있을 듯 하다.

'Programming > hdl' 카테고리의 다른 글

Digital Clock - FPGA(04 프로그램 올리기)  (0) 2010.04.10
Digital Clock – FPGA(03 Synthesize)  (0) 2010.04.10
Digital Clock – FPGA(01 프로젝트 생성)  (0) 2010.04.10
Digital_Clock TestBench  (0) 2010.04.10
D F/F Verilog  (0) 2010.04.07

오늘 짰던 Digital_Clock Verilog Code를 FPGA로 굽는 작업을 했다.

기억하기 좀 복잡해서 복습하면서 모든 사진을 다 찍었다. ㅋㅋ

일단 보자! (너무 길어서 파트별로 짤랐당ㅠㅠ)

 

나는 Xilinx ISE 10.1 버전을 사용했다.

이 것을 사용하면서 좀 어이없었던 것은 소스가 다 맞는데도 synthesize가 되지 않았다는 것이다.

(자꾸 알 수 없는 오류가 생겼다.)

그래서 프로젝트를 다시 생성했더니 잘 되더라…. 옆에 나를 가르쳐주던 형한테 물어보니…

원래 그런다더라ㅋㅋ 꼬물ㅋㅋ

암튼 위 그림처럼 먼저 프로젝트를 생성한다. 그리고 Next 클릭

 

위 그림은 프로젝트를 생성할 때 우리의 보드 정보를 입력해주는 곳이다. 나는 Sprtan3를 사용하고 XC3S200을 사용하기 때문에 위처럼 설정하고 Next를 클릭하자.

 

위 세 그림은 별로 설정할 것이 없다. 그냥 next, next 클릭하면 끝!

프로젝트 생성 완료!

'Programming > hdl' 카테고리의 다른 글

Digital Clock – FPGA(03 Synthesize)  (0) 2010.04.10
Digital Clock – FPGA(02 소스추가)  (0) 2010.04.10
Digital_Clock TestBench  (0) 2010.04.10
D F/F Verilog  (0) 2010.04.07
Computer Design - Digital Logic  (0) 2010.03.20
한 페이지에 소스 두개 안올라간다 -_-;
어쩔 수 없이... 두개의 페이지에ㅋㅋㅋ


'Programming > hdl' 카테고리의 다른 글

Digital Clock – FPGA(03 Synthesize)  (0) 2010.04.10
Digital Clock – FPGA(02 소스추가)  (0) 2010.04.10
Digital Clock – FPGA(01 프로젝트 생성)  (0) 2010.04.10
D F/F Verilog  (0) 2010.04.07
Computer Design - Digital Logic  (0) 2010.03.20
Socket 모듈을 짜던 중. 오류를 한글로 뿌려줄 필요가 있었다. 근데 코드 번호가 정수이므로 변수 하나를 지정해 놓고 문자열을 싹 밀어 넣은 다음에 스위치로 하나씩 빼질 필요가 있었다. 근데 이렇게 할경우 많은 메모리를 차지하게 된다. 그래서 enum을 이용한 문자열 가져오기를 생각하게 되었다. 근데 이게 C++에서는 원래 불가능 하다. 그래서 사람들이 여러가지 방향으로 돌려서 사용하는 법을 만들었는데 아직도 잘 모르겠더라... 일단은 사용만 하고 분석은 나중에 하는 방식으로;;


'Programming > 이것저것' 카테고리의 다른 글

[Design Pattern] Singleton Pattern  (2) 2010.04.16
typeid 연산자  (1) 2010.04.15
ASCII Table  (0) 2010.04.05
사용자 정의 exception (1)  (0) 2010.03.21
Handshking  (0) 2010.03.19
SOC 설계 시간에 처음 짜본 Verilog HDL 코드입니다. 1bit D Flip/Flop(이하 D F/F)를 짰는데요. 처음 해봐서 그런지 되게 어려웠다는.......
Design Module을 짜고 다시 Test Bench까지 만들었습니다. 아래는 그 소스들이구요 결과 사진도 첨부를 했음ㅋㅋㅋ
겨우 10줄 내외의 소스인데 되게 어려웠다는??;;;
우리 플젝은 수천줄은 될텐데 어떻게 만들지?? ㅎㄷㄷ.....

기억할 것!
1번 module에서 시작해서 endmodule로 끝난다.
2번 negedge(negative edge), posedge(positive edge)
3번 테스트 벤치에서 output은 wire이고 input은 reg이다.

Design Module: DFF.v


Test Bench: test_DFF.v


'Programming > hdl' 카테고리의 다른 글

Digital Clock – FPGA(03 Synthesize)  (0) 2010.04.10
Digital Clock – FPGA(02 소스추가)  (0) 2010.04.10
Digital Clock – FPGA(01 프로젝트 생성)  (0) 2010.04.10
Digital_Clock TestBench  (0) 2010.04.10
Computer Design - Digital Logic  (0) 2010.03.20
iPoom에 들어갈 스마트폰 알림 모듈을 만들어야 했는데
문제는 통신을 통해 데이터를 받는게 아니라 진동일줄이야 -_-;;;
TCP/IP 모듈은 한 시간만에 만들었는데 햅틱이 하루 넘게 걸렸ㅠㅠㅠㅠㅠ
암튼 그래서 블로깅함... 나중에 쉽게 하려고 -_-;

일단 옴니아2 SDK를 받아야 하는데 여기를 참조해 보세욤ㅋ(승환햄 블로그)
저기서 SDK받아서 Visual Studio에서 설정해주고......

Windows Mobile 6 Professional SDK Refresh과
Windows Mobile 6.5 Professional Developer Tool Kit (USA)를 받아서 설치하고......
(둘중에 하나만 설치해도 될지 모르지만.... 귀찮아서 걍 설치함ㅋ)
또 Visual Studio에서 Include경로, Library경로 설정해주고.

또 http://happyworm.egloos.com/2724751를 참조해서 Active Sync나 Device Center를 깔고, 옴니아 드라이버도 깔고....
(뭐가 이렇게 깔게 많냐!!) 암튼 몽땅 다 깔면 드디어 옴니아 프로그래밍 가능합니다.

진동 예제 소스


위 처럼 하면 쉽게 햅틱을 할 수 있다.. 진짜 쉽나??
아 헤더 파일은
#include <smiSDK.h>
#include <smiHaptics.h>
#pragma comment( lib, "SamsungMobileSDK_2.lib" )
이 세개다

'Programming > __etc' 카테고리의 다른 글

고수님들..  (0) 2011.12.15
C2146 구문오류  (0) 2010.03.18
패킷 만들기  (0) 2010.03.18
인터넷에서 찾기 귀찮아서 -_-;
블로그에 올려야징 -_-ㅋㅋ


'Programming > 이것저것' 카테고리의 다른 글

typeid 연산자  (1) 2010.04.15
enum 문자열  (0) 2010.04.09
사용자 정의 exception (1)  (0) 2010.03.21
Handshking  (0) 2010.03.19
Sliding Window  (0) 2010.03.19
어느 날 운영자님께서 물으셨지....
모스알아?? 네 저 그거 땄는데요?? 
MOSS라고 쳐봐.....;;;
네;;;;;

그때 부터 Windows Server2008 과 MOSS, AD, Exchange Server 와의 동거가 시작될 줄이야;;;
왐마;;;
몇 일간 Windows 64bit로 Exchange 2008과 MOSS로 삽질하다가.....
32bit로 갈아타라고 해서;;; 다시 삽질 반복......
Exchange 서버와 MOSS는 웬만하면 한 서버에 같이 깔지 않는 다는 것을 알고 좌절;;
그걸로 2주간 삽질했는데ㅠㅠ

MOSS 설치 Exchange 설치 20번 넘게 해본듯;;ㅋㅋㅋ
그래서 두개의 설치 메뉴얼을 만들었습니다. 현재는 MOSS 카페에만 올려놨는데 여기다가도 올려야겠네요.

자 그럼 이제 시작하도록 하겠습니다.!
안녕하세요. moltak 입니다. 이번에 진행할 내용은 사용자 정의 Exception 입니다. 

이번 칼럼은 (1) exception 만들기 (2) stl exception 사용하기 (3) stl exception 확장하기 순서로 진행하겠습니다.

C++을 사용할 때 예외처리를 하기 위해 try/catch를 사용하시죠? C에서는 if를 사용하겠죠.
자 일단 STL exception 을 한번 보시죠.


STL exception은 exception 클래스를 상속받아 사용됩니다. 가장 많이 사용하는 exception으로 bad_alloc이 있죠. 
exception 은 좋긴 하지만 정확한 정보를 얻기에는 조금 힘이들죠. exception을 사용하는 방법은 다음에 보도록 하고 여기서는 자신만의 exception class를 만들어 exception 이 발생했을 때 더 많은 정보를 얻도록 해보조.

일단은 자신만의 클래스를 하나 만드는 것이 좋겠죠? 저는 KException 으로 지었습니다. 그리고 아래와 같이 만들었죠.


하지만 우리는 많은 정보를 넣어야하죠. 제가 넣고 싶은 정보는 [Exception Message], [Exception Function], [Exception Line]입니다. 그것들을 받을 수 있게 다시 작성하였습니다.

위에 코드를 잠깐 설명하자면 생성자에서 [exception 종류], [exception 함수], [exception 라인]을 받아서 단순히 저장하는 역할 을 하고 있습니다. 그리고 이것들을 저장시킬 수 있는 멤버 변수들을 선언했고 m_Message에 exception 내용들을 저장해서 what() 함수에서 리턴해 주는 역할 을 하고 있습니다. 일단 예외를 발생 시켜 보죠.


위와 같이 하면 ex.what() 함수가 실행되면서 사용자 정의 메시지와, 에러가 난 함수, 그리고 라인을 볼 수있습니다.
__FUNCTION__ 과 __LINE__ 은 각각 함수와 라인을 보여 주는 매크로입니다.

근데 현재 KException는 아직 조금 부족합니다. 사용자가 what의 출력을 다르게 해주고 싶다거나 다른 변수를 넣고 싶은 경우가 있을 수 있는데 KException은 확장이 조금 어렵죠. STL Exception 을 보면 exception 클래스를 상속받아 여러가지 다른  exception 들이 존재한다는 것을 알 수 있습니다. 우리도 그렇게 만들어 보죠.

KException_File 클래스를 만들었습니다. KException_File클래스는 KException 클래스를 상속받아 구현되며 KException은 
virtual const char* what() = 0; 클래스를 만들어 추상 클래스로 만들었습니다. 이제 KException은 인스턴스화 되지 못하고 다만 자식 클래스의 인스턴스를 사용할 때만 사용됩니다. 

위와 같이 클래스 멤버 함수를 정의했습니다. 이제 어느 정도의 확장성은 가질 수 있게 되었네요. 아직 한참 더 만들어야 하지만.ㅋㅋ exception 이 발생했을 때는 아래와 같은 방법으로 받으면 되죠.

이와 같은 방법으로 자신만의 exception을 만들어서 사용 할 수있습니다. design pattern을 넣어서 조금 더 멋지게 만들면 나중에 사용하기 좋겠네요. 지금은 이쯤에서 마치도록 하겠습니다. 그럼 즐프하세요.

'Programming > 이것저것' 카테고리의 다른 글

enum 문자열  (0) 2010.04.09
ASCII Table  (0) 2010.04.05
Handshking  (0) 2010.03.19
Sliding Window  (0) 2010.03.19
CISC & RISC  (0) 2010.03.18
교재(Advanced Digital Logic Design -> Sunggu Lee)

Combinational Logic = 현재의 출력이 현재의 입력에 의해서만 영향 받음(memory element 없음)
Sequential Logic = Combinational Logic + memory element
대부분의 Digital System은 Sequential Logic이다.

F/F = edge-triggered memory element
Latch = level-triggered memory element

hazard = Glitches가 생기는 현상.
static hazard, dynamic hazard

Glitches - 노이즈, 삐침
setup-time: edge 직 전 0.1ns(공정에 따라 다름)
hold-time: edge 직 후 0ns-0.01ns(공정에 따라 다름)
setup-time, hold-time때는 D입력이 valid 해야한다. (값이 유지되고 있어야 한다.)
setup-time, hold-time때 D입력이 valid 하지 못한 상태를 Meta-stable 상태라 한다.

glitches가 clock이나 reset에 들어가면 큰 문제가 되지만 D단자에 들어 갔을 경우에는 큰 문제가 생기지 않는다. setup-time, hold-time 때문에 큰 영향을 미치지 않음.

delay 종류 2개
게이트의 입력에서 게이트의 출력까지 지연되는 시간: propagation delay
전선에서의 지연 시간: wire delay

D F/F = Delayed F/F
보통 propagation delay 의 시간이 hold-time에 비해 10배 정도 길기 때문에 위험하지 않다.

Logic Synthesis = VHDL을 해석해서 로직을 만들어 줌.(컴파일러)
S/W = state state 마다 실행됨. sequential 하고 Delay 개념이 없음
H/W = 모든 state 가 동시에 실행됨. parallel 하다. delay 개념이 있다.(wire delay, propagation delay)


'Programming > hdl' 카테고리의 다른 글

Digital Clock – FPGA(03 Synthesize)  (0) 2010.04.10
Digital Clock – FPGA(02 소스추가)  (0) 2010.04.10
Digital Clock – FPGA(01 프로젝트 생성)  (0) 2010.04.10
Digital_Clock TestBench  (0) 2010.04.10
D F/F Verilog  (0) 2010.04.07

TCP는 두 호스트들 간에 정보를 전달하기 전에 접속이 먼저 필요하다. 그 때 3Way Handshaking 이라는 방법이 필요하게 된다.

보통 위 그림과 같은 방법이다. 그림을 보면 화살표 세개가 있는 것을 알 수 가 있다. 저게 3Way Handshaking이다. 데이터를 전송하기 전에 서로 연결 설정을 해야하는데 그 때 필요하게된다. TCP 프로토콜을 사용한다면 무조건 저 방법으로 접속을 한 후 데이터 전송이 이루어지게 된다.

두 호스트가 접속을 끊을 때는 4Way Handshaking을 사용한다.

둘이 데이터를 전송하고 있었다고 가정하자. 클라이언트가 전송이 다 되었다고 FIN/ACK를 보낸다.
① B는 A에게 종료 요청의 메시지를 담은 FIN 패킷을 전송한다.
② A는 B에게 종료메시지 FIN을 주는 것이 아닌 응답을 받았다는 의미로 ACK 패킷을 보낸다. 이것은 A가 자신은 아직 끝날 준비가 되지 않았다는 것이다.
③ A는 B에게 자신도 종료할 준비가 다 됐다는 뜻으로 FIN 패킷을 보낸다.
④ B는 알았다는 의미인 ACK를 보내는데 이 후 둘의 연결은 종료된다.

'Programming > 이것저것' 카테고리의 다른 글

ASCII Table  (0) 2010.04.05
사용자 정의 exception (1)  (0) 2010.03.21
Sliding Window  (0) 2010.03.19
CISC & RISC  (0) 2010.03.18
CISC, RISC, CRISC(EPIC)  (0) 2010.03.18
패킷이 전달될 때 버퍼가 사용이 된다는 것은 다들 알고 있을 것이다. 하지만 데이터 순서가 어떻게 되는지 어떤 방식으로 전송이 되는지에 대해서는 잘 모를 수도 있다. TCP와 같이 데이터 전송에 대해 보장하는 프로토콜 같은 경우는 슬라이딩 윈도우 라는 방식을 사용한다. 그럼 이게 무엇인지 부터 알아보자. 아래는 위키 백과에서 긁어온 내용이다.

슬라이딩 윈도

위키백과 ― 우리 모두의 백과사전.

슬라이딩 윈도(Sliding window)는 두 개의 네트워크 호스트간의 패킷의 흐름을 제어하기 위한 방법이다.

TCP와 같이 데이터의 전달을 보증하는 프로토콜에서는 패킷 하나하나가 전달되었음을 확인 신호(acknowledgement, 이하 ACK)를 받아야하며, 만약 패킷이 중도에 잘못되었거나 분실되어 확인받지 못하는 경우, 해당 패킷을 재전송해야하는 필요가 있다. 슬라이딩 윈도는 일단 '윈도(메모리 버퍼의 일정 영역)'에 포함되는 모든 패킷을 전송하고, 그 패킷들의 전달이 확인되는대로 이 윈도를 옆으로 옮김(slide)으로서 그 다음 패킷들을 전송하는 방식이다.

슬라이딩 윈도는 아직 확인을 받지 않고도 여러 패킷을 보내는 것을 가능케 하기 때문에, 매번 전송한 패킷에 대해 확인을 받아야만 그 다음 패킷을 전송하는 방법(stop-and-wait)을 사용하는 것보다 훨씬 네트워크를 효율적으로 사용할 수 있다.

http://ko.wikipedia.org/wiki/슬라이딩_윈도


쉽게 풀어 써보겠다. 우리가 100바이트의 데이터를 전송한다고 가정해 보자. send함수를 호출하면 전송될 데이터가 전송이 되는 것이 아니라 전송측 버퍼에 저장되게 된다. 그리고 수신측 연락을 기다린다. 왜냐면 수신측 버퍼가 비어있어야 데이터를 전송하면 받을 수 있기 때문이다. 수신측에서 버퍼가 30바이트 비었다고 보내라고 하면 송신측에서 30바이트를 전송한다. 또 수신측에서 50바이트를 받을 수 있다고 하면 송신측에서는 50바이트를 보낸다. 이런 식으로 데이터가 전송이 되게 된다. 


이때 송,수신측 버퍼는 모두 커널에 의해 생성된다.

'Programming > 이것저것' 카테고리의 다른 글

사용자 정의 exception (1)  (0) 2010.03.21
Handshking  (0) 2010.03.19
CISC & RISC  (0) 2010.03.18
CISC, RISC, CRISC(EPIC)  (0) 2010.03.18
펜티엄부터 린필드 i5까지, 인텔 어떻게 걸어왔나  (0) 2010.03.18

C, C++ 소스를 올리려는데 가독성이 너무 안좋군요... 예전 블로그는 어떻게 하는 지 잘 몰랐는데...
티스토리는 정보가 많더군요. 우허허허허ㅋ 그래서 검색했습니다.

http://withrobot.tistory.com/180 여기서 참조를 했습니다.

우리의 목표는 바로 아래 화면ㅋㅋ



자 그럼 시작해 볼까요.
순서는 withrobot 님과 동일 합니다.

설치 방법은 3단계.
1. 다운로드 받아 압축 풀기
2. 티스토리의 스킨에 업로드
3. 스킨 수정하기

1. 다운로드 받아 압축풀기
SyntaxHighLighter의 홈페이지, 다운로드
압축을 해제 하면 아래 그림과 같이 세개의 폴더가 나옵니다.


2. 티스토리의 스킨에 업로드
네 이젠 Scripts 폴더와 Script 폴더에 있는 모든 파일을 올려야 해요.
티스토리의 관리자로 이동해서 스킨탭의 HTML/CSS 편집을 선택해 주세요.

스킨 탭의 HTML/CSS 편집으로 들어가서

파일 업로드를 선택해 주세요


Scripts 폴더와 Styles 폴더의 파일을 모두 업로드해주세요.
전 근데 IE8에서는 업로드가 안되더라구요? 그래서 IE7에서 작업했습니다.


3. 스킨 수정하기
이젠 HTML/CSS를 편집해야 할 차례입니다.
다시 스킨탭에서 HTML/CSS 편집을 선택합니다.
위에 밑줄친 부분에 <link type="text/css" rel="stylesheet" href="./images/SyntaxHighlighter.css"></link> 를 삽입합니다.

그 다음 옆의 슬라이드 바를 끝까지 내리면
</body>
</html> 로 끝나는 것을 확인할 수 있다.

</body> 앞에 다음 문장을 추가한다.

<script class="javascript" src="./images/shCore.js"></script>
<script class="javascript" src="./images/shBrushCSharp.js"></script>
<script class="javascript" src="./images/shBrushCpp.js"></script>
<script class="javascript" src="./images/shBrushCss.js"></script>
<script class="javascript" src="./images/shBrushDelphi.js"></script>
<script class="javascript" src="./images/shBrushJScript.js"></script>
<script class="javascript" src="./images/shBrushJava.js"></script>
<script class="javascript" src="./images/shBrushPhp.js"></script>
<script class="javascript" src="./images/shBrushPython.js"></script>
<script class="javascript" src="./images/shBrushRuby.js"></script>
<script class="javascript" src="./images/shBrushSql.js"></script>
<script class="javascript" src="./images/shBrushVb.js"></script>
<script class="javascript" src="./images/shBrushXml.js"></script>
<script class="javascript">
dp.SyntaxHighlighter.ClipboardSwf = '/flash/clipboard.swf'; 
dp.SyntaxHighlighter.HighlightAll('code');
</script>


자 수고 하셨습니다. 이제 글 쓰시면 되요. 마쳤으면 [저장하기] 버튼을 클릭하고 블로그 화면이 원래대로 나오는지를 확인한다.

자 이제 적용 단계이다.

아쉽게도 위지윅 모드에서 바로 적용하는 방법은 없다. 글을 쓰다가 소스 코드를 넣고 싶은 부분에서 메뉴바에 [EDIT] 버튼을 클릭하여 HTML 편집 모드로 전환한다. 그 다음 다음과 같은 문장을 추가한다.

<textarea name="code" class="Python" cols="60" rows="10">
코드는 여기에 복사한다.
</textarea>

http://withrobot.tistory.com/180 님이 python을 하셨기 때문에 저도 그렇게ㅋㅋㅋ 저 부분을 C++이나 C로 입맛에 맞게 바꿔 주세요.
수고 하셨습니다. 이젠 http://moltak.tistory.com/entry/Server-Socket-1 처럼 만들 수 있을 겁니다. 즐프 하세요~

http://jobdahan.net/server_window/17286


DNS 서버는 자신의 컴퓨터 인터넷 연결 IP Address와 밀접한 관계가 있습니다.

다른 서버들(웹 서버, 데이타베이스 서버, FTP 서버 등)은 자신의 컴퓨터 연결 IP Address가 변경되더라도
각 설정 파일들에 대해 별다른 수정없이 서비스 받고 있는 도메인의 IP Address만 Update 해주면 해결되지만
DNS 서버의 경우에는 그렇지 않습니다.

DNS 서버(BIND9, Windows에서는 ISC BIND 서비스)의 경우에는 서비스 받고 있는 도메인의 IP Address Update
뿐만이 아니라 설정 파일도 변경된 IP Address로 수정해서 BIND9을 재시작 해주어야만 합니다.

가정에 설치된 PC에 서버를 구축하였을 경우 유동 IP를 사용하기 때문에 IP 주소가 자주 변동될 수 있으므로
그에 대한 대책을 마련해야만 합니다.

그 대책의 하나는 자신의 IP 주소가 변경되면 DNIP 사이트에서 서비스 받고 있는 네임서버 도메인
(예 : ns.jobdahan.dnip.net)의 IP 주소를 업데이트 해주어야 하며,

둘째로 DNS 서버가 구축되어 있다면 개별 도메인 zone 파일(예 : jobdahan.dnip.net.zone)에 설정된
각 도메인에 대한 IP 주소도 업데이트 해주어야만 합니다.

우리는 네임서버 도메인을 DNIP 사이트에서 서비스 받고 있으므로 자신의 IP 주소가 변경되었을 경우
DNIP 사이트에 IP 주소를 업데이트 해주면 되는데 그 방법은 이미 “유동 IP를 고정 IP처럼 사용하기” 강좌에서
DNIP.exe를 이용하여 자동으로 업데이트하는 방법을 자세히 설명했었습니다.

DNS 서버는 원래 고정 IP인 곳에 설치하여야만 합니다만 지금 우리는 고정 IP가 아닌 유동 IP인 곳에
DNS 서버를 설치하였습니다. 그렇기 때문에 인터넷 연결 IP 주소가 변경되면 DNS 설정 파일에 있는 IP 주소도
변경시켜 주어야만 하는 약간의 불편함은 감수해야 합니다.

DNS 설정 파일에 있는 IP 주소를 업데이트 해주는 방법으로는 직접 수동으로 설정 파일의 IP 주소를 수정하는 방법과
\bin 디렉터리에 들어가 있는 nsupdate.exe를 이용하는 방법,
그리고 자체 제작한 소프트웨어로 IP 업데이트에 관련된 모든 작업을 자동으로 하는 방법이 있습니다.

여기에서는 수동으로 설정 파일의 IP 주소를 수정하는 방법에 대해서 설명하기로 하겠습니다.


[ 직접 IP Update ]

1) 변경된 인터넷 연결 IP 확인하여 서비스되고 있는 네임서버 도메인 IP 업데이트
 ~ 공유기를 사용하고 있을 때 내 컴퓨터 인터넷 연결 IP 주소를 확인하는 가장 간단한 방법으로는
     FTP 서버인 Hub FTP 창을 열어 [IP 확인] 도구를 클릭해서 자신의 인터넷 연결 IP 주소를 알아 보거나
     Port_Check.exe 같은 소프트웨어를 이용해서 알아 보는 방법이 있습니다.

     (cmd 창의 ipconfig 명령은 공유기를 사용하지 않고 있을 때 인터넷 연결 IP 주소 확인이 가능하지만,
     공유기를 사용하고 있을 때는 공유기의 사설 IP Address(192.168.xxx.xxx)가 표시됩니다.)

     내 컴퓨터의 인터넷 연결 IP Address와 서비스 되고 있는 ns.ID.dnip.net의 IP Address가 서로 다를 경우
     DNIP.exe를 이용하거나 http://www.dnip.net/update.cgi에서 IP Address를 업데이트 해 줍니다.

2) 개별 도메인 설정 zone 파일 수정
 ~ 자신의 IP 주소가 변경되었을 때 설정 파일 중 수정해 주어야 할 부분은 개별도메인 설정 파일인
     HostName.zone(HostName : ns.ID.dnip.net에서 "ns."을 제외한 이름, HostName.zone ⇒ 예:jobdahan.dnip.net.zone)
     파일만 수정하면 됩니다.

     C:\APM_Setup\Server\DNS\etc\ 디렉터리에 있는 jobdahan.dnip.net.zone 파일을 메모장이나 텍스트 에디터로
     열어 설정되어 있는 IP 주소를 모두 변경된 IP 주소로 수정하고 저장합니다.

     예를 들어 자신의 외부 IP 주소가 210.95.205.15에서 210.95.205.105로 변경되었다면
     아래의 내용과 같이 IP 주소가 들어간 부분만 210.95.205.15 ⇒ 210.95.205.105로 수정하고 저장합니다.

C:\APM_Setup\Server\DNS\etc\jobdahan.dnip.net.zone 파일의 내용

$TTL 43200
@ IN SOA ns.jobdahan.dnip.net. root.jobdahan.dnip.net. (
                   2007042710 ;                 ⇒ 이 네임서버의 데이타 버전, 현재 년월일시간으로 수정함
                   3H  ;
                   15M  ;
                   1W  ;
                   1D )  ; 
; Name Server
    IN NS ns.jobdahan.dnip.net.  ;
    IN A 210.95.205.15  ;                       ⇒   IN A 210.95.205.105  ;
; Host name
ns IN A 210.95.205.15  ;                       ⇒   ns IN A 210.95.205.105  ;
; Virtual Host
www IN A 210.95.205.15  ;                   ⇒   www IN A 210.95.205.105  ;
mail IN A 210.95.205.15  ;                    ⇒   mail IN A 210.95.205.105  ;
ftp IN A 210.95.205.15  ;                       ⇒   ftp IN A 210.95.205.105  ;
shop IN A 210.95.205.15  ;                   ⇒   shop IN A 210.95.205.105  ;


3) zone 파일의 Reload 또는 DNS 서버(ISC BIND 서비스)의 재시작
 ~ [시작]-[실행]-cmd 입력하여 cmd 창을 열고, rndc reload 명령을 입력하고 [Enter] 키를 치면
    C:\APM_Setup\Server\DNS\etc\ 디렉터리에 있는 모든 구성 파일들과 zone 파일들이 다시 읽혀져서
    변경시킨 내용들이 DNS 서버에 적용되어 집니다.

명령 프롬프트(cmd) 창

C:\Documents and Settings\hats> rndc reload
server reload successful

C:\Documents and Settings\hats> _


    여기에서 한 가지 알아 두셔야 할 점이 있습니다.
    위와 같이 cmd 창에서 rndc reload 명령을 사용해서 named 데몬을 제어할 수 있는 이유는
    앞서 name.conf 내용 설정에서 named 데몬이 rndc.key 파일의 key 값을 사용하고 있고,

    named 데몬을 제어하는 rndc는 rndc.conf 파일에서 불러온 key 값을 사용하는데
    rndc.key 파일과 rndc.conf 파일의 key 값을 동일하게 해 주었기 때문에 rndc로 named 제어가 가능한 것입니다.


[ DNS 서버(ISC BIND 서비스)의 재시작 ]

설정 파일이 수정되었을 때 rndc reload 명령을 이용하지 않고
DNS 서버 자체를 재시작 해주어도 수정한 업데이트 내용이 DNS 서버에 적용됩니다.

윈도우에서 DNS 서버(BIND9)를 재시작하여 주는 방법에는 다음의 두 가지가 있습니다.

첫째, [시작]-[제어판]-[성능 및 유지관리]-[관리 도구]를 선택, [서비스]를 더블클릭하여 열린 서비스 창에서
ISC BIND 라는 이름의 서비스를 찾아 오른쪽 클릭, 단축메뉴에서 [다시 시작]을 선택하면 ISC BIND 서비스가
중지되었다가 다시 시작됩니다.

둘째, cmd 창에서 다음의 명령 실행에 의해서도 DNS 서버(BIND9)를 재시작 할 수 있습니다.
       net stop "ISC BIND" : DNS 서버(BIND9)의 중지
       net start "ISC BIND" : DNS 서버(BIND9)의 시작

명령 프롬프트(cmd) 창

C:\Documents and Settings\hats>net stop "ISC BIND"
ISC BIND 서비스를 잘 멈추었습니다.

C:\Documents and Settings\hats>net start "ISC BIND"
ISC BIND 서비스를 시작합니다..
ISC BIND 서비스가 잘 시작되었습니다.


C:\Documents and Settings\hats>_


[ nsupdate.exe를 이용한 개별도메인 zone 파일 설정 Update 하기 ]

nsupdate.exe를 이용하는 방법에 대해서는 설명을 생략하기로 하겠습니다.
처음에는 이 부분에 대한 설명도 하려고 했었지만 이 방법 역시 수동적인 방법에 속하고
DNS 서버에 대해서 익숙치 않은 분들에게는 오히려 혼란만 줄 것 같아서 과감히(?) 생략했습니다.^^;

꼭 알아야 겠다는 분들이 계시다면 댓글을 달아 주시거나
관련 전문 서적을 참고하시기 바랍니다.


위와 같이 수동으로 작업을 해 주어도 되지만 이러한 일련의 작업들 즉, 외부 인터넷 연결 IP 주소가 변경되었는지
부팅할 때 마다 검사하고, 변경되었으면 개별 도메인 설정 zone 파일인 jobdahan.dnip.net.zone 파일의 내용 중
설정되어 있는 IP Address만 수정시켜 저장한 후 그 zone 파일을 reload 해주게 할 수 있는 소프트웨어를 만들어
동작하게 하면 아주 유용하겠지요?

BIND9의 설정파일들을 생성하거나 IP Address를 업데이트하는 소프트웨어를
PHP나 Delphi, C++ 등으로 만들 수 있을 것입니다.

여러분들께는 윈도우 명령 셸을 이용하여 BIND9의 모든 설정 파일들을 쉽게 생성하고 IP Update를 할 수 있는 배치 파일
(BINDzSet.cmd)을 배포하도록 하겠습니다.


아래의 기능 소개를 읽어보시고 유용하다는 생각이 드시면 이 글의 댓글로

"BINDzSet.cmd 신청합니다."라고 반드시 신청한 다음에
쪽지 보내 주시기 바랍니다.

그런데요...
DNS 서버가 설치되지 않았다면 이 배치 파일은 아무 소용없지 않겠습니까?
그래서 현재 자신의 서버에 BIND9이 설치되어 있어서 서브 도메인이 설정된 분들께만 드리고자 합니다.
(현재 이 강좌를 통해 DNS 서버를 구축한 분들이 몇 분이나 되는지 파악하고 싶어서이니 널리 양해 해주시길!^^;)

배치 파일 신청 방법은 먼저 앞서 설명한 방법으로 댓글을 올리신 다음 자신의 FTP 서버에 사용자 계정을 하나 만들고
아래의 내용을 저(ID : hats)에게 쪽지로 보내 주시기 바랍니다.

 1) FTP 사용자 계정 ID와 Password( 예 : 아이디 named, Password 2345 )
 2) 접속할 FTP 주소( 예 : ftp.xxx.dnip.net )
 3) 접속할 수 있는 시간대( 예 : 18:00~19:00 )
(파일이 업로드된 것을 확인 후 FTP 계정은 삭제하거나 Password를 변경하시기 바랍니다.)

사용방법은 아래에도 설명되어 있지만 BINDzSet.cmd 파일을 시스템 Path를 지정해 놓았던
C:\APM_Setup\Server\DNS\bin\ 디렉터리에 넣은 다음 cmd 창을 열고 BINDzSet만 입력하십시오.
그러면 아래 내용과 같은 도움말이 나올 것입니다.

BINDzSet.cmd를 사용해 보시면 아시겠지만
명령 중 옵션 입력이 잘못되었을 때에는 그 상황에 맞는 도움말이 자세히 나오게 되어 작성되어 있습니다.
사용법을 익히시지 않더라도 도움말만 보면 쉽게 사용할 수 있을 것입니다.(저의 생각일 뿐...)

Windows OS에 DNS 서버(BIND9)을 설치한 후 설정 파일들을 만들어야 할 때
BINDzSet 명령 한 줄 입력할 때마다 입력한 설정 파일이 자동으로 만들어 질 것입니다.
그리고 곧 바로 그 설정 파일의 내용을 확인해 보실 수 있으며,
BIND9을 재시작시켜 변경 내용을 적용시킬 수 있습니다.

혹시, 좀 더 자세한 사용법 설명이 필요하시다면 댓글 달아 주십시오.
BINDzSet.cmd 사용법 설명 글 올리도록 하겠습니다.

BINDzSet.cmd는 여러분의 환경에 맞게 수정하시고 사용하셔도 됩니다.
단, 다른 곳에 올리지는 말아 주세요.-.-;
윈도우 명령 셸을 공부하시는데에도 도움이 될 것이라 여겨집니다.

앞에서 설명한 [ 직접 IP Update ]의 [2]와 [3] 항목은 BINDzSet.cmd를 사용한다면
다음과 같이 2번의 명령 실행으로 간단히 해결될 것입니다.

BINDzSet Dzone jobdahan.dnip.net 210.95.205.105 2007062015 shop
BINDzSet restart


배포 받는 과정이 귀찮으시다구요?
에~구!
그럼, 저도 할 수 없죠!^^;


[ BINDzSet 사용법 ]
*****************************************************************************************
  명령 형식 : BINDzSet [설정파일명] [HostName] [IP] [Serial] [subD1 [subD2...[subD5]]]
*****************************************************************************************
  ㅇ [설정파일명] : rndc, named.ca, localhost.zone, named.local, named.conf, Dzone 중 하나
  ㅇ [Host Name]  : 네임서버도메인(ns.ID.dnip.net)에서 "ns."을 제외한 이름 ID.dnip.net
  ㅇ [IP]         : 내 컴퓨터의 인터넷 연결 IP 주소  ex) 210.95.205.15
  ㅇ [Serial]     : 이 네임서버의 데이타 버전, 현재 년월일시간으로 정함  ex) 2007050101
  ㅇ subD1 subD2  : 설정할 서브도메인 이름(공백으로 구분해서 5개까지 추가 가능)
                     www, mail, ftp, pds, blog는 기본으로 설정됨  ex) shop cafe commu 등
---------------------------------------------------------------------------------------------------
[ 실행 예 ]
[1] rndc.key, rndc.conf 파일 생성하기
     BINDzSet rndc           ⇒rndc.key 파일과 rndc.conf 파일을 생성
     BINDzSet rndc view   ⇒ 생성되어 있는 rndc.key, rndc.conf 파일 내용 보기

[2] named.ca 파일 생성하기
     BINDzSet named.ca           ⇒ named.ca 파일을 생성
     BINDzSet named.ca view   ⇒ 생성되어 있는 named.ca 파일 내용 보기

[3] localhost.zone 파일 생성하기
     BINDzSet localhost.zone           ⇒ localhost.zone 파일을 생성
     BINDzSetlocalhost.zone view   ⇒ 생성되어 있는 localhost.zone 파일 내용 보기

[4] named.local 파일 생성하기
     BINDzSet named.local           ⇒ named.local 파일을 생성
     BINDzSet named.local view   ⇒ 생성되어 있는 named.local 파일 내용 보기

[5] named.conf 파일 생성하기
     BINDzSet named.conf ID.dnip.net           ⇒ named.conf 파일을 생성
     BINDzSet named.conf view                   ⇒ 생성되어 있는 named.conf 파일 내용 보기

[6] 개별도메인 Zone 파일 생성하기
     BINDzSet Dzone ID.dnip.net xxx.xxx.xxx.xxx 2007050215 shop cafe commu
          ⇒ "ID.dnip.net.zone"이라는 파일명을 갖는 개별도메인 Zone 파일을 생성
               xxx.xxx.xxx.xxx : 인터넷 연결 IP Address, 2007050215 : Serial,
               shop, cafe, commu : 생성시킬 2차 도메인(www, mail, ftp, pds, blog는 기본으로 생성됨)
     BINDzSet Dzone ID.dnip.net view     ⇒ 생성되어 있는 개별도메인 Zone 파일 "ID.dnip.net.zone"의 내용 보기

[ 부가 기능 ]
(1) 내 컴퓨터 인터넷 연결 IP 확인
     BINDzSet ipcheck

(2) BIND9 재 시작
     BINDzSet restart
---------------------------------------------------------------------------------------------------
[ 사용 환경 ]
 1. 이 파일의 이름은 BINDzSet.cmd 이며, Windows용 배치 파일이므로 cmd창에서 실행합니다.
 2. BINDzSet.cmd 파일과 bindzset 폴더를 시스템 Path가 설정되어 있는 C:/APM_Setup/Server/DNS/bin/
    디렉터리에 넣어두고 사용하십시오.
    - bindzset 폴더에는 named.root, Port_Check.exe 파일이 들어가 있어야 합니다.

 3. BIND9이 C:/APM_Setup/Server/DNS/ 디렉터리에 설치되어 있는 환경에 맞게 배치 파일 스크립트가
    작성되어 있으므로 환경이 다를 경우 BINDzSet.cmd를 수정하여 사용하면 됩니다.
    또한 C:/APM_Setup/temp/ 디렉터리도 사용하고 있음을 참고하십시오.
    물론 이 강좌의 내용대로 하셨다면 수정 없이 그대로 사용하시면 됩니다.
 4. BINDzSet의 실행하는 위치는 시스템 Path가 설정되어 있으므로 아무 디렉터리에서나 실행하면 됩니다.

http://jobdahan.net/server_window/17274


현재는 BIND9이 설치되면서 윈도우즈 서비스에 ISC BIND라는 이름으로 등록은 되어 있지만
실행이 되지 않고 있는 상태입니다. 이 ISC BIND 서비스를 시작시켜 주어야 Windows XP가 부팅되면서
named 데몬이 자동으로 실행되게 됩니다.
(Windows XP에서 BIND9의 프로세스 이름은 named.exe이며 서비스 이름은 ISC BIND입니다.)

[시작]-[제어판]-[성능 및 유지관리]-[관리 도구]를 선택하여 관리 도구 창이 열리면
그 곳에서 [서비스]를 더블클릭하여 서비스 창을 엽니다.

그 서비스 창에서 ISC BIND 라는 이름의 서비스(상태 필드에 “시작됨”이라는 글자가 표시되지 않은 상태입니다.)를 찾아
오른쪽 클릭하여 단축메뉴에서 [속성]을 선택하면 ISC BIND 속성 창이 열립니다.
(이 속성 창을 여는 경로를 잘 기억해 두시기 바랍니다.)

아래의 그림과 같이 ISC BIND 속성 창의 [로그온] 탭을 클릭합니다.

BIND9을 설치하면서 로그온 계정 이름을 named라 하고 암호를 입력했을 것입니다.
그렇기 때문에 현재는 .\named 사용자 계정으로 선택되어져 있습니다.

이 .\named 라는 사용자 계정을 다음의 방법으로 로컬 시스템 계정으로 변경시켜 주어야만
named 데몬을 시작할 수 있게 됩니다.

아래의 왼쪽 그림과 같이 .\named 사용자 계정으로 선택되어 있는 상태를 [로컬 시스템 계정]으로 변경시키고
반드시 [적용] 버튼을 클릭합니다. 적용이 되면 [적용] 버튼은 비활성화 상태로 표시됩니다.

그 다음 오른쪽 그림과 같이 [일반] 탭을 클릭하고 “서비스 상태 :”라는 글자 바로 아래에 있는 [시작] 버튼을 클릭합니다.
서비스를 시작 상태를 나타내는 아래와 같은 서비스 제어 창이 열렸다가 자동으로 닫힐 것입니다.

서비스 제어 창이 닫히고 [시작] 버튼이 비활성화 상태가 되면 [ISC BIND 서비스]가 시작된 것입니다.

만약, 아래 그림과 같은 메시지가 나오면서 ISC BIND가 시작되지 않을 경우
[로그온] 탭에서 로컬 시스템 계정으로 변경시킨 다음 [적용] 버튼을 누르지 않은 채로 [일반] 탭에서 [시작] 버튼을
눌렀기 때문입니다.(저는 이 것 때문에 스트레스 엄청 받았었는뎅... 여러분들은 저 같은 실수 안 하시겠죠?)


이제 지속적인 서비스 실행이 되었으니 [확인] 버튼을 눌러 ISC BIND 속성 창을 닫고,
서비스 창에서 ISC BIND가 서비스되고 있는 상황을 보면
아래 그림과 같이 “시작됨”, “로컬 시스템”이라는 글자가 보일 것입니다.

[Ctrl+Alt+Del] 키를 눌러서 Windows 작업관리자 창의 [프로세스] 탭에서도 확인할 수 있습니다.
Windows 작업관리자 창의 프로세스 탭에서 named.exe라는 프로세스가 보일 것입니다.


현재 DNS 서버가 구동되어 네임 서비스를 하고 있는 중이며,
다음부터는 부팅하게 되더라도 자동으로 ISC BIND 서비스가 시작될 것입니다.
즉, DNS 서버가 동작하게 된다는 말이 되겠지요?


이제 ISC BIND를 서비스로 등록했으므로 실제 동작을 확인하기 위해서 서버 컴퓨터를 재부팅하여
다시 동작을 확인해 보도록 하십시오.

[6. BIND9 동작 테스트]의 3) 네임서버 질의 명령어 nslookup으로 확인, 4) ping 명령으로 전송 응답 테스트 과정을
다시 시도하여 마무리 동작 테스트하시길 바랍니다.


드디어 Windows XP에 DNS 서버(BIND9)을 모두 설치하고 설정한 다음
정상적인 동작까지 될 수 있도록 서비스 등록까지 하여
네임서버를 구동시켰으며 현재 네임 서비스를 하고 있는 중입니다.

http://jobdahan.net/server_window/17272


DNS 서버인 BIND9을 본격적으로 구동시키기에 앞서 지금까지 설치/설정한 모든 사항들이 실제적으로 정상적인
동작을 하고 있는지 테스트 해 볼 것입니다.

DNS 서버의 데몬(named.exe)을 명령 창(cmd)에서 임시 실행시켜서 에러 유무 확인,
프로세스 창에서 실행된 데몬 확인,
네임서버 질의 명령어 nslookup으로 서브 도메인의 IP 주소 확인 및 ping 명령어로 전송 응답 테스트를 하여
DNS 서버(BIND9의 named)가 정상적으로 동작하고 있는지 확인합니다.


 1) 명령 창(cmd)에서의 named.exe 실행

   C:\APM_Setup\Server\DNS\bin\ 디렉터리에 named.exe 파일이 있는데
   그 디렉터리는 미리 Path를 설정해 주었으므로 cmd 창에서 현재 디렉터리를 이동시키지 않고
   곧 바로 named.exe를 실행할 수 있습니다.

   [시작]-[실행]-cmd 입력하여 cmd 창을 열어서 named.exe -g 라는 명령어를 입력하고 Enter 키를 치면
   아래와 같은 실행 상태가 보여 지고 C:\Documents and Settings\hats>라는 프롬프트가 표시되지 않은 채
   맨 아래에 커서가 깜박거리면서 named 데몬이 실행됩니다.

명령 프롬프트(cmd) 창(에러없이 실행된 예)

C:\Documents and Settings\hats>named -g

30-4-2007 13:58:28.986 starting BIND 9.4.0 -g
30-4-2007 13:58:29.002 found 2 CPUs, using 2 worker threads
30-4-2007 13:58:29.002 loading configuration from 'C:\APM_Setup\Server\DNS\etc\named.conf'
30-4-2007 13:58:29.002 listening on IPv4 interface Loopback Interface 1, 127.0.0.1#53
30-4-2007 13:58:29.002 listening on IPv4 interface TCP/IP Interface 2, 192.168.2.12#53
30-4-2007 13:58:29.017 automatic empty zone: 127.IN-ADDR.ARPA
30-4-2007 13:58:29.017 automatic empty zone: 254.169.IN-ADDR.ARPA
30-4-2007 13:58:29.017 automatic empty zone: 2.0.192.IN-ADDR.ARPA
30-4-2007 13:58:29.017 automatic empty zone: 255.255.255.255.IN-ADDR.ARPA
30-4-2007 13:58:29.017 automatic empty zone: 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0
.0.0.0.0.IP6.ARPA
30-4-2007 13:58:29.017 automatic empty zone: 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0
.0.0.0.0.IP6.ARPA
30-4-2007 13:58:29.017 automatic empty zone: D.F.IP6.ARPA
30-4-2007 13:58:29.017 automatic empty zone: 8.E.F.IP6.ARPA
30-4-2007 13:58:29.017 automatic empty zone: 9.E.F.IP6.ARPA
30-4-2007 13:58:29.017 automatic empty zone: A.E.F.IP6.ARPA
30-4-2007 13:58:29.017 automatic empty zone: B.E.F.IP6.ARPA
30-4-2007 13:58:29.033 command channel listening on 127.0.0.1#953
30-4-2007 13:58:29.033 ignoring config file logging statement due to -g option
30-4-2007 13:58:29.049 zone 0.0.127.in-addr.arpa/IN: loaded serial 1997022700
30-4-2007 13:58:29.049 zone localhost/IN: loaded serial 42
30-4-2007 13:58:29.049 zone jobdahan.dnip.net/IN: loaded serial 2007042710
30-4-2007 13:58:29.049 running
_

   실행 상태를 보고 에러가 있는지 확인합니다. 만약 에러가 있으면 그 메시지를 확인하시고 설정 파일을 꼼꼼히 확인해 주시기
   바랍니다. 위의 경우는 에러가 없이 실행된 상태의 한 예입니다.

   [주의] 이 때 cmd 창을 닫으면 named 데몬의 실행이 중지되어 버립니다.
              그러므로 동작 테스트가 끝날 때까지 반드시 cmd 창을 닫지 않도록 합니다.
              커서가 깜박거리고 있는 그대로 그냥 놔 두십시오.^^;

   [참고] 분명 모든 구문을 이상 없이 입력해 주었는데도 zone 파일을 정상적으로 읽어 들이지 못해 동작이 되지 않는 경우가
   있을 수 있습니다. 아마 텍스트 에디터로 편집하면서 파일의 끝에 들어가는 보이지 않는 코드 때문이지 않았는지 짐작만 할
   뿐입니다. 그렇지만 스트레스는 받지 마십시오. 해결 방법이 없겠습니까?

   아래와 같은 에러 메시지가 나올 경우에는 해당되는 파일을 아예 삭제하시고,
   에러난 파일을 이번에는 메모장을 이용하여 처음부터 다시 입력하여 만드시길 바랍니다.

named.local:11: file does not end with newline
dns_rdata_fromtext: jobdahan.dnip.net.zone:17: unexpected end of input
one jobdahan.dnip.net/IN: loading from master file jobdahan.dnip.net.zone failed: unexpected end of input

   저도 처음 DNS 서버 구축할 때 이 것 때문에 스트레스 엄청 받았습니다.
   혹시라도 설정 파일 내용을 이상 없이 입력했는데도 에러 메시지가 나올 경우 댓글로 에러 메시지와 함께
   에러가 발생된 설정파일 내용도 올려 주시면 같이 해결해 보기로 하겠습니다.


 2) named 데몬 프로세스 확인

   에러가 없을 경우 [Ctrl+Alt+Del] 키를 눌러서 Windows 작업관리자 창을 연 다음
   [프로세스] 탭을 클릭하여 아래 그림과 같이 named.exe가 실행되고 있는지 확인합니다.


 3) 네임서버 질의 명령어 nslookup으로 확인

   named 데몬이 동작되고 있음을 확인했으니 네임서버 질의 명령어(nslookup)를 이용해서
   서브 도메인의 IP 주소를 확인해 볼 차례입니다.

   [시작]-[실행]-cmd 입력하여 cmd 창을 하나 더 열어 놓습니다.
   (왜냐구요? 아까 열어 놓았던 cmd 창은 named 데몬을 실행 중인데 그 창에서 다른 명령을 실행시키기 위해 프롬프트가
    나오게 하려면 named를 중지시켜야 하고, 글케되믄 named 동작을 확인해 볼 수 없게 되기 땜시...)

   새로 열린 cmd 창에서 아래와 같이 nslookup[Enter]을 입력하여 nslookup 모드로 들어갑니다.
   프롬프트가>로 바뀌었을 것입니다.

   이제 생성시킨 서브 도메인들을 각각 입력하여 질의 했을 때 IP 주소가 표시되면
   그 주소가 위에서 작성했던 zone 파일인 jobdahan.dnip.net.zone에서 설정했던 주소인지 확인합니다.
   210.95.205.15 이면 정상적으로 잘 설정되어 동작되고 있는 것입니다.

명령 프롬프트(cmd) 창

C:\Documents and Settings\hats>nslookup
Default Server:  cns3.bora.net
Address:  203.248.252.2

www.jobdahan.dnip.net
Server:  cns3.bora.net
Address:  203.248.252.2

Name:    www.jobdahan.dnip.net
Address:  210.95.205.15

jobdahan.dnip.net
Server:  cns3.bora.net
Address:  203.248.252.2

Name:    jobdahan.dnip.net
Address:  210.95.205.15

mail.jobdahan.dnip.net
Server:  cns3.bora.net
Address:  203.248.252.2

Name:    mail.jobdahan.dnip.net
Address:  210.95.205.15

ftp.jobdahan.dnip.net
Server:  cns3.bora.net
Address:  203.248.252.2

Name:    ftp.jobdahan.dnip.net
Address:  210.95.205.15

shop.jobdahan.dnip.net
Server:  cns3.bora.net
Address:  203.248.252.2

Name:    shop.jobdahan.dnip.net
Address:  210.95.205.15

exit
C:\Documents and Settings\hats> _

   확인이 끝났으면 exit 명령으로 nslookup 모드를 빠져 나옵니다.


 4) ping 명령으로 전송 응답 테스트

   이 번에는 설정된 도메인으로 패킷 데이터(Packet Data)를 보내고 그 응답 상태를 확인하기 위해 방금 nslookup 명령을
   사용했던 cmd 창에서 ping 서브도메인[Enter]의 명령 형식으로 각 도메인들을 테스트합니다.
   nslookup으로 확인이 잘 되었다면 ping 테스트 결과도 정상적일 것입니다.

명령 프롬프트(cmd) 창

C:\Documents and Settings\hats>ping jobdahan.dnip.net

Pinging jobdahan.dnip.net [210.95.205.15] with 32 bytes of data:

Reply from 210.95.205.15: bytes=32 time=1ms TTL=255
Reply from 210.95.205.15: bytes=32 time<1ms TTL=255
Reply from 210.95.205.15: bytes=32 time<1ms TTL=255
Reply from 210.95.205.15: bytes=32 time<1ms TTL=255

Ping statistics for 210.95.205.15:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 1ms, Average = 0ms

C:\Documents and Settings\hats>ping www.jobdahan.dnip.net

Pinging www.jobdahan.dnip.net [210.95.205.15] with 32 bytes of data:

Reply from 210.95.205.15: bytes=32 time<1ms TTL=255
Reply from 210.95.205.15: bytes=32 time<1ms TTL=255
Reply from 210.95.205.15: bytes=32 time<1ms TTL=255
Reply from 210.95.205.15: bytes=32 time<1ms TTL=255

Ping statistics for 210.95.205.15:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

C:\Documents and Settings\hats>ping shop.jobdahan.dnip.net

Pinging shop.jobdahan.dnip.net [210.95.205.15] with 32 bytes of data:

Reply from 210.95.205.15: bytes=32 time<1ms TTL=255
Reply from 210.95.205.15: bytes=32 time<1ms TTL=255
Reply from 210.95.205.15: bytes=32 time<1ms TTL=255
Reply from 210.95.205.15: bytes=32 time<1ms TTL=255

Ping statistics for 210.95.205.15:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

C:\Documents and Settings\hats> _

   ping 검사 결과 모두 Packets: Sent = 4, Received = 4, Lost = 0 (0% loss) 임을 알 수 있습니다.
   즉, 4개의 패킷 데이터를 보내서 4개 모두 받아 손실이 0 이라는 의미입니다.

   여기의 예에서는 3개 도메인에 대해서만 확인해 보았지만 여러분들은 설정한 서브 도메인 모두 확인해 보시기 바랍니다.


이제 DNS 서버(BIND9)의 동작 확인이 끝났으니 cmd 창을 두 개 모두 닫아도 좋습니다.
named가 실행되었던 cmd 창을 닫은 다음
Windows 작업관리자 창의 [프로세스] 탭을 보면 named 데몬의 실행이 중지되어 사라지고 없음을 알 수 있습니다.


자, 지금까지의 작업이 순조롭게 잘 되었습니까?

혹시라도 문제가 있으면 글을 올려 주시기 바랍니다.

작업이 잘 되었다면 이제는 임시가 아닌 정상적인 서비스가 되게 설정할 차례입니다.

 설정 파일의 마지막으로 개별 도메인에 대한 zone 파일을 만들어 주어야 합니다.
 만들 zone 파일의 이름은 zone "jobdahan.dnip.net"에서 정의한 zone 이름(Zone Name)에 “.zone"을 붙여 주는 것이
 일반적인 방법입니다.

 물론 이 zone 파일 역시 \etc 디렉터리 즉, C:\APM_Setup\Server\DNS\etc\ 디렉터리에 위치하고 있어야 합니다.
 named.conf 파일의 options 블록에서 directory "C:\APM_Setup\Server\DNS\etc";로 정의했기 때문이지요.

 바로 이 zone 파일에서 실제 사용하게 되는 도메인과 서브 도메인들을 설정해 주게 됩니다.
 도메인 설정의 핵심이라고 할 수 있겠지요?
 그래서 이 부분은 조금 더 자세하게 설명하기로 하겠습니다.

 앞에서 설명한 named.conf 파일의 맨 아래 부분에 다음과 같은 zone 블록이 있었을 것입니다.

zone "jobdahan.dnip.net" IN {
 type master;
 file "jobdahan.dnip.net.zone";
 allow-update { none; };
};


 위의 구문에서 file "jobdahan.dnip.net.zone";은 jobdahan.dnip.net.zone 파일로 네임 서비스를 하겠다는 설정이므로
 아래의 설명과 같은 내용의 jobdahan.dnip.net.zone 파일을 만들어 주어야 합니다.

[ 예 1] C:\APM_Setup\Server\DNS\etc\jobdahan.dnip.net.zone 파일의 내용

$TTL 43200
@    IN    SOA    ns.jobdahan.dnip.net.    root.jobdahan.dnip.net. (
                        2007042710  ; 시리얼 값 (년월일시간)으로 대부분 셋팅
                        3H              ; 2차 네임서버가 1차 네임서버에 접속하는 시간
                        15M            ; 접속 실패 시 다시 시도할 시간 간격
                        1W              ; 1차 네임서버에서 데이터가 없다면 1주 이후에 지워진다.
                        1D )            ; 위에서 설정한 TTL 값과 같은 의미
;
; Name Server
      IN     NS      ns.jobdahan.dnip.net. ; 도메인을 소유한 DNS의 도메인
      IN     MX 10  mail.jobdahan.dnip.net. ; 메일을 보낼 도메인 또는 주소
      IN     A         210.95.205.15  ; 도메인이 찾아갈 IP 주소
;
; Host name
ns   IN    A         210.95.205.15  ;
;
; Virtual Host
www    IN    A   210.95.205.15  ; www.도메인이 찾아갈 IP주소
mail     IN    A   210.95.205.15  ; 메일서버 아이피
ftp        IN    A   210.95.205.15  ; FTP서버 아이피
*          IN    A   210.95.205.15  ; 모든 서브 도메인이 찾아갈 서버 ip 주소

 다음은 위의 내용에 대한 설명입니다.

  a) SOA ns.jobdahan.dnip.net. : 해당 도메인(ORIGIN : jobdahan.dnip.net)에 대하여 이 곳에 설정한 네임서버
     (ns.jobdahan.dnip.net : DNIP 사이트에서 무료 서비스 받은 도메인)가 모든 정보를 가지고 있음을 선언하고 있습니다.
     도메인 끝 부분에 마침표 “.”을 붙이고 있는 것에 유의하십시오.

  b) root.jobdahan.dnip.net. :  jobdahan.dnip.net이라는 도메인의 관리자 Email 주소에 해당합니다.
     이 구문은 root@jobdahan.dnip.net을 의미하는 것으로 @기호 대신에 .(dot)을 사용하여
     root.jobdahan.dnip.net.으로 입력합니다.

  c) IN NS ns.jobdahan.dnip.net.;
     해당 도메인(jobdahan.dnip.net)의 네임서버(ns.jobdahan.dnip.net)를 지정하는 곳입니다.

  d)IN MX 10 mail.jobdahan.dnip.net.;
     MX는 Mail eXchanger의 약어로서 해당 도메인(jobdahan.dnip.net)의 메일서버를 지정하는 곳입니다.
     (지금은 메일서버가 구축되어 있지 않아 이 부분은 삭제해도 되지만 나중에 메일서버를 사용하게 될 때에는
     삽입하여야 합니다.)

  e) IN A 210.95.205.15 ;
    해당 도메인(jobdahan.dnip.net)의 IP 주소가 210.95.205.15(자신의 컴퓨터 외부 인터넷 연결 IP 주소)임을 설정합니다.

  f) ns IN A 210.95.205.15 ;
    ns.jobdahan.dnip.net의 IP 주소가 210.95.205.15임을 설정합니다.

  g) 서브 도메인 설정 ~ 각 서브 도메인들에 해당하는 IP 주소를 설정합니다.

www     IN    A     210.95.205.15 ;
mail      IN    A     210.95.205.15 ;
ftp         IN    A     210.95.205.15 ;
*           IN    A     210.95.205.15 ;

ㅇ www IN A 210.95.205.15; : www.jobdahan.dnip.net의 IP 주소가 210.95.205.15 임을 설정합니다.

ㅇ mail  IN A 210.95.205.15; : mail.jobdahan.dnip.net의 IP 주소가 210.95.205.15 임을 설정합니다.
    (이 부분은 현재 메일서버를 사용하고 있지 않으므로 사용하지 않을 것이지만 나중에 메일서버를 사용하게 될 때에는
     삽입하여야 합니다.)

ㅇ ftp  IN A 210.95.205.15; : ftp.jobdahan.dnip.net의 IP 주소가 210.95.205.15 임을 설정합니다.
    (이 부분 역시 반드시 들어가야 할 부분은 아니며 ftp.jobdahan.dnip.net이라는 도메인이 필요할 경우에 삽입하면
     됩니다.)

ㅇ *   IN A 210.95.205.15; : 앞에서 정의하지 않은 나머지 모든(*) 서브 도메인들의 IP 주소가 210.95.205.15임을 설정합니다.
    이 방법은 특정 이름의 도메인이 정해지지 않았을 경우 무조건 기본 도메인으로 사용하고 있는 jobdahan.dnip.net으로
    매핑(mapping) 처리되도록 한다든지, 또는 오타로 인한 도메인은 특정 도메인으로 처리하도록 할 때에 유용한 방법이
    될 수 있을 것입니다.(여기에서는 사용하지 않도록 하겠습니다.)

  위의 설명을 참고하여 자신의 환경에 맞게 내용을 메모장이나 텍스트 에디터로 작성한 다음 이 파일 역시 다른 zone 파일들이
  있는 C:\APM_Setup\Server\DNS\etc\ 디렉터리에 jobdahan.dnip.net.zone 이라는 파일명으로 저장합니다.
  (작성할 때 아래의 [예 2] 내용을 샘플로 하시기 바라며, 주홍색 글자만 수정하시면 될 것입니다.)

  [작성 시 주의사항]  1. 도메인 뒤에 붙어 있는 .(점)을 필히 입력하시고,
                              2. 모든 공백 라인은 “;” 문자로 주석 처리하시길 바랍니다.

  여기에서는 ORIGIN 인 jobdahan.dnip.net을 비롯하여 www.jobdahan.dnip.net, mail.jobdahan.dnip.net,
  ftp.jobdahan.dnip.net, shop.jobdahan.dnip.net이라는 jobdahan.dnip.net의 서브 도메인들을 생성하게 하는
  jobdahan.dnip.net.zone 파일 작성하는 예를 들어 보겠습니다.

[ 예 2] C:\APM_Setup\Server\DNS\etc\jobdahan.dnip.net.zone 파일의 내용

$TTL 43200
@            IN    SOA       ns.jobdahan.dnip.net.    root.jobdahan.dnip.net. (
                                   2007042710  ; 시리얼 값 (년월일시간)으로 대부분 셋팅
                                   3H  ; 2차 네임서버가 1차 네임서버에 접속하는 시간
                                   15M  ; 접속 실패 시 다시 시도할 시간 간격
                                   1W  ; 1차 네임서버에서 데이터가 없다면 1주 이후에 지워진다.
                                   1D )  ; 위에서 설정한 TTL 값과 같은 의미
; Name Server
              IN     NS     ns.jobdahan.dnip.net. ; 도메인을 소유한 DNS의 도메인
              IN     A       210.95.205.15  ; 도메인이 찾아갈 IP 주소
; Host name
ns           IN    A        210.95.205.15  ;
; Virtual Host
www       IN    A       210.95.205.15  ; www.도메인이 찾아갈 IP주소
mail        IN    A       210.95.205.15  ; mail.도메인이 찾아갈 IP주소
ftp           IN    A       210.95.205.15  ; ftp.도메인이 찾아갈 IP주소
shop       IN    A       210.95.205.15  ; shop.도메인이 찾아갈 IP주소


 [ 개별도메인 zone 파일의 유효성 검사(zone file validity checking) ]

  BIND9의 동작 테스트를 하기 전에 먼저 etc 디렉터리에 있는 jobdahan.dnip.net.zone 파일이 유효한지 검사해 보기로
  하겠습니다.

  이 작업은 DNS 서버 구축의 성공 여부를 가늠할 수 있는 마지막 과정이기 때문에 이 검사에서 에러 메시지가
  하나도 나오지 않아야만 합니다.
 만약 에러 메시지가 나오면 그 에러메시지 내용을 잘 살펴본 후 반드시 그 부분을
  해결하시기 바랍니다.

  [시작]-[실행]-cmd 입력하여 cmd 창을 열고, 현재의 디렉터리를 C:\APM_Setup\Server\DNS\etc\ 디렉터리로
  이동시킨 후 다음 형식과 같은 명령을 입력합니다.

형식 : named-checkzone {zonename} {filename}

  예) named-checkzone  jobdahan.dnip.net  jobdahan.dnip.net.zone

아래와 같이 에러 메시지가 없이 표시되면 모든 설정이 잘 되었음을 나타냅니다.

명령 프롬프트(cmd) 창

C:\Documents and Settings\hats>cd\APM_Setup\Server\DNS\etc[Enter]

C:\APM_Setup\Server\DNS\etc>named-checkzone jobdahan.dnip.net jobdahan.dnip.net.zone[Enter]
zone jobdahan.dnip.net/IN: loaded serial 2007042710
OK

C:\APM_Setup\Server\DNS\etc>

다음은 에러 메시지의 예입니다. 참고하시기 바랍니다.

에러 메시지 [예 1]

C:\APM_Setup\Server\DNS\etc>named-checkzone jobdahan.dnip.net jobdahan.dnip.net.zone
zone jobdahan.dnip.net/IN: NS 'ns.jobdahan.dnip.net.jobdahan.dnip.net' has no address records (A or
AAAA)
zone jobdahan.dnip.net/IN: loaded serial 2007042710
OK
[설명] IN NS ns.jobdahan.dnip.net 구문에서 끝부분에 점(.)이 없기 때문에 표시되는 메시지

에러 메시지 [예 2]

C:\APM_Setup\Server\DNS\etc>named-checkzone jobdahan.dnip.net jobdahan.dnip.net.zone
zone jobdahan.dnip.net/IN: NS 'ns.jobdahan.dnip.net' has no address records (A or AAAA)
zone jobdahan.dnip.net/IN: loaded serial 2007042710
OK
[설명] ns IN A 210.95.205.15 ; 라는 구문이 없기 때문에 표시되는 메시지

에러 메시지 [예 3]

C:\APM_Setup\Server\DNS\etc>named-checkzone jobdahan.dnip.net jobdahan.dnip.net.zone
jobdahan.dnip.net.zone:20: pc_book.jobdahan.dnip.net: bad owner name (check-names)
zone jobdahan.dnip.net/IN: loaded serial 2007042710
OK
[설명] zone 파일의 20번 행에서 pc_book IN A 210.95.205.15 ;이라 설정하여 서브 도메인 이름으로 사용할 수 없는 언더바(underbar, “_”)를 사용했기 때문에 표시되는 메시지. 하이픈(hyphen, "-")은 사용 가능함


이제 마지막 설정 파일인 jobdahan.dnip.net.zone 파일이 추가 되었습니다.
C:\APM_Setup\Server\DNS\etc\ 디렉터리에 모두 7개의 설정 파일들이 있을 것입니다.

수고 많이 하셨습니다...!

 a) named.ca 파일 만들기

   강좌 첫 부분 DNS 개념에서 설명했듯이 모든 네임서버는 반드시 최상위 도메인인 루트도메인에 대한 정보를
   가지고 있어야 하는데 바로 named.ca 파일에 루트도메인에 대한 정보가 들어가 있어야 합니다.

   아래 링크된 INTERNIC 사이트에 접속해 보면 여러 개의 파일들이 보이는데, 그 중에서 루트도메인에 대한 정보가
   들어가 있는 named.root 파일만을 다운로드하여 C:\APM_Setup\Server\DNS\etc\ 디렉터리에 저장 한 뒤에
   파일명을 named.ca로 바꾸어주면 됩니다.(클릭한 뒤 쪼께 기다리셔야 창이 열립니다...-.-;)

루트도메인파일 다운로드 링크 : ftp://ftp.rs.internic.net/domain/

   루트도메인 파일(named.root => named.ca)은 1년에 2번 정도 위의 URL에서 다운받아 업그레이드 해주는 것이 좋습니다.


 b) localhost.zone 파일 생성

   localhost라는 도메인의 IP 주소는 127.0.0.1임을 설정한 파일로써
   이 주소는 외부가 아닌 내부 즉, 자기 자신을 가리키는 것으로써 루프 백(loop-back)을 의미합니다.
   각 지시자들과 항목들에 대한 자세한 설명은 리눅스 전문서적의 도메인네임서버 항목을 참고하시기 바랍니다.

   어느 네임서버에서나 localhost는 127.0.0.1이라는 IP 주소를 가리켜야 하므로 아래의 내용과 똑같이 입력하여
   localhost.zone 파일을 작성하면 됩니다.

   작성을 마친 다음 C:\APM_Setup\Server\DNS\etc\ 디렉터리에 localhost.zone 이라는 파일명으로 저장합니다.

C:\APM_Setup\Server\DNS\etc\localhost.zone 파일의 내용

$TTL 86400
@    IN   SOA     @       root (
       42          ; serial (d. adams)
       3H         ; refresh
       15M       ; retry
       1W         ; expiry
       1D )       ; minimum

       IN    NS     @
       IN    A       127.0.0.1


 [ localhost.zone 파일의 유효성 확인 ]

   파일 내용 입력 과정에서 실수하지 않았는지 named-checkzone.exe 유틸리티를 이용하여
   내용의 유효성을 검사해 보기로 합니다.

   cmd 창을 열고 cd 명령으로 현재 디렉터리를 유효성 검사 대상 파일 localhost.zone이 있는
   C:\APM_Setup\Server\DNS\etc로 이동시킨 후 아래와 같은 명령으로 localhost.zone 파일의 유효성을 검사합니다.


   현재 디렉터리를 \etc 디렉터리로 이동시키는 명령 cd C:\APM_Setup\Server\DNS\etc(Enter)

   ( 현재 디렉터리를 \etc 디렉터리로 이동시키지 않으면 localhost.zone 파일이 존재하고 있는 경로를 다음과 같이 명령에
     포함시켜 입력해야 되겠지요?
     C:\Documents and Settings\hats>named-checkzone localhost C:\APM_Setup\Server\DNS\etc\localhost.zone )

   다른 에러 메시지가 나오지 않고 아래와 같이 표시되면 정상적으로 잘 작성되었음을 나타냅니다.

명령 프롬프트(cmd) 창

C:\Documents and Settings\hats>cd C:\APM_Setup\Server\DNS\etc

C:\APM_Setup\Server\DNS\etc>named-checkzone localhost localhost.zone
zone localhost/IN: loaded serial 42
OK


 c) named.local 파일 생성

   localhost 도메인의 Inverse Domain에 대한 정보를 설정한 파일로써
   IP 127.0.0.1은 localhost 도메인을 가리키게 설정하고 있습니다.
   각 지시자들과 항목들에 대한 자세한 설명은 리눅스 전문서적의 도메인네임서버 항목을 참고하시기 바랍니다.

   이 파일 역시 별도로 수정할 필요가 없으며, 이 내용 그대로 입력하여 작성한 뒤
   C:\APM_Setup\Server\DNS\etc\ 디렉터리에 named.local 이라는 파일명으로 저장합니다.
   (주의 : localhost 뒤에 있는 “.”을 반드시 넣도록 하십시오.)

C:\APM_Setup\Server\DNS\etc\named.local 파일의 내용

$TTL  86400
@    IN    SOA        localhost.    root.localhost. (
                            1997022700 ; Serial
                            28800         ; Refresh
                            14400         ; Retry
                            3600000      ; Expire
                            86400 )       ; Minimum
       IN      NS        localhost.

1     IN      PTR       localhost.


[ named.local 파일의 유효성 확인 ]

  cmd 창을 열고 cd 명령으로 현재 디렉터리를 C:\APM_Setup\Server\DNS\etc로 이동시킨 후
  다음과 같은 명령으로  named.local 파일의 유효성을 검사합니다.

  아래와 같이 표시되면 정상적으로 잘 작성되었음을 나타냅니다.

명령 프롬프트(cmd) 창

C:\APM_Setup\Server\DNS\etc>named-checkzone named.local named.local
zone named.local/IN: loaded serial 1997022700
OK


   이제 C:\APM_Setup\Server\DNS\etc\ 디렉터리에 named.ca, localhost.zone, named.local 파일 3개가 추가되어
   6개가 되었을 것입니다.

   앞으로 개별 도메인 설정 zone 파일(예 : jobdahan.dnip.net.zone) 1개만 더 만들면 됩니다.

'Programming > tool' 카테고리의 다른 글

06) BIND9 동작 테스트  (0) 2010.03.19
05) 개별 도메인 zone 파일 만들기  (1) 2010.03.19
03) named.conf 파일 만들기  (0) 2010.03.19
02) [DNS for XP] BIND9에서 named.conf, zone 파일 설정  (0) 2010.03.19
01) XP에 DNS 설치  (0) 2010.03.19

 named.conf 파일은 DNS 서버 데몬인 named의 기본 설정 파일입니다.

 즉, 각종 설정 파일들이 어디에 있는지,
 rndc로 named 제어를 허용 할 것인지 여부와 key 값은 어떻게 되는지,
 루트도메인(.)들을 지정하고 있는 파일은 무엇인지,
 localhost의 IP 주소를 지정한 파일은 무엇인지,
 또 127.0.0.1이 가리키는 도메인을 설정한 파일은 무엇인지,
 하부 도메인(서브 도메인)들이 가리키고 있는 IP 주소를 지정한 파일은 무엇인지를
 기록해둔 파일입니다.

 이 파일은 rndc.key, rndc.conf 파일과 같이 자동 생성되는 것이 아니라
 여러분이 사용하고자 하는 네임서버의 용도에 맞게 메모장이나 텍스트 에디터를 이용하여 직접 만들어 주어야 합니다.

아래의 named.conf 파일 샘플을 참고하여 메모장이나 텍스트 에디터(Edit Plus, Ultra Edit 등)로
자신의 컴퓨터 C:\APM_Setup\Server\DNS\etc\ 디렉터리에 named.conf 파일을 만들기 바랍니다.
이 때 유의할 점은 공백 한 자만을 제외하고 두 자 이상은 탭(Tab) 키를 이용하여 입력하시기 바라며 주석문은 // 입니다.

한글로 설명된 주석 부분(청색 글자)은 모두 입력하지 마시고, 주홍색 글자만 자신의 환경에 맞게 수정하고
나머지는 그대로 입력하시면 됩니다.
.(dot), ;(semicolon) 하나라도 잘못 입력하면 에러가 발생하게 되니 유의해서 작성하시기 바랍니다.

C:\APM_Setup\Server\DNS\etc\named.conf 파일의 내용

options {
 directory "C:\APM_Setup\Server\DNS\etc";       // 네임서버의 zone 파일들이 위치한 경로
};

controls {
 inet 127.0.0.1 allow { localhost; } keys { rndc-key; };    // 로컬(localhost, 127.0.0.1)에서 인증키(rncd-key)를 이용해
};                                                                             // named 데몬 제어를 허용한다는 설정

zone "." IN {
 type hint;
 file "named.ca";                            // 이 네임서버의 루트도메인(.)에 대한 정보는 named.ca라는 파일에 있다는 설정
};                                                   // 그러므로 위의 directory에서 지정한 경로에 named.ca 파일이 존재해야 됨

zone "localhost" IN {
 type master;
 file "localhost.zone";                // 이 네임서버의 localhost 도메인에 대한 정보는 localhost.zone 파일에 있다는 설정
 allow-update { none; };               // etc 디렉터리에 localhost.zone 파일이 존재해야 됨
};

zone "0.0.127.in-addr.arpa" IN {
 type master;
 file "named.local";                    // localhost의 Inverse Domain에 대한 정보는 named.local 파일에 있다는 설정
 allow-update { none; };               // named.local 파일 역시 /etc 디렉터리에 존재해야 됨
};

include "C:\APM_Setup\Server\DNS\etc\rndc.key";
                                                 // rndc.key 파일이 존재하고 있는 경로와 파일명

zone "jobdahan.dnip.net" IN {   // 여기에서 jobdahan.dnip.net은 zone Name 에 해당하며, zone Name은
 type master;                              // www.dnip.net 사이트에서 무료 서비스 받은 도메인에서 ns를 제외한 도메인 명
 file "jobdahan.dnip.net.zone";
                                       // 서비스 받고 있는 도메인에서 ns를 제외하고 확장자로 .zone을 붙인 명칭 사용이 일반적임
                                       // jobdahan.dnip.net.zone 파일을 zone 파일로 하여 네임서비스를 하겠다는 설정
 allow-update { key "rndc-key"; };
};                                    //rndc-key 값으로jobdahan.dnip.net.zone 파일의 업데이트를 허용하겠다는 설정 



[ named.conf 파일의 문법 확인 ]

자, 이제 named.conf 파일을 다 작성하였으니 문법에 틀림이 없는지 검사해 봅시다.

이 문법이 틀리면 DNS 서버가 아예 동작하지 않게 됩니다. 그 만큼 중요한 것이므로 문법 검사하는 툴(tool)까지 있는 것
아니겠습니까?

named.conf 내용의 문법을 검사해주는 유틸리티는 C:\APM_Setup\Server\DNS\bin\named-checkconf.exe 파일
입니다. 검사하는 방법은 아래와 같으며, 이상이 있을 때만 잘못된 곳을 알려주는 메시지가 표시되고 이상이 없을 때는
아무런 표시가 되지 않습니다.

명령 프롬프트(cmd) 창

C:\Documents and Settings\hats>named-checkconf C:\APM_Setup\Server\DNS\etc\named.conf

C:\Documents and Settings\hats>_

(named.conf 파일의 문법이 틀리지 않았을 경우 임)


에러 메시지가 표시되면 그 내용에 따라 named.conf 파일을 수정하고, 아무런 표시가 없을 때까지 검사합니다.

[ 에러 메시지 예 ]

C:\APM_Setup\Server\DNS\etc>named-checkconf named.conf
named.conf:35: missing ';' before end of file

named.conf 파일의 35행 문장 끝에 ';'이 없다는 메시지입니다.
즉,
 allow-update { key "rndc-key"; };
}
으로 되어 있다는 내용이므로 }를 }; 로 수정하고 다시 검사해 봅니다.

C:\APM_Setup\Server\DNS\etc>named-checkconf named.conf
named.conf:7: unknown key 'rndckey'

named.conf 파일의 7행에 입력되어 있는 rndckey 키를 알 수 없다는 메시지입니다.
rndc.key 파일의 내용을 확인해 보면 key 이름이 key "rndc-key"로 정의되어 있음을 알 수 있습니다.
named.conf의 7행 inet 127.0.0.1 allow { localhost; } keys { rndckey; };의 rndckey를 rndc-key로 수정하고
다시 검사해 봅니다.


이제 C:\APM_Setup\Server\DNS\etc\ 디렉터리에 rndc.key, rndc.conf, named.conf 파일 3개가 되었을 것입니다.
앞으로 4개의 파일이 더 있어야 합니다.

 named.ca
========================================================
ftp://ftp.rs.internic.net/domain으로 접속한다.
named.cache 파일을 받아서 확장자를 named.ca로 바꿔준다.
접속이 잘 되지 않으면 첨부 파일을 사용한다.

named.zip - Last update : 2004년 01월 28일 ← 첨부파일========================================================

☆ named.conf
- 빨간색 부분을 변경하여 저장
========================================================
options {
directory "c:\dns\etc"; <- 설치 경로명
};

zone "." IN {
type hint;
file "named.ca"; 
};
zone "localhost" IN {
type master;
file "scmlab.zone";
allow-update {none; };
};
zone "0.0.127.in-addr.arpa" IN {
type master;
file "named.local";
allow-update {none; };
};
key "key" {
algorithm hmac-md5;
secret "+vjvsrwnJ54fRgQjDqxe+A=="; <-rndc.key 에서 생성 된 값 입력
};
zone "scmlab.com" IN {  <-자신이 사용할 도메인 이름 저는 scmlab.com 으로 설정
type master;
file "scmlab.zone";
allow-update {none ;};
};
zone "24.241.203.in-addr.arpa" IN { <-IP주소 ex; 203.241.24.78 인 경우
type master;
file "scmlab.rev";   <- 도메인 이름
allow-update {none; };
};
========================================================


☆ named.local
- default 값으로 저장
========================================================
$ORIGIN .
$TTL 1D
localhost 86400 IN SOA localhost. local.localhost. (
    2001061401 ;Serial
    28800  ;Refresh (8 hours)
    7200  ;Retry (2 hours)
    604800  ;Expire (1 week)
    86400  ;Minimum (1 day)
                                )
IN NS localhost.     
IN A 127.0.0.1
========================================================


☆ scmlab.zone
- 빨간색 부분을 변경하여 자신의 도메인 이름.zone으로 저장
========================================================
$TTL 43200
@  IN SOA ns.scmlab.com. root.scmlab.com.(     <- 자신의 도메인명, 끝에 콤마 주의
   20010504 ;Serial
   10800  ;Refresh
   3600  ;Retry
   3600000  ;Expire
   43200 )  ;Minumum
IN NS ns.scmlab.com<- 자신의 도메인명, 끝에 콤마 주의
IN A 203.241.24.78 <-IP주소 ex; 203.241.24.78 인 경우
IN HINFO "Intel Pentium" "Windows XP"
ns  IN A 203.241.24.78 <-IP주소 ex; 203.241.24.78 인 경우
www  IN A 203.241.24.78 <-IP주소 ex; 203.241.24.78 인 경우
========================================================


☆ scmlab.rev
빨간색 부분을 변경하여 자신의 도메인 이름.rev으로 저장
========================================================
$TTL 43200
@  IN SOA ns.scmlab.com. root.scmlab.com.(    <- 자신의 도메인명, 끝에 콤마 주의
   20010504 ;Serial
   10800  ;Refresh
   3600  ;Retry
   3600000  ;Expire
   43200 )  ;Minumum
IN NS ns.scmlab.com<- 도메인명, 끝에 콤마 주의
78  IN PTR scmlab.com<- 자신의 도메인명, 끝에 콤마 주의
========================================================

위의 파일들을 생성 후 bind9를 실행시키면 됩니다.


출처 : 리룩스포털

출처 : http://gag.aaa.tohttp://gagstory.aaa.to

'Programming > tool' 카테고리의 다른 글

04) named.ca, localhost.zone, named.local 파일 만들기  (0) 2010.03.19
03) named.conf 파일 만들기  (0) 2010.03.19
01) XP에 DNS 설치  (0) 2010.03.19
IIS, FTP 설치  (0) 2010.03.19
VS2008로 작성한 프로젝트를 VS2005열기  (0) 2010.03.18

☆ 1. 다운로드(http://www.isc.org)
- 아래 그림처럼 윈도용 최신버전을 다운받는다.

dns01.jpg

- BIND9.3.2.zip를 다운받았으면 압축을 풀고 폴더를 확인한다.다음과 같을 것이다.
dns02.jpg


☆ 2. 설치
- BINDinstall.exe를 실행시킨다.

dns03.gif
① 설치할 경로를 지정한다. 없다면 생성할것인가라는 창이뜬다. 필자는 C:\dns로 지정했다.
② 패스워드를 적는다..솔직히 왜 적는지 모르겠다. 3번은 확인차 적는것이다.
④ install을 클릭하면 자동으로 설치가 완료된다.


☆ 3. 설정
- 설치후 c:\dns 폴더를 확인하면 bin과 etc폴더가 생성되어 있음을 알수있다.
dns04.gif
- bin 폴더에는 프로세서를 실행할수 있는 파일들이 있고, etc 폴더는 비어있다.
- 이상태로는 아무것도 실행을 할 수 없다.
- 기본적으로 local.zone named.conf 파일과 domain.zone 파일 domain.rev파일 named.ca파일은 존재해야한다.
- 필자는 위 파일 모두를 etc폴더에 위치시켰다.
- 어떤 경로에서 프로세서를 실행할 수 있도록 Path에 C:\dns\bin 을 추가하자.

[path추가]
- 시스템등록정보 -> 고급 -> 환경변수로 들어간다.
- 편집클릭
dns05.gif

- 다음을 추가한다.
dns06.gif
- 확인 -> 확인 -> 확인
- 이젠 도스창 어느경로에서든 DNS관련 프로세서를 실행시킬 수 있다.


[etc 폴더 살펴보기]
- 여기까지 필자의 폴더를 한번 살펴보겠다.
- bin 폴더는 설치때 생성된것이라 모두 같을 것이다.
- etc 폴더에는 필자가 5개의 파일을 생성했다.
5개의 파일 생성 샘플 보기
Snap21.png

[rndc.key생성 rndc.conf설정]
- rndc.key 생성
- 시작 -> 실행 -> cmd 도스창을 띄운후 아래와 같이 실행한다.


Snap2.png
- rndc-confgen 까지는 띄우지 말고 붙여서 작성하고 -a 는 한칸 띄워서 적는다.

- rndc.conf 생성

Snap5.png

- 위와 똑같이 rndc-confgen > c:\dns\etc\rndc.conf 를 적어 준다.


- c:\dns\etc 폴더에 rndc.key와 rndc.conf 가 생성되었다.

Snap3.png 


-rndc.key를 메모장으로 열어보자.

Snap4.png

-밑줄친 부분을  named.conf에 넣어 주면 된다.


☆ 4. 실행
모든 설정이 완료된 후에 실행을 한다. (5개의 파일 생성 샘플 보기)
- 실행은 아래와 같이 한다.(command창에서)

dns12.gif
- 프로세서가 실행되었는지 확인한다.
dns13.gif

- 윈도우 작업관리자에 네임서버 프로세서가 활성화 되었음이 확인된다.
- 모든것이 이상없이 실행이 되었다.


☆ 5. 기타
- zone파일과 zone.rev파일을 잘 설정하면 여러가지 도메인을 사용할 수 있을것이다.
- 위 두 파일에 서브도메인을 추가한 후 프로세서를 다시 시작하려면...
- 이때 rndc를 사용하면 아주 편리하다.
- 네임서버가 가동된 상태에서 프로세서를 다시구동하려면 rndc reload 해주면 만사 OK

[rndc reload]
dns14.gif
- 위와 같이 server reload successful 메세지가 출력되면 새로운내용이 적용된 것이다.
- 이렇게 해서 모든 설명이 끝났다.


☆ 6. 프로세서 서비스 설정
- 시스템이 시작하면 프로세서가 자동으로 작동되어야 한다.
- DNS서버를 인스톨할때 서비스에 자동으로 ISC BIND가 등록이된다.


dns15.gif

- 현재는 서비스가 중지된 상태이다.

- 서비스를 자동 시작되도록 설정한다.
dns16.gif

- 로컬 시스템 계정 선택한다.
dns17.gif

- 서비스 시작 클릭
dns18.gif

- 서비스가 자동 시작으로 설정된것을 확인한다.

dns19.gif
- 시스템을 재시작후 윈도우 작업관리자에 named.exe 프로세서가 가동중임을 확인한다.



출처 : welchsjam blog

출처 : http://gag.aaa.tohttp://gagstory.aaa.to

'Programming > tool' 카테고리의 다른 글

03) named.conf 파일 만들기  (0) 2010.03.19
02) [DNS for XP] BIND9에서 named.conf, zone 파일 설정  (0) 2010.03.19
IIS, FTP 설치  (0) 2010.03.19
VS2008로 작성한 프로젝트를 VS2005열기  (0) 2010.03.18
Visual Studio 2008 설정  (0) 2010.03.18

여기에서는 내 PC가 아닌 다른 PC에서 작업을 하는 경우에  파일 복사 같은 것이 아니라 ftp를 이용하여 간단하게 파일을 전송해서 사용을 하는 방식으로 사용을 한다. 그럼 하나 하나 설정을 하면서 살펴보기로 한다.

먼저 [제어판]->[프로그램 추가 삭제]->[windows 구성 요소 추가 삭제]->[인터넷 정보 서비스[IIS]]을 선택을 한다. 그럼 아래 그림과 같은 화면이 된다.

[그림 2] IIS 선택 이미지


 

그 후에 자세히를 누르면 아래 그림과 같은 이미지가 나타난다.

 




                                        [그림 3] IIS 자세히 선택 화면


[ 그림 3]에서와 같이 File Transfer Protocol(FTP) 서비스와 World Wide Web 서비스를 선택을 한다. 그러면 아마 Windows XP CD 넣으라는 화면이 나오는데 CD넣고 설치를 하면 된다. 일단 설치를 한 후에 IP로 http를 해본다 되는지 확인을 하기 위해서 그러면 아마 방화벽 이런게 없다면 작업중이라는 화면이 보일 것이다. 만약 방화벽이 설치되어 있어서 연결이 안된다면 다음과 같은 방법으로 해결을 하면 된다.

[제어판] -> [방화벽] ->[일반 탭] 에서 사용 안함을 선택을 한다. 또한 하나의 Tip이 있는데 이건 네이버 블로그 나도 HD영상을 갖고 싶다에서 찾은 방식인데 [제어판]->[방화벽]-[고급]-[네트워크 설정]-[설정] 선택을 해서 아래 그림과 같이 선택을 해주는 방법도 있다.

 

[그림 4] 방화벽 고급 탭의 고급 설정

일단 여기까지가 기본 설정이다. 그 다음에 설정을 해주어야 하는게 바로  FTP 설정인데 이거 상당히 귀찮코 빡세다. 젠장이다.

 먼저 [제어판] – [관리 도구] – [인터넷 정보 서비스] – [FTP 사이트] –[기본 FTP 사이트] 에서 속성을 누른 후에 보안 계정 탭에서 익명 연결 허용을 선택 해제를 한 뒤 적용을 누른 후 확인을 누른다. 그림은 아래와 같다

.



[그림 5] 익명 연결 허용 삭제

이제 폴더 옵션에서 모든 사용자에세 동일한 폴더 공유 지정을 해제를 해 준다. 이제 ftp를 기본으로 사용할 폴더로 이동을 하여 속성을 누른 후에 공유 폴더를 설정을 하면 된다. 그림은 아래와 같다.                                

[그림 6] 사용자 권한


위의 그림에서 만약 계정을 추가하고 싶으면 추가를 해주면 된다. 또 한가지 파일 전송 오류가 나는 경우에는 용량 제한이 걸려있는지 확인을 해 보고 또한 FTP 서버 폴더로 사용할 폴더의 권한을 확인을 해 볼 필요가 있다.


'Programming > tool' 카테고리의 다른 글

02) [DNS for XP] BIND9에서 named.conf, zone 파일 설정  (0) 2010.03.19
01) XP에 DNS 설치  (0) 2010.03.19
VS2008로 작성한 프로젝트를 VS2005열기  (0) 2010.03.18
Visual Studio 2008 설정  (0) 2010.03.18
NSIS 값 읽어오기  (0) 2010.03.18

"열혈강의 윈도우즈 시스템 프로그래밍"이란 책을 보면서 의문에 빠져 들었다. 

책 내용 중 내 눈에 들어온 한 문장이 있었는데

"인텔의 32비트, 64비트 CPU 뿐만 아니라, 근래에 임베디드 환경에서 사용되는 대부분의 CPU가 RISC 구조이다."

위의 문장이었다.


난 x86은 CISC 구조이고 ARM, MIPS 등등 많은 프로세서가 RISC 구조인데 어째서 저런 말이 나왔나 생각하게 되었다.

인터넷 검색 결과 아래와 같은 문장을 발견할 수 있었다.


사실상 CISC와 RISC의 구분은 모호하다. 다만, 이전의 아키텍쳐를 계속 발전시켜온 형태의 CPU, 즉 8086부터 발전해온 x86계열을 CISC, 비교적 최근에 개발된 CPU들을 RISC라 부르게 되는 경향이 있다. 현재 둘의 경계가 모호해진 이유는 최근의 CISC CPU들이 성능향상의 방안으로 RISC의 기술들을 채용했기 때문이다. 


위와 같다면 현재 아니 예전부터 CISC는 그 구조의 한계성 때문에 성능 향상을 꾀할 수 없게 되었고 RISC의 기술을 채용했다는 것이다.

RISC는 회로가 간단해 지고 성능이 좋아진다. 단점으로는 프로세서간에 차이가 많기 때문에 명령어가 달라서 프로그램을 공유해서 사용하기 어렵다는 것이다.

CISC의 장점은 범용성이 좋은 대신에 성능은 느리고 회로가 복잡해진다.

CISC는 성능 향상을 꾀하기 위해 슈퍼스칼라 구조를 도입하는 한편 RISC 기술을 채용했다. (슈퍼스칼라가 제대로 동작하려면 RISC 구조여야 한다.)

그래서 현재는 RCISC라는 괴상한 이름을 갖게 되었다.


예전에 선보였던 프레스캇은 엄청난 열을 발생하는 CPU였다. 오죽하면 "어머니 댁에 프레스캇 한대 놔드려야 겠어요". 이말이 나왔을까.

이때가 30단계 파이프라인을 갖는다고 했다. 현재 사용되는 'i7' 린필드의 파이프라인은 14단계라고 한다. 그 때문에 클럭은 줄었지만 성능은 예전보다 훨씬 뛰어나다. (게다가 소모 전력도 더 적다.)


결론은 CISC와 RISC는 각각 장단점을 갖고 있으며 우리가 가장 많이 사용하는 IA-32(IA-32는 x86으로 불린다.)은 RCISC이다. CISC의 길다란 명령을 잘게 잘라서 RISC 처럼 처리한다.


다른 페이지가 있는데 거기도 둘러 보도록

'Programming > 이것저것' 카테고리의 다른 글

Handshking  (0) 2010.03.19
Sliding Window  (0) 2010.03.19
CISC, RISC, CRISC(EPIC)  (0) 2010.03.18
펜티엄부터 린필드 i5까지, 인텔 어떻게 걸어왔나  (0) 2010.03.18
MTU  (0) 2010.03.18

CISC(Complex Instruction Set Computer; 복합명령형 컴퓨터)
RISC(Reduced Instruction Set Computer; 축소명령형 컴퓨터)
CRISC


   MPU는 동일 칩 위에 기억회로, 논리회로를 형성한 초소형 CPU(중앙연산처리장치)인데, 그 처리구조에 따라 CISC(Complex Instruction Set Computer; 복합명령형 컴퓨터)와 RISC(Reduced Instruction Set Computer; 축소명령형 컴퓨터)로 나뉜다.


     RISC(Reduced Instructions Set Computer)가 CISC(Complex Instructions Set Computer)보다 효율적으로 명령어를 처리한다. 386이나 486 컴퓨터의 중앙처리장치가 CISC방식이고, Power PC와 워크스테이션용 중앙처리장치가 대부분 RISC방식이다. 그러나 최근에는 CISC칩도 RISC구조의 일부를 채용하여 구분이 모호해지고 있다. 따라서 addressing mode는 적어야 하고, instruction format는 다양하지 못하다.


   PowerPC(Power Optimized with Enhanced RISC PC)는 RISC(Reduced Instruction Set Computer)방식의 CPU이며 이는 Intel이나 AMD사의 CISC(Complexed Instruction Set Computer)와는 전혀 새로운 방식의 것이다. PowerPC는 IBM과 Motorola, Apple사에 의해 공동 개발된 CPU로서 PPC601, 603, 603e, 604, 604e, 740, 750(G3), 7400(G4) 순서로 발전하게 된다. RISC를 우리말로 축약형 컴퓨터라고 표현한다. 대부분의 CPU들이 방대한 명령어를 가지고 있음에도 실제로 자주 사용하는 명령어는 전체 명령어의 10%도 미치지 못함에 착안하여 명령어의 갯수를 줄이고, 그 대신 CPU 인사이드 캐시, 분기 예측 기능, 수퍼스케일러, 비순차 명령 실행, 파이프라이닝, 레지스터 개수 증가등의 본질적인 CPU 성능 개선 방안을 적용한 것이다. RISC기술은 Intel의 x86계열을 제외한 모든 CPU들, 즉 SUN의 Sparc나 DEC의 Alpha, MIPS의 R계열에 현재 채택되어 있다.


   사실상 CISC와 RISC의 구분은 모호하다. 다만, 이전의 아키텍쳐를 계속 발전시켜온 형태의 CPU, 즉 8086부터 발전해온 x86계열을 CISC, 비교적 최근에 개발된 CPU들을 RISC라 부르게 되는 경향이 있다. 현재 둘의 경계가 모호해진 이유는 최근의 CISC CPU들이 성능향상의 방안으로 RISC의 기술들을 채용했기 때문이다. 그러나 현재의 x86의 경우 오래된 아키텍쳐를 계속 발전시켜 왔기 때문에, 칩에 내장된 트랜지스터의 개수가 순수 RISC칩의 수배에 이르게 되었다. iMac에 사용되는 G3(PPC-750)의 경우 펜티엄 II의 절반에도 이르지 않는 트랜지스터의 조합으로도 더 나은 성능을 나타낸다. 최근에 개발된 G4(PPC-7400)은 펜티엄 III의 2/3의 clock만 으로도 3배이상의 성능을 보여준다. 이는 아키텍쳐가 MHz보다 더 중요하다는 것을 보여주는 단서이기도 하다.


1. CISC(Complex Instruction Set Computer)

CPU의 동작을 지시할 때 한번에 여러가지 일을 하도록 지시할 수 있는 명령어 체계를 갖는다. CPU안의 내부 명령어가 100개 이상을 사용하는 프로세서를 CISC라고 한다. 내부 명령어가 많기 때문에 기능마다 하나의 명령어를 주기 때문에 좋을 것 같이 보이지만 실제로 프로그래밍을 하기 어렵고 많은 명령어로 수행 시간이 길어질 경우가 많다. 일반적으로 사용되는 IBM 컴퓨터의 XT에서 486 CPU와 매킨토시에서 사용하는 680x0 CPU는 CISC 개념이 사용된 프로세서이다.

CISC는 인텔 ‘i80486’ ‘펜티엄’ 등의 MPU에 널리 채용되고 있는 CPU이다. CISC는 하나의 명령으로 복잡한 처리가 가능하지만 회로설계가 복잡해지는 경향이 있다.
최근 동작 주파수가 해마다 향상되어 현재는 335MHz에 달하고 있어 RISC와의 격차를 줄여 가고 있다


2. RISC(Reduced Instruction Set Computer)

CPU의 동작을 지시할 때 한번에 하나의 일만을 하도록 지시할 수 있는 명령어 체계를 갖는다. CPU안의 내부 명령어를 최소로 줄여서 수행 시간을 단축하는 것으로 단순화한 명령어를 조합해서 다른 필요한 명령어를 만드는 형태이다. 일반적으로 CISC보다 50%에서 75% 정도 더 빠르고 워크스테이션과 같은 중형 컴퓨터에 사용되는 CPU에 사용되고 있다. 모토롤라 사의 R4000은 RISC명령어 체계를 가지고 있다


최첨단 서버 워크스테이션 ‘모델 250’을 실현하는 CPU는 RISC형 CPU를 채용하고 있다. 또 인텔의 ‘펜티엄’에 대항하는 ‘파워PC’ 등도 RISC형으로 되어 있다. RISC는 종래의 CISC에서 복잡하고 종류도 많았던 명령을 정리하고 단순화하여 고속화 보드형 프로세서로 컴파일러에 의한 명령렬(列)의 최적화에 의해 고속화를 실현한다. CISC에 비해 구조가 간단하고 주파수를 높이는 일이 쉬운 것이 그 특징이다.


나아가 이 RISC를 여러 개로 병렬화하여 성능 향상을 꾀해 범용 대형 컴퓨터에 접근하고 있는 것이 최근의 서버 워크스테이션의 특징이다. <표 2>에 RISC의 상용화 예(NEC)를 나타냈다. 또 


(1) RISC, CISC,CRISC

    RISC는 정확히 말하면 `축약된 명령어 표를 이용한 정보처리방식'이다. 여기에 대비되는 것이 `복합 명령어 표를 이용한 정보처리방식' 곧 CISC이다. 386이나 486 컴퓨터의 중앙처리장치가 CISC방식이고 Power 개인용 컴퓨터와 워크스테이션용 중앙처리장치가 대부분 RISC방식이다. 펜티엄은 두 가지를 적당히 섞어 쓴다. 컴퓨터중앙처리장치는 명령어사전에서 원하는 명령어를 찾아내, 실행 시 키는 작은 반도체라고 생각하면 이 기술을 이해하기 쉽다. 물론 중앙처리장치 나름의 명령어이고, `dir'(파일목록보기) 같은 도스 명령어와는 전혀 다른 것이다. RISC방식 칩의 명령어들은 길이가 짧고 크기가 같다. 또 한 명령어는 한 가지 기능만 한다. 길이가 같아 찾기가 쉽고 기능이 한 가지밖에 없어 동시에 따로따로 처리한 뒤 결과를 합칠 수 있다. 계산기를 10개쯤 놓고 동시에 계산을 해서 합산하면 결과가 나오는 식이다. 이 때문에 명령어 처리시간이 많이 줄어든다. RISC의 장점은 CISC방식을 보면 더욱 뚜렷해진다. CISC는 명령어들의 크기가 제각각이며, 이 명령어들을 같은 크기로 잘게 잘라 처리한다 . 한 명령어를 자르니 앞뒤 순서가 생기고, 따라서 동시에 처리하지 못한다. 그렇지 않으면 뒤죽박죽이 되기 때문이다.  이런 단점 때문에 CISC방식은 인기가 떨어지고 있다. 486급 중앙처리장치의 후속제품이기 때문에 CISC방식에 바탕을 둔 펜티엄칩은 대신 잘게 자른 명령어를 동시에 처리하는 기술을 RISC방식에서 빌려왔다. 그래서 RISC와 CISC를 혼합한 CRISC방식이라고 부른다.


(2) RISC와 CISC 그 차이에 대해서

    RISC와 CISC는 CPU의 아키텍쳐,즉 구조적 측면의 차이로, 어떤 일정한 방법으로 명령어를 처리하느냐에 따라 구분된다. 예전에는 RISC를 단순히 CISC를 간소화 시킨 정도로 보는 시각도 있었지만 현재에 와서는 그런 개념을 뛰어넘고 있다. 일단 현재 우리가 대부분 쓰고 있는 CISC CPU에 대해서 설명을 해보자면 일단 CISC의 어원부터 짚고 넘어가야 할 것 같다. CISC는 Complex Instruction Set Computing의 줄인 말로, 소위 복합 명령 집합 계산,컴퓨팅으로 말 그대로 복합적인 명령어를 가지고 있다. 일단 컴퓨터에 어셈블리, 또는 베이직 따위의 언어로 명령을 주면, CPU에서 그것을 여러 단계로 세분화되어 마이크로 코드(Microcode)라 하는 수행 절차를 걸쳐 처리하게 된다. 그런데, 이런 수행에 있어 좀 더 복잡한 연산에 대응하는 명령어 셋을 추가하는 것이 CISC로, 여러 개의 단순한 명령어 셋으로 명령을 처리하기 보다는 그것들을 포괄하는 연산 셋으로 한 개의 명령어로 처리해 효율을 도모한다는 것이 CISC다. MMX도 이런 의미에서 볼 때는 CISC의 확장이라 볼 수 있겠다.


  한편, RISC는 CISC와는 반대로 기본 명령어 셋을 추구하는 형태이다. 그러나 RISC라고 해서 단순히 명령어를 간소화 시킨 형태라고 봐서는 안된다. 단순히 명령어만 간소화 시킨다면, CISC보다 뛰어날 이유가 없기 때문이다. RISC에서는 컴퓨터에서 주 수행되는 작업을 색출해, 거기에 최적화 시켜 만든다. 그러니까 핵심이 되는 작업 항목에 특화시켜 전체적인 속도를 향상시키는 것이다. 한가지 예를 들어 설명하자면, 모든 컴퓨터 작업에 있어서 읽고,쓰는 작업은 항상 포함된다. 일단 데이터를 읽어 들이고 쓰는 과정은 로딩과 스왑으로 항상 생기기 때문이다. 그 과정에 최적화시키면 그 만큼 작업 속도,즉 전체적인 처리 효과를 얻게 되는 것이다. 그러기 위해선 다른 명령어 셋과는 달리 다른 공정이 필요한데, 요즘에 와선 CISC도 이런 공정을 채용해 단일 사이클에 처리하는 명령어를 많이 갖게되었다.

요즘에 와선 이런 점을 통해서 RISC와 CISC의 차이를 구분할 수 없게 되었고, 캐시에 따른 차이가 두각을 드러냈다. 바로 CISC가 가진 맹목으로, 복합적인 명령어를 많이 가지려고 하다 보니, 트랜지스터 직접도가 과다하게 늘어나는 것이다. CISC가 가진 비효율이라 할 수 있겠다. RISC에서는 이와는 달리 명령어 체계 단순화를 지향하고, 핵심명령 특화 체제에 있어, 트랜지스터 집적에 여분이 있기 때문에 L1 캐시를 증대시켜 성능을 더욱 증대 시키는 것이다. 펜티엄 프로의 경우 L1 캐시 16KB(명령어/데이터 캐시 합친 양)이고 L2 캐시를 제외한 펜티엄 프로의 트랜지스터 집적 수가 550만개인데 반해, RISC CPU인 Power PC 604e 프로세서의 경우 L1 캐시가 64KB인데도 트랜지스터는 510만개다.

특히, 604 프로세서의 세부적인 RISC의 특성을 살펴보자면 한 실행주기당 여러 명령을 동시에 처리하는 슈퍼스칼라(6~7개의 명령어를 처리한다.)를 구현하고 있다. 이상의 서술한 점이 RISC가 CISC를 앞서는 대략적인 이유와 구조적 특징이다. R10000 프로세서 같은 워크스테이션 RISC 프로세서에 대한 언급도 하고 싶지만 그러기엔 본 필자의 역량이 너무나도 떨어지는 듯하다. 다만 O2에 사용된 R10000 프로세서를 기반해 잠깐 설명하고자 한다. R10000 프로세서의 경우 clock은 그리 높지 않다. 175MHz의 동작 clock을 가진 제품도 있기 때문이다. 1MB의 L2 캐시를 가지고 있으며,(R5000SC의 경우 5MB의 L2 캐시를 탑재하고 있다.) R10000 프로세서는 RISC프로세서의 정점을 보여주는 CPU로 RISC의 효율성을 최대한으로 발휘하고 있다. 4방향 슈퍼스칼라(4개의 명령 동시 처리)에 64비트 구조를 가지고 있으며 비순차적 명령 실행 방법과 128비트 L2 캐시 버스에 별도 5개의 실행 유닛을 가지고 있다. (PC 계열의 난폭한 마케팅을 하면 R10000 프로세서는 128비트 프로세서란 말을 들을 수도 있다는 얘기가 된다.)


   CISC는 RISC를 clock 속도로써는 충분히 능가할 수 있다. 다만 그 과정에서 트랜지스터 집적도가 너무 과다하게 올라가고 있다. 특히 Intel은 CISC에 MMX를 덧붙여 CISC에 CISC를 더한 셈이 되었다. 어차피 MMX의 세부를 열어보면 그것 역시 CISC의 확장이 되는 셈이기 때문이다. 특정 연산에 대한 명령어를 추가하는 것이 결국 CISC의 특성이 아니던가. Intel이 트랜지스터 집적도를 무리하게 올리면서 지금의 가격을 형성하고 인하 정책을 펼치는 것이 신기할 정도다. 아마도 현재의 PC CPU는 RISC로 갈 가능성은 희박할 듯 하다.

그 예로 Intel이 내세우는 차세대 CPU 머시드는 EPIC라고 하는 CISC를 또 다시 확장한 형태로 구현된다고 하니 말이다.( 그 결과 머시드의 트랜지스터 집적수는 3억개라는 천문학적인 숫자에 이르고 말았다...--;) CISC와 RISC, 이 둘은 다 각기 장단점이 있다. CISC는 복합 명령을 가짐으로써 하위 호환성을 충분히 확보할 수 있고 RISC의 경우 효율적인 CPU 구조를 가지고 있다. 다만 CISC는 트랜지스터 집적에 있어서 효율성이 결여되어 있고, 그 결과 성능 향상에 난점을 겪고, RISC의 경우 하위 호환을 위해 에뮬레이션 방식을 채택해야 하고, 일정한 환경에서만 성능을 발할 수 있는 단점이 있는 것이다. 따라서 호환성이 절대적으로 필요한 PC 환경에서는 CISC가, 전문적인 일에 있어서는 RISC가 서로 독보적인 우위에 점하고 있는 것이다.

'Programming > 이것저것' 카테고리의 다른 글

Sliding Window  (0) 2010.03.19
CISC & RISC  (0) 2010.03.18
펜티엄부터 린필드 i5까지, 인텔 어떻게 걸어왔나  (0) 2010.03.18
MTU  (0) 2010.03.18
ICMP  (0) 2010.03.18

PC의 역사가 사반세기를 넘은 지 오래지만 PC의 진화는 아직 ‘현재 진행형’이다. 처음 PC가 선보일 때만 해도 이 기계는 사무실의

업무용 컴퓨터 그 이상의 가치를 갖지 못했지만 어느새 PC는 가정의 공부방과 거실로 넘어왔다. 흑백 화면의 아스키 이미지를 조합한

조잡한 게임은 영화 수준과 비교해도 그리 흠잡기 어려울 정도의 풀 HD 수준까지 발전했고, 사무 작업 위주의 용도 역시 이제는 영화,

음악, 게임 등 엔터테인먼트 기능이 기술 발전의 큰 흐름을 만들고 있다.



CPU 역시 그러한 큰 흐름에 맞춰 끊임 없이 발전해왔다. 인텔이 ‘HD급 영상과 게임’을 내세워 코어 아키텍처 CPU를 내놓은지 3년.

그 사이에 세상은 단순 HD를 넘어 풀 HD, 그리고 그 이상의 세상을 노리고 있다. 이런 세상의 변화에 인텔은 어떤 대답을 내놓을까?

이 질문에 대해 인텔은 ‘네할렘 아키텍처’라는 새로운 기술을 해답으로서 내놓았다.


이미 2008년 말에 그 모습을 선보인 네할렘 아키텍처는 워크스테이션과 서버 시장에서 그 가치를 검증받았고, 이제 개인용 PC로

그 영역을 넓힌다. 그것이 코어 i5와 i7, 일명 ‘린필드(Lynnfiled)’ CPU다.


코어 i5의 뿌리는 펜티엄 프로

CPU의 성능을 높이는 방법 가운데 가장 쉽게 생각할 수 있는 것은 작동 속도를 높이는 것이지만, 성능이 획기적으로 좋아지지는

않는다. 더구나 속도를 무한정 끌어 올릴 수 있을 것이라는 믿음의 뿌리인 ‘무어의 법칙’만으로는 한계가 있다는 것을 지난 몇 년동안

인텔을 비롯한 반도체 기업들은 몸소 느끼게 되면서 ‘속도 만능 주의’는 더 이상 고개를 들 수 없게 되었다. 속도를 높일 수 없다면

반도체 기술의 기본 뿌리, 아키텍처(Architecture)를 바꿀 수 밖에 없다.



지난 몇 년동안 인텔은 무작정 빠른 속도에 대한 욕망을 살짝 접고 아키텍처의 개혁을 꾸준히 이어가며 새로운 CPU를 내놓았다.

‘린필드’ CPU 역시 그러한 아키텍처 개혁의 가장 최신판이다. 코어 i5와 i7의 진정한 장점을 이해하기 위해 인텔이 지금까지 어떤

생각으로 아키텍처 개혁을 이뤄왔는지 먼저 살펴봤다.


무어의 법칙 황금기, 그리고 멀티미디어 명령의 시대

린필드 코어 CPU를 비롯한 지금 팔리고 있는 대부분의 인텔 CPU들은 펜티엄 프로 시절에 처음 선보인 ‘P6’ 아키텍처에서 선보인

기술을 맨 밑의 뿌리로서 삼고 있다. 90년대 중반 등장한 펜티엄 프로는 가정용이 아닌 사무 및 전문가 전용 CPU로서 그리 많이

팔리지는 않았지만, 린필드 CPU의 증조 할머니로 불릴만한 여러 기술을 담았다.


아톰을 뺀 거의 모든 인텔 x86 CPU가 쓰는 ‘아웃오브오더(Out-of-Order)’ 명령 실행 구조를 처음 쓴 것은 펜티엄 프로이며,

32비트 환경에서 4GB 또는 그 이상의 메모리를 쓸 수 있도록 하는 변형 메모리 관리 기법인 36비트 PAE(Physical Address

Extension, 물리 메모리 확장) 역시 펜티엄 프로에서 처음 선보인 것이다. 아웃오브오더 실행 구조는 CPU가 다음 자료를 기다리며

노는 시간을 줄여 같은 작동 속도에서 성능을 크게 높여 PC 역사에 큰 획을 그었으며, CPU에 2차 캐시 메모리를 넣은 것 역시

데스크탑 PC용 x86 CPU 가운데는 펜티엄 프로가 첫 번째 테이프를 끊었다. 어찌 보면 지금 나와있는 최신 CPU의 주요 기술은

이 펜티엄 프로에 뿌리를 두고 있다 해도 좋을 것이다.



그 뒤를 잇는 펜티엄 II와 펜티엄 III는 펜티엄 프로를 바탕으로 이것을 가정용 PC에 맞게 업그레이드했다.

P6 아키텍처를 그대로 유지하면서 펜티엄 MMX CPU에 처음 선보인 ‘MMX(MultiMedia eXtension)’ 기술을 더했는데, MMX는

이미지/영상 편집과 동영상 재생, 게임 등 멀티미디어 작업에서 자주 쓰는 작업을 간단한 명령 한 번으로 실행하도록 하여 효율성을

높인 x86 CPU 최초의 SIMD(Single Instruction, Multi Data, 단일 명령 다중 데이터 처리) 기술이었다.


펜티엄 III 역시 이러한 흐름은 변함이 없는데, 공정 기술을 높여 작동 속도를 더욱 끌어 올리고, MMX의 뒤를 잇는 2세대 SIMD 명령,

SSE를 새롭게 내놓았다. 아키텍처의 큰 변화는 없지만 공정 기술을 꾸준히 끌어 올린 결과 펜티엄 III 시대에는 작동 속도가 1GHz를

넘어 최고 1.4GHz에 이르기도 했다.



펜티엄 프로부터 펜티엄 III 시절의 아키텍처 특징은 무너질 기색을 보이지 않던 무어의 법칙에 따라서 공정 기술을 차근차근 끌어

올리며 작동 속도를 높여 기본 성능을 끌어 올리고, 점차 그 비중이 커지던 영화 및 이미지 처리, 게임에 맞춰 이러한 작업의 효율성을

높이는 SIMD 기술을 받아들인 점이다. 이미 아키텍처의 큰 진화는 펜티엄 프로에서 이뤄 냈으며, 그 이후에 나온 CPU는 이 아키텍처

를 잘 다듬고 뛰어난 공정 기술의 혜택인 빠른 작동 속도를 이끌어내 사용자들의 마음을 사로 잡았다.


끊임없는 질주 펜티엄 4와 그 불편함

펜티엄 프로부터 시작된 P6 아키텍처는 세 세대를 걸쳐 그 역할을 충분히 해냈지만 인텔도 새로운 아키텍처를 고민해야만 했고,

그 결과물인 2000년에 새롭게 선보인 펜티엄 4는 P6의 마이너 업그레이드가 아닌 완전히 새로운 아키텍처, ‘넷버스트(Netbust)’

를 처음 선보인 CPU가 되었다.


넷버스트 아키텍처의 특징을 한 마디로 정리하면 ‘작동 속도를 더욱 빠르게’ 만드는 것이다.

파이프라인의 단계가 많아지면 많아질수록 같은 공정 기술을 써도 작동 속도를 높일 수 있는데, 펜티엄 4는 처음에는 20단계,

나중에는 31단계까지 파이프라인 단계를 늘렸다. 기껏해야 10개 수준인 펜티엄 III보다 훨신 많은 단계를 거쳐 명령 실행이

이뤄지게 되는데, 이렇게 파이프라인의 단계가 늘면 작동 속도는 빨라지지만, 만일 잘못 실행한 명령이나 데이터가 있으면 그

작업을 취소하고 처음부터 최고 31단계의 처리 과정을 다시 밟아야 하기에 클럭 당 실행 명령 수(IPC)가 떨어지는 문제가 생긴다.



인텔은 처리를 잘못 하는 실수를 줄여주도록 분기 예측(Branch Prediction) 효율성을 높였고, 새로운 분기 예측 기술과 더 빨라진

작동 속도를 더하면 넷버스트 아키텍처 CPU가 P6 아키텍처 모델보다 더 좋은 성능을 낼 것으로 예상했다. 여기에 CPU와 칩셋을 잇는

시스템 버스 속도를 종전의 최고 3배 수준으로 높이고 넷버스트 아키텍처에 맞춘 SSE2 기술을 더해 더욱 성능을 끌어 올렸다.


1.4GHz를 첫 모델로서 출발한 펜티엄 4는 공정 기술을 한번 더 바꾼 노스우드 코어 모델까지 큰 무리 없이 인텔의 생각대로 빠르게

속도를 끌어 올렸다. 그 사이 시스템 버스 속도는 더 빨라지고 2차 캐시 메모리 용량은 더 커졌으며 CPU 코어 하나로 두 개의

스레드(Thread)를 처리할 수 있는 가상 듀얼 CPU 기술, ‘하이퍼스레딩’이 첫 선을 보였다.

이러한 변화는 펜티엄 4의 성능을 사람들이 납득할 수 있는 수준 이상으로 높이는 데 큰 역할을 했다.


그렇지만 펜티엄 4를 내놓을 때의 생각은 몇 년만에 벽에 부딪혔는데, 더 이상 무어의 법칙이 듣지 않게 된 것이다.

무어의 법칙은 18개월마다 반도체의 속도는 두 배 빨라진다는 것인데,  130nm 공정 기술까지는 무어의 법칙을 뒷받침하기에 별

어려움이 없었지만, 90nm 공정부터는 이론에 훨씬 미치지 못하는 결과를 낳았다. 전력 소비량과 반도체 크기는 생각만큼 줄지

않았고, 이 때문에 작동 속도를 높이는 데 어려움을 겪었다.



바로 3세대 펜티엄 4 코드명 ‘프레스콧’이 그 주인공이다. 최고 4GHz에 가까운 작동 속도를 내는 데 성공했지만, 실질적으로 CPU의

성능 증가 속도는 눈에 띄게 줄어들었고, 그에 비해 발열과 전력 소모량은 엄청나게 늘었다. 때마침 불어닥친 전 세계적인 에너지

절약 열풍은 속도 만능 주의를 버리고 CPU 아키텍처를 ‘효율성’ 위주로 바꾸게 만드는 힘이 되었다.

결국 인텔은 65nm 공정 펜티엄 4 계획(일명 테자스)을 버리고 조금씩 개발을 하던 새로운 아키텍처를 빠르게 현실로 옮기는 결정을

내렸다. 바로 ‘코어 아키텍처’다.


코어 아키텍처로 연 에너지 중심의 르네상스 시대

코어 아키텍처는 펜티엄 4 시절에 나온 노트북 PC용 CPU, 펜티엄 M에서 쓰던 ‘배니어스 아키텍처’에 뿌리를 둔다.

펜티엄 M은 펜티엄 III가 쓰던 P6 아키텍처를 뿌리고 펜티엄 4의 장점인 빠른 시스템 버스와 멀티미디어 기술을 더했는데,

작동 속도는 펜티엄 4에 한참 미치지 못했지만 성능은 펜티엄 4에 그리 뒤지지 않고 전력 소비량도 적어 인기가 많았다.



2006년 코어2 듀오의 발표와 함께 첫 선을 보인 코어 아키텍처는 P6 아키텍처를 그 어머니로서 삼고 있지만 여기에 넷버스트의

장점을 더해 더 좋은 방향으로 이끌어냈다. P6 시절보다 조금 늘어난 14 단계 수준으로 줄인 파이프라인 단계는 CPU 작동 속도를

2GHz 이하로 끌어 내렸지만, 전력 소비량을 줄이고 실제 성능을 두 배 가까이 작동 속도가 빠른 빠른 펜티엄 4 수준까지 끌어 올렸다.


여기에는 명령 처리의 효율성을 높인 Micro-Ops 설계와 프레스콧 코어 펜티엄 4 CPU에서 선보인 SSE3 멀티미디어 기술, 넉넉한

2차 캐시 메모리, 그리고 펜티엄 4에서 가져온 고속 쿼드 펌프 시스템 버스의 역할이 컸다. P6 아키텍처에 없던 이러한 추가 기술은

코어 아키텍처를 ‘P6 아키텍처의 재탕’이 아닌 ‘P6와 넷버스트 아키텍처 모두의 공식 후계자’로서 인정할 만큼 좋은 성능을 보여

주었다. 1.86GHz 속도를 갖는 코어2 듀오가 2.8GHz 속도를 내는 펜티엄 4 또는 펜티엄 D보다 성능이 좋을 정도로 코어 아키텍처의

모험은 성공을 거두었다.



또한 펜티엄 D CPU에서 처음 선보였고 코어2 듀오에서 널리 쓰인 듀얼코어 기술은 코어 하나의 성능에 목을 매달던 과거의 CPU와

다른 ‘멀티 코어(Multi-Core)’로 눈을 돌리는 계기가 된다. CPU를 두 개 또는 그 이상 병렬로서 연결하는 SMP(대칭형 멀티 프로세서)

는 비록 절대 작동 속도는 빨라지지 않지만 한 번에 많은 작업/스레드를 처리할 수 있어 많은 작업을 동시에 하거나 멀티 스레드 설계를

한 작업을 하면 CPU 하나를 쓸 때보다 성능이 좋아진다.


작동 속도를 높이는 데 집착하던 P6나 넷버스트 아키텍처와 달리 과거의 아키텍처의 장점만을 살린 기본 구조와 멀티코어 기술을

바탕으로 한 코어 아키텍처 CPU는 철저히 ‘에너지 효율성’을 따졌다. 코어2 듀오 CPU는 열 설계 전력(TDP)는 65W 수준에 불과

하지만 과거의 130W를 넘나드는 수준의 펜티엄 D CPU 이상의 성능을 냈으며, 줄어든 발열은 쿨러의 소음까지 줄여 ‘조용하고

유지비 부담이 적은 CPU’라는 좋은 기억을 남겼다.

이런 인텔의 노력과 경험들을 녹인 최신 프로세서가 바로 코어 i5, i7로 이름 붙여진 린필드 프로세서다.

'Programming > 이것저것' 카테고리의 다른 글

CISC & RISC  (0) 2010.03.18
CISC, RISC, CRISC(EPIC)  (0) 2010.03.18
MTU  (0) 2010.03.18
ICMP  (0) 2010.03.18
TCP/IP PPT 에서 뜯어왔음ㅋ  (0) 2010.03.18

출처 : http://www.htsns.com


질문1
 NDIS.sys란 계층이 있는데요
 저는 NDIS가 미니포트 IM 프로토콜 드라이버를 감싸고 있는
 그림만 봐서 이그림은 좀 생소하네요
 이그림의 의미가 미니포트에서는 어퍼에지쪽으로 NDIS인터페이스에 맞춰주고 프로토콜 드라이버에서는 로워에지쪽으로 NDIS의 인터페이스에 맞춰준다는 의미인가요?

 네 감싸고 있는 것이 맞습니다. 실제 코드 구현으로 하면, ndis.sys는 하나의 라이브러리라고 생각하시면 됩니다. 즉 표준 인터페이스를 제공함으로써 미니포트 드라이버와 프로토콜 드라이버를 분리시켜서 서로 다른 업체에서 개발할 수 있도록 합니다. 즉 Lower, Upper Edge 함수들은 콜백함수들입니다. 이 부분은 open block이라는 개념으로 미니포트와 프로토콜을 서로 연결 시켜서 미니포트에서는 Lower-Edge 함수들을 ndis 함수들을 통해 호출할 수 있도록 하고 Upper-Edge 함수들도 마찬가지입니다.
 즉 NdisSend 함수를 호출하면 내부적으로 초기화 시에 등록한 미니포트의 Upper-Edge 함수를 호출하게 합니다. 즉 MiniportSend함수를 호출합니다. 이런 구조가 ndis 라는 아키텍처입니다. 

질문2
 그럼 IM드라이버가 들어간다면 그림에서 어떤식으로 연결이 되는건가요?
 
 
프로토콜, 미니포트 드라이버 구조를 이해하고 계시면 im도 이해하는데 큰 어려움은 없을 겁니다. 즉 프로토콜과 연결하는 부분은 im의 미니포트에 해당하고 미니포트와 연결하는 부분은 im의 프로토콜의 해당합니다. 그리고 im 내에서 미니포트와 프로토콜 부분은 내부 바인딩 개념으로 ndis 가 알아서 처리를 해주고 잇습니다. 과거 im 인터페이스가 제공을 하지 않는 ndis 버전에서는 im 드라이버와 같은 역할을 하는 드라이버를 개발할 때, 직접 ndis protocol 드라이버와 가상 nic 드라이버를 만들어서 내부적으로 직접 연결을 시켜서 필터 드라이버를 개발했습니다.

 다시 함수 정리를 한다면, tcpip.sys라는 ndis protocol드라이버와 virtual nic driver와 바인딩 시키고 자체 ndis protocol 드라이버를 개발 미니포트 드라이버와 바인딩 시킵니다. tcpip.sys에서 ndissend함수를 호출하면 virtual nic driver와 바인딩 되었기 때문에 MiniportSend 함수가 호출될 겁니다. 그럼 MiniportSend 함수에서 자체 ndis protocol에서 ndisopenadapter함수를 통해 얻은 바인딩 핸들을 가지고 ndissend 함수를 호출하면 미니포트의 MiniportSend 함수가 호출되는 구조로 개발이 되었습니다. IM 드라이버인 경우 이런 컨텍스트 관리가 ndis 아키텍처에서 관리가 되는데 자체 위 구조로 개발하게 되면 자체적으로 연결 컨텍스트 관리를 해줘야 되는 불편함이 있습니다.

질문3
 그림에서 1번을 보면 TDI 트랜스포트와 프로토콜이 TCPIP.sys란
 파일로 묶여있는데요.. 두개가 원래 공존하는겁니까?
 
 
네 공존합니다.
즉 프로토콜 드라이버를 개발할 때 소켓단하고 연결을 하려면 tdi transport 계층이 필요합니다.

질문4
 그렇다면 DDK샘플에서 프로토콜드라이버 샘플도 TDI트랜스포트와 프로토콜드라이버로 이루어져 있는겁니까?
 
 
packet이나 ndisuio는 소켓 단과 연결을 하지 않습니다. 그래서 tdi transport 계층이 없습니다. 자체 프로토콜 드라이버기 때문에 바로 어플리케이션과 연결해서 패킷 송/수신을 할 수 있는 하나의 패킷 드라이버라고 할 수 있습니다.

질문5
 우리가 프로토콜 드라이버를 개발하면 기존에 있는 TCPIP.sys를 대체하게 되는겁니까?

 아님 아래쪽이나 위쪽으로 삽입이 되는겁니까?
 
 
병렬 구조입니다. 새로운 프로토콜 드라이버가 생기는 겁니다. 즉 tcpip.sys와는 독립적입니다.

질문6
 그림에서 2번의 TDI.sys는 NDIS.sys처럼 라이브러리(?)를 나타내는겁니까?
 
질문7
 그림 1에서 TDI Transport는 왜 Transport라는 이름이 붙은건가요?
 그림3에서 TDI Client는 왜? Client라는 이름이 붙은건가요?
 Afd.sys에서 Afd는 무슨 약자인가요?
 
 
음 의미상 그런 구조이기 때문에 그런 이름을 붙인것 같습니다. 제 생각입니다만,

transport라는 이름은 osi 7계층에서 전송 계층에 해당하는 부분이라 이런 이름을 사용하지 않았나 생각이 들고 client라는 것은 transport 서비스를 이용하는 부분이기 때문에 client라는 이름을 사용한 것 같습니다.

afd는 모르겠습니다. 추정하는 것은 address family driver 약자가 아닐까.... 생각이 듭니다. 소켓에서 AF_NET이라는 소켓 이름이 사용하는데 AF Address Family 약자라서 ...

질문8
그림3 TDI Client에서요 아래쪽은 TDI인터페이스에 마춰서 동작하는건가요?
그럼 위쪽으로는 유저모드인데 어떤식으로 동작하는지 감이 안잡히네요.. 여기서 IO메니저는 없나요?
 
 
드라이버 통신은 IO 매니저의 의해 이루어집니다. 즉 IRP 통신입니다.
즉 dll <-> sys 사이 통신은 CreateFile, ReadFile, WriteFile, DeviceIoControl, CloseHandle을 통해 이루어집니다. 즉 장치 이름을 ms에서 알고 있기 때문에 이런 인터페이스로 개발이 되었을 겁니다.

 
질문9
 TDI쪽 노란색 계층들도 NDIS의 초록색 계층들이 NDIS인터페이스에 맞춰서 작성되는것처럼
 TDI의 인터페이스가 따로있어서 거기 맞춰서 개발해야하는건가요?
 
네 맞습니다. tdi 문서에 보면 인터페이스 관련 내용들은 자세하게 나와 있습니다.

 
질문10
우리가 NDIS인터페이스에 맞춰서 드라이버를 개발하지만
실제로는 NDIS라이브러리가 윈도우즈의 드라이버 동작방식에
맞춰서 변환해주는건가요?
 
 
ndis 라이브러리의 내부 구조는 wdm 구조일 겁니다.

 
질문11
 이렇게까지 많은 계층들이 필요가 한가요?
 이렇게 여러단계로 나눠논 이유가 무엇인가요??
 
 
third party 개발을 위한 구조입니다. 그리고 os 의 아키텍처입니다. os 개발을 잘하기 위한 구조입니다.

 
한 반년동안 제대로 이해안되던 질문들입니다 ㅠㅠ
정확한 동작을 이해하기가 엄청 어렵네요
항상 답변해주시는 운영자님 감사합니다^^
수고하세요^^
 
 
운영자님 답변 정말 감사합니다^^
 많은 걸 이해하게 됐습니다^^
 
근데 또 질문이 있어요 하하~
프로토콜 드라이버를 보면 TCPIP.sys 란 파일있잖아요
여기는 IP기반 패킷만 이 드라이버로 가는건가요?
IPX라든가 IP기반이 아닌 패킷들은 다른 프로토콜 드라이버로 올라가잖아요


질문 1
 그렇다면 미니포트에서 이더넷 프레임을 검사해서 적절한 프로토콜 드라이버로 올리는 건가요?

미니포트에서는 바인딩된 모든 프로토콜 드라이버에 패킷들을 인디케이트합니다. 프로토콜 드라이버에서 자기 패킷이 아니면 드랍을 하는 방법입니다.

질문 2
 이더넷 헤더는 어디서 붙이고 버리나요?(?)
 TDI에서는 이더넷 헤더를 얻을 수 없다고 알고 있거든요

tdi에서 다루는 구조는 이더넷 프레임을 다루는 게 아니고 연결 관리를 핸들로 처리하기 때문에 즉 연결을 캡슐화해서 처리합니다. 즉 소켓 단위라고 생각하시면 될 겁니다. 그래서 이더넷 헤더를 파악할 수 없습니다.

질문 3
 TDI 클라이언트를 개발한다면
 이것두 병렬구조로 붙게 되나요?

네 그렇게 되겠죠.. 

질문 4
 Hook Driver라는건
 네트워크 계층에서 어떤 드라이버에도 붙일 수 있는건가요?

hook 방법을 이해하시면 좀 더 이해가 쉬울 겁니다. 훅은 함수 포인터를 훅하는 것이기 때문에 원본 함수 포인터를 알면 모든 함수들이 훅이 가능합니다. 네트워크 계층에 상관이 없습니다.

질문 5
 Ip Filter Hook Driver는 어떤 드라이버에 붙은 필터드라이번가요?

tcpip.sys에서 export한 필터 함수입니다. 그래서 기능이 제한되었습니다. 즉 제공된 함수이외의 기능은 불가능합니다.

질문 6
 TDI 계층에서도 어퍼에지 로워에지라는 개념이 있나요?

다른 이름으로 사용합니다. transport와 client 개념입니다. 통신 방법도 차이가 있습니다.

질문 7
 TDI를 개발하지 않고도(IM이나 HookDriver에서)
 소켓의 생성을 감지하고 차단할 수 있을까요?

소켓의 생성이라는 말의 의미에 따라 다릅니다. 소켓의 생성이 인터넷 차단인지 아니면 실제 소켓 함수의 차단인지에 따라 차이가 있습니다. 원하는 기능이나 구조에 따라 훅 방법과 접근 레이어가 달라집니다.

질문 8
 LSP계층에 대한 어떤 문서나 사이트는 없나요?
 이쪽은 자료가 전혀 없는거 같던데 ㅠㅠ

sdk에 샘플 코드가 있고 msdn 도움말과 과거 한국전산원에서 프로젝트로 한 문서가 있습니다.
그리고 lsp를 사용한 스팸 메일 차단 공개 프로젝트가 있습니다.

질문 9
 paathru예제를 보면 모든 callback(?)함수들을 다 구현해 주던데요
 보통 필터 드라이버에서 보면
 자신이 필요한 동작만 프록시함수를 만들어서 연결시켜주잖아요
 IM에서는 모든 동작을 다 정의해줘야 하나요?

훅 드라이버와 차이점입니다. 훅방법은 자신의 훅할 위치만 훅하면 되지만 im은 ndis 아키텍처입니다. 이 구조에 맞춰 개발을 해줘야 합니다.

질문 10
 윈도우 방화벽은 무슨 드라이버로 제작된건가요?

분석을 안해봐서 어떻게 개발되었는지는 모르겠습니다.
분석을 하실 때는 일단 사용된 바이너리를 검색하시고 바이너리를 역어샘블이나 바이너리 십육진 덤프등등의 리버스 엔지니어링 툴들을 사용해서 분석해 보세요.

질문 11
 미니포트 드라이버는 왜 미니포트라고 부르는건가요?
 
또 질문 많이 하게 되네요^^

과거 랜카드 드라이버는 풀 닉드라이버라고 했습니다. 말 그대로 입니다. 포트는 하드웨어와 통신을 하는 최단부분입니다. 버스 포트 등등... 미니는 최소 업체 스펙만 구현을 하면 되도록 os에서 전체 구조를 제공해주었기 때문에 미니 부분만 개발을 하면 되는게 아닌가 생각이 듭니다. 정확히 모르겠네요.. 정의에 대해서는 



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


sfilter.dll은 



NTDDK\src\network\config\filter를 build하면 sfilter.dll이 생성된다고 합니다.



저의 경우에는 ddk sample설치시 골라서 설치해서 이 폴더가 없었던것 같습니다.



이 파일의 기능은 hantech에 netcoder님이 잘 설명 해주셨더군요.



설치 관련 dll입니다.

notify object으로써 동적으로 설치 관련 부분을 담당합니다.

즉 프로토콜을 등록하면서 가상 미니포트를 등록하려하면 이 dll 안에서 설치 관련 연산을 하면 됩니다.

2003 dotnet ddk에서는 passthru의 notify object은 사용을 안해서 제거를 했습니다. mux에서는 이 부분을 사용해서 (프로토콜 + 가상 미니포트) 먼저 네트워크 등록 정보에서 muxp 프로토콜을 등록을 하면 네트워크 구성 서브시스템(네트워크 설치 관련 모듈:운영체제)에서 notify object(CoM)을 호출을 하면 이 내에서 가상 미니포트를 등록을 합니다.



즉 프로그램 상으로 설치 과정을 변경하려면(네트워크 등록 정보에서 새로운 프로퍼티 sheet 추가 등등) 이 dll을 등록을 해야 합니다.(inf 파일 내에 component dll 부분에)



보다 자세한 내용은 ddk의 네트워크 부분에서 install 부분을 참조하세요.

자세하게 나와 있습니다.

'Programming > WinDriver' 카테고리의 다른 글

NDIS Driver 01) 시작  (0) 2010.05.02
DDK 개발 환경 구축  (0) 2010.04.18
_LIST_ENTRY  (2) 2010.03.18
Lookaside list  (0) 2010.03.18
Fast I/O  (0) 2010.03.18

MTU (Maximum Transmission Unit) ; 최대 전송 단위
MTU[엠티유]는 TCP/IP 네트웍 등과 같이 패킷 또는 프레임 기반의 네트웍에서 전송될 수 있는 최대크기의 패킷 또는 프레임을 가리키며, 대개 옥텟을 단위로 사용한다.
TCP는 어떠한 전송에서라도 각 패킷의 크기를 결정하는데 있어 MTU를 사용한다.
MTU가 너무 크면 커다란 크기의 패킷을 처리할 수 없는 라우터를 만났을 때 전송 해야하는 경우가 생길 수 있다. 이와는 반대로 MTU가 너무 작으면, 대적으로 헤더 및 송수신 확인에 따르는 오버헤드가 커지게 된다.
대부분의 컴퓨터 운영체계에서는 기본적으로 대부분의 사용자에게 두루 적합한 MTU 초기치를 제공한다. 그러나, 일부 사용자들은 이 MTU 값을 변경해야할 필요가 있다.
일반적으로, 인터넷 사용자들은 MTU 기본 값을 바꿀 것인지 또는 바꾼다면 얼마로 꾸어야하는지에 대해 자신의 인터넷 서비스 공급자들의 충고를 따르는 것이 좋다.

윈도우95 사용자들의 기본 MTU 값은 1500 옥텟이며, 이것은 이더넷의 표준 MTU 값과 같다. 인터넷의 사실상의 표준 MTU는 576이지만, ISP들은 종종 1500을 사용할 것을 제시한다. 만약 웹사이트를 액세스하다가 MTU 크기가 576으로 설정되어 있는 라우터를 빈번하게 만나게된다면, 그 크기로 변경하는 것이 나을 수도 있다
(실제로는 어떻든 몇몇 사용자들은 MTU 설정을 576으로 해서 성능이 향상되었다고 주장하는 사람도 있고, 또 일부는 아무런 향상이 없다고 말하기도 한다). MTU의 최소치는 68로 설정할 수 있다.

윈도우98에서는 그들의 접속이 1500을 써야하는지 또는 576을 써야하는지를 감지할 수 있어서, 그 접속에 적합한 MTU를 선정할 수 있게 해준다. 기본 설정 값은 "자동(Automatic)"이지만, 사용자가 패킷 크기를 1500, 1000 또는 576 등과 같이 명시적으로 설정할 수도 있다. TCP 외의 프로토콜들에는 다른 MTU 크기가 적용될 수 있다.


=============== 또 다른 정의 ==============================
MTU (Maximum Transmission Unit)은 네트워크 상에 최대 전송 단위.
주어질 물리적 매체 상에서 전송 가능한 데이터의 최대 단위를 말한다. .
예) 이더넷의 MTU는 1500바이트이다

MTU란 네트워크 상에서 Maximum Transmission Unit이라는 것은 한번의 물리적인 프레임상에 전송될 수 있는 최대크기의 데이타 또는 패킷을 이야기한다. 이 패킷은 네트워크상에서 라우터가 필요로 하는 패킷의 주소와 같은 보를 싣고 있는 헤더와 트레일러(꼬리) 정보를 가지고 있다. 만약 페킷이 패킷프레임보다 더 작은 MTU를 가지고 있는 네트워크로 보내진다면 이 패킷은 불행히 쪼개져야(fragmentation,단편화) 한다. 그리고 이 조각들은 다시 조합되어야 하므로 결국은 성능저하가 생기게 되는 것이다.

MTU는 보통 MSS(Maximum Segment Size)와 RWIM(TCP Receive WINdow)와 충돌을 일으키게 되는데, MSS는 winsock이 접속 중에 받아들이려고 하는 최대 TCP데이타의 크기를 이야기한다. MSS는 MTU보다 적어도 40바이트이상 작아지는데, 이 사이즈는 헤더와 트레일러 정보 때문에 생기는 차이다. RWIN은 데이타를 받는 컴퓨터가 받기를 준비하는 데이타의 크기를 말한다. 만약 RWIN이 너무 크게 맞춰져 있다면, 하나의 패킷이 손상되거나 잃어버리게 되었을 때, 데이타의 손실이 너무 커지게 된다.

그리고 너무 작게 맞춰져 있을 때는(예를 들어, 1 x MSS), 전송이 아주 늦어지게 되는 것이다. 일반적으로 RWIN은 4x, 6x, 8x MSS 로 맞춰진다.

TCP/IP의 최대 속도는 SLIP(Serial Line Protocol)이나 PPP(Point to Point Protocol)접속을 통해 전송될 때, 무엇보다도 모뎀의 속도에 의해 결정된다. 이상적으로 생각한다면, 28.8Kbps(kilobits/s)의 속도 에서 3.2KBytes/sec의 속도를 가질 수 있어야 하고, 24Kbps접속에서는 2.7KBytes/sec의 속도를 가져할 것이다. 하지만 전송되는 TCP데이터율은 한 Byte/sec당 9bps의 모뎀 연결율(modem connect rate)를 필요로 한다.

윈도우즈의 Programs/Accessories/System 에 있는 Windows System Monitor (sysmon.exe)를 이용하면, 당신의 접속 속도를 쉽게 체크해 볼 수 있다. 데이타 전송률을 볼 수 있는 더 좋은 방법은 'Net.Medic'이라는 현재 사용하는 인터넷 브라우저와 함께 사용되는 프로그램이 있다. 이 프로그램은 인터넷을 사용하는 도중에 일어나는 문제들을 고쳐주거나, 해결방안을 마련해주도 상황들을 모니터할 수 있는 프로그램이다.

위에서 말한 데이타 전송률이라는 것은 통신상에서 획득할 수 있는 이상적인 속도를 얘기한다. 그러나 종종 네트워크 상에 보내기 전에 인터넷의 중간 IP 라우터들에서 TCP/IP요구를 조정하거나 MTU의 크기를 더 작게 다시 나누거나 하는 과정에서 이 속도는 많이 느려지는 것이다.

여러 웹 사이트들을 방문할 때, 아마도 576바이트의 IP 디폴트 MTU의 패스로 다운로드하는 라우터를 적어도 하나 이상은 만날 것이다.
그러면,이때, 당신과 또 TCP서버가 TCP 세그먼트(MSS)를 536바이트보다 크게 사용하고 있다면, 패킷을 나누기 위해 다시 느려지는
결과를 낳게 될것이다. 파일 다운로드 스피드에 상당한 영향을 미쳐 웹이나 e-mail 프로그램에서 텍스트 데이타를 받을 때나 fragmentation을 줄이는 것이 통신 환경을 개선하는 가장 중요한 부분이 될 것이다.


MTU =1500 과 576 의 차이
답> 아이넷에서는 MTU=576로 세팅하니 엄청 느려지고 인터피아에서는 꽤 빨라졌습니다.
그런데 역시나 http://www.krnic.net/net/image/connect9710.gif 을 보았더니 인터피아는 데이콤과 코넷에 E1, 미국과 T1 두개로 연결되어 있더군요. 즉, 위의 그림을 보시고 자기 ISP에서의 MTU를 최대로 쓸지 최소로 쓸지 결정하시기 바랍니다.

MTU 조절기는 http://www.iworld.net/tucows/adnload/dlmtuspeed.html 에서 다운로드 가능합니다.
먼 저, Internet의 연결된 Network Device들은 보통 MTU =1500의 Option을 사용합니다. 물론 RFC1063에 따르면 ETHERNET=1500 , POINT-TO-POINT=1500 , X.25=576 , SLIP=1006 , 등 여러 가지로 나뉘어지지만, 기본적으로 Router 및 WAN Switch로 구성된 INTERNET에서는 MTU를 1500을 사용합니다.(cisco systems 및 BayNetwork Router에서는 Default로 구성 시에 MTU=1500으로 되고, 또한 Frame-Relay 및 ATM OC-3에서도 이 Rule이 적용됩니다) 현재 WIN95 및 WINNT , HP-UX , Solaris 등 TCPIP Kernel에서는 Path-MTU -Discovery라는 Option을 사용하고 있어서 IP Header에서의 DF Bit(Don't Fragment Bit)를 1로 Marking 하여 보내고 있습니다. 이것의 의미는 자신이 보낸 IP Packet에 대해 Fragment를 허락하지 않는다는 내용입니다. ( HPUX의 경우 nettune명령으로 Option조절가능 ) 하지만 IBM MVS/TCPIP 및 Linux Old-version같은 경우는 사용을 않합니다. 만약 이러한 Frame이 Internet상의 MTU =576으로 설정되어 있는 임의의 Router로 routing 되었을 때,이 해당 Router는 Fragment를 하려하나 DF Bit이 1로 되어 있어 실패하고 해당 IP Source에게 "ICMP Type=3 Code=4 Fragment Need , but DF Bit=1"의 Message를 보내게 됩니다(Header에 Next-Hop MTU를 포함하여).이것을 Client에서 받았을 때에는 PMTU의 크기를 해당 Next-Hop MTU에 맞추어 줄여서 보내게 되고, 또한 RoutingPath 변경으로 인한 PMTU 증가는 Timer로 주기적(2분 또는 10분)으로 PMTU Size를 증가하여 ICMP Message를 받을 때 까지 MTU Size를 증가 시킨 후 DF=1로 Marking하게 됩니다. 이러한 Internet상에서의 Routing Path변경이 흔하지 않으므로 이 같은 MTU Size증가는 드물게 일어납니다 (만약 Firewall에서 이러한 ICMP Type을 Deny했다면 MTU Size가 틀리고 DF=1로 인해 Router가 Client에게 알려주려는 ICMP Message가 유실되어 Client측에서는 아무런 조치도 못하고 멍청하게 Hold되어 버립니다

외국 News Group에 이런 내용으로 하소연하는 Network Administrator을 많이 보았습니다,이런 경우에는 Sniffer또는 Network Monitor로 Packet을 Dump하여 초기 TCP Handshake때에 MSS(아래부분에 설명)를 확인하여 틀릴 경우에 1.MTU를 작은 쪽으로 맞추어 주거나 2.Firewall에서 ICMP Deny를 삭제하여준다)
-ICMP Type=3 Code=4 Message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type =3 | Code =4 | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused =0 | Next-Hop MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internet Header + 64 bits of Original Datagram Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* 이전에는 Next-Hop MTU가 없었으나 RFC1191에서 Propose된 후에 추가 되었슴. 또한 TCP Header의 초기 3-Way Handshake시에 Option Field의 MSS가 있는데 이것도 MTU 와 관계가 깊습니다. MSS란 Maximum Segment Size로 TCP Stack이 Sliding Window Buffer에서한번에 전송할 수 있는 Data Size수가 됩니다.보통 MTU -20Byte(IP Header) -20Byte(TCP Header)로 계산 되어 설정됩니다.
보통 MTU 를 1500사용 하므로 MSS=1460 증 한번의 TCP Packet전송으로 보낼 수 있는 Data Size는 1460 Byte가 되는 거죠.
초 창기 Internet에서는 TCP가 단순하게 IP Destination이 Non-Local일 경우에 536(576- 20-20)으로 설정하고 Local인 경우에는 1460(1500-20-20)로 설정하였다-아직도 IBM MVS/TCPIP는 이 Rule을 사용하고 있다 (IBM/MVS Tcpip Parameter에 Default로 놓을 경우 이렇게 되고 MTU를 1500으로 바꾸려면 해당 Network에 직접 1500을 기술하여야 한다, 이렇게 바꾸더라도 역시 PMTU 는 사용하지 못한다- DF Bit=0.역시 IBM은 Internetwrking 보다는 SNA로만 장사해야 될 것 같다 ) 물론 MSS Size는 초기 MSS Negotiation시에 작은 수로 맞추어 집니다.

octet ; 옥텟
컴퓨터에서의 옥텟은 8 비트의 배열을 말한다. 그러므로, 옥텟 한 개는 일반적으로 8 비트로 구성된 한 바이트와 같다.
그러나, 모든 컴퓨터 시스템이 8 비트를 1 바이트로 사용하지는 않기 때문에, 8 비트 한 셋을 일컫는 분명한 의미 제공을 위해 옥텟이라는 용어가 사용된다.

이 용어를 8진수의 의미를 갖는 octal과 혼동해서는 안된다.


octal ; 8진법

Octal은 8진법을 가리키는 용어이다. 8진법에서는 숫자들이 0, 1, 2, 3, 4, 5, 6, 및 7 등 8가지의 문자를 이용하여 구성된다.
7 다음의 숫자는 10이며, 17 다음의 숫자는 20 등으로 변해나간다. 컴퓨터 프로그래밍에서, 8진수는 2진수에 비해 짧게 표기할 수 있다는 장점 때문에 2진수 대신 사용되는 경우가 있다.

'Programming > 이것저것' 카테고리의 다른 글

CISC, RISC, CRISC(EPIC)  (0) 2010.03.18
펜티엄부터 린필드 i5까지, 인텔 어떻게 걸어왔나  (0) 2010.03.18
ICMP  (0) 2010.03.18
TCP/IP PPT 에서 뜯어왔음ㅋ  (0) 2010.03.18
OSI 7Layer  (0) 2010.03.18
1. ICMP란?

ICMP(Internet Control Message Protocol)는 기술적으로 오류보고 메커니즘(Error Reporting Mechanism)입니다. ICMP는 오류를 감지한 라우터가 최초 근원지에 오류를 보고할 수 있는 방법을 제공합니다. 호스트 서버와 게이트웨이 사이에서 메시지를 제어하고 에러를 알려주는 프로토콜로서 RFC 792에 명시되어 있습니다.

데이터그램이 오류를 유발하면, ICMP는 데이터그램의 최초 근원지에만 오류 상태임을 보고할 수 있습니다. 중계 라우터의 문제를 알려줄 수 없기때문에, 사실상 어떤 라우터가 문제를 일으켰는지 판단할 수 있는 확률이 낮습니다.

그럼 왜 ICMP는 최초 근원지에게만 오류를 보고할까요? 데이터그램에는 출발지와 최종 목적지 주소만 지정할 수 있기 때문입니다. 따라서 지나가는 경로에 대해서는 알 수 있는 길이 없습니다.

Snap3.bmp
2. ICMP 메시지 전달

ICMP 메시지는 두 단계의 캡슐화 과정을 거칩니다.
ICMP 데이터영역 + ICMP 헤더

데이터그램 데이터영역          + 데이터그램 헤더

프레임 데이터영역                                  + 프레임 헤더
ICMP 메시지는 IP를 이용합니다. 즉, OSI Layer 3계층에 해당하는 프로토콜입니다.
IP 데이터그램에 캡슐화도고 IP를 통하여 전송이 됩니다.

ICMP 메시지는 오류 메시지를 전송하지만, 메시지 자체의 오류에 대한 ICMP 메시지는 생성되지 않습니다.


3. 메시지 포맷

ICMP는 세가지의 필드로 이루어져 있습니다.

"TYPE"필드 - 8비트이며, 메시지를 식별하는 일을 합니다.
"CODE"필드 - 8비트이며, 메시지 타입에 대한 추가적인 정보를 제공합니다.
"CHECKSUM"필드 - 16비트이며, 체크섬을 제공합니다.

오류를 보고하기 위한 ICMP 메시지는 헤더에 추가적으로 문제를 발생시킨 데이터그램의 옥텟을 포함합니다.
오류 발생시 어떤 애플리케이션이 문제를 일으킨 것인지 정확하게 알기 하기 위해서, 문제를 유발시킨 데이터그램의 부분을 직접적으로 되돌려 주는 것입니다.

* 참고 : ICMP TYPE 별 메시지 종류

 TYPE 필드

 ICMP 메시지 종류

 0

에코 응답(echo reply) 

 3

목적지 도달 불가능(destination unreachable) 

 4

 근원지 억제

(source quench)

 5

경로 변경(redirect) 

 6

 대체 호스트 주소

(alternate host address)

 8

 에코 요청(echo request)

 9

 RA(router advertisement)

 10

 RS(router soliciation)

 11

 데이터그램에 대한 시간 초과

(time exceeded for a datagram)

 12

 데이터그램의 파라미터 문제

(parameter problem on a datagram)

 13

 타임스탬프 요청(timestamp request)

 14

 타임스탬프 응답(timestamp reply)

 15

 정보 요청(information request)

 16

 정보 응답(information reply)

 17

 주소 마스크 요청

(address mast request)

 18

 주소 마스크 응답

(address mask reply)

 30

 Traceroute



4. PING

ping은 사용자가 ICMP echo request를 보낼 수 있도록 하는 명령어입니다. 이것은 네트워크 문제를 식별하기 위하여 사용을 하는데, 호스트가 ICMP echo request 메시지를 목적지로 전송합니다. 그리고나면 echo request 메시지를 받은 대상은 echo reply 메시지를 전송받은 쪽으로 되돌려 주어야 합니다. 이렇게 echo request와 echo reply 메시지를 주고 받음으로 인해서 호스트는 목적지에 도달 가능한 지, 응답을 하는지 검사하기 위해 사용됩니다.

따라서 이 성공적인 응답을 통해서 시스템의 주요 부분들이 제대로 동작하는지 확인할 수 있습니다.

이렇게 정상적인 응답이 가능하기 위한 다음과 같은 조건들이 있습니다.
1. 호스트 컴퓨터의 IP 소프트웨어는 데이터그램을 포워딩할 수 있어야 합니다.
2. 호스트와 목적지 간의 중계 라우터가 동작 중이고, 데이터그램을 정확히 전달해야 합니다.
3. 목적지 컴퓨터는 동작중이어야 하고 ICMP와 IP 소프트웨어가 동작해야 합니다.
4. 응답이 되돌아오는 경로에 놓인 모든 라우터들의 라우팅 테이블 정보가 전달 가능한 경로를 구성해야 합니다.


* 참고 : ICMP destination unreachable 메시지

 Code 값

의 미 

 0

네트워크 도달 불가능 

 1

 호스트 도달 불가능

 2

 프로토콜 도달 불가능

 3

 포트 도달 불가능

 4

 단편화가 필요하지만 DF 비트가 설정됨

 5

 소스 라우팅 실패

 6

 목적지 네트워크를 알 수 없음

 7

 목적지 호스트를 알 수 없음

 8

 근원지 호스트가 격리됨

 9

 관리상의 이유로 목적지 네트워크와의 통신이 금지됨

 10

 관리상의 이유로 목적지 호스트와의 통신이 금지됨

 11

 TOS에 대한 네트워크 도달 불가능

 12

 TOS에 대한 호스트 도달 불가능

 13

 관리상의 이유로 통신 필터에 의해 금지됨

 14

 호스트 우선순위 위반

 15

 사실상 우선순위 미달


'Programming > 이것저것' 카테고리의 다른 글

펜티엄부터 린필드 i5까지, 인텔 어떻게 걸어왔나  (0) 2010.03.18
MTU  (0) 2010.03.18
TCP/IP PPT 에서 뜯어왔음ㅋ  (0) 2010.03.18
OSI 7Layer  (0) 2010.03.18
광역 변수  (0) 2010.03.18

+ Recent posts