创建一个企业网站流程的步骤,定制手机壳的网站,怎样创建网站以及建站流程是什么,wordpress 评论 重复1.在浏览器中输⼊URL并按下回⻋之后会发⽣什么 2.TCP三次握⼿的过程,为什么三次握手 TCP#xff08;传输控制协议#xff09;的三次握⼿是建⽴⽹络连接的过程#xff0c;确保通信双⽅能够正确地进⾏数据传输。 第⼀次握⼿#xff08;SYN#xff09;#xff1a; 客户端传输控制协议的三次握⼿是建⽴⽹络连接的过程确保通信双⽅能够正确地进⾏数据传输。 第⼀次握⼿SYN 客户端Client向服务器Server发送⼀个带有 SYN同步标志位的包表示客户端希望建⽴连接。该包同 时指定客户端的初始序列号Client Sequence Number。 第⼆次握⼿SYN ACK 服务器收到客户端的 SYN 包后会回复⼀个带有 SYN 和 ACK确认标志位的包表示服务器接受了客户端的请 求并希望建⽴连接。服务器也会指定⾃⼰的初始序列号以及对客户端序列号的确认。 3. 第三次握⼿ACK 客户端收到服务器的 SYNACK 包后会发送⼀个带有 ACK 标志位的包作为确认回复。这个包的序列号会加⼀表 示客户端已经准备好与服务器进⾏数据传输。 此时TCP 连接已经建⽴起来通信双⽅可以开始进⾏数据传输。 为什么是三次握手
三次握⼿的⾸要原因是为了防⽌旧的重复连接初始化造成混乱。 如果是两次握⼿连接就⽆法阻⽌历史连接那为什么 TCP 两次握⼿为什么⽆法阻⽌历史连接呢 我先直接说结论主要是因为在两次握⼿的情况下服务端没有中间状态给客户端来阻⽌历史连接导致服务端可能建⽴⼀个历史连接造成资源浪费。 你想想在两次握⼿的情况下服务端在收到 SYN 报⽂后就进⼊ ESTABLISHED 状态意味着这时可以给对⽅发送数据但是客户端此时还没有进⼊ ESTABLISHED 状态假设这次是历史连接客户端判断到此次连接为历史连接那么就会回 RST 报⽂来断开连接⽽服务 端在第⼀次握⼿的时候就进⼊ ESTABLISHED 状态所以它可以发送数据的但是它并不知道这个是历史连接它只有在收到 RST 报⽂后才会断开连接。
3.TCP四次挥⼿的过程为什么四次挥手 四次挥⼿是指在TCP连接的断开过程中由客户端先断开然后由服务器进⾏最后的断开。 具体的四次挥⼿步骤如下
客户端发送⼀个FIN终⽌报⽂给服务器表示客户端不再发送数据。服务器收到FIN报⽂后发送⼀个ACK确认报⽂给客户端表示收到了客户端的终⽌请求。服务器发送⼀个FIN报⽂给客户端表示服务器也不再发送数据。客户端收到服务器的FIN报⽂后发送⼀个ACK报⽂给服务器确认收到了服务器的终⽌请求然后关闭连 接。 这样经过四次挥⼿TCP连接才会完全关闭。因为TCP是全双⼯连接双⽅都需要通知对⽅停⽌数据传输所以 需要四次握⼿来完成断开连接的过程。
可以看到每个⽅向都需要⼀个 FIN 和⼀个 ACK因此通常被称为四次挥⼿。
为什么 TCP 挥⼿需要四次呢
TCP是全双工通信可以双向传输数据。任何一方都可以在数据传送结束后发出连接释放的通知待对方确认后进入半关闭状态。 当另一方也没有数据再发送的时候则发出连接释放通知对方确认后才会完全关闭了 TCP 连接。 总结两次握手可以释放一端到另一端的 TCP 连接完全释放连接一共需要四次握手
服务器收到客户端的 FIN 报⽂时内核会⻢上回⼀个 ACK 应答报⽂但是服务端应⽤程序可能还有数据要发送所以并不能⻢上发送 FIN 报⽂⽽是将发送 FIN 报⽂的控制权交给服务端应⽤程序 如果服务端应⽤程序有数据要发送的话就发完数据后才调⽤关闭连接的函数如果服务端应⽤程序没有数据要发送的话可以直接调⽤关闭连接的函数 从上⾯过程可知是否要发送第三次挥⼿的控制权不在内核⽽是在被动关闭⽅上图的服务端的应⽤程序因为应⽤程序可能还有数据要发送由应⽤程序决定什么时候调⽤关闭连接的函数当调⽤了关闭连接的函数内核就会发送 FIN 报⽂了所以服务端的 ACK 和 FIN ⼀般都会分开发送。
4.TCP与UDP的概念特点区别和对应的使用场景
TCP与UDP的概念 ● TCP传输控制协议是一种面向连接的、可靠的、基于字节流的传输层通信协议。 ● UDP用户数据报协议为应用程序提供了一种无需建立连接就可以发送封装的IP数据包的方法。特点 ● TCP面向连接传输可靠传输形式为字节流传输效率慢所需资源多。 ● UDP无连接、传输不可靠、传输形式为数据报文段传输效率快所需资源少。区别 ● 是否面向连接: TCP 是面向连接的传输UDP 是无连接的传输。 ● 是否是可靠传输TCP是可靠的传输服务在传递数据之前会有三次握手来建立连接在数据传递时有确认、窗口、重传、拥塞控制机制。 UDP是不可靠传输数据传递不需要给出任何确认且不保证数据不丢失及到达顺序。 ● 是否有状态TCP 传输是有状态的它会去记录自己发送消息的状态比如消息是否发送了、是否被接收了等等而 UDP 是无状态的。 ● 传输形式: TCP 是面向字节流的UDP 是面向报文的。 ● 传输效率:由于TCP 传输的时候多了连接、确认重传等机制所以TCP 的传输效率要比UDP 低。 ● 首部开销 :TCP 首部开销 (20 ~ 60字节)比UDP 首部开销 (8字节)要大。 ● 是否提供广播或多播服务: TCP 只支持点对点通信UDP 支持一对一、一对多、多对一、多对多。对应的使用场景 ● TCP常用于要求通信数据可靠场景如网页浏览、文件传输、邮件传输、远程登录、数据库操作 等。 ● UDP常用于要求通信速度高场景如域名转换、视频直播、实时游戏等。
5.HTTP请求常见的状态码和字段 6.常见的请求方式GET和POST请求的区别
这些区别主要体现在用途、数据传输方式、安全性、数据容量、编码方式、缓存机制、TCP数据包产生方式以及幂等性上。 作用 GET主要用于请求服务器发送资源例如请求网页、图片或视频等。POST主要用于向服务器提交数据例如提交表单数据、上传文件等。 参数传递方式 GET参数通过URL传递这导致数据容易被截取或查看。POST参数放在HTTP请求体中对外不可见支持更大的数据量和更多的数据类型。 安全性 GET因参数直接附在URL后安全性较低不适合传输敏感信息。POST由于数据在请求体内安全性较高适合传输敏感信息。 参数长度限制 GET参数长度受限通常限制在URL长度约2KB内限制由浏览器和服务器决定。POST理论上没有数据量限制适合大量数据传输。 编码方式 GET请求通常只使用application/x-www-form-urlencoded编码类型。POST支持多种编码方式包括multipart/form-data用于文件上传。 缓存机制 GET请求可以被浏览器缓存URL可存为书签并保留在浏览器历史记录中。POST请求不会被浏览器缓存请求数据不会保存在浏览器历史中且不能被存为书签。 TCP数据包 GET请求一般只生成一个TCP数据包header和data一起发送。POST请求一般会生成两个TCP数据包先发送header服务器响应100 continue后发送data。 幂等性 GET是幂等的多次执行相同的GET请求服务器上的资源状态不变结果相同。POST不是幂等的多次执行相同的POST请求可能会在服务器上创建多份资源结果不同。
选择GET还是POST请求方式取决于操作的性质和需求。如果目的是从服务器获取数据且操作对数据没有影响GET是更合适的选择。如果目的是向服务器提交数据以更改服务器状态或更新资源应使用POST。在设计Web应用时了解和正确使用这两种请求方法对于提高应用的安全性、效率和用户体验至关重要。
7.什么是强缓存和协商缓存
在Web开发中缓存是一种重要的性能优化手段它可以减少服务器的负载加快页面的加载速度。缓存策略主要分为两种强缓存Strong Cache和协商缓存Negotiated Cache。这两种缓存策略的运用能有效地控制资源的获取方式决定资源是从服务器重新获取还是直接从浏览器缓存中读取。
强缓存
强缓存不会向服务器发送请求直接从缓存中读取资源。强缓存可以通过设置HTTP响应头中的Expires和Cache-Control来实现
ExpiresHTTP/1.0中存在的字段用来指定资源到期的时间。如果浏览器发现当前时间小于Expires指定的时间就会直接使用缓存数据不会向服务器发起请求。但是Expires是一个绝对时间受本地时间影响可能会导致缓存失效。Cache-Control在HTTP/1.1中引入更加灵活。它可以通过设置max-age值来控制资源的最大缓存时间相对时间优先级高于Expires。例如Cache-Control: max-age3600表示资源可以被缓存且有效期为3600秒。
当强缓存有效时浏览器不会向服务器发送请求即使按下刷新按钮通常也会直接从缓存加载资源状态码为200但有时会标记为from cache。
协商缓存
当强缓存失效后浏览器会向服务器发送请求由服务器决定是否使用缓存。协商缓存涉及的HTTP头包括Last-Modified/If-Modified-Since和ETag/If-None-Match
Last-Modified/If-Modified-Since服务器通过Last-Modified响应头告诉浏览器资源的最后修改时间。下次浏览器请求时通过If-Modified-Since请求头发送这个时间。服务器比较时间如果资源未修改返回304 Not Modified状态码浏览器则从缓存中加载资源。ETag/If-None-MatchETag是资源的唯一标识由服务器生成。浏览器在初次接收到资源时会保存ETag值并在下次请求时通过If-None-Match发送这个值。服务器比对ETag如果未发生变化则返回304浏览器继续使用缓存的资源。
协商缓存需要服务器参与每次都会发送请求到服务器如果资源未修改虽然不会下载资源但是会消耗一定的网络带宽。
总结
强缓存优先级高直接从缓存读取资源不会发送请求到服务器极大地减少了网络带宽消耗。协商缓存需要服务器确认资源是否更新如果资源未更新返回304状态码浏览器继续使用缓存的资源。
合理配置强缓存和协商缓存可以有效提升Web应用的性能和用户体验。
8.HTTP1.0和HTTP1.1的区别
长连接Persistent Connections
HTTP 1.1 默认支持长连接Keep-Alive这意味着在一个TCP连接上可以传输多个HTTP请求和响应减少了建立和关闭连接的频繁操作从而减少了延迟并提高了网络传输效率。HTTP 1.0 默认使用短连接即每个HTTP请求/响应对后都会关闭TCP连接。这会导致每次请求都需要重新建立TCP连接增加了额外的延迟和网络负担。
缓存
HTTP 1.0 使用If-Modified-Since和Expires头部作为缓存的判断标准依赖于资源的最后修改时间和过期时间来控制缓存。HTTP 1.1 引入了更多的缓存控制策略如Entity tag (ETag)和If-None-Match提供了更灵活和精确的缓存验证机制。
3. 管道化Pipelining
HTTP 1.1 的长连接特性使得管道化成为可能。客户端可以在等待第一个请求的响应时发送后续请求这可以减少等待时间理论上提高页面加载速度。但由于响应必须按照请求的顺序返回且服务器端支持程度不一实际效果可能有限。
4. 增加Host字段
HTTP 1.1 引入了必须的Host头部允许同一个物理服务器上托管多个域名的网站是虚拟主机技术的关键支持。
5. 状态码
HTTP 1.1 新增了24个状态响应码提供了更细粒度的错误处理和更丰富的状态信息。
6. 带宽优化
HTTP 1.0 存在带宽浪费的问题比如服务器发送整个资源即使客户端只需要部分内容。HTTP 1.1 通过引入Range请求头和206Partial Content响应码支持部分请求和断点续传显著提高了带宽利用率尤其是在大文件传输和流媒体服务中非常有用。
9.HTTP2.0与HTTP1.1的区别
HTTP/2引入了一系列改进HTTP协议的新特性旨在解决HTTP/1.x特别是HTTP/1.1在现代网络环境下面临的性能限制。以下是HTTP/2的主要改进点及其分析
二进制分帧
概念在应用层HTTP和传输层TCP或UDP之间增加一个二进制分帧层。这一层负责将所有传输的信息分割成更小的消息和帧并对它们进行二进制编码。好处此改进使得HTTP/2能够突破HTTP/1.1的性能限制实现更低的延迟和更高的吞吐量。二进制协议比传统的文本协议更紧凑解析速度更快效率更高。
多路复用Multiplexing
概念在一个TCP连接上同时发送多个请求和响应而不需要等待前一个完成。好处这解决了HTTP/1.x中的队头阻塞问题即之前的请求延迟会导致后续请求即使已经就绪也无法发送。多路复用使得多个请求和响应可以同时在一个连接上进行显著提高了网页加载速度和网络利用率。
首部压缩
概念HTTP/2使用HPACK算法对首部header数据进行压缩减少了首部的大小并减少了发送包的数量。好处由于HTTP/1.x的首部未经压缩包含许多重复的首部字段这会导致不必要的带宽浪费。HTTP/2通过首部压缩可以减少单个请求-响应的开销降低延迟提高传输效率。
服务端推送Server Push
概念服务器可以主动推送资源到客户端的缓存中而无需客户端明确请求。好处服务端推送可以进一步减少加载时间因为服务器可以预测客户端需要的资源并提前发送。这减少了往返次数和等待时间尤其在复杂的应用中可以显著提升性能。
10.HTTPS的工作原理(https是怎么建立连接的
这个过程详细描述了使用数字证书进行安全通信的过程这种机制通常是在HTTPSHTTP Secure协议中实现的用于在互联网上安全地传输数据。以下是对这个过程中的关键步骤和安全机制的分析
建立连接请求
步骤客户端向服务器发起连接请求开始SSL/TLS握手过程。
数字证书生成
步骤服务器生成一对公私钥并将公钥发送给CA证书颁发机构申请数字证书。CA使用其私钥对服务器的公钥和一些身份信息进行签名生成数字证书。安全机制这一步确保了服务器的公钥是经过可信第三方CA验证的增加了信任度。
证书发送给客户端
步骤服务器将获得的数字证书发送给客户端。安全机制客户端通过验证数字证书来确认服务器的身份防止中间人攻击。
客户端验证证书
步骤客户端解析并验证服务器发送的数字证书确保它是由可信CA签发的。安全机制客户端内置的CA公钥用于验证数字证书的签名确保了证书的真实性和服务器的身份。
对称加密密钥的生成
步骤客户端生成一个随机码对称加密的密钥用于后续通信。安全机制对称加密密钥只在客户端和服务器之间共享保证了传输数据的机密性。
加密的对称密钥传输
步骤客户端用服务器的公钥加密这个随机码然后发送给服务器。安全机制即使中间人截获了加密的密钥也无法解密因为只有服务器的私钥能解开。
服务端解密对称密钥
步骤服务器用自己的私钥解密收到的加密密钥获得对称加密的密钥。安全机制确保了只有服务器能解密并获取对称加密的密钥。
加密数据传输
步骤服务器和客户端使用对称加密密钥加密通信内容。安全机制对称加密确保了数据传输过程的机密性和完整性。
加密通信
步骤客户端和服务器持续使用对称密钥进行加密通信。安全机制对称加密的高效性使得加密通信在性能上可行同时保证了通信安全。
总结
整个过程通过结合非对称加密用于身份验证和对称密钥的安全交换和对称加密用于高效的数据加密通信的方式确保了通信的安全性。这种机制既保证了通信双方身份的真实性又确保了数据传输的机密性和完整性是现代安全通信不可或缺的部分。
