S.M.A.R.T

Windows Networking 목차

새벽예찬 — Sat, 30 Apr 2011 21:20:27 +0900

단원	장	구분
윈도우 네트워크의 기초	1장. TCP/IP Network	1-1. TCP/IP Protocol의 개요
		1-2. TCP/IP Protocol Suite 1-2-1. Application Layer 1-2-2. Transport Layer 1-2-3. Network Layer 1-2-4. Physical (Network Interface) Layer
		1-3. TCP/IP 통신의 기본흐름
		1-4. Microsoft Network Monitor
	2장. IP Address	2-1. IP Address의 이해
		2-2. IP Addressing
		2-3. Subnet Mask, Default Gateway
		2-4. CIDR (Subnetting,Supernetting), VLSM
	3장. Public Key Infrastructure (PKI)	3-1. 암호화의 역할
		3-2. Symmetric Key (대칭키)
		3-3. Public Key (공용키)
		3-4. Certificate Authority(인증기관)
네트워크 서비스의 이해	4장. DHCP (Dynamic Host Configuration Protocol)	4-1. DHCP의 이해
		4-2. DHCP서버의 구현
		4-3. DHCP Client 구성
		4-4. DHCP의 임대 갱신 과정
		4-5. DHCP의 추가기능
		4-6. DHCP의 확장구현
	5장.DNS (Domain Name System)	5-1. DNS의 이해
		5-2. DNS의 구조 및 프로세스
		5-3. DNS 설치 및 구성
		5-4. DNS Server관리
		5-5. DNS Server 문제해결
		5-6. DNS 기타
	6장. 네트워크에서 컴퓨터 찾기(WINS)	6-1. NetBIOS Network
		6-2. NetBIOS Name 등록, 해제, 요청
		6-3. WINS 설치 및 구성
		6-4. Non- WINS 클라이언트를 위한 설정
		6-5. 최적화된 WINS 서버 구현 방법
		6-6. Lmhosts 파일
	7장. RAS & IAS서버	7-1. 전화접속 서버 (Dial-up Server) 7-1-2. 전화접속 사용자 설정
		7-2. VPN (Virtual Private Network)
		7-3. RAS정책 7-4. 인터넷인증 서버(IAS)
	8장. 인터넷연결공유와 개인네트워크 구축	8-1. 사설 네트워크의 필요성
		8-2. 인터넷 연결 공유 (ICS)
		8-3. Network Address Translation (NAT)
		8-4. NAT 고급기능
		8-5. 안전을 고려한 네트워크 환경
	9장. 인증기관과 전자메일응용	9-1. 인증기관(CA) 서비스
	9장. 인증기관과 전자메일응용	9-2. 전자메일 응용
	10장. 인터넷 서비스	10-1. Internet Information Server (IIS) 10-1-2. 웹서버 기본 설정 10-1-3. 웸사이트 리디렉션 10-1-4. 웹사이트 인증 및 기본 보안 10-1-5. 웹사이트와 가상 디렉터리 10-1-6. 다중 웹사이트 호스팅
		10-2. 보안 웹서버 구현 (SSL서버)
		10-3. FTP Server 구현
		10-4. 안전한 웹서버 운영을 위한 보안지침
윈도우 서버 관리	11장. Windows Server 2003	11-1. Account (계정)
		11-2. 파일시스템과 보안
		11-3. 자원관리 11-3-1. 디스크(Hard Disk) 11-3-2. 레지스트리(Registry) 11-3-3. 이벤트 뷰어 (Event Viewer) 11-3-4. 성능모니터(Performance Monitor)
		11-4. 백업과 복구 11-4-1. 백업 (Backup) 11-4-2. 백업 예약(Schedule Backup) 11-4-3. 복구 (Restore)
		11-5. 문제해결(troubleshooting) 11-5-1. 부트프로세스의 이해 및 문제해결 11-5-2. ERD(응급복구디스크) 11-5-3. F8 옵션의 이해 11-5-4. 복구콘솔의 활용
		11-6. 시스템 유지를 위한 업데이트
		11-7. 시스템 관리를 위한 도구
	12장. 파일, 프린트 서버관리	12-1. 파일서버 구축 및 보안
		12-2. DFS (분산파일시스템)
		12-3. Disk 할당량 관리
		12-4. 프린트서버 구축 및 관리
		12-5. Active Directory 에 공유폴더 게시
기업네트워크와 Active Directory	13장. Active Directory	13-1. Directory Service (Workgroup과 Domain)
		13-2. Active Directory의 개요
		13-3. Active Directory의 구조 및 이름
		13-4. Active Directory 설치
		13-5. Active Directory 관리 13-5-1. 개체생성하기 13-5-2. AD관리-권한 위임 13-5-3. AD관리-사이트(Sites) 13-5-4. 글로벌 카탈로그 서버 (Global Catalog) 13-5-4. FSMO (Flexible Single Master Operations) 13-5-5. Active Directory 제거
	14장. Active Directory 인프라 구축	<시나리오> 윈도우네트웍스(주) Active Directory 14-1. Active Directory 설계
		14-2. 서버 설치 및 구성
		14-3. 그룹정책(Group Policy) 구성
		14-4. Active Directory 클라이언트 되기
		14-5. 맺음말

"스마트워크" 세미나 소식

새벽예찬 — Sat, 16 Apr 2011 09:26:41 +0900

중소기업진흥공단 중소기업연수원은 마이크로소프트 최고의 컨설팅 서비스 파트너인 필라넷과 2011년 새로운 키워드로 급부상하고 있는 스마트워크(Smart Work)을 주제로 하는 1박2일간의 Smart Work 컨퍼런스를 개최합니다.

