Http

HTTP/2是HTTP协定自1999年HTTP 1.1的改进版RFC 2616公布后的首个更新，前身是SPDY协定（Google），于2015年2月17日被批准。 HTTP/2规范于2015年5月以RFC 7540正式发表，少数支流浏览器曾经在2015年底反对了该协定。目前国内外大多数网站也都曾经反对了HTTP/2，比方 Google/Stackoverflow/Reddit，国内的 淘宝/Segmentfault/掘金/CSDN/博客园/36Kr等等都曾经全面反对了HTTP/2协定 HTTP/2 相比HTTP/1 来说，次要是性能上的大幅晋升，而且齐全没有没有改变 HTTP/1协定中的利用语义。 Method、State Code、URI 和Header等外围概念齐全没有变动 上面具体介绍HTTP/2 中的一些要害降级点 二进制的分层（Binary Framing Layer）Binary Framing Layer 的设计，算是HTTP/2性能晋升的外围了。HTTP/2中在应用层又设计了一套BinaryFrame Layer，它定义了HTTP音讯在传输过程中的封装形式。不过这个Frame Layer和TCP 的 Packet可不是一回事，这个Frame Layer只是逻辑上的分层，在HTTP和TCP层之间，相似于Http Chunk 如上图所示，HTTP/2中的报文，在传输前都会被先构建成一个个的帧（Frame），每次Socket发送的最小单位是一个帧，每个帧都以二进制格局进行编码 二进制格局编码（Binary format encode）在HTTP/1中，数据都是以文本编码的模式进行传输的。那么什么叫文本编码，什么叫二进制编码呢？ 举个例子，协定中有一个长度的首部值为 11 ，这个数字在文本编码中（用字符串来示意），它会占用2个Byte，对应的字节为[49, 49]，那么在二进制编码下，11如果是Unsigned Int类型，那么它会占用4个Byte，对应的字节为[0, 0, 0, 11] 。 下面这个例子，看起来二进制编码下占用更大了；其实大多数状况下，二进制编码的占用会更低。如果换个大点的数字2147483647，在文本编码下须要占用10个Byte，可二进制编码下还是只须要占用4个Byte 文本编码（Byte Array）二进制编码（Byte Array）11[49, 49][0, 0, 0, 11]2147483647[50, 49, 52, 55, 52, 56, 51, 54, 52, 55][127, -1, -1, -1]二进制格局这个叫法尽管比拟容易引起歧义，不过大家都这么叫，那就是对的 不过既然都用二进制编码了，那么还能叫超文本传输（HyperText Transfer ）吗…… 比方在HTTP/1中，有一个Chunk编码，和下面提到的Binary Framing Layer有些类似，都是在TCP之上加了一层逻辑层。Chunk编码中有一个Length字段，就是用文本编码的，但Binary Framing 中的长度和其余字段都是用二进制编码，所以这也是HTTP/2新增的逻辑层叫Binary Framing的起因吧 ...

都晓得http的申请头和响应头都能够设置cache-control属性，它的作用是用来设置动态资源缓存的。难道他们就没有什么不一样的中央么？反正一开始我是不明确，在网上也硬是没找到答案，于是这篇文章就进去了。。。 以下是本次验证的代码： 客户端为了验证申请头cache-control的作用，所以采纳了ajax的形式来申请js。服务端次要是用来设置动态资源的缓存工夫的。咱们所说的缓存都是建设在get申请形式之上，其余形式设置的缓存临时没听说过哈 上面就是见证奇观的时刻： 场景一：当客户端、服务端都不设置cache-control的时候看看是什么状况 发现默认状况下是不会走缓存的 场景二：当服务端设置cache-control，客户端没有设置的时候看看是什么状况 发现缓存是由服务端开启的 场景三：当客户端设置cache-control，服务器端没有设置的时候看看是什么状况 发现当只有客户端开启cache-control时是不会失效的，缓存必须是由服务端开启 场景四：当客户端和服务端都设置了cache-control的时候看看是什么状况 发现30秒后缓存就生效了，而不是客户端设置的60秒，故缓存的生效工夫是由服务端设置决定的 场景五：当客户端设置不须要缓存，而服务端设置了缓存的时候看看什么状况 发现资源不再走强缓存了，而是间接向服务器发送了申请，故申请头中设置的cache-control是能够不走缓存的，cache-control: max-age=0这和按F5键是一样的成果 论断： 1、只有服务端能力开启缓存，默认是不会走缓存的 2、走了强缓存就不会再向服务端发送申请了 3、客户端的申请头中只有设置了cache-control为：'no-store' | 'no-cache' | 'max-age=0'才会失效（也就是客户端不想走强缓存的时候失效），除非后端对这个字段做非凡解决 如果有对强缓存和协商缓存不太分明的同学能够理解一下之前写过的一遍文章一文读懂http缓存（超具体）

简介nodejs作为一个优良的异步IO框架，其自身就是用来作为http web服务器应用的，nodejs中的http模块，提供了很多十分有用的http相干的性能。 尽管nodejs曾经带有http的解决模块，然而对于古代web应用程序来说，这或者还不太够，于是咱们有了express框架，来对nodejs的内容进行扩大。 明天咱们将会介绍一下应用nodejs和express来开发web应用程序的区别。 应用nodejs搭建HTTP web服务nodejs提供了http模块，咱们能够很不便的应用http模块来创立一个web服务： const http = require('http')const hostname = '127.0.0.1'const port = 3000const server = http.createServer((req, res) => { res.statusCode = 200 res.setHeader('Content-Type', 'text/plain') res.end('welcome to www.flydean.com\n')})server.listen(port, hostname, () => { console.log(`please visit http://${hostname}:${port}/`)})下面创立的http服务监听在3000端口。咱们通过应用createServer办法来创立这个http服务。 该办法承受一个callback函数，函数的两个参数别离是 req (http.IncomingMessage 对象）和一个res（http.ServerResponse 对像)。 在下面的例子中，咱们在response中设置了header和body值，并且以一个end办法来完结response。 申请nodejs服务咱们创立好http web服务之后，个别状况下是从web浏览器端进行拜访和调用。然而咱们有时候也须要从nodejs后端服务中调用第三方利用的http接口，上面的例子将会展现如何应用nodejs来调用http服务。 先看一个最简略的get申请： const http = require('http')const options = { hostname: 'www.flydean.com', port: 80, path: '/', method: 'GET'}const req = http.request(options, res => { console.log(`status code: ${res.statusCode}`) res.on('data', d => { console.log(d); })})req.on('error', error => { console.error(error)})req.end()下面代码咱们应用了http.request来创立一个request，并且传入了咱们自带的options参数。 ...

Spring 2.4.1 中启用HttpTrace不失效；management.endpoints.web.exposure.include=* management.endpoint.httptrace.enabled=true `<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId></dependency>`

