OSI是一个有关于计算机网络体系的概念模型，定义了网络互联的7层框架结构。作用：在此标准下，将世界范围内的计算机互连为网络。

TCP/IP是一个网络通信模型，它参考4层模型（简化的OSI），是4层协议的集合。称为TCP/IP协议族。作用：将数据应该如何封装、定址、传输、路由以及在目的地如何接收，都加以标准化，是OSI的实现。

HTTP是超文本传输协议，一个基于TCP/IP通信协议来传输数据的应用层协议。作用：定义一种请求/应答的标准，用于从万维网服务器传输超文本到本地浏览器。

HTTP

HTTP超文本传输协议，设计的最初目的是为了提供一种发布和接收HTML页面的方法，HTTP定义了客户端（用户，接收）和服务端（网站，发布）之间请求和应答的标准，通常使用TCP协议。HTTP协议中并没有规定它必须使用TCP/IP，其实HTTP可以在任何互联网协议或其他网络上实现，任何能够提供可靠传输的协议都可以被使用，只不过TCP/IP是最好的。

一句话概括，HTTP就是一个基于TCP/IP通信协议来传输数据的应用层协议。它就是一个标准,不涉及数据包（packet）传输，通讯双方都需要遵循这个准则

作用:

HTTP协议（HyperText Transfer Protocol，超文本传输协议）是因特网上应用最为广泛的一种网络传输协议，所有的WWW文件都必须遵守这个标准。用于从万维网（WWW:World Wide Web ）服务器传输超文本到本地浏览器的传送协议。

这里说到 HTTP是应用层协议，那就要说一说除了应用层，还有哪些层

OSI

OSI模型（开放式系统互联通信参考模型，Open System Interconnection Reference Model，缩写：OSI；简称为OSI模型）是一种概念模型。

根据建议X.200，OSI将计算机网络体系结构划分为以下七层，标有1～7，第1层在底部。现“OSI/RM”是英文“Open Systems Interconnection Reference Model”的缩写。

应用层（第七层）

应用层（Application Layer）提供为应用软件而设的接口，以设置与另一应用软件之间的通信。例如: HTTP，HTTPS，FTP，TELNET，SSH，SMTP，POP3.HTML.等。
表达层

表达层（Presentation Layer）把数据转换为能与接收者的系统格式兼容并适合传输的格式。
会话层

会话层（Session Layer）负责在数据传输中设置和维护计算机网络中两台计算机之间的通信连接。
传输层

传输层（Transport Layer）把传输表头（TH）加至数据以形成数据包。传输表头包含了所使用的协议等发送信息。例如:传输控制协议（TCP）等。
网络层

网络层（Network Layer）决定数据的路径选择和转寄，将网络表头（NH）加至数据包，以形成分组。网络表头包含了网络数据。例如:互联网协议（IP）等。
数据链路层

数据链路层（Data Link Layer）负责网络寻址、错误侦测和改错。当表头和表尾被加至数据包时，会形成帧。数据链表头（DLH）是包含了物理地址和错误侦测及改错的方法。数据链表尾（DLT）是一串指示数据包末端的字符串。例如以太网、无线局域网（Wi-Fi）和通用分组无线服务（GPRS）等。

分为两个子层：逻辑链路控制（logical link control，LLC）子层和介质访问控制（Medium access control，MAC）子层。

物理层（第一层）

物理层（Physical Layer）在局部局域网上传送数据帧（data frame），它负责管理计算机通信设备和网络媒体之间的互通。包括了针脚、电压、线缆规范、集线器、中继器、网卡、主机接口卡等。

各层协议：

各层作用：

现在我们知道OSI是开放式系统互联通信参考模型，是一种概念模型，由国际标准化组织提出，一个试图使各种计算机在世界范围内互连为网络的标准框架，是一个网络模型。定义于ISO/IEC 7498-1。

我们还说HTTP是基于TCP/IP通信协议的

