HTTP2.0协议中英文对照版

合集下载

http协议请求响应报文格式及状态码详解

http协议请求响应报文格式及状态码详解

HTTP协议报文格式

HTTP协议(Hypertext Transfer Protocol――超文本传输协议)浏览器端(客户端)向WEB 服务器端访问页面的过程和HTTP协议报文的格式。

基于HTTP协议的客户机访问包括4个过程,分别是建立TCP套接字连接、发送HTTP请求报文、接收HTTP应答报文和关闭TCP套接字连接:

1. 创建TCP套接字连接

客户端与WEB服务器创建TCP套接字连接,其中WEB端服务器的地址可以通过域名解析确定,WEB端的套接字侦听端口一般是80。

2. 发送HTTP请求报文

客户端向WEB服务端发送请求报文,HTTP协议的请求报文格式为:

请求消息= 请求行(实体头信息)CRLF[实体内容]

请求行= 方法URL HTTP版本号CRLF

方法= GET|HEAD|POST|扩展方法

URL = 协议名称+宿主名+目录与文件名

其中"CRLF"表示回车换行。

"请求行"中的"方法"描述了对指定资源执行的动作,常用的方法"GET"、"HEAD"和"POST"等3种,它们的含义如表15-8所示:

请求报文

一个HTTP请求报文由请求行(request line)、请求头部(header)、空行和请求数据4个部分组成,下图给出了请求报文的一般格式。

(1)请求行

请求行由请求方法字段、URL字段和HTTP协议版本字段3个字段组成,它们用空格分隔。例如,GET /index.html HTTP/1.1。

HTTP协议的请求方法有GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT。这里介绍最常用的GET方法和POST方法。

OAuth2.0中文译本

OAuth2.0中文译本

OAuth‎ 2.0中文译本‎

(一)背景知识

OAuth‎2.0很可能是‎下一代的“用户验证和‎授权”标准,目前在国内‎还没有很靠‎谱的技术资‎料。为了弘扬“开放精神”,让业内的人‎更容易理解‎“开放平台”相关技术,进而长远地‎促进国内开‎放平台领域‎的发展,笔者特意将‎O Auth‎2.0协议翻译‎成中文。

目前OAu‎t h 2.0还没有最‎后定稿,最新的修改‎版是第11‎个版本,本文下面的‎翻译即基于‎这个第11‎版本。原文见http://tools‎/html/draft‎-ietf-oauth‎-v2-11。

关于OAu‎t h 2.0的更多背‎景知识,请参考我的‎另一篇文章‎:

http://itgee‎k /mathm‎l/readp‎a per?pid=65

(二)术语中英对‎照表

由于OAu‎t h协议版‎本较多(1.0,1.0a,2.0等),并且各个版‎本中的技术‎术语也各不‎相同,关于英文技‎术术语与中‎文的对应关‎系,我们以OA‎u th 2.0的第11‎版本中的描‎述为准。

另外有一些‎情况,一些英文术‎语不容易找‎到普遍接受‎的汉语释义‎,翻译过来反‎而可能引起‎误解,而英文术语‎本身可能更‎容易理解,因此就不考‎虑对这部分‎词汇做翻译‎了。比如,“web‎servi‎c e”、“endpo‎i nt”、“user-agent‎”、“URI”、“cooki‎e”等,你只需要知‎道它是什么‎就好了。

还有一些特‎别难于翻译‎的词汇,比如“profi‎l e”,这个词用在‎协议里,大概表示:协议功能的‎某个剖面、子集、子视图或轮‎廓。如果翻译成‎“视图”,容易让人想‎到“view”这个词,产生冲突,最后,我在这里创‎造了一个新‎词汇:“子态”。

thrift是rpc协议

thrift是rpc协议

thrift是rpc协议

PC(Remote Procedure Call,远程过程调⽤)是建⽴在Socket之上的,出于⼀种类⽐的愿望,在⼀台机器上运⾏的主程序,可以调⽤另⼀台机器上准备好的⼦程序,就像LPC(本地过程调⽤).