DOM事件委托上代码： ul.addEventListener('click', function(e){ if(e.target.tagName.toLowerCase() === 'li'){ fn() // 执行某个函数 } })用mouse事件写一个可拖拽的div//HTML<div id="xxx"></div>//JSvar dragging = falsevar position = nullxxx.addEventListener('mousedown',function(e){ dragging = true position = [e.clientX, e.clientY]})document.addEventListener('mousemove', function(e){ if(dragging === false){return} console.log('hi') const x = e.clientX const y = e.clientY const deltaX = x - position[0] const deltaY = y - position[1] const left = parseInt(xxx.style.left || 0) const top = parseInt(xxx.style.top || 0) xxx.style.left = left + deltaX + 'px' xxx.style.top = top + deltaY + 'px' position = [x, y]})document.addEventListener('mouseup', function(e){ dragging = false})HTTP状态码2xx 示意胜利3xx 示意须要进一步操作4xx 示意浏览器方面出错5xx 示意服务器方面出错 ...

本文首先会 HTTP 的特点和优缺点，而后会具体介绍 HTTP 长连贯和短连贯的连贯治理，通过浏览本文可能对 HTTP 连贯有个深刻的意识。通过后面的 HTTP 系列文章，想必大家曾经晓得 HTTP 协定的基本知识，理解它的报文构造，申请头、响应头等细节。 HTTP 的特点所以接下来先是聊聊 HTTP 协定的特点、长处和毛病。既要看到它好的一面，也要正视它不好的一面，只有全方位、多角度理解 HTTP，能力实现“取长补短”，更好地利用 HTTP。 灵便可扩大 首先， HTTP 协定是一个“灵便可扩大”的传输协定。 HTTP 协定最后诞生的时候就比较简单，本着凋谢的精力只规定了报文的根本格局，比方用空格分隔单词，用换行分隔字段，“header+body”等，报文里的各个组成部分都没有做严格的语法语义限度，能够由开发者任意定制。 所以，HTTP 协定就随着互联网的倒退一起成长起来了。在这个过程中，HTTP 协定逐步减少了申请办法、版本号、状态码、头字段等个性。而 body 也不再限于文本模式的 TXT 或 HTML，而是可能传输图片、音频视频等任意数据，这些都是源于它的“灵便可扩大”的特点。 而那些 RFC 文档，实际上也能够了解为是对已有扩大的“抵赖和标准化”，实现了“从实际中来，到实际中去”的良性循环。 也正是因为这个特点，HTTP 能力在三十年的历史长河中“耸立不倒”，从最后的低速试验网络倒退到当初的遍布寰球的高速互联网，始终保持着旺盛的生命力。 牢靠传输 第二个特点， HTTP 协定是一个“牢靠”的传输协定。 这个特点不言而喻，因为 HTTP 协定是基于 TCP/IP 的，而 TCP 自身是一个“牢靠”的传输协定，所以 HTTP 天然也就继承了这个个性，可能在申请方和应答方之间“牢靠”地传输数据。 它的具体做法与 TCP/UDP 差不多，都是对理论传输的数据（entity）做了一层包装，加上一个头，而后调用 Socket API，通过 TCP/IP 协定栈发送或者接管。 不过咱们必须正确地了解“牢靠”的含意，HTTP 并不能 100% 保证数据肯定可能发送到另一端，在网络忙碌、连贯品质差等顽劣的环境下，也有可能收发失败。“牢靠”只是向使用者提供了一个“承诺”，会在上层用多种手段“尽量”保证数据的残缺送达。 当然，如果遇到光纤被意外挖断这样的极其状况，即便是神仙也不能发送胜利。所以，“牢靠”传输是指在网络根本失常的状况下数据收发必然胜利，借用运维里的术语，大略就是“3 个 9”或者“4 个 9”的水平吧。 ...

初识TCP/IP理解HTTP之前咱们得理解一下TCP/IP协定族。咱们通常所说得TCP/IP协定族是互联网相干的各类协定族的总称，而HTTP属于它外部的一个子集。还有一种说法认为TCP/IP是指TCP和IP这两种协定。 TCP/IP协定族里重要的一点就是分层。从上到下顺次分为以下4层：应用层、传输层、网络层和数据链路层。 TCP/IP协定族4层模型应用层 应用层的工作是通过利用过程间的交互来实现特定的网络应用。TPC/IP协定族内预存了各类通用的应用服务。比方，FTP（文本传输协定）和DNS（域名零碎）。HTTP协定也位于该层。 传输层 传输层次要为两台计算机过程之前的通信提供数据传输服务，也就是传输应用层的报文。该层的协定有：TCP协定和UDP协定。 网络层 网络层用来解决网络上流动的数据包。数据包是网络传输的最小数据单。该层规定通过怎么的门路达到对方的计算机，并把数据包传送给对方。在计算机网络中进行通信，之间可能会通过很多网络设备或者计算机，网络层就是要抉择适合的传输路线。网络层会把上一层的报文封装成数据包。该层应用的是IP协定。 链路层 用来解决连贯网络的硬件局部。包含操作系统、硬件设施的驱动、网卡和光纤等物理设施。硬件上的领域均在链路层的作用范畴之内。 发送端在层与层之间传输数据时，没通过一层必须要加上该层的首部信息。反之，接收端在层与层传输时必须把首部去掉。这种把数据信息包装起来的做法叫做封装。 上面会讲一讲和HTTP密不可分的三个协定：IP、TCP、DNS 负责传输的IP协定 IP协定的作用就是把各类数据包传送给对方。为了确保传送的精确，则须要满足各类条件。其中两个重要的条件就是IP地址和MAC地址。IP地址指明了节点被调配到的地址，MAC地址是指网卡所属的固定地址。IP地址是可变换的，而MAC地址基本上不会扭转。 网络通信的单方在同一局域网的状况很少，通常须要多台网络设备的直达能力连贯到对方。在直达时，会利用下一站直达设施的MAC地址来搜寻下一个直达指标。这时，会采纳ARP协定，ARP是一种解析地址的协定，依据通信方的IP地址就能够反查出对应的MAC地址。在这个直达的过程中，那些计算机、路由器等网络设备只能获悉很粗略的传输路线，这种机制称为路由抉择。 确保可靠性的TCP协定 TCP位于传输层，提供牢靠的字节流服务。所谓字节流服务，就是为了不便传输，TCP会将大数据宰割成以报文段为单位的数据包进行治理。而可靠性波及到的货色就很多了，比方三次握手、超时重传、流量管制等等。这一块会放到TCP/UDP的总结博客外面讲，临时只须要晓得TCP建设连贯会通过三次握手，断开连接会通过四次挥手。 负责域名解析的DNS服务 DNS和HTTP一样位于应用层。它提供域名到IP地址之间的解析服务。所谓域名就是相似于www.baidu.com这种字符串。为了不便记忆，计算机也能够被赋予域名。这样咱们就能够间接通过域名拜访，而不是毫无字面意义的IP地址。然而要让计算机去了解域名，就有些艰难了。为了解决这个问题，就须要用到DNS服务了。DNS提供域名查IP和IP查域名的服务。 在浏览器上输出一个域名会产生什么？ 最初，咱们以一个常见的面试题，来总结一下在应用HTTP协定进行通信的过程中，IP协定、TCP协定和DNS服务施展了哪些作用。 URI和URL URL就是咱们应用浏览器拜访WEB网页时输出的网页地址，比方：https://www.baidu.com/。URL的全称是对立资源定位符。 而URI是对立资源标识符。URI用字符串标识某一互联网资源，而URL标识资源的地点，所以URL是URI的子集。为了让你更直观的意识URI，能够理解以下URI的格局： 登录信息为指定用户名和明码，作为拜访服务器资源的登录信息，此项是可选项。服务器地址就是域名，也能够是IP。端口号也是可选项，不填的就会应用默认端口号。文件门路就是服务器上该资源的门路。查问字符串就是传入到服务器的参数。片段标识符也是可选项，它通常能够标记出已获取资源中的某个地位。 初识HTTP申请和响应HTTP协定的作用是用于客户端和服务器端之间的通信。通过申请和响应的交互达成通信。HTTP协定规定，申请从客户端收回，最初服务端响应申请并返回。 上面来看看申请报文的形成 办法就是申请的类型，URI上一节讲过。协定版本就是HTTP的版本号，其余的局部待会再说。上面再看看响应报文的形成 状态码能反应该次申请的后果如何，图中的200就代表申请胜利。 HTTP是一种无状态的协定，即HTTP协定自身不对申请和响应之间的通信状态进行保留。尽管其自身不能保留，然而为了实现放弃状态的性能，于是引入了Cookie技术。对于Cookie前面再说。 接下来具体说说后面提到的申请类型，也就是办法的意义。上面介绍以下HTTP/1.1中可应用的局部办法。 GET：获取资源 GET办法用来申请拜访被URI辨认的资源，如果申请的是文本图片这些资源，那就放弃原样返回。如果申请的是接口，那么就返回程序执行的返回后果。 POST：传输数据 尽管咱们也能够利用GET办法的参数来传输资源，然而个别还是用POST办法。尽管它们性能很类似，然而最次要的一个区别就是：GET办法的参数会显示在URI上，也就是以？号结尾的。而POST办法的参数会放在主体外面。这样对于传输数据来说，显然会平安一点。 PUT：传输文件 要求在申请报文的主体中蕴含文件内容，而后保留到URI指定的地位。 HEAD：取得报文首部 HEAD办法和GET办法一样，只是不返回报文主体局部。用于确认URI的有效性以及资源更新的日期工夫等。 DELETE：删除文件 与PUT办法相同，DELETE申请删除URI指定的资源。然而和PUT一样，它们都不带验证机制，所以个别的话也不会应用PUT或者DELETE，都能够用POST代替，而后配合程序代码来验证删除。 OPTIONS：查问反对的办法 用以查问URI指定资源反对的办法。 接着再说说后面提到的Cookie Cookie Cookie能够解决HTTP无状态的问题。Cookie会依据从服务端返回的响应报文中的一个叫Set-Cookie的首部字段信息，来告诉客户端保留Cookie。当下次客户端再次申请该服务端时就会在申请报文中退出Cookie值。常见的场景就是登录。首先客户端发送登录申请，登录胜利后服务端返回用户信息，而后客户端把用户信息存入Cookie，这样用户的登录状态就放弃住了。当然，个别不会间接把用户信息存入Cookie，毕竟Cookie是存在客户端的，很不平安，个别会配合Session来应用。比方把用户信息存到服务端的Session中，给客户端返回SessionID，这样一样能够查问出用户信息。 上面展现Cookie在申请响应中的样子 HTTP报文申请和响应之间替换的信息就被称为HTTP报文。申请方的叫做申请报文，响应方的叫做响应报文。HTTP报文大抵可分为首部和主体两局部。具体的可见下图 其中，申请行蕴含申请的办法，申请的URI和HTTP的版本。状态行蕴含响应后果的状态码和HTTP版本，状态码就比方后面提到的200，它代表申请胜利，更多的状态码和各种首部字段待会再详说。其余则蕴含Cookie等信息。 HTTP状态码状态码的职责是客户端发送申请后，形容返回的申请后果。借助状态码咱们就能够晓得该次申请在服务端是否失常解决了。状态码以结尾的数字次要分为5大类： 咱们只有遵循状态码类别的定义，即便在服务端创立本人的状态码都没问题。如果要列举每一个状态码，数量十分繁多，上面就介绍一下具备代表性的十几个状态码。 2XX：代表胜利 200 OK：示意客户端发送的申请在服务端被失常解决。 204 No Content：示意申请已被胜利解决，但在返回的响应报文中没用返回资源。 ...

本内容摘抄自《RESTful WebServices》 中文译本附录B '42种常见的HTTP响应代码'。原文作者：Leonard Ricbardson & Sam Ruby翻译：徐涵、李红军、胡伟 1、三至七种最根本的响应代码200("OK")一切正常。实体主体中的文档（若存在的话）是某资源的示意。400("Bad Request")客户端方面的问题。实体主题中的文档（若存在的话）是一个谬误音讯。心愿客户端可能了解此谬误音讯，并改过问题。500("Internal Server Error")服务期方面的问题。实体主体中的文档（如果存在的话）是一个谬误音讯。该谬误音讯通常杯水车薪，因为客户端无奈修复服务器方面的问题。301("Moved Permanently")当客户端触发的动作引起了资源URI的变动时发送此响应代码。另外，当客户端向一个资源的旧URI发送申请时，也发送此响应代码。404("Not Found") 和410("Gone")当客户端所申请的URI不对应于任何资源时，发送此响应代码。404用于服务器端不晓得客户端要申请哪个资源的状况；410用于服务器端晓得客户端所申请的资源已经存在，但当初曾经不存在了的状况。409("Conflict")当客户端试图执行一个”会导致一个或多个资源处于不统一状态“的操作时，发送此响应代码。SOAP Web服务只应用响应代码200("OK")和500("Internal Server Error")。无论是你发给SOAP服务器的数据有问题，还是服务器在解决数据的过程中呈现问题，或者SOAP服务器呈现外部问题，SOAP服务器均发送500("Internal Server Error")。客户端只有查看SOAP文档主体（body）（其中蕴含谬误的形容）能力获知谬误起因。客户端无奈仅靠读取响应的前三个字节得悉申请胜利与否。 2、状态码系列。1XX：告诉1XX系列响应代码仅在与HTTP服务器沟通时应用。 100("Continue")重要水平：中等，但（写操作时）很少用。这是对HTTP LBYL（look-before-you-leap）申请的一个可能的响应。该响应代码表明：客户端应从新发送初始申请，并在申请中附上第一次申请时未提供的（可能很大或者蕴含敏感信息的）示意。客户端这次发送的申请不会被回绝。对LBYL申请的另一个可能的响应是417("Expectation Failed")。 申请报头：要做一个LBYL申请，客户端必须把Expect申请报头设为字符串"100-continue"。除此以外，客户端还须要设置其余一些报头，服务器将依据这些报头决定是响应100还是417。 101("Switching Protocols")重要水平：非常低。当客户端通过在申请里应用Upgrade报头，以告诉服务器它想改用除HTTP协定之外的其余协定时，客户端将取得此响应代码。101响应代码示意“行，我当初改用另一个协定了”。通常HTTP客户端会在收到服务器发来的101响应后敞开与服务器的TCP连贯。101响应代码意味着，该客户端不再是一个HTTP客户端，而将成为另一种客户端。只管能够通过Upgrade报头从HTTP切换到HTTPS，或者从HTTP1.1切换到某个将来的版本，但理论应用Upgrade报头的状况比拟少。Upgrade报头也可用于HTTP切换到一个齐全不同的协定（如IRC）上，但那须要在Web服务器切换为一个IRC服务器的同时，Web客户端切换为一个IRC的客户端，因为服务器将立即在同一个TCP连贯上开始应用新的协定。 申请报头：客户端把Upgrade报头设置为一组心愿应用的协定。响应报头：如果服务器批准切换协定，它就返回一个Upgrade报头，阐明它将切换到那个协定，并附上一个空白行。服务器不必敞开TCP链接，而是间接在该TCP连贯上开始应用新的协定。 2XX: 胜利2XX系列响应代码表明操作胜利了。 200("OK")重要水平：十分高。一般来说，这是客户端心愿看到的响应代码。它示意服务器胜利执行了客户端所申请的动作，并且在2XX系列里没有其余更适宜的响应代码了。 实体主体：对于GET申请，服务器应返回客户端所申请资源的一个示意。对于其余申请，服务器应返回以后所选资源的一个示意，或者刚刚执行的动作的一个形容。 -201("Created")重要水平：高。 当服务器按照客户端的申请创立了一个新资源时，发送此响应代码。 响应报头：Location报头应蕴含指向新创建资源的标准URI。实体主体：应该给出新创建资源的形容与链接。若曾经在Location报头里给出了新资源的URI，那么能够用新资源的一个示意作为实体主体。 -202("Accepted")重要水平：中等。 客户端的申请无奈或将不被实时处理。申请稍后会被解决。申请看上去是非法的，但在理论解决它时有呈现问题的可能。若一个申请触发了一个异步操作，或者一个须要事实世界参加的动作，或者一个须要很长时间能力实现且没必要让Web客户端始终期待的动作时，这个相应代码是一个适合的抉择。 响应报头：应该把未解决完的申请裸露为一个资源，以便客户端稍后查问其状态。Location报头能够蕴含指向该资源的URI。实体主体：若无奈让客户端稍后查问申请的状态，那么至多应该提供一个对于何时能解决该申请的预计。 203("Non-Authoritative Information")重要水平：非常低。这个响应代码跟200一样，只不过服务器想让客户端晓得，有些响应报头并非来自该服务器--他们可能是从客户端先前发送的一个申请里复制的，或者从第三方失去的。 响应报头：客户端应明确某些报头可能是不精确的，某些响应报头可能不是服务器本人生成的，所以服务器也不晓得其含意。 204("No Content")重要水平：高。若服务器回绝对PUT、POST或者DELETE申请返回任何状态信息或示意，那么通常采纳此响应代码。服务器也能够对GET申请返回此响应代码，这表明“客户端申请的资源存在，但其示意是空的”。留神与304("Not Modified")的区别。204经常用在Ajax利用里。服务器通过这个响应代码通知客户端：客户端的输出已被承受，但客户端不应该扭转任何UI元素。 实体主体：不容许。 205("Reset Content")重要水平：低。它与204相似，但与204不同的是，它表明客户端应重置数据源的视图或数据结构。如果你在浏览器里提交一个HTML表单，并失去响应代码204，那么表单里的各个字段值不变，能够持续批改它们；但如果失去的响应代码205，那么表单里的各个字段将被重置为它们的初始值。从数据录入方面讲：204适宜对单条记录做一系列编辑，而205适于间断输出一组记录。 206("Partial Content")重要水平：对于反对局部GET（partial GET）的服务而言“十分高”，其余状况下“低”。它跟200相似，但它用于对局部GET申请（即应用Range申请报头的GET申请）的响应。局部GET申请罕用于大型二进制文件的断点续传。 申请报头：客户端为Range申请报头设置一个值。响应报头：须要提供Date报头。ETag报头与Content-Location报头的值应该跟失常GET申请雷同。 若实体主体是单个字节范畴（byte range），那么HTTP响应里必须蕴含一个Content-Range报头，以阐明本响应返回的是示意的哪个局部，若实体主体是一个多局部实体（multipart entity）（即该实体主体由多个字节范畴形成），那么每一个局部都要有本人的Content-Range报头。实体主体：不是整个示意，而是一个或者多个字节范畴。 3XX 重定向3XX系列响应代码表明：客户端须要做些额定工作能力失去所须要的资源。它们通常用于GET申请。他们通常通知客户端须要向另一个URI发送GET申请，能力失去所需的示意。那个URI就蕴含在Location响应报头里。 300("Multiple Choices")重要水平：低。若被申请的资源在服务器端存在多个示意，而服务器不晓得客户端想要的是哪一个示意时，发送这个响应代码。或者当客户端没有应用Accept-*报头来指定一个示意，或者客户端所申请的示意不存在时，也发送这个响应代码。在这种状况下，一种抉择是，服务器返回一个首选示意，并把响应代码设置为200，不过它也能够返回一个蕴含该资源各个示意的URI列表，并把响应代码设为300。 响应报头：如果服务器有首选示意，那么它能够在Location响应报头中给出这个首选示意的URI。跟其余3XX响应代码一样，客户端能够主动追随Location中的URI。实体主体：一个蕴含该资源各个示意的URI的列表。能够在示意中提供一些信息，以便用户作出抉择。 301("Moved Permanently")重要水平：中等。服务器晓得客户端试图拜访的是哪个资源，但它不喜爱客户端用以后URI来申请该资源。它心愿客户端记住另一个URI，并在今后的申请中应用那个新的URI。你能够通过这个响应代码来避免因为URI变更而导致老URI生效。 响应报头：服务器该当把标准URI放在Location响应报头里。实体主体：服务器能够发送一个蕴含新URI的信息，不过这不是必须的。 302("Found")重要水平：应该理解，特地市编写客户端时。但我不举荐应用它。这个响应代码市造成大多数重定向方面的凌乱的最根本原因。它应该是像307那样被解决。实际上，在HTTP 1.0中，响应代码302的名称是”Moved Temporarily”，可怜的是，在理论生存中，绝大多数客户端拿它像303一样解决。它的不同之处在于当服务器为客户端的PUT，POST或者DELETE申请返回302响应代码时，客户端要怎么做。为了打消这一混同，在HTTP 1.1中，该响应代码被重命名为"Found"，并新加了一个响应代码307。这个响应代码目前仍在宽泛应用，但它的含意市混同的，所以我倡议你的服务发送307或者303，而不要发送302.除非你晓得正在与一个不能了解303或307的HTTP 1.0客户端交互。 ...

作者简介李先生（Lemon），高级运维工程师（自称），SRE专家（指标），幻想在35岁买一辆保时捷。喜爱钻研底层技术，认为底层根底才是王道。所有新技术都离不开操作系统（CPU、内存、磁盘）、网络等。保持输入输出，记录本人学习的点滴，在平庸中保持前行，总有一天会遇见不一样的本人。公众号：运维汪（ID：Leeeee_Li）。                                                                                         一、问题解释Web服务器是如何解决HTTP事务的 二、Web服务器Web服务器会对HTTP申请进行解决并提供响应。Web服务器申请的七大步骤： 1）承受客户端连贯 2）接管申请报文 3）解决申请 4）资源映射及拜访 5）构建响应 6）发送响应 7）记录日志 1、承受客户端连贯 1）解决新连贯 客户端申请一条到Web服务器的TCP连贯时，Web服务器会建设连贯，判断连贯的另一端是哪个客户端，从TCP连贯中将IP地址解析进去。一旦新连贯建设起来并承受，服务器就会将新连贯增加到其现存Web服务器连贯列表中，做好监督连贯上数据传输的筹备。Web服务器能够随便回绝或立刻敞开任意一条连贯。有些Web服务器会因为客户端IP地址或主机名是未认证的，或者因为它是已知的歹意客户端而敞开连贯。Web服务器也能够应用其余技术辨认。 2）客户端主机名辨认 能够用”反向DNS“对大部分Web服务器进行配置，以便将客户端IP地址转换成客户端主机名。Web服务器能够将客户端主机名用于具体的访问控制和日志记录。须要留神的是，主机名查找可能会破费很长的工夫，这样会升高Web事务处理的速度。很多大容量的Web服务器会禁止主机名解析，或者只容许对特定内容进行解析。 能够用配置指令Hostnamelookups启用Apache的主机查找性能。如只关上HTML和CGI资源的主机名解析性能。 HostnameLookups off<Files ~ "\.(html|htm|cgi)$"> HostnameLookups on </Files>3）通过ident确定客户端用户 ...

 1.在电脑桌面右击鼠标抉择新建--文本文档  2.并命名为：biaobai.txt 3.关上并且把一下代码复制并粘贴到biaobai.txt  1. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 2. "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> 3. <html xmlns="http://www.w3.org/1999/xhtml"> 4. <head> 5. <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 6. <title>JUMP WORDS</title> 7. </head> 8. <body> 9. <div id="show"></div> 10. <script type="text/javascript"> 11. var str="自从和你相识以来，我平静的心湖再也无奈平静了。你的芳姿，你的丽影，你的笑靥，使我难以忘怀，我已被你美好的风度深深吸引！"; 12. var len=str.length; 13. var i=1; 14. function showword(){ 15. document.getElementById("show").innerHTML=str.substr(0,i++)+'_';; 16. if(i>len){ 17. clearInterval("done"); 18. } 19. } 20. var done=setInterval("showword()",500); 21. </script> 22. </body> 23. </html> ...

最近部门组织了一次前端性能优化交流会，大家从输出页面 URL 到最终页面展现内容这个过程提出了许多优化点。但同时发现很多同学对 HTTP 协定层的常识不能串联起来，于是整顿了这篇文章，心愿能够给大家带来一丝灵感。 当咱们在页面上发动一个 AJAX 申请的时候，在网络协议层面都经验了哪些内容？ // 发动申请fetch('https://baidu.com')// 协定层1...// 协定层2...// 协定层3....then(res=> // 失去后果 console.log(res)})如上述代码所示，咱们对 baidu.com 发动了一个网络申请，最终在 then 办法中失去了具体的响应内容。 应用 Wireshark 抓包后果如下： 图中能够看到，申请 baidu.com 时，首先通过 TCP 3 次握手建设连贯，而后通过 HTTP 传输内容，最初通过 TCP 4 次挥手断开连接。 实在的过程更加简单，咱们次要剖析以下几点： 建设连贯阶段 DNS 域名解析（应用层）建设 TCP 连贯（传输层） 通过 IP 寻址找到指标服务器（网络层）通过 Mac 寻址找到服务器硬件接口（数据链路层）通过网线向服务器硬件接口传输比特信息（物理层）发送数据阶段 建设 SSL 平安连贯（应用层）发送 HTTP 申请（应用层）建设连贯阶段要获取 baidu.com 的网页内容，就须要和 baidu 服务器建设连贯，怎么建设这个连贯呢？ 通过 DNS 获取 baidu 的 IP 地址。建设 TCP 连贯。DNS 域名解析通过 DNS 解析，咱们就能找到 baidu 服务器对应的 IP 地址。 ...

申请相干 get post Get 办法的含意是申请从服务器获取资源，这个资源能够是动态的文本、页面、图片视频等。Post向 URI 指定的资源提交数据，数据就放在报文的 body 里。GET 办法就是平安且幂等的, POST 都不是平安和幂等的概念： 在 HTTP 协定里，所谓的「平安」是指申请办法不会「毁坏」服务器上的资源。所谓的「幂等」，意思是屡次执行雷同的操作，后果都是「雷同」的。罕用端口号 200 「204 No Content」也是常见的胜利状态码，与 200 OK 基本相同，但响应头没有 body 数据。「206 Partial Content」是利用于 HTTP 分块下载或断点续传，示意响应返回的 body 数据并不是资源的全副，而是其中的一部分，也是服务器解决胜利的状态。300 301 Moved Permanently」示意永恒重定向，阐明申请的资源曾经不存在了，需改用新的 URL 再次拜访。302 Found」示意长期重定向，阐明申请的资源还在，但临时须要用另一个 URL 来拜访。301 和 302 都会在响应头里应用字段 Location，指明后续要跳转的 URL，浏览器会主动重定向新的 URL。304 Not Modified」不具备跳转的含意，示意资源未修改，重定向已存在的缓冲文件，也称缓存重定向，用于缓存管制。400 「403 Forbidden」示意服务器禁止拜访资源，并不是客户端的申请出错。500 500 Internal Server Error」与 400 类型，是个抽象通用的错误码，服务器产生了什么谬误，咱们并不知道。「501 Not Implemented」示意客户端申请的性能还不反对，相似“行将停业，敬请期待”的意思。「502 Bad Gateway」通常是服务器作为网关或代理时返回的错误码，示意服务器本身工作失常，拜访后端服务器产生了谬误。「503 Service Unavailable」示意服务器以后很忙，临时无奈响应服务器，相似“网络服务正忙，请稍后重试”的意思。缓存 缓存类型 200 form memory cache :不拜访服务器，个别曾经加载过该资源且缓存在了内存当中，间接从内存中读取缓存。浏览器敞开后，数据将不存在（资源被开释掉了），再次关上雷同的页面时，不会呈现from memory cache。200 from disk cache：不拜访服务器，曾经在之前的某个工夫加载过该资源，间接从硬盘中读取缓存，敞开浏览器后，数据仍然存在，此资源不会随着该页面的敞开而开释掉下次关上依然会是from disk cache。优先拜访memory cache,其次是disk cache，最初是申请网络资源强/协商缓存 协定 ...

                                                                                一、问题1、报文流是如何流动的 2、HTTP报文的三个组成部分 3、申请和响应报文之间的区别 4、申请报文反对的各种办法 5、和响应报文一起返回的各种状态码 6、各种各样的HTTP首部都是用来做什么的 二、报文流 1、什么是HTTP报文 HTTP报文是在HTTP应用程序间接发送的数据块。这些数据块以一些文本模式的元信息（meta-information）结尾。这些信息形容了报文的内容及含意，前面跟着可选的数据局部。这些报文在客户端、服务器和代理间接流动。 罕用术语：流入、流出、上游、上游 2、报文流入源端服务器 HTTP应用术语流入（inbound）和流出（outbound）来形容事务处理（transaction）的方向。报文流入源端服务器，工作实现后，会流回用户的Agent代理中。   3、报文向上游流动 HTTP报文会像河水一样流动。不论是申请报文还是响应报文，所有报文都会向上游（downstream）流动。所有的报文的发送者都在接收者的上游（upstream）。 对于申请报文来说，代理1位于代理3的上游；但对于响应报文来说，它就位于代理3的上游。 三、报文的组成HTTP报文是简略的格式化数据块。每条报文都蕴含一条来自客户端的申请，或者一条来自服务端的响应。他们由三个局部组成：对报文进行形容的起始行（start line），蕴含属性的首部（header）块，以及可选的、蕴含数据的主体（body）局部。 起始行和首部是由行分隔符的ASCII文本，每行都以一个由两个字符组成的行终止序列作为完结，其中蕴含一个回车符（ASCII码13）和一个换行符（ASCII码10）。 实体的主体或报文的主体是一个可选的数据块。与起始行和首部不同的是主体能够蕴含文本或二进制数据，也能够为空。 四、报文的语法所有的HTTP报文都能够分为两类：申请报文（request message）和响应报文（response massage）。申请报文会向Web服务器申请一个动作。响应报文会将申请的后果返回给客户端。申请和响应报文的根本报文机构雷同。 ...

前言我被Hr领进了一个小黑屋，让我在这里等面试官，过去一会，一位衣着拖鞋的中年男子走了进来，看着他绝顶聪明的发际线，晓得这必定是位大佬，我心里倍感到了压力； 面试官果然不是盖的，刚坐下后就开始立刻暴力输入了 面试官：我看你简历上写了相熟Http协定，当咱们应用浏览器拜访网址: https://silently9527.cn会产生什么？我：（这尼玛就是怕被搞事件所以没写精通，这也被搞。会产生什么，当然是展现出网页啊，大脑飞速旋转，脖子快断的时候，终于想到面试官可能想要问什么了） 我：英俊潇洒的面试官，你好！ 首先浏览器会去拜访DNS服务器，查问到域名对应的ip地址是多少，而后浏览器再去拜访这个ip地址；如果还要往底层在说的话，就会波及到tcp/ip的分层，我还是来画张图吧。 服务器返回资源的过程也是相似的形式 面试官：你方才有谈到tcp/ip的分层，能具体说下吗?我：（还好前前大学女友没把我当年上课的笔记给扔掉，刚好昨晚找回来复习了一下，温故而知新！只是笔记而已，大家别想歪了！）插图 我：TCP/IP协定族分为4层：应用层、传输层、网络层、数据链路层 应用层：次要是与利用通信应用到的协定，比方：FTP、DNS、HTTP传输层：为应用层提供在两台机器之间数据传输，有两种协定：TCP、UDP网络层：两台机器之间在传输的过程中会通过多个路由器有多条路线，网络层次要是从中抉择一条路线数据链路层：用来解决连贯网络的硬件局部，比如说网卡、设施驱动等面试官：在tcp/ip的分层外面，当客户端发动http申请达到服务端的过程中，数据包的封装以及解包的过程是怎么的？ 我：在这个分层中，每次网络申请都会依照分层的程序与对方进行通信，发送端从应用层往下走，接收端从数据链路层往上走；以Http来举例的话： 客户端在应用层（Http协定）发动一个HTTP申请在传输层（TCP协定）把从应用层收到的Http申请数据包分隔成小的数据包，并打好序网络层（IP协定）收到数据包后抉择发送门路服务器收到数据后依照程序往上发送，直到应用层收到数据 在发送方每通过一层，就会被加上该层的首部信息，当接管方承受到数据后，在每一个层会去掉对应的首部信息 面试官：TCP如何保证数据牢靠达到目的地？我：TCP协定采纳的三次握手策略 第一次握手：建设连贯时，客户端发送 syn 包(syn=j)到服务器，并进入 SYN_SEND 状态，期待服务器确认；第二次握手：服务器收到 syn 包，必须确认客户的 SYN（ack=j+1），同时本人也发送一个 SYN 包（syn=k），即 SYN+ACK 包，此时服务器进入 SYN_RECV 状态；第三次握手：客户端收到服务器的 SYN＋ACK 包，向服务器发送确认包 ACK(ack=k+1)，此包发送结束，客户端和服务器进入 ESTABLISHED 状态，实现三次握手。 面试官：为什么是三次握手，而不是两次或者4次呢？我：如果说是两次握手，如果客户端本人解决异样或者是服务器返回的ack音讯失落，那么客服端会认为连贯建设失败，再次从新发送申请建设连贯，然而服务端却无感知，认为连贯以及失常建设，导致服务器建设无用的连贯，浪费资源 如果四次握手，如果三次曾经足够，那就不须要四次了。如果四次的话，最初一个ACK失落，那么又会呈现两次握手的问题。 面试官：居然都到说了三次握手，那就说说四次挥手吧？ 我： 客户端向服务器发送FIN心愿断开连接申请。服务器向客户端发送ACK，表示同意开释连贯。服务器向客户端发送一个FIN示意心愿断开连接。客户端向服务器返回一个ACK表示同意开释连贯。 面试官：为什么断开连接须要四次而不是三次呢？我：因为当服务器收到客户端断开连接的申请后，服务器不能立刻断开连接，因为可能服务器端还有数据未发送实现，所以只能回复一个ACK示意我已收到音讯；等服务器端数据发送实现之后再发送一个FIN心愿端开连贯的音讯，客户端回复ACK之后，就能够平安断开了 面试官：为什么说Http协定无状态协定？怎么解决Http协定无状态？ 我：自身HTTP协定是不保留状态的，本身不对申请和响应间接的通信状态进行保留，所以是无状态的协定。因为在有些场景下咱们须要保留用户的登录信息，所以引入了cookie来治理状态。客户端第一次申请服务器的时候，服务器会生成cookie增加在响应头外面，当前客户端的每次申请都会带上这个cookie信息。 面试官：Cookie与Session有什么区别？我： Cookie是有服务器生成，写入到申请的响应头中，浏览器会保留；服务器通过Set-Cookie字段向客户端设置Cookie，属性：Name=value 设置cookie的名字和值expires 设置Cookie的有效期domain=域名 示意只能在哪个域名下失效secure示意只能在Https的通信时才发送cookieHttpOnly 示意不能被javascript拜访Session也是服务器生成的，示意服务器中的一片内存，每个客服端对应一个Session，客户端之间的Session互相独立；每次客户端发动申请，都会带上Cookie，Cookie外面个别都会有一个JSESSIONID，服务器就是通过这个JESSIONID来找到客户端对应Session，所以个别用户的登录信息都会寄存在Session；这样也解决了Http协定无状态的问题面试官：Http协定中有那些申请形式？如何抉择应用什么办法？我： GET : 获取资源; 所以查问操作个别用GETPOST: 传输实体主体, 创立更新操作用POSTPUT: 传输文件HEAD: 获取报文首部，如果想要查问某个申请的头信息能够用这个办法DELETE: 删除资源，所以删除操作用DELETEOPTIONS: 询问服务器反对哪些办法，响应头中返回 Allow: GET,POST,HEADTRACE: 追踪门路;在申请头中在Max-Forwards字段设置数字，每通过一个服务器该数字就减一，当到0的时候就间接返回，个别通过该办法查看申请发送进来是否被篡改面试官：Http如何实现长久连贯的呢？ 我：（毛线啊，我只是个来面试Java的高级程序员，干嘛要重复拿Http来摩擦我呢？！不过没事，我皮的很，这道题我又会）我：在HTTP协定的晚期，每进行一次HTTP通信就要断开一次tcp连贯，过后传输的内容少还能承受，当初每个网页个别的会蕴含大量的图片，每次申请都会造成TCP连贯的连贯和断开，减少通信的开销。 ...

Wireshark 抓包工具介绍这篇文章次要介绍一下 Wireshark 这个工具是如何抓包的，学习和应用抓包工具对于学习各种网络协议都很有帮忙。 1.如何抓取报文（1） 关上 Wireshark 抓包工具之后，点击 捕捉->选项： （2）在新关上的 捕捉选项 能够看到如下界面： （3）在 捕捉选项 界面点击 Output 能够看到如下界面： （4）在 捕捉选项 界面点击 选项 能够看到如下界面： （5）抉择好 网卡之后点击上面的 开始 即可抓取报文： （6）如下图所示是正在抓取报文的界面： 2.工具栏介绍 示意 开始抓包（捕捉->开始）示意 进行抓包（捕捉->进行）示意 从新开始抓包（捕捉->从新开始）示意 关上选项面板抓包（捕捉->选项）示意 关上抓包文件（文件->关上）示意 保留捕捉文件（文件->另存为）示意 敞开捕捉文件（文件->敞开）示意 从新载入抓包文件（视图->从新加载）示意 对报文着色（视图->着色分组列表）示意 放大（视图->缩放->放大）示意 放大（视图->缩放->放大）示意 回复失常尺寸（视图->缩放->一般大小）示意 使列宽适配内容长度（视图->调整列宽）示意 查找报文（编辑->查找分组）示意 到前一报文（跳转->前一分组）示意 到后一报文（跳转->后一分组）示意 到指定报文（跳转->转至分组）示意 到第一个报文（跳转->首个分组）示意 到最初一个报文（跳转->最新分组）示意 实时抓包时主动滚动窗口至最新报文3.数据包着色规定（视图->着色规定） Tips：能够依据本人须要来减少着色或缩小着色规定。4.设定工夫显示格局4.1 绝对工夫 Tips：能够按 Ctrl+Alt+4（视图->工夫显示格局->自捕捉开始通过的秒数） 切换为绝对工夫，如图所示显示的工夫是从开始抓包到抓取到该条报文通过的工夫。4.2 抉择绝对工夫基准点 Tips：也能够抉择某一条作为开始工夫基准点，选中之后按 Ctrl+T（右键选中该条->设置/勾销设置 工夫参考） 可切换该条当前显示的绝对工夫。4.3 相对工夫 Tips：能够按 Ctrl+Alt+1（视图->工夫显示格局->日期和工夫） 切换为相对工夫。5.数据包列表面板的标记符号 示意 会话中的第 1 个数据包。示意 会话中选中的数据包。示意 不属于会话中的数据包。示意 会话中最初 1 个数据包。示意 申请。示意 响应。示意 若以后选中的是 ACK 报文，则此报文是它确认的那个报文。示意 若以后选中的是 ACK 报文，则此报文是它反复确认的那个报文。示意 选中的报文与此报文有某种关联。6.流跟踪 ...

都说人红是非多，不知大家是否还记得，2019年爆红的歌曲《野狼Disco》就曾陷入剽窃风波，甚至被寄律师函。这件事当然曾经解决，老舅也证实了本人的清白。 然而原作者对本人音乐版权的爱护，值得咱们去学习，上面跟我来复盘一下吧： 1.保留好作品工程文件 在事件暴发之初原作者为了证实本人是原创，特意录了一段视频。视频里是他用FL Studio制作的工程文件，外面能够分明地看到单个音乐分轨。2.制作防盗水印 网络上有些作者为了避免盗图or注明出处会在图片上打上水印，这个办法同样也实用于音乐作品，例如《野狼Disco》编曲的前奏时，前奏中就有防盗水印“ihaksi”，刚听会有些许的奇怪。其实这就是原作者Vilho Ihaksi，为本人制作的防盗水印。这也是我这篇文章的要讲的重点。 在《More Sun》的第19秒处能够听到防盗水印，那具体怎么制作呢？个别做防盗水印都是把本人的名字录进去，录好之后在混音台中增加一些效果器，让它不影响音乐的美感，首先设定好音轨。 因每种伴奏的音效都不一样，所以给防盗水印增加的效果器也不尽相同，在这里就给大家演示几种罕用的效果器。 咱们平时录音时难免会录到杂音，所以先给防盗水印降噪。抉择效果器Fruity Limiter，设定噪声阈值和降噪范畴，别离为旋钮THRES和GAIN。声音是有频率的，频率越低就越爽朗，反之越尖利，当咱们须要调节防盗水印与原版伴奏匹配时，就须要用到均衡器。它能够调节防盗水印的频率，点击插槽Slot2，抉择“Fruity Parametric EQ 2”。 播放时每个频率的色彩深度会不一样，如图： 色彩越深代表这个频段点的电平越高，均衡器下端的20-10K是频率范畴，拖动图中的黑白圆点能够调节频率，最大到20K赫兹，这个范畴是人耳能听到的范畴，往上拖动则是对该频段的增益，反之为削弱，范畴为-18db-18db，能够在播放时拖动调节频率 下一步也是必要的一步，同样要用到前文提到的压缩器“Fruity Limiter”，抉择其中的“COMP”，再调节压缩阈值和压缩比率，别离为旋钮“THRES”和“RATIO”。压缩的作用是让防盗水印更加平均，不会忽高忽低。 除了这些罕用的效果器之外，还可依据理论状况增加混响。 点击Slot3，抉择“Fruity Reeverb 2”，来到混响界面。混响成果简而言之就是回声，在混响中调节一些参数能够扭转回声的成果。 混响界面右端有三个滑块： DRY：干声电平，可了解为原声。 ER：晚期反射，可了解为第一次回声，通常调高一点比拟好，成果更为显著。 WET：湿声电平，可了解为除了原声以外的反射声，即所有的回声。 除了间接对防盗水印进行调节外，还可通过扭转“外部环境”来扭转音效，拖动图中转动的图标即可，它就是“外部环境”，可比作是房子，高低拖动则是扭转房子的大小，房子越大回音工夫就越长，反之越短，而左右拖动则是扭转房子形态，即漫射。 如果咱们想给防盗水印加多点音效，比方提早。咱们能够增加提早效果器“Fruity delay 2”，再依据理论状况调节“输出音量”和“反馈电平”以及“工夫”。 除了提早之外，还有一种更为炫酷的成果就是失真。在上面的插槽中抉择“Fruity Fast Dist”，再抉择喜爱的预置成果。 除了以上这些成果之外，音乐编曲软件FL Studio20中还有很多能够增加的炫酷成果，感兴趣的小伙伴们能够试一试。 FL Studio软件提供了收费试用版能够无限期试用，只是无奈保留作品，有趣味的小伙伴能够下载试试： win版：点击下载试用 mac版：点击下载试用

HTTP状态码分类1XX：音讯这一类型的状态码，代表申请已被承受，须要持续解决。这类响应是长期响应，只蕴含状态行和某些可选的响应头信息，并以空行完结。 状态码英文名称形容100Continue客户端应该持续申请，如果曾经实现，则疏忽它。101Switching Protocols该代码是响应客户端的Upgrade标头发送的，并且批示服务器也正在切换的协定。102Processing服务器曾经收到并正在解决申请，但无响应可用。103Early Hints用来在最终的HTTP音讯之前返回一些响应头。2XX：胜利这一类型的状态码，代表申请已胜利被服务器接管、了解、并承受。 状态码英文名称形容200OK申请已胜利，申请所心愿的响应头或数据体将随此响应返回。201Created申请曾经被实现，而且有一个新的资源曾经根据申请的须要而创立，且其URI曾经随Location头信息返回。202Accepted服务器已承受申请，但尚未解决。203Non-Authoritative Information服务器是一个转换代理服务器，以200 OK状态码为起源，但回应了原始响应的批改版本。204No Content服务器胜利解决了申请，没有返回任何内容。205Reset Content服务器胜利解决了申请，但没有返回任何内容。与204响应不同，此响应要求请求者重置文档视图。206Partial Content服务器曾经胜利解决了局部GET申请。207Multi-Status代表之后的音讯体将是一个XML音讯，并且可能按照之前子申请数量的不同，蕴含一系列独立的响应代码。208Already ReportedDAV绑定的成员曾经在（多状态）响应之前的局部被列举，且未被再次蕴含。226IM Used服务器曾经满足了对资源的申请，对实体申请的一个或多个实体操作的后果示意。3XX：重定向这类状态码代表须要客户端采取进一步的操作能力实现申请。通常，这些状态码用来重定向，后续的申请地址（重定向指标）在本次响应的Location域中指明。 状态码英文名称形容300Multiple Choices被申请的资源有一系列可供选择的回馈信息，每个都有本人特定的地址和浏览器驱动的商议信息。用户或浏览器可能自行抉择一个首选的地址进行重定向。301Moved Permanently被申请的资源已永恒挪动到新地位，并且未来任何对此资源的援用都应该应用本响应返回的若干个URI之一。302Found要求客户端执行长期重定向。303See Other对应以后申请的响应能够在另一个URI上被找到，当响应于POST接管到响应时，客户端应该假设服务器曾经收到数据，并且应该应用独自的GET音讯收回重定向。304Not Modified资源在由申请头中的If-Modified-Since或If-None-Match参数指定的这一版本之后，未曾被批改。在这种状况下，因为客户端依然具备以前下载的正本，因而不须要从新传输资源。305Use Proxy被申请的资源必须通过指定的代理能力被拜访。306Switch Proxy在最新版的标准中，306状态码曾经不再被应用。最后是指“后续申请应应用指定的代理”。307Temporary Redirect与302相同，当从新收回原始申请时，不容许更改申请办法。308Permanent Redirect申请和所有未来的申请应该应用另一个URI反复。4XX：客户端谬误这类的状态码代表了客户端看起来可能产生了谬误，障碍了服务器的解决。 状态码英文名称形容400Bad Request因为显著的客户端谬误，服务器不能或不会解决该申请。401Unauthorized相似于403 Forbidden，401语义即未认证，即用户没有必要的凭据。402Payment Required该状态码是为了未来可能的需要而预留的。这个状态码通常不被应用。403Forbidden服务器曾经了解申请，然而拒绝执行它。404Not Found申请失败，申请所心愿失去的资源未被在服务器上发现，但容许用户的后续申请。405Method Not Allowed申请行中指定的申请办法不能被用于申请相应的资源。406Not Acceptable申请的资源的内容个性无奈满足申请头中的条件，因此无奈生成响应实体，该申请不可承受。407Proxy Authentication Required与401响应相似，只不过客户端必须在代理服务器上进行身份验证。408Request Timeout申请超时。409Conflict示意因为申请存在抵触无奈解决该申请。410Gone示意所申请的资源不再可用，将不再可用。411Length Required服务器回绝在没有定义Content-Length头的状况下承受申请。412Precondition Failed服务器在验证在申请的头字段中给出先决条件时，没能满足其中的一个或多个。413Request Entity Too Large服务器回绝解决以后申请，因为该申请提交的实体数据大小超过了服务器违心或者可能解决的范畴。414Request-URI Too Long申请的URI长度超过了服务器可能解释的长度，因而服务器回绝对该申请提供服务。415Unsupported Media Type对于以后申请的办法和所申请的资源，申请中提交的互联网媒体类型并不是服务器中所反对的格局，因而申请被回绝。416Requested Range Not Satisfiable客户端曾经要求文件的一部分，但服务器不能提供该局部。417Expectation Failed在申请头Expect中指定的预期内容无奈被服务器满足，或者这个服务器是一个代理服显的证据证实在以后路由的下一个节点上，Expect的内容无奈被满足。418I'm a teapot这个HTTP状态码在某些网站与我的项目中用作彩蛋。421Misdirected Request该申请针对的是无奈产生响应的服务器。422Unprocessable Entity申请格局正确，然而因为含有语义谬误，无奈响应。423Locked以后资源被锁定。424Failed Dependency因为之前的某个申请产生的谬误，导致以后申请失败。425Too Early服务器回绝解决在Early Data中的申请，以躲避可能的重放攻打。426Upgrade Required客户端应切换到Upgrade头字段中给出的不同协定。428Precondition Required原服务器要求该申请满足肯定条件。429Too Many Requests用户在给定的工夫内发送了太多的申请。431Request Header Fields Too Large服务器不愿解决申请，因为一个或多个头字段过大。451Unavailable For Legal Reasons该拜访因法律的要求而被回绝，由IETF在2015核准后新减少。5XX：服务器谬误这类状态码代表了服务器在解决申请的过程中有谬误或者异样状态产生，也有可能是服务器意识到以以后的软硬件资源无奈实现对申请的解决。 状态码英文名称形容500Internal Server Error通用谬误音讯，服务器遇到了一个未曾意料的情况，导致了它无奈实现对申请的解决。501Not Implemented服务器不反对以后申请所须要的某个性能。502Bad Gateway作为网关或者代理工作的服务器尝试执行申请时，从上游服务器接管到有效的响应。503Service Unavailable因为长期的服务器保护或者过载，服务器以后无奈解决申请。这个情况是临时的，并且将在一段时间当前复原。504Gateway Timeout作为网关或者代理工作的服务器尝试执行申请时，未能及时从上游服务器或者辅助服务器收到响应。505HTTP Version Not Supported服务器不反对，或者回绝反对在申请中应用的HTTP版本。506Variant Also Negotiates服务器存在外部配置谬误。507Insufficient Storage服务器无奈存储实现申请所必须的内容。这个情况被认为是长期的。508Loop Detected服务器在解决申请时陷入死循环。510Not Extended获取资源所须要的策略并没有被满足。511Network Authentication Required客户端须要进行身份验证能力取得网络拜访权限，旨在限度用户群拜访特定网络。非官方状态码状态码英文名称形容420Enhance Your CalmTwitter Search与Trends API在客户端被限速的状况下返回。444No ResponseNginx上HTTP服务器扩大。服务器不向客户端返回任何信息，并敞开连贯（有助于阻止恶意软件）。450Blocked by Windows Parental Controls由Windows家庭管制HTTP阻止的450状态代码的示例，用于信息和测试。494Request Header Too Large在错误代码431提出之前Nginx上应用的扩大HTTP代码。

代理（Proxy）也称网络代理，是一种非凡的网络服务，容许一个（个别为客户端）通过这个服务与另一个网络终端（个别为服务器）进行非间接的连贯。一些网关、路由器等网络设备具备网络代理性能。个别认为代理服务有利于保障网络终端的隐衷或平安，避免攻打。HTTP协定中，容许通过中间人（Intermediaries）来实现申请，“中间人”的交互流程，如下图所示：客户端本来发送给指标服务的报文，当初会发送给中间人，由中间人转发到指标服务器；当指标服务器返回后，中间人会将报文发送给客户端HTTP代理常见的利用场景有：伪造申请起源，绕过某些网络限度（你懂），抓包等等。 HTTP 代理这种“转发”模式的代理，工作原理很简略：当开启代理后，HTTP首部报文会批改为残缺URL，代理服务器就会从HTTP Request报文中解析第一行的指标服务信息，比方： # 未开启代理时的首行报文GET /v-5fc4b0fa/global/img/logo-b.svg HTTP/1.1# 开启代理后，发送的首行报文GET http://cdn.segmentfault.com/v-5fc4b0fa/global/img/logo-b.svg HTTP/1.1那么该申请的指标服务就是cdn.segmentfault.com 8080，此时收到音讯的Proxy Server会连贯到指标服务器cdn.segmentfault.com 8080，而后将收到的客户端报文发送到指标服务器，同时将收到的指标服务器报文转发给客户端 至于是收到残缺的HTTP报文才转发，还是每收到一个分组就转发，HTTP协定中并没有看到相干的标准 HTTP 隧道代理（Tunnel）隧道代理次要是为了SSL(TLS)提供的，因为下面介绍的一般代理无奈作为HTTPS的代理，HTTPS协定下会加密数据，所以解析报文头这一步就无奈工作了 在隧道代理下，和指标服务进行SSL握手的过程会交由代理服务器实现，代理服务还是会转发客户端发送和指标服务返回的每一个分组报文。 隧道代理（HTTPS）下，客户端首先会发送一个CONNECT类型的首行报文，如下所示： CONNECT home.netscape.com:443 HTTP/1.1User-agent: Mozilla/4.0...隧道代理服务收到首部报文后，会解析CONNECT信息，从中获取指标服务的地址（主机+端口），用来和指标主机建设连贯（SSL握手），当连贯建设实现后像客户端发送一段连贯建设胜利的报文： HTTP/1.1 200 Connection Established当客户端收到代理服务返回的连贯建设胜利报文时，就会进行SSL(TLS)握手/HTTP报文加密传输等工作，对于隧道代理服务来说，实现了CONNECT首部解析和返回连贯建设胜利报文之后就没有非凡工作了，只须要将客户端发送的报文间接转发给指标服务器，同时将收到的指标服务器报文转发给客户端。 在这个过程里，SSL(TLS)握手过程还是由客户端实现的，隧道代理服务并不关怀握手的细节，它只是自觉的转发报文 Socks 代理Socks代理尽管也能够作为HTTP的代理，然而它自身并不是面向HTTP协定的，可参考https://zh.wikipedia.org/zh-hans/SOCKS 基于Netty的HTTP Proxy Server实现https://github.com/kongwu-/netty-proxy-server根本实现，只实现了外围的proxy性能，keepAlive之类的并没有解决 参考HTTP tunnel - Wikipediahttps://github.com/luizluca/bridgeHypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing - ietfTunneling TCP based protocols through Web proxy servers - ietfhttps://www.ietf.org/rfc/rfc2068.txthttps://docs.oracle.com/javase/8/docs/technotes/guides/net/proxies.html

HTTP 协定（包体的传输方式&缓存的工作原理）这篇文章次要理解一下 HTTP 协定中定长包体传输的格局和不定长包体传输的格局，而后简略介绍一下 HTTP 协定中缓存的工作原理和利用场景。 1.HTTP 包体1.1 HTTP 包体格局申请或者响应都能够携带包体，基于 ABNF 形容的格局如下： #message-body = *OCTET:二进制字节流HTTP-message = start-line *(header-field CRLF) CRLF [message-body]1.2 不能携带包体的申请或响应HEAD 办法申请时对应的响应不能携带包体。1xx、204、304 状态码对应的响应。CONNECT 办法对应的 2xx 响应。1.3 发送定长包体格局在发送 HTTP 音讯时曾经可能确定包体的全副长度，格局如下： #应用 Content-Length 头部明确指明包体长度Content-Length = 1*DIGITTips：1*DIGIT 示意用 1 个 十进制（不是十六进制）数示意包体中的字节个数，必须与理论传输的包体长度统一，它的长处是接收端解决简略。1.4 发送不定长包体格局发送 HTTP 音讯时不能确定包体的全副长度，须要应用 Transfer-Encoding 头部指明应用 Chunk 传输方式，含有 Transfer-Encoding 头部后 Content-Length 头部会被疏忽。不定长包体长处如下： 基于长连贯继续推送动静内容。压缩体积较大的包体时，不用齐全压缩完（计算出头部）再发送，能够边发送边压缩。传递必须在包体传输完能力计算出的 Trailer 头部。transfer-coding = "chunked" / "compress" / "deflate" / "gzip" / transfer-extensionChunked transfer encoding 分块传输编码：Transfer-Encoding:chunkedchunked-body = *chunk last-chunk trailer-part CRLF chunk = chunk-size[chunk-ext] CRLF chunk-data CRLF#chunk-size-1*HEXDIG:留神这里是十六进制chunk-data-1*OCTETlast-chunk = 1*("0")[chunk-ext] CRLFtrailer-part = *(header-field CRLF)2.罕用 HTTP 缓存利用场景如下图所示，以百度首页为例，展现了 HTTP 缓存场景： ...

HTTP 协定（上下文介绍和多断点续传原理）HTTP 申请和响应都有一些示意 上下文 的罕用头部，所谓 上下文 指的就是某个申请（或响应）从哪里来，或者说某个申请（或响应）对后续申请（或响应）产生哪些影响，前面从 HTTP 协定的角度剖析大文件（大的包体）如何做到 断点续传 的，下载大文件（大的包体）的时候是如何做到 多线程 并发下载的。 1.申请的上下文 User-AgentUser-Agent 用于指明客户端的用户类型信息，服务器能够依据此类型信息做出对应响应，上面给出基于 ABNF 形容的 User-Agent 格局： User-Agent = product*(RWS(product/comment)) product = token ["/" product-version] RWS = 1*(SP/HTAB)2.User-Agent 示例2.1 firefox 浏览器中的 User-AgentUser-Agent:Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:83.0) Gecko/20100101 Firefox/83.0如下图所示： Tips:Mozilla/5.0 示意浏览器兼容 Mozilla/5.0，Windows NT 10.0; Win64; x64; rv:83.0示意的就是操作系统的版本信息，Gecko/20100101 是 firefox 浏览器的渲染引擎，Firefox/83.0 是浏览器的公布版本号。2.2 chrome 浏览器中的 User-AgentUser-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.198 Safari/537.36如下图所示： ...

HTTP1.0 和 HTTP1.1 的一些区别缓存解决在 HTTP1.0 中次要应用 header 里的 If-Modified-Since（比拟资源最初的更新工夫是否统一）,Expires（资源的过期工夫（取决于客户端本地工夫）） 来做为缓存判断的规范。 HTTP1.1 则引入了更多的缓存控制策略： Entity tag：资源的匹配信息If-Unmodified-Since：比拟资源最初的更新工夫是否不统一If-Match：比拟 ETag 是否统一If-None-Match：比拟 ETag 是否不统一等更多可供选择的缓存头来管制缓存策略。 带宽优化HTTP1.0 中，存在一些节约带宽的景象，例如客户端只是须要某个对象的一部分，而服务器却将整个对象送过来了，并且不反对断点续传性能。 HTTP 1.1默认反对断点续传。 Host 头解决在 HTTP1.0 中认为每台服务器都绑定一个惟一的 IP 地址，因而，申请音讯中的 URL 并没有传递主机名（hostname）。但随着虚拟主机技术的倒退，在一台物理服务器上能够存在多个虚拟主机，并且它们共享一个 IP 地址。HTTP1.1 的申请音讯和响应音讯都应反对 Host 头域，且申请音讯中如果没有 Host 头域会报告一个谬误（400 Bad Request）。 长连贯HTTP1.0 须要应用keep-alive参数来告知服务器端要建设一个长连贯，而 HTTP1.1 默认反对长连贯，肯定水平上补救了 HTTP1.0 每次申请都要创立连贯的毛病。 HTTP 是基于 TCP/IP 协定的，创立一个 TCP 连贯是须要通过三次握手的,有肯定的开销，如果每次通信都要从新建设连贯的话，对性能有影响。因而最好能维持一个长连贯，能够用个长连贯来发多个申请。 HTTP1.1 反对长连贯（PersistentConnection）和申请的流水线（Pipelining）解决，在一个 TCP 连贯上能够传送多个 HTTP 申请和响应，缩小了建设和敞开连贯的耗费和提早。 谬误告诉的治理在 HTTP1.1 中新增了 24 个谬误状态响应码，如 409（Conflict）示意申请的资源与资源的以后状态发生冲突；410（Gone）示意服务器上的某个资源被永久性的删除。 新增申请形式PUT：申请服务器存储一个资源DELETE：申请服务器删除标识的资源OPTIONS：申请查问服务器的性能，或者查问与资源相干的选项和需要CONNECT：保留申请以供未来应用TRACE：申请服务器回送收到的申请信息，次要用于测试或诊断HTTP2.0 与 HTTP1.X 的区别HTTP1.X 版本的缺点概括来说是：线程阻塞，在同一时间，同一域名的申请有肯定的数量限度，超过限度数目的申请会被阻塞。 ...

HTTP历史起源 蒂姆·伯纳斯·李（Tim Berners-Lee）爵士（1955年出生于英国）是万维网的发明者，互联网之父。 1989 年，欧洲核子钻研组织（CERN）的蒂姆·博纳斯-李（Tim Berners-Lee）博士提出一个构想：借助多文档之间互相关联造成的超文本（HyperText），连成可参阅的 WWW（World Wide Web，万维网），以帮忙远隔两地的研究者们共享常识。在这个构想中，他提出了 3 项 WWW 构建的关键技术：HTML, URI, HTTP. 互联网之父：蒂姆·伯纳斯·李（Tim Berners-Lee）、温顿·瑟夫(Vint Cerf 原名：Vinton Gray "Vint" Cerf ）、罗伯特·卡恩（Robert Elliot Kahn）等。 @Tim Berners-Lee HTTP 0.9 1989年 Tim Berners-Lee 蒂姆·伯纳斯-李在其论文中确立了： 1. URI：对立资源标识符2. HTML：超文本标记语言3. HTTP：超文本传输协定这个版本的 HTTP 只容许 Get 办法。 HTTP 1.0 1996年正式公布 减少 HEAD、POST 等新办法；减少响应状态码（status code），标记可能的谬误起因；引入了协定版本号概念；引入了 HTTP Header 的概念，让 HTTP 解决申请和响应更加灵便；传输的数据不再限于文本；此时的 HTTP/1.0 还只是一份参考文档，不是正式规范 HTTP 1.1 1999年 HTTP/1.1 公布 RFC 文档 2616，前面拆分成了 RFC7230 减少了PUT、DELETE、OPTIONS 等新的办法；减少了缓存治理和管制；明确了连贯放弃（keep-alive），容许继续连贯；容许响应数据分块（chunked），利于传输大文件；强制要求 Host 头，让互联网主机托管成为可能；HTTP/1.1 优缺点 ...

get post 上传文件 下载文件~~~~

一、背景HTTP是一个传输内容有可读性的公开协定，客户端与服务器端的数据齐全通过明文传输。在这个背景之下，整个依赖于Http协定的互联网数据都是通明的，这带来了很大的数据安全隐患。想要解决这个问题有两个思路： C/S端各自负责，即客户端与服务端应用协商好的加密内容在Http上通信C/S端不负责加解密，加解密交给通信协议自身解决 第一种在事实中的利用范畴其实比设想中的要宽泛一些。单方线下替换密钥，客户端在发送的数据采纳的曾经是密文了，这个密文通过通明的Http协定在互联网上传输。服务端在接管到申请后，依照约定的形式解密取得明文。这种内容就算被劫持了也不要紧，因为第三方不晓得他们的加解密办法。然而这种做法太非凡了，客户端与服务端都须要关怀这个加解密非凡逻辑。 第二种C/S端能够不关怀下面的非凡逻辑，他们认为发送与接管的都是明文，因为加解密这一部分曾经被协定自身解决掉了。 从后果上看这两种计划仿佛没有什么区别，然而从软件工程师的角度看区别十分微小。因为第一种须要业务零碎本人开发响 应的加解密性能，并且线下要交互密钥，第二种没有开发量。 HTTPS是以后最风行的HTTP的平安模式，由NetScape公司独创。在HTTPS中，URL都是以https://结尾，而不是http://。应用了HTTPS时，所有的HTTP的申请与响应在发送到网络上之前都进行了加密，这是通过在SSL层实现的。 二、加密办法通过SSL层对明文数据进行加密，而后放到互联网上传输，这解决了HTTP协定本来的数据安全性问题。一般来说，对数据加密的办法分为对称加密与非对称加密。 2.1 对称加密对称加密是指加密与解密应用同样的密钥，常见的算法有DES与AES等，算法工夫与密钥长度相干。 对称密钥最大的毛病是须要保护大量的对称密钥，并且须要线下替换。退出一个网络中有n个实体，则须要n(n-1)个密钥。 2.2 非对称加密非对称加密是指基于公私钥(public/private key)的加密办法，常见算法有RSA，一般而言加密速度慢于对称加密。 对称加密比非对称加密多了一个步骤，即要取得服务端公钥，而不是各自保护的密钥。 整个加密算法建设在肯定的数论根底上运算，达到的成果是，加密后果不可逆。即只有通过私钥(private key)能力解密失去经由公钥(public key)加密的密文。 在这种算法下，整个网络中的密钥数量大大降低，每个人只须要保护一对公司钥即可。即n个实体的网络中，密钥个数是2n。 其毛病是运行速度慢。 2.3 混合加密周星驰电影《食神》中有一个场景，黑社会火并，争执撒尿虾与牛丸的底盘划分问题。食神说：“真是麻烦，掺在一起做成撒尿牛丸那，笨蛋！” 对称加密的长处是速度快，毛病是须要替换密钥。非对称加密的长处是不须要交互密钥，毛病是速度慢。罗唆掺在一起用好了。 混合加密正是HTTPS协定应用的加密形式。先通过非对称加密替换对称密钥，后通过对称密钥进行数据传输。 因为数据传输的量远远大于建设连贯初期替换密钥时应用非对称加密的数据量，所以非对称加密带来的性能影响根本能够疏忽，同时又进步了效率。 三、HTTPS握手 能够看到，在原HTTP协定的根底上，HTTPS退出了平安层解决： 客户端与服务端替换证书并验证身份，事实中服务端很少验证客户端的证书协商加密协议的版本与算法，这里可能呈现版本不匹配导致失败协商对称密钥，这个过程应用非对称加密进行将HTTP发送的明文应用3中的密钥，2中的加密算法加密失去密文TCP层失常传输，对HTTPS无感知四、HttpClient对HTTPS协定的反对4.1 取得SSL连贯工厂以及域名校验器作为一名软件工程师，咱们关怀的是“HTTPS协定”在代码上是怎么实现的呢？摸索HttpClient源码的神秘，所有都要从HttpClientBuilder开始。 public CloseableHttpClient build() { //省略局部代码 HttpClientConnectionManager connManagerCopy = this.connManager; //如果指定了连接池管理器则应用指定的，否则新建一个默认的 if (connManagerCopy == null) { LayeredConnectionSocketFactory sslSocketFactoryCopy = this.sslSocketFactory; if (sslSocketFactoryCopy == null) { //如果开启了应用环境变量，https版本与明码控件从环境变量中读取 final String[] supportedProtocols = systemProperties ? split( System.getProperty("https.protocols")) : null; final String[] supportedCipherSuites = systemProperties ? split( System.getProperty("https.cipherSuites")) : null; //如果没有指定，应用默认的域名验证器，会依据ssl会话中服务端返回的证书来验证与域名是否匹配 HostnameVerifier hostnameVerifierCopy = this.hostnameVerifier; if (hostnameVerifierCopy == null) { hostnameVerifierCopy = new DefaultHostnameVerifier(publicSuffixMatcherCopy); } //如果制订了SslContext则生成定制的SSL连贯工厂，否则应用默认的连贯工厂 if (sslContext != null) { sslSocketFactoryCopy = new SSLConnectionSocketFactory( sslContext, supportedProtocols, supportedCipherSuites, hostnameVerifierCopy); } else { if (systemProperties) { sslSocketFactoryCopy = new SSLConnectionSocketFactory( (SSLSocketFactory) SSLSocketFactory.getDefault(), supportedProtocols, supportedCipherSuites, hostnameVerifierCopy); } else { sslSocketFactoryCopy = new SSLConnectionSocketFactory( SSLContexts.createDefault(), hostnameVerifierCopy); } } } //将Ssl连贯工厂注册到连接池管理器中，当须要产生Https连贯的时候，会依据下面的SSL连贯工厂生产SSL连贯 @SuppressWarnings("resource") final PoolingHttpClientConnectionManager poolingmgr = new PoolingHttpClientConnectionManager( RegistryBuilder.<ConnectionSocketFactory>create() .register("http", PlainConnectionSocketFactory.getSocketFactory()) .register("https", sslSocketFactoryCopy) .build(), null, null, dnsResolver, connTimeToLive, connTimeToLiveTimeUnit != null ? connTimeToLiveTimeUnit : TimeUnit.MILLISECONDS); //省略局部代码 }} ...

常见的 HTTP 缓存只能存储 GET 响应，对于其余类型的响应则无能为力，不是所有的 get 都能缓存，个别用来缓存动态资源(动态资源有Etag和Last-Modified)。申请和响应都会通过 web 缓存。当 web 缓存发现申请的资源曾经被存储，它会拦挡申请，返回该资源的正本，而不会去源服务端从新下载。当 web 缓存接管到响应时，增加或者更新资源的正本，更新正本的过期工夫等等； 缓存能够分为公有浏览器缓存和共享代理缓存： 公有浏览器缓存：只能被单个用户应用，比方 Web 浏览器中有内建的公有缓存共享代理缓存：能够被多个用户应用，比方缓存代理服务器缓存相干的头部信息申请头Cache-Control：在 HTTP/1.1 中 定义， 申请头和响应头都反对这个属性。通过它提供的不同的值来定义缓存策略。指令不辨别大小写，并且具备可选参数，能够用令牌或者带引号的字符串语法。多个指令以逗号分隔。 Cache-Control: max-age=<n>：当客户端发送带有 max-age 的指令时，缓存会判断正本的缓存工夫和 max-age 值 的大小。如果比 max-age 值 小，那么正本无效，能够持续给客户端返回缓存的正本。如果比 max-age 值 大，则向服务端申请资源。然而max-age=0时会验证缓存。Cache-Control: max-stale[=<n>]：客户端能够承受缓存工夫超过 max-age 的正本，但超过工夫不能大于 max-state 值。也就是说客户端能够承受缓存工夫小于 max-age 和 max-stale 值之和的正本。Cache-Control: min-fresh=<seconds>：保障资源在指定工夫内仍是陈腐的，即指定工夫内代理服务器的过期资源无奈作为响应返回。Cache-control: no-cache：放弃和第一次申请一样（不读缓存），获取最新的数据。Cache-control: no-store：疏忽缓存，每次由客户端发动的申请都会下载残缺的响应内容。Cache-control: no-transform：缓存服务器不得对资源进行转换或转变。Cache-control: only-if-cached：客户端只承受已缓存的响应，并且不要向原始服务器查看资源是否有更新。If-Match：当客户端 If-Match 的值和与服务端的 ETag 统一，服务端才会失常响应申请。If-Modified-Since： 服务器只在所申请的资源在给定的日期工夫之后对内容进行过批改的状况下才会将资源返回，状态码为 200 。如果申请的资源从那时起未经批改，那么返回一个不带有音讯主体的 304 响应，而在 Last-Modified 首部中会带有上次批改工夫。当与 If-None-Match 一起呈现时，If-Modified-Since 会被疏忽掉，除非服务器不反对 If-None-Match。If-None-Match：申请头 If-None-Match 的值与服务端的 ETag 统一，示意服务端资源未修改，返回状态码 304，间接应用缓存正本。如果不统一则响应时发送该资源，状态码为 200。Pragma：是 HTTP/1.0 规范中定义的一个 header 属性，首部的成果依赖于不同的实现，所以在“申请-响应”链中可能会有不同的成果，用来向后兼容只反对 HTTP/1.0 协定的缓存服务器。申请中 Pragma: no-cache 的成果跟在头信息中定义 Cache-Control: no-cache 雷同响应头Cache-Control： ...

一道经典的面试题是从 URL 在浏览器被输出到页面展示的过程中产生了什么，大多数答复都是说申请响应之后 DOM 怎么被构建，被绘制进去。 然而你有没有想过，收到的 HTML 如果蕴含几十个图片标签，这些图片是以什么形式、什么程序、建设了多少连贯、应用什么协定被下载下来的呢？ 要搞懂这个问题，咱们须要先解决上面五个问题： 1.古代浏览器在与服务器建设了一个 TCP 连贯后是否会在一个 HTTP 申请实现后断开？什么状况下会断开？ 2.一个 TCP 连贯能够对应几个 HTTP 申请？ 3.一个 TCP 连贯中 HTTP 申请发送能够一起发送么（比方一起发三个申请，再三个响应一起接管）？ 4.为什么有的时候刷新页面不须要从新建设 SSL 连贯？ 5.浏览器对同一 Host 建设 TCP 连贯到数量有没有限度？ 先来谈谈第一个问题：古代浏览器在与服务器建设了一个 TCP 连贯后是否会在一个 HTTP 申请实现后断开？什么状况下会断开？ 在 HTTP 1.0 中，一个服务器在发送完一个 HTTP 响应后，会断开 TCP 连贯。然而这样每次申请都会从新建设和断开 TCP 连贯，代价过大。 所以尽管规范中没有设定，某些服务器对 Connection: keep-alive 的 Header 进行了反对。 意思是说，实现这个 HTTP 申请之后，不要断开 HTTP 申请应用的 TCP 连贯。 这样的益处是连贯能够被从新应用，之后发送 HTTP 申请的时候不须要从新建设 TCP 连贯，以及如果维持连贯，那么 SSL 的开销也能够防止，两张图片是我短时间内两次拜访 Github.com 的工夫统计：头一次拜访，有初始化连贯和 SSL 开销，总耗时1.05s初始化连贯和 SSL 开销隐没了，阐明应用的是同一个 TCP 连贯耗时减小到440.90ms ...

一．接口申请的六种常见形式：1、Get 向特定资源发出请求（申请指定页面信息，并返回实体主体） 2、Post 向指定资源提交数据进行解决申请（提交表单、上传文件），又可能导致新的资源的建设或原有资源的批改 3、Put 向指定资源地位上上传其最新内容（从客户端向服务器传送的数据取代指定文档的内容） 4、Head 与服务器索与get申请统一的相应，响应体不会返回，获取蕴含在小音讯头中的原信息（与get申请相似，返回的响应中没有具体内容，用于获取报头） 5、Delete 申请服务器删除request-URL所标示的资源*（申请服务器删除页面） 6、opions 返回服务器针对特定资源所反对的HTML申请办法 或web服务器发送*测试服务器性能（容许客户端查看服务器性能） 二、get申请URL全称是资源描述符，咱们能够这样认为：一个URL地址，它用于形容一个网络上的资源，而HTTP中的GET，POST，PUT，DELETE就对应着对这个资源的查 ，改 ，增 ，删 4个操作。到这里，大家应该有个大略的理解了，GET个别用于获取/查问资源信息。 三、post申请post向指定资源提交数据进行解决申请（提交表单、上传文件），又可能导致新的资源的建设或原有资源的批改。 post申请个别通过body传递参数。例如登录： 四、head申请HEAD和GET实质是一样的，区别在于HEAD不含有出现数据，而仅仅是HTTP头信息。有的人可能感觉这个办法没什么用，其实不是这样的。设想一个业务情景：欲判断某个资源是否存在，咱们通常应用GET，但这里用HEAD则意义更加明确。 五、put申请PUT：这个办法比拟少见。HTML表单也不反对这个。实质上来讲， PUT和POST极为类似，都是向服务器发送数据，但它们之间有一个重要区别，PUT通常指定了资源的寄存地位，而POST则没有，POST的数据寄存地位由服务器本人决定。 举个例子：如一个用于提交博文的URL，/addBlog。如果用PUT，则提交的URL会是像这样的”/addBlog/abc123”，其中abc123就是这个博文的地址。而如果用POST，则这个地址会在提交后由服务器告知客户端。目前大部分博客都是这样的。显然，PUT和POST用处是不一样的。具体用哪个还取决于以后的业务场景。 六、DELETE申请DELETE：删除某一个资源。基本上这个也很少见，不过还是有一些中央比方amazon的S3云服务外面就用的这个办法来删除资源。 七、options申请OPTIONS：这个办法很乏味，但极少应用。它用于获取以后URL所反对的办法。若申请胜利，则它会在HTTP头中蕴含一个名为“Allow”的头，值是所反对的办法，如“GET, POST”。

前言HTTP 是前端开发人员必须晓得的常识，也是日常解决申请都会接触的，但如果要形成常识体系，则须要一点点填充常识，明天就要讲下 HTTP 和 HTTPS 协定。 HTTP 协定是什么HTTP 协定是超文本传输协定的缩写，英文是Hyper Text Transfer Protocol。它是一个基于申请与响应，无状态的，应用层的协定，常基于TCP/IP协定传输数据，互联网上利用最为宽泛的一种网络协议。设计 HTTP 的初衷是为了提供一种公布和接管 HTML 页面的办法。 HTTP 有多个版本，目前宽泛应用的是HTTP/1.1版本。 HTTP 特点申请和响应：根本的个性，由客户端发动申请，服务端响应简略疾速：客户向服务器申请服务时，只需传送申请办法和门路。申请办法罕用的有 GET、HEAD、POST。灵便：HTTP 容许传输任意类型的数据对象。传输的类型由Content-Type以标记。无连贯：限度每次连贯只解决一个申请。服务器解决完申请，并收到客户的应答后，即断开连接，然而却不利于客户端与服务器放弃会话连贯，为了补救这种有余，产生了两项记录 HTTP 状态的技术，一个叫做 Cookie,一个叫做 Session。无状态：无状态是指协定对于事务处理没有记忆，后续解决须要后面的信息，则必须重传。常见的申请办法GET：申请指定的页面信息，并返回实体主体。POST：向指定资源提交数据进行解决申请（例如提交表单或者上传文件）。HEAD：相似于 GET 申请，只不过返回的响应中没有具体的内容，用于获取报头PUT：从客户端向服务器传送的数据取代指定的文档的内容。DELETE：申请服务器删除指定的页面。HTTP 的毛病明文传输：数据齐全肉眼可见，可能不便地钻研和剖析，但也容易被窃听HTTP 是不平安的，无奈验证通信单方的身份，也不能判断报文是否被批改为什么要用 HTTPSHTTP 协定以明文形式传递信息，不提供任何形式的数据加密，不适宜传输一些敏感信息，比方：各种账号、明码等信息，应用 HTTP 协定传输隐衷信息十分不平安。 为了解决上述 HTTP 存在的问题，就呈现了 HTTPS。 HTTPS 协定的次要作用能够分为两种：一种是建设一个信息安全通道，来保障数据传输的平安；另一种就是确认网站的真实性；解决了 HTTP 存在的毛病问题。 什么是 HTTPS?HTTPS 协定（HyperText Transfer Protocol over Secure Socket Layer）：个别了解为HTTP+SSL/TLS，通过 SSL 证书来验证服务器的身份，并为浏览器和服务器之间的通信进行加密。 HTTPS 是一种通过计算机网络进行平安通信的传输协定，经由 HTTP 进行通信，利用SSL/TLS建设全信道，加密数据包。HTTPS 应用的次要目标是提供对网站服务器的身份认证，同时爱护替换数据的隐衷与完整性。 SSL 是什么？SSL（Secure Socket Layer，安全套接字层）：SSL 协定位于 TCP/IP 协定与各种应用层协定之间，为数据通讯提供平安反对。 TLS（Transport Layer Security，传输层平安）：其前身是 SSL，它最后的几个版本（SSL 1.0、SSL 2.0、SSL 3.0）由网景公司开发，目前应用最宽泛的是TLS 1.1、TLS 1.2。 ...

学习Shell - wget接入短信验证码的作用就是一个：实用，最近我的项目中须要接入短信验证码，给大家分享一下：`wget --no-check-certificate --quiet \ --method POST \ --timeout=0 \ --header 'Content-Type: application/x-www-form-urlencoded;charset=utf-8' \ --body-data 'appId=41KYR0EB&appKey=IIWCKKSR7NOQ&phone=1561894**&templateId=1043&variables=1234' \ 'https://vip.veesing.com/smsAp...'`尽管验证码接入很常见，对接也不简单，要害是找到一个稳固牢靠的短信服务很难，须要一个个对接测试，以上示例中的短信接口是各大云市场短信服务提供商的接口，稳定性还不错，如果大家也感觉不错的话，给个一键三连呗！毕竟测试也是很消耗工夫的呢。Shell - wget.sh和文档阐明下载

本文基于HttpClient 4.5.13 应用 http 申请内部服务时，因为网络或者服务自身的不稳定性，常常须要重试。重试当然能够通过手撸代码实现，但更好的形式是通过现有的机制去实现。HttpClient 中反对两种重试： 异样重试。服务不可用重试。异样重试HttpClient 执行时会抛出两种异样： java.io.IOExceptionClientProtocolExceptionjava.io.IOException 被认为是非致命性且可复原的，而 ClientProtocolException 被认为是致命性的，不可复原。 解决的时候要留神，ClientProtocolException 是 java.io.IOException 的子类。 如果是这样创立 HttpClient 的 CloseableHttpClient httpClient = HttpClients.custom().build();异样重试是默认开启的，具体代码能够参考 HttpClientBuilder.build() 办法，上面是相干的代码 // Add request retry executor, if not disabledif (!automaticRetriesDisabled) { HttpRequestRetryHandler retryHandlerCopy = this.retryHandler; if (retryHandlerCopy == null) { retryHandlerCopy = DefaultHttpRequestRetryHandler.INSTANCE; } execChain = new RetryExec(execChain, retryHandlerCopy);}automaticRetriesDisabled 是一个 boolean 类型的变量，默认为 false ，所以条件默认是成立的，如果没有设置 HttpRequestRetryHandler 就会用一个默认的。 DefaultHttpRequestRetryHandler次要有三个成员变量 retryCount重试次数requestSentRetryEnabled 是否能够在申请胜利收回后重试，这里的胜利是指发送胜利，并不指申请胜利。nonRetriableClasses 不重试的异样类汇合，如果异样为汇合中指定的异样时，不会重试。默认的实例变量设置如下 retryCount=3，最多重试3次。requestSentRetryEnabled=false，发送胜利的就不会重试了nonRetriableClasses蕴含了以下四种： InterruptedIOExceptionUnknownHostExceptionConnectExceptionSSLException重试的执行逻辑在org.apache.http.impl.execchain.RetryExec，有趣味的能够去看下。 默认的是否重试逻辑如下 ...

编者注：明天咱们分享的是卢士杰同学整顿的网站罕用鉴权计划的实现原理与实现以及他们的实用场景，帮忙大家在业务中做适合的抉择。 背景说起鉴权大家应该都很相熟，不过作为前端开发来讲，鉴权的流程大头都在后端小哥那边，本文的目标就是为了让大家理解一下常见的鉴权的形式和原理。 认知：HTTP 是一个无状态协定，所以客户端每次发出请求时，下一次申请无奈得悉上一次申请所蕴含的状态数据。 一、HTTP Auth Authentication简介HTTP 提供一个用于权限管制和认证的通用框架。最罕用的HTTP认证计划是HTTP Basic Authentication 鉴权流程 加解密过程// Authorization 加密过程let email = "postmail@test.com"let password = "12345678"let auth = `${email}:${password}`const buf = Buffer.from(auth, 'ascii');console.info(buf.toString('base64')); // cG9zdG1haWxAdGVzdC5jb206MTIzNDU2Nzg=// Authorization 解密过程const buf = Buffer.from(authorization.split(' ')[1] || ''), 'base64');const user = buf.toString('ascii').split(':');其余 HTTP 认证通用 HTTP 身份验证框架有多个验证计划应用。不同的验证计划会在平安强度上有所不同。 IANA 保护了一系列的验证计划，除此之外还有其余类型的验证计划由虚拟主机服务提供，例如 Amazon AWS ，常见的验证计划包含： Basic (查看 RFC 7617, Base64 编码凭证. 详情请参阅下文.),Bearer (查看 RFC 6750, bearer 令牌通过OAuth 2.0爱护资源),Digest (查看 RFC 7616, 只有 md5 散列 在Firefox中反对, 查看 bug 472823 用于SHA加密反对),HOBA (查看 RFC 7486 (草案), HTTP Origin-Bound 认证, 基于数字签名),Mutual (查看 draft-ietf-httpauth-mutual),AWS4-HMAC-SHA256 (查看 AWS docs)二、Cookie + Session注册流程 ...

理解 HTTP 协定浏览器背地的故事当咱们在浏览器输出一个域名后，背地到底产生了什么？ 第一步：当咱们输出域名后，在 DNS 服务器进行域名查问。 第二步：失去对应的 ip 地址。 第三步：浏览器依据 ip 向 web 服务器进行通信发送申请，而通信的协定就是 HTTP。 第四步：web 服务器回传页面内容。 第五步：浏览器收到回传信息的报文数据，进行渲染出咱们看得懂的页面。 举个例子：如果咱们想给张三打电话，咱们须要在通讯录中先找到名字为张三的人，而张三这个名字就是域名，对应的手机号就是 ip。在通话过程中我讲普通话，而张三讲英语，这样必定是没有方法沟通的，而共同语言就是 HTTP 协定。 那什么是 HTTP？ 超文本传输协定(Hyper Text Transfer Protocol)是一种通信协议，它容许将超文本标记语言(HTML)文档从 Web 服务器传送到客户端的浏览器。HTTP 是一个属于应用层的面向对象的协定，因为其便捷、疾速的形式，实用于分布式超媒体信息系统。它于 1990 年提出，通过几年的应用与倒退，失去一直的欠缺和扩大。WEB 和 HTTP WEB 是一种基于超文本和 HTTP 的、全球性的、动静交互的、跨平台的分布式图形信息系统。建设在 Internet 的一种网络服务，为浏览者在 Internet 上查找和浏览信息提供了图形化的、易于拜访的直观界面，其中的文档及超级链接将 Internet 上的信息节点组织成一个互为关联的网状结构。HTTP 协定的前世今生 万维网的创始人叫蒂姆·伯纳斯·李（Tim Berners-Lee）简略点说，是当代互联网的创始人。 在 1990 年，他发表了一篇论文，提出了在互联网上构建超链接文档零碎的构想，在这篇论文里他确立了三项关键技术： URI：对立资源标识符，作为互联网上资源的惟一标识HTML：超文本标记语言，形容超文本文档HTTP：超文本传输协定，用来传输超文本这三项技术间接奠定了咱们当今 Web 世界的技术，蒂姆把它称为万维网（World Wide Web）。 所以，1991 年，HTTP 0.9 诞生了。 HTTP 0.9 该版本极其简略，只有一个命令 GET。协定规定，服务器只能回应 HTML 格局的字符串，不能回应别的格局。服务器发送结束，就敞开 TCP 连贯。 ...

最近在联调接口时发现了一个要命的问题，就是接口url明明是正确的，然而发送就是不胜利，报404异样的谬误 代码伪代码如下，一个很失常的删除数据申请 function foo(id) { return axios({ method: 'delete', url: '/api/resume/queue/' + id })}报错报错如下： 这里和后端一起验证过了，的确有这个接口，应用postman申请是没问题的查资料，重复验证而后本人写了个接口模仿了下，没有重现这个问题，申请其它 api 也都失常 接着就是查各种材料，刚开始一度认为是 delete 申请、vue-cli的锅，查了各种材料，但还是满载而归 深思最初看着 DELETE http://localhost:8070/%E2%80%8B/api%E2%80%8B/resume%E2%80%8B/queue%E2%80%8B/81862404 404 (Not Found) 这一段报错信息陷入了深思 404申请必定是接口地址不正确的问题，然而这里的门路看着没问题（但也只是看着） 这里发现最初申请的门路退出了一些编码，也就是 %E2%80%8B 这个，而后在控制台调用 decodeURI('%E2%80%8B') ，返回 '' 空字符串，看到这里应该明确了，嗯，倒吸一口凉气... 起因如果将光标挪动到 下面 url 门路上，会发现每个/后面须要挪动两次能力跳过，其实那儿的确有一个非凡的字符，只是它没有宽度，让人误以为是什么也没有，然而如果 encodeURI 编码一下会发现的确是有货色的，也就是 %E2%80%8B 最初发现，还是因为偷懒图不便，接口地址间接从 swagger 文档那边复制过去的，而复制源外面的字符存在空白编码%E2%80%8B，空白编码没有宽度，尽管看不到然而会导致无奈准确匹配呈现问题，浏览器对申请门路会自动编码，这样门路齐全就不一样了，这个后端路由无奈辨认，当然就404了 网上查了下，%E2%80%8E 的学名叫 Zero-width-space(零宽空格) ，顾名思义，它是一个Unicode字符，肉眼不可见，却是的确存在的一个字符 解决一时复制一时爽，始终复制一爽快，你无奈确认你复制的字符是否存在空白编码，所以少点复制，还是老老实实手敲一遍吧，尤其是字符串的局部从开发者的角度来看，能通过代码解决的必定更好，其实能够在发送申请之前对 url 做个正则匹配，将%E2%80%8B替换掉伪代码： // 在申请发送前url = decodeURI(encodeURI(url).replace(/%E2%80%8B/g, ''))遇到这个问题其实挺无奈的，一个并不起眼的中央，如果你不留神，会导致你做很多无用功

书写URL时应用的是ASCII字符集，它是一种单字节字符的编码方案，一共收录了128个字符，用一个字节就能够存储，比方字符a用二进制就能够示意为01100001。128个并不多，所以如果URL中含有非ASCII字符集中的字符，就要对其编码。 除此之外，还须要对URL中的保留(reserved)字符和不平安(unsafe)字符进行编码。 所谓保留字符就是那些在URL中具备特定意义的字符，不平安字符是指那些在URL中没有非凡含意，但在URL所在的上下文中可能具备非凡意义的字符，比方双引号(“”)。 下图是一些保留字符和不平安字符示例： 编码时，应用的是%编码标准。具体阐明如下： 对URL中的非保留字符和非不平安字符不进行编码。对URL中的保留字符和不平安字符，须要取其ASCII内码，而后加上%前缀，将该字符进行编码。对URL中的非ASCII字符，须要取其Unicode内码，而后加上%前缀，将该字符进行编码。

作者：易哥链接：https://www.zhihu.com/questio...起源：知乎著作权归作者所有。商业转载请分割作者取得受权，非商业转载请注明出处。 首先，实名投诉题主的问题。这个问题十分好。 其次，实名拥护各个上来就讲RPC好而HTTP不好的答案。因为，题主的观点十分对。 HTTP协定，以其中的Restful标准为代表，其劣势很大。它可读性好，且能够失去防火墙的反对、跨语言的反对。而且，在去年的报告中，Restful大有超过RPC的趋势。 本想援用下报告内容，无奈最近因为某些起因，KeXueShangWang被Qiang了。等我日后出墙时，再做补充。然而HTTP也有其毛病，这是与其长处绝对应的。首先是有用信息占比少，毕竟HTTP工作在第七层，蕴含了大量的HTTP头等信息。其次是效率低，还是因为第七层的缘故。还有，其可读性仿佛没有必要，因为咱们能够引入网关减少可读性。此外，应用HTTP协定调用近程办法比较复杂，要封装各种参数名和参数值。 而RPC则与HTTP互补，咱们具体介绍下。看完这篇答复，能让你对RPC的产生、原理、实现代码都有着清晰的理解。这样，也能在业务零碎中，在RPC和HTTP之间做好抉择。 但须要再说一句，不是说RPC好，也不是说HTTP好，两者各有千秋，还在比拼中。 要问我站谁？我依据业务场景，灵便站位…… 评论区产生了一些争执，我在这里对立进行阐明。争执次要产生在两点： 1、HTTP和RPC同一级别，还是被RPC蕴含？ 2、Restful也属于RPC么？ 对于以上两点，我画图来一一阐明。 上图是一个比拟残缺的关系图，这时咱们发现HTTP（图中蓝色框）呈现了两次。其中一个是和RPC并列的，都是跨利用调用办法的解决方案；另一个则是被RPC蕴含的，是RPC通信过程的可选协定之一。 因而，第一个问题的答案是都对。看指的是哪一个蓝色框。从题主的发问看，既然题主在纠结这两者，应该是指与RPC并列的蓝色框。 第二个问题是在问近程过程调用（红色框）是不是蕴含了Restful（黄色框），这种了解的关键在于对RPC的了解。 RPC字面了解是近程过程调用，即在一个利用中调用另一个利用的办法。那Restful是满足的，通过它能够实现在一个利用中调用另一个利用的办法。 然而，上述了解使得RPC的定义过于宽泛。RPC通常特指在一个利用中调用另一个利用的接口而实现的近程调用，即红色框所指的范畴。这样，RPC是不蕴含Restful的。 因而，第二个问题的答案是Restful不属于RPC，除非对RPC有着非常规的宽泛了解。 RPC的英文全称是Remote Procedure Call，翻译为中文叫“近程过程调用”。其中稍显艰涩的其实就是“过程”，过程其实就是办法。所以，能够把RPC了解为“近程办法调用”。 要理解近程过程调用，那先了解过程调用。非常简单，如下图，就是调用一个办法。这太常见了，不多解释。 而在分布式系统中，因为每个服务的边界都很小，很有可能调用别的服务提供的办法。这就呈现了服务A调用服务B中办法的需要，即近程过程调用。 要想让服务A调用服务B中的办法，最先想到的就是通过HTTP申请实现。是的，这是很常见的，例如服务B裸露Restful接口，而后让服务A调用它的接口。基于Restful的调用形式因为可读性好（服务B暴露出的是Restful接口，可读性当然好）而且HTTP申请能够通过各种防火墙，因而十分不错。 然而，如后面所述，基于Restful的近程过程调用有着显著的毛病，次要是效率低、封装调用简单。当存在大量的服务间调用时，这些毛病变得更为突出。 服务A调用服务B的过程是利用间的外部过程，就义可读性晋升效率、易用性是可取的。基于这种思路，RPC产生了。 通常，RPC要求在调用方中搁置被调用的办法的接口。调用方只有调用了这些接口，就相当于调用了被调用方的理论办法，非常易用。于是，调用方能够像调用外部接口一样调用近程的办法，而不必封装参数名和参数值等操作。 那要想实现这个过程该怎么办呢？别急，咱们一步一步来。 首先，调用方调用的是接口，必须得为接口结构一个假的实现。显然，要应用动静代理。这样，调用方的调用就被动静代理接管到了。 第二，动静代理接管到调用后，应该想方法调用近程的理论实现。这包含上面几步： 辨认具体要调用的近程办法的IP、端口将调用办法的入参进行序列化通过通信将申请发送到近程的办法中这样，近程的服务就接管到了调用方的申请。它应该： 反序列化各个调用参数定位到理论要调用的办法，而后输出参数，执行办法依照调用的门路返回调用的后果整个过程如下所示。 这样，RPC操作就实现了。 调用方调用外部的一个办法，然而被RPC框架移花接木为近程的一个办法。之间的通信数据可读性不须要好，只须要RPC框架能读懂即可，因而效率能够更高。通常应用UDP或者TCP作为通信协定，当然也能够应用HTTP。例如上面的示例中，为了保障实现最简略，就用了HTTP进行通信。 讲到这里，RPC的产生起因、原理应该分明了。为了让大家真的明确，我写了一个真的是最最简略的RPC实现。把它放到了： https://github.com/yeecode/EasyRPCgithub.com 它蕴含一个客户端，一个服务端。客户端只有调用本身外部的接口，就通过这个小的RPC实现调用到了服务端的办法。 上面是客户端的代码，看着类有点多，其实代码不长。其中的RPC代码实现实现动静代理、近程调用参数序列化、近程调用发动、近程调用后果反序列化的工作。 RPC客户端 上面是服务端的代码，代码更少，实现近程调用接管、调用参数反序列化、调用理论触发、调用后果序列化的工作。 RPC服务端 这样，一个RPC小框架就做完了，并不简单。 所以，不要被RPC吓到，它就是让一个利用调用另一个利用中办法的一种实现形式。与调用近程接口区别不大，条条大路通罗马。 再说一次，不是说RPC好，也不是说HTTP好，两者各有千秋。实质上，两者是可读性和效率之间的抉择，通用性和易用性之间的抉择。最终谁能倒退更好，很难说。 要问我站谁？我依据业务场景，灵便站位…… 如果还有什么没说分明，能够留言探讨。

跨域 跨域总结工夫：2020年9月2日 跨域产生起因-浏览器同源策略1.1 同源ip、协定、端口号 解决方案2.1 CORS后端配置：` res.setHeader("Access-Control-Allow-Origin", "http://127.0.0.1:8080")// res.setHeader("Access-Control-Allow-Origin", "*")res.setHeader("Access-Control-Allow-Credentials", "true")` // 配置了 withCredentials = true时，必须在后端减少 response 头信息Access-Control-Allow-Origin，且必须指定域名，而不能指定为*！！！ 前端配置：须要携带cookie axios.defaults.withCredentials = true 注意事项： 配置了 withCredentials = true时，必须在后端减少 response 头信息Access-Control-Allow-Origin，且必须指定域名，而不能指定为*！！！ `res.setHeader("Access-Control-Allow-Credentials", "true") res.setHeader("Access-Control-Allow-Origin", "http://127.0.0.1:8080")`

每个时代，都不会亏待会学习的人。大家好，我是 yes。 HTTP 协定在当今的互联网堪称是随处可见，始终默默的在背地反对着网络世界的运行，对于咱们程序员来说 HTTP 更是相熟不过。 素日里咱们都说架构是演进的，需要推动着技术的迭代、更新和提高，对于 HTTP 协定来说也是如此。 不知你是否有想过 HTTP 协定是如何诞生的，一开始是怎么的，又是怎么一步一步倒退到明天的 HTTP/3 ? 其中经验了哪些鲜为人知的机密？ 明天我就想和大家一起来看一看 HTTP 的演进之路，来看看它是如何从一个小宝宝成长为当初统治互联网的存在。 不过在此之前，咱们先简略的看看互联网的始祖-阿帕网的一段小历史，还是很乏味的。 互联网的始祖-阿帕网在 1950 年代，通信研究者们意识到不同计算机用户和网络之间的须要通信，这促使了分布式网络、排队论和封包交互的钻研。 在1958 年2月7日，美国国防部长尼尔 · 麦克尔罗伊公布了国防部 5105.15 号指令，建设了高级钻研计划局(ARPA) 。 ARPA 的外围机构之一 IPTO（信息处理处）资助的一项钻研导致了阿帕网的开发。 咱们来看看这段历史。 在 1962 年，ARPA 的主任延聘约瑟夫·利克莱德负责 IPTO 的第一任主任，他是最早预见到古代交互计算及其在各种利用的人之一。 IPTO 赞助了先进的计算机和网络技术的钻研，并委托十三个钻研小组对人机交互和分布式系统相干技术进行钻研。每个小组取得的估算是失常钻研补助金的三十至四十倍。 这就是财大气粗啊，钻研人员必定是干劲十足！ 在 1963 年利克莱德赞助了一个名为 MAC 的钻研我的项目，该我的项目旨在摸索在分时计算机上建设社区的可能性。 这个我的项目对 IPTO 和更宽泛的钻研界产生了长久的影响，成为宽泛联网的原型。 并且利克莱德的寰球网络愿景极大地影响了他在 IPTO 的继任者们。 1964 年利克莱德跳槽到了 IBM，第二任主任萨瑟兰上线，他创立了革命性的 Sketchpad 程序，用于存储计算机显示器的内存，在 1965 年他与麻省理工学院的劳伦斯 · 罗伯茨签订了 IPTO 合同，以进一步倒退计算机网络技术。 随后，罗伯茨和托马斯 · 梅里尔在麻省理工学院的 TX-2 计算机和加利福尼亚的 Q-32 计算机之间，通过拨号电话连贯实现了第一个数据包替换。 ...

http状态码分类1xx服务器收到申请2xx申请胜利3xx重定向4xx客户端谬误5xx服务端谬误常见状态码200 胜利301 永恒重定向302 长期重定向304资源未被批改404资源未找到403没有权限500服务器谬误504网关超时methods申请形式get获取数据post新建数据patch/put更新数据delete删除数据Restful API传统的API设计：把每个url当做一个性能Restful API：把每个url当做一个惟一的资源 http headers—常见的Request headersAccept浏览器可接管的数据格式Accept-Encoding浏览器可接管的压缩算法，如gzipAccept-Language浏览器可接管的语言，如zh-CNconnection-keep alive 一次TCP连贯重复使用cookieHostUser-Agent(简称UA)浏览器信息Content-type 发送数据格式，如application/jsonhttp headers—常见的Response headersContent-type 返回数据格式，如application/jsonContent-length返回数据的大小，多少字节Content-Encoding返回数据的压缩算法，如gzipset-Cookiehttp缓存—Cache control强制缓存在response headers中管制强制缓存的逻辑 cache control 的值max-age设置过期的值，单位为秒no-cache不缓存no-store 不必本地缓存private只容许最终用户做缓存public容许两头的一些路由等做缓存http缓存—协商缓存（比照缓存）服务器端缓存策略

这篇笔记用来记录如何申请收费的 SSL 证书，通过本文介绍的形式所申请的证书有效期只有三个月，请审慎抉择。 筹备像这类提供收费 SSL 证书的网站十分多，这里我抉择的平台是 FreeSSL.cn 。 在正式开始之前，你得筹备一个邮箱，注册 一个 FreeSSL.cn 账号，而后登录。 将须要申请证书的域名填写在输入框中，抉择多域名通配符，而后点击创立收费的SSL 证书。 我这里抉择的是泛域名，依据你本人的理论状况，去创立相应子域名的证书： example.com：主域名*.example.com：泛域名 抉择浏览器生成。 点击确认创立。 增加TXT 记录关上须要申请 SSL 证书的域名治理后盾，找到 DNS 治理。 增加 TXT 验证，将方才的记录值与TXT 记录增加到对应的TXT 类型。 留神⚠️：记录值辨别大小写。 检测是否配置胜利。 在实现验证之前不要来到以后页面，验证胜利之后，点击验证。 如果配置胜利没问题，就能够点击验证，下载证书就实现了。 留神⚠️：应用此形式获取的证书，有效期只有三个月。

1 做根本页面，先把数据导入，还有相干依赖，8个。1.1首先改配置文件2.1 先创立管制类，负责管理所有的页面申请。能够启动测试了，看一看，根底页面是否搭建实现。这是应该查问到 的界面，以及接下来的思路。日志治理就是一个dom元素。接下来就是技术解决了。点击发动异步申请。操作：1 在starter.html注册事件。先获取日志治理的Id（load-log-id），就是在F12界面关上去看。在这个按钮点击注册函数。下一句解析，jquery中load函数向服务器发送ajax函数，间接把url加载过去的函数更新指定的的那局部，如图红色点。对应的写函数，上面有错，少写和箭头那么url是哪一部分，加进去，要加载哪一部分到指定地位。这个页面，心愿放在templates，去解决，所以放那里。这个目录下，是不能间接拜访的，所以要去配置一个Controller了。这个是页面申请，所有的页面申请都是在PageController外面。操作：对应心愿到的路劲。能够启动测试。日志列表页面加载实现，就是log-list，还心愿日志页面j加载实现之后，在把分页页面显示在这里，部分刷新，ajax。回到PageController里增加一个返回的办法这个是服务端，上面须要在客户端log-list。log-list页面里是有一块区域来贮存分页元素的因为其余中央都须要用，所以写个函数拿出去。让所有的都能够拿到分页页面，加载到doPageUI。作为全副的一部分，所以能够应用$.优化版写法，js加载后，在去实现这个函数。操作：能够把starter.html共性的提取进去，因为，都是加载不同模块的id，不日日志治理，菜单治理这些，所以能够提取共性，第二张代码。在增加，只须要改括号外面就能够了。抉择指标，能够基于id去选，也能够在class前面的就是类选择器，能够拿一个也能够拿两个!看不懂，去F12写一写bc2735d75c10d802a8988254dad339d.png那个#id就是下面那个load—log-id一样的跟着时序图去写。上面是一样的写法接下做的步骤!设计原理：从数据层开始写，放在一个pojo外面去贮存，通过list去，不是把所有记录都取出来，按页去取，因为不可能把所有记录都显示进去，那就得计算分页，那么就须要总记录数，先把总记录数取出来，能力分页。@Repository是形容类，代表是在数据层pojo。数据层要返回业务层接口那边，在业务层就波及到了计算，给了一个总记录数就能计算总页数。在业务层收到了List汇合和row count两个数据所以还须要进行封装（也能够用map）。list是传到了业务层，接口这边，业务层返回到管制层也须要进行数据封装，因为还有谬误的数据，是失常还是谬误，所以也须要封装。让客户端须要辨识进去，加一个状态码。当前页是基于点击事件，进行扭转的，比方首页，上一页，下一页，尾页，而总记录数是数据库总记录数，总页数依据总记录数去计算，不是查问进去的。操作：1 封装数据库返回数据!所有封装进行序列化接口，将对象转化为字节不便贮存或传输d0e6b84ae02b99ae079d1d0f655fb05.png2接口这个是须要查问进去的一行记录映射一个对象，参数的设计应该有它的名字，起始地位，从哪里开始查，依据别设计写。3建设映射文件所以的select都必须有一个resultType，这是一行映射一个记录的意思名字跟记录相匹配的，就记录一下。limit从什么地位开始取，去几条。order by降序排序能够提取共性，能够测试。建设测试类取出admit的记录，从0开始，拿3条g](/img/bVbOIk1)数据层完结，开始业务层。操作：在接口写查询方法。参数，返回值的思考看客户端会传什么值，比方以后的页码，用户名啊。不晓得返回值是啥就用Object。这个返回值要封装数据层返回的数据，以及通过计算的页码值，所以能够创立一个对象，在建设一个类（解决要返回的值）。如果返回值很大。int值满足不了，能够改long。records当前页记录。psgeCount总页数，rowCount总记录数，须要计算总页数还须要一个每页显示多少记录pageSize.还会显示以后页码值。优化：让其它除了日志模块也可应用!1599985608(1).png变成泛型类T就是一个变量!，当前能够写多个对应的也要改，传进来的是SysLog!这个返回值就是封装查问和计算结果的一个分页对象1599989507(1).png持续操作：建设impl实现类startIndex开始页的数，pageCurrent当前页码数，pageSize一页记录多少。而后须要封装这个数据，所以创建对象。通过算法求总页数，总记录数除以每页显示数。返回的是po。如果，拿到的后果是0，就没必要执行上面的程序，所以。username是能够为空的，而pageCurrent是不能为空的!这个抛出异样是非查看异样1599990933.png。这个到运行时才会报错，所以创立一个类去继承RuntimeException，也要序列化，解决异样能够按父类来生成构造函数不晓得就都生成。要简化流程，在PageObject设置有参和无的构造函数，@NoArgsConstructor就是无参结构。因为这个其余的页码也是能够应用的 ，所以在公共最好。放在构造方法外部去计算，意思是把计算那局部也放在公共里去持续测试类测试业务层把数据给管制层了，数据有对有谬误的。传统写法，为了给数据增加一个状态，减少一个类响应到管制端。封装调用简略。之后就能够扭转返回值为JsonResult进阶，不做try，catch的重复性工作，解决异样的web包，加非凡标记。。。测试方法客户端的出现哪里须要出现数据页面加载实现之后还想进行退出页面操作间接加函数在原有地位。在log_list页面在!72cf8cb13239706a0d086c69006f1c6.png在配置页面，page.html文件下写公共的，通过类选择器取得数据。前面就是事件处理了。

详解输出网址点击回车，后盾到底产生了什么。透析 HTTP 协定与 TCP 连贯之间的千头万绪的关系。把握为何是三次握手四次挥手？ time_wait 存在的意义是什么？全面图解重点问题，再也不必放心面试问这个问题。 大抵流程 URL 解析。DNS 查问。TCP 连贯。服务器解决申请。客户端接管 HTTP 报文响应。渲染页面重点来了： 如何了解 TCP 的三次握手与四次挥手？每次握手客户端与服务端是怎么的状态？为何挥手会呈现 2MSL，遇到大量 Socket 处在 TIME_WAIT 或者 CLOSE_WAIT 状态是什么问题？三次握手与四次挥手的过程是怎么的？HTTP 的报文格式又是怎么的？持续浏览本文，且听码哥字节答疑解惑，微信搜寻 “码哥字节”，关注公众号更多硬核。 URL 解析地址解析：首先判断你输出的是一个非法的 URL 还是一个待搜寻的关键词，并且依据你输出的内容进行主动实现、字符编码等操作。 HSTS 因为安全隐患，会应用 HSTS 强制客户端应用 HTTPS 拜访页面。详见：你所不晓得的 HSTS[1]。 其余操作 浏览器还会进行一些额定的操作，比方安全检查、拜访限度（之前国产浏览器限度 996.icu）。 查看缓存 DNS 查问 浏览器缓存：先查看是否在缓存中，没有则调用零碎库函数进行查问。操作系统缓存：操作系统也有本人的 DNS 缓存，但在这之前，会向查看域名是否存在本地的 Hosts 文件里，没有则向 DNS 服务器发送查问申请。路由器缓存。ISP DNS 缓存：ISP DNS 就是在客户端电脑上设置的首选 DNS 服务器，它们在大多数状况下都会有缓存。根域名服务器查问 在后面所有步骤没有缓存的状况下，本地 DNS 服务器会将申请转发到互联网上的根域，上面这个图很好的诠释了整个流程： 须要留神的的是： 递归形式：一路查上来两头不返回，失去最终后果才返回信息（浏览器到本地 DNS 服务器的过程）迭代形式，就是本地 DNS 服务器到根域名服务器查问的形式。什么是 DNS 劫持前端 dns-prefetch 优化TCP 连贯建设与断开TCP/IP 分为四层，在发送数据时，每层都要对数据进行封装： ...

Http介绍超文本传输协定（HTTP，HyperText Transfer Protocol)是互联网上利用最为宽泛的一种网络协议。所有的WWW文件都必须恪守这个规范。设计HTTP最后的目标是为了提供一种公布和接管HTML页面的办法。1960年美国人Ted Nelson构思了一种通过计算机解决文本信息的办法，并称之为超文本（hypertext）,这成为了HTTP超文本传输协定规范架构的倒退根基。以上并非此次文章重点，更具体的http介绍请移步 www.baidu.com Http是一种网络协议，而且是无状态的超文本协定，基于Tcp/Ip协定的应用层协定。 我要IP当用户申请某个域名的资源，比方在浏览器敲入http://www.qq.com的时候，浏览器首先会依据输出的域名去查问IP地址。去哪查呢？这里就须要引入DNS的概念，能够把DNS看做是域名映射IP的账簿。当客户端发送一个DNS申请的时候，首先本地的DNS服务器会接管到申请，会在本地先查问缓存中有没有以后域名和IP的映射关系，如果有则间接返回IP信息，如果没有，则会询问其余DNS服务器，这里简略说一下网络上DNS服务器的构造，DNS服务器在网络上是树状构造的，存在一个根服务器，根服务器的子节点是一级域名服务器（比方 .com, .cn），一级域名服务器的子节点又称为权威（权限）DNS服务器 当本地DNS服务器没有相干查问信息的时候会按照以上树的程序查问域名和IP的对应关系，查到之后会缓存到本地DNS，这个过程最终的后果就是获取到相干域名对应的IP地址，如果客户端输出的是IP地址信息，则省略了以上查问IP的过程了。 拜访互联网的任何网站实质上都是根据IP来寻址的。建设Tcp连贯当一个http申请收回之后，并且获取到了正确的服务器IP地址，这个时候就能够建设连贯了。有一点须要明确：http协定是基于Tcp协定的。所以第一步就须要建设Tcp连贯，这个过程就是很多网络文章所说的三次握手：Client：Hi，我是 Client。 Server：您好 Client，我是 Server。 Client：您好 Server... 这里是三次握手能够以这样的程序来示意：client的问->server的答->client的答有的面试官无聊会问为什么是三次握手而不是两次或者四次五次呢？你能够了解，当两个人A和B要想互相联系的时候，最简略的形式就是A发问而后能收到B的答复，B发问能收到A的答复。这也是三次握手的外围。 平时所说的Tcp是面向连贯的，这里的连贯其实是单方约定肯定格局来进行通信的过程（包含发包的程序，buffer的大小等约定），在逻辑上如同是维持了一条连贯而已。我要出网关一旦Tcp连贯建设起来，http申请就能够组织数据发送报文了。目前http协定的版本大部分是1.1，在这个版本中有一个属性 Keep-Alive，这个属性标示要放弃此http连贯建设的TCP连贯，默认是开启的。 网络上有文章大篇幅形容http的长连贯信息，其实是谬误的说法，长连贯是针对tcp连贯，http连贯关上keepalive选项只不过放弃了tcp连接不断开而已。HTTP 的报文大略分为三大部分。第一局部是申请行，第二局部是申请头（header），第三局部是申请体（body）。这里具体的http协定其余概念不再展开讨论，因为内容有点多。http协定位于应用层，所以要发送的报文首先会把http协定相干的内容蕴含在包中，而后传给下一层。 下一层是传输层，这一层次要有两个协定：Tcp和Udp，http协定抉择的是tcp协定，tcp会有两个端口信息，一个是源端口，一个是指标端口，比方http申请个别指标端口是80。传输层把端口信息封装结束，接着把申请包传给网络层。 网络层的协定是IP协定，在这一层会把源Ip地址和指标IP地址封装进去（指标IP就是申请的网站ip，查问dns取得）。 操作系统晓得了要发往的IP地址，会判断这个ip是否在本地局域网内（依据子网掩码来判断），如果不在的话，则须要网关把这个申请发送进来（网关的ip个别是DHCP协定配置的）。操作系统怎么获取网关在哪呢？这个过程基本上靠的是播送，利用的协定是ARP协定，当局域网内的所有设施接管到ARP协定的内容之后会判断ip是否和网关ip雷同，如果雷同就会回复，通过这个过程，零碎找到了网关，获取到了网关的MAC地址，并把网关的MAc地址和本机的MAc地址封装进申请包，发给下一层MAC层,最初网卡把音讯发往网关。 MAC地址次要用在同一个局域网内定位某个计算机，是在局域网内才无效的地址达到指标服务器申请包达到网关,网关会依据音讯的MAC地址来判断是否和本人的mac雷同，如果雷同则把音讯接管下来。接着会判断音讯中指标IP，如果指标IP未在本人的局域网中，则须要依据本人的路由规定把音讯发送给下一个相连的网关。网关和网关之间是通信的，至于网关怎么计算出最优门路这里不再开展。咱们以常见的家庭路由器为例，每个路由器的网关IP其实是运营商给调配的，并且网络包发送进来个别都是采纳批改IP的形式（NAT）。具体步骤： 网关查看指标IP是否在本人的局域网内，如果不在，则获取要传送的下一个网关mac和IP，把指标IP和mac批改为下一个网关的IP和mac，并把起源IP和mac批改为以后网关的IP（外网IP）和mac。下一个网关收到音讯，首先查看mac是否和本人匹配，如果匹配接会查看指标IP是否在本人的局域网内，如果不在则反复以上步骤反复以上步骤直到指标服务器所在的网关。指标服务器所在的网关收到音讯，会判断进去以后的指标IP在我的局域网范畴，就不会在跳跃下一个网关，而是向局域网内发ARP申请寻找指标服务器，指标服务器收到申请会响应，网关会把具体的申请发送给指标服务器。指标服务器收到音讯会解析申请的音讯，在比照完mac和IP信息之后，会失去端口的信息，指标服务器则在本机寻找监听这个端口的程序，http服务器很有可能是nginx或者其余web服务器。申请通过端口传送给具体的解决的程序，程序会解析http申请的内容，依据内容作出相应的回复。申请依照以上所有步骤把响应返回给申请方（网关路由器会记住起源门路），至此一个http申请完结。网关（路由器）之间通过路由表来决定下一个跳跃的网关地址写在最初以上只是http申请的一个大略过程，其实每一步都非常复杂，没有具体开展。比方：路由协定、ip的调配 等等。 支付架构师进阶材料大礼包

HTTP总结什么是HTTP协定HTTP协定是指规定浏览器和服务器之间的通信规定/标准。次要规定了浏览器发送给服务器申请的格局和服务器响应给浏览器的信息格式HTTP工作时遵循的根本规定一次申请，一次响应申请只能由浏览器收回，服务器只能被动接管，并依据申请做出响应HTTP详解HTTP申请蕴含：申请行，若干申请头，申请实体内容 1.申请行GET /news/hello.html HTTP/1.1// GET申请形式 // /news/hello.html 申请的门路 // 所遵循的协定和版本2.申请头中保留的是KEY-VALUE构造Host：localhost -- 告诉服务器，浏览器要申请的是哪一台虚拟主机。Accept：text/html, appliaction/xhtml+xml,... -- 告诉服务器，浏览器能接管的响应数据类型。...3，申请实体如果是get申请，申请实体为空。如果实post申请，申请实体才有内容。 HTTP响应蕴含：状态行，若干响应头（key-value构造），响应实体 1.状态行HTTP/1.1 200 OK// HTTP/1.1 示意响应所遵循的版本和协定// 200：状态码，示意服务器对申请的后果// OK:和状态码对应*状态码：200：示意申请解决胜利302：示意申请重定向（即须要进一步申请能力取得资源）304/307：示意告诉浏览器应用缓存404：示意浏览器申请的资源不存在500：示意服务器在解决浏览器的申请时抛出异样 2.若干响应头3.响应实体*响应实体就是浏览器所申请的资源。 GET和POST的区别次要体现在申请参数传输上的区别 1.GET申请是把申请参数拼接在URL的前面，间接显示在浏览器中，十分不平安；GET申请将数据拼接在URL前面，但数据量是有限度的。 2.POST申请是把申请通过申请实体传递给服务器的，不会显示在浏览器上，因而平安；POST申请通过申请实体提交，实践上是有限的。 Tomcat整合到eclipse略

开篇介绍大家好，我是Java最全面试题库的提裤姐，明天这篇是计算机网络，次要总结了计算机网络相干的面试题；在后续，会沿着第一篇开篇的常识线路始终总结上来，做到日更！如果我能做到百日百更，心愿你也能够跟着百日百刷，一百天养成一个好习惯。 说一下TCP/IP四层模型TCP/IP协定是美国国防部高级打算研究局为实现ARPANET互联网而开发的。 网络接口层（链路层）：包含操作系统中的设施驱动程序、计算机中对应的网络接口卡网络层（互连层、网际层）：解决分组在网络中的流动，比方分组的选路。负责IP寻址，宰割和组装数据包，路由抉择等。运输层：次要为两台主机上的利用提供端到端的通信应用层：负责解决特定的应用程序细节。说一下OSI七层模型 物理层：次要定义物理设施规范，如网线的接口类型、光纤的接口类型、各种传输介质的传输速率等。它的次要作用是传输比特流。单位：比特、数据位、流、比特流数据链路层：次要将从物理层接管的数据进行 MAC 地址（网卡的地址）的封装与解封装。在这一层工作的设施是交换机，数据通过交换机来传输。 单位：帧、数据帧`网络层：次要将从上层接管到的数据进行 IP 地址（例 192.168.0.1)的封装与解封装。在这一层工作的设施是路由器。单位：数据报、数据包、分组、包传输层：定义了一些传输数据的协定和端口号（WWW 端口 80 等），如：TCP（传输控制协议，传输效率低，可靠性强，用于传输可靠性要求高，数据量大的数据），UDP（用户数据报协定，与 TCP 个性恰恰相反，用于传输可靠性要求不高，数据量小的数据，如 QQ 聊天数据就是通过这种形式传输的）。 次要是将从上层接管的数据进行分段进行传输，达到目标地址后在进行重组。单位：数据段、分段、报文段会话层：通过传输层（端口号：传输端口与接管端口）建设数据传输的通路。次要在你的零碎之间发动会话或者承受会话申请（设施之间须要相互意识能够是 IP 也能够是 MAC 或者是主机名）表示层：次要是进行对接管的数据进行解释、加密与解密、压缩与解压缩等（也就是把计算机可能辨认的货色转换成人可能能辨认的货色（如图片、声音等））应用层： 次要是一些终端的利用，比如说FTP（各种文件下载），WEB（IE浏览），QQ等。单位：报文OSI参考模型与TCP/IP参考模型对应关系及区别？共同点： 两个都是以协定栈的概念为根底，协定栈中的协定彼此相互独立；都采纳了层次结构的概念，各层性能大体类似。不同点： OSI有7层，TCP/IP有4层。TCP/IP网络层提供无连贯通信，传输层反对无连贯和面向连贯两种；OSI网络层反对面向连贯和无连贯，传输层只反对面向连贯的通信。 介绍一下TCP 三次握手和四次挥手三次握手： 为了准确无误地把数据送达指标处，TCP协定采纳了三次握手策略。用TCP协定把数据包送出去后，TCP不会对传送后的状况束之高阁，它肯定会向对方确认是否胜利送达。握手过程中应用了TCP的标记：SYN和ACK 发送端首先发送一个带SYN标记的数据包给对方。接收端收到后，回传一个带有SYN/ACK标记的数据包以示传播确认信息。最初，发送端再回传一个带ACK标记的数据包，代表“握手”完结。留神：若在握手过程中某个阶段莫名中断，TCP协定会再次以雷同的程序发送雷同的数据包四次挥手： 断开一个TCP连贯则须要四次挥手 第一次挥手：被动敞开方发送一个FIN，用来敞开被动方到被动敞开方的数据传送，也就是被动敞开方通知被动敞开方：我曾经不 会再给你发数据了(当然，在fin包之前发送进来的数据，如果没有收到对应的ack确认报文，被动敞开方仍然会重发这些数据)，然而，此时被动敞开方还可 以承受数据第二次挥手：被动敞开方收到FIN包后，发送一个ACK给对方，确认序号为收到序号+1（与SYN雷同，一个FIN占用一个序号）第三次挥手：被动敞开方发送一个FIN，用来敞开被动敞开方到被动敞开方的数据传送，也就是通知被动敞开方，我的数据也发送完了，不会再给你发数据了第四次挥手：被动敞开方收到FIN后，发送一个ACK给被动敞开方，确认序号为收到序号+1，至此，实现四次挥手TCP和UDP的区别？TCP（Transmission Control Protocol，传输控制协议）是基于连贯的协定，也就是说，在正式收发数据前，必须和对方建设牢靠的连贯。一个TCP连贯必须要通过三次“对话”能力建设起来UDP（User Data Protocol，用户数据报协定）是与TCP绝对应的协定。它是面向非连贯的协定，它不与对方建设连贯，而是间接就把数据包发送过来！ UDP实用于一次只传送大量数据、对可靠性要求不高的应用环境TCP如何进行流量管制？TCP协定利用窗口机制实现流量管制；TCP连贯建设时，单方都为之调配了固定大小的缓冲空间；TCP的接收端只容许另一端发送其缓冲区所能接收的数据： 接收端在给发送端发送确认段时，通告接管窗口大小；发送端在接下来发送数据段时，确保未确认段的应用层数据总量不超过接收端通告的接管窗口大小，从而确保接收端不会产生缓存溢出。什么是拥塞管制？TCP是如何进行拥塞管制的？拥塞拥塞是指太多主机以太快的速度向网络中发送太多的数据，超过了网络解决能力，导致大量数据分组“拥挤”在网络中间设备（如路由器）队列中期待转发，网络性能显著降落的景象。拥塞的结果：①数据分组通过网络的时延显著减少。②因为队列满导致大量分组被抛弃。 拥塞管制拥塞管制就是通过正当调度、标准、调整向网络中发送数据的主机数量、发送速率或数据量，以防止拥塞或尽快打消已产生的拥塞。 TCP拥塞管制：从端到端的角度，揣测网络是否产生拥塞，如果推断网络产生拥塞，则立刻将数据发送速率降下来，以便缓解网络拥塞。①窗口机制：通过调节窗口的大小实现对发送数据速率的调整。②窗口调整的根本策略：AIMD（Additive Increase,Multiplicative Decrease）加性减少，乘性缩小；网络未产生拥塞时，逐步“加性”减少窗口大小，当网络拥塞时“乘性”疾速减小窗口大小。③TCP的拥塞控制算法：包含了慢启动、拥塞防止、疾速重传和疾速复原4局部。 UDP如何实现可靠性传输？传输层无奈保证数据的牢靠传输，只能通过应用层来实现。实现的形式能够参照tcp可靠性传输的形式，只是实现不在传输层，实现转移到了应用层。实现确认机制、重传机制、窗口确认机制。 如果不利用linux协定栈以及下层socket机制，本人通过抓包和发包的形式去实现可靠性传输，那么必须实现如下性能： 发送：包的分片、包确认、包的重发接管：包的调序、包的序号确认注： ①给数据包编号，依照包的程序接管并存储； ②接收端接管到数据包后发送确认信息给发送端，发送端接管确认数据当前再持续发送下一个包，如果接收端收到的数据包的编号不是冀望的编号，则要求发送端从新发送。 目前利用udp实现了牢靠的数据传输别离为RUDP、RTP、UDT。面向连贯和非面向连贯的服务的特点是什么？ 面向连贯的服务，通信单方在进行通信之前，要先在单方建设起一个残缺的能够彼此沟通的通道，在通信过程中，整个连贯的状况始终能够被实时地监控和治理。 非面向连贯的服务，不须要事后建设一个联系两个通信节点的连贯，须要通信的时候，发送节点就能够往网络上发送信息，让信息自主地在网络下来传，个别在传输的过程中不再加以监控。 Http和Https的区别Http协定运行在TCP之上，明文传输，客户端与服务器端都无奈验证对方的身份；Https是身披SSL(Secure Socket Layer)外壳的Http，运行于SSL上，SSL运行于TCP之上，是增加了加密和认证机制的HTTP。 二者之间存在如下不同： 端口不同：Http与Http应用不同的连贯形式，用的端口也不一样，前者是80，后者是443；资源耗费：和HTTP通信相比，Https通信会因为加减密解决耗费更多的CPU和内存资源；开销：Https通信须要证书，而证书个别须要向认证机构购买；Https的加密机制是一种共享密钥加密和公开密钥加密并用的混合加密机制。HTTP申请报文和响应报文的构造是怎么的？申请报文：从客户向服务器发送申请报文 HTTP典型的申请办法有： GET：申请读取由URL所标识的信息HEAD：申请读取由URL所标识的信息的首部，毋庸在响应报文中蕴含对象。POST：给服务器增加信息（例如：正文）OPTION：申请一些选项的信息PUT：在指明的URL下存储一个文档响应报文：从服务器到客户的答复HTTP状态码： 1xx：信息提醒；通告信息，可能还须要进一步交互。2xx：胜利；胜利实现客户申请的操作，并进行响应3xx：重定向；示意资源已移走，须要向新的URL发送申请4xx：客户端谬误；因为客户申请谬误，无奈胜利响应5xx：服务端谬误；因为服务端谬误，无奈胜利响应IP地址有哪些分类？A类地址(1~126)：网络号占前8位，以0结尾，主机号占后24位。B类地址(128~191)：网络号占前16位，以10结尾，主机号占后16位。C类地址(192~223)：网络号占前24位，以110结尾，主机号占后8位。D类地址(224~239)：以1110结尾，保留位多播地址。E类地址(240~255)：以1111结尾，保留位今后应用。 ARP地址解析协定的工作过程？通过IP地址取得物理地址，是设施通过本人晓得的IP地址来取得本人不晓得的物理地址的协定。 工作过程： 每个主机都会在本人的 ARP 缓冲区中建设一个 ARP 列表，以示意 IP 地址和 MAC 地址之间的对应关系当源主机要发送数据时，首先查看 ARP 列表中是否有对应 IP 地址的目标主机的 MAC 地址，如果有，则间接发送数据，如果没有，就向"本网段"的所有主机发送 ARP 数据包，该数据包包含的内容有：源主机 IP 地址，源主机 MAC 地址，目标主机的 IP 地址。 当本网络的所有主机收到该 ARP 数据包时，首先查看数据包中的目标主机 IP 地址是否是本人的 IP 地址，如果不是，则疏忽该数据包，如果是，则首先从数据包中取出源主机的 IP 和 MAC 地址写入到 ARP 列表中，如果曾经存在，则笼罩，而后将本人的 MAC 地址写入 ARP 响应包中，通知源主机本人是它想要找的 MAC 地址。 源主机收到 ARP 响应包后。将目标主机的 IP 和 MAC 地址写入 ARP 列表，并利用此信息发送数据。如果源主机始终没有收到 ARP 响应数据包，示意 ARP 查问失败。播送发送ARP申请，单播发送 ARP 响应。DNS（Domain Name System）域名零碎的工作原理？当 DNS 客户机须要在程序中应用名称时，它会查问 DNS 服务器来解析该名称。客户机发送的每条查问信息包含三条信息： ...

HTTP协定（HyperText Transfer Protocol，超文本传输协定）是互联网上利用最为宽泛的一种网络协议，用于从WWW服务器传输超文本到本地浏览器的传输协定。它能够使浏览器更加高效，使网络传输缩小。它不仅保障计算机正确疾速地传输超文本文档，还确定传输文档中的哪一部分，以及哪局部内容首先显示(如文本先于图形)等。 HTTP是客户端浏览器或其余程序与Web服务器之间的应用层通信协议。在Internet上的Web服务器上寄存的都是超文本信息，客户机须要通过HTTP协定传输所要拜访的超文本信息。HTTP蕴含命令和传输信息，不仅可用于Web拜访，也能够用于其余因特网/内联网利用零碎之间的通信，从而实现各类利用资源超媒体拜访的集成。 HTTP协定工作流程客户端和服务器之间建设一条连贯连贯建设后，客户端向服务器发动一个申请（request）服务器收到一个申请后，给客户端一个响应（应答，response）客户端收到响应后做进一步解决HTTP申请办法GET申请会向数据库发索取数据的申请，从而来获取信息，该申请就像数据库的select操作一样，只是用来查问一下数据，不会批改、减少数据，不会影响资源的内容，即该申请不会产生副作用。无论进行多少次操作，后果都是一样的。PUT申请是向服务器端发送数据的，从而扭转信息，该申请就像数据库的update操作一样，用来批改数据的内容，然而不会减少数据的品种等，也就是说无论进行多少次PUT操作，其后果并没有不同。POST申请同PUT申请相似，都是向服务器端发送数据的，然而该申请会扭转数据的品种等资源，就像数据库的insert操作一样，会创立新的内容。简直目前所有的提交操作都是用POST申请的。DELETE申请顾名思义，就是用来删除某一个资源的，该申请就像数据库的delete操作就像后面所讲的一样，既然PUT和POST操作都是向服务器端发送数据的，那么两者有什么区别呢。。。POST次要作用在一个汇合资源之上的（url），而PUT次要作用在一个具体资源之上的（url/xxx），艰深一下讲就是，如URL能够在客户端确定，那么可应用PUT，否则用POST。 综上所述，咱们可了解为以下： 1、POST /url 创立 2、DELETE /url/xxx 删除 3、PUT /url/xxx 更新4、GET /url/xxx 查看Http定义了与服务器交互的不同办法，最根本的办法有4种，别离是GET，POST，PUT，DELETE。URL全称是对立资源定位符，咱们能够这样认为：一个URL地址，它用于形容一个网络上的资源，而HTTP中的GET，POST，PUT，DELETE就对应着对这个资源的查，改，增，删4个操作 #### 申请形式: get与post申请 GET提交的数据会放在URL之后，也就是申请行外面，以?宰割URL和传输数据，参数之间以&相连，如EditBook?name=test1&id=123456.（申请头外面那个content-type做的这种参数模式，前面讲） POST办法是把提交的数据放在HTTP包的申请体中.GET提交的数据大小有限度（因为浏览器对URL的长度有限度），而POST办法提交的数据没有限度.GET与POST申请在服务端获取申请数据形式不同，就是咱们本人在服务端取申请数据的时候的形式不同了，这句废话昂。HTTP申请报文格式HTTP申请报文由3局部组成（申请行+申请头+申请体）： ①是申请办法，HTTP/1.1 定义的申请办法有8种：GET、POST、PUT、DELETE、PATCH、HEAD、OPTIONS、TRACE,最常的两种GET和POST，如果是RESTful接口的话个别会用到GET、POST、DELETE、PUT。 ②为申请对应的URL地址，它和报文头的Host属性组成残缺的申请URL ③是协定名称及版本号。 ④是HTTP的报文头，报文头蕴含若干个属性，格局为“属性名:属性值”，服务端据此获取客户端的信息。 ⑤是报文体，它将一个页面表单中的组件值通过param1=value1&param2=value2的键值对模式编码成一个格式化串，它承载多个申请参数的数据。岂但报文体能够传递申请参数，申请URL也能够通过相似于“/chapter15/user.html? param1=value1&param2=value2”的形式传递申请参数。 对照下面的申请报文，咱们把它进一步合成，你能够看到一幅更具体的结构图： HTTP响应报文格式①报文协定及版本； ②状态码及状态形容； ③响应报文头，也是由多个属性组成； ④响应报文体，即咱们真正要的“干货”。 和申请报文相比，响应报文多了一个“响应状态码”，它以“清晰明确”的语言通知客户端本次申请的处理结果。 HTTP状态码所有HTTP响应的第一行都是状态行，顺次是以后HTTP版本号，3位数字组成的状态代码，以及形容状态的短语，彼此由空格分隔。 状态代码的第一个数字代表以后响应的类型： 1xx 音讯（信息性状态码）——申请已被服务器接管，持续解决2xx 胜利（胜利状态码）——申请已胜利被服务器接管、了解、并承受3xx 重定向（重定向状态码）——须要后续操作能力实现这一申请4xx 申请谬误（客户端谬误状态码）——申请含有词法谬误或者无奈被执行5xx 服务器谬误（服务端谬误状态码）——服务器在解决某个正确申请时产生谬误HTTP和HttpsHTTP：是互联网上利用最为宽泛的一种网络协议，是一个客户端和服务器端申请和应答的规范（TCP），用于从WWW服务器传输超文本到本地浏览器的传输协定，它能够使浏览器更加高效，使网络传输缩小。 HTTPS：是以平安为指标的HTTP通道，简略讲是HTTP的平安版，即HTTP下退出SSL层，HTTPS的平安根底是SSL，因而加密的具体内容就须要SSL。 HTTPS协定的次要作用能够分为两种：一种是建设一个信息安全通道，来保障数据传输的平安；另一种就是确认网站的真实性。 HTTP协定传输的数据都是未加密的，也就是明文的，因而应用HTTP协定传输隐衷信息十分不平安，为了保障这些隐衷数据能加密传输，于是网景公司设计了SSL（安全套接字层协定）（Secure Sockets Layer）协定用于对HTTP协定传输的数据进行加密，从而就诞生了HTTPS。简略来说，HTTPS协定是由SSL+HTTP协定构建的可进行加密传输、身份认证的网络协议，要比http协定平安。 HTTPS和HTTP的区别次要如下： 1、https协定须要到ca申请证书，个别收费证书较少，因此须要肯定费用。 2、http是超文本传输协定，信息是明文传输，https则是具备安全性的ssl加密传输协定。 3、http和https应用的是齐全不同的连贯形式，用的端口也不一样，前者是80，后者是443。 4、http的连贯很简略，是无状态的；HTTPS协定是由SSL+HTTP协定构建的可进行加密传输、身份认证的网络协议，比http协定平安。 在浏览器中输出网址之后执行会产生什么？(1). 浏览器查问 DNS，获取域名对应的IP地址:具体过程包含浏览器搜寻本身的DNS缓存、搜寻操作系统的DNS缓存、读取本地的Host文件和向本地DNS服务器进行查问等。对于向本地DNS服务器进行查问，如果要查问的域名蕴含在本地配置区域资源中，则返回解析后果给客户机，实现域名解析(此解析具备权威性)；如果要查问的域名不禁本地DNS服务器区域解析，但该服务器已缓存了此网址映射关系，则调用这个IP地址映射，实现域名解析（此解析不具备权威性）。如果本地域名服务器并未缓存该网址映射关系，那么将依据其设置发动递归查问或者迭代查问； (2). 浏览器取得域名对应的IP地址当前，浏览器向服务器申请建设链接，发动三次握手； (3). TCP/IP链接建设起来后，浏览器向服务器发送HTTP申请； (4). 服务器接管到这个申请，并依据门路参数映射到特定的申请处理器进行解决，并将处理结果及相应的视图返回给浏览器； (5). 浏览器解析并渲染视图，若遇到对js文件、css文件及图片等动态资源的援用，则反复上述步骤并向服务器申请这些资源； (6). 浏览器依据其申请到的资源、数据渲染页面，最终向用户出现一个残缺的页面。 ...

本站是依据大神左耳朵耗子博客配置在此做个演绎，心愿能帮到没有配置过的敌人 配置十分的简略：3步走1. 首先关上电子子前哨基金会EFF的 Certbot的网站： https://certbot.eff.org/2.进入首页后抉择你所用的服务器软件，linux零碎名称 如：nginx centos7 在下图的两个红色框中 3.当你选好你的软件 和零碎类型，网站会加载对应你的装置配置流程。比方我的：3.1 SSH into the server 登录你的服务器3.2 启用EPEL repo 开启点击这里，自己执行了装置命令行，即可！3.3 装置 Certbot 自己一键胜利 sudo yum install certbot python2-certbot-nginx3.4 抉择你喜爱的命令装置sudo certbot --nginx 主动装置配置好https（举荐应用） sudo certbot certonly --nginx 只是取得证书，还需另行配置 sudo certbot --nginx未一键装置胜利，须要解决很多版本问题，包依赖问题，有以下命令： yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm sudo yum install certbot python2-certbot-nginx sudo certbot --nginx //装置失败 pip freeze|grep urllib3 pip uninstall urllib3 yum install python-urllib3 sudo certbot --nginx //装置失败 pip install requests pip install --upgrade pip sudo certbot --nginx //装置失败 pip install requests sudo certbot --nginx //装置失败 pip install --upgrade pyOpenSSL pip show pyOpenSSl cd /usr/lib64/python2.7/site-packages/ ll | grep 'pyOpenSSL' mv pyOpenSSL-0.13.1-py2.7.egg-info pyOpenSSL-0.13.1-py2.7.egg-info_bak pip uninstall pyOpenSSL mv pyOpenSSL-0.13.1-py2.7.egg-info pyOpenSSL-0.13.1-py2.7.egg-info_bak pip install --upgrade pyOpenSSL cd ~ sudo certbot --nginx //装置失败 pip install --upgrade --force-reinstall 'requests==2.6.0' sudo certbot --nginx //最终胜利3.5 配置定时工作 （起因：证书号只是90天无效，须要定时更行，这样能力永恒应用）网站举荐的有些看不懂，未应用 ...

前言以前在应用wireshark做协定剖析的时候，始终认为它只能抓 HTTP 的报文，所以在抓 HTTPS 包的时候始终是用的Fildder，然而有一天我忽然想抓一下HTTP2的报文看一看，Fildder就不行了，于是在一番 google 之后发现wireshark是能够反对的，只不过须要在特定的条件下才能够。 Fildder 存在的问题Fildder目前还不反对HTTP2协定，无奈看到真正的HTTP2报文，这里有些人可能会有疑难，说我明明就用Fildder抓到了HTTP2协定的报文啊，那是因为Fiddler中间人攻打服务器通过协商把协定降级成了HTTP1协定，所以实际上看到的还是的HTTP1的报文，通过上面两个图片能够直观的感触到： 不通过代理，间接拜访反对 HTTP2 的服务 通过代理拜访，进行抓包 能够看到在通过代理抓包的时候，协定变成了http/1.1。 应用 wireshark 抓取当初市面上的支流浏览器实现的 HTTP2 都是基于TLS的，也就是说要剖析HTTP2报文得先过了TLS这一关，不然只能剖析一堆加密的乱码。 wireshark反对两种形式来解密SSL/TLS报文： 通过网站的私钥通过浏览器的将 TLS 对称加密秘保留在内部文件中，以供 wireshark 加解密上面我来一一进行演示 1. 通过网站的私钥如果你想抓取的网站是你本人的，那么能够利用这种形式，因为这须要应用网站生成证书应用的私钥进行解密，就是那个 nginx 上配置的ssl_certificate_key对应的私钥文件，把它增加到 wireshark 配置中： 而后通过wireshark就能够看到明文了： 通过上图能够看到，我通过curl拜访的 https 协定的 URL，在配置了该服务器对应的私钥后能够抓取到对应的 HTTP 明文。 不过毛病也非常明显，只能剖析本人持有私钥的网站，如果他人的网站就剖析不了了，所幸的是还有第二种计划来反对。 2. 通过浏览器的 SSL 日志性能目前该计划只反对Chrome和Firefox浏览器，通过设置SSLKEYLOGFILE环境变量，能够指定浏览器在拜访SSL/TLS网站时将对应的密钥保留到本地文件中，有了这个日志文件之后wireshake就能够将报文进行解密了。 首先设置SSLKEYLOGFILE环境变量： 注：这是在 windows 零碎上进行操作的，其它操作系统同理配置wireshake，首选项->Protocls->TLS：将第一步中指定的文件门路配置好 重启浏览器，进行抓包： 同样的能够抓取到 HTTP 明文。 注：不抓包时记得把环境变量删掉，以防止性能节约和安全性问题计划二的长处非常明显，能够抓取任意网站的SSL/TLS加密的报文，惟一的毛病就是只能是浏览器反对的状况才行，而计划一能够针对任何 HTTP 客户端进行抓包。 通过 wireshake 抓取 HTTP2 报文下面都是针对TLS+HTTP1进行的抓包，市面上支流的浏览器的HTTP2都是基于TLS实现的，所以也是一样的，把TLS这层解密了天然看到的就是最原始的明文。 这里以剖析https://www.qq.com为例，为什么不是经典htts://www.baidu.com，因为百度首页至今还是HTTP/1.1协定。 应用下面的第二种计划配置好wiresharke通过http2关键字做过滤浏览器拜访https://www.qq.com查看HTTP2报文：这样就抓取到了HTTP2报文了，HTTP2 协定非常复杂，我也还在学习阶段，这里就不多说啥了。 后记wireshake 真的是一款十分弱小的网络分析工具，在HTTPS和HTTP2日渐成为支流的时候，能够用它来帮忙咱们加深对这些协定的了解，以便迎接新的时机与挑战。 ...

前言以前在应用wireshark做协定剖析的时候，始终认为它只能抓 HTTP 的报文，所以在抓 HTTPS 包的时候始终是用的Fildder，然而有一天我忽然想抓一下HTTP2的报文看一看，Fildder就不行了，于是在一番 google 之后发现wireshark是能够反对的，只不过须要在特定的条件下才能够。 Fildder 存在的问题Fildder目前还不反对HTTP2协定，无奈看到真正的HTTP2报文，这里有些人可能会有疑难，说我明明就用Fildder抓到了HTTP2协定的报文啊，那是因为Fiddler中间人攻打服务器通过协商把协定降级成了HTTP1协定，所以实际上看到的还是的HTTP1的报文，通过上面两个图片能够直观的感触到： 不通过代理，间接拜访反对 HTTP2 的服务 通过代理拜访，进行抓包 能够看到在通过代理抓包的时候，协定变成了http/1.1。 应用 wireshark 抓取当初市面上的支流浏览器实现的 HTTP2 都是基于TLS的，也就是说要剖析HTTP2报文得先过了TLS这一关，不然只能剖析一堆加密的乱码。 wireshark反对两种形式来解密SSL/TLS报文： 通过网站的私钥通过浏览器的将 TLS 对称加密秘保留在内部文件中，以供 wireshark 加解密上面我来一一进行演示 1. 通过网站的私钥如果你想抓取的网站是你本人的，那么能够利用这种形式，因为这须要应用网站生成证书应用的私钥进行解密，就是那个 nginx 上配置的ssl_certificate_key对应的私钥文件，把它增加到 wireshark 配置中： 而后通过wireshark就能够看到明文了： 通过上图能够看到，我通过curl拜访的 https 协定的 URL，在配置了该服务器对应的私钥后能够抓取到对应的 HTTP 明文。 不过毛病也非常明显，只能剖析本人持有私钥的网站，如果他人的网站就剖析不了了，所幸的是还有第二种计划来反对。 2. 通过浏览器的 SSL 日志性能目前该计划只反对Chrome和Firefox浏览器，通过设置SSLKEYLOGFILE环境变量，能够指定浏览器在拜访SSL/TLS网站时将对应的密钥保留到本地文件中，有了这个日志文件之后wireshake就能够将报文进行解密了。 首先设置SSLKEYLOGFILE环境变量： 注：这是在 windows 零碎上进行操作的，其它操作系统同理配置wireshake，首选项->Protocls->TLS：将第一步中指定的文件门路配置好 重启浏览器，进行抓包： 同样的能够抓取到 HTTP 明文。 注：不抓包时记得把环境变量删掉，以防止性能节约和安全性问题计划二的长处非常明显，能够抓取任意网站的SSL/TLS加密的报文，惟一的毛病就是只能是浏览器反对的状况才行，而计划一能够针对任何 HTTP 客户端进行抓包。 通过 wireshake 抓取 HTTP2 报文下面都是针对TLS+HTTP1进行的抓包，市面上支流的浏览器的HTTP2都是基于TLS实现的，所以也是一样的，把TLS这层解密了天然看到的就是最原始的明文。 这里以剖析https://www.qq.com为例，为什么不是经典htts://www.baidu.com，因为百度首页至今还是HTTP/1.1协定。 应用下面的第二种计划配置好wiresharke通过http2关键字做过滤浏览器拜访https://www.qq.com查看HTTP2报文：这样就抓取到了HTTP2报文了，HTTP2 协定非常复杂，我也还在学习阶段，这里就不多说啥了。 后记wireshake 真的是一款十分弱小的网络分析工具，在HTTPS和HTTP2日渐成为支流的时候，能够用它来帮忙咱们加深对这些协定的了解，以便迎接新的时机与挑战。 ...

HTTPS相干简介HTTP通过SSL的加密后生成HTTPS，使网络通信变得更加平安HTTPS使用了三种加密形式，别离是对称加密AES，非对称加密RSA和Hash算法（不可逆），用AES传输（效率思考），用RSA来沟通AES，用HTTP（来验证效率）HTTPS次要解决了三个问题 数据的保密性： 在传输过程中，数据被读取RSA+AES来确保认证问题： 在传输过程中，不能保障是真正须要的信息数字证书数据的完整性问题 在传输过程中，数据可能被增加或者篡改Hash算法连贯过程/证书验证过程1、客户端 开始申请，发送了第一个随机数，及能提供的Hash算法及加密算法2、服务器端 首先发送了第二个随机数，及选用的Hash算法及加密算法而后发送证书信息，证书信息包含，待签名的证书局部（公钥有效期等），证书签名（对报文信息用私钥加密）3、客户端 验证证书：利用公钥对证书签名进行解密，而后与待签名局部的做Hash解决，若相等则这一级的证书为无效证书，且为残缺证书。而后始终向上进行判断，直到根CA机构，最初判断该证书无效。给服务器端发消息： 用公钥加密第三个随机数。并用这三个随机数生成的对称加密算法发送后面所有内容的Hash值4、服务器端 server finished 用生成的会话密匙，加密之前传输数据的Hash值，供客户端校对5、握手完结，正式开始传输SSL在哪一层、介于HTTP的应用层与TCP层之间（表示层，会话层的地位）

HTTPS相干简介HTTP通过SSL的加密后生成HTTPS，使网络通信变得更加平安HTTPS使用了三种加密形式，别离是对称加密AES，非对称加密RSA和Hash算法（不可逆），用AES传输（效率思考），用RSA来沟通AES，用HTTP（来验证效率）HTTPS次要解决了三个问题 数据的保密性： 在传输过程中，数据被读取RSA+AES来确保认证问题： 在传输过程中，不能保障是真正须要的信息数字证书数据的完整性问题 在传输过程中，数据可能被增加或者篡改Hash算法连贯过程/证书验证过程1、客户端 开始申请，发送了第一个随机数，及能提供的Hash算法及加密算法2、服务器端 首先发送了第二个随机数，及选用的Hash算法及加密算法而后发送证书信息，证书信息包含，待签名的证书局部（公钥有效期等），证书签名（对报文信息用私钥加密）3、客户端 验证证书：利用公钥对证书签名进行解密，而后与待签名局部的做Hash解决，若相等则这一级的证书为无效证书，且为残缺证书。而后始终向上进行判断，直到根CA机构，最初判断该证书无效。给服务器端发消息： 用公钥加密第三个随机数。并用这三个随机数生成的对称加密算法发送后面所有内容的Hash值4、服务器端 server finished 用生成的会话密匙，加密之前传输数据的Hash值，供客户端校对5、握手完结，正式开始传输SSL在哪一层、介于HTTP的应用层与TCP层之间（表示层，会话层的地位）

HTTP访问控制（CORS）Http申请中的Content-TypeHTTP申请报文和HTTP响应报文 [须要更新]

背景浏览器缓存是Web利用性能优化的一个重要环节，应用缓存能够缩小浏览器向服务器申请资源的次数，从而放慢客户端加载网页的速度，减小服务器压力 浏览器缓存分类浏览器缓存策略次要有两种：强缓存和协商缓存。 浏览器在给服务器发送第一次申请后，再发送后续申请时，会先读取上一次返回header中的信息 强缓存：返回的header中的expires、cache-control字段命中强缓存，则下一次发申请时间接从缓存中返回，不与服务器通信协商缓存：如果header中没有命中强缓存的信息，浏览器发送携带header信息的申请到服务端，由服务端判断是否命中协商缓存，如果命中则服务器返回新的响应header信息更新缓存中的对应header信息，然而并不返回资源内容，它会告知浏览器能够间接从缓存获取；否则返回最新的资源内容强缓存是在本地判断缓存是否过期，没有与服务端交互，取得到的缓存也是本地的内容。 协商缓存是通过发送本地缓存的header信息到服务端，由服务端判断header信息中缓存是否过期，如果没过期客户端依然应用本地缓存，如果过期服务端返回新的资源。 强缓存强缓存通过header头部信息中的expires和cache-control字段判断是否过期。 expires字段示意缓存过期工夫，是服务端返回的相对工夫，GTM格局（咱们用的GTM+8，隔8个小时），会存在服务器与客户端工夫偏差导致缓存凌乱的问题。逐步被 cache-control代替cache-control字段通过max-age来设置缓存持续时间以下是几个cache-control相干字段及其含意 字段含意no-cache告知浏览器不间接应用本地缓存，要先向服务器发动申请no-store禁止浏览器缓存资源，每次都要向服务器申请资源，每次申请都会下载残缺的资源max-age缓存资源的无效工夫，从浏览器第一次发申请的工夫算起public能够被所有用户缓存，包含浏览器或代理private仅容许客户端浏览器缓存，不容许CDN等两头代理缓存协商缓存服务端判断申请是否命中协商缓存的时候，须要应用到 Last-Modified 或者 Etag 字段，Last-Modified基于批改工夫，Etag基于文件内容 浏览器第一次申请一个资源的时候，服务器返回的header中会加上Last-Modify，标识该资源的最初批改GTM相对工夫，例如 Last-Modify: Thu,31 Dec 2037 23:59:59 GMT。当浏览器再次申请该资源时，request的申请头中会蕴含If-Modify-Since，该值为缓存之前返回的Last-Modify。服务器收到If-Modify-Since后，依据资源的最初批改工夫判断是否命中缓存。 如果命中缓存，则返回304 Not Modified，并且不会返回资源内容，并且不会返回Last-Modify。 Etag/If-None-Match返回一个校验码。ETag能够保障每一个资源是惟一的，资源变动都会导致ETag变动。服务器依据浏览器上送的If-None-Match值来判断是否命中缓存。 与Last-Modified不一样的是，当服务器返回304 Not Modified的响应时，因为ETag从新生成过，response header中还会把这个ETag返回，即便这个ETag跟之前的没有变动。

咱们日常应用的能联网的设施，或多或少的都应用了HTTP，它是基于TCP/IP的通信协议，咱们来理解一下它的历史进程。 史前期间20世纪60年代，美国国防部建设了ARPA网，在70年代又提出了TCP/IP协定，并在80年代利用在UNIX内核中。 创世纪欧洲核子研究中心（CERN）的蒂姆·伯纳斯 - 李发表了一篇论文，提出了文档零碎，它有三大关键技术： URL：对立资源标识符HTML：超文本标记HTTP：超文本传输协定 HTTP/0.920世纪90年代的HTTP定义为0.9版本，性能十分无限，只能用于传输纯文本。 HTTP/1.01993 年，NCSA（美国国家超级计算利用核心）开发了图文混排浏览器Mosaic，在之后以开发了简化HTTP搭建的Apache。在同一时间多媒体技术以呈现了JPEG，MP3格局。1996年，HTTP1.0正式公布，更新个性： 减少了 HEAD、POST 等新办法；减少了响应状态码，标记可能的谬误起因；引入了协定版本号概念；引入了 HTTP Header（头部）的概念，让 HTTP 解决申请和响应更加灵便；传输的数据不再仅限于文本。 HTTP/1.11995年，浏览器大战，网景的 Netscape Navigator 和微软的 Internet Explorer对决，最初微软IE胜出。HTTP1.1更新个性如下： 减少了 PUT、DELETE 等新的办法；减少了缓存治理和管制；明确了连贯治理，容许长久连贯；容许响应数据分块（chunked），利于传输大文件；强制要求 Host 头，让互联网主机托管成为可能。 HTTP/2Google不满HTTP的倒退，推出 SPDY 协定并利用于利用Chrome浏览器，利于市场份额，倒逼HTTP改革。在2015年，HTTP/2公布了，更新个性如下： 二进制协定，不再是纯文本；可发动多个申请，废除了 1.1 里的管道；应用专用算法压缩头部，缩小数据传输量；容许服务器被动向客户端推送数据；加强了安全性，“事实上”要求加密通信。 HTTP/3Google创造 QUIC 协定，在2018年HTTP/3取得批准。 参考文档极客工夫透视HTTP协定课程

以生存中常见对话的状态确认场景作为切入点，简略易懂地诠释HTTP的三次握手和四次挥手。 HTTP三次握手1. 客户端向服务器端发动状态确认的询问（第一次握手）； 2.服务器端确认状态，并反诘客户端的状态确认（第二次握手）； 3. 客户端回复服务器端的状态确认，筹备建设连贯（第三次握手）； 4. 两者建设连贯，通过TCP传输数据（建设连贯）。 HTTP四次挥手1. 客户端向服务器端示意筹备完结连贯（第一次挥手）； 2. 服务器端向客户端示意正开始筹备完结连贯（第一次挥手）； 3. 服务器端向客户端示意能够完结连贯了（第三次挥手）； 4. 客户端确认服务器端的完结连贯回复（第四次挥手）； 5. 两者完结连贯。 原始起源B站Up主：程序员视角 视频：【编程根底】TCP网络通信、三次握手和四次握手

＠冒泡的马树 参考文章：HTTP状态码 | 菜鸟教程 工具：百度脑图 HTTP状态码1**信息，服务器收到申请，须要请求者继续执行操作具体代码100Continue持续。客户端应持续其申请101Switching Protocols切换协定。服务器依据客户端的申请切换协定。只能切换到更高级的协定，例如切换到HTTP的新版本协定2**胜利，操作被胜利接管并解决具体代码200OK申请胜利。个别用于GET与POST申请201Created已创立。胜利申请并创立了新的资源202Accepted曾经完结申请，但未解决实现203Non-Authoritative Information非受权信息。申请胜利，但返回的meta信息不在原始的服务器，而是一个正本204NO Content无内容。服务器胜利解决，但未返回内容。在未更新网页的状况下，可确保浏览器持续显示以后文档205Reset Content重置内容。服务器解决胜利，用户终端（例如浏览器）应重置文档视图。可通过此返回码革除浏览器的表单域206Partial Content局部内容。服务器胜利解决了局部GET申请3**重定向，须要进一步的操作以实现申请具体代码300Multiple Choices多种抉择。申请的资源可包含多个地位，相应可返回一个资源特色与地址的列表用于用户终端（例如浏览器）抉择301Moved Permanently永恒挪动。申请的资源已被永恒地挪动到新URI，返回信息会蕴含新的URI，浏览器会主动定向到新URI。今后任何新的申请都应应用新的URI代替302Found长期挪动。与301相似，但资源只是长期被挪动，客户端应该持续应用原有URI303See Other查看其它地址。与301相似，应用GET和POST申请查看304Not Modified未修改。所申请的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会缓存拜访过的资源，通过提供一个头信息指出客户端心愿只返回在指定日期之后批改的资源305Ues Proxy应用代理。所申请的资源必须通过代理拜访306Unused曾经被废除的HTTP状态码307Temporary Redirect长期重定向。与302相似，应用GET申请重定向4**客户端谬误，申请蕴含语法错误或无奈实现申请具体代码400Bad Request客户端申请的语法错误，服务器无奈了解401Unauthorized申请要求用户的身份认证402Payment Required保留，未来应用403Forbidden服务器了解申请客户端的申请，然而拒绝执行此申请404Not Found服务器无奈依据客户端的申请找到资源（网页）。通过此代码，网站设计人员可设置“您所申请的资源无奈找到”共性页面405Method Not Allowed客户端申请中的办法被禁止406Not Acceptable服务器无奈依据客户端申请的内容个性实现申请407Proxy Authentication Required申请要求代理的身份认证，与401相似，但请求者该当应用代理进行受权408Request Timeout服务器期待客户端发送的申请工夫过长，超时409Conflict服务器实现客户端的PUT申请时可能返回此代码，服务器解决申请时产生了抵触410Gone客户端申请的资源曾经不存在。410不同于404，如果资源以前有当初被永恒删除了可应用410代码，网站设计人员可通过301代码指定资源的新地位411Lenght Required服务器无奈解决客户端发送的不带Content-Length的申请信息412Precondition Failed客户端申请信息的先决条件谬误413Request Entity Too Large因为申请的实体过大，服务器无奈解决，因而拒绝请求。为避免客户端的间断申请，服务器可能会敞开连贯。如果只是服务器临时无奈解决，则会蕴含一个Retry-After的响应信息414Request-URI Too Large申请的URI过长（URI通常为网址），服务器无奈解决415Unsupported Media Type服务器无奈解决申请附带的媒体格式416Requested range not satisfied客户端申请的范畴有效417Expectation Failed服务器无奈满足Expect的申请头信息5**服务器谬误，服务器在解决申请的过程中产生了谬误具体代码500Internal Server Error服务器外部谬误，无奈实现申请501Not Implemented服务器不反对申请的性能，无奈实现申请502Bad Gateway作为网关或者代理工作的服务器尝试执行申请时，从近程服务器接管到了一个有效的响应503Service Unavailable因为超载或系统维护，服务器临时无奈解决客户端的申请。延时的长度可蕴含在服务器的Retry-After头信息中504Gateway Timeout充当网关或代理的服务器，未及时从远端服务器获取申请505HTTP Version not supported服务器不反对申请的HTTP协定的版本，无奈实现解决

HTTP报文用于HTTP协定交互的信息被称为报文。HTTP报文大抵可分为报文首部和报文主体，两者由最后呈现的空行（CR+LF）来划分。通常，并不一定要有报文主体。 报文首部：服务器端或客户端须要解决的申请或响应的内容及属性。 CR+LF：CR（Carriage Return，回车符）LF(Line Feed，换行符) 报文主体：应被发送的数据。 编码晋升传输速率HTTP传输数据是能够原样传输，也能够进行编码晋升传输速率，通过编码能无效解决大量的拜访申请。然而编码操作须要计算机实现，因而耗费更多的CPU资源。 报文主体和实体主体的差别报文（message）：是HTTP通信的根本单位，由8位组字节流组成，通过HTTP通信传输。 实体（entity）：作为申请或响应的有效载荷数据（补充项）被传输，其内容由实体首部和实体主体组成。 通常报文主体等于实体主体。只有当传输中进行编码操作时，实体主体的内容发生变化，才导致它和报文主体产生差别。 压缩传输的内容编码内容编码指明利用在实体内容上的编码格局，并放弃信息原样压缩。内容编码后的实体由客户端接管并负责解码。 罕用内容编码： gzip(GUN zip)compress(UNIX 零碎的规范压缩)deflate(zlib)identity(不进行编码)宰割发送的离开传输编码在HTTP通信过程中，申请的编码实体资源尚未全副传输实现之前，浏览器无奈显示申请页面。在传输大量数据时，通过把数据宰割成多块，可能让浏览器逐渐显示页面。（懒加载是不是用了这个技术呢） 分块传输编码：将实体主体分成多个局部（块）。每一块都会用十六进制来标记块的大小。实体主体最初一块应用“0（CR+LF）”来标记。 发送多种数据的多局部对象汇合HTTP协定应用多局部对象汇合办法，使得发送一份报文主体内可含有多类型实体。通常在图片或文本文件等上传时应用。 multipart/form-data：在web表单文件上传时应用。 multipart/byteranges：状态码206（partial Content，局部内容）响应报文蕴含了多个范畴的内容时应用。 在HTTP报文中应用多局部对象汇合时，须要在首部字段里加上Content-type。应用boundary字符串来划分多局部对象汇合指明的各类实体。在boundary字符串指定的各个实体起始行之前插入“--”标记（例如：--AaB03x、--THIS_STRING_SEPARATES），而在多局部对象汇合对应的字符串的最初插入“--”标记作为完结。 获取局部内容的范畴申请场景：解决下载文件中断后无需重头下载，提供一种可复原机制。所谓复原是指能从之前下载中断处复原下载。 要实现该性能须要制订下载的范畴实体。制订范畴发送的申请叫做范畴申请（Range Request）。 对一份10000字节大小的资源，如果应用范畴申请，能够只申请5001~10000字节内的资源。会用到首部字段Range来指定资源的byte范畴。 指定5001~10000字节 Range： bytes=5001-10000 从一开始到3000字节和5000到7000字节的多重范畴 Range: bytes=-3000, 5000-7000 针对范畴申请，响应状态码为206 Partial Content。对于多重范畴申请，响应会在首部字段Content-Type表明multipart/byteranges后返回响应报文。如果服务器端无奈响应范畴申请，则返回200 OK和残缺实体内容。 内容协商内容协商机制是指客户端和服务器端就响应的资源内容进行交涉，而后提供给客户端最为适宜的资源。内容协商会以响应资源的语言（中文网站和英文网站切换）、字符集、编码方式等作为判断的基准。 蕴含着申请报文中的某些字段（如下）就是判断基准： AcceptAccept-CharsetAccept-EncodingAccept-LanguageContent-Language三种类型： 服务器驱动协商：以申请的首部字段做参考，服务器端主动解决。 客户端驱动协商：用户在网页显示的可选列表中自行抉择。 通明协商：二者各自进行内容协商的一种办法。

原文链接 何晓东 博客 http 400+400 Bad Request1、语义有误，以后申请无奈被服务器了解。除非进行批改，否则客户端不应该反复提交这个申请。2、申请参数有误。 401 Unauthorized以后申请须要用户验证。该响应必须蕴含一个实用于被申请资源的 WWW-Authenticate 信息头用以询问用户信息。客户端能够反复提交一个蕴含失当的 Authorization 头信息的申请。如果以后申请曾经蕴含了 Authorization 证书，那么401响应代表着服务器验证曾经回绝了那些证书。如果401响应蕴含了与前一个响应雷同的身份验证询问，且浏览器曾经至多尝试了一次验证，那么浏览器该当向用户展现响应中蕴含的实体信息，因为这个实体信息中可能蕴含了相干诊断信息。 402 Payment Required此响应码保留以便未来应用，发明此响应码的最后目标是用于数字领取零碎，然而当初并未应用。 403 Forbidden服务器曾经了解申请，然而拒绝执行它。与 401 响应不同的是，身份验证并不能提供任何帮忙，而且这个申请也不应该被反复提交。如果这不是一个 HEAD 申请，而且服务器心愿可能讲清楚为何申请不能被执行，那么就应该在实体内形容回绝的起因。当然服务器也能够返回一个 404 响应，如果它不心愿让客户端取得任何信息。 404 Not Found申请失败，申请所心愿失去的资源未被在服务器上发现。没有信息可能通知用户这个情况到底是临时的还是永恒的。如果服务器晓得状况的话，该当应用410状态码来告知旧资源因为某些外部的配置机制问题，曾经永恒的不可用，而且没有任何能够跳转的地址。404这个状态码被广泛应用于当服务器不想揭示到底为何申请被回绝或者没有其余适宜的响应可用的状况下。 405 Method Not Allowed申请行中指定的申请办法不能被用于申请相应的资源。该响应必须返回一个Allow 头信息用以示意出以后资源可能承受的申请办法的列表。 鉴于 PUT，DELETE 办法会对服务器上的资源进行写操作，因此绝大部分的网页服务器都不反对或者在默认配置下不容许上述申请办法，对于此类申请均会返回405谬误。 406 Not Acceptable申请的资源的内容个性无奈满足申请头中的条件，因此无奈生成响应实体。 407 Proxy Authentication Required与401响应相似，只不过客户端必须在代理服务器上进行身份验证。代理服务器必须返回一个 Proxy-Authenticate 用以进行身份询问。客户端能够返回一个 Proxy-Authorization 信息头用以验证。 408 Request Timeout申请超时。客户端没有在服务器准备期待的工夫内实现一个申请的发送。客户端能够随时再次提交这一申请而无需进行任何更改。 409 Conflict因为和被申请的资源的以后状态之间存在抵触，申请无奈实现。这个代码只容许用在这样的状况下能力被应用：用户被认为可能解决抵触，并且会从新提交新的申请。该响应该当蕴含足够的信息以便用户发现抵触的源头。 410 Gone被申请的资源在服务器上曾经不再可用，而且没有任何已知的转发地址。这样的情况该当被认为是永久性的。如果可能，领有链接编辑性能的客户端该当在取得用户许可后删除所有指向这个地址的援用。如果服务器不晓得或者无奈确定这个情况是否是永恒的，那么就应该应用 404 状态码。除非额定阐明，否则这个响应是可缓存的。 411 Length Required服务器回绝在没有定义 Content-Length 头的状况下承受申请。在增加了表明申请音讯体长度的无效 Content-Length 头之后，客户端能够再次提交该申请。 412 Precondition Failed服务器在验证在申请的头字段中给出先决条件时，没能满足其中的一个或多个。这个状态码容许客户端在获取资源时在申请的元信息（申请头字段数据）中设置先决条件，以此防止该申请办法被利用到其心愿的内容以外的资源上。 ...

HTTP是一种无状态（stateless）协定。协定本身不对申请和响应之间的通信状态进行保留。每当有新的申请发送时，就会有对应的新的响应产生。协定自身并不保留之前所有的申请或响应报文信息。 起因：为了更快的解决大量事物，确保协定的可伸缩性，而特意将HTTP协定设计成如此简略。 长处：因为不保留状态，天然能够缩小服务器的CPU以及内存资源的耗费。 然而有时候须要保留状态，比方用户的登录状态，这时候引入cookie技术，就能够治理状态了。 申请报文申请报文由报文首部（申请办法、申请URI、协定版本、可选的申请首部字段）和报文主体（内容实体）形成，两者由空行宰割，报文的主体内容个别为空。 响应报文响应报文基本上是由报文首部（协定版本、状态码（status code）、用以解释状态码的起因短语、可选的响应首部字段）以及报文主体（实体主体）形成，二者空格隔开。 HTTP办法GET办法：获取资源用来申请拜访已被URI辨认的资源。指定的资源经服务器端解析后返回响应内容。如果申请的是文本，则放弃原样返回；如果是CGI（Common Gateway Interface，通用网关接口）那样的程序，则返回通过执行后的输入后果。 POST办法：传输实体主体 PUT办法：传输文件PUT办法用来出传输文件，要求申请报文的主体中蕴含文件内容，而后保留到申请URI指定的地位。 然而，鉴于HTTP/1.1的PUT办法本身不带验证机制，任何人都能够上传文件，存在安全性问题，因而个别的web网站不应用此办法。若配合web应用程序的验证机制，或架构设计采纳REST(REpresentational State Transfer, 表征状态转移)规范的同类web网站，就可能会凋谢应用PUT办法。 这个响应的意思是申请执行胜利了，但无数据返回。 HEAD办法：取得报文首部HEAD办法和GET办法一样，只是不返回报文主体局部。用于确认URI的有效性及资源更新的日期工夫等。 DELETE办法：删除文件DELETE办法是与PUT重复相同的办法。按申请URI删除指定的资源。然而HTTP/1.1的DELETE自身也不带验证机制，所以个别也不实用。当配合web应用程序的验证机制或恪守REST规范时还是有可能凋谢应用的。 OPTIONS办法：询问反对的办法用来查问针对申请URI指定的资源反对的办法。 TRACE办法：追踪门路TRACE办法是让web服务器将之前的申请通信环回客户端的办法。 发送申请时，在Max-Forwards首部字段填入数值，每通过一个服务器端就将该数字减1，当数值刚好为0时，就进行持续传输，最初接管到申请的服务器端则返回状态码200 OK的响应。 客户端通过TRACE办法能够查问收回去的申请时怎么样被加工/篡改的。这是因为，申请想要连贯到源指标服务器可能会通过代理直达，TRACE办法就是用来确认连贯过程中产生的一系列操作。自身不罕用，再加上容易引发XST（Cross-Site Tracing，跨站攻打）攻打，就更不会用到了。 CONNECT办法：要求用隧道协定连贯代理CONNECT办法要求在与代理服务器通信时建设隧道，实现用隧道协定进行TCP通信。次要应用SSL（Secure Sockets Layer，安全套接层）和TLS（Transport Layer Security， 传输层平安）协定把通信内容加密后经网络隧道传输。 格局： CONNECT 代理服务器名：端口号 HTTP版本 长久连贯节俭通信HTTP协定初始版本中，每进行一次HTTP通信就要端口一次TCP连贯。以前都是容量很小的文本传输，所以没什么问题。当初一个网页中有大量图片，每次申请会造成无畏的TCP连贯建设和断开，减少通信的开销。 为解决这个问题，HTTP/1.1和一部分HTTP/1.0想出了长久连贯（HTTP Persistent Connections， 也称为HTTP keep-alive 或HTTP connection reuse）的办法。特点是，只有任意一端没有明确提出断开连接，则放弃TCP连贯状态。 益处：缩小了TCP连贯和断开造成的额定开销，加重了服务器端的负载。另外，缩小开销的那局部工夫，使HTTP申请和响应可能更早地完结，这样web页面的显示速度也就相应进步了。 管线化前提是须要长久连贯。从前发送申请后须要期待并收到响应能力发送下一个申请，管线化技术呈现后，不必期待响应亦可间接发送下一个申请。并行发送多个申请。管线化技术比长久连贯还要快，申请数越多，时间差越显著。 应用Cookie的状态治理Cookie会依据从服务器端发送的响应报文内的一个叫做Set-Cookie的首部字段信息，告诉客户端保留cookie。当下次客户端再往服务器端发送申请时，客户端会主动在申请报文中退出cookie值后发送进来。 服务器端发现客户端发送过去的cookie之后，会去查看到底是从哪个客户端发送过去的申请，而后比照服务器上的记录，最初失去之前的状态信息。

HTTP(HyperText Transfer Protocol)通常被翻译为超文本传输协定，但这种译法并不谨严，严禁的译名应该为“超文本转移协定”。 最后构想的根本理念是：借助多文档之间互相关联造成的超文本，连成互相参阅的WWW(World Wide Web,万维网)。 3项WWW构建技术： 把SGML(Standard Generalized Markup Language, 规范通用标记语言)作为页面的文本标记语言的HTML(HyperText Markup Language, 超文本标记语言);作为文档传递协定的HTTP；指定当所在地址的URL(Uniform Resource Locator, 对立资源定位符)Web成长时代1990年11月，CERN(欧洲核子钻研组织)胜利研发出了世界上第一台Web服务器和Web浏览器。 HTTP正式作为规范被颁布是在1996年5月，版本被命名为HTTP/1.0，并记录于RFC1945。 TCP/IP协定计算机与网络设备要互相通信，单方就必须基于雷同的办法。这个办法规定就称为协定。 TCP/IP协定族流重要的一点就是分层：应用层、传输层、网络层和数据链路层。 益处：就如同模块化开发一样，只有各层之间的接口局部布局好当前，每个档次外部的设计就可能自在改变。而且层次化之后设计也更为简略，单个档次只思考本人分派的工作就能够了，不必思考其余局部。 应用层决定了向用户提供应用服务时的通信的流动。FTP和DNS，HTTP协定也处于该层。 传输层提供处于网络连接中的两台计算机之间的数据传输。TCP(Transmission Control Protocol, 传输控制协议)和UDP(User Data Protocal, 用户数据报协定)在这一层。 网络层用来解决网络上流动的数据包。数据包是网络传输的最小数据单位。该层规定了通过怎么的门路（所谓的传输路线）达到对方计算机，并把数据包传送给对方。 与对方计算机之间通过多态计算机或网络设备进行传输时，网络层所起的作用就是在泛滥的选项内抉择一条传输路线。 链路层用来解决连贯网络的硬件局部。包含管制操作系统、硬件的设施驱动、NIC(Network Interface Card, 网络适配器，即网卡)，及光纤等物理可见局部（还包含连接器等所有传输媒介）。硬件上的领域均在链路层的作用范畴内。 TCP/IP通信传输流 客户端在应用层（HTTP协定）收回一个想看某个web页面的HTTP申请； 为了传输不便，在传输层（TCP协定）把从应用层收到的数据（HTTP申请报文）进行宰割，并在各个报文上打上标记序号及端口号后转发给网络层； 在网络层（IP协定），减少作为通信目的地的MAC地址后转发给链路层，这样，发往网络的通信申请就筹备齐全了。 接收端的服务器在链路层接管到数据，按序往下层发送，始终到应用层，当传输到应用层，能力算真正接管到由客户端发送过去的HTTP申请。 负责传输的IP协定不要把IP和IP地址搞混，IP是一种协定，网际协议位于网络层。作用是把各种数据包传送给对方。 保障的确传送到对方那里的两个重要条件：IP地址和MAC地址（Media Access Control Address）。 IP地址指明了节点被调配到的地址，MAC地址是指网卡所属的固定地址。IP地址能够和MAC地址进行配对，IP地址可变换，但MAC地址根本不会更改。 场景：IP之间的通信依赖MAC地址，然而通常通信单方不在同一局域网下，须要通过多台计算机和网络设备直达能力连贯到对方。在直达时，会利用下一站直达设施的MAC地址来搜寻下一个直达指标。这时，会采纳APR（Address Resolution Protocol）协定。ARP是一种用以解析地址的洗衣，依据通信方的IP地址就能够反查出对应的MAC地址。 确保可靠性的TCP协定TCP位于传输层，提供牢靠的字节流服务（Byte Stream Service），是指为了不便传输，将大块数据宰割成以报文段位单位的数据包进行治理。牢靠就是指精确牢靠的传输给对方。 为了准确无误的将数据送达指标处，TCP协定采纳了三次握手（three-way handshaking）策略。握手过程应用了TCP的标记——SYN（synchronize）和ACK（acknowledgement）。 过程： 发送端先发送一个带SYN标记的数据包给对方。（先测试线路通不通）接收端接管后，回传一个带有SYN/ACK标记的数据包以示传播确认信息。（接收端通知你通了）最初发送端再回传一个带ACK标记的数据包，代表握手完结。（而后才发送信息）如果在握手过程中某个阶段莫名终端，TCP协定会再次以雷同程序发送雷同的数据包。 负责域名解析的DNS服务DNS（Domain Name System）服务是和HTTP协定一样位于应用层的协定。它提供域名到IP地址之间的解析服务。 URI和URLURL（Uniform Resource Locator）对立资源定位符，是咱们应用web浏览器等拜访web页面时须要输出的网页地址，例如http://www.baidu.com/就是URL。 URI（Uniform Resource Identifier）对立资源标识符。 ...

Http和Https的基本概念Http：超文本传输协定，是互联网上利用最宽泛的一种网络协议，是一个客户端和服务端申请和应答的规范，用于WWW服务器传输超文本到本地浏览器的传输协定。Https：是以平安为指标的Http通道，在Http协定退出SSL协定，建设一个信息安全通道，确保信息的传输平安，保障网站的真实性。http和https的区别Https协定须要CA证书，费用高。Http是超文本传输协定，信息是明文。Https是具备安全性的SSL加密传输协定。应用的端口不同。Http应用80端口。Https应用403端口。Http的连贯简略，是无状态的。Https协定是由Http和SSL协定构建的可进行加密传输、身份认证的网络协议。Https协定的工作原理客户端在应用Https url拜访服务器，要求web服务器建设ssl连贯。Web服务器接管到客户端申请后，将网站的证书（证书蕴含了公钥），返回给客户端。客户端和Web服务器端开始协商SSL链接的安全等级。客户端浏览器通过单方协商一致的安全等级，建设会话密钥，而后通过网站的公钥来加密会话密钥，并传送给网站。Web服务端通过本人的私钥解密出会话密钥。Web服务端通过密钥加密与客户端之间的通信。Https协定长处Https协定可认证用户和服务器，确保数据发送到正确的客户端和服务器。Https协定由Http协定和SSL协定构建的可进行加密传输、身份认证的网络协议，比Http协定平安。避免数据在传输中被窃取、扭转。Https协定的毛病Https握手阶段费时，会使页面加载工夫缩短50%。Https缓存不如http高效，减少数据开销。SSL证书须要花钱

HTTP笔记101：websocket200：请求成功206：视频文件304：本地缓存404：目录找不到

静态 HTTP 服务的几个用途： 静态网页的 HTTP 服务，以访问浏览 如：生成的文档、博客等公开文件的 HTTP 服务，以访问下载 如：分享的文档、安装包等以下会介绍目前我了解的方式中，最推荐的两种： Python: http.server — HTTP serversNode.js: http-server: a command-line http serverPython: http.server — HTTP servers只要你安装了 Python 就可用了。 首先 cd 到要公开的目录，然后执行： $ python -m http.server 8000Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...浏览器访问 http://0.0.0.0:8000/ ： Node.js: http-server: a command-line http server需要你安装 Node.js ，再安装此 http-server 包： npm install -g http-servermacOS 上用 Homebrew 也可一步到位： brew install http-server之后，就多了个 http-server 命令。 cd 到要公开的目录，执行： ...

GET：获取资源例如图片、css文件、js文件等，在RESTful API中，一般用来获取数据，例如列表，详情等。对应CRUD中的R，即查找操作。 POST：传输实体主体例如提交表单信息，在RESTful API中，一般用来提交数据，例如表单等。对应CRUD中的C，即创建操作。 PUT：传输文件在RESTful API中，一般用做修改数据。对应CRUD中的U，即修改操作。 DELETE：删除文件与PUT相反，在RESTful API中，一般用做删除数据。对应CRUD中的D，即删除操作。 HEAD：获取报文首部与GET类似，只是不返回报文主体部分。一般用于确认URI的有效性以及资源的更新日期时间等。 OPTIONS：询问支持的方法这个请求方式估计很多做前端的同学都会碰到，在和后端对接接口时，明明只发了一个请求，浏览器却一直显示发送了两个请求，第一个就是OPTIONS的请求方法。这一般是跨域的原因。跨域的解决方案有很多种，一般采用的是CORS，正是由于这种方式有“预检”的请求，所以浏览器主动发送了一个OPTIONS的询问请求，有两个作用。 获取服务器支持的HTTP请求方法。会在首部字段中返回，例如Allow: GET,POST,HEAD,OPTIONS。用来检查服务器的性能。这也正是AJAX中的预检功能。什么时候会发出预检请求呢？当具有下述情况之一时，就会发出预检： 使用了PUT、DELETE、CONNECT、OPTIONS、TRACE、PATCH。人为的设置了除了对CORS安全的首部字段之外的其他首部字段。Accept、Accept-Language、Content-Language、Content-Type（注意第3条）、DPR、Downlink、Save-Data、Viewport-Width、Width。Content-Type不属于application/x-www-form-urlencoded、multipart/form-data、text/plain中的一类。TRACE：追踪路径REACE方法基本不怎么使用。是让 Web 服务器端将之前的请求通信环回给客户端的方法。发送请求时，在 Max-Forwards 首部字段中填入数值，每经过一个服务器端就将该数字减 1，当数值刚好减到 0 时，就停止继续传输，最后接收到请求的服务器端则返回状态码 200 OK 的响应。 CONNECT：要求用隧道协议连接代理

一个简单回答： 浏览器生成请求并发送到服务器；服务器接受到请求后，执行一些动作或获取某些资源，然后将响应发送回客户端；浏览器在接收到响应数据之后，解析DOM树和CSS树，处理JavaScript，构建页面。如果这是你是在面试中的回答，那估计面试官的表情就是这样的。很明显，面试官在问这个问题的时候，重点应该是浏览器生成请求并发送到服务器是如何工作的。那这又不得不提到TCP/IP四层模型了。我们都知道，TCP/IP四层模型，分别是应用层、传输层、网络层、链路层。利用TCP/IP协议簇进行网络通信时，发送端从应用层往下走，接收端则往应用层往上走。以HTTP发送端为例，在应用层发起一个请求时，会将数据包交由传输层进行分割（TCP），并在各个报文上打上标记序号和端口号之后转发给网络层，网络层将目的MAC地址添加上之后又交由链路层。 那我们现在再回到这个问题，在浏览器输入URL后，发生了什么？回想一下四层模型的数据流动方向，再结合上面的图，我们再来试试回答这个问题。 首先需要解析IP（应用层）。我们在浏览器中输入的一般都是域名，相当于是IP的一个映射，所以需要DNS解析域名来获取IP地址。下图则是一个表述了这个DNS的查找过程。客户端首先会查找本地是否有对应的域名的缓存（浏览器缓存、hosts文件），没有则去请求根DNS服务器或者其他权威的DNS服务器。 建立TCP请求（传输层）。在得到上一层的数据包之后，TCP会对将请求报文分割成报文段，通过三次握手建立可靠的连接。发送HTTP请求。在经过传输层的处理之后，到达网络层，通过IP协议，搜索对方的地址，一边中转一边发送。到达链路层之后则是将数据包以帧为单位进行广播发送。直到服务器接收到数据，这个过程和上述过程是个逆过程，就不多做赘述了。服务器处理。服务器在对数据处理执行一些动作之后，将响应的数据又通过TCP发送到客户端，待数据发送完毕，会进行四次握手来关闭TCP连接。客户端响应。客户端会通过服务器返回的状态进行响应，比如重定向、zip压缩的解压等等。浏览器渲染页面。解析CSS规则树和DOM树，浏览器进行布局和渲染，处理js。更多：TCP/IP四层模型（协议簇）各层作用参考： 《图解HTTP》《JavaScript忍者秘籍》

6. 面向对象与面向过程比较6.1 什么是面向过程编程面向过程编程也是一种编程范式或编程风格。它以过程（可以理解为方法、函数、操作）作为组织代码的基本单元，以数据（可以理解为成员变量、属性）与方法相分离为最主要的特点。面向过程风格是一种流程化的编程风格，通过拼接一组顺序执行的方法来操作数据完成一项功能6.2 面向对象比面向过程的优势oop更加能够应对大规模复杂程序开发oop风格的代码更易复用、易扩展、易维护oop语言更加人性化、更加高级、更加智能（汇编语言，高级语言）扩展问题：面向对象比面向过程，更加容易应对大规模复杂程序的开发。但像 Unix、Linux 这些复杂的系统，也都是基于 C 语言这种面向过程的编程语言开发的，你怎么看待这个现象？解答：使用任何一个编程语言编写的程序，最终执行上都要落实到CPU一条一条指令的执行（无论通过虚拟机解释执行，还是直接编译为机器码），CPU看不到是使用何种语言编写的程序。对于所有编程语言最终目的是两种：提高硬件的运行效率和提高程序员的开发效率。然而这两种很难兼得。 C语言在效率方面几乎做到了极致，它更适合挖掘硬件的价值，如：C语言用数组char a[8]，经过编译以后变成了（基地址＋偏移量）的方式。对于CPU来说，没有运算比加法更快，它的执行效率的算法复杂度是O(1)的。从执行效率这个方面看，开发操作系统和贴近硬件的底层程序，C语言是极好的选择。 C语言带来的问题是内存越界、野指针、内存泄露等。它只关心程序飞的高不高，不关心程序猿飞的累不累。为了解脱程序员，提高开发效率，设计了OOP等更“智能”的编程语言，但是开发容易毕竟来源于对底层的一层一层又一层的包装。完成一个特定操作有了更多的中间环节, 占用了更大的内存空间, 占用了更多的CPU运算。从这个角度看，OOP这种高级语言的流行是因为硬件越来越便宜了。6.4 有哪些看似面向对象实际面向过程风格的代码对面向对象编程有误解，总以为把所有代码都塞到类里，自然就是在进行面向对象编程了三个例子来说明滥用 getter 、setter 方法，违反了面向对象封装的特性正确思路：在设计实现类的时候，除非真的需要，否则尽量不要给属性定义 setter 方法。除此之外，尽管 getter 方法相对 setter 方法要安全些，但是如果返回的是集合容器，那也要防范集合内部数据被修改的风险。Demo 购物车public class ShoppingCart { private int itemsCount;//商品数量 private double totalPrice;//商品总价 private List<ShoppingCartItem> items = new ArrayList<>();//商品列表 public int getItemsCount() { return this.itemsCount; } // 不合理1： itemsCount是私有属性，但是设置了public 的 setter方法，外部可以通过setter方法随意修改值 public void setItemsCount(int itemsCount) { this.itemsCount = itemsCount; } public double getTotalPrice() { return this.totalPrice; } public void setTotalPrice(double totalPrice) { this.totalPrice = totalPrice; } //不合理2：虽然属性可以设置getter方法，但是此处返回的是list集合容器，外部调用还是可以修改里面的数据 //比如： ShoppingCart cart = new ShoppCart();cart.getItems.clear();//清空了购物车 //虽然说需要清空购物车的需求，但是不应该把清空购物车的业务逻辑暴露给上层代码，正确做法应该在类中定义clear()方法，将清空逻辑封装在方法中 //如果想要查看购物车内容，Java 提供的 Collections.unmodifiableList()方法，让getter方法返回一个不可被修改的 UnmodifiableList集合容器 public List<ShoppingCartItem> getItems() { return this.items; } public void addItem(ShoppingCartItem item) { items.add(item); itemsCount++; totalPrice += item.getPrice(); } // ...省略其他方法...}滥用全局变量和全局方法全局变量：静态成员变量（它属于类上的数据，被所有的实例化对象所共有，所以也是全局变量）常量（比如MySQL配置参数等）单例类对象 （因为单例类的对象全局代码只有一份，所以相当于全局变量）全局方法：静态方法正确思路：对于全局变量和全局方法，我们尽量能做到职责单一，定义一些细化的小类，比如redis、mysql相关的，就单独定义，而不是定义一个大而全的。除此之外，如果能将这些类中的属性和方法，划分归并到其他业务类中（就是要拆分出去），那是最好不过的了，能极大地提高类的内聚性和代码的可复用性。定义 数据和方法 分离的类数据定义在一个类中，方法定义在另一个类中，典型的就是目前web开发使用的MVC模式，也是典型的面向过程式开发正确思路：后续添加进来6.5 在面向对象编程中，为什么容易写出面向过程的代码在生活中，你去完成一个任务，你一般都会思考，应该先做什么、后做什么，如何一步一步地顺序执行一系列操作，最后完成整个任务。面向过程编程风格恰恰符合人的这种流程化思维方式。而面向对象编程风格正好相反。它是一种自底向上的思考方式。它不是先去按照执行流程来分解任务，而是将任务翻译成一个一个的小的模块（也就是类），设计类之间的交互，最后按照流程将类组装起来，完成整个任务。

第三章：HTTP报文内的HTTP信息 3.1 HTTP报文HTTP通信过程包括从客户端发往服务器端的请求，以及从服务器端返回客户端的响应用户HTTP协议交互的信息 称为 HTTP报文，实质是多行数据组成的字符串文本请求端(客户端)的HTTP报文 称为 请求报文响应端(服务器端)的HTTP报文 称为 响应报文HTTP报文 主要分为 报文首部、报文主体3.2 请求报文及响应报文的结构 请求报文和响应报文的首部内容有如下构成：请求行：包含用于请求的方法，请求URI和HTTP版本状态行：包含表明响应结果的状态码，原因短语和HTTP版本首部字段：包含表示和响应的各种条件和属性的各类首部，一般有4种首部，通用首部、请求首部、响应首部、实体首部其他：可能包含HTTP的RFC里未定义的首部(cookie等)3.3 编码提升传输速率3.3.1 报文主体与实体主体的差别报文：是HTTP通信协议的基本单位，由8位组字节流组成，通过HTTP通信传输实体：作为请求和响应的有效载荷数据被传输，其内容由实体首部和实体主体组成通常，报文主体 等于 实体主体，HTTP报文主体用于传输请求或响应的实体主体。只有当传输中进行了编码操作，实体主体内容发生改变，才导致他和报文主体产生差异3.3.2 压缩传输 的内容编码作用：HTTP的内容编码，类似于对文本zip压缩的功能内容编码指明应用在实体内容上的编码格式，并保持实体信息原样压缩，内容编码后的实体由客户端接收并负责解码常见的编码格式：gzip(Gun zip)compress(Unix系统标准格式)deflate(zlib)identity(不进行编码)3.3.3 分割发送 的分块传输编码场景：在HTTP通信中，请求的编码实体资源尚未全部传输完成之前，浏览器无法显示请求页面分块传输编码：把实体主体分块的功能3.4 发送多种数据的多部分对象集合场景：类似于发送邮件时，附件中可添加文本、视频、音频、照片等多种数据HTTP协议也采取了 多部分对象集合，发送的一份报文主体中可含有多类型的实体，通常用在图片和文本上传时多部分对象集合 包含的对象如下：multipart/form-data 用户web表单上传multipart/byterange 状态码206，响应报文包含了多个范围的内容时使用HTTP报文使用多部分对象结合，需要在首部字段加上Content-type3.5 获取部分内容的 范围请求 场景： 网速不好或图片过大情况下，下载图片时网络中断，为了避免再次从头开始下载，需要能从之前下载中断处恢复下载功能范围请求：指定范围发送的请求例子:比如一份10000字节大小的资源，使用范围请求，可以只请求 5001-10000子节的资源执行范围查找时，会使用首部字段 Range 来指定资源的byte范围针对返回查找，响应会返回状态码206 Partial Content的响应报文3.6 内容协商 返回最合适的内容例子：比如同一个网站可能有多份相同的静态页面(中文版、英文版)，当浏览器默认语言是中文，则返回中文页面；是英文，则返回英文页面概念： 内容协商机制 是指客户端和服务器端 就响应的资源内容进行交涉，然后提供给客户端最合适的资源。内容协商会以响应资源的语言、字符集、编码方式等作为判断标准包含在请求报文中的某些首部字段 可以作为判断标准AcceptAccept-CharsetAccept-EncodingAccept-LanguageContent-Language内容协商技术 分为三个类型服务器驱动协商：在服务器端自动处理客户端驱动协商：比如js自动切换PC或手机版透明协商：二者结合

第四章：HTTP状态码（常用14种）4.1 状态码告知从服务器端返回的请求结果4.2 2XX 成功，请求被正常处理200 OK 请求被正常处理204 No Content服务器端接收的请求已正常处理，但返回的响应报文中不含实体的主体部分使用场景： 一般只需要从客户端往服务器发送信息，而对客户端不需要发送新内容的情况下206 Partial Content客户端进行了范围请求，而服务器成功执行了这部分请求，响应报文中包含由Content-Range指定范围的实体内容4.3 3XX 重定向301 Moved Permanently永久重定向表示请求的资源已被分配到了新的URI，以后要使用资源新的URI302 Found临时性重定向表示请求的资源已被分配到新的URI，希望本次请求使用新的URI访问303 See Other表示由于请求对应的资源存在另一个URI，应使用GET方法定向获取请求的资源303和302 有着相同的功能，但303明确表示客户端应使用GET方法获取资源304 Not Modified表示客户端发送附带条件的请求时，服务器端允许请求访问资源，但未满足条件的情况304 虽然划到3XX，但与重定向无关307 Temporary Redirect临时重定向，与302相同4.4 4XX 客户端错误400 Bad Request表示请求报文中存在语法错误401 Unauthorized未授权表示发送的请求需要有通过HTTP认证（BASIC认证、DIGEST认证）的认证信息403 Forbidden资源禁止访问表示请求资源的访问被服务器拒绝产生原因：未获得文件系统的访问授权、访问权限有问题404 Not Found资源未找到标明服务器未找到请求的资源，也可以是服务器端拒绝请求但不想说明原因4.5 5XX 服务器端错误500 Internal Server Error服务器内部错误可能是web端存在bug或临时故障503 Service Unavailable表示服务器正在进行超负荷或正在进行停机维护，现在无法处理请求

第二章：简单的HTTP协议2.1 HTTP协议用于客户端和服务器端的通信2.2 通过请求和响应的交换达成通信 客户端发送给服务器端的请求报文请求方法请求URI协议版本可选的请求首部字段内容实体服务器端返回客户端的响应报文协议版本状态码(200,500,301,404)状态码解析语句可选的响应首部字段响应主体2.3 HTTP是无状态协议HTTP协议自身不对请求和响应之间的通信状态进行保存优点：更快的处理大量事务，确保协议的可伸缩性。协议本身并不保留之前一切的请求和响应报文信息缺点：无状态协议导致在很多业务场景下不能友好支持业务处理，登录状态、聊天室通信、直播平台等解决方法：HTTP1.1虽然还是无状态协议，但为了保持状态引入了cookie第三方异步通信框架，支持TCP长连接，如PHP的Swoole，Java的netty，底层C,C++等方式2.4 请求URI定位资源HTTP协议使用URI定位互联网上的资源2.5 告知服务器意图的HTTP方法HTTP1.1 中可使用的方法GET 获取资源POST 传输实体主体PUT 传输文本，类似FTP文本上传HEAD 获取报文头部信息DELETE 删除文件OPTIONS 询问支持的方法TRACE 追踪路径2.6 持久连接 节省通讯量持久连接特点：只要任意一端没有明确提出断开连接，则保持TCP连接状态在HTTP1.1中，所有的连接默认都是持久连接优点：减少了TCP连接的重复建立和断开造成的额外开销，减轻了服务器的负载可实现异步通信2.7 使用cookie的状态管理 概念：cookie技术通过在请求和响应报文中写入cookie信息来控制客户端的状态步骤：cookie会根据从服务器端发送的响应报文的Set-Cookie首部字段信息，通知客户端保存cookie。当下次客户端再次发送请求，自动在请求报文中添加cookie服务器端接收cookie值，检查从哪个客户端发送的请求，并对比服务器端session信息，最后得到之前状态信息

第一章 了解web及网络基础1.1 使用HTTP访问web1.2 HTTP的诞生1.3 网络基础TCP/IPTCP/IP协议族通常使用的网络实在TCP/IP协议族的基础上运行的。而HTTP属于内部的一个子集。1.3.1 TCP/IP协议族协议：计算机与网络设备要相互通信，双方就必须基于相同的方法。比如，如何探测到通信目标、由那一边发起通信、使用哪种语言进行通信、怎样结束通信等。不同硬件、不同操作系统之间的通信，都必须遵循一种规则，这种规则就是协议TCP/IP是互联网相关的各类协议族的总称包括协议：TCP,IP,HTTP,FTP,UDP,DNS等1.3.2 TCP/IP的分层管理分四层： 应用层、传输层、网络层、数据链路层分层优点：可使各层之间相互独立，某一层可以使用其下层提供的服务而不需要知道服务是如何实现的灵活性好，当某一层发生改变时，只要其接口关系不变，则这层以上或以下的应用都不会受到影响结构上解耦，各层可以选择最合适的技术来实现易于实现和维护，因为可以分层次的调试，快捷方便能促进标准化工作，创造更好的互联环境应用层作用：应用层决定了向用户提供应用服务时的通信的活动。 包括：FTP(文件传输协议)、DNS(域名系统)、HTTP(超文本传输协议) HTTP协议就处在应用层传输层作用：传输层对上层应用层，提供处于网络连接中的两台计算机之间的数据传输 包括： TCP(传输控制协议)、UDP(用户数据报协议)网络层(or 网络互联层)作用：网络层用来处理在网络上流动的数据包，该层规定了通过怎样的路径(传输线路)到达对方计算机，并将数据包传送给对方。链路层(or 数据链路层 or 网络接口层)作用：用来处理网络的硬件部分，包括操作系统、硬件的设备驱动、网卡、光纤等物理可见部分。1.3.3 TCP/IP 通信传输流 利用TCP/IP协议族进行网络通信，会通过分层顺序与对方进行通信发送端从应用层往下走，接收端从网络层往上走流程首先，作为发送端的客户端在应用层(HTTP协议)发送一个HTTP请求为了传输方便，在传输层(TCP协议)把从应用层接收到的数据(HTTP请求报文)进行分割，并在各个报文上打上标记序号及端口号，然后转发到网络层在网络层(IP协议)，增加作为通信目的地的Mac地址后，转发给链路层。在此，发送网络的通信请求就准备齐全了接收端的服务器在链路层接收到数据，按序往上层发送，一直到服务器的应用层。发送端在层与层之间传输数据时，每经过一层时必定会打上一个该层所属的头部信息；反之，接收端在曾与层之间传输数据时，每经过一层时会把相应的头部去掉。封装：把数据信息包装起来的方式成为封装1.4 与HTTP关系密切的协议：IP、TCP、DNS1.4.1 负责传输的IP协议IP协议位于网络层TCP/IP中的IP是指国际协议，注意与IP地址区分开IP协议作用：把各种数据包传送给对方，确保数据传输，最重要的两个条件是IP地址和MAC地址，IP地址指明了节点被分配到的地址，Mac地址是指网卡所属的固定地址。IP地址和Mac地址可进行配对。IP地址可更改，Mac地址不可更改通信在进行中转时，会采用ARP协议，利用下一站中转设备的Mac地址来搜索下一个中转目标。ARP协议是一种解析地址的协议,根据通信方的IP地址反查出对应的Mac地址在到达通讯目标前的中转过程中,需要进行路由的选择。路由就像快递的货物集散地，分发网络请求1.4.2 确保可靠性的TCP协议TCP协议位于 传输层 ， 提供可靠的字节流服务字节流服务：将大块数据分割，以报文段为单位的数据包进行管理为了确保数据传输到目标，TCP协议采取了三次握手策略。简单的三次握手流程：发送端首先 发送一个带SYN标志的数据包给对方接收端收到后，回传一个带有SYN/ACK标志的数据包，以示传达确认信息发送端在回传一个带ACK标志的数据包，表示握手结束1.4.3 负责域名解析的DNS服务DNS协议位于应用层作用：提供IP地址与域名之间的解析服务。1.5 各种协议与HTTP协议的关系 1.6 URI和URLURI 统一资源标识符URL 统一资源定位符，URL就是常见的网页地址1.6.1 统一资源标识符URI用字符串标识某一互联网资源，URL表示资源的地点URL是URI的 子集URI例子：ftp://ftp.is.co.za/rfc/rfc.txt http://www.baidu.com/1.6.2 URI格式 协议名：HTTP，HTTPS，FTP等类型登录信息(认证)指定用户名和密码作为从服务器端资源时必要的登录信息，可选服务器地址服务器地址可以是 www.baidu.com的域名，也可以是192.168.1.1的IPv4地址，也可以是IPv6地址服务器端口号带层次的文件路径查询字符串片段标识符

文章Caching in HTTPHTTP 缓存的作用HTTP is typically used for distributed information systems, where performance can be improved by the use of response caches.响应头未配置缓存的情况以下情况，浏览器不会对请求进行缓存 没有配置 cache-control 或 last-modified、expires 只配置了 cache-control，且值为 public 或 private 只配置 last-modified未配置 expirescache-control 未配置或配置，值为 public 或 private将采用 Heuristic Expiration Since origin servers do not always provide explicit expiration times, HTTP caches typically assign heuristic expiration times, employing algorithms that use other header values (such as the Last-Modified time) to estimate a plausible expiration time. The HTTP/1.1 specification does not provide specific algorithms, but does impose worst-case constraints on their results. Since heuristic expiration times might compromise semantic transparency, they ought to used cautiously, and we encourage origin servers to provide explicit expiration times as much as possible.有什么遗漏？service work

星愿浏览器中的 ‘脚本’ 使用星愿浏览器是一款基于开源谷歌内核的浏览器，兼容Chrome扩展，个性化界面，漫画阅读模式，漫画搜索，视频下载，视频弹窗，鼠标手势，超级拖拽，多线程高速下载等等。还不了解星愿浏览器的小伙伴们 相信你们读了这篇文章也会有一种相见恨晚的感觉插件功能展示多少次因为你的浏览器下载速度超慢而烦恼？又多少次因为网页看片的速度不可控而叫嚣？或者又多少次因为看不懂英文文档而错失一手好资源？放心！这一切的一切将在今天终结！请让小编带领大家体会星愿浏览器中脚本的奥妙：话不多说 先上几个展示图： XX网盘的网页高速下载网页看片倍速选择英文文档在线翻译浏览器下载奉上官网地址：http://www.twinkstar.com/插件使用插件下载点击首页面的插件/扩展 里面会推荐许多不错的插件 也可以利用下面的网址进行下载：https://greasyfork.org/zh-CN 插件安装为了便于插件安装我建议首先安装一个插件管理器Tampermonkey 这里面可以很方便的导入本地插件和管理插件ps:在星愿浏览器推荐的插件页面下载后 会自动导入浏览器 下面主要说从各大网站下载的插件的导入方法导入本地插件 点击Tampermonkey图标->管理面板->实用工具->选择导入插件管理对于浏览器自动导入的插件： 右键插件图标->管理插件程序->选择开启关闭对于本地导入的插件： 点击Tampermonkey图标->管理面板->已安装脚本->选择相应操作插件推荐Translate Man Plus – 翻译侠升级版 翻译外语网站Advertising Terminato - 网页广告过滤PDF Mage – 把网页转变为PDFEnable Copy – 轻量级右键解锁扩展PanDownload – 百度网盘下载好帮手下面就开始测试你们的各种神操作吧 !

Differences between HTTP1.1 and HTTP2前言一次面试被问到http1.1和http2有什么区别，当时随便答了些跟keep-alive和upgrade相关的内容，从面试官的眼神里体会到了，我的回答应该差的还挺远的，查了下资料总结如下： 背景http1.0协议1987年发布，后来www发展越来越普及，为了提高http1.0的传输效率，在1997年又公布了http1.1，主要提出了对一个tcp连接的复用，也就是熟知的connection: keep-alive特性。然而，为了进一步提高基于http协议的应用体验，比如越来越多的移动设备移动娱乐（图片、视频）的需求，google提出了spdy协议，就是为了进一步提高http的性能，提高用户体验。http2协议就是基于spdy，目前应该还是提案阶段。而且提出spdy的同期，google又提出了quic协议，quic提出了spdy中存在的各种问题及部分的解决方案，并提出基于udp方式模拟tcp的面向连接的方式。 Transmission Modelhttp1.1和http2的第一个不同在于传输模型的不同。 http1.0中，对于资源请求是一个request一个response，几乎所有tcp都是短链接（除非主动开启keepalive特性）。对于一个页面的请求，通常包含了很多资源，如果需要渲染一个包含多资源的页面，只是一应一答的方式，则需要重复建多个tcp连接，增加了资源开销。因此http1.1中，默认开放了keep-alive特性，多个资源的请求可以服用同一个tcp，降低了建链拆链的开销。这种方式被称为pipeline。pipeline的问题是，虽然tcp被服用了，但对资源的请求是串行的，如果排在前面的资源请求出现阻塞，则会影响后续的资源传输。这被称为HOL(head of line) blocking。如果为了解决这个问题，采用并行建多个tcp链接的策略，那么无论是客户端还是服务端，都面临更高的开销，尤其是对服务端而言，在并发连接数有上限的情况下则并发客户端服务数量就会大幅度降低。 http2采用了底层流技术，这个流技术对http上层的语义没有影响，只是在数据流的传输上，不再采用plain text这种方式。当一次请求中包含多个资源的请求时，将不同的资源映射到不同的二进制流上，每个流有唯一id，并且通过parent字段描述不同的流资源间的相互依赖关系。同时，每个流还可以指定优先级，优先级数字越大则优先应答。对于一个资源的数据，通过流传输时，数据被进一步划分成更小的单位，称为frame。在一个流通道中（流通道建立在tcp协议上），可以同时传输不同id的流，实现多个资源的并行，且资源传输的先后顺序可以有应用通过定义优先级的方式灵活定制。 flow control第二个不同是在flowcontrol上的实现方式的改变。 对于客户端和服务端，本身都有一个buffer，用于缓存不完整的信息，待缓存中的信息完整后，一并处理。考虑如果有大资源需要传输时，可能就会发生buffer溢出，因此tcp协议中采用了滑动窗口的方式避免buffer溢出。接收端在接收数据，发送ack，在ack中可以上报本地buffer中尚存的空余空间，发送端可以根据上报的空余空间，调整 发送速率。一旦空余空间为0，则发送端停止发送。当接收端处理完buffer中的数据后，再请求发送端继续发送。http1.1的流控即依赖了tcp的滑动窗口实现。 由于http2.0提出了并行流的传输方式，它的flow control也是按流来约定的。这个约定被放到了应用层，即应用可以基于自身的buffer请求动态协商缓存大小。同时，在端到端传输过程中流经的中间节点也可以识别flow control参数，从而实现更好的流控。 Predicting Resource Requests第三个不同是资源预请求策略的不同。 在一次页面的http请求中，为了渲染一个页面，除了需要请求html页面文件外，还需要请求css。http1.1中，如果预测到某些资源在后续的请求中必定会发送，就可以在第一的请求中将这部分资源一并应答给客户端，这种称为resource inlining。但这样的方式有一定问题，比如可能会重复应答客户端已有的资源，当被inline的资源非常大的情况下，对网络资源的浪费也非常大，所以在实际情况下，很少有应用这种方式的。 http2提出了叫server push的方式。如果预测到某些资源是可能会被后续请求的，则先向客户端推送一条PUSH_PROMISE帧，在这条帧中描述了即将推送过来的内容的元数据。如果客户端不需要某些资源，则可以应答一条RST_STREAM来取消某些资源。这样就避免了资源浪费。同时，客户端还可以发送SETTINGS帧来改变server push的行为。 Compression最后一个不同是压缩。http1.1只对消息体进行压缩，不对http header压缩，因为header一般很小。但是当请求量比较大时，header对网络带宽的开销也会增大。http2定义hpack的方式对header也进行了压缩，尤其是当两次请求或应答时头部仅有部分差异时，只传输差异部分。 Conclusion以上是几个主要的不同点，如multiplexing, stream priorization, flow control, server push and compression。如果要了解http1.1和http2性能上的差异分析，可以参考 HTTP/2 – A Real-World Performance Test and Analysis，同时可以关注ietf关于http2协议的文档。

HTTP 协议可以说是开发者最熟悉的一个网络协议，「简单易懂」和「易于扩展」两个特点让它成为应用最广泛的应用层协议。 虽然有诸多的优点，但是在协议定义时因为诸多的博弈和限制，还是隐藏了不少暗坑，让人一不小心就会陷入其中。本文总结了 HTTP 规范中常见的几个暗坑，希望大家开发中有意识的规避它们，提升开发体验。 1.RefererHTTP 标准把 Referrer 写成 Referer（少些了一个 r），可以说是计算机历史上最著名的一个错别字了。 Referer 的主要作用是携带当前请求的来源地址，常用在反爬虫和防盗链上。前段时间闹的沸沸扬扬的新浪图床挂图事件，就是因为新浪图床突然开始检查 HTTP Referer 头，非新浪域名就不返回图片，导致很多蹭流量的中小博客图都挂了。 虽然 HTTP 标准里把 Referer 写错了，但是其它可以控制 Referer 的标准并没有将错就错。 例如禁止网页自动携带 Referer 头的 <meta> 标签，相关关键字拼写就是正确的： <!-- 全局禁止发送 referrer --><meta name="referrer" content="no-referrer" />还有一个值得注意的是浏览器的网络请求。从安全性和稳定性上考虑，Referer 等请求头在网络请求时，只能由浏览器控制，不能直接操作，我们只能通过一些属性进行控制。比如说 Fetch 函数，我们可以通过 referrer 和 referrerPolicy 控制，而它们的拼写也是正确的： fetch('/page', { headers: { "Content-Type": "text/plain;charset=UTF-8" }, referrer: "https://demo.com/anotherpage", // <- referrerPolicy: "no-referrer-when-downgrade", // <-});一句话总结：凡是涉及到 Referrer 的，除了 HTTP 字段是错的，浏览器的相关配置字段拼写都是正确的。 二.「灵异」的空格1.%20 还是 + ？这个是个史诗级的大坑，我曾经被这个协议冲突坑了一天。 ...

0x000 概述最近专注于 HTTP 的学习，这篇文章浅谈一下我学习 HTTP 过程中的心得，当作过渡性总结。如果能对各位有所帮助，最好不过。 0x001 HTTP 协议说起 HTTP，自然逃不过 HTTP 协议本身，以下是我的学习资料： 《图解 HTTP》《HTTP 权威指南》http/0.9http/1.0http/1.1 系列从 0.9 到 QUIC《图解 HTTP》是入门精品，是初学者的福音。 《HTTP 权威指南》对于深入学习的需求也可以满足。 深入学习之后我觉得应该回归本质，也就是 HTTP 规范自身，rfc7230-7235 就是这接下来的不二选择。 其实前两本书已经够了，可是我发现单纯看书无法掌握技术发展的脉络，譬如 HTTP/0.9、HTTP/1.0、HTTP/1.1、HTTP/2、HTTP/3 是如何发展的。规范虽然晦涩，却有很明显的历史发展性；虽然不够详细，却非常全面。 http/0.9 协议很简单，只有一行，就是simple-request： SimpleRequest = GET <uri> CrLfhttp/1.0 和 和 HTTP/1.1 变化不大。 多部署服务器默认 keep-alive 持久连接引入传输编码有人说作为前端，HTTP 协议使用的并不深，不需要掌握太深太细。但是我在学习之后却发现并不是这样，学习是一回事，实践是另一回事。 比如： 在往常思考 HTTP 的时候，总是将请求分为 client 和 server 来思考。 对于 network 中的一切都是忽略不计的，但深入学习之后才会发现，真实世界的网络拓扑可是能是这样的 并且最后处理我们请求的并不一定是目标服务器，而是中间的某个设备，可能是代理，也可能是缓存服务，或者网关。 我以为 HTTP 的报文结构从来是这样的：request-ling/status-lineheader-sectionrequest-body/response-body但其实也有可能是(Range Request)： HTTP/1.1 206 Partial ContentDate: Wed, 15 Nov 1995 06:25:24 GMTLast-Modified: Wed, 15 Nov 1995 04:58:08 GMTContent-Length: 1741Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES--THIS_STRING_SEPARATESContent-Type: application/pdfContent-Range: bytes 500-999/8000...the first range...--THIS_STRING_SEPARATESContent-Type: application/pdfContent-Range: bytes 7000-7999/8000...the second range--THIS_STRING_SEPARATES--看见了吗？HTTP 的 Header 并不是只能出现在 request-line/response-line 下面 ...

手把手教你用 Node 实现 HTTP 协议（一）在开始文章前，我们需要对一些基础知识有一些了解，比如 HTTP 协议是什么，HTTP 报文的格式，HTTP 协议的基础等等； 本篇文章将会使用到以下知识，希望读者在开始阅读前对基础知识有一些掌握： Node 的基本用法；Typescript 语法的基本理解；Postman 的基本使用方法；我们最终的目标是实现由接口工具 Postman 发起一个请求，我们的 http 协议将请求的信息解析完成后，由我们的 http 服务端返回一个请求信息的 JSON 字符串，效果图如下： 我们的代码最终调用效果如下： import http from './src/Http';const server = http.createServer((req, res) => { res.setHeader('Content-Type', 'application/json') res.end(200, JSON.stringify(req.httpMessage));});server.listen(8888, () => { console.log("server is listening in 8888...");});有些朋友可能觉得上面的代码有点眼熟，其实上面的代码调用看起来就像是 Node 的 http 模块，我们这个教程的目的也可以说是实现一个 http 模块，可以接受 HTTP 请求，并且响应处理结果。 现在我们先来了解几个开头提到的基础知识： HTTP 协议是什么？HTTP是一个属于应用层的面向对象的协议，由于其简捷、快速的方式，适用于分布式超媒体信息系统。我们使用 HTTP 协议规范来完成客户与服务器之间的通信，形象一点的说就是通信的双方需要按照规范来进行通信。比如状态码就是一个规范，状态码规定了 1xx~5xx 代表的含义，500 通常代表服务器内部错误，然而你也可以用 500 代表服务器成功处理，但是这样就属于不遵守规范了。HTTP 协议就是由一些预定义的规范所组成的最佳实践，实现 HTTP 协议换个说法就是用代码实现这些规范，遵循 HTTP 协议规范的双方可以进行通信。HTTP 报文的格式如果说 HTTP 是因特网的信使，那么 HTTP 报文就是它用来搬东西的包裹。HTTP 报文是简单的格式化数据块。它们由三部分组成：对报文进行描述的起始行（start line）、包含属性的首部（header）块、以及可选的包含数据的主体（body）部分。起步行和首部就是由行分隔的 ASCII 文本。每行都以一个 由两个字符组成的行终止序列作为结束，其中包括一个回车符（ASCII 码 13）和一个换行符（ASCII 码 10）。这个行终止序列可以写作 CRLF。报文的语法 ...

文章链接：http模块和fs模块http模块response对象常用方法： response.writeHead(200,{'Content-Type':'text/plain:charset=UTF-8'});此方法只能在消息上调用一次，并且必须在调用response.end()之前调用。 response.write()发送一块相应主体，用来给客户端发送相应数据。write可以使用多次，但是最后一定要使用end来结束响应，否则客户端会一直等待。response.end()此方法向服务器发出信号，表示已发送所有响应头和主体，该服务器应该视为此消息完成。必须在每个响应上调用方法response.end()。const http = require('http');http.createServer(function(req, res) { res.writeHead(200, {'Content-Type': 'text/html'}); res.write('hello world'); res.write('<h1>hello node.js</h1>'); res.end();}).listen(8080);console.log('Server running at http://127.0.0.1:8080');request对象 request.url获取请求路径，获取到的是端口号之后的那一部分路径，也就是说所有的url都是以/开头的，判断路径处理响应。request.socket.localAddress获取ip地址。request.socket.remotePort获取源端口。const http = require('http');let server = http.createServer();server.on('request', function(req, res) { console.log('收到请求，请求路径是：' + req.url); console.log('请求我的客户端的地址是：', req.socket.remoteAddress, req.socket.remotePort); let url = req.url; res.writeHead(200, {'Content-Type': 'text/html;charset=UTF-8'}); switch (url) { case '/': res.end('<h1>Index page</h1>'); break; case '/login': res.end('<h1>Login page</h1>'); break; default: res.end('404 Not Found.'); break; }});server.listen(8080, function() { console.log('服务器启动成功，可以访问了。。。');});fs模块所有文件系统操作都具有同步和异步的形式。异步方法中回调的第一个参数总是留给异常参数，如果方法成功完成，那么这个参数为null或undefined。 因为Node.js是单线程的，所以在Node.js中绝大部分需要在服务器运行期反复执行业务逻辑的代码，必须使用异步代码，否则，同步代码在执行期，服务器将停止响应。 服务器启动时如果需要读取配置文件，或结束时需要写入到状态文件时，可以使用同步代码，因为这些代码只在启动和结束时执行一次，不影响服务器正常运行时的异步执行。 ...

前言HTTP/2 相比于 HTTP/1.1，可以说是大幅度提高了网页的性能，只需要升级到该协议就可以减少很多之前需要做的性能优化工作，当然兼容问题以及如何优雅降级应该是国内还不普遍使用的原因之一。 虽然 HTTP/2 提高了网页的性能，但是并不代表它已经是完美的了，HTTP/3 就是为了解决 HTTP/2 所存在的一些问题而被推出来的。 一、HTTP/1.1发明以来发生了哪些变化？如果仔细观察打开那些最流行的网站首页所需要下载的资源的话，会发现一个非常明显的趋势。 近年来加载网站首页需要的下载的数据量在逐渐增加，并已经超过了2100K。但在这里我们更应该关心的是：平均每个页面为了完成显示与渲染所需要下载的资源数已经超过了100个。 正如下图所示，从2011年以来,传输数据大小与平均请求资源数量不断持续增长，并没有减缓的迹象。该图表中绿色直线展示了传输数据大小的增长，红色直线展示了平均请求资源数量的增长。 HTTP/1.1自从1997年发布以来，我们已经使用HTTP/1.x 相当长一段时间了，但是随着近十年互联网的爆炸式发展，从当初网页内容以文本为主,到现在以富媒体（如图片、声音、视频）为主,而且对页面内容实时性高要求的应用越来越多(比如聊天、视频直播),于是当时协议规定的某些特性，已经无法满足现代网络的需求了。 二、HTTP/1.1的缺陷1.高延迟--带来页面加载速度的降低虽然近几年来网络带宽增长非常快，然而我们却并没有看到网络延迟有对应程度的降低。网络延迟问题主要由于队头阻塞(Head-Of-Line Blocking),导致带宽无法被充分利用。 队头阻塞是指当顺序发送的请求序列中的一个请求因为某种原因被阻塞时，在后面排队的所有请求也一并被阻塞，会导致客户端迟迟收不到数据。针对队头阻塞,人们尝试过以下办法来解决: 将同一页面的资源分散到不同域名下，提升连接上限。 Chrome有个机制，对于同一个域名，默认允许同时建立 6 个 TCP持久连接，使用持久连接时，虽然能公用一个TCP管道，但是在一个管道中同一时刻只能处理一个请求，在当前的请求没有结束之前，其他的请求只能处于阻塞状态。另外如果在同一个域名下同时有10个请求发生，那么其中4个请求会进入排队等待状态，直至进行中的请求完成。Spriting合并多张小图为一张大图,再用JavaScript或者CSS将小图重新“切割”出来的技术。内联(Inlining)是另外一种防止发送很多小图请求的技巧，将图片的原始数据嵌入在CSS文件里面的URL里，减少网络请求次数。.icon1 { background: url(data:image/png;base64,<data>) no-repeat; }.icon2 { background: url(data:image/png;base64,<data>) no-repeat; }拼接(Concatenation)将多个体积较小的JavaScript使用webpack等工具打包成1个体积更大的JavaScript文件,但如果其中1个文件的改动就会导致大量数据被重新下载多个文件。2.无状态特性--带来的巨大HTTP头部由于报文Header一般会携带"User Agent""Cookie""Accept""Server"等许多固定的头字段（如下图），多达几百字节甚至上千字节，但Body却经常只有几十字节（比如GET请求、204/301/304响应），成了不折不扣的“大头儿子”。Header里携带的内容过大，在一定程度上增加了传输的成本。更要命的是，成千上万的请求响应报文里有很多字段值都是重复的，非常浪费。 3.明文传输--带来的不安全性HTTP/1.1在传输数据时，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份，这在一定程度上无法保证数据的安全性。 你有没有听说过"免费WiFi陷阱”之类的新闻呢？黑客就是利用了HTTP明文传输的缺点，在公共场所架设一个WiFi热点开始“钓鱼”，诱骗网民上网。一旦你连上了这个WiFi热点，所有的流量都会被截获保存，里面如果有银行卡号、网站密码等敏感信息的话那就危险了，黑客拿到了这些数据就可以冒充你为所欲为。 4.不支持服务器推送消息三、SPDY 协议与 HTTP/2 简介1.SPDY 协议上面我们提到,由于HTTP/1.x的缺陷，我们会引入雪碧图、将小图内联、使用多个域名等等的方式来提高性能。不过这些优化都绕开了协议，直到2009年，谷歌公开了自行研发的 SPDY 协议，主要解决HTTP/1.1效率不高的问题。谷歌推出SPDY，才算是正式改造HTTP协议本身。降低延迟，压缩header等等，SPDY的实践证明了这些优化的效果，也最终带来HTTP/2的诞生。 HTTP/1.1有两个主要的缺点：安全不足和性能不高，由于背负着 HTTP/1.x 庞大的历史包袱,所以协议的修改,兼容性是首要考虑的目标，否则就会破坏互联网上无数现有的资产。如上图所示,SPDY位于HTTP之下，TCP和SSL之上，这样可以轻松兼容老版本的HTTP协议(将HTTP1.x的内容封装成一种新的frame格式)，同时可以使用已有的SSL功能。 SPDY 协议在Chrome浏览器上证明可行以后，就被当作 HTTP/2 的基础，主要特性都在 HTTP/2 之中得到继承。 2.HTTP/2 简介2015年，HTTP/2 发布。HTTP/2是现行HTTP协议（HTTP/1.x）的替代，但它不是重写，HTTP方法/状态码/语义都与HTTP/1.x一样。HTTP/2基于SPDY，专注于性能，最大的一个目标是在用户和网站间只用一个连接（connection）。从目前的情况来看，国内外一些排名靠前的站点基本都实现了HTTP/2的部署，使用HTTP/2能带来20%~60%的效率提升。 HTTP/2由两个规范（Specification）组成： Hypertext Transfer Protocol version 2 - RFC7540HPACK - Header Compression for HTTP/2 - RFC7541四、HTTP/2 新特性1.二进制传输HTTP/2传输数据量的大幅减少,主要有两个原因:以二进制方式传输和Header 压缩。我们先来介绍二进制传输,HTTP/2 采用二进制格式传输数据，而非HTTP/1.x 里纯文本形式的报文 ，二进制协议解析起来更高效。 HTTP/2 将请求和响应数据分割为更小的帧，并且它们采用二进制编码。 ...

原文地址 https://mojotv.cn/go/hardware-footprint-gui-proxy

概念浏览器缓存主要分为本地缓存（又称强缓存）和弱缓存（又称协商缓存） 强缓存用户发送的请求，直接从客户端缓存中获取资源、不发送到服务器。不会与服务器发生任何的交互行为弱缓存用户发送的请求，发送给服务器，由服务器判断是否从缓存中拿资源1、第一次请求的时候，浏览器无缓存，用户发送请求到服务端，服务端响应请求。此时浏览器端将响应进行缓存。具体大概是，第一次请求到服务端时，服务端会把页面的最后修改时间通过在response-header的last-modified告诉浏览器。浏览器将页面的最后修改时间进行记录。还会生成一个Etag。2、用户第二次在访问的时候，浏览器会判断缓存是否过期， 没有过期，直接从缓存中获取资源进行呈现。没有过期，会有两种缓存机制的方式，如下：1、第一种 是查看是否有Etag，如果有查看响应服务端资源版本的报文头信息Etag是否发生改变（就是查看Etag，如果发送给服务端的某个资源发生变化了，Etag就会响应的发生变化），如果发生改变，向服务器请求的时候，会在request-header中添加if-none-match属性，属性值就是Etag的值，本次请求，发送给服务端之后，服务端将属性值和存的Etag进行对比。如果服务端验证资源的Etag没有改变的时候，将返回304状态，告诉浏览器使用本地缓存。因为资源没有更新。如果Etag有改变的时候，会返回200把新的资源和新的Etag响应给浏览器。2、第二种 是查看是否有last-modified，查看值是多少，它代表当前资源的缓存时间/即页面的最后修改时间，然后看当前资源的request-header中的last-modified-since。这个是告诉服务器当前资源的缓存时间，请求也会把此时间发送给服务端，服务端会将两者进行对比，如果时间一致，证明没有修改，服务器会返回304，告诉浏览器直接从本地缓存中获取资源，如果时间不一致，会返回200新的资源给浏览器。浏览器拿到之后会丢弃掉之前缓存的，把新的资源缓存，然后每一次请求都会用这种方式。3、如果既没有Etag又没有last-modified,就会直接向服务器请求，服务器响应，然后进行缓存协商。最后呈现。你就记住，Etag是结合if-none-match使用的， last-modified是结合last-modified-since使用的，然后搞清楚两者的结合使用关系即可。

来自 @okzero 的消息《Everything软件使用提醒》： 提醒一下吧！可能有些人已经看到这个消息了。 关于 “Everything” 软件的使用安全，用 Google 搜索 “xxx” 会出现很多电脑文档，直接就可以访问他人电脑文件了。启用 http 服务器功能内网应该是没问题的，但公网就很不安全了，可能被 Google 爬，至少也要加密先。 Everything 安全漏洞原因作为一款优秀的文件检索工具，Everything 提供了一个名为 HTTP 服务器的功能，它可以让用户在本地或局域网上的其他电脑使用浏览器进行搜索，并支持文件下载： 比如办公室有一台电脑打开了 HTTP 服务器 功能，相当于这台电脑成为了一台网页服务器，办公室的所有电脑都可以通过指定端口访问到这个搜索页面： 这是一个在互联网上泄漏的 Everything HTTP 服务器搜索页面截图并且还可以进行文件下载。这在本机，或者局域网内是一件非常方便的事情。但这个页面被搜索引擎检索，就不是一件好事了。 导致的后果当你的 Everything 搜索页面被公网搜索引擎检索并被其他人发现后，你的硬盘内容就完全暴露在了陌生人面前，对方可以随意浏览、搜索并下载你的文件。 如何解决如果要继续使用 HTTP 服务器功能： 请为 HTTP 服务器设置用户名密码关闭路由器 DMZ 主机功能关闭 HTTP 服务器端口的外网访问权限如果不使用 HTTP 服务器功能： 确保 Everything 的 HTTP 服务器功能关闭检查路由器的防火墙设置而对于办公室用户，尽快通知 IT 人员。 另外，相信 Everything 会很快修复此问题。作为一款使用了超过 10 年的必备软件，青小蛙对 Everything 还是十分有感情的。

一、工具介绍1、简介Apache httpd本身是一个提供http服务工具.其内含一个 ApacheBench(ab) 命令,可用于模拟并发HTTP请求.ab命令使用说明,见官网 2、适用场景1、只适用 http / https 协议2、请求参数只能写死，不能随机产生,合适像查询这种幂等接口压测3、产出简单报告（txt/html），不支持图二、下载安装1、Window下载安装国内推荐下载地址 下载后解压即可使用，推荐配置解压路径到系统环境变量，这样以后命令窗口就能识别到ab命令. 懒人一键下载: httpd-2.4.41-win64-VS16.zip、httpd-2.4.41-win32-VS16.zip 2、Linux安装安装命令 sudo apt install apache2如果需要最小安装,不需要apache提供的http功能,则使用下面命令安装 sudo apt install apache2-utils3、验证在命令窗口输入 ab -h 命令后，能显示ab命令使用提示，即安装完成，如下。 ~ » ab linbo@LinBoab: wrong number of argumentsUsage: ab [options] [http[s]://]hostname[:port]/pathOptions are: -n requests Number of requests to perform -c concurrency Number of multiple requests to make at a time -t timelimit Seconds to max. to spend on benchmarking This implies -n 50000 -s timeout Seconds to max. wait for each response Default is 30 seconds -b windowsize Size of TCP send/receive buffer, in bytes -B address Address to bind to when making outgoing connections -p postfile File containing data to POST. Remember also to set -T -u putfile File containing data to PUT. Remember also to set -T -T content-type Content-type header to use for POST/PUT data, eg. 'application/x-www-form-urlencoded' Default is 'text/plain' -v verbosity How much troubleshooting info to print -w Print out results in HTML tables -i Use HEAD instead of GET -x attributes String to insert as table attributes -y attributes String to insert as tr attributes -z attributes String to insert as td or th attributes -C attribute Add cookie, eg. 'Apache=1234'. (repeatable) -H attribute Add Arbitrary header line, eg. 'Accept-Encoding: gzip' Inserted after all normal header lines. (repeatable) -A attribute Add Basic WWW Authentication, the attributes are a colon separated username and password. -P attribute Add Basic Proxy Authentication, the attributes are a colon separated username and password. -X proxy:port Proxyserver and port number to use -V Print version number and exit -k Use HTTP KeepAlive feature -d Do not show percentiles served table. -S Do not show confidence estimators and warnings. -q Do not show progress when doing more than 150 requests -l Accept variable document length (use this for dynamic pages) -g filename Output collected data to gnuplot format file. -e filename Output CSV file with percentages served -r Don't exit on socket receive errors. -m method Method name -h Display usage information (this message) -I Disable TLS Server Name Indication (SNI) extension -Z ciphersuite Specify SSL/TLS cipher suite (See openssl ciphers) -f protocol Specify SSL/TLS protocol (SSL2, TLS1, TLS1.1, TLS1.2 or ALL) -E certfile Specify optional client certificate chain and private key三、测试使用1、命令格式ab [选项/参数] [URL地址]2、常用选项参数说明-c并发请求数量,默认1个-n总请求数量-T设置POST/PUT请求方式的Content-type请求头参数,如:<p>-T "application/x-www-form-urlencoded"</p>-pPOST请求发送的请求数据,需要和-T参数一起配合使用-uPUT请求发送的请求数据,需要和-T参数一起配合使用-m自定义HTTP请求方法,如DELETE/HEAD-H添加自定义请求头参数,使用冒号分离请求头的key和value,格式如:<p>-H "Accept-Encoding: zip/zop;8bit"</p>3、使用例子可以使用网上一些开发的服务.这里使用到一个Java Web服务，只需要本地安装JDK8或JDK8以上版本，即可直接运行. ...

TCP 位于传输层，提供可靠的字节流服务。 可靠的字节流服务：TCP 协议为了传输方便，将大块数据分割成以报文段（segment）为单位的数据包进行管理，并能够把这些数据准确可靠的传递给对方。TCP报文段格式下面是一张 TCP 报文格式的图片： 其中，几个比较重要的字段如下： 序号和确认号每个 TCP 报文内都有序号和确认号，结合重传机制保障数据传输的可靠性 seq 序号：TCP 连接字节流中每一个字节都会有一个编号，当建立连接的时候，TCP 选定一个初始序号（随机数），之后每发送一个数据包（消息），就将序号+1，保证每发送不同的数据包，数据包的序号都是不同的 ack 确认号：表示希望收到的下一个报文段部分的第一个字节的序号是 seq+1，以前的字节已经收到过了，ACK标志位被设置为1的时候，才会发送ack确认号。6个标志位TCP 报文共有6个标志位，每个占1位，共6位，每一位的值只有0和1 SYN：同步标志位，SYN=1 时，表示这是一个连接请求报文ACK：确认标志位，ACK=1 时，表示确认号有效，当 TCP 发送 ACK 时，相当于返回结果，需要带有确认序号，以便跟发送的消息对应起来。FIN：终止标志位，FIN=1 时，表示此报文段的发送方数据已发送完毕，要求释放 TCP 连接PSH：推送标志位，PSH=1 时表示该段报文高优先级，接收方应尽快推送给应用程序，而不用等整个 TCP 缓存都填满了在交付URG：紧急标志位，URG=1 时表示紧急指针有效，此报文中有紧急数据要尽快传送，不需要按照原来的排列顺序来传送RST：复位标志位，RST=1 时表示 TCP 连接中出现错误，需要释放并重新建立连接建立 TCP 连接：三次握手TCP 连接的建立采用客户-服务器模式，主动发起连接建立的应用进程叫做客户，被动等待连接建立的应用进程叫做服务器，以下是建立 TCP 连接的过程： 第一次握手客户端向服务端发送请求连接报文，将报文同步标志位 SYN 的值设置为1，表示要创建连接，等待服务器确认，并进入SYN_SENT状态。（报文首部：SYN=1， 初始序号 seq=x（x为随机生成数值）） 第二次握手服务端接收到客户端的请求，回复给客户端确认报文，将报文确认标志位 ACK 的值设置为1，告诉客户端已收到它的请求，同意创建连接，并进入SYN_RECV状态。（ACK=1，确认号 ack=x+1，SYN=1，初始序号 seq=y） 第三次握手客户端接收到服务端的确认报文之后，为了防止意外，再次向服务端发出确认报文，将报文ACK 的值设置为1，当服务端收到客户端发来的确认报文之后，TCP 连接建立，客户端和服务端都进入ESTABLISHED状态，完成三次握手，以后就可以开森的传递数据了。（报文首部：ACK=1, 确认号 ack=y+1, 序号 seq=x+1（服务端传过来的ack的值） 断开 TCP 连接：四次挥手由于 TCP 连接是双工的，因此每个方向都必须单独进行关闭。当一方完成它的数据发送任务后就可以发送一个FIN终止标志位来终止这个方向上的连接，收到一个FIN就意味着这一方向上没有数据流动。一个 TCP 连接在收到一个 FIN 后仍能发送数据，首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。 ...

为什么要使用缓存 ？缓存是可以自动保存为常见文档副本的 HTTP 设备，当 web 请求抵达缓存时。如果本地有已缓存了的副本，就可以从本地存储设备上直接提取这个文档，而不用去服务器中提取。 缓存可以帮助我们： 缓解服务器压力，提高了网站性能加快了网页加载速度，提升了用户的使用体验减少了冗余的数据传输，帮助网络运营减少了流量HTTP 缓存处理流程 第一步：接收请求并解析缓存从网络中读取抵达的请求报文，然后将请求报文解析成片段，将首部的各个部分放入易于操作的数据结构中，这样缓存就更容易处理首部字段并修改它们了 第二步：查找缓存副本缓存获取 URL，查找本地副本。本地副本存储在内存、本地磁盘等地方，缓存会确认本地缓存中是否有这个对象，查找会有以下两种结果： 第一种结果：未找到可用副本到达缓存的请求因为没有查找到可用的副本，会将请求转发给原始服务器去获取资源（缓存未命中），并将该资源缓存在本地 第二种结果：已找到可用副本到达缓存的请求查找到了可用副本，在向客户端提供该文档之前，HTTP 会对此文档进行新鲜度检测。 HTTP 通过缓存将服务器文档的副本保留一段时间，这段时间内（默认一小时或一天）都认为文档是新鲜的，缓存可以在不联系服务器的情况下直接提供向客户提供该文档（缓存命中，200 OK）。 一旦已缓存副本停留的时间过长，超过了文档的新鲜度限值，就会认为该对象不新鲜，这种情况下缓存会向服务器发送一个再验证请求来进行确认，以便查看文档是否发生了变化，再验证可能的结果如下： 再验证命中如果内容没有变化，服务器会向客户端发送一个HTTP 304 Not Modified 的响应，缓存知道副本仍然有效了，就会对该缓存文档新鲜度进行更新，然后将缓存文档返回给客户端。 再验证未命中如果服务器的内容有变化，就从服务器上重新获取该资源，并更新本地的缓存数据（200 OK） 对象被删除如果内容被删除，服务器返回一个404 Not Found，缓存也会将其副本删除掉。 新鲜度检测流程： 浏览器第一次向服务器发起请求：服务端在响应头返回协商缓存的头属性：ETag、Last-Modified； 浏览器第二次向服务器发发起请求：在请求头中带上与 ETag 对应的 If-Not-Match（值为上次请求时返回响应头的 ETag 值）和与 Last-Modified 对应的 If-Modified-Since。 服务器接收到这两个参数后会作比较，看看资源有没有失效或者有更改。如果返回的是 304 状态码，则表示资源没有任何修改，缓存会标记副本为新鲜并把资源返回给客户端，否则服务器会返回200 状态码，直接返回一份新的资源。 第三步：创建响应缓存将副本返回给客户端的时候，会将已缓存的服务器响应首部作为响应首部的起点，然后在这基础上对首部进行了修改和扩充，以便于客户端的要求相匹配，而且还会插入新鲜度的值信息（Cache-control、Age、Expires首部）及一个Via首部来说明该请求来自代理缓存。 第四步：发送相应给客户端响应首部准备完毕后，缓存会将该响应返回给客户端。 HTTP 缓存的分类HTTP 可分为强缓存和协商缓存，两者的本质区别就在于是否要和服务器进行交互，详细如下： 第一类：强缓存在缓存未失效的情况下，可直接由缓存提供资源给客户端使用（状态码 200），而不用去请求服务端。缓存命中就属于强缓存。 和强缓存有关属性有（优先级由高到低）：Pragma、Cache-Control、Expires Pragmahtml<meta http-equiv='Pragma' content='no-cache'/> 如果 html 的 meta 标签如果这样的话，它的意思是可以告诉浏览器当前页面不被缓存，每次访问都需要去服务器拉取。这种方法使用上很简单，但只有部分浏览器可以支持，而且所有缓存代理服务器都不支持，因为代理不解析HTML内容本身。 上述代码的作用是告诉浏览器当前页面不被缓存，每次访问都需要去服务器拉取。这种方法使用上很简单，但只有部分浏览器可以支持，而且所有缓存代理服务器都不支持，因为代理不解析HTML内容本身。 Expirehttp/1.0 提出，一个表示资源过期时间的 header，描述的是一个绝对时间，由服务器返回，值是用 GMT 格式的字符串表示，如：Expires:Thu, 31 Dec 2016 23:55:55 GMT ...

摘要： 理解HTTP协议... 原文：用了这么久HTTP, 你是否了解Content-Length和Transfer-Encoding ?作者：朴瑞卿的博客由Content-Length导致的问题引发的一系列思考:前段时间开发API网关, 使用postman调试时出现了超时的情况, 经排查确定是请求数据被处理后Content-Length与实际不一致导致的问题, 故有此文.Content-Length, HTTP消息长度, 用十进制数字表示的八位字节的数目. 一般情况下, 很多工作都被框架完成, 我们很少去关注这部分内容, 但少数情况下发生了Content-Length与实际消息长度不一致, 程序可能会发生比较奇怪的异常, 如: 无响应直到超时.请求被截断, 而且下一个请求解析出现错乱.Content-Length是HTTP消息长度, 用十进制数字表示的八位字节的数目, 是Headers中常见的一个字段. Content-Length应该是精确的, 否则就会导致异常 (特别地, HTTP1.0中这个字段可有可无). Content-Length首部指示出报文中实体主体的字节大小. 这个大小是包含了所有内容编码的, 比如, 对文本文件进行了gzip压缩的话, Content-Length首部指的就是压缩后的大小而不是原始大小. Content-Length是如何工作的Content-Length使用十进制的数字表示了消息的长度, 服务端/客户端通过它来得知后续要读取消息的长度. 如果这个长度不正确, 会发生如下情况: Content-Length > 实际长度如果Content-Length比实际的长度大, 服务端/客户端读取到消息结尾后, 会等待下一个字节, 自然会无响应直到超时. 同样地, 在响应消息中Content-Length超过实际长度也是一样的效果: Content-Length < 实际长度如果这个长度小于实际长度, 首次请求的消息会被截取, 比如参数为param=piaoruiqing, Content-Length为10, 那么这次请求的消息会被截取为: param=piao, 如图所示: 但, 仅仅是如此吗, 当然不, 我们再来看看第二次请求会发生什么让人意外的事情, 如图: 连续的两次请求, 第一次消息被截断, 而第二次没有发生预期的截断, 而是服务端抛出了异常: Request method 'ruiqingPOST' not supported.刺不刺激 (ﾉ)ﾟﾟ( ) ...

GET POST 区别一般来说，GET用于从服务器读取资源，POST 用于向服务器上传数据，比如上传表单GET 一般使用 URL 向服务器传递消息，URL 长度一般会受到 浏览器、中间结点、服务器等的限制，POST 则可以通过 body 来传递数据中间这些结点一般都会记录 URL 日志，但 body 一般很少记录通过 GET 获取的资源可以做缓存，因为多次请求的结果是一样的，post 则不幂等，不能随意多次执行，不能缓存，刷新浏览器时会被告知是否要重复提交订单但是，只要 Client 和 Server 达成共识，server 也可以接受 client 的 GET 请求携带 bodyAJAX 或者 restful 接口在实现的时候，都可以定义使用 post 来做 get 的事情，get 也可以携带 json body（但在 restful 中一般不会在 get 中携带 body），只要 CS 双方约定好即可安全性，刚才提到 post 比 get 稍微安全一点，但是其实可以忽略，只要使用明文的 http，都不安全参考资料GET 和 POST 到底有什么区别？

最近在项目中需要做一个文件上传的功能，使用的组件是elementui的upload组件，在测试的过程中发现后端返回的状态是308永久重定向，上传的过程中不仅发起了上传文件本身的请求，还有一个看起来不相干的请求，通过查询资料终于弄清了为什么上传失败以及308状态码的含义如图，是当时请求的截图： 图1 上传请求 图2 重定向请求 通过网上查找资料，找到了这篇文章，文章已经对308状态码的含义讲解得很清楚了，就是请求的地址已经被永久重定向到另一个URI，且在请求返回的response headers中会有一个叫做"Location"的header来指明被重定向的位置。 我这里上传失败的原因是接口地址本来应该是“/security/file/”，而我写成了“/security/file”，地址后面少了一个“/”，因此如图1所示，response headers中的“Location”指明了被重定向的位置，也就有了图2中的这个请求。 这里前2个file的请求是一样的，至于为什么会出现2次，还没弄清原因，是因为chrome浏览器比较高级，会自动多尝试一次请求吗？实际上在IE中，只会出现一次上传的请求，后2次都不会出现，如图3。而在firefox中，file的请求一次，重定向资源的请求一次，如图4所示。图3 IE中的所有请求图4 firefox中的所有请求 这里还有一个没弄清的问题是图2中的请求实际上是后端在Apache中的一个配置，为什么会重定向到这里也还需要进一步确定。

学习和总结文章同步发布于 https://github.com/xianshanna...，有兴趣可以关注一下，一起学习和进步。Http 优化方式是前端性能优化的重要部分，也是前端必备的知识点之一。 减少静态资源文件大小这个是最根本的途径，假设真的有个 10 几兆以上的静态资源文件，不减少大小的情况下，即使优化做到了极致，用户体验也好不了哪里去。 如果整个网页就 2K 大小的资源文件，不优化都很快。 代码层优化只打包用到的依赖包，目前 webpack tree shaking 功能已经自动处理了，还有尽量少使用第三方依赖包（当然看情况啦）。代码分割（code splitting），不同页面加载自己用到的代码，不加载其他页面的代码（其实也属于懒加载）。传输层优化Http 传承启用压缩传输方式。 一般我们开启 gzip，基本都能压缩 6 倍左右（一般都是文件越大，字符串相似率越大，压缩率越大）。 首先经过服务器压缩后，然后 Http 响应头 Content-Encoding 设置为相应的压缩方式，浏览器会自动解压的。 Content-Encoding: gzip当然还有其他的压缩方式，如 compress、deflate 等等，目前使用最广的还是 gzip。 适当合并或者分散请求合并请求或者分散请求需要看实际情况的。 合并请求http 1.1 （包括 http1.1）之前的版本，浏览器存在同域名并发限制，谷歌目前是同域名并发现在为6 个请求，其他的浏览器或多或少，但也差不了多少。 如果是使用的是 http1.1 web 服务，那么我们首次加载的资源要基本保证在 4 个以内，所以静态资源请求数过多就要看情况进行合并请求了。 分散请求Http2.0 没有同域名并发的问题，我们可以适当分散请求。当然如果在 Http1.1 一个资源文件过大，然后并发并没有达到限制，也可以拆分资源文件达到分散请求的目的。 使用预加载预加载某些情况下可以大大提升加载速度进而提示用户体验。 预加载需要了解 preload 和 prefetch 的知识。 预加载 DNSdns 解析也是需要时间的，特别在移动端的时候更明显，我们可以预解析 dns 减少不通域名 dns 解析时间。 <link rel="dns-prefetch" href="//example.com">其实还有个 preconnect，preconnect 不仅完成 DNS 预解析，同时还将进行 TCP 握手和建立传输层协议，但是浏览器有兼容性，目前用不上。 ...

自从go语言r59版本(一个1.0之前的版本)以来,我一直在写Go程序,并且在过去七年里一直在Go中构建HTTP API和服务. 多年来,我编写服务的方式发生了变化,所以我想分享今天如何编写服务 - 以防模式对您和您的工作有用. 1. Server Struct我的所有组件都有一个server结构,通常看起来像这样： type server struct { db * someDatabase router * someRouter email EmailSender }共享依赖项是结构的字段 2. routes.go我在每个组件中都有一个文件routes.go,其中所有路由都可以存在： package app func(s * server)routes(){ s.router.HandleFunc("/ api/",s.handleAPI()) s.router.HandleFunc("/ about",s.handleAbout()) s.router .HandleFunc("/",s.handleIndex())}这很方便,因为大多数代码维护都是从URL和错误报告开始的,所以只需一眼就routes.go可以指示我们在哪里查看. 3. server 挂载 handler我的HTTPserver 挂载 handler： func(s * server)handleSomething()http.HandlerFunc {...}handler可以通过s服务器变量访问依赖项. 4. return Handler我的处理函数实际上并不处理Request,它们返回一个handler函数. 这给了我们一个闭包环境,我们的处理程序可以在其中运行 func(s * server)handleSomething()http.HandlerFunc { thing：= prepareThing() return func(w http.ResponseWriter,r * http.Request){ // use thing } }该prepareThing只调用一次,所以你可以用它做一次每处理程序初始化,然后用thing在处理程序. 确保只读取共享数据,如果处理程序正在修改任何内容,请记住您需要一个互斥锁或其他东西来保护它. ...

1、token是什么？token是一种用户标识，表示用户身份，类似于我们的身份证件。Token 是在服务端产生的。如果前端使用用户名/密码向服务端请求认证，服务端认证成功，那么在服务端会返回 Token 给前端。前端可以在每次请求的时候带上 Token 证明自己的合法地位。如果这个 Token 在服务端持久化（比如存入数据库），那它就是一个永久的身份令牌。 2、为什么要使用token？先来了解一下token认证与session认证的区别：a) Session认证Session认证的方案为：第一次用户认证请求通过时，服务器端存储用户的登录信息，然后在响应时传递给浏览器，浏览器保存为cookie，下次请求时把cookie发送给服务器，服务器根据cookie信息来识别是哪个用户。Session认证适用于单个服务器的场合，如果用户增多，需要部署多个服务器时，Session认证就会暴露问题。因为每个用户在认证后，服务器都会记录Session，一般保存在内存中，随着认证用户增多，服务器开销也会增大；而且认证用户的后续请求都需要到这台保存了自己Session的服务器上验证Cookie。在多集群分布式的场合，这就造成了性能瓶颈，对负载均衡、应用的扩展都会造成影响。（不能多服务共享）进程外Session通过将Session保存在数据库或硬盘中可以解决服务器内存开销的问题，但仍然不便于扩展。 b) Token认证Token认证也是无状态的，不需要在服务端保存认证用户的信息，它的认证流程为：用户使用用户名密码请求服务器；服务器验证用户，如果验证通过就发给用户一个token；客户端保存token，并在之后的每次请求都附上token；服务端验证token、返回数据。Token认证机制不需要保存认证用户的信息、也不需要考录用户在那台服务器登录，可以很好地适应应用的扩展（可以多服务共享）。token的体积很小，请求服务端时，可以被附在URL、Header或是Post参数中。而且token中包含了用户相关的必要、非私密的相信，免去了服务端再次查询数据库的开销另外，token认证能解决以下问题： Token 完全由应用管理，所以它可以避开同源策略Token 可以避免 CSRF 攻击Token 可以是无状态的，可以在多个服务间共享现在详细说明以下roken为什么能够避免CSRF攻击呢？CSRF攻击又是什么意思？ 2.1、CSRF攻击CSRF（Cross-site request forgery）也被称为 one-click attack或者 session riding，中文全称是叫跨站请求伪造。一般来说，攻击者通过伪造用户的浏览器的请求，向访问一个用户自己曾经认证访问过的网站发送出去，使目标网站接收并误以为是用户的真实操作而去执行命令。常用于盗取账号、转账、发送虚假消息等。攻击者利用网站对请求的验证漏洞而实现这样的攻击行为，网站能够确认请求来源于用户的浏览器，却不能验证请求是否源于用户的真实意愿下的操作行为。 2.2、token如何避免CSRF攻击CSRF 攻击之所以能够成功，是因为黑客可以完全伪造用户的请求，该请求中所有的用户验证信息都是存在于 cookie 中，因此黑客可以在不知道这些验证信息的情况下直接利用用户自己的 cookie 来通过安全验证。要抵御 CSRF，关键在于在请求中放入黑客所不能伪造的信息，并且该信息不存在于 cookie 之中。可以在 HTTP 请求中以参数的形式加入一个随机产生的 token，并在服务器端建立一个拦截器来验证这个 token，如果请求中没有 token 或者 token 内容不正确，则认为可能是 CSRF 攻击而拒绝该请求。 3、使用JWT生成和验证token以下代码仅仅用于示意，并不是完整版。 3.1、采用HS256算法生成和验证后台生成token： const jwt = require('jsonwebtoken')const fs = require('fs')// Token 数据const payload = { name: 'wanghao', admin: true}/** * HS256 * 用 HS256 算法生成与验证 JWT */// 密钥const secret = 'ILOVENINGHAO'// 签发 Tokenconst token = jwt.sign(payload, secret, { expiresIn: '1day' })// 输出签发的 Tokenconsole.log('HS256 算法：', token)拦截器验证： ...

Tornado源码分析 --- Etag实现Etag(URL的Entity Tag):对于具体Etag是什么，请求流程，实现原理，这里不进行介绍，可以参考下面链接：http://www.oschina.net/questi...https://zh.wikipedia.org/wiki... Tornado实现分析：先从Tornado处理一个请求的调用顺序开始看(摘自文档：http://www.tornadoweb.cn/documentation)：程序为每一个请求创建一个 RequestHandler 对象程序调用 initialize() 函数，这个函数的参数是 Application 配置中的关键字 参数定义。（initialize 方法是 Tornado 1.1 中新添加的，旧版本中你需要 重写 __init__ 以达到同样的目的） initialize 方法一般只是把传入的参数存 到成员变量中，而不会产生一些输出或者调用像 send_error 之类的方法。程序调用 prepare()。无论使用了哪种 HTTP 方法，prepare 都会被调用到，因此 这个方法通常会被定义在一个基类中，然后在子类中重用。prepare可以产生输出 信息。如果它调用了finish（或send_error` 等函数），那么整个处理流程 就此结束。程序调用某个 HTTP 方法：例如 get()、post()、put() 等。如果 URL 的正则表达式模式中有分组匹配，那么相关匹配会作为参数传入方法。在一个请求结束的时候肯定会进行Etag的处理，所以找到调用的 finish() 函数：finish() 函数 ---- 地址：tornado/web.py（删除了部分不在此主题的代码） def finish(self, chunk=None): # Automatically support ETags and add the Content-Length header if # we have not flushed any content yet. if not self._headers_written: if (self._status_code == 200 and self.request.method in ("GET", "HEAD") and "Etag" not in self._headers): self.set_etag_header() if self.check_etag_header(): self._write_buffer = [] self.set_status(304) if self._status_code in (204, 304): assert not self._write_buffer, "Cannot send body with %s" % self._status_code self._clear_headers_for_304() elif "Content-Length" not in self._headers: content_length = sum(len(part) for part in self._write_buffer) self.set_header("Content-Length", content_length)分析：　在调用 finish() 函数的时候，对HTTP请求进行判断，如果 状态码为200，请求的方法为 GET 或 HEAD，并且 Etag 不在HTTP头信息里面，则说明该请求是第一次发生。接下来，调用 set_etag_header() 函数，将 etag 写入到 header头信息中 ...

一、经典http面试题大纲1.什么是HTTP协议？★☆2.Web客户端是什么？☆3.Web服务端是什么？☆4.什么是资源？★5.MIME类型是什么？★☆6.什么是URI？★7.什么是URL？★8.什么是URN？★9.常见的HTTP方法有哪些？★☆10.常见的状态码200，206，302，304，404，501的含义？★★☆11.什么是报文？★★☆12.HTTP协议栈是怎么样的？★★★13.什么是DNS？★14.什么是端口号？★15.在浏览器地址栏输入一个HTTP的URL地址，按下回车键之后，浏览器怎么通过HTTP显示位于远端服务器中的某个简单HTML资源？★★★☆16.什么是代理？★☆17.什么是缓存？★☆18.什么是网关？★☆19.什么是隧道？★☆20.什么是Agent代理？★☆ 二、http面试题详解1.什么是HTTP协议？★☆HTTP:超文本传输协议。使用的是可靠的数据传输协议，在传输的过程中不会被损坏或产生混乱。HTTP可以从遍布全世界的Web服务器商将各种信息块迅速、便捷、可靠地搬移到人们桌面上的Web浏览器上去。 2.Web客户端是什么？☆Web客户端常见的又各大厂商的浏览器，比如微软的IE浏览器，google的chrome浏览器。 3.Web服务端是什么？☆Web服务器存储Web类容。Web服务器使用HTTP协议，被称为HTTP服务器。客户端向服务器发送HTTP请求，服务器会在HTTP响应中回送所请求的数据。 4.什么是资源？★Web资源寄宿在Web服务器上。所有能够提供Web内容的东西都是Web资源。比如静态文件，能够动态生成内容的软件程序。 5.MIME类型是什么？★☆MIME：多用途因特网邮件扩展。最初设计MIME是为了解决在不同的电子邮件系统之间搬移报文时存在的问题。HTTP采纳了它，用来描述并标记多媒体内容。MIME类型时一种文本标记，标识一种主要的对象类型和一个特定的子类型，中间由一条斜杠来分隔。如text/html,text/plain,image/ipeg。常见的MIME类型有数百个。 6.什么是URI？★URI：统一资源标识符，在世界范围内唯一标识并定位信息资源。URI有两种形式：URL和URN。 7.什么是URL？★URL：统一资源定位符。URL描述了一台特定服务器上某资源的特定位置。URL的第一部分被称为方案（scheme）。说明了访问资源所使用的协议类型。这里使用的时HTTP协议（http://）。第二部分表示服务器的因特网地址：www.cnblogs.com。其余部分指定了Web服务器上的某个资源：/jackson0714/p/algorithm_1.html。几乎所有的URLI都是URL。 8.什么是URN？★URN:统一资源名，URN是作为特定内容的唯一名称使用的，与目前的资源所在地无关。 9.常见的HTTP方法有哪些？★☆GET ：从服务器向客户端发送命名资源POST： 将客户端数据发送到一个服务器网关应用程序PUT： 将来自客户端的数据存储到一个命名的服务器资源中去DELETE： 从服务器中删除命名资源HEAD： 仅发送命名资源响应中的HTTP首部  10.常见的状态码200，206，302，304，404，503的含义？★★☆   11.什么是报文？★★☆HTTP报文是由一行一行的简单的字符串组成的。HTTP报文都是纯文本，不是二进制代码。 请求报文：从Web客户端发往Web服务器的HTTP报文称为请求报文。响应报文：从Web服务器发往客户端的报文称为响应报文。 HTTP报文包含以下三个部分：起始行：报文的第一行就是起始行，在请求报文中用来说明要做些什么，在响应报文中说明出现了什么情况。如：GET /jackson0714/p/algorithm_1.html HTTP/1.1首部字段：起始行后面由零个或多个首部字段。以键值对的形式表示首部字段。键和值之间用冒号分隔。首部以一个空行结束。如Content-Type：text/html:charset=utf-8主体：首部字段空行之后就是可选的报文主体了，其中包含了所有类型的数据。请求主体中包括了要发送Web服务器的数据，响应主体中装载了要返回给客户端的数据。 12.HTTP协议栈是怎么样的？★★★HTTP是应用层协议。它把联网的细节都交给了通用、可靠的因特网传输协议TCPIP协议。HTTP网络协议栈: TCP协议：　a.传输控制协议　b.无差错的数据传输　c.按序传输（数据总是会按照发送的顺序到达）　d.未分段的数据流（可以在任意时刻以任意尺寸将数据发送出去） 13.什么是DNS？★域名解析服务。将主机名转换为IP地址。如将http://www.cnblogs.com/ 主机名转换为IP地址：211.137.51.78。 14.什么是端口号？★http://www.cnblogs.com:8080就是端口号。HTTP的URL中没有端口号时，可以假设默认端口号时80。有了IP地址和端口号，客户端就可以很方便地通过TCP/IP进行通信了。 15.在浏览器地址栏输入一个HTTP的URL地址，按下回车键之后，浏览器怎么通过HTTP显示位于远端服务器中的某个简单HTML资源？★★★☆（1）浏览器从URL中解析出服务器的主机名；（2）浏览器将服务器的主机名转换成服务器的IP地址；（3）浏览器将端口号（如果有的话），从URL中解析出来；（4）浏览器建立一条与Web服务器的TCP连接；（5）浏览器向服务器发送一条HTTP请求报文；（6）服务器向浏览器回送一条HTTP响应报文；（7）关闭连接，浏览器显示文档。 16.什么是代理？★☆代理是位于客户端和服务器之间的HTTP中间实体。接收所有客户端的HTTP请求，并将这些请求转发给服务器（可能会对请求进行修改之后转发）。 17.什么是缓存？★☆缓存HTTP的仓库，使常用页面的副本可以保存在离客户端更近的地方。 18.什么是网关？★☆网关是一种特殊的服务器，作为其他服务器的中间实体使用。通常用于将HTTP流量转换成其他的协议。 19.什么是隧道？★☆隧道是建立起来之后，就会在两条连接之间对原始数据进行盲转发的HTTP应用程序。常见用途是通过HTTP连接承载加密的安全套接字层（SSL）流量，这样SSL流量就可以穿过只允许Web流量通过的防火墙了。 20.什么是Agent代理？★☆用户Agent代理是代表用户发起HTTP的客户端程序。比如Web浏览器。另外有些自动发送HTTP请求并获取内容的代理,比如“网络蜘蛛”或者“Web机器人”。 如果你觉得这篇文章对你有所帮助，那就顺便点个赞吧，点赞收藏不迷路~ 黑芝麻哇，白芝麻发，黑芝麻白芝麻哇发哈！ 前端哇发哈

作者：Alex Ronin翻译：疯狂的技术宅 原文：https://frontnet.eu/http-2-fa... 未经允许严禁转载 也许人们已经听说过 HTTP2，有很多数大公司都使用HTTP2，如Google、Youtube、Facebook ...... 那么什么是HTTP2？我们现在就知道了。 HTTP 的历史 HTTP 又称超文本传输协议，就是你的浏览器与你正在访问的网站的 Web 服务器通信的方式。 两台（或多台）计算机通过 Internet 相互通信的方式有很多种，HTTP 只是用于 Web 浏览的一种方式。 第一个官方 HTTP 版本（HTTP 1.0）于1996年作为RFC1945发布。 随着 Web 的快速发展，有了更多的 css，js 组件，这意味着我们需要更多资源，在某些情况下还需要同时下载多个资源。在使用时会发生什么 1 connection / 1 resourcesHTTP 1.0 的机制无法实现带宽优化。 在 1999 年发布的版本 HTTP/1.1 解决了流水线概念这个问题。然后 HTTP/1.1 版本继续更新并使用到现在为止。 虽然有所改进，但是流水线并没有完全解决 HTTP/1.0 的问题。虽然人们觉得“还不错！”，Google 的人们觉得“不行！”，所以他们发布了一个名为 SPDY 的新协议来改善页面加载时间。 。 SPDY 通过压缩，多路复用和优先级排序技术实现了减少页面加载时间的目标。 2012年7月，SPDY 开发团队公开宣布它正朝着标准化方向发展。 Chromium、Mozilla Firefox、Opera、Amazon Silk、Internet Explorer 和 Safari 浏览器也实现了 SPDY。 部署 SPDY 后，与 HTTP/1.x 相比，它显示出显著的改进，并引起了 Firefox 和 nginx 等开发人员的兴趣。不久之后开发人员开始讨论 HTTP/2。在调用过程和提案选择完成之后，SPDY/2 作为 HTTP/2 的基础。从那时起，根据工作组的讨论和实施者的反馈，发生了一些变化。截至2015年5月，HTTP/2 规范发布（RFC 7540）。 ...

在做接口测试的过程中特别是在面试的过程中，都会遇到一些HTTP协议的基础知识问题。一般来说一开始做接口测试并不需要对HTTP协议了解很清楚，但是随着测试的深入，自然而然地会遇到各类各样的问题，如果前期知识储备不足，就需要抓紧时间恶补了。 我属于遇到问题，发现不足，然后恶补的，对于HTTP协议的基础，我十分推荐一本书《图解HTTP》这本书，通俗易懂，才用漫画+文字的形式，更加形象。 下面内容摘自豆瓣： 本书对互联网基盘——HTTP协议进行了全面系统的介绍。作者由HTTP协议的发展历史娓娓道来，严谨细致地剖析了HTTP协议的结构，列举诸多常见通信场景及实战案例，最后延伸到Web安全、最新技术动向等方面。本书的特色为在讲解的同时，辅以大量生动形象的通信图例，更好地帮助读者深刻理解HTTP通信过程中客户端与服务器之间的交互情况。读者可通过本书快速了解并掌握HTTP协议的基础，前端工程师分析抓包数据，后端工程师实现REST API、实现自己的HTTP服务器等过程中所需的HTTP相关知识点本书均有介绍。在看完这本书之后，本着传播知识共同进步的精神，自己写了一个脑图，分享出来供大家参考。 欢迎有兴趣的童鞋一起交流

Fegin简介Fegin是声明式、模块化的Http客户端，可以帮助我们快捷优雅的调用HTTP接口。在SpringCloud中可以很方便的创建一个Feign客户端，只需声明一个接口，并加上对应的注解就能完成对HTTP接口的调用。 本文不集成注册中心也就不使用Fegin的负载均衡，所以可以理解为一个更简便，高可复用的Http客户端。以示例讲解SpringBoot版本：2.1.1.RELEASESpringCloud版本：Finchley.SR2必要POM引入<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.1.1.RELEASE</version> </parent> <dependencyManagement> <dependencies> <!--spring-cloud --> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-dependencies</artifactId> <version>${spring-cloud.version}</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement> <dependencies> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> </dependencies>Fegin客户端定义1、@FeignClient 定义接口为Http客户端,调用指定方法,并将接口注入Spring上下文中参数url：所请求http服务的url、参数config：指定fegin的配置类2、@PostMapping 为@RequestMapping的组合注解,默认为Post请求调用，注解不多介绍，主要表示所需要调用的http接口的具体路径,可在url中拼接参数，也可以指定入参的ContentType3、http接口的返回值格式如果和返回对象属性一致,会反序列化为对应对象。package com.external.feign;import java.util.List;import java.util.Map;import org.springframework.cloud.openfeign.FeignClient;import org.springframework.web.bind.annotation.PostMapping;import com.external.config.FormFeignConfig;import com.external.dto.response.BaseBispDto;import com.external.dto.response.NiftyRes;import com.external.dto.response.ReportAnalyzesRes;import com.external.dto.response.ReportSummaryRes;import com.external.feign.rpc.BISPResponse;@FeignClient(name="fegin-name", url="${http-url}" , configuration = FormFeignConfig.class)public interface BispClient { /** * @Description * @author zengzp */ @PostMapping(value="/intf?method=XXXX", consumes = {"application/x-www-form-urlencoded"}) public XXXXResponse<BaseBispDto> saveSampleInfo(Map<String, ?> params); /** * @Description * @author zengzp */ @PostMapping(value="/intf?method=XXXX", consumes = {"application/x-www-form-urlencoded"}) public XXXXResponse<NiftyRes> getNiftyDetectionResultReplenish(Map<String, ?> params); Fegin配置代码配置日志输出策略与指定对应ContentType的消息的编码与解码package com.external.config;import org.springframework.beans.factory.ObjectFactory;import org.springframework.beans.factory.annotation.Autowired;import org.springframework.boot.autoconfigure.http.HttpMessageConverters;import org.springframework.cloud.openfeign.support.SpringDecoder;import org.springframework.cloud.openfeign.support.SpringEncoder;import org.springframework.context.annotation.Bean;import org.springframework.context.annotation.Configuration;import org.springframework.context.annotation.Scope;import feign.Logger;import feign.codec.Decoder;import feign.codec.Encoder;import feign.form.FormEncoder;@Configurationpublic class FormFeignConfig { @Autowired private ObjectFactory<HttpMessageConverters> messageConverters; @Bean Logger.Level feignLoggerLevel() { return Logger.Level.BASIC; } @Bean @Scope("prototype") Decoder decoder() { return new AllinpayDecoder(new SpringDecoder(messageConverters)); } @Bean @Scope("prototype") Encoder encoder(){ return new FormEncoder(new SpringEncoder(this.messageConverters)); }}统一响应DTOpackage com.external.feign.rpc;import org.springframework.http.HttpStatus;import com.external.common.dto.BaseDto;public class XXXXResponse<T> extends BaseDto { /** * */ private static final long serialVersionUID = 1L; private String code; private String msg; private Long total; private T rows;}启动服务时务必在配置类上增加@EnableFeignClients

web缓存可以自动保存常见文档副本，当web请求抵达缓存时，如果本地有已缓存的副本，就可以从本地存储设备而不是原始服务器中提取这个文档。使用缓存可以减少冗余的数据传输、缓解网络瓶颈问题、降低对原始服务器的要求和降低距离时延。 可以用已有的副本为某些到达缓存的请求提供服务，被称为缓存命中（cache hit），若请求没有副本可用，被转发给原始服务器，被称为缓存未命中（cache miss）。原始服务器的内容可能会发生变化，缓存要不时对其进行检测，被称为http再验证（revalidation）。 对缓存的副本进行再验证时，会向原始服务器发送一个小的再验证请求，如果内容没有变化，服务器会以一个小的304 Not Modified进行响应，副本依然有效，被再次标识为暂时新鲜的，并将副本提供给客户端，这被称为再验证命中或缓慢命中，这种方式比单纯的缓存命中要慢。 缓存处理步骤对一条http GET报文的基本缓存处理包括7个步骤：1、接收缓存从网络中读取抵达的请求报文2、解析缓存对报文进行解析，提取出URL和各种首部3、查询查看是否有本地副本可用，如果没有，就获取一份副本，并将其保存在本地。4、新鲜度检测http通过缓存将服务器文档的副本保留一段时间，在这段时间里，都认为文档是新鲜的，缓存可以在不联系服务器的情况下直接提供该文档。但一旦已缓存副本停留时间太长，超过了文档的新鲜度限值，就认为对象过时了，在提供该文档之前，缓存要再次与服务器进行确认，以查看文档是否发生了变化。客户端发送给缓存的所有请求首部自身都可以强制缓存进行再验证，或者避免验证。5、创建响应缓存会用新的首部和已缓存的主体来构建一条响应报文。缓存会向其中插入新鲜度信息（Cache-Control、Age、Expires），并且通常会包含一个Via首部来说明请求是由一个代理缓存提供的。6、发送通过网络将响应发回给客户端7、日志可选地创建一个日志文件条目来描述这个事务 http有一些简单的机制可以在不要求服务器记住有哪些缓存拥有其文档副本的情况下保持已缓存数据与服务器数据之间充分一致。http将这些简单的机制称为文档过期和服务器再验证。 文档过期通过http Cache-Control（http/1.1）和Expires(http/1.0+)首部，http让原始服务器向每个文档附加了一个过期日期，这些首部说明了在多长时间内可以将这些内容视为新鲜的。在缓存文档过期前，可以以任意频率使用这些副本，而无需与服务器联系，除非客户端请求中包含有阻止提供已缓存或未验证资源的首部。一旦已缓存文档过期，缓存就必须与服务器进行核对，询问文档是否被修改过，如果被修改过，就要获取一份新鲜的副本。由于绝对日期依赖于计算机时钟的正确设置，一般更倾向于使用Cache-Control相对日期。 Cache-Control：no-Store标识为no-store的响应会禁止保存文档副本Cache-Control：no-Cache标识为no-cache的响应实际上时是可以存储本地缓存的，只是在与原始服务器进行新鲜度再验证之前，缓存不能提供给客户端使用Cache-Control：must-revalidate可以配置缓存，使其提供一些陈旧（过期）的对象，如果原始服务器希望严格遵守过期信息，可以增加must-revalidate首部 试探性过期如果响应中没有Cache-Control:max-age首部，也没有Expires首部，缓存可以计算出一个试探性最大试用期。LM-Factor算法是一种常见试探性过期算法，如果文档中包含了最后修改日期，就可以使用这种算法。LM-Factor算法将最后修改日期作为依据，来估计文档有多易变。算法逻辑如下：1、如果已缓存文档最后一次修改发生在很久以前，它可能是一份稳定的文档，不太会突然发生变化，因此将其继续保存正在缓存中比较安全2、如果已缓存文档最近被修改过，说明它很可能会频繁地发生变化，因此在与服务器进行再验证之前，只应该将其缓存很短一段时间 实际的LM-Factor算法会计算缓存与服务器对话的时间跟服务器声明文档最后被修改的时间之间的差值，取这个间隔时间的一部分，将其作为缓存中的新鲜度持续时间。如果最后修改日期也没有的话，通常会为没有任何新鲜周期线索的文档分配一个默认的新鲜周期（一个小时或一天）。有时，比较保守的缓存会将这种试探性新鲜生存周期设置为0，强制在每次将其提供给客户端之前都去验证。 服务器再验证缓存文档过期，意味着到了进行核对的时间，需要询问原始服务器文档是否发生了变化。这种情况被称为服务器再验证。如果在验证显示内容发生了变化，缓存会获取一份新的文档副本，取代旧的文档副本，然后将文档发送给客户端；如果再验证显示内容没有变化，缓存只需要获取新的首部，包括一个新的过期日期，并对缓存中的首部进行更新。 用条件方法进行再验证http允许缓存向原始服务器发送一个“条件GET”，使服务器只有在文档与缓存中现有副本不同时，才回送对象主体，常用的两个首部是If-Modified-Since和If-None-Match。如果服务器收到的请求既带有If-Modified-Since又有If-None-Match，那么只有这两个条件都满足时，才返回304. If-Modified-SinceIf-Modified-Since再验证请求通常被称为IMS请求，可以与Last-Modified首部配合工作，参是数一个日期。如果自指定日期后，文档被修改了，Get请求就会成功执行，返回新的文档，新文档会包括一个新的过期日期。如果文档没有被修改，条件为假，客户端会收到一个304 Not Modified响应报文，一般会发送一个新的过期日期。 If-None-Match有些情况仅使用最后修改日期再验证是不够的。 有些文档可能会被周期性地重写，但实际包含的数据是一样的，尽管内容没有变化，但修改日期会发生变化有些文档可能被修改了，但所做修改并不重要，不需要让世界范围的缓存都重装数据（例如对拼写或注释的修改）有些服务器无法准确地判定文档的最后修改日期有些服务器提供的文档会在亚秒间隙发生变化，对这些服务器来说，以秒为粒度的修改日期就不够用了为了解决这些问题，http允许用户对被称为实体标签（ETag）的“版本标识符”进行比较。实体标签是附加到文档上的任意标签，它们可能包含了文档的序列号或版本名，或者是文档内容的校验和其他指纹信息。当发布者对文档进行修改时，可以修改文档的实体标签来说明这个新的版本，缓存就可以用If-None-Match条件首部来请求文档的新副本了。 浏览器控制浏览器中通常有refresh（刷新）和reload（重载）机制，可以强制对浏览器或代理缓存中可能过期的内容进行刷新。refresh操作会发布一个附加了Cache-Control请求首部的GET请求，这个请求会强制进行再验证，或者无条件地从服务器获取文档。refresh的确切行为取决于特定的浏览器、文档以及拦截缓存的配置。 Chrome中正常重新加载会强制对缓存的文档副本进行再验证，硬性重新加载则直接跳过缓存从原始服务器请求文档

前言最近稍微闲了一点于是把这个半年都没更新的开源项目 cicada 重新捡了起来。 一些新关注的朋友应该还不知道这项目是干啥的？先来看看官方介绍吧（其实就我自己写的????） cicada: 基于 Netty4 实现的快速、轻量级 WEB 框架；没有过多的依赖，核心 jar 包仅 30KB。 针对这个轮子以前也写过相关的介绍，感兴趣的可以再翻回去看看： 「造个轮子」——cicada(轻量级 WEB 框架)「造个轮子」——cicada 源码分析「造个轮子」——cicada 设计一个配置模块「造个轮子」——cicada 设计全局上下文利用责任链模式设计一个拦截器设计一个可拔插的 IOC 容器这些都看完了相信对这个小玩意应该会有更多的想法。 效果广告打完了，回到正题；大家平时最常用的 MVC 框架当属 SpringMVC 了，而在搭建脚手架的时候相信全局异常处理是必不可少的。 Spring 用法通常我们的做法如下： 传统 Spring 版本： 实现一个 Spring 自带的接口，重写其中的方法，最后的异常处理便在此处。将这个类配置在 Spring 的 xml ，当做一个 bean 注册到 Spring 容器中。public class CustomExceptionResolver implements HandlerExceptionResolver { @Override public ModelAndView resolveException(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) { //自定义处理}<bean class="ssm.exception.CustomExceptionResolver"></bean> 当然现在流行的 SpringBoot 也有对应的简化版本： @ControllerAdvicepublic class GlobalExceptionHandler { @ExceptionHandler(value = Exception.class) public Object defaultErrorHandler(HttpServletRequest req, Exception e) throws Exception { //自定义处理 }}全部都换为注解形式，但本质上还是一样的。 ...

在DDOS防护过程中，流量清洗是必不可少的技术操作。那么精准的流量清洗具体是通过什么样的方式实现的呢?其中会有多种的技术方式辨识。昨天给大家分享了流量清洗过程中必要的技术手段中的三个，攻击特征匹配、IP信誉检查、协议完整性检测。今天的内容主要分享速度检查与限制、TCP代理和验证、客户端真实性验证的技术手段。 1、通过对请求数据包发送的速度检查与限制来进行清洗。一部分攻击在数据包上是没有特别明显的攻击特性，同时也没有办法进行特征匹配。但在请求数据包发送的频率和速度上会有着明显的差异。比如在受到SSL DDoS攻击时，会在同一个SSL会话中进行加密密钥的多重协商。正常情况下是不会反复多重协商加密密钥的。所以在流量清洗的时候，如果发现SSL会话中的密钥协商次数超过了特定的阈值，会直接中断这个会话并且把来源加入黑名单中。或者是慢速的POST请求攻击时，客户端和服务器之间会以低速率进行互相数据传输。在清洗过程中发现HTTP请求长时间没有完成传输，就会中断会话，这种一般是通过速度检查和限制来进行清洗的。相比UDP洪水攻击等是没有明显的特征，此种是通过大流量攻击，流量清洗的缓解技术是限制流量速度。 2、针对TCP协议代理和验证：如SYN Flood洪水攻击的方式是利用了TCP协议的弱点，将被攻击的服务器连接表占满，使其无法创建新的连接而达到拒绝服务的目的。那么在SYN请求达到一定数量清洗后，就会回复一个SYN+ACK数据，等待客户端回复。确定SYN请求是正常的用户，客户端就会对SYN+ACK进行响应，同时流量清洗技术会代替用户并且保护服务器建立了TCP连接，然后将连接加入信任列表当中。这样用户端和服务端之间可以进行正常的数据通信。如果SYN请求来自攻击者，通常不会对SYN+ACK响应，所以只是单方面的连接，流量清洗技术会暂时保留一段时间这个单方面的连接，经过一定的短的时间就丢弃它。所以相比保护服务器，流量清洗技术会对连接表进行优化，也能处理很大的连接请求。因此清洗设备保护了服务器，也不会使其消耗任何的连接资源，性能不会受影响。 3、流量清洗过程中还会对客户端真实性验证，主要是对客户端的程序以及应答模式的相互验证。以此来检查客户端能否完成特定的功能和确认请求数据是否来自真实的客户端。在页面的WEB服务中，通过检查客户端是否支持JavaScript来验证请求来源是否是真实的浏览器客户端。在收到HTTP请求是，流量清洗技术会试用JavaScript等脚本语言发送简单的运算操作。一般对真实的浏览器请求会进行正确的运算结果返回，这个时候流量清洗将验证后的请求跳转到Web服务器上的正常资源位置，以此不影响正常的用户访问。如果是攻击工具发送的，是不会返回正常的运算结果，因此流量清洗技术会直接丢弃这样请求，不会让其跳转到Web服务器的连接，服务器也不会受到影响。 DDoS攻击的防御技术随着攻击的提升也在增强中。从最初的拒绝服务变为了分布式拒绝服务，而且还在变异中，所以缓解的技术也是越来越深奥。墨者安全我力所能及的分享一些关于DDOS攻防的技术，网络安全方面的知识以及见解，对此大家有各自的观点可以相互交流。

遇见DDoS攻击的时，目前的防护技术中避免不了的会出现流量清洗过滤等词，客户都会很疑惑流量清洗，是怎么清洗的，会不会把正常的访问请求一起过滤清洗掉呢？这是站在客户角度最关心的一个问题，这种想法很正常，因为谁都不想损失客户嘛。那接下来分享下DDoS防御中流量清洗的技术方法吧。 流量清洗的意思是全部的网络流量中区分出正常的流量和恶意的流量，将恶意流量阻断和丢弃，而只将正常的流量回源给源服务器。墨者安全一般建议选择优秀的流量清洗设备。有些漏报率太高的，对大量的正常请求过程中会造成中断，有可能会影响到业务的正常运行，相当于优秀的清洗设备，可以降低漏报率以及误报率，在不影响业务正常运行的情况下可以将恶意攻击流量最大化的从网络流量中去除。但是做到这一步需要用到准确而高效的清洗技术。如： 1、攻击特征的匹配：在发动DDoS攻击过程中是需要借助一些攻击工具的，比如僵尸网络等。同时网络犯罪分子为了提高发送请求的效率，攻击工具发出的数据包通常是编写者伪造并固化到工具当中的。因此每种攻击工具所发出的数据包都有一些特征存在。那么流量清洗技术将会利用这些数据包中的特征作为指纹依据，通过静态指纹技术或者是动态指纹技术识别攻击流量。静态指纹识别的原理是预先将多种攻击工具的指纹特征保存在流量清洗设备中的数据库，因此所有的访问数据都会先进行内部数据库比对，如果是符合的会选择直接丢弃。动态指纹识别清洗设备对流过的网络数据包进行若干个数据包学习，然后将攻击特征记录下来，后续有访问数据命中这些特征的直接丢弃。 2、IP信誉检查：IP信誉机制是互联网上的IP地址赋予一定的信誉值.有一些经常用来当作僵尸主机的，会发送垃圾邮件或被用来做DDOS攻击的IP地址。会被赋予较低的信誉值.说明这些IP地址可能成为网络攻击的来源。所以当发生DDOS攻击的时候会对网络流量中的IP信誉检查，所以在清洗的时候会优先丢弃信誉低的IP，一般IP信誉检查的极端情况是IP黑名单机制。 3.协议完整性验证：为提高发送攻击请求的效率，大多数的都是只发送攻击请求，而不接收服务器响应的数据。因此.如果采取对请求来源进行交替严重，就可以检测到请求来源协议的完整性，然后在对其不完整的请求来源丢弃处理。在DNS解析的过程中，攻击方的工具不接收解析请求的响应数据，所以不会用TCP端口进行连接。所有流量清洗设备会利用这种方式区分合法用户与攻击方，拦截恶意的DNS攻击请求。这种验证方式也适用于HTTP协议的Web服务器。主要是利用HTTP协议中的302重定向来验证请求，确认来源是否接收了响应数据并完整实现了HTTP协议的功能。正常的合法用户在接收到302 重定向后会顺着跳转地址寻找对应的资源。而攻击者的攻击工具不接收响应数据，则不会进行跳转，直接会被清洗拦截，WEB服务器也不会受到任何影响。 针对精准的流量清洗还需要很多种的精确技术，比如速度检查与限制、协议代理和验证、客户端真实性验证等技术方法。因为时间原因，剩下的三种方法后续分享给大家。

前言大学老师曾经说过，计算机界有三本天书，分别是：数据结构、计算机组成原理、计算机网络。所以网络也是我们从事计算机开发必须了解且掌握的一门技术 网络七层模型应用层 访问网络服务的端口，如HTTP传输 ‘hello，world’表示层 提供数据格式转换会话层 建立端连接并提供访问验证 如SSL/TLS认证传输层 UDP/TCP + ‘hello，world’网络层 IP + UDP/TCP + ‘hello，world’数据链路层 MAC地址 + IP + UDP/TCP + ‘hello，world’ + 帧尾物理层 传输二进制 01010101001HTTP请求/相应报文 **请求报文包括:** 请求方法 URL 协议版本HTTP1.0 首部字段名 请求体 （POST请求） **响应报文包括:** 版本 状态码 短语 首部字段名 响应实体请求方法GET： 代表获取资源 特点： 安全：不应该引起Server端的任何状态变化 幂等：请求多次的结果一样 可缓存：代理服务器可以缓存POST： 代表处理资源 特点： 不安全 不幂等 不可缓存HEADOPTIONPUT 状态码200： 请求成功300： 请求重定向400： 由于客户端请求地址和参数引用的失败500： 服务端原因 连接接建立流程TCP: 三次握手、四次挥手HTTP特点无连接： 每次请求都需要建立TCP连接无状态 ...