X Window System이 서버를 사용하는 이유는 무엇입니까?


25

나는 왜 윈도우 시스템에 서버가 있어야하는지 이해하지 못했습니다. 데스크탑 환경, 디스플레이 관리자 및 창 관리자에 xorg-server가 필요한 이유는 무엇입니까? 그래픽 카드 위에 추상화 레이어 만있는 것입니까? 윈도우 시스템이 클라이언트-서버 모델을 사용하는 이유는 무엇입니까? 명명 된 파이프를 통한 프로세스 간 통신이 더 간단하지 않습니까?


2
파이프는 단방향 통신 전용이므로 명명 된 파이프는 더 단순하지 않습니다. 양방향 통신을 원하면 파이프 대신 소켓을 사용하십시오. 실제로 특정 최신 시스템에서는 TCP 소켓 대신 기본적으로 명명 된 (유닉스 도메인) 소켓을 사용합니다. 예를 들어 Ubuntu 14.04에서 X는 기본적으로 TCP 소켓에서 수신 대기하지 않도록 구성되어 있습니다.
kasperd

5
유닉스와 X는 PC가 그렇게 강력하고 저렴 해지기 전에 진화했다. 일반적으로 하나 또는 몇 개의 더 강력한 컴퓨터에 연결된 단순한 터미널이 많았던 환경이다. 이 부분은 X로 진행되었습니다. 그래픽 카드가있는 단순하고 저렴한 컴퓨터 인 "터미널"이 X 서버 만 실행하고 마우스 / 키보드에서 입력을 수집하고 화면을 그리는 중입니다 ... 실제 프로그램 (X- 반면에 클라이언트)는 터미널을 사용하는 모든 사용자가 공유하는 하나 이상의 강력한 컴퓨터에서 실행되었습니다. 따라서 X를 두 부분으로 나누면 (별도로 실행될 수 있음) 의미가 있습니다.
Baard Kopperud

@BaardKopperud X 터미널은 X Window가 대중화되기 시작한 지 몇 년이 지났으므로 X Window가 그런 식으로 아키텍처 된 이유가 될 수 없습니다. X는 X 서버보다 더 많이 실행되는 Unix 워크 스테이션으로 시작했습니다.
jlliagre

답변:


39

"서버"가 필요하다는 것을 이미 알고 계신 것 같습니다. 각 클라이언트 (데스크톱 환경, 창 관리자 또는 창 프로그램)는 다른 모든 장치와 디스플레이를 공유해야하며 하드웨어의 세부 사항을 알지 못하거나 다른 사용자가 디스플레이를 사용 중인지 알 필요없이 항목을 표시 할 수 있어야합니다. 따라서 X11 서버는 IPC 인터페이스를 제공하여 언급 한 추상화 및 공유 계층을 제공합니다.

X11은 명명 된 파이프를 통해 실행되도록 만들 수 있지만 명명 된 파이프로는 할 수없는 두 가지 큰 일이 있습니다.

  • 명명 된 파이프는 한 방향으로 만 통신합니다.
  • 두 프로세스가 명명 된 파이프의 "송신"끝에 데이터를 넣기 시작하면 데이터가 혼합됩니다.

실제로 대부분의 X 클라이언트는 UNIX 도메인 소켓이라는 "새롭고 개선 된"파이프를 사용하여 서버와 통신합니다. 프로세스가 양방향으로 대화하고 누가 무엇을 말했는지 추적한다는 점을 제외하면 명명 된 파이프와 매우 비슷합니다. 이것들은 네트워크와 같은 종류의 작업이므로 UNIX 도메인 소켓은 네트워크 통신을 제공하는 TCP / IP 소켓과 동일한 프로그래밍 인터페이스를 사용합니다.

그러나 거기에서 "클라이언트가 아닌 다른 호스트에서 서버를 실행하면 어떻게됩니까?"라고 말하기가 정말 쉽습니다. UNIX 소켓 대신 TCP 소켓과 voila : Windows RDP보다 수십 년 전의 원격 데스크톱 프로토콜 만 사용하십시오. 내가 할 수있는 ssh네 가지 원격 호스트 및 실행하려면 synaptic그들 각각에 (그래픽 패키지 관리자) 및 네 개의 창 내 로컬 컴퓨터의 디스플레이에 나타납니다.


