DuckDevelope

WebSocket이란 

Transport protocol의 일종으로 쉽게 이야기하면 웹버전의 TCP 또는 Socket이라고 이해하면 된다.

WebSocket은 서버와 클라이언트 간에 Socket Connection을 유지해서 언제든 양방향 통신 또는 데이터 전송이 가능하도록 하는 기술이다.

Real-time web application구현을 위해 널리 사용되어지고 있다. (SNS어플리케이션, LoL같은 멀티플레이어 게임, 구글 Doc, 증권거래, 화상채팅 등)

사용이유

웹어플리케이션에서 기존의 서버와 클라이언트 간의 통신은 대부분 HTTP를 통해 이루어 졌으며 HTTP는 Request/response기반의 Stateless protocol이다.

즉, 서버와 클라이언트 간의 Socket connection같은 영구적인 연결이 되어있지 않고 클라이언트 쪽에서 필요할때 Request를 할때만 서버가 Response를 하는 방식으로 통신이 진행되는 한방향 통신이다.  이럴경우 서버쪽 데이터가 업데이트 되더라도 클라이언트 쪽에는 화면은 Refresh하지 않는한 변경된 데이터가 업데이트 되지 않는 문제가 발생한다. 이런 문제는 일반적은 웹어플리케이션에서는 기존의 있던 임시방편인 Long polling이라던가 Ajax를 사용해도 어느정도 해결이 가능하지만 데이터의 빠른 업데이트가 아주 중요한 요소 중에 하나인 어플리케이션에서는 실시간 업데이트가 아주 중요하기 때문에 Web Socket이 아주 중요한 기술로 사용되고 있다.

Web Socket은 Stateful protocol이기 때문에 클라이언트와 한 번 연결이 되면 계속 같은 라인을 사용해서 통신하기 때문에 HTTP 사용시 필요없이 발생되는 HTTP와 TCP연결 트래픽을 피할 수 있다. 마지막으로  Web Socket은 HTTP와 같은 포트(80)을 사용하기에 기업용 어플리케이션에 적용할 때 방화벽은 재설정 하지 않아도 되는 장점이 있다.

작동원리

서버와 클라이언트 간의 WebSocket연결은 HTTP프로토콜을 통해 이루어집니다. 만약 연결이 정상적으로 이루어 진다면 서버와 클라이언트 간에 WebSocket연결이 이루어지고 일정 시간이 지나면 HTTP연결은 자동으로 끊어집니다.

HTTP통신방법과 WebSocket의 차이점

결정적인 차이는 프로토콜이다.

WebSocket 프로토콜은 접속 확립에 HTTP를 사용하지만, 그 후 통신은 WebSocket 독자의 프로토콜로 이루어진다.

또한, header가 상당히 작아 overhead가 적은 특징이 있다. 장시간 접속을 전제로 하기 때문에, 접속한 상태라면 클라이언트나 서버로부터 데이터 송신이 가능하다. 더불어 데이터의 송신과 수신에 각각 커넥션을 맺을 필요가 없어 하나의 커넥션으로 데이터를 송수신 할 수 있다. 

pom.xml

- 빌드 / 배포와 관련된 모든 설정을 담고 있고 MAVEN이라는 유틸리티에서 메타 정보로 사용하는 설정파일

- 자바 라이브러리를 관리하기 위한 원격 저장소

- 메이븐 이란? 글 참고

web.xml

Web Application의 Deployment Descriptor(환경 파일)로서 XML 형식의 파일

- 웹과 관련된 설정(리스너, 어플리케이션 파라미터, 서블릿 설정, 필터 설정 등)을 담고 있다.

- 클라이언트의 요청이 들어오면 그에 따라 해당 요청을 처리를 할 곳으로 넘겨주고, 그 결과인 서버쪽 응답을 클라이언트에게 넘겨주는 곳

  DispatcherServlet을 여기서 설정한다. (load-on-startup을 통해 순서를 정해줄 수 있다.)

작성되는 내용

- ServletContext의 초기 파라미터

- Session의 유효시간 설정

- Servlet/JSP에 대한 정의

- Servlet/JSP 맵핑

- Mime Type 맵핑

- Welcome File list

- Error Pages 처리

- 리스너/필터 설정

- 보안

메이븐 이란?

- 라이브러리에 대한 의존 관계를 관리하고, 프로젝트 빌드에 필효한 기능을 제공하는 역할

메이븐의 기능

1. 빌드

2. 문서화

3. 리포팅

4. 의존 관계

5. 소스 코드 관리

6. 릴리즈

7. 배포

메이븐의 구조

아래는 처음 spring project를 생성하게 되면 기본적으로 생성되는 pom.xml파일 입니다.

출처: http://dahyeee.tistory.com/entry/Maven이란 []

메이븐의 라이프 사이클

- 최정 빌드 순서는 compile -> test -> package

1) compile : src/main/java 디렉터리 아래의 모든 소스 코드가 컴파일 된다.

2) test : src/test/java, src/test/resource 테스트 자원 복사 및 테스트 소스 코드 컴파일

   ** junit : 단위 테스트 프레임워크, 테스트 단계를 거치기 위해 의존 설정을 해줌

3) packaging : 컴파일과 테스트가 완료 된 후, jar나 war같은 형태로 압축하는 작업

자바 엔터프라이즈 개발을 편하게 해주는 오픈소스 경량급 애플리케이션 프레임워크

1. 애플리케이션 프레임워크

- 일반적으로 라이브러리나 프레임워크는 특정 업무 분야나 한 가지 기술에 특화된 목표를 가지고 만들어진다.

