HTTP/2から見えるTLS事情 - あどけない話
これは HTTP/2 アドベントカレンダー19日目の記事です。 この記事はたくさんの資料を読んだ上で書きましたが、間違いとか勘違いとかがあるかもしれません。もしあれば、指摘していただけると幸いです。 実質的に必須となったTLS HTTP/2は、HTTP/1.1と同じく、暗号化なし/ありのポートとして、80と443を使います。そのため、通信開始時にHTTP/1.1とHTTP/2をネゴシエーションするための仕組みが、HTTP/2で定められています。 このように仕様としては暗号化なしのHTTP/2が定義されていますが、Firefox や Chrome が TLS を要求するために、実質的は暗号化ありが必須となっています。これは、米国の監視プログラムPRISMに代表される広域監視(pervasive surveillance)に対抗するために、IETFがさまざまな通信にプライバシの強化を要求する方
Hash-flooding DoS と SipHash - あどけない話
以前、僕が実装している web サーバ Mighty が、Haskell で書いているにも関わらず、セグメンテーションフォールトを起こしていた。調べたところ hashable ライブラリがリンクする C の DJBX33X が、SipHash に変わったことが原因だった。このときから SipHash が気になっていたし、以前社内で説明した "Efficient Denial of Service Attacks" との関係も知りたかったので、少し調べてみた。この記事は、その覚え書き。 Hash-flooding DoS の歴史 1998 年に Alexander Peslyak 氏が Phrack Magazine で、Hash-flooding DoS を受けたことを報告している。ハッシュは、N 個の要素を挿入するのに通常 O(N) かかるが、ハッシュ値がすべて衝突する最悪の場合では O
書評「型システム入門」 - あどけない話
端的に説明するなら「正しく型付けされた項はおかしくなることがない」ことを学ぶための壮大な本。型に関する圧倒的な知識を持ち、説明がうまく、根気づよい人にのみ記すことができた英語の良書が、型システムを愛する訳者と監訳者、および(書中に名前が出てくる方も含む)豪華なレビュアの情熱によって翻訳された記念すべき書籍。税抜きで6,800円と高いが、それ以上の価値がある本である。 型システム入門 −プログラミング言語と型の理論− 作者: Benjamin C. Pierce,住井英二郎,遠藤侑介,酒井政裕,今井敬吾,黒木裕介,今井宜洋,才川隆文,今井健男出版社/メーカー: オーム社発売日: 2013/03/26メディア: 単行本（ソフトカバー） クリック: 68回この商品を含むブログ (11件) を見る 動的言語のプログラマと静的型付き言語のプログラマの間で、型についての議論が定期的に沸き上がる。今後、
例として推奨されているドメイン名とIPアドレス - あどけない話
解説記事や発表資料で、ドメインの例を出す場合、example.jp等を使うことが推奨されているのを知っている人は多いでしょう。しかし、IPアドレスの方は知らない人もいるみたいです。ここでは両方について出典を示しながらまとめます。 知っていて別の例を使うのはいいのですが、知らないで別の例を使うのはよくないです。 gTLDのドメイン名の例 RFC2606で以下のように定められています。 3. Reserved Example Second Level Domain Names The Internet Assigned Numbers Authority (IANA) also currently has the following second level domain names reserved which can be used as examples. example.com exa
文章の書き方 - あどけない話
2006年に IIJ の新人研修で「文章の書き方」という講義を担当しました。そのときの資料を何人もの人に個別に差し上げていたのですが、それも面倒になってきました。新人研修の担当者に問い合わせたところ、公開しても問題ないとのことでしたので、資料を公開します。 「文章の書き方」の資料
POPとIMAP - あどけない話
ようやく IMAP も普及したようで、POP から IMAP に乗り換える人が増えています。僕の周りのインターネット技術者も、ぼちぼち乗り換え始めました。(gmail が IMAP をサポートしたことが大きな要因でしょうか？) 彼らは優秀なのにも関わらず、こんな間違った表現を使います。 POP はメールをメールリーダに取ってくるもので、IMAP はサーバ側のメールを読むものだ POP だとよかったけど、IMAP は常にネットワークにつながっていないと辛い POP だとよかったけど、IMAP はフォルダ内のメールの数が多くなると辛い その度に、「そうじゃない」と言ってきたのですが、もうそう説明するのにも疲れてきました。そこで、正しいことを書いて、この説明はもう二度としないことにしようと思います。(DRY: Don't Repeat Yourself ですね。) 間違いの根源は、おそらく二つで
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