越底层,代码越复杂、灵活性越⾼、效率越⾼;越上层,抽象封装的越好、代码越简单、效率越差。Socket和RPC的区别再次说明了这点。

PC(Remote Procedure Call,远程过程调⽤)是建⽴在Socket之上的,出于⼀种类⽐的愿望,在⼀台机器上运⾏的主程序,可以调⽤另⼀台机器上准备好的⼦程序,就像 LPC(本地过程调⽤).RPC带来了开发C/S程序的简单可靠的⼿段,它通过⼀种叫XDR的数据表达⽅法描述数据,程序员书写伪代码,然后由 rpcgen程序翻译为真正的可编译的C语⾔源代码,再编译成真正的Client端和Server端程序。

RPC作为普遍的C/S开发⽅法,开发效率⾼效,可靠.但RPC⽅法的基本原则是--以模块调⽤的简单性忽略通讯的具体细节,以便程序员不⽤关⼼C/S之间的通讯协议,集中精⼒对付实现过程.这就决定了 RPC⽣成的通讯包不可能对每种应⽤都有最恰当的处理办法,与Socket⽅法相⽐,传输相同的有效数据,RPC占⽤更多的⽹络带宽.

RPC是在Socket的基础上实现的,它⽐socket需要更多的⽹络和系统资源.另外,在对程序优化时,程序员虽然可以直接修改由rpcgen产⽣的令⼈费解的源程序,但对于追求程序设计⾼效率的RPC⽽⾔,获得的简单性则被⼤⼤削弱.

http各个版本(11.12)对比

http各个版本(11.12)对比

http 各个版本(11.12)对⽐

⽬录:

参考的⽂章:

http1.1 长连接

HTTP1.1默认使⽤长连接,可有效减少TCP 的三次握⼿开销。

HTTP 1.0规定浏览器与服务器只保持短暂的连接,浏览器的每次请求都需要与服务器建⽴⼀个TCP 连接,服务器完成请求处理后⽴即断开TCP 连接

当⼀个⽹页⽂件中包含了很多图像的地址的时候,那就需要很多次的http 请求和响应,每次请求和响应都需要⼀个单独的连接,每次连接只是传输⼀个⽂档和图像,上⼀次和下⼀次请求完全分离。即使图像⽂件都很⼩,但是客户端和服务器端每次建⽴和关闭连接却是⼀个相对⽐较费时的过程,并且会严重影响客户机和服务器的性能。当⼀个⽹页⽂件中包含JavaScript ⽂件,CSS ⽂件等内容时,也会出现类似上述的情况。

为了克服HTTP 1.0的这个缺陷,HTTP 1.1⽀持持久连接(HTTP/1.1的默认模式使⽤带流⽔线的持久连接),在⼀个TCP 连接上可以传送多个HTTP 请求和响应,减少了建⽴和关闭连接的消耗和延迟。⼀个包含有许多图像的⽹页⽂件的多个请求和应答可以在⼀个连接中传输,但每个单独的⽹页⽂件的请求和应答仍然需要使⽤各⾃的连接。

HTTP 1.1还允许客户端不⽤等待上⼀次请求结果返回,就可以发出下⼀次请求,但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果,以保证客户端能够区分出每次请求的响应内容,这样也显著地减少了整个下载过程所需要的时间。

通过请求头中connection 字段在表明是否⽀持长链接

在http1.1中,client 和server 都是默认对⽅⽀持长链接的(即connection 的值默认我Keep-Alive), 如果client 使⽤http1.1协议,但⼜不希望使⽤长链接,则需要在header 中指明connection 的值为closer(connection 默认为Keep-Alive);如果server ⽅也不想⽀持长链接,则在response 中也需要明确说明connection 的值为closer 。不论request 还是response 的header 中包含了值为closer 的connection ,都表明当前正在使⽤的tcp 链接在当天请求处理完毕后会被断掉。以后client 再进⾏新的请求时就必须创建新的tcp 链接了。

grpc protobuf序列化协议

