nginx 리버스 프록시와 백엔드 웹 서버간에 HTTP / 2.0 사용

HTTP / 2.0을 수행 할 수있는 백엔드 웹 서버 앞에서 nginx를 리버스 SSL 프록시로 사용합니다.

nginx가 HTTP / 2.0이 아닌 HTTP / 1.1을 통해 백엔드 서버에 대한 요청을 프록시하는 것으로 나타났습니다. 암호화되지 않은 HTTP / 2.0 연결을 대신 사용하도록 nginx에 지시 할 수 있습니까? 성능이 향상됩니까?

nginx reverse-proxy http2

— S1lentSt0rm
소스

http2 사양에 따르면 암호화가 필요하지 않지만 nginx는 현재 SSL없이 http2를 지원하지 않습니다.

— Marco

https : // 주소를 지정한 경우 HTTP / 2.0을 사용합니까? 그렇다면 HTTP / 1.1을 사용하는 것이 낫습니다. 트래픽을 두 번 암호화하는 것은 의미가 없으며 SSL을 사용하는 HTTP / 2.0의 성능은 SSL을 사용하지 않는 HTTP / 1.1만큼 좋지 않을 것입니다. 내 말은, 그런 종류의 리버스 SSL 프록시를 쓸모 없게 만든다;)

— S1lentSt0rm

프런트 엔드 서버와 백엔드 서버 간의 트래픽이 동일한 시스템에있는 경우 실제로 암호화하는 것은 중요하지 않습니다. 성능에 관해서는 : 암호화를 사용하더라도 http2는 http1.1보다 약간 빠릅니다. 차이를 만들려고 시도하지 않고 말할 수 없습니다.

— Marco

nginx.com/blog/nginx-1-13-9-http2-server-push

— malix

답변:

이것을 발견하십시오 : https://trac.nginx.org/nginx/ticket/923

가까운 시일 내에 프록시 모듈에서 HTTP / 2 지원을 구현할 계획이 없습니다.

티켓에서 참조 된 우편에서 발췌 :

HTTP / 2의 주요 이점은 단일 연결 내에서 많은 요청을 멀티플렉싱 할 수있어 거의 동시 요청 수에 대한 제한을 제거 할 수 있다는 점에서 구현하는 것은 의미가 없습니다. 자신의 백엔드. 또한 HTTP / 2를 백엔드에 사용하면 여러 개의 연결 대신 단일 TCP 연결이 사용되므로 상황이 더 나빠질 수 있습니다.

— S1lentSt0rm
소스

백엔드 서버가 직접 액세스 한 경우이를 지원하더라도 nginx로 프록시하는 경우 HTTP / 2 서버 푸시를 사용할 수 없습니다.

— thomasrutter

느린 연결을 통해 로컬이 아닌 사이트에 nginx 리버스 프록시를 사용하므로 HTTP / 2가 도움이 될 것입니다. nginx 개발자가 유스 케이스를 고려하지 않은 것은 부끄러운 일입니다 :-(.

— markshep

슬프게도 nginx는 https://www.nginx.com/blog/http2-module-nginx/#QandA 에서 참조되는 http / 2 백엔드 서버에 대한 프록시를 지원하지 않습니다.

Q : 업스트림 측에서도 HTTP / 2를 지원합니까, 아니면 클라이언트 측에서도 HTTP / 2 만 지원합니까?

A : 현재 클라이언트 측에서는 HTTP / 2 만 지원합니다. proxy_pass를 사용하여 HTTP / 2를 구성 할 수 없습니다. [편집자 –이 게시물의 원본 버전에서이 문장은 "proxy_pass를 사용하여 HTTP / 2를 구성 할 수 있습니다."로 잘못 표기되었습니다. 이로 인해 혼란을 드려 죄송합니다.]

그러나 백엔드 측에서 HTTP / 2의 요점은 무엇입니까? 벤치 마크에서 볼 수 있듯이 업스트림 연결과 같은 지연 시간이 짧은 네트워크의 경우 HTTP / 2에는 큰 이점이 없습니다.

또한 NGINX에는 keepalive 모듈이 있으며 keepalive 캐시를 구성 할 수 있습니다. HTTP / 2의 주요 성능 이점은 추가 핸드 셰이크를 제거하는 것입니다. 그러나 keepalive 캐시로 이미 수행하는 경우 업스트림 측에 HTTP / 2가 필요하지 않습니다.

— 탕 신파
소스