TCPのRSTが飛ぶタイミングと認証が必要なHTTP POST: じーくゎい
久々のTCPネタ。 TCPのRSTについてこの記事でも簡単に触れた。 このRSTがどのようなタイミングで送信されるかというと、OSのソケットバッファに 受信データがまだ残っているにもかかわらず、アプリがcloseを実行したときに送信される（Linuxのお話）。 つまり、まだ受け取るべきデータが残っているにもかかわらず、有無を言わさずアプリが closeを実行してきたので、これは異常な状態だ、ということでRSTを送信し、 その受け取るべきデータを送ってきた送信者側に、「もうデータは送らないでくれ」と伝えたいのである。 さて、これを踏まえて考えると、実は下記のようなケースで問題が発生する。 マシンA（HTTPクライアント）はHTTP POSTのヘッダ（仮に1024バイトとする）とHTTP POSTのボディ（仮に8192バイトとする）をマシンB（HTTPサーバ）に送信した。 マシンBのOSは、9
Facebook, Twitter, Instagram等がどうやってIDを生成しているのか まとめ - Qiita
まえがき データにIDを持たせたいとき、単純な方法としては、DBの提供するauto incrementを使う場合やUUIDを利用することがある。それぞれの方法の利点欠点は以下の通り。 データベースのauto incrementを使う場合 利点: 特別な実装が必要ない 欠点: DBを1台で運用するとデータベースがパフォーマンス・障害のボトルネックになる DBを二台にするとIDのユニークさや順序の保証が困難 UUID(v4)※1を利用する場合 利点: 分散環境で各々がIDを生成しても衝突しない IDを公開したくない場合に、推測されにくいIDを生成できる 欠点: 128ビット必要、DBのインデクシングやプログラミング言語で扱うときに不利なことがある IDから時間の情報が失われる、例えば2つのIDを比べてどちらが古い投稿か判断できない 世界の大企業がどうしてるか 調べてみると多くの企業がブログなど
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
