Nginx는 러시아의 프로그래머 이고르 시쇼브(Игорь Сысоев)가 개발한 오픈 소스 웹 서버 프로그램이다.

아쉽고 죄송하네요.

이번주에는 번역을 끝내려고 했었는데....

일곱번 째 시간입니다.

아직 번역중이라 looah 사이트에는 업데이트를 못 했습니다.

http://www.looah.com/article/view/1640

• Indexing module details can be found in the nginx documentation, but these are the modules which handle requests with a trailing slash. If a specialized module like mp4 or autoindex isn't appropriate, the content is considered to be just a file or directory on disk (that is, static) and is served by the static content handler. For a directory it would automatically rewrite the URI so that the trailing slash is always there (and then issue an HTTP redirect).

• 인덱싱 모듈의 상세 내용은 nginx 문서에서 찾을 수 있으나, 이들은 슬래시와 함께 요청을 처리하는 모듈이다. mp4 또는 autoindex와 같이 특정 모듈이 적절하지 않은 경우, content는 단지 디스크 상의 파일이나 디렉토리로 간주되고 (즉, 정적) 정적 컨텐츠 핸들러에 의해 처리된다. 디렉토리에 대해서는 자동으로 URI가 rewrite 되어, 항상 슬래시가 붙도록 할 것이다. (다음 HTTP redirection 수행)

• The content handlers' content is then passed to the filters. Filters are also attached to locations, and there can be several filters configured for a location. Filters do the task of manipulating the output produced by a handler. The order of filter execution is determined at compile time. For the out-of-the-box filters it's predefined, and for a third-party filter it can be configured at the build stage. In the existing nginx implementation, filters can only do outbound changes and there is currently no mechanism to write and attach filters to do input content transformation. Input filtering will appear in future versions of nginx.

• 컨텐트 핸들러의 컨텐츠는 다음 필터에 전달된다. 필터들은 또한 locations에 부착되며, 그 곳에는 location을 위해 설정된 여러 필터가 있을 수있다. 필터는 처리기에 의해 생성되는 출력을 조작하는 작업을 한다. 필터의 실행 순서는 컴파일 시점에 결정된다. 미리 정의된 out-of-the-box 필터와 3rd-party 필터는 빌드 단계에서 설정할 수 있다. 기존의 nginx 구현에서, 필터는 단지 아웃 바운드 변경만 시킬 수 있고, 입력 내용의 변환을 수행하는 필터를 작성하고 첨부하는 메커니즘은 없다. Input 필터 기능은 nginx의 향후 버전에서나 선보일 것이다.

• Filters follow a particular design pattern. A filter gets called, starts working, and calls the next filter until the final filter in the chain is called. After that, nginx finalizes the response. Filters don't have to wait for the previous filter to finish. The next filter in a chain can start its own work as soon as the input from the previous one is available (functionally much like the Unix pipeline). In turn, the output response being generated can be passed to the client before the entire response from the upstream server is received.

• 필터들은 특별한 디자인 패턴을 따른다. 필터는 호출되고, 작업을 시작하고, 체인의 마지막 필터가 호출될 때까지 다음 필터를 호출한다. 그런 다음 nginx는 응답을 종료한다. 필터들은 이전 필터가 끝날때까지 기다리지 않아도 된다. 체인에있는 다음 필터는 바로 이전의 입력이 가능한 상태로 자신의 작업을 시작할 수 있다 (기능적으로 유닉스의 파이프라인과 아주 유사함). 그 다음, 생성된 출력 응답은 업스트림 서버로부터 전체 응답을 수신하기 전에 클라이언트로 전달될 수 있다.

• There are header filters and body filters; nginx feeds the header and the body of the response to the associated filters separately.

• 헤더 필터와 바디 필터가 있다. nginx는 연결된 필터에 대한 응답의 헤더와 바디를 별도로 공급한다.

• A header filter consists of three basic steps:

• 헤더 필터는 세 가지 기본 단계로 구성된다.

• - Decide whether to operate on this response.

• - 이 응답에 대한 작동 여부를 결정

• - Operate on the response.

• - 응답에 대한 작동

• - Call the next filter.

• - 다음 필터 호출

• Body filters transform the generated content. Examples of body filters include:

• 바디 필터는 생성된 컨텐츠를 변환. 바디 필터의 예.

• - server-side includes

• - 서버 측 포함

