클라이언트와 서버란??

참고 : 여러 블로그

 

 

주제 

 

1. 컴퓨터 세계에서 서버와 클라이언트는 무엇인가?
  - 서버, 클라이언트 각각의 개념과, 서버 클라이언트 구조에 대해 자유롭게 조사해주세요.

2. 웹 어플리케이션 서버와 게임서버의 공통점과 차이점은 무엇인가

  - 어떤 공통점과 차이점이 있는지? 게임 서버에서 중요하게 다루어야 하는 내용은 무엇인지 조사해주세요.

 

-------------------------------------------------------------------------------------------------

 

1. 컴퓨터 세계에서 서버와 클라이언트는 무엇인가

 

클라이언트는 '서비스 요청자', 서버는 '서비스 제공자' 라고도 불리는데 클라이언트는 요청하고 서버는 응답하는 관계이다.

 

 - 클라이언트란? > 클라이언트는 서버의 서비스를 받아 사용하는 장치, 프로그램을 말한다

클라이언트는 서버에서 받은 서비스를 사용하는 사용자로, 크게 장치 또는 프로그램이 될 수 있다.

'클라이언트 장치' 는 최종 사용자가 웹에 접속하는데 사용자는 시스템으로 데스크탑, 노트북, 스마트폰, 테블릿 등을 예로 들 수 있다.

'클라이언트 프로그램' 은 사용자가 웹을 통해 요청할 수 있게 해주는 프로그램으로 웹 브라우저를 예로 들 수 있다.

 

 - 서버란? > 서버는 네트워크를 통해 클라이언트에게 서비스를 제공하는 시스템이다.

 

서버는 일반적으로 클라이언트의 요청에 대해 응답해주는 시스템으로, 간단하게 무엇을 제공해 주는 입장이라고 생각하면 된다. 우리가 ㅋ컴퓨터를 할 때 일반적으로 웹 브라우저를 통해 정보를 볼 수 있는데 이것은 서버로부터 정보를 받아 우리가 볼 수 있는 것이다.

 

웹의 시각에서 한번 예시를 들어보면 웹 브라우저에 www.google.co.kr이라는 URL을 입력하면 그 URL에 해당하는 웹 서버로 요청이 가게되고  해당 웹 서버는 웹 브라우저의 요청을 확인한 후에 DB에서 www.google.co.kr이라는 도메인을 가진 웹 사이트를 찾아 우리에게 제공하여 웹 브라우저에 우리가 요청한 구글 페이지가 보여지게 된다. 

 

 

서버는 클라이언트로부터 요청을 받아 응답을 내려주고 클라이언트는 서버에 데이터를 요청하고 응답을 받는데 이 개념을 재화에서 가져와 서비스라고 일컫는다.

서비스의 종류에 따라 파일 서버  /  메일 서버  /  어플리케이션 서버 등등 으로 나눠진다.

그러면 연결하는 방식은??

 

기본적으로 서버 프로그램을 따로 두는지 또는 하나로 합친 것인지 나뉜다.

 

 서버기반 모델 - 전용 서버를 두는 것

 * 안정적인 서비스 제공 가능
 * 공유 데이터의 관리와 보안이 용이
 * 서버 구축비용과 관리비용이 든다는 단점

 p2p 모델 - 별도의 전용 서버 없이 각 클라이언트가 서버역할을 동시에 수행하는 것

 * 서버 구축 및 운용 비용을 아낄 수 있는 장점
 * 자원의 활용을 극대화 할 수 있음

 * 자원의 관리가 어려움

 * 보안이 취약하다는 단점

 

 

  - 서비스의 종류에서 이제 웹 어플리케이션 서버와 게임 서버의 공통점과 차이점은???

공통점 > 클라이언트 - 서버 구조를 이용하여 서비스를 제공 하는 것.

 

차이점 > 보통 게임은 데이터의 변화량과 응답 속도에 중점을 두고 웹 어플리케이션 서버는 데이터 이용의 효율성과 유지 보수의 편의성에 중점을 둠.

 

 

 

 

 - 게임은 반응성이 웹보다 훨씬 더 중요한 분야이다. connection을 맺고 끊는 비용, 생성되고 필요한 작업을 위해 매번 db를 질의하는 비용 모두 줄여서라도 반응성을 유지하는 것이 더 중요.

 

그렇다보니 표준이 아닌, 게임마다 다른 TCP 프로토콜 위에 게임별 프로토콜이 각기 다른 모습으로 구현이 되었는데

 

동적 컨텐츠인 게임은, 웹처럼 다수의 사용자에게 유사한 HTML 코드를 동일하게 전송 할 수 없었고, 실시간으로 변동되는 데이터를 다뤄야했기에, 다른 방향으로 발전.

 

 

제한된 서버 자원을 잘 활용해야만 동접이 높은 게임을 만들 수 있기 때문. 게임 내에서 수많은 동작이 실시간으로 이루어지는데, 이 로직들을 최대한 가볍게 짜고, 의도치 않은 큰 연산이 일어나지 않아야 렉이 생기지 않기 때문이다.

 

실제로 온라인 게임의 렉(latency)은 대부분 네트워크 환경으로 인한 문제보다는 서버 내부의 로직이 도는 시간보다 더 많은 처리 요청이 발생해 처리가 밀리면서 발생한 현상이었다. 멀티스레드로 구현하면서, 블러킹 포인트를 만들어 생기는 경우도 없었다고 할순 없다.

이는 패킷을 처리하고, 사용자에게 응답하기 까지의 시간을 유지하지 못하면 응답성이 떨어지며, 이 응답성이 게임 클라이언트가 허용한 범주보다 늦어지게 되면 사용자는 렉을 느끼게 된다. 이를 해결하는 방향성 중 하나는 모든 연산을 최저치로 낮출 수 있는 데로 낮추는 접근이었다고 말할 수 있겠다.

게임에서는 반응속도와 함께, 데이터 무결성을 보장해주어야 한다. 게임 사용자는 조금의 지연도 용납해주지 않는다.

 

 

 

 

 - 반면에 웹은 실제 db에서 처리되고 있는 데이터보다 조금 예전 데이터를 주더라도 크게 문제 삼지 않는다.

 

그렇다보니 캐싱이 더 쉬워지고, 브라우저도 캐싱을 하며, 사용자도 이를 인정하고 새로운 데이터를 전달 받기 위해 새로고침을 직접 한다.

 

이는 훨씬 더 많은 사용자에게 컨텐츠를 제공하는 방향으로 발전할 수 있는 원동력이 되기도 했다. 캐싱과 스케일아웃이 유연할 수 있는 근거는, 지금 언급한 조금의 지연이 있는 데이터, 혹은 소수의 사용자가 편집한 데이터를 전달하는 것도 용인 될 수 있는 웹 환경이 그 근거다.

 

애초에 데이터의 변화량/응답속도가 너무나도 중요한 가치인 게임과, 생산성/확장성이 더 중요한 웹은 궤를 달리 할 수 밖에 없었던 운명이었던 걸지도 모른다.