贵州建设职业技术学院网站,网站首页图片切换,效果图参考网站,网站的简单布局目录 一、POST和PUT请求的区别
二、GET方法URL长度限制的原因
三、页面有多张图片#xff0c;HTTP是怎样的加载表现#xff1f;
四、HTTP2的头部压缩算法是怎样的#xff1f;
五、说一下HTTP 3.0
六、HTTP协议的性能怎么样#xff1f;
七、数字证书是什么#xff1f…目录 一、POST和PUT请求的区别
二、GET方法URL长度限制的原因
三、页面有多张图片HTTP是怎样的加载表现
四、HTTP2的头部压缩算法是怎样的
五、说一下HTTP 3.0
六、HTTP协议的性能怎么样
七、数字证书是什么
八、同样是重定向 307303302的区别
九、DNS同时使用TCP和UDP协议
十、迭代查询与递归查询
十一、DNS 记录和报文
十二、UDP协议为什么不可靠
十三、即时通讯的实现短轮询、长轮询、SSE 和 WebSocket 间的区别
十四、TCP粘包是怎么回事如何处理?
十五、为什么udp不会粘包 一、POST和PUT请求的区别
PUT请求是向服务器端发送数据从而修改数据的内容但是不会增加数据的种类等也就是说无论进行多少次PUT操作其结果并没有不同。可以理解为是更新数据POST请求是向服务器端发送数据该请求会改变数据的种类等资源它会创建新的内容。可以理解为是创建数据二、GET方法URL长度限制的原因
实际上HTTP协议规范并没有对get方法请求的url长度进行限制这个限制是特定的浏览器及服务器对它的限制。
IE对URL长度的限制是2083字节(2K35)。由于IE浏览器对URL长度的允许值是最小的所以开发过程中只要URL不超过2083字节那么在所有浏览器中工作都不会有问题。 GET的长度值 URL2083- 你的DomainPath-22是get请求中?两个字符的长度 下面看一下主流浏览器对get方法中url的长度限制范围
Microsoft Internet Explorer (Browser)IE浏览器对URL的最大限制为2083个字符如果超过这个数字提交按钮没有任何反应。Firefox (Browser)对于Firefox浏览器URL的长度限制为 65,536 个字符。Safari (Browser)URL最大长度限制为 80,000 个字符。Opera (Browser)URL最大长度限制为 190,000 个字符。Google (chrome)URL最大长度限制为 8182 个字符。
主流的服务器对get方法中url的长度限制范围
Apache (Server)能接受最大url长度为8192个字符。Microsoft Internet Information Server(IIS)能接受最大url的长度为16384个字符。
根据上面的数据可以知道get方法中的URL长度最长不超过2083个字符这样所有的浏览器和服务器都可能正常工作。 三、页面有多张图片HTTP是怎样的加载表现
在HTTP 1下浏览器对一个域名下最大TCP连接数为6所以会请求多次。可以用多域名部署解决。这样可以提高同时请求的数目加快页面图片的获取速度。在HTTP 2下可以一瞬间加载出来很多资源因为HTTP2支持多路复用可以在一个TCP连接中发送多个HTTP请求。四、HTTP2的头部压缩算法是怎样的
HTTP2的头部压缩是HPACK算法。在客户端和服务器两端建立字典用索引号表示重复的字符串采用哈夫曼编码来压缩整数和字符串可以达到50%~90%的高压缩率。
具体来说:
在客户端和服务器端使用首部表来跟踪和存储之前发送的键值对对于相同的数据不再通过每次请求和响应发送首部表在HTTP/2的连接存续期内始终存在由客户端和服务器共同渐进地更新每个新的首部键值对要么被追加到当前表的末尾要么替换表中之前的值
例如下图中的两个请求 请求一发送了所有的头部字段第二个请求则只需要发送差异数据这样可以减少冗余数据降低开销。 五、说一下HTTP 3.0
HTTP/3基于UDP协议实现了类似于TCP的多路复用数据流、传输可靠性等功能这套功能被称为QUIC协议。 流量控制、传输可靠性功能QUIC在UDP的基础上增加了一层来保证数据传输可靠性它提供了数据包重传、拥塞控制、以及其他一些TCP中的特性。集成TLS加密功能目前QUIC使用TLS1.3减少了握手所花费的RTT数。多路复用同一物理连接上可以有多个独立的逻辑数据流实现了数据流的单独传输解决了TCP的队头阻塞问题。快速握手由于基于UDP可以实现使用0 ~ 1个RTT来建立连接。 六、HTTP协议的性能怎么样
HTTP 协议是基于 TCP/IP并且使用了请求-应答的通信模式所以性能的关键就在这两点里。
长连接
HTTP协议有两种连接模式一种是持续连接一种非持续连接。
1非持续连接指的是服务器必须为每一个请求的对象建立和维护一个全新的连接。
2持续连接下TCP 连接默认不关闭可以被多个请求复用。采用持续连接的好处是可以避免每次建立 TCP 连接三次握手时所花费的时间。
对于不同版本的采用不同的连接方式
在HTTP/1.0 每发起一个请求都要新建一次 TCP 连接三次握手而且是串行请求做了无畏的 TCP 连接建立和断开增加了通信开销。该版本使用的非持续的连接但是可以在请求时加上 Connection: keep-a live 来要求服务器不要关闭 TCP 连接。在HTTP/1.1 提出了长连接的通信方式也叫持久连接。这种方式的好处在于减少了 TCP 连接的重复建立和断开所造成的额外开销减轻了服务器端的负载。该版本及以后版本默认采用的是持续的连接。目前对于同一个域大多数浏览器支持同时建立 6 个持久连接。管道网络传输
HTTP/1.1 采用了长连接的方式这使得管道pipeline网络传输成为了可能。
管道pipeline网络传输是指可以在同一个 TCP 连接里面客户端可以发起多个请求只要第一个请求发出去了不必等其回来就可以发第二个请求出去可以减少整体的响应时间。但是服务器还是按照顺序回应请求。如果前面的回应特别慢后面就会有许多请求排队等着。这称为队头堵塞。
队头堵塞
HTTP 传输的报文必须是一发一收但是里面的任务被放在一个任务队列中串行执行一旦队首的请求处理太慢就会阻塞后面请求的处理。这就是HTTP队头阻塞问题。
队头阻塞的解决方案
1并发连接对于一个域名允许分配多个长连接那么相当于增加了任务队列不至于一个队伍的任务阻塞其它所有任务。
2域名分片将域名分出很多二级域名它们都指向同样的一台服务器能够并发的长连接数变多解决了队头阻塞的问题。 七、数字证书是什么
现在的方法也不一定是安全的因为没有办法确定得到的公钥就一定是安全的公钥。可能存在一个中间人截取了对方发给我们的公钥然后将他自己的公钥发送给我们当我们使用他的公钥加密后发送的信息就可以被他用自己的私钥解密。然后他伪装成我们以同样的方法向对方发送信息这样我们的信息就被窃取了然而自己还不知道。为了解决这样的问题可以使用数字证书。
首先使用一种 Hash 算法来对公钥和其他信息进行加密生成一个信息摘要然后让有公信力的认证中心简称 CA 用它的私钥对消息摘要加密形成签名。最后将原始的信息和签名合在一起称为数字证书。当接收方收到数字证书的时候先根据原始信息使用同样的 Hash 算法生成一个摘要然后使用公证处的公钥来对数字证书中的摘要进行解密最后将解密的摘要和生成的摘要进行对比就能发现得到的信息是否被更改了。
这个方法最要的是认证中心的可靠性一般浏览器里会内置一些顶层的认证中心的证书相当于我们自动信任了他们只有这样才能保证数据的安全。 八、同样是重定向 307303302的区别
302是http1.0的协议状态码在http1.1版本的时候为了细化302状态码⼜出来了两个303和307。 303明确表示客户端应当采⽤get⽅法获取资源他会把POST请求变为GET请求进⾏重定向。 307会遵照浏览器标准不会从post变为get。 九、DNS同时使用TCP和UDP协议
DNS占用53号端口同时使用TCP和UDP协议。
1在区域传输的时候使用TCP协议
辅域名服务器会定时一般3小时向主域名服务器进行查询以便了解数据是否有变动。如有变动会执行一次区域传送进行数据同步。区域传送使用TCP而不是UDP因为数据同步传送的数据量比一个请求应答的数据量要多得多。TCP是一种可靠连接保证了数据的准确性。
2在域名解析的时候使用UDP协议
客户端向DNS服务器查询域名一般返回的内容都不超过512字节用UDP传输即可。不用经过三次握手这样DNS服务器负载更低响应更快。理论上说客户端也可以指定向DNS服务器查询时用TCP但事实上很多DNS服务器进行配置的时候仅支持UDP查询包。十、迭代查询与递归查询
实际上DNS解析是一个包含迭代查询和递归查询的过程。
递归查询指的是查询请求发出后域名服务器代为向下一级域名服务器发出请求最后向用户返回查询的最终结果。使用递归 查询用户只需要发出一次查询请求。迭代查询指的是查询请求后域名服务器返回单次查询的结果。下一级的查询由用户自己请求。使用迭代查询用户需要发出 多次的查询请求。
一般我们向本地 DNS 服务器发送请求的方式就是递归查询因为我们只需要发出一次请求然后本地 DNS 服务器返回给我 们最终的请求结果。而本地 DNS 服务器向其他域名服务器请求的过程是迭代查询的过程因为每一次域名服务器只返回单次 查询的结果下一级的查询由本地 DNS 服务器自己进行。 十一、DNS 记录和报文
DNS 服务器中以资源记录的形式存储信息每一个 DNS 响应报文一般包含多条资源记录。一条资源记录的具体的格式为 NameValueTypeTTL 其中 TTL 是资源记录的生存时间它定义了资源记录能够被其他的 DNS 服务器缓存多长时间。
常用的一共有四种 Type 的值分别是 A、NS、CNAME 和 MX 不同 Type 的值对应资源记录代表的意义不同
如果 Type A则 Name 是主机名Value 是主机名对应的 IP 地址。因此一条记录为 A 的资源记录提供了标 准的主机名到 IP 地址的映射。如果 Type NS则 Name 是个域名Value 是负责该域名的 DNS 服务器的主机名。这个记录主要用于 DNS 链式 查询时返回下一级需要查询的 DNS 服务器的信息。如果 Type CNAME则 Name 为别名Value 为该主机的规范主机名。该条记录用于向查询的主机返回一个主机名 对应的规范主机名从而告诉查询主机去查询这个主机名的 IP 地址。主机别名主要是为了通过给一些复杂的主机名提供 一个便于记忆的简单的别名。如果 Type MX则 Name 为一个邮件服务器的别名Value 为邮件服务器的规范主机名。它的作用和 CNAME 是一 样的都是为了解决规范主机名不利于记忆的缺点。十二、UDP协议为什么不可靠
UDP在传输数据之前不需要先建立连接远地主机的运输层在接收到UDP报文后不需要确认提供不可靠交付。总结就以下四点
不保证消息交付不确认不重传无超时不保证交付顺序不设置包序号不重排不会发生队首阻塞不跟踪连接状态不必建立连接或重启状态机不进行拥塞控制不内置客户端或网络反馈机制十三、即时通讯的实现短轮询、长轮询、SSE 和 WebSocket 间的区别
短轮询和长轮询的目的都是用于实现客户端和服务器端的一个即时通讯。
短轮询的基本思路浏览器每隔一段时间向浏览器发送 http 请求服务器端在收到请求后不论是否有数据更新都直接进行响应。这种方式实现的即时通信本质上还是浏览器发送请求服务器接受请求的一个过程通过让客户端不断的进行请求使得客户端能够模拟实时地收到服务器端的数据的变化。这种方式的优点是比较简单易于理解。缺点是这种方式由于需要不断的建立 http 连接严重浪费了服务器端和客户端的资源。当用户增加时服务器端的压力就会变大这是很不合理的。长轮询的基本思路首先由客户端向服务器发起请求当服务器收到客户端发来的请求后服务器端不会直接进行响应而是先将这个请求挂起然后判断服务器端数据是否有更新。如果有更新则进行响应如果一直没有数据则到达一定的时间限制才返回。客户端 JavaScript 响应处理函数会在处理完服务器返回的信息后再次发出请求重新建立连接。长轮询和短轮询比起来它的优点是明显减少了很多不必要的 http 请求次数相比之下节约了资源。长轮询的缺点在于连接挂起也会导致资源的浪费。SSE 的基本思想服务器使用流信息向服务器推送信息。严格地说http 协议无法做到服务器主动推送信息。但是有一种变通方法就是服务器向客户端声明接下来要发送的是流信息。也就是说发送的不是一次性的数据包而是一个数据流会连续不断地发送过来。这时客户端不会关闭连接会一直等着服务器发过来的新的数据流视频播放就是这样的例子。SSE 就是利用这种机制使用流信息向浏览器推送信息。它基于 http 协议目前除了 IE/Edge其他浏览器都支持。它相对于前面两种方式来说不需要建立过多的 http 请求相比之下节约了资源。WebSocket是 HTML5 定义的一个新协议议与传统的 http 协议不同该协议允许由服务器主动的向客户端推送信息。使用 WebSocket 协议的缺点是在服务器端的配置比较复杂。WebSocket 是一个全双工的协议也就是通信双方是平等的可以相互发送消息而 SSE 的方式是单向通信的只能由服务器端向客户端推送信息如果客户端需要发送信息就是属于下一个 http 请求了。
上面的四个通信协议前三个都是基于HTTP协议的。
对于这四种即使通信协议从性能的角度来看 WebSocket 长连接SEE 长轮询 短轮询 但是我们如果考虑浏览器的兼容性问题顺序就恰恰相反了 短轮询 长轮询 长连接SEE WebSocket 所以还是要根据具体的使用场景来判断使用哪种方式。 十四、TCP粘包是怎么回事如何处理?
默认情况下, TCP 连接会启用延迟传送算法 (Nagle 算法), 在数据发送之前缓存他们。如果短时间有多个数据发送, 会缓冲到⼀起作⼀次发送 (缓冲大小见socket buffer size), 这样可以减少 IO 消耗提高性能。
如果是传输文件的话, 那么根本不用处理粘包的问题, 来⼀个包拼⼀个包就好了。但是如果是多条消息, 或者是别的用途的数据那么就需要处理粘包。
下面看⼀个例子,连续调用两次 send 分别发送两段数据 data1 和 data2, 在接收端有以下几种常见的情况:
A. 先接收到 data1, 然后接收到 data2
B. 先接收到 data1 的部分数据, 然后接收到 data1 余下的部分以及 data2 的全部
C. 先接收到了 data1 的全部数据和 data2 的部分数据, 然后接收到了 data2 的余下的数据
D. ⼀次性接收到了 data1 和 data2 的全部数据
其中的 BCD 就是我们常⻅的粘包的情况. 而对于处理粘包的问题, 常见的解决方案有:
多次发送之前间隔⼀个等待时间只需要等上⼀段时间再进⾏下⼀次 send 就好, 适⽤于交互频率特别低的场景. 缺点也很明显, 对于比较频繁的场景而言传输效率实在太低不过几乎不用做什么处理关闭Nagle算法关闭 Nagle 算法, 在 Node.js 中你可以通过 socket.setNoDelay() ⽅法来关闭 Nagle 算法, 让每⼀次 send 都不缓冲直接发送。该方法比较适用于每次发送的数据都比较大 (但不是文件那么大), 并且频率不是特别⾼的场景。如果是每次发送的数据量比较小, 并且频率特别高的, 关闭 Nagle 纯属自废武功。另外, 该⽅法不适⽤于网络较差的情况, 因为 Nagle 算法是在服务端进行的包合并情况, 但是如果短时间内客户端的网络情况不好, 或者应⽤层由于某些原因不能及时将 TCP 的数据 recv, 就会造成多个包在客户端缓冲从而粘包的情况。 (如果是在稳定的机房内部通信那么这个概率是比较小可以选择忽略的) 进行封包/拆包封包/拆包是目前业内常⻅的解决⽅案了。即给每个数据包在发送之前, 于其前/后放⼀些有特征的数据, 然后收到数据的时 候根据特征数据分割出来各个数据包十五、为什么udp不会粘包
TCP协议是面向流的协议UDP是⾯向消息的协议。UDP段都是⼀条消息应⽤程序必须以消息为单位提取数据不能⼀次提取任意字节的数据UDP具有保护消息边界在每个UDP包中就有了消息头消息来源地址端⼝等信息这样对于接收端来说就容易进⾏区分处理了。传输协议把数据当作⼀条独立的消息在网上传输接收端只能接收独立的消息。接收端⼀次只能接收发送端发出的⼀个数据包,如果⼀次接受数据的⼤小小于发送端⼀次发送的数据大小就会丢失⼀部分数据即使丢失接受端也不会分两次去接收
