系列文章目录

UDP协议和TCP协议

文章目录

系列文章目录
一：http协议和https协议的区别
二：http协议
- 1.http的报文段
- - 1）请求报文
  - - 1.请求方法
    - 2.URL
    - 3.协议版本
    - 4.请求头部
  - 2）响应报文
  - - 状态码
  - 3）GET与POST的区别
  - 4）资源重定向
  - - 1.资源重定向的分类
    - 2.资源重定向的应用场景
- 2.HTTP常见头
- 3.http缓存问题
- - 1）缓存的类型
  - - ①强制缓存
    - ② 协商缓存
    - ③ 私有缓存
    - ④共享缓存
  - 2）缓存寿命
  - 3）cookie
  - - 1.为什么要使用Cookie，解决了什么问题
    - 2.Cookie的用途
    - 3.Cookie的保存方式
    - 4.Cookie的生存周期
    - 5.Cookie的工作原理
    - 6.cookie的认证
    - 7.Cookie的安全性问题
    - 8.cookie安全策略
    - 9.Cookie的缺陷
  - 4）cookie和session的比较
  - - 1.session
    - 2.Session的工作原理
    - 3.Session和cookie的区别
    - 4.cookie和session结合使用
- 4.http无状态的原因
- 5.HTTP的连接
- - 1）短连接
  - 2）长连接
- 6.HTTP协议版本
- - 1）HTTP/1.0
  - 2）HTTP/1.1
  - 3）HTTP/2
  - 4）HTTP/3
- 7.HTTP REST
三：https协议
- 1.https的优点
- 2.https的缺点
- 3.HTTPS的SSL过程
- 4.HTTPS优化问题
- 5、SSL协议原理（安全套接层）
- 6、SSL和SSH的区别
四：Websocket协议
- 1、为什么用websocket协议
- 2、WebSocket握手的过程
- 3、websocket协议的特点
- 4、websocket和http的不同
五、网络攻击
- 1、xxs攻击的分类
- 2、SQL注入
- 3、钓鱼攻击
- 4、跨域
六：常见问题
- 1.在浏览器中输入一个网址它的运行过程是怎样的
- 2.从打开浏览器输入URL地址到到达服务器上项目中某一个Controller上（/显示主页）的过程是怎样的
- 3.soket编程和http协议
- 5.如何评价按照关键词搜索的算法的好坏
- 6.商品的种类有几十万种，在这种大数据的情况下如何评价搜索算法的好坏
- 7.搜索敏感词汇时，页面被重置的原理

一：http协议和https协议的区别

1、Https通信需要证书，而证书一般需要向认证机构（一般是ca）购买，因而需要一定费用

2、http的连接很简单，是无状态的，信息是明文传输，端口是80

https协议是由 ssl+http 协议构建的可进行加密传输、身份验证的网络协议，比 http 协议安全，端口是443，但是与HTTP通信相比，Https通信会由于加减密处理消耗更多的CPU和内存资源；

二：http协议

HTTP（hyperText transport Protocol）：

超文本传输协议，用于传送www方式的数据，采用了请求/响应模型，客户端向服务器发送了一个请求，服务器以一个状态行作为响应。

HTML就是常见的超文本，它本身只是纯文字文件，但内部用很多标签定义了图片、视频等链接。

关于http原理

1.http的报文段

通常http消息包括客户机向服务器请求消息和服务器向客户机的响应消息，这两种类型的消息由一个起始行，一个或多个头域，一个指示头域结束的空行和可选的消息体组成。

http的头域包括通用头、请求头、响应头、和实体头四个部分，每个头域由一个域名、冒号、和域值三部分组成，域名是大小写无关的，域值前可以添加任何数量的空格符，头域可以被扩张成多行，在每行开始处，使用至少一个空格或制表符。

1）请求报文

1.请求方法

POST 和 PUT 方法区别

GET：请求获取Request——URL所标识的资源

POST：在Request——URL所标识的资源后附加资源

HEAD：请求获取由Request——URL所标识的资源的响应消息报头

PUT：请求服务器存储一个资源，由Request——URL作为其标识（会覆盖URL处的原资源），
如果URI不存在，则要求服务器根据请求创建资源，如果存在，服务器就接受请求内容，并修改URI资源的原始版本。

DELETE：请求服务器删除由Request——URL所标识的资源

TRACE：请求服务器回送收到的请求信息（用于测试和诊断）

CONNECT：保留

OPTIONS：请求查询服务器性能

2.URL

URI全名为Uniform Resource Indentifier（统一资源标识），用来唯一的标识一个资源，是一个通用的概念，URI由两个主要的子集URL和URN组成。

URL全名为Uniform Resource Locator（统一资源定位），通过描述资源的位置来标识资源。

URN全名为Uniform Resource Name（统一资源命名），通过资源的名字来标识资源，与其所处的位置无关，这样即使资源的位置发生变动，其URN也不会变化。

初步了解URL（接口测试必备）
软件测试之接口自动化测试（三）：关于URL

3.协议版本

格式为HTTP/主版本号.次版本号，常用为：HTTP/1.1 HTTP/1.0

4.请求头部

Host：接受请求的服务器地址，可以是IP或者是域名

User-Agent：发送请求的应用名称

Connection：指定与连接相关的属性，例如（Keep_Alive，长连接）

Accept-Charset：通知服务器端可以发送的编码格式

Accept-Encoding：通知服务器端可以发送的数据压缩格式

Accept-Language：通知服务器端可以发送的语言

2）响应报文

1.协议版本

同请求报文

状态码

http协议的状态码 200、301、304、404、502 HTTP状态码解释

1xx：请求已收到继续处理。即表示目前是协议的中间状态，还需要后续请求。

2xx：表示请求成功。

3xx：表示资源重定向，需要重新请求。

4xx：表示客户端请求出错。请求报文错误，客户端错误，服务器无法处理。

5xx：服务器端出错，服务器在处理请求时内部发生了错误。

常用：

101：切换请求协议，从HTTP切换到WebSocket
200：请求成功，有响应体。
301：永久重定向，会缓存。
302：临时重定向，不会缓存。
由于不可预见的原因该页面暂不可用。
303：临时重定向，
用于PUT 或 POST 请求完成之后进行页面跳转来防止由于页面刷新导致的操作的重复触发。
304：协商缓存命中。特殊重定向
400：请求错误。
403：服务器禁止访问，表示客户端请求的报文有错，只是个笼统的错误。
404：资源未找到，表示请求的资源在服务器上不存在或者未找到，所以无法提供给客户端。
501：表示客户端请求的功能还不支持。
502：作为网关或者代理工作的服务器尝试执行请求时，从上游服务器接收到无效的响应。
503：服务器繁忙。
504：作为网关或者代理工作的服务器尝试执行请求时，未能及时从上游服务器（URI标识出的服务器，例如HTTP、FTP、LDAP）或者辅助服务器（例如DNS）收到响应。

3.响应头部

Server：服务器应用软件的名称和版本

Content-Type：响应正文的类型

Content-Length：响应正文的长度

Content-Charset：响应正文所使用的编码

Content-Encoding：响应正文使用的数据压缩格式

Content-Language：响应正文使用的语言

3）GET与POST的区别

GET和POST两种基本请求方法的区别

HTTP的底层是TCP/IP。所以GET和POST的底层也是TCP/IP，也就是说，GET/POST都是TCP链接。GET和POST能做的事情是一样一样的。你要给GET加上request body，给POST带上url参数，技术上是完全行的通的。不过HTTP协议给两种方法限定了规则。

1）作用不同

GET方法的含义是请求从服务器获取资源（静态文本、图片视频等）。
POST方法则是向URL指定的资源提交数据，数据就放在报文的body里面，用于传输实体主体。

2）产生的数据包个数不同

GET产生一个TCP数据包，对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；
POST产生两个TCP数据包。对于POST，浏览器先发送header，服务器响应100，浏览器再发送data，服务器响应200（返回数据）。

3）GET比POST更不安全。

GET参数通过URL传递，参数直接暴露在URL上，对所有人是可见的，浏览器会主动缓存get请求，参数被完整保留在浏览器历史记录里。所以不能用来传递敏感信息。
POST的参数放在Request body中，数据不会显示在URL中；浏览器不会主动缓存post请求，参数不会被保存在浏览器历史记录或者web服务器日志中，因此相对安全。

4）后退按钮或者刷新的影响不同

GET在浏览器回退时是无害的，
POST方法在刷新或者回退后数据会被重新提交（浏览器应该告知用户数据会被重新提交）

5）编码方式不同

GET请求只能进行url编码，
POST支持多种编码方式。

6）参数

GET请求在URL中传送的参数是有长度限制的，对参数的数据类型，GET只接受ASCII字符。
POST方法对参数的长度以及数据类型无限制。

