1.如何在项目中使用RTOS分析工具SystemView？
2.linux内核源码：网络通信简介——网络拥塞控制之BBR算法
3.音视频协议--NACK系列一
4.RTT笔记-fal
5.手把手教你把JLink变成串口调试助手
6.什么是IP欺骗

如何在项目中使用RTOS分析工具SystemView？

       在RTOS应用设计中，开发者往往难以直接观察到多任务系统运行时的实时行为，因为这些行为不仅受源代码影响，还与任务、中断、输入及其相互作用紧密相关。phpcgi源码为解决这一问题，可视化分析工具如SEGGER公司的SystemView应运而生。SystemView提供全面洞察，通过时间轴、CPU负载、运行时间信息和上下文运行时信息的可视化窗口，帮助开发者深入理解应用的执行过程。

       本文将介绍如何使用Segger J-Link和NXP LPC开发板，实现SystemView的移植与使用，以FreeRTOS .3.0版本为例。SystemView支持多种RTOS系统，包括uC/OS-II、μC/OS-III、FreeRTOS、embOS和裸机系统。

       SystemView工作模式包括持续记录、Single-Shot和Post-Mortem模式。持续记录模式通过J-Link调试器和实时传输技术（RTT）实现，实时记录目标程序运行情况。Single-Shot模式适用于不支持RTT或未使用J-Link的情况，记录数据直至缓冲区满为止。Post-Mortem模式在缓冲区满时覆盖旧事件，用于分析系统崩溃前的情况。

       为了在目标设备上使用SystemView，首先需要在应用工程中添加SystemView和RTT的源码文件。这包括配置文件、实现源码和针对不同OS及版本的接口文件。配置FreeRTOS跟踪功能，通过编译宏在FreeRTOSConfig.h中包含SystemView相关代码。此外，还需设置SystemView工作模式、事件缓存大小，并在任务创建前调用初始化函数。

       在PC端，安装和设置SystemView软件。通过Target->Recorder Configuration选项配置目标设置、调试接口类型和接口速度。选择Auto检测RTT控制块地址。点击Target->Start Recording开始跟踪记录。在持续记录模式下，跟踪视图显示RTOS应用中的中断和任务，直观展示任务抢占过程，id生成框架源码有助于开发者优化代码。

       借助SystemView，开发者能更直观地理解RTOS应用的实时行为，有效提升代码质量，创造更高性能的系统。

linux内核源码：网络通信简介——网络拥塞控制之BBR算法

       从网络诞生至十年前，TCP拥塞控制采用的经典算法如reno、new-reno、bic、cubic等，在低带宽有线网络中运行了几十年。然而，随着网络带宽的增加以及无线网络通信的普及，这些传统算法开始难以适应新的环境。

       根本原因是，传统拥塞控制算法将丢包/错包等同于网络拥塞。这一认知上的缺陷导致了算法在面对新环境时的不适应性。BBR算法的出现，旨在解决这一问题。BBR通过以下方式控制拥塞：

       1. 确保源端发送数据的速率不超过瓶颈链路的带宽，避免长时间排队造成拥塞。

       2. 设定BDP（往返延迟带宽积）的上限，即源端发送的待确认在途数据包（inflight）不超过BDP，换句话说，双向链路中数据包总和不超过RTT（往返延迟）与BtlBW（瓶颈带宽）的乘积。

       BBR算法需要两个关键变量：RTT（RTprop：往返传播延迟时间）和BtlBW（瓶颈带宽），并需要精确测量这两个变量的值。

       1. RTT的定义为源端从发送数据到收到ACK的耗时，即数据包一来一回的时间总和。在应用受限阶段测量是最合适的。

       2. BtlBW的测量则在带宽受限阶段进行，通过多次测量交付速率，将近期的最大交付速率作为BtlBW。测量的时间窗口通常在6-个RTT之间，确保测量结果的准确性。

       在上述概念基础上，BBR算法实现了从初始启动、排水、探测带宽到探测RTT的四个阶段，以实现更高效、更稳定的网络通信。

       通信双方在节点中，通过发送和接收数据进行交互。BBR算法通过接收ACK包时更新RTT、部分包更新BtlBW，以及发送数据包时判断inflight数据量是否超过BDP，通过一系列动作实现数据的网页源码搜索文本有效传输。

       在具体的实现上，BBR算法的源码位于net\ipv4\tcp_bbr.c文件中（以Linux 4.9源码为例）。关键函数包括估算带宽的bbr_update_bw、设置pacing_rate来控制发送速度的bbr_set_pacing_rate以及更新最小的RTT的bbr_update_min_rtt等。

       总的来说，BBR算法不再依赖丢包判断，也不采用传统的AIMD线性增乘性减策略维护拥塞窗口。而是通过采样估计网络链路拓扑情况，极大带宽和极小延时，以及使用发送窗口来优化数据传输效率。同时，引入Pacing Rate限制数据发送速率，与cwnd配合使用，有效降低数据冲击。

