UDP和TCP

TCP和UDP是什么?简述它们有什么区别?

TCP (Transmission Control Protocol)和UDP(User Datagram Protocol)协议属于传输层协议。其中TCP提供IP环境下的数据可靠传输，它提供的服务包括数据流传送、可靠性、有效流控、全双工操作和多路复用。通过面向连接、端到端和可靠的数据包发送。通俗说，它是事先为所发送的数据开辟出连接好的通道，然后再进行数据发送;而UDP则不为IP提供可靠性、流控或差错恢复功能。一般来说，TCP对应的是可靠性要求高的应用，而UDP对应的则是可靠性要求低、传输经济的应用。TCP支持的应用协议主要有:Telnet、FTP、SMTP等;UDP支持的应用层协议主要有:NFS(网络文件系统)、SNMP(简单网络管理协议)、DNS(主域名称系统)、TFTP(通用文件传输协议)等。

二者区别：

连接方面	TCP面向连接（如打电话要先拨号建立连接）。UDP是无连接的，即发送数据之前不需要建立连接。
安全方面	TCP提供可靠的服务，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达。UDP尽最大努力交付，即不保证可靠交付。
传输效率	TCP传输效率相对较低。UDP传输效率高，适用于对高速传输和实时性有较高的通信或广播通信。
连接对象数量	TCP连接只能是点到点、一对一的。UDP支持一对一，一对多，多对一和多对多的交互通信

请描述TCP三次握手的过程，为什么要三次握手?

在TCP/IP协议中,TCP协议提供可靠的连接服务,采用三次握手建立一个连接.

第一次握手	建立连接时,客户端发送syn包(syn=j)到服务器,并进入SYN_SEND状态,等待服务器确认；同步序列编号(Synchronize Sequence Numbers)
第二次握手	服务器收到syn包,必须确认客户的SYN（ack=j+1）,同时自己也发送一个SYN包（syn=k）,即SYN+ACK包,此时服务器进入SYN_RECV状态；
第三次握手	客户端收到服务器的SYN＋ACK包,向服务器发送确认包ACK(ack=k+1),此包发送完毕,客户端和服务器进入ESTABLISHED状态,完成三次握手.

完成三次握手,客户端与服务器开始传送数据

请描述TCP四次分手的过程, 为什么需要四次分手?

SYN	代表请求创建连接，所以在三次握手中前两次要SYN=1，表示这两次用于建立连接
FIN	表示请求关闭连接，在四次分手时，我们发现FIN发了两遍。这是因为TCP的连接是双向的，所以一次FIN只能关闭一个方向
ACK	代表确认接受，从上面可以发现，不管是三次握手还是四次分手，在回应的时候都会加上ACK=1，表示消息接收到了，并且在建立连接以后的发送数据时，都需加上ACK=1,来表示数据接收成功。
seq	序列号，当发送一个数据时，数据是被拆成多个数据包来发送，序列号就是对每个数据包进行编号，这样接受方才能对数据包进行再次拼接
ack	这个代表下一个数据包的编号，这也就是为什么第二请求时，ack是seq+1

在四次分手时
1.首先客户端请求关闭客户端到服务端方向的连接，这时客户端就要发送一个FIN=1，表示要关闭一个方向的连接（见上面四次分手的图）
2.服务端接收到后是需要确认一下的，所以返回了一个ACK=1
3.这时只关闭了一个方向，另一个方向也需要关闭，所以服务端也向客户端发了一个FIN=1 ACK=1
4.客户端接收到后发送ACK=1，表示接受成功

四次分手过程中为什么等待2msl

B收到ACK，关闭连接。但是A无法知道ACK是否已经到达B，于是开始等待？等待什么呢？假如ACK没有到达B，B会为FIN这个消息超时重传 timeout retransmit ，那如果A等待时间足够，又收到FIN消息，说明ACK没有到达B，于是再发送ACK，直到在足够的时间内没有收到FIN，说明ACK成功到达。这个等待时间至少是：B的timeout + FIN的传输时间，为了保证可靠，采用更加保守的等待时间2MSL。
MSL，Maximum Segment Life，这是TCP 对TCP Segment 生存时间的限制。
TTL， Time To Live ，IP对IP Datagram 生存时间的限制，255 秒，所以 MSL一般 = TTL = 255秒

TCP粘包是怎么回事，如何处理？UDP有粘包吗

TCP粘包就是指发送方发送的若干包数据到达接收方时粘成了一包，从接收缓冲区来看，后一包数据的头紧接着前一包数据的尾，出现粘包的原因是多方面的，可能是来自发送方，也可能是来自接收方
出现TCP粘包的原因
发送方原因：
TCP默认使用Nagle算法（主要作用：减少网络中报文段的数量），而Nagle算法主要做两件事：
只有上一个分组得到确认，才会发送下一个分组
收集多个小分组，在一个确认到来时一起发送
Nagle算法造成了发送方可能会出现粘包问题。
Negale 算法是指发送方发送的数据不会立即发出,
而是先放在缓冲区, 等缓存区满了再发出. 发送完一批数据后, 会等待接收方对这批数据的回应,然后再发送下一批数据. Negale 算法适用于发送方需要发送大批量数据, 并且接收方会及时作出回应的场合, 这种算法通过减少传输数据的次数来提高通信效率.
接收方原因
TCP接收到数据包时，并不会马上交到应用层进行处理，或者说应用层并不会立即处理。实际上，TCP将接收到的数据包保存在接收缓存里，然后应用程序主动从缓存读取收到的分组。这样一来，如果TCP接收数据包到缓存的速度大于应用程序从缓存中读取数据包的速度，多个包就会被缓存，应用程序就有可能读取到多个首尾相接粘到一起的包。
如何处理粘包现象
（1）发送方
对于发送方造成的粘包问题，可以通过关闭Nagle算法来解决，使用TCP_NODELAY选项来关闭算法。
（2）接收方
接收方没有办法来处理粘包现象，只能将问题交给应用层来处理
UDP会不会产生粘包问题呢
TCP为了保证可靠传输并减少额外的开销（每次发包都要验证），采用了基于流的传输，基于流的传输不认为消息是一条一条的，是无保护消息边界的（保护消息边界：指传输协议把数据当做一条独立的消息在网上传输，接收端一次只能接受一条独立的消息）。
UDP则是面向消息传输的，是有保护消息边界的，接收方一次只接受一条独立的信息，所以不存在粘包问题。