WebSocketについて調べてみた。 - Nao Minami's Blog
実はけっこう前からWebSocketの詳しい仕組みについて気になってて、遂に一念発起して調べてみた。何かとても良さげっぽい。 そもそもWebSocketとは Webにおいて双方向通信を低コストで行う為の仕組み。インタラクティブなWebアプリケーションではサーバから任意のタイミングでクライアントに情報の送信とかしたい事があって、例えばFacebookのチャットアプリみたいに多数のクライアントが一つのページにアクセスしてて誰かがメッセージを投稿するとそれをその他のユーザーに通知したい場合があって、そういった時に双方向通信の必要性が出てくる。 元々はWebにおいてはHTTPしか通信の選択肢が無くてHTTPのロングポーリング使って無理矢理双方向通信実現したりしてたんだけど、流石に無駄が多すぎるし辛いよねって事でWebSocketというプロトコルが作られた。 WebSocketにおいては、TCP上で
300 Multiple Choices - HTTP Status Code
このドメインは お名前.com から取得されました。 お名前.com は GMOインターネット(株) が運営する国内シェアNo.1のドメイン登録サービスです。 ※表示価格は、全て税込です。 ※サービス品質維持のため、一時的に対象となる料金へ一定割合の「サービス維持調整費」を加算させていただきます。 ※1 「国内シェア」は、ICANN(インターネットのドメイン名などの資源を管理する非営利団体)の公表数値をもとに集計。gTLDが集計の対象。 日本のドメイン登録業者(レジストラ)（「ICANNがレジストラとして認定した企業」一覧（InterNIC提供）内に「Japan」の記載があるもの）を対象。 レジストラ「GMO Internet Group, Inc. d/b/a Onamae.com」のシェア値を集計。 2024年5月時点の調査。
クッキーの最大サイズ制限について
Updated: 2004-01-11 22:26:43+0900 - [ HOME ] はじめに この文書は、クッキーの最大サイズの制限について説明したものです。なぜこんなことを調べ始めたかについては、日記、もじら組のスレッド、および、実際に問題を再現するこちらのページをご覧下さい。 この文書を書くに当たって、もじら組での議論が非常に参考になりました。ありがとうございます。自分は最初クッキーの仕様について勘違いしていて、いろいろ問題のある発言をしていて恥ずかしいのですが……。まだ間違っている個所があるかもしれません。間違いを発見されましたら、ご連絡いただけると嬉しいです。 クッキーの個数 クッキーは、「名前＝値」の1つの組みを1個と数えます。変数1個がクッキー1個に相当します。Netscapeの仕様およびRFC 2109(obsolete)によると、クライアントは1つのホストまたはドメイ
Cookieを利用したセッション維持(Sticky)の問題点 - sanonosa システム管理コラム集
ロードバランサーの機能のうち、セッション維持は重要な役割な一つです。セッション維持を実現するための方法としては主に4つあります。 ソースIPアドレス利用 Cookie利用 SSL Session ID利用 URL利用 一番手軽なのはソースIPアドレスを利用する方法なのですが、NAT環境では全てのマシンが同じIPに見えてしまうのでこの方法が使えない場合も多いと思います。そんなわけで私はこれまでCookieを利用する方法をよく使っていました。しかし最近になってCookieを利用したセッション維持が失敗するケースが増えてきました。それはなぜか？ 【Cookieを利用する方法の問題点】 Cookieを利用したロードバランスでは、セッション情報をCookieに書き込みます。ところでCookieの仕様をRFC2965で確認してみると at least 300 cookies（少なくとも300個のCoo
CNET Japan Blog - 江島健太郎 - Kenn's Clairvoyance：梅田サロン中止のお詫び、およびアーキテクチャ変更についての技術詳細レポート
先週末に予定されていたJTPA企画の梅田さん主催オンラインサロンですが、会場に多くの人が集まるにつれてLingrが重くなってしまうという事態に陥ってしまい、まるでイベントの体をなさないまま時間が過ぎてしまい、あえなく中止となってしまいました。 当イベントを楽しみにしていた皆様、そして梅田さんはじめJTPAスタッフの方々には、本当に申し訳なかったと思います。ここに改めてお詫び申し上げます。 Macworld 2007のときには180人を収容して何の問題もなく快適に使えていたので、「1000人はわからないけど、200人ぐらいなら大丈夫だろう」とたかをくくっていたのが間違いでした。 今回はその反省も含めて、内部で検証した技術情報をすべて公開し、どのような問題に直面し、どのように解決にあたっているのかをお伝えすることで、特に技術者の皆さんに役立つフィードバックにしたいと思います。 ■今回のアーキテ
404 Blog Not Found:HTTPサーバーのパイプライン対応
2006年12月21日17:30 カテゴリSciTech HTTPサーバーのパイプライン対応 今回は、HTTPのパイプラインの話。 「RFC2616の同時接続数の規定」@水無月ばけらのえび日記 「HTTPの同時接続数はどうあるべきか? (slashdot.jp) 」というお話。誰も原文を引用していないのが悲しかったので、引いておきます。 スラッシュドット ジャパン | HTTPの同時接続数はどうあるべきか?-taka2さんのコメントそれなら、「同時接続」しなくても、結果が返ってくる前に次のリクエストを送出して「リクエスト送信」と「結果受信」を並行して行えるようになれば、スループットの向上は見込める。 それがパイプライン化 [mozilla-japan.org]で、同時接続するよりも効率が良い。パイプライン化の前に、HTTPで何が行われているのかを、実際に見てみよう。telnetコマンドがあ
CNET Japan Blog - 江島健太郎 / Kenn's Clairvoyance：Lingr and Comet - 技術解説編
さて、お待たせしました。いよいよCometとLingrについての技術解説です。 ■Comet解説 さて、まずはCometとは何で、どういう背景によって生まれたのか、についての解説から始めます。 まず前提として、Webアプリケーションにおいては、通信開始のトリガーは常にクライアント側が握っています。つまりURLを入力したりボタンをクリックしたときなどに通信が発生することになるわけですが、このようなアーキテクチャは、サーバ側で発生した変化をリアルタイムにクライアント側に通知することが原理的にできないことを意味します。 チャット・アプリケーションでは、複数のユーザから不定期にメッセージが送信され、それが他の参加者に一斉に配信されなければなりません。しかし、メッセージを受け取ったサーバ側では、それをクライアントに即座にプッシュで通知する方法がないのです。 そのため、一定期間ごとにブラウザがサーバに
どさにっき - Gmail Mail Fetcher
2006年12月11日(月) ■ Gmail Mail Fetcher _ よそのメールサーバに溜まったメールを Gmail が POP で読み出してくれる機能ができたっていう 記事。 _ が、これができて「完璧になった」だって。これまで実装されてなかったことを批判してきただって。えー。なんで？ _ Gmail がよその POP サーバからメールを拾ってくるには、その POP サーバに自分のアカウントでログインするための情報を google に教える必要がある。Gmail のメールボックスに溜まったメールにアクセスするための情報を google が知ってるというのはおかしなことではない。でも、google とは無関係なサーバに溜まったメールを読み出すための情報を google が知ってるってのは話が違う。google だからどこの馬の骨とも知れない業者ではないだろうけど、それでもれっきとし
mod_limitipconn install
mod_limitipconn install and configuration mod_limitipconn のインストールと設定 IP アドレス単位で接続数の制限をするだけのモジュールです。 帯域制限は行いません。 また、今のところ IP アドレスを "限定して" の制限は行えない模様。 [ from README ] The limits defined by mod_limitipconn.c apply to all IP addresses connecting to your Apache server. Currently there is no way to set different limits for different IP addresses. [ from README 意訳 ] mod_limitipconn.c で指定された制限は、apache サーバ
mod_limitipconn.c
Home : mod_limitipconn.c : mod_limitipconn.c - Apache 2.x port mod_limitipconn.c - Apache 2.x port I have ported the original mod_limitipconn module to Apache 2.x. The most recent version has been tested on Apache 2.4 and Apache 2.2. Downloads source package README file Precompiled win32 DLL for Apache 2.0 (contributed by Apachez) Precompiled win32 DLL for Apache 2.2.11 (contributed by ntropic) Pr
– このドメインはお名前.comで取得されています。
このドメインは お名前.com から取得されました。 お名前.com は GMOインターネット(株) が運営する国内シェアNo.1のドメイン登録サービスです。 ※表示価格は、全て税込です。 ※サービス品質維持のため、一時的に対象となる料金へ一定割合の「サービス維持調整費」を加算させていただきます。 ※1 「国内シェア」は、ICANN(インターネットのドメイン名などの資源を管理する非営利団体)の公表数値をもとに集計。gTLDが集計の対象。 日本のドメイン登録業者(レジストラ)（「ICANNがレジストラとして認定した企業」一覧（InterNIC提供）内に「Japan」の記載があるもの）を対象。 レジストラ「GMO Internet Group, Inc. d/b/a Onamae.com」のシェア値を集計。 2024年5月時点の調査。
狐の王国 最大接続数を増やして速くなったと喜ぶ人々、再び
#2 最大接続数を増やして速くなったと喜ぶ人々、再び またこういうバカなことをする輩 が現れた。 2年近く前の記事 でも書いたのだが、肝心の情報が当時俺が噛みついたサイトのコメント欄にあったりして、さらにはそのサイト消えちゃってる *1 ので、ここに少しまとめておこう。 まず考慮にいれて置かねばならないのは、RFCで定められたHTTPにおいて、同時接続数が明記されてるということ。 HTTP/1.0 同時接続数は4つまでと慣習的に定められている。 HTTP/1.1 同時接続数は2までとRFC2616において定められている。その代わりpipeliningという手法が定義されている。 そしてこれが何故制限されてるかというのは、 接続をオープンするのはサーバに負荷がかかる ゆえに接続を同時にオープンできる数には限りがある 1人が多数の接続を同時にオープンすると、他の人が繋げなくなる という、わかっ
Studying HTTP
このドメインは お名前.com から取得されました。 お名前.com は GMOインターネット(株) が運営する国内シェアNo.1のドメイン登録サービスです。 ※表示価格は、全て税込です。 ※サービス品質維持のため、一時的に対象となる料金へ一定割合の「サービス維持調整費」を加算させていただきます。 ※1 「国内シェア」は、ICANN(インターネットのドメイン名などの資源を管理する非営利団体)の公表数値をもとに集計。gTLDが集計の対象。 日本のドメイン登録業者(レジストラ)（「ICANNがレジストラとして認定した企業」一覧（InterNIC提供）内に「Japan」の記載があるもの）を対象。 レジストラ「GMO Internet Group, Inc. d/b/a Onamae.com」のシェア値を集計。 2024年5月時点の調査。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Yahoo
RFC2109
ドメインパーキング
https://www.ietf.org/rfc/rfc2616.txt
ywcafe.net
https://www.ietf.org/rfc/rfc2518.txt
はてなフォトライフAtomAPI