• Client가 브라우저에서 하는 행위들을 통해서 Front와 Back이 통신
• DB를 들리지 않아도 되는 부분 - Web Server에서 처리 (홈페이지 처리(HTML) => 정적 파일)
• DB를 들려야 되는 부분 - WAS(Web Application Server)에서 처리 => JSP/Servlet(동적 파일)

1-1. WAS(Web Application Server)

• DB에게서 값을 받아서 동적으로 페이지를 구성
• Apache Tomcat을 이용해서 서버를 구성

1-2. JSP(Java Server Pages)

• Front의 기능을 이용해서 Java에서 Server단에서 페이지를 만드는 기술
• 결과 페이지를 보여주는 데 사용 (SSR - Server Side Rendering)
• SSR: Server Side Rendering으로 서버단에서 페이지를 랜더링 함
• index.jsp 파일 + thymleaf 기술
• 출력 잘하는 servelt의 변형체

1-3. CGI VS WAS

1. CGI
   

• CGI(Common Gateway Interface)는 동일 프로그램에 대한 요청이 있을 때마다 각각의 프로그램을 실행하여, 요청과 프로그램이 1:1 매칭되어 실행된다.
• 대용량 처리가 가능하다.

2. WAS (Tomcat)
   

• WAS(Web Application Server)는 웹 서버가 웹 애플리케이션 서버에 요청하면, 웹 애플리케이션 서버가 해당 프로그램을 실행하는 방식이다.
• 동일 프로그램에 여러 요청이 있으면 한 개의 프로그램을 실행하여 다수 요청을 처리한다. (multi-thread)
• 대용량 통신 처리에 유용하다.

1-4. Servlet - Controller의 개념

• Java를 Server의 기술로 사용할 수 있도록 한 기술
• spring도 dispatch servlet으로 통신을 함
• localhost:8080으로 우리가 띄어둔 서버에 접속 가능
• front와 service 계층 사이의 Controller ( 요청을 받아서 가공처리 후 응답으로 내보냄)
• HttpServlet을 상속해줘야 Tomcat이 인지하여 응답 & 요청을 할 수 있다.
• Servlet은 요청이 들어오면 하나의 Servlet 객체를 만들어서 사용하는 개념 (Serlvet 객체를 1개만 싱글톤으로 만들어서 계속 이것만 사용)
• 이 Servlet을 관리해주는 것이 Tomcat
  
  

1-4-1. Servlet 라이프 사이클

• 1. Client로 부터 요청들어옴
  2. 해당 요청에 의해 Servlet 객체 하나가 Tomcat에 생성
  3. Servlet객체의 init()를 통해 객체 초기화 (처음 생성시에만 작동)
  4. Service()가 실행되어 service 계층에서 DB와 통신
     => doGet/doPost 메소드를 통해서 통신
  5. Tomcat을 종료하면 destory()로 저장되었던 Servlet을 소멸시킴

• Client로 부터 기존과는 다른 새로운 요청이 들어오면 새로운 Servelt 객체 생성
  => 하나의 Tomcat 서버에서 여러개의 Servlet 객체 관리
  
  

1-4-2. Servlet 동작 방식

0. index.jsp 설정파일

1. XMl

• webapp/WEB-INF/web.xml파일(DD파일)을 통해서 Front의 URL을 통해서 URL을 입력하면 그 해당 화면으로 갈 수 있도록 위와 같이 설정 필요

• localhost:8080/xml-lifeycle을 입력하면 com.ohgiraffers~~ 파일에서 실행한 페이지로 이동
  

• HttpServlet을 상속한 후, override를 통해서 재정의 필요
  
  

2. Annotation

• @WebServlet(value= "jsp 경로 명) 적어주면 이렇게 이동해줌
  
  

3. Service Mehothod

1. Get VS Post
   

• Get은 데이터 조회를 위한 메소드(사용자 입력 정보 URL에 노출 + 용량 작음)
• Get은 1.Pathvariable(~~~/1) 방식과 2. QueryString(~~~?1&~~~?2) 방식 존재
• Post는 데이터를 Insert나 Update를 위한 메소드 (사용자 입력 정보 URL에 노출 X + 용량 큼)
• Post는 Request Body에 담아서 보냄

2. 구현 방식
   

• 사용자로 부터 요청(Request)가 들어오면, Request 객체와 Response 객체가 생성
• 요청시에는 Request 객체에는 사용자가 넘긴 값이 저장, Response 객체에는 응답을 보내줘야할 Request가 들어온 곳의 주소
• 응답시에는 Request는 동일하고, Response 객체에는 주소와 응답 값이 추가로 들어감
  
  

4. QueryStrig

• url에 사용자의 입력값이 key와 value로 담김 (Map<String, String>으로 변환 후 사용 - 모든 값이 String으로 넘어옴)
• ex) localhost:8080/queryString?name=hi&age=3& ~~
• 동일한 key값에 여러개의 value값이 들어오면 배열로 선언됨
• getParameter()를 이용해서 key값을 인자로 넣어주면 value값을 꺼내줌
• <a 태그에 queryString값을 전부 넣어서 보내는 방식도 동일
• Key값을 모르고 여러 개를 꺼낼 경우 Enumeration의 getParameterNames()를 통해 key값을 뽑아내어 사용 가능

