TCP和UDP协议原理及理解2——TCP

一、UDP

有关UDP的介绍，请看上一篇博客，链接：UDP.

二、TCP协议

TCP全称为 “传输控制协议(Transmission Control Protocol”). 人如其名, 要对数据的传输进行一个详细的控制;

1、TCP协议段格式

6位标志位:

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

2、确认应答机制：

确认应答机制:接收方收到TCP段(TCP Segment)之后,有责任发送应答数据给发送方。
其中，应答数据中，有几个字段需要填写:

1. ASN =收到数据中的SN +收到数据中的len (留个备注,不准确)
2. ack标志位置1.
   

TCP将每个字节的数据都进行了编号，即为序列号.

• 32位序列号（SN）：发送数据的序列号
• 32位确认序列号（ASN）：希望发送方下次发送的数据编号
• ACK:是否确认应答标志

每一个ACK都带有对应的确认序列号, 意思是告诉发送者, 我已经收到了哪些数据; 下一次你从哪里开始发。

SN和ASN的计算：

SN和ASN的计算方式：ASN=SN+数据的长度

关于TCP Header中的SN和ASN如何进行填写(TCP 协议栈填写)?

3、超时重传机制：

超时重传机制：基于TCP协议实现，动态计算保温的最大生存时间（MSL），超时时间设置位2MSL.。如果在超时时间内没有收到发送数据的应答，就需要重新发送消息。

什么情况下没有收到对方应答呢？

• 1.数据因为校验和对不上，直接被丢弃了
• 2.数据因为网络.上中间的原因,就没有到达对方

对于以上两种情况没有收到应答，我们只需要重新发送即可（超时重传机制）

如果一直没有发送出去呢？
假如我们设置可以发送五次，但是五次都没有发送出去，就通知TCP协议栈的客户(应用层) ,数据发不过去了
————在Java代码中，会抛出一个异常

TCP的缓冲区：
由于需要超时重传，所以，发送后的数据，不能丟掉,需要保留到收到这份数据的应答为止。
TCP内部:发送的数据可能还需要重发,所以,不能扔掉,需要保留。需要有地方保留--------->TCP 内部有发送缓冲区

【注意】 为了达到可靠性，TCP实现了确认答应+超时重传机制

1. 前提:需要给所有数据编号(TCP Header中的SN)，SN的含义(发送的数据中第-一个字节的编号)
2. 确认应答,需要填写ack标志位,和ASN；ASN的含义，希望发送方发送的下一个字节
3. TCP Header中的三个字段(SN/ASN/ack 标志位)
4. 超时重传不需要分情况讨论，统-处理即可，重复数据，根据序列号可以去重
5. 超时时间的设置有什么思想
6. 多次重试，仍然失败，怎么办。
7. TCP有发送缓冲区。

4、连接管理机制

1）什么是连接？

两个进程需要接收发送数据，首先需要建立连接，在TCP协议栈内部会建立很多连接，如下图所示：

我们可以把这个TCP协议栈理解成一个快递公司，它为很多人服务，包裹通过TCP协议栈（快递公司）所建立的连接，邮递快递，直到发送到对方手里。
TCP协议栈里边存储着：下次发送的数据编号、发送缓冲区/接收缓冲区等等。

在TCP协议栈内部，通过不同的五元组来标识唯一的连接，即五元组是连接的唯一标识。

2）连接的生命周期

连接的阶段主要包含三个部分：

• 建立连接
• 正常通信
• 断开连接

3）连接管理——三次握手

三次握手本质是同步信息 ，具体过程见下图：

上图详细表述了三次握手状态的变化：

• 这三次握手过程在应用层是不可见的。
• 建立连接都是单方向的

情况一：只看TCP头部中的标志位，过程见下图所示：

情况二：只关注三次握手的状态变化，过程见下图所示：

情况三：只关注三次握手中的序号和确认序号（SN和ASN），过程见下图所示：

