网络模型

OSI七层模型：

学习用的五层模型:

路由器中只有下三层（网络层，链路层，物理层）。

协议和数据：

交换机是多接口的网桥，全双工通信，有自学习MAC地址的能力。
路由器隔绝广播域，隔绝不同子网，连接不同网段。

MAC地址和IP地址

IP地址是目标地址，MAC地址是每一步的地址。
每一个网卡都有一个6字节的MAC地址，且全球唯一。

mac地址的标识格式：


当消息在网络上传输的时候，我们给出目标IP地址，消息通过路由器的转发，最终到达目标IP地址的主机上。
因为IP的底层是MAC，所以转发的过程中，是依靠MAC地址进行转发的。
通过ARP地址解析协议 —— 通过IP地址解析MAC地址。

MAC地址的获取：

1. ARP广播，如果目标主机的IP地址是对的，目标主机把自己的MAC地址发送回去，让对方知道。
2. 获取成功后，缓存IP——MAC的映射：ARP缓存。
   以上叫做动态缓存，自己手动添加的IP——MAC映射是 静态缓存。
   动态缓存会定时清理，静态缓存不一定。

查询ARP缓存：
arp -a

ARP地址解析协议：
功能：通过IP地址，获取MAC地址。
可以说是工作在网络层和链路层。

RARP逆地址解析协议：
功能：通过MAC地址，解析IP地址，现在已经不用了。
DHCP动态IP分配可以取代。

ICMP网际控制协议：
负责错误信息的返回，总是带着源数据返回。
ping 中使用的就是没有数据的ICMP报文。

IP地址：
IPV4：4字节 32位
IPV6：16字节，128位

IP地址由 网络号+主机号 组成。
子网掩码：规定网络号的位数。

同一个网络号的不同主机就是在同一个网段，或者说同一广播域，不需要经过路由器就可以到达，比如说一个局域网内。
不同网络号就是在不同网段，或者说在不同广播域，就需要路由器转发。

IP地址的分类：记住就行了。


127.0.0.1 是本地回环地址 也可以用 0.0.0.0。

划分子网：
将主机号划分到网络号里，不同子网之间的主机不能通信。
子网之间用路由器连接。

路由

信息在不同网段的转发依靠路由器，路由器的实现依靠路由表。路由表的构建可以手动建立（静态路由），也可以在转发的过程中自学习建立，通过路由选择协议RIP（动态路由）。
路由转发过程了解就行，不是后端的路线。

公网私网

A类私网，即使这台计算机是拥有公网IP的，也会有一个私网IP。

公网IP。

NAT网络地址转换：
将私网IP转换为公网IP，可以帮助内网访问互联网。
只能由内网去访问NAT网关，因为NAT网关不能主动访问内网。

链路层

物理层没什么好说的。

链路层的三个功能：

1. 封装成帧
2. 透明传输
3. 差错检验

帧格式：


可见帧格式：14字节的首部，4字节的尾部，帧定界符隐含在首部之首，尾部之尾。
FCS负责差错检验。
注意最大帧长和最小帧长。

MTU最大传输单元，一般来讲，超过MTU就会被分片，基本上每一层都有分片功能，但是一般不会让分片这个操作流传到IP层，因为路由器之间只有下三层，如果你还在IP层去分片，会增大出错的概率，一般是在传输层，或者我们写socket的时候，就保证不要分片，保证的方法就是数据的字节数=MTU-IP头部-传输层头部。


数据中出现了帧定界符，需要进行转义。

网卡：

1. 网卡接受到一个帧，首先会差错检验，通过接受，否则丢弃
2. wireshark抓到的帧没有FCS，因为抓到的永远是检验通过的帧，通过之后FCS被硬件丢弃
3. 网卡有多种模式，比如说混杂模式，就可以接收到别的MAC地址的帧，但是不会上传到IP层，像这种情况下，可以抓整个局域网内的包。

网络层

包格式：

IP数据包的头部固定部分20字节，填充部分一般用不到。
根据头部有什么字段，就基本可以确定这一层有什么功能。
比如说版本肯定是IP的版本，片偏移肯定是分片的时候用来确定顺序的，生存时间TTL确定最大跳数，防止死循环，检验和肯定是检验包是否出错，协议肯定时ipv4或者ipv6等等。

IP数据包的长度更长，但是一般不会让他这么长，如果这么长的话，就会在这一层或者说传输到下一层的时候被分片，这样在路由之间会传输更多的分片包，个人认为这样不好。

