Socket : 운영체제가 가지고 있는 것!
소켓 통신 : 타임슬라이스(쓰레드), 동시동작
=> 부하가 심함 (낭비)
http 통신 : stateless 방식
=> 부하가 적음 but 연결을 매번 새로 해야돼서 구분하기 힘듦
http는 요청(request)에만 응답(response)이 가능
개인 컴퓨터에서 중앙 서버에 request 시 => ( IP주소, URL ) 중앙 서버에 알려줌 => 중앙 서버에서 IP주소를 토대로 개인 컴퓨터에 응답 가능 but 중앙 서버에서 개인 컴퓨터에 요청을 하려면 소켓 통신이 필요함
웹서버 : 아파치 (정적) + 톰캣 (동적)
톰캣 : JSP -> Java -> 컴파일 -> html (JSP를 html 파일로 변환)
=> 웹브라우저가 JSP 파일을 인식 못함 (Html, Css, JavaScript 등만 인식)
아파치 : html 응답
서블릿 컨테이너
URL : 자원 접근 X ex) http://naver.com/a.png
URI : 식별자 접근 ex) http://naver.com/picture/a
특정한 파일을 요청 X , 요청시에 무조건 자바를 거침
- request (Java 자원)
-> 2. 서블릿 컨테이너 (톰캣) 서블릿 객체(1) 만듦
-> 3. 필요한 메서드 호출
-> 4. 스레드 생성(몇 백개도 가능)
-> 5. response 하고 또 호출 되면 해당 스레드 재사용
ex) 100명 - 스레드 100개
scale-up => 성능 개선 (쓰레드 수 늘림)
scale-out => 수평적 확장 (컴퓨터 수 늘림)
web.xml (웹 배포서술자) => 문지기 : 웹서버에 처음 진입할 때 최초로 검증
1) ServletContext의 초기 파라미터 설정 (암구호)
2) Session(자격)의 유효시간 설정
3) Servlet/JSP에 대한 정의, 매핑
4) Mime Type 매핑 => 어떤 Data Type인지 알아야 하고 가공해야함
5) Welcome File list => 어떠한 목적도 없이 왔을 때 한 곳에 모아둠
6) Error Pages 처리 => 이상한 주소에 가려고 할 때 (error page)
7) 리스너/필터 설정
=> 필터 : 걸러내는 효과
=> 리스너 : 새로운 문지기 (특정적인 것만 고려)
8) 보안
Dispatcher Servlet (Request Dispatcher + FrontController 패턴)
BufferedReader에서 가변길이의 문자를 받으면 tomcat이 객체(request,response)로 만들어줌
특정 주소를 FrontController가 필요한 클래스에 넘겨줌 (web.xml에서 다 정의하기 힘들기 때문에)
=> 새로운 요청이 생기기 때문에 request와 response가 새롭게 new 가능
so RequestDispatcher 필요
RequestDispatcher => request와 response를 그대로 유지 (기존의 request를 재사용) -> 데이터를 들고 페이징 이동을 하기 위함
Spring Container (ApplicationContext)
Spring에서는 무조건 동적파일(java 파일 : servlet) 요청
톰캣 실행시 -> web.xml -> Context Loader Listener -> root-context.xml (applicationContext.xml) 읽어짐 -> request
-> Dispatcher Servlet (servlet-context.xml) (컴포넌트 스캔) -> 주소분배
ex) 톰캣 실행되면 문지기가 xml파일을 읽고 자기가 해야할 일(DB에 관련된 애들을 메모리에 띄움)을 하고 주민(사용자 요청)이 들어오면 DispatcherServlet이 문지기가 해야할 일을 FrontController 패턴으로 분배해서 대신 일(Web과 관련된 애들을 메모리에 띄움)을 하고 주소 분배를 하고 주민(응답)들이 나갈 때 Data로 나갈지 Html 파일로 나갈지 리턴할지 결정하고 정상적인 로직이 실행됨
Context Loader Listener (root-ApplicationContext 파일)
=> 공통적으로 사용가능한 것들을 메모리에 띄움 (DB에 관련된 것=> DAO,Service,Vo)
Scan (메모리에 로딩)
Dispatcher Servlet => 어노테이션(@Service, @Controller등)이 있으면 메모리에 띄움
Bean Factory => 초기에 메모리에 로드 되지 않고 필요할 때마다 getBean()이라는 메서드롤 통해서 호출하여 메모리에 로드
(ApplicationContext 와 다른점은 미리 로드 되지 않고, 필요할 때 호출하여 로드하기 때문에 Lazy-loading)
요청 주소에 따른 적절한 컨트롤러로 요청(HandlerMapping)
응답 => Data나 HTML 파일을 응답할지 결정
Data -> MessageConverter가 작동하여 메시지 컨버팅 (json)
현재는 MessageConverter(jackson)
Html -> ViewResolver가 관여
위의 내용은 최주호님의 인프런 '스프링부트 개념정리' 내용을 참조했습니다.
