SVRGROUP 절

SVRGROUP 절에 CGI 사용을 위한 내용을 설정한다. 설정된 내용은 SERVER 절에서 서버 그룹을 설정하는 데 사용된다.

다음은 SVRGROUP 절 설정에 대한 예제이다. SvrType 항목을 CGI로 설정하면 서버 그룹은 CGI를 처리한다.

*SVRGROUP
cgig       NodeName = mynode, 
           SvrType = CGI

SERVER 절

SERVER 절에 서버 프로세스를 설정한다. 다음은 SERVER 절 설정에 대한 예제이다.

*SERVER
cgi        SvgName = cgig, 
           MinProc = 10, 
           MaxProc = 10

cgi라는 이름의 서버 프로세스가 기동된다. SvgName을 SVRGROUP 절에 설정한 cgig로 설정해서 cgi라 명명된 현재의 서버 프로세스는 cgig라는 서버 그룹에 종속된다. cgig가 SvrType이 CGI로 설정되어 있기 때문에 cgi 서버는 CGI 서비스를 한다.

URI 절

URI 절의 설정을 통해 특정 URI의 요청을 CGI로 처리하도록 설정한다. 다음은 URI가 "/cgi-bin/"로 시작할 경우 CGI로 간주하여 처리하도록 설정한 예제이다.

*URI
uri1       Uri = "/cgi-bin/",   
           SvrType = CGI

ALIAS 절

ALIAS 절에 특정 URI에 대해서 실제로 처리하게 되는 물리적인 경로를 설정한다. 해당되는 경로가 DocRoot가 아닌 다른 위치에 있을 경우에만 설정한다.

다음은 ALIAS 절 설정에 대한 예제이다.

*ALIAS
alias1     Uri = "/cgi-bin/",
           Realpath = "${WEBTOBDIR}/cgi-bin/"

SVRGROUP 절

PHP에 관련된 그룹을 설정하고 이를 SEVER 절에서 다시 정의한다.

SVRGROUP 절에 ScriptLoc 항목이 추가되는데, 이는 PHP의 실제 실행 모듈이 있는 위치이다. PHP 모듈이 있는 곳의 경로는 ${WEBTOBDIR}로부터의 상대 경로를 설정해야 한다. ScriptArgs 항목을 설정하여 PHP의 실행 모듈듈을 실행할 때 적용할 옵션을 지정할 수 있다. php.ini 파일등을 지정할 때는 절대 경로를 사용해야 한다.

다음 예제에서 ScriptLoc에 설정된 모듈 경로는 절대 경로가 아니라 "${WEBTOBDIR}/cgi-bin/php"를 의미이며, ScriptArgs에 설정된 경로는 실제(절대)경로를 의미한다.

*SVRGROUP
phpg          NodeName = mynode,
              ScriptLoc = "/cgi-bin/php", # "${WEBTOBDIR}/cgi-bin/php"를 의미
              ScriptArgs = "-c /php_conf/php.ini", # php 실행시 실행모듈에 대한 옵션
              SvrType = PHP

*SERVER
php           SvgName = phpg, MinProc = 10, MaxProc = 10

webtobtimes.com: 메인 페이지

society.webtobtimes.com: 사회면 기사를 다루는 섹션

sports.webtobtimes.com: 스포츠 기사를 다루는 섹션

DocRoot 항목 설정

대량의 Virtual Host에 있어서 DocRoot 설정만 다른 경우 이용할 수 있는 기능으로 각 Virtual Host의 DocRoot는 해당 서버의 도메인 이름 값을 디렉터리 설정 패턴으로 치환함으로서 결정한다.

Docroot = <literal>    (Default : "docs/")

예를 들어 클라이언트에서 http://www.tmax.co.kr로 요청했을 때 이 Virtual Host의 DocRoot를 "${WEBTOBDIR}/docs/www/"로 사용하고 싶을 경우 다음과 같이 설정하면 된다. 마찬가지로 http://webtob.tmax.co.kr로 접속하였다면 DocRoot는 "${WEBTOBDIR}/docs/webtob/"가 된다.