ping出路径：
windows下可以用pathping：

Linux下可以用traceroute：

传输层

传输层两个协议：

UDP数据报格式：

从udp的数据报文格式中可以知道，它几乎没有什么功能，检验和只能知道数据对不对，对就收下，不对就丢弃。UDP长度这个选项是冗余的，纯粹是为了字节对齐，因为UDP的报文头部不会变化，那么头部长度就是固定的，那么UDP的数据长度就可以由 IP数据包的长度 – IP的首部 – UDP的首部 来确定。
可见网络层上面就不再涉及到IP了。而是涉及源和目的的端口号。

端口号：
自确定的端口号不要小于1024，Linux的建议，防止冲突。
端口号16bit，2字节，差不多可以知道端口号的长度是多大。
一些常用的端口号：

端口的管理是防火墙的责任，防火墙可以确定是开闭哪些端口。
查看开放的端口：

TCP报文格式：

检验和：
检验数据内容是否正确。

标志位：
URG——为1，紧急指针有效，表明有紧急数据，可以无视阻塞和窗口值，优先发送
ACK——为1，确认号字段有效
RST——为1，连接出错，释放连接并重连
SYN——为1，且ACK为0，表示请求连接，SYN可以理解为请求？
FIN——为1，数据发送完毕，要求释放连接

序号：
这一次传给对方的TCP数据部分的第一个字节的编号。

确认号：
期望下一次传过来的TCP数据部分的第一个字节的编号。

窗口：
负责流量控制，告诉对方下次允许发送的数据大小。

可靠传输：多个方面的可靠

可靠传输就包括：基于逻辑链接，流量控制，拥塞控制，ACK确认，超时重传，校验和等等。这些功能共同保证TCP的可靠传输。

1.依靠连接实现可靠传输，停止等待协议下的三次握手建立TCP连接：

停止等待协议，就是说发送一个报文之后就停下来等待ACK，显然这种方式适合连接，但是不适合发数据（太低效率）。

1. 客户端首先会生成一个随机数J作为数据包的序号，给服务端发送一个SYN包，包的序号seq设置为J，发送成功后，自己进入SYN_SENT 状态，代表发送SYN包成功，等待服务端的确认。

2. 服务端收到SYN包之后，会进入到SYN_RECV状态，同时为了检测服务端到客户端是否通畅，会给客户端发送一个SYN包，将ACK设置为1，并且会带上ack=J+1，生成随机数作为包的序号，seq=K，用于确认之前收到了客户端发送的SYN包。

3. 客户端收到服务端发送的SYN包后，会检测ACK标志位是否为1，并且ack是否等于J+1,如果是的话，就说明之前服务器收到了客户端发送的SYN包，并且服务端发送给客户端的SYN包也是可以收到的，所以需要给服务端发送ACK包，ACK=1，ack=K+1。

4. 服务端收到ACK回应后，检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，客户端和服务器端进入ESTABLISHED状态，完成三次握手，随后客户端与服务器端之间可以开始传输数据了。

握手仅仅是握手吗？握手的时候需要交换哪些信息？

我们知道，TCP的滑动窗口是由对方确定，TCP版本是否支持选择确认对方也是不知道的，以及最大的数据部分的大小。
这些信息就是在握手的时候确定的：

1. 握手的前两次数据部分长度为0，第三次可能夹带数据
2. 双方确认交换信息：MSS（最大的数据部分长度，避免IP分片），是否支持SACK（选择确认），滑动窗口缩放系数等
3. 交换信息都存放在选项字段中

要注意，以上每一个报文都有可能丢失，丢失了怎么办？丢失只能重传。

第一次握手，当客户端与服务器建立TCP连接的时候，会有一个发SYN报文的动作，之后就会进入到SYN_SENT状态。

第一次握手丢失，当客户端未接收到 SYN-ACK 报文，此时将会触发超时重传机制，一般不同版本的操作系统设置的超时时间不同，且一般超时时间都会写死在内核中，修改也比较麻烦，一般超时时间设置有1秒、3秒等。

当客户端在1秒后未收到SYN-ACK 报文，客户端将会重新发起SYN报文的动作，在Linux里，一般客户端重传此时设置在5次，并且超时时间第一次是1秒，第二次会变成2秒，第三次会变成4秒，一直到第五次16秒，且每次超时时间是上次超时时间的2倍。

第五次超时重传后，系统会继续等待32秒，若还是没有回应，客户端将不会再重复发送SYN报文的动作，随之将断开TCP连接，结束。

