[TOC]
| 分层 | 作用 | 协议 |
|---|---|---|
| 物理层 | 通过媒介传输比特，确定机械及电气规范（比特 Bit） | RJ45、CLOCK、IEEE802.3（中继器，集线器） |
| 数据链路层 | 将比特组装成帧和点到点的传递（帧 Frame） | PPP、FR、HDLC、VLAN、MAC（网桥，交换机） |
| 网络层 | 负责数据包从源到宿的传递和网际互连（包 Packet） | IP、ICMP、ARP、RARP、OSPF、IPX、RIP、IGRP（路由器） |
| 运输层 | 提供端到端的可靠报文传递和错误恢复（ 段Segment） | TCP、UDP、SPX |
| 会话层 | 建立、管理和终止会话（会话协议数据单元 SPDU） | NFS、SQL、NETBIOS、RPC |
| 表示层 | 对数据进行翻译、加密和压缩（表示协议数据单元 PPDU） | JPEG、MPEG、ASII |
| 应用层 | 允许访问OSI环境的手段（应用协议数据单元 APDU） | FTP、DNS、Telnet、SMTP、HTTP、WWW、NFS |
**TCP（Transmission Control Protocol，传输控制协议）**是一种面向连接的、可靠的、基于字节流的传输层通信协议，其传输的单位是报文段。
TCP 如何保证可靠传输
- 确认和超时重传
- 数据合理分片和排序
- 流量控制
- 拥塞控制
- 数据校验
TCP 报文结构
[
TCP 状态控制码（Code，Control Flag），占 6 比特，含义如下：
- URG：紧急比特（urgent），当
URG＝1时，表明紧急指针字段有效，代表该封包为紧急封包。它告诉系统此报文段中有紧急数据，应尽快传送(相当于高优先级的数据)， 且上图中的 Urgent Pointer 字段也会被启用。 - ACK：确认比特（Acknowledge）。只有当
ACK＝1时确认号字段才有效，代表这个封包为确认封包。当ACK＝0时，确认号无效。 - PSH：（Push function）若为 1 时，代表要求对方立即传送缓冲区内的其他对应封包，而无需等缓冲满了才送。
- RST：复位比特(Reset)，当
RST＝1时，表明 TCP 连接中出现严重差错（如由于主机崩溃或其他原因），必须释放连接，然后再重新建立运输连接。 - SYN：同步比特(Synchronous)，SYN 置为 1，就表示这是一个连接请求或连接接受报文，通常带有 SYN 标志的封包表示『主动』要连接到对方的意思。
- FIN：终止比特(Final)，用来释放一个连接。当
FIN＝1时，表明此报文段的发送端的数据已发送完毕，并要求释放运输连接。
**UDP（User Datagram Protocol，用户数据报协议）**是 OSI 模型中一种无连接的传输层协议，提供面向事务的简单不可靠信息传送服务，其传输的单位是用户数据报。
- TCP 面向连接，UDP 是无连接的；
- TCP 提供可靠的服务，也就是说，通过 TCP 连接传送的数据，无差错，不丢失，不重复，且按序到达；UDP 尽最大努力交付，即不保证可靠交付
- TCP 的逻辑通信信道是全双工的可靠信道；UDP 则是不可靠信道
- 每一条 TCP 连接只能是点到点的；UDP 支持一对一，一对多，多对一和多对多的交互通信
- TCP 面向字节流（可能出现黏包问题），实际上是 TCP 把数据看成一连串无结构的字节流；UDP 是面向报文的（不会出现黏包问题）
- UDP 没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如 IP 电话，实时视频会议等）
- TCP 首部开销20字节；UDP 的首部开销小，只有 8 个字节
为什么不是两次？
根本原因: 无法确认客户端的接收能力。
如果是两次，你现在发了 SYN 报文想握手，但是这个包 滞留 在了当前的网络中迟迟没有到达，TCP 以为这是丢了包，于是重传，两次握手建立好了连接。看似没有问题，但是连接关闭后，如果这个 滞留 在网路中的包到达了服务端呢？这时候由于是两次握手，服务端只要接收到然后发送相应的数据包，就默认 建立连接，但是现在客户端已经断开了。看到问题的吧，这就带来了连接资源的浪费。
三次握手过程中可以携带数据么？
第三次握手的时候，可以携带。前两次握手不能携带数据。
如果前两次握手能够携带数据，那么一旦有人想攻击服务器，那么他只需要在第一次握手中的 SYN 报文中放大量数据，那么服务器势必会消耗更多的 时间和 **内存空间 **去处理这些数据，增大了服务器被攻击的风险。第三次握手的时候，客户端已经处于 ESTABLISHED状态，并且已经能够确认服务器的接收、发送能力正常，这个时候相对安全了，可以携带数据。
-
刚开始双方处于
ESTABLISHED状态。客户端要断开了，向服务器发送FIN报文。 -
发送后客户端变成了
FIN-WAIT-1状态。注意, 这时候客户端同时也变成了half-close(半关闭)状态，即无法向服务端发送报文，只能接收。服务端接收后向客户端确认，变成了CLOSED-WAIT状态。客户端接收到了服务端的确认，变成了FIN-WAIT2状态。 -
随后，服务端向客户端发送
FIN，自己进入LAST-ACK状态，客户端收到服务端发来的FIN后，自己变成了TIME-WAIT状态，然后发送 ACK 给服务端。注意了，这个时候，客户端需要等待足够长的时间，具体来说，是 2 个MSL(Maximum Segment Lifetime，报文最大生存时间), 在这段时间内如果客户端没有收到服务端的重发请求，那么表示 ACK 成功到达，挥手结束，否则客户端重发 ACK。
等待2MSL的意义
如果不等待会怎样？如果不等待，客户端直接跑路，当服务端还有很多数据包要给客户端发，且还在路上的时候，若客户端的端口此时刚好被新的应用占用，那么就接收到了无用数据包，造成数据包混乱。所以，最保险的做法是等服务器发来的数据包都死翘翘再启动新的应用。那，照这样说一个 MSL 不就不够了吗，为什么要等待 2 MSL?
- 1 个 MSL 确保四次挥手中主动关闭方最后的 ACK 报文最终能达到对端
- 1 个 MSL 确保对端没有收到 ACK 重传的 FIN 报文可以到达
对于发送端和接收端而言，TCP 需要把发送的数据放到 发送缓存区, 将接收的数据放到 接收缓存区。而流量控制索要做的事情，就是在通过接收缓存区的大小，控制发送端的发送。如果对方的接收缓存区满了，就不能再继续发送了。
发送窗口
发送端的滑动窗口结构如下:
接收窗口
接收端的窗口结构如下:
REV 即 receive，NXT 表示下一个接收的位置，WND 表示接收窗口大小。
流量控制过程
这里以一个最简单的来回来模拟一下流量控制的过程。
首先双方三次握手，初始化各自的窗口大小，均为 200 个字节。假如当前发送端给接收端发送 100 个字节，那么此时对于发送端而言，SND.NXT 当然要右移 100 个字节，也就是说当前的 可用窗口减少了 100 个字节，这很好理解。
现在这 100 个到达了接收端，被放到接收端的缓冲队列中。不过此时由于大量负载的原因，接收端处理不了这么多字节，只能处理 40 个字节，剩下的 60 个字节被留在了缓冲队列中
注意了，此时接收端的情况是处理能力不够用啦，你发送端给我少发点，所以此时接收端的接收窗口应该缩小，具体来说，缩小 60 个字节，由 200 个字节变成了 140 字节，因为缓冲队列还有 60 个字节没被应用拿走。因此，接收端会在 ACK 的报文首部带上缩小后的滑动窗口 140 字节，发送端对应地调整发送窗口的大小为 140 个字节。
此时对于发送端而言，已经发送且确认的部分增加 40 字节，也就是 SND.UNA 右移 40 个字节，同时 发送窗口缩小为 140 个字节。这也就是 流量控制的过程。尽管回合再多，整个控制的过程和原理是一样的。
流量控制 发生在发送端跟接收端之间，并没有考虑到整个网络环境的影响。
如果说当前网络特别差，特别容易丢包，那么发送端就应该注意一些了。而这，也正是 拥塞控制需要处理的问题。对于拥塞控制来说，TCP 每条连接都需要维护两个核心状态:
- 拥塞窗口（Congestion Window，cwnd）
- 慢启动阈值（Slow Start Threshold，ssthresh）
拥塞窗口
拥塞窗口（Congestion Window，cwnd）是指目前自己还能传输的数据量大小。那么之前介绍了接收窗口的概念，两者有什么区别呢？
- 接收窗口(rwnd)是
接收端给的限制 - 拥塞窗口(cwnd)是
发送端的限制
限制谁呢？限制的是 发送窗口的大小。有了这两个窗口，如何来计算 发送窗口？
发送窗口大小 = min(rwnd, cwnd)
取两者的较小值。而拥塞控制，就是来控制 cwnd的变化。
慢启动
刚开始进入传输数据的时候，你是不知道现在的网路到底是稳定还是拥堵的，如果做的太激进，发包太急，那么疯狂丢包，造成雪崩式的网络灾难。因此，拥塞控制首先就是要采用一种保守的算法来慢慢地适应整个网路，这种算法叫 慢启动。运作过程如下:
- 首先，三次握手，双方宣告自己的接收窗口大小
- 双方初始化自己的 拥塞窗口(cwnd)大小
- 在开始传输的一段时间，发送端每收到一个 ACK，拥塞窗口大小加 1，也就是说，每经过一个 RTT，cwnd 翻倍。如果说初始窗口为 10，那么第一轮 10 个报文传完且发送端收到 ACK 后，cwnd 变为 20，第二轮变为 40，第三轮变为 80，依次类推。
难道就这么无止境地翻倍下去？当然不可能。它的阈值叫做 慢启动阈值，当 cwnd 到达这个阈值之后，好比踩了下刹车，别涨了那么快了，老铁，先 hold 住！在到达阈值后，如何来控制 cwnd 的大小呢？这就是拥塞避免做的事情了。
拥塞避免
原来每收到一个 ACK，cwnd 加1，现在到达阈值了，cwnd 只能加这么一点: 1 / cwnd。那你仔细算算，一轮 RTT 下来，收到 cwnd 个 ACK, 那最后拥塞窗口的大小 cwnd 总共才增加 1。也就是说，以前一个 RTT 下来， cwnd翻倍，现在 cwnd只是增加 1 而已。当然， 慢启动和 拥塞避免是一起作用的，是一体的。
快速重传
在 TCP 传输的过程中，如果发生了丢包，即接收端发现数据段不是按序到达的时候，接收端的处理是重复发送之前的 ACK。比如第 5 个包丢了，即使第 6、7 个包到达的接收端，接收端也一律返回第 4 个包的 ACK。
当发送端收到 3 个重复的 ACK 时，意识到丢包了，于是马上进行重传，不用等到一个 RTO 的时间到了才重传。这就是 快速重传，它解决的是 是否需要重传的问题。
选择性重传
那你可能会问了，既然要重传，那么只重传第 5 个包还是第5、6、7 个包都重传呢？当然第 6、7 个都已经到达了，TCP 的设计者也不傻，已经传过去干嘛还要传？干脆记录一下哪些包到了，哪些没到，针对性地重传。
在收到发送端的报文后，接收端回复一个 ACK 报文，那么在这个报文首部的可选项中，就可以加上 SACK这个属性，通过 left edge和 right edge告知发送端已经收到了哪些区间的数据报。因此，即使第 5 个包丢包了，当收到第 6、7 个包之后，接收端依然会告诉发送端，这两个包到了。
剩下第 5 个包没到，就重传这个包。这个过程也叫做 选择性重传(SACK，Selective Acknowledgment)，它解决的是 如何重传的问题。
快速恢复
当然，发送端收到三次重复 ACK 之后，发现丢包，觉得现在的网络已经有些拥塞了，自己会进入 快速恢复 阶段。在这个阶段，发送端如下改变：
- 拥塞阈值降低为 cwnd 的一半
- cwnd 的大小变为拥塞阈值
- cwnd 线性增加
TCP 是一个基于字节流的传输服务（UDP 基于报文的），“流” 意味着 TCP 所传输的数据是没有边界的。所以可能会出现两个数据包黏在一起的情况。
解决方案
- 发送定长包。如果每个消息的大小都是一样的，那么在接收对等方只要累计接收数据，直到数据等于一个定长的数值就将它作为一个消息。
- 包头加上包体长度。包头是定长的 4 个字节，说明了包体的长度。接收对等方先接收包头长度，依据包头长度来接收包体。
- 在数据包之间设置边界，如添加特殊符号
\r\n标记。FTP 协议正是这么做的。但问题在于如果数据正文中也含有\r\n，则会误判为消息的边界。 - 使用更加复杂的应用层协议。
TCP 层面也是有 keep-alive机制。当有一方因为网络故障或者宕机导致连接失效，由于 TCP 并不是一个轮询的协议，在下一个数据包到达之前，对端对连接失效的情况是一无所知的。这个时候就出现了 keep-alive, 它的作用就是探测对端的连接有没有失效。
三次握手前，服务端的状态从 CLOSED变为 LISTEN, 同时在内部创建了两个队列： 半连接队列和 全连接队列。
-
当客户端发送
SYN到服务端，服务端收到以后回复ACK和SYN，状态由LISTEN变为SYN_RCVD，此时这个连接就被推入了 SYN队列，也就是 半连接队列。 -
当客户端返回
ACK, 服务端接收后，三次握手完成。这个时候连接等待被具体的应用取走，在被取走之前，它会被推入另外一个 TCP 维护的队列，也就是 全连接队列(Accept Queue)。
SYN Flood 攻击原理
SYN Flood 属于典型的 DoS/DDoS 攻击。其攻击的原理很简单，就是用客户端在短时间内伪造大量不存在的 IP 地址，并向服务端疯狂发送 SYN。对于服务端而言，会产生两个危险的后果:
- 处理大量的
SYN包并返回对应ACK, 势必有大量连接处于SYN_RCVD状态，从而占满整个半连接队列，无法处理正常的请求。 - 由于是不存在的 IP，服务端长时间收不到客户端的
ACK，会导致服务端不断重发数据，直到耗尽服务端的资源。
如何应对 SYN Flood 攻击？
- 增加 SYN 连接，也就是增加半连接队列的容量。
- 减少 SYN + ACK 重试次数，避免大量的超时重发。
- 利用 SYN Cookie 技术，在服务端接收到
SYN后不立即分配连接资源，而是根据这个SYN计算出一个Cookie，连同第二次握手回复给客户端，在客户端回复ACK的时候带上这个Cookie值，服务端验证 Cookie 合法之后才分配连接资源。
概念与产生
HTTP（HyperText Transfer Protocol，超文本传输协议）是一种用于分布式、协作式和超媒体信息系统的应用层协议。HTTP 是万维网的数据通信的基础。
早在 HTTP 建立之初，主要就是为了将超文本标记语言(HTML)文档从Web服务器传送到客户端的浏览器。也是说对于前端来说，我们所写的HTML页面将要放在我们的 web 服务器上，用户端通过浏览器访问url地址来获取网页的显示内容，但是到了 WEB2.0 以来，我们的页面变得复杂，不仅仅单纯的是一些简单的文字和图片，同时我们的 HTML 页面有了 CSS，Javascript，来丰富我们的页面展示，当 ajax 的出现，我们又多了一种向服务器端获取数据的方法，这些其实都是基于HTTP 协议的。
请求方法
| 方法 | 意义 |
|---|---|
| OPTIONS | 请求一些选项信息，允许客户端查看服务器的性能 |
| GET | 请求指定的页面信息，并返回实体主体 |
| HEAD | 类似于 get 请求，只不过返回的响应中没有具体的内容，用于获取报头 |
| POST | 向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改 |
| PUT | 从客户端向服务器传送的数据取代指定的文档的内容 |
| DELETE | 请求服务器删除指定的页面 |
| TRACE | 回显服务器收到的请求，主要用于测试或诊断 |
状态码（Status-Code）
- 1xx：表示通知信息，如请求收到了或正在进行处理
- 100 Continue：继续，客户端应继续其请求
- 101 Switching Protocols 切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议，例如，切换到 HTTP 的新版本协议
- 2xx：表示成功，如接收或知道了
- 200 OK: 请求成功
- 3xx：表示重定向，如要完成请求还必须采取进一步的行动
- 301 Moved Permanently: 永久移动。请求的资源已被永久的移动到新 URL，返回信息会包括新的 URL，浏览器会自动定向到新 URL。今后任何新的请求都应使用新的 URL 代替
- 4xx：表示客户的差错，如请求中有错误的语法或不能完成
- 400 Bad Request: 客户端请求的语法错误，服务器无法理解
- 401 Unauthorized: 请求要求用户的身份认证
- 403 Forbidden: 服务器理解请求客户端的请求，但是拒绝执行此请求（权限不够）
- 404 Not Found: 服务器无法根据客户端的请求找到资源（网页）。通过此代码，网站设计人员可设置 “您所请求的资源无法找到” 的个性页面
- 408 Request Timeout: 服务器等待客户端发送的请求时间过长，超时
- 5xx：表示服务器的差错，如服务器失效无法完成请求
- 500 Internal Server Error: 服务器内部错误，无法完成请求
- 503 Service Unavailable: 由于超载或系统维护，服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的 Retry-After 头信息中
- 504 Gateway Timeout: 充当网关或代理的服务器，未及时从远端服务器获取请求
影响一个 HTTP 网络请求的因素主要有两个：带宽和延迟。
-
**带宽：**如果说我们还停留在拨号上网的阶段，带宽可能会成为一个比较严重影响请求的问题，但是现在网络基础建设已经使得带宽得到极大的提升，我们不再会担心由带宽而影响网速，那么就只剩下延迟了。
-
延迟：
-
- 浏览器阻塞（HOL blocking）：浏览器会因为一些原因阻塞请求。浏览器对于同一个域名，同时只能有 4 个连接（这个根据浏览器内核不同可能会有所差异），超过浏览器最大连接数限制，后续请求就会被阻塞。
- DNS 查询（DNS Lookup）：浏览器需要知道目标服务器的 IP 才能建立连接。将域名解析为 IP 的这个系统就是 DNS。这个通常可以利用DNS缓存结果来达到减少这个时间的目的。
- 建立连接（Initial connection）：HTTP 是基于 TCP 协议的，浏览器最快也要在第三次握手时才能捎带 HTTP 请求报文，达到真正的建立连接，但是这些连接无法复用会导致每次请求都经历三次握手和慢启动。三次握手在高延迟的场景下影响较明显，慢启动则对文件类大请求影响较大。
HTTP1.0最早在网页中使用是在1996年，那个时候只是使用一些较为简单的网页上和网络请求上，而HTTP1.1则在1999年才开始广泛应用于现在的各大浏览器网络请求中，同时HTTP1.1也是当前使用最为广泛的HTTP协议。 主要区别主要体现在：
- 缓存处理，在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。
- 带宽优化及网络连接的使用，HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。
- 错误通知的管理，在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。
- Host头处理，在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。
- 长连接，HTTP 1.1支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟，在HTTP1.1中默认开启Connection： keep-alive，一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。
HTTP 协议以明文方式发送内容，不提供任何方式的数据加密，不验证身份，导致身份可能被伪装 ，也不会验证数据的前后一致性，如果攻击者截取了Web浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息，因此，HTTP协议不适合传输一些敏感信息，比如：信用卡号、密码等支付信息。
HTTPS（Hypertext Transfer Protocol Secure：超文本传输安全协议）是一种透过计算机网络进行安全通信的传输协议。HTTPS 经由 HTTP 进行通信，但利用 SSL/TLS 来加密数据包。HTTPS 开发的主要目的，是提供对网站服务器的身份认证，保护交换数据的隐私与完整性。
- HTTP 明文传输，数据都是未加密的，安全性较差，HTTPS（SSL+HTTP） 数据传输过程是加密的，安全性较好。
- 使用 HTTPS 协议需要到 CA（Certificate Authority，数字证书认证机构） 申请证书，一般免费证书较少，因而需要一定费用。证书颁发机构如：Symantec、Comodo、GoDaddy 和 GlobalSign 等。
- HTTP 页面响应速度比 HTTPS 快，主要是因为 HTTP 使用 TCP 三次握手建立连接，客户端和服务器需要交换 3 个包，而 HTTPS除了 TCP 的三个包，还要加上 SSL 握手需要的 9 个包，所以一共是 12 个包。
- http 和 https 使用的是完全不同的连接方式，用的端口也不一样，前者是 80，后者是 443。
- HTTPS 其实就是建构在 SSL/TLS 之上的 HTTP 协议，所以，要比较 HTTPS 比 HTTP 要更耗费服务器资源。
ssize_t read(int fd, void *buf, size_t count);
ssize_t write(int fd, const void *buf, size_t count);
read()
- read 函数是负责从 fd 中读取内容。
- 当读成功时，read 返回实际所读的字节数。
- 如果返回的值是 0 表示已经读到文件的结束了，小于 0 表示出现了错误。
- 如果错误为 EINTR 说明读是由中断引起的；如果是 ECONNREST 表示网络连接出了问题。
write()
- write 函数将 buf 中的 nbytes 字节内容写入文件描述符 fd。
- 成功时返回写的字节数。失败时返回 -1，并设置 errno 变量。
- 在网络程序中，当我们向套接字文件描述符写时有俩种可能。
- （1）write 的返回值大于 0，表示写了部分或者是全部的数据。
- （2）返回的值小于 0，此时出现了错误。
- 如果错误为 EINTR 表示在写的时候出现了中断错误；如果为 EPIPE 表示网络连接出现了问题（对方已经关闭了连接）。
我们知道 TCP 建立连接要进行 “三次握手”，即交换三个分组。大致流程如下：
- 客户端向服务器发送一个 SYN J
- 服务器向客户端响应一个 SYN K，并对 SYN J 进行确认 ACK J+1
- 客户端再想服务器发一个确认 ACK K+1
只有就完了三次握手，但是这个三次握手发生在 Socket 的那几个函数中呢？请看下图：
从图中可以看出：
- 当客户端调用 connect 时，触发了连接请求，向服务器发送了 SYN J 包，这时 connect 进入阻塞状态；
- 服务器监听到连接请求，即收到 SYN J 包，调用 accept 函数接收请求向客户端发送 SYN K ，ACK J+1，这时 accept 进入阻塞状态；
- 客户端收到服务器的 SYN K ，ACK J+1 之后，这时 connect 返回，并对 SYN K 进行确认；
- 服务器收到 ACK K+1 时，accept 返回，至此三次握手完毕，连接建立。
上面介绍了 socket 中 TCP 的三次握手建立过程，及其涉及的 socket 函数。现在我们介绍 socket 中的四次握手释放连接的过程，请看下图：
图示过程如下：
- 某个应用进程首先调用 close 主动关闭连接，这时 TCP 发送一个 FIN M；
- 另一端接收到 FIN M 之后，执行被动关闭，对这个 FIN 进行确认。它的接收也作为文件结束符传递给应用进程，因为 FIN 的接收意味着应用进程在相应的连接上再也接收不到额外数据；
- 一段时间之后，接收到文件结束符的应用进程调用 close 关闭它的 socket。这导致它的 TCP 也发送一个 FIN N；
- 接收到这个 FIN 的源发送端 TCP 对它进行确认。
这样每个方向上都有一个 FIN 和 ACK。
-
首先浏览器做的第一步工作就是要对
URL进行解析，从而生发送给Web服务器的请求信息。对
URL进行解析之后，浏览器确定了 Web 服务器和文件名，接下来就是根据这些信息来生成 HTTP 请求消息了。 -
通过访问的域名找出其IP地址。DNS查找过程如下：
- 浏览器缓存 – 浏览器会缓存DNS记录一段时间。 有趣的是，操作系统没有告诉浏览器储存DNS记录的时间，这样不同浏览器会储存个自固定的一个时间（2分钟到30分钟不等）。
- 系统缓存 – 如果在浏览器缓存里没有找到需要的记录，浏览器会做一个系统调用（windows里是gethostbyname）。这样便可获得系统缓存中的记录。
- 路由器缓存 – 接着，前面的查询请求发向路由器，它一般会有自己的DNS缓存。
- ISP DNS 缓存 – 接下来要check的就是ISP缓存DNS的服务器。在这一般都能找到相应的缓存记录。
- 递归搜索 – 你的ISP的DNS服务器从跟域名服务器开始进行递归搜索，从.com顶级域名服务器到Facebook的域名服务器。一般DNS服务器的缓存中会有.com域名服务器中的域名，所以到顶级服务器的匹配过程不是那么必要了
-
通过 DNS 获取到 IP 后，就可以把 HTTP 的传输工作交给操作系统中的协议栈。应用程序（浏览器）通过调用 Socket 库，来委托协议栈工作。
协议栈的上半部分有两块，分别是负责收发数据的 TCP 和 UDP 协议，它们两会接受应用层的委托执行收发数据的操作。
协议栈的下面一半是用 IP 协议控制网络包收发操作，在互联网上传数据时，数据块被切分成一块块的网络包，而将网络包发送给对方的操作就是由 IP 负责的。
此外 IP 中还包括
ICMP协议和ARP协议。ICMP用于告知网络包传送过程中产生的错误以及各种控制信息。ARP用于根据 IP 地址查询相应的以太网 MAC 地址。
IP 下面的网卡驱动程序负责控制网卡硬件，而最下面的网卡则负责完成实际的收发操作，也就是对网线中的信号执行发送和接收操作。
-
IP 生成的网络包只是存放在内存中的一串二进制数字信息，没有办法直接发送给对方。因此，我们需要将数字信息转换为电信号，才能在网线上传输，也就是说，这才是真正的数据发送过程。负责执行这一操作的是网卡，要控制网卡还需要靠网卡驱动程序。
网卡驱动从 IP 模块获取到包之后，会将其复制到网卡内的缓存区中，接着会其开头加上报头和起始帧分界符，在末尾加上用于检测错误的帧校验序列。最后网卡会将包转为电信号，通过网线发送出去。
Both threads and processes are really just one thing: a "context of execution" from Linus
进程之间私有和共享的资源
- 私有：地址空间、堆、全局变量、栈、寄存器
- 共享：代码段，公共数据，进程目录，进程 ID
线程之间私有和共享的资源
- 私有：线程栈，寄存器，程序计数器
- 共享：堆，地址空间，全局变量，静态变量
对于有线程系统：
- 进程是资源分配的独立单位
- 线程是资源调度的独立单位
对于无线程系统：
- 进程是资源调度、分配的独立单位
进程的活动是通过在CPU上执行一系列程序和对数据进行相应操作的完成来体现的，因此程序和数据是组成进程的实体，为了反映进程的动态特征，需要一个数据结构来描述进程本身的特性状态，调度信息以及对资源的占有等等。这个数据结构我们称之为进程控制块（PCB），PCB由链表实现（为了动态插入和删除）
PCB的内容
- 进程的描述信息，比如进程的名称，标识符
- 处理机的状态信息，当程序中断是保留此时的信息，以便CPU返回时能从断点执行
- 进程调度信息，比如阻塞原因，状态，优先级等等
- 进程控制和资源占用，同步通信机制，链接指针（指向队列中下一个进程的PCB地址）
PCB的作用
- PCB是进程实体的一部分，是操作系统中最重要的数据结构
- 由于它的存在，使得多道程序环境下，不能独立运行的程序成为一个能独立运行的基本单位，使得程序可以并发执行
- 系统通过PCB来感知进程的存在。（换句话说，PCB是进程存在的唯一标识）
- PCB应该常驻内存
进程是由程序段，数据段和PCB构成的，然而创建进程的时候未必会创建程序段和数据段，但一定会创建PCB
这取决于具体实现，如果只谈fork/exec，那么「创建进程」这一步是在fork()中完成的。
-
一个平凡的
fork()实现会在「创建PCB」的同时创建一个新的地址空间——它包含了空的「数据段」和「程序段」，然后在exec()中填充「程序段」。 -
但如果你实现了「Copy-On-Write」，那么在
fork()的时候只会创建新的PCB而不会创建新的地址空间，这一过程被延后到了exec()中，新进程在exec()之前和父进程共用相同的「程序段」和「数据段」
具体创建步骤
- 首先在内存中为新进程创建一个
task_struct结构，然后将父进程的task_struct内容复制其中，再修改部分数据。 - 分配新的内核堆栈、新的PID、再将
task_struct这个node添加到链表中。 - 所谓创建，实际上是“复制”。子进程刚开始，内核并没有为它分配物理内存，而是以只读的方式共享父进程内存，只有当子进程写时，才复制。即“copy-on-write”。
- 管道（PIPE）
- 命名管道：一种半双工的通信方式，它允许无亲缘关系进程间的通信
- 优点：可以实现任意关系的进程间的通信
- 缺点：
- 长期存于系统中，使用不当容易出错
- 缓冲区有限
- 无名管道：一种半双工的通信方式，只能在具有亲缘关系的进程间使用（父子进程）
- 优点：简单方便
- 缺点：
- 局限于单向通信
- 只能创建在它的进程以及其有亲缘关系的进程之间
- 缓冲区有限
- 命名管道：一种半双工的通信方式，它允许无亲缘关系进程间的通信
- 信号量（Semaphore）：一个计数器，可以用来控制多个线程对共享资源的访问
- 优点：可以同步进程
- 缺点：信号量有限
- 信号（Signal）：一种比较复杂的通信方式，用于通知接收进程某个事件已经发生
- 消息队列（Message Queue）：是消息的链表，存放在内核中并由消息队列标识符标识
- 优点：可以实现任意进程间的通信，并通过系统调用函数来实现消息发送和接收之间的同步，无需考虑同步问题，方便
- 缺点：信息的复制需要额外消耗 CPU 的时间，不适宜于信息量大或操作频繁的场合
- 共享内存（Shared Memory）：映射一段能被其他进程所访问的内存，这段共享内存由一个进程创建，但多个进程都可以访问
- 优点：无须复制，快捷，信息量大
- 缺点：
- 通信是通过将共享空间缓冲区直接附加到进程的虚拟地址空间中来实现的，因此进程间的读写操作的同步问题
- 利用内存缓冲区直接交换信息，内存的实体存在于计算机中，只能同一个计算机系统中的诸多进程共享，不方便网络通信
- 套接字（Socket）：可用于不同计算机间的进程通信
- 优点：
- 传输数据为字节级，传输数据可自定义，数据量小效率高
- 传输数据时间短，性能高
- 适合于客户端和服务器端之间信息实时交互
- 可以加密,数据安全性强
- 缺点：需对传输的数据进行解析，转化成应用级的数据。
- 优点：
- 锁机制：包括互斥锁/量（mutex）、读写锁（reader-writer lock）、自旋锁（spin lock）、条件变量（condition）
- 互斥锁/量（mutex）：提供了以排他方式防止数据结构被并发修改的方法。
- 读写锁（reader-writer lock）：允许多个线程同时读共享数据，而对写操作是互斥的。
- 自旋锁（spin lock）与互斥锁类似，都是为了保护共享资源。互斥锁是当资源被占用，申请者进入睡眠状态；而自旋锁则循环检测保持者是否已经释放锁。
- 条件变量（condition）：可以以原子的方式阻塞进程，直到某个特定条件为真为止。对条件的测试是在互斥锁的保护下进行的。条件变量始终与互斥锁一起使用。
- 信号量机制(Semaphore)
- 无名线程信号量
- 命名线程信号量
- 信号机制(Signal)：类似进程间的信号处理
线程间的通信目的主要是用于线程同步，所以线程没有像进程通信中的用于数据交换的通信机制
| 对比维度 | 多进程 | 多线程 | 总结 |
|---|---|---|---|
| 数据共享、同步 | 数据共享复杂，需要用 IPC；数据是分开的，同步简单 | 因为共享进程数据，数据共享简单，但也是因为这个原因导致同步复杂 | 各有优势 |
| 内存、CPU | 占用内存多，切换复杂，CPU 利用率低 | 占用内存少，切换简单，CPU 利用率高 | 线程占优 |
| 创建销毁、切换 | 创建销毁、切换复杂，速度慢 | 创建销毁、切换简单，速度很快 | 线程占优 |
| 编程、调试 | 编程简单，调试简单 | 编程复杂，调试复杂 | 进程占优 |
| 可靠性 | 进程间不会互相影响 | 一个线程挂掉将导致整个进程挂掉 | 进程占优 |
| 分布式 | 适应于多核、多机分布式；如果一台机器不够，扩展到多台机器比较简单 | 适应于多核分布式 | 进程占优 |
优劣
| 优劣 | 多进程 | 多线程 |
|---|---|---|
| 优点 | 编程、调试简单，可靠性较高 | 创建、销毁、切换速度快，内存、资源占用小 |
| 缺点 | 创建、销毁、切换速度慢，内存、资源占用大 | 编程、调试复杂，可靠性较差 |
选择
- 需要频繁创建销毁的优先用线程
- 需要进行大量计算的优先使用线程
- 强相关的处理用线程，弱相关的处理用进程
- 可能要扩展到多机分布的用进程，多核分布的用线程
- 都满足需求的情况下，用你最熟悉、最拿手的方式
在现代操作系统里，同一时间可能有多个内核执行流在执行，因此内核其实像多进程多线程编程一样也需要一些同步机制来同步各执行单元对共享数据的访问。尤其是在多处理器系统上，更需要一些同步机制来同步不同处理器上的执行单元对共享的数据的访问。
- 原子操作
- 信号量（semaphore）
- 读写信号量（rw_semaphore）
- 自旋锁（spinlock）
- 大内核锁（BKL，Big Kernel Lock）
- 读写锁（rwlock）
- 大读者锁（brlock-Big Reader Lock）
- 读-拷贝修改(RCU，Read-Copy Update)
- 顺序锁（seqlock）
- 系统资源不足
- 资源分配不当
- 进程运行推进顺序不合适
- 互斥
- 请求和保持
- 不剥夺
- 环路
- 打破互斥条件：改造独占性资源为虚拟资源，大部分资源已无法改造。
- 打破不可抢占条件：当一进程占有一独占性资源后又申请一独占性资源而无法满足，则退出原占有的资源。
- 打破占有且申请条件：采用资源预先分配策略，即进程运行前申请全部资源，满足则运行，不然就等待，这样就不会占有且申请。
- 打破循环等待条件：实现资源有序分配策略，对所有设备实现分类编号，所有进程只能采用按序号递增的形式申请资源。
- 有序资源分配法
- 银行家算法
操作系统的主要功能是为管理硬件资源和为应用程序开发人员提供良好的环境，但是计算机系统的各种硬件资源是有限的，因此为了保证每一个进程都能安全的执行。处理器设有两种模式：用户模式 与 内核模式。一些容易发生安全问题的操作都被限制在只有内核模式下才可以执行，例如 I/O 操作，修改基址寄存器内容等。
当我们处在用户态但是却不得不调用内核态下一些操作的时候这时候可以利用Linux提供的一些转换接口唤起操作，而连接用户模式和内核模式的接口称之为 系统调用。
应用程序代码运行在用户模式下，当应用程序需要实现内核模式下的指令时，先向操作系统发送调用请求。操作系统收到请求后，执行系统调用接口，使处理器进入内核模式。当处理器处理完系统调用操作后，操作系统会让处理器返回用户模式，继续执行用户代码。
进程的虚拟地址空间可分为两部分，内核空间 和 用户空间。内核空间中存放的是内核代码和数据，而进程的用户空间中存放的是用户程序的代码和数据。不管是内核空间还是用户空间，它们都处于虚拟空间中，都是对物理地址的映射。
一个操作系统可以支持多种底层不同的文件系统(比如 NTFS, FAT, ext3, ext4)，为了给内核和用户进程提供统一的文件系统视图，Linux 在用户进程和底层文件系统之间加入了一个抽象层，即虚拟文件系统( Virtual File System, VFS )，进程所有的文件操作都通过 VFS，由 VFS 来适配各种底层不同的文件系统，完成实际的文件操作。
通俗的说，VFS 就是定义了一个通用文件系统的接口层和适配层，一方面为用户进程提供了一组统一的访问文件，目录和其他对象的统一方法，另一方面又要和不同的底层文件系统进行适配。如图所示：
- 超级块(super_block)，用于保存一个文件系统的所有元数据，相当于这个文件系统的信息库，为其他的模块提供信息。因此一个超级块可代表一个文件系统。文件系统的任意元数据修改都要修改超级块。超级块对象是常驻内存并被缓存的。
- 目录项模块，管理路径的目录项。比如一个路径
/usr/local/hello.txt，那么目录项有 usr, local, hello.txt。目录项的块，存储的是这个目录下的所有的文件的inode号 和 文件名 等信息。其内部是树形结构，操作系统检索一个文件，都是从根目录开始，按层次解析路径中的所有目录，直到定位到文件。 - inode 模块，管理一个具体的文件，是文件的唯一标识，一个文件对应一个 inode。通过 inode 可以方便的找到文件在磁盘扇区的位置。同时 inode 模块可链接到 address_space 模块，方便查找自身文件数据是否已经缓存。
- 打开文件列表模块，包含所有内核已经打开的文件。已经打开的文件对象由 open 系统调用在内核中创建，也叫文件句柄。打开文件列表模块中包含一个列表，每个列表表项是一个结构体 struct file，结构体中的信息用来表示打开的一个文件的各种状态参数。
- file_operations 模块。这个模块中维护一个数据结构，是一系列函数指针的集合，其中包含所有可以使用的系统调用函数，例如 open、read、write、mmap 等。每个打开文件(打开文件列表模块的一个表项)都可以连接到 file_operations 模块，从而对任何已打开的文件，通过系统调用函数，实现各种操作。
- address_space 模块，它表示一个文件在页缓存中已经缓存了的物理页。它是页缓存和外部设备中文件系统的桥梁。如果将文件系统可以理解成数据源，那么 address_space 可以说关联了内存系统和文件系统。我们会在后面继续讨论。
读文件
- 进程调用库函数向内核发起读文件请求；
- 内核通过检查进程的文件描述符定位到虚拟文件系统的已打开文件列表项；
- 调用该文件可用的系统调用函数
read()； read()函数通过文件表项链接到目录项模块，根据传入的文件路径，在目录项模块中检索，找到该文件的inode；- 在
inode中，通过文件内容偏移量计算出要读取的页； - 通过
inode找到文件对应的address_space； - 在
address_space中访问该文件的页缓存树，查找对应的页缓存结点：- 如果页缓存命中，那么直接返回文件内容；
- 如果页缓存缺失，那么产生一个页缺失异常，创建一个页缓存页，同时通过
inode找到文件该页的磁盘地址，读取相应的页填充该缓存页； - 重新进行第 6 步查找页缓存；
- 文件内容读取成功。
总结一下：inode 管磁盘，address_space 接内存，两者互相指针链接。
Inode 是文件系统(VFS)下的概念，通过 一个 inode 对应一个文件 使得文件管理按照类似索引的这种树形结构进行管理，通过 inode 快速的找到文件在磁盘扇区的位置；但是这种管理机制并不能满足读写的要求，因为我们修改文件的时候是先修改内存里的，所以就有了页缓存机制，作为内存与文件的缓冲区。
address_space 模块表示一个文件在页缓存中已经缓存了的物理页。它是页缓存和外部设备中文件系统的桥梁。如果将文件系统可以理解成数据源，那么 address_space 可以说关联了内存系统和文件系统。
写文件
前5步和读文件一致，在 address_space 中查询对应页的页缓存是否存在；
- 如果页缓存命中，直接把文件内容修改更新在页缓存的页中，写文件就结束了。这时候文件修改位于页缓存，并没有写回到磁盘文件中去。
- 如果页缓存缺失，那么产生一个页缺失异常，创建一个页缓存页，同时通过
inode找到文件该页的磁盘地址，读取相应的页填充该缓存页。此时缓存页命中，进行第 6 步。 - 一个页缓存中的页如果被修改，那么会被标记成脏页，脏页需要写回到磁盘中的文件块。有两种方式可以把脏页写回磁盘：
- 手动调用
sync()或者fsync()系统调用把脏页写回； - pdflush 进程会定时把脏页写回到磁盘。
- 手动调用
同时注意，脏页不能被置换出内存，如果脏页正在被写回，那么会被设置写回标记，这时候该页就被上锁，其他写请求被阻塞直到锁释放。
Linux 提供了轮询、I/O 中断以及 DMA 传输这 3 种磁盘与主存之间的数据传输机制。其中轮询方式是基于死循环对 I/O 端口进行不断检测。I/O 中断方式是指当数据到达时，磁盘主动向 CPU 发起中断请求，由 CPU 自身负责数据的传输过程。 DMA 传输则在 I/O 中断的基础上引入了 DMA 磁盘控制器，由 DMA 磁盘控制器负责数据的传输，降低了 I/O 中断操作对 CPU 资源的大量消耗。
在 DMA 技术出现之前，应用程序与磁盘之间的 I/O 操作都是通过 CPU 的中断完成的。每次用户进程读取磁盘数据时，都需要 CPU 中断，然后发起 I/O 请求等待数据读取和拷贝完成，每次的 I/O 中断都导致 CPU 的上下文切换。
使用 I/O 中断方式读取数据步骤：
- 用户进程向 CPU 发起 read 系统调用读取数据，由用户态切换为内核态，然后一直阻塞等待数据的返回；
- CPU 在接收到指令以后对磁盘发起 I/O 请求，将磁盘数据先放入磁盘控制器缓冲区；
- 数据准备完成以后，磁盘向 CPU 发起 I/O 中断；
- CPU 收到 I/O 中断以后将磁盘缓冲区中的数据拷贝到内核缓冲区，然后再从内核缓冲区拷贝到用户缓冲区；
- 用户进程由内核态切换回用户态，解除阻塞状态，然后等待 CPU 的下一个执行时间钟。
DMA(Direct Memory Access)即直接存储器存取，是指外部设备不通过 CPU 而直接与系统内存交换数据的接口技术。
要把外设的数据读入内存或把内存的数据传送到外设，一般都要通过 CPU 控制完成，如 CPU 程序查询或中断方式。利用中断进行数据传送，可以大大提高 CPU 的利用率。但是采用中断传送有它的缺点，对于一个高速 I/O 设 备以及批量交换数据的情况，如果中断 I/O 操作带来的将是性能的损耗。对于这种类型的操作如果可以找一个第三方来执行数据拷贝而 I/O 还继续执行数据读取主流程任务是最好的。DMA 在外设与内存间直接进行数据交换，而不通过 CPU，这样数据传送的速度就取决于存储器和外设的工作速度。
通常系统的总线是由 CPU 管理的。在 DMA 方式时，就希望 CPU 把这些总线让出来，即 CPU 连到这些总线上的线处于第三态：高阻状态，而由 DMA 控制器接管，控制传送的字节数，判断 DMA 是否结束，以及发出 DMA 结束信号。DMA 控制器必须有以下功能：
1. 能向 CPU 发出系统保持(HOLD)信号，提出总线接管请求； 2. 当 CPU 发出允许接管信号后，负责对总线的控制，进入 DMA 方式； 3. 能对存储器寻址及能修改地址指针，实现对内存的读写操作； 4. 能决定本次 DMA 传送的字节数，判断 DMA 传送是否结束； 5. 发出 DMA 结束信号，使 CPU 恢复正常工作状态。
有了DMA之后的数据读取方式就变了：
CPU 从繁重的 I/O 操作中解脱，数据读取操作的流程如下：
- 用户进程向 CPU 发起 read 系统调用读取数据，由用户态切换为内核态，然后一直阻塞等待数据的返回；
- CPU 在接收到指令以后对 DMA 磁盘控制器发起调度指令；
- DMA 磁盘控制器对磁盘发起 I/O 请求，将磁盘数据先放入磁盘控制器缓冲区，CPU 全程不参与此过程；
- 数据读取完成后，DMA 磁盘控制器会接受到磁盘的通知，将数据从磁盘控制器缓冲区拷贝到内核缓冲区；
- DMA 磁盘控制器向 CPU 发出数据读完的信号，由 CPU 负责将数据从内核缓冲区拷贝到用户缓冲区；
- 用户进程由内核态切换回用户态，解除阻塞状态，然后等待 CPU 的下一个执行时间钟。
在 Linux 系统中，传统的访问方式是通过 write() 和 read() 两个系统调用实现的，通过 read() 函数读取文件到到缓存区中，然后通过 write()方法把缓存中的数据输出到网络端口，伪代码如下：
Copyread(file_fd, tmp_buf, len);
write(socket_fd, tmp_buf, len);图分别对应传统 I/O 操作的数据读写流程，整个过程涉及 2 次 CPU 拷贝、2 次 DMA 拷贝总共 4 次拷贝，以及 4 次上下文切换，下面简单地阐述一下相关的概念。
关键名词解释：
上下文切换：当用户程序向内核发起系统调用时，CPU 将用户进程从用户态切换到内核态；当系统调用返回时，CPU 将用户进程从内核态切换回用户态。
CPU 拷贝：由 CPU 直接处理数据的传送，数据拷贝时会一直占用 CPU 的资源。
DMA 拷贝：由 CPU 向 DMA 磁盘控制器下达指令，让 DMA 控制器来处理数据的传送，数据传送完毕再把信息反馈给 CPU，从而减轻了 CPU 资源的占有率。
当应用程序执行 read 系统调用读取一块数据的时候，如果这块数据已经存在于用户进程的页内存中，就直接从内存中读取数据；如果数据不存在，则先将数据从磁盘加载数据到内核空间的读缓存(read buffer)中，再从读缓存拷贝到用户进程的页内存中。
Copyread(file_fd, tmp_buf, len);基于传统的 I/O 读取方式，read 系统调用会触发 2 次上下文切换，1 次 DMA 拷贝和 1 次 CPU 拷贝，发起数据读取的流程如下：
- 用户进程通过
read()函数向内核 (kernel) 发起系统调用，上下文从用户态 (user space) 切换为内核态 (kernel space)； - CPU 利用 DMA 控制器将数据从主存或硬盘拷贝到内核空间 (kernel space) 的读缓冲区 (read buffer)；
- CPU 将读缓冲区 (read buffer) 中的数据拷贝到用户空间 (user space) 的用户缓冲区 (user buffer)。
- 上下文从内核态 (kernel space) 切换回用户态 (user space)，read 调用执行返回。
当应用程序准备好数据，执行 write 系统调用发送网络数据时，先将数据从用户空间的页缓存拷贝到内核空间的网络缓冲区(socket buffer)中，然后再将写缓存中的数据拷贝到网卡设备完成数据发送。
Copywrite(socket_fd, tmp_buf, len);基于传统的 I/O 写入方式，write() 系统调用会触发 2 次上下文切换，1 次 CPU 拷贝和 1 次 DMA 拷贝，用户程序发送网络数据的流程如下：
- 用户进程通过
write()函数向内核 (kernel) 发起系统调用，上下文从用户态 (user space) 切换为内核态(kernel space)。 - CPU 将用户缓冲区 (user buffer) 中的数据拷贝到内核空间 (kernel space) 的网络缓冲区 (socket buffer)。
- CPU 利用 DMA 控制器将数据从网络缓冲区 (socket buffer) 拷贝到网卡进行数据传输。
- 上下文从内核态 (kernel space) 切换回用户态 (user space)，write 系统调用执行返回。
在 Linux 中零拷贝技术主要有 3 个实现思路：用户态直接 I/O、减少数据拷贝次数以及写时复制技术。
- 用户态直接 I/O：应用程序可以直接访问硬件存储，操作系统内核只是辅助数据传输。这种方式依旧存在用户空间和内核空间的上下文切换，硬件上的数据直接拷贝至了用户空间，不经过内核空间。因此，直接 I/O 不存在内核空间缓冲区和用户空间缓冲区之间的数据拷贝。
- 减少数据拷贝次数：在数据传输过程中，避免数据在用户空间缓冲区和系统内核空间缓冲区之间的CPU拷贝，以及数据在系统内核空间内的CPU拷贝，这也是当前主流零拷贝技术的实现思路。
- 写时复制技术：写时复制指的是当多个进程共享同一块数据时，如果其中一个进程需要对这份数据进行修改，那么将其拷贝到自己的进程地址空间中，如果只是数据读取操作则不需要进行拷贝操作。
用户态直接 I/O 使得应用进程或运行在用户态(user space)下的库函数直接访问硬件设备，数据直接跨过内核进行传输，内核在数据传输过程除了进行必要的虚拟存储配置工作之外，不参与任何其他工作，这种方式能够直接绕过内核，极大提高了性能。
缺点：
- 这种方法只能适用于那些不需要内核缓冲区处理的应用程序，这些应用程序通常在进程地址空间有自己的数据缓存机制，称为自缓存应用程序，如数据库管理系统就是一个代表。
- 这种方法直接操作磁盘 I/O，由于 CPU 和磁盘 I/O 之间的执行时间差距，会造成资源的浪费，解决这个问题需要和异步 I/O 结合使用。
一种零拷贝方式是使用 mmap + write 代替原来的 read + write 方式，减少了 1 次 CPU 拷贝操作。mmap 是 Linux 提供的一种内存映射文件方法，即将一个进程的地址空间中的一段虚拟地址映射到磁盘文件地址，mmap + write 的伪代码如下：
Copytmp_buf = mmap(file_fd, len);
write(socket_fd, tmp_buf, len);使用 mmap 的目的是将内核中读缓冲区(read buffer)的地址与用户空间的缓冲区(user buffer)进行映射，从而实现内核缓冲区与应用程序内存的共享，省去了将数据从内核读缓冲区(read buffer)拷贝到用户缓冲区(user buffer)的过程，然而内核读缓冲区(read buffer)仍需将数据到内核写缓冲区(socket buffer)，大致的流程如下图所示：
基于 mmap + write 系统调用的零拷贝方式，整个拷贝过程会发生 4 次上下文切换，1 次 CPU 拷贝和 2 次 DMA 拷贝，用户程序读写数据的流程如下：
- 用户进程通过
mmap()函数向内核 (kernel) 发起系统调用，上下文从用户态 (user space) 切换为内核态(kernel space)； - 将用户进程的内核空间的读缓冲区 (read buffer) 与用户空间的缓存区 (user buffer) 进行内存地址映射；
- CPU 利用 DMA 控制器将数据从主存或硬盘拷贝到内核空间 (kernel space) 的读缓冲区 (read buffer)；
- 上下文从内核态 (kernel space) 切换回用户态 (user space)，mmap 系统调用执行返回；
- 用户进程通过
write()函数向内核 (kernel) 发起系统调用，上下文从用户态 (user space) 切换为内核态(kernel space)； - CPU 将读缓冲区 (read buffer) 中的数据拷贝到的网络缓冲区 (socket buffer) ；
- CPU 利用 DMA 控制器将数据从网络缓冲区 (socket buffer) 拷贝到网卡进行数据传输；
- 上下文从内核态 (kernel space) 切换回用户态 (user space) ，write 系统调用执行返回；
缺陷：
mmap 主要的用处是提高 I/O 性能，特别是针对大文件。对于小文件，内存映射文件反而会导致碎片空间的浪费，因为内存映射总是要对齐页边界，最小单位是 4 KB，一个 5 KB 的文件将会映射占用 8 KB 内存，也就会浪费 3 KB 内存。
另外 mmap 隐藏着一个陷阱，当使用 mmap 映射一个文件时，如果这个文件被另一个进程所截获，那么 write 系统调用会因为访问非法地址被 SIGBUS 信号终止，SIGBUS 默认会杀死进程并产生一个 coredump，如果服务器被这样终止那损失就可能不小。
解决这个问题通常使用文件的租借锁：首先为文件申请一个租借锁，当其他进程想要截断这个文件时，内核会发送一个实时的 RT_SIGNAL_LEASE 信号，告诉当前进程有进程在试图破坏文件，这样 write 在被 SIGBUS 杀死之前，会被中断，返回已经写入的字节数，并设置 errno 为 success。
通常的做法是在 mmap 之前加锁，操作完之后解锁。
sendfile 系统调用在 Linux 内核版本 2.1 中被引入，目的是简化通过网络在两个通道之间进行的数据传输过程。sendfile 系统调用的引入，不仅减少了 CPU 拷贝的次数，还减少了上下文切换的次数，它的伪代码如下：
Copysendfile(socket_fd, file_fd, len);通过 sendfile 系统调用，数据可以直接在内核空间内部进行 I/O 传输，从而省去了数据在用户空间和内核空间之间的来回拷贝。与 mmap 内存映射方式不同的是， sendfile 调用中 I/O 数据对用户空间是完全不可见的。也就是说，这是一次完全意义上的数据传输过程。
基于 sendfile 系统调用的零拷贝方式，整个拷贝过程会发生 2 次上下文切换，1 次 CPU 拷贝和 2 次 DMA 拷贝，用户程序读写数据的流程如下：
- 用户进程通过
sendfile()函数向内核 (kernel) 发起系统调用，上下文从用户态 (user space) 切换为内核态(kernel space)。 - CPU 利用 DMA 控制器将数据从主存或硬盘拷贝到内核空间 (kernel space) 的读缓冲区 (read buffer)。
- CPU 将读缓冲区 (read buffer) 中的数据拷贝到的网络缓冲区 (socket buffer)。
- CPU 利用 DMA 控制器将数据从网络缓冲区 (socket buffer) 拷贝到网卡进行数据传输。
- 上下文从内核态 (kernel space) 切换回用户态 (user space)，sendfile 系统调用执行返回。
相比较于 mmap 内存映射的方式，sendfile 少了 2 次上下文切换，但是仍然有 1 次 CPU 拷贝操作。sendfile 存在的问题是用户程序不能对数据进行修改，而只是单纯地完成了一次数据传输过程。
缺点：只能适用于那些不需要用户态处理的应用程序。
在某些情况下，内核缓冲区可能被多个进程所共享，如果某个进程想要这个共享区进行 write 操作，由于 write 不提供任何的锁操作，那么就会对共享区中的数据造成破坏，写时复制的引入就是 Linux 用来保护数据的。
写时复制指的是当多个进程共享同一块数据时，如果其中一个进程需要对这份数据进行修改，那么就需要将其拷贝到自己的进程地址空间中。这样做并不影响其他进程对这块数据的操作，每个进程要修改的时候才会进行拷贝，所以叫写时拷贝。这种方法在某种程度上能够降低系统开销，如果某个进程永远不会对所访问的数据进行更改，那么也就永远不需要拷贝。
缺点：
需要 MMU 的支持，MMU 需要知道进程地址空间中哪些页面是只读的，当需要往这些页面写数据时，发出一个异常给操作系统内核，内核会分配新的存储空间来供写入的需求。
缓冲区共享方式完全改写了传统的 I/O 操作，传统的 Linux I/O 接口支持数据在应用程序地址空间和操作系统内核之间交换，这种交换操作导致所有的数据都需要进行拷贝。
如果采用 fbufs 这种方法，需要交换的是包含数据的缓冲区，这样就消除了多余的拷贝操作。应用程序将 fbuf 传递给操作系统内核，这样就能减少传统的 write 系统调用所产生的数据拷贝开销。
同样的应用程序通过 fbuf 来接收数据，这样也可以减少传统 read 系统调用所产生的数据拷贝开销。
fbuf 的思想是每个进程都维护着一个缓冲区池，这个缓冲区池能被同时映射到用户空间 (user space) 和内核态 (kernel space)，内核和用户共享这个缓冲区池，这样就避免了一系列的拷贝操作。
缺点：
缓冲区共享的难度在于管理共享缓冲区池需要应用程序、网络软件以及设备驱动程序之间的紧密合作，而且如何改写 API 目前还处于试验阶段并不成熟。
无论是传统 I/O 拷贝方式还是引入零拷贝的方式，2 次 DMA Copy 是都少不了的，因为两次 DMA 都是依赖硬件完成的。下面从 CPU 拷贝次数、DMA 拷贝次数以及系统调用几个方面总结一下上述几种 I/O 拷贝方式的差别。
| 拷贝方式 | CPU拷贝 | DMA拷贝 | 系统调用 | 上下文切换 |
|---|---|---|---|---|
| 传统方式(read + write) | 2 | 2 | read / write | 4 |
| 内存映射(mmap + write) | 1 | 2 | mmap / write | 4 |
| sendfile | 1 | 2 | sendfile | 2 |
在地址映射过程中，若在页面中发现所要访问的页面不在内存中，则产生缺页中断。当发生缺页中断时，如果操作系统内存中没有空闲页面，则操作系统必须在内存选择一个页面将其移出内存，以便为即将调入的页面让出空间。而用来选择淘汰哪一页的规则叫做页面置换算法。
- 全局置换：在整个内存空间置换
- 局部置换：在本进程中进行置换
全局：
- 工作集算法
- 缺页率置换算法
局部：
- 最佳置换算法（OPT）
- 先进先出置换算法（FIFO）
- 最近最久未使用（LRU）算法
- 时钟（Clock）置换算法
数据库出现性能瓶颈，对外表现有几个方面：
- 大量请求阻塞 在高并发场景下，大量请求都需要操作数据库，导致连接数不够了，请求处于阻塞状态。
- SQL 操作变慢 如果数据库中存在一张上亿数据量的表，一条 SQL 没有命中索引会全表扫描，这个查询耗时会非常久。
- 存储出现问题 业务量剧增，单库数据量越来越大，给存储造成巨大压力。
从机器的角度看，性能瓶颈无非就是CPU、内存、磁盘、网络这些，要解决性能瓶颈最简单粗暴的办法就是提升机器性能，但是通过这种方法成本和收益投入比往往又太高了，不划算，所以重点还是要从软件角度入手。
SQL 调优往往是解决数据库问题的第一步，往往投入少部分精力就能获得较大的收益。
SQL 调优主要目的是尽可能的让那些慢 SQL 变快，手段其实也很简单就是让 SQL 执行尽量命中索引。
开启慢 SQL 记录
如果你使用的是 Mysql，需要在 Mysql 配置文件中配置几个参数即可。
slow_query_log=on
long_query_time=1
slow_query_log_file=/path/to/log
调优的工具
常常会用到 explain 这个命令来查看 SQL 语句的执行计划，通过观察执行结果很容易就知道该 SQL 语句是不是全表扫描、有没有命中索引。
select id, age, gender from user where name = '爱笑的架构师';
返回有一列叫“type”，常见取值有：
ALL、index、range、 ref、eq_ref、const、system、NULL（从左到右，性能从差到好）
ALL 代表这条 SQL 语句全表扫描了，需要优化。一般来说需要达到range 级别及以上。
以一个场景举例说明：
“user”表中有 user_id、nickname 等字段，“order”表中有order_id、user_id等字段，如果想拿到用户昵称怎么办？一般情况是通过 join 关联表操作，在查询订单表时关联查询用户表，从而获取导用户昵称。
但是随着业务量增加，订单表和用户表肯定也是暴增，这时候通过两个表关联数据就比较费力了，为了取一个昵称字段而不得不关联查询几十上百万的用户表，其速度可想而知。
这个时候可以尝试将 nickname 这个字段加到 order 表中（order_id、user_id、nickname），这种做法通常叫做数据库表冗余字段。这样做的好处展示订单列表时不需要再关联查询用户表了。
冗余字段的做法也有一个弊端，如果这个字段更新会同时涉及到多个表的更新，因此在选择冗余字段时要尽量选择不经常更新的字段。
当单台数据库实例扛不住，我们可以增加实例组成集群对外服务。当发现读请求明显多于写请求时，我们可以让主实例负责写，从实例对外提供读的能力；如果读实例压力依然很大，可以在数据库前面加入缓存如 redis，让请求优先从缓存取数据减少数据库访问。缓存分担了部分压力后，数据库依然是瓶颈，这个时候就可以考虑分库分表的方案了。
分库
随着业务发展，数据库终于成为了瓶颈，这个时候多个服务共享一个数据库基本不可行了。我们需要将每个服务相关的表拆出来单独建立一个数据库，这其实就是**“分库”**了。单数据库的能够支撑的并发量是有限的，拆成多个库可以使服务间不用竞争，提升服务的性能
分表
如果系统处于高速发展阶段，拿商城系统来说，一天下单量可能几十万，那数据库中的订单表增长就特别快，增长到一定阶段数据库查询效率就会出现明显下降。因此，当单表数据增量过快，业界流传是超过500万的数据量就要考虑分表了。当然500万只是一个经验值，大家可以根据实际情况做出决策。
分表有几个维度，一是水平切分和垂直切分，二是单库内分表和多库内分表。
分库分表带来的复杂性
分库分表的确解决了很多问题，但是也给系统带来了很多复杂性。
（1）跨库关联查询
在单库未拆分表之前，我们可以很方便使用 join 操作关联多张表查询数据，但是经过分库分表后两张表可能都不在一个数据库中，如何使用 join 呢？
有几种方案可以解决：
- 字段冗余：把需要关联的字段放入主表中，避免 join 操作；
- 数据抽象：通过ETL等将数据汇合聚集，生成新的表；
- 全局表：比如一些基础表可以在每个数据库中都放一份；
- 应用层组装：将基础数据查出来，通过应用程序计算组装；
（2）分布式事务
单数据库可以用本地事务搞定，使用多数据库就只能通过分布式事务解决了。
常用解决方案有：基于可靠消息（MQ）的解决方案、两阶段事务提交、柔性事务等。
（3）排序、分页、函数计算问题
在使用 SQL 时 order by， limit 等关键字需要特殊处理，一般来说采用分片的思路：
先在每个分片上执行相应的函数，然后将各个分片的结果集进行汇总和再次计算，最终得到结果。
（4）分布式 ID
如果使用 Mysql 数据库在单库单表可以使用 id 自增作为主键，分库分表了之后就不行了，会出现id 重复。
常用的分布式 ID 解决方案有：
- UUID
- 基于数据库自增单独维护一张 ID表
- 号段模式
- Redis 缓存
- 雪花算法（Snowflake）
作用
- 修饰变量，说明该变量不可以被改变；
- 修饰指针，分为指向常量的指针（pointer to const）和自身是常量的指针（常量指针，const pointer）；
- 修饰引用，指向常量的引用（reference to const），用于形参类型，即避免了拷贝，又避免了函数对值的修改；
- 修饰成员函数，说明该成员函数内不能修改成员变量。
const 的指针与引用
- 指针
- 指向常量的指针（pointer to const）
- 自身是常量的指针（常量指针，const pointer）
- 引用
- 指向常量的引用（reference to const）
- 没有 const reference，因为引用只是对象的别名，引用不是对象，不能用 const 修饰
const 使用
// 类
class A
{
private:
const int a; // 常对象成员，可以使用初始化列表或者类内初始化
public:
// 构造函数
A() : a(0) { };
A(int x) : a(x) { }; // 初始化列表
// const可用于对重载函数的区分
int getValue(); // 普通成员函数
int getValue() const; // 常成员函数，不得修改类中的任何数据成员的值
};
void function()
{
// 对象
A b; // 普通对象，可以调用全部成员函数
const A a; // 常对象，只能调用常成员函数
const A *p = &a; // 指针变量，指向常对象
const A &q = a; // 指向常对象的引用
// 指针
char greeting[] = "Hello";
char* p1 = greeting; // 指针变量，指向字符数组变量
const char* p2 = greeting; // 指针变量，指向字符数组常量（const 后面是 char，说明指向的字符（char）不可改变）
char* const p3 = greeting; // 自身是常量的指针，指向字符数组变量（const 后面是 p3，说明 p3 指针自身不可改变）
const char* const p4 = greeting; // 自身是常量的指针，指向字符数组常量
}
// 函数
void function1(const int Var); // 传递过来的参数在函数内不可变
void function2(const char* Var); // 参数指针所指内容为常量
void function3(char* const Var); // 参数指针为常量
void function4(const int& Var); // 引用参数在函数内为常量
// 函数返回值
const int function5(); // 返回一个常数
const int* function6(); // 返回一个指向常量的指针变量，使用：const int *p = function6();
int* const function7(); // 返回一个指向变量的常指针，使用：int* const p = function7();宏定义 #define 和 const 常量
| 宏定义 #define | const 常量 |
|---|---|
| 宏定义，相当于字符替换 | 常量声明 |
| 预处理器处理 | 编译器处理 |
| 无类型安全检查 | 有类型安全检查 |
| 不分配内存 | 要分配内存 |
| 存储在代码段 | 存储在数据段 |
可通过 #undef 取消 |
不可取消 |
- 修饰普通变量，修改变量的存储区域和生命周期，使变量存储在静态区，在 main 函数运行前就分配了空间，如果有初始值就用初始值初始化它，如果没有初始值系统用默认值初始化它。
- 修饰普通函数，表明函数的作用范围，仅在定义该函数的文件内才能使用。在多人开发项目时，为了防止与他人命名空间里的函数重名，可以将函数定位为 static。
- 修饰成员变量，修饰成员变量使所有的对象只保存一个该变量，而且不需要生成对象就可以访问该成员。
- 修饰成员函数，修饰成员函数使得不需要生成对象就可以访问该函数，但是在 static 函数内不能访问非静态成员。
volatile int i = 10;
- volatile 关键字是一种类型修饰符，用它声明的类型变量表示可以被某些编译器未知的因素（操作系统、硬件、其它线程等）更改。所以使用 volatile 告诉编译器不应对这样的对象进行优化。
- volatile 关键字声明的变量，每次访问时都必须从内存中取出值（没有被 volatile 修饰的变量，可能由于编译器的优化，从 CPU 寄存器中取值）
- const 可以是 volatile （如只读的状态寄存器）
- 指针可以是 volatile
this指针是一个隐含于每一个非静态成员函数中的特殊指针。它指向调用该成员函数的那个对象。- 当对一个对象调用成员函数时，编译程序先将对象的地址赋给
this指针，然后调用成员函数，每次成员函数存取数据成员时，都隐式使用this指针。 - 当一个成员函数被调用时，自动向它传递一个隐含的参数，该参数是一个指向这个成员函数所在的对象的指针。
this指针被隐含地声明为:ClassName *const this，这意味着不能给this指针赋值；在ClassName类的const成员函数中，this指针的类型为：const ClassName* const，这说明不能对this指针所指向的这种对象是不可修改的（即不能对这种对象的数据成员进行赋值操作）；this并不是一个常规变量，而是个右值，所以不能取得this的地址（不能&this）。- 在以下场景中，经常需要显式引用 this 指针
- 为实现对象的链式引用；
- 为避免对同一对象进行赋值操作；
- 在实现一些数据结构时，如
list。
特征
- 相当于把内联函数里面的内容写在调用内联函数处；
- 相当于不用执行进入函数的步骤，直接执行函数体；
- 相当于宏，却比宏多了类型检查，真正具有函数特性；
- 编译器一般不内联包含循环、递归、switch 等复杂操作的内联函数；
- 在类声明中定义的函数，除了虚函数的其他函数都会自动隐式地当成内联函数。
使用
// 声明
inline int functionName(int first, int second,...);
// 类内定义，隐式内联
class A {
int doA() { return 0; } // 隐式内联
}
// 类外定义，需要显式内联
class A {
int doA();
}
inline int A::doA() { return 0; } // 需要显式内联编译器对 inline 函数的处理步骤
- 将 inline 函数体复制到 inline 函数调用点处；
- 为所用 inline 函数中的局部变量分配内存空间；
- 将 inline 函数的的输入参数和返回值映射到调用方法的局部变量空间中；
- 如果 inline 函数有多个返回点，将其转变为 inline 函数代码块末尾的分支（使用 GOTO）。
优缺点
优点
- 内联函数同宏函数一样将在被调用处进行代码展开，省去了参数压栈、栈帧开辟与回收，结果返回等，从而提高程序运行速度。
- 内联函数相比宏函数来说，在代码展开时，会做安全检查或自动类型转换（同普通函数），而宏定义则不会。
- 在类中声明同时定义的成员函数，自动转化为内联函数，因此内联函数可以访问类的成员变量，宏定义则不能。
- 内联函数在运行时可调试，而宏定义不可以。
缺点
- 代码膨胀。内联是以代码膨胀（复制）为代价，消除函数调用带来的开销。如果执行函数体内代码的时间，相比于函数调用的开销较大，那么效率的收获会很少。另一方面，每一处内联函数的调用都要复制代码，将使程序的总代码量增大，消耗更多的内存空间。
- inline 函数无法随着函数库升级而升级。inline函数的改变需要重新编译，不像 non-inline 可以直接链接。
- 是否内联，程序员不可控。内联函数只是对编译器的建议，是否对函数内联，决定权在于编译器。
Are "inline virtual" member functions ever actually "inlined"?
- 虚函数可以是内联函数，但是当虚函数表现多态性的时候不能内联。
- 内联是在编译器建议编译器内联，而虚函数的多态性在运行期，编译器无法知道运行期调用哪个代码，因此虚函数表现为多态性时（运行期）不可以内联。
inline virtual唯一可以内联的时候是：编译器知道所调用的对象是哪个类（如Base::who()），这只有在编译器具有实际对象而不是对象的指针或引用时才会发生。
虚函数内联使用
#include <iostream>
using namespace std;
class Base
{
public:
inline virtual void who()
{
cout << "I am Base\n";
}
virtual ~Base() {}
};
class Derived : public Base
{
public:
inline void who() // 不写inline时隐式内联
{
cout << "I am Derived\n";
}
};
int main()
{
// 此处的虚函数 who()，是通过类（Base）的具体对象（b）来调用的，编译期间就能确定了，所以它可以是内联的，但最终是否内联取决于编译器。
Base b;
b.who();
// 此处的虚函数是通过指针调用的，呈现多态性，需要在运行时期间才能确定，所以不能为内联。
Base *ptr = new Derived();
ptr->who();
// 因为Base有虚析构函数（virtual ~Base() {}），所以 delete 时，会先调用派生类（Derived）析构函数，再调用基类（Base）析构函数，防止内存泄漏。
delete ptr;
ptr = nullptr;
system("pause");
return 0;
} 总的来说，struct 更适合看成是一个数据结构的实现体，class 更适合看成是一个对象的实现体。
- 默认的继承访问权限。struct 是 public 的，class 是 private 的。
- struct 作为数据结构的实现体，它默认的数据访问控制是 public 的，而 class 作为对象的实现体，它默认的成员变量访问控制是 private 的。
面向对象程序设计（Object-oriented programming，OOP）是种具有对象概念的程序编程典范，同时也是一种程序开发的抽象方针。
面向对象三大特征 —— 封装、继承、多态
public成员：可以被任意实体访问protected成员：只允许被子类及本类的成员函数访问private成员：只允许被本类的成员函数、友元类或友元函数访问
- 多态，即多种状态（形态）。简单来说，我们可以将多态定义为消息以多种形式显示的能力。
- 多态是以封装和继承为基础的。
- C++ 多态分类及实现：
- 重载多态（Ad-hoc Polymorphism，编译期）：函数重载、运算符重载
- 子类型多态（Subtype Polymorphism，运行期）：虚函数
- 参数多态性（Parametric Polymorphism，编译期）：类模板、函数模板
- 强制多态（Coercion Polymorphism，编译期/运行期）：基本类型转换、自定义类型转换
静态多态（编译期/早绑定）
函数重载
class A
{
public:
void do(int a);
void do(int a, int b);
};
动态多态（运行期期/晚绑定）
- 虚函数：用 virtual 修饰成员函数，使其成为虚函数
- 动态绑定：当使用基类的引用或指针调用一个虚函数时将发生动态绑定
注意：
- 可以将派生类的对象赋值给基类的指针或引用，反之不可
- 普通函数（非类成员函数）不能是虚函数
- 静态函数（static）不能是虚函数
- 构造函数不能是虚函数（因为在调用构造函数时，虚表指针并没有在对象的内存空间中，必须要构造函数调用完成后才会形成虚表指针）
- 内联函数不能是表现多态性时的虚函数，解释见：虚函数（virtual）可以是内联函数（inline）吗？
动态多态使用
class Shape // 形状类
{
public:
virtual double calcArea()
{
...
}
virtual ~Shape();
};
class Circle : public Shape // 圆形类
{
public:
virtual double calcArea();
...
};
class Rect : public Shape // 矩形类
{
public:
virtual double calcArea();
...
};
int main()
{
Shape * shape1 = new Circle(4.0);
Shape * shape2 = new Rect(5.0, 6.0);
shape1->calcArea(); // 调用圆形类里面的方法
shape2->calcArea(); // 调用矩形类里面的方法
delete shape1;
shape1 = nullptr;
delete shape2;
shape2 = nullptr;
return 0;
}虚析构函数是为了解决基类的指针指向派生类对象，并用基类的指针删除派生类对象。
class Shape
{
public:
Shape(); // 构造函数不能是虚函数
virtual double calcArea();
virtual ~Shape(); // 虚析构函数
};
class Circle : public Shape // 圆形类
{
public:
virtual double calcArea();
...
};
int main()
{
Shape * shape1 = new Circle(4.0);
shape1->calcArea();
delete shape1; // 因为Shape有虚析构函数，所以delete释放内存时，先调用子类析构函数，再调用基类析构函数，防止内存泄漏。
shape1 = NULL;
return 0；
}- 纯虚函数是一种特殊的虚函数，在基类中不能对虚函数给出有意义的实现，而把它声明为纯虚函数，它的实现留给该基类的派生类去做。
- 类里如果声明了虚函数，这个函数是实现的，哪怕是空实现，它的作用就是为了能让这个函数在它的子类里面可以被覆盖（override），这样的话，编译器就可以使用后期绑定来达到多态了。纯虚函数只是一个接口，是个函数的声明而已，它要留到子类里去实现。
- 虚函数在子类里面可以不重写；但纯虚函数必须在子类实现才可以实例化子类。
- 虚函数的类用于 “实作继承”，继承接口的同时也继承了父类的实现。纯虚函数关注的是接口的统一性，实现由子类完成。
- 带纯虚函数的类叫抽象类，这种类不能直接生成对象，而只有被继承，并重写其虚函数后，才能使用。抽象类被继承后，子类可以继续是抽象类，也可以是普通类。
- 虚函数指针：在含有虚函数类的对象中，指向虚函数表，在运行时确定。
- 虚函数表：在程序只读数据段（
.rodata section，存放虚函数指针，如果派生类实现了基类的某个虚函数，则在虚表中覆盖原本基类的那个虚函数指针，在编译时根据类的声明创建。
只能在堆上
方法：将析构函数设置为私有
原因：C++ 是静态绑定语言，编译器管理栈上对象的生命周期，编译器在为类对象分配栈空间时，会先检查类的析构函数的访问性。若析构函数不可访问，则不能在栈上创建对象。
只能在栈上
方法：将 new 和 delete 重载为私有
原因：在堆上生成对象，使用 new 关键词操作，其过程分为两阶段：第一阶段，使用 new 在堆上寻找可用内存，分配给对象；第二阶段，调用构造函数生成对象。将 new 操作设置为私有，那么第一阶段就无法完成，就不能够在堆上生成对象。
Class shared_ptr 实现共享式拥有（shared ownership）概念。多个智能指针指向相同对象，对象的最末一个拥有着有责任销毁对象，该对象和其相关资源会在 “最后一个 reference 被销毁” 时被释放，并清理与该对象相关的所有资源。
- 支持定制型删除器（custom deleter），可防范 Cross-DLL 问题（对象在动态链接库（DLL）中被 new 创建，却在另一个 DLL 内被 delete 销毁）、自动解除互斥锁
weak_ptr 允许你共享但不拥有某对象，一旦最末一个拥有该对象的智能指针失去了所有权，任何 weak_ptr 都会自动成空（empty）。因此，在 default 和 copy 构造函数之外，weak_ptr 只提供 “接受一个 shared_ptr” 的构造函数。
- 可打破环状引用（cycles of references，两个其实已经没有被使用的对象彼此互指，使之看似还在 “被使用” 的状态）的问题
unique_ptr 是 C++11 才开始提供的类型，是一种在异常时可以帮助避免资源泄漏的智能指针。采用独占式拥有，意味着可以确保一个对象和其相应的资源同一时间只被一个 pointer 拥有。一旦拥有着被销毁或编程 empty，或开始拥有另一个对象，先前拥有的那个对象就会被销毁，其任何相应资源亦会被释放。它对于避免内存泄漏 ——如 new 后忘记 delete ——特别有用。
- unique_ptr 用于取代 auto_ptr
被 c++11 弃用，原因是缺乏语言特性如 “针对构造和赋值” 的 std::move 语义，以及其他瑕疵。
- auto_ptr 可以赋值拷贝，复制拷贝后所有权转移；unqiue_ptr 无拷贝赋值语义，但实现了
move语义； - auto_ptr 对象不能管理数组（析构调用
delete），unique_ptr 可以管理数组（析构调用delete[]）；
c++ 程序的内存分布
函数栈
栈帧是指为一个函数调用单独分配的那部分栈空间。比如，当运行中的程序调用另一个函数时，就要进入一个新的栈帧，原来函数的栈帧称为调用者的帧，新的栈帧称为当前帧。被调用的函数运行结束后当前帧全部收缩，回到调用者的帧。%ebp是帧指针，它总是指向当前帧的底部；%esp是栈指针，它总是指向当前帧的顶部。
堆栈帧包含如下数据:
-
函数返回地址
-
局部变量/CPU寄存器数据备份
大于一个字节的值被称为多字节量，多字节量存在高位有效字节和低位有效字节，微处理器有两种不同的顺序处理高位和低位字节的顺序（一般默认是小端存储）。
● 小端（little_endian)：低位有效字节存储于较低的内存位置
● 大端（big_endian)：高位有效字节存储于较低的内存位置
网络字节序
网络字节顺序是 TCP/IP 中规定好的一种数据表示格式，它与具体的 CPU 类型、操作系统等无关，从而可以保证数据在不同主机之间传输时能够被正确解释。网络字节顺序采用：大端（Big Endian）排列方式。
对于基础类型，如float, double, int, char等，它们的大小和内存占用是一致的。而对于结构体而言，如果我们取得其sizeof的结果，会发现这个值有可能会大于结构体内所有成员大小的总和，这是由于结构体内部成员进行了内存对齐。
内存对齐的规则
定义有效对齐值（alignment）为结构体中 最宽成员 和 编译器/用户指定对齐值 中较小的那个。
(1) 结构体起始地址为有效对齐值的整数倍
(2) 结构体总大小为有效对齐值的整数倍
(3) 结构体第一个成员偏移值为0，之后成员的偏移值为 min(有效对齐值, 自身大小) 的整数倍
相当于每个成员要进行对齐，并且整个结构体也需要进行对齐。
程序的内存往往不是紧凑连续排布的，而是存在着许多碎片。我们根据碎片产生的原因把碎片分为内部碎片和外部碎片两种类型：
(1) 内部碎片：系统分配的内存大于实际所需的内存（由于对齐机制）；
(2) 外部碎片：不断分配回收不同大小的内存，由于内存分布散乱，较大内存无法分配；
继承
如果一个类继承自另一个类，那么它自身的数据位于父类之后。
含虚函数的类
如果当前类包含虚函数，则会在类的最前端占用4个字节，用于存储虚表指针，它指向一个虚函数表。虚函数表中包含当前类的所有虚函数指针。
在 C++11标准出来之前，C++环境没有多线程的概念。编译器和处理器认为系统中只有一个执行流。引入了多线程之后，情况就会变得非常复杂。这是因为：现代计算机系统为了加快执行效率，自动的包含了很多的优化。这些优化虽然保证了在单线程环境下不破坏原来的逻辑。但是一旦到了多线程之后，情况就不一样了。
之所以会产生差异，原因主要来自下面三个方面：
- 编译器优化
- CPU out-of-order执行
- CPU Cache不一致性
以下面这段伪代码为例：
X = 0, Y = 0;
Thread 1:
X = 1; // ①
r1 = Y; // ②
Thread 2:
Y = 1;
r2 = X;你可能会觉得，在这个程序执行完成之后，r1 和 r2怎么都不可能同时为0。但事实并非如此。
这是因为“Memory Reorder”的存在，“Memory Reorder” 包含了编译器和处理器两种类型的乱序。
这就导致：线程1中事件发生的顺序虽然是先①后②，但是对于线程2来说，它看到结果可能却是先②后①。甚至，当今的所有硬件平台，没有任何一个会提供完全的顺序一致（sequentially consistent）内存模型，因为这样做效率太低了。
不同的编译器和处理器对于Memory Reorder有不同的偏好，但它们都遵循一定的原则，那就是：不能修改单线程的行为（Thou shalt not modify the behavior of a single-threaded program.）。在这个基础上，它们可以做各种类型的优化。
编译器优化
编译器只要保证：在单线程环境下，执行的结果和原先一样就可以了。
对于编译器来说，它知道的是：当前线程中，数据的读写以及数据之间的依赖关系。但是，编译器并不知道哪些数据是在线程间共享，而且是有可能会被修改的。这就需要开发者在软件层面做好控制。对于编译器的乱序优化来说，开发者并非完全不能控制。编译器会提供称之为内存栅栏（Memory Barrier）的工具给开发者，让开发者告诉编译器：这部分代码编译的时候不能乱序。
Out-of-order执行
不仅仅是编译器，处理器也可能会乱序执行指令。不同架构的CPU会有不同类型的Memory Reorder偏好。
我们使用的台式机和笔记本电脑基本上都是x86架构的CPU，而手机或者平板之类的移动设备一般用的是ARM架构的CPU。相较而言，前者的乱序类型要比后者少很多。
下面这幅图是Preshing on Programming一篇文章中给出的对比关系图。
由此我们可以推算，在多线程环境下，假设我们写的代码包含了未定义行为，那么这些问题在手机上将比在电脑上更容易暴露出来。
Cache Coherency
事情还不只这么简单。现代的主流CPU几乎都会包含多个核以及多级Cache。
每个CPU核在运行的时候，都会优先考虑离自己最近的Cache，一旦命中就直接使用Cache中的数据。这是因为Cache相较于主存（RAM）来说要快很多。
但是每个核之间的Cache，每一层之间的Cache，数据常常是不一致的。而同步这些数据是需要消耗时间的。这就会造成一个问题：某个CPU核修改了一个数据，没有同步的让其他核知道，于是就存在了数据不一致的情况。
综上这些原因让我们知道，CPU所运行的程序和我们编写的代码可能是不一致的。甚至，对于同一次执行，不同线程感知到其他线程的执行顺序可能都是不一样的。因此内存模型需要考虑到所有这些细节，以便让开发者可以精确控制。因为所有未定义的行为都可能产生问题。
我们已经知道，C++中的数据都是由对象组成。一个对象包含了若干个内存位置。
每个对象从初始化开始，直到最终销毁，在其生命周期的范围内，对它进行的访问必须有一个确定的修改顺序，这个顺序包含了所有线程的访问操作。虽然程序的每一次运行，这个顺序可能是不一样的（例如：CPU资源的变化，调度器的影响），但是针对其中具体的某一次来说，必须有一个“一致的顺序”，这个顺序要被所有的线程认可，并且可见。
例如：一旦某个线程修改了一个数据，这个操作必须要让所有线程知道，在修改操作之后，所有线程都应该得到修改后的值。
从数据类型的角度来说，有两种情况：
- 对于原子类型（见下文）：由编译器保证数据的同步。
- 对于非原子类型：由开发者保证。
并发编程的难点之一就在于：识别出系统中那些在线程共享且可能会被修改的数据，并对它们做“合理”的保护。之所以强调这一点，是因为对于共享数据的保护本质上是在对抗编译器和处理器的优化，所以保护不能过度（在讲解并发编程的时候我们提到了锁的粒度）。
我们必须在保证正确性的基础上尽可能少的干扰编译器和处理器的优化：对于那些没有访问共享数据，或者对于所有线程来说都是只读的数据来说，这部分代码就任由编译器和处理器优化好了。
另外还有一点需要说明的是，这里说的是：对于每一个变量来说，要有明确的修改顺序。但是这并不要求所有的变量存在一个全局的一致顺序。这意味着，当将多个变量的访问顺序放在一起看的时候，不同线程看到的顺序可能是不一样的。
- seq-cst 模型
- acq-rel 模型
- relaxed 模型
详见 https://paul.pub/cpp-memory-model/
在我们的实际开发中，不可能将所有代码放在一个源文件中，所以会出现多个源文件，而且多个源文件之间不是独立的，而会存在多种依赖关系，如一个源文件可能要调用另一个源文件中定义的函数。每个源文件都是独立编译的，即每个*.c文件会形成一个*.o文件。为了满足前面说的依赖关系，则需要将这些源文件产生的目标文件进行链接，从而形成一个可以执行的程序。这个过程就是静态链接
动态链接的基本思想是把程序按照模块拆分成各个相对独立部分，在程序运行时才将它们链接在一起形成一个完整的程序，而不是像静态链接一样把所有程序模块都链接成一个单独的可执行文件。
静态链接的缺点很明显，一是浪费空间，因为每个可执行程序中对所有需要的目标文件都要有一份副本，所以如果多个程序对同一个目标文件都有依赖，如多个程序中都调用了printf()函数，则这多个程序中都含有printf.o，所以同一个目标文件都在内存存在多个副本；另一方面就是更新比较困难，因为每当库函数的代码修改了，这个时候就需要重新进行编译链接形成可执行程序。但是静态链接的优点就是，在可执行程序中已经具备了所有执行程序所需要的任何东西，在执行的时候运行速度快。
假设现在有两个程序program1.o和program2.o，这两者共用同一个库lib.o,假设首先运行程序program1，系统首先加载program1.o，当系统发现program1.o中用到了lib.o，即program1.o依赖于lib.o，那么系统接着加载lib.o，如果program1.o和lib.o还依赖于其他目标文件，则依次全部加载到内存中。当program2运行时，同样的加载program2.o，然后发现program2.o依赖于lib.o，但是此时lib.o已经存在于内存中，这个时候就不再进行重新加载，而是将内存中已经存在的lib.o映射到program2的虚拟地址空间中，从而进行链接（这个链接过程和静态链接类似）形成可执行程序。
动态链接的优点显而易见，就是即使需要每个程序都依赖同一个库，但是该库不会像静态链接那样在内存中存在多份副本，而是这多个程序在执行时共享同一份副本；
另一个优点是，更新也比较方便，更新时只需要替换原来的目标文件，而无需将所有的程序再重新链接一遍。当程序下一次运行时，新版本的目标文件会被自动加载到内存并且链接起来，程序就完成了升级的目标。但是动态链接也是有缺点的，因为把链接推迟到了程序运行时，所以每次执行程序都需要进行链接，所以性能会有一定损失。
参数从右到左入栈
对于 printf（const char* format, …） 这样的不定参函数，编译器通过format中的%占位符的个数来确定参数的个数。
假设参数的压栈顺序是从左到右的，这时，函数调用的时候，format最先进栈，之后是各个参数进栈，最后 pc 进栈，此时，由于format先进栈了，上面压着未知个数的参数，想要知道参数的个数，必须找到format，而要找到format，必须要知道参数的个数，这样就陷入了一个无法求解的死循环了！！
而如果把参数从右到左压栈，函数调用时，先把若干个参数都压入栈中，再压format，最后压pc，这样一来，栈顶指针加 2 便找到了format，通过format中的%占位符，取得后面参数的个数，从而正确取得所有参数。
所以，如果不存这种不定参的函数，则参数的压栈顺序无论是从左到右还是从右到左都是没关系的
| 容器 | 底层数据结构 | 时间复杂度 | 有无序 | 可不可重复 | 其他 |
|---|---|---|---|---|---|
| vector | 数组 | 随机读改、尾部插入、尾部删除 O(1) 头部插入、头部删除 O(n) | 无序 | 可重复 | 支持随机访问 |
| deque | 双端队列 | 头尾插入、头尾删除 O(1) | 无序 | 可重复 | 一个中央控制器 + 多个缓冲区，支持首尾快速增删，支持随机访问 |
| forward_list | 单向链表 | 插入、删除 O(1) | 无序 | 可重复 | 不支持随机访问 |
| list | 双向链表 | 插入、删除 O(1) | 无序 | 可重复 | 不支持随机访问 |
| stack | deque / list | 顶部插入、顶部删除 O(1) | 无序 | 可重复 | deque 或 list 封闭头端开口，不用 vector 的原因应该是容量大小有限制，扩容耗时 |
| queue | deque / list | 尾部插入、头部删除 O(1) | 无序 | 可重复 | deque 或 list 封闭头端开口，不用 vector 的原因应该是容量大小有限制，扩容耗时 |
| priority_queue | vector + max-heap | 插入、删除 O(log2n) | 有序 | 可重复 | vector容器+heap处理规则 |
| set | 红黑树 | 插入、删除、查找 O(log2n) | 有序 | 不可重复 | |
| multiset | 红黑树 | 插入、删除、查找 O(log2n) | 有序 | 可重复 | |
| map | 红黑树 | 插入、删除、查找 O(log2n) | 有序 | 不可重复 | |
| multimap | 红黑树 | 插入、删除、查找 O(log2n) | 有序 | 可重复 | |
| unordered_set | 哈希表 | 插入、删除、查找 O(1) 最差 O(n) | 无序 | 不可重复 | |
| unordered_multiset | 哈希表 | 插入、删除、查找 O(1) 最差 O(n) | 无序 | 可重复 | |
| unordered_map | 哈希表 | 插入、删除、查找 O(1) 最差 O(n) | 无序 | 不可重复 | |
| unordered_multimap | 哈希表 | 插入、删除、查找 O(1) 最差 O(n) | 无序 | 可重复 |
什么是 RPC
RPC（Remote Procedure Call）—远程过程调用，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。比如两个不同的服务 A、B 部署在两台不同的机器上，那么服务 A 如果想要调用服务 B 中的某个方法该怎么办呢？使用 HTTP请求 当然可以，但是可能会比较慢而且一些优化做的并不好。 RPC 的出现就是为了解决这个问题。RPC 是一种设计，就是为了解决不同服务之间的调用问题，完整的 RPC 实现一般会包含有 传输协议 和 序列化协议 这两个。
RPC 原理
-
服务消费方（client）调用以本地调用方式调用服务；
-
client stub（代理对象）接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体（序列化）；
-
client stub 找到服务地址，并将消息发送到服务端；
-
server stub（代理对象） 收到消息后进行解码（反序列化）；
-
server stub根据解码结果调用本地的服务；
-
本地服务执行并将结果返回给server stub；
-
server stub将返回结果打包成消息并发送至消费方；
-
client stub接收到消息，并进行解码；
-
服务消费方得到最终结果。
HSF 简介
HSF 实现了服务调用方（Consumer）和服务提供方（Provider）的点对点通信。
-
在 HSF 框架中，地址服务器用于维护全量服务器（包含服务调用方和服务提供方）包括 Diamond 服务器
-
配置服务器用于记录服务发布（服务提供方发布了哪些服务）和服务订阅（服务调用方需要哪些服务）信息，并将相关信息推送到对应的服务器上，如配置服务器会将服务提供方的相关信息推送给服务调用方。配置服务器与服务提供方、服务调用方均保持长连接，采用心跳的方式监控各服务运行节点的状况，以便剔除故障的服务提供方。
-
HSF 通过 ip 和端口号锁定服务提供方或服务调用方；通过服务名和版本号定位服务（因此，通过指定服务名和版本号可以直连本地服务器）
-
首先服务提供方会在配置服务器中完成服务的注册发布，然后服务调用方会在配置服务器中订阅服务，以便配置服务器即时推送服务提供方的 ip 和端口。
-
为了服务发布、订阅、推送的负载均衡，生产环境上的配置服务器一般会配置多台，且在不同的配置服务器之间会作实时的数据同步。
-
在服务提供方和服务调用方的点对点通信中，服务调用者会从服务提供者列表中随机选择一台进行通信，因此就形成“去中心化”的服务架构。当请求的服务提供方故障时，服务调用者会获得失败反馈，继而从剩下的服务提供者列表中选择一台再次通信，这就是 HSF 服务的容错机制。
HSF 使用过程
- **服务节点对配置服务器列表的获取。**伴随着web容器的启动，服务提供者和服务调用者向地址服务器获取配置服务器和Diamond服务器的ip列表信息
- 服务的注册发布。服务提供者获取配置服务器列表后，将服务的相关信息（接口类全名、服务版本等）包含当前服务器的ip地址、端口等信息注册到配置服务器
- 服务的订阅。当服务调用者的应用启动并获取配置服务器列表后，发送服务消费的相关信息（服务接口全名、服务版本等）到配置服务器订阅，然后配置服务器会通过“服务接口全名+服务版本”作为条件在内存中搜索，一旦获取到服务注册信息，就将对应的服务提供者的ip和端口发送到服务调用者的节点上
- 服务交互。在应用进行业务请求处理过程中，出现服务调用者对服务提供者的调用时，服务调用者会从已经保存在该应用节点上的服务提供者服务器列表里选择（阿里巴巴内部使用随机模式）其中一台服务进行请求的发送，服务交互期间是调用者和提供者两台服务器间的调用，无需通过中间别的服务器
由于服务器的硬件资源“充裕”，那么提高服务器性能的一个很直接的方法就是以空间换时间，即“浪费”服务器的硬件资源，以换取其运行效率。这就是池的概念。
池是一组资源的集合，这组资源在服务器启动之初就完全被创建并初始化，这称为静态资源分配。当服务器进入正式运行阶段，即开始处理客户请求的时候，如果它需要相关的资源，就可以直接从池中获取，无需动态分配。
很显然，直接从池中取得所需资源比动态分配资源的速度要快得多，因为分配系统资源的系统调用都是很耗时的。当服务器处理完一个客户连接后，可以把相关的资源放回池中，无需执行系统调用来释放资源。
从最终效果来看，池相当于服务器管理系统资源的应用设施，它避免了服务器对内核的频繁访问。
内存池是一种内存分配方式。
通常我们习惯直接使用new、malloc等系统调用申请分配内存，这样做的缺点在于：由于所申请内存块的大小不定，当频繁使用时会造成大量的内存碎片并进而降低性能。
内存池则是在真正使用内存之前，先申请分配一定数量的、大小相等(一般情况下)的内存块留作备用。当有新的内存需求时，就从内存池中分出一部分内存块，若内存块不够再继续申请新的内存。这样做的一个显著优点是，使得内存分配效率得到提升。
进程池和线程池相似，所以这里我们以进程池为例进行介绍。
进程池是由服务器预先创建的一组子进程，这些子进程的数目一般在 3~10 个之间。线程池中的线程数量应该和 CPU 数量差不多。
进程池中的所有子进程都运行着相同的代码，并具有相同的属性，比如优先级、 PID 等。
当有新的任务来到时，主进程将通过某种方式选择进程池中的某一个子进程来为之服务。相比于动态创建子进程，选择一个已经存在的子进程的代价显得小得多。至于主进程选择哪个子进程来为新任务服务，则有两种方法：
1）主进程使用某种算法来主动选择子进程。最简单、最常用的算法是随机算法和 Round Robin （轮流算法）。
2）主进程和所有子进程通过一个共享的工作队列来同步，子进程都睡眠在该工作队列上。当有新的任务到来时，主进程将任务添加到工作队列中。这将唤醒正在等待任务的子进程，不过只有一个子进程将获得新任务的“接管权”，它可以从工作队列中取出任务并执行之，而其他子进程将继续睡眠在工作队列上。
当选择好子进程后，主进程还需要使用某种通知机制来告诉目标子进程有新任务需要处理，并传递必要的数据。最简单的方式是，在父进程和子进程之间预先建立好一条管道，然后通过管道来实现所有的进程间通信。在父线程和子线程之间传递数据就要简单得多，因为我们可以把这些数据定义为全局，那么它们本身就是被所有线程共享的。
线程池的主要组成有上面三个部分：
- 任务队列(Task Quene)
- 线程池(Thread Pool)
- 完成队列(Completed Tasks)
实现线程池有什么好处呢？
- 降低资源消耗：池化技术可以重复利用已经创建的线程，降低线程创建和销毁的损耗。
- 提高响应速度：利用已经存在的线程进行处理，少去了创建线程的时间
- 管理线程可控：线程是稀缺资源，不能无限创建，线程池可以做到统一分配和监控
- 拓展其他功能：比如定时线程池，可以定时执行任务
线程池主要用于：
- 需要大量的线程来完成任务，且完成任务的时间比较短。 比如WEB服务器完成网页请求这样的任务，使用线程池技术是非常合适的。因为单个任务小，而任务数量巨大。但对于长时间的任务，比如一个Telnet连接请求，线程池的优点就不明显了。因为Telnet会话时间比线程的创建时间大多了。
- 对性能要求苛刻的应用，比如要求服务器迅速响应客户请求。
- 接受突发性的大量请求，但不至于使服务器因此产生大量线程的应用。
$ \tau \frac{du}{dt} = -u + I_{t} $
$ \frac{du}{dt} = \frac{-u + I_{t}}{\tau} $
$ u_{t+1} - u_{t} = \frac{-u_{t}dt}{\tau} + \frac{dt}{\tau}I_{t} $
$ u_{t+1} = (1 - \frac{dt}{\tau})u_{t} + \frac{dt}{\tau}I_{t}$