当前位置：首页 > news >正文

客户网站留言旅游网站建设背景

news 2026/4/21 16:42:23

客户网站留言,旅游网站建设背景,子商务网站建设的一般流程图,做网站工具不懂代码网络模型 OSI 应用层#xff1a;给应用程序提供统一的接口表示层#xff1a;把数据转换成兼容另一个系统能识别的格式会话层#xff1a;负责建立、管理、终止表示层实体之间的通信会话传输层#xff1a;负责端到端的数据传输网络层#xff1a;负责数据的路由、转发、分片…网络模型 OSI 应用层给应用程序提供统一的接口表示层把数据转换成兼容另一个系统能识别的格式会话层负责建立、管理、终止表示层实体之间的通信会话传输层负责端到端的数据传输网络层负责数据的路由、转发、分片数据链路层负责数据的封帧和差错检测以及MAC寻址物理层负责在物理网络中传输数据帧 TCP/IP模型应用层支持HTTP、SMTP等最终用户进程传输层处理主机到主机之间的通信网络层寻址和路由数据包链路层通过网络的物理电线或无线信道移动比特 TCP在传输层IP在网络层应用层应用层的协议 HTTP、HTTPS、CDN、DNS、FTP HTTP报文有哪几部分请求报文请求行请求方法、目标、HTTP版本请求头请求的附加信息Host、User-Agent…空行请求头和请求体之间用空行空格请求体请求的数据用于POST请求需要传输数据的情况响应报文状态行HTTP协议、状态码、状态信息响应头响应的附加信息Content-Type、Content-Length…空行响应头和响应体之间用空行空格响应体包含响应的数据服务器返回的HTML、JSON… HTTP常用状态码 1xx提示信息协议处理的中间状态还需要后续操作少用 2xx成功报文已收到并被正确处理200、204、206 3xx资源重定向资源位置发生变动需要客户端重新用新的URL发请求301、302、304 301 - 永久重定向说明请求的资源已经不存在了需要改用新的URL再次访问302 - 临时重定向说明请求的资源还在但是暂时需要用另一个URL访问 301 和 302都会在响应头指明后续要跳转的URL 4xx客户端错误请求报文有误服务器无法处理400、403、404、405 404 - 无法找到此页面405 - 请求的方法类型不支持 5xx服务器错误500、501、502、503 502 - 服务器执行请求时从上游服务器接收到无效的响应504 - 服务器执行请求时未能及时从上游服务器收到响应 nginx是代理服务器收到客户端请求后将请求发到后端服务器 502nginx收到无效的响应503请求超时超过了nginx的配置时间 GET和POST的区别 GET从服务器获取资源请求参数写在URL位置URL只支持ASCII且浏览器对URL的有限制 POST根据body对指定的资源做处理携带的数据写在body里。 GET是安全、幂等的只读可以对GET数据做缓存可以缓存到浏览器上也可以缓存到nginx上在浏览器中GET请求可以保存为书签。 POST是不安全、不是幂等的写浏览器一般不会缓存POST请求也不能把POST请求保存为书签实际开发中也会用POST方法实现查询数据的请求 HTTP长连接 HTTP协议是“请求-响应”模式先建立TCP连接客户端发起了HTTP请求服务器收到后就返回响应然后释放TCP连接。 HTTP短连接一次连接只能请求一次资源 HTTP长连接Keep-Alive使用同一个TCP连接来发送和接收多个HTTP请求避免了连接建立和释放的开销。只要任何一段没有明确提出断开连接则保持TCP连接状态。 HTTP怎么对请求做拆包的请求的拆包是通过“Content-Length”头字段来进行的。该字段指示了请求正文的长度服务器可以根据该长度来正确接收和解析请求。客户端发送HTTP请求会在请求头中增加“Content-Length”字段用来表示请求正文的字节数浏览器根据“Content-Length”字段来确定请求的长度并从请求中读取相应数量的字节直到读取完整个请求的内容 HTTP为什么不安全 HTTP是基于明文传输的通信链路上可以获取通信内容其他用户可以篡改内容也可以冒充发送方。 HTTPS是在HTTP和TCP层之间引入了SSL/TLS协议解决了上述风险。 HTTP 和 HTTPS的区别 HTTP是超文本传输协议存在安全风险HTTPS解决了HTTP不安全的缺陷在TCP和HTTP之间加入了SSL/TLS协议HTTP建立相对简单通过TCP三次握手后就可以进行HTTP的报文传输HTTPS在TCP三次握手后还需要建立SSL/TLS的握手才能进行加密报文传输HTTP默认端口80HTTPS默认端口443HTTPS需要向CA申请数字证书来保证服务器的身份是可用的 TLS的四次握手过程第一次握手客户端向服务器发起加密通信请求ClientHello主要发送以下信息客户端支持的TLS协议版本客户端生成的随机数后边用于生成会话秘钥客户端支持的密码套件列表RSA加密算法第二次握手服务器收到客户端请求后向客户端发出响应ServerHello主要回应以下信息确认TLS协议版本服务器生成的随机数后边也是用于生成会话秘钥确认的密码套件列表RSA加密算法服务器的数字证书第三次握手客户端收到服务器回应后通过浏览器或操作系统里的CA公钥确认服务器的数字证书的真实性。整数如果没有问题就会从数字证书里取出服务器的公钥用它加密报文向服务器发送以下信息一个随机数会被服务器公钥加密加密通信算法改变通知告知服务器随后的信息都会用“会话密钥”加密通信客户端握手结束通知表示客户端的握手已经结束通过这三个随机数接着用双方协商的加密算法各自生成本次通信的“会话密钥” 第四次握手服务器通过协商的加密算法计算出本次通信的“会话密钥”向客户端回应以下消息加密通信算法改变通知告知客户端随后的消息都会用“会话密钥”加密通信服务器握手结束通知表明服务器的握手已经结束整个TLS的握手全部结束后服务器与客户端就会进入加密通信完全是使用普通的HTTP协议只不过用“会话密钥”加密内容 HTTPS如何防范中间人攻击加密https握手期间会通过非对称加密方式协商出对称加密密钥身份验证客户端与服务器建立连接后服务器会将CA证书发送给客户端客户端会去校验CA整数的合法性。验证通过后使用证书中的公钥来加密数据并将加密后的数据传给服务器服务器用私钥解密中间人的攻击在于冒充服务器与客户端建立连接但是中间人拿不到服务器的私钥无法正确解密客户端发过来的数据。同时如果客户端校验CA证书后证书验证失败也会中断连接。 HTTP1.1 和 HTTP2.0的区别头部压缩HTTP2会压缩头部如果发送多个请求他们的请求头部是一样的协议会帮忙消除重复的部分。 HPACK算法客户端和服务器同时维护一张头部信息表所有的字段都存入这个表中并生成一个索引号以后就不会发送同样的字段直接发送索引号即可。二进制格式HTTP1.1采用的是纯文本形式的报文HTTP2全面采用了二进制格式。增加了数码据传输的效率并发传输多个Stream复用在同一条TCP连接上解决了HTTP1.1队头阻塞的问题服务器主动推送资源服务器不再是被动的响应可以主动向客户端发送消息 HTTP进行TCP连接之后什么情况下会断开连接客户端或服务器发送一条FIN报文就会进行四次挥手发送方发送了一条数据给服务器服务器超过一段时间没有响应ACK报文发送方重传达到最大次数时就会断开TCP连接HTTP长时间没有进行请求和响应。 HTTP、SOCKET和TCP的区别 HTTP应用层协议定义了客户端和服务器之间交换数据的规则在客户端和服务器之间传输和显示web页面Socket用于描述通信链路的一端提供了底层的通信接口可实现不同计算机之间的数据交换TCP传输层协议负责在网络中建立可靠的数据传输连接 DNS是什么 DNS是用来将域名转化成IP地址的数据库系统端口号53。越靠右层级越高根域名服务器顶级域名服务器权威域名服务器 DNS底层是基于UDP协议的因为UDP可以提供低延迟的特性更适合DNS这种需要快速响应的域名解析服务。虽然UDP存在丢包和数据包损坏的风险但是DNS使用一些机制来提高可靠性超时重传、请求重试、缓存… DNS域名解析流程客户端发送DNS请求发送给本地域名服务器本地域名服务器先去查询缓存如果查到直接返回IP地址如果没有查到就进行迭代查询本地域名服务器去访问他的根域名服务器根域名服务器并不会进行域名解析而是告诉它顶级域名服务器的IP地址本地域名服务器又去访问顶级域名服务器顶级域名服务器也不会进行域名解析而是告诉它权威域名服务器的IP地址本地域名服务器又去访问权威域名服务器权威域名服务器是域名解析结果的原出处将该域名对应的IP地址告诉本地域名服务器随后本地域名服务器将IP地址返回给客户端成功建立连接。 HTTP是无状态的吗 HTTP是无状态的服务器不会在多个请求中保留客户端状态的信息在每个HTTP请求中服务器不会记住之前的请求和会话状态每个请求都是独立的。可以通过一些机制来实现状态保持例如使用Cookie和Session来跟踪用户的状态。通过在客户端存储会话信息服务器可以识别和跟踪特定用户的状态。携带Cookie的HTTP是有状态的Cookie是用来在客户端存储会话信息和状态信息的通过使用Cookie可以实现一定程度的状态保持功能。 Cookie是HTTP协议簇的一部分只是无状态协议下的一种补充用来在客户端存储状态信息以实现状态保持。 Cookie和Session的区别存储位置Cookie存储在客户端浏览器向服务器发请求时会自动携带CookieSession存在服务器服务器为每个用户分配一个SessionId通过Cookie的方式发送给客户端客户端的后续请求都会携带SessionId服务器根据SessionId找到对应的数据数据容量单个Cookie大小限制在4KB左右Session存储在服务器上主要受限于服务器内存大小安全性Cookie存储在客户端相对不安全Session存储在服务器比Cookie安全生命周期Cookie可以设置过期时间过期后自动删除也可以设置会话Cookie浏览器关闭后自动删除Session在默认情况下用户关闭浏览器时Session结束服务器也可以设置Session的超时时间。 token、session、cookie的区别 session存储在服务器拥有一个唯一的SessionId这个SessionId一般存放在Cookie中。服务器收到Cookie后会解析SessionId再去Session列表中查找找到对应的Session。 Cookie类似于一个令牌装有SessionId存储在客户端浏览器一般会自动添加 Token类似一个令牌无状态用户信息都被加密到Token中服务器收到Token后解密就可以知道是哪个用户需要开发者手动添加。客户端如果禁用了CookieSession也无法正常使用因为大部分的服务器都是依赖Cookie来传递sessionId。数据存储在localStorage和Cookie有什么区别存储容量Cookie的存储容量小LocalStorage的存储容量通常较大存储大量数据时LocalStorage更合适数据发送Cookie在每次请求时都会自动发送到服务器适合在服务器和浏览器中传输数据LocalStorage不会自动发送数据只在浏览器中存储数据更适合于同一个域名下不同页面之间共享数据生命周期Cookie可以设置过期时间LocalStorage的数据将永远存在浏览器中除非通过js代码手动删除安全性Cookie的安全性低因为Cookie每次请求都会发送给服务器存在监听和篡改的风险LocalStorage的数据只存储在浏览器中相对更安全。 JWT和传统方式的区别无状态JWT时无状态的令牌不需要在服务器存储会话信息。JWT令牌中包含了所有必要的信息。安全性JWT使用秘钥对令牌进行签名保证令牌的完整性和真实性。跨域JWT令牌可以在不同域之间传递可以实现无需Cookie的跨域身份验证。 JWT令牌由头部、载荷、签名三部分组成。头部、载荷JSON格式使用Base64编码进行序列化签名对头部、载荷、秘钥进行签名后的结果 JWT的缺点 JWT一旦派发出去在失效之前都是有效的没法即使撤销JWT 解决在业务层增加判断逻辑比如添加黑名单机制。使用Redis维护一个黑名单如果让某个JWT失效就直接把这个JWT加入黑名单中每次使用前就判断这个JWT是否存在黑名单中。前端如何存储JWT 传统方式浏览器向服务器发起请求服务器在当前会话session里保存相关数据并返回一个sessionId浏览器拿到sessionId后会存入Cookie以后每次发请求都会携带Cookie。服务器拿到Cookie后会解析出sessionId并通过这个sessionId找到前期保存的数据。如果是服务器集群情况下就需要session共享数据使得每个服务器都可以读取到session 优化服务器不存储session数据所有数据都保存在客户端每次请求都会发回服务器客户端收到服务器返回的JWT后可以存储在LocalStorage里也可以存储在Cookie里还可以存储在SessionStorage里。存储在LocalStorage里提供了较大的存储空间不会随HTTP一起发送给服务器但是恶意脚本可能可以通过JS代码访问到JWTXSS攻击。存储在Cookie里设置HttpOnly标志来防止通过JS访问减少XSS攻击的风险但是单个Cookie只能存储4KB并且每次HTTP请求都会携带Cookie存储在SessionStorage当窗口关闭后数据会被清除但是用户的体验可能会受到影响每次刷新页面都需要重新登陆。 HTTP长连接和WebSocket的区别 TCP协议是全双工的HTTP1.1虽然是基于TCP的协议但是他是半双工的HTTP2是全双工的HTTP1.1对于大部分需要服务器主动推送到客户端的场景都不太友好而WebSocket是全双工的HTTP1.1里只要客户端不发起请求服务器就不会给响应。对于服务器和客户端之间需要频繁交互的复杂场景可以考虑webSocket 传输层 TCP头部序列号seq在建立连接时由计算机生成的随机数作为初始值每发送一次数据就累加一次该数据字节的大小。用来解决网络包乱序的问题确认应答号ack下次“期望”收到的数据的序列号发送端收到这个说明在这个序列号之前的所有数据都已被正常接收用来解决丢包问题控制位 ACK1 - 确认应答号有效RST1 - TCP连接出现异常时必须强制断开连接SYN1 - 希望建立连接FIN1 - 希望断开连接 TCP三次握手第三次握手可以携带数据前两次握手是不可以携带数据的一旦完成三次握手双方都处于established状态此时连接就已建立完成客户端与服务器就可以互相发送数据了。为什么TCP需要三次握手三次握手主要是为了防止旧的重复连接初始化造成混乱。客户端如果连续发送了多个SYN建立连接的报文在网络不好的情况下“旧的SYN报文seq 90”比“新的SYN报文seq 100”早到达此时服务器先返回一个SYNACK的报文给客户端客户端收到后发现自己期望收到的应该是100 1 101而不是90 1就返回RST报文。服务器收到RST报文后就会释放连接。等到新的SYN报文100 1到达后服务器与客户端就可以完成三次握手了如果只有两次握手无法防止旧的重复连接初始化。客户端先后发了两个SYN报文服务器收到了旧的SYN报文后也往客户端发一个SYNACK的报文如果只有两次握手此时双方都已进入established状态连接已建立。因为需要浏览器这里判断ack和期望的不同才会发送RST报文。 TCP三次握手在第三次握手中客户端发送的确认包丢了怎么办因为第三次握手的ACK是针对第二次握手的SYN的确认报文所以当第三次握手丢失了如果服务器一直收不到就会触发超时重传机制直到收到三次握手。如果达到最大重传次数服务器就会断开连接 TCP三次握手在第一次握手中客户端发送SYN报文丢失了怎么办客户端想和服务器建立连接向服务器发送SYN报文如果客户端一直收不到服务器的响应就会触发超时重传机制重传SYN报文重传的seq序列号是一样的如果达到最大重传次数客户端就不再发送SYN报文随后断开TCP连接 TCP三次握手在第二次握手中服务器的SYN ACK报文丢失了怎么办因为第二次握手的ACK报文代表对第一次握手的确认如果客户端没有收到第二次握手会认为自己第一次握手的SYN报文丢失客户端就会触发超时重传机制重传SYN报文。如果达到最大重传次数客户端就会断开连接。如果第二次握手丢失服务器收不到第三次握手服务器这里也会触发超时重传机制重传SYNACK报文如果达到最大重传次数服务器就会断开连接。第一次握手客户端发送SYN报文第二次握手服务器回复SYNACK报文这个过程中服务器做了什么第二次握手服务器收到客户端的SYN请求后会把该连接存储到半连接队列并向客户端发送SYNACK 第三次握手客户端收到后会发ACK报文给服务器服务器收到第三次握手的ACK后内核会把连接从半连接队列中移除然后创建新的完全的连接并添加到全连接队列等待进程调用accept函数把连接从全连接队列中取出来。如果有大量的SYN数据包从客户端发往服务器会导致服务器那边的半连接队列满了后续在收到SYN数据包就会丢弃。 TCP四次挥手客户端主动关闭连接发送FIN报文代表客户端已经不会发送数据了客户端进入FIN_WAIT_1状态服务器收到SYN报文回复ACK确认报文此时服务器进入CLOSE_WAIT状态此时服务器如果有数据要发送就需要发送完数据才能关闭连接如果没有数据要发送就可以直接关闭连接。服务器发完剩余的数据后发送FIN报文代表服务器也不会发送数据此时服务器进入LAST_ACK状态客户端收到FIN报文后发送ACK确认报文给服务器客户端此时进入TIME_WAIT状态服务器收到ACK确认后也进入CLOSE状态客户端经过2MSL时间后也进入CLOSE状态为什么四次挥手中间两次不能变成一次因为服务器收到客户端的FIN报文时需要立马响应ACK但是此时服务器可能还有数据没有发完所以不能马上发送FIN报文。因此四次挥手时服务器的ACK和FIN一般都是分两次发送的。第二次和第三次挥手之间客户端不能发送数据但是可以接收服务器还没发完的数据断开连接时客户端FIN包丢失第一次挥手不成功服务器的状态是什么客户端向服务器发送FIN报文如果发送的FIN报文丢失客户端收不到服务器的ACK确认就会触发超时重传机制重传FIN报文如果达到最大重传次数客户端就会直接进入CLOSE状态而服务器还是established状态。为什么四次挥手要等2MSL MSL是报文最大生存时间超过这个时间报文会被丢弃因为TCP报文是基于IP协议IP头有一个TTL字段是IP数据包可以经过的最大路由跳数 MSL的单位是时间TTL是经过路由跳数所以MSL应该大于等于TTL消耗为0的时间保证报文已经被自然消亡。等待2MSL主要是因为网络中可能存在发送方的报文这些发送方的数据包被接收方处理后又会向对方发送响应。一来一回需要等待2倍时间如果服务器没有收到客户端最后的ACK报文那么就会触发服务器的超时重传服务器会重新发送FIN报文一来一回正好2MSL相当于至少允许报文丢失一次 TCP和UDP的区别 TCP面向连接UDP无连接TCP一条链路只能由两个端点UDP支持一对一、一对多、多对多TCP可靠交付数据UDP尽最大努力交付基于UDP传输协议实现一个可靠的传输协议QUIC协议TCP有流量控制和拥塞控制UDP没有即使网络拥堵也不会影响UDP的发送速率TCP首部较长20字节长度不固定UDP首部只有8字节固定不变开销小。TCP是流式传输没有边界但是要保证顺序和可靠UDP是一个个包发送有边界可能会出现丢包和乱序。 TCP为什么可靠传输连接管理三次握手、四次挥手建立可靠连接序列号既能保证可靠性又能防止数据丢失还能避免数据重复。确认应答接收方收到数据后会发送ACK确认报文报文中也会携带此次确认的序列号如果未发送确认报文就会触发超时重传机制。超时重传数据包丢失指定时间内发送方未收到确认应答就会启动超时重传确认包丢失接收方收到重复数据时丢弃并重新回传ACK确认报文流量控制根据接收方处理能力来决定发送发的发送速度在TCP报文首部维护一个滑动窗口实现拥塞控制当网络拥堵时需要减少数据发送通过发送端维护一个拥塞窗口实现 TCP粘包问题粘包问题主要是不知道用户消息的边界在哪如果知道边界在哪就可以通过边界来划分出有效的用户信息。固定长度的消息【少用】每个用户消息都是固定的比如规定消息的长度是64字节当接收方收到64个字节的数据就会认为这个内容是一个完整的消息特殊字符作为边界在两个用户的消息之间插入一个特殊字符接收方收到数据后读取到这个特殊字符就认为已经读到了一个完整的消息。如果消息里正好有这个字符需要对消息里的字符做转义自定义消息结构包头数据包头大小固定包头里有个字段是用来说明随后的数据有多大。接收方收到包头后先解析包头的内容得到数据的长度然后接下来就继续读取数据直到读满数据长度。 TCP的拥塞控制在网络出现拥堵的情况如果发送大量的数据包会导致数据包丢失这时TCP就会触发重传机制导致网络的负担更重就会进入恶性循环。拥塞控制就是避免发送方的数据填满整个网络。发送方会维护一个拥塞窗口拥塞窗口会根据网络的拥塞程度动态变化。发送窗口 min(拥塞窗口, 接收窗口) 拥塞控制的四个算法慢启动发送方每收到一个ACK拥塞窗口 1指数增加当拥塞窗口达到慢启动门限就会使用拥塞避免算法拥塞避免发送方每收到一个ACK拥塞窗口 1/拥塞窗口线性增长拥塞发生当网络出现拥塞时发生数据包重传时就会触发重传机制超时重传慢启动门限设置为当前拥塞窗口的一半拥塞窗口直接设置为1快重传拥塞窗口设置为原来的一半慢启动门限等于当前拥塞窗口进入快恢复快恢复一般和快重传同时使用网络场景打开百度首页后发生了什么解析URL检查URL中是否出现了非法字符对非法字符进行转义后处理缓存判断判断请求的资源是否在缓存里如果在缓存里且没有失效就会直接使用如果失效会进行DNS解析 DNS解析如果资源不在缓存里就进行DNS解析先查询本地域名服务器如果本地域名服务器能找到对应的ip地址就返回如果找不到本地域名服务器就会分别迭代查询顶级域名服务器、根域名服务器、权威域名服务器最后在权威域名服务器中找到ip地址返回获取MAC地址当浏览器得到ip地址后数据传输还需要直到主机的MAC地址。因为应用层数据会往下传递给传输层在传输层又会下发给网络层网络层会将本机地址作为源地址获取的ip地址作为目的地址然后下发给数据链路层数据链路层需要得到双方的MAC地址本机的MAC地址作为源地址目的MAC地址需要分两种情况如果源ip地址和目的ip地址在同一个子网下可以使用ARP协议直接获取到目的主机的MAC地址如果源ip地址和目的ip地址不在同一个子网下就将请求交给网关由网关代为转发也是通过ARP协议获取网关的MAC地址此时目的MAC地址就是网关的MAC地址建立TCP连接使用目标IP地址和目标MAC地址发送SYN报文请求建立TCP连接然后由路由器转发到目标服务器后目标服务器恢复SYN_ACK报文客户端收到后发送ACK包表示收到服务器的确认TCP连接建立完成如果使用的是HTTPS协议在TCP三次握手之前还存在TLS的四次握手发送数据浏览器会向服务器发送HTTP请求服务器响应数据服务器收到请求后会根据请求的内容做处理后响应数据浏览器结束后主动发送FIN报文随后进入四次挥手。浏览器主动发送FIN报文表示要断开连接服务器收到后先返回ACK表示收到浏览器的断开请求服务器继续发送剩余的数据发送完毕后服务器也发送一个FIN报文表示服务器这里也发完了也断开连接浏览器收到服务器的断开请求后发送ACK报文表示已收到四次挥手结束。怎么判断两个服务器之间是正常连接的 TCP保活机制定义一个时间段在这个时间段内如果没有任何连接相关的活动TCP保活机制就会起作用每个一段时间就会发送一个探测报文如果探测报文没有得到响应认为TCP连接已经死亡系统内核将错误信息通知给上层应用程序。服务器ping不通但是http可以请求成功是为什么 ping走的是icmp协议http走的是tcp协议可能是服务器的防火墙禁止icmp协议但是没有禁止tcp协议。网络攻击 DDOS攻击分布式拒绝服务DDOS攻击是通过大规模互联网流量淹没目标服务器以破坏目标服务器的恶意行为。 SQL注入如果一个用户输入了一个字符串来查找特定的用户信息但是应用程序将这个用户的数据直接作为SQL查询的一部分而不考虑可能的安全问题那么攻击者可能会利用这一点来执行他们的恶意SQL查询。 CSRF攻击攻击者诱导用户执行恶意操作从而获取用户数据或执行恶意代码。通过伪造一个合法的HTTP请求来实现。 XSS攻击通过在web页面插入恶意脚本代码诱使用户访问该页面使得恶意脚本在用户浏览器中执行从而盗取用户信息。 DNS劫持攻击者在用户查询DNS服务器时篡改响应将用户请求的域名映射到攻击者控制的虚假IP地址上让用户误以为时正常的网站实际上被重定向到攻击者操控的恶意网站。

查看全文

http://www.hkea.cn/news/14356933/