캐시 무효화 확실한 캐시 무효화 응답 Cache-Control:no-cache, no-store, must-revalidate Pragma:no-cache HTTP 1.0 하위 호환 국내 네이버 국외 구글 통장잔고 (중요한 업데이트 => 캐시 x) must-revalidate 캐시 만료후 최초 조회시 원 서버에 검증 no-cache로 원 서버에 요청을 보낼 경우 (정책) 그런데 순간적으로 프록시 캐시-> 원 서버에 네트워크 문제가? 프록시 캐시 : 오류가 나는 거보다 오래된 데이터를 보여준다. must-revalidate는? 오래된 데이터를 보여 줄 이유는 없어. 그러니 오류가 나는 게 맞아! 504 GateWay Timeout 통장잔고의 과거 데이터를 보여줄 수는 없다.
Cache-Control 캐시 제어 캐시 관련된 헤더 Cache-Control: max-age 캐시 유효 시간, 초 단위 Cache-Control: no-cache 데이터는 캐시해도 되지만, 항상 원 서버에 검증하고 사용 원 서버(캐시 프록시 서버 => my server) 조건부 요청을 해서 로컬에 있는 캐시 데이터를 무조건 검증하고 쓴다는 의미 Cache-Control: no-store 데이터에 민감한 정보가 있으므로 캐시에 저장 x pragma, expires(캐시 만료일 지정하긴 하는데... 초단위가 훨씬 유연함) 프록시 캐시 한국 클라이언트 한국어딘가에 있는 프록시 캐시 서버 원 서버 첫번째 요청은 느림. 그러나 두 번째 부터는 빠름. private 캐시(웹브라우저, 로컬에 저장되는 캐시) pub..
Last-Modified, ETag 조건부 요청 헤더 검증 헤더로 조건에 따른 분기 if-modifeid-since: Last-Modified 사용 if-none-match: ETag 사용 조건이 만족하면 200 OK 조건이 만족하지 않으면 304 Not Modified 즉 변경이 안 일어난 경우 수정안되었다라는 정보 전달 Last-Modified의 단점은 날짜 기반의 로직 1초 미만 단위로 캐시 조정 불가능 ( 초단위로 조정하기 때문에 ) 데이터를 수정해서 날짜가 다르지만 같은 데이터를 수정해서 데이터 결과가 똑같은 경우 서버에서 별도의 캐시 로직을 다루고 싶은 경우 이러한 단점을 상쇄하는 ETag 캐시용 데이터에 임의의 고유한 버전 이름을 달아둠 데이터가 변경되면 이 이름을 바꾸어서 변경함 진짜 단순..
캐시 기본 동작 캐시가 없으면 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받는다. 인터넷 네트워크는 매우 느리고 비싸다. 브라우저 로딩 속도가 느리다. 느린 사용자 경험. 캐시 적용 cache-control max-age를 통해 캐시의 시간을 적용한다. 위의 모든 단점이 상쇄된다. 캐시 시간 초과 기존에 있던 데이터를 지우고 응답받은 캐시 적용할 캐시 데이터를 다시 저장한다. 클라이언트가 가진 데이터가 똑같은데 굳이 다시 다운을 받아야 할까? 2가지 상황 서버에서 기존 데이터를 변경함 서버에서 기존 데이터를 변경하지 않음 검증 헤더 조건부 요청 검증 헤더와 조건부 요청 데이터를 다 전송하는 거 대신에 로컬 캐시를 쓸 수 없나? 클라이언트와 서버의 캐시데이터가 바뀌지 않았는가에 대한..
쿠키 Set-Cookie: 서버에서 클라이언트로 쿠키 전달(응답) Cookie: 클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP 요청시 서버로 전달 쿠키 로직 웹브라우저에서 로그인 요청을 해서 서버가 받아들이면 Set-Cookie를 통해 웹브라우저 내에 쿠키 저장소에 유저정보를 저장한다. 쿠키는 모든 요청에 쿠키 정보를 자동 포함한다. 쿠키 설명 예) set-cookie: sessionId=abcde1234; expires=Sat, 26-Dec-2020 00:00:00 GMT; path=/; domain=.google.com; Secure 사용처 사용자 로그인 세션 관리 광고 정보 트래킹 쿠키 정보는 항상 서버에 전송 네트워크 트래픽 추가 유발 그래서 최소한의 정보만 사용(세션 id, 인증 토큰) ..
HTTP 헤더 표준(RFC723x) 메시지 본문을 통해 표현 데이터 전달 메시지 본문 = 페이로드 표현 = 표현 헤더 + 표현 데이터 표현은 요청이나 응답에서 전달할 실제 데이터 표현 헤더는 표현 데이터를 해석할 수 있는 정보 제공 데이터 유형, 데이터 길이, 압축 정보 등등 참고 : 표현 헤더는 표현 메타데이터와 페이로드 메시지를 구분해야 하지만 여기선 생략! 표현 Content-Type : 표현 데이터의 형식 Content-Encoding : 표현 데이터의 압축 방식 데이터를 읽는 쪽에서 인코딩 헤더의 정보로 압축 해제 Content-Language : 표현 데이터의 자연 언어 Content-Length : 표현 데이터의 길이 (페이로드 헤더) 표현 헤더는 전송, 응답 둘다 사용 협상(콘텐츠 네고시에..
3xx(Redirection) 클라이언트가 서버에게 요청을 하는데 서버가 클라이언트에게 추가 조치를 필요하다고 재요청 리다이렉션 Old Location->New Location을 서버가 응답 클라이언트는 자동 리다이렉트를 통해 새로운 페이지를 다시 요청함 서버가 새로운 Location 응답 리다이렉션 이해 영구 리다이렉션 특정 리소스의 URI가 영구적으로 이동 일시 리다이렉션 일시적인 변경 주문 완료 후 주문 내역 화면으로 이동 PRG : Post/Redirect/Get 특수 리다이렉션 결과 대신 캐시를 사용 영구 리다이렉션 301, 308 리소스의 URI가 영구적으로 이동 원래의 URL를 사용X, 검색 엔진 등에서도 변경 인지 대부분 301의 로직을 따르며 GET으로 변경되어질 수 있고 본문이 제거될 ..
HTTP 메서드 활용 클라이언트에서 서버로 데이터 전송 데이터 전달 방식 쿼리 파라미터를 통한 데이터 전송 GET 정렬 / 필터 메시지 바디를 통한 데이터 전송 POST, PATCH, DELETE 리소스 등록, 변경 등 클라이언트에서 서버로 데이터 전송하는 4가지 상황 정적 데이터 조회 이미지, 텍스트 문서 동적 데이터 조회 정렬, 필터 HTML form HTTP API Server to Server 앱 클라이언트 아이폰, 안드로이드 웹 클라이언트 Ajax HTTP API 설계 설계 방법 문서 단일 개념(파일 하나, 객체 인스턴스, 데이터베이스 row) HTTP API - 컬렉션 POST 기반 등록 서버가 관리하는 리소스 디렉토리 서버에서 새로 등록된 리소스 Location URI를 만듦 예) 회원 관리..
- Total
- Today
- Yesterday
- https://react.vlpt.us/basic/11-render-array.html
- https://jwprogramming.tistory.com/52
- ㄴ
- https://wikidocs.net/68
- https://subicura.com/2017/01/19/docker-guide-for-beginners-1.html
- Co
- https://react.vlpt.us/
- https://velog.io/@juno7803/React%EA%B0%80-%ED%83%9C%EC%96%B4%EB%82%9C-%EB%B0%B0%EA%B2%BD
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |