第六篇 TCP和UDP网络协议
在网络开发过程中，避免不了要和TCP和UDP打交道，本文就Android端使用情况，对TCP的三次握手和四次挥手进行说明，以及对UDP协议进行相关说明，以便对这两种协议有更好的理解。
概述
按OSI 7层协议划分，TCP / UDP在传输层，是无法后续非系统层面修改的协议逻辑
TCP 协议
TCP是传输控制协议（Transmission Control Protocol），用于通过传输和确保通过支持网络和Internet传递消息来在远程计算机之间创建连接。如果把TCP协议比作
协议特点：
- 面向连接： 是指发送数据之前必须在两端建立连接。建立连接的方法是"三次握手"，这样能建立可靠的连接。建立连接，是为数据的可靠传输打下了基础。
- 仅支持单播传输： 每条TCP传输连接只能有两个端点，只能进行点对点的数据传输，不支持多播和广播传输方式。
- 面向字节流：TCP不像UDP一样那样一个个报文独立地传输，而是在不保留报文边界的情况下以字节流方式进行传输。
- 可靠传输：对于可靠传输，判断丢包，误码靠的是TCP的段编号以及确认号。TCP为了保证报文传输的可靠，就给每个包一个序号，同时序号也保证了传送到接收端实体的包的按序接收。然后接收端实体对已成功收到的字节发回一个相应的确认(ACK)；如果发送端实体在合理的往返时延(RTT)内未收到确认，那么对应的数据（假设丢失了）将会被重传。
- 提供拥塞控制：当网络出现拥塞的时候，TCP能够减小向网络注入数据的速率和数量，缓解拥塞
- 超时重传机制：TCP为了保证无论在任何环境下都能比较高性能的通信，因此会动态计算这个最大超时时间，累计到一定的重传次数，TCP认为网络或者对端主机出现异常，强制关闭连接。不会一直重传。
三次握手
SYN 就是 TCP 中建立连接时的标识，ACK 是确认标识。
- 首先主机A 和主机B 之间需要连接而客户端先发送一次 SYN
- 服务器就会返回一个 ACK，表示客户端要和服务器建立连接，然后服务器再给客户端发送一个 SYN
- 客户端在返回一个 ACK，表示服务器要和客户端建立连接，完成四次交互，就可以确保建立连接成功了
虽然是四次交互，由于中间这两次 (SYN 和 ACK) 是一定会合二为一的，只需要把 ACK 和 SYN 同时置为1就可以了，因此被称为三次握手。
为什么一定是三次？ ：四次可以，但是效率低，没有必要。每次传输的数据都需要进行一系列的封装和分用, 因此传输两次肯定要比传输一次慢很多。两次是绝对不行的，两次只能确定双方中一方的发送和接收能力正常，另一方就不清楚了,这是不满足可靠性。简而言之，三次握手是通过最小次数确保了双方都有发送和接收消息的能力。
四次挥手
FIN 是通知对方, 本端要关闭连接的结束报文段标识。
这里四次挥手就是双方各自给对方发送 FIN，并在收到对方的 FIN 请求后回复一个 ACK。
三次握手的发起方一定是客户端,而四次挥手的发起方有可能是客户端，也有可能是服务器，而且三次握手中间两次是可以合并的，而四次挥手的中间两次是不一定能合并的，这里能否合并取决于 B 发送 ACK 和发送 FIN 的时机是否相同，相同的话是可以合并的，不相同的话是不能合并的。
三次握手中服务器所发送的 SYN 和 ACK 都是由操作系统内核负责执行，收到客户端的 SYN 请求之后，会把 ACK 和 SYN 同一时间发送过去，这是同一时机发生的因此是可以合并的。
四次挥手 B 给 A 发送的 ACK 是有操作系统内核负责的，而 FIN 请求只有当 B 中的代码执行到了 socket.close() 方法才会出发 FIN，如果这两操作中间间隔的时间比较短是可以合并的，间隔时间长就不能合并了，这是无法确定的，因此一般情况下都是四次交互过程，也就是四次挥手！
简单来说，四次挥手的原因是因为双方断开的时机不同，客户端和服务端都需要执行一次发起关闭和确认关闭的操作，一共是四次？
可以三次挥手吗？：如果服务端的信息在接受到客户端的数据时已经传输完了，自然是可以将自身的结束FIN信号和确认ACK信号合并至一次发出，但是实际情况是因为ACK是接收到FIN后很快就发出了，此时的服务端或许还有数据没有传完，为了避免造成了不必要的资源浪费甚至更意想不到的问题，使用四次是更合理的。
适用场景：
- HTTP请求：基于TCP实现的
- SMTP 邮件协议
UDP 协议
UDP是User Datagram Protocol（用户数据报协议）的简称。UDP 为应用程序提供了一种无需建立连接就可以发送封装的 IP 数据包的方法。
类似以前的信件传递，UDP不需要知道最后这封信有没有被送到需要的人手上，他只负责把这封信和携带的数据填上地址并塞入信箱。
协议特点：
- 无连接：只知道对端的IP和端口号就可以发送，不需要实现建立连接。(就像寄信)。
- 不可靠：没有确认机制， 没有重传机制。如果因为网络故障该段无法发到对方， UDP协议层也不会给应用层返回任何错误信息。
- 面向数据报： 应用层交给UDP多长的报文， UDP原样发送既不会拆分，也不会合并。所以UDP不能够灵活的控制读写数据的次数和数量。
- UDP存在接收缓冲区，但不存在发送缓冲区：UDP没有发送缓冲区，在调用send to时会直接将数据交给内核，由内核将数据传给网络层协议进行后续的传输动作。UDP具有接收缓冲区，但是这个接收缓冲区不能保证收到的UDP报文的顺序和发送UDP报的顺序一致，如果缓冲区满了再到达的UDP数据报就会被丢弃。
- 大小受限：UDP协议首部中有一个16位的最大长度。也就是说一个UDP能传输的数据最大长度是64K（包含UDP首部）。
适用场景：
- IP地址配置 DHCP
- 远程文件服务器
- IP电话
- 流式多媒体通信
- ...等等对可靠性要求不高的情况
可能遇到的相关问题
- 为什么UDP不需要发送缓冲区？
因为UDP不保证可靠性，它没有重传机制，当报文丢失时，UDP不需要重新发送，而TCP不同，他必须具备发送缓冲区，当报文丢失时，TCP必须保证重新发送，用户不会管，所以必须要具备发送缓冲区。