【转】HTTP协议详解

HTTP--Hyper Text Transfer Protocol,超文本传输协议,是一种建立在TCP上的无状态连接,整个基本的工作流程是客户端发送一个HTTP请求,说明客户端想要访问的资源和请求的动作,服务端收到请求之后,服务端开始处理请求,并根据请求做出相应的动作访问服务器资源,最后通过发送HTTP响应把结果返回给客户端。其中一个请求的开始到一个响应的结束称为事务,当一个事物结束后还会在服务端添加一条日志条目。


目录

  • HTTP请求

  • HTTP响应

  • HTTP报文格式

  • HTTP协议版本更替

  • 网站访问量


一、HTTP请求

HTTP请求是客户端往服务端发送请求动作,告知服务器自己的要求。

HTTP请求由状态行、请求头、请求正文三部分组成:

状态行:包括请求方式Method、资源路径URL、协议版本Version;

请求头:包括一些访问的域名、用户代理、Cookie等信息;

请求正文:就是HTTP请求的数据。

    备注:请求方式Method一般有GET、POST、PUT、DELETE,含义分别是获取、修改、上传、删除,其中GET方式仅仅为获取服务器资源,方式较为简单,因此在请求方式为GET的HTTP请求数据中,请求正文部分可以省略,直接将想要获取的资源添加到URL中。下图所示就是GET的请求,没有请求正文。详细的说明在下边。

现在大多数协议版本为http/1.1

blob.png

下图所示为POST请求的格式,有状态行、请求头、请求正文三部分。

blob.png

二、 HTTP响应

2.1 响应数据格式

服务器收到了客户端发来的HTTP请求后,根据HTTP请求中的动作要求,服务端做出具体的动作,将结果回应给客户端,称为HTTP响应。

    HTTP响应由三部分组成:状态行、响应头、响应正文;

状态行:包括协议版本Version、状态码Status Code、回应短语;

响应头:包括搭建服务器的软件,发送响应的时间,回应数据的格式等信息;

响应正文:就是响应的具体数据。

    备注:我们主要关心并且能够在客户端浏览器看得到的是三位数的状态码,不同的状态码代表不同的含义,其中

| 1xx | 表示HTTP请求已经接受,继续处理请求 |
| 2xx | 表示HTTP请求已经处理完成 |
| 3xx | 表示把请求访问的URL重定向到其他目录 |
| 4xx | 表示客户端出现错误 |
| 5xx | 表示服务端出现错误 |

具体HTTP响应实例如下图:

blob.png

2.2 常见状态码的含义

    200---OK/请求已经正常处理完毕

    301---/请求永久重定向

    302---/请求临时重定向

    304---/请求被重定向到客户端本地缓存

    400---/客户端请求存在语法错误

    401---/客户端请求没有经过授权

    403---/客户端的请求被服务器拒绝,一般为客户端没有访问权限

    404---/客户端请求的URL在服务端不存在

    500---/服务端永久错误

    503---/服务端发生临时错误

2.3 HTTP响应模型

    服务器收到HTTP请求之后,会有多种方法响应这个请求,下面是HTTP响应的四种模型:

单进程I/O模型

服务端开启一个进程,一个进程仅能处理一个请求,并且对请求顺序处理;

多进程I/O模型

服务端并行开启多个进程,同样的一个进程只能处理一个请求,这样服务端就可以同时处理多个请求;

复用I/O模型

服务端开启一个进程,但是呢,同时开启多个线程,一个线程响应一个请求,同样可以达到同时处理多个请求,线程间并发执行;

复用多线程I/O模型

服务端并行开启多个进程,同时每个进程开启多个线程,这样服务端可以同时处理进程数M*每个进程的线程数N个请求。


三、HTTP报文格式

    HTTP报文是HTTP应用程序之间传输的数据块,HTTP报文分为HTTP请求报文和HTTP响应报文,但是无论哪种报文,他的整体格式是类似的,大致都是由起始、首部、主体三部分组成,起始说明报文的动作,首部说明报文的属性,主体则是报文的数据。接下来具体说明。

3.1 HTTP请求报文

blob.png
    请求报文的起始由请求行构成(有些资料称为状态行,名字不一样而已,都是指的一个东西),用来说明该请求想要做什么,由<Method>、<URL>、<Version> 三个字段组成,注意每个字段之间都有一个空格。

    其中<Method>字段有不同的值:

GET --- 访问服务器的资源

POST --- 向服务器发送要修改的数据

HEAD --- 获取服务器文档的首部

            PUT   --- 向服务器上传资源

            DELETE--- 删除服务器的资源

<URL>字段表示服务器的资源目录定位

<Version>字段表示使用的http协议版本

首部部分由多个请求头(也叫首部行)构成,那些首部字段名有如下,不全:

            Accept     指定客户端能够接收的内容格式类型

Accept-Language 指定客户端能够接受的语言类型

Accept-Ecoding 指定客户端能够接受的编码类型

