本文深入探讨了Android中HTTP的工作原理，包括HTTP请求方法如GET、POST、DELETE、PUT的使用，状态码的意义，以及请求头的重要字段如Host、Content-Type和Content-Length的作用。通过对HTTP报文结构的分析，阐述了HTTP在移动开发中的应用。
rikkatheworld：路径path
这个是给服务器看的，服务器拿到path后，会根据路径取找到对应的信息
然后根据上面的信息，就能产生一个 http的请求，格式如下：
// HTTP请求
GET /rikkatheworld Http/1.1
Host:blog.csdn.net
有http基础的人就应该知道这些信息，其实就是http报文。
我们来分析上面那些格式：
首先第一行构成了Http的请求行
（1） 请求行
例子：GET /rikkatheworld Http/1.1
- GET
method，请求方法：包括GET、POST、DELETE、PUT
- /rikkatheworld
path，路径：给服务器看的
- Http/1.1
Http version：http版本，1.0和0.9基本已经废弃了，现在基本都是1.1，未来就都是2了。
当然了，除了请求行，Http的请求报文还有 Headers（请求头）和Body（请求体）。
（2） Headers
headers和请求行之间没有空行。下面为一个headers
Host：blog.csdn.net
Content-Tyoe：text/plain
Content-Lenth：50
（3） body
request可以有body，比如post请求的信息。和headers间有空行
Response是服务器给浏览器的返回的报文。分为 状态行、Headers和Body
长这个样子的：
也包括三个部分
状态行
状态行的格式如下：
HTTP/1.1 200 OK
- HTTP/1.1
version，放在状态行的最左边。
- 200
状态码
- OK
status message：一个简单的数据返回描述，服务端是可以改的。比如Fail、Success…
Headers
和状态行间没有空行
Body
和Headers有空行，是请求的数据，比如html。
接下来我们来对这些细节一步步讲述。
HTTP定义了这些请求方法，虽然说是定义是，但它不会去具体做这些事情，而是让客户端、服务端去遵从这些定义。
GET
获取资源：没有也不能有Body，Http的默认method就是GET
POST
增加或修改资源，肯定是有body的，因为增加和修改都要带上信息。比如 body：name=Rikka&age=22
PUT
只修改资源，肯定是也有body的
PUT和POST其实差别不是特别大，但是一般都是用POST
DELETE
删除资源，没有Body，给一个定位就可以了
比如 DELETE /users/1 HTTP/1.1 就是删除用户第1号就是了
HEAD
和GET几乎一样，区别在于服务器对于HEAD的请求不返回Body。
用途：在下载的时候，我们先用HEAD去请求下载信息，服务器会返回给我们 下载内容的大小，然后我们得知了大小，再去下载。
虽然HTTP定义了多个请求方法，但是实际情况会依据用法而改变，每个公司可能并不都会使用这些方法。
比如说把 删除的功能放在GET中而不是DELETE中…
-------------------------------------------------------
作用：对结果做出类型化描述
- 1XX：临时性消息
101：比如http 1.1和2.0是不能兼容的，一个浏览器请求一个服务器，可能会先问它是不是支持http2.0，如果服务器返回101就表示支持http2.0。就是相当于一个试探消息。
100：有时候在客户端传很大消息给服务器的时候，会分段传，这个时候客户端告诉服务器，如果你收到我第一段，你就发个100，这样我就发第二段 and so on。
- 2XX：成功
这是最爽的
- 3XX：重定向
301：重定向地址
304：内容没有改变（比如刷新了一下）
- 4XX：客户端错误
400：请求有问题，比如参数不对
401：没有权限（比如没有登录就去申请资源）
404：资源不存在
- 5XX：服务器错误
500：服务器崩了（错误）
503：服务器超载或者某种原因导致了不可用
这里有参考的比较全的http状态码：常见的HTTP错误状态码
=======================================================================
请求头，在请求行的下面并且没有隔一行。
作用：传送 HTPP消息的元数据（metadata）
元数据就是数据的属性。比如说文本的格式、文本的长度…
它有下面这些属性：
它展示服务器主机地址。但它不是用来寻址的！
寻址的时候是在url拼成request报文的时候通过DNS就寻址完了。这是ip层来做的。
它的作用也是给服务器看的。这是为什么呢？
这是因为一个服务器下面会有子服务器，这些子服务器对外的ip是一样的，所以需要这样的Host来告诉服务器是具体哪个子服务器，一般是 域名+Tcp端口
这两个字段大多是出现在POST、PUT中，客户端要求服务端做的事情。
Content-Length：要求服务器读取内容的长度（字节）
就是去服务器读这么长的长度的Body内容。
为什么要设置这么一个字段呢？为什么我们不能使用分隔符分开，让服务器好认呢？
这是因为如果文本是一个二进制的数据，那么就不可能出现分隔符了，所以为了统一，就用Content-Length去读指定的长度
- Content-Type：文本类型，即客户端传输数据的类型。
比如 text/html就是一个html的文本，再比如 application/jason就是json信息
这里有一个完整的Conent-Type对照表：HTML Content-Type对照表
这里讲几个比较重要的content-type：
（1）application/x-www-form-urlencoded：纯文字表单，不能传输二进制数据（或者必须要提前声明），encoded URL格式
这表示客户端提交的是一个表单。这说明该Request是POST，这会让服务端去查看Request的Body，Body上面会有表单的信息系。
这个Content-Type对应Retrofit的@FormUrlEncoded 注解。
（2）mutipart/form-data：多部分形式，一般用于传输二进制内容的多项内容
它里面可能会包含boundary字段：表示分界线，分界header和body。这是因为二进制的内容比较多，所以为了便于识别每段内容，加了分界线。
二进制的内容比如图片。
application/x-www-form-urlencoded也可以用来传二进制，但是二进制一般都是特别长，这样的处理会占带宽。
（3）application/json
一般都是用来接收数据，一般都是放在Response的Body里面的
一般不用于Requeset中
（4）image/jpeg
只用来传文件，而且是单文件，用于POST请求中。相交于第二个的mutipart使用更加方便。
Chunked Transfer Encoding：分块传输编码
有时候服务器可能会传回很多的数据，其中有一部分可以返回客户端了，还有还要等一部分服务端处理，处理完再传（这个部分很快，但是可能也要几百毫秒），这个时候，为了提升用户体验，就用分段传输了。
当然了服务端要处理超过5s 10s的数据，就不会使用到这个字段了。
Trasnfer-Encoding：chunked
Body格式：
< lenth1>
< data1>
< lenth2>
< data2>
…
0（结束标识）
比如：
5
rikka
3
the
5
world
0
lenth都很长的，上面只是举例。
有时候服务器可能会传回很多的数据，其中有一部分可以返回客户端了，还有还要等一部分服务端处理，处理完再传（这个部分很快，但是可能也要几百毫秒），这个时候，为了提升用户体验，就用分段传输了。
当然了服务端要处理超过5s 10s的数据，就不会使用到这个字段了。
Trasnfer-Encoding：chunked
Body格式：
< lenth1>
< data1>
< lenth2>
< data2>
…
0（结束标识）
比如：
5
rikka
3
the
5
world
0
lenth都很长的，上面只是举例。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
