android之Http协议

网络框架图

一、5层网络体系结构

其实socket和http协议不相关的，socket是对tcp/ip协议的编程，http协议则是基于tcp/ip封装的，不能说socket是封装了tcp/ip,他还有udp,也不能说http对tcp/ip的编程，http协议比tcp/ip协议要高一个层次。

之前一篇我们已经了解了socket，现在要理解http协议，要看它在网络体系结构中发挥的作用，http是属于应用层上的协议，是对下层tcp/ip的封装，可以看作是htttp包含tcp/ip,只要看http协议就是实现了数据的传输，也就是应用层app用到网络数据传输，不用关心其他下层协议。

0. http协议工作原理

客户端浏览器请求服务器数据，首先是根据http协议，组装字符串，组装成一个请求字符串，该字符串包括请求头，请求体，请求行等，然后把这个字符串转成二进制数据，然后给TCP层去分解，然后TCP层交给IP层，拆解成多个IP数据包。这时候这些包是无序的，经过网络到达服务器，不一定哪个包先到达。到达之后，然后数据包又根据各层的协议把数据包据组装成一个完整的请求，然后服务器响应请求。

从服务器端发送到客户端浏览器，首先也是根据HTTP协议，组装字符串，组装成一次响应，这个响应的字符串包括响应体，响应头，响应行等。然后这个字符串会被转成二进制数据，然后给TCP层去分解，然后TCP层交给IP层，拆解成多个IP数据包。这时候这些包是无序的，不一定哪个包先到达。比如如果发送文件，最终这些包再组成文件，如img,css,js文件。这就是为什么图片渲染出来的顺序不一样。

ISO国际标准化组织提出的7层网络体系结构，研讨久，错失先机，理想化

因特网提出的4层网络体系结构，抢先占领市场，现在一直用因特网的体系的产品

结合两者优点得出5层网络体系结构。

HTTP 协议:超文本传输协议，对应于应用层，用于如何封装数据.封装数据

TCP/UDP 协议:传输控制协议，对应于传输层，主要解决数据在网络中的传输。传输的实现

IP 协议:对应于网络层，同样解决数据在网络中的传输。地址

传输数据的时候只使用  TCP/IP  协议 ( 传输层 ) ，如果没有应用层来识别数据内容，传输后的数据都是无用的。

应用层协议很多 FTP,HTTP,TELNET等，可以自己定义应用层协议。

1.物理层

网络驱动硬件所共同遵守的

比如一个用水晶头插头，一个用三角插头是不是不能通信，要两个都一样，都是水晶头插座

2.数据链路层

物理层的上一层是数据链路层，我们也可以理解为以太网层或者令牌网。当一台主机把以太网数据帧发送到位于同一局域网上的另一台主机时，是根据48bit的以太网地址来确定目的接口的。设备驱动程序从不检查IP数据报中的目的IP地址。ARP为IP地址到对应的硬件地址之间提供动态映射。我们之所以用动态这个词是因为这个过程是自动完成的，一般应用程序用户或系统管理员不必关心。

3.网络层

网络层有不同的协议，如IP与ICMP，两者的不同就是对于上层传过来的数据根据什么样的格式进行切割，然后再次封装时候遵循的准则不同。

ICMP是Ping命令经常用到的协议。Ping命令不是什么特别神秘的东西，是一个程序员编写的一个exe应用程序，你的电脑控制台之所有能够使用这个程序，是因为你的电脑上安装了这个exe，而且在path里边设置了这个程序的路径。ICMP全称是报文控制协议。通过上边的图片可以看出，应用层的Ping工具，使用Ping协议，直接跳过运输层，调用了网络层的ICMP协议。ICMP数据包里边内容，都是关于目的主机的一些信息，因此可以用于远程判断一台主机是否存在于网络上。ping程序是对两个系统连通性进行测试的基本工具。它只利用ICMP回显请求和回显应答报文，而不用经过传输层TCP/UDP。Ping服务器一般在内核中实现ICMP的功能。

