2014. 7. 14. 11:00




1. HTTP 기본 구조(HTTP 1.0 이하)




파란 테두리: 첫 번째 Socket(TCP) 연결 및  HTTP Request/Response 처리 과정

빨간 테두리: 두 번째 Socket(TCP) 연결 및  HTTP Request/Response 처리 과정



위 그림(Wire Shake 예제)에서와 같이 HTTP는 기본적으로 Connection-Less 방식을 가진다. 즉 맷어진 Socket 연결은 유지되지 않고 매번 끊어지며다시 생성 되는 구조이다.



웹 서버 상세 처리 과정:

http://mohwaproject.tistory.com/entry/%EC%A0%95%EC%A0%81%EB%8F%99%EC%A0%81-%ED%8E%98%EC%9D%B4%EC%A7%80-%EC%9B%B9-%EC%84%9C%EB%B2%84-%EC%B2%98%EB%A6%AC-%EA%B3%BC%EC%A0%95







2. Keep-Alive(HTTP 1.1 이상) 기능 이란?


위 HTTP 기본 구조를 바탕으로 맷어진 Socket 연결이 종료된 시점(HTTP Response 이후)부터 웹 서버에 정의된 Keep-Alive Timeout 까지 기존 연결(Socket)을 유지하는 기능.


즉, 정의된 시간(Keep-Alive Timeout) 내에 새로운 HTTP 요청이 발생한다면? 맷어진 Socket 연결을 지속적으로 유지할 수 있다.(앞서 말한바와 같이 지속적인 연결은 유지되나 정의된 Keep-Alive Timeout  시간은 정확히 지켜지지 않는다.(보통 정의된 시간보다 Socket 연결이 일찍 끊어진다.)



IIS 테스트 결과 정의된 시간의 50% 이상 일찍 끊어진다.(120초 / 2)







3. IIS(6 / 7) Keep-Alive 설정 방법



- IIS 6


1. Keep-Alive 활성화 설정 및 Keep-Alive Timeout 정의


연결 시간 제한은 기본 120초를 갖는다.






- IIS 7:


1. Keep-Alive 활성화 설정












2. Keep-Alive Timeout 정의


연결 시간 제한은 기본 120초를 갖는다.












4. 웹 서버 HTTP Connection 변화




- Keep-Alive 비활성화 시:


1. 아래 예제와 같이 맷어진 HTTP Connection(Socket 연결)은 유지되지 않고 바로 끊어진다.(Current Connection 0.000)


2. Response-Header Field인 Connection 값으로 "close" 를 응답한다.








- Keep-Alive 활성화 시:


1. 아래 예제에서와 같이 맷어진 HTTP Connection(Socket 연결)은 유지된다.(Current Connection 1.000)


지속적인 연결은 유지되나 정의된 Keep-Alive Timeout(120초)  시간은 정확히 지켜지지 않는다.(보통 정의된 시간보다 Socket 연결이 일찍 끊어진다)


2. Response-Header Field인 Connection 필드는 존재하지 않는다.(IIS 기준)










5.  Wire Shake를 통해 본 Keep-Alive 처리 과정



파란 테두리: 첫 번째 Socket(TCP) 연결 및  HTTP Request/Response 처리 과정

빨간 테두리: 두 번째 Socket(TCP) 연결 및  HTTP Request/Response 처리 과정(Keep-Alive 활성화 시 HTTP 기본 구조와 달리 TCP 세션 수립과정 중 일부가 생략 되었다는걸 볼 수 있다.)







Keep-Alive 처리 과정


1. HTTP Session(논리적 연결) 생성




2. 정의된 Keep-Alive Timeout 내에 새로운 HTTP 요청이 발생할 경우, 새로운 Socket을 재 생성하는 것이 아닌 활성화 된 Keep-Alive 기능을 통해 유지된 Socket 연결 Request하게 된다.


즉, Socket 연결에 필요한 모든 비용이 감소하게 되며, 그에 따라 전체적인 성능도 좋아지게 된다.




3. 클라이언트(브라우저)와 웹 서버는 HTTP Request 및 Response를 수행한다.




4. 정의된 Keep-Alive Timeout 동안 맷어진 Socket 연결은 지속적으로 유지된다.




5. HTTP Session Close


- 클라이언트(사용자) 접속 종료 시 서버에 적재된 HTTP Session은 소멸된다.






Keep Alive Timeout(연결 유지 시간) 종료 시 처리 과정



파란 테두리: 첫 번째 Socket(TCP) 연결 및  HTTP Request/Response 처리 과정


빨간 테두리: 두 번째 Socket(TCP) 연결 및  HTTP Request/Response 처리 과정(Keep-Alive 활성화 시 HTTP 기본 구조와 달리 TCP 세션 수립과정 중 일부가 생략 되었다는걸 볼 수 있다.)


주황 테두리Socket(TCP) 연결 및  HTTP Request/Response 처리 과정(정의된 Keep-Alive Timeout(연결 유지 시간) 종료 시  첫 번째 요청과 같이 TCP 세션 수립과정 이 다시 발생하게 된다.)


출저: http://mohwaproject.tistory.com/entry/Wire-Shake%EB%A5%BC-%ED%86%B5%ED%95%B4-%EB%B3%B8-KeepAlive-%EC%B2%98%EB%A6%AC-%EA%B3%BC%EC%A0%95



TCP 세션 수립 과정



이번 포스트에서는 SSL 동작 방식에 앞서 패킷 교환 방식의 기본인 TCP 3 Way Handshake에 대해서 알아보도록 하겠습니다.



TCP 3 Way Handshake의 정의:


송신 측과 수신 측이 서로 교환할 패킷을 위해 총 3개의 패킷을 주고받으며, 서로에 대한 전송을 보장하는 세션을 수립하는 

과정입니다.




아래는 TCP 3 Way Handshake 과정을 대략적으로 도식화 한 그림 입니다.












TCP 3 Way Handshake 에 대한 상세 과정은 아래와 같습니다.






송신 측 호스트(211.254.99.210(클라이언트))

수신 측 호스트(203.242.213.203(웹서버))



1. 송신 측은 수신 측과의 통신을 원하고 있음을 알리는 신호로 TCP 헤더의 SYN(Synchoronize) Flag를 활성화(1)하고, 패킷에 일련번호(S/N(seq = 0))를 붙어 상대방에게 알려줍니다.


2. 이때 수신 측은 송신 측 SYN(Synchoronize)Flag 신호에 대한 응답 패킷 생성에 들어가기 위해, ACK(Acknowledgement)Flag를 on 시키고, 송신 측 일련번호(S/N(seq = 0))에 1을 더한 응답(A/N(ack = 1))값과 

자신의 일련번호(S/N(seq = 0))를 발송합니다. 또한, 이 과정은 송/수신 측의 양방향 세션이 수립되었음을 의미합니다.


3. 송신 측은 수신 측에게 두 번째 패킷(ack 및 일련번호(S/N(seq = 1) == (수신 측에게 받은 ack = 1 값))에 대한 응답을 주며, 이때부터 양 방향 패킷 교환이 시작되는 것입니다.






아래는 송/수신 간에 패킷 교환이 이루어지는 과정입니다.




송/수신간에 세션 수립(TCP 3 Way Handshake) 과정이 끝난 후 송신 측이 수신 측에게 GET요청을 보내고 있으며, 그에 따른 응답 메시지가 전송되고 있습니다.






위와 마찬가지로 송신 측의 GET 요청에 대한 응답 메시지가 전송됩니다.






페이지의 구성요소(js, css, img 등)이 요청됩니다.






웹서버가 클라이언트에게 HTML 응답 패킷을 전송합니다.




출저

http://mohwaproject.tistory.com/entry/TCP-3-Way-HandshakeTCP-%EC%84%B8%EC%85%98-%EC%88%98%EB%A6%BD


Posted by hoonihoon
2014. 7. 14. 10:44

들어 가면서

HTTP는 아시다 시피 connection less 방식으로 연결을 매번 끊고 새로 생성하는 구조입니다. 이는 network 비용측면에서 많은 비용을 소비하는 구조입니다.( 최초 연결하기 위한 준비과정을 의미함 ) 그래서 HTTP 1.1부터는 Keep-Alive라는 기능을 지원합니다.


Keep Alive란?

Keep Alive란 연결된 socket에 IN/OUT의 access가 마지막으로 종료된 시점부터 정의된 시간까지 access가 없더라도 대기하는 구조입니다. 즉 정의된 시간내에 access가 이루어진다면 계속 연결된 상태를 유지할 수 있다는 것 이죠.


HTTP 下에서 Keep Alive란?

HTTP는 앞서 설명드린 것과 같이 connection less방식이라 매번 socket(port)를 열어야 하고 이는 비용적인 측면에서 비효율적인 구조입니다. 해서 keep Alive time out내에 client에서 request를 재 요청하면 socket(port)를 새로 여는 것이 아니라 이미 열려 있는 socket(port)에 전송하는 구조가 됩니다.


예를 들면 image를 4개를 보여주는 구조에서 client는 동시에 2개의 image만 얻어 올수 있고 1개의 image는 얻는데 2초 걸리고 port를 여는데 1초가 걸린다고 가정.



keep alive : false 

처음 server에 2개의 port를 열고 image를 얻고 client socket의 닫고 ( 3초 ) 

다시 server에 2개의 port를 열고 image를 얻고 client socket을 닫음 ( 3초 ) 

총 6초가 걸림.

keep alive : true 

처음 server에 2개의 port를 열고 image를 얻고 ( 3초 ) 

다시 첫번째 요청에서 열어 둔 2개의 port에 2개의 image를 얻음 ( 2초 ) 

keep alive time out이 되었을 때 client의 socet이 닫히거나 browser가 더 이상 얻어 올 것이 없으면 자동으로 닫어 버림. 

총 5초가 걸림.



Keep Alive를 그럼 어떻게 쓸수 있는가?

딱, 잘라서 말하면 개발자 영역에서 할 부분은 전혀 없습니다.


client(browser)는 http 1.1을 준수하고 이해 할수 있다고 request에 Connection: Keep-Alive를 넣어서 Server에 전송 

즉 client는 http 1.1 spec을 구현하고.. 

server도 http 1.1 spec을 구현하고 keep alive 기능을 활성화하고 keep alive time out을 설정

참고

client에서 keep alive code를 보내고 server도 kepp alive 기능을 제공할 경우.


$ telnet pungjoo.com 80

Trying 121.124.124.74...

Connected to pungjoo.com.

Escape character is '^]'.

GET / HTTP/1.1

Host: pungjoo.com

Connection: Keep-Alive

HTTP/1.1 302 Moved Temporarily

Date: Tue, 15 Jan 2008 01:32:45 GMT

Set-Cookie: JSESSIONID=91569ADEF9D501B8071BD59D0DC04E82; Path=/

Location: http://pungjoo.com/servlet/com.pungjoo.blog2005.Action

Content-Type: text/html;charset=EUC-KR

Content-Length: 0

Keep-Alive: timeout=5, max=100

Connection: Keep-Alive


Connection to pungjoo.com closed by foreign host.


위에 Connection to pungjoo.com closed by foreign host. 메시지가 바로 나오는 것이 아니라 5초 후에 나오게 됩니다.

즉 server/client의 구간은 지속됨을 알수 있습니다.



$ telnet pungjoo.com 80

Trying 121.124.124.74...

Connected topungjoo.com.

Escape character is '^]'.

GET / HTTP/1.1

Host: pungjoo.com

Connection: Keep-Alive

HTTP/1.1 302 Moved Temporarily

Date: Tue, 15 Jan 2008 01:36:26 GMT

Set-Cookie: JSESSIONID=2B3EE2FE56868BD9588A7B55C405974B; Path=/

Location: http://pungjoo.com/servlet/com.pungjoo.blog2005.Action

Content-Type: text/html;charset=EUC-KR

Content-Length: 0

Keep-Alive: timeout=5, max=100

Connection: Keep-Alive


GET / HTTP/1.1

Host: pungjoo.com

Connection: Keep-Alive


HTTP/1.1 302 Moved Temporarily

Date: Tue, 15 Jan 2008 01:36:35 GMT

Set-Cookie: JSESSIONID=E4E3D9B9CFE3693DC5AFC3D6ABDE5564; Path=/

Location: http://pungjoo.com/servlet/com.pungjoo.blog2005.Action

Content-Type: text/html;charset=EUC-KR

Content-Length: 0

Keep-Alive: timeout=5, max=99

Connection: Keep-Alive


Connection to pungjoo.com closed by foreign host.



위 예제를 보시면 알겠지만 telnet(연결)은 한번 사용했고 GET method를 2번 날렸습니다. 즉 이렇게 할수 있는 이유는 keep alive 기능때문에 가능한 것 입니다.


참고로 보면 Keep-Alive: timeout=5, max=99 부분에서 max가 감소를 하는 것을 볼수 있는데 이는 최초 연결된 port에 대해서 100회 request를 받겠다는 의미입니다.


HTTP1.0으로 해 보겠습니다. 즉 keep alive 기능이 없음.


$ telnet pungjoo.com 80

Trying 121.124.124.74...

Connected to pungjoo.com.

Escape character is '^]'.

GET / HTTP/1.0

Host: pungjoo.com

HTTP/1.1 302 Moved Temporarily

Date: Tue, 15 Jan 2008 01:33:56 GMT

Set-Cookie: JSESSIONID=B4329BFEDB1363BB90FCFA9568DDBF0B; Path=/

Location: http://pungjoo.com/servlet/com.pungjoo.blog2005.Action

Content-Type: text/html;charset=EUC-KR

Content-Length: 0

Connection: close


Connection to pungjoo.com closed by foreign host.


이번 경우는 response가 날라 오고 바로 'Connection to pungjoo.com closed by foreign host.'로 나와 버립니다. 즉 바로 server/client에서 끊어 버립니다.




출저: http://pungjoo.tistory.com/2

Posted by hoonihoon
2014. 5. 19. 10:20

1. L4는 IP,포트,세션을 기반으로한 로드밸런싱이다.


2.  L4 스위치는 부하분산 장비이며,  L4 스위치를  로드밸런서 라고 한다. (Load Balancer)

    동일한 역할을 수행하는 서버 그룹을 VIP를 통해 관리하며, 서버로 향하는 트래픽을 일단 VIP를 가진 L4 스위치로 수신한뒤

    분배 정책에 따라 적절한 서버에 분배해 주는 것을 말한다.

    VIP는 Virtual IP 의 약자로, 서버 그룹의 대표 IP라 할 수 있습니다. 이 VIP를 로드밸런싱을 수행하는 L4 스위치가 있습니다.

    서버와 통신하고자 하는 클라이언트는 VIP를 향해 트래픽을 전송하고 L4 스위치가 이 트래픽을 받아 적절한 서버에 로드밸런싱 해주는 것이 L4 스위치의 역할 입니다.


3. 보통 서버 한대로 사용자의 트래픽을 감당하기 어렵기 때문에 동일한 역할을 수행하는

서버를 여러 대 두어서 사용자들의 트래픽이 많아져도 유연하고 안정적으로 사이트를 

운영하기 위해 L4 스위치를 통한 로드밸런싱을 한다.


4. 장점


1) 서버 이용률과 네트워크 대역폭의 효율이 증가 한다.

 - 사용자 세션 트래픽이 서버 풀에 있는 현재 가용한 서버들 중에서 부하가 적은 서버를 통해 처리 됩니다. 그러므로, 하나의 서버에 트래픽이 집중되는 것을 막아주고 서버의 트래픽처리 지연으로 인해 발생할 수 있는 대역폭의 낭비도 줄일 수 있습니다.


2) 사용자에게 신뢰성 있는 서비스를 제공할 수 있습니다.

