HTTP详解

了解HTTP协议

• HTTP协议是Hyper Text Transfer Protocol（超文本传输协议）的缩写,是用于从万维网（WWW:World Wide Web ）服务器传输超文本到本地浏览器的传送协议，所有的WWW文件都必须遵守这个标准
• HTTP是一个基于TCP/IP通信协议来传递数据（HTML 文件, 图片文件, 查询结果等）
• HTTP是一个属于应用层的面向对象的协议，由于其简捷、快速的方式，适用于分布式超媒体信息系统。由请求和响应构成，是一个标准的客户端服务器模型。HTTP是一个无状态的协议
• HTTP协议工作于客户端-服务端架构为上。浏览器作为HTTP客户端通过URL向HTTP服务端即WEB服务器发送所有请求。Web服务器根据接收到的请求后，向客户端发送响应信息
• 浏览器背后的故事：
  当你输入一个网站的网址（也就是域名）时，浏览器会根据域名在DNS服务器进行解析，获取对应的IP地址，接下来浏览器会向对应IP地址的web服务器发送请求，web服务器接受到请求后会返回对应的响应内容。
  

透过TCP/IP看HTTP

HTTP协议是构建在TCP/IP协议之上的，是TCP/IP协议的一个子集

TCP/IP协议族

TCP/IP协议其实是一系列与互联网相关联的协议集合起来的总称
分层管理是TCP/IP协议的重要特征，是由一个四层协议组成的系统，这四层分别是：应用层，传输层，网络层和数据链路层。

