240910 챌린지반 - 개발자 커리어 로드맵

개발자는 범용적인 것, 보편적인 것도 알아야 한다.

TCP 기본 지식

Segment Structure

Max Segment Size

• Window Scaling - 한 패킷에 많이 보내자! 해서 점보패킷 보낼때 사용. 대용량 데이터 전송 시 성능 향상에 도움. ACK 패킷 횟수를 줄여 네트워크 오버헤드를 감소시킴. SYN 패킷을 보낼 때 매우 크게 TCP 윈도우 크기를 지정할 수 있다.

TCP는 순서보장이 된다. 이건 아주 중요한 것임! 다만 순서보장은 라우터를 지나면서 랜덤이 되는 건 맞는데 후에 reassemble 하는 것임.

Timestamp 기능 - 게임 이벤트의 동기화와 순서 유지에 중요하다. 대규모 게임은 여러 서버에 분산되어 있어서, 서로 다른 서버 간 이벤트 순서를 정확히 결정하는 데 타임스탬프가 꼭 필요하다.

• 나는 핑이 많이 튀고 상대는 핑이 적게 튄다면, 나는 인터넷을 잘못 만났으니 항상 패배해야 할까? -> 이럴 때 타임스탬프가 필요하다! 레이턴시 이슈로 플레이어가 부정적 경험을 하는 것을 줄일 수 있다.

• 혼잡 제어 - 네트워크 성능 최적화에 필요하다. 교통혼잡 시 신호 길이를 조절하는 느낌. 클라와 서버 간 양방향 트래픽을 모니터링 한 뒤 네트워크 상태에 따라 동적으로 데이터 전송 속도를 조절하는 기능.
  (궁금하면 RFC 5681을 참고할 것)
  RTT라고 Round Trip Time 이라는 것이 있다. 클라이언트의 레이턴시를 찍어보고 내 생각보다 레이턴시가 크면 네트워크 상태가 나쁜 것이니 업데이트 주기를 길게 한다. 그러나 네트워크 상태가 좋으면 그럴 필요 없으니 주기를 짧게 해도 OK.

그럼 UDP는 아예 안 쓰나요? 그런건 아니다.

스타크래프트에 UDP 모드라는 것이 있다. 지금은 TCP만큼 많이 쓰이지 않을 뿐.
TCP와 UDP는 장르 구분이 명확해서 그렇다. 순서 보장되고 안정적인게 좋으면 TCP를 선택하는 것이고, 인생 뭐 있어? 빠른게 최고지! 속도 가즈아! 하면 UDP를 쓰곤 했었다. 한방이 중요하고 빠르기가 가장 중요한 FPS나 실시간 격투게임 중에서는 UDP 기반으로 통신하는 경우도 많았다.

RUDP라는 것이 있었다. 공식 프로토콜은 아니지만 TCP의 안정성, UDP의 속도라는 슬로건으로 한창 쓰였던 것이 있다.

소켓 프로그래밍

TCP 기반으로 가게 된다면 소켓 프로그래밍은 필연적으로 알 수 밖에 없다. L4에서 한꺼풀 더 헤더를 입혀 캡슐화 한게 L7이다. HTTP, SSH 등. 소켓 프로그래밍은 반응성을 위해 많이 한다.

• 바이트 조작 (Byte manipulation) ★★★★★
  네트워크를 통해 전송되는 데이터의 효율적인 처리와 최적화에 필요하다.
  게임 데이터의 압축, 압호화, 직렬화 등에 사용되며 무조건 알아야 한다!

• 주소 변환
  소켓 프로그래밍에서 UP 주소와 포트 번호를 다루는 데 필요하다.

• 디스크립터 ★★★
  리소스에 대한 일종의 식별자. 소켓 연결을 관리하고 다중 클라이언트 처리 시 필수 개념

• BSD Socket ★★★★
  유닉스 계열에서 사용되는 소켓 API
  네트워크 프로그래밍의 기본이 되는 개념이니 꼭 알아야 한다

• Windsock
  윈도우 기반에서 사용되는 소켓 API

프로그래밍 기법 & 멀티스레딩

• 고프의 디자인 패턴 한번 읽어볼 것. 면접에 심심찮게 나온다.

• TDD
  테스트 기반으로 개발하는 방법론. 버그를 줄이고 코드의 안정성 향상에 중요. CI/CD의 CI에 중요하다.

• Dump Analysis
  서버 크래시나 성능 문제 디버깅에 필수적. 보통 덤프 파일을 분석하며 어떤 문제가 일어난 것인지 / 원인이 무엇인 지 분석한다.
  -> 이거는 할 줄 알면 정말 좋다!

• 동기화 기법

• TLS (Thread Local Storage)
  쓰레드는 일꾼이다. 그 쓰레드 마다 로컬 스토리지가 있다는 것. 쓰레드일꾼 자신의 담당구역이라고 생각하면 된다.

• Windows와 P스레드
  P스레드는 진짜 유명하다.

• 동시성 문제 해결하기 위한 전략 1: Task-based
  멀티스레딩의 고급 추상화 방식 중 하나. 작업을 정의하고 스레드 풀에서 실행.
  개발자가 스레드 관리하는 대신 시스템이 작업을 스레드에 얹어준다.
  IoCP

• Actual Model
  멀티스레드 기반 프로그래밍이 버그 유발이 많고 버그 원인 파악도 어려워 대안으로 떠오른 모델. 복잡한 게임 로직을 안전하게 구현할 수 있다.
  각 액터는 자신의 상태를 가지고 독립적으로 동작하는 것이 특징.
  액터 간 직접적 상태 공유 없이 메시지 전달로만 통신한다는 게 특징.

• Reactive Model

• 비동기
  작업의 완료를 기다리지 않고 다음 작업을 수행할 수 있게 하는 패러다임
  I/O 바운드 작업이나 시간이 오래 걸리는 작업을 효율적으로 처리한다.
  -> 전체 시스템의 성능과 반응성을 향상시킬 수 있다!
  특히 게임서버는 네트워크 통신, DB 쿼리 등의 I/O 작업 빈도가 굉장히 높다
  그래서 비동기 프로그래밍 기법에 익숙해지는 것은 굉장히 중요!
  -> 그래서 콜백함수 개념도 나오는 것이다. 맡기고 맡기고 맡기고... 해서 그 작업 다 됐을때 나를 불러줘! 라는 것임.

게임서버는 ORM 생각보다 많이 안 쓴다!

서브쿼리, JOIN, UNION 등에 대해 생각보다 잘 알아야 한다! 성능 문제 때문에
최근 대세는 PostgreSQL. 벡터 검색도 되고 시계열도 되고...

Stateful한 서버는 kafka나 RabbitMQ 같은 메시지 큐 쪽은

Spark - 데이터 클러스터링

내가 아는 쓰레드는 이건데?