nginx spdy 프로토콜

SPDY는 Google에서 개발한 TCP(전송 제어 프로토콜)를 기반으로 하는 애플리케이션 계층 프로토콜입니다. 개발팀에서는 SPDY를 공식 표준(현재 인터넷 초안)으로 추진하고 있습니다. SPDY 이 프로토콜은 압축, 다중화 및 우선 순위 지정을 통해 웹 페이지 로드 시간을 개선하고 보안을 강화하도록 설계되었습니다. (SPDY는 Speedy의 애칭으로 더 빠르다는 뜻입니다.)

SPDY와 HTTP의 관계

SPDY 프로토콜은 Speedy보다 더 효율적입니다. 성능 측면에서 HTTP 연결 수를 최대한 줄이는 것이 핵심 아이디어로 많이 최적화되었지만 HTTP의 의미는 크게 수정되지 않았습니다. 구체적으로는 SPDY HTTP 메소드와 헤더를 사용하지만 일부 헤더를 삭제하고 연결 및 데이터 전송 형식을 관리하는 HTTP 부분을 다시 작성하므로 기본적으로 HTTP와 호환됩니다.

Google은 SPDY 백서에서 프로토콜 스택 아래로 침투하여 전송 계층 프로토콜(TCP)을 대체할 것이라고 명시했지만 이는 일시적으로 배포 및 구현이 어렵기 때문에 Google은 먼저 애플리케이션 계층 프로토콜인 HTTP를 개선할 계획입니다. 먼저 SSL 위에 세션 계층을 추가하여 SPDY 프로토콜을 구현하는 동시에 HTTP의 GET 및 POST 메시지 형식은 변경되지 않고 그대로 유지됩니다. 즉, 기존의 모든 서버 애플리케이션이 필요하지 않습니다. 수정되었습니다.

따라서 현재 SPDY의 목적은 HTTP를 강화하고 HTTP에 대한 더 나은 구현과 지원을 제공하는 것입니다. SPDY가 향후 널리 사용되면 왕자를 위한 사향고양이로 대체될 것인지에 대해서도. HTTP를 혁신하고 인터넷 전체에 혁명을 일으키는 것이 Google의 임무입니다.

SPDY를 다시 생성해야 하는 이유는 무엇인가요?

월드와이드웹(World Wide Web)의 아버지인 팀 버너스 리(Tim Berners-Lee)가 HTTP를 발명하고 장려하여 오늘날 인터넷에서 가장 인기 있는 프로토콜이 된 지 10년이 넘었습니다(현재 HTTP 1.1 사양도 13년 동안 정체되어 있습니다.) 웹 기술의 급속한 발전, 특히 WebSockets 프로토콜의 출현, 현재 네트워크 환경의 변화, 전송 콘텐츠의 변화 등 HTML5의 지속적인 발전으로 인해 원래의 HTTP 사양은 점차 사람들의 HTTP 요구를 충족시킬 수 없게 되었습니다. 추가 개발로 인해 HTTPbis 작업 현재 HTTP에 부과된 많은 제한 사항을 해결하기 위해 HTTP 2.0을 고려하도록 그룹이 구성되고 승인되었습니다. SPDY는 HTTP가 차세대 인터넷 통신이 되기 위해 1.1에서 2.0으로 넘어가려고 할 때 Google이 출시한 프로토콜입니다. 오랫동안 HTTP 2.0에서 실행 가능한 유일한 옵션으로 여겨져 왔습니다.

HTTP 프로토콜의 단점

1. 비효율적인 단방향 연결 요청

HTTP 프로토콜 가장 큰 단점은 각 TCP 연결이 하나의 HTTP 요청에만 대응할 수 있다는 것입니다. 즉, 각 HTTP 연결은 하나의 리소스만 요청하며 브라우저는 여러 연결을 설정해야만 이 문제를 해결할 수 있다는 것입니다. 게다가 HTTP의 요청은 엄격하게 FIFO(선입선출)입니다. 중간 요청을 처리하는 데 시간이 오래 걸리면 후속 요청이 차단됩니다.

(참고: HTTP 파이프라이닝이 연결 요청을 개선했지만 복잡성이 크게 증가하여 대중화되지 않았습니다.)

2. 클라이언트가 요청을 적극적으로 시작할 수 있습니다

