计算机网络基础——TCP/UDP（拥塞处理，流量控制，三次握手四次挥手）

服务类型：TCP和UDP

• TCP：面向连接，提供服务前建立专门的传输连接，并且这条连接可管理，在需要或通信结束时进行拆除。（建立在不可靠传输服务上，可能出现丢失、乱序、延迟、重复等问题，因此必须使用三次握手、超时、重传功能）
  
• UDP：无连接，直接发送，不管是否能到达，尽力而为

---

TCP/UDP区别

TCP

• 优点：可靠、稳定TCP的可靠体现在TCP在传输数据之前会三次握手建立连接，而在数据传递时，有确认、窗口、重传、拥塞控制，在数据传完后，还会断开连接用来节约系统资源。
• 缺点：慢、效率低、占用系统资源高、易被攻击。TCP在传递数据之前，要先建立连接，消耗时间，而且在数据传递时，确认机制、重传机制、拥塞控制机制等都会消耗大量的时间，而且要在每台设备上维护所有的传输连接，事实上，每个连接都会占用系统的 CPU、内存等硬件资源。 而且，因为 TCP 有确认机制、三次握手机制，这些也导致 TCP 容易被人利用，实现 DOS、DDOS、CC 等攻击。

UDP

• 优点：快，比 TCP 稍安全 UDP 没有 TCP 的握手、确认、窗口、重传、拥塞控制等机制，UDP 是一个无状态的传输协议，所以它在传递数据时非常快。没有 TCP 的这些机制，UDP 较 TCP 被攻击者利用的漏洞就要少一些。但 UDP 也是无法避免攻击的，比如：UDP Flood 攻击……
• 缺点：不可靠，不稳定 因为 UDP 没有 TCP 那些可靠的机制，在数据传递时，如果网络质量不好，就会很容易丢包。

---

TCP/UDP的使用场景

什么时候用TCP？

当对网络通讯质量有要求的时候，比如：整个数据要准确无误的传递给对方，这往往用于一些要求可靠的应用，比如 HTTP、HTTPS、FTP 等传输文件的协议，POP、SMTP 等邮件传输的协议。 在日常生活中，常见使用 TCP 协议的应用如下： 浏览器，用的 HTTP FlashFXP，用的 FTP Outlook，用的 POP、SMTP Putty，用的 Telnet、SSH QQ 文件传输 …………

什么时候用UDP？
当对网络通讯质量要求不高的时候，要求网络通讯速度能尽量的快，这时就可以使用 UDP。 比如，日常生活中，常见使用 UDP 协议的应用如下： QQ 语音 QQ 视频 TFTP 。有些应用场景对可靠性要求不高会用到 UPD，比如长视频，要求速率

---

TCP协议可靠保证

• 应用数据被分割成 TCP 认为最适合发送的数据块。
• TCP 给发送的每一个包进行编号，接收方对数据包进行排序，把有序数据传送给应用层。
• 校验和： TCP 将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP 将丢弃这个报文段和不确认收到此报文段。
• TCP 的接收端会丢弃重复的数据。
• 流量控制： TCP 连接的每一方都有固定大小的缓冲空间，TCP 的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。TCP 使用的流量控制协议是可变大小的滑动窗口协议。 （TCP 利用滑动窗口实现流量控制）
• 拥塞控制： 当网络拥塞时，减少数据的发送。
• ARQ 协议（应答机制）： 也是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组。
• 超时重传： 当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。

---

流量控制

TCP协议中窗口机制分为两种

• 固定大小的窗口
• 滑动窗口

固定窗口存在的问题？

• 如果窗口过小，当传输比较大的数据时需要不停对数据进行确认，造成很大延迟。
• 窗口过大，当传输的数据大于接受方处理的数据数量时，会有一些数据来拥塞我们的链路。

滑动窗口
描述接收方的 TCP 数据报缓冲区大小的数据，发送方根据这个数据来计算自己最多能发送多长的数据，如果发送方收到接收方的窗口大小为 0 的 TCP 数据报，那么发送方将停止发送数据，等到接收方发送窗口大小不为 0 的数据报的到来

---

拥塞处理

若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就会变坏，这种情况就叫做拥塞。
拥塞控制就是防止过多的数据注入网络中，这样可以使网络中的路由器或链路不致过载。注意，拥塞控制和流量控制不同，前者是一个全局性的过程，而后者指点对点通信量的控制。
拥塞控制的方法主要有以下四种：

