알고리즘 문제 풀어보기
옹알이(2)
문제 설명
머쓱이는 태어난 지 11개월 된 조카를 돌보고 있습니다. 조카는 아직 "aya", "ye", "woo", "ma" 네 가지 발음과 네 가지 발음을 조합해서 만들 수 있는 발음밖에 하지 못하고 연속해서 같은 발음을 하는 것을 어려워합니다. 문자열 배열 babbling이 매개변수로 주어질 때, 머쓱이의 조카가 발음할 수 있는 단어의 개수를 return하도록 solution 함수를 완성해주세요.
제한사항
1 ≤ babbling의 길이 ≤ 100
1 ≤ babbling[i]의 길이 ≤ 30
문자열은 알파벳 소문자로만 이루어져 있습니다.
풀이 코드
function solution(babbling) {
var answer = 0;
var speak = ["aya","ye","woo","ma"];
for(i = 0; i < babbling.length; i++){
var bab = babbling[i];
for(var j = 0; j < speak.length; j++){
if(bab.includes(speak[j].repeat(2))){
break;
}
bab = bab.split(speak[j]).join(" ");
}
if(bab.split(" ").join("").length === 0){
answer++;
}
}
return answer;
}풀이 과정
babbling[i]를 bab으로 정의해주고 두번 연속으로 발음 할 경우에 반복문에서 탈출 할 수 있게 해준다. 이후 split을 이용해 말 할수 있는 단어를 제거하고 만약 bab의 문자 갯수가 0이라면 발음 가능한 단어이므로 answer에 1을 더해준다.
게임 개발의 시작
기획 단계
어떤 사람들이 과연 처음에 가장 초기단계에 모여서 기획을 하는가?
- PD(Project Director) : 한팀의 헤드역할을 하고 게임 전반의 방향성 결정.
- TD(Technical Director) : 서버팀, 클라팀등 모든 기술팀의 헤드역할. 전체적인 기술의 흐름 및 방향을 결정. 회사마다 부르는 이름이 다른 경우가 있다. TL(Technical Leader)등
- AD(Art Director) : 아트팀의 모든 방향성을 결정. 3D그래픽, 2D컨셉등 가능 여부 결정
개발 단계
- 서버팀은 그렇게까지 바쁘진 않다.
서버팀이 하는 일
- 인프라 구성
- 대규모 트래픽처리를 위한 분산 서버 구성
- 업데이트 방식 설계
- 서버 관리, 모니터링 툴 적용
- NAS, 내부망, 클라우드 세팅
- 팀원 모집
- 인프라, 클라우드, DBA, 웹, 게임서버
- 서버 로직 개발
- 오픈 컨텐츠 개발 대응
- 더미테스트, 부하테스트
- 내, 외부 QA 대응
라이브 단계(오픈 직전 + 이후)
오픈 직전
-
연습만 하던 서버 실전 인프라세팅을 하게됨. => 서버팀의 일이 점점 바빠짐.
-
서버팀의 1~2명은 하루종일 더미테스트 스크립트만 작성하고 모니터에 뜨는 로그만 쳐다봄.
-
더미 테스트 : 실제로 의미가 없지만 발생할만한 데이터의 형태를 임의로 케이스별로 만들어서 기능이 장상적으로 동작하는지 확인하는 것.
오픈 이후
- 첫 몇달간 이슈대응으로 고생하면 상대적으로 할일이 점점 적어짐.
- 트래픽의 경우는 점진적으로 감소하는것이 일반적이라서 크게 대응할 일이 없어짐.
- 업데이트의 경우에만 바짝 긴장
- 게임 컨텐츠 개발의 연속 x 100
- 미션추가, 전투 형태 변경, PVP 등
- 각종 이벤트 대응
- 외부 투자사, 콜라보를 통해 진행하는 이벤트 로직 개발 및 기존 코드에 적용
검증 (Verification) / 검정 (확인) (Validation)
- 많은 일을 하지만 주로 하는 일은 ‘검증’임.
검증 (Verification)
- 개발자의 관점, 개발한 API, 로직이 정상적으로 동작하는지 확인하는 행위
- 서버내에서 더미테스트, 부하테스트 등 각종 테스트 기법과 도구를 활용
검정 (확인) (Validation)
- 사용자의 관점, 개발한 API, 로직이 정상적으로 동작하는지 확인하는 행위
- 개발이 완료된 서비스에서 사용자의 요구사항을 충족하며 기대값을 보여주는지 확인
HTTP, TCP, 웹소켓
HTTP(Hyper Text Transfer Protocol)와 TCP(Transmission Control Protocol)
Request <-> Response 구조 + 비연결성
- Request가 없으면 Response를 보내지 않음.
-연결을 유지하지 않으므로 많은 트래픽을 빠르게 처리가능.
무상태(Stateless)
- 이전에 일어난 일(상태)을 저장하지 않음.
- 매번 새로운 요청을 처리.
- 세션, 쿠키등으로 해당 요청에 대한 정보를 임의로 저장해 처리.
HTTP 프로토콜의 메세지 구조
- HTTP는 Application layer에서 동작하는 프로토콜이며 transport layer(전송계층)의 위에서 동작.
- 전송계층의 대표적 프로토콜은 TCP/UDP가 있음.
- HTTP는 TCP든 UDP(HTTP/3)든 둘 중 하나의 연결을 통해서 동작
=> TCP/UDP없으면 동작 불가.- HTTP는 비연결성이지만 TCP는 연결지향성임.
- TCP는 데이터교환을 할 때 무조건 연결을 가짐.
- HTTP의 Req ↔ Res 가 발생할때 밑에서 TCP 연결이 이뤄짐.
- TCP는 3-handshake 라고하는 연결 과정을 가지고 있음.
TCP통신
- 양방향 통신 (Full-Duplex) 순서
- 서버는 접속 요청을 받기 위한 소켓을 연다. → Listen
- 클라이언트는 소켓을 만들고, 서버에 접속을 요청한다. → Connect
- 서버는 접속 요청을 받아서 클라이언트와 통신할 소켓을 따로 만든다. → Accept
- 소켓을 통해 서로 데이터를 주고 받는다. → Send & Receive ⇒ 반복!
- 통신을 마치면 소켓을 닫는다. → Close ⇒ 상대방은 Receive로 인지할 수 있다.
웹소켓(Websocket)
- HTTP프로토콜 위에서 동작하는 실시간 양방향 통신(Full-Duplex)
주요 특징
- 실시간 통신
- 웹소켓은 연결이 활성화된 상태에서 빠르고 지속적인 메시지 교환을 허용합니다. 이로 인해 애플리케이션은 사용자에게 지연 없는 인터랙션을 제공할 수 있습니다.
- 양방향 통신 (Full-Duplex)
- 클라이언트와 서버가 동시에 서로에게 메시지를 보낼 수 있습니다. 이는 한 쪽이 다른 쪽의 메시지를 기다리지 않고도 독립적으로 메시지를 송수신할 수 있음을 의미합니다.
- 지속적 연결
- 일단 웹소켓 연결이 수립되면, 그 연결은 클라이언트나 서버가 명시적으로 종료할 때까지 유지됩니다. 이는 오버헤드를 줄이고 빠른 데이터 전송을 가능하게 합니다.
- 낮은 오버헤드
- 웹소켓은 데이터 패킷의 헤더가 매우 작기 때문에 오버헤드가 낮습니다. 이는 효율적인 네트워크 자원 사용을 가능하게 합니다.
- HTTP와의 호환성
- 웹소켓은 HTTP 포트(80과 443)를 통해 작동하기 때문에 기존 웹 인프라와 잘 통합됩니다. 웹소켓 연결은 HTTP 연결을 통해 초기화되며, 이후 전이중 통신 채널로 전환됩니다.
TCP 패킷의 구조
- 소스 포트번호(16비트): 발신자의 포트 번호.
- 목적지 포트번호(16비트): 수신자의 포트 번호.
- 시퀀스 번호(32비트): 데이터 스트림 내에서 이 세그먼트의 위치를 식별하기 위한 번호.
- 응답 번호(32비트): 다음에 기대하는 데이터의 시퀀스 번호.
- 헤더 길이(4비트): 헤더의 크기를 나타냄.
- 예약된(3비트): 향후 사용을 위해 예약된 공간.
- 플래그(9비트): 연결 설정, 관리, 종료를 제어하는 다양한 플래그.
- 윈도우 크기(16비트): 수신자가 받을 준비가 되어 있는 버퍼의 크기.
- 체크섬(16비트): 오류 검사를 위한 값.
- 긴급 데이터 포인터(16비트): 긴급 데이터의 끝을 가리키는 포인터.
- 옵션(가변 길이): 필요에 따라 추가적인 옵션을 포함할 수 있음.
- 데이터(가변 길이): 실제 전송할 데이터.
- 웹소켓의 연결방법은 TCP의 연결방법 (3-way-handshake)를 닮아있음.
- 웹소켓은 기본적으로 TCP 연결 위에서 작동하기 때문에, 웹소켓 연결을 시작하기 전에 TCP의 표준 연결 방법인 3-way handshake가 수행됩니다. 하지만 웹소켓은 이후에 추가적인 핸드셰이크 과정을 진행하여 웹소켓 특유의 연결을 완성합니다.
