Linux 网络基础（2）应用层（http/https协议、请求格式、响应格式、session、cookie、加密传输）

说明：网络基础2讲解的是应用层的典型协议， 通过对于典型协议的理解，来体会数据的网络传输的软件层面的流程与原理。

面试中网络通信相关问题占了很大的比重，而网络通信相关的问题大多都集中在网络基础2这个单元中

下面是应用层的位置：

应用层: 自定制协议 (私有协议) ，HTTP协议;

传输层: UDP & TCP协议

1.应用层

应用层: 负责应用程序之间的数据沟通

应用层协议其实是面向程序员的协议，因为应用程序是程序员写的，因此应用程序之间如何沟通是程序员定的。

程序员自己定理的程序沟通的数据格式约定，而针对某些场景，大佬们定制出的协议，大家觉得非常好，都用了这种协议，这种协议叫做知名协议

自定制协议: 程序员自己定义的程序沟通的数据格式约定

序列化:在网络传输或者数据的持久化存储时，将多个数据对象按照指定格式组织成为一个二进制数据传进行传输或持久化的过程

反序列化: 对二进制数据传，按照指定格式进行解析，得到各个数据对象的过程

程序员设计自定制协议的时候需要考虑的要素有哪些?

1.传输性能:定制一个协议，传输的数据尽可能短小，传输数据的时候才能尽可能的快。

2.解析性能:传输多个数据对象的时候需要进行序列化，对方拿到数据后要进行反序列化，解析性能指得就是序列化和反序列化要足够快

3.调试便捷性:讨论的更多的式对于程序员的可见性，可识别性。

举例：网络版计算器

一个客户端要进行两个数据的运算，运算的过程并不自己进行，而是将数据传输给服务器，让服务器运算，并返回结果。

数学运算: 11 + 22

需要向服务器传输的数据对象有三个: 第一个数字，第二个数字，运算符

协议如何定制:

方案1: 11+22字符串传输， 解析过程:获取数字字符，遇到其他字符截止，取出第一个数字，特殊字符为运算符，剩下的获取数字字符

方案2:解析过程: 先以;进行字符串分割，前两个字符串转换为数字，最后是运算符11;22;+;

方案3:二进制序列化，将三个对象的二进制数据分别放到一整块内存的指定位置，最终按照位置进行解析即可

因为网络传输是跨主机的传输，因此结构体序列化需要考虑：

1. 结构体内存对齐问题

2. 传输的数据字节序问题

2.http协议

HTTP协议: 互联网公司中使用最多的协议。

认识: HTTP--超文本传输协议 (最早期就是为用来传输web网页而设计的)

特性:

1.基于字符串明文传输的，调试便捷性高，

2.是一种简单的请求-响应协议(早期是短链接-一次请求-响应结束就关闭)

1. 基于TCP协议，传输安全可靠。

3.请求格式

格式:想要使用一个协议，用的好，就必须去了解他的格式，了解协议中每一个字段的功能.

1.请求行:请求中的第一行，主要对请求进行关键性描述

请求行中的内容分为三部分，以空格作为间隔，请求行以\n \r作为结尾(请求行，其实刚好就是一行数据)

第一部分: 请求方法:多种多样，描述不同的请求目的