*VHOST
TmaxSoft
    NodeName = tmax,
    Hostname = "www.tmax.co.kr"
    HostAlias = "webtob.tmax.co.kr"
    Port = "80",
    Docroot = "${WEBTOBDIR}/docs/%1/"

Realpath 항목 설정

여러 개의 Virtual Host를 사용할 때 ALIAS 절의 Realpath를 설정한다. 서버의 도메인 이름 값을 디렉터리 설정 패턴으로 치환함으로써 RealPath 경로를 설정할 수 있다.

Realpath = <literal>    (Default : mandatory)

DocRoot를 설정했을 경우와 마찬가지로, "%1"이 클라이언트가 요청한 도메인의 첫 번째 항목으로 치환된다.

*ALIAS
alias1        Uri = "/cgi-bin",
              Realpath = "${WEBTOBDIR}/docs/%1/cgi-bin/"

시스템 측면에서 로그는 디스크에 기록하는 작업을 해야 하기 때문에 로그를 남기지 않는 것에 비해 속도가 약간 느려지게 된다. WebtoB에선 내부적으로 효율적인 방법을 이용하지만, 한계가 있는 관계로 약간의 속도 저하는 발생할 수 있다.

Capacity 측면에서는 로그를 남기는 공간에 대한 부하를 고려해야 한다. 접속자가 적은 곳에서는 로그 파일의 크기가 작겠지만, 접속자가 아주 많은 곳에서는 하루에 로그 파일이 몇 백 Mbytes에서 수 Gbyte에 이르는 로그를 남길 수 있다. 시스템에 적당한 공간이 남아있지 않다면 불가능하기 때문에 이에 대한 관리가 중요하다.

NODE 절

다음과 같이 HTH 개수와 JEUS와의 연결을 맺을 JsvPort를 설정한다.

*NODE
          …
        HTH = 1,
        JsvPort = 9999,
          …

HTH에 설정된 값은 WebtoB에서 HTH 프로세스의 개수로서 이 값과 JEUS 환경 파일 중 WEBMain.xml의 <webtob-listener> 하위에 있는 <hth-count> 항목 값과 일치해야 한다. 또한 JsvPort는 웹 컨테이너와 연결을 맺을 포트 번호로서 실제 웹 브라우저로 요청받는 포트 번호와는 무관하다. JEUS 환경 파일 WEBMain.xml의 <webtob-listener>하위에 있는 <port> 항목 값과 일치해야 한다.

SVRGROUP 절

SVRTYPE이 JSV인 서버 그룹을 설정한다.

*SVRGROUP
htmlg      NodeName = webtob1, SvrType = HTML
jsvg       NodeName = webtob1, SvrType = JSV

SERVER 절

서비스와 실제로 웹 컨테이너와 연결하여 작업을 할 서버를 설정한다.

*SERVER
html       SvgName = htmlg, MinProc = 2, MaxProc = 10
MyGroup    SvgName = jsvg, MinProc = 4, MaxProc = 10

서버의 이름으로 MyGroup이고, 서버 그룹의 이름은 SVRGROUP 부분에서 설정한 jsvg이다.

MinProc은 웹 컨테이너와의 최소 연결 개수이고, MaxProc은 웹 컨테이너와의 최대 연결 개수이다. 이 개수들은 JEUS 환경 파일 중 WEBMain.xml의 <webtob-listener> 하위에 있는 <thread-pool> 설정값과 각각 일치하거나 커야 한다.

URI 절

URI 부분은 어떤 URI가 요청이 되었을 때 어떤 서버를 수행시킬지를 지정하는 것으로 서버(MyGroup)의 서비스에 대한 URI를 설정한다.

