前端也要知道的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 是如何做到可靠的。

1. 校验：如果接收端校验出包有错，则进行丢弃且不进行响应
2. 排序：在将数据包交给应用层之前，TCP 协议会保证数据包的有序性
3. 去重：丢弃重复的数据
4. 应答：接收方接收到数据后，将发送确认信息给发送方
5. 超时重发：当发送方发出数据后，会启动一个定时器，当超过定时器时限后，会重新发这个报文段
6. 流量控制：利用固定大小的缓冲空间防止接收方缓冲区溢出

三次握手

我想不管你了不了解这些协议，你都会听说过三次握手。

我们把客户端和服务器每一次交互都比喻成一次握手，那么简单来说，当建立一个 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 包响应，客户端就可以感知到错误。