怎么优化网站的单个关键词排名,下载软件的app大全,宁波智能模板建站,wordpress 重置文章目录 一、TCP丢包原因、解决办法1.1 TCP为什么会丢包1.2 TCP传输协议如何解决丢包问题1.3 其他丢包情况#xff08;拓展#xff09;1.4 补充1.4.1 TCP端口号1.4.2 多个TCP请求的逻辑1.4.3 处理大量TCP连接请求的方法1.4.4 总结 二、UDP丢包2.1 UDP协议2.1.1 UDP简介2.1.2… 文章目录 一、TCP丢包原因、解决办法1.1 TCP为什么会丢包1.2 TCP传输协议如何解决丢包问题1.3 其他丢包情况拓展1.4 补充1.4.1 TCP端口号1.4.2 多个TCP请求的逻辑1.4.3 处理大量TCP连接请求的方法1.4.4 总结 二、UDP丢包2.1 UDP协议2.1.1 UDP简介2.1.2 UDP协议特点2.1.3 基于UDP实现的用户层协议2.1.4 TCP与UDP的区别 2.2 UDP丢包原因2.3 如何解决UDP丢包问题 一、TCP丢包原因、解决办法
TCP是基于不可靠的网络实现可靠的传输肯定也会存在掉包的情况如果通信中发现缺少数据或者丢包那么最大的可能在于程序发送的过程或者接收的过程出现问题。
例如服务端要给客户端发送大量数据Send频率很高那么就很有可能在Send环节出现错误1.程序处理逻辑错误2.多线程同步问题3.缓冲区溢出等如果没有对Send发送失败做处理那么客户端收到的数据比理论要收到的数据少就会造成丢数据丢包现象。
1.1 TCP为什么会丢包
TCP协议Transimission Control Protocol是以一种面向连接的、可靠的、基于字节流的传输层通信协议。
TCP是基于不可靠的网路实现可靠传输肯定会存在丢包问题。
如果在通信过程中发现缺少数据或者丢包那边么最大的可能性是程序发送过程或者接受过程中出现问题
例如我有2台服务器 A和B服务器。A服务器发送数据给B服务器频率过高时B服务器来不及处理造成数据丢包。(原因可能是程序逻辑问题多线程同步问题缓冲区溢出问题)。
如果A服务器不对发送频率进行控制或者数据进行重发的话那么B服务器收到数据就会少。就会造成丢失数据
1.2 TCP传输协议如何解决丢包问题
为了保障传输可靠性TCP协议本身有如下规定
基于数据块传输/数据分片应用数据被分割成TCP认为最适合发送的数据块再传输给网络层数据块被称为报文段或段。对失序数据包重新排序以及去重TCP为了保证不发生丢包就给每个包一个序列号有了序列号能够将接收到的数据根据序列号排序并且去掉亚复序列号的数据就可以实现数据包去重。校验和TCP将保持它首部和数据的检验和。这是一个端到端的检验和目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错TCP 将丢弃这个报文段和不确认收到此报文段。重传机制在数据包丢失或延迟的情况下重新发送数据包直到收到对方的确认应答ACK。TCP重传机制主要有基于计时器的重传也就是超时重传、快速重传基于接收端的反馈信息来引发重传、SACK在快速重传的基础上返回最近收到的报文段的序列号范围这样客户端就知道哪些数据包已经到达服务器了、D-SACK重复SACK在SACK的基础上额外携带信息告知发送方有哪些数据包自己重复接收了。关于重传机制的详细介绍可以查看详解TCP超时与重传机制这篇文章。流量控制滑动窗口TCP连接的每一方都有固定大小的缓冲空间TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据能提示发送方降低发送的速率防止包丢失。TCP使用的流量控制协议是可变大小的滑动窗口协议TCP利用滑动窗口实现流量控制。拥塞控制慢开始、拥塞避免、快重传和快恢复当网络拥塞时减少数据的发送。TCP在发送数据的时候需要考虑两个因素一是接收方的接收能力二是网络的拥塞程度。接收方的接收能力由滑动窗口表示表示接收方还有多少缓冲区可以用来接收数据。网络的拥塞程度由拥塞窗口表示它是发送方根据网络状况自己维护的一个值表示发送方认为可以在网络中传输的数据量。发送方发送数据的大小是滑动窗口和拥塞窗口的最小值这样可以保证发送方既不会超过接收方的接收能力也不会造成网络的过度拥塞。自主重传ARQ停止等待ARQ、连续ARQ接收端接收到分片数据时根据分片数据序号向发送端发送一个确认超时重传
关于TCP如何保障传输可靠性可查阅 计算机网络常见面试题一TCP/IP五层模型、TCP三次握手、四次挥手TCP传输可靠性保障、ARQ协议
1.3 其他丢包情况拓展
按理说TCP协议经过处理、已能保障传输可靠性但是IP协议是不可靠、无连接的以下情况仍有可能会丢包
服务端要给客户端发送大量数据时Send频率很高Send环节可能出现错误程序处理逻辑错误、多线程同步问题、缓冲区溢出等有大量TCP连接请求网络较差譬如握手过程中丢包 TCP 本身具有重传机制但在极端情况下丢包仍然可能发生
对应解决方案如下
1、服务端要给客户端发送大量数据时Send频率很高Send环节可能出现错误程序处理逻辑错误、多线程同步问题、缓冲区溢出等
对Send失败做处理
2、有大量TCP连接请求
优化服务器配置、使用高效的 I/O 处理机制多线程、多进程、事件驱动模型、异步IO、负载均衡和合理管理连接提高服务器的并发处理能力和稳定性具体见本文1.4.3小节
3、网络较差譬如握手过程中丢包 TCP 本身具有重传机制但在极端情况下丢包仍然可能发生
1调整TCP参数
增加重传次数和超时时间可以通过调整内核参数来增加 TCP 的重传次数和超时时间以提高在网络不稳定情况下的可靠性
# 增加重传次数
sudo sysctl -w net.ipv4.tcp_retries215# 增加超时时间
sudo sysctl -w net.ipv4.tcp_fin_timeout30调整拥塞控制算法选择合适的拥塞控制算法可以改善网络性能。Linux 提供了多种拥塞控制算法如 reno、cubic、bbr 等
# 查看当前使用的拥塞控制算法
sysctl net.ipv4.tcp_congestion_control# 设置为 BBR Bottleneck Bandwidth and RTT
sudo sysctl -w net.ipv4.tcp_congestion_controlbbr2使用TCP快速重传和恢复
快速重传快速重传允许发送方在接收到三个重复的 ACK 后立即重传丢失的段而不是等待重传计时器到期
# 开启快速重传
sudo sysctl -w net.ipv4.tcp_frto2快速恢复快速恢复是在快速重传之后的一种机制旨在更快地恢复连接
3使用TCP快速打开
TCP 快速打开TCP Fast Open简称 TFO是一种优化 TCP 连接建立过程的技术。传统的 TCP 连接建立需要三次握手SYN, SYN-ACK, ACK而在某些情况下这三次握手会导致额外的延迟。TCP 快速打开允许客户端在第一次 SYN 包中携带数据从而减少了一次往返时间RTT提高了连接建立的速度。
TCP 快速打开的工作原理
客户端发送 SYN 包客户端在发送 SYN 包时不仅包含 SYN 标志还携带了数据。服务器响应 SYN-ACK 包服务器在响应 SYN-ACK 包时也包含对客户端数据的确认。客户端发送 ACK 包客户端发送 ACK 包同时可以继续发送更多数据。数据传输连接建立完成双方可以立即开始数据传输。
TCP 快速打开TCP Fast Open可以减少建立连接的时间从而减少丢包的可能性。
# 开启 TCP 快速打开
sudo sysctl -w net.ipv4.tcp_fastopen3参数3的含义是客户端和服务器都支持 TFO、客户端可以发送 TFO 请求、服务器可以接受 TFO 请求
4优化网络设备和驱动、调整网络设备参数
可以通过调整网络设备的参数来优化性能例如增加接收缓冲区大小。
# 增加接收缓冲区大小
sudo ethtool -G eth0 rx 40965使用网络监控工具
使用网络监控工具如 Wireshark、tcpdump来监控和分析网络流量及时发现和解决问题。
# 使用 tcpdump 抓包
sudo tcpdump -i eth0 -w capture.pcap1.4 补充
TCP传输控制协议是一种面向连接的、可靠的、基于字节流的传输层通信协议。TCP 端口是用于标识网络应用的逻辑地址。每个 TCP 连接由源 IP 地址、源端口号、目标 IP 地址和目标端口号唯一标识。
端口号是一个 16 位的数字范围从 0 到 65535。其中0-1023 是众所周知的系统端口通常由系统进程使用1024-49151 是注册端口可以被用户进程使用49152-65535 是动态或私有端口通常由操作系统自动分配。
1.4.1 TCP端口号
TCP传输控制协议端口号是一个 16 位的数字用于标识网络应用程序的逻辑地址。每个 TCP 连接由四个部分唯一标识
源 IP 地址源端口号目标 IP 地址目标端口号
端口号的范围是从 0 到 65535其中
0-1023熟知端口通常由系统进程使用。1024-49151注册端口可以被用户进程使用。49152-65535动态或私有端口通常由操作系统自动分配。
1.4.2 多个TCP请求的逻辑
当有多个 TCP 请求时这些请求并不一定都使用同一个端口。实际上每个连接都有唯一的四元组源 IP 地址、源端口号、目标 IP 地址、目标端口号来区分。
1服务器端口
服务器通常监听一个固定的端口例如 HTTP 服务通常监听 80 端口HTTPS 服务通常监听 443 端口。当客户端发起连接请求时服务器的监听端口会接受连接请求并为每个连接分配一个新的端口。
2客户端端口
客户端发起连接时操作系统会为每个连接分配一个临时端口通常是动态端口范围在 49152-65535 之间。这个临时端口在连接期间是唯一的。
3示例说明
假设有一个 Web 服务器监听 80 端口两个客户端分别从不同的 IP 地址发起连接
客户端 AIP 地址 192.168.1.1操作系统为其分配临时端口 50000客户端 BIP 地址 192.168.1.2操作系统为其分配临时端口 50001
服务器接收到这两个连接请求后会为每个连接分配一个新的端口
连接 1(192.168.1.1:50000, 服务器 IP:80)连接 2(192.168.1.2:50001, 服务器 IP:80)
尽管服务器监听的是同一个端口80但由于每个连接的四元组不同服务器可以区分这些连接并同时处理它们。
1.4.3 处理大量TCP连接请求的方法
当有大量 TCP 连接请求时服务器需要采取一些措施来有效地管理和处理这些连接以保证系统的性能和稳定性。以下是一些常见的处理方法
1. 使用高性能服务器
多核处理器使用多核处理器可以提高服务器的并发处理能力。高内存增加服务器的内存容量以支持更多的连接和更大的缓存。
2. 优化网络配置
调整内核参数优化 Linux 内核参数如 net.core.somaxconn最大监听队列长度、net.ipv4.tcp_max_syn_backlogSYN 队列长度、net.ipv4.tcp_fin_timeoutFIN 超时时间等。使用 TCP 快速打开启用 TCP 快速打开TCP Fast Open可以减少建立连接的时间。
3. 使用连接池
连接复用使用连接池技术复用已建立的连接减少连接建立和断开的开销。连接池管理合理管理连接池的大小避免过多的空闲连接占用资源。
4. 服务器端优化 多线程模型使用多线程模型每个线程处理一部分连接。 多进程模型每个连接由一个独立的进程处理。这种方法可以利用多核处理器的优势但进程间的通信和资源管理较为复杂。 事件驱动模型使用事件驱动模型如 epoll、kqueue高效处理大量的 I/O 事件。这种方法可以高效地处理大量连接适用于高并发场景 异步 I/O框架使用异步 I/O 模型如 Node.js、Python 的 asyncio可以在单个线程中处理多个连接提高并发处理能力。
5. 负载均衡
反向代理使用反向代理服务器如 Nginx、HAProxy将请求分发到多个后端服务器分散负载。集群构建服务器集群通过负载均衡算法将请求分发到不同的节点。
6. 限制连接速率
限流使用限流算法如令牌桶、漏桶限制客户端的连接速率防止突发流量冲击。连接超时设置合理的连接超时时间及时关闭不活跃的连接。
7. 优化应用程序
减少响应时间优化应用程序的逻辑减少每个请求的处理时间。缓存使用缓存机制减少对后端数据库的访问频率。异步处理将耗时的操作异步处理提高响应速度。
1.4.4 总结
TCP 端口号用于标识网络应用程序的逻辑地址每个连接由四元组源 IP 地址、源端口号、目标 IP 地址、目标端口号唯一标识。多个 TCP 请求服务器监听一个固定端口但每个连接都会分配一个唯一的四元组因此可以同时处理多个连接。处理大量 TCP 连接请求优化服务器配置、使用高效的 I/O 处理机制多线程、多进程、事件驱动模型、异步IO、负载均衡和合理管理连接提高服务器的并发处理能力和稳定性其他丢包情况 服务端要给客户端发送大量数据时Send频率很高Send环节可能出现错误程序处理逻辑错误、多线程同步问题、缓冲区溢出等 ——对Send失败做处理有大量TCP连接请求 ——优化服务器配置、使用高效的 I/O 处理机制多线程、多进程、事件驱动模型、异步IO、负载均衡和合理管理连接提高服务器的并发处理能力和稳定性网络较差譬如握手过程中丢包 TCP 本身具有重传机制但在极端情况下丢包仍然可能发生 ——调整TCP参数、使用TCP快速重传和恢复、使用TCP快速打开、优化网络设备和驱动、调整网络设备参数、使用网络监控工具
二、UDP丢包
2.1 UDP协议
2.1.1 UDP简介
UDPUser Datagram Protocol是一种无连接的传输层协议它提供了一种简单的、不可靠的数据传输服务。UDP 提供了不面向连接的通信且不对传送的数据报进行可靠的保证适用于一次传送少量的数据不适用于传输大量的数据。UDP属于网络协议栈中的传输层协议直接负责数据的传输和接收
2.1.2 UDP协议特点
无连接两台主机在使用UDP进行数据传输时不需要建立连接只需知道对端的IP和端口号即可把数据发送过去。不可靠UDP协议没有确认重传机制如果因为网络故障导致报文无法发到对方或者对方收到了报文但是传输过程中乱序了对方校验失败后把乱序的包丢了UDP协议层也不会给应用层任何错误反馈信息。在网络中“不可靠”是个中性词因为可靠就意味着要付出更多的代价去维护可靠实现起来会复杂很多而“不可靠”的话实现起来会更简单面向数据报UDP传输数据时是以数据报文为单位一个个地发出去然后一个个地接收的这导致上面应用层无法灵活控制数据数据的读写次数和数量。 2.1.3 基于UDP实现的用户层协议
NFS网络文件系统TFTP简单文件传输协议DHCP动态主机配置协议BOOTP启动协议(用于无盘设备启动)DNS域名解析协议
2.1.4 TCP与UDP的区别
TCPUDP面向连接无连接提供可靠服务不保证可靠交互有状态无状态面向字节流面向报文传输效率较慢传输效率较快有拥塞控制没有拥塞控制每一条TCP连接只能是stron支持一对一、一对多、多对一、多对多首部开销20字节首部开销8字节
2.2 UDP丢包原因
1、接收端处理时间过长导致丢包
调用recv方法接收端收到数据后处理数据花了一些时间处理完后再次调用recv方法在这二次调用间隔里,发过来的包可能丢失。对于这种情况可以修改接收端将包接收后存入一个缓冲区然后迅速返回继续recv。
2、发送的包巨大丢包
虽然send方法会帮你做大包切割成小包发送的事情但包太大也不行。例如超过50K的一个udp包不切割直接通过send方法发送也会导致这个包丢失。这种情况需要切割成小包再逐个send。
3、发送的包较大超过接受者缓存导致丢包
包超过mtu size数倍几个大的udp包可能会超过接收者的缓冲导致丢包。这种情况可以设置socket接收缓冲。以前遇到过这种问题我把接收缓冲设置成64K就解决了。
4、发送的包频率太快
虽然每个包的大小都小于mtu size 但是频率太快例如40多个mut size的包连续发送中间不sleep也有可能导致丢包。这种情况也有时可以通过设置socket接收缓冲解决但有时解决不了。所以在发送频率过快的时候还是考虑sleep一下吧。
5、局域网内不丢包公网上丢包
这个问题我也是通过切割小包并sleep发送解决的。如果流量太大这个办法也不灵了。总之udp丢包总是会有的如果出现了用我的方法解决不了还有这个几个方法 要么减小流量要么换tcp协议传输要么做丢包重传的工作。
2.3 如何解决UDP丢包问题
1.发送频率过高导致丢包
很多人会不理解发送速度过快为什么会产生丢包原因就是UDP的SendTo不会造成线程阻塞也就是说UDP的SentTo不会像TCP中的SendTo那样直到数据完全发送才会return回调用函数它不保证当执行下一条语句时数据是否被发送SendTo方法是异步的。这样如果要发送的数据过多或者过大那么在缓冲区满的那个瞬间要发送的报文就很有可能被丢失。至于对“过快”的解释作者这样说“A few packets a second are not an issue; hundreds or thousands may be an issue.”一秒钟几个数据包不算什么但是一秒钟成百上千的数据包就不好办了。
要解决接收方丢包的问题很简单首先要保证程序执行后马上开始监听如果数据包不确定什么时候发过来的话其次要在收到一个数据包后最短的时间内重新回到监听状态其间要尽量避免复杂的操作比较好的解决办法是使用多线程回调机制。
2.报文过大丢包
至于报文过大的问题可以通过控制报文大小来解决使得每个报文的长度小于MTU。以太网的MTU通常是1500 bytes其他一些诸如拨号连接的网络MTU值为1280 bytes如果使用speaking这样很难得到MTU的网络那么最好将报文长度控制在1280 bytes以下。
3.发送方丢包
发送方丢包内部缓冲区internal buffers已满并且发送速度过快即发送两个报文之间的间隔过短 接收方丢包Socket未开始监听 虽然UDP的报文长度最大可以达到64 kb但是当报文过大时稳定性会大大减弱。这是因为当报文过大时会被分割使得每个分割块翻译可能有误差原文是fragmentation的长度小于MTU然后分别发送并在接收方重新组合reassemble但是如果其中一个报文丢失那么其他已收到的报文都无法返回给程序也就无法得到完整的数据了。
面试TCP/UDP如何解决丢包问题、【网络】UDP协议
