Bin_S+StudyRoom

25년 4월 15일 유나이트 서울에 방문하였다.

키노트에서 유니티 6에서 추가된 기능들을 소개하고 있다.

첫번째 섹션에서 안드로이드 ANR에 대한 이야기를 듣고왔다

ANR이 왜 일어나는지 디버그를 통해 분석하는게 일반적이며 주로 일어나는 경우에 대해서 설명해 주셨다.

이외의 섹션은 따로 게시물을 작성하여 남겨놓으려 한다.

티셔츠와 레고를 받았다. 궁금했던 기술에 대해서 자세하게 알 수 있어서 좋았다.

• TCP/UDP 차이점 중에 보안 관련된 이슈
  • TCP
    • 호스트 사이에 세션이 설정되는 연결 지향
    • 보내는 순서 유지
    • 데이터 중복, 손실 없음
    • 승인 및 순차적인 데이터 전송을 통해 신뢰성 보장
    • 패킷 흐름 제어
    • 1:1 통신만 지원
  • UDP
    • 호스트 사이에 세션이 설정되지 않은 비연결성
    • 보내는 순서 유지하지 않음
    • 데이터 중복, 손실 가능
    • 전송 승인이나 데이터 정렬 보장하지 않음
    • 흐름 제어 없음
    • 1:1, 1:N, M:N(다대다) 통신 지원
  • 보안상 차이점
    • UDP는 stateless로 Request없을 때 Reply 수신하지 않음
    • UDP는 인증이 없음
    • UDP는 암호화가 없음 (대칭키 사용)
    • UDP는 Spoofing 공격에 취약함
• OSI 설명
  • 네트워크에서 통신이 일어나는 과정을 7단계로 나눈 것
    • 물리 계층 (L1, Physical Layer)
      • 이 계층에서 사용되는 통신 단위는 비트이며 컴퓨터의 랜카드가 전기 신호를 받아 신호가 강하면 1, 약하면 0을 반환
    • 데이터 링크 계층 (L2, Data Link Layer)
      • 이 계층에서는 MAC 주소를 통해 내 컴퓨터와 다른 사람의 컴퓨터와 통신함 데이터 단위는 프레임이다.
        • 프레임의 구성 : 목적지 MAC 주소 + 출발지 MAC 주소 + 네트워크 데이터(패킷) + 트레일러
        • MAC 주소 : 랜카드의 ID, MAC주소는 한 자리당 4bit씩 12자리로 구성
    • 네트워크 계층 (L3, Network Layer)
      • 데이터 링크 계층의 데이터가 네트워크 계층의 데이터이다. 이 계층에서 IP주소가 사용된다. 데이터 단위는 패킷이다.
        • 패킷의 구성 : 목적지 IP 주소 + 출발지 IP 주소 + 전송 계층 데이터 (세그먼트)
    • 전송 계층 (L4, Transport Layer)
      • 데이터 전송을 위해서 포트 번호를 사용함. 대표적인 프로토콜로 TCP, UDP가 있음. 포트를 통해 어떤 프로그램이 이 데이터를 처리해야 되는지 알 수 있다.
        • TCP : 3-way handshake를 통해 데이터를 받았는지 확인하고 연결 맺었는지 확인
        • UDP : 연결 맺고 난 후 별도의 확인작업 없이 데이터를 보냄
        • 세그먼트의 구성 : TCP 헤더 (목적지 Port 주소 + 출발지 Port 주소) + 세션 계층 데이터
        • 데이터 그램의 구성 : UDP 헤더 (목적지 Port 주소 + 출발지 Port 주소) + 데이터
    • 세션 계층 (L5, Session Layer)
      • 세션 계층은 TCP/IP 세션을 만들고 없애는 계층이다. 이를 통해 통신 장치 간 상호작용 및 동기화를 제공하고 연결 세션에서 데이터 교환과 에러 발생 시의 복구를 관리
    • 표현 계층 (L6, Presentation Layer)
      • 표현 계층은 데이터를 어떻게 표현할지 정하는 계층이다. 데이터의 형식상 차이를 다루는 부담을 응용 계층으로부터 덜어준다.
    • 응용 계층 (L7, Application Layer)
      • 사용자와 가장 밀접한 계층으로 인터페이스 역할을 하며 HTTP, FTP, SMTP, POP3, IMAP, Telnet등과 같은 프로토콜이 있다. 포트를 실제로 처리하는 계층은 여기서 이루어지고 응용 계층은 응용 프로세스와 직접 관계하여 일반적인 응용 서비스를 수행한다.
• AES-256 암호화/복호화 이슈
  • AES-256은 대칭키 방식으로 암호화 및 복호화에 사용되는 키 값이 동일함
  • AES 128, AES 192, AES 256이 있는데 뒤에 숫자는 바이트를 의미하고 키 값이 길면 무작위 대입 공격에 유리하다는 자엄이 있다.
  • AES키를 하드 코딩하기보다는 키 값에 사용될 값을 숨겨야 한다 방법은 여러가지 인데
    • AOS는 Keystore를 사용해 키 저장, IOS는 Keychain을 사용해 키 저장, Unity IL2CPP로 빌드하여 추가 난독화를 적용
    • 클라우드 KMS를 사용하여 키를 클라우드에서 가져오고 앱 메모리에만 유지
    • 사용자의 로그인 정보를 기반으로 키를 생성하여 고유한 보안 계층을 추가한다.
