http://blog.daum.net/_blog/BlogTypeView.do?blogid=0G38s&articleno=7181009  에서 참조

일단 자세히 알아보기 전에 조금 쉽게 이야기하면

 

우리가 포트라고 쓰는 것에는 통신포트(물리적인 포트=예를들어 COM1, COM2, LPT1 LPT2 USB 포트등…)란 것도 있고

 

TCP/IP 포트라는 것도 있는데….. (예를들어 예전에 우리회사의 파워넷 같은 경우 홈페이지 주소 되에 ;8080 등으로 포트번호를 지정해서 접속되곤 했죠)

 

여기서의 포트는 하드웨어적인 포트가 아니고 가상의 소프트웨어적인 포트입니다.

 

바로  프로토클 규약인 TCP/IP 에서 지정하는 포트입니다.

 

하드웨어적으로 연결이 된 네트워크망에서, 컴퓨터들끼지 서로 통신을 하는데 필요한 규약이 TCP/IP이죠.

그리고 통신을 할때 동시다발적인 통신을 가능케 하기 위하여 포트라는 가상의 “문"이 정의 됩니다.

 

네트워크 하면 가장 기초적으로 OSI 7 layer에 대해서 이야기 해야 하는데,

 

이는 표준으로서 TCP/IP는 비슷하게(?) 이를 구현은 하지만 정확히 따르지는 않습니다.

 

그래서 OSI 7 layer를 건너 뛰고 바로 TCP/IP에 대해서 설명 드리겠습니다.

 

웹에서 OSI 7 layer를 검색하면 아주 많은 자료를 구하실 수 있을 것 입니다.

 

 

중요하지만 직접적이지 않은 것들은 (계층 이야기) 다 건너 뛰고…

 

TCP/IP에서 TCP는 신뢰성 있는 데이터를 전송하는 프로토콜이고

 

IP는 데이터를 정확한 곳에 보내기 위한 프로토콜 입니다.

 

여기서 유일 무이한 컴퓨터 고유 주소인 IP Address (흔히 말하는 IP)가 있습니다.

 

(똑 같은 주소가 두개라면 집배원 아저씨가 제대로 편지를 전달 못하듯이

 

IP도 내부 IP가 아닌이상 전 세계에 유일 무이 해야 제대로 전달 되겠죠.)

 

 

선박 운항에 비유 하자면….

 

하나의 배가 한 단위의 정보 (패킷)이라고 가정하면 목적지인 부산 항(IP Address)에

 

잘 도착 했다고 가정 하면… 단순히 배가 부산 항에 도착 하는 것 만으로

 

수송이 완료 된 것은 아닙니다.

 

적절한 선착장(Port)에 배를 대어서 짐을 내려 줘야지

 

제대로 수송이 완료 되는 것 입니다.

 

물론 부산항에는 수 많은 선착장이 있을 것 입니다.

 

이때 미리 무역 업자는 약속한 선착장에서 기다리고 있어야 하겠지요.

 

(Port를 의미 그대로 항구로 해석을 하려 한다면 IP Address는 "대한민국"으로

 

Port는 대한민국의 많은 항구 중 하나인 부산항으로 생각하면 됩니다.

 

어디까지나 비유이니…)

 

 

기본적으로 21, 23, 80 번 등의 포트는 FTP, Telnet, HTTP로 약속이 되어 있고

 

(요놈들 말고도 몇개 더 있지만 직접 사용 해 보지 않아서 기억나지 않네요.)

 

저 멀리 몇 천번대 포트는 P2P등 임의로 이용 할 수 있습니다.

 

즉, 선착장에서 무역 업자가 기다리듯이 80번 포트에서는 HTTP가 기다리고 있다가

 

전달된 정보를 적절히 처리해서 우리에게 보여 주게 됩니다.

 

(Port는 65536개가 있는데 TCP와 그의 친구 UTP가 관할하고 있습니다.)

 

 

그리고 이렇게 포트를 사용하는 목적을 어려운 말로

 

호스트 내에서 다중 프로세스에 대한 처리라고 하는데

 

옛날 모뎀으로 통신 하던 시절에는 다운 받고 있는 동안은 채팅을 할 수 없었습니다.

 

그러나 요즘은 프루나로 다운 받으면서 채팅도 하고 동시에 실시간으로 영화도 보는데,

 

즉, 여러 프로그램 (엄밀히 프로세서)이 동시에 사용 할 수 있다는 의미로 생각 합니다.

 

좀더 자세히 하면 TCP 의 역할은 4계층으로 나누어서 다양한일은 하는데(애플리케이션층,트랜스포트층 네트원크 인터넷층, 데이터링크층) 복잡하니까. 간단하게만 설명하면

 

프로그램등이 데이터를 보내면 TCP가 데이터를 송신할 수 있도록 TCP가 이해할 수 있는 형태로 포멧하고,

 TCP는 그 데이터를 패킷 형태로 자르고 에러 체킹을 위한 헤더를 각 패킷에 붙이게되죠.

 네트워크 층에는 IP 포장(목적지 IP의 주소를 가르켜 줌)을 하고 IP헤더를 넣게되고,

 데이터 링크층은 네트워크 층에서 보내온 데이터의 IP 주소를 특정한 네트워크의 하드웨어 주소로 번역하는 역할을 합니다.
 