可以从上文看出，从丢失到断开，用时也就1分钟左右，看来TCP也是很聪明，不会无限循环操作！

第二次握手，当第一次握手顺利完成后，将会向客户端回传SYN-ACK 报文，此时服务端进入SYN_RCVD 状态。

第二次握手丢失，首先是ACK，是对第一次握手的确认报文，如果客户端没有收到第二次握手，客户端以为第一次握手的SYN丢失，此时会启动重传机制。

其次SYN，是服务端发起建立TCP连接报文。当服务端没有收到第二次握手，服务端将会启动超时重传机制，重新传送SYN-ACK 报文（重传次数默认为5）。

第三次握手，ACK是对第二次握手的SYN确认报文，客户端将会进入ESTABLISHED状态。

第三次握手丢失，服务端将不会收到确认报文，此时将会触发超时重传机制，重新传送SYN-ACK 报文，直到第三次握手成功或者达到最大重传次数为止。

可见，服务器和客户端都会重传，且都有最大重传次数，在这样的保证下都连接不上，就会断开连接。

socket编程，每一步对应以上哪一个步骤？

socket编程步骤：

1. 服务器bind地址
2. 服务器listen
3. 客户端connect
4. 服务端accept
5. 交换数据

网上的步骤：
主要的就是listen，connect，accept三步，其实三次握手全部发生在connect中。
当客户端调用connect函数的时候，开始执行三次握手，执行完毕后将完成的连接扔进accept池里，accpet函数从完成连接的池子里取出一个连接而已。

unix网络编程卷1里的步骤：

1. 客户端调用connect，此时发送syn报文，同时connect阻塞；
2. 服务器阻塞在accept，收到syn报文，accept回复syn和ack报文，同时accept继续阻塞；
3. 客户端收到syn和ack报文，connect发送ack报文，connect返回；
4. 服务器收到ack报文，accept返回。

两次握手行不行？

2.校验和保证可靠传输：

主要是将数据切分成若干个16位的二进制串，将每个二进制串看成一个二进制数，对这些数进行相加等运算得到一个校验和，然后接收方收到数据会使用同样的算法来对数据计算校验和，如果结果和发送端发过来的校验和一样，那么就校验成功。主要是为了防止接收方收到的是已经损坏的数据。

3.连续ARQ协议，滑动窗口，选择性确认保证可靠传输

前面说了停止等待协议，就是发送一个报文，就等待一个ACK确认报文，一个TTL没等到，就重传，这样固然好，但是效率太低。
滑动窗口协议就是连续发送多个报文，这多个就是滑动窗口里的报文，然后服务端依次发送ACK（仍然是每个报文对应一个ack），滑动窗口每收到一个ack，就移动一个位置，就会再发送一个报文。

连续ARQ协议：一次把滑动窗口的都发出去，只需要收到一个ACK，就认为是整个窗口的报文全部收到了，窗口滑动整个长度。这样效率更高，ack是连续的报文中，不间断的最后一个报文，比如窗口发送了 1.2.3.4.5，如果这五个报文都收到了，那么服务端就回复 ack = 6，窗口就移动到6.7.8.9.10的位置（注意，未收到ack前，绝对不能滑动，否则数据就可能会丢失，因为一般只有前面有缓存，窗口后面的数据就直接丢了）；如果3号丢了（即使4，5收到了），那么就ack = 3，这样滑动窗口移动到3.4.5.6.7，再发送。
这样的一个缺点就是4.5会重复发送，这也是选择性确认出现的原因。

选择性确认SACK：3丢了，也会把4.5确认发回去，只重传3，不一定所有的版本都支持这个。

为什么在传输层就把数据分段，而不是等到网络层？

路由器是没有传输层的，所以路由器不会把IP包合并成报文看看是否还准确，只能确定当前包正确，如果最后到了目标主机，一合成发现错了？那怎么办？一连串的数据全部重传。所以在传输层就把该分的报文彻底分了，让IP确保每一个包正确，就相当于确定每一个小报文正确，最后在服务器那边，丢哪个重传哪个，排排序，就成了。

4.流量控制保证可靠性传输