那么TCP/IP是啥呢？

TCP/IP

TCP/IP也是一个网络模型

互联网协议套件（英语：Internet Protocol Suite，缩写IPS）[1]是一个网络通信模型，以及一整个网络传输协议家族，为网际网络的基础通信架构。它常被通称为TCP/IP协议族（英语：TCP/IP Protocol Suite，或TCP/IP Protocols），简称TCP/IP。因为该协议家族的两个核心协议：TCP（传输控制协议）和IP（网际协议），为该家族中最早通过的标准。

TCP/IP提供点对点的链接机制，将软件通信过程抽象化为四个抽象层，是简化的七层OSI模型。

对照：

OSI、TCP/IP、HTTP的区别联系

首先要搞清楚三个东西的本质：

1、OSI是一个有关于计算机网络体系的概念模型，定义了网络互联的7层框架结构。

OSI概念模型做的事情是：制定一个标准时所使用的框架，描述一些概念，将世界范围内的计算机互连为网络。（当然你可以不遵循这个标准）

2、TCP/IP是一个网络通信模型，参考模型有4层。它是一整套网络传输协议的家族，只是因为TCP、IP两大协议是该协议家族中的核心协议，也是最早通过的标准，所以命名为TCP/IP协议族（简称TCP/IP）。

TCP/IP网络通信模型做的事情是：将数据应该如何封装、定址、传输、路由以及在目的地如何接收，都加以标准化。与其说是OSI7层模型的简化版，不如说是OSI模型的一种实现。

3、HTTP是一种用于分布式、协作式和超媒体信息系统的应用层协议，是客户端和服务端请求应答的标准。它也是一个标准，HTTP1.0,HTTP1.1,HTTP2是这个标准的具体实现。

HTTP协议做的事情是：提供一种发布、接收HTML页面的方法。

**易误解点：

TCP/IP(协议族) ≠ TCP 和 IP

前者是一个网络通信模型，和OSI相似。这个网络通信模型中每一层都有相应的众多协议，而TCP或者IP只是一个协议。

关于每层都有什么协议在上面介绍OSI和TCP/IP是有图示。

浏览器输入url，回车后发生的事情：
输入url地址-dns解析（查找域名对应的ip地址）-tcp建连-浏览器发起http请求-服务器处理请求并响应-浏览器显示页面

HTTP通信流程：客户端发送一个请求(request)给服务器，服务器在接收到这个请求后将生成一个响应(response)返回给客户端。

在这个通信的过程中HTTP协议在以下4个方面做了规定：

1. Request和Response的格式
1. 建立连接的方式
1. 缓存的机制
1. 响应授权激发机制

要介绍HTTP协议中的规定，先要弄清楚HTTP是建立连接的，通过什么建立连接，总不能朝着天空大喊一身“我要和xxx建立连接”吧。

1、HTTP之URL

HTTP使用统一资源标识符（Uniform Resource Identifiers, URI）来传输数据和建立连接。

统一资源标识符URI又包含两个内容：URL和URN。我们的http请求一般都是URL形式的

URI

URI（Uniform Resource Identifier）：统一资源标识符，在世界范围内唯一标识并定位信息资源。

URI有两种形式：URL（统一资源定位符Uniform Resource Locator）和URN（统一资源名称Uniform Resource Name）。

URI是以一种抽象的，高层次概念定义统一资源标识，而URL和URN则是具体的资源标识的方式。URL和URN都是一种URI。就像等边三角形，等腰三角形都属于三角形一样。

笼统地说，每个 URL 都是 URI，但不一定每个 URI 都是 URL。这是因为 URI 还包括一个子类，即统一资源名称 (URN)，它命名资源但不指定如何定位资源。

URL是一种特殊类型的URI，包含了用于查找某个资源的足够的信息

URI和URL、URN的区别联系