(네이버에서 퍼온글… 이해를 돕기위해.

 

예를 다시 들면, HTTP 서버가 0 과 1 로만 되어 있는 자료를 애플리케이션 층에 보낸다면,
애플리케이션 층에서는 그 데이터를 새로운 형태로 포멧 (디지털을 아날로그) 트랜스포트 층에 보내고.

트랜스포트 층에서는 TCP가 데이터를 전달하기 쉬운 형태로 자르고 난 뒤 네트워크 층으로 데이터를 보낸다. 네트워크층에서는 데이터가 가야할 장소와 IP 헤더를 붙이고 데이터를 데이터 링크층으로 보낸다. 데이터 링크층은 네트워크 층에서 보내온 데이터의 IP 주소를 특정한 네트워크의 하드웨어 주소로 번역한다.
 
송신측에서 각 계층은 상위 계층에서 받은 데이터의 헤더를 추가하고, 유사하게 수신측에서 각 계층은 다음 상위 계층에 데이터를 보내기 전에 자신의 헤더를 추출한다. 그래서 최종적으로 얻게되는 데이터는 원래 보냈던 데이터와 동일한 것이 된다.
 
TCP는 전달 되는 데이터의 관리 기능외에 또 다른 기능이 있다. 그것은 TCP가 다른
프로토콜과 같이 사용될 수 있도록 지원한다. 예를 들어 여러분이 집에서 모뎀으로
인터넷에 WWW을 항해 하려 한다면 먼저 윈속등으로 여러분 컴퓨터에 TCP/IP 환경을
만들어야 한다. WWW에서는 브라우저와 서버와 통신을 위해 HTTP라는 프로토콜을 따로
사용하는 데 왜 TCP/IP라는 프로토콜을 따로 컴퓨터에 설정 해 주어야 하는가? 이미
언급했다시피 인터넷에는 많은 종류의 컴퓨터(OS)가 존재한다. 이들 간을 묶는 첫 번째
프로토콜(언어)이 TCP/IP이고 인터넷을 기반으로 움직인는 WWW에서 정보를
교환하기 위한 프로토콜이 HTTP인것이다.)

 

 

 

 

TCP포트 번호가 필요한 이유

 

TCP/IP 프로토콜을 기반으로 하는 네트워크상에 한 서버가 있다고 생각하면 그 서버는 한 사용자와 만 통신을 하는 것이 아니라 여러 사용자와 동시에 통신을 하게 됩니다. 또한 서버는 한가지 서비스만 제공하는 것이 아니라 여러 가지의 서버 응용 서비스를 여러 사용자에게 제공을 하게 됩니다. 즉 데이터 통신 환경에서 한 서버는 여러 가지의 서비스를 여러 사용자에 제공을 할 수 있고 또한 한 사용자는 여러 개의 서버로부터 여러 가지의 서비스를 제공 받을 수 있습니다.

 

두 대 이상의 컴퓨터가 통신을 할 때 데이터를 목적지 까지 전달 해 주는 것은 IP주소에 의해 결정이 되고 목적지 서버에 도달한 정보를 어느 응용프로그램에서 처리해 줄 것인지를 결정하는데 사용하는 것이 바로 포트번호가 됩니다. 데이터를 전송 할 때도 같은 방법으로 적용이 될 수 있습니다. 서버가 제공하는 여러 사용자중 어느 사용자가 요청한 서비스인지 또는 어느 프로그램이 요청한 서비스인지를 구분하기 위하여 송신지 포트 번호가 있는 것입니다. 이 표기된 포트 번호에 따라 데이터가 정확한 응용 프로그램에서 처리 될 수 있습니다. 요청한 서비스의 포트번호가 맞지 않거나 차단이 되어 있으면 그 서비스는 제대로 이루어 질 수 없습니다.

 

즉 어느 응용 프로그램이나 사용자가 보낸 데이터 인지를 구분하기 위해 송신측 포트 번호(Source Port Number)가 사용되고 어느 응용 프로그램이 수신해야 하는지를 구분하기 위해 수신측 포트 번호(Destination Port Number)가 사용됩니다.

 

실제로 통신을 할 때는 모든 장치가 포트 번호를 사용하여 전송층에서 통신을 하며 이 포트 번호를 결정하는 방법에는 두 가지가 있습니다. 다음은 이 방법에 대해 알아봅니다.

 

1. 공식 기관에서 공표한 포트 번호

 

많이 쓰이는 일반적인 TCP/IP 프로토콜을 사용하는 응용 프로그램들은 통신을 할 경우 대부분 공식 기관에서 결정한 포트 번호를 사용하게 됩니다. 이와 같이 공식 할당된 포트 번호를 Well-known Port Number또는 Well-known Port Assignment라고 합니다.

 

실제로 사용되는 예를 보도록 하겠습니다.

 

– 포트번호 0 : Reserved

– 포트번호 1 : TCP MUX(TCP 멀티플렉스)

– 포트번호 5 : RJE(Remote Job Entry)

– 포트번호 7 : ECHO

– 포트번호 9 : DISCARD

– 포트번호 11 : SYSTAT(활성 사용자)

– 포트번호 13 : DAYTIME(주간)

– 포트번호 15 : NETSTAT(네트워크 상태 프로그램)

– 포트번호 17 : QOTD(해당일 인용문)

– 포트번호 19 : CHARGEN(문자 발생기)

– 포트번호 20 : FTP-DATA(파일전송 프로토콜(데이터))

– 포트번호 21 : FTP(파일전송 프로토콜)

– 포트번호 23 : TELNET(단말기 연결)

– 포트번호 25 : SMTP(간단한 메일 전송 프로토콜)

– 포트번호 37 : TIME(시간)

– 포트번호 42 : NAME(호스트 이름)

– 포트번호 43 : WHOIS(누구)