금번 Smart Work 컨퍼런스는 약 120개사의 중소기업 IT담당자를 모집하여 개최될 것이며 Smart work의 개념부터 시작해서 사례발표 및 Microsoft의 Exchange 2010, Lync 2010, Sharepoint 2010 기반의 Smart work 구현기술과 구축을 위한 하드웨어, 통신 기술 등에 이르기까지 Smart Work에 대한 모든 것을 다루기 위해 준비되었습니다.

컨퍼런스는 2011.5.3(화)~5.4(수)까지 1박2일로 진행되며 연수원의 기숙사 시설을 제공합니다.
상세한 안내는 http://www.fa.or.kr/conf/10th/index.html 를 통해 확인하실 수 있습니다.

Secure.pe.kr 안내

새벽예찬 — Tue, 10 Mar 2009 21:44:37 +0900

늘 행복하시고, 건승하시길 바랍니다.
행복하세요..!!!

Microsoft TechNet 칼럼 - 도메인 컨트롤러에 얽힌 에피소드

새벽예찬 — Wed, 14 Jan 2009 08:20:24 +0900

내 자리의 데스크탑은 Windows 2000 advanced server가 인스톨되어 있고, 그 서버는 도메인 컨트롤러로 셋업되어 하나의 도메인을 만들어 내고 있다. 노트북은 그 도메인의 멤버로 설정된 Windows 2000 professional이다.

어느날 문득 노트북의 시계를 확인하니 핸드폰의 시간보다 6분 정도 느린 것을 발견했다. 컴퓨터로 작업을 하다 보면 무의식적으로 모니터의 트레이에 위치한 시계를 통해서 시간을 체크하는 것이 일반적이다.

핸드폰의 시간을 기준으로 시계를 맞추고 나서 작업을 계속했다. 다음날 또 다시 시간이 6분 정도 느려진 것을 알게 됬다.

"왜일까??

노트북 제조회사의 서비스센터에 전화를 하니 아마도 CMOS보조 배터리의 상태가 좋지 않은 듯하다고 기사를 보내겠다고 했다. "아니요.. 오실 필요까지는 없는데.."라고 했지만 극구 직접 방문해서 확인을 해 주겠단다. '음.. 서비스 많이 좋아졌군..^^' 하는 생각을 하고 기다렸다.

제조회사의 기사가 와서 노트북을 분해하기 시작했다. 잠시후.. 어?? 당황하는 빛이 역력했다. 키보드를 뜯어냈는데 있어야 할 배터리가 나오질 않는거다. 잠시후~ 시스템을 분해하지 않았어도 될 위치에서 배터리를 발견했다. 노트북 바닥면의 메모리 확장 슬롯을 장착하는 공간에 배터리가 있었던 것이다. 으흐흐..~ (속으로 ..)
배터리를 빼내고 전압체크를 하더니 뭔가 갸우뚱하는 듯한 인상을 주었고, 어찌됬건 배터리를 교체하고 나서 1시간쯤 지났을까? 이런.. 또 다시 시계가 6분 정도 느려져 있었다. 왜 이럴까?? 하는 순간에

아차.. 하고 스치고 지나가는 생각. 부리나케 데스크탑에서 관리자로 로그온을 했다.

데스크탑의 시계를 확인하니 역시 6분 정도 느린, 지금의 노트북과 일치하는 시간을 확인할 수 있었다. 그랬구나.. 바보였어. 배터리 문제가 아니라 시스템이 정상적으로 동작하고 있었던 결과였던 것을...

노트북 담당기사가 배터리를 교체하고, 꺼낸 배터리의 전압을 체크하고 갸우뚱... 하던 모습이 이해가 되는 순간이었다.

Windows2000의 도메인컨트롤러는 SNTP (Simpel Network Time Protocol)을 이용하여 시스템들의 시간을 동기화시켜주는 기능을 제공한다. Windows2000에서 로그온 하는 클라이언트가 타임스탬프를 이용한 암호화를 통해서 도메인컨트롤러에 사용자정보를 제공하기 때문에 상대적으로 시간정보가 중요하기 때문이다.

이론으로 정리를 하고, Active Directory강의시 이러한 내용들을 강조해서 강의를 하면서도 막상 이런 실수를 하고 말았다. 모든 상황에서 알고 있는 지식이 바로바로 매칭되어 튀어 나올수 있다면 좋을텐데... 하긴, 어쩌한 그러한 순간순간의 해결을 위해서 수백페이지의 책을 읽어야 하는 지도 모를일이다.

글, 송원석 팀장 "(주)필라넷 정보기술팀”

http://technet.microsoft.com/ko-kr/library/cc700736.aspx

우체국 택배 등기 조회

새벽예찬 — Tue, 6 Jan 2009 10:43:37 +0900

http://service.epost.go.kr/iservice/trace/Trace.jsp

오픈마켓 성공하기

새벽예찬 — Fri, 19 Dec 2008 13:29:56 +0900

네이버에서 지식검생중에 우연히 발견한 글이다. 비단 오픈마켓 뿐이랴, 시사하는 바가 있는 듯 하여 옮겨 놓는다.

======================================================================================================

온라인, 특히 오픈마켓에서 판매하고 있거나 판매중인 사람은 누구나가 빅셀러가 되고 싶어한다. 그러나 모두가 빅셀러가 되는 것은 아니다.
성공을 하려면 성공한 사람을 만나야 한다는 말이 있다.
유사 분야의 빅셀러와 안면이 있다면 좋겠으나 그러나 그것이 어디 말처럼 쉬운 일인가? 그리고 또한 자신외 타인은 경쟁상대로 보는 마당에 누가 자신이 쌓아온 노하우를 쉽게 공개해 주겠는가?
하지만 당신은 온라인상에서 판매하는 빅셀러를 벤치마킹하려는 것이다.
다행스럽게도 온라인이라는 특징때문에 당신은 그들의 판매기법을 간접적으로마나 살펴 볼 수 있다.

