총 5개의 글
웹소켓 HTTP 프로토콜은 Client가 요청을 보내면 Server가 이에 응답해주는 방식으로 진행된다. 그러나 이러한 방식은 요청이 있을 때만 1회성으로 데이터를 주고받는 것이기에 실시간으로 주식가격을 보여준다거나 실시간 채팅을 하는 등의 기능을 구현하기에는 부적합하다. 이러한 배경에서 등장한 것이 웹소켓 통신이다. 웹소켓 통신은 ws 라는 프로토콜을 이용한 통신으로, 이를 사용하면 서버와 브라우저 간 연결을 유지한 상태로 데이터를 교환할 수 있다. http와 https의 관계처럼 wss도 존재한다. 이러한 웹소켓 통신을 구현하는데 도움을 주는 라이브러리는 여러가지가 있지만, 그 중 하나가 Socket.io이다. 아래는 Socket.io를 이용하여 웹소켓 통신을 구현한 예제이다. 서버 측 설정 클라이언트
Cross-Origin Resource Sharing 동일 출처 정책 (SOP) 브라우저에서 서버에 요청을 보낼 때, 출처가 같지 않으면 차단하는 정책 브라우저에서 서버에 요청을 보낼 때는, 클라이언트의 Origin과 서버의 Origin이 같아야 동일 출처 정책에 의해 차단되지 않음. 이는 백엔드에서 요청을 보낼 때에는 적용되지 않고, 브라우저에서 요청을 보낼 때만 적용된다. 출처 비교와 차단은 브라우저에 구현된 스펙이다. (서버에 구현된 스펙이 아니다) 브라우저는 사용자의 개인정보를 담고있고, 이러한 제약이 없다면 해커가 CSRF(Cross-site request forgery)나 XSS(Cross-site scripting)등의 방법을 이용하여 개인정보를 가로챌 수 있기 때문이다. [참고] 출처(Or
로컬 스토리지의 문제점 저장 용량 제한 로컬 스토리지는 일반적으로 5MB 정도의 저장 용량을 제공합니다. 대용량 데이터를 저장하기에는 부족합니다. 동기적 API 로컬 스토리지는 동기적 API를 사용합니다. 이는 데이터 저장 및 검색 작업이 완료될 때까지 브라우저의 다른 작업이 블로킹된다는 것을 의미합니다. 특히 대용량 데이터를 처리할 때 성능 문제가 발생할 수 있습니다. 단순한 데이터 구조 로컬 스토리지는 문자열 형태의 키-값 쌍만 저장할 수 있습니다. 복잡한 데이터 구조를 저장하고 관리하기 어렵습니다. 이 때문에 객체 형태를 저장하려면 JSON 형태로 변환하는 작업을 거치면서 에러가 날 확률이 높아집니다. 보안 문제 로컬 스토리지에 저장된 데이터는 클라이언트 측에서 쉽게 접근할 수 있어 보안에 취약할 수
SPA(Single Page Application) (2005) SPA가 등장하기 전에는, a태그를 클릭하여 다른 페이지로 이동하면 해당 페이지의 HTML을 다시 불러와야 했음 (SSG) SPA는 AJAX의 등장과 함께 등장한 것으로, 사용자가 하나의 페이지 안에서 머무르면서, 변경이 필요한 부분만 부분적으로 업데이트 Web Application이 더 많이 사용하게 된 계기 (개인적인 생각) CSR과 SSR CSR (Client Side Rendering) 클라이언트인 브라우저가 렌더링을 처리하는 방식 새로고침이 발생하지 않아 화면 전환이 매끄럽고 서버 트래픽을 감소시킨다는 장점 첫화면에서 HTML, CSS, JS가 모두 다운로드 되므로 첫 페이지 로딩 시간이 길고, SEO에 SSR보다 불리하다는 단점 SS
Open Authorization OAuth 등장배경 특정 서비스가 유저의 구글 캘린더에 일정을 등록하려고 한다고 생각해보자. 해당 서비스가 유저의 구글 캘린더에 접근하기 위해서는 1차원적으로 유저의 구글 ID와 PW를 받아 직접 구글에 접속하는 방법이 있을 것이다. 그러나 이 방법은 유저의 입장에서도 신뢰할 수 없는 특정 서비스에 ID와 PW를 노출하는 것이 되어 꺼려지고, 해당 서비스의 입장에서도 유저의 ID와 비밀번호를 갖게 되는 것은 보안 측면에서 부담스러운 일이 된다. 또한, 해당 서비스가 구글 캘린더에 일정을 등록하는 것 뿐 아니라 사용자의 Gmail에도 접근할 수 있는 등 다른 부분에도 접근할 수 있게 된다. 이러한 상황에서 등장한 것이 OAuth이다. OAuth를 사용하면 구글은 accessT