– 포트번호 53 : NAMESERVE(도메인 이름 서버)

– 포트번호 79 : FINGER(finger)

– 포트번호 101 : HOSTNAMES(NIC 호스트 이름 서버)

– 포트번호 103 : X400(X.400 메일 서비스)

– 포트번호 113 : AUTH(인증 서비스)

– 포트번호 117 : UUCP-PATH(UUCP 경로 서비스)

– 포트번호 119 : NNTP(USENET 뉴스 전송 프로토콜)

– 포트번호 129 : PWDGEN(암호 발생기 프로토콜)

– 포트번호 160 – 223 : RESERVED(예약되어 있슴)

 

2. 동적으로 포트 번호를 할당하는 방법

 

어떤 장치(device)가 서비스를 제공하기 위해 필요 할 때 그 장치들이 사용하는 포트 번호가 중복이 되거나 불일치가 일어나지 않도록 번호를 임의로 생성하여 사용하는 방법입니다.

 

컴퓨터에서는 임의의 작업을 처리하기 위해 실행 중인 프로그램을 프로세스라합니다. 하나의 프로세스가 하나의 프로그램의 기능을 처리할 수도 있고, 여러 개의 프로세스가 하나의 프로그램의 기능을 처리하기도 합니다.

 

운영체제에 예약된 프로세스는 컴퓨터를 운영하기 위해 반드시 실행되고 있어야 하는 프로그램으로 이 프로세스들은 고유의 프로세스 번호를 가지고 수행이 되며

이러한 예약된 프로세스는 일반 사용자들이 요청한 서비스를 제공하기 위해 다른 프로세스를 불러 오거나 처리를 하게 됩니다. 이 프로세스는 사용자의 서비스 요청이 있을 때 마다 동적으로 생성된 임의의 번호를 가지게 되며, 통신을 위한 처리도 이러한 예약된 프로세스가 수행되고 있는 동안에 필요에 의해 부가적으로 할당이 되므로 동적인 포트 번호 할당이라고 할 수 있습니다.

 

3. 포트 번호와 전송층 프로토콜

앞에서 설명한 TCP에서 사용하는 포트 번호는 다른 전송층 프로토콜에서도 사용 할 수 있습니다. 서로 다른 전송층 프로토콜은 서로 다른 프로세스로 인식이 되고 포트 번호는 전송층 프로토콜 마다 규정이 되어 있기 때문입니다. 일반적으로 TCP와 함께 많이 사용되고 있는 UDP프로토콜에서도 TCP프로토콜에서 사용하는 것과 동일한 포트 번호를 가지고 같은 서비스를 제공 해 줄 수 있습니다. 물론 TCP가 데이터 처리하는 방법과 UDP가 데이터를 처리해 주는 방법은 서로 다릅니다. 보통 TCP/IP서비스는 UDP/IP에서도 처리 할 수 있게 많이 사용 됩니다.

 

UDP프로토콜에서 정의되어 사용하는 포트 번호의 예를 들어 보면 다음과 같습니다.

 

– 포트번호 0 : Reserved

– 포트번호 7 : ECHO

– 포트번호 9 : DISCARD

– 포트번호 11 : SYSTAT(활성 사용자)

– 포트번호 13 : DAYTIME(주간)

– 포트번호 15 : NETSTAT(네트워크 상태 프로그램)

– 포트번호 17 : QOTD(해당일 인용문)

– 포트번호 19 : CHARGEN(문자 발생기)

– 포트번호 37 : TIME(시간)

– 포트번호 42 : NAME(호스트 이름)

– 포트번호 43 : WHOIS(누구)

– 포트번호 53 : NAMESERVE(도메인 이름 서버)

– 포트번호 67 : BOOTPS(부트스트랩 프로토콜 서버)

– 포트번호 68 : BOOTPC(부트스트랩 프로토콜 클라이언트)

– 포트번호 69 : TFTP(간단한 파일 전송 프로토콜)

– 포트번호 123 : NTP(네트워크 시간 프로토콜)

– 포트번호 161 : SNMP(단순 네트워크 관리 프로토콜)

– 포트번호 162 : SNMP-TRAP

– 포트번호 512 : BIFF(UNIX 콤샛 통신)

– 포트번호 513 : WHO(UNIX RWHO 프로세스)

– 포트번호 514 : SYSLOG(시스템 로그)

– 포트번호 525 : TIMED(시간 데몬 프로세스)

 

위에서 보신 것처럼 같은 서비스가 TCP프로토콜로 처리가 될 수도 있고

UDP 프로토콜로 처리가 될 수도 있습니다. 상위 계층 프로그램이 전송층 프로토콜로 TCP또는 UDP를 선택적으로 사용 할 수 있다는 이야기 입니다. 그렇다면 어떤 경우에 TCP를 사용하고 어떤 경우에 UDP를 사용하면 좋을까? 간단하게 정리하면 TCP는 좀 더 안정적인 데이터 처리를 하고자 할 때 쓰는 프로토콜이며 UDP는 안정적인 데이터 전송을 보장 않아도 되는 경우에 사용 하는 것이 좋습니다.

http://socurites.com/m/248 에서 참조

아래는 스마티 사이트의 “About Smarty"의 번역본이다.

철학

