TCPヘッダと3WHS

Windows の tracert は ICMP　tracert 1回につき送信3回
Linux や Cisco IOS では UDP

TCPポート
1024-49151　IANA登録済み
49152-　ダイナミック

TCPヘッダ
送信元ポートで16ビット　宛先ポートで16ビット
シーケンス番号で32ビット
確認応答番号で32ビット

データオフセット=ヘッダ長(*)が4ビット、予約(未使用)が6ビット、コントロールフラグ(URG、ACK、PSH、RST、SYN、FINの6ついずれか)で6ビット、ウインドウサイズで16ビット

*基礎から学ぶWindowsネットワーク：
第15回　信頼性のある通信を実現するTCPプロトコル（2） (2/3)
http://www.atmarkit.co.jp/ait/articles/0401/29/news080_2.html

チェックサムで16ビット、緊急ポインタで16ビット。
オプションとパディングが可変長。

TCPコネクションとシーケンス/Ack番号については、いろいろなWebコンテンツがあるが示される例が適切でない場合があるので、初心者が誤解しにくそうな図が描かれているところとして次に。

「スリーウェイハンドシェイク」の手順、わかっていますか？
http://ascii.jp/elem/000/000/619/619702/


ヘッダや3ウェイハンドシェイクの絵はそこそこいい一方で、マンガ部分は無用か。


実際の通信で示すなら

HTTPクライアント--------------------->Webサーバー

という並びで、まず3ウェイハンドシェイク

---------------- SYN=1 ACK=0  SEQ=0 ACK=0--------->
<------------ SYN=1 ACK=1  SEQ=0 ACK=1-------------
---------------- SYN=0 ACK=1  SEQ=1 ACK=1--------->

挨拶が終わったところでデータのやりとり、ここではHTTP GET


---------------- ACK=1 PSH=1 SEQ=1 ACK=1--------->

このとき、TCPセグメントのレングスは295。これに対してWebサーバー側から分割されたデータが

<------------ ACK=1 PSH=0  SEQ=1 ACK=296 (LEN=0)-------------
<------------ ACK=1 PSH=0  SEQ=1 ACK=296 (LEN=1460)-------------
<------------ ACK=1 PSH=0  SEQ=1461 ACK=296 (LEN=1460)-------------

送ったセグメントサイズ+1がネクストシーケンス番号=相手から送られてくるACK番号。

これをWebサーバー側から見ると次のクライアント側のパケット

---------------- ACK=1 PSH=0 SEQ=296 ACK=2921 (LEN=0)--------->

送ったセグメントサイズ=相手が受け取ったサイズである場合に+1がネクストシーケンス番号=相手から送られてくるACK番号。これによってデータの到達状況がわかる。

見方を変えれば、送ったはずのサイズ+1に満たないACKが返ってきたとき、送ったはずのデータの一部が未だ先方に届いていない状況であるとわかる、と。

<------------ ACK=1 PSH=0  SEQ=2921 ACK=296 (LEN=1460)-------------
<------------ ACK=1 PSH=0  SEQ=4381(2921+1460) ACK=296 (LEN=1460)-------------


---------------- ACK=1 PSH=0 SEQ=296 ACK=5841(4381+1460) (LEN=0)--------->

以下全容はこんな感じ。