表达TCP三次握手的流程/过程？

1. 第一次： 首先客户端发送一个SYN请求到服务端。
2. 第二次： 服务端接受请求后，发送一个从客户端发送的SYN的ACK响应，并且发送一个从服务端到客户端的SYN请求（SYN和 ACK合并发给客户端），当客户端接收到以后，就相当于客户端到服务端之间的连接建立起来了。
3. 第三次： 这时候客户端还要回复服务端一个ACK的响应，当服务端接收到这个相应之后，相当于服务端到客户端之间的连接就建立起来了。

为什么TCP的建立连接过程是三次握手,而不是两次握手或者四次握手?

• 两次握手，就无法保证双方把数据都同步给对方了;
• 四次握手,发送的数据就浪费了。
• 但是可以四次握手：也就是第二次服务端接收到客户端的SYN请求后，服务端向客户端发送的SN和ACK可以分两次发送。

4）连接管理——四次挥手

四次挥手过程见下图所示：

CLOSED状态: 正确关闭socket后的状态。
CLOSE_ WAIT状态: 原因就是服务器没有正确的关闭 socket（应用层没有关闭，即没有调用close（）方法关闭）, 导致四次挥手没有正确完成；也就是服务端程序没有调用close方法,导致出现大量的连接处于CLOSE _WAIT状态，代表半关闭，是一种bug，只需要用户加上对应的 close方法。
TIME_WAIT状态:

1>为什么会有这个状态？
情况一： 在最后一次发送的ACK，对方可能没有收到（也就是对于被动关闭方：我发送了FIN,但是没有收到主动关闭方的ACK，这个时候就需要超时重传，再次发送FIN），所以需要保留一段时间（也就是处于TIME_WAIT状态）.
情况二： 另一个原因就是在很巧合的情况下，建立了两次连接，在第一次连接（老连接）中，数据超时重传了，也就是数据发送了两次，第一次的数据相当于找不到接收方，此刻也就是迷路了；然后在新连接建立之后，由于五元组信息是一样的，迷路的数据就在这时抵达了接收方。这就造成了把迷路的数据当作新连接的数据处理了。因此，在没有收到ACK的情况下需要等待一定的时间，也就是处于TIME_WAIT状态。见下图所示:

2>TIME_WAIT状态保留的时间是多少？为什么？

• 一般设定为2MSL;
• MSL(Maximum Segment Live): - 个TCP Segment在网络上的最大寿命。
• 2MSL -个来回的时间。
• TIME_ WAIT是2MSL：因为返回的ACK传输时间+服务端重新发送FIN的传输时间

3>TIME_WAIT状态的作用：

• 是为了防止最后一次ACK，对方没有收到。
• 将上一次建立连接的五元组保留一段时间再分配，否则会导致迷路数据问题。

4>主动关闭方最终的宿命都是TIME_ WAIT。

TCP四次挥手的过程?能否三次挥手?能否五次挥手?

• 不能三次，因为第二次ACK是系统内核实现的ACK响应, 而FIN是用户程序手动关闭，即：FIN和ACK不能同步发送。目的是让用户程序在关闭连接前处理需要的任务(如释放资源)
• 可以五次，第四次ACK响应报文可能丟包，导致服务端无法关闭连接,需要服务端重新发送FIN请求。

连接管理以及发送数据总过程:

5、滑动窗口----->发送端机制

• “滑动窗口”的概念，本质上就是根据对方的应答+接收能力，实时记录下一步的情况。
• 窗口大小：指的是无需等待确认应答（不需要等待Ack响应报文）而可以继续发送数据包的最值。
• 操作系统内核为了维护这个滑动窗口, 需要开辟 发送缓冲区 来记录当前还有哪些数据没有应答; 只有确认 应答过的数据才能从缓冲区删掉------》与确认应答和超时重传是相关的

1）那么如何知道对方的接受能力呢？

