计算机网络

博主刚考完计算机网络，基础知识就不废话了，来一个七层体系结构图(学习中大家一般用的都是五层体系)

1 七层网络结构图

图片来源：https://blog.csdn.net/yaopeng_2005/article/details/7064869

1.2 七层与五层协议对比

1.3 四层协议对应位置

2 TCP三次握手

2.1 TCP 三次握手漫画图解

如下图所示，下面的两个机器人通过3次握手确定了对方能正确接收和发送消息(图片来源：《图解HTTP》)。



seq：序号，占4个字节，范围[0,4284967296],由于TCP是面向字节流的，在一个1个TCP连接中传送字节流中国的每一个字节都按照顺序编号，此外序号是循环使用的

ACK： 仅当ACK=1时确认字段才有效，当ACK=0时确认字段无效，并且TCP规定，在连接建立后所有的传送报文段都必须要把ACK置为1

SYN：同步序列号，用来发起一个连接。当SYN=1而ACK=0时表明这是一个请求报文段；若对方同意连接，则响应报文中SYN=1，ACK=1

FIN ：用来释放一个连接，当FIN=1表示此报文段的发送方已经发送完毕。并要求释放链接

2.2 为什么要三次握手

三次握手的目的是建立可靠的通信信道，说到通讯，简单来说就是数据的发送与接收，而三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。

第一次握手：Client 什么都不能确认；Server 确认了对方发送正常，自己接收正常

第二次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：对方发送正常，自己接收正常

第三次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：自己发送、接收正常，对方发送、接收正常

如果你听说过红军蓝军通信的故事，你就会知道并没有办法保证百分百正确连接，所以三次握手就能确认双发收发功能都正常，如果改为四次握手、万次握手，也就是把99%变成99.99%，意义不大。

以下内容摘自https://networkengineering.stackexchange.com/questions/24068/why-do-we-need-a-3-way-handshake-why-not-just-2-way

将握手分解为实际操作。

在TCP中，双方通过使用序列号来跟踪发送的内容。实际上，它最终是发送的所有内容的运行字节数。接收方可以使用对方讲话者的序列号来确认接收到的内容。

但是序列号不是从0开始。它从ISN（初始序列号）开始，它是一个随机选择的值。由于TCP是双向通信，因此双方都可以“讲话”，因此双方都必须随机生成一个ISN作为其起始序列号。反过来，这意味着双方都需要将其开始的ISN通知另一方。

因此，您以以下事件序列结束，开始了Alice和Bob之间的TCP对话：

Alice ---> Bob    SYNchronize with my Initial Sequence Number of X
Alice <--- Bob    I received your syn, I ACKnowledge that I am ready for [X+1]
Alice <--- Bob    SYNchronize with my Initial Sequence Number of Y
Alice ---> Bob    I received your syn, I ACKnowledge that I am ready for [Y+1]

注意，正在发生四个事件：

• Alice picks an ISN and SYNchronizes it with Bob.
• Bob ACKnowledges the ISN.
• Bob picks an ISN and SYNchronizes it with Alice.
• Alice ACKnowledges the ISN.

实际上，中间的两个事件（＃2和＃3）发生在同一数据包中。使数据包成为一个SYN或ACK仅仅是使每个TCP报头中的二进制标志处于打开或关闭状态的原因是什么，所以没有什么可以阻止在同一数据包上同时启用这两个标志。因此，三向握手最终为：

Bob <--- Alice     SYN
Bob ---> Alice     SYN ACK 
Bob <--- Alice     ACK  

因此，回到您的问题上，为什么不只是使用双向握手？简短的答案是因为双向握手只会允许一方建立ISN，而另一方承认它。这意味着只有一方可以发送数据。

但是TCP是双向通信协议，这意味着任何一端都应该能够可靠地发送数据。双方都需要建立一个ISN，并且双方都需要确认对方的ISN。

因此，实际上，您所拥有的只是双向握手的描述，但是在每个方向上。因此，发生了四个事件。同样，中间两个标志出现在同一数据包中。这样，三个数据包将包含在完整的TCP连接启动过程中。

2.3 为什么不能用两次握手进行连接

我们知道，3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号ISN进行协商，这个序列号在握手过程中被发送和确认。

如果只是两次握手， 至多只有连接发起方的起始序列号能被确认， 另一方选择的序列号则得不到确认

三次握手：

