• 客户端的端口为57063，服务器端口为80；
• 客户端向服务器请求建立连接，发送其TCP数据报，数据方向 57063 -> 80；
• 数据报中，SYN=1，是一个建立连接的信号；ACK=0，没有开启序号确认；
• 客户端的Sequence number为一个随机值x=1926459878，其上面一行为相对序号；Acknowledgment number ：0；

• 服务器收到请求，回复客户端，数据方向 80 -> 57063；
• SYN=1，服务器连接允许；
• ACK=1，客户端收到之后要验证（x+1）=Acknowledgment number；
• 服务器表示已经接收到x=1926459878，并说明下次要收到（x+1），即Acknowledgment number=1926459879；
• 服务器发送自己的Sequence number，也是一个随机值，y=980795485；

• 客户端验证 自己的Sequence number+1=1926459879，和ACK=1；
• 若验证成功，向服务器发送数据报，数据方向 57063 -> 80；
• 数据报中，SYN=0，表明最后的确认；
• ACK=1，服务器收到报之后要验证，验证值（y+1）=980795486=Acknowledgment number；
• 客户端回复服务器期望值Sequence number=（x+1）=1926459879；
• 服务器收到报之后，确认 自己的Sequence number+1=980795486，ACK=1；
• 若验证成功，则一次TCP连接建立，可以通信了。

• 图中，客户端的IP地址为：192.168.99.30；服务器的地址为：154.8.190.35。
• 一次TCP连接断开以后，再次连接同一个服务器需要重新握手连接，并且重新分配端口号。
• 下面对图中第一次断开进行分析，第一个FIN前，客户端向服务器发了最后一个包。
• 包中，Sequence number=1392，Acknowledgment number=607（为了方便均取相对值）。

• 客户端申请断开连接，向服务器发送数据报；
• FIN=0，客户端表明自己没有数据要发了，申请断开连接；
• ACK=1，服务器收到包之后要验证Acknowledgment number；
• Sequence number=1392，因为上一个包Seq=1392，Len=0；
• Acknowledgment number=607，因为上一个Ack=607，期间又没有收到服务器的数据；

• 服务器回复客户端；
• 第二次挥手是服务器告诉客户端我收到了你要断开的请求，但我可能还有数据没发完，你等我后面通知，FIN=0；
• 第三次挥手是服务器也完成了数据传送，告知客户端我也完事了，FIN=1；
• 图中客户端申请断开时、恰好服务器也没有数据要发，于是第二、三次挥手的包合并了。
• 服务器收到包，验证ACK=1，自己要发的下一个包的序号=607；
• 验证成功，答复客户端：
• Sequence number=607；
• Acknowledgment number=1393，ACK=1；表明客户端收到之后也要验证要发的下一个包序为1393；
• FIN=0。

• 客户端收到包，验证ACK=1，自己要发的下一个包序=1393；
• 验证成功，答复服务器：
• Sequence number=1393；
• Acknowledgment number=608，ACK=1；表示服务器收到之后要验证自己下一个包序=608；
• FIN=0；
• 客户端发送完等待一段时间后关闭；
• 服务器收到包验证ACK=1、下一个包序=608，验证成功，服务器关闭。

- End -

近期课程上新：

Windows服务安全 | 以太网交换与路由技术 | Linux安全运维 | Web安全 | 灰帽编程 | 渗透测试  | 安全化概述与虚拟化 | 跨站脚本攻击