• 慢启动：不要一开始就发送大量的数据，先探测一下网络的拥塞程度，也就是说由小到大逐渐增加拥塞窗口的大小。
• 拥塞避免：拥塞避免算法让拥塞窗口缓慢增长，即每经过一个往返时间 RTT 就把发送方的拥塞窗口 cwnd 加 1，而不是加倍，这样拥塞窗口按线性规律缓慢增长。
• 快重传：快重传要求接收方在收到一个 失序的报文段 后就立即发出 重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己发送数据时捎带确认。快重传算法规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。
• 快恢复：快重传配合使用的还有快恢复算法，当发送方连续收到三个重复确认时，就执行 “乘法减小” 算法，把 ssthresh 门限减半，但是接下去并不执行慢开始算法：因为如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法，而是将 cwnd 设置为 ssthresh 的大小，然后执行拥塞避免算法。

---

TCP三次握手

我要和你连接，你真的要和我连接吗，我真的要和你连接，连接成功

• 第一次握手：客户端发送 syn 包 (syn=x) 到服务器，并进入 SYN_SEND 状态，等待服务器确认；
• 第二次握手：服务器收到 syn 包，必须确认客户的 SYN（ack=x+1），同时自己也发送一个 SYN 包（syn=y），即 SYN+ACK 包，此时服务器进入 SYN_RECV 状态；
• 第三次握手：客户端收到服务器的 SYN＋ACK 包，向服务器发送确认包 ACK (ack=y+1)，此包发送完毕，客户端和服务器进入 ESTABLISHED 状态，完成三次握手。

---

TCP四次挥手

我要和你断开连接，好的，我也要和你断开连接，好的

• 第一次挥手：客户端主动关闭方发送一个 FIN，用来关闭客户端到服务端的数据传送，也就是客户端告诉服务端：我已经不会再给你发数据了 (当然，在 fin 包之前发送出去的数据，如果没有收到对应的 ack 确认报文，客户端依然会重发这些数据)，但是，此时客户端还可以接受数据。
• 第二次挥手：服务端收到 FIN 包后，发送一个 ACK 给客户端，确认序号为收到序号 + 1（与 SYN 相同，一个 FIN 占用一个序号）。
• 第三次挥手：服务端发送一个 FIN，用来关闭服务端到客户端的数据传送，也就是告诉客户端，我的数据也发送完了，不会再给你发数据了。
• 第四次挥手：客户端收到 FIN 后，发送一个 ACK 给服务端，确认序号为收到序号 + 1，至此，完成四次挥手。

---

为什么不是一次、二次握手？

防止服务端的一直等待而浪费资源
为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。如果此时客户端发送的延迟的握手信息服务器收到，然后服务器进行响应，认为客户端要和它建立连接，此时客户端并没有这个意思，但 server 却以为新的运输连接已经建立，并一直等待 client 发来数据。这样，server 的很多资源就白白浪费掉了。

---

第三次握手失败会怎么办？

当失败时服务器并不会重传ack报文，而是直接发送RTS报文段，进入CLOSED状态。这样做的目的是为了防止SYN洪泛攻击。

---

为什么要有2MSL等待延迟

对应这样一种情况，最后客户端发送的ACK = 1给服务端的过程中丢失了，服务端没收到，服务端怎么认为的？我已经发送完数据了，怎么客户端没回应我？是不是中途丢失了？然后服务端再次发起断开连接的请求，一个来回就是2MSL，这里的两个来回由那一个来回组成的？

客户端给服务端发送的ACK = 1丢失，服务端等待 1MSL没收到，然后重新发送消息需要1MSL。如果再次接收到服务端的消息，则重启2MSL计时器，发送确认请求。客户端只需等待2MSL，如果没有再次收到服务端的消息，就说明服务端已经接收到自己确认消息；此时双方都关闭的连接，TCP 四次分手完毕。

---

如果双方建立连接，一方出问题了怎么办？

如果双方建立连接，一方出问题怎么办？为了防止出现上述恋爱故事中千年等一回的情况，已经建立连接，但是服务端一直等待接收，发送端出现问题一直不能发送。

所以设计一个保活的计时器，如果一方出现问题，另一方过了这个计时器的时间，就发送试探报文，以后每隔 75 秒发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。