다음은 "/examples/" URI에 대해 JSV 서버(MyGroup)의 서비스를 수행하도록 설정하는 예이다.

*URI
uri1     Uri = "/examples/",
         SvrType = JSV,
         SvrName = MyGroup

REVERSE_PROXY_GROUP 절

다음과 같이 reverse proxy를 그룹으로 묶어서 하나로 관리할 항목들을 설정한다.

*REVERSE_PROXY_GROUP
rproxyG1
         VhostName = "vhost1",
         PathPrefix = "/before/",
         RegExp = "\.(do|jsp)$",
         ServerPathPrefix = "/after/",
         RewriteHtmlUrl = "/after/ /before/",
         HtmlUrl = "a href",
         HtmlUrl = "img src",
         HtmlUrl = "link href",
         HtmlUrl = "script src",
         HtmlUrl = "frame src",
         HtmlUrl = "td background",
         HtmlUrl = "table background",
         HtmlUrl = "iframe src",
         HtmlUrl = "OBJECT CODEBASE",
         RewriteHtmlMaxSize = 4194304,
         WBRoutingCookieKey = "W2BRID"
        #SessionIDCookieKey = "JSESSIONID"

위 설정은 /before/로 시작하는 요청을 /after/로 변경하여 서비스하기위한 설정이된다.

다중 WAS를 구성하는 것은 각각의 WAS에서 동일한 서비스를 하기 위한 목적이기 때문에 VhostName, PathPrefix, RegExp, ServerPathPrefix 항목은 reverse proxy group과 reverse proxy가 동일하게 설정하거나 reverse proxy group에만 설정해야 한다.

WAS의 sticky session routingid와 상관없이 자체 routingid를 사용하고자 하는 경우 WBRoutingCookieKey 설정을 사용하면 된다.

REVERSE_PROXY 절

reverse proxy group명과 WAS의 HTTP Listener 정보(Ip:Port) 및 각 WAS별 연동정보를 설정한다.

*REVERSE_PROXY
rproxy1
         ServerAddress = "127.0.0.1:8088",
         ReverseProxyGroupName = "rproxyG1",
         MinPersistentServerConnections = 1,
         MaxPersistentServerConnections = 20,
         PersistentServerCheckTime = 50,
         PersistentServerTimeout = 300,
         PersistentServerCheckUrl = "/after/ping.html",
         MaxWebSocketConnections = 20
        #StickySessionRoutingID = "was1_servlet_engine",
        #ProxySSLFlag = Y,
        #ProxySSLName = pssl1

rproxy2
         ServerAddress = "127.0.0.1:8089",
         ReverseProxyGroupName = "rproxyG1",
         MinPersistentServerConnections = 1,
         MaxPersistentServerConnections = 20,
         PersistentServerCheckTime = 50,
         PersistentServerTimeout = 300,
         PersistentServerCheckUrl = "/after/ping.html",
         MaxWebSocketConnections = 20
        #StickySessionRoutingID = "was2_servlet_engine",
        #ProxySSLFlag = Y,
        #ProxySSLName = pssl1

위 설정은 rproxyG1 그룹에 속하는 rproxy1(127.0.0.1:8088), rproxy2(127.0.0.1:8089) 설정을 한 경우이며, 요청은 RR(Round Robin) 방식으로 분배된다. 하나의 reverse proxy 내에서 연결이 여러개 존재할 때 요청은 각 연결에 대하여 FA(First Assign) 방식으로 분배된다.

MaxPersistentServerConnections은 동시 요청을 최대로 처리할 수 있는 연결 수를 설정한다. MaxPersistentServerConnections보다 많은 요청이 동시에 들어온다면 WebtoB가 큐잉하게 된다.

MinPersistentServerConnections은 요청이 없더라도 지속적인 연결을 유지하고자 하는 연결 수를 설정한다. MinPersistentServerConnections을 넘어선 연결들은 PersistentServerTimeout 시간 동안 어떠한 요청도 들어오지 않으면 끊어지게 된다.

