【2018/11/16 追記】 本記事は、2016 年 4 月に Google Public DNS サーバに実装された、実験的な DNS over HTTPS プロトコルについて紹介しています。DNS over HTTPS プロトコルはその後 IETF の doh ワーキンググループにて標準化が進められ、2年半後の 2018 年 10 月に RFC8484 として出版されました。本記事で紹介したプロトコルは RFC8484 に規定されたプロトコルとはいくつもの点で異なっていることにご注意ください。 Google Inc. が公開 DNS サーバを運営していることはご存知でしょうか? Google Public DNS と呼ばれるこの公開 DNS サーバは、”8.8.8.8″ という特徴的な IP アドレスで全世界のインターネットユーザに対して無料の DNS サーバ(フルレゾルバ)を提供し
前編では、CRL(Certificated Revocation List)とOCSP(Online Certificated Status Protocol)の違いと、証明書の有効/失効をブラウザで確認する方法について解説しました。後編ではまず、現時点で利用できる3種類の証明書「Domain Validation(DV)」と「Organization Validation(OV)」「Extended Validation(EV)」について説明します。 DV(ドメイン認証)証明書 DV証明書は、最も安価で最も良く利用されている証明書です。証明機関は企業や組織に求める情報を独自に設定しており、シンプルな認証内容と簡潔な手続きが特徴です。 一例を挙げると、企業側はWebサーバー上の対象となるドメインに、ドメインの認証証明機関から送信されたファイルを設置します。これだけで証明機関は正しい所有者で
* 現在お使いのネットワークは安定していません。この数字は推定値であり、実際のネットワークパフォーマンスは異なる場合があります。
二つの head of line(HOL) blocking Web 周辺のコンテキストで (HOL blocking) と言うと、実際には二つの種類がある。 HTTP での HOL Blocking TCP での HOL Blocking この二つは違うものなので、話す場合は「どの」レイヤでの話なのかは明示したい。 HTTP の HOL Blocking HTTP/1.1 のリクエスト-レスポンスの組は、常に順番を保ち同期的に行われる必要がある。 具体的に 1 つの TCP コネクション上で、 3 つの画像(a.png, b.png, c.png) を取得する場合、 HTTP リクエストは以下のようになる。
以下の記事内容について、奥一穂氏(@kazuho)より、「connectのエラーコードが信頼できなくなるといった欠点もあるのに透過 SOCKS プロキシが汎用的に良いように読めてしまう」というご指摘をいただきました。確かに、下記内容は当社が抱えていた複数の課題を短期間で解消できる「ワークアラウンド」として透過 SOCKS プロキシという技法もあることを紹介したものであり、NAT と比較して常に良いという主張をしたかったわけではありません。また、記事内では解説を省きましたが、従来より HTTP(S) 通信は NAT ではなく HTTP プロキシを利用しています。謹んで補足・訂正とさせていただきます。 猫が好きだけど猫アレルギーで近寄ることができない山本泰宇です。 先日アーキテクチャ刷新プロジェクト「Neco」を紹介しましたが、今回はその活動の一環として実施したネットワークアドレス変換(NAT
本部長や副本部長もプログラミングを(たまに)することで有名なサイボウズの運用本部長、山本泰宇です。 有名じゃないかもしれませんが、ブログに書いたので有名になるということでご了承ください。 今回は、先日発生した yrmcds に起因する障害の原因と対策を解説します。 yrmcds というのは、サイボウズが開発している memcached 互換のキーバリューストレージです。 問題の理解のため、まず TCP 通信で、通信先の相手の障害にどう対応するか解説します。 データの送信中に相手が落ちるケース このケースはさらに二つに分かれます。 相手の OS は生きているが、通信しているプログラムが落ちるケース 相手の OS ごと(あるいはネットワークごと)落ちるケース 1 と 2 の違いは、前者の場合 RST パケットが返ってくるのに対して、後者ではなにも返ってこない点です。後者の場合、ack されない
論点書き出してみたけど多すぎて超絶カオス。 現状発生している実害 チェックサム比較の失敗(発端) 画質の劣化 exif等メタデータ削除による情報欠損 元ファイルよりサイズが増える 技術的詳細が非公開 「最適化」という単語の是非 オプトインとオプトアウト 送信者(コンテンツ提供者)の同意 自衛のために全HTTPS化することで、かえってトラフィック増える問題 HTTPS化による計算機コスト、ファイル改竄による不具合対応のリスクの負担 サービス内容の意図しない/再現が難しい劣化*1 受信者の財産権の侵害とも言える。 受信者(顧客)の同意 消費者保護観点からより深い内容周知の上での同意が必要では無いか オプトアウトが可能かどうか ISPとしてのサービスが土管であるべきか否か 例えば、可逆圧縮での再圧縮なら良かったのかどうか 携帯キャリアが提供しているのは「インターネット」サービスかどうか iモード
こんにちは。インフラ開発チームの深谷です。 Linux の conntrack モジュールがロードされたサーバーで、レイヤー4 (L4) ロードバランサを LVS-DR で構成したところ、 パケットフィルタが正常に働かず、通信はできるものの、一部のパケットは落ちるという挙動に悩まされました。 今回はこの問題について詳細に解析し、原因と対策がわかったのでご紹介いたします。 発生した問題 今回の問題は、Ubuntu を使って L4 ロードバランサを実装している時に遭遇しました。 構築したロードバランサには、セキュリティ対策のため iptables のラッパーである UFW を使って、 パケットフィルタをかけていました。 ロードバランサの実装には、Linux カーネルに実装されている LVS を使いました。 LVS ではいくつかのパケット転送方式をサポートしており、今回はパフォーマンスに優れる
現実的な値と根拠など Slow Start などの例に良く出てくる数字の論拠と、個々の単位がどこで決まってくるかを主に取り扱う。というメモ。苦手科目だ。_:(´ཀ`」 ∠): Max Segment Size (MSS) の決定 この MSS がウインドウサイズ(一度に転送するデータサイズ)の単位として扱われる。(後述) TCP コネクションが 3-way handshake によって確立される際、ノード間で下記のような MSS に関するやり取りが発生する。 各ノードは Maximum Transmission Unit (MTU) から TCPヘッダ20バイト、IPヘッダ20バイトの計40バイトを引いた値を MSS として提示する 各ノードの希望 MSS のうち低い方を、そのコネクションにおける MSS とする たとえばイーサネットでは最大1,500バイト(オクテット)がIP通信に利用で
2022-03-02 dti_comment 2022-02-28 comment 2022-02-18 FrontPage 2021-11-26 biglobe_comment 2021-10-29 interlink_comment 2021-03-26 BBexcite_comment 2021-01-31 nifty_comment 2020-12-19 インターリンク - interlink 帯域規制 2020-12-08 freebit_comment 2020-05-13 AutoTicketLinkName 加筆・修正した情報には根拠となる情報源を提示して下さい。 昨今、東西フレッツ環境(IPv4 PPPoE)において輻輳(速度低下)が多数報告されています。制約は生じますが混雑箇所のNTT設備を経由しないIPv6(IPoE)接続の利用もご検討ください。 P2P規制は有料VP
(1) (2) (3) ご存じのとおり、VDI や BCP/DR はネットワークの帯域・回線品質に大きく左右されるソリューション。 本社オフィスであればリッチな専用線を契約しているかもしれませんが、拠点オフィスなどではフレッツ系などを利用しているケースも多々あります。 WAN 回線が潤沢でない場合も支障が無い設計を行うために「回線シミュレータ」や「帯域制御装置」を使って事前検証しておきたいところです。 しかし、帯域制限ならまだしも遅延まで作れるような装置は意外と高価。。。 検証のためだけに購入するのは難しいところです。"ぶっつけ本番" で導入してしまうケースもありますが、遊休サーバーや仮想マシンを使ってソフトウェアベースの帯域制御装置を作ってみましょう。昨今流行りの "Software-Defined" です。 Linux の「tc qdisc」で回線シミュレーション Linux にある程
はじめに オンプレとAWSにまたがるシステムの場合、オンプレ側の帯域を圧迫しないようサーバからの通信に帯域制限をかけたい場合があります。 今回はLinuxの機能を利用しアウトバウンド通信の帯域を制限してみました。 Windows Serverの帯域制限についてはこちらをご覧ください。 帯域制限が無い状態 制限が無い状態でのアウトバウンド速度を計測してみましょう。 5GBのファイルをS3にアップロードしてみます。 [ec2-user@ip-10-0-0-37 ~]$ mkdir files [ec2-user@ip-10-0-0-37 ~]$ dd if=/dev/zero of=files/5GB count=5120 bs=1M > /dev/null [ec2-user@ip-10-0-0-37 ~]$ aws s3 sync files s3://qos.test --region=
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く