スポンサーサイト
IEEE802.11n
IEEE802.11nについて調べてみた。
■特徴
・規格上は最大速度600Mbps。(ただし、実装では300Mbpsが多いみたい)
・IEEE802.11a/b/gと下位互換性がある。
・2.4GHz帯、5GHz帯の両方で使える。
■速度向上の仕組み
★チャネル当たりの速度向上
IEEE802.11a/gではチャネル当たりの速度は54Mbpsだったが、それはOFDMで利用するサブチャネル48個によって実現していた。802.11nではOFDMのサブチャネルを52個に増強した。また、FEC(Forwarding Error Correction:前方誤り訂正)の冗長性ビットを4bitにつき3bitつけてたものを、6bitにつき5bitとした。さらにガードインターバルと呼ばれるパケット干渉防止のためのパケット送信間隔を800nsから400nsに狭めることにより、1チャネル当たりの速度を75Mbpsに向上される。
★チャネルボンディング
1チャネル当たり20MHz帯域を利用するが、チャネルボンディングにより2チャネルを論理上の1チャネルとして扱うと。その結果、倍速モードで最大150Mbpsの通信ができます。
★MIMO
アンテナを複数立てることにより、さらに複数倍のスループットが可能。
よく無線APで(2x2)などと表記されているが、受信アンテナ2, 送信アンテナ2という意味。2ストリーム。
この場合、受信も送信も300Mbpsとなる。
規格上は4x4まで規定されており、最大600Mbpsとなるが、現在販売されている製品はたいてい2x2の300Mbps。
また、MIMOにより、わざと位相をずらした波を送ることで、反射波を有効に扱える仕組みもあるため、部屋の隅だと意外と電波が強かったりする。
a/b/gにも実装としてアンテナを2つ立て、反射波を有効に扱う仕組みがある(無線ダイバーシティ(ダイバーシチ)と呼ぶ)
ちなみに、この反射波を有効に扱う仕組みは、昔自分が勉強していた主成分分析(PCA)や独立成分分析(ICA)のモデル式と一緒で、受信電波をy, 送信電波をx、係数行列をA、ノイズをnとして
y1 A1 A2 x1 n1
( ) = ( ) ( ) + ( )
y2 A3 A4 x2 n2
というモデルから、受信側で送信電波xを推定することのようだ。
上記のモデルからすると、無線クライアント側が利用位置を変えると、計算し直しになるはず。
■特徴
・規格上は最大速度600Mbps。(ただし、実装では300Mbpsが多いみたい)
・IEEE802.11a/b/gと下位互換性がある。
・2.4GHz帯、5GHz帯の両方で使える。
■速度向上の仕組み
★チャネル当たりの速度向上
IEEE802.11a/gではチャネル当たりの速度は54Mbpsだったが、それはOFDMで利用するサブチャネル48個によって実現していた。802.11nではOFDMのサブチャネルを52個に増強した。また、FEC(Forwarding Error Correction:前方誤り訂正)の冗長性ビットを4bitにつき3bitつけてたものを、6bitにつき5bitとした。さらにガードインターバルと呼ばれるパケット干渉防止のためのパケット送信間隔を800nsから400nsに狭めることにより、1チャネル当たりの速度を75Mbpsに向上される。
★チャネルボンディング
1チャネル当たり20MHz帯域を利用するが、チャネルボンディングにより2チャネルを論理上の1チャネルとして扱うと。その結果、倍速モードで最大150Mbpsの通信ができます。
★MIMO
アンテナを複数立てることにより、さらに複数倍のスループットが可能。
よく無線APで(2x2)などと表記されているが、受信アンテナ2, 送信アンテナ2という意味。2ストリーム。
この場合、受信も送信も300Mbpsとなる。
規格上は4x4まで規定されており、最大600Mbpsとなるが、現在販売されている製品はたいてい2x2の300Mbps。
また、MIMOにより、わざと位相をずらした波を送ることで、反射波を有効に扱える仕組みもあるため、部屋の隅だと意外と電波が強かったりする。
a/b/gにも実装としてアンテナを2つ立て、反射波を有効に扱う仕組みがある(無線ダイバーシティ(ダイバーシチ)と呼ぶ)
ちなみに、この反射波を有効に扱う仕組みは、昔自分が勉強していた主成分分析(PCA)や独立成分分析(ICA)のモデル式と一緒で、受信電波をy, 送信電波をx、係数行列をA、ノイズをnとして
y1 A1 A2 x1 n1
( ) = ( ) ( ) + ( )
y2 A3 A4 x2 n2
というモデルから、受信側で送信電波xを推定することのようだ。
上記のモデルからすると、無線クライアント側が利用位置を変えると、計算し直しになるはず。
インターネット通信パケットキャプチャ3(http)
パソコンがインターネットと通信する際のパケットキャプチャをとってみた。
■キーワード
httpパケットフォーマット, TCPシーケンス
■環境
OS：Windows7(32bit) on VMWare(R) Player 3.1.3, ブラウザ：IE8
192.168.11.3のPCから、yahooのHP(www.yahoo.co.jp)にアクセス
■pcapファイル
ここからダウンロード
■解説
★pcapファイルの6パケット目
HTTP GET のパケット。
webサーバのコンテンツのダウンロードを要求する。具体的には
www.yahoo.co.jp/index.html
のファイルを要求する。
---↓キャプチャ(L2,L3,L4部分は省略。http部分のみ)---
Hypertext Transfer Protocol
GET / HTTP/1.1\r\n
[Expert Info (Chat/Sequence): GET / HTTP/1.1\r\n]
[Message: GET / HTTP/1.1\r\n]
[Severity level: Chat]
[Group: Sequence]
Request Method: GET
Request URI: /
Request Version: HTTP/1.1
Accept: */*\r\n
Accept-Language: ja\r\n
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0)\r\n
Accept-Encoding: gzip, deflate\r\n
Host: www.yahoo.co.jp\r\n
Connection: Keep-Alive\r\n
\r\n
---
キャプチャを見るとindx.htmlは明示的には要求していないことが分かる。通常はURI: /index.htmlなどのファイル名が記載されているが、このパケットキャプチャを見ると、URI: /となっている。このように、取得すべきファイルが明記されていないhttpパケットをwebサーバが受け取ると、サーバ側であらかじめ指定されているファイルを自動的に返す。サーバで設定されているファイルは、index.htmlだけでなく、index.htm, index.phpなどがよく使われる。
★pcapファイルの7パケット目
TCP 80番ポートからの通信でindex.htmlの内容を含むhttpフォーマットを受信している。
---↓キャプチャ(L2,L3,L7部分は省略。TCP部分のみ)---
Transmission Control Protocol, Src Port: http (80), Dst Port: 49188 (49188), Seq: 1, Ack: 297, Len: 1414
Source port: http (80)
Destination port: 49188 (49188)
[Stream index: 1]
Sequence number: 1 (relative sequence number)
[Next sequence number: 1415 (relative sequence number)]
Acknowledgement number: 297 (relative ack number)
Header length: 20 bytes
Flags: 0x10 (ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgement: Set
.... 0... = Push: Not set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 66458 (scaled)
Checksum: 0x86ad [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
[SEQ/ACK analysis]
[This is an ACK to the segment in frame: 6]
[The RTT to ACK the segment was: 0.024742000 seconds]
[Number of bytes in flight: 1414]
TCP segment data (1414 bytes)
---
スロースタートにより、2〜5(pcapファイルの7〜10)のパケットを送信した後、クライアントからのACKを待ちます。
★pcapファイルの11パケット目
クライアントからのACK。
---↓キャプチャ(L2,L3部分は省略。TCP部分のみ)---
Transmission Control Protocol, Src Port: 49188 (49188), Dst Port: http (80), Seq: 297, Ack: 5657, Len: 0
Source port: 49188 (49188)
Destination port: http (80)
[Stream index: 1]
Sequence number: 297 (relative sequence number)
Acknowledgement number: 5657 (relative ack number)
Header length: 20 bytes
Flags: 0x10 (ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgement: Set
.... 0... = Push: Not set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 65700 (scaled)
Checksum: 0x8b8f [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
[SEQ/ACK analysis]
[This is an ACK to the segment in frame: 10]
[The RTT to ACK the segment was: 0.000045000 seconds]
---
受け取った後にさらに5パケットを送っています。pcapファイルの32パケット目でダウンロード終了。
ちなみに、pcapファイルの7〜32パケット目のクライアントからのACKを除くデータ部分を結合すると、以下のhttpフォーマットが出てきます。
---
Hypertext Transfer Protocol
HTTP/1.1 200 OK\r\n
[Expert Info (Chat/Sequence): HTTP/1.1 200 OK\r\n]
[Message: HTTP/1.1 200 OK\r\n]
[Severity level: Chat]
[Group: Sequence]
Request Version: HTTP/1.1
Response Code: 200
Date: Wed, 12 Jan 2011 13:02:45 GMT\r\n
Set-Cookie: B=cti5hkh6ir9jl&b=3&s=i5; expires=Tue, 12-Jan-2013 20:00:00 GMT; path=/; domain=.yahoo.co.jp\r\n
P3P: policyref="http://privacy.yahoo.co.jp/w3c/p3p.xml", CP="CAO DSP COR CUR ADM DEV TAI PSA PSD IVAi IVDi CONi TELo OTPi OUR DELi SAMi OTRi UNRi PUBi IND PHY ONL UNI PUR FIN COM NAV INT DEM CNT STA POL HEA PRE GOV"\r\n
Cache-Control: no-cache, private\r\n
Cache-Control: no-store, must-revalidate\r\n
Vary: User-Agent\r\n
Expires: -1\r\n
Pragma: no-cache\r\n
X-XRDS-Location: http://open.login.yahoo.co.jp/openid20/www.yahoo.co.jp/xrds\r\n
Cache-Control: private\r\n
Connection: close\r\n
Transfer-Encoding: chunked\r\n
Content-Type: text/html; charset=utf-8\r\n
Content-Encoding: gzip\r\n
\r\n
HTTP chunked response
Data chunk (26947 octets)
Chunk size: 26947 octets
Data (26947 bytes)
~~~省略~~~
[Length: 26947]
Chunk boundary
End of chunked encoding
Chunk size: 0 octets
Chunk boundary
Content-encoded entity body (gzip): 26947 bytes -> 96222 bytes
Line-based text data: text/html
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">\n <html lang="ja">\n <head>\n <meta http-equiv="content-type" content="text/html; charset=utf-8">\n <meta http-equiv="content-style-type" content="text/css">\n<br /><meta http-equiv="content-script-type" content="text/javascript">\n [truncated] <meta name="description" content="\346\227\245\346\234\254\346\234\200\345\244\247\347\264\232\343\201\256\343\203\235\343\203\274\343\202\277\343\203\253\343\202\265\343\202\244\343\203\210\343\200\202\346\244\234\347\264\242\ <title>Yahoo! JAPAN</title>\n ~~~省略~~~
---
また、pcapファイル37パケット目から新たなセッションを張り、javascriptをダウンロードしています。
実際に、キャプチャ内のURIフィールド(http://www.yahoo.co.jp/javascript/fp_base_bd_ga_5.0.5.js)にブラウザでアクセスすると、java-scriptのファイルをダウンロードできます。
■キーワード
httpパケットフォーマット, TCPシーケンス
■環境
OS：Windows7(32bit) on VMWare(R) Player 3.1.3, ブラウザ：IE8
192.168.11.3のPCから、yahooのHP(www.yahoo.co.jp)にアクセス
■pcapファイル
ここからダウンロード
■解説
★pcapファイルの6パケット目
HTTP GET のパケット。
webサーバのコンテンツのダウンロードを要求する。具体的には
www.yahoo.co.jp/index.html
のファイルを要求する。
---↓キャプチャ(L2,L3,L4部分は省略。http部分のみ)---
Hypertext Transfer Protocol
GET / HTTP/1.1\r\n
[Expert Info (Chat/Sequence): GET / HTTP/1.1\r\n]
[Message: GET / HTTP/1.1\r\n]
[Severity level: Chat]
[Group: Sequence]
Request Method: GET
Request URI: /
Request Version: HTTP/1.1
Accept: */*\r\n
Accept-Language: ja\r\n
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0)\r\n
Accept-Encoding: gzip, deflate\r\n
Host: www.yahoo.co.jp\r\n
Connection: Keep-Alive\r\n
\r\n
---
キャプチャを見るとindx.htmlは明示的には要求していないことが分かる。通常はURI: /index.htmlなどのファイル名が記載されているが、このパケットキャプチャを見ると、URI: /となっている。このように、取得すべきファイルが明記されていないhttpパケットをwebサーバが受け取ると、サーバ側であらかじめ指定されているファイルを自動的に返す。サーバで設定されているファイルは、index.htmlだけでなく、index.htm, index.phpなどがよく使われる。
★pcapファイルの7パケット目
TCP 80番ポートからの通信でindex.htmlの内容を含むhttpフォーマットを受信している。
---↓キャプチャ(L2,L3,L7部分は省略。TCP部分のみ)---
Transmission Control Protocol, Src Port: http (80), Dst Port: 49188 (49188), Seq: 1, Ack: 297, Len: 1414
Source port: http (80)
Destination port: 49188 (49188)
[Stream index: 1]
Sequence number: 1 (relative sequence number)
[Next sequence number: 1415 (relative sequence number)]
Acknowledgement number: 297 (relative ack number)
Header length: 20 bytes
Flags: 0x10 (ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgement: Set
.... 0... = Push: Not set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 66458 (scaled)
Checksum: 0x86ad [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
[SEQ/ACK analysis]
[This is an ACK to the segment in frame: 6]
[The RTT to ACK the segment was: 0.024742000 seconds]
[Number of bytes in flight: 1414]
TCP segment data (1414 bytes)
---
スロースタートにより、2〜5(pcapファイルの7〜10)のパケットを送信した後、クライアントからのACKを待ちます。
★pcapファイルの11パケット目
クライアントからのACK。
---↓キャプチャ(L2,L3部分は省略。TCP部分のみ)---
Transmission Control Protocol, Src Port: 49188 (49188), Dst Port: http (80), Seq: 297, Ack: 5657, Len: 0
Source port: 49188 (49188)
Destination port: http (80)
[Stream index: 1]
Sequence number: 297 (relative sequence number)
Acknowledgement number: 5657 (relative ack number)
Header length: 20 bytes
Flags: 0x10 (ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgement: Set
.... 0... = Push: Not set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 65700 (scaled)
Checksum: 0x8b8f [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
[SEQ/ACK analysis]
[This is an ACK to the segment in frame: 10]
[The RTT to ACK the segment was: 0.000045000 seconds]
---
受け取った後にさらに5パケットを送っています。pcapファイルの32パケット目でダウンロード終了。
ちなみに、pcapファイルの7〜32パケット目のクライアントからのACKを除くデータ部分を結合すると、以下のhttpフォーマットが出てきます。
---
Hypertext Transfer Protocol
HTTP/1.1 200 OK\r\n
[Expert Info (Chat/Sequence): HTTP/1.1 200 OK\r\n]
[Message: HTTP/1.1 200 OK\r\n]
[Severity level: Chat]
[Group: Sequence]
Request Version: HTTP/1.1
Response Code: 200
Date: Wed, 12 Jan 2011 13:02:45 GMT\r\n
Set-Cookie: B=cti5hkh6ir9jl&b=3&s=i5; expires=Tue, 12-Jan-2013 20:00:00 GMT; path=/; domain=.yahoo.co.jp\r\n
P3P: policyref="http://privacy.yahoo.co.jp/w3c/p3p.xml", CP="CAO DSP COR CUR ADM DEV TAI PSA PSD IVAi IVDi CONi TELo OTPi OUR DELi SAMi OTRi UNRi PUBi IND PHY ONL UNI PUR FIN COM NAV INT DEM CNT STA POL HEA PRE GOV"\r\n
Cache-Control: no-cache, private\r\n
Cache-Control: no-store, must-revalidate\r\n
Vary: User-Agent\r\n
Expires: -1\r\n
Pragma: no-cache\r\n
X-XRDS-Location: http://open.login.yahoo.co.jp/openid20/www.yahoo.co.jp/xrds\r\n
Cache-Control: private\r\n
Connection: close\r\n
Transfer-Encoding: chunked\r\n
Content-Type: text/html; charset=utf-8\r\n
Content-Encoding: gzip\r\n
\r\n
HTTP chunked response
Data chunk (26947 octets)
Chunk size: 26947 octets
Data (26947 bytes)
~~~省略~~~
[Length: 26947]
Chunk boundary
End of chunked encoding
Chunk size: 0 octets
Chunk boundary
Content-encoded entity body (gzip): 26947 bytes -> 96222 bytes
Line-based text data: text/html
---
また、pcapファイル37パケット目から新たなセッションを張り、javascriptをダウンロードしています。
実際に、キャプチャ内のURIフィールド(http://www.yahoo.co.jp/javascript/fp_base_bd_ga_5.0.5.js)にブラウザでアクセスすると、java-scriptのファイルをダウンロードできます。
インターネット通信パケットキャプチャ2(TCP)
パソコンがインターネットと通信する際のパケットキャプチャをとってみた。
■キーワード
TCPシーケンス
■環境
OS：Windows7(32bit) on VMWare(R) Player 3.1.3, ブラウザ：IE8
192.168.11.3のPCから、yahooのHP(www.yahoo.co.jp)にアクセス
■pcapファイル
ここからダウンロード
■解説
★1パケット目（pcapファイルの3パケット目）
PCからyahooのwebサーバへのTCPセッション確立の打診をする
(いわゆるsynパケット)
---↓キャプチャ(L2,L3部分は省略。TCP部分のみ)---
Transmission Control Protocol, Src Port: 49188 (49188), Dst Port: http (80), Seq: 0, Len: 0
Source port: 49188 (49188)
Destination port: http (80)
[Stream index: 1]
Sequence number: 0 (relative sequence number)
Header length: 32 bytes
Flags: 0x02 (SYN)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...0 .... = Acknowledgement: Not set
.... 0... = Push: Not set
.... .0.. = Reset: Not set
.... ..1. = Syn: Set
[Expert Info (Chat/Sequence): Connection establish request (SYN): server port http]
[Message: Connection establish request (SYN): server port http]
[Severity level: Chat]
[Group: Sequence]
.... ...0 = Fin: Not set
Window size: 8192
Checksum: 0x8b9b [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
Options: (12 bytes)
Maximum segment size: 1460 bytes
NOP
Window scale: 2 (multiply by 4)
NOP
NOP
SACK permitted
---
httpを使うから宛先ポートは80。flagのところにsynが立ってる。これはPC⇒YahooWebサーバへのセッションに関するsynってこと。
また、オプションフィールドですが、これは主に最初のセッション確立(syn, syn/ack)のみに使われるフィールドです。
・Maximum segment size (=MSS)
1パケット当たりのL5〜L7の部分のデータサイズを決める。windowsではデフォルトで1460。理由は以下計算式。
1518(Ethernet最大フレームサイズ)
- 18(Ethernetヘッダサイズ)
- 20(IPヘッダサイズ)
- 20(TCP/UDPヘッダサイズ)
= 1460
併せて、MTU値は1500(MTUはIPヘッダ込みのサイズ)となっている。
でもBフレッツ等ではMTUが1454だったりするので、cisco等のルータでは通常、ip tcp adjust-mss 1414コマンド等により、TCPセッション確立時にこのオプションフィールドのMSSを1414に書き換え、TCP通信に関してはMTU1454で効率的な通信ができるようにする。
MSS=1460の場合、たいていのhttp通信では、IPヘッダにdfビットが立っているため、Webサーバからのhtml等のコンテンツダウンロード中に、MTUが1500以下の経路があるNW機器でパケットがいったん破棄され、同時にICMP destination unreachable Code4が(最大MTU値を含めて)Webサーバに返される。それを受け取ったwebサーバはMSS値を適切な値に変更して通信を再開する。
・Window scale
パケット中にWindow size = 8192 とありますが、このフィールドの最大値は65536。しかし昨今の回線高速化により、効率性を考える際にこの最大値では物足りないことがある。そこでフィールドの拡張としてこのWindow scaleというものが追加された。この値がXのとき、2のX乗(今回はX=2なので4)倍のサイズとなる。
すなわち、Windows sizeは 8192×4 = 32768 Byte となる。
・SACK Permitted
Selective ACK のことらしい。つまり、ACKはWindowサイズごとに返されるが、Windowサイズがでかい場合特に、そのサイズ内で1,2個エラーがあった場合、送り手はもっかいそのWindowサイズ分送らなければならないのは効率が悪い。てことで、受信側は、正しく受け取れたものをリスト化して送信側に提出しましょうってこと。
この機能を有効にするオプション。
★2パケット目（pcapファイルの4パケット目）
PCからyahooのwebサーバへのTCPセッション確立を了承し、かつ
yahooのwebサーバからPCへのTCPセッション確立を打診をする
(いわゆるsyn/ackパケット)
---↓キャプチャ(L2,L3部分は省略。TCP部分のみ)---
Transmission Control Protocol, Src Port: http (80), Dst Port: 49188 (49188), Seq: 0, Ack: 1, Len: 0
Source port: http (80)
Destination port: 49188 (49188)
[Stream index: 1]
Sequence number: 0 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 32 bytes
Flags: 0x12 (SYN, ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgement: Set
.... 0... = Push: Not set
.... .0.. = Reset: Not set
.... ..1. = Syn: Set
[Expert Info (Chat/Sequence): Connection establish acknowledge (SYN+ACK): server port http]
[Message: Connection establish acknowledge (SYN+ACK): server port http]
[Severity level: Chat]
[Group: Sequence]
.... ...0 = Fin: Not set
Window size: 65535
Checksum: 0xa973 [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
Options: (12 bytes)
Maximum segment size: 1460 bytes
NOP
Window scale: 1 (multiply by 2)
SACK permitted
EOL
[SEQ/ACK analysis]
[This is an ACK to the segment in frame: 3]
[The RTT to ACK the segment was: 0.012407000 seconds]
---
回線はBフレッツだけど、安いルータなのでMSS値は1460のままで返ってきてる。
pcapファイルを見てもらうと分かるとおり、httpでのダウンロードの際は1454のMTUサイズで通信されている。
★3パケット目（pcapファイルの5パケット目）
yahooのwebサーバからPCへのTCPセッション確立を了承する
(いわゆるackパケット)
---↓キャプチャ(L2,L3部分は省略。TCP部分のみ)---
Transmission Control Protocol, Src Port: 49188 (49188), Dst Port: http (80), Seq: 1, Ack: 1, Len: 0
Source port: 49188 (49188)
Destination port: http (80)
[Stream index: 1]
Sequence number: 1 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x10 (ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgement: Set
.... 0... = Push: Not set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 65700 (scaled)
Checksum: 0x8b8f [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
[SEQ/ACK analysis]
[This is an ACK to the segment in frame: 4]
[The RTT to ACK the segment was: 0.000043000 seconds]
---
オプションフィールドは無し。
次回はhttpについて。
■キーワード
TCPシーケンス
■環境
OS：Windows7(32bit) on VMWare(R) Player 3.1.3, ブラウザ：IE8
192.168.11.3のPCから、yahooのHP(www.yahoo.co.jp)にアクセス
■pcapファイル
ここからダウンロード
■解説
★1パケット目（pcapファイルの3パケット目）
PCからyahooのwebサーバへのTCPセッション確立の打診をする
(いわゆるsynパケット)
---↓キャプチャ(L2,L3部分は省略。TCP部分のみ)---
Transmission Control Protocol, Src Port: 49188 (49188), Dst Port: http (80), Seq: 0, Len: 0
Source port: 49188 (49188)
Destination port: http (80)
[Stream index: 1]
Sequence number: 0 (relative sequence number)
Header length: 32 bytes
Flags: 0x02 (SYN)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...0 .... = Acknowledgement: Not set
.... 0... = Push: Not set
.... .0.. = Reset: Not set
.... ..1. = Syn: Set
[Expert Info (Chat/Sequence): Connection establish request (SYN): server port http]
[Message: Connection establish request (SYN): server port http]
[Severity level: Chat]
[Group: Sequence]
.... ...0 = Fin: Not set
Window size: 8192
Checksum: 0x8b9b [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
Options: (12 bytes)
Maximum segment size: 1460 bytes
NOP
Window scale: 2 (multiply by 4)
NOP
NOP
SACK permitted
---
httpを使うから宛先ポートは80。flagのところにsynが立ってる。これはPC⇒YahooWebサーバへのセッションに関するsynってこと。
また、オプションフィールドですが、これは主に最初のセッション確立(syn, syn/ack)のみに使われるフィールドです。
・Maximum segment size (=MSS)
1パケット当たりのL5〜L7の部分のデータサイズを決める。windowsではデフォルトで1460。理由は以下計算式。
1518(Ethernet最大フレームサイズ)
- 18(Ethernetヘッダサイズ)
- 20(IPヘッダサイズ)
- 20(TCP/UDPヘッダサイズ)
= 1460
併せて、MTU値は1500(MTUはIPヘッダ込みのサイズ)となっている。
でもBフレッツ等ではMTUが1454だったりするので、cisco等のルータでは通常、ip tcp adjust-mss 1414コマンド等により、TCPセッション確立時にこのオプションフィールドのMSSを1414に書き換え、TCP通信に関してはMTU1454で効率的な通信ができるようにする。
MSS=1460の場合、たいていのhttp通信では、IPヘッダにdfビットが立っているため、Webサーバからのhtml等のコンテンツダウンロード中に、MTUが1500以下の経路があるNW機器でパケットがいったん破棄され、同時にICMP destination unreachable Code4が(最大MTU値を含めて)Webサーバに返される。それを受け取ったwebサーバはMSS値を適切な値に変更して通信を再開する。
・Window scale
パケット中にWindow size = 8192 とありますが、このフィールドの最大値は65536。しかし昨今の回線高速化により、効率性を考える際にこの最大値では物足りないことがある。そこでフィールドの拡張としてこのWindow scaleというものが追加された。この値がXのとき、2のX乗(今回はX=2なので4)倍のサイズとなる。
すなわち、Windows sizeは 8192×4 = 32768 Byte となる。
・SACK Permitted
Selective ACK のことらしい。つまり、ACKはWindowサイズごとに返されるが、Windowサイズがでかい場合特に、そのサイズ内で1,2個エラーがあった場合、送り手はもっかいそのWindowサイズ分送らなければならないのは効率が悪い。てことで、受信側は、正しく受け取れたものをリスト化して送信側に提出しましょうってこと。
この機能を有効にするオプション。
★2パケット目（pcapファイルの4パケット目）
PCからyahooのwebサーバへのTCPセッション確立を了承し、かつ
yahooのwebサーバからPCへのTCPセッション確立を打診をする
(いわゆるsyn/ackパケット)
---↓キャプチャ(L2,L3部分は省略。TCP部分のみ)---
Transmission Control Protocol, Src Port: http (80), Dst Port: 49188 (49188), Seq: 0, Ack: 1, Len: 0
Source port: http (80)
Destination port: 49188 (49188)
[Stream index: 1]
Sequence number: 0 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 32 bytes
Flags: 0x12 (SYN, ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgement: Set
.... 0... = Push: Not set
.... .0.. = Reset: Not set
.... ..1. = Syn: Set
[Expert Info (Chat/Sequence): Connection establish acknowledge (SYN+ACK): server port http]
[Message: Connection establish acknowledge (SYN+ACK): server port http]
[Severity level: Chat]
[Group: Sequence]
.... ...0 = Fin: Not set
Window size: 65535
Checksum: 0xa973 [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
Options: (12 bytes)
Maximum segment size: 1460 bytes
NOP
Window scale: 1 (multiply by 2)
SACK permitted
EOL
[SEQ/ACK analysis]
[This is an ACK to the segment in frame: 3]
[The RTT to ACK the segment was: 0.012407000 seconds]
---
回線はBフレッツだけど、安いルータなのでMSS値は1460のままで返ってきてる。
pcapファイルを見てもらうと分かるとおり、httpでのダウンロードの際は1454のMTUサイズで通信されている。
★3パケット目（pcapファイルの5パケット目）
yahooのwebサーバからPCへのTCPセッション確立を了承する
(いわゆるackパケット)
---↓キャプチャ(L2,L3部分は省略。TCP部分のみ)---
Transmission Control Protocol, Src Port: 49188 (49188), Dst Port: http (80), Seq: 1, Ack: 1, Len: 0
Source port: 49188 (49188)
Destination port: http (80)
[Stream index: 1]
Sequence number: 1 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x10 (ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgement: Set
.... 0... = Push: Not set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 65700 (scaled)
Checksum: 0x8b8f [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
[SEQ/ACK analysis]
[This is an ACK to the segment in frame: 4]
[The RTT to ACK the segment was: 0.000043000 seconds]
---
オプションフィールドは無し。
次回はhttpについて。
インターネット通信パケットキャプチャ1(DNS)
パソコンがインターネットと通信する際のパケットキャプチャをとってみた。
■キーワード
TCPシーケンス, DNSパケットフォーマット, httpパケットフォーマット
■環境
OS：Windows7(32bit) on VMWare(R) Player 3.1.3, ブラウザ：IE8
192.168.11.3のPCから、yahooのHP(www.yahoo.co.jp)にアクセス
■pcapファイル
ここからダウンロード
■解説
★1パケット目
DNSサーバにwww.yahoo.co.jpのAレコードを問い合わせ
---↓キャプチャ(L2〜L4部分は省略。DNS部分のみ)---
Domain Name System (query)
[Response In: 2]
Transaction ID: 0xfa21
Flags: 0x0100 (Standard query)
0... .... .... .... = Response: Message is a query
.000 0... .... .... = Opcode: Standard query (0)
.... ..0. .... .... = Truncated: Message is not truncated
.... ...1 .... .... = Recursion desired: Do query recursively
.... .... .0.. .... = Z: reserved (0)
.... .... ...0 .... = Non-authenticated data OK: Non-authenticated data is unacceptable
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 0
Queries
www.yahoo.co.jp: type A, class IN
Name: www.yahoo.co.jp
Type: A (Host address)
Class: IN (0x0001)
---
Recursion desiredにフラグが立ってる。フラグが立ったDNS requestを受けると、再帰的に上位のDNSサーバに聞いて回るようになる。フラグが立ってないDNS reqeustを受け取ると、知らない場合は"知らないよ"もしくは"このDNSサーバが知ってるよ"とだけ返す(それ以上は自分では探さない)。
クライアント⇔DNSサーバのDNSパケットはRecursion disiredが1, DNSサーバ間のDNSパケットは0になるのが一般的。
★2パケット目
DNSサーバからの返答
---↓キャプチャ(L2〜L4部分は省略。DNS部分のみ)---
Domain Name System (response)
[Request In: 1]
[Time: 0.008945000 seconds]
Transaction ID: 0xfa21
Flags: 0x8180 (Standard query response, No error)
1... .... .... .... = Response: Message is a response
.000 0... .... .... = Opcode: Standard query (0)
.... .0.. .... .... = Authoritative: Server is not an authority for domain
.... ..0. .... .... = Truncated: Message is not truncated
.... ...1 .... .... = Recursion desired: Do query recursively
.... .... 1... .... = Recursion available: Server can do recursive queries
.... .... .0.. .... = Z: reserved (0)
.... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server
.... .... .... 0000 = Reply code: No error (0)
Questions: 1
Answer RRs: 2
Authority RRs: 3
Additional RRs: 3
Queries
www.yahoo.co.jp: type A, class IN
Name: www.yahoo.co.jp
Type: A (Host address)
Class: IN (0x0001)
Answers
www.yahoo.co.jp: type CNAME, class IN, cname www.ya.gl.yahoo.co.jp
Name: www.yahoo.co.jp
Type: CNAME (Canonical name for an alias)
Class: IN (0x0001)
Time to live: 1 minute, 23 seconds
Data length: 12
Primary name: www.ya.gl.yahoo.co.jp
www.ya.gl.yahoo.co.jp: type A, class IN, addr 203.216.243.240
Name: www.ya.gl.yahoo.co.jp
Type: A (Host address)
Class: IN (0x0001)
Time to live: 23 seconds
Data length: 4
Addr: 203.216.243.240
Authoritative nameservers
gl.yahoo.co.jp: type NS, class IN, ns gns02.net.bbt.yahoo.co.jp
Name: gl.yahoo.co.jp
Type: NS (Authoritative name server)
Class: IN (0x0001)
Time to live: 1 minute, 22 seconds
Data length: 16
Name server: gns02.net.bbt.yahoo.co.jp
gl.yahoo.co.jp: type NS, class IN, ns gns01.net.djm.yahoo.co.jp
Name: gl.yahoo.co.jp
Type: NS (Authoritative name server)
Class: IN (0x0001)
Time to live: 1 minute, 22 seconds
Data length: 16
Name server: gns01.net.djm.yahoo.co.jp
gl.yahoo.co.jp: type NS, class IN, ns gns01.net.bbt.yahoo.co.jp
Name: gl.yahoo.co.jp
Type: NS (Authoritative name server)
Class: IN (0x0001)
Time to live: 1 minute, 22 seconds
Data length: 8
Name server: gns01.net.bbt.yahoo.co.jp
Additional records
gns01.net.bbt.yahoo.co.jp: type A, class IN, addr 202.93.64.132
Name: gns01.net.bbt.yahoo.co.jp
Type: A (Host address)
Class: IN (0x0001)
Time to live: 11 minutes, 12 seconds
Data length: 4
Addr: 202.93.64.132
gns01.net.djm.yahoo.co.jp: type A, class IN, addr 124.83.159.36
Name: gns01.net.djm.yahoo.co.jp
Type: A (Host address)
Class: IN (0x0001)
Time to live: 6 minutes, 47 seconds
Data length: 4
Addr: 124.83.159.36
gns02.net.bbt.yahoo.co.jp: type A, class IN, addr 202.93.64.133
Name: gns02.net.bbt.yahoo.co.jp
Type: A (Host address)
Class: IN (0x0001)
Time to live: 6 minutes, 17 seconds
Data length: 4
Addr: 202.93.64.133
---
AnswerのところにAレコードがあるが、それだけじゃなくてAuthoritative nameserversのところにNSレコード、Additional RecordsのところにNSレコードのホスト名に対するAレコードもついてくる。
次回はTCPについて。
■キーワード
TCPシーケンス, DNSパケットフォーマット, httpパケットフォーマット
■環境
OS：Windows7(32bit) on VMWare(R) Player 3.1.3, ブラウザ：IE8
192.168.11.3のPCから、yahooのHP(www.yahoo.co.jp)にアクセス
■pcapファイル
ここからダウンロード
■解説
★1パケット目
DNSサーバにwww.yahoo.co.jpのAレコードを問い合わせ
---↓キャプチャ(L2〜L4部分は省略。DNS部分のみ)---
Domain Name System (query)
[Response In: 2]
Transaction ID: 0xfa21
Flags: 0x0100 (Standard query)
0... .... .... .... = Response: Message is a query
.000 0... .... .... = Opcode: Standard query (0)
.... ..0. .... .... = Truncated: Message is not truncated
.... ...1 .... .... = Recursion desired: Do query recursively
.... .... .0.. .... = Z: reserved (0)
.... .... ...0 .... = Non-authenticated data OK: Non-authenticated data is unacceptable
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 0
Queries
www.yahoo.co.jp: type A, class IN
Name: www.yahoo.co.jp
Type: A (Host address)
Class: IN (0x0001)
---
Recursion desiredにフラグが立ってる。フラグが立ったDNS requestを受けると、再帰的に上位のDNSサーバに聞いて回るようになる。フラグが立ってないDNS reqeustを受け取ると、知らない場合は"知らないよ"もしくは"このDNSサーバが知ってるよ"とだけ返す(それ以上は自分では探さない)。
クライアント⇔DNSサーバのDNSパケットはRecursion disiredが1, DNSサーバ間のDNSパケットは0になるのが一般的。
★2パケット目
DNSサーバからの返答
---↓キャプチャ(L2〜L4部分は省略。DNS部分のみ)---
Domain Name System (response)
[Request In: 1]
[Time: 0.008945000 seconds]
Transaction ID: 0xfa21
Flags: 0x8180 (Standard query response, No error)
1... .... .... .... = Response: Message is a response
.000 0... .... .... = Opcode: Standard query (0)
.... .0.. .... .... = Authoritative: Server is not an authority for domain
.... ..0. .... .... = Truncated: Message is not truncated
.... ...1 .... .... = Recursion desired: Do query recursively
.... .... 1... .... = Recursion available: Server can do recursive queries
.... .... .0.. .... = Z: reserved (0)
.... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server
.... .... .... 0000 = Reply code: No error (0)
Questions: 1
Answer RRs: 2
Authority RRs: 3
Additional RRs: 3
Queries
www.yahoo.co.jp: type A, class IN
Name: www.yahoo.co.jp
Type: A (Host address)
Class: IN (0x0001)
Answers
www.yahoo.co.jp: type CNAME, class IN, cname www.ya.gl.yahoo.co.jp
Name: www.yahoo.co.jp
Type: CNAME (Canonical name for an alias)
Class: IN (0x0001)
Time to live: 1 minute, 23 seconds
Data length: 12
Primary name: www.ya.gl.yahoo.co.jp
www.ya.gl.yahoo.co.jp: type A, class IN, addr 203.216.243.240
Name: www.ya.gl.yahoo.co.jp
Type: A (Host address)
Class: IN (0x0001)
Time to live: 23 seconds
Data length: 4
Addr: 203.216.243.240
Authoritative nameservers
gl.yahoo.co.jp: type NS, class IN, ns gns02.net.bbt.yahoo.co.jp
Name: gl.yahoo.co.jp
Type: NS (Authoritative name server)
Class: IN (0x0001)
Time to live: 1 minute, 22 seconds
Data length: 16
Name server: gns02.net.bbt.yahoo.co.jp
gl.yahoo.co.jp: type NS, class IN, ns gns01.net.djm.yahoo.co.jp
Name: gl.yahoo.co.jp
Type: NS (Authoritative name server)
Class: IN (0x0001)
Time to live: 1 minute, 22 seconds
Data length: 16
Name server: gns01.net.djm.yahoo.co.jp
gl.yahoo.co.jp: type NS, class IN, ns gns01.net.bbt.yahoo.co.jp
Name: gl.yahoo.co.jp
Type: NS (Authoritative name server)
Class: IN (0x0001)
Time to live: 1 minute, 22 seconds
Data length: 8
Name server: gns01.net.bbt.yahoo.co.jp
Additional records
gns01.net.bbt.yahoo.co.jp: type A, class IN, addr 202.93.64.132
Name: gns01.net.bbt.yahoo.co.jp
Type: A (Host address)
Class: IN (0x0001)
Time to live: 11 minutes, 12 seconds
Data length: 4
Addr: 202.93.64.132
gns01.net.djm.yahoo.co.jp: type A, class IN, addr 124.83.159.36
Name: gns01.net.djm.yahoo.co.jp
Type: A (Host address)
Class: IN (0x0001)
Time to live: 6 minutes, 47 seconds
Data length: 4
Addr: 124.83.159.36
gns02.net.bbt.yahoo.co.jp: type A, class IN, addr 202.93.64.133
Name: gns02.net.bbt.yahoo.co.jp
Type: A (Host address)
Class: IN (0x0001)
Time to live: 6 minutes, 17 seconds
Data length: 4
Addr: 202.93.64.133
---
AnswerのところにAレコードがあるが、それだけじゃなくてAuthoritative nameserversのところにNSレコード、Additional RecordsのところにNSレコードのホスト名に対するAレコードもついてくる。
次回はTCPについて。
NTP
NTPについてどうもよく分からないので調べてみた。
■ハードウェアクロックとは？ソフトウェアクロックとは？
Linuxでは、ハードウェアクロックとソフトウェアクロック（システムクロック）に分かれている。
ソフトウェアクロックは、主にタイムスタンプ等OSが制御する際に利用するクロック。OSが管理するので電源が切れるとリセットされ、OS起動時にハードウェアクロックを参照して設定される。
一方、ハードウェアクロックは、LSIについているクロックで、電源が切れても時を刻む。OS起動時以外では利用されないクロック。
んで、Ciscoも同じように分かれていて、config上では
ソフトウェアクロック = clock
ハードウェアクロック = calendar
と区別しているよう。
EX.
・ソフトウェアクロックの設定
#clock set 9:00:00 25 Oct 2009
・ハードウェアクロックの設定
#calendar set 9:00:00 25 Oct 2009
んで、NTPで調整するのはソフトウェアクロックの方。
ハードウェアクロックを定期的に更新するには
(config)#ntp update-calendar
を使う。
■UTC GMTについて
GMT = イギリスのグリニッジ天文台で観測される太陽の周期を元に計算される世界標準時間
UTC = 原子時計により計算される時間を元に計算される世界標準時間
最近はUTCが使われることがほとんどのようで、GMTと書いててもUTCを利用しているようです。（Windows OSもそうらしい）
NTPはUTCを使います。
以上。
■ハードウェアクロックとは？ソフトウェアクロックとは？
Linuxでは、ハードウェアクロックとソフトウェアクロック（システムクロック）に分かれている。
ソフトウェアクロックは、主にタイムスタンプ等OSが制御する際に利用するクロック。OSが管理するので電源が切れるとリセットされ、OS起動時にハードウェアクロックを参照して設定される。
一方、ハードウェアクロックは、LSIについているクロックで、電源が切れても時を刻む。OS起動時以外では利用されないクロック。
んで、Ciscoも同じように分かれていて、config上では
ソフトウェアクロック = clock
ハードウェアクロック = calendar
と区別しているよう。
EX.
・ソフトウェアクロックの設定
#clock set 9:00:00 25 Oct 2009
・ハードウェアクロックの設定
#calendar set 9:00:00 25 Oct 2009
んで、NTPで調整するのはソフトウェアクロックの方。
ハードウェアクロックを定期的に更新するには
(config)#ntp update-calendar
を使う。
■UTC GMTについて
GMT = イギリスのグリニッジ天文台で観測される太陽の周期を元に計算される世界標準時間
UTC = 原子時計により計算される時間を元に計算される世界標準時間
最近はUTCが使われることがほとんどのようで、GMTと書いててもUTCを利用しているようです。（Windows OSもそうらしい）
NTPはUTCを使います。
以上。
