X는 클라이언트-서버 아키텍처로 설계되었다. 어플리케이션 그 자신이 클라이언트이고 서버와 서로 통신하며 정보요구(request)를 발생시키고 서버로부터 정보를 얻는다.
X서버는 클라이언트의 화면표시와 서비스 정보요구(request)에 대한 배타적인 제어권을 갖는다. 여기에서 이러한 모델에서의 장점이 분명함을 알 수 있다. 어플리케이션(클라이언트)는 단지 어떻게 서버와 통신할 것인가를 알기만 하면 되고 화면표시장치에 어떻게 정보를 전달할 것인가는 알 필요가 없는 것이다. 아주 기초적인 레벨에서 클라이언트는 '여기서 저기까지 선을 그려라' 또는 ' 이 글꼴을 사용하여 이 지점에 문자열을 출력하라'등의 명령만을 서버에게 전달하면 되는 것이다.
이것은 어플리케이션을 작성할 때 그래픽 라이브러리를 사용한다 하여도 아무런 차이도 없음을 말한다. 게다가 X모델은 한 단계 더 진보적이다. 이것은 클라이언트가 서버와 동일한 컴퓨터에서 작동되는 것을 강요하지 않는다. 서버와 클라이언트간에는 프로토콜로, 프로세스간 상호 통신 메커니즘은 믿을만한 octet stream을 제공하므로서, 서로 통신하기 때문이다. 짐작하겠지만 이것은 TCP/IP 프로토콜을 사용하므로 구현될 수 있다. 우리가 알고 있는 한 X모델은 강력하다. 이것의 전형적인 좋은 예는 Cray computer에서 프로세서 의존적인 어플리케이션을 구동한다던가 솔라리스 서버에서의 데이터베이스를 small BSD 메일 서버에서의 이메일 어플리케이션을 SGI 서버에서 비주얼 프로그램을 그리고 내 GNU/Linux 워크스테이션 화면에 이 모든 것을 표시할 수 있다는 것이다.
지금까지 우리는 X 서버가 그래픽 표시를 담당하는 장치라는 것을 알았다. 또한 실제적으로 사용자가 작업하는 물리적인 컴퓨터를 구동하는 것도 X 서버이기 때문에 사용자와의 상호작용 또한 X의 몫이다. 마우스나 키보드의 입력을 받는 것도 X이고 이 정보를 클라이언트에게 전달해야 한다. 당연히 클라이언트는 이 정보에 대하여 반응할 것이다.
X는 Xlib이라는 저 수준의 클라이언트-서버 통신을 제어하는 라이브러리를 제공한다. 다시 말해서 클라이언트는 어떠한 일을 하기 위해서는 Xlib에 포함된 함수를 호출해야 한다는 것을 의미한다.
이 시점에서 우리는 시각적인 출력과 데이터 입력, 클라이언트 프로그램, 그리고 이것들이 서로 통신하는 방법을 서버가 담당한다는 것을 알게 되었다. 서버와 클라이언트가 서로 작용하는 것을 상상해 본다면 클라이언트는 서버로부터 화면에 사각 영역이 할당되는 것을 요구할 것이라고 생각할 수 있다. 사실 클라이언트 입장에서 보면 자신이 어디에 표시되고 있는가는 관심 밖의 일이다. 단시 서버로부터 X와 Y만큼의 크기만 요구하면 되고 '여기에서 저기까지 선을 그려라'라든가 '사용자가 마우스를 자신의 영역으로 이동하였는지 알려달라'등 함수만 호출하면 되는 것이다.