HTTP、HTTPS、TCP、UDP

一次完整的HTTP事务流程

（1）域名解析

（2）发起TCP的三次握手

（3）建立TCP连接后发起http请求

（4）服务器响应http请求，浏览器得到HTML代码

（5）浏览器解析HTML代码，并请求HTML代码中的资源

（6）浏览器对页面进行渲染呈现给用户

（7）连接结束

解析IP过程

从网址到IP地址的转换，称为DNS解析，DNS解析是一个递归查询的过程，具体步骤如下（以www.google.com为例）：

（1）首先在本地域名服务器（最近的一台DNS服务器）中查询IP地址

（2）如果没有找到，本地域名服务器会向根域名服务器发送一个请求

（3）如果根域名服务器中也不存在该域名，但判定这个域名属于“com”域，则本地域名服务器会向com顶级域名服务器发送一个请求

（4）如果com顶级域名服务器没有找到该域名，但判定这个域名属于“google.com”域，则本地域名服务器会向google.com域名服务器发送一个请求，以此类推

（5）直到本地域名服务器得到域名对应的IP地址，并将其缓存到本地，供下次查询使用

（6）综上，网址的解析过程为.->.com->google.com->www.google.com.。

TCP传输

上述标记说明：

（1）ACK（acknowledgement number）应答：TCP规定，只有当ACK=1时有效，也规定连接建立后所有发送的报文的ACK必须为1

（2）SYN（synchronization）：在连接建立时用来同步序号。当SYN=1而ACK=0时，表明这个是一个连接请求报文。对方若同意建立连接，则响应报文中SYN=1，ACK=1。因此，SYN置1表示这是一个连接请求或连接接受报文。

（3）FIN（finish）：终结的意思，用来释放一个连接。当FIN=1时，表明此报文段的发送方的数据已经发送完毕，并请求释放连接。

（4）seq ：序列号（sequence number）

建立连接需要“三次握手”

为了准确无误地把数据送达目标处，TCP协议采用了三次握手策略。
用TCP协议把数据包送出去后，TCP不会对传送后的情况置之不理，它一定会向对方确认是否成功送达。握手过程中使用了TCP的标志：SYN和ACK（同步-应答）。

1、发送端首先发送一个带SYN标记的数据包给对方。

2、接收端收到后，回传一个带有SYN/ACK标记的数据包以示传达确认信息。

3、最后，发送端再回传一个带ACK标记的数据包，代表“握手”结束。
若在握手过程中某个阶段莫名中断，TCP协议会再次以相同的顺序发送相同的数据包。

详细介绍：

（1）第一次握手：建立连接。客户端发送连接请求报文段，将SYN位置1，序列号seq（sequence number）为x；然后，客户端进入SYN_SEND状态，等待服务器的确认。

（2）第二次握手：服务器收到SYN报文段。服务器收到客户端的SYN报文段，需要对这个SYN报文段进行确认，ACK位置1，确认号ack（acknowledgement number）为x+1；同时，自己还要发送SYN请求信息，将SYN位置1，序列号seq为y；服务器将上述SYN+ACK报文段一并发送给客户端，此时服务器进入SYN_RECV状态。

（3）第三次握手：客户端收到服务器的SYN+ACK报文段。然后将确认号ack设置为y+1，向服务器发送ACK报文段。这个报文段发送完毕后，客户端和服务器都进入ESTABLISHED状态，完成TCP三次握手，之后可以开始传数据。

断开连接需要“四次握手”

第一次挥手：主动关闭方发送一个FIN/ACK标记，用来关闭主动方到被动关闭方的数据传送，也就是主动关闭方告诉被动关闭方：我已经不会再给你发数据了

(当然，在FIN包之前发送出去的数据，如果没有收到对应的ACK确认报文，主动关闭方依然会重发这些数据)，但是，此时主动关闭方还可以接受数据。

第二次挥手：被动关闭方收到FIN包后，发送一个ACK标记给对方，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号）。

第三次挥手：被动关闭方发送一个FIN标记，用来关闭被动关闭方到主动关闭方的数据传送，也就是告诉主动关闭方，我的数据也发送完了，不会再给你发数据了。

第四次挥手：主动关闭方收到FIN后，发送一个ACK标记给被动关闭方，确认序号为收到序号+1.
至此，完成四次挥手。

详细介绍：
（1）第一次挥手：主机1（可以是客户端，也可以是服务器）设置序列号seq为u，向主机2发送一个FIN报文段；此时，主机1进入FIN_WAIT状态，这表示主机1没有数据要发送给主机2了。

（2）第二次挥手：主机2收到了主机1发送的FIN报文段，向主机1回复一个ACK报文段，确认号ack为u+1，序列号seq为v；主机2进入CLOSE_WAIT状态；主机1收到主机2发送的ACK报文段之后，进入FIN_WAIT_2状态。

（3）第三次挥手：主机2向主机1发送FIN报文段，设置序列号seq为w，确认号ack为u+1，请求关闭连接，同时主机2进入LAST_ACK状态

