1.TCP

①概念

什么是TCP？ :::success TCP协议全称是传输控制协议，是一种面向连接的、可靠的、基于字节流的传输层通信协议。 ::: TCP的特点：

（1）基于流的方式； （2）面向连接； （3）可靠通信方式； （4）在网络状况不佳的时候尽量降低系统由于重传带来的带宽开销； （5）通信连接维护是面向通信的两个端点的，而不考虑中间网段和节点。

为了实现上面的特点，TCP采用了如下策略：

①数据分片：在发送端对用户数据进行分片，在接收端进行重组，由TCP确定分片的大小并控制分片和重组； ②到达确认：接收端接收到分片数据时，根据分片数据序号向发送端发送一个确认； ③超时重发：发送方在发送分片时启动超时定时器，如果在定时器超时之后没有收到相应的确认，重发分片； ④失序处理：作为IP数据报来传输的TCP分片到达时可能会失序，TCP将对收到的数据进行重新排序，将收到的数据以正确的顺序交给应用层； ⑤滑动窗口：TCP连接每一方的接收缓冲空间大小都固定，接收端只允许另一端发送接收端缓冲区所能接纳的数据，TCP在滑动窗口的基础上提供流量控制，防止较快主机致使较慢主机的缓冲区溢出； ⑥重复处理：作为IP数据报来传输的TCP分片会发生重复，TCP的接收端必须丢弃重复的数据； ⑦数据校验：TCP将保持它首部和数据的检验和，这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到分片的检验和有差错，TCP将丢弃这个分片，并不确认收到此报文段导致对端超时并重发。

②三次握手

TCP采用三次握手，主要也是解决网络信道不可靠的一个问题。

(1)原理

SYN：同步标志。表明同步序列编号栏有效。该标志仅在三次握手建立TCP连接时有效。它提示TCP连接的服务端检查序列编号，该序列编号为TCP连接初始端（一般是客户端）的初始序列编号。

ACK：确认标志。表明确认编号栏有效。大多数情况下该标志位是置位的。TCP报头内的确认编号栏内包含的确认编号（w+1）为下一个预期的序列编号，同时提示远端系统已经成功接收所有数据。

:::success 三次握手：
第一次握手：建立连接时，客户端发送SYN包（SYN=i）到服务器，并进入到SYN-SEND状态，等待服务器确认
第二次握手：服务器收到SYN包，必须确认客户的SYN（ack=i+1）,同时自己也发送一个SYN包（SYN=k）,即SYN+ACK包，此时服务器进入SYN-RECV状态
第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认报ACK（ack=k+1）,此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手，客户端与服务器开始传送数据。 :::

(2)为什么是三次握手

:::danger 这是为了防止，已经失效的请求报文又重新传入到服务器，发生请求错误，这是什么意思呢？ ::: :::success 如果只采用两次握手（也就是服务端返回SYN+ACK后就建立起连接），那么会出现下面的问题：
① 当 客户端 第一次发送请求给 服务端时，SYN因为网络原因，没有到达服务端
② 此时，客户端会重新发送一个SYN，重新与服务端建立连接，并且第二次SYN没有丢失，连接建立成功
③ 但是，第一个SYN因为网络恢复了，又成功的到达了服务端
④ 此时，服务端就会认为客户端又发送了一次请求，因此就会又与客户端建立一次连接
到这，我们来捋一捋：
① 服务端认为客户端发送了两次，由于只有两次握手，因此服务端单方面的就进入了数据等待的状态
② 客户端则认为只有一个连接，因此服务端永远不会在第二个连接上收到客户端的数据，进而导致资源的浪费 ::: 由此可见，当只采用两次握手时，当SYN丢失又恢复这种情况，就会导致客户端和服务端的状态不一致的问题

因此，如果采用三次握手就不会发生上面的情况了 :::warning ① 当服务端收到第一次被丢失的SYN后，又发送SYN+ACK给客户端，但是客户端已经取消了上一个连接，因此也就不会发送最后的ACK给服务端
② 服务端只要收不到最后的ACK包，就不会与客户端建立连接了 :::

③四次挥手

四次挥手和三次握手一样，也是为了在不可靠的网络链路中，进行可靠的连接断开

(1)原理

FIN：终止 标志，用来释放一个连接。当 FIN=1 时，表明此报文段的发送发的数据已发送完毕，并要求释放运输连接

:::warning 四次挥手：