PersistentServerCheckTime은 WAS와의 연결을 지속적으로 유지하기 위해 PING 메시지를 보내는 주기이다. 이 값은 WAS의 HTTP Listener에 대한 KeepAliveTimeout보다 작게 설정해야 한다. 그렇지 않으면 WAS에서 먼저 연결을 끊어버릴 것이기 때문이다. 해당 주기마다 WebtoB는 WAS에 주기적으로 PING 메시지를 보내고 이에 대한 응답을 받음으로써 각 연결들을 지속적으로 유지하게 된다. 이를 바탕으로 WebtoB는 WAS와의 연결에 대하여 connection pool을 구성하게 되고 각 connection을 동적으로 관리할 수 있게 된다.

PING 메시지는 PersistentServerCheckUrl 설정을 가지고 만들어진 HTTP HEAD Request이다. 위와 같이 설정하게 되면 PING 메시지는 "HEAD /after/ping.html HTTP/1.1"가 된다. HEAD 메소드는 HTTP Response Header만 받고자 하는 메소드이기 때문에 PING 메시지에 대한 응답(PONG 메시지)을 최소화 하는데 유용하다. 이를 위해 WAS에서는 반드시 "/after/ping.html" application을 준비해야 한다.

WAS와의 connection을 WebSocket으로 사용하는 경우 MaxWebSocketConnections 설정을 통해 WebSocket으로 사용하고자 하는 connection 수를 제한할 수 있다.

reverse proxy group에 WBRoutingCookieKey를 설정한 경우 rproxy1, rproxy2에 대해 자체 routing하게 된다. rproxy1에서 처리된 응답에 대해 WBRoutingCookieKey와 rproxy1을 Base64로 인코딩된 값을 Set-Cookie 헤더 추가해준다. 이후 동일 클라이언트로부터의 요청을 받은 경우 Cookie의 해당 값을 이용하여 rproxy1로 요청을 routing하게 된다. WBRoutingCookieKey를 사용하지 않는 경우에 StickySessionRoutingID는 reverse proxy group의 SessionIDCookieKey설정과 함께 sticky session routing을 사용하는 경우 설정한다. WAS에서 "Set-Cookie" Responose Header에 JSESSIONID로 만들어 주는 값의 dot(.)이후의 엔진명을 넣어주면 된다.

ProxySSLFlag, ProxySSLName은 WebtoB와 WAS의 연결에 대해 SSL 암호화 통신을 할 경우 설정한다.

PROXY_SSL 절

WebtoB와 WAS의 SSL 암호화 통신을 할 경우 설정한다.

*PROXY_SSL
pssl1          
         Verify = 2,
         VerifyDepth = 1,
         RequiredCiphers = "ALL:!ADH:!EXPORT56:RC4+RSA:!SHA:+HIGH: +MEDIUM:+LOW:+SSLv2:+EXP:+eNULL",
         CACertificateFile="$(WEBTOBDIR)/ssl/server.crt",
         CheckPeerValidPeriod = Y

위 설정은 WebtoB가 WAS로 연결을 맺을 때 SSL 연결을 위한 설정이다. WebtoB가 클라이언트가 되고 WAS가 서버가 되기 때문에 WAS는 서버를 위한 SSL 설정을 해야 한다. 이렇게 설정된 경우 WebtoB는 WAS로 연결을 맺을 때 TCP 연결 이후 SSL Handshake 과정을 요청한다.

SSL Handshake 과정에서 서버 인증서를 검증하고자 하는 경우 Verify를 2로 설정하고 그렇지 않다면 0으로 설정하면 된다. 서버 인증서를 검증하는 경우 반드시 CACertificateFile을 설정해야 한다.

<TestString>

TestString에는 다음과 같은 예약어와 일반 문자열을 사용할 수 있다.

<CondPattern>

