TCP运输连接管理（实验）

在Cisco Packet Tracer 下配置了一台主机和服务器，通过主机浏览器访问服务器上的资源，详细描述TCP的运输连接。运输连接有三个阶段：连接建立，数据传送，连接释放。

建立连接（三握手）

一.通过本机的浏览器向服务器发起请求

注：数据长度是24说明该请求报文段的总长度是24，因为请求报文段不携带数据，所以这24字节就是首部的长度（TCP报文段的首部是由20字节的固定首部和最长可达40字节的选项部分构成），这里是最大3字节的MSS容量（每个tcp报文段数据字段的最大长度）和1字节的填充，使用填充是为了是整个首部长度能被4字节整除。

来看一下要发送的数据的流向

1.数据到达运输层，封装成TCP报文段

sequence number(序号)：在一个tcp连接传送的字节流中的每一个字节都按顺序编号，起始序号必须在连接建立时设置，首部中的序号字段指的是本报文段所发送的数据的第一个字节的序号**。这里为0，实际中是个随机值**
acknowledgement number (确认号)：是期望收到对方下一个报文段的第一个数据字节的序号。这里为0.对本报文段没有意义，因为本报文段不是一个确认报文段
offset（数据偏移） ：指出tcp报文段的数据起始处离tcp报文段的起始处有多远，实际上指出了tcp报文段的首部长度。
reserved（保留）：为0，保留为今后使用
flags：占6位，表示六种不同的控制位，用来说明本报文段的性质。
URG
ACK：在建立连接后所有传送的报文段都必须把ack置为1
PSH：若发送方报文段置为1说明了两个应用进程进行交互式通信时，告诉接收方尽快交付接受应用进程，不必等待缓存满了再上交
RST
SYN:这里=1说明这是一个请求连接报文段
FIN

2.数据到达第三层网络层后，封装IP数据报

1. 源IP地址未指定。设备将其设置为该端口的IP地址。
2. 目的IP地址与源IP地址在同一子网。设备把下一跳设置为目的IP地址。
   3.到达第二层数据链路层，封装成以太网帧
   
3. 下一跳IP地址是一个单播地址。ARP进程在ARP表中查找它。
4. 下一跳IP地址在ARP表中。ARP进程设置帧的目的MAC地址为该IP地址在缓存中对应的MAC地址。
5. 设备将PDU封装到一个以太网帧中。
   4.到达第一层物理层
6. FastEthernet0发送帧。

二.服务器收到请求，并发送确认

来看一下接受到的数据的流向

数据到达第一层物理层

1. FastEthernet0接收帧。
   上传至第二层
2. 该帧的目的MAC地址与接收端口的MAC地址、广播地址、或者多播地址匹配。
3. 设备从一个以太网帧中解封出PDU。
   上传至第三层
4. 数据包的目的IP地址与设备的IP地址或广播地址匹配。设备解封该数据包。
   到达第二层，解析该报文段是tcp连接请求报文段
5. 设备在服务器端口80上接收到一个TCP SYN报文段。
6. Received 报文段信息： 序号 0，ACK号 0，数据长度 24。
7. TCP从TCP报文段首部中的最大报文段选项中获取到的MSS值为1460字节。
8. 连接请求被接受。
9. 设备设置连接状态为SYN_RECEIVED。

然后发送确认报文段，在运输层封装成TCP报文段

1. TCP可接受的最大窗口值为16384字节。
2. TCP添加“最大报文段容量MSS”选项到TCP SYN-ACK的首部，其值等于536字节。
3. 设备发送一个TCP SYN+ACK报文段。
4. Sent 报文段信息： 序号 0（这是服务器为自己选择的初始序号，实际是个随机值），ACK号 1（表明这是个确认报文段），数据长度 24。
   

三.客户端收到确认,状态为established，并向服务器回应 ，服务器收到确认，服务器端状态为established

客户端收到确认,状态为established

数据到达运输层后解封，知道这是一个tcp连接请求确认报文段

开始发送确认报文段

1. 设备发送一个TCP ACK报文段。
2. Sent 报文段信息： 序号 1（之前是0），ACK号 1（表明是对确认报文段的确认），数据长度 20。（因为前面发送请求是已经消耗一个序号，这里序号从1开始）
   

服务器收到确认，服务器端状态为established

数据传送

一.主机发送会话内容

二.服务器收到数据，解封TCP，并把资源响应客户端

1. 设备在与(IP地址192.168.0.1, 端口1045)的连接上接收到一个TCP PUSH+ACK报文段。（这里push=1，服务器尽快交付应用程序）
2. Received 报文段信息： 序号 1（之前发送的确认报文段不携带数据，也不消耗序号），ACK号 1（对之前收到的请求确认报文段又重复确认），数据长度 100。
3. TCP报文段具有所期望的对等序号。
4. TCP处理负载数据。
5. TCP重新组装所有数据段并传递给更高层。
   开始封装成TCP报文段响应客户端
6. Sent 报文段信息： 序号 1，ACK号 101，数据长度 471。
   

三.客户端收到响应

报文段首部序号字段为1，因为服务器之前发送确认报文段要消耗一个序号，当时为0且不携带数据。
确认号101，说明已收到100字节，并且希望客户端发送请求的下一个字节序号是101
数据长度表明该tcp报文段数据总长471个字节
此时可以开始会话。

释放连接

一.客户端先发送连接释放报文段（进入FIN-WAIT-1状态）给服务器

报文段序号为1：之前发送请求报文的序号为1 ，长度为100
确认号472：对收到的tcp响应报文段的确认，那个报文段序号为1，长度为471

二.服务器收到，然后主动发送一次释放请求（进入close_wait状态）

由上图可知，此时服务器没有数据要发送给主机了，进入最终确认状态（LASK_ACK）
与理论上有所不同：理论上，处于关闭等待（close_wait）的服务器还有数据要发送给主机。
现在处于最终确认状态的服务器还要发送tcp连接释放报文段

三.客户端接收（客户端关闭连接CLOSING状态），发送一个普通的确认报文段

closing状态，必须经过时间等待器设置的时间2MSL后才进入到closed状态
原因：1.保证客户端发送的最后一个ack确认报文段(这个确认报文段是对服务器发送的连接释放的确认)能够到达服务器。
若服务器没有收到确认，它就会超时重传这个释放报文段，而客户端就能在2MSL时间内收到并发出确认，同时重新启动2MSL计时器。
2.防止已失效的连接请求报文段出现在本连接。2MSL后，使本连接持续时间内所产生的的所有报文段从网络中消失，这样下一个新的连接中不会出现旧的连接请求报文段。

四.服务器只要收到确认，服务器关闭连接(进入closed状态)

服务器结束的时候要比客户端早。一段时间后，主机的tcp也会进入closed状态，那是tcp连接释放报文段才算真正结束！！！