스마티는 아래의 목표를 만족시키기 위해 설계되었다.

  • 프레젠테이션 코드와 어플리케이션 코드의 명확한 분리
  • 백엔드에서는 PHP를, 프론트엔드에서는 스마티 템플릿을
  • PHP를 보완하지, 대체하지는 않는다
  • 프로그래머와 디자이너가 빠르게 개발해서 배포해야 한다
  • 유지보수를 쉽고 빠르게 할 수 있어야 한다.
  • PHP 지식이 없더라도 구문은 이해하기 쉬워야 한다.
  • 쉽게 확장할 수 있는 유연성
  • 보안 : PHP로부터 분리
  • 무료, 오픈소스

스마티란?

스 마티는 PHP를 위한 템플릿 엔진으로, 스마티를 사용하면 프레젠테이션 로직(HTML/CSS)와 어플리케이션 로직을 분리할 수 있다. 다시 말해 PHP 코드는 어플리케이션 로직을 위해서만 사용하며, 프레젠테이션으로부터는 분리할 수 있다. 

템플릿에 대한 두 진영간의 의견 대립

PHP 에서 템플릿을 사용한다고 할 때, 여기에는 서로 상반대는 두 진영이 있다. 한 진영에서는 "PHP 그 자체가 템플릿 엔진"이라고 주장한다. 이 진영에서는 PHP 코드와 HTML을 단순히 섞어서 사용한다. 순전히 스크립트를 실행한다는 관점에서 보면 이 방식은 빠르긴 하다. 하지만 대다수의 사람들은 PHP 코드가 프레젠테이션 코드와 섞어서 사용하게 되면 구문이 지저분해지며, 결국 유지보수 하기귀 십자 않다고 반대한다. PHP는 프로그래밍에는 적합하지만, 템플릿으로 사용하기엔느 적합하지 않기 때문이다.

반 대 진영에서는 프리젠테이션에는 어떤 프로그래밍 코드가 있어서는 안되며, 어플리케이션 컨텐츠가 필요한 위치에는 단순한 태그를 사용해야 한다고 주장한다. 이러한 사상은 대다수의 템플릿 엔진(또한 프로그래밍 언어)이 지닌 철학과 일맥상통하며, 스마티에서 이와 동일한 입장을 취한다. 즉 별도의 노력을 들이지 않고도 템플릿에서는 프레젠테이션에만 집중하며, 어플리케이션 로직은 사용하지 않자는 것이다.

PHP와 템플릿을 분리하는 일이 왜 중요한가?

PHP 코드와 템플릿을 분리하게 되면 많은 장점이 있다. 예를 들어 다음과 같다.

  • 구문(Syntax)
    템 플릿은 주로 HTML과 같은 의미적인 마크업(semantic markup)으로 구성된다. PHP 구문은 어플리케이션에는 적합하지만, HTML과 섞어 쓰게 되면 문제가 되기 쉽상이다. {tag}와 같은 간단한 스마티 구문은 다른 무엇보다도 프레젠테이션을 표현하기 위해 만들어졌다. 스마티를 사용하면 프레젠테이션에만 집중할 수 있으며, "코드"에는 신경을 쓰지 않아도 된다. 이를 통해 템플릿을 십게 배포할 수 있으며, 유지보수 또한 쉬워진다. 스마티 구문을 사용하기 위해서 PHP에 대한 별도의 지식을 필요료하지 않는다. 또한 스마티 구문은 프로그래머뿐만 아니라 프로그래머가 아닌 사람들도 이해하기 쉽다.
  • 기능(Feature)
    템 플릿 엔진을 사용하면 다양한 프레젠테이션 기능을 사용할 수 있다. 만약 템플릿을 엔진을 사용하지 않았더라면, 여러분이 직접 개발하고 테스트해야 하며, 유지보수 해야했을 것이다. 뿐만 아니라 태그를 사용하면, PHP 문장의 복잡성을 숨길 수 있게 된다. 예를 들어 아래의 PHP 코드를

    PHP

    <?php echo strtolower(htmlspecialchars($title,ENT_QUOTES,UTF-8)); ?>

    스마티에서는 아래와 같이 작성할 수 있다.

    Smarty

    {$title|escape|lower}

    좀더 쉽게 개발을 하기 위해서 PHP가 C 레이어 위에서 추상화를 제공한 것과 마찬가지로, 템플릿 유지를 쉽게 하기위해 스마티는 PHP 레이어 위에서 추상화를 제공한다.

  • 샌드박스(Sandbox)
    PHP 를 템플릿과 섞어 쓰게 되면, 템플릿에 포함될 수 있는 로직에 대한 제약을 할 수 없게 된다. 스마티는 템플릿을 PHP로부터 분리하므로, 프레젠테이션과 비즈니스 로직의 분리를 제어할 수 있게 된다. 또한 스마티는 보안 측면에서 템플릿을 점진적으로 제한할 수 있는 기능을 제공한다.

PHP 구문과 스마티 구문을 비교가 궁금하다면, 구문 비교를 참고하라.

웹 디자이너와 PHP

