接口自动化测试之HTTP协议详解

协议

简单理解，计算机与计算机之间的通信语言就叫作协议，不一样的计算机之间只有使用相同的协议才能通讯。因此网络协议就是为计算机网络中进行数据交换而创建的规则，标准或约定的集合。

OSI模型

1978年国际化标准组织提出了“开放系统互联网参考模型”，即著名的OSI模型。它将计算机网络体系结构的通讯协议划分为7层，自上而下分别是：物理层，数据链路层，网络层，传输层，会话层，表示层，应用层。(7层网络默认具体是什么自行百度)

那么们的今天的主题HTTP协议就在应用层，也是应用层使用最多的协议

HTTP

超文本传输协议，是一种分布式，协做式的，面向应用层的超媒体信息系统。它是一种通用的，无状态的协议。

原理

HTTP协议工做于客户端与服务器的架构上，客户端经过URL向服务器发送全部的请求。服务器根据接收到的请求，向客户端发送响应信息。HTTP协议定义客户端如何向服务器发送请求，以及服务器如何将响应请求传送给客户端，因此HTTP请求协议采用了请求/响应模型

 

客户端

客户端主要有两个职能

1.向服务器发送请求

2.接收服务器返回的报文并解释成友善的信息供咱们阅读

客户端大概有：浏览器，应用程序等

现在时代咱们可能使用最多的就是浏览器， 当用户在地址栏输入网址回车时，浏览器会为何作以下处理：

1.解析协议和域名

2.使用HTTP协议并建立请求报文向服务端发送请求

3.接收服务器返回的内容并展现给客户

服务端

服务器端在接收到客户端发送的请求后会开始处理请求

服务器处理过程以下

服务器软件一直在监听端口是否有新的请求达到，如iis或者tomcat在创建web站点后，默认会一直监听80端口等待HTTP请求到达服务器。

1.创建链接：若是客户端已经打开一条道服务器的持久链接，则能够直接使用，不然客户端须要在服务器打开一条新的链接

2.接收请求报文：链接上有数据到时，web服务器会从网络链接中读取数据，并将请求报文中的内容解析出来

3.处理请求：当请求被接收后，服务器即可以根据请求报文进行处理了。例如post方法中提出报文主体的数据并插入到数据库中

4.访问资源：请求处理完后，好比web会根据数据生成一系列的HTML页面或图片等信息，此步骤将访问这些存储在服务器上的物理文件

5.构建响应：web服务器在识别资源后，构造响应报文，响应报文包括：状态码，响应头，响应主体等内容

6.发送响应：服务器将响应的数据发送给客户端机器

7.记录日志：请求结束，服务器会在日志文件中记录一条请求日志

你们都知道浏览器想客户端发送请求是经过URL地址传递的，那么接下来咱们看一下URL的组成

URL

实例URL：https://i.cnblogs.com/EditPosts.aspx?postid=10913098&update=1#name

组成

URL主要有如下几个部分组成

1.协议部分

该URL的协议为HTTP

2.域名部分

该URL的域名部分为/www.kath2.com， URL中也可使用ip地址做为域名

3.端口部分

端口部分跟在域名：后面，若是没有，那么说明URL使用的是默认端口80，端口不是URL的必须组成部分

4.虚拟目录部分

从域名后的第一个/到最后一个/之间的部分，虚拟目录也不是URL的必须组成部分

5.文件名部分

最后一个/到？号为止，是文件名部分。若是没有？号，则到#号为止，若是没有？和#号，则从域名最后/开始到结束都是文件名部分，示例中的文件名部分为EditPosts.aspx

6.锚部分

从#号到最后

7.参数部分

从？号开始到#号结束， 多个参数使用&号分割

报文

客户端与服务器之间的信息传递使用的载体叫作报文，报文分为请求和响应两个部分

请求报文

客户端发送数据给服务器的过程叫作请求

组成

请求报文分为4个部分

1.请求首行

包含请求方法，要访问的资源以及所舒勇的HTTP版本

2.请求头部

说明服务器要使用的附加信息

3.空行

请求报文头部后的空行是必须的

4.请求体

get每每不存在请求体，post请求体包含请求的参数

格式

实例

get请求实例

 

post请求实例

请求方法

主要请求方法有get，post，put，delete等

get请求

1.从服务器获取数据，返回响应的实体部分，能够类比数据库的select操做，不会影响数据库自己

2.没有请求体

3.请求参数附在URL后，以？号开始，多个参数使用&分割

4.一般对数据不敏感的请求使用get请求，由于参数跟在URL后不安全

5.传输的参数长度是有限制的

post请求

1.向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会致使新的资源的创建和/或已有资源的修改。

2.一般post请求含有请求体