자 그럼 빅셀러를 직접 만나서 노하우를 듣거나 전수받는 것 외에 온라인을 통해 간접적
으로 빅셀러의 어떤 부분을 벤치마킹 해야 하는지를 살펴보도록 하자.

1. 빅셀러의 아이템 Vs 나의 아이템

당신이 경쟁자가 거의 없는 독특한 아이템을 취급한다면 아래부분을 자세히 볼 필요가 없다. 그러나 그렇지 않다면 아래 글들을 반드시 살펴보기 바란다.
취급하고자 하는 분야의 카테고리에서 잘 팔리고 있는 상품을 보라.
여기서 주의할 점은 당연히 취급상품의 특성도 반드시 포함하여 살펴봐야 한다는 것이다. 계절적 요인이 작용하는 상품이라면 계절적 특수성도 봐야할 것이며 유행이나 트렌드(Trend)에 민감한 상품인지 등을 반드시 검토할 때 염두에 두고 살펴봐야 한다는 의미이다.
또한 해당 아이템을 취급하는 판매자는 어느 정도 수준인지 검토해야 한다.
많이 판매되는 아이템일지라도 취급하는 판매자 또한 많다면 과연 그 시장에 참여하여 경쟁할 것인지 아니면 판매는 적을지라도 경쟁상대가 없는 틈새시장의 아이템을 발굴해서 취급할 것인지를 반드시 검토해야 한다.
저자의 경우라면 빅셀러의 판매보다 경쟁력있는 판매가 가능하다면 전자를 택할 것이고 그렇지 않다면 후자를 택할 것이다.
왜냐하면 오픈마켓은 이미 저렴한 가격을 기준으로 구매하는 고객이 전체의 70%를 차지하고 있기때문이다.

2. 상품의 제목! 글자 토씨 하나도 놓치지 말고 분석하자.

잘되는 판매자는 잘되는 판매자만의 노하우가 분명이 존재한다.
우리가 게시판의 글을 보더라도 다른 제목보다 더 눈길이 가는 제목의 글들이 있다.
즉, 같은 게시판의 글일지라도 분명 그 글들간에는 차별화가 존재한다는 뜻이다.
이는 모방을 통해서는 한계가 있을 것이며 무한하게 창작 가능한 부분이기도 한다.
그리고 부단한 연습과 노력, 시행착오를 통해서만 얻을 수 있는 분분이기도 하다.
하지만 이러한 노력과 시행착오를 통해 얻은 결과는 이제 당신의 것이며 당신의 상품 판매량은 점점 달라지기 시작할 것이다. 온라인 판매에 있어서 제일 중요한 '고객의 눈길을 끌어라'는 아무리 강조해도 지나치지 않기 때문이다.

3. 상품의 판매방식, 판매기간은 어떻게 하고 있는지 모니터링 하자.

빅셀러들도 처음부터 빅셀러는 아니었다. 빅셀러가 되기까지 여러가지 시행착오를 거쳐서 여기까지 온 것이다.
그러니 그들이 판매하는 판매방식(경매/공동구매/즉시구매설정여부 등등)은 그들의 경험이 녹아져 들어가 반영된 결과인 것이다.
또한 빅셀러들은 오픈마켓에서 제공하는 유/무료 부가서비스는 어떻게 이용하고 있는지살펴보자. 작은 것하나라도 놓치지 말고 꾸준히 모니터링하고 분석하는 습관을기른다면 이미 성공적인 첫발을 뗀 것이라 확신한다.

4. 상품의 소개 페이지를 어떻게 구성하고 관리하고 있는가?

빅셀러들의 상품소개 페이지를 보라.
빅셀러들의 상품소개 페이지를 보면 대부분 상당히 신경을 써서 제작한 흔적이 여기 저기에서 엿보인다.
이유는 간단하다. 온라인이라는 특수성 때문이다.
오프라인 가게라면 전시된 물품을 눈으로 보고 직접 체감을 통해 판단할 수 있지만 온라인에 전시된 상품은 이미지와 글로서 상품의 가치와 구매호소력을 지닌다.
특히나 의류, 패션관련 아이템의 경우 디테일한 부분까지 제품소개 이미지를 제공하는 것을 알 수 있을 것이다. 좀 더 발전된 판매자의 경우 연예인 등 스타를 이용한 상품페이지도
진행중인 것이 현실이다. 그렇다고 반드시 돈을 많이 들어야만 되는 부분은 아닌 것이다.
이 부분은 다른 판매기법 소개시 다시 살펴보도록 하자.
빅셀러의 상품페이지를 보면 대부분 정돈된 이미지, 표와 같은 형식으로 구성된 제품의 특성표시, 거기에다가 판매하는 다른 상품의 추가 간접광고 등의 기법을 이용하고 있음을 알 수 있을 것이다.
자 이제 당신은 판매할 상품을 어떻게 표현할 것인지 감이 오는가?
내가 구매자라면 어떻게 내상품이 표현되어야 구매할 마음이 들지를 생각해보면 될 것이다.

5. 빅셀러의 구매자들의 구매거래평을 참고하라.

구매자들의 글 속에는 진리가 숨겨져 있다.
빅셀러의 무엇이 구매고객들로 하여금 만족감을 주는지, 더 나아가 감동을 주고 있는지 확인하라. 그리고 느꼈다면 당장 할 수 있는 작은 부분부터 실천하라.
이러한 것들이 쌓이고 쌓여서 당신을 정상의 길로 안내하고 있는 것이다.

6. 고객들에게 특별한 인센티브를 제공하고 있는지 확인하라.

