住房城乡与建设厅网站首页,网络公司主要做哪些,六安人论坛六安杂谈,公众号制作公司TCP字节流
之所以会说 TCP 是面向字节流的协议#xff0c;UDP 是面向报文的协议#xff0c;是因为操作系统对 TCP 和 UDP 协议的发送方的机制不同#xff0c;也就是问题原因在发送方。 为什么 UDP 是面向报文的协议#xff1f; 当用户消息通过 UDP 协议传输时#xff0c;…TCP字节流
之所以会说 TCP 是面向字节流的协议UDP 是面向报文的协议是因为操作系统对 TCP 和 UDP 协议的发送方的机制不同也就是问题原因在发送方。 为什么 UDP 是面向报文的协议 当用户消息通过 UDP 协议传输时操作系统不会对消息进行拆分在组装好 UDP 头部后就交给网络层来处理所以发出去的 UDP 报文中的数据部分就是完整的用户消息也就是每个 UDP 报文就是一个用户消息的边界这样接收方在接收到 UDP 报文后读一个 UDP 报文就能读取到完整的用户消息。 你可能会问如果收到了两个 UDP 报文操作系统是怎么区分开的
操作系统在收到 UDP 报文后会将其插入到队列里队列里的每一个元素就是一个 UDP 报文这样当用户调用 recvfrom() 系统调用读数据的时候就会从队列里取出一个数据然后从内核里拷贝给用户缓冲区。 为什么 TCP 是面向字节流的协议 当用户消息通过 TCP 协议传输时消息可能会被操作系统分组成多个的 TCP 报文也就是一个完整的用户消息被拆分成多个 TCP 报文进行传输。 这时接收方的程序如果不知道发送方发送的消息的长度也就是不知道消息的边界时是无法读出一个有效的用户消息的因为用户消息被拆分成多个 TCP 报文后并不能像 UDP 那样一个 UDP 报文就能代表一个完整的用户消息。
在发送端当我们调用 send 函数完成数据“发送”以后数据并没有被真正从网络上发送出去只是从应用程序拷贝到了操作系统内核协议栈中。
至于什么时候真正被发送取决于发送窗口、拥塞窗口以及当前发送缓冲区的大小等条件。也就是说我们不能认为每次 send 调用发送的数据都会作为一个整体完整地消息被发送出去。
我们不能认为一个用户消息对应一个 TCP 报文正因为这样所以 TCP 是面向字节流的协议。
当两个消息的某个部分内容被分到同一个 TCP 报文时就是我们常说的 TCP 粘包问题这时接收方不知道消息的边界的话是无法读出有效的消息。
要解决这个问题要交给应用程序
粘包
粘包的问题出现是因为不知道一个用户消息的边界在哪如果知道了边界在哪接收方就可以通过边界来划分出有效的用户消息。
一般有三种方式分包的方式
固定长度的消息 特殊字符作为边界 自定义消息结构。
固定长度的消息
这种是最简单方法即每个用户消息都是固定长度的比如规定一个消息的长度是 64 个字节当接收方接满 64 个字节就认为这个内容是一个完整且有效的消息。
但是这种方式灵活性不高实际中很少用。
特殊字符作为边界
可以在两个用户消息之间插入一个特殊的字符串这样接收方在接收数据时读到了这个特殊字符就把认为已经读完一个完整的消息。
HTTP 是一个非常好的例子。 HTTP 通过设置回车符、换行符作为 HTTP 报文协议的边界。
有一点要注意这个作为边界点的特殊字符如果刚好消息内容里有这个特殊字符我们要对这个字符转义避免被接收方当作消息的边界点而解析到无效的数据。
自定义消息结构
可以自定义一个消息结构由包头和数据组成其中包头包是固定大小的而且包头里有一个字段来说明紧随其后的数据有多大。
比如这个消息结构体首先 4 个字节大小的变量来表示数据长度真正的数据则在后面。
struct { u_int32_t message_length; char message_data[];
} message;当接收方接收到包头的大小比如 4 个字节后就解析包头的内容于是就可以知道数据的长度然后接下来就继续读取数据直到读满数据的长度就可以组装成一个完整到用户消息来处理了。