1. A 发送同步信号SYN + A’s ISN
2. B 确认收到A的同步信号，并记录 A’s ISN 到本地，命名 B’s ACK sequence number，B发送同步信号SYN + B’s Initial sequence number
3. A确认收到B的同步信号，并记录 B’s ISN 到本地，命名 A’s ACK sequence number

二次握手：

1. A 发送同步信号SYN + A’s ISN
2. B 确认收到A的同步信号，并记录 A’s ISN 到本地，命名 B’s ACK sequence number，B发送同步信号SYN + B’s Initial sequence number

这里有一个问题，A与B就A的初始序列号达成了一致，但是B无法知道A是否已经接收到自己的同步信号，如果这个同步信号丢失了，A和B就B的初始序列号将无法达成一致。

谢希仁版《计算机网络》中的例子是这样的，“已失效的连接请求报文段” 的产生在这样一种情况下：client 发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达 server。本来这是一个早已失效的报文段。但 server 收到此失效的连接请求报文段后，就误认为是 client 再次发出的一个新的连接请求。于是就向 client 发出确认报文段，同意建立连接。假设不采用 “三次握手”，那么只要 server 发出确认，新的连接就建立了。由于现在 client 并没有发出建立连接的请求，因此不会理睬 server 的确认，也不会向 server 发送数据。但 server 却以为新的运输连接已经建立，并一直等待 client 发来数据。这样，server 的很多资源就白白浪费掉了。采用 “三次握手” 的办法可以防止上述现象发生。例如刚才那种情况，client 不会向 server 的确认发出确认。server 由于收不到确认，就知道 client 并没有要求建立连接。”

2.4 为什么要传回 SYN

接收端传回发送端所发送的 SYN 是为了告诉发送端，我接收到的信息确实就是你所发送的信号了。

