admin管理员组文章数量:1567518
文章目录
- OSI七层和TCP/IP五层模型
- OSI七层模型:
- TCP/IP五层模型:
- http状态码
- 一个url请求经历了哪些过程
- 1. URL解析
- 2. DNS解析
- 3. 建立TCP链接 (3次握手)
- 4. 发送http/https请求
- 5. 服务端响应请求
- 6. 客户端(浏览器)解析数据,渲染页面
- 7. 断开TCP链接 (4次挥手)
- UDP和TCP
- UPD :
- TCP :
- 1.字节流传输示意图:
- 2.TCP报文首部信息格式:
- 3.tcp的3次握手 - 建立链接
- 4.tcp的4次挥手 - 断开连接
- 5.为啥是3次握手?
- 6.为啥是4次握手?
- 7.tcp可靠传输
- 8.TCP流量控制
- 9.TCP拥塞控制
- 对称加密和非对称加密
- 1.对称加密 : 密钥密文一起发送
- 2.非对称加密 :公钥加密,私钥解密
- 3.非对称加密用于签名校验
- http和https
- http:
- https:
- GET和POST的区别
- 网络转发和网络代理
- CORS跨域
- 啥是跨域?
- 怎么解决?
本人才疏学浅,如果哪里写错了,还请大佬们多多指教~
参考文章:https://blog.csdn/yangbindxj/article/details/125087593
OSI七层和TCP/IP五层模型
OSI七层模型:
TCP/IP五层模型:
http状态码
参考:https://wwwblogs/Jinge/archive/2012/08/29/2661641.html
本人摸着胸脯保证,这个点真的经常问,有必要记一下,标红的重点记。
ps:状态码有很多,这里我只是整理一些经常会用,面试老被问的,不是全部的http状态码(全部也记不过来…)
开搞:
类别 | 描述 | 人话 |
---|---|---|
1xx | 服务器收到请求,客户端请继续操作 | 不用特殊处理 |
2xx | 操作成功被接受并处理了 | 成功了 |
3xx | 资源重定向 | 你要找的东西不在这里了,诺,这是新的地址,重写发请求去找 |
4xx | 客户端请求错误 | 客户端发的请求不对,客户端的锅 |
5xx | 服务器错误 | 服务器处理出错了,服务器的锅 |
状态码 | 英文 | 中文 | 人话 |
---|---|---|---|
100 | Continue | 继续 | 继续搞 |
101 | Switching Protocols | 切换协议,只能切换到更新的协议 | 你换身新衣服 |
200 | Ok | 请求成功 | nice |
201 | Created | 成功请求并且创建了资源 | 收到了 |
202 | Accepted | 接受请求,但并未处理 | 收到了,待会处理 |
203 | Non-Authoritative information | 服务器已成功处理了请求,但返回的信息可能来自另一来源 | nice, 但给你的东西可能不是你想要的 |
204 | No Content | 服务器成功处理,但未返回内容 | 服务器干完活了,但是啥也没给你 |
205 | Reset Content | 服务器成功处理,没有新内容,浏览器要重置文档 | nice,刷新一下 |
300 | Multiple Choices | 多种选择。请求的资源可包括多个位置,相应可返回一个资源特征与地址的列表用于用户终端选择 | 这东西在很多地方都有, 给你列个表自己去找 |
301 | Moved Permanently | 请求的资源已被永久的移动到新URI,返回信息会包括新的URI,浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替 | 这东西不在这里,给你个新地址,以后就去这里找 |
302 | Found | 与301类似。但资源只是临时被移动。客户端应继续使用原有URI | 东西暂时不在这里,诺你去这里找,但下次继续来我这里找 |
303 | See Other | 与301类似。使用GET和POST请求查看 | 使用GET和POST方式再请求下 |
304 | Not Modified | 所请求的资源未修改,服务器返回此状态码时,不会返回任何资源。客户端通常会访问缓存的对应资源,通过提供 If-Modified-Since 头信息指出, 客户端希望只返回在指定日期之后修改的资源 | 东西在你那里有, 你看看自己的缓存,等定好的时间过了,那东西要是有修改我再给你 |
305 | Use Proxy | 所请求的资源必须通过代理访问 | 我不和你聊,找代理来 |
307 | Temporary Redirect | 与302类似。使用GET请求重定向 | 东西暂时不在这里,诺你去这里找,但下次继续来我这里找,但是要用get的方式 |
400 | Bad Request | 客户端请求的语法错误,服务器无法理解 | 你说错了 |
401 | Unauthorized | 请求要求用户的身份认证 | 出示下证件 |
403 | Forbidden | 服务器理解请求客户端的请求,但是拒绝执行此请求(一般是权限问题) | 我收到了,但是我不干活(一般是权限问题) |
404 | Not Found | 服务器无法根据客户端的请求找到资源(网页)。通过此代码,网站设计人员可设置“您所请求的资源无法找到”的个性页面 | 东西没了 |
408 | Request Time-out | 服务器等待客户端发送的请求时间过长,超时 | 你说话太慢了 |
413 | Request Entity Too Large | 由于请求的实体过大,服务器无法处理,因此拒绝请求。为防止客户端的连续请求,服务器可能会关闭连接。如果只是服务器暂时无法处理,则会包含一个Retry-After的响应信息 | 你说的太多了,处理不了 |
414 | Request-URI Too Large | 请求的URI过长(URI通常为网址),服务器无法处理 | 你给的url太长了,处理不了 |
415 | Unsupported Media Type | 服务器无法处理请求附带的媒体格式 | 这种格式处理不了 |
500 | Internal Server Error | 服务器内部错误,无法完成请求 | 服务器的锅 |
501 | Not Implemented | 服务器不支持请求的功能,无法完成请求 | 你这个功能处理不了 |
502 | Bad Gateway | 充当网关或代理的服务器,从远端服务器接收到了一个无效的请求 | 代理的锅 |
503 | Service Unavailable | 由于超载或系统维护,服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中 | 停服维护 |
504 | Gateway Time-out | 充当网关或代理的服务器,未及时从远端服务器获取请求 | 网关干活太慢了 |
505 | HTTP Version not supported | 服务器不支持请求的HTTP协议的版本,无法完成处理 | 你这个版本处理不了 |
一个url请求经历了哪些过程
1. URL解析
- URL 统一资源定位符号,用来定位互联网的资源。
- 根据url编码规则和网络标准对url进行解析,解析成格式正确的域名。
- 浏览器对URL进行判断
URL是否合法
合法:
判断是否完整:
不完整:
猜测补全前缀后缀,比如www. http之类的。
不合法:
把URL作为搜索条件,从用户默认的搜索引擎搜索,从书签等先开始查找。
2. DNS解析
- 检查浏览器缓存和本地hosts文件里面是否有这个域名对应的ip,如果有就从本地完成解析
- 本地没有的话,向本地域名解析服务器系统(tcp,ip参数中设置的DNS地址)发起域名解析的请求(校园网、移动、电信或联通运营商)
- 本地域名解析服务器还没有的话,本地域名解析服务器就:
- 发送请求到根DNS服务器,返回顶级DNS服务器地址。
- 再发送请求到顶级DNS服务器,返回权威DNS服务器地址。
- 再发送请求到权威DNS服务器,返回最终ip地址。
ps:前端可以在html页面头部写入dns缓存地址
3. 建立TCP链接 (3次握手)
4. 发送http/https请求
5. 服务端响应请求
6. 客户端(浏览器)解析数据,渲染页面
7. 断开TCP链接 (4次挥手)
UDP和TCP
参考王道考研,计算机网络部分。
UPD :
- UDP是无连接的,减少开销和发送数据之前的时延
- UDP使用最大努力交付,但不保证可靠交付。
- UDP是面向报文的,适合一次性传输少量数据的网络应用。
- UDP无拥塞控制,适合很多实时应用。
- UDP首部开销小,8B,TCP20B。
TCP :
- 每一条TCP连接只能有两个端点,每一条TCP连接只能是点对点的。
- TCP提供可靠交付的服务,无差错、不丢失、不重复、按序到达。(可靠有序,不丢不重)
- TCP是全双工通信,有发送缓存和接受缓存(每个端都可以发送和接受数据)。
- TCP面向字节流传输,把应用层数据看成一连串无结构的字节流。
1.字节流传输示意图:
2.TCP报文首部信息格式:
- 序号:此次发送数据的第一个字节的序号。(字节流每一个字节都按顺序编号)
- 确认号:期望收到回复数据的第一个字节的序号。
- 数据偏移:真正的数据距离报文段起始位置的偏移距离。
- 紧急位URG:URG=1时,标明此报文段中有紧急数据,是高优先级的数据,应尽快传送,不用在缓存里排队,配合紧急指针字段使用。
- 确认位ACK:ACK=1时确认号有效,在连接建立后所有传送的报文段都必须把ACK置为1。
- 推送位PSH:PSH=1时,接收方尽快交付接收应用进程,不再等到缓存填满再向上交付。
- 复位RST:RST=1时,表明TCP连接中出现严重差错,必须释放连接,然后再重新建立传输链接。
- 同步位SYN:SYN=1时,表明是一个连接请求/连接接受报文。
- 终止位FIN:FIN=1时,表明此报文段发送方数据已发完,要求释放连接。
- 窗口:指的是发送本报文段的一方的接收窗口,即现在允许对方发送的数据量。(tcp每一端都有一个发送窗口和一个接受窗口,称为滑动窗口)。
- 检验和:检验首部+数据。
- 紧急指针:URG=1时才有意义,指出本报文段中紧急数据的字节数。
- 选项:最大报文段长度MSS、窗口扩大、时间戳、选择确认等等。
3.tcp的3次握手 - 建立链接
刚开始客户端和服务器都是关闭状态。
-
第一次握手:
-
客户端:
发送连接请求报文,无应用层数据:
同步位SYN=1,表示这是一个连接请求报文。
数据序号seq=x, x表示发送的数据第一位序号,随机的,无意义。
客户端状态由 关闭(closed) 变成 syn已发送 (syn-sent)。 -
服务器:
服务状态由 关闭(closed) 变成 监听 (listen)。
-
-
第二次握手:
- 服务器:
服务器为该tcp连接分配缓存和变量。
服务器发送确认报文给客户端, 无应用层数据:
同步位SYN=1,表示这是一个连接接受报文。
ACK=1, 确认号有效。
ack=x+1, 表示服务器希望下次收到的字节序号第一位是 x+1。
数据序号seq=y, y表示发送的数据第一位序号,随机的,无意义。
服务状态由 监听 (listen) 变成 syn已经接受 (syn-rcvd)。
- 服务器:
-
第三次握手:
- 客户端:
客户端为该tcp连接分配缓存和变量。
客户端发送确认报文给服务端, 可携带数据:
同步位SYN=0。
ACK=1, 确认号有效。
ack=y+1, 表示客户端希望下次收到的字节序号第一位是 y+1。
数据序号seq=x+1, x+1表示发送的数据第一位序号,就是第二次握手时候服务器希望收到的数据。
- 客户端:
-
3次握手完成之后,客户端和服务器的状态都变成了 确认 (estab-lished), 连接已经建立,可以进行数据传输了。
-
3次握手可能存在的风险之一:SYN洪泛攻击。
- 一句话总结SYN洪泛攻击 :说一句话就不搭理你了。
- 具体过程:
攻击者发送第一次握手。
服务器进行第二次握手。
攻击者不进行第三次握手。
这样的话这个TCP连接就会被挂起,处于半连接状态。
攻击者进行大量的第一次握手,就会造成服务器有大量的TCP连接被挂起,消耗服务器的CPU和内存资源。 - 解决办法:
1.降低SYN timeout时间,使服务器尽快释放半连接状态的TCP。
2.使用SYN cookie:
第一次握手服务器不会为该报文段生成一个半开连接。
服务器使用客户端的ip和port生成一个TCP序列号,也就是 cookie. 发送给客户端
服务器通过客户端发过来的cookie进行校验该连接是否合法。
4.tcp的4次挥手 - 断开连接
- 第一次挥手:
- 客户端:
发送连接释放报文:
结束位FIN=1,表示这是一个连接释放报文。
数据序号seq=u, u是客户端已经传送数据的最后一位序号+1。
客户端状态由 确认 (estab-lished) 变成 等待结束-1 (FIN-wait-1)。
- 客户端:
- 第二次挥手:
- 服务端:
发送确认报文:
ACK=1, 确认号有效。
ack=u+1, 表示服务端希望下次收到的字节序号第一位是u+1。
数据序号seq=v, v表示服务端已经发送的数据的最后一位是 v-1。
服务端状态由 确认 (estab-lished) 变成 等待关闭 (close-wait)。
- 服务端:
- 第三次挥手:
- 服务端:
发送连接释放报文:
结束位FIN=1,表示这是一个连接释放报文。
ACK=1, 确认号有效。
ack=u+1, 表示服务端希望下次收到的字节序号第一位是u+1。
数据序号seq=w, w表示服务端第二次挥手之后发送的最后一个字节序号是 w-1。
服务端状态由 等待关闭 (close-wait) 变成 最后确认 (last-ack)。 - 客户端:
客户端状态由 等待结束-1 (FIN-wait-1) 变成 等待结束-2 (FIN-wait-2)。
- 服务端:
- 第四次挥手:
- 客户端:
发送确认报文:
ACK=1, 确认号有效。
ack=w+1, 表示客户端希望下次收到的字节序号第一位是W+1。
数据序号seq=u+1。
客户端状态由 等待结束-2 (FIN-wait-2) 变成 倒计时 (time-wait)。
客户端倒计时等待2MSL后,链接彻底关闭,状态由 倒计时 (time-wait) 变成 关闭 (closed)。
为什么要等待2MSL? 确认客户端的最后的ACK包成功到达。
因为在等待之前,客户端发了一个ACK,需要在这2MSL时间内看看服务端会不会让客户端重发,确认包到达了才能断开。 - 服务端:
服务端状态由 最后确认 (last-ack) 变成 关闭 (closed)。
- 客户端:
5.为啥是3次握手?
一句话总结:少于2次无法保证数据传输,多于3次没必要。
- 2次握手的话,发送方可以确定自己能发能收,但是接收方只知道自己可以接收,但不确定自己是否可以发送。
- 2次握手的话,如果网络延迟阻塞了,一个数据可能会发送多个请求,造成了多个tcp连接,浪费资源。
6.为啥是4次握手?
一句话总结:少于4次无法保证服务器数据完全发送完成,多于4次没必要。
因为:
客户端主动要求断开后,服务器先回复确认,
然后在所有数据发送完成之后,再发送FIN=1的报文段(第三次挥手)
最后才能关闭,保证数据传输完成。
7.tcp可靠传输
可靠传输:发送和收到的数据是一模一样的。
如何实现可靠传输?
1. 首部校验。
2. 序号确认机制:tcp数据都是有序号的,只有对端回复了确认收到的报文,发送方才会把数据从发送缓存中移除。
3. 超时重传:TCP采用动态改变重传时间RTTS,发送方在规定时间(RTTs)内没有收到确认报文,就重新发送。
4. 冗余ACK确认, 例如 :
发送方发送 1, 2, 3, 4, 5,这个5个报文段.
接收方收到1,返回冗余ACK为 “我已经收到了1”。这时候报文段 2 丢失了。
接收方收到3, 返回冗余ACK为 “我已经收到了1”。
发送方已经把3都发出去了,但是收到的消息任然是 “我已经收到了1”, 所以认为2已经丢失,就重传。
8.TCP流量控制
流量控制 : 你发慢点,我接收不过来了。
TCP利用滑动窗口机制实现流量控制:
1.接收方把自己的接收窗口大小-win的数量,放入tcp头部"窗口大小"字段中,传输给发送方。
2.发送方根据接收方的接收窗口大小,来调整发送的速度。
3.接收方系统会开辟一个缓冲区,用来记录哪些数据还没有处理应答,只有处理应答了才会从接口窗口(缓存)中删除。
9.TCP拥塞控制
拥塞控制 : 避免过多的数据进入网络。
流量控制只是控制一个设备的数据,拥塞控制是控制全局网络的数据。
拥塞控制的方法:
-
慢开始和拥塞避免
1.慢启动 : 经过一个RTT(请求往返时间), 运算窗口进行一次指数级增加。
2.如果窗口数量超过慢启动的上限值(16),窗口进行拥塞避免阶段,停止指数级增长,使用加法增长。
3.加法增长到了网络拥塞(24), 窗口直接变成1,重新一次慢启动。
4.但是这个时候慢启动的上限值只有上一次网络拥塞时的数量的一半。
问题 :遇到网络拥塞时候,直接把窗口干到1个,会导致传输速率大大降低,所以该算法优化后变成 - 快重传和快恢复 -
快重传和快恢复
1.刚开始的也是和之前一样的流程。
2.当收到3个重复的ACK,表示有包丢了,也就是遇到了网络拥塞,把窗口大小调整为一半。
3.然后重传ACK需要的包。
4.然后进入拥塞避免,窗口使用加法增长的阶段。
对称加密和非对称加密
参考 :https://juejin/post/7036551179517558791
1.对称加密 : 密钥密文一起发送
- 发送方使用 密钥Y 与 加/解密算法fn 对原始数据进行加密 得到 加密报文X。
- 发送方把 密钥Y 与 加密报文X 一起进行发送。(接收方需要知道密钥才能解密)。
- 接收方把 加密报文X 与 密钥Y 用 加/解密算法fn 进行解密,得到原始数据。
问题来了,由于加/解密算法fn是公开的,也就那么几种,所以黑客只需要把密钥Y 和加密报文X一起撸下来,就可以解密数据了啊,所以http是不安全的。
优点:高效,适用于大量数据的加密。
缺点:加解密算法公开,只要得到key,就可以解密数据,不安全。
2.非对称加密 :公钥加密,私钥解密
1.接收方生成一对匹配的 公钥 和 私钥。
2.私钥自己装好,公钥向外界公布。
3.发送方拿到接收方的公钥 ,使用接收方的公钥加密数据,接收方使用自己的私钥解密数据。
优点:安全性高。
缺点:加解密复杂,效率低。
3.非对称加密用于签名校验
问题,我拿到你给的一个数据,我怎么知道这个数据一定是你给的呢?
1.你把数据"hello" 用SHA256进行hash计算,得到明文的hash值。
2.然后使用私钥对 明文的hash值 进行加密, 得到hash值的密文(密钥签名)。
3.接着把数据"hello"和hash值的密文(密钥签名)一起发送给我。
4.我用你的公钥解密hash值的密文(密钥签名),得到 明文的hash值。
5.我再对数据"hello"用SHA256进行hash计算,得到明文的hash值。
6.最后我对两个明文的hash值进行比对,相同则说明是你发的数据,不同则不是你发的。
(因为hash值的密文(密钥签名)是用你的私钥进行加密的,所以如果用你的公钥能解密出来数据,则这个数据必然是你发的)
ps : 上图的密钥是指私钥
http和https
参考 :https://juejin/post/7036551179517558791
http:
-
http超文本传输协议,是一个请求与响应,无状态的应用层协议。
-
基于tcp/IP协议传输数据。
-
端口是80.
-
HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。
-
无链接:一次请求和响应之后断开连接,但如果头部信息设置 Connection : keep-alive,可以保持连接状态。
-
请求数据明文传输,保密性差。
-
请求报文:
- 起始行(start line):描述请求或响应的基本信息;
- 头部字段(header):使用 key-value 形式更详细地说明报文;
- 消息正文(entity):实际传输的数据,它不一定是纯文本,可以是图片、视频等二进制数据。
其中起始行和头部字段并成为 请求头 或者 响应头,统称为 Header;
消息正文也叫做实体,称为 body。
HTTP 协议规定每次发送的报文必须要有 Header,但是可以没有 body,也就是说头信息是必须的,实体信息可以没有。
-
响应报文:
-
版本信息:
版本 | 内容 | 现状 |
---|---|---|
http/0.9 | 不能进行数据包传输,只有get请求 | 没有使用 |
http/1.0 | 传输内容格式不限制,增加了post,put,delete等方法 | 开始使用 |
http/1.1 | 支持持久连接,host域,管道机制,分块传输 | 广泛使用 |
http/2 | 多路复用(一个请求可以有多个响应),头信息压缩,二进制协议等 | 广泛使用 |
https:
通过SSL或TLS提供加密处理数据,身份验证和数据完整性保护。
1.内容加密:采用混合加密技术,中间者无法直接查看明文内容.
2.验证身份:通过证书认证客户端访问的是自己的服务器.
3.保护数据完整性:防止传输的内容被中间人冒充或者篡改.
4.端口443.
问题1:
中间人攻击:黑客可以把服务器的公钥,改成自己的公钥发给客户端,那么截取客户端的数据,就可以用自己的私钥解密了。
解决办法:客户端通过证书认证机构验证服务器的公钥是否合法。
比如去学信网 (证书) 查一下你的学历 (公钥) 是否合法。
认证机构是大家都相信的,全世界就那么几个, 但有分公司。
问题2 :
对数据进行非对称加密,效率太低。
解决办法:
1.客户端生成自己的对称加密密钥key : 会话密钥
2.对数据进行对称加密。
3.对会话密钥使用非对称加密,即使用服务器的公钥加密, 得到加密后的会话密钥。
4.然后把 加密后的会话密钥 和 对称加密后的数据 一起发给服务器。
5.服务端使用私钥解密加密后的会话密钥 得到解密数据的会话密钥。
6.服务端使用会话密钥 解密数据。
5.一次https链接结束后,客户端清除会话密钥,下次又重新创建。
GET和POST的区别
GET :
1. 请求的数据会附在 URL 之后(放在请求行中),以 ? 分割 URL 和传输数据,多个参数用 & 连接。
2. 用于信息获取。
3. 请求行是这样:GET /search/users?q=xxxxx HTTP/1.1。
4. 会被浏览器主动缓存的,如果下一次传输的数据相同,那么就会返回缓存中的内容,以求更快地展示数据。
5. URL 一般都具有长度限制(http协议不限制,浏览器和具体的服务器做限制,不同的浏览器和不同的服务器有所不同)。
6. 只产生一个 TCP 数据包,把请求头和请求数据一并发送出去,服务器响应 200 ok(返回数据)。
POST :
1. 用于给服务器提交数据。
2. 请求行是:POST / HTTP/1.1, 可以没有URL。
3. 请求数据是放在请求体body中,请求数据没有长度限制。
4. POST 方法会产生两个 TCP 数据包,浏览器会先将请求头发送给服务器,待服务器响应100 continue,浏览器再发送请求数据,服务器响应200 ok(返回数据)。这么看起来 GET 请求的传输会比 POST 快上一些(因为GET 方法只发送一个 TCP 数据包),但是实际上在网络良好的情况下它们的传输速度基本相同。
注意:
1.get和post的本质是一样的,都是基于TCP/IP协议的http请求。
2.在技术上完全可以给 POST 加上URL参数,给 GET 加上请求数据,但是强烈不建议这么搞。
3.为什么要区分:1.语意化,2.方便管理。
网络转发和网络代理
- 网络转发 : 客户端直接请求目标服务器,中间路由器对报文进行转发。
- 网络代理 : 本身就是一个服务,客户端请求代理服务器,代理服务器再去请求真正的服务器,收到数据之后回复给客户端。
1.正向代理:一种客户端的代理技术,帮助客户端访问无法访问的服务器资源,可以隐藏用户真实IP,比如 VPN。
- 接收客户端请求
- 根据请求数据做一些配置
- 复制请求到发送到真正的服务器
- 接收服务器返回数据
- 对返回数据做一些处理,返回客户端
2.反向代理:一种服务器的代理技术,帮助服务器做负载均衡,缓存,安全校验等,可以隐藏服务器真实IP,比如 nginx。 - 接收客户端请求,根据需求修改请求结构信息。
- 通过负载均衡算法把请求发到对应的服务。
- 得到数据,处理数据,返回数据给客户端。
CORS跨域
啥是跨域?
跨域是由于浏览器和服务器之间同源策略, 也就是 协议,域名,端口号不对应产生的。
比如 浏览器是 http://111.22.33:8080, 服务器是 http://111.22.33.9090,这时候就会产生跨域问题,服务器收到请求也返回了,但是浏览器拿到数据之后,看了http请求头中的相关信息,就知道端口不一致,就报错不显示数据了。
怎么解决?
- 服务器中间件里面,这是http请求头,解决跨域. (常用的方案)
- 反向代理服务器设置 (例如: nginx),把port改成和浏览器一样
本文标签: 计算机网络
版权声明:本文标题:“计算机网络“ 那些事 内容由热心网友自发贡献,该文观点仅代表作者本人, 转载请联系作者并注明出处:https://www.elefans.com/xitong/1727200038a1102024.html, 本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容,一经查实,本站将立刻删除。
发表评论