发送方把自己的接受能力填到TCP头中的16位窗口大小，发送给接收方，这个时候接受方就知道了发送方的接受能力大小。接收端同理。

2）滑动窗口模型：

“滑动窗口”机制：发送方， 发送缓冲区上的两个下标（滑动窗口左边界/右边界）来控制当前能发送的数据量。随着收到对方的应答ack之后,进行更新调整——不动或者向右划。
滑动窗口大小=右边界-左边界==接收能力
下面是滑动窗口的移动过程：

3）那么如果出现了丢包, 如何进行重传?

情况一：数据包已经抵达，ACK丢了

在ACK响应报文(处于接收端)中，携带下一个序号是多少—>表示在此序号之前的所有数据都已经接收到了，所以之前的ACK响应就算丢包也没关系。

情况二：数据包就直接丢了

• 当某一段报文段丢失之后, 发送端会一直收到 1001 这样的ACK, 就像是在提醒发送端 "我想要的是 1001"一样;
• 如果发送端主机连续三次收到了同样一个 “1001” 这样的应答, 就会将对应的数据 1001 - 2000 重新发送;----->这时不需要超时重传，直接重新发送（快重传）。
• 这个时候接收端收到了 1001 之后, 再次返回的ACK就是7001了(因为2001 - 7000)接收端其实之前就已经收到了, 被放到了接收端操作系统内核的接收缓冲区中;

接收缓冲区保存有响应ACK数据的信息，可以根据ACK丢包进行重发，这种机制被称为 “高速重发控制”(也叫 “快重传”)

那如果2000之后的数据从缓冲区被读取怎么办?
TCP协议栈保证有序传递给应用层的一没有收到 [1001, 2000)的数据之前，不允许应用层读取[2000, 4000)的数据。

那如果发送缓冲区满了怎末办?
首先，看一下Socket编程的代码：

我们知道Java中对数据读写都是通过流来实现的。os.write()方法会发生阻塞，当发送缓冲区满了之后，需要等待发送缓冲区收到ack来清理数据。（也就是等待）。

6、流量控制 ------>接收端的机制

首先，发送量受到哪些因素影响呢？

因素	对应机制
接收方的接受能力	“流量控制”机制
网络情况的影响	“拥塞控制”机制

流量控制一一根据接收方能力， 控制发送量的机制。

• 接收端：通过TCP协议头中的“窗口大小”（此处不是滑动窗口中的，是TCP头部中的16位窗口大小）字段，告诉发送端应该发送数据的大小（也就是自己的接受能力）.
• 接收数据的能力是随时在变化的，因为随时有数据被读写出去。
• 接收端处理数据的速度是有限的. 如果发送端发的太快, 导致接收端的缓冲区被打满, 这个时候如果发送端继续发送, 就会造成丢包(接受区无法继续接收，就直接丢弃), 继而引起丢包重传等等一系列连锁反应.
  因此TCP支持根据接收端的处理能力, 来决定发送端的发送速度. 这个机制就叫做流量控制(Flow Control);

7、拥塞控制

拥塞控制：根据网络情况，进行发送量控制(发送量控制也是通过滑动窗口控制)
发送量受两个因素影响：

• 接收方能力大小----->流量控制
• 网络承载能力大小----->拥塞控制

发送量的大小= MIN(接收方能力,网络承载能力);
原理:拥塞窗口初始值设为1,以慢启动指数级增长的方式，达到一定阈值转变为线性增长的方式。见下图所示：

8、延迟应答机制和捎带应答机制

1）延迟应答机制：

原理: 接收到多个数据报时，不针对每条数据报响应ack,而是延迟一定时间，这样接收缓冲区数据很快被处理（一次响应多条数据）,可用空间就更大,返回的窗口大小字段就可以设置的更大，使网络吞吐量更大，传输效率更高。
延迟的依据: (1) 数量(2)时间
具体的数量和超时时间, 依操作系统不同也有差异; 一般数量取2, 超时时间取200ms;

