计算机网络面试题：1.TCP和UDP区别

一、TCP和UDP

TCP和UDP都是传输层的协议。在程序之间传输数据（文本文件、视频、图片）。

    

 

TCP

TCP 是面向连接的、可靠的流协议。流就是指不间断的数据结构，当应用程序采用 TCP 发送消息时，虽然可以保证发送的顺序，但还是犹如没有任何间隔的数据流发送给接收端。TCP是面向字节流，虽然应用程序和TCP的交互是一次一个数据块（大小不等），但TCP把应用程序看成是一连串的无结构的字节流。TCP有一个缓冲，当应用程序传送的数据块太长，TCP就可以把它划分短一些再传送。

TCP 为提供可靠性传输，实行“顺序控制”或“重发控制”机制。此外还具备“流控制（流量控制）”、“拥塞控制”、提高网络利用率等众多功能。

TCP有以下特点：

• TCP充分地实现了数据传输时各种控制功能，可以进行丢包时的重发控制，还可以对次序乱掉的分包进行顺序控制。而这些在 UDP 中都没有。
• 此外，TCP 作为一种面向有连接的协议，只有在确认通信对端存在时才会发送数据，从而可以控制通信流量的浪费。
• 根据 TCP 的这些机制，在 IP 这种无连接的网络上也能够实现高可靠性的通信（ 主要通过检验和、序列号、确认应答、重发控制、连接管理以及窗口控制等机制实现）。

UDP

UDP 是面向报文的，所谓面向报文，是指面向报文的传输方式是应用层交给UDP多长的报文，UDP就照样发送，即一次发送一个报文。因此，应用程序必须选择合适大小的报文。若报文太长，则IP层需要分片，降低效率。若太短，会是IP太小。

UDP 是不具有可靠性的数据报协议，细微的处理它会交给上层的应用去完成。在 UDP 的情况下，虽然可以确保发送消息的大小，却不能保证消息一定会到达。因此，应用有时会根据自己的需要进行重发处理。

UDP有以下特点：

• UDP 不提供复杂的控制机制，利用 IP 提供面向无连接的通信服务。
• 传输途中出现丢包，UDP 也不负责重发。
• 当包的到达顺序出现乱序时，UDP没有纠正的功能。
• 并且它是将应用程序发来的数据在收到的那一刻，立即按照原样发送到网络上的一种机制。即使是出现网络拥堵的情况，UDP 也无法进行流量控制等避免网络拥塞行为。
• 如果需要以上的细节控制，不得不交由采用 UDP 的应用程序去处理。
• UDP 常用于以下几个方面：
  • 1.包总量较少的通信（DNS、SNMP等）；
  • 2.视频、音频等多媒体通信（即时通信）；
  • 3.限定于 LAN 等特定网络中的应用通信；
  • 4.广播通信（广播、多播）

1.TCP和UDP区别

2.TCP如何确定连接

序列号seq： 用来标记数据段的顺序；
确认号ack： 期待收到对方下一个报文段的第一个数据字节的序号；
确认ACK： 仅当ACK=1时，确认号字段才有效。ACK=0时，确认号无效
同步SYN： 连接建立时用于同步序号。

2.1三次握手（TCP建立连接）

三次握手：在不可靠的信道上建立可靠的连接。

（1）第一次握手：Client将标志位SYN置为1，随机产生一个值seq=J，并将该数据包发送给Server，Client进入syn_sent状态，等待Server确认。

（2）第二次握手：Server收到数据包后由标志位SYN=1知道Client请求建立连接，Server将标志位SYN和ACK都置为1，ack=J+1，随机产生一个值seq=K，并将该数据包发送给Client以确认连接请求，Server进入syn_rcvd状态。

（3）第三次握手：Client收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，并将该数据包发送给Server，Server检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，Client和Server进入established状态，完成三次握手，随后Client与Server之间可以开始传输数据了。
 

 Q1:握手为什么需要三次呢，如果把最后一次的去掉改为两次握手是否可行呢?

      假如客户端向服务端进行握手，进行第一次请求时，可能会遇到网络信号差或者服务器负载过多，导致这个握手请求没有立即达到服务端这就形成了一个失效的握手连接，但是服务端接收到失效的请求报文就会误认为是客户端又发了一次连接请求，服务端就会进行第二次握手。

如果说TCP握手是两次的话，只要服务端确认消息就算建立连接了，这是不可靠的。

     假如现在客户端并没有发出建立连接的请求，之前发过的这个请求是失效的请求，一切都是服务端在自相情愿，因此客户端是不会理睬服务端的确认信息，也不会向服务端发送确认的请求，但是服务器却认为新的连接已经建立起来了，并一直等待客户端发来数据，这样的情况下，服务端的很多资源就没白白浪费掉了。

