230216 30분 TIL

1. GET과 POST 차이 

 

Get 방식

- 클라이언트에서 서버로 데이터를 전달할 때, 주소 뒤에 "이름"과 "값"이 결합된 스트링 형태로 전달

- 주소창에 쿼리 스트링이 그대로 보여지기 때문에 보안성이 떨어진다.

- 길이에 제한이 있다.(=전송 데이터의 한계가 있다.)

- Post방식보다 상대적으로 전송 속도가 빠르다.

 

Post 방식

- 일정 크기 이상의 데이터를 보내야 할 때 사용한다.

- 서버로 보내기 전에 인코딩하고, 전송 후 서버에서는 다시 디코딩 작업을 한다.

- 주소창에 전송하는 데이터의 정보가 노출되지 않아 Get방식에 비해 보안성이 높다.

- Get방식보다 속도가 느리다.

- 쿼리스트링(문자열) 데이터 뿐만 아니라, 라디오 버튼, 텍스트 박스 같은 객체들의 값도 전송가능.'

 

Get과 Post 차이점

- Get은 주로 웹 브라우저가 웹 서버에 데이터를 요청할 때 사용

- Post는 웹 브라우저가 웹 서버에 데이터를 전달하기 위해 사용.

- Get을 사용하면 웹 브라우저에서 웹 서버로 전달되는 데이터가 인코딩되어 URL에 붙는다.

- Post방식은 전달되는 데이터가 보이지 않는다.

- Get방식은 전달되는 데이터가 255개의 문자를 초과하면 문제가 발생할 수 있다.

- 웹서버에 많은 데이터를 전달하기 위해서는 Post 방식을 사용하는 것이 바람직하다.

 

참고자료: https://bangu4.tistory.com/28

2. Web Storage VS Cookie 

Web Storage는 기존 웹 환경의 쿠키(Cookie)와 매우 유사한 개념이다.사실 거의 차이가 없지만 몇 가지 쿠키의 단점을 극복하는 개선점이 도입되었다. 그러나 쿠키는 여전히 유효하고 꽤 적절한 클라이언트 저장도구임에 틀림없다

 

1. 쿠키는 매번 서버로 전송된다.

웹 사이트에서 쿠키를 설정하면 이후 모든 웹 요청은 쿠키정보를 포함하여 서버로 전송된다. Web Storage는 저장된 데이터가 클라이언트에 존재할 뿐 서버로 전송은 이루어지지 않는다. 이는 네트워크 트래픽 비용을 줄여 준다.

 

2. 단순 문자열을 넘어(스크립트) 객체정보를 저장할 수 있다.

문자열 기반 데이터 이외에 체계적으로 구조화된 객체를 저장할 수 있다는 것은 개발 편의성을 제공해주는 주요한 장점이 된다. 브라우저의 지원 여부를 확인해 봐야 하는 항목이다.

 

3. 용량의 제한이 없다

쿠키는 개수와 용량에 있어 제한이 있다. 하나의 사이트에서 저장할 수 있는 최대 쿠키 수는 20개이다. 그리고 하나의 사이트에서 저장할 수 있는 최대 쿠키 크기는 4KB로 제한되어 있다. 그러나 Web Storage에는 이러한 제한이 없다. 그러나 쿠키도 하위키를 이용하면 이러한 제한을 일부 해소할 수 있습니다. 그리고 대부분 쿠키의 제한으로까지 데이터를 저장할 일이 없다.

 

4. 영구 데이터 저장이 가능하다

쿠키는 만료일자를 지정하게 되어 있어 언젠가 제거된다. 만료일자로 지정된 날짜에 쿠키는 제거되는 것이다. 만약 만료일자를 지정하지 않으면 세션 쿠키가 된다. 만일 영구 쿠키를 원한다면 만료일자를 굉장히 멀게 설정하여 해결할 수 있다.
WebStorage는 만료기간의 설정이 없다. 즉, 한번 저장한 데이터는 영구적으로 존재하는 것이다.

 

WebStorage와 쿠키의 차이점에 대해서 WebStorage가 특별히 좋은 이유는 없다고 봐도 무방하다. 다만 한가지 매번 서버로 전송되지 않는다는 특징은 꽤나 유용하다.

 

 

3. LocalStorage와 SessionStorage

Web Storage는 데이터의 지속성과 관련하여 두 가지 용도의 저장소를 제공한다.

