※ 오늘 발생한 문제 : 카카오 회원가입이 되지 않고, redirect 되지 않는 문제

BE 코드 수정 부분

redirect_uri 주소가 localhost:8080으로 시작되는 백엔드 사용 로컬테스트 서버로 되어있었는데 (주석처리 된 부분), 그 부분을 프론트엔드 사용 로컬테스트 서버인 localhost:3000번으로 변경해 주었다.

FE 코드 수정 부분

문제가 발생했을 때 위의 사진과 같이 instance.post(`auth/kakao/callbak`,code)로 잘못 작성되어 있었다.

위와 같이 post('auth/kakao/callbak',code) -> get(`auth/kakao/callback?code=${code}`) 로 수정

그리고 원래 REACT_APP_BASE_URL에 백엔드에서 배포한 서버주소가 들어가 있었는데, 그 부분에 프론트엔드에서 사용하는 로컬테스트 서버인 localhost:3000을 넣고, REACT_APP_API_URL 부분에 백엔드 배포 서버를 넣어주니 정상 작동 되었다.

[ 참고 자료 ]

https://data-jj.tistory.com/53

1. 웹소켓 기술  

• 전이중 통신 - 실시간성 보장하는 서비스 (채팅, 게임, 주식거래 사이트 등)에 주로 사용
• HTTP에도 실시간성 보장하는 기법이 존재하지만, 서버에 부하가 많이 가기 때문에 웹소켓을 이용한다.
• HTTP는 비연결성 프로토콜, 단방향성 통신이다. 따라서 매번 연결 맺고 끊는 과정의 비용이 든다.
• 반면, 웹소켓은 연결지향이라 한번 연결 맺은 뒤 유지, 양방향 통신이다.
• 보내야하는 메시지와 데이터 양에서도 차이가 난다. 웹소켓을 사용하면 HTTP와 비교했을 때 한번 통신한 후엔 훨씬 적은 양의 데이터로 통신해서 부담을 덜 수 있다. 

2. 웹소켓의 단점 : 모든 브라우저에서 허용되는 것은 아니다.

→ 이 문제를 SockJs 와 Socket.io 를 사용하여 해결 할 수 있다. (스프링은 SoketJs사용)

※ 스프링에서 웹소켓 설정은 아주 간단한다. 

• 웹소켓 Config 파일 - addHandler 핸드쉐이크할 주소를 적어줌
• 핸들러 부분 - 웹소켓 세션을 오버라이드해서 받아오는데, 웹소켓 연결정보를 담고 있는 세션이다.
• Cors설정
• .withSockJS() 를 통해 라이브러리 사용 가능.

3. Stomp 프로토콜

• 메시지 브로커를 활용하여 쉽게 메시지를 주고 받을 수 있는 프로토콜
• 웹소켓 위에 얹어 함께 사용할 수 있는 하위 프로토콜 
• 메시지 브로커랑 발신자의 메시지를 받아와 수신자들에게 메시지를 전달하는 어떤 것 !

그렇다면 왜 이게 필요한가 ?

프레임 단위 ( 커맨드, 헤더, 바디 ) 의 형태로 메시지 형태를 정해줌. - 컨벤션을 따로 정의할 필요 없다.

https://www.youtube.com/watch?v=rvss-_t6gzg 

Message Broker란?

• Publisher로부터 전달받은 메세지를 Subscriber로 전달해줄 때 중간에서 메세지를 주고 받게 해주는 중간 역할

https://docs.spring.io/spring-framework/docs/4.3.x/spring-framework-reference/html/websocket.html

In Memory Broker란?

• Spring websocket에서 STOMP 프로토콜을 사용해서 웹소켓 기능을 구현할 때 STOMP는 Message Broker가 필요하다.
• 이 때 아무 설정 없이 Spring 환경에서 STOMP 프로토콜을 사용한다면 메세지 브로커로 In Memory Broker를 사용하게 된다.