- 하나의 서버에 문제가 발생하더라도 나머지 서버들에 의해 어플리케이션과 데이터로 접속할수 있습니다.


3) 서비스의 범용성을 높일 수 있습니다.

- 사용자가 늘어나고 서버들의 처리 용량이 부족하게 되는경우, 기존 서비스에 영향을 주지 않고 새로운 서버를 서버풀에 추가 할 수 있습니다. 





참고:

http://blog.naver.com/dltlahs007?Redirect=Log&logNo=100037040202

http://finerss.tistory.com/40



정리 제일 잘된거 펌!  http://finerss.tistory.com/40


한마디로 말하면,

L4의 핵심은 'IP, 포트, 세션' 을 기반으로한 
로드 밸런싱(Load Balancing)이다!

라고 말하고 싶네요. L4에서 가장 중요한건 역시 4계층답게 
포트(port)라는 생각이 드네요.

2계층의 MAC
3계층의 IP
그럼 4계층은 바로 포트 입니다.

그리고 이 포트와 맞물려 로드 밸런싱이라는 개념이 등장 합니다.

L4 스위치는 마치 포트와 로드밸런싱의 오묘한 조합이랄까요.

L4 스위치 = 포트 + 로드밸런싱(물론 IP,세션도 중요합니다)

L4스위치가 로드밸런싱을 수행하는 장비이기 때문에 L4스위치를 
다른말로 로드 밸랜서(Load Balancer) 라고도 합니다.

로드밸런싱은, 동일한 역할을 수행하는 서버 그룹을 VIP를 통해 관리하며, 
서버로 향하는 트래픽을 일단 VIP를 가진 L4스위치로 수신한 후 
분배정책에 따라 적절한 서버에 분배해 주는 것을 말합니다.

VIP는 Virtual IP의 약자로, 서버그룹의 대표 IP라 할 수 있습니다. 
이 VIP를 로드밸런싱을 수행하는 L4 스위치가 가지고 있습니다.
서버와 통신하고자 하는 클라이언트는 VIP를 향해 트래픽을 전송하고 
L4스위치가 이 트래픽을 받아 적절한 서버에 로드밸런싱 해주는 것이 
L4스위치의 역할입니다.

한마디로, L4 스위치는 부하분산 장비입니다.
요즘 웬만한 사이트는 서버 한 대로 사용자들의 트래픽을 감당하기 
어렵기 떄문에 동일한 역할을 수행하는 서버를 여러 대 두어서 사용자들의 
트래픽이 많아져도 유연하고 안정적으로 사이트를 운영하기 위해 
L4스위치를 통한 로드밸런싱
을 하는걸로 알고 있습니다.

L4스위치, 즉 로드밸란서가 없어도 네트워크를 하는데 지장은 없습니다. 
하지만 IT가 발전하고 트래픽이 과도해지면서 로드밸런서 없이는 안정적인
네트워크를 구성하는것이 불가피해지고 있다는 생각이 드네요.


이 그림에서 보는바와 같이,
클라이언트와 서버 사이에 로드밸란서가 위치하여 서버 2대에 대해 
로드밸런싱을 수행합니다.
즉, 로드밸런서가 트래픽을 왼쪽 서버로 보낼 수도 있고, 오른쪽 서버에 보낼 
수도 있습니다.


###################################################

그러면 L4를 왜 쓰느냐??

2가지 이유가 있습니다.

첫 번째 로드를 분산하기 위해서 입니다.(로드 발란싱)

예를 들어 한 서버에 웹 서비스(80)를 하는 서버가 있습니다.

그런데 서버에 부하 때문에 서버를 증설 해야 합니다.

하지만 서버를 분리 시키면 IP가 하나 더 필요하게 되고 IP가 늘어나면 기존 서비스와 IP가 달라지는 문제가 생깁니다.

이 때 사용하는 것이 L4장비의 VIP입니다.

예를 들어 기존에 사용하는 서버의 IP가 128.x.x.1이라고 합시다.

이 IP를 L4장비에 VIP로 할당합니다. 128.x.x.1 for 80 128.x.x.1 regarding 80

(VIP는 가상의 아이피를 말합니다.)

기존 서버에는 128.x.x.2 와 새로운 서버에는 128.x.x.3을 할당합니다.

(물론 기존 서버와 새로운 서버는 데이타가 동기되어 있어야 합니다.)

그리고 L4장비에 로드발란싱이 가능하게 세팅합니다.


그러면 이제 128.x.x.1로 요청하는 응답에 대해서 L4가 처리 하게됩니다. (대표IP로 서버여러대를 가지치기 할수 있다.)

L4는 로드발란싱 규칙에 따라서 기존 서버에서 응답하게 할 수도 있고 신규 서버에서 응답하게 할 수도 있습니다.


간단하게 L4에서 홀수 번째 요청은 기존 서버에서 짝수 번째 요청은 신규 서버에서 응답하게 설정 할 경우 요청에 대한 응답을 정확하게 반으로 나눌수 있습니다.


이렇게 한 서버의 요청건수를 줄여주어 실제로 한대의 서버가 처리해야 할 요청을 두대(여러 대)의 서버가 처리하게 되는 것을 로드 발란싱이라고 합니다.

알테온으로 설명 드리면, 웹서버 두대를 로드밸런싱 하려면 먼저

웹서버를 각각 real server 로 각각 ip를 등록합니다.
그리고 웹서버 즉 real server ip 두개 를 group1 에 소속시킵니다.
그리고 virtual ip (vip=대표ip)를 하나 등록해서 그 ip로 오는
패킷중에 http(80) 패킷에 대해서는 group1으로 보내면 
설정된 
matric(hash, 라운드로빈, least connection, weighted )값에 의해
로드밸런싱 되는것입니다. 대부분 hash 방식을 사용하죠...


이렇게 하면 128.x.x.1 for 80 은 오직 80 포트만을 받고, 다른 포트는 filtering 된다.. 쓸데없는 포트로 들어오는 공격을 막을수 있다.


그리고 L4의 두번째 기능으로 무결성을 위한 fail over기능입니다.


흔히 가장 안정적으로 서비스되는 서버는 일년에 다운타임(동작 불능시간)이 50분 미만인 서버라고 합니다.

(1년동안 50분 정도 다운되면 최고로 안정적인 서버가 되는 것입니다.)


서버역시 기계인 것이라 영원히 죽지 않는 서버는 존재하지 않습니다.

그러나 사람들은 좀더 서버가 안정적으로 동작하길 윈하게 되죠

아주 중요한 서버(예를 들면 정치 관련 홈페이지나 은행과 같은 금융 그리고 그 외 쇼핑몰등)의 경우 일년에 50분의 다운이라도 서비스에 큰 타격을 입을 수 있습니다.


예를 들어 128.x.x.1이라는 서버가 있습니다.

그러나 이 서버는 중요한 서버라 절대 서버에 장애가 있으면 안됩니다.

이럴경우 사용하는 장비가 L4입니다.


L4에 VIP를 이용해서 128.x.x.1이라는 IP를 할당합니다.

기존 서버의 IP를 128.x.x.2로 변경합니다.

새로운 서버에 128.x.x.3으로 할당합니다.(물론 기존 서버와 자료가 같도록 동기화 되어 있어야 합니다.)


L4에 fail over기능을 이용 할 경우

128.x.x.1로 오는 모든 요청에 대해서 L4는 128.x.x.2가 응답하게 합니다.

그리고 128.x.x.2에 장애가 있을 경우(서버가 다운될 경우)에는 128.x.x.3서버가 자동으로 응답하게 처리하게 됩니다.


이렇게 미리 동일한 서버를 준비해 놓고 L4를 이용해서 fail over로 연결하면 첫번째 서버(마스터)에 장애가 있을 경우라도 미리 준비해 놓은 서버(슬래이브)가 동작하게 되므로

실제로 서비스에는 문제가 없게되는 것입니다.


Alteon L4 스위치 기본 설정방법


- Real 서버가 2대이고 1개의 그룹으로 설정, vitural 서버는 1개 사용
- metric(분산알고리즘) 미설정 시 default는 leastconnection
- health 체크 미설정 시 default는 tcp, inter=2(매 2초마다 체크), retry=4(4번 실패 체크 시 down으로 정의)
- DAM(Direct Access Mode)가 default로 disable (Real IP를 통한 직접 서비스 안됨)
※ 즉, 여기서는 Real IP를 이용한 http(80번 포트) 접속 안됨
(하지만 Load Balance와 무관한 서비스는 각각 가능: ssh, 터미널 접속,... 등)

