TCP协议格式和特点

文章目录

1.协议格式：
2.协议特性：
- 2.1 面向链接
- - 2.1.1三次握手建立连接
  - 2.1.1四次挥手断开连接
  - 相关问题和知识点：
  - - 1. 握手为啥三次，挥手是四次？
    - 2. 三次握手失败两端是如何处理的？
    - 3. SYN泛洪攻击是怎么回事?
    - 4. 一台主机上出现了大量CLOSE_WAIT状态链接是什么原因？
    - 5. TIME_WAIT状态有什么作用？
    - 6. 一台主机上出现大量TIME_WAIT链接，什么原因，怎么解决？
    - 7. TCP的保活机制（心跳探测）
- 2.2 可靠传输
- - 2.2.1 安全有序传输(保证数据可靠到达对端并且有序进行交付)
  - - 1. 确认应答机制
    - 2. 超时重传机制
    - 3. 协议字段中的序号(th_seq)和确认序号(th_ack)进行包序管理，实现有序交付
    - 4. 协议字段中的校验和校验数据一致性。
  - 2.2.2 避免没必要的丢包
  - - 1. 滑动窗口机制
    - 2. 拥塞窗口机制
  - 2.2.3 提高一些传输性能
  - - 1. 确认序号
    - 2. 快速重传协议
    - 3. 捎带应答机制：
    - 4. 延迟应答机制
    - 5. 延迟发送机制
- 2.3 面向字节流传输
3 对应用层编程影响
- 问题:tcp和udp协议的区别？
- tcp如何实现可靠传输
- udp如何实现可靠传输

TCP ：传输控制协议

1.协议格式：

16位源端端口-16位对端端口：描述通信两端
32位序号-32位确认序号：用于实现包序管理。
4位报头长度：描述tcp报头长度。4位表示最大数字15；以四字节为单位，所以TCp报头最小长度20字节，最大为15 * 4 = 60字节。
6位保留

6位标志位:

     URG: 紧急指针是否有效ACK: 确认应答PSH: 提示接收端应用程序立刻从TCP缓冲区把数据读走RST: 对方要求重新建立连接; 我们把携带RST标识的称为复位报文段SYN: 请求建立连接; 我们把携带SYN标识的称为同步报文段FIN: 通知对方, 本端要关闭了, 我们称携带FIN标识的为结束报文段

16位窗口大小：用于实现滑动窗口机制–进行发送数据的流量控制。防止缓冲区溢出丢包。
16为校验和：校验数据一致性。
16位紧急指针：发送的带外数据的位置
0-40字节选项数据：存储一些可能需要的额外的信息。Mss…
应用数据

2.协议特性：

2.1 面向链接

面向链接：通信双方建立连接之后才能进行通信，—>确保通信双方都据有数据收发能力

TCP的链接管理：三次握手建立链接，四次挥手断开链接。
主要是为了确认通信双方都在线有数据收发能力。

2.1.1三次握手建立连接

客户端向服务端请求建立连接:

2.1.1四次挥手断开连接

2.2 可靠传输

2.2.1 安全有序传输(保证数据可靠到达对端并且有序进行交付)

面向链接（前提）：首先确保双方都具有数据收发能力

1. 确认应答机制

实现丢包检测功能，接收方针对接收的每一条数据都应该进行确认回复。
发送方收到确认回复认为传输成功，否则认为数据丢包。

2. 超时重传机制

发送方等待超时没有得到确认回复，则会对数据包重新传输。超时等待时长会随着网络环境的不同, 是有差异的.如果超时时间设的太长, 会影响整体的重传效率;如果超时时间设的太短, 有可能会频繁发送重复的包;

3. 协议字段中的序号(th_seq)和确认序号(th_ack)进行包序管理，实现有序交付

利用==协议字段中的序号(th_seq)和确认序号(th_ack)==进行包序管理，实现有序交付。

举个例子感受一下序号(th_seq)和确认序号(th_ack)的作用，下图中seq为其实序号，ack表示确认序号。

4. 协议字段中的校验和校验数据一致性。

数据不一致则丢弃，丢弃则无针对此数据的确认回复，对方收不到确认回复则重传此数据；也可直接发送重传请求。

2.2.2 避免没必要的丢包

丢包情况：

发送方发送数据过多，接收方来不及处理，缓冲区溢出之后所产生的丢包。
2.>传输起始或者过程中网络突然变差所导致的大量丢包。

1. 滑动窗口机制