URI可被视为定位符（URL），名称（URN）或两者兼备。统一资源名（URN）如同一个人的名称，而统一资源定位符（URL）代表一个人的住址。换言之，URN定义某事物的身份，而URL提供查找该事物的方法。

统一资源标识符URI在某一规则下，把世界上的任一资源唯一的标识出来。
拿人做个例子，什么能把一个人唯一标识出来呢？一定是身份证，每个人的身份证号码绝对不一样，所以身份证就相当于人的URI，身份证(URI)让我们能且只能确定唯一的一个人。

而URL呢？统一资源定位符URL，我们注意一下URI和URL词义上的区别：标识和定位。

还拿人做例子，URL就相当于一个人的当前地址：

太阳系/地球/中国/河南省/南阳市/宛城区/南阳理工学院/11号宿舍楼/233寝室/小明

这就相当于一个URL，这个URL也能唯一标识一个人，不过我们可以通过这个地址（URL）定位到这个人（资源）。

对于上述中的小明同学，

我们可以用身份证：123456789 唯一确定这个人
也能用地址：太阳系/地球/中国/河南省/南阳市/宛城区/南阳理工学院/11号宿舍楼/233寝室/小明唯一确定这个人

所以身份证和地址都可以称作是URI,但是只有地址能称作URL，因为我们可以通过身份证或地址标识他，但只能通过这个地址（URL）定位到他。

而在互联网世界，假设所有资源都有一个编号xxxx，那么这个编号就是URI,而URL则通过描述某个主机的某个路径的某个文件名字来唯一确定一个资源，也就是通过定位的方式实现URI。

所以对于这样的连接https://github.com/hanhanhanxu/MyHashMap/blob/master/src/Main.java人们更习惯叫他URL,因为它提供了资源的位置信息，但既然是能唯一标识资源的，就也能够叫做URI。

URN同理。

所以

URL和URN是URI的子集

2、HTTP之请求与响应

由HTTP客户端发起一个请求，创建一个到服务器指定端口(默认80)的TCP连接。HTTP服务器则在此端口监听客户端的请求，一旦收到请求，HTTP服务器会向客户端返回一个状态（比如HTTP/1.1 200 OK）和内容（比如请求的文件或错误信息）。

HTTP请求实例：

http请求由四部分组成：

请求行（例如GET /images/logo.gif HTTP/1.1，表示get请求从/images目录下请求logo.gif这个文件；例如POST / HTTP1.1表明了是post请求，以及http1.1版本。包含请求方法、URI、HTTP版本信息）
请求头部（例如Accept-Language: en）
空行（一行空行）
请求数据（name=Professional%20Ajax&publisher=Wiley）

下面是两个例子：

Get请求例子

GET /562f25980001b1b106000338.jpg HTTP/1.1
Host    img.mukewang.com
User-Agent  Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36
Accept  image/webp,image/*,*/*;q=0.8
Referer http://www.imooc.com/
Accept-Encoding gzip, deflate, sdch
Accept-Language zh-CN,zh;q=0.8
此处有一行空行

Post请求例子

POST / HTTP1.1
Host:www.wrox.com
User-Agent:Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)
Content-Type:application/x-www-form-urlencoded
Content-Length:40
Connection: Keep-Alive

name=Professional%20Ajax&publisher=Wiley

上述例子中，各部分代表：

请求行，用来说明请求类型（get post）,要访问的资源以及所使用的HTTP版本.
请求头部，用来说明服务器要使用的附加信息
空行，请求头部后面的空行是必须的
请求数据也叫主体，可以添加任意的其他数据。

在HTTP/1.1协议中，所有的请求头，除Host外，都是可选的。

也有人认为http请求由三部分组成，分别是：请求行、消息报头、请求正文。我猜这种是将请求头部看作消息报头，将空行忽略，将请求数据看作请求正文。

HTTP响应实例

一般情况下，服务器接收并处理客户端发过来的请求后会返回一个HTTP的响应消息。

http响应也由四部分组成：

