计算机网络——应用层2(知识点补充 open

HTTP和HTTPS的区别与HTTPS的三次握手

  1. 超文本传输协议HTTP协议 被用于在 Web 浏览器和网站服务器之间传递信息,HTTP协议以明文方式发送内容,不提供任何方式的数据加密,如果攻击者截取了 Web 浏览器和网站服务器之间的传输保温,就可以直接读懂其中的信息,因此,HTTP协议不适合传输一些敏感的信息,如:支付密码等

  2. 为了解决HTTP协议明文传输不安全的缺点,提出了HTTPS协议,HTTPS在HTTP的基础上加入了SSL协议,SSL依靠证书来验证服务器的身份,并为浏览器和服务器之间的通信加密

  3. HTTPS的三次握手其实就是使用三次TCP握手确立一个HTTP连接
    在这里插入图片描述
    客户端发出请求----->服务端返回证书(证书中包含公钥,还有一个私钥服务器自己留下了,这个证书的公钥私钥是一对)----->客户端解析证书、生成一个随机值(密钥)、用公钥对密钥加密、传送加密的密钥信息----->服务器用私钥解密,知道了密钥、用这个密钥加密在双方通信上----->客户端收到加密信息,通过仅双方知道的密钥解密信息
    ★★在服务端用私钥解开密钥之后,服务端就把内容通过这个密钥进行了对称加密,就是将内容与某种算法混合在一起

  4. 区别:
    1)https协议需要用到证书
    2)http是明文传输,https是具有安全性的ssl加密
    3)http直接与TCP进行数据传输,而https是经过一层SSL(OSI表示层)
    4)http用80端口;https用443
    ★★★注意:https加密是在传输层,是报文被包装成tcp报文的时候完成加密过程的,无论是beader域还是body域都被加密

  5. 另,HTTPS一般使用的加密算法与HASH算法:

  • 非对称算法:RSA、DSA/DSS
  • 对称加密算法:AES, RC4, 3DES
  • HASH算法:MD5, SHA1, SHA256

此内容参考并感谢https://www.cnblogs.com/wqhwe/p/5407468.html


Cookie和Session的区别

看例子:参考并感谢https://blog.csdn.net/xiaojie_570/article/details/87467141

举例一: 发送顾客一张卡片,上面记录着消费的数量,一般还有一个有效期限。每次消费时,若顾客出示这张卡片,则此次消费就会与以前或者以后相连接起来。这种做法就是在客户端保持状态。

举例二:发给顾客一张会员卡。除了卡号之外什么信息都没有记录。每次消费时,若顾客出示该卡片,则店员在店里的记录本上找到这个卡号对应的记录添加一些消费信息。这种做法就是在服务端保持状态。

由于HTTP协议是无状态的,而处于种种考虑也不希望使之成为有状态的。因此,后面两种方案就成为现实的选择。具体来说:

  • Cookie机制采用的是客户端保持状态的方案;
  • Session机制采用的是在服务端保持状态的方案。

同时,我们也看到,由于采用服务端保持状态的方案在客户端也需要保存一个标识,所以session机制可能需要借助 cookie机制来达到保存标识的目的。

Cookie

当你在浏览网站的时候,WEB服务器会先送一个小资料放在你的计算机上,Cookie 会帮你在网站上所打的文字或是一些信息都记录下来,当你下次再访问同一个网站的时候,WEB服务器会先看看有没有它上次留下来的cookie资料,如果有的话,就依据之前的cookie来给你提供网页。

Cookie的内容主要包括:名字、值、过期时间、路径和域。路径和域一起构成了cookie的作用范围。若不设置过期时间,则表示这个cookie的生命期为浏览器的会话期间,关闭浏览器,cookie就会消失。这种生命期为浏览器会话的cookie被称为会话cookie。

会话cookie一般不存储在硬盘上而是保存在内存里,当然这种行为并不是规范规定的。**如果设置了过期时间,浏览器就会把 cookie保存到硬盘上,关闭之后再次打开浏览器,这些cookie仍然有效直到超过设定的过期时间。**存储在硬盘上的cookie可以在不同的浏览器进程之间共享,比如两个IE窗口。而对于保存在内存中的cookie,不同的浏览器有不同的处理方式。


GET、POST区别

  1. 【注意】HTTP没有要求,如果Method 是POST,数据就要放在BODY中。也没有要求 Method 是GET,数据就一定放在 URL 中而不能放在 BODY中。

GET 和 POST 是HTTP 协议中的两种发送请求的方法。 HTTP是什么呢? HTTP 是基于 TCP/IP 的关于数据如何在万维网上通信的协议。HTTP 底层是 TCP/IP,所以 GET 和 POST 的底层也是 TCP/IP

  1. 先看看这道题表面上的“标准答案”,在这里插入图片描述
  2. 来,看看本质区别:首先再提醒,HTTP底层是TCP/IP,所以GET和POST底层也是TCP/IP,也就是说他俩都是TCP链接,GET和POST能做的事情是一样的,回到开头说的要给GET加上request body,给POST带上url参数,技术上完全行得通