2
X는 Solaris 및 SCO Unixes를 포함하여 명명 된 파이프가 양방향 인 SysV 시스템에서 명명 된 파이프를 사용했습니다.
alanc

14

윈도우 시스템에는 서버가 필요하지 않지만 클라이언트 서버 모델을 기반으로 윈도우 시스템을 구현하도록 결정할 수 있습니다. 이렇게하면 클라이언트와 서버의 활동을 명확하게 분리 할 수 ​​있으므로 몇 가지 장점이 있으며 동일한 시스템에서 실행할 필요가 없으며 여러 클라이언트를보다 쉽게 ​​서비스 할 수 있습니다. 그것은 여전히 ​​매우 편리하지만 (예를 ssh들어 다른 컴퓨터에 넣을 때 ) X가 개발 될 때 필요하다고 여겨지는 로컬 컴퓨터가 클라이언트를 실행하기에 충분히 강력하지 않을 수 있음을 알아야합니다.

명명 된 파이프는 TCP 구현처럼 네트워크를 통해 실행할 수 있다는 자동 이점을 제공하지 않습니다. 그러나 DosExtender가 Desqview / X (1992)를 실행하는 DOS에서는 명명 된 파이프를 사용할 수 없었으며 AFAIK도 VMS에는 없습니다. 이러한 구현에서 유닉스 고유의 통신은 문제가 될 것입니다.

TCP는 Unix 전용이 아니며 VAX / VMS에서 클라이언트를 실행하고 (1984 년 X 개발 시작) 로컬 UNIX 기반 그래픽 워크 스테이션에 출력을 제공 할 수 있습니다. "X Window 시스템 : Xlib, X 프로토콜, ICCCM, XLFD에 대한 완전한 참조"¹에서 :

1986 년 가을, Digital은 ULTRIX, VMS 및 MS-DOS에 대한 전체 데스크톱 워크 스테이션 전략을 X에 기반으로 결정했습니다. 이로 인해 약간의 지연이 발생했지만 결국에는 더 나은 디자인으로 이어졌습니다. Ralph Swick of Digital은이 기간 동안 Project Athena에 합류했으며 버전 11의 개발은 아니지만 중요한 역할을 수행했습니다. 마지막 버전 10 릴리스는 1986 년 12 월에 제공되었습니다.

"X 프로토콜 참조 매뉴얼"²에서 :

책임 분담

X 프로토콜을 설계하는 과정에서 서버와 클라이언트 간의 기능 분할에 대한 많은 생각이 있었으며, 이는 요청, 응답 및 이벤트를 통해 어떤 정보를 앞뒤로 전달해야하는지 결정합니다. 프로토콜 설계에서 선택한 특정 선택의 근거에 대한 훌륭한 정보 소스는 Robert W. Scheifler와 Jim Gettys의 The X Window System 기사, Association of Computing Machinery 저널, Transaction on Graphics, Vol 5, No. 1986 년 4 월 2 일 궁극적으로 도달 한 결정은 클라이언트 프로그램의 이식성, 클라이언트 프로그래밍의 용이성 및 성능에 따라 결정되었습니다.

첫째, 서버는 클라이언트 응용 프로그램에서 기본 하드웨어의 차이점을 숨기도록 가능한 한 많이 설계되었습니다. ...

나는 TOG의 기사가 흥미로운 기사임을 기억합니다. 그것은 X에 대한 관심을 불러 일으켰으며 (이것은 WorldWideWeb 이전이었습니다) O'Reilly가 X 시리즈 책을 출판하기 시작할 때까지 더 많은 정보를 얻는 데 어려움을 겪었습니다.

¹ X 버전 11, 릴리스 4, 2-X, PDF ( 여기에서 온라인으로 제공)
² 이 문서는 1990 년에 구입 한 O'Reilly가 발행 한 2 판 9 페이지에서 발췌 한 것입니다. 이것들과 AFAIK는 종이로만 제공됩니다. 나는 그들이 책임 분담의 근거를 바꾸지 않았다고 생각합니다.


2
또한 디스크가없고 수동적으로 냉각되며 즉시 교체 할 수있는 전용 X 터미널을 사용했으며, 100 석이 필요한 경우 모두 유용합니다.
Simon Richter

7

