重识TCP/IP协议族与HTTP基础

926 阅读7分钟

不忘初心 砥砺前行, Tomorrow Is Another Day !

本文概要:

  1. TCP/IP协议族的网络分层
    • TCP三次握手四次挥手
  2. Http简介
  3. 报文结构
  4. Http的请求方法及状态码
  5. 常用的Header

前言:

声明:掌握好HTTP非常重要,具体理由本文最后再揭晓!

一. TCP/IP协议族的网络分层

在了解HTTP协议之前,先来快速了解TCP/IP的网络分层以及三次握手四次挥手的流程.

1.1 网络分层

由于网络的不稳定性,所以将网络分层多个网络模型.

  • 应用层: HTTP FTP DNS
  • 传输层: TCP UDP
  • 网络层: IP
  • 链路层: 以太网 WIFI

大致流程:

  1. 应用层将内容打包好交给传输层.
  2. 传输层负责将内容信息进行切割分包,依次交给网络层.并确认信息是否发送成功.
    • 如果不成功,将数据包继续交给网络层发送.
  3. 网络层只负责将信息的发送到目标地址,不负责信息全部准确发送到目标地址.
    • 确认信息是否发送成功的是传输层.
  4. 最后实际发送的是通过我们的链路层也就是网线和网关路由等.

1.2 TCP三次握手四次挥手

这里用最简单粗暴的方式快速了解其过程,不带任何复杂的专业术语.让你看图就明白.

  • 三次握手

TCP三次握手
  • 四次挥手

TCP四次挥手

可以发现在四次挥手中,第2步与第3步会分开发送,之所以这样是因为此时服务器可能还有消息没有发送完毕.所以就没有像握手流程时一起发送消息.

二. Http简介

HyperText Transfer Protocol 超文本传输协议

  • URL 格式 : 协议类型 + 主机名 + 路径

示例

api.github.com/users?key1=…

  • http : 协议类型
  • api.github.com : 主机名
  • /users?key1=value1&key2=value2 : 路径

三. 报文结构

  • 请求报文结构

HTTP请求报文结构

示例

    GET /users HTTP/1.1
    Host: api.github.com
    Content-Type: text/html
    Content-Length: 110

    bodybodybody假装我是一个Body
    bodybodybodybodybodybody
  • 响应报文结构
    响应报文和请求报文大同小异,只是将请求行换成了状态行.

响应报文状态行结构

示例

    HTTP/1.1 200 OK
    content-type: application/json; charset=utf-8
    cache-control: public, max-age=60, s-maxage=60
    content-encoding: gzip
    
    bodybodybody假装我是一个Body
    bodybodybodybodybodybody

四. 请求方式及状态码

4.1 状态码
status code 类别 原因短语 示例
1XX Informational(临时信息) 接收的请求正在处理 100(继续发送)
2XX Success 请求正常处理完毕 200(OK)
3XX Redirection(重定向) 需要进行附加操作以完成请求 301(永久移动)、304(内容未改变)
4XX Client Error 服务器无法处理请求 400(客户端请求错误)、404(内容找不到)
5XX Server Error 服务器处理请求出错 500(服务器内部错误)

更多信息,可以查看HTTP状态码详解

4.2 请求方式
Method description
GET 1. 获取资源 2. 不发送Body
POST 1. 增加或者修改资源 2. 发送Body
PUT 1.修改资源 2. 发送Body
DELETE 1.删除资源 2. 不发送Body
HEAD 与GET基本一致 , 区别在于返回响应无Body

五. 常见的Header

HTTP的元数据,传递一些附加信息.

格式: 键: 值,注意冒号后面有一个空格

由于Header过多,这里只列举了个人觉得比较重要且常用的Header

5.1 通用的Header
字段名 内容说明
Content-Type 内容类型(下一节详细讲解)
Content-Length 内容长度,单位字节
Content-Encoding 压缩编码格式,如gzip
Last-Modified 资源的最后修改日期时间
Cache-Control 控制缓存的行为,取值为一般为no-cache或max-age=XX
5.2 请求Header
字段名 内容说明
Host 请求的主机和端口号
User-Agent 用户代理,仅用于找到目标主机后确认主机域名和端口
Accept 接受的媒体类型,可以多个值,用,(半角逗号)分开.如text/html,
Accept-Charset 接受的字符集,如UTF-8
Accept-Encoding 接受的压缩编码类型,如gzip
--- ------------------------------------------
Last-Modified 值,用于确认某个资源是否被更改过,没有更改过(304)就从缓存中读取
If-Modified-Since 比较资源的更新时间;值为上一次服务器返回的
If-Match 比较实体标记(ETag)
If-None-Match 比较实体标记(与 If-Match 相反);值为上一次服务器返回的 ETag 值,一般会和If-Modified-Since一起出现
--- ------------------------------------------
Cookie 已有的Cookie
Authorization 用于设置身份认证信息
5.3 响应Header
字段名 内容说明
Location 令客户端重定向至指定URI
Transfer-Encoding 分块传输,如Transfer-Encoding: chunked
Accept-Range 如Accept-Range: bytes,表示服务器支持按字节获取数据
Content-Range 如Content-Range:-/total,表示发送的是哪段数据
----------- ------------------------------
ETag 资源的匹配标识,和Last-Modified、If-None-Match、If-Modified-Since配合,用于缓存控制
Set-Cookie 设置Cookie

