要約：
この記事では、TCPコネクションの確立と解放のプロセスを分析するためのHTTPパケットをつかんで、パケットトレーサツール適切に構成されたネットワークパラメータを使用する方法について説明します。
1.個人情報
- 名前：黄魯迅
- 学生ID：201821121104
- クラス：1814計算
2.ネットワークトポロジの確立
上記のように、図のネットワークトポロジーは、ネットワークトポロジはPC（PC0）、ルータおよびサーバ（Server0）の合計で構成され、そのうちの3つが接続されています。
3.設定パラメータ
- クライアントのIPアドレスです
192.168.1.104 - サーバーのIPアドレスです
192.168.1.105 -
ルータの設定パラメータ：
•ルータ>有効
•ルータ＃設定トン
-
Fa0 / 0インターフェイスを設定します：
•R（設定）#interface f0を/ 0
•R（設定-IF）#ipのアドレス192.168.1.105 255.255.255.0
•R（設定-IF）#NOシャットダウン
-
コンフィギュレーションのFa0 / 1インターフェイス。
•R（設定）#interfaceのF0 / 1
•R（設定-IF）#ipのアドレス192.168.2.105 255.255.255.0
•R（設定-IF）#NOシャットダウン
入力ルータの設定には、show ipインターフェイスの簡単なを完了した後、以下のように設定が、正しいことを確認してください。
4.キャプチャ、TCPコネクションの確立を分析
Webブラウザの下でオープンエンドデスクトップPC、サーバーのIPアドレスを入力します。192.168.2.104は、キャプチャを開始します。下図のように：
次のようにメッセージをクロール：
TCPパケット： 
HTTPメッセージ：
図のレッスンで与えられたTCPパケットのヘッダフォーマットで：
我々は、TCPコネクションの分析を確立することができます。
（1）TCP接続の概略図を描きます
下図のように：
（2）番号と確認応答番号の変更を
両者の分析、すなわち、スリーウェイハンドシェイク・パケット3つの交換用のTCPセグメントに対応する3つの図形番号：
- 首先由PC端创建传输控制模块TCB。然后向Server发送连接请求报文端，这时候首部中的SYN同步位=1，同时该报文段不能携带数据，故seq=0(x)，ack=0(x)，TCP客户进程进入SYN_SENT状态。
- 然后Server接受到请求报文段后，进行回复确认。在确认报文段中把SYN位和ACK位置为1，并把ack值+1(x+1)变为1。
- 然后PC端再次确认，ACK=1，ack值不变为1(x+1)，seq值+1变为1(x+1)。(SYN=1时，表明这是一个请求连接或接受连接报文）
（3）解答：为什么连接建立需要第三次握手
主要是为了防止以及PC失效的连接请求报文段突然又传送到了Server，因而产生错误（Server的许多资源会被失效的连接端口所浪费）
5.分析TCP连接释放
TCP连接释放抓取到的报文如下：
三部分报文分别如下：
同上诉分析TCP连接建立，我们先画出分析图：
从TCP报文段中我们可以看到只有三次交换过程：
- PC端发出连接释放请求，置ACK,FIN均为1，此时seq=103(即u=103）
- Server端收到连接释放请求后，置ACK，FIN为1，将seq=472(即v=472),ack=u+1=103+1=104
- PC端在收到Server发出的来连接释放报文后，对此发出确认。在确认报文段中置ACK为1，ack=w+1（不得而知），seq=u+1=103+1=104。
6.通过该实验产生的新的疑问
实际上，完成了整个实验，实现了TCP连接建立与释放之后，能够发现TCP的连接建立过程与课本中描述的完全相同。但是在完成实验的拓展——TCP连接释放的时候，像上文所述，它的报文交换只有3次，与课本的四报文握手并不一致，其中的一些数据也是不尽相同的。在完成的时候我做出假设是——Server端将第二次和第三次的报文握手过程整合到一个步骤了，这也就是上图中为何一个报文端有两个序号的原因（仅仅是我的大胆假设）。这样似乎能在一定程度上解释与课本不符的原因，但是还遗留了一个问题，在PC端的确认报文中ack=w+1，ack的值是无从得知的（因为并不知道w是之前哪个报文的值），从数据分析是得出了ack=v，也与课文不太一致。总之做完拓展后，我针对TCP连接的释放这方面的理论与实际产生了一定的困惑，希望老师看到能否解释一下？
2019-10-19 20:45:20