Main#
Main# /cfg/l3 ; 스위치 IP 설정...
(또는 Main# /cfg/ip)
Layer 3# if 1 ; 스위치 자체 IP 설정...
IP Interface 1# addr 1.2.3.4 ; IP address 할당
IP Interface 1# mask 255.255.255.0 ; subnet mask 할당 (필요시)
IP Interface 1# ena ; IP address 활성화

IP Interface 1# /cfg/l3/gw ; default gateway 설정...
Enter default gateway number: (1-255) 1 [Enter] ; gateway 번호 입력 (필요시)
Default gateway 1# addr 1.2.3.1 ; default gateway 할당
Default gateway 1# ena ; gateway 활성화

Default gateway 1# /cfg/slb/real 1 ; 첫번째 real 서버 설정...
Real server 1# rip 1.2.3.5 ; real 서버 IP address 할당
Real server 1# ena ; 첫번째 real 서버 활성화

Real server 1# /cfg/slb/real 2 ; 두번째 real 서버 설정...
Real server 2# rip 1.2.3.6 ; real 서버 IP address 할당
Real server 2# ena ; 두번째 real 서버 활성화

Real server 2# /cfg/slb/group 1 ; real 서버 그룹 설정...
Real server group1# add 1 ; 등록된 real 서버 1번을 그룹에 추가
Real server group1# add 2 ; 등록된 real 서버 2번을 그룹에 추가

Real server group1# /cfg/slb/virt 1 ; virtual 서버 설정...
Virtual server 1# vip 1.2.3.2 ; virtual 서버 IP address 할당
Virtual server 1# ena ; virtual 서버 활성화
Virtual server 1# service http ; http 서비스 설정...
Virtual server 1 http Service# group 1 ; http 서비스를 real 서버 그룹에 할당
(필요시 Virtual server 1 http Service# rport 8080 ; http 서비스를 real 서버의 8080 포트에 매핑)

Virtual server 1# /cfg/slb/port 1 ; L4의 물리적인 포트 1번 설정...
SLB port 1# server ena ; 포트 1번을 서버 포트로 할당
SLB port 1# /cfg/slb/port 2 ; L4의 물리적인 포트 2번 설정...
SLB port 2# server ena ; 포트 2번을 서버 포트로 할당

SLB port 8# /cfg/slb/port 8 ; L4의 물리적인 포트 8번 설정...
SLB port 8# client ena ; 포트 8번을 클라이언트 포트로 할당

SLB port 8# /cfg/slb ; SLB 설정...
Layer 4# on ; Server Load Balancing 모드 On
Layer 4# apply ; 변경된 설정값 적용
Layer 4# cur ; 현재 설정값 확인
Layer 4# save ; FLASH 메모리에 현재 설정내용 저장
Layer 4# /info/slb/dump ; SLB 정보 확인


------------------------------------------------------
| ㅁ1 ㅁ2 ㅁ3 ㅁ4 ㅁ3 ㅁ4 ㅁ5 ㅁ6 ㅁ5 ㅁ6 ㅁ7 ㅁ8 | --> Alteon L4 스위치
--+---+--------------------------------------+--------
| | |
| | |--> 클라이언트 포트 (외부 연결)
| |
| |--> 서버 포트 (서버 연결)
|
|
|--> 서버 포트 (서버 연결)

사용자 삽입 이미지

※ 설정 시 port 9번은 미사용


//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////



L4/L7 스위치 개요 (로드밸런서)

from 이유있는 코드 2010/02/01 14:05

스위치의 분류 :

L2 : OSI 레이어 2에 속하는 MAC 어드레스를 참조하여 스위칭하는 장비


L3 : OSI 레이어 3에 속하는 IP주소를 참조하여 스위칭하는 장비


L4 : OSI 레이어 3~4에 속하는 IP 주소 및 TCP/UDP 포트 정보를 참조하여 스위칭하는 장비


L7 : OSI 레이어 3~7에 속하는 IP 주소, TCP/UDP 포트 정보 및 패킷 내용까지 참조하여 스위칭함





L4/L7 스위치의 용도 :


일반적으로 서버들의 로드밸런싱을 위해 사용됨


복수개의 웹서버가 있을 때, 임의의 웹서버에 접속을 시도하면, 스위치가 각 서버의 부하를 고려하여


적당한 서버와 연결시켜준다.


설정에 따라 순차적 연결 또는 접속이 가장 적은 서버에 연결하는 방식 등이 있다.



L4 스위치 :


Layer 4에서 패킷을 확인하고 세션을 관리하며, 로드밸런싱을 제공하는 스위치

TCP/UDP 패킷 정보를 분석해서 해당 패킷이 사용하는 서비스 종류 별로 처리(HTTP, FTP, SMTP...)

세션관리, 서버/방화벽 로드밸런싱, 네트워크 서비스 품질 보장


L7 스위치 :

L4 스위치의 서비스 단위 로드밸런싱을 극복하기 위해 포트 + 데이터 페이로드 패턴을 이용한 패킷 스위치

(e-mail 내용/제목, URL ...)

connection pooling(시스템 부하 감소), Traffic Compression (컨텐츠 압축 전송), 보안 기능


L4 vs L7 :
공통점 : 스위치로 들어온 패킷을 적절한 목적지로 전송해줌 (불필요한 패킷은 drop시킴)

차이점 : 
기능과 역할은 동일하나 패킷을 분석하는 인텔리전스가 다름

L7은 보안 기능 강화

(DOS/SYN 공격 방어, CodeRed/Nimda 등 감염 패킷 필터링, 네트워크 자원 독점 방지 등)

L7 스위치에 대한 오해 :
L7 스위치는 레이어 7 계층을 위한 스위치이다.

: 기본적으로 L2, L3 및 부분적으로 L4 스위치를 지원한다. 레이어5 세션 계층 위주이다.

L7 스위치는 URL 기반 스위치다.

: L7 스위치 기능에 대한 일부분을 말한 것이다.

L7 스위치는 모든 TCP/UDP 포트(0-65535)에 대한 인지가 가능하다.

: 알려진 일반 포트에 대한 세션처리는 가능하지만, 순간적으로 사용하는 임시 포트는 제한적이다.

sticky session :
L4 스위치를 통해 분배된 서비스 세션은 하나의 연결 요청에 1~n 중에 한 대의 서버에 분배된다.
여러 번 시도해도 그 때마다 1~n 중에 한 대에 분배되므로, 같은 서버에 접속될 확률은 1/n이 된다.
그러나 처음에 접속했던 서버와 같은 서버에 계속 연결시킬 수 있다.
바로 sticky 옵션이다.
(일반적인 상태)
사용자A -> L4 -> 1번서버
사용자A -> L4 -> 3번서버

(sticky 상태)
사용자A -> L4 -> 1번서버
사용자A -> L4 -> 1번서버

기존 사용자의 세션 상태를 timeout 시간 내에는 계속 유지시켜주는 것이 sticky session이다.

timeout 시간은 60분 이내로 조절 가능하다.
sticky session의 문제점 :

L4 스위치의 가장 큰 목적(?)인 로드밸런싱이 제대로 동작하지 않을 수 있다.
개별 사용자가 사용할 경우에는 세션 timeout이 있으므로 어느 정도 로드밸런싱을 충족시킨다.
하지만 프록시서버를 사용하는 경우 문제가 된다.
예를 들어 회사에서 외부로 나가는 경우 각 PC의 IP가 아니라 프록시서버의 IP를 달고 나간다.
여러 사람이 timeout 시간 내에 접속하는 경우, 계속해서 한 서버에만 로드가 집중된다.
(외부에서 보기에는 동일한 사람으로 보이므로)


대안 :

SSL이나 기타 다른 보안모듈을 이용해서 인증된 특정 사용자에 대해서 Cookie/DB에 기록 후
해당 사용자에 대해서만 세션을 유지하도록 한다. (단점 : performance 저하 및 기타 cost)
그래서 L7 스위치를 사용한다.

< L7 스위칭 방식 >

URL 스위칭 :

URL 주소에서 특정 String을 검사하고, 검색된 문자열을 기준으로 부하를 분산시키는 방식이다.
http://www.test.com/test.html 이라는 주소로 사용자들이 웹페이지를 요청한다.
해당 페이지는 이미지가 빈번히 변경되고, 이미지 크기도 크다. (전체적으로 로딩이 느리다)
이런 경우, client의 http request 내용에 html이 들어가면, 메인 웹서버로 전송하고..
해당 request에 jpg 등의 이미지를 요청하는 경우 이미지 웹서버로 분산할 수 있다.

Cookie 스위칭 :
Http header의 cookie 값에 따른 특정 String을 기준으로 부하를 분산하는 방식이다.
Cookie 값 필드를 보고 설정된 분류 기준에 따라 어느 서버로 보낼지 결정한다.


Content 스위칭 :
legacy한 L7 스위칭은 URL/Cookie 스위칭을 사용했으나,
최근 L7 스위칭은 Content 스위칭 방식을 이용한다.
기존에는 제한적인 기능, 즉 호스트네임, URL, Cookie 를 기준으로 로드밸런싱을 하였으나,
L7 content 스위칭은 추가적인 기능을 지원한다.
Http header 의 모든 필드를 기반으로 한다.
XML content를 기반으로 한다.
XML tags 나 multiple Http header를 기준으로 복잡한 로드밸런싱을 구현한다.
Cookie 와 http header의 insertion과 deletion을 포함한 contents-rewrite 기능을 지원한다.
alternate한 url이나 도메인의 redirecting request를 지원한다.

 


Posted by hoonihoon
2014. 1. 2. 16:31

* 네이버 블로그에 자바 빈즈에 대한 토론 내용이 있어 올립니다.

 
딱히 결론이 있는 내용은 아니지만 읽어볼만한 내용입니다.

개인적으로는 Map을 선호합니다.
 

1. 개발이 편하다. VO를 사용하면 클래스가 너무 많아집니다.

2. VO가 성능이 좋다고 하는데??

 - 과연그럴까요??
 - VO를 이용하려면 요즘 프레임워크들은 자동화를 위해 리플렉션을 사용하게 됩니다. 빠를까요?
   상황에 따라 다를것이니 검증은 본인이.. ^^ 
 

예를 들면 Request로 받은 값을 VO에 세팅하기위해 첫번째 리플렉션을 사용합니다.(날코딩이 아닌 잘 설계된 프레임워크 사용시)

ibatis를 거치며 쿼리를 날리기 위해 2번째 리플렉션을 사용합니다.

그리고 결과 데이터를 담기위해 3번째 리플렉션을 사용합니다.

또한 UI를 X-Internet등을 사용한다면 혹은 UI에 필요한 데이터 형식으로 변환되야 하는 경우

여기서 다시한번 4번째 리플렉션이 사용됩니다.

 

3. 자바빈즈가 표준이다?

 - 아래 내용을 읽어보면 알겠지만, 디펙토표준 정도로 여겨지는 것이 대세인듯합니다.

 - 또한 DTO로 Map도 이미 디펙토표준으로 여겨진다는...

 - 많은 Framework에서 Map을 DTO로 사용가능하게 되어있습니다.

 

* 만약 내가 프로젝트를 한다면

 - 순수 JSP라면 VO 사용을 한번 고려해 보겠습니다.

 - 그렇지 않다면 Map을 사용할것입니다.(자사의 LData는 Map 이죠)

 - 모델러와 의견 일치가 안된다면??? 아래 내용을 근거로 제시하고 다시한번 토론해 보시길...

 

 

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


자바빈즈에 대한 토론(강추!!) JAVA Family / Programming

2006/02/16 00:28

복사 http://blog.naver.com/emilio19/40022016140

제목 : beans에 대해...
글쓴이: 손님(guest) 2004/11/12 17:03:29 조회수:2232 줄수:17  

안녕하세요...^^
아직 내공이 많이 부족한 새끼 개발자입니다..
제가 현재 프로젝트를 수행 중인데요
beans의 정확한 개념을 알고 싶어서 이렇게 글을 드립니다.
제 생각에는 단순히 get,set을 포함한다구해서 bean이라고 생각하지 않습니다.
jsp와 bean을 사용한 프로젝트라 소개하려면 bean을 효율적으로 사용해야만 한다고
생각되기 때문입니다.
제가 생각하기에 get,set을 포함하는 것은 jsp에서 데이터를 효율적으로 넣고 빼기 
위해서라 생각했습니다. 즉 bean.getXXX()라는 식이 아닌 getProperty등의 태그를 
사용하여 데이터를 관리하는 것이지요...
위와 같은 의문을 가진 것은 제 옆자리에 있는 개발자가 꼭 get, set을 써야 하
냐구 물어보더라구요...
힘들게...
그러면서 자신은 변수 선언시 public으로 선언해서 사용했고 get, set은 안썼다구 
하면서 그걸 보고 다른 사람들도 자신과 동일한 방법으로 코딩을 하더라구 해서요..
그럼...좋은 답변 부탁드립니다...^^

제목 : Re: 지길건 지켜야죠 ㅎㅎ
글쓴이: 이희승(anoripi) 2004/11/15 00:55:23 조회수:530 줄수:20  

바로 퍼블릭 필드를 쓰는 것은 일단 자바빈즈 표준에 어긋납니다.  표준은 개발자들간의
약속이니 지켜야 한다고 생각합니다.  요즘은 자동 생성도 해주니 귀찮지도 않구요.

또 요즘 Byte Code Engineering 을 하는 라이브러리들이 많습니다.  즉 getter/setter
메소드가 호출 될 때 데코레이션을 해서 특정 오퍼레이선 (e.g. validation) 이 수행되
도록 한다는 이야기지요.  또 BCE 안한다 해도 밸리데이션이나, 프로퍼티 A 가 바뀌면
프로퍼티 B 가 바뀐다던지 하는 경우도 있고요.

get/setProperty(String propName [, Object value]) 를 이용한 빈은 보통
DynaBean 이라 부릅니다.  표준은 아니고 Commons-beanutils 에서 나온 용어입니다.
스트러츠에도 있죠?  나쁜 방법이라고 말할 수는 없겠지만 프로퍼티 명을 문자열로
줘야 하니 컴파일타임에서 제대로 컴파일된 코드가 런타임에서 철자가 틀린다던지
해서 오동작할 수 있는 문제가 있어서 저는 기피합니다.  한다면 인터페이스를 만들고
다이나믹프록시로 연결해 주겠습니다.  예전에 사용해 보았는데 괜찮더군요.

--
what we call human nature in actually is human habit.
--
http://gleamynode.net/

제목 : Re: 자바빈즈..
글쓴이: 박영록(poci) 2004/11/15 22:54:02 조회수:512 줄수:34  

자바빈즈는 표준이라기보다 관습이죠. 전 개인적으로 악습이라고까지 보고 있습니다.
private 필드와 public getter setter의 결합은 public 필드에 비해 훨씬 많은 코드를
필요로 하고 사용하기도 훨씬 불편하지만 이런 단점을 상쇄할 만한 장점을 제공하지 않습니다.
코드 자동 생성은 편리해보이지만 코드 자동 생성의 필요성이 느껴진다는 것은 디자인에
결함이 있다는 반증일수도 있습니다. http://c2.com/cgi/wiki?CodeGenerationIsaDesignSmell

좀더 실용적으로 생각할 필요가 있는 듯 합니다. 프로그래머가 코딩하면서 뭔가 불편함을
느낀다면 그것은 문제가 있다는 증거일 수 있습니다. iBatis, Spring Framework의 JdbcTemplate
등의 API가 점점 자바빈즈보다 Map에 대한 지원을 강화하고 있는 것도 beans의 불편함에
대해 느끼는 사람이 많기 때문입니다.

field encapsulation의 입장에서도 getter와 setter가 짝을 이루어 존재하는 것은 좋지
않습니다. setter로 해야하는 일이 있다면 생성자에서 하는 것이 좋죠. Data Transfer
Object로서의 자바빈즈라면 public field나 Map이 더 낫고 그 외의 경우라면 적절한
getter만 있는 immutable에 가까운 디자인이 더 낫다고 봅니다.

파이썬이나 그루비 등의 언어에는 public, private와 같은 접근 제한자가 없습니다.
객체의 필드는 직접 접근할 수도 있고 자바의 map과 유사한 방식으로 접근할 수도 있죠.
이 방식은 코딩 방식에 대단한 유연성을 가져다줍니다. field encapsulation을 강제해봐야
어차피 getter setter 주면 다 쓸 건데 굳이 문법으로 제약해봐야 실익이 없다는 생각인거죠.

다음 링크에서 이와 유사한 논의를 보실 수 있습니다.
http://c2.com/cgi/wiki?BeansConsideredHarmful

다음은 주로 setter에 대한 경계를 담고 있는 글입니다.
http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox-p2.html

덧붙여, jsp:setProperty, jsp:getProperty 등의 태그는 권장하지 않습니다. JSTL을
쓰시는 게 훨씬 더 편리하고 강력합니다. 빈즈도, 컬렉션도 다 지원합니다.

----
http://youngrok.com
NHN Corp. 웹플랫폼팀

제목 : Re: 자바빈즈..
글쓴이: 이희승(anoripi) 2004/11/16 08:53:37 조회수:270 줄수:37  

꼭 Setter 를 둘 필요는 없지 않나요?  자바 빈즈 스펙에서도 알 수 있지만 읽기 전용 
프로퍼티의 경우 setter 가 없습니다.

Map을 DTO로 이용할 경우 Java 5 의 generics 를 사용하지 않으면 validation 을 해야 하는 
문제도 있고요.  Map 의 key 또는 value 가 null 인 경우도 있을 수 있고, 만약 Java 5 에서
사용되지 않은 경우에는 프로젝트으 리스크만 높이는 결과를 가져옵니다.  차라리 annotation을
이용해 getter/setter 를 자동 생성하는 게 낫지 않나요?  groovy 도 그런 기능 제공한다고
하더군요.

그리고 주신 링크는 잘 읽어 보았습니다만.  c2.com 에서는 바로 퍼블릭 필드를 사용하는 것이
아니라 getter 및 setter 메소드를 거치고 있어 encapsulation 의 여지를 주고 있습니다.  
앨런 홀럽의 기사는 setter 를 단순히 나쁘다고 하는 것이 아니라, 이 프로퍼티한테 정말 setter
가 필요한지 잘 몰라서 무작정 setter 를 넣는 것에 대한 경계를 하라는 내용 같군요.  따라서
setter 가 나쁘다거나 퍼블릭 필드 액세스에 대한 옹호는 아니고, 따라서 적절한 부연은 아닌 것
같네요.

특히 setter 메소드가 없을 경우 bug tracability 가 현저히 떨어집니다.  setter 에서
null 을 체크한다던지 하지 않고 바로 필드를 설정하게 되면 버그가 발생하는 시점과 예외가
발생하는 시점에 차이가 발생하게 되어서 추적이 생각보다 훨씬 어려워질 수도 있습니다.  단순히
스택 트레이스만 보고 버그를 찾을 수 있느냐 디버거를 돌려야 되느냐의 차이는 잘 아시리라
봅니다.

코드를 생성하는 것이 오늘날에는 툴의 역할이지만, 앞으로는 그런 것들이 컴파일타임이나
런타임에 일어나게 될 것으로 생각됩니다.  따라서 코드 상에서는 objectA.name = "A"; 라는
코드가 실제 런타임에서는 objectA.setName("A"); 로 바뀌게 되고 자동 생성된 setter 코드에는
AOP 스타일로 annotation 된 validation 이나 기타 문장이 patch 되겠죠.  즉 groovy 등의 
언어에서의 = 연산자는 Java 에서처럼 단순한 대입문이 아니니 단순하게 비교하기는 힘들지
않을까 합니다.

현재 방금 말씀드린 기능이 완벽하면서도 편리하게 제공되고 있는 언어나 툴은 그다지 없는 것
같고, 다만 Java 5.0 이 발표되고 apt 라는 컴파일 툴이 함께 번들되면서 이에 대한 가능성은
한층 더 커졌다고 봅니다.
--
what we call human nature is actually human habit.
--
http://gleamynode.net/

제목 : Re: setter
글쓴이: 박영록(poci) 2004/11/16 12:53:53 조회수:154 줄수:53  

setter에 대한 링크는 제 주장에 대한 부연이라기보다 setter에 대한 경계를 담은
링크로 소개한 것입니다. 그리고 그 링크에서도 getter & setter가 많이 나타나는
경우의 디자인 문제에 대한 언급도 하고 있죠.

빈즈를 DTO로 이용할 경우는 setter를 둘 수 밖에 없습니다. 실제적으로 DTO는
객체 처음 생성할 때 단 한 번 setting이 일어남에도 불구하고 이 때 사용하기
위해 setter를 둘 수 밖에 없죠. 객체가 커지면 모든 값을 생성자에 넘길 수도
없으니까요. 결국 나중에는 써서는 안되는 setter가 처음 생성할 때 필요하다는
이유로 만들어지기 때문에 field encapsulation을 해치게 되죠. 이것이 빈즈가
field encapsulation을 위해 public field에 대비한 불편함을 감수하면서도
정작 field encapsulation은 제대로 달성하지 못하는 이유죠.

결국 DTO는 어차피 getter & setter가 다 필요하고 DTO는 성격상 필드 내용이
자주 바뀔 수 있습니다. 런타임에 동적으로 바뀔 가능성도 있구요. 이런 점을
고려한다면 단순 Map이 빈즈보다 효율성이 높죠. 게다가 DTO가 가장 많이 사용되는
영역인 데이터베이스에서 이미 많은 툴들이 빈즈보다 Map을 바라보고 있습니다.

null 처리나 부가적인 validation도 빈즈가 낫다고 할 수 없습니다. 오히려 이런
부분을 자동화하기는 Map이 훨씬 쉽습니다. 빈즈의 경우 getter나 setter에
일일이 코딩을 하고 만약 모든 필드를 다 검사해야하거나 내용을 로그로 찍고
싶다면 리플렉션을 써야하는데 Map은 훨씬 가볍게 처리할 수 있죠. Map을 상속해서
이런 것들이 자동으로 일어나게 할 수도 있구요.

bug tracablility가 떨어질 수 있다는 가능성이 있는 것은 맞습니다. 하지만,
우선 제 경험상으로는 map으로 인해 버그 추적이 힘들어지는 경우는 거의 없었습니다.
그리고 사실 이런 문제의 추적은 테스트로 충분히 커버가 가능합니다. 실제로
map으로 인한 유연성과 생산성 증가를 비교해본다면 이 부분의 단점은 그리
중요한 문제가 아니라고 봅니다.

코드 생성이 컴파일 타임이나 런타임에서 지원된다면 부가적인 툴을 쓰는 것보다
분명 훨씬 좋겠죠. 그러나, 여전히 자동으로 생성할 수 있는 코드라면 왜
일부러 생성해야하는가 하는 고민은 해야할 것입니다.

BeansConsideredHarmful의 논의를 어떻게 보셨는지 모르겠습니다만, 거기에는
public field에 비해 빈즈가 나은 점이 별로 없다는 의견이 많죠. 이것이
public field를 쓰자는 이야기라기보다는 빈즈가 별달리 장점이 없다는 뜻으로
받아들이는 것이 좋을 듯 합니다.

저 개인적으로는 public field를 쓰는 것도 좋다고 봅니다. 예를 든 파이썬처럼
접근 제한은 걸어서 억지로 막는 것보다 API 문서, 좋은 클래스 디자인을 통해
자연스럽게 access violation이 일어나지 않게 하는 것이 좋다고 생각합니다.

전 요즘은 DTO는 거의 항상 Map을 사용하고 그 외의 경우는 setter 없이 생성자에서
파라미터를 받고 꼭 필요한 부분만 getter를 두고 있습니다. 단순히 필드 멤버를
리턴만 하는 getter도 가급적 안 만들려고 하고 있죠.

어쨋거나 개개인이 판단은 다 다를 수 있겠습니다만, 자바 빈즈가 널리 쓰인다는
이유로 그냥 받아들이기에는 해로움이 적지 않으므로 다시 한 번 검토해보는
시간이 필요할 것입니다.
----
http://youngrok.com
NHN Corp. 웹플랫폼팀

제목 : Re: setter
글쓴이: 이희승(anoripi) 2004/11/16 13:17:31 조회수:236 줄수:38  

후반부에 말씀드렸듯 언어나 툴의 지원이 있다면 내부에 getter/setter 가 쓰이든 어떻든
사실은 중요한 것이 아니겠죠.  내부적으로 언어의 요소가 어떻게 구현이 되느냐는 어떻게
보면 나중의 문제니까요.

안타까운 것은 현재 그런 것이 지원되지 않는다는 것이고, 그를 어떻게 해결하느냐의 문제인데..
사실 빈즈의 방식이 100% 옳은 것이 아니라 사실상의 표준이라는 것이죠.

bug tracability 에 대해 말씀드리면.. 저 같은 경우 웹 어플리케이션 개발보다는 서버측
개발을 많이 해서 그런건지는 모르겠지만 그런 문제가 중요하게 느껴지더군요.  예를 들면,
NullPointerException은 겉에 보이는 현상이고, 어느 필드가 null 인지는 또 다른 문제죠:

String foo(Bar bar) {
 return bar.a.length() + bar.b.length();
}

라는 코드가 있다 했을 때 해당 라인에서 NPE 가 발생했을 경우 a 가 null 인지 b 가 null 인지 
모호한 부분이 있습니다.  물론 라인을 나눠 쓰면 되기도 하겠지만 매번 고려하기도 힘들고,
null 일 경우에 대한 특화된 처리를 a 와 b 에 접근하는 다른 부분에서도 항상 해 준다면 비효율
적이기도 하구요.  이것은 매우 간단한 예이고, 여러 레이어로 이루어진 서버 어플리케이션의
경우 그 효과가 2 레이어 뒤 (심지어는 다른 머신)에 나타난다던지 하여 골치가 아플 때가
있습니다.

하지만 만약 setter 에서 set 하는 녀석이 null 일때 NPE 를 던지거나, 이를 빈 문자열로 
자동 치환한다면 일이 훨씬 수월해 집니다.  생성자이든 setter이든 어디에선가는 가능한 한 
조기에 문제가 생겼을 경우 이를 해결하거나 알려야 코드의 리스크가 감소될것이라는게 제
생각입니다.

setter 와 getter 가 번거롭고 비효율적인 면이 있는 것은 맞지만 아예 불필요한 것은 아니라는
것이죠.  영록님과 그렇게 큰 견해 차이가 있는 것은 아닙니다.  개체가 immutable 이라면
당연히 Constructor 를 이용한 초기화를 선호하고, 파라메터가 많을 경우 좀더 다양한 타입을
만들어 파라메터 수를 줄입니다.  다만 저는 setter 를 써야 할 경우 de facto standard를
약간 보수적으로 따르는 면이 있다고 봐야 겠죠?

--
what we call human nature in actually is human habit.
--
http://gleamynode.net/

제목 : Re: 그 부분은 해결책이 있습니다.
글쓴이: 박영록(poci) 2004/11/16 14:18:59 조회수:193 줄수:41  

getter 메쏘드를 이용할 경우 필드별로 부가적인 작업이 요구될 경우 처리하기가
쉽다는 장점이 있는 것은 사실입니다. 그러나, 그 부가적인 작업들이 대체로
validation, null 처리, 타입 변환 등임을 감안해본다면 오히려 Map을 쓰는 것이
더 편리할 수가 있습니다. Map을 상속해서 get을 오버라이드해서 get(key, defaultValue)와
같은 방식으로 사용하게 할 수도 있고, XML 설정이나 클래스 내부의 약간의 코드를
통해서 validation을 편하게 할 수도 있습니다. 일반적인 DTO라면 이런 문제에서도
Map이 빈즈보다 낫다고 할 수 있습니다. 예의 그 코드는 이렇게 바꿀 수 있겠죠.

int foo(MapWrapper bar) {
 return bar.get("a", "").length() + bar.get("b", "").length();
}

get(key)는 get(key, "")를 자동으로 실행한다든지 할 수도 있겠죠.
set을 오버라이드해서 기본적인 validation을 수행하게 할 수도 있을 꺼구요.
업무 영역이 늘어날수록 매번 빈즈 클래스를 만드는 것보다 이런 방식이 더
생산적일 겁니다.

그리고 사실 빈즈가 관례이긴 하나, DTO에 있어서는 Map 역시 마찬가지입니다.
현재 추세로는 분명히 DTO로 Map을 사용하는 라이브러리들이 늘어가고 빈즈를
사용하는 것은 줄고 있습니다.

그러나, 웹보다 일반 서버 개발을 많이 하신다면 아마도 단순한 DTO보다는
기능이 풍부한 도메인 오브젝트가 더 필요한 상황일 것입니다. 이런 경우는 많은
프로퍼티들의 처리를 위해 getter & setter가 유용하게 쓰일 수 있을 것입니다.
그러나, 이런 도메인 오브젝트 역시 Map을 상속하거나, wrapping해서 만들 경우
단순 프로퍼티들의 처리를 상당히 편리하게 할 수 있습니다. 객체의 프로퍼티는
모두 내부 Map에 담고 이를 get, set 하는 것은 단순 프로퍼티는 Map의 인터페이스를
그대로 사용하고 중간 처리가 필요한 경우는 부가적인 getter, setter를 만드는
식의 조합이 가능하죠. 저 역시 getter & setter가 적게 쓸수록 좋다고는 생각하지만
완전히 없어져야할 것이라고까지는 생각지 않습니다. 자바의 특성상 완전히
없앨 수는 없기도 하구요.

코드 생성이 언어 차원에서 지원되어서 코드 생성인지 전혀 모르고 사용할 수
있다면 그것은 저도 좋다고 봅니다. 다만 현재 AspectJ와 같은 방식은 약간은
냄새가 남아 있는 것이 아닌가 싶네요. 그래서 이런 면에서 고민할 필요가 없는
파이썬에 점점 끌리는 건가 봅니다.

----
http://youngrok.com
NHN Corp. 웹플랫폼팀

제목 : Re: JavaBeans의 기본 목적은?
글쓴이: 사랑전쟁(lovewar) 2004/11/16 20:19:32 조회수:224 줄수:26  

JavaBeans의 스펙을 보면 "Software component model을 정의하는 것이다."
라고 되어 있습니다.

그래서, JSP와 JavaBeans간의 연관고리를 다음과 같이 해석할 수 있습니다.

 "JSP는 변경되지 않는다. 다만 JavaBeans가 다른 JavaBeans로 변경될 수 있다."

즉, View 단과 Model 단을 각각 원하는 것으로 변경할 수 있다는 사상입니다.

그래서 되도록 JavaBeans의 형태를 따른다면, 차후에 JavaBeans만을 다른 회사의 
JavaBeans으로 교체할 수 있다는 것 입니다.(현재의 SI환경에서는 거의 전무하지 않을까 
생각합니다.)

모회사의 제품중에 Component를 끼워놓을 수 있게끔, 광고에 나오는 것을 봐서는
아마도 Component쪽으로 가는 방향에서는 JSP와 JavaBeans의 기본 사상을 지키는 것이 좋을 것으로
봅니다.

단순하게 Object의 개념으로 코딩을 한다면, 구지 JavaBeans의 규약을 지킬 필요는 없습니다.

-- 덧붙이는 글 --
여기서 빈즈란 개념은 JavaBeans 또는 Enterprise JavaBeans의 개념으로 보시면 됩니다.

빈즈의 규약은 다음 사이트에서 찾을 수 있습니다.
http://java.sun.com/products/javabeans/downloads/index.html

제목 : Re: 필요한곳에 쓰십시요.....
글쓴이: 이규주(29zu) 2004/11/16 23:56:25 조회수:98 줄수:13  

웹플밍에서 데이터성 클래스등의 필드에 대한접근을 getter setter로해봤자..
개발시간만 늦어진다고 생각합니다...

일단 이런 클래스는 재활용같은건 기대도 할수없으며 getter setter통해서 접근할
이유도 별로 없습니다...단순히 화면에 한번뿌리는 역할등인데..굳이 공들여
메소드를 만들 이유는 없는거지요..

저같은경우 이런 일회성(?) 에 가까운 기능을 하는 클래스들의 필드는 상당수
public로 처리하고있구요...

공통컴퍼넌트와같이 외부의 다른사람도 쓸지모르는 클래스의 경우엔..
필드접근을 setter/getter를 통해서 하게합니다....

제목 : Re: 필요한 곳에서만 getter/setter를 사용하는 것이 좋겠죠
글쓴이: 윤남영(skywatch) 2004/11/17 01:35:49 조회수:195 줄수:53  

저 역시 getter/setter는 필요한 곳에서만 사용을 하는 것이 좋다고 생각을 합니다.
요즘은 보통 빈즈라고 얘기하면 범위가 넓게 얘기를 하기 때문에 (보통 일반 클래스들도
빈즈라고 칭하는 경우가 많더군요...저도 종종 그런 경우에 당황이 되더군요...)
조금 범위를 구분을 지어 보면 DTO나 Value Object 등의 경우에는 저는 getter/setter를 거의
사용하지 않습니다. 그리고 이와는 조금 다른 의미인 비즈니스 로직을 담는 자바빈즈나
EJB의 경우에는 getter/setter를 반드시 사용을 합니다.

VO의 경우에는 보통 특정 데이터 구조를 나타내는 것이기 때문에 굳이 객체지향의
Encapsulation이나 Information Hiding의 특성을 나타낼 필요는 없다는 생각입니다.
물론 특정 값에 대한 검사의 문제 및 어떤 값이 설정이 될 경우에 자동으로 어떤 로직을
담아야 하는 경우도 생길 수 있는데 이럴 경우에는 조금은 넓은 의미의 getter/setter를 
사용하기는 합니다. 머 예를 들면 여러개의 attribute의 값을 조합해서 특정한 값을 
자동으로 만들어 내야 하는 경우 등에 getter를 사용을 합니다.(^^;; 엄밀히 말해서 이러한
기능을 하는 메소드를 단순히 getter라고 할 수 있을지는 조금 애매한 것 같습니다. 보통
getter라고 얘기를 하면 특정 attribute의 값을 리턴하는 경우를 말하는 것으로 대부분
생각하고 있기 때문에 그래서 일단은 넓은 의미에서의 getter라고 얘기를 했습니다.)

개발에서 이런 식으로 public 필드를 가진 VO를 사용할 경우에는 얘기가 나올 수 있는 부분이
로직의 변경에 대한 부분일 것 같습니다. 그렇지만 실제로 VO가 변경이 되어야 하는 경우에는
해당 VO를 사용하는 JSP 및 비즈니스 로직을 담고 있는 클래스 역시 같이 변경되어야 하는 것이 
보통이겠죠. 예를 들어 특정 데이터 항목이 추가가 된 경우에는 당연히 DAO 및 Entity Beans
역시 변경이 되어야 할 것입니다. 그래서 이러한 데이터나 로직의 변경은 필연적으로 관련
부분의 변경을 보통은 가져오기 때문에 getter/setter를 사용하는 경우와 큰 차이가 없어
보입니다.

그리고 VO의 필드 값에 대한 에러 처리 및 데이터 처리 룰은 VO 보다는 비즈니스 로직을 담고
있는 클래스나 Session Beans 등에서 처리를 해주어야 하는 부분이기 때문에 그러한 부분에
대해서도 역시 public 필드를 가진 VO를 사용하는 것에 대한 부담은 없는 것 같습니다.

흠... 한가지 더 얘기를 하면 컴포넌트화나 모듈화를 할때 이와 같이 public 필드를 접근할 수
있도록 한다면 문제가 생길 수는 있을 것입니다. 대표적으로 동일 컴포넌트의 이전 버전과의
호환성과 같은 문제가 생길 수 있겠죠. 그렇지만 컴포넌트나 특정 비즈니스 로직을 가진
클래스의 내부적인 부분의 변경은 보통 외부적인 변경을 가져오는 것 같습니다. 특히 VO가
변경이 되어야 하는 경우가 있다면 해당 도메인 모델에 변경이 있는 경우가 될 것입니다.
즉 데이터를 가져오는 부분이나 저장하는 부분 등이 변경이 되어야 하는 경우겠죠. 이러한
경우에는 어짜피 기존 컴포넌트와는 달라지기 때문에 조금 다른 데이터/비즈니스 로직을
가지는 새로운 컴포넌트로 보는 것이 좋을 것 같습니다. 그래서 이러한 경우는 기존의
클래스를 확장(extend)하거나 새로 컴포넌트를 만들어서 기존의 컴포넌트를 참조?? 
(association즉... 가져가 사용하는 것을 말합니다..^^;; 마땅한 어휘가 생각이 안나네요.)하는
형식으로 구현을 할 수 밖에 없겠죠.

머... 개인적으로 public field를 주로 사용하고 있기 때문에... 간단히 변명?? 을 해 봤습니다.
제가 쓴 VO에 대한 내용에 조금 한정을 지어 보면... 제가 얘기한 VO는 주로 웹개발 쪽에서의
방법에 어울릴지도 모르겠습니다. 서버쪽이나 프레임워크 쪽의 개발에서는 실제로 단순한 VO는
거의 사용이 되지 않으니까요. ^^;; 그러고 보면 조금의 얘기의 주제에서 벗어난 얘기가 된 것
같습니다. 맨처음의 질문이 Beans에 대한 것이다 보니까...아무래도 사랑전쟁님이 말씀하신 
JavaBean 또는 Enterprise Java Bean의 개념으로 보면 비즈니스 로직을 주로 담고 있어야 하기
때문에 getter/setter는 필수적인 요소 겠지요..

ㅎㅎㅎ 글을 써놓고 보니까... 왠지 예날 얘기의 "이것도 옳다, 저것도 옳다" 라는 글을 쓴 것
같습니다.

제목 : Re: 또 배가 산으로 가는군요
글쓴이: 손님(guest) 2004/11/23 16:42:11 조회수:569 줄수:33  

또 배가 산으로 가는군요.

JavaBean는 선에서 내놓은 Component Spec. 이름입니다.
ActiveX는 MS에서 내놓은 Compnent Spec.을 구현한 제품 이름입니다.

습관적으로 get/set name convension을 쓰는것이 아니라 Spec. 이기때문에 쓰는겁니다.

setter가 좋지않다고 말을 하는 이유는 Thread Safe 문제 때문이고 적절한 sync를 고려
하면 나쁜것은 아닙니다.

get/set method를 이용해서 property에 접근을 한다는것 자체가 JavaBean이란 뜻입니다.
여기에 많은 수식어가 붙죠?
캡슐화, BlackBox, Interface.. 

Object가 메소드/프로퍼티/이벤트 의 특성을 만족하면 자바빈즈라고 불릴 수 있습니다.

놀랍습니다. 자바빈즈를 표준이 아니라고 하는 사람이 있다니요!! 게다가

자바빈즈를 표준이 아니라 '악습'이라고 말한 사람이 있는데...

사람이 무식하면 용감하다는 말이 다시한번 떠오릅니다.

왜 책에 "javabean을 이용한.."이란 말이 나오는지 한번 생각해 보십시요.
폼생폼사때문에 쓰는 말이 아닙니다.

질문하신분..

옆자리에 있는 사람에게 될 수 있는대로 get/set을 써라고 말씀해 주시고property는 
꼭 private 혹은 protected로 붙이는 습관을 들이라고 말씀해 주세요..

몇글자 더 치는게 그렇게 힘듭니까? 


제목 : Re: 저는 배가 맞게 간거 같은데..
글쓴이: 서민구(guest) 2004/11/23 20:26:48 조회수:174 줄수:29  

그래서 이런말이 있죠..
"악화가 양화를 구축한다"고요..

단지 스펙이라는 논리만으로 자바빈즈의 setter/getter를
사용해야한다면, 오늘 우리는 스펙이라는 이유만으로 ejb의
모든 퍼시스턴스 레이어는 항상 cmp로 작성해야하게요...?
그리고 tcp/ip는 갈아엎고 깨끗한 osi 7 layer에 맞게 
새로 만들어야겠네요..

전 윗 글들을 따라가서 읽다보니, 분명 자바에서는 메타 정보를
표현하는데 있어서 부족함이 있는건 사실이라는 생각이 드는데요..

닷넷하고 비교해보아도 쉽게 알 수 있는데..
닷넷에서는 property라는 개념을 사용해서,
그 필드가 public 필드인지 아니면 프로퍼티인지 
클라이언트 입장에서는 모르는 상태에서 접근이 가능하죠...

캡슐화, 블랙박스, 인터페이스와 같은 단어에는 또 이런 응수가
가능하죠.. 'software architecture는 another indirection만
있으면 만사가 해결될거라고 착각하는 사람들의 작품이다'라고요..
setter가 좋지 않은 건 thread safety때문이라니, 그 이유가
정말 궁금하군요...

몇글자 더 치는 귀찮음증이라.. 아마 그런 귀찮음증이 없었다면
사회의 발전이 없었을걸요? 걷기 싫어서 차를 만들고, 차타는것도
너무 오래걸리는게 싫어서 기차를 만들고, 비행기를 만들고.
직접 가서 이야기하는게 힘드니까 전화를 만들고.
인류역사가 이렇게 발전한걸 왜 모른척 하시려는지.

제목 : Re: 입장을 바꾸면...
글쓴이: 박찬우(nucha) 2004/11/24 01:00:49 조회수:133 줄수:27  

여러분이 컴포넌트 표준을 만든다고 생각해보세요.
단순히 사용하는 입장이 아닌 만드는 입장에서...

결국 SUN의 입장도 이해가 갈 것입니다.
어느 누군가의 불만을 해결하면 다시 다른 누군가의 불만이 또 나올 것이므로...

그런데 데이타 전송 객체는 자바 빈 수준의 표준을 지키면서 만들수도 있고
public 필드들로만 구성되게 해서 작성할 수도 있습니다.

필요하다면 데이터와 서버로 전달되면 그 데이터로 뭘 할지 
로직까지 구현해서 전달할 수도 있습니다.

다 구현하기 나름이지요.

물론 Map을 이용한 데이타 전송 객체도 그 한가지 방법입니다.
그 것은 선택의 문제일 뿐입니다.
맘에 안들면 안쓰면 되는 것이지요.

왜냐하면 제각각 장단점을 가지고 있어서
자신에게 맞고 편리한 것을 선택하면 그 것이 자신에겐 최선의 선택인 것입니다.

그렇다고 자신이 선택하지 않은 다른 것을 나쁘다고만 할 수는 없는 것이지요.

ps: 
그런데 Map을 상속받아 구현하는 것보다 위임으로 작성하는게 좋을텐데요.
사용하는 구체적 Map이 무엇이든 간에...

제목 : Re: JavaBeans의 뒤틀림
글쓴이: 이원영(javaservice) 2004/11/24 03:53:04 조회수:554 줄수:35  

조금 위로 거슬로 올라가서, 처음 "JavaBeans"가 대두되었을 때, 원래의 그 취지를
되짚어 봤으면 합니다. 98년도에 제가 작성한 아래의 첨부파일이, 지금의 논란에 바람직한
방향으로의 이해에 도움이 되었으면 합니다.
첨부: JavaBean_전략보고서.doc (잠깐 둘러보시죠..)

사랑전쟁님이 미리 언급하신 JavaBeans의 규약에도 보면,
http://java.sun.com/products/javabeans/downloads/index.html

 ...that allow for the visual construction of applications

이라 되어 있어요. 이것이 서버측의 EJB모델로 이어지고, JSP에서 JavaBeans가 활용되고,
지금 이 쓰레드에서 일파만파 이어지고 있는 Server-side programming model의 얘기로
전해 내려오고 있습니다.

제 생각은 JavaBeans는 "Visual construction"를 위한 기가막힌 이상적 모델이었습니다.
단지 CBD(Component-Based Development)가 생각만큼 현실화되지 못했고, Visual Cafe,
JBuilder, ViualAge for Java/WSAD/Eclipse 등의 IDE Tool들이 Visual Construction-Based
Component를 양산할 것으로 기대되었으나, 현실적으로 그러하질 못했고, 결국 이름만
JavaBeans로 덩그러니 남아 있는 형국으로 보입니다. 안타깝죠.

server-side에서의 JavaBeans활용은 그 효용성과 가치를 부단히 찾아가려 노력했지만, 
저를 포함해 많은 분들이 이미 그다지 높은 점수를 주고 있는 것 같지는 않네요.

3박자가 모두 맞아떨어졌어야 했습니다. 

 1) Visual Construction기반 개발 대중화
 2) 다양한 Visual Component의 생산 및 판매(그러한 전문업체의 성장)
 3) CBD 애초 의도대로의 실질적인 발전