网络上一台主机的可达性不仅仅取决于 IP 层是否可达，还要取决于使用何种协议以及端口号。就比如说，一台主机确实存在于互联网上边，而且一台 Client 向这台主机使用 Ping 工具发起 ICMP 协议包，这些数据包也准确到达了主机。主机在接收到这些数据包之后，从链路层传到网络层一层层拆去包装进行解析，但是主机的操作系统从网络层再往上解析的时候，发现了 Ping 的端口为 6666 （假设该主机封闭了该端口），就不会做出反应，而且默默的把这些数据吞了。那么在 Client 看来，发出去的数据包失联了，会认为这个主机找不到。

所以，总结一下Ping不可达的原因：主机不在线，比如说关机了或者拔掉网线了。还有就是网络防火墙或者IP策略，会对ICMP报文进行过滤，ping命令无法回应，还有就是主机本身的一些策略，会过滤掉ICMP数据包。

4.传输层

当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。TCP将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP将丢弃这个报文段和不确认收到此报文段（希望发端超时并重发）。既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能会失序，因此TCP报文段的到达也可能会失序。如果必要， TCP将对收到的数据进行重新排序，将收到的数据以正确的顺序交给应用层。

另外，TCP对字节流的内容不作任何解释。TCP不知道传输的数据字节流是二进制数据，还是ASCII字符、EBCDIC字符或者其他类型数据。对字节流的解释由TCP连接双方的应用层解释。这种对字节流的处理方式与Unix操作系统对文件的处理方式很相似。Unix的内核对一个应用读或写的内容不作任何解释，而是交给应用程序处理。对Unix的内核来说，它无法区分一个二进制文件与一个文本文件。

一个TCP连接是全双工（即数据在两个方向上能同时传递），因此每个方向必须单独地进行关闭。这原则就是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向连接。当一端收到一个FIN，它必须通知应用层另一端几经终止了那个方向的数据传送。发送FIN通常是应用层进行关闭的结果。

端口号，不是说一个真正存在的实体，或者说在网卡上有个端口啥的。其实端口号就是一个简单的数字标识，用于区分不同的应用程序，有点类似于应用程序的ID，因为网络数据到达了一个主机上边，怎么知道这个数据是给哪个应用程序的呢，这时候端口号就起作用了。前面已经指出过， TCP和UDP采用16bit的端口号来识别应用程序。那么这些端口号是如何选择的呢？服务器一般都是通过知名端口号来识别的。例如，对于每个TCP/IP实现来说，FTP服务器的TCP端口号都是21，每个Telnet服务器的TCP端口号都是23，每个TFTP (简单文件传送)服务器的UDP端口号都是69。

客户端通常对它所使用的端口号并不关心，只需保证该端口号在本机上是唯一的就可以了。客户端口号又称作临时端口号（即存在时间很短暂）。这是因为它通常只是在用户运行该客户程序时才存在，而服务器则只要主机开着的，其服务就运行。

网络层（  IP ）提供点到点的服务，而运输层（  T C P 和 U D P ）提供端到端的服务。

在TCP/IP协议族中，网络层IP提供的是一种不可靠的服务。也就是说，它只是尽可能快地把分组从源结点送到目的结点，但是并不提供任何可靠性保证。而另一方面，TCP在不可靠的IP层上提供了一个可靠的运输层。为了提供这种可靠的服务， TCP采用了超时重传、发送和接收端到端的确认分组等机制。由此可见，运输层和网络层分别负责不同的功能

为什么IP层是不可靠的，而TCP是建立在IP的基础上的，却是可靠的呢？因为做了一些冗余的操作来保证可靠。Telnet和Rlogin这两个交互应用要求最小的传输时延，因为人们主要用它们来传输少量的交互数据。另一方面，FTP文件传输则要求有最大的吞吐量。

TCP连接的三次握手