grpc protobuf序列化协议

gRPC使用Protobuf序列化协议。

Protobuf即Protocol Buffers,是Google公司开发的一种跨语言和平台的序列化数据结构的方式,是一个灵活的、高效的用于序列化数据的协议。与XML和JSON格式相比,protobuf更小、更快、更便捷。protobuf是跨语言的,并且自带一个编译器(protoc),只需要用protoc进行编译,就可以编译成Java、Python、C++、C#、Go等多种语言代码,然后可以直接使用,不需要再写其它代码,自带有解析的代码。只需要将要被序列化的结构化数据定义一次(在.proto文件定义),便可以使用特别生成的源代码(使用protobuf提供的生成工具)轻松的使用不同的数据流完成对结构数据的读写操作。

gRPC使用http2.0协议,http2.0相比于HTTP 1.x,大幅度的提升了web 性能。gRPC使用protobuf定义服务,然后使用这个文件来生成客户端和服务端的代码。因为pb是跨语言的,因此即使服务端和客户端语言并不一致也是可以互相序列化和反序列化的。

【HTTP】一、HTTP协议简介及其工作流程

【HTTP】一、HTTP协议简介及其工作流程

【HTTP】⼀、HTTP协议简介及其⼯作流程

协议是指计算机通信⽹络中两台计算机之间进⾏通信所必须共同遵守的规定或规则,超⽂本传输协议(HTTP)是⼀种通信协议,它允许将超⽂本标记语⾔(HTML)⽂档从Web服务器传送到客户端的浏览器。

(⼀)HTTP协议简介

HTTP(超⽂本传输协议)是⼀个应⽤层协议,它是互联⽹的⼀个基础协议,它规定了浏览器如何向万维⽹服务器请求万维⽹⽂档、服务器如何把⽂档传给浏览器。HTTP是⾯向事务的应⽤层协议,它是万维⽹可以进⾏可靠⽂件交换的重要基础。对于技术岗位的程序员来说理解掌握HTTP协议是必须的。

1、万维⽹概述

万维⽹实际上我们并不陌⽣,实际它并不是⼀个⽹络,⽽是⼀个⼤规模的、联机式的信息储藏所,是⼀个分布式的超媒体系统。⼀个超⽂本由多个信息源链接⽽成。利⽤⼀个链接可使⽤户找到另⼀个⽂档。这些⽂档可以位于世界上任何⼀个接在因特⽹上的超⽂本系统中。超⽂本是万维⽹的基础。

万维⽹以客户-服务器⽅式⼯作。客户程序就是⽤户计算机上的各种浏览器,万维⽹⽂档所驻留的机器就成为服务器,客户程序向服务器程序发出请求,服务器程序向客户程序送回客户所要的万维⽹⽂档。

万维⽹必须解决的⼏个问题:

为了标志分布在整个因特⽹上的万维⽹⽂档,使⽤了统⼀资源定位符URL。每⼀个⽂档在整个因特⽹的范围内具有唯⼀的标识符 URL。

为了实现万维⽹上各种超链之间的链接,使⽤了HTTP协议。

为了使各种万维⽹⽂档都能在因特⽹上的各种计算机上显⽰出来,使⽤了浏览器和HTML语⾔。

2、HTTP的版本演变

HTTP与HTTPS知识点详解

HTTP与HTTPS知识点详解

HTTP与HTTPS知识点详解

⼀、TCP/UDP

1.1、TCP

TCP(Transmission Control Protocol:传输控制协议)是⼀种⾯向连接的、可靠的、基于字节流的传输层通信协议。

TCP的主要特点有:

基于流的⽅式

⾯向连接

可靠通信⽅式

⽀持错误重传⽅式

⽀持拥塞控制,能够在⽹络拥堵的情况下延迟发送

提供错误校验和,甄别有害的数据包

1.2、UDP

