【前言】以下源于慕课网《大话HTTP协议》课程笔记

认识HTTP协议

HTTP 基础

通过TCP/IP看HTTP

TCP/IP 协议

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

2、TCP/IP协议其实是一系列与互联网相关联的协议集合起来的总称。

3、分层管理是TCP/IP协议的重要特征。TCP/IP协议是由一个四层协议组成的系统，分别是：应用层、传输层、网络层、数据链路层。

TCP/IP协议

应用层：应用层一般是我们编写的应用程序，决定了向用户提供的应用服务。应用层协议有 FTP、DNS、HTTP等。

传输层：传输层 向 应用层 提供在网络中数传输的数据。传输层中由两个相知不用的协议：TCP和UDP。

网络层：网络层处理在网络上流动的数据包，数据包是网络传输的最小数据单位。该层规定了通过怎样的路径到达对方计算机，并把数据包传递给对方。

链路层：链路层用来处理连接网络的硬件部分。包括控制操作系统、硬件设备驱动、NIC网卡、网络适配器、光纤等物理可见部分。

数据包的封装和传输过程

上层协议的数据，是怎么转变成为下层协议数据的？这就是通过”封装“来实现的。

数据包的封装过程：
应用程序的数据在发布到网络层之前，数据会沿着TCP/IP协议栈，从上往下进行传递，而每层协议都会在上层协议的基础之上加上自己的头部信息（在数据链路层还会加上尾部信息），以此实现所有层的数据封装，为到达网络提供所有的必要信息。

数据包的封装过程

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

TCP/IP协议数据流

TCP的三次握手和四次挥手

前言：

在客户端和web服务器端在发送一个http请求的发送和返回的过程当中，需要创建一个 【TCP connection】。因为 HTTP 是没有 【链接】的概念的，它只有【请求】和【响应】的概念，而请求和响应都是数据包，它们之间是需要经过一个传输的通道，那么这个通道就是TCP 发起的从客户端到服务器端的一个链接。http请求是在这个链接的基础上去发送的 。
在TCP连接上，我们可以发送多个http请求吗？在不同的版本上情况不同：
在 HTTP1.0，一个HTTP请求就创建一个TCP连接，请求完成后，连接就断开；
在 HTTP1.1，可设置TCP连接不断开
在 HTTP2，在TCP连接上的http请求是可以并发的

为什么要进行三次握手？

防止服务款开启无用的连接。
因为网络传输是有延时的，中间可能隔着非常远的距离，需要通过光纤和中间的各种代理服务器来进行传输。
在传输的过程中，如果客户端发起“SYN=1,Seq=X”创建连接的请求，服务器端就直接创建连接，然后返回内容给客户端，如果这个数据因为网络原因丢失了，那么客户端就一直没有接收到服务器返回的内容，直到客户端请求超时然后自动关闭连接，又发起一个新的创建连接的请求。
如果没有三次握手在，对服务器端来说，就不能确认客户端是否有接收到我返回的信息，并且是没有给我确认是需要去创建 还是 关闭 这个请求。并且端口会一直开着来等客户端发送请求。这样服务端的开销就浪费了，它不知道客户端的请求已经失败了并且去创建新的连接去了。
所以，三次握手能帮我们确认这个连接过程，让客户端和服务器端能够及时的察觉到说可能因为网络原因的一些问题导致数据客户端关闭了请求服务器端却一直在等待请求的情况，规避网络传输延时导致的一些服务器开销的问题。

三次握手

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

第一次握手：建立连接。客户端发送连接请求报文段，将SYN位置为1，Sequence Number为随机值x；然后，客户端进入SYN_SEND状态，等待服务器的确认；

第二次握手：服务器收到客户端的SYN报文段，需要对这个SYN报文段进行确认，设置Acknowledgment Number为x+1(即收到的Sequence Number+1)；同时，自己还要发送SYN请求信息，将SYN位置为1，Sequence Number为随机值y；服务器端将上述所有信息放到一个报文段（即SYN+ACK报文段）中，一并发送给客户端，此时服务器进入SYN_RECV状态；

第三次握手：客户端收到服务器的SYN+ACK报文段。然后将Acknowledgment Number设置为y+1，向服务器发送ACK报文段，这个报文段发送完毕以后，客户端和服务器端都进入ESTABLISHED状态，完成TCP三次握手。

完成了三次握手，客户端和服务器端就可以开始传送数据。以上就是TCP三次握手的总体介绍。通信结束客户端和服务端就断开连接，需要经过四次分手确认。

第一次挥手：主机1（可以使客户端，也可以是服务器端），设置Sequence Number和Acknowledgment Number，向主机2发送一个FIN报文段；此时，主机1进入FIN_WAIT_1状态；这表示主机1没有数据要发送给主机2了（断开连接示意）；

第二次挥手：主机2收到了主机1发送的FIN报文段，向主机1回一个ACK报文段，Acknowledgment Number为Sequence Number加1；告诉主机1，我“收到”你的关闭请求了；主机1进入FIN_WAIT_2状态；

第三次挥手：主机2处理好自己事务可以关闭连接后，向主机1发送FIN报文段；告诉主机1，我“可以”关闭请求了；同时主机2进入LAST_ACK状态；

第四次挥手：主机1收到主机2发送的FIN报文段，向主机2发送ACK报文段，然后主机1进入TIME_WAIT状态；主机2收到主机1的ACK报文段以后，就关闭连接；此时，主机1等待2MSL后依然没有收到回复，则证明Server端已正常关闭，那好，主机1也可以关闭连接了。

可以看到一次tcp请求的建立及关闭至少进行7次通信，这还不包过数据的通信，而UDP不需3次握手和4次分手。

下图为抓取的HTTP请求创建TCP连接三次握手数据包的详细过程：

附 关于TCP的一些问题

1．TCP服务器最大并发连接数是多少？

关于TCP服务器最大并发连接数有一种误解就是“因为端口号上限为65535,所以TCP服务器理论上的可承载的最大并发连接数也是65535”。首先需要理解一条TCP连接的组成部分：客户端IP、客户端端口、服务端IP、服务端端口。所以对于TCP服务端进程来说，他可以同时连接的客户端数量并不受限于可用端口号，理论上一个服务器的一个端口能建立的连接数是全球的IP数 x 每台机器的端口数。实际并发连接数受限于linux可打开文件数，这个数是可以配置的，可以非常大，所以实际上受限于系统性能。

附 TCP和UDP

TCP 的全称是Transmission Control Protocol ，传输控制协议。它能够帮助你确定计算机连接到 Internet 以及它们之间的数据传输。通过三次握手来建立 TCP 连接，三次握手就是用来启动和确认 TCP 连接的过程。一旦连接建立后，就可以发送数据了，当数据传输完成后，会通过关闭虚拟电路来断开连接。

TCP 的主要特点有:

• TCP 能够确保连接的建立和数据包的发送
• TCP 支持错误重传机制
• TCP 支持拥塞控制，能够在网络拥堵的情况下延迟发送
• TCP 能够提供错误校验和，甄别有害的数据包。

关于传输层TCP、UDP协议可能我们平时遇见的会比较多，有人说TCP是安全的，UDP是不安全的，UDP传输比TCP快，那为什么呢，我们先从TCP的连接建立的过程开始分析，然后解释UDP和TCP的区别。

