从HTTP的底层规范上面学习一下，用实际的例子保你醍醐灌顶

文章目录

简述
关于Http的基本标准
- Http的四要素
- 四要素举例
- - 最常见的get请求
  - 普通字符串的post请求
  - 普通form表单的post请求
  - multi-form(多表单)的post请求
Http传递参数的方式
不同的方法有不同的处理方式
其它内容
总结

简述

本文不做基础普及，希望对用过HTTP但觉得不熟悉的人有所帮助，同时我也不对很多细节做太多描述，仅仅对HTTP4要素以及我们常见的传参方式进行讲解，最重要的是我会举实实在在的例子来表达，我学习的时候看了很多文章，了解的感觉不是特别清楚，直到我按照这种方式方式去学习了一下，就完完全全明白了，希望你也可以。

注：本文内容节选与我的另外一篇关于HttpUtils的文章，感觉可以独立出来。

关于Http的基本标准

这边我对Http的基本知识不做太多普及，仅讲述和我设计有关的相关知识。

Http的四要素

众所周知，Http是基于TCP，而TCP是用来传输数据的，说得再通俗一些，就是用来传递字符串的。那么这个字符串到底要如何传递以及如何解析，这就是应用层协议需要设计的，我们平时见到的应用层协议都是围绕“如何来传递字符串”这个目标然后实现的（如何传递也意味着如何解析），Http也是，它的标准就是4要素，或者是4块内容。

请求行
请求行占了一行，格式是：方法请求地址 HTTP/版本号
后面中间分别有1个空格
请求头
这个是多行，每一行都是key:value的形式
空行
就是一个空行，用于区分请求头和请求体
请求体
请求体就是我们常说的body或者form部分了。这个行数不定，那如何知道结尾了呢？就要用请求头里面所标记的Content-Length来判断了，用一些框架在解析的时候，如何发现Length的长度和请求体的长度不一致的时候，就会出现异常。包括接收Http请求或者请求http的时候。

对于Http的响应也是这4要素。

四要素举例

光看上面的解释，其实还是比较抽象的，我举几个平时最常见的例子，一目了然。对了，我都是用postman做的测试。

最常见的get请求

GET /http/get?arg=123 HTTP/1.1
name: xiaopang
Host: localhost:8080

get请求，没有请求体。

普通字符串的post请求

POST /http/post/string?arg=123 HTTP/1.1
name: xiaopang
Content-Type: text/plain
Host: localhost:8080
content-length: 4test

这个相对与之前的增加了3个地方。
请求头增加了Content-Type：text/plain，这个就是告诉接收方我发送的就是普通的字符串，不用特殊处理。
关于这个参数多说一点点，这个看你使用的web框架，会不会用这个，有的根本不会用。
增加了请求体，因此也有了conten-length，这个长度它指的是字节。

普通form表单的post请求

我们经常也会用这种的，就是以key-value的方式去提交表单。都是普通的字符串，这种form我们都称之为“application/x-www-form-urlencoded”。

POST /http/post/form-simple?arg=123&arg1=456 HTTP/1.1
name: xiaopang
content-type: application/x-www-form-urlencoded
content-length: 15name=ywg&age=25

这种的其实还是比较常见的，这边我传递了两个参数，name和age，但是你注意看第一行，我还传递了两个参数arg和arg1，你会发现和请求体里面的格式特别像。这也就解释了为什么叫做form-urlencoded了，form代表了它是表单形式，在请求体里面，同时我还标记了一下它的方式仍然是按照url参数来传递的。
在url后面跟着的key-value形式的参数，我们一般称之为url参数户或者查询参数（query），我比较喜欢称之为查询参数，叫做query。对于这些一般传递的时候都会encode一下，解析的时候需要decode一下。

multi-form(多表单)的post请求

我们这边以传递一个字符串和一个文件为例：

POST /http/post/form-multi?arg=123&arg1=456 HTTP/1.1
name: xiaopang
cache-control: no-cache
Host: localhost:8080
content-type: multipart/form-data; boundary=--------------------------400103441794568578082510
content-length: 350
Connection: keep-alive----------------------------400103441794568578082510
Content-Disposition: form-data; name="name"ywg
----------------------------400103441794568578082510
Content-Disposition: form-data; name="file"; filename="多表单测试文件.txt"
Content-Type: text/plain多表单测试文件
----------------------------400103441794568578082510--

这个很明显复杂了很多，我挨个说一下里面的点。
content-type是multipart/form-data，代表是多表单，然后后面多了一个boundary，也就是边界，什么的边界呢？既然是多表单，那就是多个表单之间的边界。这个是随机生成的，后面的请求体的话以boundary开头，中间以boundary分割，最后以boundary+“–”结尾。
然后我们再仔细看一下form里面的每个细节，你就会发现它完全就是http的3要素啊，请求头+空行+请求体。请求头里面全都是对里面内容的描述，比如它是个字符串，还是个普通文件，或者是图片视频之类的。不过它不需要content-length，因为有boundary。
再看一下传图片的吧，里面的我就不解释了，也不用纠结里面乱七八糟的符号是什么了。

