服务器可以卸货吗安全吗 服务器可以装软件吗

详解Http

(1)HyperText Transfer Protocol 超文本传输协议

为南溪等地区用户提供了全套网页设计制作服务，及南溪网站建设行业解决方案。主营业务为做网站、网站设计、南溪网站设计，以传统方式定制建设网站，并提供域名空间备案等一条龙服务，秉承以专业、用心的态度为用户提供真诚的服务。我们深信只要达到每一位用户的要求，就会得到认可，从而选择与我们长期合作。这样，我们也可以走得更远！

(2)解释

协议:"协"代表两个人以上,"议"代表一种规范,约束

传输:把A搬到B点,双向协议,我们访问报读的流程:

我们是请求方A,百度就是应答方B,双方约定用HTTP协议传输,brower把请求数据发送给网站,网站在把一些数据返回给浏览器,浏览器在渲染到屏幕,我们就看到图片了

超文本:超越了普通文本的文本呗! 早期的字符 = 图片,视频,压缩包等

1xx:提示信息,说明到现在为止正常,还可以进行后续的请求

2xx:成功状态码,报文收到并正确处理

3xx:重定向

4xx:客户端错误

--400:请求报文有误

--401:请求访问需要有认证信息

--403:服务器禁止访问资源

--404:Not Found,请求的资源在服务器未找到

5xx:服务端错误

(1)Host:域名,可以请求同一台主机的不同域名网站

(2)Connection:Keep-Alive

--:Http/1.1默认采用的是TCP持久连接,可以进行复用

--:为了兼容老版本,需要加上Keep-Alive

(3)Content-Length:服务器响应client时,表明本次的数据长度

(4)Content-type: text/html 返回的数据格式, 客户端也可以用Accept设置接收的类型

(5)Content-Encoding: gzip 返回类型使用什么压缩,客户端也可以用Accept-Encoding设置接收哪些压缩方法

GET:从服务器获取资源(文本,图片,视频等...)

POST:向URI指定的资源提交数据,把我们的[留言文本消息]放入请求体body,再拼接好POST请求头,通过TCP协议发送给服务器

(1)幂等性:多次执行多次操作,那么结果都是[相同]的

(2)GET是安全且幂等:它只是[可读]操作,无论执行多少次,服务器的数据都是安全的,每次的结果都是相同的

(3)POST是不安全且不幂等:新增数据会修改服务器资源,所以是不安全,多次提交会创建多个资源,所以不是幂等的

1.Http协议底层是TCP/IP,所以GET和POST的底层也是TCP/IP,也就时说Get/Post都是TCP连接

2.Get和Post做的事情是一样的,如果给Get加上Request Body,给Post带上url参数,技术上是完全行得通的

3.举个栗子

1.C/S ==== 2K/64K

业界不成文规定:浏览器(大多数)都会限制url的长度在2k个字节,而服务器(大多数)最多处理64k个字节大小的url,超过的部分不处理

2.用Get请求方式,私藏数据在Request Body

(1)有的服务器会绑定卸货,读取数据,有的直接忽略

(2)虽然Get请求方式可以把数据放在Request Body,但是却不能保证一定会被服务器接收

(1)简单:报文格式 == head + body 头部信息也是key-value的形式

(2)灵活易于扩展:

--:状态码和请求头字段都可以由开发人员自定义

--:由于http在应用层(最顶层),那么下层可以随意变化

例子:HTTPS其实就是在应用层和TCP加了一个SSL/TLS的协议

(3)跨平台,应用广泛:从台式机的浏览器到手机的各种APP,都是HTTP的应用,遍地开花

(1)无状态:

描述:好处是服务器不需要额外资源记录这些客户端状态,减轻负担,但是我们登录 == 添加到购物车 == 下单 == 结算这种连贯的操作需要每次都验证一次身份,那很麻烦

解决:使用cookie在请求和响应报文记录客户端的状态

[第一次访问server,server会发放"门牌卡"给client,下次请求,client只要带上这个卡,服务器就认识你了]

(2)url地址的明文传输,不安全

描述:url地址的明文传输,不安全

解决:使用Http + SSL/TLS

(1)早期HTTP/1.0的性能问题

--描述:每发起一个请求,都要新建一个TCP连接(三次握手),而且是串行执行,增加了开销

--解决:HTTP/1.1采用了长连接,减少了连接重复的新建和断开,减轻了服务器的负担

(2)管道网络通讯