” 어쨋든 웹 디자이너는 구문을 배워야만 하는데, PHP는 왜 배우면 안되는가"라고 흔히들 묻는다. 물론 웹 디자이너도 PHP를 배울 수 있고, 심지어는 이미 익숙할 수도 있다. 중요한 점은 웹 디자이너가 PHP를 배울 능력이 되느냐가 아니라, PHP와 HTML을 섞어 썼을 떄 과연 유지보수가 쉬우냐다. {tags}는 간단하며, 이해하기 쉽고, PHP 구문에 비해 실수할 가능성도 적다. 또한 템플릿은 템플릿에 포함될 수 있는 코드에 제약을 가할 수 있다. PHP를 사용하게 되면 템플릿에 포함하지 말아야 할 코드를 템플릿에 포함하게 되는 우를 범하게 될 가능성이 높다. 물론 어플리케이션 설계 규칙에 대해 디자이너에게 설명해줄 수는 있지만, 사실 이러한 과정을 불필요한 작업이다(만약 디자이너가 어플리케이션 설계 규칙을 배운다면 이미 디자이너는 디자이너가 아니라 개발자인 셈이다!). PHP 매뉴얼은 개발자를 위한 것이다. 디자이너는 매뉴얼의 일부만 알고 있으면 되며, 디자이너가 매뉴얼에서 자신이 필요한 요소를 찾기란 쉽지 않다. 이러한 상황에서 스마티는 디자이너가 필요로 하는 최적의 툴이다. 또한 개발자는 스마티를 완전히 제어할 수 있다. 템플릿 상속과 같은 프레젠테이션을 위한 여러 기능도 제공되므로, 템플릿 재사용할 수 있을 뿐만 아니라 능률적으로 구조화할 수 있게 된다.

구현이 중요하다

스 마티가 프레젠테이션과 어플리케이션 코드를 명확히 분리할 수 있는 도구를 제공하지만, 분리 규칙을 어기게 되는 상황도 충분히 많이 존재한다. 예를 들어 구현을 잘못한 경우(PHP를 템플릿에 포함하는 것과 같은), 프레젠테이션 분리를 통해 해결하고자 했던 문제보다 더 큰 문제를 야기할 수 있다. 스마티 문서에서는 유의해야할 항목들에 대해 잘 설명하고 있다. 또한 베스트 프랙티스를 살펴보라.

스마티는 무엇이며, 어떻게 사용해야 하는가?

크래쉬 코스에서 PHP 어플리케이션에서 스마티를 사용하여 전형적으로 구현하는 방식에 대한 개요를 잘 설명하고 있다.

어떻게 동작하나?

스 마티는 내부적으로 템플릿과 PHP 스크립트 복사본을 컴파일한다. 이를 통해 템플릿 태그 구문 뿐만 아니라 PHP 처리 속도 향상이라는 장점을 얻는다. 각 템플릿이 처음 호출될 때 컴파일이 이루어지며, 이후로는 컴파일된 버전이 사용된다. 이 모든 작업을 스마티에서 처리하므로, 템플릿 디자이너는 그저 스마티 템플릿을 수정하면 될 뿐, 컴파일된 버전을 관리할 필요가 없어진다. 따라서 템플릿을 유지보수하기가 쉬워질뿐만 아니라, 처리 속도 또한 상당히 빨라진다. 컴파일된 버전 또한 PHP 코드이므로 APC나 ZendCache와 같은 op-code 가속기는 컴파일된 스크립트에도 여전히 적용할 수 있다.

템플릿 상속

스 마티 버전 3에서는 템플릿 상속 기능이 추가되었는데, 이는 스마티의 강력한 기능 중 하나이다. 템플릿 상속이 없었을 때에는 헤더(header) 템플릿, 푸터(footer) 템플릿과 같은 단위로 템플릿을 관리했다. 이러한 구조화는 그 자체로 많은 문제점을 낳았으며, 페이지 단위로 헤더/푸터에 컨텐츠를 관리하는 마구잡이 방식이 나타났다. 템플릿 상속을 사용하면 다른 템플릿을 포함하는 대신에, 템플릿을 하나의 페이지로 관리할 수 있다. 그리고 템플릿을 상속받고, 상속받은 템플릿 내에서 컨텐츠 블록을 조작할 수 있다. 이를 통해 템플릿을 더 쉽게 이해할 수 있게 되었고, 쉽고 효율적으로 관리할 수 있다. 더 자세한 내용은 템플릿 상속을 살펴보라.

XML/XSLT 구문을 사용하지 않는 이유는?

여 기에는 몇가지 근거가 있다. 먼저, 스마티는 XML/HTML 기반 템플릿이 제공하지 못하는 일들을 할 수 있다. 예를 들어 이메일, 자바스크립트, CSV, PDF 문서 등을 생성할 수 있다. 둘째, XML/XSLT 구문은 PHP 코드보다도 장황하며, 실수하기도 쉽다. XML/XSLT 구문은 컴퓨터가 보기에는 완벽하지만, 사람이 보기에는 끔찍한 구문이다. 스마티는 사람이 쉽게 읽을 수 있고, 이해할 수 있으며 관리하기 위해 만들어졌다.

템플릿 보안

스 마티는 PHP 코드를 분리할 수 있지만, 여러분이 원하는 방식으로 사용할 수 있다. 템플릿 보안은 PHP에 제한을 가한다. 이는 써드 파티 편집 템플릿을 사용하고 있고, PHP와 스마티의 완전한 기능을 모두 허락하고 싶지 않은 경우에 유용하다.

또다른 템플릿 엔진들..

스마티는 “프로그래밍코드와 프레젠테이션의 분리” 철학을 따르는 유일한 템플릿 엔진은 아니다. 예를 들어 파이썬에서는 장고(Django) 템플릿, 치타(Cheetah) 템플릿과 같이 동일한 원칙을 따르는 템플릿 엔진이 만들어졌다.

주 석: 파이썬과 같은 언어는 태생적으로 HTML과 섞어 쓰지는 않으므로, 프로그래밍 코드와 외부 코드를 적절히 분리해서 사용할 수 있는 장점이 있다. 하지만 파이썬과 HTML을 섞어서 쓸 수 있는 라이브러리가 존재한다. 하지만 이러한 방식은 피해야 한다.

스마티가 지원하지 못하는 것들

