구글와이드(336x280)_상단 2개


WEB SEVER & PROXY SEVER 구축 홈피 제작 관련지식

2.WEB SEVER & PROXY SEVER 구축 Network
2006/02/01 12:24
chap 2. WEB SEVER & PROXY SEVER 구축
0. WEB 이란 무엇인가?
월드 와이드 웹은 인터넷에서 HTTP 프로토콜을 지원하는 서버와 클라이언 트의 모임이다. 지금 이 순간에도 전세계에서 새로운 서버와 클라이언트가 웹에 연결되고 있다.

모든 온라인 서비스가 이미 WWW 접속을 지원하고 있거나 빠른 시일 안에 지원할 것이라고 발표했다.

1. 클라이언트와 서버
클라이언트는 무엇인가를 원하는 프로그램이다. 서버는 무엇인가를 제공하는 프로그램이다. 클라이언트는 여러 서버에 요청 할 수 있다. 서버는 여러 클 라이언트에게 뭔가를 제공할 수 있다.

보통 클라이언트 쪽에서 서버와의 대 화나 세션을 시작한다. 서버는 항상 수행되고 있으면서 클라이언트의 요청을 기다린다. 클라이언트는 사용자나 프로그램의 요청에 의해 동작된다. 프로토 콜은 클라이언트가 서버에게 요청을 하고 서버가 요청에 응답하는 방법에 대한 정의다.
월드 와이드 웹 클라이언트로는 보통 NCSA 모자이크(Mosaic),넷스케이프 내비게이터,마이크로소프트 인터넷 익스플로어,LYNX 등이 있다. 서버는 여 러 NCSA,CERN,마이크로 소프트,넷스케이프,오라클,그 밖의 많은 회사의 것 이 있다.
2. 월드 와이드 웹의 기원
Atlantic Monthly 의 1945 년 8 월호에 바네바 부시(Vannevar Bush) 의 에 세이 "As We May Think" 에 실린 이후 전자적으로 연결된 문서에 대한 개념이 정보 학자들과 도서관원, 작가들의 머리를 맴돌기 시작했다.

작가들 은 부시의 글 훨씬 이전부터 지식의 연결을 예상했다. 각주가 잉크와 종이 대신 하이퍼링크로 바뀌었다. Ezra Pound 의 참조와 다른 작가들로부터의 차용도 마찬가지 경우다. T.S Eliot 의 The Waste Land ,로버트 프로스트의 New Hampshire : A Poem with Grace Notes , Vladimir Nabokov 의 Pale Fire 는 종이 위에서 하이퍼텍스트를 시도해 본 경우이다.

요점은 하이퍼 텍 스트와 같은 것이 오랫동안 요구되고 있었다는 것이다. 그러나 이 생각을 전자 기술로 연관시킨 것은 부시였다. 부쉬는 전쟁에서 생 겨난 새로운 기술이 우리의 사고 방식을 확장하는데 적용될 수 있다는 것을 예견했다.
이상한 기록과 재생 장치가 있는 Memex 에 대한 그의 설명이 그의 맹목적 인 사회적 관점(모든 과학자는 남자이고 모든 비서와 서기는 여자라는)처럼 낡은 것이긴 하지만 우리가 조직화하고 정보를 사용하는 방법에 대한 부쉬 의 기본착상은 오늘 우리가 월드 와이드 웹과 하이퍼텍스트로 알고 있는 것 들의 기초가 되어왔다.
1965년 테드 넬슨이 발명한 하이퍼 텍스트(hypertext)는 선형으로 제한되지 않는 텍스트를 뜻한다. 선형이라는 말은 대부분의 글에서 한 문장 다음에는 또 다른 문장이 나오고 , 한 문단 뒤에 다음 문단이 나오고 ,하나의 개념 뒤 에는 다음 개념이 따른다는 것이다.

하지만 하이퍼 텍스트에서는 한문장 안 에서도 독자들이 여러 경로를 거쳐 여러 가지 개념에 도달할 수 있다. 다시 말하면 하이퍼 텍스트의 일부 또는 전체가 선형일수 있지만 역시 문서의 일 부나 전체가 비선형일 수도 있는 것이다.

하이퍼텍스트는 다른 텍스트로의 링크나 참조를 이용해 선형의 한계를 벗어난다.
하이퍼미디어는 비선형방식으로 다른 미디어에 연결되는 미디어 (텍스트,그 림,사운드,비디오등)를 뜻한다. 하이퍼텍스트는 하이퍼 미디어에 속한다. 하이 퍼텍스트는 집중력이 부족하고 책상이 지저분한 , 책한 권을 다 읽지 못하고 여섯 권을 동시에 조금씩 보는 사람,여행중에 길을 잃으면 당황하지 않고 재 미있게 생각하는 사람들을 위한 구제 수단으로 생각해도 된다.