1、TCP是面向链接的，虽然说网络的不安全不稳定特性决定了多少次握手都不能保证连接的可靠性，但TCP的三次握手在最低限度上(实际上也很大程度上保证了)保证了连接的可靠性;而UDP不是面向连接的，UDP传送数据前并不与对方建立连接，对接收到的数据也不发送确认信号，发送端不知道数据是否会正确接收，当然也不用重发，所以说UDP是无连接的、不可靠的一种数据传输协议。

2、也正由于1所说的特点，使得UDP的开销更小数据传输速率更高，因为不必进行收发数据的确认，所以UDP的实时性更好。知道了TCP和UDP的区别，就不难理解为何采用TCP传输协议的MSN比采用UDP的QQ传输文件慢了，但并不能说QQ的通信是不安全的，因为程序员可以手动对UDP的数据收发进行验证，比如发送方对每个数据包进行编号然后由接收方进行验证啊什么的，即使是这样，UDP因为在底层协议的封装上没有采用类似TCP的“三次握手”而实现了TCP所无法达到的传输效率。

URI 、URL 和 URN

URI （Uniform Resource Identifier ）统一资源标识符
URL （Uniform Resource Locator） 统一资源定位符
URN（Uniform Resource Name ）统一资源名称

• URI可以分为URL和URN两部分，URN确定了东西的身份，URL提供了找到它的方式。

• URL用地址定位，URN 用名称定位。

• 格式：<协议>：//<主机>：<端口>/<路径> （注：端口和路径有时可以省略，HTTP默认端口号是80）
  如：https://localhost:8080/index.html?key1=value1&keys2=value2、http://www.magedu.com/downloads/nginx-1.5.tar.gz

DNS域名解析

DNS（Domain Name System，域名系统），因特网上作为域名和IP地址相互映射的一个 分布式数据库，能够使用户更方便的访问互联网，而不用去记住能够被机器直接读取的IP数串。通过主机名，最终得到该主机名对应的IP地址的过程叫做域名解析（或主机名解析）。

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

你是如何访问慕课的？

访问慕课与DNS域名解析

浏览器输入域名https://www.imooc.com，首先浏览器会解析 www.imooc.com 这个域名（准确的叫法应该是主机名）对应的IP地址，通过这个IP地址才能真正的访问到慕课网的web服务器。怎么解析到对应的IP地址？

1、浏览器首先搜索浏览器自身的DNS缓存（缓存时间比较短，大概只有1分钟，且只能容纳1000条缓存），看自身的缓存中是否有 www.imooc.com 对应的条目，而且没有过期，如果有且没有过期则解析到此结束。
注：
① 怎么查看Chrome自身的缓存？可以使用 chrome://net-internals/#dns 来进行查看
② 浏览器在访问一个页面的时，我们就要从URL中分解出协议名、主机名、端口、对象路径等。如从” https://www.imooc.com“ 分解出：协议为HTTP协议、主机名为www.imooc.com、端口默认为80端口、对象路径为跟节点/

2、如果浏览器自身的缓存里面没有找到对应的条目，那么Chrome会搜索操作系统自身的DNS缓存,如果找到且没有过期则停止搜索解析到此结束.
注：怎么查看操作系统自身的DNS缓存，以Windows系统为例，可以在命令行下使用 ipconfig/displaydns 来进行查看。每种操作系统都有自己的DNS缓存时间控制，Windows DNS默认值是 MaxCacheTTL，它的默认值是86400s，也就是一天

3、如果在Windows系统的DNS缓存也没有找到，那么尝试读取，看看这里面有没有该域名对应的IP地址，如果有则解析成功。
注：hosts文件位于 C:\Windows\System32\drivers\etc

4、如果在hosts文件中也没有找到对应的条目，浏览器就会发起一个DNS的系统调用：
1） 如果在本地的 hosts 文件没有能够找到对应的 ip 地址，浏览器会发出一个 DNS请求到本地DNS服务器 。
注：
① 本地DNS服务器一般都是你的网络接入服务器商提供，比如中国电信，中国移动。
② 浏览器发起的域名解析请求，通过的是UDP协议向DNS的53端口发起的

2）本地DNS服务器会首先查询它的缓存记录，如果缓存中有此条记录，就可以直接返回结果，此过程是递归的方式进行查询。如果没有，本地DNS服务器还要向DNS根服务器进行查询。
注：先是找根DNS服务器的IP地址（这个DNS服务器都内置13台根域的DNS的IP地址），找打根域的DNS地址，就会向其发起请求

3）根DNS服务器没有记录具体的域名和IP地址的对应关系，而是告诉本地DNS服务器，你可以到域服务器上去继续查询，并给出域服务器的地址。这种过程是迭代的过程。

4）本地DNS服务器继续向域服务器发出请求，在这个例子中，请求的对象是.com域服务器。.com域服务器收到请求之后，也不会直接返回域名和IP地址的对应关系，而是告诉本地DNS服务器，你的域名的解析服务器的地址。

5）最后，本地DNS服务器向域名的解析服务器发出请求，这时就能收到一个域名和IP地址对应关系，本地DNS服务器不仅要把IP地址返回给用户电脑，还要把这个对应关系保存在缓存中，以备下次别的用户查询时，可以直接返回结果，加快网络访问。

知识扩展：

1)hosts文件

host文件：我们本地电脑会把一些我们常用的域名和对应的IP地址建立一个映射关系，并且保存到系统文件里，这个文件就是host文件。

2)DNS查询的两种方式

当局部DNS服务器自己不能回答客户机的DNS查询时，它就需要向其他DNS服务器进行查询。此时有两种方式：递归查询和迭代查询
1、递归解析
局部DNS服务器自己负责向其他DNS服务器进行查询，一般是先向该域名的根域服务器查询，再由根域名服务器一级级向下查询。最后得到的查询结果返回给局部DNS服务器，再由局部DNS服务器返回给客户端。

2、迭代查询
当局部DNS服务器自己不能回答客户机的DNS查询时，局部DNS服务器不是自己向其他DNS服务器进行查询，而是把能解析该域名的其他DNS服务器的IP地址返回给客户端DNS程序，客户端DNS程序再继续向这些DNS服务器进行查询，直到得到查询结果为止。
也就是说，迭代解析只是帮你找到相关的服务器而已，而不会帮你去查。

3)DNS负载均衡

当一个网站有足够多的用户的时候，假如每次请求的资源都位于同一台机器上面，那么这台机器随时可能会蹦掉。处理办法就是用DNS负载均衡技术，它的原理是在DNS服务器中为同一个主机名配置多个IP地址,在应答DNS查询时,DNS服务器对每个查询将以DNS文件中主机记录的IP地址按顺序返回不同的解析结果,将客户端的访问引导到不同的机器上去,使得不同的客户端访问不同的服务器,从而达到负载均衡的目的｡例如可以根据每台机器的负载量，该机器离用户地理位置的距离等等。

HTTP事务处理

当客户端访问Web站点时，首先会通过DNS服务查询到域名的IP地址。让后浏览器发起HTTP请求，通过TCP/IP协议三次握手建立TCP连接，再把消息发送到Web服务器。Web服务器接收到请求后会根据请求生成响应内容，再通过TCP/IP协议返回给客户端。

HTTP事务处理过程

当我们在浏览器的地址栏输入 www.linux178.com ，然后回车，回车这一瞬间到看到页面到底发生了什么呢？