--优化串行请求:Http/1.1的长连接是基于"管道"通讯,在同一个TCP连接可以发起多个请求,之前的TCP连接时A请求后等待服务器返回,再发送B请求

--产生问题:但是服务器并不是并发处理请求,而是按照排队顺序执行,也叫做[队头堵塞],相当于高速路上堵车了

(1)安全:HTTP是明文传输,存在安全风险问题,HTTPS在TCP三次握手之后还需要进行SSL/TLS的握手过程,在进行加密报文传输

(2)端口:HTTP的端口是80, HTTPS的端口是443

(3)CA证书:HTTPS协议需要向CA机构申请数字证书,来保证服务器是可信的

(1)优化

--长连接:TCP长连接改善了HTTP/1.0短连接不断创建,断开连接造成的性能开销

--pipeline:支持管道pipeline网络传输,只要第一个请求出去了,不必等它回来就可以请求第二个,减少了整体的响应时间

(2)缺点

--头部:请求头部Header未压缩发送,而且每次都需要发送相同的头部造成浪费多

--队头阻塞:server按照请求顺序来响应,若服务器慢,导致client一直请求不到数据

--没有优先级控制

(1)HTTPS安全:HTTP/2.0是基于HTTPS的,安全性提高

(2)HPACK算法-头部压缩:若你同时发送多个请求,他们的头是一样的,那么协议会帮你消除重复部分

HPACK算法:client和server共同维护一张消息表,所有字段会存入这个表并生成一个索引号,发送只需要传索引号即可

(3)二进制的数据帧:HTTP/1.1是(报文首部+空行+报文主体),HTTP/2换成(头信息帧+数据帧),好处是接收报文后无需将明文报文转成二进制,对计算机来说可以提高传输效率

(4)数据流:

--非顺序:连接中连续数据包不是按照顺序发送,可能属于不同响应,

--流编号:每个请求对应一个数据流(有独立编号),客户端为奇数编号,服务端为偶数编号,客户端可以指定数据流的优先级

(5)多路复用:

--并发处理请求:移除了HTTP/1.1的串性请求,可以并发的回应多个请求,解决了[队头阻塞]问题

--例子:在TCP连接中,server收到A(耗时长),B请求,于是server先回应A已处理部分,在回应B,继续回应A的剩余部分

(6)服务器推送 server push,Cache push

--:Http/2改善了传统的[请求-应答]工作模式,服务器可主动向client发送消息

--:当brower请求HTML时,会提前把js,css静态资源主动发给client,减低延时

问题:

(1)HTTP/1.1丢包情况:在pipeline传输中有一个请求阻塞了,那么在队列后请求会统统被阻塞住了

(2)HTTP/2丢包情况: 多路复用一个TCP连接,一旦发生丢包,所有的请求都会阻塞住

解决:

(1)HTTP/3将HTTP下层的TCP协议改成了UDP,UDP是不管顺序和有无丢包的,所以不会出现HTTP/1.1的[队头阻塞]和HTTP/2的丢包重传问题

(2)UDP是不可靠连接,但基于 UDP 的 QUIC 协议 可以实现类似 TCP 的可靠性传输。

服务器的安全包括哪些方面?

服务器安全包括如下几个方面：

1、物理安全：服务器的硬盘，电源，主板，赖以维持服务器正常工作的硬件，都是需要进行定期维护确保安全的，只有保证这些硬件的绝对安全才能保证我们的服务器能正常运行。

2、软件安全：软件安全包括系统安全，服务安全，漏洞安全，密码安全，网络安全

①、系统安全：系统本身是有很多一般都是比较安全的只要我们打好足够的补丁，但是系统文件我们创建好的网站目录权限，系统盘的关键位置例如temp的位置的权限设置。

②、服务安全：注册表和服务项一定要仔细进行检查严禁远程修改。

③、密码安全：对于弱密码要立即进行修改，密码强度要有数字加英文以及特殊符号进行整改

④、网络安全：防cc，抗doss是我们服务器安全很常见的问题了。也是防止木马病毒的入侵的必要的手段。

⑤、资源安全：进行资源监控保证资源不被篡改入侵是针对服务器一项很重要的安全措施能够及时帮助我们找出被篡改的资源，以及进行告警来帮助我们更好的管理服务器安全。

液晶显示器邮寄可不可靠？

不怎么安全，如果想邮寄，你就得考虑液晶显示器在运输过程中，如果损坏了，该怎么办。我前天收到显示器的时候，已经被压坏了，而想找邮政索赔很难。所以建议你如果要邮寄，一定不要选中国邮政。