状态行（当前HTTP版本号，3位数字组成的状态代码，以及描述状态的短语，彼此由空格分隔。例如HTTP/1.1 200 OK）
消息报头（例如Content-Encoding: gzip）
空行（一行空行）
响应正文（）

下面是一个http响应

HTTP/1.1 200 OK
Date: Fri, 22 May 2009 06:07:21 GMT
Content-Type: text/html; charset=UTF-8

<html>
      <head></head>
      <body>
            <!--body goes here-->
      </body> 
</html>

上述例子中，各部分代表：

状态行，由HTTP协议版本号，状态码，状态消息三部分组成。第一行为状态行，（HTTP/1.1）表明HTTP版本为1.1版本，状态码为200，状态消息为（ok）
消息报头，用来说明客户端要使用的一些附加信息。第二行和第三行为消息报头，
Date:生成响应的日期和时间；Content-Type:指定了MIME类型的HTML(text/html),编码类型是UTF-8
空行消息报头后面的空行是必须的
响应正文，服务器返回给客户端的文本信息空行后面的html部分为响应正文。

上面的响应行中出现了状态码，下面就介绍下HTTP的状态码

HTTP状态码

状态代码有三位数字组成，第一个数字定义了响应的类别，共分五种类别:

1xx：指示信息–表示请求已接收，继续处理。这类响应是临时响应

2xx：成功–表示请求已被成功接收、理解、接受。

3xx：重定向–要完成请求必须进行更进一步的操作。通常用来重定向，后续的请求地址（重定向目标）在本次响应的Location域中指明

4xx：客户端错误–请求有语法错误或请求无法实现

5xx：服务器端错误–服务器未能实现合法的请求

常用状态码

200 OK                        //客户端请求成功。请求所希望的响应头或数据体将随此响应返回。

400 Bad Request               //客户端请求有语法错误，不能被服务器所理解

401 Unauthorized              //请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用 

403 Forbidden                 //服务器收到请求，但是拒绝提供服务

404 Not Found                 //请求资源不存在，eg：输入了错误的URL

500 Internal Server Error     //服务器发生不可预期的错误

503 Server Unavailable        //服务器当前不能处理客户端的请求，一段时间后可能恢复正常

次常用

204：请求被受理但没有资源可以返回
206：客户端只是请求资源的一部分，服务器只对请求的部分资源执行GET方法，相应报文中通过Content-Range指定范围的资源。
301：永久性重定向 搜索引擎在抓取新内容的同时也将旧的网址交换为重定向之后的网址；
302：临时重定向 搜索引擎会抓取新的内容而保存旧的网址（SEO302好于301）
303：与302状态码有相似功能，只是它希望客户端在请求一个URI的时候，能通过GET方法重定向到另一个URI上
304：发送附带条件的请求时，条件不满足时返回，与重定向无关
307：临时重定向，与302类似，只是强制要求使用POST方法

附：可在Chrome浏览器中ctrl+f进行查找

HTTP请求方式

HTTP/1.1协议中共定义了八种方法（也叫“动作”）来以不同方式操作指定的资源

GET

向指定的资源发出“显示”请求。使用GET方法应该只用在读取数据，而不应当被用于产生“副作用”的操作中，例如在网络应用程序中。其中一个原因是GET可能会被网络蜘蛛等随意访问。参见安全方法

HEAD

与GET方法一样，都是向服务器发出指定资源的请求。只不过服务器将不传回资源的本文部分。它的好处在于，使用这个方法可以在不必传输全部内容的情况下，就可以获取其中“关于该资源的信息”（元信息或称元数据）。

POST

向指定资源提交数据，请求服务器进行处理（例如提交表单或者上传文件）。数据被包含在请求本文中。这个请求可能会创建新的资源或修改现有资源，或二者皆有。

PUT

向指定资源位置上传其最新内容。

DELETE

请求服务器删除Request-URI所标识的资源。

TRACE

