DNSを変更するとネットワークは速くなるか | IIJ Engineers Blog
はじめに あえてどことは言いませんが、先日某サイトで「ネット速度を高速化する方法」としてDNSサーバの設定をpublic DNSサービスに変更する記事が出てました。その記事の結論としては「変更しても大差ない」というものでしたが、DNSでネットワークを高速化するというこのような記事は何年も前からときどき見かけます。いい機会なので、このあたりについてもう少し深く掘り下げて考えてみましょう。 ※この記事では、とくに明示しなければDNSサーバとはキャッシュDNSサーバ(フルサービスリゾルバ)を指すものとします。 DNS応答の速さ DNSの設定を変えることによりネットワークの速度が速くなるとすれば、(1)DNSそれ自体の応答が速くなるか、(2)その後のWebアクセスが速くなるか、のどちらか(または両方でしょう)。このそれぞれについて検討してみましょう。 前者が速くなると画像やJavascriptなど
Linux カーネルをバイパスして TCP 通信を 10 倍速くする | IIJ Engineers Blog
【IIJ 2023 TECHアドベントカレンダー 12/16の記事です】 この記事について 背景：TCP はコンピュータネットワークの通信において広く利用されているプロトコル・標準化された通信規格です。コンピュータは TCP/IP スタックと呼ばれるようなソフトウェアを実行することで、定められた規格に則って通信を行います。汎用 OS 環境では、TCP/IP スタックは多くの場合、カーネル空間に OS 機能の一部として実装されています。 課題：通信に関するソフトウェアの研究コミュニティでは、そのようなカーネル空間に実装されている TCP/IP スタックは、近年の高速な NIC の性能を十分に引き出すことが難しいという課題が指摘されてきました。 テクニックの紹介：当記事では、近年の研究コミュニティにおいて比較的一般的な高速化テクニックとされている「カーネルをバイパス（迂回）して TCP 通信を
ChatGPTとプラグインを使ってIoTサービスのサンプルプログラムを作成する | IIJ Engineers Blog
ChatGPTに魅せられた30歳の新米エンジニア。Splatoonが好きで社内大会の運営をしています。元は営業でした。 IIJのIoTサービスをご利用の皆様、そして本記事に興味を持ってくださった皆様、こんにちは。 今回は、Gateway APIを活用してデバイスからのセンサーデータをIIJ IoTサービスに送信するプログラムをChatGPTに作成してもらう方法について解説します。 本記事に出てくる用語 Gateway APIとは？ Gateway APIは、デバイスからのセンサーデータを送信することで、IIJ IoTサービスが提供する多彩なプラットフォーム機能を利用するためのAPIです。 通信は、インターネットに出ない閉域網での接続、もしくはVPNプロトコルによる暗号化が行われているため、安全にデータを送信することができ、HTTP、FTP、TCP、UDP、MQTTといった多様なプロトコルを
QUICをゆっくり解説(19)：バージョン・ネゴシエーション | IIJ Engineers Blog
Haskellコミュニティでは、ネットワーク関連を担当。 4児の父であり、家庭では子供たちと、ジョギング、サッカー、スキー、釣り、クワガタ採集をして過ごす。 前回は「QUICバージョン2」について説明しました。アップグレードの例として、クライアントとサーバ共に、バージョン1もバージョン2もサポートしている場合を考えます。互換性の観点からクライアントは、バージョン1でコネクションを張ろうと試みるでしょう。サーバはハンドシェイクの際に、バージョン2をサポートしていることをクライアントへ伝える必要があります。今回は、このようなバージョンを交渉する仕組みについて説明します。 バージョン・ネゴシエーションの復習 忘れている方も多いとは思いますが、実はすでに「ネゴせよ」でバージョン・ネゴシエーションについて説明しています。バージョン・ネゴシエーションに使われるVersion Negotiationパケ
QUICをゆっくり解説(17)：QUICビットとトランスポート・パラメータ | IIJ Engineers Blog
Haskellコミュニティでは、ネットワーク関連を担当。 4児の父であり、家庭では子供たちと、ジョギング、サッカー、スキー、釣り、クワガタ採集をして過ごす。 お久しぶりです。一家の引っ越しでバタバタしておりました。ようやく落ち着いてきましたので、「硬直化」をテーマとしてQUICに関して3つほど記事を書いてみようと思います。 硬直化 硬直化とは、中間装置が想定外の動作をすることによって、新しい機能の普及が困難になることです。硬直化の例としては、TCP Fast Openが完全に普及できないことが挙げられます。 TCPでは、コネクションを確立するために、いわゆる3WAYハンドシェイクが実行されます。通常は、クライアントがSYNパケットを送信し、サーバがSYN/ACKパケットを返し、その後クライアントがACKを返す際に初めてデータを送信できます。 もし最初のSYNパケットにデータを乗せることがで
QUIC | IIJ Engineers Blog
IIJインフラから見たインターネットの傾向 〜2023年（IIR vol.61 1章） IIR vol.61 第1章では「IIJインフラから見たインターネットの傾向 〜2023年」をお届けします。 インターネットサービスを提供するIIJは、国内でも有数規模のネットワーク・サーバインフラを… IIJ Engineers Blog編集部 2023年12月25日 月曜日 QUICをゆっくり解説(19)：バージョン・ネゴシエーション 前回は「QUICバージョン2」について説明しました。アップグレードの例として、クライアントとサーバ共に、バージョン1もバージョン2もサポートしている場合を考えます。互換性の観点からクライアントは、バー… 山本 和彦 2022年07月21日 木曜日
QUICをゆっくり解説(16)：ヘッダ圧縮 | IIJ Engineers Blog
たとえば、メソッドの値がGETという擬似フィールドを表現するには、2というインデックスを指示すればよいわけです。フィールドの表現として存在するのは以下の3つです。 1つのインデックスでフィールド名とフィールド値の両方を指示する インデックスでフィールド名を指示し、フィールド値は文字列で指示する フィールド名とフィールド値の両方とも文字列で指示する 2)と3)の文字列の部分では、Huffman符号を使って圧縮するか否かを選べます。また、2)と3)には、それぞれ以下3つの版があります。 動的表に登録する 動的表に登録しない 動的表に登録しない。加えてセキュリティのため、中継装置で伸長後、再圧縮される場合も、常に文字列による指示を使用する制約を付ける 動的表には大きさの制限があり、エントリでいっぱいになると、古いエントリが削除されていきます。動的表にはデフォルトの大きさがありますが、復号側が S
QUICをゆっくり解説(15)：HTTP/3 | IIJ Engineers Blog
Haskellコミュニティでは、ネットワーク関連を担当。 4児の父であり、家庭では子供たちと、ジョギング、サッカー、スキー、釣り、クワガタ採集をして過ごす。 QUICは汎用的なトランスポート層プロトコルですので、様々なアプリケーションプロトコルのやりとりに使えます。みなさんがよく知っているHTTP/1.1を乗せることも可能です。実際、開発者の間では、HTTP/1.1の前身の前身であるHTTP/0.9がテスト用に使われていました。 しかし、QUIC上のHTTPの本命は、第一回目の記事で説明したようにHTTP/3です。QUICは、「HTTP/2のストリームによる多重化の機能」を取り込んでいます。QUICに取り込まれなかったHTTP/2の残りの部分をQUIC用に再定義したのがHTTP/3です。 今回は、HTTPの標準化状況とHTTP/3について説明します。 HTTPの標準化状況 現在よく使われて
QUICをゆっくり解説(11)：ヘッダの保護 | IIJ Engineers Blog
Haskellコミュニティでは、ネットワーク関連を担当。 4児の父であり、家庭では子供たちと、ジョギング、サッカー、スキー、釣り、クワガタ採集をして過ごす。 QUICと「TCP上のTLS 1.3」との決定的な違いに、トランスポート層に関連する情報が保護されているか否かが挙げられます。TLS 1.3では情報が格納されるTCPヘッダは保護できません。一方QUICでは、トランスポート層に関する情報の多くがペイロードに暗号化されて格納されます。またヘッダの一部のフィールドも保護されます。今回は、ヘッダの保護について解説します。 TCP Fast Openのジレンマ 「ハンドシェイク」の記事で説明したように、QUICと「TCP上のTLS 1.3」を比較すると、前者の方がハンドシェイクが1RTT分早く終わります(下図)。2回目以降のハンドシェイクで0-RTTを使う場合も、前者の方が1RTT分早く終わり
QUICをゆっくり解説(8)：フロー制御 | IIJ Engineers Blog
Haskellコミュニティでは、ネットワーク関連を担当。 4児の父であり、家庭では子供たちと、ジョギング、サッカー、スキー、釣り、クワガタ採集をして過ごす。 前回、QUICのストリームについて説明しました。今回は、ストリームのフロー制御についてお話しします。フロー制御はそれほど難しい機能ではないので、今回はほとんど用語整理のような内容になっております。 フロー制御と輻輳制御 ネットワーク通信の勉強をしていると、フロー制御と輻輳制御という用語を目にすることがあるかと思います。この2つは同一視されがちです。かくゆう僕も、長い間両者は同じ機能だと間違って理解していました。フロー制御と輻輳制御は、以下のように異なる仕組みです。 フロー制御：受信者の受信バッファが溢れないようにするための仕組みです。受信者が送信者に何らかの指示をし、送信者はその指示にしたがって送信するデータ量を調整します。 輻輳制御
QUICをゆっくり解説(7)：アプリケーションデータとストリーム | IIJ Engineers Blog
Haskellコミュニティでは、ネットワーク関連を担当。 4児の父であり、家庭では子供たちと、ジョギング、サッカー、スキー、釣り、クワガタ採集をして過ごす。 これまでの記事で、QUICのコネクションを確立する手順について説明しました。今回は、いよいよコネクションを使って、アプリケーションデータをやりとりします。 ストリーム ストリームとは、QUICコネクションの中で、順番を守って配送されるバイト列のことです。アプリケーションのデータが、ストリームとして運ばれます。たとえば、あるHTTPの要求とそれに対する応答は、QUICでは1つのストリームとして扱われます。 QUICコネクションの中では、複数のストリームが利用できます。ストリーム間ではタイミングを気にする必要はありません。HTTP/1.1のように応答が返ってきた後に次の要求を出すのではなく、複数の要求をあたかも同時に送り、それぞれの応答を
QUICをゆっくり解説(5)：2回目以降のハンドシェイクと0-RTT | IIJ Engineers Blog
Haskellコミュニティでは、ネットワーク関連を担当。 4児の父であり、家庭では子供たちと、ジョギング、サッカー、スキー、釣り、クワガタ採集をして過ごす。 前回はクライアントとサーバが初めてコネクションを確立する際に実行されるハンドシェイクについて説明しました。まだ、コネクションの切り方を説明してないので恐縮ですが、今回は1回目のコネクションが終了した後の2回目以降のハンドシェイクについてお話しします。 事前共有鍵 前回使ったQUICのハンドシェイク図を少し修正して以下に示します。 色の意味はこうでした。 薄い灰色：イニシャル鍵で暗号化されている 濃い灰色：ハンドシェイク鍵で暗号化されている 黒色：アプリケーションデータ鍵で暗号化されている イニシャル鍵は、クライアントが乱数的に作ったサーバのコネクションIDから生成されました。 ハンドシェイク鍵やアプリケーションデータ鍵は、鍵交換で共有
QUICをゆっくり解説(3)：QUICパケットの構造 | IIJ Engineers Blog
Haskellコミュニティでは、ネットワーク関連を担当。 4児の父であり、家庭では子供たちと、ジョギング、サッカー、スキー、釣り、クワガタ採集をして過ごす。 前回の説明では、「Initial パケット」や「Version Negotiation パケット」といった用語を未定義で使いました。今回は、こういった「パケット」や「フレーム」が、どのような構造を持っているかについて説明します。 古典的なパケット IP、UDP、およびTCPでデータをやり取りする基本単位は、すべて「ヘッダ＋ペイロード」という構造を持っています。このヘッダ＋ペイロードという単位は、それぞれ以下のように呼ぶのが慣習です。 IP – パケット UDP – データグラム TCP – セグメント すべてパケットと呼んでも間違いではありません。UDPの場合、IPペイロードが「UDPデータグラム(UDPヘッダ＋UDPペイロード)」に
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