UDP(User Datagram Protocol:⽤户数据报协议),为应⽤程序提供了⼀种⽆需建⽴连接就可以发送封装的IP数据包的⽅法。⽆需建⽴连接,即不需要所谓的握⼿操作,从⽽加快了通信速度,允许⽹络上的其他主机在接收⽅同意通信之前进⾏数据传输。

数据报是与分组交换⽹络关联的传输单元

UDP的特点:

可以发送⼤量的数据包(因为不建⽴连接,也就不需要维护连接窗台,包括收发状态等,因此⼀台服务机可同时向多个客户机传输相同的消息)

尽最⼤努⼒交付,不保证可靠交付

⾯向报⽂的

没有拥塞控制,⽹络出现的拥塞不会使源主机的发送速率降低

⽀持⼀对⼀、⼀对多、多对⼀、多对多的交互通信

UDP的⾸部开销⼩,只有8个字节,⽐TCP得0个字节⾸部要短

1.3、TCP和UDP的不同

TCP UDP

TCP⾯向连接(TCP在发送数据前需要先建⽴连接,然后再发送数据,并且有发送确认)UDP⾯向⽆连接(UDP⽆需建⽴连接就可以发送⼤量数据,并且没有发送确认)TCP⾯向字节流UDP⾯向报⽂

TCP头部字节20字节UDP头部字节只有8字节

TCP会按照特定顺序重新排列数据包UDP数据包没有固定顺序,所有数据包都相互独⽴

Http协议规范

Http协议规范

Http协议规范

协议名称:HTTP协议规范

背景介绍:

HTTP(Hypertext Transfer Protocol)是一种用于传输超文本的应用层协议。它是Web应用中最重要的协议之一,用于客户端和服务器之间的通信。HTTP协议规范定义了请求和响应的格式、状态码、头部字段以及其他相关细节,确保了互联网上的信息交换的顺利进行。

一、协议版本

HTTP协议目前有多个版本,包括HTTP/1.0、HTTP/1.1和HTTP/2等。本协议遵循HTTP/1.1版本。

二、请求格式

1. 请求行:

请求行由请求方法、请求URI和协议版本组成,格式如下:

```

请求方法请求URI 协议版本

```

示例:GET /index.html HTTP/1.1

2. 请求头部:

请求头部包含了请求的附加信息,格式为键值对,每个键值对占一行,以冒号分隔,示例如下:

```

键: 值

```

常见的请求头部字段有:

- Host:指定请求的主机名和端口号

- User-Agent:发送请求的用户代理信息

- Accept:指定客户端可接受的MIME类型

- Content-Type:指定请求体的MIME类型

- Cookie:包含了客户端的Cookie信息

3. 请求体:

请求体是可选的,用于传输请求的数据,例如表单数据或上传的文件等。

三、响应格式

1. 状态行:

状态行由协议版本、状态码和状态描述组成,格式如下:

```

协议版本状态码状态描述

```

示例:HTTP/1.1 200 OK

2. 响应头部:

响应头部包含了响应的附加信息,格式同请求头部。

3. 响应体:

HTTP2.0学习与Nginx和Tomcat配置HTTP2.0

HTTP2.0学习与Nginx和Tomcat配置HTTP2.0

HTTP2.0学习与Nginx和Tomcat配置HTTP2.0

⽬录

⼀、HTTP2.0

1.1 简介

1.2 新的特性

1.3 h2c 的⽀持度

⼆、Nginx 对 http2.0 的⽀持

2.1 Nginx 作为服务端使⽤http2.0

2.2 Nginx 作为客户端使⽤ http2.0

三、Tomcat 对 HTTP2.0 的⽀持

3.1.1、依赖环境

3.1.2、h2c 配置(⾮加密)

3.1.3、h2 配置(加密)

3.1 、Tomcat 8.5

四、扩展

问题

解决

⽅法⼀(没⾏通)

⽅法⼆(可⾏)

4.1、测试 h2c

4.2、查看浏览器是否⽀持 http2.0

4.3、查看⽹站是否⽀持 http2.0

4.4、JAVA8 如何⽀持 HTTP2.0 TLS

⼀、HTTP2.0

