目录
OSI七层框架/结构（自下而上：物联网淑惠试用）
应用层：所有能和用户交互产生网络流量的程序 是用户与网络的界面
协议：文件传输（FTP协议） 电子邮件（SMTP协议） 万维网（HTTP协议） DNS（域名服务）
表示层：对语法语义进行处理，如数据格式变换 数据加密解密 数据压缩与恢复
协议 JPEG ASCII
会话层：控制应用程序的会话能力，它定义了一段会话的开始、控制和结束。向表示层的进程提供建立连接并在连接上有序的传输数据 这就是会话。
协议：ADSP ASP
传输层：负责主机中两个进程的通信 即端到端的通信。传输单位是报文段或用户数据报。
协议：TCP UDP
可靠传输：发送端发送数据后需要等待接收端发送确认收到的信息
不可靠传输：发送端发送信息后就不管了
流量控制：控制发送方发送速度 若发送方发送速度太快 接收方跟不上了 就会让发送方降低发送速度
网络层：主要负责寻找地址和路由选择。传输单位是数据报
协议：IP IPXICMP IGMP ARP PARP OSPF
数据链路层：该层的作用包括：物理地址寻址、数据的成帧、流量控制、数据的检错、重发等。传输单位是帧。
协议：SDLC HDLC PPP STP
物理层：定义接口特性、传输模式、传输速率、比特同步、比特编码等
协议：Rj45 802.3
HTTP
HTTP：是一个客户端和服务器端请求和应答的标准（TCP），用于从WWW服务器传输超文本到本地浏览器的传输协议，它可以使浏览器更加高效，使网络传输减少。
HTTP1 HTTP2 HTTP3的区别
- HTTP 1.0
（1）引入了请求头、响应头、引入了accept、accept-encoding、accept-Charset、accept-language、user-agent、content-encoding、content-type
（2）引入了状态码。状态码是通过响应行的方式来通知浏览器的。
（3）提供了Cache机制 - HTTP 1.1
（1）增加了长连接：connection:keep-alive。目前浏览器中对于同一个域名，默认允许同时建立 6 个TCP长连接。
（2）增加了Host字段
（3）增加range请求头。最后使用一个零长度的块作为发送数据完成的标志。
（4）引入了客户端Cookie机制和安全机制
（5）长连接虽然能减少TCP的建立和断开次数，但它需要等待前面的请求返回之后才能进行下一次请求。如果TCP通道中的某个请求因为某些原因没有及时返回，那么就会阻塞后面的所有请求，这就是队头阻塞的问题。HTTP/1.1 中试图通过管线化的技术来解决这个问题。管线化是指将多个HTTP请求整批提交给服务器，虽然可以整批发送请求，不过服务器依然需要根据请求顺序来回复浏览器的请求。 - HTTP 2.0
（1）HTTP2使用的是二进制传送（HTTP1是字符串传送）二进制传送的单位是帧和流。帧组成了流，同时流还有流ID标示
（2）HTTP2支持多路复用：因为有流ID，所以通过同一个http请求实现多个http请求传输变成了可能，可以通过流ID来标示究竟是哪个流从而定位到是哪个http请求
（3）HTTP2头部压缩：HTTP2通过gzip和compress压缩头部然后再发送
（4）HTTP2支持服务器推送：HTTP2支持在未经客户端许可的情况下，主动向客户端推送内容
数据流：已建立的连接内的双向字节流 可以承载一条或多条消息
HTTP/2 的请求和接收过程：
（1）首先，浏览器准备好请求数据，包括了请求行、请求头等信息，如果是POST方法，那么还要有请求体。
（2）这些数据经过二进制分帧层处理之后，会被转换为一个个带有请求ID编号的帧，通过协议栈将这些帧发送给服务器。
（3）服务器接收到所有帧之后，会将所有相同ID的帧合并为一条完整的请求信息。
（4）然后服务器处理该条请求，并将处理的响应行、响应头和响应体分别发送至二进制分帧层。
（5）同样，二进制分帧层会将这些响应数据转换为一个个带有请求ID编号的帧，经过协议栈发送给浏览器。
（6）浏览器接收到响应帧之后，会根据ID编号将帧的数据提交给对应的请求。
- HTTP 3.0
quic协议是使用udp实现的类似于TCP的可靠传输 类似于TSL的加密传输，减少了tcp三次握手时间，以及tls握手时间
请求方式
- OPTIONS：返回服务器支持的HTTP请求方法，
作用：
1.检测服务器所支持的请求方法
2.在 CORS 中，可以使用 OPTIONS 方法发起一个预检请求，以检测实际请求是否可以被服务器所接受。
- HEAD：向服务器索与GET请求相一致的响应，只不过响应体将不会被返回。
用途：可以不必传输整个响应内容，就可以获取包含在响应消息头中的元信息。
- GET：发送请求
- POST：提交数据 例如提交表单或者上传文件
- get和post的区别：
（1）get请求类似于查找的过程 用户获取数据 可以不用每次都与数据库连接 所以可以使用缓存 post做的一般是删除或修改工作 所以必须与数据库交互 不能使用缓存 因此get请求适合于请求缓存
（2）get传递的参数有限制 post传递的参数没有限制 其实HTTP协议从未规定get/post请求的长度限制 get有长度限制是因为浏览器或WEB服务器限制了URI的长度 不同浏览器和WEB服务器限制的最大长度不一样
（3）get在浏览器回退时无害 post会再次提交请求
（4）get会被浏览器主动catch post不会 需要手动设置
（5）get请求的参数会保留历史记录 post中的参数不会保留
（6）get只接受ASCII字符的参数数据类型 post没有限制
（7）get的参数放在URL中传递 可见且不安全 post参数放在请求体中传递 不可见也较安全
（8）get体积小 post可以无限大
（9）get更简单 快速 高效- 什么时候使用post：post请求一般用于修改服务器上的资源 对所发送的信息没有限制
（1）无法使用缓存文件（更新服务器上的文件或数据库）
（2）向服务器发送大量数据（post没有数据量限制）
（3）发送包含未知字符的用户输入时 post比get更稳定也更可靠
- PUT：上传最新内容
- DELETE：删除指定资源
- TRACE：回显服务器收到的请求，主要用于测试或诊断
- CONNECT：HTTP1.1协议中预留给能够将连接改为管道方式的代理服务器。
- PATCH：对资源应用部分修改
状态码
1XX：请求已被接收，需要进一步处理
2XX：请求成功
200：服务器已成功处理请求
3XX：重定向
301：永久重定向。请求的资源已经永久移动到新地址 服务器返回此响应告知浏览器以后都去新地址请求该资源，并自动跳转到新位置，与location配合使用。
应用：域名需要切换、协议从http变成https；
302：临时重定向。请求的资源临时移动到新地址 服务器返回此响应告知浏览器，这次去新地址获取资源，以后还是取旧地址请求该资源，并自动跳转到新位置，与location配合使用。
- 应用：未登录时访问已登录页时跳转到登录页面、404后跳转首页
- 302会出现“网址劫持”现象，从A网址302重定向到B网址，由于搜索引擎或B网址的一些原因，导致浏览器的地址栏显示A网址，但是网页内容却是B网址上的内容。
- 301、302的相同点：都表示重定向，新地址可以从响应的Location首部中获取（用户看到的效果就是他输入的地址A瞬间变成了另一个地址B）
304：未修改。自从上次请求后，请求的网页未修改，直接从缓存中拿。
4XX：客户端的错误
403：服务器拒绝客户端的请求，客户端没有请求服务器的权限。
404：服务器找不到你要请求的网页
5XX：服务器的错误
500：服务器内部出错
502：错误的网关。产生错误的原因是连接超时，我们向服务器发送请求，由于服务器当前链接太多，导致服务器方面无法给于正常的响应
504：网关超时
请求头
Accept：浏览器可以接受服务器回发的类型
Accept-Encoding：浏览器申明自己是否支持压缩，支持什么压缩方法
Accept-Language：浏览器申明自己接收的语言。
Connection
Connection：keep-alive 当一个请求完成后，客户端和服务器之间用于传输数据的TCP连接不会关闭，如果客户端再次访问该服务器上的这个资源，会继续使用这一条已经建立的连接。
Connection：close 代表一个请求完成后，客户端和服务器之间用于传输数据的TCP连接会关闭， 当客户端再次发送请求时，需要重新建立TCP连接。
Cache-Control
Cache-Control：no-cache 不使用缓存
Cache-Control：max-age=seconds 告知服务器客户端希望接收一个存在时间(age)不大于seconds的资源。单位s
Cookie是用来存储一些用户信息以便让服务器辨别用户身份的，比如cookie会存储一些用户的用户名、密码、sessionid等，当用户登录后就会在客户端产生一个cookie来存储相关信息，这样浏览器通过读取cookie的信息去服务器上验证并通过后会判定你是合法用户，从而允许查看相应网页。
Host：请求的服务器的主机名，它通常从URL中提取出来的。
Referer：告诉服务器我是从哪个页面链接过来的
Origin：最初的请求是从哪里发起的 只会精确到端口 比Referer更尊重隐私
Range：bytes=0-5 指定第一个字节的位置和最后一个字节的位置。用于告诉服务器自己想取资源的哪部分。用于断点续传。
User-Agent：告诉服务器， 客户端使用的操作系统和浏览器的名称和版本。
响应头
Cache-Control
Cache-Control：private 返回报文中全部或指定客户端可以缓存资源
Cache-Control：public 任何情况下都缓存该资源
Cache-Control：must-revalidate 对于客户机的每次请求，代理服务器必须向服务器验证缓存是否过时
Cache-Control：no-cache 不直接使用强缓存 要向服务器发送过时校验请求
Cache-Control：no-store 请求和响应的信息都不应该被存储在对方的磁盘系统中
Cache-Control：max-age=10 是通知浏览器10秒之内资源是有效的，无需向服务器发送请求，自己从缓冲中取
注意： 请求头里的Cache-Control影响的是当前这一次请求，响应头里的Cache-Control是告诉浏览器这样存储，下次依照这样来。影响的是下一次请求。且no-store优先级最高.
Content-Type：text/html;charset=UTF-8 告诉客户端资源文件的类型、字符编码。
Content-Encoding：gzip 告诉客户端，服务端发送的资源是采用gzip压缩的。
Connection：keep-alive 这个字段作为回应客户端的Connection：keep-alive，告诉客户端服务器的tcp连接也是一个长连接，客户端可以继续使用这个tcp连接发送http请求。
Date: Tue, 03 Apr 2018 03:52:28 GMT 这个是服务端发送资源时的时间，GMT是格林尼治所在地的标准时间。http协议中发送的时间都是GMT的，这主要是解决在互联网上，不同时区在相互请求资源的时候，时间混乱问题。
Server：Tengine/1.4.6 告诉客户端服务器和相对应的版本信息。
Transfer-Encoding：chunked 告诉客户端，服务器发送的资源的方式是分块发送的。一般分块发送的资源都是服务器动态生成的，在发送时还不知道发送资源的大小，所以采用分块发送，每一块都是独立的，独立的块都能标示自己的长度，最后一块是0长度的，当客户端读到这个0长度的块时，就可以确定资源已经传输完了。
Expires：Sun, 1 Jan 2000 01:00:00 GMT 告诉客户端在这个时间前，可以直接访问缓存副本，很显然这个值会存在问题，因为客户端和服务器的时间不一定会都是相同的，如果时间不同就会导致问题。所以这个响应头是没有Cache-Control：max-age=* 这个响应头准确的，因为max-age=date中的date是个相对时间，不仅更好理解，也更准确。
Last-Modified：所请求的资源最后修改日期
ETag: “737060cd8c284d8af7ad3082f209582d” 就是一个对象（比如URL）的标志值，就一个对象而言，比如一个html文件，如果被修改了，其Etag也会被修改，所以，ETag的作用跟Last-Modified的作用差不多，主要供WEB服务器判断一个对象是否改变了。比如前一次请求某个html文件时，获得了其 ETag，当这次又请求这个文件时，浏览器就会把先前获得ETag值发送给WEB服务器，然后WEB服务器会把这个ETag跟该文件的当前ETag进行对比，然后就知道这个文件有没有改变了。
ETag比Last-Modified准确：因为资源被修改了 但是内容没有变 不如加了格空格 ETag依旧不变 但是Last-Modified会改变
Refresh：* 用于重定向，或者当一个新的资源被创建时。默认会在5秒后刷新重定向。
Access-Control-Allow-Origin：指定哪些网站可以跨域资源共享 *号代表所有网站可以跨域资源共享，如果当前字段为那么Access-Control-Allow-Credentials就不能为true
Access-Control-Allow-Methods：GET,POST,PUT,DELETE 允许哪些方法来访问
Access-Control-Allow-Credentials: true 是否允许发送cookie。默认情况下为true，即表示服务器明确许可Cookie可以包含在请求中一起发给服务器。如果服务器不要浏览器发送Cookie，删除该字段即可。如果access-control-allow-origin为，当前字段就不能为true
Content-Range：bytes 0-5/7877一个数据片段在整个资源中的位置
Set-Cookie
HTTPS
- HTTPS：HTTP的安全版 即HTTP下加入SSL层/TSL层（TSL是改进版 更高效 二者区别不大）
通常HTTP直接和TCP通信，HTTPS则先和安全层通信，然后安全层再和TCP层通信。也就是说HTTPS所有的安全核心都在安全层，它不会影响到上面的HTTP协议，也不会影响到下面的TCP/IP
- 作用
（1）内容加密：建立一个信息安全通道，来保证数据传输的安全
（2）身份认证：确认网站的真实性
（3）数据完整性：防止内容被第三方冒充或者篡改
如何保证安全？介绍SSL
- SSL：安全套接层，工作于传输层和应用层之间，为应用提供数据的加密传输
在TCP和HTTP之间插入一个安全层，所有经过安全层的数据都会被加密或者解密
- 对称加密和非对称加密实现HTTPS/HTTPS如何保证安全的/SSL如何工作的？：
（1）客户端首先向服务器发送建立TCP连接的请求 经过三次握手后建立连接 然后 客户端会向服务端发送HELLO报文，这个报文中包含了客户端所支持的密码算法列表和随机数client-random；
（2）服务器保存随机数client-random，选择自己支持的对称加密算法和非对称加密算法，然后生成随机数service-random，并和数字证书一起发送给客户端；
（3）浏览器保存公钥，并利用client-random和service-random计算出来pre-master，然后利用公钥对pre-master加密，并向服务器发送加密后的数据；
（4）最后服务器拿出自己的私钥，解密出pre-master数据，并返回确认消息
（5）现在服务器和浏览器就有了共同的client-random、service-random和pre-master，然后服务器和浏览器会使用这三组随机数生成对称密钥，因为服务器和浏览器使用同一套方法来生成密钥，所以最终生成的密钥也是相同的。
（6）有了对称加密的密钥之后，双方就可以使用对称加密的方式来传输数据了 - SSL 连接断开后如何恢复：
（1）Session ID：每一次的会话都有一个编号，当对话中断后，下一次重新连接时，只要客户端给出这个编号，服务器如果有这个编号的记录，那么双方就可以继续使用以前的密钥，而不用重新生成一把。
（2）Session Ticket：是服务器在上一次对话中发送给客户端的，这个 ticket 是加密的，只有服务器能够解密，里面包含了本次会话的信息，比如对话密钥和加密方法等。这样不管我们的请求是否转移到其他的服务器上，当服务器将 ticket 解密以后，就能够获取上次对话的信息，就不用重新生成对话秘钥了。
HTTPS和HTTP的区别
（1）https协议需要到ca申请证书，要花钱。
（2）http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。
（3）http和https使用的端口不一样，前者是80，后者是443。
（4）http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。
加密算法
- 数字签名
（1）数字签名：用HASH函数对原文产生一个摘要信息 将摘要信息用发送者的私钥加密，与原文一起传送给接收者。接收者只有用发送者的公钥才能解密被加密的摘要信息，然后用HASH函数对收到的原文产生一个摘要信息，与解密的摘要信息对比。如果相同，则说明收到的信息是完整的，在传输过程中没有被修改；否则说明信息被修改过，因此数字签名能够验证信息的完整性。
（2）数字签名是个加密的过程，数字签名验证是个解密的过程。
（3）作用：保证信息传输的完整性、发送者的身份认证 - 数字证书：由CA机构发行，数字证书绑定了公钥及其持有者的真实身份，人们可以在网上用它来识别对方的身份。
- 服务器如何申请数字证书：
（1）首先服务器需要准备一套私钥和公钥，私钥留着自己使用；
（2）然后服务器向 CA 机构提交公钥、公司、站点等信息并等待认证，这个认证过程可能是收费的；
（3）CA 通过线上、线下等多种渠道来验证服务器所提供信息的真实性，如公司是否存在、企业是否合法、域名是否归属该企业等；
（4）如信息审核通过，CA 会向服务器签发认证的数字证书，包含了服务器的公钥、组织信息、CA 的信息、有效时间、证书序列号等，这些信息都是明文的，同时包含一个 CA生成的签名。（首先CA使用Hash函数来计算网站提交的明文信息，得到摘要信息；然后CA使用它的私钥对信息摘要进行加密，加密后的密文就是CA颁给极客时间的数字签名。）- 浏览器如何验证 CA 证书?
（1）首先浏览器读取证书中的证书所有者、有效期等信息进行校验，校验证书来源的网站域名是否与证书中记录的颁发域名一致，校验证书是否在有效期内（校验证书所有者、证书是否过期）。
（2）浏览器开始查找操作系统中已内置的受信任的证书发布机构 CA，与服务器发来的证书中的颁发者 CA 比对，用于校验证书是否为合法机构颁发（校验 CA 机构）。
（3）客户端用内置的 CA 机构的公钥解密证书的数字签名，得到证书明文的摘要信息；将证书明文用一样的方法（证书里有说明签名算法）计算出摘要信息。两个摘要信息一样证书才合法。
- 对称加密算法：加密和解密都是使用的同一个密钥。
缺点：如果和每个用户都约定一个独立的密钥，如何把密钥传输给对方，又是一个安全难题
- 非对称加密算法：加密和解密使用不同密钥的加密算法。非对称加密算法有 A、B 两把密钥，如果你用 A 密钥来加密，那么只能使用 B 密钥来解密；反过来，如果你要 B 密钥来加密，那么只能用 A 密钥来解密。
缺点：加密解密耗时长 只适合对少量数据进行处理
- 消息验证码MAC：使用对称加密算法，发送方和接收方事先共享同一个密钥。发送方将要发送的信息和密钥进行MAC运算，得到MAC值，并把MAC值与信息一同发送给接收方。接收方接收到信息后，将信息与事先共享的密钥进行MAC运算，得到MAC值，将MAC值与发送方发送的MAC值进行比较，如果一致，证明信息是来自发送方且没有被篡改过。
- MAC、数字签名的区别：数字签名使用的是非对称加密算法，而MAC使用对称加密算法。
TCP
- TCP：传输控制协议，是一种面向连接、确保数据在端到端间可靠传输的协议，基于字节流。
面向连接：在发送数据前，需要先建立一条虚拟链路，然后让数据在这条链路上完成传输
端到端：只管接收端是谁 别的啥也不管
可靠：要确保通信双方的通信信息不会丢失，若丢失了保证能够对其进行恢复，并且收到的信息内容与原发送内容一样。
- TCP的flag由6个bit组成：
（1）SYN：用作建立连接时的同步信息
（2）ACK：用于对收到的数据进行确认，所确认的数据由确认序列号表示
（3）FIN：所建立的连接需要关闭 - TCP如何实现可靠传输：传输数据之前，三次握手建立连接，并且在数据传递时，有确认、窗口、重传、拥塞控制机制，数据传完之后，四次挥手断开连接，节省系统资源。
在 TCP 中，传输报文都是通过建立的虚拟连接来进行传输，发送端传输的每一个 TCP 报文，都会对其进行编号（编号是由于网络传输的原因，发送的报文可能会乱序到达，因此需要根据编号对报文进行重排），并且开启一个计时器；当接收端收到报文后，并且通过校验和对收到的报文数据进行校验，若校验成功则会返回一个确认报文，告知发送端我已经成功收到该报文了；若发送端在计时器结束前仍未收到确认报文，则认为接收端接收失败，则会重传该报文；服务端若收到重复报文（根据编号发现已经是收到了），则会将该报文丢弃。
（1）校验和：TCP的首部字段中有一个字段是校验和，发送方将伪首部、TCP首部、TCP数据使用 累加和校验的方式计算出一个数字，然后存放在首部的校验和字段里，接收者收到TCP包后重复这个过 程，然后将计算出的校验和和接收到的首部中的校验和比较，如果不一致则说明数据在传输过程中出错。
（2）序列号：在 TCP 中，传输报文都是通过建立的虚拟连接来进行传输，发送端传输的每一个 TCP 报文，都会对其进行编号（编号是由于网络传输的原因，发送的报文可能会乱序到达，因此需要根据编号对报文进行重排），并且开启一个计时器；当接收端收到报文后，并且通过校验和对收到的报文数据进行校验，若校验成功则会返回一个确认报文，告知发送端我已经成功收到该报文了；若发送端在计时器结束前仍未收到确认报文，则认为接收端接收失败，则会重传该报文；服务端若收到重复报文（根据编号发现已经是收到了），则会将该报文丢弃。
（3）确认应答
（4）超时重传：
（5）流量控制：当接收方来不及处理发送方的数据，能通过滑动窗口，提示发送方降低发送的速率，防止包丢失。
（6）拥塞控制：当网络拥塞时，通过拥塞窗口，减少数据的发送，防止包丢失。
慢开始 拥塞避免 快重传 快恢复
拥塞控制
- 拥塞：网络堵了 网络状况不好
- 产生拥塞的条件：对网络资源的需求总和大于可用资源
网络资源：网络的链路容量 如带宽 假如这条链路是50兆的带宽 很多主机都往这个链路上发送数据，就导致该链路的带宽不够大家使用了 导致网络出现拥塞；交换节点的缓存交换节点的处理机 如路由器中的处理机等
如果在某段时间对于网络中某一个资源的需求总和超过了这个资源它可以提供的可用部分那网络性能会变差
- 拥塞控制的目的：防止过多的数据注入到网络中
- 拥塞控制与流量控制的区别：
（1）拥塞控制：发送方们使用同一个网络资源给接收方发送数据 就会使得网络繁忙 甚至出现拥塞的状况 接收方不知道是哪些主机发送速度过快/发送数据过多导致的拥塞
（2）流量控制是点对点之间的通信量的控制 是一种端到端的问题 如果数据过多来不及接收了 接收方知道是哪台主机造成的
（3）拥塞是由于网络发生堵塞 导致很多发送方发送的数据到不了接收方
（4）流量控制是由于发送方发送数据速率过快导致接收方接受缓存或接收窗口不够 来不及接收数据 - 拥塞的标识/如何判断网络拥塞：（1）重传计时器超时（2）接收到三个重复确认
- 拥塞控制四种算法：慢开始与拥塞避免 快重传与快恢复
在研究这四种算法前 需要假定：
（1）一方发送数据 一方只发送确认报文段
（2）接收方总是有足够大的缓存空间 因而发送窗口大小取决于拥塞程度 发送窗口=Min{接收窗口rend，拥塞窗口cwnd}
接收窗口：接收方根据接收缓存设置的值 并告知给发送方 反应接收方容量
拥塞窗口：发送方根据自己估算的网络拥塞程度而设置的窗口值 反应网络当前容量 会随着网络拥塞程度以及所使用的拥塞控制算法动态变化。
传输轮次：发送方给接收方发送数据报文段，接收方返回确认报文段，发送方收到该确认报文段这一过程称为一个传输轮次。一个传输轮次所经历的时间就是往返时间RTT(RTT并非是恒定的数值），使用传输轮次是为了强调，把拥塞窗口cwnd所允许发送的报文段都连续发送出去，并收到了对已发送的最后一个报文段的确认。
（1）慢开始与拥塞避免
假设慢开始门限ssthresh为16（个报文段） 当前发送方拥塞窗口cwnd的值为1，发送窗口swnd等于拥塞窗口cwnd，因此发送方当前只能发送一个数据报文段（拥塞窗口cwnd的值是几，就能发送几个数据报文段），接收方收到该数据报文段后，给发送方回复一个确认报文段，发送方收到该确认报文后，将拥塞窗口的值变为2，发送方此时可以连续发送两个数据报文段，接收方收到该数据报文段后，给发送方一次发回2个确认报文段，发送方收到这两个确认报文后，将拥塞窗口的值加2变为4，发送方此时可连续发送4个报文段，接收方收到4个报文段后，给发送方依次回复4个确认报文，发送方收到确认报文后，将拥塞窗口加4，置为8，发送方此时可以连续发送8个数据报文段，接收方收到该8个数据报文段后，给发送方一次发回8个确认报文段，发送方收到这8个确认报文后，将拥塞窗口的值加8变为16，当前的拥塞窗口cwnd的值已经等于慢开始门限值，之后改用拥塞避免算法。也就是每个传输轮次，拥塞窗口cwnd只能线性加一，而不是像慢开始算法时，每个传输轮次，拥塞窗口cwnd按指数增长。同理，16+1……直至到达24，假设24个报文段在传输过程中丢失4个，接收方只收到20个报文段，给发送方依次回复20个确认报文段，一段时间后，丢失的4个报文段的重传计时器超时了，发送发判断可能出现拥塞，将慢开始门限ssthresh的值变为发生拥塞时的发送方拥塞窗口cwnd的一半 将发送方拥塞窗口cwnd置1 重新开始慢开始算法
有时个别报文段会在网络中丢失 但实际上网络并未发生拥塞 这将导致发送发超时重传并误认为网络发生了拥塞 发送方错误的启动慢开始算法 并把拥塞窗口swnd又设为1 因而降低传输效率 于是有了快重传与快恢复算法。
（2）快重传与快恢复
发送方发送1号数据报文段，接收方收到1号报文段后给发送方发回对1号报文段的确认，在1号报文段到达发送方之前，发送方还可以将发送窗口内的2号数据报文段发送出去，接收方收到2号报文段后给发送方发回对2号报文段的确认，在2号报文段到达发送方之前，发送方还可以将发送窗口内的3号数据报文段发送出去，假设该报文丢失，发送方便不会发送针对该报文的确认报文给发送方，发送方还可以将发送窗口内的4号数据报文段发送出去，接收方收到后，发现这不是按序到达的报文段，因此给发送方发送针对2号报文段的重复确认，表明我现在希望收到的是3号报文段，但是我没有收到3号报文段，而收到了未按序到达的报文段，发送方还可以将发送窗口中的5号报文段发送出去,接收方收到后，发现这不是按序到达的报文段，因此给发送方发送针对2号报文段的重复确认，表明我现在希望收到的是3号报文段，但是我没有收到3号报文段，而收到了未按序到达的报文段,，发送方还可以将发送窗口内的最后一个数据段即6号数据报文段发送出去，接收方收到后，发现这不是按序到达的报文段，因此给发送方发送针对2号报文段的重复确认，表明我现在希望收到的是3号报文段，但是我没有收到3号报文段，而收到了未按序到达的报文段，此时，发送方收到了累计3个连续的针对2号报文段的重复确认，立即重传3号报文段，接收方收到后，给发送方发回针对6号报文的确认，表明，序号到6为至的报文都收到了，这样就不会造成发送方对3号报文的超时重传，而是提早收到了重传。
快重传：收到3个重复确认的报文后 立即重传
快重传执行完了之后立即执行快恢复：拥塞窗口降为新的门限值 新的门限值=收到3个重复确认时的拥塞窗口的一半 然后执行拥塞避免算法 线性增加拥塞窗口
建立连接：3次握手
- 过程：
（1）A机器发送一个数据包并将SYN置1，标识希望建立连接，假设包中的序列号为x。此时A机器由listening状态转为SYN_SENT状态
（2）B机器收到A机器发过来的数据包后，通过SYN得知这是一个建立连接的请求，于是发送一个响应包并将SYN和ACK标记都置1，假设这个包中的序列号是y，确认序列号必须是x+1，表示收到了A发过来的SYN。在TCP中，SYN被当作数据部分的一个字节。此时B机器由listening状态转为SYN_RCVD状态
（3）A收到B的响应包后进入established状态，并返回确认包，包中ACK置1，并将确认序列号设置为y+1，表示收到了来自B的SYN。B机器收到A机器发来的ACK后进入established状态 - 为什么要3次握手：
（1）信息对等：只有进行3次握手才能保证 A B两机器的收发能力正常
（2）防止超时：如果两次握手就可以创建链接，假如A机器发送了一个请求连接，这个连接超时了，但是报文仍在网络上传输，A机器重新发送连接请求，和B机器建立连接，传输数据并释放连接后，之前超时的连接请求到达B机器，B机器会以为是A创建新连接的请求，然后确认同意创建连接。因为此时A是established状态而非SYN_SENT状态，所以直接丢弃了B的确认数据，以致于最后只是B机器单方面创建连接完毕。
断开连接：4次挥手
- 过程：
（1）A机器想要关闭连接，则待本方数据发送完毕后，传递FIN信号给B机器。A机器由established状态进入FIN_WAIT_1状态
（2）B机器将ACK置1返回给A机器，此时B机器由established状态进入CLOSE_WAIT状态。B机器相当于告诉A机器可以断开，但是需要等B机器处理完数据，再主动给A机器发送FIN信号。
（3）A机器收到ACK，进入FIN_WAIT_1状态，即半关闭状态，无法再发送新数据。
（4）B机器做好连接关闭前的准备工作后，发送FIN给A机器，B机器进入LAST_ACK状态 也是半关闭状态
（5）A机器发送针对B机器FIN的ACK后，进入TIME_WAIT状态，经过2MSL后，没有收到B机器传来的报文，则确定B机器已经收到A机器最后发送的ACK指令，此时TCP连接正式释放。（B机器收到A机器的ACK后，进入CLOSED状态，A机器等待2MSL后进入CLOSED状态）
2MSL是报文在网络上生存的最长时间，MSL为2分钟，在当前的高速网络中，这个等待时间会造成资源的大量浪费，那为什么不直接进入CLOSED？
（1）确认被动关闭方能够顺利进入CLOSED状态：如果A机器收到B机器的FIN+ACK报文后，发送ACK给B机器，然后立即进入CLOSED，假如这个ACK由于网络原因没有到达B机器，B机器会以为A机器没有收到自己的FIN+ACK报文而重发，而此时A机器已经关闭了，B机器无法进入CLOSED状态。
（2）防止已失效连接的请求数据与正常连接的请求数据包混淆发生异常：已失效的连接指的是握手过程中因为某些原因没有成功，可是也没有断开的连接，有了TIME_WAIT，那么前面已失效的连接就会因为超时而被丢弃，从而不会干扰正常的连接。
- 为什么进行4次挥手，3次行不行：因为挥手多了一个清理现场的部分 就是发送剩余数据、处理现场、关闭资源，若没有什么需要清理的，B机器也可以省略这一阶段，再收到A机器的FIN信号时，直接返回FIN和ACK信号，这样就会变成3次挥手了。
应用
当对网络通讯质量有要求的时候，比如：整个数据要准确无误的传递给对方，这往往用于一些要求可靠的应用，比如HTTP、HTTPS、FTP等传输文件的协议，POP、SMTP等邮件传输的协议。
（1）浏览器，用的HTTP、HTTPS
（2）文件传输，用的FTP
（3）邮件传输，用的POP、SMTP
（4）QQ文件传输
TCP断点重传怎么实现的
每次请求资源都会带上请求的资源的起始点，这样就可以支持从断点下载了。HTTP里的断点续传也是这个原理，在HTTP的头里有个可选的字段RANGE，表示下载的范围
http多个tcp连接怎么实现的
某些服务器支持Connection: keep-alive。意思是说，完成这个 HTTP 请求之后，不要断开 HTTP 请求使用的 TCP 连接。这样的好处是连接可以被重新使用，之后发送 HTTP 请求的时候不需要重新建立 TCP 连接，以及如果维持连接，那么 SSL 的开销也可以避免
TCP为什么要做KeepAlive
当两台机器通过三次握手建立TCP连接后，就可以传输数据了，数据传输完毕，连接并不会自动关闭，而是一直保持。只有两台机器分别通过发送各自的 FIN 报文时，才会关闭自己侧的连接。这个关闭机制看起来简单明了，但实际网络环境千变万化，衍生出了各种问题。假设因为实现缺陷、突然崩溃、恶意攻击或网络丢包等原因，一方一直没有发送 FIN 报文，则连接会一直保持并消耗着资源，为了防止这种情况，一般接收方都会主动中断一段时间没有数据传输的TCP连接，但有的时候我们的确不希望中断空闲的TCP连接，因为建立一次TCP连接需要经过一到两次的网络交互，且由于TCP的慢开始机制，新的TCP连接开始数据传输速度是比较慢的，我们希望保持一部分空闲连接，当需要传输数据时，可以直接使用之前的TCP连接，这样对性能有很大提升。为了支持这种情况，TCP实现了KeepAlive机制。TCP里KeepAlive默认都是关闭的，且是每个连接单独设置的，而不是全局设置。另外当某应用进程关闭后，如果还有该进程相关的TCP连接，一般来说操作系统会自动关闭这些连接。
粘包问题
- 粘包问题：TCP 连接会采用延迟传送算法，在数据发送之前缓存他们。如果短时间有多个数据发送，会缓冲到一起作一次发送（缓冲大小是socket.bufferSize），这样可以减少 IO 消耗提高性能。
- 解决方法：
（1）多次发送之前间隔一个等待时间：处理简单，但是影响传输效率；
（2）关闭 延迟传送算法：消耗资源高，整体性能下降；
（3）封包/拆包：使用一些有标识来进行封包拆包（类似 HTTP 协议头尾）
UDP
- UDP：用户数据报协议，是一种无连接的、不可靠的传输层协议，面向报文。
- 在通信过程中，只要目的地址，端口号，源地址，端口号确定了，就可以直接发送信息报文，并且不需要确保服务端一定能收到或收到完整的数据。它仅仅提供了校验和机制来保障一个报文是否完整，若校验失败，则直接丢弃报文，不做任何处理。
- 应用
（1）当对网络通讯质量要求不高、速度要求尽量快的时候，如QQ语音、QQ视频
（2）应用层的TFTP协议、DNS（域名服务）协议基于UDP的
- 怎么用UDP实现可靠传输，两条连接
在应用层实现。发送端发送数据时，生成一个随机seq=x，然后每一片按照数据大小分配seq。接收端收到数据后放入缓存，并发送一个ack=x的包，表示对方已经收到了数据。发送端收到了ack包后，删除缓冲区对应的数据。时间到后，定时任务检查是否需要重传数据。 - 数据量很大的时候，UDP怎么可靠传输
使用UDT协议，UDT的主要目的是支持高速广域网上的海量数据传输。UDT建于UDP之上，并引入新的拥塞控制和数据可靠性控制机制。UDT是面向连接的、双向的应用层协议。它同时支持可靠的数据流传输和部分可靠的数据报传输。它也可以应用在点到点技术（P2P），防火墙穿透，多媒体数据传输等等。
TCP、UDP的区别
- TCP是面向连接的，可靠性高；UDP是无连接的，可靠性低
- 由于TCP是连接的通信，需要有三次握手、重新确认等连接过程，会有延时，实时性差，同时过程复杂，也使其易于攻击；UDP没有建立连接的过程，因而实时性较强，也稍安全
- 在传输相同大小的数据时，TCP首部开销20字节；UDP首部开销8字节，TCP报头比UDP复杂，故实际包含的用户数据较少。
- TCP在IP协议的基础上添加了序号机制、确认机制、超时重传机制等，保证了传输的可靠性，不会出现丢包或乱序，而UDP有丢包，故TCP开销大，UDP开销较小
- 每条TCP连接只能时点到点的；UDP支持一对一、一对多、多对一、多对多的交互通信
TCP/IP
- TCP/IP：定义了电子设备如何连入因特网，以及数据如何在它们之间进行传输。
- 4层网络模型、协议栈
（1）应用层：定义数据格式，并按照对应的格式解读数据。
（2）传输层：定义端口，确认主机上应用程序的身份，并将数据包交给对应的应用程序；
（3）网络层：主要负责寻找地址和路由选择。
（4）链路层：物理地址寻址、数据的成帧，传输数据
客户端缓存/浏览器缓存
为了节约网络的资源加速浏览，浏览器在用户磁盘上对最近请求过的文档进行存储，当访问者再次请求这个页面时，浏览器就可以从本地磁盘显示文档，这样就可以加速页面的阅览。是（web）缓存的一种。
HTTP缓存
-
强缓存：浏览器第一次向服务器发送请求或缓存过期后浏览器向服务器发送请求，得到数据后，浏览器数据中响应头的cache-control的信息知道这个数据要缓存，然后就将数据缓存在本地浏览器，以后每次浏览器向服务器请求数据时，浏览器根据URL知道请求的数据已缓存，就不向服务器发请求了，直接从缓存中将数据及状态码200返回。
-
协商缓存：浏览器第一次向服务器请求数据，服务器会返回数据及数据在服务器上的唯一标识Last-Modified或Etag，浏览器以后每次向服务器发送请求时都会带上这个标识，服务器会将其与当前服务器上该资源的标识进行对比，若一样，则返回304，告诉浏览器资源未改变，直接从缓存中取，若不一样，则返回数据及新的标识。
-
缓存机制：浏览器访问服务器时，先查看是否有缓存及缓存是否过期，如果有缓存且缓存未过期，则直接使用缓存并返回200状态码，否则查看是否有ETag，若有则携if-None-Match向服务器发送请求，若没有则查看是否有Last-Modified，若有则携带if-Modified-Since向服务器发送请求，服务器通过比对浏览器带来的标识和服务器上该资源目前的标识，若相同则返回304告知浏览器资源未改变，从缓存中取，若不相同，则返回资源、新的资源标识、状态码200。若两个标识都没有，则浏览器向服务器发送请求，服务器返回数据及ETag或Last-Modified，浏览器保存标识并根据响应头cache-control决定是否缓存资源。
-
刷新操作对缓存的影响：
a.正常刷新：跳转页面、前进后退、输入URL：强缓存 协商缓存都有效
b.手动刷新：F5、刷新按钮、菜单栏刷新：强缓存无效 协商缓存有效
c.强制刷新：CTRL+F5：强缓存 协商缓存都无效 -
应用：可以将不会改变的东西强缓存下来 对于一些不经常改变但是定期还是会变的东西协商缓存下来
-
与缓存相关的请求头 响应头
Web Storage
cookie
- 特点：
（1）容量4K
（2）常用于存储用户身份信息
（3）可以设置有效期 若设置了有效期，浏览器就会把cookie保存到硬盘上，关闭后再次打开浏览器，这些cookie仍然有效直到超过设定的过期时间。存储在硬盘上的cookie可以在不同的浏览器进程间共享，比如两个IE窗口。而对于保存在内存里的cookie，不同的浏览器有不同的处理方式
（4）cookie得同源协议：域名、路径一致即同源 - 危害：
（1）如果只使用cookie进行身份认证而不使用session与服务器配合进行身份验证的话，会有危险，黑客可能会盗取你的cookie，模仿你的身份向服务器发送请求
（2）如果没有配置httpOnly的话，可能会被js脚本盗取cookie - 安全策略：
（1）cookie的有效期不要设置太长，合适即可
（2）httpOnly设为true 禁止JS脚本获取cookie
（3）cookie设复杂一点 cookie得key随机生成 cookie的值可以使用复杂的组合 如：用户名+当前时间+有效时间+随机数 使cookie难解密
（4）用户第一次登录时 将ip和cookie进行加密形成token保存起来 每次浏览器来访问服务器 都将ip和cookie进行加密形成token 两个token一样才校验成功 - 运行机制：客户端访问服务器 服务器响应客户端，响应头中包含Set-Cookie字段 客户端保存cookie，之后向服务器发送请求时，请求头中会包含一个Cookie字段 服务器返回相应数据
session
- 服务器要知道当前给自己发请求的是谁 就会给每个客户端分配不同的sessionID 客户端每次给服务器发请求时都会带上这个sessionID
- session是一个会话 当页面不同即使同一页面打开两次 也被视为同一会话
- 服务器使用session将用户的信息临时保存在了服务器上 用户离开网站后session会被销毁
- 缺点：如果服务器做了负载均衡 那么下一个操作请求到了另一台服务器的时候 session会丢失
- 总结：当程序需要为某个客户端的请求创建一个session时，服务器首先检查这个客户端的请求里是否已包含了一个session标识（称为session id），如果已包含则说明以前已经为此客户端创建过session，服务器就按照session id把这个session检索出来使用（检索不到，会新建一个），如果客户端请求不包含session id，则为此客户端创建一个session并且生成一个与此session相关联的session id，session id的值应该是一个既不会重复，又不容易被找到规律以仿造的字符串，这个session id将被在本次响应中返回给客户端保存。保存这个session id的方式可以采用cookie，这样在交互过程中浏览器可以自动的按照规则把这个标识发送给服务器。一般这个cookie的名字都是类似于SEEESIONID。但cookie可以被人为的禁止，则必须有其他机制以便在cookie被禁止时仍然能够把session id传递回服务器。
localstorage
- 特点：
（1）容量5M
（2）同一浏览器同源共享
（3）需要手动删除 - 应用：保存一些页面关闭后仍然留下来的东西 比如可以将首页保存在localstorage中 避免每次取回数据前页面一片空白 可以存储页面上一些不易修改的数据 如保存购物车的内容
- 危害：同步执行 会阻塞UI
sessionstorage
- 特点：
（1）容量5M
（2）页面关闭立即销毁
（3）同一页面共享 - 应用：适合单页面应用程序 音乐播放器播放进度条
- 危害：同步执行 会阻塞UI
token
- token在客户端一般存放于localStorage、cookie、sessionStorage中。在服务器一般存于数据库中。
- 认证流程：客户端登陆传递信息给服务端，服务端收到后把用户信息加密（token）传给客户端，客户端将token存放于localStroage等容器中。客户端每次访问都传递token，服务端解密token，就知道这个用户是谁了。
- token与cookie的区别：token可以抵抗csrf，cookie+session不行：因为form 发起的 POST 请求并不受到浏览器同源策略的限制，因此可以任意地使用其他域的 Cookie 向其他域发送 POST 请求，形成 CSRF 攻击。在post请求的瞬间，cookie会被浏览器自动添加到请求头中。但token不同，token是开发者为了防范csrf而特别设计的令牌，浏览器不会自动添加到headers里，攻击者也无法访问用户的token，所以提交的表单无法通过服务器过滤，也就无法形成攻击。
- cookie localstorage sessionstorage共同点：都将数据保存在本地硬盘上
保持前后端实时通信的方法
- WebSocket 是 HTML5 提供的一种在单个 TCP 连接上进行全双工通讯的协议。浏览器和服务器只需要一次握手，就可以进行持续的，双向的数据传输，因此能节约资源和带宽 常用于实时性要求高的场景
缺点：1. 兼容性问题:不支持较低版本的IE浏览器2.不支持断线重连3.通信机制相对复杂 - server-sent-event（event-source）
优点：（1）只需一次请求，便可以流的方式多次传送数据，节约资源和带宽 （2）相对WebSocket来说简单易用 （3）内置断线重连功能
缺点： （1）是单向的，只支持服务端->客户端的数据传送，客户端到服务端的通信仍然依靠AJAX（2）IE浏览器完全不支持 - AJAX轮询
优点：兼容性良好，对标低版本IE
缺点：请求中有大半是无用的请求，浪费资源 - Flash Socket
缺点：（1）浏览器开启时flash需要用户确认（2）加载时间长，用户体验较差 （3）大多数移动端浏览器不支持flash
优点： 兼容低版本浏览器 - 永久帧（ forever iframe）
缺点： iframe会产生进度条一直存在的问题，用户体验差
优点：兼容低版本IE浏览器
CDN
CDN的全称是Content Delivery Network，即内容分发网络。其目的是通过在现有的网络中增加一层新的网络架构，将网站的内容发布到最接近用户的网络边缘，使用户可以就近取得所需的内容，提高用户访问网站的响应速度。
CDN加速原理
- 当用户点击网站页面上的url时，经过本地dns系统解析，dns系统会将域名的解析权给交cname指向的cdn专用dns服务器。
- cdn的dns服务器将cdn的全局负载均衡设备ip地址返回给用户。
- 用户向cdn的全局负载均衡设备发起内容url访问请求。
- cdn全局负载均衡设备根据用户ip，以及用户请求的内容url，选择一台用户所属区域的区域负载均衡设备
- 区域负载均衡设备会为用户选择一台合适的缓存服务器提供服务，选择的依据包括：根据用户IP地址，判断哪一台服务器距用户最近；根据用户所请求的URL中携带的内容名称，判断哪一台服务器上有用户所需内容；查询各个服务器当前的负载情况，判断哪一台服务器尚有服务能力。基于以上这些条件的综合分析之后，区域负载均衡设备会向全局负载均衡设备返回一台缓存服务器的IP地址全局负载均衡设备把服务器的IP地址返回给用户。
- 用户向缓存服务器发起请求，缓存服务器响应用户请求，将用户所需内容传送到用户终端。如果这台缓存服务器上没有用户想要的内容，而区域均衡设备依然将它分配给了用户，那么这台服务器 就要向它的上一级缓存服务器发起请求内容，直至追溯到网站的源服务器将内容拉回给用户。
同源协议
- 同源协议：浏览器为了安全起见提出的协议 他要求A机器向B机器请求数据时 A B机器的协议、域名、端口号都相同
- 为什么提出同源协议
为了避免你自己的页面访问别人的网站，别的网站对页面进行一系列的改动 - 同源策略的限制
（1）Cookie、LocalStorage 和 IndexDB 无法读取。
（2）DOM 无法获得。
（3）AJAX 请求不能发送。 - 同源策略作用
（1）防止恶意网页可以获取其他网站的本地数据。
（2）防止恶意网站iframe其他网站的时候，获取数据。
（3）防止恶意网站在自已网站有访问其他网站的权利，以免通过cookie免登，拿到数据。
跨域
- 跨域解决方案
（1）CORS：在后端的响应头中设置 支持所有请求 低版本浏览器不兼容
res.setHeader(‘Access-Control-Allow-Origin’, ‘*’)
res.setHeader(‘Access-Control-Allow-methods’, ‘GET,POST,PUT,OPTION’)
（2）postmessage：假如你有一个主页面 主页面中有一个iframe页面 两个页面相通信 那么主页面可以用postmessage发送数据 iframe监听数据window.addEventListener
（3）node中间件 nginx反向代理：都是靠CORS实现的
（4）websocket
（5）JSONP：利用script标签可以跨域的特性 将回调函数作为参数拼接在url中 服务器收到请求后调用回调函数 并将数据作为参数 一起返回给客户端 只支持get请求
缺点：
（1）只支持GET请求
（2）不能注册success error等事件监听函数 不能很容易的确定JSONP请求是否失败
（3）JSOP是从其他域中加载代码执行 很容易受到CSRF攻击
- 允许跨域加载资源的标签
<img src='xxx'>
<link href='xxx'>
<script src='xxx'> - 为什么要解决跨域问题：浏览器禁止非同源的请求
- 同域请求的并发数限制的原因：chorme和firefox的限制请求数都是6。基于浏览器端口的限制和线程切换开销的考虑，浏览器为了保护自己不可能无限量的并发请求，如果一次性将所有请求发送到服务器，也会造成服务器的负载上升。
网络安全
中间人攻击
- 过程：
（1）服务器向客户端发送公钥；
（2）攻击者截获公钥，保留在自己手上；
（3）然后攻击者自己生成一个【伪造的】公钥，发给客户端；
（4）客户端收到伪造的公钥后，生成加密 hash（秘钥） 值发给服务器；
（5）攻击者获得加密 hash 值，用自己的私钥解密获得真秘钥；
（6）同时生成假的加密 hash 值，发给服务器；
（7）服务器用私钥解密获得假秘钥；
（8）服务器用假秘钥加密传输信息；
在将 HTTP 数据提交给 TCP 层之后，数据会经过用户电脑、WiFi 路由器、运营商和目标服务器，在这中间的每个环节中，数据都有可能被窃取或篡改。比如用户电脑被黑客安装了恶意软件，那么恶意软件就能抓取和篡改所发出的 HTTP 请求的内容。或者用户一不小心连接上了 WiFi 钓鱼路由器，那么数据也都能被黑客抓取或篡改。
- 防范：服务器在发送浏览器的公钥中加入 CA 证书，浏览器可以验证 CA 证书的有效性
XSS
- XSS攻击：恶意攻击者往web页面中插入了恶意script代码 当用户浏览该页面时 嵌入其中web里面的script代码就会被执行 从而达到恶意攻击用户的目的。
- 恶意script代码能做的事：
（1）可以窃取 Cookie 信息。恶意 JavaScript 可以通过document.cookie获取 Cookie 信息，然后通过XMLHttpRequest或者Fetch加上CORS功能将数据发送给恶意服务器；恶意服务器拿到用户的Cookie信息之后，就可以在其他电脑上模拟用户的登录，然后进行转账等操作。
（2）可以监听用户行为。恶意 JavaScript 可以使用addEventListener接口来监听键盘事件，比如可以获取用户输入的信用卡等信息，将其发送到恶意服务器。黑客掌握了这些信息之后，又可以做很多违法的事情。
（3）可以通过修改 DOM伪造假的登录窗口，用来欺骗用户输入用户名和密码等信息。
（4）可以在页面内生成浮窗广告，这些广告会严重地影响用户体验。等 - 注入恶意脚本的方式：存储型XSS攻击、反射型XSS攻击、基于DOM的XSS攻击
- 无论是何种类型的 XSS 攻击，它们都有一个共同点，那就是首先往浏览器中注入恶意脚本，然后再通过恶意脚本将用户信息发送至黑客部署的恶意服务器上。所以要阻止 XSS 攻击，我们可以通过阻止恶意 JavaScript 脚本的注入和恶意消息的发送来实现。
（1）服务器对输入脚本进行过滤或转码
code:<script>alert('你被 xss 攻击了')</script>
// 过滤后：
code:
// 转码后
code:<script>alert(' 你被 xss 攻击了 ')</script>
（2）充分利用 CSP。CSP 有如下几个功能：
a. 限制加载其他域下的资源文件，这样即使黑客插入了一个JS文件，这个JS文件也是无法被加载的；
b. 禁止向第三方域提交数据，这样用户数据也不会外泄；
c. 禁止执行内联脚本和未授权的脚本；
d. 还提供了上报机制，这样可以帮助我们尽快发现有哪些 XSS 攻击，以便尽快修复问题。
为了解决 XSS 攻击，浏览器中引入了内容安全策略，称为 CSP。CSP 的核心思想是让服务器决定浏览器能够加载哪些资源，让服务器决定浏览器是否能够执行内联 JavaScript 代码。
（3）使用 HttpOnly 属性来保护Cookie的安全。HttpOnly 是服务器通过 HTTP 响应头来设置的 set-cookie 属性值最后使用了 HttpOnly 来标记该 Cookie
set-cookie: NID=189=M8q2FtWbsR8RlcldPVt7qkrqR38LmFY9jUxkKo3-4Bi6Qu_ocNOat7nkYZUTzolHjFnwBw0izgsATSI7TZyiiiaV94qGh-BzEYsNVa7TZmjAYTxYTOM9L_-0CN9ipL6cXi8l6-z41asXtm2uEwcOC5oh9djkffOMhWqQrlnCtOI; expires=Sat, 18-Apr-2020 06:52:22 GMT; path=/; domain=.google.com; HttpOnly
存储型 XSS 攻击
- 存储型 XSS 攻击大致需要经过如下步骤：
（1)首先黑客利用站点漏洞将一段恶意 JavaScript 代码提交到网站的数据库中；
（2）然后用户向网站请求包含了恶意 JavaScript 脚本的页面；
（3)当用户浏览该页面的时候，恶意脚本就会将用户的 Cookie 信息等数据上传到服务器。
反射型 XSS 攻击
- 在一个反射型 XSS 攻击过程中，恶意 JavaScript 脚本属于用户发送给网站请求中的一部分，随后网站又把恶意 JavaScript 脚本返回给用户。当恶意 JavaScript 脚本在用户页面中被执行时，黑客就可以利用该脚本做一些恶意操作。
- Web 服务器不会存储反射型 XSS 攻击的恶意脚本，这是和存储型 XSS 攻击不同的地方。
基于 DOM 的 XSS 攻击
黑客通过各种手段将恶意脚本注入用户的页面中，比如通过网络劫持在页面传输过程中修改 HTML 页面的内容，这种劫持类型很多，有通过 WiFi 路由器劫持的，有通过本地恶意软件来劫持的，它们的共同点是在 Web 资源传输过程或者在用户使用页面的过程中修改 Web 页面的数据。
CSRF
- CSRF：指黑客引诱用户打开黑客的网站，在黑客的网站中，利用用户的登录状态发起的跨站请求。简单来讲，CSRF 攻击就是黑客利用了用户的登录状态，并通过第三方的站点来做一些坏事。
- 通常当用户打开了黑客的页面后，黑客有三种方式去实施 CSRF 攻击。
（1）自动发起 Get 请求：
（2）自动发起 POST 请求：
（3）引诱用户点击链接： - 的发起 CSRF 攻击的三个必要条件：
（1）目标站点一定要有 CSRF 漏洞；
（2）用户要登录过目标站点，并且在浏览器上保持有该站点的登录状态；
（3）需要用户打开一个第三方站点，可以是黑客的站点，也可以是一些论坛。 - CSRF 攻击不需要将恶意代码注入用户的页面，仅仅是利用服务器的漏洞和用户的登录状态来实施攻击，因此黑客是无法通过 CSRF攻击来获取用户页面数据的；其最关键的一点是要能找到服务器的漏洞，所以说对于 CSRF攻击我们主要的防护手段是提升服务器的安全性。
- 防范：
（1）充分利用好Cookie的SameSite属性，在HTTP响应头中，通过set-cookie字段设置Cookie时，可以带上SameSite选项，SameSite选项通常有Strict、Lax、None三个值。如果SameSite的值是Strict，那么浏览器会完全禁止第三方Cookie。简言之，如果你从极客时间的页面中访问InfoQ的资源，而InfoQ的某些Cookie设置了SameSite = Strict的话，那么这些Cookie是不会被发送到InfoQ的服务器上的。只有你从InfoQ的站点去请求InfoQ的资源时，才会带上这些Cookie。Lax相对宽松一点。在跨站点的情况下，从第三方站点的链接打开和从第三方站点提交Get方式的表单这两种方式都会携带Cookie。但如果在第三方站点中使用Post方法，或者通过img、iframe等标签加载的URL，这些场景都不会携带Cookie。而如果使用None的话，在任何情况下都会发送Cookie数据。
（2）由于 CSRF 攻击大多来自于第三方站点，因此服务器可以禁止来自第三方站点的请求。
怎么判断请求是否来自第三方站点呢?
- HTTP请求头中的Referer：我从哪个网站的链接过来的
但是有一些场景是不适合将来源URL暴露给服务器的，因此浏览器提供给开发者一个选项，可以不用上传Referer值，于是又有了Origin属性，在一些重要的场合，比如通过XMLHttpRequest、Fecth发起跨站请求或者通过Post方法发送请求时，都会带上Origin属性
- HTTP请求头中的Origin属性：最初的请求是从哪里发起的。只包含了协议、域名信息，并没有包含具体的URL路径
因此服务器优先判断Origin，如果请求头中没有包含Origin属性，再根据实际情况判断是否使用Referer值
（3）CSRF Token：首先在浏览器向服务器发起请求时，服务器生成一个CSRF Token（字符串）。然后将该字符串植入到返回的页面中。
浏览器端如果要发起转账的请求，那么需要带上页面中的CSRF Token，然后服务器会验证该CSRF Token是否合法。如果是从第三方站点发出的请求，那么将无法获取到CSRF Token的值，所以即使发出了请求，服务器也会因为CSRF Token不正确而拒绝请
求。
扫一扫
8345
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
