Golang is evil on shitty networks
This adventure starts with git-lfs. It was a normal day and I added a 500 MB binary asset to my server templates. When I went to push it, I found it interesting that git-lfs was uploading at 50KB per second. Being that I had a bit of free time that I’d much rather be spending on something else than waiting FOREVER to upload a file, I decided to head upstairs and plug into the ethernet. I watched i
GitHub - threadfly/ListenRain: Go network programming framework, supports multiplexing, synchronous and asynchronous IO mode, modular design, and provides flexible custom interfaces。The key is the transport layer, application layer protocol has nothing to
The parallelogram represents the interface. It can be seen from the figure that the interface is fully reused on both the server and the client. A brief introduction to the functions of the next few interfaces: EncodePacket/DecodePacket: Responsible for solving the sticky packet problem of data receiving and sending. Through this interface, memory can be reclaimed when sending and receiving data,
TCPパケットを解析して構造化ログでダンプするツール tcpdp を作った - Copy/Cut/Paste/Hatena
やっと形になってきました。 github.com 「データベースのクエリログを取得したい」 例えば、データベース（RDBMS）のクエリログを取得したいとき一番確実な方法は、そのRDBMSに備わっているログ機構を利用することです。 一方で、全てのクエリログを出力するとなるとそれなりにIO負荷がかかることが予想されるので、負荷状況によってはクエリログ出力（のIO負荷）を別サーバに分離したくなります。 では、どうすればよいかというと、例えば アプリケーションサーバとデータベースサーバの間にプロキシサーバを挟んでそこで記録することでIO負荷を分離する アプリケーションサーバ側で（notアプリケーションで）記録することで（大抵、サーバ台数の多い）アプリケーション側にIO負荷を分散する というような方法を思いつきます。 そこで、「もし、TCPコネクション上に流れている（例えば）クエリログを解析してログ
Go言語でTCPやソケット通信を多重化，高速化するsmux(ソケットマルチプレクサ)をつくった · THINKING MEGANE
サーバ間で分散処理を行う際の相互通信におけるボトルネックを解消するため，smux(Socket multiplexer)を開発している． サーバ間の相互通信におけるボトルネックとその解決策 一対のサーバ間で多数のリクエストとレスポンスが送受信され，信頼性の高い通信としてTCPを利用する場合，コネクション確立のオーバーヘッドを排除するために接続の再利用が行われる．しかしながら，クライアントは送信に対する受信を待つ必要があるため，レスポンスまでに幾許かの処理時間を要する状況では送信のキューがたまってしまう．そこで複数の接続を利用することでこれを解消する方法が取られるが，追加の接続はリソース使用に関するオーバーヘッドを発生させてしまう．なにより各接続におけるレスポンス待ち時間は依然として解決しておらず，接続の利用面から見て非効率である．そこで，単一の接続において，仮想的に並行送受信を行う方法が提
Big Sky :: IP アドレスからレンジを引いて CIDR 形式で表示するツールを作った。
仕事でサーバを運用していると某国からのアタックがそこそこ多いのだけど、出来れば早急にブロックしてしまいたかったので IP アドレスから whois を引いて CIDR 形式で表示出来るツールを作った。昔はこういうの Perl で書いた気がする。 GitHub - mattn/iputil https://github.com/mattn/iputil ライブラリとして作ったけど、コマンドも用意してあります。 $ go get github.com/mattn/iputil/cmd/iprange 実行結果のイメージはこんな感じ。 $ iprange [IPアドレス] XXX.XXX.XXX.XXX/16 YYY.YY.YYY.YY/16 ... あとはこの結果を使って ufw (Universal FireWall) を使っているのであれば $ iprange [ヤバいIPアドレス] |
golang版Exping「pexpo」を書きました。 - Qiita
https://github.com/nnao45/pexpo どういうツールなのか。 題名にもあるような、Exping的なものをgolangでterminal上で動くアプリに描き下ろしたものです。 とても軽く、IPv6も対応しており、pingのintervalも500msまでならしっかりと打てます。 windows,Mac,Linux等プラットフォームを選ばず動きますし、色も変な色になりません。 なぜ作ったのか。 筆者は普段ネットワークエンジニアをやっており、 Expingを愛用しているのですが、 他のPING監視ツールも含めもっとこうだったらな、なポイントがいくつかありました。 Expingは実装上、ping-listのホストの全部を事前にメモリ予約してping発射するので監視ホストを多くしすぎると(例えば100台)重い、というかそもそもメモリ不足で動かない。 Expingやその他のツ
GitHub - traefik/traefik: The Cloud Native Application Proxy
Traefik (pronounced traffic) is a modern HTTP reverse proxy and load balancer that makes deploying microservices easy. Traefik integrates with your existing infrastructure components (Docker, Swarm mode, Kubernetes, Consul, Etcd, Rancher v2, Amazon ECS, ...) and configures itself automatically and dynamically. Pointing Traefik at your orchestrator should be the only configuration step you need. .
Zebra開発者の石黒氏、Go言語で全面的に書き換えた「Zebra 2.0」を開発中
2016年10月21日に開催されたネットワーク関連のイベント「ONIC Japan 2016」で、HASH-SET 代表取締役の石黒邦宏氏（写真1）は新しいルーティングソフトウエア「Zebra 2.0」を開発中であることを明らかにした。同氏が開発した「GNU Zebra」およびその派生ソフトウエアである「Quagga」は、オープンソースのルーティングソフトウエアとして広く使われている。Zebra 2.0は、米グーグルが開発したプログラミング言語「Go」を採用し、マルチスレッドに対応したのが特徴。2017年には公開したいとする。 同氏がZebraの開発を始めたのは1996年。当時のネットワークソフトウエアはモノリシックな（＝一体型の）構造を持つものが多かった。それに対し、Zebraはマルチプロセスで、各プロトコルを処理するモジュールを独立したプロセスとして実装するという、当時としては先進的な
NAT をやめて、透過 SOCKS プロキシを導入した - Cybozu Inside Out | サイボウズエンジニアのブログ
以下の記事内容について、奥一穂氏（@kazuho）より、「connectのエラーコードが信頼できなくなるといった欠点もあるのに透過 SOCKS プロキシが汎用的に良いように読めてしまう」というご指摘をいただきました。確かに、下記内容は当社が抱えていた複数の課題を短期間で解消できる「ワークアラウンド」として透過 SOCKS プロキシという技法もあることを紹介したものであり、NAT と比較して常に良いという主張をしたかったわけではありません。また、記事内では解説を省きましたが、従来より HTTP(S) 通信は NAT ではなく HTTP プロキシを利用しています。謹んで補足・訂正とさせていただきます。 猫が好きだけど猫アレルギーで近寄ることができない山本泰宇です。 先日アーキテクチャ刷新プロジェクト「Neco」を紹介しましたが、今回はその活動の一環として実施したネットワークアドレス変換(NAT
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - opencoff/go-tunnel: TLS/SSL Tunnel - A modern STunnel replacement written in golang
GitHub - jsimonetti/rtnetlink: Package rtnetlink provides low-level access to the Linux rtnetlink API. MIT Licensed.
google/netstack: IPv4 and IPv6 userland network stack
Golangで作るFTPプロキシサーバ
GitHub - coreswitch/zebra: routing protocol daemon
GitHub - nnao45/pexpo: :computer: Terminal sending ping tool written in Go.
GitHub - aregm/nff-go: NFF-Go -Network Function Framework for GO (former YANFF)