依赖于协议字段中的窗口大小字段实现，避免发送方发送数据过多，接收方来不及处理，缓冲区溢出之后所产生的丢包。
原理：接收方接收数据之后就会进行确认应答，这时候会通过窗口大小字段告诉对方最多再给自己发送多少数据。窗口大小不能大于接收缓冲区剩余空间大小。
实现：通信双方都会维护一个发送窗口和接收窗口。
图画不动了，参考文章：网络滑动窗口机制，这个里面有比较图解，过程较详细。

2. 拥塞窗口机制

拥塞窗口机制：解决网络突然变差产生大量丢包的问题。
原理：发送方维护了一个拥塞窗口，用于限制当前所能发送的数据量。拥塞窗口大小是一种慢启动快增长（指数上涨，阈值为窗口大小）的形式进行传输控制。防止突然网络变差，导致大量丢包。每次丢包都会进行一次网络状况探测的过程。

2.2.3 提高一些传输性能

tcp为了实现可靠传输，牺牲了传输性能，而在传输过程中，有些性能上的损失是没有必要的。

1. 确认序号

确认序号标识序号之前的数据都已经收到了，为了避免因为确认应答丢失导致的重传。

2. 快速重传协议

在传输过程中，若接收方接收到的数据并非是接收窗口后沿数据，则有理由认为前边发送的数据丢失了，这时候每收到一条数据就会发送一条后沿数据的重传请求，一旦发送方连续收到三条（三条是为了避免数据延迟到达的情况）相同重传请求，则直接对这条数据（确认序号的数据）进行重传。丢包后不用完全等待超时重传，节省时间。

3. 捎带应答机制：

接收方对接收到的每一条数据都需要进行确认回复，然而确认回复最主要的信息就是确认序号，因此每一条确认回复都是一个tcp传输，至少是一个空报头（没有实际数据）的传输。如果收到数据后刚好要给对方发送数据，则将及即将要发送的数据和确认回复放到一起进行发送（在要发送的数据报头中加入确认序号）。

4. 延迟应答机制

接收方对接收到的每一条数据都需要进行确认回复，其中包含有当前窗口大小字段，如果立即进行回复，窗口大概率是不断减小的，因此延迟进行确认回复，有可能上层将数据取出，维持窗口大小。通过这种方式保证传输吞吐量不会降低。

5. 延迟发送机制

tcp传输过程中，如果对每次send的数据直接封装报头进行发送，若发送的数据比较小，但是次数较多，则io次数比较多，效率低。因此延迟发送，将数据在发送缓冲区中先堆积起来，再合适的时候一次性发送，减少了io次数，提高效率。
nagle算法–通过套接字选项设置(默认是开启的)

2.3 面向字节流传输

面向字节流传输：可靠的，有序的，双向的，基于连接的，以字节为单位的传输方式。传输时，并不限制上层（send \ recv）发送或者接收的数据大小。tcp延迟发送数据在缓冲区中积攒，基于mss取出合适大小数据进行发送。
优势：相对于面向数据报来说，传输更加灵活。
缺陷：产生粘包问题—将多条数据当作一条数据处理。
产生粘包的原因：tcp不会对数据进行边界处理。
解决方案：程序员需要在应用层进行数据的边界管理。可用特殊字符作为间隔(需要考虑特殊字符转译)；使用TLV格式数据（在应用层头部加入数据长度）；数据定长----提前约定会定长的数据，但是数据太短需要进行补全；

3 对应用层编程影响

连接断开：recv返回0，send触发异常。
recv一旦返回0，就要考虑文件描述符的回收关闭
Send因为会触发一次导致进程退出，若不想退出进程需要自定义信号处理。
tcp传输存在粘包问题，需要在应用层进行数据边界管理。udp整条交付，无粘包问题。

问题:tcp和udp协议的区别？

实现上的区别：协议格式，协议字段不一样。
特性上的区别：TCp是面向连接的可靠的字节流传输方式。udp是无连接不可靠面向数据报的传输方式。udp支持广播,tcp不支持。
应用场景上的区别：UDP适用于实时性高于安全性的场景，tcp用于传输安全性高于实时性的场景。

tcp如何实现可靠传输

确认应答机制
超时重传机制
协议字段中的序号(th_seq)和确认序号(th_ack)进行包序管理，实现有序交付
协议字段中的校验和校验数据一致性。

udp如何实现可靠传输

ud协议本身没有实现可靠传输，需要在应用层手动实现类似tcp的可靠传输机制：确认应答机制，超时重传机制，包序管理。