一个例子说明问题:
在我大万维网世界中,TCP就像汽车,我们用TCP来运输数据,它很可靠,从来不会发生丢件少件的现象。但是如果路上跑的全是看起来一模一样的汽车,那这个世界看起来是一团混乱,送急件的汽车可能被前面满载货物的汽车拦堵在路上,整个交通系统一定会瘫痪。为了避免这种情况发生,交通规则HTTP诞生了。HTTP给汽车运输设定了好几个服务类别,有GET, POST, PUT, DELETE等等,HTTP规定,当执行GET请求的时候,要给汽车贴上GET的标签(设置method为GET),而且要求把传送的数据放在车顶上(url中)以方便记录。如果是POST请求,就要在车上贴上POST的标签,并把货物放在车厢(body)里。当然,你也可以在GET的时候往车厢内偷偷藏点货物,但是这是很不光彩也可以在POST的时候在车顶上也放一些数据,让人觉得傻乎乎的。HTTP只是个行为准则,而TCP才是GET和POST怎么实现的基本。

  1. 例子就解决了HTTP对GET和POST参数的传送渠道的问题,那么关于“标准答案”中关于参数大小的限制又是怎么回事呢?

还是例子:
在我大万维网世界中,还有另一个重要的角色:运输公司。不同的浏览器(发起http请求)和服务器(接受http请求)就是不同的运输公司。 虽然理论上,你可以在车顶上无限的堆货物(url中无限加参数)。但是运输公司可不傻,装货和卸货也是有很大成本的,他们会限制单次运输量来控制风险,数据量太大对浏览器和服务器都是很大负担。业界不成文的规定是,(大多数)浏览器通常都会限制url长度在2K个字节,而(大多数)服务器最多处理64K大小的url。超过的部分,恕不处理。如果你用GET服务,在request body偷偷藏了数据,不同服务器的处理方式也是不同的,有些服务器会帮你卸货,读出数据,有些服务器直接忽略,所以,虽然GET可以带request body,也不能保证一定能被接收到哦。

以上我们就可以知道GET和POST本质上就是TCP链接,并无差别,知识由于HTTP的规定和浏览器/服务器的限制,导致它们再应用过程中体现出一些不同

  1. GET和POST还有一个重大区别:GET产生一个TCP数据包,POST产生两个TCP数据包,具体来说:
  • 对于GET方式的请求,浏览器会把http header和data一并发送出去,服务器响应200(返回数据);

  • 而对于POST,浏览器先发送header,服务器响应100 continue,浏览器再发送data,服务器响应200 ok(返回数据)。

也就是说,GET只需要汽车跑一趟就把货送到了,而POST得跑两趟,第一趟,先去和服务器打个招呼“嗨,我等下要送一批货来,你们打开门迎接我”,然后再回头把货送过去。
因为POST需要两步,时间上消耗的要多一点,看起来GET比POST更有效。因此Yahoo团队有推荐用GET替换POST来优化网站性能。但这是一个坑!跳入需谨慎。为什么?

  1. GET与POST都有自己的语义,不能随便混用。
  2. 据研究,在网络环境好的情况下,发一次包的时间和发两次包的时间差别基本可以无视。而在网络环境差的情况下,两次包的TCP在验证数据包完整性上,有非常大的优点。
  3. 并不是所有浏览器都会在POST中发送两次包,Firefox就只发送一次。

★★★区别
【区别一】

GET 参数是通过 URL 传递
POST 放在 request body中

【区别二】

参数的大小

【区别三】

GET 产生一个 TCP 数据包;POST 产生两个 TCP 数据包。

【区别四】

get 比post 更不安全,因为参数直接暴露在 URL 中,所以不能用来传递敏感信息
get 请求会被完整的保存在浏览历史记录中,post 中的参数不会被保留。

参考并感谢https://www.cnblogs.com/logsharing/p/8448446.html


URL、URI区别

一、URL 和 URI 的区别

URL:(Uniform/Universal Resource Locator的缩写,统一资源定位符)
URI:(Uniform Resource Identifier 的缩写,统一资源标识符)

主要的区别:

URI 标识请求服务器的路径
URL说明要如何访问这个资源(是 HTTP 方式还是 HTTPS 方式或者是 ftp等方式)

二、URL 的标准格式

URL 格式由4部分组成:
在这里插入图片描述

感谢 https://blog.csdn.net/xiaojie_570/article/details/87626189

HTTP2.0、HTTP1.1、HTTP1.0区别

感谢并参考
https://www.cnblogs.com/smlp/p/9779206.html
https://blog.csdn.net/xiaojie_570/article/details/87468277

一、 HTTP1.0 与 HTTP1.1的区别

  1. 长连接(就是上文的持续链接)

HTTP1.0 需要使用keep-alive参数来告知服务器端要建立一个长连接,而HTTP1.1默认开启keep-alive, 支持长连接;HTTP是基于TCP/IP协议的,创建一个TCP链接是需要经过三次握手的,有一定的开销,如果每次通讯都要重新建立连接的话,对性能有影响,长连接在一定程度上弥补了HTTP1.0每次请求都需要创建连接的缺点