물론 부정적 관점으로 보면 하이퍼텍스트는 우리의 다소 불안정한 마음, 사무, 생활을 비 추는 거울이라고 할 수 있다. 또한 하이퍼 텍스트는 끝에 몇 가지 정보가 있 는 구부러진 길을 지나는 자동차라고 생각해도 된다.
이 때문에 우리는 찾고 있는 것에 도달할 때까지 여기서 조금 저기서 조금 씩 읽게된다.

첫 번째 하이퍼 텍스트는 테드넬슨과 마우스의 발명자인 더글 라스 엘겔바트가 구현했다. 두 사람이 구현한 하이퍼 텍스트는 모두 1960년 대의 기술과 복잡한 설계과정 때문에 제한적이었다. 두 계획 모두 구현하기 불가능한 면이 있었다. 예를 들어 넬슨은 그의 계획 재나두(Xanadu)가 모든 저작권과 회계 문제를 다루도록 제안했다.넬슨에 따르면 이 확고함을 위해 재나두는 전 세계의 문학 전집을 온라인으로 올리는데 사용되어야 한다.

1987 년 제프콘클린은 IEEE 간행물에서 18 가지 하이퍼텍스트/하이퍼미디어 구현 을 검토하였다. 흥미 있게도 여덟 가지만이 다중 사용자가 호용 되며 이 여 덟가지중 네 경우만 그래픽을 구현한다. HTML과 다른 WWW문서를 다룰 프로토콜은 Hyper Text Transfer Protocol 이라 부리게되었다. 이는 모든 프로토콜이 이름이 TP 로 끝나는 인터넷의 전통을 따른다. 서버 는 HyperText Transfer Protocol damon 즉 HTTPd라 불리고 이것도 대몬 의 스펠링에서 따온 d 로 독립 프로세서의 이름을 끝내는 유닉스 전통을 따 를 것이다.
1991년 10월 중 팀의 소프트웨어를 CERN에서 얻을 수 있다고 유스넷 뉴스 그룹 alt.hypertext , comp.sys.next , comp.mail-media 에 발표되었다. 불행 히도 이 소프트웨어는 재미있지만 널리 쓰이지 않는 넥스트 워크스테이션에 서 동작했다.
팀은 그해 10월 텍사스 샌 안토니오에서 열린 HyperText'91 회의를 포함해 여러 회의에 WWW를 발표하였다. 회의의 다른 발표자들 가운데 두 사람은 오토데스크에서 나왔다. 어떤 사람은 오토 데스크가 재나두의 지원을 중단한 것이 팀의 WWW 발표 직후라고도 이야기한다.
WWW 는 1992년 7월에 CERN 전체에 배포되었고 여기에 라인 모드 클라 이언트와 같이 포함된 넥스트스텝 클라이언트 비올라(viola)는 드랙엔드롭 페 이지 제작과 연결이 가능했다. 라인 모드 클라이언트는 모의 VT-100환경 (VT-100은 제작 중단되었으므로 실제 VT-100은 아니다)에서 동작하도록 만들어진 텍스트 전용브라우저이다. WWW는 열렬히 환영받았고 곧 인터넷 에 널리 퍼지게 되었다.
1993년 1 월에 세계에는 WWW 서버가 50개 알려져 있었다. 그중 하나는 노 스 캐롤라이나 대학에 있었다. 여러 개의 브라우저가 공개됐고 거기에는 매 킨토시와 X원도우 클라이언트도 들어있었다.그 다음 날 Urbana-Champagne 에 있는 일리노이 대학에 있는 국립 수퍼컴퓨팅 응용센타(National Center For SuperComputing Applications(NCSA)에서 새 클라이언트가 공개되면서 WWW 는 모양을 갖추기 시작했다.
3. NCSA 모자이크
모자이크가 나오기 전에는 WWW 의 문제점 중 하나는 대부분의 컴퓨터와 운영체제에서 믿을 만한 브라우저나 클라이언트가 없다는 점이다. CERN 은 주로 문서 공유와 연결등 초기 구현에만 초점을 맞추었다.

팀과 그의 개발팀 은 CERN 의 특정한 요구에 맞추어야 했고 마감일 때문에 서둘러야 했다. 하지만 CERN 은 넥스트를 사용했고 서버에 더 관심이 있었기 때문에 맥과 X 원도우 브라우저를 발표하긴 했지만 불안정하고 투박했다.

반면에 NCSA 는 크로스 플랫폼 클라이언트 개발 경험이 있었다. 반면에 NCSA는 크로스 클라이언트 개발 경험이 있었다. NCSA Telnet 클라이언트는 아직도 널리 사용된다.
Jow Hardin 이 이끄는 NCSA 시스템 개발 그룹은 WWW뿐 아니라 팀 버너 스 리 가 말한 것처럼 여러 프로토콜을 지원하는 유용한 WWW 브라우저를 만들기 위한 프로젝트에 착수했다. 이 클라이언트는 모자이크로 불렀고 X 원도우용으로 1993년 2월에 공개 됐다.
그달말에 마크 엔드리센은 www-talk@cern.ch 에 HTML 의 간단한 확장을 설명하였으며 마크는 이미지가 tag를 이용해 브라우저 안에 들어가야 한다 고 제안했다. 마크의 간단한 제안은 WWW이 발전할 방향에 대해 많은 것을 제시했다.
《IMG》태그가 추가되면서모자이크는 진정한 멀티 미디어가 되었다. 갑자기 하이퍼 텍스트 페이지가 더 친숙하게 보이기 시작했다. 다른 과학자들과 학 자들은 과학적 학술적 정보를 무미건조하게 보여주는 대신 , 페이지에는 과 학자들이 몇 년간 같이 일하면서 만나보지 못한 사람들의 사진이 실렸다. 이 페이지의 제작자들은 시각적으로 만족스러운 페이지를 만들 기회가 생긴 것 이다.
태그가 만들어지기 전까지 HTML 은 매우 제한적인 SGML 의 구현이었다. SGML 은 문서의 구조를 정의하기 위한 언어이지 그것을 표현하기 위한 것 은 아니다.
1993년 12월 존 마콥은 New York Times 비즈니스 면에 모자이크를 인터넷 의 경이적이 애플리케이션으로 극찬하는 기사를 썼다. 이 기사는 모자이크 페이지의 화면 사진을 실었고 모든 사람들이 넓게 퍼진 네트워크에서 이미 지와 텍스트가 통합되는 것이 중요한 이유를 깨닫기 시작했다. 화면 사진은 " 여기에 광고를 실으시오" 라고 번쩍이는 거대한 게시판처럼 보였다.
WWW는 1992년 12 월에 인터넷 백본에서 78 메가 바이트를 차지했지만 1993년 12월에는 225,443 메가 바이트로 급격히 성장하였다.
1994년 11월에 는 WWW 사용량은 3,126,195 메가 바이트 이상이었다. 성장 패턴은 명백했 다. CERN 의 서버개수는 1994년 6월까지 1500 개로 늘었다. 1995년 인터넷 도메인 수가 거의 100배 늘었고 서버의 수는 거의 측정하기 어렵다. 웹은 성숙하여 바로 인터넷이 오랫동안 필요로 했던 것이 되었다. 깔끔한 그 래픽 사용자 인터페이스를 통해 도달할 수 있는 무질서하고 널리 분포된 세 계가 생겨났다.
4. 하이퍼 텍스트 전송 프로토콜
HTTP 는 클라이언트 서버 정조 분산 모델을 기초로 한다. 이 모델은 Network Working Groups Internet Draft of HTTP specification 의 용어로 는 "요청/응답 패러다임"이다. 이는 월드 와이드 웹에서 구할 수 있는 정보 는 중심장소 ("서버")에 저장되어 사용자의 PC("클라이언트")에 있는 프로그 램을 통해 사용자의 요청에 따라 이용된다.
5. HTTP 의 동작
HTTP 는 클라이언트로부터 서버로 서버로부터 클라이언트로 메시지를 전 달한다. 클라이언트가 서버에 보내는 메시지는 여러 가지가 있지만 GET,HEAD,POST 의 세 가지가 흔히 쓰인다.

이 메시지들은 여러 종류의 정보를 보내라는 클라이언트의 요청이다. 예를 들면 GET 요청은 웹페이지 를 보내 달라고 할 때 사용된다. 클라이언트는 GET URL 다음에 캐리지 리 턴이 오는 형식으로 요청을 보낸다. 이는 지정된 URL 에 있는 파일이나 문 서를 보내달라고 서버에게 요구하는 것이다. 서버로부터의 응답은 사용된 HTTP 버전 ,요청상태(예를 들면 OK,Not Found)문서의 MIME 타입 등의 정보로 시작하여 문서의 본문(BODY) 으로 구성되다.
HEAD 요청은 서버에게 본문을 제외하고는 GET 요청 때와 같은 정보를 보 내라고 요구한다. HTML 문서에서는 여기에〈TITLE〉,〈META〉,〈LIN K〉, 〈BASE HREF 택에 지정된 모든 정보가 등이 있다.〉 HEAD 요청은 "로봇" 이라는 프로그램들이 사용된다. 로봇은 헤더 정보를 요청하여 URL 이 유효한지 통계적 정보를 수집하고 웹페이지의 본문이 필요 없는 기타 다 른 기능을 수행한다. POST 요청은 서버에게 정보를 보낸다.

여기엔 뉴스그 룹에 메시지를 게시 할 때의 형식이나 폼을 사용한 전송 또는 웹페이지와 인터페이스간에 스크립 인터페이스를 사용한 데이터 베이스로의 전송과 같 은 형식이 있다.
클라이언트-서버 모델은 많은 특징이 있다. 첫 번째로 정보는 요청에 의해서 만 전송되므로 TV 광고처럼 사용자에게 강요 될 수 없다. 사용자는 정보를 얻을 특정 서버에 접속할 것인지 확인해야 되고 관심이 없는 내용이라면 보 지 않아도 된다. 클라이언트-서버 모델로 인한 또다른 중요한 요소는 모든 정보가 서버에서 제공되어야 한다는 것이다.

이 는 서버 하드웨어가 다수의 동시 사용자들에게 모든 정보를 전해줄 능력을 갖추어야 한다는 뜻이다. 이 때문에 항상 고려되어야 요소가 몇 가지 있는데 페이지에 들어가는 이미지 의 크기 한 페이지의 길이 스크립에서 사용하는 시스템 호출의 종류들이다. 각각의 페이지를 로드하는데 부하가 많이 걸릴수록 서버의 부담이 커진다. 서버 컴퓨터에 걸리는 부하와 히트(클라이언트에서 서버로의 요청 )의 횟수 는 사용자가 정보를 이용하는데 걸리는 시간을 증가시킨다.
HTTP 대몬 ( damon 컴퓨터가 HTTP 클라이언트에게 정보를 제공하도록 하는 프로그램) 은 클라이언트의 요청을 받아서 처리한다. 대몬이 요청을 받 을 때마다 그 요청을 처리하기 위한 새 프로세서를 만든다.

보통 프로세서들 이 응답하고 작업을 끝내는 속도가 매우 빠르므로 프로세서를 많이 만드는 것은 문제가 되지 않는다. 그러나 HTTP 대몬의 대부분은 요청에 응답하는 프로세서를 한번에 하나씩 만들기 때문에 사용자들이 많을 때에는 대몬이 중복 로드될수 있어서 요청에 따라 프로세서를 재빨리 만들지 못한 게 된다.

이 상태는 지연시간(클라이언트의 브라우저에 페이지가 나타나는데 걸리는 시간)의 세 가지 주요 이유중 하나이다. 한번에 하나씩 요청을 처라 하는 것 은 지연시간의 두 번째 요인과 관련되어 있는데 바로 부하 즉 매번 마다
CPU 가 해야할 작업량이다. 히트가 많은 컴퓨터는 여러 개의 프로세서를 실 행해서 이 프로세서들끼리 시간을 다투게된다. 두 가지 문제 모두 방치하거 나 최소화 할 수 있다. 사이트를 선택적으로 조장 다시말 하면 인터넷 사회 안의 특정 집단으로 광고를 집중시키므로 서 가능하다. 필요에 알맞은 HTTP 대몬 소프트웨어를 선택하는 것 과 이들 문제를 감소시킬 수 있도록 개선된 최신버전을 이용하는 것이 중요하다.
사이먼 스페로의 HTTP-NG 제안은 서버로드에 기인한 지연시간에 관한 현 재의 HTTP 규정의 문제를 다루려는 것이다. 스페로의 업적은 한가지 명령 으로 여러 개의 요청이 만들어 질 수 있다는 생각이다. 부하가 심한 페이지 는 25 또는 30 개의 GET 타입이 아니라 하나의 GET 으로 요청될 수 있다 는 것이다. HTTP-NG 의 프로토타입을 테스트한 결과 부하가 많이 걸린 서 버에서 극적으로 서버 수행능력이 향상되었음을 알 수 있다.
지연시간의 세 번째 주 요인은 대역 폭의 양이다. 인터넷 연결은 한번에 전 송할 수 있는 정보의 양이 한정되어 있다. 저 용량 연결에선 서버가 이 한계 를 초과하기 쉽다. 사이트에 무엇을 올려야 할지 결정하는데 연결의 종류( 예를 들면 SLIP,T1,56Kbps)를 고려하여야 한다.

HTTP 와 같이 유동적인 프로토콜의 아이러니한 특징이다. HTTP 는 여러 종류의 파일을 허용하기 때문에 공급자들이 하드웨어의 초과하는 정보를 서비스하려 하게된다. 새로 정의된 PUT 명령으로 서버는 더 대화적일 수 있지만 아직까지는 하나 의 서버에 서에서만 구현되었다.

그 서버는 Jigsaw 인데 선 마이크로 시스템 의 객체지향, 네트워크 분산, 크로스 플랫폼,buzzword compliant 언어인 자 바(JAVA) 로 완전히 작성되었다. Jigsaw 의 혁신적인 점 하나는 서버가 많 이 요청 받는 파일을 일시 저장하여 매번 디스크에서 읽을 필요 없이 메모 리에서 읽을 수 있도록 해주는 읽기-쓰기 공간이 있다는 것이다. 자바로 작 성되었으므로 확장이 용이하며 능력 있는 프로그래머라면 알맞게 변형하는 것도 쉽다.
HTTP 의 한계를 늘어놓았지만 대체로 대부분의 서버에서 이런 문제는 심 각하지 않다. HTTP 는 강력한 프로토콜로서 클라이언트에게 매우 빠르게 멀티미디어 정보를 전송할 수 있다.
TCP 연결이 다른 전송층 보다는 비교적 싸지만 기존연결에서 패킷 하나를 보내는 것보다 새로 연결을 설정하는 것이 훨씬 더 비싸다. 그 이유는 상대 성 이론의 불쾌한 결과에 기인한다. 빛의 속도를 바꿀 수 없으며 그 속도를 넘을 수도 없다.

웹이 입자 물리학자들을 위해 만들어 졌지만 그들에게도 마 찬가지다. TCP로 연결을 오픈 할 때는 "핸드 세이크" 즉 연결 요청을 서버 에 보내고 응답을 기다려야 한다. 기다리는데 걸리는 시간을 라운드 트립 타 임(Round Trip Time) 즉 RTT 라고 한다. 연결을 오픈 하면 HTTP 전송에 추가로 RTT를 더하게 된다.
인터넷 초기에는 TCP 연결은 데이터를 원하는 만큼 빨리 보낼 수 있었다. 수신자에게 보내는 것만큼의 용량이 있다면 연결이 허용하는 한 마음대로 퍼 담을 수 있었다. 불행히도 이런 연결은 분주한 네트워크를 포화 상태로 만들었다. 1980년대 후반에 인터넷의 정체현상인 congestion collapse 의 기 록된 사례가 몇 개 있었다.

Congestion collapse 에서는 네트워크가 너무 분 주해서 네트워크 중앙의 라우터의 큐가 가득 차버린다. 패킷이 큐를 거쳐가 는데 시간이 너무 오래 걸려서 송신자가 패킷이 소실되었다고 생각하고 다 시 보내게 된다. 이 상황은 악순환 되어 네트워크의 전송 량이 많아지면 네 트워크로 들어오는 전송 량이 더 많아진다. 정체방지와 조절이 모든 전송 프 로토콜이 인터넷에서 사용되기 전에 지나야 할 장애물이 되어 왔다.
TCP는 이런 정체를 방지하기 위해 특별히 신경 쓰고 있다. 로렌스 버클리 국립 연구소의 밴 자콥스(Van Jacobson)은 이런 종류의 연결이 인터넷에 지 나친 부담을 주지 않도록 하는 중요한 변화는 slow-start 라는 알고리즘 이 는 모든 TCP 구현에 필요하다.
이름에서 알 수 있듯이 slow-start 는 TCP 연결이 처음에는 늦게 시작하고 서버로의 경로가 전송을 감당할 수 있을 때만 속도가 증가하도록 한다. 패킷이 승인될 때마다 congestion 원도우가 증가한다. 패킷이 유실되면 원도 우는 반으로 줄어든다. 이렇게 몇 번을 주고받아야 보내는 사람이 최고 속도 를 얻을 수 있다. 연결이 오랫동안 우회한다면 이것은 문제가 되지 않는다. 불행히도 대부분의 HTTP 연결은 클로즈될때까지 최고 속도에 이르지 못한 다. 다음번 요청도 같은 과정을 거친다.
HTTP 1.X 는 제한적으로 메타 정보를 사용할 수 있다. 문서의 종류의 길이 변경일시 등을 전할 수 있다. 이것으로는 사람이 문서에 대한 목록을 만들거 나 컴퓨터에게 설명해 주기에 부족하다.
HTTP-NG 에는 더 풍부한 메타 정보 모델이 있다. 임의로 사용자가 정의한 태그로 문서에 대한 설명을 넣을 수 있다. 위의 교섭과정에서 이 태그들이 결정된다. 디폴트 태그는 HTTP 1.0 에 정의된 태그와 USMARK(라이브러 리 커뮤니티의 표준태그) 의 태그로 구성된다.
새로운 이들 태그로 자동 인덱스 생성기는 문서를 더 잘 조직화하고 컴퓨터 는 이들을 더 잘 처리할 수 있다. 저작권 고지를 디스플레이 하거나 버전표 시 기타 다른 잡일을 처리하는데 이들 태그를 사용할 수 있다. 교섭과 자바 와 같은 동적 언어를 혼합하여 사용하면 웹이 지금보다 더 빨리 성장할 수 있을 것이다.
6. 서버 설정
HTTP 는 간단한 비지속형(stataless) 프로토콜로서 프로그래머가 클라이언 트와 소프트웨어를 구현하기 쉽도록 구성되었다. 이런 평이함 때문에 여러 회사와 조직 개인이 HTTP 서버 소프트웨어를 작성했다. 이들 각각은 나름 대로의 기능과 취약점이 있다. 이런 다양함이 웹마스터에게 많은 선택의 기 회를 줄 수도 있지만 혼란스러울스도 있다.
웹이 생겨난 첫해에는 무료 서버 소프트웨어들이 시장을 지배했다. 그러나 빠르고 설정하기 쉬운 사용 품이 나오자 프리웨어의 사용이 줄어들었다.그와 동시에 많은 개발자들이 가장 인기 있는 서버소프트 웨어 패키지인 NCSA HTTPd의 발전이 느리다고 생각했다. 상용제품들 보다 더 품질 좋은 무료 소프트웨어가 있다는 것을 증명하기 위해 이 개발자들을 모아서 NCSA 서버 를 개선시키는 패치를 제작하여 "패치서버"즉 아파치 서버가 만들어 졌다. 아파치는 계속 새로운 기능을 추가하였고 서버에 새로운 아이디어를 넣고 싶어하는 프로그래머들에게 용이한 명령들을 제공했다. 1996년 6월 1일의 조 사에 의하면 아파치는 가장 널리 사용되는 HTTP 서버 소프트웨어이다. 아파치 에 관련된 조정(configuration) 파일이 세 가지 있다.
이들은 /user/local/etc/http/conf 에 있다. 이 조정 파일들은 서버의 모든 동작을 제 어한다. 이 조정 파일들은 서버의 모든 동작을 제어한다. 이 파일들을 마음 에 맞게 편집했으면 서버를 운영할 수 있다. 더 이상의 조정은 필요 없다. 먼저 서버의 조정 디렉토리인 /user/local/etc/httpd/conf에 갈 수 있다. 이들 은 참조를 위한 것이므로 직접 편집하면 하면 안된다. 서버를 조정하기 전에 복사 해야한다.
$ for I in *-dist
〉do
〉mycopy = 'basename $ i -dist'
〉cp $i $ mycopy
〉done
ServerType

이 지시자의 디폴트는 Servertype standalone 이다. 스텐드 얼론 서버는 부 팅때시스템 시작 스크립트에서 기동된다. 이 설정은 수행능력을 높이기 위해 권장된다. 스탠드 얼론 대신에 inetd를 사용할 수 있다. inetd는 유닉스용 인 터넷 슈퍼 유저이다. 대부분의 네트워크 서버는 HTTP 서버가 감당하는 초 당 수십 번의 연결에 비하면 드물게 사용된다. 텔넷처럼 인기 있는 서비스도 수분당 한번 꼴이다. 각각의 인터넷 서버마다 스탠드 얼론 서버를 돌린다면 CPU 타임이나 메모리와 같은 시스템 자원이 놀고 있는 서비스 때문에 낭비 될것이다.이 문제 대한 유닉스의 해결책이 inetd 이다.
Port

이 지시자 는 스텐드얼론 모드를 사용하는 경우 서버가 동작하는 네트워크 포트를 지정한다. (inetd를 사용하면 /etc/services에서 포트를 지정해야한다) 디폴트는 Port 80 으로 웹브라우저가 연결을 예상하는 포트이며 HTTP 의 표준 포트 사이즈다.사이트내의 주 서버라면 이 설정을 권장한다. 이 포트나 1024 미만의 다른 포트에서 운영하려면 시스템 운영자(루트)권한이 있어야 한다.
Hostname Lookups

아파치는 서버의 동작을 로그 파일에 기록하여 나중에 볼 수 있다. 로그 파 일 중에 어떤 컴퓨터가 서버에 접속하였는지를 기록하는 것도 있다. 로그 파 일 중에는 어떤 컴퓨터가 서버에 접속하였는지를 기록하는 것도 있다.

HostnameLookups 지시자 는 서버가 클라이언트 컴퓨터의 이름을 로그에 기 록할 것인지 (예를 들어,macl.shoop.com) 또는 IP 어드레스만 (예를 들어 152.2.22.81) 기록할 것인지를 정한다. 디폴트 서버는 컴퓨터 이름을 기록 하 지만 사용량이 아주 많을 것 같지만 호스트 이름 검색을 끄면 서버의 부담 이 조금 줄어들 것이다. 검색을 끄기 위해서는 "HostnameLookups off"로 고 치면 된다.
User & Group

이 항목은 스탠드 얼론을 사용할 때 실제적인 사용자와 그룹퍼미션을 정한 다.(inetd를 사용한다면 대부분의 유닉스 시스템은 /etc/inetd. conf 에 그룹을 지정하여야 한다.)사용자와 그룹이름이나 etc/passwd 와 /etc/group에 주어진 대응하는 숫자를 사용하여 지정할 수 있다. 디폴트 사용자는 nobody 이며 보안을 고려할 때 이것이 최선이다. 이렇게 하면 웹서버가 world readable 파일과 디렉토리에만 접근할 수 있다.
ServerAdmin

사이트의 웹 관리자의 공식 전자 우편 주소이다. 보통 webMaster@yoursite 형식으로 하는 게 좋다. 여기서 yoursite는 서버 이름이다.
SeverRoot

이 지시자 는 아파치 HTTP 소프트웨어가 설치되어 있는 베이스 디렉토리 를 지정한다. 디폴트는 /user/local/etc/httpd 이다.
BindAddress

이 지시자 는 하나 이상의 IP 어드레스가 있는 컴퓨터에서 사용한다. 이 설 정으로 서버가 어떤 어드레스에서 요청을 기다려야할지 정한다.
Errorlog & Transferlog

이 두지시자는 서버의 에러와 접속을 기록하는 로그파일의 위치를 지정한다. 서버는 슬래시로 시작하지 않는 값은 ServerRoot에 상대적인 것으로 간주한 다. 이들 로그는 간단하다. ErrorLog는 서버의 진단 메시지와 CGI 스크립트 로부터의 에러 메시지가 전달되는 곳이다. 서버는 모든 클라이언트 요청을 TransferLog에 기록한다. HostnameLooksups 가 켜져 있다면 클라이언트의 요청은 컴퓨터의 이름과 같이 나열된다. 꺼져 있으면 클라이언트의 IP 어드 레스에만 기록된다.
Pidfile & ScoreBoardfile

스탠드 얼론으로 수행되고 있으면 Pidfile 지시자 는 원래의 서버 프로세서가 그 프로세스 ID 번호를 기록하는 파일의 이름을 지정한다. 이 정보를 이용해 서버를 죽이거나 재 시작할 수 있다.
ServerName

이 항목은 URL 에서와 같이 서버의 공식 호스트 네임이다.
CacheNegotiatedDocs

이 지시자 는 프록시 서버를 거치는 사용자들을 위한 것이다. 프록시 서버는 정보를 수집하고 저장하여 인터넷에서 새로 받는 대신 저장된 정보를 보여 준다.
Timeout

이 값으로 불안정한 요청의 수신이나 정체된 응답의 수신을 계속하는 시간 을 초 단위로 지정한다.인터넷에 느린 회선으로 연결되어 있거나 매우 큰 파 일을 공급하면 이 숫자를 늘려야 한다.
KeepAlive & KeepAliveTimeout

KeepAlive는 HTTP 1.1의 기능으로서 요청을 처리하는 속도를 증진시킨다. KeepAlive 의 디폴트는 5로 서버가 하나의 연결에서 할 수 있는 최대의 요 청 개수이다. 이 값이 너무 크면 하나의 클라이언트가 서버의 자원을 독점 할 수 있다.
StartSevers

SeverType 이 스탠드얼론으로 정해져 있고 StartSevers가 1보다 크게 설정 되어 있으면(디폴트는 5) 서버의 동작은 근본적으로 달라진다. 하나의 마스 터 서버가 뜨는 게 아니라 처음부터 이 개수만큼 복제되어 서버폴 (sever pool)을 만든다. 원본서버는 폴의 모든 서버들의 마스터 스케쥴러 역할을 하 여 연결을 받아 들여 놀고 있는 사본에 전달한다. 이론적으로 이 방법은 오 버헤드를 감소하여 요청처리 속도를 증가시킨다.
7. 프록시 서버의 설정
프록시 서버는 서버와 클라이언트 사이에 존재한다.

클라이언트는 프록시 서 버로 가고 프록시 서버는 원하는 정보를 담고있는 실제 서버에게 클라이언 트처럼 동작한다. 클라이언트는 문서를 요청 하지만 클라이언트는 HTTP 의 프록시 서버를 찾는다. 요청은 프록시 서버로 보내지고 프록시 서버는 이 요 청을 가로채서 클라이언트 대신 실제 서버에 문서를 요청한다. 실제 서버는 문서를 프록시 서버에 보내고 프록시 서버는 다시 클라이언트에게 이 문서 의 복사 본을 보내고 같은 과정을 반복한다.

보통 프록시는 네트워크가 방화 벽으로 숨겨져 있을 때 보안 적인 이유로 사용된다. 방화벽은 네트워크 안과 밖사이를 정보가 마음대로 드나들지 못하게 한다. 그러나 프록시 서버는 자 주 사용하는 문서에 접근하는 속도를 높이기 증진시키기 위해서도 사용한다.

위의 각본대로 수행됐으면 요청된 문서는 캐쉬 되어 프록시 서버에 저장된 다. 다음 클라이언트가 같은 문서를 요청하면 프록시 서버는 다시 인터넷으 로 나갈 필요 없이 지난 요청때 저장하고 있던 것을 보낸다. 이 방식은 큰 인터넷 서비스 공급자들이 사용하며 New Zealand 나 UK 와 같은 나라에서 도 분주한 인터넷 연결에서 전송을 줄이기 위하여 사용한다.
chap 3. 네트워크 에센셜
네트워크 입문
서버란 프로그램 및 데이터를 저장하며 다른 컴퓨터에 이러한 자원을 서로 공유하게 하는 컴퓨터를 말한다. 클라이언트는 손님이다. 즉 서버에서 공급하는 자원을 공급 받는것이다.

윈도우95 및 윈도우NT 그리고 윈도우 워크그룹은 Peer to Peer 방식으로 네트워크를 지원하는 운영체제로 사용된다. 주) Peer to Peer : 주인임과 동시에 손님이다. 뒤에서 언급 하겠지만 모든 자원을 사용자 모두가 제어할수 있다. 즉 범죄 조직에서 점조직을 생각하면 된다.

