应用层HTTP协议

目录

前言 

一.认识URL

二.HTTP协议

        2.1http协议的基本特征

        2.2HTTP发下请求和响应的格式

        2.3 HTTP协议请求方法 

        2.4 http的状态码

         2.5 http常见Header(报头)

        2.5 http和https对比

---

前言 

        协议是一种"约定"。

        当我们在往网络中读写数据时，都是按比特位的方式接收的，如果我们要传输一些结构化的数据，比如多条数据，该怎么传输呢？

        发送方可以将多条数据合成一条数据发出去，接收方将一条数据分成对应多条数据。

        数据又多变一的过程叫做序列化。数据由一变多的过程叫反序列化。

        短连接：客户端发起请求，服务器处理后，发送响应，服务器将连接断开。一个服务周期结束。

        长连接：客户端和服务器长时间连接。

        虽然说应用层协议是我们自己程序员自己定的，但是实际上，已经有大佬们定义了一些现成的，有非常好用的协议，供我们直接使用。HTTP(超文本协议)就是其中之一。

        HTTP协议是应用层的一种协议，它是建立在传输层TCP协议上的。

   一.认识URL

• URL就是我们"网址"

• urlencode和urldecode

        在url中/?:等这样的字符已经被赋予特殊的意义了，因此这些字符已经不能随便出现。如果要参数中要使用这些字符，就需要对特殊字符进行转义，对特殊字符进行转义被称为urlencode。

        转义规则：将要转义的字符转为16进制，然后从右到左，去四位(不足4位直接处理)，没两位做一位，前面加上%，编码成了%XY的格式。

 "+"被转义成了"%2B"。

urldecode就是urlencode的逆过程，将转义翻译成特殊字符。

二.HTTP协议

        2.1http协议的基本特征

1. 无连接：http协议在客户端和服务器之间没有连接。http协议是无连接的，但是它是建立在TCP协议上的，TCP协议是有连接的。
2. 无状态：并不会记录用户的任何信息。
3. 简单快速：短连接，文本传输。

        2.2HTTP发下请求和响应的格式

        不准确的说，服务器应用层按照下面请求的格式发送数据给服务器，服务器收到后，按照响应的格式发送数据给客户端，这可以等价于是一种协议。

        实际上：应用层将数据封装后，通过接口，将数据发送给下一层。

 两个问题：

1.服务器或者客户端收到数据后，怎么直到读完状态行和报头了呢？

        状态行和报头之间有一个空行，当读到空行，说明读完状态行和报头了。

2.服务器和客户端怎么知道正文有多少，因该读到哪里结束？

        在报头有一个Conten-length：字节数，这个对应的是正文字节的个数。

•  fiddler工具进行抓包

        fiddler是一个可以抓包的工具，下载地址：fiddler官网

        对照上面的格式。

         fiddler工作原理：

        fiddler实际是一个代理。

        2.3 HTTP协议请求方法 

请求方法	说明	支持的版本
GET	获得资源	HTTP1.0，1.1
POST	传输实体主体	1.0，1.1
PUT	传输文件	1.0，1.1
HEAD	获得报文首部	1.0，1.1
DELETE	删除文件	1.0，1.1
OPTIONS	询问支持方法	1.1
TRACE	追踪路径	1.1
CONNECT	要求用隧道协议连接代理	1.1
LINK	建立和资源之间的联系	1.0
UNLINE	断开连接关系	1.0

         其中最常用的是GET和POST方法，其它方法一般对用户来说是禁用的。

        GET和POST方法的差别：GET和POST请求方法都可以传参(用户的账号密码信息)，但是GET不带正文，只能通过URL进行传参，POST有正文，可以通过正文进行传参。

        http1.0是短连接的，http1.1是长连接的。

        2.4 http的状态码

	类别	解释
1XX	informational(信息状态码)	接受的请求正在处理
2XX	success(成功状态码)	请求正常处理完毕
3XX	redirection(重定向状态码)	需要进行附加操作已完成请求(比如：跳转到其它的网页)
4XX	client error(客户错误状态码)	服务器无法处理请求
5XX	server error(服务器错误状态码)	服务器处理请求出错(比如：创建进程或者线程失败)

 最常见的状态码：200(OK)，404(NOT FOUND)，403(Forbidden)，301(永久重定向)，302(临时重定向)，307(临时重定向)，504(Bad Gateway)。

        永久重定向：是想进入一个网页，直接跳转到另外一个网页，彻底忘记之前网址的存在。

        临时重定向：是先进入旧的网页，服务器返回响应实际要跳转到另外一个网页，客户端再去连接实际要跳转的网页。

         2.5 http常见Header(报头)