우선 기본적으로 Web Storage는 쿠키와 마찬가지로 사이트의 도메인 단위로 접근이 제한된다. 예를 들어, A 도메인에서 저장한 데이터는 B 도메인에서 조회할 수 없다는 것이다. 이는 데이터의 보안 측면에서 당연하다.

LocalStorage

저장한 데이터를 명시적으로 지우지 않는 이상 영구적으로 보관이 가능하다. 앞서 말한대로 도메인마다 별도로 로컬 스토로지가 생성된다. Windows 전역 객체의 LocalStorage라는 컬렉션을 통해 저장과 조회가 이루어진다.

SessionStorage

SessionStorage는 데이터의 지속성과 액세스 범위에 특수한 제한이 존재한다. SessionStorage는 windows 전역 객체의 sessionStorage라는 컬렉션을 통해 저장과 조회가 이루어진다.

 

참고자료: https://kcizzang.tistory.com/entry/SessionStorage-와-LocalStorage-차이점

 

4. 쿠키와 세션 

1) 쿠키와 세션을 사용하는 이유

HTTP 프로토콜의 특징인 비연결지향(ConnectionLess)와 상태없음(Stateless) 특성을 보완하기 위해서 쿠키와 세션 사용 

 

비연결지향이라는 특성 덕분에 계속해서 커넥션을 유지하지 않기 때문에 서버 리소스 낭비가 줄어드는 것은 아주 큰 장점이지만, 통신할 때마다 새로 커넥션을 만들기 때문에 클라이언트 측면에서는 상태를 유지(ex. 인증에 쓰이는 상태, ...)를 위해 통신할 때마다 어떤 절차를 가져야하는 단점이 생긴다.

심각하게 말하면 만약 쿠키와 세션이 없다면 어떤 페이지에서 다른 어떤 페이지로 넘어갈 때마다 인증을 다시 받아야하는 것이다.

 

2) 쿠키

쿠키는 세션쿠키와 지속쿠키로 나뉜다.

 

 2-1) 세션쿠키 

• 만료 날짜를 지정하지 않으면 '메모리에 있는 동안' 계속 유효하다고 판단하여 세션 쿠키에 저장된다. 
• 브라우저 메모리에 저장되므로 브라우저 종료시 쿠키는 사라짐
• 브라우저의 메모리에 저장되기 때문에 보안에 유리함

 2-2) 지속쿠키 

• 만료 날짜를 지정하면 메모리 사라지더라도 특정 날짜까지 유효하므로 지속쿠키에 저장
• 지속쿠키는 파일로 저장되므로 브라우저 저장되더라도 쿠키는 남아있음 
• 파일로 저장되기 때문에 보안에 취약 

 2-3) 쿠키 사용 사례

• 자동로그인, 팝업에서 "오늘 더 이상 이 창을 보지 않음" 체크, 쇼핑몰의 장바구니, ..

2-4) 쿠키의 한계

• 클라이언트에 최대 300개 까지 쿠키를 저장할 수 있다.
• 서버 도메인 하나당 최대 20개의 쿠키를 저장할 수 있다.
• 하나의 쿠키 값은 최대 4KB까지 저장할 수 있다.

 

3) 세션

서버(Server)에 클라이언트의 상태 정보를 저장하는 기술로 논리적인 연결을 세션이라고 한다.

웹 서버에 클라이언트에 대한 정보를 저장하고 클라이언트에게는 클라이언트를 구분할 수 있는 ID를 부여하는데 이것을 세션아이디라 한다.

 

결과적으로 세션을 통해 클라이언트의 정보는 서버에 두고, 세션 아이디를 이용해서 인증받고 정보를 이용하는 방식이다.

 

4) 쿠키와 세션의 차이

• 저장 위치
  • 쿠키는 클라이언트(브라우저)에 메모리 또는 파일에 저장하고, 세션은 서버 메모리에 저장된다.
• 보안
  • 쿠키는 클라이언트 로컬(local)에 저장되기도 하고 특히 파일로 저장되는 경우 탈취, 변조될 위험이 있고, Request/Response에서 스나이핑 당할 위험이 있어 보안이 비교적 취약하다. 반대로 Session은 클라이언트 정보 자체는 서버에 저장되어 있으므로 비교적 안전하다.
• 라이프 사이클
  • 쿠키는 앞서 설명한 지속 쿠키의 경우에 브라우저를 종료하더라도 저장되어 있을 수 있는 반면에 세션은 서버에서 만료시간/날짜를 정해서 지워버릴 수 있기도 하고 세션 쿠키에 세션 아이디를 정한 경우, 브라우저 종료시 세션아이디가 날아갈 수 있다.