네트워크를 연결하기 위해서는 물리적인 연결이 필요하다. 물리적 연결이란 컴퓨터 선을 연결 하는것으로 이해 하면 된다. 보통은 구리선을 사용하나 구리선은 저항이 심하여 전송 매체로서 그리 좋은것이 못돼서 광 이란 신기술이 등장한다. 광 에 대한 것은것은 추후 언급 하겠음. 네트워크 연결방식은 버스,스타,링 방식이 있다. 그리고 구리선이 됐든 광이 됐든 데이터를 전송하는 흐름선( 즉 컴퓨터 선 )을 유식한 말로 백본 또는 버스( 시내에 돌아 다니는 버스를 생각하면 됨? )라고 한다.

LAN( Local Area Network ) 이란 말 그대로 지역 네트워크이다. 특성상 150-200m 네트워크를 이룬다. 그리고 WAN ( Wide Area Network ) 이라는게 탄생한다. 이것은 LAN을 묶어놓은것이라 생각하면 간단하다. 이해가 안되시는분은 네트워크에 관련된 책자중 그림만 보면 금방 이해된다.

네트워크에는 서로 통신 하기 위해서 규칙을 만들어 놓았는데 이것을 프로토콜(규약)이라고 한다. 다른것도 있지만 TCP/IP 가 전형적인 규약의 표준이다.

