カンファレンスイベントで会場回線を過信してはいけない - notokenの覚書
前段 PHP Conference Japan 2023が 10/08 に大田区産業プラザPiOで行われたわけですが、開会直後に提供している無線LANがいきなり不安定になってしまい、そのまま一部の部屋以外で提供できない状態になってしまった。 この記事では、なぜそのようなことが発生してしまったか？という点に関して解説しようと思う。 結論 会場側設備として入っているNAPT-BOXが YAMAHA RTX1200 という 15年前*1に発売されたルータで、来場者を捌けるだけのNAPTセッションテーブル*2が備わっておらず、NAPTテーブル溢れ*3を起こしてしまった。 事前知識 NAPT Network Address Port Translation 1つのグローバルIPアドレスを複数のホストで共有するための仕組み。この機能により1つのグローバルIPアドレスを複数のクライアント(コンピュータや
TCPとQUICの比較
ジェフ・ヒューストンのブログより。 QUICトランスポート・プロトコル(RFC 9000)は、オリジナルのTCPトランスポート・プロトコルを改良したものに過ぎないという一般的な見解があります[1][2]。私は、この意見に同意し難く、私にとってQUICは、通信のプライバシー、セッション制御の完全性、柔軟性の面で、アプリケーションが利用できるトランスポート機能における重要な変化を象徴しています。QUICは、より多くの形式のアプリケーションの動作に本質的に役立つ、異なる通信モデルを体現しています。そうです。TCPよりも高速です。私の意見では、公衆インターネットは、いずれQUICがTCPに取って代わると思っています。ですから、私にとってQUICは、TCPに少し手を加えただけのものではありません。ここでは、TCPとQUICの両方について説明し、QUICがトランスポート・テーブルに加えた変更について見
HTTP and 5G (fixed1)
5GのNG-RANのOverallに関するTS、TS 38.300 V1.0.0をまとめた資料。 LTEのTS 36.300相当です。 まだ仕様未FIXでFFSのところも多いです。適宜バージョンアップしていきます。 不明点、最新の議論状況を反映できるところはできるだけ反映しました。 1 Scope 2 References 3 Abbreviations and Definitions 4 Overall Architecture and Functional Split 5 Physical Layer 6 Layer 2 7 RRC 8 NG Identities 9 Mobility and State Transitions 10 Scheduling 11 UE Power Saving 12 QoS 13 Security 14 Network Interfaces 15 Fu
詳解 Reliable UDP - Speaker Deck
謎の伝送制御プロトコルRUDPの詳細について解説します これは2018年11月10日に行われた Kernel/VM/探検隊@北陸 part 4 での発表資料です サンプルコード: https://github.com/Fadis/rudp
Head of Line Blocking - High Performance Web 2015 - Qiita
二つの 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 リクエストは以下のようになる。
Exponential backoff を実例で理解する - リサーチ・アンド・イノベーション 開発者ブログ
RNI dev の K.oshima です。 network mobility が好きです。 弊社のサービス Mycomment はユーザーのアクセス解析に Woopra と言うサービスを利用しています。 先日、Mycomment と Woopra のデータコレクター間の通信が失敗した結果、ログ監視にエラーが大量に上がってくる事象がありました。 失敗理由は特定データコレクターまでの経路消失です。 どうすればよかったかというと、一度目の通信失敗後にリトライして欲しかった。リトライすればハズレを引かずに成功する可能性があった。Woopra SDK がリトライしてくれればよかった話なのですが、実際にはリトライ機能がないため SDK を利用する利用者(rni-dev)が失敗したらリトライするように書く必要があります。 この待ってリトライするときに、一般によくある実装ではリトライが失敗するたびにリト
GoogleのQUICの論文が知見の塊だった - ASnoKaze blog
20181107追記 QUICプロトコルについての概要は別途記事を書きました asnokaze.hatenablog.com 概要 ACM SIGCOMM 2017という通信系の学会に、Googleの人 総勢21人によって書かれた「The QUIC Transport Protocol: Design and Internet-Scale Deployment」という論文が提出され、学会ホームページより閲覧出来る。 この論文は、QUICの設計仕様と実際にGoogleのサービスにデプロイした結果について書かれている。 すでにGoogler SearchやYoutubeでQUICは有効になっており、一日あたり数十億の接続を処理し、Googleのegress trafficのうち30%がQUICになっており、インターネットのトラフィックの内7%がQUICだと推定されるという説明から論文は始まる。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
