일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- 알고리즘
- java
- Spring Boot
- jpa
- pointcut
- AOP
- Android
- 스프링 핵심 원리
- Proxy
- 김영한
- Exception
- transaction
- 스프링
- 자바
- db
- 그리디
- JPQL
- http
- 인프런
- spring
- kotlin
- Greedy
- springdatajpa
- Thymeleaf
- 스프링 핵심 기능
- SpringBoot
- QueryDSL
- JDBC
- Servlet
- 백준
- Today
- Total
목록인프런 (528)
개발자되기 프로젝트
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. 캐시 시간 초과된 경우...? 캐시 시간 초과..
Set - Cookie: 서버에서 클라이언트로 쿠키 전달(응답) Cookie: 클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP 요청시 서버로 전달. 0. Stateless, Connectionless HTTP의 특징은 Stateless, Connectionless이다. 즉 서버와 클라이언트는 서로의 상태를 유지하지 않고, data 전송 수 연결을 종료한다. 이와 같은 특징으로 아래와 같은 상황에서 문제..? 불펴함..? 이 발생할 수 있다. 무상태(stateless) 프로토콜 서버가 클라이언트이 상태를 보존하지 않음 장점 : 서버 확장성 높음, 스케일 아웃 단점 : 클라이언트가 추가 데이터 전송필요. 1. 상태 유지 :Stateful 서버가 클라이언트의 이 전 상태를 보존 2. 무 bsh-devel..
Authorization: 클라이언트 인증 정보를 서버에 전달 WWW-Authenticate: 리소스 접근시 필요한 인증 방법 정의 1. Authorization : 클라이언트 인증 정보를 서버에 전달 Authorization: Basic xxxxxxxxxxxx 인증 종류마다 값이 달라짐 HTTP 에서 어떤 인증인지 관계없이 헤더 제공 2. WWW-Authenticate : 리소스 접근시 필요한 인증 방법 정의 리소스 접근시 필요한 인증 방법 정의 401 Unathorized 응답과 함꼐 사용 WWW-AUthenticate: Newauth realm='apps', type=1, title="Login to\"apps\"", Basic realm="simple"