WebMaster

프로젝트 생성 스프링 부트 서블릿 환경 구성 서블릿 등록 에노테이션 추가 서블릿 생성하기 WAS 서버가 request, response 객체를 생성해 준다. 쉽게 QueryParmeter 를 가지고 올 수 있고, response에 데이터를 넣기 쉽다. @WebServlet 서블릿 애노테이션 name: 서블릿 이름 urlPatterns: URL 매핑 Http 요청 메시지 로그 남기기 application.properties에 해당 프로퍼티 추가 logging.level.org.apache.coyote.http11=debug 운영서버에 이렇게 모든 요청 정보를 다 남기면 성능 저하가 발생할 수 있다. 개발 단계에서만 적용하자. 서블릿 컨테이너 동작 방식 설명 초기 웹 애플리케이션 서버의 요청 응답 구조 HT..

과거 기술 서블릿 - 1997 HTML 생성이 어려움 JSP - 1999 HTML 생성은 편리하지만, 비즈니스 로직까지 너무 많은 역할 담당 서블릿, JSP 조합 MVC 패턴 사용 모델, 뷰 컨트롤러로 역할을 나누어 개발 MVC 프레임워크 춘추 전국 시대 - 2000년 초 ~ 2010년 초 MVC 패턴 자동화, 복잡한 웹 기술을 편리하게 사용할 수 있는 다양한 기능 지원 스트럿츠, 웹워크, 스프링 MVC(과거 버전) 현재 사용 기술 애노테이션 기반의 스프링 MVC 등장 @Controller MVC 프레임워크의 춘추 전국 시대 마무리 스프링 부트의 등장 스프링 부트는 서버를 내장 과거에는 서버에 WAS를 직접 설치하고, 소스는 War 파일을 만들어서 설치한 WAS에 배포 스프링 부트는 빌드 결과(Jar)에..

정적 리소스 고정된 HTML 파일, CSS, JS, 이미지, 영상 등을 제공 주로 웹 브라우저 HTML 페이지 동적으로 필요한 HTML 파일을 생성해서 전달 웹 브라우저: HTML 해석 HTTP API HTML이 아니라 데이터를 전달 주로 JSON 형식 사용 다양한 시스템에서 호출 데이터만 주고받음, UI 화면이 필요하면, 클라이언트가 별도 처리 앱, 웹 클라이언트, 서버 to 서버 다양한 시스템 연동 주로 JSON 형태로 데이터 통신 UI 클라이언트 접점 앱 클라이언트(아이폰, 안드로이드, PC 앱) 웹 브라우저에서 자바스크립트를 통한 HTTP API 호출 React, Vue.js 같은 웹 클라이언트 서버 to 서버 주문 서버 -> 결제 서버 기업 간 데이터 통신 서버사이드 렌더링, 클라이언트 사이드 ..

스레드 애플리케이션 코드를 하나하나 순차적으로 실행하는 것은 스레드 자바 메인 메서드를 처음 실행하면 main이라는 이름의 스레드가 실행 쓰레드가 없다면 자바 애플리케이션 실행이 불가능 스레드는 한 번에 하나의 코드 라인만 수행 동시 처리가 필요하면 스레드를 추가로 생성 단일 요청 - 쓰레드 하나 사용 다중 요청 - 쓰레드 하나 사용 요청마다 스레드 생성 요청마다 스레드를 생성해서 다중 요청을 해결할 수 있지만 장점/ 단점이 있다. 장점 동시 요청을 처리할 수 있다. 리소스(CPU, 메모리)가 허용할 때까지 처리 가능 하나의 스레드가 지연되어도, 나머지 스레드는 정상 동작한다. 단점 쓰레드는 생성 비용은 매우 비싸다. 고객의 요청이 올 때마다 스레드를 생성하면, 응답 속도가 늦어진다. 쓰레드는 컨텍스트 ..

HTML Form 데이터 전송 만약 내가 WAS를 직접 구현한다면? 비즈니스 로직보다, 외적인 부분을 해야 하는 것이 많다 (비효율적이다) 이를 해결하기 위해 서블릿이 나타났다. 서블릿 urlPatterns(/hello)의 URL이 호출되면 서블릿 코드가 실행 HTTP 요청 정보를 편리하게 사용할 수 있는 HttpServletRequest HTTP 응답 정보를 편리하게 제공할 수 있는 HttpServletResponse 개발자는 HTTP 스펙을 매우 편리하게 사용 HTTP 요청 시 WAS는 Request, Response 객체를 새로 만들어서 서블릿 객체 호출 개발자는 Request 객체에서 HTTP 요청 정보를 편리하게 꺼내서 사용 개발자는 Response 객체에 HTTP 응답 정보를 편리하게 입력 W..