1.1 简介

HTTP/2(超⽂本传输协议第2版,最初命名为HTTP 2.0),简称为h2(基于TLS/1.2或以上版本的加密连接)或h2c(⾮加密连接),是HTTP协议的的第⼆个主要版本。

1.2 新的特性

具体可以看这篇⽂章:https:///a/1190000013420784

1. 头数据压缩 Data compression of HTTP headers

2. 服务器推送 HTTP/2 Server Push

3. 管线化请求 Pipelining of requests.

4. 对数据传输采⽤多路复⽤,让多个请求合并在同⼀ TCP 连接内 Multiplexing multiple requests over a single TCP connection,因为每⼀个tcp 连接在创建的时候都需要耗费资源,⽽且在创建初期,传输也是⽐较

Http2概述

Http2概述

2.4、HTTP/2协议——多路复用
HTTP/1.1 client open server client open HTTP/1.1 pipelining server client open HTTP/1.1 线头阻塞 server client open HTTP/2 多路复用 server
close
• 状态码 Control 头部字段名 : 值 回车符 换行符 灵活 Accept 怎么传输? • 1xx:信息(请求已接受) HTTP Accept• 2xx:成功 保证安全? HTTPS … Charset 请求头 • 3xx:重定向 HTTP User-Agent • 4xx: 客户端错误 Authorization 头部字段名 : 值 回车符 换行符 Host • 5xx:服务端错误 (特殊的URI) …… • 状态描述 空行 怎么显示?回车符 换行符 HTML • 响应头 • 空行 请求数据 请求数据 4 • 响应正文 3
HTTP/1.1
POST /upload HTTP/1.1 Host: www.xwood.net Content-Type: application/json Content-Length:15 {“msg”:”hello”}
应用层(HTTP/2)
二进制帧(Frame)
TLS(可选)
传输层(TCP)
HPACK

http是一种什么传输协议

http是一种什么传输协议

竭诚为您提供优质文档/双击可除http是一种什么传输协议

篇一:http协议详解

ttp协议是互联网的基础协议,也是网页开发的必备知识,最新版本http/2更是让它成为技术热点。

一、http/0.9

http是基于tcp/ip协议的应用层协议。它不涉及数据包(packet)传输,主要规定了客户端和服务器之间的通信格式,默认使用80端口。

最早版本是1991年发布的0.9版。该版本极其简单,只有一个命令get。get/index.html

上面命令表示,tcp连接(connection)建立后,客户端向服务器请求(request)网页index.html。

协议规定,服务器只能回应html格式的字符串,不能回应别的格式。helloworld

服务器发送完毕,就关闭tcp连接。

二、http/1.0

2.1简介

1996年5月,http/1.0版本发布,内容大大增加。

首先,任何格式的内容都可以发送。这使得互联网不仅可以传输文字,还能传输图像、视频、二进制文件。这为互联网的大发展奠定了基础。

其次,除了get命令,还引入了post命令和head命令,丰富了浏览器与服务器的互动手段。

再次,http请求和回应的格式也变了。除了数据部分,每次通信都必须包括头信息(httpheader),用来描述一些元数据。

其他的新增功能还包括状态码(statuscode)、多字符集支持、多部分发送(multi-parttype)、权限(authorization)、缓存(cache)、内容编码(contentencoding)等。

ONVIF2.0中文协议原版

ONVIF2.0中文协议原版

ONVIF2.0中文协议原版

1 范围 (17)

2 引用标准 (20)

3 术语与定义 (27)

3.1定义 (27)

3.2缩写 (31)

4 概述 (38)

4.1W EB 服务 (39)

4.2IP配置 (41)

4.3设备发现 (41)

4.4设备类型 (42)

4.5设备管理 (43)

4.5.1 功能 (43)

4.5.2 网络 (45)

4.5.3 系统 (45)

4.5.4 系统信息检索 (46)

4.5.5 固件升级 (46)

4.5.6 系统还原 (47)

4.5.7 安全 (47)

4.6设备IO (47)

