dorapon2000’s diary

忘備録的な。セキュリティとかネットワークすきです。

macOSで1つのコアだけに負荷を掛けたいけどできない!

&とwaitに関する記事を書いた時、macで1つのコアだけに負荷を掛けたいという状況がありました。しかしどうしても均等に負荷が掛かってしまうので、そのことについてまとめます。なお、この記事からは、原因も解決策もわからないです。

宣伝

dorapon2000.hatenablog.com

目次

環境

やったこと

yesで負荷を掛ける

macOSに収録のyesコマンドはマルチスレッドに最適化されていないため、メニーコアのCPUを積むMacで実行しても、1基の論理CPU(コア)に対し負荷をかけるに過ぎないからだ。

ひたすらMacを重くする「ストレステスト」をお手軽に - 新・OS X ハッキング!(248) | マイナビニュース

私は上の記事を読んで、macのyesであれば1つのコアだけに負荷を掛けられると想像しました。(今あらためて読むと全体として1コア分の負荷を掛けるだけで、1つのコアとは言っていない気もしますが...)

❯ yes > /dev/null &
❯ ps -o pid,comm,%cpu
  PID COMM   %CPU
 6152 -fish   0.0
 8925 -fish   0.0
14652 yes   100.0

yesのcpu使用率は100%ですが、

f:id:dorapon2000:20210612183524p:plain:w400

yes > /dev/null & yes > /dev/null &

f:id:dorapon2000:20210612183555p:plain:w400

1つ実行でも2つ実行でも4つの物理コアに対して均等に負荷が掛かっています。

最近のmacだとなにか仕組みが違うのかと思って別のコマンドでも試してみました。

opensslで負荷を掛ける

yesで紹介した記事の方法にありました。こちらであればCPU数を指定できます。

openssl speed -multi 1

f:id:dorapon2000:20210612184449p:plain:w400

うーん、こちらでも均等に負荷が掛かってしまいます。

openssl speed -multi 8

f:id:dorapon2000:20210612184438p:plain:w400

ちなみに、8を指定すればすべての論理コアに負荷がかかることは確認できます。

stress-ngで負荷を掛ける

stress-ng — Homebrew Formulae

このコマンドであれば、指定したコアにだけ負荷を掛けられるようなので試してみます。

❯ brew install stress-ng

# CPU数1つでコア番号1に指定して負荷を掛ける
❯ stress-ng -c 1 --taskset 1
taskset: setting CPU affinity not supported

エラーが出ました。

結論っぽいもの

エラーについて調べると以下のような記事を見つけました。

stackoverflow.com

どうやら、macAPIではコアを指定してプロセスを実行できないようで、カーネルがすべてのスレッドを掌握しているようです。

となると、それぞれのコアに均等に負荷がかかるのはmacOSがよしなにした結果で、macでは1つのコアだけに負荷を掛けるのは無理そう?

これ以上はブロックボックスっぽいので調べられなさそうです。記事おわり!

シェルの&とwaitについて少し調べてみた

&はシェルにおいてバックグラウンド実行をするコマンド?です。 そして、複数のバックグランドジョブの終了を待つコマンドがwaitです。

つまり、

sleep 20 &
sleep 10 &
wait  # 上2つのコマンド入力直後であれば20秒待機

# sleep 20 & sleep 10 & wait  #1行にもできる

というコマンドは20秒sleepするジョブと10秒sleepするジョブをバックグランドで実行し、それらが終わるまで待つことになります。

今回はmanを見てもよくわからなかった2つの疑問を調べてみます。

疑問

  • 1行に2つ書いた&によるバッググラウンド実行は、ハイパースレッドあるいはマルチコアで実行されるか
  • waitによって完了を待つのは同じ親プロセスに属する&によるプロセスなのか

結論

  • 1行に2つ書いた&によるバッググラウンド実行は、マルチコアで実行される
  • waitによって完了を待つのは、同じ親プロセスに属するすべての&による子孫プロセス