应用层：应用层一般是我们编写的应用程序，决定了向用户提供的应用个服务，应用层可以通过系统调用与传输层进行通信。如：FTP,DNS,HTTP等。
传输层：传输层通过系统调用向应用层提供处于网络连接中的俩台计算机之间的数据传输功能，在传输层有俩个性质不同的协议：TCP和UDP。
网络层：网络层用来处理在网络上流动的数据包，数据包是网络传输的最小数据单位，该层规定了通过怎样的路径（传输路线）到达对方计算机，并把数据包传输给对方。
数据链路层：数据链路层用来处理连接网络的硬件部分，包括控制操作系统、硬件设备驱动、NIC(Network Interface Card,网络适配器）以及光纤等物理可见部分。硬件上的范畴均在链路层的作用范围之内。

数据包的封装过程

HTTP数据传输过程

1. 发送端发送数据时，数据会从上层传输到下层，且每经过一层都会被打上该层的头部信息。而接收端接收数据时，数据会从下层传输到上层，传输前会把下层的头部信息删除
2. 

传输层——TCP三次握手

使用TCP协议进行通信的双方必须先建立连接，然后才能开始传输数据，为了确保连接双方可靠性，在双方建立连接时,TCP协议采用了三次握手策略。

• 第一次握手;客户端发送带有SYN标志的连接请求报文段，然后进入SYN_SEND状态，等待服务端的确认。（确保客户端发送能力正常）
• 第二次握手：服务端接收到客户端的SYN报文段后，需要发送ACK信息对这个SYN报文段进行确认。同时，还要发送自己的SYN请求，服务端会将上述的信息放到一个报文段（SYN+ACK报文段）中，一并发送给客户端，此时服务端将会进入SYN_RECV状态。（确保服务端接收和发送能力正常）
• 第三次握手：客户端接收到服务端的SYN+ACK报文段后，会想服务端发送ACK确认报文段，这个报文段发送完毕后，客户端和服务端都进入ESTABLISHED状态，完成TCP三次握手。（确保客户端接收能力正常）
• 总结就是TCP三次握手的目的在于保证客户端和服务端都具有正常和发送和接收能力，想要建立一个连接，至少要经历三次握手

DNS域名解析

通常我们访问一个网站，使用的是主机名或者域名来进行访问的。因为相对于IP地址（一堆纯数字），域名更容易让人记住。但TCP/IP协议使用的是IP地址进行访问的，所以必须有个机制或服务把域名转换成IP地址，DNS服务就是用来解决这个问题的，它提供域名到IP地址之间的域名解析服务。

本地电脑会将我们经常使用的域名和对应的IP地址来进行一个映射关系保存到系统文件中，正常情况下是优先从系统文件来根据域名来找出对应的IP地址，如果系统文件没有找到的话，才会使用本地DNS服务器来进行域名解析服务找到对应的IP地址。如果本地的DNS服务没有找到才会一层一层的向上一级的DNS服务器来发送请求找域名对应的IP，找到后会回传给浏览器。

回溯HTTP事务处理过程

当客户端访问Web站点时，首先会通过DNS服务查询到域名的IP地址，然后浏览器生成HTTP请求，并通过TCP/IP协议发送给Web服务器。Web服务器接收到请求后会根据请求生成响应内容，并通过TCP/IP协议返回给客户端。

另一种分析流程图完整的工作方式

熟悉HTTP协议结构和通讯原理

HTTP协议特点

1. 支持客户/服务器模式
   客户/服务器模式工作的方式是由客户端向服务器发出请求，服务器端响应请求，并进行相应服务
   
2. 简单快速
   客户向服务器请求服务时，只需传送请求方法和路径
   请求方法常用的类型有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同
   由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快
3. 灵活
   HTTP允许传输任意类型的数据对象
   正在传输的类型有Content-Type（Content-Type是HTTP包中用来表示内容类型的标识）加以标记
4. 无连接
   无连接的含义是限制每次连接只处理一个请求
   服务器处理完客户的请求，并收到客户的应答后，即断开连接
   采用这种方式可以节省传输时间
5. 无状态
   HTTP协议是无状态协议
   无状态是指协议对于事物处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大
   另一方面，在服务器不需要先前信息时它的应答就较快

URL与URI

Question : 我们输入在浏览器里的Web地址应该叫URL还是URI？

• URI：一个紧凑的字符串用来标示抽象或物理资源
• A URI 可以进一步被分为定位符、名字或俩者都是
• 术语“Uniform Resource Locator ”(URL)是URI的子集，除了确定一个资源。还提供一种定位该资源的主要访问机制（如其网络“位置”）
• URI可以分为URL、URN或同时具备locators和names特性的一个东西
• URN作用就好像一个人的名字，URL就像一个人的地址，换句话说：URN确定了东西的身份，URL提供了找到它的方式
• URL是URI的一种，不是所有的URI都是URL
• URI和URL最大的差别是“访问机制”
• URN是唯一标识的一部分，是身份信息

当我们讨论 URI 时，一个例子是 “mailto:example@example.com”。这是一个 URI，它使用了 “mailto” scheme，表示此 URI 是一个用于发送电子邮件的地址。“example@example.com” 是资源的具体标识。
当我们讨论 URL 时，一个例子是 “https://www.example.com/index.html”。这是一个 URL，它包含了以下部分：
-Scheme: “https”，表示使用 HTTPS 协议进行访问。
Authority: “www.example.com”，指示了资源所在的主机名。
Path: “/index.html”，表示资源在服务器上的路径。
这个 URL 可以被浏览器解析，根据指定的协议和主机名，请求服务器上的 “/index.html” 页面。

HTTP报文头

HTTP/1.1里一共规范了47种报文头字段，大体可以分为四类，分别是：通用报文头，请求报文头，响应报文头和实体报文头。

通用报文头：
通用首部字段（General Header Fields）请求报文和响应报文两方都会使用的首部。

Cache-Control：用来声明服务器端缓存控制的指令。包括请求设置指令和响应请求指令。

请求控制指令如下。

• no-cache：不使用缓存实体，要求从 Web 服务器去请求内容。
• max-age：只接受 Age 值小于 max-age 值的内容，即没有过期的请求对象。
• max-stale：可以接受过去的对象，但是过期时间必须小于 max-stale 值。
• min-fresh：接受生命期大于其当前 Age 跟 min-fresh 值之和的缓存对象。

响应控制指令如下。

• public：可以用 Cache 中内容回应任何用户。
• private：只能用缓存内容回应先前请求该内容的具体用户。
• no-cache：可以设置哪些内容不被缓存。
• max-age：设置响应中包含对象的过期时间。
• ALL: no-store 不允许缓存。

Connection：在请求头中，Connection：close 指令告诉 Web 服务器或者代理服务器，在完成本次请求响应后断开连接，无须等待本次连接的后续请求，Connection：keep-alive 告诉 Web 服务器或者代理服务器，在完成本次请求响应后保持连接，等待本次连接的后续请求。在响应头中，close 连接已关闭。keep-alive 保持连接，等待本次连接的后续请求，如果浏览器请求保持连接，则该头部表明希望 Web 服务器保持连接的时长（秒），例如，keep-alive：300。

请求报文头：
请求首部字段（Request Header Fields）从客户端向服务器端发送请求报文时使用的首部。补充了请求的附加内容、客户端信息、响应内容相关优先级等信息。

• Accept：告诉 Web 服务器自己能接收什么媒体类型，/ 表示能接收任何类型，type/*- 表示接收该类型下的所有子类型，一般格式为 type/sub-type，多个类型使用 q 参数分割，q 的值代表 quality 请求质量也就是权重值，反映了用户对这类媒体类型的偏好程度，例如 Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8, text/x-c。

• Accept-Charset：浏览器接收内容的字符集，通常是 utf-8。

• Accept-Encoding：浏览器接收内容的编码方法，例如指定是否支持压缩，若支持压缩的话支持什么压缩方法，具体如 Accept-Encoding:gzip, deflate, sdch。

• Accept-Language：浏览器接收内容的语言。语言跟字符集是有区别的，例如中文是语言，中文有多种字符集，big5、gb2312、gbk 等。该参数也可以设置多个，如 Accept-Language: zh-CN,zh;q=0.8。

• Authorization：当客户端接收到来自 Web 服务器的 WWW-Authenticate 响应时，后面可以用该头部来携带自己的身份验证信息给 Web 服务器直接进行认证。

• Host:指定被请求资源的Internet主机和端口号，它通常从HTTP URl中提取出来。

• Referer:当浏览器向web服务器发送请求的时候，一般会带上Referer，告诉服务器我是从哪个页面链接过来的，服务器可以获得一些信息用于处理。

• User-Agent:告诉HTTP服务器，客户端使用的操作系统和浏览器的版本与名称。很多情况下我们可以通过User-Agent来判断浏览器类型，从而进行不同的兼容设计。

响应报文头：
响应首部字段（ Response Header Fields）从服务器端向客户端返回响应报文时使用的首部。补充了响应的附加内容，也会要求客户端附加额外的内容信息。

Accept-Ranges：Web 服务器表明自己是否接受获取某个实体的一部分（比如文件的一部分）请求，这里主要用于部分文件传输，实际上我们用的比较少。bytes 表示接受传输多大长度内容，none 表示不接受。

Age：一般当服务器用自己缓存的实体去响应请求时，可以用该头部表明实体从产生到现在经过了多长时间，如 Age: 3600。

Etag：对象（比如 URL）的标志值。一个对象（如 HTML 文件）如果被修改了，其 Etag 也会被修改，所以 Etag 的作用和 Last-Modified 差不多，主要供 Web 服务器判断一个对象是否改变。例如前一次请求某个 HTML 文件时获得了其 Etag，当这次又请求该文件时，浏览器就会把先前获得的 Etag 值发送给 Web 服务器，然后 Web 服务器会将这个 Etag 值跟该文件当前的 Etag 值进行对比，判断文件是否改变。

实体报文头：
实体首部字段（Entity Header Fields）针对请求报文和响应报文的实体部分使用的首部。补充了资源内容更新时间等与实体有关的信息。

Allow：该参数头部可以设置服务端支持接收哪些可用的 HTTP 请求方法，例如 GET、POST、PUT，如果不支持，则会返回 405(Method Not Allowed)。

Content-Encoding：与请求头的 Accept-Encoding 对应，指 Web 服务器表明使用何种压缩方法（gzip，deflate）压缩响应中的对象，例如，Content-Encoding：gzip。

Content-Language：与请求头中的 Accept-Language 对应，Web 服务器告诉浏览器响应的媒体对象语言。

Content-Length：Web 服务器告诉浏览器 HTTP 请求内容的长度。例如，Content-Length: 1024。

Content-Range：Web 服务器表明该响应包含的部分对象为整个对象的哪个部分。

Content-Type：与请求头的 Accept 对应，指明 Web 服务器告诉浏览器响应的对象的类型。例如，Content-Type：application/xml。

HTTP报文结构分析——请求报文

HTTP报文结构分析——响应报文

HTTP请求方法的解析

HTTP常用方法;GET,POST,PUT,HEAD,DELETE,OPTIONS,TRACE,CONNNECT。
1、get请求：
get：可以理解 为 取 的意思，对应select操作
用来获取数据的，只是用来查询数据，不对服务器的数据做任何的修改，新增，删除等操作。
说明：
get请求会把请求的参数附加在URL后面，这样是不安全的，在处理敏感数据时不用，或者参数做加密处理。
get请求其实本身HTTP协议并没有限制它的URL大小，但是不同的浏览器对其有不同的大小长度限制

举例：
https://www.tapd.cn/company/my_take_part_in_projects_list?project_id=20085821&t=1655176334048&from=left_tree

2、post请求：
post 可以理解 为 贴 的意思
数据发送到服务器以创建或更新资源，侧重于更新数据，对应update操作
说明：
post请求的请求参数都是请求body中，一般用来传输实体的主体，post方法的主要目的不是为了获取响应体的内容，而且post请求其实本身HTTP协议并没有限制它的URL大小,克服了GET方法的保密性差和url大小被限制的缺点。
举例：
https://www.tapd.cn/20085821/bugtrace/buglists/query/1/created/desc?query_token=%……&&**

3、put请求：
put：可以理解为 放 的意思
数据发送到服务器以创建或更新资源，侧重于创建数据，对应insert操作
put方法和post方法有些类似，最大的不同是;put是幂等的，post是不幂等的，因此，put方法用作传输资源

4、delete请求：
delete：字面意思删除，即删除数据，对应delete操作
用来删除指定的资源，它会删除URI给出的目标资源的所有当前内容

5、options请求：
用来描述了目标资源的通信选项，返回服务器针对特定资源所支持的HTTP请求方法，也可以利用向web服务器发送‘*’的请求来测试服务器的功能性![
举例：https://imgservice.csdn.net/direct/v1.0/image/upload?type=blog&rtype=markdown&x-image-template=standard&x-image-app=direct_blog&x-image-dir=direct&x-image-suffix=png

6、head请求：
HEAD方法与GET方法相同，但没有响应体，仅传输状态行和标题部分。这对于恢复相应头部编写的元数据非常有用，而无需传输整个内容，用于获取报头。

7、connect请求：
CONNECT方法用来建立到给定URI标识的服务器的隧道；它通过简单的TCP / IP隧道更改请求连接，通常实使用解码的HTTP代理来进行SSL编码的通信（HTTPS）。也就是开启一个客户端和所请求资源之间的双向沟通的通道，它可以用来创建隧道。

8、trace请求：
TRACE方法用于沿着目标资源的路径执行消息环回测试；它回应收到的请求，以便客户可以看到中间服务器进行了哪些（假设任何）进度或增量。也就是回显服务器收到的请求，主要用于测试和诊断

综上，大家记得以下总结，即达到目的
1、get 取，是查询数据，对应select操作
2、post 贴，常用于修改数据，对应update操作
3、put 放，常用于新增数据，对应insert操作
4、delete 删，是删除数据，对应delete操作

HTTP响应状态码拆解

状态码

是用以表示网页服务器超文本传输协议响应状态的3位数字代码。

一、1开头的状态码(信息类)

100，接受的请求正在处理，信息类状态码

二、2开头的状态码(成功类)

2xx(成功)表示成功处理了请求的状态码
200(OK)服务器已成功处理了请求。
202(Accepted)已经接受请求，但未处理完成。
206(Partial Content)服务器成功处理了部分get请求。

三、3开头的状态码(重定向)

3xx(重定向)表示要完成请求，需要进一步操作。通常这些状态代码用来重定向。
301(Moved Permanently)，永久性重定向，表示资源已被分配了新的 URL,返回信息会包括新的URL，浏览器会自动定向到新的URL。
302(Found)，临时性重定向，表示资源临时被分配了新的 URL，客户端用继续使用原有的URL
303，表示资源存在另一个URL，用GET方法获取资源
304(Not modified)，(未修改)自从上次请求后，请求网页未修改过。服务器返回此响应时，不会返回网页内容

四、4开头的状态码(请求错误)

4xx(请求错误)这些状态码表示请求可能出错，妨碍了服务器的处理
400(Bad Request)服务器不理解请求的语法
401(Unauthorized)表示发送的请求需要有通过HTTP认证的认证信息,需要身份认证
403(Forbidden)服务器理解客户端的请求，但是拒绝执行此请求
404(Not Found)服务器找不到请求网页

五、5开头的状态码(服务器错误)

5xx(服务器错误)这些状态码表示服务器在尝试处理请求时发生内部错误。这些错误可能是服务器本身的错误，而不是请求的错误
500，(Internal Server Error)服务器遇到错误，无法完成请求
502，(Bad Gateway)充当网关或代理的服务器，从远端服务器接受到了一个无效的请求
503，表示服务器处于停机维护或超负载，无法处理请求

HTTP状态管理(会话机制)：Cookie和Session

Cookie

Cookie实际上是一小段的文本信息，客户端请求服务器，如果服务器需要记录该用户状态，就向客户端浏览器颁发一个Cookie。客户端浏览器会把Cookie保存起来，当浏览器再次请求该网站时，浏览器把请求的网站连同该Cookie一同提交给服务器，服务器检查该Cookie，以此来辨别用户状态。

Session

Session是另一种记录客户状态的机制，保存在服务器上，客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上，客户端浏览器再次访问时只需要从该Session中查找该客户的状态就可以了

保存SessionID的方式：Cookie、URL重写和隐藏表单。
Cookie就是上图描述的方式，URL重写有俩种方法，

• 第一种是直接把sessionID附加到URL路径的后面
  
• 第二种是作为参数放到URL路径的后面

Session的有效期

• Session超时失效：当访问越来越多，Session也越来越多，为了防止内存溢出，会自动把长时间不用的Session删除。
• 程序调用HttpSession.invalidate()主动来删除一个Session来让此Session失效
• 服务器进程或停止也会使Session失效

Cookie和Session的区别
1、保存的位置不同
cookie保存在浏览器端，session保存在服务端。
2、使用方式不同
cookie如果在浏览器端对cookie进行设置对应的时间，则cookie保存在本地硬盘中，此时如果没有过期，则就可以使用，如果过期则就删除。如果没有对cookie设置时间，则默认关闭浏览器，则cookie就会删除。
session：我们在请求中，如果发送的请求中存在sessionId，则就会找到对应的session对象，如果不存在sessionId,则在服务器端就会创建一个session对象，并且将sessionId返回给浏览器，可以将其放到cookie中，进行传输，如果浏览器不支持cookie，则应该将其通过encodeURL(sessionID)进行调用，然后放到url中。
3、存储内容不同：cookie只能存储字符串，而session存储结构类似于hashtable的结构，可以存放任何类型。
4、存储大小：``cookie最多可以存放4k大小的内容，session则没有限制。
5、session的安全性要高于cookie
6、cookie的session的应用场景：cookie可以用来保存用户的登陆信息，如果删除cookie则下一次用户仍需要重新登录
session就类似于我们拿到钥匙去开锁，拿到的就是我们个人的信息，一般我们可以在session中存放个人的信息或者购物车的信息。
7、session和cookie的弊端：cookie的大小受限制，cookie不安全，如果用户禁用cookie则无法使用cookie。如果过多的依赖session，当很多用户同时登陆的时候，此时服务器压力过大。sessionId存放在cookie中，此时如果对于一些浏览器不支持cookie，此时还需要改写代码，将sessionID放到url中，也是不安全。

HTTP协议之认证

BASIC认证(基本认证)
基础认证简单的使用base64对密码、用户名进行加密，并将加密后的信息放在Header中，本质上还是明文传输用户名、密码等，但是安全等级太低，现在基本不用，基本流程：

• 客户端发起GET请求
• 服务器响应401 Unauthorized，www-Authenticate指定认证算法，realm指定安全域
• 客户端重新发起请求，Authorization指定用户名和密码信息
• 服务器认证成功，响应200
  

优点：简单易用，容易实现和理解，可以在各种环境下使用。
缺点：安全性较弱，因为用户名和密码只是经过 Base64 编码而并非加密，容易被拦截和解码，不适用于传输敏感信息

DIGEST认证(摘要认证)
摘要认证使用随机数+MD5加密哈希函数来对用户名、密码进行加密，在上述第二步时服务器返回随机字符串nonnce，之后客户端发送摘要=MD5（HA1:nonce:HA2），其中HA1=MD5(username:realm:password),HA2=MD5(method:digestURI)

优点：相对于基本认证，提供了更高的安全级别，密码不会明文传输，随机数和摘要保护了密码的安全性。
缺点：相对复杂，每次请求都需要进行摘要计算，对服务器资源开销较大。不适用于传递敏感数据或资源保护级别较高的场景。

SSL客户端认证
SSL 客户端认证（SSL Client Authentication）是一种基于 SSL/TLS 协议的身份认证方式，通过客户端提供有效的数字证书来验证其身份。SSL 客户端认证的过程如下：

1. 服务器要求客户端进行 SSL 客户端认证，并发送证书请求（Certificate Request）给客户端。
2. 客户端在收到证书请求后，选择合适的数字证书，并将其发送给服务器。客户端证书通常由客户端事先生成或者由认证机构（CA）颁发。
3. 服务器收到客户端的证书后，会验证该证书的有效性和真实性。这个验证过程包括检查证书的签名、有效期、颁发者的信任等。
4. 如果服务器验证客户端提供的证书通过，那么认证成功，SSL 握手过程继续，服务器和客户端之间建立安全连接，并进行数据传输。
5. 如果服务器验证失败，那么认证失败，服务器可以选择终止连接或采取其他措施，比如要求重新进行认证或者拒绝服务。

优点：基于公钥加密技术，提供了较高的身份验证安全性，客户端使用数字证书进行身份认证，无需传输密码。
缺点：配置复杂，需要生成和管理证书，适用性较低，需要客户端和服务器都支持证书认证。

FormBase认证(基于表单认证)
基于表单的认证（Form-based Authentication）是一种常用的身份认证方式，通常应用于 Web 应用程序中。基于表单的认证的基本原理是，用户在 Web 应用程序的登录页面（表单）中提供用户名和密码，然后将这些凭据发送给服务器进行验证，并获取相应的资源和权限。基于表单的认证一般通过以下步骤实现：

1. 用户在 Web 应用程序的登录页面中输入用户名和密码，将数据封装在表单中提交给服务器。
2. 服务器对用户提供的用户名和密码进行验证，通常会将密码进行哈希计算，并与存储在服务器中的哈希密码进行比对，以判断用户是否授权访问资源。
3. 如果用户名和密码验证通过，应用程序会为该用户创建一个会话，并将会话 ID 放入用户的 Cookie 中，以便后续资源访问的验证和跟踪。
4. 用户在 Web 应用程序中访问资源时，应用程序会验证用户的会话 ID，以确保用户已经通过了身份认证。如果用户会话 ID 无效或者已经过期，应用程序会通知用户需要重新进行身份认证。

基于表单的身份认证是一种简单、有效的身份认证方式。它可以使用 HTTPS 协议进行数据传输，增加安全性。但是基于表单的身份认证也存在一些缺点，其中最常见的是会话劫持攻击（Session Hijacking），攻击者可以通过各种手段获取合法用户的会话 ID，并使用该会话 ID 进行身份认证，获得资源访问权限。

为了避免会话劫持攻击，应用程序可以使用基于 Token 的认证方式（比如 JSON Web Token），将随机生成的 Token 放入用户的 Cookie 中返回给客户端，而不是直接将会话 ID 放入 Cookie 中，从而降低攻击风险。此外，应用程序还可以采用其他安全策略，如使用密钥链（Key Chain）或单向哈希（One-way Hash）技术来处理密码等敏感信息，以提高安全性。

HTTP的长连接和短连接

HTTP协议是基于请求/响应模式的，因此只要服务端给了响应，本次HTTP请求就结束了。
HTTP的长连接和短连接本质上是TCP长连接和短连接。
在HTTP1.0中，默认使用的是短连接。也就是说，浏览器和服务器每进行一次HTTP操作，就建立一次连接，结束就中断。
从HTTP1.1开始，默认使用长连接，用以保持连接特性。

在 HTTP 协议中，长连接（Keep-Alive）和短连接是两种不同的连接方式，用于管理客户端与服务器之间的连接持续性。
短连接：
1.默认情况下，HTTP 协议采用短连接方式，即每次客户端发送一个请求后，服务器会发送一个响应并立即关闭连接。
2.短连接适用于客户端只需获取一次请求的响应信息，然后立即关闭连接的场景。
3.短连接对服务器的资源要求较低，但在频繁请求的情况下，会造成较多的连接开销和延迟。
长连接：
1.长连接是指客户端与服务器之间建立一次连接后，可以持久保持连接，多次请求和响应在同一连接上完成。
2.长连接通过在请求头中设置 Connection: Keep-Alive 来告知服务器保持连接开放。
3.长连接适用于客户端需要发送多个请求给同一服务器的场景，减少了连接建立和关闭的开销。
4.长连接可以有效降低延迟，提高网络传输效率，尤其适用于移动端和实时通信应用。
需要注意的是，长连接并不是永久的连接，服务器和客户端都可以主动断开连接。此外，长连接在一些情况下可能会导致服务器资源占用过高，因此服务器一般会设置连接超时时间，以确保资源的合理分配。
值得一提的是，HTTP/1.1 引入了持久连接（Persistent Connection）的概念，使得多个请求和响应可以复用同一连接，而无需频繁地创建和关闭连接，有效提高了网络性能。

HTTP中介之代理

HTTP代理是位于客户端和服务器之间的一种位于网络中转的服务器，用于接收客户端和服务器之间的HTTP请求和响应。代理可以是透明代理（Transparent Proxy）或匿名代理（Anonymous Proxy）。

代理服务器的作用如下：

1. 缓存静态资源：

   • 代理服务器可以缓存将要发送到客户端的静态资源，如图片、样式表和脚本等，以减少客户端和服务器之间的网络传输。
   • 代理服务器还可以缓存向服务器请求的数据，以便下一次请求时可以直接从代理服务器中获取，而无需从服务器中获取。

2. 过滤和截获数据：

   • 代理服务器可以过滤和修改HTTP请求和响应，以便提供安全、过滤和修改功能。
   • 代理可以监视并记录所有请求和响应，以提供安全审计和调试工具。

3. 内容访问控制：

   • 代理可以根据各种原因（如地理位置、用户身份、设备等）限制或过滤客户端请求，保护服务器资源。

4. 提高性能：

   • 代理服务器可以将单个服务器分解为多个逻辑服务器，从而提高HTTP请求的吞吐量和性能。
   • 代理服务器还可以增加数据压缩和请求最小化技术，以减小数据传输和客户端请求的大小。

总的来说，HTTP代理作为客户端与服务器之间的一个中介，可以提高性能、安全性和可靠性，并且在互联网上的负载均衡和数据流管理扮演着重要的角色。

HTTP中介之网关

HTTP网关（HTTP Gateway）是一种在代理服务器和应用服务器之间转换协议的设备或应用程序，将HTTP请求和响应转换成其他协议，并将其他协议的请求和响应转换成HTTP协议。网关可以提供对于其他协议的支持，使得使用HTTP协议的客户端可以访问其他协议的网络资源。

通常来说，网关主要有以下几个功能：

1. 网络协议转换：

   • 网关拦截并解析HTTP请求和响应，将其转换为其他协议（如SMTP、FTP等），以便客户端能够访问非HTTP协议的资源。

2. 安全性：

   • 网关可以检查和过滤HTTP请求和响应，以提供保护和安全的访问方式。
   • 网关还可以提供安全性和可靠性的服务，例如将HTTP请求和响应加密。

3. 缓存：

   • 网关还可以缓存非HTTP协议的数据，以加快后续请求速度。
   • 网关缓存的内容可以是其他协议的数据，如FTP文件或邮件附件等。

4. 负载平衡：

   • 网关可以分担Web服务器的负荷，提高性能和可靠性，通过将HTTP请求转发给多个Web服务器构建一个负载平衡的环境。

HTTP网关具有以下特点：

1. 网关位于应用层协议的上层，将HTTP请求和响应转换回其他协议，然后将其路由到业务服务器处理。

2. 网关可以将客户端请求分发给不同的服务器，实现负载均衡和高可用性。

3. 网关还可以提供安全加密机制和访问控制，以确保网络资源的安全性。

需要注意的是，网关是在HTTP协议和其他协议之间转换的设备或应用程序，而代理则是在HTTP协议中进行缓存和过滤的设备。两者的作用虽然有所重叠，但它们的实现方式和目标是不同的。

网关的类型：

1. 网关路由器（Gateway Router）：

   • 网关路由器是网络中的边界设备，连接不同的网络。它可以将传入的数据包从一个网络转发到另一个网络，执行网络地址转换（NAT）等功能。网关路由器通常用于连接局域网（LAN）和广域网（WAN）之间，例如将内部网络连接到互联网。

2. 应用网关（Application Gateway）：

   • 应用网关是位于应用层的网关，负责连接不同的应用程序和协议。它可以执行协议转换、路由、负载均衡、缓存等功能。应用网关常用于构建面向服务的体系结构（SOA）和微服务架构，以便在不同的应用程序之间进行通信和集成。

3. 安全网关（Security Gateway）：

   • 安全网关是一个网络安全设备，用于保护网络免受威胁和攻击。它可以执行防火墙、入侵检测和防御（IDS/IPS）、虚拟专用网络（VPN）连接等安全功能。安全网关可帮助保护网络资源免受未经授权的访问、恶意软件和数据泄露等威胁。

4. 缓存网关（Cache Gateway）：

   • 缓存网关是一种具有缓存功能的网关，用于加速访问网页、静态内容和其他常用数据。它可以缓存从后端服务器获取的数据，以便将来的请求可以快速获得响应，从而减少对后端服务器的负载并提高用户体验。

5. 电子邮件网关（Email Gateway）：

   • 电子邮件网关是用于处理和转发电子邮件的网关。它可以执行电子邮件的路由、协议转换、垃圾邮件过滤、病毒扫描和加密等功能。电子邮件网关帮助保护邮件服务器免受垃圾邮件、恶意软件和数据泄露等威胁，并提供更好的电子邮件传输和安全性。

内容协商机制

在HTTP协议中，内容协商机制指的是在客户端（浏览器）和服务器之间，在处理响应数据时，根据客户端的参数，协商出最佳的响应内容。具体来说，包括以下3种协商方式：

1. 请求头中的 Accept：客户端在发送请求时，可以通过Accept头部字段指定它所能处理的响应数据类型，比如text/html、application/json、image/jpeg等。服务器基于这些参数，返回客户端最适宜的内容形式。

2. 请求头中的 Accept-Language：客户端可以通过Accept-Language头部字段指定其能够处理的自然语言。服务器基于这些参数，返回客户端最适宜的自然语言版本的内容，请求时可以使用多种语言赋值优先值q来实现。

3. 请求头中的 Accept-Encoding：客户端可以通过Accept-Encoding头部字段指定它所支持的编码方式，比如gzip、deflate等。服务器基于这些参数，返回客户端最适宜的编码形式，从而能够更快地传输数据。

断电续传和多线程下载

断点续传和多线程下载：HTTP通过在Header里面俩个参数实现的，客户端发请求时对应的是Range，服务器端响应时对应的是Content-Range。

Range是一个请求头部字段，用于指定客户端希望获取的资源的范围。它主要用于实现断点续传或获取部分资源的功能。

Range头部字段的格式为：
Range: bytes=start-end

其中，start表示起始位偏移量，end表示结束位偏移量。这个范围是相对于资源的字节偏移量而言的，以0开始计数。如果只指定start而不指定end，则表示从start开始获取到资源的末尾。

客户端可以将Range头部字段包含在HTTP请求中，向服务器发送希望获取的资源范围。服务器在收到这个请求后，会根据Range字段指定的范围返回部分资源，状态码为206 Partial Content。服务器会在响应头部中使用Content-Range字段指示返回的资源范围，并在响应体中返回实际的资源数据。

通过使用Range头部字段，客户端可以实现断点续传，只请求下载未下载的部分资源，从而减少网络带宽的消耗和下载时间，提高下载效率。同时，Range头部字段还可以用于获取大文件中的特定部分，而不需要下载整个文件。

Content-Range是HTTP响应头部字段，用于指示服务器返回的响应实体的范围和总大小，通常与Range请求头部字段一起使用。

Content-Range的格式为：
Content-Range: bytes start-end/total

其中，start表示响应实体的起始位偏移量，end表示响应实体的结束位偏移量，total表示整个资源的总大小。

当服务器返回带有Range请求头部字段的部分资源时，会在响应头部中包含Content-Range字段，以指示返回的资源范围。例如，Content-Range: bytes 5000000-9999999/20000000 表示服务器返回的是从第5000000字节到第9999999字节的响应实体，而整个资源的总大小为20000000字节。

使用Content-Range字段，客户端可以得知服务器返回的是部分资源，并且可以获取响应实体的范围和总大小。这对于实现断点续传、分块下载或获取大文件的特定部分非常有用，并提供了更准确的资源管理和下载控制。

断点续传的一个完整过程

断点续传是在下载大文件时实现的一种功能，可在网络中断或下载中止后，从已下载的位置继续下载而不必重新开始。以下是一个简单的断点续传过程的示例：

1. 客户端发起初始下载请求：客户端向服务器发送一个HTTP GET请求，不带Range头部字段，请求完整的文件资源。

2. 服务器响应并返回资源信息：服务器接收到请求后，返回HTTP响应，状态码为200 OK，并在响应头部中包含文件的总大小（Content-Length字段）。

3. 客户端接收响应并开始下载：客户端接收到服务器的响应后，创建一个本地文件用于保存下载的数据，并从响应中读取数据开始下载。

4. 下载中断或网络故障：在下载过程中，如果网络中断或其他错误导致下载中止，客户端会记录已下载的字节数。

5. 客户端恢复下载请求：客户端重新连接到服务器，并发送一个带有Range头部字段的HTTP GET请求，指定要继续下载的数据范围。Range头部字段的值为“bytes=<已下载字节数>-”，表示从已下载字节数开始下载剩余的部分（字节范围）。

6. 服务器处理续传请求：服务器接收到带有Range头部字段的请求后，会解析Range的范围，返回对应范围的资源数据，并在HTTP响应头部中使用206 Partial Content状态码和Content-Range字段指示资源的范围。

7. 客户端接收数据并将其写入文件：客户端接收到服务器返回的数据后，将其写入之前创建的本地文件中，继续从上次下载中止的位置记录已下载字节数。

8. 完成下载或重复步骤5-7：下载会继续进行，直到下载完整个文件或再次中断。如果下载完成，客户端会断开连接并完成整个断点续传过程。

断点续传使得大文件的下载更加可靠和高效，避免了重新下载整个文件的需求，同时提升了用户的下载体验。

HTTPS协议概述

HTTP目前的缺点是：

1. 通信使用明文，不加密，可能会被窃听
2. 不会验证通信方的身份，可能会被伪装
3. 无法证明报文的完整性，报文可能被更改

HTTPS (HyperText Transfer Protocol Secure) 是一种通过加密和身份验证来保护网站数据传输的协议。它是 HTTP 的安全版本，并不是应用层的一种新协议，只是HTTP中的部分协议被SSL或者TLS所替代，通过使用 SSL (Secure Sockets Layer) 或其继任者 TLS (Transport Layer Security) 加密来确保数据的机密性和完整性。

使用 HTTPS 可以提供以下保护：

1. 加密：HTTPS 使用加密算法来保护数据在传输过程中的安全性，防止恶意用户窃听、篡改或窃取敏感信息。
2. 身份验证：HTTPS 使用数字证书来验证网站的身份，确保用户在与网站建立连接时无法被劫持或欺骗。
3. 完整性保护：HTTPS 可以防止数据在传输过程中被篡改或损坏，确保数据的完整性。

通过使用 HTTPS，网站可以提供更高的安全性和保护用户隐私。许多网站都已经采用了 HTTPS 作为默认的传输协议，特别是在涉及个人信息、支付信息或其他敏感数据的情况下。因此，当您在浏览网站时，尽量寻找通过 HTTPS 加密保护的安全连接，以确保您的数据传输得到适当的保护。

HTTPS的使用成本

HTTPS 的使用成本包括以下几个方面：

1. 证书费用：为了使用 HTTPS，您需要为您的网站获取数字证书。这些证书通常需要购买并进行定期更新。证书费用因证书类型、证书颁发机构和证书有效期的不同而有所差异。

2. 服务器资源：为了支持 HTTPS，您的服务器需要进行加密和解密数据传输。这意味着服务器需要更多的计算资源来处理传输过程中的加密和解密操作，这可能会增加服务器的负载。您可能需要考虑升级服务器或增加服务器数量来满足这些额外的资源需求。

3. 配置和维护：配置和维护 HTTPS 可能需要一些技术知识和专业技能。您需要确保正确地安装和配置证书、配置服务器以支持 HTTPS，并进行定期的证书更新和安全策略更新。

4. 性能影响：由于加密和解密过程的额外开销，使用 HTTPS 可能会对网站的性能产生一定的影响。特别是对于大型网站和资源密集型应用程序，可能需要优化服务器和网站的配置，以确保在提供安全保护的同时保持良好的性能。

尽管 HTTPS 的使用成本存在一些方面的考虑和投入，但它提供了重要的安全和隐私保护，对于涉及敏感信息或进行在线交易的网站来说是至关重要的。在当前的网络环境中，保护用户数据和建立用户信任是非常重要的，因此多数网站都应当采用 HTTPS 来提供更安全的连接。

HTTPS对性能的影响

使用 HTTPS 可能会对网站性能产生一些影响，主要是由于加密和解密数据的过程会增加服务器和客户端的计算负载。下面是 HTTPS 对性能的几个主要影响因素：

1. 建立握手的开销：在建立 HTTPS 连接时，需要进行握手过程，涉及多轮的通信和密钥协商。这个过程会增加初始连接的延迟，并且在网络拥塞或高延迟条件下，可能导致连接建立的时间增加。
   

2. 加密和解密的开销：使用 HTTPS 时，数据需要在传输过程中进行加密和解密操作。这涉及额外的计算和处理开销，可能会增加服务器和客户端的负载。在资源受限的设备上或高流量网站上，可能需要特别关注性能问题。

3. 缓存困难：HTTPS 请求的缓存通常比 HTTP 请求更具限制。由于数据被加密，中间缓存服务器无法缓存和共享特定用户的数据。这可能导致从服务器获取资源的频率更高，增加了对服务器的请求负载。

尽管 HTTPS 可能对性能产生一些影响，但现代的计算能力和网络基础设施的改善有助于减轻这些影响。此外，以下措施可以缓解 HTTPS 对性能的影响：

• 优化服务器配置：根据服务器硬件和软件的要求，对服务器进行调整和优化，以最大限度地提高 HTTPS 的性能。
• 使用 TLS 加速器：TLS 加速器是专门的硬件设备，可处理大量的加密和解密操作，以减轻服务器的负载。
• 强化缓存策略：使用适当的缓存策略，包括适当的缓存头设置，以最大限度地减少从服务器获取资源的请求。

总之，虽然 HTTPS 可能会对网站性能产生一些影响，但为了保护用户隐私和数据安全，将网站迁移到 HTTPS 是非常重要的。借助适当的优化和配置，可以最小化对性能的负面影响，并确保提供更安全的用户体验。

HTTPS的加密

HTTPS的加密过程与身份认证
HTTPS 使用了两个主要的加密过程来保护数据传输的安全性：对称加密和非对称加密。

1. 对称加密：对称加密使用相同的密钥来加密和解密数据。在建立 HTTPS 连接时，服务器和客户端会协商一个共享的对称密钥。一旦密钥协商完成，所有数据都会使用这个密钥进行加密和解密。对称加密算法通常具有较高的加密和解密性能，因此在实际的数据传输过程中，对称加密被用于加密大量的数据。

2. 非对称加密：非对称加密使用一对密钥：公钥和私钥。公钥可以被共享给其他人，而私钥是保密的。在 HTTPS 连接建立过程中，服务器会将其公钥发送给客户端。客户端使用服务器的公钥来加密一个用于对称密钥交换的随机生成的密钥。然后，服务器使用自己的私钥来解密该随机密钥。一旦对称密钥被协商好，后续的数据传输即可使用对称加密进行加密和解密。

通过使用对称加密和非对称加密的组合，在建立 HTTPS 连接时，客户端和服务器可以协商一个对称密钥，并使用对称加密算法来加密和解密实际的数据传输。这样，即完成了加密和解密，又保证了数据的机密性。使用非对称加密协商对称密钥的过程可以保证密钥的安全传输，避免了潜在的窃听和中间人攻击。

最常见的对称加密算法是 AES (Advanced Encryption Standard)，而非对称加密算法通常使用的是 RSA、Diffie-Hellman 或椭圆曲线加密算法。通过这种加密方式，HTTPS 可以保护数据传输的机密性和完整性，确保用户的隐私和安全性。

HTTPS的身份验证

HTTPS 通过使用数字证书来进行身份验证。数字证书是由受信任的第三方机构（证书颁发机构）签发的电子文件，用于验证服务器的身份并提供加密通信。

以下是 HTTPS 的身份验证过程：

1. 服务器获取证书：服务器管理员向证书颁发机构申请数字证书。证书颁发机构将验证服务器的身份，并使用其私钥对服务器的公钥进行签名，生成数字证书。该数字证书包含了服务器的公钥、证书持有者的信息和证书颁发机构的数字签名。

2. 客户端请求连接：当用户访问一个使用 HTTPS 的网站时，客户端（通常是 web 浏览器）将发送一个连接请求到服务器。

3. 服务器发送数字证书：服务器接收到客户端的连接请求后，会将服务器的数字证书发送给客户端。这个数字证书会包含服务器的公钥和证书的相关信息。

4. 客户端验证数字证书：客户端的浏览器会验证服务器的数字证书。它会检查证书颁发机构的信任链，确保证书的有效性和可信性。如果证书是由受信任的证书颁发机构签发的，并且没有过期或被吊销，客户端会接受证书并继续连接。

5. 建立加密连接：一旦客户端接受了服务器的数字证书，它会生成随机的对称密钥，并使用服务器的公钥对其进行加密。服务器使用自己的私钥解密客户端发送的密钥，建立对称加密方式下的加密连接。

通过使用数字证书和公钥加密，HTTPS 实现了服务器身份验证和通信数据的加密保护。这确保了客户端与服务器之间的通信是安全的，并可防止中间人攻击和信息窃听。用户可以通过查看浏览器的地址栏中显示的安全锁图标来确认连接是否使用了 HTTPS，并且数字证书是否有效。

HTTP协议的瓶颈

1. 明文传输：HTTP 在传输数据时使用明文，这意味着数据可以被窃听和篡改。缺乏数据加密和身份验证机制可能会导致安全漏洞。

2. 不可靠的连接：HTTP 是一种无状态协议，它没有内建的机制来跟踪连接状态。每次请求-响应周期都是相互独立的，这将导致每个请求都需要重新建立连接，增加了网络开销和延迟。

3. 频繁的请求：HTTP 采用了简单请求-响应模型，每个请求都需要一个完整的 HTTP 报文，包括请求头和响应头等信息。对于短时间内频繁的请求，这些额外的开销可能成为瓶颈，影响性能和效率。

4. 串行处理：标准的 HTTP 协议在发送请求后需要等待响应才能发送下一个请求，这意味着在传输大量资源时，必须等待前一个请求完成才能开始下一个请求，无法充分利用网络带宽。

为了解决这些问题，出现了一些改进的协议和技术，例如：

1. HTTPS：HTTPS 通过加密和身份验证解决了 HTTP 的安全性问题，使用 SSL/TLS 协议对通信进行加密，保护数据的机密性和完整性 。

2. 持久连接：HTTP/1.1 引入了持久连接机制，复用同一个连接进行多个请求和响应，减少了连接建立和关闭的开销，提高了性能。

3. 压缩：通过压缩 HTTP 报文和资源文件，可以减少数据传输的大小，节省带宽和提高性能。

4. 并行处理：使用技术如多线程或多路复用，可以实现同时处理多个请求，提高请求的并发处理能力。

另外，新一代的协议，如 HTTP/2 和 HTTP/3，引入了更多性能优化的特性，如多路复用、头部压缩和服务器推送等，进一步改善了 HTTP 的性能瓶颈。

双工通信的WebSocket网络协议

WebSocket的资料

WebSocket 是一种双向通信协议，它主要用于在 Web 应用程序和服务器之间建立持久连接，实现实时通信（例如聊天系统、数据监控等）。

与 HTTP 不同的是，WebSocket 建立一次连接后，可以在客户端和服务器之间不间断地发送和接收数据，而无需每次都重新建立连接。这种双向通信的实现方式与 HTTP 传输的单向请求/响应模型相比，大大提高了通信的效率和实时性。

WebSocket 通过将 HTTP 协议升级到 WebSocket 协议来实现双向通信。建立 WebSocket 连接的过程如下：

1. 客户端向服务器发送 HTTP 请求并请求升级协议：

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

其中，Upgrade 和 Connection 表示将协议从 HTTP 升级为 WebSocket，Sec-WebSocket-Key 是客户端用来验证服务器的响应的密钥。

2. 服务器返回 HTTP 响应并升级协议：

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

其中，Sec-WebSocket-Accept 是服务器用来验证客户端的响应的密钥。

3. 连接建立后，客户端和服务器可以进行双向通信，通过发送 WebSocket 帧来传输数据。

WebSocket 的双向通信实现了实时数据交换和推送，可以应用于各种 Web 应用程序中。然而，需要注意安全性问题，包括 XSS、CSRF 和基于 WebSocket 的 DoS 攻击等。因此，建议在使用 WebSocket 时，通过授权和鉴权等手段来确保数据安全和合法性。

WebSocket的特点

WebSocket 的特点主要包括以下几个方面：

1. 双向通信：WebSocket 实现了双向通信，允许客户端和服务器之间实时地进行双向数据传输。相比起传统的 HTTP 请求-响应模型，WebSocket 的双向通信模式能更快地实现实时数据的推送和更新。

2. 持久连接：一旦建立了 WebSocket 连接，客户端和服务器之间的连接将保持打开状态，允许多个消息的连续传输，而不需要重复建立连接和发送额外的 HTTP 请求。这种持久连接减少了连接建立和关闭的开销，提高了通信的效率。

3. 低延迟：由于 WebSocket 连接始终保持打开状态，而不需要重复建立连接，可以实时地进行数据传输。这使得 WebSocket 可以在实时性要求较高的应用场景下，如聊天、在线游戏和股票交易等，提供较低的延迟。

4. 小的开销：WebSocket 使用较小的数据包头，以及基于二进制数据帧的轻量级传输格式，减少了传输的开销。相比起传统的 HTTP 请求，WebSocket 的开销更小，节省了带宽和处理能力。

5. 跨域支持：与其他跨域通信技术（如 XMLHttpRequest）不同，WebSocket 具有跨域通信的能力。通过在服务器端配置适当的跨域策略，可以实现在不同域名之间建立 WebSocket 连接，以进行数据传输和实时通信。

总体而言，WebSocket 的特点使得它成为实时通信和实时数据传输的有效工具。它在许多 Web 应用程序中得到广泛应用，包括聊天室、实时数据监控、在线游戏和实时协作工具等领域。

SPDY网络协议

SPDY网络协议资料
SPDY（SPeeDY）是由 Google 开发的一种优化网络传输的协议。它的目标是减少网页加载时间并提高性能，通过引入新的机制和优化策略来替代传统的 HTTP 协议。

SPDY 的主要特点和改进包括以下几个方面：

1. 多路复用（Multiplexing）：SPDY 允许在单个 TCP 连接上同时传输多个请求和响应。传统的 HTTP 协议需要为每个请求和响应建立一个独立的连接，而多路复用使得服务器能够同时处理多个请求，从而降低了延迟和连接的数量。

2. 请求优先级（Request Prioritization）：SPDY 允许客户端为每个请求设置优先级级别，使得重要的请求可以优先获得资源和响应。这种机制可以有效地提高重要资源的加载优先级，提升用户体验。

3. 压缩（Header Compression）：SPDY 使用了更高效的头部压缩算法，减少了请求和响应数据中头部信息的大小，从而减少了网络传输的数据量，节省了带宽。

4. 服务器推送（Server Push）：SPDY 允许服务器主动推送数据给客户端，提前发送客户端可能需要的资源，避免了客户端发起多个请求的延迟，提高了页面加载速度。

5. 流控制（Flow Control）：SPDY 引入了流控制机制，通过控制数据的流动速率，避免了网络拥塞和过载，提高了传输的稳定性和性能。

6. 安全性（Security）：SPDY 协议必须基于 SSL/TLS 安全套接字进行数据传输，提供了对数据的加密和验证，增强了通信的安全性。

尽管 SPDY 取得了显著的进展，但它已经被 HTTP/2 协议所取代。HTTP/2 在 SPDY 的基础上进行了进一步的改进和优化，并被广泛应用于现代的 Web 环境中。尽管 SPDY 已经停止更新和推广，但其对于网站性能优化的重要性不可忽视。

HTTP2.0网络协议

HTTP2.0资料

HTTP/2.0（又称为HTTP2）是超文本传输协议（HTTP）的第二个主要版本。它是对HTTP/1.1的重大改进，旨在提高性能、效率和安全性。

以下是HTTP/2的一些主要特点和特性：

1. 多路复用（Multiplexing）：HTTP/2采用了多路复用技术，允许通过单个连接同时传输多个请求和响应。这替代了HTTP/1.1中的串行请求模式，减少了延迟，并提高了资源利用率，可以减少服务链接压力，内存占用少了，连接吞吐量大了。由于TCP连接减少而使网络拥塞状况得以改观。慢启动时间减少，拥塞和丢包恢复速度更快。
   

2. 并行双向字节流：这意味着在同一个连接上，客户端和服务器可以同时发送请求和响应。这使得客户端和服务器之间的交互更加灵活，例如实时通信和流式数据传输等场景。但是请求之间也是有优先级的，高优先级的流都应该优先发送，优先级不是绝对的，不同优先级混合也是必须的。

3. 

4. 二进制分帧（Binary Framing）：HTTP/2引入了二进制协议，将请求和响应数据分割成二进制帧，提供更高效的数据传输和解析。这种二进制格式有助于减少开销并提高解析速度。
   

5. 头部压缩（Header Compression）：与SPDY类似，HTTP/2使用了头部压缩机制，减少了请求和响应头部的数据传输量。这通过使用动态表和索引来实现，避免了头部的重复传输，从而降低了带宽占用。也就是在HTTP2.0中，我们使用了HPACK（HTTP2头部压缩算法）压缩格式对传输的header进行编码，减少了header的大小。并在两端维护了索引表，用于记录出现过的header，后面在传输过程中就可以传输已经记录过的header的键名，后端收到数据后就可以通过键名找到对应的值，这样就减少了对重复头部的重复传输。
   

6. 服务器推送（Server Push）：HTTP/2支持服务器主动推送资源给客户端，提前发送可能需要的资源，以优化页面加载速度。服务器可以在解析请求期间发现额外的资源，并直接推送给客户端，减少了往返延迟。

7. 

8. 流控制（Flow Control）：HTTP/2引入了流控制机制，允许客户端和服务器控制数据的流动速率，以适应不同的网络条件和资源限制。这有助于避免拥塞和过载，优化传输的稳定性和性能。

9. 提升安全性：HTTP/2要求使用SSL/TLS加密，强调了数据传输的安全性和保护用户隐私的重要性。

HTTP/2采用了向后兼容的方式，可以在现有的应用程序和基础设施上进行部署。大多数现代的浏览器和服务器都支持HTTP/2，它已经成为许多网站和应用程序中提升性能的首选协议。通过使用HTTP/2，可以减少页面加载时间，提高性能，并提供更好的用户体验。

管理WEB服务器文件的WebDAV协议

WebDAV协议资料
WebDAV（Web Distributed Authoring and Versioning）是一种基于HTTP扩展的协议，用于在网络上进行文件的管理和协同编辑。它允许用户通过Web进行远程文件操作，如上传、下载、重命名、删除等，同时还支持文件夹和属性的管理。

以下是WebDAV协议的主要特点和功能：

1. 统一资源定位符（URL）：WebDAV使用URL来标识和定位服务器上的文件和文件夹。它扩展了HTTP的URL，通过添加一些特定的路径和参数来表示文件的版本、属性和锁定状态等信息。

2. 文件操作和管理：WebDAV允许用户通过HTTP方法（GET、PUT、POST、DELETE等）对服务器上的文件进行操作。用户可以上传、下载、删除、重命名、复制、移动等文件操作，类似于本地文件系统的操作。

3. 文件夹和集合：WebDAV支持对文件夹和集合（Collection）的管理。用户可以创建、删除、重命名文件夹，也可以列出文件夹中的文件和子文件夹。

4. 属性管理：WebDAV允许用户为文件和文件夹定义和管理各种属性。属性可以是基本的元数据（如文件大小、创建日期），也可以是自定义的属性（如作者、版本号等）。用户可以使用PROPFIND和PROPPATCH方法来查询和更新属性信息。

5. 锁定和协同编辑：WebDAV提供了文件级别的锁定机制，允许用户对文件进行独占访问和编辑，以防止多人同时编辑引发冲突。用户可以通过LOCK和UNLOCK方法来申请和释放文件锁。

6. 版本控制：WebDAV支持文件的版本控制，允许用户对文件进行版本历史管理和回滚操作。用户可以通过CHECKOUT、CHECKIN和VERSION-CONTROL等方法来管理文件的版本。

WebDAV协议的设计使得它成为许多应用领域的关键技术，如在线文件管理系统、内容管理系统、协同编辑工具等。它提供了一种标准化的、跨平台的方式来进行文件操作和协同编辑，为用户提供了更方便、更灵活的Web文件管理体验。

QUIC与HTTP3.0

HTTP3.0资料

QUIC（Quick UDP Internet Connections）是一种基于UDP的传输协议，而HTTP/3（也称为HTTP over QUIC或简称为HTTP3）是使用QUIC作为传输协议的下一代HTTP协议。

下面是关于QUIC和HTTP/3的一些关键特点和区别：

QUIC:

• 快速连接建立：QUIC使用0-RTT连接建立，意味着在已经建立过连接的情况下，客户端可以在第一次请求中发送数据，无需等待握手过程完成，从而减少了网络延迟。

• 多路复用：QUIC支持全双工的多路复用，允许在单个连接上同时处理多个请求和响应。这消除了HTTP/1.1中的串行请求和HTTP/2中的头阻塞问题，提高了并发性能和效率。
  -

• 可靠传输：QUIC在应用层实现了可靠性，而不依赖于底层网络协议。它使用自定义的错误纠正和拥塞控制机制，以处理丢包、重排和抖动等问题，从而提供可靠的数据传输。

• 低延迟：QUIC通过减少握手延迟和头阻塞，以及支持0-RTT连接建立，降低了连接和数据传输的延迟。这对于实时通信、流媒体和互动应用非常有益。

• 安全性：QUIC要求使用SSL/TLS进行加密和身份验证，在加密的QUIC连接上传输数据，提供更强的安全性和隐私保护。

• 拥塞控制：QUIC使用自己的拥塞控制算法，以避免TCP的传统拥塞控制问题。它通过动态调整发送速率和接收方的窗口大小，以实现更高的吞吐量和更好的网络利用率。

• 移动网络友好：由于QUIC被设计用于不稳定和高延迟的网络环境，它在移动网络（如4G、5G）下表现良好。它具有故意设计的轻量级握手和快速连接恢复，以适应移动网络的特点。

HTTP3.0:

• HTTP3.0是使用QUIC作为传输协议的下一代HTTP协议。它使用QUIC的连接特性和可靠性，并在其之上构建HTTP应用层协议。
• HTTP3.0保留了HTTP/2中的大部分功能和语义，但使用QUIC作为传输层，提供更好的性能和可靠性。
• HTTP3.0使用加密的QUIC连接，要求使用SSL/TLS进行加密和身份验证，从而提高安全性。
• HTTP3.0支持多路复用和并行请求，允许在单个连接上同时传输多个请求和响应，提高了效率和性能。

总结起来，QUIC是一种新的传输协议，而HTTP3.0是在QUIC上构建的下一代HTTP协议。QUIC通过提供更高的性能和可靠性来改进传输层，而HTTP3.0则在此基础上使用新的传输协议，以提供更好的Web应用性能和安全性。

Web安全攻击概述

Web应用的概念：

• Web应用是由动态脚本、编译过的代码等组合而成
• 它通常架设在Web服务器上，用户在Web浏览器上发送请求
• 这些请求使用HTTP协议，由Web应用和企业后台的数据库及其他动态内容通信

Web应用的三层架构：：
典型的Web应用通常是标准的三层架构模型：

产生问题大部分会发生在哪里？
大多在Web层以及业务逻辑层的中间。因为Web层是用来发起HTTP协议的，一旦我们的Web安全出现了漏洞，那就会在发起HTTP请求的过程中，导致某些参数和内容发生错乱，这就是Web安全的由来

WASC的定义：

• Web Application Security Consortium
• 是一个由安全专家、行业顾问和诸多组织的代表组成的国际团体
• 负责为WWW制定被广泛接受的应用安全标准

WASC将Web应用安全威胁分为哪六类：
a.Authentication(验证)：用来确认某用户、服务或是应用身份的攻击手段

b.Authorization(授权)：用来决定是否某用户、服务或是应用具有执行请求动作必要权限的攻击手段

c.Client-Side Attacks(客户侧攻击)：用来扰乱或是探测Web站点用户的攻击手段

d.Command Execution(命令执行)：在Web站点上执行远程命令的攻击手段

e.Information Disclosure(信息泄露)：用来获取Web站点具体系统信息的攻击手段

f.Logical Attacks(逻辑性攻击)：用来扰乱或是探测Web应用逻辑流程的攻击手段

OWASP的定义：
Open Web Application Security Project

该组织致力于发现和解决不安全Web应用的根本原因

它们最重要的项目之一就是“Web应用的十大安全隐患”

从OWASP谈漏洞分类：

验证机制安全

验证机制概述：
1.验证机制是web应用程序中最简单的一种安全机制

    一般来说，应用程序必须核实用户提交的用户名和密码是否正确。正确则允许登录，反之不允许登录

2.验证机制是应用程序防御恶意攻击的核心机制

   它处在安全防御的最前沿，如果被用户轻易突破，通常应用程序的全部功能、数据都会被其控制

   缺乏安全有效的验证机制，其他核心安全机制都无法实施（会话管理和访问控制）

典型的身份验证模式化讨论：

验证技术：

1. 基于HTML表单的验证
2. 多元机制，如组合型密码
3. 客户端ssl证书

SQL注入

##SQL注入防御

XSS攻击

XSS（Cross-Site Scripting）攻击是一种常见的安全漏洞，它利用了网站对用户输入数据的不足验证，攻击者可以在页面中插入恶意脚本，使用户在浏览网站时执行该脚本，获取用户的个人信息和敏感数据。XSS 攻击的形式有很多，包括反射型 XSS 攻击、存储型 XSS 攻击和 DOM 型 XSS 攻击等。

当遭受 XSS 攻击时，攻击者可以利用以下方法进行各种恶意行为：

1. 窃取用户信息：攻击者可以通过注入恶意脚本来获取用户的登录凭证、cookie 信息、个人资料等敏感信息。
2. 伪造用户操作：攻击者可以通过修改网页内容或注入恶意链接来模拟用户操作，从而进行各种欺骗和钓鱼行为。
3. 恶意重定向：攻击者可以将用户重定向到一个恶意网站，使其暴露于更大的安全风险中。
4. 恶意操纵页面：攻击者可以通过修改网页内容来破坏网站的完整性，比如篡改页面布局、插入广告或恶意链接等。

为了预防 XSS 攻击，以下是一些常用的防御措施：

1. 输入验证和过滤：对用户输入的数据进行合理的验证和过滤，确保只接受所期望的类型和格式。
2. 输出编码：在将用户输入数据输出到页面时，使用适当的编码方式进行转义，如 HTML 编码、URL 编码、JavaScript 编码等。
3. Content Security Policy（CSP）：通过自定义策略限制页面可以加载和执行的资源，防止恶意脚本的注入。
4. HttpOnly Cookie：确保将敏感信息存储在 HttpOnly 标志的 cookie 中，使其无法被恶意脚本访问。
5. 最小权限原则：为网站和应用程序设置最小化的权限，避免攻击者利用 XSS 漏洞获得敏感操作的权限。

综上所述，防御 XSS 攻击需要开发人员和用户共同努力，通过合理的编码和安全实践来保护网站和用户的安全。

CSRF攻击

CSRF（Cross-Site Request Forgery）攻击是一种常见的网络安全漏洞，它利用了网站对用户身份验证的不充分保护。攻击者通过欺骗用户在已登录的网站上执行特定的恶意操作，从而在用户不知情的情况下发送伪造的请求。

攻击者通常利用以下方式进行 CSRF 攻击：

1. 伪装图片：攻击者可以在恶意网站上嵌入一个具有恶意请求的图片，并欺骗用户访问该网站，以触发恶意请求。
2. 自动提交表单：攻击者可以在恶意网站上编写带有恶意请求的表单，并使用各种手段（例如隐藏的 iframe、自动提交等）让用户无意中提交表单。
3. 链接引诱：攻击者可以通过发送带有恶意请求的欺骗性链接给用户，当用户点击该链接时，就会在已登录的网站上执行该请求。

以下是一些防御 CSRF 攻击的措施：

1. 随机令牌：在每个表单或请求中包含一个随机生成的令牌，该令牌与用户会话相关联。当服务器接收到请求时，验证令牌的有效性，如果不匹配，则拒绝该请求。
2. SameSite Cookie 属性：将 Cookie 的 SameSite 属性设置为 Strict 或 Lax，以限制 Cookie 的跨站行为，减少 CSRF 攻击的潜在风险。
3. 验证来源请求头：服务器可以验证请求中的 Referer 头部信息，确保请求来自与之相关的网站，如果来源不可信，则拒绝请求。
4. 双重确认：对于敏感操作，可以要求用户在执行前进行额外的确认，例如输入密码、进行二次验证等。

总结来说，防御 CSRF 攻击需要采取多种措施，包括使用随机令牌、限制 Cookie 的跨站行为、验证来源请求头以及进行双重确认等。同时，开发人员和用户都应理解 CSRF 攻击的原理和防御方法，保障网站和用户的安全。