TCP/IP四层中常见协议Ⅰ—应用层

2019-12-05 0 条评论 123 次阅读 0 人点赞

应用层

负责应用程序之间的数据沟通

自定制协议

程序员自己定义的协议/私有协议,例如网络版计算器:

  • 客户端:将两个数字和一个运算符传输给服务器
  • 服务端:对接收到的信息进行解析,得到数字和运算符,运算出结果后将结果返回给客户端

协议的定制:

  • 原理:

    序列化urlencode:将数据对象按照指定的协议在内存中进行排布,称为可持续化存储的/数据传输的数据串

    反序列化urldecode:将数据传按照指定的协议进行解析得到各个数据对象

  • 序列化种类:

    json序列化/protobuf序列化/二进制序列化

知名协议——HTTP/FTP

FTP专门用于文件传输,已经快要被淘汰/用得很少,FTP能完成的事用HTTP也能完成,且HTTP比FTP更灵活,所以选择使用HTTP协议

HTTP:超文本传输协议——早期用于传输超文本数据HTML

网址:统一资源定位符——URL

域名<->服务器IP地址

查询字符串(一个个key=val形式的键值对,键值对之间以&符号进行间隔):客户端提交给服务器的数据,提交的数据中不能出现特殊字符,容易与URL中的分隔查询字符符造成二义,导致URL解析失败;因此若提交的数据中有特殊字符就必须进行转义:

  • URL编码:+(ascii=43)—>16进制数字字符串0x2b;所以c++则被转义为c2b2b;并且为了标识这两个字符是经过URL编码的数据,因此在前边加上%做以标识—>c%2b%2b
  • URL解码:在查询字符串中若遇到了%,则认为紧跟其后的两个字符需要转码:2b—>2 / b;2*162<<4= 32 + 'b' - 'a' + 10 = 43

完整的URL:http://username:password@server_ip:server_port/index.html?

协议方案名称://用户名:密码@服务器IP地址:端口/请求资源路径?查询字符换#片段标识符

将网址输入浏览器回车后,向服务器发起请求

HTTP协议格式:

首行:

主要描述当前的数据使用的协议版本,以及请求的资源路径/请求方法/响应状态

  • 请求首行 格式:请求方法 URL 协议版本\r\n

    • 请求方法

    9种,GET / HEAD / POST / PUT / DELETE / CONNECT / OPTIONS / TRACE / PATCH

    GET:主要用于服务器请求尸体资源,也可以提交数据,提交的数据作为查询字符串存储在URL中,url提交数据:1. 不安全;2. URL长度有限:1kb->4kb;

    POST通常用于提交表单数据

    • URL

    • 协议版本

    http0.9只用于传输超文本数据,只有一种请求方法—GET,短连接—在传输层基于TCP协议,请求应答模式(一来一回连接关闭)

    http1.0 长连接——一次请求答复之后不关闭socket,依然可以使用这个socket发送请求,提高了效率,依然一来一回,长连接默认关闭,可以通过头信息开启,加入POST、HEAD

    http1.1 长连接默认开启,管线化,可以连续发送请求,新增六种请求方法.

    http2

  • 响应首行 格式:协议版本 状态码 状态码描述\r\n

    • 状态码:1xx/2xx/3xx/4xx/5xx

    2xx:请求已经正确处理完毕 200
    3xx:请求重定向 301/302
    4xx:客户端错误 404/400 具体显示通过html更改
    5xx:服务端错误 502/504

头部

更加细致的描述本次数据的一些详细信息

  • 格式:

    以一个个key:val形式组成的键值对,并且每个键值对以\r\n作为结尾

  • 常见头部字段

    Content-Length:正文长度

    Content-Type:传输类型识别

    Transfer-Encoding:传输方式如chunk分块

    Location:位置

    Set-Cookie

    Cookie

    Referer:网页跳转来源

    cookie和session的区别?

    cookie:携带有用户的认证信息/其他信息传递给服务器,保存在客户端 ,每次请求都会发送给服务端

    session:服务端为每个客户端创建的会话, 会话信息包含session_id以及用户验证信息, 都保存在服务端

    第一次登陆,服务端收到登录请求后,会为这个客户端建立一个session,通过set-cookie:session_id:xxxx,将这个会话的id返回给客户端,客户端将这个cookie中的信息保存下来,下一次请求相同的服务器时,会从cookie文件中读取到这些cookie信息发送给服务端

空行

间隔头部与正文\r\n

正文

具体要传输给对端的数据

手动实现一个http服务器

不管请求什么,给对方相应——我好帅

  1. http服务器实际上是一个tcp服务器,业务的数据处理是http协议格式的数据处理
  2. 接受HTTP请求(1. 先接受HTTP头部,根据头部中的Content-Length来接收正文),打印出来
  3. 解析HTTP请求首行(1. 请求方法;2. URL(path请求的资源路径;query_string查询字符串);3.协议版本)
  4. 解析头部(拆开每一个键值对,unordered_map)
  5. 根据业务请求,进行处理响应数据
    1. 响应首行(HTTP1.1 200 OK\r\n)
    2. 头部Content-Length
    3. 正文:

      Hello Word

HTTPS和HTTP的区别

http使用80端口,https使用443端口

https在http协议的基础上进行了一层加密

  1. 数据加密方式:对称加密/非对称加密
  2. 对称加密很容易被破解(一直使用同一种加密方式),因此增加使用非对称加密
  3. 可以动态协商非对称加密算法,但是一旦被劫持后会被获悉加密算法
  4. 采用非对称加密;公钥加密数据,使用私钥才能进行解密,通信时服务端先将公钥传递给客户端,客户端使用公钥对数据进行加密发送给服务端
  5. 非对称加密效率较低(包含重复取模的操作等)
  6. 使用非对称加密加密过的对称加密的算法发送给对方进行协商对称加密算法,以防止被破解
  7. 依然无法避免中间被劫持,中间黑客劫持接收服务端的公钥,然后将自己的公钥发送给客户端,以实现中间代理角色获悉加密后的数据
  8. 因此需要对公钥的传输进行保护,引入签名证书:服务端拿着公钥到权威机构去生成证书,证书中包含公钥,机构信息,认证机构信息。
  9. 通信时先将证书发送给客户端,客户端拿到证书进行解析,获取到机构信息以及权威机构信息和公钥,接下来去权威机构进行机构认证是否身份正确。以此实现先协商使用非对称加密加密过的对称加密算法,协商完毕后在使用对称加密算法对数据进行加密传输。

L_KingMing

这个人太懒什么东西都没留下

文章评论(0)