그러나 이것은 해킹 하기가 매우 쉽다. 왜냐하면 소스가 공개되어 있기 때문이다. 전송 중에 서로를 알수 있는 암호를 패킷이라는것에 숨겨 같이 전송하는데 중간에서 가로채 분해하면? 이것은 해킹의 기본이면서 가장 널리 이용된다.

서버의 형태에는 파일 서버,프린터 서버,응용 프로그램 서버가 있다. 일부 식자층은 매우 어렵게 설명 하지만 이것은 말그대로 파일,프린터,프로그램을 서버에서 사용한다는것이다. 그러니까 그냥 집에서 누구나 다가지고 있는 시스템인데 괜히 거창하게 이렇게 부른다는 것 뿐이다.
<자료출저 : dykim님>



바보들의 영문법 카페(클릭!!)

오늘의 메모....

시사평론-정론직필 다음 카페
http://cafe.daum.net/sisa-1

바보들의 영문법 다음 카페
http://cafe.daum.net/babo-edu/

티스토리 내 블로그
http://earthly.tistory.com/

내 블로그에 있는 모든 글들과 자료에 대한 펌과 링크는 무제한 허용됩니다.
(단, 내 블로그에 덧글쓰기가 차단된 자들에게는 펌, 트랙백, 핑백 등이 일체 허용되지 않음.)

그리고 내 블로그 최근글 목록을 제목별로 보시려면....
바로 아래에 있는 이전글 목록의 최근달을 클릭하시면 됩니다.
그러면 제목을 보고 편하게 글을 골라 보실 수 있습니다.

그리고 내 블로그내 글을 검색하시려면 아래 검색버튼을 이용하시면 됩니다.


가가챗창

flag_Visitors

free counters