빅셀러가 자신의 고객에게 어떤 인센티브를 제공하고 있는지 확인하자.
여기서 말하는 인센티브는 유무형의 모든 것을 말한다.
사은품이 될 수도 있고 무료배송 혜택일 수도 있고 쿠폰이 될수도 있다.
그렇지 않다면 상품배송시 들어가는 구매감사의 표현이 담긴 작은 쪽지 일수도 있다.
빅셀러들은 고객들에게 어떤 인센티브를 제공하여 만족과 감동과 단골을 확보하고 있는지 확인해보라.

7. 직접 물품을 구입해서 해당 빅셀러의 일처리 프로세스(과정)에 대해서 느껴보자.

벤치마킹을 위해 많은 빅셀러들의 물품을 구입해보라는 의미는 아니다.
(물론 할수만 있다면 좋겠으나...)
단, 이 단계에서 대상 빅셀러를 선정하는 방법은 가격으로만 승부하는 빅셀러는 제외한다.
왜냐하면 가격으로 승부하는 빅셀러는 가격 자체가 큰 무기이자 경쟁력을 갖고 있으므로 벤치마킹해서 얻을 부분이 그리 많지 않을 것이기 때문이다.
오픈마켓에서 판매하고 있는 사람이거나 판매를 시작하려는 사람들중 과연 몇 %정도가가격에서 큰 경쟁력을 가지고 있겠는가?

실제 생산, 유통을 하지 않는 한 대부분의 판매자는 가격적 부분에서 서로가 경쟁의 Boundary(범위)에 있다고 보는게 맞다.
따라서 지금 말하고자 하는 빅셀러는 자신에 적합한 대표적인 몇 몇 빅셀러를 의미한다.
그럼으로써 그들이 판매과정에서 고객들에게 어떤 반응을 보이고 또 어떤 서비스를 제공하고 있는지 알아볼 수 있으며 해당 빅셀러의 좋은 점을 금방 잡아낼 수 있다.
예를 들자면, 배송시작부터 종료시까지 구매자에게 진행상황에 대한 SMS(단문문자메시지)을 전송해준다거나 상품포장은 어떤 식으로 하는지, 사은품을 제공하고 있는지 등을 파악하여 알 수 있게 해준다. 당연히 좋다고 여겨지는 부분은 응용해야 하지 않을까.

----------------------출처와 저작권에 대한 안내 -------------------------------
출처 : 대한민국 파워셀러 양성소 프로셀러 www.proseller.co.kr

태도(attitude)와 능력(ability)

새벽예찬 — Thu, 18 Dec 2008 17:25:34 +0900

한 사람은 능력이 뛰어나지만 태도가 나쁘다. 또 다른 한 사람은 태도는 좋지만 능력은 떨어진다. 이 중 한 명을 해고해야 한다면 누구를 선택하겠는가? CEO라면 누구나 이 같은 딜레마 상황에 빠져봤을 것이다.

만약 GE의 잭 웰치(Welch) 전 회장이라면 어떤 선택을 할까? GE는 사람을 평가할 때 두 가지 요소를 감안한다. 하나는 태도(attitude), 또 다른 하나는 능력(ability)이다. 모든 인사 평가는 이 두 가지 요소의 조합을 통해 이뤄진다. 태도와 능력이 모두 우수한 사람에겐 파격적인 연봉 인상과 승진이 주어진다. 일반적으로 이들의 비율은 전체 직원의 20% 정도다. 반면 태도와 능력이 모두 떨어지는 10%에겐 차가운 해고 통지서가 날아든다.

문제는 둘 중 하나가 모자라는 직원을 처리하는 방법이다. 웰치 전 회장의 원칙은 간단하다. 능력이 떨어지는 직원에겐 보직 이동을 통해서 한번 더 기회를 준다. 하지만 태도가 나쁜 직원은 해고의 수순을 밟는다. 지금 당장 성과를 낼지는 몰라도 장기적 관점에서 봤을 때 조직의 문화를 파괴할 위험이 있다는 게 그의 판단이다. 여기서 말하는 태도란 '얼마나 상사의 말을 잘 따르는가' 등과 같은 문제가 아니다. '얼마나 회사가 중요하게 생각하는 가치를 지키느냐','얼마나 열정을 갖고 일하느냐' 등과 같은 조직의 문화와 관련된 것이다. 다시 세계상사의 회의실로 돌아가 보자.

검은 고양이든, 흰 고양이든 쥐만 잘 잡으면 나머지는 관용할 수 있는 것일까? 나 사장은 한 가지를 깊게 생각해 봐야 한다. '혹시 색깔 다른 고양이 한 마리가 우리 조직의 문화와 가치를 흐리거나 망치고 있지는 않는가?' 만약 '예스'라고 생각된다면 이때는 과감한 결단(해고)이 필요하다. 그대로 뒀다간 이 고양이는

쥐만 잘 잡는 게 아니라 우리 조직도 '잡아먹을' 수 있기 때문이다.

[출처] 조선일보 土日섹션경제 2008년 6월 14-15일 C3페이지, 최철규 IGM(세계경영연구원)부원장의 글 인용

윈도우 서버 2003 터미널 서비스 응용

새벽예찬 — Mon, 1 Dec 2008 05:56:58 +0900

터미널서비스를 단순히 관리 용도로만 사용한다면 특별한 설정이 필요없다. 몇가지 추가기능들을 고려해 보고자 한다. 원격제어기능, 어플리케이션 서버기능 등이 그것이다.

(1)원격 제어

