【Linux】TCP协议简介

德拉库斯

已于 2023-08-25 10:55:30 修改

阅读量518

点赞数

分类专栏： linux 文章标签： linux 网络

于 2023-08-12 17:38:12 首次发布

本文链接：https://blog.csdn.net/qq_40376612/article/details/131635260

版权

linux 专栏收录该内容

31 篇文章 0 订阅

订阅专栏

TCP协议简介

TCP协议格式
面向连接
- 1.连接管理机制
- 2.包序管理
可靠传输
- 1.保证数据可靠到达对端
- 2.保证数据的传输效率
面向字节流
- TCP粘包问题
TCP和UDP的对比

TCP协议格式

在这里插入图片描述

16位源端口号和16位目的端口号：标识数据从哪个进程来，到哪个进程去；
32位序号：在包序管理中，发送消息方和接收消息方各自都维护了包的序号，要用包序来表示哪些数据包是收到的，哪些还未收到。
4位首部长度：表示TCP头部有多少个字节。
6位标志位：
URG：紧急指针是否有效
ACK：确认号是否有效
PSH：提示接收端立刻将数据从TCP缓冲区把数据读走
RST：对方要求重新建立连接
SYN：请求建立连接
FIN：通知对方，本端要关闭了
16位窗口大小：TCP有一个流量控制机制，对端会将自己的接收能力通过16位窗口大小告诉当前端，以便于当前端调整自己发送消息的流量大小
16位紧急指针：标识哪部分数据是紧急数据

面向连接

1.连接管理机制

三次握手
下图是三次握手的详细流程图，左端为客户端，也就是发起连接方，右端为服务端

两次握手为什么不行？
两次握手会导致服务端的状态不能从SYN_RCVD转换到ESTABLISHED状态，从而无法建立连接
四次挥手
下图为四次挥手的详细流程图，左端为主动断开连接方，右端为被动断开连接方，双方发送的数据包名称和双方的状态

三次挥手可以吗？五次挥手可以吗？

三次挥手可以，但是很少见，三次挥手存在于被动断开连接时，没有数据要继续发送，此时利用捎带应答机制，将FIN和ACK一起发送给主动断开连接方，会变成三次挥手。但是大部分情况下，被动断开连接方很少在主动断开连接方发起断开时就完全没有消息要发送的了，所以三次挥手可以，但是可能性很小。

五次挥手可以，但是没有必要，因为四次挥手足以将双方完全断开，五次就显得多余了

2.包序管理

对于TCP协议格式中的32位序号和32位确认序号标识的是发送方和接收方各自维护的包序号，对于有数据的TCP包来说，会将每个字节都进行编号，这个编号就是包序号，（除了TCP协议头部之外的数据称为纯有效载荷）有应用层数据的包称为TCP数据包，没有应用层数据的称为TCP协议包，而纯的ACK协议包是不消耗序号的。

可靠传输

1.保证数据可靠到达对端

有两个机制：确认应答机制和超时重传机制

确认应答机制：
当A给B机器发送了1000字节的数据之后，B必须要给A回复1001，表示B已经接收到了Ａ发送的1000个数据，这样就能确保数据是一定到达对端的。

超时重传机制：
当Ａ给Ｂ发送了1000个字节，Ｂ迟迟不回复给Ａ消息，表明可能Ａ发送的消息已经丢失了，那么Ａ就会重新给Ｂ发送消息，而这个超时时间是不固定的，它随着网络的情况和双方通信的情况而变化

2.保证数据的传输效率

保证数据传输效率可以从三个角度分析：
1.自身发送数据量
2.对方的接收能力
3.网络的转发能力

依据自身发送的数据量：滑动窗口机制
也就是说所有需要发送的数据如果为ｎ个窗口大小，当前设置4位窗口，将当前四位窗口中的数据发送到网络中，暂时不用确认，只有收到较先的确认数据之后，窗口才能向后移动，这样就能在同一时刻发送多个数据，而提高发送的数据量，唯一的缺点是需要将窗口内的数据暂时维护起来。
在这里插入图片描述