4）资源重定向

HTTP 的重定向

URL 重定向，也称为 URL 转发，是一种当实际资源，如单个页面、表单或者整个 Web 应用被迁移到新的 URL 下的时候，保持（原有）链接可用的技术。HTTP 协议提供了一种特殊形式的响应—— HTTP 重定向（HTTP redirects）来执行此类操作。

在 HTTP 协议中，重定向操作由服务器通过发送特殊的响应（即 redirects）而触发。HTTP 协议的重定向响应的状态码为 3xx 。

浏览器在接收到重定向响应的时候，会采用该响应提供的新的URL,并立即进行加载；大多数情况下，除了会有一小部分性能损失之外，重定向操作对于用户来说是不可见的。

重定向可实现许多目标：

站点维护或停机期间的临时重定向。
永久重定向将在更改站点的URL，上传文件时的进度页等之后保留现有的链接/书签。
上传文件时的表示进度的页面。

1.资源重定向的分类

分为永久重定向，临时重定向、特殊重定向

1）永久重定向：

这种重定向操作是永久性的。它表示原 URL 不应再被使用，而应该优先选用新的URL。
搜索引擎机器人会在遇到该状态码时触发更新操作，在其索引库中修改与该资源相关的 URL 。

2）临时重定向：

有时候请求的资源无法从其标准地址访问，但是却可以从另外的地方访问。在这种情况下可以使用临时重定向。
搜索引擎不会记录该新的、临时的链接。在创建、更新或者删除资源的时候，临时重定向也可以用于显示临时性的进度页面。

3）特殊重定向：
304 （Not Modified，资源未被修改）：
协商缓存命中时返回，使页面跳转到本地陈旧的缓存版本当中
300 （Multiple Choice，多项选择）：手工重定向
以 Web 页面形式呈现在浏览器中的消息主体包含了一个可能的重定向链接的列表，用户可以从中进行选择。

2.资源重定向的应用场景

有以下几种应用场景可以使用重定向机制，但是需要注意应该尽可能地限制其使用数量，因为每一次重定向都会带来性能上的开销。

1）域名别称：

理想情况下，一项资源只有一个访问位置，也就是只有一个 URL 。但是由于种种原因，需要为资源设定不同的名称（即不同的域名，例如带有和不带有 www 前缀的URL，以及简短易记的 URL 等）。在这种情况下，实用的方法是将其重定向到那个实际的（标准的）URL，而不是复制资源。

在以下几种情况下可以使用域名别称：

扩大站点的用户覆盖面。

一个常见的场景是，假如站点位于 www.example.com 域名下，那么通过 example.com 也应该可以访问到。
这种情况下，可以建立从 example.com 的页面到www.example.com 的重定向映射。
此外还可以提供常见的同义词，或者该域名容易导致的拼写错误的域名别称。

迁移到另外一个域名。

例如，公司改名后，你希望用户在搜索旧名称的时候，依然可以访问到应用了新名称的站点。

强制使用 HTTPS 协议。

对于 HTTP 版本站点的请求会被重定向至采用了 HTTPS 协议的版本。

2）保持链接有效：

当你重构 Web 站点的时候，资源的 URL 会发生改变。即便是你可以更新站点内部的链接来适应新的命名体系，但无法控制被外部资源使用的URL 。
你并不想因此而使旧链接失效，因为它们会为你带来宝贵的用户（并且帮助优化你的SEO），所以需要建立从旧链接到新链接的重定向映射。

3）对于不安全请求的临时响应

不安全（Unsafe）请求会修改服务器端的状态，应该避免用户无意的重复操作。
通常，你并不想要你的用户重复发送 PUT、POST 或 DELETE请求。假如你仅仅为该类请求返回响应的话，简单地点击刷新按钮就会（可能会有一个确认信息）导致请求的重复发送。
在这种情况下，服务器可以返回一个 303 (See Other)响应，其中含有合适的响应信息。如果刷新按钮被点击的话，只会导致该页面被刷新，而不会重复提交不安全的请求

4）对于耗时请求的临时响应：

一些请求的处理会需要比较长的时间，比如有时候 DELETE 请求会被安排为稍后处理。在这种情况下，会返回一个 303 (See Other) 重定向响应，该响应链接到一个页面，表示请求的操作已经被列入计划，并且最终会通知用户操作的进展情况，或者允许用户将其取消。

2.HTTP常见头

1.Accept：

text/html， application/xhtml+xml； application/xml，q=0.9； image/webp； image/apng；/， q=0.8

作用：向服务器申明客户端（浏览器）可以接受的媒体类型（MIME）的资源