이 3가지가 90년대 말에 추정했듯이 예상대로 진행만 되어 졌더라면, 그 중심에는
JavaBeans가 있었을 거예요. 그러나 현실은 그렇지 못하고, setter와 getter를 개발자가
코딩하고, 그것의 이용도 개발자의 editor에서 코딩되니, 그 가치와 의미를 이미 상실한
것이라 봐요.

자바서비스넷 이원영

Download JavaBean_전략보고서.doc (830976 Bytes) JavaBean_전략보고서.doc (830976 Bytes)

제목 : Re: JavaBeans
글쓴이: 서민구(guest) 2004/11/24 09:08:16 조회수:134 줄수:25  

죄송합니다. 앞서 글에서 제가 사실 '손님'님의 글에 흥분한 나머지 삐딱하게 답을
달았습니다.

제 생각을 좀 더 명확히 하자면,
(1) VO에서 Map 등의 사용이 편한 것은 사실이고, 단순 public field 가 편한 것도 사실.

    더구나 만능 VO를 만들 목적이 있다면 Map이 유리한 것도 사실.
    예를 들자면, select 해온 모든 필드를 키로 갖도록 동적으로 Map을 만들어
    반환한다든가..

(2) 하지만 역시 표준이 아닌 건 사실.. 이로 인해 모두가 합의하는 필드 값에
    대한 validation 방식이 Map에 대해 없죠. 물론 프로젝트나 팀이나 회사 단위로
    이에 대한 표준화가 이루어진다면 얼마든지 Map을 써도 상관없겠지만,
    모두가 합의하는 방식이 되기는 힘들단 거죠..