- 프레임워크 애플리케이션의 특정 계층에서 주로 동작하는 한 가지 분야에 집중된다. 하지만 스프링은 이와 다르게 '애플리케이션 프레임워크'라는 특징

- 애플리케이션 프레임워크는 특정 계층이나 기술,업무 분야에 국한되지 않고 애플리케이션의 전 영역을 포괄하는 범용적인 프레임워크다.

- 애플리케이션 프레임워크는 애플리케이션 개발의 전 과정을 빠르고 편리하며 효율적으로 진행하는데 일차적인 목표를 두는 프레임워크다.

- 애플리케이션의 전 영역을 관통하는 일관된 프로그래밍 모델과 핵심 기술을 바탕으로 해서 각 분야의 특성에 맞는 필요를 채워주고 있기 때문에,

  애플리케이션을 빠르고 효과적으로 개발할 수가 있다. 바로 이것이 스프링이 애플리케이션 프레임워크라 불리는 이유

- 스프링의 일차적인 존재 목적은 핵심 기술에 담긴 프로그래밍 모델을 일관되게 적용해서 엔터프라이즈 애플리케이션 전 계층과 전 영역에 전략과 기능을 제공해 줌으로써 애플리케이션을 편리하게 개발하게 해주는 애플리케이션 프레임워크로 사용되는 것임을 기억하자.

2. 경량급

- 불필요하게 무겁지 않다.

- 스프링은 가장 단순한 서버환경인 톰캣이나 제티에서도 완벽하게 동작한다.

- 단순한 개발툴과 기본적인 개발환경으로도 엔터프라이즈 개발에서 필요로 하는 주요한 기능을 갖춘 애플리케이션을 개발하기에 충분하다.

- 스프링의 장점은 가볍고 단순한 환경에서도 복잡한 EJB와 고가의 WAS를 갖춰야만 가능했던 엔터프라이즈 개발의 고급 기술을 대부분 사용이 가능

- 만들어진 코드가 지원하는 기술수준은 비슷하더라도 그것을 훨씬 빠르고 간편하게 작성하게 해줌으로써 품질 면에서 유리하다는 것이 바로 경량급이라는 말로 표현되는 스프링의 특징

3. 자바 엔터프라이즈 개발을 편하게

- 스프링은 근본적인 부분에서 엔터프라이즈 개발의 복잡합을 제거해내고 진정으로 개발을 편하게 해주는 해결책을 제시

- 초기에 스프링의 기본 설정과 적용 기술만 잘 선택하고 준비해두면, 이후로 애플리케이션 개발 중에는 스프링과 관련된 코드나 API에 대해 개발자가 거의 신경 쓸 일이 없다.

- 엔터프라이즈 개발에서 필연적으로 요구되는 기술적인 요구를 충족하면서도 개발을 복잡하게 만들지 않는다는 점이 스프링의 뛰어난 면

4. 오픈소스

- 여전히 오픈소스 개발 모델과 오픈소스 라이선스를 가지고 개발되는 중이며, 앞으로 바뀌지 않는다.

GET과 POST는 HTTP프로토콜을 이용해서 서버에 무언가를 전달할때 사용하는 방식이다.

GET은 주소줄에 값이 ?뒤에 쌍으로 이어붙고 POST는 숨겨져서(BODY안에) 보내진다.

GET은 URL에 이어붙기 때문에 길이제한이 있어서 많은양의 데이터를 보내기 어렵고 POST는 많은 양을 보내기에 적합하다.

즉 http://url/bbslist.html?id=5&pageNum=2 같은 것이 GET 방식이고 form을 이용해서 submit을 날리는 형식이 POST이다.

그렇다면 언제 GET을 사용하고 언제 POST를 사용해야 할까?

예를들면 id값을 넘겨서 게시판의 리스트를 불러온다고 가정하면 당연히 GET을 사용할 것이고 게시판에 글을 작성한다면 POST를 사용할 것이다.

전달해야 할 데이터가 많으면 고민없이 POST를 사용하겠지만, 양이 많지 않은 경우에는 고민이 된다.

GET은 가져오는 것이고 POST는 수행하는 것이다.

GET은 SELECT적인 성향이 있다. 즉 GET은 서버에서 어떤 데이터를 가져와서 보여준다거나 하는 용도이지 서버의 값이나 상태를 바꾸지 않는다.

예를 들면 게시판의 리스트라던지 글보기 기능이다.

POST는 서버의 값이나 상태를 바꾸기 위해 사용한다. 글쓰기를 하면 글의 내용이 DB에 저장이 되고 수정을 하면 DB값이 수정이 된다. 

기본적인 개념을 확실히 알고 가자!

아파치(Apache)란?

- 아파치 재단에서 만든 소프트웨어

- 정적인 데이터를 처리하는 웹서버

  웹서버는 클라이언트가 GET, POST, DELETE 등등의 메소드를 이용해 요청을 하면 그에 대한 결과를 돌려주는 기능

  정적인 HTML이나 이미지를 제공하는 서버를 웹서버라 한다.

아파치 톰캣(Apache Tomcat)란?

- 아파티 재단에서 만든 소프트웨어

- 동적인 데이터를 처리하는 웹서버

  동적인 처리를 담당하는 서버를 WAS라 하고, 대표적인 WAS가 아파치 톰캣이다.

- WAS라고 불리며, 웹서버와 웹 컨테이너의 결합으로 다양한 기능을 컨테이너에 구현하여 다양한 역할을 수행할 수 있는 서버

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

웹서핑을 하다보면 브라우저에 자물쇠표시가 되어있는 경우를 종종 보게된다. 해당 웹사이트는 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의 부하에 따라 적절한 대응할 수 있지만 설계단
계 유지보수 단계가 복잡해 질 수가 있다.