总结：TCP 采用三次握手的办法就是为了防止上述这种情况的发生，比如客户端不会向服务端发出确认的请求，服务端会因为收不到确认的报文，就知道客户端并没有要建立连接，那么服务端也就不会去建立连接，这就是三次握手的作用。

Q2:如何处理TCP丢包问题？

为了满足TCP协议不丢包。TCP协议有如下规定：

数据分片：发送端对数据进行分片，接受端要对数据进行重组，由TCP确定分片的大小并控制分片和重组

到达确认：接收端接收到分片数据时，根据分片数据序号向发送端发送一个确认

超时重发：发送方在发送分片时设置超时定时器，如果在定时器超时之后没有收到相应的确认，重发分片数据

滑动窗口：TCP连接的每一方的接受缓冲空间大小固定，接收端只允许另一端发送接收端缓冲区所能接纳的数据，TCP在滑动窗口的基础上提供流量控制，防止较快主机致使较慢主机的缓冲区溢出

失序处理：作为IP数据报来传输的TCP分片到达时可能会失序，TCP将对收到的数据进行重新排序，将收到的数据以正确的顺序交给应用层;

重复处理：作为IP数据报来传输的TCP分片会发生重复，TCP的接收端必须丢弃重复的数据;

数据校验：TCP将保持它首部和数据的检验和，这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到分片的检验或有差错，TCP将丢弃这个分片，并不确认收到此报文段导致对端超时并重发

2.2四次挥手（TCP断开连接）

在断开连接之前客户端和服务器都处于ESTABLISHED状态，双方都可以主动断开连接，以客户端主动断开连接为优。

 

（1）第一次挥手：客户端打算断开连接，向服务器发送FIN报文(FIN标记位被设置为1，1表示为FIN，0表示不是)，FIN报文中会指定一个序列号，之后客户端进入FIN_WAIT_1状态。

也就是客户端发出连接释放报文段(FIN报文)，指定序列号seq = u，主动关闭TCP连接，等待服务器的确认。

（2）第二次挥手：服务器收到连接释放报文段(FIN报文)后，就向客户端发送ACK应答报文，以客户端的FIN报文的序列号 seq+1 作为ACK应答报文段的确认序列号ack = seq+1 = u + 1。

接着服务器进入CLOSE_WAIT(等待关闭)状态，此时的TCP处于半关闭状态(下面会说什么是半关闭状态)，客户端到服务器的连接释放。客户端收到来自服务器的ACK应答报文段后，进入FIN_WAIT_2状态。

（3）第三次握手：服务器也打算断开连接，向客户端发送连接释放(FIN)报文段，之后服务器进入LASK_ACK(最后确认)状态，等待客户端的确认。

服务器的连接释放(FIN)报文段的FIN=1，ACK=1，序列号seq=m，确认序列号ack=u+1。

（4）第四次握手：客户端收到来自服务器的连接释放(FIN)报文段后，会向服务器发送一个ACK应答报文段，以连接释放(FIN)报文段的确认序号 ack 作为ACK应答报文段的序列号 seq，以连接释放(FIN)报文段的序列号 seq+1作为确认序号ack。

之后客户端进入TIME_WAIT(时间等待)状态，服务器收到ACK应答报文段后，服务器就进入CLOSE(关闭)状态，到此服务器的连接已经完成关闭。

客户端处于TIME_WAIT状态时，此时的TCP还未释放掉，需要等待2MSL后，客户端才进入CLOSE状态。

Q1:为什么是四次挥手而不是三次挥手？

 某些情况下是可以的，但普遍情况是不行。

四次挥手把同意对方请求跟自身请求分离开。是因为在客户端请求断开时（客户端发送端->服务器接收端），服务器可能还有数据未发完，所以需要分开操作：

先同意对方关闭连接，对方无法传输数据；（第二次挥手）
自己若还有数据未发送完，接着发送直至全部发送完毕；
请求自身关闭连接；（第三次挥手）
也就是说，三次挥手、四次挥手差别就在第二次，有没有把同意对方请求跟自身请求拆分开。

如果客户端请求关闭连接时，服务器并没有数据需要发送，其实三次挥手应该也是可以的。但一般情况下，客户端猝不及防地请求断开连接，服务器还是有数据需要传输的，所以四次挥手更加地稳妥。

一条视频讲清楚TCP协议与UDP协议-什么是三次握手与四次挥手_哔哩哔哩_bilibili