HTTP详解

一、tcp/Ip四层模型
    1. 应用层：http、ftp（文件传输协议)、smtp(邮件传输协议）、telnet(tcp)|  ping->ICMP
    、DNS->UDP
    2. 传输层：TCP UDP
    3. 网络层：IP、ICMP、IGMP、ARP、RARP。
    4. 网络接口层：
二、http协议详解：
    1. http(超文本传输协议)
   >2. 请求报文格式
        请求行：   GET http://www.baidu.com HTTP/1.1（方法名：url地址 协议版本+【回车换行】）
        头部字段： User-Agent: Weget/1.12            (字段名称：【空格】 字段的值+【回车换行】)
                  connection: keep-alive->表示长连接
                  Content-Length: 128---->表示消息正文的长度
                                                    （【空行】）
        请求数据： ——————————————————————————————
   >3. 响应报文格式：
        状态行：  HTTP/1.1 200 OK                    (版本号 状态码)
        响应头：  Server: Apache-Coyote              (字段名称：【空格】 字段的值+【回车换行】)
                 Content-Type: application/jason->内容的类型
                 Content-Length: 128------------->正文的长度
                                                     （【空行】）
        相应正文：————————————————————————————————

    4. 请求的方法：
        GET ： 从服务器获取资源，是安全的不会改变服务器的资源的状态
        HEAD： 仅要求服务器返回头部信息
        POST： 客户端向指定资源提交数据进行资源请求（例如提交表单或上传文件）
               可能会导致已有资源的修改。
        TRACE：回显服务器收到的请求->主要用于测试人员测试用

    5. POST与GET方法的区别：
        1. GET请求的数据会被附在URL之后，而POST是以将信息放在消息主体中，所以GET不安全
        2. GET方法最多提交的数据大小为1024字节，而POST理论上无限制
        3. GET方法只用于获取信息而并非修改信息，所以不会影响已有资源的状态
           而POST可能修改已有资源的状态


    6. 状态码 :
        . 1XX：服务器接收到了请求行和头部信息，告知客户端继续发送数据
               (客户端首先要先发送Except： 100-continue 头部字段告诉服务器自己还有数据要发送)
        . 2XX：请求成功
        . 3XX：资源被转移了，将被重定向
        . 4XX：客户端出错
        . 5XX：服务器出错

    7. http的请求报文和响应报文为什么是这种格式？
        为了避免粘包问题
        1. 使用空行作为消息报头的结束
        2. 以固定的方式读取消息报头，http报头的每一行都是一个完整的消息
        3. 给出请求正文的大小，按大小读取Content-Length
    8. TCP粘包问题：
        1. 什么是粘包？
            发送的后一包的头部紧紧粘着前一包的尾部，导致接收方不能正确的接收包的现象叫做粘包问题
            . 只有在TCP长连接时才会发生粘包问题，短连接不会，因为短连接发送完一次数据就会断开链接
            . UDP不会发生粘包问题，因为UDP是面向数据包的有固定的消息边界
            . 无格式的文件等也不会发生粘包，因为只关心接收和发送
        2. 为什么会出现粘包现象？
            . 发送方原因：
                由于TCP默认使用Nagle算法
                            ————>只有让上一个分组得到确认才会发送下一个分组
                    Nagle算法
                            ————>收集多个小分组，在一个确认到来时一起发送
                正是Nagle算法导致了发送方可能的粘包问题
            . 接收方原因：
                TCP接收到分组后，将分组保存至接收缓冲区中，然后应用程序主动从缓冲区里读数据，这样一来
                如果TCP接收分组的速率大于应用程序从缓冲区里读数据的速率，就会有多个包被放进缓冲区里，
                就会出现粘包现象。
        3. 怎么处理粘包现象？
            . 发送方处理
                可以通过关闭Nagle算法防止粘包出现，使用setsockopt函数里面的选项TCP_NODELAY,缺点：
                会降低传输效率
            . 接收端
                没有相应机制
            . 应用层处理：
                应用层的处理简单易行，不仅能够解决接收方造成的粘包问题，还能解决发送方产生的粘包问题
                解决方法就是循环处理：应用程序在处理从缓存读下来的数据时，读完一条数据，就应当循环读
                取下一条数据，直到所有的数据都被处理；但是如何判断每条数据的长度呢？
                    1. 格式化数据：每条数据都有固定的格式（开始符，结束符）缺点，如果正文中有开始符或者
                结束符就会失效。
                    2. 发送长度： 发送每条数据时，将数据的长度一并发送，比如可以选定每条数据的前四位是数据
                的长度，应用层可以根据数据的长度来判断数据的开始和结尾。

    9. get_line()
        int get_line(int sock,char *buf,int size)
        {
            int i=0;
            char ch='\0';
            ssize_t ret=0;
            while(i<size&&ch!='\n')
            {
                ret=recv(sock,&ch,1,0);
                if(ret>0&&ch=='\r')
                {
                    ssize_t s=recv(sock,&ch,1,MSG_PEEK);
                    if(ch=='\n')
                        recv(sock,&ch,1,0);
                    else
                        ch='\0'
                }
                buf[i++]=ch;
            }
            buf[i]='\0'
            return i;
        }

    10. http长连接与短连接
        connection: keep-alive
        http1.0-->默认短链接
        http1.1-->默认长连接
        TCP在读写操作之前，server与client必须先建立一个连接，读写操作完成后，若双方不需要
        连接就可以释放连接，建立连接三次握手，释放连接四次握手
        http长连接实现原理：
            保活计时器：
            如果一个给定的链接在两小时内没有任何响应，则服务器就会想这个客户端发送一个探测
            报文段，客户端必须处于以下四种状态之一。
                1. 客户主机依然正常运行，并且服务器可达，客户的tCP响应正常，而服务器也知道
                对方是正常的，则2小时后保活计时器复位
                2. 客户主机已经崩溃且关闭，或者正在重启，则服务端将不能收到探测报文的响应
                并在75秒后超时，服务器总共发10个这样的探测每个相隔75秒，若没有收到响应则认为
                客户主机已关闭，就终止链接
                3. 客户机正常运行，但是服务器探测报文不可达，类似2
                4. 若客户端没有崩溃，但是已经重启，服务器会受到对其存活性的响应，该响应是一
                复位，从而引起服务器对链接的终止。
        长连接与短连接的应用场景：
            长连接多用于操作频繁，点对点的通信，如数据库的链接用长连接
            一般网站的访问用短连接，因为长连接比较耗费资源。
        心跳包，心跳检测机制：
            心跳包，每隔一段时间就会发起一次链接，查看客户端的链接是否还存在，一般在应用层实现
            一般只有一个标志位（仅用来判断链接是否通畅）
            比如微信就在应用层使用了心跳检测的机制。

转载于:https://www.cnblogs.com/readlearn/p/10806418.html