5. Request

• Get 요청을 통해서 온 request에는 사용자가 넘긴 값 + 설정정보(HTTP) 포함

• Request Header에 담긴 정보들을 Server에 뽑아 사용( getHeaderNames()를 통해 이름 추출 가능)

• Request Header 종류

  1. General Header
   : 요청 및 응답 모두에 적용되지만 최종적으로는 body에 전송되는 것과는 관련이 없는 헤더이다.
  2. Request Header
  : 패치 될 리소스나 클라이언트 자체에 대한 상세 정보를 포함하는 헤더이다.
  3. Response Header
  : 요청 위치나 서버 응답에 대한 부가적인 정보를 갖는 헤더이다.
  4. Entity Header
  : 컨텐츠 길이나 MIME 타입과 같은 엔티티 바디에 대한 상세 정보를 포함하는 헤더이다.
  (요청 및 응답 모두에서 사용되며, 메시지 body의 컨텐츠를 나타내기에 GET요청은 해당되지 않는다.)
  (Content_Length, Content-Type, Content-Language, Content-Encoding)

  
  

6. Response

• JSP 없이 Server 단에서 response를 보내 화면에 띄우려면 StringBuilder를 이용해서 html파일과 같은 형식으로 만들고 MIME를 사용해 text/html로 지정 필요
  (+ request와는 다른 Stream(통로)를 PrintWriter로 만들어 내보냄)
• Response Header에는 JWT Token정보나 Session 관련 인증 인가에서 사용된다.
  ( + iterator로 반환)
• Respones Header는 Error 처리에 사용되며, 통신의 상태값을 나타내는 status, message,반환결과 등이 담긴다 (ex. 200 OK , 404 NOT FOUND ...)
  
  

7. Exception Handler

• error가 발생하면 request에 사용자가 넘긴 값인 parameter와 error에 관련 정보인 attribute가 넘어온다
• request를 getAttribute()를 통해서 뽑아야 Exception Handler에 사용 가능
  
  

1-4-3. Servlet 전체 구조 및 기능

• 전체적인 흐름 파악 중요!

0. HTTP 프로토콜

• 특징
  1. Stateless (무상태성) : 다른 서블릿은 각 서블릿의 상태를 공유 못함(연결 X) => 이를 해결하기 위해 Forwarding 기술 사용됨
  2. Connectless (무연결성): 요청과 응답이 끝나면 연결을 끊어버림 => 이를 해결하기 위해 Forwarding 기술 사용됨
  
  

1. forward

• 하나의 Tomcat 내부에 여러개의 목적이 다른 servlet 사이에서 값을 주고 받는 개념
• HTTP 프로토콜의 무상태성과 무연결성에 대한 해결책
• 사용자로부터 request를 받는 서블릿에서 작업을 마치고(ex.DB와의 교류) 응답을 잘하는 서블릿으로 상태값인 request와 response 객체를 넘겨주고 응답을 잘하는 서블릿에서 응답을 하도록 하는 개념이 Forwarding 이다.
• Forward 사용시 문제점 => Redirect로 해결
  => Insert와 같이 DB에 영향이 가는 요청일 경우 새로고침 문제점을 해결하지 X
  => client 입장에서는 컨테이너 내부에서 서블릿이 forward가 일어나서 다른 서블릿으로 응답이 온 줄 알지 X
  => Insert요청 중간에 새로고침이 일어나면 계속 insert가 일어나 DB에 큰 영향미침
• forward는 server끼리의 전달이므로, attribute()를 사용(client에서 온 값은 parameter())
• forward를 통해서 다른 서블릿에게 전달시에는 RequestDispatcher를 이용 (dispatcher.forward())
• forward를 받는 서블릿은 client로 붙어 받아온 방식에 맞춰서 선언해줘야함(doGet으로 오면 doGet, doPost로 오면 doPost)
  
  

2. Redirect