• Content-Type：数据类型(text/html等)。
• Content-Length：正文长度(字节)
• Host：客户端告知服务器，请求资源的主机号和端口号。
• User-Agent：声名用户的操作系统和浏览器版本信息。
• referer：当前页面从哪个页面跳转过来的。
• location：搭配3XX状态码使用，告诉客户端接下来要跳转到哪里访问。
• Cookie：同于再客户端存储少了信息，用于实现会话的功能。

cookie和session原理：        

我们拿登录账号举例：

        我们知道http协议是无状态的，并不会记录用户的信息。但是我们实际生活中使用网页需要登录时，一般我们登录了一次，之后并不会需要再登录了。

        这是因为http本身是无状态的，但是如果访问某资源频繁需要登录，会导致用户的体验不好。

cookie原理：

        于是当浏览器访问某资源需要登录时，客户端将name和passwd发送个服务器，服务器与注册时保存的name和passwd对比，成功后响应，将name和passwd放在报头的set-cookie中发送给客户端，客户端将其保存到cookie中，下次访问时，将cookie信息发送给服务器，就不需要登录了。

        cookie本质是一个浏览器的文件，里面保存用户的一些信息。

        文件保存分为内存级(关闭浏览器进程就空间释放了)，硬盘级文件(长时间保存在硬盘中，关闭进程并不会释放)。

        但是：直接发送cookie，cookie保存的name和passwd并不安全，中间人可以直接获得用户的name和passward。

session原理：

        在本地保存用户的信息，发送的时候不安全。于是，在客户端登录时，将name和passwd发送给服务器，服务器形成一个文件session，里面有一个标识sid，全互联网唯一，标识的是用户的信息，响应时将sid放到set-cookie里发送给客户端，客户端将sid保存到cookie中，下一次访问带有的cookie中保存的是sid，服务器只要拿着sid比较即可。

        这样用户信息保存到了服务器，相比较只使用cookie安全性会高一点。

        2.5 http和https对比

         http的端口号是80，https协议端口号的443。

为什么发送数据使用session还需要加密呢？

        因为在注册或者是输入账户密码时，总会有实际传输用户信息的情况，信息总时不安全的。 

• https加密细节

        对称加密：对称加密有一个秘钥，对数据加密和解密都是通过同一个密钥实现。

        非对称加密：非对称加密会有一个公钥和私钥，通常情况使用公钥进行加密，使用私钥进行解密。特殊情况，使用私钥加密，公钥解密是用来认证的。

         用户端和服务器端确定好加密规则后，客户端和服务器端都得知道秘钥，秘钥也会需要传输，秘钥也是数据，也要保证秘钥的安全。于是是通过非对称加密来保存秘钥的安全。

为什么不直接使用非对称加密要加密数据？

        非对称加密算法复杂，效率低下。

        使用对称加密只需要对秘钥用一次非对称加密。之后用秘钥加密即可。

        直接用非对称加密，有多次数据就要使用多次次非对称加密。

        但是还会有一种隐患，如下，这样中间服务器也能获得客户端的秘钥，数据和服务器的响应。并且还能修改服务器的响应，再响应给客户端，导致客户端收到一个错误的响应。

 解决：要解决两个问题

• 远端服务器的认证问题？ 

• 这里时旧的记录先保存，下面是新的理解：

          远端服务器有公正部门的证书，证书中包含权威信息，中间服务器没有。发送时将权威信息通过哈希算法映射成数据摘要，将证书和数据摘要通过私钥加密，发送给客户端。

          客户端内置证书信息，可以用公钥解密，将权威信息进行比较，来识别远端服务器。

          中间服务器无法获取权威信息的数据摘要，数据摘要进行加密了。

  

          服务器有自己的私钥和公钥，服务器将公钥发送给CA机构(证书颁发机构)认证，CA机构使用私钥对服务器的公钥进行加密，并加入一些权威信息生成证书，返回给服务端。

          由于CA机构比较权威，客户端会内置CA根证书，包含CA公钥。

          服务器将证书(CA私钥加密的)发送给客户端，客户端使用CA公钥解密，获得服务器的公钥和权威信息等。

          中间服务器没有根证书，即使有，也只能进行认证。

  

• 中间信息被修改的问题？

        服务器端收到客户端发来的信息，响应会将响应信息通过哈希算法对响应数据进行映射，得到一个定长字符序列，这个定长字符序列被称为数据摘要。服务器将数据和数据摘要一起发送给客户端，并且都进行了加密。数据加密通过秘钥进行加密，数据摘要加密是通过公正部门的秘钥进行加密，中间人获取不到这个秘钥。数据摘要加密后称为数据签名(指纹)。

        当客户端收到数据，只要将摘要解密，将数据通过相同哈希算法或一个数据摘要，再和发送来的数据摘要进行比较，相等说明没有被窜改。

        中间服务器修改数据同时还得修改数据摘要，但是无法解密数据摘要，即使对数据进行修改，客户端也能识别。