• 속도
  • 쿠키에 정보가 있기 때문에 쿠키에 정보가 있기 때문에 서버에 요청시 헤더를 바로 참조하면 되므로 속도에서 유리하지만, 세션은 제공받은 세션아이디(Key)를 이용해서 서버에서 다시 데이터를 참조해야하므로 속도가 비교적 느릴 수 있다.

 

5) 세션을 주로 사용하면 좋은데 왜 굳이 쿠키를 사용할까?

→ 세션은 서버에 데이터를 저장 즉, 서버의 자원을 사용하기 때문에 서버 자원에 한계가 있고 메모리를 사용하다보면 속도 저하도 올 수 있기 때문이다.

 

 

참고자료: https://jeong-pro.tistory.com/80

 

 

6) Web Worker

자바스크립트는 싱글 스레드 언어인데 실제 사용시 멀티 스레드처럼 사용할 수 있는 이유는 Web worker를 사용하기 때문이다. 

 

HTML 페이지에서 스크립트를 실행할때 그 페이지는 스크립트가 완료할때 까지 응답하지 않게 됩니다. 이를 해결하기 위해 Web worker를 사용하는데요, Web worker는 페이지의 퍼포먼스에 영향을 주지 않고 다른 스크립트와는 독립적으로 백그라운드에서 실행되는 javascript입니다.

 

기존의 웹은 다중 쓰레드가 불가능했기 때문에 작업이 끝나기 전까지 UI 멈춰버리는 경우가 발생했습니다. 하지만, Web worker 덕분에 웹은 멀티 쓰레드 구동이 가능해졌습니다. 

 

 

참고자료: https://boxfoxs.tistory.com/294

 

 

7) 태스크 큐 vs 마이크로 태스크 큐 

 

자바스크립트는 이벤트 루프를 이용해서 비동기 방식으로 동시성을 지원하다. 

이벤트 루프란 자바스크립트 엔진이 아닌, 구동하는 환경(브라우저, 노드)에서 가지고 있는 장치이다.

콜 스택과 태스크 큐(= 콜백 큐)를 감시하며, 콜 스택이 비어있을 경우에 태스크 큐에서 태스크(= 콜백함수)를 가져와 콜 스택에 넣어 실행시키는 기능을 한다.

지금까진 이렇게 알고 있었는데 태스크 큐 말고도 마이크로태스크 큐 (Micro task queue)가 있다고 한다! 

 

1) 태스크 큐 vs 마이크로태스크 큐

• 2개의 큐 모두 콜백함수가 들어간다는 점에도 동일하지만 어떤 함수를 실행하느냐에 따라 어디로 들어가는지 달라진다.
• 또 명칭은 큐(Queue)이지만 자료구조의 큐와 다르다.
• 엄밀히 말하자면 우선순위 큐 (Priority Queue) 라고 할 수 있는데, 이벤트 루프가 2개의 큐에서 태스크를 꺼내는 조건이 “제일 오래된 태스크” 이기 때문이다. 

콜백함수를 태스크 큐에 넣는 함수들

• setTimeout, setInterval, setImmediate, requestAnimationFrame, I/O, UI 렌더링

콜백함수를 마이크로태스크 큐에 넣는 함수들

• process.nextTick, Promise, Object.observe, MutationObserver

 

익숙한 함수인 Web API의 setTimeout() 의 콜백함수가 태스크 큐에 들어가고 Promise 의 콜백함수가 마이크로태스크 큐에 들어간다는 것을 알 수 있다. 이벤트 루프는 각 콜백함수를 태스크/마이크로태스크 큐에서 꺼내쓰는 것인데, 그렇다면 어떤게 먼저일까?

 

2) 누가 먼저인가? 

• 마이크로태스크가 먼저이다. 

이벤트 루프는 마이크로태스크 큐의 모든 태스크들을 처리한 다음, 태스크 큐의 태스크들을 처리한다. 따라서, Promise 의 콜백함수가 setTimeout() 의 콜백함수보다 먼저 처리된다. 

 

 

참고자료: https://baeharam.netlify.app/posts/javascript/JS-Task%EC%99%80-Microtask%EC%9D%98-%EB%8F%99%EC%9E%91%EB%B0%A9%EC%8B%9D