당신이 회사의 고객지원부서에 근무하는 담당자라고 가정해 보자. 회사의 사용자는 오피스2000의 새로운 기능에 대해서 묻고 싶어한다. 당신은 전화상으로 사용방법에 대해서 설명할 것이다. "도구메뉴에 보면 옵션이 있죠? 그걸 열고.. 어쩌고 저쩌고... " 기껏 설명을 했더니 잘 모르겠다고 한다. 또 다시 설명하고, 스트레스는 있는 대로 받고.. 이럴 때 터미널 서비스의 원격제어 기능은 아주 유용하다. 한가지 예제일 뿐이다. 이것을 효율적으로 응용하는 것은 여러분에게 달려있다.

예제에서는 192.168.2.200 IP Address를 사용하는 터미널서버가 있다. 당신은 tsuser2 계정을 사용한다. tsuser1이라는 계정을 사용하는 사용자가 회사에서 새롭게 도입한 프로그램의 기능을 묻고 있는데 직접 프로그램을 띄운 상태에서 설명하고 싶다. 다음과 같은 절차를 통해서 원격제어로 접근해 보자.

① tsuser1에게 터미널 서버로 접속하도록 요청한다.

<화면1. tsuser1 클라이언트 접속>

② 자신도 tsuser1이 접속한 터미널 서버에 tsuser2계정으로 접속한다.

<화면2. tsuser2 클라이언트 접속>

아래의 <화면3>에서는 이해를 돕기 위해 한 컴퓨터에서 두 개의 터미널 서비스 클라이언트 창을 띄워서 각각 tsuser1, tsuser2로서 로그온한 화면을 보여준다. 화면에서 아래의 창은 tsuser1, 위의 창은 당신이 로그온한 tsuser2이다.

③ 터미널 서비스 클라이언트를 이용해 접속한 상태에서 터미널 창안에서 "시작-관리도구-터미널 서비스 관리자"를 연다. 관리콘솔의 오른쪽을 보면 현재 서버에 로그온 한 사용자의 리스트를 볼 수 있다. tsuser1과 tsuser2, wssong이 보인다. 여기서 wssong은 현재 터미널서버에 로컬로 로그온한 사용자를 보여준다. 터미널 클라이언트는 tsuser1과 tsuser2 두명이 있다. 원격제어를 원하는 tsuser1을 클릭하고 마우스 오른쪽 단추를 눌러 "원격제어"를 클릭한다.

<화면3. 원격제어 요청 >

④ 원격제어 세션을 끝낼 때 사용할 단축키를 선택한다. 예제에서는 [Ctrl]+[Tab]을 선택했다.

<화면4.원격제어 단축키 선택>

⑤ 확인버튼을 누르면 tsuser1이 로그온한 화면에서는 <화면5>의 아래창에서 보는 것처럼 "원격 제어 요청"메시지를 받게 된다. 읽어보니 tsuser2이 원격제어 요청을 하고 있으니 수락하겠느냐?는 메시지이다. 당연히 클라이언트쪽에서 [예]를 선택해야 한다.

<화면5. 원격제어 요청 메시지>

⑥ 상대방이 '원격제어요청'을 허용해 주면 아래의 <화면6>에서 볼 수 있듯이 양쪽의 터미널 창에 동일한 화면을 보여주게 된다. tsuser1이 터미널 서버에 로그온한 세션을 공통으로 사용하도록 설정이 되었다.

<화면6. 원격제어 연결 >

⑦ 한쪽에서 프로그램을 띄운다거나, 텍스트를 입력하는 등의 모든 작업은 다른 터미널 창에서도 반영이 된다. 결국 하나의 세션이 양쪽의 터미널 창을 통해서 보여지도록 허용이 되는 것을 의미한다.

<화면7. 원격제어 테스트>

지금까지 한가지 예제를 들어서 원격제어를 구현해 보았다. 응용하는 것은 각자의 할 일이다. 만일 터미널 서비스 사용자의 동의없이 사용자의 세션에 참여하고 싶다면 어떻게 할까? 그렇다면 그 사용자가 터미널 서버에 접속해서 무슨 일을 하는지를 들여다 볼 수 있을텐데, 역시 옵션이 제공된다. "관리도구-터미널 서비스 구성"을 열어서 "연결- RDP-TCP"의 등록정보를 클릭한다.<화면8>

<화면8. 터미널 서비스 구성>

원격제어 탭에서 "사용자의 허가 필요"체크박스의 체크를 해제하고 나면 상대방의 동의 없이 원격제어가 가능해진다. 어떤 용도로 사용할 수 있을까?

<화면9. 터미널 서비스 구성 - 등록정보 수정>

(2)어플리케이션 서버 구현

또 다른 용도를 고려해 보자. 회사에서 업무상 필요한 어플리케이션이 Windows2000환경에서만 작동한다면 어떻게 할까? 당연히 모든 클라이언트들은 Windows2000으로 업그레이드를 해야 할 것이다. 또, 모든 사용자가 그 어플리케이션을 사용해야 한다면 사용자들의 시스템마다 해당 어플리케이션을 설치해야 할 것이고, 당연히 회사는 적절한 라이센스를 확보해야만 법적인 대항력을 확보할 수 있게 된다. 다른 방법은 없을까? 이런 경우에 Windows2000 터미널 서비스는 역시 해결책이 될 수 있다. 터미널서버에 어플리케이션을 설치하고 사용자들이 그 어플리케이션을 쓰기 위해서 터미널서버로 로그인을 하면 된다. 하지만 터미널 클라이언트들에게 주어진 어플리케이션 이외의 프로그램에는 접근하지 못하도록 제한을 두고 싶다면 다음과 같은 방법을 고려한다.

먼저 클라이언트 연결관리자를 통해서 터미널 클라이언트 연결을 하나 만들어보자. "시작-프로그램-터미널 서비스 클라이언트-클라이언트 연결관리자"를 실행한다.<화면10>

< 화면10. 터미널 서비스 클라이언트 연결 관리자 >

파일메뉴 아래의 버튼을 이용하여 마법사를 시작한다.<화면11>

