서버 측 프로그래밍 언어에 액세스하는 방법에 대한 설명

45

모든 범용 프로그래밍 언어를 웹 사이트의 서버 측 개발에 사용할 수 있다는 것을 이해합니다.

서버와 프로그래밍 언어를 함께 사용하려면 서버에 CGI와 같은 인터페이스가 필요하다고 생각하는 것이 맞습니까? 그렇다면 왜 일부 프로그래밍 언어 (예 : PHP)가 다른 언어보다 더 인기가 있습니까?

programming-languages web-development web

— 크리스 댄스
소스

2

다른 프로그래밍 작업과 같은 이유입니다. 사람들은 기존 언어에 대해 뭔가 싫어하기 때문에 새로운 프로그래밍 언어를 발명합니다. 그리고 다른 사람들은 똑같은 것을 싫어하지 않거나 적어도 전환하기에 충분하지 않기 때문에 오래된 것을 계속 사용합니다.

— Kilian Foth

php와 같은 일부 언어는 웹 개발을 염두에두고 설계되었으므로 일반적인 응용 프로그램을위한 더 쉬운 (따라서 더 널리 사용되는) 옵션입니다.

— Chris Dance

29

PHP는 내가 "얕은"언어라고 부르는 것입니다. 기본 구조는 이해하기 쉽고 유용한 기능을 수행하는 수백 개의 작은 함수가 있습니다. 따라서 새로 온 사람들에게 호소합니다. 상속, 객체 지향, 유형 안전성 및 상대적으로 복잡한 라이브러리를 생산 해야하는 C #과 같은 언어와 비교하십시오.

— Robert Harvey

4

그러한 인터페이스가없는 경우에도 서버 를 언어로 작성할 수 있습니다.

— user253751

75

웹 초기에 CGI는 실제로 동적 컨텐츠를 보유 할 수있는 유일한 (실제적인) 방법이었습니다 (이름이 지정된 파일 파이프를 사용할 수 있으며 cgi 전날에 사용되었지만 전혀 실용적이지 않았습니다).

CGI는 분기 된 프로세스 환경에서 많은 정보를 집어 넣은 다음 실행 (및 아마도 stdin의 일부)하여 stdout에서 나온 정보를 가져와 요청자에게 다시 뱉어냅니다.

이것은 구현 언어가 무엇인지 조금 신경 쓰지 않습니다. 실제로 저는 초기 CGI를 C 또는 C ++로 작성했습니다. 고통 스러웠습니다. 나는 나중에 90 년대 초에 약간의 펄을 배웠고 그것은 훨씬 덜 고통 스러웠다.

이것은 한 지점까지 작동합니다. 문제는 규모입니다. 각 CGI 요청은 프로세스의 포크와 실행입니다. 수천 개의 요청은 수천 개의 프로세스를 의미합니다. 그것은 실제로 잘 작동하지 않습니다.

이에 대한 해결책은 웹 서버 자체의 스레드로 포크를 이동하거나 포크 및 실행없이 요청을 처리하는 다른 프로세스로 요청을 전달하여 포크 및 실행을 제거하는 것입니다. mod_perl은이를 수행하는 도구 중 하나입니다 (플러그를 아파치로 옮기는 플러그인). Php (90 년대 후반)는 웹 서버 자체에서 플러그인으로 언어를 구현하여 포크와 초과하는 것이 아니라이를 수행했습니다. 이것은 초기의 지배적 인 웹 프로그래밍 언어 인 perl과 유사하고 perl cgis보다 성능이 우수하여 상당히 인기를 얻었습니다. 90 년대 중반에는 이보다 더 많은 모멘텀이 남아 있습니다. 더 많은 엔터프라이즈 급 애플리케이션 서버가보다 공식화 된 언어를 사용하기 시작했습니다. 주위를 파면

이를 통해 내부 스레드가 생성되는 애플리케이션 서버 (또는 모든 접근 방식이 아닌 다른 접근 방식)가 완전히 새로운 프로세스가 아닌 요청을 처리 할 수있게되어 확장에 도움이됩니다. 외부 프로세스로서 이는 FastCGI에서 볼 수 있으며 나중에 다른 응용 프로그램 서버에서 널리 사용되었습니다. 이로 인해 응용 프로그램 서버와 웹 서버 간의 경계가 약간 흐려졌습니다. 많은 응용 프로그램 서버는 웹 서버로 두 배가 될 수 있지만 기존 웹 서버와 같은 방식으로 정적 파일 IO를 처리하는 데 최적화되지 않았습니다.