getter/setter보다 더 나은 대안이 나오기 힘들기는 하지만, Map을 사용하되
여러가지 사항을 잘 고려하면 (가령 키를 조작하지 못하게 반환하거나 값을
할당할 때 값의 validatin을 해줄 수 있게 하거나) 코드가 더 나아질 수 있다는
생각이 드네요...

하지만 표준이 아니라는 이유만으로 다른 방향으로의 생각이나 발전을 거부한다면, 
스트러츠 같은 프레임웍이나 자바 세계의 다양한 퍼시스턴스 레이어(얼마나 많은지 
이젠 일일히 공부할 수가 없죠)나, GNU GPL 내의 다양한 프로젝트들은 있을 수 
없었을지도 모르죠.

제목 : Re: 머 그런걸로..
글쓴이: 손님(guest) 2004/11/24 17:03:13 조회수:148 줄수:20  

머 답글보고 삐딱하게 반응까지야..

JavaBeans 자체를 데이터 Container 역활로 한정시키니까 Map이니 getter/setter 니 뭐니 
그런 말들이 난무하는겁니다.
그런 용도로 쓸려면 Thread-safe한 Collection들 많이 있으니까 걍 그것 쓰면 되구요..


JavaBeans가 현재 가치와 의미를 상실했다는 말은 3rd party 개발자로서 동의할 수 
없습니다.
(사실 코어클래스들은 모두 빈즈라고 할 수 있기때문에 JavaBean란 말이 쉽게 쓰입니다)