4.7图像配置 (49)

4.8媒体配置 (50)

4.8.1 媒体配置文件 (50)

4.9实时流 (56)

4.10事件处理 (58)

4.11PTZ控制 (58)

4.12视频分析 (60)

4.13分析设备 (63)

4.14显示 (64)

4.15接收器 (65)

4.15.1 同步点 (66)

4.16存储 (66)

4.16.1 存储模式 (67)

4.16.2 记录 (69)

4.16.3 查找 (70)

4.16.4 回放 (72)

4.17安全 (72)

5 WEB服务框架 (74)

5.1服务概述 (75)

5.1.1 服务要求 (76)

5.2WSDL概述 (77)

5.3命名空间 (78)

5.4类型 (91)

5.5消息 (92)

5.6操作 (93)

5.6.1 单向操作 (95)

5.6.2 要求-应答操作类型 (96)

5.7端口类型 (98)

5.8绑定 (98)

5.9端口 (99)

5.10服务 (99)

5.11错误处理 (99)

HTTP协议详解及http1.0与http1.1http2.0的区别

HTTP协议详解及http1.0与http1.1http2.0的区别

HTTP协议详解及http1.0与http1.1http2.0的区别

HTTP协议介绍

http(超⽂本传输协议)是⼀个属于应⽤层的⾯向对象的协议,由于其简捷、快速的⽅式,适⽤于分布式超媒体信息系统。特点:

(1)⽀持客户/服务器模式。 HTTP是⼀个客户端和服务器端请求和应答的标准(TCP)。客户端是终端⽤户,服务器端是⽹站。通过使⽤、或者其它的⼯具,客户端发起⼀个到服务器上指定端⼝(默认为80)的HTTP请求。称这个客户端叫⽤户代理。服务器则在那个端⼝监听客户端发送过来的请求。应答的服务器上存储着(⼀些)资源,⽐如HTML⽂件和图像。称这个应答服务器为源服务器。⼀旦收到请求,服务器(向客户端)发回⼀个状态⾏,⽐如"HTTP/1.1 200 OK",和(响应的)消息,其消息体即为服务器上的资源。HTTP使⽤TCP ⽽不是UDP的原因在于(打开)⼀个⽹页必须传送很多数据,⽽TCP协议提供传输控制,按顺序组织数据,和错误纠正。

(2)简单快捷。 客户向服务器请求服务时,只需传送请求⽅法和路径。请求⽅法常⽤的有GET、HEAD、POST。每种⽅法规定了客户与服务器联系的类型不同。由于HTTP协议简单,使得HTTP服务器的程序规模⼩,因⽽通信速度很快。

(3)灵活。 HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。

(4)⽆连接。 意思限制每次连接只处理⼀个请求。服务器处理完客户的请求,并收到客户的应答后,即断开连接。采⽤这种⽅式可以节省传输时间。

(5)⽆状态。 HTTP协议是⽆状态协议。⽆状态是指协议对于事务处理没有记忆能⼒。缺少状态意味着如果后续处理需要前⾯的信息,则它必须重传,这样可能导致每次连接传送的数据量增⼤。另⼀⽅⾯,在服务器不需要先前信息时它的应答就较快。

CAS协议介绍

CAS协议介绍

CAS 协议介绍中创软件商用中间件有限公司

CAS 协议介绍前言本文是 CAS 协议规范的中文译文。I

