이미지 같은 자원들은 한번 요청을 해서 응답이 나가면 브라우저가 캐시에 저장함.
이미지 새로고침으로 다시 요청하면 200->304로 바뀜. 이미 한번 캐싱이 됬다.
-> 서버상에서 자원이 바뀌어도 한번캐싱한거 계속 쓰려고 하는 특성이 있어서 잘 안바뀌는 때도 있음
=> 캐싱이 되지 않도록 해야함
1. 동적인 리소스인것처럼 만들기. 동적인 요소 넣어주기. -> 불편
2. response header를 이용해서 직접적으로 제어.
캐시제어 문제
- 서버상에서 데이터가 갱신되도 잘 반영이 안됨
- 캐시는 브라우저에 저장되기 때문에 클라이언트 사이드이다. -> 파일 형태로 저장되는데(브라우저 안에) 어디에 저장되는지만 찾으면 누구나 다 볼 수 있다 -> 정보 유출
캐시 관련 헤더
- Cache-Control(HTTP/1.1)
- Pragma(HTTP/1.0)
- Expires(만료시간)
Cache-Control, Pragma는 같은 얘기인데 버전의 차이. 캐시 쓸건지 안쓸건지.
항상 결정은 클라이언트가 함. 서버는 클라이언트가 어떤 브라우저나 시스템을 사용할지 모름. -> 웹표준화해야됨. 어떤 버전을 사용하든지 다 동작되게.
캐시는 저장소를 빌려쓰는 개념. 계속 저장해놓을 수가 없고 만료기간이 있음
- cacheControl.jsp
< script src="sample.jsp"></ script>script의 바디안에 넣어라-> sample.jsp는 자바스크립트 코드여야 함
도큐먼트 부분 지워야됨. 들어가면 안되고 들어갈수도 없음
refresh
실행하면
실시간으로 보려면 매번 요청 보내야됨
-> 1초마다 자동 요청이 발생해야 함
refresh 헤더. 1초마다 서버에서 데이터가 갱신되고 있으니까 1초마다 받아야되
현재 페이지를 리로딩하겠다 - 동기에서만 사용. 바뀌지 않는 부분까지 바뀔필요 없음 => 위 3가지 방법으로 처리
클라이언트 방식으로 refresh. 응답데이터가 나간 다음에 브라우저가 해석을 하니까 클라이언트 방식
equiv. 5초뒤에 새로고침이 됩니다..리뉴얼 메세지 이 방식으로 대부분 처리됫음
이 헤더 이용하면 페이지 새로고침 할 수 있음. -> 5초 후에 네이버로 새로고침.
자바스크립트 스케줄링 함수
interval - 주기 설정하고 주기마다 반복.
timeout - 지연시간 설정. 그 시간동안 아무것도 안하다가 그뒤에 한번실행
1초마다 페이지 리로딩-주기설정. 동기방식.
단점 : 전체가 리로딩된다.
동기방식 정리
- refresh헤더
- meta http-equiv
- location.reload()
비동기 요청
- ajax(XMLHttpRequest API)
- fetch API(Promise)
- eventsource
1. ajax 방식
ajax코드 매번쓰기 귀찮아서 ctrl+space눌렀을때 나오게 등록함.
시간 : 요청 보내서 응답 나간 시간
-> 1초마다 시간 바뀌게 하고 싶음 -> ajax를 1초마다 호출하면 됨 - 주기 : setInterval()
polling - 서버사이드의 자원을 가져오는 것
우리가 지금 쓰는 것 - Long Polling방식. http 1.1에서 많이 씀..?
서버 입장에서는 매 1초마다 새로운 요청 보내고 있음. 그게 10000명이라면?
-> Long Polling방식의 단점.
1. 서버 부하
2. 1초 미만으로 갱신되는 데이터는 확인 불가. 1초와 1초 사이에 데이터가 갱신되면 그 데이터는 가져올 수 없음. 실시간인척한것.
=> 해결
1. webSocket.
2. 서버센트이벤트 ServerSentEvent
ajax-jquery없으면 못씀
jquery없어도 쓸 수 있는 비동기요청 => fetch
2. fetch 방식
promise객체로 넘어옴. 약속 - 나중에 뭐 하겠다.
1초마다 getServerTime.jsp로 요청이 발생해 콘솔에 쌓임.
__proto__밑에 있는 메서드로 바디 접근함. 마샬링, 언마샬링 고려 안하고 응답 그대로 들어옴. 라인, 헤더 바디 다 있음 -> json()으로 우리가 언마샬링 해줘야됨.
ajax와 fetch()차이
fetch()는 데이터 타입 제한이 없음. - blob()
서버에서 보내주는 데이터가 1기가 - 한번에 전송 못함. 받을 수 있는 만큼으로 쪼개서 받음. 낱개 데이터(청크). 청크 데이터가 다 나가야 응답데이터가 됨.
- 응답데이터는 여러개의 청크로 나눠져서 들어온다!
한번에 return data하는게 아니라 모아서 promise객체로 넘김
xhr없음. 이거 있고 없냐로 비동기요청인지 확인 못함 - 그때 비동기인지 아닌지가 중요한게 아니라고 했음..
패치도 롱폴링. 부하 많이걸린다.
SSE : serversentevent
여기서 event는 건바이건 데이터.
promise는 한번 요청오면 끝나기 때문에 then해줫던것. eventSource는 계속 연결되있기 때문에 promise안 맞음
sse - 클라이언트는 서버에게 요청을 보낼 수 없고 서버에서 계속 푸쉬할수있음 -> websocket과 차이점
- getServerTime_SSE.jsp
그냥 데이터 내보내면 얘가 뭔지 모름-식별자 붙여서 내보냄
데이터, 데이터 건을 구별할때는 엔터 두개. 그냥 하나는 한개의 데이터임
저 화살표는 엔터 한번한거
근데 엔터 두번치면 line data가 안나옴..뭐지???
그냥 쓰면 처음에 한번 실행되고 끝남 - while
pending-기다리는중. 얘는 close하기 전까지 연결안끊김
아무 이벤트도 발생하지 않음
->버퍼때문에. 버퍼 다 안차서
flush()로 방출해줌.
연결은 한번만 하고 서버쪽에서 계속 요청 보냄.
->sse와 long polling차이.
이벤트 발생 안함. test라는 이벤트 없어서->이번트 추가해줌
자바스크립트 방식과 jquery방식의 event 객체가 완전히 다름
- jquery
sse가 서버 입장에서는 부하가 덜 걸림
단점 - 연결 계속 유지됨. 대부분의 클라이언트는 잠깐 사용했다가 떠남-> 적절한 시점되면 연결 끊어줘야됨.
<오늘 한것>
-
자바스크립트에서 요청을 발생시키는 방법
스케줄링 함수 구분 분명히!!- setInterval()
- setTimeout()
-
refresh헤더 - 동기요청. 페이지 전체에 대해 refresh
-
비동기에서는 refresh헤더 무시되고 사용안됨.
1) Long polling(ajax, fetch) - 서버 부하
2) serversentevent
상황에 따라 써야되는거 다름. 무조건 2번만이 좋은게 아님.
★ 모듈라 사이트 도큐먼트 보는법
추가로(다음날 복습한거)
success는 응답데이터가 완전히 다 오면 실행됨. -> done으로 빼는 경우도 있다.(fetch처럼). success는 성공했을때만인데 done은 응답이 다 오면 실행되서 성공, 실패 다 포함. -> error:도 없어도 됨.
성공, 실패에 대한 정보 다 갖고 있어야 되서 xhr이 들어와야됨.
promise객체가 어떻게 동작하는지를 잘 이해
serversentEvent에서 이벤트는 건건의 데이터를 말한다.
서버에서 데이터가 stream(흐름)으로 가야됨. -> 마임도 text/event-stream
흐름이기 때문에 건건의 데이터를 구별할 수 있어야 됨 - 엔터 두개.
서버에서 데이터가 계속 만들어서 오고 있음-refresh에서 서버에서 오는 건건의 데이터를 처리할 수 있어야 함-> eventListener메서드
SSE 단점 : 클라이언트에서 서버로는 못보냄. serversent라서
=> websocket 사용
