3-way handshake

　　　

TCP/IPの通信
�@	TCPコネクションを確立しようとする「WinXPPC」は、SYN フラグを立てて接続要求を行います。 　　 　　通信確立の最初は、Aｃｋ番号は [ 0 ]、Seq番号は[ 0 ] となります。※Seq初期値は適当な値。
�A	SYNフラグを受信した 「 MSN WWW Server 」 は、ACKフラグを立てて接続要求に応えます。 　　 　　今度は 「 MSN WWW Server 」 もSYNフラグを立てて 「 WinXPPC 」 に接続要求を行うので 　　 　　適当に割当てたSeq番号[ 0 ]とAck番号[ 1 ] ( Seq番号 + 1 ) を「WinXPPC」に送信します。 　　 　　※MSS1460と1380を通知し合った結果、小さい方が採用されるのでMSSは1380となります。
�B	SYNフラグを受信した「 WinXPPC 」も同様に、ACKフラグを立て接続要求に対して応えます。 　　 　　「 WinXPPC 」はSeq番号[ 1 ] ( = 受信ACK番号 ) とACK番号[ 1 ]( = 受信Seq 番号＋1 ） 　　 　　を 「 MSN WWWServer 」へ送信します。�@〜�Bの流れがTCPの [ 3-way handshake ] です。
�C	�Bの後に、「 MSN WWW Server 」 からSeq番号やACK番号をまだ受信していないことから 　　 　　再び( Seq 1/Ack1 ) にて1313byte（Len1313) のデータ送信と同時にHTTPのGETをします。 　　 　　※ この ( Len 1313 ) はHTTPのデータで、こちらのOS、ブラウザ、表示言語、Cookie等です。
�D	続いて、�Cに対するAckを返しています。
�E	ここでようやく「 MSN WWW Server 」がブラウザで表示するHTMLソースのデータを送信します。 　　 　　データは 互いに取り決めた MSS1380 ずつ、RWIN の値になるまで[ACK を返さず]送信します。 　　 　　Seq 番号は、相手から受信した Ack番号を使用することから Seq 番号 [ 1 ] となり、 　　 　　Ack 番号は、相手から受信した Seq番号+LENを使用するので、ACK番号[ 1314 ]となります。
�F	「WinXPPC」からACKを受け取っていないのに、なぜ[ Seq1381 ]に変化しているのでしょうか。 　　 　　例えば 「 WinXPPC 」の RWIN が 1381 なら、�Dを受信した後にACKを返す必要がありますが、 　　 　　RWINは [ 32120 ] なのでACKをまだ返す必要がありません。つまりLenが累積した結果です。 　　 　　�Dを受信した時に 「 WinXPPC 」 がACKを返していたら、「 MSN WWW Server 」 に対して、 　　 　　「 Seq 1314/Ack 1381/Len 0 」 の ACK を返していると仮定して考えれば分かると思います。
�G	�Eで1380、�Fで80の計1460byteのデータを受信し終えたWinXPはようやくAckを返します。続く・・・

4年前のキャプチャーでは、YahooのWWWサーバを対象にTCP/IP通信のやりとりを説明しましたが
今のYahooサーバでキャプチャーすると少し例外的なシーケンスのやりとりを行うので、SeqとAckの
やりとりが、どこの参考書にでも書かれているような一番標準的であったMSNのWWWサーバを対象
にキャプチャーを行いその結果を解説しました。上記解説はTCP/IP通信の理解のベースにできます。




　　 　Win98のブラウザ(IE5)で http://www.yahoo.co.jp/ にPPPoEでアクセスした結果 ( 4年前 )


　　　

TCP/IPの通信 ( 4年前のキャプチャーデータのFeedback )
�@	TCPコネクションを確立しようとする「Win98PC」は、SYN フラグを立てて接続要求を行います。 　　 　　通信確立の最初は、Aｃｋ番号は [ 0 ]、Seq番号は適当に割り当てられるので [ 10 ] とします。
�A	SYNフラグを受信した 「 YahooWWW Server 」 は、ACKフラグを立てて接続要求に応えます。 　　 　　今度は 「 YahooWWW Server 」 もSYN フラグを立てて 「 Win98PC 」 に接続要求を行うので 　　 　　適当に割当てたSeq番号[ 100 ]とAck番号[ 11 ] ( Seq番号 + 1 ) を「Win98PC」に送信します。
�B	SYNフラグを受信した「 Win98PC 」も同様に、ACKフラグを立て接続要求に対して応えます。 　　 　　「 Win98PC 」はSeq番号[ 11 ] ( = 受信ACK番号 ) とACK番号[ 101 ]( =受信Seq 番号＋1 ） 　　 　　を 「 YahooWWWServer 」へ送信します。�@〜�Bの流れがTCPの [ 3-way handshake ] です。
�C	�Bの後に、「 Yahoo WWW Server 」 からSeq番号やACK番号をまだ受信していないことから 　　 　　再び( Seq11/Ack101 ) にて1000byte（Len1000) のデータ送信と同時にHTTPのGETをします。 　　 　　※ この ( Len 1000 ) はHTTPのデータで、こちらのOS、ブラウザ、表示言語、Cookie等です。
�D	ここでようやく「 YahooWWWServer 」がブラウザで表示するHTMLソースのデータを送信します。 　　 　　データは 互いに取り決めた MSS1414 ずつ、RWIN の値になるまで[ACK を返さず]送信します。 　　 　　Seq 番号は、相手から受信した Ack番号を使用することから Seq 番号 [ 101 ] となり、 　　 　　Ack 番号は、相手から受信した Seq番号+LEN を使用するので、ACK番号[ 1011 ]となります。
�E	「Win98PC」からACKを受け取っていないのに、なぜ[ Seq1515 ]に変化しているのでしょうか。 　　 　　例えば 「 Win98PC 」の RWIN が 1414 なら、�Dを受信した後にACKを返す必要がありますが、 　　 　　RWIN は [ 8192 ] なので、ACKをまだ返す必要がありません。つまりLenが累積した結果です。 　　 　　�Dを受信した時に 「 Win98PC 」 がACKを返していたら、「 Yahoo WWW Server 」 に対して、 　　 　　「 Seq 1011/Ack 1515/Len 0 」 の ACK を返していると仮定して考えれば分かると思います。