# 2021年/清明(後) TCPの短命接続の高速化、Obsidian、e34.fm、シンエヴァ
Created: April 12, 2021 3:06 PM
Research: transtracer
Tags: airpods, e34fm, evangelion, obsidian, tcp
Week: April 12, 2021 → April 18, 2021
# Research
## TCPの短命接続の高速化
connperfのTCPの短命接続モードで、ハードウェアリソースを使い切るまえに、ソフトリミットに到達してした問題を、TCP_NODELAY, TCP_QUICKACK, SO_LINGER, TCP_FAST_OPENを設定して、ある程度解決した。
[https://github.com/yuuki/connperf/pull/10](https://github.com/yuuki/connperf/pull/10)
- **TCP_NODELAY**: Nagle Algorithmを無効にする。少量のデータであっても即座に送信する。 [https://linux.die.net/man/7/tcp](https://linux.die.net/man/7/tcp)
- Go言語ではデフォルトで有効になっている。[https://golang.org/pkg/net/#TCPConn.SetNoDelay](https://golang.org/pkg/net/#TCPConn.SetNoDelay)
- **TCP_QUICK_ACK**: 通常のTCPの動作に従って、必要に応じて遅延させるのではなく、すぐにACKが送信される。
- 設定方法はnet.Conn -> TCPConn -> syscall.RawConn -> rawconn.Controlでfdを手に入れてからsetsockoptする [https://kechako.dev/posts/2018/12/03/create-udp-conn-each-client/](https://kechako.dev/posts/2018/12/03/create-udp-conn-each-client/)
- 実験の環境ではあまり効果がなかった。
- **SO_LINGER**: close(2)後に即座にtimeoutさせる [https://man7.org/linux/man-pages/man7/socket.7.html](https://man7.org/linux/man-pages/man7/socket.7.html)
Go言語でSO_LINGERを設定する方法 [https://golang.org/pkg/net/#TCPConn.SetLinger](https://golang.org/pkg/net/#TCPConn.SetLinger)
[https://github.com/yuuki/connperf/pull/10/commits/c531614832c00ab74c2c2fff8247ce31d04493ef](https://github.com/yuuki/connperf/pull/10/commits/c531614832c00ab74c2c2fff8247ce31d04493ef)
- 実験では少し効果があった。
- **TCP_FAST_OPEN**: 一度コネクションを貼った相手とは、TCPの3ウェイハンドシェイク中にデータを送受信できるようになる。クライアントからSYNとともにデータを送信することで、実際にデータを送受信開始するまでの待ち時間が短縮できる。 [https://asnokaze.hatenablog.com/entry/2017/05/09/223534](https://asnokaze.hatenablog.com/entry/2017/05/09/223534)
- clientとserverで設定するために `echo 3 > /proc/sys/net/ipv4/tcp_fastopen` を設定。 [https://github.com/bradleyfalzon/tcp-fast-open](https://github.com/bradleyfalzon/tcp-fast-open)
- connectを実行せず、いきなりsocketでソケットを作成して、いきなりsendtoのオプションに設定する。`syscall.Sendto(c.fd, data, syscall.MSG_FASTOPEN, sa)`
- [https://github.com/bradleyfalzon/tcp-fast-open/blob/master/client.go#L39](https://github.com/bradleyfalzon/tcp-fast-open/blob/master/client.go#L39)[https://christina04.hatenablog.com/entry/go-so-reuseport](https://christina04.hatenablog.com/entry/go-so-reuseport) の記事にListenConfigでsocket optionを設定できそう。
[net: add support for TCP Fast Open](https://github.com/golang/go/issues/4842) 経由で [https://github.com/shadowsocks/go-shadowsocks2/pull/162](https://github.com/shadowsocks/go-shadowsocks2/pull/162) にGoでTCP_FASTOPENを設定するコードがあった。
- 実験では、これも効果があった。
- SO_LINGERとTCP_FASTOPENにより、15k conns/sでソフトリミットにあたっていたのが、20k conns/sまでスケールするようになった。
- 今ならコードを変更しなくても、eBPFでできるかも。BPF_PROG_TYPE_CGROUP_SOCKあたりでできないか。
## 研究室で発表
所属研究室の研究会で、最近進めているジャーナル向けの研究をまとめて発表した。翌日にたまたま研究室を訪れて、先生と話をしたときに、昨日の話はおもしろかったですと仰っていただいてうれしかった。カーネルとユーザのコピーコストが問題なら、ユーザ側で動的リンクされたライブラリからフローをとる方法はどうかという話をいただいて、たしかにそれは考えていなかったなと気づいた。クラウドで広く利用されているGo言語が直接システムコールをたたくので、この手法は使えないのだが、これも比較しておこう。
![[2021%E5%B9%B4 %E6%B8%85%E6%98%8E(%E5%BE%8C) TCP%E3%81%AE%E7%9F%AD%E5%91%BD%E6%8E%A5%E7%B6%9A%E3%81%AE%E9%AB%98%E9%80%9F%E5%8C%96%E3%80%81Obsidian%E3%80%81e34 fm%E3%80%81%E3%82%B7%E3%83%B3%E3%82%A8%E3%82%A6%E3%82%99%E3%82%A1/Untitled.png]]%20TCP%E3%81%AE%E7%9F%AD%E5%91%BD%E6%8E%A5%E7%B6%9A%E3%81%AE%E9%AB%98%E9%80%9F%E5%8C%96%E3%80%81Obsidian%E3%80%81e34%20fm%E3%80%81%E3%82%B7%E3%83%B3%E3%82%A8%E3%82%A6%E3%82%99%E3%82%A1%2019197477b9fe4b87b279ff9d20fd4138/Untitled.png)
## Obsidianを導入した
先週、TaskpaperとPlan、Totを導入した話を書いた。意外とさっとメモするケースがなくてTotはまだそんなに使っていない。PlanとTaskpaperは、常に使用している。
TaskpaperにTo-Doと調査メモを書いているのだけど、調査メモやプログラムの実行結果を貼っていくとTo-Doが視認しづらくなっていく問題があった。細かいTo-DoをカレンダーベースのPlanで管理するのはやはり難しいので、複雑なTo-Do管理はテキストベースのTaskpaperがよい。
[[]]/)を使い始めた。ObsidianはNotionやEvernoteのようなSaaS型のノートアプリと違って、ローカルにMarkdownファイルが配置されるだけ。Dropboxでバックアップや共有もできる。画像もローカルに配置され、貼り付けた画像をプレビュー表示でみれる。PDFもプレビュー表示でみれるのもよい。まだデータが少ないので評価は慎重になったほうがいいけど、ローカル型で通信しないので、Obsidianは動作がとにかく快適だ。
Roam Researchと一緒で、Today's memoをショートカットで毎日つくって、そこにタイムラインでメモを書いていく。ある程度まとまった話はinboxファイルにまとめていく。テキストにどの箇所にもタグをつけて、タグを書いた前後のテキストを一覧したりもできる。
ObsidianでTo-Do管理はできないもないけど、余計なものがみえないTaskpaperを今は使っている。
今度はNotionとの使い分けに悩んできた。
## e34fm
[2: eBPF with yuuki](https://e34.fm/2/)
e34.fmのep2のゲストによんでもらった。eBPFとはなにか、なぜeBPFなのか、eBPFのユースケース、アーキテクチャ、フレームワークやライブラリ、eBPFの未来について話した。実際にコード書いてみてどうかという話は時間がなくてできなかったけど、Tracingに関するeBPFの話をだいたいまとめられたんじゃないかと思う。
Twitterで何件かよいコメントをもらっていた。
[https://twitter.com/YutaroHayakawa/status/1382621120851943429](https://twitter.com/YutaroHayakawa/status/1382621120851943429)
[https://twitter.com/mapk0y/status/1382213523237851142](https://twitter.com/mapk0y/status/1382213523237851142)
## BPF Performance Tools輪読会
- profileコマンドはほとんどのCPUパスをトレースするので、外観を掴むのによさそうだった。
## Concurrency in Go輪読会
さくら社内で輪読会がはじまったので参加していた。序盤は、なぜ並行処理なのか、なぜ並行処理が難しいのかという話から始まった。
# Clips
## AirPods Pro ⇒ Macを強制切り替え
[AirPodsをMacに強制的に接続する - 宇宙行きたい](https://yoshiori.hatenablog.com/entry/2021/04/13/171405)
と同じことをやった :thanks:。 Cmd+Shift+lで切り替わるようになった。いつもちまちまと、GUIで切り替えてたので捗る。手元環境にあわせて少し手直ししてある。
```bash
#!/bin/bash
AIR_PODS_ADDRESS="38-ec-0d-c3-1c-67" # Your AirPods MAC address
AIR_PODS_NAME="Yuuki’s AirPods Pro" # Your AirPods name
BREW_BIN=$(/Users/y-tsubouchi/homebrew/bin/brew --prefix)/bin
${BREW_BIN}/bluetoothconnector -c $AIR_PODS_ADDRESS
for ((i=0 ; i<10 ; i++))
do
if [ "Connected" == $(${BREW_BIN}/bluetoothconnector -s $AIR_PODS_ADDRESS) ]; then
sleep 1
${BREW_BIN}/SwitchAudioSource -s "${AIR_PODS_NAME}"
sleep 1
say -v samantha Connected
break
fi
sleep 1
done
```
## 臨床研究分野のエビデンスのレベル
国立の医療研究センターがちゃんとエビデンスのレベルを定めてるのすごい。情報系の分野にはあまりない気がする。
[https://twitter.com/raurublock/status/1382114937149952001](https://twitter.com/raurublock/status/1382114937149952001)
## ノーフリーランチ定理
[The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software](http://www.gotw.ca/publications/concurrency-ddj.htm)
## 物理学に美しさは必要か
[物理学に美しさは必要か？ という根本的な問題提起──『数学に魅せられて、科学を見失う――物理学と「美しさ」の罠』 - 基本読書](https://huyukiitoichi.hatenadiary.jp/entry/2021/04/18/080000)
いつも購読している「基本読書」ブログの、「数学に魅せられて、科学を見失う――物理学と「美しさ」の罠」という書籍についてのレビュー。
> 問いかけられていく話題は、多岐にわたる。たとえば、現代の物理学がいかに美意識に頼って研究を推進しているのか。物理学における美しさとは何なのか。それを使って仮説を求めるのは、客観的であるべしとする科学者の義務に反しているのではないか。美しさに変わって理論を評価する基準をどう考えればいいのか。高エネルギー物理学の研究の世界についてなどなど。特に、現代物理学が主観的な「美しさ」「自然さ」を基準に、検証もできない恰好がいいだけの理論──多宇宙論や未知の素粒子の提唱などを乱造してきたことについて、かなり批判的な論調で展開している。
科学的アプローチをとっているものとしては興味深い話になっている。客観性を重視する科学であっても、どこかしかに主観は入りこんでくるものであると考えているので、理論物理学では主観をどのように扱っているかを知れるのはおもしろそう。
## データベースリライアビリティエンジニアリング
[データベースリライアビリティエンジニアリング ―回復力のあるデータベースシステムの設計と運用](https://www.amazon.co.jp/dp/4873119405)
まだ買ったばかりで、さっと下読みした程度ではある。
訳者あとがき冒頭にACミランのパオロ・マルディーニの名言「サッカーに古いも新しいもない。あるのは、良いサッカーと悪いサッカーだけだ。」が書かれていた。10代のころにみて以来、ひさびさにこの言葉を思い出した。たしかに情報技術の世界でも、ポップカルチャーのように新しいものがよいとされがちだけど、新しいかろうが古かろうが、優劣で論じるべきであると思う。
翻訳文はよみやすくてすばらしい。原著は2017年の出版であるため、コンテナについての言及の仕方など、すこし内容が古いところもある。SREを知っていて、データベースのある程度の運用経験があると、それほど目新しい内容は今の所みあたらない。
「1.3 欲求段階説」にマズローの欲求段階の話をデータベースに置き換える話があるのだけど、この2つを置き換えることは妥当なのかが、特に理由が書かれていなかったので、よくわからなかった。データベースにおける承認欲求が「観測可能なこと、デバッグ可能なこと、内部で起こっていることが把握可能なこと、そ してツールによる分析が可能なこと」に対応すると書かれているのも、なぜそう言えるのかがよくわからなかった。
データベースリライアビリティに対する定義も与えていないようにみえたり、全体的に著者らの主観で語られているのではないかと訝しむ記述が散見される。
というわけで、この本に対する期待値がちょっと下がってきてしまった。
# Life
## シン・エヴァンゲリオン劇場版:||
エヴァをはじめて観たのは、たぶん5,6歳のころだった。当然話などわかるはずもなく、おぼろげな記憶しかなかった。それから、エヴァのTVシリーズと旧劇場版を観たのは高校生3年生のころだった。ちょうど新劇場版が公開されるタイミングで、再度10年ごしにエヴァに注目が集まっていた時期だった。
話のつながりも、結末も、わかるようでわからない、明らかに謎のまま終わった舞台装置、なんだこれ？おもしろいの？と思ったものだが、もやもやだけは残った。「エヴァンゲリオン解読」を読んだりして、旧約聖書やら形而上学やらの知識を踏まえたその解釈性の奥深さに驚いた。
[エヴァンゲリオン解読 新版―そして夢の続き](https://www.amazon.co.jp/dp/4380072150)
エヴァにはわかりやすい結末はない。厳密には結末だけは一応わかるのだが、なぜの結末に帰着するのかさっぱりわからない。わずかなヒントを頼りになんとなく、観る人が観る人なりにイメージを構成していく。
シン・エヴァンゲリオン劇場版を観終わったときの感想は、やっぱりエヴァはエヴァだった、ということだった。TV版からの謎がいっきに明かされたとか、なにかわかりやすい結末が用意されたということもなかった。違いといえば、心の壁を理解し、大人になった、登場人物が成長したあとの姿がみえる、より緻密に作られたエヴァ。それを観る自分は、高校生のころとはまた違って、人間の心の壁がままならないことをよりよく理解できるようになり、TV版の序盤にあったヤマアラシのジレンマが心に刺さるようになる。相変わらずもやもやするのだけど、それは物語の謎にもやもやするというより、自分と物語の境界線上がはっきりしなくてもやもやするといったほうがいい。
スタッフロールの「One Last Kiss」では、高校生のときに映画館で観た新劇場版の序を観たときのBeautiful Worldを思い出し、映画館から外にでた景色は、ちょうど雨上がりで晴れ渡って澄んでいた。いつもとちょっと違ってみえた景色は、ラストシーンの続きの世界のようにみえた。