【Linux 网络 (五)】Tcp/Udp协议

一前言

 本篇文章将会介绍Tcp/Udp协议中的所有字段、以及确认应答、超时重发、连接管理、流量控制、拥塞控制、滑动窗口、快速重传、延迟应答、捎带应答相关面试高频考点！！

二、Udp协议

1）、Udp协议特点

 Udp是一种面向数据报，无连接、不可靠传输协议。Udp广泛应用于直播领域。

面向数据报解释：
 Udp报头中存在描述完整Udp报文长度字段（后面介绍），所以在内核将报头和有效载荷分离后，交给上层的就是一个完成报文！！并且不管应用层交给Udp多长的报文，Udp原样发送，既不才分也不合并。所以Udp面向数据报。
 
无连接解释：
 Udp协议通信只需要对端的ip和port即可通信，不需要建立连接。就好比寄快递，我只需要知道对方的地址就可以向对方邮寄东西了。
 
不可靠解释：
 首先需要明确的是，可靠和不可靠描述的是不同通信协议的特点，本身并不存在谁好谁坏！前面已经提到过Udp无连接，而Udp报文发送过程中可能会存在丢包问题。但对于Udp而言，Udp认为只要将数据交给网络层就发送成功，对于网络报文丢包问题并不做任何处理（Tcp会重传）
 虽然Udp不会做丢失重传等工作，但其实在目前的网络环境中，数据丢包的概率极小。并且Tcp为了保证可靠性，需要做大量工作（超时重发、流量控制、拥塞控制、快速重传…），也就意味着Tcp通信更复杂，速度更低。所以如果对可靠性要求不高的场景，一般选择Udp作为传输层协议。

2）、Udp协议格式

• 16位UDP长度,：表示整个数据报(UDP首部+UDP数据)的最大长度。
• 16位UDP校验和：如果校验和出错, 就会直接丢弃;

 任何协议都需要解决两个问题：报文和有效载荷分离问题，报文向上交付问题。
 
 报文和有效载荷分离问题：首先Udp报头采用固定长度，8字节。并且报头中16位UDP长度字段表示整个报文长度。所以在读取Udp报文时，只需要先读取报头（8byte），剩余就是有效载荷了。
 报文向上交付问题:报文中存在目的端口号字段，明确交给上层那个端口。

3）、Udp报文封装和解包过程

 在OS中，存在大量的Udp报文。OS需要对报文进行管理，先描述在组织！

4）、UDP的缓冲区

 Udp没有真正的发送缓冲区。数据从应用层拷到传输层后，添加报头，构建sk_buff结构体后直接向下交付，交给网络层。
 但Udp存在接收缓冲区。原因在于Udp可能会接收到大量的报文。Udp本身特点不可靠，如果对端传输层中已经存在报文，但上层没有及时取走，此时Udp可以直接接将新收到的报文丢弃或覆盖原始报文，这并不影响上层对Udp处理，但这并不合理。 Udp报文经过千里迢迢之后将报文正确发送到目标主机后，在这其中消耗了大量的资源，Udp收到报文后仅因为上层没有及时将前一个数据取走，就直接将新报文丢弃。Udp虽然不可靠，但也不能这么不可靠。所以对于Udp接收方，我们还是提供了一个接收缓冲区，暂时保存新到的报文！
 Udp接收缓冲区本质就是一个队列，将所有新到的sk_buff结构体连接到改队列下即可。

三、TCP协议

1）、TCP协议特点

 TCP全称为 “传输控制协议(Transmission Control Protocol”)。Tcp不仅控制报文传输（丢包了需要重传，网络拥塞时执行网络拥塞算法，以及流量控制等）保证可靠性，还做了大量工作来保证效率（后面介绍）
 
 TCP是一种可靠的，面向字节流的通信协议，并且在通信前需要先建立连接！

2）、TCP协议格式

1、4位首部长度、源端口、目的端口

任何协议都需要解决两个问题：报文和有效载荷分离问题，报文向上交付问题。
 
 报文和有效载荷分离问题：Tcp的标准报头长度为20字节，4位首部长度表示Tcp报头的总长度。所以在分解报文时，只需先读取头20字节数据，然后分析提取出4位首部长度。此时就能明确Tcp报头的长度，将报文和有效载荷分离。
 
 在Tcp报头中存在目的端口号，解决向上交付问题！

• 4位首部长度的基本单位为4字节，所以tcp报头的长度为[20，4*15]，即[20, 60]

2、16位窗口大小

 Tcp典型的全双工协议，双方地位是对等的。在报文发送过程中，Tcp为了保证可靠性需要做流量控制！如果接收方来不及接收，就让发送端少发点。（否则Tcp收到多余报文会被丢弃，不可靠，不合理）
 
 为了实现流量控制，发送端需要知道接收端的接收能力，也就是对端接收缓冲区的剩余空间大小！而16位窗口中填写的就是接收缓冲区剩余空间大小！
 
 在tcp协议中，所有的报文都必须应答。所以客户端和服务器直接互发消息时，对端必须确认应答。而确认应答大多数就是一个最简单的标准报头，而报头中携带的16位窗口大小表示接收方的接收能力。从而实现告知对方我的接收能力！

1. 上述所有的行为都是双方Tcp协议做的，应用层不需要关心。就像文件操作，我们直接调用write将用户数据拷贝到内核后，数据什么时候刷新落盘是由OS来决定实现的，上层用户不需要关心。
2. Tcp流量控制和管道类似，当接收端满了后，发送端会发送阻塞。如果此时上层还在忘发送端的发送缓冲区写，导致发送缓冲区也满了，此时上层进程就会发生阻塞！

3、Tcp确认应答机制

 Tcp规定接收端必须对接收到的数据进行应答。所以我们可以每发一条消息后，等待应答。然后在发生下一条数据！ 但这样串行发送，效率较低。所以实际Tcp发送报文是一次发送多个报文，然后等待应答！

• tcp为了保证可靠性，所以Tcp引入确认应答机制就可以100%明确历史最近一跳消息一定被对方收到！
• tcp做不到100%可靠的网络通信，原因在于最近一条消失没有应答。

4、序号和确认序号

 发送方一次发送大量报文，接收方接收到的数据可能是乱序的。而乱序是不可靠的一种表现（发送http报文时，报头和有效载荷接收反了，上层处理会出异常） 所以Tcp引入32位序号，保证报文的按序到达！接收方根据接收报文中的序号进行排序即可修正！
 
 但发送方还需要对发送的大量报文进行应答。但一次发送大量报文，如何得到接收到的应答是对历史那个具体报文的确认呢？ 所以Tcp引入32位确认序号（确认序号= 序号 + 1）。确认序号表示确认序号之前的报文都被