POST /http/post/form-multi?arg=123&arg1=456 HTTP/1.1
name: xiaopang
Host: localhost:8080
content-type: multipart/form-data; boundary=--------------------------345861699398287183379366
content-length: 2324----------------------------345861699398287183379366
Content-Disposition: form-data; name="name"ywg
----------------------------345861699398287183379366
Content-Disposition: form-data; name="file"; filename="多表单测试.png"
Content-Type: image/png�PNGIHDR   �      "]�Q   sRGB ���   gAMA  ���a       pHYs  �  ��o�d  gIDATx^�!�KF�o�G`�80X�$(4�E�Y�D�`
���I0�y��u�����[KOW3�$_z�fz;u��V�   S�C'߿�������(�V�2����@� �7Ba�1��E{�����0�X�PA�o�
�|c T���0����@� �7Ba�1�PA�o�
BF�P�1JǙ?W�*" ������R!�a+���2 Te@�|ʀP� ���A(B�P��g7B�=�[�7  B-�ԦU�5���ҡv�R�Ku��ݡ�c�:mʀP� ���A(�1�޾}K� ��P�߿'U�pL(��2 T�2 T�2 T�2 T�2 T�2 T�2 T����Dl���L�M�nk���C턞�,�9Bw���i�v��3t���ӧO�ȶ �at�~��ux�����ÇW��� BF�۷oW?AWw��Ǐ�+ہ
P�х�r��$��߿?Ĳ�P���*�]�Hb�Ʒ�#%�ԕ�2��w�ܹZ��#Uw���i��2�*T�G_ԙw�-@(èB��]A˝��-o��0�P�f����{�T �aD��u!�Cmys�P���2 T��OM�5�P˔ڴ궔�:�:�N��&j:�A�ӂP�ʃP�ʃP�ʃP�ʃP�ʃP�ʃP�ʃP�ʃP�cB}���TA(�1�Z{L�{�pL(��2 T����Dl���L�M�nk���C턞�,�9Bw���i� ��� ��� ��� ��� ��� �ad��s�z��-�4( �at��{�?T����*e�?T����*{Fm��!�aOB�3��f���Lܔ#�ci��*�|��J�Cm��ڴ�Fz?_:TEK��zj�T�j:�9�X�r T�d�oʷ�I �ad�F��������������������g7B�=�[�7 B-SjӪ���|�P;��6Ku��ݡ�c�5�j�1y�A(�1�Z{L�{�pL(��2 T�2 T�2 T�2 T�2 T�2 T�2 T�2 T�2 T�2�A(�Zx���z��S��t⩣���G�l�Xo�!���Iz�M�nKY��CU���c]MOm6�P�1��(�v��w���;��@(èBic1mݣ-|F��
�{��;�P�ʃP�Q�������
U�2��;�eU(��.UK5��Pj �D�T�oʷ�I �at�F��������g7B�=�[�7   B-SjӪ���|�P;��6Ku��ݡ�c�:e@�e@�e@�e@�e8&YN�����YD�_.//�J�8{�"lu.�PA�o�
�|c T���0����꟯���PA�o�
�|c T���0����@� �7���/����w�W�    IEND�B`�
----------------------------3458616993982871

顺便说一句，这就是http的标准，但这个标准定的是在太大了，也就是太不规范了，因此有了我们常说的REST协议了。

Http传递参数的方式

其实HttpUtils要解决的问题就是http参数传递的问题，因此想写出好的工具类，那就必须知道所有的传参方式，哪怕自己不用，也可以不写，但得知道。上面花那么多篇幅讲4要素，顺便也把所有的参数传递方式讲了一遍，我这边总结一下，下面的几种参数，只有请求体里面只能允许一种情况存在，其它的都可以存在。

请求方法，这也算参数吧，因为在用的时候需要用。
请求地址。
路径参数。
请求头参数。
请求体参数。

关于请求体的话，有这么几种情况。
普通字符串。这个就包含我们常见的字符串，xml以及json，在我眼里。都是字符串。
普通form。
多表单形式。
我觉得就这3种，但是在日常工作中可能提及的不止这么几种，但本质上就是它们。
而且可能更多人用流这个词，这个也没啥问题，因为从Socket编程来讲，确实是这样，以字符串的形式说这些，我觉得更好理解吧。

不同的方法有不同的处理方式

对于Http来讲，整体上就分为两种，有没有请求体。没有的，就是代表性的get，有请求体的就是post(这个也可以没有)。
不要跟我纠结到底get能不能传递body，要严格来说的话，从Http角度来讲，它确实可以传。但是从应用角度来讲，千万不要这样做，这不是一种主流，也不符合REST规范，而且最关键的在于，你所用的框架支持不支持，这是最重要的。
但是对于没有body的情况，你可以认为body是空，因此，它还是4要素，都是一样的。因此我们工具类里面就是分别处理一下上面说的5种参数，然后把它们按照不同的情况进行组合一下，就可以支持很多种情况了。

其它内容

我们在工作中用到的远不止如此，往往都是更加细致的内容，比如请求头的某一个参数代表了某种含义，比如accept-encoding是干什么的，为什么访问有的地址就会直接下载文件，它是通过什么标准去判断的，还有你知道get，post,也知道put,delete，但是你知道OPTIONS方法是做什么的吗？

其实关于http的内容还特别多，这些都是HTTP的规范，或者也是它的进一步应用了，不知道也没有关系，一步一步慢慢来，只要知道了上面讲的知识，所有关于http的都不怕。

REST是对http的进一步规范，让开发用的更加舒服，就是你这样做比较好。

WEBSERVICE是建立在HTTP之上的，它使用HTTP的请求体去传递XML，然后对xml的格式做了很多规范，它重点体现在xml的规范上面，就是请求参数如何传，包含响应如何来解析。

总结

现在，知道http是咋回事了么？