HTTP协议细节

一】客服端  -->  服务端
        1》结构
            a)请求行
            b)请求头
            c)请求体:请求的内容,如果没有,就是空白字符
        2》请求(客户端)    
            请求详细:
                1》请求行
                GET(请求的方式)    /books/java.html(请求的目标资源) HTTP/1.1(请求采用的协议和版本号)
                2》多行请求头
                Accept:*/*    (客户端能接受的资源类型)    
                Accept-Charset:GBK  (客户端支持的编码格式)            
                Accept-Language:en-us(客户端接受的语言类型:中文、英文等)
                Connection:Keep-Alive    (发出请求后,维持客户端和服务端的连接关系)
                Host:localhost:8080                (连接的目标主机和端口号)
                Referer: http://localhost/links.asp    (来自于哪里)
                User-Agent:Mozila/4.0        (客户端版本号的名字)
                Accept-Encoding: gzip, deflate    (客户端能够接收的压缩的数据的类型)
                If-Modified-Since:Tue,11 Jul 2014 18:23:50 GMT  (缓存的时间)
                Cookie(客户端暂存服务端的信息)
                Date:TUe,11 JUl 2013 18:33:34 GMT (客户端请求服务端的时间)
                3》请求的内容(没有就空白字符)即:请求体
    二】常用的提交方式
            1)GET
                    特点:
                    1》求参数无论多少,都会跟着URL后面传到服务端,并且以明文的方式。    
                    2》GET传递会收到浏览器的限制,有长度的限制。
                    3》GET方式传递信息不安全。
                                
            2)POST
                    特点:
                    1》请求参数无论多少,都不会跟着URL后面传到服务器,而是以参数形式在求体中传递到服务端
                    2》POST方式传递无大小限制
                    3》GET方式传递信息相对安全
                    4》传送的数据量无限制,还可以用于文件的下载
    三】服务端 ---> 客户端
        1)结构:
                a、一个状态行
                b、若干个消息头
                c、实体内容
        2)详细
            Http/1.1    (相应采用的协议和版本号)  200(状态码)    ok(描述信息)
            Location: http://www.baidu.com(服务端需要让客户端去访问的页面路径)
        Server:apache tomcat(服务端的Web服务器名)
        Content-Encoding: gzip(服务端能够发送的压缩编码类型)
        Content-Length: 80(服务端发送给服务端的压缩后数据的长度)
        Content-Language: zh-cn(服务端发送的语言类型)
        Content-Type: text/html; charset=GB2312(服务端发送的类型及采用的编码方式)
        Last-Modified: Tue, 11 Jul 2000 18:23:51 GMT(服务端对该资源最后修改的时间)
        Refresh: 1;url=http://www.it315.org(服务端要求客户端1秒钟后,刷新,然后访问指定的页面路径)
        Content-Disposition: attachment; filename=aaa.zip(服务端要求客户端以下载文件的方式打开该文件)
        Transfer-Encoding: chunked(分块传递数据到客户端)  
        Set-Cookie:SS=Q0=5Lb_nQ; path=/search(服务端发送到客户端的暂存数据)
        Expires: -1(服务端禁止客户端缓存页面数据//3种包含下面的2种)
        Cache-Control: no-cache(服务端禁止客户端缓存页面数据)  
        Pragma: no-cache(服务端禁止客户端缓存页面数据)   
        Connection: close/Keep-Alive(维护客户端和服务端的连接关系,1.0用close,1.1用Keep-Alive)  
        Date: Tue, 11 Jul 2000 18:23:51 GMT(服务端响应客户端的时间)
                
    四】状态码        
            302:重定向。客户端请求服务端,但服务端没有对应的资源,服务端要求客户端再次请求找其它的服务端,即客户端二次请求。
            307:转发。客户端请求服务端,但服务端没有对应的资源,服务端自行请求去找其它的服务段,即客户端一次请求。
            304:客户端请求服务端,但此时客户端缓存中有这个资源,无需再从服务端下载新的内容,此时服务端叫客服端自行找缓存。优化常用的方式。
            404:服务端没有此资源。
            500:客户端请求的资源服务端存在,但在执行的时候出错了。
    总结:
            想让浏览器有何种行为,服务端只能通过响应头的方式来设置
            想让浏览器知道何种行为,浏览器只能通过请求头的方式来请求

时间: 2024-10-14 18:45:34

HTTP协议细节的相关文章

<再看TCP/IP第一卷>关于网络层及协议细节---IP协议

说到关于IP协议,就必须先说IP协议的两个特性: (一)不可靠性(unreliable) 不可靠性的意思是它不能保证IP数据报能成功地到达目的地,IP所能做的只是提供最好的传输服务,IP有一个简单的错误处理算法:丢弃该数据,然后发送ICMP消息报给信源端,任何的可靠性就必须由上一层的协议来提供. (二)无连接性(connectionless) 无连接性的意思是IP并不维护任何关于后续的数据报(datagram)的状态信息,数据报之间是平行的互不干涉,IP不维护后续的状态信息. IP数据报的格式如

<再看TCP/IP第一卷>关于网络层及协议细节---IP协议(2)--移动IP及DHCP

题外话:本来想按照互联网的层级自下向上回顾这些协议的,但是今天实在得破个例,DHCP不得不说! 主机从一个网络迁移到另一个网络,那么IP编址的结构就要发生改变,当今主流有如下几种修改方案: (一)改变地址: 主机在移动到新的网络的时候改变它的地址,这里需要DHCP协议,将其和新的网络关联起来,这么做的话需要我们手动修改可能需要如下的命令 1 sudo vim /etc/network/interface 每次修改若想要使修改之后生成的IP地址生效,大部分情况下需要我们重启主机 1 /etc/in

TCP/IP协议--TIME_WAIT状态存在的原因

1. 实际问题         初步查看发现,无法对外新建TCP连接时,线上服务器存在大量处于TIME_WAIT状态的TCP连接(最多的一次为单机10w+,其中引起报警的那个模块产生的TIME_WAIT约2w),导致其无法跟下游模块建立新TCP连接. TIME_WAIT涉及到TCP释放连接过程中的状态迁移,也涉及到具体的socket api对TCP状态的影响,下面开始逐步介绍这些概念. 2. TCP状态迁移        面向连接的TCP协议要求每次peer间通信前建立一条TCP连接,该连接可抽

SOCKS5 协议解析

意图 SOCKS5 是一个代理协议,旨在为位于 Intranet 防火墙后的用户提供访问 Internet 的代理服务(Intranet,你没听错,这是个有一定年头的协议,其 RFC 提案的时间比 HTTP 1.0 还要早两个月). 代理 根据 HTTP 1.1 的定义,proxy 是: An intermediary program which acts as both a server and a client for the purpose of making requests on be

Consul:Gossip协议

Consul使用gossip协议来管理成员和广播消息到集群.所有这些都是通过使用Serf库提供的.Serf使用的gossip协议基于“SWIM: Scalable Weakly-consistent Infection-style Process Group Membership Protocol”,有一些小的修改.更多关于Serf的协议细节见此文档. Consul中的Gossip Consul使用两个不同的gossip池.我们分别称为LAN和WAN池.每个数据中心有一个LAN gossip池,

adb概览及协议參考

原文:https://github.com/android/platform_system_core/blob/master/adb/OVERVIEW.TXT) Implementation notes regarding ADB. ADB实现注解 1. General Overview: 1概要 The Android Debug Bridge (ADB) is used to: ADB在下面情况下使用: keep track of all Android devices and emulat

聊聊HTTPS和SSL/TLS协议

原文地址:http://www.techug.com/https-ssl-tls 要说清楚 HTTPS 协议的实现原理,至少需要如下几个背景知识.1. 大致了解几个基本术语(HTTPS.SSL.TLS)的含义2. 大致了解 HTTP 和 TCP 的关系(尤其是“短连接”VS“长连接”)3. 大致了解加密算法的概念(尤其是“对称加密与非对称加密”的区别)4. 大致了解 CA 证书的用途 考虑到很多技术菜鸟可能不了解上述背景,俺先用最简短的文字描述一下.如果你自认为不是菜鸟,请略过本章节,直接去看“

浅谈 HTTPS 和 SSL/TLS 协议的背景与基础

相关背景知识 要说清楚 HTTPS 协议的实现原理,至少需要如下几个背景知识. 大致了解几个基本术语(HTTPS.SSL.TLS)的含义 大致了解 HTTP 和 TCP 的关系(尤其是"短连接"VS"长连接") 大致了解加密算法的概念(尤其是"对称加密与非对称加密"的区别) 大致了解 CA 证书的用途 考虑到很多技术菜鸟可能不了解上述背景,俺先用最简短的文字描述一下.如果你自认为不是菜鸟,请略过本章节,直接去看"HTTPS 协议的需求&

HTTPS协议的实现原理

要说清楚 HTTPS 协议的实现原理,至少需要如下几个背景知识.1. 大致了解几个基本术语(HTTPS.SSL.TLS)的含义2. 大致了解 HTTP 和 TCP 的关系(尤其是“短连接”VS“长连接”)3. 大致了解加密算法的概念(尤其是“对称加密与非对称加密”的区别)4. 大致了解 CA 证书的用途 考虑到很多技术菜鸟可能不了解上述背景,俺先用最简短的文字描述一下.如果你自认为不是菜鸟,请略过本章节,直接去看“HTTPS 协议的需求”. 先澄清几个术语——HTTPS.SSL.TLS 1. “