（4）第四次挥手：主机1收到主机2发送的FIN报文段，向主机2发送ACK报文段，确认号ack为w+1，序列号seq为u+1，然后主机1进入TIME_WAIT状态；主机2收到主机1的ACK报文段以后，就关闭连接；此时，主机1等待2MSL（MSL，最长报文段寿命）后依然没有收到回复，则证明服务端已经正常关闭，那么主机1也可以关闭连接了。

TCP和UDP的区别

TCP（Transmission Control Protocol，传输控制协议）是基于连接的协议，也就是说，在正式收发数据前，必须和对方建立可靠的连接。一个TCP连接必须要经过三次“对话”才能建立起来

UDP（User Data Protocol，用户数据报协议）是与TCP相对应的协议。它是面向非连接的协议，它不与对方建立连接，而是直接就把数据包发送过去！

UDP适用于一次只传送少量数据、对可靠性要求不高的应用环境。

HTTP请求码及其作用

HTTP状态码：当用户访问一个网页时，浏览器会向网页所在的服务器出请求，当浏览器接收并显示网页前，此网页所在服务器会返回一个包含HTTP状态码的信息头（server header）用以响应浏览器的请求，HTTP状态码用于描述服务器对请求的处理结果。

HTTP状态码分类：

（1）1**：信息，服务器收到请求，需要请求者继续执行操作

（2）2**：成功，操作被成功接收并处理

（3）3**：重定向，需要进一步的操作以完成请求

（4）4**：客户端错误，请求包含语法错误或者无法完成请求

（5）5**：服务器错误，服务器在处理请求的过程中发生了错误

常见的HTTP状态码：

200——OK，请求成功
301——Moved Permanently，资源（网页等）被永久转移到其他URL
302——Found，307——Temporary Redirect，临时重定向，请求的文档被临时移动到别处
304——Not Modified，未修改，表示客户端缓存的版本是最近的
401——Unauthorized，请求要求用户的身份认证
403——Forbidden，禁止，服务器理解客户端请求，但是拒绝处理此请求，通常是权限设置所致
404——Not Found，请求的资源（网页等）不存在
500——Internal Server Error——内部服务器错误
502——Bad Gateway，充当网关或代理的服务器从远端服务器接收到了一个无效的请求
504——Gateway Time-out，充当网关或代理的服务器，未及时从远端服务器获取请求

浏览器解析渲染过程

（1）浏览器解析HTML源码，然后创建一个DOM树。

在DOM树中，每一个HTML标签都有一个对应的节点（元素节点），并且每一个文本也都有一个对应的文本节点，DOM树的根节点就是documentElement，对应的是html标签

（2）浏览器解析CSS代码，然后创建一个CSSOM树。

解析CSS的时候会按照如下顺序来定义优先级（递减）：

标签样式 > 内联样式 > 外联样式 > 用户设置 > 浏览器设置

（3）根据DOM树和CSSOM来构建一个渲染树（render tree）。

（4）当渲染树创建完成之后，浏览器就可以根据渲染树直接把页面绘制到屏幕上。

渲染树（render tree）和DOM树的关系

（1）在DOM树构建的同时，浏览器会构建渲染树。（为了提高用户体验，浏览器并不会等到所有HTML文档加载完成之后才建立渲染树并渲染，而是会在从网络层获取html文档的同时把已经接收到的局部内容先渲染出来）

（2）DOM树完全和html标签一一对应，而渲染树会忽略（即不包含）不需要渲染的元素（如head，样式为display:none的元素等）

（3）渲染树中每一个节点都存储着对应的CSS属性

reflow（重排、回流） 和 repaint（重绘）

reflow：浏览器要花时间去渲染，当它发现了某个部分发生了变化并且影响了布局，就需要倒回去重新渲染

repaint：如果只是改变了某个元素的背景颜色或文字颜色等，不影响元素周围或内部布局，就只会引起浏览器的repaint，重画其中一部分。

reflow比repaint更花费时间，也就更影响性能，所以在写代码时应尽量避免过多的reflow。

什么时候会发生reflow ?

（1）页面初始化的时候
（2）操作DOM的时候（增加或删除DOM元素）
（3）某些元素的尺寸改了（边距，填充，边框，宽高）
（4）CSS的属性发生变化（隐藏display：none）
（5）内容改变（文本改变或图片改变而引起的的计算值的宽高改变）
（6）浏览器窗口尺寸改变（当resize事件发生时）

如何减少reflow / repaint ？

（1）不要逐个修改DOM样式，可以预先定义好css的class，然后修改DOM的className，将多个需要进行相同操作的元素一次修改
（2）不要把DOM结点的属性值放在一个循环里当成循环的变量
（3）当动画元素使用fixed或absolute的position时（脱离了文档流），那么在修改他们的CSS时不会发生reflow
（4）不要使用table布局，因为可能很小的一个改动都会造成整个table的重新布局
（5）在内存中多次操作结点，完成后再添加到文档中去
（6）如果要对一个元素进行复杂的操作，可以先隐藏它（display：none），操作完成后再显示
（7）对于需要经常取出的引起浏览器重排的属性值，要缓存到变量中

为什么要先引入css文件，再引入js文件

（1）js代码的下载是阻塞下载，不可以和其他代码并行下载和解析；CSS的加载不会阻塞DOM树的解析（会阻塞其渲染，也会阻塞后面的js执行）

（2）页面加载时，是按照从上到下，从左到右的顺序加载的。如果将js放在前面，会立即执行，阻塞后续的资源下载和执行。如果外部脚本加载时间过长，会造成网页长时间失去响应，浏览器就会呈现“假死”状态（阻塞效应）

（2）页面需要等到head中的js和css加载完成之后才开始绘制，当js放在body最后时，不需要等待，可以避免资源阻塞，同时使静态页面迅速显示

（3）部分js的执行依赖于前面的样式。

（4）js一般是处理功能，所以不需要提前加载。先给用户观感，在给用户上手体验。

为了避免用户看到长时间的白屏时间，应尽可能的提高CSS的加载速度，具体方法？

（1）使用CDN（Content Delivery Network，内容分发网络），CDN会根据你的网络状况，替你挑选最近的一个具有缓存内容的节点为你提供资源，减少加载时间

（2）对css进行压缩

（3）合理的使用缓存（设置cache-control，expires以及E-tag）

（4）减少http请求数，将多个css文件合并，或者干脆直接写成内联样式（但是内联样式的缺点是不能缓存）

页面性能优化 ？

（1）CSS方面：CDN、压缩css、缓存、减少http请求数（将多个css文件合并）

（2）将样式表放在头部，将脚本放在底部

（3）减少重排（reflow）和重绘（repaint）

HTTP和HTTPS的区别

HTTP（Hyper Text Transfer Protocol，超文本传输协议）被用于在web浏览器和网站服务器之间传递信息，HTTP协议以明文的方式发送内容，不提供任何方式的数据加密，如果攻击者截取了web浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息，因此，HTTP协议不适合传输一些敏感信息，比如：信用卡号，密码等支付信息。

HTTPS（Hyper Text Transfer Protocol over Secure Socket Layer，安全套接字超文本传输协议），为了数据传输的安全，HTTPS在HTTP的基础上加入了SSL/TLS，依靠证书来验证服务器的身份，并为浏览器和服务器之间的通信加密。其中SSL（Secure Socket Layer，安全套接层），TLS（Transport Layer Securit，传输层安全协议），SSL 3.0和TLS 1.0差别很小，在HTTPS通信中具体使用哪一个还要看客户端和服务端的支持程度，二者在网络模型中位于哪一层？

区别：

（1）HTTPS协议需要CA申请证书，一般免费证书比较少，所以需要一定费用

（2）HTTP是超文本传输协议，信息室明文传输，HTTPS则是具有安全性的SSL加密传输协议

（3）HTTP和HTTPS使用的是完全不同的连接方式，使用的端口号也不一样，前者是80，后者是443

（4）HTTP连接很简单，是无状态的；HTTPS协议是由HTTP+SSL协议构建的可进行加密传输、身份认证的网络协议，比较安全。

（5）谷歌搜索引擎算法中，比起同等HTTP网站，采用HTTPS加密的网站在搜索结果中排名会更高

客户端使用HTTPS方式与web服务器通信的步骤：

（1）客户使用HTTPS的URL访问web服务器，要求与web服务器建立SSL连接

（2）web服务器收到客户端请求后，将网站的证书信息（证书中包含公钥）传送一份给客户端

（3）客户端的浏览器与web服务器开始协商SSL连接的安全等级，也就是信息的加密等级

（4）客户端的浏览器根据双方同意的安全等级，建立会话秘钥，然后利用网站的公钥将会话秘钥加密，并传送给网站

（5）web服务器利用自己的私钥解密出会话秘钥

（6）web服务器利用会话秘钥加密与客户端之间的通信

TCP/IP四层协议体系结构？

由上至下顺序为：

（1）应用层（FTP、Telnet、SMTP、RIP、NFS、DNS）

（2）运输层（TCP、UDP）

（3）网际层（IP、ICMP、ARP、RARP）

（4）网络接口层

五层协议体系结构？

（1）应用层

（2）运输层

（3）网络层

（4）数据链路层

（5）物理层

OSI的七层体系结构？

（1）应用层

（2）表示层

（3）会话层

（4）运输层

（5）网络层

（6）数据链路层

（7）物理层

前端优化方案？移动端优化方案？（面试常考，同时还会针对其中某些方案深入）

1、前端优化

• 减少请求数量：合并脚本和样式表，CSS Sprites，划分主域
• 降低请求带宽：使用GZip，精简JavaScript，移除重复脚本，图像优化，尽可能减少DOM节点数
• 缓存利用：使用CDN，使用外部的JavaScript和CSS，减少DNS查找，添加Expires头，配置ETag，使Ajax可缓存
• 页面结构：将样式表放在头部，将脚本放在底部，尽早刷新文档的输出

2、移动端优化

在上述的前端优化方案的基础上，可以做以下优化：

保持单个内容小于25KB，打包组件成符合文档

原文链接：https://blog.csdn.net/u012194956/article/details/79110212