- 博客(136)
- 收藏
- 关注
RSS订阅原创 传输层协议TCP（上）
本文深入解析了TCP协议的关键机制：1. TCP报文格式详解，包括源/目的端口、序列号、确认号等核心字段；2. 通过"数据偏移"字段实现报头与载荷分离的原理；3. 确认应答(ACK)机制保障可靠传输，32位序号/确认序号实现精确应答；4. 流量控制机制通过"窗口大小"动态调整发送速率；5. 6个关键标志位(SYN/ACK/FIN/PSH/RST/URG)的功能及组合应用；6. 紧急指针实现带外数据传输。文章系统阐述了TCP如何通过序号机制、确认应答、流量控制等实现可靠
2025-05-29 19:22:35
2
原创 传输层协议UDP
本文深入探讨了网络编程的传输层原理，重点分析了UDP协议的特性与实现机制。文章首先明确了传输层在网络协议栈中的位置，指出其核心作用是在发送端和接收端之间传输数据。通过对UDP协议格式的详细解析，说明了UDP报头包含的四个关键字段：源端口、目的端口、长度和校验值。文章阐述了UDP的典型特征包括无连接、不可靠但高效传输、面向数据报等特点，并分析了其适用场景。此外，还探讨了UDP的缓冲区管理机制，解释了端口号的作用原理，以及操作系统如何通过sk_buff结构体来组织和管理网络数据包。最后，文章简要介绍了基于UDP
2025-05-24 17:35:18
1098
原创 HTTP 协议详解
本文介绍了HTTP协议的基础知识，包括其无连接、无状态特性以及URI/URL编码规则。重点分析了HTTP请求/响应格式，详细讲解了GET/POST方法的应用场景和区别，并列举了常见的HTTP状态码和Header字段。文章通过代码示例展示了HTTP服务器的实现原理，包括静态资源处理、动态交互、Cookie/Session管理等核心功能。最后梳理了HTTP各版本的技术演进，从HTTP/0.9到HTTP/3.0的性能优化路径。内容涵盖HTTP协议从基础到实践的完整知识体系，适合作为网络开发的参考指南。
2025-05-23 22:03:42
1280
1
原创 从零实现一个高并发内存池 - 6
本文介绍了高并发内存池项目的优化与性能测试过程。项目通过三层缓存机制（线程缓存、中央缓存、页面缓存）管理内存分配，针对不同大小的内存请求采用不同的策略：小于等于256KB的内存请求通过三层缓存快速分配，大于256KB的内存请求则根据大小进一步细分处理。优化过程中，使用定长内存池替代malloc和new，减少内存碎片，提升分配效率。此外，通过基数树（Radix Tree）优化了内存映射的查找效率，实现了无锁读取，显著提升了多线程环境下的性能。最终的性能测试表明，优化后的内存池在多线程环境下表现优于传统的mal
2025-05-18 01:21:16
895
原创 从零实现一个高并发内存池 - 5
本文详细介绍了内存回收机制，重点在于线程缓存、中央缓存和页面缓存之间的内存回收流程。当线程缓存的链表过长时，会将多余的内存块批量返回到中央缓存，中央缓存再根据内存块大小将其放入全局链表供其他线程使用。为了高效管理内存块与Span的映射关系，采用`unordered_map`记录页号与Span的映射。当Span的`useCount`为0时，表示所有小块内存对象已回收，可以将其归还到页面缓存。页面缓存会尝试合并相邻的Span以缓解内存碎片问题，并通过`_isUse`标志位避免线程安全问题。
2025-05-17 01:06:02
737
原创 从零实现一个高并发内存池 - 4
本文详细介绍了高并发内存池中的PageCache层，重点阐述了其内存申请和释放的过程。PageCache作为内存池的最后一层，负责管理大块内存的分配与回收。当CentralCache向PageCache申请内存时，PageCache会检查对应的Span是否存在，若不存在则向后寻找更大的Span进行分裂。如果仍找不到合适的Span，PageCache会向操作系统申请大块内存并切分。PageCache的核心结构是基于SpanList的哈希桶，与CentralCache不同，它采用直接定址法映射，能够高效处理大块
2025-05-16 15:34:14
900
原创 从零实现一个高并发内存池 - 3
本文详细介绍了高并发内存池中的中央缓存（CentralCache）结构及其工作原理。中央缓存采用哈希桶结构，与线程本地缓存（ThreadCache）的映射关系一致，但中央缓存是共享的，需要加锁。每个哈希桶挂载一个SpanList链表，Span管理大块内存，并将其切割成小内存块对象，挂载在自由链表中。中央缓存使用桶锁，减少锁竞争。内存申请流程中，当ThreadCache内存不足时，会向CentralCache批量申请内存，采用慢开始算法控制申请数量。若CentralCache内存不足，则向PageCache申
2025-05-15 17:57:33
1019
原创 从零实现一个高并发内存池 - 2
《高并发内存池-threadcache》一文详细介绍了ThreadCache的基本结构与原理。ThreadCache基于哈希桶结构，每个桶维护一个自由链表，用于存储特定大小的内存块。系统为每个线程配备独立的ThreadCache对象，通过无锁操作提升内存分配与释放的效率。内存申请流程包括分段对齐、桶位置映射及从CentralCache获取内存块。内存释放流程则将内存块推回对应桶的自由链表，若链表过长则触发回收机制。文章还介绍了线程本地存储（TLS）在多线程环境中的应用，确保了线程间数据隔离与无锁操作。通过分
2025-05-14 20:21:29
748
原创 从零实现一个高并发内存池 - 1
本文深入探讨了C++中内存管理的重要性，并介绍了如何通过内存池技术提升程序性能。传统的内存分配方式如malloc和free在高并发场景下存在性能瓶颈，而内存池通过预先申请大块内存并在程序内部管理分配，显著提高了内存分配效率和减少了内存碎片。文章详细解析了Google的tcmalloc内存分配器，它通过线程缓存、中央缓存和页缓存三层结构优化了多线程环境下的内存分配。此外，文章还展示了如何实现一个定长内存池，并通过实验比较了传统new/delete与内存池在性能上的差异，证明了内存池在高频内存操作中的优势。
2025-05-13 19:36:14
1059
原创 进程间关系与守护进程
本文主要介绍了客户端与服务端之间的自定义协议实现及序列化处理。在前一篇中，我们实现了服务端的代码，本篇补充了客户端的实现。客户端同样需要遵循协议，并通过序列化向服务端发送请求报文，接收服务端返回的序列化应答报文，再通过反序列化获取可读的应答数据。为了实现这一功能，我们进一步完善了 Protocol 类，增加了 GetResponse 接口用于获取服务端应答，以及 BuildRequestString 接口用于构建并序列化请求报文。通过这些接口，客户端能够与服务端进行有效的通信，并处理返回的数据。此外，文章还
2025-05-11 18:24:49
869
原创 应用层自定义协议与序列化
本文主要探讨了网络协议栈的分层结构，重点介绍了应用层协议的定制与实现。通过分析TCP/IP模型，文章指出应用层协议的本质是双方约定的结构化数据。以网络计算器为例，展示了如何通过序列化和反序列化技术实现数据的结构化传输。文章详细介绍了协议层的设计，包括Request和Response类的定义、报文的编码与解码机制，以及如何解决TCP流式协议中的粘包和拆包问题。同时，文章还介绍了业务逻辑层的实现，包括计算核心和错误码体系的设计。最后，通过Jsoncpp库的示例，展示了如何在实际开发中进行JSON数据的序列化和反
2025-05-10 00:36:08
710
原创 socket套接字-TCP
上一篇：socket套接字-TCP（下）在套接字编程中，UDP是不面向连接，面向数据报的一种通信方式，UDP套接字创建好，直接发送消息就可以通信，而TCP是面向连接的，注定了要比UDP要复杂一点点，但是两者代码的主体是很像的。一样的，我们通过TCP编程来实现一个最简单的功能性验证的服务---Echo Server。
2025-05-07 17:27:27
965
原创 socket套接字-UDP（下）
在实现翻译功能时，服务器通过sockfd文件描述符接收客户端的消息，同时也能通过这个文件描述符向客户端发送消息。这意味着服务器可以收集并保存所有访问客户端的信息。当有新的消息到达时，服务器就可以将保存的客户端信息用于消息的转发。这其实就是群聊功能的基本实现原理。但如果仅用一个 UDP 服务器来实现群聊，就会出现问题。因为服务器同时承担接收和发送消息的任务，这可能影响收发效率，尤其是在高并发情况下。为了解决这个问题，我们可以在服务器收到消息后，将消息和客户端信息放入一个队列中。
2025-04-29 20:32:59
978
1
原创 socket套接字-UDP（中）
通过这一系列的改进，我们的UDP服务器已经从一个简单的消息收发工具，进化成了一个具有实用翻译功能的应用程序。这个过程让我深刻体会到了模块化设计和回调机制的强大之处。它们不仅让我们的代码更加清晰和易于维护，还极大地提高了代码的可扩展性和复用性。在未来的开发中，我计划继续优化这个服务器。比如，增加对更多语言的支持，或者让服务器能够同时处理多个客户端的请求。另外，我还想尝试将这个服务器部署到云平台上，让更多的用户能够使用这个翻译服务。如果你对这个项目感兴趣，或者有任何建议和想法，欢迎随时与我交流。
2025-04-27 21:19:53
848
原创 网络基础概念（上）
TCP/IP协议的本质是一种解决方案；TCP/IP协议能分层，前提是因为问题们本身能分层。操作系统内的协议非常多，每一层都有对应的协议，，将来网络还有报文，报文里会携带各种协议字段，有这么多的协议，未来有这么多的报文，操作系统就需要管理这些协议和报文，如果要管理，又该如何管理？------先描述再组织！！！协议本质就是约定好的结构体。问题：主机 B 能够识别 data，并且准确提取 a=10，b=20，c=30 吗？回答：答案是肯定的。因为双方都有同样的结构体类型。
2025-04-18 09:23:51
1006
原创 线程同步与互斥：线程池
日志系统的设计需要考虑多个方面，包括日志的格式、输出目标（如控制台、文件等）以及线程安全性。C++17引入了文件系统库，使得文件操作更加方便。此外，策略模式允许我们在运行时动态选择日志的输出策略，从而增加了系统的灵活性。单例模式是一种设计模式，像之前单例模式是一种常用的软件设计模式，它确保一个类只有一个实例，并提供一个全局访问点。单例模式的实现需要满足以下两个条件：保证一个类只有一个实例。提供一个全局访问点。
2025-04-15 11:56:02
830
原创 线程概念与控制（上）
我们Linux“线程”，可以采用“进程来模拟”；对资源的划分，本质就是对地址空间，虚拟地址范围的划分，虚拟地址就是资源的代表；我们该如何理解代码区划分？
2025-03-26 19:32:59
863
原创 Linux进程信号（下）
如果信号的处理动作是自定义的信号处理函数（即用户定义的信号处理函数），内核会将控制权返回到用户模式，并执行相应的信号处理函数。这个信号处理函数是在用户空间中定义的，用于处理特定信号的逻辑。
2025-03-20 12:09:11
829
原创 Linux进程信号（中）
递达是终点：信号处理的最终执行阶段，可能终止进程或触发自定义逻辑。未决是等待队列：信号在阻塞期间的临时状态，内核仅记录常规信号一次。如果在进程解除对某信号的阻塞之前这种信号产生过多次，将如何处理？POSIX.1允许系统递送该信号一次或多次。Linux是这样实现的：常规信号在递达之前产生多次只计一次，而实时信号在递达之前产生多次可以依次放在一个队列里。本章不讨论实时信号。阻塞是主动防御：通过屏蔽信号保护关键代码，与忽略（被动丢弃）有本质区别。操作需谨慎：使用和sigpending。
2025-03-18 17:33:36
863
原创 Linux进程信号（上）
就好比你在听到警报声后，根据之前制定的应急计划，迅速找到重要物品并按照预定路线撤离。这是一种经过提前规划和准备的应对方式。在进程里，开发者可以根据需求定义信号的处理逻辑，让进程在接收到信号时执行特定的操作，而不是简单地终止。
2025-03-17 19:00:05
900
原创 进程间通信（补充）
信号量主要用于同步和互斥的！信号量其实很重要，但是system V版本的信号量并不重要，关于信号量，在后面的多线程专题会着重理解！我们这里先引入一些并发编程的概念铺垫。
2025-03-11 14:01:33
934
原创 进程间通信（中）
匿名管道和命名管道的主要区别在于它们的创建和打开方式，以及匿名管道通常用于父子进程间通信，而命名管道用于任意进程间通信。一旦创建和打开完成，它们在通信语义上是相同的。
2025-02-27 20:12:08
1013
原创 进程间通信（上）
（问题我们到网络会解决）（就是我们打开文件时，通常喜欢将打开一个文件，叫做打开一个文件流，文件流就是字节流，我们往文件写一个字符串，再写一个浮点数，写一个整数等等，是很好写的，但是我们向文件读取的时候，我们将字符串，整数，浮点数准确读上来，是有点困难的，因为我们写的时候是一条一条写的，但是读的时候是一坨一坨的都上来的。而且文件间共享就是利用文件描述符，A用A的，B用B的文件描述符，只不过指向同一个文件不就可以，基于这种思路，我们既可以遵守Linux下一切皆文件，也可以将之前的技术服用起来。
2025-02-22 21:45:23
641
原创 库制作与原理（下篇：库的理解与加载）
静态链接的出现，确实提高了程序的模块化水平。对于一个大的项目，不同的人可以独立地测试和开发自己的模块。通过静态链接，生成最终的可执行文件。我们知道静态链接会将编译产生的所有目标文件（.o 文件），以及用到的各种静态库（通常是.a 文件）合并成一个独立的可执行文件。在这个过程中，会修正模块间函数的跳转地址，这一过程也被称为“编译重定位”（或“静态重定位”）。也就是说，静态链接在编译阶段就确定了所有函数和变量的最终地址，生成的可执行文件是完全独立的，不依赖于外部库。
2025-02-14 02:52:40
351
原创 库制作与原理（中篇：ELF）
其实我们不需要害怕，我们用到的ELF格式就是一个大文件，比如说这个文件一共是10兆，这个可执行程序10兆的话，所谓的section1，section2，...，sectionN，他本质上只需要告诉我，我这个sectionM相比较于整个文件的开头，我的偏移量大概在什么位置，再加上我的高度，那么此时，我们就能够在文件部分用起始的偏移量+sectionM的长度，就能够将一个section表示出来。是操作系统加载程序时的概念，代表了执行视角下程序在内存中的不同区域，如可执行代码段、可读写数据段、只读数据段等。
2025-02-12 20:22:13
1036
原创 库制作与原理（上篇：动静态库）
库的本质库是一种将现有成熟代码进行复用的方式，避免重复编写相同的代码。通过库，可以将常用的函数或功能封装起来，供多个程序使用。例子在C语言中，标准库提供了许多常用的函数，如printf。如果标准库不提供这些函数，每个程序员都需要自己实现，这会导致代码质量参差不齐。通过将常用的函数（如printf）抽取出来，由顶级程序员实现并打包成库，程序员只需调用库函数即可，无需关心函数的具体实现。现实生活中的类比使用手机时，用户不需要关心手机的生产过程，只需要购买和使用即可。
2025-02-11 23:29:14
961
原创 Ext系列文件系统（下）
这些图描述了在Linux操作系统中，文件从进程打开到挂载在文件系统上的整个流程。首先，每个进程（如进程A和进程B）都有一个结构，其中包含一个结构，用于跟踪该进程打开的所有文件。每个打开的文件由file结构表示，该结构包含文件描述符、文件状态信息以及指向inode和dentry的指针。inode结构代表硬盘文件系统上的索引节点，包含文件的元数据，如权限、所有者、大小和时间戳等。dentry（目录项）结构代表文件系统中的文件名和它对应的inode的关联。dentry通过其d_inode字段与inode关联。
2025-02-10 18:27:55
795
原创 Ext系列文件系统（上）
我们之前说过，文件=内容+属性，这是我们从一个文件得视角去谈的，而系统当中存在成百上千的文件，在系统层面上，文件也就被打开了一小部分，操作是将那么多的文件是进行怎么样的管理呢？更重要的是，我们之前fopen()打开文件的时候，为什么我们的系统就能够准确的把我们想要打开的文件打开，并且可以在系统层面上将文件信息加载到内存？怎么可以做到如此精准？被打开的文件是在内存当中的，因为操作系统要管理他，如果文件没有被打开呢？他在哪里呢？答案是在磁盘上！
2025-02-09 16:45:35
890
原创 基础IO-缓冲区
我们生活中有许多“缓冲区”的，就好比我们学校的菜鸟驿站，别人给你寄快递的时候，你当前可能在宿舍打游戏，你来不及处理这个数据，也就是这个包裹，所以快递员就把你的快递放在了楼下对应的菜鸟驿站里，给你缓存起来，将来要取快递的时候就去底层缓存区去取.你（用户）：不用停下手头的事情，继续打游戏。快递员（OS）：不需要等任何人，只要将包裹送到菜鸟驿站。菜鸟驿站（内核文件缓冲区）：临时存储包裹，直到收件人有空来取。作为一个中间存储点，缓解了快递员和收件人之间的时间不匹配问题。这种机制最大的体现就是提高了效率！！
2025-02-07 11:14:24
874
原创 基础IO-首篇补充
原因是因为，我们今天在进行对应的输出的时候，虽然我们的标准输出和标准错误都指向同一个文件，但是当我们进行对应的重定向时，他的本质是把文件描述符1重定向到新文件log.txt，即把新打开的文件描述符对应内容的的地址拷贝到了1里面，这时候1指向的内容就是log.txt，可是2依旧指向标准错误，在重定向时，这也是我们后面要谈到的，其实struct file是我们操作系统内打开的文件，但是我们文件相关的一些硬属性，相关属性并没有在该file结构体当中存储，而是在另一个数据结构，这个数据结构称为。
2025-02-06 17:38:28
637
包含了多个关于C++编程概念和特性的图像文件，具体内容涵盖了排序算法、内存管理、迭代器使用、拷贝构造函数等多个方面，会更新，放心
2024-08-23
STL中string，vector，list，queue，stack....等原码
2024-08-23
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人