CondPattern은 Perl compatible reqular expression을 사용할 수 있으며, 다음과 같은 추가적인 패턴을 사용할 수 있다.

참고로 다음은 Regex vocabulary에 대한 설명이다.

[flags]

CondPattern에 [flags]를 사용하여 패턴 매칭 방식을 변경할 수 있다.

다음은 [OR] flag 사용한 예이다.

RewriteCond %{HTTP_HOST}  ^host1.*  [OR]
RewriteCond %{HTTP_HOST}  ^host2.*  [OR]
RewriteCond %{HTTP_HOST}  ^host3.*
RewriteRule ...

[OR] flag를 사용하지 않을 경우 3개의 RewriteCond/RewriteRule을 각각 생성해야 한다.

<Pattern>

<Substitution>

URL을 어떤것으로 교체할지 설정하며, 다음과 같은 값을 사용할 수 있다.

[flags]

예제 1

다음은 "www.test.com/"과 같은 URL 패턴을 매칭하여, "www.test.com/rewrite.html"로 변환하는 URLRewriteConfig 설정 예제이다.

# url rewrite config - ex1
RewriteCond %{HTTP_HOST} ^www\.test\.com$       # if {Host} == "www.test.com"
RewriteRule ^/$ /rewrite.html [L]               # then "/" > "/rewrite.html"

예제 2

다음은 "www.test.com/temp/xxx.html"과 같은 요청을 할 때 temp 디렉터리에 xxx.html 파일이 없는 경우 "www.test.com/temp/temp_error.html"로 변환하는 URLRewriteConfig 설정 예제이다.

# url rewrite config - ex2
RewriteCond %{REQUEST_FILENAME} !-f             
# if {요청파일명} != 파일을 가리키거나 포함
RewriteRule ^/([^/]+) /$1/$1_error.html [L]     
# then "/temp/xxx.html" > "/temp/temp_error.html"

예제 3

다음은 "http://www.test.com:80"과 같은 요청을 할 때 "https://www.test.com:443"으로(http 요청을 https 요청으로) 변환하는 URLRewriteConfig 설정 예제이다.

# url rewrite config - ex3
RewriteCond %{HTTP_HOST} ^www\.test\.com$       
# if {Host} == "www.test.com"
RewriteCond %{SERVER_PORT} 80                   
# AND {Port} == "80"
RewriteRule .* https://www.test.com:443$0 [R]    
# then > "https://www.test.com:443$0"   ($0: request uri)

예제 4

다음은 "www.test.com/xxx.html"과 같은 URL 패턴을 매칭하여 Request URI는 무시하고 무조건 "www.test_new.com/"으로 변환하는 URLRewriteConfig 설정 예제이다.

# url rewrite config - ex4
RewriteCond %{HTTP_HOST} ^www\.test\.com$       # if {Host} == "www.test.com"
RewriteRule .* http://www.test_new.com [R]       # then > "http://www.test_new.com"

예제 5

다음은 "www.test.com/test.html"과 같은 URL 패턴을 매칭하여 "www.test_new.com/test.html"로 변환하는 URLRewriteConfig 설정 예제이다.

# url rewrite config - ex5
RewriteCond %{HTTP_HOST} ^www\.test\.com$       
# if {Host} == "www.test.com"
RewriteRule .* http://www.test_new.com$0 [R]     
# then > "http://www.test_new.com$0"   ($0: request uri)

예제 6

다음은 Request Method가 POST이고 Referer Header가 없을 경우 "403 Forbidden" 에러로 처리하는 URLRewriteConfig 설정 예제이다.

# url rewrite config - ex6
RewriteCond %{REQUEST_METHOD} POST              # if {Method} == "POST"
RewriteCond %{HTTP_REFERER} =""                 # AND {Referer} == ""
RewriteRule . - [F]                             # then > 403 Forbidden Return

예제 7

