Q-Successから2020年8月のWebサーバのシェアが発表された。2020年8月はApacheがシェアを減らし、NginxとCloudflare Serverがシェアを増やした。Q-Successの集計データでは、Apacheの減少とNginx系の増加という傾向がはっきり示されている。シェアの値は異なるものの、他の調査データも似たような傾向を示している。 2020年8月Webサーバシェア/円グラフ 2020年8月Webサーバシェア/棒グラフ
![Nginx系が増加し、Apache減少 - 8月Webサーバシェア](https://cdn-ak-scissors.b.st-hatena.com/image/square/9f6989277a63bfb32ed2f856d2e667db6c57b1e0/height=288;version=1;width=512/https%3A%2F%2Fnews.mynavi.jp%2Ftechplus%2Farticle%2F20200808-1198182%2Fogp_images%2Fogp.jpg)
Q-Successから2020年8月のWebサーバのシェアが発表された。2020年8月はApacheがシェアを減らし、NginxとCloudflare Serverがシェアを増やした。Q-Successの集計データでは、Apacheの減少とNginx系の増加という傾向がはっきり示されている。シェアの値は異なるものの、他の調査データも似たような傾向を示している。 2020年8月Webサーバシェア/円グラフ 2020年8月Webサーバシェア/棒グラフ
2020/060/01 追記 nginx公式版が提供されました。こちらを御覧ください asnokaze.hatenablog.com NginxをHTTP/3対応させるパッチがCloudflareから提供されました (CloudflareのHTTP/3ライブラリ Quicheを利用しています。現状ではHTTP/3ドラフト23版の対応になります) github.com 基本的に、書いてるとおりにやればビルドできるのですが、無事HTTP/3しゃべるところまで確認できました ビルド rustインストールしておく $ curl https://sh.rustup.rs -sSf | sh $ source $HOME/.cargo/env書いてあるとおり $ curl -O https://nginx.org/download/nginx-1.16.1.tar.gz $ tar xzvf ngin
NGINX Unit ホームページは以下 www.nginx.com もしくはミラーだけどGitHubが以下となる github.com RestAPIやJSONで設定できる、phpのPHP-FPMやpythonのwsgiサーバーなど言語ごとのアプリケーション・サーバーを集約したアプリケーションサーバーという感じ。なのでNginxの後ろで動くサーバーという認識で大丈夫なのかな? まだversionは0.1なので、今後どんどん成長していくはず。 現状は以下に対応しているとのこと Python 2.6, 2.7, 3 PHP 5, 7 Go 1.6 or later ざっくりとした所感 プロダクトに関して 言語ごとのミドルウェア運用がNGINX Unitに集約されて嬉しい可能性がある Docker + NGINX Unit も嬉しいが、NGINX Unitだけでも十分に嬉しいかも ベンチマーク
Dockerでは一般的に次のようなコマンドを実行します。 $ docker run -d -p 8080:80 wordpress この場合、ホストマシンへの8080番へのアクセスをコンテナの80番ポートへつなぐという意味になります。そのためURLとしては、 http://ホストのアドレス:8080/ といったポート番号を使ったサーバアクセスになります。しかしこれはコンテナが増えていった場合にあまり格好良くありません。そこで nginx-proxy を使ってドメインを割り当てたアクセスを行うようにしましょう。 jwilder/nginx-proxy 用意するもの Linuxサーバ(今回はさくらのクラウドでUbuntu 14.04 LTSを使ってます) Docker(今回は1.0.1を使っています) nginx-proxyの実行 まず nginx-proxy を起動します。これはDocker
[20170809追記] nginx-1.13.4に ngx_http_mirror_module は含まれました Nginxで、リクエストを複製するmirrorモジュールがコミットされ、何もせずとも使用できるようになりそうです(現状最新コミットをビルドする必要あり)。 例えば本番環境のproxyからリクエストを複製して開発環境に流すような事も出来ます。もちろん複製処理は本来のリクエスト処理をブロックしません。 例えば以下のように、mirrorに来たリクエストを複製してバックエンドサーバに投げるようにしてみます conf server { listen 80 ; server_name localhost; mirror_request_body on; log_subrequest on; location /mirror { mirror /proxy; #/proxy宛にリクエストを
この記事では Let’s Encrypt で証明書を発行し, nginx で利用するための設定を紹介します. Nginx をアプリケーションサーバーのためのプロキシとして利用している場合を想定して, Let’s Encrypt のための webroot を別に設定しています. 概要 Let’s Encrypt では様々な方法での認証・証明書のインストール方法がプラグインとして提供されています. Nginx 用のプラグインも開発されていますが, 現時点で experimental となっているようなので, webroot プラグインを利用するのが一般的なようです. この記事では /var/www/letsencrypt に Let’s Encrypt の webroot プラグインによる認証のためのディレクトリを作成し, 以下のようなコマンドで証明書の発行を行えるようにすることを目標とします
この記事は ピクシブ株式会社 Advent Calendar 2015 10日目の記事です。 qiita.com こんにちは。Androidアプリエンジニアのいとおちゃんです。 高校生の頃からアルバイトとしてピクシブに入社してから4年目になりました。昨年は若手アルバイトと名乗っていましたが、気づいたらもう大学生です。最近はpixivマンガアプリの開発をしています。 今回はAndroidアプリ開発の話ではなく、個人的に最もアツいと感じているLet's Encryptを使ってnginxでHTTP/2サーバを立てる話をします。 Let’s Encryptを使おう Let's Encryptを利用すると、無料で認証されたSSL証明書を簡単に発行することができ、ここ最近話題を集めています。今月、Let's EncryptはようやくPublic Betaになりました。そこで、まさに今が旬ともいえるLe
インフラストラクチャー部 id:sora_h です。クックパッドでは、社内向けの Web アプリ (以降 “社内ツール”) を社外のネットワークから利用する際、アプリケーションレベルでのアクセス制御とは別に、リバースプロキシでもアクセス制御を実施しています。*1 これまで BASIC 認証あるいは VPN による社内ネットワークを経由した接続という形で許可していました。しかし、iOS の Safari などでは BASIC 認証時のパスワードを保存できない上、頻繁に入力を求められてしまいますし、VPN はリンクを開く前に接続をしておく必要があります。これにより、社内ツールを社外で開く時に手間がかかってしまう問題がありました。 これに対し、一部では typester/gate などを導入し Google Apps での認証を行なっていました。しかしいくつか問題があり、非アドホックな対応では
nginxをJavaScriptで拡張できるnginScriptがローンチされたので軽く触ってみた。 nginScriptをビルド nginScriptは今のところnginx本家のMercurialリポジトリからcloneすることができる。また、nginxモジュールの実装とnginScriptの実装が一緒に含まれているため、まずはnginScriptをビルドする。
Analytics cookies are off for visitors from the UK or EEA unless they click Accept or submit a form on nginx.com. They’re on by default for everybody else. Follow the instructions here to deactivate analytics cookies. This deactivation will work even if you later click Accept or submit a form. Check this box so we and our advertising and social media partners can use cookies on nginx.com to better
Nginxでは, serverコンテキストのlocationコンテキストにおいて, proxy_passディレクティブを利用することで任意のホストにアクセスを転送することができます. 例えば, serverコンテキストにおいて, location / { proxy_pass http://127.0.0.1:5000; } みたいに書いてあげれば, localhostの5000番ポートにアクセスを転送することが出来ます. Webサービスでは, こういう感じでNginxが443番(HTTPS)や80番ポート(HTTP)で受けたアクセスを5000番ポートなどで動いているWebアプリケーションに転送している訳です. で, このproxy_passディレクティブは, IPをそのまま書くのではなく, 次のようにドメインを書くこともできます. location / { proxy_pass http
nginxのデフォルトの動作ではクライアントから受け取ったリクエストボディをメモリにバッファリングするようになっています。 このメモリバッファのサイズはclient_body_buffer_sizeで変更することができ、リクエストボディのサイズがこのバッファのサイズを越えた場合はclient_body_temp_pathにファイルとして書き出されます。 ログレベルがwarn以上の場合はエラーログにa client request body is buffered ...という警告が出ます。 2015/03/29 14:02:20 [warn] 6965#0: *1 a client request body is buffered to a temporary file /etc/nginx/client_body_temp/0000000001, client: x.x.x.x, ser
HTTPレスポンスヘッダにサーバのバージョンの表示を消す なぜ必要? 潜在攻撃者への情報提供になることも。 もし使用中バージョンの脆弱性が明らかになった時、恰好の標的になるとか。 対応 nginx.confのhttpディレクティブに server_tokens off; を追加。
こんにちは。インフラチームの野島です。 最近、cybozu.com はロードバランサを Apache から nginx に置き換えました。 (参考: cybozu.com のリバースプロキシを nginx にリプレイス) 置き換えの一環として、Apache に実装していた DoS 対策の仕組みを nginx の拡張モジュールにする形で移植しました。今回、この拡張モジュール nginx-maxconn-module を OSS として公開しましたので紹介します。 背景 DoS 対策 秒間リクエスト数 v.s. 瞬間同時リクエスト数 実装方針 nginx-maxconn-module 基本的な使い方 高度な使い方 インストール おわりに 背景 本題に入る前に、cybozu.com において、HTTP リクエストがどのように処理されているかを説明します。 cybozu.com では、負荷分散のた
Docker container で nginx を起動するときとか、nginx.conf で何かしらのパラメータを動的に設定したいことがあると思います。server_name とか。 今回は nginx.conf で何とかして環境変数を読み込む手法を紹介します。 TL;DR env ディレクティブと ngx_http_perl_module (or lua_nginx_module) を使って、環境変数を nginx 変数に設定する。 Example server_name を環境変数 SERVER_NAME から動的に読み込む例を示します。 user nginx; worker_processes 4; env SERVER_NAME; http { perl_set $server_name_from_env 'sub { return $ENV{"SERVER_NAME"}; }'
処理能力の高さなどを理由に、近年、大規模サイトを中心に急速にシェアを拡大しているWebサーバー「Nginx」。この連載では、その特徴と魅力を分かりやすく紹介します。 第3のWebサーバーとして注目を集めるNginx 1日に数億リクエストを処理するような大規模サイトを中心に、近年急速にシェアを拡大しているWebサーバーが「Nginx(エンジンエックス)」です。HTMLドキュメントや画像ファイルといった静的コンテンツを高速で配信し、消費メモリが少なく、リバースProxyやロードバランサーといった機能も有した注目の軽量Webサーバーです。ネットクラフト社の調査によると、2014年6月時点でApache HTTP、Microsoft IISに次ぐ第3位のシェアを獲得しています。 依然としてApache HTTPやMicrosoft IISのシェアは高いものの、Nginxの認知度は日に日に高くなって
HTTPS通信は複数のプロトコル、手法が組み合わされて実現されている。そのため、暗号化手法それぞれのリスク、ブラウザの対応等様々な用件があり、全てを理解するにはちょっと時間とリソースが足りない。結局のところ、我々はどのようにして安全なHTTPS通信を提供できるのか。色々調べていたところ、MozillaがMozilla Web siteに使用する、HTTPSの推奨設定を公開している。 Security/Server Side TLS - MozillaWiki このドキュメントはMozillaのサーバ運用チームが、Mozillaのサイトをより安全にするために公開しているもので、他のサイトにそのまま適用できるかは十分に注意する必要がある。例えばガラケー向けサイトとか。そのまま使えないとしても、HTTPS通信の設定をどうすれば良いか、理解の一助になるはずだ。 この記事は上記MozillaWiki
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く