2.HOST头处理
在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址,因此,请求消息中的URL并没有传递主机名hostname,但是随着虚拟主机技术的发展,在一台物理服务器上可以存在多个虚拟机,并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都支持HOST头处理,且请求消息如果灭有HOST头,会报错404

  1. 带宽优化
    3.1. HTTP1.1支持只发送header信息(不包含任何的body信息),如果服务器认为客户端有权限请求服务器,则返回100,否则返回401。 只有当客户端接收到400,才开始把body发送到服务器(就是post的两次TCP数据包?)
    3.2. 在HTTP1.0中,存在浪费带宽的现象,例如客户端已经有了一部分资源,应该只需要另外一部分资源就可,但是1.0中服务器会将整个对象送过来,且不支持断点续传的功能,这就造成浪费;1.1在请求头中引入了range头域,它允许只之请求资源的某个部分,即返回码是206(Partial Content),这样就方便了开发者自由选择以便充分利用带宽和连接

  2. 缓存
    在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准,HTTP1.1则引入了更多的缓存控制策略例如Entity tag,If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。

二、 HTTP1.1 与 HTTP2.0 的区别

  • ★★ 先简单介绍一下超文本传输协议第二版HTTP2.0
    采用二进制格式而非文本格式;
    是完全的多路复用,非有序并阻塞的——只需要一个连接即可实现并行
    使用报头压缩,降低了开销
    让服务器可以将响应**主动“推送”**到客户端缓存中
    -★★ 具体讲讲主要区别:
  1. 多路复用
    2.0使用多路复用技术,做到同一个连接并发处理多个请求,而且并发请求的数量比1.1大了好几个数量级;
    当然1.1也可以多创建几个TCP连接来处理更多并发的请求,但是创建TCP连接本身也是有开销的:
    TCP连接有一个预热和保护的过程,先检查数据是否传送成功,一旦成功才慢慢加大传送速度。因此对应瞬时并发的连接,服务器的响应就会变慢,所以最好能使用一个建立好的连接,并且这个连接可以支持瞬时并发的请求。

  2. 数据压缩
    HTTP1.1不支持header数据的压缩,HTTP2.0使用HPACK算法对header的数据进行压缩,这样数据体积小了,在网络上传输就会更快。

  3. 服务器推送
    2.0的web server请求数据时,服务器会顺便把一些客户端需要的资源一起推送到客户端,免得客户端再次创建连接来发送请求到服务器端获取。这种方式非常适合加载静态资源。
    服务器推送过来的资源,会统一放在一个网络与http缓存之间的地方,可以理解为本地。当客户端把index.html解析完之后,会向本地请求这个资源,由于资源一斤本地化,所以这个请求的速度非常快,这也是服务端推送性能优势的体现之一在这里插入图片描述

  • ★★讲讲一些原因
  1. 2.0为什么是二进制
    因为比起文本协议,二进制协议解析起来更加高效,错误也更少

  2. 消息头为什么需要压缩
    假定一个页面有80个资源需要加载(这个数量对于今天的web而言还是挺保守的),而每次请求都有1400字节的消息头,至少需要7 到8 个来回去“在线”获得这些消息头,这还不包括响应时间,这只是从客户端获取所花费的时间而已。
    那由于TCP的慢启动机制,它会基于已知有多少个包,来确定来要回去获取哪些包,这很明显的会限制最初几个来回可以发送的数据包的数量;
    相比之下,头部轻微压缩就可以让那些请求秩序一个来回就能搞定,有时候甚至一个包就可以搞定了。

  3. 多路传输/多路复用
    1.×有一个问题叫线段阻塞head-of-life blocking,指一个连接一次只能提交一个请求,请求多了就会变慢。1.1试过流水线来解决问题(上一篇提过,忘了就立刻马上去看),但是效果不理想,因为数据量较大或者速度较慢就会阻塞后面的请求),此外,由于网络媒介和服务器不能很好地支持流水线就会导致部署比较困难
    2.多路复用(multiplexing)能很好解决上面地问题,因为它能同时处理多个消息地请求和响应,甚至可以在传输过程中将一个消息跟另外一个掺杂在一起,所以客户端只需要一个连接就可以加载一个页面

  4. 服务器推送的好处
    浏览器请求一个网页时,服务器将会发回HTML,★★在服务器开始发送JsvaScript,图片和CSS前,服务器需要等待浏览器解析HTML和所有发送内嵌资源的请求★★,服务器推送服务通过“推送”那些它认为客户端将会需要的内容到客户端的缓存中,以此来避免往返的延迟


本以为应用层就是三下五除二但我仿佛从来没有学过应用层……明天上午把版本不同看了,整理好,明天下午就可以开始新的学习了,嗯……这边的话也要常常复习才行,操作系统的实验也还没有做……おやすみ、まだあした、頑張って

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值