回显服务器收到的请求，主要用于测试或诊断。

OPTIONS

这个方法可使服务器传回该资源所支持的所有HTTP请求方法。用’*’来代替资源名称，向Web服务器发送OPTIONS请求，可以测试服务器功能是否正常运作。

CONNECT

HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。通常用于SSL加密服务器的链接（经由非加密的HTTP代理服务器）。
方法名称是区分大小写的。当某个请求所针对的资源不支持对应的请求方法的时候，服务器应当返回状态码405（Method Not Allowed），当服务器不认识或者不支持对应的请求方法的时候，应当返回状态码501（Not Implemented）。

HTTP服务器至少应该实现GET和HEAD方法，其他方法都是可选的。

3、HTTP之连接方式

HTTP支持两种建立连接的方式：

非持久连接和持久连接(HTTP1.0为非持久连接，可通过Connection: keep-alive启用Keep-Alive，HTTP1.1默认的连接方式为持久连接，默认启用Keep-Alive，可通过Connection: close关闭。【加在HTTP请求头中】 )。

当Keep-Alive不启用时，为非持久连接，HTTP发起请求，TCP三次握手建立连接，请求/应答，数据传输完成后立即断开连接。

当Keep-Alive启用时，为持久连接，数据请求/应答完成后不会立即断开连接。而是通过请求中的Content-Length和Transfer-Encoding字段判断当前连接是否需要断开。（这两个字段在下面HTTP各版本区别里的HTTP1.1版本会讲到）

持久化连接还分为不带流水线和带流水线两个版本，带流水线（1.1引入，管道机制）的持久化连接将一次请求尽可能的降低到1个RTT的延迟。

HTTP各版本区别

HTTP0.9

最早版本是1991年发布的0.9版。该版本极其简单，只有一个命令GET。

GET /index.html

上面命令表示，TCP 连接（connection）建立后，客户端向服务器请求（request）网页index.html。

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

<html>
  <body>Hello World</body>
</html>

服务器发送完毕，就关闭TCP连接。

HTTP1.0

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

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

其次，还引入了POST和HEAD命令，丰富了浏览器和服务器交互的手段。

再次，HTTP请求和回应的格式也变了。除了数据部分，完善了请求与响应的格式：请求行、请求头、空行、请求数据；状态行、消息报头、空行、响应正文。至今仍被广泛采用。

其他的新增功能还包括状态码（status code）、多字符集支持、多部分发送（multi-part type）、权限（authorization）、缓存（cache）、内容编码（content encoding）等。

下面是一个1.0版的HTTP请求的例子。

请求格式：

GET / HTTP/1.0

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5)

