[CS] 공통프로젝트 기술 질문 정리

두리두두·2023년 6월 22일

WEBRTC websocket

TIL

목록 보기

7/15

🐤 WebRCT vs WebSocket

1. WebSocket

기본 http 프로토콜은 서버가 브라우저의 요청에 응답하고 나면 브라우저-서버 간 통신이 끝남! 그렇기 때문에 티키타카가 안 됨
원하는 순간까지 통신이 열려있게 하기 위해 웹소켓이 대두
브라우저, 서버 둘 다 메세지를 보내고 받을 수 있음. (서버와 클라이언트 실시간으로 양방향 통신 가능케 함)
주식거래, 채팅, 게임 등 리얼타임 경험을 위해 만들어짐.
person to person이 아니라 모두 다 같은 웹소켓 서버에 접속해 정보를 주고받기 때문에 메모리 파워가 중요

2. WebRTC

서버를 거치지 않고 브라우저 상에서 Peer to Peer로 통신이 가능한 프로토콜
브라우저끼리만 오디오, 영상 미디어, 데이터 등을 높은 품질로 교환 가능
브라우저간 통신이기 때문에 훨씬 빠르며 지연 시간이 짧다
webRTC의 signaling 서버로 webSocket 사용하는 것
작동 원리
1) 서로의 주소 공유
2) 보안 사항 및 방화벽 우회
3) 데이터 실시간 교환
- 이 때, 1)2)의 과정일 시그널링이라 함. 시그널링을 하기 위한 중간 역할을 해주는 서버가 시그널링 서버
시그널링 과정
1) NAT(Network Address Translation)
P2P 연결하려면 서로 IP 알아야하는데 개인IP를 그대로 노출하면 해킹의 위험이 있기 때문에 공인 IP를 외부에 노출함. (라우터가 개인 IP를 공인 IP로 변환해서 서버에 노출함) 변환된 공인 IP를 STUN이나 TURN 서버로 내보냄

2) STUN or TURN??
변환되어 온 IP를 식별하게 바꿔주는 서버가 STUN. 그러나 보호 정책이 강한 NAT이나 방화벽이 설정되어있는 경우 TURN 서버를 사용

3) ICE (Interactive Connectivity Establishment)
STUN ,TURN 서버를 통해 획득한 정보와 개인 정보를 활용해 최적 경로 찾음
```
자신의 사설 IP와 포트 넘버(원래 디바이스에서 가지고있음)
자신의 공인 IP와 포트 넘버 (STUN, TURN 서버로부터 획득 가능)
TURN 서버의 IP와 포트 넘버 (TURN 서버로부터 획득 가능)
```

위의 정보들을 ICE가 가지고 있다가 P2P 연결을 가능하게 하도록 최적의 경로를 찾아주는 프레임워크가 ICE 프레임워크

참고 : https://jangstory.tistory.com/10, https://gh402.tistory.com/45

질문

왜 webRTC와 webSocket을 둘 다 사용하였는지? (둘 중 하나만 사용해도 됐을텐데)
WebRTC의 장단점에 대해 말씀해주세요.
- 장점
  1) 중개 서버를 거치지 않기 때문에 빠르고 지연이 적음
  2) HTTPS 강제되기 때문에 보안 보장
  3) 비디오, 오디오 높은 품질
  4) 플랫폼 간 지원 : 브라우저가 WebRTC를 지원하는 경우 모든 데스크톱 또는 모바일 운영 체제에서 잘 작동합니다. 이러한 방식으로 소프트웨어 개발 비용을 크게 절감할 수 있습니다.
- 단점
  1) 메모리 많이 요구하여 큰 스케일의 작업 어려움 (트위치나 아프리카처럼 몇십만명이 동시에 들어오는 방송 불가)
  2) 추가 서버가 필요없는게 WebRTC의 장점이지만, IP를 알아야하기 때문에 STUN, TURN 서버가 필요함