• - XSLT filtering

• - XSLT(Extensible Stylesheet Language Transformations) 필터링

• - image filtering (for instance, resizing images on the fly)

• - 이미지 필터링 (예, 이미지 즉석 크기 조정)

• - charset modification

• - 캐릭터셋 변경

• - gzip compression

• - gzip 압축

• - chunked encoding

• - chunked 인코딩

• After the filter chain, the response is passed to the writer. Along with the writer there are a couple of additional special purpose filters, namely the copy filter, and the postpone filter. The copy filter is responsible for filling memory buffers with the relevant response content which might be stored in a proxy temporary directory. The postpone filter is used for subrequests.

• 필터 체인 후, 응답은 writer로 전달된다. writer와 함께 복사필터라고 하는 추가적인 특수 목적의 필터 몇 가지와 연기필터가 있다. 복사 필터는 프록시 임시 디렉토리에 저장되어 있는 관련된 응답 컨텐츠들을 메모리 버퍼에 담는 역할을 한다. 연기필터는 하위 요청에 사용된다.

• Subrequests are a very important mechanism for request/response processing. Subrequests are also one of the most powerful aspects of nginx. With subrequests nginx can return the results from a different URL than the one the client originally requested. Some web frameworks call this an internal redirect. However, nginx goes further—not only can filters perform multiple subrequests and combine the outputs into a single response, but subrequests can also be nested and hierarchical. A subrequest can perform its own sub-subrequest, and a sub-subrequest can initiate sub-sub-subrequests. Subrequests can map to files on the hard disk, other handlers, or upstream servers. Subrequests are most useful for inserting additional content based on data from the original response. For example, the SSI (server-side include) module uses a filter to parse the contents of the returned document, and then replaces include directives with the contents of specified URLs. Or, it can be an example of making a filter that treats the entire contents of a document as a URL to be retrieved, and then appends the new document to the URL itself.

• 하위 요청은 요청/응답 처리를 위한 매우 중요한 메커니즘이다. 하위 요청도의 nginx의 가장 강력한 측면 중 하나이다. 하위 요청으로 nginx는 클라이언트의 원래 요청이 아닌 다른 URL로부터의 결과를 반환할 수 있다. 어떤 웹 프레임웍에서는 이것을 내부 redirect라고 부른다. 하지만, nginx는 필터가 여러 개의 하위 요청을 수행하고 하나의 응답으로 출력을 결합할 수 있을 뿐 아니라, 하위 요청이 중첩되고 계층적이게도 할 수 있다. 하위 요청은 자신의 하위-하위 요청을 수행 할 수 있으며, 하위-하위 요청은 하위-하위-하위 요청을 시작할 수 있다. 하위 요청은 하드 디스크의 파일, 다른 처리기 또는 업스트림 서버에 매핑 할 수 있다. 하위 요청은 원래의 응답 데이터를 기반으로 추가 콘텐츠를 삽입하기에 가장 유용하다. 예를 들면, SSI(server-side include) 모듈은 반환된 문서의 내용을 파싱하는데 필터를 사용하고, include 지시어를 지정된 URL의 내용으로 대체한다. 또는 검색할 URL로 문서의 전체 내용을 취급하고, URL 자체에 새 문서를 추가하는 것이 필터를 만드는 예제가 될 수 있다.

• Upstream and load balancers are also worth describing briefly. Upstreams are used to implement what can be identified as a content handler which is a reverse proxy (proxy_pass handler). Upstream modules mostly prepare the request to be sent to an upstream server (or "backend") and receive the response from the upstream server. There are no calls to output filters here. What an upstream module does exactly is set callbacks to be invoked when the upstream server is ready to be written to and read from. Callbacks implementing the following functionality exist:

• upstream 및 부하 분산 장치도 간단하게 설명하는 가치가 있다. upstream은 리버스 프록시(proxy_pass 핸들러)의 컨텐츠 핸들러로 식별 할 수 있는 것을 구현하는 데 사용된다. upstream 모듈은 대부분 upstream 서버 (또는 "backend")로 보내어지는 요청을 준비하고, upstream 서버로 부터 응답을 받는다. 여기에는 output 필터 호출이 없다. upstream 모듈이 정확하게 하는 것은 upstream 서버가 읽거나 쓸 준비가 되었을 때 호출되게 하는 일련의 callback 이다. Callback은 다음과 같은 기능을 구현한다.

