タグ

ブックマーク / eng-blog.iij.ad.jp (28)

  • システムコールを速く漏れなくフックする方法 | IIJ Engineers Blog

    ptrace、Syscall User Dispatch:カーネルが提供している ptrace や Syscall User Dispatch のような機能は、ユーザ空間でシステムコールのフックを実装するために利用できます。ですが、これらを利用すると、元のユーザ空間プログラム内部でのシステムコール呼び出しのコストが大きくなり、結果として、性能が大きく劣化してしまいます。(要件1を満たせない) eBPF :eBPF のようなカーネル内の関数へフックを適用できる仕組みもありますが、eBPF は XDP のような場合を除くと、基的にカーネルの挙動を変更するためには利用できないため、カーネル機能をユーザ空間でエミュレートする、といった用途には適していません。(要件5を満たせない) ライブラリ関数の置き換え:標準ライブラリ(libc 等)は、沢山のシステムコールのラッパーライブラリ関数を実装してお

    システムコールを速く漏れなくフックする方法 | IIJ Engineers Blog
    ryshinoz
    ryshinoz 2021/12/22
  • mrubyを通じてWebAssemblyの未来を想う~新しいウェブサービスの開発課程にて | IIJ Engineers Blog

    Haskellユーザーグループ(愛称 Haskell-jp)発起人の一人にして、Haskell-jpで一番のおしゃべり。 HaskellとWebAssemblyプリキュアとポムポムプリンをこよなく愛する。 こんにちは。ブラウザ外のWebAssemblyに関心が偏りすぎて、ブラウザにおけるWebAssemblyについて聞かれると戸惑うことが多い山悠滋です。普段はIIJ-IIの技術開発室という部署で、IIJ体をサポートするための開発をいろいろ行ったり、WebAssemblyを応用した新しいウェブサービスの開発に取り組んでいます。 今回は、開発している「WebAssemblyを応用した新しいウェブサービス」のサンプルとして、mrubyのインタープリタをWASIに準拠したWebAssemblyファイルにコンパイルするまでの課程や、それを通じてわかった、今のWebAssemblyに足りない

    mrubyを通じてWebAssemblyの未来を想う~新しいウェブサービスの開発課程にて | IIJ Engineers Blog
    ryshinoz
    ryshinoz 2021/10/12
  • QUICをゆっくり解説(1):QUICが標準化されました | IIJ Engineers Blog

    Haskellコミュニティでは、ネットワーク関連を担当。 4児の父であり、家庭では子供たちと、ジョギング、サッカー、スキー、釣り、クワガタ採集をして過ごす。 不定期連載を始めます IIJ-II 技術研究所 技術開発室の山です。私はプログラミング言語HaskellでHTTP/2とTLS 1.3を実装した後、もっぱらQUICを実装することに時間を費やしてきました。 ご存知の方もいらっしゃると思いますが、今年の5月にQUICの仕様がRFC9000として公開されました。このRFCは実によく書かれているので、読みこなせばQUICの全容が掴めるでしょう。 しかし仕様は膨大ですし、実際に実装してみて初めて腑に落ちることもあります。そこでこの機会に、実際にQUICを実装した経験者目線で、QUICの解説をしていきたいと思います。なんとなくTCP/IPを分かっている方が、ある程度QUICの理解ができることを

    QUICをゆっくり解説(1):QUICが標準化されました | IIJ Engineers Blog
    ryshinoz
    ryshinoz 2021/07/02
  • 分散SNSを使って技術を覚える | IIJ Engineers Blog

    Twitterフォロー&条件付きツイートで「バリーくんぬいぐるみ」を抽選で20名にプレゼント! 応募期間は2019/11/29~2019/12/31まで。詳細はこちらをご覧ください。 今すぐツイートするならこちら→ フォローもお忘れなく! 【IIJ 2019 TECHアドベントカレンダー 12/12(木)の記事です】 久しぶりに書きました。 どうもこんばんわ。九州支社で働くとみです。お久しぶりです。 実は2016年に一つ記事を投稿したのですが、実に3年半経過した今になってアドベントカレンダーの話が聞こえてきたので、久方ぶりに書いてみることにしました。 当時はこんな記事なんかを書いてたわけですが、この記事を書いてから3年間色々あったので、その中の一つを書いてみようかなと思います。 3年間で覚えたことを並べてみる 2016年当時はTHE ON-PREMISEと言われてもおかしくないような、どイ

    分散SNSを使って技術を覚える | IIJ Engineers Blog
    ryshinoz
    ryshinoz 2019/12/12
  • DNS over TLS/HTTPSについて考える | IIJ Engineers Blog

    はじめに 昨年から DNS over TLS (DoT)、DNS over HTTPS (DoH) にまつわる動きが急速に活発になっています。 DoT は2016年に RFC7858 が出てしばらくは大きな動きはありませんでしたが、2017年11月にサービス開始した public DNS である Quad9 (9.9.9.9)、昨年4月開始の Cloudflare (1.1.1.1)が相次いで DoT に正式対応し、遅れて今年1月には Google Public DNS (8.8.8.8) も対応しました。クライアント側としては昨年8月リリースの Android 9 “Pie” が DoT に対応しています。 DoH は仕様の標準化より実装の方が先行しています。Cloudflare は DoT だけでなく DoH も昨年4月のサービス開始当初からサポートしています。Mozilla Fire

    DNS over TLS/HTTPSについて考える | IIJ Engineers Blog
    ryshinoz
    ryshinoz 2019/05/09
  • TLS 1.3の標準化と実装 | IIJ Engineers Blog

    IIJ-II 技術研究所 技術開発室の山です。現在技術開発室は、私を含めた4人で構成されており、主にプログラミング言語Haskellを使って開発を進めています。今回の話題である TLS(Transport Layer Security) 1.3 もHaskellで実装しました。 4年の歳月をかけて議論されてきたTLS 1.3ですが、この8月にめでたく仕様がRFC 8446となりました。貢献者リストに私の名前が載っていることを聞きつけた広報から、ブログ記事の執筆依頼がありましたので、TLS 1.3の標準化や実装の話について書いてみます。 なぜTLS 1.3を標準化する必要があったのか理由を知りたい方は、「TLSの動向」という記事や「TLS 1.3」というスライドを読んで下さい。 インターネットで使われているプロトコルは、IETFという団体で仕様が議論されて策定されます。IETFには、誰でも

    TLS 1.3の標準化と実装 | IIJ Engineers Blog
    ryshinoz
    ryshinoz 2018/09/26
  • Let’s EncryptとACME | IIJ Engineers Blog

    社会人生活の半分をフリーランス、半分をIIJで過ごすエンジニア。元々はアプリケーション屋だったはずが、クラウドと出会ったばかりに半身をインフラ屋に売り渡す羽目に。現在はコンテナ技術に傾倒中だが語りだすと長いので割愛。タグをつけるならコンテナ、クラウド、ロードバイク、うどん。 2018年7月はWeb業界にとって記憶に残る日になるでしょう。httpsが標準となった日として。 これまでWebサイトへのアクセスにはhttpを利用するのが通常で、安全性が求められる場合にはhttpsを利用すると考えられてきましたが、これからはhttpsを使うのが当たり前になっていくでしょう。この流れを強力にけん引しているのは、保守的な我が国においてもトップシェアブラウザとなったChromeを擁するGoogleであることはご存知の通りです。これまではhttpでのアクセスには特に表記はなく、httpsでアクセスすると「保

    Let’s EncryptとACME | IIJ Engineers Blog
    ryshinoz
    ryshinoz 2018/07/26
  • Google Public DNS over HTTPS を試す | IIJ Engineers Blog

    【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 サーバ(フルレゾルバ)を提供し

    Google Public DNS over HTTPS を試す | IIJ Engineers Blog
    ryshinoz
    ryshinoz 2016/08/15