윈도우 시스템은 여러 개의 독립적 인 프로그램이 공통 자원, 화면 및 입력 장치를 공유 함을 의미합니다. 공유 리소스는 다음 두 가지 방법으로 만 안전하게 구현할 수 있습니다.

  • 리소스는 커널에 의해 제어 될 수 있으며 응용 프로그램은 커널 호출을 통해 액세스합니다.
  • 리소스는 전용 프로세스 (서버)에 의해 제어 될 수 있으며 응용 프로그램은 서버에 접속하여 액세스합니다.

물론 실제 디스플레이 하드웨어에 대한 액세스는 커널에 의해 제어되지만 윈도우 시스템에는 충분하지 않습니다. 프로세스가 디스플레이 의 특정 부분 (윈도우)을 합리적으로 할당 할 수있는 방법이 있어야합니다. 다른 프로세스가 방해하지 않도록하고, 어떤 애플리케이션이 어떤 시점에 리소스의 어느 부분에 액세스 할 수 있는지에 대한 특정 수준의 보호가 있어야합니다.

이제 모든 것이 커널에 들어갈 수 있었는데, 이는 Windows가하는 AFAIK입니다. 이것은 더 빠르다는 장점이 있지만 (보통 커널을 호출하는 것이 다른 프로세스에 접촉하는 것보다 훨씬 빠르지 만) 보안 허점을 열 수 있다는 단점이 있습니다 (시스템의 악용은 커널 수준에서의 악용 임). 시간은 이식성을 제한합니다 (커널에 구현 된 시스템은 커널에 강력하게 연결되어 있으므로 다른 운영 체제로 쉽게 이식 할 수 없으며 커널 코드에 액세스 할 수없는 경우 완전히 수행 할 수 없습니다).

커널에서 커널을 구현하지 않으려는 경우이를 구현하는 유일한 다른 방법은 전용 프로세스, 즉 서버입니다. 명명 된 파이프를 통해 연결된 서버는 여전히 서버입니다. 또한 같은 컴퓨터에서 실행될 때 요즘 X 서버와 클라이언트 간의 많은 통신은 공유 메모리를 통해 이루어집니다. 여전히 디스플레이 서버가 서버라는 사실을 변경하지는 않습니다.

이제 서버가 소켓을 사용하여 연결되고 명명 된 파이프를 사용하지 않는 이유는 무엇입니까? 소켓을 사용하여 전체 서버에 대해 하나의 소켓 만 있으면 모든 통신을 수행 할 수 있습니다. 파이프와 통신하는 경우 클라이언트 당 두 개의 파이프가 필요합니다. 이러한 모든 파이프를 관리하는 것이 상당히 번거 롭다는 사실 외에도, 충분한 수의 프로그램이 동시에 서버와 통신하려고 시도하는 경우 열린 파이프 수에 대한 일부 운영 체제 제한에 도달 할 수 있습니다.

물론 파이프보다 소켓의 또 다른 장점은 소켓을 사용하여 여러 기계를 연결할 수 있다는 것인데, 이는 전용 터미널에 앉아 많은 사람들이 실제 컴퓨터를 공유 할 때 특히 중요했기 때문에 컴퓨터의 프로그램이 통신해야했습니다. 다른 터미널에도 적용되지만 오늘날에도 네트워크 환경에서 매우 유용합니다.


MS Windows 가정은 부분적으로 사실 입니다. 윈도우 시스템에 필요한 일부 구조는 일종의 커널 속하지만 복잡합니다. Windows에 대해 놀랍게도 Windows와 관련이있는 대부분은 실제로 단일 사용자 모드 하위 시스템 ( Win32 하위 시스템)과 vm과 관련이 있습니다. 커널 자체와 구성 Executive 모듈은이 모든 것과 떨어져 있습니다. 별도의 POSIX 하위 시스템이 NT 커널 위에서 작동 할 수있게 해주는 것이 분리입니다. 그것을 확인하십시오
mikeserv

1
링크 된 기사에서 이미지를 보면 특정 디자인에 대해 알지 못했지만 커널 창에 "창 관리자"라는 용어가 들어 있는 상자 가 있습니다. 실제 창 장식은 개별 프로그램에 의해 그려 지므로 (X11 창 관리자와 같은 것은 없습니다) 기본적으로 X11 디스플레이 서버와 동일한 구성 요소라고 결론 내릴 수 있습니다. Win32 부분은 X11 서버의 일부 가 아닌 X11 창 관리자의 기능 과 X의 클라이언트 컨텍스트에서 X11 툴킷의 ​​조합 일 수 있습니다.
celtschk