말만 앞세우는 개발자는 믿지 않은지 오래됐기땜에..

앞으로 증명해 보이겠습니다..

P.S.
JavaBeans 정의 자체에 'Visual' 이란 말이 들어가는 바람에 개념에 상당히 혼란을 주는
점은 역시 초창기 server-side를 의식하지 않은 때문으로 보입니다.
뒤에 Non-Visual이란 말이 나오지만 이건 상당한 불만입니다.

제목 : Re: JavaBeans의 불투명한 방향성
글쓴이: 이원영(javaservice) 2004/11/24 19:13:58 조회수:386 줄수:36  

"코어클래스들은 모두 빈즈"라는 행간의 의미는 임의의 클래스는 Beans의 instantiate()라는
메소드를 통해 "JavaBeans화" 될 수 있다는 뜻입니다.
예를 들면, JSP에서 <jsp:useBeans ...> 라고 했을 때, precompiled된 java 소스를 보면,
Beans.instantiate(...) 를 통해 해당 클래스가 JavaBeans의 특성을 모두 갖는 Beans로
instance화 되는 것이지요.
http://www.javaservice.net/~java/docs/j2sdk_1.3.1/api/java/beans/Beans.html

JavaBeans에 관한 김세종님의 (오래된)강좌도 읽어봄직하지 않나요?
http://www.javaservice.net/~java/bbs/search.cgi?m=resource&b=applet&p=0&c=search&k=...

아시다시피 자바빈즈는 Delegation Event Model, Property, Introspection, Persistency, 
core Reflection, Customization 등의 특성을 갖고 있습니다.

그러나, 우린 지금 다소 "Property"라는 속성만 놓고 JavaBeans에 대한 얘기를 끌어오고
있는 듯 해요. 그러나, 위에 나열된 JavaBeans의 상당부분은 "Visual construction"를
위한 것이었다는 것을 강조하고 싶고, "Visual"을 뺀 non-visul JavaBeans는 그러한 관점에서
(다소) 의미를 상실했다는 것이지요.

Server-side에서의 JavaBeans활용은 분명 가치가 있을 겁니다. 그러나, 그 장점이 극대화
되기 위해선 IDE Tool에서 Visual Construction 개발방법이 가능해져야 했던 것 아니냐라는
것이지요.

저역시 editor를 이용한 코딩시에 Entity-Object에서 setter/getter를 굳이 만들 필요가
없다고 보여지며, (역설적으로) reflection 기능을 이용하여 public field의 setting/getting이
(경우에 따라!) 보다 생산적이더군요. 심지어 JSP에서 <jsp:useBeans ...> tag를
써야할 이유를 찾지 못합니다. 그러한 코드가 IDE Tool에 의해 Component-Based Drag&Drop으로
자동생성되는 것일 때, 의미를 갖는 것 아닐까요.

PS: 98년도엔, "JavaBeans와 EJB(Enterprise JavaBeans)는 이름만 Beans이지 전혀 다른
것입니다"라고 했는데, 이젠 다들 광의의 관점에서 "유사한 것입니다"라고 여겨지나봐요.

NOTE: "JavaBeans의 방향성"이나, server-side programming시에 JavaBeans 속성 중 어떤
 속성은 어느 부분에서 매우 활용가치가 높다, 혹은 server-side component의 visual
 conctruction 개발 방향이 어디로 흐르고 있다, 등에 대해 말씀해 주시면 감사하겠습니다.

자바서비스넷 이원영

제목 : Re: JavaBeans와 표준..
글쓴이: 박영록(poci) 2004/11/24 20:56:29 조회수:412 줄수:43  

JavaBeans를 표준이라고 말하기에는 다소 어폐가 있습니다. JavaBeans 스펙은
beans를 다루는 API에 대한 것이지 어떻게 클래스를 코딩할 것인가에 대한 표준은
아닙니다. 프로퍼티들을 public field로 쓰거나 Map으로 관리한다고해서 이것이
비표준인 것은 아닙니다. 그보다는 일반적으로 객체의 프로퍼티를 자바빈즈 스타일로
관리한다는 점에서 이희승님의 말씀처럼 de facto standard라고 보는 게 맞겠죠.

그리고, 이런 시각에서 본다면 최소한 DTO의 영역에서는 Map 역시 de facto standard가
되어가고 있습니다. iBatis, Spring DAO, commons-dbutils 등의 JDBC 래퍼들이
이런 경향을 반영하고 있고 JSTL의 EL 역시 마찬가지입니다.

자바빈즈가 처음에는 visual component를 목표로 출발한 것은 사실입니다만
자바빈즈의 특징들이란 게 사실 빈즈로 코딩된 클래스 자체가 가지는 특징은
getter/setter 밖에 없습니다. 그 외에는 빈즈의 특징이 아니라 빈즈를 지원하는
API들의 특징이죠. 요즈음 일반적으로 사용하는 빈즈의 의미는 이런 프로퍼티
관리 이상의 의미를 크게 담고 있지 않습니다. XMLBeans, commons-beanutils,
스트러츠의 FormBean 등에서 사용하는 beans의 의미는 프로퍼티 관리를 getter/
setter로 한다는 정도의 의미로 사용되고 있죠. 그렇다고 이것이 beans는 모두
단순 getter/setter만 가진 DTO를 의미하느냐하면 그건 아닙니다. full-featured
object이더라도 자신의 프로퍼티를 getter/setter로 관리한다는 것 뿐이죠.

사실 이런 게 논란이 되는 이유는 자바이기 때문일 수 있습니다. getter/setter
방식이 단점이 많음에도 불구하고 쓰일 수 밖에 없는 것은 Map이나 public field가
가지기 힘든 장점, 프로퍼티 접근 과정에서 부가적인 프로세스를 수행할 수 있다는
점 때문이죠. 이런 점은 사실 프로퍼티라는 개념을 별도로 지원하는 언어들에서는
고민할 필요가 없는데 자바이기 때문에 고민할 수 밖에 없는 것 같습니다.


p.s. component의 visual construction은 원래 자바빈즈의 목적이긴 하지만
요즘 통용되는 의미의 자바빈즈와는 거리가 있고 자바빈즈에만 연관시켜서
이야기하기엔 조금 큰 주제인 듯 합니다. 많은 사람들이 관심 갖고 있는
주제이기도 하니 새로 쓰레드를 열어보는 것은 어떨까요?

----
http://youngrok.com
NHN Corp. 웹플랫폼팀

 


-------------------------------------------------------
게시판관리자주: Visual construction 이슈는 아래의 스레드로 분리하여 이어집니다.
332 Visual component 와 Visual construction 은 다른거 아닐까요 
http://www.javaservice.net/~java/bbs/read.cgi?m=resource&b=discussion&c=r_p&n=1101340367

제목 : Re: 오호....
글쓴이: 손님(guest) 2004/11/26 23:12:17 조회수:285 줄수:61  

JavaBeans는 de facto standard가 아니라 standard입니다.
getter/setter는 전혀 중요한 문제가 아닌데 이렇게 강조하는 이유를 모르겠습니다.
(Object 멋대로 만들어서 걍 쓰세요.. 아무 문제없습니다.)

