UDP和TCP（UDP/TCP特性及TCP的三次握手四次挥手）

回顾：网络传输设计协议考虑的两个因素：效率、安全

一、UDP协议（用户数据报协议）

  格式：

特点：

• 无连接: 知道对端的IP和端口号就直接进行传输, 不需要建立连接直接发送数据
• 不可靠: 没有类似TCP保证数据传输的安全机制（连接管理机制、确认应答机制，超时机制），但是效率更高
• 面向数据报: 不能够灵活的控制读写数据的次数和数量（应用层交给UDP多长的报文，UDP原样发送，既不会拆分也不会合并），只能一次接收（系统级别的操作：调用系统函数）

          

• 没有发送缓冲区（发了消息就不管），有接收缓存区
• 传输数据的最大长度为64K

基于 UDP传输层协议之上 的应用层协议：

1. NFS: 网络文件共享
2. TFTP: 简单文件传输协议
3. DHCP: 动态主机配置分配协议
4. BOOTP: 启动协议(用于无盘设备启动)
5. DNS: 域名解析协议 （域名转IP）

二、TCP协议（，传输控制协议，可靠传输）

1. 确认应答机制       （安全机制）
2. 超时重传机制       （安全机制）
3. 连接管理机制       （安全机制）
4. 滑动窗口              （效率机制）
5. 流量控制              （安全机制）
6. 拥塞控制              （安全机制）
7. 延迟应答              （效率机制）
8. 捎带应答              （效率机制）

TCP特性：

• 有连接
• 可靠（安全）
• 面向字节流
• 同时存在发送缓冲区和接收缓冲区
• 传输数据大小无限制

TCP是可靠，稳定的，TCP的可靠体现在TCP在传递数据之前，会有三次握手来建立连接，而且在数据传递时，有确认应答、超时重传、连接管理、流量管理、拥塞控制机制，在数据传完后，还会四次挥手断开连接用来节约系统资源。 但是它相对UDP较慢，效率低，占用系统资源高，而且在数据传递时，确认机制、重传机制、拥塞控制机制等都会消耗大量的时间，而且要在每台设备上维护所有的传输连接，每个连接都会占用系统的CPU、内存等硬件资源.

UDP没有TCP的确认应答、超时重传、连接管理、流量管理、拥塞控制等机制，是一个无状态的传输协议，所以它在传递数据时非常快。但是UDP不可靠、不稳定，因为UDP没有TCP那些可靠的机制，在数据传递时，如果网络质量不好，就会很容易丢包.
 

不是百分百安全，但尽可能提高网络传输数据的效率

格式：

• 源/目的端口号: 表示数据是从哪个进程来, 到哪个进程去
• 4位TCP报头长度: 表示该TCP头部有多少个32位bit(有多少个4字节)，所以TCP头部最大长度是15 * 4 = 60
• 6位标志位:

        （1） URG: 紧急指针是否有效

        （2）ACK: 确认号是否有效

        （3） PSH: 提示接收端应用程序立刻从 TCP 缓冲区把数据读走

        （4）RST: 对方要求重新建立连接 ; 我们把携带 RST 标识的称为 复位报文段

        （5） SYN: 请求建立连接 ; 我们把携带 SYN 标识的称为同步报文段

        （6） FIN: 通知对方, 本端要关闭了 , 我们称携带 FIN 标识的为 结束报文段

• 16位校验和: 发送端填充, CRC校验.，接收端校验不通过, 则认为数据有问题.，此处的检验和不光包含TCP首部, 也 包含TCP数据部分
• 16位紧急指针: 标识哪部分数据是紧急数据

（一）确认应答（ACK）机制---安全机制

       

1. 保证安全（我发送的消息，对方必须确认回复）
2. 保证多条数据确认消息的安全  序号+确认序号

             发送时携带数据序号，确认回复时携带确认序号

（二）超时重传机制---安全机制

   （1）数据报丢了的可能的情况：

