-
说一下http和https？
http：超文本传输协议，是一个基于请求与响应、无状态的应用层协议，以明文方式发送信息，最初设计目的是提供一种发布和接收 HTML 页面的方法。
https：是http的安全版，它的安全基础是SSL。通俗来讲就是外层加了一个SSL加密协议的http。是一种通过计算机网络进行安全通信的传输协议，经由http进行通信，利用SSL和TLS建立安全通道，来进行加密数据包。https主要就是用来提供对服务器的身份认证，同时对进行传输的内容进行加密。SSL协议又分为记录协议和握手协议。
区别：
1、HTTPS 协议需要到 CA （Certificate Authority，证书颁发机构）申请证书，一般免费证书较少，因而需要一定费用。(以前的网易官网是http，而网易邮箱是 https 。)
2、HTTP 是超文本传输协议，信息是明文传输，HTTPS 则是具有安全性的 SSL 加密传输协议。
3、HTTP 和 HTTPS 使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
4、HTTP 的连接很简单，是无状态的。HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，比 HTTP 协议安全。(无状态的意思是其数据包的发送、传输和接收都是相互独立的。无连接的意思是指通信双方都不长久的维持对方的任何信息。)
-
tcp三次握手，一句话概括？
一句话概括:确认双方的接收与发送能力是否正常。
从图片可以得到三次握手可以简化为：C发起请求连接S确认，S也发起请求连接C确认
每次握手的作用：
第一次握手： S只可以确认 自己可以接收C发送的报文段
（客户端给服务器发送一个 SYN 报文）
（服务器收到 SYN 报文之后，会应答一个 SYN+ACK 报文。）
第二次握手：C可以确认 S收到了自己的报文段，并且可以确认自己可以接受S发送的报文段
（客户端收到 SYN+ACK 报文之后，会回应一个 ACK 报文。）
第三次握手：S可以确认C收到了自己发送的报文段
（服务器收到 ACK 报文之后，三次握手建立完成。）
• TCP 和 UDP 的区别
TCP和UPD协议，是提供拥塞，错误和流量控制的协议。
TCP: 传输控制协议（TCP）是TCP/IP模型的传输层协议。它是一个面向连接的协议。因此，协议首先在源和目标之间建立连接。此外，源和目标开始通过此已建立的路径进行通信。
UDP 或用户数据报协议是 TCP/IP 模型传输层的无连接协议。它既不建立连接，也不检查目标计算机是否已准备好接收。该协议只是将数据发送到目标计算机。
| TCP 实现三次握手协议，有助于流量控制、错误控制和拥塞控制，这使得TCP高度可靠。因为它需要确认发送的信息。此外，重新发送丢失的数据包（如果有）。保证以相同的顺序传递数据包。 |
| UDP不太可靠，在UDP的情况下，如果数据包丢失，它不会请求重新传输，目标计算机会收到损坏的数据。因此，UDP 是一种不可靠的协议。 |
tcp | udp | |
| 概念 | 面向连接（即需要建立连接） | 面向无连接 |
| 保证数据顺序 | 无法保证数据顺序 | |
| 只支持点对点通讯 | 支持一对一、一对多、多对多通讯 | |
| 有拥塞机制 | 无拥塞机制 | |
| 头部20-60个字节 | 头部8个字节 | |
| 传输速度 | 要求实时性低，准确度高 | 要求实时性高，准确度低 |
| 面向字节流（发送数据时会将数据分解为多个小的数据报文进行发送） | 基于数据报（发送数据时会直接打上UDP头部将整个报文发送出去） | |
| 类型 |
|
|
| 应用场景 | 发送或接收邮件（POP IMAP SMTP 对数据准确性要求高，非紧急应用），远程登录（TELNET SSH 对数据准确性有一定要求，有连接的概念）等 | 即时通信（QQ聊天 对数据准确性和丢包要求比较低，但速度必须快），在线视频（RTSP 速度一定要快，保证视频连续，但是偶尔花了一个图像帧，人们还是能接受的），网络语音电话（VoIP 语音数据包一般比较小，需要高速发送，偶尔断音或串音也没有问题），发送音频和视频文件等等， |
| 有三次握手可以保证数据传输的可靠性 | 传输数据可能存在丢包 | |
| 错误检查 | 只有 TCP 可以纠正错误，因为它同时具有拥塞和流量控制。 | UDP只可以检查，不可以纠正错误 |
• WebSocket 的实现和应用
WebSocket是一种协议，可以在单个TCP连接上进行全双工通信。该协议使客户端与服务器之间数据交换变得更加简单，可以让服务器端主动向客户端推送数据。
在WebSocket API中，浏览器与服务器只需要完成一次握手，两者之间就可以创建持久性的连接并进行双向数据传输。
首先，http协议的特点是无状态连接。即http的前一次连接与后一次连接是相互独立的。
交互是双方的事情，怎么能限定一方发数据，另一方接数据呢？
websocket的解决方案： 建立固定连接，适用于项目中存在需要S端向C/B端发送数据的情形。
应用场景
1.数据传输实时性要求较高的场景，比如网页聊天室，直播。
2.推送信息，比如网站消息通知，邮箱新邮件提醒等。
3.监控在线状态，统计在线时长，比如在线考试等。
4.远程调试代码、云指令系统，比如云服务器。
5.其它也可用于网络渗透技术，多玩家网络游戏。
6.账户余额等数据的实时更新。
实际的使用，其实就是服务端自己调用WebSocket的sendInfo接口。当然也可以自己扩展更为细致的逻辑，方法等。
• HTTP 请求的方式，HEAD 方式
head：类似于 get 请求，只不过返回的响应中没有具体的内容，用户获取报头
options：允许客户端查看服务器的性能，比如说服务器支持的请求方式等等。
• 一个图片 url 访问后直接下载怎样实现？
• 说一下 web Quality（无障碍）
• 几个很实用的 BOM 属性对象方法?
(1)location 对象
(2)history 对象
(3)Navigator 对象
• 说一下 HTML5 drag api
- dragstart：事件主体是被拖放元素，在开始拖放被拖放元素时触发，。
- darg：事件主体是被拖放元素，在正在拖放被拖放元素时触发。
- dragenter：事件主体是目标元素，在被拖放元素进入某元素时触发。
- dragover：事件主体是目标元素，在被拖放在某元素内移动时触发。
- dragleave：事件主体是目标元素，在被拖放元素移出目标元素是触发。
- drop：事件主体是目标元素，在目标元素完全接受被拖放元素时触发。
- dragend：事件主体是被拖放元素，在整个拖放操作结束时触发
• 说一下 http2.0
• fetch 发送 2 次请求的原因
• Cookie、sessionStorage、localStorage 的区别
区别：
1、数据传递不同
- cookie 数据始终在同源的 http 请求中携带（即使不需要），即 cookie 在浏览器和服务器间来回传递。
- sessionStorage 和 localStorage 不会自动把数据发给服务器，仅在本地保存。
2、生命周期不同
就是数据的有效期不同。
- cookie：可以设置失效时间；如果没有设置失效时间，浏览器关闭后数据会失效
- localStorage：数据会永久保存，除非手动清除
- sessionStorage：会话当前数据有效就是在浏览器窗口关闭之前有效，浏览器关闭后数据会被清除
3、存储大小限制不同
- cookie 数据还有路径（path）的概念，可以限制 cookie 只属于某个路径下,存储的大小很小只有 4K 左右。 （key：可以在浏览器和服务器端来回传递，存储容量小，只有大约 4K 左右）
- webStorage 虽然也有存储大小的限制，但是比 cookie 大得多，可以达到 5M 或更大
4、http请求不同
- cookie：每次http请求都会携带cookie，请求过多保存过多的数据会带来性能问题
- web Storage（localStorage和sessionStorage）：只在客户端保存，不参与服务器的交互。
5、作用域不同
- cookie：同源窗口共享
- localStorage：同源窗口共享
- sessionStorage：不在不同的浏览器窗口中共享
6、易用性不同
- cookie：需要自己封装，原生接口不友好
- web Storage（localStorage和sessionStorage）：原生接口友好，API接口更方便。也可以再次封装，对Object和Array有更好的支持
数据更新
web Storage（localStorage和sessionStorage）支持事件通知机制，可以将数据更新的通知发送给监听者。
使用场景
- cookie：不能跨域请求！验证登录、判断是否登陆过网站、保存上次登录的信息、保存上次查看的页面、浏览计数器
- localStorage：跨页面传递参数，长期登录，长期保存在本地的数据，数据永久保存除非手动删除
- sessionStorage：临时保存数据，页面刷新，敏感账号一次性登录
• cookie 和 session 的区别，localstorage 和 sessionstorage 的区别
- 保存用户登录状态。
例如将用户 id 存储于一个 cookie 内，这样当用户下次访问该页面时就不需要重新登录了，现在很多论坛和社区都提供这样的功能。 cookie 还可以设 置过期时间，当超过时间期限后，cookie 就会自动消失。因此，系统往往可以提示用 户保持登录状态的时间：常见选项有一个月、三个 月、一年等。
- 跟踪用户行为。
例如一个天气预报网站，能够根据用户选择的地区显示当地的天气情况。如果每次都需要选择所在地是烦琐的，当利用了 cookie 后就会显得很人性化了， 系统能够记住上一次访问的地区，当下次再打开该页面时，它就会自动显示上次用户 所在地区的天气情况。因为一切都是在后 台完成，所以这样的页面就像为某个用户所 定制的一样，使用起来非常方便定制页面。如果网站提供了换肤或更换布局的功能， 那么可以使用 cookie 来记录用户的选项，例如：背景色、分辨率等。当用户下次访问 时，仍然可以保存上一次访问的界面风格。
• Cookie 和 session 的区别
cookie与session区别有：1、对象不同；2、存储数据大小不同；3、生命周期不同；4、存储位置不同；5、数据类型不同；6、安全性不同。其中，定义不同是指cookie是针对每个网站的信息，每个网站只能对应一个，而session是针对每个用户的，只有客户端才能访问。
1、对象不同
cookie：是针对每个网站的信息，每个网站只能对应一个，其他网站无法访问，这个文件保存在客户端，每次您拨打相应网站，浏览器都会查找该网站的 cookies，如果有，则会将该文件发送出去。cookies文件的内容大致上包括了诸如用户名、密码、设置等信息。
session：是针对每个用户的，只有客户端才能访问，程序为该客户添加一个 session。session中主要保存用户的登录信息、操作信息等等。此 session将在用户访问结束后自动消失(如果也是超时)。
2、存储数据大小不同
cookie：一个 cookie存储的数据不超过3K。
session：session存储在服务器上可以任意存储数据。当 session存储数据太多时，服务器可选择进行清理。
3、生命周期不同
cookie：cookie的生命周期当浏览器关闭的时候就消亡了，cookie的生命周期是累计的，从创建时就开始计时，30min后cookie生命周期结束。
session：session的生命周期是间隔的，从创建时开始计时如在30min内没有访问session，那么session生命周期就被销毁。
4、存储位置不同
cookie：cookie数据保存在客户端。
session：session数据保存在服务器端。
5、数据类型不同
两者都是key-value结构，但针对value的类型是有差异的。
cookie：value只能是字符串类型。
session：value是object类型。
6、安全性不同
cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗，如果主要考虑到安全应当使用session。
• 说一下 web worker
• 对 HTML 语义化标签的理解
什么是语义化
语义化就是构成HTML结构的标签要有意义。
比如有这样的标签：
header表示页面头部
main表示页面主题
footer表示页面底部
那么这些标签构成的HTML结构就是有意义的，也是语义化的。
如果说页面的头部、主体以及底部都用div来表示，那么他就不是一个语义化的HTML结构了。
SEO与爬虫与SSR
在此之前，大家得了解了解H5语义化: http://www.daqianduan.com/6549.html ，可以看看这篇文章，写的很透彻。语义化就是为了代码具有可读性，提高了代码的可维护性，可以让页面结构清晰，有利于SEO和爬虫解析。div是非语义化标签，一个 div 看起来总没有一个 p 意义更明显。虽然现在 H5 出了一些语义化标签，比如 <header>/<section>/<footer>/<article> ，但是其实各大网站上用的很少，一方面是为了兼容低版本的浏览器，另一方面也可能是前端工程师（比如我），没有意识到语义化的重要性。
现在我们谈谈SEO（Search Engine Optimization ），SEO是搜索引擎优化，说简单点，就是你的前端的页面最好能让机器也很容易的看懂，并且轻松提取关键字。SEO在搜索引擎时代对于网站来讲意义重大，对于网站的流量导入，起着重大的作用。可以看看：https://www.v2ex.com/t/302616 。而纯前端的项目，由于需要页面加载完成后再去拉取数据进行渲染，大部分搜索引擎没法读取页面内容。特别是SPA项目，更是无法读取到每个路由页面的页面Title。在首屏渲染上，纯前端项目，先要加载Js，再通过Js去加载数据，这两部分网络传输都需要时间，所以难以避免出现页面白屏时间，体验不友好。所以就出现了SSR。
SSR（server side render），就是服务端渲染，服务器将每个要展示的页面都运行完成后，将整个相应流传送给浏览器，所有的运算在服务器端都已经完成，浏览器只需要解析 HTML 就行。浏览器渲染对爬虫不友好，也就是对SEO不友好，所以就出现了服务器端渲染。 Vue2.0在服务端创建了虚拟DOM，因此可以在服务端可以提前渲染出来，这解决了单页面一直存在的问题：SEO和初次加载耗时较多的问题。同时在真正意义上做到了前后端共用一套代码。要用SSR，得准备一个node server（express，koa…），这也不可避免地加大了性能、运维等挑战。
下面举个栗子：
比如用户A在上海某个局域网打开了 https://live.kuaishou.com/ ，用户B在背景某个局域网也打开了 https://live.kuaishou.com/ ，这是两个client，都向 live.kuaishou.com （前端服务器）发起了页面请求，假设前端服务器的物理机器在C地。前端服务器接受请求后，先向后台请求数据，一般前端服务器和后台同源，不跨域；（如果跨域，前端服务器和后台约定跨域策略）。前端服务器得到数据后，有两种选择。一是该页面初始模板发送给用户浏览器，用户浏览器等JavaScript 都完成下载并执行，自己输出 Vue 组件，进行生成 DOM 和操作 DOM，也就是浏览器端渲染页面（CSR）。另一种就是将同一个组件渲染为服务器端的 HTML 字符串，将HTML 字符串直接发送到用户浏览器，最后将这些静态标记"激活"为客户端上完全可交互的应用程序，这就是服务器端渲染（SSR）。
在CSR这里，同步是关键。如果 live.kuaishou.com 页面某些部分初始展示 loading 菊花图，然后通过 Ajax 获取内容，爬虫抓取工具并不会等待异步完成后再行抓取页面内容。也就是说，如果 SEO 对站点至关重要，而页面又是异步获取内容，则需要服务器端渲染(SSR)解决此问题。这样在客户端页面其实是静态的，这样方便抓取工具就能 get 到页面的很多重要内容。
https://www.lmlphp.com/user/58680/article/item/1447739/
• iframe 是什么？有什么缺点？
• Doctype 作用?严格模式与混杂模式如何区分？它们有何意义?
• Cookie 如何防范 XSS 攻击
- httponly-这个属性可以防止 XSS,它会禁止 javascript 脚本来访问 cookie。
- secure - 这个属性告诉浏览器仅在请求为 https 的时候发送 cookie。
• 一句话概括 RESTFUL（表现层状态转化）
1、RESTful是一种架构风格、设计风格，基于RESTful的web系统更有层次、简便、轻量级以及通过HTTP直接传输，RESTful web服务成为替代SOAP服务的一个更有前途的替代方案。
2、基于RPC（Remote Procedure Call Protocal）的web服务和基于RESTful的web服务，RPC服务的关注点在于方法，REST服务的关注点在资源。RPC样式架构、RESTful样式架构以及REST-RPC混合架构。
总而言之，一句话，RESTful是一种web服务的架构风格。
总结
REST是Representational State Transfer，即表现层状态转化。
- 符合REST原则的架构，就叫RESTful架构。
- URL定位资源Resources，即通过访问URL来获取资源。
- 表现层的状态转化，实际上是资源的表现层发生状态转化。
- 客户端访问资源，使服务器端上的资源的表现层发生状态转化。
- 客户端通过HTTP四个动词，GET、POST、PUT、DELETE，对服务器端资源进行操作，实现资源的表现层状态转化。
概括如下：
- URL定位资源
- 客户端与服务器端之间的互动，使得资源的表现层发生状态转化
- 客户端通过4个HTTP动词：GET、POST、PUT和DELETE，对服务器端的资源进行操作，实现服务器端上资源的“表现层状态转移”
讲讲 viewport 和移动端布局
<meta name="viewport" content="width=device-width, user-scalable=yes,initial-scale=1.0, maximum-scale=1.0, minimum-scale=1.0">
适配方案
如今移动端web的适配方案从根本性质上可分为两大类：自适应，响应式
自适应
- PC端，移动端两套网页代码（甚至更多）。
- 表现“在不同尺寸的手机设备上，页面保持统一效果的等比缩放”的效果。
1、 百分比适配
主要使用百分比%单位去编写页面元素的宽度,一些情况下的元素高度，边距等样式，根据可视区域实时尺寸进行调整，尽可能适应各种分辨率，通常使用max-width/min-width控制尺寸范围过大或者过小。
优点：
原理简单，无兼容性问题
缺点：
1：不适用于页面元素较多，较复杂的场景。
2：由于设备分辨率的跨度较大，元素的百分比不好把控，可能出现元素拉伸变形的问题。
3：字体大小无法自适应。
4：在CSS中百分比所相对的包含块或参考对象所遵循规则不固定，容易使布局复杂化。
2、 rem适配
CSS中数值单位除了px,还有em和rem。em是相对于当前元素的font-size大小（如当前元素没有设置，则以父元素font-size为准）的倍数单位，适用场景较少。而rem则是相对于html根元素的font-size大小的倍数单位。如html的font-size为16px，则2rem代表32px.
rem适配方案的核心实现过程就是根据先设置好的比例关系在CSS样式中使用rem单位，通过监听视口尺寸（即设备分辨率）的变化，动态地改变根元素font-size的大小，从而实现页面元素等比缩放的自适应效果。
优点：
兼容性和自适应效果好
缺点：
1：不是纯css移动适配方案，需要引入js脚本，具有一定耦合度。
2：通过 rem 计算后可能会出现小数像素，而浏览器在渲染时会进行四舍五入。所以可能会存在一定的精度问题和页面显示效果问题
3：由于是等比缩放，如果使用ipad等较大设备，则会看到夸张的字体大小和布局尺寸
3、 vw/wh适配
vw,vh,vmax,vmin是CSS推出的视口专属单位，各单位具体含义如下：
vw : 1vw 等于 视口宽度 的 1%，即100vw等于视口宽度
vh : 1vh 等于 视口高度 的 1%，即100vh等于视口高度
vmin : 选取 vw 和 vh 中 较小 的那个
vmax : 选取 vw 和 vh 中 较大 的那个
4、 vw+rem+calc()移动端适配最佳实践
需求：375-414px的屏幕设备根字号大小为16px-18px
html{
font-size: 16px;
}
@media screen and (min-width: 375px) {
/*375px屏幕作为16px根元素字号的基准，414px屏幕正好对应18px的根元素字号*/
html {
font-size: calc((100vw - 375px) / 375 + 1px);
}
}
@media screen and (min-width: 414px){
/*屏幕宽度从414px到1000px，根元素字号为18px-22px*/
html {
font-size: calc(18px + 4 * (100vw - 414px ) / 586);
}
}
@media screen and (min-width: 1000px){
/*屏幕宽度1000px往上，每增加100px则根元素字号增加0.5px*/
html {
font-size: calc(22px + 5 * (100vw - 1000px ) / 1000);
}
}
响应式
- 一套代码，多端适用。
- 通过媒体查询，弹性布局等手段来为从移动端到PC端由小变大的不同分辨率提供可伸缩性的页面布局效果。
- 一般来说，响应式方案是自适应方案的子集。都是致力于适配不同设备，提升用户体验。
常见适配问题优化
响应式布局的常用解决方案对比(媒体查询、百分比、rem和vw/vh） · Issue #13 · forthealllight/blog · GitHub
• click 在 ios 上有 300ms 延迟，原因及如何解决？
• addEventListener 参数
- event 指定事件名；
- function 指定要事件触发时执行的函数；
- useCapture 指定事件是否在捕获或冒泡阶段执行。
-
跨域和同源
-
判断条件
- 协议是否相同（http、https、file）
- 主机地址是否相同（www.xxx.com 127.0.0.1）
- 端口（0~65535）
http默认的端口号是80（可以省略），https默认端口是443 ， MySQL默认的端口是3306
同源
如果两个url协议、主机地址、端口都相同，那么这两个url是同源，否则就是非同源
非同源受到限制：
- Cookie无法操作
- DOM无法操作
- Ajax请求无效（请求可以发送，服务器也会处理这次请求，但是响应结果会被浏览器拦截）
跨域
违反了同源策略的请求，叫做跨域请求。
解决方案
1、CORS方案
CPRS：通过服务器设置响应头来实现跨域，比较符合解决跨域的真正问题
2、JSONP
JSONP：
- JSONP方案只支持GET请求
- JSONP方案和AJAX没有任何关系
- JSONP任何浏览器都支持，兼容性好
• 介绍知道的 http 返回的状态码
1、什么是Http状态码
2、状态码的类别
状态码有很多，但可以分成如下几种类别
| 状态码 | 类别 | 原因短语 |
| 1XX | Informational (信息状态码) | 接收的请求正在处理 |
| 2XX | Success (成功状态码) | 请求正常，处理完毕 |
| 3XX | Redirection (重定向状态码) | 需要进行附加操作完成请求 |
| 4XX | Client Error (客户端错误状态码) | 服务器无法处理请求 |
| 5XX | Server Error (服务器错误状态码) | 服务器处理请求出错 |
3、2XX成功
2XX的响应结果代表请求被正常处理了。
3.1 200（成功） OK
200 OK应该是平时遇见最多的请求之一，代表请求没有问题，一次成功的HTTP请求。
3.2 204（无内容） No Content
HTTP状态204 (No Content)指服务器成功处理了请求，但没返回任何内容。
3.3 206（部分内容） Partial Content
该状态码表示客户端进行了范围请求，而服务器成功执行了这部分的Get请求。响应报文中包含由Content-Range指定的实体范围。
什么是范围请求，范围请求是指访问一个资源的时候，由于资源很大，如果一次性下载，如果遇见网络中断或者异常，就得从头开始，范围请求允许对下载的实体，一次只请求资源部分实体，比如对一份10 000字节的图片，只请求他0-5000字节的数据，之后再请求50001-10000的数据。比如加载图片，图片先加载一半出来。
4、3XX重定向
3XX响应结果表示浏览器需要执行某些特殊的处理以正确的处理请求。
4.1 301（永久移动） Moved Permanently
永久性重定向，该状态码表示资源已经被分配了新的URI。
4.2 302（临时移动）Found
临时性重定向，该状态码表示请求的资源已经被分配了新的URL，希望用户本次使用新的URL登录。
5、4XX
4XX的结果表示客户端是产生问题的主要原因。
5.1 400 （错误请求）Bad Request
该状态码标识请求报文中存在语法错误。
5.2 401（未授权） Unauthorized
该状态码标识发送的请求需要有通过的Http认证。
5.3 403 （禁止）Forbidden
该状态码明确标识请求资源被拒绝了。
5.3 404（未找到） Not Found
请求了一个不存在的资源。经常在URL写错的时候就会遇见这个。
6、5XX
5XX表示服务器异常。
6.1 500 （服务器内部错误）Internal Server Error
该状态码表示服务器在执行请求的时候出现了错误。
6.2 503 （服务不可用）Service Unavailable
该状态码表示服务器暂时处于超负载状态或正在停机维护，现在无法处理请求。
• 301 和 302 的区别
• 状态码 304 和 200
• 说说 302，301，304 的状态码
• 补充 400 和 401、403 状态码 参考回答：
• http 常用请求头
一、通用头域（即通用头）
1、Cache-Control头域
- Cache -Control指定请求和响应遵循的缓存机制。在请求消息或响应消息中设置 Cache-Control并不会修改另一个消息处理过程中的缓存处理过程。
- 请求时的缓存指令包括no-cache、no-store、max-age、 max-stale、min-fresh、only-if-cached；
- 响应消息中的指令包括public、private、no-cache、no- store、no-transform、must-revalidate、proxy-revalidate、max-age。
Date头域
- date头域表示消息发送的时间，时间的描述格式由rfc822定义。例如，Date:Mon,31Dec200104:25:57GMT。Date描述的时间表示世界标准时，换算成本地时间，需要知道用户所在的时区。
Pragma头域
Pragma头域用来包含实现特定的指令，最常用的是Pragma:no-cache。在HTTP/1.1协议中，它的含义和Cache- Control:no-cache相同。
-
Connection表示连接状态
请求：
close（告诉WEB服务器或者代理服务器，在完成本次请求的响应后，断开连接，不要等待本次连接的后续请求了）。
keepalive（告诉WEB服务器或者代理服务器，在完成本次请求的响应后，保持连接，等待本次连接的后续请求）。
响应：
close（连接已经关闭）。 keepalive（连接保持着，在等待本次连接的后续请求）。
Keep-Alive：如果浏览器请求保持连接，则该头部表明希望 WEB 服务器保持连接多长时间（秒）。例如：Keep-Alive：300
二、请求消息（请求头）
请求消息的第一行为下面的格式：Method Request-URI HTTP-Version
- Host头域指定请求资源的Intenet主机和端口号，必须表示请求url的原始服务器或网关的位置。HTTP/1.1请求必须包含主机头域，否则系统会以400状态码返回；
- Accept：告诉WEB服务器自己接受什么介质类型，*/*表示任何类型，type/*表示该类型下的所有子类型，type/sub-type。
- Accept-Charset： 浏览器申明自己接收的字符集。
- Authorization：当客户端接收到来自WEB服务器的 WWW-Authenticate响应时，用该头部来回应自己的身份验证信息给WEB服务器。
典型的请求消息：
GET http://download.microtool.de:80/somedata.exe
Host: download.microtool.de
Accept:*/*
Pragma: no-cache
Cache-Control: no-cache
Referer: http://download.microtool.de/
User-Agent:Mozilla/4.04[en](Win95;I;Nav)
Range:bytes=554554-三、响应消息（响应头）
响应消息的第一行为下面的格式：
HTTP-Version Status-Code Reason-Phrase
- HTTP -Version表示支持的HTTP版本，例如为HTTP/1.1。
- Status- Code是一个三个数字的结果代码。
- Reason-Phrase给Status-Code提供一个简单的文本描述。
Status-Code主要用于机器自动识别，Reason-Phrase主要用于帮助用户理解。Status-Code的第一个数字定义响应的类别，后两个数字没有分类的作用。第一个数字可能取5个不同的值：
1xx:信息响应类，表示接收到请求并且继续处理
2xx:处理成功响应类，表示动作被成功接收、理解和接受
3xx:重定向响应类，为了完成指定的动作，必须接受进一步处理
4xx:客户端错误，客户请求包含语法错误或者是不能正确执行
5xx:服务端错误，服务器不能正确执行一个正确的请求
四、实体消息（实体头和实体）
一般格式：
Content-Range:bytes-unitSPfirst-byte-pos-last-byte-pos/entity-legth
例 如，传送头500个字节次字段的形式：Content-Range:bytes0-
499/1234如果一个http消息包含此节（例如，对范围请求的响应或对一系列范围的重叠请求）。
• 强，协商缓存
| 获取资源形式 | 状态码 |
发送请求到服务器
| |
| 强缓存 | 从缓存取 | 200（from cache） | 否，直接从缓存获取 |
| 协商缓存 | 从缓存取 | 304（not modified） | 是，通过服务器来告知缓存是否 可用 |
- 强缓存相关字段有 expires，cache-control。如果 cache-control 与 expires 同时存在的话，cache-control 的优先级高于 expires。
- 协商缓存相关字段有 Last-Modified/If-Modified-Since，Etag/If-None-Match
• 强缓存、协商缓存什么时候用哪个
• 前端优化
- 降低请求量：合并资源，减少 HTTP 请求数，
- minify / gzip 压缩，webP，lazyLoad。
- 打包工具webpack,gulp等。
- 加快请求速度：预解析 DNS，减少域名数，并行加载，CDN 分发。
- 缓存：HTTP 协议缓存请求，离线缓存 manifest，离线数据缓存 localStorage。
- 渲染：JS/CSS 优化，加载顺序，服务端渲染，pipeline。
• GET 和 POST 的区别
一、功能不同
1、get是从服务器上获取数据。
2、post是向服务器传送数据。
二、过程不zhi同
1、get是把参数数据队列加到提交表单的ACTION属性所指的URL中，值和表单内各个字段一一对应，在URL中可以看到。
2、post是通过HTTP post机制，将表单内各个字段与其内容放置在HTML HEADER内一起传送到ACTION属性所指的URL地址。用户看不到这个过程。
三、获取值不同
1、对于get方式，服务器端用Request.QueryString获取变量的值。
2、对于post方式，服务器端用Request.Form获取提交的数据。
四、传送数据量不同
1、get传送的数据量较小，不能大于2KB。
2、post传送的数据量较大，一般被默认为不受限制。但理论上，IIS4中最大量为80KB，IIS5中为100KB。
GET和POST的区别_get和post请求的区别_哪 吒的博客-CSDN博客
• HTML5 新增的元素
- 首先 html5 为了更好的实践 web 语义化，增加了 header，footer，nav,aside,section 等语义化标签，
- 在表单方面，为了增强表单，为 input 增加了 color，emial,data ,range 等类型，
- 在存储方面，提供了 sessionStorage，localStorage,和离线存储，通过这些存储方式方便数据在客户端的存储和获取，
- 在多媒体方面规定了音频和视频元素 audio 和 vedio，另外还有地理定位canvas 画布，拖放，多线程编程的 web worker 和 websocket 协议。
• 在地址栏里输入一个 URL,到这个页面呈现出来，中间会发生什么？
流程：
1、浏览器的地址栏输入URL并按下回车。
2、浏览器查找当前URL是否存在缓存，并比较缓存是否过期。
3、DNS解析URL对应的IP。
4、根据IP建立TCP连接（三次握手）。
5、HTTP发起请求。
6、服务器处理请求，浏览器接收HTTP响应。
7、关闭TCP连接（四次挥手）。
8、渲染页面，构建DOM树。
• HTTP2.0 的特性
1、内容安全，
2、二进制格式，
3、多路复用，
• cache-control 的值有哪些
• 浏览器在生成页面的时候，会生成那两颗树？
• csrf 和 xss 的网络攻击及防范
• 怎么看网站的性能如何
被动去测：
主动监测：
• 介绍 HTTP 协议(特征)
• cookie 有哪些字段可以设置
• cookie 有哪些编码方式？
• HTML5 和 CSS3 用的多吗？你了解它们的新属性吗？有在项目中用过吗？
html5：
css3：
• get 请求传参长度的误区
参考回答：
误区：我们经常说 get 请求参数的大小存在限制，而 post 请求的参数大小是无限制
的。
实际上 HTTP 协议从未规定 GET/POST 的请求长度限制是多少。对 get 请求参数的限制
是来源与浏览器或 web 服务器，浏览器或 web 服务器限制了 url 的长度。为了明确这
个概念，我们必须再次强调下面几点:
- HTTP 协议 未规定 GET 和 POST 的长度限制
- GET 的最大长度显示是因为 浏览器和 web 服务器限制了 URI 的长度
- 不同的浏览器和 WEB 服务器，限制的最大长度不一样
- 要支持 IE，则最大长度为 2083byte，若只支持 Chrome，则最大长度 8182byte
post请求和get请求的区别
get请求:从指定的资源请求数据，用于获取数据，一般用于搜索排序和筛选之类的操作。
post请求:向指定的资源提交要被处理的数据，用于将数据发送给服务器，一般用于修改和写入数据。
（1）post请求更安全（不会作为url的一部分，不会被缓存、保存在服务器日志、以及浏览器浏览记录中，get请求的是静态资源，则会缓存，如果是数据，则不会缓存）
（2）post请求发送的数据更大（get请求有url长度限制，http协议本身不限制，请求长度限制是由浏览器和web服务器决定和设置）
（3）post请求能发送更多的数据类型（get请求只能发送ASCII字符）
（4）传参方式不同（get请求参数通过url传递，post请求放在request body中传递）
（5）get请求产生一个TCP数据包；post请求产生两个TCP数据包（get请求，浏览器会把http header和data一并发送出去，服务器响应200返回数据；post请求，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 返回数据）
注意：在发送 POST 的时候都没有带 Expect 头，server 也自然不会发 100 continue。
• 补充 get 和 post 请求在缓存方面的区别
参考回答：
post/get 的请求区别，具体不再赘述。
补充补充一个 get 和 post 在缓存方面的区别：get 请求类似于查找的过程，用户获取数据，可以不用每次都与数据库连接，所以可以使用缓存。
post 不同，post 做的一般是修改和删除的工作，所以必须与数据库交互，所以不能使用缓存。因此 get 请求适合于请求缓存。
nginx在应用程序中的作用
- 解决跨域
- 请求过滤
- 配置gzip
- 负载均衡
- 静态资源服务器
2526
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
