计网复习
网络分层：OSI七层模型，TCP/IP四层模型和五层模型
应用层：为应用程序提供交互服务。在互联网中的应用层协议很多，如域名系统DNS、HTTP协议、SMTP协议等。
传输层：负责向两台主机进程之间的通信提供数据传输服务。传输层的协议主要有传输控制协议TCP和用户数据协议UDP。
网络层：选择合适的路由和交换结点，确保数据及时传送。主要包括IP协议。还有BGP、ICMP等协议。
链路层：在两个相邻节点之间传送数据时，数据链路层将网络层交下来的 IP 数据报组装成帧，在两个相邻节点间的链路上传送帧。
TCP
三次握手
- 第一次握手：客户端向服务端发起建立连接请求，客户端会随机生成一个起始序列号x，客户端向服务端发送的字段中包含标志位
SYN=1，序列号seq=x。第一次握手前客户端的状态为CLOSE，第一次握手后客户端的状态为SYN-SENT。此时服务端的状态为LISTEN。 - 第二次握手：服务端在收到客户端发来的报文后，会随机生成一个服务端的起始序列号y，然后给客户端回复一段报文，其中包括标志位
SYN=1，ACK=1，序列号seq=y，确认号ack=x+1。第二次握手前服务端的状态为LISTEN，第二次握手后服务端的状态为SYN-RCVD，此时客户端的状态为SYN-SENT。（其中SYN=1表示要和客户端建立一个连接，ACK=1表示确认序号有效） - 第三次握手：客户端收到服务端发来的报文后，会再向服务端发送报文，其中包含标志位
ACK=1，序列号seq=x+1，确认号ack=y+1。第三次握手前客户端的状态为SYN-SENT，第三次握手后客户端和服务端的状态都为ESTABLISHED。此时连接建立完成。
两次握手可以吗
第三次握手主要为了防止已失效的连接请求报文段突然又传输到了服务端，导致产生问题。
- 如果不采用三次握手，只要B发出确认，就建立新的连接了，此时A不会响应B的确认且不发送数据，则B一直等待A发送数据，浪费资源。
- 当A收到不是期望的
ACK时，就会发送RST报文是B返回LISTEN状态。
也就是说，在建立连接的过程中，只要收到的ACK不是期望的值，就发送RST报文。（RST的syn必须在窗口内才有效）
而在同步的状态中，收到滑动窗口外的序号或不能接受的序号，回复一个空报文，SYN为当前序列号，ACK为期望的下一个序列号。
四次挥手
TCP确保用户的所有数据都能够送达对方，在连接关闭之前。
第四次挥手为什么要等待2MSL？
为什么是四次挥手？
HTTP
POST和GET的区别？
GET请求参数通过URL传递，POST的参数放在请求体中。
GET产生一个TCP数据包；POST产生两个TCP数据包。对于GET方式的请求，浏览器会把请求头和请求体一并发送出去；而对于POST，浏览器先发送请求头，服务器响应100 continue，浏览器再发送请求体。
GET请求会被浏览器主动缓存，而POST不会，除非手动设置。
GET请求只能进行url编码，而POST支持多种编码方式。
GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。
HTTP1.1和 HTTP2.0的区别？
新的二进制格式：HTTP1.1 基于文本格式传输数据；HTTP2.0采用二进制格式传输数据，解析更高效。
在应用层（HTTP）和传输层（TCP）之间增加一个二进制分帧层。
多路复用：在一个连接里，允许同时发送多个请求或响应，并且这些请求或响应能够并行的传输而不被阻塞，避免 HTTP1.1 出现的”队头堵塞”问题。
一个request对应一个stream并分配一个id，这样一个连接上可以有多个stream，每个stream的frame可以随机的混杂在一起，接收方可以根据stream id将frame再归属到各自不同的request里面。
头部压缩，HTTP1.1的header带有大量信息，而且每次都要重复发送；HTTP2.0 把header从数据中分离，并封装成头帧和数据帧，使用特定算法压缩头帧，有效减少头信息大小。并且HTTP2.0在客户端和服务器端记录了之前发送的键值对，对于相同的数据，不会重复发送。比如请求a发送了所有的头信息字段，请求b则只需要发送差异数据，这样可以减少冗余数据，降低开销。
TCP有slow start的特性，三次握手之后开始发送tcp segment，第一次能发送的没有被ack的segment数量是由
initial tcp window大小决定的。这个initial tcp window根据平台的实现会有差异，但一般是2个segment或者是4k的大小（一个segment大概是1500个字节），也就是说当你发送的包大小超过这个值的时候，要等前面的包被ack之后才能发送后续的包，显然这种情况下延迟更高。intial window也并不是越大越好，太大会导致网络节点的阻塞，丢包率就会增加。http的header现在膨胀到有可能会超过这个intial window的值了，所以更显得压缩header的重要性。
服务端推送：HTTP2.0允许服务器向客户端推送资源，无需客户端发送请求到服务器获取。
HTTPS原理
- client向server发送请求，然后连接到server的443端口，发送的信息主要是随机值1和客户端支持的加密算法。
- server接收到信息之后给予client响应握手信息，包括随机值2和匹配好的协商加密算法，这个加密算法一定是client发送给server加密算法的子集。
- 随即server给client发送第二个响应报文是数字证书。服务端必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面，这套证书其实就是一对公钥和私钥。传送证书，这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间、服务端的公钥，第三方证书认证机构(CA)的签名，服务端的域名信息等内容。
- 客户端解析证书，这部分工作是由客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随即值（预主秘钥）。
- 客户端认证证书通过之后，接下来是通过随机值1、随机值2和预主秘钥组装会话秘钥。然后通过证书的公钥加密会话秘钥。
- 传送加密信息，这部分传送的是用证书加密后的会话秘钥，目的就是让服务端使用秘钥解密得到随机值1、随机值2和预主秘钥。
- 服务端解密得到随机值1、随机值2和预主秘钥，然后组装会话秘钥，跟客户端会话秘钥相同。
客户端通过会话秘钥加密一条消息发送给服务端，主要验证服务端是否正常接受客户端加密的消息。 - 同样服务端也会通过会话秘钥加密一条消息回传给客户端，如果客户端能够正常接受的话表明SSL层连接建立完成了。
加密原理
由公钥加密的内容，只能由私钥进行解密。
公钥密码体制的公钥和算法都是公开的，私钥是保密的。在实际的使用中，有需要的人会生成一对公钥和私钥，把公钥发布出去给别人使用，自己保留私钥。
(2) RSA加密算法
一种公钥密码体制，公钥公开，私钥保密，它的加密解密算法是公开的。 RSA的这一对公钥、私钥都可以用来加密和解密，并且一方加密的内容可以由并且只能由对方进行解密。
(3) 签名
就是在信息的后面再加上一段内容，可以证明信息没有被修改过。
一般是对信息做一个hash计算得到一个hash值（该过程不可逆），在把信息发送出去时，把这个hash值加密后做为一个签名和信息一起发出去。 接收方在收到信息后，会重新计算信息的hash值，并和信息所附带的hash值(解密后)进行对比，如果一致，就说明信息的内容没有被修改过，因为这里hash计算可以保证不同的内容一定会得到不同的hash值，所以只要内容一被修改，根据信息内容计算的hash值就会变化。
当然，不怀好意的人也可以修改信息内容的同时也修改hash值，从而让它们可以相匹配，为了防止这种情况，hash值一般都会加密后(也就是签名)再和信息一起发送，以保证这个hash值不被修改。
如何确定公钥是服务器的？
数字证书，一个证书包含下面的具体内容：
证书的发布机构
发布证书的机构，指明证书是哪个公司创建的（并不是指使用证书的公司）。出了问题具体的颁发机构是要负责的
证书的有效期
证书的使用期限。过了这个期限证书就会作废，不能使用。
证书所有者（Subject）
公钥
指纹和指纹算法
签名算法
指纹和指纹算法
这个是用来保证证书的完整性的，也就是说确保证书没有被修改过。 其原理就是在发布证书时，发布者根据指纹算法(一个hash算法)计算整个证书的hash值(指纹)并和证书放在一起，使用者在打开证书时，自己也根据指纹算法计算一下证书的hash值，如果和刚开始的值对得上，就说明证书没有被修改过，因为证书的内容被修改后，根据证书的内容计算的出的hash值(指纹)是会变化的。
因为由“服务器”用私钥加密后的内容，由并且只能由公钥进行解密，私钥只有“服务器”持有，所以如果解密出来的内容是能够对得上的，那说明信息一定是从“服务器”发过来的。
假设“黑客”想冒充“服务器”：
“黑客”->“客户”：你好，我是服务器
“客户”->“黑客”：向我证明你就是服务器
“黑客”->“客户”：你好，我是服务器 {你好，我是服务器}[？？？|RSA]
//这里黑客无法冒充，因为他不知道私钥，无法用私钥加密某个字符串后发送给客户去验证。
RSA的两个作用
- 因为私钥只有“服务器”拥有，因此“客户”可以通过判断对方是否有私钥来判断对方是否是“服务器”。
- 客户端通过RSA的掩护，安全的和服务器商量好一个对称加密算法和密钥来保证后面通信过程内容的安全。
参考链接：
https://blog.csdn.net/xiaoming100001/article/details/81109617
https://blog.csdn.net/liuno0/article/details/100552564