CAS 协议介绍1.Introduction以下是 CAS1.0 和 2.0 协议的官方规范。 注:CAS1.0 和 2.0 协议大体包含两个方面的内容:各种票根(Ticket)和暴露给 CAS 客 户的 HTTP(S)URL。这些 UPL(/login、/logout、/validate、/serviceValidate、/proxy、 /proxyValidate 等)围绕着这些票根(ST、TGC、PGT、PT 等)进行活动。在此期间服 务和终端服务之间会进行多次 HTTPS 交互。Conventions & Definitions(公约和定义)    “Client” 指的是终端用户或者是 WEB 浏览器。 “Server”指的是统一认证服务所在的服务器。 “Service” 指的是终端用户或者 WEB 浏览器试图访问的应用. “Back-end service”是指一个服务试图代表一个 client 去访问一个应用,这个应 用就被称为终端服务(Back-end service) 。它也被称作“target service”目标 服务。 注:这里的 service 可以包含两部分,一是应用程序本身提供的 service;二是应用程序 本身还可提供代理服务,使 Client 能够通过它的代理功能访问终端服务。 按照翻译,不容易理解“终端服务”,通过下面的图可以很容易看清楚它的作用。 黄色区域指 Client;绿色区域指 Server;紫色区域指 Service;蓝色区域指终端服务。其 中 CAS1.0 中没有终端服务这一块,也没有 Service 的 proxy,也即不能进行代理认证。2

Web基础与HTTP协议

Web基础与HTTP协议

Web基础与HTTP协议

⽬录

DNS与域名

域名

⽹页

Web

HTTP协议概述

⼀、DNS与域名

1、⽹络是基于 TCP/IP 协议进⾏通信和连接的,每⼀台主机都有⼀个唯⼀的标识(固定的 IP 地址),⽤以区别在⽹络上成千上万个⽤户和计算机。⽹络在区分所有与之相连的⽹络和主机时,均采⽤⼀种唯⼀、通⽤的地址格式,即每⼀个与⽹络相连接的计算机和服务器都被指派⼀个独⼀⽆⼆的地址

七层参考模型和五层,逻辑⽹卡(IP地址)和物理⽹卡(MAC地址) bond

2、为了保证⽹络上每台计算机的 IP 地址的唯⼀性,⽤户必须向特定机构申请注册,分配 IP 地址

⽹络中的地址⽅案分为两套:IP 地址系统和域名地址系统。这两套地址系统其实是⼀⼀对应的关系

由于 IP 地址是数字标识,使⽤时难以记忆和书写,因此在IP 地址的基础上⼜发展出⼀种符号化的地址⽅案,来代替数字型的 IP 地址

⼩结:

1、⽹络上交互是基于TCP/IP协议的,每个主机在逻辑上有⼀个唯⼀位置标识(IP地址),物理地址为MAC地址

2、为了保证地址唯⼀性,⽤户协议向特地给机构申请注册,分配IP地址⽹络中的地址有两套⽅案:

① IP地址系统

②域名地址系统

⽽由于IP是由32位⼆进制数字标识,不⽅便记忆,所以以IP地址为基础发展出了符号化地址来代替解决⽅案,也是是域名

3、DNS 解析

DNS解析⽅式,三种:

① /etc/hosts

linux系统中负责快速解析的⽂件,包含了ip与主机名的映射关系,在没有DNS服务器的情况下,使⽤本地/etc/hosts完成解析/映射,实现快速访问

HTTP协议

HTTP协议

HTTP协议

HTTP协议简介

HTTP协议请求Request

HTTP协议响应Response

HTTP协议完整⼯作流程

HTTP协议总结

HTTP协议简介

学习前端开发之前先了解⼀下⼏件事

1.什么是互联⽹

互联⽹就是物理连接介质+互联⽹协议

2.建⽴互联⽹的⽬的

使数据传输打破地域限制

3.什么是上⽹

上⽹就是过程就是浏览器像服务端发送请求,然后将服务端⽂件下载到本地显⽰,⽽浏览器与服务端就是遵循的HTTP协议。

1、HTTP协议:全称Hyper Text Transfer Protocol(超⽂本传输协议)

HTTP协议是⽤于从(www.word wide web,简称万维⽹)服务器传输超⽂本到本地浏览器的传送协议

2、HTTP协议⼯作于B/S架构

浏览器作为HTTP客户端通过URL向HTTP服务端即WEB服务器发送请求Request。

Web服务器根据接收到的请求后,向客户端发送响应信息Response。

3、HTTP协议是基于TCP/IP通信协议来传递数据的(HTML ⽂件, 图⽚⽂件等),如下图