그렇다면 하나의 서비스를 만들 때 In Memory Broker를 메세지 브로커로 사용해도 상관 없을까?

상관있다... 아래를 보면, In Memory 브로커의 단점들이 존재한다.

1. 세션을 수용할 수 있는 크기가 제한되어 있다.
2. 장애 발생 시 메세지의 유실될 가능성이 높다.
3. 따로 모니터링하는 것이 불편하다.

그렇다면 In Memory 브로커 대신 무슨 브로커를 사용할 수 있을까?

• RabbitMQ, ActiveMQ 등에서는 STOMP 프로토콜의 Message Broker 기능을 제공해준다. 
• 따라서 이들의 힘을 빌려 In Memory 브로커 대신 잘 만들어진 STOMP 전용 외부 브로커를 사용하는 것이 더 좋다.

STOMP 전용 외부 브로커를 사용하는 장점이 무엇이 있을까?

1. 확장성 : 세션을 수용할 수 있는 크기가 크다.
2. 결함 허용성 : 영구적이며 문제가 발생했을 시 재시도가 가능하여 복구가 가능하다.
3. 모니터링 : 간편하게 모니터링을 할 수 있다.

[ 참고자료 ]

https://withseungryu.tistory.com/137

WebSocket은 클라이언트 서버간 양방향 통신이 가능하지만, 다음과 같은 이슈가 있다.
1. websocket미지원 웹 브라우저가 있다는 점
2. 웹 브라우저 이외의 클라이언트 지원(서버 입장에서는 클라이언트는 웹 브라우저뿐만이 아님)

WebSocket

• WebSocket 동작 순서

• Http의 특징 중 하나는 단방향 통신이다.
  클라이언트와 서버간의 통신은 단건으로 이루어지며 하나의 요청(통신)이 끝나게 되면 클라이언트와 서버는 아무런 관계가 없어지게된다. 이 말은 서버입장에서 클라이언트로부터 요청이 있기전까지는 어떤 데이터도 전송할 수 없다는 것이다.
  이런 문제를 해결하기 위해 양방향 통신이 생겨나게 되었고, WebSocket으로 구현하게 되었다.
• WebSocket은 Http를 통해 작동하도록 설계되었으며, Http Header에 특정 값("websocket")을 명시함으로써 WebSocket 프로토콜로 전환하는 요청으로 시작된다.

STOMP 

• 스트리밍 텍스트 지향 메시지 프로토콜
• STOMP는 Simple/Stream Text Oriented Message Protocol의 약자로, 메시지 브로커의 역할을 한다.
• 메시지 전송을 효율적으로 처리하기 위한 프로토콜
• STOMP는 WebSocket 기반으로 동작하며 pub/sub 구조로 되어 있다. pub/sub 구조는 쉽게 말해 편지를 쓰는 사람(Publisher)이 편지함에 편지를 넣어두면 그걸 기다리고 있던 편지를 받는 사람(Subscriber)이 편지를 받고 읽는 구조이다.
• 즉, WebSocket 위에서 동작하는 프로토콜로써 클라이언트와 서버가 전송할 메시지의 유형, 형식, 내용들을 정의하는 메커니즘이다.

Stomp를 사용하는 이유

• STOMP 를 사용하여 WebSocket만 사용할 때보다 더 다채로운 모델링을 할 수 있다.
• Messaging Protocol을 만들고 메세지 형식을 커스터마이징 할 필요가 없다.
• RabbitMQ, ActiveMQ 같은 Message Broker를 이용해, Subscription(구독)을 관리하고 메세지를 브로드캐스팅할 수 있다.
• WebSocket 기반으로 각 Connection(연결)마다 WebSocketHandler를 구현하는 것 보다 @Controller 된 객체를 이용해 조직적으로 관리할 수 있다.
• 즉, 메세지는 STOMP의 "destination" 헤더를 기반으로 @Controller 객체의 @MethodMapping 메서드로 라우팅 된다.
• STOMP의 "destination" 및 Message Type을 기반으로 메세지를 보호하기 위해 Spring Security를 사용할 수 있다.

