环境介绍：
1、客户端访问FTP服务器进行下载文件，由于FTP是基于TCP协议进行工作的，所以客户端在访问FTP服务器时必然会进行建立TCP连接。
2、通过在交换机上对任意端口进行抓包，来分析TCP的传输数据时报文交互的过程，以及TCP的窗口机制凸显的现象。
一、TCP数据报文交互
为什么说TCP协议可靠的？
其中一项就是因为TCP协议在传输数据的过程对，会对接收到的TCP数据进行一个确认。
当对方发来一个Seq报文序号2、并承载100Byte的TCP数据，我成功收到且FCS检查无误之后，回复Flags-ACK置位1、ack序号=(收到的Seq+收到的数据大小)=4+100=104TCP报文进行确认。对方收到Seq为104的报文，就知道了我成功接收到了100Byte的数据。
简述TCP数据报文交互过程：
- 客户端请求下载文件之后，建立起传输的TCP连接。
- 连接建立之后，服务器告知客户端：请求文件的大小以及发送的方式、编码等。随后基于TCP连接发送FTP-DATA。 FTP-DATA为什么是两个包？因为在TCP建立的时候知道MSS=1460(传输最大文件大小限制)，而下载的index.html文件大小为1649Byte，需要分成1460+189两个FTP-DATA包进行传输
- 收到FTP-DATA之后，客户端向服务器回复ACK确认：ack=1651。 FTP-DATA(1)报文信息：seq=1，ack=1，Len=1460FTP-DATA(2)报文信息：seq=1461，ack=1，len=189两个包都收到之后，检查无误，最后一个包的seq=1461、数据大小lene=189，所以回复的ACK报文中，ack序号=1461+189=1651.
抓包信息：
（1）总体信息
（2）FTP-DATA(1)
（3）FTP-DATA(2)
（4）FTP回复的ACK
华为官网教材截图（HCIA-02 网络参考模型）：
为什么PC1所发的Ack字段没有增长？
TCP成功建立之后，回复的TCP报文ackp字段只会将收到的报文中seq字段与Data字段大小进行相加成为ack字段的新值。
即：ack=seq+data，如果收到的TCP报文中data(载荷)=0，即ack=seq，也就是图中ack=seq=b+1的原因。
二、TCP窗口机制
TCP通过滑动窗口机制来控制数据的传输速率，保障数据传输时不会因为其中一端传输太快导致数据丢失。
在TCP三次握手建立连接时，双方都会通过Window（win）字段告诉对方本端最大能够接受的字节数（也就是缓冲区大小，单位Byte）。
TCP窗口机制如何进行工作的？
- 连接建立成功之后，发送方会根据接受方宣告的Window大小发送相应字节数的数据。
- 接受方 接受到数据之后会放在缓冲区内，等待上层应用来取走缓冲的数据。若数据被上层取走，则相应的缓冲空间将被释放。
- 接收方 根据自身的缓存空间大小，在回复TCP报文时更新窗口大小( Window )。
- 发送方 根据接收方回复的窗口大小，实时更改发送相应数量的数据。
TCP窗口机制对数据交互有什么影响？
- 教程中常常看到的数据交互都是发一个数据包就回复一个确认，这种主要为了让我们好理解，现实中如果需要实现这种一个数据报文就回复一个确认，就需要使用到TCP报文中的PSH字段。
- 如果网络中都是这样一包一回复，大量不必要的数据报文在网络中传输，易造成网络负载较重，使得传输效率降低。
- 窗口机制有个特点就是不断的接收数据放置在缓冲区中，直到缓冲区被占用满或者遇到PSH置位的TCP报文，才会进行数据转发，以及回复ACK进行数据确认。这样统一的回复有效减少了大量确认数据在网络中传输。
TCP中的PSH字段作用？
- 通过TCP报头中的PSH字段 控制服务器缓冲区内的数据立即传送出去。
- 什么时候用到PSH字段呢？
- 对于需要紧急处理的指令数据，需要快速的进行转发处理，就需要应用到PSH。
- 如：数据交互实例中的客户端下载index.html文件，需要紧急执行下载，如果等待send buffer（缓冲区）满了再转发，客户端看来就是等了很久才开始进行下载/传输文件。
华为官网教材截图（HCIA-02 网络参考模型）：
注：图中的win=3，表示可接收的数据包为3个。在实际环境中，该字段通常表示目前可接受处理的数据大小，单位Byte。
为什么PC1所发报文的Win字段没有变化？
因为win表示的是本端目前所能接收的数据窗口大小，即目前可处理的数据量大小。自己发送的数据并不会占用win窗口量。
为什么PC1所发报文的Win字段没有变化？
因为win表示的是本端目前所能接收的数据窗口大小，即目前可处理的数据量大小。自己发送的数据并不会占用win窗口量。
