package main import ( "fmt" "log" "net" ) func main() { l, err := net.Listen("tcp", "127.0.0.1:0") if err != nil { log.Fatal(err) } fmt.Println(l.Addr()) }
![Goで適当に空いてるportをListenする - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/2de52308deae7fa5cfdff72874cac1c18308bab7/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9R28lRTMlODElQTclRTklODElQTklRTUlQkQlOTMlRTMlODElQUIlRTclQTklQkElRTMlODElODQlRTMlODElQTYlRTMlODIlOEJwb3J0JUUzJTgyJTkyTGlzdGVuJUUzJTgxJTk5JUUzJTgyJThCJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWNsaXA9ZWxsaXBzaXMmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz00NGU4ZGI4MGI4YzkyZDlmZmUzMGJkODM5NjZlNzlhMA%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwc2Z1aml3YXJhJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz03ODFkYzg0Y2U4MDUzOWQzM2VlMWNhOGRlNTM4OTJmNA%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D09decea4a168f8b109f7622a8a3e16fd)
昨年末からずっとこんなことをしてまして、この時期になってようやく今年初のブログ記事です。 進捗的なアレがアレでごめんなさい。そろそろ3年目に突入の @pandax381です。 RTT > 100ms との戦い 経緯はこのへんとか見ていただけるとわかりますが「日本と海外の間を結ぶ長距離ネットワーク(いわゆるLong Fat pipe Network)において、通信時間を削減するにはどうしたらいいか?」ということを、昨年末くらいからずっとアレコレやっていました。 送信したパケットが相手に到達するまでの時間(伝送遅延)を削減するのは、光ファイバーの効率の研究とかしないと物理的に無理なので、ここで言う通信時間とは「TCP通信」における一連の通信を完了するまでの時間です。 伝送遅延については、日本国内のホスト同士であれば、RTT(往復遅延時間)はだいたい10〜30ms程度ですが、日本・北米間だと10
tl;dr 書いていたら思わず長文の大作になってしまいましたので、プロトコルオタ以外の方は文章の多さに退屈されるかと思います。GoogleマップサービスでSPDYの問題が発覚し、GoogleがLinuxカーネルに修正を加えて対応したというお話です。将来 Linux + nginx + SPDY を使いリバースプロキシでサービス運用を検討されている方は参考になるかもしれません。 1. はじめに、 プロトコルに執着する年寄りエンジニアの老害が叫ばれて久しい。 年甲斐もなく自分好みのパケットを追っかけるおやじエンジニアの姿を見て眉をひそめる若者も多いと聞く。 そんな批判に目もくれず、今日も一つ、プロトコルオタのネタをブログで公開したいと思いますw 今回はちょうど1年ほど前に書いたブログ記事 「GmailがハマったSPDYの落とし穴」の続編です。といっても今度の舞台は、Googleマップ。ネタ元も
TCP Fast Open – Webを速くするためにGoogleがやっていること Make the Web Faster 4 – Jxck HTTPは、その下層にあたるトランスポートレイヤーのプロトコルとして、通常TCPを使用します。 したがって、TCPのレイヤで速度が改善することは、そのままWebの高速化につながる可能性があるといえます。 GoogleはWebを速くするための活動として、TCPのようなプロトコルレイヤの改善にも取り組んでいます。 今回はその中の一つ、TCP Fast Openを取り上げ、解説と動作検証、簡単なベンチマークを行います。 検証環境等は最下部に記載します. Make the Web Faster: TCP Fast Open 3 Way Handshake TCPは、「正確、確実にデータを届ける」ことを重視した設計になっています。 特に接続確立時には、双方の状
by liz west イーサネットや複数のモバイルルーターなどを接続して回線を束ね安定運用できる「Dispatch」というソフトがありますが、iOS 7はこのDispatchを使ったときと同じように、複数経路のTCPコネクションを張れる「MPTCP(マルチパスTCP)」に対応していることがわかりました。 Apple iOS 7 surprises as first with new multipath TCP connections - Network World http://www.networkworld.com/news/2013/091913-ios7-multipath-273995.html MPTCPというのは、インターネット技術の標準化を推進している団体IETFが近年作業を進めてきたTCPの改良プロトコルで、TCPコネクションを複数にすることで冗長性を高め性能を向上させ
TCPLock Background TCPLock grows out of a problem I had working at Attachments.me. We use OpenOffice's UNO web-service to convert between various document formats. Over time, OpenOffice leaks memory and locks up. A potential solution is to restart OpenOffice periodically. Here's the problem, at any given time many clients are connecting to OpenOffice for conversion. This makes restarting the servi
はじめてのnpm publish。 PerlでTest::TCPを愛用しているのですが、Node.jsでもこういうの欲しいと思っていて探してみたけどそれらしきものが見当たらなかったので作ってみました。 https://github.com/sugyan/node-test-tcp 「サーバのインスタンスとクライアントのコードを渡すと、空いているportでサーバを立ち上げてクライアントコードを実行してくれる」というもの。 こんなカンジで使うイメージです。 var assert = require('assert'); var net = require('net'); require('test-tcp').test_tcp({ server: net.createServer(function (socket) { socket.on('data', function (data) { s
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く