接收方有接收的缓冲区，如果这个缓冲区满了，发送方还在不停的发送，就会导致有一些数据进不去缓冲区，那么就会被丢弃。导致丢包率上升。
保证可靠的方法就是每轮，两方都告知自己的滑动窗口的大小，这样对方发送数据的量就不会超过这个窗口的值。
报文每次传送的时候，都会带上自己的滑动窗口的大小，发送的窗口大小不能大于接收方的窗口大小。但是，有一个问题，如果接收方将窗口调整为0，那么发送方将不再发送数据，这个时候，如果接收方通知发送方调整窗口的报文丢了。发送方一直以为是0，就一直不发数据，就会陷入僵死状态。解决方法是，当窗口值为0的时候，就定时发报文去主动询问对方的窗口的值。

5.拥塞控制保证可靠性传输

流量控制是两个机器之间要做的事情，而拥塞控制是整个网络要做的事情，整个网络资源是大家共享的，大家要共同遵守网络阻塞处理原则。拥塞控制可以防止过多的数据注入到网络中，避免网络中的路由器或链路过载。
拥塞控制是一个全局的过程，涉及到所有的主机，路由器，以及与降低网络传输性能有关的所有因素，是大家共同努力的结果。

拥塞控制的方法：
慢开始，拥塞避免，快重传，快恢复。

几个名词：
MSS（maximum Segment Size）：每个段最大的数据部分大小，应确定刚好不在IP被分片。
cwnd：拥塞窗口
rwnd：接收窗口
swnd：发送窗口 = min(cwnd, rwnd)

慢开始：

这是没有连续ARQ协议的，一个报文一个应答。
总是发送窗口=拥塞窗口，拥塞窗口指数级增长。当达到慢开始门限值的时候，执行拥塞避免算法。

拥塞避免

拥塞避免使得拥塞窗口线性增大。
当出现丢包的时候，就认为是网络阻塞，执行乘法减小，将门限值设置为峰值的一半，然后重新慢开始。

快重传

ack可以放在自己的报文中，捎带过去，但是快重传要求：收到失序的分组就立即重复确认，让发送方及时知道有分组没有到达。而发送方只要收到三个重复确认，就立即重传对方尚未收到的失序的报文，而不等待重传计时器。

快恢复

快恢复取代以后的慢开始。

6.四次挥手

1.首先客户端给服务端发送一个FIN包，seq=J，客户端进入FIN_WAIT_1状态，代表客户端已经没有数据发送给服务端了。

2.服务端接收到FIN包之后，会给客户端发送一个ACK，ack=J+1，用于确认客户端-服务端这边的连接进行断开。同时会进入到CLOSE_WAIT状态，表示在等待关闭，因为服务端往客户端可能还在继续传输数据，暂时还不能断开。客户收到服务端返回的ACK回应后，会进入到FIN_WAIT_2状态，代表客户端-服务端的连接已经断开成功，等待服务端发送FIN包断开服务端-客户端的连接。

3.服务端发现没有数据发给客户端后，会发一个FIN包给客户端，并且进入LAST_ACK，代表等待客户端的ACK，一旦收到ACK，代表连接正式断开，服务端可以进入CLOSE状态。

4.客户端收到服务端发送的FIN包后，说明连接已经断开了，但是需要服务端知道，客户端会给服务端发送一个ACK包通知服务端，并且会进入TIME_WATING状态，代表超过超时时间后自动进入CLOSE状态，如果ACK包中途丢了，服务端会再发送FIN包，客户端会进行ACK包重发，这也是TIME_WAITING状态的意义之一，并且time_wait时间会清空本次挥手期间的所有报文，保证下一次连接进来，这一次挥手遗留的报文不会影响下一次握手，等待2msl，链路上肯定没有报文了。否则，如果直接关闭，而恰好有一个因阻塞晚到达的fin报文，下次握手，刚握手就收到了这个fin报文，那不就直接断开了？

close_wait太多怎么处理？

close_wait 主要在TCP四次挥手时，服务端给客户端返回ACK应答后，由于自身还需要给客户端传输数据，所以会进入到close_wait状态，直到不需要给客户端发数据了，才会去给客户端发送FIN包，同时进入LAST_ACK状态。(被动关闭的一方没有及时发出 FIN 包就会导致自己一直处于close_wait状态。)

tcp_keepalive_time默认是2个小时，也就是TCP空闲连接可以存活2个小时，在close_wait状态下，可以把这个时间调小，减少处于close_wait连接的数量

time_wait太多是怎么造成的？

在高并发短连接的TCP服务器上，当服务器处理完请求后立刻主动正常关闭连接。这个场景下会出现大量socket处于TIME_WAIT状态。如果客户端的并发量持续很高，此时部分客户端就会显示连接不上。
我来解释下这个场景。主动正常关闭TCP连接，都会出现TIMEWAIT。