일반 응용 프로그램 서버는 대신의 솔루션에 도로를 포장하고있다 일반적인 애플리케이션 서버, 응용 프로그램 그 자체에 내장 된 웹 서버를 실행하거나 전체 배포되고 있습니다. 이러한 상황에서는 응용 프로그램 서버에 웹 응용 프로그램을 배포하지 않습니다. 웹 응용 프로그램은 자체적으로 실행되고 요청을 처리하기 만합니다. 이 모델의 목표는 애플리케이션의 새 인스턴스를 시작하는 데 따른 높은 가격을 피하고 대신 훨씬 가벼운 스레드 또는 유사한 접근 방식으로 애플리케이션 내부의 요청을 처리하는 것입니다.

여기에 문제가 있습니다. 모든 솔루션은 어떤 방식, 모양 또는 형태로 부족합니다. CGI는 쉽지만 규모에 심각한 문제가 있습니다. 웹 서버의 플러그인은 웹 서버 자체에 바인딩되고 (apache vs nginx vs IIS vs ...) 언어의 공통 기능을 잃습니다. Microsoft는 홍보하고자하는 자체 기술 퍼레이드를 보유하고 있습니다. 그리고 하나의 언어를 아는 경우 스택의 다른 부분 (클라이언트 및 Node.js의 자바 스크립트)에 다른 언어가 아닌 프로그래밍을 계속하지 않습니까?

그리고 오늘, 당신은 가지고 있습니다. 어떤 사람들은 자바 스택에서 작업합니다 (스칼라와 클로저는 드문 일이 아닙니다). C # 스택의 다른 것. JavaScript 스택의 다른 것. 거기에는 꽤 많은 PHP 스택이 있습니다. 많은 파이썬. 여전히 일부 perl 스택을 찾을 수 있습니다 (그리고 일부 저용량 사이트를 보면 여전히 CGI를 찾을 수 있습니다). Google은 클라우드 컴퓨팅을 통해 Go를 실행 가능한 서버 측 웹 언어로 홍보했습니다.

각각의 장점, 단점, 프레임 워크 및 서버가 있습니다. 이들 썰물의 상대적 인기는 그들 주변의 기술이 변화함에 따라 흐릅니다. 그들은 다른 일을 잘합니다.

이것이 바로 내가 찾던 것입니다. 포괄적이고 이해되지 않은 답변. 감사합니다!

— Chris Dance

1

"해결책은 포크와 실행주기를 웹 서버 자체로 옮기는 것입니다." 반드시 그런 것은 아닙니다 : FastCGI, 리버스 프록시는 대상 언어 나 웹 서버 구현을 신경 쓰지 않고 응용 프로그램 서버에 연결하는 잘 알려진 솔루션으로, 잘 지정된 프로세스 간 통신 프로토콜을 사용하여 작업을 수행합니다.

— jhominal

1

@jhominal "FastCGI는 각 요청에 대해 새로운 프로세스를 생성하는 대신 영구 프로세스를 사용하여 일련의 요청을 처리합니다. 이러한 프로세스는 웹 서버가 아닌 FastCGI 서버가 소유합니다." ( source )-이것이 핵심입니다. 이것이 어플리케이션 서버가하는 일입니다. 포크와 실행을하지 않고 요청을 처리하는 지속적인 프로세스입니다.

@MichaelT : 용어가 서로 교환 가능한 것처럼 "웹 서버"와 "응용 프로그램 서버"를 사용하고 있으며, "웹 서버"를 사용하여 아파치, nginx, 즉 일반적인 웹 서버 소프트웨어를 주로 사용합니다. (핵심적으로) 제한된 프로그래밍 기능 만 가지고 있습니다.

— jhominal

1

나는 이것이 각각의 응용 프로그램을 하나의 HTTP 프록시가 직면 할 수있는 자체 웹 서버로 만드는 (지금까지 매우 일반적인) 관행을 언급하기에 충분하지 않다고 생각합니다.

— hobbs

19

예, 모든 일반 프로그래밍 언어는 웹 사이트의 서버 측 부분을 작성하는 데 사용될 수 있습니다.

그러나 프로그래밍 언어의 특성은 다른 주제와 마찬가지로 일반적으로 인기에 기여하는 많은 요소 중 하나 일뿐입니다.

예를 들어, 다음과 같은 이유로 PHP가 웹 사이트에 널리 보급되었다고 생각합니다.

정적 웹 사이트에서 PHP 동적 웹 사이트로 업그레이드하는 것은 매우 쉽습니다. HTML 파일의 파일 확장자를 바꾸고 <?php태그를 시작 부분에 놓으면 PHP가 설치되면 동적 웹 사이트가 있습니다! 나머지 워크 플로는 정적 웹 사이트와 동일합니다.
배포가 쉬워 동적 웹 사이트를 제안하려는 웹 호스트는 PHP를 선택하여 가장 널리 배포 된 서버 측 플랫폼으로 만들었습니다.
적시에 시장에 나왔습니다.