環境

  • WSL2
  • Ubuntu 20.04 LTS
  • bash
  • CPU 4コア4スレッド

調査

疑問に対してそれぞれ調査して確認します。

マルチコアになるか

CPUに負荷をかけるためyesを2つバックグランドで実行します

$ yes > /dev/null & yes > /dev/null &
[1] 2929
[2] 2930

$ jobs
[1]-  Running                 yes > /dev/null &
[2]+  Running                 yes > /dev/null &

$ top
略
%Cpu0  :   0.0/18.2   18[|||||||||||||||||                                                                            ]
%Cpu1  :  62.4/37.6  100[|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||]
%Cpu2  :   0.0/1.1     1[|                                                                                            ]
%Cpu3  :  64.0/36.0  100[|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||]

2つのCPUの利用率が100%になっているため、マルチコアで実行されるということがわかります。

バックグランドジョブの終了

$ kill %1 %2
$ jobs
[1]-  Terminated              yes > /dev/null
[2]+  Terminated              yes > /dev/null

waitが待つプロセス

wait() This function waits for the first child to die. The return value is that of the wait(2) system call.

manの説明ではよくわからなかったので確認します。

叔父プロセス

親プロセスのfishでsleep 100を実行し、その子プロセスのbashでさらにsleep 10sleep 5を実行しました。

sleep 100 &
❯ bash

$ ps
  PID TTY          TIME CMD
   13 pts/1    00:00:06 fish
 3248 pts/1    00:00:00 sleep
 3311 pts/1    00:00:00 bash
 3317 pts/1    00:00:00 ps

$ sleep 10 & sleep 5 & pstree -p 13; wait
[1] 3318
[2] 3319
fish(13)─┬─bash(3311)─┬─pstree(3320)
         │            ├─sleep(3318)
         │            └─sleep(3319)
         └─sleep(3248)
# 10秒後
[1]-  Done                    sleep 10
[2]+  Done                    sleep 5

上の挙動から親のfishで実行されたsleepは待たず、bashで実行された2つのsleepの実行を待っている事がわかります。

ワンライナーではない兄弟プロセス

$ sleep 20 &
[1] 3354

$ sleep 5 & pstree -p 13; wait
[2] 3355
fish(13)───bash(3311)─┬─pstree(3356)
                      ├─sleep(3354)
                      └─sleep(3355)
# 約20秒後
[1]-  Done                    sleep 20
[2]+  Done                    sleep 5

当然ですが、ワンライナーとか関係ないです。同じbashの子プロセスであればすべて待ちます。

甥プロセス

$ sh -c 'sleep 10' & sleep 5 & pstree -p 13; wait
[1] 3358
[2] 3359
fish(13)───bash(3311)─┬─pstree(3360)
                      ├─sh(3358)───sleep(3361)
                      └─sleep(3359)
# 10秒後
[1]-  Done                    sh -c 'sleep 10'
[2]+  Done                    sleep 5

同じ親を持つ子孫すべてのバックグラウンドジョブを待ちました。

まとめ

結論に書いたとおりですが、期待どおりの動作をしてくれました。 package.jsonのscripts内でコマンドを&で並列実行できるか確認したかったのが今回の調査の動機でした。

甥プロセスや叔父プロセスといった名詞があるかは知りません。

HTTP/2のTCPレベルのHoLブロッキングとQUIC

HTTP/2はHTTP/1.1で問題だったHTTPレベルのHoLブロッキングを解消しました。しかし、TCPレベルのHoLブロッキングという問題が依然として残っています。。。。。。🤔🤔

ぐぐるとたくさん解説サイトが出てきますが、いろいろ調べて、自分の言葉に落とし込んでみます。

概要

  • HTTP/1.1にはHTTPレベルのHoLブロッキング問題がある
    • HTTP/2で解決する
  • HTTP/2にはTCPレベルのHoLブロッキング問題がある
    • HTTP/3で解決する
  • HTTP/3ではTCPを使わずに、HTTP/2におけるストリームを別々で管理する

HoLブロッキング とは

