j39_l4l7_last2

Size: px

Start display at page:

Download "j39_l4l7_last2"

えつまゆきしげ
4 years ago
Views:

1 L1 L3 触ってるたちに知っておいて欲しい L4 L7 の技術 XFLAG STUDIO 吉野純平株式会社ミクシィ 2017/01/20 1

2 今の主題コンテンツやアプリレイヤのが何をているかの共有ネットワーク等を運している時のトラブル解析に役にてば嬉しい 2

3 お題 HTTP のリクエストヘッダレスポンスヘッダーのいろいろアプリが TLS 通信している時の通信先ホスト名の確認法トンネル技術利時の ECN ビットの挙動パケット再送に関する話とその新しい発策 (tips なので新しいとかそういうのは少ないです ) 3

4 HTTP のヘッダー

5 ヘッダーをれば体わかる HTTP 1.1 周りが RFC7230 関連するものが RFC に連続してある ( 目新しいものは少ないけど RFC2616 他が更新された ) A client sends an HTTP request to a server in the form of a request message, beginning with a request-line that includes a method, URI, and protocol version (Section 3.1.1), followed by header fields containing request modifiers, client information, and representation metadata (Section 3.2), an empty line to indicate the end of the header section, and finally a message body containing the payload body (if any, Section 3.3). RFC7230 より引用コンテンツの中はアプリによるけどヘッダーをみればいろいろわかる 5

6 よくるもの Host HTTP/1.1では必須接続先のホスト名を送る IPで複数ドメインをカバー X-Forwarded-For Proxy 等する際に接続元情報等を伝える RFC7239で Forwarded として定義しなおされた併可能なのでまだまだき続けそう 6

7 地味にハマったり忘れたりするもの Range (RFC7233) コンテンツの部をリクエストする無効な場合があるので注意 Vary レスポンスヘッダー : どのリクエストヘッダーでキャッシュを別けるか例 "Vary: User-Agent とするとブラウザごとにキャッシュされる Date レスポンスヘッダー : コンテンツにアクセスされた時間これもキャッシュされる可能性があるので注意が必要 7