그리고 일단 PHP가 널리 배포되면, 광범위한 배포의 이점을 누리기 위해 더 심각한 웹 응용 프로그램을 PHP로 작성하는 것이 흥미로워졌습니다.

보다 일반적인 방식으로 말하면, 언어 채택은 종종 이러한 질문에 대한 답변에 관한 것입니다.

내가하고 싶은 일을하는 것이 얼마나 쉬운가요?
내가하고 싶은 언어가 얼마나 광범위하게 지원됩니까?

— 경의
소스

7

서버와 프로그래밍 언어를 함께 사용하려면 서버에 CGI와 같은 인터페이스가 필요하다고 생각하는 것이 맞습니까?

거의. HTTP 요청에도 응답 할 수있는 소프트웨어가있는 웹 서버가 필요합니다.

정적 페이지가 어떻게 제공되는지 생각해보십시오. 서버는 HTTP 요청을 검색하고 HTTP 서버의 구성에 따라 파일 시스템에서 요청 된 문서를 찾은 후 정적 페이지를 리턴합니다.

CGI는 파일 시스템에서 실행 파일 또는 스크립트를 저장할 수있는 cgi-bin 폴더를 지정할 수 있도록하여이 개념을 확장합니다. CGI를 통해 프로그램에 액세스하면 HTTP 서버는 프로세스 또는 스크립트를 실행하고 단순히 정적 문서를 제공하는 대신 표준 출력을 클라이언트로 다시 전달합니다.

 If so then why are some programming languages (such as php) more popular than others?

이전 CGI 구조는 많은 양의 요청에 비해 잘 확장되지 않습니다. 웹을위한 서로 다른 프로그래밍 언어와 프레임 워크는 다른 이유로 존재하며 각각 다른 일을합니다. PHP는 CGI에 의존하지 않고 동적 페이지를 제공하는 최초의 쉽고 저렴한 솔루션 중 하나였으며 광범위한 호스팅 지원을 제공했기 때문에 역사적 이유로 인기가 있습니다. ASP는 VB 개발자가 자신의 기술을 웹으로 전환 할 수있게했기 때문에 Microsoft에서 널리 사용되었습니다. ASP.NET (Web Forms)을 사용하면 VB 코더 인 Windows Forms 개발자가 웹으로 쉽게 전환 할 수있었습니다.

— ravibhagw
소스

3

브라우저가 HTTP 요청을하면 다음과 같습니다.

GET /search?q=cats HTTP/1.0
Host: www.google.com
Connection: close

… 서버는 다음과 같은 응답을 보내야합니다.

HTTP/1.0 200 Success
Content-Type: text/html; charset=UTF-8
Content-Length: 1337

<!DOCTYPE html>
<html>
  <head><title>cats - Google Search</title>
  <body>
    <h1>About 415,000,000 results</h1>
    …
  </body>
</html>

TCP 소켓에서 요청을 수신하고 요청을 읽고 적절한 응답으로 응답하는 서버에서 실행되는 모든 코드로 충분합니다. 멍청한 방법 중 하나는 쉘 스크립트를 사용하여 TCP 포트 80에 연결하는 모든 사람에게 미리 준비된 응답을 내보내는 것입니다.

$ nc -l 8000 <<'RESPONSE'
HTTP/1.0 200 Success
Content-Type: text/html; charset=UTF-8
Content-Length: 1337

<!DOCTYPE html>
<html>
  <head><title>cats - Google Search</title>
  <body>
    <h1>About 415,000,000 results</h1>
    …
  </body>
</html>
RESPONSE

물론이 기술은 HTTP 프로토콜 을 거의 따르지 않는 것 같습니다 .

미리 준비된 답변에서 한 단계 업그레이드 된이 간단한 Python 프로그램 http.server은 Python 3 의 라이브러리 를 사용합니다 .

#!/usr/bin/python3

import http.server

class Handler(http.server.BaseHTTPRequestHandler):
    def do_GET(self):
        payload = '<!DOCTYPE html>... insert cats here ...'.encode('UTF-8')
        self.send_response(200)
        self.send_header('Content-Type', 'text/html; charset=UTF-8')
        self.send_header('Content-Length', len(payload))
        self.end_headers()
        self.wfile.write(payload)

http.server.HTTPServer(('', 80), Handler).serve_forever()

HTTP 서버는 모든 언어로 작성 될 수 있습니다. 그것은 단지 예일뿐입니다. 분명히이 예는 매우 기초적인 것입니다. 페이로드는 하드 코딩되어 있습니다. 프로그램은 요청 내용 (URL, 쿼리 문자열, Accept-Language 헤더 등)을 완전히 무시합니다. 요청에 따라 의미있는 응답을 생성하는 코드를 추가 할 수 있지만 코드는 매우 커집니다. 복잡한. 게다가 프로그래머는 웹 애플리케이션 작성에 중점을 두어 HTTP 요청을 처리하는 방법에 대한 세부 정보를 걱정할 필요가 없습니다.

