网站地图文件,网站建设系统分析,如何注册公司营业执照,开发一个简单的app需要多少钱在之前的网络基础博客中#xff0c;我们对网络的基本概念进行了一个简单的介绍#xff0c;那么接下来的网络内容中#xff0c;我们将对网络通信中的典型协议进行详细解释。
我们根据网络协议中的分层来对典型协议进行注意介绍#xff0c;不过对于物理层的传输我们不做考究…在之前的网络基础博客中我们对网络的基本概念进行了一个简单的介绍那么接下来的网络内容中我们将对网络通信中的典型协议进行详细解释。
我们根据网络协议中的分层来对典型协议进行注意介绍不过对于物理层的传输我们不做考究我们只从软件层面入手。接下来我们从应用层出发讲述它的典型协议。
目录
1.应用层传输
1.1自定制协议
1.2HTTP协议
1.2.1内容
1.2.2特性
1.2.3格式
1.2.4Cookie
1.3HTTPS协议
1.应用层传输
应用层是负责应用程序之间的数据沟通是一种面向程序员的协议。因为应用程序都是由程序员设计所以它们之间的数据沟通也由程序员来设计完成。而其中一些协议的设计在针对某些场景时有很好的使用效果并且使用人数较多。我们把这种协议称为知名协议。
1.1自定制协议
自定制协议时程序员自己定义的程序沟通数据格式约定在我们设计自定制协议时肯定需要就某些要素进行考虑使得通向传输更加稳定便捷和快速。
不过在了解这些要素之前我们需要明白数据的序列化和反序列化的大致内容。对于序列化指的是在网络传输或数据的持久化存储中将多个数据对象按照指定格式组织成为一个二进程文件进行传输或持久化存储的一个过程对于反序列化指的是对二进程数据进行指定格式的解析得到各个数据对象内容的一个过程。
那么对于我们设计自定制协议需要考虑的要素内容便是
传输性能定制一个协议传输的数据需要尽可能小不影响表达助于提高传输速度解析性能传输和接收多个数据对象的时进行序列化和反序列化需要尽可能简单快捷调试便捷性对于不同的程序员而言拥有较好的可见性和可识别性。
在大致了解完毕自定制协议的内容之后我们来讲述一些知名协议的内容。
1.2HTTP协议
1.2.1内容
HTTP协议是一种超文本传输协议是现在互联网公司中使用最多的协议它早期是用来传输web网页所设计的协议。
1.2.2特性
HTTP存在三点特性即
基于字符串明文传输调试便捷性高是一种简单的请求--响应协议早期是短链接--一次请求响应结束后便关闭基于TCP协议传输安全可靠。
1.2.3格式
HTTP的请求格式请求报文分为四部分分别是请求行首行、请求头部、空行和正文。 笔者引用《图解HTTP协议》书中的图示说明其中请求方法、URLURI和协议版本构成的第一行内容是请求行首行接下来是请求头部请求首部字段然后空白部分是空行用于分隔正文最后剩下的内容便是正文内容实体。
对请求报文中内容进行逐一大致描述便是请求行用于标识请求中的关键性描述信息请求头部由多个键值对构成用于对请求进行附加描述和对正文作以形容空行用于分隔头部和正文正文则是提交给服务器的数据内容。
解析来我们对请求报文的内容进行逐一细致解析先对请求行中的内容进行仔细说明首先是请求行中的请求方法
HTTP1.1中的请求方法 GET获取资源用来请求访问已被URI识别的资源POST传输实体的主体GET也能进行传输但POST并不会获取响应的主体内容PUT传输文件要求在请求报文中包含文件内容然后保存在URI指定位置HEAD获得报文首部同GET方法但不返回报文主体DELETE删除文件是和PUT方法相反的方法OPTIONS询问支持的方法用于查询针对请求URI指定的资源支持的方法TRACE追踪路径让Web服务器端将之前的请求通信返回给客户端CONNECT要求用隧道协议连接代理用于和代理服务器实现用隧道协议进行TCP通信
其中最常使用的三种请求方法是GET、POST和HEAD还需注意GET和HEAD请求方法的区别。此外附上HTTP1.0和HTTP1.1支持方法的差异
然后是URLURIURL是统一资源定位符是一个具体的网站定位信息网址我们可以直接通过URL连接来访问到具体的连接而这部分内容也可以是URIURI也是用于定位互联网上的信息和URL不同的是URI是一种标识是一个相对的路径连接。https是对http协议的加密
除此之外如果不是访问特定资源而是对服务器本身发起请求时我们可以使用一个 * 来代替请求URLURI。附上URL构成说明图片同样出自于《图解HTTP》一书 最后是协议版本它所描述的是当前HTTP协议所使用的版本不同的版本在功能支持力度上存在一些差距。具体的迭代过程我们不做细究有兴趣的伙伴可以阅读《图解HTTP》一书。
之后我们对请求头部内容进行解析其中由一个个键值对构成这是针对请求的一些附加描述以及对请求正文的描述。需要注意的关键信息有User-AgrantHostReferer……这些关键字来描述请求还有Content-Length和Content-Type者两者分别描述正文长度和正文数据类型决定对方如何解析数据。
接下来是空行/r/n的解析空行主要的作用也是前文我们所提到的用于间隔HTTP头部和正文。实际上主要是用于实现HTTP解析时先接收一个完整的HTTP头部根据其中的Content-Length确定正文长度然后根据长度取出指定大小的正文则刚好能够获取一个完整的HTTP请求。
最后是正文正文即是客户端提交给服务端的数据其中的数据格式通过Content-Type来进行描述。
了解完HTTP请求格式请求报文后我们来大概了解一些HTTP响应格式响应报文 首先是对于响应报文中的响应行首行中的内容其中包括协议版本、状态码和状态码描述。对于协议版本我们不做细究然后是状态码状态码主要用于明确告知客户端本次请求的处理结果不同的状态码便代表不同的请求结果最后是状态码的描述状态码没有什么具体的功能意义主要作用于告知程序员状态码的描述信息文字。
其次是对响应头部中的内容需要注意的是Location关键字其用来描述重定向告知客户端上一次服务端所响应的连接以及Connection关键字用来描述当前所使用连接时短链接还是长连接。
然后是空行的作用同请求报文。最后正文即是响应给客户端的数据。
1.2.4Cookie
了解cookie之前我们对HTTP的发展历程进行简单说明也是为了回答我们在HTTP中为什么需要cookie。
在HTTP的初始版本中每进行一次的HTTP通信就要断开一次TCP连接这种连接方式也叫做短链接。这是因为在当时的通信情况中数据都是一些容量很小的文本传输所以即使每次连接都断开也不会产生问题。
但随着HTTP的普及文本中包含大量图片的情况就多了起来。此时短链接的方式在每次通信中会增加请求HTML页面的其他资源扩大了通信量的开销。所以在HTTP1.1的一部分的HTTP1.0中提出了持久连接长连接。
这样的连接方式也叫做HTTP keep-aliveHTTP connection reuse方法。如此在客户端和服务端通信中只要其中任一端没有明确提出断开连接之前则会一直保持TCP连接。在HTTP1.1中所有的连接默认都是持久连接但在HTTP1.0中并未对其进行标准化。
持久化连接使得多数请求以管线化方式发送数据成为可能在此之前发送请求后需要等待响应请求之后才可以发送下一个请求。这样一问一答的方式并不利于效率的提高。所以管线化技术实现后我们不用等待也可以直接发送下一个请求。如此便可以做到通信并发多个请求而不需要一个接一个的等待响应。
但仅对连接的优化使得通信效率提高并不能满足我们对通信的期待因为HTTP是无状态协议它并不会对之前发生的请求和响应状态进行存储和管理这意味着我们无法根据之前的请求来对本次请求进行处理我们无法将上下的响应内容相互联系。
当我们访问需要登录的Web页面时由于它本身并不对登录状态进行管理记录已登录的状态。所以在每次跳转和刷新页面的时候我们都需要重新在请求报文中添加登录信息。
从一方面来说身为无状态协议的HTTP协议由于不需要保存状态的原因可以很有效的减少CPU及内存资源的消耗但从另一方面来说不保存状态并不列于我们对于一些场景的使用。
于是我们引入了Cookie技术信息缓存机制通过在请求报文和响应报文中写入Cookie信息来控制客户端的状态。Cookie根据响应报文中Set-Cookie的首部字段信息来通知客户端保存Cookie当下一次客户端继续向服务端发送请求时客户端会自动在请求报文中加入Cookie值再发送。
服务端会检查客户端发送过来的Cookie通过其中内容识别出是那一个客户端发送的连接请求然后对比服务器上的记录最终得到之前的状态信息。
Cookie技术很好的解决的我们在多次通信中不断维护客户端的状态但是这并不安全当我们的通信被劫持之后其中的敏感信息很容易被获取。所以我们并不能将敏感信息直接以Cookie的方式进行传输。
我们引入session会话机制在客户端和服务端之间的通信建立一个会话将会话的重要内容保存起来会话内容将保存在服务器之中接下来我们只需要通过Cookie传输session_id即可访问对应信息。如此便很好的避免了敏感信息的传输提高了传输的安全性。
不过尽管如此仍存在一些安全隐患Cookie篡改于是引入token来解决。
1.3HTTPS协议
在了解HTTP协议之后我们可以来讲述以下HTTPS协议。通俗而言HTTPS协议实际上就是加密之后的HTTP协议。
因为HTTP协议在传输过程中容易被劫持所以我们引入HTTPS协议对其进行加密对于加密我们采取两种方式身份加密和加密传输。
身份加密我们采用CA认证即电子认证服务。是通信双方到第三方权威机构办理一份CA证书当后面连接建立后会将证书先发送给对方对方对证书解析成功之后双方才会进行正常的通信。
传输加密是对通信双方传输的数据进行加密。对于不同的加密方式我们存在不同的加密算法通向双方需要对密钥算法进行协商确定加密和解密的密钥。
我们将数据加密和解密使用相同密钥的传输加密称作对称加密将数据加密和解密使用不同密钥的传输加密称作非对称加密。
对称加密在传输过程中密钥容易被劫持导致加密形同虚设通信不安全但是由于加解密采用密钥相同其传输效率较高。
非对称加密传输过程中我们使用相关算法生成一对密钥公钥和私钥。在传输过程中通信双发分别向对方发送自己的加密算法公钥并保留自己加密算法的解密密钥私钥。如此在通信过程中客户端和服务端各自使用接收到的对方加密算法公钥来对传输的数据进行加密通信双方再通过自己保留的解密算法私钥对数据进行解密即可获得数据的原本内容。
非对称解密对传输数据的处理方式保证了数据传输的安全性因为即使传输数据被劫持对方知晓公钥也无法对数据解密但是由于加解密算法的不同会导致传输更花费时间效率较低。
为集合两种传输加密的优势我们引入了混合加密的设计来对对称加密和非对称加密都进行使用。其原理是我们首先使用对称加密来快速对数据进行加密数据将被处理为密文然后我们将对称加密后的密文当作非对称加密传输中的数据来进行处理即可。
因为对称加密对数据加密之后得到的密文长度比原数据长度更加简短所以此时再采用非对称加密进行传输的话便可以很好的避免非对称加密处理较长数据的解加密时间过长问题。
