なぜあなたがウェブサイトをHTTPS化するとサイトが遅くなってユーザーが逃げていくのか - 射撃しつつ前転 改
完全に釣りタイトルですけど中身は真面目に書くよ。 近年、ウェブサイトのHTTPS化が流行のようになっている。私の知る限り、Googleの各種サービスやTwitter、Facebookなどが完全にHTTPSで通信を行うようになっている。HTTPS、つまりSSLによる通信の暗号化によって、ユーザにこれまでよりも安全なウェブサイトを提供できる。 しかし、あなたが作っているサイトをふと思いつきでHTTPS化してしまうと、たぶん、これまでよりもサイトが遅くなる。ここでは、HTTPSで通信する場合の問題を解説する。 なぜ遅くなるのか HTTPで通信する場合、クライアントがサーバへと接続するためにはTCP/IPの3ウェイハンドシェイクという手順が必要になる。めんどくさいのでここでは詳しくは説明しないが、要するにクライアントがリクエストを投げる前にパケットを１往復させないといけないのである。パケットの往復
日本語入力を支える技術 振り返り、もしくは技術書を書きたい人へ - 射撃しつつ前転 改
本を書いてからこっち、年度末で忙しかったり、体調がずっと悪かったりしていますが、そろそろ本気出します。正誤表も大幅にアップデートします。今書いてる。 今日は、本を書いてみてどうだったか、ということをふり返る。たぶんこれで本について触れるのは最後かな。宣伝はたまにすると思いますが。 ※思いがけず大量にアクセスがあったから、最後に追記を書いたので、そっちも読んでね！ 本を書いたきっかけ 会社の方でPFIセミナーという勉強会のようなものをやっており、なぜかそれがUStreamでインターネットに中継されているのだが、そこで日本語入力の話をしたら「本書かない？」って話が来た。編集さんとは、その前年に会社に来たWEB+DB Pressの記事執筆依頼で記事を書いた際に知り合ったので、そういう意味では貪欲にチャンスを掴みに行った結果であると言えなくもない。 PFIセミナーがUSTで中継されるようになったの
強烈に便利なzshrcの設定 3種盛り - 射撃しつつ前転 改
タイトルはやや釣りぎみのような気もするが、この設定がないサーバで長時間作業したくない、と思う程度には便利なので、個人的には釣りではないと言える。 ctrl + 矢印で単語単位のカーソル移動 コマンドの真ん中あたりに間違いがあった場合、修正するためにカーソルを移動させるのはちょっとした苦痛である。デフォルトのキーバインドだと、emacsバインディングであればalt + bとかalt + nで単語単位で移動できるのだが、これは片手で打つと親指に無理がかかるキーバインドである。そこで、emacsと同じように、ctrl + ←→ で単語単位の移動を可能にしておく。ついでに、/は単語の一部と見做さない様に設定しておく。この設定により、長いパス名の中程に間違いがあった場合に修正するのが楽になる。 bindkey ";5C" forward-word bindkey ";5D" backward-wor
Firefoxからsshのダイナミック転送を使って非公開サーバへアクセスする - 射撃しつつ前転 改
sshにはダイナミック転送という機能がある。この機能を使うと、sshはアプリケーション側にはSOCKSプロクシとして振る舞うが、そこからsshの接続先までは暗号化された状態で通信が行われる。 これだけだと通常のトンネリングとどう違うのかよくわからないかもしれないが、ダイナミック転送の場合は転送ポートを指定する必要がない。ここがダイナミックと表現される所以だろう。 例えば、オフィスAにある開発サーバdev1にオフィス外からアクセスしたいとする。しかし、dev1はオフィス外には公開されておらず、踏み台サーバladd1を経由してしかアクセスするしかない。ladd1はsshのみが動いており、これまではsshのトンネリング機能を使ってアクセスしてきたのだが、ウェブアプリケーションをデバッグする際はいちいちウェブアプリケーションのポート毎にトンネルを掘るのが面倒くさい。オフィスに限らずデータセンターへ
Apacheのmod_proxy_balancerを使うときはretryを設定すべき - 射撃しつつ前転
今作っているサービスは、Apacheのmod_proxy_balancerを使ってロードバランシングしている。しかし、バックエンドのサービスサーバを一旦落としてから復帰させると、コネクションがしばらくつながらないという問題に悩んでいた。1分ぐらい放置するとつながるようになるんだけど、1分は結構長い。 よくわからないのでソースを読んでみたところ、mod_proxy_balancer.cを眺めた感じ、ap_proxy_retry_workerという関数がコネクションの再確立をしているのではないかと思えた。しかし、関数の定義を眺めてみると、現在時刻がエラー発生時刻とworker->retryを足した数字よりも大きければworkerのstatusからPROXY_WORKER_IN_ERRORのビットを下ろしているだけで、コネクションの確立がどうのこうのなんて関数はまったく呼ばれてない。ここでなにが
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
