パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

Google、「Webの高速化」をうたう高速データ送受信技術「SPDY」を発表 」記事へのコメント

  • 昨今のネットワークの性能からすると、HTTPやPOP3はとても性能が悪いです。

    メール容量にしたら、たった2MBほどなんでftpで/var/mail/${USER} を持ってきたら
    (帯域次第ではあるが)一瞬で転送が終るのだが、POP3を通すと、
    1. メールを取得, 2. メールのフラッシュ, 3. ローカルの処理待ち
    を届いたメールの数だけ繰り返す、なおかつ、その度にprocmailをforkするんで
    遅くて仕方がないです。

    ネットワークの遅延を100ms, サーバのレスポンスを50ms, procmailのforkと処理の
    時間を100msとすると、1つのメールあたり250msかかることになり、2000通メールが
    たまっていると、どれだけ帯域が広

    • ほかの人も書いているけど、それは、
      POP3 の話じゃなくて 特定の POP3 サーバーかクライアントの実装の話ですよね。

      POP3 サーバーを Dovecot にでもして、メールボックス形式を maildir か何か
      (mbox 以外) にでもしたらどうですか。
      (Qpopper あたりを利用して遅いとか言っているんじゃないかと邪推 :-p)

      > 同時にメールを取得して同時にメールをフラッシュできるようなプロトコルが

      「メールのフラッシュ」って、具体的にどこのどんな動作のことを指していますか?

      • POP3ですと、USER, PASS, STAT, LIST, RETR, DELEの順番にリクエストしていくわけですが、
        RETRを送った後にOK+Octets数のステータスを受信するまでに次のRETRを発行しても問題なく
        動作するものなのでしょうか?

        また、最近は実際にそのようなリクエストの出し方をしているメーラが多いのでしょうか?

        もし、このようなリクエストの出し方ができるのであれば、プロトコルの限界ではなく、
        指摘の通り、特定のメーラの実装の話です。

        「メールのフラッシュ」とは、RETRを実行した後に実行するDELEおよびその完了動作を指して
        使っています。

        親コメント
        • > POP3ですと、USER, PASS, STAT, LIST, RETR, DELEの順番にリクエストしていくわけですが、
          > RETRを送った後にOK+Octets数のステータスを受信するまでに次のRETRを発行しても問題なく
          > 動作するものなのでしょうか?

          諸々の事情でたぶん動作するでしょうが、意味はないでしょう。

          それよりも、どうしてこれ↑とこれ↓から、

          > また、最近は実際にそのようなリクエストの出し方をしているメーラが多いのでしょうか?

          これ↓が導き出されるんですか?

          > もし、このようなリクエストの出し方ができるのであれば、プロトコルの限界ではなく、
          > 指摘の通り、特定のメーラの実装の話です。

          あなたの書いた /var/mail/${USER} とか、procmail は POP3 仕様ではないので、
          mbox 形式のメールボックスのフラッシュが遅いだとか、procmail の fork が
          遅いだのってのは、POP3 とは関係ありません。

          POP3 のプロトコル仕様を勉強してくださいな。

          親コメント
          • thorin氏が#1672793 [srad.jp]で書いたように、POP3はpipeline capabilityが無いと遅くなりますし、POP3のデータをftpで転送すりゃ速度は出るでしょう。POP3にpipeline capabilityがあったとしてもfetchmailでprocmailのフィルタを通すなど、(車1台1台がハイウエイの料金を支払うときのように)1通1通のメールに対しシーケンシャルに処理行なえば、メール毎にTCPは1セグメントから転送を開始しますので、(車が料金所で混雑するように)POP3のプロトコルの性能上処理は遅くなるでしょう。これは、POP3(というか、HTTPしかり、複数のオブジェクトを取ってくる必要のあるプロトコルをTCP上で動作させた場合に発生する)固有の問題です。(メールを/var/mail/${USER}のように)単一のオブジェクトとみなしてftpで転送する場合には、この現象は発生しません。

            昨今のネットワークのシステム設計では、このようなみかけのネットワークレイテンシィをいかに抑制するかが課題となっていると思います。

            親コメント
        • > POP3ですと、USER, PASS, STAT, LIST, RETR, DELEの順番にリクエストしていくわけですが、
          > RETRを送った後にOK+Octets数のステータスを受信するまでに次のRETRを発行しても問題なく
          > 動作するものなのでしょうか?

          昔 POP3 server の実装やりました。

          これは POP3 server と client の実装によります。
          規格的に言うと POP3 server と POP3 client の両方が PIPELINING capability を実装している場合には上記動作が可能になります。(cf. RFC2449)
          ということで規格の方はずっと昔に既に拡張済み。

          # それよりも(世の中にあふれている?)行バッファリングでパケットを送る駄目 POP3 server の方が本当の問題だと思う
          親コメント
        • DELEは削除マークを付けるだけで、実際の削除はQUITしたときだけなんで、都度削除はしないですよ。
          そーじゃなきゃRSETでキャンセルできない。
          親コメント

Stableって古いって意味だっけ? -- Debian初級

処理中...