第一次握手：客户端发送 syn 包 (syn=j) 到服务器，并进入 SYN_SEND 状态，等待服务器确认 ;

第二次握手：服务器收到syn包，必须确认客户的SYN(ack=j+1)，同时自己也发送一个SYN包(syn=k)，即SYN+ACK包，此时服务器进入SYN_RECV状态;

第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。

握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。

理想状态下， TCP 连接一旦建立，在通信双方中的任何一方主动关闭连接之前， TCP  连接都将被一直保持下去。

断开连接时服务器和客户端均可以主动发起断开TCP连接的请求，断开过程需要经过“四次握手”(过程就不细写了，就是服务器和客户端交互，最终确定断开)

5.应用层（HTTP 协议）、

HTTP协议是一个web服务器和客户端通信的超文本传送协议，是建立在TCP协议上的一个应用层协议。

HTTP连接最显著的特点是客户端发送的每次请求都需要服务器回送响应，在请求结束后，会主动释放连接。从建立连接到关闭连接的过程称为“一次连接”。

HTTP1.0

客户端的每次请求都要求建立一次单独的连接，在处理完本次请求后，就自动释放连接。

HTTP1.1

可以在一次连接中处理多个请求，并且多个请求可以重叠进行，不需要等待一个请求结束后再发送下一个请求。

http 为短连接：客户端发送请求都需要服务器端回送响应.请求结束后，主动释放链接，因此为短连接。而做长连接通常的做法是，不需要任何数据，也要保持每隔一段时间向服务器发送"保持连接"的请求。这样可以保证客户端在服务器端是"上线"状态。

HTTP连接使用的是"请求-响应"方式，不仅在请求时建立连接，而且客户端向服务器端请求后，服务器才返回数据。

主要的特点：

1.支持客户/服务器模式。

2.简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。

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

4.无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。

5.无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。

HTTP协议之URL：

 http（超文本传输协议）是一个基于请求与响应模式的、无状态的、应用层的协议，常基于TCP的连接方式，HTTP1.1版本中给出一种持续连接的机制，绝大多数的Web开发，都是构建在HTTP协议之上的Web应用。

HTTP URL (URL是一种特殊类型的URI，包含了用于查找某个资源的足够的信息)的格式如下：

http://host[":"port][abs_path]

http表示要通过HTTP协议来定位网络资源；host表示合法的Internet主机域名或者IP地址；port指定一个端口号，为空则使用缺省端口80；abs_path指定请求资源的URI；如果URL中没有给出abs_path，那么当它作为请求URI时，必须以“/”的形式给出，通常这个工作浏览器自动帮我们完成。

eg:

1、输入：http://square.github.io/okhttp/

HTTP协议之请求头：

HTTP客户程序（例如浏览器），向服务器发送请求的时候必须指明请求类型（一般是GET或者POST）。如有必要，客户程序还可以选择发送其他的请求头。大多数请求头并不是必需的，但Content-Length除外。对于POST请求来说Content-Length必须出现。

下面是一些最常见的请求头

　　Accept：浏览器可接受的MIME类型。

　　Accept-Charset：浏览器可接受的字符集。

　　Accept-Encoding：浏览器能够进行解码的数据编码方式，比如gzip。Servlet能够向支持gzip的浏览器返回经gzip编码的HTML页面。许多情形下这可以减少5到10倍的下载时间。

　　Accept-Language：浏览器所希望的语言种类，当服务器能够提供一种以上的语言版本时要用到。

　　Authorization：授权信息，通常出现在对服务器发送的WWW-Authenticate头的应答中。

　　Connection：表示是否需要持久连接。如果Servlet看到这里的值为“Keep-Alive”，或者看到请求使用的是HTTP1.1（HTTP1.1默认进行持久连接），它就可以利用持久连接的优点，当页面包含多个元素时（例如Applet，图片），显著地减少下载所需要的时间。要实现这一点，Servlet需要在应答中发送一个Content-Length头，最简单的实现方法是：先把内容写入ByteArrayOutputStream，然后在正式写出内容之前计算它的大小。