为什么我们要关注这个高并发短连接呢？有两个方面需要注意：

1. 高并发可以让服务器在短时间范围内同时占用大量端口，而端口有个0~65535的范围，并不是很多，刨除系统和其他服务要用的，剩下的就更少了。
2. 在这个场景中，短连接表示“业务处理+传输数据的时间 远远小于 TIMEWAIT超时的时间”的连接。

这里有个相对长短的概念，比如取一个web页面，1秒钟的http短连接处理完业务，在关闭连接之后，这个业务用过的端口会停留在TIMEWAIT状态几分钟，而这几分钟，其他HTTP请求来临的时候是无法占用此端口的(占着茅坑不拉翔)。

单用这个业务计算服务器的利用率会发现，服务器干正经事的时间和端口（资源）被挂着无法被使用的时间的比例是 1：几百，服务器资源严重浪费。（说个题外话，从这个意义出发来考虑服务器性能调优的话，长连接业务的服务就不需要考虑TIMEWAIT状态。同时，假如你对服务器业务场景非常熟悉，你会发现，在实际业务场景中，一般长连接对应的业务的并发量并不会很高。

综合这两个方面，持续的到达一定量的高并发短连接，会使服务器因端口资源不足而拒绝为一部分客户服务。同时，这些端口都是服务器临时分配，无法用SO_REUSEADDR选项解决这个问题。

应用层

超文本传输协议：HTTP，HTTPS
文件传输协议：FTP
电子邮件：SMTP，POP3，IMAP
动态主机分配：DHCP
域名系统：DNS

DNS协议：

通过域名，解析出IP地址。
一般来讲，通过域名找IP地址，是先看浏览器的本地缓存，没有的话，就拿着DNS去DNS服务器（这个服务器IP地址是众所周知的，这种服务器有多个），去解析IP地址。

查看DNS缓存
ipconfig /displaydns ： 查看
ipconfig /flushdns：清空

Linux里要使用dns管理程序。

HTTP

http1.0：支持post，head方法，只支持短链接，不支持长连接。底层还是TCP，只不过浏览器的每次请求都需要建立一个TCP连接，处理完毕就断开。
http1.1：应用最广泛，支持长连接。

长短连接是相对而言的，处理完一个请求断开就是短链接，不断开就是长连接；长连接更节省时间。

HTTP的报文格式

http有两种主要的报文：请求报文和响应报文。

请求报文：
响应报文：

除状态行之外，首部行都是 键值对 的形式：key——value；
同理，根据不同的请求方法，可以确定不同的功能，根据不同的首部字段，也可以确定不同的功能。

笼统的报文格式：

请求方法：
get，head，post，put，delete，connect，options，trace

GET：
常用于读取的操作，请求参数直接拼接在URL的后面（浏览器对URL是有长度限制的)。

POST：
常用于添加、修改、删除的操作，请求参数可以放到请求体中(没有大小限制)

HEAD：
请求得到与GET请求相同的响应，但没有响应体。
使用场景举例:在下载一个大文件前，先获取其大小，再决定是否要下载。以此可以节约带宽资源。

PUT：
用于对已存在的资源进行整体覆盖。

请求头字段：

响应头字段：



会话与cookie：

HTTP是无状态的，即这次连接和上次连接没有关系，而同一个客户不同时间可能会与服务器建立多次连接，怎么知道这些连接是同一个人的？

成功登陆之后，服务器会给客户一个cookie，这个cookie就是一小段文本，可以用来标识你就是你，然后服务器会为客户保存一个session（会话），之后它们的交流仅限于会话空间内。之后每次客户发送消息都会带着这个cookie，服务器收到cookie看看是不是有它的会话，有就正常交流，没有就报错。

cookie是保存在客户端的，session是保存在服务端的。

状态码：

缓存：

通常会缓存的情况是：GET请求 + 静态资源（HTML，JS，图片等）。

与缓存相关的响应头：

Cache-Control的默认值是public。

与缓存相关的请求头：

缓存的实用流程：

缓存的两种方式：强缓存和对比缓存

强缓存：

强缓缓存就是浏览器缓存数据库里有缓存数据就不再去向服务器发请求了

可以造成强制缓存的字段有Expires和Cache-Control两个：

Expires：该字段标识缓存到期时间，是一个绝对时间，也就是服务器时间+缓存有效时间。 缺点：如果客户端修改了本地时间，会造成缓存失效。如果本地时间与服务器时间不一致，也会导致缓存失效。

