サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
体力トレーニング
github.com/yuuki
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
GoでHTTP APIサーバ書くときのスタック 最近書いているJSON APIサーバはこういう感じ。 リポジトリストラクチャ Go best practices, six years in を参考に。 個人的には、pkg ではなく、lib を使っている。 HTTPサーバ WAFを使わずに、net/http ベースでハンドラを書く。 negroniは、PerlのPlack::Middlewareのような感じで、net/http をラップしてくれる。 panicをキャッチして、ISEにしてくれる Recovery https://github.com/urfave/negroni#recovery アクセスログを吐いてくれる Logger https://github.com/urfave/negroni#logger その他いろいろ https://github.com/urfave/neg
nginxのステータスコード444 nginx独自のステータスコード444は、レスポンスヘッダを返さずにコネクションを切断できる。レスポンスヘッダを返さないので、ステータスコード444をクライアントが受け取ることはない。 http://nginx.org/en/docs/http/ngx_http_rewrite_module.html#return The non-standard code 444 closes a connection without sending a response header. DoS攻撃など、特定条件のアクセスをBANするときに、なるべく計算機リソース消費を抑えたいときに使えるはず。 403を返すときなどと比べて、レスポンス送信のためのCPUコストを節約 403を返すときなどと比べて、レスポンスヘッダ分のネットワーク帯域を節約 HTTP Keepalive
// https://github.com/nginx/nginx/blob/9842cff/src/http/ngx_http_request.h#L120-L126 /* * HTTP does not define the code for the case when a client closed * the connection while we are processing its request so we introduce * own code to log such situation when a client has closed the connection * before we even try to send the HTTP header to it */ #define NGX_HTTP_CLIENT_CLOSED_REQUEST 499 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の設定をテストできない
子プロセスでacceptedなソケットをclose()すれば、FINパケットが送られると思っていたが、親プロセスでもacceptedなソケットをclose()する必要があった UNIXネットワークプログラミング第2版の4.8節 並行サーバに以下のようなことが書かれていた。 ソケットやファイルはすべて参照カウントをもつ。fork()すると子プロセスがディスクリプタを複製するため、参照カウントが2になり、子プロセスがclose()するだけだと参照カウントが0にならず、FINパケットが送信されない。したがって、親プロセスでも同じソケットディスクリプタをclose()する必要がある。 強制的にFINを送るshutdown()というものもある。shutdown()をどういうときに使うかもUNIXネットワークプログラミングにかかれていた。 大量に子プロセスが残っていて、ab -n 1000 -c 1
[pid 2406] accept4(3, <unfinished ...> [pid 2407] sched_yield( <unfinished ...> [pid 2406] <... accept4 resumed> {sa_family=AF_INET, sin_port=htons(42741), sin_addr=inet_addr("127.0.0.1")}, [16], SOCK_CLOEXEC|SOCK_NONBLOCK) = 5 [pid 2406] epoll_ctl(4, EPOLL_CTL_ADD, 5, {EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, {u32=1105458016, u64=139991269503840}}) = 0 [pid 2406] getsockname(5, {sa_family=AF_INET, si
このページを最初にブックマークしてみませんか?
『yuuki (y_uuki)』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く