网络协议-TCP、UDP区别及TCP三次握手、四次挥手

网络的五层划分

• 应用层
  常见协议：HTTP (Hyper Text Transfer Protocol),FTP(文件传输协议)，DNS（域名解析协议）
• 传输层
  常见协议：TCP(传输控制协议)，UDP(用户数据报协议)
• 网络层
  常见协议：IP
• 数据链路层
• 物理层

TCP 和 UDP 的区别

• TCP/UDP都属于传输层协议
• TCP是面向连接的传输层协议，能够准确可靠的把数据传递给对方，当数据有丢包情况会重发，但是需要在建立和断开连接需要至少7次的发包和收包，会浪费网络流量，主要用在对可靠性要求较高的地方
• UDP是面向无连接的传输层协议，即只负责传输数据，不能确保对方是否收到数据和数据的正确顺序，数据的正确性由应用层来校验，主要用于高传输和实时性要求较高的场合如音视频会议，广播。

序列号，确认号

• 序列号seq（Sequence Numbers）：用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记
• 确认序号ACK（Acknowledge Number）：在接收端，用来通知发送端数据成功接收;其数值等于发送方的发送序号+1(即接收方期望接收的下一个序列号)；
• 标志位：
  （A）SYN：创建一个连接
  （B）ACK：确认序号有效
  （C）FIN：终结一个连接
  （D）RST：重置连接。
  （E）PSH：接收方应该尽快将这个报文交给应用层。
  （F）URG：紧急指针（urgent pointer）有效。

TCP 三次握手

1. 第一次握手：
   建立连接。客户端发送连接请求报文，将 SYN 设置为 1、Sequence Number（seq）为x；接下来客户端进入 SYN_SENT 状态，等待服务端的确认。
2. 第二次握手：
   服务器端收到客户端的 SYN 报文段，对 SYN 报文段进行确认，设置Acknowledge Number（ACK）为x+1(seq+1)；同时自己还要发送 SYN 请求信息，将 SYN 设置为1，seq 为 y。服务端将上述所有信息放到 SYN+ACK 报文段中，一并发送给客户端，此时服务端进入SYN_RCVD 状态。
3. 第三次握手：
   客户端接收到服务器的 SYN+ACK 报文段；然后将 ACK 设置为 y+1，向服务端发送 ACK 报文段，这个报文段发送完毕后，客户端和服务端都进入ESTABLISHED（TCP连接成功）状态，完成TCP的三次握手。

当客户端和服务端通过三次握手建立了 TCP 连接以后，当数据传输完毕，断开连接时就需要进行 TCP 的四次挥手。

TCP 四次挥手

• 由于TCP连接时全双工的，因此，每个方向都必须要单独进行关闭，这一原则是当一方完成数据发送任务后，发送一个FIN（终结一个连接）来终止这一方的连接，收到一个FIN只是意味着这一方向上没有数据流动了，即不会在收到数据了，但是在这个TCP连接上仍然能够发送数据，直到这一方向也发送了FIN。首先进行关闭的一方将执行主动关闭，而另一方则执行被动关闭。

• 第一次挥手：
  客户端设置 seq 和 ACK，向服务端发送一个 FIN 报文段。此时，客户端进入 FIN_WAIT_1 状态，表示客户端没有数据要发送给服务端了。

• 第二次挥手：
  服务端收到客户端发送的 FIN 报文，向客户端回了一个 ACK 报文段。

• 第三次挥手：
  服务器向客户端发送 FIN 报文段，请求关闭连接，同时服务端进行 LAST_ACK 状态

• 第四次挥手：
  客户端收到服务器发送的 FIN 的报文段，向服务端发送 ACK 报文段，然后客户端进入到 TIME_WAIT 状态。服务端收到客户端的 ACK 报文段后，就关闭连接。此时，客户端等待2MSL（最大报文段生成时间）后依然没有收到回复，则说明服务端已正常关闭，这样客户端就可以关闭连接了。

• 为什么要等待 2MSL
  客户端发送的第4次握手报文，服务器没有收到。这时候服务器端会再次发送一个 FIN =1 的报文，而这个时候客户端还处于 TIME_WAIT 状态，所以可以再次发送确认消息。

如果有大量的连接，每次在连接、关闭时都要经历三次握手、四次挥手，这很显然会造成性能低下。因此，HTTP 有一种叫作 keepalive connections 的机制，它可以在传输数据后仍然保持连接，当客户端需要再次获取数据时，直接使用刚刚空闲下来的连接而无须再次握手。

• 为什么需要三次握手，两次确认？
  为什么客户端还要发送一次确认呢，主要是为了防止已失效的链接请求报文突然又传到了服务器端，造成错误。比如：客户端发送链接请求，因为网络或者一些其它因素造成没有在一定时间到达服务器端，所以客户没有收到确认。由于客户端会重发一次链接请求，通过三次握手与服务器建立连接，但是这时上次的请求到达服务器端了，服务器会误以为客户端又发了一次新的链接请求，会向客户端发送报文同意建立连接，但是客户端已经建立连接了，就会放弃该报文，服务端没有收到响应，也就不会建立连接了。

• 三次握手出现错误时的应对措施？
  第一次握手A发送SYN传输失败，A,B都不会申请资源，连接失败。如果一段时间内发出多个SYN连接请求，那么A只会接受它最后发送的那个SYN的SYN+ACK回应，忽略其他回应全部回应，B中多申请的资源也会释放

  第二次握手B发送SYN+ACK传输失败，A不会申请资源，B申请了资源，但收不到A的ACK，过一段时间释放资源。如果是收到了多个A的SYN请求，B都会回复SYN+ACK，但A只会承认其中它最早发送的那个SYN的回应，并回复最后一次握手的ACK

  第三次握手ACK传输失败，B没有收到ACK，释放资源，对于后序的A的传输数据返回RST(重置连接)。实际上B会因为没有收到A的ACK会多次发送SYN+ACK，次数是可以设置的，如果最后还是没有收到A的ACK，则释放资源，对A的数据传输返回RST