TCP/IP PORT 기본 설명

by

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는 안정적인 데이터 전송을 보장 않아도 되는 경우에 사용 하는 것이 좋습니다.

TCP/IP PORT 기본 설명

by ⋅ Link

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는 안정적인 데이터 전송을 보장 않아도 되는 경우에 사용 하는 것이 좋습니다.

스마티(Smarty) – PHP 템플릿 엔진 개요

by

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% 무료로 사용할 수 있는 오픈 소스 프로젝트

[참고자료]

스마티(Smarty) – PHP 템플릿 엔진 개요

by

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% 무료로 사용할 수 있는 오픈 소스 프로젝트

[참고자료]

스마티(Smarty) – PHP 템플릿 엔진 개요

by ⋅ Link

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% 무료로 사용할 수 있는 오픈 소스 프로젝트

[참고자료]

PHP How long do variables stay in the POST array?

by ⋅ Video

http://forums.devshed.com/php-development-5/how-long-do-variables-stay-in-the-post-array-216896.html 에서 참조

The post variables are stored in $_POST inside the HTTP headers. The page submitting the values then post them to the next pages HTTP headers, when the next page goes anywhere it no longer keeps the values and the information stored within the variables are gone.

Webpages unlike applications are known as being ‘stateless’ there’s no state between the server computer and the client computer. This means we have to come up with other means to have ‘state’ the method used is to use user sessions. You want to be interested in User Sessions as within a session you can store information in a $_SESSION variable. On each page you begin the session – this means all your PHP scripts will need to open with session_start(); – make sure it’s right at the top though as it won’t work if any outputted information has already been sent. Then you store information inside the session variables. Research sessions and session variables – or you could look at cookies (though some users do turn off cookies so this is not a fool-proof method of keeping ‘state’).

Tell me if you want more information on sessions and I’ll try to pick out some good sites. Have a try looking for some yourself first .

Hope this helps!!