서버는 클라이언트가 요청을 보낼 때까지만 기다릴 수 있는데, 이는 사전 로딩을 충족할 수 있는 현재 상황에 대한 제약입니다.

3. HTTP 헤더 중복성

HTTP 헤더는 사용자와 같은 중간에 중복된 정보를 포함하여 동일한 세션에서 반복적으로 전송됩니다. Agent, Host 등 반복적으로 전송할 필요가 없는 정보도 반복적으로 전송되므로 대역폭과 자원이 낭비됩니다.

SPDY 프로토콜의 장점

1. 다중화 요청 최적화

SPDY 규정이 있을 수 있습니다. SPDY 연결 내에서 무제한 병렬 요청을 통해 여러 개의 동시 HTTP 요청이 TCP 세션을 공유할 수 있습니다. 이러한 방식으로 SPDY는 단일 TCP에서 다중화됩니다. 각 요청에 대해 별도의 연결을 여는 대신 연결에 대한 여러 요청을 통해 웹 페이지의 모든 리소스를 전송하기 위해 하나의 TCP 연결만 설정할 수 있습니다. 이는 메시지 상호 작용의 왕복 시간을 줄일 뿐만 아니라 새로운 연결 생성으로 인한 지연. TCP를 더욱 효율적으로 만듭니다.

또한 SPDY의 다중화는 우선순위를 설정할 수 있습니다. 요청을 하나씩 엄격하게 처리하는 기존 HTTP와 달리 CSS를 먼저 선택적으로 전송합니다. 이렇게 더 중요한 리소스를 전송한 다음 웹사이트 아이콘과 같은 덜 중요한 리소스를 전송하면 중요하지 않은 리소스가 네트워크 채널을 차지하는 문제를 방지하고 성능을 향상할 수 있습니다. TCP 성능.

2. 서버 푸시 기술 지원

서버는 클라이언트와의 통신을 적극적으로 시작하고 클라이언트에 데이터를 푸시할 수 있습니다. 항상 빠른 네트워크를 유지하세요.

3. SPDY는 HTTP 헤더를 압축

압축한 후 중복되는 데이터 전송 비용을 절약할 수 있습니다. 대기 시간과 대역폭이 있습니다.

4. SSL 전송 프로토콜 강제 사용

Google은 향후 웹의 발전 방향은 안전한 네트워크 연결이 되어야 한다고 믿습니다. 모든 요청은 SSL로 암호화되어야 하며 정보 전송은 더욱 안전합니다.

SPDY 프로토콜의 의미

Google에 따르면 SPDY는 웹을 더 빠르게 만들기 위한 목적(웹 전체를 빠르게 만들기 위해 노력)만을 위해 만들어졌으며 그 이름은 SPDY입니다. SPDY(Speedy)도 이를 암시하는 것 같습니다. 그렇다면 SPDY의 의미는 무엇입니까?

1. 일반 사용자:

사용자 입장에서는 브라우저에 숨겨진 SPDY와 HTTP 사이에 별 차이가 없다고 느낄 수 있습니다. Google 서비스는 Chrome에서 매우 빠릅니다. 크레딧은 SPDY에 전달됩니다. 또한, 웹사이트 정보 전송이 암호화된 후에는 정보가 가로채지는 등의 걱정이 없어 보안과 기밀성이 크게 향상됩니다.

2. 프론트엔드 인력 :

프론트엔드 엔지니어들에게 페이지 효율성을 높이는 것은 매우 중요한 일이며, 대부분 현재 페이지가 로드될 때 각 사진과 아이콘에 대해 CSS Sprites와 같은 방법을 사용합니다. 그들은 모두 하나의 연결을 요청하고 한 페이지의 이미지 요청 수를 줄이기 위해 서로 다른 페이지에서 서로 다른 이미지를 참조하기도 합니다. 이제 SPDY의 요청 최적화를 사용하면 요청 순서를 다시 정렬할 수 있어 페이지가 로드될 때 이미지 요청의 영향을 크게 줄일 수 있습니다. 예를 들어 2012년 Geek Park Innovation Conference나 Geek Park의 27차 Great Wall Conference와 같이 Geek Park의 등록 페이지에 등록된 사용자가 너무 많으면 아바타에 대한 요청이 둔화될 것임을 분명히 느낄 수 있습니다. 전체적인 페이지 로딩이 느려지거나, 타오바오나 웨이보를 자주 가보시는 분들은 이 부분을 깊이 이해하실 거라 믿습니다. 일단 인터넷 속도가 조금 느려지면, 애플 같은 제품도 있을 겁니다. App Store(지역으로 인한 서버 지연 제외) Doujia와 같은 애플리케이션 배포 플랫폼의 애플리케이션 아이콘은 아래 동영상과 같이 느리게 새로 고쳐집니다.

