웹소켓, 서버 사이드 이벤트?
웹소켓도 HTTP1.0에서는 사용 X
304 정적 자원에 주로 쓰임!
네이버 맨 처음 캐시가 없어서 느린데
그 이후는 캐싱으로 정적자원이 저장되어있어서 두번째 이후부터는 빠르게 로딩되는것
오늘 수업의 핵심은 3XX대 코드를 알아보는것
304 -> 캐싱의 문제점 서버사이드에서 데이터가 변경되더라도 적용하기가 쉽지 않다?
어떤경우에 문제가 생기냐 이게
200
새로 고침 -> 304
바로바로 되도록하려면 캐싱안되게 해야한다.
자바스크립트가 동적리소스인 것처럼 인식하게한다.
- 이렇게 하면 매번 새로 인식하나 불편하다.
캐쉬의 단점 : 누구나 접근 가능하다.
2가지?
참고 : https://feel5ny.github.io/2019/09/30/HTTP_007-1/
우린 클라이언트가 어떤 버전을 사용할지 모르기 때문에 웹표준화 전략에 따라 웹 전략성을 보장하려면 버전에 구애 받지 않아야한다.
참고 : https://developer.mozilla.org/ko/docs/Web/HTTP/Headers/Cache-Control
헤더에 설정한 것 확인해 보기
이러면 캐싱을 하지 않는 것
가장 좋은 것은 필터에서 해버리면 정적자원에 대한 캐싱을 걱정하지 않아도 된다.
비동기 요청 3가지
1. ajax API
2. fetch api - Promise
3. EventSource API
서버의 시각 -> 서버사이드 모듈을 사용해야한다.
이건 서버사이드가 아님 그냥 한번 찍힌것
계속갱신이 되는 데이터를 실시간으로 가져올 것인가? 라는 의문 적어도 1초 마다 한번씩 새로고침?(1초마다 한번씩 자동으로 요청)
ajax 템플릿 만들어 주기 ajaxCode로 불러쓸 수 있다.
Long Polling : 서버 측에서 접속을 열어두는 시간을 길게하는 방식
Polling : 서버사이드에 있는 데이터를 가져오는 것
HTTP/1.0에서 주로 사용
단점 : 요청하는 단말이 많아지면 부하가 심해진다.
진짜 실시간이 아니라 실시간인 것 처럼 보이는 것
그 주기내에 갱신되는 데이터는 확인이 불가능하다
그래서 보완한 것
1. 웹소켓
갱신될때마다 계속 보내줌
2. server-sent events
fetch API
제이쿼리없으면 AJAX 못쓰니 HTTP/1.1에서 지원하는 방식
ajax는 콜백함수를 지정하는데
fetch는 Promise라는 객체로 넘어온다.
나중에 ~것을 하겠다 라는 것이다.
then(콜백함수)성공, false(콜백)실패
fetch()에서는 마샬링/언마샬링 여부가 고려되지 않음 그래서 이때 사용하는게 바로 json이라는 함수임 근데 그 문자열을 그대로 가져오는게 text함수
ajax 문자열 기반
fetch 데이터타입에 제한이 없다.(blob, arrayBuffer -> 파일 업로드, 다운로드)
근데 이 text()로 오고 이런것은 promise 객체로온다 이유 어마어마한 데이터 청크가 다 와야지 완성이 되어 차후 쓸수 있는 프로미스형태로 온다.
그래서 전에 ajax로 요청시 header에 XMLHttp리퀘스트 달렸는데 비동기라고 식별하면 안된다
fetch에서는 그런 헤더가 없다.
동기라는 방식이 단점때문에
비동기 방식으로 long-polling선택
여태까지 클라이언트 사이드(브라우저에서 처리된것)
EventSource - 이벤트를 보내는 HTTP 서버에 지속적인 연결을 합니다.
웹소켓과 비슷
mime - text/event-stream 흐름이 끊기지 않는다.
이벤트 데이터 받아올 때는 메시지
한번 연결을 수립하고 나서 끊고 싶을 때는 close()
한계점 : 웹소켓은 게속 연결 서로 통신(양방향)
, 클라이언트는 서버에게 요청X
다만 서버는 계속 응답 데이터를 보내줄수 있다.(단방향)
모든 이벤트는 자기가 가리키는 타켓의 정보를 모두 가지고 있다.
에러가 발생하더라도 3~5초내에 계속 받을 생각을 한다. 요청을 보내더라도 정상데이터가 안올 확률이 높기때문에 직접 연결을 끊는 처리를 해야한다.
역슬래시 n 한번 ( 공백? 한줄로 처리됨 )
역슬래시 n 라인 변경 두번 (건바이건 구별시)
라인 개행에 따라 달라진다?
(jsp서비스에서 인식을 못한다 그래서 두번개행해야 인식되는 것)
pending 기다리고 있다.
차이점 연결은 딱 한번만 서버사이드 이벤트 방식인것 (양방향은 상관없지만 서버에서 주기적으로 요청을 줘야할때, 쪽지알림, 메시지가 계속 건으로 식별된다.)
event가 어떤방식으로 가져왔냐에 따라서 가지고 노는 방법이 달라져야한다
제이쿼리문법에서는 제이쿼리 이벤트
그냥 자바 스크립트에서는 자바스크립트 이벤트
연결수립은 롱폴링(연결X)과 SSE(한번 연결수립으로 쭉)와의 차이이다
요청의 갯수로만 판단하면 SSE 방식이 부하가 덜걸린다. 무한 루프 걸면 연결이 계속 수립하는데 그러면 한명의 클라이언트와 계속 연결해야하는데 클라이언트는 사용이 끝나면 떠난다. 그래서 서버사이드에서는 적절히 시점에 한번 끊을 수 있어야한다.
비동기에서는 Refresh가 전~~혀 적용이 안되서 그래서 long polling 방식을 이용 (단점: 서버를 괴롭힙, 보완:SSE)
다만 상황에 따라 써야하기 때문에 각 API 차이점과 방식을 알고 있어야한다. 결국 MOZILLA 사이트에서 DOC 잘 읽어보기!
클라이언트 사이드에서도 SSE에 대한 연결을 종료하는 기능이 존재해야한다는 것
웹 어플리케이션 흐름제어
(ex. 피자주문)
3가지 방식의 차이점을 알아야한다.
3가지가 둘로 쪼개짐
1. 상태를 유지하는 방식 (Forward)
2. 유지하지 않는 방식 두개로 쪼개짐(Redirenct)
선행 - HTTP특징(connectless, statusless)
서버의 자원절약, 요청을 박고 응답을 하면 사라지는 특성(보완을 위해서 세션, 쿠기이용)
Forward 서버사이드에서 존재하기 때문에 (서버사이드 경로를 이용하는 것, 서버안에서의 위임처리 방식(떠넘겼다) Dispatch 디스패치 방식, 그래서 대부분 모델 2에서 이용 하는 것(요청을 분리하고 그 요청을 처리하는 곳으로 떠넘김))
Include 방식 A에서 시작해서 B 다시 A 그러면 A가 B를 내포하고 있다.(한페이지가 두개 이상의 JSP에서 만들어짐, 페이지 모듈화)
A,B가 합쳐져서 나감
페이지 모듈화 할때 는 방식 Include 방식
Redirect 브라우저(클라이언트사이드)에서 다른 링크로 요청하라고 보냈기떄문에 클라이언트 사이드 경로를 이용하는 것, 로그인 처리
302,307 응답코드와 Location헤더(새위치, 주소) 같이 보내야함. A의 응답데이터는 바디X(B에 대한 정보)
상태코드, Location 헤더
바디가 없다.
차이 상태를 유지할것이냐, 상태를 포기하고 새로운 요청으로 넘길것이냐
깨알 디스패치 - 분기자
오늘의 과제
비동기 요청을 발생시키는 여러가지를 봤는데
중프에? 비동기 방식들을 적용해 봐라??
