TCP 1

确认应答

确认应答(ACK,Acknowledgment) 是一种通信机制:接收方收到数据后,向发送方发送一个确认信号,告诉对方"这份数据我已经收到了"

序号和确认序号

序号 : 给发送的数据的每一个字节编号、第一个字节就是该数据的序号

确认序号 : 收到的数据的最后一个字节的序号 + 1

(1 ~ 1000 : 数据的序号 )

超时重传

如果 主机1 在⼀个特定时间间隔内没有收到 主机 2 发来的确认应答,就会进⾏重发。如果发送方没有收到 ack 、发送方重新传输数据是需要一定的等待时间的、 超出等待时间就会重新传输数据。

如果发送方收到 ack 、说明数据发送成功。 发送方没有收到 ack 可能会有两种情况 :

  1. 可能是数据没发过去(数据丢包)

  2. 可能是 ack 没传回到发送方(ack 丢包)

    在第 2 种情况、数据就会重复发送。接收方的接收缓冲区会根据数据的序号进行去重、相同数据不会被重复接收

建立连接的三次握手

客户端和服务器通信前需要建立连接。客户端和服务器建立连接的流程就是"三次握手"。网络中的握手就是通信的时候,给对方传达一个不包含载荷(只有报头)的数据包。 通信双方需要通过 3 次这样的"握手数据"、才能建立连接

发送了 4 次 "握手数据" 、为什么是 3 次握手 ? 在应答的同时申请建立连接

  • 3 次握手有什么作用 ?
  1. 初步验证通信链路是不是通畅
  2. 验证通信双方的发送能力和接受能力是不是正常的
  3. 协商必要数据(序号的起始值)

断开连接的四次挥手

服务器和客户端在完成通信后,需要断开连接。服务器和客户端断开连接的过程就是"四次挥手" 。挥手和握手类似都是只有报头没有载荷

  • 4 次挥手 能不能变成 3 次挥手呢 ?
    一般是不能的。3 次握手的 ack 和 syn 都是 操作系统内核控制的、服务器收到客户端的 syn 操作系统就会立刻发送 ack 和 syn 、ack 和 syn 都是 相同时机发送的。而 4 次握手的 ack 也是在收到 客户端的 fin 后立刻发送、但是 fin 的返回时机是应用程序控制的、在应用程序(服务器)调用 Socket.close() 时才会向客户端发送 fin。
    发送时机不同 => 不能合并
相关推荐
GodSure09141 小时前
WorkBuddy上手指南
1024程序员节
greatonce1 小时前
巨益及核标杆案例|高端羽绒服饰品牌:账单自动化与智能核销实现T-1实时对账
1024程序员节
geovindu1 小时前
sql:SQL Pagination and Limiting Results using PorstgreSQL 18.0
大数据·数据仓库·sql·postgresql·数据库开发·数据库架构·1024程序员节
LCG米1 小时前
STM32 DMA 多通道链式传输实测:请求仲裁顺序错位根因、半满中断乒乓与高速并发搬运落地
stm32·单片机·嵌入式·1024程序员节
Shaoshing2 小时前
MySQL日志
1024程序员节
奇树谦2 小时前
朴素贝叶斯(Naive Bayes)详解
机器学习·1024程序员节
Liaiyang662 小时前
空圈容错·极限工程实战下篇——外部供给层怎么升维,内外层怎么联动
量子计算·脑机接口·1024程序员节·科学哲学·容错设计·系统思维·工程方法论
传奇开心果编程2 小时前
【Jetpack Compose娓娓道来】第26课:Repository模式与数据层设计——数据的唯一入口
android·移动开发·1024程序员节·jetpack compose·编程语言理论·编程框架·声明式ui
Lucis__2 小时前
Redis持久化机制解析
redis·缓存·操作系统·文件·非关系型数据库·1024程序员节