前端也要知道的TCP和UDP
TCP 和 UDP
作为一个前端已经不止一次的在面试中被问到 TCP 和 UDP 协议了。为了让自己的回答不那么敷衍，从前端的角度对 TCP 和 UDP 在基础层面进行了一下总结。
TCP 和 UDP 是运输层的两种协议，什么是运输层呢？
运输层（Transport Layer）就是负责向两台主机进程之间的通信提供通用的数据传输服务，应用进程利用该服务传送应用层报文。
这里的通用是指并不针对某一个特定的网络应用，而是多种应用可以使用同一个运输层服务。
TCP 协议是一种面向连接的、可靠的数据传输服务。可靠指得是通过 TCP 协议传送数据可以无差错、不丢失、不重复、并且按序到达；
并且 TCP 协议还具有以下特点：
- 双方在连接建立之后，都可以在任何时候进行数据发送
- 有缓存，发送和接收时都可以利用缓存临时存放数据
- TCP 是面向字节流的
UDP 协议是无连接的、不可靠的。具有以下特点：
- 无连接
- 因为无连接所以不可靠
- UDP 是面向报文的
- 支持 n 对 n 的交互通信
- UDP 无拥塞控制
拥塞控制：
我们知道，两台主机在传输数据包的时候，如果发送方迟迟没有收到接收方反馈的ACK，那么发送方就会认为它发送的数据包丢失了，进而会重新传输这个丢失的数据包。然而实际情况有可能此时有太多主机正在使用信道资源，导致网络拥塞了，而A发送的数据包被堵在了半路，迟迟没有到达B。这个时候A误认为是发生了丢包情况，会重新传输这个数据包。结果就是不仅浪费了信道资源，还会使网络更加拥塞。因此，我们需要进行拥塞控制。
由于 UDP 具有无连接、传输速度更快、效率更高、并且没有拥塞控制，所以源主机发送速率不受网络拥塞的影响，因此 UDP 协议被广泛的应用到直播和实时视频的领域。
与 UDP 相反，TCP 协议在速度、效率方面没有优势，但是 TCP 协议可以很好的保证数据传输的可靠性，下面来看看 TCP 是如何做到可靠的。
- 校验：如果接收端校验出包有错，则进行丢弃且不进行响应
- 排序：在将数据包交给应用层之前，TCP 协议会保证数据包的有序性
- 去重：丢弃重复的数据
- 应答：接收方接收到数据后，将发送确认信息给发送方
- 超时重发：当发送方发出数据后，会启动一个定时器，当超过定时器时限后，会重新发这个报文段
- 流量控制：利用固定大小的缓冲空间防止接收方缓冲区溢出
三次握手
我想不管你了不了解这些协议，你都会听说过三次握手。
我们把客户端和服务器每一次交互都比喻成一次握手，那么简单来说，当建立一个 TCP 连接的时候，整个过程需要客户端和服务端交互三个包，交互这些包的目的是连接服务器指定端口，建立 TCP 连接，并同步连接双方的序列号和确认号以及交换 TCP 窗口大小。
在这里插入图片描述
第一次握手
开始建立连接时，客户端向服务器发出连接请求报文，报文首部中的同部位 SYN = 1，同时选择一个初始序列号 seq = x ，
此时客户端进程进入了 SYN-SENT （同步已发送状态）状态，等待服务器确认。
第二次握手
服务器收到 syn 包后，如果同意连接，则发出确认报文；确认报文 ACK = 1，SYN = 1，确认号是 ack = x + 1，同时也要为自己初始化一个序列号 seq = y，
此时服务器进程进入了 SYN-RCVD（同步收到）状态。
第三次握手
客户端收到服务器的 SYN + ACK 包，要向服务器给出确认。确认报文的 ACK = 1，ack = y + 1，自己的序列号 seq = x + 1。此时，TCP 连接建立，
此时客户端进入 ESTABLISHED （已建立连接）状态。
四次挥手
当断开连接时的四次挥手
在这里插入图片描述
第一次挥手：
客户端进程发出连接释放报文，并且停止发送数据。此时，客户端进入 FIN-WAIT-1（终止等待 1）状态。
第二次挥手：
服务器收到连接释放报文，发出确认报文，此时，服务端就进入了 CLOSE-WAIT（关闭等待）状态。
第三次挥手：
服务器将最后的数据发送完毕后，就向客户端发送连接中断报文，此时，服务器就进入了 LAST-ACK（最后确认）状态，等待客户端的确认。
第四次挥手：
客户端收到服务器的连接释放报文后，必须发出确认，客户端就进入了 TIME-WAIT（时间等待）状态。
最后服务器只要收到了客户端发出的确认，立即进入 CLOSED 状态。就结束了这次的 TCP 连接
了解了整个建立和断开连接的过程，思考几个问题：
1.TCP 建立连接为什么需要三次握手，一次握手行不行？
答案是当然不行，为什么不能一次握手：因为 TCP 是面向连接的，一次握手，只发一条信息出去，没有任何回信肯定无法建立连接。
2.两次握手是否可行？
假设只有两次握手，当 A（客户端） 想要建立连接时发送一个 SYN ，然后等待 ACK ，结果这个 SYN 因为网络问题没有及时到达 B（服务端），所以 A 在一段时间内没收到 ACK 后，会再发送一个 SYN ，这次 B 成功收到，并向 A 发送了 ACK ，然后 A 也收到 ACK ，但是此时 A 发送的第一个 SYN 终于到了 B，对于 B 来说这是一个新连接请求，然后 B 又为这个连接申请资源，返回 ACK ，然而这个 SYN 是个无效的请求，A 收到这个 SYN 的 ACK 后也并不会理会它，而 B 却不知道，B 会一直为这个连接维持着资源，造成资源的浪费。
3.那为什么三次握手就可以解决这些问题？
两次握手的问题在于服务器端不知道一个 SYN 是否是无效的，而三次握手机制因为客户端会给服务器回复第二次握手，也意味着服务器会等待客户端的第三次握手，如果第三次握手迟迟不来，在尝试重发后仍未收到，服务器便会认为这个 SYN 是无效的，释放相关资源。但这时有个问题就是客户端完成第二次握手便认为连接已建立，而第三次握手可能在传输中丢失，服务端会认为连接是无效的，这时如果客户端向服务端写数据，服务端将以 RST 包响应，客户端就可以感知到错误。
4.如果第三次握手失败怎么办？
与第三题类似，当客户端收到服务端的 SYN+ACK 应答后，其状态变为 ESTABLISHED，并会发送 ACK 包给服务端，准备发送数据了。如果此时 ACK 在网络中丢失，过了超时计时器后，那么Server端会重新发送 SYN+ACK 包，默认是5次。如果重传指定次数到了后，仍然未收到 ACK 应答，那么一段时间后，服务端自动关闭这个连接。但是客户端认为这个连接已经建立，如果客户端端向服务端写数据，服务端端将以 RST 包响应，客户端就可以感知到错误。