最后着重学习下Content-Type,这是实际开发中最经常使用的.

  • Content-Type
    指定Body的类型
  1. text/html 一般用于响应时,返回html页面.

示例

    HTTP/1.1 200 OK
    content-type: text/html; charset=utf-8
    Content-Length: 666
    
    <!DOCTYPE html>
    <html>
    <head>
        ......
    </head>
    <body>
        ......
    <body>    
    </html>

  1. application/x-www-form-urlencoded
    普通表单,提交纯文本.

示例

POST /users HTTP/1.1
Host: api.github.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 33

userName=jasonhww&password=123456

对应Retrofit代码

@FormUrlEncoded
@POST("/users")
Observable<User> login(@Field("userName") String userName, @Field("password") String
password);
  1. multipart/form-data; boundary={boundary} 带文件的表单

将body分成多个部分,每部分都被boundary分成单独的段;

  • 每段以 -- 加 boundary开头,
  • 然后是该段的conten-disposition,
  • 空行,
  • 传入的value,
  • 最后请求结束的标识为boundary后面加--

示例

           POST /users/photo HTTP/1.1
           Host: api.github.com
           Content-Length: 3698
请求头      Content-Type: multipart/form-data;boundary={boundary的值}
空行
请求体part1 --{boundary的值}
            conten-disposition: form-data; name="userName"
            \r\n
            jasonhww
请求体part2 --{boundary的值}
            conten-disposition: form-data; pwd="password"
            \r\n
            123456
请求体part3 --{boundary的值}
            conten-disposition: form-data; name="photo"; filename="文件名.txt";
            Content-Type: image/jpeg
            \r\n
            sdsdsdfqfvfvsvadvavdavakvkakvadvanvnav
            afdfafaiewfre482ekdsji21dnefrgoonwncvewnfefeowkkr假设我是一个文件ddsrrogkrn2n3934
请求体结束  ---boundary的值--

其中Content-Disposition中的filename是区分是否当成文件;因为文件有不同的类型,所以还要使用Content-Type指示文件的类型;如果不知道是什么类型取值可以为application/octet-stream表示该文件是个二进制文件.

对应Retrofit代码

@Multipart
@POST("/users/photo")
Observable<User> uploadPhoto(@Part("userName") RequestBody userName, @Part("password") RequestBody password, @Part("photo")
RequestBody photo);


RequestBody namePart = RequestBody.create(MediaType.parse("text/plain"),
nameStr);
RequestBody pwdPart = RequestBody.create(MediaType.parse("text/plain"),
nameStr);
RequestBody avatarPart = RequestBody.create(MediaType.parse("image/jpeg"),
avatarFile);
api.addUser(namePart, avatarPart);

  1. application/json , image/jpeg
    单内容,实际开发使用较少.

示例-提交json

POST /users HTTP/1.1
Host: api.github.com
Content-Type: application/json
Content-Length: 41

{"userName":"jasonhww","password":123456}

这样请求body中直接为json字符串了

对应Retrofit代码

@POST("/users")
Observable<User> addUser(@Body("user") User user);

示例-提交文件

POST /users/photo HTTP/1.1
Host: api.github.com
Content-Type: image/jpeg
Content-Length: 6666

dsfdsfncwowncnowncodwcw...假设是个文件数据

这样请求body中直接为文件数据了

对应Retrofit代码

@POST("/users/photo")
Observable<User> updatePhoto(@Body RequestBody avatar);

最后顺便提下restFul,其实 RestFul风格就是指规范的使用HTTP,但是国内大多数公司一般都不遵从.比如请求方式,实际就只会用到GET与POST.

另外:前面提到掌握好HTTP非常重要,现在揭晓理由,理由就是调试接口时,与后台互怼的强力保障,再也不要担心他们忽悠客户端了.O(∩_∩)O
不过新时代社会主义还是和谐为主,尽量少互怼,合作共赢才是正道!

由于本人技术有限,如有错误的地方,麻烦大家给我提出来,本人不胜感激,大家一起学习进步.

参考链接: