计算机网络

TCP/IP的网络模型

TCP/IP模型是一系列网络协议的总称，这些协议的目的是使得计算机之间可以进行信息交换，

TCP/IP模型四层架构从下到上分别是链路层，网络层，传输层，应用层

• 链路层的作用是负责建立电路连接，是整个网络的物理基础，典型的协议包括以太网，ADSL等，

• 网络层负责分配地址和传送二进制数据，主要协议是IP协议，

• 传输层负责传送文本数据，主要协议是TCP

• 应用层负责传送各种最终形态的数据，是直接与用户信息打交道的层，主要协议是http，ftp等

HTTP

HTTP1.0

HTTP1.1

HTTP2

HTTP/2: HTTP/2是基于HTTPS的，HTTP/2相对于HTTP/1.x更专注于性能，相对于HTTP/1.x做了许多性能上的优化：二进制传输，多路复用，Heard压缩，服务器推送，安全

HTTPs

HTTPS协议是HTTP协议的安全版本，在HTTP协议和TCP协议之前添加了SSL/TSL协议，在TCP握手之后进行SSL/TSL握手。

HTTPS在传输数据之前需要客户端（浏览器）与服务端（网站）之间进行一次握手，在握手过程中将确立双方加密传输数据的密码信息。TLS/SSL协议是一套加密传输的协议，使用了非对称加密，对称加密以及HASH算法。
握手过程的简单描述如下：

1.浏览器将自己支持的一套加密规则发送给网站。

2.网站从中选出一组加密算法与HASH算法，并将自己的身份信息以证书的形式发回给浏览器。证书里面包含了网站地址，加密公钥，以及证书的颁发机构等信息。

3.获得网站证书之后浏览器要做以下工作：
a) 验证证书的合法性（颁发证书的机构是否合法，证书中包含的网站地址是否与正在访问的地址一致等），如果证书受信任，则浏览器栏里面会显示一个小锁头，否则会给出证书不受信的提示。
b) 如果证书受信任，或者是用户接受了不受信的证书，浏览器会生成一串随机数的密码，并用证书中提供的公钥加密。
c) 使用约定好的HASH计算握手消息，并使用生成的随机数对消息进行加密，最后将之前生成的所有信息发送给网站。

4.网站接收浏览器发来的数据之后要做以下的操作：
a) 使用自己的私钥将信息解密取出密码，使用密码解密浏览器发来的握手消息，并验证HASH是否与浏览器发来的一致。
b) 使用密码加密一段握手消息，发送给浏览器。

5.浏览器解密并计算握手消息的HASH，如果与服务端发来的HASH一致，此时握手过程结束，之后所有的通信数据将由之前浏览器生成的随机密码并利用对称加密算法进行加密。
这里浏览器与网站互相发送加密的握手消息并验证，目的是为了保证双方都获得了一致的密码，并且可以正常的加密解密数据，为后续真正数据的传输做一次测试。另外，HTTPS一般使用的加密与HASH算法如下：
非对称加密算法：RSA，DSA/DSS
对称加密算法：AES，RC4，3DES

GET和POST的区别

get参数通过url传递，post放在request body中。

get请求在url中传递的参数是有长度限制的，而post没有。

get比post更不安全，因为参数直接暴露在url中，所以不能用来传递敏感信息。

get请求只能进行url编码，而post支持多种编码方式

get请求会浏览器主动cache，而post支持多种编码方式。

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

GET和POST本质上就是TCP链接，并无差别。但是由于HTTP的规定和浏览器/服务器的限制，导致他们在应用过程中体现出一些不同。

GET产生一个TCP数据包；POST产生两个TCP数据包

HTTP状态码

200 OK 请求成功。一般用于GET与POST请求
301 Moved Permanently 永久移动。请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替
302 Found 临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有U
304 Not Modified 未修改。所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源
403 Forbidden 服务器理解请求客户端的请求，但是拒绝执行此请求
404 Not Found 服务器无法根据客户端的请求找到资源（网页）。通过此代码，网站设计人员可设置"您所请求的资源无法找到"的个性页面
500 Internal Server Error 服务器内部错误，无法完成请求
502 Bad Gateway 作为网关或者代理工作的服务器尝试执行请求时，从远程服务器接收到了一个无效的响应

cookie和session的区别，localstorage和sessionstorage的区别

Cookie和session都可用来存储用户信息，cookie存放于客户端，session存放于服务器端，因为cookie存放于客户端有可能被窃取，所以cookie一般用来存放不敏感的信息，比如用户设置的网站主题，敏感的信息用session存储，比如用户的登陆信息，session可以存放于文件，数据库，内存中都可以，cookie可以服务器端响应的时候设置，也可以客户端通过JS设置cookie会在请求时在http首部发送给客户端，cookie一般在客户端有大小限制，一般为4K，

生命周期：

Cookie：可设置失效时间，否则默认为关闭浏览器后失效
Localstorage:除非被手动清除，否则永久保存
Sessionstorage：仅在当前网页会话下有效，关闭页面或浏览器后就会被清除

存放数据：

Cookie：4k左右
Localstorage和sessionstorage：可以保存5M的信息

http请求：

Cookie：每次都会携带在http头中，如果使用cookie保存过多数据会带来性能问题
其他两个：仅在客户端即浏览器中保存，不参与和服务器的通信

易用性：

Cookie：需要程序员自己封装，原生的cookie接口不友好
其他两个：即可采用原生接口，亦可再次封装

应用场景：