• 第一次挥手： 若客户端认为数据发送完成，则它需要向服务端发送连接释放请求，发送一个FIN包给服务端。
• 第二次挥手：服务端收到连接释放请求后，会告诉应用层要释放 TCP 链接。然后会发送 ACK 包，并进入 CLOSE_WAIT 状态，此时表明客户端到服务端的连接已经释放，不再接收客户端发的数据了。但是因为 TCP 连接是双向的，所以服务端仍旧可以发送数据给客户端。
• 第三次挥手：服务端如果此时还有没发完的数据会继续发送，完毕后会向客户端发送连接释放请求，发送FIN包，然后服务端便进入 LAST-ACK 状态。
• 第四次挥手： 客户端收到释放请求后，向服务端发送确认应答，此时客户端进入 TIME-WAIT 状态。该状态会持续 2MSL（最大段生存期，指报文段在网络中生存的时间，超时会被抛弃） 时间，若该时间段内没有服务端的重发请求的话，就进入 CLOSED 状态。当服务端收到确认应答后，也便进入 CLOSED 状态。 :::

  (2)为什么是四次挥手

  由于前面建立连接时是三次握手，那么我们理所应当的认为关闭连接应该也是三次挥手，但为什么会是四次呢？ :::success 因为当服务端收到客户端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。
  但是关闭连接时，当服务端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉客户端，“你发的FIN报文我收到了”。只有等到我服务端所有的报文都发送完了，我才能发送FIN报文，因此 ACK 和 FIN 不能一起发送，故需要四次挥手。
  （简单点说：就是服务端那边可能还有没发送完的数据，所以FIN不能和ACK一起发给客户端，要等到数据都传输完了，才能发FIN给客户端） :::

  (3)为什么TIME_WAIT状态需要经过2MSL才能返回到CLOSE状态

  :::success 答： 这是为了保障 服务端 能收到ACK
  如果客户端发送完ACK包后直接关闭连接，一旦ACK包在最后传输时因为网络问题而丢失，服务端因为收不到最后的ACK包而一直处于LACT_ACK（最后确认）状态，无法关闭连接。
  如果客户端发送完ACK包后等待一段时间，这样即使服务端没有收到ACK包，服务端也会向客户端重新发送一个FIN包，这样客户端就会响应这个FIN包并重新发送一个ACK包，然后刷新超时时间。 :::

④拥塞控制

(1)慢启动

:::success 每当建立一个TCP连接时或一个TCP连接发生超时重传后，该连接便进入慢启动阶段。进入慢启动后，TCP实体将拥塞窗口的大小初始化为一个报文段，即：cwnd=1。此后，每收到一个报文段的确认（ACK），cwnd值加1，即拥塞窗口按指数增加。当cwnd值超过慢启动阐值（ssthresh）或发生报文段丢失重传时，慢启动阶段结束。前者进入拥塞避免阶段，后者重新进入慢启动阶段。 :::

(2)拥塞避免

:::success 在慢启阶段，当cwnd值超过慢启动阐值（ssthresh）后，慢启动过程结束，TCP连接进入拥塞避免阶段。在拥塞避免阶段，每一次发送的cwnd个报文段被完全确认后，才将cwnd值加1。在此阶段，cwnd值线性增加。 :::

⑤重传机制

(1)快速重传

快速重传是对超时重传的改进。当发送方一旦连续收到对同一个报文的三个重复确认时，就确定一个报文段已经丢失，因此立刻重传丢失的报文段，而不必等到重传定时器（RTO）超时。以此减少不必要的等待时间。

(2)快速恢复

当发送方收到三个重复确认，它就知道了是只丢失了个别报文段，因此不启动慢开始算法，而启动快速恢复算法。

快速恢复是对丢失恢复机制的改进。在快速重传之后，不经过慢启动过程而直接进入拥塞避免阶段。每当快速重传后，设置ssthresh=cwnd/2、ewnd=ssthresh+3。此后，每收到一个重复确认，将cwnd值加1，直至收到对丢失报文段和其后若干报文段的累积确认后，直到cwnd=ssthresh，进入拥塞避免阶段。

2.UDP

①概念

:::success UDP 全称是用户数据报协议，是一种无连接，不可靠的，基于报文的传输层协议 ::: UDP特点：

（1）由于传输数据不建立连接，因此也就不需要维护连接状态，包括收发状态等，因此一台服务机可同时向多个客户机传输相同的消息。 （2）UDP信息包的标题很短，只有8个字节，相对于TCP的20个字节信息包而言UDP的额外开销很小。 （3）吞吐量不受拥挤控制算法的调节，只受应用软件生成数据的速率、传输带宽、源端和终端主机性能的限制。 （4）UDP是面向报文的。发送方的UDP对应用程序交下来的报文，在添加首部后就向下交付给IP层。既不拆分，也不合并，而是保留这些报文的边界，因此，应用程序需要选择合适的报文大小。

②UDP协议为什么不可靠？

UDP在传输数据之前不需要先建立连接，远地主机的运输层在接收到UDP报文后，不需要确认，提供不可靠交付。
总结就以下四点：

1. 不保证消息交付：不确认，不重传，无超时
2. 不保证交付顺序：不设置包序号，不重排，不会发生队首阻塞
3. 不跟踪连接状态：不必建立连接或重启状态机
4. 不进行拥塞控制：不内置客户端或网络反馈机制

3.TCP和UDP对比

TCP适用场景 :::success TCP适用于对网络质量要求较高的场景，能把数据准确无误的传给对方
协议：
HTTP , HTTPS , FTP , SMTP
实际场景：
QQ文件传输，网页信息的传输，消息的传输，发送邮件等 ::: UDP适用场景 :::success UDP速度快，会丢包，适用于对实时性要求较高，对少量丢包并没有太大要求的场景
协议：
DNS ，TFTP ，SNMP等
实际场景：
视频、音频等多媒体通信（即时通信），广播通信 :::