• 主机A发送数据给B之后, 可能因为网络拥堵等原因, 数据无法到达主机B
• 如果主机A在一个特定时间间隔内没有收到B发来的确认应答, 就会进行重发

          

 （2）ACK确认应答数据报丢失

        发送数据之后，在特定的时间间隔内未收到确认应答，主机A在之后会重新发送数据继续等待主机B的确认应答数据，因此主机 B 会收到很多重复数据。这时候可以利用前面提到的序列号, 做到 去重 的效果 .

            

如果超时的时间如何确定?

最理想的情况下 , 找到一个最小的时间 , 保证 " 确认应答一定能在这个时间内返回 "，但是这个时间的长短, 随着网络环境的不同 是有差异的，如果超时时间设的太长, 会影响整体的重传效率， 如果超时时间设的太短, 有可能会频繁发送重复的包

TCP为了保证比较高性能的通信，会动态计算这个最大超时时间

根据当前网络环境的情况（决定发送数据的速度得到单词报文发送的最大生存时间为msl，超时时间即为2msl）

 Linux 中 (BSD Unix 和 Windows 也是如此 ),， 超时以500ms 为一个单位进行控制，   每次判定超时重发的超时时间都是 500ms的整数倍 ，如果重发一次之后， 仍然得不到应答 ， 等待 2*500ms 后再进行重传， 如果仍然得不到应答， 等待 4*500ms 进行重传，   依次类推，   以 指数形式递增 ， 累计到一定的重传次数， TCP 认为网络或者对端主机出现异常 ， 强制关闭连接。

（三）连接管理机制---安全机制

     

建立连接

步骤

1. 主机A发送syn建立连接的数据报到主机B
2. 主机B响应ack给主机A+ 主机B发送给主机A的syn
3. 主机A响应ack给主机B

问题1：syn为什么有两个？

    答：双方保存连接状态（有方向的连接）

问题2：第二步为什么是ack + syn？

     答：本质上是一个ack应答，一个syn请求，方向相同的两个数据可以合并在一起

问题3：第三步ack确认应答哪一个？

      答：应答第二步的syn

三次握手流程

• 主机A发送syn到主机B，要求建立主机A到主机B的连接，主机A状态设置为syn_sent
• 主机B收到主机A发送的请求，发送ack（确认主机A到主机B的连接）和syn到主机A，要求建立主机B到主机A的连接，主机B的状态设置为syn_rcvd
• 主机A收到并回复第二步syn的ack，（发送ack，确认主机B到主机A的连接）主机A状态设置为established，建立主机A到主机B的连接，主机B接收到第三步主机A的数据报，建立主机B到主机A的连接

关闭连接

四次挥手流程

• 主机A发送fin到主机B，请求关闭主机A到主机B的连接
• 主机B回复ack，主机B状态设置为close_wait
• 主机B发送fin到主机A，请求关闭主机B到主机A的连接
• 主机A回复ack（确认应答第三步的fin），状态设置为time_wait，主机B接收到第四步的数据报，状态设置为closed ，主机A经过2msl(超时等待时间)之后，状态设置为closed

问题1：第二步和第三步为什么不能合并？

      答：第二步是tcp协议在系统内核实现时字段响应的ack（系统自动响应的数据包），第三步是应用程序手动调用close来关闭连接。程序在关闭连接时可能需要执行释放资源等前置操作，所以不能合并（tcp协议实现时，没有这样的设计）

问题2：第三步主机A为什么不能直接设置closed状态？

       答：第四个数据报(ack)可能丢包，主机B到达超时时间后，重发的三个数据报(fin)，会要求主机A再次回复ack

问题3：服务器出现大量的close_wait（半关闭状态）状态是什么原因？要如何解决？

       答：出现大量的close_wait状态是因为服务端没有正确的关闭连接（程序没有调用close，或者没有正确调用close）