예-그것은 제가 일종의 의미로 , 그것은 행정 서비스 계층입니다. 그것은 커널 모드에서 실행되지만 자체적으로 분리 된 모듈 인 서비스의 호지 포드와 같습니다. 나는 그것이 커널이라고 생각합니다-같은 방식으로 리눅스 커널 드라이버는 컴파일 될 필요는 없지만 모듈 식으로로드 / 언로드 될 수 있습니다. 모든 것이 마무리되어 있기 때문에 Windows에서는 더 이상합니다. 어쨌든, 나는 항상 그것이 재미 있다고 생각했지만 전문가는 아닙니다 . 당신의 대답은 방금 생각 나게했습니다.
mikeserv

2

X는 원래 MIT에서 개발하고 유지 관리했으며 오픈 소스 MIT 라이센스가 있었지만 실제로는 중요하지 않습니다.

언약적인 것으로 여겨지지만 잠시 생각해보십시오. 소프트웨어에서 클라이언트-서버 패러다임을 사용하는 선택을 어떻게 설명 할 것인가? 그리고 아마도 나는 CEO에게 말해야한다 ..

대학에서의 선택에 감사하는 방법을 소개합니다. 클라이언트 - 서버, 서버는 자원을 관리하고, 특히 , 어떤 자원이 있어야공유 . 따라서 X 서버는 클라이언트 앱, 키보드, 마우스 및 프레임 버퍼 (또는 시스템의 화면에 쓰는)에 제공하는 프로세스입니다 .

실제로 정확하지는 않지만 창 관리자는 종종 다음과 같이 설명됩니다. 간단하게, 그 일, 핸들 및 기타 장식을 앱의 프레임과 창, 대화 상자 등에 넣는 것입니다.


0

클라이언트 서버 모델은 하나의 서버와 하나의 클라이언트 만있는 경우에도 모든 종류의 응용 프로그램에 널리 사용되는 디자인입니다. 책임 영역간에 깨끗하고 명확한 인터페이스를 제공합니다.

서버와 클라이언트가 통신 할 수있는 많은 방법이 있지만, 선택은에 의해 X(에 관계없이 다른 사람에 의해 언급 한 장점이) 불필요한되지 않습니다 : 당신은 할 수 에 연결하는 X또 다른 협력을 바탕 화면에 다른 시스템과 열려있는 창에 서버 (또는에 데스크톱). 이것은 X가 개발 된 시절, 많은 대학과 기업이 Unix 서버와 많은 "X 터미널"을 가지고있을 때 매우 흔했습니다. 인터넷 지원 통신 프로토콜을 사용하면 X를 호스트 내에서 또는 호스트간에 원활하게 사용할 수 있습니다.

X는 단일 컴퓨터의 단일 사용자 용 OS가 아닌 다중 사용자 환경으로서의 UNIX 기록과 일치하여 다른 컴퓨터의 창을 투명하게 표시 할 수있는 최초의 GUI 환경이었습니다. 컴퓨터와 (물리적 또는 원격으로) 상호 작용할 수있는 유일한 사람이라면 많은 UNIX 기능이 과도하게 보입니다.


-1

처음에는 컴퓨팅 리소스가 부족하고 메인 프레임이 대부분의 작업을 수행했기 때문에 x 서버는 클라이언트 서버 아키텍처로 설계되었다고 생각합니다. X- 터미널은 x- 서버에 연결되어 사용자에게 표시해야하는 모든 것을 표시하는 씬 클라이언트입니다.

X의 통신 프로토콜은 현재 매우 무겁지만 많은 이점이 있습니다. 특히 여러 클라이언트에서 동일한 디스플레이를 표시 할 수 있으며 X에서 여러 사용자와 화면을 공유하는 것이 쉽습니다.


X 터미널은 X Window가 널리 사용되기 시작한 지 수 년이 지난 지금부터 X Window가 그런 식으로 아키텍처 된 이유가 될 수 없습니다. 또 다른 요점 : X 터미널은 X 서버에 연결되지 않았으며 X 서버를 실행하고있었습니다.
jlliagre
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.