URL&HTTP协议的详解

URL&HTTP协议的详解
    一、URL(统一资源定位器，通常来说是http协议用来识别对方的一个重要方式。)
        （一）协议（protocol ,就是指冒号之前的部分。）: http  https http+ssl(tls)  ftp  SMTP pop3   ssh:  
        1、域名。domain,域名，是指要访问的接口服务器的标识符，可以使机器名，IP地址，域名(域名是由域管理器进行管理维护，一般是虚拟的，字域中具有唯一性）。
        2、端口。
            （1）port,是跟在域名之后，格式为：domin:port
            （2）端口是由服务器自身来制定，可以配置。
            （3）如果服务器所设置的端口是其应用通信所采用的协议的默认通信端口，则用户在进行访问时，可以忽略端口。
            （4）常见的应用协议及其默认通信端口对应关系如下
                http: 80
                https: 443  or 8443
                ftp: 21
                ssh: 22
                smtp: 25
                pop3: 110
        3、地址。（path,是要访问的资源、请求在服务器上的相对地址） 相对地址是相对于服务器的容器（DocumentRoot）地址而言。
        4、URL地址参数。
                是跟在path之后，使用问号作为连接符，用来向服务器传递数据的（一般是get方法）
                url 地址参数本身也是可以算在path中的。
                参数采用键值对。
    二、http协议： http协议是一个分为http  request(http 请求）和http response(http 响应）两部分的协议 。
        （一）http  request：http 请求
            1、request line：请求行，是指请求数据中的第一行内容，包含以下信息： 如示例：GET/phpwind/HTTP/1.1
                （1）request  method
                    请求方法。所有的http请求都必须指定请求方法，如果没有指定，则指定将使用get方法。
                    常见的常见的http请求的方法有：get，post, put, patch, delete。
                    对于请求方法，不是由我们测试决定，而是有接口（开发）来决定
                    get 和post 的联系和区别：
                        联系：
                            get 和post 都是请求方法。
                            get 和post 都可以向服务器发送数据。
                        区别：
                            post方法所发送的数据是以request  body(data) 的方式实现。
                            因为浏览器对于URL的限制（包括长度和字符），如果我们要通过浏览   器来发送请求的话，不符合通过GET方法来传递长度很长，特殊字符很多的数据，而是根据用post方法。
                            post方法比GET更加安全。
                                post 方法获取的相应在客户端是不可缓存的。
                （2）request path
                    就是URL中的path中的path及URL地址参数。
                （3）protocal/version
                    协议和版本
            2、request headers
               （1）是指请求数据包中从第二行开始到第一个空行截止的部分。请求头是客户端用来和服务器进行交互、信息控制的，通常来说和业务本身无关。
               （2）请求头是键值对应
               （3）请求头的名称一般来水是由协议指定的，不同的请求头具有不同的特殊作用
               （4）通常来说，我们在实现接口测试的过程种，需要重点关注的头有以下：
                    User-Agent: 
                       该信息头是用来服务器，客户端配置信息的。通常和cookie,session有关。
                       属于必加信息头，然后绝大多数请求下，只需要保证统一即可。值本身无所谓
                    Content-Type：
                       只有当request body中存在数据时，需要指定该信息头。该信息头是客户端用来告知服务器，body中的数据（Content)的数据组织格式
                       该信息头要求和实际body 的数据组织格式保持一致，然后数据组织格式是有接口（开发）决定对此，在抓包时，我们要切换到sourse/raw模式去查看原始的数据组成，不要被解析之后的格式所迷惑
                    cookie：
                       一般不需要单独处理。jmeter中提供了组件：http cookie 管理器自动管理器
                    其他的权限相关的头：
                       token、csrftoken、author等，一般来说都是需要做关联处理
                    ps:在模拟接口测试时，以上信息头都处理到位的情况下，请求还是无法成功的，可以将抓包的其他信息头逐步添加
            3、request body
                （1）是指请求数据包中从第一个空行开始到最后的内容。http请求数据包中，header和body之间是由一个空行分隔的。一般来说，应用层的接口测试工具都会帮我们自动处理。但是我们一旦我们通过tcp层去模拟发送http请求，则一定要注意空行。
                （2）一旦body中有内容，则100%需要去指定信息头
                （3）body 的数据组织格式以接口和抓包（source，raw,  stream)为准。
        （二）http  response:http 响应
            1、response line
                （1）响应行，是指响应数据包中的第一行内容
                    response  code :响应代码，又叫状态码（Status),是服务器用来告知客户端，服务器对于请求的处理状态
                        该状态仅仅是表示通信层面上服务器的处理状态，而不代表业务的处理状态
                        状态码是三位长度的数字，根据收尾数字的不同，可以分为五类：
                            1xx: 表示连接建立过程中的交互信息
                            2xx:表示通信成功
                            3xx：表示重定向
                            4xx:表示客户端错误
                            5xx:表示服务器错误
                            ps:一般来说，所有的的接口测试工具，都是自动对状态码做检测，并且作为请求是否成功的第一判断元素，状态码为1xx,2xx,3xx都表示成功。4xx和5xx 表示失败。
                            在调适阶段，4xx ,5xx一旦出现，99。9%的情况是我们自身的脚本封装有误导致
                    response   message：
                        响应信息，是用来描述响应代码，没有任何实际意义
                （2）示例：HTTP/1.1 200 OK   包含以下信息：protocol /version、response code 、response message  
            2、response header
                响应头，参考请求头。有的时候，响应头中可能会包含一些权限相关信息（非cookie)   cookie 做 cookie管理器
            3、response body
                响应主体，是指响应数据包中第一个空行之后的所有内容。一般来说，响应主体就是服务器对于请求的处理结果。
                通常需要关联的数据可能会存在于响应主体或者响应头中。
                我们也可以对响应主体进行检测，来判断业务是否正确。