TCP三次握手和四次挥手

TCP报文格式：

其中：

• 序号号码：seq，是随机生成的用来表示当前的这个报文序号是多少
• 确认号码：ack（acknowledgement number）对上一次发送的信息进行确认，每次都是+1
• ACK：确认标志位。占1个比特位，仅当ACK=1，确认号字段才有效。ACK=0，确认号无效。
• SYN:连接建立时用于同步序号。当SYN=1，ACK=0表示：这是一个连接请求报文段。若同意连接，则在响应报文段中使用SYN=1，ACK=1.因此，SYN=1表示这是一个连接请求，或连接接收报文，SYN这个标志位只有在TCP建立连接才会被置为1，握手完成后SYN标志位被置为0.
• FIN:1表示关闭连接

TCP连接：

通俗解释：
Tcp协议是传输层面向连接安全可靠的一个传输协议，三次握手的机制是为了保证能建立一个安全可靠的连接：

• 第一次握手，是由客户端发起，客户端会向服务端发送一个报文，在报文里面SYN位标志位是置1的
• 当服务端收到这个报文之后就知道，客户端要跟我发起一个新的连接，于是服务端就像客户端发送一个确认消息报文，这个消息报文里面ACK位置1
• 以上两次握手之后，其实对于客户端而言知道了所有的信息，我既能给服务端发消息，我还能收到服务端的消息。但是对服务端而言两次握手是不够的，因为到目前为止服务端只知道一件事情，就是客户端给我的消息我能收到，但是我发给客户端的消息客服端能不能收到不知道，所以呢还要进行第三次握手。
• 第三次握手就是当客户端收到服务端发过来的确认消息的报文之后，还要继续给服务端进行一个回应，也是ACK位置1一个确认消息，通过以上三次链接，不管是服务端还是客户端，都彼此知道了彼此既能给对方发消息也能收到对方的消息，那这个链接就被安全的建立。

常见面试问题：三次握手中，为什么客户机最后还要再向服务器发送一次确认呢？

答：这是为了防止已失效的连接请求报文段突然又传到了服务器。所谓“已失效的连接请求报文段”是这样产生的。考虑一种正常的情况，客户机发出连接请求，但因为连接请求报文丢失而未收到确认。于是客户机再重传了一次连接请求，后来收到了确认，建立了连接。数据传输完后，就释放了连接。客户机共发送了两个连接请求报文段，其中第一个丢失，第二个到达了服务器，没有所谓的“已失效的连接请求报文段”。

但是如果出现了一种异常情况，即客户机发出的第一个报文段并没有丢失，而是在某个节点上长时间滞留了，直至客户机向服务器发送了第二个报文段并且已经完成数据传输释放了连接，此时，第一个报文到达服务器后会被误以为是客户机重新发起的一次连接请求，实质上是一个早已失效的连接请求。如果没有第三次握手，那么这个连接就建立了，但是客户机并不会向服务器发送任何请求，这样连接就会一直持续，白白的消耗网络资源。

TCP连接释放：

• 四次挥手也是由客户端首先发起的，客户端会发送一个报文，在报文里面FIN位标志位置1，当服务端收到这个报文，我就知道了客户端想要跟我断开链接
• 但是此时服务端不一定能做好准备，因为当客户端发起断开链接的这个消息，对于服务端而言他可能还有未发送完的消息还要继续发送，此时对于服务端而言只能进行一个消息确认，就是我先告诉服务端我知道你要跟我断开链接，但我可能还没最好准备，你需要等我一下等会告诉你
• 于是呢，发完这个消息确认报文之后可能稍过片刻，他就继续发送一个断开连接报文，是一个FIN置1报文，是由服务端发给客户端的。这个报文表示了服务端已经做好了断开连接的装备
• 那么当这个报文发给客户端的时候，客户端同样要给服务端继续发送一个消息确认的报文，一共有四次。那么通过这四次的相互沟通和连接我就知道了，不管是服务端还是客户端都已经做好了断开连接的准备，于是连接就可以被断开了。

问：为什么客户机发送完最后一个数据后要在TIME-WAIT状态等待 2MSL（四分钟）的时间呢？

答：第一：为了保证客户机最后发送的那个ACK报文段能够到达服务器。这个ACK报文段可能会丢失。因而使处在LAST-ACK状态的B收不到对已发送的FIN＋ACK报文段的确认。服务器会超时重传这个FIN＋ACK报文段，而客户机就能在2MSL时间内收到这个重传的FIN+ACK报文段。接着客户机重传一次确认，重新启动2MSL计时器，最后客户机和服务器都可以进入到CLOSED（关闭）状态。如果没有2MSL等待时间，那么就无法收到重传的FIN+ ACK包，无法进入正常的CLOSED状态。
第二，防止“已失效的连接请求报文段”出现在本连接中。客户机在发送完最后一个ACK报文段，再经过时间2MSL，就可以使本连接持续的时间内所产生的报文段都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段。

参考资料：https://blog.csdn.net/wwl012345/article/details/90261423

TCP和UDP区别和应用场景

区别：

TCP（Transmission Control Protocol，传输控制协议）提供的是面向连接，可靠的字节流服务。即客户和服务器交换数据前，必须现在双方之间建立一个TCP连接，之后才能传输数据。并且提供超时重发，丢弃重复数据，检验数据，流量控制等功能，保证数据能从一端传到另一端。

UDP（User Data Protocol，用户数据报协议）是一个简单的面向数据报的运输层协议。它不提供可靠性，只是把应用程序传给IP层的数据报发送出去，但是不能保证它们能到达目的地。由于UDP在传输数据报前不用再客户和服务器之间建立一个连接，且没有超时重发等机制，所以传输速度很快。

应用场景：

TCP一般用于文件传输（FTP HTTP 对数据准确性要求高，速度可以相对慢），发送或接收邮件（POP IMAP SMTP 对数据准确性要求高，非紧急应用），远程登录（TELNET SSH 对数据准确性有一定要求，有连接的概念）等等；

UDP一般用于即时通信（QQ聊天 对数据准确性和丢包要求比较低，但速度必须快），在线视频（RTSP 速度一定要快，保证视频连续，但是偶尔花了一个图像帧，人们还是能接受的），网络语音电话（VoIP 语音数据包一般比较小，需要高速发送，偶尔断音或串音也没有问题）等等

TCP阻塞控制

1.什么是拥塞控制

1.拥塞控制就是防止过多的数据注入网络中，这样可以使网络中的路由器或链路不致过载。

2.拥塞控制要考虑的因素

1.拥塞控制所作的都有一个前提，就是网络能够承受现有的网络负荷。

2.拥塞控制是一个全局性的过程，涉及到所有的主机、所有的路由器，以及与降低网络传输性能有关的所有因素。

3.TCP连接的端点只要迟迟不能收到对方的确认信息，就猜想在当前网络中的某处可能发生了拥塞，但这时却无法知道拥塞到底发生在网络的何处，也无法知道发生拥塞的具体原因。

3.拥塞控制的方法：

1.慢开始

2.拥塞避免

3.快重传

4.快恢复