f:id:dorapon2000:20210411070906p:plain

HoL (Head of Line) ブロッキングとは、待ち行列ができている中で先頭の客しかサービスを受けられない場合、残りの人が待たされなくてはいけないことを指します。

コンビニで例えるなら、レジにお客さんが並んでいるとして、精算中の人以外の人はスマホをいじりながら待つ必要があります。そんな中、精算中の人がお金が足りないなどと言ってATMに駆け出したら、いらっとくるわけです。このような状況がHTTPでも同じように発生します。

HTTP/1.1

HTTPコネクションを張るということはTCPコネクションを張るということです。ここでの、コネクションという単語はどちらの意味でも取ることができます。

特徴

f:id:dorapon2000:20210411135230j:plain

  • KeepAliveすることにより1つのコネクションで複数のファイルを送信可能。
    • ただし単一コネクション内では並行には送れない(HoLブロッキング
  • コネクションは一般に1つのドメインに対して並列に6つまで張ることができる
    • HTTPの仕様ではなく、一般的なブラウザによる制約
  • 6つ以上張りたい場合はドメインを複数用意する(ドメインシャーディング)
    • 2つのドメインを用意すれば、最大12個のファイルを並列に送信できる

HTTPレベルのHoLブロッキング

1つのHTTPコネクションだけに注目します。

http://www.plantuml.com/plantuml/png/SoWkIImgAStDuKegoYylJYrIqBLJ059bG9QLWhjhY4AYeLv1NZeNI0miMw40Ksc58OSXXTjK8rmwOL8EgNafG7S10000

GET a1.pngGET a2.pngGET c3.png の順に、HTTPリクエストがクライアントの送信キューで順番待ちしているとします。a1.pngのレスポンスがどこかで損失した場合、サーバは再送しますが、その間GET a2.png以降のリクエストを送ることはできません。具体的には、a1.pngは複数のTCPパケットに分割して送られており、そのうちの1つ以上が損失するとこのような状況になります。

HoL=GET a 1.pngが、GET a2.png以降のHTTPリクエストをブロッキングしています。

HTTP/2

HTTP/1.1のコネクションが、HTTP/2ではストリームにあたります。そして、HTTP/2では単一のTCPコネクションで複数ストリームを扱うことで並行にファイルを送信します。

HTTP/2の説明は詳解HTTP/2をとても参考にしています。

特徴

f:id:dorapon2000:20210411170325p:plain

  • 単一のTCPコネクションを使う
    • 1つのTCPパケットに複数ストリームのバイナリが含まれる可能性もある
  • 100以上のストリームでファイルを並行に送信可能
    • 同時に流せる最大ストリーム数はブラウザやサーバによって異なるがapacheは100
    • ファイルごとにストリームが生成される(再利用不可)
    • HTTP/2が出た今、ドメインシャーディングは非推奨*1

TCPレベルのHoLブロッキング

f:id:dorapon2000:20210411170329p:plain

HTTP/2でストリームを謳っても、TCPの上で成り立つ以上、MTUのサイズに整えられたTCPパケットが送信されます。そのパケットが損失すれば、TCPの機能で再送と順序制御がされます。ここがネックなのです。

上図では、ストリーム1だけを含むパケットが損失したため再送されます。その再送パケット以外をブラウザが受け取ったとして、ストリーム2とストリーム3のデータはすべて揃ったのだから、緑とオレンジの画像は表示されると期待してしまいます。

しかし、実際はTCPはシーケンス番号通りの順にしか処理できないため、4つ目のパケットをキューに入れて、3つ目のパケットが来るまで待ちます。キューに入っている間はHTTP側はストリーム3のデータを取り出せないため、オレンジの画像も表示できないです。

HoL=順序が入れ替わったパケットが、後続のパケットの処理をブロッキングしています。

HTTP/2の欠点

ここから見えてくるのは、HTTP/1.1と比べてHTTP/2がパケットロスに弱いという性質です。HTTP/1.1では独立したTCPコネクションを張っていたため、パケット損失はそのコネクションにしか影響がありません。HTTP/2は後続のすべてのストリームに影響があります。

具体的には、2%のパケロスでHTTP/1.1のほうが性能がよくなるようです*2*3。ただ、2%のパケロス環境も相当なようで、現実ではそこまでネックにはならないみたいです。

HTTP/3のQUIC

TCPレベルのHoLブロッキング問題を改善しているのがHTTP/3です。HTTP/3はほぼHTTP/2+QUICの組み合わせを指すため、QUICが肝になります。

QUICの特徴

UDP上で構築されていますが、トランスポート層プロトコルに相当します。

  • TCPと同じような動作をする
    • コネクション志向
    • 再送制御
    • 輻輳制御
  • 複数のストリームを扱うことができ、各ストリームごとに制御することができる
    • アプリケーション層のHTTP/2のストリームの概念をトランスポート層まで落としてきたといえる
    • 特定のストリームのパケット損失は他のストリームに影響がでない

TCPだから問題だったHoLブロッキング問題を、TCPを使わないことで解決しています。大胆ですね汗。

まとめ

L4〜L7のことを調べていると、面白くて無限に文献を漁ってしまいます。QUICはすごいし名前も速そう!

参考文献

example.comのTLS1.3ハンドシェイクを見てみる

example.comのTLS1.3ハンドシェイクを覗いてみます。

この記事を書くために、TLS1.3について別記事にまとめました。

dorapon2000.hatenablog.com

通信を覗く方法

下記のサイトのやり方でexample.comと通信するchromeの通信をWiresharkで覗きました。

【解析/Wireshark】https(SSL/TLS)を復号化する方法(SSLKEYLOGFILE),ブラウザで見る方法 | SEの道標

TLSハンドシェイク

以下のスクショは、実際にキャプチャしたTLSパケットです。

f:id:dorapon2000:20210406004132p:plain

見やすくシーケンス図にすると次のようになります。[]は暗号化済みのメッセージで外部からは中身を見ることができません。

http://www.plantuml.com/plantuml/png/hOzFIyD04CNl-HHp3ofux44AeTA3Y9ZWfUIm9A_TeVjddPrey-rTh8UA13pqCZ3pVeyViyvgH2VlgeF4AL7tr98rOSpM754rLg87tJmGJiOdXziXUbfHunX1QGldOdKP5VAdipgdz0gLkSpt2LcfBh491r33oKAeJHYMBNzGgl-dRY4Va3DKEhjD66HEYf4s9qLGZg5VBEyQYFAU1wFegVwrqnk4z_Ft-P43PuknNthW4a4ObuNF-AGMENCCrF5mXFPNWhTTzt9ttrVhuf-y-m80

翻訳版。

http://www.plantuml.com/plantuml/png/SYWkIImgAStDuKeloYyjK0Zn2LR8ICnBASv8p4xbSiueoizDLT2rKqYjICmjo4dLIyxFLR1I03HB1Za9Wq4KtdCgxu7iN7C6tZ-A8L8HZGfYn0QbW8Oc6YDAQm_p-jTsnHKS4IEI_AxTjJFJzxutK-A4c5BQb375fqGq2H4KjOiqyMqhp2LUHFtjgcruElXLrZwDeMaG0w9VU4z4az3A0T4cnZHpYj0yKmBAewrxnPcs0iBJ6TKhhLCer0fFUQH6MHgW-mTqXqO8uw9togUlzJmOi8RoTv8xc-pbGn2JJHbpdCrqu9nuKvYAKxESJxny5ArBwMlMESnwCsBq7Z_O8urjVgavivMpcqlzt4wRohg8eBxL7RTtTk_RtbKwloswd_VPM3mH_gp8l512QZPfQBOqJfRN6n8jufeu9NOh_y28ihywWFkXKjhIhUY__W40

Clinet Hello

Client HelloはサーバにTLS通信の開始を伝えるわけですが、暗号スイート以外の必要な情報は各拡張機能にいれておきます。

思ったより拡張の数が多かったので1フィールド+6拡張に絞って見ていきます(あんまり絞れていない)。

  • 利用できるTLSのバージョン(supported_versions)
  • 利用できる暗号スイート(Cipher Suitesフィールド)
  • 利用できる鍵交換アルゴリズムの提示(supported_groups)
  • 通信予定の鍵交換アルゴリズムのパラメータ(key_share)
  • 利用できる署名アルゴリズムの提示(signature_algorithms)
  • 今後PSKの交換をするかどうか(psk_key_exchange_modes)
  • 過去の通信で交換したPSK(pre_shared_key)

f:id:dorapon2000:20210407040902p:plain

supported_versions拡張

クライアント(ここではChrome)が対応しているTLSのバージョンを格納します。

f:id:dorapon2000:20210407015424p:plain

TLS1.0~1.3まで対応しているようです。もちろんクライアントとしては新しいバージョンで通信してほしいわけです。

Cipher Suitesフィールド

クライアントが対応している暗号スイートを格納します。TLS1.3はTLS1.2までとフォーマットが異なり、暗号化アルゴリズム共通鍵暗号)の部分だけが示されています。詳しくは僕の前の記事に書いています。

