TCP包协议格式
SYN—为1表示这是连接请求或是连接接受请求,用于创建连接和使顺序号同步
ACK—为1表示确认号字段有效
TCP协议三次握手流程主要就是 SYN 和ACK字段。
服务器开始属于监听 状态。
1、 客户端发送连接请求。SYN置为1. 序列号 为1234
2、 服务器收到请求。ACK置为1, 确认号码就是收到的包序列号+1. 1234 + 1 = 1235 。然后发送给客户端。
3、 客户端收到服务端,然后确认号码为 ACK+1. 1235 + 1 = 1236. 发送给客户端。
四次挥手
抓包分析
123 包是三次握手
4567是数据传输确认
8、9、 10、11是四次挥手。
注意:客户端和服务端都可以主动发起挥手。
- 第一次握手+第二次握手
Flags:只有syn为1. 源端口是系统分配。目标端口是固定的12346 seq也是操作系统自己分配。
服务端和客户端自己的序列号是不一样的。
-
第三次握手
-
客户端开始发送实际的应用数据
-
服务端确认 收到消息
疑问。为啥这里的确认号不是客户端序列号+1了
4010677602 -> 4010677616
-
服务端给客户端发送消息
发现 服务端发送的俩个 包序列号和确认号一致 -
客户端回复确认收到消息
-
服务端准备断开连接开始挥手。第一次挥手
FIN置为1 -
客户端确认收到服务端要断开的连接。
-
客户端也告诉服务端,要断开连接,
-
服务端确认收到客户端断开连接。并确认
服务器收到ACK应答报文段后,服务器就进入CLOSE(关闭)状态
客户端处于TIME_WAIT状态时,此时的TCP还未释放掉,需要等待2MSL后,客户端才进入CLOSE状态。
表格展示
功能 | 发送方 | 接收方 | 序列号 | 确认号 | Flag |
---|---|---|---|---|---|
握手1 | client | server | 4010677601 | 0 | SYN |
握手2 | server | client | 3905876082 | 4010677602 | SYN,ACK |
握手3 | client | server | 4010677602 | 3905876083 | ACK |
客户端发送消息 | client | server | 4010677602 | 3905876083 | ACK,PUSH |
服务端确认收到消息 | server | client | 3905876083 | 4010677616 | ACK |
服务端发送消息 | server | client | 3905876083 | 4010677616 | ACK,PUSH |
客户端确认收到消息 | client | server | 4010677616 | 3905876097 | ACK |
服务端确认并开始请求断开 | server | client | 3905876097 | 4010677616 | ACK,FIN |
客户端收到断开的请求,确认 | client | server | 4010677616 | 3905876098 | ACK |
客户端页请求断开 | client | server | 4010677616 | 3905876098 | ACK,FIN |
服务端收到客户端断开的请求,确认 | server | client | 3905876098 | 4010677617 | ACK |
希望得到的 ACK 是自己上次的SEQ+data的数据长度字节数。 4010677602 +14(Hello, Server!) = 4010677616
标签:UDP,ACK,IP,确认,TCP,server,client,服务端,客户端 From: https://www.cnblogs.com/clllll/p/18092252