< 화면11. 클라이언트 연결 관리자 마법사 >

연결 이름을 적절히 입력하고 서버이름 항목에는 터미널 서버의 FQDN형태의 호스트이름이나 IP Address를 입력하고 [다음]을 누른다.<화면12>

< 화면12. 연결 만들기 >

로그온 정보를 입력한다. 터미널서버에 접속할 때 제시할 사용자이름과 암호, 그리고 도메인 이름을 입력한다. <화면13> "이 정보를 사용하여 자동으로 로그온"옵션을 체크하였다.

< 화면13. 로그온 정보 입력 >

화면옵션에서 터미널 서버에 연결했을 때의 해상도를 설정한다. 전체화면 모드에서 보기를 원한다면 "전체화면"옵션에도 체크해 준다.<화면14>

< 화면14. 해상도 설정 >

연결등록정보 항목에서는 느린 네트워크에서의 효율적인 전송을 위해서 "데이터 압축 사용"을 하거나 "비트맵 캐싱" 옵션을 사용하여 성능을 향상시킬 수도 있다.<화면15>

< 화면15. 클라이언트 연결 관리자 마법사 - 연결 등록 정보 >

지금 생성하는 연결이 실행할 프로그램을 지정한다. 서버에서 실행될 것이므로 서버에서 해당 프로그램을 실행하기 위한 경로를 입력한다. 단축아이콘을 생성하면 경로를 쉽게 알 수 있다. 예제에서는 인터넷 익스플로러를 실행할 경로를 입력하였다. <화면16>

< 화면16. 프로그램 시작 경로 등록 >

아이콘을 적절히 변경하고 이 연결을 등록할 프로그램 그룹을 등록한다.<화면17>

< 화면17. 아이콘 변경 >

연결 관리자 마법사를 완료한다.<화면18>

< 화면18. 클라이언트 연결 관리자 마법사 완료 >

클라이언트 연결관리자에 "터미널 서버 엑셀"이라는 아이콘이 생성되었다. 프로그램은 인터넷 익스플로러를 실행할 건데 왜 이름이 "엑셀"이냐구? 내맘이다.<화면19>

< 화면19. 클라이언트 연결 관리자에 추가된 형태 >

이제 클라이언트는 준비가 되었다. <화면13>에서 클라이언트가 로그온 할 때 사용할 정보를 제공하였지만 실제로 테스트를 해 보면 여전히 터미널 서버는 클라이언트에게 계정정보를 새롭게 요구하게 된다. 서버의 기본설정이 항상 로그온 정보를 묻도록 되어 있기 때문이다. 터미널 서버에서 이것을 해제해 보자.

관리도구-터미널 서비스 구성을 열고 연결-RDP-Tcp의 등록정보를 연다.<화면20>

< 화면20. 터미널 서비스 구성 관리도구 >

로그온 설정 탭을 열면 "항상 암호 묻기"라는 옵션이 체크되어 있음을 알 수 있다. 해제한다. "항상 다음 로그온 정보 사용"이라는 옵션을 활성화시키면 이 터미널 서버에 접근하는 사용자는 서버가 설정한 계정으로서 터미널 서버에 연결을 하는 형태가 된다. 터미널 클라이언트에게 계정정보를 요구하지 않도록 할 때 사용되는 옵션이다. <화면21>

< 화면21. RDP-Tcp 등록정보 >

이제 설정을 마쳤다. 터미널 서버에 연결해서 결과를 테스틑 해보자. 터미널 연결 관리자를 통해서 만든 연결을 클릭하면 아래의 <화면22>의 결과를 얻을 수 있다. 로그온이 됨과 동시에 터미널 클라이언트는 인터넷 익스플로러가 실행되는 것을 볼 수 있다. 그 외에 어떠한 작업도 할 수가 없다. 만일 클라이언트가 인터넷 익스플로러를 마친다면 터미널 연결까지 끊기게 된다. 터미널 서버를 어플리케이션 서버 용도로 제대로 구현할 수 있는 방법이라고 하겠다.

<화면22. 터미널 서버에 연결된 화면 >

TCP Window Size의 크기에 따른 영향

새벽예찬 — Mon, 1 Dec 2008 05:41:56 +0900

앞에서 우리는 TCP Sliding Window 에 대해서 알아 보았다. 그러면, 이러한 TCP Window라고 하는 것의 Size의 크기 여부가 네트워크에서 가지는 영향에 대해서 정리를 해 보도록 한다.먼저 정리를 해 보면, NT는 "Window size"는 8K, "Segment Size"는 1K로 설정이 되어 있다. 물론 NT의 Registry를 편집함으로써 수정은 가능하지만 권장하지는 않는다. 이미 우리의 선배들이 시행착오를 거쳐서 최적의 size로서 설정이 되어 있기 때문에 우리는 그러한 문제를 고민하는 것보다는 효율적으로 운영하는데 초점을 두는 것이 바람직하겠다. window size가 너무 작을 경우와 너무 클 경우 어떠한 일이 생길 것인지 알아보자.

(1) Window size가 작은 경우 [그림1~3]

[그림1]

Window size가 1K라고 가정을 해 보면 어떻게 될까? 이제 앞에서 보았던 전송과 응답과정을 이해했다면 금방 알 수 있는 문제다.송신측의 컴퓨터는 1K의 데이터를 전송하고 그것에 대한 응답을 기다릴 것이다. Ack신호가 오면 그 다음 차례인 2번으로 window를 sliding시켜서 또 전송을 시작할 것이다.

하나를 보내고 하나를 받고, 좋아 보이지만 답답한 방법이 아닐 수 없다.

[그림2]

[그림3]

(2) Window size가 큰 경우

