重庆建设厅网站公示公告栏,网络公司怎么做网站,wordpress 主题管理,wordpress 首页缩列图表面上我是个技术博主。 但没想到今天成了个情感博主。 我是没想到有一天#xff0c;我会通过技术知识#xff0c;来挽救粉丝即将破碎的感情。 掏心窝子的说。这件事情多少是沾点功德无量了。 事情是这样的。 最近就有个读者加了我的绿皮聊天软件#xff0c;女生#xff0c…表面上我是个技术博主。 但没想到今天成了个情感博主。 我是没想到有一天我会通过技术知识来挽救粉丝即将破碎的感情。 掏心窝子的说。这件事情多少是沾点功德无量了。 事情是这样的。 最近就有个读者加了我的绿皮聊天软件女生头像挺好看的就在我以为她要我拉她进群发成人专升本广告的时候。 画风突然不对劲。 她说她男朋友也是个程序员异地恋也关注了我天天研究什么 TCP、UDP 网络。一研究就是一晚上一晚上都不回她消息的那种。 话里有话懂。 不出意外的出了意外她发出了灵魂拷问 你们程序员真的有那么忙吗忙到连消息都不知道回。 没想到上来就是一记直拳。 但是这一拳我接住了。 我很想告诉她 分了吧下一题。 但我不能。因为这样我就伤害了我的读者兄弟。 沉默了一下。 单核 CPU 都快转冒烟了才颤颤巍巍在九宫格键盘上发出消息。 再回慢一点我就感觉我要对不起我这全日制本科学历了。 其实他已经回了你消息了但你知道吗网络是会丢包的。 我来帮他解释下这个话题就要从数据包的发送流程聊起。 数据包的发送流程 首先我们两个手机的绿皮聊天软件客户端要通信中间会通过它们家服务器。大概长这样。 聊天软件三端通信 但为了简化模型我们把中间的服务器给省略掉假设这是个端到端的通信。且为了保证消息的可靠性我们盲猜它们之间用的是 TCP 协议进行通信。 聊天软件两端通信 为了发送数据包两端首先会通过三次握手建立 TCP 连接。 一个数据包从聊天框里发出消息会从聊天软件所在的用户空间拷贝到内核空间的发送缓冲区send buffer数据包就这样顺着传输层、网络层进入到数据链路层在这里数据包会经过流控qdisc再通过 RingBuffer 发到物理层的网卡。数据就这样顺着网卡发到了纷繁复杂的网络世界里。这里头数据会经过 n 多个路由器和交换机之间的跳转最后到达目的机器的网卡处。 此时目的机器的网卡会通知 DMA 将数据包信息放到 RingBuffer 中再触发一个硬中断给 CPUCPU 触发软中断让 ksoftirqd 去 RingBuffer 收包于是一个数据包就这样顺着物理层数据链路层网络层传输层最后从内核空间拷贝到用户空间里的聊天软件里。 网络发包收包全景图 画了那么大一张图只水了 200 字做解释我多少是有些心痛的。 到这里抛开一些细节大家大概知道了一个数据包从发送到接收的宏观过程。
可以看到这上面全是密密麻麻的名词。 整条链路下来有不少地方可能会发生丢包。 但为了不让大家保持蹲姿太久影响身体健康我这边只重点讲下几个常见容易发生丢包的场景。 建立连接时丢包 TCP 协议会通过三次握手建立连接。大概长下面这样。 TCP 三次握手 在服务端第一次握手之后会先建立个半连接然后再发出第二次握手。这时候需要有个地方可以暂存这些半连接。这个地方就叫半连接队列。 如果之后第三次握手来了半连接就会升级为全连接然后暂存到另外一个叫全连接队列的地方坐等程序执行 accept () 方法将其取走使用。 半连接队列和全连接队列 是队列就有长度有长度就有可能会满如果它们满了那新来的包就会被丢弃。 可以通过下面的方式查看是否存在这种丢包行为。 # 全连接队列溢出次数
# netstat -s | grep overflowed 4343 times the listen queue of a socket overflowed # 半连接队列溢出次数
# netstat -s | grep -i SYNs to LISTEN sockets dropped 109 times the listen queue of a socket overflowed 从现象来看就是连接建立失败。 流量控制丢包 应用层能发网络数据包的软件有那么多如果所有数据不加控制一股脑冲入到网卡网卡会吃不消那怎么办让数据按一定的规则排个队依次处理也就是所谓的 qdisc (Queueing Disciplines排队规则)这也是我们常说的流量控制机制。 排队得先有个队列而队列有个长度。 我们可以通过下面的 ifconfig 命令查看到里面涉及到的 txqueuelen 后面的数字 1000其实就是流控队列的长度。 当发送数据过快流控队列长度 txqueuelen 又不够大时就容易出现丢包现象。 qdisc 丢包 可以通过下面的 ifconfig 命令查看 TX 下的 dropped 字段当它大于 0 时则有可能是发生了流控丢包。 # ifconfig eth0
eth0: flags4163UP,BROADCAST,RUNNING,MULTICAST mtu 1500 inet 172.21.66.69 netmask 255.255.240.0 broadcast 172.21.79.255 inet6 fe80::216:3eff:fe25:269f prefixlen 64 scopeid 0x20link ether 00:16:3e:25:26:9f txqueuelen 1000 (Ethernet) RX packets 6962682 bytes 1119047079 (1.0 GiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 9688919 bytes 2072511384 (1.9 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 当遇到这种情况时我们可以尝试修改下流控队列的长度。比如像下面这样将 eth0 网卡的流控队列长度从 1000 提升为 1500。 网卡丢包 网卡和它的驱动导致丢包的场景也比较常见原因很多比如网线质量差接触不良。除此之外我们来聊几个常见的场景。 RingBuffer 过小导致丢包 上面提到在接收数据时会将数据暂存到 RingBuffer 接收缓冲区中然后等着内核触发软中断慢慢收走。如果这个缓冲区过小而这时候发送的数据又过快就有可能发生溢出此时也会产生丢包。 RingBuffer 满了导致丢包 我们可以通过下面的命令去查看是否发生过这样的事情。 # ifconfig
eth0: RX errors 0 dropped 0 overruns 0 frame 0 查看上面的 overruns 指标它记录了由于 RingBuffer 长度不足导致的溢出次数。 当然用 ethtool 命令也能查看。 # ethtool -S eth0|grep rx_queue_0_drops 但这里需要注意的是因为一个网卡里是可以有多个 RingBuffer 的所以上面的 rx_queue_0_drops 里的 0 代表的是第 0 个 RingBuffer 的丢包数对于多队列的网卡这个 0 还可以改成其他数字。但我的家庭条件不允许我看其他队列的丢包数所以上面的命令对我来说是够用了。 当发现有这类型丢包的时候可以通过下面的命令查看当前网卡的配置。 #ethtool -g eth0
Ring parameters for eth0:
Pre-set maximums:
RX: 4096
RX Mini: 0
RX Jumbo: 0
TX: 4096
Current hardware settings:
RX: 1024
RX Mini: 0
RX Jumbo: 0
TX: 1024 上面的输出内容含义是 RingBuffer 最大支持 4096 的长度但现在实际只用了 1024。 想要修改这个长度可以执行 ethtool -G eth1 rx 4096 tx 4096 将发送和接收 RingBuffer 的长度都改为 4096。 RingBuffer 增大之后可以减少因为容量小而导致的丢包情况。 网卡性能不足 网卡作为硬件传输速度是有上限的。当网络传输速度过大达到网卡上限时就会发生丢包。这种情况一般常见于压测场景。 我们可以通过 ethtool 加网卡名获得当前网卡支持的最大速度。 # ethtool eth0
Settings for eth0: Speed: 10000Mb/s 可以看到我这边用的网卡能支持的最大传输速度 speed1000Mb/s。 也就是俗称的千兆网卡但注意这里的单位是 Mb这里的 b 是指 bit而不是 Byte。1Byte8bit。所以 10000Mb/s 还要除以 8也就是理论上网卡最大传输速度是 1000/8 125MB/s。 我们可以通过 sar 命令从网络接口层面来分析数据包的收发情况。 # sar -n DEV 1
Linux 3.10.0-1127.19.1.el7.x86_64 2022年07月27日 _x86_64_ (1 CPU) 08时35分39秒 IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s
08时35分40秒 eth0 6.06 4.04 0.35 121682.33 0.00 0.00 0.00 其中 txkB/s 是指当前每秒发送的字节byte总数rxkB/s 是指每秒接收的字节byte总数。 当两者加起来的值约等于 12~13w 字节的时候也就对应大概 125MB/s 的传输速度。此时达到网卡性能极限就会开始丢包。 遇到这个问题优先看下你的服务是不是真有这么大的真实流量如果是的话可以考虑下拆分服务或者就忍痛充钱升级下配置吧。 接收缓冲区丢包 我们一般使用 TCP socket 进行网络编程的时候内核都会分配一个发送缓冲区和一个接收缓冲区。 当我们想要发一个数据包会在代码里执行 send (msg)这时候数据包并不是一把梭直接就走网卡飞出去的。而是将数据拷贝到内核发送缓冲区就完事返回了至于什么时候发数据发多少数据这个后续由内核自己做决定。 tcp_sendmsg 逻辑 而接收缓冲区作用也类似从外部网络收到的数据包就暂存在这个地方然后坐等用户空间的应用程序将数据包取走。 这两个缓冲区是有大小限制的可以通过下面的命令去查看。 # 查看接收缓冲区
# sysctl net.ipv4.tcp_rmem
net.ipv4.tcp_rmem 4096 87380 6291456 # 查看发送缓冲区
# sysctl net.ipv4.tcp_wmem
net.ipv4.tcp_wmem 4096 16384 4194304 不管是接收缓冲区还是发送缓冲区都能看到三个数值分别对应缓冲区的最小值默认值和最大值 min、default、max。缓冲区会在 min 和 max 之间动态调整。 那么问题来了如果缓冲区设置过小会怎么样 对于发送缓冲区执行 send 的时候如果是阻塞调用那就会等等到缓冲区有空位可以发数据。 send 阻塞 如果是非阻塞调用就会立刻返回一个 EAGAIN 错误信息意思是 Try again 。让应用程序下次再重试。这种情况下一般不会发生丢包。 send 非阻塞 当接受缓冲区满了事情就不一样了它的 TCP 接收窗口会变为 0也就是所谓的零窗口并且会通过数据包里的 win0告诉发送端球球了顶不住了别发了。一般这种情况下发送端就该停止发消息了但如果这时候确实还有数据发来就会发生丢包。 recv_buffer 丢包 我们可以通过下面的命令里的 TCPRcvQDrop 查看到有没有发生过这种丢包现象。 cat /proc/net/netstat
TcpExt: SyncookiesSent TCPRcvQDrop SyncookiesFailed
TcpExt: 0 157 60116 但是说个伤心的事情我们一般也看不到这个 TCPRcvQDrop因为这个是 5.9 版本里引入的打点而我们的服务器用的一般是 2。x~3。x 左右版本。你可以通过下面的命令查看下你用的是什么版本的 Linux 内核。 # cat /proc/version
Linux version 3.10.0-1127.19.1.el7.x86_64 两端之间的网络丢包 前面提到的是两端机器内部的网络丢包除此之外两端之间那么长的一条链路都属于外部网络这中间有各种路由器和交换机还有光缆啥的丢包也是很经常发生的。
这些丢包行为发生在中间链路的某些个机器上我们当然是没权限去登录这些机器。但我们可以通过一些命令观察整个链路的连通情况。 ping 命令查看丢包 比如我们知道目的地的域名是 baidu.com。想知道你的机器到 baidu 服务器之间有没有产生丢包行为。可以使用 ping 命令。 ping 查看丢包 倒数第二行里有个 100% packet loss意思是丢包率 100%。 但这样其实你只能知道你的机器和目的机器之间有没有丢包。 那如果你想知道你和目的机器之间的这条链路哪个节点丢包了有没有办法呢有。 mtr 命令 mtr 命令可以查看到你的机器和目的机器之间的每个节点的丢包情况。 像下面这样执行命令。 mtr_icmp 其中 -r 是指 report以报告的形式打印结果。 可以看到 Host 那一列出现的都是链路中间每一跳的机器Loss 的那一列就是指这一跳对应的丢包率。 需要注意的是中间有一些是 host 是那个是因为 mtr 默认用的是 ICMP 包有些节点限制了 ICMP 包导致不能正常展示。 我们可以在 mtr 命令里加个 -u也就是使用 UDP 包就能看到部分对应的 IP。 mtr-udp 把 ICMP 包和 UDP 包的结果拼在一起看就是比较完整的链路图了。 还有个小细节Loss 那一列我们在 icmp 的场景下关注最后一行如果是 0%那不管前面 loss 是 100% 还是 80% 都无所谓那些都是节点限制导致的虚报。 但如果最后一行是 20%再往前几行都是 20% 左右那说明丢包就是从最接近的那一行开始产生的长时间是这样那很可能这一跳出了点问题。如果是公司内网的话你可以带着这条线索去找对应的网络同事。如果是外网的话那耐心点等等吧别人家的开发会比你更着急。 发生丢包了怎么办 说了这么多。只是想告诉大家丢包是很常见的几乎不可避免的一件事情。 但问题来了发生丢包了怎么办 这个好办用 TCP 协议去做传输。 TCP 是什么 建立了 TCP 连接的两端发送端在发出数据后会等待接收端回复 ack 包ack 包的目的是为了告诉对方自己确实收到了数据但如果中间链路发生了丢包那发送端会迟迟收不到确认 ack于是就会进行重传。以此来保证每个数据包都确确实实到达了接收端。 假设现在网断了我们还用聊天软件发消息聊天软件会使用 TCP 不断尝试重传数据如果重传期间网络恢复了那数据就能正常发过去。但如果多次重试直到超时都还是失败这时候你将收获一个红色感叹号。 这时候问题又来了。 假设某绿皮聊天软件用的就是 TCP 协议。 那文章开头提到的女生她男朋友回她的消息时为什么还会丢包毕竟丢包了会重试重试失败了还会出现红色感叹号。 于是乎问题就变成了用了 TCP 协议就一定不会丢包吗 用了 TCP 协议就一定不会丢包吗 我们知道 TCP 位于传输层在它的上面还有各种应用层协议比如常见的 HTTP 或者各类 RPC 协议。 四层网络协议 TCP 保证的可靠性是传输层的可靠性。也就是说TCP 只保证数据从 A 机器的传输层可靠地发到 B 机器的传输层。 至于数据到了接收端的传输层之后能不能保证到应用层TCP 并不管。 假设现在我们输入一条消息从聊天框发出走到传输层 TCP 协议的发送缓冲区不管中间有没有丢包最后通过重传都保证发到了对方的传输层 TCP 接收缓冲区此时接收端回复了一个 ack发送端收到这个 ack 后就会将自己发送缓冲区里的消息给扔掉。到这里 TCP 的任务就结束了。 TCP 任务是结束了但聊天软件的任务没结束。 聊天软件还需要将数据从 TCP 的接收缓冲区里读出来如果在读出来这一刻手机由于内存不足或其他各种原因导致软件崩溃闪退了。 发送端以为自己发的消息已经发给对方了但接收端却并没有收到这条消息。 于是乎消息就丢了。 使用 TCP 协议却发生丢包 虽然概率很小但它就是发生了。 合情合理逻辑自洽。 所以从这里我铿锵有力的得出结论我的读者已经回了这位女生消息了只是因为发生了丢包所以女生才没能收到而丢包的原因是女生的手机聊天软件在接收消息的那一刻发生了闪退。 到这里。女生知道自己错怪她男朋友了哭着表示一定要让她男朋友给她买一台不闪退的最新款 iPhone。 额…… 这类丢包问题怎么解决 故事到这里也到尾声了感动之余我们来聊点掏心窝子的话。 其实前面说的都对没有一句是假话。 但某绿皮聊天软件这么成熟怎么可能没考虑过这一点呢。 大家应该还记得我们文章开头提到过为了简单就将服务器那一方给省略了从三端通信变成了两端通信所以才有了这个丢包问题。 现在我们重新将服务器加回来。 聊天软件三端通信 大家有没有发现有时候我们在手机里聊了一大堆内容然后登录电脑版它能将最近的聊天记录都同步到电脑版上。也就是说服务器可能记录了我们最近发过什么数据假设每条消息都有个 id服务器和聊天软件每次都拿最新消息的 id 进行对比就能知道两端消息是否一致就像对账一样。 对于发送方只要定时跟服务端的内容对账一下就知道哪条消息没发送成功直接重发就好了。 如果接收方的聊天软件崩溃了重启后跟服务器稍微通信一下就知道少了哪条数据同步上来就是了所以也不存在上面提到的丢包情况。 可以看出TCP 只保证传输层的消息可靠性并不保证应用层的消息可靠性。如果我们还想保证应用层的消息可靠性就需要应用层自己去实现逻辑做保证。 那么问题叒来了两端通信的时候也能对账为什么还要引入第三端服务器 主要有三个原因。 第一如果是两端通信你聊天软件里有 1000 个好友你就得建立 1000 个连接。但如果引入服务端你只需要跟服务器建立 1 个连接就够了聊天软件消耗的资源越少手机就越省电。第二就是安全问题如果还是两端通信随便一个人找你对账一下你就把聊天记录给同步过去了这并不合适吧。如果对方别有用心信息就泄露了。引入第三方服务端就可以很方便的做各种鉴权校验。第三是软件版本问题。软件装到用户手机之后软件更不更新就是由用户说了算了。如果还是两端通信且两端的软件版本跨度太大很容易产生各种兼容性问题但引入第三端服务器就可以强制部分过低版本升级否则不能使用软件。但对于大部分兼容性问题给服务端加兼容逻辑就好了不需要强制用户更新软件。 所以看到这里大家应该明白了我把服务端去掉并不单纯是为了简单。 总结 数据从发送端到接收端链路很长任何一个地方都可能发生丢包几乎可以说丢包不可避免。 平时没事也不用关注丢包大部分时候 TCP 的重传机制保证了消息可靠性。 当你发现服务异常的时候比如接口延时很高总是失败的时候可以用 ping 或者 mtr 命令看下是不是中间链路发生了丢包。 TCP 只保证传输层的消息可靠性并不保证应用层的消息可靠性。如果我们还想保证应用层的消息可靠性就需要应用层自己去实现逻辑做保证。
