|
什么是tcp
TCP,全称Transmission Control Protocol,是一种传输控制协议,TCP协议也是计算机网络中非常复杂的一个协议
tcp的特点
- tcp是面向连接的协议
- tcp是端到端的链接
- tcp提供可靠的传输服务
- tcp协议提供双工通信
- tcp是面向字节流的协议
tcp粘包
tcp有这么多的特点,但是为什么还会出现粘包呢?其实这是对tcp传输的一种优化而引起的一些问题。
为什么要优化?
我们前面说了, tcp是面向字节流的协议,而不是消息包的协议,为什么是面向字节流?因为一个tcp连接,它负责传输数据,但是这些数据的大小是未知的,可能很大,也可能很小,而且是没有边界的,它只会将你的数据编程字节流发到对面去,而且保证顺序不会乱,而对于字节流的解析,就需要我们自己来搞定了,那数据怎么传输呢?方法来了,不管你是什么数据,我都给你转换成二进制。然后由tcp切割为tcp认为合适的长度。
那么这个长度怎么确定?
我们知道,从应用层到物理层,数据都是一层一层经过打包过的,我们可能一下子没法知道tcp最大传输多少,但是我们可以反推一下,以太网数据包(packet)的大小是固定的,最初是1518字节,后来增加到1522字节。其中, 1500 字节是负载(payload),22字节是头信息(head)。IP 数据包在以太网数据包的负载里面,它也有自己的头信息,最少需要20字节,所以 IP 数据包的负载最多为1480字节。TCP 数据包在 IP 数据包的负载里面。它的头信息最少也需要20字节,因此 TCP 数据包的最大负载是 1480 - 20 = 1460 字节。由于 IP 和 TCP 协议往往有额外的头信息,所以 TCP 负载实际为1400字节左右。
这里插播一个http2的一个改进
在 HTTP/1 中,HTTP 请求和响应都是由「状态行、请求 / 响应头部、消息主体」三部分组成。一般而言,消息主体都会经过 gzip 压缩,或者本身传输的就是压缩过后的二进制文件(例如图片、音频),但状态行和头部却没有经过任何压缩,直接以纯文本传输。而http2里面的一个重大改进,就是压缩http的协议的头信息,怎么实现的头部压缩呢?主要是基于以下几点:
维护一份相同的静态字典(Static Table),包含常见的头部名称,以及特别常见的头部名称与值的组合;
维护一份相同的动态字典(Dynamic Table),可以动态地添加内容;
支持基于静态哈夫曼码表的哈夫曼编码(Huffman Coding)
好了,我们前面说了,一个tcp包负载是1400字节左右,那么你发送2000个字节,就需要发送两个数据包,第二个数据包可能就是600个字节。那么问题来了,明明一次可以发送1400字节,但是实际只发送600个字节,是不是有点浪费网络之间的IO,怎么办?John Nagle(约翰.纳格) 提出了一种简单有效的解决方法。也就是Nagle 算法。
相关视频推荐
c++后端开发面试4个常见问题:什么是tcp粘包与分包?如何解决?epoll为什么比select/poll性能高?reactor如何与多线程结合?什么是惊群现象
4个小时搞懂tcp/ip协议栈,从tcp/ip协议栈原理到实现一个网
8个方面完善linux c/c++开发,再也不用全网搜刮了
需要C/C++ Linux服务器架构师学习资料加qun812855908获取(资料包括C/C++,Linux,golang技术,Nginx,ZeroMQ,MySQL,Redis,fastdfs,MongoDB,ZK,流媒体,CDN,P2P,K8S,Docker,TCP/IP,协程,DPDK,ffmpeg等),免费分享
Nagle 算法
Nagle 算法的基本定义是任一时刻,最多只能有一个未被确认的小段。所谓“小段”,指的是长度小于 MSS 尺寸的数据块,而未被确认则是指没有收到对方的 ACK 数据包。Nagle 算法的规则(参考 tcp_output.c 文件里 tcp_nagle_check 函数注释):
如果包长度达到 MSS,则允许发送;
如果该数据包含有 FIN,则允许发送;
设置了 TCP_NODELAY 选项,则允许发送;
未设置 TCP_CORK 选项时,若所有发出去的小数据包(包长度小于 MSS)均被确认,则允许发送;
上述条件都未满足,但发送了超时(一般为 200 ms),则立即发送。
该算法的精妙之处在于它实现了自时钟(self-clocking)控制:ACK 返回得快,数据传输也越快。在相对高延迟的广域网中,更需要减少微型报的数目,该算法使得单位时间内发送的报文段数据更少。也就是说,RTT 控制着发包速率。
简单理解 就是如果你普通的数据流,小于传输的负载量,我就不传输,等到下次有数据满足了我的负载量我再传输,但是我也不能一直等,如果时间超过200ms都么有数据流过来,那我就传输。
tcp粘包的演示
服务端
package main
import (
"bufio"
"fmt"
"io"
"net"
)
func main() {
network:="tcp"
address:="127.0.0.1:30000"
//绑定和监听tpc和端口
listen, err := net.Listen(network, address)
if err != nil {
fmt.Println("listen err")
}
//关闭监听
defer listen.Close()
for{
//等待连接
conn,err:=listen.Accept()
if err != nil {
fmt.Println("accept error")
}
//从连接里面读取数据
go process(conn)
}
}
func process(conn net.Conn){
defer conn.Close()//关闭连接
//读取连接数据
reader:=bufio.NewReader(conn)
//定义每次接收的长度
buf:=make([]byte, 7)
for {
//用buf接收连接发送的内容
read, err := reader.Read(buf)
//读完了
if err == io.EOF {
break
}
if err != nil {
fmt.Println("read conn err")
}
fmt.Printf("the msg i read length is %d \n",read)
str:=string(buf[:read])
fmt.Println(str)
}
}客户端代码
package main
import (
"fmt"
"net"
)
func main() {
network:="tcp"
address:="127.0.0.1:30000"
//拨号 请求创建tcp连接
conn, err := net.Dial(network,address )
if err != nil {
fmt.Println("connect err")
}
//关闭连接
defer conn.Close()
//想tcp写入数据
conn.Write([]byte("123456789"))
}我们先后发送123,1234567,123456789和123,456并打印出来看看,我们来看截图里面的内容,发现出现了问题,这就是粘包造成的问题,可能会把你的消息分段发送,也可能会把多段消息合并 。
tcp粘包的解决
- tcp是只负责按顺序传输数据,并没有边界的概念,那么我们如果想要确定消息边界,就得发送一种信号,或者说一种约定,当接收者接到这种信号,就能知道是消息的开始还是结尾,比如我们的http请求有一个content-length
那么我们约定消息边界一般有三种模式
定长消息:协议提前约定好包的长度为多少,每当接收端接收到固定长度的字节就确定一个包,就像咱们上面截图的那个
消息分隔符:利用特殊符号标志着消息的开始或者结束,例如 HTTP 协议中的换行符;
长度前缀:先发送N个字节代表包的大小(注意大端和小端问题),后续解析也按长度读取解析。
粘包解决方案
这里我们使用第三种来实现,即给消息体添加一个长度前缀。
我们先来写一个文件,基于长度前缀来编码和解码消息
package tcp_code
import (
"bufio"
"bytes"
"encoding/binary"
)
// Encode 将消息编码后返回byte类型
func Encode(msg string)([]byte,error){
//1.读取消息的长度,用int32存放消息长度,这个长度大概能支持4G的数据传输,如果用int64就代表16777216T
length:=int32(len(msg))
//定义一个Buffer结构体用来存储数据,Buffer是一个变长缓冲区,可读可写
var pkg =new(bytes.Buffer)
//把长度以二进制的形式写入消息头
err := binary.Write(pkg, binary.LittleEndian, length)
if err != nil {
return nil, err
}
//把消息以二进制的形式写入pkg
err = binary.Write(pkg, binary.LittleEndian, []byte(msg))
if err != nil {
return nil, err
}
//将缓冲区的数据返回
return pkg.Bytes(),nil
}
// Decode 参数是从连接中获取的原始消息,用这个方法将消息体解码
func Decode(reader bufio.Reader)(string,error){
//1.获取消息的长度
//按照约定,读取前32的长度
//Peek是返回字节类型,一个字节是8个bit,所以是4个字节即代表32位的长度的数据
lengthByte,_:=reader.Peek(4)
//转换为buff类型
lengthBuff:=bytes.NewBuffer(lengthByte)
//这个长度是指消息体的长度
var length int32
//将长度赋值给length
err := binary.Read(lengthBuff, binary.LittleEndian, &length)
if err != nil {
return "", err
}
//消息体的长度加上4个字节 就是完整的消息体了
totalLen:=length+4
//查看当前缓存区中消息的长度,如果消息还没有传输完毕,先不处理
if int32(reader.Buffered())<totalLen{
return &#34;&#34;, err
}
//定义一个切片从缓冲区获取数据
pack:=make([]byte,totalLen)
_, err = reader.Read(pack)
if err != nil {
return &#34;&#34;, err
}
//返回消息 ,注意不要返回前4个byte,前4个byte代表的是消息体的长度
return string(pack[4:]),nil
}服务端代码
package main
import (
tcp_code &#34;acurd.com/pkg/pkg/tcp-code&#34;
&#34;bufio&#34;
&#34;fmt&#34;
&#34;io&#34;
&#34;net&#34;
)
func main() {
network:=&#34;tcp&#34;
address:=&#34;127.0.0.1:30000&#34;
//绑定和监听tpc和端口
listen, err := net.Listen(network, address)
if err != nil {
fmt.Println(&#34;listen err&#34;)
}
//关闭监听
defer listen.Close()
for{
//等待连接
conn,err:=listen.Accept()
if err != nil {
fmt.Println(&#34;accept error&#34;)
}
//从连接里面读取数据
go process(conn)
}
}
func process(conn net.Conn){
defer conn.Close()//关闭连接
//读取连接数据
reader:=bufio.NewReader(conn)
//定义每次接收的长度
for {
//使用decode解码消息
msg, err := tcp_code.Decode(reader)
//读完了
if err == io.EOF {
break
}
if err != nil {
fmt.Println(&#34;read conn err&#34;)
}
fmt.Println(msg)
}
}客户端代码
package main
import (
tcp_code &#34;acurd.com/pkg/pkg/tcp-code&#34;
&#34;bufio&#34;
&#34;fmt&#34;
&#34;io&#34;
&#34;net&#34;
)
func main() {
network:=&#34;tcp&#34;
address:=&#34;127.0.0.1:30000&#34;
//绑定和监听tpc和端口
listen, err := net.Listen(network, address)
if err != nil {
fmt.Println(&#34;listen err&#34;)
}
//关闭监听
defer listen.Close()
for{
//等待连接
conn,err:=listen.Accept()
if err != nil {
fmt.Println(&#34;accept error&#34;)
}
//从连接里面读取数据
go process(conn)
}
}
func process(conn net.Conn){
defer conn.Close()//关闭连接
//读取连接数据
reader:=bufio.NewReader(conn)
//定义每次接收的长度
for {
//使用decode解码消息
msg, err := tcp_code.Decode(reader)
//读完了
if err == io.EOF {
break
}
if err != nil {
fmt.Println(&#34;read conn err&#34;)
}
fmt.Println(msg)
}
}我们看一下效果,发送了两个消息,一12345678,一个是abcdefghi
总结
通过上面,我们了解到了原来粘包的问题,并不属于tcp的锅。tcp是基于数据流的传输,保证数据流的顺序,但是正式由于这种数据流的传输模式,对于tcp来说,自己就像一个传送带,传递的是一个个的快递包裹,源源不断。具体包裹到是什么,到哪里去,就需要接收端和发送端通过定制的协议来编码和解码解决。 |
本帖子中包含更多资源
您需要 登录 才可以下载或查看,没有账号?立即注册
×
|