Window size가 크다 혹은 작다는 것은 상대적인 개념이다. 네트워크가 얼마나 안정적이며, 또 LAN에서의 통신인지 WAN에서의 통신인지에 따라서 달라질 것이다. 또, WAN구간이라고 할 지라도 56K의 모뎀을 이용하는지 아니면 T3의 빠른 회선을 이용하는 지에 따라서 달라질 수 있다.예제를 통해서 느린 네트워크에서 window size가 큰 경우의 문제를 알아보도록 하자.[그림4]에서는 8K의 window size를 사용하고 있다. 하지만, 문제는 네트워크가 느리다는 데 있다. 속도가 느려서 혹은 트래픽이 많아서 기대되는 응답시간보다 더 오랜시간이 걸려야만 Ack신호를 받을 수 있다고 한다면, 결국엔 송신측 컴퓨터는 미처 Ack신호를 받지 못하고 "Retransmission Timer"의 시간이 만료되어 같은 데이터를 재전송해야 하는 일이 많아지게 될 것이다. 당연히 비효율적인 네트워크가 운영이 될 것이다..

[그림4]

이런 경우라면 오히려 window size를 보다 작은 size로 줄이는 것이 현명한 방법일 것이다. 위의 2가지 예제의 경우에 TCP는 "Connection Oriented protocol"이라는 가장 큰 장점이 오히려 적절하지 못한 window size로 인해서 비효율적인 Protocol이 될 수도 있다. 적절한 window size를 사용하게 된다면 TCP의 장점을 극대화한 최적의 네트워크를 구성하게 될 것이다.

TCP Sliding Window

새벽예찬 — Mon, 1 Dec 2008 05:38:08 +0900

TCP/IP Protocol Suite중의 하나인 TCP는 TCP Host간에 효율적인 데이터 전송을 위하여 "Window"라고 부르는 Buffer를 이용한다. Window는 TCP/IP통신을 원하는 컴퓨터(일반적으로 Host라고 부른다)가 송신, 혹은 수신할 수 있는 size를 가리켜 준다.

이러한 window라는 것을 이용하여 호스트간에 전송을 하고 받는 과정중에, 네트워크의 트래픽 혹은 호스트의 불안한 요소등 여러 가지 원인에 의하여 전송되는 데이터의 손실이 생길 수 있는 경우가 발생하게 된다. 반대로 안정적인 네트워크 상황하에서 보다 많은 데이터를 전송할 수 있음에도 TCP가 제공하는 가장 큰 특징중의 하나인 "확실한 전송"이라는 책임 때문에 오히려 비효율적인 전송을 하게 되는 경우도 있게 될 것이다. 이러한 요소들을 모두 고려하여 가장 효율적인 데이터 전송방법으로써 "Sliding Windows" 라는 기법을 사용하여 호스트 간의 통신에서 최적의 성능을 제공할 수 있게 된다.

그러면, 실제로 호스트간의 TCP/IP통신 중에서 "TCP Sliding windows"라는 기법이 무엇인지, 어떻게 동작을 하는지 차근차근 접근해 보도록 하자.

[그림1]

TCP/IP를 사용하는 모든 호스트들은 각각 2개의 window를 가지고 있다. 하나는 보내기 위한 window, 또 다른 하나는 받기 위한 Window이다.

[그림2]

호스트들은 실제 데이터를 보내기 전에 먼저 "TCP 3-way handshaking"을 통하여 수신컴퓨터의 receive window size에 자신의 send window size를 맞추게 된다. 상대방이 받을 수 있는 크기에 맞추어 전송을 하겠다는 것이다.

[그림2]의 "A"컴퓨터가 "B"컴퓨터에게 10K byte size의 데이터를 전송하려 한다고 가정을 해 보자.또, 이 컴퓨터의 "window size"는 8K이고, "TCP Segment Size"는 1K라고 가정을 한다. 사실 이것은 우리가 가장 많이 사용하는 Ethernet환경에 최적화된 size이기 때문에 NT는 기본적으로 위와 같은 windows와 segment size를 이용한다."TCP Segment Size"는 Application이 만든 데이터를 TCP가 받아서 IP에게 전달해서 통신을 하려고 할 때, IP에게 전달해 주는 데이터 패킷의 크기이다. 결과적으로는 실제 데이터를 TCP가 보다 작은 크기로 나누게 되는데, 이 때 나누게 되는 크기를 가리켜서 "TCP Segment Size"라고 부른다.예제의 경우와 같을 때, "A"컴퓨터는 "B"컴퓨터에게 데이터를 전송하기 위해서 먼저 10K크기의 데이터를 1K크기로 나누게 된다. 당연히 10개의 패킷으로 데이터가 나뉘게 될 것이다. TCP는 1K로 나눈 데이터마다 순서를 붙이게 된다. 1번부터 10번까지 번호를 붙이고, 1번부터 데이터 전송을 시작하게 된다.

TCP의 특징은 "신뢰성있는 전송"을 보장한다는 데 있다. 1번을 보내고, "A"컴퓨터는 "B"컴퓨터로부터 잘 받았다는 확인 메시지(Acknowledgement)를 받을 때까지 기다리게 된다. 마침내 Acknowledgement 메시지가 오면 "A"컴퓨터는 그 다음 순서인 2번 데이터를 전송한다. 생각하기에는 당연한 이야기고 그런대로 쓸 만한 방법이라고 생각할 수도 있겠지만 지극히 비효율적인 방법이다. "A"컴퓨터는 1번 데이터를 보내고 나서도 충분히 다음 데이터를 보낼 여유가 있지만, 응답을 받을 때까지 기다리고만 있어야 한다는 것이다. 만일 회선상의 문제가 있어서 Ack신호가 더욱 지연된다면 그 결과는 당연히 영 아닌 상태의 네트워크 통신을 지켜 봐야만 할 것이다. 이러한 문제점을 해결하기 위해서 TCP는 데이터를 낱개단위로만 처리하지는 않는다는 것이며, 그때 한꺼번에 전송하는 데이터의 크기를 바로 "Window Size"라고 부르는 것이다.

