clllll  

TCP介绍

是为了在不可靠的互联网络上提供可靠的端到端字节流而专门设计的一个传输协议
特点

  • 慢启动
    如果有一个tcp连接超时重传之后,将窗口设置为1.收到一个确认包之后,窗口值 指数增加
  • 拥塞控制
    窗口值到了一定的阈值,收到一个确认包之后。 窗口值 +1.线性增加。

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

无连接的传输。直接就可以发送数据。不需要握手。

源端口 目的端口 长度 校验和 UDP数据部分
长度包括 UDP的报头+数据部分。

IP

网络层协议。 IPv4 ipv6. 负责俩个主机之间的联系。

posted on 2024-03-24 12:18  llcl  阅读(19)  评论(0编辑  收藏  举报