AWS無料利用枠でWordPressは運用できるか 1-2 解析編

前回の続き。
WordPressをAWSの無料利用枠で運用できるか、試行錯誤した不肖カクヤ。
しかし、インスタンスを再起動した途端とても運用できない惨状に計画が破綻してしまった。
打開策として思い当たる限りの手を尽くしたが解決に至らず、一矢報いるべくWiresharkを召喚するのであった・・・

さっそくWiresharkでの分析結果を見てみる

実際にwiresharkを使用したのは今回が初めてでした。
そのため、今回は付焼刃感満載の手際と解釈で確認を進めていきます。

今回、EC2インスタンスのIPは「52.194.245.9」です。
Wireshark上段のブランクスペースに、「ip.src == 52.194.245.9」と入力します。
すると、解析結果が指定したIPがやり取りした通信のみ表示されます。
結果、下記二枚の画像のようなエラーが確認できます。

鉛色(黒?)のラインが「Bad TCP」で赤のラインが「TCP RST」、RSTはリセットの略語です。
今回着目すべき点は、「Bad TCP」、または前後の処理で何をしているか、になります。

ざっとですが見た感じ、二回（2セット×2回）「Bad TCP」が発生しているようです。
タイムフローに沿って並べて各処理について、理解を深めていきます。
（★注意：前述のように付け焼刃なため、解釈に誤りが混じっている可能性があります）
（★注意：参考程度に参照願います）

◆前提知識
SEQ：シーケンス番号。データ送信元が受信先に送る番号。送信元が発行したオーダ番号と類義。
ACK：アック番号。データ受信先が送信元に送る番号。受信先が発行した番号と類義。

解析結果への理解

＜参考サイト：https://milestone-of-se.nesuke.com/knowhow/wireshark/wireshark-tcp-error/ ＞

◆1回目の「Bad TCP」

①行番号：28
　Time：0.284209
　通信：AWS[52.194.245.9]→自宅端末
　メッセージ：[TCP Previous segment not captured] 443 → 51235 [PSH, ACK] Seq=8645 Ack=1118 Win=61824 Len=1420 [TCP segment of a reassembled PDU]

意味：
ポート443 → 51235にて、
●[TCP Previous segment not captured]
パケットの Seq# (シーケンス番号) を見る限り、このパケットよりも一つ前に本来あるべきパケットが Wireshark からは見られない。

●TCP segment of a reassembled PDU
・TCPレベルでパケットをMSS（最大セグメントサイズ）で分割した
・PDU：データ通信において、あるプロトコル（通信規約）が扱うひとまとまりのデータの送受信単位のこと

➡途中でパケットの通信が途絶えてしまったことを意味する。
　（要約：シーケンス 8645ね～♪……何か忘れていないか？）

②行番号：29
　Time：0.284209
　通信：AWS[52.194.245.9]→自宅端末
　メッセージ：[TCP Out-Of-Order] 443 → 51235 [ACK] Seq=7225 Ack=1118 Win=61824 Len=1420 [TCP segment of a reassembled PDU]

意味：[TCP Out-Of-Order]
Seq# が進んでおらず、かつ一番高い Seq# のパケットを受信してから 3 ms 以内にそれよりも低い Seq# のパケットにマークされている。
可能性として、NW 経路が(負荷分散などにより)異なるために本当に順番が入れ替わった。
または、Dup ACK を3回受信する前、かつ 3ms 以内にその ACK で要求しているパケットを受信した (再送されたのか遅れて来たのかは不明)

➡ACK1118内の複数シーケンスにて、Seq 8645が先に来ている。Seq 7225が遅れてしまっている状態。
　（要約：ケビン（シーケンス 7225）がいないぞ！）←映画、ホームアローン参照

③行番号：34
　Time：0.284349
　通信：自宅端末→AWS[52.194.245.9]
　メッセージ：51235 → 443 [ACK] Seq=1118 Ack=7225 Win=262656 Len=0 SLE=8645 SRE=10065

意味：ポート51235 → 443にて、遅延していたSeq 7225を送っている。

（要約：ケビン（シーケンス 7225）！無事でよかったわ）←映画、ホームアローン参照

◆2回目の「Bad TCP」

④行番号：73
　Time：5.292659
　通信：自宅端末→AWS[52.194.245.9]
　メッセージ：[TCP ACKed unseen segment] 51235 → 443 [ACK] Seq=1118 Ack=58149 Win=262656 Len=0

意味：[TCP ACKed unseen segment]
ポート51235 → 443にて、
直前までのパケットが見えていない（ロスしている）にも関わらず、「パケットを受信したよ！」という ACK だけ返っている状態。

（要約：58149をキャッチ！あれ・・・？どこに置けばいいの？キョロキョロ…）

⑤行番号：74
　Time：5.292669
　通信：AWS[52.194.245.9]→自宅端末
　メッセージ：443 → 51235 [FIN, ACK] Seq=58148 Ack=1118 Win=61824 Len=0

意味：Seq 58148が今届いた。

（要約：シーケンス番号58148「遅れてごめんなさい！」　　シーケンス番号58149「・・・」）

⑥行番号：75
　Time：5.292687
　通信：自宅端末→AWS[52.194.245.9]
　メッセージ：[TCP Dup ACK 73#1] 51235 → 443 [ACK] Seq=1118 Ack=58149 Win=262656 Len=0
　
意味：[TCP Dup ACK 73#1]
Ack# (応答確認番号)のパケット (#1回目) が観測されたことを意味する。
これを何度も送る場合、 Seq# = 58149 のパケットが受信できていないため、再送要求をしている、と考えられる。

（要約：「シーケンス番号58149はどこじゃあ、我！」
　　　　　シーケンス番号58149「呼び出されちゃった！なんか唐突に怖い！」）

⑦行番号：76
　Time：20.061821
　通信：AWS[52.194.245.9]→自宅端末
　メッセージ：Encrypted Alert

意味：パケットキャプチャ時に Encrypted Alert と表示される場合がある。これは ”Content Type:21 = Alert” によるものらしい。
TCP FIN の直前にある場合は大抵、TLS コネクションの終了を意味する『close_notify』だと思われる(暗号化されていて見えない)。

（要約：シーケンス番号58149「ここにいます～！（あどけない走り）」　）
（要約：迷子のシーケンスを確認しました！）

おしまいに

解析結果としてはエラーであるため、面倒極まりないですが日本固有の柔軟なサブカル性をあてて表現してみると、不思議と、何故か愛着が湧いてきました（笑）
閑話休題、パケット通信で遅延が発生していることはわかりました。
では、こちらを解消しようとすると通信各所にWiresharkなどの解析ツールを導入したりと、
マクロな対応になったりと、個人の努力では難しいようでした。
調べるならおそらく、行75～76と思われます。ここで15秒かかっているのでかなり臭います。
そのため、一旦はこの課題をクローズします。

知識不足もありましょうし、時間があれば根掘り葉掘り調べてみてもいいですが・・・
その前に転職したい。

ここまでお付き合いいただきありがとうございました。