内容来源 B站 一条视频讲清楚TCP协议与UDP协议-什么是三次握手与四次挥手
仅供个人学习参考，面试宝典
应用层 - 传输层 - 网络层 - 数据链路层 - 物理层
tcp和udp都工作在传输层，他们的目标都在程序之间传输数据。数据可以是文本文件，可以是视频，也可以是图片。对于tcp协议和upd 协议来说，都是一堆二进制数，并没有多大区别。
两个协议最大的区别一个基于连接，一个基于非连接。
如果把人与人之间的通信比喻为进程与进程的通信。基本有两种方式，第一种是写信，第二种方式是打电话。
如果不考虑速度因素，这两者之间最大的区别就是信寄出去对方是否能收到，以及收到的信的内容是否完整，先后寄两封信过去是否按照顺序接收都变成了未知数，甚至填写的收信地址和收信人是否存在，都无法确认；而打电话则不同，从拨打电话到对方接通，互相通话，再到结束通话后挂断。这一系列的流程都能得到及时的反馈，并且能确认对方准确的接收到。
打电话也是基于链接的也就是TCP，而写信就是基于非连接的就是UDP。
TCP协议
保证传输过程的三个关键的步骤，分别为三次握手、传输确认、四次挥手。
三次握手
三次握手是建立连接的过程，当客户端向服务端发起连接时，会先发一包连接请求数据，过去询问一下，能否与你建立连接，这包数据我们称之为SYN包。如果对端同意连接，则回复一包SYN+ACK包，客户端收到之后回复一包ACK包连接建立。
因为这个过程中互相发送了三包数据，所以称之为三次握手。
Q：为什么要三次握手，而不是两次握手，服务端回复完SYN+ACK包之后就建立连接
A：这是为了防止因为已失效的请求报文突然又传到服务器引起错误。解决网络信道不可靠的问题
Q：为什么不是四次握手？
A：因为通信不可能100%可靠，而上面的三次握手已经做好了通信的准备工作，再四次握手，并不能显著提高可靠性，而且也没有必要。
假设采用两次握手建立连接，客户端向服务端发送了一个SYN包，因为某些未知的原因，并没有到达服务器。在中间某个网络节点产生了滞留。为了建立连接，客户端会重发SYN包，这次的数据包正常送达，服务端回复SYN+ACK包之后建立了连接。但是第一包数据阻塞的网络节点突然恢复，第一包SYN包又送达到服务器，这时服务端会误认为是客户端又发起了一个新的连接，从而在两次握手之后，进入等到数据状态。服务端认为是两个连接，而客户端认为是一个连接，造成了状态不一致。
如果在三次握手的情况下，服务端收不到最后的ACK包，自然不会认为连接建立成功，所以三次握手本质上来说就是为了解决网络信道不可靠的问题。为了能在不可靠的信道上，建立可靠的连接。
数据传输
经过三次握手之后，客户端和服务端都进入了数据传输状态。tcp协议需要在不可靠的信道上保证可靠的连接。现在就有几个问题需要面对：1. 一包数据有可能被拆成多包发送，如何处理丢包问题 ；2. 这些数据包到达的先后顺序不同，如何处理乱乱序问题。
针对以上的要求，TCP协议为每一个连接建立了一个发送缓冲区，从建立链接后的第一个字节的序列号为0，后面每个字节的序列号就会增加1。发送数据时，从发送缓冲区，取一部分数据组成发送报文，在其tcp协议头中会附带序列号和长度，接受端在收到数据后，需要回复确认报文。确认报文中的ACK，等于接收序列号加长度，也就是下一包数据需要发送的起始序列号。
这样一问一答的发送方式，能够使发送端确认发送的数据已经被对方收到，发送端也可以一次发送连续多包数据，接收端只需要回复一次ACK就可以了，这样发送端可以把待发送的数据分割成一系列的碎片，发送到对端。对端根据序列号和长度，在接受后重构出来完整的数据，假设其中丢失了某些数据包，在接收端可以要求发送端重传。比如丢失了100-199，这100个字节，接收端向发送端发送ACK = 100 报文，发送端收到后重传这一包数据，接受端进行补齐。
以上过程不区分客户端和服务端，TCP连接是全双工的，对于两端来说均采用上述机制。
处于连接状态的客户端和服务端都可以发起关闭连接请求，此时需要四次挥手来进行连接关闭。
假设客户端主动发起连接关闭请求，他需要将服务端发起一包FIN包，表示要关闭连接，自己进入终止等待1状态，这是第一次挥手。
服务端收到FIN包，发送一包ACK包，表示自己进入了关闭等待状态，客户端进入终止等待2状态，这是第二次挥手。
服务端此时还可以发送未发送的数据，而客户端还可以接收数据，待服务端发送完数据之后，发送一包FIN包，进入最后确认状态，这是第三次挥手。
客户端收到之后回复ACK包，进入超时等待状态，经过超时时间后关闭连接，而服务端收到ACK包后，立即关闭连接，这是第四次挥手。
Q：为什么客户端需要等待超时时间？
A：为了保证对方已收到ACK包，因为假设客户端发送完最后一包ACK包后就释放了连接，一旦ACK包在网络中丢失，服务端将一直停留在最后确认状态；如果客户端发送最后一包ACK包后，等待一段时间，这是服务端会因为没有收到ACK包会重发FIN包，客户端会响应这个FIN包重发ACK包并刷新超时时间。这个机制跟三次握手一样，也是为了保证在不可靠的网络链路中进行可靠的连接断开确认。
UDP协议
基于非连接的。发送数据就是简单的把数据包封装一下，然后从网卡发出去就可以了，数据包之间并没有状态上的联系。
UDP这种简单的处理方式，导致他的性能损耗非常少。对于CPU、内存资源的占用也远小于TCP，但是对于网络传输过程中产生的丢包，UDP协议并不能保证。所以UDP在传输稳定性上要弱于TCP。
可以总结出来TCP和UDP的主要区别：
TCP 传输数据稳定可靠，适用于对网络通讯质量要求较高的场景，需要准确无误的传输给对方。比如传输文件、发送邮件、浏览网页等
UDP 的优点是速度快，但是可能产生丢包，所以适用于对实时性要求较高，但是对少量丢包并没有太大要求的场景，比如域名查询、语音通话、视频直播等
UDP还有一个非常重要的应用场景，就是隧道网络。比如常用的VPN，以及在SDN中用到的VXLAN也是一种隧道网络。
关于三次握手四次挥手更详细的内容
三次握手
- 第一次握手：
客户端发送syn包(Seq=x)到服务器，并进入SYN_SEND状态，等待服务器确认；
- 第二次握手：
服务器收到syn包，必须确认客户的SYN（ack=x+1），同时自己也发送一个SYN包（Seq=y），即SYN+ACK包，此时服务器进入SYN_RECV状态；
- 第三次握手：
客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=y+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。
握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。理想状态下，TCP连接一旦建立，在通信双方中的任何一方主动关闭连接之前，TCP 连接都将被一直保持下去。
四次挥手
数据传输完毕后，双方都可释放连接。最开始的时候，客户端和服务器都是处于ESTABLISHED状态，假设客户端主动关闭，服务器被动关闭。
预览
- 第一次挥手：
客户端发送一个FIN，用来关闭客户端到服务器的数据传送，也就是客户端告诉服务器：我已经不 会再给你发数据了(当然，在fin包之前发送出去的数据，如果没有收到对应的ack确认报文，客户端依然会重发这些数据)，但是，此时客户端还可以接受数据。
FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
- 第二次挥手：
服务器收到FIN包后，发送一个ACK给对方并且带上自己的序列号seq，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号）。此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
- 第三次挥手：
服务器发送一个FIN，用来关闭服务器到客户端的数据传送，也就是告诉客户端，我的数据也发送完了，不会再给你发数据了。由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
- 第四次挥手：
主动关闭方收到FIN后，发送一个ACK给被动关闭方，确认序号为收到序号+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。
至此，完成四次挥手。
