アカウント名:
パスワード:
HTTP or HTTPSでしか使えない、という記述を見ると、Netliのノードにはキャッシュ機能が備わっているのではないかと思ったのでした。ブラウザからのリクエストに対するレスポンスをサーバーから先読みしてキャッシュしておく、
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stay hungry, Stay foolish. -- Steven Paul Jobs
ネットワーク・プロトコル？ (スコア:0)
プロトコルのように考えられます。
だとすると、MPLSを使うのと具体的にどう違うのか
あまりよくわからないのですが、、
（Netliプロトコルになっている間は、どのルータを通過しているのか
とかはわからないわけですよね？これは）
どこかにNetiプロトコルの詳細はないものでしょうか。
Re:ネットワーク・プロトコル？ (スコア:1)
HTTP or HTTPSでしか使えない、という記述を見ると、Netliのノードにはキャッシュ機能が備わっているのではないかと思ったのでした。ブラウザからのリクエストに対するレスポンスをサーバーから先読みしてキャッシュしておく、
---- 末は社長か懲戒免職 なかむらまさよし
Re:ネットワーク・プロトコル？ (スコア:2, 興味深い)
コンテンツをキャッシュするならばSSLで暗号化したままではいけません（解読するための鍵はクライアントだけが持つので）し、だからといって暗号化しない(without SSL)通信をしてしまっては意味がありません。
Re:ネットワーク・プロトコル？ (スコア:1)
よく見ると、デモにはSSLの例がないなぁ。
実際のところはどうなんでしょうか。
でも、キャッシュとは言わないまでもサーバーからの先読みはSSLでも可能ですよね。そのセッションにだけ一時的に使われるキャッシュ、とでもいいましょうか。
あとは1Mbpsで月額
---- 末は社長か懲戒免職 なかむらまさよし
Re:ネットワーク・プロトコル？ (スコア:2)
ルーター同士で連絡し合いデータ転送、要求者側に近いルーターは本物ackにあるセグメント番号を見て、そのパケットを作成し端末側に送信。
こんな感じの気がするけど。
TCPの窓拡張で窓でかくしたり、スロースタートなどの輻輳制御でスタート時のパケット数を絞っているのをやめれば良いだけの気がする。
何故OSが拡張されたTCP窓を初めっから全開で開かないのかとか、何のために輻輳制御しているのか、存在しているのか、などを考えると、なえる技術の気がする。
http1.1でキープアライブ使うときには推奨2セッションまでとかの考えあるよね。
もっと沢山セッション張るとか、一つのセッションでも読み終わる前に次の要求するとかでも、大して困らない。
ついでに、
結局は先読み技術だよね。でかいファイル相手に要求し即切りされれば、回線やサーバーに負荷掛けるんじゃないの？
まぁ、先読みサイズは制御しているだろうけどさ。
Re:ネットワーク・プロトコル？ (スコア:1, 興味深い)
endからACKが来る事を予測してACKを先行するんじゃなくて、区間ごとにデータの保証を行うと。
中継のNetli区間は、自組織内、または契約組織間で閉じており帯域の保証などもできるので、スロースタートやWindowサイズなどの輻輳制御はやらない（というか極力影響を減らす）、または、全く別のプロトコルで行うという感じなのでは？
Re:ネットワーク・プロトコル？ (スコア:2)
偽ackと表現したけど、偽要求指示パケットでもあるからね。