WebRTC의 STUN 서버와 TURN 서버에 대해 설명해주세요.
- STUN : Session Traversal Utilities for NAT, 공개 주소를 발견하거나 Peer 간 직접 연결을 막는 등 ICE를 보완하는 프로토콜. 해당 Peer의 public IP 주소를 보내는 역할
- TURN : Traversal Using Relays around NAT, STUN의 확장으로, NAT 보안 정책이 너무 엄격하거나 NAT 순회를 하기 위해 필요한 NAT 바인딩을 성공적으로 생성할 수 없는 경우에 사용. 각 Peer들이 직접 통신하는 것이 아니라 릴레이 역할을 하게 해줌. 때문에 클라이언트와의 연결을 거의 항상 보장하지만 STUN에 비해 리소스 낭비가 심함.
WebRTC와 Web Socket 각각의 개념과 차이점에 대해 말씀해주세요.

🐤 JWT

JWT란?

JSON Web Token, 토큰 기반 인증
Header, Payload, Signature로 이루어짐
- Header : 사용할 타입과 알고리즘(HS512 등)
- Payload : Claim(서버에서 첨부한 사용자 권한 정보와 데이터, key-value 형식)
- Signature : private key로 서명한 전자서명. 헤더와 페이로드가 변조되었는지 확인하기 위해 사용되는 중요 정보. JWT를 신뢰할 수 있는 토큰으로 사용할 수 있는 근거가 됨
왜 나오게 되었는가?
- 세션 방식을 사용하면 세션ID를 HttpResponse의 쿠키값에 세팅해 사용자에게 보내야한다. 이 후 사용자가 권한이 필요한 요청을 서버에 보낼 때 세션ID를 보내고, 서버는 해당 세션ID가 서버에 있는지 확인하고 인가할지 정한다.
- 이 때 여러대의 서버를 사용한다면 다른 서버로 접근했을 시 인가가 불가능함!! (1번 서버에서 발급된 세션ID로 2번 서버에서 인가과정 시도할 수 없음.)
- JWT는 인가에 대한 정보를 토큰에 담고 있기 때문에, 사용자의 요청이 있을 시 토큰만 확인하면 되므로 세션 관리가 필요 없어짐 (세션 사용하면 서버의 세션 저장소에 인증 내용 담음)

장단점

장점
1) 토큰에 정보 담고 있으므로 별도의 저장소 필요 없음
2) 서버의 무상태 보장 가능 (unlike 세션)
3) 모바일에서도 작동 가능
단점
1) 토큰 길이가 길어서 인증 요청이 많아질수록 네트워크 부하 심해짐
2) 토큰 탈취 당하면 대처가 어려움
참고 : https://velog.io/@u-nij/JWT

질문

JWT의 개념과 알고 있는 주요 키워드에 대해 말해보세요.
- 토큰
- Access/Refresh
- Stateless
JWT 활용해서 로그인하는 과정을 설명해주세요
1) ID, PW 로 서버에 로그인 요청
2) 로그인 후 JWT 생성해 클라이언트에게 발급
3) Access Token 사용해 API 요청 -> 만료됐으면 Refresh Token 사용해 확인하고, 새로운 Access Token 발급 받음.

🐤 DB설계

질문

데이터베이스 설계할 때 특별히 주의한게 있다면?
- 스터디라는 행위와 통계를 어떻게 분리해서 테이블을 짤지?
  - 스터디 게시글 / 스터디 참가 명단 / 통계
  - 스터디 게시글 / 스터디 참가 명단 / 스터디 참가 이력 / 통계 / 채점표
  => 통계와 채점표를 따로 분리할지? 채점표는 개별 스터디에만 해당하고 통계는 마이페이지에서 볼 수 있는 스터디 누적 통계. 한 스터디 끝날 때마다 바로 통계에 누적할지 vs 채점표 테이블을 따로 만들지
  => 여러명이 한 사람에 대한 채점을 하는 것이므로 스터디 끝날 때 한꺼번에 처리한 후, 평균을 계산하는게 오차가 없으리라고 판단, 채점표 테이블 따로 만들어서 계산 후 통계에 넘김
mysql의 쿼리 속도 개선 방법엔 어떤게 있을까요?
- 실행계획(EXPLAIN) 사용해서 최적화... 근데잘모름;;;
- select * 지양하기
- IN 절 사용 (참고 : https://jojoldu.tistory.com/565)