简要概况为：域名解析 --> 发起TCP的3次握手 --> 建立TCP连接后发起http请求 --> 服务器响应http请求，浏览器得到html代码 --> 浏览器解析html代码，并请求html代码中的资源（如js、css、图片等） --> 浏览器对页面进行渲染呈现给用户

1、DNS将域名解析出对应IP。

浏览器自身的DNS缓存 - 系统自身的DNS缓存 - 系统hosts文件 - 本地DNS服务器（递归） - 根服务器（无缓存，告域服务器地址，迭代） - 域服务（无缓存，告知域名的解析服务器的地址）- 域名的解析服务器 - 查找到域名对应ip，本地DNS服务器返回ip地址给浏览器且保存该条目到缓存中

2、建立TCP连接。

拿到域名对应的IP地址之后，User-Agent（一般是指浏览器）会以一个随机端口（1024 < 端口 < 65535）向服务器的WEB程序（常用的有httpd,nginx等）80端口发起TCP的连接请求。这个连接请求（原始的http请求经过TCP/IP4层模型的层层封包）到达服务器端后（这中间通过各种路由设备，局域网内除外），进入到网卡，然后是进入到内核的TCP/IP协议栈（用于识别该连接请求，解封包，一层一层的剥开），还有可能要经过Netfilter防火墙（属于内核的模块）的过滤，最终到达WEB程序（本文就以Nginx为例），最终建立了TCP/IP的连接

问：
1）TCP 为什么需要3次握手？

2）为什么建立连接是三次握手，而关闭连接却是四次挥手呢？

3）为什么HTTP协议要基于TCP来实现？
目前在Internet中所有的传输都是通过TCP/IP进行的，HTTP协议作为TCP/IP模型中应用层的协议也不例外，TCP是一个端到端的可靠的面向连接的协议，所以HTTP基于传输层TCP协议不用担心数据的传输的各种问题。

因为HTTP在最上层的应用层，再往下的才是传输层。所以再把这个数据包封装成TCP包，建立TCP连接（三次握手）。

HTTP是基于传输层的TCP协议，而TCP是一个端到端的面向连接的协议。所谓的端到端可以理解为进程到进程之间的通信。所以HTTP在开始传输之前，首先需要建立TCP连接，而TCP连接的过程需要所谓的“三次握手”。

在HTTP开始工作之前，客户端需要通过网络与服务器进行连接，这个连接就是TCP来完成的。TCP协议与IP协议共同构建了我们的互联网，也就是TCP/IP协议族，所以互联网也被称作TCP/IP。HTTP因为是比TCP/IP更高层次，所以只有底层协议建立之后才能进行更高层次的协议。

3、发送http请求。

进过TCP3次握手之后，浏览器发起了http的请求。

请求的数据格式为HTTP请求报文格式。

4、服务器接到http请求后，给予相应的响应信息。

服务器端WEB程序接收到http请求以后，就开始处理该请求，处理之后就返回给浏览器html文件。

响应的格式为HTTP响应报文格式。

5. 浏览器解析html代码，并请求html代码中的资源

浏览器拿到index.html文件后，就开始解析其中的html代码，遇到js/css/image等静态资源时，就向服务器端去请求下载（会使用多线程下载，每个浏览器的线程数不一样），这个时候就用上keep-alive特性了，建立一次HTTP连接，可以请求多个资源，下载资源的顺序就是按照代码里的顺序，但是由于每个资源大小不一样，而浏览器又多线程请求请求资源，所以从下图看出，这里显示的顺序并不一定是代码里面的顺序。

浏览器在请求静态资源时（在未过期的情况下），向服务器端发起一个http请求（询问自从上一次修改时间到现在有没有对资源进行修改），如果服务器端返回304状态码（告诉浏览器服务器端没有修改），那么浏览器会直接读取本地的该资源的缓存文件。

6.浏览器对页面进行渲染呈现给用户

最后，浏览器利用自己内部的工作机制，把请求到的静态资源和html代码进行渲染，渲染之后呈现给用户。

7、释放TCP连接（四次挥手）。

客户端接收服务器所返回的信息通过浏览器显示在用户的显示屏上，然后客户机与服务器断开连接。

如果在以上过程中的某一步出现错误，那么产生错误的信息将返回到客户端，有显示屏输出。对于用户来说，这些过程是由HTTP自己完成的，用户只要用鼠标点击，等待信息显示就可以了。

HTTP无状态协议

HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。

无状态协议：

协议的状态是指下一次传输可以“记住”这次传输信息的能力。

为了保证服务器内存，http是不会为了下一次连接而维护这次连接所传输的信息。

比如客户获得一张网页之后关闭浏览器，然后再一次启动浏览器，再登陆该网站，但是服务器并不知道客户关闭了一次浏览器。

HTTP”无状态“ 和 ”无连接“ 的区别：

无状态指：协议对于事务处理没有记忆能力，服务器不知道客户端是什么状态。从另一方面讲，打开一个服务器上的网页和你之前打开这个服务器上的网页之间没有任何联系。

无连接指：每次HTTP请求都需要建立一次TCP连接，请求完成后连接就断开。

两者并没有什么联系，无状态不代表HTTP不能保持TCP连接，更不能代表HTTP使用的是UDP协议（无连接）。

对HTTP的无状态特征该怎么解决：

既然HTTP是无状态的，那为何当我们输入用户名密码登陆一个网站后，关闭浏览器，下次再打开页面时登录状态还在？

我们可以通过一些策略/方法，让浏览器拥有”记忆“能力：

1. 通过Cookie & Session 保持状态

2. JWT 机制
   还有一种方式是使用 JWT 机制，它也是能够让你的浏览器具有记忆能力的一种机制。与 Cookie 不同，JWT 是保存在客户端的信息，它广泛的应用于单点登录的情况。JWT 具有两个特点：
   1）JWT 的 Cookie 信息存储在客户端，而不是服务端内存中。也就是说，JWT 直接本地进行验证就可以，验证完毕后，这个 Token 就会在 Session 中随请求一起发送到服务器，通过这种方式，可以节省服务器资源，并且 token 可以进行多次验证。
   2）JWT 支持跨域认证，Cookies 只能用在单个节点的域或者它的子域中有效。如果它们尝试通过第三个节点访问，就会被禁止。使用 JWT 可以解决这个问题，使用 JWT 能够通过多个节点进行用户认证，也就是我们常说的跨域认证。

Cookie & Session

Cookie

Cookie就是一小段文本信息。当客户端请求服务器，如果服务器需要记录改用户状态，就向客户端浏览器颁发一个Cookie。浏览器把Cookie保存起来，当浏览器再次请求改网站时带上该Cookie，以供服务器辨认用户状态。

如果你的浏览器允许 cookie 的话，查看方式 chrome://settings/content/cookies

Session

Session机制是一种服务器端的机制，服务器使用一种类似于散列表的结构来保存信息。

当你向服务端发送请求时，服务端会给你发送一个认证信息，服务器第一次接收到请求时，开辟了一块 Session 空间（创建了Session对象），同时生成一个 sessionId ，并通过响应头的 Set-Cookie：JSESSIONID=XXXXXXX 命令，向客户端发送要求设置 Cookie 的响应；客户端收到响应后，在本机客户端设置了一个 JSESSIONID=XXXXXXX 的 Cookie 信息，该 Cookie 的过期时间为浏览器会话结束；
接下来客户端每次向同一个网站发送请求时，请求头都会带上该 Cookie信息（包含 sessionId ）， 然后，服务器通过读取请求头中的 Cookie 信息，获取名称为 JSESSIONID 的值，得到此次请求的 sessionId。这样，你的浏览器才具有了记忆能力。

