DuckDevelope

웹을 개발하면 기본적으로 회원을 관리하고 로그인하는 부분을 개발하기 마련이다.

웹서핑을 하다보면 브라우저에 자물쇠표시가 되어있는 경우를 종종 보게된다. 해당 웹사이트는 SSL 이라는 보안 프로토콜을 사용한다는 표시다.

SSL은 Secure Socket Layer이라는 약자로 보안 소켓 레이어이다.

보통 443포트를 사용하며 https:// 를 사용한다.

앞으로 웹개발을 하다보면 이런 https:// 를 사용하는 많은 웹사이트를 보게 될것이고,

또한 SSL기반으로 개발을 할 수도 있다.

아직 SSL의 개념을 잘 모르므로 SSL에 대한 간단하게 개념을 이해해 보도록하겠다.

SSL은 Netscape사에서 웹서버와 웹브라우저간의 보안을 위해 만들어졌으며, 공개키/개인키 대칭키 기반으로 사용한다.

공개키/개인키는 많이 들어봤듯이, 공개키로 암호화하고 공개키와 매칭되는 개인키로만 복화할 수 있다. 따라서 공개키는 누구든지 알아도 상관없고 개인키는 복호화해야 하는 대상만 알 수 있도록 잘 보관해야 한다.

공개키/개인키는 계산하는데 복잡하고 시간복잡도가 높으므로 보통 모든 전송을 공개키/개인키 암호화기법을 이용하여 전송하는것이 아니라, 전송할것들은 대칭키를 이용하여 암호화하고, 대칭키만을 공개키/개인키로 암호화하여 전송한다.

이런 과정을 통해 암호화한다해도 대상 사이트가 만약에 가짜사이트 또는 대상이 해커라면 사용자의 정보가 노출될수 있다. 이 때문에 인증서라는것이 있다.

https로 통신하는 웹사이트를 이용하다보면 웹브라우저에 자물쇠 표시가 있는데 해당 자물쇠를 눌러보면 보통 인증서가 있다. 이 인증서는 신뢰할수 있는 제3자 인증기관에서 발급받을 수 있으며 이 인증서에는 인증서의 해당 사이트의 공개키와 사이트의 정보들이 있다. 인증서가 전송될떄는 인증기관의 제공하는 개인키로 암호화하여 전송된다.

인증서 또한 만약 가짜사이트 또는 해커가 인위적으로 만들었다면 사용자의 정보가 노출이 될수 있는데 이를 막기 위해 인증기관의 공개키를 브라우저에게 알려주고 브라우저에서는 해당 사이트에서 제공하는 공개키가 아닌 브라우저의 공개키를 사용하기 때문에 대상이 인증기관인지 아닌지 판별할 수 있다.

이렇게하여 SSL의 통신을 사용한다.

간단하게 요약하자면

1. 사이트에서 인증기관(CA: Certificate Authority)에 인증요청
2. 인증기관에서 검증후에 사이트의 공개키와 정보를 인증기관의 개인키로 암호화, 인증기관의 공개키는 브라우저에 제공
3. 사용자가 사이트로 접속 요청시 사이트는 인증서 전송
4. 사용자는 브라우저에 내장된 공개키로 인증서를 복호화 -> 사이트의 공개키로 대칭키를 암호화하여 전송
5. 사이트는 전송받은 암호화된 대칭키를 사이트의 개인키로 복호화 -> 사용자, 사이트 같은 대칭키 획득
6. 전송시 해당 대칭키로 암호화하여 전송

SSL통신을 하는 사이트의 SSL 보안등급을 분석해주는 사이트 : https://www.ssllabs.com/ssltest/analyze.html?d=[SSL 사용하는 url]

ex: https://www.ssllabs.com/ssltest/analyze.html?d=id.payco.com

각 인증서에는 만료기간이 있으며, 인증서의 만료되기 전에 갱신을 해야한다.

차후에 인증서는 어디에 저장하고, 어떻게 갱신을 하는지 공부하도록 하겠다.

참고한 사이트 : https://wiki.kldp.org/HOWTO/html/SSL-Certificates-HOWTO/x70.html http://minix.tistory.com/397#recentTrackback

Servlet(서블릿)

- 웹프로그래밍에서 클라이언트의 요청을 처리하고 그 결과를 다시 클라이언트에게 전송하는 Servlet 클래스의 구현 규칙을 지킨 자바 프로그래밍 기술

