计算机网络杂七杂八
-
子网掩码：https://baike.baidu.com/item/%E5%AD%90%E7%BD%91%E6%8E%A9%E7%A0%81/100207?fr=aladdin
-
子网划分：https://baike.baidu.com/item/%E5%AD%90%E7%BD%91%E5%88%92%E5%88%86/5446046?fr=aladdin
vpn和代理：
OSI七层模型每一层干了什么：
-
物理层（二进制位=>光电信号）：实际上就是布线、光纤、网卡和其它用来把两台网络通信设备连接在一起的东西，物理层是将二进制位转换为光电信号传输
-
数据链路层（数据帧==>二进制位）：如果是讨论mac地址，交换机，网卡，驱动程序就是属于数据链路层，这一层主要是在通信实体间建立数据链路联接，传输的基本单位为“帧”（将网络层传输过来的数据封装成帧，具体可见：什么是数据帧），并为网络层提供差错控制和流量控制服务。
-
网络层（数据包==>数据帧）：讨论ip，路由等就是网络层的问题，网络层主要为数据在节点之间传输创建逻辑链路，通过路由选择算法为分组选择最佳路径，从而实现拥塞控制、网络互联等功能。也就是负责地址解析和路由
-
传输层：tcp，udp所在的层，主要负责端到端的通信，数据形式也是数据包，是高低层衔接的接口层
-
会话层：主要功能是负责维护两个节点之间的传输联接，确保点到点传输不中断，以及管理数据交换等功能；不参与具体的传输，它提供包括访问验证和会话管理在内的建立和维护应用之间通信的机制。如服务器验证用户登录便是由会话层完成的。数据形式是报文
-
表示层：表示层的主要功能是处理在两个通信系统中交换信息的表示方式，主要包括数据格式变化、数据加密与解密、数据压缩与解压等。
-
应用层：OSI模型中的最高层，是直接面向用户的一层，用户的通信内容要由应用进程解决，这就要求应用层采用不同的应用协议来解决不同类型的应用要求，并且保证这些不同类型的应用所采用的低层通信协议是一致的。
-
应用层、表示层和会话层可以视为应用层（高层），而剩余层则可视为数据流动层（底层）
浏览器输入url到返回结果，这中间发生了什么
-
URL解析：地址解析（字符编码等操作），HSTS，其他操作（安全检查，访问控制），检查浏览器缓存
-
DNS查询：浏览器缓存，操作系统缓存（host文件），路由器缓存，ISP DNS缓存，根域名服务器
-
tcp握手连接
-
发送http请求
-
服务器返回响应
-
浏览器解析资源并渲染
三次握手
-
首先客户端向服务端发送一个带有 SYN 标志，以及随机生成的序号 100(0 字节)的报文
-
服务端收到报文后返回一个报文(SYN200(0 字节)，ACk1001(字节+1))给客户端
-
客户端再次发送带有 ACk 标志 201(字节+)序号的报文给服务端
四次挥手
- 客户端发送带有 fin 标识的报文给服务端，请求通信关闭
- 服务端收到信息后，回复 ACK 答应关闭客户端通信(连接)请求
- 服务端发送带有 fin 标识的报文给客户端，也请求关闭通信
- 客户端回应 ack 给服务端，答应关闭服务端的通信(连接)请求
更多关于三次握手四次挥手可见：https://blog.csdn.net/u013227473/article/details/81530930。
为什么不能两次握手或者四次握手？
为什么是四次挥手，不是三次挥手？
-
因为挥手的确认收到断开连接和断开连接报文分两次发，为什么分两次，因为确认收到断开连接后，客户端还可以收数据，服务端数据还有可能没有发完，所以确认收到断开和断开报文不能一起发
四次挥手中第三次挥手，客户端为什么要等待2msl？
-
第一，保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。
第二，防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。
-
为什么是2msl而不是msl：**最后一个ack要在msl才能确认失效。而重传的包也要保证msl才能确认失效，确认收不到
http1.1和http2的区别
-
HTTP1.1基于文本解析，而HTTP2基于二进制解析，
-
HTTP1.1采用长连接，若干个请求排队串行化单线程处理，后面的请求等待前面请求的返回才能获得执行机会；而HTTP2采用多路复用，即连接共享，多个请求每个请求分配一个id，可以在同一连接并行
protocol buffers 是一种语言无关、平台无关、可扩展的序列化结构数据的方法，它可用于（数据）通信协议、数据存储等。protof是一种数据传输格式，比如json，xml，传输效率更高，适用于即时通讯系统，
Http 长连接、短连接、长轮询、短轮询、webSocket
https://blog.csdn.net/chenwiehuang/article/details/89930054
https和http
- https安全是因为基于ssl协议（介于tcp和应用层之间的协议，为数据提供安全支持）
- 记录协议：数据封装，压缩，加密
- 握手协议：，基于记录协议，主要是身份认证、协商加密算法、交换加密密钥
- ssl分单向认证和双向认证，单向只要是服务端有ca证书就ok了，但双向认证就是两边都要有ca，客户端也有ca证书（非常少，一般金融机构app可能需要，所以一般都是单向认证）
- ca包括ssl，ssl一般由ca机构颁发，也可以自签名，但不被认可，但也可以在客户端中添加密钥库
- 浏览器一般内置权威性ca证书和他的公钥，
- https连接流程（总共有三个密钥，一个服务端证书的公钥和私钥，一个对称密钥），注意服务器公钥和ca公钥是两个东西
ssl包括ssl记录协议和ssl握手协议
- 客户端的浏览器向服务器发送请求，并传送客户端SSL 协议的版本号，加密算法的种类，产生的随机数，以及其他服务器和客户端之间通讯所需要的各种信息。
- 服务器向客户端传送SSL 协议的版本号，加密算法的种类，随机数以及其他相关信息，同时服务器还将向客户端传送自己的证书。
-
客户端利用服务器传过来的信息验证服务器的合法性，服务器的合法性包括：证书是否过期，发行服务器证书的CA 是否可靠，发行者证书的公钥能否正确解开服务器证书的“发行者的数字签名”，服务器证书上的域名是否和服务器的实际域名相匹配。如果合法性验证没有通过，通讯将断开；如果合法性验证通过，将继续进行第四步。
-
用户端随机产生一个用于通讯的“对称密码”，然后用服务器的公钥（服务器的公钥从步骤②中的服务器的证书中获得）对其加密，然后将加密后的“预主密码”传给服务器。
-
如果服务器要求客户的身份认证（在握手过程中为可选），用户可以建立一个随机数然后对其进行数据签名，将这个含有签名的随机数和客户自己的证书以及加密过的“预主密码”一起传给服务器
-
如果服务器要求客户的身份认证，服务器必须检验客户证书和签名随机数的合法性，具体的合法性验证过程包括：客户的证书使用日期是否有效，为客户提供证书的CA 是否可靠，发行CA 的公钥能否正确解开客户证书的发行CA 的数字签名（双向验证），检查客户的证书是否在证书废止列表（CRL）中。检验如果没有通过，通讯立刻中断；如果验证通过，服务器将用自己的私钥解开加密的“预主密码”，然后执行一系列步骤来产生主通讯密码（客户端也将通过同样的方法产生相同的主通讯密码）。
- 服务器利用私钥解密加密后的“预主密码”。得到对称密码，后面就是通过对称密钥加密数据通讯了