보다 적절한 솔루션은 Apache HTTPD , IIS 또는 nginx 와 같은 웹 서버를 사용하는 것 입니다. 웹 서버는 관련 TCP 소켓에서 수신 대기하고 여러 요청을 수락하고 (아마도 동시에) 요청 URL, 헤더 및 기타 규칙에 따라 응답을 생성하는 방법을 결정하는 프로그램입니다. 이상적으로 SSL, 액세스 제어 및 리소스 제한과 같은 많은 세부 정보가 코드가 아닌 구성을 통해 처리됩니다. 대부분의 경우 웹 서버는 파일 시스템의 파일 내용만으로 구성된 응답을 공식화합니다.

그러나 동적 컨텐츠의 경우 웹 서버는 일부 코드를 실행하여 응답을 생성하도록 구성 할 수 있습니다. 이를 수행하는 한 가지 메커니즘은 CGI를 사용하는 것입니다. 서버는 요청에 따라 일부 환경 변수를 설정하고 프로그램을 실행하며 출력을 TCP 소켓에 복사합니다. 약간 더 정교한 해결책은 다른 프로그래밍 언어로 코드를 호출하기 위해 웹 서버에 지원을 추가하는 모듈을 갖는 것입니다 (예 : mod_php for Apache ). 또 다른 옵션은 웹 응용 프로그램과 동일한 언어로 웹 서버를 작성하는 것입니다.이 경우 요청 디스패치는 단지 함수 호출입니다. node.js 및 Apache Tomcat 과 같은 Java 서블릿 엔진 의 경우입니다 .

기술 선택은 실제로 귀하에게 달려 있으며 사용하려는 프로그래밍 언어, 사용 가능한 호스팅 환경, 성능 요구 사항, 대중 의견 및 유행에 따라 달라집니다. 예를 들어, 외부 프로그램을 시작해야하므로 확장 성이 제한되므로 CGI는 최근에 선호되지 않았습니다.

— 200_ 성공
소스

1

웹 서버는 표준 / 응용 프로그램 수준 프로토콜 (HTTP 등)을 준수하는 소켓을 통해 "웹 트래픽"을 처리하는 모든 프로그래밍 언어로 작성된 프로그램입니다. 대부분의 프로그래밍 언어는 소켓을 생성하도록 제공합니다.

서버와 프로그래밍 언어를 함께 사용하려면 서버에 CGI와 같은 인터페이스가 필요하다고 생각하는 것이 맞습니까?

전용 서버 프로그램과 응용 프로그램이 필요하지 않습니다-성능 관련 문제를 무시하고 동일 할 수 있습니다.

— 무 카호
소스

0

C로 코딩 된 프로그램 (또는 C ++, Wt 참조)에서도 일부 HTTP 서버 라이브러리 (예 : libonion)를 사용할 수 있습니다 . HTTP 클라이언트 라이브러리도 있습니다 (예 : libcurl )

다른 HTTP 라이브러리 (예 : ocsigen & ocamlnet for OCaml)를 사용할 수 있습니다 .

Opa , HOP , Kaya 등과 같은 몇 가지 웹 전용 언어가 있습니다 (예 : Opa , HOP , Kaya 등) (HOP & Opa는 서버 측과 브라우저 측 계산을 쉽게 혼합 할 수 있지만 고통스럽고 수동으로 수행해야합니다 AJAX 기술을 명시 적으로 사용 하고 브라우저를 위해 일부 Javascript를 수동으로 코딩하는 PHP . 반면, HOP, Opa, Ocsigen은 해당 Javascript를 생성 할 수 있습니다).

FASTCGI 기술을 사용 하여 일부 웹 서버에 동적 서비스를 추가 할 수 있습니다 . FASTCGI는 들어오는 모든 HTTP 요청에 대해 새 프로세스를 시작하는 일반 CGI 보다 낫습니다 . FASTCGI 응용 프로그램은 동일한 프로세스에서 많은 HTTP 요청을 처리 할 수 있습니다. BTW, PHP는 FASTCGI 응용 프로그램으로 작동하도록 구성 할 수 있습니다.

C.Queinnec은 웹 브라우징과 연속 이 크게 관련되어 있음을 관찰했습니다 .

추신. 나는 PHP가 마음에 들지 않으며, 그 인기는 역사적이면서 사회적 이유 (주로 기술적 이유가 아님)를 가지고 있다고 생각합니다. 실제로 PHP는 AJAX가 널리 사용되기 전에 널리 보급되었으며 HOP 또는 Opa (또는 Ocsigen)보다 오래되었습니다.

— 바 실레 스타 인케 비치
소스