[그림4]

[그림4]처럼 호스트는 자신이 보내야할 전체 데이터 중에서 사용가능한 Window size만큼 데이터를 전송하기 시작한다. 위의 예제에서 window size는 8K이다. 1번부터 8번까지 순차적으로 계속해서 데이터를 내 보내게 되는 것이다. 그리고 나서 이 호스트는 상대방의 응답을 기다리게 된다. 단순하게 생각해도 일단은 하나씩 보내고 응답을 기다리는 것보다는 효율적인 방법일 것이다. 성공적으로 통신이 되어서 상대방으로부터 응답이 온다면 그때 "A"호스트는 나머지 남은 9번, 10번의 데이터를 전송한다.이것이 "TCP Sliding Windows"라는 기법이다. window size만큼 데이터를 전송하고, 상대방으로부터 Ack신호가 올 때까지 기다렸다가 Ack신호가 오면, window를 이동(Slide)시켜 다음 순서의 TCP데이터를 전송하는 방식을 말한다.

하지만, 역시 이것만으로는 뭔가 비효율적인 면이 여전히 남아있다. 1번부터 8번까지 데이터를 전송하고 상대방으로부터 1번부터 시작하여 자신이 보낸 데이터의 마지막인 8번까지의 데이터에 대한 Ack신호가 올 때까지 기다려야 한다면 어리석은 일이 아닐 수 없다. 우리가 생각하는 정도는 이미 TCP/IP를 개발한 개발자들도 충분히 고려했던 부분이었기에 그것에 대한 생각도 물론 했을 것이다. 그렇기 때문에 보다 효율적인 방법을 채택했다.

[그림 5]

일단 보내는 쪽의 TCP는 window size만큼 한꺼번에 데이터를 전송하고, 받는 쪽에서의 Ack신호가 오면 오는대로 바로바로 window를 Sliding시키는 방법이 그것이다. 다시 말하면 굳이 자신이 발송한 마지막 데이터에 대한 Ack신호가 오지 않더라고 일단 그 전의 데이터에 대한 Ack가 오게 되면 그만큼은 여분의 window size가 생긴 것이기 때문에 추가로 더 전송할 여유가 생겼다는 의미이다.

[그림 5]에서 보면 window가 이동한 그림을 볼 수 있다.예제의 경우는 받는 쪽에서 2번까지의 데이터를 잘 받았다는 Ack신호를 발송해 주게 되면 그때 "A"컴퓨터는 1,2번 데이터는 제대로 전송해야 할 책임을 완수했기 때문에 window를 이동시켜서 그 다음 순서의 데이터인 9번과 10번을 전송할 수가 있게 되었다. 추가로, 받는 측인 "B"컴퓨터는 패킷 하나마다 계속해서 Ack신호를 전송한다는 것은 역시 그것도 하나의 트래픽을 발생시키는 것이기에 약속을 해 두었다. 적어도 2개 이상의 연속된 패킷이 들어왔을 때 Ack신호를 전송하도록 한 것이 그것이다.

[그림6]

[그림6]에서처럼 1번과 3번 패킷이 도착을 했지만, 중간에 이빨이 빠진 채로 2번이 아직 도착을 하지 않았다라고 가정을 해 보자. 그렇게 되면, 받는 측의 TCP는 2개이상의 연속된 패킷이 도착하면 전송을 하자는 약속을 해 두었기에 마냥 기다려야 할 것이다.

그래서 만일의 경우를 대비하여 한가지 해결책을 강구해 두었다. 받는 측의 컴퓨터는 패킷이 도착하였을 때, "Delay Acknowledgement Timer"라고 부르는 Timer를 설치하게 된다. 이 Timer의 시간이 만료될 때까지 2번 패킷이 도착하지 않는다면, 받은 1번 패킷에 대한 Ack신호만이라도 전송을 해 주는 것이 보다 효율적이기 때문이다.

[그림7]에서 보면, 받는 측의 TCP는 1번 패킷에 설치해 둔 Timer가 만료되었고, Ack신호를 전송하고 있다.

[그림 7]

송신컴퓨터는 이렇게 수신컴퓨터의 Ack신호를 받고, window를 sliding시켜서 다음 신호를 전송하는 방식을 쓰고 있지만, 또 한가지 문제가 여전히 남아 있다. 만일 무슨 이유에선지 Ack신호가 전혀 오지 않는 상황이라면 어떻게 해야 할까? 이러한 문제를 해결하기 위해서 송신컴퓨터의 TCP는 자신이 보낼 수 있는 Window Size만큼 데이터를 전송하고 자신이 보낸 데이터에 대해서 각 Segment마다 "Retransmission Timer"라고 불리우는 timer를 설치 해 둔다. 만일 이 timer의 시간이 만료될 때까지 Ack신호가 도착하지 않으면 재전송을 하기 위한 배려이다.

[그림 8]

결국, TCP는 window size를 이용해서 한꺼번에 일정량의 데이터를 전송하며, 보다 효율을 기하기 위해서 이러한 window를 Sliding시키는 방식을 이용하여 계속적인 데이터 전송을 할 수 있도록 하고 있다. 여기에서 생길 수 있는 문제점들을 "Delay Acknowledgement Timer"와 "Retransmission Timer"를 이용해서 대비책을 마련해 두고 있는 것이다.

이상 TCP Sliding windows에 대해서 정리해 보았다. 다음엔 이어서 TCP Window Size가 네트워크에 미치는 Performance에 대해서 알아보도록 하자.