音视频协议--NACK系列一

       在WebRTC技术中，前向纠错（FEC）与丢包重传（NACK）是抵抗网络错误的关键手段。FEC通过在发送端添加纠错码，确保数据包在接收端正确检查与纠正；而NACK机制在接收端发现数据丢失后，向发送端发送报文，促使发送端重新发送丢失的数据包。NACK机制在RFC中有详细定义。

       本文以WebRTC源代码为基础，针对Video数据包的发送与接收，深入分析了NACK丢包重传机制的实现。主要内容涉及SDP协议中NACK的协商、接收端对丢包的判定、NACK报文的构造、发送、接收与解析，以及RTP数据包的重传。

       在NACK框架中，NACK与ACK是通知机制的对比，当接收方未收到数据时，向发送方发送通知。根据RFC协议，重传未到达数据的类型分为RTPFB和PSFB。在WebRTC中，NACK功能与视频编解码器关联，用于补偿因RTT延迟较小而产生的丢包问题。WebRTC在处理NACK重传时，设计了一个重传码率控制器，通过统计单位时间窗口周期内的数据发送量，限流以避免网络风暴。

       NACK算法构建与实现方面，WebRTC的NACK算法通过NACKList进行数据包处理与反馈。具体流程包括接收RTP包、解析包头信息、html查看网站源码数据帧获取与处理、构建NACKList，以及将NACKList通过RTCP反馈给发送端，实现数据包重发。

       优化音视频流畅度过程中，发现NACK机制存在一定的问题，如通话初期有7~秒黑屏现象。分析后，马赛克问题可能与NACK参数优化不足有关。而黑屏问题可能与Android版本的NACK请求数据量较大且响应较慢有关，而iOS版本的NACK请求则更少且反应更快。针对这些问题，需要优化NACK机制参数与反馈机制，确保音视频流畅度。

       通过改进NACK机制，结合网络状况与设备特性进行针对性优化，可以有效提升WebRTC通话过程中的音视频流畅度，降低黑屏、马赛克与卡顿现象，提供更优质的用户体验。

RTT笔记-fal

        该笔记类别主要是在自己学习时做的一些记录，方便自己很久不用忘掉时进行快速回忆

        然后导入头文件地址

        在rtconfig.h文件中添加宏定义

        根据在移植文件中定义的存储空间名字来分区，例如在fal_flash_stml1_port.c中定义了

        则在fla_cfg.h中可用如下划分区域

        注意的是头文件中必须使用宏(FAL_PART_HAS_TABLE_CFG)，才会使用这里定义的分区方式

        输出结果：

        先读取3个寄存器，然后写入新数据1,2,3，再次读取显示出来。串口打印结果在第一次读取时输出为零，在擦除写入后读取出来便是数据1,2,3. 复位模块后第一次读取出的数据也为1,2,3. 表示掉电保存成功了。

        失败返回NULL

        led：分区表长度

        FAL 初始化时会自动装载默认分区表。使用该设置将临时修改分区表，重启后会 丢失 该设置

        返回实际读取大小

        该函数可以根据指定的分区名称，创建对应的块设备，以便于在指定的分区上挂载文件系统

        该函数可以根据指定的分区名称，创建对应的 MTD Nor Flash 设备，以便于在指定的分区上挂载文件系统

        该函数可以根据指定的分区名称，创建对应的字符设备，以便于通过 deivice 接口或 devfs 接口操作分区，开启了 POSIX 后，还可以通过 oepn/read/write 函数操作分区

        使用一节中提到的samples\porting目下便是移植需要修改的文件，例如源码只提供了fal_flash_sfud_port.c和fal_flash_stmf2_port.c两个文件，我想在芯片stmL上使用它的eeprom，则自己新建立一个文件，实现初始化、读、写、擦即可，最后在同目录下的fal_cfg.h中进行分区，就想下面这样

        fal_flash_stml1_port.c

        同理无论任何存储，只需要实现对于接口后，上层使用便没有任何区别

        /RT-Thread-packages/fal