SockJS

• WebSocket은 upgrade Header를 이용하여 Socket연결을 하고, 통신을 진행한다. 이 과정에서 여러가지 이유로 소켓연결이 불가능하게 될 경우가 있는데 이럴 경우 Http기반의 다른 기술로 전환하여 다시 연결을 시도해야할 필요가 있다. 이 때 사용하시는 것이 'WebSocket Emulation'이다. 그리고 Spring에서는 Emulation을 위해 'SockJS' 라이브러리를 지원한다.
• SockJS는 다양한 기술을 이용해 웹소켓을 지원하지 않는 브라우저에서 정상 작동하도록 도와주는데.

1. WebSocket
2. HTTP Streaming
3. HTTP Long Polling
   세가지 타입을 이용한다.

Redis 

레디스(Redis)는 Remote Dictionary Server의 약자로서, "키-값" 구조의 비정형 데이터를 저장하고 관리하기 위한 오픈 소스 기반의 비관계형 데이터베이스 관리 시스템(DBMS)이다.

redis를 사용하는 이유?

1.놀라울 정도로 빠른 성능

Redis와 같은 인 메모리 데이터베이스는 디스크에 액세스해야 할 필요를 없앰으로써 검색 시간으로 인한 지연을 방지하고 CPU 명령을 적게 사용하는 좀 더 간단한 알고리즘으로 데이터에 액세스할 수 있다.

2. 인메모리 데이터 구조

Redis를 사용하면 사용자가 다양한 데이터 유형에 매핑되는 키를 저장할 수 있다.

3. 다양성과 사용 편의성

Redis는 개발과 운영을 좀 더 쉽고 좀 더 빠르게 수행할 수 있는 여러 가지 도구를 제공한다. Pub/Sub는 메시지를 채널에 게시하며, 채널에서 구독자에게 전달된다. 채팅과 메시징 시스템에 매우 적합하다.

4. 복제 및 지속성

Redis는 마스터-슬레이브 아키텍처를 사용하며 비동기식 복제를 지원하여 데이터가 여러 슬레이브 서버에 복제될 수 있다. 이렇게 하면 주 서버에 장애가 발생하는 경우 요청이 여러 서버로 분산될 수 있으므로 향상된 읽기 성능과 복구 기능을 모두 제공할 수 있다.

5. 선호하는 개발 언어 지원

Redis 개발자는 백 개가 넘는 오픈 소스 클라이언트를 사용할 수 있으며, Java, Python, PHP, C, C++, C#, JavaScript, Node.js, Ruby, R, Go를 비롯한 다수의 언어가 지원된다.

※ Redis 다운로드

https://github.com/microsoftarchive/redis/releases

[ 정리 ]

• Websoket을 사용하려면 메시지 브로커 역할을 해주는 Stomp와 웹소켓을 지원하지 않는 브라우저에서 작동하도록 도와주는 SockJS 라이브러리를 같이 사용해야 한다.
• Stomp broker 설정으로만 채팅이 되는 것이 아니다. 클라이언트가 서로 다른 서버에 연결이 됬을때 채팅을 하려면 Redis가 필요하다.
• 메시지 브로커 사용하는 이유는 3가지
  • 서비스(어플리케이션) 간의 의존성 제거
  • 메시지 처리 시점
  • 다양하고 유연한 통신

[ 참고자료 ]

https://fgh0296.tistory.com/24

https://velog.io/@koseungbin/WebSocket

https://thdwngus2.tistory.com/100

실전프로젝트에 실시간 채팅과 음성 채팅 기능을 구현해야 한다.

Spring 채팅기능에 관련해 찾아보니 WebSocket과 WebRTC 두가지 키워드가 등장했다. 