API란 말의 의미는 '이런 Spec.을 만족하는 뭔가를 만들려면 이렇게 해라' 라고 하는 표준
입니다. API의 I는 Interface란걸 명심하십시요.
이말은 곧 'Java 프로그램을 만들려면 이걸 이용해서 이렇게 해라..' 란 뜻올시다..
(이런것까지 설명을 해줘야 합니까?)

System.out.println("hello?");

hello? 란 말을 console에 뿌릴려면 out 즉, java.io.PrintStream이란 Interface를 이용하란
말입니다. 댁이 그래픽 디바이스 API를 얻어서 뿌리실려우?
그 많은 그래픽 카드 벤더들 API들 다 연구해서?

도대체 standard를 무의식중에 이용하면서 de facto라니요..

이야기가 잠시 샜는데.. 위에도 이야기했지만 getter/setter는 전혀 중요한게 아닙니다.
아... 개인적으로 reflection보다는 interface를 좋아합니다. 취향문제겠지요..

제가 이야기하고 싶은것은..
사람들이 왜 EJB하면 Business Logic을 떠올리면서 JavaBeans를 이야기하면 단순한 데이터
저장소를 떠올리냐는 것입니다.
(EJB와 JavaBeans는 완전히 틀립니다. Spec.이 틀리지않습니까?)
(사실 EJB로 99년도에 사업화를 생각했었지요.. 50Kbyte 하나 deploy시키는데 1000만원
듭디다.. 젠장..)

JavaBeans 역시 거대한 Business Logic 을 가진 객체덩어리입니다.
JVM 위에서 돌아가는 Business객체 덩어리..
이 자체가 흥미롭지 않습니까?
JavaBeans 컴포넌트를 IDE Tool에서 drag & drop 해봤자 소스보면

SomeJavaBean bean = new SomeJavaBean();

입니다. IDE는 Introspection을 통해 이 jar파일이 javabeans란 것을 인식하고 property
와 event를 설정할 준비를 하는것뿐입니다.
IDE가 원하는건 Interface뿐입니다.
Interfaec는 곧 Spec. 전문용어로 표준입니다.

할 이야기는 많지만 이 Interface를 부정하는 글뿐이니.. 힘이 쫙 빠집니다.


이원영님 말씀대로 JavaBeans가 제대로 방향을 잡을려면 CBD가 정착이 되어야합니다.
그러나 그전에 CBD가 뭔지를 서로 이해가 되어야 할것같습니다.

그렇지 않으면 이야기가 계속 겉돕니다.

CBD, Interface, 강한 내부응집력, 완전한 BlackBox..

이것도 극히 개인적인 취향입니까?

P.S.
public 접근자를 가지는 property를 좋아하는 사람이 있다니..
이건 정말 의외입니다.
좋아하는 여자 사타구니를 개나소나 아무 제한없이 만질수 있단 이야기인데..
현실에서도 가능하지 않은 이야기를 컴퓨터상에 구현을 한다?

너무 KTF적인 생각아닙니까?

 

제목 : Re: 고정관념
글쓴이: 박영록(guest) 2004/11/27 02:06:20 조회수:215 줄수:36  

String vs StringBuffer에서도 느꼈는데 무언가 한 번 주입된 고정관념을 깨지 않으려는
종류의 사람들이 세상에는 참 많은 것 같습니다. 고정관념을 깨고 세상을 한 번 보십시오.
세상은 당신이 변하는 것보다 훨씬 빨리 변하고 있습니다. 아마도 이런 종류의 사람들이
고정관념을 쉽게 깨지 못하는 이유는 다른 사람의 의견을 주의깊게 살피지 않기 때문이
아닌가 합니다. 나름대로 다른 생각을 접하고 다시 한 번 고민해보면 좋은 기회가 될
수도 있는 것을 고정관념 때문에 날려버리고 있지는 않나 생각해보셨으면 좋겠군요.

1. public 프로퍼티와 private 프로퍼티 + public getter/setter는 접근성이 완전히 동등합니다.
결코 더 KTF적인 생각은 아니죠. 자바빈즈는 블랙박스가 아니라 화이트박스입니다.
주입된 지식을 잠시 접어두고 '상식적'으로 생각해보십시오.

2. "JavaBeans 역시 거대한 Business Logic 을 가진 객체덩어리입니다."라고 하셨는데..
자바의 모든 객체는 비즈니스 로직을 가진 객체 덩어리일 수 있습니다. 이런 자바 객체와
구분되는 자바빈즈의 특징이 무엇일까요?

3. 자바빈즈를 이야기하면서 인터페이스를 이야기하는 의도도 조금 혼동됩니다.
reflection보다 interface를 좋아하신다면 당연히 자바빈즈를 싫어하셔야할 것 같은데요.
그 introspection이 어떻게 동작하는 거라고 생각하시는 건지?

4. 물론 빈즈 API에 맞게 쓰려면 자바빈즈의 형식을 갖춰야겠죠. 그렇다고 빈즈 API를
쓰지 않는 객체를 코딩할 때조차 자바빈즈처럼 getter/setter를 갖춰야할까요? 빈즈 API는
표준일지언정 자바빈즈는 결코 프로퍼티 관리 방식의 표준이 아닙니다.

5. 흔히 말하는 좁은 의미의 CBD가 주류로 정착되는 일은 없을 꺼라고 감히 말해봅니다.
CBD는 변화에 약한 방법론입니다. CBD의 성공 사례들은 보통 견고하고 잘 작성된 컴포넌트들을
조립만 해도 requirement를 만족시킬 수 있을 때 뿐이죠. 하루하루 변화하는 requirement를
만족시키기에는 낡은 방법론입니다. 물론 넓은 의미의 CBD라면 RUP 등도 포함될 수 있으니
그리 나쁜 것은 아니지만요.

6. 파이썬은 접근 제한자가 아예 없는 언어임에도 자바보다 더 객체지향적인 언어로 불리고
있습니다. 왜 그럴까요? 파이썬 개발자가 KTF적인 사람이라서? 

----
http://youngrok.com
NHN Corp. 웹플랫폼팀
code for human, not for programmer.

제목 : Re: CBD
글쓴이: 서민구(guest) 2004/11/27 05:17:04 조회수:378 줄수:52  

앞에 '손님'님 한번 이렇게 생각해보세요.
CBD라고 말할때, 컴포넌트라는 단위가 무엇인지요..

우리가 EJB를 디플로이할때의 단위인지,
아니면 EJB내의 클래스 하나하나가 컴포넌트인지.

컴포넌트로 제대로 동작하려면 그것을 어떤 곳에 옮겨놓아도
인터페이스를 통해서 정의된 동작을 수행하면 되죠..
그런데 그 컴포넌트가 JAVA 클래스 한개인지에 대해서는
생각해 볼 필요가 있는 것 같네요..

예를들어, 하나의 웹 서비스를 만들어서 이를 등록시켰을 때
이 서비스는 잘 정의된 통신 규약인 SOAP으로 동작하고,
서비스 종점 및 제공하는 서비스는 UDDI에 등록되어있을 때
그 서비스 내의 하나하나의 자바 클래스가 다 완전한
추상화가 되야할까요? 그것도 현재로서는 불필요하다고 생각되고,
미래에는 일어날지 안일어날지도 모르는 검증을 위해 모든 field 를 
private으로 만들면서요?

저는 그런 완전한 추상화에 대해서 상당히 회의적인 입장이거든요.

아마 마틴 파울러역시 내부에서 쓰는 클래스를 인터페이스를 사용한
publish를 하지 말라고하죠.. 

http://www.artima.com/intv/principles3.html

인터페이스나 블랙 박스나 하는 개념이 나쁘다는게 아니라, 그것을
어떤 업무 단위에서 블랙 박스로 만들고 인터페이스로 만드는 게
낫다는 이야기이죠..

사실 자바의 자바 빈즈라고 하면 어디나 갖다놓아도 잘 동작하는
바이너리 비즈니스 로직이라고 말할 수 없는게, 그건 어디까지나
자바 언어와만 통신하는 거라고 생각합니다.. 그리고 그런 자바
클래스를 묶어서 이기종환경에서도 완전히 통신가능한 서비스 형태로
만들자는게 지금의 이야기인데 (심지어 사람들은 API의 시대는
가고 SOA의 시대가 갔다고까지 말하죠...), 그렇게 제공되는 서비스
내의 자바 클래스들이 모두 자바빈즈 규약을 따라야할런지.
완전한 추상화는 미래에 대한 투자이지만, 만약 미래에 투자한
노력에 대해 돌아오는 것이 전혀 없다면 어떻게 될까요..?
drag & drop 으로 그림 그리듯이 프로그램을 짠다.. 라는 개념도
그리고 자바 빈즈 - 클래스 - 단위 보다는 훨씬 큰 비즈니스 로직단위로
그림 그리듯이 짠다.. 라는게 또 MDA의 흐름 아닌지..

요즘은 유연하게 코드를 바꿀 수 있어야한다.. 라는게 대세가 아닌가
(옳건 그르건 간에)라고 생각이되고, 그런만큼 세세한 단위에서
추상화는 지양하게 되지 않나 생각되네요.. 제 코딩 스타일도 그렇고..
역시 파울러는 같은 일을 두번할때까지는 그냥 두번 한다, 세번 해야한다고
하면 그땐 한번만 하도록 고친다..라고 말했죠.

인터페이스가 필요없다고 말하는 건 아닙니다..
다만, 그 단위가 어떻게 되느냐를 다르게 볼 뿐인 듯.

제목 : Re: 잠시 덧붙여..
글쓴이: 황종훈(guest) 2004/12/02 13:23:13 조회수:135 줄수:46  

박영록님의 첫번째 글에서
"파이썬이나 그루비 등의 언어에는 public, private와 같은 접근 제한자가 없습니다.
객체의 필드는 직접 접근할 수도 있고 "
다음과 같은 부분이 있는데요. 파이썬은 모르겠으나 그루비 같은 경우
물론 접근 제한자는 없지만, 필드를 직접 접근하지 않습니다.

class Foo{
String name;
}
과 같은 클래스는 public필드 하나 있는 것 처럼 보이지만 사실 내부적으로
set과 get을 만들고 있습니다.

class Foo{
 String name;

 Foo(){
  name = "my name is foo."
 }

 String getName(){
  println "....getName()"
  return "my name is not foo."
 }


 static void main(args){
  foo = new Foo()
  println foo.name
 }
}

다음과 같은 groovy화일 실행시 "....getName()"과 더불어
"my name is not foo."이 출력됩니다.

public필드접근이라면 "my name is foo."가 출력되야 하겠죠.

한마디로 groovy자체가 코드제네레이터라는 겁니다.

 

뭐 참고로 빈즈가 악습까진 아니더라도 

저도 박영록님과 Map에 대한 생각이 비슷합니다.

----
by 이즌해

제목 : Re: Active Code Generation
글쓴이: 박영록(poci) 2004/12/02 13:51:21 조회수:206 줄수:18  

그루비가 코드 제네레이터 역할을 하는 것은 자바의 입장이고 그루비를 하나의
언어로 본다면 접근 제한자가 없다고 할 수 있죠. 내부적으로 코드 생성을 하더라도
유저가 그루비만 본다면 상관 없는 문제입니다. 위에 예를 드신 코드의 경우는
접근 제한자의 문제라기보다 그루비의 멤버 변수가 파이썬, C#등의 프로퍼티와
유사한 개념으로 동작할 수 있다는 예로 보는 게 맞는 것 같습니다.

그리고, 이런 종류의 자동 코드 생성은 별다른 문제가 있는 구조는 아니라고 봅니다.

CodeGenerationIsaDesignSmell unless it's ActiveCodeGeneration

http://c2.com/cgi/wiki?CodeGenerationIsaDesignSmell
http://c2.com/cgi/wiki?ActiveCodeGeneration

p.s. 인용하기는 역시 위키가 편하군요.
----
http://youngrok.com
NHN Corp. 웹플랫폼팀

제목 : Re: 프로퍼티접근에 대한 부연설명
글쓴이: 황종훈(guest) 2004/12/02 22:15:25 조회수:145 줄수:32  

예 맞습니다.
전 groovy의 필드 접근이 파이썬, C#등의 프로퍼티 접근과 유사한 
뭐 그런거라는 것을 보여드리고 싶었던 겁니다. 

박영록님의 "객체의 필드는 직접 접근할 수도 있고" 라는 말에 오해의 소지가 있어
올려드렸던 겁니다.
박영록님께서 바로 위에서 말씀하신대로 저 접근은 프로퍼티접근입니다.

제가 말을 다시 바꾸자면
"객체의 필드를 getter,setter없이 직접 접근하는 것처럼-public처럼-접근 할 수 있고,
필요에 따라 getter,setter을 두어 프로퍼티 접근에 부가적인 기능을 지원할 수 있다."
뭐 이정도 되겠습니다.

박영록님께서는 이 사실을 알고 계신다 하더라도
읽으시는 분이 오해할 소지가 있어 올린 것 뿐입니다.
(특히 '자바'만 접하신 분에게)


'내부적으로 코드 생성해서 문제'가 있다고도,
'접근 제한자의 문제'라고도,
'자동 코드 생성은 별다른 문제가 있다'고도 하지 않았습니다.
지금까지 박영록님께서 말씀하시고자 하는 바도 다 알겠고, 
전부 다는 아니지만 저도 생각했던 부분이며 동의하고 있습니다.
문제라고 말씀하시며, 굳이 위키까지 인용 안하셔도 됩니다.