手把手教你把JLink变成串口调试助手

       在单片机开发过程中，打印调试信息通常依赖于串口调试。通常，我们会预留串口1进行调试，但如果在实际项目中没有预留，JLink仿真调试器可以成为你的得力助手。JLink，由SEEGER公司出品，体积小巧，只有四根线，非常适合携带和使用，尤其适合ST系列芯片的开发。

       首先，确保你的电脑上已安装JLink驱动，可以从segger.com下载最新版本的JLink V7.或更高版本。安装完成后，你将发现安装目录下包含RTT功能的相关文件。RTT源码包位于JLink驱动的Samples\RTT文件夹中，只需将其复制到项目文件夹并与工程中的.c文件集成即可。

       接下来，配置RTT功能。在编译无误后，连接JLink下载器，并启动JLinkRTTViewer.exe。配置好RTT参数，将程序下载到单片机，就能看到打印信息了。java 项目源码idea注意，RTT的缓冲大小可自定义，以适应大量信息的打印需求。

       RTT还支持多虚拟端口打印，以及颜色定制，只需在字符串前添加对应宏定义。此外，你还可以通过重定向printf到RTT来简化调试，只需替换fputc函数即可。这样，即使在没有预留串口的情况下，你也能轻松进行调试和打印信息。

       总结来说，当遇到项目中无串口调试需求时，JLink的RTT功能是一个实用的解决方案，可以根据具体项目的特点灵活运用。通过这个方法，你可以轻松地在单片机开发中实现调试打印。