解释：浏览器可以接受text/html、application/xhtml+xml、application/xml类型，通配符*/* 表示任意类型的数据。并且浏览器按照该顺序进行接收。( text/html —> application/xhtml+xml —> application/xml)

2、Accept-encoding：

gzip；deflate； br

作用：向服务器申明客户端（浏览器）接收的编码方法，通常为压缩方法

解释：浏览器支持采用经过gzip，deflate 或 br 压缩过的资源

3、Accept-Language：

en-US；en，q=0.9；zh-CN，q=0.8；zh，q=0.7

作用：向服务器申明客户端（浏览器）接收的语言

解释：浏览器能够接受en-US, en 和 zh-CN 三种语言，其中 en-US 的权重最高 ( q 最高为1，最低为 0)，服务器优先返回 en-US 语言

延伸：语言与字符集的区别：zh-CN 为汉语，汉语中有许多的编码：gbk2312 等

4、Cache-control: max-age=0

作用：控制浏览器的缓存，常见值为private（私人的）、no-cache、max-age、alidate，默认为 private，根据浏览器查看页面不同的方式来进行区别

解释：浏览器在访问了该页面后，不会再访问服务器

cache：电脑高速缓冲存储器

1）cache-control: max-age=xxxx，public

客户端和代理服务器都可以缓存该资源；

客户端在xxx秒的有效期内，如果有请求该资源的需求的话就直接读取缓存，如果用户做了刷新操作，就向服务器发起http请求

2）cache-control: max-age=xxxx，immutable(不变的)

客户端在xxx秒的有效期内，如果有请求该资源的需求的话就直接读取缓存，即使用户做了刷新操作，也不向服务器发起http请求

3）cache-control: max-age=xxxx，private

只让客户端可以缓存该资源；代理服务器不缓存，客户端在xxx秒内直接读取缓存

4）cache-control: no-cache

跳过设置强缓存，但是不妨碍设置协商缓存；一般如果你做了强缓存，只有在强缓存失效了才走协商缓存的，设置了no-cache就不会走强缓存了，每次请求都回询问服务端。

5）cache-control: no-store

不缓存，这个会让客户端、服务器都不缓存，也就没有所谓的强缓存、协商缓存了。

5、Cookie:

作用：告诉服务器关于Session 的信息，存储让服务器辨识用户身份的信息。

6、Refer：https://www.baidu.com/xxxxxxxxxx

作用：告诉服务器该页面从哪个页面链接的

解释：该页面从https://www.baidu.com 中的搜索结果中点击过来的

7、Upgrade-insecure-requests：1

作用：申明浏览器支持从http 请求自动升级为 https 请求，并且在以后发送请求的时候都使用 https

解释：当页面中包含大量的http 资源的时候（图片、iframe），如果服务器发现一旦存在上述的响应头的时候，会在加载 http 资源的时候自动替换为 https 请求

insecure：不安全的

8.User-agent：

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36

作用：向服务器发送浏览器的版本、系统、应用程序的信息。

解释：Chrome 浏览器的版本信息为 63.0.3239.132，并将自己伪装成 Safari，使用的是 WebKit 引擎，WebKit伪装成 KHTML，KHTML伪装成Gecko（伪装是为了接收那些为Mozilla、safari、gecko编写的界面）

延伸：可以随便填（但不应该随便填）不过一般用于统计。

9、X-Chrome-UMA-Enabled、X-Client-Data ：

与 Chrome 浏览器相关的数据Response Headers

3.http缓存问题

1）缓存的类型

缓存是一种保存资源副本并在下次请求中直接使用该副本的技术，缓存能够节约网络资源，提升页面响应速度。

根据是否需要重新向服务器发起请求来分类可分为：强制缓存、协商缓存

强制缓存如果生效，不需要再和服务器发生交互，而协商缓存不管是否生效，都需要与服务端发生交互。

根据是否可以被单个或者多个用户使用来分类可分为：私有缓存、共享缓存

①强制缓存

强制缓存在缓存数据未失效的情况下（即Cache-Control的max-age没有过期），那么就会直接使用浏览器的缓存数据，不会再向服务器发送任何请求。

优点：强制缓存生效时，http状态码为200。这种方式页面的加载速度是最快的，性能也是很好的

缺点：在这期间，如果服务器端的资源修改了，页面上是拿不到的，因为它不会再向服务器发请求了。

② 协商缓存

上面说到的强缓存就是给资源设置个过期时间，客户端每次请求资源时都会看是否过期；只有在过期才会去询问服务器。所以，强缓存就是为了给客户端自给自足用的。

而当某天，客户端请求该资源时发现其过期了，这是就会去请求服务器了，而这时候去请求服务器的这过程就可以设置协商缓存。这时候，协商缓存就是需要客户端和服务器两端进行交互的。

协商缓存步骤总结：

每次请求返回来 response header 中的 etag和 last-modified，在下次请求时在 request header 就把这两个带上，服务端把你带过来的标识进行对比，然后判断资源是否更改了。

如果资源发生更改，返回状态码200和新的资源，以及更新对应的response header的标识etag、last-modified；
如果资源没有变，返回状态码304，浏览器读取本地缓存，etag、last-modified不变。这样就减少了服务器的数据传输压力

③ 私有缓存

HTTP缓存和浏览器缓存

浏览器级缓存：Cache-Control: Private

私有缓存只能用于单独用户，常见的浏览器缓存（session、cookie）便是私有缓存。私有缓存能够存储用户通过http下载过的文档，从而在用户再次访问时直接提供给用户，而不用向服务器发送请求。

④共享缓存

代理级缓存：Cache-Control: Public

共享缓存能够被多个用户使用，常用的web代理中便使用的共享缓存

2）缓存寿命

缓存寿命的计算的依据依次是：

请求头中的Cache-Control: max-age=N。
相应的缓存寿命即为 N，从设置开始，N秒之后过期。

Expires（有效期）属性，Expires属性的值为过期的时间点，在这个时间点后，该缓存被认为过期

Last-Modified（修改）信息。缓存的寿命为头里面 Date表示的事件点减去 Last-Modified的时间点的结果乘以 10%

**判断文件在服务器中是否更改:**可以看文件时间戳

3）cookie

“小型文本文件”，是某些网站为了辨别用户身份，进行Session跟踪而储存在用户本地终端上的数据（通常经过加密），由用户客户端计算机暂时或永久保存的信息。

1.为什么要使用Cookie，解决了什么问题

web程序是使用HTTP协议传输的，而HTTP协议是无状态的协议，对于事务处理没有记忆能力。

缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大；如果服务器不需要先前信息时它的应答就较快。

cookie的出现就是为了解决这个问题。

2.Cookie的用途

会话状态管理（如用户登录状态、购物车、游戏分数或其它需要记录的信息）
个性化设置（如用户自定义设置、主题等）
浏览器行为跟踪（如跟踪分析用户行为等）

3.Cookie的保存方式

1）浏览器会将Cookie保存在内存中
2）保存在客户端的硬盘中，之后每次HTTP请求浏览器都会将Cookie发送给服务器端。

4.Cookie的生存周期

Cookie在生成时就会被指定一个Expire值，这就是Cookie的生存周期，在这个周期内Cookie有效，超出周期Cookie就会被清除。

有些页面将Cookie的生存周期设置为“0”或负值，这样在关闭浏览器时，就马上清除Cookie，不会记录用户信息，更加安全。

5.Cookie的工作原理

（1）浏览器端第一次发送请求到服务器端
（2）服务器端创建Cookie，该Cookie中包含用户的信息，然后将该Cookie发送到浏览器端
（3）浏览器端再次访问服务器端时会携带服务器端创建的Cookie
（4）服务器端通过Cookie中携带的数据区分不同的用户

6.cookie的认证

基于Cookie的认证过程，主要由以下三个阶段组成：

（1）发布Cookie

当用户试图访问某Web站点中需要认证的资源时，Web服务器会检查用户是否提供了认证Cookie，如果没有，则将用户重定向到登录页面。
在用户成功登录后，Web服务器会产生认证Cookie，并通过HTTP响应中的Set-Cookie头发送给客户端，用于对用户随后的请求进行检查和验证，接着将用户重定向到初始请求的资源。

（2）检索Cookie

在用户随后的访问请求中，客户端浏览器检索Path和Domain等属性与用户请求资源相匹配的Cookie，并将找到的Cookie通过HTTP请求中的Cookie头提交给Web服务器。

（3）验证Cookie

Web服务器提取客户端浏览器递交的Cookie，验证其中的访问令牌。若合法，则将访问请求的资源发送给客户端浏览器；反之则拒绝用户的访问请求。

Cookie 认证技术简化了用户访问 Web 网站资源的过程，即用户只需在初次登录网站时输入身份信息进行认证，随后便可以访问被授权的所有站点资源，不再需要重复手工提交身份信息

7.Cookie的安全性问题

（1）Cookie被用户非法篡改

篡改其中的expire项，可将Cookie的有效期延长；
篡改path项可使用户能够访问服务器上不被授权的内容；
修改domain项，使用户能够访问不被授权的服务器从而获得合法用户的信息等;

（2）被非法用户非法截获，然后在有限期内重放，则非法用户将享有合法用户的合法权益，可能会损害网站方的利益;

（3）若Cookie被服务器加密，而非法用户通过强力攻击或其他手段获得了相应的加密密钥，则非法用户可以伪造任何合法Cookie，从而可以访问合法用户的所有个性化信息，甚至是账户信息等

8.cookie安全策略

在服务器端设置cookie的时候设置 http-only, 这样就可以防止用户通过JS获取cookie。

对cookie的读写或发送一般有如下字段进行设置：

http-only:
只允许http或https请求读取cookie、JS代码是无法读取cookie的(document.cookie会显示http-only的cookie项被自动过滤掉)。发送请求时自动发送cookie.
secure-only:
只允许https请求读取，发送请求时自动发送cookie。
host-only:
只允许主机域名与domain设置完成一致的网站才能访问该cookie。

domain：域名

9.Cookie的缺陷

1）数量受到限制。

一个浏览器能创建的Cookie数量最多为 300 个，并且每个不能超过4KB，每个 Web 站点能设置的Cookie 总数不能超过20 个

2）安全性无法得到保障。

通常跨站点脚本攻击往往利用网站漏洞在网站页面中植入脚本代码，或在网站页面引用第三方法脚本代码时存在跨站点脚本攻击的可能。
在受到跨站点脚本攻击时，脚本指令将会读取当前站点的所有Cookie内容（已不存在Cookie作用域限制），然后通过某种方式将 Cookie 内容提交到指定的服务器（如：AJAX）。一旦 Cookie落入攻击者手中，它将会重现其价值。

3）浏览器可以禁用Cookie，禁用Cookie后，也就无法享有Cookie带来的方便。

4）cookie和session的比较

参考：cookie和session的区别

彻底了解Cookie和Session的区别

1.cookie和session都是用来跟踪浏览器用户身份的会话方式。

1.session

Session在计算机中，尤其是在网络应用中，称为“会话控制”。

Session 对象存储特定用户会话所需的属性及配置信息。

在web开发中，服务器可以为每个用户创建一个会话对象(session对象)，默认情况下一个浏览器独占一个session对象，因此在需要保存用户数据时，服务器程序可以把用户数据写到用户浏览器独占的session中，当用户使用浏览器访问其他程序时，其他程序可以从用户的session中取出该用户的数据，为用户服务。

session是基于Cookie技术实现，重启浏览器后再次访问原有的连接依然会创建一个新的session，因为Cookie在关闭浏览器后就会消失，但是原来服务器的Session还在，只有等到了销毁的时间会自动销毁

Session的生命周期根据需求设定。

2.Session的工作原理

其实现原理是服务器创建session出来后，会把session的id号，以cookie的形式回写给客户机，这样只要客户机的浏览器不关，再去访问服务器时，都会带着session的id号去，服务器发现客户机浏览器带session id过来了，就会使用内存中与之对应的session服务。

（1）浏览器端第一次发送请求到服务器端，服务器端创建一个Session，同时会创建一个特殊的Cookie（name为JSESSIONID的固定值，value为session对象的ID），然后将该Cookie发送至浏览器端

（2）浏览器端发送第N（N>1）次请求到服务器端，浏览器端访问服务器端时就会携带该name为JSESSIONID的Cookie对象

（3）服务器端根据name为JSESSIONID的Cookie的value(sessionId)，去查询Session对象，从而区分不同用户。

a. 若name为JSESSIONID的Cookie不存在（关闭或更换浏览器），返回1中重新去创建Session与特殊的Cookie
b. 若name为JSESSIONID的Cookie存在，根据value中的Session Id去寻找session对象：
ba. 若value为Session Id不存在**（Session对象默认存活30分钟）**，返回1中重新去创建Session与特殊的Cookie
bb. 若value为SessionId存在，返回session对象

3.Session和cookie的区别

1）cookie是把用户的数据写给用户浏览器，即cookie数据存放在客户的浏览器上，对客户端是可见的，因此cookie不是很安全，别人可以分析存放在本地的cookie并进行cookie欺骗。

同时由于Cookie是保存在客户端的，不会占用服务器的资源。像baidu、Sina这样的大型网站，一般都是使用Cookie来进行会话跟踪。

session是把用户的数据写到用户独占的session中，即session数据放在服务器上，对客户端是透明的，不存在敏感信息泄露问题。同时由于session会在一定时间内保存在服务器上。当并发访问用户很多时，session会消耗大量内存。

如果主要考虑到减轻服务器性能方面，应当使用cookie；如果主要考虑到安全应当使用session。可以将登陆信息等重要信息存放为session，其他信息如果需要保留，可以放在cookie中

2） session对象由服务器创建，开发人员可以调用request对象的get session方法得到session对象

3）cookie只能存储字符串，如果要存储非ASCII字符串还要对其编码；
Session可以存储任何类型的数据，可以把Session看成是一个容器

4）Cookie保存在硬盘中，只需要设置maxAge属性为比较大的正整数，即使关闭浏览器，Cookie还是存在的。
Session的保存在服务器中，通过设置maxInactiveInterval属性值来确定Session的有效期。如果关闭了浏览器，该Session虽然没有从服务器中消亡，但也就失效了。

5）单个cookie在客户端的限制是4K，就是说一个站点在客户端存放的COOKIE不能超过4K。
session是保存在服务器端，理论上是没有是没有限制，只要你的内存够大

6）如果浏览器禁用了Cookie，那么Cookie是无用的了。
如果浏览器禁用了Cookie，Session可以通过URL地址重写来进行会话跟踪。

4.cookie和session结合使用

1、存储在服务端：

通过cookie存储一个session_id，然后具体的数据则是保存在session中。如果用户已经登录，则服务器会在cookie中保存一个session_id，下次再次请求的时候，会把该session_id携带上来，服务器根据session_id在session库中获取用户的session数据。就能知道该用户到底是谁，以及之前保存的一些状态信息。这种专业术语叫做server side session。

2、将session数据加密，然后存储在cookie中。

这种专业术语叫做client side session。flask采用的就是这种方式，但是也可以替换成其他形式。

注：

简单的说，当你登陆一个网站的时候，如果web服务器端使用的是session，那么所有的数据都保存在服务器上，客户端每次请求服务器的时候会发送当前会话sessionid，服务器根据当前sessionid判断相应的用户数据标志，以确定用户是否登陆或具有某种权限。由于数据是存储在服务器上面，所以你不能伪造。

sessionid是服务器和客户端连接时候随机分配的，如果浏览器使用的是cookie，那么所有数据都保存在浏览器端，比如你登陆以后，服务器设置了cookie用户名，那么当你再次请求服务器的时候，浏览器会将用户名一块发送给服务器，这些变量有一定的特殊标记。服务器会解释为cookie变量，所以只要不关闭浏览器，那么cookie变量一直是有效的，所以能够保证长时间不掉线。

如果你能够截获某个用户的cookie变量，然后伪造一个数据包发送过去，那么服务器还是认为你是合法的。所以，使用cookie被攻击的可能性比较大。

如果cookie设置了有效值，那么cookie会保存到客户端的硬盘上，下次在访问网站的时候，浏览器先检查有没有cookie，如果有的话，读取cookie，然后发送给服务器。

所以你在机器上面保存了某个论坛cookie，有效期是一年，如果有人入侵你的机器，将你的cookie拷走，放在他机器下面，那么他登陆该网站的时候就是用你的身份登陆的。当然，伪造的时候需要注意，直接copy cookie文件到 cookie目录，浏览器是不认的，他有一个index.dat文件，存储了cookie文件的建立时间，以及是否有修改，所以你必须先要有该网站的cookie文件，并且要保证从时间上骗过浏览器

两个都可以用来存私密的东西，session过期与否，取决于服务器的设定。cookie过期与否，可以在cookie生成的时候设置进去。

4.http无状态的原因

无状态是指协议对于事务处理没有记忆能力。

因为http协议目的在于支持超文本的传输，更加广义一点就是支持资源的传输，那么在客户端浏览器向服务器发送请求，继而服务器将相应的资源发回客户这样一个过程中，无论对于客户端还是服务器，都没有必要记录这个过程，因为每一次请求和响应都是相对独立的，一般而言，一个url对应唯一的超文本，正因为这样的唯一性，所以http协议被设计为无状态的链接协议符合它本身的需求。

5.HTTP的连接

1）短连接

浏览器和服务器每进行一次HTTP操作，就建立一次连接，但任务结束就中断连接。如果客户端浏览器访问的某个HTML或其他类型的 Web页中包含有其他的Web资源，如JavaScript文件、图像文件、CSS文件等；当浏览器每遇到这样一个Web资源，就会建立一个HTTP会话。

在HTTP/1.0中，默认使用的是短连接。

2）长连接

在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，如果客户端再次访问这个服务器上的网页，会继续使用这一条已经建立的连接。

Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现长连接要客户端和服务端都支持长连接。

从HTTP/1.1起，默认使用长连接，用以保持连接特性。

使用长连接的HTTP协议，会在响应头有加入这行代码：

 Connection:keep-alive

HTTP如何实现长连接：

通过在头部（请求和响应头）设置Connection:keep-alive。

HTTP1.0协议支持，但是默认关闭。

从HTTP1.1协议以后，连接默认都是长连接。

实际上HTTP没有长短链接，只有TCP有，TCP长连接可以复用一个TCP连接来发起多次HTTP请求，这样可以减少资源消耗，比如一次请求HTML，可能还需要请求后续的其它请求等。

6.HTTP协议版本

1）HTTP/1.0

默认使用短连接，也就是说客户端和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接。当客户端浏览器访问的某个 HTML 或其他类型的 Web 页中包含有其他的 Web 资源，每遇到这样一个 Web 资源，浏览器就会重新建立一个 HTTP 会话。

2）HTTP/1.1

1.长连接：

只要任意一端没有明确地提出断开连接，则保持TCP连接状态。

2.管道网络传输：

管道机制是允许浏览器同时发出A请求和B请求，但服务器还是按顺序先回应A，完成后再去回应B，要是前面的回应特别慢，后面就会有许多请求排着队，这称之为队头阻塞。所以1.1存在队头阻塞问题。

优化问题：

1.通过缓存技术来避免发送HTTP请求：

客户端收到第一个请求的响应后，可以将其缓存在本地磁盘，下次请求的时候如果缓存没有过期，就直接读取本地缓存的响应数据。如果缓存过期，客户端发送请求的时候带上响应数据的摘要，服务器比对后发现资源没有变化，就发出不带包体的304响应（协商缓存命中），告诉客户端缓存的响应仍然有效。

2.减少HTTP请求的次数：

将原本由客户端处理的重定向请求交给代理服务器处理，这样就可以减少重定向请求的次数；

将多个小资源合并成一个大资源再传输，能够减少HTTP请求次数以及头部的重复传输，再来减少TCP连接数量，进而省去TCP握手和慢启动的网络消耗；

按需访问资源，只访问当前用户看得到/用得到的资源，当客户往下滑动时再访问接下来的资源，以此达到延迟请求，也就减少了同一时间的HTTP请求次数。

3.通过压缩响应资源，降低传输资源大小，从而提高传输效率，所以应当选择更好的压缩算法

3）HTTP/2

1.对HTTP头部通过静态表和哈夫曼编码的方式，将体积压缩了近一半，而且针对后续的请求头部，还可以建立动态表，将体积压缩近90%，大大提高了编码效率，同时解决了宽带资源。

2.实现了Stream并发，多个stream只需复用1个TCP连接，节约了TCP和TLS握手时间，以及减少了TCP慢启动阶段对流量的影响，不同的Stream ID才可以并发，即使乱序发送帧也没问题，但是同一个Stream里的帧必须有序。

3.服务器支持主动推送资源，大大提升了消息的传输性能，服务器推送资源时，会发送PUSH_PROMISE帧，告诉客户端接下来在哪个Stream发送资源，然后用偶数号Stream发送资源给客户端。

采用了多路复用，即在一个连接里，客户端和浏览器都可以同时发送多个请求或回应，而且不用按照顺序一一对应。还做了Header压缩、服务端推送等。

优化问题：

HTTP/2通过Stream的并发能力，解决了HTTP/1.1的队头阻塞的问题，但是还会存在“队头阻塞”，只不过是HTTP这一层面而不是TCP这一层面。

HTTP/2是基于TCP协议来传输数据的，TCP是字节流协议，TCP层必须保证收到的字节数据是完整且连续的，这样内核才会将缓冲区里的数据返回给HTTP应用，那么当前1个字节数据没有达到时，后收到的字节数据智能存放在内核缓冲区里，只有等到这个1字节数据达到时，HTTP/2应用层才能从内核中拿到数据，这就是HTTP/2队头阻塞问题，而HTTP/3就是用UDP代替TCP解决这个问题。

HTTP/2虽然具有多个流并发传输的能力，但是传输层是TCP协议，于是存在缺陷：队头阻塞、TCP和TLS握手时延，连接迁移需要重新连接。

4）HTTP/3

QUIC

7.HTTP REST

REST(Representational State Transfer：表述性状态转移)一种轻量级的Web Service架构。可以完全通过HTTP协议实现。其实现和操作比SOAP和XML-RPC更为简洁，还可以利用缓存Cache来提高响应速度，性能、效率和易用性上都优于SOAP协议。

REST架构对资源的操作包括获取、创建、修改和删除资源的操作对应HTTP协议提供的GET、POST、PUT和DELETE方法。

REST提供了一组架构约束，当作为一个整体来应用时，强调组件交互的可伸缩性、接口的通用性、组件的独立部署、以及用来减少交互延迟、增强安全性、封装遗留系统的中间组件。

REST架构约束：

客户-服务器（Client-Server），提供服务的服务器和使用服务的客户需要被隔离对待，客户和服务器之间通过一个统一的接口来互相通讯。

无状态（Stateless），服务端并不会保存有关客户的任何状态，客户端自身负责用户状态的维持，并在每次发送请求时都需要提供足够的信息。

可缓存（Cachable），REST系统需要能够恰当地缓存请求，以尽量减少服务端和客户端之间的信息传输，以提高性能。

分层系统（Layered System），服务器和客户之间的通信必须被这样标准化：允许服务器和客户之间的中间层（Ross：代理，网关等）可以代替服务器对客户的请求进行回应，而且这些对客户来说不需要特别支持。

统一接口（Uniform Interface），客户和服务器之间通信的方法必须是统一化的。

三：https协议

HTTPS（Hyper Text Transfer Protocol over Secure Socket Layer）：安全的超文本传输协议

HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全。Https是身披SSL外壳的Http，运行于SSL上，SSL运行于TCP之上，是添加了加密和认证机制的HTTP。

Http协议运行在TCP之上，明文传输，客户端与服务器端都无法验证对方的身份。

1.https的优点

1.使用HTTPS协议可以认证用户和服务器，确保数据发送到正确的客户机和服务器。
2.HTTPS 协议是由 SSL + HTTP 协议构建的可进行加密传输、身份认证的网络协议，要比 HTTP 协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性；
3.HTTPS 是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。

2.https的缺点

1.HTTPS 协议握手阶段比较费时，会使页面的加载时间延长近50%，增加10%到20%的耗电
2.HTTPS连接缓存不如HTTP高效，会增加数据开销和功耗，甚至已有的安全措施也会因此而受到影响；
3.SSL 证书需要钱，功能越强大的证书费用越高，个人网站、小网站没有必要一般不会用；
4.SSL 证书通常需要绑定 IP，不能在同一 IP 上绑定多个域名，IPv4 资源不可能支撑这个消耗；
5.HTTPS 协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。最关键的，SSL 证书的信用链体系并不安全，特别是在某些国家可以控制 CA 根证书的情况下，中间人攻击一样可行。

3.HTTPS的SSL过程

https通信时，首先建立ssl层的连接，客户端将ssl版本号和加密组件发到服务器端，服务器端收到后对ssl版本号和加密组件进行匹配，同时将CA证书及密钥发送到客户端。

客户端对证书进行验证，验证通过后使用非对称加密对数据通信时的密钥进行协商。协商后得到一致的对称加密密钥。

然后使用对称加密算法进行TCP连接，后续的过程跟http的过程一致。三次握手，数据交换，四次挥手，通信结束。

PKI（Public Key Infrastructure）：公钥基础设施，又称公钥体系，用于发布和传输公开秘钥（即公钥）的系统
（PKI通过数字证书来发布用户的公钥，并提供了验证公钥真实性的机制。数字证书（简称证书）是一个包含用户的公钥及其身份信息的文件，证明了用户与公钥的关联。数字证书由权威机构—CA签发，并由CA保证数字证书的真实性。）

1.客户端和服务器端通过TCP建立连接。

2.客户端提交 https请求。

3.服务器响应客户，并将数字证书发送给客户端，数字证书包括公共秘钥、域名、申请证书的公司。。

4.客户端收到服务器端的数字证书之后，会验证数字证书的合法性，如果数字证书合法，则使用其证书公钥。

5.如果证书公钥有效，则客户端会生成一个会话密钥，并用该证书公钥对其进行非对称加密。

6.客户端发起HTTPS中的第二个HTTP请求，将加密之后的客户端密钥发送给服务器。

7.服务器收到该客户端密钥后，用私钥对其进行非对称解密，获取会话密钥，SSL客户端和SSL服务器利用该会话密钥计算出相同的主密钥，在利用主密钥生成用于对称密钥算法的密钥。

8.客户端和服务器双方利用计算出的密钥加密要传输的数据进行通信。（对称密钥算法）

9.服务器使用密钥对数据进行对称加密，生成密文并发送。
客户端收到密文，并使用密钥进行解密，渲染网页。

4.HTTPS优化问题

对于重建HTTPS时，使用一些技术让客户端和服务器使用上一次HTTPS连接使用的会话密钥，直接回复会话，而不用重构走完整的SSL握手过程（但是会话重用技术不仅不具备前向安全，而且有重放攻击的风险，所以应当对会话密钥设定一个合理的过期时间）

5、SSL协议原理（安全套接层）

安全套接字层(Secure Sockets Layer (SSL)) ，SSL
是一种安全协议，它为网络（例如因特网）的通信提供私密性。SSL 使应用程序在通信时不用担心被窃听和篡改。

SSL 实际上是共同工作的两个协议：

“SSL 记录协议”（SSL Record Protocol），“SSL 握手协议” （SSL HandshakeProtocol）。
"SSL 记录协议"是两个协议中较低级别的协议，它为较高级别的协议，例如 SSL 握手协议对数据的变长的记录进行加密和解密。
SSL 握手协议处理应用程序凭证的交换和验证。

SSL利用数据加密、身份验证和消息完整性验证机制，为网络上数据的传输提供安全性保证。SSL支持各种应用层协议。由于SSL位于应用层和传输层之间，所以可以为任何基于TCP等可靠连接的应用层协议提供安全性保证。

1.身份验证机制

SSL利用数字签名来验证通信对端的身份。非对称密钥算法可以用来实现数字签名。由于通过私钥加密后的数据只能利用对应的公钥进行解密，因此根据解密是否成功，就可以判断发送者的身份，如同发送者对数据进行了“签名”。例如，Alice使用自己的私钥对一段固定的信息加密后发给Bob，Bob利用Alice的公钥解密，如果解密结果与固定信息相同，那么就能够确认信息的发送者为Alice，这个过程就称为数字签名。使用数字签名验证身份时，需要确保被验证者的公钥是真实的，否则，非法用户可能会冒充被验证者与验证者通信。如下图所示，Cindy冒充Bob，将自己的公钥发给Alice，并利用自己的私钥计算出签名发送给Alice，Alice利用“Bob”的公钥（实际上为Cindy的公钥）成功验证该签名，则Alice认为Bob的身份验证成功，而实际上与Alice通信的是冒充Bob的Cindy。SSL利用PKI提供的机制保证公钥的真实性。

2.数据传输的机密性

SSL加密通道上的数据加解密使用对称密钥算法，目前主要支持的算法有DES、3DES、AES等，这些算法都可以有效地防止交互数据被破解。对称密钥算法要求解密密钥和加密密钥完全一致。因此，利用对称密钥算法加密传输数据之前，需要在通信两端部署相同的密钥。

消息完整性验证

为了避免网络中传输的数据被非法篡改，SSL利用基于MD5或SHA的MAC算法来保证消息的完整性。MAC算法是在密钥参与下的数据摘要算法，能将密钥和任意长度的数据转换为固定长度的数据。利用MAC算法验证消息完整性的过程如下图所示。发送者在密钥的参与下，利用MAC算法计算出消息的MAC值，并将其加在消息之后发送给接收者。接收者利用同样的密钥和MAC算法计算出消息的MAC值，并与接收到的MAC值比较。如果二者相同，则报文没有改变；否则，报文在传输过程中被修改，接收者将丢弃该报文。

MAC算法要求通信双方具有相同的密钥，否则MAC值验证将会失败。因此，利用MAC算法验证消息完整性之前，需要在通信两端部署相同的密钥。

4.利用非对称密钥算法保证密钥本身的安全

对称密钥算法和MAC算法要求通信双方具有相同的密钥，否则解密或MAC值验证将失败。因此，要建立加密通道或验证消息完整性，必须先在通信双方部署一致的密钥。SSL利用非对称密钥算法加密密钥的方法实现密钥交换，保证第三方无法获取该密钥。如下图所示，SSL客户端（如Web浏览器）利用SSL服务器（如Web服务器）的公钥加密密钥，将加密后的密钥发送给SSL服务器，只有拥有对应私钥的SSL服务器才能从密文中获取原始的密钥。SSL通常采用RSA算法加密传输密钥。（Server端公钥加密密钥，私钥解密密钥）

实际上，SSL客户端发送给SSL服务器的密钥不能直接用来加密数据或计算MAC值，该密钥是用来计算对称密钥和MAC密钥的信息，称为premaster secret。SSL客户端和SSL服务器利用premaster secret计算出相同的主密钥（master secret），再利用master secret生成用于对称密钥算法、MAC算法等的密钥。premaster secret是计算对称密钥、MAC算法密钥的关键。

5.利用PKI保证公钥的真实性

PKI（Public Key Infrastructure）：公钥基础设施，又称公钥体系，用于发布和传输公开秘钥（即公钥）的系统

PKI通过数字证书来发布用户的公钥，并提供了验证公钥真实性的机制。数字证书（简称证书）是一个包含用户的公钥及其身份信息的文件，证明了用户与公钥的关联。数字证书由权威机构——CA签发，并由CA保证数字证书的真实性。

SSL客户端把密钥加密传递给SSL服务器之前，SSL服务器需要将从CA获取的证书发送给SSL客户端，SSL客户端通过PKI判断该证书的真实性。如果该证书确实属于SSL服务器，则利用该证书中的公钥加密密钥，发送给SSL服务器。

验证SSL服务器/SSL客户端的身份之前，SSL服务器/SSL客户端需要将从CA获取的证书发送给对端，对端通过PKI判断该证书的真实性。如果该证书确实属于SSL服务器/SSL客户端，则对端利用该证书中的公钥验证SSL服务器/SSL客户端的身份。

6、SSL和SSH的区别

SSL和SSH有什么区别

SSL和SSH的区别

网络安全协议比较(PKI SSH SSL SET)

简单的说：SSL是安全传输的一种安全协议，SSH只是在传输的时候为了防止"中间人"篡改数据而提供的安全的"通道"

在使用的时候我们只关心传输数据的安全性,那么在对于传输层和应用层,在数据请求返回的时候就存在安全性的问题:

"中间人"篡改数据，并且可以伪装为服务器提供给客户端数据

由此就有了SSL和SSH

SSL：

Web安全的基础
SSL是一种在线安全协议，提供数据加密，从而确保访问者的连接是安全的。

SSL的主要功能是：

1）数据加密

它的核心功能是维护服务器与客户端之间的通信。因此，它加密信息或数据的每一位，这些信息或数据只能由预期的接收者解锁。如果您的网站保存了敏感数据，例如ID，密码，付款信息等，则此SSL功能非常有用。

2）认证方式

SSL证书通过要求您进行身份验证过程来向您的网站提供身份验证。除非您完成彻底的验证过程，否则证书颁发机构将不会颁发SSL。因此，人们会信任您的网站。

SSH：

SSH协议（安全外壳）是一种确保从一台计算机到另一台计算机的远程通信安全的方法。它提供强大的身份验证，同时通过加密确保通信和完整性。
它的本质是在http/ftp等应用层提供一个安全的"通道"，避免了"中间人"的攻击,SSH是由客户端和服务端软件构成的.
此安全协议通常用于访问类Unix的操作系统。但是，您也可以在Microsoft Windows上使用它。

SSH的主要功能是：

1）加密（SSH提供三种加密类型来保护通信安全）

对称加密：
以这种加密形式，客户端和主机都在对消息进行加密和解密时使用秘密密钥。
非对称加密：
在非对称加密中，使用两个单独的密钥进行加密和解密，称为公钥和私钥。这些密钥形成一个公共-私有密钥对。
散列：
SSH还使用单向散列，这种形式的加密无法解密。每个输入都会生成一个固定长度的唯一值，该值没有明显的趋势，因此几乎不可能反转。

2）认证方式

SSH的另一个功能是提供身份验证。这些协议由三个不同的协议（即传输层，身份验证层和连接层）组成，它们对连接中的另一方进行身份验证。它会加密数据并在检查数据完整性时提供机密性。

SSH与SSL主要区别如下：

SSH实现端口22，而SSL实现端口443。
SSH可以帮助您安全地在Internet上执行命令，而SSL可以安全地传输关键信息。
SSH在建立安全连接时需要密码验证系统。SSL不需要它。
SSH主要处理网络隧道，而SSL处理证书。

对于各种网站来说，可以使用SSL保护客户端和服务器之间的Internet连接。它非常适合在进行在线业务交易时为客户提供安全性。

四：Websocket协议

WebSocket（3）-- WebSocket协议简介

WebSocket（4）-- WebSocket与TCP、Http的关系

WebSocket是一种双向通信协议，它与http协议一样都是基于TCP的，所以他们都是可靠的协议，都是通过TCP来传输数据。

WebSocket在建立握手连接时，数据是通过http协议传输的，但是在建立连接之后，真正的数据传输阶段是不需要http协议参与的。
他最大的特点就是服务端可以主动向客户端推送消息，客户端也可以主动向服务端发送消息，实现了真正的平等
当服务器完成协议升级后（HTTP->Websocket），服务端就可以主动推送信息给客户端啦。
状态码101：切换请求协议，从HTTP切换到WebSocket

1、为什么用websocket协议

WebSocket介绍和Socket的区别

HTTP协议是非持久化的，单向的网络协议，在建立连接后只允许浏览器向服务器发出请求后，服务器才能返回相应的数据。

当需要即时通讯时，通过轮询在特定的时间间隔（如1秒），由浏览器向服务器发送Request请求，然后将最新的数据返回给浏览器。

这样的方法最明显的缺点就是需要不断的发送请求，而且通常HTTP request的Header是非常长的，为了传输一个很小的数据需要付出巨大的代价，是很不合算的，占用了很多的宽带。

缺点：

会导致过多不必要的请求，浪费流量和服务器资源，每一次请求、应答，都浪费了一定流量在相同的头部信息上

然而WebSocket的出现可以弥补这一缺点。在WebSocket中，只需要服务器和浏览器通过HTTP协议进行一个握手的动作，然后单独建立一条TCP的通信通道进行数据的传送。

2、WebSocket握手的过程

当Web应用程序调用new WebSocket(url)接口时，Browser就开始了与地址为url的WebServer建立握手连接的过程。

Browser与WebSocket服务器通过TCP三次握手建立连接，如果这个建立连接失败，那么后面的过程就不会执行，Web应用程序将收到错误消息通知。
在TCP建立连接成功后，Browser/UA通过 http 协议传 WebSocket支持的版本号、协议的字版本号、原始地址、主机地址等等一些列字段给服务器端
WebSocket 服务器收到 Browser/UA 发送来的握手请求后，如果数据包数据和格式正确，客户端和服务器端的协议版本号匹配等等，就接受本次握手连接，并给出相应的数据回复，同样回复的数据包也是采用 http 协议传输。
Browser收到服务器回复的数据包后，如果数据包内容、格式都没有问题的话，就表示本次连接成功，触发onopen消息，此时Web开发者就可以在此时通过send接口想服务器发送数据。
否则，握手连接失败，Web应用程序会收到onerror消息，并且能知道连接失败的原因。

3、websocket协议的特点

1）推送功能

支持服务器端向客户端推送功能。服务器可以直接发送数据而不用等待客户端的请求。

2）减少通信量

只要建立起websocket连接，就一直保持连接，在此期间可以源源不断的传送消息，直到关闭请求。也就避免了HTTP的非状态性。
和http相比，不但每次连接时的总开销减少了，而且websocket的首部信息量也小，通信量也减少了。

3）减少资源消耗

其实我们所用的程序是要经过两层代理的，即HTTP协议在Nginx等服务器的解析下，然后再传送给相应的Handler（PHP等）来处理。

简单地说，我们有一个非常快速的接线员（Nginx），他负责把问题转交给相应的客服（Handler）。本身接线员基本上速度是足够的，但是每次都卡在客服（Handler）了，老有客服处理速度太慢。导致客服不够。

Websocket就解决了这样一个难题，建立后，可以直接跟接线员建立持久连接，有信息的时候客服想办法通知接线员，然后接线员在统一转交给客户。这样就可以解决客服处理速度过慢的问题了。

4、websocket和http的不同

WebSocket是一种双向通信协议，在建立连接后，WebSocket服务器和Browser/UA都能主动的向对方发送或接收数据，
WebSocket是一种建立在Web基础上的一种简单模拟Socket的协议；
WebSocket需要通过握手连接，类似于TCP它也需要客户端和服务器端进行握手连接，连接成功后才能相互通信。

五、网络攻击

常见网络攻击类型

xxs：（Cross Site Scripting）跨站脚本攻击

XSS攻击

服务器对客户端的输入检测不严格，导致客户端输入的恶意JAVASCRIPT代码被植入到HTML代码中，这些JAVASCRIPT代码得以执行，实现一些特殊的目的。

人们经常将跨站脚本攻击（Cross Site Scripting）缩写为CSS，但这会与层叠样式表（Cascading Style Sheets，CSS）的缩写混淆。因此，有人将跨站脚本攻击缩写为XSS。

XSS攻击通常指的是通过利用网页开发时留下的漏洞，通过巧妙的方法在web页面中会插入一些恶意的script代码，当用户浏览该页面的时候，那么嵌入到web页面中script代码会执行，因此会达到恶意攻击用户的目的。如盗取用户Cookie、破坏页面结构、重定向到其它网站等。
这些恶意网页程序通常是JavaScript，但实际上也可以包括Java、 VBScript、ActiveX、 Flash或者甚至是普通的HTML。
攻击成功后，攻击者可能得到包括但不限于更高的权限（如执行一些操作）、私密网页内容、会话和cookie等各种内容。

1、xxs攻击的分类

web安全之XSS攻击原理及防范

从攻击代码的工作方式可以分为三个类型：

反射型、存储型及 DOM-based型。
反射型和DOM-based型属于非持久型跨站
存储型可以归类为持久性XSS攻击

1）反射型跨站脚本漏洞，最普遍的类型。用户访问服务器-跨站链接-返回跨站代码。

常见的反射型xxs：恶意链接。
反射性xss一般指攻击者通过特定的方式来诱惑受害者去访问一个包含恶意代码的URL。当受害者点击恶意链接url的时候，恶意代码会直接在受害者的主机上的浏览器执行。
反射型XSS指的是这种攻击方式的注入代码是从目标服务器通过错误信息，搜索结果等方式反射回来的，
非持久性XSS指的是这种攻击方式只有一次性。
比如：攻击者通过电子邮件等方式将包含注入脚本的恶意链接发送给受害者，当受害者点击该链接的时候，注入脚本被传输到目标服务器上，然后服务器将注入脚本 "反射"到受害者的浏览器上，从而浏览器就执行了该脚本。

反射型XSS的攻击步骤如下：

攻击者在url后面的参数中加入恶意攻击代码。
当用户打开带有恶意代码的URL的时候，网站服务端将恶意代码从URL中取出，拼接在html中并且返回给浏览器端。
用户浏览器接收到响应后执行解析，其中的恶意代码也会被执行到。
攻击者通过恶意代码来窃取到用户数据并发送到攻击者的网站。攻击者会获取到比如cookie等信息，然后使用该信息来冒充合法用户的行为，调用目标网站接口执行攻击等操作。

2）DOM跨站（DOM XSS）：

DOM（document object model文档对象模型），客户端脚本处理逻辑导致的安全问题。
基于DOM的XSS漏洞是指受害者端的网页脚本在修改本地页面DOM环境时未进行合理的处置，而使得攻击脚本被执行。在整个攻击过程中，服务器响应的页面并没有发生变化，引起客户端脚本执行结果差异的原因是对本地DOM的恶意篡改利用。

3）存储型XXS：

最直接的危害类型，跨站代码存储在服务器（数据库）。
存储型XSS的原理是：主要是将恶意代码上传或存储到服务器中，下次只要受害者浏览包含此恶意代码的页面就会执行恶意代码。

存储型XSS的攻击步骤如下：

攻击者将恶意代码提交到目标网站数据库中。
用户打开目标网站时，网站服务器将恶意代码从数据库中取出，然后拼接到html中返回给浏览器中。
用户浏览器接收到响应后解析执行，那么其中的恶意代码也会被执行。
那么恶意代码执行后，就能获取到用户数据，比如上面的cookie等信息，那么把该cookie发送到攻击者网站中，那么攻击者拿到该
cookie然后会冒充该用户的行为，调用目标网站接口等违法操作。

如何防范存储型XXS：

后端需要对提交的数据进行过滤。
前端也可以做一下处理方式，比如对script标签，将特殊字符替换成HTML编码这些等。

2、SQL注入

SQL注入是通过客户端的输入把SQL命令注入到一个应用的数据库中，从而执行恶意的SQL语句。

SQL注入，就是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令

sql被攻击的原因是：
sql语句伪造参数，然后对参数进行拼接后形成xss攻击的sql语句。最后会导致数据库被攻击了。

比如：

有一个登录框需要输入用户名和密码
我们在查询用户名和密码是否正确的时候，本来执行的sql语句是：select * from user where username = ’ ’ and password = ’ '. 这样的sql语句
现在我们输入密码是 'or ‘123’ = '123 这样的。
然后我们会通过参数进行拼接，拼接后的sql语句就是： select * from user where username = ‘’ and password = ’ ’ or ‘123’ = '123 '；这样的了，
则会有一个or语句，只要这两个有一个是正确的话，就条件成立，因此 123 = 123 是成立的。因此验证就会被跳过。

根据相关技术原理，SQL注入可以分为平台层注入和代码层注入：

平台层注入由不安全的数据库配置或数据库平台的漏洞所致；
代码层注入主要是由于程序员对输入未进行细致地过滤，从而执行了非法的数据查询。

基于此，SQL注入的产生原因通常表现在以下几方面：

不当的类型处理；
不安全的数据库配置；
不合理的查询集处理；
不当的错误处理；
转义字符处理不合适；
多个提交处理不当。

防SQL注入的方法：

可以使用预编译语句(PreparedStatement），这样的话即使使用sql语句伪造成参数，到了服务端的时候，这个伪造sql语句的参数也只是简单的字符，并不能起到攻击的作用。
不要把机密信息直接存放，加密或者hash掉密码和敏感的信息。比如可以对密码使用md5进行加密，为了加大破解成本，可以采用加盐的方式。
对用户的输入进行校验，可以通过正则表达式，或限制长度；对单引号和双"-"进行转换等。
不要使用动态拼装sql，可以使用参数化的sql或者直接使用存储过程进行数据查询存取。
不要使用管理员权限的数据库连接，为每个应用使用单独的权限有限的数据库连接。
应用的异常信息应该给出尽可能少的提示，最好使用自定义的错误信息对原始错误信息进行包装

sql注入的检测方法一般采取辅助软件或网站平台来检测，
软件一般采用sql注入检测工具jsky，
网站平台就有亿思网站安全平台检测工具。MDCSOFT SCAN等。采用MDCSOFT-IPS可以有效的防御SQL注入，XSS攻击等。

3、钓鱼攻击

通过大量发送声称来自于银行或其他知名机构的欺骗性垃圾邮件，意图引诱收信人给出敏感信息（如用户名、口令、帐号 ID 、ATM PIN 码或信用卡详细信息）的一种攻击方式。

最典型的网络钓鱼攻击将收信人引诱到一个通过精心设计与目标组织的网站非常相似的钓鱼网站上，并获取收信人在此网站上输入的个人敏感信息，通常这个攻击过程不会让受害者警觉。

它是“ 社会工程攻击 ”的一种形式。

4、跨域

跨域：指的是浏览器不能执行其他网站的脚本。。它是由浏览器的同源策略造成的，是浏览器对javascript施加的安全限制。
跨域限制访问，其实是浏览器的限制。
同源策略：是指协议，域名，端口都要相同，其中有一个不同都会产生跨域；
浏览器从一个域名的网页去请求另一个域名的资源时，域名、端口、协议任一不同，都是跨域。

跨域的解决方案：

什么是跨域？跨域解决方法

六：常见问题

1.在浏览器中输入一个网址它的运行过程是怎样的

http的请求和响应过程1

http的请求和响应过程2

http的请求和响应过程3

1、DNS解析：查询DNS，获取域名对应的IP。

（1）检查浏览器缓存、检查本地hosts文件（操作系统缓存）中是否有这个网址的映射，如果有，就调用这个IP地址映射，解析完成。同时域名被缓存的时间也可通过TTL属性来设置。

（2）如果没有，则查找本地DNS解析器缓存是否有这个网址的映射，如果有，返回映射，解析完成。

（3）如果没有，则查找填写或分配的首选DNS服务器，称为本地DNS服务器（LDNS）。

服务器接收到查询时：如果要查询的域名包含在本地配置区域资源中，返回解析结果，查询结束，此解析具有权威性。

如果要查询的域名不由本地DNS服务器区域解析，但服务器缓存了此网址的映射关系，返回解析结果，查询结束，此解析不具有权威性。

（4）如果本地DNS服务器也失效：

如果采用迭代模式，本地DNS就把请求发至13台根DNS，根DNS服务器收到请求后，会判断这个域名（如.com）是谁来授权管理，并返回一个负责该顶级域名服务器的IP，本地DNS服务器收到顶级域名服务器IP信息后，继续向该顶级域名服务器IP发送请求，该服务器如果无法解析，则会找到负责这个域名的下一级DNS服务器（如http://baidu.com）的IP给本地DNS服务器，循环往复直至查询到映射，将解析结果返回本地DNS服务器，再由本地DNS服务器返回解析结果，查询完成。

如果采用递归模式，则此DNS服务器就会把请求转发至上一级DNS服务器，如果上一级DNS服务器不能解析，则继续向上请求。最终将解析结果依次返回本地DNS服务器，本地DNS服务器再返回给客户机，查询完成。

2、得到目标服务器的IP地址及端口号（http：80端口，https：443端口），会调用系统库函数socket，请求一个TCP流套接字。

客户端向服务器发送HTTP请求报文：

（1）应用层：客户端发送HTTP请求报文。

（2）传输层：（加入源端口、目的端口）建立连接。实际发送数据之前，三次握手客户端和服务器建立起一个TCP连接。

（3）网络层：（加入IP头）路由寻址。

（4）数据链路层：（加入frame头）传输数据。

（5）物理层：物理传输bit。

3、服务器端经过物理层→数据链路层→网络层→传输层→应用层，解析请求报文，发送HTTP响应报文。

4、关闭连接，TCP四次挥手。

5、客户端解析HTTP响应报文，浏览器开始显示HTML

2.从打开浏览器输入URL地址到到达服务器上项目中某一个Controller上（/显示主页）的过程是怎样的

这个过程中发生了网络通信，即利用 tcp/ip 协议簇进行网络通信，发送端由应用层往下走，接收端由数据链路层往上走，步骤如下：

１、URL解析：对URL进行解析，从而发送给Web服务器的请求信息。

２、DNS解析：浏览器查询DNS，获取域名对应的IP地址。

３、TCP连接：浏览器获得域名对应的IP地址以后，浏览器向服务器请求建立，发起三次握手。

4、发送HTTP请求：TCP连接建立起来后，浏览器向服务器发送HTTP请求。

HTTP请求过程为：网络层ip查询mac地址，传输层tcp传输报文，数据到达数据链路层，此时客户端发送请求结束

5.服务器处理请求并返回HTTP响应报文：服务器时接收到这个请求后，并根据路径参数映射到特定的请求处理器进行处理，并将处理结果及相应的数据返回给浏览器。

服务器回应报文的返回过程为：服务器在数据链路层收到数据包，再层层下上直到应用层

6、浏览器解析渲染页面：浏览器解析并渲染，若遇到静态资源的引用，则重复上述步骤并向服务器请求这些资源；浏览器根据其请求到的资源、数据渲染页面，最终向用户呈现一个完整的页面。

7、四次挥手，断开连接。

3.soket编程和http协议

由于通常情况下Socket连接就是TCP连接，因此Socket连接一旦建立，通信双方即可开始相互发送数据内容，直到双方连接断开。但在实际网络应用中，客户端到服务器之间的通信往往需要穿越多个中间节点，例如路由器、网关、防火墙等，大部分防火墙默认会关闭长时间处于非活跃状态的连接而导致 Socket 连接断连，因此需要通过轮询告诉网络，该连接处于活跃状态。

而HTTP连接使用的是“请求—响应”的方式，不仅在请求时需要先建立连接，而且需要客户端向服务器发出请求后，服务器端才能回复数据。很多情况下，需要服务器端主动向客户端推送数据，保持客户端与服务器数据的实时与同步。

此时若双方建立的是Socket连接，服务器就可以直接将数据传送给客户端；若双方建立的是HTTP连接，则服务器需要等到客户端发送一次请求后才能将数据传回给客户端，因此，客户端定时向服务器端发送连接请求，不仅可以保持在线，同时也是在“询问”服务器是否有新的数据，如果有就将数据传给客户端。

5.如何评价按照关键词搜索的算法的好坏

比如淘宝的搜索算法，输入关键词，会给出搜索出来的商品结果

淘宝的搜索算法：

1、目标性比较强，当然，这个相对而言，从query来看，用户对目标商品的认知度相对较强

2、短query/符合query较多，传统搜索引擎里的xxx的商品这种query较少，当然，这与淘宝搜索的处理能力也有关系，用户对query进行分词的情况很常见

3、属性类query较为常见，如雪纺、鱼嘴等等表明用户特征的query较为常见

4、用户对结果的判断，基本上是价格敏感+信用敏感+销量敏感，其中销量敏感和信用敏感其实是一回事，因此这样的算法，比较符合淘宝搜索要求的，能够更加精准，

6.商品的种类有几十万种，在这种大数据的情况下如何评价搜索算法的好坏

在大数据时代，搜索算法最重要有三点，足够快，能够将用户所潜在需要的商品全部搜索出来，性能稳定。

7.搜索敏感词汇时，页面被重置的原理

根据TCP协议的规定，用户和服务器建立连接需要三次握手：第一次握手用户向服务器发送SYN数据包发出请求（SYN, x:0），第二次握手服务器向用户发送SYN/ACK数据包发出回应（SYN/ACK, y:x+1），第三次握手用户向服务器发送ACK数据包发出确认（ACK, x+1:y+1），至此一个TCP连接建立成功。其中x为用户向服务器发送的序列号，y为服务器向用户发送的序列号。

关键字检测，针对明文或者base64等弱加密通讯内容，与准备好的敏感词库进行匹配，当发现敏感词时，将服务器发回的SYN/ACK包改成SYN/ACK, Y:0，这代表TCP连接被重置，用户便主动放弃了连接，提示连接失败。让用户误认为服务器拒绝连接，而主动放弃继续与服务器连接，自动阻断记录含有敏感词的网页。

计算机网络整理：HTTP协议、HTTPS协议、Websocket协议相关推荐

AJAX--URL--http、https、websocket协议、跨域
AJAX AJAX -- URL -- http.https.websocket协议 -- 跨域一. 客户端与服务器二. url地址 2.1 概念:URL(全称是UniformResourceLo ...
html实现websocket协议,HTML5实现WebSocket协议原理浅析
WebSocket协议的目的是为了工作于现有的网络基础设施.作为这一设计原则的一部分,WebSocket连接的协议规范定义了一个HTTP连接作为其开始生命周期,进而保证其与pre-WebSocket世 ...
计算机网络整理：UDP协议和TCP协议
系列文章目录 HTTP协议和HTTPS协议文章目录系列文章目录一.TCP/IP 各层协议二.UDP协议和TCP协议 1.TCP和UDP的区别 2.UDP 协议 3.TCP 协议 1)特点 2) ...
http协议与https协议+UDP协议和TCP协议+WebSocket协议下服务端主动去发送信息+对称加密与非对称加密+get和post请求方式区别详解+浏览器内核以及jsj解析引擎
TCP和UDP协议是TCP/IP协议的核心. 在TCP/IP网络体系结构中,TCP(传输控制协议,Transport Control Protocol).UDP(用户数据报协议,User Data P ...
WebSocket 协议
1.1 背景知识由于历史原因,在创建一个具有双向通信机制的 web 应用程序时,需要利用到 HTTP 轮询的方式.围绕轮询产生了 "短轮询" 和 "长轮询". ...
WebSocket协议分析
点击上方↑↑↑蓝字[协议分析与还原]关注我们 " 解析websocket数据格式." 好久不见,一晃一年又过去了,祝大家新年好运. 今天,给大家分析一个常见的协议--WebSock ...
用node实现websocket协议
协议 WebSocket是一种基于TCP之上的客户端与服务器全双工通讯的协议,它在HTML5中被定义,也是新一代webapp的基础规范之一. 它突破了早先的AJAX的限制,关键在于实时性,服务器可以主 ...
Websocket协议的学习、调研和实现
1. websocket是什么 Websocket是html5提出的一个协议规范,参考rfc6455. websocket约定了一个通信的规范,通过一个握手的机制,客户端(浏览器)和服务器(webse ...
WebSocket协议探究（序章）
一 WebSocket协议基于HTTP和TCP协议与往常一样,进入WebSocket协议学习之前,先进行WebSocket协议抓包,来一个第一印象. WebSocket能实现客户端和服务器间双向.基 ...
dotnet core 开发无缝兼容Http和Websocket协议的接口服务
在应用接口开发中往往要针对不同协义开发相应的代理服务,但对于Websocket和http这两种协议来说就有些不同,从实现上来看Websocket可以说是Http的升级子协议, 两者在协议处理上基本一致 ...

计算机网络整理：HTTP协议、HTTPS协议、Websocket协议