websocket 뿐만 아니라 웹에서 실시간 통신을 구현하기 위해 polling, long polling, streaming 방식도 있다. - websocket 1. 양방향 통신: 클라이언트 - 서버 간의 실시간 양방향 통신을 제공하는 프로토콜 2. 지속적인 연결: 클라이언트 - 서버 간의 지속적으로 데이터 주고받기 가능 3. 낮은 오버헤드: 연결을 유지하기 때문에 데이터를 주고 받을 때 네트워크 오버헤드가 낮다. 4. 실시간 업데이트: 변경 사항이 발생하면 즉각적인 업데이트가 가능하다. 실시간 양방향 통신이 필요할 경우 사용한다. 예를 들어 실시간 채팅, 실시간 협업 도구, 실시간 게임 등에 사용한다. 데이터의 실시간 전송과 즉각적인 업데이트가 필요한 경우 사용한다. - server sent event..

이번 사이드 프로젝트의 메인 주제는 미팅에서 사용할 수 있는 간단한 게임이다. 동시에 클라이언트에게 데이터를 전달할 수 있는 실시간 통신이 필요했다. 웹에서 어떻게 실시간 통신을 가능하게 할까? 찾아보니 websocket 을 사용하여 구현할 수 있었다. 이전 회사에서 윈도우 소켓 프로그래밍을 아주 잠깐 맛본 경험이 있었다. 그래서 대략적으로 어떤 플로우로 흘러가는 지 이해할 수 있었고, 조금 더 공부하기 위해 정리해보았다. 프로젝트의 기본적인 플로우 방장이 방을 개설한다. -> 유저들이 방으로 접속한다. -> 반복되는 부분 (방장이 이벤트(알림)을 보낸다. -> 유저들에게 실시간으로 알람이 간다. -> 유저들이 게임에 참여(응답) 한다.) 이게 기본적인 게임의 플로우이다. 이 흐름이 끊어지지 않게 실시간..

사람들과 함께하는 사이드 프로젝트에서 실시간 통신을 위해 웹 소켓을 사용한 기능 구현이 필요하게 되었다. 이전 회사에서 vb6와 C#을 이용한 윈도우 소켓 프로그래밍을 구현해본 경험이 있다. 웹 소켓은 http 의 웹 소켓 프로토콜 기반이고 윈도우 소켓은 tcp/ip 프로토콜 기반이다라는 차이만 인지하고 있었는데 문득 웹 소켓과 tcp/ip 소켓의 구체적인 차이점이 궁금해져서 정리해보았다. 목적 웹 소켓은 웹 애플리케이션에서 실시간 양방향 통신을 위해 사용한다. 웹 브라우저와 서버 간의 실시간 데이터 전송을 할 수 있다. tcp/ip 소켓은 네트워크 통신을 위한 프로토콜과 api를 제공하는 기술이다. 프로토콜 웹 소켓은 http 를 통해 웹 소켓 연결을 설정한 후, websocket 프로토콜을 이용하여..

요새 팀원들과 사이드 프로젝트를 수행하고 있는데, 로그인할 때 aws cognito를 사용하기로 했다. 난 이번에 처음 들어보는 것이여서 매우 생소했다. cognito는 aws 에서 제공하는 인증과 사용자 관리 솔루션이다. cognito 에 대해 알아보기 전에 나는 oauth도 정확히 무엇인지 몰랐다. 그냥 소셜 로그인 정도?? 그래서 oauth 에 대해서 먼저 공부해보았다. 그리고 내가 기억하기 위해 기록을 남긴다. OAuth 는 무엇이며 왜 써야할까? OAuth 의 핵심은 사용자의 아이디, 비밀번호를 공유하지 않고 서드파티 애플리케이션에 제한적 접근할 수 있도록 하는 것이다. 예를 들어 우리 프로젝트에 구글 로그인을 넣고 싶다면 기본적으로 유저의 구글 아이디와 비밀번호를 공유 받아야 한다. 그러나 유..

프로젝트를 진행하면서 처음으로 인프라를 구성하고 무중단 배포에 대해서 공부해보았다. 이 과정에서 공부한 것들, 겪었던 에러 사항 등등 더 오래동안 기억에 남기기 위해 블로그에 기록하기로 했다. 전체적인 구성은 하단의 블로그를 참고해서 구성해보았다. https://wbluke.tistory.com/39 1. github 에 push 후 pull request 를 올리면 sonar cloud 와 github actions 의 workflows 가 실행된다. (workflows 에는 chatGPT code review 와 deploy 가 있다.) 2. deploy 관련한 스크립트에는 프로젝트를 빌드하여 jar 파일로 만들어 s3 에 업로드하고, code deploy가 s3에 업로드된 jar 파일을 가져와 배포..

로그인 처리를 하면서 servlet filter, spring interceptor, spring argument resolver 에 대해서 공부했다. 모두 공통의 관심사를 처리할 때 사용한다는 특징이 있다. 어떠한 상황에 어떤 것을 사용해야 하는지 정확히 구분하기 위해 정리해보기로 했다. servlet filter 디스패처 서블릿에 요청이 전달되기 전 처리를 할 수 있다. url 패턴에 맞는 모든 요청에 대해서 처리가 가능하다. 필터는 J2EE 표준 스펙 기능으로서 spring 과 분리된 기능을 처리해야할 때 사용한다. 웹 컨테이너에서 동작하기 때문에 올바르지 않은 요청일 경우 사전에 차단 가능하여 스프링 컨테이너까지의 진입이 차단되어 안정성을 높일 수 있다. spring interceptor 컨트롤러..

세션 방식을 택한 이유 저번 연습 프로젝트에서는 로그인 시 jwt 토큰 방식을 선택했다. 그리고 이번 프로젝트에서는 session 방식을 선택했다. 세션과 토큰 방식의 차이점을 찾아보면, 세션이 안정성이 높고 사이즈가 작아서 네트워크 부하가 작다는 등의 여러 장점이 나온다. 하지만 그런 이유보다는 '제대로 안써봐서' 써보기 위해 선택했다. 배우는 단계에서는 이것저것 다양한 기술을 구현해보는 경험도 중요하다고 생각했다. 토큰 방식을 사용했을 때의 문제점들 로그아웃이 애매하다. 일단 한 번 발급한 토큰은 무효가 안된다. 그래서 보통 redis에 블랙리스트를 사용하는데, redis 에 블랙리스트로 저장한다는 것은 결국 서버를 stateful 하게 사용하게 된다. 토큰의 tateless 한 장점이 없어진다. 나..

프로젝트를 하면서 로그인 인증 방식을 아무 생각 없이 Spring Security 와 jwt 토큰 방식으로 채택하고 구현했다. 정확히 말하면 다른 사람이 만들어둔 코드를 복붙했다. 그리고 jwt 토큰이 뭔데? 구조가 어떤데? 왜 세션을 안쓰고 토큰을 쓰는데? 라는 질문을 들었을 때 아무런 대답을 할 수 없었다. 내가 만드는 코드에 이유를 말하지 못하는 개발 방식과 공부 습관은 정말 위험하다는 생각이 들었다. jwt에 대해서 공부하였고, 내가 왜 이 방식을 선택했는지에 대해서 글을 남기려고 한다. 아직 spring security 까지 공부할 실력과 수준이 아니라고 판단되어 spring security 는 일단 프로젝트에서 걷어내기로 했다. JWT 란? Json Web Token 의 약자이다. JWT 는 ..