保持 Session ID 的方式：

1、使用Cookie来实现
服务器给每个Session分配一个唯一的JSESSIONID，并通过Cookie发送给客户端。
当客户端发起新的请求的时候，将在Cookie头中携带这个JSESSIONID。这样服务器能够找到这个客户端对应的Session。

Cookie在浏览器中是可以手动禁用的，用户选择禁用Cookie后， Session ID 的机制还有其他实现方法吗？

2、使用URL回写来实现
URL回写是指服务器在发送给浏览器页面的所有链接中都携带JSESSIONID的参数，这样客户端点击任何一个链接都会把JSESSIONID带会服务器。
以路径附加信息形式：http://xxx;Sessionid=xxx
以查询参数的形式：http://xxx?Sessionid=xxx

3、隐藏表单方式实现
这个原理和Cookies大同小异，只是每次请求和响应所附带的信息变成了表单变量。

HTTP长连接和短连接

HTTP长连接和短连接的原理与本质

HTTP协议是基于请求/响应模式的，只要客户端得到服务器端的响应，客户端就关闭连接，本次HTTP请求就结束了。“HTTP中长连接和短连接”本质上指的是TCP的连接。

例如当打开imooc.com 时，需要加载很多css、js、图片，静态网页等，如果使用的是短链接，每个资源的请求都要建立一个TCP连接，而使用长连接时，这些请求都可以在一个TCP连接上完成，就可以节省很多消耗。

短连接：
建立连接 —— 数据传输 —— 关闭连接...建立连接 —— 数据传输 —— 关闭连接
长连接：
建立连接 —— 数据传输...（保持连接）...数据传输 —— 关闭连接

HTTP/1.0中，默认使用的时短连接。也就是说，浏览器和服务器每进行一次HTTP操作，就建立一次连接，请求完成就断开连接。
HTTP/1.1起，默认使用长连接，用以保持连接性（可在 Response Headers 中 的 Connection: keep-alive 设置）。

短连接对于服务器来说，管理较为简单，存在的连接都是有用的连接，不需要额外的控制手段。但如果客户请求频繁，将在TCP建立和关闭的操作上浪费时间和带宽，那么客户端上响应速度就会变慢，降低了用户体验。对于这种需要频繁请求资源的场景，就比较适合使用长连接模式了。

client 和 server 端都可以发起关闭连接请求，不过在短连接上，关闭连接请求一般由 client 发出，长连接上则一般由 server 发起。长连接模式下，client 和 server 的连接如果一直不关闭的话，随着客户端连接的越来越多，会给 server 造成一定的负担和压力，所以 server 需要有些策略，例如关闭一些长时间没有读写操作的连接、限制客户端的最大连接数等等，避免一些恶意连接导致 server 端服务受损。

所以长连接和短连接的产生，其实是 server 和client采取的关闭策略，根据不同的应用场景而采用不用的策略。

当前在HTTP1.1 下，使用长连接更更更为广泛。

HTTP长连接和短连接的设置 Connection

Connection：请求头，决定当前事务（一次三次握手和四次挥手）完成后是否会关闭网络连接。属性值有两种，持久性连接 和 非持久性连接。

• keep-alive：
  当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，如果客户端再次访问这个服务器上的网页，，或者请求这个页面上的其他资源，会继续使用这一条已经建立的连接。
  HTTP1.1 默认进行持久连接。
  默认keep-alive的时间是两个小时，超过这个时间后会自动回收，就是希望尽可能的节约资源并且又不会造成浪费。当然，服务端可以修改这个保活时间。
• close:
  代表一个Request完成后，客户端和服务器之间用于传输HTTP数据的TCP连接会关闭，当客户端再次发送Request，需要重新建立TCP连接。

HTTP缓存

WEB缓存(cache)位于Web服务器和客户端之间。

缓存会根据请求保存输出内容的副本，例如html页面，图片，文件，当下一个请求来到的时候：如果是相同的URL，缓存直接使用副本响应访问请求，而不是向源服务器再次发送请求。
（注意：缓存的是 css、JavaScript脚本、图片 等更新频率不大的静态资源文件，而不是某个http请求的响应。
）

HTTP 协议定义了相关的消息头来使WEB缓存尽可能好的工作。

为什么要用HTTP缓存

减少相应延迟 / 减缓端压力 / 客户端渲染优化：因为请求从缓存服务器（离客户端更近）而不是源服务器被响应，这个过程耗时更少，让web服务器看上去相应更快。

减少网络带宽消耗：当副本被重用时会减低客户端的带宽消耗；客户可以节省带宽费用，控制带宽的需求的增长并更易于管理。

Web 缓存机制

HTTP/1.1中缓存的目的是为了在很多情况下减少发送请求，同时在许多情况下可以不需要发送完整响应。前者减少了网络回路的数量，HTTP利用一个“过期（expiration）”机制来为此目的；后者减少了网络应用的带宽，HTTP用“验证（validation）”机制来为此目的。

HTTP定义了3种缓存机制：

• Freshness：允许一个回应消息可以在源服务器不被重新检查，并且可以由服务器和客户端来控制。例如，Expires回应头给了一个文档不可用的时间。Cache-Control中的max-age标识指明了缓存的最长时间；

• Validation：用来检查以一个缓存的回应是否仍然可用。例如，如果一个回应有一个Last-Modified回应头，缓存能够使用If-Modified-Since来判断是否已改变，以便判断根据情况发送请求；

• Invalidation：在另一个请求通过缓存的时候，常常有一个副作用。例如，如果一个URL关联到一个缓存回应，但是其后跟着POST、PUT和DELETE的请求的话，缓存就会过期。

HTTP缓存的设置

Cache-Control

Cache-Control：请求/响应头，通用标头，缓存控制字段。
可设置的值有：

• no-store：所有内容都不缓存。
• no-cache：缓存，但是浏览器使用缓存前，都会请求服务器判断缓存资源是否是最新。
• max-age=x(单位秒)：请求缓存后的X秒不再发起请求。
• s-maxage=x(单位秒)：代理服务器请求源站缓存后的X秒不再发起请求，只对CDN缓存起效。
• public：客户端和代理服务器（CDN）都可缓存。
• private：只有客户端可以缓存。

Expires

Expires：响应头，代表资源过期时间，由服务器返回提供；是 http1.0的属性；

在与http1.1的 Cache-Control:max-age 共存的情况下，优先级较低。

Expires的缺点：

1. 如果缓存时间没过期，那么浏览器会被拦截，无法拿到最新的文件。HTTP1.1的客户端和缓存会将非法的日期格式（包括0）看作已经过期。所以如果像想浏览器不要缓存页面，也可以将Expires设置为0。
2. Expires指定一个绝对的过期时间(GMT格式),这么做会导致至少2个问题
   1）客户端和服务器时间不同步导致Expires的配置出现问题
   2）很容易在配置后忘记具体的过期时间
   max-age 指定的是从文档被访问后的存活时间，这个时间是个相对值(比如:3600s),相对的是文档第一次被请求时服务器记录的Request_time(请求时间)

If-Modified-Since 和 Last-Modified

If-Modified-Since：请求头，资源最新修改时间，由浏览器告知服务器。
Last-Modified：响应头，资源最新修改时间，由服务器告知浏览器。