• map/set 자료구조
  • map
    • key/value 의 쌍으로 이루어진 트리임, 검색을 빠르게 하고 싶은 경우 사용하며 key를 기준으로 정렬된 상태여서 검색이 빠르다 (key값이 중복 되지 않는다)
  • set
    • key만 있는 map이라고 보면 된다, 정렬되어 있기 때문에 검색이 빠르다 (key 값이 중복 되지 않는다)
• 에셋 번들 관리 및 만드는 법
  • C# 스크립트는 에셋 번들로 만들 수 없음 (비쥬얼 스크립트는 가능)
  • 에셋 번들 태그를 설정하고 동일한 태그를 가진 에셋들은 하나의 번들 파일로 패키징 된다.
  • 에셋 번들을 빌드하면 번들 파일 외에 Manifest 파일이 생성되어 에셋 번들 간의 의존성을 추적한다.
  • 에셋 번들 로드
    • 비동기 로드 또는 로컬/원격 로드가 있다
    • 비동기 로드 → 에셋 번들 로드할 때 메인 스레드를 차단하지 않고, 별도의 스레드에서 비동기로 작업을 수행한다. 즉, 작업이 완료될 때까지 앱이 멈추지 않고 계속 실행
      • 장점 : 로드 중에도 게임 정상 작동, 프레임 레이트 유지, 대규모 에셋을 로드할 때 성능 저하 방지
      • 단점 : 로드 완료 시점을 정확히 알기 위해서 코루틴 또는 콜백을 사용해야 함
    • 로컬 로드 → 에셋 번들을 로드할 때 디바이스의 로컬 스토리지에서 에셋 번들을 읽어오는 방식
      • 장점 : 네트워크 연결이 없어서 빠르고 안정적, 오프라인에서도 작동 가능
      • 단점 : 모든 에셋을 미리 포함해야 해서 앱 크기가 커질 수 있음, 콘텐츠 업데이트를 위해 전체 앱을 다시 배포해야 함
    • 원격 로드 → 에셋 번들을 원격 서버에서 다운하거나 스트리밍 방식으로 로드하는 방식 (UnityWebRequest 사용)
      • 장점 : 앱 설치 후에도 새 컨텐츠를 제공하거나 업데이트 가능, 초기 앱 크기를 줄일 수 있음
      • 단점 : 네트워크 연결 필요, 연결 상태가 나쁘면 속도가 느림, 서버 설정 및 관리를 추가적으로 해야함
  • 에셋 번들 관리
    • 의존 번들을 먼저 로드 (Manifest 파일 읽기) 해야 한다.
    • 서버에서 에셋 번들의 해시 또는 버전을 관리하여 클라이언트가 최신 번들을 로드하도록 구현해야하는데 Manifest의 해시 정보를 사용하여 UnityWebRequest를 사용해 필요한 번들만 다운로드한다.
• 클라이언트에서 스테이지 데이터 받을 때 바뀐 스테이지는 어떻게 아는지
  • 각 스테이지 파일의 해시 값을 생성하여 관리
    • 로컬에 저장된 파일의 해시를 계산한 후 서버의 해시와 비교해서 다운
    • 장점 : 파일 내용이 변경 되면 정확하게 판단 가능, 이름이 같아도 내용이 다르면 탐지 가능
    • 단점 : 해시 값을 비교해야 해서 처리 시간 추가
  • 마지막 수정 시간 비교
    • 서버에서 스테이지 파일의 마지막 수정 시간을 가져와서 수정 시간이 로컬에 저장된 수정 시간과 다르면 다운
    • 장점 : 해시 계산보다 성능이 좋음, 간단하게 구현 가능
    • 단점 : 내용이 동일하지만 수정 시간이 달라질 경우, 불필요한 다운로드 발생
• http 통신 과정
  • 요청 준비
    • 클라이언트에서 요청 준비 (URL 지정, HTTP 메소드 선택, 헤더와 데이터 설정)
  • 요청
    • 클라이언트에서 서버로 요청
  • 요청 처리
    • 서버는 요청 내용을 분석하고 필요한 데이터를 처리
  • 응답 반환
    • 클라이언트에게 요청 결과 반환
  • 응답 처리
    • 클라이언트는 응답 데이터를 사용해서 화면에 출력하거나 추가 작업을 수행
• 옵저버 패턴이 정확하게 뭔지
  • 주체(Subject)에 관찰자(Observer)를 등록
  • 주체의 상태가 변경되면 등록된 모든 관찰자들에게 알림을 보냄
  • 관찰자들은 주체로부터 상태 정보를 가져와 각자의 방식으로 갱신하거나 작업 수행

지난날의 내 잔디가 전부 사라졌다. 퇴사하게 되면서 프로젝트에서 제외됨으로서 잔디가 모두 사라졌다..