스마티는 어플리케이션 개발 프레임워크는 아니다. 스마티는 MVC가 아니다. 스마티는 Zend 프레임워크, CodeIgniter, CakgePHP와 같이 PHP 개발을 위한 어플리케이션 프레임워크가 아니다.

스 마티는 템플릿 엔진이며, 어플리케이션 내에서 V(iew) 컴포넌트로만 동작한다. 스마티는 위에서 언급한 모든 프레임워크가 쉽게 결합하여, 뷰 컴포턴트로 사용할 수 있다. 물론 다른 소프트웨어와 마찬가지로, 스마티를 배우기 위해선 노력이 든다. 스마티 자체가 좋은 어플리케이션 설계 또는 적절한 프레젠테이션 분리를 보장하는 것은 아니다. 이는 컴포넌트 개발자와 웹 디자이너가 여전히 고민해야할 요소다.

내게 정말 스마티가 필요한가?

스마티를 모든 경우에 사용할 수 있는 것은 아니다. 따라서 스마티가 당신에게 정말로 적합한지 확인하는 과정이 매우 중요하다. 아래와 같은 질문을 스스로에게 물어보라.

  • 템플릿 구문(Template Syntax)
    PHP 와 HTML 태그를 섞어서 쓰더라도 만족하는가? 웹 디자이너가 PHP에 익숙한가? 웹 디자이너가 프레젠테이션에 특화된 태그 기반의 구문을 더 선호하는가? 얼마간 스마티와 PHP를 함께 사용해 보면, 정답을 찾을 수 있을 것이다.
  • 비즈니스 상황(Business Case)
    템 플릿을 PHP로부터 분리해야 하는 요구사항이 있는가? 믿을만하지 않은 써드 파티에서 만든 편집 텝플릿을 사용하고 있고, PHP 코드의 완전한 기능을 해당 편집 템플릿에 허락하고 싶지 않은가? 템플릿에서 사용할 수 있는 것과 사용할 수 없는 것을 프로그래밍적으로 제어할 필요가 있는가? 스마티는 이러한 기능을 제공하기 위해 만들어졌다.
  • 기능 집합(Function Set)
    캐싱, 템플릿 상속, 플러그인 아키텍처와 같은 스마티 기능을 사용하면 해당 코드를 직접 개발하지 않아도 되므로 개발 사이클을 단축시킬 수 있는가? 사용하려는 코드베이스 또는 프레임워크에서 프레젠테이션 컴포넌트를 제공하는가?

또한 스마티 웹사이트에서 유스케이스와 워크플로우를 살펴보라.

스마티를 사용하는 사이트들

스 마티 웹 사이트에는 매일 유니크한 수만명의 사용자가 방문하며, 그들 중 대다수는 문서를 읽으려는 개발자들이다. 잘 알려진 PHP 프로젝트 중 많은 수가 스마티를 활용한다. 예를 들어 XOOPS CMS, CMS Made SImple, Tiki CMS/Groupware 등이 있다.

요약

스마티를 간단한 웹사이트를 위해서 사용하든지 아니면 대규모의 기업 솔루션을 개발하기 위해 사용하든지 관계없이 여러분이 필요한 것들을 만족시켜줄 것이다. 스마티를 선택해야만 하는 이유에는 여러가지가 있다.

  • PHP와 HTML/CSS는 반드시 분리해야 한다.
  • 쉽게 구조화하고 관리가 편리하다.
  • 서드 파티 템플릿 접근에 대한 보안
  • 완전한 기능을 제공하며, 필요에 따라 쉽게 확장 가능하다.
  • 대규모 사용자를 기반으로 한다.
  • 상용의 경우 LGPL 라이선스
  • 100% 무료로 사용할 수 있는 오픈 소스 프로젝트

[참고자료]

Why are you looking at this wiki page?

Are you looking at this page because you cannot access the mysql server installed on your pc/server when you were trying to see if it works well? Or do you receive error messages like the following? :

ERROR 1045: Access denied for user: 'root@localhost' (Using 
password: NO)

or

ERROR 1045: Access denied for user: 'root@localhost' (Using 
password: YES)

To resolve this problem ,a fast and always working way is the “Password Resetting” .

How can I reset my MySQL password?

IconsPage/IconWarning3.png Following this procedure, you will disable access control on the MySQL server. All connexions will have a root access. It is a good thing to unplug your server from the network or at least disable remote access.

To reset your mysqld password just follow these instructions :

  • Stop the mysql demon process using this command :
    •    sudo /etc/init.d/mysql stop
  • Start the mysqld demon process using the –skip-grant-tables option with this command
    •    sudo /usr/sbin/mysqld --skip-grant-tables --skip-networking &

Because you are not checking user privs at this point, it’s safest to disable networking. In Dapper, /usr/bin/mysqld… did not work. However, mysqld –skip-grant-tables did.

  • start the mysql client process using this command
    •    mysql -u root
  • from the mysql prompt execute this command to be able to change any password
    •    FLUSH PRIVILEGES;
  • Then reset/update your password
    •    SET PASSWORD FOR root@'localhost' = PASSWORD('password');
  • If you have a mysql root account that can connect from everywhere, you should also do:
    •    UPDATE mysql.user SET Password=PASSWORD('newpwd') WHERE User='root';
  • Alternate Method:
    •    USE mysql
         UPDATE user SET Password = PASSWORD('newpwd')
         WHERE Host = 'localhost' AND User = 'root';
  • And if you have a root account that can access from everywhere:
    •    USE mysql
         UPDATE user SET Password = PASSWORD('newpwd')
         WHERE Host = '%' AND User = 'root';