다음은 "/../" 으로 시작하는 요청의 경우 "/403.html"로 처리하는 URLRewriteConfig 설정 예제이다.

# url rewrite config - ex7
RewriteRule ^/\.\./ /403.html [L]               # "/../"로 시작 > "/403.html"

예제 8

다음은 "aaa.test.com/xxx.html"로 요청할 경우 "www.test.com/aaa/xxx.html"로, "bbb.test.com/xxx.html"로 요청할 경우 "www.test.com/bbb/xxx.html"로 처리하는

# url rewrite config - ex8
RewriteCond %{HTTP_HOST} ^(aaa|bbb)\.test\.com  
# if {Host} == ("aaa.test.com" OR "bbb.test.com")
RewriteRule .* /%1$0 [L]                         
# then "/xxx.html" > "/(aaa|bbb)/xxx.html" (%1: RewriteCond의 첫번째 괄호, $0: request uri)

예제 9

다음은 "www.test.com/test.do?query=value1"로 요청할 경우 "www.test.com:8080/test.do?query=value1"로, "www.test.com/test.do?query=value2&.."으로 요청할 경우 "www.test.com:8080/test.do?query=value2&.."로 Query string에 따라 포트 변경 처리를 하는 URLRewriteConfig 설정 예제이다.

# url rewrite config - ex9
RewriteCond %{QUERY_STRING} ^query=value1$ [OR] 
# if {QueryString} == "query=value1" 
RewriteCond %{QUERY_STRING} ^query=value2&      
# OR {QueryString} == "query=value2&.." 
RewriteRule .* http://www.test.com:8080$0 [R]    
# then > "http://www.test.com:8080$0"   ($0: request uri)

예제 10

다음은 "aaa.test.com/test.html"로(www 로 시작하지 않는) 요청할 경우에 "www.test.com/aaa/test.html"로 처리하는 URLRewriteConfig 설정 예제이다.

# url rewrite config - ex10
RewriteCond %{HTTP_HOST} !^www\.test\.com$          
# if {Host} != www.test.com
RewriteCond %{HTTP_HOST} ^([a-zA-Z0-9]+)\.test.com$ 
# AND {Host} == "(영문숫자조합).test.com"
RewriteRule  .* /%1/$0 [L]                           
# then > "(영문숫자조합)/$0"   (%1: RewriteCond의 첫번째 괄호, $0: request uri)

예제 11

다음은 Request Header에 Referer Header가 없이 css나 js 파일을 요청하는 경우 403 Forbidden으로 처리하는 URLRewriteConfig 설정 예제이다.

# url rewrite config - ex11
RewriteCond %{HTTP_REFERER} !.        # if {HTTP_REFERER} == ""
RewriteRule \.(css|js)$ - [F]         # then "*.css|*.js" > 403 Forbidden Return

예제 12(REQEUST_URI)

다음은 "/user@somehost.com/"과 같은 URL 패턴을 매칭하여 "/req_test.jsp?blogId=user@somehost.com"으로 변환하는 URLRewriteConfig 설정 예제이다.

# url rewrite config - ex12 (REQEUST_URI)
RewriteCond %{REQUEST_URI} /([a-zA-Z0-9_-]+(@([a-zA-Z0-9_-]+).(com|net|co.kr))?)/?$
RewriteRule . /req_test.jsp?blogId=%1 [PT,L]

예제 13(HTTP_HOST)

다음은 HTTP Request Header의 호스트가 "tmaxsoft.com"으로 끝나고, URL이 "/redirect/"로 시작하는 경우를 매칭하여 "http://www.tmaxsoft.com/redirect.html"로 redirect하도록 하는 URLRewriteConfig 설정 예제이다.

# url rewrite config - ex13 (HTTP_HOST)
RewriteCond %{HTTP_HOST} tmaxsoft.com$
RewriteCond %{REQUEST_URI} /redirect/.*$
RewriteRule . http://www.tmaxsoft.com/redirect.html [R,L]