TCP && UDP_tcp&&udp-优快云博客

在TCP中，当发送端的数据到达对端时，对端会返回一个对已收到消息的通知，这个通知就是确认应答。在日常生活中，两个人如果进行网络聊天，不考虑对方没有看到的情况，如果你给对方发送了一个消息，那么对方是会给你返回一个响应的，在网络中同样如此，为了让发送端得知接收端已经收到了消息，接收端就会给发送端回一个消息，这个消息就是确认应答（ACK）。

如果在上述过程中，主机A没有收到来自主机B的一个响应（ACK），那么有很大的可能是主机B发出的ACK在网络传输的过程中丢失了。还有一种可能就是主机B根本没有收到主机A发送来的消息，这种情况就是数据在传输的过程中发生了丢失。

数据丢失

丢失ACK

为了应对这种消息丢失的情况，TCP引入了重发控制（重新发送数据）（后面说）来实现消息的可靠传输。

序列号

再来考虑一下上面数据丢失的情况，对于发送端主机来说，只需要按照重传机制进行数据重传即可，但是对于目标主机来说，这就是一种“灾难”，为什么这么说呢？因为目标主机会反复的收到相同的数据，目标主机如果无法区分这些数据是不是已经接受过了的话，那这可就是真的灾难了，为此，就必须引入一种机制，它可以识别是否已经接受过该数据。

上述这些确认应答处理，重发控制以及重复控制等都可以通过序列号来进行解决。

序列号是按顺序给发送数据的每一个字节都标上编号，接收端会查询接收数据TCP首部中的序列号和数据的长度，将自己下一个应该接收的序列号作为确认应答号发送出去，这样，通过序列号和确认应答号，TCP可以实现可靠传输。

连接管理

连接建立（三报文握手）

假设运行在一台服务器上的主机（客户）上的一个进程想与另一台主机（服务器）的一个进程建立一条连接。客户端应用进程首先会通知TCP，它想要建立一个与服务器上某个进程之间的连接，这就是连接建立。