2）捎带应答机制：

原理： 就是发送ACK响应的时候可以同时发送数据。

9、面向字节流

• 创建一个TCP的socket, 同时在内核中创建一个 发送缓冲区 和一个 接收缓冲区;
• 调用write时, 数据会先写入发送缓冲区中;如果发送的字节数太长, 会被拆分成多个TCP的数据包发出;如果发送的字节数太短, 就会先在缓冲区里等待, 等到缓冲区长度差不多了, 或者其他合适的时机发送出去;
• 接收数据的时候, 数据也是从网卡驱动程序到达内核的接收缓冲区;然后应用程序可以调用read从接收缓冲区拿数据;
• 另一方面, TCP的一个连接, 既有发送缓冲区, 也有接收缓冲区, 那么对于这一个连接, 既可以读数据, 也可以写数据. 这个概念叫做 全双工

10、粘包问题

• 首先，粘包问题中的 “包” , 是指的应用层的数据包。
• 在TCP的协议头中, 没有如同UDP一样的 “报文长度” 这样的字段, 但是有一个序号这样的字段。
• 站在传输层的角度, TCP是一个一个报文过来的. 按照序号排好序放在缓冲区中。
• 站在应用层的角度, 看到的只是一串连续的字节数据。

那么应用程序看到了这么一连串的字节数据, 就不知道从哪个部分开始到哪个部分, 是一个完整的应用层数据包。解决办法是什么？

答：明确两个包之间的边界(应用层用户程序中使用协议来进行数据的解析/格式化)，相当于自己程序中定义了一个应用层的协议（以换行符区分）。

UDP是不存在粘包问题的：

UDP本身是基于一个数据包进行发送的，数据报的长度也是在字段中包含的，所以UDP不会存在粘包，只有多个数据包才会存在粘包问题

11、TCP异常情况

首先先了解一下RST:
RST是TCP协议栈种的一个标志位，它是在发生异常情况时会向对方发送一个RST，表示该连接出现异常需要关闭。

TCP异常情况分为三种：

1>进程终止: 进程终止会释放文件描述符, 仍然可以发送FIN. 和正常关闭没有什么区别（正常的四次握手）
2>机器重启: 和进程终止的情况相同.

3>机器掉电/网线断开:
首先接收端认为连接还在：

• 一旦接收端有写入操作(就是接收端向发送端发消息), 接收端发现连接已经不在了, 就会进行reset（重置–>RST标志）；
• 即使没有写入操作（也就是一直等待发送端发消息）, TCP自己也内置了一个保活定时器, 会定期询问对方是否还在. 如果对方不在, 也会把连接释放.

三、Tcp机制总结

TCP安全机制:
(1)确认应答机制(2) 超时重传机制(3) 连接管理机制(4)流量控制(5) 拥塞控制
TCP性能机制:
(1)滑动窗口(2)延迟应答(3) 捎带应答

TCP/UDP对比:

我们说了TCP是可靠连接, 那么是不是TCP一定就优于UDP呢? TCP和UDP之间的优点和缺点, 不能简单, 绝对的进行比较

• TCP用于可靠传输的情况, 应用于文件传输, 重要状态更新等场景;
• UDP用于对高速传输和实时性要求较高的通信领域, 例如, 早期的QQ, 视频传输等. 另UDP可以用于广播;

归根结底, TCP和UDP都是程序员的工具, 什么时机用, 具体怎么用, 还是要根据具体的需求场景去判定.

用UDP实现可靠传输:

参考TCP的可靠性机制,UDP是在传输层的，我们可以在应用层实现类似的逻辑（安全+效率机制）;
例如:

• 引入序列号, 保证数据顺序;
• 引入确认应答, 确保对端收到了数据;
• 引入超时重传, 如果隔一段时间没有应答, 就重发数据;