SYN 是 TCP/IP 建立连接时使用的握手信号。在客户机和服务器之间建立正常的 TCP 网络连接时，客户机首先发出一个 SYN 消息，服务器使用 SYN-ACK 应答表示接收到了这个消息，最后客户机再以 ACK(Acknowledgement[汉译：确认字符 ,在数据通信传输中，接收站发给发送站的一种传输控制字符。它表示确认发来的数据已经接受无误。 ]）消息响应。这样在客户机和服务器之间才能建立起可靠的TCP连接，数据才可以在客户机和服务器之间传递。

2.5 传了 SYN,为啥还要传 ACK

双方通信无误必须是两者互相发送信息都无误。传了 SYN，证明发送方到接收方的通道没有问题，但是接收方到发送方的通道还需要 ACK 信号来进行验证。

2.6 TCP第三次握手失败怎么办？

Server端：
如果此时ACK在网络中丢失，那么Server端该TCP连接的状态为SYN_RECV，并且依次等待3秒、6秒、12秒后重新发送SYN+ACK包，以便Client重新发送ACK包。
如果重发指定次数后，仍然未收到ACK应答，那么一段时间后，Server自动关闭这个连接。

Client端：
但是Client认为这个连接已经建立，如果Client端向Server写数据，Server端将以RST包(用于强制关闭tcp连接)响应，方能感知到Server的错误。

2.7 三次握手有哪些缺陷

SYN Flood 攻击

SYN- Flood攻击是当前网络上最为常见的DDoS攻击，也是最为经典的拒绝服务攻击，它就是利用了TCP协议实现上的一个缺陷，通过向网络服务所在端口发送大量 的伪造源地址的攻击报文，就可能造成目标服务器中的半开连接队列被占满，从而阻止其他合法用户进行访问。这种攻击早在1996年就被发现，但至今仍然显示 出强大的生命力。很多操作系统，甚至防火墙、路由器都无法有效地防御这种攻击，而且由于它可以方便地伪造源地址，追查起来非常困难。它的数据包特征通常 是，源发送了大量的SYN包，并且缺少三次握手的最后一步握手ACK回复。
原理：攻击者首先伪造地址对 服务器发起SYN请求，服务器回应(SYN+ACK)包，而真实的IP会认为，我没有发送请求，不作回应。服务 器没有收到回应，这样的话，服务器不知 道(SYN+ACK)是否发送成功，默认情况下会重试5次（tcp_syn_retries）。这样的话，对于服务器的内存，带宽都有很大的消耗。攻击者 如果处于公网，可以伪造IP的话，对于服务器就很难根据IP来判断攻击者，给防护带来很大的困难。
————————————————
版权声明：本文为CSDN博主「silentsharer」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/hacker00011000/article/details/52319111

3 TCP 四次挥手

第一次挥手：Client不再说话了，挥手(fin)
第二次挥手：Server伤感地微笑(ack)，如果有话要说继续说话
第三次挥手：Server不再说话了，挥手(fin)
第四次挥手：Client伤感地微笑(ack)

第一次挥手之后，Server进入关闭等待状态，也就是单向关闭。Client已经挥了手，可是人还没有走，只是不再说话，但是耳朵还是可以继续听，Server呢继续喊话。等待Server累了，也不再说话了，超Client挥了挥手，Client伤感地微笑了一下，才彻底结束了。

• 客户端-发送一个 FIN，用来关闭客户端到服务器的数据传送
• 服务器-收到这个 FIN，它发回一 个 ACK，确认序号为收到的序号加1 。和 SYN 一样，一个 FIN 将占用一个序号
• 服务器-关闭与客户端的连接，发送一个FIN给客户端
• 客户端-发回 ACK 报文确认，并将确认序号设置为收到序号加1

3.1 为什么要四次挥手

任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候，则发出连接释放通知，对方确认后就完全关闭了TCP连接。

举个例子：A 和 B 打电话，通话即将结束后，A 说“我没啥要说的了”，B回答“我知道了”，但是 B 可能还会有要说的话，A 不能要求 B 跟着自己的节奏结束通话，于是 B 可能又巴拉巴拉说了一通，最后 B 说“我说完了”，A 回答“知道了”，这样通话才算结束。

4 TCP与UDP 协议的区别（常问）

UDP 在传送数据之前不需要先建立连接，远地主机在收到 UDP 报文后，不需要给出任何确认。虽然 UDP 不提供可靠交付，但在某些情况下 UDP 确是一种最有效的工作方式（一般用于即时通信），比如： QQ 语音、 QQ 视频 、直播等等

TCP 提供面向连接的服务。在传送数据之前必须先建立连接，数据传送结束后要释放连接。 TCP 不提供广播或多播服务。由于 TCP 要提供可靠的，面向连接的传输服务（TCP的可靠体现在TCP在传递数据之前，会有三次握手来建立连接，而且在数据传递时，有确认、窗口、重传、拥塞控制机制，在数据传完后，还会断开连接用来节约系统资源），这一难以避免增加了许多开销，如确认，流量控制，计时器以及连接管理等。这不仅使协议数据单元的首部增大很多，还要占用许多处理机资源。TCP 一般用于文件传输、发送和接收邮件、远程登录等场景。

5 TCP 协议如何保证可靠传输

1. 应用数据被分割成 TCP 认为最适合发送的数据块。
2. TCP 给发送的每一个包进行编号，接收方对数据包进行排序，把有序数据传送给应用层。
3. 校验和： TCP 将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP 将丢弃这个报文段和不确认收到此报文段。
4. TCP 的接收端会丢弃重复的数据。
5. 流量控制： TCP 连接的每一方都有固定大小的缓冲空间，TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。TCP 使用的流量控制协议是可变大小的滑动窗口协议。 （TCP 利用滑动窗口实现流量控制）
6. 拥塞控制： 当网络拥塞时，减少数据的发送。（慢开始、拥塞避免、快重传、快恢复）
7. ARQ协议（自动重传请求）： 也是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组。
8. 超时重传： 当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。

这一块知识点很多，但我不想写

6 如何实现UDP的可靠传输

运输层无法保证数据的可靠传输，只能通过应用层来实现了。实现的方式可以参照tcp可靠性传输的方式，只是实现不在传输层，实现转移到了应用层。

最简单的方式是在应用层模仿传输层TCP的可靠性传输。下面不考虑拥塞处理，可靠UDP的简单设计。

1. 应答确认，添加seq/ack机制，确保数据发送到对端
2. 有序接受 ，添加包序号
3. 添加超时重传机制。

详细说明：送端发送数据时，生成一个随机seq=x，然后每一片按照数据大小分配seq。数据到达接收端后接收端放入缓存，并发送一个ack=x的包，表示对方已经收到了数据。发送端收到了ack包后，删除缓冲区对应的数据。时间到后，定时任务检查是否需要重传数据。

目前有如下开源程序利用udp实现了可靠的数据传输。分别为RUDP、RTP、UDT。

参考文章：UDP如何实现可靠传输

7 TCP协议存在那些缺陷

TCP不知道为什么会丢包
TCP流控算法的关键，是基于丢包，有否丢包是唯一的判断依据，是加油门还是踩刹车。
但TCP由于对网络了解的很片面，无法分辨丢包是什么原因造成的
1）网络真的拥堵而丢包
2）线路质量差CRC校验失败丢、或信号干扰丢
3）IP包乱序而引起的误判
只有情况1是需要踩刹车的，而情况2、3并不需要。关于这个已经有很多改进的算法了，比如BBR。

8 在浏览器中输入url地址发生了什么（太常问了）

总体来说分为以下几个过程:

1. DNS解析
2. TCP连接
3. 发送HTTP请求
4. 服务器处理请求并返回HTTP报文
5. 浏览器解析渲染页面
6. 连接结束

具体看这个：https://segmentfault.com/a/1190000006879700
详细的：浏览器输入 URL 后发生了什么？——知乎

9 列举常见的http请求头和响应头及其作用：

—请求头—
Accept：用于高速服务器，客户机支持的数据类型
Accept-Charset：用于告诉服务器，客户机采用的编码格式
Accept-Encoding：用于告诉服务器，客户机支持的数据压缩格式
Accept-Language：客户机的语言环境
Host：客户机通过这个头高速服务器，想访问的主机名
If-Modified-Since：客户机通过这个头告诉服务器，资源的缓存时间
Referer：客户机通过这个头告诉服务器，它是从哪个资源来访问服务器的（防盗链）
User-Agent：客户机通过这个头告诉服务器，客户机的软件环境
Cookie：客户机通过这个头可以向服务器带数据
Connection：处理完这次请求后是否断开连接还是继续保持连接
Date：当前时间值
—响应头—
Location：这个头配合302状态码使用，用于告诉客户找谁。
Server：服务器通过这个头告诉浏览器服务器的类型。
Content-Encoding：服务器通过这个头告诉浏览器数据的压缩格式。
Content-Length：服务器通过这个头告诉浏览器回送数据的长度
Content-Type：服务器通过这个头告诉浏览器回送数据的类型
Last-Modified：告诉浏览器当前资源的最后缓存时间
Refresh：告诉浏览器隔多久刷新一次
Content-Disposition：告诉浏览器以下载方式打开数据
Transfer-Encoding：告诉浏览器数据的传送格式
ETag：缓存相关的头
Expires：告诉浏览器把回送的资源缓存多长时间 -1或0则是不缓存
Cache-Control：no-cache
Pragma：no-cache

10 状态码

11 各种协议与HTTP协议之间的关系

一般面试官会通过这样的问题来考察你对计算机网络知识体系的理解。

图片来源：《图解HTTP》

12 HTTP与HTTPS的区别

12.1 什么是HTTP？

HTTP代表超文本传输​​协议。当您在http://后的地址栏中输入内容时，它会告诉浏览器通过HTTP连接。HTTP通常通过端口80使用TCP（传输控制协议）在Web上发送和接收数据包。简而言之，它是客户端和服务器使用的协议，允许您与其他网站进行通信。客户端向托管网站的HTTP服务器（在TCP握手之后）发送请求消息，然后该服务器用响应消息进行回复。响应消息包含完成状态信息，例如“ HTTP / 1.1 200 OK”。

Http报文

HTTP有两种报文：请求报文和响应报文，具体介绍如下

请求报文

响应报文

详细可见：http报文详解

HTTP/1.0与HTTP/1.1

在HTTP/1.0中默认使用短连接。也就是说，客户端和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接。当客户端浏览器访问的某个HTML或其他类型的Web页中包含有其他的Web资源（如JavaScript文件、图像文件、CSS文件等），每遇到这样一个Web资源，浏览器就会重新建立一个HTTP会话。

而从HTTP/1.1起，默认使用长连接，用以保持连接特性。在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现长连接需要客户端和服务端都支持长连接。

HTTP协议的长连接和短连接，实质上是TCP协议的长连接和短连接。
关于长连接与短连接的详细部分可以看：https://www.cnblogs.com/gotodsp/p/6366163.html

12.2 什么是HTTPS？

HTTPS代表安全的超文本传输​​协议（也称为TLS上的HTTP或SSL上的HTTP）。当您https://在域前面的地址栏中输入内容时，它会告诉浏览器通过HTTPS连接。通常，运行在HTTPS上的站点将具有适当的重定向，因此即使您键入http://它也将重定向以通过安全连接进行传递。HTTPS还使用TCP（传输控制协议）来发送和接收数据包，但是它是通过端口443（在由传输层安全性（TLS）加密的连接）中进行的。

12.3 HTTPS流程

HTTPS比HTTP多了一道SSL/TSL连接，保证安全性。

在建立TCP连接后，如果客户端此前未与服务器建立会话，那么双方需要进行一次完整的 TLS 四次握手。之后才能发送 HTTP 请求。

12.3 HTTP与HTTPS的区别

HTTP和HTTPS之间的主要区别在于SSL证书。在HTTPS上加载的站点使用SSL证书以加密状态发送和接收信息。在HTTP上，数据以文本格式发送，任何人都可以轻松读取。HTTPS还可以改善站点的SEO。
虽然SSL（安全套接字层）已更新为TLS（传输层安全性），但Web社区可互换使用TLS和SSL，以至于它们已成为同义词。

1. HTTP是不安全的，而HTTPS是安全的。
2. HTTP通过端口80发送数据，而HTTPS使用端口443。
3. HTTP运行在TCP之上，而HTTPS运行在SSL/TLS之上。
4. HTTP不需要SSL证书，对于HTTPS，要求您具有SSL证书并且由CA签名。
5. HTTP不需要域验证，而HTTPS至少需要域验证，而某些证书甚至需要法律文档验证。
6. HTTP中未加密，使用HTTPS之前，数据已加密。

12.4 HTTPS是如何使用TLS加密的

对称加密

所谓对称加密，就是它们在编码时使用的密钥e和解码时一样。

对称加解密的过程如下：

发送端和接收端首先要共享相同的密钥k(即通信前双方都需要知道对应的密钥)才能进行通信。发送端用共享密钥k对明文p进行加密，得到密文c，并将得到的密文发送给接收端，接收端收到密文后，并用其相同的共享密钥k对密文进行解密，得出明文p。

一般加密和解密的算法是公开的，需要保持隐秘的是密钥k，流行的对称加密算法有：DES，Triple-DES，RC2和RC4。

对称加密的不足：

1. 发送方和接收方首先需要共享相同的密钥，即存在密钥k的分发问题，如何安全的把共享密钥在双方进行分享，这本身也是一个如何安全通信的问题，一种方法是提前双方约定好，不通过具体的通信进行协商，避免被监听和截获。另外一种方式，将是下面我们介绍的通过非对称加密信道进行对称密码的分发和共享，即混合加密系统。

2. 密钥管理的复杂度问题。由于对称加密的密钥是一对一的使用方式，若一方要跟n方通信，则需要维护n对密钥。

对称加密的好处：

加密和解密的速度要比非对称加密快很多，因此常用非对称加密建立的安全信道进行共享密钥的分享，完成后，具体的加解密则使用对称加密。即混合加密系统。

另外一个点需要重点说明的是，密钥k的长度对解密破解的难度有很重大的影响，k的长度越长，对应的密码空间就越大，遭到暴力破解或者词典破解的难度就更大，就更加安全。

非对称加密(RSA)

所谓非对称加密技术是指加密的密钥e和解密的密钥d是不同的（e!=d），并且加密的密钥e是公开的，叫做公钥，而解密的密钥d是保密的，叫私钥。

非对称加解密的过程如下：

甲方生成一对密钥并将公钥公开，需要向甲方发送信息的其他角色(乙方)使用该密钥(甲方的公钥)对机密信息进行加密后再发送给甲方；甲方再用自己私钥对加密后的信息进行解密。甲方想要回复乙方时正好相反，使用乙方的公钥对数据进行加密，同理，乙方使用自己的私钥来进行解密。

常用的非对称加密算法有：RSA

非对称加密的优点是：

1，不存在密钥分发的问题，解码方可以自己生成密钥对，一个做私钥存起来，另外一个作为公钥进行发布。

2，解决了密钥管理的复杂度问题，多个加密方都可以使用一个已知的公钥进行加密，但只有拥有私钥的一方才能解密。

非对称加密不足：

加解密的速度没有对称加密快。

综上，分析了对称加密和非对称加密各自的优缺点后，有没有一种办法是可以利用两者的优点但避开对应的缺点呢？答应是有的，实际上用得最多的是混合加密系统，比如在两个节点间通过便捷的公开密码加密技术建立起安全通信，然后再用安全的通信产生并发送临时的随机对称密钥，通过更快的对称加密技术对剩余的数据进行加密。

HTTPS是如何加密的

客户端生成一个对称加密算法的密钥， 用非对称加密的方式安全发给服务端， 随后就不用非对称加密了。 只用这个密钥，利用对称加密算法来通信，这样即可以保证安全又可以加快速度。【也就是只利用RSA传输密钥，保证密钥的安全。然后利用对称加密进行信息传输。】

HTTPS相比HTTP，在请求前多了一个「握手」的环节。在握手时，你和你想访问的网站会交换一个密钥，就是非对称加密的密钥。握手完成后，你的请求先用密钥加密才会发出去，网站服务器的响应会先用密钥加密再传给你。由于整条链路上的节点拿到的数据都是加密过的，所以他们即无法分析出源数据的内容，也无法篡改这个加密过的数据（如果一个节点篡改了加密后的数据，你和服务器都没办法用密钥解密出来，会认为数据是无效的）。

总的来说，握手过程中，服务器会发出一张证书（带着公钥），客户端用公钥加密了一段较短的数据S，并返回给服务器。服务器用私钥解开，拿到S。此时，握手步骤完成，S成为了一个被安全传输到对方手中的对称加密密钥。此后，服务器与我的请求响应，只需要用S作为密钥进行一次对称的加密就好。

证书体系

使用对称加密和非对称加密，我们的HTTPS协议就一定安全了吗？
考虑下这种情况

• 你和服务器之间有一台邪恶的路由器M
• 当你给HTTPS网站的服务器发请求后，网站带着公钥P响应你
• 响应到达路由器M，M拿到了公钥P，但是并不把它交给你，而是自己伪造了一对公私钥MP和MS，并把MP给你
• 你拿到MP，以为是网站的公钥P，用它加密了S，再请求网站
• 请求到达M，M使用MS解开S，再用P加密S交给网站

没错，就这样，邪恶路由器得到了S。至此你和网站的通信不再安全。

中间人能劫持成功的本质，还是因为链路是不安全的。所以没有被加密的握手过程一定会有这个问题。

而目前我们解决问题的思路，却是放在了公钥发放上，暂时绕开了这个问题。这就是证书体系（也是为什么你要去找证书签发机构花钱购买证书的原因）。

简单来说，一个HTTPS网站响应给我们的并不是一个公钥，而是证书。证书上包含了公钥，还包含了域名、签发机构、有效期、签名等等。

那证书的安全性怎么保证？为什么中间人不能做一个假证书？

因为这套证书体系已经根植于每一个操作系统里了。每一个操作系统里，都内置了数十张根证书，每个根证书都对应一个非常权威的证书签发机构。这些根证书上记录了各个机构的公钥。

当网站找证书机构购买了一份合法的证书时，网站申请的证书上的公钥、域名、有效期等信息会被计算一次hash，然后证书机构用它的私钥给这个hash加密一次。这个加密结果就是证书的签名。

当网站的合法HTTPS证书到达你的电脑上，这个证书上带有签发机构的信息（具体来说应该是一条证书链），你的浏览器会用这个签发机构对应的操作系统内置根证书上的公钥，去解开网站HTTPS证书的签名（还记得吗，由于运算结果有周期性，所以用私钥加密的信息可以用公钥解开）。发现签名解开的hash与证书信息内容的hash一致，就可以证明证书是合法的了。

那中间人能不能申请一个真的证书然后去做劫持呢？

通常来说，证书签发机构的审核非常严格，如果无法证明www.zhihu.com这个域名属于他，签发机构是不会给他签发一个知乎域名的证书的。而如果中间人用了其他域名的证书，浏览器会发现你请求的域名和返回的证书不一致，从而拒绝继续请求。除非你一定要点下面的「仍然继续」：

最后无奈地说，在破解了这么多数学上的难题后，HTTPS的安全性仍然保证在『证书签发机构一定都是很有良心的』这种脆弱的基础上。

SSL协议通信过程

(1) 浏览器发送一个连接请求给服务器;服务器将自己的证书(包含服务器公钥S_PuKey)、对称加密算法种类及其他相关信息返回客户端;

(2) 客户端浏览器检查服务器传送到CA证书是否由自己信赖的CA中心签发。若是，执行4步;否则，给客户一个警告信息：询问是否继续访问。

(3) 客户端浏览器比较证书里的信息，如证书有效期、服务器域名和公钥S_PK，与服务器传回的信息是否一致，如果一致，则浏览器完成对服务器的身份认证。

(4) 服务器要求客户端发送客户端证书(包含客户端公钥C_PuKey)、支持的对称加密方案及其他相关信息。收到后，服务器进行相同的身份认证，若没有通过验证，则拒绝连接;

(5) 服务器根据客户端浏览器发送到密码种类，选择一种加密程度最高的方案，用客户端公钥C_PuKey加密后通知到浏览器;

(6) 客户端通过私钥C_PrKey解密后，得知服务器选择的加密方案，并选择一个通话密钥key，接着用服务器公钥S_PuKey加密后发送给服务器;

(7) 服务器接收到的浏览器传送到消息，用私钥S_PrKey解密，获得通话密钥key。

(8) 接下来的数据传输都使用该对称密钥key进行加密。

上面所述的是双向认证 SSL 协议的具体通讯过程，服务器和用户双方必须都有证书。由此可见，SSL协议是通过非对称密钥机制保证双方身份认证，并完成建立连接，在实际数据通信时通过对称密钥机制保障数据安全性

TLS

SSL大都不再使用，现在主要用TLS，但是一般情况下将二者写在一起TLS/SSL，我们可以将二者看做同一类协议，只不过TLS是SSL的升级版。

TLS：位于 HTTP 和 TCP 之间的协议，其内部有 TLS握手协议、TLS记录协议
HTTPS 经由 HTTP 进行通信，但利用 TLS 来保证安全，即 HTTPS = HTTP + TLS

TLS工作流程

此为服务端单向认证，还有客户端/服务端双向认证，流程类似，只不过客户端也有自己的证书，并发送给服务器进行验证

13 多进程多线程浏览器

浏览器的进程大概分为以下这几种：

1. 浏览器主进程(Browser进程)：控制chrome的地址栏，书签栏，返回和前进按钮，同时还有浏览器的不可见部分，例如网络请求和文件访问
2. 第三方插件进程：每种插件一个进程，插件运行时才会创建
3. 浏览器渲染进程（浏览器内核，内部是多线程的）：负责界面渲染，脚本执行，事件处理等
4. GPU进程：最多一个，用于3D绘制

同时，浏览器中的每一个frame框也都是一个独立的进程，因为浏览器的安全策略中，来自不同源的界面，在没有授权前不可以访问另一个界面的数据。同时给不同源的界面分配不同的进程可以有效的实现这一效果。

详细看：重学浏览器(1)-多进程多线程的浏览器

14 Post与Get的区别

简单一点讲，Get从服务器获取数据，Post用来向服务器提交数据。

• GET请求在URL中传送的参数是有长度限制的，而POST没有。

• GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。

• GET参数通过URL传递，POST放在Request body中。

• GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。

• GET请求只能进行url编码，而POST支持多种编码方式。

• GET请求会被浏览器主动cache，而POST不会，除非手动设置。

• GET产生的URL地址可以被Bookmark，而POST不可以。

• GET在浏览器回退时是无害的，而POST会再次提交请求。

但是，GET和POST是什么？HTTP协议中的两种发送请求的方法。HTTP是什么？HTTP是基于TCP/IP的关于数据如何在万维网中如何通信的协议。

HTTP的底层是TCP/IP。所以GET和POST的底层也是TCP/IP，也就是说，GET/POST都是TCP链接。GET和POST能做的事情是一样一样的。你要给GET加上request body，给POST带上url参数，技术上是完全行的通的。

详细可见：Get与Post的区别？（面试官最想听到的答案）

参考文章：

https://github.com/Snailclimb/JavaGuide/blob/master/docs/network/%E8%AE%A1%E7%AE%97%E6%9C%BA%E7%BD%91%E7%BB%9C.md
漫画：一招学会TCP的三次握手和四次挥手
TCP的三次握手与四次挥手（详解+动图）
非对称加密与HTTPS
HTTPS演化过程（对称加密、非对称加密、公钥、私钥、数字签名、数字证书）
https处理的一个过程，对称加密和非对称加密