User-Agent 用户代理,向服务器说明自己的操作系统、浏览器等信息

Connection 是否开启持久连接(keepalive)

Host 服务器域名

...

    主体部分就是报文的具体数据。                      

3.2 HTTP响应报文

blob.png
    响应报文的起始由状态行构成,用来说明服务器做了什么,由<Version>、<Status-Code>、<Phrase>三个字段组成,同样的每个字段之间留有空格;

    <Status-Code> 上边已经说明; 

    首部由多个响应头(也叫首部行)组成, 首部字段名如下,不全:

            Server    服务器软件名,Apache/Nginx

            Date      服务器发出响应报文的时间

            Last-Modified   请求资源的最后的修改时间

            ...

主体部分是响应报文的具体数据。

小tips:关于更多请求头和响应头(即首部字段名)的说明请参考http://tools.jb51.net/table/http_header


四、 HTTP协议版本更替

HTTP/0.9

    HTTP协议的最初版本,功能简陋,仅支持请求方式GET,并且仅能请求访问HTML格式的资源。

HTTP/1.0

    在0.9版本上做了进步,增加了请求方式POST和HEAD;不再局限于0.9版本的HTML格式,根据Content-Type可以支持多种数据格式,即MIME多用途互联网邮件扩展,例如text/html、image/jpeg等;同时也开始支持cache,就是当客户端在规定时间内访问统一网站,直接访问cache即可。

但是1.0版本的工作方式是每次TCP连接只能发送一个请求,当服务器响应后就会关闭这次连接,下一个请求需要再次建立TCP连接,就是不支持keepalive。

HTTP/1.1

    解决了1.0版本的keepalive问题,1.1版本加入了持久连接,一个TCP连接可以允许多个HTTP请求; 加入了管道机制,一个TCP连接同时允许多个请求同时发送,增加了并发性;新增了请求方式PUT、PATCH、DELETE等。

    但是还存在一些问题,服务端是按队列顺序处理请求的,假如一个请求处理时间很长,则会导致后边的请求无法处理,这样就造成了队头阻塞的问题;同时HTTP是无状态的连接,因此每次请求都需要添加重复的字段,降低了带宽的利用率。

HTTP/2.0

为了解决1.1版本利用率不高的问题,提出了HTTP/2.0版本。增加双工模式,即不仅客户端能够同时发送多个请求,服务端也能同时处理多个请求,解决了队头堵塞的问题;HTTP请求和响应中,状态行和请求/响应头都是些信息字段,并没有真正的数据,因此在2.0版本中将所有的信息字段建立一张表,为表中的每个字段建立索引,客户端和服务端共同使用这个表,他们之间就以索引号来表示信息字段,这样就避免了1.0旧版本的重复繁琐的字段,并以压缩的方式传输,提高利用率。

另外也增加服务器推送的功能,即不经请求服务端主动向客户端发送数据。

当前主流的协议版本还是HTTP/1.1版本。


五、 网站访问量

    IP IP访问量

相同的公网IP计算一次,就是同一个局域网内的所有用户访问一个网站,但是他们都是借助一个公网IP去访问那个网站的(NAT),因此这也只能算作一个IP访问量。换一次公网IP则会加1。

    PV 网页访问量

用户访问的页面数就是PV访问量,同一个局域网的不同用户,而且就算是同一个用户,只要刷新一次网站页面,PV访问量就加1,三个访问量的值往往数PV的值最大。

    UV 访客访问量

这里的访客不是用户,而是电脑,一台电脑算一个访客,即使是同一台电脑的不同用户,访问同一个网站UV也只能加1,只有更换电脑才会使UV加1,因为服务端会记录客户端电脑的信息。

本文为转载,只做知识记录。点击阅读原文

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,098评论 5 476
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,213评论 2 380
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 149,960评论 0 336
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,519评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,512评论 5 364
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,533评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,914评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,574评论 0 256
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,804评论 1 296
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,563评论 2 319
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,644评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,350评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,933评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,908评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,146评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,847评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,361评论 2 342

推荐阅读更多精彩内容

  • Spring Cloud为开发人员提供了快速构建分布式系统中一些常见模式的工具(例如配置管理,服务发现,断路器,智...
    卡卡罗2017阅读 134,580评论 18 139
  • 一、概念(载录于:http://www.cnblogs.com/EricaMIN1987_IT/p/3837436...
    yuantao123434阅读 8,326评论 6 152
  • 作者:涤生_Woo链接:https://www.jianshu.com/p/6e9e4156ece3 本篇文章篇幅...
    Fi的学习笔记阅读 1,691评论 0 4
  • HTTP协议详解 当今web程序的开发技术真是百家争鸣,ASP.NET, PHP, JSP,Perl, AJAX ...
    拉肚阅读 261评论 0 3
  • 秋天,我不愿意走进去 就像我不愿意走进这样的夜里 我不想被空虚抓住,把生命挂在时钟的秒针上 一个生命或者一段爱情,...
    马骥北阅读 2,808评论 50 86