TCP

TCP通信需要服务器端侦听listen、接收客户端连接请求accept，等待客户端connect建立连接后才能进行数据包的收发（recv/send）工作（面向连接）

 而UDP则服务器和客户端的概念不明显，服务器端即接收端需要绑定端口，等待客户端的数据的到来。后续便可以进行数据的收发（recvfrom/sendto）工作。（无连接）

基于TCP网络传输的应用程序有时会出现粘包现象（即发送方发送的若干包数据到接收方接收时粘成一包）。详细解释如下：由于TCP是流协议，对于一个socket的包，如发送 10AAAAABBBBB两次，由于网络原因第一次又分成两次发送， 10AAAAAB和BBBB，如果接包的时候先读取10(包长度)再读入后续数据，当接收得快，发送的慢时，就会出现先接收了 10AAAAAB,会解释错误 ,再接到BBBB10AAAAABBBBB，也解释错误的情况。这就是TCP的粘包。

 为了避免粘包现象，可采取以下几种措施。

        一是对于发送方引起的粘包现象，用户可通过编程设置来避免，TCP提供了强制数据立即传送的操作指令push，TCP软件收到该操作指令后，就立即将本段数据发送出去，而不必等待发送缓冲区满；

        二是对于接收方引起的粘包，则可通过优化程序设计、精简接收进程工作量、提高接收进程优先级等措施，使其及时接收数据，从而尽量避免出现粘包现象；

         三是由接收方控制，将一包数据按结构字段，人为控制分多次接收，然后合并，通过这种手段来避免粘包

三次握手，四次挥手

三次握手建立连接后ACK=2：

A发送连接请求：SYN=1，ACK=0；

B回复连接请求：SYN=1，ACK=1

A回复确认收到链接同意请求：SYN=1，ACK=2；

三次握手(three-way handshake)方案解决了由于网络层会丢失、存储和重复分组带来的问题

四次握手：

（1）客户端（服务器）发送关闭连接的请求（FIN）然后进入FIN_WAIT状态。这表示主机1没有数据要发送给主机2了；

（2）服务器（客户端）收到了客户端（服务器）发送的FIN报文段，向主机1回一个ACK报文段，Acknowledgment Number为Sequence Number加1；主机1进入FIN_WAIT_2状态；主机2告诉主机1，我“同意”你的关闭请求；

（3）主机2向主机1发送FIN报文段，请求关闭连接，同时主机2进入LAST_ACK状态；

（4）主机1收到主机2发送的FIN报文段，向主机2发送ACK报文段，然后主机1进入TIME_WAIT状态；主机2收到主机1的ACK报文段以后，就关闭连接；此时，主机1等待2MSL后依然没有收到回复，则证明Server端已正常关闭，那好，主机1也可以关闭连接了