Accept: */*

响应格式：

HTTP/1.0 200 OK 

Content-Type: text/plain

Content-Length: 137582

Expires: Thu, 05 Dec 1997 16:00:00 GMT

Last-Modified: Wed, 5 August 1996 15:55:28 GMT

Server: Apache 0.84

<html>
  <body>Hello World</body>
</html>

Content-Type 字段

关于字符的编码，1.0版规定，头信息必须是 ASCII 码，后面的数据可以是任何格式。因此，服务器回应的时候，必须告诉客户端，数据是什么格式，这就是Content-Type字段的作用。

下面是一些常见的Content-Type字段的值。

text/plain
text/html
text/css
image/jpeg
image/png
image/svg+xml
audio/mp4
video/mp4
application/javascript
application/pdf
application/zip
application/atom+xml

这些数据类型总称为MIME type，每个值包括一级类型和二级类型，之间用斜杠分隔。

MIME type还可以在尾部使用分号，添加参数。

Content-Type: text/html; charset=utf-8

上面的类型表明，发送的是网页，而且编码是UTF-8。

客户端请求的时候，可以使用Accept字段声明自己可以接受哪些数据格式。

Accept: /

MIME type不仅用在HTTP协议，还可以用在其他地方，比如HTML网页。

Content-Encoding 字段

由于发送的数据可以是任何格式，因此可以把数据压缩后再发送。Content-Encoding字段说明数据的压缩方法。

Content-Encoding: gzip
Content-Encoding: compress
Content-Encoding: deflate

客户端在请求时，用Accept-Encoding字段说明自己可以接受哪些压缩方法。

Accept-Encoding: gzip, deflate

缺点

HTTP/1.0 版的主要缺点是，每个TCP连接只能发送一个请求。发送数据完毕，连接就关闭，如果还要请求其他资源，就必须再新建一个连接（HTTP1.0非持久连接）。

TCP连接的新建成本很高，因为需要客户端和服务器三次握手，并且开始时发送速率较慢（slow start）。所以，HTTP 1.0版本的性能比较差。随着网页加载的外部资源越来越多，这个问题就愈发突出了。

为了解决这个问题，有些浏览器在请求时，用了一个非标准的Connection字段。

Connection: keep-alive

这个字段要求服务器不要关闭TCP连接，以便其他请求复用。服务器同样回应这个字段。

Connection: keep-alive

一个可以复用的TCP连接就建立了，直到客户端或服务器主动关闭连接。但是，这不是标准字段，不同实现的行为可能不一致，因此不是根本的解决办法。

HTTP1.1

1997年1月，HTTP/1.1 版本发布，只比 1.0 版本晚了半年。它进一步完善了 HTTP 协议，一直用到了20年后的今天，直到现在还是最流行的版本。

持久连接

1.1 版的最大变化，就是引入了持久连接（persistent connection），即TCP连接默认不关闭，可以被多个请求复用，不用声明Connection: keep-alive。

客户端和服务器发现对方一段时间没有活动，就可以主动关闭连接。不过，规范的做法是，客户端在最后一个请求时，发送Connection: close，明确要求服务器关闭TCP连接。

目前，对于同一个域名，大多数浏览器允许同时建立6个持久连接

管道机制(流水线机制)

1.1 版还引入了管道机制（pipelining），即在同一个TCP连接里面，客户端可以同时发送多个请求。这样就进一步改进了HTTP协议的效率。

举例来说，客户端需要请求两个资源。以前的做法是，在同一个TCP连接里面，先发送A请求，然后等待服务器做出回应，收到后再发出B请求。管道机制则是允许浏览器同时发出A请求和B请求，但是服务器还是按照顺序，先回应A请求，完成后再回应B请求（这点设计的不好，所有数据通信都是按照次序进行，若服务器处理A请求时，处理特别慢，那么后面的请求就会一直排队等着，这称为“队头堵塞”）。

Content-Length 字段

一个TCP连接现在可以传送多个回应，势必就要有一种机制，区分数据包是属于哪一个回应的。这就是Content-length字段的作用，声明本次回应的数据长度。

Content-Length: 3495
上面代码告诉浏览器，本次回应的长度是3495个字节，后面的字节就属于下一个回应了。

在1.0版中，Content-Length字段不是必需的，因为浏览器发现服务器关闭了TCP连接，就表明收到的数据包已经全了。

分块传输编码

使用Content-Length字段的前提条件是，服务器发送回应之前，必须知道回应的数据长度。对于一些很耗时的动态操作来说，这意味着，服务器要等到所有操作完成，才能发送数据，显然这样的效率不高。更好的处理方法是，产生一块数据，就发送一块，采用”流模式”（stream）取代”缓存模式”（buffer）。

因此，1.1版规定可以不使用Content-Length字段，而使用”分块传输编码”（chunked transfer encoding）。只要请求或回应的头信息有Transfer-Encoding字段，就表明回应将由数量未定的数据块组成。

每个非空的数据块之前，会有一个16进制的数值，表示这个块的长度。最后是一个大小为0的块，就表示本次回应的数据发送完了。

HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked

25
This is the data in the first chunk

1C
and this is the second one

3
con

8
sequence

0
此处有一个空行