3. 운영 및 유지 관리 인력:

SPDY는 연결 수를 줄일 뿐만 아니라 각 클라이언트가 차지하는 리소스도 줄입니다. 서버가 줄어들어 더 많은 메모리와 CPU가 확보됩니다. 또한 SPDY를 결합하면 탐색 속도를 두 배로 늘리고 페이지 로딩 대기 시간을 최대 2배까지 향상시킬 수 있습니다. 64%.

널리 지원되는 SPDY 프로토콜

Chrome 브라우저와 Gmail과 같은 Google 네트워크 서비스를 사용하는 경우 실제로 더 이상 액세스할 수 없습니다. 이러한 서비스는 HTTP를 통해 이루어집니다. 브라우저에서 열기 chrome://net-internals/#spdy를 검색하면 이미 SPDY 프로토콜을 사용하고 있음을 알 수 있습니다. (Google 자체 Gmail, Google Plus 및 기타 Google 서비스 외에도 Twitter 및 Webtide와 같은 다른 공개 사이트도 이 프로토콜을 지원했습니다. 중국에서는 WebKit 기반 Wandoujia 2.0도 Chrome의 SPDY 기술을 도입하여 더욱 개선할 것이라고 밝혔습니다. 속도.

SPDY를 구현하려면 브라우저 클라이언트와 웹 서버 모두의 지원이 필요합니다. 말할 필요도 없이 Google 자체 Chrome 및 Chromium과 같은 모든 클라이언트 브라우저는 이미 SPDY를 지원합니다. . Mozilla의 Firefox도 Firefox 13부터 기본적으로 SPDY를 지원합니다. Amazon Silk의 SPDY 사용은 실제로 Google의 Chrome 및 Firefox보다 나쁘지 않습니다.

웹 서버의 경우 가장 널리 사용되고 널리 사용되는 Apache, Netty, Jeety, Varnish, Erlang 및 Hightide 애플리케이션 서버가 포함됩니다. Node.js 서버는 SPDY에 대한 지원도 발표했습니다. (Nginx도 SPDY를 지원한다고 하더군요)

SPDY를 어떻게 배포하나요?

최근 Google은 가장 널리 사용되는 웹 서버인 Apache용 플러그인 mod_spdy를 공식 출시했습니다. 이를 다운로드하여 설치하면 Apache 서버에서 사용할 수 있습니다. SPDY 프로토콜은 Chrome, FireFox 등 SPDY 프로토콜과 호환되는 브라우저와 통신합니다. 앞서 언급했듯이 SPDY는 HTTPS를 통해 실행되며 HTTPS가 아닌 트래픽은 mod_spdy의 영향을 받지 않습니다.

SPDY 배포 요구 사항:

1. Apache 2.2(≥2.2.4)

2. mod_ssl 모듈 활성화

SPDY 배포 단계:

1 mod_spdy 모듈 다운로드

다운로드 페이지로 이동해당 시스템에 맞는 설치 패키지를 다운로드

2. module

시스템 터미널에서 다음 명령줄을 실행합니다.

dpkg -i mod-spdy-*.deb

apt-get -f install

-시스템은 Debian/Ubuntu

------- --------- --------------- ---------

yum install at (아직 'at'이 설치되어 있지 않은 경우)

rpm - U mod-spdy-*.rpm

-시스템은 CentOS/Fedora

3. 서버(Apache)를 다시 시작합니다

sudo /etc/init.d/apache2 restart(Debian/Ubuntu)

4. 활성화 여부 확인

Chrome 브라우저를 열고 chrome://net-internals/#spdy 페이지에 접속하여 호스트 이름이 식별자 표시줄에 나타나는지 확인하세요. 나타나는 경우 배포가 완료된 것입니다. 나타나지 않는 경우에는 서버 오류 로그(error.log)를 확인하세요.

위 내용은 nginx의 spdy 프로토콜을 소개하며, PHP 튜토리얼에 관심이 있는 친구들에게 도움이 되기를 바랍니다.