• forward의 해결책으로 나온 개념( 새로고침이 일어나도 이미 redirect된 부분으로 요청이 들어감)
• 서블릿1 객체에서 사용한 requset와 response 객체는 redirect가 일어나면 소멸 -> 서블릿 2에게 전달하고 싶으면 queryString,Cookie,Session 방식으로 response에 보냄
• redirect는 url을 받아오는 작업임으로 doGET방식만 사용 가능
• Redirect 발생 흐름
  : 1. client가 서블릿1로 request를 날림
  : 2. 서블릿1에서 처리 완료 후 응답 처리를 잘하는 서블릿2로 가봐!! 하면서 response와 300번대 코드를 전송
  : 3. 브라우저에서 코드를 보고, 서블릿1에서 사용하였던 request와 response를 가지고 다른 서블릿2로 url을 재요청
  : 4. 서블릿2에서 응답을 처리하여 client에게 최종으로 보내주고, 이때 client의 url주소는 서블릿2의 url 주소로 변환
  
  
  

3. Cookie

• redirect가 일어날 때, redirect전 서블릿에서의 request와 response를 cookie에 담아서 가져와 사용 가능
• response Header에 정보를 실어서 Cookie로 관리 요청을 해야 Cookie로 관리 가능(response에 addCookie()를 통해 담아서 요청)
• 쿠키 생성 방법
  : 1. 쿠키 객체 생성
  : 2. 쿠키 만료시간 설정
  : 3. 응답 헤더에 쿠기 담기(addCookie())
  : 4. 응답
• 쿠키 사용 방법
  : 1. request Header에서 쿠키를 배열형태로 꺼냄
  : 2. 꺼낸 쿠키를 getName(), getValue()를 통해서 필요한 key,value값을 꺼내 씀
• 쿠키의 장점과 단점
  : 장점 = 서버의 부담이 줄어듬
  : 단점 = 보안에 취약
  
  

4. Session

• redirect 전에 서블릿에서 값들을 session에 저장하고, redirect시켜서 동일한 JsessionID를 가져오면 redirect된 서블릿에서도 값을 사용이 가능
• 사용자로부터 요청이 들어오면, cookie에 담긴 JsessionID를 통해서 사용자에게 저장할 수 있는 공간을 제공하는 방식 (만료시간 존재)
• 헬스장의 사물함과 동일한 개념
• redirect 시켜도 동일한 JSessionID만 가져오면 동일한 Session을 사용 가능
• 로그인과 같이 사용자별 만료시간을 지정해서 사용하는 값들이 있을 경우 session 사용
• 로그아웃시 강제로 session을 삭제시켜야지 만료시간이 지나기 전에 session을 다시 사용 가능(session.invalidate() 사용)

5. filter

• 요청 전처리 + 후처리 용도
• @WebFilter(경로)를 Annotation에 달아야 filter로 인지해준다.
• dofilter(request, response, filterchain)을 통해 request와 response를 전처리 하고, filterchain의 지정한 필터를 거치고 다음 servlet이나 다음 filter로 가는 구조
• Filter는 Tomcat이 실행되고 Servlet container가 생성되기 전에 먼저 생성된다. (Filter는 Tomcat에서 관리된다.)
• 해당 필터에서 업무를 다 마쳤다면, filterChain.doFilter(servletRequest, servletResponse);를 통해서 꼭 다음 필터나 서블릿으로 전달해줘야 한다.

5-1. filter를 통한 암호화

• filter는 전처리, 암호화등 많은 곳에 쓰이지만 주로 암호화하는데 많이 쓰임
• 비밀번호와 같은 경우에는 사용자에게 입력받는 평문(plain text)를 Bcrypt암호화(단방향 암호화(hash 암호화)- 암호화 O, 복호화 X)를 통해서 다이제스트(digest)로 만들어 암호화 시킨다.
• 암호화(Bcrypt): 평문(plain text) -> 다이제스트(암호화된 문장)
• 복호화(decrypt): 다이제스트(암호화된 문장) -> 평문(plain text)
• servlet에서는 password를 암호화 할때, Wrapper를 통해서 getParameter를 재정의하여 암호화 시키고, 암호화된 password와 사용자가 입력한 password를 확인하기 위해서는 EncryptPasswordEncoder의 matches()를 통해서 비교한다.

6. listener

• Listener를 통해서 하루방문자 수를 구하는데 사용할 수 있다.
• 특정 이벤트나 context(Tomcat 내부에 있는 application의 저장 공간)가 발생하는지 귀를 귀울이고 듣고 있다가 발생을 인지하는 기능
• Listener를 등록할 경우에는 @WebListener가 필요하다.
• Listener를 통해서 어떤 event가 발생하였는지 log를 찍어보는데 사용 가능
• Context라는 저장공간은 servletRequest를 통해서 꺼낼 수 있다.(req.getServletContext())
• HttpSessionBindingListener를 이용해서 해당 클래스의 객체가 session에 저장되었는지 확인하기 위해서 클래스에 직접 Listener를 달기도 한다.