image.png

If-Modified-Since 通常与 Last-Modified 搭配使用，通过文件最新修改时间的对比来确认是否使用缓存。
If-Modified-Since 把浏览器端缓存页面的最后修改时间发送到服务器去，服务器会把这个时间与服务器上实际文件的最后修改时间 Last-Modified 进行对比。如果时间一致，那么返回304，客户端就直接使用本地缓存文件。如果时间不一致，就会返回200和新的文件内容。客户端接到之后，会丢弃旧文件，把新文件缓存起来，并显示在浏览器中。

If-None-Match 和 Etag

If-None-Match：请求头，缓存资源标识，由浏览器告知服务器（其实就是上次服务器给的Etag）。
Etag：响应头，资源标识，由服务器告知浏览器。

If-None-Match 通常与 ETag一起工作。
工作原理是在HTTP Response中添加ETag信息。 当用户再次请求该资源时，将在HTTP Request 中加入If-None-Match信息(ETag的值)。如果服务器验证资源的ETag没有改变（该资源没有更新），将返回一个304状态告诉客户端使用本地缓存文件。否则将返回200状态和新的资源和Etag。使用这样的机制将提高网站的性能。

（当前常用方式。）

HTTP缓存的缺点和可改进方案

从上面可知HTTP缓存的设置有
1.客户端缓存时间的设置（Expires 或 Cache-Control:max-age ）；
2.服务器与浏览器的文件修改时间去做对比（If-Modified-Since 与 Last-Modified）；
3.文件标识对比（If-None-Match 与 ETag）
三者都有一个前提，就是需是在两者文件路径完全相同的情况下，否则就直接获取新的文件了。

除了HTTP自身的缓存，我们还可以有其他缓存方案：

1. md5/hash缓存
   通过不缓存html，为静态文件添加md5或hash标识，解决浏览器无法跳过缓存过期时间主动感知文化变化问题。
2. CDN缓存
   CDN是构建在网络之上的内容发布网络，依靠部署在各地的边缘服务器，通过中心平台的负载均衡、内容发布、调度等功能模块，使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率。

HTTP内容协商机制

指客户端和服务器端就响应的资源内容进行交涉，然后提供给客户端最为适合的资源。内容协商会以响应资源的语言，字符集，编码方式等作为判断的基准。
例如，开发了一个中文的网址，希望也能支持英文等其他语言，就是根据HTTP内容协商机制来做的。

内容协商的三种方式：

1. 客户端驱动
   客户端发起请求，服务器发送可选项列表，客户端作出选择后在发送第二次请求。
   缺点：需要发送两次请求
2. 服务器驱动
   服务器检查客户端的请求头部集并决定提供哪个版本的页面。
   缺点：当头部集都不匹配时，服务器要做猜测，所有一般服务器上都设置个默认值。
3. 透明协商
   某个中间设备（通常是缓存代理）代表客户端进行协商。
   缺点：不是标准的HTTP机制，没有相应的规范

当前使用最广的应当是，服务器驱动了，下面就来说说服务器驱动。

服务器驱动内容协商 - 请求首部集

