C++ 网络编程

TCP与UDP的比较

TCP是面向连接的，交互双方的进程各自建立一个流式套接字，服务器需要等待客户端向其提出连接申请。一旦接受客户端申请就立刻返回一个新的套接字描述符。通过该描述符调用数据传输函数与客户端进行数据的收发。

UDP是面向无连接的，双方建立的是数据报套接字，服务器和客户端在进行传描数据之前不需要进行连接的申请和建立，可以随时向对方发消息。

TCP

优点：可靠、稳定
缺点：速度慢，效率低、占用系统资源高、易被攻击。
适合场景：网络通讯质量要求高（可靠、稳定）

UDP

优点：速度快，比TCP稍安全
缺点：不可靠、不稳定
适用场合：网络通讯质量要求不高，速度快。

Socket粘包问题

什么时候需要考虑粘包问题

1：如果利用tcp每次发送数据，就与对方建立连接，然后双方发送完一段数据后，就关闭连接，这样就不会出现粘包问题（因为只有一种包结构,类似于http协议）。关闭连接主要要双方都发送close连接（参考tcp关闭协议）。如：A需要发送一段字符串给B，那么A与B建立连接，然后发送双方都默认好的协议字符如"hello give me sth abour yourself"，然后B收到报文后，就将缓冲区数据接收,然后关闭连接，这样粘包问题不用考虑到，因为大家都知道是发送一段字符；

2：如果发送数据无结构，如文件传输，这样发送方只管发送，接收方只管接收存储就ok，也不用考虑粘包；

3：如果双方建立连接，需要在连接后一段时间内发送不同结构数据，如连接后，有好几种结构：

1）“hellogive me sth abour yourself”

2）“Don’tgive me sth abour yourself”

那这样的话，如果发送方连续发送这个两个包出去，接收方一次接收可能会是"hello give me sth abour yourselfDon’t give me sth abouryourself" 这样接收方就傻了，到底是要干嘛？不知道，因为协议没有规定这么诡异的字符串，所以要处理把它分包，怎么分也需要双方组织一个比较好的包结构，所以一般可能会在头加一个数据长度之类的包，以确保接收。

粘包出现原因：

在流传输中出现，UDP不会出现粘包，因为它有消息保护边界。

1 发送端需要等缓冲区满才发送出去，造成粘包

2 接收方不及时接收缓冲区的包，造成多个包接收

解决办法：

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

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

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

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

以上提到的三种措施，都有其不足之处。

第一种编程设置方法虽然可以避免发送方引起的粘包，但它关闭了优化算法，降低了网络发送效率，影响应用程序的性能，一般不建议使用。

第二种方法只能减少出现粘包的可能性，但并不能完全避免粘包，当发送频率较高时，或由于网络突发可能使某个时间段数据包到达接收方较快，接收方还是有可能来不及接收，从而导致粘包。

第三种方法虽然避免了粘包，但应用程序的效率较低，对实时应用的场合不适合。

更为简洁的说法：

定包长

包尾加\r\n

包头加包体长度

网上说法：

个人比较喜欢的一种做法是给一帧数据加帧头帧尾，然后接收方不断接受并缓存收到的数据，根据帧头帧尾分离出一帧完整的数据，再分离各字段得到数据