什么是IP欺骗

       IP欺骗的技术比较复杂，不是简单地照猫画老虎就能掌握，但作为

       常规攻击手段，有必要理解其原理，至少有利于自己的安全防范，

       易守难攻嘛。

       假设B上的客户运行rlogin与A上的rlogind通信：

       1. B发送带有SYN标志的数据段通知A需要建立TCP连接。并将TCP

       报头中的sequence number设置成自己本次连接的初始值ISN。

       2. A回传给B一个带有SYS+ACK标志的数据段，告之自己的ISN，并

       确认B发送来的第一个数据段，将acknowledge number设置成

       B的ISN+1。

       3. B确认收到的A的数据段，将acknowledge number设置成A的

       ISN+1。

       B ---- SYN ----> A

       B <---- SYN+ACK A

       B ---- ACK ----> A

       TCP使用的sequence number是一个位的计数器，从0-。

       TCP为每一个连接选择一个初始序号ISN，为了防止因为延迟、重传

       等扰乱三次握手，ISN不能随便选取，不同系统有不同算法。理解

       TCP如何分配ISN以及ISN随时间变化的规律，对于成功地进行IP欺

       骗攻击很重要。

       基于远程过程调用RPC的命令，比如rlogin、rcp、rsh等等，根据

       /etc/hosts.equiv以及$HOME/.rhosts文件进行安全校验，其实质

       是仅仅根据信源IP地址进行用户身份确认，以便允许或拒绝用户

       RPC。关于上述两个文件请man，不喜欢看英文就去Unix版看看我

       以前灌过的一瓢水。

       IP欺骗攻击的描述：

       1. 假设Z企图攻击A，而A信任B，所谓信任指/etc/hosts.equiv

       和$HOME/.rhosts中有相关设置。注意，如何才能知道A信任

       B呢？没有什么确切的办法。我的建议就是平时注意搜集蛛丝

       马迹，厚积薄发。一次成功的攻击其实主要不是因为技术上

       的高明，而是因为信息搜集的广泛翔实。动用了自以为很有

       成就感的技术，却不比人家酒桌上的巧妙提问，攻击只以成

       功为终极目标，不在乎手段。

       2. 假设Z已经知道了被信任的B，应该想办法使B的网络功能暂时

       瘫痪，以免对攻击造成干扰。著名的SYN flood常常是一次

       IP欺骗攻击的前奏。请看一个并发服务器的框架：

       int initsockid, newsockid;

       if ((initsockid = socket(...)) <0) {

       error("can''t create socket");

       }

       if (bind(initsockid, ...) <0) {

       error("bind error");

       }

       if (listen(initsockid, 5) <0) {

       error("listen error");

       }

       for (;;) {

       newsockid = accept(initsockid, ...); /* 阻塞 */

       if (newsockid <0) {

       error("accept error");

       }

       if (fork() == 0) { /* 子进程 */

       close(initsockid);

       do(newsockid); /* 处理客户方请求 */

       exit(0);

       }

       close(newsockid);

       }

       listen函数中第二个参数是5，意思是在initsockid上允许的

       最大连接请求数目。如果某个时刻initsockid上的连接请求数

       目已经达到5，后续到达initsockid的连接请求将被TCP丢弃。

       注意一旦连接通过三次握手建立完成，accept调用已经处理这

       个连接，则TCP连接请求队列空出一个位置。所以这个5不是指

       initsockid上只能接受5个连接请求。SYN flood正是一种

       Denial of Service，导致B的网络功能暂 碧被尽?nbsp;

       Z向B发送多个带有SYN标志的数据段请求连接，注意将信源IP

       地址换成一个不存在的主机X；B向子虚乌有的X发送SYN+ACK

       数据段，但没有任何来自X的ACK出现。B的IP层会报告B的

       TCP层，X不可达，但B的TCP层对此不予理睬，认为只是暂时的。

       于是B在这个initsockid上再也不能接收正常的连接请求。

       Z(X) ---- SYN ----> B

       Z(X) ---- SYN ----> B

       Z(X) ---- SYN ----> B

       Z(X) ---- SYN ----> B

       Z(X) ---- SYN ----> B

       ......

       X <---- SYN+ACK B

       X <---- SYN+ACK B

       X <---- SYN+ACK B

       X <---- SYN+ACK B

       X <---- SYN+ACK B

       ......

       作者认为这样就使得B网络功能暂时瘫痪，可我觉得好象不对头。

       因为B虽然在initsockid上无法接收TCP连接请求，但可以在

       another initsockid上接收，这种SYN flood应该只对特定的

       服务(端口)，不应该影响到全局。当然如果不断地发送连接请

       求，就和用ping发洪水包一个道理，使得B的TCP/IP忙于处理

       负载增大。至于SYN flood，回头有机会我单独灌一瓢有关DoS

       的。如何使B的网络功能暂 碧被居 很多办法，根据具体情况而

       定，不再赘述。

       3. Z必须确定A当前的ISN。首先连向端口(SMTP是没有安全校验

       机制的)，与1中类似，不过这次需要记录A的ISN，以及Z到A的

       大致的RTT(round trip time)。这个步骤要重复多次以便求出

       RTT的平均值。现在Z知道了A的ISN基值和增加规律(比如每秒增

       加，每次连接增加)，也知道了从Z到A需要RTT/2

       的时间。必须立即进入攻击，否则在这之间有其他主机与A连接，

       ISN将比预料的多出。

       4. Z向A发送带有SYN标志的数据段请求连接，只是信源IP改成了

       B，注意是针对TCP端口(rlogin)。A向B回送SYN+ACK数据段，

       B已经无法响应(凭什么？按照作者在2中所说，估计还达不到

       这个效果，因为Z必然要模仿B发起connect调用，connect调用

       会完成全相关，自动指定本地socket地址和端口，可事实上

       B很可能并没有这样一个端口等待接收数据。除非Z模仿B发起

       连接请求时打破常规，主动在客户端调用bind函数，明确完成

       全相关，这样必然知道A会向B的某个端口回送，在2中也针对

       这个端口攻击B。可是如果这样，完全不用攻击B，bind的时候

       指定一个B上根本不存在的端口即可。我也是想了又想，还没来

       得及看看老外的源代码，不妥之处有待商榷。总之，觉得作者

       好象在蒙我们，他自己也没有实践成功过吧。)，B的TCP层只是

       简单地丢弃A的回送数据段。

       5. Z暂停一小会儿，让A有足够时间发送SYN+ACK，因为Z看不到这

       个包。然后Z再次伪装成B向A发送ACK，此时发送的数据段带有

       Z预测的A的ISN+1。如果预测准确，连接建立，数据传送开始。

       问题在于即使连接建立，A仍然会向B发送数据，而不是Z，Z

       仍然无法看到A发往B的数据段，Z必须蒙着头按照rlogin协议

       标准假冒B向A发送类似 "cat + + >> ~/.rhosts" 这样的命令，

       于是攻击完成。如果预测不准确，A将发送一个带有RST标志的

       数据段异常终止连接，Z只有从头再来。

       Z(B) ---- SYN ----> A

       B <---- SYN+ACK A

       Z(B) ---- ACK ----> A

       Z(B) ---- PSH ----> A

       ......

       6. IP欺骗攻击利用了RPC服务器仅仅依赖于信源IP地址进行安全

       校验的特性，建议阅读rlogind的源代码。攻击最困难的地方

       在于预测A的ISN。作者认为攻击难度虽然大，但成功的可能性

       也很大，不是很理解，似乎有点矛盾。考虑这种情况，入侵者

       控制了一台由A到B之间的路由器，假设Z就是这台路由器，

       那么A回送到B的数据段，现在Z是可以看到的，显然攻击难度

       骤然下降了许多。否则Z必须精确地预见可能从A发往B的信息，

       以及A期待来自B的什么应答信息，这要求攻击者对协议本身相

       当熟悉。同时需要明白，这种攻击根本不可能在交互状态下完

       成，必须写程序完成。当然在准备阶段可以用netxray之类的

       工具进行协议分析。

       7. 如果Z不是路由器，能否考虑组合使用ICMP重定向以及ARP欺骗

       等技术？没有仔细分析过，只是随便猜测而已。并且与A、B、

       Z之间具体的网络拓扑有密切关系，在某些情况下显然大幅度

       降低了攻击难度。注意IP欺骗攻击理论上是从广域网上发起的，

       不局限于局域网，这也正是这种攻击的魅力所在。利用IP欺骗

       攻击得到一个A上的shell，对于许多高级入侵者，得到目标主

       机的shell，离root权限就不远了，最容易想到的当然是接下来

       进行buffer overflow攻击。

       8. 也许有人要问，为什么Z不能直接把自己的IP设置成B的？这个

       问题很不好回答，要具体分析网络拓扑，当然也存在ARP冲突、

       出不了网关等问题。那么在IP欺骗攻击过程中是否存在ARP冲突

       问题。回想我前面贴过的ARP欺骗攻击，如果B的ARP Cache没有

       受到影响，就不会出现ARP冲突。如果Z向A发送数据段时，企图

       解析A的MAC地址或者路由器的MAC地址，必然会发送ARP请求包，

       但这个ARP请求包中源IP以及源MAC都是Z的，自然不会引起ARP冲

       突。而ARP Cache只会被ARP包改变，不受IP包的影响，所以可以

       肯定地说，IP欺骗攻击过程中不存在ARP冲突。相反，如果Z修改

       了自己的IP，这种ARP冲突就有可能出现，示具体情况而言。攻

       击中连带B一起攻击了，其目的无非是防止B干扰了攻击过程，

       如果B本身已经down掉，那是再好不过(是吗？)。

       9. fakeip曾经沸沸扬扬了一下，我对之进行端口扫描，发现其tcp端

       口是接收入连接的。和IP欺骗等没有直接联系，和安全校验是

       有关系的。当然，这个东西并不如其名所暗示，对IP层没有任何动

       作。

       . 关于预测ISN，我想到另一个问题。就是如何以第三方身份切断

       A与B之间的TCP连接，实际上也是预测sequence number的问题。

       尝试过，也很困难。如果Z是A与B之间的路由器，就不用说了；

       或者Z动用了别的技术可以监听到A与B之间的通信，也容易些；

       否则预测太难。作者在3中提到连接A的端口，可我想不明白的

       是端口的ISN和端口有什么关系？看来需要看看TCP/IP内部

       实现的源代码。

       未雨绸缪

       虽然IP欺骗攻击有着相当难度，但我们应该清醒地意识到，这种攻击

       非常广泛，入侵往往由这里开始。预防这种攻击还是比较容易的，

       比如删除所有的/etc/hosts.equiv、$HOME/.rhosts文件，修改/etc/

       inetd.conf文件，使得RPC机制无法运做，还可以杀掉portmapper等等。

       设置路由器，过滤来自外部而信源地址却是内部IP的报文。cisio公司

       的产品就有这种功能。不过路由器只防得了外部入侵，内部入侵呢？

       TCP的ISN选择不是随机的，增加也不是随机的，这使攻击者有规可循，

       可以修改与ISN相关的代码，选择好的算法，使得攻击者难以找到规律。

       估计Linux下容易做到，那solaris、irix、hp-unix还有aix呢？sigh

       虽然作者纸上谈兵，但总算让我们了解了一下IP欺骗攻击，我实验过

       预测sequence number，不是ISN，企图切断一个TCP连接，感觉难度

       很大。作者建议要找到规律，不要盲目预测，这需要时间和耐心。现

       在越发明白什么是那种锲而不舍永远追求的精神，我们所向往的传奇

       故事背后有着如此沉默的艰辛和毅力，但愿我们学会的是这个，而不是

       浮华与喧嚣。一个现成的bug足以让你取得root权限，可你在做什么，

       你是否明白？我们太肤浅了......