241029 TIL - 주특기 플러스 wk2 2 + 면접질문 정리

일퀘 1~3일차

프로토콜 버퍼에 제발 익숙해지자

241021 TIL 내가 내 손으로 썼는데도 불구하고 .proto 파일만 보면 '이게 뭐야?' 라고 생각하는 통에 걱정이 태산.

프로토콜 버퍼의 개요도 241022 TIL 에다가 직접 써놨는데도 불구하고 기억이 나지 않아서, 그냥 구글링을 다시 해서 잘 정리된 블로그를 참고해 보았다.
역시 남의 블로그가 최고야

일단 프로토콜 버퍼는 구글에서 만든 데이터 직렬화 규격이다.

---

면접 질문 정리

1. 전송계층의 프로토콜

기억이 나지 않을 땐 항상 OSI 7 Layer CS세션 글을 보자.

• 전송계층 = L4. 포트번호와 전송방식(TCP/UDP)을 결정해주는 계층. 이 계층에서 TCP 헤더가 붙는다.

참고 블로그

전송계층의 프로토콜 : TCP, UDP, STCP, RTP, RTCP 등

• TCP: 신뢰성, 연결지향적. 데이터의 정확한 전달이 목표. 3 way handshake 연결 수립.
  -> 전송단위: Segment
• UDP: 비신뢰성, 비연결성, 실시간. 데이터의 빠른 전달이 목표.
  -> 전송단위: Datagram

SCTP, RTP, RTCP - 패킷 기반 실시간 전송 프로토콜들

• SCTP: TCP와 UDP의 특성을 결합한 프로토콜. TCP처럼 연결지향성.
• RTP: UDP 위에서 돌아가는 프로토콜. 데이터그램에 순서번호를 추가한 것.
  -> UDP의 패킷유실, 순서오류 등의 문제 해결
• RTCP: RTP 제어용 프로토콜

꼬리질문 - IP의 한계

IP의 한계: 비연결성, 비신뢰성, 비식별성

1. 비연결성: 패킷을 받을 대상이 없거나 서비스 불능상태여도 패킷을 전송함
   (ex. 컴퓨터 꺼진 경우)
2. 비신뢰성: 중간에 패킷이 사라지거나, 보낸 순서대로 도착하지 않을 수 있음
3. 비식별성: 한 컴퓨터에서 여러 어플리케이션들이 같은 IP를 쓰는 상황에서 도착한 패킷이 어떤 어플리케이션 것인지 구분 못함 (이거 구분하려면 포트번호 필요함)

꼬리질문 - 오류 제어, 흐름 제어

참고 블로그

• 오류제어: 데이터 변형, 순서 어긋남 등 통신장애가 발생하지 않도록 오류를 검출하고 정정하는 것.
  -> 확인 응답: 수신측으로부터 ACK플래그를 받지 못하면 오류로 판단
  -> 시간 초과: 일정 시간 내 ACK 플래그가 안 오면 오류로 판단

• 흐름제어: 송수신자 간 데이터 처리 속도 차이를 해결하기 위해, 수신자 상황에 따라 송신자의 데이터 전송량을 조정하는 방법.
  -> 정지-대기: 하나의 데이터 전송 후 다음 데이터 전달 전에 확인 응답을 기다리는 것
  (데이터링크 계층의 정지-대기 방법과 동일)
  -> 슬라이딩 윈도우: 수신측에서 설정한 크기만큼 확인응답 없이 전송 가능하게 하는 것

---

2. 대칭키, 비대칭키 암호화

• 대칭키 암호화: 암호화와 복호화에 같은 키를 사용하는 방식
• 비대칭키 암호화: 암호화와 복호화에 별도의 키를 사용하는 방식.
  -> 일반적으로 암호화에는 공개 키, 복호화에는 비밀 키 사용하지만, 반대일 수도 있다.
  관련된 키 중 하나가 비공개여서 어느 한 과정을 해커가 알 수 없다고 보는게 맞다.

꼬리질문 - 혼합 사용

참고 블로그

