How TCP backlog works in Linux
When an application puts a socket into LISTEN state using the listen syscall, it needs to specify a backlog for that socket. The backlog is usually described as the limit for the queue of incoming connections. Because of the 3-way handshake used by TCP, an incoming connection goes through an intermediate state SYN RECEIVED before it reaches the ESTABLISHED state and can be returned by the accept s
Goでプライベートネットワークへのアクセスを制限する - 詩と創作・思索のひろば
Go において、いわゆる SSRF (Server Side Request Forgery) を防ぐような目的で、内部 IP アドレスにアクセスしない HTTP クライアントを作るには hakobe/paranoidhttp が便利だった。ただ、近年ではこれが作られて以降の Go 側のアップデートとして、net.Dialer.Control の登場がある（Go 1.11 より）。 type Dialer struct { ... // If Control is not nil, it is called after creating the network // connection but before actually dialing. // // Network and address parameters passed to Control method are not //
ネットワークフロー問題たちの関係を俯瞰する - 私と理論
ネットワークフロー好き好きマンとして，フローを布教したくなったので記事を書きました． ただし，フローの解説資料は既に素晴らしいものがたくさんあるので，今回は今まであまり焦点が当てられてこなかった部分を推して話をしたいと思います． テーマは，数あるフローの問題の関係を整理することです． フローの問題たちには共通の歴史があり，共通の定式化があり，共通のアルゴリズムの思想があります． その「共通」の部分を理解することで，フローに対する理解が深まり，より面白いと感じられると僕は思っていて，そこについて書きます． かなり基本的な内容しか書いてないので，強い人が得るものはあまりないかもしれません． あとこの記事はおきもちを書いてる部分が多いです． また，この記事では問題の話だけをしてアルゴリズムの詳細の話をほとんどしません．この辺りは 保坂さんのスライド などが非常に分かりやすいので，そちらを参照して
ネットワーク越しリトライ考 - その手の平は尻もつかめるさ
ここ最近では何らかのインターネットサービスを構築・運用するにあたって、ネットワーク越しのリトライを考えることは避けられなくなりつつあります。 micro services のようなアーキテクチャを採用している場合はサービス間のメッセージのやり取りはまず失敗する前提 (つまりリトライをする前提) で組む必要がありますし、たくさんのクライアントがいてそのクライアントが定期的に何かを処理してセントラルにデータを送ってくる IoT のようなシステムを構築する時もその処理のリトライをよく考える必要があります。 というわけで「ネットワーク越しのリトライ」についてここ最近考えていることをざっくりと書き留めるものであります。 前提 リトライをする側をクライアント、リトライを試みられる側をサーバと呼称します リトライにおいて、サーバおよびネットワークはクライアントよりも弱者です クライアントはリトライをコン
Low-Level Academy
In this course, you will learn how to work with the UDP and TCP internet protocols in real-world scenarios. You will apply your skills to build small, fun networking applications in Rust — right in your browser! No previous knowledge of network programming is required, but we assume that you are familiar with Rust syntax. If you’re not, that's fine too! You can read The Rust Book and learn by prac
The state of QUIC and HTTP/3 2020 | Fastly
QUIC — a latency-reducing, reliable, and secure transport protocol — and HTTP/3 — a mapping of HTTP semantics on top of QUIC — are co-evolving protocols that are being developed and deployed in tandem. This regularly updated blog post will elaborate on the current state of the protocols, their deployment across the web, and our expectations for the technologies in the near future. TL;DR, Summer 20
Wireshark によるパケット解析講座 1: Wiresharkの表示列をカスタマイズする
This post is also available in: English (英語) 概要 Wireshark は無料で利用できるプロトコル アナライザです｡ Wireshark を使うと、ネットワーク トラフィックをキャプチャーしたり､キャプチャーしたパケットを表示させることができます｡ITの専門職についているかたがたは､このツールを使って日々ネットワークのさまざまな問題を解決しています｡セキュリティの専門家も、この Wireshark を使ってマルウェアが生成するトラフィックを確認しています。 そこで、今回は Wireshark の便利な機能のひとつである表示列のカスタマイズをご紹介したいと思います｡Wireshark はデフォルトでは､非常にたくさんの情報を列表示してくれますが､これをカスタマイズすることで皆さん自身の用途に使いやすいようにできます｡ 本稿は Wireshark
Python: ソケットプログラミングのアーキテクチャパターン - CUBE SUGAR CONTAINER
今回はソケットプログラミングについて。 ソケットというのは Unix 系のシステムでネットワークを扱うとしたら、ほぼ必ずといっていいほど使われているもの。 ホスト間の通信やホスト内での IPC など、ネットワークを抽象化したインターフェースになっている。 そんな幅広く使われているソケットだけど、取り扱うときには色々なアーキテクチャパターンが考えられる。 また、比較的低レイヤーな部分なので、効率的に扱うためにはシステムコールなどの、割りと OS レベルに近い知識も必要になってくる。 ここらへんの話は、体系的に語られているドキュメントが少ないし、あっても鈍器のような本だったりする。 そこで、今回はそれらについてざっくりと見ていくことにした。 尚、今回はプログラミング言語として Python を使うけど、何もこれは特定の言語に限った話ではない。 どんな言語を使うにしても、あるいは表面上は抽象化さ
続・リトライと冪等性のデザインパターン - リトライはいつ成功するか - Blog by Sadayuki Furuhashi
三度の飯よりエラー処理。古橋です。 大変好評をいただいた序章リトライと冪等性のデザインパターンの続編です。 前回はほぼ前置きでしたが、今回は冪等でない操作を冪等にする具体的なテクニックもまとめていきます。 パターン２：エラーを区別してDELETEを冪等にする リソースに常に一意なIDが振られていれば、Deleteを冪等にするのは難しくない。そもそも同じリソースを2度削除することはできない。 一つ注意するべきなのは、削除されたリソースのIDが再利用されるケースでは、Deleteの冪等性は保証されない。例えば、kill -KILL <pid> コマンドはDelete系のAPIと考えられるが、pidは再利用されるので、何度も繰り返すと意図しないプロセスを殺してしまう可能性がある。 一般にIDの生成は非常に難しい問題だが、Deleteに関してのみ言えば再利用されなければいいので、単調増加する整数（
1台のPCでできるOpenFlow開発環境
今回は、実際にTremaの環境を導入し、リピータハブとして動作する簡単なOpenFlowコントローラを作成する方法を紹介します。 前回「SDNの基本動作とアジャイルな開発が可能なSDN実装、『Trema』」ではSDN/OpenFlowの概要と、OpenFlowのプログラミングフレームワーク「Trema」の特徴を中心に紹介しました。今回は、実際にTremaを利用し、簡単なOpenFlowコントローラを作成する方法を紹介します。 1台のPCでできるOpenFlow開発環境 これから「アジャイルなOpenFlowプログラミングフレームワーク環境」を、種も仕掛けもないPC1台だけで本当に開発してみます。 まず初めに、PCを1台用意してください。もちろん、普段利用しているPCでも構いません。Tremaを動作させるOSはLinuxですが、用意できるPCがWindowsマシンならば仮想PC環境（VMwa
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
