[TIL #30] 모의 면접을 준비하며

모의 면접에서 메인 토픽뿐만 아니라, 그 연계질문까지 공개하는 건 이례적이라는 생각이 든다.

애초에 미리 고지한다고 그 꼬리로 가는 것이 가능한 건지 의문스럽기도 하다.

대답에 따라 꼬리 무는 것도 달라지지 않나.

그 의도는 모르겠으나, 일단 준비된 질문들에 대해 생각해 보자.

 

 

1. 전송 계층 프로토콜에 대한 설명
   - 꼬리1 : IP의 한계
   - 꼬리2 : 오류 제어, 흐름 제어
2. 대칭키, 비대칭키 암호화에 대한 설명
   - 꼬리1 : 혼합 암호 사용
   - 꼬리2 : HTTPS
3. 로드 밸런싱에 대한 설명
   - 꼬리1 : 로드밸런싱 알고리즘
   - 꼬리2 : 헬스 체크

 

 

전송 계층 프로토콜

전송 계층은 4번째 계층으로 종단 간 통신을 담당한다.

신뢰성 있는 통신을 위한 여러 기능(흐름 / 혼잡제어 및 오류 검출 및 수정)을 수행한다. 

프로토콜엔 TCP와 UDP가 있다.

 

TCP

연걸 지향적 프로토콜로 통신 전 연결을 설정한다.

신뢰성 있는 통신 보장을 위해 다양한 제어 메커니즘이 존재한다.

데이터의 순서 보장을 위한 시퀀스 넘버를 사용한다.

핸드쉐이크를 통해 연결 설정 및 해제

 

 

UDP

IP의 특성을 그대로 물려받은 비연결성 프로토콜

신뢰성은 낮으나 속도가 빠르므로 스트리밍 등에 사용

 

 

IP의 한계

IP는 기본적으로 신뢰할 수 없고 연결을 설정하지 않는다.

회복을 위한 메커니즘도 존재하지 않는다.

UDP가 이를 계승한 프로토콜이라고 볼 수 있으며,

이러한 특성이 TCP와 같은 연결형 프로토콜의 등장에 영향을 끼쳤다.

 

흐름, 혼잡, 오류 제어

• 흐름 제어
  • 수신 측의 한계를 넘지 않는 만큼의 속도로 데이터를 전송할 수 있게 함
    • 슬라이딩 윈도우를 통해 한번에 전송 가능한 데이터 양 조절
    • 수신 측에 이 윈도우 사이즈를 미리 알려준다
• 혼잡 제어
  • 네트워크의 혼잡 상황을 보고 데이터 전송을 조절
    • 슬로우 스타트로 서서히 전송량을 올린다
    • 빠른 재전송
      • 순서대로 도착하지 않으면 유실된 번호에 대한 ACK를 계속 보낸다
      • 송신 측에선 중복을 감지하고 재전송
    • 빠른 회복
      
      • 혼잡 감지 시 반으로 줄이고 선형 증가
• 오류 제어
  • 통신 중 발생할 수 있는 오류를 검출하고 수정하여 통신의 신뢰성 보장
    • 자동 재전송 요청(ARQ)나 패리티 비트 등을 활용하여 요류 제어
    • 빠른 재전송 및 빠른 회복도 오류 제어의 일종이라고 볼 수 있음

 

 

 

 

대칭키 /  비대칭키 암호화

대칭키

하나의 키로만 암복호화 수행

속도가 빠르고 구현이 간단

AES가 대표적 대칭키 알고리즘

키 분배가 어려울 수 있음

 

비대칭키

개인키와 공개키의 2개의 키를 사용

공개키로 암호화된 데이터는 개인키로만 복호화 가능

속도가 느리고 복잡하다

키 분배 문제 해결

 

소인수분해를 활용한 RSA

타원 곡선을 활용한 ECC

HTTPS에서 SSL/TLS의 형태로 사용되고 있다

 

 

혼합 암호 시스템

속도와 안전을 모두 챙기기 위함

대칭키로 데이터를 암호화

수신 측의 공개키로 대칭키를 암호화

 

이를 같이 보내 수신 측은 개인키로 키를 복호화하고,

그 키로 데이터를 복호화해 사용

 

대칭키를 통한 암복호화의 효율을 챙기고,

비대칭키로 키 교환의 리스크를 줄였다

 

 

HTTPS

기존 HTTPS에서 SSL/TLS를 통해 보안성을 강화

 

클라가 연결을 요청하면 서버는 인증서를 제공해 신원 검증

세션키 생성해 교환 후 보안 통신 시작

 

SSL보다 발전된 형태인 TLS를 많이 사용

 

 

 

로드 밸런싱

트래픽 등의 부하를 분산시켜 보다 안정적인 처리를 가능케 하기 위한 기술

 

한 서버에 과도한 부하가 걸리면 정상적인 처리가 불가능할 수 있기 때문에,

분산 처리는 매우 중요

 

서버 하나가 죽어도 다른 데에서 분산 처리가 가능하고

확장이 용이함

 

소프트 및 하드 양쪽에서 로드 밸런싱을 수행할 수 있다.

L4 로드 밸런서가 전송 계층에서 빠른 분산을 할 수 있어 게임 서버 등에 사용

 

알고리즘

• 라운드 로빈
  • 순차적으로 분배
  • 구현이 간단하다
  • 가중치를 부여할 수도 있음
• 연결의 수가 적거나 응답 시간 기준으로 분배
• 해싱

 

헬스 체크

로드 밸런서가 서버의 상태를 주기적으로 확인해,

살아있는 서버에만 요청을 보내도록 함

 

핑을 주기적으로 보내거나 포트가 열려있는지 확인하는 것으로 가능

세션을 통해 동일한 서버와의 연결을 지속 가능

매번 밸런싱 하는 과정이 사라져 더 효율적일 수 있음

 

헬스 체크에 실패 시 로드 밸런서는 해당 서버를 풀에서 제거

예비 서버가 있을 경우 대체해 고가용성 확보