Cache-Control：该字段表示缓存最大有效时间，该时间是一个相对时间。 使用相对时间的话，即使本地时间与服务器时间不一致，也不会导致缓存失效。 下面列举一下Cache-Control的字段可以带的值：
max-age：即最大有效时间
no-cache：表示没有缓存，即告诉浏览器该资源并没有设置缓存
s-maxage：同max-age，但是仅用于共享缓存，如CDN缓存
public：多用户共享缓存，默认设置
private：不能够多用户共享，HTTP认证之后，字段会自动转换成private。

对比缓存：

对比缓存的实现原理时，先给给服务器发请求，并且带上缓存的资源文件的缓存标识，让服务端进行对比，如果资源文件没有更改，就只返回header部分，body为空，状态码是304，浏览器使用缓存的资源文件。如果数据有更改，就返回更新后的资源文件。

可以实现对比缓存的机制有Last-Modified/If-Modified-Since和Etag/If-None-Match两种：

Last-Modified/If-Modified-Since

就是 请求的response header中会返回Last-Modified字段，代表资源文件最近的修改时间，发请求时 request header中会带上If-Modified-Since字段，代表上次获取的资源文件的最近修改时间，服务器判断资源文件是否有更新，来决定返回最新的资源文件（返回200），还是让浏览器使用缓存(返回304)。

缺点：

Last-Modified标注的最后修改只能精确到秒级，如果某些文件在1秒钟以内，被修改多次的话，它将不能准确标注文件的修改时间。

如果某些文件会被定期生成，当有时内容并没有任何变化，但Last-Modified却改变了，导致文件没法使用缓存。

Etag/If-None-Match

就是 response header中会返回Etag，代表资源文件的版本号，发请求时 request header中会加上If-None-Match字段，值是上次请求的资源的文件的版本号，代表上次请求的资源文件的版本号，服务器判断资源文件是否有更新，来决定返回最新的资源文件（返回200），还是让浏览器使用缓存(返回304)。

优先级
优先级方面排序是 强缓存（Cache-Control）> 强缓存（Expires）> 对比缓存（Etag/If-None-Match）> 对比缓存（Last-Modified/If-Modified-Since）

HTTPS

超文本传输安全协议。

HTTPS是在HTTP的基础上使用了SSL/TLS来加密报文。

SSL/TLS是差不多一种协议：安全套接层/传输层安全协议。

SSL/TLS工作在会话层和表示层。

HTTPS的通信过程：

TLS的连接，细分可以分为十次握手…

对称加密

使用相同的密钥，进行加密，也进行解密。但是，只要使用对称加密，就一定会遇到密钥配送问题。

非对称加密

非对称加密可以解决密钥配送问题。

公钥加密，私钥解密

发送者生成 公钥和私钥，并把公钥发送出去，然后接收者用公钥把对称密钥加密，传回去，发送者用非对称私钥进行解密，得到对称加密的密钥。

非对称加密是可以用来通信的，那还有必要去送对称加密的密钥？直接用非对称加密通信不行吗？

非对称加密的成本很高，加密解密的速度很低，所以我们一般是用非对称配送密钥，用对称加密通信，这就是混合密码系统，就是https里面的s。

问题：公钥的合法性：证书
怎么知道你的公钥是你的，而不是攻击者的？

证书（公钥证书）：

这个证书里最起码有两个内容：你的信息和你的公钥，两者不可分离。
认证机构（CA）给这个人的信息和公钥进行一个数字签名，保证公钥属于此人。

先不看（2）注册，这里就涉及到数字签名，Alice把 Bob传来的信息和公钥 与 经过AC签名的 Bob的信息和公钥 做比对，如果正确，说明没有伪造，否则就是伪造，因为不管是ALice的AC公钥是伪造的，还是证书是伪造的，都不可能验证通过。

唯一不安全的就是（2）注册这条路，证书有一部分保存在自己的电脑上，有一些是出厂就认证的，还有一些其他的方法，可以默认这条路是安全的。

数字签名

数字签名是用来保证数据的可靠性的，即没有被篡改，而不是用来加密的。
涉及到签名密钥和验证密钥。一般是用消息发送者的私钥用来签名。

如果有人篡改了消息，签名就会验证失败。

数字签名不是为了保证机密性，仅仅是为了能够识别内容有没有被篡改。

作用：

1. 确认消息的完整性
2. 识别消息是否被篡改