从安全性来说，因为每次http请求都回携带cookie信息，这样子浪费了带宽，所以cookie应该尽可能的少用，此外cookie还需要指定作用域，不可以跨域调用，限制很多，但是用户识别用户登陆来说，cookie还是比storage好用，其他情况下可以用storage，localstorage可以用来在页面传递参数，sessionstorage可以用来保存一些临时的数据，防止用户刷新页面后丢失了一些参数，

在地址栏里输入一个URL,到这个页面呈现出来，中间会发生什么？

DNS解析，TCP连接，发送HTTP请求，服务器处理请求并返回HTTP报文，浏览器解析渲染页面，连接结束

输入url后，首先需要找到这个url域名的服务器ip,为了寻找这个ip，浏览器首先会寻找缓存，查看缓存中是否有记录，缓存的查找记录为：浏览器缓存-》系统缓存-》路由器缓存，缓存中没有则查找系统的hosts文件中是否有记录，如果没有则查询DNS服务器，
得到服务器的ip地址后，浏览器根据这个ip以及相应的端口号，构造一个http请求，这个请求报文会包括这次请求的信息，主要是请求方法，请求说明和请求附带的数据，并将这个http请求封装在一个tcp包中，
这个tcp包会依次经过传输层，网络层，数据链路层，物理层到达服务器，服务器解析这个请求来作出响应，返回相应的html给浏览器，
因为html是一个树形结构，浏览器根据这个html来构建DOM树，在dom树的构建过程中如果遇到JS脚本和外部JS连接，则会停止构建DOM树来执行和下载相应的代码，这会造成阻塞，这就是为什么推荐JS代码应该放在html代码的后面，
之后根据外部央视，内部央视，内联样式构建一个CSS对象模型树CSSOM树，构建完成后和DOM树合并为渲染树，这里主要做的是排除非视觉节点，比如script，meta标签和排除display为none的节点，
之后进行布局，布局主要是确定各个元素的位置和尺寸，之后是渲染页面，

因为html文件中会含有图片，视频，音频等资源，在解析DOM的过程中，遇到这些都会进行并行下载，浏览器对每个域的并行下载数量有一定的限制，一般是4-6个，当然
在这些所有的请求中我们还需要关注的就是缓存，缓存一般通过Cache-Control、Last-Modify、Expires等首部字段控制。 Cache-Control和Expires的区别在于Cache-Control使用相对时间，Expires使用的是基于服务器 端的绝对时间，因为存在时差问题，一般采用Cache-Control，在请求这些有设置了缓存的数据时，会先 查看是否过期，如果没有过期则直接使用本地缓存，过期则请求并在服务器校验文件是否修改，如果上一次 响应设置了ETag值会在这次请求的时候作为If-None-Match的值交给服务器校验，如果一致，继续校验 Last-Modified，没有设置ETag则直接验证Last-Modified，再决定是否返回304

token

TCP和UDP的区别

TCP和UDP之间的区别
OSI 和TCP/IP 模型在传输层定义两种传输协议：TCP（或传输控制协议）和UDP（或用户数据报协议）。

UDP 与TCP 的主要区别在于UDP 不一定提供可靠的数据传输。 事实上，该协议不能保证数据准确无误地到达目的地。

为什么TCP要进行四次挥手呢？

因为是双方彼此都建立了连接，因此双方都要释放自己的连接，A向B发出一个释放连接请求，他要释放链接表明不再向B发送数据了，此时B收到了A发送的释放链接请求之后，给A发送一个确认，A不能再向B发送数据了，它处于FIN-WAIT-2的状态，但是此时B还可以向A进行数据的传送。此时B向A 发送一个断开连接的请求，A收到之后给B发送一个确认。此时B关闭连接。A也关闭连接。

为什么要有TIME-WAIT这个状态呢，

这是因为有可能最后一次确认丢失，如果B此时继续向A发送一个我要断开连接的请求等待A发送确认，但此时A已经关闭连接了，那么B永远也关不掉了，所以我们要有TIME-WAIT这个状态。

当然TCP也并不是100%可靠的。

WebSocket

WebSocket本质上一种计算机网络应用层的协议

与HTTP不同点

WebSocket使用HTTP来建立连接，但是定义了一系列新的header域，这些域在HTTP中并不会使用。
WebSocket的连接不能通过中间人来转发，它必须是一个直接连接。
WebSocket连接建立之后，通信双方都可以在任何时刻向另一方发送数据。
WebSocket连接建立之后，数据的传输使用帧来传递，不再需要Request消息。
WebSocket的数据帧有序。

缓存

git

多人开发提交流程

1、在 dev 开发完成后commit到本地，不push到远程；
2、切换到 master 拉取远程分支代码；
3、show in finder 打开项目运行，没有问题后切换到 dev 分支;
4、将master 分支合并到 dev ，运行代码

• 没有冲突：

  运行step5

• 有冲突

两人操作同一份类文件冲突：

定位到冲突文件，调整类文件代码顺序，清除冲突标记;
在 sourceTree 中右键选择冲突文件，选择解决冲突 ;
提交后确认代码确认没有问题 ;

工程文件冲突：

直接在 sourceTree 中选择冲突文件，选择 采用他人版本;
show in finder 找回因采用他人版本自己本地被移除的本地文件;
提交后运行代码，确保自己后面修改的文件都在，运行没有问题；
解决完冲突提交后，跳回 master 分支，合并 dev 到 master ；
再次在 master 分支中运行项目，确保没有问题提交并推送到远程 master 分支跳转到 dev 分支继续开发