- 자바를 사용하여 웹을 만들기 위해 필요한 기술

특징

- 클라이언트의 요청에 대해 동적으로 작동하는 웹 어플리케이션 컴포넌트

- HTML을 사용하여 요청에 응답한다.

- Java Thread를 이용하여 동작한다.

- MVC패턴에서 Controller로 이용

- HTTP 프로토콜 서비스를 지원하는 javax.servlet.http.HttpServlet 클래스를 상속받는다.

- HTML 변경 시 Servlet을 재컴파일해야 하는 단점이 있다.

일반적으로 웹서버는 정적인 페이지만을 제공합니다. 그렇기에 동적인 페이지를 제공하기 위해서 웹서버는 

다른 곳에 도움을 요청하여 동적인 페이지를 작성해야 합니다. 동적인 페이지로는 임의의 이미지만을 보여주는 페이지와 같이

사용자가 요청한 시점에 페이지를 생성해서 전달해 주는 것을 의미합니다. 여기서 웹서버가 동적인 페이지를 제공할 수 있도록

도와주는 어플리케이션이 서블릿이며, 동적인 페이지를 생성하는 어플리케이션이 CGI입니다.

CGI(Common User Interface)

- CGI는 특별한 라이브러리나 도구를 의미하는 것이 아니고, 별도로 제작된 웹서버와 프로그램간의 교환방식입니다. CGI방식은 어떠한 프로그래밍언      어로도 구현이가능하며, 별도로 만들어 놓은 프로그램에 HTML의 Get or Post 방법으로 클라이언트의 데이터를 환경변수로 전달하고, 프로그램의 표    준 출력 결과를 클라이언트에게 전송하는 것입니다.

  즉, 자바 어플리케이션 코딩을 하듯 웹 브라우저용 출력 화면을 만드는 방법입니다.

Servlet 동작 방식

1. 사용자(클라이언트)가 URL을 클릭하면 HTTP Request를 Servlet Conatiner로 전송합니다.
2. HTTP Request를 전송받은 Servlet Container는 HttpServletRequest, HttpServletResponse 두 객체를 생성합니다.
3. web.xml은 사용자가 요청한 URL을 분석하여 어느 서블릿에 대해 요청을 한 것인지 찾습니다.
4. 해당 서블릿에서 service메소드를 호출한 후 클리아언트의 POST, GET여부에 따라 doGet() 또는 doPost()를 호출합니다.
5. doGet() or doPost() 메소드는 동적 페이지를 생성한 후 HttpServletResponse객체에 응답을 보냅니다.
6. 응답이 끝나면 HttpServletRequest, HttpServletResponse 두 객체를 소멸시킵니다.

Servlet Container(서블릿 컨테이너)

- 서블릿을 관리해주는 놈을 서블릿 컨테이너라고 한다. 서블릿 컨테이너는 서블릿의 생명주기를 관리하고 요청에 따른 스레드를 생성해준다. 또, 클라이언트의 Request 를 받아주고 Response 를 보낼 수 있게 웹 서버와 소켓을 만들어서 통신을 해준다. 자세한 서블릿 컨테이너의 역할은 아래와 같다.

[Servlet Container 역할]

1. 클라이언트의 요청이 들어오면 컨테이너는 해당 서블릿이 메모리에 있는지 확인하고, 없을 경우 init()메소드를 호출하여 적재합니다. init()메소드는 처음 한번만 실행되기 때문에, 서블릿의 쓰레드에서 공통적으로 사용해야하는 것이 있다면 오버라이딩하여 구현하면 됩다. 실행 중 서블릿이 변경될 경우, 기존 서블릿을 파괴하고 init()을 통해 새로운 내용을 다시 메모리에 적재합니다.
2. init()이 호출된 후 클라이언트의 요청에 따라서 service()메소드를 통해 요청에 대한 응답이 doGet()가 doPost()로 분기됩니다. 이때 서블릿 컨테이너가 클라이언트의 요청이 오면 가장 먼저 처리하는 과정으로 생성된 HttpServletRequest, HttpServletResponse에 의해 request와 response객체가 제공됩니다.
3. 컨테이너가 서블릿에 종료 요청을 하면 destroy()메소드가 호출되는데 마찬가지로 한번만 실행되며, 종료시에 처리해야하는 작업들은 destroy()메소드를 오버라이딩하여 구현하면 됩니다.

