系列文章目录

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）请求报文

同请求报文

状态码

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,并立即进行加载；大多数情况下，除了会有一小部分性能损失之外，重定向操作对于用户来说是不可见的。

2）临时重定向：

• 有时候请求的资源无法从其标准地址访问，但是却可以从另外的地方访问。在这种情况下可以使用临时重定向。

• 搜索引擎不会记录该新的、临时的链接。在创建、更新或者删除资源的时候，临时重定向也可以用于显示临时性的进度页面。
  

  

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

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

1）域名别称：

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

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

1. 扩大站点的用户覆盖面。

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

2. 迁移到另外一个域名。

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

3. 强制使用 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不变。这样就减少了服务器的数据传输压力
  

  

  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协议，会在响应头有加入这行代码：

  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 资源不可能支撑这个消耗；

    来源：yπ_π

    声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！