1、拖拽释放（drag and drop）API 2、语义化更好的内容标签（header footer nav aside article section） 3、音频、视频（audio video）API 4、画布（Canvas）API 5、地理（Geolocation）API 6、localstorage 和 sessionstorage 缓存方式 7、表单控件（calendar date time email ul search） 8、新技术（webworker websocket Geolocation） <canvas> 是 HTML5 新增的，一个可以使用脚本(通常为JavaScript)在其中绘制图像的 HTML 元素。它可以用来制作照片集或者制作简单(也不是那么简单)的动画，甚至可以进行实时视频处理和渲染。 Canvas是由HTML代码配合高度和宽度属性而定义出的可绘制区域。JavaScript代码可以访问该区域，类似于其他通用的二维API，通过一套完整的绘图函数来动态生成图形。 1、HTTPS 协议需要到 CA （Certificate Authority，证书颁发机构）申请证书，一般免费证书较少，因而需要一定费用。(以前的网易官网是http，而网易邮箱是 https 。) 2、HTTP 是超文本传输协议，信息是明文传输，HTTPS 则是具有安全性的 SSL 加密传输协议。 3、HTTP 和 HTTPS 使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。 4、HTTP 的连接很简单，是无状态的。HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，比 HTTP 协议安全。(无状态的意思是其数据包的发送、传输和接收都是相互独立的。无连接的意思是指通信双方都不长久的维持对方的任何信息。) 1.0的HTTP版本，是一种无状态，无连接的应用层协议。 HTTP1.0规定浏览器和服务器保持短暂的链接。 浏览器每次请求都需要与服务器建立一个TCP连接，服务器处理完成以后立即断开TCP连接（无连接），服务器不跟踪也每个客户单，也不记录过去的请求（无状态）。 这种无状态性可以借助cookie/session机制来做身份认证和状态记录。 HTTP 1.0 存在的问题
无法复用连接
每次发送请求，都需要进行一次TCP连接，而TCP的连接释放过程又是比较费事的。这种无连接的特性会使得网络的利用率变低。 队头阻塞（head of line blocking）
由于HTTP1.0规定下一个请求必须在前一个请求响应到达之前才能发送，假设前一个请求响应一直不到达，那么下一个请求就不发送，后面的请求就阻塞了。 HTTP1.1继承了HTTP1.0的简单，克服了HTTP1.0性能上的问题。 长链接
HTTP1.1增加Connection字段，通过设置Keep-Alive保持HTTP连接不断卡。避免每次客户端与服务器请求都要重复建立释放建立TCP连接。提高了网络的利用率。 如果客户端想关闭HTTP连接，可以在请求头中携带Connection:false来告知服务器关闭请求。 管道化
HTTP1.1支持请求管道化（pipelining）。 基于HTTP1.1的长连接，使得请求管线化成为可能。 管线化使得请求能够“并行”传输。 二进制分帧
HTTP2.0通过在应用层和传输层之间增加一个二进制分层帧，突破了HTTP1.1的性能限制，改进传输性能。 多路复用（链接共享）— 真并行传输
流（stream）：已建立连接上的双向字节流。 消息：与逻辑消息对应的完整的一系列数据帧。 帧（frame）：HTTP2.0通信的最小单位，每个帧包含头部，至少也会标识出当前所属的流（stream_id） 所有HTTP2.0通信都在一个TCP链接上完成，这个链接可以撑在任意流量的双向数据流。 每个数据流以消息的形式发送，而消息由一或多个帧组成。这些帧可以乱序发送，然后再根据每个帧头部的流标识符（Stream_id）重新封装。 多路复用（连接共享）可能会导致关键字被阻塞，HTTP2.0里每个数据流都可以设置优先级和依赖，优先级高的数据流会被服务器优先处理和返回客户端，数据流还可以依赖其他的子数据流。 可见，HTTP2.0实现了真正的并行传输，它能够在一个TCP上进行任意数量的HTTP请求。而这个强大的功能基于“二级制分帧”的特性。 头部压缩
HTTP2.0使用encoder来减少需要传输的header大小，通讯双方各自cache一份header_files表，既避免重复header的传输，又减少了需要传输的大小。 高效的压缩算法可以很大的压缩header，减少发送包的数量从而降低延迟。 服务器推送
服务器除了最初请求的响应外，服务器还可以额外向客户端推送资源，而无需客户端明确的需求 Google搞了一个基于UDP协议的QUIC协议，并且使用在了HTTP/3上， HTTP/3之前的名称为HTTP-over-QUIC 多路复用
QUIC基于UDP，一个连接上的多个stream之间没有依赖，即使丢包，只需要重发丢失的包即可，不需要重传整个连接。 更好的移动端表现
QUIC在移动端的表现比TCP好，因为TCP是基于IP识别连接，而QUIC是通过ID识别链接。 加密认证的根文 — 武装到牙齿
TCP协议头没有经过任何加密和认证，在传输过程中很容易被中间网络设备篡改、注入和窃听。 QUIC的packet可以说武装到了牙齿，除了个别报文，比如PUBLIC_RESET和CHLO，所有报文头部都是经过认证的，报文Body都是经过加密的。 所以只要对 QUIC 做任何更改，接收端都能及时发现，有效地降低了安全风险。 向前纠错机制
QUIC协议有一个非常独特的特性，成为向前纠错（Foward Error Connec，FEC），每个数据包除了它本身的内容之外还包括了其他数据包的数据，因此少量的丢包可以通过其他包的冗余数据直接组装而无需重传。 向前纠错牺牲了每个数据包可以发送数据的上限，但是带来的提升大于丢包导致的数据重传，因为数据重传将会消耗更多的时间（包括确认数据包丢失，请求重传，等待新数据包等步骤的时间消耗）。
各类别常见状态码：
2xx （3种）
200 OK：表示从客户端发送给服务器的请求被正常处理并返回； 204 No Content：表示客户端发送给客户端的请求得到了成功处理，但在返回的响应报文中不含实体的主体部分（没有资源可以返回）； 206 Patial Content：表示客户端进行了范围请求，并且服务器成功执行了这部分的GET请求，响应报文中包含由Content-Range指定范围的实体内容。 3xx （5种）
301 Moved Permanently：永久性重定向，表示请求的资源被分配了新的URL，之后应使用更改的URL； 302 Found：临时性重定向，表示请求的资源被分配了新的URL，希望本次访问使用新的URL；301与302的区别：前者是永久移动，后者是临时移动（之后可能还会更改URL） 303 See Other：表示请求的资源被分配了新的URL，应使用GET方法定向获取请求的资源；302与303的区别：后者明确表示客户端应当采用GET方式获取资源 304 Not Modified：表示客户端发送附带条件（是指采用GET方法的请求报文中包含if-Match、If-Modified-Since、If-None-Match、If-Range、If-Unmodified-Since中任一首部）的请求时，服务器端允许访问资源，但是请求为满足条件的情况下返回改状态码； 307 Temporary Redirect：临时重定向，与303有着相同的含义，307会遵照浏览器标准不会从POST变成GET；（不同浏览器可能会出现不同的情况）； 4xx （4种）
400 Bad Request：表示请求报文中存在语法错误； 401 Unauthorized：未经许可，需要通过HTTP认证； 403 Forbidden：服务器拒绝该次访问（访问权限出现问题） 404 Not Found：表示服务器上无法找到请求的资源，除此之外，也可以在服务器拒绝请求但不想给拒绝原因时使用； 5xx （2种）
500 Inter Server Error：表示服务器在执行请求时发生了错误，也有可能是web应用存在的bug或某些临时的错误时； 503 Server Unavailable：表示服务器暂时处于超负载或正在进行停机维护，无法处理请求； HTTP/1.1协议中共定义了八种方法（有时也叫“动作”），来表明Request-URL指定的资源不同的操作方式
其中：
HTTP1.0定义了三种请求方法： GET, POST 和 HEAD方法。 HTTP1.1新增了五种请求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法 最常用的四种请求方法：GET, POST, PUT, DELETE cookie的内容主要包括：名字、值、过期时间、路径和域。路径与域一起构成cookie的作用范围。若不设置时间，则表示这个cookie的生命期为浏览器会话期间，关闭浏览器窗口，cookie就会消失。这种生命期为浏览器会话期的cookie被称为会话cookie。 会话cookie一般不存储在硬盘而是保存在内存里，当然这个行为并不是规范规定的。若设置了过期时间，浏览器就会把cookie保存到硬盘上，关闭后再打开浏览器这些cookie仍然有效直到超过设定的过期时间。对于保存在内存里的cookie，不同的浏览器有不同的处理方式session机制。 当程序需要为某个客户端的请求创建一个session时，服务器首先检查这个客户端的请求里是否已包含了一个session标识（称为session id），如果已包含则说明以前已经为此客户端创建过session，服务器就按照session id把这个session检索出来使用（检索不到，会新建一个），如果客户端请求不包含session id，则为客户端创建一个session并且生成一个与此session相关联的session id，session id的值应该是一个既不会重复，又不容易被找到规律以仿造的字符串，这个session id将被在本次响应中返回给客户端保存。保存这个session id的方式可以采用cookie，这样在交互过程中浏览器可以自动的按照规则把这个标识发送给服务器。 cookie数据存放在客户的浏览器上，session数据放在服务器上 cookie不是很安全，别人可以分析存放在本地的cookie并进行cookie欺骗，考虑到安全应当使用session session会在一定时间内保存在服务器上，当访问增多，会比较占用你服务器的性能，考虑到减轻服务器性能方面，应当使用cookie 单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie 建议将登录信息等重要信息存放为session，其他信息如果需要保留，可以放在cookie中 session保存在服务器，客户端不知道其中的信心；cookie保存在客户端，服务器能够知道其中的信息 session中保存的是对象，cookie中保存的是字符串 session不能区分路径，同一个用户在访问一个网站期间，所有的session在任何一个地方都可以访问到，而cookie中如果设置了路径参数，那么同一个网站中不同路径下的cookie互相是访问不到的 Web Storage的概念和cookie相似，区别是它是为了更大容量存储设计的，cookie的大小是受限的，并且每次请求一个新的页面的时候cookie都会被发送过去，这样无形中浪费了带宽，另外cookie还需要指定作用域，不可跨域调用。 除此之外，web storage拥有setItem,getItem,removeItem,clear等方法，不像cookie需要前端开发者自己封装setCookie，getCookie。但是cookie也是不可或缺的，cookie的作用是与服务器进行交互，作为http规范的一部分而存在的，而web Storage仅仅是为了在本地“存储”数据而生 sessionStorage、localStorage、cookie都是在浏览器端存储的数据，其中sessionStorage的概念很特别，引入了一个“浏览器窗口”的概念，sessionStorage是在同源的同窗口中，始终存在的数据，也就是说只要这个浏览器窗口没有关闭，即使刷新页面或进入同源另一个页面，数据仍然存在，关闭窗口后，sessionStorage就会被销毁，同时“独立”打开的不同窗口，即使是同一页面，sessionStorage对象也是不同的 减少网络流量：一旦数据保存在本地之后，就可以避免再向服务器请求数据，因此减少不必要的数据请求，减少数据在浏览器和服务器间不必要的来回传递 快速显示数据：性能好，从本地读数据比通过网络从服务器上获得数据快得多，本地数据可以及时获得，再加上网页本身也可以有缓存，因此整个页面和数据都在本地的话，可以立即显示 临时存储：很多时候数据只需要在用户浏览一组页面期间使用，关闭窗口后数据就可以丢弃了，这种情况使用sessionStorage非常方便 在网络中的两个应用程序（进程）需要全双工相互通信（全双工即双方可同时向对方发送消息），需要用到的就是socket，它能够提供端对端通信，对于程序员来讲，他只需要在某个应用程序的一端（暂且称之为客户端）创建一个socket实例并且提供它所要连接一端（暂且称之为服务端）的IP地址和端口，而另外一端（服务端）创建另一个socket并绑定本地端口进行监听，然后客户端进行连接服务端，服务端接受连接之后双方建立了一个端对端的TCP连接，在该连接上就可以双向通讯了，而且一旦建立这个连接之后，通信双方就没有客户端服务端之分了，提供的就是端对端通信了。我们可以采取这种方式构建一个桌面版的im程序，让不同主机上的用户发送消息。从本质上来说，socket并不是一个新的协议，它只是为了便于程序员进行网络编程而对tcp/ip协议族通信机制的一种封装。 websocket是html5规范中的一个部分，它借鉴了socket这种思想，为web应用程序客户端和服务端之间（注意是客户端服务端）提供了一种全双工通信机制。同时，它又是一种新的应用层协议，websocket协议是为了提供web应用程序和服务端全双工通信而专门制定的一种应用层协议，通常它表示为：ws://echo.websocket.org/?encoding=text HTTP/1.1，可以看到除了前面的协议名和http不同之外，它的表示地址就是传统的url地址。 既然是基于浏览器端的web技术，那么它的通信肯定少不了http,websocket本身虽然也是一种新的应用层协议，但是它也不能够脱离http而单独存在。具体来讲，我们在客户端构建一个websocket实例，并且为它绑定一个需要连接到的服务器地址，当客户端连接服务端的时候，会向服务端发送一个类似下面的http报文：
可以看到，这是一个http get请求报文，注意该报文中有一个upgrade首部，它的作用是告诉服务端需要将通信协议切换到websocket,如果服务端支持websocket协议，那么它就会将自己的通信协议切换到websocket,同时发给客户端类似于以下的一个响应报文头：
返回的状态码为101，表示同意客户端协议转换请求，并将它转换为websocket协议。以上过程都是利用http通信完成的，称之为websocket协议握手(websocket Protocol handshake)，进过这握手之后，客户端和服务端就建立了websocket连接，以后的通信走的都是websocket协议了。所以总结为websocket握手需要借助于http协议，建立连接后通信过程使用websocket协议。同时需要了解的是，该websocket连接还是基于我们刚才发起http连接的那个TCP连接。一旦建立连接之后，我们就可以进行数据传输了，websocket提供两种数据传输：文本数据和二进制数据。 基于以上分析，我们可以看到，websocket能够提供低延迟，高性能的客户端与服务端的双向数据通信。它颠覆了之前web开发的请求处理响应模式，并且提供了一种真正意义上的客户端请求，服务器推送数据的模式，特别适合实时数据交互应用开发。 强缓存：不用跟服务器进行通信，直接使用本地缓存的资源 协商缓存：首先，将所缓存资源的信息发送给服务器；其次，让服务器判断资源是否已经更新了,
若已更新，则返回更新后的资源； 若没有更新，则返回304状态，告诉浏览器可直接使用本地缓存的资源 整个过程至少与服务器通信一次 懒加载也叫延迟加载，指的是在长网页中延迟加载图像，是一种很好优化网页性能的方式。用户滚动到它们之前，可视区域外的图像不会加载。这与图像预加载相反，在长网页上使用延迟加载将使网页加载更快。在某些情况下，它还可以帮助减少服务器负载。常适用图片很多，页面很长的电商网站场景中。 首先将页面上的图片的 src 属性设为空字符串，而图片的真实路径则设置在data-original属性中， 当页面滚动的时候需要去监听scroll事件，在scroll事件的回调中，判断我们的懒加载的图片是否进入可视区域,如果图片在可视区内将图片的 src 属性设置为data-original 的值，这样就可以实现延迟加载。 示例 < htmllang = " en" > < head> < metacharset = " UTF-8" > < title> </ title> < style>
.image-item {
display : block;
margin-bottom : 50px;
height : 200px; //一定记得设置图片高度
}
</ style> </ head> < body> < imgsrc = " " class = " image-item" lazyload = " true" data-original = " images/1.png" /> < imgsrc = " " class = " image-item" lazyload = " true" data-original = " images/2.png" /> < imgsrc = " " class = " image-item" lazyload = " true" data-original = " images/3.png" /> < imgsrc = " " class = " image-item" lazyload = " true" data-original = " images/4.png" /> < imgsrc = " " class = " image-item" lazyload = " true" data-original = " images/5.png" /> < imgsrc = " " class = " image-item" lazyload = " true" data-original = " images/6.png" /> < imgsrc = " " class = " image-item" lazyload = " true" data-original = " images/7.png" /> < imgsrc = " " class = " image-item" lazyload = " true" data-original = " images/8.png" /> < imgsrc = " " class = " image-item" lazyload = " true" data-original = " images/9.png" /> < imgsrc = " " class = " image-item" lazyload = " true" data-original = " images/10.png" /> < imgsrc = " " class = " image-item" lazyload = " true" data-original = " images/11.png" /> < imgsrc = " " class = " image-item" lazyload = " true" data-original = " images/12.png" /> < script>
var viewHeight = document. documentElement. clientHeight
function lazyload ( ) {
var eles= document. querySelectorAll（'img[data-original][lazyload]' ）
Array . prototype. forEach . call ( eles, function ( item, index ) {
var rect
if ( item. dataset. original=== "" )
return
rect= item. getBoundingClientRect ( )
if ( rect. bottom>= 0 && rect. top < viewHeight) {
! function ( ) {
var img= new Image ( )
img. src= item. dataset. url
img. onload = function ( ) {
item. src= img. src
}
item. removeAttribute（"data-original" ）
item. removeAttribute（"lazyload" ）
} ( )
}
} )
}
lazyload ( )
document. addEventListener（"scroll" ，lazyload)
</ script> </ body> </ html> XSS攻击中文名称为：跨站脚本攻击，XSS的重点不在于跨站，而在于脚本的攻击。 XSS攻击的工作原理：攻击者会在web页面中插入一些恶意的script代码。当用户浏览该页面的时候，那么嵌套在该页面的代码就会执行，因此会达到攻击用户的目的。 XSS的分类：XSS攻击最主要分为如下几类，反射型，存储型，DOM-based型。反射型和DOM-based型可以归类于非持久性XSS攻击。存储型可以归类于持久性XSS攻击。 输入过滤
对于一些特别的输入比如电话号码，邮箱地址等等信息可以使用输入过滤。此时我们应该将侧重点放在防止浏览器恶意执行代码。 预防存储型和反射型 XSS 攻击
纯前端渲染：浏览器先加载一个静态 HTML，此 HTML 中不包含任何跟业务相关的数据。 转义HTML：如果需要拼接HTML是必要的话，就需要采用合适的转义库，对HTML模板各处插入点进行充分的转义。常用的模板引擎，如 doT.js、ejs、FreeMarker 等，对于 HTML 转义通常只有一个规则，就是把 & < > " ’ / 这几个字符转义掉，确实能起到一定的 XSS 防护作用。 预防DOM型攻击：DOM型XSS攻击，实际上就是网站前端javascript代码本身不够严谨，把不可信的数据当做代码执行了。在使用.innerHTML,.outerHTML,document.write()时要特别小心，不要把不可信的数据当做HTML插入到页面上，而应尽量使用.textContent，.setAttribute。 CSRF（Cross-site request forgery），也被称为：one click attack/session riding，中文名称：跨站请求伪造，缩写为：CSRF/XSRF。 一般来说，攻击者通过伪造用户的浏览器的请求，向访问一个用户自己曾经认证访问过的网站发送出去，使目标网站接收并误以为是用户的真实操作而去执行命令。常用于盗取账号、转账、发送虚假消息等。攻击者利用网站对请求的验证漏洞而实现这样的攻击行为，网站能够确认请求来源于用户的浏览器，却不能验证请求是否源于用户的真实意愿下的操作行为。 目前防御 CSRF 攻击主要有三种策略：
验证 HTTP Referer 字段； 在请求地址中添加 token 并验证； 在 HTTP 头中自定义属性并验证。 同源策略/SOP（Same origin policy）是一种约定，由 Netscape 公司 1995 年引入浏览器，它是浏览器最核心也最基本的安全功能，现在所有支持 JavaScript 的浏览器都会使用这个策略。如果缺少了同源策略，浏览器很容易受到 XSS、 CSFR 等攻击。 同源是指"协议+域名+端口"三者相同，即便两个不同的域名指向同一个 ip 地址，也非同源。 CDN的全称是Content Delivery Network，即内容分发网络。CDN是构建在网络之上的内容分发网络，依靠部署在各地的边缘服务器，通过中心平台的负载均衡、内容分发、调度等功能模块，使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率。
4487
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