웹 서버 HTTP 기반으로 동작 정적 리소스 제공, 기타 부가기능 정적(파일) HTML, CSS, JS, 이미지, 영상 예) NGINX, APACHE 웹 애플리케이션 서버(WAS) HTTP 기반으로 동작 웹 서버 기능 포함+ (정적 리소스 제공 가능) 프로그램 코드를 실행해서 애플리케이션 로직 수행 동적 HTML, HTTP API(JSON) 서블릿, JSP, 스프링 MVC 예) 톰캣(Tomcat) Jetty, Undertow 웹 서버, 웹 애플리케이션 서버(WAS) 차이 웹 서버는 정적 리소스(파일), WAS는 애플리케이션 로직 사실은 둘의 용어도 경계도 모호함 웹 서버도 프로그램을 실행하는 기능을 포함하기도 함 웹 애플리케이션 서버도 웹 서버의 기능을 제공함 자바는 서블릿 컨테이너 기능을 제공하면 WA..

확실한 캐시 무효화 응답 Cache-Control: no-cache, no-store, must-revalidate Pragma: no-cache HTTP 1.0 하위 호환 Cache-Control: no-cache 데이터는 캐시 해도 되지만, 항상 원 서버에 검증하고 사용(이름에 주의!) Cache-Control: no-store 데이터에 민감한 정보가 있으므로 저장하면 안 됨 (메모리에서 사용하고 최대한 빨리 삭제) Cache-Control: must-revalidate 캐시 만료후 최초 조회 시 원 서버에 검증해야 함 원 서버 접근 실패시 반드시 오류가 발생해야 함 - 504(Gateway Timeout) must-revalidate는 캐시 유효 시간이라면 캐시를 사용함 Pragma: no-cach..

Cache-Control: public 응답이 public 캐시에 저장되어도 됨 Cache-Control: private 응답이 해당 사용자만을 위한 것임, private 캐시에 저장해야 함(기본값) Cache-Control: s-maxage 프록시 캐시에만 적용되는 max-age Age: 60 (HTTP 헤더) 오리진 서버에서 응답 후 프록시 캐시 내에 머문 시간(초)

Cache-Control: 캐시 제어 Cache-Control: max-age 캐시 유효 시간, 초 단위 Cache-Control: no-cache 데이터는 캐시 해도 되지만, 항상 원(origin) 서버에 검증하고 사용 Cache-Control: no-store 데이터에 민감한 정보가 있으므로 저장하면 안 됨 (메모리에서 사용하고 최대한 빨리 삭제) Pragma 캐시 제어(하위 호환) Pragma: no-cache HTTP 1.0 하위 호환 Expires 캐시 만료일 지정(하위 호환) expires: Mon, 01 Jan 1990 00:00:00 GMT 캐시 만료일을 정확한 날짜로 지정 HTTP 1.0 부터 사용 지금은 더 유연한 Cache-Control: max-age 권장 Cache-Control:..

캐시 유효 시간이 초과해서 서버에 다시 요청하면 다음 두 가지 상황이 나타난다. 서버에서 기존 데이터를 변경함 서버에서 기존 데이터를 변경하지 않음 캐시 만료 후에도 서버에서 데이터를 변경하지 않음 생각해보면 데이터를 전송하는 대신에 저장해 두었던 캐시를 재사용할 수 있다. 단 클라이언트의 데이터와 서버의 데이터가 같다는 사실을 확인할 수 있는 방법 필요 검증 헤더 추가 첫 번째 요청 두 번째 요청 캐시 유효 시간이 초과해도, 서버의 데이터가 갱신되지 않으면 304 Not Modified + 헤더 메타 정보만 응답(바디 X) 클라이언트는 서버가 보낸 응답 헤더 정보로 캐시의 메타 정보를 갱신 클라이언트는 캐시에 저장되어 있는 데이터 재활용 결과적으로 네트워크 다운로드가 발생하지만 용량이 적은 헤더 정보만..