　　Content-Length：表示请求消息正文的长度。

　　Cookie：这是最重要的请求头信息之一

　　From：请求发送者的email地址，由一些特殊的Web客户程序使用，浏览器不会用到它。

　　Host：初始URL中的主机和端口。

　　If-Modified-Since：只有当所请求的内容在指定的日期之后又经过修改才返回它，否则返回304“Not Modified”应答。

　　Pragma：指定“no-cache”值表示服务器必须返回一个刷新后的文档，即使它是代理服务器而且已经有了页面的本地拷贝。

　　Referer：包含一个URL，用户从该URL代表的页面出发访问当前请求的页面。

　　User-Agent：浏览器类型，如果Servlet返回的内容与浏览器类型有关则该值非常有用。

　　UA-Pixels，UA-Color，UA-OS，UA-CPU：由某些版本的IE浏览器所发送的非标准的请求头，表示屏幕大小、颜色深度、操作系统和CPU类型。

　　有关HTTP头完整、详细的说明，请参见http://www.w3.org/Protocols/的HTTP规范。

        

HTTP协议之请求体：

get请求方式，请求体没有数据，post请求方式，请求体有数据

HTTP协议之请求行：

请求行以一个方法符号开头，以空格分开，后面跟着请求的URI和协议的版本，格式如下：

Method Request-URI HTTP-Version CRLF  

其中 Method表示请求方法；Request-URI是一个统一资源标识符；HTTP-Version表示请求的HTTP协议版本；

CRLF表示回车和换行（除了作为结尾的CRLF外，不允许出现单独的CR或LF字符）。

请求方法（所有方法全为大写）有多种，各个方法的解释如下：

GET     请求获取Request-URI所标识的资源

POST    在Request-URI所标识的资源后附加新的数据

HEAD    请求获取由Request-URI所标识的资源的响应消息报头

PUT     请求服务器存储一个资源，并用Request-URI作为其标识

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

TRACE   请求服务器回送收到的请求信息，主要用于测试或诊断

CONNECT 保留将来使用

OPTIONS 请求查询服务器的性能，或者查询与资源相关的选项和需求

应用举例：

GET方法：在浏览器的地址栏中输入网址的方式访问网页时，浏览器采用GET方法向服务器获取资源，

HTTP协议之响应行：

第一行响应回来的数据

响应首行：其内容是”HTTP/1.1  200  OK”

 HTTP/1.1 ：表示协议版本

  200 ：表示响应状态码，200表示响应成功。

  OK ：表示响应成功，对响应状态码的解释。

HTTP协议之响应头：

HTTP/1.1(响应采用的协议和版本号) 200(状态码) OK(描述信息)

    302（客户端请求服务端，但服务端没有对应的资源，服务端要客户端再次请求找其它的服务端，即客户端二次请求，重定向） 

    307（客户端请求服务端，但服务端没有对应的资源，服务端自行再次请求找其它的服务端，即客户端一次请求，转发）

    304（客户端请求服务端，此时客户端缓存中有，无需再从服务端下载新的内容,服务端叫客户端自行找缓存，优化）

    500(客户端请求的资源，服务端存在，但在执行时出错）

    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种(服务端禁止客户端缓存页面数据)

    Cache-Control: no-cache(服务端禁止客户端缓存页面数据)  

    Pragma: no-cache(服务端禁止客户端缓存页面数据)   

    Connection: close(1.0)/(1.1)Keep-Alive(维护客户端和服务端的连接关系)  

    Date: Tue, 11 Jul 2000 18:23:51 GMT(服务端响应客户端的时间)

HTTP协议之响应体：

 响应回来的数据，可以是xml数据，也可以是json数据

总结:Http协议和规范的规则集合，让我们数据传输有依据，要对协议的实现，需要代码来实现，各个公司对协议的实现措施不同，就产生了各种底层库。