※Aはアルゴリズムの略です。

TLS1.2: TLS_鍵交換A_署名A_WITH_(暗号化A_鍵長_暗号利用モード)_ハッシュ関数
TLS1.3: TLS_(暗号化A_鍵長_暗号利用モード)_ハッシュ関数

f:id:dorapon2000:20210407041005p:plain

なるほど~。TLS1.2以前とTLS1.3の暗号スイートが混ざっています。このClient HelloがTLS1.3として解釈されたときは上の3つが、そうでないときは下のものが利用されるというわけですね。TLS後方互換性に配慮していることが見て取れます*1

ちなみにVersionフィールドがTLS 1.3ではなくTLS1.2なのも後方互換性のためです。TLS1.3では本当はVersionフィールドを消したかったみたいです*2

supported_groups拡張

クライアントが対応している鍵交換アルゴリズムを格納します。メッセージの暗号化に必要な鍵を交換するために使います。

f:id:dorapon2000:20210407021111p:plain

ECDHEのうち3つの楕円曲線に対応しているようで、逆に、DHEは提示していません。

x25519はTLS1.3から導入されたアルゴリズムで、新しいためまだ未対応のケースが多いようですが、さずがChrome様。対応済みです。

key_share拡張

TLS1.2では、鍵交換アルゴリズムを決定後に、アルゴリズムの計算に必要なパラメータを別の通信で送ります。TLS1.3では、そのアルゴリズムが使われるかわからないのに、Client Helloの段階で送ってしまいます。そうすることで、あわよくば通信に必要な往復を削減できるのが特徴です。

