- 综合排序
- 最热优先
- 最新优先
- 来自专栏阿牛的牙
RTT & RTO
RTT(Round-Trip Time)：往返时延。是指数据从网络一端传到另一端所需的时间。通常，时延由发送时延、传播时延、排队时延、处理时延四个部分组成。 （3）排队时延 排队时延是分组在所经过的网络结点的缓存队列中排队所经历的时延，排队时延的长短主要取决于网络中当时的通信量，当网络的通信流量大时，排队时间就长，极端情况下，当网络发生拥塞导致分组丢失时，该结点的排队时延视为无穷大 TCP发送一个报文时,就启动重传计时器,有2种情况: 1.若在计时器超时之前收到了特定报文的确认,则撤消这个计时器; 2.特定数据报在计时器超时前没有收到确认,则重传该数据报,并把计时器复位 RTT 简单来说，就是我发送一个数据包，然后对端回一个ack，那么当我接到ack之后，就能计算出从我发送出包到接到过了多久，这个时间就是RTT。 RTT的计算是很简单的，就是一个时间差。
2.1K20编辑于 2022-09-07 - 来自专栏程序猿的那点事
Android RTT ： 通过 RTT 确定 WLAN 位置信息
用户可以利用 WLAN RTT（往返时间）API 提供的 WLAN 定位功能，测量距附近支持 RTT 的 WLAN 接入点和 WLAN 感知对等设备的距离。 前台应用执行 WLAN RTT 操作不受限制，但后台应用执行此类操作时会受限。 WLAN RTT 和相关精确时间测量 (FTM) 功能由 IEEE 802.11mc 标准规定。 检查 WLAN RTT 是否可用 设备上可能存在 WLAN RTT，但由于用户已禁用 WLAN，该功能目前或不可用。 如果 SoftAP 或网络共享处于使用状态，则某些设备可能不支持 WLAN RTT，具体视设备的硬件和固件功能而定。如要检查 WLAN RTT 当前是否可用，请调用 isAvailable()。 WLAN RTT 的可用性随时可能发生变化。
2.7K20发布于 2020-07-15 - 来自专栏take time, save time
三十天学不会TCP,UDPIP网络编程 -- RTT的计算
如果对和程序员有关的计算机网络知识，和对计算机网络方面的编程有兴趣，虽然说现在这种“看不见”的东西真正能在实用中遇到的机会不多，但是我始终觉得无论计算机的语言，热点方向怎么变化，作为一个程序员，很多基本的知识都应该有所了解 也许ACK正在路上，你却错误的认为是丢失了，那么网络中就会增加很多本来就不必要的包。 而且，要知道，现实的网络环境是十分复杂多变的，有时候可能突然的抽风，有时候可能突然的又很顺畅，所以说如果只用一个一直不变的时间作为重传计时器的时长是完全不现实，不可用的。 原因是这个RTT是过去完成时了，是上一次成功的时候的时间，和下一次网络会不会突然抽风，还是会突然变得更通畅没有太大的必然关系，最愚蠢的一种思维就是简单的用过去代表未来。 假设在某个时间，网络极度的抽风，突然由快变得很慢，导致所有的包都要重传。
2.3K100发布于 2018-04-16 - 来自专栏嵌入式程序猿
STM32H743+RTT-Studio
RTT Studio 现在RTT-Studio已经更新到了1.15版本，记得第一个版本出来的时候就试用过，前两天更新了1.15版本，今天刚好在H743的板子上使用了下，功能强大，而且大大方便了原来使用集成 Studio使用 其实最早IDE出来的时候给大家简单介绍过，因为最近刚好在做基于H743的项目，而之前是用freeRTOS做的，现在想在做个RTT的版本，就直接选择用RTT Studio来开始。
1.6K10发布于 2020-11-06 - 来自专栏Rice嵌入式
如何使用CMake编译RTT微内核
《如何移植RTT微内核到树莓派3B》 目前RTT微内核是RTT提供的体验版本。它采用了scons构建。作者也是刚接触scons，不是很了解，在这不过多的说明。 不是因为scons不好，而是之前作者在写关于cmake的文章中，熊大（RTT的创始人）看到，然后在交流中，熊大说可以采用cmake进行编译。所以我也是冒着尝试的想法，开始了使用cmake去构建微内核。 microkernel_sdk_dir "${CMAKE_SOURCE_DIR}/sdk") set(microkernel_apps_dir "${CMAKE_SOURCE_DIR}/apps") project(rtt_microkernel project(rtt_microkernel) 6.使能可以支持的语言，这里使能C语言和汇编语言。如果不是能，则相关文件不会进行编译。 link.txt文件内容如下： 编译测试： 1.测试应用如下： 2.生成可执行文件：rtt_microkernel.elf. 3.运行验证（烧录到树莓派上进行验证）： 如上是整个测试以及CMakeLists.txt
2.6K20编辑于 2022-05-10 - 来自专栏Rice嵌入式
【GD32F310开发板试用】基于RTT Nano的RTT 软件包使用
在评测期间，我移植RTT完整版本，发现移植完，其实资源已经所剩无几了，而且裁剪也没有意义，这款芯片不适合移植RTT的完整版本。 于是我选择移植RTT的nano版本，并且适配完整版本的PIN驱动接口和I2C驱动接口。即可完美的适配RTT的软件包。 rtt nano移植说明 移植rtt nano的过程很简单，完全按照官方的教程即可。 RTT的软件包是基于他的驱动框架进行设计的，而nano增加驱动框架显得有点重，所以可以可以封装一层RTT的驱动框架接口。而这一封装接口，我在去年已经实现了，并且把教程提交到RTT的文档中心了。 rtt 软件包在nano中的使用 因为我主要适配了RTT的PIN驱动接口和I2C驱动接口，所以我选择一个使用I2C接口的传感器软件包--as7341，其实这个软件包也是我共享给RTT的其中一个软件包，所以选择最熟悉的
78320编辑于 2022-05-10 - 来自专栏嵌入式实验基地
ART-PI OLED小时钟+ESP8266获取网络时间（RTT-Studio平台）
继上次的OLED显示开发之后，觉得RTT的平台挺好玩的，图形化配置，容易上手，这次在上次OLED显示的基础之上，增加ESP8266获取网络时间，同步网络时间并利用模拟RTC模块，做一个精巧的小时钟，ART-PI 2、硬件平台很简单，搭建OK之后，下面就开始我们的RTT-Studio的探索之旅啦，伙伴们只需搬好小板凳，配置这种糙活累活交给小飞哥就OK啦。 老规矩，没有枪没有炮，RTT给我们造，感谢RTT模块贡献者们，我们只需要在软件包里面找到at device模块，添加进我们的工程就OK了，然后double click就进入详细配置界面，选择乐鑫ESP8266 然后，来吧，推开网络的大门吧，ping百度，可以看到数据完全无问题咯 ? 5、然后，添加netutils工具软件包，netutils软件包中汇集了RT-Thread可用的全部网络小工具集合，包括NTP工具，方法同其他工具包一样咯，然后配置默认就可以啦。 ? ?
93630发布于 2021-08-16 - 来自专栏cwl_Java
速读原著-TCPIP(往返时间RTT的例子)
第21章 TCP的超时与重传 21.4 往返时间RTT的例子 在本章中，我们将使用以下这些例子来检查 T C P的超时和重传、慢启动以及拥塞避免等方方面面的实现细节。 虽然我们仅能够在运行 t c p d u m p的主机上测量分组发送和接收的时间，但在本图中我们希望显示出分组正在网络中传输（它们确实存在，因为这个局域网连接与共享式的以太网并不一样）以及接收主机何时可能产生 21.4.1 往返时间RTT的测量 在图2 1 - 2左边的时间轴上有三个括号，它们表明为进行RT T计算对哪些报文段进行了计时，并不是所有的报文段都被计时。 21.4.2 RTT估计器的计算 让我们来看一下RT T估计器（平滑的RT T和平滑的均值偏差）是如何被初始化和更新，以及每个重传超时是怎样计算的。 变量A和D分别被初始化为0和3秒。
1.4K30发布于 2020-03-13 - 来自专栏全栈程序员必看
线程池参数调优_rtt线程池
gRPC 线程池：负责处理所有网络请求，它会把不同任务类型的请求转发给不同的线程池。 由于 gRPC 线程池几乎不会有多少计算开销，它主要负责网络 IO、反序列化请求，因此该配置通常不需要调整。
1K20编辑于 2022-11-09 - 来自专栏网络加速
QUIC 0-RTT实现简析及一种分布式的0-RTT实现方案
现如今，高速且安全的网络接入服务已经成为人们的必须。 本文单独就网络传输的建连问题展开了分析, 浅析了建连时间对传输的影响, 以及QUIC的0-RTT建连是如何解决建连耗时长的问题的。 加之如果用户网络不好，RTT延时大的话，建连时间可能耗费数百毫秒至数秒不等，这将极大的影响用户体验。究其原因一方面是TCP和TLS分层设计导致的：分层的设计需要每个逻辑层次分别建立自己的连接状态。 QUIC“真”0-RTT握手 QUIC为规避TCP协议僵化的问题，将QUIC协议建立在了UDP之上。考虑到安全性是网络的必备选项，加密在QUIC里强制的。 总结 本文就网络传输的一个方面的建连问题展开了分析, 浅析了建连时间对传输的影响。分析了TLS在缩短建连方面的努力, 以及分层网络设计在这里方面的本质局限。
9.9K63发布于 2020-03-05 - 来自专栏计算机工具
信道，流量控制，滑动窗口概念，ARQ，RTT
早期的网络通信中，通信双方不会考虑网络的拥挤情况直接发送数据。由于大家不知道网络拥塞状况，同时发送数据，导致中间节点阻塞掉包，谁也发不了数据，所以就有了滑动窗口机制来解决此问题。 参见滑动窗口如何根据网络拥塞发送数据仿真视频。图片是一个滑动窗口的实例： 滑动窗口协议是用来改善吞吐量的一种技术，即容许发送方在接收任何应答之前传送附加的包。 RTT(Round-Trip Time): 往返时延。在计算机网络中它是一个重要的性能指标，表示从发送端发送数据开始，到发送端收到来自接收端的确认（接收端收到数据后便立即发送确认），总共经历的时延。
32910编辑于 2024-12-16 - 来自专栏wenzi嵌入式软件
RTT 是如何管理和构建工程的？
那对于 rtt 来讲，它又是如何管理和构建工程的呢？下面笔者将从一个工程的目录结构开始来进行阐述。 工程目录结构 下图是一个STM32f4 基于 rtt 的一个工程目录： ? packages:rtt 存在丰富的软件包，这个文件夹存放的就是我们使用的软件包的相关文件。 rt-thread:这个文件夹存放的就是 rtt 内核以及组件的相关文件。 rtconfig.h:这个是极为关键的一个文件，rtt 进行内核裁剪实际上也就是通过这个文件里的宏定义来关闭或者打开 rtt 所具备的功能。 rtt 的相关功能。 同时，RTT 采用 scons 来进行构建工程，通过 SConscript 控制文件和 group 加入到工程中进行编译。
1.8K10发布于 2021-03-04 - 来自专栏音视频技术
通过QUIC 0-RTT建立更快的连接
此外，之中会有一些风险如通过API端点发送HTTP请求间的bank API重放攻击、Cloudware如何拒绝0-RTT请求并通过加密保护连接网络。感谢学而思网校架构师刘连响对本文的技术审校。 Attack of the clones 0-RTT连接恢复并非那么简单，它会带来许多意外风险及警告，这正是为什么Cloudfare默认程序不启用0-RTT连接恢复的原因。 在0-RTT阶段之后、或握手之后发送的数据，仍然是安全的。 这使得origins对于安全的端点进行0-RTT请求更有可能，例如网站的索引页面是对于0-RTT最有用处的地方。 One stop shop for all your 0-RTT needs 就像之前的TLS 1.3 ，我们现在已支持QUIC的0-RTT恢复。
2.6K20发布于 2019-12-25 - 来自专栏音视频技术
QUIC之拥塞控制和0-RTT连接建立
特别是在高延迟的网络上（比如，超过50ms RTT的网络），丢包会严重影响网络性能。 另一个问题是，我们无法提前知道最大带宽将是多少。它通常取决于端到端连接中的瓶颈，但是我们无法预测或知道它的所在。 在较慢的网络上，这意味着100ms~200ms的开销。 图2：TCP+TLS vs. QUIC连接建立 你也许想知道为什么TCP + TLS握手无法简单地合并，并在同一个RTT中完成。 尤其是在网速比较快的情况下（比如，小于50ms的RTT），几乎很难发现其中的差别，显然较慢的网络和较远的服务器连接受益显著。 接下来，你也许想知道我们需要等待握手的原因。 比如，服务器可以检查0-RTT是否来自之前与其有效连接的IP[26]。不过，只有客户端存在于同一网络时才有效（在某种程度上限制了QUIC的连接迁移特性[27]）。 因此，如果你的用户使用的是具备很高延迟的网络（比如，超过200ms RTT的卫星网络）或者你通常不会发送太多数据，这一特性将会非常有效。
1.1K10编辑于 2022-09-14 - 来自专栏嵌入式实验基地
RT-Thread OLED驱动流程（RTT-Studio平台））
最近RT-Thread举办了一个RTT全连接大赛，也是借着这次机会，申请了一块RTT的STM32H750为主控芯片的RTT核心板，做工还是很漂亮的，老规矩，话不多说，上干货！
2.5K41发布于 2021-08-16 - 来自专栏Rice嵌入式
如何移植RTT微内核到树莓派3B
socket 接口( SAL/socket ); 设备驱动框架接口; 可选的设备驱动(如 UART , GPIO , IIC 等); 如下图： 而在用戶态中,也包括了一些具体的实现,例如文件系统的实现,网络协议栈的实现等 : 具体的文件系统实现,例如 FAT 文件系统 elmFATKit ; 具体的 TCP/IP 网络协议栈实现,例如 lwIP 轻型网络协议栈 lwIPKit ; 图形用戶界面( GUI )实现 - PersimKit ; 音频流媒体播放器服务 - AudioKit ; 以及一些用戶态驱动: USB 、 LCD 等驱动; RT-Thread Smart的工程 目前RTT还没将内核源码开源，不过据RTT的老大说，RT-Thread rice@rice:~/rtt/rtthread-microkernel-v2/tool/env-cli$ cd ../ rice@rice:~/rtt/rtthread-microkernel-v2/ :~/rtt$ rice@rice:~/rtt/rtthread-microkernel-vmv gcc-arm-none-eabi-5_4-2016q3-20160926-linux gcc-arm-none-eabi
1.1K30编辑于 2022-05-10 - 来自专栏草根博客站长Live
开始体验 TLSv1.3 的 Early data (0-RTT)
第二步：TCP 握手（ 1 RTT） 和服务器建立 TCP 连接，客户端向服务器发送 SYN 包，服务端返回确认的 ACK 包，这会花费一个往返（1 RTT） 第三步：TLS 握手 （2 RTT） 该部分客户端会和服务器交换密钥 ，同时设置加密链接，对于 TLS 1.2 或者更早的版本，这步需要 2 个 RTT 第四步：建立 HTTP 连接（1 RTT） 一旦 TLS 连接建立，浏览器就会通过该连接发送加密过的 HTTP 请求。 2 RTT 变为 1 RTT。 总结： 建立新连接 ：4 RTT + DNS 查询时间 访问刚浏览过的连接：3 RTT + DNS 查询时间 TLSv1.2 需要 2 个 RTT 完成 TLS 协商，TLSv1.3 只需要一个。 而重复连接 TLSv1.2 需要 1RTT，TLSv1.3 Early data 就可以 0RTT 重复连接，也就是说 TLSv1.3 比 TLSv1.2 少了一个 0RTT，TLSv1.3 比 TLSv1.2
3.6K30发布于 2019-05-15 《打破固有认知：RTO对RTT说“不”的底层逻辑》
RTO（重传超时时间）与RTT（往返时间）的关系，看似只是简单的数值关联，实则藏着网络通信最深刻的生存逻辑——RTO从不甘心成为RTT的固定倍数。 RTT作为数据从发送端到接收端再返回确认的时间总和，本应是衡量网络延迟的直观指标。但真实的网络环境里，它从不是一个稳定的数值。 假设某条链路的平均RTT是100ms，固定3倍的RTO便是300ms。可当网络突然拥堵，实际RTT飙升至400ms时，300ms的RTO会让发送端过早判定数据包丢失并启动重传。 它需要像经验丰富的航海家，既根据洋流（RTT历史数据）预判航线，又要为突发风浪（网络抖动）预留缓冲。TCP协议通过复杂的算法，让RTO始终保持对RTT变化的敏感。 RTO对RTT的“不盲从”，正是TCP协议历经数十年迭代后，对网络本质的深刻洞察，在网络通信中，误判重传的代价远高于轻微延迟。
17300编辑于 2025-07-13- 来自专栏Rice嵌入式
R-Plan上位机-cmd console & rtt ota pack (1)
背景 嵌入式开发工具繁多，特别是在windows，每次开发，各种工具都要打开，比如串口，网络调试助手等，挺烦的。有时打开多个的时候，很难辨别。 功能 目前已经完成了两个功能- 《cmd console》 & 《rtt ota pack》 这两个功能比较相似，都是调用QT的QProcess的API，即调用外部程序。 问题 如何将按键值通过QProcess输入到cmd.exe--比较麻烦 输入，目前还有一些问题--这个问题不太大 演示 rtt ota pack rtt ota pack比较简单，rtt提供了工具-
62730编辑于 2022-05-10 - 来自专栏码海
为了解决这个 RTT 过长的问题，我祭出了大招！
问题描述 前端同学发现新开发的项目接口有 1/3 概率出现 RTT（请求往返时间）大于 3 s 的情况，以登录接口为例，Chrome 请求所花时间如下 ? 正常的 RTT 在几十 ms 左右，所以 3s 这个时延肯定不正常，于是着手排查，由于每个接口都可能超过 3s，所以下文皆以登录接口分析为例，因为登录接口逻辑相对比较简单。 排查思路 1. 的问题，不急，我们要先把浏览器本身可能导致请求缓慢的问题给排除了，浏览器本身可能因为「请求最大并发数量限制」，「更高优先级的请求插队，低优先级的任务被延后」等原因导致请求缓慢 所以为了排除浏览器本身造成的网络请求过慢 curl 在终端请求也发现了 RTT 大于 3s 的情况，如何使用 curl 请求呢，这里提醒一下，大家千万不要傻傻地去构建一个 curl 请求，浏览器的网络请求本身可以导出成 curl 的形式的，在「 network」中点击网络请求，选中「Copy as cURL」，就可获取此请求的 curl 表示方式 ?
2.1K40发布于 2021-06-17
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号