For either method, once have received a message indicating a successful query (one or more rows affected), flush privileges:

FLUSH PRIVILEGES;

Then stop the mysqld process and relaunch it with the classical way:

sudo /etc/init.d/mysql stop
sudo /etc/init.d/mysql start

When you have completed all this steps ,you can easily access to your mysql server with the password you have set in the step before. An easy way to have a full control of your mysql server is phpmyadmin (www.phpmyadmin.net), software made in php that can give you a web interface that can be very usefull to people that havent got a lot of confidence with bash .To install phpmyadmin on you server you will need to have 4 things:

  • web server apache
  • php
  • mysql server/mysql client installed
  • php_mysql support for apache

All packages can be found browsing synaptic.

http://brown.ezphp.net/39 에서 참조

HTML 밖에 모르는 웹 브라우저 ?

웹 브라우저는 HTML밖에 모릅니다. HTML이 브라우저가 쓰는 언어라는 것이지요. (자바스크립트와 같은 약간의 외국어도 합니다.^^;;) 그래서 우리가 홈페이지를 만들려면 모든 문서를 HTML로 작성해야만 합니다.

HTML을 울려 버린 CGI의 등장

인터넷 초창기에는 대부분의 홈페이지가 모두 HTML(SGML)로 만들어져 있었습니다. (선택의 여지가 없었죠)
HTML로 홈페이지를 만들어 보신 분은 아시겠지만 HTML은 일방향적이고 수정하기 전에는 절대 변하지 않는 특성을 가지고 있습니다. 이러한 단점 때문에 사람들은 HTML 말고 다른 무언가가 필요함을 느꼈습니다. 그래서 생겨난 것이 바로 CGI (Common Gateway Interface)입니다.

CGI의 구조

CGI는 위와 같은 구조를 가지는데.. ( HTML은 1과 4의 과정만 있음 ) 보시는 바와 같이 HTML 보다 한단계 더 처리를 함으로써 계산과 처리 기능이 추가되었습니다.  이로 인해 우리는 정적인 웹 페이지에서 변화가 자유롭고 방문자와 홈페이지간에
서로 상호작용이 가능한 웹 페이지를 만들 수 있게 된 것입니다. 그러나 여기서 주의해야 할 점은 3번에서 보듯이 CGI로 처리된 값은 HTML로 전송됩니다. 웹 브라우저가 HTML밖에 모르니 HTML로 결과를 보여줘야 하는 것입니다. 그러니 PHP를 하려면 당연히 HTML을 알고 있어야겠죠?

그러면 CGI와 PHP는 어떤 관계인가?

PHP는 약간 다르긴 하지만 일종의 CGI라고 볼 수 있습니다. 그래서 PHP도 저 위의 그림과 비슷한 구조를 가집니다.

참고. (중급)
CGI는 일반적으로 웹서버로 요청이 들어오면 CGI 프로그램을 실행하여 하나의 프로세스를 생성하고 그 처리 결과를 웹서버로 전송한 후 프로세스가 종료되는 형식입니다. 100개의 요청이 들어오면 CGI 프로세스가 100개가 생성이 됩니다.

PHP는 CGI와 달리 아파치 웹서버에 모듈로 장착되어 있습니다. 따라서 매회 실행시마다 프로세스가 생성되는 CGI와 달리 하나의 프로세스에 여러개의 쓰레드를 생성하여 처리가 가능합니다.

프로세스, 쓰레드?? 뭐가다르냐구요? 프로세스는 각각 별도로 시스템 자원을 소비합니다. 1개의 프로세스가 메모리 1메가바이트를 소비한다면 100개의 경우 100메가 바이트의 메모리를 소비하게 됩니다. 그러나 쓰레드는 쓰레드간에 시스템자원의 공유가 가능하므로 100개라고해서 100메가 바이트를 소비하는 것이 아니라 그보다 훨씬 적은양의 메모리를 소비하게 됩니다.
그래서 프로세스방식인 CGI 보다 쓰레드방식인 PHP가 성능이 우수합니다.

http://freean.egloos.com/186933 에서 참조

CGI
(common gateway interface)

 CGI는 웹서버가 하지 못하는 일을 외부의 프로그램을 이용할 수 있게 하는 표준적인 방법, 또는 그 방법에 따라 수행되는 외부 응용 프로그램들을 가리킨다.

 일반적으로 웹 서버가 브라우저에게 넘겨주는 HTML 자료는 정적인 자료이다. 즉, 일정한 텍스트 화일이다. 그러나 질의를 통해서버의 데이타베이스로부터, 만족하는 레코드만의 출력을 원할 경우, 되돌려지는 문서는 질의에 따라 동적으로 변화해야 한다.CGI는 바로 이러한 역할을 수행하기 위해 존재하는 인터페이스 프로그램이다.

보통 이 CGI로 동작되는 응용 프로그램을 게이트웨이 스크립트(Gateway Script)라고 부른다. 게이트웨이 스크립트는 웹브라우저에 의해 웹서버에서 동작되는 프로그램을 말한다. 이 게이트웨이 스크립트를 통해서 웹서버는 보통 그 시스템의 다른 프로그램들과 연결된다. 이 게이트웨이 프로토콜은 반드시 특수한 스크립트 파일일필요는 없고, 단지 실행 가능한 프로그램이기만 하면 된다.

(1) 게이트웨이 스크립트의 동작 원리

