TCP超时与重传核心问题 发送时设置一个定时器来解决数据和确认可能丢失的问题 如何确定超时判断间隔？ 如何确定重传的频率？ 1，2，4，8， 16，32，64…… 典型实现 测量TCP报文段的往返时间 这样才能比较好的确定超时时间 发出数据 -> 收到ACK的时间间隔？ 使用测量结果对下一个将要传输的报文段建立重传超时时间 四个定时器 对每个连接，TCP管理四个不同的定时器 重传

任务切换 task_struct->stack成员指向的内存空间就是内核栈 陷入内核时，用户任务上下文保存在其内核栈上：且保存的位置也是固定的，就在内核栈空间最上方预留的的pt_regs区域 参考《vectors.md》种entry_handler的定义：mov x0, sp; bl el\el\ht\()_\regsize\()_\label\()_handler 参考 kernel_

中断处理初期汇编码&dup2分析参考博客 ARM-GNU常用汇编伪指令 ARM64底层中断处理 总结 kernel_ventry : el 0 64 sync el0t_64_sync kernel_entry \el -> 保存异常处理的现场[x0-29, lr, sp(sp_el0/1), pc(elr_el1), pstate(spsr_el1)]到当前spsp_e

TCP学习（misc）参考书籍 《TCPIP详解：卷1》 TCP概览 - 可靠性应用数据被分割成TCP认为最适合发送的数据块；如何确定合适的数据块长度？【18.4】TCP发出一个段后启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段；【21章：自适应超时及重传机制】延迟确认：收到发自TCP连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几

TCP学习（三） 滑动窗口是相对于确认号开始的 慢启动 核心点：新分组进入网络的速率应该与另一端返回确认的速率相同而进行工作 拥塞窗口【给发送方使用，cwnd】 发送方使用拥塞窗口与通告窗口的最小值作为发送上限： 拥塞窗口是发送方使用的流量控制：大小根据接收到的ACK数量指数增加，会与延迟确认冲突嘛？ 通告窗口则是接收方使用的流量控制

TCP学习（二）连接建立 - 三次握手 - 沟通双方的初始序列号 请求端发送SYN段，包含发端初始序号（ISN-C），以及服务器端口，MSS 服务器通过发送SYN进行响应：包含收端初始序号(ISN-S)，ACK被设置为1作为对请求端SYN的确认，确认序号 = ISN-C + 1， MSS 请求端发送ACK，响应服务器的SYN：ACK被设置为1作为对服务器SYN的确认，确认序号 =

TCP学习（一） TCP只对含有数据的ACK进行确认【发端超时重传】；单独的ACK不会发送不会设置超时定时器 因此TCP要考虑每个阶段中可能出现的ACK丢失的情况！！！ 报文类型 通过头部的控制位（6bit）区分不同的报文类型： SYN报文：用于建立连接，包含SYN标志 -> 需要占用一个序号；其中包含最大报文段长度信息，且该信息只能出现在SYN中 ACK报文：用于确认接收

常用宏 WRITE_ONCE && READ_ONCE 从__native_word的定义可以看出，所谓的原子读写并不能保证，只是尽可能地避免 对一个10字节的数据进行读写，肯定要分成2次以上的内存访问操作 如果为一个原始类型：char, short, int, long, long long，对其进行读写操作就只产生一次内存访问 有些需要避免竞态的，需要加锁 123456789

高级I/O I/O多路复用 有多个描述符，数据可能在任一个描述符上到达（可用），但是事先无法知道究竟是哪一个描述符 不能对任意一个描述符进行阻塞读操作，因为数据可能已经在其它描述符上到达 使用两个或多个进程/线程分别处理一个描述符，但是带来资源开销、同步处理的问题 不使用阻塞I/O：对所有描述符进行轮询处理 异步I/O+信号：信号数量有限，无法与描

线程 每个线程都包含有表示执行环境所必须的信息 进程中标识线程的线程ID。pthread_t，所有可移植的操作系统实现不能把它作为整数处理，因此必须提供一个函数来对两个线程ID进行比较 一组寄存器值 栈 调度优先级和调度策略 信号屏蔽字 -> 继承于创建它的线程 errno变量 线程私有数据 POSIX线程的功能测试宏是**_POSIX_THREADS**，可以用它在编译时确定是否支持