HTTP/2
分为两部分 : 理论知识 和 nghttp2库使用 理论知识可以理解为在HTTP/1.1上做了很多精简优化的工作, 解决了很多冗余的部分, 实现了精细地控制. 提升了加载速度, 减少了连接资源的浪费, 避免的频繁的队头阻塞. 整体理解 依旧使用TCP进行数据传递, 但是一组请求响应不再会长时间占用整个TCP连接, 并且不同的请求都将始终在一条TCP连接上实现. 流机制和帧机制实现了上
HTTP/1
HTTP/1.0短连接(非持久性连接) 每次HTTP请求都要创建一个新的TCP连接, 响应完就关闭连接. HTTP/1.1长连接, 使用最广泛的HTTP协议 keep-alive : 持久连接Connection: keep-alive : 表示复用已有的TCP连接连续发送多个请求, 不断开当前的TCP连接. Connection: close : 表示想确实关闭连接. 分块
Linux多线程服务端编程 读书笔记3
工程实践经验谈 分布式系统 分布式系统不是放大了的单机系统, 根本原因在于单机没有部分故障. 单机与分布式的根本区别在于进程地址空间是一个还是多个. 负载均衡一般的解决方案是 : 通过某个集中的负载均衡器来收集并分发负载情况, 可以把消息数目降到M + N(M台web服务器, N台服务提供服务器). 但是这种方式会引发单点故障(Single Point of Failure), 最简单的
Linux多线程服务端编程 读书笔记2
第二部分 Muduo网络库 文件传输 如何完整高效地传输一个文件? 文件传输过程一般如下 : 磁盘 -> 内核页缓冲 -> 用户缓冲区 -> Tcp发送缓冲区 -> 网卡等 最简单的传输方式当然就是fread + send 一口气传出, 但是这样如果文件非常大的话, 服务器扛不住几个连接, 因为这样的内存消耗非常大. 书中提出了一种解决内存占用过多的方法 :
Linux多线程服务端编程 读书笔记1
第一部分 C++多线程系统编程 析构所在的线程当share_ptr引用计数归零时, 会在归零的这个线程就地析构, 而这个线程不一定是对象诞生的线程. 这就引发出一个问题 : 如果对象的析构比较耗时, 且经常在关键线程触发析构, 就会拖慢关键线程的速度. 这种情况的解决方案是专门做一个阻塞队列存入要析构的智能指针, 另开一个专门析构的线程从队列中取出进行析构. 多线程适用场景 其核心作用在
libuv事件库
回显服务器先实现一个最简的Tcp回显服务器 : 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192
boost::asio网络库
主要学习asio网络库有关异步方面的使用 这里先给出一个最简便的TCP异步echo服务器 : 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879
C++ 协程学习笔记
协程是可以理解为一个可以被暂停(挂起)和唤醒的函数, 系统会帮助你保存协程函数中的局部变量. 协程 vs 线程协程和线程几乎没有任何联系, 它们是相互独立的. 对于执行时间比较短的任务, 不建议用线程来处理, 线程的创建, 调度, 销毁都是会占用资源的. 线程适合那些长时间的任务, 比如轮循或监控. 线程是一个实际的需要操作系统进行调度的对象, 而协程只是函数外加一些在底层跳来跳去的指令.