개발자되기 프로젝트

1. REST - Representational State Transfer: 자원의 상태 전달 Client, Server: 클라이언트와 서버가 서로 독립적으로 분리되어 있어야 한다. Stateless: 요청에 대해서 클라이언트의 상태를 서버에 저장하지 않는다. Cache: 클라이언트는 서버의 응답을 캐시할 수 있어야 한다. 클라이언트가 캐시를 통해서 응답을 재사용 할 수 있어야 하며, 이를 통해서 서버의 부하를 낮춘다. Layered System(계층화): 서버와 클라이언트 사이에 방화벽, 게이트웨이, Proxy 등 다계층 형태를 구성할 수 있어야 하며, 확장할 수 있어야 한다. 인터페이스의 일관성: 아키텍처를 단순화 시키고 작은 단위로 분리하여서, 클라이언트 , 서버가 독립적으로 개선될 수 있어야 한다..

1. 서블릿 특징 @WebServlet(name = "helloServlet", urlPatterns = "/hello") public class HelloServlet extends HttpServlet { @Override protected void service(HttpServletRequest request, HttpServletResponse response){ //애플리케이션 로직 } } urlPatterns(/hello)의 URL이 호출되면 서블릿 코드가 실행 HTTP 요청 정보를 편리하게 사용할 수 있는 HttpServletRequest request객체에서 원하는 정보 꺼내면 됨. HTTP 응답 정보를 편리하게 제공할 수 있는 HttpServletResponse 원하는 정보를 Respon..

1. 확실한 캐시 무효화가 가능한 응답 브라우저가 임의로 캐시하는 경우가 있음 만약 이 페이지는 진짜 캐시 되면 안돼!!!!멈춰!! 하고싶으면 아래 헤더 필요함. Cache-Control: no-cache, no-store, must-revalidate Pragma: no-cache 과거 브라우저가 있을 수 있으니.. 2. 캐시 지시어 - 확실하게 캐시 무효화 하는 방법 Cache-Control: no-cache - 데이터는 캐시해도 되지만, 항상 origin 서버에 검증하고 사용(이름.. ㅎㅎ주의) Cache-Control: no-store - 데이터에 민감한 정보가 있으니 저장하지마 - 메모리에서 사용하고 삭제 Cache-Control: must-revalidate - 캐시 만료 후 최소 조회 시 o..

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

1. 캐시 제어 헤더 Cache-Control: 캐시 제어 Pragma: 캐시 제어(하위 호환을 위해서 씀. 대부분 Cache-Contorl로 처리 가능) Expires: 캐시 유효 기간(하위 호환을 위해서 씀. 대부분 Cache-Contorl로 처리 가능) 2. Cache-Control Cache-Control: max-age 캐시 유호 시간. 초 단위 설정 가능 Cache-Control: no-cache 데이터는 캐시해도 되지만, 조건부 요청을 통해 항상 원(origin)서버에 검증하고 사용 캐시를 해도 되긴되는데, If-Modified-Since 나 If-Non-Match를 사용하여 무조건 검증해야함. Cache-Control: no-store 데이터에 민감한 정보가 있으니, 저장하면 안됨! 보통 ..

1. 검증 헤더 캐시 데이터와 서버 데이터가 같은지 검증하는 데이터 Last-Modified, ETag 2. 조건 부 요청 헤더 검증 헤더로 조건에 따른 분기 If-Modified-Since: Last-Modified 사용 If-None-Match: ETag 사용 조건이 만족하면 200 OK 조건이 만족하지 않으면 304Not Modified 3. If-Modified-Since 사용 예시 서버측 데이터 미 변경 시 - 캐시 : 2020년 11월 10일 10:00:00 vs 서버 : 2020년 11월 10일 10:00:00 - 해당 조건이 만족하지 않으니 304 Not Modified 및 헤더 데이터만 전송(Body 없음) - 3xx : 리다이렉션? 어디로? 캐시로! 서버측 데이터 변경 시 - 캐시 : ..

1. 캐시 유효 시간이 초과한 경우..? 캐시 유효 시간이 초과하여 서버에 재 요청했을 때 서버는 둘 중 한 가지 상황이다. 서버에서 기존 데이터를 변경함 서버에서 기존 데이터를 변경하지 않음. 2. 서버에서 데이터를 변경하지 않은 경우 캐시 만료 이후에 서버에서 데이터를 변경하지 않음 이 경우에는 캐시를 사용할 수 있을 것 같은데...? 단, 클라이언트의 데이터와 서버의 데이터가 같은지 검증이 필요함. 검증헤더가 필요해 3. 검증헤더, 조건 부 요청 : Last-Modified, If-modified_since 클라이언트의 요청에 대한 응답으로 서버에서 응답을 줄 때 Last-Modified: 2021년 08월 04일 22:00:00 과 같이 마지막으로 수정된 시각 전달 가능. 응답을 받은 브라우저는 ..

1. 캐시가 없을 때 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운받아야 한다...ㅜ 인터넷 네트워크는 느리고 비쌈... 브라우저 로딩 속도가 느려.. ??? : 왜이렇게 느려???? 2. 캐시 적용 캐시 덕분에 캐시 가능 시간동안 네트워크를 사용하지 않아도 된다. 비싼 네트워크 사용량을 줄일 수 있음 ㄱㅇㄷ 브라우저 로딩 속도가 매우 빠름 ??? : 편 ㅡ 안 브라우저에는 캐시 저장소 있음. 처음 요청시 서버는 캐시가 유효한 시간을 헤더에 담아서 보낼 수 있음 cache-control: max-age=60 --> 60초 동안 캐시 유효 브라우저는 응답 결과를 캐시에 저장. 동일 요청을 클라이언트가 다시 요청을 할 때 캐시를 사용하면됨. 3. 캐시 시간 초과된 경우...? 캐시 시간 초과..