• - Crafting a request buffer (or a chain of them) to be sent to the upstream server

• - upstream 서버로 전송되는 요청 버퍼(또는 버퍼 체인) 기술

• - Re-initializing/resetting the connection to the upstream server (which happens right before creating the request again)

• - upstream 서버에 대한 연결의 재초기화/재설정 (요청을 다시 작성하기 직전에 발생하는)

• - Processing the first bits of an upstream response and saving pointers to the payload received from the upstream server

• - upstream 응답의 첫번째 비트 처리 및 upstream 서버로부터 수신된 내용에 대한 포인터 저장

• - Aborting requests (which happens when the client terminates prematurely)

• - 요청 취소 (클라이언트의 종료로 발생하는)

• - Finalizing the request when nginx finishes reading from the upstream server

• - nginx가 upstream 서버로부터 읽기가 끝나면 요청을 마무리

• - Trimming the response body (e.g. removing a trailer)

• - 응답 바디 정리 (예, 트레일러 제거)

• Load balancer modules attach to the proxy_pass handler to provide the ability to choose an upstream server when more than one upstream server is eligible. A load balancer registers an enabling configuration file directive, provides additional upstream initialization functions (to resolve upstream names in DNS, etc.), initializes the connection structures, decides where to route the requests, and updates stats information. Currently nginx supports two standard disciplines for load balancing to upstream servers: round-robin and ip-hash.

• 로드 밸런서 모듈은 한 개 이상의 upstream 서버를 사용할 수 있을 때 upstream 서버를 선택할 수 있게 하는 가용성을 제공하는 proxy_pass 처리기에 붙일 수 있다. 로드 밸런서는 구성 파일 지시어 활성화를 등록하고, 추가적인 upstream 초기화 기능을 제공하고 (DNS 등에 등록되어 있는 upstream 이름을 해석하기 위한), 연결 구조를 초기화하고, 요청을 분기시킬 위치를 결정하고, 통계정보를 업데이트 한다. 현재 nginx에서는 upstream 서버에 대한 로드 밸런싱에 round-robin과 ip-hash 2가지 표준 규칙을 제공한다.

• Upstream and load balancing handling mechanisms include algorithms to detect failed upstream servers and to re-route new requests to the remaining ones—though a lot of additional work is planned to enhance this functionality. In general, more work on load balancers is planned, and in the next versions of nginx the mechanisms for distributing the load across different upstream servers as well as health checks will be greatly improved.

• upstream과 로드 밸런싱 처리 매커니즘은 upstream 서버 실패 감지와 살아 있는 서버에 대한 새로운 요청의 재전달 알고리즘이 포함되어 있고, 이러한 기능의 고도화에 대하여 많은 추가적인 작업이 계획되어 있다. 일반적으로, 부하 분산에 더 많은 작업이 계획되어 있고, 다음 버전에서는 health-check 뿐만 아니라, 서로 다른 upstream 서버 간의 부하에 대한 분산을 위한 매커니즘이 크게 향상될 것이다.

• There are also a couple of other interesting modules which provide an additional set of variables for use in the configuration file. While the variables in nginx are created and updated across different modules, there are two modules that are entirely dedicated to variables: geo and map. The geo module is used to facilitate tracking of clients based on their IP addresses. This module can create arbitrary variables that depend on the client's IP address. The other module, map, allows for the creation of variables from other variables, essentially providing the ability to do flexible mappings of hostnames and other run-time variables. This kind of module may be called the variable handler.

• 구성 파일에 사용하기 위한 변수의 추가 세트를 제공하는 다른 흥미로운 모듈의 몇 가지가 있다. nginx의 변수가 다른 모듈 간의 생성 및 업데이트를 하는 동안, 두 개의 모듈은 완전히 변수에 할당된다. geo와 map. geo 모듈은 클라이언트의 IP 주소에 기초하여 클라이언트의 추적을 용이하게 하기 위해 사용된다. 이 모듈은 클라이언트의 IP 주소에 따라 임의의 변수를 만들 수 있다. 다른 모듈인 map은 호스트 및 다른 런타임 변수의 유연한 매핑을 수행하는 가용성을 필수적으로 제공하는 다른 변수로부터 변수들의 생성을 허용한다. 이런 종류의 모듈은 변수 처리기라고 불리운다.