GET:向服务器请求一个网页实体资源，请求中没有正文，但是也可以向服务器提交数据，提交的数据在URL中(安全性低，长度受限

POST: 向服务器提交表单数据，请求中有正文

HEAD:面试中经常会问GET和HEAD有什么区别--目的与GET类似，但是不同的是，实际的响应中不要实体资源，只要响应头部

PUT: 更新服务器上的资源

DELETE:删除服务器上的资源

................

第二部分: URL

第三部分: 协议版本

描述了当前请求所使用的HTTP协议版本，不同的版本之间有功能支持力度上的差异

HTTP协议的版本迭代：

HTTP/0.9--- 0.9版本，是一个不成熟的版本，只能使用GET获取网页，而且也没有当前的完善的协议格式

HTTP/1.0---1.0版本，完善了协议格式，新增支持了更多的请求方法:GET，HEAD，POST，并且有了缓存的控制，以及流媒体的传输

HTTP/1.1---1.1版本，是当前用的最多的版本，新增支持了更多的请求方法:PUT,

DELETE ....；针对当前的网络，觉得以前的通信效率太低了: 支持了长连接，对缓存的管理更加精细了

长连接与短链接：

短链接:建立TCP连接-》发送请求-》接收响应-》关闭连接

每次要获取一个资源，都要重新建立连接，关闭连接，效率很低

长连接(管线化传输):

长连接: 建立连接-》发送请求-》接收响应-》发送请求-》接收响应。。。。-》关闭连接

长连接管线化传输:建立连接-》发送请求-》接收响应-》发送请求1-》发送请求2-》接收响应1-》接收响应2-》关闭连接

HTTP/1.1版本的迭代，更多的是对传输效率的改进

HTTP/2这个版本是一个大跃进，因为并不向前兼容

1.使用二进制传输，以前是名文字符串

2.不用重复每次请求传输相同的头部字段

3.长连接的一些改进，不需要按序响应，解决了队头阻塞问题

4.主动推送功能的加入，服务器响应数据的时候，可以主动响应依赖数据

2.请求头部:一个个的键值对，对于请求的附加描述以及对正文的描过

请求头部: 由的键值对组成，key: val r nkey:针对请求的些附加描述，以及对于请求正文的描述valrin

请求头部 (只会在请求中出现的头部字段，描述请求)

User-Agent，Host,Referer....

正文头部 (在请求与响应中都会出现，主要是对于正文的描述)，

Content-Length:129 用于描述正文长度

Content-Type: application/json;charset=UTF-8 用于描述正文的数据类型，决定了对方如何解析处理正文

响应头部(只会在响应中出现的头部字段，描述响应)

Location: http://baidu.com 用于描述重定向

通用头部(在请求与响应中都会出现，属于对于本次通信或者连接的一些描述)

Connection: keep-alive/close : 用于描述当前的连接使用的是短链接还是长连接

3.空行: 间隔头部与正文

空行: \rn 主要用于间隔HTTP头部与正文

主要是实现在HTTP协议解析时，先接收一个完整的HTTP协议头部，根据其中的Content-Length确定正文长度,然后根据正文长度，取出指定长度的正文，则刚好能够完整的获取到一条HTTP请求。

4.正文:提交给服务器的数据

正文: 提交给服务器的数据，类型格式通过Content-Type描述

4.响应格式

响应格式:响应行，响应头部，空行，正文

响应行: 协议版本 状态码 状态码描述\r\n ---> HTTP/1.1 200 0K\r\n

状态码: 用于明确直接的向客户端表示本次请求的处理结果

1xx:继续请求或者协议切换，101---协议切换

2xx:请求已经成功处理了，200---成功处理:206---区间内容处理成功

3xx:表示请求进行了重定向 301---永久重定向 302---临时重定向:

303-see other 304--not modifvy，

重定向:把一个请求，重定向到其他链接。示例:一个请求，要请求的资源，被移动到了其他位置。但是想要依然保持原链接有效301.302,303这种要跟 Location响应头字段搭配使用，Location字段用于指定的重定向的新链接， Location: htp:/baidu.com

4xx:表示客户端的错误， 400--bad request，404--Not Found 请求的资源不存在

5xx: 表示服务器的错误， 500--服务器内部错误

502--bad gateway,代理服务器连接服务器失败; 504-gateway timeout--代理请求超时

状态码描述:没有实际的功能性意义，给程序员看的,是对于状态码的文字描述信息

响应头部: Connction， Location 。。。。

空行：间隔头部与正文

5.Cookie

头部字段中的 Cookie (请求头) & Set-Cookie (响应头)

:http是一个简单的请求-响应协议，不管是短链接还是长连接，连接都不是一直持续的。

这样就会存在一个问题: 例如在购物网站购物，因为连接不是持续的，导致每次买东西都要重新建立连接，进行登录因此就需要不管连接是不是原来的，但是都要能够区分出用户，为了解决这个问题就提出了一个方案: cookie机制

cookie:小饼干，cookie是一种信息缓存机制，将一些信息保存到客户端主机上，等下一次请求服务器的时候读取出来发送给服务器

Set-Cookie (响应头) :告诉客户端，那些信息需要保存起来，保存到客户端本地

6.session（会话）

session: 会话，就是为客户端与服务器的通信建立一个会话，将会话重要内容保存起来,会话内容被保存在服务器上，通过cookie只需要传输Session id 即可这样做有个好处，不会在网络上传输用户的敏感信息

session会话机制，是在cookie的基础上，避免了敏感信息的传输，提高了安全性

cookie和session的区别:

1.cookie是将关键信息保存在客户端本地，每次通信前发送给服务器

2. session是将会话信息保存在服务器，通过session id进行cookie传输，保护隐私性

本质上来说这两种还是有一些安全隐患的: cookie篡改 --- 解决方案: token

7.HTTPS协议

HTTPS协议:在HTTP协议的基础上进行了一层加密，因此HTTPS不是一个新的协议，而是一个加密后的HTTP协议。

加密: SSL/TLS加密

为什么要加密:

身份验证:小明和小红是小学同学，小明有一天给小红表白，我喜欢你，小红说我也喜欢你，你先给我打200块行不行过了一段时间，过年了，小明和小红都回村子了，小明去找小红，小红说我的gg早都已经被盗了。在网络通信的时候，我们都必须明确知道对方是谁，并且还要能够验证，现在通信的就是这个人，而且还要防止对方赖账

解决方案：第三方权威机构+CA认证

8.加密传输

对传输的数据进行加密

通信双方进行传输加密，需要进行密钥的协商

对称加密：数据的加密和解密使用的是相同的密钥

缺点：进行密钥协商的时候容易被劫持，加密形同虚设；

优点：加解密的效率高

非对称加密：数据加密和解密使用的密钥是不一样的

缺点：加解密效率较低

优点：安全，不怕劫持

思想：通过指定的算法（RSA），可以生成一对密钥（公钥&私钥），使用公钥进行数据加密，加密后的数据只能使用私钥进行解密

流程：连接成功后，将自己的公钥发送对方，对方使用公钥加密要传输的数据，这个数据就只能用私钥解密

混合加密

思想：假设是客户端对服务器进行验证

1. 服务器生成一对非对称密钥，连接成功建立，通信前，将公钥发送客户端

2. 客户端收到后，使用公钥加密一个随机数A，以及自己支持的对称加密算法

3. 服务器收到后，使用私钥进行解密，得到随机数A，以及对方的对称加密算法

4. 服务器向客户端发送一个随机数B，以及自己支持的对称加密算法

客户端和服务器，各自根据两个随机数以及支持的对称加密算法，计算出一个对称，密钥。

e.往后的通信使用对称密钥进行加密解密

在实际的SSL加密中，身份验证和加密传输是整合在一起的。CA证书中包含了更多的信息: 通信方的公钥，机构信息，证书颁发机构信息，失效时间.....整体流程: 单向验证，以服务端验证为主

1.服务器自己生成一对密钥，拿着公钥，去第三方权威机构颁发证书

2.权威机构根据服务器的公钥，生成一个CA证书，给服务器

3.客户端与服务器建立连接后，通信前，服务器先将CA证书发送给客户端

4.客户端收到CA证书，进行解析验证权威机构是否自己信任，在权威机构验证对方身份，解析出公钥

5.客户端生成一个随机数，使用公对随机数+加密算法进行加密，发送给服务器

6.服务器收到数据后，使用私钥进行解密，生成一个自己的随机数，将随机数和加密算法发送给客户端

7.客户端收到数据后，客户端和服务器都有对方的随机数，和自己的随机数，以及加密算法，进行计算得到一个对称密钥

8.往后通信，使用对称密钥进行传输加密