다음은 WebSoket과 WebRTC에 대한 간략한 정리이다.

WebRTC vs WebSockets: What are the key differences?

• WebSocket provides a client-server computer communication protocol, whereas WebRTC offers a peer-to-peer protocol and communication capabilities for browsers and mobile apps.
• While WebSocket works only over TCP, WebRTC is primarily used over UDP (although it can work over TCP as well).
• WebSocket is a better choice when data integrity is crucial, as you benefit from the underlying reliability of TCP. On the other hand, if speed is more important and losing some packets is acceptable, WebRTC over UDP is a better choice.
• WebRTC is primarily designed for streaming audio and video content. It is possible to stream media with WebSockets too, but the WebSocket technology is better suited for transmitting text/string data using formats such as JSON.

TCP와 UDP의 차이점은 ?

• TCP는 연결 지향 프로토콜인 반면 UDP는 비연결 프로토콜입니다. TCP가 UDP보다 비교적 느리기 때문에 TCP와 UDP의 주요 차이점은 속도입니다. 전반적으로 UDP는 훨씬 빠르고 간단하며 효율적인 프로토콜이지만 손실된 데이터 패킷의 재전송은 TCP를 통해서만 가능합니다. 
• TCP와 UDP의 또 다른 주목할 만한 차이점은 TCP는 사용자에서 서버로(또는 그 반대로) 데이터를 순서대로 전달하는 반면 UDP는 종단 간 통신 전용이 아니며 수신자의 준비 상태를 확인하지도 않는다는 것입니다.  

When to use WebRTC?

WebRTC is a good choice for the following use cases:

• Audio and video communications, such as video calls, video chat, video conferencing, and browser-based VoIP.
• File sharing apps.
• Screen sharing apps.
• Broadcasting live events (such as sports events).
• IoT devices (e.g., drones or baby monitors streaming live audio and video data).

When to use WebSockets?

We can broadly group Web Sockets use cases into two distinct categories:

• Realtime updates, where the communication is unidirectional, and the server is streaming low-latency (and often frequent) updates to the client. Think of live score updates or alerts and notifications, to name just a few use cases.
• Bidirectional communication, where both the client and the server send and receive messages. Examples include chat, virtual events, and virtual classrooms (the last two usually involve features like live polls, quizzes, and Q&As). WebSockets can also be used to underpin multi-user synchronized collaboration functionality, such as multiple people editing the same document simultaneously.

[ 정리 ]

• WebSocket은 데이터 무결성이 중요한 경우 TCP의 기본 안정성을 활용하므로 더 나은 선택
• 반면에 속도가 더 중요하고 일부 패킷 손실이 허용되는 경우 UDP를 통한 WebRTC가 더 나은 선택

[ 결론 ] : 두 가지 모두 사용 ?

WebSocket : 게임과 채팅 구현을 위해 실시간성을 보장하는 통신 방식. HTTP에서도 실시간성을 보장하는 반이중 기법들(polling, long polling, streaming)이 존재하나, 실시간성이 떨어지거나 서버 부하가 올라갈 수 있다는 단점이 있어서, 하나의 TCP 연결을 통해 양방향 통신을 제공하는 Websocket을 선택.

WebRTC : 화상/보이스 채팅 기능을 위해 카메라와 마이크 등의 미디어 자원을 통해 실시간으로 소통할 수 있는 기술이 필요. WebRTC는 브라우저에서 지원하는 프레임워크로 많이 사용되어 안정성이 검증되어있고, 별도의 플러그인 없이 사용이 가능하여 User 경험에 유리하다.

이번 프로젝트땐 아마 일반 채팅엔 WebSocket을, 그리고 화상/음성 채팅엔 WebRTC를 사용할 것 같다 : ) 

[ 참고자료 ]

https://ably.com/topic/webrtc-vs-websocket

https://www.lifesize.com/blog/tcp-vs-udp/