f:id:dorapon2000:20210407022200p:plain

ここでは、x25519が使われると想定して、そのパラメータを格納しています。どうなるでしょうか。

signature_algorithms拡張

クライアントが対応している署名アルゴリズムを格納します。サーバの認証に必要です。

f:id:dorapon2000:20210407022721p:plain

ECDSAとRSAに対応しているようです。鍵交換アルゴリズムでx25519に対応しているので、その署名アルゴリズムverのed25519にも対応していそうなものですが、提示されていませんね。謎です。

psk_key_exchange_modes拡張

TLS1.3ではセッションの再開にPSK(Pre-Shared Key)を使えます。PSKの共有方法は、前回のセッション中に交換するか、TLSスコープ外(手渡しとか?)で交換するかです。psk_key_exchange_modes拡張では、PSKの交換に対応しているか、PSKで接続を確立する方法を格納します。

f:id:dorapon2000:20210407023419p:plain

対応していました。PSKのみのセッション再開ではPFS(同じ鍵で過去の通信まで復号できないこと)がないため、PSKとECDHEを使ったハイブリッドな鍵交換でPFSを保証できるpsk_dhe_ke方式が指定されています。

pre_shared_key拡張

PSKが格納されています。キャプチャする前に試しにアクセスしているため、そのときに交換したものだと思われます。