• Accept ：告知服务器发送何种媒体类型 。
  例如 Accept: text/html 代表浏览器可以接受服务器回发的类型为 text/html 也就是我们常说的html文档，如果服务器无法返回text/html类型的数据，服务器应该返回一个406错误(non acceptable)。通配符 * 代表任意类型，如 Accept: */* 代表浏览器可以处理所有类型。

• Accept-Encoding ：告知服务器采用何种编码
  浏览器申明自己可接收的编码方法，通常指定压缩方法，是否支持压缩，支持什么压缩方法。
  常见的内容编码有这几种： gzip、compress、deflate、identity，可应用在请求报文和响应报文中。
  如Accept-Encoding: gzip, deflate

• Accept-Language ：告知服务器发送何种语言

• Accept-Charset ：告知服务器发送何种字符集

服务端会根据请求的这些设置进行匹配，并返回几个对应的实体回复：Content-Type、Content-Language、Content-Type、Content-Encoding。

服务器驱动内容协商 - 近似匹配q

HTTP 提供q机制，允许服务器近似匹配。q机制可在Accept、Accept-Language、Accept-Charset、Accept-Encoding中使用，以Accept-Encoding来举例：

Accept-Language: en;q=0.5, fr;q=0.0, nl;q=1.0, tr;q=0.0

译：客户端提出的是，用户最愿意接受的是nl(荷兰)语，其次是en(英)语，不愿接受fr(法)语或tr(土耳其)语。
q，权重，值的范围是0~1，表示偏好优先级；
当客户端提出了用户的语言偏好的时候，服务器端能根据该偏好做出相应的匹配。

HTTP的断点续传和多线程下载

当我们在下载一个大文件时，HTTP是如何实现断点续传或多线程分块下载的？

HTTP是通过在 Header 的两个参数实现的，客户端发送请求时对应的是 Range，服务器端响应时对应的是 Content-Range。
Range：
用于请求头中，指定第一个字节的位置和最后一个字节的位置。
例如：
Range: bytes=0-499 表示头500个字节
Range: bytes=500-999 表示第二个500字节
Range: bytes=-500 表示最后500个字节
Range: bytes=500- 表示500字节开始到文件结束
Range: bytes=500-600,601-999 同时指定几个范围

Content-Range：
用户响应头中，在发出带Range的请求后，服务器会在Content-Range 头部返回当前接受的范围和文件总大小。
而在响应的完成后，返回的响应头内容也不同：
不使用断点续传方式: HTTP/1.1 200 OK
使用断点续传方式: HTTP/1.1 206 Partial Content
如果续传成功（或者多线程分块下载成功）服务器返回206，如果文件有变动，服务器返回200和新文件的内容（之前说过HTTP状态吗206表示的是部分内容下载）。

断点续传过程

1.客户端下载一个 1024K 的文件，当下载了其中 512K时，网络因某些原因中断了（或用户主动暂停了下载）。
2.网络重连（或用户选择了继续下载）
3.客户端请求续传，因此需要在HTTP头中申明本次需要续传的片段： "Range: bytes = 512000-" ，这个头通知服务端从文件的 512K 位置开始传输文件。
4.服务端收到断点续传请求，从文件的 512K 位置开始传输，并且在HTTP头中增加： "Content-Range : bytes 512000-/1024000" ，512000-表示从文件的512000位置开始传输到文件结束，1024000表示文件的总大小。 此时服务端返回的HTTP状态码应该是 206 ，而不是 200。

多线程下载

多线程下载类似于断点续传，只不过断点续传是被动的增量下载，而多线程下载是主动的分片下载，同样都是使用Range模式。例如把100M的文件分为100个片来下载，那么第一个片的Range为0-1024000，第二个片的Range为1024001-2048000，以这样的模式不断向下叠加，主动的把他分成了100片。

HTTP与HTTPS

HTTP与HTTPS

HTTPS(Hypertext Transfer Protocol Secure) 从名称我们可以看出 HTTPS 要比 HTTPS 多了 secure 安全性这个概念。实际上， HTTPS 并不是一个新的应用层协议，它其实就是 HTTP + TLS/SSL 协议组合而成，而安全性的保证正是 TLS/SSL 所做的工作。

那么，HTTP 和 HTTPS 的主要区别是什么呢？

• 最简单的，HTTP 在地址栏上的协议是以 http:// 开头，而 HTTPS 在地址栏上的协议是以 https:// 开头；

• HTTP 的默认端口是 80，而 HTTPS 的默认端口是 443；

• HTTP 是未经安全加密的协议，它的传输过程容易被攻击者监听、数据容易被窃取、发送方和接收方容易被伪造；而 HTTPS 是安全的协议，它通过 密钥交换算法 - 签名算法 - 对称加密算法 - 摘要算法 能够解决上面这些问题。

TLS

TLS是传输加密协议，它的前身是SSL协议。

SSL(Secure Sockets Layer：安全套阶层)：对传输层数据进行加密后传输，保证数据的安全(不被泄露)和完整(不被篡改)。

TLS建立在应用层和传输层中间，在TCP之上建立了一个加密通道。TLS协议主要有5个部分：应用数据层协议、握手协议、报警协议、加密消息确认协议、心跳协议。

因为我们知道 HTTPS 不是一种新出现的协议，而是 HTTP + TLS/SSL。所以，我们探讨 HTTPS 的握手过程，其实就是 SSL/TLS 的握手过程。

TLS 旨在为 Internet 提供通信安全的加密协议。TLS 握手是启动和使用 TLS 加密的通信会话的过程。在 TLS 握手期间，Internet 中的通信双方会彼此交换信息，验证密码套件，交换会话密钥。

每当用户通过 HTTPS 导航到具体的网站并发送请求时，就会进行 TLS 握手。除此之外，每当其他任何通信使用HTTPS（包括 API 调用和在 HTTPS 上查询 DNS）时，也会发生 TLS 握手。TLS 具体的握手过程会根据所使用的密钥交换算法的类型和双方支持的密码套件而不同。

HTTPS功能介绍

HTTPS提供了三个功能，来对抗HTTP不安全、可能被劫持的缺陷。

• 内容加密：浏览器到服务器的数据，都是以加密形式来传输的，中间者无法直接查看原始内容。
  =》对称内容加密、非对称密钥交换
  • 对称内容加密：对称加密的第一步是需要协商加密算法的密钥，中间人依然可以在第一次通信的时候截获加密方式和密钥。
  • 非对称密钥交换：非对称交换，用公钥和私钥的方式，把正常通信的密钥key2协商好。但是在协商过程中，有一步是服务器把自己的公钥key1用明文传给客户端。此时中间人可以截获key1，换成自己的公钥key3，这样一来中间人就可以获取正常通信的密钥，通信仍然不安全
• 身份验证：由于证书的存在，保证了用户访问的是你想问的服务，若访问站点被劫持，会给用户相应提示。
  =》数字证书
  • 数字证书：服务端向权威机构申请证书（证书包含 证书机构、服务器网址、机构加密的私钥、私钥加密过的公钥、证书签名等等）。在客户端和服务器端通信时，服务器端先把证书传递为客户端，客户端收到证书后，用证书的公钥解密证书签名，然后用签名生成规则再生成一个签名来对比，一致的是真证书，反正为假证书。如果为真证书，就解密服务器公钥key1，再生成通信用的密钥key2，再用服务器端的公钥key1加密发给服务端。
    这个权威证书，也称为CA证书。CA证书就是可信的吗？厂商和浏览器、操作系统都是有合作的，它们的公钥都默认装在浏览器、操作系统的环境里。
• 数据完整性：防止传输的数据被第三方冒充或篡改。

HTTPS对性能的影响

1、协议交互所增加的网络RTT <=> 网络耗时

RTT：RTT表示从 “发送端” 发送数据开始，到 “发送端” 收到来自 “接收端” 的确认，这个过程中总共花费的时间

下面来比较下HTTP和HTTPS在网络访问和往返时延上的区别（以下忽略DNS的域名解析）：

HTTP

HTTP：只需完成TCP三次握手建立TCP连接，就能够发送HTTP请求，获取应用层数据。除此无需消耗其他的计算资源。

HTTPS：

HTTPS

第一步：三次握手往返，耗时一个RTT。

第二步：一般是由一个HTTP GET请求，服务端返回302跳转到https，这里耗时一个RTT。（通常用户访问网站时不会手动的去输入https，例如访问百度时，我们一般是直接在浏览器输入baidu.com，所有服务端只能返回302，让浏览器跳转到 https:www.baidu.com

第三步：服务器跳转到HTTPS之后，由于和服务器不一样，所有需要重新完成三次握手建立TCP连接，耗时一个RTT。

第四步：接下来是 TLS完全握手阶段1，耗时一个RTT。这个阶段主要是完成 加密套件的协商 和 证书的身份确认。

这个阶段里服务器和浏览器会协商出 密钥交换算法、对称加密算法、内容一致性加密算法、证书签名算法等等。

浏览器获取到证书后，需要校验证书的有效性：
1）CA站点的域名DNS解析，耗时一个RTT。
2）CA站点三次握手建立TCP连接，耗时一个RTT。
3）浏览器发送Ocsp(在线证书状态协议)请求，查询证书状态(有效？过期？未知)，耗时一个RTT。

第五步：最后是 TLS完全握手阶段2。这个阶段主要是密钥协商，耗时一个RTT。这个握手结束后浏览器和服务器就能就行应用层的数据传输了。

从以上可以看到，这些步骤最多会耗费7个RTT，当然不是每个请求都需要耗费7个RTT来完成HTTPS首次请求交互。例如如果CA站点域名解析，DNS有缓存的话都能在一定程度上减少RTT的消耗。

可以确定的是，HTTPS在网络上的消耗是略大于HTTP的。

以上是HTTPS在网络路径上必须消耗的存网络耗时，还不包括CUP资源的计算耗时，大概会在30毫秒以上，主要看设备性能而定。

2、加解密相关的计算耗时 <=> 计算耗时

计算耗时可以分外两个方面：
浏览器计算耗时：包括浏览器解析证书签名、各种密钥交换、应用层数据加解密等的耗时
服务器计算耗时：同样包括密钥交换、应用层数据加解密等的耗时

SSL安全通信握手

数字证书

SSL安全通信握手

• 综合使用对称加密、非对称加密
  在进行随机数交流的阶段，使用的是非对称加密来进行通信的，等双发都确定了随机数之后，就可以使用对称的加密了。
• 双发分别生成密钥，没有经过传输
  减少了密钥泄露的可能性。

ASE加密

ASE对称加密：
缺点：
“第一次约定加密方式”　和　“约定加密方式的密钥的通信”　仍然还是用明文，如果第一次通信时就已经被拦截，那么密钥就会泄露给中间人，中间人就可以解密后续所有的通信内容。
ASE非对称加密：　
明文可以用公钥加密，私钥解密。也可以用私钥加密，公钥解密。

基于 HTTP 的功能追加协议

HTTP协议的瓶颈

1）条连接上只可发送一个请求
2）请求只从客户端开始（解决方法：long poll 和 ajax轮询）
3）客户端不可以接受除响应以外的指令
4）请求／响应头部不经压缩就发送
5）每次互相发送相同的头部造成的浪费较多
6）非强制压缩发送

=》
1）单链路，请求低效
2）HTTP只允许由客户端主动发起请求
3）HTTP头部冗余

一、双工通信的WebScocket

WebSocket 是基于HTTP协议的，或者说，接用了HTTP协议来完成一部分握手。当HTTP升级为Websocket协议时，服务器端可以主动推送消息给客户端。

WebSocket 请求

WebSocket 响应

WebSocket 的特点

1）正真的全双工方式
2）减少通信量
客户端和服务器端只需要建立一次握手，就可以建立持久性的连接。传统的客户端轮询需要不断的建立、关闭HTTP连接，由于HTTP是无状态协议，每次都要传递鉴别消息，服务端也是每次都要处理鉴别消息。
3）应用：聊天室、社交网站、股票行情

WebSocket 通信过程

long poll 、 ajax 和 WebScocket 之间的区别

long poll 其实原理跟 ajax轮询 差不多，都是采用轮询的方式，不过采取的是阻塞模型（类似于一直打电话，没收到就不挂电话）

Ajax轮询与long poll都属于不断发送http请求，然后等待服务器处理，服务端不能主动联系客户端，只有客户端发起。

webSocket实现了浏览器与服务器之间的全双工通信，能很好的节省服务器资源与带宽，并在服务器端与浏览器端实现实时通行，他建立在TCP之上， 同http一样，通过tcp来传输数据。

只需要一次HTTP握手，所以说整个通讯过程是建立在一次连接/状态中，服务器端会知道连接的信息，知道客户端关闭请求，同时由服务器主动推送，当有信息需要发送时，直接发送。客户端的连接通过session对象存储，能够实现实时推送。

所以实际上整个底层的思路是完全不同的。

二、SPDY 与 HTTP2.0

SPDY

SPDY是Google开发的基于TCP的会话层协议，用以最小化网络延迟，提升网络速度，优化用户的网络使用体验。SPDY并不是一种用于替代HTTP的协议，而是对HTTP协议的增强。新协议的功能包括数据流的多路复用、请求优先级以及HTTP报头压缩。谷歌表示，引入SPDY协议后，在实验室测试中页面加载速度比原先快64%。

SPDY

SPDY的改进：
1）多路复用请求优化
2）支持服务器推送技术
3）SPDY 压缩了 HTTP 头
4）强制使用 SSL 传输协议

HTTP2.0

HTTP2.0

HTTP2.0的改进：
1）二进制分帧

2）首部压缩

3）多路复用
资源合并，减少请求（雪碧图、文件合并等）优化的手段，对于HTTP2.0来说，只会增大无用的工作量，并没有特别大的意义。
单链接多资源的优势：
1.可以减少服务链接压力，内存占用少了，连接吞吐量大了
2.由于TCP 连接减少而使网络拥塞状况得以改观
3.慢启动时间减少，拥塞和丢包恢复速度更快

4）并行双向字节流的请求和响应
1.并行交错地发送请求，请求之间互不影响
2.并行交错地发送响应，响应之间互不干扰
3.只使用一个连接即可并行发送多个请求和响应，消除不必要的延迟，减少页面加载的时间

5）请求优先级
1.高优先级的流都应该优先发送
2.优先级不是绝对的
3.不同优先级混合也是必须的

6）服务器推送

三、管理WB服务器文件的WebDAV协议

在客户端通过WebDAV协议可以直接对服务器上的文件进行操作，实现远程文件管理。

四、QUIC 与 HTTP3.0

HTTP3.0

HTTP2.0的问题：
1）多路复用的队头阻塞
2）TCP建立连接的握手延迟大

QUIC的特性：
1）0 RTT

2）没有队头阻塞的多路复用

3）前向纠错

Web安全威胁解析

Web应用安全威胁分为六大类：

WASC(Web Application Security Consortium) 一个负责为 WWW指定应用安全标准的组织，将Web应用安全威胁分为六大类。
1）Authentication（验证）：用来确认某用户、服务或是应用本身份的攻击手段。如 登录、注册、忘记密码等。
2）Authorization（授权/会话管理）：用来决定是否某用户、服务、或是应用具有执行请求动作必要权限的攻击手段。
3）Client-Side Attacks（客户侧攻击）：用来扰乱或是探测Web站点用户的攻击手段。
4）Command Execution（命令执行）：在Web站点上执行远程命令的攻击手段。如SQL注入。
5）Information Disclosure（信息暴露）：用来获取Web站点具体系统信息的攻击手段。
6）Logical Attacks（逻辑性攻击）：用来扰乱或是探测Web应用逻辑流程的攻击手段。

验证技术

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

一、验中机制安全

image.png

二、会话管理安全

会话管理漏洞的防御：

1. 令牌传输安全
   令牌只能通过HTTPS传送；
   如果使用HTTP cookie传送令牌，应该将这些cookie标记为secure，以防止用户浏览器通过HTTP传送它们

2. 增加会话过期
   软会话过期，它指的是用户在一定的时间内与应用系统没有交互，则会话过期，也就是我们常说的** session 失效**；
   硬会话过期，它指的是用户登录到系统中经过一定的时间，不管用户做什么，该会话都会过期

3. 提供完善的注销功能
   用户可以手动地使当前会话过期，如 退出登录按钮；
   TlpS ：要保证注销不存在会话终止漏洞，如退出登录操作应在客户端和服务器端保持同步。

三、SQL注入攻击

SQL注入防御 —— 参数化查询。

参数化查询是对SQL注入根本性的防御策略，也叫预处理语句，在建立一个包含用户名输入的SQL语句时分为两步：
第一步：指定查询结构，用户输入预留占位符
第二步：指定占位符的内容

四、XSS 跨站脚本攻击

XSS攻击原理：

跨脚本攻击（Cross Site Scripting）,XSS 是一种经常出现在web应用中的计算机安全漏洞。它允许恶意web用户将代码植入到提供给其他用户使用的页面中，其他用户在观看网页时，恶意脚本会执行。
这里攻击通常通过注入HTML或JS脚本发动攻击。
攻击成功后，攻击者可以得到网页内容和cookie等。

XSS防御措施：

1. 输入验证

• 数据不是太长
• 数据仅包含某组合法字符
• 数据与一个特殊的正规表达式相匹配
• 根据应用程序希望在每个字段中收到的数据类型，应尽可能限制性地对姓名、电子邮件地址、账号等应用不同的确认规则

2. 输出编码

• 如果应用程序将某位用户或第三方提交的数据复制到它的响应中，那么应用程序应对这些数据进行HTML编码，以净化可能的恶意字符。
• HTML编码指对应的HTML实体代替字面量字符。这样做可确保浏览器安全处理可能是恶意的字符，把它们当作HTML文档的内容而非结构处理。
• 经常造成问题的字符的HTML编码如下：
  " => "
' => '
< => <
> => >
/=> x2F
• 在这两种防御中，输出确认最为重要，必不可少。实施严格的输入确认应被视为一种次要故障恢复。

五、CSRF 跨站请求伪造攻击

跨站请求伪造（Cross-site Request Forgery），通常被缩写为 CSRF 或 XSRF。

听起来像XSS（跨站脚本），但却与XSS不尽相同。 XSS 利用站点内的信任用户（受害者），而 CSRF 通过伪装来自受信任用户的请求来利用受信任的网站。今通过社会工程学的手段（如通过电子邮件发送一个链接）来蛊惑受害者进行一些敏感性的操作，如修改密码、修改E-mail 、转账等，而受害者还不知道他已经中招。

CSRF攻击原因：

1. web浏览器对于 Cookie 和 HTTP 身份验证信息之类的会话信息的处理方式。
   浏览器收到站点设置的 Cookie 后，每当向该站点发送请求的时候，浏览器都会 ”自动地“ 连同 Cookie 一起发出。
2. 应用程序依赖以管理会话的信息对浏览器的透明性问题。
   为提高Web应用的便利性，用来管理会话的信息，如 Cookie 或基于HTTP的身份验证等敏感信息，都是由浏览器来存放的；并在每当向需要身份验证的应用程序发送请求时自动捎带上。也就是说，浏览器可以访问会话管理信息，如果 Web 应用程序完全依赖于这类信息来识别一个用户会话，就为跨站请求伪造创造了条件。因为 Web 应用程序不会判断这个请求到底是否是合法用户发送的。

CSRF攻击预防：

1. 增加一些确认操作。
   如支付之前的确认支付提示框；
2. 重新认证。
   如在做一些敏感操作时，要求用户重新输入密码来进行二次验证；
3. 使用Token。
   提交此请求的时候，在服务器端检查提交的 Token 与用户 session 中的 Token 是否一致，如果一致，继续处理请求，否则返回一个错误信息给用户。在用户退出或者 session 过期的时候，用户信息（包括 CSRF Token ）从 session 中移除并且销毁 session 。

HTTP协议认证

HTTP常见认证方式

• BASIC认证（基本认证）
• DIGEST认证（摘要认证）
• SSL客户端认证
• FormBase认证（基于表单认证）

BASIC认证

HTTP请求报头： Authorization

HTTP响应报头： WWW-Authenticate

认证模式：基于质询/响应(challenge/response)的认证模式
质询/响应(challenge/response)：一方先返送认证要求给另一方，接着使用从另一方接受到的质询码计算生成响应码，再进响应码返回给对方进行认证。

基本认证是一种用来允许Web浏览器或其他客户端程序在请求时提供用户名和口令形式的身份凭证的一种登录验证方式。把 "用户名+冒号+密码"用BASE64算法加密后的字符串放在http request 中的header Authorization中发送给服务端。
客户端对于每一个realm，通过提供用户名和密码来进行认证的方式。

当浏览器访问使用基本认证的网站的时候， 浏览器会提示你输入用户名和密码：

假如用户名密码错误的话，服务器会返回401：

支持：HTTP1.0就被定义的一种认证方式。

优点：较容易实现、基本上所有流行的网页浏览器都支持基本认证。基本认证很少在可公开访问的互联网网站上使用，有时候会在小的私有系统中使用（如路由器网页管理接口）。

缺点：采用的是Base64编码方式，可对其进行解码得到用户名和密码。在HTTP这样非加密通信的线路上，如果没有使用SSL/TLS这样的传输层安全的协议，那么以明文传输的密钥和口令很容易被拦截。安全性不够。

认证步骤：
1、客户端访问一个受http基本认证保护的资源。

2、服务器返回401状态 和 Authoriz ation Required，告知客户端需要进行身份认证。同时响应头会带上WWW-Authenticate 字段，如：WWW-Authenticate： Basic realm="请求域" 。

3、客户端将输入的用户名密码以 ”用户名:密码“ 字符串形式再Base64进行编码后，采用非加密的明文方式传送给服务器。如：Authorization: Basic xxxxxxxxxx.

4、服务器将Authorization头中的用户名密码解码并取出，进行验证，如果认证成功，则返回相应的资源。如果认证失败，则仍返回401状态，要求重新进行认证。

BASIC认证过程

DIGEST认证（基本认证）

Digest认证也是采用质询/响应的认证模式，可以看做是基本认证的增强版本。
Digest用了一种nonce随机数字符串，双方约好对哪些信息进行哈希运算即可完成双方身份的验证。Digest模式避免了密码在网络上明文传输，提高了安全性，但它仍然存在缺点，例如认证报文被攻击者拦截到攻击者可以获取到资源，Digest认证提供了高于 BASIC 认证的安全等级。

支持： HTTP1.1提出的基本认证的替代方法。

优点：提供了密码被窃听的保护机制。

缺点：DIGEST认证安全等级虽高于 BASIC认证，提供了密码被窃听的保护机制，但并不能防止用户伪装。安全性不够。

认证步骤：
认证步骤与BASEC认证步骤大致一样，不同第方法在第2、3 步：

第2步：WWW-Authenticate 的内容不一样，提供 认证域(realm)、随机生成且只使用一次的随机数字符串(nonce)、加密方法(algorithm)、保护质量(qop) 等。

第3步：客户端消息头Authorization 返回进行 DIGEST 认证需要的字段：realm、nonce、url、response。因服务器在接受到 Authorization 后，就拥有与客户端同样的信息，因此服务器可以进行同样的计算，以验证客户端提交的 response 值的正确性。

response 值由三步计算而成：
1）对用户名、认证域(realm)以及密码的合并值（使用冒号：作为分割符）计算 MD5 哈希值，结果称为 HA1。
2）对HTTP方法以及URI的摘要的合并值计算 MD5 哈希值，例如，"GET" 和 "/dir/index.html"，结果称为 HA2。
3）对HA1、服务器密码随机数(nonce)、请求计数(nc)、客户端密码随机数(nonce)、保护质量(qop)以及 HA2 的合并值计算 MD5 哈希值。结果即为客户端提供的response 值。

response生成方式

DIGEST认证过程

SSL客户端认证

借由HTTPS的客户端证书完成认证的方式。凭借客户端证书认证，服务器可确认访问是否来自自己登录的客户端。
优点：安全性高。
缺点：成本高，一般使用在银行、金融 方面。

FormBase认证（基于表单认证）

基于表单认证方式并不是 HTTP 协议中定义的，而是使用由web应用程序各自实现基于表单的认证方式，在通过Cookie和Session的方式来保持用户的状态。

HTTP中介—— 代理 和 网关

HTTP代理服务器

代理服务器（Proxy Server），其功能就是代理网络用户去取得网络信息。可理解为，网络信息的中转站。

对于web客户端来说，代理扮演的是服务器的角色，接受 Request，返回 Response；
对于web服务器来说，代理扮演的是客户端的角色，发送 Request，接受 Response；

代理服务器是介于浏览器和Web服务器之间的一台服务器，有了它之后，浏览器不是直接到Web服务器去取回网页而是向代理服务器发出请求，Request信号会先送到代理服务器，由代理服务器来取回浏览器所需要的信息并传送给你的浏览器。

而且，大部分代理服务器都具有缓冲的功能，就好象一个大的Cache，它有很大的存储空间，它不断将新取得数据储存到它本机的存储器上，如果浏览器所请求的数据在它本机的存储器上已经存在而且是最新的，那么它就不重新从Web服务器取数据，而直接将存储器上的数据传送给用户的浏览器，这样就能显著提高浏览速度和效率。

代理的作用

抓包、FQ、匿名访问、过滤器 等

HTTP网关

网关扮演的是“协议转换器”的角色，它抽象出了一种能够到达资源的方法；

代理连接的是两个或多个始终相同的应用程序，而网关连接的是两个或多个使用不同协议的端点；

web网关在一侧使用HTTP协议，在另一侧使用另一种协议
第一种：（HTTP/）服务器端网关：通过HTTP协议与客户端对话，通过其他协议与服务器通信（例如发邮件）；
第二种：（/HTTP）客户端网关：通过其他协议与客户端对话，通过HTTP协议与服务器通信（例如查收有邮件）。

常见网关类型：
（HTTP/*）服务器端web网关、（HTTP/HTTPS）服务器端安全网关、（HTTPS/HTTP）客户端安全加速器网关、资源网关