第⼀个HTTP协议诞⽣于1989年3⽉,已过时。

#⼀:它的组成极其简单:

#1、只允许客户端发送GET这⼀种请求

#2、不⽀持请求头。

#3、由于没有请求头,造成了HTTP 0.9协议只⽀持⼀种内容,即纯⽂本。不过⽹页仍然⽀持⽤HTML语⾔格式化,同时⽆法插⼊图⽚。

#⼆:⽆状态性

#1、HTTP 0.9具有典型的⽆状态性,每个事务独⽴进⾏处理,事务结束时就释放这个连接。详细解释如下:

⼀次HTTP 0.9的传输⾸先要建⽴⼀个由客户端到Web服务器的TCP连接,由客户端发起⼀个请求,然后由Web服务器返回页⾯内容,然后连接会关闭。如果请求的页⾯不存在,也不会返回任何错误码。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

超文本传输协议版本 2

IETF HTTP2草案(draft-ietf-httpbis-http2-13)

摘要

本规范描述了一种优化的超文本传输协议(HTTP)。HTTP/2通过引进报头字段压缩以及多路复用来更有效利用网络资源、减少感知延迟。另外还介绍了服务器推送规范。

本文档保持对HTTP/1.1的后向兼容,HTTP的现有的语义保持不变。

1 介绍

The Hypertext Transfer Protocol (HTTP) is a wildly successful protocol. However, the HTTP/1.1 message format ([RFC7230], Section 3) was designed to be implemented with the tools at hand in the 1990s, not modern Web application performance. As such it has several characteristics that have a negative overall effect on application performance today.

超文本传输协议(HTTP)是一个非常成功的协议。但是HTTP/1.1 是针对90年代的情况而不是现代web应用的性能而设计的,导致它的一些特点已经对现代应用程序的性能产生负面影响。

In particular, HTTP/1.0 only allows one request to be outstanding at a time on a given connection. HTTP/1.1 pipelining only partially addressed request concurrency and suffers from head-of-line blocking. Therefore, clients that need to make many requests typically use multiple connections to a server in order to reduce latency.

特别是,HTTP/1.0只允许在一个连接上建立一个当前未完成的请求。HTTP/1.1管道只部分处理了请求并发和报头阻塞的问题。因此客户端需要发起多次请求通过数次连接服务器来减少延迟。

Furthermore, HTTP/1.1 header fields are often repetitive and verbose, which, in addition to generating more or larger network packets, can cause the small initial TCP [TCP] congestion window to quickly fill. This can result in excessive latency when multiple requests are made on a single new TCP connection.

此外,HTTP/1.1的报头字段经常重复和冗长。在产生更多或更大的网络数据包时,可能导致小的初始TCP堵塞窗口被快速填充。这可能在多个请求建立在一个新的TCP连接时导致过度的延迟。

This specification addresses these issues by defining an optimized mapping of HTTP's semantics to an underlying connection. Specifically, it allows interleaving of request and response messages on the same connection and uses an efficient coding for HTTP header fields. It also allows prioritization of requests, letting more important requests complete more quickly, further improving performance.

本协议通过定义一个优化的基础连接的HTTP语义映射来解决这些问题。具体地,它允许在同一连接上交错地建立请求和响应消息,并使用高效率编码的HTTP报头字段。它还允许请求的优先级,让更多的重要的请求更快速的完成,进一步提升了性能。

The resulting protocol is designed to be more friendly to the network, because fewer TCP connections can be used in comparison to HTTP/1.x. This means less competition with other flows, and longer-lived connections, which in turn leads to better utilization of available network capacity.

最终协议设计为对网络更友好,因为它相对HTTP/1.x减少了TCP连接。这意味着与其他流更少的竞争以及更长时间的连接,

从而更有效地利用可用的网络容量。

Finally, this encapsulation also enables more efficient processing of messages through use of binary message framing.

最后,这种封装也通过使用二进制消息帧使信息处理更具扩展性。

2 HTTP / 2协议概述

相关文档
最新文档