Go Conference 2018 Springで話した内容です。 話し手は、Golangを利用して、FTPプロキシサーバを開発しています。その際に起こった問題や、Golangにおける複数ソケットを扱う際のテクニックを紹介します。
以前書いたとおり、ApacheではリバースプロキシでバックエンドとHTTP2通信することができます。 asnokaze.hatenablog.com Nginxの場合は、開発者のメーリングリストでGoogleの人が書いてる「ngx_http_v2_upstream」パッチを利用することでバックエンド(upstream)とHTTP2通信することが出来るようになります。 パッチ [PATCH 01 of 14] Output chain: propagate last_buf flag to c->send_chain() [PATCH 02 of 14] Upstream keepalive: preserve c->data [PATCH 03 of 14] HTTP/2: add debug logging of control frames [PATCH 04 of 14] HTTP/
リバースプロキシのコンフィグテスト やりたいこと Apacheをnginxに置き換えたい Apacheやnginxをバージョンアップしたい テストパターン パターン1: 本番のproxyサーバに実際にリクエストする パターン2: proxyサーバをテスト用に起動しつつ、upstreamやlistenディレクティブなどconfigの一部を書き換える パターン3: ngx_mrubyやmod_mrubyで設定をmrubyで書き、mruby-mtestなどでテストコードを書く パターン2はconfigの一部を書き換えるため、本当に本番の環境で正しく動作するかわからない問題がある。テストコードがnginxやApacheなど特定の実装に依存する。CIは回しやすい。 パターン3はngx_mrubyやmod_mrubyでconfigを書かなければならないため、今動いているproxyの設定をテストできない
Amazon S3の利用料節約を考えてみる ~apache(mod_proxy,mod_cache設定編) Amazon S3の利用料節約を考えてみる(の結果) の続きの話しです。前回、構成については説明しましたが、具体的にapacheでどうやっているの?については触れていなかったので、今回apacheの設定に絞って説明したいと思います。 こんな構成 haproxy の話しは今回のリバースプロキシにはとりあえずあまり関係のない話しなので割愛しますね apache のインストール apache 最新版をyum でインストールする にまとめました。これを参考にと言いたいところですが、単にこれでインストールしましたと言いたかっただけなので無視してもらって結構です /etc/init.d/httpd.conf の編集 インストールが無事完了しましたら、httpd.confの編集をします 以下の箇所
今までFiddlerをただのセッションの中身を確認できるLocal Proxyとしてしか見ていなかったのですが 改めて良く調べると色々できることが多すぎると判明。感動したので便利な機能をまとめてみました。 先に簡単に説明しておくと、FiddlerはMicrosoftが無料で配布しているWeb Debugging Proxyです。 Windows環境にインストールして、ブラウザとサーバの間の通信を読んだり操作したりできます。 配布サイトはこちら。 Fiddler Web Debugger – A free web debugging tool 動作環境は「Windows 2000 / XP / 2003 / Vista with Microsoft .NET Framework v2.0 or later」 今回使ったバージョンは、2009年9月10日時点で最新の安定版、2.2.4.6。 と
経緯 WebSocketを使ったアプリケーションを作ったが、ポートが80しか使えない nginxでどっちも80に流したい ポイント / はまり所 WebSocketのプロキシにはUpgradeヘッダ(HTTP 1.1)への対応が必要 Upgradeヘッダへの対応は nginx v1.3.13以降 参考: WebSocket proxying 厳しい条件から先に書く デフォルトだと30秒通信がないと切断される(!) nginxでリバースプロキシしているときだけ一定時間で接続が切れるので何かと思えば、 普通のHTTPの通信と同様に30秒(だったはず)通信がなかった場合はタイムアウトってことで自動でコネクションを切ってくれていたみたい。 ping/pongを30s以内にやればいいんだろうけど、とりあえず5分に設定。 config server { listen *:80 default_serv
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
Varnish HTTP Cache¶ I’m new here, please explain this Varnish thing What is happening¶ 2024-03-18 - Varnish 7.5.0 is released¶ Our bi-annual “fresh” release is here: Varnish Cache 7.5.0 The 7.3 series is no longer supported in any capacity. 2024-03-18 - Varnish HTTP/2 Broke Window Attack¶ All Varnish Cache releases with HTTP/2 support suffer a vulnerability in the HTTP/2 protocol. Please see VSV00
NginxのTCP Load Balancing(ngx_stream_core_module) もともとNginx+で利用できたTCP Load Balancing機能というものがある http://nginx.com/products/application-load-balancing/ HTTPにかぎらずTCPレイヤでロードバランシグ機能を提供する。つまりMySQLやMemcachedのロードバランサとしても使用することができるようになる。 OSS版でも使用できるようになったらしいhttp://hg.nginx.org/nginx/rev/61d7ae76647d 試しにMemcachedのロードバランサを構築してみた(環境はubuntu14.04) nginxビルド ざっと適当にインストール sudo apt-get install libpcre3 libpcre3-dev b
古い書籍に掲載されたPHP記述の掲示板ソフトを動かしていると、ログアウト処理がうまく動作していないことに気がつきました。チェックの方法ですが、ログアウト処理の脆弱性検査の簡単なものは、「安全なウェブサイトの作り方」別冊の「ウェブ健康診断仕様」に記載されています。 (J)認証 ログアウト機能はあるか、適切に実装されているか ログアウト機能がない、あるいはログアウト後「戻る」ボタンでセッションを再開できる場合 この仕様書にある通り、『ログアウト後「戻る」ボタンでセッションを再開できる』状態でした。 おそらくセッション破棄がきちんと書かれていないのだろうと思いログアウト部分のソースを見ると、以下の様な処理内容でした(オリジナルからはリライトしています)。 <?php // logout.php require_once('common.php'); // 共通の設定・処理 session_sta
概要 社内プロキシに様々なサイトへのアクセスをブロックされたり、社外サーバにsshできなかったりする人向けに社外プロキシを立ててあらゆるサイトにアクセスする方法のまとめです。(後述しますが半分くらいネタポストです。) 他にも以下のような効果がありますので、プロキシフリーな会社にお勤めもし良かったら参考にして頂ければと思います。 なぜか2015年になっても存在するカフェとかホテルとかでの保護されていなかったりする無線wifiを使っても盗聴されない。 日本からアクセスできないサイトにアクセスできる。(海外のデータセンタ上のVMを使った場合) なお、非認証プロキシを例にしてます。認証プロキシでもあまり変わらないとは思いますが、環境が無いため未確認です。また、プロキシの挙動や設定方法はプロキシサーバの種類や設定によって多岐に渡るため、全てのプロキシで同じ方法が使えるとは限らないとは思います。 最後
2014年11月19日、20都道府県警の合同捜査本部が国内で違法にプロキシサーバーを運営する全国8業者へ一斉捜索をかけました。ここではその関連情報をまとめます。 タイムライン 大光・SUNテクノ関連 日時 出来事 2013年4月〜8月 AmebaへSUNテクノのサーバーから不正ログインが行われた可能性。 2014年1月 愛知県警が偽サイトのIPアドレスからSUNテクノを割り出し。*1 2014年2月頃 SUNテクノのサーバーに大手銀行(MUFJ?)のフィッシングサイトが開設。*2 2014年3月頃 SUNテクノのサーバーに大手銀行(MUFJ?)のフィッシングサイトが設置され当月だけで約1万3千件のアクセス。*3 2014年8月 大光とSUNテクノが捜索を受ける。 その後 大光と他1社がISPから不正行為に関わったとして契約を解除。 その後 大光、SUNテクノが他人のIDを使ってインターネッ
Nginx + Luaを用いた、ハイパフォーマンスで動的なプロキシサーバを考察中です。 そのための施策の一つとして 上流サーバへのアクセスをKeepAliveする という方法がありますが その際、プロキシサーバにどの程度性能に変化があるのかを調査してみました。 リバースプロキシのkeepalive設定 前提条件として Nginx > 1.1.4 が必要。 upstreamに keepalive というattributeがあるのでそれを設定します。 それと同時に、プロキシヘッダーにHTTP/1.1設定などを行いましょう。 ちなみにproxy_passだけだとkeepaliveできないようです。upstream必須。 あと、もちろんバックエンドサーバ側もkeepalive設定しておきます。 upstream http_backend { server oreore.micro.service;
フロントエンジニアに知ってもらいたいリバースプロキシの重要性 | RickyNews この記事が目に入って読んでみた。なるほど、昨今は Reverse Proxy は便利な L7 ルーター的なものとして認識されているのだな、と思った。URL の Rewrite や、VirtualHost 云々。確かに Reverse Proxy の便利な側面ではある一方、それらは Nginx などの Reverse Proxy でなければ実装が不可能かと言えばそんなことはないものでもある。 自分は Reverse Proxy はもうすこしサーバー/インフラ的な側面でその役割を捉えている。今更何をというものでもあるが、昼休みがてら時間があるので簡単に書いてみよう。 Reverse Proxy はWebシステム全体のリソース最適化のためのパーツ Reverse Proxy のインフラ的な視点での役割は「Web
Randen Pederson 大規模なシステムであれば使っているであろうリバースプロキシ。 セキュリティや稼働率の観点からみて利用することは非常にメリットは高いです。 ただ、社内や周りであまり知見がなく、 「動くからいいや」という理由でApacheをそのままWebサービスの一次受けとして利用されている方も多いと思います。 動くという目的からすれば確かにその通りですが、ただ一枚リバースプロキシを入れるだけで ぐっと運用効率、稼働率も拡張性も上がります。 1. ルーティング処理の簡略化 例えばRESTfulな一般的なAPI構成を作りたいと思った時に以下のようなURL構成になると思います。 http://api.something.com/search/v1/item/list.json?cid=xxxx&gid=xxxxx もしアプリケーション側のルーティングしか知らなければframewor
人間とウェブの未来(旧) 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 Docker Hubがアナウンスされて以来、焦ってDockerを触っている@matsumotoryです。 今日は早速mod_mrubyとngx_mrubyをdocker buildに対応させました。これによって、Docker環境においてmod_mrubyを組み込んだApache httpdやngx_mrubyを組み込んだnginxを迅速かつ容易に連携させる事ができるようになります。 今日はその一例を紹介したいと思います。 リバースプロキシのnginxの挙動をmrubyで制御する ngx_mrubyのGitHubレポジトリにはすでにDockerに対応させています。ですので、ngx_mrubyをcloneするとDockerfileとdocker/
nginx-1.26.1 stable and nginx-1.27.0 mainline versions have been released, with fixes for vulnerabilities in HTTP/3 (CVE-2024-32760, CVE-2024-31079, CVE-2024-35200, CVE-2024-34161). nginx-1.26.0 stable version has been released, incorporating new features and bug fixes from the 1.25.x mainline branch — including experimental HTTP/3 support, HTTP/2 on a per-server basis, virtual servers in the str
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く