8 何か変だとわれたらまずはヘッダーをる!! $ curl -v > GET /index.html HTTP/1.1 > Host: > User-Agent: curl/ > Accept: */* > 8

9 何か変だとわれたらまずはヘッダーをる!! > < HTTP/ OK < Content-Type: text/html; charset=utf-8 < Transfer-Encoding: chunked < Connection: keep-alive < Server: nginx < Date: Thu, 19 Jan :13:37 GMT < Vary: Accept-Encoding 9

10 TLS でも接続先ホスト名がわかる

11 なんで知りたいんだっけ? デバッグする時等に TLS セッションができる IP レンジをみればどこの AS( 多くはクラウド ) かわかるどんな通信先か確認したい自社の API エンドポイントなのかアプリになんらかの SDK を入れたことによるものなのか 11

12 Client Hello の中の SNI の情報をよう!! TLS でも暗号化されてない情報がある 12

13 トンネルと ECN

14 ECN のサポート状況の変化の込み JANOG LT Night で屋さんが発表 ECN(Explicit Congestion Notification) のあるネットワーク Linux のデフォルト実装が気になる Version 4.1 より前 ECN が有効な接続を受けた場合に ECN を有効にして応答 Version 4.1 以降自分からも ECN を有効で接続 Android も 7.0 からベースになる? ECN 周りでハマったことを共有 14

15 特定パターンでは drop するトンネル利とECNを組み合わせた時に当たったもの innerがnot-ectで outerがce 状態だとdrop (RFC6040 Tunnelling of Explicit Congestion Notification 参照 ) LinuxでもすでにIPIPトンネル等で上記のコードが動いている ( 部ロスするので気がつきづらい ) Inner IP (Not-ECT) Inner IP (Not-ECT) Outer IP (ECT) Inner IP (Not-ECT) Outer IP (CE) トンネル終端 15

16 パケット再送とその発

17 パケロスのインパクトと発段パケロスは不幸の連鎖の始まり検知して運したいアプリケーションサーバのプロセスが滞留バックエンドの解放が遅れる場合もあるユーザ体感の悪化パケットロスをつける法としてサーバの tcp の再送処理を利する段の共有 ( キャプチャされたファイルを解析するのではない ) 17

18 パケロス発法の整理 : 中継ノードかエンドか中継ノードの error や discard のカウントアップを探す分の管理範囲内で閉じればできる End to End で再送をつける End ノードなら問題の宛先がわかるただどこで起きたかは特定できない END ルータルータ END 18

19 サーバでの旧来からある再送確認法 SNMPで tcpretranssegs にてカウンターが取れるデメリット : 誰との間でretransしているかわからないクラウド含め全サーバでています 19

20 End to End でつける SSコマンド ss -tni 等するとパケロスしているセッションを発可能カーネル内での再送処理をフック発した瞬間に記録可能カーネル書き換え=>SystemTAP => ebpfの変遷 20

21 ss コマンドによる情報取得 kernel 内から情報を取り出して表する $ ss nti State Recv-Q Send-Q Local Address:Port Peer Address:PortESTAB 0 0 X.X.X.X:XXXX X.X.X.X:XXXXX cubic wscale:5,7 rto:208 rtt:4.5/0.759 ato:40 mss:1368 cwnd:10 ssthresh:16 bytes_acked:5109 bytes_received:4149 segs_out:45 segs_in:60 send 24.3Mbps lastsnd:40 lastrcv:48 lastack:36 pacing_rate 29.2Mbps rcv_rtt:8 rcv_space:

22 再送もつけられる SYN-SENT 0 1 x.x.x.x:xxxxx X.X.X.X:80 cubic rto:8000 backoff:3 mss:524 cwnd:1 ssthresh:7 segs_out:4 lastsnd: lastrcv: lastack: unacked:1 retrans:1/3 lost:1 22

23 発展系 ss tni -Eとすると終了したセッションを流せる分でコードを書けば以下のセッションのみを書き出すことも可能再送したセッション RTTがきなセッション 23

24 カーネルで再送する処理をフックするパケット再送の関数が呼ばれた時に該当の通信の情報を取る iovisor 便利です! ols/tcpretrans_example.txt (systemtap も不要なので debuginfo とかのビルドがいらない!) ( ダンプパケットをファイルに書いてから解析がいらない ) ( 再送した度に記録されるが故にうるさいかも ) 24

25 L7 アプライアンス機器への要望 L7 のロードバランサでコネクション終端する機器サーバと同等の情報が取れると嬉しいです実装予定はありますか? クライアントロードバランササーバパケット再送等の情報を転送分析用サーバ 25

26 インターネットと再送の発いかに再送している場所をつけるかが肝経路情報とフロー情報と再送情報があれば戦えるかもしれない out 向は分で再送状況をえてトライしやすい in 向はどうしようもないのでインパクトあるなら個別交渉トランジット A IX トランジット B AS 経路を振ってみて変わるか確認等 26

27 議論理想はL1-L3とL4-L7の世界とのコラボレーション統計情報化してお渡しするといいことありますかね例: このAS-PATH 品質あやしくないですか? コンテンツやさんで同じようなことしてます? 27

MIRACLE LoadBalancerを使用したネットワーク構成と注意点

MIRACLE LoadBalancerを使用したネットワーク構成と注意点 MIRACLE LoadBalancer を使用したネットワーク構成と注意点ミラクルリナックス 2015/02/13 Agenda ネットワーク接続パターンパケット転送方式 NATオプション注意点負荷分散方式固定化方式 Cookieオプション注意点 2 ネットワーク構成パターンパフォーマンスダイレクトサーバーリターン (DSR) 対障害性対応レイヤ備考接続パターン 1 冗長無し