• 웹사이트 암호화에 사용되는 SSL, TLS 통신은 대칭키/공개키 방식 혼합 사용!
  SSL: 보안 소켓 계층 (Secure Sockets Layer)
  TLS: 전송 계층 보안 (Transport Layer Security)
  -> 통신 자체는 대칭키 암호화인데, 이 대칭키를 비대칭키 암호화 해버려서 결국 비밀키 없이는 아무것도 알 수 없게 만든 것이 대칭키, 비대칭키의 혼합 사용

꼬리질문 - HTTPS

241008 CS세션

• HTTPS: HTTP의 보안 문제 해결을 위해 탄생한 프로토콜. SSL/TLS 구조로 구현.
  HTTPS는 인증서와 디지털서명 개념이 있어, 서버가 공개키를 주면서 공개키에 대한 인증서를 같이 보내준다.
  인증서에 서명값이 들어있는데, 클라이언트는 이 서명값을 바탕으로 인증서 검증 가능.

서명값 : 인증서 내용에 대한 해시값을 인증기관의 개인키로 암호화 한것

1. 인증기관의 공개키는 공개되어 있어 서명값을 공개키로 복호화 할수 있다
2. 서명값 복호화하면 인증서 내용에 대한 해시값을 얻을 수 있다
3. 복호화한 해시값이 실제 인증서를 해싱한 값과 일치하는지 확인해보자
4. 일치하면 전달받은 인증서는 인증기관의 암호화를 거친게 맞는 것!

-> SSL, TLS: 인터넷에서 통신을 암호화하여 제삼자가 데이터를 훔쳐보거나 조작할 수 없게 한 기술

사용자 - 사이트의 인증서 사용 과정

1. 사용자가 브라우저를 통해 사이트에 접속
2. 사이트는 발급받은 인증서를 전달
3. 인증기관의 공개키로 해독
4. 해독하면 사이트 정보와 서버의 공개키가 나옴 -> 이 서버 공개키로 대칭키를 암호화!
5. 서버 공개키로 암호화된 대칭키 전송 - 사이트 개인키로 암호화된 대칭키 해독

---

3. 로드밸런싱

참고 블로그
참고 블로그2

• 로드밸런싱: 서버나 네트워크의 부하를 분산하여 성능, 가용성, 신뢰성을 높이는 작업
  L4, L7의 스위치가 로드밸런싱을 한다. 그래서 L4, L7 로드밸런서 라고도 한다.
  (스위치: 데이터를 어딘가로 보내주는 역할을 하는 하드웨어)
• L4 로드밸런싱: TCP/UDP 프로토콜 기반으로 클라이언트-서버 간 트래픽 분산
  -> 클라이언트-서버의 IP주소/포트번호 기반으로 로드밸런싱 수행
• L7 로드밸런싱: HTTP/HTTPS 프로토콜 기반으로 클라이언트-서버 간 트래픽 분산
  -> IP, PORT 외에도 요청 내용(URL, 헤더, 쿠키 등)을 기반으로 로드밸런싱 수행

꼬리질문 - 로드밸런싱 알고리즘

1. 라운드로빈 - 요청을 로드밸런싱 대상 서버에 순서대로 할당

-> 1번 요청은 1번 서버, 2번 요청은 2번 서버에 할당하는 방식
대상 서버 성능이 동일하고 처리시간이 짧다면 균등분산 가능
단점: 동적 분산이 아니라서 다운된 서버에다 할당해 버리기도...

2. 최소 연결 - 최소 라우팅 서버를 우선적으로 배치

-> 연결 수가 가장 적은 서버로 네트워크 연결방향을 지정
동적인 분산 알고리즘이라 동적으로 변하는 요청에 대응 가능
단점: 대상서버의 성능이나 부하를 고려하지 않아 불균형한 부하분산😖

3. 해시 - 특정 클라이언트는 특정 서버로만 할당

4. GSLB - 글로벌 서버 로드 밸런싱. 다른 지역 서버에 뿌리는 것!

꼬리질문 - 헬스체크

• 헬스체크: 서버가 정상적인 동작을 하고있는지 모니터링 하는 것
  -> ping 체크, 모니터링 서버에서 HTTP 요청, SSL/TLS 인증서 유효기간 확인 등
  -> Zabbix, Nagios, Prometheus 같은 소프트웨어 존재