f:id:dorapon2000:20210407052229p:plain

Client Helloまとめ

Chrome「サーバーさんサーバーさん

  • TLS1.3に対応してるよ!
  • こんな暗号スイートに対応してるよ!(雑)
  • x25519で鍵交換しようよ!
    • 無理でもsecp256r1とsecp384r1に対応してるよ!
  • RSAとECDSAで署名の検証ができるよ!
  • PSK対応してるよ!
  • PSK持ってるよ!

Hello Retry Request

クライアントが提示した鍵交換アルゴリズムのパラメータに対応していなかった場合、このメッセージでやり直しをさせます。

f:id:dorapon2000:20210407032011p:plain

Chromeはx25519のパラメータを送っていましたが、サーバはsecp256r1のものがほしかったようです。

Change Cipher Spec

TLS1.2では暗号スイートの変更の際に利用されたメッセージですが、TLS1.3ではHello Retry Requestがあるため不要なはずです。なぜChange Cipher Cpecを送信しているのかはよくわかりません。

  • The server sends a dummy change_cipher_spec record immediately after its first handshake message. This may either be after a ServerHello or a HelloRetryRequest.

https://tools.ietf.org/html/rfc8446#appendix-D.4

ミドルボックス互換性のためのようです。

2度目のClient Hello

Chromeは署名アルゴリズムのパラメータとしてsecp256r1のものを送って再挑戦します。

Client Helloが更新された際のPSK

In addition, in its updated ClientHello, the client SHOULD NOT offer any pre-shared keys associated with a hash other than that of the selected cipher suite.

https://tools.ietf.org/html/rfc8446#section-4.1.4

Hello Retry Requestが送られたあとはPSKによるセッションの再開ができない可能性があるようです。

今回はそのパターンのようで、セッション再開されていればやり取りされないはずのCertificateとCertificate Verifyがあります。

Server Hello

クライアントが提示したアルゴリズムリストから1つづつアルゴリズムを選んでクライアントに教えます。 よく考えるとHello Retry Requestと同じ事をしており、実際に中身もほぼ同じなので省きます。

Encrypted Extensions

鍵交換/署名/暗号化アルゴリズム同意後であれば、それ以外の情報はもう暗号化して隠せます。なのでTLS1.3では、Server Helloとは別でEncrypted Extensionsがあります。

f:id:dorapon2000:20210407034021p:plain

ALPNはHTTP通信のバージョンの合意をとるプロトコルで、クライアントがh2(HTTP/2)で通信したいと提案してきたので、対応しているサーバもh2を返しています。

f:id:dorapon2000:20210407034522p:plain

こちらがClient Hello内にあったALPNプロトコルです。

Certificate

サーバの認証に必要な証明書チェーンが格納されています。

f:id:dorapon2000:20210407044610p:plain

ブラウザからも見られます。

f:id:dorapon2000:20210407044810p:plain

Certificate Verify

サーバの認証に必要なデジタル署名が格納されています。証明書チェーンとセットで使われます。

f:id:dorapon2000:20210407044858p:plain

署名アルゴリズムrsa_pss_rsae_sha256が指定されていました。

Finished

クライアントもサーバもハンドシェイクの最後はFinishedを送り、今までのやりとりが改ざんされたものでないか検証をします。

TLS Session Ticket

PSKの計算に使うチケットをサーバ側から任意のタイミングでクライアントに通知します。Client Hello時のpsk_key_exchange_modes拡張で、クライアントがPSKに対応していることをサーバは確認済みです。

今回は連続で2つのチケットを送信していますが、なぜかはわからないです。

まとめ

1つ1つ調べるのが大変でしたが、TLS1.3について理解が進みました。別のサイトについてモチベーションが保てていれば見ていきたいと思っています。

参考

*1:https://tools.ietf.org/html/rfc8446#appendix-D

*2:PDF版プロフェッショナルSSL/TLS 付録A