3.请求参数存放在请求体中，能够是任意格式

4.相对来讲数据比较安全

5.请求数据无大小限制，能够认为是无限制

其余请求不作介绍

响应报文

客户端发送请求到服务器，服务器处理以后返回数据给客户端的过程叫作响应

组成

响应报文一样包含了4个部分

1.响应首行

协议版本，状态码，成功与失败的状态信息

2.响应头部

用来讲明客户端要使用的一些附加信息

3.空行

响应报文头部后的空行是必须的

4.响应数据

返回给客户端的数据等信息

格式

实例

get响应实例

 post响应实例

响应状态码

HTTP扩展

Cookie机制

Cookie是什么？

你们都知道咱们登陆一个网站的时候，在输入账号和密码的时候下面常常会看到一个“记住我”的选项，那么只要咱们勾选了这个选项，再次登陆的时候就无需再输入账号和密码便可登陆网站，那么这种方法就是经过Cookie机制实现的。用来记录用户的状态和用户的身份

Cookie是由服务器发给客户端的特殊信息，而这些信息，以文本文件的方式存在客户端，而后客户端每次向服务器发送请求的时候就会带上这些特殊信息，以便服务器作身份识别

Cookie处理过程

当用户第一次请求服务器时，请求报文中并不会包含Cookie信息，当服务器接收到客户端的请求时，会响应信息给客户端，这时候响应报文的头部会包含一个set-Cookie的字段信息，并包含了用户的身份信息。当客户端收到set-Cookie时，会把Cookie保存在本地（内存或者硬盘中）

当客户端再次发送请求报文给服务器时，请求报文头部会携带Cookie信息并发送给服务器，服务器经过Cookie自带的信息分析，动态生成与该客户端相对应的数据。

实例

第一次访问

http://120.78.128.25:8765网站，咱们使用Fiddler抓取请求此网站首页的请求报文和响应报文

能够看到第一次请求次网站时，请求报文是不含有Cookie信息的，而响应报文返回一个set-Cookie给客户端

第二次访问

第二次请求的报文和响应报文，咱们能够看到已经发生了变化

请求报文已经携带了Cookie信息， 而响应报文再也不携带set-Cookie信息

因此说只要咱们不清楚cookie信息，那么之后有效时间内，咱们均可以直接访问这个网站

Session机制

Session是什么？

Session是另一种记录客户状态和身份的机制，不一样的是Cookie保存在客户端本地中， 而Session保存在服务器中

与Cookie机制做用相同，只不过Cookie是经过检查客户身上的通行证肯定客户身份，而Session则是经过服务器上的客户明细表来确认客户身份

Session处理过程

当客户端第一次请求服务器时，服务器会建立一个Session并为该Session分配惟一标识Session id，并向Session中添加内容，服务器收到客户的请求后，会返回给客户端响应的信息，那么响应报文头部会携带Session id返回给客户端

当客户端再次请求服务器时，请求报文头部会携带以前的Session id(session id 是须要经过cookie传递)， 服务器收到请求后根据Session id查找对应的session内容， 并分析对比是否为同一个客户端发来的请求，接着返回相应的数据给客户端

区别

最后咱们经过一个生活中的实例来深刻理解两者的区别

笔者曾常常去的一家咖啡店有喝5杯咖啡免费赠一杯咖啡的优惠，然而一次性消费5杯咖啡的机会微乎其微，这时就须要某种方式来纪录某位顾客的消费数量。想象一下其实也无外乎下面的几种方案： 

    一、该店的店员很厉害，能记住每位顾客的消费数量，只要顾客一走进咖啡店，店员就知道该怎么对待了。这种作法就是协议自己支持状态。 

    二、发给顾客一张卡片，上面记录着消费的数量，通常还有个有效期限。每次消费时，若是顾客出示这张卡片，则这次消费就会与之前或之后的消费相联系起来。这种作法就是在客户端保持状态。 

    三、发给顾客一张会员卡，除了卡号以外什么信息也不纪录，每次消费时，若是顾客出示该卡片，则店员在店里的纪录本上找到这个卡号对应的纪录添加一些消费信息。这种作法就是在服务器端保持状态。

因为HTTP协议是无状态的，而出于种种考虑也不但愿使之成为有状态的，所以，后面两种方案就成为现实的选择。具体来讲cookie机制采用的是在客户端保持状态的方案，而session机制采用的是在服务器端保持状态的方案。同时咱们也看到，因为采用服务器端保持状态的方案在客户端也须要保存一个标识，因此session机制可能须要借助于cookie机制来达到保存标识的目的，但实际上它还有其余选择

原文出处：https://www.cnblogs.com/linuxchao/p/linuxchao-http.html