반론이라기보다 오해의소지가 있는 것을 추가설명했다고 생각해 주시면 감사하겠습니다.


------
by 이즌해



[출저]  http://blog.naver.com/PostView.nhn?blogId=gunlee00&logNo=10100486790


'2019년 이전 정리 > Server' 카테고리의 다른 글

[HTTP] Keep-Alive 기능  (0) 2014.07.14
L4 로드밸런싱  (0) 2014.05.19
Tomcat 에러 java.lang.UnsupportedClassVersionError  (0) 2013.12.16
클러스터링 환경  (0) 2013.12.14
세션(session) 시간 설정  (0) 2013.12.02
Posted by hoonihoon
2013. 12. 16. 17:30

문제점:

java.lang.UnsupportedClassVersionError: com/enki/loves/servlet/DownloadServlet : Unsupported major.minor version 51.0 
(unable to load class com.enki.loves.servlet.DownloadServlet) 

war파일 실행했는데 위에 처럼 에러 발생했습니다. 

javacomplier 버전 문제로 파악되었지만 같은 버전을 사용하고 있습니다. 
이클립스 컴파일버전 -> 1.7.0 
jdk path 설정 - > 1.7.0 


해결:

환경변수 셋팅을 잘 해야 한다. JRE_HOME 부분이 문제였음.


TOMCAT_HOME  =   C:\jdk\jdk1.7.0_21

path  =   C:\jdk\jdk1.7.0_21\bin

JAVA_HOME = C:\jdk\jdk1.7.0_21

JRE_HOME = C:\jdk\jdk1.7.0_21

Posted by hoonihoon
2013. 12. 14. 22:37

클러스터링(Clustering)이란 복수개의 장비를 묶어서 마치 이것이 하나의 거대한 장비처럼 인식되도록 하거나 동작하도록 만들어진 전산 환경을 일컷는 말이다.  클러스터링 환경에서는 따라서 특정 장비에 문제가 생기거나 특정 장비에서 실행중인 어플리케이션에 문제가 발생하더라도 해당 장비의 문제로 국한시키고 이것이 특정 서비스 혹은 기능 전체에 영향을 미치지 않도록 제어가 가능하기 때문에 대규모 시스템 혹은 안정적인 기능의 수행이 필요한 대부분의 시스템들에 채용되고 있다.


일반적인 클러스터링 구현

클러스터링을 구현하는 방법은 기본적으로 가상 IP(Virtual IP)를 기반한다.  서비스를 제공하는 실제 장비는 물리적인 IP를 갖고, 이 앞단에 가상 IP를 갖는 장비를 두고 이 장비에서 실제 장비로 데이터 처리를 혹은 요청을 중계하는 방식을 갖는다.  따라서 서비스를 위해 외부에 공개된 네트워크 접속 정보는 가상화된 IP에 근거한 정보가 제공되며 내부 시스템은 철저하게 가려져있는게 일반적인 원칙이다.

통상 이와 같이 가상 IP를 가지고 이를 각각의 물리적인 장비에 외부에서 요청된 처리를 중계해주는 역할을 스위치 장비에서 처리를 해주며 이 장비는 일반적인 허브등과는 차별화된 기능을 수행한다. (따라서 고가이며 이에 대한 범용적인 처리를 위한 대규모 장비들이 데이터센터등에 위치한다.)  스위치 이외에 일반적인 장비를 이용해서 소프트웨어적인 기법으로 이를 구현할 수도 있으며 특정한 목적이 필요한 경우에는 S/W적인 기법을 이용한 스위치 장비를 사용하기도 한다.


상태에 따른 클러스터링의 종류

기본적인 클러스터링은 위에서 언급한 바와 같이 가상 IP를 통해 들어온 요청을 물리적인 장비로 분기시켜주는 기능을 수행한다.  내부적으로 각각의 요청간에 특정 정보를 관리해야 하는 경우에 따라 클러스터링 모델에 차이가 있을 수 있다.

예를 들어 웹 서버에 대한 클러스터링의 경우에는 해당 사용자에 대한 세션 정보의 공유가 필요하며 이 정보는 통상 쿠키(Cookie)를 통해 이루어지므로 클러스터링을 위해 기반된 어플리케이션이 특정한 기능을 별도로 수행할 필요없이 해당 쿠키 정보를 엑세스 할 수 있으면 된다.

반면에 대규모 DBMS 시스템의 경우에는 각 요청단에서 이루어진 Transaction에 대한 상태 정보와 해당 데이터를 DBMS에 Commit 시킬지 Rollback시킬지 여부에 대한 정보 관리가 필요하다.  또한 개별 Transaction에 한 서버에서만 이루어지는 것이 아니라 복수 서버에서 나누어 처리되기 때문에 한 서버에서 Rollback을 수행했을 때 다른 서버에서 이루어진 Transaction도 마찬가지로 복구 처리가 이루어져야 한다.

이 경우에는 개별 장비단에서 동작하는 어플리케이션들이 상호 긴밀하게 사용자에 대한 인지와 해당 사용자에 의해 이루어진 각각의 요청 업무에 해당 상태 및 이력들을 보관하고 있어야 하기 때문에 단순한 구조가 아닌 복잡한 S/W Architecture 및 정보 교환 모델을 요구한다.

따라서 이와 같은 복잡한 상태 정보의 Sharing을 가능하게 해주는 기능을 해당 소프트웨어가 탑재하고 있는냐 없느냐에 따라서 해당 소프트웨어의 가격이 결정된다.  (통상 이런 클러스터링 기능이 탑재된 제품의 가격은 억대다.)

Active/Active 모델과 Active/Standby 모델

이러한 클러스터링 기술을 기반으로 안정적인 시스템 운용 모델을 가져가는 데표적인 형태가 바로 Active/Active 모델과 Active/Standby 모델로 구분되는 운용 모델이다.

Active/Active 모델은 두 대의 장비를 서로 서비스에 운용하면서 두 장비에 있는 어플리케이션이 서로 상태 정보를 공유함으로써 장비의 활용성을 높이고 높은 Throughput을 낼 수 있는 구조를 나타낸다.  통상 오라클이나 J2EE 엔진등이 이런 기반 기술을 지원한다.

Active/Standby 모델은 실제 서비스는 한 장비에서 운용하고 다른 한대는 장애 대비용 시스템으로 사용한다.  만약 한 장비에서 하드웨어 혹은 소프트웨어적인 결함이 발생되면 해당 장비의 기능이 통채로 대기중인 장비로 이전되며 대기중인 장비에서 기능 수행을 위한 어플리케이션이 실행된다.  ( 이 상황에서 장애 장비에서 실행중인 데이터 처리가 유실될 수 있다.) 

Active/Standby 모델은 어플리케이션 자체가 이중화 방식을 지원하지 못하는 경우에 사용되며 이 경우에도 데이터 처리를 넘겨주는 S/W가 필요하다.  이를 위한 기반 S/W는 통상 OS 수준에서 제공되며 많이 알려진 제품으로는 HP의 MC/SG(MC Service Guide)다.


출저: 클러스터링 환경

Posted by hoonihoon
2013. 12. 2. 13:54

세션의 유효시간은 디폴트로 30분으로 설정 되어있다.

C:\Tomcat\conf\web.xm   파일을 열어서 수정이 가능 하다

<session-config>

     <session-timeout>30</session-timeout>

 </session-config>


코드에서 설정 하는 법 

session.setMaxInactiveInterval(30) : 30초후 세션 삭제.(30초 후, refresh하면 ID 변경)

session.invalidate() : 세션 바로 삭제.

Posted by hoonihoon
2013. 12. 2. 13:41

HTTP 개념

1. HTTP 는 비연결 구조로 사용자의 연결을 계속 유지 하지 않는 방식

2. 사용자의 요청에 대한 응답을 한 후 연결을 해제


아래글은 쿠키와 세션을 이해하기 쉽게 그림으로 설명 해 놓은 글입니다. 


로그인 정보나 장바구니 정보 같은 클라이언트 기반 정보들은 어떻게 저장할까?

다음 그림을 보자.

HTTP는 연결 보장을 하지 않으므로 또 다시 요청이 들어 온다면 서버는 해당 브라우저의 세션정보를 찾아줘야 할 것이다.

그런데 서버입장에서 생각해보면 서버에 요청해놓은 브라우저들이 엄청 많기에 세션정보를 어떻게 줄까?


그래서 자신의 세션 정보를 찾기 위해 자신의 세션을 증명하는 ID 가 필요하다.

보통의 사이트에서는 ID를 쿠키로 가지고 있게 된다. 

쿠키란 브라우저 상에서 저장되는 객체이다.

더쉽게 말하면 쿠키는 사용자 컴퓨터의 하드디스크에 저장되는 작은 텍스트 파일이며 세션은 서버의 메모리상에 존재하는 객체이다.

사용자 컴퓨터에서 세션정보처럼 많은 정보를 저장하기 힘든 관계로 많은 정보는 세션에 저장하고 그 세션 아이디만 web browser(사용자pc) 에 쿠키 형태로 저장을 해두는 것이다.


이런식으로 하면 세션아이디로 로그인 정보를 꺼내 줄 수 있다.

그럼 한번 이 세션아이디로 정말 로그인이 가능한지 테스트 해볼까?



일단 쿠키를 수정하기 위해 크롬 ad-on "Edit This Cookie" 를 설치한다.



원하는 사이트에 로그인 한 후 Edit This Cookie 를 실행해 보면



앵간하면 SESSION ID 라고 써있는 쿠키를 발견할 수 있을 것이다.


SESSION ID 라고 써있는 쿠키를 발견했다면 그 값을 잠시 메모장에 저장해 둔다.


그러고선 SESSION ID 를 지워보자



브라우저를 리플래쉬하면??




당연히 세션ID를 잃어버렸으니까 서버에서 자기 세션을 찾지 못하므로 서버는 이놈이 로그인 안된줄 알고 로그인 하라는 메시지를 보낼 것이다.


그렇다면 다시 아까 메모장에 저장해둔 세션 아이디를 입력하고 리프래쉬 해보자!


어떻게 되는가?




멀쩡하게 로그인 한것과 같은 화면이 되버린다.


아직 서버 안에 세션객체가 죽지 않았기 때문에


알맞는 세션 아이디만 있으면 다시 그 세션(로그인 정보와 장바구니 정보)를 물려줄 것 이다.



이쯤되면 아~ 로그아웃을 꼭 누르고 나와야 겠구나 할것이다.


왠만한 사이트의 로그아웃 기능은 쿠키의 세션아이디를 지워버리는 역할을 한다.


만약 피씨방 같은곳에서 로그아웃을 하지 않고 브라우저 창만 닫고 나온다면?


 


피씨에 저장된 쿠키의 세션 아이디값을 읽어다가 


브라우저에 쿠키를 설정하고 해당 사이트에 들어가면 그대로 로그인이 되버리므로 조심 조심


공공장소에서는 항상 로그아웃버튼을 누르고 나오시길!



[추가정리]
1. 쿠키
- 서버에 접속시 접속한 클라이언트 정보를 클라이언트에 저장한다.
-이후에 서버로 전송되는 요청에는 쿠키가 가지고 있는 정보가 같이 포함되어서 전송
-크기는 4096 Byte 이하
-클라이언트에 총 300개 까지 쿠키를 저장할 수 있다.
-하나의 도메인 당 20개의 값만 가질수 있다.
-쿠키는 이름,값,유효기간,도메인,경로 등으로 구성

사용예)
방문했던 사이트에 다시 방문 하였을 때 아이디와 비밀번호 자동 입력
팝업에서 오늘 이창을 다시 보지 않음체크

2. 세션
-웹서버 쪽 웹 컨테이너에 상태를 유지하기 위한 정보를 저장
-저장 데이터에 제한이 없음
-웹서버는 각각의 웹브라우저로부터 발생한 요청에 대하여 특정한 식별자를 우여하여 같은 브라우저인지 구별
-세션쿠키라고도 한다.
-브라우저를 닫거나, 서버에서 이 이쿠키를 삭제 했을때만 삭제가 되므로 비교적 지속성이 쿠키보다 안전하다
- 각각의 클라이언트마다 고유의 ID를 부여
-세션 객체마다 저장해 둔 데이터를 이용하여 서로 다른 클라이언트의 요구에 맞게 서비스제공

차이점은 : 
저장되는 곳이 다르다는 것.
= (쿠키는 클라이언트, 세션은 서버)
저장형태 
=(쿠키 텍스트형식, 세션은 Object형으로 메모리에 저장)
만료기간도 다르다는 것
= (쿠키는 저장시 설정하는데 설정하지 않으면 브라우저 종료시 소멸, 세션은 정확한 시점을 알 수 없음)
자원
=(쿠키는 클라이언트자원사용, 세션은 서버의 자원 사용)
용량
=(쿠키는 한 도메인에 20개, 쿠키당 4KB, 총 300개, 세션은 서버가 허용하는 한 용량에 제한 없음)

출저: 

 http://jhoonslife.tistory.com/354

http://marcof.tistory.com/16

http://bllizz.tistory.com/15

Posted by hoonihoon