第一次握手
A 发送同步报文段（SYN）请求建立连接。
A进入SYN-SENT(同步已发送）状态。
第二次握手
B 监听到连接请求，向 A 发送针对 SYN 的确认 ACK，同时 B 也发送自己的请求建立连接（SYN）。
B进入SYN-RCVD (同步收到）状态
第三次握手
A 收到 B 发出的 SYN，给出确认应答 ACK。
A 收到确认后进入 ESTABLISHED (己建立连接）状态。B 收到 A 的确认后，也进入ESTABLISHED状态

TCP为什么要三次握手而不是两次

1. 网络延迟导致服务端建立连接，而客户端没建立连接

2. 如果服务端的ACK丢失，会导致客户端一直重试，服务端会连接大量无效连接

当服务端的确认应答 ACK 总是丢失时，客户端以为服务端没有连接，它将会不断地重新请求连接，而服务端会连接大量的无效连接，给服务器增加维护成本，服务器很容易受到 SYN 洪水攻击。

SYN洪泛攻击

TCP的连接管理为经典的Dos攻击 SYN洪泛攻击 (SYN flood attack) 提供了环境,在这种攻击中,攻击者发送大量的TCP SYN 报文段,而不是完成三次握手的步骤。随着这种SYN纷至沓来，服务器会不断为这些半开连接分配资源，导致服务器的连接资源被耗尽。

当服务器收到一个SYN连接报文段时，它并不知道该报文段是来自合法的用户还是SYN洪泛攻击的一部分。因此服务器不会为该报文段生成半开连接，而是使用一个加密函数生成一个序列号 “cookie” 返回发送方。
如果客户是合法的，则它会返回一个ACK报文段。当服务器收到该ACK，会进行cookie的验证，如果结果合法的话，服务器就会生成一个TCP连接。
如果客户没有返回一个ACK，则初始的SYN也没有对服务器造成危害，因为服务器并没有为它分配任何资源。

连接关闭（四报文挥手）

第一次挥手
当主机 A 发送数据完毕后，发送 FIN 结束报文段。
第二次挥手
主机 B 收到段后，向主FIN 报文机 A 发送一个确认序号 ACK（为防止这段时间内，对方重传 FIN 报文段）。
第三次挥手
主机 B 准备关闭连接，向主机 A 发送一个 FIN 结束报文段。
第四次挥手
主机 A 收到 FIN 结束报文段后，进入 TIME_WAIT 状态。并向主机 B 发送一个ACK 表示连接彻底释放。

TIME-WAIT可不可以取消？

不可以取消，防止第四次挥手时发送的ACK丢失，导致服务端无法正常进行关闭。

利用滑动窗口控制提高发送速率

在建立TCP连接的同时,也可以确定发送数据包的单位，也可以称之为“最大消息长度” （MSS，Maximum Segment Size）MSS通常根据最初确定的由本地发送主机发送的最大链路层帧长度（即所谓的最大传输单元 MTU）来设置。最理想的情况是，最大消息长度是不会被IP做分片处理的最大消息长度。

MSS是在建立连接时，在两端计算机之间被计算得到的。两端计算机在发出建立连接请求时，会在TCP首部中写入MSS选项。

TCP以一个段为单位，每发一个段进行一次消息的确认应答处理，但是如果一次往返时间很长，网络的吞吐量就会很差！

为了解决这个问题,TCP引入了窗口这个概念。即使在往返时间较长的情况下, 它也能控制网络性能的下降

窗口大小就是无需等待确认应答就可以继续发送数据的最大值。

流程如下

图中白色部分就是窗口，在窗口范围内的数据即使没有收到确认应答也可以发送出去。此外，如果发送的数据丢失，发送发需要进行重发，所以，发送方主机在收到对应的确认应答之前，必须在窗口中保留这部分数据。

在收到确认应答的情况下，窗口就可以移动到确认应答所对应的序列号所在的位置。这就是滑动窗口机制。

高速重发控制

在使用窗口控制中，考虑一下消息丢失的情况，如果是ACK丢失了，问题不大，可以通过下一个ACK来进行确认，但如果是数据丢失了，正常情况下发送放需要等待重传时间进行数据重传。

为了提高效率，引入了高速重发控制：默认收到三个相同的ACK时,表名该报文段丢失, 不必等待超时重传, 可以立即重传。

流量控制

一条TCP的连接的每一侧主机都会为该连接设置接收缓存。如果TCP连接接收到正确，按序的字节后，它就会将数据放入接收缓存。与之相关联的进程会从该缓存中读取数据，但不必是数据一到达就立即读取。事实上，接收方应用可能正在处理其他事情，如果这个时候发送放不加节制的持续进行数据的发送，不难预料缓存可能会出现溢出的情况。

为了防止这种情况发生， TCP为它的应用程序提供了流量控制服务，用来消除发送方使接收方溢出的可能性。

TCP通过让发送方维护一个接收窗口（窗口大小）的变量来提供流量控制。接收窗口用于给发送方一个提示-该接收方还有多少可用的缓存空间。

流量控制图解

拥塞控制

上面的流量控制是考虑的发送和和接收方主机之间的通信能力，没有考虑到数据在网络中传输的情况，如果网络十分拥塞，而发送发还是按照原来的窗口大小进行发送数据，无疑会产生丢包问题，情况严重的话，网络直接瘫痪！！

为了调节发送方要发送的数据量，定义了一个叫“拥塞窗口” 这样的概念

实际上的发送窗口大小 = Math.min（拥塞窗口，接收端主机通知的窗口大小）

那么问题来了， TCP到底是如何计算拥塞窗口大小的呢？

拥塞控制算法

慢开始

慢开始（Slow Start）是TCP拥塞控制算法中的一种机制，用于在连接刚建立或者在网络中出现拥塞时，控制发送端的发送速率，避免导致网络拥塞恶化。

初始时，拥塞窗口大小为1个报文段的大小（通常为MSS，最大报文段长度）。
每经过一个往返时间（RTT），拥塞窗口大小加倍。
当拥塞窗口大小达到一定阈值（慢开始门限），就会进入拥塞避免阶段。

拥塞避免

当拥塞窗口大小达到慢开始门限时，进入拥塞避免阶段。
在拥塞避免阶段，每经过一个往返时间（RTT），拥塞窗口大小线性增加，即每经过一个RTT，拥塞窗口大小加1。
如果发生丢包事件（超时或接收到重复的冗余ACK），将慢开始门限设置为当前拥塞窗口大小的一半，并将拥塞窗口大小重新设置为1，然后重新开始慢开始算法。

慢开始门限（Slow Start Threshold）

快重传

快重传的原理是当发送端接收到连续三个重复的确认（Duplicate ACK）时，就知道现在只丢失了个别的报文段，于是不启动慢开始算法，改为快重传

发送端发送报文段并启动定时器等待确认。
如果接收端收到乱序的报文段，会发送一个重复的确认。
当发送端连续收到三个重复的确认时，立即重传丢失的报文段。
在重传后，发送端继续正常的拥塞控制算法（如拥塞避免）。

快恢复

快恢复的原理是在发送端收到第一个重复的确认（Duplicate ACK）时，将拥塞窗口大小减半，然后进入快恢复状态。在快恢复状态下，发送端继续以每收到一个重复的确认就将拥塞窗口大小加1，最终，当对丢失报文的ACK到达时，TCP在降低cwnd后进入拥塞避免。

发送端发送报文段并启动定时器等待确认。
如果接收端收到乱序的报文段，会发送一个重复的确认。
当发送端收到第一个重复的确认时，将拥塞窗口大小减半，并进入快恢复状态。
在快恢复状态下，每收到一个重复的确认，将拥塞窗口大小加1，直到达到慢开始门限为止。
当拥塞窗口大小达到慢开始门限时，发送端进入拥塞避免状态继续发送数据。