1) 브라우저가 서버에게 게이트웨이 스크립트의 수행을 요구한다.
2) 서버는 게이트웨이 스크립트에 해당하는 스크립트를 수행한다.
3) 게이트웨이 스크립트는 외부 프로그램이나 DB를 수행한다.
4) 수행결과를 다시 서버에 넘겨준다
5) 넘겨받은 수행 결과를 브라우저에게 다시 전송한다.

보통 이런 관계로 브라우저와 서버, CGI의 관계가 설정된다. 예를 들어 링크에

cgi

라고 설정하고, 웹서버측에서 getdate 스크립트를 설치하면 다음과 같이 된다.

#!/bin/sh
echo Context-type: text/html
echo 
/bin/date

이 스크립트를 설치하면 이에 해당하는 동작을 하게 된다.

CGI는 실행가능한 프로그램이므로, 시스템에 실행 화일로 존재하게 된다. Web 서버는 CGI프로그램의 내용을 보내는 것이 아니라, 실행결과를 보내야 한다. 그러므로, 서버가 실행시키는 프로그램이 CGI다. 이를 위해 CGI 프로그램들은 특정한 디렉토리에 존재하게 된다. 이 디렉토리는 Web 마스터가 직접 관리하며, 일반 사용자가 CGI프로그램을 생성시킬 수는 없다. NCSA HTTPd 서버에서는 /cgi-bin이라는 디렉토리가 할당된다. 이 곳에 CGI프로그램들이 놓여지게 된다.

CGI 응용 프로그램의 작성에서 가장 많이 사용되는 언어는 C, C++, Java, Perl 등이다

오래된 암호화 방법이다. 대칭키 알고리즘을 흔히 비밀키 알고리즘이라고도 부른다. A B만이 아는 비밀키를 이용해서 암호화 통신을 한다는데서 기인한다. 여기에서 핵심은 대칭키라는데 있다. 키가 대칭을 이룬다? 이것은 암호화키와 복호화키가 동일하다(대칭을 이룬다)라는 데서 정답을 얻을 수 있다.


 

<그림3-1. 대칭키 알고리즘>

 

<그림3-1>의 예제에서 보듯이 대칭키 알고리즘에서는 암호화를 할 때 사용하는 키와 복호화를 할 때 사용하는 키가 동일해야 한다. Alice‘1234’를 키로서 데이터를 암호화했다면 Bob역시 ‘1234’라는 키를 알아야만 복호화를 할 수 있다는 것이다. 이 대칭키 알고리즘을 사용하는 대표적인 암호화 프로토콜로는 DES(Data Encryption Standard, 56bit, ‘데쓰프로토콜로도 읽는다.), 3DES(Triple DES, 168bit)가 있다. DES를 세번 반복하는 3DES는 상대적으로 안전하기는 하지만 당연히 키 길이가 길어짐으로써 더 느려진다는 단점이 있다. 56bit키를 사용하는 DES는 사용을 권장하지 않는다. 현재 대부분의 상업용 암호화는 128비트 이상의 암호화가 구현되는 것이 일반적이다.

 

이러한 대칭키 알고리즘은 작은 키 길이를 사용함으로써 빠르게 암호화와 복호화가 이루어진다는 장점이 있지만 몇가지 문제점을 안고 있다.

 

첫번째 문제는 암호화 키 교환의 어려움이다. Alice‘1234’라는 암호화키를 이용해서 암호문을 만들었다면 암호화된 메시지를 받은 Bob은 역시 ‘1234’라는 키를 알아야만 한다. Bob은 이 키를 어떻게 알 수 있을까? 이때 사용된 암호화키는 웹사이트에 게시하거나 공유폴더에 저장해 둘수는 없다. Bob이 아닌 제3자가 이 Key를 가져간다면 Alice의 암호문을 해독하는 것이 가능하기 때문이다. 전자메일을 사용해서 key를 전송하는 것 역시 조금은 낫지만 바람직한 방법은 아니다. 결국 안전한 방법은 디스켓에 담아서 직접 상대방에게 가져다 주는 방법을 사용해야 할 것이다. 번거로운 일이 아닐 수 없다. 이것을 해결하기 위해서 SSL, Kerberos등의 다른 암호화 방법과 더불어 키 교환을 제공하고 있지만 대칭키 알고리즘 자체로만 보자면 고려되어야 할 부분이다.

 

두번째 문제는 키 관리의 어려움을 들 수 있다. 예를 들어서 웹사이트 하나가 있고 1만명의 회원이 있다고 하자. 1만명의 모든 회원들은 웹서버에 신용카드번호, 유효기간, 비밀번호 등을 전송해야 하는데 당연히 고려할 점은 웹서버가 아닌 어느 누구도 이 데이터를 열수 있어서는 안된다. 이 경우 키는 몇 개가 필요할까? 웹서버가 한대이니 키도 한 개만 있으면 좋겠지만 아쉽게도 키는 1만개가 있어야 한다. 1만명의 회원들에게 각각 고유한 비밀키를 할당해 주어야 한다는 것이다. Alice라는 회원과 Eve라는 회원의 키가 동일하다면 Alice가 암호화한 데이터를 Eve도 해독할 수 있기 때문이다. 그렇게 되면 Confidentiality는 깨지고 만다.

 

이것에 비해 PKI는 보다 유연한 관리를 가능하게 만든다. 하지만 다음장에서 설명할 PKI는 대칭키 방식에 비해서 키 길이가 길고 알고리즘이 복잡하여 성능면에서 상대적으로 떨어진다. 그런 이유로 현재 사용되는 형태를 보면 대칭키 알고리즘과 공용키 알고리즘이 공존하여 쓰이고 있는 형태이다.