[Web] Spring Boot with JPA (0-3) 소켓 통신과 Apachi Tomcat

• 먼저 소켓 Socket 통신에 대해 알아야 한다. Socket은 운영체제가 가지고 있다.
  • 소켓통신과정 
    1. A와 B가 통신을 하고 싶다?
    2. A의 Socket이 오픈 된다. 오픈한 소켓은 포트번호가 빌요하다. 예를 들어 5000이라고 하자.
    3. 이제 5000번 포트는 연결을 위한 소켓이 존재하게된다.
    4. B는 ip주소와 포트번호(5000번)를 통해 A에 접속한다. 이제 A와 B는 메시지를 주고받을 수 있다.
    5. 하지만 이렇게 되면 C라는 애가 A와 통신을 하고 싶어도 못하게된다. 이미 5000번 포트로 B와 A가 짝짝꿍 중이기 때문이다.
    6. 따라서 위처럼 만들면안됨. 다시 처음부터..
    7. 최초의 5000번 포트는 연결을 위한 포트로만 사용한다.
    8. 5000번 포트와 연결이 되는 순간 새로운 소켓을 오픈한다. 이때 생성되는 포트 번호는 랜덤으로 만들어지고 직접 번호를 지정할 수도 있다.
    9. 따라서 B가 5000번 포트로 A와 연결을 하게되면 A의 5001번(ex) 포트가 열리고 5000번과의 연결을 끊고 새로운 소켓(5001)에 연결이 된다.
    10. 근데 갑자기 C도 A와 통신을 하고싶다. 5000번 포트에 연결하면 되겠지?
    11. 아니다. CPU는 A와 B의 통신(5001)에 몰두한다. 따라서 C는 연결조차 할 수 없다.
    12. 그렇다면 어떡해? => 위에 5001번 포트에 새로운 소켓을 만들때 A는 새로운 스레드1를 만들어야 한다. 참고로 A의 main스레드는 5000번 포트에서 계속해서 새로운 사용자의 연결요청을 받는다.
    13. A의 스레드1(5001) 에서는 이제 B와 통신을 하고 있다. 이 상태에서는 새로운 사용자 C의 요청을 받을 수 있다.
    14. C가 5000번 포트에 접근하여 연결요청을 한다.
    15. 5002번 포트에 새로운 소켓이 생성되며 새로운 스레드2 가 만들어진다.
    16. 물론 5000번의 연결은 끊어진다. 새로운 사용자의 연결 요청을 받아야하기 때문이다.
    17. 이제 C는 5002번 포트로 소켓통신을 통해 A와 메시지를 교환할 수 있다.
        
        • 소켓통신의 단점 : 연결이 계속 되어있기 때문에 연결이 많아질수록 부하가 생각보다 크고 느려진다. 따라서  http 통신은 연결을 지속시키지 않고 끊어버리는 Stateless 방식을 쓴다.
  • http 통신 : 문서를 전달하는 통신 
    • 연결을 지속시키지 않고 끊어버리는 Stateless 방식을 쓴다.
    • 즉, A와 C가 연결되고 필요한 문서를 얻으면 그 연결을 끊어 버린다. 따라서 똑같은 사용자가 재 요청할 경우 그 사용자가 아까랑 같은 놈인지 구분할 수 없다는 단점이 있다.

 

Spring Boot의 특징

• 내장 톰켓을 가진다
  • 톰켓을 따로 설치할 필요 없이 바로 실행할 수 있다.
  • 톰켓이란?
    • 톰켓을 설명하려면 먼저 웹 서버에 대해 설명해야한다.
    • 웹서버 : 갑과 을 관계의 '갑'
      • '을'은 '갑'에게 자원에 대한 요청 Request를 한다. Request 하기 위해서는 자신의 IP와 URL (자원을 요청하는 주소)이 필요하다.
      • '갑'은 '을'의 요청에 대하여 응답 Response 한다. '갑'은 '을'의 IP를 몰라도 된다. '을'의 Request에 담겨있으므로.
      • 이때 갑이 웹서버가 되는 것이다.
      • Http 통신에서의 '갑'은 '을'의 요청이 없으면 '을'의 주소를 알 수 없다. 연결이 끊기니까. 하지만 이때 위의 소켓통신을 이용하면 연결이 계속 지속되기 때문에 '갑'은 자신이 원하는 시점에 '을' 에게 데이터를 전달할 수 있다.
    • 웹서버 통신
      1. 보통 웹서버는 Apachi를 쓴다. 
      2. A가 아파치에 자원을 요청(Request) 한다. 
      3. 아파치는 A에게 그 자원을 응답(Response) 해주면 통신 끝이다.
    • 만약 자바코드가 있는 요청(Requset)일 경우
      1. A가 Apachi에게 .JSP 로 요청한다.
      2. 아파치는 자바코드를 이해하지 못한다.
      3. 따라서 .JSP 파일에 대한 제어권을 톰켓에게 넘겨준다. 
      4. 톰켓은 .JSP 파일에 있는 모든 자바 코드를 컴파일하고 컴파일 된 데이터를 .html 에 덮어씌운다. 즉 .html 문서로 만들어 준다는 뜻.
      5. 이 .html 문서를 아파치에게 돌려준다.
      6. 아파치는 A에게 .html 파일을 응답(Response) 해준다.
      7. 흔히 요청은 웹 브라우저로 요청을 할 것이다. 웹 브라우저는 html, Javascript, CSS, avi와 같은 정적인 파일들만 이해할 수 있기 때문데 톰켓이 없을 경우 JSP 요청은 그대로 JSP 응답으로 돌아오고 웹 브라우저에서 깨져 보일것이다.
    • 결론 : 아파치는 요청한 파일을 응답해주는 놈. 톰켓은 요청한 파일중에 Java 코드가 있다면 그것을 컴파일 하여 html 파일로 번역해서 돌려주는 놈이다. 
    • 참고 : 톰켓같은 역할을 해주는 것을 WAS(Web Application Server) 라고 하며, 웹 서버와 웹 컨테이너의 결합으로 다양한 기능을 컨테이너에 구현하여 다양한 역할을 수행할 수 있는 서버를 말한다. 톰켓은 서블릿 컨테이너 라고도 불린다.

출처 : https://www.youtube.com/watch?v=wc-K2QurjSk&list=PL93mKxaRDidG_OIfRQ4nztPQ13y74lCYg&index=10 

 

후기

 

 소켓 통신의 과정 및 아파치 톰켓에 대해 다시한번 복습할 수 있었다.