웹 서버(Web Server)

- Web Client(웹 브라우저)에게 컨텐츠를 제공하는 서버, 정적인 HTML이나 jpeg, gif 같은 이미지를 HTTP 프로토콜을 통해 웹 브라우저에게 전송하는 역할

- 클라이언트의 요청을 받아 HTML이나 오브젝트를 HTTP 프로토콜을 이용해 전송하는 것.

  사용자가 클라이언트로 요청을 보내오면 그 명령에 대한 처리를 실행하고 다시 사용자에게 답변을 보내준다.

- 사용자가 요청한 것들 중에 웹 서버 자체적으로 처리할 수 없는 것들을 톰캣과 같은 컨테이너나 PHP모듈과 같이 처리할 수 있는 곳으로 넘겨 처리 받아    와서 사용자에게 넘겨주는 역할도 수행

- 웹서버만 구축된 서버는 웹 페이지, 이미지등 정적인 페이지를 생성하지만, JSP 컨테이너가 탑재되어 있는 WAS는 JSP페이지를 컴파일 해 동적인 페이지    를 생성한다.

- 웹 서버는 웹 문서를, WAS는 JSP페이지 등을 양분하여 서버 부담을 줄이는 것이 가능하다.

- Apache, IIS, WebtoB

웹 어플리케이션 서버(Web Application Server / WAS)

- 웹 서버 + 웹 컨테이너

- 웹상에서 사용하는 컴포넌트들을 올려놓고 사용하게 되는 서버

- 웹과 기업의 기간 시스템 사이에 위치하면서, 웹 기반 분산 시스템 개발을 쉽게 도와주고 안정적인 트랜잭션 처리를 보장해 주는 일종의 미들웨어

  소프트웨어 서버

- 클라이언트와 서버 환경에서 트랜잭션 처리 및 다른 기존 시스템 간의 어플리케이션 연동등을 주된 기능으로 하고 있다.

- Web Logic, Web Sphere, Jeus, JBoss

- Tomcat은 JSP / Servlet Container의 기능을 구현했으나 EJB Container로서의 기능이 없다 (Tomcat은 Was가 아니라는 사람도 있다...)

Web Server와 WAS의 차이

- 웹 서버와 WAS를 구별 짓는 것은 동적 서버 컨텐츠를 수행하는가? 만약 수행한다면 WAS로 보면 된다.

- 웹서버 : 정적인 HTML이나 이미지를 제공하는 서버

  WAS : 동적인 처리를 담당하는 서버

- 웹서버 기능

  1. Clustering 기능: 사용자 요청이 발생하면 상황에 따라 각각의 WAS에 요청을 넘김.

  2. Cache 기능: css, js, image 등의 리소스 파일을 가지고 있다가 was를 거치지 않고 사용자에게 직접 넘김.

                      사용자는 cache period동안 전달받은 리소스를 사용함.

- WAS 기능

  Servlet 페이지를 html 형태로 변환함.

  예를 들어 jsp의 경우 jsp를 WAS에서 java class파일로 컴파일 후 html형태의 페이지를 사용자에게 전달하게 됨.

Web Server와 WAS의 일반적인 구성

- 사용자가 브라우저에서 요청을 하게 되면 다음과 같이 웹서버와 WAS서버를 거쳐 응답이 돌아오게 된다.

  사용자 요청(웹 브라우저) -> 웹 서버 -> WAS(동적 처리) -> 웹 서버 -> 사용자 응답 메세지(웹 브라우저)

Web Server와 WAS의 구성에 따른 분류
○ WAS와 WebServer를 분리하지 않는 경우 
모든 컨텐츠를 한곳에 집중시켜 웹서버와 WAS의 역할을 동시에 수행, 스위치를 통한 로드 밸러싱, 사용자가 적을 경우 효율적

○ WAS와 WebServer를 분리한 경우 
웹서버와 WAS의 기능적 분류를 통해 효과적인 분산을 유도, 정적인 데이터는 웹서버에서 처리, 동적인 데이터는 WAS가 처리

○ WAS 여러개와 WebServer를 분리한 경우
WAS단을 프리젠테이션 로직와 비즈니스 로직으로 구분하여 구성, 특정 logic의 부하에 따라 적절한 대응할 수 있지만 설계단
계 유지보수 단계가 복잡해 질 수가 있다.